マスタカの ChangeLog メモ

■ 「以後気をつけます。」

前職のころから気になっていました。「以後気をつけます。」

このフレーズ、私は使った記憶がありません。いや、使ったことはあるか
もしれませんが、よほどのことがない限り使わないです。なんでかと言う
と「以後気をつける」ことって、めちゃめちゃ大変だからです。

例えば今日何かミスをして「以後気をつけます」と言ったとします。
あなたは「以後気をつける」ことを 1 つ抱えます。

３日後に別件でミスをして、また「以後気をつけます」と言ったとします。
あなたの「以後気をつける」ことが 2 つになりました。

一週間後に..(略)

このまま続くと「以後気をつける」ことが溜まりすぎて、本来やるべきこ
とに集中できません。ギブアップです。まあ実際は「以後気をつける」の
は忘却の彼方に行くのでしょう。

重要なのは「以後気をつける」必要がないような仕組みを作ることです。
もちろん頻度が少なければ、作らないのもアリです。その都度、自分のア
タマで考えないといけませんね。

■ 受託開発から自サービス開発に移って気づいたことメモ [Programing]

[2011-04-22-1] に受託開発から自サービス開発に移って、１年ちょっと過
ぎました。今さらながら気づいたことがあったので、ちょっとメモ。

受託開発は契約が無事決まるとやるべき作業や予算が決まる。どのくらい
開発リソースを使えるかが分かるので、その範囲内で新規実装やメンテナ
ンスなどをする。基本的には他の案件は発生しないが、この案件は○○に
含まれるよねなどと、契約の範囲内で対応を要望されることはよくある。
プロジェクト開始時の要件定義が重要。どちらかと言うとウォーターフォー
ル型開発と相性が良い。

自サービス開発はやるべき作業が決まっても、どこからも予算(お金)は降
りてこない。昨日決まったことが今日覆ったり、なくなったり、全然違う
急ぎの作業を要望されることは日常茶飯事。サービスをリリースしないと
売り上げが分からないので、極力小規模で開発することが重要。受託開発
と同様、中長期的なスケジュールは立てる必要はあるが、状況は刻々と変
わるため、よりこまめな更新が必要。アジャイル開発と相性が良いという
か、それしか選択肢がない。

※ 受託開発の時はそこそこの規模の会社(300人くらい)で、自サービス開
発は零細企業(開発者数人)なので、その辺の違いもあります。

■ プログラムは仕様通りに動いて当たり前 [Programing]

去年の [2011-04-22-1] に組み込み系＆受託のお仕事から、Web 系＆自サー
ビス提供のお仕事に転職し改めて思ったので書き留めておきます。特定の
個人を批判する記事ではないのであしからず..。

何かサービスを作るときに、中身がぐちゃぐちゃでも動くプログラムに価
値があることには全く同意します。私は０を１にするのは得意ではないの
で、むしろ尊敬します。しかしそこで終わってしまってはそのサービスの
将来は暗いでしょう。

メンテナンス性の高いコードに！

サービスが安定稼働し始めたら、メンテナンス性の良いコードに変更して
いく必要がありますし、新しく追加する機能も同じです。

※ もっとも、緊急時は最小限の工数でできる変更を採用すべきですが、
あとで絶対に適切な修正に改めなければいけません。

その新しく追加する機能なんですが、私は実装して開発環境で意図通りに
動いた時がスタートラインだと思っています。

ちゃんと動いた時がスタートライン

そこからバグや重複、むだなコード、むだなコメントを減らし、いかにメ
ンテナンス性の良いコードにするか、集中して作り込みます。もちろんテ
ストも書きます。

私はここがプログラマの腕の見せ所だと思ってますし、細かいこだわりを
入れられたり、より良いやり方で作り込めると、何度も何度もコードを読
み直してニヤニヤしてしまいます。

プログラムは仕様通りに動いて当たり前なので、プログラマとしてはメン
テナス性の良さだとか、パフォーマンスだとかの付加価値を付けることが
重要です。しょうもないバグは論外です。

もうひとつ大事なのが、コミットにストーリー性を持たせることです。

コミットにストーリー性を持たせる

私は最低でもインストール前に５回は変更を見直して、「本当にこの変更
で良いのかな」「このコミットは２つに分けた方が良いな」とか「これと
これは同じコミットだろう」とかやってます。Git だとこれが容易なので、
とっても便利です。最終的には２０回くらい見直していると思います。

※ 平時はこのくらいやる習慣を付けることが重要です。ろくに確認しない
ことを習慣化してはいけません。

インストール後は(当たり前ですが)、インストールした環境で正常に動作
するかをチェックします。

まあ、Jenkins で CI(継続的インテグレーション) やっているので、単体
レベルでの動作はあまり気にしなくて良いのは助かります。

まとめ

仕様通りに動くようにプログラムを作るのは、プログラマとして当然です。
コードに付加価値を付けることが、自分への付加価値に繋がると信じてい
ます。

おまけ

組み込み系でも Web 系でも「品質の良いコードを書く」ことについては同
じでした。前職では数百人規模のプロジェクトに所属しており、自分要因
でシステムが止まる恐ろしさは十分すぎるほど分かっているので、その点
は良い経験でした。

Web 系だと新しいツールを使いやすかったり、テスト環境も構築しやすかっ
たり、他社のプログラマーとの交流もしやすいので、プログラマーの幸福
度は高いかも？

■ git stash やめました！ [Git]

git stash は便利なんですけど、stash したのを忘れたり、egg 使ってい
ると pop しても消えなかったりするので、もう使わないことにしました。

gitで現在の作業内容をクイックセーブする - アジャイルSEを目指すブログ

この記事からヒントを得て、最近はオレオレ git qsave を使ってます。

見てのとおり、変更点を全部 commit しているだけです。

git reset --soft 'HEAD^1' とかすれば commit 前の状態、つまり
Staging の状態に戻ります。

リセットしないであとで圧縮 commit しても良いですね。

git-qsave という名前で(git-qsave.sh じゃないですよ！)パスの通ったディ
レクトリに置けば、git qsave で実行できます。

■ Jenkins-CLI使わずに、リポジトリの変更をプッシュ通知する方法がやっと分かった [Jenkins][Git]

git push したら、すぐにテストを実行して欲しいだけなんです。
もう、ポーリング [2011-12-30-5] で新しい commit があるかチェック
するのは嫌なんです。

いや〜、Jenkins-CLI でやろうとしてかなりハマりました。

loading...

loading...

loading...

初心に返ってJenkins実践入門読みましたが、Git には特に触れられておらず...。

どうせこれも Jenkins-CLI のススメだろうと WEB+DB PRESS Vol.67 の
17 ページ目のコラムの URL を読んでみた。

「あれ？ Git プラグインだけでできるの？」

試しに git push の後に Web ブラウザで
http://example.com:8080/git/notifyCommit?url=/home/foo/hoge.git
にアクセスしたら、ビルドが始まったじゃありませんか！

あとは /home/foo/hoge.git/hooks/post-receive に以下を追加して終了。

curl 'http://example.com:8080/git/notifyCommit?url=/home/foo/hoge.git'

なんか矛盾しますが、「SCMをポーリング」にはチェックを入れる必要があ
ります。スケジュールは空っぽで OK です。

あと、今回のもうひとつの素晴らしい点は、認証が必要なシステムでも使
えることにあります。

長年のつっかえがやっと取れました！
Jenkins さん、dis ってすみませんでした。

Subversion はこの方法で出来るみたいです。

■ Emacs の C-x h (mark-whole-buffer) を使うようになった 〜手癖は直せる〜 [Emacs][OSX]

loading...

連投しようかと思いましたが、思い直してブログに書くことにしました。
ツイッターやるとそれなりに発散できますが、どこにも収束しませんからね。

上のツイートでは M-< とか書いてますけど、実は Esc-< って打ってます。
最初に触った Emacs(NEmacs(ver18.55)) は X など使えなかったので。

手癖は直せる

こういう手癖ってなかなか直せないと思いがちですが、そんなことないです。

- 半年ほど前、Return キーは Ctrl-m に、Tab キー Ctrl-i を打つように
手癖を直しました。キータッチが少し速くなったと思います。(鬼軍曹.el
さんありがとう！)

- C-; や C-: を 1 行スクロールアップ/ダウンに割り当ててましたが、
Command-j,k に変更しました。右手小指の痛みが治りました。

- メタキーを打ちやすいように、以下の設定で Command と Option を入れ
替えてましたが、デフォルトの設定に戻しました。おかげで Emacs でも
Mac 特有のキーバインドを使えるようになったり、Super キーを積極的に
使えるようになりました。

(setq mac-command-modifier 'meta)
(setq mac-option-modifier 'super)

最初の 2 つは 10 年以上染みついた手癖です。最初は結構イライラしまし
たが、3 日くらいで慣れました。で、2 週間ほどで手癖は忘れました。

まとめ

M-< を「Esc 押して離して < を打つ」するのを止めます。