iPadアプリ開発日誌： neu.Notes 1.3 リリース
８月３日付けで「AppBankの2010上半期ベストiPadアプリのまとめ。超厳選した２０個！」が発表されたが、CloudReaders と neu.Notes の両方が入っており、開発者としては正直うれしい。アプリを使っていただいているユーザーの方々にもAppBankの人にも感謝の気持ちでいっぱいである。 アプリの平均起動回数がわずか１.5回という短命なiPhone/iPad向けアプリの中で、「長期間にわたって使ってもらえるアプリ」を作るには、やはり「本・マンガを読む」「手書きメモを取る」などのごく基本的なシナリオを押さえたアプリを、必要最低限の機能は提供しながらも、初心者でも使える様にシンプルに、かつサクサク動く様に作るしかない、という発想で作ったのがこの二つのアプリである。 他にも作りたいアプリはたくさんあるし、既にリリースしたアプリのアップデートもしなければならないし、CloudR
iPadアプリ作成日記: アプリ間の連携について一考察
CloudReadersというPDF/マンガリーダーを個人で、neu.Notesという手書きノートアプリをneu.Pen LLCを通して開発・リリースしている私だが、当然のようにその二つを組み合わせて「PDFの赤入れアプリ」を作って欲しいというユーザーからのリクエストは聞こえて来るし、私自身も欲しい。 これまで二つのプロトタイプを作っては見たのだが、どうも気に入らないのでリリースは見合わせている。 最初に作ったのは、CloudReadersに "Annotation Mode" (赤入れモード)を追加したバージョン。とりあえず赤入れが出来るところまでは三日ぐらいであっさりと動いたのだが、「シンプルでサクサク読める」ことを最優先に設計されているCloudReadersの場合、追加した書込みを常に表示するのかしないのかでかなりパフォーマンスに影響が出るし、「赤入れモード」という明示的なモードを
「なぜAppleはiPadにFlashを載せるべきではない」のか
気がついた人も多いと思うが、iPadのアナウンスメントであっさりと無視されたのがAdobeのFlash。私は意図的（＝「Flashなんか重要じゃない」というメッセージ）と読んだが、皆さんはどうだろうか。 iPhoneがFlashをサポートしていないことに対するAdobeを含めたさまざまな方面からの批判を考えれば、「the best way to experience the web （最高のウェブ環境）」を売り文句のiPadが、これだけ広く使われているFlashをサポートしないというのはおかしな話だ。 不思議に思う人も多いかもしれないが、自分をAppleの経営陣の立場に置いて良く考えてみれば答えは明確になる。 Appleという会社は、昔からさまざまなクリエーターたち（アーティスト、ミュージシャン、ウェブ・デザイナー、etc.）を魅力的で便利なパソコンやツールで味方につけ、彼らの作品を消費者
GoogleはなぜAndroidやChrome OSを無料で配布するのか？
先週「Androidと家電」というタイトルで講演をさせていただいた私だが、そのプレゼンのキーポイントは、「なぜGoogleはAndroidを無料で配布するのか？」。それを私なりに説明するための資料として作ったスライドが以下の二枚。 まずこれは、MicrosoftとIntelがパソコン・ビジネスを育てるためにした「コモディティ戦略」を図式化したもの。IntelとMicrosoftで協力してCPUとOSを部品化・規格化することにより、誰でもパソコンを作れる様にしたのがそれ。これにより、パソコン・ビジネスへの参入障壁が減り、パソコン・メーカーが乱立。差別化がしにくい部分（つまりIntelとMicrosoftがほぼ独占的に提供するCPUとOS以外の部分）で激しいコスト競争が起こり、パソコンのコモディティ化が一気に進んだのは皆さんの記憶にも新しいはず。 特筆すべきなのは、MicrosoftもInte
モバイルブラウザーのデファクトスタンダードになりつつあるWebkit
最近、なぜかいろいろなところでHTML5やら モバイル端末向けのブラウザーの話をすることが多いのだが、今年になってトレンドとしてはっきりと見えてきたのは、WebKitがモバイル端末のブラウザーのデファクト・スタンダードになりつつあるということ。 私自身、最初にAppleがブラウザーを作ると聞いた時には「なんでそんな大変なことを今更？片手間でできる仕事じゃないぞ」と思ったりしたわけだが、その予想に反してAppleが見せた本気度とリーダーシップには本当に関心してしまった。 世の中にすでに何百万とあるサイトとコンパチビリティを保つというだけでも大変な作業なのに（経験者語る）、CANVASやCSS Transform/Transitionなどの新しいコンセプトを次々に導入してHTML5の標準化でリーダーシップを取っている点は注目に値する。 「スタンダードを決める」立場に自分を置く事がどのくらい重要
O/Rマッピング技術の進化が皮肉にも助長している「えせMVC症候群」
昨日の「Ruby on Railsの『えせMVC』の弊害」というエントリー。若干「釣り」の要素が含まれたタイトルが功を奏したのか、たくさんのフィードバックがいただけた。そんな中で見えて来たのは、この問題はRailsに限った話ではなく、業務用アプリケーションで使われているJavaや.Netの世界でもよく見られる問題だということ。 その「問題」とは、ActiveRecordに代表されるO/Rマッピングの技術の進化が、本来のMVC（そしてオブジェクト指向そのもの）のメリットを無視した「えせMVC」な設計を助長している、という問題である。 ・MVCやオブジェクト指向を表面的にしか理解していないエンジニアが増えている（ここが根本的な問題） ↓ ・SQLを自分で記述しなくて良いO/Rマッピングはとても魅力的（これはこれで別の問題を含んでいるが、このエントリーではあえて突っ込まない） ↓ ・O/Rマッピ
Ruby on Railsの「えせMVC」の弊害
先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC（Model View Controller）がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。 ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの（コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること）を避
Google WaveがHTML5ブラウザーへのシフトを加速する
Internet Explorer 3.0/4.0 の開発に関わっていた人間として言うのも変な話だが、そろそろIEには主役の座を降りてもらった方が良いと思っている。いろいろな要因がからみあって今の状況があるわけで、その部分について今さらここであれこれ言うつもりはないが、実際のところ、 IEが他のブラウザー（Safari/Firefox/Chrome/Opera)と比べてHTML5やCSS3のサポートに関して大きく遅れている そもそもIEの進化のスピードが（というかMicrosoftから出る製品すべての進化のスピードが）遅すぎる にもかかわらずIEのシェアが大きいため、業界全体の足を引っ張っている という現状があることは誰にも否定できない。 HTML5やCSS3の新しい機能により可能になる新しいウェブアプリをどんどんと作って行きたいと考えているエンジニアは私だけではないわけで、その意味では「
「Flash vs. HTML5」という構図がはっきりと見え始めたぞ、と
業界関係者（特にスマートフォン関係の仕事をしている人たち）少し前からすでに気がついていた話だが、今回のAdobeからの一連のアナウンスメントで明らかになってきた「HTML5対Flash」という構図。とてもワクワクする戦いだ。 ウェブ上のリッチコンテンツという分野でリーダーシップ・ポジションを取りながらも、「無料Flashゲーム」と「ウェブサイトの見栄えをちょっと良くするアイ・キャンディ」というニッチなポジションに一度は追いやられるように見えたFlash（数年前の話）。しかし、動画フォーマットがReal Networks、Microsoft、Appleの三強いの間で中に浮く隙間を付いた戦略で、見事に「ウェブ上のマルチメディアのデファクト・スタンダード」のポジションをがっちりつかんだかに見えるFlash（現在）。しかし、その地位も安泰ではない。 Adobeにとって一番頭の痛い問題はiPhone
GoogleのAndroid向けのアプリビジネスはなぜ魅力的ではないか？
PhotoShareをiPhone向けに提供して早くも一年になるが、もっとも良く投げかけられる質問は「PhotoShareはAndroidとかの他のプラットフォームに移植しないの？」というものだ。 少し前までは、「まだiPhone以外のビジネスが十分に大きくないから今はまだ早い」、「iPhone上でやるべきことはまだ沢山あるから」、などと答えて来たのだが、最近は少し見方が変わってきた。 今の勢いでHTML5が進化・浸透してくれるのであれば、わざわざ移植コストをかけてAndroidやWindows Mobile向けにネーティブ・アプリを開発するよりは、少なくともUIの部分をすべてHTML+Javascriptにまかせたアーキテクチャでのインタラクティブなアプリの開発というのも十分に可能性があるように思えてきたのだ。 この「HTML+Javascriptですべて出来るじゃん」という発想は、そも
PhotoShare の Atom/JSON/JSONP Feed の正式発表
PhotoShareの写真のFeedに関しては、少し前に実装が完了していたのだが、「サンプルをきちんと整えてから」などと考えているといつまでたっても発表できないので、とりあえずFeedのURLのみ発表してしまうことにした。 PhotoShareの場合、ユーザーごとにユニークなIDが当てはめられている。iPhone上のPhotoShareからメアドを登録後に通常のブラウザーからログインして、"My Photo"を開いた時にURLバーに表示されるURLの最後の部分がそれだ。例えば私の場合、それが"http://www.bcphotoshare.com/photos/67"なので、"67"がユーザーIDとなる。
iPhone OS 3.0 に関してひと言
米国のPR会社に勤める知り合いに「iPhoneの新しいOSに関してひと言」というテーマでインタビューを受けた。要約するとこんな感じ。 私：Big Canvasのビジネスにとって一番プラスになるのは間違いなくPush Notification。昨年の９月にリリースされるはずだったので、その時から首を長くして待っていた。PhotoShareのようなコミュニケーション型のサービスにとって、Push型で情報を届けることは、携帯電話にふさわしいおもてなしを提供するという意味でも必須。3.0向けのSDKを入手し、開発をしているところだ。 私：私は常日頃から「AppleはGoogleやMicrosoftの１８〜２４ヶ月先を走っている」と言っているが、今回のアップデートで、Appleは業界のリーダーシップのポジションをまだしばらくは走り続けることを明確にした。Big Canvasのようなベンチャー企業にと
Life is beautiful: Ajaxの本質、「非同期メッセージ型ウェブ・アプリケーション」のススメ
最近、「これからのウェブ・アプリケーションはAjaxだ」という声を良く聞く。ソフトウェアを生業としているエンジニアとしては、この手の「流行もの（hype）」に触れた時には、表面的なものに踊らされずに、その本質を自分なりにしっかりと捕らえて消化・吸収して自分のものにしなければいけない。今までも、「オブジェクト指向」、「マルチ・ティアー・アーキテクチャー」、などの言葉が一人歩きするたびに、「これからは○○だ」とか「○○の時代は終わった」などと、過激なことを言って読者の目を引こうとだけするマスコミや企業のマーケティング戦略に数多くの人が踊らされてきた。 そんなノイズだらけのメッセージに混乱させられた結果、「Ｃではオブジェクト指向のプログラミングは出来ない」と信じているエンジニアがいまだに沢山いることは全く嘆かわしいことだ。「オブジェクト指向のプログラミング」は、設計姿勢・プログラミングスタイルに
「戦略的OS」の開発がことごとく失敗している点に関する一考察
９０年代にIBM、Microsoft、Apple各社が巨額の開発費を投じて作っていた「戦略的OS」がすべて失敗してしまったことを皆さんはご存知だろうか？ IBMが作っていたのはOS/2。元々はMicrosoftとの共同開発だったが、途中で仲違いをしてしまい、最後はIBMだけが細々とサポートしていたことすら覚えていない人が多いとは思うが、Windows95の成功であっというまに市場から消えてしまったのがOS/2。具体的な数値は公開されていないので分からないが、両社が数百人体制で数年間開発していたので、少なく見積もっても日本円で数百億円は投じられたことは間違いない。 Cairoの方は私自身が初期のころにいたこともあるし、最終的には「Chicago(Windows95のプロジェクト名) vs. Cairo」の戦いの最前線にいた私としては知りすぎている点も多いのだが、一つだけ確かなのは、プロジェク
マーケティングともの作りの話
「マーケティング」という言葉を聞くと「商品に関する情報を顧客に向けて発信する」だけと考える人が多いが、マーケティング部門の役割として同時に重要なのは、顧客のニーズをきちんと探り出して「何を作るべきか」という部分に反映させること。 ちょうど今読んでいるHarard Buisness Reviewにとても良い例が出ていたのでその紹介。 米国のペンキ会社が、競争相手に安売り競争を仕掛けてられ、「利益を削ってでもマーケットシェアを維持すべきか」という厳しい選択に迫られていた。その時にその会社のマーケティング部門が調べ出したのが、主な顧客である塗装業者が何にお金を使っているかというデータ。 そのデータによると、ペンキそのものは経費の１５％にすぎず、大半は人件費だという。それも、ほとんどのケースで、一度塗ったペンキを十分に乾かすために、次の日にもう一度現場に足を運んで二度塗りをしているためによけいな人
マルチスレッド・プログラミングの落とし穴、その２
ずいぶん前に、「マルチスレッド・プログラミングの落とし穴、その１（かもしれない）」というエントリーを書いたが、今回はPhotoShareサーバーを運営していて、まさにこのあたりの深い考察が必要になって来たので、良い機会なので続編エントリー。 PhotoShareのバックエンドのようにCRUD（Create/Read/Update/Delete）のAPIをサポートするバックエンドを作る場合、Create/Update/Deleteのリクエストに対してはクライアントからのAPIコール時にすぐに（HTTP Requestに返事をする前に）データベースに変更を加え、Readの際にも（キャッシュを使う・使わないを別にして）データベースの最新の状況を反映するデータを返すように設計するのが普通である。 このアーキテクチャの問題は、ユーザーのアクティビティが増えた時に、データベースやI/Oがボトルネックと
なぜ「iPhoneキラー」がことごとく失敗するのか
MBAの授業の一環で、"Marketing Myopia" (by Theodor Levitt) という１９６０年に書かれた論文を読む機会があったのだが、色々とうなずけるところがあったので、メモ代わりに。 家電メーカーのような技術系の会社は、どうしても技術系の人が経営者になりがち。技術系の人は（私も含めてだが）色々な問題を論理的に解決しようとする。技術的な問題を解決するためにはこのアプローチはとても有効だが、消費者心理のように曖昧で非論理的なものには適用できない。 技術系の経営者が陥りやすい失敗は、自分がコントロールできる分野、すなわち、技術的に難しい問題を解決することにばかりエネルギーをそそぎ、非論理的で簡単にはコントロールできない消費者の動向のようなものに十分な注意を払わないこと。 その結果、「消費者はどのみち論理的な行動なんてしないんだから、それに関して色々と戦略を立てたところで無
WSJからiPhoneに関して取材を受けた
Wall Street Journalの記者からiPhone向けのアプリの開発に関しての取材を受けた。来週のWWDCに向けた下準備らしく、全文がWSJに乗ることはまずないので、私なりにインタビュー記事を起こしてみた。 WSJ：なぜiPhone向けのアプリを作っているのか？ 私：OS+開発環境という意味で他のモバイルプラットフォームより圧倒的に優れているから。私は、Windows Mobile、BREW、Symbian、J2ME/MIDP、J2ME/DojaなどのさまざまなモバイルOS/VMの開発に関わって来たが、iPhoneの開発環境ほど開発効率の良いプラットフォームに出会ったことはない。 WSJ：開発環境に関してはMicrosoftがマーケットのリーダーだと思っていたが 私：Visual Studioはすばらしい開発環境だが、モバイルに限って話で言えば、Xcode上でiPhoneアプリを
プラットフォームを選ぶということ
この業界で仕事をしていると、しばしば迫られるのが「どのプラットフォームに向けて商品開発をして行くのか」という決断。会社としての経営判断の場合もあれば、個人のスキルアップやキャリアパスのための判断の場合もあるが、いずれにしろ限られたリソース・時間をいかに有効に使うか、という点ではとても大切。 パソコン用のソフトウェアであれば、「Windows向けに作るのかMac向けに作るのか」というOSレベルでの選択肢もあるし、「Windows Vista独自の機能を使って差別化を図るのか、それともWindows XPでもちゃんと動くように作ってまずは大きな市場をとりに行くのか」というOSのバージョンレベルでの選択肢もある。もちろん「そもそも特定のOS向けのアプリを作るべきか、それとも、すべてウェブ・アプリケーションとして作るか」というアーキテクチャ・レベルでの選択肢もある。 「少なくともここ数ヶ月はiPh
スティーブ・ジョブズが一度アップルを追い出されてNeXTを作ったからこそ存在するiPhone OS
ここのところブログの更新がさっぱりなのは、iPhone向けのアプリの開発で大忙しだから。４月１５日にApple Desng Awardの件がアナウンスされてから二週間、ようやくAward向けのアプリも形になって来たので一息つける。締め切りの５月１２日まではまだ少し余裕があるが、締め切り寸前にプログラムを変更するのが大嫌いな性分の私はこのくらいの段階で「今日出そうと思えば出せる」ぐらいのクオリティに仕上げておかないと気が済まないのだ。後は徹底的なテストと、見た目の微調整。「ベータ版」としては十分のできだ。 iPhone SDKもbeta4になり、ようやくチューニング用のinstrumentsも安定して動き始めたので、今日はメモリー・リークの徹底的なチェック。非同期通信だらけなのと、Objective-C覚えたての時に書いたコードが混ざっているため、予想通りリークだらけだったが、このツールのお
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
