よかろうもん！

■[Rails] capybara-webkit のbundleに失敗したら。

以下のようにcapybara-webkit のbundle時に失敗したときの対応メモ。

Installing capybara-webkit (0.8.0) with native extensions /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/rubygems/installer.rb:482:in `build_extensions': ERROR: Failed to build gem native extension. (Gem::Installer::ExtensionBuildError)

/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby extconf.rb

Gem files will remain installed in /Users/interu/.rvm/gems/ruby-1.8.7-p352@rails3/gems/capybara-webkit-0.8.0 for inspection.

Results logged to /Users/interu/.rvm/gems/ruby-1.8.7-p352@rails3/gems/capybara-webkit-0.8.0/gem_make.out

from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/rubygems/installer.rb:445:in `each'

from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/rubygems/installer.rb:445:in `build_extensions'

from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/rubygems/installer.rb:197:in `install'

from /Users/interu/.rvm/gems/ruby-1.8.7-p352@global/gems/bundler-1.0.18/lib/bundler/source.rb:101:in `install'

from /Users/interu/.rvm/gems/ruby-1.8.7-p352@global/gems/bundler-1.0.18/lib/bundler/rubygems_integration.rb:78:in `preserve_paths'

from /Users/interu/.rvm/gems/ruby-1.8.7-p352@global/gems/bundler-1.0.18/lib/bundler/source.rb:91:in `install'

from /Users/interu/.rvm/gems/ruby-1.8.7-p352@global/gems/bundler-1.0.18/lib/bundler/installer.rb:58:in `run'

from /Users/interu/.rvm/gems/ruby-1.8.7-p352@global/gems/bundler-1.0.18/lib/bundler/rubygems_integration.rb:93:in `with_build_args'

from /Users/interu/.rvm/gems/ruby-1.8.7-p352@global/gems/bundler-1.0.18/lib/bundler/installer.rb:57:in `run'

from /Users/interu/.rvm/gems/ruby-1.8.7-p352@global/gems/bundler-1.0.18/lib/bundler/installer.rb:49:in `run'

from /Users/interu/.rvm/gems/ruby-1.8.7-p352@global/gems/bundler-1.0.18/lib/bundler/installer.rb:8:in `install'

from /Users/interu/.rvm/gems/ruby-1.8.7-p352@global/gems/bundler-1.0.18/lib/bundler/cli.rb:220:in `install'

from /Users/interu/.rvm/gems/ruby-1.8.7-p352@global/gems/bundler-1.0.18/lib/bundler/vendor/thor/task.rb:22:in `send'

from /Users/interu/.rvm/gems/ruby-1.8.7-p352@global/gems/bundler-1.0.18/lib/bundler/vendor/thor/task.rb:22:in `run'

from /Users/interu/.rvm/gems/ruby-1.8.7-p352@global/gems/bundler-1.0.18/lib/bundler/vendor/thor/invocation.rb:118:in `invoke_task'

from /Users/interu/.rvm/gems/ruby-1.8.7-p352@global/gems/bundler-1.0.18/lib/bundler/vendor/thor.rb:263:in `dispatch'

from /Users/interu/.rvm/gems/ruby-1.8.7-p352@global/gems/bundler-1.0.18/lib/bundler/vendor/thor/base.rb:386:in `start'

from /Users/interu/.rvm/gems/ruby-1.8.7-p352@global/gems/bundler-1.0.18/bin/bundle:13

from /Users/interu/.rvm/gems/ruby-1.8.7-p352@global/bin/bundle:19:in `load'

from /Users/interu/.rvm/gems/ruby-1.8.7-p352@global/bin/bundle:19

こんなエラーが出たら、Mac OS X Lionなら

$ brew update

$ brew install qt

$ bundle

他のプラットフォームの場合は、以下を参照して適切なパッケージをインストールする必要がある。

https://github.com/thoughtbot/capybara-webkit/wiki/Installing-QT

ツイートする

Permalink | コメント(0) | トラックバック(0) | 16:32

■[Rails] after_updateなどのActiveRecordのCallbackを実行しないようにする方法

Objectの追加/削除/変更時に、after_createやafter_updateのようなcallbackが実行されないようにしたい場合があります。

簡単にcallbackが実行されないようにできないかを調べてみると、各Railsのバージョンで変化はしているものの、どのバージョンでも簡単にcallbackを回避する方法がありました。

Rails2系の場合(rails 2.3.12で確認)

foo = Foo.new

foo.title = "HogeHoge"

foo.send(:update_without_callbacks)

Rails3.0系の場合(rails 3.0.11で確認)

Foo.reset_callbacks :save

foo = Foo.new

foo.title = "HogeHoge"

foo.save

Rails3.1系の場合

update_columnメソッドを使うと良いみたいです。

APIを見ると以下のような解説がありました。

• Validation is skipped.
• Callbacks are skipped.
• updated_at/updated_on column is not updated if that column is available.

ちなみにこちらを見ると他にも様々なやり方があるようです。

ツイートする

Permalink | コメント(0) | トラックバック(0) | 20:46

■トータルフットボールなチームの成り立ち 〜エンジニア視点〜

先日、SonicGardenの代表の倉貫が『兼業のススメ〜トータルフットボールなチームを目指して』というブログを公開していました。

これを読んで、SonicGardenがどのような背景でトータルフットボールなチームになり始めたかをエンジニア視点で考えてみました。

2008年頃

SonicGarden内にもアプリチームとインフラチームという括りがありました。

アプリチームは、アプリケーションの設計/開発を行い、インフラチームはアプリケーションのバージョンアップ、サーバのメンテナンスなどをメインに行なっていました。

この時はほぼ分業制でソースコードをいじるのはアプリチームの人にお願いし、ツールやミドルウェア、サーバに関することはインフラチームの人にお願いするという風習で、各チームがその分野のエキスパートとして仕事をしていました。

2010年頃

SonicGardenのメンバーは最大8名になっていましたが、諸事情等によりメンバーが5名になりました。

メンバーが減っても今までやっていた仕事をただ単に減らすというわけにはいきません。

とにかく無駄を省き効率化し、今いるメンバーで仕事を回せるようにする必要がありました。

こなしていた仕事の中で必要性の低いタスクをやらなくするというだけでなく、より効率的に作業ができるようにならないかを全員で考えました。

繰り返し作業については作業内容をなるべくシンプルにし、さらに自動化することで作業量を減らしました。

また、全員が作業範囲を広げ合うことで、アプリチームとインフラチームの垣根がなくなり互いにの領域の知識を学び始めました。

すなわち、「かけもち」をしはじめたのです。

2011年

エンジニアが「かけもち」の範囲を広げた結果、開発から運用までを一人のエンジニアできるようになるDevOpsを実践するようになりました。

常に100%の品質や成果を求めるのではなく、対効果などを考えて品質、成果を考えることもできるようになってきました。

「それをやって本当に意味はあるんですか？」ということを常に考えるようになり、それと同時に対効果もエンジニア自身が考えるようになってきました。

振り返ってみると…

2008年頃は、チームが分離していたため、各チームがその役割を全うし過ぎ、機能的にアプリケーションが高機能なものになりがちでした。

また、インフラについても高可用性を実現するための検証や新しいミドルウェア/ツールの検証などをやり過ぎていたのかもしれません。

これは、参考ブログ中の"専門部署の人たちが真面目であればあるほど、その役割を全うしようとし過ぎて起きてしまうのです。"に該当するところです。

しかし、この時に培ったノウハウは今でも生きているという事実もあります。

ちなに2010年頃が大きな転機でした。

「かけもち」をすることになり、一人ひとりがスキル範囲を広げることで、これまで意識できていなかったところの改善も考えることができるようになってきたのです。

例えば、アプリケーションのバックアップの仕組みです。

当時、バックアップ作業はインフラチームが行うというのが当たり前でしたが、アプリケーションデータのバックアップをするためには、アプリケーションの内部のことも知っておく必要がありました。他にもアプリケーションの仕様上、バックアップを実行する時間なども制約がありました。

このような状況を回避するために backup というgemを利用して、アプリケーションデータのバックアップの仕組みもアプリケーションに持たせるなどの工夫をしました。

この工夫も、アプリケーションとインフラの両方の観点が無いと思いつかなかったように思えます。

最後にこれまでを振り返って見て、「かけもち」やDevOpsを実践するようになり、以下のような効果が得られたのではないかと個人的には思っています。

• アプリケーション開発/運用がよりシンプルな仕組みに
• エンジニアも機能開発時に意見を言うように（本当に必要な機能かどうかを含めて）
• いろんな人と組みながら複数のアプリケーション開発に携われるので技術知識が向上

上記のような効果が得られ、各個人がこなすことのできる仕事量も年々増えています。

おそらくというか必ず今後もSonicGarden内のスタイルは変化していくことでしょう。

ツイートする

Permalink | コメント(0) | トラックバック(0) | 08:13

■[Rails][日記] SonicGarden検定で作ったアプリ〜2011年(冬)〜

@kuranukiのブログで『ビジョン合宿に行ってきました』の記事中にあるSonicGarden検定という名のアプリ開発で私が作ったものを晒してみます。

このSonicGarden検定では、foursquareのようなモバイル向けアプリを作るのですが、最低限で以下のような機能を満たすことが条件となっていました。

• Facebookでログイン可能
• チェックイン機能
• フレンド機能

あと、開発時間は最大でも24時間。時間をかければ良いものができるのは当たり前なので、あえての制限時間制です。

限られた時間でどれだけシンプルに課題を解決できるかが試されるというわけです。

この課題に対して私はRails3.1とjQuery-Mobileでチャレンジしましたが、メンバーの中には、新しい技術を試してみたいという人もいて、その人はsenchaでTryしていました。課題に対する解決策も多岐に渡り、人それぞれの個性がフレームワーク選定のところから現れていました。

基本機能は6〜7時間くらいで作り終えることができたため、もう少しアプリっぽくするために、以下の機能も追加してみました。

• Twitterログイン
• Twitter/Facebookのプロフィール画像表示
• フレンド機能で申請/承認
• 友達申請通知機能(画面上での通知とメール通知) ※メール通知はバグってるかも。

これらを実装して、トータル実装時間は11時間〜12時間くらい。

開発に取り組む前は24時間で終わるかな？という考えだったのですが、実際にやってみると、シンプルなアプリを作るのに24時間を費やすというのは結構贅沢なことなんだということを知ることができました。

ちなみに作成したアプリのスクリーンキャプチャはこんな感じです。

実際に触ってみたいという方はこちらからアクセス可能です。

http://square5.heroku.com

※スマートフォン以外からアクセスする場合は、ログイン後にブランクページが表示されますが、再度、http://square5.heroku.com にアクセスし直すとログイン後の画面が正常に表示されますので。

ツイートする

Permalink | コメント(0) | トラックバック(0) | 10:12

■[Ruby][AWS] 定期的にS3にバックアップしているデータが最新の状態かをチェックしよう！

過去のエントリでS3にアプリケーションのデータやログ、DBのダンプファイルなどを保存するときにはBackupというgemを利用すると便利だということを紹介しました。

• 『データやログのバックアップを楽に実現するために活用すべきライブラリ〜Backup〜』

このようなgemを利用することでバックアップを簡単に、かつ、バックアップで失敗したらエラー通知なども容易に実現できます。

ただ、バックアップというのは、きちんと保管できているかを定期的に確認しておかないと、万一の時に、”取得していたはずのデータが無いぞ！”ということになりかねません。

しかし、この確認作業はcreativeな作業ではないので、モチベーションもあがらないですよね。

ということでツールを作成したので公開しておきます。

https://github.com/interu/s3_backup_files_checker

現時点で動作確認ができているのは以下の環境です。

■ruby (1.9.2 p290)

■gem

• activesupport (3.1.1)
• fog (1.1.1)
• colorize (0.5.8)
• pit (0.0.6)

実行する前に pit の設定をしておいてください。

s3:

access_key: "ACCESS_KEYを入力"

secret_key: "SECRET_KEYを入力"

あとは、config.yml.sampleを参考にconfig.ymlを作成してください。

実行方法は以下のようにするだけです。

$ ruby check_backup_files.rb

するとコンソールで以下のように表示されます。

現在の仕様では、指定したバケット配下のディレクトリ内の最新のファイルが24時間以内のものであれば出力結果がGreenとなり、そうでなければRedとなります。

設定さえ作成してしまえば、後々のバックアップデータの確認作業は楽に行えるようになるので、ぜひ試してみてください。

ツイートする

Permalink | コメント(0) | トラックバック(0) | 19:47