手書きチャットアプリ、neu.Chat ついにリリース
４回の承認落ち、３回のエスカレーション、３回の長時間電話の末、１１ヶ月の歳月をかけ、ついに neu.Chat（無料） が Apple の承認を通り、ようやくiTunes ストアにリリースすることができた。 手書きチャット（およびボイスチャット）のために P2P コネクションが必要だったので、Apple が提供している GameCenter + GameKit を活用して実現し、去年の１２月に申請に出したところ、「ゲームでもないのに GameCenter のサービスを使うのは規約違反」と承認落ち。 何かの勘違いだろうとエスカレーションをして電話で担当者と話したところ、勘違いではなく、それが Apple のポリシーだと言われる。かなり長く粘ったのだが突っぱねられ、かなり気落ちしたことを覚えている。 しかたがないので、手書きで「マルバツ」と「五目並べ」を遊べる機能を加え、「これならゲームだから問
ソニー、家電事業からの完全撤退を表明
２０１２年４月１日、エレクトロニクスおよびエンターテインメント大手のソニーは、テレビ・DVDレコーダ・デジタルカメラ・携帯電話機などの民生用電子機器事業をすべて売却し、業務用電子機器およびソリューション事業に集中することを発表した。事業の売却先は未発表だが、パナソニック、鴻海精密工業、サムソン、ノキアなどと交渉中とされている。また同時に、医療用カメラ事業の取得を目的に、株式会社オリンパスの株式の公開買い付けを発表した。また、これまで複数の子会社に分散していた映像・音楽・ゲーム事業を一つにまとめ、「ソニー・エンターテイメント」として２０１２年中に米国ナスダック市場で上場させることを発表した。上場時に２０％、２０１５年末までに８０％の株式の売却をする予定。 エイプリルフールネタなので、本気にしてほしくはないが、このくらい思い切ったことをしないとソニーは再生できないだろう。去年、ソニーが Haw
SNBinderと「混ざり物のないコンソメスープ」と
先日オープンソース化したSNBinder（参照）、たくさんの人たちから色々なフィードバッックをいただけてとても感謝している。ブログの記事として書かれたものは私が知る限り以下の三つ。 penultimate diary: SNBinderを試してみる js do.it: SNBinderを試したよ！ a2c.get.diary: SNBinderに目からウロコ 小さなMVCが今現実に 当初は、最新のjQueryと動かないというバグがあったり、READMEにタイポがあったりとご迷惑をおかけしてしまったが、こうやってフィードバックをいただくことによって、励みになったり改良したり、というのがオープンソースの醍醐味である。とてもありがたい。 ちなみに、SNBinderは原型のようなものは１年前以上前からあったのだが、ViewとControllerの切り分けに部分がなかなかすっきりせず、公開を控えてい
勝てば官軍、負ければガラパゴス
私が数年前からこのブログで使っている「ガラパゴス化」という言葉、今やテレビや雑誌でまで見る様になり、何だかうれしいような悲しいような、複雑な気持ちである。 私が最初に公の場でこの言葉を使ったのは、２００１年のCTIA（米国最大の携帯通信業界のカンファレンス）でのこと。UIEvolutionというベンチャー企業を立ち上げたばかりでもあり、この業界でなんとか注目を集めようと、「NTTドコモのiモードのことなら詳しいので、日本の若い人たちのライフスタイルがiモードでどう変わったからなら解説できるよ」と会議の主催者に連絡すると、いきなり２０００人も収容できる会場を割り当てられたのだ。 私がNTTドコモから来た人間だと勘違いした人もいたようで、会場は超満員。冒頭でドワンゴの「釣りバカ気分」の面白さを手振り身振りで伝えたところそれが大受けで、日本のギャルの生態系の解説も交えながら、日本の「ケータイ文化
Google App Engine入門：実践編
今週に入って、Tiny Message に続く二つ目の Google App Engine ベースのサービスをリリースした。３日ぐらいで試験的に作った Tiny Message とは異なり、今回のものは、丸二ヶ月間寝る間も惜しんで作った力作である。 米国向けのサービスな上に招待制のSNSなので、ここではサービスそのものは公開しないが、いくつかこだわって作った部分があるので、それについて語ってみようかと思う。 1. 対象となるユーザーの絞り込み FacebookやTwitterのような巨人が存在している中で、それにまっこうから対抗するようなソシアル・ネットワーク・サービスを作ったところで無謀なだけである。そこで、逆に対象にするユーザー層を究極にまで絞り込んで、彼らのライススタイルに徹底的にマッチしたサービスを作ることにより差別化をはかる、という戦略を選択。対象は「LAに住む２０〜３０代の社交
Google App Engine上のベスト・プラクティス、その１: Datastore
Google App Engine上でアプリを作りはじめて約二ヶ月。いろいろと分かって来たこともあるので、自分へのメモも含めてまとめてみる。まずは、Datastoreの話から。 なによりも大切なのはデータベースの設計 あたりまえと言えばあたりまえの話だが、App Engine上でアプリを作る上でもっとも大切なこと（＝頭を使うべきところ）は、データベースの設計である。特にリレーショナル・データベース（RDB）上でのアプリ作りに慣れた人には、大きな「発想の転換」が必要なので、ここは注意が必要。 特に絶対にやっては行けないのは、 将来RDB上へ移行できるようにレイヤーを作って、その上にアプリを作る RDB上に作ったアプリをデータモデルを大幅に変更せずにApp Engine上に移植する RDBを前提に設計されたフレームワークをApp Engine上に載せて、その上にアプリを作る など。App En
「RESTful MVC」なアーキテクチャの話
最近、増井君と私でアーキテクチャの話をすることが多いのだが、そんなディスカッションの中で気に入っているのは左の図のようなアーキテクチャ。 もちろん、核となるのはビジネスロジックを含んだModelの部分。そこをしっかりと実装し、内部構造を隠す粒度の荒いインターフェイスを定義し、外から何をされてもデータの整合性が壊れない様にすることは何よりも大切。 そして、そのModel層へのインターフェイスを特定の言語に依存したクラスやAPIではなく、HTTP上でJSON（XMLでもかまわない）をやりとりするだけの RESTfulなWeb Serviceにすることがミソ。こうすることによりにより、どんなに締め切りに負われようが、誰がControllerを実装しようが「ずるができない」ように作っておく（ずる＝本来使うべき外部インターフェイスだけでなく、Model内部に直接アクセスして依存関係を作ってしまう事）
Ruby on Railsの「えせMVC」の弊害
先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC（Model View Controller）がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。 ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの（コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること）を避
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
