Blog on AIRS

JIRAとGitでDRYなワークフローを実践する

2011-12-18T00:00:00+09:00

こんにちは、加藤です。誰かに振られたわけではなく自主的に、JIRA Advent Calendar 2011の17番目として参戦します。

ジラリアンとしては、１年半位前にEatwitという自社製品のiPhoneアプリの開発からJIRA+GreenHopper / Confluence / Fisheye を使い始めて、ようやくひと通りの機能が使えるようになってきたレベルです。その前はTracを使っていました。受託案件ではRedmineも使っています。

Fisheye経由でJIRAとGitを連携

エアーズではバージョン管理にGitを使っています。共有リポジトリはJIRAやFisheyeと同じサーバー(Mac mini)にgitosisというソフトウェアを使って設置してあります。プロジェクトによっては、GitHubやBitbucketも使いますが、社内にある共有リポジトリは速くて快適です。

Gitの共有リポジトリをFisheyeに登録し、JIRAのFisheye設定でJIRAプロジェクトとFisheyeリポジトリのマッピング設定をすると、JIRAとGitを連携させることができます。具体的には、GitのコミットメッセージにJIRAの課題IDを含めることで指定されたJIRAの課題のアクティビティとして各コミットが記録できるようになります。

また、Fisheye 2.7で導入されたスマートコミットを利用すると、コミットメッセージに簡単な構文を追加することで、ワークフローのトランジション、コメント、時間の記録など、JIRAの課題を自動的に更新できるようになるそうです（筆者のバージョンは2.5系なので未確認...orz）。スマートコミットについては、@g2gjさんの下記の記事が参考になると思います。

FishEye および Crucible 2.7 – Git レポジトリ管理、スマートコミット、より強固になった JIRA との統合

git-jiraによる課題ベースのJIRA/Git連携ワークフロー

Stéphane ÉpardaudさんがGitHubで公開している git-jira を使うと、作業の開始／終了時に良くおこなうJIRA/Gitの一連の操作を、それぞれ1コマンドでおこなうことができるようになります。あらかじめJIRA Command Line Interfaceが必要です。

% git jirabranch FOO-123

課題:FOO-123と同じ名前のブランチ:FOO-123を作成
ブランチ:FOO-123にスイッチ
課題:FOO-123のステータスを進行中に更新
課題:FOO-123にコメントを追加＞ "Coding started by Masakuni Kato"

% git jirafix FOO-123

ブランチ:FOO-123にスイッチ
ブランチ:FOO-123にブランチ:masterをrebase
ブランチ:masterにスイッチ
ブランチ:masterにブランチ:FOO-123をマージ
課題:FOO-123のステータスを解決に更新
課題:FOO-123にコメントを追加＞ "Fix committed by Masakuni Kato"

課題に着手するごとにトピックブランチを切るというのは良い習慣ですね。作業の開始や終了時にコメントを入れるのも、他の開発者とのコミュニケーションに役立つ良い習慣だと思います。これらの手順を1つのコマンドで実行できるgit-jiraはチョー便利。オススメです。

ちなみに、jirabranchとjirafixと打つのは長くてシンドいので、筆者はそれぞれjbとjfというaliasを設定して使っています。

% git config --global alias.jb jirabranch
% git config --global alias.jf jirafix

コミットメッセージにJIRAの課題IDを含める

GitのコミットメッセージにJIRAの課題IDを含めるだけで連携することが分かっていても、開発者にお願いしただけではついつい書くのを忘れてしまいがちです。

git-jiraでは、コミットメッセージに課題IDやタイトルを自動的に含めるためのGitのフックスクリプトも提供しています。ただ、スクリプトで使われているsedやawkがMac標準のものだと動かなかったり、タイトルに日本語が含まれていると文字化けしてしまったりするので使いづらいかもしれません。

git-jira / prepare-commit-msg
https://github.com/FroMage/git-jira/blob/master/prepare-commit-msg

筆者は、いまのところブランチのチェックアウト時にブランチ名を含んだメッセージテンプレートを作成するpost-checkoutフックと、Gitの設定commit.templateの組み合わせで対応していますが、まだ研究中です。他に良い方法があれば教えてください。

まとめ

JIRAとGitの連携について簡単に紹介してみました。JIRAやConfluenceを使っていると、スペックシートだけでは解らない細かな部分での使い勝手の良さに感心することが多いのですが、いかに良いツールでもうまく活用してあげなければ宝の持ちぐされになってしまいます。

今後も、JIRAの豊富な設定や拡張機能を利用してジラリアンとしてのレベルをアップしていきたいと思います。なんといっても色々試すのは楽しいですしね。

では、引き続きJIRA Advent Calendar 2011をお楽しみください。と書きましたが次の方がまだいないみたいです。どなたか、立候補を！

第2回浜松ハッカソン(ハマッカソン2) 開催レポート

2010-12-06T13:00:00+09:00

12月4日の土曜日にエアーズの入居するインキュベーション施設のハイキューブで、「第2回浜松ウェブAPIハッカソン」をおこない、開発メンバーと見学者あわせて計25名の方にご参加いただきました。

今回のテーマ

今回のハッカソンでは3チームが、メインテーマである「モバイル」に沿って実際に動くプログラムを当日の10:00から17:00にかけておこない、最後に成果発表と参加者・見学者全員による投票をおこないました。以下、上位順にチーム別の発表内容と感想です。

1位: Androidチーム – 「自宅から離れたら勝手にマナーモード」「ケモノカメラ」「ワンセグでTwitter」

Androidチームのプレゼン中

投票の結果iPhoneチームと同数票となり、歴史的な同点決勝(後述)によって一位になったのは @amay077 さん、 @kiwofusi さん、 @w1mvy さん、 @natsumesou さんと私 @mackato のAndroidチームでした。@amay077さんと@mackato以外は静岡大学の学生さんです。

今回のハマッカソンでは、チームのメンバーで同じものを作っても、各メンバーで別々のものをつくっても良いルールで、Androidチームは各自別々のものを作って3人が発表しました。

まずAndroidチームのトップバッターとして発表し、今回のハマッカソンで一番感心を集めていたであろうのが@amay077さんの「自宅から離れたら勝手にマナーモード」です。GeoHexという地図上に表示された六角形の領域を使って、あらかじめマナーモードにしたいエリアを設定しておくと、そこに入った時に自動的にマナーモードになるというアプリです。

家や会社でAndroidケータイのマナーモードをいちいち切り替えるのがメンドクサイというご自身のニーズから作ったアプリということで実用性があるうえに、実際の人間の代わりに地図上を移動するプログラムを用意して、それがマナーエリアに入ってきたらそれまで流れていたラジオを止めるというデモもバッチリで、会場から感嘆のため息がもれてました。

あらかじめエリアを設定しておくと…

ラジオを流しておいても、あとでエリアに入ったときに音声が消えます。

発表後の質疑応答では、「今日だけで全部作ったんですか？」などAndroidチームの中ではこのアプリに質問が集中していましたね。

@amay077さんのあとでは学生さんも発表しづらいだろうということで、続いて私が作った「ケモノカメラ」を発表しました。「ケモノカメラ」はAndroidの音声認識とカメラを使ったネタアプリで、実用性はありませんが笑いはとれたので本人的には狙い通りです。

「ケモノになれ！」ボタンを押して音声認識APIを起動し、「ワン」とか「モー」とか動物の鳴きまねをするとカメラに写っている人の上に犬や牛の写真が顔抜きオーバーレイで表示され、「お前は犬だ！」などと罵倒されます。ちなみに「ニャー」は激ムズで、認識されずに「お前は人間だ！」となかなかケモノ扱いしてもらえません。

モーと叫ぶと…

カメラに写った助手のT君が牛になりました。

Androidチームの最後に、学生代表として@kiwofusiさんが「ワンセグでTwitter」を発表しました。ワンセグ画面の上にTwitterのタイムラインをオーバーレイ表示するアプリで、発表の時はTwitterの後ろでワンセグが動くところまでは行かなかったようですが、Twitterの検索APIを使って取得したツイートをオーバーレイ表示するところまでは出来ていました。完成したらニコ動みたいな感じで色々と使い道はありそうです。

ワンセグの画面のうえにツイートが表示されています。

@w1mvyさんと、@natsumesouさんは加速度センサーをつかったアプリを作っていたみたいですが、残念ながら発表できるところまではいかなかったようです。@amay077さんと私の大人二人は面目が立ってホッとしたので、「大人力を魅せつけた」とか「大人は納期を守る」とか好き勝手なことをほざいてあげました。若者よ、次回ガンバレ！

2位: iPhoneチーム – 「通信対戦型の時限爆弾アプリ」

iPhoneチームプレゼン中

投票の結果Androidチームと同数票となり、歴史的な同点決勝(後述)によって惜しくも二位だったのは、 @tinymouse_jp さん、 @arfyasu さん、 @youzz さん、 @sasakisasa さん、 @hide621 さんのiPhoneチームでした。

iPhoneチームは全員で協力して「通信対戦型の時限爆弾アプリ」を開発しました。BluetoothでつながったiPhone同士で時限爆弾を回していって、爆発したらアウトというゲームです。バラエティ番組で見たことがある、膨らむ風船を回して破裂したらアウトみたいなのをデジタル化した感じですね。

技術的にはiOSのGameKitというフレームワークを使ってBluetoothでiPhone同士の通信をおこない、その中の1台がサーバーとなってゲームを管理しているということでした。

ユーザー名を入力してゲームに参加

参加中のプレイヤーが各iPhoneに表示されて、そのうち1台に爆弾が表示されています。

今回は完成までいきませんでしたが、「ネットワークでプロフィール画像をやり取りしてアイコン表示する」とか、「加速度センサー使って端末を振ってバクダンを渡す」という機能を追加していずれ公開するそうです。開発の中心になっている@hide621さんは、すでにApp Storeに10本以上アプリをリリースされているので、これもApp Storeで公開されるのかな？
Lapture.net/@hide621さんのブログ

ちなみに、Androidチームのエース@amay077さんとiPhoneチームのエース@hide621さんはともに豊橋からの参加です。二川恐るべし！

3位: HTML5チーム – 「認証UI: Andoroid風のロック解除 / 金庫のダイヤル風」

HTML5チームプレゼン中

最後に惜しくも3位となったのが、 @akisoftware さん、 @jacoyutorius さん、 @katsu2000x さん、 @cherenkov さん、プラス見学組から飛び入り参加のウェブデザイナー @planpot さんのHTML5チームです。

こちらのチームもiPhoneチームと同様にメンバー間で協力しての開発です。「認証UIをHTML5で実現」というアイデアをもとに、Andoroid風にマトリックスを指でなぞってその軌跡でロックを解除するUIと、金庫のダイヤル風に左右にダイヤルを何回か回してロックを解除するUIをHTML5のキャンバスで実装して発表されました。

AndroidチームやiPhoneチームに比べてハードウェアの機能をフルに使えない点や、認証UIという部品ということで投票的には不利だったと思いますが、機能的にはどちらのUIも完成していましたし、Android風の方は@planpotさんが協力したUIデザインもカッコ良くてレベル高いです。

Androidのロック解除風のログイン画面

指でなぞると軌跡が表示されます。動きもスムーズ！

こちら金庫のダイヤル風。怪盗ゲームとかで使えそう

Android風のロック解除のメイン開発者の@akisoftwareによると、こちらのコードはいずれオープンソースで公開されるそうです。

おまけ「同点決勝」

前述の通り、みんなの投票ではAndroidチームとiPhoneチームが同点となり「同点決勝」をおこなうことになりました。はじめ私が「じゃぁジャンケンで…」とジャンケンで決めようとしたのですが、その時、いつの間にか見学していた @tetsu1969 さんから「ニャーで決めればいいじゃん」というナイスなキラーパスが出ました。同点決勝はケモノカメラに「ニャー」と叫んで猫が出たほうが勝ちに決定です。

先行はiPhoneチーム、エースの@hide621さんがケモノカメラを起動したギャラクシータブにむかって「にゃ〜」とやさしくささやきます。「認識中です」のあとに出た画面は…残念「お前は人間だ！」。

つづいてAndroidチーム、@amay077さんが「ニヤー」と力強く叫びます。「認識中です」のあとに出た画面は…「お前は猫だ！」。ヤッター！開発中に、となりで「ワン」とか「ニャー」とかいってた甲斐がありました。

ということで、最後はドラマチック？な展開で一位が決まった今回のハマッカソン、前回よりこなれてきて運営側も参加側もレベルが一段あがった感じで、個人的には大成功でした。他の人はどうだったのかな？次回は3月前半の予定です。テーマとか要望があればTwitterで @hamackathon まで。

参加者、見学者全員で記念撮影

デモ用に用意したハンディカムとゴリラポッド

忘年会シーズンとぶつかってしまった懇親会はアバンギャルドな配席に

Trac+SubversionのようにJIRA+Gitで作業時間を記録する

2010-09-27T10:00:00+09:00

エアーズではこれまでプロジェクト管理ツールとしてTracとそのScrumプラグインの Agilo を使っていたのですが、今年の春から Atlassian社のJIRA と GreenHopper も使い始めました。

理由はAtlassian社のツールの方が操作が軽快で機能も優れていたこと、10ユーザー以下であれば各ツールのライセンスをわずか1,000円で購入できるスターターライセンスを利用できたことなどからです。JIRAとGreenHopper以外に、 Confluence 、 Bamboo 、 FishEye 、 Crowd も導入済みです。

現在は、お客様のプロジェクトはTrac(Agilo無し)、社内プロジェクトはJIRA+GreenHopperを使って管理しています。

今回やりたいコト

Tracでは Timing and Estimation Plugin というプラグインとSubversionのフックスクリプトを使って、コミットメッセージに特定の書式を含めると自動的に作業時間を記録できるようにしています。

例えば、チケットNo.3で1時間半の作業をしたら、以下のようにコミットすることで該当するチケットに作業時間が追加されます。

% svn commit -m "refs #3 (1.5) テストデータを追加"

これと同じような機能をJIRAで探してみましたが無いようでしたし、Gitを使ってローカルコミットのタイミングでこまめに作業を記録したかったので、カスタムスクリプトを作成して対応することにしました。

具体的には、例えばDragonプロジェクト(キー:DRA)のチケットNo.3で30分の作業をしたら、以下のようにコミットすることで該当するチケットに作業時間が追加されるようにします。

% git commit -a -m "DRA-3 (.5) テストデータを追加"

jira4rのインストール

今回のカスタムスクリプトはRubyで作成しました。JIRAのSOAPサービスのドライバであるjira4rが必要になりますので、あらかじめgemでインストールしておきます。

% gem install jira4r

JIRAのSOAPサービスはデフォルトで有効になっているのでJIRA側で特別な設定は必要ありませんでした。JIRAのSOAPサービスやjira4rの使い方については以下のドキュメントが参考になります。

git configにJIRA連携用の設定を追加

次にgit configにJIRA連携用の設定を追加します。JIRAでは複数プロジェクトを管理できるので、URLとユーザー名とパスワードはグローバルに設定できます。

% git config --global jira.url https://www.example.com/jira/ # JIRAサイトのURL
% git config --global jira.user kato # JIRAユーザー名
% git config --global jira.pass foobarbaz # JIRAログインパスワード

各プロジェクトのリポジトリでは、プロジェクトのキーの設定を追加するだけです。

% git config jira.project DRA # JIRAプロジェクトのキー

JIRA連携用のRubyスクリプトの作成と配置

JIRA連携用のRubyスクリプトを作成し適当なディレクトリに配置します。このスクリプトはどのプロジェクトでも共通で使用できるのでプロジェクト毎には必要ありません。僕はパスが通してある $HOME/bin に実行権限付きで置いています。

作成した後に気づいたんですが、 Grit のようなRubyからGitリポジトリを操作できるライブラリがいくつかあるので、それらを利用した方がスマートでしたね。今回は取りあえずgitコマンドを呼び出した結果を読み込んで処理しています。

プロジェクトのpost-commitフックに連携用スクリプトの呼び出しを追加

最後にプロジェクトのpost-commitフックに連携用スクリプトの呼び出しを追加します。

#!/bin/sh
# /path/to/project/.git/hooks/post-commit
# An hook script that is called after a successful commit is made.
...
# Add worklog to JIRA project.
$HOME/bin/git-jira-post-commit.rb

連携がうまくいっていれば、以下のようにコミットと同時にJIRAに作業ログが追加されます。

まとめ

今回の作業で、jira4rを使えば(インターフェイスはイマイチだけど)Rubyから簡単にJIRAのデータを操作できることがわかりました。レポートの作成にも使えそうなので、今後はお客様にも提案していきたいです。

あとJIRAはインストールやアップデートが結構面倒なのですが、それらがネックになる場合はGoogle Appsと連携できる JIRA Studio というホスティングサービスがあるので、予算があえばそれを使うのも良いと思います。

製品紹介を見る限りとても魅力的な製品で、エアーズでも有料版のGoogle Appsを使っているのでぜひ導入したいと思ったのですが、購入単位が5users、10usersと5人単位だったので断念しました。

1ユーザーあたり月額$25は高いとは思いませんが、うちのような小さな会社では取りあえず2、3人で使うため利用料が半分ぐらい無駄になるのは勿体無いので、1ユーザー単位でも購入できるようになったら検討してみたいと思います。

オススメ書籍

アジャイルな見積りと計画づくり <価値あるソフトウェアを育てる概念と技法>
JIRA+GreenHopperを使ったプロジェクト管理をおこなうならマストな1冊。
ただただしさんのAmazonレビューが秀逸。

第1回浜松ウェブAPIハッカソン開催レポート

2010-09-06T13:00:00+09:00

先週9月4日の土曜日にエアーズの入居するインキュベーション施設のハイキューブで、「第1回浜松ウェブAPIハッカソン」を弊社主催でおこない、休日にもかかわらず見学もあわせて計16名もの方にご参加いただきました。

ハッカソンとは？

ハッカソンというのは、Googleなどが開発者向けによく開催しているイベントの呼称で、同じテーマに興味を持ったデベロッパーが集まり、丸一日かけてテーマに沿った開発を協力して行ないます。

浜松でもIT系の勉強会や、TwitterでのIT技術者同士のユルいつながりみたいなのは広まってきてはいるのですが、個人的に技術的なところでちょっと物足りなさを感じていたので、今回はハッカソンの名前や形式を拝借して、実際にコーディングをおこなえるイベントとして企画してみた次第です。

今回のハッカソンでは3名もしくは4名の3チームが、メインテーマである「ウェブAPI」に沿って実際に動くプログラムを当日の10:00から17:00にかけておこない、最後に成果発表と参加者・見学者全員による投票をおこないました。以下、投票上位順にチーム別の発表内容と感想です。

1位: ソーシャルアプリチーム – 位置情報つきでつぶやくmixiアプリ「なう」

@ilink_ito さんプレゼン中

厳正なる投票の結果、1位に輝いたのは @ilink_ito さん、 @nya023 さん、 @sasakisasa さん、 @take_hvn さんのソーシャルアプリチームでした。

「なう」は、mixiの画面上で自分の現在地を取得して、コメントと一緒にmixiボイスに投稿するmixiアプリです。まだmixi上で一般には公開していないようですが、「なう」からつぶやいた内容が以下のmixiボイスで確認できます。ソースの公開はしていないみたい＜メールで共有してマージしたらしい。

トッティさんのつぶやき

このチーム、昼食ぐらいまでオシャベリばかりしていてまったく進んでいる気配はなかったのですが、2時ぐらいから急にモクモクしだして、各自役割分担を決めて、最後に数分あまらせてキッチリ仕上げてくるあたりは流石でした。特に位置情報を取得するのにブラウザのAPIを使うあたりは、ハッカソンのような限られた環境で動けば良い状況にあわせた手段で関心します。

ボクもこのチームに投票したんですが、mixiアプリとして、見た目のつくりこみまでは無いにしてもひと通りキッチリ完成していたこと、 @ilink_ito さんが発表でキッチリ笑いを取っていたこと(プレゼン重要)、が勝因じゃないかと思います。引き続き開発を継続したいなんていうハナシもあるみたいなので、そちらも期待しています。

2位: 情報収集効率化チーム – クーポンまとめサイト「リスポン」

@tinymouse_jp さんプレゼン中

2位は @tinymouse_jp さん、 @doya さんと、わたくし @mackato の情報収集効率化チームでした。

「リスポン」は、今流行のクーポンサイトをクロールして集めた情報をまとめて紹介するクーポンまとめサイト&iPhoneアプリです。実際のウェブサイトとそのソースコードは公開しています。iPhoneアプリの方は未公開です。

@doya さんがフロントページの作成を、 @tinymouse_jp さんがiPhoneビューワーの作成を担当し、ボクがGoogle App EngineをつかってウェブクローラーとRestAPIを担当しました。フロントページとiPhoneアプリの受け入れ準備はできていたんですが、ボクのクローラー開発が間に合わなくて、 QPod だけからクーポンのタイトルとエリア名ぐらいしか取得することが出来ず、結果ショボい感じになってしまったのが申し訳なかったです。きっちりフィールド決めてあったのに。。。

残念ながら1位は取れませんでしたが、この企画はやり方次第では化ける可能性があると思うので個人的にもうちょっと追いかけたいと思っています。 @em_design さんにかわいいロゴもつくってもらったので。

リスポンのロゴ(リスのシッポとタヌキのおヘソで出来てます)

3位: Twitterアプリチーム – キーワード"茶"を含んだつぶやきを返すTwitterボット「チャガッパ」

@youzz さんプレゼン中

3位は @youzz さん、 @arfyasu さん、 @em_design さんのTwitterアプリチームでした。

「チャガッパ」はTwitter上で話しかけてきた相手に対して、"茶"を含んだつぶやきを返す静岡ならではのTwitterボットです。たとえば、「疲れた」というキーワードを含むつぶやきに対して、「疲れたときはカテキン補給っ茶！」みたいなつぶやきを返します。Rubyクラウドホスティングの Heroku を使って開発や公開をおこなっていて、Twitterアカウントとして公開されています。ソースは未公開です。

チャガッパ

Herokuでの環境共有に手間取ったらしく充分な時間が取れなかったようで、残念ながら発表時に動かせるところまで開発がすすまなかったそうです。 @youzz さんが、発表が終わった後ボクに「クヤシイです！」って言ってくれてグッときました。そこまでマジになってもらえるのが主催者として一番うれしいです。次回リベンジ期待しています。

チャガッパでも @em_design さんは大活躍、速攻でサービスのゆるキャラ「チャガッパ」を産み出していました。

僕、チャガッパ！茶柱が立っているのは元気のしるしだよ！

番外: 見学チーム

@cherenkov さんのJavaScript講座

発表時間まではモクモクと作業するだけなので、見学だけで楽しいのかなー？と心配していましたが、 @cherenkov さん、 @jacoyutorius さん、 @tsstkyokku さんにも見学者として楽しい時間をすごせてもらったようで良かったです。

@cherenkov さんは、ボクからiPadをまき上げて「ハイ、見学者集合ー！」といきなりJavaScript講座をはじめたり、3時を過ぎたあたりからおやつを要求しだしたりとフリーダム全開でしたので、次回からは運営側にまわってもらうつもりです。（懇親会おごりでどう？）

@jacoyutorius さんには、朝から懇親会までガッツリ参加していただきました。そういえば、懇親会だけ参加していた人もいたなぁ。

@tetsu1969 さん、 @m_utsunomiya さん、 @akisoftware さんには、最後の発表の時に見学&投票で参加していただきました。 @tetsu1969 さんは @cherenkov さんが甘いものを欲しがっているタイミングでお菓子やジュースを差し入れしてくれたり、ボクが進行上で忘れていた質疑応答をナイスつっこみで思い出させてくれたりして、さすがにイベント慣れしている感じでした。見学者のみなさんも、次回はぜひ参加でお願いします。

参加者・見学者全員で記念撮影。みんなイイひとばかりだよ！

まとめ

最後の投票の時にアンケートも同時に取らせていただいたのですが、企画自体は概ね好評だったみたいでホッとしました。事前準備の期間や開発時間が足りないというご意見が多かったので、次回以降の参考にさせていただきます。

次回は、11月か12月頃「モバイル」をテーマに検討中です。ご意見やご質問はTwitterアカウント @hamackathon までお願いします。

あと、WiFi環境が悪く、ときどきつながらなかったり、スピードが遅かったりして、作業のボトルネックになってしまったようで大変申し訳ありませんでした。次回以降は改善するつもりです。参考までに今回のネットワーク環境をご紹介。Time CupsuleとAirMac Expressが共に初期のモデルなので、ここがボトルネックになっていたみたいです。あと、 PLANEXの無線LANエクステンダーは発売されたばかりで、まだ安定して動作しませんでした。

iBooks用にRuby on Rails GuidesのePubを自炊してみた

2010-06-04T13:15:00+09:00

先週の金曜日に日本でもiPadが発売になりました。エアーズでも業務用および開発用として3GモデルとWi-Fiモデルの各1台を購入し、電子書籍ビューワーや JIRA のダッシュボードモニタとして活用しています。

今回は、Rails 3のガイドドキュメントである Ruby on Rails Guides [Edge Guides] から、iPad用の電子書籍フォーマットであるePubファイルを作成してみたので、その手順を紹介します。

ePubとは

ePubとは、iPadの電子書籍アプリのiBooksやソニーの電子書籍端末で採用されている電子書籍ファイルフォーマット規格です。コンテンツをXHTMLで作成しCSSでデザイン制御をおこなえるので、ウェブコンテンツを作成したことのある人には馴染みやすいフォーマットだと思います。

ウィキペディア: EPUB

iPadやiBookストアについては、その閉鎖性について色々と抵抗もあるようですが、ePub自体はオープンな規格で誰でも作成できますし、作成したファイルはiTunes経由で簡単にiBooksのコンテンツとして転送できます。また、iBooksはHTML5にも一部対応していて videoタグで電子書籍に簡単に動画を埋め込むことができます。

iPad用の電子書籍フォーマットについても、PDFが良いとか、オープンで軽いウェブブラウザで見るタイプが良いとか色んな意見があるようですが、iPadのビューワーアプリの中では今のところiBooksが一番できが良いと思いますし、データのポータビリティに関しても問題ないと思うので、現時点で僕はePub派です。

Ruby on Rails GuidesからePubを自炊した手順

Ruby on Rails Guidesはウェブサイトとして公開されているので、ヘッダー・フッター・サイドバーなど電子書籍には不要な要素が含まれています。また、スタイルシートにも余分なデザインが含まれているのでそれらも削除する必要があります。

1. GitHubから最新ドキュメントのソースコードを取得

Ruby on Rails GuidesはGitHub上にあるRails関連ドキュメントのプロジェクト docrails の中でメンテナンスされているので、そこから最新のソースコードを取得します。

% git clone git://github.com/lifo/docrails.git

Ruby on Rails Guidesのサイトのソースコードは取得したdocrailsプロジェクト内の railties/guides になります。

2. レイアウトファイルとスタイルシートを変更しサイトを生成

Ruby on Rails Guidesのサイトは、コンテンツのソースコードから同梱のRubyスクリプト rails_guides.rb を使って生成します。その前に、ePub用にレイアウトファイルとCSSファイルを変更しました。変更内容は以下のとおりです。

gist: docrails_guides_epub.diff

変更が済んだら、サイトの生成をおこないます。出力先は output ディレクトリです。

% ruby rails_guides.rb

3. ePubライブラリEeePubをインストールしてちょっとイジる

ePub生成には jugyo さんが公開されている EeePub を利用しました。まず、gemでインストールします。

% gem install eeepub

EeePubはHTMLや画像、CSSといったコンテンツをePub内の同じディレクトリ内にフラットに配置するのですが、Ruby on Rails Guidesのサイトは画像やCSSを別ディレクトリに配置しているので、そのままではePub化したときに画像などへのリンクが切れてしまいます。

EeePubでは、階層化コンテンツには対応されていないようなので、今回は以下のようなモンキーパッチで eeepub/maker.rb を直接修正して対応しました。

gist: eeepub_maker_assets_subdir.diff

4. ePub生成スクリプトを書いてePubファイルを生成する

最後にePub生成用のRubyスクリプトを書いてサイトデータをePubファイルに変換します。スクリプトでは引数として渡されたサイトデータをもとに、ファイルのコピーやクレジットページからの著者データの生成、目次の作成などをおこなっています。

gist: rails_guides_to_epub.rb

スクリプトを実行すると、RubyOnRailsGuides.epub というファイル名のePubファイルが生成されます。

% ruby rails_guides_to_epub.rb /path/to/guides/output

Ruby on Rails Guides ePub版のダウンロード

自炊はイヤだという方のために作成したePubファイルをしばらくダウンロードできるようにしておきます。ダウンロードしたファイルはiTunesのライブラリにドラッグアンドドロップして登録できます。データは上記の手順で生成したもので怪しいファイルは含まれていないはずですが、インストールはあくまで自己責任でお願いします。

Ruby on Rails Guides ePub版: RubyOnRailsGuides.epub[1.2MB]

また、手元のiPadで問題なく閲覧できることは確認していますが、あくまでウェブサイトのスタイルを継承しているので、多少見にくい部分もありますし、ePubのフォーマットや妥当性は検証していません。ePubの検証については標準的なツールがあるようなので、いずれ利用したいと思います。

ePubオーサリングの課題

今回、すべての作業はMac上のエディタとiTunesを使っておこなったのですが、ePubを作るのが初めてということで色々とハマりました。昨日の仕事が終わった後に始めて、日が変わる前に終わらせようと思っていたのが、夜なべになる程度のハマリです。以下、参考までに。

iBooksのレンダリングは独特なのでiTunesで実機に配置しないと確認できない
iBooksはCSSをメモリにキャッシュするので、ファイルを入れ替えたらiBooksも再起動しないといけない
実際の閲覧状況によって1行に表示できる文字数が大きく変わるので、codeブロックなどはどうしても見切れる

iBooksでのレンダリングについては、Mac上でePubリーダーの Stanza でも確認してみたのですが、iBooksとはまったく異なります。XCodeについているiPad simulatorで確認できるようになるといいですね。

iBookストアでは個人出版も出来るようですし、いずれ日本版のiBookストアもオープンすると思うので、今後もePub関連の情報を追っていきたいと思います。

Flexアプリケーション開発をRailsライクに簡単にする軽量フレームワーク「RIALY」

2010-04-20T10:00:00+09:00

RIALY というFlex用の軽量フレームワークを開発しGitHubで公開しました。機能やドキュメントはこれから追加していく予定ですが、まずは簡単に紹介したいと思います。

開発の経緯

1年ぐらい前からエアーズではクライアント側にFlexを使う案件が多くなってきているのですが、Flexのイベントフレームワークだけで開発するとどうしてもコンポーネント間の依存性が強くなってしまいます。そこで既存のFlex用フレームワークを調査して、まず初めに PureMVC を採用してみました。

PureMVCを採用したことでコンポーネント間の依存性を弱くするという問題はかなり解消し、無事にひとつのプロジェクトを終わらせることができました。しかしコマンドパターンをベースとするPureMVCでは大量の定型コードを書く必要があって面倒だったことや、UIと処理とをよりキレイに分離したかったことから、次にPureMVCのパターンをベースにイベント処理用のメタデータタグやコマンドの代わりとなるコントローラー層を追加した独自フレームワークを開発しました。

その後、その独自フレームワークをもとに、Railsライクな命名規則や環境ごとの設定の切り替え機能などを導入してさらに改良・軽量化したものが今回公開した RIALY になります。

RIALYの利点

MXMLとActionScriptの分離

Flexの宣言的UIであるMXMLファイルとプログラム処理を記述するActionScriptを別けて書くことには、チーム内での分業をしやすくしたり、アプリケーションのメンテナンス性を向上させたりするメリットがあります。

他のFlex用フレームワークではMXMLファイルの中に、イベント発生をActionScriptに伝えるための部分的な内部スクリプトが必要であったり、ActionScriptと結びつけるための特別なMXMLタグが必要であったりしますが、RIALYではアプリケーションのメインのMXMLファイルの中で以下のようなboot関数を1回呼び出すだけですませることができます。

<?xml version="1.0"?>
<mx:Application
    xmlns:mx="http://www.adobe.com/2006/mxml"
    initialize="boot(this)">
  <mx:Button id="button" label="Click me!" />
</mx:Application>

処理をカプセル化する必要のあるカスタムコンポーネントをMXMLで作成する場合を除き、アプリケーション内のMXMLファイルにはScriptタグやその他のActionScript連携用タグは一切必要ありません。

独自メタデータタグによる見通しの良さ

RIALYではMXMLコンポーネントで発生したイベントの処理や、アクションの実行結果をMXMLビューに反映させる処理を、独自のメタデータタグで宣言することができます。例えば、イベント処理ではイベントの発生元と処理メソッドを以下のように同じ場所にまとめられるので、少ないコードで見通し良く書くことができます。

[EventHandler("button.click")]
public function doSomething(event:Event):void {
  ...
}

Railsライクで判りやすいシンプルな規約

RIALYはRuby on RailsからCoCやDRYといった考え方の影響を受けて開発されています。フレームワーク内で使用する命名規約もRailsにとても良く似ていて、例えばUserControllerのloginメソッドは、"user.login"という文字列表現で呼び出すことができます。

その他、プロジェクトのディレクトリ構成や環境ごとの設定の切り替え機能などもRailsを参考にしているため、RailsやRailsライクなその他のウェブフレームワークの経験がある開発者の方は理解しやすいと思います。

環境ごとの設定の切り替え

Railsでは開発・テスト・本番の各環境ごとに設定を簡単に切り替えることができます。RIALYでも、開発用の"development"と本番用の"production"という2つの環境を標準で用意してある他、テスト用やステージング用の環境を追加することもできます。

環境ごとの設定の切り替えは、アプリケーション用のConfigクラスでそれぞれの環境に対応した初期化メソッドに記述するだけなのでとても簡単です。例えばサーバーと連携するFlexアプリケーションを開発する場合、リモートサービスのエンドポイントURLは開発環境と本番環境で異なることが普通ですが、そのような場合も以下のようにそれぞれのURLを簡単に設定できます。

public class ApplicationConfig extends Config {
  
  public var url:String;
  
  public function development():void {
    url = "http://localhost:8080/service/";
  }
  
  public function production():void {
    url = "http://app.example.com/service/";
  }
  ...
}

何も指定しない標準の環境は"development"で、コンパイル時に環境を指定することでそれぞれの環境用のSWFファイルを作成することができます。RIALYではビルドツールの Maven と Flexmojos というMavenプラグインを使用していて、本番環境用のSWFを作成する場合はコマンドラインから以下のように指定できます。

% mvn -P production flexmojos:compile-swf

いますぐ試すには

最初に書いたように、RIALYにはこれから機能やドキュメントを追加していく予定ですので弊社以外の開発で投入するのは時期早尚だと思いますが、ここまで読んだくださった方には実際に試してフィードバックをいただけるとありがたいです。以下の手順で動作させることができます。

MavenおよびFlex 3 SDKをインストールし、mvnコマンドとmxmlcコマンドにパスを通しておきます。
GitHubからRIALYのブランクアプリケーション rialy-flex-blank-app を取得します。
取得したrialy-flex-blank-appの中に移動し、mvnコマンドでSWFへのコンパイルをおこないます。無事にコンパイルが通った場合、targetディレクトリ内にSWFファイルが生成されます。
```
% mvn flexmojos:compile-swf
```

今後の開発予定

今後は以下のような開発を予定しています。

Adobe AIRおよびFlex 4への対応
サンプルアプリケーションやチュートリアルの作成
MVCパターンでいうM(モデル層)の追加
アプリケーションジェネレータやコードジェネレータの提供

Adobe AIRについてはすでに対応できているはずですが検証がまだ出来ていません。Flex 4についてはコンポーネント層に大きな変更があったようなので修正対応が必要な感じです。

ジェネレータがないのは不便なので、差し当たり次はMavenのプラグインかRubyスクリプトでジェネレータを作成するつもりです。

次回予告

次回は近日中に開発予定のジェネレータを使って、簡単なアプリケーションを実際に作ってみるチュートリアルを公開します。４月の終わりか５月の初めになる予定。お楽しみに！

RailsのMigrationでMySQLのカラムコメントを使う

2009-02-20T08:41:00+09:00

加藤です。

MySQLの4.1以降ではテーブルの作成時やALTER TABLEでカラムを変更する際に、下のようにカラムコメントを付けることが出来ます。

CREATE TABLE `users` (
  `id` int(11) NOT NULL auto_increment,
  `name` varchar(50) NOT NULL COMMENT '氏名: 日本語可。50文字以内。',
  `email` varchar(100) COMMENT 'メールアドレス: 半角英数文字のみ。100文字以内。',
  PRIMARY KEY  (`id`)
)

また、付けたコメントは下のようなSQLで取得することが出来ます。

mysql> SHOW FULL COLUMNS FROM users;

このMySQLのカラムコメントをRailsのマイグレーションで簡単に設定できるようにすれば、ドキュメント生成なんかに使いまわせてDRYで便利じゃないかということでパッチを書きました。

module ActiveRecord
  module ConnectionAdapters
    class ColumnDefinition
      attr_accessor :comment
      def to_commented_sql
        self.comment ? "#{to_sql} COMMENT '#{self.comment}'" : to_sql
      end
      alias to_s :to_commented_sql
    end

    class TableDefinition
      alias :_orig_column :column
      def column(name, type, options = {})
        _orig_column(name, type, options)
        if comment = options[:comment]
          column = @columns.find { |col| col.name == name }
          pos = @columns.index(column)
          @columns[pos].comment = comment
        end
        self
      end
    end
  end
end

これをconfig/initializers/column_comment.rbあたりに置いておけば、マイグレーションでのテーブル作成時にカラムコメントを設定出来るようになります。

class CreateUsers < ActiveRecord::Migration
  def self.up
    create_table :users do |t|
      t.string :name, :null => false, :limit => 50, :comment => '氏名: 日本語可。50文字以内。'
      t.string :email, :limit => 100, :comment => 'メールアドレス: 半角英数文字のみ。100文字以内。'
    end
  end

  def self.down
    drop_table :users
  end
end

Windowsで最新のRailsをJRubyで動かす。

2008-12-13T13:24:00+09:00

こんにちは。石上です。

Windows Vista上で最新のRailsをJRubyで動かしたいと思います。少し前まで、JRubyなんて…と思っていましたが、jrubystackを利用したら思いのほか上手く動いたので、報告したいと思います。Java屋の人で、Windows環境でRails開発始めたいと思っている人は注目かもしれません。

jrubystackは、Jruby on Railsの開発環境に必要なソフトウェア一式を一度に整えることが出来るソフトウェアです。GlassFish、Java、JDBC、MySQL、Ruby on Rails、Subversion、Tomcatなどから構成されます。そのため、何もインストールされていない状態でも、Railsの開発環境を得ることが出来ます。

まず最初に行うのは、jrubystackのインストールです。公式サイトから、Windows版のバイナリをダウンロードし、インストーラーを起動します。今回は、JRubyStack 1.1.4-0（JDK含む）を利用しました。

インストールはウィザードに従っていけば良いですが、MySQLを既にインストールしている人は注意が必要です。既にインストールしてあるMySQLとJrubystackでインストールされるMySQLのポート番号が被らないようにしましょう。私は「13306」にしました。

自動的にコマンドプロンプトが立ち上がり、暫くしてブラウザに「Welcome aboard」と表示されたらJRubyStackのインストールは完了です。開いたコマンドプロンプトとブラウザは一旦閉じてください。

JrubyStackを起動します。Windowsのスタートメニューから、[スタート] → [BitNami JRubyStack] → [Use Bit Nami JRubyStack]を管理者権限で起動させ、コマンドプロンプトが立ち上がることを確認してください。

JrubyStackに既にインストールされているRailsは、2.1.0と少し古いので最新版にします。

> jruby -S gem install 
Successfully installed rake-0.8.3
Successfully installed activesupport-2.2.2
Successfully installed activerecord-2.2.2
Successfully installed actionpack-2.2.2
Successfully installed actionmailer-2.2.2
Successfully installed activeresource-2.2.2
Successfully installed rails-2.2.2
7 gems installed

次に、gem自体をアップデートします。参考：gemが1.3.xにバージョンアップできない件



> jruby -S gem install rubygems-update

> jruby -S update_rubygems

Railsのプロジェクトを展開します。

> jruby -S rails test -d mysql

testというディレクトリが作成されたと思います。以降は、testディレクトリで作業をします。

DBの設定
「config\database.yml」を編集します。以下の様な感じで設定します。

development:
  adapter: jdbcmysql
  database: jrubystack_development
  username: jrubystack
  password: 
  host: localhost
  socket: C:\Program Files\BitNami JRubyStack/mysql/tmp/mysql.sock
  port: 13306

雛形の作成



> jruby -S script/generate scaffold person name:string age:integer

データベーススキーマの作成



> jruby -S rake db:migrate

サーバーの起動



> jruby -S script/server

ブラウザでの確認
http://localhost:3000/people/

どうでしたか。「jruby -S」以外の部分を除けば、普通のRailsアプリケーションの構築とほとんど変わらないと思います。是非とも、スレッドセーフなJRuby on Railsを楽しんでください。

RailsとGWT "混ぜるな危険" にしない5つのポイント

2008-10-09T12:45:00+09:00

加藤です。しばらくぶりの更新です。
ここ最近はRailsとGWTの組み合わせを色々と検証しています。

GWTといえばJava言語でJavaScriptアプリケーションを書くためのツールという認識が一般的だと思いますが、実際に触ってみると、これは軽くて速いJavaScriptコードを生成するための道具なんだなということが判ります。また全世界で展開するGoogleが開発しているしているだけあって、国際化の仕組みが標準で組み込まれているのも日本人にとってうれしいところです。

Railsとの連携についての詳しい内容はいずれここで紹介したいと思いますが、Flexなどと比べるとGWTはあまりにもスルーされてる感があるので、差し当たりこれまでにハマった経験をもとにいくつかポイントを晒したいと思います。

その1: データ交換はJSONでおこなう

まぁ、そりゃそうだろといわれればそうなんですが、データ交換はJSONでおこなうのが一番ラクです。最近正式にリリースされたGWT1.5ではJavaScriptとの連携が強化されたのですが、その中のひとつである JavaScript Overlay Types をつかうとJSONコードをパースによるオーバヘッド無しでGWT内のJavaオブジェクトに変換出来ます。

Rails側のモデルをto_jsonで返して、GWT側ではJavaScript Overlay Typesで受け取ってモデルの基底クラスにNULLチェックや型変換を書いておくのが、今のところベストな方法です。

その2: GWT on Railsは使えない

というのは言い過ぎのような気もしますが、GWTとRailsで調べるとすぐに出てくる GWT on Rails はあまりおすすめ出来ません。最近メンテナンスされていないので、Rails 2.1やGWT 1.5 にまだ対応していないというのが理由のひとつです。また、GWT on RailではRailsとGWTのコードをジェネレータで同時に生成するのですが、これだとどちらも自由度が下がってしまいます。例えば、RSpec使いたいとかMaven使いたいとかいう時には大変不便です。

他にGWTとRailsの連携を助けるツールとして、 GWT-REST がありますが、これも長らく更新されていませんし、GWT-RESTで出来ることは前述のJavaScript Overlay Typesで出来ることと変わらないので特に使うメリットはありません。

その3: GWTとRJSの連携はやりすぎ

GWTが生成するのは普通のHTMLとJavaScriptなので、やろうと思えばRJSとも簡単に連携できます。例えば、GWTからのHTTPリクエストを受け取ったRailsアクションがサーバー側でRJSをつかってHTML上のDOM要素を書き換えてしまってもまったく問題無いわけです。また、RJSで書き換えたコンポーネントからアンカーをつかってURLを変更しGWT側でそれを検知することで、RJSからGWT側に操作を伝えることも出来ます。

僕も最初は、これなら必要なコンポーネントを遅延ロードさせることが出来るし、簡単なフォームならRJSの方がラクだからこの組み合わせは完璧だねと思ったのですが、クライアント側の処理コードが分散すると1ヶ月もしないうちに書いた人間すら判らない状態になってしまうので、最終的に全部GWT側にまとめました。

ただアイデア自体は悪くないと思います。いずれフレームワークが出てくるかもしれないので、それまで待ちましょう（もしくは作りましょう）。

その4: 認証はRailsでページ遷移させておこなう

色々と調べている中で、GWT関連の書籍やブログに「GWTアプリケーションは単独のHTMLページ内で動作し、ログインもその中でおこなわれます」みたいなことが書かれているのを見たのですが、セキュリティ上かなり難しいと思いますし、そうするメリットもあまりないように思います。OpenIDやその他の認証プロバイダを使う場合は現実的にかなり困難です。

ここは割り切ってRails側でrestful-authenticationあたりをつかってさくっと作りましょう。ホストページ（GWTアプリケーションが動作するコンテナとなるHTMLページ）に初期データを埋め込んでおけば、HTTPリクエストが減らせてGWTアプリケーションの起動も早くできます。

その5: GWTの拡張ライブラリは必須

これはRailsとは直接関係の無いGWT側のポイントですが、GWTの標準ライブラリにはかなりプリミティブなものしか無いので、拡張ライブラリは必須です。メジャーなものとして、 GWT incubator と GWTx の2つは最初から導入しておきましょう。

GWT incubatorはGoogleが提供するベータ版ライブラリのような位置づけでかなりボリュームがありますが、良く使うのはロギングや拡張されたGUIウィジェットなどです。また、これはまだ検証できていませんが少し面白いものとして、GWTのコンパイル時にCSSを最適化する CSSResource なんてものもあります。

GWTxはGWTのJREエミュレーションから漏れたJava標準ライブラリを補完するライブラリで、モデルの変更をオブザーブするためのProperty Change Listenerを良く使います。最近リリースされたGWT1.5対応版では、java.beans.Introspectorやjava.beans.BeanInfoなども追加されたようなので、標準でリフレクションが使えないGWTではますます重宝されそうです。

また、Ext JSについてあまり詳しくないのでまだ使用したことはありませんが、Ext JSとの連携ライブラリとして、"Ext GWT":http://extjs.com/products/gxt/ や GWT-Ext などがあります。見た目が固定化されてしまいそうな点がちょっと気になりますが、GUIコンポーネントが豊富に揃っているので社内用のアプリケーション開発などには良いのではないでしょうか。

その他、GWT版JQueryの GwtQuery も要注目です。"Google I/Oのプレゼンテーション":http://sites.google.com/site/io/gwt-extreme で開発者のRay Cromwellさんが、「縮小化・圧縮されたJQueryは15kb。コンパイル後のGwtQueryはどんだけだと思う？なんとたったの712bytesだぜ（意訳）」とアピールされておりました。プラグインも書けるみたいです。

まとめ

ということで、色々と紹介しましたが少しはRailsとGWTの組み合わせに興味はもっていただけたでしょうか？

あまり生産性は良くないなど色々と課題はありますが、GWTはJavaScriptハッカーじゃなくても高性能なJavaScriptアプリケーションが書ける貴重なツールです。登場から2年、正式リリースから1年以上経つにもかかわらず、ましてやGoogle印にもかかわらず、これまであまり注目されていなかった感がありますが、ブラウザの開発競争が激しくなる中で今後注目は高まっていくと思います。Railsやってる人もぜひ一度試してみて下さい。

onclickの無いRJSなんて

2008-05-21T10:57:00+09:00

加藤です。もはやインラインRJSだらけなので、onclickダメとかいわれても困ります。

ということでRJSネタなんですが、RJSでメソッドチェイン出来ることに今更気付きました。というか、対応するPrototypeやScript.aculo.usのメソッドがElementを返すことを知りませんでした。

例えば、onClickで要素クラスを入れ替えてYellow Fadeさせる場合は以下のように書けます。

<%= link_to_function '表示に戻る' do |page|
  page[:item].remove_class_name(:edit).add_class_name(:show).visual_effect(:highlight)
end %>

あとRJSとは直接関係ないですが、Effect.Highlightを使うと最終的な背景色がスタイル属性に書き込まれてしまい色々と副作用があります。一度エフェクトさせた後に背景色が変化しなくなるとか、エフェクトをかける度に背景色が濃くなっていくとったダサい状況は、これが原因であることが多いと思います。

問題を解決するには、style属性のbackgroundColorをnullにしてあげれば良いのですが、エフェクトのキューの最後に実行したい事が多いので、新しいEffectクラスを作成して対応することにしました。

Effect.ResetHighlight = Class.create(Effect.Base, {
  initialize: function(element) {
    this.element = $(element);
    if (!this.element) throw(Effect._elementDoesNotExistError);
    var options = Object.extend({ fps: 10, duration: .1 }, arguments[1] || { });
    this.start(options);
  },
  setup: function() {},
  update: function() {
    this.element.setStyle({ backgroundColor: null });
  },
  finish: function() {}
});

先ほどのRJSで使うと以下のようになります。

<%= link_to_function '表示に戻る' do |page|
  page[:item].remove_class_name(:edit).add_class_name(:show).visual_effect(:highlight).visual_effect(:reset_highlight, { :queue => :end })
end %>

ちなみに、どちらもまだFirefox3でしか確認していないのでブラウザ互換性については不明です。