「ミドルウェア」を含む日記 RSS

はてなキーワード: ミドルウェアとは

2019-04-06

anond:20190406105140

手作りエクセルシートなら各自好きに作れるからどうとでもなるかもしれないけど。

基本的には

1. OS(マイクロソフトとか)やエクセルVBA関数、その他ライブラリ対応を待って、

2. それを利用したミドルウェア屋とかOCR屋とかが対応して、

3. そのミドルウェアを利用したSIer顧客企業システム合致するかテストして

4. 顧客企業自らテストして・・・

みたいにいくつも業者テストがはさまるんじゃないの。

2019-03-27

公式なり非公式なりのフォーラム使わずに、プログラム分かりませんだのとTwitterなどで匿名で喚いた挙句

「あーこの{言語|モジュール|ライブラリ|ミドルウェア}はクソだわ」って言って終わるの

そろそろ辞めてもらっていいですかね。

 

三流以下っすよ、あなた

2019-03-25

Stadiaの開発者インタビュー その2

やっぱり途中で切れたので続きから


サービス提供を開始します。

するとシステムの準備は万端で、必要ソフトウェアの開発が必要ということでしょうか。Microsoftを見ますと、彼等はXBox OneのHWをサーバラックに積んでいるようです。あなたがたの手法とは異なりますか?

違います

するとGoogleインフラバックエンドのみでなくソフトウェアにも投資を考えていますか?

そうです。

自身の開発スタジオも考えていますか?

はい。Stadia Games and Entertainment組織を発表しました。これは我々の1stパーティスタジオです。

それが今起こっている?

はい

Google開発者に対し全てのツール支援しています。Stadia向けの開発は彼らにとって別のターゲットしか過ぎません。Visual Studioを用いる既存ツールや彼らが用いるツールの全てと共に、彼らのワークフロー統合されます。従ってStadia向けの開発はPlayStationXbox向けの開発と同じくらい簡単です。

我々はUnrealサポートします。UnityがStadiaサポートします。予想される多種多用な業界標準ツールミドルウェアが準備されます

意地悪な質問します。Googleコントロールを超えたものがありますよね。特にユーザサイド、クライアントサイドのインフラ家庭内安価ルータです。このような問題をどのように解決しますか?

とても良い質問です。我々はユーザに対し彼等のインフラの中で何が起こっているかをできる限り理解できるよう支援する必要があります。また我々はゲーマーに対し最適な体験を得られるようなチューニングを行うことが可能情報に対し投資を行うだけでなく、我々自身技術を用いて最良のパフォーマンスを実現するつもりです。Google技術の多くがインターネット網の基盤であることを思い出して下さい。我々はDCから情報がどのようにユーザに届くかを良く理解しております。できる限りの最適化を行うつもりです。

デベロッパパブリッシャは既存ゲームをStadia移植できるのですね。しかし同時にGoogleは新しい選択肢も数多く提供できると

その通りです。それこそが我々のプラットフォーム根本的な差別化ポイントです。既存ゲームカタログを持つデベロッパにとってStadia簡単で親しみ易いものです。我々はできる限り摩擦なくゲーム移植を行えるようにします。なぜならゲーマーは好きなゲームを遊びたいですし、彼らの愛するキャラクターストーリー世界を楽しみたいのです。しかし我々はまた開発者未来を描く新しいキャンバスをも提供します。ゲームを高速に配布し、プレーヤーと新しい手段で、特にYoutubeにて繋げます。そして開発者が持つアイデアを実現するための前例の無い技術提供します。


これまでのクラウドシステムクライアントサイドの限界基本的に画質やレイテンシに起こりました。明らかにこれらの問題インパクトはここ数年で新たにより良い技術を得ることとインフラ改善されることで緩和されてきました。しかローカル品質ストリーミング品質との間には今でも根本的なギャップ存在します。私はidソフトウェアZenimax特許を見たのですが彼らはh.264のモーションベクター効果的に用いてクライアントサイドのある程度の予測を立てレイテンシの知覚を減らしていました。Project Streamにも測定可能レイテンシ存在します。ギャップを閉じるために何をしていますか? これらの問題解決されたでしょうか。それとも少なくとも緩和はされましたか

解決されたと同時に緩和されています。まずデータセンターに対しより多くの人々がより良い経験を得られるようにするための投資が行われました。また圧縮アルゴリズムについては我々に抜本的な先進性が存在します。Google圧縮アルゴリズム標準仕様先駆者でありこの点がストリーミングの将来をより確実にします。残念なことですがGoogleでも制御できない点が光の速さです。そのためこの点が常に要因となりますしかし常に理解しなければならないこととして、我々は常にエッジ(終端)にもインフラを構築していることが挙げられますGoogleの中心にある巨大なデータセンタだけではありません。我々はできる限りエンドユーザの側にインフラを構築しています。それによって歴史上の幾つかの問題回避することが可能です。さらにまだ率直な、あまり洗練されていないProject Streamのストリーマーでも信じられない結果を出していますさらに我々はサービスリリース時に1080p60を超える品質を実現できるだけの根本的な改善を行いました。我々は8Kに至るでしょう。

それは素晴しい。それらの改善は全て圧縮に関連するものですか?

圧縮ネットワークです。我々はGoogleインフラに投入した数々の改善点に依っています。BBR、QUIC、WebRTCを基盤としてその上に構築がなされました。だからIPパケットの低レイテンシでの配信だけでなく、送信元へのフィードバックも行うことが可能です。ですのであなたが仰るZenimax使用した技術なら、彼らはここでも利用することが可能です。彼らは彼らのゲーム最適化を行うことができるでしょう。我々はフレーム毎のレイテンシ予測可能で彼らにそれに合わせて調整を行わせることができます


入力を受け取って、ゲームロジックを処理して描画を行うと、60Hzのゲームでは50ms程になります。続いてエンコード転送デコード、表示を行うとストリームではPC上のゲームに比べさらに60ms程かかります。これを改善することはできますか?

我々は改善を続けますStream最初バージョンです。我々は性能向上のために調査を行っており、レイテンシ適応していきますリリース時にはより良くなっているでしょう。

クラウドシステム接続可能性に従って成否が決まります。例えばRed Dead Redemption 2を数万、数十万、場合によっては数百万のプレーヤーオンラインにて同時に立ち上げるとします。システムの成否はアクセスによります。もしゲームプレイできないなら重大な障害となります

かにそのとおりです。そしてそれこそがGoogleが何年もかけて開発してきたスキルであり、抜本的なスケールする能力です。我々がどうやって実現しているのか、何をしてきたかについては今日は詳細にはお話しません。しかGMailMapYoutubeが同時に利用可能であるためと同じ基本的技術のいくつかが我々が依るものです。


我々は現在、現行世代が終了する移行の時を迎えています。これまではコンソールベースラインを定めてきました。Stadia次世代XboxPlayStationに対抗できると考えますか?

我々は競合他社が何をしているかは存じておりません。

でもGoogleには良い予測を立てられる優れた人々がいますよね?

我々の第一世代システムに導入されるGPU10Tflops以上の性能があり、さらスケールアップしま

GPUユーザ間で共有されますか? それとも1人のユーザが独占しますか?

単一インスタンスです。

NVIDIAGPUですか?

AMDです。

カスタムGPUだと思います

カスタムGPUです。

Google要件のために作られた訳ですね。他にも公開できる情報はありますか? Vegaですか? それともNavi、もしくはさら新世代ですか?

情報を公開したくない訳ではないのですが、このプラットフォーム進化することのほうがより重要です。そしてこの進化ユーザ開発者の双方に対しシームレスに行われることを確認して頂きたいのです。そして進化は常に継続し、誰もが常に最新で最高の物を手に入れます

クラウド確約する点ですね。ユーザはHWをアップグレードする必要がないと。

開発者にもこのように考えて欲しいのです。もちろん完全には抽象化されていません。特にゲーム開発者にとっては。しかし我々はそれでもこのプラットフォームが常に進化していると考えて欲しいのです。速さや容量、リソースには制限されていないのだと。

AMDGPUを使うことでStadiaと他のコンソールの間に共通な点ができました。開発者にとって利益となるでしょうか?

シェーダコンパイラツールをいくつか開発しました。これらは開発を楽にするでしょう。しか現在GPUはとても優れており開発者が既にVulkanに親しんでいれば、例えばid Softwareさんは既に全てVulkanに移行していますが、そのような開発者の方々には既存ゲームをStadia移植するのはとても簡単です。Doom Eternal4K、60フレームで動いでいるのは既にご覧になったと思います。非常に素晴しい状態です。これこそが我々にとって重要証明ポイントです。FPSグラフィックプレイアビリティの双方で要求が高いゲームです。 従ってこれは我々のプラットフォームの強力な証拠であり、idさんにも講演して頂きます

CPUについては何か公開できる話はありますか?

x86で2.7GHzで動作しています開発者にとり慣れのあるものです。開発全体を通して、CPUは制約となる要因ではありません。我々は全てのタイトル動作するに十分なCPU提供します。

コア数、スレッド数は?

沢山です。

8コア、16スレッド? それより多い? 少い?

公開できない情報です。ハイパースレッド使用しています

しかサーバ級のCPUです。Stadiaはこれまでのコンソールと違いパッケージングに制約を受けません。熱対策問題も異なりますコンソールとはサイズパッケージング動機が異なりますデータセンタの中でそれはとても汚なく見えるかもしれません。一方でとても帯域幅が高いメモリ使用可能で、とても高速なペタバイト級のローカルストレージ使用可能です。ご家庭のコンシューマデバイスよりも数百倍は速い物です。

するとそれが開発者が全く異なる体験のために利用可能な要因となる訳ですね。得られる機会はとても大きいことでしょう。しかし我々はマルチプラットフォーム時代生活していますGoogle先進的な機能は1stパーティのみが利用できるものですか?

パートナーには彼らが話せる時点で彼らの計画を教えてくれるよう伝えています。Stadiaをこの世界で最も偉大なゲーム開発者達に説明することにはとても興奮します。Stadiaは、開発コードではYetiと呼ばれていましたが、Stadiaビジョン説明すると、開発者リアクションは「これは私が期待したもののものだ。これはまさに我々の次のゲームのためのビジョンのものだ。elastic computingの考え、次世代レベルマルチプレーヤー環境ゲームを観ることと遊ぶことの境をあやふやにし1つの体験にすること」と話されます

イノベーションの1つの領域として、最初のほうで述べましたが、マルチプレーヤー環境において、単純にパケット複数プレーヤーリダイレクすることから原子時計レベルでのコンシステンシーを全ての状態遷移において定期的にクライアント間で更新する真のシミュレーションへの移行が挙げられます。これにより開発者はこれまでには不可能だった分散された物理シミュレーションを得ることができます。これだけでもゲーム設計イノベーションに対し大きく寄与します。このため多くの開発者が、大袈裟でなしに、実際にとても感動的なリアクションを我々のプレゼンに対して返して下さっています


多くの問題解決し、規準を上げる可能性がある訳ですね。

これこそがゲーム業界の素晴しい点です。技術が常に創造性を刺激し、ゲームに対しより大きな聴衆を作り、そのことがプレーヤー開発者に対しより大きな機会を作ってきました。エコシステム進化し、正の方向に回り続けるなら、それはゲームを遊ぶことにとって良いことです。

あなたは先程、スケーラビティとStadiaがどのようにしてより多くのリソースを立ち上げ増大する要求対応するかについて話して下さいました。しかし、同時に10TflopsのGPUサーバクラスCPU存在するとも仰いました。リソース拡張をどのように行うのですか?

3台のGPSが一緒に実行されるデモを行っています。私は上限が無いとは申しません。しかし我々は技術上の限界を上げています。そしてStadiaは静的なプラットフォームではありません。このプラットフォームは5年や6年の間、レベルが変わらない訳ではありません。開発者プレーヤー要求に従い、成長し、進化するプラットフォームです。なぜならStadiaデータセンタの中に構築されています進化させるのは我々にとって簡単なことです。

ここまで第一世代について多くのことを教えて頂きました。すると第二世代やその後の世代もあるでしょう。現状でもスケールアップできるわけですが、3台のGPU連携次世代でも可能ですか?

CPU/GPU/メモリ帯域幅の変更にはいくつかの自然な段階があります。これは家庭の物理な小売の端末よりももっとスムースでより継続的な進化です。しかし、より重要なことは基盤データセンタ網とそれに含まれネットワーク技術への投資です。この2つが一致して行われることが重要でどちらか1つではダメなのです。

先程、エッジ上のインフラについて触れられましたが、例えばNetflixISPキャッシュインストールしている状況があると思います。これがGoogleが行っていることですか? それとも既にYoutubeで行われていますか?

それは我々も既に行っていますGoogleが既に20年以上、行っていることです。我々が依って立つまた別の巨人の肩です。


Project Streamではユーザに対し最低で25Mbpsの帯域幅要件しました。これはストリーミングのみのためですか? それとも他のユーザが同時に同じインスタンス接続する場合を含みますか?

我々はStreamさらに強化させています。従ってユーザはこの制約が全体のスタックに対する改善最適化、また特に時間によって緩和されることを期待するでしょう。我々はその期待の上を行きます

4K60には相当の帯域幅がいるのでしょうね?

4K60はもちろんより要求が高くなります

1080p60は低くなる・・・

私は具体的な数値についてはコメントしません。しかし当然低くなります

インターネット接続環境はStadiaリリースする市場では全体的に上昇機運が見られます。つまりこのパフォーマンス特性ますます多くのユーザが利用可能になります

さらに繰り返しになりますが、BBRを初めとする我々の技術がありますさらに覚えておいて頂きたいのは我々のネットワークに対する理解そのままではありません。それらもまた時と共に改善されていきますYoutubeマクロ

Stadiaの開発者インタビュー

Eurogamerにより独占配信されたStadia開発者二人に対するインタビュー記事

https://www.eurogamer.net/articles/digitalfoundry-2019-google-stadia-phil-harrison-majd-bakar-interview

やっつけなので可能なら原文を読むことをお勧めします。

---

なぜ今なのでしょうか?

タイミング問題です。20年間の蓄積によりGoogleにはデータセンタ内のパフォーマンスに優位性が存在します。Googleデータセンタ内ではHWメーカーです。我々はデータセンタ内で何年もの間、高い性能で端末間を接続する基盤を構築してきました。Youtubeでの経験からプレーヤーサイドの観点からだけでなくデータセンタ内部から技術観点から技術統合を行ってきました。他社でもその視点存在していますGoogleにはその点に固有のアドバンテージ存在します。

これまでの箱をTVの下に置いておいたパラダイムに比べ、無限演算リソースによる可能性が現れます。これまで存在しなかったことをできる可能性があります

その通りです。我々にはレガシーがありません。全てが21世紀のために設計されています開発者制限の無い計算資源が利用でき、何よりもマルチプレーヤーサポートできます。これまでのマルチプレーヤー環境は一番遅い通信に影響を受け開発者は最も遅い接続に対し最適化必要でした。我々のプラットフォームではクライアントサーバも同じアーキテクチャの下にあります。これまではクライアントサーバの間のping支配されていましたが我々の環境なら最速でマイクロ秒で済みます。だからプレーヤーの数は単一インスタンスにて動的にスケールアップが可能です。バトルロイヤルなら数百から数千、数万のプレーヤーが集まることも可能です。それが実際に楽しいかどうかは置いておくとしても、新聞ヘッドラインを飾ることが可能技術です。

クライアントサーバの双方でこの利益を得られるのでしょうか

両方です。

すると開発者に対しStadiaホリデーシーズンにぴったりの最高の製品だと言えると。理に適った範囲無限計算資源が得られると。

ユーザが我々のプライベートLANからはみ出さないだけでもその効果は大きいものです。Googleは45万kmに及ぶ光ケーブルにより世界中データセンタ間を接続しています米国西海岸から東海岸まででも20ms、フランクフルトからマドリッドでも20ms。これにより開発者は最も極端な場合においてもレイテンシ予測可能でそれに従い設計を行うことができます


Youtbeとの統合について教えて下さい。

StadiaYoutube技術と深く結びついていますが、実際には一歩引いています今日ゲーム業界を考えてみて下さい。2つの世界共存しています。1つはゲームプレイする人々で、もう1つはゲームを見る人達です。2億人の人々がYoutubeゲーム毎日見ています2018年には述べで500億時間ゲームを視聴するのに費されています時間人口の双方で信じられない程の視聴が存在します。我々のビジョンはこの2つの世界を1つにすることでゲームを見ることができ、かつ、プレイもできる、双方向に楽しめることです。

まり重要なのはゲームシステムでもなくコンソールでもありません。噂とは異なり我々はコンソールビジネスには参入しません。我々のプラットフォームの要点はコンソールでは無いことで、皆が集まる場所を作ることです。我々は箱でなく場所を作る。今までと異なる体験を得られる場所です。ゲームを見るなり、遊ぶなり、参加する場所であり、かつユーザが楽しむ場所であり、ユーザ他人を楽しませる場所です。

から我々のブランドはStadiaといいます。これはスタジアム複数形です。スタジアムスポーツを行う場所ですが同時に誰もがエンターテイメントを楽しむ場所でもあります。だから我々はそれをブランドにしたかったのです。皆が遊んで、観て、参加して、さらにはゲームをする場所。一歩下がって見ることもできる場所。常にどのボタンを押したか意識しないでも良い場所。他のアーキテクチャでは実現できない場所です。

まりリアルタイムシミュレーションゲームで全ての駒が人々であるようなものですか?

その通りです。そして単純に技術的に深い点を求めて、我々は第一世代でも4K60fpsHDRサラウンドサポートしました。さら開発者必要インフラに従ってスケールします。それだけでなく、同時にYoutubeに常に4K60fpsHDR画像送信することが可能です。だからあなたゲーム体験の思い出は常に最高の状態になります

Googleは全てを記録するでしょうか?

プレーヤー次第です。Googleは全てを記録はしません。もしプレーヤーが望むならGoogle4Kストリームしま

共有が友達だけか、世界中に公開かも自由選択可能です。Googleユーザ制御を明け渡します。もしユーザYoutubeで公開すれば誰でもリンククリックすることでそのゲームを遊ぶことができます

するとユーザshareするだけで誰でもがその特定ゲームに参加することができる訳ですね。

そう。そしてこれはマルチプレーヤーゲームロビーの新しい形となりますYoutubeクリエイターなら誰でもがファンチャンネルのsubscriberを自分ゲームへと誘うことができます生主として、Youtubeクリエイターとして私は視聴者を私のゲームに瞬間的に招待できます。それが私と10人の友達でも、(訳注: セレブの)Matpatと彼の数百万の購読者でも、技術は同じです。

アカウントシステムベースYoutubeですか?

Googleアカウントの一部です。従ってGMailアカウントがStadiaへのログインに利用できます。他の基盤についても説明させて下さい。最初サービス立ち上げから全ての画面への対応を行いますTVPCラップトップタブレット携帯です。我々のプラットフォームの基本は画面に依存しないことです。これまで40年間、ゲーム開発は端末依存でした。開発者として私は制約の範囲内で、私の創造性を開発対象の端末に合わせてスケールダウンする必要がありました。

我々はStadiaでそれを逆にしたいのです。我々は開発者に対し彼らの考えをスケールさせ、どの端末の縛りから解放したいのです。パフォーマンスに優れ、リンククリックすればゲームは5秒以内に開始されますダウンロードもなく、パッチもなく、インストール必要なく、アップデートもありません。多くの場合、専用のHWも必要がありません。従って古いラップトップChromeブラウザ使用する場合にでも皆さんが既に持っているだろうHID仕様に準ずるUSBコントローラ動作します。そして、もちろん、我々自身コントローラも開発中です。

なぜ独自コントローラを作るのですか? USBコントローラはどこにでもあるじゃないですか

コントローラ自作する理由はいくつかあります。1つはTVへの接続です。我々はChromecastをストリーミング技術採用します。Stadiaコントローラの最も優れた機能の1つはそれがWiFi接続DC内のゲームに直接接続することです。ローカルデバイスとは接続しません。

それは面白い。するとほとんどそれ自体が端末な訳ですね。

その通りです。これこそが我々のブランドの実現であり、具現化です。そして独自コントローラにより最高のパフォーマンスが実現します。ゲームに直接接続するためにプレーヤーは画面を移動することが可能です。プレーヤーはどの画面でも自由に遊び、停止し、他の画面でゲームに復帰することが可能です。

そしてコントローラには2つの追加されたボタンがあります。1つはGoogle Assistantの技術マイクを用いますユーザ選択により、ユーザプラットフォームゲームの双方に対し、自然言語を用いて会話が可能です。例えば「Hey, Google。MadjとPatrickと一緒にGame Xをやりたいな」と言えばStadiaマルチプレーヤーゲーム指定した友人と共に直ぐに開始します。

するとGoogle伝統的なUI回避するのですね?

我々はゲーマー可能な限り素早くゲームに辿り着かせるよう考えています。数多くの研究を行いましたが、多くのゲーマーゲームを起動したら直ぐに友人とゲームを開始したいと考えていますゲーマーUI時間を費したくは無いのです。

誰かが言ったことですが、現在コンソールは起動した時にまるで仕事のように感じると言うのです。ゲーム自体更新や、ゲーム更新があります。我々はそれらを完全に取り除きたいと考えています。もう1つのボタンは、ちょっと趣が異なるのですが、Youtubeシェアできます

端末は何でも良いのですね? スマホスマートTVも?

Youtubeが観られるならどこでもStadiaは動きます

TVへの接続にはChromecastが使用されると。では実際にはどのように動きますか?Chromecastがスマホラップトップからストリーミングを受け取るのでしょうか?

Chromecastはスマホからストリームを受取はしません。Chromecastはスマホから命令のみ受けます画像NetflixYoutubeから直接受け取ります。Stadia場合、StadiaコントローラからChromecastへとこのゲームインスタンスへと接続せよと命令がなされ、Chromecastはゲームインスタンスから動画ストリームを受け取りますクライアントはとてもシンプルです。行うのはネットワーク接続ビデオと音声のデコードのみです。Chromecastは入力を処理しません。全て入力コントローラが扱いますビデオと音声とネットワーク接続Chromecastの基本動作で全て既に組込まれています

Stadiaの起動はどうするのですか? コントローラで?

そうです。とても良く出来ていますWiFiに繋ぐだけです。コントローラにはWiFiIDとPWを入れるだけです。それだけです。ホームボタンを押すと勝手Chromecastを探し直ぐにChromecast上でクライアントを起動します。UIが表示され直ぐにゲームを遊ぶことができますデジタルパッドでUI操作することも可能です。これが重い処理を全てクラウドへと移行する点の美しさです。Chromecastのような低消費電力の端末で説得力のある体験ができますChromecastは5W位下です。Micro-USBで給電可能です。典型的コンソール100から150Wもします。またこれまで説明しませんでしたが、例えスマホでも行うことは動画再生だけです。従ってAssassin's CreedDoomや他の重いゲームあなたスマホの上でモバイルゲームよりも低消費電力で動作します。だからスマホ10時間でも遊べます

スマートTVではStadiaYoutubeクライアントに組込まれるのでしょうか。それともStadia独立して起動させますか?

今の所、我々はChromecastのみに集中しています。でも技術的、機能的な観点からYoutubeがある場所ならどこでも動きます。我々はまだStadiaをどのようにユーザに届けるかは検討中です。

コントローラに話が戻りますが、モバイル端末にはやはり物理的なアタッチメント必要に思われます。例えばスマホコントローラ接続するような。MicrosoftのXCloudを見ていると操作には実際に問題があるようです。

Googleには解決手段があります

そうでしょう。スマホコントローラ取り付け以外にも、明らかな解決手段としてSwitchのようなクライアント端末を作るのでしょうか?

サービス開始時から提供されるサードパーティによる解決手段サポートしています。他にもアイデアがありますしかし今は話せません。

なるほど。GoogleUbisoftデモを行いましたが、これまでにDoom 2016でもデモを行いました。他にも開発企業はありますか?

良い質問です。私がこのプロジェクトに参加する前からチームは既に何社かと提携しここ何年かの間に技術提供していました。StadiaLinuxベースです。グラフィックAPIはVulkanです。開発企業クラウドインスタンス作成しますので、開発キットも今ではクラウドにありますしかクラウドだけでなく、開発社のプライベートDCでも、机上のPCでも可能です。

すると開発者物理的なHWを持つことが可能ですか?

もしそうしたいなら。でも我々は今後のトレンドが開発でも配布でもますますクラウドへと移行していくと考えています。従って今後数年で開発者にとってクラウド中心、クラウドネイティブゲーム開発での標準となるでしょう。

どの企業自身クラウドシステムを開発しているように見えます。例えばOriginクラウドがあるでしょう。しか必要とされるインフラ要件は、我々がここで話しているような内容を達成するには、3rdパーティには荷が重いように思えます。彼らは自身クラウド継続しながら、Googleシステムを導入するでしょうか。

デベロッパーパブリッシャーはとても賢くクラウドネイティブとなる新しいゲーム体験を達成するために必要ツール技術について考えていると思いますしかしそれは世界中で何千ものアクセスポイントを持つデータセンターを運営することや、それらの運営必要な莫大な投資資本とは異なるものです。Googleは今年単年でも$13Bの資本を投下しています

それはとても巨額ですね。しかしそれでも依然としてシステムを構築しインストールするのは根本的な問題です。多分野に渡る段階的なロールアウトになるのでしょうか?

米国では全ての必要場所に展開が終わっています。Project Stream試験必要環境2018年末には整いました。我々はGoogle社内で、Google社員対象2017年の始めから2年間の間、プライベートテストを行ってきました。2019年には米、加、西欧、英にて このエントリーをはてなブックマークに追加ツイートシェア

2019-03-10

量子コンピュータエンジニア始めて5年が経った」を読んで

https://qiita.com/YuichiroMinato/items/7192a15505d15409e904

Googleが早くから問い合わせており、海外リサーチ能力は高い

アメリカのように量子コンピュータ用のミドルウェアを開発する起業が出てきているわけでもない状態で、

名前も聞いたことがない日本企業に対して、多くのコメントがあるのは、

Googleが問い合わせている」という点がある。


これが富士通NECNTTという名前が出てきたら吐き捨てられていたと思われる。


もう一つ、海外企業リサーチ能力がすごく、資金がどこから出ているのか、把握している。

異能vationはあまり注目されていない

日本企業技術判断する際に、純粋技術評価されなくなっているのではないか


人脈が大事

大学先生などの人脈がスタートアップでは大事

地方大学ハブとなるのはおそらく紹介できるかとかなのだろうが。

2018-10-29

オンボードメモリマウスって便利だけど一度なんかのソフトと相性が悪かったりして不具合でると泥沼になってクソだな

ミドルウェア削除しただけじゃ元通りにならんし

2018-09-19

とある会社機械学習環境を整備しているんだが心が折れそうだ

昨今流行りの機械学習プロジェクトがぽこぽこ立ち上がっている状況なのだが、一部の人を除き、apt-getで躓いているのは会社にとって損失だと考え、オンプレクラウドのようなものを構築することにした。

グループ全体の規模はそこそこ大きいが、将来単なるアッセブリー屋になることが目に見えている事もあり(今後20年以内には喰われてしまうという憶測もあり)ネットワークLinuxコンテナプログラミングが出来る自分が社内の機械学習、引いてはITインフラ民主化、なんだったら外販できるくらいのもの作ってやろうと鼻息巻いて無理やり一人プロジェクトを興すことにした。

まずは既存DHCPサーバ名前解決ができないDNSサーバからゲートウェイPCを用いてネットワーク的に分離、社内の物理的な設置スペースの問題デスクトップPCサーバPCが離れた所にあるため、WireGuardでVPN構築、ゲートウェイPCはそれぞれKea DHCPサーバ、PowerDNSサーバを稼働させ、OpenStack導入検討時に悩んだ鶏が先か卵か先か問題解決することにした。

上述の通り、システム構築にあたってOpenStackやMAAS,RancherOSなどを検討したが、社内のニーズを「100%」汲みとった上で、次世代オンプレクラウド個人的にはエッジクラスタがゆるく繋がるアメーバクラウド?のような呼称があっている気がするが)を構築するにはどれも痛し痒しで何かしら制限がついて回るのは許容できなかった。これは今後5年、特に海外事業所の開発者の事を考えた時には外せない要件だった。

とはいえmiekg/dnsを用いてCoreDNS進化版を作るにはリソースが足りず、BINDを用いるにはSA対応がしんどすぎるため、APIを備えており、今後も進化が見込めるであろうOSS、また必要であれば商用製品保守サービスが受けられる事から上記2つを選択した。

PowerDNSはさておき、ISC KeaはナウでYANGなLinux YANGに対応しようとしているなど(言いたかっただけ)、世の中のオンプレ環境を塗り替えるためには兎にも角にもAPIゲートウェイ重要だと考えたため、双方が提供しているAPIをうまく吸収するミドルウェア(とちょっとしたAPIサーバ)をGo言語作成した。

次に世の中のパブリッククラウドOpenStackなどを触ったことのある開発者はCloud-initに慣れているはずという前提の元、対応コスト勘案の結果、NoCloudで対応しつつ、上記APIサーバ連携し、ベアメタルマシン管理した事のある人はわかる、ベアメタルマシン特有の諸問題解決することにした。

まぁなんだかんだ大企業なのでお金解決する手段もあるが、そもそも高集積ラック搭載GPUサーバ購入の稟議が通るような会社だったら既にKubernetes導入しているだろうし、俺もこんなことしてない。

脱線したが、上記以外にも検証バックアッププランとしてAnsible記述などの作業はありつつも、3ヶ月かけてようやく基礎となるインフラ基盤が構築できたため、nuxt.js+go簡単フロントエンドサーバを構築し、一人情シス様相を呈している部下のリソース開放、Calico対応+Kubernetes導入、不安がっている上席が安心できるように、分かりやすい餅を用意しようとしている、というのが現状。

ここまで寝る時間も惜しんでトップスピードを維持したまま頑張ってきたものの、少し限界を感じている。

特にオンプレクラウド部外者が中々見えてこないものがあり、なんならその見えないもの限界まで吸収できるように、かつ現実的に実現可能ギリギリラインを狙っているのだが、そもそも周りに相談しようとしても何を言っているのか解説する所から始めないといけない。

覚悟はしていたが、ふとした時にとてつもない脱力感に襲われてしまう。

世の中を切り開いてきた諸氏はおそらく一度はぶつかったであろう、この内なる自分の壁をどのように突破してきたのだろうか?

ひたすら孤独との戦いだというのは頭では理解しているものの、突発的にくるこの脱力はいかんともしがたい。

推敲もせずに大変失礼極まるが、コメントをいただければ幸いである。

2018-09-08

anond:20180908155359

iOSiPhoneOSだと思うけど。

増田が言っているドコモガラパゴス化の要因として指しているのはMOAPの事なのではないかなぁ。

あれはOSではなくてミドルウェアで、OSSymbianだった気がする。

2018-08-31

anond:20180831152349

ハードウェアってCPUとかグラボとかメモリの数値の事言ってるでしょ。

OSミドルウェアは同じなんて到底言えないよ。

2018-08-15

サマータイムB2B通信。あと費用負担の話

以前、短期間だけど、B2B通信ミドルウェアメーカーにいた。B2B通信っていうのは企業間でのデータのやりとりのこと。

あなたが近所のスーパードラッグストアで買い物をしているとする。お店は品物を仕入れるため、B2B通信で「冷えピタ20ケース売ってください」というデータを送り、受け取った卸売業者は「受注しましたよ」というデータを返す。卸売業者はさらに、メーカーに対して発注データを送り、メーカー卸売業者に受注しましたよというデータを返す。

あるいは、あなたAmazonで買い物をしたとする。Amazonクレジットカード会社請求データを送り、クレジットカード会社は成否をAmazonに返す。

あるいは、あなたが使っているA銀行の口座から、別のB銀行の口座に振込をしたとする。当然、銀行間でやり取りが行われる。

こういうデータのやり取りが、毎日恐ろしい件数で行われている。サマータイムが導入されるとしたら、B2B通信にも影響がある。ちょっと考えただけでも、

サマータイム導入が決まった場合、そういった問題が起きないように対応しなければいけないわけだけど、

限られた予算の枠内でサマータイム導入にコストを取られるということは、それ以外の施策は後回しになる。停滞のもとだ。

対応方法企業によってばらけそうなところも問題だ。B2B通信しているすべての企業が揃って完璧対応をできれば問題ない。でも、場合によっては、「うちはIT予算に余裕がないので、サマータイムの切り替わりタイミングサーバ時計を2時間ずらすだけにします」みたいなところも出てくるだろう。そうすると、「時刻は確かに2時間ずらされているけど、タイムゾーン指定JSTのまま」みたいなデータが送られてくることになる。メーカーユーザ企業の力関係にもよるけど、ミドルウェアでは「通信相手ごとにサマータイム対応方法が違う」という前提で複雑なプログラムを組まないといけなくなるかもしれない。

おそらく、サマータイムの開始・終了時には、夜間にも関わらず関係各社の担当者が待機させられることになるだろう。B2B通信も夜中には頻度が下がるのが確かだけど、ないわけではない。データの種類によっては「毎日1回夜中の3:00に送る」みたいなケースもある。万が一何も起きなければ安心して寝ればいいけど、何か障害が起きた場合、影響が大きくなる早朝までに対応しなければいけないので、ミドルウェアメーカー運用担当者も開発担当者も召集され、タクシーで集まって全員で対応するハメに、というのも十分ありうる。

海外との取引がある企業もあるから日本だけの話でもない。「へぇ日本でもサマータイム導入されるんだ。どれどれ、このJDTっていう1時間ずれるやつかな」なんて中途半端対応されてトラブルになるケースもあるかもしれない。

……ここまで書いてきて思ったけど、サマータイム対応問題なのは費用負担が一番大きいんじゃないだろうか。

オリンピックは、主催者や、そこから仕事をもらっている広告代理店建築業者、スポーツ用品メーカーなどが収入を得る。それ自体別にいいんだけど、そのためにサマータイムが導入されて、オリンピック関係ない企業や、そこで働く人たちが負担を求められている。娯楽はそもそも提供する側がサービスして、享受する側がお金を払うという交換をするわけだけど、サマータイム導入で反感を買っているのは、オリンピックから直接利益を受けない企業や人が、「あくまサマータイム対応コストがかかるのであって、オリンピックお金徴収わけではないか問題ない」という論理でタダ働きさせられることが大きい気がする。いわば、日本全体から金をふんだくって、オリンピック主催者関係者に集約するかたちになっている、その構図が問題なのではないか

そこで提案なんだけど、「サマータイムは導入してもいいから、対応にかかる費用東京オリンピック主催者請求できる」というかたちに持っていくのがいいのでは。

「いやいや、開始までの時間が残り少ないのが問題だよ」という意見もあると思うけど、費用請求できるなら、優先度上げてできることが色々増えるよね。単純に人を増やしたり、深夜残業代にあてることだけじゃなくて。

たぶん、開催時刻をずらすんじゃなくてサマータイム導入、という話が出たのも、「IOCとの契約時間が決まっちゃってるから変えると違約金払わされる」とかそういうことだと想像するので、サマータイム対応にかかる費用主催者負担して違約金回避できるなら、問題ないよね。……まさか対応費用が払えないほど莫大になることがわかっていて、それを全国の企業押し付けようとしているわけではないよね? もちろん、「サマータイム対応費用を都や国が補助金とか出して負担する」ではダメですよ。それだと結局、主催者が儲かるために国民全員に負担押し付けるかたちになっちゃうので。

いやぁ、いい案を思いついた。これなら全員がニッコリ、Win-Winな感じになれそうですね。よかったよかった。

2018-07-02

「好きな仕事だけど必死なんだよ」って言ってから1年半経った

最近、「『好きなことを仕事にしてる奴には勝てない』っていうけどさ」というのを(https://anond.hatelabo.jp/20180627004115) に上げたが、これは去年の正月に上げたものコピペしたものだ。(https://anond.hatelabo.jp/20170103185847)

「反応が違ったりするんだろうか」という興味本位でやったのだが、思いの外昔を振り返る良い機会になったので、現状を書いて未来につなげてみようと思う。

ちなみに、件の記事を書いたのは、「好きなことを仕事にしてる奴には勝てない」というようなことを連続で言われて気になっていたのと、http://crapp.hatenablog.com/entry/venture-the-war-front記事を読んで、気がたったからだ。

普段はそういう言葉は気にしないのだが、年末の忙しさもあって気が立っていた。

さて、1年半前と比べて、プライベートの削り方はあまり変わらない。だいたい、仕事終わりに1,2時間本を読んだり土日にプログラムを書いたりしているぐらいだ。ただ、Netflixにハマってプログラミング時間が少なくなった気がするので、そこは反省している。

技術力に関しては、だいぶ気にならなくなっている。

問題に対して以前より良い選択を取れている自信があるし、IT業界技術の方向もわかってきたので、流行していない技術にも「良い」と言えるようになってきた。

論文積極的に読める様になってきた。

特に自分の行動で状況を変えられていると実感出来るようになったのが大きい。関わっているサービスが、自分が作ったり考えたりした方法改善され、自分判断ミス悪化するのを実感するので、成果がよりわかりやすくなった。

だが、不安や焦りがあるのは変わらない。

尊敬している優秀な人たちにはまだ追いつけていないし、35までにそこまで行けるという確信もないので、まだ必死に走り続ける必要が有ると思っている。

だが、以前ほど切実ではない。

流行の伝播を見ていて、たとえ、今勉強をやめても5年ぐらいはプログラマでいられるだろうという、自信はある。

次の5年に最先端を走り続けていられるかどうかが今の関心事だ。

ただ、こういう自信はコロコロ変わるので、安心できるわけではない。

プログラミングを始めてからずっと、「俺は何でも出来る」と「俺は何も知らない」がくるくる回っているので、すぐに不安な時期が来るだろう。

さらに、井の中の蛙ではないかという恐怖もある。今の周りのレベルが低いだけで、別の場所に行くと無能になるかもしれないという恐怖だ。この現象相対的ものから、この恐怖とは死ぬまで付き合うしか無いだろう。

プログラマ的な話をすると、

以前はフルスタック志向で、フロントエンドからインフラまで技術を漁っていたが、最近サーバーサイドに収束しつつある。

フロントエンドの流れは流行ったものを後追いすれば良いやと思い捨てた。やっとGraphQLを真面目に気にし始めた程度だ。

最近の関心は、クラウドネイティブを前提としたミドルウェアとか、分散の仕組み自体だ。かなり偏ってきている。CNCFとか、kafkaとかcockroachdbとvitessの違いとかだ。分厚い本も手に入れた。ミドルウェアへの憧れは昔から合ったが、やっと作り始められる。

全体的な方向性としては、

1. 「他人に今以上の力を引き出させる」力を鍛える(リーダーシップ力という言葉が適切かはわからないが、人の心で結果が変わるというのを見てきたので、自分だけでなく周りも気になってきた)

2. 専門性の深化

3. 生き残る技術を見極める力を鍛える

4. 変化に敏感であり続け、好奇心を持ち続ける(新しい物を見ても「既存のモノのほうが良い」と考える事が増えたので、反省している)

という方向で行こうかなと思っている。

1年後に見て同じことを思っているかはわからないが、今より良い判断ができていると何より。

2018-06-24

開発環境と本番環境を一つにすれば効率的そもそもお金貰えるの?

そもそも弊社って開発環境の代金を見積もりに入れてなくて、

なんか対応が入る度に本番環境からソース落としてきてCentOSiso使ってVirtualBox仮想環境作って

yumで手順書見ながら必要ミドルウェアとか導入して、

本番環境と同じ設定でメールとか飛んだらまずいからその部分を探して修正して、

反映の際はそこだけ戻してってやってるんだけど、

これはもしかして物凄く頭が悪いのか?

2018-05-12

元号が変わることへの対応なんてミドルウェア任せにできないものかね

昭和から平成プログラムの書き換えが面倒で一気に和暦が減ったが、今時はそれくらいの自動化はできていて欲しいところ。

glibc.NET FrameworkJavaOracleあたりのメジャーどころは標準で和暦機能提供しているわけだし。

2018-04-01

anond:20180401183450

もう痛いほど分かる。

フレームワークって生産性上げるためのおまけに過ぎないのに、知ってないと話にならない基盤になってるんだよね。

それなのに色々ある上にミドルウェアとの組み合わせとかもあるしもう正直ついてけねー。フレームワークについて考えたくねー。

2018-03-11

自分自己肯定感が弱いと感じている

日頃、自分の興味のあることに関する課題発見し、それを解決するためにアプリ(小規模だけど)を開発し公開している。作ったものがたまにバズることがあって、その結果1日の広告収入が1万円を超えたこともあった。しかし、定期的に作ったアプリに対して使った技術要素やコーディング量を見返した時、これぐらいのものはxxさんなら自分より短時間かつ高クオリティで開発できるなと思うことがあるのだ。

興味があることに自分課題発見し実際に手を動かしているのですごい!みたいな話を聞いたことがあるが、理解はできても共感ができない。

常にネガティブ感情を抱いているわけでもなく、難しい箇所をうまくコーディングできた時は自分のことを天才だと感じることや、ミドルウェアを含むバックエンドからフロントエンドまで1人で開発できるようになり、昔の自分と比べて成長したと感じることはある。ただ、これらのポジティブ感情は一瞬で終わり、あっという間に上に書いたようなネガティブ感情自分支配するようになる。

レッドコーダーやKaggle Masterになるか未踏に採択されるなどのレベルに達すれば、自分を認めることが出来るような気はしているが、あいくそこまでの能力は持ち合わせていない。

https://anond.hatelabo.jp/20180311003723 を見て書きたくなった

2018-03-10

anond:20180310153423

プログラミングをやればやるほど、上には上がいることを実感する。

普通プログラマーは、誰かが作ってくれたツールCPUプログラミング言語、ミドルウェア)を使っているに過ぎない。

本当にできる奴は、自分ハードも開発できるし、プログラミング言語も作れる。それだけの勉強をしっかりやっているからこそ、基礎力がある。スティーブ・ウォズニアックとかスゴイよね?

ちょっとコードを書けるぐらいで、自分スーパーハッカーなどと自惚れない方が良い。それでは、成長が止まってしまう。

もっと上を見よう。

anond:20180310144402

実行環境の構築は、インストーラーでワンタッチポン!でできないとダメ

環境の構築が面倒くさいプログラミング言語ミドルウェアって普及しないよね?

2017-12-31

きれいなコードを書くのはやめた

きれいなコードを書け。コミットは細かく、メッセージをちゃんと書け。

そうずっと教えられてきたし努力してきた。

でも、もうきれいなコードを書くのはやめることにした。


業界2位のミドルウェアが、、1990年代タイムスリップたかのような継承拒否した継承構造で書かれていた。

世界的なOSSで3桁や4桁のスターがついているリポジトリコードは、コピペの嵐。巨大なマージコミットやFワード入りのコミットメッセージ

有名なスタートアップCTOコードは、メタプログラミング黒魔術の塊だった。

リードプログラマの同僚が、素早い機能追加で顧客から高く評価されている。

でも、それはコピペまみれで、巨大のコミットの汚いコードからできる。

自分バグのないきれいなコードを書くように心がけている。

同僚にくらべて、実装は遅い。そのことを叱責ばかりされる。


優秀なプログラマは、自分は quick and dirty なコードをかくくせに、 他人にはきれいなコード要求する。

ダブルスタンダードだ。

他人きれいなコード要求するのは、他人コードを読む時間を短くするためなのだろう。


優秀なプログラマになるために、私もきれいなコードをかくのはやめにすることにした。

2017-12-21

バグばっかりだったあのゲームの思い出

きららファンタジアというスマホゲーで何か大きな問題が起こって大騒ぎになっているというのは Twitter自分タイムラインにちらほらと出てきていたので「そうなんだー」程度の認識だったのだけれど、その炎上のまとめと考察(https://smhn.info/201712-kirara-fantasia-cheat)を読む機会があってなるほどこれは大変な問題ですね、と思った。

それで僕は、サービスインからサービス終了までをほぼ全て見守ってきたあのゲームの事を久しぶりに思い出したので懐かしい思い出としてここに書き記しておこうと思う。

そのゲーム、仮にスキマとしよう。そのスキマはスマホゲーによくある隙間の時間を埋められるようなデザインをされたゲームで、大まかにいうと冒険者を組織してダンジョンへと冒険に出かけさせ、持ち帰った財宝を使って冒険者を強化して、また冒険に出かけさせるというサイクルのゲームなのだが、冒険中はユーザ特にすることがなくただ待っているだけという、冒険者を送り出して帰ってきたのを確認するだけの作業をその隙間の時間にやってね、というゲームだった。なお、スキマは単発のゲームというよりは、はるか昔のパソコンで動いていたゲームを始祖とする名のあるタイトル(仮にウィリーとしよう)を冠したゲームで、ルネサンスと名付けられたウィリーブランド再生プロジェクトのうちの一つであった。僕はそのウィリーが好きだったのでとりあえず遊んでみようとダウンロードしたのであった。

サービスイン直後に一ヶ月メンテ

まず、スキマのサービスイン直後だが、オンラインゲーの例に漏れサービスイン直後に色々な問題を起こしてメンテにつぐメンテでまともに遊べる状態ではなかった。だいたい4,5日はメンテをしたり、たまにサービスしていたり、という感じだったのではないかと思う。そのサービスインから4,5日経ったあたりで、「このままでは安定したサービスが続けられないので長期メンテナンスに入る」といった感じのアナウンスと共に、メンテナンスに入った。このメンテナンスは一ヶ月とちょっとの間続いた。僕はサービスイン初日にはプレイできず長期メンテナンスに入る前に少し遊んだ程度だったのだが、遊んでみた所では「これは酷い」としか言いようがなかった。

まず動作もっさりとしている。何かのボタンを押すたびに CONNECTING… というダイアログが出て2秒位は待たされる。場合によってはボタンを3,4回押さないと目的の事ができないのに押すたびに CONNECTING… なのである。次にタップに反応しない。ボタンを押すと書いたが押したつもりが押されていない事がしばしばある。この場合は CONNECTING… が出ないのでわかるのかと思いきや、1秒位経ってから CONNECTING… と出てあぁ、押していたのか、とわかったりするようなもっさり具合である(もちろん押していなかった時もあるので1秒後までは押せたか押せなかったを判別できなかったりする)。

また、バグと言っていいであろう謎の動作が多い。ダンジョンに送り出したパーティダンジョン内部での行動がダンジョンログとして閲覧できるようになっており、そのダンジョンログは直前の3回までのログが観られるようになっているのだが、そのダンジョンログの表示される内容が複数が同じものになっていて実質的には3回のログはみられないであるとか、CONNECTING… が出るタイミングで他の部分をタップしてしまうと高確率アプリが落ちるであるとか、特定の順番で装備している武器を変更すると攻撃力が最低値に固定されるであるとか、リリース記念かなにかで貰えるキャラがなぜか毎日もらえて同じキャラが増えていくであるとか、まぁ色々な問題があって面食らったものである

そんな感じでサービスインを迎えたスキマなのであるが、こんなに酷い状態なのではユーザはどんな事を言っているのだろうとコミュニティを探した所、2chスレッドが立っていた。案の定スキマのバグ報告スレと化しており、「あぁ、このゲームは本当に全然駄目なんだな」とほっとしたのを覚えている。僕はその頃からその2chスレッドを眺めるようになった。また、こんな状態ではサービスが続けられないのはわかるけれど、一ヶ月程度のメンテナンスでなんとかなるものでもないだろうとも思ったので、せっかくなのでサービス終了まで看取ると面白いのではないかとも考えた。

サービス再開後も問題改善せず

一ヶ月と少し経った頃、スキマのサービスが再開された。まぁ残念ながら僕の予想は外れておらず、お世辞にもちゃんと遊べるとは言えない状態であった。とはいえ、本来は一回しか貰えないはずのキャラ複数回貰えるであるかいった所に代表されるゲームとして守られるべきルールのようなものについてのバグの多くは直っており、残っている問題の多くはクライアントアプリ側の問題サーバ側の負荷対策ができていない問題とみられ、クライアントアプリ側の問題特定操作をしなければ落ちはしないしサーバ側の問題もっさりだけれど待てば処理はしてくれるので一応遊べないことはない状態だとは言えた。それでも、クライアントアプリ側でのUI不思議動作(押してるつもりでも押せていない、連打するとクラッシュ)に誘発されたと考えられる進行不能バグ代表とする理不尽問題は沢山残っており、ユーザとしては不満が渦巻いていた。

そんなスキマではあるのだが、サービス再開の後はウィリーでは有名な人の名前を冠したイベントを行ったり、定期的に期間限定ダンジョンオープンしたりといった運営を行っていた。もちろんバグはじんわりと直ってはいくのだが、特に劇的な直り方はせず、「俺サービス開始直後からログインできなくなっててまだログインできないんだけど」みたいな事を報告するユーザ(?)も2chでは散見されるという状態で、2chスレッドは「スキマのバグを踏まないようにプレイするにはどうすれば良いのか」という情報を交換するための機能果たしていた。

開発会社の変更

一ヶ月メンテからサービス再開から3,4ヶ月経った頃、運営会社から開発会社の変更が発表された。曰く、外部の開発会社制作を依頼して制作したのだが、不都合が多すぎてどうしようもないので開発を自社に引き取るということであった。その後一ヶ月程して「不都合収束クライアント」と銘打ったクライアントが配布される。この不都合収束クライアントで確かにいくつかのバグ修正されはしたのだが、もっさりとした動作が変わるわけではなく(プロトコルサーバ側も修正されていないようであったので当然ではある)、操作によってはクライアント強制終了していたのが強制終了はしなくなった、程度の修正であり、これを解決するには根本的な改革必要であるとみてとれた。

サービス開始1周年

そんなスキマではあったが、何故かサービスは終了せず、サービス1周年の時を迎えた。この時、スキマの開発体制についての発表もあった。現在のスキマのクライアントプログラムは改修を重ねていくが、それと平行して開発ミドルウェアを変更してフルスクラッチクライアントを作り直している、という発表であった。2chスレッドではフルスクラッチクライアントを書き直すということで、バグの根治は当然として、目的の事を行うのに3〜4タップ必要であったりするというUI周りまで手がつけられるのではないか、という事を期待する声が上がったりもした。

また、この1周年挨拶の3ヶ月後には新クライアントの開発状況は70%と発表された。

この頃からであろうか、僕が遊んでいる環境のみなのか、又は他の人ではあまり現れない問題であったのか、とにかく僕が遊んでいる環境では冒険からの帰還を行おうとすると変に時間がかかるようになった。この問題は何らかの原因で帰還操作完了するまでの時間が少しづつ伸びていくという問題であった。この問題は後で僕には大きな問題として認識されるようになる。

この頃からは新クライアントを開発しているためなのか、旧クライアント修正はあまり行われなくなり、定期的なイベントが行われるのみであった。思えばこの頃はスキマの遊び方(このようにするとバグを踏むのでこれはしない、であるかいった遊ぶための作法)がわかっている人間しかスキマを遊んでおらず、運営側積極的には宣伝もしていないため新しいユーザも増えなかったため、比較的安定した運営が行われていたのではないかと思われる。

また、恐らくこの頃であると思われるが、2chスレッドで「スキマは冒険者が冒険をしてきたログを眺めることでそのダンジョン攻略法を考えたりするゲームなんだけど、あまりにもバグが多すぎるから2chというログを読む事でスキマというゲーム攻略しているよね」といった書き込みが行われるなど、スキマをダンジョン攻略ゲーとして捉えるのではなく、バグ攻略ゲーとして捉えるというユーザが現れていた。

期待はずれの新クライアント

さて、一周年の時に発表された新クライアント開発は、その後3ヶ月程で70%まで出来ていると発表されたが、結局その新クライアントがお目見えしたのは2周年を目前に控えた頃であった。新クライアントのお披露目はAndroidβテストという形で行われた。言い忘れていたがスキマはiOSしかサービスされておらず、それまでAndroid版は存在しなかった。僕はAndroidiOSも持っていたため、βテストに応募し、当選したので遊んでみたのである

まず、フルスクラッチ制作されると言われていたのでUI周りも変わるのであろうと思っていたのは完全に裏切られた。見た目はほとんど何も変わらず、もちろんUIタップ回数まで全く同じであった。しか使用されているフォントが違うために文字が見切れていたりといった問題が発生しており、お世辞にも前のクライアントとくらべて良くなったとは言えなかった。また、恐らくはサーバクライアント間のプロトコルも何も変わっていないのか、プロトコルサーバ側に起因する問題は依然として残っていた(武器や防具を鍛錬すると+の数値が上がるという仕様があるのだが、連続して鍛錬を行うと必ず1以上は上がるはずの鍛錬値が上がらなかったり下がったりするといった問題は残っていた)。また、動作iOS版と比べるともっさりとした感じが強く、何のために作り直したのかわからないという感想であった。2chスレッドの中ではこの新クライアントは単に今までの旧クライアントAndroid移植したものであり、本物の新クライアントはまだ開発中なのだと言って聞かない人が長いこと存在した程である

その後、βテストでお披露目された新クライアントは3ヶ月後にAndroidリリースされ、その後さらに3ヶ月後にiOSでも新クライアントリリースされた。

クライアントで新たに現れる問題の山

鳴り物入りで導入された新クライアントであるが、先程も書いたように、旧クライアントと比べると確かに解決された部分もあるが、サーバ側が関わる問題は全く同じ問題を抱えており、新クライアント特有問題が多く発見され、実質的には旧クライアントの方がバグが少ないという状態であった。

僕はβテスト以降は特にAndroid版で遊ぼうとはしていなかったため、新クライアントが先行リリースされたAndroid版を遊んでいた人達を眺めていたのだが、Android版で起こっていると2chで報告されている問題がそのままiOS版でも起こるとなると大変だと思って眺めている位には、Android版は阿鼻叫喚の様を呈していた。iOS版での新クライアントリリースは3ヶ月遅れたが、この間Android版は何度もなんどもアップデートを繰り返し、その度に少しづバグ修正されていくのをみて戦々恐々としていた。

iOS版の新クライアントリリースされた直後、僕はスキマを遊ぶことができなくなった。これはゲームを起動した後すぐに「通信エラー」が表示されてタイトル画面に戻されるという問題で、これを回避する方法全然からなかったためだ。「あぁ、ログインボーナス貰えてたのがなくなっちゃうなぁ」と思ったのを覚えている。

しかし、この問題については2ch(正確にはTwitter経由であるのでTwitterの誰か)に「お知らせ」をタップしてからだと通信エラーが起こらない、というオカルトじみた書き込みがあり、それを信じてやってみると確かに通信エラーが起こらないということが確認できた。これで僕もスキマをプレイすることができるようになったのである。この時は本当に2chというログを読んでスキマというゲーム攻略している感じがしたものだった。

この時、僕は何故通信エラーが起こるのか、何故「お知らせ」をタップすると通信エラーが起こらないのか、といった事を確認したくなってiOS版の通信を眺めてみることにした。本来であればこのような行為を行うのは自分主義に反するため、それまでは行わなかったのであるが、突然ゲームプレイできなくなるというのは大変衝撃であったので、つい出来心で、という感じで眺めてみたのである

クライアントサーバ間の通信HTTP、つまり平文で行われており簡単通信内容をみることができた。タイトル画面から通信エラーが出るまでの通信内容はだいたい以下のような感じであった。

1. クライアントからユーザ情報送信

2. サーバからセッションキーが送られてくる

3. クライアントから並列で何らかの情報を取得するためのGETリクエスト送信

4. 並列で送られたリクエストへの返信をサーバが返すが、その全てに更新された(別の)セッションキーが入っている

5. ログイン完了してゲーム画面が表示される

6. クライアントで何らかの操作を行おうとしてサーバリクエスト送信

7. 6.のリクエストへの返事が4**でエラー

まり、3. のリクエストが並列で行われ、サーバ更新したセッションキーが 4. でクライアントに届けられるのであるが、恐らくは届いたセッションキー前後してしまうことで壊れてしまったと考えられる。

これが、何故「お知らせ」をタップすると解消するのかであるが、実は「お知らせ」を取得するためのURLhttp://…../login2 というURLへのGETリクエストであり、かつセッションキー必要としておらず、このURLからリクエストの返事にはセッションキーが含まれるという特殊URLであったのだ。つまり本来であれば 5. の状態の時には壊れたセッションキーを保持していたはずが、そこで「お知らせ」をタップすることで新しい(正しい)セッションキーを手にすることができるようになり、その後の通信はちゃんと行えるようになったのである(その後の通信では並列にリクエストを投げるパスは僕の観測した範囲では存在しないように見えた)。

この事に気づいたTwitterの人はどうやって気づいたのかはわからないが、よく見つけてくれたものである。ともかく、僕はこの情報に助けられ、スキマを再開することができた。

長くなったので https://anond.hatelabo.jp/20171221020636 へ続く

2017-11-05

Webフレームワーク選定の悩み

Webアプリを作るとき何を基準にしてプログラム言語Webフレームワークミドルウェアを選定していますか?

RailsCoC:convention over configuration)以外の手法活用して、開発を高速化するにはどうすれば良いでしょうか?

 

希望条件

  1. 素早いプロトタイピングscaffold機能など
  2. テストコスト削減:関数型プログラミングモジュール手法
  3. 性能:コンパイル型の言語

…こういう条件を備えていれば良いかな?

 

フロントエンド

  1. JSGUI作成Vue.js等のSPAフレームワーク

 

バックエンド

  1. データ永続化ストレージCRUD機能を用意できれば何でも良い?

 

試作

  1. Railsプロトタイプを作りデザインスプリント実践

 

本番

  1. 形が決まったらGolangGCPで作り直して本番投入

プロトタイプを作り直す手間を省きたい。プロトタイプと本番を同じツールで作りたい。)

 

サーバーAWSバックエンドElixir/Phoenixフロントエンド:Elmという組合せはあまり盛り上がっていないようなので、Rails代替手段は何が良いのか?気になります

2017-10-12

プログラミング界隈で言語フレームワークミドルウェアの移り変わりについていかなきゃいけないつらさなんて話はよくあるが

デザインとかその他表現そもそも表現に限らずなんだって流行り廃りはあるから

そこで生き残ってる人は結局アップデートしてんだよな

2017-09-11

https://anond.hatelabo.jp/20170910205249

まじな話をすると、N予備校プログラミング入門コースやるのがオススメ

https://www.nnn.ed.nico

一日8時間勉強時間があるなら、だいたい一ヶ月で終わる内容。

月額1000円だけどしっかり勉強すれば一ヶ月の無料間中に終わると思う。

もともとN高等学校のノンプログラマーの生徒をWebエンジニアとして就職させるために作られたカリキュラム講師曰く去年はこれで二人エンジニア就職を決めたらしい。

内容も相当親切に説明していて、プログラミングで何か作るだけじゃなくて、就職必要な環境構築やセキュリティまでみっちりやる。

http://qiita.com/sifue/items/7e7c7867b64ce9742aee#%E3%82%B3%E3%83%B3%E3%82%BB%E3%83%97%E3%83%88%E3%82%92%E3%82%82%E3%81%A8%E3%81%AB%E6%A7%8B%E6%88%90%E3%81%95%E3%82%8C%E3%81%9F%E3%82%B3%E3%83%BC%E3%82%B9%E3%81%A8%E5%86%85%E5%AE%B9

講師が書いてる入門コースで習うことがまとめ。テキスト教材もあるけど授業も1項目を2時間で説明している。授業は週2の生放送とそのアーカイブがある。

↓みたいなことが学べる

----

Webプログラミング入門コース

Web ブラウザとは (Chrome, デベロッパーコンソール, alert)

はじめてのHTML (VSCode, HTML, Emmet)

さまざまなHTMLタグ (h, p, a, img, ul, tableタグ)

HTMLで作る自己紹介ページ (HTMLタグ組み合わせ, コンテンツ埋め込み)

はじめてのJavaScript (JS, ES6, エラー)

JavaScriptでの計算 (値, 算術演算子, 変数, 代入)

JavaScript論理を扱う (論理値, 論理積, 論理和, 否定, 比較演算子, if)

JavaScriptループ (ループ, for)

JavaScriptコレクション (コレクション, 配列, 添字, undefined)

JavaScript関数 (関数, 関数宣言, 引数, 戻り値, 関数呼び出し, 再帰)

JavaScriptオブジェクト (オブジェクト, モデリング, プロパティ, 要件定義)

はじめてのCSS (CSS, セレクタ, background-color, border)

CSSを使ったプログラミング (transform, id, class)

Webページの企画とデザイン (企画, 要件定義, モックアップ, 16進数カラーコード)

診断機能の開発 (const, let, JSDoc, インタフェース, 正規表現, テストコード)

診断機能組込み (div, 無名関数, アロー関数, ガード句, truthy, falsy)

ツイート機能の開発 (リバースエンジニアリング, URI, URL, URIエンコード)

Linux開発環境構築コース

LinuxというOS (VirtualBox, Vagrant, Ubuntuインストール, OS, CUIの大切さ)

コンピューター構成要素 (ノイマンコンピューター, プロセス, lshw, man, ps, dfの使い方)

ファイル操作 (pwd, ls, cd, mkdir, rm, cp, mv, find, ホストマシンとの共有ディレクトリ)

標準出力 (標準入力標準出力標準エラー出力パイプgrep)

vi (vimtutor)

シェルプログラミング (シバン, echo, read, 変数, if)

通信ネットワーク (パケット, tcpdump, IPアドレス, TCP, ルーター, ping)

サーバークライアント (tmux, nc, telnet)

HTTP通信 (http, https, DNS, hostsファイル, ポートフォワーディング)

通信をするボットの開発 (cron, ログ収集)

GitHubウェブサイトの公開 (GitHub, リポジトリ, fork, commit, 情報モラル)

イシュー管理とWikiによるドキュメント作成 (Issues, Wiki)

GitとGitHub連携 (git, ssh, clone, pull)

GitHubへのpush (init, add, status, インデックス, commit, push, tag)

Gitのブランチ (branch, checkout, merge, gh-pages)

ソーシャルコーディング (コンフリクト、プルリクエスト)

Webアプリ基礎コース

Node.js (Node.js, nodebrew, Linux, REPL, コマンドライン引数, プルリク課題)

集計処理を行うプログラム (集計, 人口動態CSV, Stream, for-of, 連想配列Map, map関数)

アルゴリズムの改善 (アルゴリズム, フィボナッチ数列, 再帰, time, プロファイル, nodegrind, O記法, メモ化)

ライブラリ (ライブラリ, パッケージマネージャー, npm)

Slackボット開発 (slack, mention, bot)

HubotとSlackアダプタ (hubot, yo)

モジュール化された処理 CRUD, オブジェクトライフサイクル, filter)

ボットインタフェースとの連携 (モジュールのつなぎ込み, trim, join)

同期I/Oと非同期I/O (同期I/O, 非同期I/O, ブロッキング)

例外処理 (try, catch, finally, throw)

HTTPサーバー (Web, TCPとUDP, Webサーバーの仕組み, Node.jsイベントループ, リスナー)

ログ (ログ, ログレベル)

HTTPのメソッド (メソッド, GET, POST, PUT, DELETE, CRUDとの対応)

HTMLフォーム (フォームの仕組み, form, input)

テンプレートエンジン (テンプレートエンジン, jade)

HerokuWebサービスを公開 (Webサービスの公開, heroku, dyno, toolbelt, login, create, logs)

認証利用者を制限する (認証, Basic認証, Authorizationヘッダ, ステータスコード)

Cookie を使った秘密匿名掲示板 (Cookie, Set-Cookie, expire)

UI、URI、モジュール設計 (モジュール設計, フォームメソッド制限, リダイレクト, 302)

フォームによる投稿機能の実装 (モジュール性, textarea, 303)

認証された投稿の一覧表示機能 (パスワードの平文管理の問題, 404, テンプレートのeach-in)

データベースへの保存機能の実装 (データベース, PostgreSQL, 主キー)

トラッキングCookieの実装 (トラッキング Cookie, IDの偽装, Cookie の削除)

削除機能の実装 (データベースを利用した削除処理, 認可, サーバーサイドでの認可)

管理者機能の実装 (Web サービス管理責任, 管理者機能の重要性)

デザインの改善 (Bootstrap, レスポンシブデザイン, セキュリティの問題があるサイトを公開しない)

脆弱性 (脆弱性, 脆弱性で生まれる損失, 個人情報保護法, OS コマンド・インジェクション)

XSS脆弱性対策 (XSS, 適切なエスケープ処理, リグレッション)

パスワード脆弱性対策(ハッシュ関数, メッセージダイジェスト, 不正アクセス禁止法, パスワードジェネレーター, 辞書攻撃)

セッション固定化攻撃脆弱性対策 (セッション, セッション固定化攻撃, ハッシュ値による正当性チェック)

より強固なセッション管理 (推測しづらいセッション識別子, 秘密鍵)

CSRF脆弱性対策 (CSRF, ワンタイムトークン)

安全なHerokuへの公開 (脆弱性に対する考え方, HTTPの廃止)

Webアプリ応用コース

Webフレームワーク (Express.js, フレームワーク導入, 簡単なAPI, セキュリティアップデート, Cookie パーサー, ミドルウェア, 外部認証, ロガー)

ExpressのAPI (app, Properties, Request, Response, Router)

GitHubを使った外部認証 (Passport, OAuth)

スティングフレームワーク (Mocha, レッド, グリーン, リファクタリング)

継続的インテグレーション (CircleCI)

クライアントフレームワーク (Webpack, Chrome 以外のブラウザでもES6)

DOM操作フレームワーク (jQuery, jQueryアニメーション, this)

AJAX (jQuery.ajax, クロスドメイン, 同一生成元ポリシー, x-requested-by, CORS)

WebSocket (WebSocket, WebSocketの状態遷移, Socket.io)

RDBとSQL (DDL, DCL, CREATE, DROP, INSERT, DELETE, UPDATE, WHERE)

データモデリング (リレーショナルモデル, 正規化)

テーブルの結合 (外部結合, 内部結合, 片側外部結合, JOIN ON)

インデックス (インデックス, 複合インデックス, Bツリー)

集計とソート (SUM, COUNT, ORDER BY, GROUP BY)

「予定調整くん」の設計 (要件定義、用語集、データモデル、URL設計モジュール設計、MVC)

認証とRouterモジュールの実装 (Mocha, supertest, passport-stub, モックテスト)

予定とユーザーの保存 (セキュリティ要件, UUID, 複合主キー)

予定とユーザーの一覧の表示 (非同期処理, Promise, then)

出欠とコメントの表示 (入れ子の連想配列, Promise.all, 子どもからデータを消す)

出欠とコメント更新 (Promiseチェイン, リファクタリング)

予定の編集と削除 (要件の衝突, 関数再利用)

デザインの改善 (this, グローバルオブジェクト)

セキュリティ対策と公開 (X-Frame-Options, Heroku環境変数)

2017-06-27

anond:20170627155813

スクリプト言語楽しいと思う人はアプリ寄りのことをしたいんだろうから

大学にいる間はまぁ我慢しておくんだな。

大学じゃアプリ開発なんて教えてくれないし、教えることができない。

情報系の学部で C を教えない方がおかしいだろう。

君たち大学生は将来コンパイラを書くかもしれないしOSミドルウェアの開発を

期待されてるんだよ。アプリ屋になることなど期待されてない。

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん