発売日直後に買ったものの読むためのまとまった時間がとれず今日まできてしまいましたが、ようやく「ウェブ時代５つの定理」を読みきりました。
- 作者: 梅田望夫
- 出版社/メーカー: 文藝春秋
- 発売日: 2008/03/01
- メディア: 単行本（ソフトカバー）
- 購入: 29人 クリック: 4,720回
- この商品を含むブログ (425件) を見る
ウェブ時代５つの定理
インクリメンタル検索中のバックスペース
通常、C-hは以下のようにしてバックスペースにしてます。
(define-key global-map "\C-h" 'delete-backward-char)
C-sのインクリメンタル検索中、検索文字列の入力を間違えたときに修正したいなーと思いC-hとすると、検索モードから抜けてバックスペースしてしまいます。それでずっと「インクリメンタル検索使えない！」と思っていたのですが、下記の一行を付け足したら解決。すごく快適になりました。
(define-key isearch-mode-map "\C-h" 'isearch-delete-char)
subversionをざっくり勉強してみた
subversionの知識が中途半端なのでsvnbook日本語訳のPDF版を作成してみましたをざっくりと１章〜３章まで読んでみた。
３章までで力つきたので、４章以降はまた後日。
勉強になったところのまとめ
リビジョンキーワード
- HEAD -> リポジトリ内の再審理ビジョン
- BASE -> 作業コピーのリビジョン
- COMMITTED -> 変更された最後のリビジョン
- PREV -> COMMITEDの一つ前のリビジョン
BASEとCOMMITTEDってリビジョン番号は違っても、中身は一緒だよね？あえて二つに分ける必要ってあるんだろうか？
リビジョン日付
- リビジョン番号の代わりに{"2008-03-28 15:00"}みたいに時間が指定できる。
- {"2008-03-28"}のように日付だけ指定すると、28日の0時以前を指定したことになるため28日のリビジョンは含まれないので注意。
check out
svn checkout http://hoge.net/repos/svn/trunk hoge
の様にすると、hogeディレクトリに作業コピーを作る。
hogeを付けないと、trunkディレクトリに作業コピーを作る
update
- R
- Replaced 同じ名前だけど別のファイル
- G
- merGed マージ。なんでMじゃないんだろう。
Conflictがおこったら、以下の三つのファイルが作成される
- filename.mine
- update前の作業コピー中のファイル
- filename.rOLDREV
- update前のBASEリビジョンにあったファイルの内容
- filename.rNEWREV
- HEADリビジョンの内容
svn resolved filenameで三つのファイルは消える。commitできるようになる。
diff
svn diff > patchfile
みたいにファイルにリダイレクトするとパッチが作れる
list
svn list http://hogehoge.net/repos/svn
でリポジトリのディレクトリ構成を表示
cleanup
Lが表示されたらsvn cleanupで解決
level20リリース！
本日、level20という転職プロフィールサービスをリリースしました。
一言でこのサービスを説明するのは難しいですが、あえて言うなら「ブログやSNSを履歴書にして、ブログパーツで転職活動ができるサービス」です。
level20のアピールポイントの一つとして、ブログやmixiとの関連づけをすることで、従来の転職サービスにありがちな膨大な登録作業（氏名、年齢、住所、資格、自己PR・・・）を省略できるというものがあります。僕は半年くらい前に転職活動をしていて、大手転職サービス４つに登録したのですが登録にはだいぶ骨が折れました。特に資格の欄を埋めるのがめんどかった記憶があります。無数の資格が微細に分類されていて、大分類→中分類→小分類みたいな感じで順々に選んでいってようやく一個のスキルを登録。この資格はどの分類なのかなーとか考えながらやらなきゃいけない。検索する側（企業の人事さん）や運営側にとっては検索しやすくなって楽なのでしょうが、登録する側としてこれは大分敷居が高いです。level20はブログやmixiを見てもらうのが前提なので、登録に最低限必要な情報はニックネームとブログのアドレスだけです。らくちん。
また、level20は転職に興味がある人のプロフィール情報は誰でも見ることができます。誰でもメッセージを（level20に登録したら)送れます。なので、転職する気はあんまりなくても、「とりあえず自分のスキルセットをみんなに晒しておくよー」とか「友達募集！」というような使い方もできます。（後者はちょっと無理があるかもしれないけど）
というわけで気軽にどんどん登録したらいいと思うよ！
クラス定数は継承されない
railsでこんなふうに書いたら
class HogeController < ApplicationController def hoge begin redirect_to :back rescue RedirectBackError => e redirect_to :controller => "main", :action => "index" end end end
こんなエラーが出た。
NameError: uninitialized constant HogeController::RedirectBackError
RedirectBackErrorのスペルミスか？それともRedirectBackErrorなんて存在しないのか？とか思いつつ色々調べた結果、これを
rescue RedirectBackError => e
こう直したら動いた。
rescue ActionController::RedirectBackError => e
HogeControllerはActionControllerを継承してるのになんでだろう？
と思ったが、どうもクラス定数は継承できないみたい。
参考
プログラミング作法 第一章「スタイル」
最近、効率のよい○○にはまっています。
- 効率のよいコードの書き方
- 効率のよいテストの仕方
- 効率のよいDBの設計
などなど。
この中から、まず手始めに効率の良いコードの書き方を学ぶことにしました。個人的に、小手先のテクニックを学ぶよりも基礎から勉強した方が長い目で見た時に効率がいい！と思うので、思いっきり基礎から勉強していきます。そこで、基礎からの勉強のためにプログラミング作法と言う本を買ってみました。
- 作者: ブライアンカーニハン,ロブパイク,Brian Kernighan,Rob Pike,福崎俊博
- 出版社/メーカー: アスキー
- 発売日: 2000/11
- メディア: 単行本
- 購入: 58人 クリック: 1,152回
- この商品を含むブログ (204件) を見る
最近いろんなことに手を出しているので、全部読みきるまでには結構かかりそうですが…気長にお付き合いください。まずは第一章。
名前
グローバルにはわかりやすい名前を、ローカルには短い名前を
ローカルグローバルにかかわらず、長くてもわかりやすい名前をつけた方がよいと思っていた。
関数には能動的な名前をつける。名前は動詞＋名詞の順番がよい。（getTime()とか）
time_displayみたいな名前つけてたかも＞＜。統一しよう。
式と文
自然な形の式を使おう。式は自分で音読するつもりで書こう。条件式に否定が含まれていると、間違いなく分かりづらくなる。
unlessはいいのかな？railsで結構多用するんだけど。こんな感じで。
name = params[:name] unless params[:name].blank?
複雑な式は分割しよう
式を分割してコードが複数行になった時に、途中結果を変数に格納しなくてはいけなくなって、変数名が増えて書きにくい→短くしちゃえ
みたいなことをしがちなので、これから自重しようと思います。
一貫性と慣用句
getsは絶対に使ってはならない。getsで読み込まれる入力の量を制限する手段がないからだ。この点はセキュリティの問題を引き起こす。*1
そうだっけ？やばい。Cだいぶ忘れてるなー。
多分岐の判定にはelse-ifを使おう
else-ifを使うっていうだけなら、「当たり前じゃん」って思うんだけど。
間違い例
if (argc == 3) if ((fin = fopen(argv[1], "r")) != NULL) if ((fout = fopen(argv[2], "w")) != NULL) { while ((c = getc(fin)) != EOF) putc(c, fout); fclose(fin); fclose(fout); } else printf("Can't open output file %s\n", argv[2]); else printf("Can't optn input file %s\n", argv[1]); else printf("Usage: cp inputfile outputfile\n");
正解例
if (argc != 3) printf("Usage: cp inputfile outputfile\n"); else if ((fin = fopen(argv[1], "r")) == NULL) printf("Can't optn input file %s\n", argv[1]); else if ((fout = fopen(argv[2], "w")) == NULL) { printf("Can't open output file %s\n", argv[2]); fclose(fin); else { while ((c = getc(fin)) != EOF) putc(c, fout); fclose(fin); fclose(fout); }
僕は正常系を先に書いて異常系を後に書くってことを意識している（気がする）ので、その感覚で書くと間違い例のようになってしまいそうな気がした。（まあさすがにこの例では正解例を書くと思うけど）
個々の判定とそれに対応する動作はできるだけ近くに記述するのが原則だ。
って書いてあったけど、これは覚えておこうと思う。
関数マクロ
これはCオンリーな話なので飛ばす。
コメント
コードと矛盾させるな
これだけだと「そうだよねー」という話。でも
コメントはコードと一致しているだけではだめで、それに沿っていなければならない。
これは参考になった気がする。以下例。
time(&now); strcpy(date, ctime(&now)); /* ctimeからコピーされた末尾の改行文字を除去 */ i = 0; while(date[i] >= ' ') i++; date[i] = 0;
コメントとコードは一致しているんだけど、コメントは改行文字について書いてあるのにコードは空白について書いてあるのが問題だよねーという話。これだと確かに一見コメントとコードが一致してない内容に見えてわかりづらい。
コメントまとめ
太字の部分を抜粋。
- 当たり前のことはいちいち書くな
- 関数とグローバルデータにコメントを
- 悪いコードにコメントをつけるな。書き直せ。
- あくまでも明解に、混乱を招くな
最後の部分を引用
コメントは、コード自体からは即座に意図を読み取れないプログラムの部分を解読しやすくするためのものだ。とにかくできるだけわかりやすいコードを各個と。そうすればそうするほど必要なコメントは少なくなる。優れたコードは下手なコードよりコメントが少なくて住むのだ。
コメントが少なくても分かるコードを書けるように頑張ろう。
感想
Cをだいぶ忘れている気がするので、ちょっとリハビリしたい。
*1:この本に書かれているサンプルプログラムは、ほとんどCです
マイエディタ探求日
今の僕のrails開発環境はemacs + emacs-railsです。でもemacs-railsがどうもいまいち。
- viewからcontrolに戻ると、一番上の行に戻る
- viewやcontrolからC-nでmodelには行けるけど、modelからcontrolやviewへは戻れない
- C-RETが効かないときがある
- html.erb編集時のsnippetがhtmlモード？
多分railsが2.0にバージョンアップしたのに、emacs-railsは去年の５月から更新が途絶えているのが原因。で、ちょっとtextmateに浮気をしてみた。
TextMate ― The Missing Editor for Mac OS X
インストールはあっさり。起動して、rhtmlの編集モードにしてみると・・・おー。タグの折りたたみができる。すごい。
でもC-hがバックスペースにならない。やり方調べても？？？バインドエディタやKeyBindings.dicsをいじってもうまくできなかったので、とりあえずTextMateを使うのは保留にします。
使いこなせたらものすごく生産性が上がりそうなんだけどね。
