UKSTUDIO

どうやら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さんをはじめ、スタッフ、お店の方々ありがとうございました。

ちょっと色々わからなくなったので、誰かのアドバイスを期待してここに書く。

簡単に前提を書くと、UserモデルのCRUDとは別にUserのパスワードを変更する画面が必要になった。Usersコントローラにpassword_editみたいなactionを書くのもあまりきれいじゃないなと思ってコントローラを分けることにした。

resources :users do
  resource :password
end

確実にUserのレコードは必要になるので上記の用にネストさせることにした。ここで気になるのがpasswordのコントローラ名。通常PasswordsControllerになる。ただ、PasswordsController内の処理は確実にUserに依存する処理が入るため、これはこれであまりしっくりこない。別にPasswordsControllerを他で使う予定があるわけじゃないけど、User::PasswordsControllerの方がいい気がする。

resources :users do
  resource :password, :only => :edit, :module => 'user'
end

# app/controllers/user/passwords_controller.rb
module User
  PasswordController < ApplicationController::Base

ただ、たかがあるモデルのカラムの為にここまでする必要があるのか?そもそもリソースじゃないよなと思ったりもするわけで。やっぱりUsersコントローラにactionを用意する程度に留めるべきなのだろうか。

追記:10/09/11

やっぱりコントローラを作る(というよりresourcesを追加するのが)がおかしいと思いはじめ、結局気にしてるのはURLなので以下のようにしてみようかなと思う。

resources :user do
  match 'password/edit' => 'users#password_edit'
end

新書なのでサクッと読めた。おもしろかったので簡単に紹介する。

このような背景から、「外国語学習」という現象そのものを対象とした学問分野が1960年代ごろから発達してきました。これが、「第二言語習得(Second Language Acquisition = SLA)」という新たな研究分野です。

書名にある第二言語とは、上記の引用の通り比較的新しい学問で、主に「第二言語習得メカニズムの解明」と「どのような習得方法が効果的か」という問題を扱うとのこと。

ちなみに第二言語 = 英語というわけではなく、母国語を第一言語として、それ以外の言語については全て第二言語として扱うらしい。日本語話者が英語を習って、次にロシア語を習った場合でも、ロシア語は第二言語と呼ばれる。

そもそも僕がこの本を手にとったきっかけは「いい加減、科学的に正しい英語学習法が確立されてていいんじゃないの?」という疑問なので、この本はそういう疑問に対して丁度よさそうだったため。

結論から書くと、現状「正しい英語学習法」というのは確立されていないらしい。とは言え、今までの研究でわかってきたことをベースに、ある程度の方向性は見えてきているようで、この本に目を通しておけば少なくとも巷の「うさんくさい英語学習法」に騙されることはなくなりそうではある。

何にせよ、英語学習者、英語を教える側、子を持つ親(子供の言語学習についても触れられているため)など英語に関わる人は読んでおいて損はない本であるのは間違いない。もちろん「第二言語習得」という研究に興味がある人もその取っ掛かりとしてはいい本だと思う。

ちなみに英語を学習するための効率的な方法を知りたいという人は6章の「効果的な外国語学習法」だけ読んでおけば十分かとも思うが、そんなに量の多い本でもないし、残りの章も読むことをおすすめする。読み易いし、内容もおもしろいので、ちょっとした読み物気分で読めばいいと思う。

9月からやる仕事がめでたく、Rails3.0 + Ruby1.9.2のお仕事なので色々と環境構築。とりあえず自動テストまわりやりました。

一応、環境を他と切り分けるために、rvmでアプリ用にgemsetを用意。アプリごとに簡単に環境を構築できるrvmマジ便利。

gem install bundler --pre
gem install rails

まずは、bundlerとrailsをインストール。次は適当なアプリを作って必要なgemのインストールなどを行う。テストはRSpecで書くので、-TをつけてTest/Unitは使わないようにする。

rails new demo -T

次に必要なgemをGemfileに記述。rspecとかを「テストだけだから」と思って、gropu :testにしたら、モデルを作成したときにTest/Unitのテストコードが作られたりしたので注意。githubのWikiを見るとautotestのgemは不要そうなんだけど、実際ないとうまくautotestが動かなかた。

bundle install

あとはモデルを作って、テストが実行できればOK。

rails g rspec:install
rails g model user
rake
autotest

追記

Twitterで@conceal_rsさんから補足ありました。ありがとうございます!

via http://www.flickr.com/photos/recompile_net/sets/72157624694727057/

少し間があいたけど、今年のRubyKaigiについてつらつらと書こうかな。

スタッフ参加してみて

今年はスタッフとしての参加だったのだけれど、RubyKaigiのスタッフは東京RubyKaigi03の時にやっただけなので、本家の方は初めて。3日間と結構な長丁場なのでうまく立ち回れるか不安だったのだけど、自分なりにはそれなりに頑張れたのではないかなと思う。

ひとつ前のエントリでも書いたけど、担当はレポート班でした。当日スタッフに応募する前はrubykaigi.orgの制作・実装の方も手伝っていたけど、実質ほとんど何もしていない・できなかったのでスタッフとしては90%ぐらいはレポート班な感じ。

レポート班はある意味発表を見るのが仕事みたいな部分もあったし、文章を書くのも割と好きなので、RubyKaigiを楽しみつつ仕事も楽しむという割とおいしい感じに過ごせた。自分の語彙の少なさや英語力のなさなど色々と痛感した部分もあるけど、楽しくやることが出来ました。

今年は開催が筑波ということで、スタッフの大半はホテル山久(#hotel39)に泊まったわけだけど、本当に楽しかった。#hotel39_107 の楽しさは異常である。あの感じはなんだったんだろうなぁ。

実はChad Folwerの基調講演と高橋さんのclosingから、色々な想いがまざって泣きそうになってた。未だにその時の気持ちが整理できていないのだけど「Chadに励まされてる感じ」「今年のRubyKaigiが終わる感じ」「来年でRubyKaigiが終わる感じ」「3日間の疲れ」あたりの気持ちが色々と混ってよくわからない感じになったのだと思う。

元々、この手の技術系カンファレンスは情報を仕入れに来てるタイプだったので、まさか泣きそうになるとは自分でも意外だった。多分、一般参加してそうなるとは思えないので、やっぱりスタッフとして参加したのが大きかったのかなと思う。

来年のRubyKaigi

最後のRubyKaigiと言うことで、自分なりに何を成し遂げたいか簡単に書いておく。

ひとつは発表者として参加すること。やっぱりあの場で話すのは一種の憧れみたいなものがあるにはあるので、それを憧れで終わらせない為にも何か話したい。一応話してみたいことはちらほらあるので、1年あれば十分まとめられるはず。

あとは、書き始めてるアレを間に合せたい。あわよくばサイン会・・・実質、ほとんどまだ手が動いていないのでいい加減動かないとまずい。

最後はやっぱりスタッフ参加かなぁ。本当に終わってしまうのであれば、最後はスタッフとして見届けたい。

さて、いよいよRubyKaigi2010前日となりました。僕は今日の夜に筑波入りをする予定なのですが、初スタッフ参加ということもありすでになんかそわそわしています。

ところで僕の所属はKaigiFreaksレポート班なのですが、既にスタッフ業としてRubyist Magazine 日本Ruby会議2010直前特集号と、gihyo.jpにRubyKaigi2010直前レポートを一部書きました。まだ読んでいない方はぜひ読んでみてください。直前特集号の中にRubyKaigi2010参加者のしおりがありますので、参加者の方は明日以降のRubyKaigi2010に向けて目を通しておくといいと思います。

当日はgihyo.jpにて当日レポートを行います。このレポートはRubyKaigi2010スペシャルレポートに掲載される予定です。

そんなわけで、ちょっとしたレポート班の宣伝でした。会期中はレポートを書きながら会場をフラフラしてると思いますので、気軽に声をかけてくださいまし。ではでは、RubyKaigi2010楽しんでいきましょー。

今のところ仕事、プライベート共にメールは全部Gmailでまかなっているのでそこらへんのtipsとかをまとめておきます。

mailtoをGmailにする

PCでGmailを使うにあたってメーラーを使わずWebで済ませていますが、その場合mailtoをクリックしたときに使ってもいないMail.appが起動してしまったりと困る場合があります。

その場合、Google Notifierを使うと便利です。Google NotifierはGmailの受信通知やGoogle カレンダーのリマインダ通知などをしてくれるアプリですが、簡易的なメール送信機能もありmailtoにそれを指定することができます。メーラーを使うほどでもないけど、通知とmailtoの設定ぐらいはしたいという時に便利なアプリです。設定は設定画面のAdvancedタブにあります。

複数のメールアカウントを1つのアカウントに統合する

実は普段使うメールアカウントを2つ程持っています。理由は元々Gmailドメインをそのまま使っていたのですが、仕事の都合上独自ドメインでも運用したくなりGoogle Appsで改めてアカウントを取得した為です。2つアカウントを持っているとそれぞれログインしなおしたりするのが面倒なので1つのアカウントに統合すると便利です。

とりあえず、普段使用したいアカウントをA、統合してしまいたいアカウントをBとします。

まず、受信ですがこれは単純に転送設定を用います。アカウントBでログインし、「設定」から「メール転送とPOP/IMAP」から転送アドレスを追加します。後は好みでアカウントBのメールはアーカイブするなり削除するなりすればいいでしょう。アカウントAでは一応わかりやすい用にアカウントBから転送されたメールにはラベルを付けるようフィルターの設定をしています。

次に送信です。実はGmailにはFromのアドレスを独自に設定することが出来ます。アカウントAの「設定」から「アカウントとインポート」を選び、そこにある「別のアドレスからメッセージを送信」を選びます。後は指示に従ってアカウントBのアドレスを設定します。これでアカウントAにログインした状態からアカウントBとしてもメールを送ることが出来ます。

同じく、「アカウントとインポート」から「メッセージの受信時」の設定を「メールを受信したアドレスから返信する」にしておくと返信の際にアドレスが変わってしまうということがなくなります。これでHT-03Aなどでも受信したアドレスで返信することが出来るようになります。

参考: 独自に設定した [From] アドレスの追加

ただ、GmailやGoogle カレンダーは複数アカウントに対応しはじめたみたいなので人によってはわざわざこういう設定をする必要はないかもしれません。ただ、僕の場合HT-03Aがアカウントの切り替えに対応しておらずしばらくはこの設定で運用することになりそうです。

グループに登録してある人にまとめてメールを送信する

Googleの連絡先には「グループ」という概念があります。グループに連絡先をまとめておくことで、まとめてメールを送信することができます。MLを用意する程でもないけど複数人数で話題を共有したいというときにちょっと便利です。

やり方は連絡先にグループを作り、そこに連絡先を登録しておきます。後はWebでメールを新規に書くときにFromの欄でメールアドレスと同じようにグループ名がサジェストされるのでそれを選択するだけです。後は自動的にメールアドレスが補完され記入されます。

参考: 連絡先グループのメンバー全員にメッセージを送信するにはどうすればよいですか。 – Gmail ヘルプ

ラベルをネストにする

Gmailにラベルという機能があります。ラベルはそれぞれ独立しており、そこに特に関係性はありません。しかし、Gmail Labsにある「Nested Labels」を使えば名前の通りラベルをネスト構造にすることができます。「設定」から「Labs」を選び「ラベルのネスト」(日本語版の場合です)を有効にし、あとは適切にラベルを設定するだけです。例えば僕の場合「ruby/ruby-list」「ruby/rubykaigi」と言った感じでラベリングしています。

ただ、紹介しといて何ですがそんなに便利でもないかなーというのが正直なところです。ですが、サイドバーのラベルが折り畳めるようになるのでラベルの数が増えてきて整理したいという場合にはそれなりに便利なのではないかと思います。