おまぬけ活動日誌

● 昨夜のRPM更新情報

まだできてへんし。 今度のワナは、rpmが.で始まるパスを理解しないことでした。

なんでやねん。下のようなパスならうまくいきます。

というわけで、specrcs2html.rbを変更して、 次の朝4時JSTを楽みにしよう。超弩級アンテナの方は、

1. とりあえず今の機能のspecrcs2html.rbがちゃんと動く
2. specrcs2html.rbからRCS関係の部分を抜きだして、 specファイルだけではなくて、アンテナファイルとかZOO/OBSOLETEのファイルも updateするようにする
3. update後に新版specrcs2html.rbとextract.rbを動かす
4. 最後にtama.rbを動かす

という手順で改造しようかと思います。 なにしろフィードバックが一日一回なので、 namazu_MANdb以上のおそ〜い進行になるかと思いますが ご了承のほどを〜 > anegaさめ、 kazさめ。 それはそうと、いつもあやしい関西弁ですんません。

● 昨夜のHEAD修行

skipstone以外はだいたいできていたのですが、tcpdumpが最後のリンクの時に、

とかいいはります。 /usr/lib/libc.aにはあるのになぁ。

● 個人的tDiary改良項目

• pre内の空行でパラグラフが変らないようにしたい
• タグの閉じ忘れを警告したい

そのうち…。

● 相変わらずバグ報告だけしている

すみません〜。そのうち自分で直せるようにしたいです〜。> famaoさま

● いたずらに過ぎてゆく時間が…

って宇多田ヒカルの曲なんですよね？い〜な〜。 (ShoutCastの放送曲で時々流れるのですが、曲名はわからず。 今度帰れたらCDを探してみよう。

…という話ではなく。 famaoさんはモリモリ開発されている し、きたさんは新幹線の中でソースを読んでおられる し、 こ〜りんさんはBTSの 処理をばしばしやっておられるし、 パッケージはあいかわらずどんどんリリースが上がっていくし。 これは僕もがんばらにゃいかんばい。というわけです。

これから何をするべきかちょっと整理をしておこう。

1. 本職をちゃんとする。もちろん。
2. /a/まわりをちゃんとする。- 一週間くらいあればおちつく？
3. tDiaryの個人的改良 - ぼちぼちと
4. Sourceforge.jpに入れるiiimf-skkのドキュメントをなんとかする。 - Kondaraのドキュメントとの兼ね合いが難しいな。
5. iiimf-skkのCUI版を作ってみる - だんだんアヤシクなってくる。
6. skkreenにする - これはもう夢物語であろうか…。

とりあえず、今度帰国できたら宇多田ヒカルのCDを買ってこよう。

● 毛糸の帽子がいるなぁ…。

● sdf-jp

昨日の日誌のリンク元を眺めていたら、sdf-jpというサイトを発見しました。他にも日本語の方がいらっしゃるんですね。よろしくどうぞです。

● [tDiary] 更新しました

1.5.4です。たださん、リリースおつかれさまでした。第二のβテストもつつがなく進みますように。

独自改造つきTrackBackとツッコミも含めていまのところうまく動いてる様子。

latest.rbはやはりプラグインでやるには複雑すぎるかな？という気になってますです。pluginオブジェクトからTDiaryLatestオブジェクトにさわるのが難しそうなのだ。

● [Chobbit] Apache Wiki

Apache純正Wiki。すべての変更履歴を記録している。Perlのようですが、先を越されてましたね。がーん。

yamk日記より。

● 通勤ちゅうても日曜日だけど。先週ぼちぼちと直していた5年以上前に買った自転車に乗って仕事場に来ました。すごおく快適。なんてったってほどんど下りなのだ。帰りがおもいやられます。それにしても、シマノの変速機は、3年放っておいてほとんど調整の必要がなかった。すごいな。

● 今日の中古車屋さん巡り

そういうわけで自動車がなく、仕事場から町に行くのが大変だったのだけど、友達の自動車に乗っけてもらって昼ごはんに行くついでに中古車屋さんに行ってきました。

2003年の日産Sentra(って日本だとサニーなのかな？)が各色とりそろえて大量に。なんでこんなに沢山?と訊いたらレンタカー屋さんから買ったとのこと。レンタカーあがりの自動車には乗りたくないよねぇ…。

● [tDiary] title_tag.rbを使うようにしました

mputさん作の、HTMLのタイトルにその日のタイトルを追加するプラグイン。これはいいな。やっぱり宣伝って大事だ。

そういえば、この日誌のNamazuのフィルターはHTMLのタイトルに日記のタイトルを入れるようにしてたんだけど、エスケープってどうしてるんだろう？←おい。

● このサイトは発足５周年くらいみたい

英語の作文が進まないので知人のサイトを覗いていたら、そこは９年目を迎えたとのこと。すごいな。このサイトはどうだろう？と思って見てみたら、残っている記録で一番古いものは、99年5月9日の写真のようです。この頃は契約していたISPに作っていたのか仕事場のサーバーに居たのか…。

最初のHTMLは実験室のサーバー(SunOS 4.1.4だよ)で公開していたと思うのだけど、CD-ROMのどれかに残っているだろうか？5インチのMDかも。そうだとしたらもう読めないよなぁ。

● 家に居ると暑いのだそうだ。職場は冷房が効きすぎていてよくわからないよ。ごめん。

● ライブ行きたいなー

インターネットラジオであるアーティストのライブ録音を放送してる。いーなー。ライブ行きたいなー。前行ったのはいつだろう…。

● チームおっさん。

「なんでも作るよ。」より。うむ。失なった分だけの知識と経験が身についてるだろうか…。がんばろー。

● Thunderbirdで右上の検索窓でみつけたメールと同じスレッドのメールを表示する

Thunderbird 1.5.0.2。表示方法を変えると現在選ばれてるメールは表示されたままになるのだけど、スレッド表示の部分のカレットはわけのわからないところに飛ばされちゃう。

仕方がないので検索でみつけたメールを件名でもう一度検索している。

Thunderbird、良くできてると思うのになんだか痒いところに手が届かない感じがしてしまうんだよな。なんでだろう？まあこれについてはGMailも同じ問題をかかえているけど。Muttは検索にかからなかったメールもスレッド表示されるのでこの問題はない。

● SourceForge.netでsubversionに移行しようとする

自分でひっそりやってるプロジェクトのバックアップをやっとrsyncに移行した。

subversionに移行するのは大変そうだなあ、と思っていたら、project summary pageからできるみたいだ。後でやる〜いつ〜(またか

● くっそー。Wordから逃げられない。しかたが無いのでビール飲みながらシゴト←逆効果です。

● [tDiary] この日誌をtdiary-2.3.2とruby-1.9.0にしようとした時のはまりどころ

オトナになったのでデバグは手元のマシンでやることにしました。ついでにruby-1.9.0 (Momonga 5のパッケージ版)でも走らせてみたら、下記のような作業が必要でした。

• index.rbと同じディレクトリのtdiary.confの143行目「ほげほげ日記」がinvalid multibyte charを受ける→#!にオプションをつけて「#!/usr/bin/ruby19 --encoding=utf-8」として解決した
• 「*** glibc detected *** /usr/bin/ruby19: free(): invalid next size (fast): 0x0000000000bdb950 ***」…むむ。

● [Ruby][memo] 最近のrubyを作る

http://svn.ruby-lang.org/repos/ruby/trunkをsvn upして下記の作 業をしたらrevision.hが無いと怒られた。

これでもMakefileはできちゃうのだけれど、 s21g::Hello, world!を参考に、svn infoに表示されるRevisionを使って、下記のような内容のファイルを、 configureのあるディレクトリにrevision.hとして作成した。

make testは下記のように失敗したがきっと既知なのだろう。

make install後のmake test-allの結果は下記。

えーと。yak shavingはここまでにして本筋にもどります。

追記: 10番目のFailureは安易な対処ができそうだったのでご報告しておきました→

● [tDiary] 本日のリンク元もうちょっと強化プラグインがruby-1.8で動かない問題の修正

Yak shavingを何度かして、やっと尻尾をつかまえたと思ったら チケット一覧 を見られなくなっちゃいました。どうしたんだろう。 そろそろ時間切れなのでとりあえずこちらに書いておきます。

手元では、tdairy-2.3.2に下記のパッチを当てると期待通りの動作になって、 ruby-1.8.7-p72とruby-1.9.2dev(trunkのr.23473)でも問題なく動作することを確認しました。

● [run] 最短コース

しばらくさぼってたらActivity classが2から1に下がりましたよ。

34分34秒、脈拍平均132、最大162 BPM。距離4.64 km、ペース 8.1km/h。

皮膚はぼろぼろなのだが途中から毒気が抜けたようにすっきりしてきた。続けて走らないとな。

● 会場WiFiは朝ご飯の奥の方ならつながるのが朝の発見

● [io13] Android Protips 3: Making Apps Work Like Magic

Googleによる録画。 この記事はzundaのメモからの講演内容の再現です、発表内容を網羅しているわけではありませんし、誤りが含まれるかもしれません。 Reto Meterさんの講演は興味深い引用とかアニメとかあって良いような気がする。

年齢を、経過した年数ではなく、トランジスタ数で測ってみる。 (我々はICの上に載る程のトランジスタしか持っていないのだ。) これをムーア齢と読んでみる。 みんな知ってるように*1ムーア齢は22年ごとに2倍になるので、 ムーア齢は実年齢に対して片対数にプロットすると直線になる :D するとRetoさんの年齢はだいたい131,000年*2。 これは 直感的には理解できないくらい ちょっとした年数*3で、 対数で時間を測るのはあんまりみんなのやっていることではない。 わかりやすい例を見てみよう。 例えば私は、電話モデムの音が聞こえるとオンラインになるんだな、 と感じるくらい古い。 対数で測った時間は現在はもっともっと速く進んでいる。 高校に入ったころにはタイプライタはもう無くなっていたし、 携帯電話が登場し始めていたんだ。 テキストメッセージもやりとりできなかったし、 この他にも、今の携帯電話みたいな何もすごいことはできなかったけれど。 パーソナルコミュニケータを使ってたのはUSS Enterpriseに乗ってる人たちだけだった。 さて、これはアプリの開発とどう関係しているのか。

Any siginificantly advanced technlogy is indistinguishable from magic. (Arthur C. Clarke)

不可能の開発。

The only way of discovering the limits of the possible is to venture a little way past it into the impossible. (Arthur C. Clarke)

Is that actually doing anything, or is it jsut a mock? (A. N. Engineer)

他のアプリを眺めながら開発をする時に、 そのアプリが進化しないと仮定するのは間違い。 デバイス数はいつも増え続けている*4。

最良のアプリを全てのユーザーに届けよう。 例えば、Lock screen widgetを使っているアプリはまだそんなに無い。 また、今後は、 Context(Activity recognition＋Locatoin＋Google+アカウント)の利用は 重要なのではなく必須になる。 "Your phone knows you"*5。 Fused Location Providerを使ってください。

Geofenceの利用 - Geofence.builder。 Activity Recognitionの利用 - ActivityRecognitionIntentProvider、 ActivityRecognition.Result→歩いてる、止まってる、自転車、自動車…。 Google+ - mPlusClient.loadPeople()。

アプリケーションの不気味の谷。 (動画 22:40付近) 横軸をアプリが認識しているユーザーのコンテキストの量、 縦軸をアプリの素晴しさとすると、 コンテキストが増えていくに従ってアプリの素晴しさが増えていく (GalleryアプリからGoogle Mapへ)が、 あるところで谷が出現して、 それを越えるともっと素晴しいアプリ(Google Now)になる。 このために、 例えば電子メールアドレスを片方向ハッシュするなど、 ユーザーのデータはそのアプリがやっていることにだけは使いやすくするが、 その他のことには使えないようにする必要がある。

無意識、五感に訴えるアプリ。 scentairのように匂いを提供する企業も無いことはないが、 GoogleはAPIを用意してるわけじゃないけれど。 $5のコーヒーが提供する価値は色付きの水だけではない。 アプリに使えるのは視覚、聴覚、触覚だけではあるけれど、がんばる。 安全な領域に留まらずにリスクを取る。 アプリが何をやっているのか、ユーザーにしっかり知らせる。

Android Design。

視覚。UIのデザイン。

聴覚 (動画 31:50付近から)。Text to speech (TTS) tts.speak(text, TextToSpeech.QUEUE_ADD, null); 例えば、コンテクストを得て、自動車の運転をしている時だけ、 ニュースのヘッドラインを読んでくれる。 ユーザーに対して、自分だけのために特化してくれているという感覚を届ける。 音声認識。 RecognizerIntent.EXTRA_RESULT。 コンテキストを知っていれば、よりうまく認識できる。

触覚。48DP (7 mm)周期のリズム、片側 4DP の不感領域、 下にボタンを置いてナビゲートボタンとタッチミスしちゃうのを避ける。 触った時の色の変化によるフィードバック。

Simple Accessiblity Support。 <Button ... andoird:contentDescription="@string/my_button_description" /> このボタンは何をするのか。

Touch Gestures。10本の指を使ったmagic。

テスト。 Magicを演出するのに古典的な操作方法を変えなくちゃいけないことがある。 それで混乱する人もいる。そんな時に。 デベコンからアルファ版、ベータ版を使ってもらうユーザーの割合を選べるようになった。

統計を取る。デベコンで、アプリにトラッカーを仕込んで。

魔法の種明しをしないこと。 例えば、いつでも表示を最新にしておくようにして、同期ボタンを無くす。 Google Cloud Messaging (GCM)。 サーバからの更新をGCMを通じてアプリに届ける。 クロスデバイスな更新が可能。GoogleCloudMessagin.get(context)。 アプリから更新内容を送る。SyncAdapterの実装 (動画 49:50付近)。AbstractThreadSyncAdaptorをextendして。

● Cognitive Science and Design。部屋に入れなかった。後で見る。

● [io13] Big Data Mashups: Enabling Next Generation Analytics Using BigQuery

Googleによる録画。ShutterflyさんによるBigQueryの使用例。BigQueryとのやりとりはPythonでやっているようだ。周囲の処理も含めてシェルスクリプトからPythonを起動しているのが意外だった。

● [io13] All the Ships in the World: Visualizing Data with Google Cloud and Maps

Googleによる録画。 この記事はzundaのメモからの講演内容の再現です、発表内容を網羅しているわけではありませんし、誤りが含まれるかもしれません。

75,000隻の船の4億点のデータをどう扱うか。

船には現在位置を放送する仕組み (VHFで送信するAIS) がととのっている。 船どうしの衝突を避けるのが最初の目的。 2012年5月から 人工衛星による中継で全世界のデータ(76k隻の40M点)を受けられるようにしたのが、 SpaceQuestなどの会社。 この他、NOAAによる2005年からの9k隻の364M点のデータもある。 先週から Google San FranciscoやSydeneyの開発者も最近受信機を買ってデータを集めはじめて、 現在、それぞれ、171隻の240k点、48隻134k点のデータがある。 これらのデータの可視化。

チャレンジは、データの大きさ、GPSの状態に依存するデータの質、データの重複。

データの保管には、Google Cloud Storageを利用する。 アクセルコントロールが効き、4PBほどまでスケールし、 データセンター内だけで操作をするには非常にレイテンシが小さいのが良い。

AISからのデータはエンコードされているので、まずは、 C++で書いたライブラリでcsvに変換した。 libc++ on Compute Engine。 Bucket APIのBucket Notificationでデータが来たのを知り、 解析のキューに放り込む。

データの提供。Bucket NotificationからGAE経由でBigQueryへ。 BigQuery Rest APIを利用してApp EngineでJava Scriptへ*1。

● [io13] Google Cloud Messaging

Googleによる録画 この記事はzundaのメモからの講演内容の再現です、発表内容を網羅しているわけではありませんし、誤りが含まれるかもしれません。

c2dmと呼ばれていたサービスがGCMになった。メッセージの種類は2種類。 Send to syncはアプリのサーバからhttpsでGCMのサーバにメッセージを送り、 GCMサーバからアプリにメッセージを送り、それを受けて、 アプリがアプリのサーバに接続する。 Send dataでは、ペイロードを含めたメッセージを、 アプリのサーバからGCMサーバ経由でアプリに送る。

APIで下記のような項目を指定できる。詳細はGoogle Cloud Messaging for Android

• Time to live - 一定時間の間にアプリに到達しなければ消える
• Delay while idle - ?
• Multiple senders
• Message multicasting
• その他

[NEW] XMPPエンドポイント。 これまでhttpsでシーケンシャルに送っていた場合、 レイテンシは60msec、スループットは30message/secくらいだった。 XMPP経由では、4000msessage/sec送れる。 Persisitentにする場合、アプリのサーバからGCMサーバにXMPPでメッセージが到達した場合、ACKが返ってくる。 ACKの返ったメッセージの同定のため、 送信時に送信先のRegistration IDだけではなくメッセージIDを指定する。 なお、XMPPで送る場合にはmulticastはない。

[NEW] Upstream messaging*1。 アプリからGCMサーバ経由でアプリのサーバにメッセージを送ることができる。 アプリからGCMサーバまではGoogleによって信頼できる経路がある。

アプリはGoogleCloudMessagingのインスタンスに、 PROJECT_IDを渡してメッセージを送信する。 端末内のGCMフレームワークがメッセージを受け取りローカルに保存してから GCMサーバに送り、到達が確認できたローカルのコピーを消す。 GCMサーバからアプリサーバへの通信も同様。 Time to live もある(0秒から4週間)。0秒の場合はすぐに送る。 接続が無い場合はエラーになる。

電池消費の最適化。 GCMフレームワークはいろいろなアプリの動作を知っているので。

Google Play ServicesはForyo以降の全ての端末で利用可能*2。

User Notigications。 アプリのサーバからGCMサーバへ、ユーザー名等のハッシュを送ると、 GCMサーバはNotification keyを付けて、そのユーザーのすべての端末に Notificationを送る。 どれかの端末でユーザーがNotificationを読むと、 その情報がNotification keyと一緒にGCMサーバに伝わるので、 他の端末のNotificationも消すことができるし、 アプリのサーバにも知らせることができる。

● [io13] High Performance Apps with Go on App Engine

Googleによる録画。 この記事はzundaのメモからの講演内容の再現です、発表内容を網羅しているわけではありませんし、誤りが含まれるかもしれません。

GoはApp Engineでスタートも実行中も最も速いランタイム。 GoはApp Engineではバイナリのネイティブコードとして走る。 App Engineは自動的にスケールしてくれるしメンテナンスの必要も少ないので良いです。

2011年11月のTurkey DoodleはGoで動いていた。 Goの初級者が24時間ほどで完成させたもの。 2012年12月のSanta trackerも。毎秒5000個のクエリに耐えた。

パフォーマンスのボトルネックを見つけるには。 測定を最初から、繰り返すことが大事。 appstatsを利用する。 それはそうとGo 1.1はずいぶんパフォーマンスが良くなりましたよ。

高速化のテクニック。 Defer work。appengine/taskqueueとかappengine/delayを importして、速度のいらない処理をうつす。 例えば、メールを送信する処理。 Batch。Get→ GetMulti、Put→PutMulti。 Cachnig。 データストアはレイテンシ20msecくらいと遅いので、 memcache (1msec)とかローカルなメモリ(1us)とかを使うのが速い。 途中で消える可能性があるのに注意が必要。 Concurrency。 Control Variance。かかる時間に差がある。 "The Tail at Scale", By Jeffrey Dean, Luiz André Barroso Communications of the ACM, Vol. 56 No. 2, Pages 74-80。 これを制御したい*1。 memcacheを非同期にして、ハンドラが通る時にAPI Callがキャンセルされるように。 コンカレントにしてdoneチャンネルに完了を知らせる。タイムアウトありにする。

● [io13] From Nothing to Nirvana in Minutes: Cloud Backend for Your Android Application

Googleによる録画。 この記事はzundaのメモからの講演内容の再現です、発表内容を網羅しているわけではありませんし、誤りが含まれるかもしれません。

Mobile Backend Starter。 https://cloud.google.com/console よりGet startedを辿って、 APIをEnableしてAPI Keyをもらってください。

サンプルのゲストブックを作ってみる。 デバイスの中にMobile backend Server Client Libraryが入る。 アプリはbackendとやりとりをして、 backendはGAEのMobile Backend Starterと通信する。 ゲストブックに書いたメッセージが端末に届く。 アプリが新しいメッセージをもらうのにポーリングを使うのは 電池的にもネットワーク的にも高価。GCMを使う。

GeekSelendipityアプリ (bradabrams/GeekSerendipity-io13、 Geek Serendipity on Google Play)。 登録しているGeekの位置から自分の近くのGeekを探してくれます。 setOnMyLocationChanged()からsendMyLocation()する。 cloudEntityを作って、getCloudBackend().update()すればよい。 このためには、CloudBackendActivityをextendする。

GAEサーバ。対応するAndoridアプリからのみ使えるようにlockdownする。 アプリへの署名を使って同じpublisherであることを確かめる。 Android Client IDをアプリのPackage nameと署名鍵の指紋から作って設定して、 oAuth Client IDをアプリとGAEの両方に設定して、 GAEとアプリと同じユーザーであることを確かめる。

GAEサーバでGeekの場所を探す。 Continuous Queries。 データが来るたびにクエリを発行して結果が返れば、 GCMでアプリに「近くに居るよ」メッセージを送る。 アプリはGAEにqueryGeeks()クエリを発行して、 結果を表示する。

Endpointを足す。 GAE側。Pyhon等で書いてデプロイ。API Explorerから見える。 Android側。Google Play Services for EclipseでGenerate Cloud Endpointすると ライブラリを作ってくれるので、ビルドパスに追加して、 ThreadからAsyncに呼ぶ。 service.logs().log(messae).execute()みたいに。

● [io13] IGNITE

Googleによる録画。去年は部屋に入れなかったのではやめに並びました。整数をらせん状に並べて素数に印をつけるとなんだかパターンがうかびあがる、というのは鳥肌ものだった。

● Pitch nightに参加する

Google I/Oの参加案内に関連行事としてPitch Night! Powered by Startup Weekend and Google Developer Groups Startup Weekend Organizationというのが紹介されていました。たぶん、アイディアを発表して良いものにご褒美がもらえる。ぼっちプログラマとしては勇気を出して参加してきました。バスが行っちゃったので知らない参加者の方々にタクシー相乗りさせてもらったよ。

Google San Franciscoでご飯をいただきながら、アイディアの分野にわかれてそれぞれのアイディアを発表しあい、グループの代表が本戦に出場という順に進んでいきました。いろいろな経歴の人たちと話をできるのは楽しかった。

僕のアイディアはボツになったけれど、いつか自分で実装してみたい。価値があるのはアイディアを実現することだし。

● 宿への帰りは深夜の金融街。怖い地域かと思ったけれどそうでもなかった。元だけあって、Google Mapsのナビゲーションに助けられながらバスで無事に帰投しましたとさ。