Kindle ダイレクト・パブリシングを試してみた
発表された時から一度は試してみなければと考えていた Amazon の Kindle ダイレクト・パブリッシング。出版社を通さずに、誰でも自費出版を自己資金ゼロで出来、かつ、印税も３０％〜７０％という高いのも魅力だ（紙の書物だと、印税は１０％前後）。 そこでまずはメルマガ「週刊 Life is Beautiful」のバックナンバーを電子書籍化して出版してみた。 週刊 Life is Beautiful 創刊号（２０１１年８月分） 週刊 Life is Beautiful Vol.2（２０１１年９月分） 値段はどちらも最低の９９円に設定してあるのでぜひお試しいただきたい。私が原発事故まもない時期に管総理と会って「東電の破綻処理」のお願いをした時の話を連載したのはこの時期だ。また「ブログには書けない／書かない話」のコーナーでは、スクエニによるUIEvolution の買収と、その後のMBOに関す
neu.Node リリースのお知らせ
去年の暮れから準備を進めて来た neu.Node だが、ようやく今日、オープンソース・プロジェクトとして github に公開することができたので報告する。 https://github.com/snakajima/neunode 詳しくは README.md ファイルに書いたが、neu.Node は iOS 上で Node.js の API を使って作った マイクロ・サーバーを走らせる仕組みである。iTunes ストアで配布する iOS アプリに組み込んでも良いし、自分や仲間だけで楽しむ「手作りアプリ」に組み込んでいただいても良い。ライセンスは MIT で、ライセンス料フリーで、非営利・商用、無料・有料の区別なく使える。 neu.Node が目指すのは、新しい形の分散コンピューティングである。「モバイル・デバイスはクライアント、サーバーはウェブ・サービス」という垣根をとっぱらい、全てのモ
google appengine に関してひと言
ここ数日、Twitter上で appengine に関する発言をたくさん目にする。それを見る限り、「注目をされてはいるが、手を出しかねている人が多い」というのが現状だろう。そこで、私からもひと言。 App Engine は純粋なソフトウェア・エンジニアにとっての天国 私自身、色々な開発環境を試して来たが、私のようにプログラミングが大好きで、新しい言語や環境を学ぶのが楽しくて仕方が無いエンジニアにとっては、「App Engineは天国」というのが正直な感想。SQLやRailsのように一見開発効率を良くしてはくれるが、直感的に実行効率とかが把握できない「補助輪付きプログラミング」と違い、App Engine上でのプログラミングは、ちょっと手を抜くとすぐに実行効率の悪さとして跳ね返ってくる「一輪車プログラミング」。 新しい言語を学ぶのが苦ならApp Engineは避けた方が良い 現時点で、Pyt
iPadに最適化したPDFファイルの作り方
iPad向けにPDF/マンガリーダーCloudReadersを発表してから、いままで直に付き合いがなかった出版業界の人たちからちょくちょくコンタクトをいただくようになった。その中で良くある質問の一つが、「iPad向けに最適化したPDFファイルの作り方」。そこで今日は、そのあたりのノウハウをまとめて書いてみる。 まもなく日本でも発売されようとしているiPadは色々な意味で画期的なデバイスだが、あくまで位置づけはモバイル・コンピューターであり、パソコンではない。画面も大きく、CPUも高速になったとは言え、搭載するメモリ（RAM）の量はiPhone 3GSと同じだ。 そのため、メモリがふんだんにあるパソコン用に作ったPDFファイルを読もうとすると、メモリ不足でアプリが落ちたり、極端に遅くなったりしてしまう。アプリを作る側もいろいろと対応はしてはいるが（参照）、やはり快適にiPad上でPDFファル
iPadのインパクト：電子書籍のビジネスモデル
Tech Waveの「iPadに期待する米出版業界、期待すれば裏切り者扱いされる日本の業界【湯川】」という記事を読んでから色々と気になったことがあったので日本における書籍の流通の仕組みについて調べてみた。 とても参考になったのが、少し古いが「書籍の価格構成比をめぐる小考」というブログ記事。流通マージン等に関して、具体的な数字が列挙されているのがうれしい。 紙代：6％ 製版・写植代：12％ 印刷・製本代：7％ 編集コスト：3％ 版元粗利：32％ 著者への印税：10％ 取次マージン：8％ 書店マージン：22％ この数字（特に写植代と取次マージン）がそもそも電子写植・大規模店舗・オンライン店舗・チェーン店の時代に適切かどうか、という話はひとまずおいておいて、電子書籍の時代にどうなるかを考えてみる。 紙代：0％ (不要） 製版・写植代：?％ （はるかに低コスト） 印刷・製本代：0％（不要） 編集コ
iPadのインパクト、私の予想８
iPadの米国でのローンチまで１０日となったわけだが、色々と思うことがあるので書いてみる。 予測１：４月３日のローンチは成功する これは99.9%確実である。この手のデバイスのローンチには、（１）開発者に魅力的なプラットフォームを提供してアプリを作らせ、（２）ブロガーの興味をそそって発売前からせっせとブログエントリーを書かせ、（３）アーリーアダプターの心をくすぐって注文予約させれば良いのだが、まさにその戦略に１００％ハマっている私がここにいる（笑）。 先日のエントリーで書いた様に、開発者としては、iPad用のクラウド本棚付きeBookリーダー「Cloud Readers」をすでにAppleに審査のために提出済みである。ブロガーとしてはこのエントリーも含めてiPadに関しては何度も書いて来ているし、当然アーリーアダプターとしてiPadはオンラインで注文してある。Appleから表彰状をもらいた
共著「Google Chrome OS」出版のお知らせ
先日のセミナーでも少し触れた、「Googleのコモディティ戦略」。インプレスからこのたび出版される「Google Chrome OSー最新技術と戦略を完全ガイド」の「戦略」の部分に共著者の一人として寄稿したのでここで紹介させていただく。 Chrome OSにせよAndroidにせよ、OSをGoogleが無料で提供するには深い意味があるのだから、それをちゃんと理解した上で、自社のデバイスに採用するかしないかを「経営判断」として決めるべき。「他のメーカーも載せはじめたから」とか「自分だけ乗り遅れたくないから」ぐらいな安易な気持ちで始めると、「実際やってみたら得をしたのはGoogleだけ」という結末になりかねないので慎重にすすめるべき。 ２年ほどiPhone向けのアプリを作って来た結果、最近強く思うのは、テレビなどの据え置きがたの家電にアプリをダウンロードして走らせる、という発想自体が根本的に間
予告：iPad向けクラウド本棚付きeBook Readerを無料で配布します
数ヶ月前から、自分専用のiPhone向けComicリーダーを作ってスキャンした本とかマンガを読んでいる私だが、いまいち画面が小さいので、マンガは良いとしても本を読むにはちょっとつらい。そこでiPadには多いに期待している。自分だけで楽しむのももったいないので、iTunesストアから無料で配布するつもりなので期待していただきたい。 ちなみに、ついでにGoogle App Engine上に「クラウド本棚」を作ってそこからいろいろな本をダウンロードできるような仕組みも作ったのだが、今のところ「使い方マニュアル」しか置くものがないのでちょっと困っている。いくつか手持ちの本をスキャンしてはあるが、これを勝手に配布することはもちろんできない。青空文庫の本をPDF化しておいておけば喜んでもらえると思うんだが、読みやすい大きさにレイアウトするには、それなりに手間がかかる。 そこで、みなさんのご協力をあおぎ
HTML5時代の「運営しやすいアーキテクチャ」の話
増井君と二人でPhotoShareというサービスを立ち上げてもう１５ヶ月になるが、いろいろと学んだことがある。その中でもつくづく思うのは、サービスを作り上げる段階よりも、運営のことを考えた設計が大切なこと。つまり、メンテナンスしやすい、テストしやすい、多少のミスをしても大丈夫、こまめなアップデートがしやすい、作業分担がしやすい、などなどである。 そんななかで強く感じるのは、「AJAXを見た目や使いやすさの面だけに利用するだけでなく、『運営しやすいサービス』を作るのに利用できないか」ということである。 私のイメージするアーキテクチャを図にするとこんな感じになる。 まず一番の特徴は、テンプレート等を利用したHTMLのダイナミックな生成をすべてやめて、データ（JSONもしくはXML)だけをダイナミックに生成するようにし、HTMLはスタティック・ファイルをサーバー側に置いておく（上の図で、CSS,
Google App Engine上のベスト・プラクティス、その１: Datastore
Google App Engine上でアプリを作りはじめて約二ヶ月。いろいろと分かって来たこともあるので、自分へのメモも含めてまとめてみる。まずは、Datastoreの話から。 なによりも大切なのはデータベースの設計 あたりまえと言えばあたりまえの話だが、App Engine上でアプリを作る上でもっとも大切なこと（＝頭を使うべきところ）は、データベースの設計である。特にリレーショナル・データベース（RDB）上でのアプリ作りに慣れた人には、大きな「発想の転換」が必要なので、ここは注意が必要。 特に絶対にやっては行けないのは、 将来RDB上へ移行できるようにレイヤーを作って、その上にアプリを作る RDB上に作ったアプリをデータモデルを大幅に変更せずにApp Engine上に移植する RDBを前提に設計されたフレームワークをApp Engine上に載せて、その上にアプリを作る など。App En
無名関数を使った非同期通信のススメ（JavaScript）
ここ最近はブラウザーの上で動く思いっきりRIAなアプリケーションを書いている私。こと通信の部分になると JavaScript での開発効率が、C++/Java/Objective Cなどと比べて格段に高いことをつくづく感じている毎日なので、今日は、そのあたりを少し解説してみようかと思う。 サーバーのAPIにアクセスするプログラムを書く方法は色々とあるが、「サーバー上の特定のURLにHTTPでアクセスして結果をXMLやHTMLやJSONで受け取る」というケースに限定すれば、基本的に３つのパターンに分けられる。 1. 同期通信 result = urlfetch.fetch("http://www.google.com/") if result.status_code == 200: doSomethingWithResult(result.content) その書きやすさのために、実務経験の
Google App Engine入門：実行効率を犠牲にせずに開発効率だけを上げるテクニック
一つ前の富豪プログラミングのエントリーともつながる話だが、Google App Engineは「ちゃんとスケーラビリティを考慮してアプリケーションを作るには何に気をつけなければならないか」を勉強するには絶好の環境だ。そこで今回は、その「ケチな大富豪的なプログラミング」の実践編。 Google App Engine上のアプリをいくつか書いているうちに、必要に迫られて自然発生的にできてきたのが、gdispatchという数十行のコードからなる小さなモジュール（ソースコードはgithubに置いてある）。これをGoogle App Engineに標準で付いて来るwebappと組み合わせてフレームワークとして使っている。 gdispatchを設計する上で重視したのは、 （１）Google App Engine上でのアプリの開発を効率化する上で「明らかにこれがあると開発効率が格段に向上する」というもの以
Cloud Computing考：Amazon ec2とGoogle App Engineの違いを私なりにまとめてみた
Cloud Computing の話が注目されるようになってしばらく経つが、商用での本格応用という意味ではまだまだ未熟な市場である。PhotoShareは去年の７月サービス開始時から Amazon の ec2＋S3 という組み合わせで運営しており、私から見れば当然の選択だったわけだが、あのタイミングで商用サービスへの採用に踏み切った会社も少なかったのか、何件かインタビューの申し込みが来たりして少し驚いている（参照）。 すぐに陳腐化するハードウェアの資産はできるだけ持ちたくないし、自分でデータセンターにラックを借りるなんてことはコスト的に見合わない。かといって、通常のレンタルサーバーは初期費用がばかにならない（今は少しは改善されているのかも知れないが、去年の段階では「それじゃあハードが自分で買えるじゃん」と言わせるぐらいの初期費用を請求する企業がほとんどであった）。それに加えて、どのくらいの
Google App Engine入門：Entity Groupとトランザクション処理
今週に入ってから、ようやく少し本気でGoogle App Engineでプログラムを書き始めている私だが、ようやく Entity Group の使い方が分かって来たので簡単に解説してみる。 Entity Groupとは、一口で言えば「トランザクションを使ったアトミックな読み書きの対象となるEntity（＝データベース上のオブジェクト）の集まり」である。 イメージとしては、まず「一つのハノイの塔を三人で同時に遊んでいる姿」を思い浮かべると分かりやすいかも知れない。全くのルールなしで皆で同時に遊ぼうとすると、腕が交錯してぐちゃぐちゃになってしまう。 そこで、「ある時点でハノイの塔ボード（三つの棒を支えている水平に置かれた板）に触ることが出来る人は常に一人。一度ボードに触った人はすべての円盤をいずれかの棒の位置に置いた状態にしてからしか手を離してはいけない。もし自分がハノイの塔に触りたい時に、す
Google App Engine入門：Datastore上で「ユニーク制限」を実現する方法
Google App Engine のDatastoreには、通常のリレーショナルデータベースと比べた時にいくつかの制限があるが、その一つが「このプロパティの値は常にユニークでなければならない」という指定（ユニーク制限）ができないことである。 Invoice IDのように自動生成するものであれば、アプリケーション側でなんとかすることも簡単だが、メールアドレスやハンドル名など、ユーザーが入力するものになると、ユニークであることをきちんと判定した上でEntityを作ることが必要になる。 もちろん、単純に「有無をチェックして、なければ作る」というプログラムではスレッド間の競合に対応できないので、そこはトランザクションを使ってアトミックに処理をする必要がある。 App Engine上でトランザクションを実現するには、エンティティグループという仕組みを使って行うが、気をつけなければいけないのは、エン
Twitterに140文字以上つぶやきたい時のためのサービス、Tiny Message
Google App Engineでプログラムを書き始めて１週間ほど経つが、ようやくDatastoreの基本が分かってきたので、サービス運営の経験値を積むためにもアプリを一つリリースしてみることにした。 サービス名は、Tiny Message。Tiny URLはTwitterに書くURLを短くしてくれるサービスだが、こちらはTwitterに書くメッセージそのものを短くするサービス。 使い方はいたって簡単。Tiny Messageのホームページ（http://tinymsg.appspot.com/）でメッセージを書き、"make my tweet"というボタンを押すとTwitter投稿用の要約（最初の１００文字）＋URLが表示されるので、それをコピペしてTwitterでつぶやけば良いという仕組みである（メッセージの全文を読みたい人にはURLをクリックしてもらう）。 こんなサービスがチャチャ
Google App Engine入門：フレームワークの選択
Google App Engine向けのアプリを作る際に最初に悩んだのはフレームワークの選択。Google App Engineにはwebappという最低限の機能を持ったフレームワークが付いて来るが、Python使いの人たちの間では、DJangoというフレームワークが広く使われているらしいし。かといって、あまり大きなフレームワークを使うと、パフォーマンスのチューニングとかもしにくくなるし、フレームワークそのもののバグや制限に悩ませられる可能性もある。 そんな中で増井君が見つけてくれてまず試したのが、Junoというフレームワーク。DJangoと比べると遥かに小さく、WebappよりもURLのルーティングのメカニズムとかが充実している。 そこで一旦はアプリをJunoの上で作り始めたのだが、Junoのソースコードを見ているうちにいろいろと気に入らないところが出て来た。不必要にオプションが多いし、
「リニアにスケールするように作れる」からこそのGoogle App Engine
Google App Engineを使った最初の作品 Tiny Message （http://tinymsg.appspot.com）をリリースしてまだ２０時間経っていないが、設計の過程でいろいろと学べたことがある。 その中でも一番収穫として大きいのは、「Google App Engineを使えば、リニアにスケールするサービスを作ることが可能」だということが実感できたこと。 もちろん、Google App Engine上に作ったからと言ってすべてのアプリがリニアにスケールするわけではなし、どんなアプリでもそう作れるわけではない。Entity Groupの構成を間違えればそこがボトルネックになるし、Queryの二重ループなんかを書いたら、すぐにタイムアウトしてしまう。 リニアなスケーラビリティを持つDatastoreの上で作るとは言え、やはりDatastoreの仕組みをちゃんと理解してデー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
