プログラマブログhttp://aics-app.sakura.ne.jp/rss_share/201505111431301807622プログラマ・IT関係者のための個人ブログ-
2016-01-26T21:00:00+09:00
Basilica - Haskell製のモダンなフォーラム
2016-01-26T21:00:00+09:00MOONGIFT
-
2016-01-26T17:00:00+09:00
Mejiro - 1ファイルの写真ビューワー
2016-01-26T17:00:00+09:00MOONGIFT
-
2016-01-25T21:00:00+09:00
Safari-Extension-Swift-API-Diff - AppleのSwiftドキュメントを見やすく整形
2016-01-25T21:00:00+09:00MOONGIFT
-
2016-01-25T17:00:00+09:00
radicast - radikoをPodcasting化
2016-01-25T17:00:00+09:00MOONGIFT
-
2016-01-24T21:00:00+09:00
diff-pdf - PDFファイルの差分を表示
2016-01-24T21:00:00+09:00MOONGIFT
-
2016-01-24T17:00:00+09:00
Rabbit - 複数のブラウザで動画再生を同期
2016-01-24T17:00:00+09:00MOONGIFT
-
2016-01-23T21:00:00+09:00
MindMapIt - リストを編集して表示はマインドマップで
2016-01-23T21:00:00+09:00MOONGIFT
-
2016-01-23T17:00:00+09:00
Photo Editor - Webベースの写真編集ソフトウェア
2016-01-23T17:00:00+09:00MOONGIFT
-
2016-01-22T21:00:00+09:00
Diff to HTML - 差分をHTMLに変換
2016-01-22T21:00:00+09:00MOONGIFT
-
2016-01-22T17:00:00+09:00
uonome - 魚眼レンズで撮影した写真を補正
2016-01-22T17:00:00+09:00MOONGIFT
-
2016-01-21T21:00:00+09:00
Fabricator - 自作UIツールキットのベースに
2016-01-21T21:00:00+09:00MOONGIFT
-
2016-01-21T17:00:00+09:00
Web Attacks - 敵を知り己を知れば百戦危うからず
2016-01-21T17:00:00+09:00MOONGIFT
-
2016-01-20T21:00:00+09:00
OS.js - 実用的な品質のWebOS
2016-01-20T21:00:00+09:00MOONGIFT
-
2016-01-20T17:00:00+09:00
N1 - シンプルで格好いいUIのメーラー
2016-01-20T17:00:00+09:00MOONGIFT
-
2016-01-20T02:30:10+09:00
業務で使えるオープンソース(173)「Electron」
2016-01-20T02:30:10+09:00MOONGIFT
-
2016-01-19T21:00:00+09:00
FeSlideFilter - スライドしてフィルタを適用
2016-01-19T21:00:00+09:00MOONGIFT
-
2016-01-19T17:00:00+09:00
Github Email Thief - GitHubからメールアドレスを収集
2016-01-19T17:00:00+09:00MOONGIFT
-
2016-01-18T21:00:00+09:00
React Komik - Reactを使ってマンガを編集
2016-01-18T21:00:00+09:00MOONGIFT
-
2016-01-18T17:00:00+09:00
WebShell - WebサイトをMac OSXアプリ化
2016-01-18T17:00:00+09:00MOONGIFT
-
2016-01-18T06:50:45+09:00
レガシーなIEのサポート終了へ!HTML5の本格導入を検討しよう
2016-01-18T06:50:45+09:00MOONGIFT
-
2016-01-17T21:00:00+09:00
Dunk - iOSアプリのDribbbleビューワー
2016-01-17T21:00:00+09:00MOONGIFT
-
2016-01-17T17:00:00+09:00
amazhist - Amazonの購入履歴をグラフ化
2016-01-17T17:00:00+09:00MOONGIFT
-
2016-01-16T21:00:00+09:00
Internet Explorer - 3D空間にインターネットを表現
2016-01-16T21:00:00+09:00MOONGIFT
-
2016-01-16T17:00:00+09:00
forkability - リポジトリがフォークされやすいかチェック
2016-01-16T17:00:00+09:00MOONGIFT
-
2016-01-15T21:00:00+09:00
Colorify.js - 画像を分析して写真に合わせた枠を表示
2016-01-15T21:00:00+09:00MOONGIFT
-
2016-01-15T17:00:00+09:00
Web.md - WebベースのMarkdownビューワー
2016-01-15T17:00:00+09:00MOONGIFT
-
2016-01-14T21:00:00+09:00
Pjuu - Python製のソーシャルサービス基盤
2016-01-14T21:00:00+09:00MOONGIFT
-
2016-01-14T17:00:00+09:00
objc2swift - Objective-CをSwiftに変換
2016-01-14T17:00:00+09:00MOONGIFT
-
2016-01-13T21:00:00+09:00
TrackRecord - タイムシートベースのプロジェクト管理
2016-01-13T21:00:00+09:00MOONGIFT
-
2016-01-13T17:00:00+09:00
KindleUnpack - KindleデータをePub化
2016-01-13T17:00:00+09:00MOONGIFT
-
2016-01-12T21:12:53+09:00
みんな大好きマリオブラウザーズ風ゲームまとめ
2016-01-12T21:12:53+09:00MOONGIFT
-
2016-01-12T21:00:00+09:00
MariOCaml - ステージ自動生成型スーパーマリオ
2016-01-12T21:00:00+09:00MOONGIFT
-
2016-01-12T17:00:00+09:00
jetzt - 英文速読を補助するブックマークレット
2016-01-12T17:00:00+09:00MOONGIFT
-
2016-01-11T21:00:00+09:00
Open Hunt - Product Huntのオープンソース版
2016-01-11T21:00:00+09:00MOONGIFT
-
2016-01-11T17:00:00+09:00
Elodie - CLIで写真を分類分け
2016-01-11T17:00:00+09:00MOONGIFT
-
2016-01-10T21:00:00+09:00
Sharer.js - 多様なサービスに対応したシェア機能を提供
2016-01-10T21:00:00+09:00MOONGIFT
-
2016-01-10T17:00:00+09:00
WordPress.com for Desktop - WordPress.com用のデスクトップクライアント
2016-01-10T17:00:00+09:00MOONGIFT
-
2016-01-09T21:00:00+09:00
Gyamm - メールをWebページに変換
2016-01-09T21:00:00+09:00MOONGIFT
-
2016-01-09T17:00:00+09:00
CloudyTabs - iOSで開いているサイト一覧を表示
2016-01-09T17:00:00+09:00MOONGIFT
-
2016-01-09T05:32:17+09:00
マイクロサービスとサーバレスアーキテクチャについて
2016-01-09T05:32:17+09:00MOONGIFT
-
「「0÷0=」を実行すると「エラー」になる理由」を見て割り切れない気持ちを抑えられない理由
http://blog.livedoor.jp/dankogai/archives/51983144.html
異端の数ゼロ
Charles Seife /
林大訳
[原著:Zero:The Biography of a Dangerous Idea]
やはりblogにも書いておこう。SNSだけでは割り切れない気持ちが抑えられないので。
iPhoneアプリ「計算機」で「0÷0=」を実行すると「エラー」になる理由 - ねとらぼ
「計算機」ア...
2015-12-03T19:30:25+09:00
404 Blog Not Found
-
にわか Audible ファン
http://anemone.dodgson.org/2015/09/13/like-an-audible-listener/
Sun, 13 Sep 2015 00:00:00 +0000
<p>Macbook を壊してしまい、手元にデスクトップ環境がなくなってしまった。いい機会だから電話でどこまで文章を書く気になるか試し中。たまには世代格差に向き合わないとね。</p>
<p>さて、最近ふと <a href="https://audible.com/">Audible</a> を聞き始め、気に入っている。Podcast のおかげで音声メディアに抵抗がなくなったせいもある。先月から三冊読(?)了、一冊挫折、いまは五冊目。</p>
<p>Audible で本を聴くのは、ものによっては活字で読むよりラクな気がする。語学力の制限もあり、自分は本を読むと消耗する。気がつくと居眠りしたりネットを見たりしてしまう。活字と違い音声は勝手に進んでいき、ダレることが少ない。皿洗いやジョギングなど体を動かしながらだと眠くもならない。</p>
<p>内容の難しさや集中力の不足で話を聞き逃し理解が欠けることはある。本腰を入れて読む技術書なんかには向かない。</p>
<p>もっとも込み入った難しい本はあまり音声化されてない。自分が Audible で聴くのは軽めの読み物。エッセイ、ハイテク偉人伝、自己ケーハツとか、時間があったら読みたいと思いつつ読まずにいた本を選んでいる。先月聴いたのは <a href="https://audible.com/pd/Bios-Memoirs/The-Everything-Store-Audiobook/B00FJJFO1C">The Everything Store</a>, <a href="https://audible.com/pd/Science-Technology/Make-It-Stick-Audiobook/B00M0EO7EY">Make It Stick</a>, <a href="https://audible.com/pd/Bios-Memoirs/What-I-Talk-about-When-I-Talk-about-Running-Audiobook/B002V5BLM8">What I Talk about When I Talk about Running</a>. あとは亡くなった Oliver Sacks を偲んで <a href="http://www.audible.com/pd/Science-Technology/The-Man-Who-Mistook-His-Wife-for-a-Hat-and-Other-Clinical-Tales-Audiobook/B0051VJH84/">The Man Who Mistook His Wife For a Hat</a> を聴いてみたものの、これは難しすぎ半分くらいで挫折した。活字でも辛そう。要修行。</p>
<p>自分を英語に差し向けるため、何年か前からなるべく日本語の本を読まずにやってきた。でも結果として読書量が激減し困っていた。こういう「面白そうだけど読まなくていい本」は全く読めない。Audibleのおかげでそれが生活に戻ってきて嬉しい。</p>
<p>音声本一冊の長さは5−6時間から長いものだと10時間以上。実際試すまでは長いと思っていたけれど、自分はジョギングと家事労働あわせて一日平均一時間くらい耳が空いていた。10時間の本が月に三冊聴ける。悪くないでしょ。</p>
<p>再生速度も変更できる。ただ1.25倍を試してみたら自分にはやや無理があった。ナレーションの音声はPodcastの喋りよりずっと聞きやすいものの、解釈のスループットが間に合わない感じ。これも要修行。</p>
<p>聴きやすさ以外で Podcast と Audible の違いは何か。これはウェブと本の違いみたいなものだと思う。本に速報性や即興の面白さはない。金もかかる。でもまとまった考えを読む良さがある。その時の気分で選べばいい。Audibleだと一単位が長いぶん Podcastの面倒だったエピソードを選ぶ手間が少ないのはよい。</p>
<p>ガジェット。ながら聴きにはワイヤレスイヤホンが必須。試しに首輪型(<a href="http://www.amazon.co.jp/dp/B00VDES2SE/">こういう感じ</a> …の安いやつ)を買い、かけっぱなしにしてみている。掃除機をかけるかとか配偶者の身支度を待つみたいな細かい時間を使えるようになる。</p>
<p>まとめると、家事を読書に変えるAudibleはなかなかよいという話。日本版は月額一定聞き放題らしい。ちょっと羨ましい。</p>
Sun, 13 Sep 2015 00:00:00 +0000steps to phantasien
-
iKnow 感想など
http://anemone.dodgson.org/2015/07/26/iknow-review/
Sun, 26 Jul 2015 00:00:00 +0000
<p>ちょっと前に買収だか事業譲渡だかされたオンライン単語帳の iKnow、 気がつくと未だに使ってるのでふたたび感想などを書いてみる。長く使ってる人の感想はあまり見かけない気がするから。あと中の人に届けばと儚い願いも少々。</p>
<p><a href="http://iknow.jp/">iKnow</a> はコンテンツ付きのオンライン単語帳。コンテンツ付きな上に出題順序の工夫などを上手いことやってくれるので、金を払えばサービスの指示に従う以外に頭を使わず突っ込んだ時間の分だけ単語を覚えられる。コンテンツ集めやトレーニング方法の工夫は英語学習の面倒なところなので、それが金の力で解決できるのはよい。</p>
<p>単語を覚える以外にもいろいろできそうなことが書いてあるけれど、基本的には単語(と構文や熟語など)の暗記のためのサービスだと思って使うのが良いと思う。</p>
<p>コンテンツ付きの単語帳アプリは世の中にそこそこあれど、語彙の網羅性とテクノロジ側の出来をあわせて一番良いのは知ってる範囲だと iKnow と思う。自分は一時期 <a href="http://ankisrs.net/">Anki</a> という単語帳アプリを使っていた。アプリの出来に大きな不満はなかったけれど、とにかくコンテンツ(=単語)の登録が面倒で、あるとき挫けて以来 iKnow に出戻った。データ入力というのはほんとに苦痛なのですよ。音声データなんて現実的には諦めるしかない。</p>
<h2 id="自分の使い方:684dc9cfd33aec3a03cb938ce6a74e81">自分の使い方</h2>
<p>基本的な使い方は試せばわかるので省き、自分がやっていることをぱらぱら書く:</p>
<ul>
<li>1日 15 分、出勤前にやっている。毎日が目標だけど現実には週 5くらい。15 分は退屈さに負けない自分の上限。</li>
<li>モバイルではなく Mac からウェブ版を使う。キーボードがある方が速くタイプできる。</li>
<li>カウンターに Mac を置き、立ってやる。座ると眠くなる。</li>
<li>“まとめて学習” モードだけ使う。コースを選ぶのに頭を使うのは精神力の無駄。</li>
<li>知っている単語をスキップする機能は使わない。知ってる/知ってないの判断に頭を使いたくない。</li>
<li>音声は新しい単語や怪しい単語のみ聞く。復習ではスキップする。時間がかかるため。</li>
<li>一方で自分は声を出す。単語や文章は声を出して読む。声は記憶を助ける。慣れると逆に無言が辛くなる。</li>
<li>iKnow は新しく覚える単語を購読中のコース(=単語リスト)から小出しにしてくれる。
新しい語彙の在庫が切れたタイミングで新しいコースを自分で継ぎ足す。</li>
<li>数日さぼると “要復習” の単語が増えてくる。そうなったら新しい単語を覚えるのは一休みして復習を優先する。</li>
</ul>
<p>基本的な方針は, まず飽きたり挫けたりないこと。続ければ何かは身につく。継続優先で無理はしない。あとトレーニング以外で頭を使う部分を減らす。そういう暗黙のオーバーヘッドは、やる気が低い日に響く。あーだるいなーさっさと iKnow やって会社いくべ…と歯磨きの延長くらいになるとよい。</p>
<p>一方、その範囲でなるべく効率を上げる。iKnow は語学のトレーニングとしてはだいぶぬるい部類。それはテクノロジのおかげで無駄な負担が減っているおかげでもあるけれど、サービスとして学習意欲が低い人にフォーカスしているせいもあるだろう。負担が小さい引き換えに、単位時間あたりで覚えられる単語の数は、たとえば Anki を使うときより小さい気がする。なのでできる範囲で工夫して学習の勾配を調整する。必要ない音声をスキップしたり、声を出したり。</p>
<p>たぶんデータを scrape して Anki にインポートするのが負荷調整の最終形だろうけれど、さすがにやってない。ダッシュボードがちゃんとしてるとか、たまに gamification 的な励ましがあったりするのは、それなりに良いものだと思うから。というのは言い訳だな。面倒だから。</p>
<h2 id="不満-要望:684dc9cfd33aec3a03cb938ce6a74e81">不満、要望</h2>
<p>iKnow、やる意味はあると思って続けているけれど、もうちょっと良くなってくれよと思いもする。
買収後の展開に期待しつつ不満を書いてみる。</p>
<ul>
<li>コース選択が面倒。そしてコース間で語彙の重複がある。英会話、ビジネス、TOEIC, 留学などとカテゴリごとにコンテンツが用意してあるけれど、外国人が英語を覚える水準で必要な語彙に大きな違いがあるとは思えない。どうせ最終的には数千語を覚えなければいけないんだから、一列に並べて上から下に覚えてけばいいじゃん。その方が重複もなくなるし、到達点もわかりやすくていいでしょ。</li>
<li>ぬるすぎる。負担を調節したい。たとえば自分は四択がいらない。記憶の曖昧さを隠してしまう。常に単語をタイプしていい。単語一語だけの意味を問うのもなくていい。文章とセットで覚えるの方が似た意味の単語と disambiguate されて助かる。負担を上げて一日 15 分が 10 分で済むなら自分はその方がいい。</li>
<li>ウェブ版のキーボードショートカットをもうちょっと強化してほしい。たとえば出題に対して「わかる」は Enter が使えるけど「わからない」を選ぶ方法がない。毎日使うものなので習熟で効率化する余地を作ってほしい。</li>
</ul>
<h2 id="そのほか:684dc9cfd33aec3a03cb938ce6a74e81">そのほか</h2>
<p>語彙の強化は語学の一部でしかないとはいえ、これだけ機械的に片付けられるのはありがたい。受験勉強でこういうのが使えたら楽だったろうにと思う。</p>
<p>ただ覚えた語彙も出会わないと忘れていくので iKnow の復習だけでは足らない。日常的に活字/音声コンテンツを消化しないと蒸発してしまう。技術資料やテックゴシップの記事が使う語彙は限られているので、もうちょっと雑多な読み物を読むようにしたいとは思う。あまりできてない。普段読まないもののために語彙を鍛えるのは無駄に見えるかもしれないけれど、そこは鶏と卵。やや人工的に bootstrap しないと読めるものは増えない気がする。</p>
Sun, 26 Jul 2015 00:00:00 +0000steps to phantasien
-
A Million Hello Worlds
http://anemone.dodgson.org/2015/07/13/a-million-hello-worlds/
Mon, 13 Jul 2015 00:00:00 +0000
<p>テクノロジの流行をファッションに例えて揶揄することがある。新しいテクノロジを追いかけてばかりいるプログラマを非難し、勉強会もいいけど問題解決に頭を使えという。</p>
<p>ファッショナブルなプログラマを責めるのは、衣服や装飾品で散財する人を無駄遣いせず金を貯めろと責めるのに似ている。ユニクロ・無印・(その他無難なブランド)でいいじゃん、それより体でも鍛えなよ、なんて説教するかんじ。一理ある。でも話が通じる気はしない。</p>
<p>おしゃれ貧乏はさておき、人々はなぜ身だしなみに気を使うのだろう。周りと同じがいいなんて消極的な理由もあろう。特定の文化的集団、サブカルチャーに参加するためかもしれない。反対に人と同じが嫌だからかもしれなければ流行りに詳しいところを見せたいからかもしれず、単に目立ちたいからかもしれない。演出したい自己像を求める人もいれば洋服マニアもいる。防寒や衛生や法令遵守だけが衣類への期待とは限らない。身だしなみは社会的なシグナルでもある。</p>
<p>テクノロジにも似たところがある。モバイルファーストに沸く社内で波風を立てまいと Java や Swift に手を染め、インフラを支える分散システムハッカーに憧れて Go で書いたサーバを EC2 に載せ、オブジェクト指向だドメイン駆動だと煩いおっさんになりたくないと Haskell や VHDL の門を叩き、IoT で一目置かれようと Arduino や Spark をいじり、腕自慢に OS や言語処理系を書いてみる。</p>
<p>どれも何らかの社会的な欲求を含んでいる。欲求や下心が時に私たちをテクノロジーへと差し向ける。「成長」「問題解決」「雇用」「人類の叡智」みたいな肩肘張った動機だけが人を動かすわけじゃない。</p>
<p>プログラマを動かす社会的な欲求は様々だろう。中でもわかりやすいのは二つ。一つ目は「居場所探し。」趣味のあう友達をみつけたい、話し相手、仲間が欲しい。二つ目は「自分探し。」難しいアルゴリズムをそらで書けるハッカーになりたい。オープンソース・コミッタになりたい。誰かに認められたい。</p>
<p>程度に個人差はあれ、これらは伝統的であると同時に現代的な欲求でもある。プログラマに限らず、昔から専門職は同業者のコミュニティにアイデンティティを預けてきた。(<a href="http://www.amazon.co.jp/dp/4561233857">1</a>, <a href="http://www.amazon.co.jp/dp/0691127956/">2</a>) そこにインターネットが拍車をかけた。オープンソース・プロジェクトからユーザグループまで、今や居場所に不足はない。GitHub に競技プログラミングと、腕を問う機会も溢れている。</p>
<h2 id="原動力の内訳:2d1db08a58da5fd27c83c31f8b7f8098">原動力の内訳</h2>
<p>社会的欲求、肩肘張った動機。これらは互いに繋がりあっている。自分を認めてもらうには相手がいる。問題を解決すれば相手から関心を集められる。その過程で人は成長する。仲間を通じて職が見つかる。仕事を通じて真実を垣間見る。隣り合う動機や欲求は切り離せない。一方で自分を動かす原動力の内訳に目を向けてわかることもある。社会的な切望と肩肘の緊張を読み違えると空回りする。</p>
<p>ある最新テクノロジに強い魅力を感じたとする。たとえばプログラミング言語。型システムがすごい、文法が練られている、最新超絶技巧 MonadJIT で速い - でも正直、説明は難しくてよくわからない。触ってもピンとこない。でも俺これすごいと思うんだよ!一緒にやろうぜイソノ!!衝動が自分を駆り立てる。</p>
<p>けれどこの強い気持ちは、本当にテクノロジそれ自体から来たのだろうか。テクノロジを使っているのが景気のいいスタートアップだった、尊敬するプログラマが Twitter でウェブスケールと騒いでいた、そんな憧れや羨望に根ざしてはいないか。憧れも羨望も悪くない。でも気持ちの出処に気づかないままテクノロジにのめりこむと、彼らが飽きて別の何かを触りだした途端に裏切られたと気を落とし、貴重なやる気を損ないかねない。それよりもヒップなスタートアップに乗り込む手管、憧れを追う道の一つとしてテクノロジに取り組む方がいい。浅はかに見えるかも知れない。でも歪みがなく努力と成果が噛み合いやすい。</p>
<p>別のよくある話。野心的な未完成テクノロジの愛好家がいる。プロジェクトの挑戦的な目標に賛否が渦巻くなか真っ先に飛びつく人々。社会的欲求のメガネを通すと、ここには二通りの自分探し、居場所探しがいる。まずは命知らずのリスクテイカー。今から手をつけて、テクノロジが化けたとき先頭に立ちたい。もう一つは自分だけがその良さをわかっていると思いたいサブカル知識人。同好の士がつくる小さな輪の中で知る人ぞ知る喜びに浸る。</p>
<p>未完成テクノロジには夢があるから識者と話すのは楽しい。けれど中には無自覚に地雷を売りつけたりジャーゴンに酔うばかりの人もいる。参照透過な FPGA だからデータレイクのフリートでも楽勝なんですよ。まあちょっと専門的だし iOS9 beta2 以降しか対応してないので森田さんには無理ですかね・・・なんて言う人とにこやかに付き合うには厚い教科書より社会的欲求を読み解きたい。</p>
<p>こうしたステレオタイプに限らず、プログラマの世界でおこる突飛な出来事の多くには社会的欲求の影がちらついている。</p>
<h2 id="目移りの時代:2d1db08a58da5fd27c83c31f8b7f8098">目移りの時代</h2>
<p>社会的欲求は自分を動かす活力にもなるが、煩わしさもある。</p>
<p>テクノロジの移り変わる速さに焦る気持ちのいくらかは、自分の居場所や立場を持たない不安に根ざしている。居場所と立ち位置が定まると不安は和らぐ。少し距離を置き、本来の目的、たとえば問題解決のためにテクノロジと向き合う余裕が生まれる。だからさっさと居場所を見つけて頑張ろう。そのためには・・・</p>
<p>そのためにはどうすればいいのだろうね。色とりどりのテクノロジに目移りし、腰を据えられない現実がある。</p>
<p>以前 <a href="http://www.theatlantic.com/magazine/archive/2013/01/a-million-first-dates/309195/">A Million First Dates</a> という記事を見かけた。アメリカの出会い系サービスが社会に与えつつある影響を綴った読み物で、<a href="http://www.amazon.com/dp/B00EV4YYGC">同名書籍</a>からの抜粋。著者によると、出会い系サービスの登場によって相手探しが楽になった結果、逆に誰か一人に覚悟を決められない現象が起きているという。今の相手がダメでも別の誰かを探せばいいというわけ。カジュアルな関係を求める身にはいいけれど、結婚相手を探す人には困った話だ。</p>
<p>プログラマの居場所さがしはどこか出会い系時代の受難に似ている。世の中は新しく魅力的なテクノロジに溢れている。みなよく出来ていて、アクティブで、未来を感じる。でもこの先もっといいテクノロジが登場するかもしれない。週末に試して手応えを調べようか。でも先週書きかけのプロジェクトがまだ片付いてないな・・・そういえばこないだ送った pull request どうなったろう・・・返事きてるのに無視してた・・・え、この本読んでから出直してこい、ですか・・・。</p>
<p>テクノロジの社会的洗練も人々を煽り立てる。オープンソース・プロジェクトは居場所としてのコミュニティ運営に労を惜しまない。フォーラム、ソーシャルメディア、カンファレンス、コントリビューションガイド・・・声は届き、コードは取り込まれる。殺伐荒野のオープンソースは過去のものになりつつある。プロプリエタリな製品でもかつての無機質さは影をひそめる。企業主体のイベントのみならず、当事者がオンラインのあちこちに顔をだしユーザと対話している。</p>
<p>居場所を求めればその願いが叶う。良い時代になったと思う一方、社会的な誘惑がかつてなくプログラマを惑わしてもいる。斜に構えた見方をすれば、自分たちの秘めたる欲望がテクノロジ・マーケティングの餌食になったとも言える。でもどちらかというと <a href="http://www.amazon.co.jp/dp/4270000384/">Paradox of Choice</a> の文脈で考える方が腑に落ちる。選択肢が多すぎると人は不幸になる。何を手に取っても後悔するばかり。選ぶだけでくたびれてしまう。ホットなテクノロジはどんどん入れ替わる。きりがない。</p>
<h2 id="おうちがいちばん:2d1db08a58da5fd27c83c31f8b7f8098">おうちがいちばん</h2>
<p>Paradox of Choice に疲れた人への処方箋は「一番良い」のかわりに「十分良い」選択肢で満足すること。同じことはテクノロジ選びにも言える。気に入った「十分良い」テクノロジに腰を落ち着け、しばらくそこでがんばる。一つの解決だと思う。無印を買えとは言わない(けっこう高いし)までも、皆がみなヒップスターでなくていい。</p>
<p>あるテクノロジに腰を据えると、主観的にはそれが自分にとって「一番良い」テクノロジになる。習熟がもたらす自信。コミュニティに所属する安心感。テクノロジへのエンゲージメントには正のフィードバックがある。テクノロジは移り変わるから、今の「十分良い」もいつか十分でなくなる。でもその入れ替わりの周期は、市場の「一番良い」テクノロジの周期よりずっと長い。「十分良い」はそれなりに日持ちする。加えて自分自身の習熟や影響力が賞味期限を延ばす。新参者にとっての良さとベテランにとっての良さは違う。</p>
<p>テクノロジへの習熟は、あるテクノロジ、たとえばツールやフレームワーク固有の技法を身につけても終わらない。使えるテクノロジがひとつだけではさすがに仕事にならない。それでもどこかに居場所があると、それを足がかりに辺りを歩き回ることができる。ウェブのフレームワークならデプロイメントやデータベースをはじめ様々な周辺技術を試せるだろうし、言語処理系の実装、プロトコルといった要素技術の中身に目を向けてもいい。モバイルなら UX やメディア処理などがすぐそばにある。</p>
<p>わかりやすい隣接関係が全てではない。たとえば自分のテクノロジを育てるべく競合を知る。弱点を補うテクノロジを学ぶ。数駅先で交わるテクノロジがある。</p>
<p>戻る場所があるから旅行、冒険ができる。見聞を伝える相手がいる。戦果を飾る広場がある。逃げ帰る家がある。居場所としてのテクノロジを通じて世界への理解を深めるプロセスこそが、そのテクノロジへの習熟だと考えてみる。「十分良い」を「一番良い」に引き上げるのは、そんなエンゲージメントの力だ。</p>
<h2 id="n-回目の別れ:2d1db08a58da5fd27c83c31f8b7f8098">N 回目の別れ</h2>
<p>蜜月もいつかは終わる。</p>
<p>ヒトと比べてソフトウェアの寿命は短い。自分が勝ち取ったテクノロジもある日を境に少しずつ衰えはじめる。死が二人を分かつ日は期待するほど遠くない。墓守にでもならない限り、古巣を去り新しいテクノロジに身を投じる日は待っている。</p>
<p>居場所に愛着が強いほど終わりを認めるのは難しい。けれど名残惜しさや別れの痛みは血の通う証でもある。冷え切った関係は体から熱を奪う。自分の愛したテクノロジがそうなる前に、少しずつ別れを告げよう。いつもより遠くの国へ旅をして、新しく関係をやりなおそう。</p>
<p>やりなおしのエンゲージメントは、良くも悪くも初めてのそれとは違う。必ずしもかつてのような熱意はない。一方で焦りもかつてほど大きくない。擦り切れたテクノロジの隙間から滲み出た居場所の澱が、あちこちでぼんやりと瞬いているのに気づく。往年の輝きはないが暗闇の心細さもない。古巣への情も気休めになる。着古したジャケットを羽織ると社会的欲求は近寄ってこない。テクノロジのライフサイクルを見越した慎重さが身を助ける。次の十分良い何かを決める惑いは少ない。</p>
<p>自分を突き動かす社会的欲求の必死さがない。それは弱さでもある。テクノロジとの関係が、少なくともはじめはどこか冷めている。信頼関係を築き心を許すまでに時間がかかる。冷めていて慎重なのは何かをなくした人間の性。情熱と焦燥に駆られて走る人々には追いつけない。</p>
<p>それでも共に日々を過ごせば、いつかわかりあえる日がくる。ゆっくりと情の灯がともり、静かな蜜月が訪れる。別れもいずれまたやってくる。永遠の愛を誓うことはできない。だから限られた時の中でこの身を捧げる。最期の夜に伝える言葉を胸の奥に留めながら。</p>
<hr />
<p><a href="http://shunichi-arai.blogspot.com/2015/07/it.html">新井さんの人気</a> を羨んで書いた草稿にコメントをくれた <a href="twilog.org/karino2012">@karino2012</a> ありがとう。</p>
Mon, 13 Jul 2015 00:00:00 +0000steps to phantasien
-
Disowned by a Dysfunctional Family
http://blog.livedoor.jp/dankogai/archives/51968656.html
Open Source の定義とはなんだろうか?
私にとっての定義は、以下だった。
Perl, the first postmodern computer languageImagine, open source is merely a byproduct of our need for family. So, look at all of you out there. You're just a big, dysfunctional family...
2015-07-11T13:30:24+09:00
404 Blog Not Found
-
YAPC::Asia does not welcome Dan Kogai
http://blog.livedoor.jp/dankogai/archives/51968425.html
His money is welcome, however.
2015-07-09T10:45:55+09:00
404 Blog Not Found
-
生焼け四半期終了
http://anemone.dodgson.org/2015/07/02/end-of-half-baked-quarter/
Thu, 02 Jul 2015 00:00:00 +0000
<p>第二四半期は毎週ブログを書くぜと<a href="http://anemone.dodgson.org/2015/03/31/half-baked-weekly/">宣言し</a>、その四半期がおわった。14 回書いている。悪くはないが、毎週はかけなかった。</p>
<p>週刊は忙しすぎる。そして生焼けな文章を書くのは、やってみると思ったより満足度が低い。短く済むものを短く書くよう促す効果があるのはいいけれど、少し丁寧に書こうとすると時間切れになってしまう。生焼けのために他のことをする時間がなくなると虚しい。憂さ晴らしのはずが憂さを溜めてしまう。自分がおっさんなせいで体力や時間といった資源が足りないせいもあるとは思う。</p>
<p>というわけで週刊実験はおしまい。なにか違う書き方を考えたい。
短く書けることがわかったのはよかった。</p>
Thu, 02 Jul 2015 00:00:00 +0000steps to phantasien
-
Ftrace と Systrace
http://anemone.dodgson.org/2015/06/15/ftrace-and-systrace/
Mon, 15 Jun 2015 00:00:00 +0000
<p><a href="http://developer.android.com/tools/help/systrace.html">Systrace</a> を使いたいとおもい調べた記録。</p>
<p><a href="https://www.kernel.org/doc/Documentation/trace/ftrace.txt">Ftrace</a> は Linux カーネルのプロファイル(トレーシング)機構。Ftrace にはざっと三つの構成要素がある:
1. Linux の debugfs を介して操作するトレース情報のバッファリング機構、
2. 2. カーネル標準で用意されているいくつかの標準probe(トレーシング情報)、
3. 3. コンパイラのプロファイリングオプションを介して全てのカーネル内関数に注入されるフック。</p>
<p>Ftrace の機能はコンパイル時スイッチでオフにできる。特に 3 のコンパイラ経由のフックはオフにされていることがあるっぽい。若干のオーバーヘッドがあるため。
手元の Ubuntu では有効になっていた。</p>
<p>Android の Systrace は ftrace のインフラを使って作られている。
Android のトレーシング機構 Systrace は 3 に頼らず必要な情報をとれるよう, Android 自身がフレームワークのコードとかに probe を入れている。</p>
<p>Solaris 出身で最近は Linux チューニングに熱心な性能改善エキスパート Brendan Gregg が、少し前から <a href="https://lwn.net/Articles/608497/">ftrace スゲーサイコー</a>と騒いでおり何かと思っていた。彼は 3 が気に入っているのだな。Solaris のカーネルはは色々ながんばりの結果 3 相当がきっちり動き、おかげで DTrace が使える。Brendan Gregg は Linux の性能モニタリングが弱いとよく不満を書いているけれど、ftrace に DTrace 代替としての可能性を見出し喜んでいるのだろう。</p>
<p>Brendan Gregg がもう一つ騒いでいる Linux カーネルの要素技術に eBPF がある。BPF/eBPF は Linux カーネルに入っているミニ言語処理系で、パケットフィルタなんかを書くのに使われているという。Chrome も Linux 版のサンドボックス機構に eBPF を使っており、システムコールの引数をチェックして不正な呼び出しを殺したりしている(らしい)。自分はそれで名前だけ知っていた。</p>
<p>Brendan Gregg にとって eBPF は DTrace の D 言語相当なのだろう。Ftrace でカーネルのあちこちにフックを差し込めるようになり、そのフックのなかで eBPF のプログラムを動かして欲しいデータを数える。これで Linux 版 DTrace のできあがり・・・みたいなイメージと思われる。こうやって声の大きいユーザが欲しいものアピールするのは良い話な気がする。DTrace 相当までの道のりは遠そうだけどがんばってほしい。じっさい <a href="https://lwn.net/Articles/599755/">Tracing で使う試みはある</a> ぽい。</p>
<p>もっとも Android アプリ開発者としてはそこまで立ち入るまでもなく、というか立ち入りようがない。
当分は Systrace をよく理解しておく方がよさげだな。</p>
Mon, 15 Jun 2015 00:00:00 +0000steps to phantasien
-
転校生の本歌取
http://anemone.dodgson.org/2015/06/11/cover-songs/
Thu, 11 Jun 2015 00:00:00 +0000
<p>ふと思い出し書き直しの話 (<a href="http://anemone.dodgson.org/2015/04/13/age-of-non-rewrite/">1</a>, <a href="http://anemone.dodgson.org/2015/04/09/probablistically-sacrificial/">2</a>) の続き。</p>
<p>書き直しの必要に迫られることも、たまにはある。それはオリジナルが手に入らないとき。転職先で前の職場にあった内製ツールが使いたい。慣れたプログラミング言語にあったライブラリが新しい言語に欲しい。そんなときは自分の新しい環境でオリジナル相当品を書き直したいかもしれない。再発明、移植なんて呼ぶこともある。</p>
<p>この書き直し、再発明は、必ずしもオリジナルを超えなくていい。越えるべきオリジナルを使えない事情があってのコードだから。スポーツの試合で怪我をしたエースのかわりに急遽投入された補欠の立場に似ている。ベストを尽くし役割を果たせばいい。補欠系書き直しとでも呼ぶことにしよう。</p>
<h2 id="bazel-と補欠たち:5c5c8031d356923c1cc6ecef60bafba0">Bazel と補欠たち</h2>
<p>一応の役目は果たすものの、オリジナルほどはぱっとしない。そんな補欠系書き直しはたくさんある。</p>
<p>プログラミング言語をまたいだ補欠系書き直しとして真っ先に思いつくのは Node.js 用のビルドツールたち。Grant にしろ Gulp にしろ、たしかに Node のライブラリを直接呼び出せるぶん JavaScript 専用ツールならではの仕事をしている。けれど素晴らしい出来とも言い難い。
かつて GNU Make がつとめた決定版としての貫禄を欠いている。</p>
<p>職場をまたいだ再発明はどうか。</p>
<p>少し前、 Google は <a href="http://bazel.io/">Bazel</a> というプロジェクトをオープンソース化した。クロス言語の汎用ビルドシステム。Google 社内のコードは大半が Bazel でビルドされている。公開こそ最近だけれど内製ツールとしての歴史は長い。大規模コードベース相手にも動作が速いと社内外にファンが多く、会社をまたいで何度も再発明されている。</p>
<p>Facebook は <a href="http://buckbuild.com/">Buck</a> という Android と Java 用のビルドツールを作った。Buck は Bazel の強い影響下にある。DSL の文法があまりにそっくりなので、Buck の存在を明かした<a href="https://www.youtube.com/watch?v=HUE_yrd8tl0">講演</a>ではサンプルコードが画面に現れた途端に会場が Google 社員の笑いに沸いた。Bazel と同じく Buck は巨大ツリーのビルドを得意とする。加えて Android 向けの高速インクリメンタルビルドというキラー機能がある。一方で制限も多く、用途も Android と Java に限られる。そのためか今のところ普及しているとは言えない。</p>
<p>Twitter には <a href="https://pantsbuild.github.io/">Pants</a> と呼ばれるビルドシステムがある。これも Bazel の仲間。文法もよく似ている。Pants は Scala や Python など複数のプログラミング言語および Thrift コンパイラのようなコード生成ツールを標準でサポートする。Twitter の Polyglot な性格をよくあらわしている。そして Bazel や Buck 同様大きなコードベースを扱うのが得意。Twitter の Scala エコシステムに集う企業を中心に使われてはいるものの、やはり普及の兆しは弱い。</p>
<p>Google 自身も Blaze の亜種を持っている。Chrome は <a href="https://chromium.googlesource.com/chromium/src/+/master/tools/gn/README.md">GN</a> というビルドシステムへの移行を進めている。GN は高速低機能な make 代替品 <a href="https://martine.github.io/ninja/">Ninja</a> の設定ファイルを出力するメタビルドシステム。だから Buck や Pants とは少しちがう。それでも Blaze からいくつかのデザインを引き継いでいる。GN は前身の <a href="https://chromium.googlesource.com/external/gyp/+/master/README.md">GYP</a> より高速で文法も簡潔なのがウリ。でも現状の Chrome ビルドが複雑すぎてまだ移行が終わっていない。Chrome 以外で使う話も聞かない。</p>
<p>みな Bazel を使えばいいじゃん、といえるほど簡単な話でもなかろう。表舞台に現れるのが遅かった上にまだオープンソース化がおわっていない。今となっては Buck や Pants の得意分野で同じだけの力を発揮できるのかすら怪しい。贔屓目に言っても膝に矢を受けている。</p>
<p>内製ツールとしての Bazel は補欠でない書き直しの成功例だ。表現力を絞り厳密さを強いる DSL にビルドシステム本体の拡張性を組み合わせる優れた設計を起点に分散ビルドまでを備え、社内の GNU Make を置き換えた。けれどその成功はより広い世界に届いていない。書き直された補欠達もどこかぱっとしない。これはビルドシステムの呪いなのか、それとも書き直しの宿命なのか。いずれにせよ冴えない。</p>
<p>これらのツールを使ってる当人たちは困ってないだろうから、補欠よわばりが失礼なのはわかっている。でも Makefile を書いては自己嫌悪に陥り GNU Make を呪う身の自分はがっかりしてしまう。誰かあいつをやっつけてくれよ・・・。</p>
<h2 id="転校生-git:5c5c8031d356923c1cc6ecef60bafba0">転校生 Git</h2>
<p>落ち込んできた・・・明るい話をしよう。補欠が思わぬ活躍をすることもある、とかね。</p>
<p>ある人は補欠系書き直しの金字塔として Git の名を挙げる。Linux カーネルのバージョン管理システムとしてうまれた Git は、ライセンスの変更に伴い使うことが難しくなった商用の分散バージョン管理システム <a href="http://en.wikipedia.org/wiki/BitKeeper">BitKeeper</a> の穴を埋めるために生まれた。分散バージョン管理がまだ珍しい 21 世紀初頭のことだから、Git の開発者が分散バージョン管理について多くを BitKeeper から学んだであろうことは想像に難くない。</p>
<p>今や Git はバージョン管理ソフトウェアの代名詞となり、一方の BitKeeper はユーザを探すのすら難しい有様。</p>
<p>Git を補欠よわばりするのはいくらなんでも畏れ多い。もうちょっと妥当な例えはないものか。転校生なんてどうかしら。ある土曜日、決勝戦当日の朝。エースストライカーが交通事故で骨折との報が届く。自分ら人数ギリギリだったのにどうすんの。青ざめるチームメイト達。そんな中、オレを出せと歩み出たのはウチのクラスの転校生だった。名前はたしか… Linus Torvalds…</p>
<p>Git の素晴らしさに異論はないし Linus Torvalds のことは尊敬している。でも転校生がロックスターだったこのストーリーに自分はあまり胸踊らない。転校生モノの面白さってそこじゃないでしょ。</p>
<h2 id="finagle:5c5c8031d356923c1cc6ecef60bafba0">Finagle</h2>
<p>別の転校生 <a href="https://twitter.github.io/finagle/">Finagle</a> の話。Finagle は Twitter で開発された Scala の PRC フレームワーク。Twitter の Microservices 基盤の中核ともいえるコンポーネントだ。プロトコルは <a href="https://thrift.apache.org/">Thrift</a> を話す。</p>
<p>Finagle の元ねたシステムの一つは Google の内製 RPC フレームワークだろう。<a href="http://www.grpc.io/">GRPC</a> の前身たるそのシステムは C++ で書かれ <a href="https://github.com/google/protobuf">Protobuf</a> を話す。</p>
<p>直列化フォーマットとしての Protobuf は以前からオープンソースだけれど、当時その RPC 実装は公開されていなかった。Protobuf のライバルたる Thrift にはいちおう PRC もあったが、多重化も非同期 API もないしょぼい代物。本気の RPC 実装は Twitter の Microservices 化に不可欠。でも使えるコードがない。そこで Finagle が生まれた・・・と自分は理解している。</p>
<p>Finagle は単なる補欠ではない。Scala の言語機能や <a href="http://netty.io/">Netty</a> の拡張性をとりこみ、同世代には類のないフレームワークとなった。<a href="https://twitter.github.io/finagle/guide/Futures.html">Future</a> ベースのスマートな非同期 API。<a href="https://twitter.github.io/zipkin/">Zipkin</a> に代表される様々なプラグイン。派生元の C++ RPC 実装にこのカッコ良さはなかったに違いない。(あったらごめんなさい。)</p>
<p>Finagle 開発者の一人 <a href="http://monkey.org/~marius/">Marius Eriksen</a> はもともと Google でインフラまわりのコードを書いていた BSD ハッカー。良いプログラマには違いない。一方で件の内製 RPC を作っていたわけではない。それでも前職の経験と Twitter の Scala 力、それに彼自身の技術を組み合わせて Finagle を作り上げた。</p>
<p>大企業からスタートアップに移って活躍をするエンジニアは、都会の私立高校から田舎の公立校にやってきた転校生とどこか似ている。都会のクラブでは当たり前の殺伐とした厳しさがここの部活にはない。田舎の公立で Rails なんて・・・。最初は馬鹿にしていた主人公。それでも段々と心を開いて練習に打ち込み、ついには全国大会へと進出する。会場で彼を待っていたのは一昨年まで在籍していた検索学園だった。「おまえ Ruby 使ってるんだって?クラッシュしない言語は楽だよナァ」ビッグデータだクラウドだとプロプリエタリな C++ コードをちらつかせつつ主人公を嘲笑するかつてのチームメイト達。でも今の俺には Scala がある!ノンブロッキングの未来が俺を待っているんだ!!逐次型マシン語と関数型バイトコードの戦いの火蓋がいま切って落とされた!!!</p>
<p>というストーリーの方が転校生モノとしては面白いとおもうのだよ。なおこの投げやりな物語はフィクションであり、実在の人物・団体とは一切関係ありません。</p>
<p>Finagle をめぐる俺たちの RPC (仮題)には続きがある。少し前、Uber 高校は <a href="https://github.com/uber/tchannel">TChannel</a> という RPC フレームワークを公開した。やはり Thrift を話し、Python, Node, Go をサポートする。TChannel は Finagle の影響を<a href="https://github.com/uber/tchannel/blob/master/docs/protocol.md">隠さない</a>。Finagle みたいのが欲しかったけど Scala を使っていないから自分たちの使う言語で書いたよと言っている。組織ではなく言語の壁が書き直しを促すパターン。Finagle に限らず GRPC など他の選択肢も増えた昨今、オープンソースプロジェクトとしての TChannel にどれだけ魅力があるのかはわからない。コードを軽くひやかしたかんじさほど意欲的にも見えない。地味な幕開けの第二部。行方は暇なときにでも見届けたい。</p>
<h2 id="本歌取:5c5c8031d356923c1cc6ecef60bafba0">本歌取</h2>
<p>単なる書き直しには身構える自分だけれど、補欠系、転校生系の書き直しはけっこう好きだ。転校生系書き直しは本歌取でもある。舞台を変え、新しい制約や文脈の中で古いアイデアを再発見する。その歌の核が何なのか、何が偶然で、何が時代の要請なのか。本歌取の歌い手に助けを借りながら、自分も答えに近づくことができる。そんな期待がある。</p>
<p>期待は叶わない事も多い。それでもカバー曲を聞く楽しみは残されている。新しい時代の風をうけ軽やかに歌う姿はそれだけで励まされる。羨ましくもある。オリジナルの隣で書き直すとなかなかこうはいかない。本家のプレッシャーが強すぎて息苦しい。</p>
<p>あるソフトウェアが再発明なのかオリジナルなのか、その境目は必ずしもはっきりしない。たとえばプログラミング言語の実装なんて繰り返されるアイデアのるつぼだ。だから何かを再発明だモノマネだと非難するのは気が乗らない。同じものになったらむしろ大したものだけれど、そもそもカバーはモノマネと違う。そっくりじゃなくていい。書き直しでなくても、新しいソフトウェアに潜む耳慣れたモチーフに気づくと得をした気分になる。わかるよ、僕もそれ好きだよ、なんて頬が緩む。</p>
<p>そういうの、たまにはいいじゃん。</p>
<hr />
<p>草稿にコメントをくれた <a href="https://twitter.com/karino2012">@karino2012</a>, <a href="https://twitter.com/jmuk">@jmuk</a> ありがとう。</p>
Thu, 11 Jun 2015 00:00:00 +0000steps to phantasien
-
続・にわか Podcast ファン
http://anemone.dodgson.org/2015/05/20/more-like-a-podcast-listener/
Wed, 20 May 2015 00:00:00 +0000
<p>およそ<a href="http://steps.dodgson.org/b/2013/09/21/an-overnight-podcast-listener/">1年半前</a>から聞き始めたにわか podcast listening は継続中。</p>
<p>最近は多めに subscribe して面白そうなエピソードだけ聞くことにしている。
消化は炊事中とジムでのランニング中。ランニングは週に 4-5 回 30 分、炊事は週に数回各 30 分から1時間くらい。
時間予算が増えたのに加え全部聞くのを諦めたおかげで、聞く時間が足りないと感じることはなくなった。
むしろ炊事の手際をよくしたい・・・。</p>
<p>以下聞いているものたちを列挙。</p>
<h2 id="tech-podcasts:9f07f2639c2c3a35cc51f915ee1f1bff">Tech Podcasts</h2>
<p>まず技術系から。前に書いた中でいまだ聞いているのは <em><a href="https://changelog.com/">The ChangeLog</a></em> くらい: 最近だと <a href="https://changelog.com/152/">TypeScript の Anders Hejlsberg</a> が登場する回は面白かった。IDE でコンパイラの書き方は変わったんだよ!という語りが熱い。ちょっと TypeScript のコードを読みたくなる。
ただ番組全体では Docker や Node などゴシップの渦中にいる関係者を呼んでコミュニティの話を聞き出すパターンが多い。やや食傷気味。
コードに踏み込んだ話をもっとして欲しい。</p>
<p>そういう意味で <em><a href="http://www.se-radio.net/2015/05/se-radio-episode-226-eric-evans-on-domain-driven-design-at-10-years/">Software Engineering Radio</a></em> は面白い: 最近人気急上昇中の <a href="http://www.brendangregg.com/">Brendan Gregg</a> なんかが登場する一方、このところ陰の薄い <a href="http://www.se-radio.net/2015/04/se-radio-episode-225-brendan-gregg-on-systems-performance/">Eric Evans</a>が最新回。この振れ幅たるや。昔からやっている番組なので、面白そうなバックナンバーを探す楽しみもある。Paxos の作者 <a href="http://www.se-radio.net/2014/04/episode-203-leslie-lamport-on-distributed-systems/">Leslie Lamport</a> の回は痺れたし、チューリング賞をとったデータベースマフィア <a href="http://www.se-radio.net/2013/12/episode-199-michael-stonebraker/">Michael Stonebraker</a> の回なんかも普通に勉強になる。</p>
<p>その出自ゆえ iOS を話題にした podcast はたくさんある一方、 Android の番組は少ない。それでも二つ聞いてる。
Android の中の人がやっている <em><a href="http://androidbackstage.blogspot.com/">Android Developers Backstage</a></em> (略して ADB) と、コミュニティ発の <em><a href="http://fragmentedpodcast.com/">Fragmented</a></em> 。ADB はもうちょっと録音をなんとかして欲しいけれど当事者だけあって趣深い内容。Fragmented はホストのパーソナリティが辛いと思っていたら回を追うごとだんだん良くなってきた。要素技術を扱うよりゲストを呼ぶエピソードがいい。頑張っている Android アプリ開発者の話を聞くのは励まされる。
iOS 系も一個くらい聞きたい気がする。なんかないかな。</p>
<p>たまに聞いている <em><a href="http://devopscafe.org/">DevOps Cafe</a></em>: 要素技術の話は全然せず、もっぱらおっさんが世間話をしている。
組織を変えなきゃダメなんだよドンッみたいなノリ。
Basho CTO <a href="http://devopscafe.org/show/2015/4/15/devops-cafe-episode-59-dave-mccrory.html">Dave McCrory</a>
の登場するエピソードはよかった。データベース開発者ってテクノロジー厨二病みたいなのばっかりだとおもってたけれど、
商売の臭覚が鋭そうな人でした。</p>
<p><em><a href="http://codelunch.fm/">Codelunch.fm</a></em>: 何度か聞いた。若々しさがよい。自分の好きなテクノロジを根拠なくしかし熱く語る様が楽しい。まわりに全然若者がいない身としては癒される。日本語。</p>
<h2 id="non-tech-podcasts:9f07f2639c2c3a35cc51f915ee1f1bff">Non-Tech Podcasts</h2>
<p>バリエーションを求め、最近はプログラマ向け以外の番組も聞いている。</p>
<p>まず <em><a href="http://gimletmedia.com/show/startup/">Startup</a></em>: 第一シーズンを聴きそびれたと思っていた矢先、第二シーズンが始まった。<a href="https://www.datingring.com/">Dating Ring</a> という出会い系スタートアップを創業から追いかける体裁。このスタートアップ、女子大生(というのが差別的表現であることは承知しておりますが、そのゴシップ感が面白さの一部なので使ってます)が友達と勢いで創業した会社がなぜか Y Combinator のプログラムに採用され、けれど勝手が分からず四苦八苦。セクハラ投資家まで現れて・・・という展開。テレビドラマ <a href="http://www.hbo.com/silicon-valley#/">Silicon Valley</a> を見た時も思ったけれど、スタートアップ・ストーリーって学園スポーツマンガみたいな風情があるよね。努力友情勝利売却。</p>
<p><em><a href="http://a16z.com/tag/podcasts/">a16z Podcast</a></em>: テック投資家の親玉格 Andreessen Horowitz が流行りのテクノロジやニュースについて識者に聞く番組。金の匂いが渦巻く今時のシリコンバレーっぽい内容。ずっとイノベーションイノベーション言ってて疲れる。大企業にいると平和ボケする気がして、キナ臭さに身を慣らそうとたまに聞いてる。ワナビー精神。</p>
<p><em><a href="http://www.reddit.com/r/upvoted">Upvoted</a></em>: Reddit の中の人が最近話題になったスレの当事者を呼んで話をきく。にちゃんねるのよい話まとめブログみたいなもの。当事者が出てくるのがベタに面白い。Reddit はアメリカネットカルチャーの中でそれなりに存在感がある。そういうサブカル的感心もあって半分くらいは聞いてる。Huck という著名 vagabond (ホームレス旅人) の<a href="https://www.reddit.com/r/Upvoted/comments/30eako/episode_11_four_walls_and_a_roof/">回</a>は特に面白く、<a href="http://www.newsweek.com/2015/05/01/homeless-millennials-are-transforming-hobo-culture-323151.html">雑誌記事</a>も派生していた。</p>
<p><em><a href="http://feeds.harvardbusiness.org/harvardbusiness/ideacast">HBR IdeaCast</a></em>: HBR だけにライフハック兼自己啓発みたいなもんです。その手の本の著者を呼んでつまみ食いする回が多い。
キリッとしたい朝にぽつぽつ聞く。</p>
<p><em><a href="http://longform.org/podcast">Longform</a></em>: ノンフィクション作家など物書きを呼ぶ対談番組。<a href="http://freakonomics.com/">Freakonomics</a> の Stephen J. Dubner が出ているのに気づいてつまみ食いはじめた。まだどうこう言えるほど聞いてない。Stephen J. Dubner の回はおもしろかった。</p>
<h2 id="npr:9f07f2639c2c3a35cc51f915ee1f1bff">NPR</h2>
<p>ラジオ局 NPR の配信している番組たちに Podcast らしいライブ感はない。完成されたラジオ番組相当が降ってくる。
でもプロの仕事だけあってどれも完成度が高く面白い。滑舌もいい。</p>
<p><em><a href="http://www.npr.org/programs/ted-radio-hour/">TED Radio Hour</a></em>: 決まったテーマの TED のトークを毎回数本紹介し、ついでに講演者当人を呼んで話を聞く。量が多すぎて聞く気が起きない TED も選別されると悪くないなと見直す。ただこれを聞いて興味の湧いたトークを通しで聞くと特に面白くなかったりする。
編集に騙されてるかも。</p>
<p><em><a href="http://www.npr.org/programs/invisibilia/">Invisibilia</a></em>:
NHK のドキュメンタリーのいいやつに匹敵する出来。 ぶっちぎりで面白いっ・・・などと興奮したのも束の間、
あっという間に第一シーズンが終わってしまった。<a href="http://current.org/2015/03/npr-there-will-be-more-invisibilia-episodes/">再開待ち</a>中。聞くものがないときにバックナンバーを予習しておくとよいのではないでしょうか。この話をする相手がいなくて寂しい・・・。</p>
<p>こんなとこです。思ったより subscribe していた。</p>
<p>テックでない番組は <a href="http://www.shiftyjelly.com/pocketcasts">PocketCast</a> の Discovery タブから探したり、他の番組の中で流れる宣伝をきっかけに聞き始めたり。最近はニュースが聞きたいと思っているのだけれど、今の所うまく探せていない。</p>
<p>最近は聞きがてらシャドーイングしようと試している。声は出さず唇を動かすくらい。話の速さに一割もついていってないとおもうけれど、シャドーイングに集中すると時の流れが速くなり、ジムで走る退屈さが和らぐのはいい。語学トレーニングとしての効用は不明。</p>
Wed, 20 May 2015 00:00:00 +0000steps to phantasien
-
異動ルールズ
http://anemone.dodgson.org/2015/05/14/move-rules/
Thu, 14 May 2015 00:00:00 +0000
<p>異動してみた。Chrome と関係ない Android アプリのチームへ。</p>
<p>モバイルに詳しくなろうと余暇にちまちまコードを書いてみたもののまったく捗らない。いっそ仕事にしてみようという次第。座席の引越しから数日、よろよろしながらもやっと初コミットできた。めでたい。</p>
<p><a href="http://www.amazon.co.jp/dp/1455534846/?tag=stepstophanta-22">Work Rules</a> という本がある。
Googleの人事(People Ops)のボスによる Google の本で、人事制度を中心に企業文化やシステムを紹介している。
いまいち時代背景が不透明な <a href="http://www.amazon.co.jp/dp/4532319552/?tag=stepstophanta-22">How Google Works</a>
と違い大企業としての Google をうまく描いている。興味深く読んだ。</p>
<p>中でも三つの論点が印象に残った。透明性、自由、そして管理職の権威を削ぐこと。異動の支度をしながら読むと説得力がある。一例として様子を書いてみたい。</p>
<p>Google のエンジニアリング部門は、たまの異動を薦めている。いろいろ経験してよいエンジニアになりなさいね、という意図だと思う。強制されるわけではない。同じ製品の仕事を続ける人も多い。一方で数年おきに居場所を変える人も少なくない。</p>
<h2 id="透明性:ac81a3432111faf3fe57d24d84646c04">透明性</h2>
<p>社内には求人サイトがある。既存の製品からリリース前の秘密プロジェクトまで幅広く募集がある。面白そうなものをいくつかブックマークし、どれにしようと思いを馳せる。</p>
<p>ここで透明性が光る。</p>
<p>募集要項には一緒に働くであろうチームメイトのリストがついてくる。チームの規模や地理的な散らばり具合がわかるほか、社内名簿経由でレジュメを辿れば期待されるスキルセットも透けて見える。私は小さめのチームがよかったので、チームメイトの名前が長々と並ぶところはやめておいた。</p>
<p>大抵はプロジェクトのコードネームも載っている。秘密プロジェクトの求人は詳細をぼかし「メールで訊いてね」などと書いてあるが、コードネームで社内を検索するとあっさりプロジェクトのページ (Google Sites) がみつかったりする。リリース前の製品だと閲覧制限されていたりもするけれど、まあ半分以上の募集では何かしら見つかる。同様にチームメンバーの名前を検索すればメーリングリスト(Google Groups) のアーカイブにたどり着く。締め切り前にチームを励ますマネージャからのメールが目に止まる。いいマネージャだけど締め切りきついのはちょっとな・・・と思ったりする。</p>
<p>ページにはコードのビルド方法が書いてある。特殊なケースを除き、大半のコードは読める場所にある。チェックアウトすればコードの規模や好みがわかる。履歴から開発ペースもわかる。コミットログを集計してエースか誰が推し量ったりしてみる。名簿にない名前がログにあらわれ、誰かと思ったら少し前に異動でチームを離れた人だった・・・そんなこともわかる。</p>
<p>Googlegeist と呼ばれる社内サーベイの結果を公表しているチームもある。チーム外に公表するかどうかは当人たちの意向次第のため必ずしも気になる結果が見えるわけではない。私の異動先は結果を公表しており、スコアは良かった。このサーベイはけっこう素直に現状を描きだすと経験上知っているから、好スコアは不安を少し和らげてくれた。</p>
<p>知り合いの少ない自分にとって、この透明性は助けになる。</p>
<h2 id="権威と自由:ac81a3432111faf3fe57d24d84646c04">権威と自由</h2>
<p>一通りのストーキングを済ませたら候補を絞り込む。もたつく間にいくつかの募集は姿を消していた。まだ生きている募集の窓口にメッセージを送る。該当チームの管理職から返事。どんな仕事があるのか話を聞いてごらんとメンバーを紹介される。ビデオ会議で話したり、ランチを食べつつ話を聞いたり。そのあとマネージャ当人とも話す。人事考課の過去ログを見せたりなんだりしたあと、大丈夫そうだから気が向いたら手続きしてねと連絡をもらう。</p>
<p>行き先の目処が立った。ここで上司に申し開く。もう C++ には飽きました。よそのチームで Java やります。などと伝える。おやおや、他の Chrome プロジェクトをやるってのはどう?そんな代案を丁重にお断りし、じゃあ仕方ないねと話は終わる。</p>
<p>異動手続きのサイトでフォームを埋め提出。値の張る買い物みたいな承認のワークフローが始まる。けれど承認チェーンに並ぶのは異動先のマネージャたち。自分の今の上司はいない。ある条件を満たした異動を、管理職が妨げることはできないという。次のリリースまで待ってくれと口を挟むくらいがせいぜいらしい。</p>
<p>私の場合はすでに話をつけてある。だから承認されない心配はない。社内の異動ガイドにもきちんと話を通せとある。けれど実はそもそも承認がいらなかったとは、少し驚く。</p>
<p>ここで渋られても困るから、的を射た設定だとは思う。これが管理職の権威を削ぐ構造の一部なのだろう。おかげで自分は労もなく好きにチームを移ることができる。特に気にしていなかった空気のようなこの自由はシステムのデザインだった。多少の誇張もあるにせよ、そんな面はたしかにある。まあ、伝え聞くところによるとアメリカのテック大企業はだいたい似たようなものらしいけれど。</p>
<p>これは良いデザインなのか?あてにしていたメンバーがあっさりいなくなってしまうこともありうる。大丈夫なのかしら。でも考えてみれば、無理に引き止めた相手は厭気が差し転職してしまうかもしれない。それなら異動くらいで済んだ方がよかろう。</p>
<p>大企業、巷でいうほど悪くないじゃん。勤務先を見直す一幕と一冊だった。</p>
Thu, 14 May 2015 00:00:00 +0000steps to phantasien
-
Hiccup, An Audio Player
http://anemone.dodgson.org/2015/05/11/hiccup/
Mon, 11 May 2015 00:00:00 +0000
<p>ちまちまつくっていたアプリを公開してみる。<a href="https://play.google.com/store/apps/details?id=es.flakiness.hiccup">Hiccup</a> と命名。ローカルおよび Google Drive (Storage Access Framework に対応したサービス) から音声ファイルを選んで再生する。語学学習用で、再生中は画面全体が再生/一時停止/巻き戻し/早送りボタンになって細かい一時停止や巻き戻したりがラク、という意図。シャドーイングや日本語->英語が交互に使ってる教材を消化するのに自分ではぼちぼち使っている。</p>
<p>もうちょっとかっこよく、多機能で、かつ速くしてから公開したいと思っていたけれど、実力不足でコードがひどいかんじになってしまい Hello World に毛が生えたくらいで挫けた。ビギナーなので仕方なし。もうちょっと修行したら書き直したいかもしれない。</p>
<p>反省としては腰が引けて抽象化しすぎたり RxJava や DI を濫用したりでコードがまったく読めない代物になってしまったこと。あと単体テストが全然ないこと。もうちょっと抽象を薄くバリっと書きつつ必要な範囲でテストする、というのができるようになりたい。人に使ってもらえるものを作るまでの道のりは遠い。でも自分で使うものが作れるだけでもけっこう楽しい。作りたいものがさっと作れるようになりたいもんです。</p>
<p>コード: <a href="https://github.com/omo/hiccup">https://github.com/omo/hiccup</a></p>
Mon, 11 May 2015 00:00:00 +0000steps to phantasien
-
Communicate, Not Socialize
http://anemone.dodgson.org/2015/05/02/communicate-not-socialize/
Sat, 02 May 2015 00:00:00 +0000
<p>あるとき「エンジニアの仕事は設計をしたりコードを書いたり communicate をすることだ」と何かの資料に書かれているのを読み、胃が痛くなりかけた。そのあと「socialize は求められてない」と続くのを見て気を取り直す。仕事の外の付き合いは Communication じゃなくて Socializing か。なお “Socialization” は違う意味。</p>
<p>自分は言語障壁および性格のせいでチームでの振る舞いが socially awkward 側に倒れている。でも最低限の communication はこなしているせいか、大きく問題視されたことはない。めでた・・・くはないが、最悪の事態は免れた。「コミュ障」じゃなくて「ソシャ障」ってとこか。あるいは「非コミュ」じゃなくて「非ソシャ」。まあ自分に communication の問題がまったくないとは言わないけれど。</p>
<p>濫用されたカタカナのコミュニケーションのうち socializing をしない人。自分は人付き合いが苦手なおたくのステレオタイプが頭に浮かぶ。けれど件の資料に登場したのは小さな子供を持つ親だった。付き合いで飲みに行くより帰って子供の相手をしたい人たち。違う文書の似た文脈ではマイノリティの人種や性別も同じように描かれていた。文化的差異のため話が合わない人たち。</p>
<p>実際おたく的性癖が一大勢力たるエンジニアの世界で先のステレオタイプが不利にはたらくとは考えにくい。マイノリティかどうかは隣接する人々という分布のどこに位置するかで決まるわけだから。</p>
<p>誰であれ socialize しない自由があり、その選択が仕事で不利に働いてはいけない。となると「ソシャ障」や「非ソシャ」と呼ぶのも discrimination になりそう。ナシだな。訂正。</p>
<p>Socializing が職業人生に無関係とは思わない。たとえば networking は socializing の延長だろう。でも別のラベルがつけられて職務範囲から外されると少し気が楽になる。そして socializing を職務と切り離せるのは成熟の証かもしれない。「Cultural fit がない」と付き合いの悪い年寄りを追い出すスタートアップの話は、ときどき<a href="http://www.nytimes.com/2015/04/08/upshot/silicon-valley-perks-for-some-workers-struggles-for-parents.html">紙面</a>をにぎわせている。</p>
<hr />
<p>草稿にコメントをくれた <a href="https://twitter.com/jmuk">@jmuk</a> <a href="https://twitter.com/kzys">@kzys</a> ありがとう。</p>
Sat, 02 May 2015 00:00:00 +0000steps to phantasien
-
Custom Views の気楽さ加減
http://anemone.dodgson.org/2015/04/28/lightly-defining-custom-views/
Tue, 28 Apr 2015 00:00:00 +0000
<p>唐突に Android 入門日記。</p>
<p>余暇につくっている小さな Android アプリを <a href="http://developer.android.com/tools/help/hierarchy-viewer.html">Hierarchy Viewer</a> で眺めてみた。性能上 View tree はフラットなほど良い。自分のアプリは思ったよりツリーが深くてげんなり。</p>
<p>Custom Elements や React Componentsと同じノリで沢山の Custom View を定義しているのがまずいのだろうか。状態を持たせるためだけに <code>View</code> のサブクラスをつくっている。各 custom view はコンストラクタで <code>inflate()</code> してサブツリーを作り、それを表示する。<code>View#onDraw()</code> は override しない。今のところ必要がない。</p>
<p>このやり方で custom view のレイアウトを与えると、ルートとなる View (大抵はなんらかの Layout クラス) が自分自身とは別に必要。ルートになれる View は一つだけ。この制限がなければ custom view 自身がその Layout クラスを継承すれば済むのに、XML の構文だけが理由で単一ルートというこの制限を受ける。Custom view -> LinearLayout -> 本来の sub view … と一段 View 階層が深くなってしまう。やや理不尽。</p>
<h2 id="activity-fragment:52471b1e9d2721f3e08bad758a66ccbd">Activity, Fragment</h2>
<p>人々はどうしているのだろう。サンプルアプリの親玉 <a href="https://github.com/google/iosched">iosched</a> を覗く。アプリの規模と比べて custom view の数は少ない。20 個くらい。むしろ Activity や Fragment の方が多そう。</p>
<p>Custom view を使わないなら、どのように View をグループ化するのか。</p>
<p>ある程度の規模があるまとまりには Fragments を使っている。Responsive にしない画面では Activity にベタな layout を流し込んで終わり。自分が custom view を作りたくなる典型的なケース、<code>RecyclerView</code> の個々のアイテムにも custom view は作らない。適当な layout を inflate し、そのサブツリーに必要な状態やイベントリスナをくっつけておわり。たしかにこれなら余計な階層はできない。でもオブジェクト指向の敗北みたいでなんとなく悲しい。Adapter の <code>getView()</code> が巨大になるし・・・</p>
<h2 id="viewholder:52471b1e9d2721f3e08bad758a66ccbd">ViewHolder</h2>
<p>オープンソースの Twitter クライアント <a href="https://github.com/klinker24/Talon-for-Twitter">Talon</a> を覗く。すると状態は ViewHolder という呼ばれるクラスを定義し <code>View#setTag()</code> で個々の View に紐付けている。たしかにこれなら View を継承しなくて済みそう。よく見るとオフィシャル文書でも<a href="http://developer.android.com/training/improving-layouts/smooth-scrolling.html">紹介されている</a>パターン。主に性能上の理由で使えと言ってるけど、ここに振る舞いや状態を与えてもよさそうじゃない?ダメ?</p>
<p>ViewHolder はパターンにすぎず、必ずしも決まった型があるわけではない。ただ <code>RecyclerView</code> には <code>RecyclerView.ViewHolder</code> なんてクラスもある。これを使うのが流儀なのかね。</p>
<p>さて custom view を定義するのはいつなのか。
再利用可能な部品を作る時、特殊な描画が必要なときに使っているように見える。</p>
<p>少ないサンプルから得た自分の理解をまとめると:</p>
<ul>
<li>レイアウトを inflate してリスナや値を差し込めば済むケースではいちいち Custom View を作らない。</li>
<li>粒度の大きな View の集まりは Fragment でグループ化する。主に responsive な画面をつくるため。</li>
<li>Fragment が必要ないなら Activity だけで済ますのもあり。</li>
<li>リストの要素など小さなまとまりには ViewHolder クラスを定義して状態をまとめ、そのインスタンスをサブツリーのルートに <code>setTag()</code> する。</li>
<li>凝った描画をしたいときや再利用可能な汎用 View 部品は custom view にする。</li>
</ul>
<p>今書いているコードと結構違ってしまうなあ・・・。</p>
<h2 id="アンチ-fragment-の-custom-view:52471b1e9d2721f3e08bad758a66ccbd">アンチ Fragment の Custom View</h2>
<p>ふと思い立ち Jake Wharton のサンプルアプリ <a href="https://github.com/JakeWharton/u2020">u2020</a> を覗いてみる。この人はカジュアルに custom view を定義している。ただしそうした View 自身は subview を inflate しない。Adapter が custom view をルートとする layout を inflate する。これなら余分な view のネストは発生せず、かつ custom view を view tree のカプセル化に使う馴染み深いスタイルを踏襲できる。先の iosched なら Fragment を使いそうな場面でこうなっているのは、彼らが<a href="https://corner.squareup.com/2014/10/advocating-against-android-fragments.html">アンチ Fragment 派</a>だからかもしれない。</p>
<p>Adapter に inflate させると本来は View が隠すべき詳細たるレイアウトが漏れ出ている気がするけれど、一方で <code>onFinishInflate()</code> など View 標準のライフサイクルに則りやすくなるのはよい。このバランスがちょうどいいかも。</p>
<p>この流儀では:</p>
<ul>
<li>View ツリーをまとえる手段としても気軽に Custom View を定義して良い。</li>
<li>Custom View のインスタンス化は全体を Inflater に任せ、View を直接 new したり View 自身に inflate() させたりしない。</li>
</ul>
<h2 id="大げさ加減:52471b1e9d2721f3e08bad758a66ccbd">大げさ加減</h2>
<p>Custom view は大げさで、わざわざそれが欲しくなるほどの複雑さは多くないとも聞いた。抽象の厚さには好みもあるので一概には言えないけれど、たしかに inflate して OnClickListener つけておわりくらいなら custom view はいらなそう。どうせクラスがないなら functional な感じにかけるとかっこいいんだけどなー・・・</p>
<ul>
<li>まとまりをつくるのに新しいクラスが必要とは限らない</li>
</ul>
<hr />
<p>ドラフトにコメントをくれた <a href="https://twitter.com/karino2012">@karino2012</a> ありがとう。</p>
Tue, 28 Apr 2015 00:00:00 +0000steps to phantasien
-
Rust の Lifetimes
http://anemone.dodgson.org/2015/04/22/rust-lifetimes/
Wed, 22 Apr 2015 00:00:00 +0000
<p><a href="http://blog.rust-lang.org/2015/02/13/Final-1.0-timeline.html">もうすぐ 1.0</a> という Rust。
久しぶりに<a href="http://doc.rust-lang.org/nightly/book/">チュートリアル</a>を読む。以前見た時は不可解な機能が多く、こりゃ難しさに溺れて死にそうだな・・・と思っていた。今見るとずいぶんすっきりしている。単純さに舵を切れたのはえらい。</p>
<p>チュートリアルに登場したうちわからなかった機能は 2 つ: Lifetimes と Macros. Macros はさておき Lifetimes は理解してよさそう。詳しい情報を求めて<a href="http://doc.rust-lang.org/nightly/reference.html">リファレンス</a>をひやかすが、驚くほど何も書いてない。かわりにメモリ安全な C の方言 <a href="http://cyclone.thelanguage.org/">Cyclone</a> による region based memory management が元ネタとして言及されている。勢いでその資料にも目を通す。<a href="http://www.cs.umd.edu/projects/cyclone/papers/cyclone-regions.pdf">解説 PDF</a> ひとつと<a href="http://cyclone.thelanguage.org/wiki/Memory%20Management%20Via%20Regions/">マニュアルの一部</a>。どちらもよく書けていた。記法も Rust の lifetimes と似ている。</p>
<p>Cyclone の region based memory management では、フレームに確保したメモリの出処、つまりメモリの生存期間を、そのメモリを指すポインタ変数に静的な型情報としてくっつける。この生存期間が Regions. 型は総称的で、その総称性を通じ関数の呼び出し元から呼び出し先へと変数毎の reigons が伝わっていく。そして長い regions のポインタに 短い regions のポインタを代入しようとすると型チェックに失敗してコンパイラに怒られる。だから dangling pointer がおきない。</p>
<p>全てのポインタ変数が型に regions を持っている。関数の引数も同じ。そう聞くと仰々しいけれど、大抵はデフォルトの型でうまく動く。そしてデフォルトを使うかぎりコード上に regions は姿を見せない。だから普段は気にしなくて良い。Cyclone だと C からの移植で 8 割くらいは元のコードそのままでよかったという。それでも時々 lifetimes を指示したい場面があり、region 記法の出番となる。</p>
<p>Rust の仕組みはだいたい Cyclone と同じに見える。生存区間を表す型を Cyclone では Regions, Rust では Lifetimes と呼ぶ。Rust の reference すなわちポインタは, 変数の型に (多くは暗黙の) regions を含んでいる。</p>
<p>Lifetimes はコールスタックというかフレーム上のメモリの寿命をトラックするための仕組み。だから lifetimes の寿命は呼び出し関係に応じた入れ子になっている。ヒープに確保したオブジェクトの動的な寿命をトラックして正当性を担保するのは lifetimes の仕事ではない。ヒープへの reference も取りだすことはできるけれど、その reference の lifetime はヒープを指す変数があるフレームのスコープに紐づく。ヒープ上のメモリが関数のスコープを超えて outlive する事実を lifetimes で表現することはできない。</p>
<p>ではヒープにあるメモリの寿命はどう守るかというと、<code>Box</code> (<code>unique_ptr</code> 相当), <code>RC</code>, <code>Arc</code> (<code>shared_ptr</code> 相当) といったスマートポインタぽい型, move semantics と RAII がうまくやってくれる。ヒープへの reference を取り出すことはできる。ヒープとフレームの交わるところ - ヒープを指す reference の正当性は、ownership の borrowing 機構と borrowing が強制する imutability によって保証される。RAII-Move-Borrowing-Lifetimes の組み合わせが memory safety を実現する。この結論にたどり着いたのはえらい。デザインの勝利だと思う。元ネタたる Cyclone には汎用的な RAII が無いなどヒープの管理には大した工夫がなく、普通に Boehn GC を使っていると書いてあった。Rust のような GC-less にはできてない。</p>
<p>安全なぶん厳しい制限でもある。C++ と同じようにコードを書くわけにはいかなそう。いままで曖昧に済ませていた細部をよく考えないといけない。自分が混乱したのも lifetimes とヒープの関係が曖昧だったせい。おもったより寿命にルーズだった自分に気付く。</p>
<p>Rust には安全でないメモリを扱う raw pointer もある。どのくらいの頻度で raw pointer が必要になるのだろうか。動的サイズの配列 Vec 型の実装では raw pointer が使われていた。C++ で replacement new を呼んだり destrucdtor を明示的に呼んだりする程度に必要なかんじかしら。つまりしょぼいコードを書いてる分には必要ない。めでたい。</p>
Wed, 22 Apr 2015 00:00:00 +0000steps to phantasien
-
Borg Paper 感想
http://anemone.dodgson.org/2015/04/17/borg-paper/
Fri, 17 Apr 2015 00:00:00 +0000
<p>Kubernetes の元ネタになった <a href="http://research.google.com/pubs/pub43438.html">Borg というシステムの whitepaper</a> が出ていた。読んでみる。自分の Borg 経験は hello world したくらい。
全然知らない。そしてめんどくさそうなので出来ることなら使わずに人生を終えたいと思っている。
でも後学のために読んでも損はあるまい。 Google インフラシリーズでは親玉格のはず。</p>
<p>Whitepaper としては不親切な内容。読者がこの手のスケジューラについてある程度知っている前提で書かれている。ただ Cell だの Borgmaster だの Borglet だの Preemption だの、サーバ側の人々の会話に出てくる用語は一通り解説されている。きっとポイントは押さえられているのだろう。</p>
<p>・・・と思って読んだものの、やはりどうにもとりとめがない。細かい工夫の話が多く big picture がよく見えない。設定ファイルの例やプロセスのデプロイ方法といったエンドユーザ視点の説明が少なく、どうやってシステムを bootstrap するか、マシンを足す時はどうやるかなど運用の目線もなく、実装する人の観点だけで書かれているからだろう。それは正しい想定読者だと思うけど、もうちょっとファンサービスがあってもいいのではないか。そのうち tech talk のひとつもやってほしいもんです。</p>
<p>後半の Lessons セクションを見ると, Borg のいまいちだったところは Kubernetes で直したと繰り返している。クラスタマネージャを勉強したくなったらむしろ Kubernetes について調べるほうがいいのかもしれない。まあ Borg みたいにチューニングされまくってはいないだろうけれど、コードやマニュアルが読めるぶんよい。気がする。ちなみに <a href="http://mesos.berkeley.edu/mesos_tech_report.pdf">Mesos paper</a> はもうちょっとフレンドリーだった記憶。</p>
<p>以下ランダムに面白かったこと:</p>
<ul>
<li>エージェント(Borglet)が中央のサーバ(Borgmaster)に状態を報告するのではなく、Borgmaster が Borglet に状態を訊いて回る。そうやってスパイクを避けているという。なるほど。</li>
<li>名前解決のサービス (BNS) がついている。どの物理マシンにジョブが割り振られてもこの名前で引ける。名前サービスは別なのかとおもってたら Borg の一部だったのか。</li>
<li>ユーザ毎の資源はクオータで制限しており、クオータ割り当てはシステムの外で決めている。そもそも他の方法があるのだろうかとおもったが、理論的にはなんかあるっぽい。</li>
<li>Compressible な資源 (CPU や IO 帯域など)と Non-compressible な資源(メモリやディスク)を区別している。たしかにそういう区別は必要そう。</li>
<li>Preemption によって優先度の低いタスクは殺されることがある。殺されると pending queue にはいってやりなおし。「夜に流して帰った Map Reduce が朝来たら死んでた…」みたいなぼやきをたまに聞いたのを思い出す。これだったか。ハードウェアの故障以前にスケジューラが殺しに来るんじゃ idempotent に作らないとどうにもならないね。むしろこの荒々しい世界で Map Reduce を使わずバッチの何かを書くのは大変そう。</li>
<li>資源の割り当て設定を変えるとデプロイしなおし。資源をインクリメンタルに要求できる普通の OS とは違う。Mesos はインクリメンタルに要求できた気がする。まあフレームワークという巨大な単位相手にリソースを割り振るからだろうけど。</li>
<li>Borg 対応バイナリには HTTP サーバが入ってる。便利そう。</li>
<li>同じマシンで動かしたい job を指定するには Allocs という仕組みを使う。仮想 job みたいなもんか.</li>
</ul>
<p>Related work のセクションでは色々な会社の似たようなシステムが紹介されている。YARN, Mesos, Aurora は聞いたことがあったけれど、Facebook の Tupperware やら Alibaba の Fuxi やらはまったく知らなかった。Facebook ウォッチャーを気取っていたけど未熟であった。そろそろ Uber ウォッチャーに宗旨替えすべきか・・・。</p>
<p>数年前 Twitter 開催の tech talk で Mesos の話を聞いた時、講演者は Mesos のことを “Google の Borg みたいなもんです” と説明していた。元 Google 社員が蔓延するベイエリアのテック企業では Borg の存在は公然の秘密になっており、でかい会社は結局どこも似たようなものを持っているのだなあと思ったのだった。</p>
<p>Twitter といえば、かの社で SRE(Ops) をやってる人が Borg は動きが予測できなくて辛い、Mesos のほうがわかりやすくてよい、というようなことを以前<a href="http://www.goodmath.org/blog/2014/02/14/controlling-thousands-of-machines-aka-my-day-job/">書いていた</a>。どうなんだろうね。最近 Twitter は MySQL-Mesos インテグレーションを <a href="https://blog.twitter.com/2015/another-look-at-mysql-at-twitter-and-incubating-mysos">Mysos</a> という名前で発表している。ちゃんとつかってるぽい。</p>
<p>オープンソース好きとしては Kubernetes と Mesos を応援していきたい。
といっても一個人にはまったく使い道がない。掛け声だけ。</p>
Fri, 17 Apr 2015 00:00:00 +0000steps to phantasien
-
書き直さない時代の気分
http://anemone.dodgson.org/2015/04/13/age-of-non-rewrite/
Mon, 13 Apr 2015 00:00:00 +0000
<p>なんとなく続き。(<a href="http://anemone.dodgson.org/2015/04/09/probablistically-sacrificial/">前回</a>)</p>
<p>Martin Fowler が蒸し返すまで、
自分は書き直しについてことさら何か書く気が起きなかった。
どうでもよさは時がたつほど増していった。気分の出処を見直してみたい。</p>
<h2 id="部分的に書き直す:2662d6e1b0354713d7feada608afcf17">部分的に書き直す</h2>
<p>最初の理由は、書き直しがゼロかイチかの大きな判断ではないという納得かもしれない。コードの書き換えには様々な粒度がある。一番小さいのが厳密なリファクタリング。一番大きいのがフルスクラッチの書き直し。その間には様々な大きさの書き直しがある。書き直しの粒度が連続的である以上、どちらか一端を擁護する議論は虚しい。</p>
<p>小さい刻みの変更を積み重ねれば危険を冒さず大きな変更ができる。それがリファクタリングのテネットだ。刻みは小さいほど安全だから、良いプログラマは大きな変更を連続した小さい変更へと噛み砕く。変更の難しさに実力が及ばないと刻みが大きくなり失敗の危険が増す。バグが増えたり納期に遅れたりする。</p>
<p>自分の能力を超えた変更を求められることはある。仕方なく刻みを緩める。とはいえ全開のフルスクラッチまで緩め切ることはない。大半は部分的な、たとえばモジュール単位の、書き直しで事足りる。まず書き換えるモジュールをくくり出すところから始めることもよくある。Microservices だってそんなかんじでプロセスを切り離すでしょ。たぶん。</p>
<p>一見フルスクラッチを避けがたい場面ですら、十分な(あるいは例外的な)能力をもってすれば安全に大きな変更をやりとげられる。Russ Cox の <a href="https://golang.org/s/go13compiler">異言語間 Go コンパイラ移植</a> はその極端な例。わかりやすい「細かい変更」の集合ではないけれど、変換を通すための小細工を山ほど積み重ねたはず。</p>
<p>反対から見れば、変更の難しさから技量を差し引き足が出た分を危うい資金で補填するのが粒度の大きい書き直しだとも言える。</p>
<h2 id="互換性を諦める:2662d6e1b0354713d7feada608afcf17">互換性を諦める</h2>
<p>もう一つの理由は、互換性への期待が変わったことだろうか。フルスクラッチな書き直しへの批判は、書き直された新版が旧版と互換性を保つ難しさを論拠の一つにしている。一方で多くのソフトウェアは互換性を捨てながら前に進んでいる。API は deprecate される。刷新された UI からは不人気な機能が姿を消す。ウェブ標準ですら古い API のうち評判が悪かったものを取り下げている。この非互換は書き直しのバグではなく意思決定の結果だ。
意図した互換性の破棄は前もってわかる。だからランダムに壊れるフルスクラッチの非互換よりだいぶマシ。</p>
<p>互換性を損ねると決めた途端、書き直しは楽になる。決めた範囲で互換性を壊しつつ新しい方向に進めばいい。自暴自棄のフルスクラッチに走りたい衝動は遠ざかる。</p>
<p>Windows 10 に載る新しいウェブブラウザのレンダリングエンジン Edge は、古いエンジン Trident をフォークしたものだ。フルスクラッチの書き直しではない。けれどその違いは既に <a href="http://www.smashingmagazine.com/2015/01/26/inside-microsofts-new-rendering-engine-project-spartan/">WebKit と Blink より大きいという</a>。Edge は近代的なウェブでの競争力を理由に IE との互換性を捨てると決め、大きな書き直しの扉を開けた。IE の足を引っぱっていたのはひどいコードでなく互換性の鎖だった。</p>
<p>まあコードもひどかったに違いないけれど、それだけが相手ならプログラマの力量でなんとかできる。Microsoft にプログラマ不足の心配はなかろう。</p>
<h2 id="世紀末の悲鳴:2662d6e1b0354713d7feada608afcf17">世紀末の悲鳴</h2>
<p>書き直しの切り口はいくらでもあるし、必要なら互換性を切り崩してもいい。フルスクラッチでの書き直しを強行する理由を自分はもはや見出せない。けれど 15 年前に Joel Spolsky が<a href="http://www.joelonsoftware.com/articles/fog0000000069.html">書き直しは悪</a>と書いた時、それは人々の心に響いた。なぜか。西暦 2000 年と今は何が違うのか。</p>
<p>槍玉にあげられたソフトウェアの一つは、奇しくもまたウェブブラウザ。Netscape の失敗を Joel は批判した。Netscape はその後 IE に負け AOL に買収されてしまったわけだから、この書き直しを失敗とみなすのは的外れでもない。今だったら「フルスクラッチで書き直しとかあいつら狂ってるな・・・」で終わる話。けれどたしかに 15 年前、フルスクラッチの書き直しはよくある話だった気がする。</p>
<p>書籍 <a href="http://www.amazon.com/dp/0201485672">Refactoring</a> の出版が 1999 年。等価書き換え健康パズルのアイデアは今ほど浸透していなかった。コードは少しずつ腐っていくもの。腐敗を遅らせるのがせいぜい。ソフトウェアのリリースも今よりずっと離散的で、オートアップデートなんてなかった。だから仮に少しずつコードを直せても、それを撒いて試すのは難しかった。人々は健全性を取り戻す術をフルスクラッチ以外に持っていなかったのかもしれない。</p>
<p>一方、ソフトウェアの互換性に対する期待は今よりずっと高かった。それはたぶん Microsoft が持ち込んだゲームのルールだった。彼らは互換性のために莫大な工学資本をつぎ込んで高いバーを設けた。ウェブの時代がそれを塗り替えるまで、互換性への期待はソフトウェアの前に立ちふさがっていた。「同じものは壊れない」というユーザの期待が「まったく新しい何か」へと開発者を追い込み、結果として「すっかり壊れた何か」を生み出し破滅を招いた。</p>
<p>15 年前、ソフトウェア開発者は少しずつ直すことを知らず、少しだけ壊すこともできなかった。フルスクラッチの決断は板挟みになった開発者の悲鳴だった。だいぶ単純化してるけど、時代の空気はそんな風だった気がする。</p>
<p>そして今。書き直しは多くの変数を持つ入り組んだトレードオフに姿を変えた。もはやフルスクラッチの書き直しでわざわざ自分の稼ぎ口をふいにするがさつな開発者はそういるまい。Sacrificed Architecture も全てをゼロから書き直せとは言わない。</p>
<p>時代が変わり、書き直しに関する議論はかつての意味を失った。自分の興味も遠のいた。けれどその一方、誰かが書き直しについて話すのを聞くと私は落ち着かない気持ちになる。意味がないのに落ち着かない。この矛盾がどこから来るのかと考える。一つの理由は、私がまだ時代の変化を自分のものにできていないからかもしれない。古い価値観の染みはなかなか落ちない。</p>
<p>たまにはフルスクラッチもいいじゃん、という話を書こうと思ってたのにまた長くなりすぎて尻切れ・・・。</p>
Mon, 13 Apr 2015 00:00:00 +0000steps to phantasien
-
確率的に犠牲的
http://anemone.dodgson.org/2015/04/09/probablistically-sacrificial/
Thu, 09 Apr 2015 00:00:00 +0000
<p>Martin Fowler が <a href="http://martinfowler.com/bliki/SacrificialArchitecture.html">Sacrificial Architecture</a> と言い出した時は驚いた。”変化を受け入れよ” はどこにいったの。書き直しはダメと自分の中の結論が出たのは随分前のことだけれど、ひさしぶりに考え直してみる。</p>
<p>Sacrificial Architecture の論拠として Martin Fowler はいくつかのインターネッツ企業を例にとっている。でも一般化するには偏ってないか。それにこれら企業が面していたのはごく限られた種類の変化だ: 彼らはもっぱら性能不足と戦っていた。</p>
<p>機能の変化に強いコードは柔軟性の裏で性能を犠牲にしがち。機能の変化を捉えることに先鋭化した従来の Agility は性能要件の変化を必ずしもやり過ごせない。一方で存在感を増すスタートアップの世界では性能への期待が当たり前のように大きく変わる。だから Agile はあてにならない、堅牢なアーキテクチャで急成長に備えよ。そう訴えて勢いづく BDUF Microservices 勢を威嚇すべく Sacrificial Architecture は生まれた。でも行き過ぎた一般化に拡大解釈が加わり技術的負債を自己破産する言い訳として流布してしまった。誤解されても無理はない名前だ。焦って口が滑ったな。</p>
<p>性能に対する法外な期待に応えるには書き直しが必要かもしれない。これは妥当な意見に思える。それに別の見方もできる: 性能が追いつかないほどビジネスが急成長しているときは、勢いに乗って書き直しても元がとれる。性能不足は好調さのあらわれ。無理をしてでもこの勢いを逃したくない。機会損失が書き直しの危険を上塗りする。</p>
<p>一方、古き良きダメな書き直しは機能の変化や複雑化に音を上げておこる。この書き直しは何がまずいか。</p>
<p>別の角度から眺める。ソフトウェアの方向性を大きく変えたいとき、あるいは機能をやたらと追加したいとき、だいたいビジネスは失速している。行き詰まりを打破しようと方向転換や守備範囲の拡大を図っている。この投機的な場面で更に書き直しの博打を打つのは雪解けの薄氷で踊るようなもの。危険に見合う期待値がない。</p>
<p>Martin Fowler はこう言うべきだった: ソフトウェアは確率的に sacrificial である。どんなソフトウェアも連続した打ち手では乗り切れない急激な変化に襲われる可能性を孕んでいる。特に成功したインターネット企業では成長という大波が性能上の限界にコードを打ち付ける。けれど波の狭間に新大陸の影が見えていたら? 賭けに出よう。その愛するコードを生贄に…</p>
<p>こうして犠牲となってしまうコードはある。でもそのためのアーキテクチャなんてない。やっぱり失言だな。</p>
<p>拡大解釈された Sacrificial Architecture もけっこう人気がある: スピードのためにひどいコードを書き、うまくいって長期的展望がもてた頃合いでゴミを捨て書き直す。このアイデアは妥当か。うまくいくこともあるだろう。性能だけが書き直しを正当化するとは言わない。でも Martin Fowler 名義でそれを語るのはやめてあげたい。傷に塩塗るみたいで気の毒。例に挙げるのも別の何かにした方がいい。個人的には Windows NT あたりを推したい。<a href="http://www.amazon.co.jp/dp/4822247570/?tag=stepstophanta-22">人生を書き換えるアーキテクチャ</a>とでも呼ぼう。</p>
<p>書きたいことは別にあったけど長くなったので一旦おしまい。</p>
Thu, 09 Apr 2015 00:00:00 +0000steps to phantasien
-
ブロマガ更新 - 404 SECRET Not Found #29 まだディスク処分で消耗してるんですか?
http://blog.livedoor.jp/dankogai/archives/51946003.html
“404 SECRET Not Found #29 まだディスク処分で消耗してるんですか?:404 SPAM Not Found:404ch Not Found(小飼弾) - ニコニコチャンネル:社会・言論” http://t.co/h3Owx4IAgp— Dan Kogai (@dankogai) December 23, 2014
2014-12-23T21:15:20+09:00
404 Blog Not Found
-
紹介 - 未来予測を嗤え!
http://blog.livedoor.jp/dankogai/archives/51944447.html
未来予測を嗤え!
神永正博/小飼弾
久しぶりに本を上梓しましたのでおしらせを。本日発売です。
2014-12-09T05:15:51+09:00
404 Blog Not Found
-
ブロマガ更新 - 404 SPAM Not Found #28 I code therefore I am
http://blog.livedoor.jp/dankogai/archives/51943446.html
404 SPAM Not Found #28 I code therefore I am http://t.co/1jgo6p8Ggt #blomaga— Dan Kogai (@dankogai) November 30, 2014
2014-11-30T22:00:58+09:00
404 Blog Not Found
-
ブロマガ更新 - 404 SPAM Not Found #27 大きなつづらと小さなつづら
http://blog.livedoor.jp/dankogai/archives/51939927.html
“404 SPAM Not Found #27 大きなつづらと小さなつづら:404 SPAM Not Found:404ch Not Found(小飼弾) - ニコニコチャンネル:社会・言論” http://t.co/9tevzlNNUY— Dan Kogai (@dankogai) October 30, 2014
2014-10-31T01:00:55+09:00
404 Blog Not Found
-
ブロマガ発行遅延のお知らせ - 404 SPAM Not Found #27
http://blog.livedoor.jp/dankogai/archives/51936370.html
408 Request Timeout
小飼弾です。現在諸般の事情でオランダはアムステルダムにおります。
ブロマガ発行用のCMS不安定につき、本日発行予定だった#27を、私の帰国まで延期します。毎月楽しみにしてくださっている読者のみなさんごめんなさい。
2014-09-30T00:15:14+09:00
404 Blog Not Found
-
ブロマガ更新 - 404 SPAM Not Found #26 大統一言語?
http://blog.livedoor.jp/dankogai/archives/51933192.html
404 SPAM Not Found #26 大統一言語? http://t.co/37wtVyZr4X #blomaga— Dan Kogai (@dankogai) August 31, 2014
2014-08-31T23:00:47+09:00
404 Blog Not Found
-
#yapcasia - Introducing Swift - and the Sunset of Our Culture?
http://blog.livedoor.jp/dankogai/archives/51932861.html
今年も発表したので。
2014-08-29T12:30:37+09:00
404 Blog Not Found
-
ブロマガ更新 - 404 SPAM Not Found #25 こっち立てばあっち立たず
http://blog.livedoor.jp/dankogai/archives/51929139.html
404 SPAM Not Found #25 こっち立てばあっち立たず http://t.co/l7nNocNKav #blomaga— Dan Kogai (@dankogai) July 30, 2014
2014-07-31T07:15:59+09:00
404 Blog Not Found
-
恐れのみを恐れよ - 書評 - リスクにあなたは騙される
http://blog.livedoor.jp/dankogai/archives/51216658.html
早川書房東方様より献本御礼。
リスクにあなたは騙される
Dan Gardner /
田淵健太訳
[原著:Risk: The Science and Politics of Fear]
2009.05.25 初出
2014.07.24 文庫化につき更新
本書こそ、今最も恐るべき一冊だ。
初の著作がこれだとは、著者恐るべ...
2014-07-24T08:30:03+09:00
404 Blog Not Found
-
ブロマガ更新 - 404 SPAM Not Found #24 博士の異常な劣情 または私は如何にして心配するのを止めて少子化を愛するようになったか
http://blog.livedoor.jp/dankogai/archives/51925464.html
“404 SPAM Not Found #24 博士の異常な劣情 または私は如何にして心配するのを止めて少子化を愛するようになったか” http://t.co/Ch9U9aG0Rf— Dan Kogai (@dankogai) June 29, 2014
2014-06-30T05:30:05+09:00
404 Blog Not Found
-
石の模様 - 書評 - 思考する機械コンピュータ
http://blog.livedoor.jp/dankogai/archives/50509322.html
思考する機械コンピュータ
Daniel Hillis
[原著:The Patter on the Stone]
2006.05.26 初出
2014.06.06 文庫化につき更新
Connection MachineのEntryを書いてから、原著の方をむしょうに読みたくなったのだが、入手がなかなか困難そうなので、The Society...
2014-06-06T05:00:25+09:00
404 Blog Not Found
-
why(matters(Swift) > matters(Yosemite + iOS[8]))
http://blog.livedoor.jp/dankogai/archives/51922323.html
「新HWの発表ゼロ!?」なんて言っている場合じゃない。
YosemiteもiOS 8も、さらに次のヴァージョンが出るまで、高々1年半かそこらの問題だけど、Swiftは少なくとも向こう10年、いや言語というものの性格からして何十年に及ぶことなのだから。
2014-06-03T22:00:08+09:00
404 Blog Not Found
-
ブロマガ更新 - 404 SPAM Not Found #23 Owners Take All
http://blog.livedoor.jp/dankogai/archives/51921895.html
“404 SPAM Not Found #23 Owners Take All:404 SPAM Not Found:404ch Not Found(小飼弾) - ニコニコチャンネル:社会・言論” http://t.co/qydQ2OJivT— Dan Kogai (@dankogai) May 31, 2014
2014-05-31T16:55:42+09:00
404 Blog Not Found
-
来た、観た、呆れた - 品評 - Google Chromecast
http://blog.livedoor.jp/dankogai/archives/51921776.html
Chromecast
Google
というわけで私も入手したのですが…
タイトルどうり。
タイトルの理由を知りたい方は、「続きを読む」を。
2014-05-30T17:00:44+09:00
404 Blog Not Found
-
[勉強会・セミナー][Java]JJUG CCC 2014 Springに参加してきました
http://d.hatena.ne.jp/ryoasai/20140519/1400512831
本日、日本Javaユーザーグループ(JJUG)主催のCCC 2014 SpringというJavaの勉強会に行ってきました。会場は、ベルサール西新宿で、都営大江戸線都庁前のA5出口を出て、新宿中央公園の5分くらい歩いたところにありました。今はスマートフォンで地図を確認しながら行けるので
2014-05-20T00:20:31+09:00
達人プログラマーを目指して
-
俺のサム伯父さんがこんなにマヌケなわけがない - 書評 - 暴露
http://blog.livedoor.jp/dankogai/archives/51920196.html
暴露
-スノーデンが私に託したファイル-
Glenn Greenwald /
田口俊樹・濱野大道・武藤陽生訳
[原著:No Place to Hide]
ここに書評を書くのは久しぶり。出版社より献本御礼。
これでますます信用できなくなった。
米国政府が?いや、Snowdenが。
2014-05-19T22:30:43+09:00
404 Blog Not Found
-
javascript - でiTunes Matchedなaacの出自を調べてみた
http://blog.livedoor.jp/dankogai/archives/51919493.html
左手のリハビリがてらに。
2014-05-14T13:00:29+09:00
404 Blog Not Found
-
[アーキテクトの仕事][仕事環境]開発チームにアーキテクトがいないなと感じてしまうような、残念なコードスメルの例
http://d.hatena.ne.jp/ryoasai/20140510/1399722742
まったく個人的なモチベーションの問題から、前回の最終更新から2年以上が経過してしまい、多くの読者のみなさんにはご心配をおかけいたしました。「プログラミングに関して調べたことや日々感じたことをメモとして残していきたいと思います。」というもともとの原点に立ち
2014-05-10T20:52:22+09:00
達人プログラマーを目指して
-
ブロマガ更新 - 404 SPAM Not Found #22 A Heartbleeding Story
http://blog.livedoor.jp/dankogai/archives/51917820.html
“404 SPAM Not Found #22 A Heartbleeding Story:404 SPAM Not Found:404ch Not Found(小飼弾) - ニコニコチャンネル:社会・言論” http://t.co/LzzpV6tFZq— Dan Kogai (@dankogai) April 30, 2014
2014-04-30T18:56:41+09:00
404 Blog Not Found
-
FreeBSD - Jailは仮想化ではなく半仮想化と呼ぶべきではないか
http://blog.livedoor.jp/dankogai/archives/51916648.html
もう10年以上看守していたオレが通りますよ。
FreeBSDを1,000台管理する方法(1)
後藤大地
Free bsd jail入門
勉強会聴講メモ 【第28回 #FreeBSD 勉強会 数千台のFreeBSD Jailホストを管理する技術、実務実践からのテクニック】 #FreeBSDStudy | しげはるblog
...
2014-04-21T16:30:15+09:00
404 Blog Not Found
-
書評 - The End of Poverty
http://blog.livedoor.jp/dankogai/archives/50770211.html
もっと早く読んでおくべきだった。
貧困の終焉
Jeffrey D. Sachs /
野中邦子・鈴木主税訳
[原著:The End of Poverty]
2007.02.22 初出
2014.04.06 邦訳文庫版上梓につき再掲
まだ読んでいない人は、原著でも邦訳でもいいので読んで欲しい。
2014-04-06T09:00:57+09:00
404 Blog Not Found
-
Introducing FoolBSD 4.1
http://blog.livedoor.jp/dankogai/archives/51914121.html
FreeBSDを1,000台管理する方法(1)
後藤大地
April Fool なので Fool Proof な OS を作りました。
Proof of Concept ではありますが。
2014-04-01T06:30:05+09:00
404 Blog Not Found
-
ブロマガ更新 - 404 SPAM Not Found #21 騙され上手になろう
http://blog.livedoor.jp/dankogai/archives/51913977.html
404 SPAM Not Found #21 騙され上手になろう http://t.co/kCoMwc7cZV #blomaga— Dan Kogai (@dankogai) March 30, 2014
2014-03-31T08:30:40+09:00
404 Blog Not Found
-
Unicode - perl+javascript - にプログラムでよく使われる英語の記号の読み方を調べさせる
http://blog.livedoor.jp/dankogai/archives/51913704.html
プログラマのための文字コード技術入門
矢野啓介
プログラマーたるもの、プログラムに出来ることを自らやるべからず。
挑戦者求む!【英語】英語でなんて読むか知ってる? by @masuidrive 増井 雄一郎│CodeIQプログラムでよく使われる英語の記号の読み方知ってい...
2014-03-29T00:00:01+09:00
404 Blog Not Found
-
Windowsという名の薄皮一枚
http://blog.livedoor.jp/dankogai/archives/51913215.html
Unixという考えかた
Mike Gancarz
/
芳尾 桂 訳
[原著: The Unix Philosophy]
寝込みうどんになりながらiPadで以下を読んだら熱がぶりかえしたので。
Macの良さがわからなすぎて、死にたい
MacがWindowsに勝る理由 ~Mac vs Windows宗教戦争の歴史をひもと...
2014-03-24T23:00:14+09:00
404 Blog Not Found
-
Tips - 静的リソースのURIに?をつけるべからず
http://blog.livedoor.jp/dankogai/archives/51911918.html
Webを支える技術
HTTP、URI、HTML、そしてREST
山本陽平
であればなおのことこの実装はNG。
ブラウザのキャッシュを利用できれば、余分なリクエストを減らすことができます。はてなブログでは、なるべく長い間ブラウザにキャッシュを保存するために、JavaScrip...
2014-03-14T20:00:15+09:00
404 Blog Not Found
-
些末なゴミは出所を問わず拾うのが客商売
http://blog.livedoor.jp/dankogai/archives/51911784.html
USJのジェットコースターはなぜ後ろ向きに走ったのか?
森岡毅
たとえ話を一つ。
些末なコードレビュー - naoyaのはてなダイアリーあるサービスの JavaScript が重いとか、そのコードが難読化されてないとか、担当者とおぼしき人間が書いたコメントがそのまま残ってるから...
2014-03-13T16:30:59+09:00
404 Blog Not Found
-
llevalに久しぶりに手を入れた
http://blog.livedoor.jp/dankogai/archives/51910930.html
サーバサイドJavaScriptNode.js入門
OSバージョンを上げたついでに、llevalにも手を入れたので変更点など。
lleval - run codes from your browser
2014-03-06T18:00:49+09:00
404 Blog Not Found
-
ブロマガ更新 - 404 SPAM Not Found #20 核心の問題
http://blog.livedoor.jp/dankogai/archives/51910175.html
404 SPAM Not Found #20 核心の問題 http://t.co/XeKvafeowL #blomaga— Dan Kogai (@dankogai) February 28, 2014
2014-02-28T21:00:20+09:00
404 Blog Not Found
-
A Brief History of Guts - 紹介 - 図解・内臓の進化
http://blog.livedoor.jp/dankogai/archives/51909226.html
図解・内臓の進化
岩堀修明
オビを書いたのでここでも紹介。
2014-02-21T16:30:35+09:00
404 Blog Not Found
-
備忘録 - FreeBSD 10 あれこれ
http://blog.livedoor.jp/dankogai/archives/51907188.html
この後無茶苦茶インストールしまくった。
FreeBSD 10.0-RELEASE Announcement
ので、気づいたことを。
2014-02-05T18:45:27+09:00
404 Blog Not Found
-
perl - func(tion()) considered harmful?
http://blog.livedoor.jp/dankogai/archives/51906737.html
初めてのPerl 第6版
Randal L. Schwartz /
Tom Phoenix /
brian d foy/
近藤嘉雪訳
[原著:Learning Perl, 6th ed.]
久々のPerlの話題です。
2014-02-02T17:15:32+09:00
404 Blog Not Found
-
ブロマガ更新 - 404 SPAM Not Found #19 俺の幹細胞がそんなにちょろいなわけがない
http://blog.livedoor.jp/dankogai/archives/51906488.html
404 SPAM Not Found #19 俺の幹細胞がそんなにちょろいなわけがない http://t.co/LpdFi48DgQ #blomaga— Dan Kogai (@dankogai) January 31, 2014
2014-01-31T15:00:50+09:00
404 Blog Not Found
-
ブロマガ#12より転載 - 日本の原子力に未来はあるか?
http://blog.livedoor.jp/dankogai/archives/51906277.html
「中卒」でもわかる科学入門
小飼弾
以下より記事を転載します。
404 SPAM Not Found #12 Not-So-Nice-to-Have:404 SPAM Not Found:404ch Not Found(小飼弾) - ニコニコチャンネル:社会・言論
2014-01-29T21:00:16+09:00
404 Blog Not Found
-
社会科学を真の科学に - 書評 - 偶然の科学
http://blog.livedoor.jp/dankogai/archives/51768020.html
偶然の科学
Duncan J. Watts/
青木創訳
[原著:Everything Is Obvious:*Once You Know the Answer]
出版社より献本御礼。
2012.01.26 初出
2013.01.12 文庫化につき更新。
本entryがオビに採用されております
あやうく騙されるところだった。
...
2014-01-12T16:30:40+09:00
404 Blog Not Found
-
Tips - iMac 27-inch, mid 2011 を回春してみた
http://blog.livedoor.jp/dankogai/archives/51903316.html
年末の大掃除とかは「なにそれ?」という感じで「本塚」はあいもかわらず成長しているのですが、その代わり2年半ものの iMac 27-inch, mid 2011 を回春したらびんびんになったので備忘録。
2014-01-06T15:45:10+09:00
404 Blog Not Found
-
続報 - Windows 8.1 & Miix 2 8
http://blog.livedoor.jp/dankogai/archives/51903074.html
Lenovo IdeaPad Miix2 8
新春早々、ごめんなさい。
404 Blog Not Found:Back to the Netbook - 品評 - Windows 8.1 & Miix 2 8「8インチWindowsタブレットいつ買うの?」今でしょ!
この台詞、撤回します。
2014-01-04T16:00:57+09:00
404 Blog Not Found
-
ブロマガ更新 - 404 SPAM Not Found #18 器用貧乏
http://blog.livedoor.jp/dankogai/archives/51902634.html
404 SPAM Not Found #18 器用貧乏 http://t.co/5AGG7WTtpl #blomaga— Dan Kogai (@dankogai) December 31, 2013
2013-12-31T21:00:27+09:00
404 Blog Not Found
-
靖国神社に参拝することに賛成な方に、一つだけ質問
http://blog.livedoor.jp/dankogai/archives/51902241.html
あれ?
【産経抄】12月28日+(2/2ページ) - MSN産経ニュース米国はかけがえのない同盟国ではあるが、国のために命をささげた先人への感謝は譲れぬ一線である。心ある日本人が「嫌米」にならぬようケネディ駐日大使はぜひ、靖国神社にお参りいただきたい
その前に「お参...
2013-12-29T00:15:47+09:00
404 Blog Not Found
-
備忘録 - 仏の秘密も百度まで
http://blog.livedoor.jp/dankogai/archives/51902049.html
ちょw
また百度(baidu)が日本語入力ソフトの件でやってくれたようです(山本 一郎) - 個人 - Yahoo!ニュースこれには我らがダニーもお怒りです
私自身は、Baidu IME も Simeji も使っていないので怒る権利自体があるかどうかも疑問なのだけど、いい機会なのでちょっ...
2013-12-27T13:30:19+09:00
404 Blog Not Found
-
備忘録 - MacでWindowsを使うには
http://blog.livedoor.jp/dankogai/archives/51901837.html
マックとウィンドウズ 2013[共存・共有]
~避けきれない事態とその解決策~
え?
Windows使ってるやつは仕事できないバカ - Togetterまとめ
それってAppleもバカってことですか?
2013-12-25T22:30:52+09:00
404 Blog Not Found
-
Back to the Netbook - 品評 - Windows 8.1 & Miix 2 8
http://blog.livedoor.jp/dankogai/archives/51901149.html
Lenovo IdeaPad Miix2 8
うちにも届いたので。
「8インチWindowsタブレットいつ買うの?」今でしょ!
「これさえあれば、何もいらない」?そんなわけないでしょ!
2013-12-20T16:15:49+09:00
404 Blog Not Found
-
パンドラの箱 - 書評 - コンテナ物語
http://blog.livedoor.jp/dankogai/archives/50987910.html
404 Blog Not Found:コンテナーという革命を読んだ日経BPの黒沢様より献本御礼。
コンテナ物語
Marc Levinson /
村井章子訳
[原著:The Box]
2008.01.20 初出
2013.12.17 Kindle化にともない更新
スゴ本。ものを作る人も運ぶ人もそして買う人も一読してお...
2013-12-17T15:45:19+09:00
404 Blog Not Found
-
訃報 - Nelson Mandela, 1918-2013
http://blog.livedoor.jp/dankogai/archives/51899370.html
嗚呼。
Message from The Nelson Mandela Foundation, The Nelson Mandela Children’s Fund and The Mandela Rhodes FoundationIt is with the deepest regret that we have learned of the passing of our founder, Nelson Rolihlahla Mandela – Madiba. The Presidenc...
2013-12-06T13:30:43+09:00
404 Blog Not Found
-
ブロマガ更新 - 404 SPAM Not Found #17 一目不瞭然
http://blog.livedoor.jp/dankogai/archives/51898616.html
“404 SPAM Not Found #17 一目不瞭然:404 SPAM Not Found:404ch Not Found(小飼弾) - ニコニコチャンネル:社会・言論” http://t.co/uGoDjxfgsI— Dan Kogai (@dankogai) November 30, 2013
2013-11-30T15:30:00+09:00
404 Blog Not Found
-
品評 - VE-GDW03DL & スマートフォンコネクト for GDW03
http://blog.livedoor.jp/dankogai/archives/51898227.html
VE-GDW03DL-W
Panasonic
我が家のコードレス電話機がほとんど寿命を迎えていたので、渡りに船とばかり入手。
2013-11-27T23:30:19+09:00
404 Blog Not Found
-
iPhone 5c がいまいち萌えないもう一つの理由
http://blog.livedoor.jp/dankogai/archives/51897403.html
「え、一部生産停止?」「そうは言っても他よりずっと売れてるでしょ!」とは言っても5sの方がずっと売れているのは確かなので。
2013-11-21T13:00:44+09:00
404 Blog Not Found
-
The (R|L)ightest - 品評 - iPad mini with Retina display
http://blog.livedoor.jp/dankogai/archives/51896581.html
来た、見るまでもなく、買った。
2013-11-15T12:00:37+09:00
404 Blog Not Found
-
For the Best Billion - 品評 - iPhone & iOS
http://blog.livedoor.jp/dankogai/archives/51895618.html
9月に出たのに何を今さら感があるけど法林先生のビデオが出たのだって昨日(2013.11.06)だし、ま、いっか。
2013-11-07T21:45:08+09:00
404 Blog Not Found
-
[英語学習][勉強会・セミナー][PGのキャリアーパス]アマゾンにおけるソフトウェア開発の仕事について感じたこと
http://d.hatena.ne.jp/ryoasai/20120422/1335101193
ちょうど、先日アマゾンのオープンハウスというイベントでお話をさせていただく機会があったのですが、開発者向けの20日のセクションだけで90名近くの方々にご参加いただきました。平日にもかかわらず、多数の方々にご参加いただき、どうもありがとうございました。 私自身
2012-04-22T22:26:33+09:00
達人プログラマーを目指して
-
[PGのキャリアーパス][IT業界]日本のユーザー企業は忍者のようなプログラマーをもっと登用して重用すべきでは
http://d.hatena.ne.jp/ryoasai/20120212/1329038962
あの記事から一年、ひがやすを氏が以下のエントリーで、プログラマーとして、新しいサービスを作ることの難しさについて書かれています。 僕と君とSIerの生きる道 - DJ HIGAYASUWO (元ひがやすを) 確かに私自身は、サービスを作る側に回った(まだISIDにいるけど、ベンチャー
2012-02-12T18:29:22+09:00
達人プログラマーを目指して
-
[IT業界]ソフトウェア技術者軽視のシステム開発を続けるのはもう限界かもしれない
http://d.hatena.ne.jp/ryoasai/20120125/1327501906
つい先日、富士通がグループで抱える3万人ものSEを再教育して、職務転換を行う計画であるというニュースを知りました。 富士通の3万人SE職務転換大作戦は成功するのか? - GoTheDistance 一つのシステムを複数の企業などが利用するクラウドサービスがこのまま普及すれば、顧
2012-01-25T23:31:46+09:00
達人プログラマーを目指して