キーボード超うちづらいけどマウスオペレーションならあんまり問題ないよ(^o^)
_ 2009年も無病息災でいきたいところですね
_
だいぶ規模縮小されたけどそれなりに便利な書斎を紹介するよ!
キーボード超うちづらいけどマウスオペレーションならあんまり問題ないよ(^o^)
_ 技術者として、あるいは人間としての自分を救ってくれた本がいくつかある。 Writing Solid Codeもその一つで(他に思いつく限りでは、 「ライトついてますか」 「.NET&Windowsプログラマのためのデバッグテクニック徹底解説」 「臆病者のための株入門」などがある)、 もう何回目か分からないけど読み直してみた。
_ 毎回新しい発見があるのだが、(記憶力がないわけではない)今回突き刺さったのは (原子炉に関するソフトで炉が過剰に熱せられた場合を処理する、 というシチュエーションで、警告を発せずに対処を続けるか、異常が 回復するまで警告を発しつづけるか、どちらがいいのか？という議論に対し)
この件についてはかなり異論があるかもしれないが、最終的にはオペレータに警告した方がよい だろう。問題が起きたという事実は、コンピュータが炉を正常な状態に戻せるかということとは無 関係なのである。(以下略)という記述だった。
_ 一方、Writing Solid Codeの中で遵守がとくに難しいと思うのは、 あらゆるコードパスをステップ実行せよ、というやつだと思うんだが、 たぶん毎回困ったことがあるとステップ実行してあれこれやっているので、 最初っからやっとけというのは正しのかもしれないなあ...と思いつつなかなか
_ SELECT * FROM 〜とやっておいてindexを数字にしてフィールドひっぱってきたり、 INSERT INTO〜でフィールド名を指定しなかったりする人達は自分を何様だと 思っているんだろう...そんな人が他人の問題意識のなさが云々とか 言ってるわけで、人材の底の浅さに涙が止まらない
_ 裸族もう1組買った。これで3つめ。3つとも同じドライブを買ったんだが 当時1万overだったのが気付けば5000円ちょっとになっていた。500GBで 5000円!すごい話だねえ
_ 開発サーバもくたびれてきたのでなんとかしたいところだ。 Tracはもう手放せないのでもっと維持しやすいようにしたい。 仕事でSubversion使ってて、TortoiseSVNはあったらうれしいが AnkhSVNは別になくてもいいかなあ、というか新しくなってだんだん 不便になっているような気がしてならないし、バージョン管理してはいけない ファイルは把握できているし...
_ と考えるとTortoiseHGもあることだし別にSubversionでなくてもいいかなあと 思った(TortoiseHGの完成度がどうなのかという疑問はあるが)。 分散バージョン管理というやつもいっぺん体験してみたいし... なので、自宅ではSubversionやめてMercurialに移行してしまおうと思う。
_ 一方会社はいまさらMercurialにはできないので、svkを使ってみることにした。 インストールしたら$PATHすっとばされてコスモが高まった。
_ 今日から通常営業。さっそくいくつも問題が出てきたり、 直す手が足りなかったり、頼んでいたことができていなかったり、 気を抜いて他人に迷惑をかけたりしている。で、どうも 落胆したりイライラしたりソワソワしたりで何もできなくなる時間が 増えているようだ。自分に限らず、周囲を見てもそんな感じがする。 よくない傾向だ
_ 会社の月報に社長の言葉が出てた。日本一の決済パッケージを作りあげて 日本一信頼できる決済センターを作りあげるという中長期目標がぶちあげられていて、 その後に 「実際に仕事をしていると迷うことが出てきます。そんなとき『日本一』に必要か不要かで判断してください。」と書いてあって、 この人は本当にすごい人だと思った。 書いてあることやぶちあげていることの滑稽さや、現状が見えてない もどかしさ、脱力感を覚えずにはいられないけど、迷わない、曲げない、 成功を信じて疑わないという意思が強く感じられて、それは後天的に 身につけるのがとても難しい能力だと思っている。
_ 少くとも自分の考えかたとは対極にあるわけだが、 どうせ今の泥沼なんて半年や1年続くわけでもないのに、目先1〜2週間の 有事のことで神経をすりへらしたり、精神的に参りかけたりしているのも どうかと思うので、ちょっとは見習わないといけないのかもしれない。
_ 余計な一言をつけ加えるなら、あの人の目指すところに自分を重ね合わせるのは とても困難なので、書いてある内容はともかくとしての話になるけど....
_ 首がまわらないのは嫌ですね...
_ 書きたいことはいろいろあるが書く時間が本当にない
_ 昨今の大混乱を導いた原因はテムレイに気をとられてるうちに 内部でカタストロフィが起きていた、というあたりにあって、 そちらについては一応の決着を見つつあるんだけど、そんな 折にやってきたコードは、CSVのパースで項目数が足りなかったり 重複キーがあったりすると無限ループになるという素晴しいクオリティを 発揮しており、選択は決して間違っていなかったんじゃないのかという気がする
_ 焦げ臭かったのは買ったばかりの中華鍋についてる酸化防止の油が揮発したときの 臭いであって料理で焦げたわけではない。とにかく中華鍋と蒸籠が 来たので料理が楽しい。中華鍋はまだ扱いが下手なのでどうも焦げつかせて しまいがちだ。たぶんもっと熱してから料理を始める必要があるんだと思う... 周辺部はお湯がかかってもあんまり反応してないしな
_ 終わってもいないプロジェクトのことを振り返ると鬼が笑うと言うが(言わないが)、 環境とか製造とかについて少し書いておこうと思う。
_ こんな程度の低いところでつまづく奴は恥ずかしい等の意見もあると思うけど 事実なのでしょうがない。こういったことで足をひっぱられると ただでさえ大変な作業がもっと大変になるので、気をつけてゆきたいと思う。
_ まず、標準やルールは他の何を犠牲にしても先に提示することが 大事だ。すでにそういうものがあれば乗っかるべき。 個人的にはここで残業や徹夜を繰返したおかげで救われた部分も多く、 またそれでも足りなくて苦しんでいる部分も多い。
_ 標準、ルールについては、基本として使えるライブラリの提示以外に、 例えばログのとりかた、DBへの接続のしかた、 ソースの配置のしかた、実行イメージの配置のしかた、ブランチの切りかた、 リリースのしかた、などなどがある。 これらがきちんとしていないと、各自が自分なりに考えたやりかたを始めるか、 決まるまで何もしないかのどちらかになってしまう。
_ ツールも開発着手前には揃えておく。 バージョン管理は誰でも使えるように教育しておくのも大事だ。 今回は早目の段階でTortoiseSVNの説明を開発者以外も含めてしておいた おかげで、文書・ソースがわりとうまく管理できたと思う。 また、ビルド→配置はコマンド一発でできるようにしておくと、 変なソースをコミットされてもすぐ気付くし、あちこちにテスト環境作るときにも 便利だ。 「おかしいな、うちでは動いていたんですけどね」問題も起きづらくなる。
_ 今回投入が遅かったのがTracのチケットだった。規模にもよるけど10人前後の プロジェクトならチケットで十分BTSとスケジュール管理の役割を果たしてくれるようだ。 開発とテストが分業できたのもチケットの存在が大きいと思う。もっと 早く導入したほうがよかった。マイルストーンに紐づいた チケットを消化してグラフが100%に近づくのは単純にうれしいし。
_ ログについても枠組・体系が決まるのが遅かった。主に自分の怠慢なのだが、 コード内で出しているログのリストアップ、なんてのは 常に求められるものであり、またよく変わる部分であるので、 早い段階で確定して維持する仕組を持っている必要があった。 ログに関しては、
_ 内部スケジュール調整は、最初はphpGroupWareを使っていたが 最終的にはGoogle Calendarで落ち着いた。基本的に持ち帰りができない 内容だったので、パートナーさんがいつ来てくれるのか、や、自分や社員が いつ外出しているのか、等を共有する程度の用途ではこれで十分だったと思う。
_ 枠組ではないがバックアップの仕組も初期に整えておくべきものだと 思う。すでに社内にそういうのがあればそれに従えばいいのだが、今回は 事情があってそっちは使えなかったので、共有フォルダ+SVN/Trac関係を 毎日zipで固めて2週間保存しつつ複数のマシンにミラーして、 週に1回CD-Rに焼くという運用をしている。CDに焼くのは手動だけど、 それ以外は自動でやっている。 今のところCD-R1枚でおさまる内容だが、Subversionに不要なデータ(pchとかね!)が 大量にコミットされているのでどんどんRepositoryが膨らんできていて困っている。 初期の教育ではTortoiseSVNの使いかたは扱ったものの、 プロジェクト/ソリューションをインポートするときの手順を示さないまま 進んでしまったためこのようなことになっている。 途中で「〜と〜と〜は入れないでね!」とメールで通知したのだが、 すでに入っているものを取り除く方法を伝えなかったので 対応してもらえず後の祭りだった。
_ CruiseControl.NETは途中まで使っていたものの、維持を怠っているうちに 動かなくなってしまい、それっきりになってしまった。NUnitをきちんと 使っていればこの辺も役立つと思うんだけど...
_ いろいろと選択上の失敗が多く反省するところだらけだが、 テストケースとテストツールを早い段階で充実させていたのは よい方向に働いたと思う。途中からテストを他の担当者に任せることが できるようになったし、テストの実施自体はバイトとか社員とかを 使えるようになった。これがなかったら開発の負担はさらにすさまじいことに なっていたように思う。
_ テストツールについてはもっとテストの負担が軽くなる方向に力を 入れるべきだと思っていたが結局あまりそちらに対応することができなかった。 1つの試行にかかる時間や精度を上げるために数日の時間を費したとしても、 数百〜数千のテストをこなすにあたっては十分にお釣が来るわけで、そこまで 分かっていても目先の問題の消化に追われてしまった。 今やっている作業について、こうやったらもっと 素早くできるだとか、ここが間違えやすいからなんとかしてほしいだとか、 やりかたが分かりづらいだとか、そういうフィードバックをテストメンバーから もらいたいと思っていたが、まあこっちの状況見てそれどころではないと判断したのか、 あまりそういったフィードバックはなかった。どちらかというと後から 出てきたものが今までの段取りを崩すものだったりすると、教育等のコストも あって導入に消極的になる部分もあるようで、この点についても 事前の準備の重要性を痛感した。
_ 他に、ソーシャルエンジニアリング的な話もあるんだけど、さすがにそれは プロジェクトが終わってから書こうと思う。なお、 「このプロジェクトが終わったら、俺……」は死亡フラグなので注意が必要だと思う。
_ 今回のプロジェクトでは今まであまり深入りしなかった部分に 触れることができてとても勉強になった。具体的には
_ 九十九電気最近大変だねえ...と他人事のように思っていたが Aero SlimはTSUKUMOだった
_ ファンがうるさめの換気扇のような音を発していて耳ざわりだなあと 思っていたら、今度はあきらかに軸がいかれた音をしだしたので 分解して1つ撤去した。4cmのファンのくせにえらい音が出るもんだ...
_ と思ったら換気扇のような音を発しているファンは別のやつだったみたいで、 今現在も異音は続いている。CPUファンかな？どっちにしろ面倒だ
_ ファンの音はうるさいし空気吸いこんで埃溜めていくないので、 ファンレスのサーバでも組みたいなあと思いつつ最近の商品を見てみると、 どうやらAtomというプロセッサが流行しているらしい。 XenとかVMware ESXiとかでたくさんVM動かしながら使うには苛酷なのかしら。 静かで場所とらないマシンが欲しいところだ
_ Aero Slimはせっかくamd64積んでるのでWindows 7でも試してみようかなあなんて 思っているがまずファン取りだすのにも一週間がかりのどうしようもない 生活をなんとかしないといけない
_ しかしメモリが2GBまでしか積めないみたいなのが気になる。 あと、Atom 330というのはどうやらVTには対応していないらしい。あらまあ
_ VIA NanoというプロセッサはVTも使えるらしい。どっちかというとこっちだろうか
_ あちこちから噴火が起きててもうなにがなにやら...
_ exFATという 名前を見てまだFATを拡張していたのかと驚く
_ CentOS入れて、SoftEther入れて...などという作業をした。 あんまり趣味では使わない組み合わせだけど、ちょっと楽しかった。
_ ゆっくり物事を考える時間が欲しい。
_ 今すぐどうにかなるもんでもないし、大勢の人を巻き込んでいる以上 ここで引くわけにもいかんのだけど、それでもこのまま放っておくわけには いかないし、どうにもならなくなってから思案しても遅すぎるという気はする。 確実なのはお金が溜まっていっているという事実だけで、でもそれが いったい自分達の何をどのくらい支えてくれるだけのポテンシャルがあるのかという 点についても明確な展望があるわけではなく
_ なにがなんでもここにいたいとか、ここにいたくないとか、そういう気持ではないと いうのは以前書いたときと変わっていないものの、前段で書いたように、 どうにもならなくなってからでは遅すぎるというのがあるので、 せめて全力疾走が終わって少しは普通に 呼吸ができるようになってきたら、というようなタイミングでいろいろ 考え始めないといけないのかなあと思う。息が上がっているのは自分だけで、 周囲はこちらの息が整うのを待ち構えているという別の問題もあったりするので、 本当のところ求められているのは全力で走りつつ考えるというパフォーマンスなのかもしれないが
_ 残業代一部or全部カットや給料カットの話も出ているので、そうなると また話は変わってくるのかもしれないが...