色々、方向修正が必要そうだったり、というのもあるけれど、なによりもあの大震災のインパクトは強烈だった。しばらくの間、そして今も継続して、あの震災の影響を抜きに考えられることは殆どありません。

当日の深夜まで復旧しない停電。辛うじてSkypeとtwitter、そして車のワンセグで途切れ途切れに状態が分る程度だった。電気が回復すれば、テレビからはすさまじい津波の映像により衝撃を受ける。テレビから目がそらせない。そして、原発の問題。

計画停電がはじまり、手元で動かしている各種開発サーバーの手当やら、今後どうするのかについて考えなければいけなくなった。とても簡単には解決ができないことばかりで、本当に大変であり、今も継続中。

当然だが、津波の影響をもろに受けた東北沿岸部や、原発からの直接被害を受けた福島県を中心とする人達から比べれば、たいしたことはない。サーバーの移動をはじめとして、自分で出来ることを着実にするしかない、と思っています。しかし、これからの日本のエネルギー事情と、今後絶対に来る東南海地震などを考えると、無防備のままではいけない、と強く感じています。

と、全然、事態が進まないイイワケはこの辺にして…

5月27日の午後、次世代電子出版とWeb 表現技術フォーラム in 東京のストリーミング中継を見ていた。本当だったら朝から見たかったところだが、昼と夜が逆転しており、朝からは耐えられなかったのだ。別にMacじゃみられないなんて! と拗ねた訳ではありません(タブン)。

で、ふと感じた事がいくつかあります。後半は、妄想が広がった感じで、全然表現技術からは乖離してますが。

すでに最低限の組版はできてるんじゃないの?

日本語なのに縦書きができない? とても紙のかわりなんてだめだね。禁則がない? そんなのありえない。ルビも振れないの?ダメでしょ。

こんな議論は常にあったように思います。XMDFなり.bookなり国内のビュワ/フォーマットは、実装可能で優先順位の高いものから実装していったと思います。

なんか、紙と「比べれば」足りないものは沢山のこってるかもしれない。けど紙じゃないし。というのが最近の印象。紙ではできないこともできる余地があったりもする。動画とか音声再生なんかが非常に分りやすい。

できる事が違うのは媒体が違うのだから当たり前のこと。新しく出来ることだけじゃなく、困難になることも当然ある。もう紙を模倣しようとしなくてもいいんじゃないかな。模倣の先に、明るい未来は私には見えない。

質疑応答の中で、編集者の意図した組版を逸脱していいのかという問題提起があったように思うけど、リフロー可能にするなら、もうそういうのはある程度諦めるベキだと思う。返答としてレイアウトを固定にしたいならPDFにすべき、という話がでてた。多分そういうことなんだと思う。

縦書き横書きを切り替えることがT-Timeとかで出来るのは、多分出自なんだよね。

もともと縦書きのコンテンツなんてなくて、横書きのテキストやHTMLをできるだけ見やすいようにして見せてくれるビュワ的な意味あいがあった。だから、縦横を切り替えられたり、いろんな表示オプションが豊富。古くからあるビュワは、そういう出自をもっている。

だけど、時代が変って、最初から縦書き前提でコンテンツが提供されるようになった。今は、縦書きだとか横書きは変更できなくてもいいのかもしれない。

でも、デバイスの表示エリアは千差万別といっていい。だから紙を前提として想定したレイアウトなら、それを維持する意味なんて薄いんじゃないだろうか。

視力の悪い人にとっては、とても大きなフォントサイズにしないと読めないかもしれない。その時、1行xx文字と指定されていたとして、それを優先して読者が読むことに苦労したら、電子書籍のメリットが減じているとは言えないだろうか。著者の強い意向があったとしても、色盲の人に判断がつかない文字色、背景色とかで指定されていたら?

程度の問題というのはあるかもしれない。問題集だったとして、問題が表のページで、解答が次のページに配置されているようなコンテンツは、改ページはやっぱり指定したいだろう。でも、すべてが紙と同じであるのが最適解とはいえないと思う。それが、表示系の実装上の課題だったとしても。

供給サイドにとっての理想

正直、個人的には横書きしかできないなら、それでもいい。ルビが振れないなら、それも許容できる。禁則が実現できなくても、許す。

自分が読みたいコンテンツが提供されてくれさえすれば。それも、自分がどのデバイスで読むかを強制されなければ、ね。

角川さんのBOOK☆WALKER とか頑張っていると思う。角川さんは映像作品やらと関連してラノベとか資産が沢山あるし、そういうのを最大限プロデュースしていきたいんだろうね。

んだけど、レーベルや出版社でショップアプリを組むというのは、やっぱり提供サイドの理想だと思う。

ある出版社の本が欲しい。ある書店で本が買えればどの本でもいい。
そんなことは普通じゃないわけで。

なにか読みたいモノがある。それをドコカで購入する。自分が読みたい環境で読む。
モノが電子書籍。ドコカが書店サイト。読みたい環境がデバイスとビュワ。

紙の本なら、これらの選択はユーザー主導なんだけど、どうも電子書籍の世界だとユーザーは置いてきぼり。

この辺から派生する各種事情が、電子書籍の「売れないスパイラル」の主要因なんじゃないだろうか。

まあ BOOK☆WALKER さんみたいなのは、まだわりと納得できる気はするんだけどさ。あと例えば、 講談社ブルーバックス アプリ みたいなのね。今はないと思うけど。

こういうレーベル的なアプリはショップとしてはアリな気はする。

でも、やっぱり、フォーマットはオープンなものにして、ビュワを固定にしないで欲しいとは思う。

そういう意味ではキンドルは色々と上手い。

キンドルだと、PCを含む色んなデバイスで見れるようにしてくれている。今後デバイスが変っても、同じように見れるのではないか、という期待を持たせる。読書に特化したデバイスも提供されているし。

出版社ではないので、いろんなところの電子書籍をまとめて見れるプラットフォームになっている。

すでに、確固とした紙のオンライン書店としてのベースがあり、ショップサイトとしても一定水準を越えている。

アマゾンが書籍以外にも手を出しはじめたころ、なんか潰れそうみたいな話があった気がする。しかし、今となってはそうそう潰れそうにも見えない、というのも大きい。まあ、分らないけれども。

ここまで出来ていているので、フォーマットが独自でDRMがかけられていても、「あまり」問題視されない。まあ気になる人は気になるとは思うけど。

ここまで、網羅的に推進できるところは、世界にそう多くは存在できないと思う。そういう意味では、アマゾンは一歩抜きんでてる。グーグルも頑張るとは思うけど、グーグルよりはアマゾンのほうが商売上手い気がする…

DRM

DRMがあると、フォーマットがパブリックなEPUBといっても、基本はビュワを制限される。

コンテンツ共有側はオーサリングとかコンテンツの用意では意味があるけど、DRMをかけたら、ユーザーからみてEPUBも独自フォーマットも大差なし。

購入したコンテンツ用のDRMをサポートしたビュワがディスコンになったら、もうコンテンツを見る手段はなくなります。

私は別に本好きじゃない。昔はともかく、今はもうそんなに読む機会もないし。そんな私ですら、毎年何十万円かは書籍を買ってる。月2万買ったらそれだけで24万なわけで、そんな人はごろごろいると思います。

以前、ばっさり故あって捨てたけど、捨てる前は本の為に部屋が1つあった。引越しもトラックが1台余分になったりする訳ですよ。まあこれは小学校の頃から、期間が長く捨てられなかっただけだけれども。電子書籍なら、この部屋が不要になるかと思うと、とても嬉しいだろうと思うわけです。

と、こ、ろ、が! DRMなんてのがかかってると、そういう資産が、他人の事情でゴミになったりするわけですよ。勝手にディスコンになったりしてね。10年もたてば累積数百万とかいう資産な訳です。当然、簡単に捨てたくないわけですよ。自分で捨てるのは、まあいい。でも勝手にゴミになるのは、許せないと思うわけです。また資料的な価値を減じる。

コンテンツを毎回読み捨てするのなら、コンテンツファイルの寿命なんて気にしなくていいのかもしれない。売店で買われて、電車で読まれて、降りたら捨てられる雑誌みたいなもの。こういうものであれば、蓄積する価値が元々ないのだとすれば、DRMが掛っていてもいいのかもしれない。権利者は、自分達が売ってるコンテンツには、保存したくなるような価値なんてないと思っているのかも。大分毒が混じってるけど。

この辺がもうすこしフレンドリにならないと、抵抗が生じます。まあ気にしない人もいるかもしれないけどね。

DRMがあると、本当に広範に影響がでる。

その上、完全に守ることなんて不可能。

人間がプログラムし、プログラムが復号できるデータを、閲覧する権限を有しているにも関わらず、保護することなんてできない。

暗号化は、途中の盗聴などについては機能する。

しかし、解釈系(ビュワ)が購入者の手元にあるのに、これを解析から保護するのはやっぱり難しいように思う。専門家ではないけれども。

DVDのDeCSSなんかそうだけど、一度仕組みが破られると、専門知識がない人もアクセスコントロールを容易に回避できるようになる。

後は法律で制限し、酷い場合は摘発して処罰することになる。結局そうなるなら、アクセスコントロールで不便にしなくても同じじゃないかと思う。DRMをかけなくても、著作権がなくなるわけじゃないのだから。

どうせ無理なら、前向きに対処することはできないんだろうか。例えば、人間、知らないものは、欲することはできません。コピーがそんなに広がるなら、それはある種の宣伝と捉えることもできる。

私も個人的には、youtubeやニコニコで見て、気にいって音楽を購入することはかなり増えた。その前は何年もずっと音楽なんて聞かないし、買わない時期もあったんだけどね。今は月1くらいでアルバムを買ってる気がする。共有サイトがなければ、見ないが、買いもしないだろう。そもそも知ることがない。

大体、紙の本だって、今や出版したらスキャンを止めることはできません。ある種の人は、脳内に記憶して、しゃべっちゃうかもしれない。

そんなに大事にしたいなら、出版なんてだいそれたことは考えず、大事に「誰にも見られないように」金庫にしまっとけ、といいたい。まあ、いいすぎました。

自分は権利者ではないので、強制することはできません。けど、売るということ、世の中にコンテンツを放出するということについて、もうすこし良く考えてみたらどうだろうか、と思うことは良くある。

国内でもオーム社さんやオライリーさんをはじめとして、non DRMの動きがはじまっていて、こういう動きを進めている関係各位には尊敬の念を抱きます。頑張って欲しい。

文芸書なんかも含む、大手出版社がそうなる日は来るのかな…
あと漫画。漫画は、色々と戦争になりそうな気もするけれど。

終りに

「次世代電子出版とWeb 表現技術フォーラム」なので、関連の技術的な問題について、識者が意見を出したりするのがそもそもの目的。そういう意味では何も問題はありませんし、参加者のことを非難するような意図もありません。

ただ日本でも電子書籍の歩みは10年以上あるのに、いつまでも夜明けをくりかえしている気がします。ビューティフルドリーマー的なお約束世界で連環しちゃってるのかな、とふと思ったもので。

日本での電子書籍は、今の延長線上では未来が開けないような気がします。上手く文章を書けないというか、それ以前の考えがまとまってないので散漫なんだけれども…

ある位置の関係者にとっては、これは心地いいくりかえしだったのかもしれません。
海外はともかく、日本は、まだこの先10年くらいは毎年電子書籍の夜明けをくりかえしているかも。10年先にどの程度出版の規模が維持されているのかは、よくわかりませんが。

この震災で、紙やインクの供給が問題になっているようです。本当は電子書籍の導入にはいい切っ掛けになるはず。実際に、震災後、雑誌などのオンラインでの公開実験やら、テレビでもネットでの配信やら、それまでだったらありえそうもないようなことがいくつかあった。残念ながら、それらの試みは概ね終ってしまったけれども。

電子書籍の話を聞いていて良く感じるのは、発言するような人は本当に(紙の)「本」が好きなんだなぁ、ということです。まあ当たりまえかもしれませんが。

でも本好きばっかりだから、とても「本」にこだわる。

購入する人は、そりゃやっぱり同じように本が好きな人は多いけど、供給サイドだったり発言をするような人たちほどの本好きばかりじゃないと思うんだよね。

そういう意味では、最近は若いWeb系の人が乱入してきていたりして、ちょっとだけ嬉しかったりします。

この辺の問題は、もちろん皆判ってるんだけれども、センシティブな問題なんで、なかなか取扱いに困るんでしょうね。何かこの辺を打開する方法はないか、と良く考えます。

最近は、紙の本に対する電子書籍じゃなく、紙の本はもうどうでもよくて、Web的なテキストコンテンツの世界をドライブしていけないか、と思ってるんですけどね。誰か、一緒にこういう妄想を抱く人とか、いませんかね。投げ銭でもいいけどw

色んな所で買った電子書籍やら、自炊した本やら、自分で作成したり誰かからもらった電子データをデバイスを跨いで自在に扱えるような情報インフラアプリが欲しいなぁ。検索とかも色々跨いでできてさ。

現状だと、こういう実験的な試みに興味のある人なんかが、ちょこっと見にきてくれてるような状態です。

それもまあ当然。青空文庫テキストのビュワソフトなら、こういう一覧や検索もできて、それもネットワークに繋がず単体でいけるのだから。出来の悪い再実装みたいなもんです。普通の人には興味なくて当然だよね。

でも、個人的にはもう少しOPDSの可能性を追求してみたい。青空文庫OPDSだけだと色々とパーツがそろっていないので、今後も拡張していく予定です。(OPDSでなくたっていいんだけど、比較的使えそうな技術としてOPDSに出会う機会があったので。)

当面は、まずfeedの品質の向上。

まず動く形が自分でも見たかったので、外字注記の展開やら、feedの品質やらがおざなりなのでこれを少しずつなおしたい。一部はなおってるけど、他と合せて早めにリリース。

対応フォーマットがない時なんかのハンドリングもやらないと。

次に、検索とOpenSearchへの対応。

検索は、最終的にはテキストの地の文も含む全文検索を目標にしています。ここまで踏みこめれば、ある程度の意義がでてくる。この辺は本職でも個人的には踏み込みたい所ではあったんだけれども、コンテンツの権利とか色々あったりして、勝手にやると何かあった時の問題だとか、許可しない権利者とかの対応がでてきちゃってなかなか踏みこむ機会がなかった。この辺 google のつっぱしり具合とかは… ゴホゴホ…

それから使えるいいOPDSクライアントがなかったので、大分出力をビュワに合せている所がある。これらを何とかしたい。

ビュワまでは手が回らないのと、そこまで踏みこむと色々とアレでソレな大人の事情がでてきそうなので、当面はOPDSをハンドリングするOPDSクライアント(モバイルアプリ)の実証アプリを作成中です。

必要な要素技術の検証が大分終ってきて、とりあえずの目標までは作れそうな気がしてきているところ。

あとは、個人的には色んなフィードを混ぜて扱いたいので、OPDSのフィードの種類を少し増やしたいところです。

@kzakza さんがこんな記事を書いています。政府機関や地方の自治体の公開文書のフィードなんかは、たしかにアリセンかもしれません。

OPDSは電子書籍に縛られないと思います。紙の本でもいいし、雑誌の1記事や短編集の一編に対応させたっていいと思います。元々のATOMの考え方からすれば、ある情報(リソース)へのポインタと付随情報を規定し配信する為の規格。

私は本職(?)では電子書籍に関連したことをやっています。電子書籍に関係した企業に外注で関わっています。ショップもビュワもフォーマットも関連業務で扱ったことがある。

ただ、そうした仕事の中で、色々とこうなったほうがいいのに、大人の事情でどうにも出来ないなんてことが沢山ありました。これらを一気に変化させるのは、もう無理だと感じています。というか最近話題なので始めたとかいうのではなく、相当前から少しずつ関わっていて、長期間関係していたので、もうこの方向性にはかなり疲れてしまって…

そもそも、本=書籍というパッケージでなくても、Webを始めとして _テキスト_ コンテンツには日常的に沢山触れています。なので、そういった所から、人が「テキスト」と係るあり方みたいなことを、考えていきたいな、と最近感じています。

そういった方向性で、OPDSが使えたらいいな、つかえるかもしれないな、という妄想の元、作業を始めてみた次第です。

まあ、こういうのは胸に秘め、成功したらかっこよく表明したらいいんだけど、ある程度表明しておかないと、なまけもの体質なので放置しちゃいがちなんだよね。なので、上のも、デキない親父の妄想的な感じではあるんだけど。

こういうのを考えたり実装したりするのは楽しいことなので、これで生活できたらイイんだけどねぇ。

まあ私が道半ばで斃れても、きっと有望な道なら、若い人がよりパワフルにやってくれるよね。

アマゾンからのメールで気がついた。twitterみてなかったよ…

で、青空文庫OPDSのシステムはEC2のUS-WESTに設置してあったんだけど、ついカッとなって、その日の朝までに東京に持ってきてしまいました。テヘッ。

素のOSの状態からシステムのセットアップやDBの設定、動作確認まで2時間強くらいだったでしょうか。あんまり複雑な構成じゃなかったし、コンテンツのサイズも激少だったので。

優秀な人は「こんなこともあろうか」とイメージ作成しておくんでしょうけど、弱小なので… ゴホッゴホッ

おなじクラスのサーバー契約なんですが、やっぱり国内にあるとレイテンシの関係で有利ですね。

pingの戻り：
US-West: 120ms 前後
TOKYO: 18ms 位(1時くらいに計測した時は9-11msくらいだった)

OPDSの出力： ( http://aozora.textlive.net/opds/new/ )
US-WEST: 1.6s 前後
TOKYO: 500ms 前後

結構違います。行って帰りが遠いと、どうしても時間がかかりますね。

自宅からの帯域幅は3.6MB/Secくらいでした。ちょっと想像より遅い。複合的なテストはしていないんですが、結構外との接続は枠がかけてあるか、遅いのかどちらかかも。

以前 EC2のUS-WESTとLinodeのfremontの間で計測した時は、顎が外れるような数字がでたこともあったんでちょっとだけ期待したんだけど、そこまで甘くはなかったというところ。

EC2は金額的はさくらのVPSなんかと比べると高い気はしますが、なんといっても構成の自由度とかインスタンス追加の速さとか、イメージの保存とか、関連するサービスの量と質が国内の会社とは比較になりません。

最近はニフティクラウドとかでAPIが公開されたり、イメージの保存や利用ができるようになったり、段々成長はしてるけど、まだまだ追っ掛けている印象が強い。

これまではどうしてもセンターが海外ということでレスポンスの問題から減点傾向だったけど、大本命がきて、これから国内の他の会社のサービスがどうなっていくのか、興味津々です。

まあ最近のまねきTVなんかの判決を見ていると、国内にサーバーを設置していいのか、そもそも日本に居て大丈夫なのか、という不安は漠然としてあったりなかったり。ダイレクトに影響はないかもしれないが、雰囲気というか、躊躇感がでてしまうのだよね、何か考える時に。

どうも twitter で日頃の鬱憤?は晴れているし、なにか output できるようにと思っても中身がないのでなかなか書くべきものもなし。忙しさにかまけて、気がついたらこんなに時間が経っていた。

ところで、最近青空文庫さんが、書誌CSVの拡張版を公開してくれている。詳細はこちらから。

最近、OPDSを少し調べていたので、この二つを結びつける実験をしてみた。

現状、どのくらい有用か分らないが、とりあえず今動いてるものを公開してみることにする。

OPDSフィードのURLは

http://aozora.textlive.net/opds/

です。

当然?ですが、出力項目の保証はありません。まずどんな風に動くのかの確認を優先したので、出力項目の内容等にはまだ色々と問題が…

現状では手動でCSVのデータを流すコマンドを叩いてるので、データの更新タイミングは不定期です。更新中は、一時的に利用できないこともあります。

ePubダウンロードは佐藤 直樹さんの 青空文庫 (XHTML) -> ePub変換 を利用しています。

PDFダウンロードは高山 恭介さんの 青空キンドル を利用しています。

このOPDSフィードの便利?なところは、御二方の尽力におうところ大です。公開していただいてありがとうございます。

色々スタイルを指定したいとか、御二方のサイトに負荷がかかりにくいようにキャッシュしたいとか、妄想は膨らむんだけれども、現状はストレートにリンクしています。迷惑がかかるようならば、すぐに外すことになると思います。

このOPDSフィードがあると、OPDSフィードを読めるビュワで青空文庫の作品のブラウジングとダウンロードができるようになります。

私がチェックに使ったビュワは、iOSではStanza。AndroidではAldikoです。

具体的にどんな風になるかは、Stanzaで簡単に説明します。

1. Stanzaの「ブックを取得」 > 「共有」を選択、「編集」 > 「ブックソースの追加」をタップ

2. 青空文庫OPDSフィードを登録する

(2011/2/28 注記：追加の画面では「OPDSカタログ」「ウェブページ」があるので、「OPDSカタログ」を選択する必要があります。)

3. 登録した名前でOPDSフィードが表示されている

4. フィードをタップすると、「作品一覧」「作家名一覧」などがでるのでタップで操作

5. 「作品一覧」の「ア」の項目

6. 「ア、秋」を選択

7. 試しに「ePubダウンロード」を選択

一旦Safariを経由して、ePubが見れるビュワが選択できる(但し、ドキュメントタイプの登録がされているアプリケーションのみ)。最後に使ったものが右に表示され、他のビュワを選択するには「次の方法で開く…」を選択するとアプリケーションのリストがでてくる。

縦書きができるePubビュワということでINFO CITYさんのbREADERで開く。

8. ビュワで開いた所

色々と思うところがあって試作してみたのだけど、実際どうなんでしょうね。

これからも、気力の続く範囲で修正や機能追加をぼちぼちしてみようかと思います。

苦情、感想は @gridsurfer までどうぞ。

D02HWはUSBモデムとして使えたので、Mac/Windowsだけではなく、Linuxなどでも接続スクリプトかけば利用可能だった。これが嬉しい。ただ接続したコンピュータでWifiでの無線LAN共有をしないと当然複数デバイスでの利用は出来ない。

Pocket Wifiなら、基本は無線LANで複数デバイスの接続が出来て、必要(USBのほうが速そうとか無線LANが混線しそうな環境など)があればUSBで接続出来る。なにより、問題がなければiPhoneの契約を来年解除してiPod touchのように使えるようになるのかな、と。

iPhoneは、電話としてはDocomoで運用してるので不要。電池があまりにも持たないのとMobile Suicaがないので、iPhone 1台での運用は論外です。1台だけならiPhoneを切る。使い勝手は試さないとわからないけど、無線LANで外出中でもネットが使えれば、SOFTBANKの回線じゃなくてもいいかなと。結構遅い時が多いし。

SOFTBANKには、iPhoneの回線契約を切っても無線LAN経由での利用には問題ないとの確認はしてある。

で、実際ほとんど持ち出しての運用はできていませんが、感想その他を。

D02HWと一番違うのは、Mac/Windowsのドライバを入れるとネットワークデバイスとして認識されること。

セットアップツールは、ブラウザで192.168.1.1へアクセスにいくだけ。基本はドライバ経由で自動的にネットワークに接続をするので、それ以後はブラウザ経由で設定をする。

Linuxの場合は、無線LANで接続すれば、同じように192.168.1.1へアクセスしてログインすれば設定可能でした。

これでどこが変るのかというと、USBを繋いだあと接続(発呼)の手順が不要になるっぽい。接続をオートにしておくと、自動的にネットワーク利用するようにしておけば、接続した状態(=ネットワーク利用可能)になるようです。正確には、無線LANで接続した後、インターネットへの通信があれば自動的に発呼する、なのかな。

手動制御にしたい場合は、マニュアル接続するように設定しておいて、ブラウザ上の管理ページからコネクトすればいい。発呼を制御したい場合は、以前より手間が掛るけど、そうでないなら悪くないような気がします。

通常は無線LANで十分だと思う。この場合は、やはりオートにしておけば、接続がある度必要に応じてコネクトします。ようするにオートにしておけば発呼の制御はユーザーからは不要。途中で切れても、自動的に発呼しなおします。

一度回線が切れた場合、IPアドレスは振りなおされます。なので、常時ポートを繋いでおく必要がある場合(sshなど)は、keepalive設定しとかないとまずそう。マニュアル発呼制御にしておくと時間で接続断しないようにも設定できるようです。

LinuxでUSB経由でPocket Wifiを繋ぐと、

Dec 26 18:01:08 kokoro kernel: [138183.776124] usb 1-3: new high speed USB device using ehci_hcd and address 4
Dec 26 18:01:08 kokoro kernel: [138183.912541] usb 1-3: configuration #1 chosen from 1 choice
Dec 26 18:01:09 kokoro kernel: [138185.092269] Initializing USB Mass Storage driver…
Dec 26 18:01:09 kokoro kernel: [138185.092640] scsi2 : SCSI emulation for USB Mass Storage devices
Dec 26 18:01:09 kokoro kernel: [138185.093162] usbcore: registered new interface driver usb-storage
Dec 26 18:01:09 kokoro kernel: [138185.093174] USB Mass Storage support registered.
Dec 26 18:01:12 kokoro kernel: [138188.047244] usb 1-3: USB disconnect, address 4
Dec 26 18:01:13 kokoro kernel: [138188.832210] usb 1-3: new high speed USB device using ehci_hcd and address 5
Dec 26 18:01:13 kokoro kernel: [138189.000801] usb 1-3: configuration #1 chosen from 1 choice
Dec 26 18:01:13 kokoro kernel: [138189.026477] scsi3 : SCSI emulation for USB Mass Storage devices
Dec 26 18:01:13 kokoro kernel: [138189.041008] usbcore: registered new interface driver usbserial
Dec 26 18:01:13 kokoro kernel: [138189.041056] USB Serial support registered for generic
Dec 26 18:01:13 kokoro kernel: [138189.041176] usbcore: registered new interface driver usbserial_generic
Dec 26 18:01:13 kokoro kernel: [138189.041183] usbserial: USB Serial Driver core
Dec 26 18:01:13 kokoro kernel: [138189.057178] USB Serial support registered for GSM modem (1-port)
Dec 26 18:01:13 kokoro kernel: [138189.057349] option 1-3:1.0: GSM modem (1-port) converter detected
Dec 26 18:01:13 kokoro kernel: [138189.057641] usb 1-3: GSM modem (1-port) converter now attached to ttyUSB0
Dec 26 18:01:13 kokoro kernel: [138189.057693] option 1-3:1.2: GSM modem (1-port) converter detected
Dec 26 18:01:13 kokoro kernel: [138189.057931] usb 1-3: GSM modem (1-port) converter now attached to ttyUSB1
Dec 26 18:01:13 kokoro kernel: [138189.057980] usbcore: registered new interface driver option
Dec 26 18:01:13 kokoro kernel: [138189.057987] option: v0.7.2:USB Driver for GSM modems
Dec 26 18:01:18 kokoro kernel: [138194.032925] scsi 3:0:0:0: CD-ROM            HUAWEI   Mass storage     ffff PQ: 0 ANSI: 2
Dec 26 18:01:18 kokoro kernel: [138194.038787] scsi 3:0:0:1: Direct-Access     HUAWEI   Mass storage     ffff PQ: 0 ANSI: 2
Dec 26 18:01:18 kokoro kernel: [138194.069406] sr0: scsi-1 drive
Dec 26 18:01:18 kokoro kernel: [138194.069422] Uniform CD-ROM driver Revision: 3.20
Dec 26 18:01:18 kokoro kernel: [138194.070092] sr 3:0:0:0: Attached scsi generic sg1 type 5
Dec 26 18:01:18 kokoro kernel: [138194.070704] sd 3:0:0:1: Attached scsi generic sg2 type 0
Dec 26 18:01:18 kokoro kernel: [138194.104039] sd 3:0:0:1: [sdb] Attached SCSI removable disk
Dec 26 18:01:19 kokoro kernel: [138195.661482] cdrom: This disc doesn’t have any tracks I recognize!

こんな感じになります。

MASS storageはHuawaiお得意のDriver diskなんだけど、USB Serialがくっついてる。

ここだけみると、LinuxからもUSBモデムとして使えるのかもしれません。ただ、D02HWの時に使っていたスクリプトでは接続不可でした。

LinuxからUSBモデムとして接続可能になるかどうかはもうちょっと試してみないと判りません。

通信速度はD02HWで繋いでも、1Mbpsなんて夢。大抵は500kbpsいけばいいか、みたいな所、というのがこれまでの現状。対して、D25HWの無線LANだと、1Mbps弱くらいのようなので、すこしUpしたかな、という感じです。都内とかだと違うのかもしれないが、まあこの位でもあるなら十分です。

電池のもちは全然試せていません。ただ、USBから充電しながら無線LANは利用できないようですが、USB給電での稼動は問題ないようなのでPCやKBC-L2からの給電で稼動させて使えそうです。

ちなみにAirMac Express(WPA2+AES)で自宅の無線LANを運用していたんですが、この環境でDell mini9(Ubuntu)だけ定期的に接続が切れる問題が出ていました。

しかし、Pocket Wifi(WPA2+AES)にしたところ、接続は切れません!

てっきりUbuntu側のドライバに問題があると思ってたけど、どうやらAirMac Express(か相性か)に問題がありそうな気配です。これは微妙にありがたい。体調が悪い時ベッドで使うにはMini 9が一番楽なんだけど、無線LANがびしびし切れるのでイライラすることが多かったんだよね。それが思いもしない所で解決しました。

マニュアルの最後にLinuxと同梱のソフトのクレジットがありました。中身はlinuxの模様です。こんなちっこいのに一人前?のルーターです。

LinuxでUSB接続が今の所出来ていませんが、無線LANでの利用が思ったよりも悪くないので、今のところは満足。

と、とりあえず感想でした。

もちっと使うと勘違いに気がついたり、欠点に気がついたりしそうですが、今の所は好印象でほっとしてます。

2009.10.30 – 31 渋谷にて。

http://matsuri.cakephp.jp/

ワークショップとカンファレンス両方参加するつもりで申し込んだが、ワークショップは外せない会議が入ってしまいカンファレンスのみ参加した。

当日のメモをベースにカンファレンスの感想を。当然、理解の間違いやら、好みにより取捨選択ありです。

もっとちゃんと書かないとと思うが、書いてる時間もないしこのままだとCakeMatsuriが終わらないので、自分メモってことで出すことに決定。こんなんだったらもっと早く出しとけばよかった。早くだせば、こんなのでもまだ意味あったような気がするが、今になっては今さらな感は否めない。

CakePHP道

安藤さん、楽天勤務なのか。

フランクな雰囲気を出そうとしてる。

すでに、CakePHPは他のメジャーなフレームワークより露出している。

障壁が低い。ユーザーが多い

CakePHPの哲学
give back much as you take. もらったものだけ返す
オープンソースの哲学と同じ
礼儀正しく

自分の書いたコードをパブリックに公開する。
大事だよね。なかなか出来ない。

外部からの刺激が必要。
コードレビューなど。自分の方法に固執しない。

CoreライブラリのSetが便利らしい

Croogo
CMS。バングラディッシュの人が書いた。結構よく作られているそうだ。
JSONとのコンバートに使うEncodeBihaviorとか便利そう。

外部からインプットとアウトプット両方やらないとだめ。
自分の間違いに気がつかない。

安藤さん。Peggyつかってるな。

事例紹介

地域SNS(あつ さん)

開発は岐阜県らしい。会社の社屋?がでてたが、山小屋？みたいでかっこええ！
こういうの夢だ。いいのぉ。

ドメインがバラバラのサイトの作りかた。
WEB 1台 + DB 1台の構成
Cakeディレクトリは共有。

ドメインがばらばらで、デザインもばらばら。

プログラムの知識がないのに、デザインはそれぞれのオーナーさんが変えられるの？ > プログラムの知識がない人がさわってる。
メインコンテンツの位置などは、文字列を指定して、str_replace()で置き換えてる。
テンプレートへのPHPのプログラムの混入は出来るだけ避けている。

要件定義からはじめて30日程度。
CakePHPで短縮出来た。

アソシエーションで苦労。
やっぱり、直接Model->query()はデフォルトでつかう。
findのパラメーターでjoinsを指定。

スズキ自動車販売のサイト

(syuhariさん)

スズキの中古バイクのサイト構築もやった。
PostgreSQLを使った。ふむぅ。
table 131, view 46。でけぇ。

PostgreSQLでビューを作成して、ビューに対してモデルを作る方法を採用していた。

当時資料がなくて苦労。また携帯対応に苦労した。

できたてのスズキ自動車販売のサイト
スズキ自販サイト(スズキ自販浜松が例に出ていた)

2009.8 – 2009.10
当初は2ヶ月予定で、1ヶ月増やしてもらう。

CMSはWordPress MU
登録、検索をCakePHP

apache 2.2
php 5.3
Mysql 5.0

Cake 1.2利用
GoogleMap, WordPressと通信するコンポーネントを作成

反省点:
MySQLでもビューをモデルに。
携帯ライブラリを使わなかったのは、失敗。

CakePHP部分のメインプログラマは優秀だけど台湾の人だって。今は外国の人と普通にチームなのか！！

CakePHPの感想
コアを直接カスタマイズしてはいけない
開発スピードがはやい
使える人がおおい

使える人がおおくて、デスマーチになったけど、補充が楽だった。

質疑応答
パフォーマンスは問題にならなかったのか？ (コアデベロッパより)
やっぱり、遅いとテスト公開畤にクライアントにいわれた。
しかし、調べたらボトルネックはその時はテスト環境の回線だった。プログラムが遅いとは限らない。

nanapi

(ロケットスタート 和田さん)

生活の知恵を共有するサイト(CGM
PV150万程度(月間)
公開2ヶ月くらい

CentOS 5.3
NetBeansで開発

インフラが専門だった。

便利だけど重い
> 全部CakePHPで作るんではなく、必要な所だけ使う

PHP + Clearsilver(テンプレートエンジン)

clearsilver
google groupなどでつかわれてる。
Cでかかれている

apacheのエイリアスでCakePHPとpurePHPなどの振り分けをしてる。

豪華なシステムは組めない。
データさえ分散できれば、スケールアウトは容易

評価の数字、PVの数字 > TokyoTyrantを使ってキャッシュしてる
(ページ?)キャッシュなど > memcached
HTMLしたデータ、文章データ ファイル
ドキュメントデータ、会員情報など  > MySQL

投稿時のデータをMySQLに入れて、それをHTMLにしてキャッシュ

Lsyncdで指定したディレクトリを監視し、リモートサーバーにファイルを転送

文章分(コンテンツの本質的な部分)を最優先で表示させる(速度が早く見えるように)
それ以外のログイン数などのパーツは、遅くてもいい。
コンテンツ本体のテキストデータはキャッシュしたものを利用

CakePHP: The framework strikes back ～フレームワークの逆襲～

(graham Weldon)

CakePHP 1.2
メンテナンスモード

CakePHP 1.3
JavaScript関係が主
JQueryが標準
templateサポート(bakeで出すときのベースのものみたい)
routingのプリフィックスがadmin以外にも対応
データソースプラグイン
プラグインからデータソースにアクセス可能
複数のデータソースへのアクセスが容易になる
migration guide / http://code.cakephp.org/wiki/1.3/new-features

CakePHP 2.0
PHP4はサポートしない
PHP 5 strict modeのみ
PHP 5.2以降？ not just supporting PHP 5.2/5.3
PHP 6？

DataSourceの扱いがDataMapperみたいになるらしい
検索結果としてObjectそのものがかえされる。
アレイを返すことも可能。

モデルはlazy loading 必要な時のみロード

CakePHP Questions
cakeqs.org
cakeqs.org/register
質問サイト
デベロッパーチームが70%くらい参加している
現状、
クローズドベータ

– QA

cakephp 1.3
templateってなに？
コンソールで利用できるテンプレートが拡張可能という意味らしい

cakephp 2.0
配列が嫌いなのでオブジェクトがかえるのはうれしいが、遅くならないか
配列は値渡しで無駄がおおい。オブジェクトにすれば、参照渡しですむので早い。

contributeはどこにアクセスすればいい
出発点としてはバグリポートが早い

事例紹介2

leebennyさん

おれおれフレームワークからの脱却
CakePHP採用 CodeIgniterもよかった

不動産案件
1.5人月くらい
既存のZendFrameworkからの移植。
管理者側の管理を自前のコンポーネントを実装
ajaxを利用してアップロード (メモリリミット対応)
DBの結果はキャッシュする

DHCのExpressionEngineと連携した案件
稼動12人日
CookieComponent/SessionComponentは強力だった

研究分野でのCakePHPの活用 (飯塚さん)

話が楽しい。いいね、上手い人は。

参考文献管理機能
LaTexによる論文執筆機能
もうかってない。

もうかってないといってるのに、公開するとエンジェルなどから連絡がくる。公開するべし。

ext.jsを使ってる
Ajaxをフルに使うことで、HTMLとPHPを分離できる。
SQLをかかなくてすむ。

Peggyを使っていたが、EclipseのPleiadesに統一
FTPはFireFTP(Firefox)を利用
仕様、コミュニケーションはGoogleDocs、Googleグループ
バージョン管理はsvn、DropBox

請負契約ではなく準委任契約(弁護士と同じ)
お客さんへ
10分1000円
作業者
10分500円

生産性が高いので思ったより稼げない
お客さんの要件決めで時間がかかる

プラグイン活用法

slywalkerさん

有名？なのはDebugKit
説明ではaccount_managerを利用して説明

CakePHPを複数のアプリケーションで使う場合
ROOT/plugins/xxx
bootstrapで個々のアプリケーション用設定をする

プラグインで多言語化
__(…)
ではなく、
__d(…)
を利用

pluginでviewを使う
themed機能が使える

Key-Value Stores & Non-Relational Databases

github.com/jperras

RDBMSはなくならない。
長い実績があり、理論の裏打ちもある。

1、2台のDBサーバーでは無理な大規模サイト用にKVSがある。

可変するschemaという問題
電話はあるがFAXがないとか、電話が複数あるとか。
オプションで使われないfieldが増える。

複雑なmany to many relationship

対策:
load balancer

しかし特効薬ではない。銀の玉ではない。

流行しているからではなく、ベンチマーク/テストしてして実用的なので採用すべき

対抗する技術3種:
KVS/DHT(Distributed hash table)
ドキュメント指向DB
列指向DB

今年のマジックワード:Data sources

CouchDBを使ったもの
github.com/jperras/divan

githun.com/jperras/tyrannical

非リレーショナルなデータソースを設計する時に透明性よりもシンプルを優先

Lightning Talk

新原さん

Exceptionを使ってる!

独自にBehavior, Componentなどをまとめてpluginにしてる。

ko1LoWさん

ERDなどを作ってくれる。githubにある。

akiyanさん

ContainableBehavior
アソシエーションがついてても欲しいモデルだけとれる!!!
unbindModelやbindModelをしなくてもいい。

全体的な印象

Mac率高い！
アルミのユニボディが結構いた。Macのほうが多かったかも?

電源と無線LANは完備。やっぱりこうでないとね。
カンファレンスは70人くらいかな。

PostgreSQL率高い(発表者)。やっぱり国内だからか?

MySQLよりPostgreSQLがいいが、案件で使おうとしたら使えるPostgreSQLが7.4未満で駄目だったんだよなぁ。古いとスキームとる所とかの機能が使えずダメだった記憶がある。

コアでも拡張でもまだまだ使ってない/知らない機能が多い。すぐにでも実戦投入出来そうなものもあった。

知識とかそういう面では参考になることがおおかったが、知らない人と交流するという祭の目的という意味では大減点。

ほとんど話すことも出来ず、パーティーも結局でずに帰宅した。翌日ぶったおれたことを考えると帰宅で正解だったかもしれないが、自分の閉鎖的性格には辟易するな。

追記(2009.11.11)：

もっとまともなレポートはこちら http://cakephp.jp/modules/newbb/viewtopic.php?viewmode=flat&topic_id=2117&forum=16

MacOS Xは、かつて待望した、

1. リーズナブルな価格で購入出来る

2. 表示が綺麗

3. 設定が楽

4. 商用のアプリケーションがある

Unixマシンだ。

商用アプリケーションと設定が楽を除外すれば、今ならUbuntuがかなりイケてるとは思うが、UnuntuはやっぱりLinux。

一歩道を踏みはずすと、そこは深い闇が広がってる。特にドライバまわりとかね。

Dell のMini 9を主にUbuntuで使っているが、ネットワーク系は多分普通の人には手に負えないんじゃないだろうか。今でも、無線LAN(WPA2)は不安定で一定時間で勝手に切れる。メッセージみると、ドライバ周りっぽいが、解決できてない。

こういうところは、アップルは自社で全部まとまってるので、少なくともアップルが提供しているハードについては、基本動作でつまずくことは少ない。これも嬉しい所かな。

だが、Unixとは言え、LinuxやFreeBSDとは違うところも多い。デーモン系のスタートアップとかかなり違うし。

で、Ubuntuが動くなら、今の仕事の内容だったらThinkpadもいいなぁとかなり思ってる。

もともと、赤ポッチの大ファンだし。というか、極最近までタッチパッドが全然だめだったんだ。今は、だいぶ慣れた。タッチパッド、微妙に誤動作するんだよね、体質なのか。あとは、キーと打ってると、パッドに掌が当るようで、うまく動かせないことが多い。MacBook Proだと、そういうことも減ったし、マルチタッチでのスクロールがかなりいいので、赤ポッチ恋しさは結構減ったかもしれない。

ただ、MacBookの時はバッテリーがemobileを付けてると3時間くらいが限度。で、重い。

Dell Mini 9は軽いけど、もっと短い。それに、タイピングはあれでメールとかくらいはいいけど、プログラミングはちょっと…

Thinkpadはキーボードは期待できるし、赤ぽっちあるし、なによりx200sはMacBook Pro 15と同等の解像度を12″で提供してるモデルがあるんだよね。で、かなり触手が動いてた。

ただ、高解像度モデルが、検討期間中ずっとパネルの供給が足りず注文出来ない状態だった。なのでMacBook Pro。

あの時売ってたら、久しぶりのThinkpadでMacのノートさようならぁ〜だった可能性が高いな。

しかし、MacBook Pro 15″はでかくて重い…

で、結構イヤな所があったのでメモ。

まず、MacPortsの環境がかなり変った。

入れかえた当時は全然動かない。MacPortsのベースシステムを再インストールすることで、portコマンドなんかは動くようになったが、もとが32bitだったMacBookからのアップグレードシステムはぼろぼろだった。

結局、観念してMacPortで入れたものは、一旦全部uninstallして入れなおした。これ、結構ビルドの時間とか掛るので、面倒。全部のインストールしたportが使うものでもないので、必要なものから順番に。

ただ、今でも入れたいのに入らないportとかは残ってる。

Exposeの動作が変ったのも気にいらない。

以前は、出来るだけウィンドウが広く見える様に表示してくれたが、今はウィンドウのセンターがきっちりならぶようにでる。いろんなサイズのウィンドウが多数あるような状態だと、以前より視認性がわるい。Exposeする時にDesktopなんか見えても仕方ない。この辺defaultsで変えられそうな気もするが、今の所不明。

そして今一番頭にくるのが、ネットワーク関連の2件。

1つはセキュリティのアプリケーションファイアウォールの動作。

2つめはconfigdがらみ(らしい)。

アプリケーションファイアウォールは、何故かアプリケーションを指定しても上手く反映しない時が多い。portで入れたhttpdだとか、webrickなんかで開いたポートが設定しても上手く開けたり開けなかったりする。Leopardではこんなことはなかったんで、結構頭にくる。設定状態が、またGUIでしか見れない(見方をしらない)んで、さらに頭にくる。

configdのほうは、DHCPから配られたdomain/DNSをいつのまにか使わなくなるってもの。オフィスの環境は、外部から隔絶されたDNSサーバーやらDHCPサーバーがあって、ローカルなテストサーバーなどへのipを配ったりしている。

また、ちょっと普通じゃないと思うが、持ち出す関係上MacBookにマスターのファイル(プログラムやドキュメント)があることが多く、それをオフィスで使う時はiMacからネットワーク共有でマウントして編集することが多い。

因みに、synergyでMacBook ProとiMacを繋げているので、オフィスではMacBook ProはServerみたいに、キーボードも画面もぜんぜん利用されてない。

で、この環境下で勝手に接続が切られることが多発する。

ファイル共有自体は切れないっぽいが、どちらかで動かしているWebアプリケーションに反対側からアクセスできなくなったりする。全然外部のネットワークには名前の解決もできて、繋るんだけど、sshとか届かなくなったりするんだ。

よくしらべてみると、新しいターミナルウィンドウを開くとドメインがlocalに変わってる。ログを見るとconfigdが何かのタイミングで切りかえるっぽいんだ。そうなると、接続出来なくなる。

これ、本当に迷惑なんだよなぁ、なんとかしてほしい。

一応、ネットワーク環境の場所を選びなおすと、元にもどる。でもFinderで開いてるネットワークドライブのパスがリセットされてしまう…

Snow Leopard、結構評価低いです。

CPUパフォーマンス的には許容範囲だったが、メモリが2GBまでというのがいただけなかった。4GBまで使えればよかったんだけどね。

先月、調子が良くないのを騙し騙しつかっていたが、ついに観念してMacBook Pro 15″ 2.66GHzに買い替えた。いわゆる竹とかいう真ん中の奴ね。AppleCare切れてたし。

13″とかなり迷った。というか、買ってから暫くは後悔した。やっぱり、自分の使い方だと、13″がベストに感じたし、今でもそう思う。

普段は15″にしても、lid closedで24″モニターにつなげてディスプレイは使ってない。

持ち運ぶ時は、やっぱり13″のほうが軽いしカバンなんかもデカくならなくて使いやすい。

こうやって考えると、15″は好みじゃないんだな、と新ためて思う。

ただ、持ち出して使う時、やっぱり15″あると画面が広くて楽に感じることもある。まあメリットはこのくらいかな。

なぜ13を選ばなかったかというと、13だと外部GPUが選択出来ないから。こういう選択肢の狭めかたが、本当にAppleはイヤだ。

MacBookの時、Intelの内蔵GPUは遅くて結構いやだったんだ。1920 x 1200のモニターを、仮想スクリーンを9枚作って使ってる。この中にウィンドウが2, 30枚開くのがザラ。この状態でMacBookでExposeすると、メモリがキツい時は特に動作が止る。そしてFirefoxなんか、超メモリを食うので2GBとかだとページアウトしまくりだった。

同じように使ってるiMacは24″で1920 x 1200とさらに外部モニターも1920 x 1200でこれも仮想スクリーンを9枚。同じようにExposeしても、4GBと外部GPUなので結構軽快だった。

この対比が頭にこびりついていたので、どうしても内蔵GPUには不安があったので、最も安価な外部GPUのMacBook系列ということで選択したのが15″ 竹。

でも、実際つかってると、これが内蔵GPUでぜんぜん問題ないんだよね。これが。

勿論、これからはGPUを使う方向が打ちだされているので、今後はわからない。しかし、今は内蔵でも全然困らない。この辺がまた13でよかったのに…という気持になってしまう要因。

まあ、交換できるわけでもなし、ノングレアにしたのでこれも13にはないし、喫茶店などに持ち出した時は、微妙に広い解像度が結構いいかんじなのでいいんだけどね、と思うことにしてます。

やっぱり、13がよさそうだけど;)

裏方で設定したりするだけじゃなく、少しずつoutputするような方向で考えようと思い改め初投稿なり。