steps to phantasien

異動ルールズ

Thu, 14 May 2015 00:00:00 +0000

異動してみた。Chrome と関係ない Android アプリのチームへ。

モバイルに詳しくなろうと余暇にちまちまコードを書いてみたもののまったく捗らない。いっそ仕事にしてみようという次第。座席の引越しから数日、よろよろしながらもやっと初コミットできた。めでたい。

Work Rules という本がある。 Googleの人事(People Ops)のボスによる Google の本で、人事制度を中心に企業文化やシステムを紹介している。いまいち時代背景が不透明な How Google Works と違い大企業としての Google をうまく描いている。興味深く読んだ。

中でも三つの論点が印象に残った。透明性、自由、そして管理職の権威を削ぐこと。異動の支度をしながら読むと説得力がある。一例として様子を書いてみたい。

Google のエンジニアリング部門は、たまの異動を薦めている。いろいろ経験してよいエンジニアになりなさいね、という意図だと思う。強制されるわけではない。同じ製品の仕事を続ける人も多い。一方で数年おきに居場所を変える人も少なくない。

透明性

社内には求人サイトがある。既存の製品からリリース前の秘密プロジェクトまで幅広く募集がある。面白そうなものをいくつかブックマークし、どれにしようと思いを馳せる。

ここで透明性が光る。

募集要項には一緒に働くであろうチームメイトのリストがついてくる。チームの規模や地理的な散らばり具合がわかるほか、社内名簿経由でレジュメを辿れば期待されるスキルセットも透けて見える。私は小さめのチームがよかったので、チームメイトの名前が長々と並ぶところはやめておいた。

大抵はプロジェクトのコードネームも載っている。秘密プロジェクトの求人は詳細をぼかし「メールで訊いてね」などと書いてあるが、コードネームで社内を検索するとあっさりプロジェクトのページ (Google Sites) がみつかったりする。リリース前の製品だと閲覧制限されていたりもするけれど、まあ半分以上の募集では何かしら見つかる。同様にチームメンバーの名前を検索すればメーリングリスト(Google Groups) のアーカイブにたどり着く。締め切り前にチームを励ますマネージャからのメールが目に止まる。いいマネージャだけど締め切りきついのはちょっとな・・・と思ったりする。

ページにはコードのビルド方法が書いてある。特殊なケースを除き、大半のコードは読める場所にある。チェックアウトすればコードの規模や好みがわかる。履歴から開発ペースもわかる。コミットログを集計してエースか誰が推し量ったりしてみる。名簿にない名前がログにあらわれ、誰かと思ったら少し前に異動でチームを離れた人だった・・・そんなこともわかる。

Googlegeist と呼ばれる社内サーベイの結果を公表しているチームもある。チーム外に公表するかどうかは当人たちの意向次第のため必ずしも気になる結果が見えるわけではない。私の異動先は結果を公表しており、スコアは良かった。このサーベイはけっこう素直に現状を描きだすと経験上知っているから、好スコアは不安を少し和らげてくれた。

知り合いの少ない自分にとって、この透明性は助けになる。

権威と自由

一通りのストーキングを済ませたら候補を絞り込む。もたつく間にいくつかの募集は姿を消していた。まだ生きている募集の窓口にメッセージを送る。該当チームの管理職から返事。どんな仕事があるのか話を聞いてごらんとメンバーを紹介される。ビデオ会議で話したり、ランチを食べつつ話を聞いたり。そのあとマネージャ当人とも話す。人事考課の過去ログを見せたりなんだりしたあと、大丈夫そうだから気が向いたら手続きしてねと連絡をもらう。

行き先の目処が立った。ここで上司に申し開く。もう C++ には飽きました。よそのチームで Java やります。などと伝える。おやおや、他の Chrome プロジェクトをやるってのはどう？そんな代案を丁重にお断りし、じゃあ仕方ないねと話は終わる。

異動手続きのサイトでフォームを埋め提出。値の張る買い物みたいな承認のワークフローが始まる。けれど承認チェーンに並ぶのは異動先のマネージャたち。自分の今の上司はいない。ある条件を満たした異動を、管理職が妨げることはできないという。次のリリースまで待ってくれと口を挟むくらいがせいぜいらしい。

私の場合はすでに話をつけてある。だから承認されない心配はない。社内の異動ガイドにもきちんと話を通せとある。けれど実はそもそも承認がいらなかったとは、少し驚く。

ここで渋られても困るから、的を射た設定だとは思う。これが管理職の権威を削ぐ構造の一部なのだろう。おかげで自分は労もなく好きにチームを移ることができる。特に気にしていなかった空気のようなこの自由はシステムのデザインだった。多少の誇張もあるにせよ、そんな面はたしかにある。まあ、伝え聞くところによるとアメリカのテック大企業はだいたい似たようなものらしいけれど。

これは良いデザインなのか？あてにしていたメンバーがあっさりいなくなってしまうこともありうる。大丈夫なのかしら。でも考えてみれば、無理に引き止めた相手は厭気が差し転職してしまうかもしれない。それなら異動くらいで済んだ方がよかろう。

大企業、巷でいうほど悪くないじゃん。勤務先を見直す一幕と一冊だった。

Hiccup, An Audio Player

Mon, 11 May 2015 00:00:00 +0000

ちまちまつくっていたアプリを公開してみる。Hiccup と命名。ローカルおよび Google Drive (Storage Access Framework に対応したサービス) から音声ファイルを選んで再生する。語学学習用で、再生中は画面全体が再生/一時停止/巻き戻し/早送りボタンになって細かい一時停止や巻き戻したりがラク、という意図。シャドーイングや日本語->英語が交互に使ってる教材を消化するのに自分ではぼちぼち使っている。

もうちょっとかっこよく、多機能で、かつ速くしてから公開したいと思っていたけれど、実力不足でコードがひどいかんじになってしまい Hello World に毛が生えたくらいで挫けた。ビギナーなので仕方なし。もうちょっと修行したら書き直したいかもしれない。

反省としては腰が引けて抽象化しすぎたり RxJava や DI を濫用したりでコードがまったく読めない代物になってしまったこと。あと単体テストが全然ないこと。もうちょっと抽象を薄くバリっと書きつつ必要な範囲でテストする、というのができるようになりたい。人に使ってもらえるものを作るまでの道のりは遠い。でも自分で使うものが作れるだけでもけっこう楽しい。作りたいものがさっと作れるようになりたいもんです。

コード: https://github.com/omo/hiccup

Communicate, Not Socialize

Sat, 02 May 2015 00:00:00 +0000

あるとき「エンジニアの仕事は設計をしたりコードを書いたり communicate をすることだ」と何かの資料に書かれているのを読み、胃が痛くなりかけた。そのあと「socialize は求められてない」と続くのを見て気を取り直す。仕事の外の付き合いは Communication じゃなくて Socializing か。なお “Socialization” は違う意味。

自分は言語障壁および性格のせいでチームでの振る舞いが socially awkward 側に倒れている。でも最低限の communication はこなしているせいか、大きく問題視されたことはない。めでた・・・くはないが、最悪の事態は免れた。「コミュ障」じゃなくて「ソシャ障」ってとこか。あるいは「非コミュ」じゃなくて「非ソシャ」。まあ自分に communication の問題がまったくないとは言わないけれど。

濫用されたカタカナのコミュニケーションのうち socializing をしない人。自分は人付き合いが苦手なおたくのステレオタイプが頭に浮かぶ。けれど件の資料に登場したのは小さな子供を持つ親だった。付き合いで飲みに行くより帰って子供の相手をしたい人たち。違う文書の似た文脈ではマイノリティの人種や性別も同じように描かれていた。文化的差異のため話が合わない人たち。

実際おたく的性癖が一大勢力たるエンジニアの世界で先のステレオタイプが不利にはたらくとは考えにくい。マイノリティかどうかは隣接する人々という分布のどこに位置するかで決まるわけだから。

誰であれ socialize しない自由があり、その選択が仕事で不利に働いてはいけない。となると「ソシャ障」や「非ソシャ」と呼ぶのも discrimination になりそう。ナシだな。訂正。

Socializing が職業人生に無関係とは思わない。たとえば networking は socializing の延長だろう。でも別のラベルがつけられて職務範囲から外されると少し気が楽になる。そして socializing を職務と切り離せるのは成熟の証かもしれない。「Cultural fit がない」と付き合いの悪い年寄りを追い出すスタートアップの話は、ときどき紙面をにぎわせている。

草稿にコメントをくれた @jmuk @kzys ありがとう。

Custom Views の気楽さ加減

Tue, 28 Apr 2015 00:00:00 +0000

唐突に Android 入門日記。

余暇につくっている小さな Android アプリを Hierarchy Viewer で眺めてみた。性能上 View tree はフラットなほど良い。自分のアプリは思ったよりツリーが深くてげんなり。

Custom Elements や React Componentsと同じノリで沢山の Custom View を定義しているのがまずいのだろうか。状態を持たせるためだけに View のサブクラスをつくっている。各 custom view はコンストラクタで inflate() してサブツリーを作り、それを表示する。View#onDraw() は override しない。今のところ必要がない。

このやり方で custom view のレイアウトを与えると、ルートとなる View (大抵はなんらかの Layout クラス) が自分自身とは別に必要。ルートになれる View は一つだけ。この制限がなければ custom view 自身がその Layout クラスを継承すれば済むのに、XML の構文だけが理由で単一ルートというこの制限を受ける。Custom view -> LinearLayout -> 本来の sub view … と一段 View 階層が深くなってしまう。やや理不尽。

Activity, Fragment

人々はどうしているのだろう。サンプルアプリの親玉 iosched を覗く。アプリの規模と比べて custom view の数は少ない。20 個くらい。むしろ Activity や Fragment の方が多そう。

Custom view を使わないなら、どのように View をグループ化するのか。

ある程度の規模があるまとまりには Fragments を使っている。Responsive にしない画面では Activity にベタな layout を流し込んで終わり。自分が custom view を作りたくなる典型的なケース、RecyclerView の個々のアイテムにも custom view は作らない。適当な layout を inflate し、そのサブツリーに必要な状態やイベントリスナをくっつけておわり。たしかにこれなら余計な階層はできない。でもオブジェクト指向の敗北みたいでなんとなく悲しい。Adapter の getView() が巨大になるし・・・

ViewHolder

オープンソースの Twitter クライアント Talon を覗く。すると状態は ViewHolder という呼ばれるクラスを定義し View#setTag() で個々の View に紐付けている。たしかにこれなら View を継承しなくて済みそう。よく見るとオフィシャル文書でも紹介されているパターン。主に性能上の理由で使えと言ってるけど、ここに振る舞いや状態を与えてもよさそうじゃない？ダメ？

ViewHolder はパターンにすぎず、必ずしも決まった型があるわけではない。ただ RecyclerView には RecyclerView.ViewHolder なんてクラスもある。これを使うのが流儀なのかね。

さて custom view を定義するのはいつなのか。再利用可能な部品を作る時、特殊な描画が必要なときに使っているように見える。

少ないサンプルから得た自分の理解をまとめると:

レイアウトを inflate してリスナや値を差し込めば済むケースではいちいち Custom View を作らない。
粒度の大きな View の集まりは Fragment でグループ化する。主に responsive な画面をつくるため。
Fragment が必要ないなら Activity だけで済ますのもあり。
リストの要素など小さなまとまりには ViewHolder クラスを定義して状態をまとめ、そのインスタンスをサブツリーのルートに setTag() する。
凝った描画をしたいときや再利用可能な汎用 View 部品は custom view にする。

今書いているコードと結構違ってしまうなあ・・・。

アンチ Fragment の Custom View

ふと思い立ち Jake Wharton のサンプルアプリ u2020 を覗いてみる。この人はカジュアルに custom view を定義している。ただしそうした View 自身は subview を inflate しない。Adapter が custom view をルートとする layout を inflate する。これなら余分な view のネストは発生せず、かつ custom view を view tree のカプセル化に使う馴染み深いスタイルを踏襲できる。先の iosched なら Fragment を使いそうな場面でこうなっているのは、彼らがアンチ Fragment 派だからかもしれない。

Adapter に inflate させると本来は View が隠すべき詳細たるレイアウトが漏れ出ている気がするけれど、一方で onFinishInflate() など View 標準のライフサイクルに則りやすくなるのはよい。このバランスがちょうどいいかも。

この流儀では:

View ツリーをまとえる手段としても気軽に Custom View を定義して良い。
Custom View のインスタンス化は全体を Inflater に任せ、View を直接 new したり View 自身に inflate() させたりしない。

大げさ加減

Custom view は大げさで、わざわざそれが欲しくなるほどの複雑さは多くないとも聞いた。抽象の厚さには好みもあるので一概には言えないけれど、たしかに inflate して OnClickListener つけておわりくらいなら custom view はいらなそう。どうせクラスがないなら functional な感じにかけるとかっこいいんだけどなー・・・

まとまりをつくるのに新しいクラスが必要とは限らない

ドラフトにコメントをくれた @karino2012 ありがとう。

Rust の Lifetimes

Wed, 22 Apr 2015 00:00:00 +0000

もうすぐ 1.0 という Rust。久しぶりにチュートリアルを読む。以前見た時は不可解な機能が多く、こりゃ難しさに溺れて死にそうだな・・・と思っていた。今見るとずいぶんすっきりしている。単純さに舵を切れたのはえらい。

チュートリアルに登場したうちわからなかった機能は 2 つ: Lifetimes と Macros. Macros はさておき Lifetimes は理解してよさそう。詳しい情報を求めてリファレンスをひやかすが、驚くほど何も書いてない。かわりにメモリ安全な C の方言 Cyclone による region based memory management が元ネタとして言及されている。勢いでその資料にも目を通す。解説 PDF ひとつとマニュアルの一部。どちらもよく書けていた。記法も Rust の lifetimes と似ている。

Cyclone の region based memory management では、フレームに確保したメモリの出処、つまりメモリの生存期間を、そのメモリを指すポインタ変数に静的な型情報としてくっつける。この生存期間が Regions. 型は総称的で、その総称性を通じ関数の呼び出し元から呼び出し先へと変数毎の reigons が伝わっていく。そして長い regions のポインタに短い regions のポインタを代入しようとすると型チェックに失敗してコンパイラに怒られる。だから dangling pointer がおきない。

全てのポインタ変数が型に regions を持っている。関数の引数も同じ。そう聞くと仰々しいけれど、大抵はデフォルトの型でうまく動く。そしてデフォルトを使うかぎりコード上に regions は姿を見せない。だから普段は気にしなくて良い。Cyclone だと C からの移植で 8 割くらいは元のコードそのままでよかったという。それでも時々 lifetimes を指示したい場面があり、region 記法の出番となる。

Rust の仕組みはだいたい Cyclone と同じに見える。生存区間を表す型を Cyclone では Regions, Rust では Lifetimes と呼ぶ。Rust の reference すなわちポインタは, 変数の型に (多くは暗黙の) regions を含んでいる。

Lifetimes はコールスタックというかフレーム上のメモリの寿命をトラックするための仕組み。だから lifetimes の寿命は呼び出し関係に応じた入れ子になっている。ヒープに確保したオブジェクトの動的な寿命をトラックして正当性を担保するのは lifetimes の仕事ではない。ヒープへの reference も取りだすことはできるけれど、その reference の lifetime はヒープを指す変数があるフレームのスコープに紐づく。ヒープ上のメモリが関数のスコープを超えて outlive する事実を lifetimes で表現することはできない。

ではヒープにあるメモリの寿命はどう守るかというと、Box (unique_ptr 相当), RC, Arc (shared_ptr 相当) といったスマートポインタぽい型, move semantics と RAII がうまくやってくれる。ヒープへの reference を取り出すことはできる。ヒープとフレームの交わるところ - ヒープを指す reference の正当性は、ownership の borrowing 機構と borrowing が強制する imutability によって保証される。RAII-Move-Borrowing-Lifetimes の組み合わせが memory safety を実現する。この結論にたどり着いたのはえらい。デザインの勝利だと思う。元ネタたる Cyclone には汎用的な RAII が無いなどヒープの管理には大した工夫がなく、普通に Boehn GC を使っていると書いてあった。Rust のような GC-less にはできてない。

安全なぶん厳しい制限でもある。C++ と同じようにコードを書くわけにはいかなそう。いままで曖昧に済ませていた細部をよく考えないといけない。自分が混乱したのも lifetimes とヒープの関係が曖昧だったせい。おもったより寿命にルーズだった自分に気付く。

Rust には安全でないメモリを扱う raw pointer もある。どのくらいの頻度で raw pointer が必要になるのだろうか。動的サイズの配列 Vec 型の実装では raw pointer が使われていた。C++ で replacement new を呼んだり destrucdtor を明示的に呼んだりする程度に必要なかんじかしら。つまりしょぼいコードを書いてる分には必要ない。めでたい。

Borg Paper 感想

Fri, 17 Apr 2015 00:00:00 +0000

Kubernetes の元ネタになった Borg というシステムの whitepaper が出ていた。読んでみる。自分の Borg 経験は hello world したくらい。全然知らない。そしてめんどくさそうなので出来ることなら使わずに人生を終えたいと思っている。でも後学のために読んでも損はあるまい。 Google インフラシリーズでは親玉格のはず。

Whitepaper としては不親切な内容。読者がこの手のスケジューラについてある程度知っている前提で書かれている。ただ Cell だの Borgmaster だの Borglet だの Preemption だの、サーバ側の人々の会話に出てくる用語は一通り解説されている。きっとポイントは押さえられているのだろう。

・・・と思って読んだものの、やはりどうにもとりとめがない。細かい工夫の話が多く big picture がよく見えない。設定ファイルの例やプロセスのデプロイ方法といったエンドユーザ視点の説明が少なく、どうやってシステムを bootstrap するか、マシンを足す時はどうやるかなど運用の目線もなく、実装する人の観点だけで書かれているからだろう。それは正しい想定読者だと思うけど、もうちょっとファンサービスがあってもいいのではないか。そのうち tech talk のひとつもやってほしいもんです。

後半の Lessons セクションを見ると, Borg のいまいちだったところは Kubernetes で直したと繰り返している。クラスタマネージャを勉強したくなったらむしろ Kubernetes について調べるほうがいいのかもしれない。まあ Borg みたいにチューニングされまくってはいないだろうけれど、コードやマニュアルが読めるぶんよい。気がする。ちなみに Mesos paper はもうちょっとフレンドリーだった記憶。

以下ランダムに面白かったこと:

エージェント(Borglet)が中央のサーバ(Borgmaster)に状態を報告するのではなく、Borgmaster が Borglet に状態を訊いて回る。そうやってスパイクを避けているという。なるほど。
名前解決のサービス (BNS) がついている。どの物理マシンにジョブが割り振られてもこの名前で引ける。名前サービスは別なのかとおもってたら Borg の一部だったのか。
ユーザ毎の資源はクオータで制限しており、クオータ割り当てはシステムの外で決めている。そもそも他の方法があるのだろうかとおもったが、理論的にはなんかあるっぽい。
Compressible な資源 (CPU や IO 帯域など)と Non-compressible な資源(メモリやディスク)を区別している。たしかにそういう区別は必要そう。
Preemption によって優先度の低いタスクは殺されることがある。殺されると pending queue にはいってやりなおし。「夜に流して帰った Map Reduce が朝来たら死んでた…」みたいなぼやきをたまに聞いたのを思い出す。これだったか。ハードウェアの故障以前にスケジューラが殺しに来るんじゃ idempotent に作らないとどうにもならないね。むしろこの荒々しい世界で Map Reduce を使わずバッチの何かを書くのは大変そう。
資源の割り当て設定を変えるとデプロイしなおし。資源をインクリメンタルに要求できる普通の OS とは違う。Mesos はインクリメンタルに要求できた気がする。まあフレームワークという巨大な単位相手にリソースを割り振るからだろうけど。
Borg 対応バイナリには HTTP サーバが入ってる。便利そう。
同じマシンで動かしたい job を指定するには Allocs という仕組みを使う。仮想 job みたいなもんか.

Related work のセクションでは色々な会社の似たようなシステムが紹介されている。YARN, Mesos, Aurora は聞いたことがあったけれど、Facebook の Tupperware やら Alibaba の Fuxi やらはまったく知らなかった。Facebook ウォッチャーを気取っていたけど未熟であった。そろそろ Uber ウォッチャーに宗旨替えすべきか・・・。

数年前 Twitter 開催の tech talk で Mesos の話を聞いた時、講演者は Mesos のことを “Google の Borg みたいなもんです” と説明していた。元 Google 社員が蔓延するベイエリアのテック企業では Borg の存在は公然の秘密になっており、でかい会社は結局どこも似たようなものを持っているのだなあと思ったのだった。

Twitter といえば、かの社で SRE(Ops) をやってる人が Borg は動きが予測できなくて辛い、Mesos のほうがわかりやすくてよい、というようなことを以前書いていた。どうなんだろうね。最近 Twitter は MySQL-Mesos インテグレーションを Mysos という名前で発表している。ちゃんとつかってるぽい。

オープンソース好きとしては Kubernetes と Mesos を応援していきたい。といっても一個人にはまったく使い道がない。掛け声だけ。

書き直さない時代の気分

Mon, 13 Apr 2015 00:00:00 +0000

なんとなく続き。(前回)

Martin Fowler が蒸し返すまで、自分は書き直しについてことさら何か書く気が起きなかった。どうでもよさは時がたつほど増していった。気分の出処を見直してみたい。

部分的に書き直す

最初の理由は、書き直しがゼロかイチかの大きな判断ではないという納得かもしれない。コードの書き換えには様々な粒度がある。一番小さいのが厳密なリファクタリング。一番大きいのがフルスクラッチの書き直し。その間には様々な大きさの書き直しがある。書き直しの粒度が連続的である以上、どちらか一端を擁護する議論は虚しい。

小さい刻みの変更を積み重ねれば危険を冒さず大きな変更ができる。それがリファクタリングのテネットだ。刻みは小さいほど安全だから、良いプログラマは大きな変更を連続した小さい変更へと噛み砕く。変更の難しさに実力が及ばないと刻みが大きくなり失敗の危険が増す。バグが増えたり納期に遅れたりする。

自分の能力を超えた変更を求められることはある。仕方なく刻みを緩める。とはいえ全開のフルスクラッチまで緩め切ることはない。大半は部分的な、たとえばモジュール単位の、書き直しで事足りる。まず書き換えるモジュールをくくり出すところから始めることもよくある。Microservices だってそんなかんじでプロセスを切り離すでしょ。たぶん。

一見フルスクラッチを避けがたい場面ですら、十分な(あるいは例外的な)能力をもってすれば安全に大きな変更をやりとげられる。Russ Cox の異言語間 Go コンパイラ移植はその極端な例。わかりやすい「細かい変更」の集合ではないけれど、変換を通すための小細工を山ほど積み重ねたはず。

反対から見れば、変更の難しさから技量を差し引き足が出た分を危うい資金で補填するのが粒度の大きい書き直しだとも言える。

互換性を諦める

もう一つの理由は、互換性への期待が変わったことだろうか。フルスクラッチな書き直しへの批判は、書き直された新版が旧版と互換性を保つ難しさを論拠の一つにしている。一方で多くのソフトウェアは互換性を捨てながら前に進んでいる。API は deprecate される。刷新された UI からは不人気な機能が姿を消す。ウェブ標準ですら古い API のうち評判が悪かったものを取り下げている。この非互換は書き直しのバグではなく意思決定の結果だ。意図した互換性の破棄は前もってわかる。だからランダムに壊れるフルスクラッチの非互換よりだいぶマシ。

互換性を損ねると決めた途端、書き直しは楽になる。決めた範囲で互換性を壊しつつ新しい方向に進めばいい。自暴自棄のフルスクラッチに走りたい衝動は遠ざかる。

Windows 10 に載る新しいウェブブラウザのレンダリングエンジン Edge は、古いエンジン Trident をフォークしたものだ。フルスクラッチの書き直しではない。けれどその違いは既に WebKit と Blink より大きいという。Edge は近代的なウェブでの競争力を理由に IE との互換性を捨てると決め、大きな書き直しの扉を開けた。IE の足を引っぱっていたのはひどいコードでなく互換性の鎖だった。

まあコードもひどかったに違いないけれど、それだけが相手ならプログラマの力量でなんとかできる。Microsoft にプログラマ不足の心配はなかろう。

世紀末の悲鳴

書き直しの切り口はいくらでもあるし、必要なら互換性を切り崩してもいい。フルスクラッチでの書き直しを強行する理由を自分はもはや見出せない。けれど 15 年前に Joel Spolsky が書き直しは悪と書いた時、それは人々の心に響いた。なぜか。西暦 2000 年と今は何が違うのか。

槍玉にあげられたソフトウェアの一つは、奇しくもまたウェブブラウザ。Netscape の失敗を Joel は批判した。Netscape はその後 IE に負け AOL に買収されてしまったわけだから、この書き直しを失敗とみなすのは的外れでもない。今だったら「フルスクラッチで書き直しとかあいつら狂ってるな・・・」で終わる話。けれどたしかに 15 年前、フルスクラッチの書き直しはよくある話だった気がする。

書籍 Refactoring の出版が 1999 年。等価書き換え健康パズルのアイデアは今ほど浸透していなかった。コードは少しずつ腐っていくもの。腐敗を遅らせるのがせいぜい。ソフトウェアのリリースも今よりずっと離散的で、オートアップデートなんてなかった。だから仮に少しずつコードを直せても、それを撒いて試すのは難しかった。人々は健全性を取り戻す術をフルスクラッチ以外に持っていなかったのかもしれない。

一方、ソフトウェアの互換性に対する期待は今よりずっと高かった。それはたぶん Microsoft が持ち込んだゲームのルールだった。彼らは互換性のために莫大な工学資本をつぎ込んで高いバーを設けた。ウェブの時代がそれを塗り替えるまで、互換性への期待はソフトウェアの前に立ちふさがっていた。「同じものは壊れない」というユーザの期待が「まったく新しい何か」へと開発者を追い込み、結果として「すっかり壊れた何か」を生み出し破滅を招いた。

15 年前、ソフトウェア開発者は少しずつ直すことを知らず、少しだけ壊すこともできなかった。フルスクラッチの決断は板挟みになった開発者の悲鳴だった。だいぶ単純化してるけど、時代の空気はそんな風だった気がする。

そして今。書き直しは多くの変数を持つ入り組んだトレードオフに姿を変えた。もはやフルスクラッチの書き直しでわざわざ自分の稼ぎ口をふいにするがさつな開発者はそういるまい。Sacrificed Architecture も全てをゼロから書き直せとは言わない。

時代が変わり、書き直しに関する議論はかつての意味を失った。自分の興味も遠のいた。けれどその一方、誰かが書き直しについて話すのを聞くと私は落ち着かない気持ちになる。意味がないのに落ち着かない。この矛盾がどこから来るのかと考える。一つの理由は、私がまだ時代の変化を自分のものにできていないからかもしれない。古い価値観の染みはなかなか落ちない。

たまにはフルスクラッチもいいじゃん、という話を書こうと思ってたのにまた長くなりすぎて尻切れ・・・。

確率的に犠牲的

Thu, 09 Apr 2015 00:00:00 +0000

Martin Fowler が Sacrificial Architecture と言い出した時は驚いた。”変化を受け入れよ” はどこにいったの。書き直しはダメと自分の中の結論が出たのは随分前のことだけれど、ひさしぶりに考え直してみる。

Sacrificial Architecture の論拠として Martin Fowler はいくつかのインターネッツ企業を例にとっている。でも一般化するには偏ってないか。それにこれら企業が面していたのはごく限られた種類の変化だ: 彼らはもっぱら性能不足と戦っていた。

機能の変化に強いコードは柔軟性の裏で性能を犠牲にしがち。機能の変化を捉えることに先鋭化した従来の Agility は性能要件の変化を必ずしもやり過ごせない。一方で存在感を増すスタートアップの世界では性能への期待が当たり前のように大きく変わる。だから Agile はあてにならない、堅牢なアーキテクチャで急成長に備えよ。そう訴えて勢いづく BDUF Microservices 勢を威嚇すべく Sacrificial Architecture は生まれた。でも行き過ぎた一般化に拡大解釈が加わり技術的負債を自己破産する言い訳として流布してしまった。誤解されても無理はない名前だ。焦って口が滑ったな。

性能に対する法外な期待に応えるには書き直しが必要かもしれない。これは妥当な意見に思える。それに別の見方もできる: 性能が追いつかないほどビジネスが急成長しているときは、勢いに乗って書き直しても元がとれる。性能不足は好調さのあらわれ。無理をしてでもこの勢いを逃したくない。機会損失が書き直しの危険を上塗りする。

一方、古き良きダメな書き直しは機能の変化や複雑化に音を上げておこる。この書き直しは何がまずいか。

別の角度から眺める。ソフトウェアの方向性を大きく変えたいとき、あるいは機能をやたらと追加したいとき、だいたいビジネスは失速している。行き詰まりを打破しようと方向転換や守備範囲の拡大を図っている。この投機的な場面で更に書き直しの博打を打つのは雪解けの薄氷で踊るようなもの。危険に見合う期待値がない。

Martin Fowler はこう言うべきだった: ソフトウェアは確率的に sacrificial である。どんなソフトウェアも連続した打ち手では乗り切れない急激な変化に襲われる可能性を孕んでいる。特に成功したインターネット企業では成長という大波が性能上の限界にコードを打ち付ける。けれど波の狭間に新大陸の影が見えていたら? 賭けに出よう。その愛するコードを生贄に…

こうして犠牲となってしまうコードはある。でもそのためのアーキテクチャなんてない。やっぱり失言だな。

拡大解釈された Sacrificial Architecture もけっこう人気がある: スピードのためにひどいコードを書き、うまくいって長期的展望がもてた頃合いでゴミを捨て書き直す。このアイデアは妥当か。うまくいくこともあるだろう。性能だけが書き直しを正当化するとは言わない。でも Martin Fowler 名義でそれを語るのはやめてあげたい。傷に塩塗るみたいで気の毒。例に挙げるのも別の何かにした方がいい。個人的には Windows NT あたりを推したい。人生を書き換えるアーキテクチャとでも呼ぼう。

書きたいことは別にあったけど長くなったので一旦おしまい。

Web Push Protocol

Wed, 08 Apr 2015 00:00:00 +0000

“Generic Event Delivery Using HTTP Push” なる RFC を知った。 JavaScript の Push API をネットワークレベルでどう実現するか決めるものらしい。 Push API, システムが提供する GCM なんかのラッパーだと思い込んでいた。 Chrome の現状はそのようだけど、標準的にはスタック全体を定義しようとしている模様。仕様を書いているのは Mozilla の人。えらい。

Web Push は HTTP/2 の上に定義されており、PUSH_PROMISE で UA にメッセージを送る。 TCP で現実的なプッシュを作れるとは思っていなかったので驚いた。ざっと調べてみたところ GCM も TCP ベースらしい。接続を保つべく適当な間隔で heartbeat していると、世間の資料にはある。 SMS など cell network の技術は使わないのか。もっとも Wi-Fi だけでも動かす手前 TCP 頼みは仕方がない? よくわからないな。 Web Push の仕様は SMS を使うなど適当な方法でそれらモニタリングを置き換えて良いと断っている。

PUSH_PROMISE 以外で面白いところ: 個々のメッセージは URL を持たない。 URL は Subscription 単位(=UA 単位)で割り振られる。メッセージの到達も保証しない。適当に expire するのでアプリケーションはメッセージがドロップされてもちゃんと動くように書けと注意している。トランザクションとか言い出さないあたり、地に足が付いている。好感。 Heartbeat の方法も指示しない。HTTP/2 の PING を使えということだろう。下にあるプロトコルの出来が良いとラクだ。

Web Push をブラウザの外、たとえばサーバ間、あるいはデスクトップアプリで使うのはどうか。 XMPP でいい気もすれど、セマンティクスの違いや単純さから Web Push を選ぶのもそれはそれで悪くないかも。 ACK がないとだめかな。あとは GCM の代替実装としてフルスタックを揃えると Cyanogen などの Forked Android 勢に喜ばれるかもしれない。HTTP/2 実装の普及が待たれる。

Funemployment

Thu, 02 Apr 2015 00:00:00 +0000

“A beginner’s guide to funemployment” を読んで Funemployment という言葉を知った。満足に楽しくやってる無職を指す言葉らしい。

Urban dictionary に登録されたのは 2004 年。 Google Trend によれば 2009 年に盛り上がり、今日までゆっくりと滑空を続けている。2009 年といえばサブプライム危機で大きな不況があった年。当時の記事では不況の煽りでレイオフされた若者がいい機会だからと funemployed を自称し、仕事をさがすかわりに楽しくフラフラしている様が描かれている。強がりのような楽観のような、アメリカ的いいかげんさが眩しい。いま流行が下火なのは好景気の裏返しだろう。

私の知り合いには現役フルタイムを含め funemployment 経験者が一定数いる。羨望の眼差しで体験談に聞き入ったのを思い出す。彼らは自分を無職や NEET と呼ぶ。間違ってはいないが、言葉の示唆する悲壮感を逆手にとる感じの悪さが鼻についた。まあ完全に労働者の僻みなんだけど、彼らが funemployed を名乗っていたら手放しで羨ましがってあげられたかもしれない。私もときどき無職になりたいと呟いてしまうことがある。このとき求めているのは funemployment であって失業ではない。身勝手な願望に名前がついてよかった。Sabbatical と呼ぶ人もいる。でも funemployed の方がポップ。日本語だと “有閑無職” くらいだろうか。いずれにせよ謙遜よりも強がり相手のほうが付き合いやすい。

冒頭の記事も認めるとおり, funemployment はどこか特権的だ。最終的にはなんとかできる自負があるからこそ楽しさを見いだせる。不景気だった 2009 年の funemployment は強がりだったかもしれない。でもいま funemployed になるプログラマは余裕があるにちがいない。余裕の裏付けは若さかもしれないし、高い技能かもしれないし、金銭的なゆとりかもしれない。自国経済への信頼かもしれないし、性格からくる楽観かもしれない。私の目にはどれも手の届かない贅沢に映る。

だから仕事のない優雅な日々を満喫されている諸兄は無職や NEET を気取らず胸を張って funemployed を名乗り、素直に身分を羨ましがらせてほしい。明日も仕事の会社員はそうおもう次第。おまえらが無印無職を連呼するのはほんとに、むかつく。いいなあ。

生焼け週報

Tue, 31 Mar 2015 00:00:00 +0000

Hugo への乗り換えに伴い blog の書き方も変えてみようと思う。具体的には頻度を上げて一回あたりの分量を短くしたい。この数年来の願いは放っておいても叶う様子がない。数値目標をたてよう: 今四半期、毎週一度は何か書く。さっそく水曜日にカレンダーを登録した。

短い間隔で短く書くと何が起こるか？文章はいいかげんになるだろう。調べ物も深入りはしないだろう。考えは生煮えが増えるだろう。それはよいのか？わからない。いまいちだったらごめんなさい。

このごろ文章を書くことについてよく考えている。その果てに書くとは自分のための読み物を用意するプロセスだと見なすようになった。自炊に近い。炊事に楽しさがあるように、書くこと自体にも楽しみはある。でも根底にはあるのは書いたものを読む満足だと思う。料理をつくるのも、結局は食べたいからだからね。私の場合。

自分で読むだけなら公開することもないかなと、しばらく Evernote に書き溜めたり閉じたメディアに書いたりもしてみた。それほど悪くもなかったけれど、どこか物足りない。虚栄心のスパイスが恋しくなる。

炊事のメタファをもてあそぶうちに気付いた: 長い文章ばかりを断続的に書くのは、ホームパーティのバーベキューで肉を焼くときしか料理をしないおっさんみたいなものだ。健康的とはいえない。毎日は無理にしても日頃から台所に立ち、外食では不足しがちな材料や調味料を煮炊きしたい。不慣れからくる生煮えも手を動かすうちに姿を消すだろう。体脂肪も落ちるだろう。

そんな期待で週刊発行を目指す所存でございます。でも思いつきなので挫けたらやめます。

Travis からのアップロード

Fri, 27 Mar 2015 00:00:00 +0000

Static site generators は Travis でアップロードするのが楽らしい。試し中。 Travis は AWS で動いているため GitHub (これもいろいろ AWS にある)のダウンロードが速い。 Hugo の速さと相まってあっという間・・・とおもいきや S3 に push するツール awscli のインストールがボトルネック。 Travis いわく所要時間 11 秒. 体感は 30 秒くらい。 Go で書かれた awscli 相当のツールがあるといいのだけれど。

GitHub の Web から更新できるのは良い。これがしたかった。もうちょっと使いやすいエディタがほしい。 Dillinger はいまいち。当面は Evernote で下書きしたのをコピペしよう。

花の名前

Fri, 20 Mar 2015 22:07:09 -0700

Octopress の遅さに疲れていたら Hugo が良いと教わった。たしかに速い。インストールが楽なのもいい。CSS プリプロセサがないのは残念。テーマは Vienna をいじって使おう。

プラグインなどの都合で Markdown を移すのは諦め、新しいサブドメインを使うことにした。西暦を入れる 8-p.info 方式よりも arbitrary であろうと A から順に花の名前をつけてみる。まずは anemone.dodgson.org から。フィードの URL が変わらなければいいよね。

表紙画像も前と同じ。

バックナンバー

Thu, 19 Mar 2015 00:00:00 +0000

過去の記事は:

http://steps.dodgson.org/blog/archives/ および
http://steps.dodgson.org/bn/

からアクセスできます。