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

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

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

2018/12/14の気になる記事まとめ

つい先日、外作業用にiPadのキーボード買いました(`・ω・´)

この記事はこれで書き始めたんですが、意外となんとかなりますね。といってもまだなれてないので普段どおり作業PCで続き書いたんですけど_(:3」∠)_

外で気軽に作業できるようになるのでいい買い物だったと思います。あとは開発環境も整備して、どこでもiPadでコード書けるようになるといいですな

MVVMからMVCに戻した事例を読んで

speakerdeck.com

技術選定するときに、「なぜそれを選ぶのか?」を考えることが非常に大切なのがわかる記事。ふわっとした理由で決めると、あとで負債になって爆発しますね(:3」∠)

個人的に考えるMVVMのメリットは、VMを作ることでViewに必要な項目の構造が定義でき、かつ表示関連のロジックをVM側に固めて隠蔽できることにあると思ってます。ModelをまんまViewで参照すると、そのままでは嵌らないことが多いのですが、そのための処理をViewModelの中に書き、Viewからはメソッドなりプロパティを呼ぶだけに留めると、うまく整理できることが多くありました。

記事では、ViewControlとViewModelの重複定義の話がされてますが、実装見る限りRxを使ったことによる弊害に感じますね(´・ω・`) ViewModelが良くなかったというよりRxのbindingを愚直にやろうとした結果と、ViewModelの責務が多くなってる結果、そっちにもRx仕込まないといけなくなってるのが、辛い要因かな、と思います。

iOSアプリ開発経験ないんで、無知ゆえの戯言かもしれませんが、もし自分なら個々の要素に対してObserveせずに、ViewModelのオブジェクトで要素を更新するようObserveして、1要素1Disposedしか書かないようにするかと思います。多少無駄な更新が走るかもしれませんが実装の手間を考えると楽できるかな?と。

実際に事業でブロックチェーン使うとこうなるんだろうなと考える事例

logmi.jp

Lineの事例。設計周りの話にしっかり触れられており参考になります。思想がユーザー体験から始まってるのすごくいいと思います。

コンセンサス周りの設計、というかLINK Chainですが、ブロック生成と情報提供を分離することで負荷分散する。これよくあるmasterとread replicaの考え方と似たようなものなんですが、ブロックチェーンでやってるの結構珍しいと思います。

ブロックチェーンのアプリをProductionで書いたことないんで完全に憶測でしかないんですが、create より readの方に負荷がよりがちになるんじゃないかなと。その観点からみれば情報提供が分けて定義されてあると、スケールアウトしやすくていいですね。

後は独自技術使わずに既存と同じ技術を採用されてるのがいいです。Pythonコントラクトが実装でき、jsonRPCで通信できる。実際に利用する側から見たとしても使いやすいものになりそうじゃないかと感じました。

ドラゴンスレイヤー爆誕

https://qiita.com/cawpea/items/fd0c6633cd2b0c919d7a

読んでて、つい、ふふっと変な笑いがでました( ゚д゚)バグや障害を楽しめる雰囲気づくりいいですね。

技術的負債の何が一番問題かというと、後から手を出すには面倒で億劫すぎる、ということにあります。技術的負債の見える化までは、どの開発組織でも出来ているとは思うのですが、まぁ消化率は良くないことが多いんですよね...着手までが時間かかるというか。

そういった見方から考えると、バグを退治する意欲にあふれる環境作りが効いてきます。自分はこれまでうまくその環境つくれなかったんですが、伝説の剣を与えるようなノリと文化が作れれば、実行に移すのも楽しくやれそうですね( ・`ω・´)

モチベーション大事。