iPadを机で使う時、そのまま置くと角度が無くて覗き込むようにして、使う必要があります。

　純正ケースを使えば角度はつくのですが、背面まで覆われるケースが、どーもダサい気がして、買ったのに外してしまいました。
　クレイドルも買ったんですが、縦型にしか使えないので、机に置いてWeb見たりTweet打ったりするには、向きません。

　そこで、LEGO使って机に置く時用のクレイドルを自作することにしました。
　幸い、近所にLEGO STOREがあって、ブロックを小売りにしているので、何も考えずにお店に行って、現地で組み立てながら作ってみました。

　ちょうどいい具合に、小さな爪みたいなパーツがあったので、それを前のストッパにしています。

　背面は湾曲しているので、左右の二カ所で押さえます。
接地が少ないので、弱そうに見えますが、結構安定しています。

　これで机の上でGoodReaderを使って資料を見たり、ちょっとニュースをチェックするのに、とても使いやすくなりました。

　かなりお手軽にできて、意外にしっかりしているのでおすすめです。

p.s
　余ったパーツで、走るNexus oneスタンドも作ってみました。

　先月Googleが買収したiPhone向けMailアプリのreMail for Gmailがオープンソースになって戻ってきました。
　買収された直後は、reMailがAppStoreから消えたため「Appleとの対立か!?」とか言われていたのですが。

　どうやら、Google内での別のプロジェクトに注力するために、メンテナンスが出来なくなるためAppStoreから削除したようです。たぶん、Gmailだと思いますが。

　そこで早速Google Code: remail-iphoneからソースをダウンロードして、コンパイルしてみました。ライブラリのコンパイルに1時間ぐらいかかります。
　私の所ではライブラリのヘッダのエラーでコンパイルが完了できませんでした。
たぶん、コンパイルの設定の問題だと思うので、後でまた試してみようよ思います。
　
　プロジェクトサイトでは、アイディアとして、機能拡張案とその難易度が提示されています。
　難易度1として、翻訳も上げられていますが、日本語はサポートされていないようですので、もし興味のある方は参加されてみてはいかがでしょうか？

　iPadが発表され、いろいろなメディアやブログで紹介されています。
ハードウエア的には目立ったところがないため、多くの人に取ってあまり目新しさがなく、残念に思った人も多かったように感じます。

　私がiPadに期待するところは、タブレット型デバイス向けの、新しいユーザインタフェースです。
　うちには、富士通製のWindowsXPのピュアタブレット(キーボードが無くペンだけで操作するタイプ)があります。
ちょっと重いのですが概ね便利で、布団や居間でネットをするときに使っています。

　しかし、普通のWindowsアプリケーションは、マウスでの操作を前提にしているので、余り使いやすくありません。
普通は、Firefoxを起動しっぱなしにしているのですが、いくつかアドオンを入れて、さらに自作のアドオンも使っています。

　iPhoneが成功した一つの要因に、OSXのユーザインタフェースを引き継がずに、小さいタッチパネルディスプレイ用にユーザインタフェースを設計したことがあると思います。
入力方法も画面サイズも違うデバイスですから、PC用とは異なったユーザインタフェースが必要になります。

　同じようにタブレットサイズのユーザインタフェースは、iPhoneとも、デスクトップとも違うものが要求されます。

　アップルのPRビデオを見ていると、ドロップダウン式のメニューや、左右の２ペインなど、iPhoneでは見たことのなかったUI部品が使われていることが分かります。
　実際に指で画面を触るUIを多くのiPhoneユーザが体験し、デベロッパーもそれに慣れています。その上で画面の大きなiPadが出て、ユーザもデベロッパーもそれについて行くという流れができています。

　iPadは、大衆向けの製品としては、初めてタブレットサイズに最適化されたUIを持った製品だと言えます。

　MSは、数年前からTabletPCをリリースしていますが、これはノートパソコンにタッチパネルをくっつけただけのものでした。
多くの人が自由に扱えるパソコンに必要だったのは、タッチパネルだけではなく、それに最適化された新しいUIだったのだと思います。

　ビルゲイツは、1990年に”Information at your fingertips“というコンセプトを掲げました。私はこのコンセプトにとても感銘を受け、いまでも好きな言葉の一つです。
　しかし、このコンセプトに見合う製品は、その後MSからリリースされてきませんでした。MSは過去の資産から抜け出せず、せいぜい”Computing at your fingertips”止まりだったと思います。

　iPhoneが出たときに、”Information at your fingertips”といえる初めての製品が出た。それもアップルから！と感動しましたが、iPadは扱えるInformationをさらに大きく広げ、一般的なWebや動画も十分に鑑賞できるようになっています。

　iPhone向けのUI部品では、iPadの画面は大きすぎます。そのため、多くのデベロッパーは、iPad向けに画面の再設計を行うことになると思います。
　その時に多くのアプリケーションが、「情報を直接、指で扱う」感覚を持ち、それを多くの一般ユーザがリビングで操作する、そんな世界が広がるのが非常に楽しみです。

p.s
　iPadが出るときに期待された点の一つに、マルチタスクがあります。

　Google携帯こと、Androidではマルチタスクがサポートされ、アプリケーションの中で辞書を引いたり、常駐するアプリケーションが、アラートを鳴らしたりと、iPhoneでは出来なかった多くのことができるようになっています。

　その代わり、ユーザはアプリケーションが使うメモリ量やバッテリに気を遣う必要が出て、さらにアプリケーションがクラッシュした際の原因究明が非常に困難になります。
　多くのユーザはメインメモリと、ハードディスク容量の区別が付きません。そんな中、同時にアプリケーションを起動するとアプリが落ちる、などということを理解させるのは困難です。

　またウイルスやスパイウエアが発生する可能性が高くなり、アンチウイルス的な仕組みが必要になってくる可能性もあります。

　Windowsの様に使っているとよく分からないけど重くなる、アンチウイルスは必須、とならない為に、マルチタスクのサポートはこの先も行われることはないと思います。

　個人的には、マルチタスクは欲しいですが、自分の両親にiPadを持たせることを考えると、マルチタスクと引き替えに、メンテナンスの必要性が少なくなるのは大歓迎です。

p.s – 2
　iPad用の鞄をどうするか激しく迷い中。
MacbookPro用に使ってる、MEGALOPOLISじゃでかいしなぁ。
SAMには入らないし、今持ってる、Tumiのバッグには入るかなぁー。
PEOPLES DELITEを買おうかなぁー。
　iPad用じゃないけど、MEGALOPOLIS A1欲しいなぁー。

その場合は、下記のようなCSSを指定する事で、コピーの吹き出しが出なくなります。

body {
     -webkit-user-select: none;
}

　いまPhotoShareのサーバの実装を大きく変えようとして悩んでいます。 (参考: Life is beautiful: マルチスレッド・プログラミングの落とし穴、その２)

　Rails 2.2でThread safeになるとか、NeverBlockで12倍速くなるっていう話もあるんだけど、負荷が上がればレスポンスが悪くなるのは、どうしようもない。マシンを増やせば解決できる部分もあるけど、マシンを増やせばコストは上がる。

　Life is beautifulで書かれていますが、確かに全部の処理を同期的に行う必要はないんですよね。

　PhotoShareでも、既にいくつかのページは非同期にerbを生成して、それをRailsとerubisで読み込んで実行しています。
　しかし、Railsだけではこういった非同期の処理やviewの一部を事前に生成するという処理ができないので、この処理は別途プラグインを作って実現しています。

高速化の為にはキャッシュを使おう

　Railsで高速化を考えていくと、特にキャッシュが重要になります。たとえばブログエンジンで、RSS Feedを生成するアクションがあったとします。

　通常Railsで組むと、Feedを生成するアクションでページキャッシュを行なうようにします。こうする事で、Feedを生成する処理は一度だけ行い、あとはApacheがキャッシュファイルを返すようになり、Rails側の負荷が下がります。

　この時、ブログを更新する処理を行なうと、Sweeperによって先ほどのキャッシュが破棄され、次回Feedのアクションにページにアクセスしたときに、再度Feedが生成されるようになります。

　これでは、更新の度にキャッシュが破棄/生成され、処理待ちが発生してしまうことが考えられます。

　そこで、更新の時にキャッシュを破棄するのではなく、投稿の処理の自体を非同期にして、更新処理を行った後、Feedなど関係するページを事前に生成します。
　そして、Feedは常に事前に生成したファイルを返すようにします。こうすることで、投稿があった直後にFeedへアクセスした場合でも、キャッシュの破棄は行われずに、キャッシュ(というか非同期に生成したページ)を返します。

　この非同期処理をキューで管理するようにすれば、ページの更新が沢山あってもFeedへの反映が遅くなるだけで、Feedそのもののレスポンスは悪化しません。

Webだってアクションごとに優先順位があるよね

　重要なのは、RailsではFeedのアクションも普通のページも同じプロセス群で同じ優先度で処理されることです。

　ほとんどのFeedは人間ではなくロボットからのアクセスです。人間と違ってレスポンスが悪かったり反映が遅くても問題になりません。
　そのため、Feedアクションのレスポンスが悪化しても、それ自体は問題ないのですが、Railsが同時に処理できるのは、Feedや普通のページを含めて一定数です。(mongrelの起動数など)

　その為、Feedのアクションが重いと、処理待ちが増え、普通のページのレスポンスも悪化します。

　コントローラごとに実行するmongrelを振り分けるようなルールをリバースプロキシに書けばある程度回避できますが、どのように振り分けるのか決定するのは困難です。(Feedなら簡単だけどもっと難しいケースもあるよね)

　このように実はアクションごとに優先順位があります。Feedやランキングと言った部分は、反映が遅くてもほとんど問題になりませんが、自分の写真リストや写真そのものはすぐにアクセスできるようにしたいのです。
　現在のRailsはコントローラごとに優先順位を付けるような処理は苦手なので、これを行うには、なんらかの仕組みが必要になると思います。

でも全部を非同期にする訳にはいかないし

　もちろん、処理のうち非同期にできる部分とできない部分があります。特に問題になるのは、エラー処理です。

　ブラウザでは、一度レスポンスを返してしまうと、サーバからブラウザにメッセージを送る方法がありません。
その為、非同期処理の中でエラーがおこった場合、それをどのようにユーザに伝えるかが問題になります。

　ブログの記事を書く処理では、タイトルの有無や、添付している画像のチェックなど、処理が正しく行えるかのチェックは非同期処理にまわす前にチェックします。事前にチェックできないものについては、何らかの方法であとで通知する仕組みが必要です。

　投稿ボタンを押した後、処理中画面を出して、Ajaxを使って数秒おきにサーバへ確認にいくか、別のページに遷移したときに通知する方法で行けるかなと思ってます。

　また事前に生成しにくいページもあります。PhotoShareの「すべての共有写真」では、100人フォローしている場合、100人分の写真リストがマージされてきます。
　逆に、100人にフォローされている人がいる場合には、その人が写真をアップするたびに100人分の「すべての共有写真」を更新する必要があります。
　これでは、写真をアップすることに100人分のXMLを生成する事になります。
しかし、ほとんどのユーザは誰かがアップする度に写真を見るわけではありません。このようなケースの場合は、いままでと同じように同期で処理をした方がよいでしょう。

　このような処理の場合は、通常のキャッシュやDBのチューニングなどが有効だと思います。

Rails捨てちゃおうか

　こんな風に非同期処理を行う為のRails向けのライブラリはいくつかリリースされていて、BackgroundFuやAP4Rなんかがメジャーです。

Photo by robotgirl

　非同期処理をさせるためにRailsとこれらのソフトを使う方法もあるのですが、キャッシュの事前生成などを考えると、Railsのメリットがないので、メッセージキューとviewの事前生成を中心にしたフレームワークっぽいものを自作しようかなと思っています。

　ユーザ登録、管理画面などRailsを残したい部分もあるので、データベースはActiveRecordのままで、ActionPackに相当する部分をRackの上で自作しようかと考えています。

　実際の構造についてはなるべく早く次のエントリで書く予定です。

　まだ漠然とした話なんですが、もし、お知恵がありましたら、コメントをもらえると幸いです。

　iPhoneのアプリを色々と入れていると、突然iPhoneが起動しなくなることがあります。

　iTunesから認識する場合は、「復元」ボタンを押せばいいのですが、iPhoneが起動せず、認識すらしない場合があります。

　その場合は、一度Home+電源長押しで、電源を切った後、USBに接続して、Homeを押しながら電源をいれてください。
　このようにすると、下のような画面が出てiTunesがリカバリーモードになってiPhoneを認識するので、iTunesから復元を実行してください。

　アメリカに来て約3か月がたち、やっと生活も落ち着いてきました。

　現在、BigCanvasでは、7月のAppStoreオープンに向けてiPhone向けのアプリを中島さんと作っています。

　本当は、私もCocoaで遊ぶつもりだったのですが、このプロジェクトを始めたのが4月で時間が無いため、アメリカでも引きこもりの様にRailsのコードを書いています。早くもっとCocoaでアプリを書けるようになりたいなぁ。

　ネットへの依存度が高いので、日本に居てもアメリカに居ても生活全般、あまり違いがない気がします。
　ただ、デザイナやPR会社との打ち合わせなどが英語なので、そこが違うかな。

　これが一段落したら、自分でも書きたいiPhoneアプリがあるので、自分でも色々書いてみようと思っています。

　自分のアイディア以外でも色々作ってみたいと思っていますので、ぜひ「こんなiPhoneアプリ欲しい！」とかありましたら、メール: masuiあっとmasuidrive.jp、チャットでは、MSN:masui@hisec.co.jp、skype:masuidrive76まで呼びかけていただけると、うれしく思います。

　みんな書くだろうけど、これは書かずには居られない。

　ソフトバンクからiPhoneがリリースされることが、発表されました。

　iPhoneいいよ！ iPhone!

　普通にウェブが見れて、PCメールがさくさく読めて、ほんとに手のひらに入る情報端末って言う感じ。

　ゲイツが昔言っていた「Information at your finger tips」を体現しているものが、Appleから出ているって言うのも皮肉だなぁ。

　別に日本で一社からしか出ないとは決まった訳じゃないのですが、「今回の発表は残念」とドコモは言っている模様。

　しかし「タッチパネルで操作できる端末としては、PRADA Phone by LGなど同様の端末を当社でも提供している」は無いだろう・・・。

　タッチパネルという点を引き合いに出して、PRADA Phoneと比べるのは・・・・。まぁこういう事を広報が言うことが、いまのDoCoMo端末の使いづらさを物語ってると言えるけどね。

　いま、うちの会社は、iPhone向けアプリ/サービスを作ってるんだけど、まじめに日本語化をしないといけないなぁ。

　色々作りたい物はあるんだけど、時間が足りない。頑張ってるんだけど、自分の脳みその遅さにがっくりくるなぁ。

p.s
　iPhone SDKの開発者登録って、もう日本からも出来るようになってるのかな？