Category Archives: プログラミング

プログラムや技術系のお話

jQTouchで遊んでみたよ!

iPhoneのアプリのデザインやUIはもちろんだけど、

Twitterからの受け皿になるページなど、

iPhoneのWebページのUIも、もうちょっとどうにかしたいなーと思い始めている。

javascriptのライブラリも出回っているけど、

実は最初はライブラリを使用することには否定的だった。

ファイルサイズがネックになると思っていたから。

アプリのパフォーマンスチューニングをするとわかるけど、

一番の問題は3G回線での利用時の通信速度が遅いこと。

データ転送量を如何に減らすかが大事になってくる。

ライブラリを使用していると、どうしても余計な機能もついてきてしまうので、

その分のファイルサイズを転送しなければならないので難しいなと思っていたわけ。

念のため一応調べてみると、jQTouchなんかは思いの他ファイルサイズが小さかったけど、

jQueryが必須になるので、このファイルサイズがちょっと…と悩んでいたところ、

あることを思い出した。

もともと通信量を抑えるために、Apacheのmod_deflateで通信を圧縮しているのだ。
(iPhoneでサーバーとのデータのやりとりをする場合には絶対入れた方が良い!)

そこで圧縮後の転送量を測ってみると…CSSやjQueryを含めて30KB弱。

これならなんとかなるね!と使用することに決めた。

ちょっと使ってみると非常によく出来ていることがわかる。

デフォルトのテーマのデザインだと物足りなかったので、

テーマをちょっといじった30min.用のテーマを作成すると、

iPhoneアプリライクな動作が簡単に実現できる。

ただ一つだけ問題がでてきた。

UINavigationControllerのようなスライドインのアニメーションを実装するには、

HTML1枚に各種動作を書かねばならないようだ。
(勉強不足でやり方知らないだけだったらすみません。。。)

そうするとHTMLのファイルサイズが大きくなる。

…どうしようか?

とりあえず最初のHTMLに大枠だけ書いて、

スライドイン(ドリルダウン)した時の内容はAjaxでjson読みに行って、

それでコンテンツのタグ生成みたいなことをすれば通信量は減らせるかな?

解決できそうな問題な気がする。

結論としては、Apacheのmod_deflateなど、通信を圧縮することができる環境化では、

jQTouchはかなり実用的だと思います。

O’REILLYの「iPhoneアプリケーション開発ガイド」などを参考にすると導入が楽です。

ただこの本のタイトルは…。

iPhoneアプリを作るものではなくてiPhone用Webサイトを作るための内容なので、

App Storeにアプリを並べたいという人には用途が違うかと。。。

でも、目的に合致した方には良い入門書だと思います。オススメですよ。

セオリー

開発をする上やサービスを作る上で一般的なセオリーと言われていること。

それは決して「一般的」ではなくて、「ある時点に当てはまる」ことな気がする。

一発で大ヒットするサービスを作れれば良いけど、

大概のサービスには原始時代から中世を経て近代へとの進化がある。

一般論におきかえて考えてみよう。

「夜に口笛を吹いてはいけない!」

という話を聞いたことはないだろうか。

これは暗闇の中で自分の位置を敵に知らせないため、という由来だと考えている。

自分の身を危険にさらさないためだ。

原始時代やまだ暗い箇所が多い中世には当てはまるかもしれないが、

今週の金曜日の夜に六本木交差点で口笛を吹くか吹かないかで、

大きな変化があることはまずないだろう。

何が言いたいかというと、

サービスを開発している上で、色々なアドバイスをいただくことがあるけど、

現在のステージでやらなければならないこと、今は意味が無いけど将来きっと役立つこと、

聞く側もきちんと理解して進めなくてはならないんだ。

例えば、いわゆるサービスの原始時代には、

進化のスピードを上げることが重要になる。

この時点では細かい所まで作り込んでいる時間もリソースも無いから、

まずはどんどん作ったものを公開してTry & Errorを繰り返していくことが必要だ。

そういう意味では、細かな箇所にかかわることに対応している余裕がない。

ただ、サービスを中世、近代へと進化させられるかどうか、

競合サービスとの差別化となるのが、最初の頃に言われていた、

細かな箇所にかかわるアドバイスだったりする。

この時期には初期のTry & Errorというスタンスから、

ある程度きちんとしたコンセプトのあるものを出す方向にシフトすべきだと思う。

初期のスピード重視から、後半はクオリティ重視になるのかな。

サービスの状況に応じて、スピードとクオリティの適切な配分をしていくことが必要だと感じてきた。

そんなことを考えていて、最近サービス開発へのアプローチを少し変えてみている。

もう一段上のレベルに持っていこうかなと。

この週末で作っているプロトタイプはちょっと面白いかも。

古の手法&登壇予定

携帯からの画像投稿のために、毎回違うワンタイムのメールアドレスを使って、

そのメールアドレス宛に来たものを同じプログラムで処理することをやりたい。

Postfixでqmailの ***-default みたいなことって出来ないかなと調べてみたが、

イマイチ良さそうな方法が見つからない。

そこで久々にqmailをインストールしてセットアップしてみた。

.qmail-****-default ファイルに

|起動したいプログラム名

と書けばそれでOKだ。 -default の部分は環境変数のRECIPIENTから取得すれば良い。

起動させるものもちょっとしたプログラムで済むから、わざわざRails通さずに、

久々にPerlで組んじゃった方が楽かなーと。

昔さんざんやった手法だけど、久々に書くとなんか新しく感じる。

…こうやって歳を取って行くのか?とちょっと寂しくもあるが…。

それはそうと、色々作りこんでいるものが溜まっているんですが、

少しずつリリースして行けそうです。

目立つリリースもあれば、ちょっとした機能追加もあればなので、

どれが「おっ!?」と思って貰えるかわかりませんが、

一つくらいみなさんの心に刺さるものがあればなと願ってます。

あ、あとイベントの登壇が2つ決まりました。

まずは5月26日のHeat on Wed.(ヒートオンウェンズディ)!。

優勝賞品はiPadなので気合が入ります。発表内容については…諸事情によりまだ内緒です。

あとは6月18日のベンチャーCTOだらけカンファレンス vol.1。

なんか豪華な面々の中に埋もれそうですが、せっかくなので楽しんで来ようと思います。

Macでプレゼンしたいので、iworkが欲しくなって来た。

iPadとも連携できるし、買っちゃおうかなー。