今年読んだ/聞いた本 - steps to phantasien
Learning Spark 知り合いが Hadoop をやっているのをみて羨ましくなり向こうが Hadoop ならこっちは Spark だ！と入門してみた。実際には大したことはせず, DataProc で遊んでみたくらい。まあ面白くはあった。DataProc は History Server にアクセスするのが面倒でいまいちという感想。真面目に使うとそのへんの workaround は確立できるんだろうけれど。 そのあと仕事で少しだけ Flume (Cloud DataFlow の前身) を触る機会があり、Spark 入門とあわせてちょっと big data な気分を味わえたのは良かった。 Programming in Scala (3ed) Spark をやった勢いで Scala を復習。むかし初版を読んだときの印象よりは難しくない気がした。まわりの言語が難しくなってきたからかもしれな
レイテンシとスケーラビリティ - steps to phantasien
いま仕事をしているチームのリードはレビューの反応が速い。レビューに限らずメールの返事も速い。リード以外の人々もだいたい反応が速い。時差のある仕事をしていた頃は反応に一日かかるのが当たり前だったし、時差がなくなったあとも反応の遅い相手との仕事が多かった自分には新鮮だ。 一方、自分がこの速さを期待されたらしんどいと正直なところ思う。誰かに反応するには自分の作業を中断しないといけない。集中が途切れる。他人の仕事をブロックしないために自分の進みを犠牲にする。フォーカスやらフロー状態やらを重視する一方で反応の速さに美徳を見出す。共同作業のジレンマといえばそれまでだけれど、レイテンシ・スループットのトレードオフがレイテンシ側に倒れすぎていると思う。もう少しスループットに倒せる世の中になってほしい。 時差のある仕事では、待たされる前提でいくつもの仕事を同時に進めていた。一つをレビューに出したら、別の仕事
異動ルールズ - steps to phantasien
異動してみた。Chrome と関係ない Android アプリのチームへ。 モバイルに詳しくなろうと余暇にちまちまコードを書いてみたもののまったく捗らない。いっそ仕事にしてみようという次第。座席の引越しから数日、よろよろしながらもやっと初コミットできた。めでたい。 Work Rules という本がある。 Googleの人事(People Ops)のボスによる Google の本で、人事制度を中心に企業文化やシステムを紹介している。 いまいち時代背景が不透明な How Google Works と違い大企業としての Google をうまく描いている。興味深く読んだ。 中でも三つの論点が印象に残った。透明性、自由、そして管理職の権威を削ぐこと。異動の支度をしながら読むと説得力がある。一例として様子を書いてみたい。 Google のエンジニアリング部門は、たまの異動を薦めている。いろいろ経験して
書き直さない時代の気分 - steps to phantasien
なんとなく続き。(前回) Martin Fowler が蒸し返すまで、 自分は書き直しについてことさら何か書く気が起きなかった。 どうでもよさは時がたつほど増していった。気分の出処を見直してみたい。 部分的に書き直す 最初の理由は、書き直しがゼロかイチかの大きな判断ではないという納得かもしれない。コードの書き換えには様々な粒度がある。一番小さいのが厳密なリファクタリング。一番大きいのがフルスクラッチの書き直し。その間には様々な大きさの書き直しがある。書き直しの粒度が連続的である以上、どちらか一端を擁護する議論は虚しい。 小さい刻みの変更を積み重ねれば危険を冒さず大きな変更ができる。それがリファクタリングのテネットだ。刻みは小さいほど安全だから、良いプログラマは大きな変更を連続した小さい変更へと噛み砕く。変更の難しさに実力が及ばないと刻みが大きくなり失敗の危険が増す。バグが増えたり納期に遅れ
転校生の本歌取 - steps to phantasien
ふと思い出し書き直しの話 (1, 2) の続き。 書き直しの必要に迫られることも、たまにはある。それはオリジナルが手に入らないとき。転職先で前の職場にあった内製ツールが使いたい。慣れたプログラミング言語にあったライブラリが新しい言語に欲しい。そんなときは自分の新しい環境でオリジナル相当品を書き直したいかもしれない。再発明、移植なんて呼ぶこともある。 この書き直し、再発明は、必ずしもオリジナルを超えなくていい。越えるべきオリジナルを使えない事情があってのコードだから。スポーツの試合で怪我をしたエースのかわりに急遽投入された補欠の立場に似ている。ベストを尽くし役割を果たせばいい。補欠系書き直しとでも呼ぶことにしよう。 Bazel と補欠たち 一応の役目は果たすものの、オリジナルほどはぱっとしない。そんな補欠系書き直しはたくさんある。 プログラミング言語をまたいだ補欠系書き直しとして真っ先に思い
確率的に犠牲的 - steps to phantasien
Martin Fowler が Sacrificial Architecture と言い出した時は驚いた。“変化を受け入れよ” はどこにいったの。書き直しはダメと自分の中の結論が出たのは随分前のことだけれど、ひさしぶりに考え直してみる。 Sacrificial Architecture の論拠として Martin Fowler はいくつかのインターネッツ企業を例にとっている。でも一般化するには偏ってないか。それにこれら企業が面していたのはごく限られた種類の変化だ: 彼らはもっぱら性能不足と戦っていた。 機能の変化に強いコードは柔軟性の裏で性能を犠牲にしがち。機能の変化を捉えることに先鋭化した従来の Agility は性能要件の変化を必ずしもやり過ごせない。一方で存在感を増すスタートアップの世界では性能への期待が当たり前のように大きく変わる。だから Agile はあてにならない、堅牢なアーキ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
