真っ白だと目が痛いので若干色味をつける。
Solarizedっぽいけど、Solarizedはつかっていない。
別に白背景のほうが生産性が上がる! みたいな理由はまったくなくて単なる気分転換。Vimも白背景にしている。
ちなみにvim-magica-colorsというカラースキームをつかっていて、これは bg の値によって白背景むけの配色と黒背景むけの配色が入れ替わるようになっている。
白背景だとすこしコントラストが低い微調整が必要だとおもうけど、だいたいいいかんじ。
ほげ
ふがふが
だいたいこれらに書いてあることを考えている。
基本的にGit Successful Branch Modelで運用する。git-flowを入れて使っているけど、手でやってもそんなに面倒ではないし好きなようにしたらよさそう。
Subversionを個人で使っていたころはブランチはよくわからないけど恐しいものだったけど、Gitを使いはじめてだいぶ親しめるようになった。
文字通り、ブランチ、枝である。気軽に扱えるということは理解の助けにもなる。
論理的に最小限度のコミットをつくる。「こういう機能を実装した」っていうコミットはできるだけ避けたほうがいいと思っている。
コミットの粒度はテストを書いていると感覚が掴みやすい。
たとえばActiveRecordのバリデーションのテストを書くとき、異常値と正常値についてテストと実装を書く。余裕があれば境界値のテストまで含めてひとつのコミットとする。
コミットの単位は自分の脳のバッファの量に合わせるとよさそう。ロールが絡む認証のテストは条件分岐が複雑になるので異常値ひとつについてテストと実装を書いたらコミットすることもある。
実装が一通り終わったら
実装を進めていくとバリデーションに通らないでほしい (あるいは通ってほしい) ときに予期せぬ挙動をしたりするので境界値のテストを足す。この時、ブランチを切っておく。
fix/user-name-validation みたいな。論理的にまとまりのあるいくつかのコミットをまとめるものとしてブランチを扱うことで、たとえばバリデーションの修正だけ先に開発ブランチにマージすることができる。
もしバリデーションの修正がある機能開発ブランチの中にだけ存在していると、機能の開発に目処がつくまで修正は開発ブランチに取り込まれず、機能開発ブランチに対してバグ修正と機能の提供というふたつの責務を負わせることになる。
また、長引けば長引くほどconflictの危険性も高まる。conflictしないことに越したことはない。まめにコミットしておけばむだなconflict解決を減らせる。はず。
ブランチの命名規則はそれほどクリティカルではないから好きにしたらいいとおもうけど、たとえばバグ修正は fix/ で始まる、とかそういう簡単な規約をつくっておくと便利そう。
そういう規約を設けることでたとえばリポジトリブラウザで fix/ 以下にあるバグ修正ブランチを一覧する、みたいなのも簡単に実現できておもしろそう。
あまりしないけど、バグ修正のコミットとかはよくrebaseする。Gitはローカルでいくらでもできるのだから、branch切りまくってrebaseとか実践していくほうがずっとためになる。
というか、怖くなったら適当なリポジトリを作って試すことができる。便利。
あと、Git Successful Branch Modelでも言及されているけど、基本的にブランチのマージは --no-ff で行う。
Railsとかはジェネレータを供えている。どういうコマンドやオプションでファイルが生成されたか記録しておいて不便しないのでジェネレータを走らせるたびにコミットしている。
Zshだとfcというビルトイン関数がある。
rails new myapp -T git add -A; git commit -m "$(fc -l -n -1)" # rails new myapp -T
ActiveRecord::Migrationを走らせるたびにどのバージョンにマイグレートしたのか記録しておきたい。
bundle exec rake db:migrate git commit -m "Migrate $(bundle exec rake db:version)" # Migrate Current version: 20124081204
コミットメッセージは現在形を使うようにする。歴史修正が容易く行われるので、「このコミットは) 〜という変更を及ぼす」と読み下せるようなメッセージがよいと思う。
詳しいメッセージは空行を挟んでから書くか、重要度が低そうならgit notesにでも。
コストがかかることやリスクのある方法を実行するときは、できるだけ手間がかかるようにするべきだと思う。
対してコストが少なく済んだりリスクが軽減できる方法は、より手間のかからないやり方で提供されるべき。
プログラムを書くための言語について考えてみると、まずスコープの解決。
デフォルトでレキシカルスコープであるべき。Perlはダメ。少なくともPerl 5はダメ。
JavaScriptも危うい。コーディングに気をつければ回避できる。
Pythonなんかはかなり安全なスコープになっている。
Rubyも惜しいけどclass/moduleで親スコープかれ切り離されてしまう。一貫性に欠ける。現状でRubyの最もダサいところのひとつだと思う
スコープに関連して外部ファイルからのソースコードの読み込み (+ コンパイル) を行う際、カレント・スコープ上に展開される識別子を限定できたらよい。
Rubyはダメ。すべて読み込まれてしまう。Perlはデフォルトですべてexportする挙動なのがちょっといけていないけどimportするものを明示するようにすれば解決するのでよし。
PythonやHaskellは比較的安全で、qualifyもできる。
CommonJSでの定義は、さすがに先行実装がたくさんある中でつくられたので悪くないとおもう。ライブラリ (ファイル) が明示的にexportしたオブジェクトを、利用するスコープにおいて変数に代入するというのはマジカルじゃない (勝手にスコープに識別子が追加される?) ので素敵。
(ねむいのでやめる)
作品としてのアプリケーション
軸となる利用法があってその周りに付加的な機能がついてまわる
ブログ
記事を公開し効率よくレスポンスを受け取る、コメント、トラックバック、RSS
想定された使い方をはずれると不自由になる
自由さを武器とした対抗馬を立てる→当初、その分野が想定していた使い方から逸脱、発散、よくわからなくなる
アーキテクチャを提供する
シンプルなメッセージング
使い方を想定しない
自律的に成長、変化する
写真を撮り続ける → 写真に関する機能が増えたり中心的に改善される、デザインが写真を見せるものに変わっていく
日記を書く → 日記、テキストを中心とした機能やデザインをサジェストする
未来は不確定である 予想できない
→ 未来をつくる? コストがかかる 技術、政治における力比べ
→ 未来を歓迎する コストをかけない アプリケーションの提供→アーキテクチャの提供→なにも提供しない
形あるものを提供すると、形があることによる制約を受ける 「形あるものはいつか崩れる」
無名、無形の流れ、作用を提供する 人の思考に影響を与える ゆるやかな排他
お金を払ってもらえなくて困る → お金を払う方法・機会を複数用意する、お金を払うことについての意識の変化
広告が主たる収入源→広告がコンテンツの中心に据えられてしまう、依存
フリーミアム? 1の有料会員で100の無料会員をペイできるモデルならあり お金を払うモチベーションが低いことが問題 → 解決できていない、場当たり的
人間を信用しない 人間に従うのではなく人間のそばにある 自ら流れをつくる 呼び込む
今週はずっとPerlを書いていたのでいろいろ。
コンテキストつらい。
コンテキストがどういうものかは『初めてのPerl』とPlackなどのコードを通して概要をハハンと掴んでいた程度で実際に付き合いはじめたのは今回が初めて。
使ってみての印象は最悪で動的型付けと静的型付けの悪いところを合わせたよう。
リファレンスも印象が悪い。
配列とそのリファレンスが別にあって組み込みの関数は配列のリファレンスには適用できなかったり、散々。
後方互換性を確保するという思想は結構なことだけど、スコープとかリファレンスとか、「ちゃんと書く」ためにキーワードをいちいち書かなきゃいけないとかっていうのは、道具として失敗だと思う。
オブジェクトへの安心感が足りない。Rubyはオブジェクトが自分自身についてあらゆることを知っていて、わからないことがあればオブジェクトに聞けばよい。Pythonはドキュメンテーションへのアクセサが関数やクラスに備わっている。
PHPを馬鹿にできないほどトップレベルに関数が散らばっていて、perldocを引かないとわからない。
何より致命的なのがこれらの問題はほぼ間違いなくこれから先ずっとPerl 5が抱え続けるということだ。悪く変わることもないだろうが良く変わることもない。
いろいろ書いてきたけど、ふたつ、Perlでコードを書いてよい発見もあった。
ユニットテストを書くことで安心感が得られるという体験ができた。
Rubyは慣れすぎてしまって、Red -> Green -> Refactorという手順を辿るのが回り道に感じられて非常に億劫になるのだけど、慣れない言語で慣れないコード (アルゴリズム、データ構造) を書くときには非常に安心できる。
本当に単純なユニットテストと実装のイテレーションで進めていった。
sub is_nil { }sub is_nil { my ($self) = @_; $self->head ? 1 == 1 : (); } みたいなかんじという具合。本当に乳飲み子のようなかんじでテストと実装を書いていた。
Test::Moreは本当にシンプルなライブラリだけど必要最低限のものはあるといったかんじ。
オブジェクトの等価性 (neq 等値) のテストがリファレンスとかごちゃごちゃしているのもあっていまいちうまく書けなかったけど、まあだいたいよいかんじ。
普通に書くとテストの件数を意識しなきゃいけなかったりだるいので、subtestを使ってRSpecのdescribe/contextっぽく使ってゴリゴリ書いている。
昨日書いたコードのだめなところ、イケてないところが次の日に見えてくるといったかんじで急勾配の学習曲線を描いているのがよくわかる。
Perlを書いていてぎりぎり苦にならない。楽しくない一方で興味深いかんじ。さっさと書けてさっさとテストできるのがいい。Scalaはmaven使っても走るのが遅くてだるすぎた。
Perlでも自動テストとかしたい。
みたいなことがしたい。
シェルスクリプト + αというかんじだった言語が、という風に言われることも多いが、所詮、PythonやRubyもPerl + αみたいなかんじだし、おもしろい言語 (たとえばIoとか) と流行る言語、生き延びる言語がよい言語とは限らない。 (JavaとかCとかへの回想をする)
今年中にCPANでおふざけでないモジュールを出してYAPCとかで諜ってPerlについてなにか考えるのをやめにする、という予定を立てた。