フィリピンから帰国します

えーと、いまさらなんですが、周りの近い人には告げてますが、フィリピンから本格的に帰国することになりました。

今度は日本がメインになりますので、フィリピンにはたまにしか来ないことになります。

日本で不都合をかけた皆様には大変申し訳なく思うとともに、今後日本でもがんばってやっていきますので、なんとかよろしくお願いいたします、ということです。

フィリピンはやっと暑さに体が慣れてきたとことですが、ちょっと生活的に限界を感じていた所でもあります。やっぱり家庭は大事だなーと思います。

あとネット人間としては、無線環境、ネット環境ともに貧弱なのも辛かったです。

おかげでオフライン性能のことも考えさせられました。

日本以外ではまだ貧弱なネット環境なんだってこと。

おいしいマンゴージュースを気軽に飲めなくなるのはちょっとだけ寂しいですが、日本は日本で楽しいことが一杯あるので実にわくわくしてます。

ということで明日の（今日かもう）飛行機で帰ります。

PCのSafariとモバイルsafariの違い

いやー、結構はまりました。

iPhone用のBookmarkletをまた作っていたのですが、

先日のポストでsafariにgetElementsByClassNameやdocument.evaluteがあることを書いてたんですが、それはPCだけでipod touchには存在しないことがわかりました。

調子にのって便利に書いていたんですが、bookmarkletが動かなくて、しょうがなく少しずつでバッグするはめに。。

それともっと行けなかったのが、実はwebkitのnightly buildを使っていて、それにはElement.addEventListenerがあるらしく、調子にのってそれでいいと思っていたのですが、これもsafari3.1には存在せず、当然モバイルsafariにも存在しません。。

まずは次のsafariでは取り入れられるはずなので、まあいいんですが、iPhone2.0では上記のメソッドは動くのでしょうか。しばらくはどのレベルなのか探る必要がありますね。

しかし、PCのsafariとモバイルで実装が違うのは遺憾ですな。

そこは何とかそろえてくれないと、デバッグができまへん。。

safariってxpathつかえるんだ。。

ふと別の調べ物をしているときに、safariで、

document.evalute()

ができることがわかる。

もしや、とおもってロケーションバーに

javascript: alert(document.getElementsByClassName)

してみると、こちらも存在する。

なんだ。。

いままで結構冗長な書き方してきたよ。。

しかも両者ともネイティブコードで実装されてるらしいのできっと早いだろう。

これからはこちらの方を使おう。

（しかしAppleのDeveloper ConnectionのDOM Referenceにはかいてなかったんだよね）

safari環境整備

webkit関係の特徴になれる為に、わざわ「最高の」Firefox3から乗り換えてsafari3.1を使い始めた。これもなにも次期世界携帯に普及するはずであるwebkitになれておくため。

色々、現状safariだけでしか動かないであろうHTML5のvideoやaudioタグとか、CSSアニメーション、canvas等見ていると、本気でwebkit陣営はFlashのいらない世界をいち早く目指していることがわかる。

でsafariなんだが3.1が出たときは爆速っていわれたけど、ずっとFirefox3を使ってきたかんじからするとそんなに早い感じではない。いや、JavaScript関係ははやいんだけど、ページ全体の読み込みが重く感じるというか、おそらくsafariの方が全部読み込んでからレンダリングしているようなかんじで、多少画面表示までまたされる感じがする。

safariでFirefox3の便利な機能が使えなくなるので、最低限モダンなブラウジングには必要なAutopagerが必要だということで、GreeseKitをいれてoAutoPagerizeを入れる。

しかし色々userscriptを見てみたんだけど、JavaScriptの世界は奥深いねー。

アイディア次第でいろんなことができる感じがする。

こんな手法もあるのかと驚くことばかり、勉強になる。

ipod touchのTabulaterの時も思ったんだけど、この分野はアイディア次第でいろんなことができそうな氣がする。

iPhoneアプリについて考える

最近、僕の周りの敏感な奴らがこぞってiPhoneアプリの開発をはじめている。
それは当然なことだとおもう。
久しぶりにアプリケーションを開発する大きな（少なくともそう感じられる）単一のプラットホームができたのだ。windowsが出てきて以来ではないか。
そこで金を稼ぎたいひと、名前を売りたい人が出てきて当然だし、感度のいいギークがそれになだれ込むの当たり前のことなんだよね。

しかし久しぶりである。
日本の携帯みたいに様々な機種に適合する必要もなく、単一プラットホームを考えればいいだけだし、しかもSDKが充実していてしっかりした物になっているので、開発者としてはやりがいがある。

僕は稼ぎたい方で、名前を売りたい方ではないので、少しiPhoneのAppStoreでアプリを売るという商売が商売になるのかってことを考えてしまう。昨日はネットに繋げなかったので、じっくりと考える時間があった。

で、結論だけど、ごく個人的にでもAppStoreで個人が生計を立てられるだけの物は、結構難しいと思う。
だいたい自分が欲しい月収なり年収をアプリ単価の70%（自分に入ってくる分）で割ると、いくつアプリが売れなければならないかがわかる。計算してみるとわかるが、僕の欲しい売り上げには、結構な数量を売らなければならないというハードルがある。

これだと一個のアプリだけではむりだろうし、複数のアプリを提供しないと行けない。
また、経験上、ダウンロード売り切りの商売の場合、提供直後は普通売り上げのピークでその後売り上げはガクンとダウンする。そう考えると、結構な数をリリースしていき続けなければ、おそらく収入の維持は難しいだろう。ごく少数の定番と言われるアプリなら別であろう。これとて一度それなりのiPhoneユーザに可否を判断されたあとは、あとは、iPhoneユーザの拡大するのに合わせた拡大しか望めない。つまり、日本の携帯電話の時と異なり、新機種への機種変更がないので、一度ユーザがいらないとおもったら、その後そのユーザが購入する確率はかなり低い。あとはiPhoneへ乗り換えるユーザが増えるたびにそのユーザが新たに購入の可否を下すというチャンスがあるだけだ。勢い、売り上げを維持するにはアプリを出し続けなければならないのではないか。

実は携帯電話のゲームをリリースする会社にいたことがあるのだ。
そこで売り上げのながれだとかは多少はわかっているつもりだ。
なので、シビアに考えると上記のようなことが考えられる。

また、iPhoneの行き届く環境が整うまでにも結構まだ時間がかかりそうだ。
当初の販売国数は24カ国だし、60カ国になるには年内一杯かかるだろう。
その後それらの国に普及しだしてから、ということを考えると、整うのは来年にはいってからだろう。

また、かなりの申請されているアプリをappleがさばききれていないようだ、というのがある。
実際にAppStoreに掲載されるのは審査のような物があるのかどうかはわからないが、それに近い物があるのだろう。これだけ開発者が殺到すれば、実際に販売されない、またはいつまでも販売に乗らない物が出てくる可能性は大きい。

もう一つは、下記のようなものである。

先ほどSoftbankShopから電話が来ました。
「予約いただいたiPhoneですが、現在の状況ですとお渡しすることが出来ません、初回入荷数が余りにも少ないため年内にお渡しできないかもしれません。」
との事。
事実上の予約キャンセル
これはAppleStoreに徹夜で並ぶしかねぇかなぁ？

iPhoneの現状

ということである。
だからおもったより万人に広く行き渡るには時間がかかりそうなのだ。

そういったこともあり、
冷静に考えるとiPhoneアプリ販売には過大な期待を抱きすぎないことが良いと思ってる。
基本的にWeb2.0以降の世界でわかったことは、ソフトウェアを販売する商売は下火になったと言うことである。これは世の中の趨勢で、AppStoreも70%は無料ソフトであるということは、これも時代の流れなのである。だから、よほど価値のあるソフトでないとユーザは有料で買うことは無いと思う。おそらく、同じ機能でフリーで出す奴がでてくるんで。そういった物はPCの世界で既におこったことで、PC買ってから有料のソフトをインストールすることってそうなくなったんじゃないでしょうか。そういうことだと思います。

まあ、副収入とか会社の事業のあくまで小さい一つ、としては当然挑戦しがいのあるものだと思っている。

それより僕が今一番興味があるのは、iPhoneがwebkitブラウザのプラットホームとなるということである。
ネイティブアプリもいいんだけど、やはりiPhoneの強みは、今までの携帯にないパワフルなPCに近いブラウザが乗っていると言うことだと思う。今までの携帯電話のブラウザは非力で、JavaScriptも動かず、しょぼいCSSしかつかえなかったが、iPhoneのブラウザは違う。ある意味CPUの早さを除いてはMacのSafariに近い機能をもつパワフルなプラットホームなのだ。

今、Firefox3が熱いが、実はwebkit陣営も負けず劣らず熱い。
実は今一番すすんだCSSだとかHTML５だとかJavaScriptの実装をしているのが、このWebkit陣営である。
webkitが実現するのは、ネイティブアプリの負けないリッチな環境を、（Appleのお好きでない）FlashだとかAIRだとかSilverlightだとか特定ベンダーに依存せず、世界標準仕様で実装できるようにすることだ。

このwebkitがくしくもiPhoneとAndroidという次世代のハイパー携帯プラットホームに搭載されるということは偶然だけではないだろう。ある種、AppleやGoogleがどうしたいのかという方向性に裏打ちされている物なのだと思う。

おそらく将来の携帯プラットホームはこの二者がPCの時代にAppleとWindowsという覇権で争ったようなことを行うのかもしれない。

しかし、ブラウザのプラットホームが両者とも同じということは、そこにかなりチャンスがある。
これにPC用のプラットホームのブラウザを考えると、そこには大きな大きな、iPhoneネイティブアプリ以上のビジネスチャンスのあるプラットホームが広がっていると思われる。

だから、iPhoneネイティブアプリもいいんだけど、同時にもっとwebkitの仕様ハックをしていきたい。
ここには結構大きなチャンスがあると思うからだ。

フィリピン台風直撃

この週末はさんざんだった。
土日と二日続けて台風直撃の為に、外にもでれず、しかもネットも切れてしまうという最悪な状況。
しかも、iPhoneアプリ開発の勉強をしている最中でネットが切れやがって、全くさんざん。。

しかし、ネットが切れるとなにもPCでやることがないね。
僕はゲームをするわけじゃないので、ネットがきれるとPCに向かってもいっさいなにもすることが無い。
プログラム書くにもネットにリファレンスとか情報があるので、やっぱりネットがないとだめ。
いかに自分がネットに依存しているのかわかったし、それは結構いろんな人がそうなんじゃないかな、と思っている。いまやPCはネットに接続してないとただの箱、である。
ちょっと昔はソフトがないとただの箱って言われていたんだけど、今はソフトがあってもそれがネットを必要としているソフトばっかんなんだな。スタンドアロンだけで楽しめるソフトって、ゲーム以外には考えられない。

そういった意味で、先週末はネットにつながらなかった分だけ、いろいろなことを考えられた時間であった。

別にRubyが嫌いな訳じゃない

よく最近いろんな人に誤解されているみたいだけど、俺はRubyが嫌いでもやったことが無い訳でもない。

実際、俺はRubyは昔からいじってきた。1.4の頃だから1999年くらいだろうか。
あのときは主にはバックエンドのバッヂ処理とかはRubyで書いていたのだ。
簡単なCGIなんかもerbを使って書いていたのだ。遅かったけど。。
Perlがどうしても苦手だった俺にはRubyは斬新だった。助かった。

その後、同時期かちょっと前くらいに、Linuxのディストリビューションをやっていた関係で、インストーラーの日本語化の際にソースを見る必要があって、それはQTをつかってPythonで書かれていた為に、その頃からPythonも使うようになった。

そうやってPythonの方を使うようになって、あんまりRubyは使わなくなったのだ。
その頃はRubyは入っているもんじゃなくって、コンパイルしてインストールするもんだった。
なんで既にはいっているPythonの方が使い勝手がよかったってのもある。

Rubyの斬新さだとか、簡単なことを簡単にできつつ、しかも、難しいことも簡単にできる素晴らしさに関しては、今でも尊敬のまなざしで見ている。Rubyが好きか？と聞かれれば好きだ、と答えるし、Pythonよりもある意味言語的に一本筋が通っていると思っている。

じゃ、なんでRubyをあんまり使ってないかって言うと、使う機会が無いからだ。
いや、実際にはRuby on Railsのプロジェクトを一個メンテしていて、全く関係ない訳じゃないけど、それはばりばりRubyのコードを書きまくる訳ではない。

Webの開発は職業としてやっているのですが、どうしても顧客の要望がPHPが多い為に、ほとんどPHPでこなしてます。実際にはRuby on Railsをかなり参考にして作られている、CakePHPというフレームワークを使っていくつか開発しており、それで足りてしまう為に、Ruby on Railsをあえて使う必要がないのだ。スピードもRuby on Railsに負けず劣らずな感じで開発できるし、できることにもそう差異はないのだ。

また、実際に私の顧客環境を考えると、わざわざRuby on Railsで開発するといっても、はいそうですか、といって簡単に受け入れてくれる斬新な顧客はそういない。やっぱりちまたではまだまだ、PHPの方が実績がある為に安心して受け入れられている。

たとえRuby on Railsが受け入れられたとしても、じゃ、それを顧客に導入するかと言われると、そうはならない。まだ、Ruby on Railsは運用面において、長時間安定してそれなりのパフォーマンスを維持して運用し続けられるだけの実績が世の中にそうないし、ノウハウもまだ蓄積されていない。

だから賭けでRuby on Railsに入れ込んでもいいが、リスクは自分で追わなければならない。
私は職業開発者だから、複数のプロジェクトを廻している、
その中で、そういった実績の自分で確定できていない物で顧客のシステムが回っているとなると、それに時間を取られる恐れがある。それは自分にとって貴重な資産である時間を浪費することになって命取りなのだ。

こういった感覚も長い開発者経験から来ている。
まだ、tomcatが一般的に使用されていない頃に、ノウハウがたまっていないにも関わらず、若かった俺は顧客のシステムにtomcatを入れたことがある。
そしてそれはそれは運用で痛い目をみた。何日も徹夜することになったし、何ヶ月も引っ張り回され、一年後にはPHPで書き換えになったという経験をしている。

だから、新しい物は、ギークとしての私は当然興味があるしやりたいのだが、職業開発者としての私がそれをセーブするのだ。顧客のシステムで実験しちゃいけないよね。

そういったこともあり、自分の仕事ではPHPが主体なので、なかなかRuby on Railsは触る機会がない。

あとはちょっとした書き捨てスクリプトとかバックエンド処理とかだが、これもなかなかRubyを使う機会がない。ついPythonの方を使ってしまうのだ。Rubyにもirbがあるのはしってるが、なにかると、すぐPythonのインタラクティブシェルかiPythonをたててしまう。これはある意味癖である。仕事の経験上の。
それで仕事がすんなりとおわってしまって、なかなかRubyで書く所までいかない。

じゃ、空き時間は？というと、今はクライアントベースの物の方に興味がある。
サーバサイドは既にフレームワークの確立された世界であり、これから大事なのは、以下に安定かつ確実にサーバ側は運用されるかという所であろう。それにくらべて、クライアントベースの物は、これからまだまだ発展していくぶぶんであり、いろいろと新しいトレンドが細かいタイミングで来る世界でる。

なので、空き時間はObjectiveCを書いたりJavaScriptやCSSをハックしたりしています。

そういったことでRubyの出番が無い訳です。

なので、俺は別にRubyが嫌いな訳でないということだけは言っておきたいと思う。

Sproutcoreに関して

Cocoa for Railsともいわれ、Appleが今回のMobileMeを実現するにあたって、webアプリを限りなくデスクトップアプリに近づける為に使われたという、HTMLのUIフレームワークを調べてみました。

これのインパクトの方が大きすぎてiPhoneネイティブアプリ開発よりは優先になってしまいました。

で、UIの方はかなりMac風ではあります。
全く同じということではありませんが、雰囲気は似ています。

で、これを開発するときは、基本的にRubyを使って開発します。
その開発の仕方はRailsに似ていて、Railsを触っている人であれば理解しやすいと思います。

そして出来上がったMVCをRubyでコンパイルして最後にPureなHTML、CSS、JavaScriptを生成するようです。

バックエンドとの連携は通常のXHRなので、バックエンドは何でも良いそうなのですが、やはりRuby on Railsとの相性が良さそうです。（フォーラムではJava等のバックエンドの人が使いにくいって文句を言ってましたが。。）

これは、きちんとしたUIパーツのあるフレームワークなので、Cocoa風のUI部品で統一したアプリケーションを作りたい場合はこれは非常におすすめです。しかし、作者も語っている通り、通常のサイトに効果や風味を加える為に使うというのは難しそうで、それならば、通常のPrototypeとかをすすめるよ、とのことです。

ほんとにネイティブUIのアプリ（メーラーとか）そういう物を作るときにはいいのでしょう。
デザインとか不要に悩むより、コンポーネントが解決してくれます。

ただしカスタマイズして使ったり、一部だけ使うってのは難しそうなので、使う目的は限定されるでしょう。

ということで、やはり、自分の仕事の枠だとJquery＋アルファで自由度が高いのが良さげです。

HTML5 Client-side database storageに関して

昨夜同僚と飲みに行ったのでまとめられなかったのでまとめ。

HTML5で策定中のブラウザ側でローカルデータベースをもってデータパシストするという規格「HTML5 Client-side database storage」はまだ最終決定までまとまっていない。

この規格をいち早く取り入れたのが、WebKit陣営。

その最初の製品として「Safari3.1」が上記仕様での実装を行っている。

それとは一方別にちょっと前から、Googleの方でも「Gears」というブラウザへの機能拡張を使って同様の機能を提供できる環境を提供していた。GeaesはFirefox1.5以上とIE6以上の対応。OSもMac、Win、Linuxと対応。（MacのSafariには対応してない）

GearsはもともとClient-side database storageだけを提供するのもではないが、一部の機能としてそれを実現している。それはHTML5で策定中の仕様とは異なる物で、アクセスするJavaScriptのコードもHTML5（Safari）版とは異なる書き方である。

先日リリースされたFx3はClient-side database storageには対応していないので、使用する場合はGearsが必要（ギリギリにリリースされた）。

WebKit陣営は積極的にこの仕様を取り入れているので、一部、携帯電話デバイスも含め、WebKitを利用する各所に取り入れられている。AIRも同様だし、iPhone2.0のSafariに取り入れられているという話もある。となると同じWebKitを仕様する「Android（By Google）」もこれを実装する可能性は高い。なので、気がつくと次世代の携帯端末の雄は携帯においてClient-side database storageを実装するプラットホームとなる可能性がある。

Gearsの方はFacebookやMySpace等が自信のプラットホームアプリの改善の為に取り入れ初めている。
そういった形でオープンなwebプラットホームのなかから取り入れられる可能性が高い。

Fxも最終的にはHTML５仕様のClient-side database storageを入れると思われる。

Gearsは最終的には形を残しつつも、よりHTML5仕様のAPIと互換性を持つ形で発展していく物と思われる。

Client-side database storageの利点は、何よりも、クライアントサイドでのwebアプリケーションのパフォーマンスや使い勝手が圧倒的に向上すると言うことである。また、電波が来ない場合のオフライン機能としてこれを使うこともできる。よりwebアプリがネイティブアプリに近い形に進化する可能性があり、一種RIA環境を構築する際の重要なパーツにもなるであろう。

ということで、早速、今日はSafariとFx3＋Gearsでテストをしてみました。
簡単なテーブルを生成して、フォームから書き込んだデータをローカルのDBにインサートして、その後新着からデータをリストで引っ張ってくるという簡単なものだ。

やはりAPIの使い勝手はHTML5版の方が良さげである。
現状、一つのHTMLで両者に対応しようとすると、コードを分岐させて同じロジックを二回書かなければならない。一応、ばからしいと思いながらも、経験ということでやってみたが、やっぱりばからしい。
できれば、GearsのAPIをHTML5版にラップするライブラリを書くことが必要だろう。

ま、（現状のPCの）シェアを考えると、IE、Fxが多いだろうから、やっぱGearsを中心に考えなければならないだろう。ただし、iPhoneとかプラットホームが限定されたサイトを考える場合、結構絞り込みで使えるのでこちらは楽そう。

あ、ちなみにClient-side database storageの実装の招待はSqliteです。
なので、通常使えるSQLはばりばり使うことができます。
SQLばりばりの開発者の方はうれしい方向性ですね。

モバイルとJavaScript

常々モバイルのブラウザにこそJavaScriptが必要だと考えてきた。
だが、セキュリティーの問題やCPUパワーの問題からなかなか実現できていなかった。

モバイルのコンテンツこそ、全体のドキュメントの必要な部分を必要なだけロードして更新すべきだし、レスポンスのいらない操作はバックグラウンド（非同期）で行われるべきである。

携帯のプラウザはJavaScriptを持たないのでリッチな操作感を目指すと勢いFlash Liteである。
そのFlashと携帯ブラウザの今の統合のされ方じゃ、それでもまだ完全にはほど遠い。
（インライン再生とインタラクティブ操作の関係）

やっぱりipod touchが出てきたときに非常にAjaxが使えることがうれしかった。
実際に初期にサイトを立ち上げた人たちは非常に効果的にAjaxが使われているものもあった。

つたない回線だからこそ、効果的に情報遷移と通信を合理的に設計する為にAjaxが必要なのだ。
また、最近はドラックアンドドロップや各種エフェクトの効果のあるJavaScriptライブラリも充実してきているので、それらを利用することで、狭い画面で効果的に操作を行わせたり、効果的に表示できたりもする。

iPhone2.0のSafariがどれほど初代より充実しているのかわからないが、iPhoneサイトの要はそれらを効果的に使うことにつきると思う。

あんまりAjax使うとGoogleに引っかからないんで、おそらく通常のサイトはGoogleに引っかかるようにプレインに作っておいて、iPhoneからのアクセスの時は、iPhone用のインタラクティブなページを見せてやるようにすれば良いのだろう。もちろんそれようのマーキングやCSSも必要になるから。

モバイル分野に本当にパワフルなプラットホームが出てきて本当にうれしい。
あとはサードパーティー向けにFirefoxなんかはでてくるのだろうか。
あれのコンセプト映像は本当にすばらしい物だった。
Firefoxが出てくるとプラグインなんかも実現されるのかな。
楽しみである。

あともう一つは、おそらくPCの方ではHTML5の流れで、クライアント（ブラウザ）側でデータパシストを実現する機能が備わる。今、おそらくsafariでは実現されていて、Firefox3ではどうなのだろう。とにかくブラウザ内蔵のSQLiteがSQLでデータをクライアント側で管理してくれる。これが無いブラウザにはGoogle Gearsがある。

ここら辺がもっと普及すると、webアプリの概念はかなり変わってくるように思われる。
定期的にデータをローカルとリモートでシンクすればよく、作り方も変わってくるだろう。
もちろん、ローカルアプリの動作スピードも通信に惑わされない部分がでてくるので、かなりスピードアップするはず。

これがモバイル（iPhone、Android）の方でも実現してほしい訳である。
というのも、同じことを書くようだが、モバイルの様な通信環境が多少不安定なものほど、オフライン機能が充実していることが必要なのだ。なので、いつも通信や電力が完備されているPCのような環境より、モバイルでバイスの方が、ローカルストレージやAjaxが必要になってくるわけである。

ここら辺が実現するのはそう遠くないと思う。
技術的には難しくないからである。
正常な進化を遂げてほしいと思う。

Tumblrとipod touch

コンドミニアムに帰ると、腰痛の問題もあって楽な姿勢でネットを見れるようずっとipod touchを使っている。

で、Tumblrをしきりに見るのだが、ダッシュボードがiPhoneに最適化されていないのでやっぱ重たい。
（やっぱレンダリングのスピードの問題があると思う）

あと、PCでやってるようなtomblooのような感じのpostができない。

これをiPhone向けのページ最適化の所と絡めて明日解決してしまおうと思う。

具体的にはダッシュボードの方は、こういうときこそのAjaxということですな。
APIをたたいて20件取得して20件目の画面下部ぶ移動したときに自動的にオートページャみたいに次の20件をくっつけるか、新たにページをレンダリングする。とにかく、あの今のダッシュボード全体を再読み込みる重さを回避したい。常々、iPhoneにこそAjaxは向いていると思っている。

できればJSONPの方を使ってAll Javascriptでやりたいですね。サーバを絡めたくない。

もう一つの書き込みの方は、Bookmarkletを使う。
ページのタイトルとリンクのポストはAPIを使って楽勝だろう。
問題は画像を引用してのポストである。一つ画像だけ抽出するBookmarkletを噛まさないと行けないかも。
ちょっとできなさそうなのが、選択範囲の引用によるポスト。
セレクションという概念がiPhoneにはないんだよな。
音声と動画のポストはほとんどしないので無視。

実は明日はメインの仕事がまっているのだが、乗らないので、まずこっちをやってのってから、メインの仕事に取りかかろうと思う。

iPhoneアプリと商売

iPhone熱が一段落落ち着き冷静に色々考えることができるようになってきた。
SDKもはいり、開発する氣十分で少しずつ時間をとってるが、他の仕事もあるのでそう自由にはいかない。

さて、iPhoneアプリはほとんど無料であるという記事が入っていた。

iPhoneアプリは約7割が無料になりそう

売られるアプリもApple分を乗っけてもせいぜい500円位ではないかともこと。

日本の携帯の課金の感覚を考えるといい感じかなーとは思います。

ただ、この金額だと、携帯のアプリ開発をやっていた経験からいうと、結構開発側としては辛いなー、当価格ですね。個人事業主としてなら、なんとか食っていく可能性もあるかもしれませんが、企業としてこれに懸けることはむずかしいですね。おそらく矢継ぎ早にアプリをどんどんリリースしないと結構会社的には難しいんじゃないですかね。

月に100本売れて5万円。60カ国で売れたとして月300万円。
また60カ国に万全と売れだすのは来年以降。
やっぱり規模的にはかつての携帯のゲームマーケットよりしょぼいんじゃないでしょうか。
冷静にみると。

その割にJavaと比べてObjectiveCの開発はどうでしょうか？
おそらく感じとしては、既にCでゲームのソースやアプリのソースを持っている会社は、移植は簡単でしょうね。なんで、資産を持っている会社の方が有利でしょう。そうじゃなくって、一から、ゲームを起こしてiPhone向けに出していこうとなると、結構、Javaアプリの時以上に難しいことになるのでは無いかと思います。

あと、ゲームと各種定番必須ソフトウェア以外はお金取るのは難しいでしょうね。
簡単なアプリは無料で他の会社が出すでしょうから。

ま、最初はiPhoneもやるよ、っていうスタンスでしょうね、みんな。
ただ、まだそれに全部を懸けられるだけの物はないと思います。

すべてはiPhone普及とAppStoreの動向にかかってきているものと思いますがまずは様子見でしょうね。
みんなどのくらいのレベルをいくらで提供してくるのか。
AppStoreでアプリを頻繁に購入するであろう（僕みたいな変な）人はどのくらいいるか。
（でも多分ゲームは買わないな）

あと、最近僕の周りでも色々iPhoneのアイディアを聞くことがあるんですが、みんな思うんですが、ちょっと仕掛けやアイディアが複雑すぎ。多分、ipod touchの使い勝手とか使い込んでみないとわからないんだろうな。Appleのネイティブアプリもかなりシンプルですから。

あと、UIは指で操作するということを意識しないとね。
かなり想像以上にシンプルにして各UIパーツの大きさを大きく取らないと、指で押せません、というか誤操作します。

もしかすると、商売のやり方は単純にアプリを売るというモデルにならないかもしれませんねー。

google気になる

実は黒船だと騒がれているiPhoneももちろん興味があるが、もっと興味があるのはGoogleなのだ。

iPhoneはiPhoneで新しいマーケットとアプリケーションプラットホームを期待させてくれるのだが、Googleが狙っている所はもっと大きな部分であると思っている。

それはiPhoneも飲み込む規模なのではないか。

GoogleはiPhoneが勝とうがWindowsMobileが勝とうがどっちでもいいという、非常に都合の良い立ち位置にいる所であらたなアプリケーションプラットホームを提供してくれそうな気がする。

iPhoneにどっぷり浸かるということは、その枠内で閉じてしまうことを意味する。

Googleが提供しようとしているアプリケーションプラットホームはもっとハードやOSから抽象化されたレイヤーで存在するものだ。だからAndroidでさえも、その中のコマの一つにすぎない。

やはりGoogleが何をしようとしているのか、つかず離れず見続けていった方が良さそうだ。

やる気が出ないとき

そのような状態のとき、会社に行きたくないときは、まず体を温めましょう。
そういうときは、体が冷えの状態になっていることが多いです。
汗をかくくらいがいいと思います。

次に、プチ断食します。
水分はお茶等の暖かい飲み物で補い、どうしてもおなかがすくときはバナナを一本食べることをお勧めします。ヨーグルトなどの酵素食品もいいと思います。

これは両方とも、体の免疫力抵抗力を高める為の手法です。
そうすることにより、体の免疫抵抗力が高まり、精神的にも前向きで打たれ強い気持ちに変わります。

化かされたとおもってやってみては。

パスタ

フィリピンでは水道の水は飲み水や調理用として使わない。
水は買うものである。

通常は飲料水としては、最近日本で見かけるようになった、ウォーターサーバ（冷たい水と熱いお湯が出る）用のでかいボトルを買って運んでもらい、それを使用する。

一個50ペソくらいだろうか。

しかし、炊事をしてておもうのだが、パスタは水を使うという点においては非常に不経済な食べ物である。

よく、笑い話でイタリア軍が砂漠で（貴重な水を使って）パスタを作っているという笑い話があるが、全くそれは実感するのだ。パスタをガンガン作ってると、あっという間に水がなくなっていく。しかもそのゆで汁はすててしまうものねえ。

水が貴重な国ではパスタはそうそう作れんね。

フィリピンのバナナ

フィリピンに来ておいしいと思うもの。
バナナとマンゴー。

両方ともミラクルフルーツと言われ、その栄養素はすごい物があるそうです。

特にマンゴーはカロチンやビタミンAが豊富。
こちらでは日本と比べ物にならないほど安くマンゴー100%のジュースがかえますので、ほとんど毎日それを飲んでいます。

あとはバナナ。
こちらもミネラルが豊富。
三種類の糖質を持っている為に、それぞれ吸収速度が異なり、いわゆる腹もちするとのこと。
その割に低カロリー。
こちらのスーパーで売っているバナナは、若干日本の物とは異なる。
皮が暑く長さが多少短い。
肉質はもっと黄色がかり粘り気があり濃厚である。
おそらく日本で売っている物より栄養が濃そうな気がする。

野菜が不足しがちな一人暮らしを是で補っています。

だいぶよくなった

今日一日安静にしていたら、だいぶ状態が良くなりました。

腰痛にプラス喉に風邪を引いてしまって、咳はでるし、咳をするときに体が緊張して腰が痛むという最悪な状態でした。

しかし不思議に思うのは、鍼とマッサージをしたのが金曜日夜。
そのときに先生はいかにも日曜日は大丈夫だろうというようなことを、結構確信をもっておっしゃっていた。もし日曜になってもどうしてもきになるようなら来なさい、と。
最初はそのときの痛みから、日曜も痛いでしょ、とおもっていたのだが、ふたをあけてみたら結構良い状態な訳である。

最初、金曜に鍼から帰ってきたときに洗面所で自分の顔をみたら、ひどく疲れているように見えた。
目の下にくまがはっきりと出ていたのだ。こりゃいかんな、ということで、マッサージ後はひどく疲れるのでそのまま寝入ったのだった。

その翌日、土曜日、体調はかなりわるかった。
思えばそれはもみ返しのようなものだったのだろう。
あんまりベッドから起き上がれずに、これじゃ、日曜にまた先生の所に行かないとな、とおもっていた。

そして、今日日曜。
まったく昨日の状態が嘘のような状態である。
さすがにちょっと痛みはまだ腰にあるのだが、緊急を要することまでもない。
今日は先生の所には行かないことにきめた。
（結構先生のいるあたりは、フィリピンの地理のわからない俺としては、あんまり休日の夜には行きたくないということもある。平日のよるだったら結構タクシー流してるしあんしんなのだが。ま、あんまり夜にはいきたくないのだ。）

考えてみると、これはやっぱり人間の自己治癒力を引き出す手法なのではないかと思う。
鍼とマッサージで体を結構刺激して、痛めつけるという表現は悪いかもしれないが、いい意味で体に負荷を与える。最初、その時点と特に翌日はその刺激のせいで体の状態が悪くなったかのように感じる。
ところが、その後、人間の自然治癒力が大きな反発をして一気に良い方向に降り幅をグッともっていく。
そういうように個人的には理解した。

だから、鍼とかつぼとかは即効性ではなく、もう少しサイクルを考えた物のようで、あんまり毎日する物じゃないのかもしれない。いっぱいすればいい、という考えは西洋的な薬学の考え方に近い。
必ず、治療をうけた日とその翌日は安静にしているのが良いようだ。

ipod touch復活

しばらく使ってなかったipod touchだが、腰痛になってから必要になってきた。

今のフィリピンのコンドミニアムは、仮住まいなので適当な家具がない。
なので、PCを適切な姿勢で見る机がないのだ。
勢い変な姿勢でPCを見ることになり、腰痛が強まる。

それでは楽な姿勢でネットを見るには、と考えると、ipod touchがいいのではと思い立った。

しかし、最初、こちらのネット環境では無線LANがない、どうしようと言うことになったが、Macのネット接続を共有させAirMacを簡易アクセスポイントにできることがわかった。これで無線LANアクセスポイントを買わずにすむ。ラッキー。

これでネット環境はOK。

あとはネットツールだが、僕の一番のメインアイテムRSSリーダー「Livedoor Reader」がiPhone向けだといまいちの機能なのだ。

ここはgoogleに任せようと、フィード登録をすべてgoogle readerに移行させた。
googleのサービスはほとんどがiphone対応になっているので、すげーフレンドリー。
大体海外系のサービスの方がiPhone向けが充実しているようなので、サービスがそれらを選んだ方がいい。Remember the milkなどもこれでOK。

あとはtumblrなのだが、iPhoneでうまくpostするような機能が見つかっていない。
それだけがちと不便。
しかし、腰痛を悪化させるよりはいいだろう。

腰痛

実は先週末から腰痛に悩まされている。
やっぱり朝がひどく半日しか会社にいけない。

そこで会社の知り合いの紹介で鍼にかよっている。
フィリピンに来て初めて鍼をするとは思わなかった。

今日は二回目の治療。
鍼とマッサージの合わせ技。
今、帰ってきた所。

かなり効いてきたように思う。
先生は日曜までみてまだ痛かったらもう一度来なさいとおっしゃる。

しかし、東洋医療ってほんとに不思議ですね。
実際に効くことは間違いないんだけど、その理屈はさっぱりわからない。

パラダイムチェンジ

パラダイムチェンジが起こったらそれに合わせて自分の動き方をかえていくのは事前の道理。
特に資金を多く持たない私のような物は、細かい変化に合わせて、すぐに方針変更することが大切。
短気だとよく言われるが、判断を早くするのは必須。だから見切りも早い。

iPhone2.0の発表はパラダイムチェンジにふさわしい物だった。

今年の後半の目標。

・iPhoneアプリの開発体制
必要な手続きを整えてさっさと開発する。
ObjecttiveCはMacの時に少しやったが、開発対象にモチベーションを保てず挫折している。
今回はiPhoneアプリが目標なんでがんばれそう。

・Google App Engineをプラットホームにした開発
これも先取り（でもないか）。
いずれ是が正式版になったときに必ず個々で開発したい要望が出てくるはず。
あとweb開発もやっぱやりたいし。
Pythonは前の会社のメイン言語だったんで学習は容易。

・フィリピンからの撤退をするか
ちょっと会社の方向性にブレを感じている。
あんまりフィリピンにいるメリットを見いだせないでいる。
元々投資のつもりできたのでだめでもいいんだが、そんなに資金があるわけではないので、損切りは早い方が良い。
というか、損ではないけど、まだ会社の体制として私の参加は時期早々かなと感じている。
早ければ来週、友人でもある社長が帰ってきたら結論をだすことになる。
場合によっては日本に帰国もありうる。

ちと脱力

しかし昨日のWWDCの発表に興奮しながら出社して、周りにはなしたけど、「何それ？」的な反応。。。

しかし同じ業界にいる人たちとは思えない情報感度の低さ。

しかも経営陣なのに、目の前の「きせかえツール」とかに追い回されて、単なる、他の会社でいう「ディレクター」の存在「だけ」になりさがっている。

たとえ目の前の仕事がどうであれ、自分が経営者であったりすることに誇りと責任感をもって仕事しなきゃね。

たいていこういう人は、iPhoneなんて日本の携帯がすべて実現できてることばかりじゃん、とかさー、
お財布が無いもんねとかさー、（じぶんら使ったことも無いくせに）
ワンセグないんでしょーとかさー、

本当に鎖国の中の発言ばかりなんだよな。

iPhoneがすごいのってそういうことじゃないでしょ。

あれが今年中に世界70カ国で販売されるということと、
それのターゲットは3GでiPhoneを使える＝PCを使えるリッチな層になるということ、
既に２万５千のデベロッパーが申請して、まだ4千しかAppleではアプリを承認できてないこと、
iPhoneはあのスペックで199$で販売されるということ、

どれをみてもターゲットがワールドワイドじゃない？
そう、マーケットはワールドワイドなんだよ。
ワンセグとかお財布とか関係ないの。

このスペックの3G携帯を199$で世界にばらまかれたら、日本の携帯メーカーでどこが太刀打ちできる？
世界に占める日本の携帯業界の鎖国性だとか存在感の小ささをまるでわかっていないんだ。

着せ替えとかもいいけどさ。
今ごはんを食うだけで精一杯なのは、まわりだけでいいや。
なんかちと脱力しました。

やっぱ人の問題なのかなー。
俺の理想と遥かに遠いんだけど。。

SQLに関してメモ

AppleのWWDCのライブを覗いている合間にメモ。

SQLは集合を扱うのに向いている。
しかし我々は手続き型言語の思考回路にとらわれている。
手続き型言語の思考回路で集合を考えると、ついループと条件分岐の発想をしがちである。
ところがSQLはそれをスマートかつ効果的な形で表現するパワーを持っている。

一番駄目だと思うのは、SQLで取り出した集合を再度プログラム言語側で手続きルーチンでループして加工したり構造を変えたり、融合させたり、分離させたりすること。
（Viewをレンダリングするときにループさせるのはしようがないよね）

これじゃ全くSQLの恩恵を受けていない！

これらは手続き型言語でやることではなくって、SQLがスマートにできること。
だから、こういった物はSQL側にまかそう。
たいていはサブクエリーやJOINや集約やUNIONとか使って実現できるはず。
時にはSQL関数だって使える。

また、できるだけ一回のクエリーで望む集合を取り出そうとしよう！

そうでないと、それぞれ複数のクエリーで取り出した集合をメモリ上で手続き型言語によって再構築しなければならない。それはクールじゃない。

最終的に取り出したい集合のイメージをしっかりと持ってくエリーを組み立てることが大切。
SQLにおいては集合の取り出し方ではなくって、どんな集合が欲しいのかの方が大切。

昔々、webの世界でRDBMSを使うことはそれはそれは高価なことだった。
webのわずかばかりの機能にそんな高価なRDBMSを使うことは採算的にあわなかった。
ところがオープンソースのRDBMSの発展によってRDBMSは低コストで使えるようになった。
またwebも少しずつRDBMSの持つ複雑な問い合わせ機能に依存する機能をほしがるようになった。
そしてwebでRDBMSを使うことはコモディティー化した。
最近では単に永続データを実現する為に、単なるデータ置き場として使われているようだ。
また、最近のSQLを書かなくてもいいフレームワークがそれにいっそう拍車をかける。
そしてみんな複雑なSQLは書かなくなって、フレームワークに任せるようになった。

でも、もっとSQLはデータを取り扱うときにパワーはあるし、それをもっと使うべきでしょう。
フレームワークは簡単なSQLは「書かなくってもいい場合がある」ということを助ける。
だから、フレームワークが発行する簡単な物があってそれで実現できればそれにたよればいい。
しかしフレームワークが実際にどのようなSQLを発行しているのかをハックすることは大事だと思う。

現実解としてのデータベースとSQL

前にすべてのウェブサービスがローカルにデータベースを持たずに、クラウドのデータベースサービスやweb自体を直接データベースとしてクエリーできるようになるという絵空事を書いたことがある。

この考えは自分としては変わってないんだけど、現実解としては、やっぱり各ウェブサービスがデータベースを個々に抱えてそれを提供するサービスにならざるを得ないんだな、やっぱり。

いろいろクラウドとしてのウェブ開発環境が初期段階なので、まだ、十分に使えるようになっていないということ。いろいろ回数や使用量の制限がありすぎて実用にならない。

また、クラウドのサービスを使うと高コストになってしまうということ。
現実にそこらの安いホスティングでMySQL使っている方が安くって、なおかつ、ある程度までのリクエストに耐えることもできる。アマゾンもGoogleも提供しているクラウド環境は結局有償なので、何か金儲けする為のサイトでないと、簡単に使うことができんよね。

ただ、言えることはネットのウェブサービスのほとんどはデータの検索と更新追加等に翻訳されるってことは変わりはない。なんの変哲もないそれだけのことなのだ。

DBで言うとCRUDだし、HTTPでいうとRESTな訳である。
データを生成し、取得し、更新し、削除する。
それができるインターフェイスがインターネット世界にいろいろおかれているだけのことなのだ。

まずはユーザはブラウザ等のインターフェイスを使って、URLでサーバにクエリーをかける。
サーバはプログラムでそのクエリーをDBのクエリーに変換する。
そして最終的にはウェブにくっついているRDBMSがクエリーされて結果が返される。

これがクラウドになった場合、
単にRDBMSがクラウドに変わるだけで、
今はRDBMS用のSQLというクエリー言語が使われているのが、
別の言語に変わるだけである。

今単純にMVCでしっかりと作っているwebサービスは、
Mがちゃんと抽象化されていれば、簡単にRDBMSからクラウドに置き換えは可能であろう。

あとはそのデータを検索するクエリー言語の能力おの差があろうが。

その点SQLは長い歴史に基づき、また、数学的な集合理論に裏打ちを持つ為に、かなり高性能である。
私が、現在のクラウドデータベースサービスの問い合わせが、あんまり複雑なことができないというのはそういうことである。単純に今SQLでできていることが、実現できない、または、実現するにはアプリケーションの方でいろいろ面倒を見なければならないからである。

SQLがいいのは、ちゃんとRDBMSの設計が適切にできていていれば、かなり凝った手を加えた状態でデータをRDBMSから取得できる。それが一回のRDBMSの接続でできたりする。

アプリケーションの方は、ほとんどその取得データをアプリケーション側で何の手も加えることも無しに使うことができるほどだ。

だからwebアプリケーションの極意（ってほどでもないけど）のほとんどは、SQLに関するもので、SQLで適切かつ楽にデータが取得できるようにRDBMSの設計をすることである。
特にデータの持ち方は非常にアプリケーションのパフォーマンスにも影響する。

だから、しばらくはこういったRDBMS主体のアプリケーションの作り方は変わらないのかもしれない。

そういえば、最近、Firefoxも内部でSQLiteつかってたり、組み込みRDBMSがFの携帯に使われていたり、いろんなweb以外の所でも、データ管理の為にSQLが使えるデータベースが普及してきたようだ。

やはり、データを適切に管理することが現代のどのアプリケーション分野でも求められていて、それの最も標準的で普及した手法としてRDBMSが見られているということだろう。

独立記念日

フィリピンは6/12が独立記念日の様ですが、大統領令で月曜日に祝日が変更されたようです。
なので、フォリピンは月曜が休みで三連休です。

て言う訳なのかどうか知りませんが、今仕事の合間に気晴らししてたら、外から轟音でファンカデリックが鳴り響いてることに気づきました。なんかお祝いムードなのでしょうか。

周りに聞くと独立記念日はテロがあるかもしれん、なんて物騒なことを言ってました。
月曜はこちらは休みでも日本は動いてるからな。。
せめてオフィスに行かないで家で仕事しよか。

で、うちの会社もそんなこんなで金曜に新人歓迎会をかねてパーティーを開きました。
場所はエドコンの前のカラオケ屋です。

フィリピン人はカラオケが大好きで、というか、歌うこと自体が大好きなので、職種を問わず必ず誰かが仕事中に歌を歌ってます。

そういう国ですから、カラオケでパーティーを開くと大盛り上がりです。
はじめは日本人と同じく「シャイ」の気質をもつフィリピン人なので、目立ちたがり屋が歌うだけなのですが、乗ってくると、我も我もと歌い始めてすごく盛り上がるようです。
楽曲はみんな20代で若いんで、ほとんどがアメリカのポップスですね。

しかし、歌で一致団結することってあんまり実感がないんですが、ここの国民は歌で一致団結というか意気投合できる人たちなんですね。大合唱なんかしちゃって。

こういう所で音楽のパワーって感じますね。

なんて、しらけた視点で見ている寒い日本人の親父は、ただあっけにとられて、暖かい視線を送るだけでした。

saasとしてデータベース

webにデータベースというかRDBMSがくっついてwebアプリケーションなどと言われるようになってかなりの時間が経過したと思う。

僕がweb業界に入ったときは、まだRDBMSをくっつけてwebを運用するのは新しい手法で、普通ではなかった。ファイルベースの簡単なデータファイルであったり、ハッシュ型のDBMでデータを突っ込んだりしてデータパシストを実現していたように思う。

ところがRDBMSがwebにくっつくようになって、web自体のサービスが変わってきた。
今までのCGIとテキストファイルやハッシュDBMで実現していたのは、単にデータが永続化されるというメリットだけを実現できていたのだが、RDBMSが使われるようになって、RDBMSの持つ集計や並び替えの細かな昨日だとか、きめ細かい更新などが行えるようになってきたのだ。

技術者以外の方はあんまり関係ない話と思うかもしれないが、僕が言いたいのは、その技術の進化によってweb企画者の企画の発想もそれに影響されるようになってきたということだ。
例えば、最新アクセストップ10とか、カテゴリ毎に集計数をだしてリスト化してみせるだとか、そういった手法はRDBMSがwebにくっつく前はあんまり実現しにくかった。故に、RDBMSがくっついてから、そういうのが容易にできるようになったことが影響して、web企画者は企画の発想がある意味RDBMSのもつ機能や実現できることに、逆にコントロール（規定）されるようになってきたと思うのだ。

作り手も企画者も、言葉には表さないが、なんとなくRDBMSが既に存在することを前提に企画の型にはまっているような感じだし、作り手は企画者の企画をシステムい落とし込むにあたり、RDBMSを使った手法に、まず第一に落とし込むことになる。

最初、RDBMSを使うwebアプリケーションは高価なOracleだとかが使われていて、結構、重かったり、アクセスが多くなると破綻していたように思う。
それが、MySQL等の安価なコストのRDBMSの出現で一気にコモディティー化した。
誰でも、何でもかんでもRDBMSを使うことがwebの決まり事であるかのようになっていった。
RDBMSの使い方も本来の使い方とは違うところで、単なる、ファイルシステムの代わりとして使われるようになっていった。

確かにMySQL等オープンソースのRDBMSの普及により、前よりはシステムが負荷によって落ちることは少なくなった。ノウハウも少しずつ蓄積されていったことも影響している。

ところが、そういったRDBMSの機能向上を上回る勢いでインターネットというかwebを取り巻く環境が成長していった。それによって、驚くほどのアクセス数がアクセスするようになり、未だにRDBMSをどうアクセス数に大してスケーラブルにしていくかに関するノウハウやそれにかかるコストは無視できない物になってきている。データも無くしていい軽い物から公共の財産という概念にかわり、よりいっそうデータをなくさないように運用することが求められてきている時代でもある。

同時に僕がかねてからいっているように、RDBMSに規定された企画の発想が故に、二つの大きな問題がwebシステムについて回るようになった。

一つはどうやってそのRDBMSを埋めるデータを個々のサービスは集めることができるのか。
もう一つはそのデータを良質なレベルに維持するため、メンテナンスをどうすればいいのかということ。

大概のweb企画はここで頓挫する。
これは大規模になったときの問題（twitterの残念な現状とか）とあわせ現状の問題点になっている。

ところが最近一つの流れが起きてきている。
インターネット自体を一つのプラットホームとして見なすクラウドコンピューティングの考え方である。

既に大きなクラウドコンピューティング環境を保持するgoogleとかamazonがそういったクラウドコンピューティング環境を一般webサービサーに解放していく流れが最近でてきている。

インターネットをプラットホームと考えたり、クラウドコンピューティングの考えを持つと、上記にあげた二つの現状の問題点は解決されてくるのではないか。

データをどう「自分んの物として」集めるか、ではなく、データは既にプラットホーム（インターネット）の中に豊富に存在してるのだという視点。また、プラットホーム（インターネット）のデータは公共財であるが故に、自分の集めたデータも公開していくというマナーといかルール。

また、膨大な負荷をさばくことも、既にあるクラウドコンピューティング環境がさばいてくれる。
個人やサービサーは安心してそういったことを気にせずにサービスだけを考えていくことができる。

そういった経緯もあり、最近、amazonのSimpleDBとかgoogleのApp Engineとかsaasとしてのプラットホームを活用できないかどうか調査している。

しかし、こういったサービスに共通していることだが、やはり既存のサービスと比べてできることが限られているし効率も落ちる。
それはちょうど昔、デスクトップアプリケーションとwebアプリケーションを比べて、やはりwebアプリケーションの方ができることに制限があったり（OSの内部にアクセスできないとか）使い勝手においてデスクトップアプリに負けていたことを思い起こさせる。

しかし最終的に、webアプリケーションの使用がデスクトップアプリケーションに勝りそうな状態になっている現代である。

これはwebアプリケーションの使い勝手やできることが進化したということもあるだろうが、やはり、ユーザ自体の使い方が変わってきたいうことだろう。全体的にリッチで複雑な操作系よりはシンプルな操作系、使い方も効率性よりはライトな使い方が中心になってきたからではないだろうか。

saasとしてのデータベースやアプリ環境も同じで、
現在のローカルにDBをもつwebアプリケーションに比べると、あまりできることは多そうにはおもわれない。

例えばamazonやgoogleが提供するデータストアに関しても、現在のRDBMSのような細かい集計機能はそなわっておらず、それを簡単に実現することはむつかしい。
つまり今までのweb企画者が発想する企画を実現するには、これらのサービスは「機能がたらない」。
プラットホームとのインターフェイスがSOAPなものもあり、細かい頻度の更新にも向いていないようだ。
だから、「今までの発想の企画」にこれらを使おうとすると、開発者は大変である。

おそらく、「違った切り口」か「よりいっそうのシンプルさ」を軸にサービス企画を立てないと、これらのsaasプラットホームはうまく企画にフィットしないように思われる。

しかし時代の流れは必然なので、webにRDBMSがくっついてweb企画者の発想が変わったのと同じく、saasプラットホームが中心の時代には、それにより発想が転換した「新種の企画者」が出てくるのではないかと思われる。

おそらくは、もっとライトなサービス。
（プラットホームの）部品としてのサービス。
それらの部品を利用したメタサービス。
お互いのサービスは利用しあうという発想。
そのためにインターフェイスが常に公開されているという姿勢（みんなの為は自分の為！）

僕が最後にいいたいのは、
技術者の人には非常にweb企画やサービス企画に関わるのに有利な時代が来ているということ。
サービス企画をやられる人には、技術を恐れないで、そこで提供されるプラットホームで何ができるのかを、さけないで、正面から見つめることをお勧めしたい。
それには多少の技術を知ることも必要になるとは思うが、この世界はやはりそれを知らないで通り過ぎることはできない。

新しいサービスをやりたいのならなおさらである。
もしあなたが、今の、自分の所で抱えた閉鎖的なデータベースでゴチャゴチャやってそれで満足している、楽しいのならばそれでもいいんだけど。

ユーザはあなたの所のトップ10とか新着とかにもう興味が無いんじゃないかな？
そのカテゴリに何件あるとかさ、全く関係ないんじゃないかな。

少なくとも僕はそうだし、時代は本当に変わりかけていると思う。

睡眠は大切

今日の偏頭痛で昨夜0時台から本日15時台まで睡眠を取ったんですが、非常に調子がよくなりますね。

僕は人と比べてロングスリーパーの方なのかもしれない。
わりとだらだらと。睡眠の集中力が無いのかもしれない。

ロングスリープをすると、
昨夜まで悩んでいたことに、おきがけに既に結論が出ていたり。
昨日まで気づかなかった価値に気づいたり。
新しい物や情報に対する意欲が増進してたり。
創造性が活発になったり。

とにかくいいことずくめですね。
起き抜けから頭がフル回転しているかんじです。
起き抜けに取るコーヒーのカフェインがそれを増幅します。

今日からは睡眠時間の確保にもっと注意を払おう。
具体的にはもっと早く睡眠につかないとだめですね。
僕の場合は集中した睡眠が難しいので、割と余裕時間をとって、眠りにつくまでのぐずぐずとか、寝起きの二度寝三度寝とかを計算に入れないと行けないみたいです。

I was down

極度に体調が優れず、今日はずっとコンドミニアム。

昨夜、同僚にマニラの火鍋屋につれていってもらって帰ってきたのがこちらの0時くらい。
極端に疲れていてすぐ寝入ったのだが、結局今朝起きるとまた偏頭痛で、二度寝して起きたのは15時頃であった。

近頃、偏頭痛が頻繁にする。
何かがおかしいのか。
マニラの暑さは偏頭痛を増幅する。冷やすと心地よい。
まだ環境に体がついていってないのかな。

今日はずっとよくなったので、お米を買いにいこう。
納豆なんかも買えるといいな。

フィリピン到着

今フィリピンに到着してコンドミニアムに落ち着いています。

着いて早速、暑いですね。
夜なので幾分涼しいのですがそれでも。。

着いて早速チップ攻勢にあい、フィリピンに来たことの実感を感じます。
この国はサービスは金で買う、安全や快適は金で解決する、が徹底してます。
といってもサービス大したことは無いですが。。。

空港からマカティーのコンドミニアムまでクーポンタクシーを使いました。
普通のタクシーだと結構ぼられたりトラブルになりやすいです。
一見安そうなんですが、結局高いことになる。
特にこのご時世原油価格が上がっていて、この国のタクシーはガソリンなので、結構困ってると思います。その分悪どいことをしようという人間も多くなります。
入国でて出口ですぐ声をかけてくるのはこのたぐいです。
この国のタクシーを嫌いな俺としては絶対に乗りたくないです。
クーポンタクシーは値段は普通のタクシーより張りますが前払いで明朗会計です。

このようにこの国では安全や快適は金で買うのです。

久しぶりにコンドミニアムに戻ってきて、前と違うのは、日本のご飯を食べられる食材を持ってきていること。生活に必要な小物を持ってきていること。インターネットが通じていること。
だいぶ前よりは人間らしくなってきました。

今回は体調を崩さないように気をつけて参りたいと思います。

フィリピン出発

いよいよ出発で今、成田で飛行機を待っています。

なんかPCを開くのもおっくうで、EMONSTERでかいてます。

なんかフィリピンの生活に魅力を感じていないのでちょっと凹んだ気分です。いいなあ、と言ってくれる人もいましたが、個人的にはちっともいいことはなくって、家族と離れるしさみしい限りです。

恥ずかしい限りですが、うちの犬は子供と同様なので会えないとかなりつらいです。妻はSkypeでコンタクトできたりして結構つながれるんですが、犬はそういうわけにいきません。犬は嗅覚で存在を感るので、Skypeで声や顔は認識できてもにおいがしないので、不思議なようで、かえってさみしい思いをさせてします。僕の声が聞こえると玄関に走って探しにいっちゃうようです。

今日も出かける近くで準備から出かけることを感じ取って急に息が激しくなってまと割りついて大変でした。

そんなこんなもあって、思い出して写真とか見ると寂しく後ろ向きになるので、逆に前向きに早く生活と環境を安定させて、フィリピンの方に呼べるようにと考えるようにしています。頭でシュミレーションするのです。そうすると、心が落ち着きます。

さて、物事を前向きに考えれるようにするためには、いろいろ基礎環境が必要です。僕の経験では、睡眠をきちんととること。これが一番です。後ろ向きだなと感じたらまずは睡眠をとること。自律神経が正常にはたらきます。

あとは、フィリピンは暑いのでばてないようにすること。

結構、冷たいものをがぶのみしがちなので、冷たいものは、口に少量づつ含んで少しずつ飲むこと。胃液が薄まっちゃって消化能力が落ちます。

あとは甘いものの飲みすぎに注意。
フィリピンで買える飲料は水を除き甘いものが多いので飲みすぎるとビタミンB群が不足してばてやすくなります。

とにかく体のコンディションの維持が前向きにつながると思います。

というまに、搭乗の時間になりました。
それでは。

プラットホームとしてのウェブということ

案外、ネットに関わる人たちの間でもあんまり実感できてないことの一つだと思う。

僕らは既にあるwebのプラットホームの上に新しいアプリケーションを築けばよくって、なにもかんにも、一から構築する必要はないんだということ、案外理解されていないと思う。

逆に一からすべてを構築することは、既にいままで蓄積されてきたwebというプラットホームの恩恵を受けることができずに、面白みの無いアプリケーションの構築につながる可能性が高い。

まずはデータということ。
それをどこから集めるの？ってこと。そういういつもまとわりつく問題点。
これひとつとってもwebプロットホームの既にある豊富な資産という視点が見えないサービス企画は多い。そういうサービスに限って、そのコンテンツがwebというプラットホームになんにも（データという形で）還元しないという負の連鎖を持っていると思う。

私（私のサイト）だけで完結するより、外部とつながった方がもっと面白くなれるから、周りに対してはオープンでいてほしい。外部にオープンでいてほしいがゆえに自分のデータもオープンにするという姿勢。
この連鎖がwebというプラットホームをより面白くしていくのだと思う。

だから、既にあるwebアプリケーションやサービスに付随したサービスを作ることに後ろめたさを感じるよりは、より積極的にそっちの方に出て行くべきだ。

googleを近年まれに見るプラットホームだと認識するだけで、かなりかわった観点でサービスを作ることができるんだけどね。