無気力生活 (ノ ´ω`)ノ ~゜

脱力系エンジニア。てきとーに生きてます。

2018/12/23 気になった記事まとめ

気づけば毎日ブログ書きを続けて14日。なんとか継続できてますが、油断すると下記忘れそうな状態です_(:3」∠)_

一ヶ月間継続できれば、習慣化できる...のか?

静かに生き始めると人生まさに終わった感あり(´・ω・`)こわい

type.jp

今年8月くらいの昔の記事ですが、なぜかはてブで上がってますね。

企業が最新のテクノロジーをビジネスに活用しようとする時の重要な課題は、社内にどれだけ技術を理解して動かせる人がいるかということ。だからこそ、どんどん自分で動いていくことが有効ですね。

昨日書いたおちんぎんを上げる技術にも、それとなりに書いた話なのですが『問題に挑戦する機会』を得て、『会社の問題を解決できる力』を身につける。

会社の問題にもいろいろありますが、この記事の例だと最新のテクノロジをビジネスに活用することが挙げられています。 それができる人であれば、目立つし、それに関わる仕事が多く舞い込んでくるようになります。自分の選んだやりたい仕事をやり続けられる日々は最高だと思います(`・ω・´)

耐障害性の設計は忘れがちですが

tech.mercari.com

これまでいろいろと開発してきたんですが、割と『障害が起きたときにどう動かすべきなのか?』を意識されているシステム、特にtoCでお金が絡まないサービスにおいてはおざなりになります(´・ω・`)

特にMicroserviceを適用する場合、そのAPI自身も外部のAPIに通信して処理を行うことになります。ここで同期処理を行っていた場合で、外部のAPIで何らかの障害が発生してレスポンスを返せない状況下にあるとそれに引き摺られて一緒に死にます。

非同期通信を使用することで、サービス間の疎結合を保ち自律性を維持することができます。

(私個人が考えた)一言で表すと、「他のサービス死んでても、自サービスは正常に処理を完了できる」です。例えば外部処理をキューに詰める処理だけして後で問い合わせるなり、この記事のようにPub/Subを使うなりの方法を用いて、外部APIの呼び出しもとAPIもまとめて死ぬことを防ぐことが重要です。

前職でモバイルゲームの開発をやっていました。イベントの開始時大量のアクセスが来てUnicornが詰まることがあり、対策を考えていました。そこでExponential Backoffとリトライを使おうとしたことがあります。

まあ結局はAPPサーバーを増台してUnicornのワーカー数を増やすことで決着したので結局利用しなかったのですが、こういうやり方を知っておくだけでも有益だと思います。

jQueryだけでSPAやってました_(꒪ཀ꒪」∠)_

https://www.m3tech.blog/entry/js_3_point

シングルページアプリケーションのHTMLゲーム。やってた時期は今からだと5-6年くらい前ですかね...。

当時はまだReact.jsがOSSになっておらず、jQueryなり軽量jQuery的なものが幅を効かせていた時代でした。 データを扱う層、画面を描画する層を分離することがとても大事。この記事にも書かれていますね。

その時担当していたHTMLゲームでは、なにか操作して画面の表示を切り替える際、まずAPIリクエストでそのページでアクセスされる可能性の高い情報を一括で引いてました。例えば装備一覧画面なら、所持しているすべてのデータをJSON形式で受け取ります。

処理の流れを雑に列挙すると、

  1. 今の条件で表示するデータを1ページ分取得し、内部のHashに保存しておく
  2. 1以外のデータの取得をリクエストしておく。
  3. 2の処理を行っている間、1で取得したデータとテンプレートからDOMオブジェクトを生成し、ページ中のコンポーネントを丸々入れ替える
  4. 2でリクエストしたレスポンスを内部のHashに詰める

で、ここで重要なのは、データの取得と描画処理を分離することです。絶対にxHttpRequest.onreadystatechange でレスポンス受け取った中で描画しないことを心がけてます。

  1. 予め、データ用のModelオブジェクトに受け取ったデータを詰めておく
  2. Modelオブジェクトのデータから、コンポーネントに表示するためのDOMオブジェクトを、テンプレートとデータから生成(当時はhttps://ejs.co/使ってました)
  3. ページ中のComponent要素の直下を、2で生成したDOMオブジェクトで差し替え

データを元に描画するDOMを構築しそれで置き換えるだけ。楽。(`・ω・´) 一番メリット大きかったのは開発が非常に楽だった点ですね。画面を表示したままデータを取得する処理だけ実行してサーバー側の実装変更に追従したり、逆にフロント側の条件分岐を確認するためにデータ書き換えて、renderメソッドだけ実行する。ちょっとした変更をすぐ試せるので効率が良かった記憶があります。

今になって思えば(程度の差こそあれ)Reactに似てるんですよね(`・ω・´) 実はReact等無くても実現できるので、ものすごく小規模なら自前で書いたほうが楽かもしれませんよ。