Redux 再考 - mizchi's blog
今まで自分で作ったものが十数個、仕事で5社ぐらいの redux を見てきたので、その結果思うところを書く。 前提として、自分はエコシステムに乗るという意味で今では redux 肯定派だが、redux それ自身が過剰に抱えている複雑さはもっと分解されるべきだ、という立場。 Redux がうまく設計されているとどうなるか 一貫した一つの設計論に従うので、考えることがなくなる 難しさが廃されるのではなく、難しい部分が一箇所に集中する。React Component の末端では、何も考えることがなくなる。状態管理という難しい部分を作る人と、末端のコンポーネントのデザインに注力する人を分けられる。 大規模になっても設計が破綻しにくい、というエンタープライズ向きな特性を持つ。が、その技術基盤は(静的)関数型由来の考えが多く、基礎設計や基盤理解にはハイスキルが要求され、需要と適用対象のミスマッチを感じる
Twitter での6年間 #6｜Satoshi Nakagawa｜note
(Twitter での6年間 5 からの続き) 2014年3月、グリーンカード、つまり永住権の申請プロセスをはじめることにした。そのときぼくは H-1B ビザで働いていたのだが、このビザには6年の最終期限がある。2010年10月からなので期限まで残り2年半しかなかった。一度期限が切れてしまうと、基本的には国外に出ていかなければいけなくなる。H-1B で働いていてこれからも US で働きたいと考える以上、グリーンカードを取得する必要があるわけだ。 6月の WWDC で、iOS 7 にシェアエクステンション機能が搭載されるとの発表があった。社内でそれを実装するために優秀なエンジニア2人のチームが結成された。この機能はアプリから独立した拡張として別プロセスで動作するので、iOS に標準搭載されている Twitter 連携機能を直接使う必要があった。そこでその問題について詳しいぼくが認証部分をチー
Twitter での6年間 #5｜Satoshi Nakagawa｜note
(Twitter での6年間 4 からの続き) 2013年の春ごろだっただろうか。上のほうの人が、A/B テストをプロダクト開発に活用することを推奨し始めた。A/B テストでプロダクトの方向性を決めていくというのだ。これにつられ、この頃の社内では A/B テスト万能論のような空気さえただよっていた。普通に考えて、A/B テストを数週間走らせてデータをとっても、それが長期的な成功につながるか判断できるはずがない。短期的に数字が上がるからといってユーザーの嫌がることを続けていれば、いつかユーザーの忍耐の限界に達してしまうかも知れない。そのユーザーの堪忍袋の状態をどうやって計測できるというのか、など疑問は尽きなかった。 そのころ Growth という大きな部署ができて、従来国際化を担当していた i18n エンジニアリングチームもその下に組み込まれることになった。Growth チームの強い権限のも
Twitter での6年間 #4｜Satoshi Nakagawa
(Twitter での6年間 3 からの続き) 2013年に入り、iOS 6 の普及率も十分に高くなったころ、同僚のエンジニアから1つの提案がなされた。ツイートビューを作り直そうというのだ。その時点での Twitter for iOS は、iOS の黎明期に Apple が推奨していたように、できるだけビュー階層を減らして描画するようになっていた。たとえば、ツイートビューには一切サブビューがなく、ツイートテキスト、プロフィール画像、ユーザー名、タイムスタンプなどのパーツは直接ツイートビューに自前で描画する設計になっていた。当初はそのほうがパフォーマンス的に速かったからだ。それから数年間の Apple によるハードウェア、ソフトウェア両面での改善の結果、ベンチマークを取ってみるとどうやらその設計はもう古いらしいことがわかった。たとえば画像を表示するときに、自分でビューに CPU で描画するの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
