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,  ptions=>'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,  nly_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',  rder => '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',  rder => '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.ゲストディスクイメージ上のデータアクセス

というわけで本日町田のヨドバシにて予約して参りました。
iPhone 3G S。
モデルはブラックの32GB。

お昼ちょっと前に行ったら自分は20番目の予約者であった。
ブラック32GB希望者としては8番目だったようなので、ブラック32GBは割合的にかなり出ているようだ。

Wホワイトは強制加入だったけどすぐやめてかまわないと言うことだったので気にせず。
端末代金は一括で払うと10%ポイントがつくということだったので一括で払うことにした。

ちなみに町田のヨドバシでは予約順ごとに優先受け渡し時間というのが設けられていて、自分の場合は当日11:30から12:00の間に行くとあんまり待たずに受け渡しが完了するらしい。
そういうわけで当日は時間厳守でさくっとゲットしてこようと思います。

多分ダメな店

実は町田まで行かずとも自宅から歩いて10分くらいのところにソフトバンクのショップがある。
ので最初はそこに行った。
しかし料金とか契約の説明がたどたどしすぎて面白不安になったので町田まで足を伸ばした次第。

さすがに料金説明に「多分」とかつけるのはないわー。

「多分端末代金の支払いが月々3,300円くらいです。まだよくわかんないんですけど」

とか言われた気がする。それ君多分間違えてないかな。
料金説明の要領がかなり悪かったのでこっちが何かと勘違いしてたかもしれないけど。

「多分端末は値引きがあるんですけど、はっきりとしたことはまだ分からないです」

とかも言われたな。確か。

「パケット定額フルをフルに使うと5,985円になります。多分4,410円になると思うんですけど」

これは確実に言われた。

「多分」という言葉は好きだが使われると怖いときがあるのも事実。
そこで「多分」という言葉は聞きたくなかった。そこは「多分」であってほしくなかった。

いい言葉だが使いどころを間違えないようにしよう。

移行の理由は世間の流行に乗って、という部分もあるのだけど主な理由はクライアントソフトの不在。
MacでいいGUIのSVNクライアントがなくて結局コマンドラインで使っているので、そんだったらGitでいいじゃんといったノリで移行。

WindowsだとTortoiseSVNがかなりいい感じだけど、Macではそれに匹敵する物が見つからなかったのが理由。
svnXはMacでもイマイチなUIなソフトはあるんだなー、と言う残念さ教えてくれたし、SCPluginは後一歩だったけどやや機能的に物足りず使い続けるには至らなかった。
人に何かいい物ないかと聞いてもコマンドライン派が多かったような気がする。

でコマンドラインでも使い始めてみれば実のところそんなに不便はなかったのだが、ただignoreするファイルの設定がいちいちめんどくさくて死にそうだった。
（svn propsetとかコマンドラインでやるもんじゃねえって個人的に思いました）

Gitは以前から実験的に触ったことはあったので移行は割とスムーズに。
ただsvnとrevertの意味が違うのでそこだけちょっと戸惑ったくらい。

リポジトリの移行も簡単で

$ sudo port install git-core +svn

とかでgit-svn込みのGitを入れて

$ git svn clone svn://hoge_repos/hoge_project/trunk hoge_by_git

これをリポジトリサーバ上ににまんまコピーするなり–bareオプションを付けてcloneするなりして完了。
さくっと移行できてしまった。
詳しいところはぐぐればたくさん出てくるので詳細は割愛。

しかし使い始めてみると分散管理の必要がなくてもGitは使いやすい。

• オフラインでも使える（やはり区切りごとにコミットできるのは精神衛生上よい）
• サーバ上のマスターリポジトリに何かあっても手元のリポジトリをさくっとマスターにできる（これはひとり開発だからか）
• （上に関連して）.git/configをいじれば簡単に参照しているマスターを変更できる
• ブランチ切ったりマージするのが簡単（まあブランチ切らないけど）
• ignoreするファイルの設定が簡単（.gitignoreに書くだけでいい）
• .svnファイルがディレクトリごとにできないので煩わしくなくていい
• githubがある

ざっと思いつく限りでこんなかんじ。
サーバ上のリポジトリに縛られない軽快さが予想以上に良い。

あとはGUIのクライアントでいいものが出ればSubversionのアドバンテージはなくなってしまう気がするね。

iPhone SDKの教科書―Cocoa Touchプログラミング、最初の一歩

posted with amazlet at 09.06.07

赤松 正行
秀和システム
売り上げランキング: 3792

おすすめ度の平均:

アプリケーションの開発に初めて取り組む人に。
やっといい本がでた。

Amazon.co.jp で詳細を見る

iPhoneアプリ開発の最初のステップとしては現在最良の入門書だと思う。
分かりやすくていい本。

とにかく自分の作ったアプリがiPhoneやiPod Touch上で動く楽しさを手軽に味わえる点がとても良い。
画像や効果音の素材がサポートページからダウンロードできるので、それらを使うと見栄えの点でもいいかんじのものができあがるのもうれしい。
楽しさ重要。

他の初心者本がまずは座学で理屈から教える先生なら、この本は実技でお手本を見せてくれる先生といったかんじがする。

内容はiPhone SDKのインストールの説明からはじまるので、完全初心者でも安心。
そういった部分が読み飛ばせるくらいの人はすっとばしてサンプルアプリ作成から行くもよし。

アプリの作成はアイデアを形にするまでの制作の流れなども説明されていて、かなり実践的内容。
また作成の手順説明が操作のスクリーンショットを交えて丁寧でかなり分かりやすい内容になっている。
レシピ通りに進めていけばほとんど迷わず読み進めていくことができるだろう。

この本に従って進んで行くと最終的にサンプルアプリを6つ作ることになる。
数作ることで、操作を反復することになり開発の要領を体で覚えることができるのもいいんじゃないだろうか。

一方でサンプルコードに含まれるクラスやメソッドの説明は最小限にとどめられている。
ただそのおかげでサンプルアプリの作成がテンポ良く進められるようになっているような気がするので、それはむしろプラス評価。

足りない点へのフォローとしてはレシピ通りにサンプルアプリを作って終わり、とならないように、そこから先のステップに進む道筋として改良アイデアを提示して促したり、補足資料としてドキュメントやコミュニティへのポインタを設けたりもしている。

ということでこの本を読み終わったら、提示されたアイデアや自分のアイデアを形にする過程で別の本とかAppleの公式リファレンスで調べていけばいいだろう。
そしたら脱初心者。

で、別の本に関しては何冊か本屋でパラパラ立ち読みしてみたけど、入門の部分がすめばあとはリファレンスで足りるような気がした。
とりあえず自分はこの本で入門はすんだので、あとはしばらく公式のリファレンスでがんばってみようかと思っている。
（翻訳が変と評判の『iPhone デベロッパーズ クックブック』だけちょっと気になっているけど）

もうちょい本で基礎を勉強したいよという人は『基礎からのiPhone SDK』あたりが二冊目によさげな気がする。

CentOS 5.3ではXENがとても簡単に導入できる。
OSインストール時に仮想化にチェックを入れたらそれだけで入るし、後からでも

$ sudo yum install xen

これで依存するパッケージなど必要なものも全部入る。
後から入れた場合はxen用のカーネルで立ち上がるようにgrub.confの修正とかは必要だけど。

まあここらへんはぐぐればいくらでも出てくるので詳細は割愛。
なおパッケージのXENのバージョンは3.0.3になる。

仮想マシンの構築は最初はCUIでがんばろうとしたけれども、イメージ作る途中でインストーラのカーソルが明後日の方向行ったりしてワケがわからなくなったので、あきらめておとなしくGUIで。
GUIのUIはよく出来ていて、簡単に仮想マシンのイメージファイルが作れてOSもインストールすることが出来た。

イメージをひとつ作ったらsudoの設定とかどのサーバにも必ず入れるパッケージを入れたりとか基本的な部分をある程度セットアップ。
そしたらあとはそのイメージファイルコピーして/etc/xen以下に設定ファイルを仮想マシンの台数分作って6台くらい作ってみた。

同じ構成の仮想マシンをコピーでさくっと作れるし、実マシンへの束縛がなくなったので身軽になった気がしていい気分。
ディスク以外はリソース割り当ても柔軟にできていいかんじ。

ただひとつだけ気になることとして、仮想マシンの一台がディスクI/Oを大量に発生させると他のマシンも巻き込んで遅くなる、ということがあった。
例えば一台が割り当てのメモリを使い切ってスワップをガリガリ発生させようものなら、他のマシンでもスワップが発生したかのように遅くなる。

これは最近某VPSを使っていて経験したことと同じだ。
そこでは深夜にバッチが動く時間帯になるとひどくパフォーマンスが落ちる。
こういうことがあるのでVPSも自由度は高いけど所詮共有サーバーだよなって思う。

ここらへんの問題って何か回避するノウハウとかあるんだろうか。

その一環として安売りで1年前くらいに買った110GeのCPUをもともとついていたCeleronからCore2Quad 9400に上げることに。
このときBIOSのバージョンをアップする必要があった。
そのためにはFDドライブが必要になる。
しかし今時フツーはFDドライブとかついてない。

• NEC Express5800／110Ge – wiki@nothing

上記のサイト（多謝！）で調べてみるにUSBのFDドライブが使えるらしいが、使えないモデルもあるらしい。
で、更にぐーぐる先生に聞いてみると最近売ってるものは、どのメーカーから出てても、ほとんどその使えないモデルのOEMっぽい。
要するに今から新品のものを買ってきても高確率で使えないようだ。

ここで押し入れにしまってあるおたから箱から内蔵のFDドライブを発掘するという手もあったが、最近はパーツ類と格闘するのがちょっと億劫になっているので最後の手段と言うことでひとまずパス。
よく見てみるとアップデートツールにWindows版があるのでそれを使ってみることにした。

このツールはWindows 2003と2008に対応しているとのこと。
それぞれ評価版がダウンロードできるのでそれを使ってみることにした。
Windows 2003はインストール途中にHDDが認識されなかったので終了。こっちはドライバを別途準備する根性も必要だった。
根性はとりあえず出し惜しみしてWindows 2008を入れてみたらちゃんとすんなり入った。

BIOSのアップデートもツールを起動しただけでさくっと終了。
善哉。

せっかく入れたんで2008をちょっとだけ触ってみたけれど、なんか小ぎれいになってますな。
Windows Serverなんて2000以来久しぶりに触りました。
ということなので大した評価はできませんでした。小ぎれいになってる。以上。

しかしそうだひとつだけ。
シャットダウン時にその理由を聞いてくるとか大きなお世話って気がするんですけど。
こういう挙動が固いところで使うにはいいのかな。

さて今回はOS再インストール予定だったのでこういう手段も使えたが、絶賛運用中のもののBIOSを上げることになったらいちいち2008入れるのもめんどくさいですな。
それにこんな使い方してるとMSから怒られそうだ。