2013年やってしまったこと

年始に、2013年にやらないことを決めた。

• 日帰りできないレース（トライアスロン中島大会は例外）
• 時間のかかる栄養補給
• 長時間のネットサーフィン

だが、やってしまったことがいくつかある。まず、マウイマラソンに出場した。とうてい日帰りなどできない。

ここで、大阪にトライアスロンしに行くことを考える。1週間前の週末に自転車を梱包してヤマト便で送る。ヤマト便は集荷時刻を指定できないので、自宅で待っている時間が長くなる。前々日には、レースの道具、ウェア、補給用のドリンク、その他の着替えをかばんに詰め込んでおく。前日に新幹線で大阪に行き、当日レースに参加する。レース後疲れた体をひきずって、新幹線で帰宅する。その翌週末、1日中自宅待機のつもりで待っていると、ヤマト便で自転車が届く。土日のいずれかを整体を予約しておいて、疲れを回復させる。

レースを日帰りに限定したかった理由は、時間と体力のロスを避けたかったからだ。仕事が立て込んで土日出勤が必要なときもあるし、土日に出勤することが必須要件（生放送がある、とか）の場合もある。日程のコントロール権はない。

マウイマラソンは、予め2週間の休暇をとり、ハワイをぶらぶらしている過程での参加だった。時間と体力の「ロス」が発生しない。例外扱いとする。

時間のかかる栄養補給を、3月以降よくやるようになった。平日の昼食にカロリーメイトではなくて、職場近くのレストランに行く、というのがよくない、ということである。時間もお金も消費する。何も考えずにコンビニ弁当を食べたり外食するのと、カロリーメイトを食べるのでは、おそらく健康に与える影響の差はほとんだいないだろう。バランス栄養食万歳。

年始から、たばこを吸い始めてしまったが、9月以降やめている。禁煙にストレスがあるので、他のストレスをかけないように、好きなモノを食い、好きなモノを飲むことを許した。その結果太った。クローゼットの中は、ほとんど総入れ替えである。一着も残っていない。だが、クローゼットを開けても、たばこの臭いがしないのでよしとする。

長時間のネットサーフィンはやらなくなった。SNS で時間を潰すのは、死語たるネットサーフィンと同じく「費用対効果の悪い閲覧行為」だと考えている。もちろんウェブで情報を集めたり、SNS で交流/情報交換したりすることの中には費用対効果が高いこともある。ネットサーフィン的な活動を避けた、ということだ。Twitter アプリをPCからアンインストールし、通知もすべて切った。

来年の抱負として具体的な活動に帰着させられるものはない。大きな指針として、より多くのことをやめ、より多くのものを捨てようとしている。同僚と話した内容を覚えてないくらい飲酒すること、インストールしっぱなしのスマホアプリ、3年以上クローゼットの容積を圧迫し続けるだけの電気カーペット、5年以上着ていない自転車ウエア、読者がいないどころか同僚に何故か dis られるビール・アドベント・カレンダーは、邪魔にしかならない。そのような心意気で2014年を迎えるのだと知人に伝えるべく、本日は、お気に入りの居酒屋でたくさん飲み食いする所存である。飲み会やっほう。

サンクトガーレン / スイート・バニラ・スタウト

ローストした麦を使った、香ばしいビールがスタウトだ。コーヒーのような香りがする。サンクトガーレンのスイート・バニラ・スタウトには、バニラが入っている。コーヒーフロートを飲んでいる感じがする。砂糖の甘さはないはずだが、香りと苦味とアルコールで、そんな味がする。


あまり知られていないが、私はスイート・バニラ・スタウトがこわい。まずこれはビールである。ビールといえばプリン体で、プリン体と言えば痛風である。健康指向であるところの私は、痛風になりたくないのだ。とても痛いらしい。

さらにバニラである。ましてやスイート・バニラ、である。バニラアイスをうっかり1ガロン、約4リットル買ってきて、1日でたいらげた挙句、翌日ずーっとお腹が痛かった経験がある。思い出すだけでもぞっとする話だ。スタウトの苦味に騙されて、スイート・バニラ・スタウトもごくごく飲んでしまうかも知れない。

おそろしいことである。そんなわけで、ビールがこわいのだ。ところでクリスマスだし、今夜はケーキがこわい。

サントリー / 深みの贅沢

サントリーの深みの贅沢を飲んだ。味、アルコール、苦さいずれも、サントリーのビールより濃い。贅沢、というのは、リソースを無駄遣いする、という意味とほぼ同義なのだろう。

冬になると、スーパーやコンビニのビール棚に、限定醸造や特別なビールが置かれる。寒いときに、自宅でゆっくり飲むのが楽しみな味が多い。ただ、冬にビールを飲むと冷えやすいのが難点だ。

そういえば、アメリカに行くと、湯船が長いけど浅い。肩までつかるためには、ずるずるーっと寝そべるくらいにしないといけない。冷えた底面積が大きくので、すぐにぬるくなる。

そう考えると、自宅の風呂は深いので、容易に肩までつかれる。風呂の湯を使いまくるけれど。

八ヶ岳地ビール / タッチダウン デュンケル

八ヶ岳に物見遊山に行った知人から、タッチダウンのデュンケルを土産にもらった。デュンケルは軽くローストした麦を使って、下面発酵させたビールである。ピルスナーや、日本でよく飲めるラガーを香ばしくしたような味と風味だ。

ボトルのラベルによると、フットボールを日本に普及させたなんとかいう外タレにちなんで、タッチダウンという名前にしているらしい。ラグビーでは点にならないが、アメリカンフットボールでは6点になるという、あのタッチダウンである。アメフトのタッチダウン、テレビでちらっと見たことがある程度だが、レシーバーが全力で走り、それを体当たりで止めてくるわけだから、なかなか大変そうではある。

日本のフットボールと言えば蹴鞠である。ぱっとみたところ優雅そうではあるが、あれはあれで大変なのだろう。当時の蹴鞠プレイヤーが、現代のフリースタイル・フットボール競技に来たら意外といいところにいくのかも知れない。

一方でサッカー、ラグビー、アメリカンフットボールなどを見たら、何が起こっているか理解できないかも知れない。「いくさじゃー」とか「くせものー」とか言い出すに違いない。家臣が、あれは蹴鞠の一種でございます、などとと説明し、「なんとサッカーでおじゃるか」と驚き、目が点になるだろう。

サンクトガーレン / エル・ディアブロ

サンクトガーレンのエル・ディアブロ。スペイン語で悪魔という意味だ。大麦（バーレー）を使い、ワインと同じ程度のアルコール度数の、バーレーワインというスタイルである。熟成期間を長くできる。

毎年、ボジョレー・ヌーボーが解禁になる夜、このビールも解禁になる。悪魔のビールを深夜0時に開栓してくれるビアバーもある。今年は残念ながら行っていない。

ワインは熟成させることで味がよくなるらしく、ボジョレー・ヌーボーはそれほど美味しくないのだ、と聞いたことがある。真偽のほどは定かではない。一方、ビールは、もともと鮮度が命であるため長期間熟成させるものではない。したがって早い段階で飲むことには、意味がるように思える。

しかしながら、バーレーワインは長期熟成が可能なため、敢えて古いものを飲んで味を楽しめるのだ。解禁日に飲むもよし、後で飲むもよし。天使の誘惑である。

サンクトガーレン / ウン・アンヘル

サンクトガーレンのウン・アンヘル。スペイン語で天使という意味だ。小麦（ウィート）を使い、ワインと同じ程度のアルコール度数の、ウィートワインというスタイルである。熟成期間を長くできる。

毎年、ボジョレー・ヌーボーが解禁になる夜、このビールも解禁になる。天使のビールを深夜0時に開栓してくれるビアバーもある。今年は残念ながら行っていない。

ワインは熟成させることで味がよくなるらしく、ボジョレー・ヌーボーはそれほど美味しくないのだ、と聞いたことがある。真偽のほどは定かではない。一方、ビールは、もともと鮮度が命であるため長期間熟成させるものではない。したがって早い段階で飲むことには、意味がるように思える。

しかしながら、ウィートワインは長期熟成が可能なため、敢えて古いものを飲んで味を楽しめるのだ。解禁日に飲むもよし、後で飲むもよし。悪魔の誘惑である。

ギネス / ドラフトギネス

ギネスのドラフトギネス缶を買ってきた。無造作にグラスに注いでも、缶の中にあるボールのおかげで、細かくクリーミーな泡が立ち、ちょうどよいバランスになる。ローストした大麦を使う黒ビールなので、香ばしい。わずかに酸味がある。香ばしさと酸味で、味がしまっている。

ビールが好きだ、と言うと、やっぱりドイツビールがいいのかと聞かれる。実はドイツビールよりも、ギネスなどのアイリッシュビールが好きだ。特に白っぽいビールよりも、黒いビールが好きである。黒ビールの焙煎された麦の香ばしさが好きなのだ。

などと話したりすると、今度は自分で醸造しないのか、と言われることもある。ビールに関しては消費に徹すると決めている。例えば黒ビールが好きだからと、麦をローストしたとしよう。苦味が欲しくなって様々なホップを買い漁る。飲み比べたいので、同時にいろいろ作る。簡易でいいから広い場所が欲しくなって、借金して場所を借りたりする。

だが思い出してみよう。そもそもビールで商売をする気はないのだ。ただ味わいたかっただけなのだ。儲けがないので、借金も返せなくなる。金を貸してくれた銀行にしてみたら、ビールだけでなくローンが焦げ付いてしまうのだ。

箕面ビール / ゴッドファーザー２

久々にふらりとビアバーに行った。変わったビールはあるかと聞いたら、箕面ビールのゴッドファーザー２を出してくれた。「みのお」と読む。大阪府北部の市である。山本太郎が卒業した箕面自由学園がある。ゴッドファーザー２は、ベルジャン酵母を使ったスタウトで、柚子の皮を漬け込んだビールである。

ベルジャン酵母、つまりベルギービールで使われる酵母を使ったビールは、傾向としてフルーティな味になる。柔らかい香りと甘みがある。日本のラガーとはかなり違う。ただし、炎天下でキンキンに冷やすと、中途半端な香りが口に残る感じがする。傾向として。美味しいかどうかは、そのビールと、人の好みによる。個人的には、ベルジャンには苦手な味のビールは、けっこうある。

スタウトは、しっかりめにローストした麦を使ったビールだ。黒いビールになる。味は香ばしい味と香りになる。ホップの苦さとは違う。これも好みによる。焦げ臭く感じる人もいるだろう。私は好んで飲む。

柚子である。このビールは、柚子の皮だけを使って風味付けがされている。酸っぱさはないが、柑橘系の苦く爽やかな風味がある。スタウトの香ばしさに負けない、だが、ベルジャンの柔らかさを殺さない風味である。柑橘好きとしては好きな風味である。マッチョには受けないかもしれない。ちなみに柚子の未のほうは、ポン酢になるらしい。

非常に複雑なビールだ。10人いれば、10とおりの評価になるだろう。意見がばらばらなので、箕面スパーガーデンに行くことにする。

コナ / ビッグウェーブ・ゴールデンエール

コナ・ブリューイングのビッグウェーブ・ゴールデンエールを買ってきた。穀物っぽい味、しっかりした苦味のあるエール。暑いところで、飲むのに合っている。

イラッとすることがあった。イラッとしているときに、ホップの効いた苦いビールを飲むと、すっきりする。意識が苦さに集中して、細かいことを気にしなくなるからだろう。

飲み終わって、ふとメールを見たりして、またイライラしていたことを思い出す。これはいかん、と思って冷蔵庫に向かい、さらに苦いビールを飲む。落ち着く。メールを見る。イラッとする。ビールを飲む。繰り返す。

これでは躁鬱で苦しんでいる人みたいだ。どうも浮き沈みが激しい。

サンクトガーレン / 湘南ゴールド

サンクトガーレンの湘南ゴールドは、横浜の柑橘である湘南ゴールドを漬け込んだ、エールだ。「げっぷまでオレンジ」と記述されていることが多い。嘘ではないし、間違ってはいないが、勘違いされやすい。オレンジジュースとビールを混ぜたもの、みたいな感じではない。やや苦味のあるエールで、オレンジの皮の苦味がある、というのが近い。バッチによっては甘みがある。

湘南ゴールドは夏に合うビールだ。昨年の夏は、湘南の海に毎週のように行って、トライアスロンレースにそなえて泳いでいた。海の家では、湘南ゴールドは売られていないことが多い。

ひとりで泳ぐだけではなく、海でのスイムを教えてくれる教室にもいった。湘南ベルマーレという、トライアスロンチームを持つスポーツクラブがある。クラブ主催のスイミング教室があり、海での泳ぎ方のコツを教わった。

湘南ベルマーレで有名なのはサッカーチームだ。オフィシャルビールが、湘南ゴールドである。スタジアムに行くと飲めるらしい。最近は J1 と J2 を行ったり来たりしているそうで、頑張ってほしい。応援しているビールを飲みながら、応援しているチームが勝つと、きっと嬉しいだろう。湘南ゴールっと。

ベルビュー / クリーク

ベルビュー醸造所のクリークというビールがある。ビールとは思えない、チェリージュースのような甘酸っぱい炭酸飲料である。アルコール度数は、普通のビールと同程度の5%である。

ベルギーには、麦汁だけ用意しておくと、そこらへんに漂っている菌がついて、ビールを醸造できる地域がある。この製法で作られたビールをランビックという。日本で普段飲むビールと比べると、苦味がなく、非常に酸っぱい。ランビックに、クリークと呼ばれるチェリーを混ぜてつくられたのが、ベルビュー醸造所のクリークである。ここまで、ほとんどの情報は、漫画「もやしもん」が出典である。

知人（ここでは某としておこう）とベルビュー・クリークを飲んだことを思いだす。某と私は、外国の食材やお酒が売られている気取ったスーパーに行き、ベルギービールを飲もうと、カゴにビールを放り込んでいた。某は「総ての工程が終わってからではなく、醸造の段階でチェリーを入れるのがクリークなのだ」などと話しており、私は「めんどくせーよ」などと言い返したと記憶している。どちらにしてもお互い知ったかぶりで、ベルギービールを買った。

知識がないながらも、楽しくクリークや白ビールを飲んでいた。買ったビールにはランビックも含まれていた。某は知識ゼロでランビックを口に運んだ。あまりの酸っぱさに、私の自宅であるにも関わらず吐き出し「ぐへっ、これはダメだ、腐ってる、ぜったいヤバイ」と取り乱した。錯乱某である。

サンクトガーレン / ジンジャー IPA

仕事帰りに、サンクトガーレンのジンジャー IPA を飲んだ。八重洲にあるビアパブ「バッカス」開店6周年を祝って醸造さ
れたビールだ。ジンジャーエールでビールを割った、シャンディガフとは違う。しっかり味もアルコールも濃いのだが、風邪が治りそうな勢いで生姜が効いている。ビールの苦味と合う。

だらだらと飲んでいたら、大きな荷物を持った外国人が隣に座った。オーストラリアから着いたところで、北海道にスノーボードに行くらしい。休日に一人で飲み歩いてるのかと聞かれたので、仕事なのだと答えた。

基本的に月曜から金曜が勤務の仕事なのだが、状況に応じて土日にも仕事をすることがあるのだ、と言ったのだが通じない。それが、私の英語が拙いからなのか、異文化の壁のせいなのか、彼らの英語がしょぼいからなのかは分からない。

どんな種類の仕事なのか、どういう商慣習のある業界なのか、など話してみたが首をかしげるばかりだ。面倒なので、日本のアニメや、サケや、ニンジャの話をするのだけれど、すぐに仕事の話に戻ってくる。いい加減に面倒になってくる。しかたないだろう、仕様が決まらないのだから。

オリオンビール / オリオン ドラフトビール

コンビニに行くと、オリオンビールのオリオンドラフトビールが棚に並んでいた。飲んだら、すっきりと味が引いていき、少しアルコール感が漂ったあと、これもすぐに引いていく。暑い日にのどごしで飲むと、もっと美味しいだろう。

あいにく今は冬だ。オリオン座がよく見える。ギリシャ神話の英雄で、さそりを追いかけてるとかいう設定だ。英雄だと足を怪我したとか、いろんなことを記録に残され、勝手に星座にさせられ、冬空を飾らなければならない。英雄も損な役回りである。

ここまで書いて気づいたが、足を怪我したのはオリオンではなく、アキレスである。アキレス腱と言うではないか。中途半端すぎる情報を持っている人間の発言に、夜空の神々は辟易しているだろう。

「相変わらず足が痛むんですか？」

「人違いですやん。それアキレスさんでっせ。私はさそりを追いかけてるだけですねん」

「そうでしたか。そしたら、なんで、足ひきずってますのん？」

「正座やってると、足が痺れますねん」

鬼伝説 / 金鬼ペールエール

鬼伝説の金鬼ペールエールは、エールの持つしっかりした味に、華やかな苦味が強く出ているビールだ。華やかな苦味、というのを理解できたのは、このビールだった。苦いのだけれど、とても華やかなのだ。

金鬼ペールエールを飲むまでは、Python 忘年会に出ていた。久しぶりに会う人や、ちょっと前に会ったけど今回初めてゆっくり話す人がいた。リラックスしつつも、刺激を受ける寄り合いだ。Haskell が得意で、Erlang で仕事すると聞いて入社したら、Django でウェブアプリ書いている若者もいた。強く生きて欲しい。

今年のことは忘れたので、来年のことを考える。新しい言語を使ってみるとか、フレームワークを作ってみるとか、やりたいことは色々ある。よく分からないので、ここは明言せずにいる。

来年で東京に出てきて10年なので、その頃、お酒の嗜み方を見せてくれた方と、当時に行ったバーを巡ってみるのもいいかも知れない。来年の話ばかりしていたので、笑われてそうだ。

ヘリオスブルワリー / 天使の RED ALE

ヘリオスブルワリーの天使の RED ALE なるものを、コンビニの棚で発見した。すなわち、冷蔵庫で発見したこととほぼ同義であるがゆえ、レジで支払って帰宅した。ローストした大麦らしい甘さがある。

沖縄の水を使っているので味が柔らかい。苦さは控えめ、と見せかけてそこそこホップが効いている。しかしながら、カラメルモルトの甘さに、うまく抱擁されている。アルコール度数は 5% 。

味の薄い料理には味の薄いビール、味の濃い料理には味の濃いビールが合うと言われている。誰が言っているかというと、いつぞやのビール講習会の講師である。このレッドエールは、いろんな料理に合いそうだ。寿司と一緒でも、魚や貝の味をじゃましない。ステーキと一緒でも、肉とソースに負けない。そういう感じがする。

薄味、濃味の間の料理はなんだろうか。パスタか。濃厚なカルボナーラ、カニやエビのクリームソースのパスタといったところか。しっかり味がありつつも、パスタとソースを合わせるることで微妙な味が楽しめそうな種類の料理である。絡める盛る、と、いうわけである。

サンクトガーレン / YOKOHAMA XPA

サンクトガーレンの YOKOHAMA XPA は、軽く華やかで柑橘を思わせるホップの香りと、苦さが特徴のインディア・ペール・エールだ。飲んだ後で、舌にほんのりと甘さが残る。渋みは少ない。YOKOHAMA は、横浜市オフィシャルウォーター「はまっ子どうし」を使っていることに由来する。

XPA は Extra Pale Ale の略だが、IPA (India Pale Ale) との違いがよく分からない。いずれにしってもホップが多めの苦いビールである。似た名前で、似た意味なので、大きな問題ではない。

Java と JavaScript は名前が似ているが、およそ異なるものなので混乱と誤解が多い。インドとインドネシアも同様の状況だ。西インド諸島もかなりなことになっている。南北アメリカの間にある諸島のことだ。カリブ海あたりである。

西インド諸島の子どもたちが、インドがどこにあるかを知った時は驚愕であろう。「インドって、ここより、ちょい東くらいかなぁ」「だろうね。地図を見てみよう」「えー、ぜんぜん違うじゃん」「つーか、俺らって別にインドと関係ないじゃん」などという会話をするのだ。バハマっ子どうしで。

サッポロビール / 琥珀ヱビス

琥珀ヱビスは、軽くローストした麦芽を使うアンバーラガー。普通のヱビスに比べて、香ばしい味と香りがする。とは言え、極端ではないし、カラメル風味の甘さがある。期間限定ではあるけれど、コンビニやスーパーで手に入る。手軽だ。

以前、恵比寿の近くに住んでいたことがある。他の地域に比べて、飲み屋もコンビニも、エビスビール置いている率が高い。さすが、ヱビスビールがあったから、恵比寿という地名になっただけのことはある。

部屋の暖房をつけてビールを飲んでいたら、暑くなってきた。窓を開けて空を見る。子供の頃、星座に興味を持ってしまい、断続的に寝たり起きたりして星空を見ていたことがある。夜中のほうが星が見やすく、少し季節をずらした星座が見えた。

今では星を見ても、どの星がどの星座なのかまったく分からない。織姫と彦星も見つけられない。永遠に出会えなくなってしまうのでは、と勝手に責任を感じてしまう。短冊にふたりが逢えるように書いておかねばなるまい。笹を持ってこい、ということか。

ヤッホーブルーイング / よなよなエール

りんごばかりを食べさせた牛の肉を食べたことがある。さすがに、りんご味ではない。りんごの香りがあり、美味しかった。

生ハムの原料のイベリコ豚は、どんぐりを食べさせるらしい。甘い肉になるのは餌のおかげらしい。

味が濃いめ料理には、味が濃いめのビールがよく合う。ヤッホーブルーイングのよなよなエールは、ボディも苦味もしっかりしている。ビール好きな人なら、クラフトビール初挑戦におすすめ。ただ、時間がたつと、あるいは温度が上がると、渋みがでてくる。

そんな、よなよなエールを今夜も飲んでいる。年明けには渋いオヤジになれるはずだ。

セルヴェッサ・キルメス

セルヴェッサ・キルメスは、アルゼンチンの都市キルメスのビール醸造所または、そのビールだ。熱い気候に合う、軽くてすっきりな飲みくちだけれど、ドイツビールっぽい甘さがわずかにある。

来年は、アルゼンチンの隣国ブラジルで、サッカーのワールドカップが開催される。決勝リーグのグループが抽選で決まり、アルゼンチンは楽に決勝トーナメントに上がれそうだ。30年ぶりの南米開催で盛り上がっていることだろう。

というようなサッカー談義を、整体師にされた。「休みの日はなにしてますか？」「寝てます」「運動したりしませんか？」「しません」「観戦も？」「いえ」という、つながりのない会話をした。かわいそうになったので「サッカーワールドカップのグループが決まりましたね」と言ったら、各グループの話になった。まったく興味はない。

その後、話題は日本のプロサッカーリーグに移った。湘南ベルマーレのオフィシャルビールの話をしようかなと思った。それなら話せるからだ。整体師は関西のチームを贔屓にしているらしく、ビールの話にはならずに終了。どうもパスがつながらない。

サンクトガーレン / アップルシナモンエール

焼きりんごとシナモンを入れて醸造したビールがある。サンクトガーレンのアップルシナモンエールだ。麦芽とホップ以外の材料が入っているので、酒税法上は発泡酒である。しっかりビールでありながら、りんごの甘さとシナモンの香りで、飲むアップルパイだと言われている。私が言っている。

今年のできがそうなのか、このバッチがそうなのか、口の大きいグラスで飲んだからなのか、シナモンの香りがふわっと広がる。りんごの甘さ、モルトの甘さのコントラストで、シナモンが香辛料であることを思い出す。

自宅にはビール専用の冷蔵庫があって、ビールのボトルやカンだけが入っている。ときどき日本酒やワインやウコンの力が入っている。自宅ではほとんど飲んでいるか寝ているか食べているか、だ。最近は外食かコンビニ弁当が多い。

今借りている部屋は、少し大きすぎるかも知れない。ベッドと冷蔵庫があればよいのだ。さっさと引っ越せば、安くあがる。時期をうまく計画すれば、節約できるお金として、更新料があることを思い出す。

キリン / 一番搾り とれたてホップ

仕事が立て込んだり、困ったことがあったりすると、無意識に爪を噛んでいることがある。普段は飲まないハーブティーのティーバッグを買ってきて、ゆっくり飲む。ハーブは刺激物だけれど、少量ならほっとする。採れたてのハーブを口に含んだら、ほっとするどころではないだろう。

キリンの一番搾りとれたてホップは、冷凍保存したホップを戻して使っているらしい。だからなのかは不明だが、みずみずしい苦さがある。

ビールを片手にテレビを見るともなく見ていると、アナログ時代に読んだコラムを思い出した。曰く、スタジオで撮ってすぐの映像は綺麗だが、放送されて受像するころにはかなり劣化する、と。撮れたては綺麗だったらしい。

リラックスしていたはずなのに、やはり爪を噛んでいることに気づいた。子供の頃、ウルトラマンのビニール人形で遊んでいたはずなのに、気づけばかじっていたことがある。無惨に取れた手を、思い出した。

キリン / グランドキリン ジ アロマ

グランドキリンは、キリンの他のビールに比べて、味がしっかりしていて、ホップの香りが強い。ボトルの口が大きく、飲むときには、さらに香りが広がる。

ハワイ島ワイコロアにあるヒルトンに、キリンという中華料理レストランがある。料理は広東、四川、湖南、北京とそろっている。ビールは、バドワイザーや地元のクラフトビールなどがある。キリンビールがあったかは覚えていない。

このレストランに行く数日前、マラソンに出た。店員も近くでマラソンがあったことを知っていて、話題になる。完走したのか、それはすごい。僕ならしんでしまうよ。と、英雄のように扱ってくれる。

気をよくして、そもそもマラソンとはとか、練習がすべてだとか、スタートラインに立った時には結果は決まっているのだとか、君もしっかり練習すれば走れるよ、などと語る。実のところ6時間以上かかったのだから、完歩である。我ながら大口を叩いたものだ。

サンクトガーレン / ペール・エール

サンクトガーレンのペールエールは、ドライホップなる方法で味付け、あるいは、香りづけをしている。原材料を混ぜた後、発酵しているフェーズでわざわざホップを投入し、香りを際立たせる。後で香をつけるのは、工程が地味に面倒だし、このフェーズのあとは高温殺菌がないだろうから、何かと気を使うらしい。

ウェブサービスを作ることを生業にするようになって、4年がすぎた。気にしていること、あるいは付加価値が高いと認識していることは、突然の仕様変更に対応できるようにすることだ。「ここにこんなボタンがあるといいな」という些細に見える変更であっても、裏側で変更は大規模になることがある。

変更に対するリアクションには2種類がある。1つの極端なリアクションは「そんなことは聞いていない」と突っぱねることだ。これは実はとても正しい対応だ。あらかじめ、こうやって欲しいのだがいくらなのか？という問いに見積りという形で答え、それをベースに契約しているからだ。


ところが、商慣習的にばっさり切りにくい場合がある。そして、ほぼ間違いないく仕様変更は発生する。本当の問題は、発注側が仕様変更することを予測できていないことなのだ。だから、時間の許す限り変更を受け入れられるようにシステムを作る。それでも、予期しない変更にはてこずる。後付けするときには、何かと気を使うものなのだ。

サンクトガーレン / ゴールデン・エール

Python Developer Festa 2013.11 で、Python 3.4 で追加される標準ライブラリを紹介した。最近プレゼンテーションの準備がおろそかになっている。調査に時間をかけたとしても、コンテンツはほとんど変わらないだろう。発表自体の準備不足を自覚している。

準備が足りないと、無理に喋って間をつなぐ癖がある。Python 3.4 を知らない人に知らせる、という発表で、ぺらぺら休みなく話すと、聞いているほうが頭を整理しにくくなる。咀嚼する時間を意図的に提供したほうが、目的達成に近づく。

サンクトガーレンのゴールデンエールを飲みながら考えていた。やわらかく飲みやすい味で、苦味も抑え気味だ。よくあるラガービールとどう違うのか聞かれると、味がしっかりしてるとかな、程度のぼんやりした答えをしてしまう。けれど、明らかに違う。

一見小さな違いだけれど、確実に異なるものを比較する時には、五感を集中させなければならない。ぺらぺら喋りながらでは、なかなか気づかない。沈黙は金なのだ。

サントリー / ザ・プレミアム・モルツ

サントリーのザ・プレミアム・モルツは、飲みくちすっきり、でも、味がしっかりしているラガービールです。

日本の4大ビールメーカーの製品ラインナップは、普通のラガービールと、プレミアムなラガービールの二本立ての印象があります。サントリーにもモルツがあるはずなのですが、スーパーやコンビニではザ・プレミアム・モルツしか見かけません。

ラガービールはすっきりした味で、のどごしで飲むビールです。高温多湿な日本の夏には、飲みやすいですね。夏には日本のラガービールを、ぐびぐびっと飲むと爽快感があります。日本のおいしい軟水で仕上げているので余計においしい。

そんなラガービールの醸造に使う酵母は、低温な軟水でも活動できるそうです。低温とか高温って、相対的なのでよく分かりませんね。どのくらいの温度なのか聞いてみたことがあります。「低いって何度くらいなんですか？ へー、十度。」

Google App Engine から backlog.jp の API にアクセスする

Google App Engine から backlog.jp の API にアクセスしようとしたら、何やらエラーが出ました。 libbacklog は xmlrpc を使っていて、xmlrpc は socket を使っていて、Google App Engine では無料枠では socket 使えないのですよね。ちょっとしたツールを作ることが目的だったので、まずはその場しのぎすることにしました。Making XML-RPC calls from a Google App Engine application をちょっと変えただけです。

結局、このツールは使う必要がなくなったのですが、もしものときのために書き置きしておきます。

PyCon APAC 2013 に行ってきました

2013年9月14日、15日にPyCON APAC 2013 に行ってきました。ほんとは、今日はスプリントをやっているそうですが、自宅でだらだらしています。だらだらしながら、Evernote のメモを、ここに書き写すことにしました。

（9/16 23:30 ごろ: イアン・ルイス氏のプレゼンの感想を追記）

自分自身の発表

"Test Failed, Then..." というタイトルで、以前に書いた「requests でテストした、その後ですよ」の内容を、ラッパのコードだけではなくて、なんでそもそもそういうことをしているのか、という視点で話しました。コンポーネントだけでなく、人も疎結合にしたいのですよ、私は。

プレゼンテーション資料は、しゃべりがあることを前提に作るので、この内容だけでは伝わらないような気がします。You Tube に動画があがっていますが、話し始める前に動画が終了します。演台の後ならばれないと思ったのですが、パンツ履いていないのが見えたためカットされたのでしょう。

いつか、まとめて文章にするかも。

Programming AWS with Python

VPN を設定するときに boto でやるとどんな感じなのかな、と思って聞いていたら、かなり簡単そうである、というのが分かりました。これは試してみます。

Release Faster

David Cramer 氏による、継続的リリースの考え方と必要条件の話でした。内容自体はおそらくは、継続的デリバリーや devops の文脈で語られる話を総括したものです。ですが、ちと思い入れがあります。

Cramer 氏は2012年の PyCON US で Practicing Continuous Deployment という演題で発表をしています。この発表の practical さに感動し、自分のプロジェクトに少しずつ取り込んでいき、その結果を、昨年の PyCon JP で Trying Continuous Delivery という演題で発表しました。DISQUS から Dropbox へ移った Cramer 氏の発表を聞きたいなぁと wktk で行きました。

ブートストラップ

• 新メンバーが速く仕事できるように環境設定は自動化
• 依存性をできるだけ排除
• 本当に必要なものだけインストールする。Apache、HAProxy、RabitMQ、Zookeeper、Hadoop はアプリ開発者のローカルには、初日には要らないだろう。

テスト

• テストさえあれば、まあなんとかやってける
• ツールを整備することで、文化に影響を与える
• テスト書きたくなるようにする
• コピペでもいいから、とにかく書きたくさせる
• pytest, flake8, mock
• 素早いフィードバック

レビュー

• 壊れたマージを防ぐ
• 「この変更ってまともかな？」

フィーチャ・ゲート

• 一部の人にだけ機能を追加/変更する
• 社内でリリースするのは、外部に対してリリースするのと同じ効果がある
• gargoyle  Django 用のフィーチャゲート

その他

• ツールの提供を通して、文化を浸透させる
• インフラのビルドには時間がかかるので、最後に成功したビルドのスナップショットをとっておき、続きからやることでスピードアップする

Does Python dream of being unleashed?

Google App Engine の実験的機能 VM backend の紹介。Google App Engine のバックエンドサーバに、Google Compute Engine のインスタンスが使えるようになるそうです。まだ trusted tester のみ。

• apt-get のみ管理者権限で実行できる。
• /_ah/start でシェルを呼び出せる（ので、ユーザ領域で好きなことできる）
• TCP, UDP 使える
• CGI, WSGI 経由のリクエストは、これまでどおりの書き方でOK
• URL による frontendとbackend の振り分けもこれまでどおりOK

これは気になります。やりたいことがいっぱいある。

Luigi, The Friendly Pipeline Plumber

俺達のイアン・ルイス氏によるツールの紹介。入力、出力（ファイル）、タスクを定義しておいて実行すると、依存関係を解決して順番にタスクを実行してくれるツールである luigi 。

このセッションが、いちばん即効性がありました。というのは、日付からネットワーク上に保存されているデータを特定してダウンロードし、加工して保存し、それをさらに加工や修正をする、という仕事があるのです。あるのですが、これがたまーーーーにしかやってこないので、ほったらかしになってて、やる度にちょっとずつバグを修正している感じです。Luigi は失敗したファイルを生成しない＝そのタスクは終わっていない、ってことになっているので、コードを修正したら、そこから再実行してくれるのです。

今は、Make を使っているんですが、Luigi に乗り換えるのがいいなと思い始めました。Make で呼び出しているひとつひとつのタスクは、Python で書いてあるので移植も簡単だと思います。

おわりに

主催者のみなさん、ありがとうございました。10人の宴会どころか、4人の飲み会の幹事もできない私には想像もできないような大変なことだったことでしょう。

来年の PyCon APAC は台湾らしいです。PyCon US や Euro Python と違って近いので、行きたいなぁと思い始めました。そういう風にふらっと出ていける仕事の回し方ができるようになるといいなぁ。

David Cramer 氏と話をしたかったのですが、何を話していいのか分からず、結局ひとことも話していません。話すことがないのに話す必要もないわけですが。

英語も、プレゼンももっと練習しないとなぁと痛感。去年も思ったような気がしつつ。せっかく時間を割いて聞いてくれているのだから、もうちょいうまくならねば失礼ってもんです。しかもプレゼンのときすごく体がガチガチだったらしく、終わってから腰が痛くて、帰り道で休憩しないと動き出せないくらい疲れました。何やってんだか。

質問タイムでも、その後のパーティでも、「そのアプローチで、一体に何を作っているのか？」と、何人にも聞かれました。需要がありそうなので、機会があればまとめてみようと思います。

森博嗣「ヴォイド・シェイパ」「ブラッド・スクーパ」

森博嗣の剣豪小説シリーズの1作目「ヴォイド・シェイパ」と2作目「ブラッド・スクーパ」を読んだ。物心ついたときから、山の中で師匠と暮らし、師匠の死後に山を降りてきた侍ゼンが主人公。一人称で物語は進み、生死や人の価値について思索しながら旅をする。スカイクロラに近い文体で、剣術バトルがときどき描かれる。戦いや他の人との会話を通して思索していく流れもスカイクロラっぽいし、全体的に静かな感じも似ている。剣豪小説という体ではあるけれど、時代や場所がまったく分からない。登場人物の名前もカタカナ表記されている。

ここから、全力でネタバレと、私の妄想を無粋にも書き連ねる。スカイクロラをはじめ、他の作品にも言及するので、そのつもりで。


 






主人公ゼンが「この国よりももっと大きな、すべての国を統一する方」の血筋であるようなことが、ほのめかされる。時代背景は不明。性別が明に記述されてない人物が何人かいる。主人公はやたらと内省する一方で、あまり深く考えてない人物とよく関わる。どうも狭い世界に閉じられている印象があって、これは世界の構造がスカイクロラや、百年シリーズと似ている。

スカイクロラでは、戦争請負会社が戦争していて、戦局などは一切出てこない。ただ戦争している。登場人物の名前は日本っぽいがカタカナ表記で、出自が分からない。

百年シリーズのルナティックシティもイルサンボックも、閉じられた街で住民の生活が完結していて、外の世界の状態がよく分からない。外の世界から分離した状態になっている。Gシリーズで真賀田四季がほそぼそとやっていた実験が、外乱の少ない環境でさらに進められているように見える。サエバミチルは真賀田四季（と久慈）の子孫だろうから、国より上のレイヤを統一する者の血筋だ。

無粋な妄想というのは、スカイクロラとヴォイド・シェイパの世界は、真賀田四季がいる世界だろう、ということだ。真賀田四季の箱庭が描かれている、と思いながら読んでいる。

おまえらこのライブラリ使ってないの? m9 (2013-07)

pyfes 2013.07 に行ってきました。最近、ぜんぜんコードを書いていないので、この機会にエディタを開いてコードを書いたのは楽しかったです。数行のサンプルだけですけどね。

bpython ちょっと使ってみたら面白そうでした。あと suddendeath, xaxtsuxo, aodag.scaffold も便利だよという意見もあったので、気が向いたらカバーします（しねぇよ）。

おまえらこのライブラリ使ってないの? m9 (2013-07) from Toru Furukawa

とりあえず10分、を始めて1年

自習できる人をうらやましがっている増田がいました。

会社を定時上がりしてもダラダラパソコンやったり携帯見てしまう

無駄な時間だと思っててもあとちょっとだけを繰り返して23時

文章どおり受け取り、かつ、勝手に妄想で補完すると、自習自体ができないんじゃなくて、取りかかるのが億劫なんだと思います。それにはとても共感します。自分もずーっとそんな感じだから。想像するだけだでしんどさ、面倒くささに圧倒されて、結局何もやらずに済ませていまいます。

そんな自分もとりあえず10分だけやるというのを実践しはじめて、1年くらいたちました。10分たったたらどんなに進展がなくてもやめてもいい、というルールもつけてます。

よいニュースと悪いニュースがあります。ほんとに何もできずに終わる日もありますが（ほとんどがこのパターン）、気分が乗ってきて数時間続けている日もあります。Better than nothing と言い聞かせて、あんまりしんどい思いをせずに、少しずつだけど何らかの意味ある活動に時間を費やせるようになりました。悪いニュースは、この活動が直接的に昇給など、目に見える結果には反映されていないことです。闇雲に仕事をしたからって昇給しないのと同じですね。

さてさて。こういうプラクティスを、TODO管理ツールなりカレンダーなり、しくみやツールに自然に組み込めるといいんだろうな、と思っています。

Go で関数に型っぽく渡す

先日、Go の型は First-class ではないことを、ぐずぐず書いていたら、こんなコメントがありました。

reflect.ValueOf(x).Type().Name() で型取れますよね？そういう話ではなく？&Foo{} とか？ / “Go の型は First-class ではない: Addicted To Indentation” htn.to/L2rfDQ

— mattnさん (@mattn_jp) 2013年5月8日

もともと困っていたのは、型を引数にできないことでした。そして、見たところ Go は型（int とか、type Foo struct{...} の Foo とか）を引数にできません。できないのですが、やりたいことは「型をわたすこと」ではありません。

やりたいことは、「クエリ対象の指定をもうちょい安全にしたい」です。NewQuery(c, "Foo") だと "Eoo" と書いて渡してもコンパイルを通ってしまい実行時にエラーになるけれど、すでに定義してある Foo 型を使うのだ、と記述することができれば少しは安全側に倒れるのではないか、と考えたわけです。その仮定で、型を知らせるために、使いもしない変数を定義することに居心地の悪さを感じていました。

そこで @mattn さんの &Foo{} という書き方ですよ。f(&Foo{}) や f(Foo{}) と書けば型を知らせているのだ、と分かりやすいし、余計な変数宣言もないしで、なかなかいい。たぶん Foo 型の値が生成されそうで、要らないメモリだろうと思ったりもしましたが、自分が書くコードではもっと別なボトルネックがありそうです。そんなわけで、この書き方いいなぁと思っています。

あとですね。そもそも型を渡して〜というアプローチが、 Go の考え方に合っていない気がしています。先日のブログにも書いたのですが、ここではクエリを発行して、そのあとデータストアから Foo の配列に値を取ってくるわけです。非同期に実行するとしても chan を使うでしょう。なので Foo の型情報を持った変数が、文脈上あとで必ず出てきます。であれば、ここからここまでで Foo 配列に対する操作をしまっせー、という中にクエリ発行が出現する、という書き方もできて、それが合っている気もしてきました。

Go の型は First-class ではない

Go の型は First-class ではない、ということにゴールデンウィーク最終日に気づき、悶々としています。（何も Go が悪いわけではない）

ことの発端は、以下の様な関数を定義したところから始まります。

func getName(x interface{}) string {
  return reflect.TypeOf(x).Elem().Name()
}

この関数に、任意の型のポインタをわたすと、型の名前を取得できます。けど、ポインタを渡さなければならないのですね。

  var foo *Foo
  name := getName(foo)

foo は使わないのに！ 使わないというのはウソですね。けど、ちょっと違うんですよ。まあこれは私がPython 脳だからであって、別にGoが悪いわけじゃない。

何をしたいかと言うとですね、Google App Engine datastore のクエリの生成をラップしたいのです。標準ライブラリを使うと、以下のように書きます。

  c := appengine.NewContext(r)
  q := datastore.NewQuery("Foo")  // ☜(◉ɷ◉ )
  q.Filter("Y =", "xaxtsuxo")
  foos := make([]Foo, 0, 10)
  keys, err := q.GetAll(c, &foos)

Foo が型が定義されているのに、文字列で "Foo" を渡すのが悔しいわけです。そこはコンパイル時にスペルミスをひっかけて欲しいわけですよ。ストアされているデータと、Foo の定義が違うと、それはそれで実行時エラーになるんだけど。なので、

func createQuery(AnyType) *datastore.Query

のような関数を定義したいな、と思ったのですね。ところが、型は渡せないのです。以下のような方法に落ち着きます。

func createQuery(x interface{}) *datastore.Query {
  kind := reflect.TypeOf(x).Elem().Name()
  q := datastore.NewQuery(kind)
  return q
}

…

  var foo *Foo
  q := createQuery(foo).Filter("Y =", "xaxtsuxo")
  var foos := make([]Foo, 0, 10)
  keys, err := q.GetAll(c, &foos)

あぁ foo 使わないのに。いや、 配列の foos があるんで、そっち使えよって話なんだけど。なんなら GetAll せずに、foo を使ってイテレートするのが筋なのかも知れません。

ああ、そんなこと言い出したら、Filter にだって文字列を渡してるぞ。そう考えると GAE/Python の NDB はよくできてるなぁ、あのライブラリ作った人は Python のことよく分かってるなぁ。薄いラッパにしたかったんだけど、やっぱり厚くなってしまうのかなぁ。PropertyList とか PropertyLoadSaver をうまく使ったらよいのか？ ぎゃぁ。というわけで連休が終わってしまったので、ペースダウンしていきます。

Go の struct に任意の名前のフィールドがあるか調べる

静的型付け言語たる Go ですが、実行時にごにょごにょすることを reflection と言うらしく、reflect パッケージが標準で入っています。

v := Foo{}
structField, found := reflect.TypeOf(v).FieldByName("x")

Foo 型に x フィールドが存在すれば、found に true が入ります。http://play.golang.org/p/F9TY4RcBEC

値とポインタは異なった型なので、もとの struct にたどり着くまでの道筋が異なります。 http://play.golang.org/p/_V19gURisU

v := Foo{}
typeFromValue := reflect.TypeOf(v) 

p := new(Foo)
typeFromPointer := reflect.TypeOf(p).Elem()

それから struct 定義のとき、各フィールドにタグをつけられますが、これも reflect パッケージを使って取得できます。http://play.golang.org/p/K__zcCZ7Nd

type Foo struct {
 int
 x string `wozozo:"show" hoge:"fuga"`
}

func main() {
 v := Foo{}
 t := reflect.TypeOf(v)
 field, _ := t.FieldByName("x")
 fmt.Println(field.Tag)  // => `wozozo:"show" hoge:"fuga"`
 fmt.Println(field.Tag.Get("wozozo")) // => show
}

フィールドにつけるタグは文字列ならなんでもいいのですが、key:"value" のフォーマットをスペース区切りにしたものを定義すると、structTag.Get(key) で value を取得できます。Google App Engine では、エンティティのフィールド定義に struct を書くときに、インデックスしてくれるな、とか、struct には含むけどエンティティとして保存するな、のような指示に使われています。

input type="datetime" で、ブラウザから素早く日時を入力する

ブラウザから日時を入力させたくて、どうすれば素早く入力できるのかなぁと、いくつか試しました。前提は Bootstrap の responsive を使って、PC とスマートフォンで同じHTML/CSS を使う、ということです。別に、PCとスマートフォンで分けてもいいんだけど、まずは動くものを作りたいので、ブラウザ判定とかしない方向で。一方で、自分が使っている環境、Chrome on Mac OS X と Safari/Chrome on iOS 6、動けばよいので他のブラウザでの互換性は気にしていない。Android とか危うい気がする。

いくつか試してみたところ、 HTML5 の input タグの属性に type="datetime" や type="datetime-local" を指定するのが、いちばん入力しやすく、11秒で入力できました。入力しやすさ、の指標は「iPhone の Safari を使って、テキストフィールドに『ビール飲むぜ』と入力し、さらに、今から1時間以上先のキリのいい時間時刻（今が19:30なら21:00）を入力するまでの時間」です。

他の方法は以下のとおり。

• すべてテキストフィールド: 約30秒
• select と option タグ。分は10分刻み: 約30秒
• Bootstrap DateTime Picker
  • 日時をひとつのフィールドで: 約30秒
  • 日付と時刻を、別々のフィールドで: 約20秒

意外とどれを使ってもあまり変わらず。iPhone の場合、wheel scroller っていうんですかね、あれを、複数項目に対して使えるかどうか、が鍵なのかも知れません。

Go で時刻から文字列を生成する

Go で時刻を文字列にフォーマットしたくなりました。結論から言うと、time.Time 型の Format 関数の引数に、「2006年1月2日午前3時4分5秒」を、どう表現したいのかを指定します。

t := time.Time.Now()
var x := t.Format("01/02 15:04")

とすると、現在時刻をこの書式で文字列になります。

最初、t.Format("%y") とか %Y とかしても、そのまま %y とか表示されてしまい、困惑していました。ドキュメントを、一瞥したら

The layout defines the format by showing the representation of the standard time,

Mon Jan 2 15:04:05 -0700 MST 2006

which is then used to describe the time to be formatted.

と書いてあって「だから年や月のフォーマットはどうやって指定するんだよ」と思ったわけです。

ソースをしばらく眺めていて、あーそういうことであったか、と、やっと分かりました。Parse() 関数も同じ方法で文字列から時刻に変換します。

時刻文字列の書式をこんな方法で指定するのは初めて知りました。知らなかっただけで、実はメジャーなのかも知れません。

明日の自分へ: ドキュメントを読めと、あれほど。

定期的に連絡取りたい人の管理

Luper というアプリを知りました。毎月とか、半年ごととかに連絡とりたいコンタクトを登録しておくと、リマインドしてくれるというもの。

今じゃだめ、後でやる必要がある、というタスクの管理も有用であるなぁと最近思い始めました。いろんなアプリがあると同期や移行が面倒なので、Luper は使わないけど。

8080 番ポートがいつも使われていた

Mac を使っていて、いつも再起動するとローカルの 8080 ポートが使われていて、Google App Engine のローカルサーバを立ち上げようとするとエラーがでました。それで Evernote にメモしてあるコマンドを叩いて終了させる、ということを繰り返していました。なんか、めっちゃバタバタしているとき（つまり、いつも）に、とりあえずやって、そのままだったのです。

自分のクビをしめるのはやめておこう。ってことで。動いていたのは Jenkins です。朦朧とした頭で、ビルド、インストール、設定したら自動で立ち上がるようになっていました。

• /Library/LaunchDaemon/org.jenkins-ci.plist を削除する。これが起動時に呼ばれていました。
• /Library/Application Support/Jenkins ディレクトリを削除する。この中に Jenkins 起動スクリプトが入っていました。
• /Application/jenkins.war を削除する。本体。

スクワットは続くのに、早起きはできないのはなぜか

生活や習慣を変えようと、もう38年くらい努力しているわけですが、なかなかうまくいいきません。Runtastic Squats というアプリのフリー版を使っています。1日おきくらいのスケジュールで、ちょっとずつスクワットの負荷が上がっていくプランを提示してくれるアプリです。加速度センサでスクワットの数も数えてくれます。気に入ってて、スケジュール通りに進んでいますが、もうすぐフリー版のレベル1が終わってしまうので、おそらく有料の Pro に乗り換えることでしょう。Pro になると通知もしてくれるそうです。

一方で、Lift というアプリで早起き習慣を身につけようとしていますが、一向にうまくいきません。Lift は身につけたい習慣を登録/選択して、できたらチェックするというアプリです。別にアプリ自体に大きな欠陥があるようには思えません。Squats に比べて扱う範囲が格段に広いわけですが、それが大きな問題とも思えないわけです。

そこで、早起きの時刻設定の敷居が高すぎる仮説です。Squats は設定がよくできていて、第1回目のセッションは、5回、4回、3回、3回 みたいなのです。こんなの余裕です。一方で、早起き設定は普段の起床時刻よりも、1:30くらい早くてこれは余裕とは言いがたい。いきなり敷居が高いわけです。何かのライフハック記事で「習慣を変えたいなら、最初は damn easy な変化にしておけ」と書かれていました。

というわけで、普段の起床時刻から、5分早くするみたいな damn easy なところから始めようと思います。今夜、酔ってるんで、明日はちょっと厳しいかも知れません。

requests でテストした、その後ですよ

Web API をもつアプリケーションのテストを、Python と requests ライブラリを使って書いています。それはよいのですが、テストが通らなかったときですよ。酔ってますよ、もう、休日に仕事してぜんぜんはかどらなくて。それと、これとは別ですけど。

アプリケーションが Python で書かれていない場合、開発者が Python 環境を自由に使えない場合があります。テストのレポートを再現するためだけに、Python モジュールをインストールしてもらうのも気が引けます。

というわけで、requests を使ったアクセスを、 curl で再現するように hooks に追加することにしました。最初から curl 使えよとか、いろいろあると思いますが、すでにレイヤをまたいで requests 使ってたもので。

import curledrequests as requests
requests.debug = True
requests.post('http://example.com/', auth=("foo", "bar"), data={"hoge":"moge"})

のように書くと、

$ curl http://example.com/ -u 'foo:bar' -w '\n%{http_code}\n'
... ここに body が入る ...
200

と表示されます。これを Web API 開発者に渡して、再現してもらうことができます。gist においてあります。

Go Conference 2013 Spring

Go Conference 2013 Spring 略して GoCon に行ってきました。

A Tour of Go

公式チュートリアルであるところの A Tour of Go というのがあります。1ページにコードと文書があって、Run ボタンをクリックすると実行結果が見られます。以前にこれを読んだことがあったのですが、よく分からないまま Run ボタンを押して、どんどんページを送っていって、結局何も分かっていない、という状態になりました。そこで今回は写経することにしました。

ダウンロードサイト から、OS X のバイナリをダウンロード、インストールして写経をしていたら、主催者の @ymotongpoo が Go Playground を教えてくれました。ブラウザで Go のコードを書いて、その場で実行できます。実行時間が短く、サードパーティのライブラリを必要としないコードであれば、これで簡単に実行できます。そういうわけで、Go Playground でチュートリアルをやっていきました。

ついでに書いたコードを簡単に共有するための URL も生成できます。

変数とポインタ

Go では変数とポインタが明確に区別されます。普段つかっている Python では名前にオブジェクトをバインドするモデルで、事実上すべてがポインタみたいなものです。ここはちょっと注意が必要でした。Go では x = y と書くと x に y のコピーを代入します。ポインタ（というか参照というか）は明示的に & を使います。

package main
import "fmt"

type Foo struct {val int}

func main() {
     f := Foo{0}
     g := f   // 変数なので f のコピー
     h := &f  // ポインタ
   
     f.val++

     fmt.Println(f.val)  // => 1
     fmt.Println(g.val)  // => 0
     fmt.Println(h.val)  // => 1
}

一方 Python では x = y と書くと、x に y のポインタ（というか参照というか）を代入します。コピーを代入するには明示的に copy モジュールを使うという考え方です。

from copy import copy

class Foo(object):
    def __init__(self, val):
        self.val = val

f = Foo(0)
g = copy(f)  # copy
h = f        # pointer

f.val += 1

print(f.val) # => 1
print(g.val) # => 0
print(h.val) # => 1

goroutine

並列処理/並行処理を Go は言語レベルでサポートしていて、go foo(..) と書くと、foo() 関数の呼び出しが非同期で実行できます。

トイレで「goroutine ってコルーチンなんだなぁ」と思っていたのですが、席に戻った瞬間 @Jxck_ さんの発表 で「goroutine はコルーチンではありません」と電撃発言です。どうやら OS のスレッド上で動作する並行ルーチンとして実装されているようです。

実装はおいといて、コルーチンを使ったトランポリンみたいなことが簡単に書けそうです。ちなみにトランポリンの理解は非常に曖昧です。

goroutine として呼び出す時でも、関数は通常の引数をとるので、ポインタを渡すことができます。ということは、複数の goroutine で同じオブジェクトを参照するという事態が起こるんだろうなぁと考えて、簡単なコードを書きました。

package main

import (
  "fmt"
  "time"
)

type Foo struct {
  value int
}

func main() {
  f := Foo{0}  // 初期値は 0
  fmt.Println(f.value)

  go Incr(&f, 1, 1)  // +1
  go Incr(&f, 2, 200) // +2

  time.Sleep(1 * time.Second)
  fmt.Println(f.value)  // => 2
}

func Incr(f *Foo, delta int, wait time.Duration) {
  oldValue := f.value  // 古い値を取得して
  time.Sleep(wait * time.Millisecond)  // しばらく休んで
  f.value = oldValue + delta  // 上書き
}

プロセスをまたいでいる時にどうなるかは不明です。こんなときにスレッドセーフじゃないようなコードを書くなという話なわけです。

並列処理といえば…

#gocon 会場のはじっこで @ikasamt @torufurukawa と熱いFPGAトークしてたらbuchoがハード設計バリバリな人だってことが判明した

— Kazunori Satoさん (@kazunori_279) 2013年4月13日

これは明らかに誤解なのですが、気分がよかったので、Twitter 上では訂正せずにいました。

以前の職場で開発環境/ツールのマーケティングをしていて、そのラインナップに FPGA 用にコードを書くツールが含まれていました。もともとグラフィカルに記述すると、PC 用に実行形式のバイナリを吐き出すというツールで、簡単に並列処理を記述できたのです。そこ発展して FPGA を搭載した I/O ボードの処理をデプロイできる、というツールです。

そんなわけでハードの設計は、まったくできません。ただFPGAを使うときにはプログラムの書き方が、大きく変わる、というのは感じています。Go も並列処理を念頭においた言語らしいので、あらためて並列処理を考える時期にきているようです。

mock.patch() が置き換えする対象

mock.patch() の挙動について質問されて、即答できなかったので、簡単に調べ直してみました。

簡単なサンプル

まず以下のようなコードを想定します。

# foo.py その1
import random

def pickup(seq):
    return random.choice(seq)

random.choice() 関数は呼び出すごとに挙動が変わり、テストしにくいので、mock の出番です。

# test.py
from unittest.mock import patch
import foo

with patch('random.choice') as m:
    m.return_value = 0
    assert foo.pickup([1, 2, 3]) == 0

import の仕方を変えるとモックに失敗する

ここで foo.py の書き方を以下のように変えます。

# foo.py その2
from random import choice

def pickup(seq):
    return choice(seq)

pickup() 関数を外側から見た挙動は同じです。しかし、なんということでしょう、test.py を実行すると assert が失敗します。pdb や print を使って調べるとわかりますが、choice() 関数が Mock オブジェクトになっていません。

名前に対してパッチしている

with patch('random.choice') のコンテクストに入るとき、大雑把に以下のようなことが起こります。

import random
random.choice = Mock()

※ 実際には Mock ではなく、そのサブクラス MagicMock ですが、この議論の本質ではないので、Mock で話を進めます。

Python のプロセスでは、モジュールはシングルトンとしてふるまうため、プロセス内で random.choice という名前は、Mock オブジェクトを参照することになります。foo.py その1の中では random.choice という名前を使っているため、Mock オブジェクトを参照します。

ところが foo.py その2 は random.choice という名前を参照しているわけではありません。from random import choice すると、大雑把に以下のようなことが起こります。

import random
choice = random.choice
del random

patch() 適用後、名前の参照先は

• グローバルな random.choice => Mock オブジェクト
• foo.py の choice => 元の choice 関数

のようになっています。このため、foo.py その2では choice がモックにならないのです。

名前空間 foo 以下の名前に対して patch を適用する

じゃあ、どうするのかというと、普段は patch('foo.patch') としています。上記の問題が発生するような状況だというのが分かっていれば、これで解決です。しかしながら、foo.py を、その1からその2に実装を変えたとき、テストが fail するけれど、どこがどうなっているのか見つけにくいな、と思いました。

その1のときに、test.py に patch('foo.random.choice') と書くとよいのでしょうか。こうすると foo.py その2に書き換えてテストすると、fail ではなくて patch() 実行時にエラーが出るので、名前がおかしいことに気付くような気がします。

Robin Williams / ノンデザイナーズ・デザインブック

文書デザインの考え方を紹介する本

今年、付きまとっている @ymotongpoo が読んでると聞いて、ノンデザイナーズ・デザインブックを再読しました。プログラミングでいうところの、デザインパターンとも言うべきプラクティスが解説されています。

この本自体は以前から持っていましたが、流し読みしただけで、実践したことはありません。使う機会がなかったのと、この本がパターンのカタログであると捉えていなかったからです。

再読したので、忘れないうちの実践として、このブログのデザインを変更しました。Blogger.com に最初から入っている「シンプル」というテーマをベースに、CSS だけを変えました。HTML は触っていません。

整列、近接、反復

あなたは文字揃えの扱いに慣れてきました。しかしいっそうの訓練を積むまでは、 1ページに1種類の文字揃えだけを使うようにしてください。つまりすべての文字列を、左揃えか、右揃えか、中央揃えかのどれか一つにするのです。

もとのデザインではタイトル、エントリのタイトル、本文が揃っていませんでした。そこで、これらの左端を揃えました。

右のカラムは元々揃っていたので、そのままです。

もし関連する項目がいくつかあるなら、それを近接させてグループにしましょう。直接的な関連をもたない項目は離しましょう。

ブログの論理的な構成は、以下のようになっています。

• ヘッダ
• 記事群
• 記事
• 日付
• 題名
• 本文
• セクション
• [セクションタイトル]
• 文章

これまではセクションタイトルのフォントが小さくて、セクションを認識しづらい見栄えでした。大きくすると、まとまりが見えるようになりました。

反復は、一貫性をさらに強化したものです。約物、書体、線、色など、あなたがす でに繰り返し使っている要素を見つけて、そのうちの一つを強調して反復の要素と して使えないか考えてみましょう 

ブログの場合、似た構成要素が反復するつくりになっています。絵や文章を配置するのではなく、文書構造にスタイルを適用しているので、自動的に反復が適用できます。

コントラストが課題

コントラストは、染みを隠すために壁を塗るのに似たところかあります。染みの上に塗る色が周りの色とだいたい同じではだめで、正確に同じ色にするか、それが不可能なら壁全体を塗り直すしかないのです。

今回の作業ではコントラストを活用できていません。タイトルを目立たせていないため、全体的にメリハリがないのです。

広告なんかだと、読む気がなかった人に強制的に提示するので、タイトルが目立つことは重要かも知れません。このブログへの流入は、リンクか検索エンジンからのほとんどです。ブログのタイトルが目立ったから読む、という因果関係はまず成立しないでしょう。かといって本文との差がないと構造が分かりにくいものです。そんなわけで、ヘッダ部分はフォントを大きく、色を薄くしました。

そもそもブログ名が悪いのかも知れません。見栄えではなくて、コンテンツの問題なので、今回は保留。

また、色のセンスがないのでモノトーンにしていますが、本当は色を使わないほうが難しいはずです。marippe の「色彩センスのいらない配色講座」や、フルカラー新装増補版が助けになるのだと思います。

問題解決のフレームワーク

実践してみたところ、かなりマシになりました。特に整列の効果は絶大です。インデントが好きで Python を使っているのに、もっと早く気づかなかったのが不思議なくらいです。

これまで、漠然と気に入らないなあ、と感じていたことに対して、体系的に問題と解決を捉えられるようになったのが最大の収穫です。

oldriver.org の整理: ウェブサイト編

年間数アクセスの http://oldriver.org を、使っていたレンタルサーバから、Github Pages に移行しました。まずは、そのまま移行しただけですが、コンテンツも整理していく予定です。

作業にあたって、以下を参考にしました。

• User, Organization and Project Pages
• Setting up a custom domain with Pages

作業手順は以下のとおり。

1. torufurukawa.github.com というリポジトリを作る。
2. master ブランチにウェブサイトのコンテンツを add して commit して push する。
3. 10分ほど待つとホスティングされる。
4. CNAME というファイルを作り、 oldriver.org とだけ書いて、push する。
5. DNS の A レコードを設定する
   torufurukawa.github.com.      IN      A       204.232.175.78

Aレコードに使う IP アドレスですが、ググったときに見つかったもので設定しても動かず。nslookup で解決。

これでレンタルサーバとサヨナラです。が、退会方法が分からないので、問い合わせ中。月曜以降にお返事がくることでしょう。

oldriver.org の整理 : メール編

oldriver.org というドメインを持っていますが、ほとんど活用していません。どうして org なんて取ったのかなぁ。.com とか .net がすでに取られていて、まだ .jp とかなかったのかなぁ。ちなみに torufurukawa.com は誰かに取られているようです。

そしてウェブサーバとメールサーバは、アメリカのホスティング会社の共有サーバを使っています、いまどき。しれっとカナダの会社に買収されて、Python で書いた CGI も動かなくなりました。小さなスクリプトを動かしたくて、プランのアップグレードの相談メールを出したら、「あー、そんなのでいいんなら、権限だけあげとくよ」というなぁなぁ対応で SSH できるようになったのですが、買収されて法人が変わって、本来のサービス提供を受けています。

どーせアクセスのないサイトだし、そろそろ整理をすることにします。

まずはメールから。ほとんど使っていないのですが、たまーに、ID として使っていたりするわけですよ。完全に停止させるわけにいかないので、お手軽な方法を探しました。

結論としては outlook.com を使います。 Windows Live アドミンセンターとやらで、独自ドメインのメールを受け取れるように設定できました。数年以内に有料になったりしそうですが、自分でメールサーバ管理するくらいなら、ちょっとくらいお金を払ってもいいです。

DNS サーバも、ホスティング会社のを使っていましたが、今回、AWS Route 53 に移行しました。

Python 旅館 2013.03

Python 旅館 2013.03 に参加しました。

Python 温泉の簡易版です。なんと温泉もありません。

というイベントです。前回参加したのはいつだったかなと思い、検索してみたら、 2010年4月でした。3年前です。泊りのイベントは初めてで、知っている人も少なくて、どきどきしながら行ったことを覚えています。何をしたかは、まったく覚えていません。検索してみたら...

文字コード周りの挙動がアヤシイときにはbuchoに助けてもらいました。

（kuenishi's blog）

そんな偉そうなことしたかなぁ。

@torufurukawa と酔っぱらいUstreamしてたらあんまり出来ませんでした。

（YAMAGUCHI::weblog）

これはよく覚えています。

さて、今回は簡単な課題を持って参加しました。とおるメモという駄文集がありまして、これを Kindle Direct Publishing で出版することです。もはや Python でも、プログラミングでもありません。と見せかけて、HTML から epub 形式に変換するまでを Python 3 で書きました。

もともと、簡易オレオレなマークアップで書いたテキストファイルから、スクリプトを使って静的なページ群を作っていました。m4 使ったり、XSLT 使ったりした記憶がありますが、もはや、どこにいったのか分かりません。@ae35 が reST 形式に変換したものを作ってくれていますが、今回は自分でやってみようと思いました。Python 3.3 を使ってみたかったんだい。

各文章の HTML から題名、日付、本文を取得するのに、 Beautiful Soup を使って HTML をパースしてから取り出しました。find_all() メソッドしか使っていません。いつの間にかバージョンが4になっていて、 beautifulsoup4 はそれ以前のものとはまったく別物になっているようです。

ちまちま作っていくときに、何度 print hoge と書いてエラーが出たことか。なかなか慣れませんね。Python 2 を使う時でも、 print(hoge) って書くように気をつけているつもりだったんですけどね。

その後は、まとめて torumemo.rst としてテキストファイルに吐き出すだけでした。タイトル、日付、1つ以上の段落で、ひとつの文書が構成されているので、ベタで出力しました。

それを Sphinx を使って、epub 形式にビルドしました。困ったことがひとつありました。epub テーマで変換すると、各ページのヘッダに「とおるメモ 1.0 document」、フッタに「(c) ふるかわとおる 2013, Created using Sphinx 1.1.3」 になり、それぞれハイパーリングがつきます。あと、index.rst に書いていなくても、空っぽのインデックスページができてしまう。ちと、これ要らないんすけど...。

これはもしやテーマを自作しなければいけないのか、と焦ってしまいました。テーマの作り方とか読んでしまいましたよ、はい。だらだらドキュメントを読んでいってるうちに、簡単な解決策がありました。

まずフッタとインデックスは、conf.py で指定できます。

html_use_index = False
html_show_sphinx = False

ヘッダは layout.html という、すべてのテーマが継承しているファイル  document という文字列が定義されているようでした。ようでしたというのは、このあたりで調べるのをやめました。というのは、 conf.py に自前の CSS を定義できることに気づいたからです。

def setup(app):
  app.add_stylesheet('torumemo.css')

これ。で、torumemo.css の中で

div.related {display: none}

という強引な方法で不可視にしています。データとしては含まれている、という、セマンティック的にひどい状態です。

とこんなことを書いているうちに、Kindle ストアで買えるようになるはずなのですが、Amazon からのメールに書かれていた「このURLで公開されているぜ」というページが 404 です。なんか時間がかかるみたいなので、もう今日はいいです。

作業の終わりと、タスクトリガーワンダーランド

作業にせよ、まとまった仕事にせよ、なかなか思い通りに進まないことが多いことが悩みです。もう30年くらい悩んでいます。単純に自分が完了させるだけのスキルを持っていない場合と、仕組みに問題があるときがありますが、後者について考えてみます。

仕事の終わり

何をもって完了したと言えるのか、を定義するようにし始めました。「要件定義をする」という仕事だったら、設計担当者に要件定義書を渡すとかです。あるいは、機能の実装であれば、それが試験担当者が確認できる環境においてある、とか。

これをやらないと、たいてい手戻りが発生します。作業を重ねている途中で予期しないことが起こり、紆余曲折したりします。使おうと思ってた道具が、予想と違う挙動をすると分かり、深追いが始まり、潮時を忘れてしまいがちです。あるいは書いている文書の体裁が受け入れられないことが、最後の最後に発覚し、またやり直しです。

なので「藤本さん（仮名）が開発するときに参照する文書を、共有場所に保存する」などと定義することで、藤本さんに出来上がりの期待値を確認する、など細かい作業が浮き彫りになって、予期しない手戻りが減ります。おそらく。

タスクトリガーワンダーランド

一方で、タスクが増えてくると、そのタスクの山の大きさに圧倒されて、躊躇してしまうことがある。後回しや逃避などという行動に出る。GTDでいうところのプロジェクト（複数のタスクをこなすことで終了するかたまり）のゴールを明確に定義すればするほど、小動物のファミリーのように、いつのまにかタスクが増殖し、やがて対処するのが嫌になってくる。特に私は、人にものを頼むのが苦手なので、相談系のタスクを避ける傾向があり、そのためよけいにあとでややこしくなる、という悪循環に陥りいがちだ。

そんなわけで、最初のほうのタスクは、すごく簡単にするように設定する。ゴールの設定さえもややこしそうなときには、ゴールを決める、みたいなタスクにしてしまう。それも大変そうなときには、ゴールの思いつきを10個メモする、にする。とにかく乗ってくるまでは、どう考えてもできるだろう、というくらいのアクションを並べるようにしている。

というわけで、まずはコーヒーでも飲もう。

Python の辞書に dot-notation でアクセスする

Python の辞書オブジェクトは x['foo']['bar'] みたいに書くのですね。それはよいのですが、 x.foo.bar みたいにアクセスしたくなる日もあるわけですよ。

もうこれは、古くて新しい問題で、いろんな人がいろいろと似たような実装をしていて、検索するといっぱい引っかかります。 自分のプロジェクトの中にも、そういうのが幾つかあります。

今日も久しぶりに検索したら、よさそうなのがありました。

https://github.com/makinacorpus/easydict

これが、x.foo.bar みたいに辞書に辞書が含まれててもうまくいく実装のなかで、シンプルできれいだなぁと思いました。

赤柳初朗の正体は....

ついカッとなって、森博嗣の小説群Gシリーズの登場人物「赤柳初朗」の素性を妄想した軌跡をまとめた。全力でネタバレゆえ、注意されたし。

Redis でインデックス的なものを使う

お手軽さとパフォーマンスの噂を聞いて Redis を使い始めたわけですが、RDB のようなクエリをしようとすると、当然、利用者側でなんとかする必要があります。たぶん、こうやればいいのかなぁという感じで。

クイズの回答を Redis に保存しようとしています。「各 user は、各 quiz に多くとも1つだけ回答できる。ただし、上書きができる。」という前提です。こんな JSON でデータを保存しましょう。

{"quiz": "1", "user": "alice", "ans": "X", ...}

{"quiz": "2", "user": "alice", "ans": "Y", ...}

{"quiz": "1", "user": "bob", "ans": "X", ...}

必要なクエリは以下のとおり。

• quiz=1 に回答したユーザを取得する。
• quiz=1 に、ans=X と回答したユーザを取得する。
• user=alice の回答を取得する。

データ構造

データ本体を保持するハッシュ

quiz:1:user, alice => {...}

クイズ番号と回答の組み合わせごとのユーザを保持するセット

index:quiz:1:ans:X:users => (alice, bob)

ユーザが回答したクイズ番号を保持するセット

Index:user:alice:quizzes => (1, 2)

まず登録。以下、コードは redis-cli です。

> HSET quiz:1:user alice '{...}'
(integer) 1
> SADD index:quiz:1:answer:X:users alice
(integer) 1
> SADD index:user:alice:quizzes 1
(integer) 1

残りふたつの回答も同様に。

> HSET quiz:2:user alice '{...}'
> SADD index:quiz:2:answer:Y:users alice
> SADD index:user:alice:quizzes 2

> HSET quiz:1:user bob '{...}'
> SADD index:quiz:1:answer:X:users bob
> SADD index:user:bob:quizzes 1

クイズ番号とユーザ名から、任意の回答を取得できます。

> HGET quiz:1:user alice
"{...}"

quiz=1 の回答、回答数、および回答したユーザは、このハッシュから取り出します。

> HGETALL quiz:1:user
1) "alice"
2) "{…}"
3) "bob"
4) "{…}"
> HLEN quiz:1:user
(integer) 2
> HKEYS quiz:1:user
1) "alice"
2) "bob"

quiz=1 かつ ans=X の回答数、回答したユーザ、回答は index:quiz:1:answer:X:users セットから取り出します。

> SCARD index:quiz:1:answer:X:users
(integer) 2
> SMEMBERS index:quiz:1:answer:X:users
1) "alice"
2) "bob"
> HMGET quiz:1:user alice bob  # クイズ番号とユーザ名を使って、ハッシュから取得
1) "{…}"
2) "{…}"

user=alice の回答数、クイズ番号、回答は index:user:alice:quizzes セットから取得します。

> SCARD index:user:alice:quizzes
(integer) 2
> SMEMBERS index:user:alice:quizzes
1) "1"
2) "2"
> HGET quiz:1:user alice
"{…}"

削除するときには、ハッシュと2つのセットを削除します。

> HDEL quiz:1:user alice
(integer) 1
> SREM index:quiz:1:answer:X:users alice
(integer) 1
> SREM index:user:alice:quizzes 1
(integer) 1

と、こんなやりかたで考えています。筋がいいことを願う。

2013年にやらないこと

Chikirinの日記に「来年の抱負）　やらないことを３つ決めよう！」という記事があります。昨年末のですね。

ビジネスであれば、「アジア市場には出るけど、欧米には進出しない」と決めたり、「インフラビジネスはやるけど、個別商品は売らない」と決めることができるでしょう。

何かを選ぶということは、他のもの・ことを選ばないということです。とはいえ、意識しないと、優先順位の低いことを選んでしまって、高いことを選ぶ資源がなくなってしまうことがあります。

というわけで、2013年にやらないこと

• 日帰りできないレース（トライアスロン中島大会は例外）
• 時間のかかる栄養補給
• 長時間のネットサーフィン

昨年は大阪でトライアスロンに出たりとかしてて、時間もお金もかかったのでした。というわけで、今年はレース控えめ、とくに遠方のレースには出ません。

栄養補給というのは、食事のことです。私にとって、食事は大きく分けて2種類あります。ひとつは生命活動、もうひとつはエンターテイメントです。前者はよっぽど苦痛でなければ味とかどうでもいいので、効率重視です。森博嗣の小説で「空中給油が理想」みたいな台詞がありましたが、そういう感じですね。

長時間のネットサーフィンというのは、Twitter や Facebook や Google+ をだらだら見るとか、メンション送り合ったりとかのことです。長時間の定義はまだわかりませんが、まずは5分（ポモドーロの休憩分）くらいをリミットにしてみようと考えています。

Redis をさわりはじめました

Python で Redis を触ってみました。オートインクリメントやインデックス用のkeyを使うイディオムがある。

import json
import redis
r = redis.Redis()

def create_user(name, auth):
    uid = r.incr('global:next_uid')  # ユニークなIDを取得
    return put_user(uid, name, auth)

def get_user(uid):
    value = r.get('user:%s' % uid)
    if value:
        return json.loads(value)

def put_user(uid, name, auth):
    user = {'uid': uid, 'name': name, 'auth': auth}
    r.set('user:%s' % uid, json.dumps(user))
    r.set('index:user:auth:%s' % auth, uid)  # auth -> uid を引くため
    return user

def get_user_by_auth(auth):
    uid = r.get('index:user:auth:%s' % auth)
    if not uid:
        return
    return get_user(uid)

a = create_user('wozozo', 'xxxxxxxx')
b = get_user(a['uid'])
assert a == b
put_user(a['uid'], b['name'], 'yyyyyyyy')

c = get_user_by_auth('yyyyyyyy')

Elasticity

あけまして、おめでとうございます。巳年なので Pythonista としてはテンションあがりますね。実は、別にそんなことないですけどね。

昨年（2012年）は、継続的デリバリを使っていきました。おかげで、手作業でのテストやデプロイから開放され、作ったものの品質が上がり、かつ、開発のスループットが向上しました。

プロダクト自身ではなく、プロダクトの作り方を考えるのは、想像以上にチャレンジが多く、また、楽しいものでした。

今年は、昨年よりも意図的にテーマを決めてみようかと思いました。

Elasticity について理解を深める

必要に応じて、システムのキャパシティを上げ下げする仕事が増えてきました。これまでは、自分の少ない経験と、識者のアドバイスでなんとかやってきました。今年はこのあたりの技術、知識、経済性などを改めて理解し直します。

Elasticな何かを作ってみる

アプリケーションなのか、ライブラリなのか、デモなの決めていませんが、elastic な何かを作ります。

理由は2つあって、まず、自分のGithub が寂しい限りであること。何もできないようにしか見えないので、何か作ってみたい。

もうひとつは、効率が悪いのですが、自分が作って初めて理解するタイプだからです。読んだだけだと、なんとなく分かった気になるだけで、理解が浅いのですね。学校で習った核反応による中性子の増減の微分方程式なんかも、その計算をするコードを作ろうとして初めて、本当に理解が深まったのでした。字面だけ追っかけてしまうのでしょう。

pyfes 以外でプレゼンする

こちらは効果がよく分からないのですが、教えるときがもっとも学ぶ、という噂がまことしやかに語られます。ですので、やってみようかと。Pyfes では、だらだらしたいので、LTでもいいからどこか別のところでできるといいんぁ、と漠然と考えています。