速く書くのではなく間に合うようにする: ある nakagami の日記
「nakagami さんはプログラム書くの速いので・・・」 と、仕事の中の会話の中で言われたことがあって、（うーん、なんかそれ違うなぁ）と思ったことがあった。書く速度でいったら普通だし、僕よりもっとちゃんと、速く書ける人はいっぱいいると思う。 僕が常に「間に合うようにするにはどうしたらよいか」ということを考えているのが、速く書けてると感じられているのではなかろうか。 仕事としてプログラムを書いている以上は、間に合わなければどんなに立派なプログラムでも意味がない、と思っている。 機能が足りなくても、テストが書いてなくても、さらに状況によってはバグがあっても（そのバグが把握できているのならば）間に合わない立派なプログラムよりも、間に合う不都合のあるもののほうが、100倍ましだ。 時には、不具合だらけで仕様も満たしていなくも、本当に大切な部分がかろうじて動いて、ビジネスとして破綻しないためには、
人の足を踏まずに仕事をするということ: ある nakagami の日記
公開しているソースを使ってくれて「改良しましたー」と言ってメールで連絡をくれるのは良いのだが、未だにソース全部を送って「こことここなおしました」と言ってくる人がいて驚く。（さ、差分だけで良いよ・・・・） やれオープンソースだの、勉強会だの言いつつ、世の中思いのほか patch (context diff）ベースでソースについてコメントするということに慣れていない人が多いようだ。 一緒に仕事をするときに心配なのは、コーディングスキルの有無よりは、git や mercurial に慣れているか、とか merge 作業に慣れているかと言うこと。 非エンジニア（デザイナー等）が「git/Mercurial 使えます」と言ってくれると、期待してないだけに、ものすごくうれしい。（そんなこと過去にはほとんどなかったけど） プログラムが書ける人よりは git や mercurial がちゃんと使えるひとの
目玉の数が足りない: ある nakagami の日記
最近の僕のストレスは、目玉の数が十分あれば緩和されるもののようだ 「目玉の数さえ十分あれば、どんなバグも深刻ではない」 というのは、バザールの世界だけではなく広く普遍的なもののように思う。 結局、イテレータブルな開発も、ペアプログラミングも、突き詰めれば目玉の数を増やす方策なんではないか。 僕が最初に入った会社の僕の部署は受託開発で収入を得ていた。 スケジュールを引いて、納期があって、納期には仕様通りのソフトウェアを納品する。 僕は、できるだけ早い段階で客先に途中のものを見てもらいたかったのだが、課長はそれを許さなかった。むしろ、最終納品まで極力途中の成果を見せないようにしていたように思う。 それは、見積もりより速くできてることに客が不信感をいだかないようになのか、追加料金なしの仕様変更が発生することを恐れていたのか知らないが、作っている側にしてみたら、はたしてこれでいいのか？と不安になる
メールアドレスの漏洩を防止するというシステム: ある nakagami の日記
とある会社の人からメールを受け取って、文面を見ると自分のほかにＡさんＢさんにメールを送ってきてるはずなのに、その人たちは TO や CC に入ってない。 宛先に自分のメールアドレスが入っていて、CC には先方の関係者のみ。 忘れてるのかと思ってＡさんＢさんに転送したが、ＡさんＢさんにもきちんと送られているらしい。 よくよく聞くと、先方はどうもこんなの↓を使ってるらしい。 http://itpro.nikkeibp.co.jp/article/NEWS/20061031/252305/ メールの良さをかなり減ずる製品だな。かなりうっとーしい。 関係者全員に返信したい場合には新たに TO か CC に入れないといけないじゃないか。さぞや連絡ミスも多いに違いない。 利害をはかりにかけたら使わないほうがましと思われるようなセキュリティ製品の典型だなおい。 こんなの使わされてる人はかわいそうだ。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
