日々の破片

_ スリー・ビルボーズ

妻に誘われてスリー・ビルボーズを観に行く。

全然内容を知らないまま観始めると（ビルボードトップなんちゃらの連想からショービズものだと思っていた）、タイトルのスリービルボーズの後ろにミズーリ州エビング外れ、というのがついているし、田舎道だし、運転しているのは険がある女性だし、ロードムービーか、それとも看板の近くにバグダッドカフェみたいな店があってそこで働く話か？ と思って見ていると、看板が三基出て来て、ビルボードって立て看のことかと初めて意味がわかった。女性は看板の広告会社をメモして去って行く。

その一方で、ショービズものという先入観から抜けきれないので、サーカスかショーの広告を出すのか、その看板の近くに小屋を立てるのかとみていくと、広告屋に入っていく。向かいが警察署なのが強調される。うん？ と思いながら見ていると看板の古さと裏腹に妙に若くて性格が良さそうな兄ちゃんが広告屋で、彼女が見せるコピーに対して、事件がどうのという話になる（もしかするとここで窓から見える向かいの警察署が強調されるのだったかな）。間抜けと貧乏人しか通らない道沿いの看板みたいなセリフが出てくる。

翌日、パトロール中の警官が看板を塗り替える作業に気づく。怒り出す。

警察署腐敗告発ものの映画なのか？ と思いながら見ていくと、微妙に異なるようだ。

ここでも、看板の立地について間抜けと貧乏人みたいな言葉が出てくるが、女性が住んでいるのはまさにその道沿いだ。

こちらは先入観で悪徳警察署の腐敗告発ものと思って見ているので、署長が犯人か、または警察署ぐるみで身内をかばっているのかな？ と思ってい観ている。やたらすさんだ警官が出てくるし、差別主義者なので、こいつか？ とか思う。

が、全然異なる方向に話が進む。というか、署長がやたらと良い人だったり。

映画というよりは、テレビみたいだと妻が終わった後言っていたが同感だ。やたらとBGMが流れるし、ときどき美しいシーンがあるが、たいていはバストショットやアップだ。

すべてを語るわけではないから、脚本は映画っぽい。

主役の警官が怒って飛び出してから新任の署長と顔を合わせるまでの一連の流れはブツ切れではあるが、きれいに流れて映画っぽかった。というように、ところどころ良い。

警官側の主役の母親がやたらと容疑者追い詰めに詳しいのと、父親の不幸に対するほのめかし、住んでいる家がわりと良い場所のようだとかから、父親は警部で殉職した（犯人は黒人）とかかな？ とか。

最後、エクスターミネーターコンビのロードムービーが始まりそうなところでおしまい。

とにかくストーリーの作り、脚本は映画（後から家族で話し合ってなるほどあれはそういう意味かみたいなものがお互いにあったりするくらいに、うまい。愚かな説明がほとんどない）だし、役者も悪くなく、一体どうなるのかという意味でのサスペンスもあり、それぞれの人物がそれぞれに背景を持っているし（というのも映画っぽい）、BGMがうるさいことを除けば良い映画だった。と思わなくもないが、やはりテレビっぽいな。細かなエピソードの入れ方（表現方法）がテレビっぽいのか（例：イヤホンでのっていると署内がざわついているのが見えるあたりとか。意外性と発見がなくて紋切り型なのだ）。

予告編では、空海（なのかな）が実はチェンカイコーのむちゃくちゃな活劇映画とわかって、観に行くことが確定した。

_ プログラマーとお仕事をするということ読了

翔泳社の野村さんからいただいた「プログラマーとお仕事をするということ」を通勤電車の中でちびちび読んでいて、大体1か月で読了（他の本読んだりしていたからで、すごく読むのに時間がかかるというわけではない）。

内容はソフトウェア開発プロジェクトをどうすれば成功させることができるのかを、筆者の経験と統計データ（脚注でそれぞれの数字の出典が示される）を組み合わせて説明したものだ。といっても、プロジェクト運営の話かというと相当違う。どちらかと言うと、ソフトウェア開発とは何か？ 何が問題点なのか？ についてヒューマンリソースという観点から説明したものだ。

すでにアマゾン評が3つ出ていて、星5、3、2と分かれていて、それを読むと、なぜこの本が成立するのかわかる。

星3の人の評。

プログラマーとして、どういう点に気をつけるべきなのかというモチベーションで読みました。

(略)

技術的な詳細について中途半端に（わかりにくい比喩で）触れていたり、全体的に文章が回りくどかったりして非常に読みにくいです。

(略)

プログラマーにとって、中途半端でわかりにくい比喩が書かれているそうだ。

この人、残念ながら、筆者の意図も主張もわかっていない。まさに、プログラマーにとって自明なことが（用語を使えば1発で理解できることが）プログラマー以外の誰にも理解できないことこそ問題の本質だ、というのが筆者の経験から得た観点であり主張であり（そして数的な裏付けがあること）なのだが、それを自分の口から証明してしまっている。

星5の人を見ると、

非プログラマーとして、プロマネの仕事をするようになって、かれこれ30年近い。

(略)

おう。

星2の人。

この本のターゲットは、プロジェクトリーダー、発注者、デザイナーなど、プログラマーに仕事を依頼したり管理したり協働する人たちのはずです。

したがって、プログラマーのことは、ブラックボックスとして記載すれば良いのに、ホワイトボックス、つまりプログラマーの中の事情をけっこう書いてしまっています。

(略)

いや、プログラマーをブラックボックスとして扱う（1か月にブラックボックスがコードを吐き出す量は何行だから、頭数何人で何か月でソフトウェアが完成するという発想）ことこそが本質的な問題だから、そもそもプログラマという人々がどういうことを脳内でやっていて、それがどう表現されて、何をすると不愉快にさせて、何をすると気持ちよく仕事してもらえるかを非プログラマがきちんと理解、把握（ただし技術的な詳細は無理なんだからそこはおもしろ話を使って）できるように解説した本なんだから、そもそも読み方が間違っているし、問題の本質を理解してないじゃん。

というわけで、5の人は正しく読んでいるし、正しく読めば星5となるのは（類書がないだけに）当然だ。

3の人は、わけわからん比喩こそが、自分の説明責任の範疇にあるのだなとびっくりして（＝認識をあらためて）出直すべきだし、2の人はさすがに読解力が無さすぎるから、そりゃうまくいかないだろうなぁ。

採用戦略（7章）、採用した人間の引き留め戦略（8章）、コミュニケーション戦略というかヒューマンマネジメントのための基礎情報（9章）は、プログラマ（おれおれ）が読んでもおもしろい（宗教戦争とか言語戦争とかフレームワークフレームウォーとかその帰結とか）。意外と明文化されることで、実はおれはこう考えていて、隣のやつはこう考えているのかという発見もあった。

特に非プログラマにとって重要なのは2章の「なぜソフトウェア開発は建築と似ていないのか」と4章の「彼らは一日中何をしているのか」（特に4章）、逆に言うと、もしプログラマで4章を読んで首肯できないとしたら、相当問題がある。正しくプログラミングをしていない可能性が高い。

プログラマーとお仕事をするということ(PatrickGleeson)

というわけでお勧めできる。

# アマゾン評でも指摘があるが読みやすさは万全ではない。おれの偏見かも知れないが、いかにもイギリス人っぽい、斜に構えた意地悪さ（というよりも辛辣さ）と皮肉がある。それは喉にささる小骨だから、コーラを飲むようにはいかない。パトリシアハイスミスとかシェークスピアとかオースティンとかサキとかに似ている。

_ Chromebookでクラウド開発

以前購入したHPのChrome Bookだが、次の点で重宝している。

・ちゃんとしたクラムシェルだからどういう使い方でもキーボードが打てる（横向きに寝転がっても、90度倒しても立つから使える）ので、寝台で使うのにもってこい

・全然発熱しないから腿の上に置いても、腹の上に置いても無問題。

（ここまではTwitterみたり、FBとか眺めたり、リンクたどりまくったり、PDF読んだりする普通の使い方）

それにさらに1点加わった。

croshというアプリケーションがあるのだが、こいつが実に良い。

Chrome Bookで普通何かしようとすると必ずChromeで動かすことになって、それはsshもそうなのだが（アドレスバーに、ssh://ユーザーID@ホスト名 を入れれば良い）、Chromeでsshしているととてつもなく使いにくい。bash使うわけじゃん。当然、^nを打つわけだ。あっというまに新しいウィンドウが開く。emacs使うわけじゃん。当然、^wを打つ。あっというまにすべてが消え去ってしまう。使えん！

が、croshは独自ウィンドウを持つアプリケーションなので、そんな問題は皆無。

ただ起動すると、crosh>というプロンプトが出て、これが使い物にならなくて、最初戸惑いまくる。

ssh 〜と打つと、sshはリムーブされたからofficial SSHをインストールしろというわけのわからないメッセージを出力して終わる。

helpと打つと、pingの説明が出て来る。

なんだこれ？

help_advancedと打つとすごい勢いで何かメッセージが流れていって、uptimeとvmstatととかしか見えない。パイプはないので、|moreも|lessもできない。

それで当てずっぽうでいろいろ打っているうちに、ついに見つけた。何を？

永遠を。太陽に溶け込む海を。

つまり、

shell

だ。

shellと打つと、bashに入れる。

そこで、ssh が使える。

sshが使えれば、アカウントがあればどこにでも入れる。Chromeと違って余分なことはしないので、^nも^wも問題なし。

Shift-Ctrl-Nでウィンドウも複数開けるし。

日本語入力については最初サーバー側にSKKを入れていたが、そんなことしなくてもクライアント側のGoogle IMEでも日本語入力ができることに後から気づいた。もっともGoogle IMEよりはSKKのほうが変換効率がはるかに良いから（念のため、おれはSKK原理主義者ではないから、WindowsではMSのIMEを使う（Vistaは除く）。あくまでもGoogle IMEがだめなだけだ。ただし日本語のコメントやコミットログやイシューを書くくらいならGoogle IMEでも問題ない。まともな日本語の文章を書くには語彙が貧弱過ぎるということだ）どちらにしてもSKKを入れることは問題なかった。

で、当然だがChromeは動くから、Webアプリケーションをインタラクティブにプログラミングするには必要にして十分な環境が得られるわけだ（要は端末として速度も機能も必要十分以上ということ）。

もっとも最初、F12が無くて愕然としたが、Ctrl-Shift-Iを見つけたので、これも無問題だった（良くみたら右端のメニューアイテムからもその他ツール−デベロッパーツールで呼び出せることに後で気づいた）。

というわけで、Chrome Bookは相当良い。

HP Chromebook 11 G3 Chrome OS(日本語版) Celeron 2.16-2.41GHz 4GB SSD(eMMC)16GB 光学ドライブ非搭載 無線LAN 802.11ac/a/b/g/n Bluetooth USB3.0 HDMI 720pHDwebカメラ SDカードスロット 11.6型ワイド液晶搭載ノートパソコン グローバルワランティモデル 重さ約1.28kg バッテリー駆動時間最大約8時間(-)

_ Apache2とUnicornをUnix Domainソケットで直結

balancerをかます例や、nginxとUnicornの直結、Apache2-nginx-Unicorn（を同一マシン）、Apache2-UnicornをHTTPはすぐに見つかるのだが、Apache2とUnicornをUnix Domain socket直結の例が見つからなくて閉口して、えらく時間を食った。

というわけでメモ。

なお、Apacheは、2.4.10以上を使っている。

Unicornは、config/unicorn.rbにふつうに書く。

Apacheのconfは仮想ホストなどは他のドキュメントを参照するとして（というのは、そのあたりは普通だからだ）、重要なのは

unixドメインは通常:の直後にパスを書くので、unix:/var...とするが、mod_proxyがabsolute pathを要求するので、unix:///var...と書く必要がある（ここで時間を食いまくる）。と思ったら、"unix:/var..."でもちゃんと動くじゃん。すべてはパイプの後ろの問題だったのか……(unix:///でも動く)。

次に、Unix Domainソケットにトンネルさせるプロトコルをパイプでつないで指定する。ホスト名以下はダミーで記述が必要。

（ここで、fcgiだと思い込んで、さらに余分な時間を食った。というか、最初からhttp://で書いていれば///とか回り道をせずに済んだようだ。うー）

_ 独習C

翔泳社から独習Cを上梓しました。

翔泳社の独習シリーズは数年前までは海外の定番書の翻訳だったわけですが、ここ数年は日本の著者による書下ろしに移行していて、いよいよCの番となり、光栄なことに僕に声がかかったという次第です。

正気に正直に言って、Cの入門書としては素晴らしいできの、Cを学習するなら、これしかないものを作ったつもりです。

とは言え、何しろCなので、つまりは常識的に考えて死すべき言語筆頭なわけですよ。したがって声がかかったからといって当然のように即答とはいかないわけで、書き方と切り口をどうするかは大問題。

数年前はC死ねと思っていました(今も思ってます)が、へんな言語でみんな苦しんでいるという意味では近年ではObjective CとJavaScriptの死ね度の急上昇には注目したい。人類のために今滅ぼすべき言語としてはそちらのほうが優先されても良いと思います。

— Urabe, Shyouhei (@shyouhei) 2014年5月1日

（2014年には死すべき言語筆頭の座を明け渡したとは言え、それはすでに死語になりかけていたからと言えなくもない）

しかも、Webプログラマー用というわけではないので環境の軸足をmacとするわけにもいかないわけだ。でも当然、CL.exeというわけにはいかない（最初からC11というのは企画の基本方針となっていた）。というか、Windowsでmingwとかcygwinだったらさすがに引き受けない。

ところが幸か不幸かClang/C2がリリースされているわけで、つまりはそういう時宜を得ていたということだ。

clangを使ってC11（実質はC99、可変長配列あり）、今は21世紀とくれば執筆方針は明確だ。

x64、x86、ARMといった具体的なCPUはおいておくとしても、箱だの何だのの意味ない抽象化モデルは使わない。代わりにCPUとバスとメモリを単純化したモデル（キャッシュとレジスタは存在しないこととする）を操作するための言語として扱うことだ。

したがって、変数とはメモリ上の位置、型とは変数用に確保するバイト数と中身のビット構成の扱い方、つまりは整数型の違いは確保するバイト数の大小（stdint.hベースでint8_tとか使うのでビット数）、浮動小数点数については指数部、仮数部、符号という構成を示し、ポインタはアドレスを格納したもので押し通す。

その一方で、今、Cを学習するということの理由には、20世紀に作成された名作（駄作もあるとは思うが）を鑑賞するために必要な読解力をつけるという意味があるはずなので、%dのような古い書き方や、do while(0)マクロのようなイディオムについての説明はくそまじめにする。ただし、非ASCIIコードについてはUTF-8とワイド文字以外はすべて単なる多バイト文字としてほぼ無視する。

の、2本柱とする。

ポインターの説明が終わるまでは、しつこく同じことを説明して（上で書いた単純なノイマン型コンピュータ）モデルの形成を助ける。

そのあとは、スタック（と言う言葉は最後まで使わなかった）と再帰対制御文とループ、構造体とポインタをくどくど書く。（しつこく、とか、くどくどというのは練習問題があるからなわけだ）

独習C 新版(arton)

書籍購入者用の特典PDFというのがあって、いろいろ案を作ったが、最終的にすごくハイコンテキストな内容にしたのは、おそらく特典執筆直前に読んだ「もうすぐ絶滅するという開かれたウェブについて 続・情報共有の未来」の影響だと思う。そのくらいあの特典（ボーナストラック）はすごかった。

・サンプルと練習問題のバグ出しや動作チェックのヘルプをしてくださった村上さん、編集の宮腰さんと川月さんには、相当な行きつ戻りつにお付き合いしていただけて感謝しています。

_ Ruby25周年パーティ

品川でRuby25周年パーティ。

Javaはうんことか、おれってすげー感のkitajさんとあいさつしたり、Rubyできめると気持ち良いの松田さんの講演を聞いたりして、考えた。

今は、仕事でC#とJavaScriptとCoffee（注）とRubyを使ってプログラムをしているのだが、JavaScript以外はどれもそれなりに気分良い。気分良いが、確かにRubyのほうが何か良い感触がある。

それが、おそらくkitajさんや松田さんの発言に通じるのではなかろうか。

注）ES6という意見はさんざん食らっているがというか今日も食らったが、

1)Railsが作る（おれは松田さんではないので、gemがインストールするRailsがRailsだ）assets/javascriptsの下のファイルがCoffeeなので拡張子変えるのは面倒なのでCoffee一択。

2)ES6ったってBabelがいるんでしょ？ どっちにしたってトランスクリプトじゃん。だったら黙っていてもトランスパイラが自動で走るCoffeeのほうが100倍ましだ。というか3年後のこた知らね（どうせUI回り言語なんだから必要なら書き直す。というか同じUIがもつはずないじゃん）

というわけで基本はCoffeeだ。

で、打鍵数に由来する集中力の維持時間が関係するのではないかと考えた。

書き始めれば相当深く潜るのだが、当然、ある程度きりが良いところになれば、海上に上がってきて呼吸をするのだが、その期間が微妙に適切なように感じる。だいたい、20分から30分というところで、意識していないのだが、ポモドーロっぽい単位に思える。

Coffeeはもっと早いし（きりはわりと悪い）、C#は2時間くらい潜っていることがある（Emacsよりも微妙にVS2007のほうがレスポンスが鈍いという点もありそうだ）。

おそらく時間的および打鍵数的にきりが良いコード単位（クラス、メソッドとか）、調べなければならないメソッド引数とかを含めて、こちらの設計粒度と、ライブラリが提供するメソッドの粒度のバランスが良いように感じる（というか、感じでしかないことを書いているのだ）。

打鍵数（または応答速度）からはRubyのC由来のメソッド名は相当適切に思える。C#は長すぎる（補完速度を含めてもタイムラグがある）。これがJavaだとNetBeansもAndroidStudioも、ましてやEclipseは遅すぎて話にならないから、それが不快感になるのだろう（記憶している限りはEmacsでそれなりの速度で打ち込めるからそれほど不快ではないのだが、いかんせん長すぎるものが多いし、あと意味ないtry/catchの記述の必要性が今度は出てくるので、それが辛いのだな）。

まあ、速度の問題だから、人それぞれではある。

アジャイルな時間管理術 ポモドーロテクニック入門(Staffan Noeteberg)

(これ、実に良い本だなぁ。影響受けまくっていると言わざるを得ない)

_ 未来のイノベーターはどう育つのか読了

どうして買ったのか記憶にないが、Kindle積読シリーズ解消のため読んだ。なんか1か月近くかかった。

一昔前の本なので最後の記述は2015年で、主たる内容は2011年だから、また状況は変わっているかも知れない。

読んでいていろいろ驚く（知らなくて、あるいはこちらが知っているつもりのこととかけ離れていて）ことが多い。

アメリカ合衆国の話なのだが、基本的に

・高校は大学受験のための準備で勉強はカリキュラムでがちがち（底辺校に入ると荒廃していて勉強どころではない）

・大学の先生は教えることには興味がないので暗記主体。

・受験のためには暗記重要。と同時に良い大学に入るためには習い事重要（習い事と勉強で子供を締め上げる両親はタイガーマザーとかヘリコプターペアレントと呼ばれて、風潮としてはそうあるべきだとされているが、筆者はそれではだめだと考えている）

・小学校、中学校もカリキュラムでがちがちなので暗記主体

これでは創造力なんてつくはずありませんね、やれやれ、というのが基調となっていて、それはどの国の日本だ（ゆとり教育前かも知れないが）？ 状態で読むことになる。

そうはいっても、それではまずいと考える人はいるし、子供もいる。

理系から5人、文系から3人の20代（19歳くらいもいたかも）のイノベーターの卵を紹介して、両親、生育環境、小中高、大学、教師、インターンのリーダーといった連中のインタビューの記録が主な内容だ。

翻訳の問題ではなく、あからさまに、理系と文系という区別をしている。（STEM対リベラルアーツではあるが、内容、観点、社会的意義のすべてにおいて、日本での理系、文系と相似だ）。靴デザイナーの卵が理系に組み込まれていること、文系のイノベーターはNGOがゴールっぽいところが日本とは異なる点ではある。

読んでいて、はて、なぜおれはこの本を読んでいるのか？ という自問自答に悩まされる。そのため、途中で何度も読むのやめようと考えるのだが、なにか魅了されるものがあるのだ。

で、それは筆者のあとがきで理解できた。

とにかくあとがきの危機意識、目的意識、（アメリカ3億人の中のごくごく少数のイノベーターに対する）揺るぎない信頼と、（アメリカ3億人の中の数1000人くらいはいるはずのイノベーターを目指す若者に対して）真摯に呼びかけたいことが、筆者にはあるからだ。

どう読もうが本体は親や教師や役人に向けて書いているとしか思えぬのだが、あとがきでは、実際の読者として想定しているのは、イノベーターたらんとして本書を手にした（つまり、イノベーション教育を受けることができていない不遇な）若者だということが、明示される。

その構造が見えたとたんに、それまでのうんざりが雲霧消散して、深い感動が訪れた。

恐るべしアメリカ。

未来のイノベーターはどう育つのか――子供の可能性を伸ばすもの・つぶすもの(トニー ワグナー)