2014年のふりかえり

今年は、年末年始に仕事がないので、あれやこれやと考え事をしている。飲んでる合間に。

昨年の大晦日に、

来年の抱負として具体的な活動に帰着させられるものはない。大きな指針として、より多くのことをやめ、より多くのものを捨てようとしている。

と書いてある。こういうぼんやりした指針を立てると、ぼんやりした結果になる。体重を減らしたり、基本的にコードを書かない職務についた、社外の人と話す機会が増えた、外側から見るとチラリと変化があった程度か。

昨年も思ってたんだけど、明確に新しい技能を身につけていなくて、焦っている。コードを書く仕事から、書かない仕事になったので、変化はあるんだけれど、自覚的に技能を獲得していない。知覚できていないのか、できてないだけなのか。

ぐずぐずもぞもぞしていたなぁという1年だった。いや、もちろん自分なりに、もぞもぞしながら前進はしたんだけれど、 「YAMAGUCHI::weblogの2014年を振り返る」みたいなのを読むと、あーなるほどなぁ、こういうところで差が出るんだろうなぁ、やっぱりあんたすげーよ、と感じる。

あんまり自省ばっかりしてると、湿っぽくなるので、いいことも書いておこう。コードを書かない縛りってことは、いざとなったら自力で（番組本番数時間前に、ある PaaS が変更コードのデプロイを受け付けなくなったので、別の PaaS/IaaS にやっつけで移植するみたいな）解決ができない、ということだ。自分が SPOF にならないプロダクトや開発プロセスになるようにした。これまではほんと属人的であったなぁと気づいた。

テレビ連動サービス開発の勉強会が、なにやら人気で嬉しい。飲み会の幹事もできない自分が企画して、いまのところ反響がよいのは嬉しい。あと2週間、残りのタスクをこなしていこう。

と、気分がいい流れもあるので、来年は流れに乗りつつ、舵を切って行こうかなぁなどと考えている。

さて、なんとなくまとまってきたので、飲み納めをしようと近所の居酒屋に電話したら「こちらで予約いれておきましたので、来店時刻だけ教えてください」と言われた。何を言っているのか分からねぇと思うが、とりあえず飲みに行こうと思う。

なんで話しかけられてるのか、知りたい

ここ数日、お疲れさまですでチャットを始めることの是非について、ブログや SNS 投稿が目についた。元の記事の意図と、受け取られ方がずれているような気がした。と、続けるように見せかけて、ここからは仕事のチャットで気をつけていること/相手に期待していることを書いてみる。元記事やその反応とは、あまり関係ない。

予防線を張っておくと、できてないことも書いてある。でも気をつけています、というスタンスです。と逃げておく。

基本的に「あなたが始めた情報伝達セッションのコストは、あなたが負担して欲しい。」と思っている。

話しかけられた時に、で、私はどうしたらいいの、というのがすぐに分からないと、ちょっとストレスになるからだ。会話を始めたほうが、ある程度のコストを負担して欲しい（もちろん、こっちの非で相手にコミュニケーションさせてる場合とか、例外はある。）。

たとえば、チャットで呼びかけられて、こっちらが返事するまで待たれるのは、たしかにちょっとストレスだ。

@ぶちょー

とか

お疲れさまです^^

とか言われた後、こっちから返事をするまで、何も書いてくれないのはちょっとストレスだ。呼びかけられたときだけ通知するようにしているので、次の文章がいつ来るかをときどきチャットアプリを見ないといけない。

それよりも、

@ぶちょー、〇〇の仕様で確認したい。

って言ってくれれば、受け取った側が「何を期待されているのか？ 次のアクションは何か？ そうすることに価値があるのか？」が分かる。

もし目上だからなどの理由で、気遣いをしてくれるなら

お疲れさまです。見積の確認をお願いしてよいですか？

と、一発で聞いてほしいとは思う。

いきなり今いいか？だけ聞いてこられるのも苦手だ。返事をしたら、相手をすることが期待されてる。用件を書いておいてくれたら、あるいは、メールや社内共有できるところに書いておいてくれたら、あとで返事できるのに。

むかーしむかし、女性の同僚に、週末空いてるかと聞かれたことがあります。そりゃあ、空いてるって答えるわけですよ。だが...

「今週末あいてる？」
「空いてますよ（wktk）」
「たまった仕事手伝ってください」
「（しまった…）」

わざと、なんだろうけど。

チャットも同じで、

@ぶちょー、今いいですか？

って聞かれても。それ大事だけど、後にしてよとかある。なので、なんの用事なのか、何を期待されているのかを知りたい。だから、相手にも知らせるように努めている。

田村耕太郎「頭に来てもアホとは戦うな」 〜 最優先事項を最優先する

イラッとしていることが顔や文章に出やすい。もちろん問題だとは思っている。

というわけで、田村耕太郎「頭に来てもアホとは戦うな」を読んだ。他人を見下す「アホ」という言葉が使われ、この本の中でもそういうニュアンスで使われている。けれど、後半に読み進めるにしたがって、アホへの対応というのが本質的な問題ではないことが説かれていく。

最優先事項を最優先しろよ、ということである。自分の正しさを証明したり、自分の優秀さを認めさせたりすることを優先させると、目標の達成から遠ざかるということだ。最優先事項である目標の達成のためなら、相手の矛盾を見逃す、非がなくても頭を下げる、権力にすり寄る、一時的に手柄を誰かに渡すということも、手段のひとつになり得る、と考えればよいのだ。

当たり前だろって人には、この本は既出すぎる。ピンとこない人には、もしかしたら新しい視点を提供してくれるかも知れない。

平等なマネジメント、公平なマネジメント

1分間ナントカシリーズ、タイトルが胡散臭いと思ってたのだけれど、どっかのブログで高評価だったので、ブランチャードらの「1分間リーダーシップ」を買った。結論から言うと、学びがあった。

ばらつきが課題

前提として、私は4人のソフトウェア開発者がいるチームの、開発プロジェクト管理をしている。要件を定義したり、工数から考えてどの順序で作るかを決めたり、そういうことをしている。開発者は私の部下ではないけれど、この本では部下と書いてあるので、部下という言葉を使う。

開発者によって得意分野、習熟度、問題解決、コミュニケーションにばらつきがある。

部下のステージに合わせたマネジメント

この本で提案する方法では「部下がとりくむ分野におけるステージを分ける。ステージごとに異なる指示と援助のしかたをする。そのためには、業務ごとの目標を明確にする必要がある。」というものだ。

異なる特性を持つ部下に対して、異なるアプローチをとることは、決して不当ではないという。ちょっとまえに、equality と equity の違いが SNS に流れてきたけれど、そういう感じだ。さっきまで、異なるアプローチをとるのは不公平だと思っていた。だが自分が部下だったら、それを気にするかっていうと、何が起こっているかわかっていれば、気にしない。そのためにも業務ごとの目標を明確にし、アプローチを取り決める必要がある。

業務ごと、というのは、部下がやっている仕事が複数あるときに、業務ごとに部下のステージが異なるからだ。

明日から

すでにチームの慣性があるので、コロコロやりかたを変えてしまうと却って、開発者の迷惑になるかも知れない。だいたい部下じゃないしなぁ。

宝くじが魅力的にみえるとき

電車の吊り広告を眺めていたら、宝くじが魅力的に見えた。「何億円当たるかも知れないんだったら、買ってみようかな」と認識してしまったのだ。ROI が100%を明らかに下回っているのに、である。そして、宝くじが魅力的にみえるのは、よりよい投資ができないからだ、と気づいた。

宝くじはビジネスとしてのギャンブルなので、期待値は低い。胴元の利益が、コストに含まれるからだ。ROI （投資対効果）は 1 を下回る。だいたい 50 %というところか。300 円払って、平均して 150 円返ってくる。

他の投資、たとえば読書はどの程度の ROI なのだろう。2000円の本を1冊買って読んだ結果、給料があがるだろうか。期待値どのくらいだろう。1%の確率で、月給が1000円アップ？ 年間の期待値は 1% x 1000円 x 12ヶ月 = 600円。ROI = 120/2000 = 6%。給料が上がったら1年だけじゃなくてもうちょい続くけど 10〜20% ってところか。

宝くじの ROI のほうがよい。本でも、講習会でも、飲み歩きでもなんでもいいけど、宝くじよりもROIがよくないと、投資として認識できない気がする。惰性の読書を投資と呼ぶのは、実は欺瞞なのかも知れない。サイタ×サイタ の Kindle 版が出たら、消費として買うんだけど。早く出ないかなぁ。

えっ 私の知識少なすぎ！？

えっ 私の知識少なすぎ！？

最近、自分が持っているデータ量、情報量、知識量が少ないせいで、困ることが多くなってきた。以前から困ってたんだろうけど、気づかなかっただけかも知れない。とりあえず情報量と呼ぶ。データとはとか、知識はとか、そういうレベルの高い話ではない。

アンテナを張っていないのが直接的な原因なのだけえど、単純に情報を集め始めると、その処理に時間がかかって、アウトプットできなくなるのが目に見えている。今の状態で、単純にあふれているのだ。

たとえば RSS フィードを通勤中に消化している。このとき、気分によって（たいてい悪い）英語の記事を飛ばす。あるいは、ちょっとだけ読んで、Evernote の後で読むノートブックにクリップする。帰りにはそれを読んでいく。けど、疲れているので英語は飛ばす。音声プレゼンも飛ばす。詳しくないジャンルの文章も飛ばす。そうやって、たまりにたまった不案内なジャンルの記事がたまる。1ヶ月くらいたって「だめだ、とても読めない。Archive フォルダに移そう」となる。

体力ないやつが、急に走り始めるとこける

なぜこうなるかというと、

1. 自分にとって新しいことをやっているため、新ジャンルでの情報の処理に時間がかかっている
2. 自分は同じ所にいるが、ものすごい勢いで情報の流量が増えている
3. 自分がものすごい勢いで衰えている

1 なら前向きだけど、3ならなかなかつらい。おそらくは、程度の差こそあれ1〜3すべてが起こっている。

いずれにしても、自分を中心に考えた場合には、自分の処理能力が情報流量に追いついていない、というだけのことだ。選別する能力も含めて。

まずはウォーキングから

うっかり根性だけで対応したくなるけど、それはかなり筋が悪い。なんせ衰えているのだ。「最近、走るのが遅くなったなぁ。よし長時間はしろう」とか無理なので。体力がなくなってるんだから。

体系だった知識を仕入れる時間（つまり勉強する時間）と、流して情報を仕入れる時間を意識的に持ってみよう。

• Feedly のRSS を選別する。
• 座ってゆっくり読む/考える/手を動かす時間を作る。

自分が不案内なことを意図的に取り入れるとか、配分とか、そういう難しいことは、もっと先に考えようそうしよう。

人生の8割は show

最近、仕事に行くのが苦痛で、ぐずぐずベッドから出ないとか、そんなことばっかりやってる。どうせ出社しないといけないのに、だ。

RunKeeper のブログに「What I wish I knew about motivation when I started running」という記事があった。

As Woody Allen famously said, “80 percent of success is showing up.” And this rings true for running, too.

ジョギングの大事なことは、とにかくまずジョギングすること。距離よりも何よりも。というのは、よく言われる。

ウッディ・アレンの、この引用をよく見かけるけど、本当のところはどうなのだと調べてみた。本人が言及しているインタビュー記事「Woody Allen Interview」が見つかった。

I made the statement years ago which is often quoted that 80 percent of life is showing up. People used to always say to me that they wanted to write a play, they wanted to write a movie, they wanted to write a novel, and the couple of people that did it were 80 percent of the way to having something happen. All the other people struck out without ever getting that pack. 

（人生の80%は show up することにある、って引用されてるんだけど、何年も前にそう言った。演劇を書きたい、映画の脚本を書きたい、小説を書きたいって言う人がたくさんいた。その中の数人だけが書きあげ、何かが起こすまでの80%を進んだことになる。他の人達は、一塁に出る前に三振してる。

これって、プログラミングでも同じだ。「プログラミングできるようになりたいんです」「ほうほう、おじさんに見せてみなさい」「 いえまだ書いてません」

show up は姿をあらわすとか、居るべき場所に出向く、みたいな意味なのだろうけれど、何か書いたり作ったりする場合は、ジョギングより show up のステップが大きい。expose （見えるように外に出す/アウトプットする）に近い。

村上春樹が、1日のうち何時から何時までは小説を書く時間を決めて、その時間は執筆しかしない、筆が進まなくても他のことをしない、みたいなこと書いてたような気がする。違う作家かもしれない。

そんなわけで、まず小さなステップでもいいからやろう、みたいなことを書こうとしたわけだ。だが「とりあえず10分やるのがいい 」ってエントリを過去に書いていて、いつの間にかやらなくなっててびびる。

締め切りを延ばしたとき起こること

「締め切りを延ばすと、こういうことが起こってるのだ」という記事を見つけた。

Here’s What Really Happens When You Extend a Deadline

最初に言っておくが、私は締め切りを延ばしたがる。締め切りを延ばすためなら、どんな努力も厭わないくらい延ばしたがる。世界トップクラスの先延ばし屋たる私に、何が起こっているのかが分かるのなら、と読んだわけだ。治せるものなら、治してみよ。

1. 心理的に、ゴールまでの距離とモチベーションは反比例する。したがって締め切りを延ばすと、やる気がなくなるのである。だめじゃん。
2. プレッシャーがあるほうが成果が出る、というのは欺瞞だ。私はプレッシャーがだるいので、そうは思ってない。この記事ではプレッシャーがあると成果が出るんじゃなくて、プレッシャーがないとやらないってだけだろと、ぶった切っている。
3. 直感による見積というのはアテにならない。楽観的なシナリオに頼ったり、途中の細かい作業を見落としたり。しょっちゅうだ。

モチベーションとプレッシャーをコントールし、見積もりの精度を上げることで、物事を成し遂げられる（確率が高くなる）ということだ。

この記事には、解決策まで書かれている。まず、中間目標を設定することで、適切なモチベーションとプレッシャーを確保する。ただし、中間目標の締め切りにはちゃんと意味付けが必要だ。延ばしても大丈夫な締め切りなんてものは、この文脈での締め切りの意味をなさない。

それから、過去の似たような仕事にどれだけ時間がかかったか、うまくいかないシナリオ、中間ステップを考慮して計画することで、見積の精度を上げる。

文章だけ読んでるとあたりまえのことだけれど、知っていることと実行することは全く別である、ということを思い知らされる。というわけで、まずは冷蔵庫の前まで移動し、次にビールを飲むことにする。過去の経験から、その後のことは予測不可能なので、あえて計画しない。

一分間マネージャー 〜 ピストルよりもサル

「一分間マネージャーの時間管理」という本を読んだ。やるべきことを、やるべき人がするための考え方が書かれている。次にやるべきことを「サル」と比喩し、サルの世話（次の対応の実行）と、監視（進捗の確認）が必要だと考える。もしも、部下の仕事を引き受けてしまったら、部下の仕事を自分がやり、その監視を部下がする（「あの件、どうなりました？」）ことになる。



私は誰かの上司ではないし、部下もいない。ただ現在進行中のプロジェクトにおいて「自分でプロダクトを作ってはならない」という制約がある。ソフトウェア開発の文脈では分かりにくいかも知れないけれど、ディレクションという役割だ。全体の物量が多いのと、ビジネスレイヤへの説明や打ち合わせが多いので、そもそも自分で全部作れない。

そこで問題がある。指示を出すことが苦手だ。文句を言われても言い返せないし、なんかもう、じゃあもう自分でやるよ、という気分になる。

「〇〇が苦手」というのには2種類ある。ひとつは、才能であれ技能であれ、現時点で何かをする能力が足りていない場合。たとえば、英語の聞き取りが苦手などがそうだ。もうひとつは、心理的にそれをするのがイヤな場合。前者か後者かを見分けるのは、比較的簡単だ。「こめかみにピストルを突きつけられたら、〇〇するか？」と問えばよい。

ここで言うところの私の「人に指示を出すことが苦手」は後者だ。もちろん下手だから伝わらないとか、適切に伝える用意ができていないとか、あるけれど、問題にしているのはそんなレベルではない。「えー」とか「この間と言ってることが違う」とか言われるのがイヤなのだ。忙しそうなのにタスクを追加して困った顔をされるのが嫌なのだ。

これまで、他人に何かをするように伝える、という訓練をしてこなかった。ただ、私より上の立場の人には、それができるように見えることが多い、ということも自覚している。年齢も影響しているかも知れない。

小学校で学級委員になると、欠席/保健室常連になる。中学校の部活で部長になってしまったらサボり始める。アルバイト先で後輩ができると辞める。管理職っぽいポジションへの昇格を察知して、転職する。など。

上司の見る目がないのだろうけど、まあ、それは置いておこう。未来の雇用主が読んだら、雇ってくれないかも知れないけど、まあ、それも一旦おいとこう。いまクビ切られても困るし、別に次のアテもない。自分よりできる人だけを採用した結果、開発者の代わりができない。

そこで、サルの比喩だ。開発者のサルの面倒をみて、開発者に監視をさせてしまう、という状況は、どう考えてもおかしい。組織が想定している責任と権限を、私が持っていないということに、やっと気づいた。なぜ気づかなかったのか。昔の上司、部活の顧問の先生、アルバイト先の社員、担任教師、これまで気づかなくてさーせん。

明日になったら「やっぱり人間と話すのは嫌です」と泣き言を垂れ流すかもしれない。けど、ピストルよりもサルのほうが、精神衛生上よいし、まともな成果が出る気がする。

知っていることを全部話したくなる症候群

何年も前のことだけれど「お客さんが、製品の話を聞きたいと言っているから、同席してくれ」と営業に言われたことがある。顧客の興味の範囲は大きくて、自社と他社のセンサから取得したデータをブラウザで閲覧できる、とかそんなのだったはずだ。普段なら要件を絞ってからにしてくれ、と言うところだけど、上得意だったのと、顧客が大雑把にしか考えてないっぽかったので、調べてから対応することにした。

さて、顧客と話してみると、準備した知識や情報のごく一部でできそうだったので、必要十分な情報と方法、質問への回答をした。打ち合わせ後「あれだけ時間をかけて準備してたのに、よくぞ喋らずにいられたな」と営業に言われた。

という話を思い出した。これだけだらだら書いておいてナニだけれど、必要以上に（あるいは不必要な）情報を提供する人はなんなんだろうと、ふと思ったのだ。ついさっき。

時間や労力をかけたとき、工夫をしたとき、話したくなる気持ちはすごく分かる。準備の課程で発見や発明があったらなおさらだ。私も冒頭で2段落も使って書いているわけだ。で、棚に上げるけど、「相手が知りたいこと、知るべきことなのか」には気をつけるようにしている。

外食に行って「今朝入荷した、新鮮な明石の真鯛を〇〇したカルパッチョです」くらいなら、ほほーって気分になる。けど、その真鯛を手に入れるためにどんな人脈をつかったか、〇〇するためにどれだけ苦労したか、今日はバイトが休んだから仕込みが大変だった、みたいな話をされるとげんなりするだろう。きいてねーし、付加価値ゼロだし、知りたかったらこっちが聞くし、って思う。

と思いながら、聞いていることがある。全部話したいのは分かる。だって知ってるんだし、知らないと思われたくないし。けど、汝は5分しか話してはならぬ、みたいな状況でもない限り、相手の質問に答えればいい。それよりも、相手にとって不要な情報を話すことによって「そんなこと関係ないだろ、こいつ分かってないだろ」と認識される方が、やっかいな気がする。話を真面目に聞いてもらえなくなりそうだからだ。

そんなわけで、よっぽどかこの文章を消そうと思ったんだけど、がんばって書いたので公開する。

※ 一応追記しておくと、その作業がどれだけ大変だったか、を伝える必要があるとき/伝えることに価値があるときは、なんとしてでも伝えるほうがよい。

クリエイティブ業界で働くべき理由、キャリア論

キャリアハックのインタビュー記事「エンジニアがクリエイティブ業界で働くべき最大の理由｜バスキュール 古川亨のキャリア論」が公開された。こういうところにも、ソフトウェア・エンジニアのポジションがあることを知ってもらえるといいなぁ、という思いでグダグダ話した内容を、記者の白石氏がきれいにまとめてくれた。

タイトルにある働くべき理由や、キャリア論が明示的ではないと指摘された。記事に興味を持った人に対して、続きはブログで、という位置づけで、この文章を書くことにした。

「一般的な問題解決方法と、技術的知識/技能を、自分自身の環境に合った組み合わせで習得/実践することで、エンジニアが提供できる価値が大きくなる領域が存在する。クリエティブ業界はそのひとつだ。」という立ち位置で、インタビューに答え、この文章を書いている。

主語は、私（のようなエンジニア）

人口百人以下の村役場に勤める二十三歳の出納係と、丸の内の外資系証券会社に勤める二十三歳のファンドマネージャーでは恋愛のあり方が違う。（村上龍「恋愛の格差」）

インタビューもこの文章も、主語は「私」だ。あるいは「私のようなエンジニア」だ。似た状況になっている人なら、ヒントになると思う。エンジニアリング自体が目的になっていない組織に雇用され、エンジニアチームが数人で、1-2ヶ月単位でプロジェクトが編成され、人命に関わるような製品ではなく、技術レベルでの仕様がしょっちゅう変更され、自分自身はスーパーハカーではないアラフォー、という状況だ。まったく同じ状況ではなくても、似たような状況や、似たような派生状況（テストだけに1ヶ月もかけられないなど）ならヒントになるだろう。

一方で似ていない状況だと、役に立たないだろう。エンジニアリング自体が目的の組織、ものすごく厳格な品質管理プロセス、継続的に同じチームが同じ製品を開発、長期のプロジェクト、などだ。

ワインバーグの言葉を借りると、問題とは希望と認識のギャップだ。希望と認識に依存するということは、人に依存するということだ。同じ現象であっても、観測者によって異なる問題が定義されることがある。このへんは「ライトついてますか？」あたりを読まれたし。

汎用的なスキルと、個別具体的なスキル

そういう人たちは、二つの点で誤解をしている。一つは、好きなことを見つけることは大してむずかしいことではないと思っている点で、二つ目は、好きなことをやる場合にはたいてい訓練された高度な技術が必要になるということだ。（村上龍「恋愛の格差」）

汎用的な問題解決スキルと、技術やビジネスの個別具体的な知識の両方が必要で、日々、更新していくことで、自分の価値を提供できるだろうと考えている。

汎用的な問題解決というのは、もれなくダブりなく問題のロジックツリーを描くだとか、原因と結果をきちんと分けて認識するだとか、仮説思考だとか、なぜなぜ5回だとか、そういうことだ。高い凝集度と低い結合度を維持するとかも、技術的ではあるが汎用的な知識だろう。汎用的な問題解決スキルがないと、たとえばある言語の仕様を知っていても、個別の知識やベストプラクティスをどう適用すべきかが分からないことがある。

一方で、具体的な知識や技能がなければ、現実的な時間で、問題の解決や、発見自体ができなくなる。HTMLとJavaScriptの知識なしで、ウェブアプリのレイアウト崩れを直すのは至難の業だ。

両方できるのがいいに決まっている。君も明日からフルスタックエンジニアだ、と言うのは簡単だ。けれど、両方ですごく高いレベルで習得するには時間がかかるだろう。状況によって適切なバランスも異なるので、次は何を学ぶか、に単一の回答はない。

おそらくは、日々、問題解決をして、細かい意思決定をしているはずだ。毎日でも毎週でもなんでもいいから、定期的に方法論と技術的知識と、あとは他のこと（穏やかに文句を言うスキルとか、おっぱいばっかり見て話さないとか）のどこが欠けていたのか、何を身につければいいのか、を繰り返していくことで、適切なスキルセットを構築していくしかない。

単一障害点を減らす

「自分一人で生活できる能力を持つこと」が自立だと仮定すると、リストラされたとたんに生活の基盤を失ってしまう人は果たして自立していると言えるのだろうか。（村上龍「恋愛の格差」）

"「作り方」を開発できること。たくさんの案件が同時に走った時、ゼロから全部つくっていたら死んでしまう。" http://t.co/ca2WBl5Ptj 実際話を聞きに行ったことあるけど、この辺凄く意識してる感じで、実際ものを持ってる。
— voluntas#1345 (@voluntas) 2014, 5月 20

記事には、コミュニケーションなしで開発を進める、というようなことを書いてある。関係者の仲が悪いという意味ではない。開発仮定における人的な単一障害点（Single Point of Failure / SPOF）を減らすために、そうなっている、ということだ。私が置かれている状況で発生する問題にたいする解決策のひとつだ。

とにかく仕様変更が発生する。「この仕様は変えないでください。事前に検討して決定してください」と言うことはできる。けれど変わる。もう少し上のレイヤでできることがあるだろうけれど、一朝一夕に変えることは（今の私には）できない。けれど作り方を工夫できる。

API やコンポーネントの設計をするとき、各担当者が「自分のタスクを完了させるために、誰かの助けが必要」という状況をできるだけ減らすようにしている。個々の工数が少々増えても構わない。「サーバがAPIにこの値をつけてくれないと、クライアントの開発とテストができないので、待ち」みたいな時間を減らすほうが効果が大きい。サーバとクライアントの両方が同時にデプロイしないと動かない、みたいな状況も減らしたい。個別の工数ではなくて、全体のリリースサイクルを短くしたいのだ。

NETFLIX のダイナミック・スクリプティング・プラットフォームとか、PaaS とか、Lua でスクリプトを組み込むとか、そういうのが理想だろう。いまの案件のエンジニアリング・リソースと、プロジェクトごとの要件のばらつき具合を見ると、躊躇している。一方で、汎用の BaaS をいくつか持っていて、プロジェクトをまたいで使用している。

というわけで

汎用的な問題解決方法と、個別具体的な知識/方法を、自分に合った組み合わせで習得/実践することが必要だと考える次第である。コンテクストに強く依存すると、話が長くなりがちなのだけれど、前提条件を明らかにすることで話がクリアになると考えたので、書いてみた。
http://careerhack.en-japan.com/report/detail/332 に関するツイート

ベストプラクティス（）とコンテクスト

第一四半期バタバタしていた。テレビの収録、リハーサル、放送の日程は残念ながら given な条件なので変えられないのだけれど、そうじゃないときは休みを取りやすい。代休も、もちろんちゃんと取れる。部署の上司が取らせようとしてくれるのと、周りが寛容だからだろう。自分ばっかり休んでる気がするけど、気づかないふりして、代休で5日ほど休んでいる。

休んでいると、いろいろ余計なことを見るし、考える。以下は、その考えの吐露である。

きっかけはTDDである。が、TDDの話はいい。よくわからないことはあるし、テストの重要性は分かっていつつも、スキルがー、とかでまだあるべき姿に追いついていないところだ。

そこで、あるべき姿とは何か、である。かーらーの、問題の発見/定義と解決である。たとえば（さまざまな紆余曲折を経て）ちょっとしたDBがあり、Webブラウザで閲覧/更新をしたいとしよう。解決策として Django の管理画面を使うことになったとしよう。たぶんテストファーストでユニットテストを書く必要はないだろう。フレームワークのデフォルト機能使うだけなのだから、そんなものテストする工数のほうが多くなりそうだ。

一方で、そのDBに外部からアクセスできるようにし、ロールごとに細かく権限が異なるようなAPIとして提供し、課金までするとなると話が一気に変わる。おそらくは、リリース後に「ACL間違ってました、てへ」は通用しないだろうから、テストファーストかどうか知らないが、何らかの形で自動テストをしたくなるだろう。

この2つは極端だしわかりやすいんだけど、製品やサービスの機能要件、非機能要件、組織のあり方、開発サイクルなどによって、テストの位置づけは全く違うと思う。コンテクスト抜きで問題定義できないし、解決策候補の評価もできない。

ちょっと長いけれど、引用する。

たとえば、エクストリームプログラミング(XP)の方法論でよく知られている
格言のひとつに、「失敗する可能性のあるものすべてをテストせよ」があります。 初心者にとっては、これはレシピとなってしまいます。初心者は何をテストすればよいのでしょうか？オブジェクトの属性値を設定する「セッターメソッド」と属性値を取得する「ゲッターメソッド」のすべてをテストすればよいのでしょうか？プリント文をテストすればよいのでしょうか？見当違いなものをテストするのが関の山でしょう。
熟練者なら、何か失敗するか ― 正確にいえば、何か失敗する可能性が高いか ― を知っています。経験と判断力を備えているので、この格言が特定の状況（コンテキスト）において何を意味するかわかっています。

（Hunt「リファクタリング・ウェットウェア」）

あなたが置かれている状況と、私が置かれている状況が異なり、コンテクストが違うなら、TDD の意味が違う。TDDの解釈に揺れがない、としてもだ。テスト、devops の意味や位置づけもだろう。なんなら、「開発」とか「製品」とかの意味だって違う。「いやいや、テストとは〇〇だ」と言いたいかも知れないけれど、全く残念なことに、そんなことはない。比較的近いと思っている仕事の人達と話しても、違うことあるんじゃないすか？そんなことないすか？ そんなことないと、ここまでドヤ顔で書いてきた私は、ちょっと困るんですけどね。

というわけで、もうちょっと前提条件やコンテクスト明らかにしたほうが、意味のある議論や意見交換ができるんじゃないかな、と思う。私は自分のコンテクストを鑑みて、次のビールを飲む。

片付けゴールデンウィーク

放置していたことを片付けた。 

トライアスロン中島大会に申し込む

スイム1.5km、バイク40km、ラン10km。5年くらい毎年参加している。紙に書き込んで郵送するか、Excel のファイルをダウンロードして記入してメールするの二択。Excel ファイルが地味にチェックボックスとかになっていて、Mac にプリインストールされていた Number.app では編集できない。Office for mac の DVD を探し出したが、マウントできない。いろいろやってUSBケーブルがダメだと気付き、インストール。記入して、出場許可がでることを祈りつつ申し込んだ。
https://www.city.matsuyama.ehime.jp/shisei/shiminkatsudo/sports/triathlon.html

CDをiTunesに取り込む

Office for Mac の DVD を探していたら、音楽CDが出てきた。音楽を聞いていた時期が私にもありました。ってわけで、iTunes に取り込んでいなかったCDを取り込んだ。

• Incognito 「Beneath The Surface」
• 岡村靖幸「OH!ベスト」
• C-C-B「GOLDEN BEST」
• Dave Grusin「Now Playing」
• Thomas Hardin Trio「Satie & Debussy」
• Dave Grusin「Two For The Road: The Music of Henry Mancini」
• 渡辺美里「Sweet 15th Diamond」
• 上原ひろみ「Spiral」
• 「JET STREAM ニューヨーク/サクセスストリート」
• David Benoit 「Remembering Christmas」
•  「Now Jazz 4」

イーモバイルのsim交換

なんかよくわからないけど、機種変更した時にemチャージなるプランに変更になっていたらしいので、sim を入れ替えて、チャージや自動更新の設定をし... ようと思ったら、この sim カードはでかすぎて、pocket wifi に入らない。放置。

東京・江戸前トライアスロン

10月のレースなのだけれど、早めに申し込む。どうせぎりぎりまで粘っても、年に何回はレースをキャンセルする羽目になる。スイム0.5km、バイク12km、ラン5km。会場が、自転車で軽く自走できるくらい近いし、距離も短いので気軽に参加できる。

その他

• 先週のランニングレースの結果入力
• 昔の上司からメールに返事をかく。軽く返事を書いたんだけど、改めて丁寧に。

Team Geek を読んで、実践し始めたこと

Fitzpatrik と Collins-Sussman「Team Geek」を読んだ。体系化された方法論として書かれているわけではないので、内容をそのまま紹介することが難しい。この本で問題であると指摘されていることのうち、自分がやってきたこと、どう対処しようとしているかを書いておく。

※ 誤字脱字、分かりにくい表現、スタイルをリライト。ロジックはそのまま。-- 2014/04/24 8時半ごろ

で、でたーw 天才じゃないのがばれるのが嫌だから、途中の成果を隠奴〜w

Most programmers are afraid to share work they've just started, because it means peers will see the mistakes and know the author of the code is not a genius.

これは自分に当てはまる。そのとおりだ。だって天才じゃないって知られるの嫌じゃん。（うすっぺらい）プライドの高さと、器の小ささにかけては、世界トップレベルの自称天才にとって苦痛でしかない。

一方で、ソフトウェア開発における成果にフォーカスするとき、障害になりうる考え方だ。私の場合、確実に障害になる。妥当性のチェックを自分ひとりでできないため、間違いが組み込まれることが必至である。コードレビューでは遅すぎることもある。要件定義のミスがテストまで残ってると、修正コストが跳ね上がるという有名な話だ。つまり、早い段階から、レビューしてもらうのもっともコストが低いのに、その手段を放棄しているということだ。

もうひとつ。自分しか分からないコードやプロセスが存在すると、自分が SPOF （Single Point of Failure; 単一障害点）になってしまう。よっぽど職場で立場が危うくて、どうしても仕事を守る必要があるなら別だけど。

最近は、プロジェクトの初期段階で自分がやろうとしていること、やっていることを共有するようにしている。

で、でたーw 謙虚・尊敬・信頼の欠如でギスギスす奴〜ww

Almost every social conflict can ultimately be traced back to a lack of humility, respect, or  trust.

尊敬というか、敬意を払うってことだと解釈している。

かならず最後に自分のコメントを付け足したがる病についても、触れられている。見ててだるいし、無理に何か言おうとするから、みんながす指摘してないけど瑣末なこと言ったりとかになりがち。つまり、なんの付加価値もない音声のやりとりを待つ時間が増えるということだ。気をつけよう。最近、多い気がする。

以前から気をつけているのは「バグを憎んで人を憎まず」である。悪意や極端な怠慢でないかぎり、バグについて人を責めたりしない。ひとつは、自分が責められたくないから。もうひとつは、さっさとバグを修正することに集中して欲しいからだ。

で、出ーw べき論だけ語って、イライラ奴〜www

If you focus on the way thing should be in your organization, you'll find nothing but frustration and disappointment.

現状把握、問題解決、具体的なアクションを考えろ、ということなのだ。

そして自己アピールや昇進は悪ではないことを、受け入れるときなのかも知れない。組織上の上位のポジションであるが故に実現しやすいこと、というのは確実に存在する。発言力だって大きくなる。もちろん責任は増えるだろうし、非合理的な人間の相手をする必要もある。

ソフトウェア開発者にはひとつ有利な点がある。自動化や成果の複製が容易なのだ。やったことを/作ったことを複製するというオプションが存在する。システム化してしまおう（Excel のフォームを綺麗にするんじゃなくて、マクロで自動送信するとか）、部署間での口頭での調整にしようというような、意思決定と運用は、広い意味でエンジニアリングだ。

数年前、マーケティングをやっていたとき「儲かるしくみをエンジニアリングする」というのが部署の役割だった。要件定義、開発、運用をふくめて回るようにする。そのための広告、ウェブサイト、プレゼン、他部署との調整、値付けだった。

エンジニアリングを実践する技能は、きっと組織の成果を向上させることにも使えるだろうな、と思い始めている。

赤柳初朗の正体を考える、を更新

赤柳初朗の正体を考えるを更新した。ちょこちょこリライトしたのと、「キウィγは時計仕掛け」の情報を追加した。ほとんど進展はない。

地の文で、西之園萌絵のことが、西之園は/が〜と書かれる箇所と、萌絵は/が〜と書かれる箇所があることに気づいた。もしこれが、語り部がによって書かれ方が変わっているとすると、やっかいであると同時に、これまでと違った読み方ができることになる。誰が書いたか、によって、ベースとして知っている情報が変わってくるからだ。

森博嗣の叙述トリック（といっていいか分からないんだけど）を解く立場になるときにイラッとするのは、地の文で三人称で書いているときでも、嘘があるときだ。そこ信じられないんなら、なにを信じたらいんだよ、となる。境界条件が定まらないじゃないか、と。西之園、萌絵の使い分けは、そのヒントにになるのかも知れない。

boto から Apache Libcloud に乗り換えるかも

簡単な管理ツール＋管理画面を作ることになり、以前からやってみたかった Python 3 での開発を試みた。AWS の S3 にファイルをアップロードするタスクがあるのだけれど、boto は Python 3 で使えない。

今回は Apache Libcloud を使うことにした。いろんなクラウドサービスを単一のインタフェースで扱おう、というライブラリだ。S3 に特化した操作をするのは難しいかも知れないけれど、今回はシンプルな KVS サービスとして使うので、これでよい。


ただ、Fabric が Python 3 に対応していなかったので、結局 2.7 で書くことになっている。

試したもの、捨てたもの: BusyCal、毛布、Atom など

BusyCal: Mac OS X 用のカレンダアプリ BusyCal を試用したが、継続使用を見合わせることにした。毎日の行動の記録をカレンダに記録していて、標準アプリでは1日分のカレンダを表示すると、わたしがまったく使わないリスト表示で埋まる。BusyCal は時間の長さが分かるビューだけ表示されるので試用してみた。けれど、アラームを手軽に「1分前にスヌーズ」できないのと、日をまたぐ項目（睡眠時間とか、テレビ番組とか）を操作したときに表示がガクガクするので、やめた。

毛布が売れた: 使ってない毛布を、住んでいる自治体のリサイクルショップに販売を委託していた。1000円で売れて、60%の600円が自分の取り分として貰えた。委託料100円を先に払っていたので、500円。ビールを飲んだ。

テキストエディタ Atom: Github 製のテキストエディタ Atom を使ってみた。もともと Sublime Text 2 でも大したことをやっていなかったので、わりと使えるんだけど、ファイルごとにタブ幅を設定する方法が分からなくて、やめた。まだベータフェーズなので、できたいことがあっても別によいんだけど。

Twitter: 酔っていたときに、誤ってアンフォローしてしまった。そのままやりとりの少ないアカウントをアンフォローしていったら、酔っていたのでやりとりのあるアカウントもアンフォローしてしまった。面倒になったので、全部アンフォローした。気が向いたときにフォローしている。フォローが少ないと見える景色ががらっと変わる。また、周りからつっこみが来ないから、プライベートなチャットルームにいるように錯覚する。

RunKeeper: エリートアカウント（有料プラン）を試しはじめた。消費カロリーの推移や、練習時間の推移の表示ができるようになる。ほかにもいろいろあるけど、まずは「自分の運動の履歴を可視化したら、やる気がでる」仮説を検証する。

おれがときめく整理整頓

不要なものを捨てたり、いつやってもいいが完了していないことをやったりした記録。

使わない容器を捨てる: 化粧水の詰め替えボトル、や、押入れの乾燥剤を入れるためのケースなどを捨てた。旅行などめったに行かないし、顔くらい水で濡らしておけばいいし。

使わないソフトウェアのパッケージ: 最近廃棄した emobile の端末に付属のソフトウェアを捨てた。Windows 7 のパッケージ。なんでこんなものを所有しているのか、一瞬分からなかった。基本的に Mac を普段使っているのだが、唯一持っていたゲームソフトが Windows 専用だったので Bootcamp だか VMWare Fusion だかでプレイしようとしていたのだ。そのゲームは捨てたので、この Windows も要らない。

Macbook Air: 先月、Macbook Pro を購入して完全に乗り換えたので、ディスクの内容を消去して、OS をインストールしなおした。ディスクの内容は念入りに消去した。義理の母にゆずるからだ。

ギフト券: どこで使えるのかよく分からないし、いかにも使えそうなデパートに行こうとすると電車代だってかかる。というわけで、近所の金券ショップで換金した。ビアバーでの軍資金にする。

革のブックカバー: なんでカバーなんか持ってたのか思い出せない。紙の本を読むとき、べつにカバーかけていない。というわけでゴミ箱へ。

上記を入れていた段ボール箱は、次の資源ごみの日に出す。

とおるメモは死んだ

10年以上前に書きためた雑文を、Kindle の電子書籍にして99円で販売した。もともと知人がウェブじゃなくて Kindle で読みたい、とうるさく言ってきたので作った。ふと、儲けることはできるのだろうか、と思った。結論からいうと、まったく儲け方が分からなかった。

釣りタイトルで、ブログ記事を書く → はてブ、そこから派生したgunosyから 1000 ページビュー → そのうち1%が購入 → 10冊売上 → ちゃりんちゃりーん

という流れを期待していた。

ブログは150ページビューくらい。私のブログにしては多いほうだ。はてブ、gunosy からの流入はない。

ブログを書いてから40冊ほど売れたが、知人による御祝儀購入だと思う。露出しているのが Twitter しかなく、知り合いとアフィリエイト狙いのスパムアカウントばかりだった。知人によるツイートが多い時間帯と、売れた時間帯が一致している感がある。

書名に魅力がないので、Kindle ストアで衝動買いというのは考えにくい。

誤字脱字、自分が読んでもよく分からない文章、最後のページにJavaScriptのエラーみたいなのが残っているので、気が向いたら修正しようと思っている。書名や価格は、大いに再考の余地がある。

とおるメモは私のなかで、終わってしまっている。我ながら面白くかけている文章もあるけれど、松本人志が何かの本で書いていたところの「誰もが1つや2つ持っている、滑らないネタ」でしかない。

Angular JS のチュートリアルを写経

Python 旅館 2014.02 なる寄り合いに参加した。会議室を借りて、だべったりコード書いたりする。今回は Angular JS のチュートリアルを写経した。

このチュートリアルは、各ステップで、すべてのソースコードが文書に書かれていない。git checkout step-8 を実行すると、ステップ8でのすべてのファイルの変更が分かる。この方式だと、私はステップをきちんと入力せずに、なんとなく解説を読んで分かったような気になる。もちろん分かっていない。

というわけで、写経してチュートリアルを読み進めていった。結果として有効だったと思う。モジュールの基本的な考え方がなんとなく見えたし、コントローラ、フィルタ、サービスを追加するイディオムらしきものも分かった。「写経」は定義のゆれが大きい言葉なので、具体的にやったことを書いておく。

• チュートリアルのリポジトリを git clone する。
• git checkout step-1 とかしながら、ステップを進めていく。
• 別のディレクトリに、チュートリアルのコードを写していく。
• npm install は使わない。
• index.html から写経し、必要なファイルを追加していく。
• これは何が起こっているのだ？という箇所があったら、チュートリアルのドキュメントを読む。
• 次のステップへ。

を、繰り返した。スマホのカタログサイトを作るというチュートリアルで、スマホのスペックが書かれたJSON ファイルは、1ファイルをちょっとだけ写経したあとは、ファイル郡を丸ごとコピーした。CSS や HTMLテンプレートで、似たような繰り返しはコピペで済ませた。

Python/Sphinx を使って Kindle 本を出版した

Kindle 本を出版するのに使用した、ドキュメント生成ソフトウェア Sphinx の紹介と、ドキュメント自体の紹介をする。

はじめに

Amazon の Kindle Direct Publishing は、手軽に電子書籍を出版するためのサービスだ。特定のフォーマットで電子書籍データを作り、ウェブページで情報を入力、手続きすれば、Amazon の Kindle 本として販売ができる。

先日、拙作を上梓したときには Sphinx  というソフトウェアを使った。Sphinx はドキュメントを生成するソフトウェア がある。サンプルをとったことはないけれど、おそらくは主にソフトウェアの技術文書を記述/生成するために使われていると思っている。たとえば Sphinx を使っているコミュニティのウェブサイトは、Sphinx で作られている。けれど別に仕様書を書く以外に使ってもよい。

restructuredText という単純なテキストでコンテンツを準備すると、Sphinx の標準機能で epub 形式に変換できる。Kindle Direct Publishing に epub 形式のファイルをアップロードして、著者情報やジャンルを設定しておけば、めでたく出版されるというわけだ。

Sphinx で epub 形式のファイルを生成

Sphinx を使うには、プログラミング言語 Python を使う。何を言っているのか分からない、かつ、Mac を使っているのであれば homebrew と pyenv を使うとよい。

$ pip install sphinx
$ sphinx-quickstart

続きはドキュメントを読めばよい。最後に make epub すれば epub 形式のファイルが生成される。これを Kindle Direct Publishing で出版すれば完了だ。

さて...

多忙なビジネスパーソンに求められる癒し

クラウドジェネレーションのビジネスパーソンは、日々大きなストレスにされされています。常態化した人手不足により、残業や休日出勤が当然のように要求されます。

現実を知らない評論家は訳知り顔で「残業は無能の証」「効率が悪いだけ」「社畜乙」などの罵詈雑言をSNSでつぶやき、ビジネスパーソンにさらなるストレスを与えているというのが現実です。

直近で目の前の問題に対するソリューションを期待できない今、ビジネスパーソンに必要なことは癒やしです。ひとりでも多くのビジネスパーソンに癒やしを提供したい、その想いから、とおるメモを出版する決意をしました。

メモで癒せるの？

たかがメモを読むだけで癒やしを得られるとは思えない、という人がいます。私がお伝えしたいのは、まさにそのような人にこそ、癒やしとしてのメモ、すなわち Memo as a Heal が必要だということです。

薬物中毒の患者さんは、頑なに「自分には治療が不要だ」と言います。けれど、患者さんこそが、まさに治療を必要としていると思いませんか？ 気づかない間に、同じことがビジネスパーソンにも起こっているのです。

なぜメモが癒やしになるのか

長時間のセラピーは、まとまった時間が必要です。これでは多忙なビジネスパーソンに、さらにストレスを与えてしまうことになります。

短いメモを読むだけなら、比較的容易に時間を確保できます。またその癒やされたときに湧き出るβエンドルフィンの作用により、自発的に癒やしを求めるようになり、さらにメモを読むことになります。まさに、ポジティブ・スパイラルですね！

メモが効果的である、たった3つの理由

POINT 1: ショート・センテンス

とおるメモは、短いショート・センテンスとショート・パラグラフで構成されています。だから電車でひと駅の間にひとつのメモを読み切れます。乗り過ごしによるストレスとは、もうグッバイ。

ショート・センテンスだから、寝る前にちょっと読むのにも適しています。これがとても面白い長編小説だと、のめり込んでしまって睡眠時間を削ってしまって、本末転倒。とおるメモなら、1メモくらい読んだら飽きてしまうので、すぐに眠れます。

POINT 2: エクストラ・オーディナリなエクスペリエンス

多くの人が体験できないこと、普段気にしないテクノロジのことが書かれています。擬似的に、非日常的な体験をすることで、読者の魂を開放し、ヒーリングへと導くのです。

たとえばテキサスの片田舎にわざわざ行きますか？ 行きませんよね。ニューヨークやサンフランシスコに行きたいと思います。けれど何も考えなかったせいで、クリスマスにはゴーストタウン化してしまう町に住んでしまう愚か者の生活は、なかなか愉快です。

またスーパーコンピュータや、いま話題の原子力についての考察もあり、読者の見聞を広げ、教養を深める効果があります。

POINT 3: ポジティブなアティテュード

エレナ・ホグマン・ポーターの小説「少女パレアナ」を知っていますか？ 日本ではポリアンナとして知られているかも知れません。母をなくした少女が、父との約束である「よかった探し」をすることで幸福に生きていく物語です。

とおるメモも、ものごとのポジティブな面に焦点を当てます。成績がCであったとき、A ではなかったことを嘆きません。D でなかったことを喜ぶのです。ネガティブなことを考えても道は開けません。起こったことは変えられないのですから、自分自身の考え方を変えるのです。このようなポジティブなアティテュードのことを、ポリアンナ症候群と呼ぶこともあるようです。

読者の声

出版して間もない「とおるメモ」ですが、すでに多くの読者からポジティブなフィードバックが届いています。

とおるメモ、ポチった。通勤の時に読むかー
— Shinya Okano (@tokibito) 2014, 2月 15

なんか少ししんみりな気持ちであったけれど、とおるメモ読んだらちょっと元気でた。
— たい焼きの人 (@tmmkr) 2014, 2月 15

ヒット商品 7時ごろの第3位 『とおるメモ』 ふるかわとおる (著) 99円 http://t.co/JxEEFpEzFh #Kindle
— Kindleのベストセラー(総合) (@KindleJPRanking) 2014, 2月 15

とおるメモ: ふるかわとおる: ￥99 Kindleストア ヒット商品3位 http://t.co/79fMnOHtLS
— Kindleランキング (@sale_ebook) 2014, 2月 16

#3: とおるメモ http://t.co/M2bT4YIjp5
— 冬夢 (@fuyume0228) 2014, 2月 15

#3: とおるメモ http://t.co/PPh6uR5DRA
— のこ (@noko0104) 2014, 2月 15

#3: とおるメモ http://t.co/gQNPRjg8LQ
— 沖奈 (@okina0702) 2014, 2月 15

#3: とおるメモ http://t.co/GU89RnSYNB
— 菜子 (@nako0503) 2014, 2月 15

豪華特典

Kindle 版の出版を記念して、今だけ特別に2つの特典があります。

特典１:  通常価格 3,900円を、99円でご提供

特典２：クリエイティブ・コモンズライセンス

この機会をお見逃しなく！ あなたの癒された生活を願っております。

とおるメモ Kindle 版

Amazon の Kindle Direct Publishing でとおるメモという本を出しました。もともと、ウェブ上で書き散らかしていた雑文です。10年前の話です。昨年 Kindle版を出版しようとしました。出版しようとしたファイル形式がおかしかったようです。

ウェブで公開しているので無料で読めます。Kindle版を出すにあたってダルい思いをしたので、99円いただきます。うっかり人気が出て、儲けになりそうだと思ったら、値上げしてちゃりんちゃりん生活します。

捨てたもの: オフィスの引き出しの中身など

職場のデスクの引き出しを整理した。まず、もう食わないだろうという感じのお菓子。それから、使ったきりもとの場所に戻されていない、ケーブルやアダプタ類を所定の位置へ戻した。

自宅の汚れたままだったレジャーシートをゴミ箱へ移動した。雨の日のトライアスロンのレースで使って、後日きれいにしようと思っていた。けれど後日が訪れることなく本日に至る。100円のシートだし。

金属や陶器のゴミを出した。部屋の隅を選挙していたゴミ袋が消えた。

捨てたもの: データ通信端末、完走証、写真

ランニングやトライアスロンの完走証がまたもや出てきたので捨てた。それから写真も何枚か出てきたので捨てた。

5年以上まえに契約したイーモバイルの、USBスティック型の通信端末を手放した。機種変更なので、正確には捨てたわけではない。風邪で休んでいたら、イーモバイルから機種変更しませんか、と電話がかかってきたのだ。この電話がなければ、以前の端末を使い続けただろうから、まあよい。

問題は何も考えずに機種変更をしたお陰で、この端末が本当に必要なのか怪しくなったことだ。そもそも社外で打ち合わせするとき、新幹線に乗るときくらいしか使わない。今は iPhone でテザリングできる。どうせだったら Nexas 5 にしたらよかった、などといろいろ考えてしまう。

pyenv と tox で複数バージョンの Python に対応したライブラリ開発

生まれてはじめて PyPI にコードを登録した。Python 2.7 と 3.3 で使えるようにするにあたり、ライブラリの実装とは直接関係ないところで、とまどった。現時点での手順を記録しておく。

以下を前提とする。

• OS X 10.9.1 (Mavericks)
• homebrew でパッケージを管理
• pyenv, pyenv-virtualenv で OS 上の Python 環境を管理
• PyPI に登録するライブラリは Python 2.7 と 3.3 に対応

まず始める

shimizukawa によるハンズオン資料と公式ドキュメントを併読しながら進める。基本的な作業はハンズオンでだいたい分かる。とはいえ、あなたが持っているライブラリは、必ずしもチュートリアルどおりではないだろうから、公式ドキュメントのガイドが必要になるだろう。

ところで、ナウなヤングは egg じゃなくて wheel を使うらしい。

pyenv と pyenv-virtualenv をインストールする

pyenv は先週まで存在すら知らなかった。肉の日生まれの wozozo が使っているらしいので、試すことにした。まずインストールする。

$ brew install pyenv pyenv-virtualenv
$ cat >> ~/.zshrc
export PATH=$HOME/.pyenv/bin:$PATH
if which pyenv > /dev/null; then eval "$(pyenv init - zsh)"; fi

pyenv は複数の Python インタプリタをインストール/アンインストールするツールだ。pyenv-virtualenv は、pyenv と virtualenv を一緒に使いやすくする。実際に使ってみる。

$ pyenv install 2.7.6
$ pyenv virtualenv 2.7.6 foo-27

ひとつめのコマンドで Python 2.7.6 をインストールする。通常 ~/.pyenv/versions/2.7.6/bin/python にインストールされる。他にも pip なんかも入る。

ふたつめのコマンドで、Python 2.7.6 をベースに virtualenv を作る。通常 ~/.pyenv/versions/foo-27/bin/python に構築される。pip の他に activate なんかも入る。

同様に Python 3.3 をインストールして、仮想環境を作る。

$ pyenv install 3.3.3
$ pyenv virtualenv 3.3.3 foo-33

普段は Python 2.7 で作業しているので、おそらく foo-33 環境は不要だ。Python 3.3 については、tox が virtualenv を別途作ってくれる。けれど、カジュアルに pip とかしてしまうと、元の環境を壊してしまう。元の環境は綺麗にしておきたいので foo-27 と foo-33 環境を作る。

つづいて、プロジェクトで foo-27 と foo-33 う使うように設定する。

$ cd /path/to/foo
$ pyenv local foo-27 foo-33
$ cat .python-version
foo-27
foo-33

pyenv local X Y を実行すると、そのディレクトリで使う Python 環境を設定する。ここでは foo-27 と foo-33 だ。

順序には意味がある。python コマンドを発行した時には、foo-27 環境の Python が呼び出される。

そして foo-27 と foo-33 の両方を指定する必要がある。後述する tox は python2.7 や python3.3 というコマンドを実行する。このとき pyenv local で指定された環境を探しに行くからだ。pyenv local foo-27 だと python3.3 が見つからないというエラーがでる。

ref. Using tox with pyenv #92

tox を設定する

$ pip install tox pytest
$ pip freeze | grep -v wsgiref > requirements.txt

wsgiref を含まないようにしている。理由は後述。

tox を使うための設定ファイルは以下のとおり。

$ cat > tox.ini
[tox]
envlist = py27,py33

[testenv]
deps = -rrequirements.txt
commands=py.test

envlist で py27 と py33 を指定しているため、このディレクトリ以下で、ビルドやテスト時に python2.7 と python3.3 を呼び出す。

tox.ini ファイルで、Python 2.7 インタプリタをフルパスを指定できる。だが、やらない。小さなプロジェクトだけれど、自分のところでしか動かないような設定にしたくないからだ。

tox を実行

$ tox

Python 2.7 用に virtualenv して、インストールして、ビルドして、テストを実行。Python 3.3 も同じ。

requirements.txt に wsgiref が含まれていると Python 3.3 で以下のようなエラーが出る。

Downloading/unpacking wsgiref==0.1.2 (from -r requirements.txt (line 7))
(...)
  File "./ez_setup/__init__.py", line 170

    print "Setuptools version",version,"or greater has been installed."

                             ^

SyntaxError: invalid syntax

PyPI へ登録する

$ python2.7 setup.py sdist bdist_egg upload
$ python3.3 setup.py bdist_egg upload

これで登録はできるが、こういう呼び出し方でいいのか自信がない。

まとめ

• はじめて setup.py を書いた。
• ヤク刈り、とは言わないけれど、地味に解決すべきことがことがあった。
• 明日は肉の日である。 

捨てた: ドライバ（ねじまわし）、データ集録デバイス、ケーブル、NAS、年賀状

捨てたもの記録

• ドライバ ... 以前に勤めていた会社で、エンジニアの小道具兼ノベルティになっていた会社ロゴ入りドライバ（ねじまわし）。どう考えても使わないので、次の金属ゴミの袋へ。
• データ集録デバイス ... ±5V のアナログ信号入出力、デジタル信号入出力をするデバイスをゴミ袋へ。どう考えても使わない。
• ケーブル類 ... 同じような長さの同じような端子のケーブル。特にUSBケーブル。まとめてゴミ箱へ。品川区ではUSBケーブルは燃えるゴミ。
• NAS ... .ero フォルダだけが 800GBくらいになっていたけど、まったく使っていなかった。HDDを物理的にエイヤっとして、次の金属ゴミへ。
• 年賀状 ... 年賀状は読み返すことはないし、出さないので参考にすることもないので、持っていてもしょうがない。すべてスキャンして、住所だけアドレス帳に入力して、さよなら。
• ペン ... なぜか増えていくペン類。黒を2本、青を5本（普段は青のボールペンを使う）、筆ペンを1本のこして、すべて廃棄。とくに蛍光ペンとかまったく使っていない。

git log --graph --decorate=full

git を使っていて、ブランチやコミットがどうなっているのか知りたくなる。SourceTree を使っていると、グラフを可視化してくれるんだけど、git log と入力しただけだと、ずらずらっとシーケンシャルに出てくるだけで、わかりにくい。hg の glog エクステンションみたいなのはないのか、と探した。

git には標準で、そんな機能はついている。

git --graph --decorate=full

decoreate を full にするのは、ブランチ名を表示させたいから。デフォルトの short では、コミットのハッシュしか表示されない。

--pretty=format:xxx を使うと、より細かく設定できる。

[alias]
 glog = log --graph --date=short --decorate=short --pretty=format:'%h %Cblue%d%Creset %cd %cn %s'

けど、もうこんなことやるのだるいので、 --graph --decorate=full だけをエイリアスにしておいた。

森博嗣「キウイγは時計仕掛け」

森博嗣の「キウイγは時計仕掛け」を読んだ。

それが、つい二カ月ほどまえになって、君も発表者だよ、と言われたのだ。え、そんな、と驚いたら、あれ、言わなかったっけ、というのが山吹の言葉だった。そういえば、論文の著者名で、加部谷のところに○が記されている。それが発表者の意味だったのだ。

学会発表ってこんな感じだったなぁ、もう、ぜんぜん分かんないなぁと、思いながら、学会の会期中に起こる事件を追った内容を読んだ。赤柳初朗の正体赤柳初朗の正体を考えるためには、再読が必要である。

シリーズとしては半分以上きているのかな、とタイトルを眺めていたら、タイトルのつけかたが折り返しているように見える。

1. φは壊れたね
2. θは遊んでくれたよ
3. τになるまで待って
4. εに誓って
5. λに歯がない
6. ηなのに夢のよう
7. 目薬αで殺菌します
8. ジグβは神ですか
9. キウイγは時計仕掛け

5作目「λに歯がない」と7作目「目薬αで殺菌します」は、それぞれ歯と目がタイトルに含まれていて、体または顔に関係する。

4作目「εに誓って」と8作目「ジグβは神ですか」は、誓う、神と信仰に関係ある言葉が含まれる。

3作目「τになるまで待って」と9作目「キウイγは時計仕掛け」は、時間を連想させるタイトルだ。

今後は、2作目、1作目と対応する作品が出て完結か、謎は解けたぜベイビーと思ったのだけれど、森博嗣本人が全12作だと書いているので、およそ関係ない。


ところで、この本を買ったときには、まだノベルスしか売られていなくて、しょうがなく買ったんだけど、いま Amazon をみたら Kindle 版が売られている。裁断してスキャンするの面倒なので、2冊分の金払うから、最初から Kindle 版が欲しい。

スキャン、クローゼットと棚の整理、クリーニング

昨日に引き続き、本のスキャンをした。これで手持ちの本はすべてスキャンできた。

棚とクローゼットの中を整理した。不要なものをゴミ袋へ。長さが同じで口の形がおなじのUSBケーブルが5本もあったり。プログラマ向けイベントや、レースでもらったTシャツも腐るほどあった。外出に使えなさそうなのはすべてゴミ袋へ。どうしていいか分からない書類もゴミ箱へ。

クローゼットにはゴミの他に、当分着ない服があった。クリーニング屋に出した。後は、旅行のおみやげを送るとか、部屋を片付けたりとか、古いメールアドレスで登録しているサービスの設定を変更するとかやっていたら夜になった。

本の裁断と自炊、ファイル名変更、アドレス帳整理

段ボール箱3つと布団だけで東京に来てから、ずいぶん荷物が増えている。ついでに、ゴミも。冷蔵庫の下のように、普段気にしないので掃除を先延ばしにしたけど、長い間ほったらかしたがために、堆積している埃もある。物理的ではないが、ほったらかしにしていることもたくさんある。少しずつでもよいから、確実に手放していこうとしている。

本の裁断と自炊

未読も既読も、紙のままになっていた本を裁断してスキャンしている。スキャンが終わってからの、OCR 処理に時間がかかる。

自炊後のファイル名

OCR を待ちながら、ビールを飲んでるのにも飽きた。スキャンしたPDFファイルの名前のフォーマットを統一した。Good Reader で読むときに探しやすいようにするというのが目的だ。

[<著者名>]<書名>_<巻>.pdf

外タレの場合は姓だけにする。たとえば DeMarco というぐあいだ。著者が複数いるときには、最初のひとりだけ。所有している本で、複数の著者というのは、ほとんどの場合、技術書だ。タイトルで検索できればいい。フォーマットを統一しておいたほうが後々楽だろうと考えた。雑誌の場合は []Triathlon LUMINA_2013-01.pdf のように著者名を空文字にした。

例外が1冊ある。小池真理子と村上龍によるアンソロジー「美しい時間」だ。小池真理子がひとりめの著者なのだけれど、普段、小池真理子を読まないので、誰が著者だったかすぐに思い出せない。山田詠美だったっけかなぁ、などとよく分からない混乱をする。村上龍だというのはすぐに思い出せる。なので、この本の著者は村上龍にしてある。

「片付けをしていると、中身を見てしまって進まない」問題というのがあるらしい。らしいって、私自身そうなのだが。けれど PDF ファイルの名前を変えるだけなら、そんなことにならない。淡々とファイル名を書き換えるだけだからだ。たまに、著者名が分からなくて、ファイルを開くこともあったけれど、すぐに作業に戻った。紙のデメリット、電子媒体のメリットが、ひとつずつ明らかになった。

アドレス帳

アドレス帳も整理した。どこかで名刺交換したんだろうけど、まったく思い出せない人の情報は削除した。件数が多いわけじゃないけど、気分的にすっきりした。それから、所属が変わったりして、情報が複数ある人は統合した。

自転車のチューブ

バルブの先が壊れている。いまのところ直接困っていないけれど、いつまでも使うわけにもいかない。2本買った。700 x 20-23c の W/O チューブ。

副作用

同僚に「から副作用とは何か教えろ」という趣旨の要求があった。この文書はその同僚に向けて書く。

副作用がある、というのは「知ることができるような状態変化が発生する」ということだ。定義から入ろうとすると、状態とはみたいな話になってしまうので、例をあげていく。サンプルコードはすべて Python で書く。

副作用のない関数呼び出し

>>> def add(a, b):
...    return a + b
... 
>>> add(1, 2)
3

関数 add の呼び出しには、副作用はない。関数は呼び出され、計算され、結果が返されているが、システムの状態に変化はない。関数が値を返すことは、副作用ではない。

代入

>>> VAL = 0

この代入文は副作用がある。この代入の実行前には VAL が定義されていないか、他の値が入っている。実行後には VAL に 0 が入っている。VAL の値が変化する = 状態変化がある = 副作用がある。

この代入の前にも VAL の値は 0 の場合もあり、状態は変わっていない。それは結果的にたまたま変わっていないだけであって、この代入文には VAL の値を書き換えるという副作用がある。

副作用のある関数呼び出し

>>> VAL = 0
>>> def incr_by(x):
...     VAL += x
...
>>> incr_by(4)
>>> VAL
4

incr_by 関数の呼び出しには、副作用がある。呼び出す前と後で、VAL の値が変わる = 状態変化がある = 副作用がある。incr_by に 0 を渡した場合は(r

副作用のあるメソッド呼び出し

>>> d = {'foo': 1, 'bar': 2}
>>> d.update({'baz': 999})

辞書の update 関数は副作用がある。上の例で、呼び出す前には辞書 d はキー baz を持っていない。update 関数を呼び出した後に、 d はキー baz を持つ。あるいは、最初から d['baz'] が定義されていても、値が書き換えられる。最初から d['baz']==999のとき(r

ファイル書き込み

>>> fout = open('iwata.txt', 'w')
>>> fout.write('hello')

上の例では open 関数も write メソッドも副作用がある。Python では、書き込みモードでファイルをオープンすると、そのファイルが作られる。したがって、呼び出し前後で os.path.exists() の戻り値が変わる。これはシステムに対する副作用である。

write メソッドを呼び出すと、ファイルに文字列が書き出される。write メソッドの前後で、open('iwata.txt', 'r').read() の戻り値が変わる。これも副作用である。

ところがどっこい

ここで「代入は副作用ではないが、ファイルへの書き込みは副作用である」なる発言を考える。VAL の例で代入は副作用である、という上の例と矛盾する。視点/立場をどこに置くか、で副作用の範囲が異なる。このエントリで例示してきたプログラムの視点で見ると、代入は副作用である。けれど、ファイルシステムだけを観測した場合には、変化がないので、副作用ではない。

最初の add 関数を呼び出すとき、足し算結果が欲しいプログラムのレイヤで観測すると副作用はない。しかし、実際には呼び出し前後で、内部のメモリ状態には変化が起こり、inspect ライブラリを使えば変化を知ることもできる。その立場で観測すれば副作用がある、と言える。

というわけで

知覚できる状態を変えてしまうとき、その関数、メソッド、操作は副作用がある、という。ただし「誰/何にとって」なのかによって、解釈が異なる場合がある。

BDD 的なアプローチでテストを書くとき、通常 given の操作は、テスト対象を特定の状態に強制するため、副作用が起こりえる。when 操作に副作用がないときには、then で戻り値を確認すればよい（副作用がないことを確認したければ、他にもすることはある）。when 操作に副作用があるときには、戻り値の確認だけでは不十分で、副作用を検出（他のAPIを呼び出して変化していることを確認など）する必要がある。

着られない服、履かない靴、使わないコップなどを捨てる

来週あたりに仕事納めができそうだ。公私ともに落ち着いてきた。今月は余計なモノやコトを捨てることにしたので、まずはクローゼットや靴箱を整理した。着ない（着られない）服、履かない靴、使わないコップなどをゴミ袋にまとめた。可燃ごみと不燃ごみばかりなので、それぞれ次の収集日に出す。

Vagrant のチュートリアルをやった

Vagrant のチュートリアルをやった。仕事で使うツールが、間接的に Vagrant を使っている。基本的なことくらい知っておこうと考えた。

Vagrant は virtualbox、VMWare Fusion、AWS EC2 の操作をラップする、と理解している。チュートリアルでは virtualbox が操作対象である。

vagrant init は、Vagrantfile を作る。Vagrant レイヤでの仮想マシン設定項目が、 Ruby で記述されている。vagrant init はひな形を作る。ユーザが用途に合わせて編集する。

vagrant box add は、box（仮想マシンイメージ）を取得して、~/.vagrant.d/boxes ディレクトリに保存する。

vagrant up はVagrantfile の box を読み取り、box を使って virtualbox 上で仮想マシンを起動する。このとき、.vagrant/machines/ 以下に仮想マシン情報が書き込まれる。

プロジェクトディレクトリは、仮想マシンの /Vagrant ディレクトリにマウントされる。ローカルで好きなツールを使って編集すればよい。

Vagrantfile にプロビジョニングの方法を記述しておくと、最初に vagrant up したときや、vagrant reload --provision したときに実行される。チュートリアルでは、/Vagrant ディレクトリ以下に Apache をインストールするシェルスクリプトを配置した。

なるほど。なるほどですね。

bpython をインストールした。まだ使っていない

bpython をインストールした。Python のインタラクティブシェルを拡張したもの、と理解している。たとえば、入力中に関数やメソッド名の候補が表示される。パス名や、引数のヘルプも出る。

$ bpython
>>> import os.path
>>> os.path.e
┌──────────────┐
│exists     expanduser             │
│expandvars extsep                │
└──────────────┘

オリジナルの環境にはできるだけ入れたくない。しかし、プロジェクト毎の環境に入れるのもちょっと違う気がする。時雨道場に、シェルでログインしたときに、virtualenv を適用した環境にする、という教えがあった。bpython をインストールした環境を作り、 ~/.zshrc.local に以下のように書いておいた。

export VIRTUAL_ENV_DISABLE_PROMPT=1
source ~/.virtualenvs/default/bin/activate
unset VIRTUAL_ENV_DISABLE_PROMPT