おまぬけ活動日誌

● 昨日のHEAD修行

skipstone以外は平和にできました。すごい。しかし、カーネルを入れかえたのにブートセクタをOS Loaderに知らせるのを忘れて危うく起動できなくなりそうになりました。コワー。

とりあえずは古いカーネルで起動(モジュールもなーんも消しちゃっててコンソールでしか使えない。)/usr/lib以下のディレクトリをシンボリックリンクにして古いカーネルからも見えるようにしてdepmod(unresolved symbolが続々)、新しいカーネルを/etc/lilo.confに登録、liloしてブートセクタをOS Loaderに。再起動したら今度は新しいカーネルで起動できました。

● 今朝のRPM更新情報

やっとうまくできた模様。次はcheckout部分をまずは~zunda以下で試してみよう。

● sourceforge.jpのBTS

あいかわらず口ばかりで手を出せないでいるのですが…。一行72文字で整形した文章を投稿したら、もう少し少ないカラム幅で整形された上に、漢字の2バイトの途中で切られてるし。見にくくなってすみません。

● さっきのRPM更新情報

アンテナファイルもcoするようにしたのですが、一つしかできていない。 specfile/タグ名/パッケージ名.specというディレクトリ構造にしていたので、 どのパッケージもspecfile/タグ名/Antennaにcoしていたという…。

今度の休憩の時にはディレクトリをもう一段掘るように→自分。

● iiimf-skk-0.1.20.7

Sourceforge.jpにご報告した不具合が手元でしか再現しないという…。 もしやと思って、ダウンロードできるtar ballではなくて、 cvsでIIIMF_SKK_0_1_20_7でソースをいただいて来たのですが、結果は同じでした。 (というか、やっぱりちゃんとこのタグのついたソースがリリースされてると、 確認しただけでした。) なぜに手元だけ〜。すみません〜。

● 近くの飛行場で複葉機がとびまわる

ドイツ博物館の開館100周年とライト兄弟の動力飛行100周年で、ドイツ博物館の飛行機の分館で記念行事がありました。

入場料大人10ユーロ(感覚的には2000円くらい)はなかなか高いけど、ミュンヘン中から飛行機好きが集まってる感じ。娘はお祭りの雰囲気をとにかく満喫しておりました。デモ飛行はパラシュートの人が降りてくるのから始まって、いろいろクラシックな飛行機が飛んでいきました。複葉機がぶーん、と飛んでいったり。のどかでいいのう。

家に帰ってからも学校の校庭越しに飛んでいる飛行機が見えたり。宙返りをしているのはなかなかの迫力でした。デモ飛行を見るだけなら入場料ははらわずにちょっと遠くから見たほうが楽しめた。

● [memo][book] The Unix-Haters Handbook

「Unix. The World's First Computer Virus」だそうだ。読んでみたーい♪今日のなんでやねんより。

● [bitchannel] edit時にformだけにスクロールバーを出したい

手元の環境ではrows="20"ではtextareaが縦長になりすぎて、bodyにもスクロールバーが出てしまいます。編集するのに両方のスクロールバーをいじらないといけないし、saveとかpreviewを押すのにもbody側のスクロールバーをいじるのが必須になってしまう。

cssででもtextareaの高さを、「他のものを配置した残り」みたいに定義できればいいのだろうけど、

みたいに書いても少なくともMozilla 1.6(Windows XP)では効かないのです。何か別の方法があるのかな？

● シンプル・イズ・ザ・ベスト――「チャリべえ」

ITmediaライフスタイルより、車輪と脚で不整地も動きまわれるロボット。動画を見てみました。おもしろーい。ちょっと揺れて怖そうなのですが、完璧じゃない、というのが強いんだろうな。記事のタイトルにはシンプルなのがいい、と書いてあるけれど、どこをシンプルにして、どこを複雑にするか、という采配をするにはセンスと経験が必要なんだろうと思う。

● CPUならいっぱいある。といっても2つを4つに見せてるだけ。

観測データの解析。今まで比較的ファイルI/Oリミットな解析をしていたのですが、だんだんフィッティングといったCPUを使う解析に移ってきました。ちょっとは進んでるか。そういうわけで「&」マークを使う機会が増えてきてます。CPUを3つ使っておいて残りの1つで人間が頭を使う作業をしている。

作業をどれくらい並列化するか、をシェルのレベルで自動的に最適化してくれるとうれしいんだけど、難しいよな。

(追記)でもやっぱり人間の頭でちゃんと考えないといけなかった。データ点を一つずつ増やしながら直線回帰分析をして比較的いいフィットのデータ点の数を求めていたのだけれど、ライブラリを使っていると毎回何万点かについて足し算をしなくちゃいけないことに気づいた。ライブラリを使わないで前回までの和を保存しとくようにしたら何桁か早くなったよ。共分散行列の式を計算するのに時間がかかったけど。

● adminのあたりがタイヘンなことに

● [book] The Little, Brown Handbook

同僚が高校の時に使っていた作文の教科書。忘れないようにメモをしておく。

● [memo] Linuxアプリケーションの64ビット・システムへの移植

そのうち必要になるかも〜

● バッドノウハウのダークサイドに落ちかける

今手元のマシンでrabbitが使えない(ビルドマシンと常用マシンの環境がはなれすぎていて入れるのが怖い)ので、セミナーの発表をTeXでできないかとちょっと調べてみた。

くらいで比較的きれいに出力できる。が、問題が。

• 考えてみたら日本語の発表。Linuxで作ったPDFの漢字をみんなに見てもらえる自信がない。
• 図を含めるのが少し大変。下記のようにしたらなんとかなるけど。

というわけで、Powerpointにします。ごめん。

● [Ruby] るびま19号出ました

19号では「Rubyist Hotlinks」が休載になっちゃいましたけど、それを補ってあまりある記事が目白押しですよー。お楽しみください :)

カヤック星人からのプレゼントもあります。僕も応募したい！

● [memo] Windowsで8+3形式のファイル名を表示させる

@ITより、dir /xだった。cdで長いファイル名が使えればいいのにな。

● がんばって起きてMoscone Center Westまで歩いてドーナツとコーヒーとオレンジジュースをいただく。twitterのログを見るとgit pullをして何かバグを直してたみたい。何を直してたんだろうw コード書きたいよね。

● [io13] The New Android SDK Build System

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

Gradleベースのビルドシステムに乗り換えます。 build.gradleの例 (動画3:00付近)

ファイルの位置は基本的にconventionで決まっている。 古い(eclipseで始めた)プロジェクトでは、build.gradleでフォルダを指定しておく (動画4:50付近)。

GradleTasks。 gradleコマンドのコマンドラインにタスクを複数指定できる。 assemble、check、build (assembleとcheck)、clean、…。

で一覧が見られる。

Customization。これもbuild.gradleで(動画7:40付近)。

ビルドしたらバージョンコードを上げたいとすると(動画8:10付近)*1、

BuildTypes (動画9:10付近)。

デバグのみに必要なソースがある場合にはソースコードのフォルダを追加したりもできる(動画10:10付近)。

署名のしかたもbuild.gradleに書く(動画11:15付近)。

ビルドタイプによってパッケージ名を分けることもできる。 ファイルの依存もbuild.gradleに書く。ローカルなフォルダ、リモートレポジトリ。

MultiProject。settings.gradleに。ライブラリプロジェクトの記述。

バイナリパッケージをアップードできる。

プロダクトのflavorの設定 - paid/free/...

build type/flavorと次元が増えている。優先度つきで設定を選んできてくれる。

テスト。ライブラリはapkに入る。check、connectedCheck (PCに端末をつないで)、deviceCheck (ビルドサーバ経由で端末あるいはエミュレータで)。 設定はbuild.gradleに書いておく。レポートを作ってくれる。

ビルド環境。gradleのバージョンはラッパーを使って、プラグインのバージョンはbuild.graldeで指定して、tools versionもbuild.gradleで指定する。 プロジェクトによってSDKのバージョンを設定できる。 IDE(Android Studio)はビルドに関係しない。

参考サイト。 Android Tools Project Site、 http://b.android.comより AndroidのIssueのリスト。

● [io13] Device Agnostic Development

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

ウェブサイトを閲覧する環境。デスクトップ、モバイルだけではなく、 テレビ、ゲームコンソール、…。 Network、Compute、Renderが様々な環境がある。 どのように対応すればよいか？ Chrome DevToolsにいろいろあるから活用するといいよ。

Network。Page Load Time (PLT)を気にする。 ロードに3秒かかると57%のユーザーはどこかに行ってしまい、 46%は戻ってこない。22%は友だちにあのサイトには行くな、とアドバイスする。 ネットワークには、レインシ、バンド幅、課金というコストが存在する。 リクエストをできるだけ減らす、Concentrate & minify、画像による負荷を減らす、 といった努力が必要。 画像はトラフィックの60%を占めるので、 WebPを使う、必要なサイズにサーバ側で小さくしてから送る、SVGを使うといった工夫が大切。 mod_pagespeedによる高速化も。

Compute。Jankを減らす。 60 FPSのリフレッシュレートのなか(16.7msec)で描画を終わらせるべき。 ユーザーはフレームの抜けに気づく。 スタイルの変更はDOMの中に留める。子要素の変更で済むときはBodyは変更しない。 レイアウトの再生成(layout trashing)を避ける。 例えば、offsetwidthを参照すると、その時点でレンダリングしなければならない。 style.widthを設定すると、レンダリングのリフレッシュが必要になる。 position.fixedを使って再レンダリングを減らす。 Javascriptを減らす。 アニメーションやトランジションはブラウザの実装を使うようにする。 イベントリスナは最小限にする。

Render。 画像のデコードや拡大縮小には時間がかかる。 ピクセルを塗り潰すのは大変。影をつけるなどの複雑なペイントは負荷が高い。 ChromeのDevToolsでペイントしなおしている場所を見ることができる。

UXの改善。 ユーザーの環境に依らない内容と機能。 開発者が受けている制限をユーザーに押し付けてはいけない。 内容の配置をユーザーの環境に合わせて最適化すること。

その他。 制限を決めて、限界を決めて、最初から測定を続けて、目標に到達するまでは出荷しない。Let's Make the Web Jank-free!。

● 「UX Design for Developers」は部屋に入れる直前に満室になってしまいました。聴きたかっんだけれど録画も無いとのこと。残念。「Code Lab: Android Location Based Services」に行ってみましたが無線ではSDKのダウンロードもままならず断念。早めのお昼にしました。二階の南側でぽかぽか日光に当たりながらGoogle Glassも試させていただきました。そういえば何かコードも書いてた気がする。

● [io13] When Bad Things Happen to Good Clusters: Robust Systems with Google Compute Engine

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

Google Compute Engine - Infrastructure as a Service (IaaS)。 バーチャルマシン+ネットワーク、ストレージに、 スケール、スピード、グローバルなフットプリントがくっついたもの。 Googleのエンジニアリングの専門知識と経験も。 Google Cloud Engineの一部。

さて。何がうまくいかなくなるか？なにもかも: 人的ミス。設定、手順の問題や、事故。 バグやリソース不足によるソフトウェアの不具合、それに引き続くリカバリの失敗や、 アップグレードの失敗。 ハードウェアの問題やセキュリティの問題。

ガイドライン。 信頼性のゴールを設定して、指標の測定を続けること。 すべてをドキュメントすること。 すべてを自動化すること。 メンテナンスや機能停止に備えておくこと。 アップグレード計画を用意しておくこと。

Google Compute Engineからの電動工具(power tool)。

ストレージ。 VMと一緒に消えるscratch disk、高速でスナップショットもとれるpersistent disk、 VM外のcloud storage、cloud SQL、cloud database、 また、ユーザの所有するストレージが使える。

自動化。 VMのメタデータにssh鍵等を含めておく、rc.localなどで起動時の処理をさせる、 イメージをつくる、ChefやPuppetによるオーケストレーション。

スケーリングや安定性。 ロードバランサ、geographic density。高速な起動。

最後に。

Reliavility = Infrastructure + Design + People

アプリ、サーバ、ゾーン、リージョン、その他、の機能停止に備えておこう。 Google Compute EngineにはEalry Access Programもあります。

● 講演の合間には分解されたChromebook Pixelを眺めたり。こういうのも興味を持って会場にやってくると得られる情報量が違うんだろうなあ…。

● [io13] Mobile Performance from the Radio Up: Battery, Latency and Bandwidth Optimization

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

有線とは異なる無線の性質、デザインへの制限、パフォーマンスの特性、最適化の基準。 無線ネットワークはWiFiとMobileに、Mobileはさらに2G、3G、4Gに分かれている。

WiFi (802.11 1999年から)はデスクトップやラップトップのための規格。 消費電力に制限はない。 衝突が起きた場合にはランダムな時間だけ待つ。 輻輳するとパフォーマンスが落ちるため、 それぞれのチャンネルの負荷は10%程度に抑えないといけない。 規格では16チャンネル用意されているがそれぞれの通信が複数チャンネルにまたがってしまうので、 同時に使えるのは最大3チャンネル(例えば1、6、11)だけ。 講演者の近所には15個近いアクセスポイントが見えている。 混雑しているところでは、通信の95%で35msec程度のレイテンシが生じてしまう。

Mobile。 安定していてスケールできる。 消費電力をできるだけ抑える。 Radio Resource Controller (RRC)による交通整理。 端末からデータを送りたいというリクエストを送ると、 時間、電力、エンコード等を指定される。 RRCは2G、3Gではコアネットワークにあったが、4Gではアンテナタワーに設置されていて、 レイテンシの短縮に寄与している。

端末網のレイテンシ。 Control Plane Latenctyは3Gでは2.5秒未満、4Gでは0.1秒未満、 User Plane Latencyは3Gでは0.1秒未満、4Gでは0.05秒未満。 Low power stateからだと、 Idle to activeには0.1秒、 Dormant to activeには0.05秒かかってしまう。 通信がない状態がしばらく続くと、Control planeからやり直しになる。 ここで、例えばDNS参照には、TCPのハンドシェイク等も含めて、 3Gでは0.5-3.5秒かかり、4Gではもう少し短かい。

遅延が0.1秒未満だと動作はスムーズに感じられるが、 0.1-0.3秒だとひっかかりを感じ、1秒を越えるとコンテキストが破壊される。 (YouTubeでは5-10秒に動画を切って送付しながら回線の速度をモニターして クオリティを調整している。)

電力消費。 通信がない状態が続いて低消費電力状態になるまでの電力の消費で ぜんたいの消費電力が決まる。 1回のサイクルで10J程度消費する。 定期的に通信をするビーコンや解析ツールはどんどん電池を消費するので注意が必要。

携帯デバイスのためには、 キャッシュを有効活用する、 通信内容を圧縮することがたいせつ。

● Google I/Oの終わった後には、Fisherman's Wharf方面のTrader Joe'sにお土産を買いに行きました。贅沢してケーブルカーに乗ろうと思ったら満席だったのでバスで。Google Mapsで検索してすぐに経路がわかるのが便利です。さすが地元。38番のバスはトロリーで、インバーターの音を聞きながらチャイナタイウン、イタリアタウン(!)を抜けて行きました。ちょっと足を伸ばしてFisherman's Wharfに行って食べたクラムチャウダーはホワイトソースの缶詰の味しかしなかった。残念。Google Glassをかけたままの人を見かけましたが強奪されたりしないかな。

● 夜は、火曜日にご飯をおごってくれた友だちとThe Tipcy Pigへ。おいしかったけれど、「Big Platae」なメニューの大きいのはお皿だけだったりするのは笑ったよね。そのあとの、Blue Bottleのコーヒーもなかなかおいしかった。

●