  |
はてなキーワード: コンパイラとは
やっぱり途中で切れたので続きから
違います。
そうです。
はい。Stadia Games and Entertainmentの組織を発表しました。これは我々の1stパーティのスタジオです。
はい。
Googleは開発者に対し全てのツールを支援しています。Stadia向けの開発は彼らにとって別のターゲットにしか過ぎません。Visual Studioを用いる既存のツールや彼らが用いるツールの全てと共に、彼らのワークフローに統合されます。従ってStadia向けの開発はPlayStationやXbox向けの開発と同じくらい簡単です。
我々はUnrealもサポートします。UnityがStadiaをサポートします。予想される多種多用な業界標準のツールとミドルウェアが準備されます。
とても良い質問です。我々はユーザに対し彼等のインフラの中で何が起こっているかをできる限り理解できるよう支援する必要があります。また我々はゲーマーに対し最適な体験を得られるようなチューニングを行うことが可能な情報に対し投資を行うだけでなく、我々自身の技術を用いて最良のパフォーマンスを実現するつもりです。Googleの技術の多くがインターネット網の基盤であることを思い出して下さい。我々はDCからの情報がどのようにユーザに届くかを良く理解しております。できる限りの最適化を行うつもりです。
その通りです。それこそが我々のプラットフォームの根本的な差別化ポイントです。既存のゲームカタログを持つデベロッパにとってStadiaは簡単で親しみ易いものです。我々はできる限り摩擦なくゲームの移植を行えるようにします。なぜならゲーマーは好きなゲームを遊びたいですし、彼らの愛するキャラクター、ストーリー、世界を楽しみたいのです。しかし我々はまた開発者に未来を描く新しいキャンバスをも提供します。ゲームを高速に配布し、プレーヤーと新しい手段で、特にYoutubeにて繋げます。そして開発者が持つアイデアを実現するための前例の無い技術を提供します。
解決されたと同時に緩和されています。まずデータセンターに対しより多くの人々がより良い経験を得られるようにするための投資が行われました。また圧縮アルゴリズムについては我々に抜本的な先進性が存在します。Googleは圧縮アルゴリズム標準仕様の先駆者でありこの点がストリーミングの将来をより確実にします。残念なことですがGoogleでも制御できない点が光の速さです。そのためこの点が常に要因となります。しかし常に理解しなければならないこととして、我々は常にエッジ(終端)にもインフラを構築していることが挙げられます。Googleの中心にある巨大なデータセンタだけではありません。我々はできる限りエンドユーザの側にインフラを構築しています。それによって歴史上の幾つかの問題は回避することが可能です。さらにまだ率直な、あまり洗練されていないProject Streamのストリーマーでも信じられない結果を出しています。さらに我々はサービスリリース時に1080p60を超える品質を実現できるだけの根本的な改善を行いました。我々は8Kに至るでしょう。
圧縮にネットワークです。我々はGoogleがインフラに投入した数々の改善点に依っています。BBR、QUIC、WebRTCを基盤としてその上に構築がなされました。だからIPパケットの低レイテンシでの配信だけでなく、送信元へのフィードバックも行うことが可能です。ですのであなたが仰るZenimaxが使用した技術なら、彼らはここでも利用することが可能です。彼らは彼らのゲームの最適化を行うことができるでしょう。我々はフレーム毎のレイテンシを予測が可能で彼らにそれに合わせて調整を行わせることができます。
我々は改善を続けます。Streamは最初のバージョンです。我々は性能向上のために調査を行っており、レイテンシに適応していきます。リリース時にはより良くなっているでしょう。
確かにそのとおりです。そしてそれこそがGoogleが何年もかけて開発してきたスキルであり、抜本的なスケールする能力です。我々がどうやって実現しているのか、何をしてきたかについては今日は詳細にはお話ししません。しかしGMailやMap、Youtubeが同時に利用可能であるためと同じ基本的な技術のいくつかが我々が依るものです。
我々は競合他社が何をしているかは存じておりません。
我々の第一世代システムに導入されるGPUは10Tflops以上の性能があり、さらにスケールアップします
AMDです。
情報を公開したくない訳ではないのですが、このプラットフォームが進化することのほうがより重要です。そしてこの進化がユーザと開発者の双方に対しシームレスに行われることを確認して頂きたいのです。そして進化は常に継続し、誰もが常に最新で最高の物を手に入れます。
開発者にもこのように考えて欲しいのです。もちろん完全には抽象化されていません。特にゲームの開発者にとっては。しかし我々はそれでもこのプラットフォームが常に進化していると考えて欲しいのです。速さや容量、リソースには制限されていないのだと。
シェーダコンパイラのツールをいくつか開発しました。これらは開発を楽にするでしょう。しかし現在のGPUはとても優れており開発者が既にVulkanに親しんでいれば、例えばid Softwareさんは既に全てVulkanに移行していますが、そのような開発者の方々には既存のゲームをStadiaに移植するのはとても簡単です。Doom Eternalが4K、60フレームで動いでいるのは既にご覧になったと思います。非常に素晴しい状態です。これこそが我々にとって重要な証明ポイントです。FPSはグラフィックとプレイアビリティの双方で要求が高いゲームです。 従ってこれは我々のプラットフォームの強力な証拠であり、idさんにも講演して頂きます。
x86で2.7GHzで動作しています。開発者にとり慣れのあるものです。開発全体を通して、CPUは制約となる要因ではありません。我々は全てのタイトルを動作するに十分なCPUを提供します。
沢山です。
しかしサーバ級のCPUです。Stadiaはこれまでのコンソールと違いパッケージングに制約を受けません。熱対策の問題も異なります。コンソールとはサイズやパッケージングの動機が異なります。データセンタの中でそれはとても汚なく見えるかもしれません。一方でとても帯域幅が高いメモリが使用可能で、とても高速なペタバイト級のローカルストレージも使用可能です。ご家庭のコンシューマデバイスよりも数百倍は速い物です。
パートナーには彼らが話せる時点で彼らの計画を教えてくれるよう伝えています。Stadiaをこの世界で最も偉大なゲームの開発者達に説明することにはとても興奮します。Stadiaは、開発コードではYetiと呼ばれていましたが、Stadiaのビジョンを説明すると、開発者のリアクションは「これは私が期待したものそのものだ。これはまさに我々の次のゲームのためのビジョンそのものだ。elastic computingの考え、次世代レベルのマルチプレーヤー環境、ゲームを観ることと遊ぶことの境をあやふやにし1つの体験にすること」と話されます。
イノベーションの1つの領域として、最初のほうで述べましたが、マルチプレーヤー環境において、単純にパケットを複数のプレーヤーにリダイレクすることから、原子時計レベルでのコンシステンシーを全ての状態遷移において定期的にクライアント間で更新する真のシミュレーションへの移行が挙げられます。これにより開発者はこれまでには不可能だった分散された物理シミュレーションを得ることができます。これだけでもゲーム設計のイノベーションに対し大きく寄与します。このため多くの開発者が、大袈裟でなしに、実際にとても感動的なリアクションを我々のプレゼンに対して返して下さっています。
これこそがゲーム業界の素晴しい点です。技術が常に創造性を刺激し、ゲームに対しより大きな聴衆を作り、そのことがプレーヤーと開発者に対しより大きな機会を作ってきました。エコシステムが進化し、正の方向に回り続けるなら、それはゲームを遊ぶことにとって良いことです。
3台のGPSが一緒に実行されるデモを行っています。私は上限が無いとは申しません。しかし我々は技術上の限界を上げています。そしてStadiaは静的なプラットフォームではありません。このプラットフォームは5年や6年の間、レベルが変わらない訳ではありません。開発者とプレーヤーの要求に従い、成長し、進化するプラットフォームです。なぜならStadiaはデータセンタの中に構築されています。進化させるのは我々にとって簡単なことです。
CPU/GPU/メモリ帯域幅の変更にはいくつかの自然な段階があります。これは家庭の物理な小売の端末よりももっとスムースでより継続的な進化です。しかし、より重要なことは基盤データセンタ網とそれに含まれるネットワーク技術への投資です。この2つが一致して行われることが重要でどちらか1つではダメなのです。
それは我々も既に行っています。Googleが既に20年以上、行っていることです。我々が依って立つまた別の巨人の肩です。
我々はStreamをさらに強化させています。従ってユーザはこの制約が全体のスタックに対する改善と最適化、また特に時間によって緩和されることを期待するでしょう。我々はその期待の上を行きます。
私は具体的な数値についてはコメントしません。しかし当然低くなります。
インターネットの接続環境はStadiaをリリースする市場では全体的に上昇機運が見られます。つまりこのパフォーマンス特性はますます多くのユーザが利用可能になります。
さらに繰り返しになりますが、BBRを初めとする我々の技術があります。さらに覚えておいて頂きたいのは我々のネットワークに対する理解はそのままではありません。それらもまた時と共に改善されていきます。Youtubeはマクロと
Eurogamerにより独占配信されたStadia開発者二人に対するインタビュー記事。
---
タイミングの問題です。20年間の蓄積によりGoogleにはデータセンタ内のパフォーマンスに優位性が存在します。Googleはデータセンタ内ではHWメーカーです。我々はデータセンタ内で何年もの間、高い性能で端末間を接続する基盤を構築してきました。Youtubeでの経験からプレーヤーサイドの観点からだけでなくデータセンタ内部からの技術的観点からの技術統合を行ってきました。他社でもその視点は存在していますがGoogleにはその点に固有のアドバンテージが存在します。
その通りです。我々にはレガシーがありません。全てが21世紀のために設計されています。開発者は制限の無い計算資源が利用でき、何よりもマルチプレーヤーをサポートできます。これまでのマルチプレーヤー環境は一番遅い通信に影響を受け開発者は最も遅い接続に対し最適化が必要でした。我々のプラットフォームではクライアントもサーバも同じアーキテクチャの下にあります。これまではクライアントとサーバの間のpingに支配されていましたが我々の環境なら最速でマイクロ秒で済みます。だからプレーヤーの数は単一のインスタンスにて動的にスケールアップが可能です。バトルロイヤルなら数百から数千、数万のプレーヤーが集まることも可能です。それが実際に楽しいかどうかは置いておくとしても、新聞のヘッドラインを飾ることが可能な技術です。
両方です。
ユーザが我々のプライベートLANからはみ出さないだけでもその効果は大きいものです。Googleは45万kmに及ぶ光ケーブルにより世界中のデータセンタ間を接続しています。米国の西海岸から東海岸まででも20ms、フランクフルトからマドリッドでも20ms。これにより開発者は最も極端な場合においてもレイテンシが予測可能でそれに従い設計を行うことができます。
StadiaはYoutubeの技術と深く結びついていますが、実際には一歩引いています。今日のゲーム業界を考えてみて下さい。2つの世界が共存しています。1つはゲームをプレイする人々で、もう1つはゲームを見る人達です。2億人の人々がYoutubeでゲームを毎日見ています。2018年には述べで500億時間がゲームを視聴するのに費されています。時間と人口の双方で信じられない程の視聴が存在します。我々のビジョンはこの2つの世界を1つにすることでゲームを見ることができ、かつ、プレイもできる、双方向に楽しめることです。
つまり重要なのはゲームシステムでもなくコンソールでもありません。噂とは異なり我々はコンソールビジネスには参入しません。我々のプラットフォームの要点はコンソールでは無いことで、皆が集まる場所を作ることです。我々は箱でなく場所を作る。今までと異なる体験を得られる場所です。ゲームを見るなり、遊ぶなり、参加する場所であり、かつユーザが楽しむ場所であり、ユーザが他人を楽しませる場所です。
だから我々のブランドはStadiaといいます。これはスタジアムの複数形です。スタジアムはスポーツを行う場所ですが同時に誰もがエンターテイメントを楽しむ場所でもあります。だから我々はそれをブランドにしたかったのです。皆が遊んで、観て、参加して、さらにはゲームをする場所。一歩下がって見ることもできる場所。常にどのボタンを押したかを意識しないでも良い場所。他のアーキテクチャでは実現できない場所です。
その通りです。そして単純に技術的に深い点を求めて、我々は第一世代でも4K60fps、HDRとサラウンドをサポートしました。さらに開発者が必要なインフラに従ってスケールします。それだけでなく、同時にYoutubeに常に4K60fpsHDRで画像を送信することが可能です。だからあなたのゲーム体験の思い出は常に最高の状態になります。
プレーヤー次第です。Googleは全てを記録はしません。もしプレーヤーが望むならGoogleは4Kでストリームします
共有が友達だけか、世界中に公開かも自由に選択可能です。Googleはユーザに制御を明け渡します。もしユーザがYoutubeで公開すれば誰でもリンクをクリックすることでそのゲームを遊ぶことができます。
そう。そしてこれはマルチプレーヤーゲームのロビーの新しい形となります。Youtubeのクリエイターなら誰でもがファンやチャンネルのsubscriberを自分のゲームへと誘うことができます。生主として、Youtubeのクリエイターとして私は視聴者を私のゲームに瞬間的に招待できます。それが私と10人の友達でも、(訳注: セレブの)Matpatと彼の数百万の購読者でも、技術は同じです。
Googleアカウントの一部です。従ってGMailアカウントがStadiaへのログインに利用できます。他の基盤についても説明させて下さい。最初のサービス立ち上げから全ての画面への対応を行います。TV、PC、ラップトップ、タブレットに携帯です。我々のプラットフォームの基本は画面に依存しないことです。これまで40年間、ゲーム開発は端末依存でした。開発者として私は制約の範囲内で、私の創造性を開発対象の端末に合わせてスケールダウンする必要がありました。
我々はStadiaでそれを逆にしたいのです。我々は開発者に対し彼らの考えをスケールさせ、どの端末の縛りからも解放したいのです。パフォーマンスに優れ、リンクをクリックすればゲームは5秒以内に開始されます。ダウンロードもなく、パッチもなく、インストールも必要なく、アップデートもありません。多くの場合、専用のHWも必要がありません。従って古いラップトップでChromeブラウザを使用する場合にでも皆さんが既に持っているだろうHID仕様に準ずるUSBコントローラが動作します。そして、もちろん、我々自身のコントローラも開発中です。
コントローラを自作する理由にはいくつかあります。1つはTVへの接続です。我々はChromecastをストリーミング技術に採用します。Stadiaコントローラの最も優れた機能の1つはそれがWiFi接続でDC内のゲームに直接接続することです。ローカルのデバイスとは接続しません。
その通りです。これこそが我々のブランドの実現であり、具現化です。そして独自コントローラにより最高のパフォーマンスが実現します。ゲームに直接接続するためにプレーヤーは画面を移動することが可能です。プレーヤーはどの画面でも自由に遊び、停止し、他の画面でゲームに復帰することが可能です。
そしてコントローラには2つの追加されたボタンがあります。1つはGoogle Assistantの技術とマイクを用います。ユーザの選択により、ユーザはプラットフォームとゲームの双方に対し、自然言語を用いて会話が可能です。例えば「Hey, Google。MadjとPatrickと一緒にGame Xをやりたいな」と言えばStadiaがマルチプレーヤーゲームを指定した友人と共に直ぐに開始します。
我々はゲーマーを可能な限り素早くゲームに辿り着かせるよう考えています。数多くの研究を行いましたが、多くのゲーマーがゲームを起動したら直ぐに友人とゲームを開始したいと考えています。ゲーマーはUIに時間を費したくは無いのです。
誰かが言ったことですが、現在のコンソールは起動した時にまるで仕事のように感じると言うのです。ゲーム機自体の更新や、ゲームの更新があります。我々はそれらを完全に取り除きたいと考えています。もう1つのボタンは、ちょっと趣が異なるのですが、Youtubeにシェアできます。
Youtubeが観られるならどこでもStadiaは動きます。
Chromecastはスマホからストリームを受取はしません。Chromecastはスマホから命令のみ受けます。画像はNetflixやYoutubeから直接受け取ります。Stadiaの場合、StadiaコントローラからChromecastへとこのゲームのインスタンスへと接続せよと命令がなされ、Chromecastはゲームインスタンスから動画のストリームを受け取ります。クライアントはとてもシンプルです。行うのはネットワーク接続、ビデオと音声のデコードのみです。Chromecastは入力を処理しません。全て入力はコントローラが扱います。ビデオと音声とネットワーク接続はChromecastの基本動作で全て既に組込まれています。
そうです。とても良く出来ています。WiFiに繋ぐだけです。コントローラにはWiFiのIDとPWを入れるだけです。それだけです。ホームボタンを押すと勝手にChromecastを探し直ぐにChromecast上でクライアントを起動します。UIが表示され直ぐにゲームを遊ぶことができます。デジタルパッドでUIを操作することも可能です。これが重い処理を全てクラウドへと移行する点の美しさです。Chromecastのような低消費電力の端末で説得力のある体験ができます。Chromecastは5W位下です。Micro-USBで給電可能です。典型的なコンソールは100から150Wもします。またこれまで説明しませんでしたが、例えスマホでも行うことは動画の再生だけです。従ってAssassin's CreedやDoomや他の重いゲームがあなたのスマホの上でモバイルゲームよりも低消費電力で動作します。だからスマホで10時間でも遊べます。
今の所、我々はChromecastのみに集中しています。でも技術的、機能的な観点からはYoutubeがある場所ならどこでも動きます。我々はまだStadiaをどのようにユーザに届けるかは検討中です。
サービス開始時から提供されるサードパーティによる解決手段をサポートしています。他にもアイデアがあります。しかし今は話せません。
良い質問です。私がこのプロジェクトに参加する前からチームは既に何社かと提携しここ何年かの間に技術を提供していました。StadiaはLinuxベースです。グラフィックAPIはVulkanです。開発企業はクラウドにインスタンスを作成しますので、開発キットも今ではクラウドにあります。しかしクラウドだけでなく、開発社のプライベートなDCでも、机上のPCでも可能です。
もしそうしたいなら。でも我々は今後のトレンドが開発でも配布でもますますクラウドへと移行していくと考えています。従って今後数年で開発者にとってクラウド中心、クラウドネイティブがゲーム開発での標準となるでしょう。
デベロッパーやパブリッシャーはとても賢くクラウドネイティブとなる新しいゲーム体験を達成するために必要なツールや技術について考えていると思います。しかしそれは世界中で何千ものアクセスポイントを持つデータセンターを運営することや、それらの運営に必要な莫大な投資資本とは異なるものです。Googleは今年単年でも$13Bの資本を投下しています。
米国では全ての必要な場所に展開が終わっています。Project Streamの試験に必要な環境は2018年末には整いました。我々はGoogle社内で、Google社員を対象に2017年の始めから2年間の間、プライベートなテストを行ってきました。2019年には米、加、西欧、英にて 
ツイートシェア
まあ終了自体は仕方ない。このゲームはゲームと言うには余りに大きな設計ミスを抱えすぎており、また、システム的にもかなり古くなっている。
だいぶ前からオンラインゲーム終了時にどうするか、という話はあるけど、あまり進展はない（ソシャゲ、ネトゲ等のサービス終了後のゲームの保存について考える、とか、米国でサービス終了オンラインゲームを著作権法例外とする動き―ESAは反対とか）。一つ根本的な問題として、本当にオンラインが重要なゲームはオフラインモードに余り意味がないのも大きい。
逆に、ゲームとしてのサービスが終わろうが俺には見たいエロシーンがあるんだよ！
anond:20190209083051 とかでも書かれていたけど、エロの質はいいし、ここにしかないものも多い。しかもそれは(ゲーム上で)自分が苦労して手に入れたものだ。勝手に閉じてほしくない。
……けど、運営コストを考えたらそうも言ってられないのはよく分かる。
自分入手した分のデータをダウンロードして、後は各人がローカルPCで再生すればいい。
必要な機能は大きく分けて、サーバからデータをダウンロードしてくる部分、それからデータ（カードやエロシーン）を閲覧するパートだ。
ちなみにこのゲームは初期に作られただけあって(?)、エロシーンに機能が少なく、BGV はおろか BGM も無い。オーバレイも１枚のみで、基本的に背景(シーン画像含む)と、テキストに 1:1 対応するボイスしかない。
これなら割とできそうな気がしたので保存・再生するソフトウェアを書いてみることにした。
https://aakeeper.appspot.com 驚くほどあっさりできてしまった。
でも、今はできた物自体の話はいい。それより作る過程で色々感動したのでその話をしたい。
今回使ったのはざっくり以下のもの
Quasar Framework も Node.js も Electron も使うのははじめて、他はちょっと触ったことあるけどそんな詳しくない。 ES もあまり好きでなかったので基本的には避けてきた。
Quasar Framework は、とにかく物凄くよく出来ていてびっくりした。今回 Electron モードしか使っていないけど、本来はこれで SPA/PWA/モバイル(Cordova) アプリケーションが作れるという凄まじい対応幅のプラットフォームになっている。着手時に 1.0beta の予告だけあるというタイミングの悪さ(数日後に出た)だったので、 0.17 系を使った。しかし、それでも十分すぎるほどよく出来ている。
ES は今でも嫌いな点は多いんだけど、今回 async/await を使って感動した。これは素晴らしい。他の言語にも欲しい。
CoffeeScript は趣味だけど、とにかく短く書ける点が素晴らしい。あれは終わったという人もいるが、記述量の少なさは js 系では他の追従を一切許していない。今回みたいな急いでいるケースでは、括弧の世話を焼いたり eslint おばさんと語り合う時間はない。CoffeeScript ならコンパイラが全部上手くやってくれる。
HTML5 ベースの GUI は今や chronium の各種アクセラレーションのおかげで、並のポータブル GUI ツールキットよりずっと高速に動作する。
また、Vue.js + pug は非常に記述量が小さくて目的の画面がすぐ作れ、カプセル化がしやすくコンポーネントの再利用も容易だ。
Babel/Webpack は正にバッドノウハウを煮詰めて固めた感じだが、こいつがバッドな部分を吸収してくれるおかげで開発者は正気を保てる。ただし追求しだすとSAN値が減る。
ユーザ側から見ると、Electron 製のアプリはメモリをやたら喰う、少しもっさりしている、配布バイナリが巨大になるという問題は確かにある。
しかし、そうだとしても何より、とてつもなく高速に作れて、各種プラットフォームで割とちゃんと動く。
自分は色々初めてだったので結局２週間分くらい掛かったけど、前提知識が揃っている人なら本当に数日でできたりするんじゃなかろうか。
つい数年前まで、クロスプラットフォームなアプリケーションの作成というのは本当に本当に大仕事だった。こんなに早く手軽に書ける事は無かったし、ユーザ側でもラインタイムのインストールが必要とか環境側のハードルも非常に高かった。
自分は今まで知らなかったけど、最早そういう時代は終わっていた。
もちろん過去に数多くのクロスプラットフォームフレームワークが登場しては消えていったのと同じく、Electron もいつかその仲間入りをするだろう。
でも確実に、びっくりするくらい状況は良くなっている。
興味があるけどまだ触ってないという人は、ぜひ試して感動を味わってもらいたい。
https://www3.nhk.or.jp/news/special/net-koukoku/article/article_02.html
で言及されたSpeee社に所属した事がありその時の所感を述べてゆきたい。(そこそこ長くなったので時間がない人は総括だけ読んでほしい)
創業者のH氏からして名古屋大の物理学部であり、理系高学歴が立ち上げた企業だった。H氏は理系卒だが営業経験があり20代前半でSpeee社を起業した非常に優秀な人間であった。
ざっと思い出すだけで、東工大、早稲田、慶應、京大と言った世間一般でも高学歴と呼ばれる人間が中心に構成されていた。
基本は学歴不問で高卒叩き上げみたいな人もいたが高学歴者が中心であった。
開発部には、商用コンパイラ作成経験があるという本当に優秀な人もいたし、高学歴で優秀な人が多かった。
また、人柄も多くは世間的には「いいヤツ」と呼ばれるような前向きで、気さくで親切な人が多かった。
ただ、私の在職中に敏腕営業マネージャーのパワハラが発覚し、飛ばされかけた事件もあったことにはあったので、演じることがうまい人も多かったのかもしれないが。
まぁ聞いた話によるとSpeee社は一度派閥争いにより乗っ取られかけたことがあるので、人柄重視の採用をしていたらしい。
私が在職中のSpeee社の事業の柱はSEOだった。当時はまだページランクが存在していて、それをあげるに被リンクが有効だった。
なので何をするかというとお客さんのページにリンクするためにブログなどにツールを使ってリンクを貼りまくるという結構グレーというか、
今なら完全にブラックな事をしていた。
他にもページランクが高いドメインが売られていると自動的に購入するツールや、
意味のないワードサラダまみれのサイトを自動生成しそこからお客さんのページにリンクするツールなどを作成していた。
ほかにもお客さんのページの検索順位を記録するために、グーグルの検索結果をDBに保存するため、レコード数は数十億とあった。そのため大量レコードを捌くノウハウみたいなのは結構蓄積されていた。
私が所属していたのは開発部だったので、ここらへんのツールの作成やメンテを行っていた。
当時のSpeeeの中心は営業部であった。前述したように創業者のH氏からして営業出身であり、創業に必要な資金を貯めれるくらいには優秀な営業であった。
そのため、営業部はH氏のお目にかなう優秀な営業部員で構成されており放送局など大手企業からの案件を受注していた。
Speee社の営業部には他のWebやSIerにはない特異な風習があった。
それは大手案件を受注した営業がオフィスの中心で受注報告を行い、それを全社員が聞き拍手喝采を行うというものだった。
おそらく営業になろうという人間は他の部署の人間に比べて目立ちたがり屋が多いのでこの風習は麻薬的にモチベーションを爆上げしたものだと思われる。（もしこれを読んでいて営業成績に悩んでいる経営者とかいたら参考にしてほしい）
あと、SEOを分析する部署もあり、この部署には東工大数学科出身の人間などがおり、コンサルティングと数値分析を行っていた。
このように営業部的な雰囲気が私に合わなかったが、基本的には働くには良い会社だったと思う。業務が倫理的にグレーな事を除けば。
当時の事を総括すると高学歴かつ優秀で人柄もいい人たちが、情弱を騙すような倫理的にグレーな事をして結構な利益を上げていた。
その有様はスタンフォード監獄実験のようだった。
これが資本主義で金を稼ぐという事がどういう事なのかを実感できた。
WELQ事件などを通してグーグルの検索結果はゴミばかりと認知されてきたが、Speeeでの経験はそれを予想するには十分であったし、個人的にはそれほど踊ろなかった。
そして、ネットの理想とか良心は資本主義の前には、あっさり敗北するものだと認識できた。
勝手にジョークぶちあげて揚げ足取られたら話の筋道をそらすのは如何な論法かと思うけどね、ジョークならジョークで完結させろよと言いたいが、「それはジョークだじゃあ話を元に戻そう」、これでいいのでは？それとも子供に対してCPUのことを計算してくれる装置ですよと語りかけるが如く丁寧懇切に連立方程式の解き方からBLASの存在まで説明しろとおっしゃるのかな？
それは筋が通らない話だと思うし議論する気があるなら最低限・・そうだな大学がならう数値計算とか並列計算機の授業のレジュメをさらっと目を通すぐらいはしたらどうでしょうか？
https://www.cspp.cc.u-tokyo.ac.jp/hanawa/class/sp20180925.pdf
うーむHPCに対するアプローチは二通りあって情報工学的に計算機科学の一環（つまりスパコンを作る側）として見るか、1科学者としてのシミュレーションを行う場、仮想実験場（スパコンを使う側）としてる見る場合の2つのアプローチがあると思うのだけど・・・PEZY-SCを搭載したシステムに関しては前者、計算機科学の成果としてみるべきシステムだと思うのよ、これの成果としては「非GPUで超メニーコアシステムを実現すると共に高効率なシステムを構築することに成功した」って言う一つの事実に集約されると思う。
でここで高効率なシステムの基準はなんなのかとというと「HPL」と言うベンチマークですわな、HPL=LINPACKと言う認識で話を進行させるけど、HPLは本来連立方程式の求解を行う速度を競うベンチマークであって、これを皆が手放しで賞賛してるのはおかしいと言う批判が存在する。
これは一理あってすべての科学技術計算の性能向上に寄与する指標とは言いがたいからだ。
じゃあなんでこれが推されている居るかというと理由は何個かあるけど連立方程式の解を求める必要のある技術計算はとても多いから、昔からやっててデーターが揃ってるから
ここまででHPLが重要視されている理由がご理解いただけると幸いなんだけど・・じゃあ具体的に連立方程式を使用する場面を示せよと言われると腐るほどあってどれを示せばいいのかわあらんのですが・・
http://www.cs.kyoto-u.ac.jp/wp-content/uploads/2012/07/05hori.pdf
まああんまり人様の研究をあれこれ紹介して間違った説明しても申し訳ないので中身には触れないでおくけど実際に連立方程式は最もシェア率が高い問題であると言う認識は持ってくれると
話が早い
まあさっきのXeonでいいじゃんって話も一理あって性能が低くてもx86_64時代のコードそのまま使いまわせるし、さっきあげたユーザー側から見た時楽ちんであるのは事実だ。
なによりintel C++/Fortranコンパイラと言うクソ便利なものがあってライセンス料払うとある程度勝手に高速化してくれたりするし使いまわせるコードも多い
まあPEZY-SCよりXeonのほうが計算機を研究してるわけじゃない物理学者とかの各種研究者エンジニアからすれば魅力的な点が多いのは事実だと思う
だからと言って計算機科学としての計算機の純粋な性能向上を主とする研究・開発成果を邪険にしていいわけないしまた別の問題、確かに商業ベースで考えたとき
これらの問題をどうにかしないといけないのは事実だし改善して行かねばならないのはPEZYやエクサスケーラーの各位に残された課題であるのは間違いない。
だが少なくともまだこの世に銀の弾丸となりうる万能システムは存在しない。
もしあるなら俺にくれ あといい加減なこと言ってたらゴメン、強いひとに殴ってもらうと筋トレになる
個人的には、
という順番がいいと思う。
…というかんじ。
双方の立場の一番の違いは、動的型付け言語がシステムの非平衡状態を重視するのに対し、 静的型付け言語は平衡状態を重視していることなんじゃなかろうか。
型とは設計である
型とは設計だと思っている。しかもコードから乖離することのない、生きた設計だ。
型を見れば静的な性質の多くが分かる。
型を見てそれらが分からないようなら、それは設計(型)が悪いのだろう、と僕は思っている。
設計の変更時にはコンパイラが何処を直せば良いか全て洗い出してくれる。
静的型付言語では型が煩わしくなるという旨の発言を聞くたびに、僕には「私は設計が出来ません/設計を考えた事がありません」と言っている様にしか聞こえない。
徴兵制度。それは就職・採用活動と名を変えて今でも日本社会に延々と受け継がれている。
卒業年度の翌日である4月1日。この日に正社員の職を得ていない者は社会の枠からはみだした者とみなされ、批難・嘲笑の的だ。徴兵検査で落とされた者、良心的徴兵拒否をしたものには社会は徹底的に厳しい。再チャレンジの芽は徹底的に摘まれる。
大学卒業後に半年間世界を放浪してリフレッシュした気分で仕事を探すなんてとんでもない。「ちょっと旅行に行くから徴兵検査を先延ばしにしてくれない？」なんて戦時中に言う奴がいるだろうか。
我先にと徴兵検査の列に並んで、上官殿に踊れと言えば踊り、歌えといわば歌う。兵士を目指す者として当然だ。徴用されるまでには何度も何度も別の列に並ぶのは極めて一般的である。
苦労して徴兵検査に合格したとしても彼らを待っているのは帝国陸軍ゆずりの初年兵いじめだ。古年兵は初年兵より常に偉く、常に正しい。
「兄より優れた弟なぞ存在しねえ！！」と。
一流大学でコンパイラの最適化を研究していた初年兵よりも、HTMLすらまともに書けない古年兵の方が圧倒的に正しい。よって彼らから礼儀作法や精神論などを徹底的に叩き込まれる。おじぎの角度や名刺の渡し方が何よりも重要なのは言うまでもない。
この過程によって「新人の自分のほうが優秀な部分もあるはずだ」といった反逆思想は矯正され、「大学で学んだ事など社会ではなんの役にも立たない事が分かりました。先輩のやり方をそっくり踏襲させていただきます。」といった優秀な兵士に育っていくのだ。
そうした思想矯正研修を無事に修了したら初めて配属部署が決まる。間違っても初年兵が自分のやりたい事を選べるなどと思いあがってはいけない。
仕事よりも面子が大事なので、それを守るためにルールが沢山あるのは当たり前。上司や先輩が残業しているのに先に帰るなどはもっての他だ。毎日夕方に家に着いて家族とご飯を食べるなんて夢は諦めた方がいい。そんなのはサザエさんの世界の話だ。マスオさんにしか許されない幻想だ。初年兵諸君は決して惑わされてはいけない。
日々乗っている快適な満員電車が人身事故で遅れたとしても会社に遅刻するのは決して許されない。長い列に並んで遅延証明書なるものを貰っても効果はあまりない。叱責のセリフが「遅刻した事には変わりがない。２本前の電車に乗っていれば間に合っていた。」などといったありがたい小言に変化するぐらいである。
ちなみに開始時間には非常に厳しいが終了時間には無頓着だ。仕事が長引いても延長証明書などは発行してくれないのでプライベートの予定は最初から入れないように気を付けよう。
もし君が「荷物が家に届く予定なのでそれまで自宅で作業してから出社します」なんてメールを送ろうもんなら、係長、課長、部長クラスまで集まって反逆思想矯正のための対策会議が開かれることだろう。
(他にも上司より高いランチを注文してはいけないなど、数限りないルールがあるのだがキリがないので割愛させていただく。)
さて・・・このような数限りない理不尽に耐えている会社員はさぞかし高い給料を貰っているに違いないと皆は考えるだろう。
否っ！全くの反対っ・・！
過去20年で他の先進国の賃金がどんどん上昇して行っているのに比べて、我が国の賃金はどんどん下降している。
専門職にいたってはわが国の賃金は他の先進国の半分以下といった水準である。大企業でも昇給はすずめの涙。入社二年目になったら住民税が引かれるので手取りはむしろ減るのが当たり前だ。
答えは簡単。ここまで書いた全ての事を逆にすればいいだけだ。
え？そんな無茶苦茶な会社あるの？と思うかもしれないが普通のアメリカ企業はこんな感じだ。
果たして学生に最初に教えるプログラミング言語はCで良いのか？ってのは情報系大学学部でも議論紛糾してて、
データサイエンスの教授はPythonでいいじゃんと言ってるし、
中学生なのにすごいね、とか女の子なのにすごいね、と言われると悔しいですね。 女じゃなかったらすごくないのかな、とか思ってしまう。 https://twitter.com/YukiMihashi/status/1054325472480264192
小中高大のときは「女子」のほうが頭いいし、むしろ女子のほうがプログラミングなり音楽は秀でて当然ではないか。
「中学生で」というのは、ひとむかし前はパソコン１台３０万で、コンパイラー１０万は必要で、
そもそも敷居が高すぎてやる気があっても触れることすらできなかった。
今となってはブラウザで Ctrl+Shift+i のコンソールから alert("こんにちはこんにちは！！ "); で即入門可能。恵まれすぎてる。
実を言うと、普通のプログラマはオブジェクト指向以前のプログラミングも理解できないんだけど、あれらはまだ手続き的な要素を内在してるから、そっちだけを受け取ることはできる。
それまで手続き的な要素＋宣言的な要素だったプログラミングが、関数型プログラミングへと移行する時に手続き的な要素を切り捨てたのね。より純粋な手法に進化するために。
だから、それまで手続き部分だけを受け取って喜んでた普通のプログラマは急にわからなくなりヒステリーを起こした。
だけど、プログラミング上級者はオブジェクト指向以前にも宣言的な部分しか見てないから普通のプログラマが何を騒いでるのかわからない。
普通のプログラマって、部品化の凄いやつが関数型プログラミングになるとか勘違いしがちだけど(staticおじさんもその変奏)、全く質の違うもの。
部品化って、重複コードをひすたらサブルーチンに括り出すようなもの。副作用がある。
日本のSIer(日立NEC富士通とか)って教養がない極東の田舎者だから、副作用を理解できない。すぐに「部品化」を持ち上げる。怖いんだろう。自分に理解できないプログラミングが。モナドですら大多数は理解できないんだもの。あんな教科書的なものですら。
とにかくアジアってIT後進国なのね。トップの日本ですらこうなのだから。"NTT"データがHaskellでレガシーシステムを脈絡なく解析してホルホルしてるレベルだもの。
まず日本に生まれた時点で、関数型プログラミングを理解するには圧倒的に不利。こんなこと言うと、「普通のプログラマにもわかやすく説明できるのが一流ダー」みたいな恥ずかしい駄々っ子が沸いてくるけど、プログラミングって歴史上一度も大衆を相手にしてないので。
OSSの恩恵で、普通のプログラマもコンパイラを無料で使えるようにになっただけで泣いて喜ぶべき。
そしてあれは、将来のスポンサーとコミッタの入り口としてやってるの。1000人に1人、将来コミュニティに貢献する人材がいるかもしれないと信じて。
シリコンバレー住人にもOSSコミッタにもなれない普通のプログラマはまあ、おこぼれで"文化的"コスプレしてQiitaでもやればいいんだと思うよ。
MS製のVisual Studio Codeを使えば、MS言語のTypeScriptも苦労せずに済む。
http://www.atmarkit.co.jp/news/200711/07/techday.html
「Emacsは30年前には、すばらしいものだった。しかし、Emacsは消滅すべき。現在のEmacsが30年前のものと似ているのを見るのは、何だか寂しい」。
Javaの生みの親であるジェームス・ゴスリング氏は、UNIX上で標準的に用いられてきたテキストエディタ、Emacsの開発者としても知られている。
ゴスリング氏は最近のコンパイラや開発環境の進化について触れ、「もうテキストエディタを使ってはいけない。NetBeansを使ってほしい」と語りかけた。
私は20代半ば手前の者です。
昨年仕事（第一次産業）を辞めてしまい、学歴もスキルもないのに何やってんだろ...と引きこもりかけたところ、
ハローワークで長期の職業訓練を見つけたので応募してみました。
それは専門学校に委託される２年間の訓練でした。その間失業保険の支給は、期限が過ぎても延長してもらえます。
要するに入学料・授業料タダ、お金をもらいながら勉強でき、専門卒になれるチャンスというわけです。
（本当に有難い制度です。就職したら、きちん税金を納めて世の中にお返しするつもりです）
どうやら希望者は少なかったようで、筆記（中学レベルの知識で大丈夫でした）と面接はすんなり通りました。
同じ訓練生は1割程度です。(30~40代の方が2人おられます）
ワイワイやる人が3割、静かな人が7割ぐらい？ といった印象です。
男子100%ですが、ホームルームだけは女子１００％のコースと一緒にやります。
悪い人はいない感じで、授業が荒れて成り立たないとか、そういうのはなくてよかったです。
ただ、バイトが忙しいのか授業中イビキかいて寝ちゃう人や、全然授業について行けなくて辞めちゃう人はいます。
○Office（前期のみ）
word,excel,powerpointを一通りやりました。PC操作に慣れていない人も多いので、
手取り足取りゆっくりやる感じでした。自分は仕事で使ったことがあったので、課題を早く終わらせて
○C言語
terapadとコマンドプロンプトを使っての授業です。（コンパイラはborlandです）
元SEの先生（本人曰くCOBOLer）の説明聞いてから、課題をこなしていく感じです。
入学前に、RubyやらJavaの参考書を一周してみたり、ドットインストールでC言語の動画を見たりしていたので、
授業にはついていけています。
ただ授業だけだと完全に足りなさそうなので自学を頑張ってます。
分野ごとに授業があります。教科書を読んで先生が板書・たまに問題集やプリントを生徒にやらせるといったスタイルです。
ただ試験対策なので、問題演習を重視した方が良いと思いました。
授業を聴きながら（たまに当てられるので）、ひたすら過去問をやっています。
ちなみに学校は１２月の修了試験（合格すると本試験の午前問題免除）→来年4月の本試験 を前提にカリキュラムを組んでいますが、
私は年も食っているし、合格が就職活動に間に合わないので、来月受験します。
就職指導の先生は応用情報技術者も取っておけ、と言われましたが、必要ですかね...?
勿論取らないに越したことはありませんが、Railsチュートリアルとか他の技術書に時間をさいたほうがいいかな、と思いました。
○アルゴリズム（前期のみ）
フローチャートや疑似言語を使って、バブルソートや基本選択法など初歩的なアルゴリズムの勉強です。
実際のプログラムのコードの方がわかりやすい気がしますが、基本情報技術者試験対策なので仕方ないですね。
今も現場ではフローチャートや疑似言語は使われているのですかね？
そんなの古い現場でしか使ってないよ、という意見はよく聞きますが...
先生の意向でなぜかメモ帳推奨。(他のエディタを使っていたら嫌な顔をされた）
素人がいうのも何ですけど、ミスに気づきにくいし、使いづらくないですかね...
案の定何でもないところでハマる人がいて、授業はよく止まってしまいます。
ブラウザの開発者ツールの使い方を隣の子に教えてあげたら、喜んで使ってくれていましたが、
やっぱり変なもん教えるなという目を先生から向けられちゃいました...
○データベース実習（後期〜）
Accessを使った授業です。テキスト通りにやっていきます。
Accessは初めて使いましたが、Mysqlをちょこっと触ったことがあるので、要領はなんとなく掴めました。
これも授業は遅いので、先に教科書の内容は家で一通りやってしまいました。
グループワークとかやめてください死んでしまいます、と思ったけど、意外と楽しめました。
ただ、喋らない人たちしか居ないグループだと、何を話しかけても反応が薄かったので、ちょっと辛かったです。
・授業で使うPCはメモリ4GBでもうちょっと欲しいなあと思いました。
エディタはAtomをUSBに入れて使っていましたが、カクカクでよくフリーズしました...
モニタも19インチの正方形で、ウィンドウをたくさん出したい時は不便ですね。
どんな職場に行ってもどんな環境でも何とかやれ、という訓練ということなんでしょうかね。
１年生後半にRubyの基礎、インターンシップ（強制）、就職活動の開始
２年生からは、Java,Rails,サーバ構築, データベース構築あたりの授業、という流れで進んでいきます。
年齢が20後半になるので、周りの若い人たちと何かしら差をつけないといけないので大変ですが、
地元企業のSE(Web系を希望しています）で採ってもらえるよう頑張ります。
アドバイスがありましたら、いただけると嬉しいです。
拙い感想文にいろいろと反応いただきありがとうございます。
ごもっともです。私は皆様の雇用保険から学校に通わさせていただいているので、文句言う立場じゃないですね...
ただ、年100万近く払っている一般生徒の方は、不満に思っているかもしれませんね。
＞＞田舎で数年間無職してるけどIT系の就職訓練無くて最悪 羨ましい 田舎はゴミ
そうですか... 私の住んでいるところも地方都市ではない田舎なのですが、
近隣にIT企業が進出してきていることもあってか、今年からIT系が訓練の対象となりました。
都市部ではない地域も、もっとIT系の訓練が拡充されると良いですね。
＞＞otihateten3510 基本情報さえ取ればどっかに潜り込めるだろうから、そこで3年くらい真面目にやれば結構いけるとおもう。
＞＞コード書けると良い。／授業はまあそんなもんだよね。現役の人に聞いたほうが正しい。／東京のほうがイージー
ちょっと精神的に病んで前の仕事をやめてしまったので、家族のサポートを得て、地元に就職しようという情けない有様でございます。
なんか書いといたほうがいいような気がしたので書いておく。
なんてところもあれば、中身はARMでLinuxですみたいなところもあるし、その中間でRTOS使ってます。ということもある。
ただ、歴史的経緯として、マイコン制御などと呼ばれていたような時代から組込みソフトウェア開発がはじまって、
時代をくだるにつれて最終製品の機能が高機能化、複雑化するにしたがってソフトウェア開発の規模も比例的に、
あるいは指数関数的に拡大しているわけで、NonOSでアセンブラやCで書くという仕事は相対的に減っている。
(なんせ、ある程度高価格、高付加価値な製品を作らなければ国内メーカーは潰れるしかない)
なので、一番規模が小さいところの仕事はなくなりはしないし、働いている人は食いっぱぐれないとは思うけど、
わざわざ新たに飛び込むのは正直オススメしない。
で、問題は規模の大きい方で、当時マイコン制御をやっていたようなベテランやそれに薫陶を受けた開発者が
「勉強」をせずにこちらの方にコンバートするとどうなるかという話だ。
コンパイラはC++11,C++14であるにもかかわらず、Cもどきのコードを書くし、プロセスは巨大だし、
強烈に古臭いアーキテクチャを擬似的にOS上に構築してしまう。
その結果出現するのは、ひたすら肥大化しアンタッチャブルになったコードと原因不明のバグである。
IoTがどうのこうのなんて言っていても、組み込みが専門じゃない人がラズパイとセンサー買ってきて
一日半あればできるようなことを、ああだこうだやっているようじゃやっぱり生き残る道はないんじゃないかなー。
おいでよ組み込み系ワールドへ。プライベートで一切勉強しなくてもそこそこの収入とよその会社からスカウト殺到のエンジニアライフがあなたを待っている
(ソースコードの最新は共有サーバのこのフォルダなんて運用だったり、コンパイラの都合でwindows XPを使ってたり)
年次で昇級するってのは人によってはデメリットに感じると思う
今回おすすめしてるのは「プライベートで勉強しなくても周りと大して差がつかない」という理由なので実力者はそれに見合う環境を選択したほうがいいですね。
目に見える範囲の競争が緩いとこが多いので業界丸ごと外国からの黒船で駆逐されたら諦めましょうの精神。ゆるくやっていきましょう。
これは鋭い指摘で、問題を解法のパターンマッチングで処理するタイプの人は厳しいかもしれない。
時として宇宙線によるメモリエラーとか突拍子もない原因の不具合に遭遇することがあるので目の前で起きている事象を論理的に切り分けられる人でないと仕事量が爆発するかも。
たとえばC#など.NET系のリファレンスはMSDNで読むことができる。
RubyだってHaskellだってScalaだって、公式サイトにガイドぐらい置いてある。
Oracle、DB2、MySQL、PostgreSQL、SQLite、AccessなどSQLが実装されたDBMSは様々にあるが、どれを取っても仕様が違う。
皆が標準SQLに従っていてその上で適当に増設している程度ならよいが、もはや誰も標準SQLに従う気が無い。
根幹的に必要な機能があったりなかったりするから、あるDBMSで書けるようになったからと言ってSQLを覚えたとは言えない。
これと上記１とのせいで、何かググった時に特定のDBMSでしか解決法にならないものが大量に出てくる。
最近のプログラミング言語は大抵、雑に書いたってコンパイラが適当に最適化してくれる。
同じ結果を生むような二つのコードは、よほど下手くそに書かない限りは同じような実行速度になる。
SQLもオプティマイザが最適化はするが、ほぼ同じような二つのコードで速度が全く変わったりする。
そのため実行計画というオプティマイザの中間言語のようなものを読んであげて、
より速い中間言語が生成されるようSQLをチューニングし直さなければならない。
これでは何をやっているのかわからない。
有名なサイトでは、初心者が必死で書いたような可愛らしいSQLを「それでは遅すぎるんじゃ」とけちょんけちょんにけなし、
なんかシンプルなのだけれどよくわからない文法を一杯使って実行速度を高めたのを「正解」としていたりする。
しかもその文法、ググってもろくな解説が無かったり、特定のDBMSに依存してたりと使えないオチ。
上手い人はSQLを綺麗に書く。だけど、その綺麗さの基準が人によって違う。
エディタが単なるメモ帳でしかないようなDBMSも多いから、インデントの文字数さえ個々人に任される。
インデントは2文字か4文字か。SELECTで改行するかしないか。カンマは列の後ろか、前か。
いろいろなサイトに色々なことが書いてあったけれど、全部違うこと言ってた。
つまり各々綺麗に書ければいいやということであり、読むほうも宗教が違ってもまあ綺麗なら読めるから困りはしない。
何かの解決法をググるたびに違うスタイルだからどう書いていいのかわからない。
結局なんかいろいろな上手い人のスタイルをツギハギした新たなスタイルが世に誕生してしまうのだ。