既存のスキームを超えたものなので、ジャンルとかどういうゲームだ、というのを言葉で表すのは難しいし、自分も実際にやってみるまではレビューを読んでもよくわからなかった。SSもたくさん紹介しておられるので、未購入の方は「AppBank:Zen Bound:待ちわびた、木を縛るiPhone緊縛プレイ。Ghost Monkeyの音楽で時間が消える。136」を参考にされると購入の参考になりやすいかな？とご紹介してみる。

評価も多くて高いので迷わず買ってみたが、やはりこれだけの市場の中で世界中に支持されるモノは、やはり「ゲームってこうでなくては」というようなジャンルとか、そういった前提となるセオリーを壊してるからこそ≒代わりになるものが他にない、創造性の高いジャンルだからこそ成功したのだろうなぁ、とつくづく思わされた。

余談ですが、ウチの会社は朝礼があるのですが、丁度当番だったので、このアプリの例を紹介して「セオリーも大事だが、その枠にとらわれないことも大事だ」というような事を言ったんですけどね。終了直後、「セオリーを踏襲した上で、その上でやらなきゃダメだよね」とマネジメントクラス二人が言ってるのが聞こえた。

下っ端の俺が思うのもなんだけど、そこが“一線”なんじゃないのかよ、と。

セオリー、定石というのは、成功経験の蓄積によって出来たものだ。だから普通はセオリーを踏襲するのが当然だ。しかし、IT業界は変わりのものがいくらでもある。成功するには、他にないオリジナリティがないと難しくなってきている。参入障壁は低いが、その分競合するものも多いからだ。

特に新規コンテンツ企画といったものは、既存のスキームに縛られた時点でアウトだ。そんなものはたぶん競合他社も作ってるだろう。ヒット作のせいで、続編でそこから抜け出せずに失敗する映画やゲームのよくあるパターンと同じだ。また、自分が成功してなくても、他人の成功談を本やなんかで読んで、それを盲信してしまう人も同様。

経済ニュースを斜め読みでもしてれば誰でも分かることだが、「ニーズ」は粗方汲み尽くされて、新しいこと・誰もやったことないことを、顧客ニーズから引っ張る以前にこちらから新しい価値として提案しよう、というタームに入っている。セオリーにとらわれた時点で終わりだ。
本当に創造力の高い人は大抵、まず作りたいもの、やりたいことをとりあえず考えてしまってから、それは可能か・やってもいいことか・穴はないか、などといった、要は現実問題を考える。一般人の我々には難しいことだが、それを知りつつも尚、最初に制限という枠組みを設けた上で、そのサンドボックスに自ら入り込んでしまった時点で、「安全だけど、最初に作った砂場のサイズを越えるもの」は絶対に作れない。より矮小なものしか作れない。実現は難しくとも、学ぶことは出来るハズだ。

セオリー通りの企業がGoogleになりえたか？むしろGoogleがセオリーをつくったではないか。Appleもそうだし、Twitterはじめ、これまでになかったものを作り出した者はみんな「自分がセオリーを作り出してきた」。

上に書いたように、Webコンテンツ業界という競合の激しい業種にいる時点で、もう「ウチはもっと穏便にやります」は通用しない。否応なく世界中との競争に巻き込まれる。だからこそスピード感と創造力の双方が欠かせないのではないのか。

まあ、後輩が間違ってると思うなら、面と向かって「それは違う」と言えない時点でまずマネジメントとして失格だね。マネジメントしてないんだから。
また、チャレンジャブルな企画提案を同氏に持ちかけたら「そんな甘いことは無理」と言っていた割に、更に上の上司を通して話してもらった途端、肯定に変わった。何をマネジメントしてるんですか？
本当に有能だと思う上司は、きちんと「下の子と話してるけど、やっぱり下も細かいところをちゃんと見てるんだなと思う」と言ってますね。下の我々からも学ぶところがある、と言われたほうが、遥かにその人の下で働きたいと思いませんか？

自分が正しいかどうかは分かりませんけどね。しかし、少なくとも自分の考えは「絶対間違う」ことを前提としているので、常に自己批判しながらやっていくしかないな、といったところでしょうか。

自分は今んとこサーバーとかネットワーク周りの仕事がほとんどなので、たまぁにプログラム書いてもPerlで簡単なスクリプト書いてcronで回すとかそんなもんですが、時々ちゃんとMVCとかオブジェクト指向を今のウチに習得しとかんと、年くったら吸収悪くなんぞ？という危機感はあります。

Perlで先に進むのも一つの選択肢ですが、悲しいかなOOPやWebアプリケーション開発という時流を汲んで開発（または拡張）された後続言語からすれば、Perlの実装は特殊すぎて他に使い回せねぇじゃねーか、と思うところはなくもない。こないだ少し大きめの社内用アプリをWebベースで書いてたらキレそうになった。まあ、packageの使い方がダメダメだとか能力的なものはあるけど、少なくとも素人が書いたらどうしようもなくなる言語は、そこそこの人が書いても規模が大きくなったときにほころびがより出やすいんじゃないだろうか。

もちろん、mixiなどもmod_perlで書かれてますし、キチンとコーディングルールを作った上でpackageやライブラリ化などを適切に使えるならそれでもOKなのでしょうが、それが出来ないレベルの素人（＝自分）にはしんどいです、正直。フレームワークも…なぁ。

んなワケで。会社で使ってるから?という理由で同じ言語やフレームワークを使ってもイイのですが、OOPに向いてる言語、可能だけど不向きな言語とかはよく聞きますよね。ruby on railsはものすごく賞賛されていますが、概念自体はいろんな言語に取り入れられたけど、rubyで開発された大規模なシステムって（あるんだろうけど）そういえば聞かない。実行速度やソース行数（記述）などを考えると、かなり大規模なシステムでは、むしろPython使ったりとかいうケースが多いらしい。

JAVAはよくオブジェクト指向という言葉と同時に出てきたりしますが、周囲にJAVA使いがまったくいないし、故にTomcatをわざわざ入れることもないので使いません（ちょっとだけ書いてみたことはある…触りだけね）。Webアプリ＋フレームワークで気軽に覚えられることを考えると、やはりLAMPでフレームワークをどうするか、って感じが一番ラクなのかねぇ（基本的に概念を掴むことが目的なので、資料が豊富な言語であればいいし）。

じゃ、フレームワークは？会社で使ってるヤツは、特性と目的が決まってて選んでるだけなので、世間的にはマイナーで資料もホントに少ない。Zend Frameworkとか、cakePHPとか、Symfonyは本屋でよく見ますね。そのへんはホント素人なのでPHPプロを見てみると、…。どうなんだろう。symfony、自動生成部分が多いということは、少なくとも初心者があまり考えずに書いても、ViewにActionほとんど書いてしまったり、ということは少ないんじゃないか、と思うのだが…。実行速度で劣るようだが、書きやすさや安定性を重視した結果そうなっているのなら、実務は知らんが学習にはいいんじゃなかろうか…。

以前、symfonyのデモ動画を見たら、WebアプリケーションのクセにデスクトップのIDE並みにサクサクブログとかを実装してて驚いた記憶があります。んー、ちーと入れてみたりするかなぁ。

ペーストビン(pastebin)について – Life, don’t talk to me about life.

詳細とか使い方は上で説明されてるので割愛しますが、「コピペ内容を共有するためのサイト」らしい。

フォーラムやメッセンジャーなど、エラーやソースコードを直接貼り付けたら迷惑になる場合、「○○でエラーが出ました。エラーログは…（ペーストビンのURL）です」と書けばスッキリするワケです。

なるほどねぇ。

ちなみに原語（カナダ英語）ではgeneral pastebinで、日本語版を直訳しちゃったからよくわからないタイトルになっちゃったんでしょうね。「このサイトは別な国語を表示されています。下手な翻訳に申し訳ないです。」とありますし…。

別にiPhone向けとかいうワケではない（当然PCやMacだけでも使える）のですが、かなりiPhoneとの親和性が高いです。iPod touchでも良いとは思いますが、3Gとの組み合わせがあるiPhoneでは、デフォルトでつけてくれよと思うくらい便利。

元々PDAとかでPIM機能を多用していたとかもあるとは思いますが、今まで個人的には、PC・PDA・オンラインストレージ間でデータを動機するには、

1. PDAをPCにつなぐ
2. ソフトとかでオンラインに同期
3. どこかの端末でデータを編集した場合は、いちいち同期作業が必要

だったのですが、MobileMeを有効にして、iPhone本体でプッシュ機能を有効にしていれば、

• ネット（ブラウザ）でデータを編集する→即座にiPhoneに反映される
• iPhoneでデータを編集する→即座にネットに反映される

PIM機能としては今までにない革命だと思うのですが…。

ちなみにPCはMobileMe同期ソフトがあれば、Outlook ExpressやWindowsのアドレス帳など、数種類のアプリケーションと同期することができます（自動にしたり、間隔を変えたり、無効にしたり、特定の機能だけONなども可能）。

個人的にはPCとiPhoneはiTunesとの同期しかしていないので、PC側のMobileMeは切っていますが、とにかく編集がラクなPCでアドレス帳や予定入力などを一気にしてしまえば、何の作業もせずに、勝手にiPhoneとデータが同期されてます。

あとはme.comドメインのメールが、日本の一般的な携帯のメールっぽい通知をしてくれるので、「プッシュでメールがこねぇ！使えねぇ！」という人は、iPhoneの欠点のひとつを補完してくれてイイ感じだと思います（通知は淡白ですが…）。

欠点としましては。

• 値段が高い
• Safariやfirefox（Windows）でたまにWeb版の動作が変
• ふりがなが「名・姓」の順になっている（漢字は姓名）など、微妙に日本仕様になりきってない

まあ下二つは世界中で使われてるサービスですし、これから改善されていくことも期待したいですが、機能をもう少し削ってもいいので（ライト版を作るとか…）、他のキャリアの似たような機能と同等の金額で実現してほしいなーと。まあ元々iPhoneだけじゃなくてPC・Macとの連携を含めたサービスだし、母艦と同期する前提なら高くはないとも言えますが…。

# でもiPhoneユーザーも多岐に渡ってきてるし…安いプランがあってもいいかな、と。

当然ながら2.6x系から大幅に変更されてDB構造が変わっているので、アップグレード時にDB構造も更新されます。重要なサイトを運営されている方は、情報が出揃うまで待っても良いかも知れません（今フォーラム等でプラグインの互換性とかの情報が追加されつつあるので…）。

あと、自動アップデートが一部まだ正常に動かないよ～という情報があった気もするので、まだしばらくは自分でファイルを置き換えていく作業がいるかも知れません。

ぱっと見た感じでは、管理画面のデザインなどは大きく変わっている割に、プラグインやスキンは特に問題なく動いているので、公式にもあったとおり、今回のバージョンアップは仕様より、公式にもあるように、今後の開発の土台を再構築したところが大きいのかも知れません。

んじゃ直接ユーザーが使う分には何が変わったのかですが、以前RCを入れたときに書いたように、管理画面のデザインはもちろん、JSやFlashなどでUIはかなり良くなってます。自分の環境だけかと思ってた、画像のFlashアップローダがうまく動作しない現象が他ブログでも言及されてたので、どうやら不具合だったようですが、2.7では解消されてます。あと、細かいけどユーザビリティが向上してるところ（下書きの自動保存がリアルタイムで表示されたりとか）が結構ありますが、使いやすさって結局そういう細かいところのストレス潰しですからねー。大切。

あとは自分でプラグインとか作らないし、内部的にもあんまりいじらないから分からないのですが、APIが追加された？何かまた新しいモノが出てくるかも知れません。

JS、CSS3、APIなどが追加され、簡単な記述で描画できるようになったようなので、プラグインなどがなくても、ブラウザ標準で結構リッチな表示が可能になってるようです。HTML構文も、HTML4対応ブラウザに影響を与えないことを重視して草案が作られているようなので、「また移行かよ～」とWebデザイナーさんがムキーとなる機会は（これまでほど）ひどくないかも知れません。新しいことをするには結構覚えることがあるかも知れませんが…。

…と、個人的にはこっちよりCliant-side DBのほうが気になっているところです。これまで、クライアントサイドに情報を保持させるにはCookieやプラグイン等に依存するなどといった方法しかありませんでしたが、標準化されているCookieは少量のデータしか扱えない→基本的にはサーバーサイドで処理することになっていたわけですが、クライアントサイドにSQLデータベースが実装されることで、かなり色んな可能性が広がるんじゃないかなーと思います。

オンラインゲームとかメッセンジャーでも、すべてを大本のサーバーで処理するのは負荷が大きすぎるので、クライアントサイドで親子関係をつくって、簡単な処理はクライアントサイドや親とのみやりとり、親が計算結果をサーバーに返すという構造をとっている場合もあるとか（Skypeも一部そんな仕組みがあったハズ）。

それと同様、少し大きな処理をするときはクライアントサイドDBに情報を格納しておき、JSなどで計算や制御を行い、最終結果だけサーバーに返すことで、毎回サーバーに接続するコストがかなり小さくできます。現在でもFlashで実装したり、専用アプリケーションをDLさせたりといったものはありましたが、それがブラウザ標準で出来るようになるなぁ、ということです。
GoogleがOfficeアプリをWeb上で提供していますが、現在ネックとなっている通信待ちが大幅に短縮できるとなると、Web上でのアプリケーション提供がもっと一般的になるんじゃないか？という話もあります。MSも、OfficeのWebバージョンを開発していますし、今後どんな変化があるかは楽しみなところです。
もちろんOfficeアプリケーションだけでなく、たとえばCGMサービスではコストの都合上難しかったことが、サーバーがデータの送受信に処理能力を集中させられることで、かなりリッチなコンテンツの配信を可能にするかも知れません。

画像や音楽など、データ量的やセキュリティ的にもデスクトップアプリケーションが駆逐されるほどの変化はないでしょうが、Webアプリとデスクトップアプリ開発の垣根が徐々に薄れていくことで、両方の長所やノウハウ蓄積によって、これまでなかった新しいモノが登場する可能性が楽しみです。

※一応、もし今後スキンとかデザインを変えたときのために書いとくと、PCブラウザ用にはWP.vicuna＋bazookaスキンを使っています

…とまあ、こんな感じでiPhoneの操作性に合ったデザインにしてくれます。ちなみにWordPressのコンパネから設定はできますが、今回はとりあえず入れて有効にしただけです。やっぱり画面が小さい分、タイトル一覧とか、文字などが大きくてタッチ操作に最適化されているのがイイ。

今回コレを入れてみて思ったのですが、日本の一般的な携帯とか他PDAとか、確かにフルブラウザでPCサイトを表示できるようになってるし、リンクなど項目間の移動はしやすいように（ハード側の）インタフェースが工夫されたりしてるけど、やっぱ操作方法とかハードが違うモノだと完全にはフィットしないな、と。Windows Mobileとかは細いスタイラスだったけど、それでも細かいリンクは押しにくかったので、結局表示を拡大して使ってたような。ユーザーの方が仕様に合わせてた、的な。携帯はいわずもがなですね。

もちろん、もし「話題の端末だから、サイト側がしぶしぶ対応せざるをえない」独自規格だったら「ふざけんなー」で終わるのですが、Safariはそのままでもピンチイン／アウトがあるし、iPhone最適化も、基本的にはWeb標準規格に沿うだけでOKなところは、ある意味携帯キャリア毎の独自規格とか、PCブラウザの独自拡張よりは良心的な対応だ。こういう最適化の方法は、他OSでも積極的にパクッて欲しいところ。フルブラウザがPCサイトをそのまま表示しない選択肢もアリ、というのは目からウロコだ。

当然、ゴロ寝で見るとき勝手に表示がランドスケープにならないように固定したい…とか、広告とか画像多いと落ちたり重かったりする…とか、サイトURLとかRSS FeedのURLとかを他アプリにコピーできないとか、Flash見られないとか、不満は少なくないですが…。少なくとも、フルブラウザの中では今んとこ一番使いやすいんじゃないかと思う。

全体的に今よりスタイリッシュな感じになっています。アイコンは公式で複数案の中から選ばれたものが使われています。ドロップダウンリストやメニューにはかなり動的要素が用いられていて、大メニューにマウスカーソルを置くと▼が表示され、直接小メニューに飛ぶことが出来るようになっています。動的要素の積極的な導入で、同じ領域の中により多くの情報が詰め込めるようになったという感じがします。

ダッシュボードにクイック投稿がついていたり、これまでのメール投稿だけでなく、ブックマークレットetc、多くの投稿手段が用意されています。

プラグインの自動アップデートは現在もありますが、2.7ではFTPだけでなくSSL経由のFTPも使えるようになっています。これは、2.7の目玉機能のひとつである、WordPress自体の自動アップデートでも同じです。（なんかホストやログイン情報を入力しないといけなくなったようですが）

投稿のタグ機能など、今までもより多くの付加的な要素は追加されてきていましたが、さらにテーマ側で使うための付加的要素なども盛り込めたり、リンク（ブログロール）も（日本ではあまり使われてないと思うけど）リンク先との関係性などの要素がより細かく入力できるようになっています。

気になる点があるとすれば、UIが大幅に変更されていること。上に書いたように使いやすさもアップしているものの、やはり突然上メニューがサイドになっていたり、これまでと多々変更がなされているので若干迷います。まあ、ここは良し悪しというより好き好きですね。客観的に見ての使いやすさはかなり改善されてきていると思います。

あと、設置後の自動アップデートは一旦環境をつくってしまえばその後はブラウザ上でほとんどのメンテナンスが出来るようになるので大歓迎（というか、他機能をあまり使わない自分としてはそれが一番重要）なのですが、現在2.5系以前を使っている場合、要素などが増えている分、DB設計も結構変わっているハズなので、そのあたりの変換が必要になった場合にどうなるのかは気になるところです（ファイル構成はぱっと見あまり変化なかったので、メディアファイルはまだ移しやすそうな感じ）。

他はまあプラグインとかスキンですが、こちらはそれぞれの開発元の正式対応発表を待つか、自分でいじるしかないですね。個人的には2.5系でも特に不便を感じているワケでもないので、そうした環境や情報が揃うまでは待ちでいいかな、と思っています。

Twitterのサイト、重すぎてつながらない。

と思ったら、TwitterのDBサーバーはたったの３台らしい！（Next Big Thing!!）から、まあそりゃ重いわけだ。しかもメッセージング処理だけなので１つの処理は軽いと思われるが、その分プロセスが1サーバに大量に発生するはずなので、C10K問題に引っかかる、さあどうしましょ、ということらしい。

まあ、試験的にはじめたとか、ビジネスモデルとして成立するかという話に至ってないからしょうがないとか、色々意見はあるようですが。個人的には今までまったく興味がなかったので知りません。というか、とりあえず重いなら代替サービスを探すのみ。話題になったんだから、いっぱいあるでしょ、同系サービス、ということで。

基本的に、日本人受けしやすいモノ（≒日本人に使いやすいもの）は大抵日本独自のアレンジがされたものだ（日本のSNSでLinkedInみたいなのはまず流行らない。個人的にはよさそうだと思うのだが…）、と考える私は、Wassrを選択。APIも公開してるし、いくつかあった中ではよさそうだ。ちゃんと公式でブログパーツやツールも。

まあ、しばらくいじってみますかね。

まーだからこそ寡占ってイヤだねぇという話なのだけど、検索精度の上がってきたYahooやMSNはどうなのだろう、とちょっと使ってみたところ、やはりテキスト検索ではさっぱり使い物にならん。いや、Googleのテキスト検索精度がそれだけ高いということなのだろうけど、履歴記憶一切無しにしていても、テキスト検索でGoogleは強い（まあ画像はイマイチだけど）。

その上、先日故あってインターンシップのサンプルプログラムでGoogle Map APIのプログラムを作ったのも皮肉な話だ。まあ、GPS連携とか、同様の処理（Yahoo!地図とか）には部分的に使いまわせるトコもあると思うのでメモっておこう。あ、Perlです。

今回試したのは、携帯GPSとGoogle Static Map APIの組み合わせデモプログラム。通常のGoogle MapはJavascriptでAjaxバリバリですが、携帯ブラウザでは閲覧できないので、Static Mapを使います。と言っても、値を渡すURLと、一枚の画像として出力される点が異なるだけです。URLは以下のような形式になっていますので、値を渡してやれば画像が出力されます。

<img src=”http://maps.google.com/staticmap?center=[緯度],[経度]&zoom=[ズーム]&size=[横x縦]&maptype=mobile&markers=[緯度],[経度],redp&key=[APIキー]” />

こんな感じで…staticmap?の後に引数を渡します。各項目の詳細は以下。

• center 画像の中心の経度と緯度。カンマで区切る。
• zoom 画像の倍率。数値。大きいほど寄り、小さいほど引きになる。とりあえず15くらいでテストした。
• size 横x縦。ピクセル単位、真ん中はx（小文字エックス）で区切る。今の携帯だと240×320くらいかな。
• maptype 今回は携帯なのでmobile。roadmapというのもありますが、今回使ってないからやってません。
• markers マーカーの緯度,経度,色と文字。緯度経度はcenterと同様に指定すればOKですが、色と文字は例えば赤でAと表示したければreda、青でPと表示したければbluepと指定。どんな色があるかは調べて下さい。
  ちなみに[マーカー引数]%7C[マーカー２引数]%7C…とやることで複数のマーカーを指定できます。
• key APIキー。

とりあえず基本はこんだけ。ドコモの場合、formタグやaタグの最後に

<form action=”url” method=”GET” lcs>

とlcsをつけると位置情報をプログラムに渡せるので、取得した位置情報を先ほどのURLに渡…したいのですが、実はGoogleとドコモはどちらも世界測地系のWGS84とやらを使っているのですが、ドコモで取得した値はdms（度分秒）なのに対し、ここでAPIに渡す値はdegree（度）になっているので、途中に変換処理をかます必要があります。計算式もあるようですが、PerlならGeo::Coordinates::Converterを使うと、さまざまな表記法を相互変換してくれます。とりあえず、今回のdms→degreeであれば、

use Geo::Coordinates::Converter;
（略）
my $geo = Geo::Coordinates::Converter->new( lat => $lat, lng => $lon, datum => ‘wgs84′);
my $point = $cgeo->convert( dms => ‘degree’ );

こんな感じで緯度・経度・測地系、変換元形式・変換後形式を指定してやればOK。

このモジュールの使い方は、なんか今CPANつながらなかったので、飛んで検索してもらえばよいかと。