主なテーマはPocket Wifi買うか買わないかみたいな。
一応3GがDocomo説とかも考えた。

3GでDocomoが来るならば

• すばらしい
• でもそんなにiPadを遠くまで持ち歩くのか？ Docomoの力が欲しい範囲まで。 => 持ち歩きたい
• iPhoneがDocomoなら素敵だがiPadがDocomoでもそんなにうれしくないかもしれない。いや実はうれしいかも。どっちだ
• iPhoneの3Gと料金二重払いはさすがにきつい テザリングとか無理そうだし
• そしておそらくわかりにくい料金プランを理解しなくてはならないのか
• ハイ消えたー

いろいろと考えたものの、料金的にちょっときつすぎるという話になった。

Pocket Wifiのケース

• Wifiモデルでお外で通信 iPodでもお外で通信
• バッテリーが4時間とか心配だけどエネループで充電できる？ぐぐるとできるらしい。安心
• がっつり使う気ならデータプランのにねんMがいいんだろうか 4,980円/月
• いま使ってないE-Mobileがあるので解約手数料みたいなのが半年分くらい12,000円
• そもそもiPad持ち歩くの？ => バイクでの日常的な運搬に耐えるのだろうかってところ
• iPhone持ち歩くときだけでも持ち物が増えるってどうなの？
• Macbook Pro持ち歩いたとき使えるね。
• 気に入らなかったとき解約が簡単にできないね。

その場合のiPhoneの料金

• 基本3Gを使わなくなる パケット代 4,410円 => 1,029円 マイナス3,381円
• -3,381 + 4,980 = 1,599負担うｐ
• 実はE-Mobile通信できないところが多くて3G使いまくるという状況が発生したら課金がマッハ。
• その場合自宅のネットとauも合わせたら通信エンゲル係数高すぎでしょう・・・
• まあとはいえ日常生活圏内の都内およびその近郊なら問題にならないはず。

Pocket Wifiよくないとこ整理

• iPhoneで使うとき荷物が増える
• 金銭的負担も増える（状況に応じて若干〜大幅）
• お得なプランで契約すると解約が困難
• 山間部での使用は絶望的

Pocket Wifiよいとこ整理

• iPadで使える
• Macbook Proで使える
• バッテリーの心配はエネループでなっしんぐ
• iPadで使える回線としては最も安価な選択（公衆無線LAN除く、及びiPhoneとの併用前提）

結論としてはiPad購入と同時にゲットの公算が高まってきた。
iPadとイーモバ抱き合わせで割引やんないかなー。

追記

バリューデータプランやギガデータプランも検討する余地がありそうだ。

• バリューデータプラン 2,457,600パケットまで2980円 そのあと30万パケットくらいで5,980円
• ギガデータプラン 8,388,700パケットまで3980円 そのあと30万パケットくらいで5,980円

iPhoneのみで今まで使った最大のパケット量が100万/月に満たないのでバリューデータプランにできれば更に-2,000円ということで、これはかなり安くなる。
ただし最近iPhoneの通信量も増加傾向なので約250万パケットまでのバリューデータプランはやや不安かも知れない。

加えてMacBook Proで心置きなく使いたければやっぱりギガデータプランかデータプランで悩むべきと言うことになるのかなあ。
MacBook Proを外で使う頻度も多くないし、やっぱギガデータかな。それでも-1,000円だからありがたいよね。

ちなみに第1回で1章2章をやったのだけれど、その日は仕事の打ち合わせが長引いてしまいほとんど終わりかけの参加であったというわけで割と何も覚えていません。
第2回はそういった第1回での自分と同様で、仕事の都合で来られない人も何人かいたようで。

ともあれ今回は3章の「Hadoop分散ファイルシステム」

Hadoop分散ファイルシステム、略してHDFS（Hadoop Distributed FileSystem）
Hadoopのパワーを生かすための分散ファイルシステムのお話ですね。

以下復習。

HDFSの得手不得手

得手

• 非常に大きなファイル
• ストリーミング型のデータアクセス
• コモディティハードウェア

基本的にたくさんのマシンで構成したクラスタに大量のデータをどんどん蓄積していくイメージ。

ブロックサイズがデフォルト64MBと非常に大きく、実際にはこれより大きいサイズで運用されるらしい。
高スループットのデータアクセスが可能な仕組みで、データをクラスタ内のマシンに分散して保存することによりスケーラビリティと耐障害性に優れている。

不得手

• 低レイテンシが求められるデータアクセス
• 大量の小さなファイル
• 複数のライターからの書き込みや、任意のファイルの修正

これら不得意な使い方は基本的にするなということなんだと思う。

低レイテンシはダメなのに高スループットってどういうこと？って質問が出てきてたけど、今読んだら「データセット全体を読むのに要する時間は、最初のレコードを読み出すレイテンシよりも重要」って書いてある。
トータルの処理時間を縮めるために初動のレスポンスは重視していないということのようだ。

クラスタの構成

マスター/ワーカーパターンというやつだ。よく知らないがそういうパターンだ。

ネームノード（マスター）はデータのある場所を知っていて、実際のデータはデータノード（ワーカー）にある。
クライアントから問い合わせを受けたネームノードは、その対象データを持っているデータノードをご案内する。（通常はレプリケーションされているので複数ご案内する）
クライアントはデータノードから直接データを持ってくると言う具合。

データはファイル単位ではなくブロック単位で各ノードに分散される。
これによってひとつのファイルが複数のノードにまたがって構成される＝ファイルサイズの制限がディスク容量に縛られなくなるので、ペタバイトに及ぶファイルも問題なくファイルシステム内に保存できる。
またブロック単位での保存はレプリケーションとの相性もいいということだ。

ちなみにHDFSのブロックサイズ64MBとか128MBだが、各ノードのファイルシステムのブロックサイズはまた別なので、1MBのファイルをHDFS上に保存してもディスク容量は1MBしか食わないとかそんな話もある。

必要なディスク容量の見積もりとかどうするんだろう。
単純に考えると複製数 * ファイルサイズか。こういう質問とっさに出てきたらいいのに。質問力が弱いなあ。

ネームノードは特に冗長化されていない。
データだけローカルディスクとNFSマウントしたディスクに書いて二重化する。
二重化してなくてネームノードのデータが破壊されたらHDFS内のファイル全部死亡。

フェイルオーバーの仕組みは用意されていないようだ。←こういうのも質問しとけよってかんじですね。
それはHadoopが責任持つところとはまた別の話ということなのかな。
まあリアルタイム性の高い処理を行っているわけでもなさそうだし。

セカンダリネームノードと言うものもあるが、これは名前負け。
ネームノードが落ちたときに代わりにマスタに昇格するような名前だけど、実際の仕事は定期的に名前空間のイメージと編集ログをマージさせること。
一応マスタがクラッシュした際にセカンダリネームノードが持っている情報をもとにある程度は復元できるが、最後のマージとクラッシュまでの間の情報は永久に失われる。

HDFSじゃなくてもHadoopは動く

Hadoopファイルシステムの実装はHDFS以外にもいろいろある。
httpやAmazon S3の上で動くものも。
ただし大規模なデータ処理を行う場合はHDFSやKVSのようなデータローカリティの最適化機能を持っている分散ファイルシステムを使うべき。

「データローカリティの最適化機能」ってどういうことなんでしょう。

Hadoopのファイルシステムとやりとりするインタフェース実装いろいろ

もっとも一般的なのはJavaのAPI。
ファイルの読み書き、ディレクトリの作成、ファイル情報の取得、ファイル一覧の取得と絞り込み、データやファイルの削除といった操作が可能。

コマンドラインのインタフェースもある。（中身Java?）
APIだとCとかWebDAVとかFUSEとか。
特にThriftをサービスとして動かしておくとプロキシとして動作してThriftのAPIを使っていろんな言語からHadoopを操作できる。

データ読み書きの詳細

APIが良きに計らってくれるのでクライアントは中の仕組みが全然分からなくても透過的に利用できる。
なので略。

ではなくてHadoopを利用する上では一応知っておいた方がいいでしょう。
でも説明はめんどいので略。さない。一応がんばってみよう。

読むときはクライアント（のAPI）がネームノードにどのデータノードにデータがあるか聞きに行って、それを聞いたらあとはデータノードから勝手に読むかんじ。
ネームノードは場所を教えるだけ。データを中継したりはしないのでここがボトルネックになることはない。
障害に備えて同じブロックを持っている複数のデータノード教える。一応ネットワークの近い順に教える。
クライアントは障害を見つけたら一応ネームノードに教えるみたいだ。

書くときはクライアントがネームノードに書くぞーって言うと、ネームノードで既存のファイルがないかとかパーミッションとかをチェックする。
そしたらネームノードはデータを書くデータノードをクライアントに返して、クライアントはデータ書き終わったらネームノードに書いたぞーって教える。
レプリケーションするので書き込むデータノードは複数。
書こうとしたデータノードに障害があった場合、一定数のノード（デフォルトは1以上）に書き込みができていれば成功と見なす。
書き込めなかったノードにはあとで非同期でレプリケーションが行われる。

flashとかsyncとかの使いどころがイマイチわからなかった。
syncを呼ぶことで一貫性を保証できるようなので、書き込みつつ適当なタイミングで呼ぶべきってことみたいだけど。

以上、間違ってたらすまんてかんじだ。

distcpによる並列コピー

並列動作で効率よくコピー。
実はMapReduce実装。
Hadoopのバージョンがまったく同じでないと使えない。
マイナーバージョンがひとつ違うだけで使えないそうだ。

Hadoopアーカイブ

小さなファイルをtarのごとく固めて効率よく扱う仕組み。
ネームノードのメモリ消費を押さえることができる。

アーカイブ内へのファイル追加や削除をしたい場合はアーカイブ作り直し。
アーカイブ作るときに元のファイルと同量のディスク容量を食う。
うまくmapに渡せない。

といった話だった。たしか。

以上

やっぱ一回は読んでからいかないと、情報のインプットにいっぱいいっぱいで質問とか出せないですね。

追記

資料上がってました。

第２回 Hadoop本 輪読会 発表資料

これで開発環境でも本番環境でも同じファイルが使えるようになり、リリースの都度手動又はデプロイツールで書き換えるとかそういうめんどくさいことしなくてもよくなる。

ちなみに以下のページを激しく参考にしました。感謝。

• CakePHP core.phpの設定をbootstrap.phpに書く | Shin x blog
• CakePHP 環境に応じてDBの設定を変える | Shin x blog

httpd.conf

まずCAKE_ENVというのをApacheのSERVER変数に持つ。
これがproductionなら本番環境。
セットされてなかったら開発環境扱いで。

<virtualhost *:80>
    ServerAdmin webmaster@dummy-host.example.com
    DocumentRoot "/var/www/hoge_production"
    ServerName hoge.example.com
    ErrorLog "logs/hoge.production.error_log"
    CustomLog "logs/hoge.production.access_log" common
    SetEnv CAKE_ENV production
</virtualhost>

app/config/bootstrap.php

次にbootstrap.phpでCAKE_ENVにproductionを指定したときの動作とかを記述。
とりあえずデバッグメッセージがでないように。
もっと他にも環境別の項目を設定したい場合はswitch文とか使って書いたりした方がいいかもしれない。

<?php
/* SVN FILE: $Id$ */
Configure::write('debug', isset($_SERVER['CAKE_ENV']) && $_SERVER['CAKE_ENV'] == 'production' ? 0 : 2);
Configure::write('Security.salt', 'teketou ni kakikaeta salt');
Configure::write('Session.cookie', 'sid');
//EOF
?>

app/app_model.php

仕上げにデータベースの切り替えを定義。
まず環境ごとにデータベースを切り替えるためのハック。

<?php
class AppModel extends Model {
    function __construct($id = false, $table = null, $ds = null) {
        $this->useDbConfig = empty($_SERVER['CAKE_ENV']) ? 'default' : $_SERVER['CAKE_ENV'];
        parent::__construct($id, $table, $ds);
    }
}
?>

そしてdatabase.phpでpuroduction用のデータベースを定義

app/config/database.php

<?php
class DATABASE_CONFIG {

  /* 開発用のDB */
	var $default = array(
        'driver' => 'mysqli',
        'persistent' => false,
        'host' => 'localhost',
        'login' => 'dev',
        'password' => 'xxxxxxx',
        'database' => 'hogedb_dev',
        'prefix' => '',
        'port' => '/opt/local/var/run/mysql5/mysqld.sock', # MacPortsで入れたMySQL用の設定
	);

  /* 本番環境用のDB ApacheにCAKE_ENV=productionを定義 */
	var $production = array(
        'driver' => 'mysqli',
        'persistent' => false,
        'host' => 'db.example.com',
        'login' => 'dev',
        'password' => 'xxxxxxx',
        'database' => 'hogedb_prod',
        'prefix' => '',
	);

  /* SimpleTestによるテスト用のDB */
	var $test = array(
        'driver' => 'mysqli',
        'persistent' => false,
        'host' => 'localhost',
        'login' => 'dev',
        'password' => 'xxxxxxx',
        'database' => 'hogedb_test',
        'prefix' => '',
        'port' => '/opt/local/var/run/mysql5/mysqld.sock',
	);
}
?>

以上。
お望みならstagingなんて環境も作れたりしますよ。

今回初参加。
Rails3とGoogleAppEngine上でRailsを動かすというセッションに参加してきた。

Rails3について

松田さんによるRails3ハンズオン。

小生恥ずかしながらRails3に始めて触れました。
railsコマンドをRails2.xに後戻りできないように書き換えてしまったりと、こやつなかなか傍若無人に振る舞います。

ACアダプタ忘れてバッテリのみのMacBook ProにRails3を入れていっしょにコーディングしつつRails3について学ぶひととき。
railsコマンドが言うことをきかなくなって、ここを見つつ問題解決したりとか、いろいろと山あり谷ありだったけれど、手を動かすのは楽しかった。

Rails3になるといろいろと変わってるわけですが、中でもクエリオブジェクトを返すwhereメソッドが便利げと思いました。
ハッシュに検索条件入れて持ち回らなくても、クエリ条件を保持し続けるオブジェクトができるので、同じ条件でfindしたりcountしたりが簡単にできると言う。

GAE on Rails

セッションマスターはTinyDSを作成したurekatさん。

セッション中の質疑応答でGAEに激しくロックインされてしまうのはどうなのか、みたいなことを質問で言ってしまったが、それでもGAE上でRails（JRuby）が動くというのはなかなか感動的な体験だった。
BigTable用にモデルにはActiveRecordではなくてTinyDSを使うので既存のRailsアプリをすぐにGAE上で動かせるわけではないが、RubyプログラマがGAE上でさくっと作った何かを動かしたいと言ったときにはかなり使えるのではなかろうか。

詳細な手順が以下にまとまっているのでGAE on Railsを試してみたい人は是非。

• GoogleAppEngine/JRuby+RailsでscaffoldからTwitterBotまで

自分は上記通りに試して最初はうまく動かなかったがgem install jrubyしたらなんだかうまく動いた。
それでも動かなかった人もいたのでなんだかよくわからないけれど。

ちなみに普通にrubygemsを使うとRailsのスピンアップに30秒以上かかってGAEの制限にひっかかってしまうため、rubygems使わないようにしてあるそうだ。
Sinatraなんかも動くので簡単なものならRailsよりSinatraとか使った方がいいのかも知れない。

総括

けっこう気軽な感じのいい勉強会だった。
なにより手を動かしながらやるというのが楽しい。

来月は春分の日連休でどっか行こうと思ってるので参加できないけどまた是非参加したいと思いました。まる。
次回の募集も始まっているので興味のある人は是非行ってみるといいと思います。

以下はまとめというより感想で。
内容もかみ砕いているのでなんか間違ってるところもあるかも知れません。

OpenSocial ケータイGame戦国時代

mixiの山下さんとモバゲーのZigorouさんによるそれぞれのプラットホームとアプリ開発の基礎的なお話。
パートナー向けに公開されているドキュメントの内容をかいつまんだもののよう。
ちょっと駆け足すぎた感はあるが、だいたいのかんじはつかめたかな？
コンテンツの作り方の基本は携帯サイトとあんまり変わらないようだ。

あとはオフレコの話が面白かったけどオフレコなので書けないって言う。
なんつーか夢が広がりんぐってかんじですね。

Agility@Scale(アジャイル開発のスケールアップ)を実現する14のベストプラクティス

IBMの玉川憲氏によるIBMでの大規模アジャイル開発の取り組みについて。

規模に関係なく利用できるプラクティスと大規模ならではのプラクティスが半々。
小さなコンポーネントチームをいくつも束ねて、それをマネージャチームで管理して、みたいな大分練り上げられた感のあるやり方をしているようだ。
大規模開発ということで大変そうではあるけど全体を小分けにせずまるごと管理するよりは楽そう。

IBMにはアジャイル推進チームがいて社内のアジャイル浸透度とかを測定したりしているそうな。
トップダウンなアジャイル導入のお手本といったところだろうか。

三周遅れのXP -僕とドワンゴのXP-

ドワンゴのよしおりさんによるXPの話。

特に印象に残ったのは組織がアジャイルではない場合でも、まずは個人で始めることができるという話。
そうした実践をもとにをアジャイルな取り組みをチームに、会社に、最終的には社会にすら広げていくことができる（かもしれない）
玉川氏もボトムアップ的な取り組みを隠れアジャイルと呼んでいたなあ。

Joel on Softwareの中で自分が特に好きな節である「下っ端でも何かを成し遂げる方法」と似ているね。
思い立ったら明日からあなたもアジャイラーですよ。

プランニングポーカーは面白そうだったのでいつかやってみたい。
バーンダウンチャートがFF13発売で停滞する様が笑えたｗ

クラウド開発に役立つOSSあれこれ

オージス総研の水野正隆氏と奥垣内喬氏がクラウド開発の実例を交えて実際の開発に役立つOSSのツールをいろいろと紹介。

• 開発を手軽に → APIを使いやすくするラッパーライブラリなど
• 複数サービス間の連携 → ？
• クラウド環境で共同開発 → AWSをfabulatrを使って複数人で
• テスト → EucalyptusでEC2の互換インフラ構築
• デプロイ → Puppetによるサーバの構成管理, Wakameで自動スケール

？は睡魔による。申し訳ない。
Eucalyptusとか面白そうだと思った。Puppetは来週勉強会行ってきます。

出張！ DDD難民救済キャンプ 〜ドメイン駆動設計をあきらめない〜

和田卓人氏、角田直行氏、渡辺健太郎氏、和智右桂氏、佐藤匡剛氏によるパネルディスカッション。

DDDって聞いたことはあるけどいったい何？という状態での参加。
終了後はちょっと興味がわいた状態に。

海外では今けっこうDDDがブレイクしているらしい。
原因分析として

* NoSQLの台頭によりDBMS側に寄っていたドメインモデル構築の役割がアプリ側に戻ってきた
* Railsのようなフレームワークのおかげでユーザーのドメインに関連した問題解決に注力できるようになった

といったことが挙げられていた。

実践Cucumber 〜ユーザの視点でシステムの振る舞いをテストしよう

英和システムマネジメントの諸橋さん。

いまやってる仕事でCucumberを使ってみようと思って動かし始めているので非常に参考になった。
お客さんへの説明がかなり楽になりそうだ。

コミュニケーションのためのフレームワークという考え方は面白かった。

以上

あともうひとつセッションに参加する予定だったのだけど、気がかりな電話がかかってきてたので申し訳ないけどキャンセルして抜けた。
でも確かめてみたら実は大したことじゃなかったとかもうね。

それにしても運営関係者の皆様お疲れ様でした。
こんだけのイベントに無料で参加できるってすげえなあと思いました。

追記

しっかりしたまとめレポートを見つけたので追記。
4つくらい同じセッションに参加していたみたいなのでそれぞれどんなセッションだったかきちんと知りたい人は是非。

• [devsumi2010] デブサミ2010 2日目 – しあわせプログラマ

Spatial Adapter for Railsを使うとマイグレーションとかでgeometry型を扱えるようになる。
geometry型とか絡むところは生のSQL書いてますよという場合でも、schema.rbにテーブル定義がちゃんと出力されるようになるので、それだけでも便利。

PostgreSQLでも使えるらしいです。

インストール

GeoRubyに依存しているのでまずGeoRubyを入れる。
READMEではgeorubyになっているが、これは情報が古いようだ。

sudo gem install GeoRuby

そのあとプラグインを入れる

ruby script/plugin install git://github.com/fragility/spatial_adapter.git

マイグレーション

マイグレーションは以下のように。

create_table :facilities, :options=>'ENGINE=MyISAM' do |t|
  t.string :name, :null => false, :limit => 50
  t.string :kana, :limit => 50
  t.column :latlng, :geometry, :null => false
end

add_index :facilities, :latlng, :spatial => true 

なつかしのt.columnを使わなくてはならないのは仕様っぽいです。
型は:geometryでも:pointでも。

インデックスを張るときは「:spatial => true」をつける。

なおMySQLのバージョンが5.0.16以下の場合はMyISAMにしないとダメ。
それより後のバージョンではInnoDBでも問題ない。

データの取得とか

作成

 Facility.create(:name => 'なめ', :kana => 'かな', :latlng => Point.from_x_y(43.194, 140.351))

取得

f = Facility.find_by_latlng([[43, 140], [42, 141]])
fs = Facility.find_all_by_latlng([[43, 140], [42, 141]])

参照

f.latlng.x #=> 43.194
f.latlng.y #=> 140.351

ほかREADME参照。

先週末にリリースだったようで。
主な内容はバグフィックス、セキュリティフィックス。

• Ruby 1.9上でよりきちんと動くように
• RailsXssプラグインが使えるようになった
• Nokogiriを使う上でのいくつかの問題が解決
• その他（strip_tagsの脆弱性の修正など）

みたいなかんじですな。

Ruby1.9いまだに使ってないのでコンパチ周りはどうなのかよくわからんです。
そろそろ触り始める必要はあるだろうなあとは思ってますが。

RailsXssはよいもの。
テンプレートに埋め込んだ変数がデフォルトでエスケープされるようになるというもので、ついうっかりエスケープし忘れた、をなくすプラグイン。

「h」が不要になって面倒がなくなる。
逆にエスケープしたくないときに「raw」というヘルパーメソッドを使うようになる。

Exampleを見るに「h」はつけてもつけなくても同じ結果になるようだ。
なので既存のアプリへの導入もそれほど苦労はないはず。

「マイグレーションの中にデータをいじるコードを含めるのやめようぜ。な！」

ってことのようだ。

参考: http://github.com/rails/rails/commit/4932f7b38f72104819022abca0c952ba6f9888cb

Seed Dataって？

まあなんとなくニュアンスは分かるけど、そもそもSeed Dataって何なんだという疑問。

• Rail Spikes: Loading seed data
• Ryan’s Scraps: What’s New in Edge Rails: Database Seeding

上記を参考にすると

• ほとんど変更されないデータ
• 例: Userテーブルの管理者アカウントのような初期データ
• 例: アプリケーションの設定のためのデータ

ざっくり言うとアプリケーションの動作に必要な初期データ。
この中には都道府県マスタや権限マスタみたいなマスタも含めていいと思う。

db/seeds.rbの書き方

seeds.rbを開けば中に書いてあるサンプルコードですぐ分かるけど、単にseeds.rbにレコードを追加するコードを書いていくだけという単純な仕組みだ。

Category.create(:name => 'テント')
Category.create(:name => '寝袋')

とか

%w{テント 寝袋}.each do |name|
  Category.create(:name => name)
end

とかひたすらRubyのコードを好きなように書くべしとなっている。
フォーマットをCSVとかXMLとかYAMLとかに限定するでもなく、新しいDSLを定義するでもなく、好きなようにコードで書けよという投げっぱなしぶりが潔い。

まあもともとマイグレーション内にまざってたデータ作成/編集コードを分離させたものに過ぎないわけだね。

rake db:seed

seeds.rbの適用はrake db:seedという新しいタスクで行う。

又はrake db:setupを実行した際に読み込まれる。
ただrake db:setupはデータベースをイチから作り直すという破壊と創造を司るタスクなので稼働中の本番環境でうっかり使ったりしないように注意。

rake db:seedの挙動はきわめてシンプル

rake db:seedを叩くとseeds.rbの内容がその都度実行される。
この時既存のデータベースの内容は加味してくれず、今までに何回rake db:seedが実行されたのかなどの考慮もない。

つまりマスタデータを追加するつもりで

%w{テント 寝袋}.each do |name|
  Category.create(:name => name)
end

のようなコードを書いているとrake db:seedするたびにこれが何回も実行されてしまうので、ここらへんの面倒は自分で見ないといけないということだ。
例えば

Category.delete_all
%w{テント 寝袋}.each do |name|
  Category.create(:name => name)
end

みたいな。
ただこの例の場合はIDが変わってしまうのでIDを固定にしたければもうちょっと凝ったコードにしないといけない。

しかしながら実際のところseeds.rbにはあんまり複雑なコードは書かない方がいいだろう。
複雑になりそうならモデルにメソッドを実装してseeds.rb内では単純にそれを呼び出すだけとかにした方が幸せになれるはず。

rake db:seedするタイミングについて

rake db:seedは最初に一回だけ実行するべきものなんじゃないか？
という説も考えられるがそれだと運用途中でマスタを追加した時とか使えないし、結局マイグレーションファイルの中にデータ追加コードを書きたくなってしまう。
ので多分それは違うだろう。

マスタの初期化や再構築のトリガーとしてはちょうどいいので、アプリケーションを修正したときなど運用中の任意のタイミングで使いたい。
ということでseeds.rbはrake db:seedがいつ実行されてもデータに破綻が起きないように書いておいた方が良さそうだ。

まとめ

こうして見ると「便利な仕組み追加しました」というより「マイグレーションの中でデータいじるな」って言うスタンスを明確にしたいというのが一番の目的なかんじ。

• データを作成/編集するコードはマイグレーションの中に書かない
• データを作成/編集するコードはdb/seeds.rbに好きなようにRubyのコードで書く
• rake db:seedで実行

seeds.rbのたぶんベターなプラクティス。

• 複雑な処理はモデルに実装する
• いつ実行されてもデータが破綻しないようにしておく
• 何度実行されてもデータが破綻しないようにしておく

• Ruby on Rails 2.3.4: Security Fixes

主な内容はXSSとCookie storeに関する脆弱性の修正。
2.3.4では加えて100個ぐらいのバグ修正の他、いくつかの機能追加がされているようだ。

いつの間にか2.1系はセキュリティフィックスもなしっぽい。（リリースはないけどパッチは出ている）
自分も昔作ったやつは放置状態でまだ2.1のやつとかあるんだけど、そろそろ上げろってことかな。

XSS脆弱性

• XSS Vulnerability in Ruby on Rails

こちらはフォームヘルパーのバグによるXSS脆弱性。

対象は2.0.0以降のすべてのバージョン（ただしruby 1.9を使っている場合は影響なし）
修正済みバージョンは2.3.4、2.2.3。

Cookie storeの脆弱性

• Timing Weakness in Ruby on Rails

セッションストアにCookie storeを使っている場合、Cookieに含まれている値が改ざんされてないかどうかを検証するダイジェストを攻撃者が生成した任意のものにできる。
って書いてある気がする。
Cookie storeを使ってない人、そもそもセッションを使ってない人は慌てる必要なし。

対象は2.1.0以降のすべてのバージョン。
修正済みバージョンは2.3.4、2.2.3。

db/seeds.rbの追加

これは新機能。
各種マスタのデータとかをマイグレーションじゃなくてこれ使って入れなさいってことだと思う。たぶん。

よさげなのであとで使ってみよう。

2.0系と2.1系にはパッチ有り 2009/09/15追記

対応したバージョンのリリースはないけどパッチは出てたみたい。

InfoQ: Ruby on Railsのセキュリティの脆弱性

Railsインスタンスプロセスの立ち上がりすぎ

PassengerMaxPoolSizeを適切に設定してないとそうなることがある。

PassengerMaxPoolSizeのデフォルトは6なのでRailsインスタンスが一個につき400MBのメモリを食っていたら最大で2.4GBのメモリを食うことになる。
というわけでメモリが2GBのサーバでも撃沈する。（まあ400MB消費すること自体がおかしいけど）

インスタンスひとつあたりのメモリ使用量を把握するにはしばらく動かしてみるしかないと思うので（何か方法あるかな？）最初は小さめに設定しておくのが無難かもしれない。
この値が1とか2くらいでも小さなサービスでは全く問題ないし。
今回のケースでもこれを4以下にしておけばスワップ発生はなかっただろう。

とはいえ2GBのメモリを搭載しているサーバでPassengerMaxPoolSizeが6で破綻するというのは残念すぎる。
今回の場合はこれは主原因ではなく副原因と言うべきだろう。

一気に大量のレコードを取得しすぎ

そこでもうひとつの問題。

たまにPassengerのRailsインスタンスプロセスのサイズが300MBとか400MBくらいに肥大化しているときがあるので何でかと思って調べてみた。
何となくカンでアタリをつけて動作を確認していると、案の定サイトマップのために数千レコード取得してるのが原因だった。

ビューテンプレートで以下のようにして一度に取得するレコード数を制限したら90MB台をキープするようになった。

Item.paginated_each(:per_page => 100) do |item|
  xml.url do
    xml.loc(url_for(:controller => 'item', :action => 'show', :id => item.id, :only_path => false))
  end
end

善哉。
本当はなるべくビュー側でモデルを直接取得しない方がいいのだろうけど、背に腹は代えられない。
なお、こういう場合はカンじゃなくてログとか調べて時間のかかってる処理からアタリをつけるのがほんとはいいと思う。

ちなみにPassengerじゃなくてthinとかでも同じ問題は起きる。
アプリの実装次第でメモリ使用量が大分変わるという例でもあるということで。

導入の意図がまだよくわかってないのだけど、何なのかな。
利用状況を厳密に把握して何かやりたい？

ともあれ対応自体はもうRubyのサンプルコードもいろいろと出ていて簡単だった。
既存のURLから機械的に変更するのも簡単なので大した対応コストは取られない。

主に参考にしたのは以下。感謝です。

• Amazon Product Advertising API （認証対応）

多少引っかかったのは以下の点だけ。

TimeStampじゃなくてTimestamp

TimeStampだと400 Bad Request

単なる自分のタイポ。

ホストにhttp://は不要

「http://ecs.amazonaws.jp」で計算してたら403 Forbidden。
「SignatureDoesNotMatch」だそうだ。

引っかかったときに一応公式のドキュメントも見たけど、これはそんなにがっつり理解しなくても動けばいいもんだと思う。

• Product Advertising API 開発者向けガイド リクエストの署名認証について（参考訳）

はじめてのiPhoneプログラミング

はじめてのiPhoneプログラミング

posted with amazlet at 09.07.09

デイヴ・マーク Dave Mark ジェフ・ラマーチ Jeff LaMarche
ソフトバンククリエイティブ
売り上げランキング: 325

おすすめ度の平均:

非常に分かりやすい
真打ち登場。

Amazon.co.jp で詳細を見る

iPhone開発初心者向けの本ではあるが、それなりに経験を積んだプログラミング経験者を想定読者としている。
そのためiPhone開発からプログラミングを始めようとする人にはかなり敷居が高いと思うが、すでにObjective-Cや他の言語に親しんでいる人にとっては無駄のない内容となっている。

帯にある「iPhoneアプリ開発は、この一冊で十分です。」という文句は伊達じゃない。
訳が時々変だったり中途半端だったりするけど全体的にかなり読みやすい。

内容は非常に分かりやすく、かつしっかりしている。
チュートリアル的に進んでいくが通り一遍のチュートリアルではなく、要所要所で理屈を説明しつつ、普通はテンプレートを使えば済むところをあえてイチから作ってみるなど、仕組みからしっかり理解させるような作りになっている。

この本を最後まで読んで手を動かせばもう初心者の域から脱したと言えると思う。
まあまだ自分は最後まで行ってないんですけどね。
でも半分くらいまでよんで大分いろいろ分かったし、Objective-C自体にもけっこう慣れてきた。

今のところ初心者本としてはダントツの出来と言える本。

サンプルソースや素材は以下のサイトからダウンロードできる。

• Dave and Jeff’s Excellent iPhone Support Page

iPhoneデベロッパーズクックブック

iPhone デベロッパーズ クックブック

posted with amazlet at 09.07.09

Erica Sadun
ソフトバンククリエイティブ
売り上げランキング: 32846

おすすめ度の平均:

初心者にはおすすめできない
なぜだろう？評判悪いですね
翻訳は？だが、内容はやはりよい
翻訳に落胆
中級者向け

Amazon.co.jp で詳細を見る

こちらはクックブック。
逆引きリファレンス的な内容を期待していたらちょっと的外れな内容だった。
中級者以上が自分のやりたいことのヒントを得るにはいい本なんだろう。

初心者には内容を理解するのがなかなかキツイ。
ソースコードの書き方もmain.mに全部書いちゃうとかあんまり模範的ではないスタイルで書いている。

というわけでiPhone開発を学ぶために読むのはオススメできないと思う。
ある程度わかってくるといろいろとコンパクトなまとめになっていることがわかるのだが。

アンドキュメンテッドなAPIを使うことのメリットとデメリットのトレードオフが繰り返し説明されていて、そういうiPhone開発者のスタイルが感じられたりするのはいいかも。

なお本文内のサンプルコードは抜粋で全体像がよくわからなかったりするので内容が理解できない場合は全体を以下のサイトから落とした方がよい。

• ericasadun.com

現在3.0対応版が執筆中＆3.0になっていろいろ死んだ内容もあるっぽいので、いずれにしろ今買うのは待った方がいいかも。
7/8から3.0対応のサンプルコードがgithubで公開されているようで、フィードバック募集中とのこと。

• erica’s iphone-3.0-cookbook

先日予約したものを26日の午前中受け取りに町田のヨドバシまで。
契約カウンターは満席だったが中には予約無しの人もいたようで、その日にぶらりと行っても買えたようだ。
ただ黒の32GBは自分が係の人と話している間に品切れのアナウンスがあった。

ゲットするやいなやまっすぐ帰宅してそっこーアクティベート。
早速外に持ち出してみる。
やっぱり外でつながるのは便利だなあ。
それだけでも使い道が大幅に広がるし。

ほかにもカメラやらマイクやらGPSやらコンパスやらいろいろと。
できることたくさんで面白い。
てかコンパスカッコイイです。

touchとは面白さが一回り違うなあ。

もともと旅先とかの調べ物とかに使いたいと思っていたので、どんどん外に持ち出して使っていきたいところ。
あとなんか旅に役立つアプリとかできないかなーとか思ってます。

現状把握

今回スロークエリの発生していたテーブルの状況を整理したのが以下。

• レコード件数は110万件くらい
• カラム数は30程度
• インデックスは効いている（explainで確認済み）
• 処理の性質的にキャッシュは使えない

スロークエリになっているのはもっぱら以下のクエリ。

select * from pages order by updated_at limit 100;

Railsのコードで見るとこんなかんじ。

Page.all(:order => 'updated_at', :limit => 100)

こんな単純なクエリが実行に2秒から10秒程度もかかってスロークエリとして記録されているのは切ない。
インデックスは効いているので問題解決には他のアプローチが必要になる。

考えるに対象は30以上カラムがあってレコードサイズもそこそこ大きいテーブル。
そこで取得するカラムを絞って余計なカラムを取得しないようにしてみたらどうかと思った。

というかクエリが単純すぎてまずはそれくらいしか浮かばなかったわけだけど。

ベンチマークとチューニング

計測なくしてチューニングなしということでベンチマークで使ったのはmybench。

• mybench – a simple benchmarking tool for MySQL

ベンチマークとチューニングは手元の開発環境で実行した。
こちらレコード件数は3万件程度。本番環境より大幅に少ないが十分だろう。たぶん。

全カラム取得とカラムを絞った結果の比較が以下。
10クライアントから100回ずつ、計1000回のリクエストを送るというのを試行回数3回ずつ行った結果。
serialは経過時間（秒）です。

まずは全部まるごと取得している現状のクエリ。

select * from pages order by updated_at limit 100;
# Page.all(:order => 'updated_at', :limit => 100)
  serial  : 29.173278
  serial  : 29.433684
  serial  : 30.258237

これを取得カラムを絞ったものにしてみると。

select id, updated_at from pages order by updated_at limit 100;
# Page.all(:select => 'id, updated_at', :order => 'updated_at', :limit => 100)

  serial  : 16.422306
  serial  : 17.562543
  serial  : 16.070013

倍近く速くなった。
うつくしい。

いやぁ、チューニングって本当に気持ちがいいものですね。
これを本番環境にアップしたらスロークエリもパッタリなくなり幸せになれました。

以下詳しく見たい人向け

select * from pages order by updated_at limit 100;
# Page.all(:order => 'updated_at', :limit => 100)

test: 1000 0.001631 0.060372 0.029173278 29.173278 342.779443571614
  clients : 10
  queries : 1000
  fastest : 0.001631
  slowest : 0.060372
  average : 0.029173278
  serial  : 29.173278
  q/sec   : 342.779443571614

test: 1000 0.001535 0.06981 0.029433684 29.433684 339.746801657584
  clients : 10
  queries : 1000
  fastest : 0.001535
  slowest : 0.06981
  average : 0.029433684
  serial  : 29.433684
  q/sec   : 339.746801657584

test: 1000 0.00298 0.065291 0.030258237 30.258237 330.488521191767
  clients : 10
  queries : 1000
  fastest : 0.00298
  slowest : 0.065291
  average : 0.030258237
  serial  : 30.258237
  q/sec   : 330.488521191767

select id, updated_at from pages order by updated_at limit 100;
# Page.all(:select => 'id, updated_at', :order => 'updated_at', :limit => 100)

test: 1000 0.000327 0.037233 0.016422306 16.422306 608.927881382797
  clients : 10
  queries : 1000
  fastest : 0.000327
  slowest : 0.037233
  average : 0.016422306
  serial  : 16.422306
  q/sec   : 608.927881382797

test: 1000 0.001182 0.050836 0.017562543 17.562543 569.393623691057
  clients : 10
  queries : 1000
  fastest : 0.001182
  slowest : 0.050836
  average : 0.017562543
  serial  : 17.562543
  q/sec   : 569.393623691057

test: 1000 0.000301 0.04706 0.016070013 16.070013 622.277032383234
  clients : 10
  queries : 1000
  fastest : 0.000301
  slowest : 0.04706
  average : 0.016070013
  serial  : 16.070013
  q/sec   : 622.277032383234

muninのグラフを見ると障害の直前までに徐々に負荷が高まっている様子が確認できたので、なんとなく状況は把握。
この負荷が高まった原因については分かっているけど、すぐに対応できるものではないのでこちらはタスクに放り込んでスルーしておく。

止まっても緊急性のないサーバなのでのんびりと復旧を開始した。

ひとまず再起動

しょっぱなから適当に最強の回復魔法を試してみたのだが撃沈。
どうもブートの途中でひっかかってしまって起動しなくなった。

起動時にfsckが走ることを期待したのだが、そこまでも行かないっぽい。
しかしながらXenのconsoleから確認するとディスクをマウントするところで止まっているっぽいので、やはりまずはfsckをかけたいところだ。

Domain0からディスクイメージの中身をfsck

そこでDomain0からイメージファイルの中身を触って修復することにした。

まずディスクイメージをloopデバイスに割り当てる
これにはlosetupを使う。

# losetup /dev/loop0 /var/lib/xen/images/hoge.img

まだこの状態ではfsckかけてもext2じゃないよとか言われて動かないので更にパーティションごとにアクセスできるようにする。

# kpartx -a /dev/loop0

これで/dev/mapper/以下にloop0p1からloop0p8までパーティションに応じたデバイスができるので、これらをfsckすることができるようになった。

# e2fsck -c -f /dev/mapper/loop0p1

p4が欠番でp3はswapなのでスルーしてp1,p2,p5,p6,p7,p8を順にfsck。
p7とp8でいくつか不良ブロックが見つかったのでyを何回か押して修復完了。

最後に後始末しておしまい。

# kpartx -d /dev/loop0
# losetup -d /dev/loop0

これで再度起動すると無事起動して動き出した。
素晴らしい。

参考

• Xenのイメージファイルをマウントする < < そこはかと
• HDDイメージファイルをマウントして使う方法 – adsaria mood
• 19.11.ゲストディスクイメージ上のデータアクセス