ただのにっき

■ ABC2011w (Android Bazaar and Conference 2011 Winter)に行ってきた

6月のABC2010sに続いて、Android Bazaar and Conferenceに行ってきた。前回は東大駒場キャンパスだったけど、今回は本郷、メイン会場は安田講堂である。……と言っても前夜、急な謎の吐き気に襲われて*1、10時間もぶっ通しで寝てしまったので、午前中の基調講演を聞き逃したばかりか、午後から行ってみたら予定していたセッションはすでに満席で入ることもできなかったという。何しに行ったんだオレ。

事前情報で参加申し込みが3,000人(!)というのを聞いていたので、こういう状況は予想できたことではあるが、混雑が苦手な人間にはつらいイベントになってしまったなぁ。まぁそれはそれとして、Androidが盛り上がっていることはたいへん喜ばしい。アメリカでVerizonがiPhoneを売るようになったことからしても、AppleがAndroidに相当危機感を持っていることがわかるわけで*2、やはり対抗馬がしっかりしていないと健全な市場は形成されないからねー。

で、そんなAndroid一色のセッション(同時7トラック!)を尻目に、電子出版のセッションを聴いたりしていたのだが(ホント、何しに行ったんだ。いや、村田真さんがしゃべるというので)。EPUB3.0の話題だったのだけど、縦書き、ルビ、縦中横などの実装は先行してWebkit上で行われていて(ここだけがAndroidとの接点)、現在はほぼ問題なく表示できているとのこと。逆に言えばEPUB 3.0の仕様を満たすにはほぼフルスペックのWebブラウザを作らなくてはいけないわけで、なかなかハードルの高い話だ*3。そんな最新のWebkitがAndroidに取り込まれて各端末に配備されるのはだいぶ先になるはずで、普及までにはしばらくかかりそうだなぁ。

最後は(せっかくなので)安田講堂でシャープの話を聴くなど。主に夏・秋モデルの話だったので新しいことは多くなかったのだけど、「開発用に端末貸し出しはないのか」という質問に「キャリアを通して出荷しているものだから難しい」と回答していたのが印象的だった。そうか、せっかくメーカーが開発者とうまくやっていきたいと思っていても、キャリアが足かせになってるのか。だったらさぁ、「つぎのNexus」をシャープから提供するように画策してみたらいいんじゃねーの、と思った。「Nexus SH」とか。せっかくの国産Android端末、ドメスティックな機能を盛り込むことばかりに注力してないで、世界標準の端末作るという方向はどうよ?

■ 「ひとりぼっちのプログラマ」に読んで欲しい、『 プログラマが知るべき97のこと』

オライリーの高さんから献本いただいた。いつもありがとうございます。

この本はねぇ、「ひとりぼっちのプログラマ」にぜひ読んで欲しいなぁ。

ここでいう「ひとりぼっち」にはふたつの意味があって、ひとつは「ひとりでがんばっているプログラマ」。

Twitterやブログを読んでいると、仕事でいろんなことにチャレンジしたり、業務を改善したりしたいと思っているのに、職場の文化が壁になったり、上司の理解が得られなくて歯がゆい思いをしている若いプログラマの叫びが、それはもう、かなり頻繁に聞こえてくる。10年前ならいざしらず、今ならさっさと転職してしまうのが正しい道だろうけど、そうもいかない事情を抱えている、でも現状をなんとかしたい……そう感じているひとりぼっちのプログラマにとって、本書はいい味方になってくれると思う。というか、モチベーションを失って旧弊な企業文化に飲み込まれるまえに読むべき。

本書にエッセイを寄せている数十人のベテランプログラマたちは、おそらく今は恵まれた環境で仕事をしていると思うけれど、けっこうな人数が若い頃の失敗や挫折についてかなり赤裸々に語っている。そうそう、あちこちに「達人プログラマ」への言及も目立つのも特徴的。彼らとて、Daveら「達人」に憧れて、失敗を繰り返しながら今の地位にのぼりつめ、達人の一人になったんだよね。

我々日本人からすると青々とした芝生に見えていた英語圏のプログラマたちだって、さまざまな壁にひとりぼっちで立ち向かわなければいけなかった時はあるし、それでも「達人プログラマ」を目標に歯を食いしばって努力を続けたから、英語圏を代表する数十人のプログラマの一人としてエッセイを書くまでになれたのだ。

エッセイの内容は「えっ」と思うほど初歩的なことも多い。でも彼らがそこに至るまでには、きっとひとりでがんばっている時期があって、それが血となり肉となっているから、どんなに初歩的な内容であってもここに載る価値を持ったのだ。だから、いま、ひとりぼっちでがんばっているプログラマは、同じ境遇の「仲間」と「目標」を得る意味で本書を手に取るといいんじゃないかなぁと思う。

もうひとつは「孤立したプログラマ」という意味での「ひとりぼっち」。これは自覚しにくいけど、日頃から「自分以外のプログラマはバカばっか」と考えていたり、テスターや上司(ときには顧客まで)を敵だと感じることが多いなら、本書を読むべきだ。

上で書いたような「ひとりでがんばる」ことをやりすぎた結果、職場で孤立してしまう弊害について書かれたエッセイもまた、本書で大きな割合を占めている。というか、純粋に技術的なエッセイを除けばほとんどが「一人で仕事してると思うなよ」という戒めがテーマになっていると言っても過言ではない。それは、プロダクトに関わる他の人々のことであったり、(自分を含む)未来のメンテナのことであったりさまざまだけれど、自分勝手で独りよがりなプログラマはプロではないという意見が、手をかえ品をかえて登場している。

もし自分が職場で孤立していると感じているプログラマがいたら、これもまた一度手にとってなぜいま自分は孤立しているのかを振り返るきっかけにしてみてはどうかと思う。とはいえ、こっちの「ひとりぼっち」は、たいてい自覚症状がないからなぁ。

プログラマが知るべき97のこと
和田 卓人
オライリージャパン
￥2,090

蛇足: ほんとはだいぶ前に読み終えていたんだけど、Amazonの在庫がぜんぜん復活しないのでちょっと待っていたのだ。読みたいと思ってもらえてもその場で買えないんじゃ紹介する意味がないし。まぁ年末年始を跨いでるからしょうがないね……と思っていたが、年があけて一週間待ってもまだ入荷しないし、あんまり時間があくと内容を忘れてしまうので(笑)、しょうがない。リアル店舗では買えるみたいなので。

ホント、こういうのを見ると紙の本なんてとっととなくして、デフォルトで電子書籍になって欲しいと思うよ。まぁ、オライリージャパンのPDFは制限キツくて評判悪いみたいだけど。

■ Kindle3向けdot by dotな自炊PDFを(真面目に)作成する

ePUB 3.0が、縦書きやルビをサポートしてそろそろ仕様確定するそうで、それはそれでめでたいんだけど、各種デバイスがいつサポートするのかもわからんし、出版サイドにノウハウがつくのにも時間がいるだろうし、普及にはしばらくかかるだろう。

いっぽう、大長編「まおゆう」を自作したPDFで読んだり、最近高橋さんが作っているSONY Reader向けの青空文庫PDFをKindleに入れてみた経験からすると、電子書籍は必ずしもリフローできるフォーマットである必要はないんじゃないかとも思い始めている。世に出回っている電子書籍端末は、3～4インチ(スマートフォン)、5～6インチ(KindleやSONY Reader)、10インチ前後(いわゆるタブレット)の3種類。だったらこれらに合わせて最低3種類のPDFを選択可能にしてくれればそれで十分じゃないのか? 字の大きさのバリエーションを2種類作ってもせいぜい6種類。これで大多数の人が使えるなら、ePUBじゃなくてもいいわな。

いずれにせよ、現時点でePUBが読めないKindleがePUB 3.0をサポートするかというと怪しいと思うので、自分にとって自炊本がソースである期間はまだしばらく続きそうだ。

というわけでベストプラクティス宣言後も、シェルスクリプトのRakefile化と並行してチマチマと最適化をしていたりして。なにせ、字がまだ汚いのだ。ちなみに最新のRakefileはGitHubで公開してある。

最近の発見(?)は、pdftoppmが吐き出す画像ファイルのデフォルトの解像度が150dpiだったこと。えーと、たしかおれ、600dpiでスキャンしてたよね? 150dpiつったら、Kindleそのものの解像度より小さいわけで、そんな画像を拡大表示してたら汚くてあたりまえだ……。というわけで「-r 300」をつけて大きめの画像を抽出するようにした(「-r 600」ならなお良いが、300でも十分な解像度である)。

それから、これをトリミングしたあとで、Kindleの画面にぴったりフィットするようにあらかじめリサイズする。けっきょくこれが一番確実なのがわかった。そのために、真っ黒な画像を使ったPDFを作り、Kindle上でどれくらいの大きさに表示されるのかチェック(ググればわかるように他の人も似たようなことをしているけど、みんな微妙に数字が違うので自分だけを信じることにした[笑])。

まず文庫や新書向けの縦持ち(ポートレイト)の場合、560x735がPDFの表示エリア。紙の書籍を画像化した場合は縦がつっかえるので、高さ735に最適化すれば良い。ImageMagicには「-resize x735」を指定する。できたPDFのスクリーンショットがこんな感じ。ちょっとノイズが乗っているけど、実際にKindle上で読んでいれば気づかない程度:

続いて大型の技術書を横持ち(ランドスケープ)で読む場合、722x535が表示エリア。こんどは横だけフィットすれば良いので、ImageMagicのオプション指定は「-resize 722」になる。これで最適化するとこんな感じ:

これならmobiな書籍と比べても遜色の無い美しさだよ。満足だ。長かったけどこれで最適化の旅はたぶんおしまい。あとはファイルサイズ削減のためにもうちょっと圧縮率を上げられないかトライするかも。