2004-03-15
_ オレ ssh 環境整備
とりあえず IO DATA の安い USB フラッシュメモリをゲット。USB 1.1 なので遅いが、接続さえしちゃえばあとはサーバ側の頑張りと、クライアント側はオンメモリの処理なのでまったくもって関係ない。いやしかし putty が ini ファイル対応するとこんなに便利なのかと痛感した。
で、設定をあれこれ変更。黒バックの terminal は好きじゃない（もともとは黒バックの方が好きだったんだけど、Windows も Mac も GUI は基本的に黒バックじゃないので、terminal だけ黒バックだと目が疲れる。）ので白バックで適切に表示されるように。putty は標準では太字を色を変えることで表現するが、これもちゃんと太字で表示するように変更。よしよし。いい具合だ。
しかし、ini ファイル対応版 putty もサーバの鍵はレジストリに保存しようとするようだ。OpenSSH だと known_hosts に相当するものだけど。まぁこれはそもそもこの USB メモリからのサーバへの接続はテンポラリのものだから、単に鍵を保存しないようにすればいいだけの話なのでよしとしよう。
これでマンキツだろうがなんだろうが、インターネットに繋がる環境さえあればそれだけで自分の環境が再現できるってわけだ。モバイラーならこんなもの要らないじゃんてのは正しい指摘ですが、なにか？
_ パッケージ作れるようにならんとなぁ。
とりあえず deb と ports か。Gentoo のパッケージも興味あるが Gentoo 入れるのがメンドイしな。
_ RDoc って
単純に RD フォーマットでドキュメントを書けばいいんじゃなくて、# でいちいちコメント行にしていかないとダメなのね。まぁ JavaDoc や PHPDoc の流れからするとそれでも間違ってないような気がするけど、激しく面倒くさい感じがするなぁ。
_ csv.rb は
Ruby 1.8 から標準添付。Ruby 1.8 はいろいろ標準添付になってくれて嬉しいかもしれない。
_ Emacs のモード判別
- 拡張子
- 1行目の -*-
だけかと思ったら
- ! の中身
も影響あった。すげーびっくり。拡張子なしのスクリプトが #! の記述だけでモード判別できるなら、確かに Unix では実行するスクリプトに拡張子要らないよね。いやーたまげた。
_ 価値を伝える技はあるか＜村上 隆が語る仕事・３＞ コンプレックスは才能だ
そうなんだよねぇ。満たされると制作意欲落ちるんだよね。
心理的にやばげな頃がいちばん剥き出しで、作品を生み出すパワーにあふれている。メジャーになったらつまらくなった、というのはあながち嘘ではない。プロモーションがうまくなりすぎてつまらないとか、そういうレベルじゃない本人の変化が必ずある。
かくいう自分も、もう昔のような写真は撮れないだろう。時間がないとか金がないなんてのは後付けの理由だ。
_ Ruby のエラー
基本的には今扱おうとしているオブジェクトが何のクラスに属しているのかを気にしないといけないという点は、変数に型があることに近い。それを、言語全体のレベルまで（原則的に）破綻なく適用できるから、考え方がシンプルでよいかも。
よく遭遇するエラーは今のところ「そんなメソッドは今扱おうとしているオブジェクトの○○クラスでは定義されてねーよ」だ。最初は戸惑ったが、エラーの出てるオブジェクトのクラスを追跡していけば原因が分かる。よくやるのは print obj.class ですな。長年見慣れた $ がなくてちょっと寂しいコードになるが、よい感じだ。
考え方に慣れるまで時間は掛かるけど、逆に初めから Ruby で OO しか学ばないなら習得は速そう。ただ今度は他の言語を触るときにけっこう苦労しそうだけど。いずれにしても特徴的な言語であることに変わりはない。いろんな言語に触っている人ならそれほど問題ではないと思うが。
2005-03-15
_ バン（マニュアル）延長決定
ちょうど引っ越しのタイミングで事故ってしまったんだけど、自分でやるつもりだった引っ越しの際にセダンとかこられても役に立たないので無理を言って日産の AD を貸してもらった。
この AD、知ってる人は知ってる CALDINA か AD かという定番商用車。MT ですよ。ひっさしぶりー。ということで坂道の多い金沢でどっきどきのお引っ越し。案の定エンストポイント*1ではしっかりエンストしたけど、まぁこんなもんかと。最初数分で左足が痛くなってきたときはどうしようかと思ったけど、意外と慣れるもんだ。
ほんとはこの週末だけの予定だったけど、代わりの車がないので直るまでずっとこのままだそうだ。問題ないっすよー。くいくいっとな。
それより腰とケツ筋と上腕から肘、あと肩が痛い。頭は起きてるけど身体を使うガッツが不足気味。
*1 住んだことのある人なら何カ所かパッと思い浮かぶポイントがある。
_ Wikiばな Vol.4 がなんかすごかったらしい
田舎者には縁のないオフ*1なのですが、こういう機会のおかげで、ツール作者相互によい刺激が生まれるのはユーザーからしてもとても嬉しいことです。オフにはオフのよさがある。
またチェックしなきゃなぁ。
*1 時間も金も自分でなんとかするのだよ、と正論を言われるかもしれないので一応予防線を張っておこう。どっちも余裕ねっす。
_ Logitec の LHD-NAS
をいじり始める。NetPocket のシリーズで、Synology 社の OS を採用して、GigabitEther にも対応。
- 電源を刺したらいきなり DHCP で動く
- アシスタントツールは単に検索するだけで、設定はすべてブラウザから
というのはいいんだけど、この
- 設定画面が IE 前提
っていうのはかなりのマイナスポイント。IE 依存の JavaScript ガリガリで、今のところ Firefox, Safari ではまともにいじれないというところまでは分かっている。Mac 版 IE でもいじれているっぽいけど、こうもブラウザが制限されていると、どの程度の動作検証がされているのか気になるのと、「検証したブラウザの名前くらい列挙しとけ」と文句を言いたくなる。
ファームウェアアップデートとかでなんとかならないのかなぁ。ものすごく苦痛だ。というか IE の存在しないプラットフォームの人はまともに設定できないんですが、そういう人は…確かにわざわざ NAS 買う必要ないのか。でもさぁ、マイクロソフトからきた CD のときにも思ったけど、Windows で利用する製品の管理者が Windows 使いとは限らないってのは想像するの難しい話ですかね？
最初から用意されている Public1 というダサイ名前の共有フォルダが削除できないのもマイナスだなぁ。
これを選ぶ決め手になったのはユーザー数の制限が緩いからなんだけど、IO などの NAS はどうしてあんなにユーザー数の上限が低いのだろうか。バックアップを含めた機能としてはあっちの方がほんとはよかったんだけど、ユーザー数がネックで選べなかったのだな。
_ サーバ生きてた
BIOS の画面すら見ることができなかったのに、なぜか KNOPPIX の CD を入れたら起きた。うーん、KNOPPIX すごいな。見ると BIOS のデータが一部壊れてるらしい。起きてこなかったときに BIOS の初期化とかしたのが裏目に出たか？
2010-03-15
_ TDD BootCamp Hokuriku Extra Day - Development Antinews
これは個人的なイベントというか、起きたこととそれの観察記。
そして、BootCamp と日常を重ねて思ったことなど。
大変だ！ レガシーコードの修正だ！
TDDBC の翌日は普通に仕事していたのですが、この現場には Camp とは比較にならない劣悪なレガシーコードがゴロゴロしています。
そこに修正の依頼が入りました。自分にじゃないですが。電話口のやりとりを小耳に挟んだので、要求を再確認。
- 対象はいわゆるMVCフレームワークを利用したWebアプリ
- 最速でやってくれ（ここがもう「なんだかな」ではあるんだが）
- 変更を加える必要のあるメソッドはもう見つかっているが、これが一つで140行あってベッタベタ
- できるだけここはいじりたくない
いやぁ、レガシーだねぇ。
- どうやら基本的にはブラックリストの考え方で迂回する方法で実現できそうだ
- なんか censor のない Camp ネタのように見えるな
- この部分だけ切り出せば圧倒的にテストしやすくなるぜ。ボリューム的にも TDD の導入にモッテコイダ
というわけで、判定処理の class を別個に作るように指示。
実録！ これがレガシーな現場だ！
1時間後。
- 判定処理は class に分かれていた
- できた class は実際の処理の中に思いっきり組み込まれ、
- ブラウザで一回一回実行して人間が特定のボタンを一生懸命押して
- printfデバッグ！
orz orz orz
いや、まぁ。まぁね。TDD でやれとは言わなかったけどね。やったことはあるけど身に付いていない方法を「最速」と言われている仕事で使えとはよー言いません。
- なぜ判定にミスるのか、一生懸命に目視しているが分からない！
- けっきょく脇で見ていた自分が原因を発見
何のことはない、単に改行コードが混ざってただけで、実はこれ、自分が Camp でハマったのと同じ(笑) すぐ使える Camp
なんとか動く状態になったので、一応対応完了となった。
レガシーコードにレガシーに対応する方法のここがダメ！
上の流れの中で自分が「こりゃダメだな」と思った点を挙げておく。
実システムは遅い！
まずいちばん気になるのは、フレームワークに載っけて目視チェックする方法は不必要なコードがたくさん動いているので遅い。おまけにブラウザも不必要な機能がたくさん動いているので遅い。つまり、
Feedback までの道のりが遠い。
これが自分が PHPer なのにコマンドラインでテストを回している最大の理由。最小のコードだけを動かして最短で Feedback を得るため、そして自分の手を Terminal から離さず、より良いリズムを作るための手法として自分はコマンドラインでテストを回している。
※ まぁ、自分の環境が劣悪なのもあるとは思いますが。
ブラウザは特に「値」の目視チェックに向かない
目視チェック自体の是非はともかく、sensitive な目視チェックの工程にブラウザは向いていないと思う。なぜなら Web ブラウザは HTML のレンダリング向けのツールであり、ホワイトスペースはいい具合に省略して表示してしまう。
もちろん PHP なら var_dump() などを使うことでクォート文字列が出力されるので、「クォート文字の間に何があるか」を人間が一生懸命読めばチェックは可能。しかし。しかし、次に続く。
目視チェックの精度は決して上がらない
ここまでで、すでに
- ブラウザで正しいページを出して
- 正しい操作をトレースして
- その結果を人間が正しく読み取る
という、極めて高度な操作を行っている。
上のどれをミスっても現象の把握、問題の発見を始めることはできない。
野球に例えるとこれは高度な連係プレーなのだ。野球に興味のある人なら連係プレーが本番で完璧に機能する確率が決して高くないことをよく知っていると思う。上のテストのための操作はそれと同じである。つまり、こうした手動テストは
わざわざテスト工程にミスを自分たちで入れているのと同じ
である。また、成功したとしても、ここまでですでに脳力を浪費している。問題を発見し、デバッグを行うために使える MP が、デバッグ開始時にすでに減っているのだ。しかもこれを何回もくり返していればどんどん MP は減っていく。
疲労である。
上の方法では自動化されたテストよりも人間の疲労が大きい。結果、修正作業の速度は遅くなる。
断言する。遅くなる。
コメントアウト地獄
これは BootCamp のときにも感じたことなんだけど、日頃から TDD に親しんでいる人に比べてそうでない人の方が
コメントアウトを乱発する
傾向にあるように思う。このコメントアウトがまたコードの視認性を悪くする。
テストコードがない目視チェックの場合、当然、プロダクトコードの中でチェック用のコードがコメントアウトされたりインされたりをくり返すので、TDD していない人は
コメントアウトが入っていて当たり前
と思っているように見える。
この傾向はよくないと思う。プロダクトコードの中には、必要なコードと必要なコメントと必要な余白以外ない方がよい。コメントアウトそのものを全面否定する気はないんだけど、やはり気にすべき情報は少なければ少ない方がよいと思う。人間の脳は優秀だから無意識のフィルタリングは十分有効に機能する。しかし、本当の目的以外に力を使っているという事実は変わらない。
JOJOネタの向こうを張って HxH のヒソカの台詞で言えば
「君の敗因は容量（メモリ）の無駄使い」
オレ repos のススメ
上の話とも絡むんだけど、TDD 体質の人の多くはバージョン管理システムやエディタの機能に依存してしまうことの楽さをすでに知っていて、
「不要だよな」と思った瞬間コードをばっさり削っている
と感じた。これは
あとで必要になったら戻せばいいし、戻せる
ことを「身体が」覚えているからなんだろうなと思う。
ここで言うバージョン管理システムは、より柔軟な運用ができる分散バージョン管理システムのことを指すと考えてしまった方がよいように思う。自分も去年から official な repository である svn とは別に、自分用に必ず git か hg を併用するようにしている。この方法は多少の混乱は生むけど、
svn の commit をきれいに保ちつつオレ repos で好きなようにコードを蹂躙できる
ので
「自分の作業に対する不安」が減る
ことに繋がり、とてもよいと思う。
CVS や svn 一本だと、例え branch でもあまり変な commit を作るわけにいかないというプレッシャーが残ってしまう。このプレッシャーをオレ repos で解消すると、よりコード変更に自信を持って取り組むことができる。目先の面倒が多少あっても、最終的に
自信を持って取り組めるかどうか
が、いちばん大事なんじゃないかと最近よく思う。
当たり前の話だけど不安やプレッシャーは能力の発揮を妨げる。これはアスリートたちだけの問題じゃない。我々の日常の小さな作業においても同様に、不安やプレッシャーを取り除くことが大事なんだ。
以下完全に余談。
「git は速いから」という理由を挙げている記事を目にするけど、必ずしもすべての操作において git の方が svn より速いわけではないことには注意しておいた方がいいと思う。特にリポジトリがでかいとかディスクが遅い（ネットワーク越しとか）ケースでは、branch の操作は git の方が速いけど日常的な diff 出しは svn の方が速い、ということも起きる。日常的な操作が遅いとリズムが悪くなってしまう。
_ hikaruworld [品質保証における目視チェック、つまりデバッガによるチェックはありかなと逆に最近思っています(TDDじゃないですよ)。..]
_ katzchang [コメントアウトはよくされますね。 バージョン管理に突っ込んだら、マージするときの差分がぐちゃぐちゃになったことがあ..]
_ wtnabe [目的に応じて手に馴染む道具を増やさないといけないとは思いますね。使えるけど馴染んでない道具がまだあるので。 も..]