UKSTUDIO

札幌Ruby会議03、お疲れ様でした!本当にいい会議でした、ありがとうございます。

すごいざっくりと感想を言うと「感極まった」とだけ言っておく。あの場にいた時の気持ちはなかなか文章にしづらい。個々の発表で行くと気になるトピックがどうだったとか、この話が良かった、あの話よくわからんみたいなことは言えるのだけど、「札幌Ruby会議」のあの場に居て思ったことはうまく言い表せないんだなー。とは言え「感極まった」で止まってては話にならんので、今後どう行動していくかだな。

ちょっと過去の話になるけど、札幌Ruby会議03に参加したきっかけとしては、やっぱりRubyKaigi2010でスタッフやったことかな。RubyKaigiスタッフで札幌なNiceな人達と会って「札幌RubyKaigiやるよ」と言われて、素直に「行きたい!」と思えたので参加を決めた。更にRubyKaigiのスタッフをやるきっかけとしては東京RubyKaigi03のスタッフをやったことで、そのスタッフをやったきっかけも更に前の〜と遡っていく。

結局あの時あの場にいたってことはそれまでの積み重ねがあってそれが1本の道になってるんだなと。「今後どう行動していくか」ってのも結局は「今やれること、やるべきこと、やりたいこと」をやっていくしかないなと改めって思った次第。

ところで話は少し変わって、島田さんの発表に僕の発表が影響を与えられていたようで良かったです。大抵、自分がなにかを発表したときはあの場にいた人やまわりにどう思ってもらえたのだろう?と不安になる部分は少なからずあるのでこう言ってもらえるのはとてもうれしいです。

j, k, u, m
みんながオブジェクト倶楽部の夏イベントでした発表は、コードや技術、自分自身に等身大で向き合ったとても良い発表でした。あの時の発表に対して自分だったらどんな発表をしただろうか、というのが発表の筋の入り口になりました。ありがとう。
『Rubyの教えてくれたこと』 – but it's up to us to change(2010-12-04)

最後に、札幌Ruby会議03に参加できたことは僕の中で非常に大きなことだったと思います。単純なモチベアップだけでなく、今後自分がどうしていくか考えるきっかけになりました。本当にありがとうございます。

札幌観光

北海道は幼少のころに2回ほど来てるけどあまり記憶がないので実質初めて。なので滞在3日目(12/5)はひとりで適当に観光。本当はたいやき部の方に参加するつもりだったけど、午前中若干二日酔いですぐ動けなさそうだったのと、ツアーにスープカレーが含まれてた(辛いの苦手)ので断念。たいやきは食べたいのでそれはまたの機会に。

観光は札幌周辺と小樽をノープランで。北海道は食べ物がおいしくて素晴しい。次は函館行きたいなぁ。

vimの環境を少し整理した。

pathogen.vimを使うことにした

tpope's vim-pathogen at master – GitHub

我らがtpope先生のプラグイン、pathogen.vimを使ってプラグインを管理するようにした。.vim/bundleにあるプラグインに対してruntimepathを追加してくれるので、今まで.vim以下のautoloadやpluginsとかにバラバラになってたプラグインを1つにまとめたまま管理できる。

1つにまとめられると、githubとかにあるプラグインはgitのsubmoduleで扱うことが出来るので便利。特にgithubにあがってるようなプラグインは更新が速いものが多いのでなおさら便利(unite.vimとか)。これで主要なプラグインの更新はgit submodule updateで済む。

ちなみに今のディレクトリ構成はこんな感じ。
.vim/bundle at master from ukstudio's config – GitHub

ちなみにこういうことをしていて、プラグインの自動更新とかがデフォルトでないvimもいい加減レガシーな環境だよなぁと思うのであった。

neocomplcache.vimのsnippets機能を使いはじめた

何となくなじめなかったsnippets機能だけど、neocomplcacheにいつのまにか実装されてたので試すことにした。とりあえず、rspecまわりをいくつか追加したけど思いの他便利である。補完で候補がでてくるのとsnippetsの編集がラクなのがとてもいい。

.vim/snippets/rspec.snip at master from ukstudio's config – GitHub

RailsDevCon2010、お疲れ様でした。主催かつ発表のお声をくれた@ysakakiさん、スタッフの方々、スピーカー、発表を聞いてくれたみなさま、どうもありがとうございました。

今回、「Railsプロジェクトを成功させるために現場ができること」というタイトルで話したけどびっくりするぐらいRailsに関係のない話。オマケ程度にちょこっと。以下、資料です。

テーマとしては、@ysakakiさんから声をかけて頂いた時に、[Railsの現場でまだまだバージョン管理すらしてないところあるよね。そういう基本的なところを改めて赤松さんの方から話して欲しい」と言うことだったので、個人的に基本的な所と言うと「TDD」と「バージョン管理」(できれば継続インテグレーションもいれたい)だったので、その変も踏まえて技術的負債というトピックを扱った。

具体的な話をしても、スクリーン上じゃコード読みづらいし、わかりにくいかなと思ったので少しぼかした形で発表したわけだけど、全体的にふわふわと掴みどころのない話になってしまったかもしれない。次どこかで発表する時、もしくはブログにでももっと具体的なコードレベルのことを書きたいな。

懇親会は二次会まで参加した。久しぶりに同世代の人と話せたのは楽しかった。ぜひぜひこれからも頑張ってほしい。

普段ブログ書くとき、ローカルのvimで記事を書いてからそれをWordPressの記事作成画面にコピペしている。Macの時はpbcopyを使っていたけど、それと同じことをUbuntuでするにはxselというのを使えばよさそうだ。

$ sudo aptitude install xsel
$ cat hoge.txt | xsel -ib

最近メインで使っているMacBookが調子悪かったので新しいマシンを買うことにした。元々、Core i7&メモリ8GBでMacBook Proの15インチを買うつもりだったけど、Lenovoが18周年記念でThinkPadが安かったので以前から考えていたLinuxマシンに手を出すことにした。

X201sをCore i7&メモリ8GBで

基本的にほぼ毎日パソコンを持ち歩くので比較的重さが軽めのX201sを選択。CPUとメモリは元々予定してたi7と8GBを選択。HDDとSSDで迷ったけど、500GB HDDから128GB SSDへの変更で +6万円だったのでSSDは自分で換装することにしとりあえずはHDDを選択。キーボードは当然英字配列。

X201sが届いて最初にやったことは電源を入れることではなく、SSDへの換装。HDDを引っこぬいてSSDを挿すだけだったのですぐに終了。ちなみに使用したSSDはまわりに聞いて評価の高かったIntel SSD 160GB SATA 2.5 SSDSA2MH160G2C1。Ubuntuは10.10の日本語RemixをCDに焼いてそれでインストール。

立ち上がりの速さに感動

起動して最初に思ったのが、立ち上がりの速さ。ログインするまでが本当に速い。普段起動時間が長いのを嫌ってノートPCの電源は基本的に落さないタイプだけどこれならちゃんと電源落してもいいかなと思える。Firefoxも待ち時間がほとんどなく立ち上がる。素晴しい。

セットアップ

とりあえずキーボードレイアウトからCapsLockをCtrlにする設定をした。次にSKKを使うためにuim-skkをaptitudeでインストール。Sands(Space長押しでShiftにするやつ)は結構設定がめんどうな感じだったのでとりあえず諦め。

ChromeやCompiz、xchat、Sylpheedなど必要そうなものをインストール。Chromeは同期機能のおかげでMacの方のChromeから特別なにもしなくてもほとんど移行できた。Compizは余計なアニメーションとかさせなければ結構便利。

IRCはxchatをとりあえずインストール。@ursmさんからquasselという奴をおすすめされたけど使い方がよくわからないのでとりあえず保留。おもしろそうな感じはするのでそのうちゆっくり試してみよう。

EvernoteはUbuntu用のアプリケーションがないのでNevernoteやWine上でWindowsのEvernoteを動かしてみたけど日本語が文字化けして使い物にならないのでとりあえずWebで我慢。

後は開発ツールまわりをインストール。vim、rvm、MySQL、screen(git://git.savannah.gnu.org/screen.git)、zshあたりをインストール。なんちゃらrc系全部githubに置いてあるのでこの辺りもさくっと移行完了。

まとめ

なによりUbuntu + SSDは本当に快適で素晴しい。これだけでも買い替えてよかったと思える。Linuxはデスクトップマシンとして使うのは初めてだけど、Ubuntuは一昔前じゃ考えられないぐらい洗練されていて何も不自由を感じない。プリンタなどのハードウェアまわりで不安がないわけじゃないけれど、とりあえずは何とかなるだろう。

参考にしたところ

• 連載：Ubuntu Weekly Recipe｜gihyo.jp … 技術評論社
• キーボード派におすすめするLinuxのCompiz設定 – Secret Sword!!!
• 漢(オトコ)のコンピュータ道: ラップトップ購入!OSは・・・

Rails3.0のscope(2系で言うnamed_scope)を使ったお手軽検索。モデルにextendして使う。やってることは渡されたパラメータのkeyのscopeを呼び出して、それらを全部チェインさせるだけ。お手軽だけど、scopeを定義するだけなので結構融通が効くし便利。

どうやらsteakで対応してるみたいです(コメント欄参照)。steakのgroupに:developmentを追加すればrake statsの結果にAcceptance specsと表示されます。

結論から言うとrakeファイルを追加して以下のように書けばOK。(Rails.root/lib/tasks/statistics.rakeとかね)

task名がstatsetupなのはrspec-rails/lib/rspec/tasks/rspec.rakeでそうなっている為。cucumberでも同じ要領で大丈夫なはず。rake statsを実行するとちゃんと計算されている。

今の仕事についてつらつらと書く。今漠然と思ってることを書き出しただけなので、そんなに意味のある内容でもないかも。

アジャイル

そもそも何をもってアジャイルと言うのか、中々難しいところではある。昨日から読んでる「間違いだらけのソフトウェア・アーキテクチャ」では僕はアジャイル(開発)というのは、できればアジャイル宣言を守るか、守る努力をしているものだけに、その名前を冠してほしいと思っているけど・・・。とある。そういう意味だと改めてうちのチームでもアジャイル宣言を確認するべきかもしれない。

何はともあれ、今うちのチームではCTOのちゃんとアジャイルな開発をしていきたいという想いからいくつかのプラクティスを実践している。イテレーション、プランニングポーカー、バーンダウンチャートなど。まだまだチームとして未熟な為、見積りの精度ややり方が少しうまくいっていない気はするけどこの辺りは徐々に改善されそう。

特にポイントを付けたことで、今週に終わらせないといけないポイント量や、バーンダウンチャートで間に合うのか間に合わないのかがわかるのがいい。現時点で正直色々と間に合っていないのだけど、納期と言うか1回目のリリースのタイミングは既に決まっていてそれはずらすことが出来ない。その代わり1回目のリリースに向けてストーリーを削れないかという交渉をしたりした。以前は(実は以前お世話になったところで個人として契約して仕事している)そもそもこう言う交渉すらなかったのでいい兆候だと思う。

ただ、削ってもまだ間に合わないのでここは残業や土日でカバーをするしかないのが残念なところ。土日や残業で消化したポイントをベロシティに含むと正しいベロシティが出ないのかなと少し思ったけど、残業や土日作業は一時的なもの(リリースが今月)なので、そのうち誤差としておさまっていくのかな。

最近コードを書くことに集中していたので改めてこの辺も勉強しなおすべきかなとちょっと思っている。とりあえず、「アジャイルな見積りと計画づくり」を読み直そうと思う。

ネガティブな感情

実は最近自分自身にあまり良くない兆候がある。漠然とだけど、汚いコードや落ちてるテストを見ると「なんでちゃんとやれないんだ」という少しネガティブな感情があることにここ数日気づいた。念の為言っておくと、「テスト落ちてますよー」と言えばすぐ直してコミットしてくれるし、汚いコードと言うのもエンジニア同士でよくネタにする「ひどいコード」みたいなものではなく、「もう少し上手く書けるよなー、これ」と言ったもの。

つまり、コードの質に拘るあまり若干過敏になり過ぎてる部分がある気がしてる。もちろんコードは出来る限りきれいに書くべきだとは思う。ただ、そこに拘り過ぎて本来の目的を忘れちゃいけないと思う。今の目標は最初のリリースに間に合わせることで、細かいリファクタリングや修正はその後でも出来る。

テスト駆動開発

テストコードの量を見る限り少し不十分な部分もありそうだけど、少なくとも全くテストが無いって部分は無くなってきてる感じ。バグがあった場合も「再現するテストコード書いて修正してください」で済むのでいい感じ。TDDに関してはそれなりに習得していると思うので、チーム内で不十分だなと思ったところは上手くサポートしていきたい。例えば僕が率先してテストコードを書けばそのコードから他のメンバーも書き方を知ることができるみたいに。

steak

今回、受け入れテストをsteakで書いてる。今のところ僕が書いてるだけだけど。実はまだチーム内でcukeにするかsteakにするかハッキリ決まってない。と言うのももしかしたらcukeのシナリオをエンジニアじゃない人が書く可能性があるから。ただ、結局テストデータを用意する必要があったりとかで中々難しいのかなとも思う部分もある。この辺@moroさんとちょっと話してみたいな。

git-svn小話

git-svnについてはこの間も記事にしたけど、少しだけ補足。

topic branchをmergeする前にgit rebase master

gitはmergeした時にmerge commitを作るときがある。コミットメッセージがデフォで「Merge branch ‘hoge」みたいになっている奴。これをそのままgit svn dcommitするとその「Merge branch ‘hoge’」のコミットだけsvn側に反映される。これだと他の人が具体的にどんなコミットかよくわからない。なので、branchをmergeする前にmasterでgit svn rebaseしてbranch側でgit rebase masterをすると良い。これで履歴が一直線になるのでmerge commitが作られずsvn側にもちゃんとbranch側の各コミットが反映される。

topic branchは作業が終わるまでmasterの変更を取り込まない

この辺の話は「入門Git」に詳しく書いてあったので細かくは話さない。何となしに、作業中のbranchに最新のmasterをrebaseしたら落ちてるテストがコミットされててちょっと面倒だったので改めて思い直した次第。

Rails3.0とRuby1.9.2

今のところ目立って困ってる所はなし。主要なライブラリもRails3.0に対応してきたし、結構実務でも使えるのではなかろうか。ただ、日本語の情報があまりなくRailsGuides(僕は大体edgeを見てる)や、http://railsapi.com/や海外のブログを見ながら手探りな感じの部分もあったのでその辺は少し大変かも。個人的には今後Rails2系を使う理由はないかなといった所。個人的にはArelがお気に入り。Arelについては@a_matsudaさんのRuby Freaks Lounge 第43回 Rails 3を支える名脇役たち その1 – Arel -やActive Record Query Interfaceを読むといいです。

本当につらつらと書いただけになったけど、ここまで読んでくれた人ありがとうございました。

普段のプログラミングにgitを使用しているのだけど、実際の現場ではまだまだsvnが主流だったりする。svnを直接使ってもいいのだけど、やはりローカル上でコミットしたいとか、複数のコミットを1つにまとめたいとか、トピックブランチを切りたいとかあるのでそれはsvn単体だと厳しい。そんなわけでBetter SVNとしてのgit svnの紹介、と言うよりメモ。

リポジトリのクローン

git svn clone repository_url

これでsvnリポジトリをgitリポジトリとして取得できる。大きめのリポジトリだと結構時間がかかるのでのんびりと。svnリポジトリの構成がtrunk/branches/tagsという一般的な構成であればオプション-を付けるのがおすすめ。trunkをmaster、branches/tagsをremote branchとして扱うようになる。個別に指定する方法もあるのでhelp参照。

git svn clone -s repository_url

リポジトリの更新

git svn rebase

svn upに相当する。remote brancheのtrunkをgit coしてそれをmergeする方法もあるけど、基本はこれで問題ない。

リポジトリへのコミット

git svn dcommit

これはsvn ciに相当するって言うと、少し違う気もするのだけどsvnリポジトリにコミットするっていう意味だと同じ。git pushの方がイメージに近い。ローカルにたまっているコミットをsvnリポジトリにpushする感じ。ローカルにコミットされていない変更があるとdcommitできないので、その時はgit stashする。

git stash
git svn dcommit
git pop

ブランチの作成

git svn branch name

trunk-masterでやり取りするだけだったら、上記さえ覚えておけば後は普通のgitリポジトリと同じ。gitのブランチを作るのは通常のgitリポジトリと同じだけど、svnのブランチを作るにはこのコマンドを叩く。この時点でsvnリポジトリにコミットされるので注意(–dry-runオプションはある)。-mオプションでコミットメッセージを書ける。指定しない場合は「Create branch name」となる。

svnリポジトリの別のブランチや、ローカルのgitリポジトリのブランチから新しくブランチを作る場合には後ろに名前を指定する。

git svn branch name remotes/branch
git svn branch name local_branch

ブランチのチェックアウト

git co -b branch remotes/branch

svn switchに相当。git svnはsvnのbranches/tagsをremote branchとして扱うのでそれをgit coすればいい。これは上記のgit svn branchで作成したものも同じ。

ブランチ間のマージ

git merge --no-ff branch_name
git svn dcommit

マージは通常のgitとほぼ同じ。注意しなくてはいけないのは–no-ffが必要なこと(参考: http://webtech-walker.com/archive/2010/03/26101332.html)。

ブランチの削除

svn rm branches/name #svnリポジトリをcoしてそこで
git branch -r -d name #git-svnのgitリポジトリ上で

現時点(v1.7.0.6)ではsvnリポジトリのブランチを削除するコマンドは用意されていない模様。なので直接svn上でブランチを消して、git側のremote branchも直接消すしかないと思う。

どのブランチにコミットされるのか

git svn info

もしかしたら、今いるgitリポジトリのブランチでgit svn dcommitしたらsvnリポジトリのどのブランチにコミットされるのかがわからなくなることもあるかもしれない。その時はgit svn infoで表示されるURLをみればよい。

ignoreの設定

git svn create-ignore

ignoreは少しややこしいんだけど、svn側とgit側の2つ存在する。このコマンドはsvn側のignore設定を.gitignoreとして出力する。ちなみにsvn側のみignore設定してある場合、当然git側ではignoreされずgit svn dcommit出来てしまう。その場合、svn側のignoreも無視して通常通りコミットされてしまうので注意。

まとめ

git-svnでの開発はsvnの面倒なところをカバーしてくれたりするので非常にオススメ。もちろん全てがgit-svnで出来るわけでもないので、その辺は諦めて直接svnを使う必要もある。ある意味、最悪わからなくなったらいつでもsvnに戻ればいいのでとりあえず試してみるといいと思う。

ちなみにgitに詳しくない人は濱野さんの入門Gitがおすすめです。

9日に開催されたmitaka.rb#10に参加してきた。何だかんだで3回目の参加。今回のmitaka.rbは主催の@ysakakiさんと協賛の(株)HatchUpさんの圧倒的財力により、なんと3000円というお得な会でした。飲み放題だし、ご飯もとてもおいしかった。おかげで今日は若干二日酔いです。

今回は@takahashimさんが参加されてて、たまたま席が近く色々とお話が出来て楽しかった。実はあまりちゃんと話したことがなかったのでよかった。後はTokyo Rubyist Meetupから@pwimさんが来られてて少しお話した。9月22日にKickoff Partyをやるとのことなのでみんな参加しよう!

今回もLTがあって、わざわざ群馬から車で来られてる人がいた。フットワーク軽いなー。@bash0C7さんがChiba.rbとShibuya.rbと東京RubyKaigi04について発表してた。Shibuya.rbは今丁度渋谷勤務なので参加しようと思う。東京RubyKaigi04はスタッフまたやろうかなとも思ったけど、「初めてだけどスタッフやりたい!」って人が多そうだったら一般参加者になるかも。割と気分次第。

帰り際、「実はえにしテックってどちらが社長か知らないんですけど」って言われたらすごい笑われた。本当に知らなかったんだよね。@takahasimさんに放流されてしまった。今は一応把握してます。多分。

そんなわけで、主催の@ysakakiさんをはじめ、スタッフ、お店の方々ありがとうございました。