Latest topics 近況報告
たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。
の動向はもえじら組ブログで。
宣伝。日経LinuxにてLinuxの基礎？を紹介する漫画「シス管系女子」を連載させていただいています。
以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能！
setTabState()を使わないでタブのサスペンドと復元をやる実装のサンプル - Apr 25, 2012
ツリー型タブに「バックグラウンドにあるタブをアンロードする機能を付けてくれ」って要望が来てて、そんなもんDormancyやらBarTabやらSaveMemoryやらUnloadTabやらなんぼでもあるがな、と思ったんだけど調べてみたらツリー型タブと併用できなかったり（Dormancy, UnloadTab）併用できても今のFirefoxで動かなくなってて開発止まってたり（BarTab）併用できないわ開発止まってるわだったり（SaveMemory）と軒並み全滅だった。
そもそもこの手の奴がなんでツリー型タブと併用できないのかっていうと、
- ツリー型タブは、ツリー構造の情報をタブのセッション情報の一部として保存している。
- タブをアンロードする系のアドオンは、セッションストアAPIを使って
getTabState()でタブの現在のセッション情報を吸い出した後、タブを閉じて、新しい空のタブを開いて、そのタブが選択された時にさっき吸い出したセッション情報をsetTabState()で適用する、という事をしている。
ということで、アンロードする系のアドオンが元のタブを閉じてしまうからツリー構造が破壊されてしまうわけです。BarTabは互換性のためにツリー型タブのAPIを呼んでツリー構造をわざわざ復元するようにしてくれてたから併用できてただけで、本質的にはやっぱり相性が悪い。
っていうかべつに元のタブを閉じる必要なんてなくね？ nsISHistoryのPurgeHistory()でセッションヒストリを空にするだけやったらあかんの？ あと状態を復元する時もタブの属性とかまで含めて全部上書きせんでもいくない？ と思って、「アンロードする時はセッションヒストリを消すだけ」「復元する時はセッションヒストリを復元するだけ」という実装のサンプルを作ってみた。
めんどくさかったから、nsSessionStore.jsをそのまま読み込んで流用するという乱暴なことをやってる。
これに「何分以上放置したら勝手にアンロード」「タブが選択されたら復元」みたいな事を加えればDormancyとかBarTabとかの代替になるんだろうけど、これ以上管理対象のアドオンを増やすのもイヤだし、かといってDormancy等にそのまま取り込んでもらえるとも思えないし（やり方があまりにダーティすぎて、開発の継続性を低下させてしまうだろうし、そもそも現状で困ってるのなんてツリー型タブのユーザくらいだろうし……）、どうしたもんでしょうかね。
……とかいってたんだけど結局真面目に作り始めてしまった。30分以上放置してたら勝手にアンロードするとかその程度の事はとりあえずできるようになってはいる。
Fox Splitterを更新した - Apr 23, 2012
バージョン0.6系（旧版）と2.x系（現行バージョン）の両方とも更新した。
バージョン0.6系の方は、前に書いた2.x系への自動アップデート機能の追加だけで、他は何もいじってない。AMOからインストールした人が2.x系に自動アップデートされないという問題への対処のためだけに作ったバージョンなので、AMOにしかアップロードしてない。基本的にこっちはもう終了したバージョンということでよろしく。
2.x系の方は、最近になってUbuntu上でヘビーに常用し始めるようになって色々気付いた問題を修正したのと、僕の使い方で「ああこういう機能欲しいやばい（ないとめんどい）」と思った機能を追加した。
修正の方で特に大きいのは、「グループ化されたウィンドウの1つを移動した後に他のウィンドウをそれに併せて移動する」という部分の改善だと思う。
GNOME2のワークスペース切り替えの時はそこまで酷いことになってなかったんだけど、Ubuntu 11.10にアップデートして3×3のワークスペースを使うようにし始めた（これ多分GNOME3の機能ですよね？）ところ、全く使い物にならないレベルでグループの配置が壊れるようになってしまった。GNOMEのワークスペース切り替えは、少なくともFirefoxの中から見た時には、各ウィンドウの座標を固定してビューポートの方だけを移動させるんじゃなくて、ビューポートの座標の方を固定して全部のウィンドウの座標をぐりぐり動かしているように検知されている。なので、ワークスペース切り替えの時に全部のウィンドウのscreenX/screenYの値が変わってしまう。それで、それぞれのウィンドウがてんでバラバラに「グループの中のウィンドウが1個動かされたから他のウィンドウも再配置しよう」という事を始めてしまってシッチャカメッチャカになっていた。
「グループ化されたウィンドウ全部が相対座標を保ったまま一度に移動されたので、再配置の必要なし」とかの判断をちゃんとするようにすればよかったんだけど、僕の頭で思いつくやり方だとどーにもうまくいかんかったので、諦めて安全確実だけどちょっと重い方法でウィンドウの移動→グループ全体の再配置を行うようにした。普通にウィンドウをドラッグで移動した時とかのレスポンスは悪くなったんじゃないかと思うけど、背に腹は代えられない。
新機能は、「グループ化されたウィンドウの1つでPanoramaを使った時に、グループ全体の大きさまでそのウィンドウを一時的に広げる」という機能が元々あったのを、Panoramaの時以外にも使えるようにした（ついでに、詰めが甘かった所を色々直した）という物。何でこういう物が欲しかったかというと、
- 僕は今Ubuntuのワークスペースの1つをFox Splitterで3分割したFirefoxのウィンドウ専用に割り当てている。
- 分割後のそれぞれのウィンドウには、別々のプロジェクトのRedmineのチケット一覧を表示している。
- それぞれのプロジェクトでチケットを追加する時は、その分割されたウィンドウの中でやっている。
- Redmineはある程度の大きさのウィンドウで表示される前提でレイアウトが組まれているので、狭いウィンドウの中では非常に使いにくい。
- なので、チケットを書いたり詳細を読んだりするときだけそのウィンドウを大きくして、終わったら元の大きさに戻す（そうしないと他のウィンドウのRedmineが見えないから）という事をよくやっていた。
という使い方をしていて、いいかげんいちいち自分でリサイズするのが面倒になったから。
今のFox Splitterは、全体を管理する大きなウィンドウのような実体が無い状態で各ウィンドウをあたかも1つのグループの下に属しているかのように協調して動作させる、ということをやっていて、作ってる側の自分としては、頭を抱える部分も多いけれども「元々Firefoxにある物だけを駆使してどこまでできるか？」ということを追及するある種の挑戦というかパズルに挑んでいるような感覚もあって、そういうことを効率よくやるためには結局2分木でやるのが安全確実なんだなあとか色々と気付かされた所があって、ノウハウ的にも自分のやってきたことの集大成になってるんだけど、エンドユーザとしての使い勝手は多分旧版のFox Splitterに比べると劣化してると受け取られることの方が多そうで、報われないことに一生懸命になってるなー感が自分である。
とはいっても、自分で使う分にはとりあえずこれだけ動いてくれれば十分だし、旧版の設計で今後もずっと自分でメンテナンスし続けるのは絶対に無理だし、もっといいやり方が見つかるまでは、この路線を変えることは多分無いと思う。
シス管系女子 第9話「コマンド履歴をもっと使おう」 - Apr 09, 2012
表紙にも載ってなくてあんまり存在を知られてないっていうか忘れられてるくさいので、マメに宣伝していこうと思います……
Linuxの主にコマンドライン関係のTips、小ネタ、豆知識をゆるゆると紹介・解説するマンガの「シス管系女子」をこっそり連載中の日経Linux 5月号が発売されました。
今回は前回に引き続き、Bashのコマンド履歴の話です。
ところでバックナンバーを見返していて気付いたのですが、他のライターの方にもご覧頂けているようで、確か3月号か4月号の記事でtmuxの紹介の回に言及していただけてました。こういうのは素直に嬉しいですね。
Ez Sidebarを数年ぶりに更新した - Apr 07, 2012
bit.ly/I4YzVe bit.ly/I4YAbC Ez SidebarのFirefox 11対応は僕の手では不可能だけど、技術的には出来そうということは調べはついたので誰かやってください。
— Piroさん (@piro_or) 4月 5, 2012とかなんとか発言した舌の根も乾かないうちにEz Sidebar 4.0.2012040701を公開した。実験的にやってみたら案外あっさりできたので、その勢いで完成まで一気に。実質的にほぼ0からのスクラッチで、基本設計が全く別物になっていてコードの共有部分はほとんど無い。
旧版ではサイドバー用のウィンドウを物理的に（DOMツリー的に）別ウィンドウとして開いていて、パネル内のスクリプトに対してどうやってブラウザウィンドウの中にあるように見せるかという所が技術的な鍵だった。例えばwindow.parent.gBrowserにアクセスされたら、最も手前にあるブラウザウィンドウを探してきてそのgBrowserを返す、みたいな感じで。そういう強引なことをやってたから、つくづく、よくあんなんで動いてたなという感じだ。
今回の再実装では、根本的な考え方は至極単純で、ウィンドウの内容が初期化されるタイミングで<panel>の中にサイドバーのボックスを丸ごと移動して、以後はその<panel>を「別ウィンドウに切り離されたサイドバー」として表示している。これだとサイドバーは相変わらず元のウィンドウのDOMツリーの中に存在しているから、パネル内のスクリプトから見た時に普通に親のフレームとしてFirefoxのウィンドウにアクセスできるし、Firefoxのウィンドウの側からもパネルの内容を普通にサブフレームとして認識できる。Firefoxのウィンドウが複数ある時は最前面のウィンドウの<panel>だけを表示しておき、ウィンドウが切り替わったタイミングで同じ位置・同じ大きさに<panel>を表示する、という事をやってるので、見た目的には1つの<panel>が個々のFirefoxのウィンドウとは独立して存在しているように見えなくもない。他にも、ドラッグ操作での移動とかリサイズとか、ただの<panel>をウィンドウっぽく動かすために細かい所で違和感が出ないように色々やってる。
何故旧版では<panel>を使わなかったのかというと、やりたくてもやれなかったんですよ。サイドバーは一種のインラインフレームなんだけど、確か昔は<panel>の中にインラインフレームを置くとまともに動作しなかったと思う。そういう細かい技術的な障壁が当時は色々あって、Ez Sidebarのような事をどうしてもやりたいとなると、旧版のようにダーティなハックをたくさん仕込まないといけなかった。それが今では、「こう書いたらこう動いて欲しいよね」という書き方をすればだいたいフツーに動いてくれるわけですよ。隔世の感だ。
あと、バージョン3.2（1つ前のバージョン）にあった機能を全部引き継いでるわけではなくて、というかサイドバーをメインウィンドウから切り離して表示する機能以外は全部バッサリ切り捨てた。All-in-One Sidebarのような有名所のアドオンが既にそういう機能を持ってるみたいだから、わざわざ同じ機能を作らなくても、そっち使えばいいじゃんという話です。Ez Sidebarは、他のアドオンが提供してくれない機能だけに絞って提供した方が意義があるはず……と思って。
過去にこのアドオンの名前を「Sidebar Window」から「Ez Sidebar」に変えたのは、サイドバーの切り離し以外の機能も色々付けたからだったんだけど、今回のリリースで機能的には最初の物より低機能な所に逆戻りしてしまった。皮肉な結果だ。
Fox SplitterのせいでユーザのFirefox 3.6からの移行が進まないって言われた件 - Apr 02, 2012
Linuxでwmctrlを使うようにしたバージョンのFox Splitterを今日付で公開した。
なんだかんだで最近腰が重いんだけどその重い腰を上げてリリースのための作業をやろうと思った背景の1つには、Mozillaの中の人からメールで表題の件について連絡があったからだ。既知のバグがあってmasterでは直ってるのにリリースされていない、という状況ではそのメールに返信するのが憚られる……と思って、慌てて細かい所を直してリリースしたというわけ。これも罪悪感駆動開発な気がする。
Fox Splitterのユーザが古いバージョンを使い続けている最大の理由は、AMOでFox Splitter 0.xから2.0への自動アップデートが行われないからじゃないかと思ってる。諸々の事情でFox Splitter 2.0では旧版からアドオンのIDを変えないといけなかったので、AMOのサイト上ではFox Splitter 2.0と0.xが別々のアドオンとして登録されてて、Fox Splitter 0.xのユーザにはFox Splitter 2.0が自動アップデート経由で提供されない。2.0への移行は、完全にユーザの自由意志に任せざるを得ないという事になっている。使い勝手がどうとか以前に、勝手にアップデートが下りてくるかこないかがネックになってるっていう予想だ。
強権的手段として、「単にFox Splitter 2.0を自動的にインストールして、その後Fox Splitter 0.xを削除する」というだけの内容のアドオンをFox Splitter 0.x最新版としてアップロードすれば、Fox Splitter 0.xから2.0への移行を強制することはできるけど……2.0の方には否定的なレビューが多く付いていて評価も低い（旧版は星2つ以下は15％なのに対し、新版は星2つ以下が57％……まあ母数が圧倒的に少ないから統計的にはあんまり意味がないかもなんだけど）という現状を見ると、そこまでやっちゃっていいっていう自信をまだ持てずにいる。
4月4日追記。Mozillaの中の人から「ちょうどそういう（Fox Splitter 0.x系の新バージョンとして、Fox Splitter 2への自動アップデート機能を含んだ物をリリースするという）方法について提案しようと思ってた所だった」的なレスポンスがあったので、春の嵐で早退したのをいいことに頑張って書いてみたんだけど、死ぬほどめんどかった。
Fox SplitterのLinuxでの挙動の改善と、Mac OS Xで残された課題 - Mar 25, 2012
Fox SplitterをWindows以外で使った時に 実にパネェ感じでストレスフルな挙動を示す件について、とりあえずLinuxではちょっとだけ改善できた気がする。
要点を先にまとめておくと、こういうことだ。
- Windows上では以前から、ウィンドウの1つが選択されて最前面に来たら、グループ化された他のウィンドウもそれによって「押し上げられ」て最前面に来る、という挙動になっていた。
- でもFirefoxの仕様上の制限で、LinuxとMac OS Xではそれができていなかった。
- 今回、Linuxではwmctrlを呼び出すことによってWindows上と同じような挙動を再現できるようになった。
- Mac OS Xで同じ事ができるのかどうかは分からないままである。
- JSDeferredはやっぱり素晴らしいです。
以下、背景も含めた詳しい話。
文字入力中に補助的な情報や機能をポップアップとして表示するとキャレットが消えてしまう件について分かったこと - Mar 10, 2012
先に要点だけ書いておくと、文字入力中にXULのmenupopupで補助的な情報や機能を表示したい時は、openPopupAtScreen()やopenPopup()の引数で明示的にコンテキストメニューであると指定してポップアップを開くようにすると、キャレットが消えなくなります（あくまでworkaround。根本的な解決策とは言えない）。それか、menupopupの代わりにtooltipやpanelを使うようにするというのも、キャレットを消えなくする方法として有効のようです。という話。以下は、そこに辿り着くまでの間に何を調べたかという事の記録です。
FirefoxやThunderbirdを必ずクラッシュさせるコード - Mar 02, 2012
クラッシュレポーターの挙動を調べたい時に。以下のコードを改行無しでエラーコンソールあたりで実行すれば一発で落ちる。
Components.utils.import('resource://gre/modules/ctypes.jsm');
const gNspr4 = ctypes.open(ctypes.libraryName('nspr4'));
const PR_Free = gNspr4.declare(
'PR_Free',
ctypes.default_abi,
ctypes.void_t,
ctypes.voidptr_t
);
var ptr = new ctypes.voidptr_t(0123);
PR_Free(ptr);要は、js-ctypesを使って適当なアドレスのメモリを解放してメモリ破壊を引き起こしてみるということで。
破壊するアドレスによってはひょっとしたらどえらいことになるかもしれないので、試す時は自己責任でね！
なんか誤解してる人がいるかもなので追記しておく。
このコードはjs-ctypes（JavaScriptからC製のライブラリを呼び出す機能）を使っていて、NSPRというFirefoxやThunderbirdのかなり根っこの方のライブラリに含まれてるメモリ操作系の関数を呼び出して意図的にメモリ破壊を引き起こすという例です。クラッシュして欲しくないコードでクラッシュしてしまうという脆弱性系の話ではありません。
でもって、js-ctypesはChrome権限が無いと使えません。言い換えると、Chrome権限を取られてしまうような脆弱性を突かれない限りこのようなコードはWeb上にある普通のスクリプトからは実行できないし、Chrome権限を取られてる（アドオンの一部として実行されている）状況ではクラッシュどころかパスワードマネージャに入ってるパスワードのぶっこぬきでも何でもやり放題だから、むしろその事（特権を取られてるという事）自体の方が問題です。
仕事でFirefoxの導入案件をやる時に、クラッシュレポーターを無効化してくれと言われて無効化したつもりだけど、ほんとに無効化されてるかどうか確認したかった、でも最近のFirefoxはわりかし安定してるからそう簡単にはクラッシュしてくれない、ハードウェアアクセラレーション系の機能あたりを使ってクラッシュするのを気長に待つわけにもいかない、ということでこういうコードを使って手っ取り早くクラッシュさせてみた……というだけの話ですよ。
tabFx2Compatible.xul、tabFx2Compatible.css、tabFx2Compatible.xmlを使わないようにした - Feb 09, 2012
ツリー型タブ、情報化タブの今日付でのリリース分から、tabFx2Compatibleという自作のライブラリ（？）を使わないようにした。当初はマルチプルタブハンドラでも使ってたけど、ツリー型タブ・情報化タブに先駆けて一足先に使わないようにしていた。今回残りの2つでも利用をやめたことで、TBEやり直し組のアドオンからはこのライブラリが全く姿を消したことになる。作ったのが2008年の2月からだから、丸4年くらいは使ってたのか。
このライブラリは元々、Firefox 3での仕様変更に追従するために仕方なく作った物だった。
Firefox 2ではタブの中に任意の要素（サムネイル描画用のcanvasだったりカウンタ表示用のlabelだったり）をXBLのコンテナ要素を使って動的に追加できていた。しかしFirefox 3になる時、具体的には2007年の12月頃に、高速化のためにそういう冗長性を排除する変更が行われてしまって、JavaScriptで動的にタブの内容を追加するということが原理上不可能になってしまった。
正確には、方法はあった。Firefox本体がタブに適用していたXBLによるバインディングを独自のバインディングで置き換えて、それを使ってタブの内容を変更するというやり方だ。しかし、XBLのバインディングは同時に1個だけしか適用できないという制限がある。複数のアドオンが同じ事をやろうとしたら、結局どれか1つのアドオンしかまともに動かないという事になってしまう。他の人の作る物との互換性という話に限らず、リッチでファットなAll-in-One型のアドオンであったTBEを捨てて各機能ごとに個別のアドオンに開発し直す道を選んでいた僕にとっては、自分の手がける物同士の互換性を維持するためにも、これは致命的な問題だった。
前述のライブラリは、特定のアドオンのために特化したバインディングを適用するのではなく、Firefox 2時代の「ある程度好きなようにタブの内容を増やせる余地がある」、冗長性を持った汎用的なバインディング定義を、Firefox 3向けに復活させるという物だった。
風向きが変わったのは2010年9月の事だった。Firefox 3.7のモックアップで示された視覚的なデザインを実現するために、タブのバインディングに再び冗長性が付与された。メジャーバージョンとしては、この変更はFirefox 4から反映されている。僕はこの仕様変更をうけてtabFx2Compatibleを改修し、Firefox 4以降のタブのバインディングの構造と、Firefox 2以前のタブのバインディングの構造の、両方を併せ持つ状態に変更した。
という経緯を見ると分かるかもだけど、このtabFx2Compatibleというライブラリは本質的に、Firefox 3.0から3.6までの間のバージョンに対応するためには欠かすことができなかった。ツリー型タブ等のアドオンの対応バージョン範囲の下限がこの範囲に重なっている間は、このライブラリは絶対に使う必要があったので、いくらTMPやVimperator等とバインディングの衝突の危険性があったとしても、構成ファイル群から外すことができなかった。
今回、Firefox 10のESR（延長サポート版）がリリースされたことにより正式にFirefox 3.6の死期が確定したので、サポート終了を待たずにFirefox 3.6のサポートを打ち切って、それと同時にtabFx2Compatibleも廃止することにした。レガシーなFirefox 2由来のDOMツリー構造を前提にして書かれたスクリプトやスタイルシート等を、全面的にFirefox 4以降の既定のDOMツリー構造に合わせて変更する作業は、それなりの手間を要したけれども、これでカビの生えた過去から決別できるのなら安い物だと思った。
選択肢の1つとして、tabFx2Compatibleを今後も使い続ける（Firefoxのタブのバインディングの構造が変わったら、その度にtabFx2Compatibleを更新していく）というやり方もあった。今この瞬間にかける労力を最小化する事を選ぶのなら、そういう選択もあり得たと思う。でも、tabFx2Compatibleは元々Firefox 3から3.6までの暗黒期を乗り越えるためだけに用意された物だったのだから、用済みになったのなら、思い切って捨てた方が今後のためになると思った。
こういう切り替えをできる時にやっておかないと、またTBEみたいな事になってしまう恐れがある。TBEでは、タブの移動等といった基本的な機能すらFirefox本体に備わっていなかった頃から開発していたため、TBE自身で独自の「タブを移動する」などのAPIを実装していた。そういう古いオレオレAPIから、Firefox 1.5くらいから新しくFirefox本体に備わったTabMoveとかのDOMイベントベースでのやり方にスイッチする事の手間を惜しんで、「とりあえず今動いてるから」と独自のオレオレAPIを維持することに固執してしまったがために、TBEはFirefox 1.5とともに時代に取り残され死んでしまった。そんな愚はもう繰り返してはいけない。
それにつけても、あの辺（Firefoxのタブまわり）の開発をやってる人達の意向に振り回されっぱなしだった4年間だったなー……と思うと、なんか感慨深い。
より良いコード - Feb 01, 2012
自分で自分の書くプログラムが（道具として使って目的を達成できるかどうかという評価ではなくて、プログラムコードそのもの綺麗さとかそういう意味で）良いかどうかっていうのは正直よくわかんない。もちろん「良いコードを書こう」と思って意識はしてはいるけど、他の人から見たら「全然駄目じゃん」って言われるんじゃないかって思ってる。ただ、それでも、過去（数年単位に限らず、下手したら数ヶ月単位で）の自分が書いたコードは確かに悪かったのだなということは、今なら分かる。
良くなってる点があるとしたら、一言で言うと、「独り善がりさが減った」って事なんじゃないかなーと思う。属人性が減って、普遍性が増したというか。
過去の僕は、今よりずっと多くの時間を趣味のコーディングに費やせていたし、作っていた物の規模も今より小さかった。だから、傍目にはスパゲッティコードにしか見えないようなコードであっても、その時の僕の頭の中にはプログラムの全体像が入っていて、問題があったらどこを直せば良いのか、新しい機能を付け加えるにはどこに手を入れればいいのか、把握できていたのだと思う。そういう状況では、モジュールの分割であるとか関数の分割であるとか変数・関数の命名であるとかに気を遣う必要性が薄いから、自分の頭の中にモヤモヤとあった物がそのまま形になったような、そういう物ができあがるんじゃないかと思う。
でも、作る物の規模がだんだん大きくなっていったり、抱え込む物の数が増えて関心があちこちに分散したりして、全てのプログラムの全体像を常時完全には把握しきれなくなってくると、だんだんボロが出始める。また、費やせる時間もだんだん減ってきて、力業でも補えなくなってくる。そうなってきて初めて、「良い設計」とか「良いコード」とかいうものが身に染みて分かってきた気がする。
それまでも一応知識として「どういう設計になってるのがいいのか」とかいう事は知っていたし、元々完璧主義者な所もあって、頭でっかちなりに「良い設計」とか「良いコード」とかいう事は考えてはいたと思うんだけれども、実感は伴ってなかったんじゃないだろうか。
最初は誰かの受け売りだった「1ヶ月後や1年後の自分が見ても分かるコードを書く」という方針は、そういう事があって、今自分の中に実感を持って染み着いている。初めてその言葉を聞いた時の僕にとっては、「1ヶ月後の自分」「1年後の自分」とは、「昨日も今日もその事に没頭し続けていて、そのように連続した開発が1ヶ月間、1年間と続いた先にいる自分」という意味にしか受け取れなかったと思う。だから「1ヶ月後の自分なんてもう完全に他人」なんて言われてもピンと来なかった。でも今はよくわかる。なんだかんだで時間を取れなかったりやる気を維持できなかったりして1ヶ月くらいプロジェクトから離れてしまうというのは、実によくある事なのだ。毎日毎日同じ好きな事ばかりやっていられるとは限らないのだ。そうして久しぶりに触れた時に愕然とするのだ。1ヶ月前の自分が何を考えていたのか、まるで思い出せないという事に。
ましてや本当に他人だったら、「思い出す」ための手がかりすら無い。他の人がやっているプロジェクトに共同開発者として参加したり、誰かからプロジェクトを引き継いだりした時に、独善的で属人的なコードがあるとどういう事になるか。複数人で1つの物を手がける時、将来的には誰かに引き継がなければならない物を作る時に、自分自身が何に気をつけなければいけないのか。
クラスやらモジュールやらが分けられているとか、名前空間がどうであるとか、関数が小さいとかコメントが豊富とか、そういう個別の「テクニック」が駆使されている「から」、「良いコード」である、という事ではない。毎日毎日「今の自分」のためにしかコードを書いていないような人間には欠けている、1ヶ月後の自分やあるいは全くの他人でもスムーズに開発を継続・継承できるような状態を保とう、自分という人間がいなくても勝手に生き残って生き続けてくれるようにしておこうという、美学とか哲学とか信念とか言われるようなもの、未来を見ている姿勢。少なくともそれがあるのが「良いコード」なのではないかと、僕は思ってる。
1ヶ月前に自分が書いたっきりのコードを読み返してみて、ちゃんと分かるかどうか。良いコードなのかどうかは、時間が証明してくれると思う。