Twitterによると去年は手作りケーキと(息子のリクエストによる)納豆ごはんだったのが、今年はこんなかんじ。

大変おいしゅうございました。

我が家のレンジと炊飯器は、私が上京するときに、大学生協のようなところから来たパンフレットで適当に選ばれたものを今まで使っていたのだが、

• レンジはお菓子を作るときに焼きむらができて困る
• 炊飯器は大量の炊き込み御飯を作るときにうまく炊けない

という実害が出はじめたので買い替えることとなった。

アキヨドに言ってその辺の店員の話を聞いてみて、レンジは東芝 石窯ドーム ER-KD420に、炊飯器は象印 極め炊き NP-VD10というのになった。

ついでに、今あるレンジ台(のようなもの)ではこの大きさを支えられないので、レンジ台も購入して台所がだいぶ一新された。

夏に買った洗濯機も合わせて、これでようやく私が上京時に買った家電が全て置き換えられたような気がする。12年間おつかれさまでした。

11月の初めての更新になりますが、このような状況になってしまった原因である「アイアンボトムサウンド杯」についてまずは書こうと思います。

アイアンボトムサウンド杯とは

アイアンボトムサウンド杯とは、艦これ秋の特別イベント「決戦！鉄底海峡を抜けて！」の第4海域が未クリアだった@nsgc提督と@hrysd提督が、母港拡張を賭け、11/21〜11/27の期間で対決をするというイベントであった。

また、イベント最後の週末ということもあり、E-4、E-5への挑戦する提督が多数現れちょっとした祭となった。

参加した提督は以下の通りである。

• E-4: @nsgc, @hrysd, @m_pixy, @htkymtks
• E-5: @ursm, @hide_nba, @kenchan

今回は、母港拡張をかけた2名だけではなく、総勢7名の作戦となった 広義のアイアンボトムサウンド杯 と、弊社の提督活動を支えるインフラについて紹介する。

弊社艦これインフラについて

提督の活動を支えるインフラは以下の2つである。

• idobata
• Google Hangout

idobataの艦これルームには、便利情報を通知してくれるGeneric Hookがあり、公式やまとめブログの情報などが自動で流れてくるようになっている。

また、お互いの指揮を披露する場として、Google Hangoutの画面共有を積極的に活用している。夜になるとどこからともなくidobataにURLが貼られ、多い時では6名くらいの提督が集まって、各自が艦隊の指揮を取りながら他の提督の様子をウォッチしている。

アイアンボトムサウンド杯の結果

肝心のアイアンボトムサウンド杯の結果だが、両者の事前準備があまりにも惨々だったため、2名ともクリアできないという斜め上の結果となった。

ただ、両者がクリアできなかった場合は(何故か)@ursmが2名から母港拡張の権利を得るということになっていたために、狭義のアイアンボトムサウンド杯の勝者は@ursmとなった。

広義のアイアンボトムサウンド杯の結果も以下に記す。

• E-4失敗: 捨て艦の@nsgc, 大破進撃の@hrysd
• E-4クリア: 魔法(のカード)使いの@m_pixy, 艦これ最後の良心@htkymtks
• E-5クリア & 阿賀野: @kenchan
• E-5クリア & 阿賀野 & 矢矧: @ursm, @hide_nba

なんと、当人2名以外は全員が目標を一定のレベルで達成できるという異常事態であった。

アイアンボトムサウンド杯を終えて感じたこと

初めてのイベント参加となったが、他の提督の指揮や、自身の経験でいろいろと思うことがあったので記録しておく。ただし、全て主観に基いたものであることをあらかじめ断わっておく。

キラキラ付けはストレスにならないならやればいい

E-4は常に戦艦以外をキラキラで出撃、E-5は隠れ疲労回復で出撃、という感じでやっていたが両者で大きな差があるとは感じなかった。夜戦メインというのもおそらく影響があったと思われるが、次回は無理にキラキラを付けるということはやらないと思う。

一方で、隠れ疲労と疲労無しでは、体感ではカスヒット率がかなり違うように感じた。特に最終日など、隠れ疲労回復の時間をケチって出撃した場合の初戦カスヒットはひどいもので、場合によってはA勝利も取れないということが何度かあった。

決戦支援は高レベルのほうがよい

E-5の決戦支援は、最初「駆逐2+ちとちよ」のレベル50-60を使っていたが、同じ構成で平均レベル80超えの@ursm提督とのダメージ差があまりにあったため、「駆逐2正規空母2」のレベル70-80にしたところだいたい同じダメージがでるようになった。空母の艦載機はたしかに@ursm提督のほうが充実していたが、ステータスの数値差を遥かに超えるダメージ差だったことを記しておく。

まとめ

あまりソーシャルな面が表に出ていない艦これだが、インフラを整えれば十分にソーシャルな遊び方ができるので、まだ上記のような遊び方をしたことがない人がいれば是非試してみてほしい。

また、アイアンボトムサウンド杯の勝者である@ursm提督おめでとう。

内容については当事者(?)のあんちぽさんが詳しく書かれているのでこれで。「#ぶつかり稽古」という事件について - delirious thoughts

なんというか、とにかくすごかった。あと、冗談みたいなことを本気でやるってのがやっぱりかっこいい。

(これを書いているのは一ヶ月後の12/1です…)

AWS Casual Talks#1で「Amazon Simple Workflow Casual」というタイトルでLTしてきました。

会場で Simple Workflow を知っているというレベルでも片手で足りるくらいの人数だったような。

開始時点で、これはまずったなと思ったのですが、もう走り抜けるしかないと思い、当初の予定通り「Simple Workflowとはなんぞや」という説明を一切せずに、使っていて困ったところや、いろいろ試行錯誤して解決した話をしてきました。

ただ、話したいことや相談したいことはもちろんこれだけはないので、もしまた機会があればもう少し時間をいただいて、導入的なところから、他にもあるハマり所やTipのようなものを紹介したいなぁと思いました。

他の方の発表や、その後のインターネットの動向を見るに、mBaaSやVPCあたりがやっぱりホットなテーマなんですね。 このあたりは自分はまったくノータッチな分野だったので、一線の人達の話が聞けて勉強になりました。

主催の@con_mameさん、会場のAmazonさん、ありがとうございました！

追記:

gihyo.jpの記事になってました。 第6回　ガジュアルなナレッジ共有でクラウドサービスを使い倒す～AWS（Amazon Web Services） Casual Talks：IT勉強会を開催するボクらの理由｜gihyo.jp … 技術評論社

参加登録開始後あっという間に定員となったイベントAWS Casual Talks#1で Amazon Simple Workflow について LT することになりました。

詳しい内容はまだ決めてないのですが、非同期化、エラー処理、イベントの履歴、あたりでよさそうなところを探しているところです。

なんとかカジュアルに参加するのは初めてなのですが、カジュアルとは名ばかりというのは聞いているので、回りに負けないようにカジュアルな話ができるようにがんばろうと思います。

前回から丁度2ヶ月。

息子と一緒に行ってきたんだけど、終始借りてきた猫状態だった。

息子は2回目の美容院だったはずなんだけど、前回は奥さんがずっと近くいたりトーマスのDVDを見せてもらっていたらしいが、今回は席も少し離れていたしDVDも見れなかったらしい。

だいぶ不安そうな顔をしていたので、美容師さんにも緊張が伝わっていたらしく、終わってから心配されてしまった。

外に出て聞いてみると「また行きたい」と言ってたので大丈夫でしょう。

ケーキ買って帰ったらサプライズ的なプレゼントを貰ってしまったのであった。

もう5年もたったんだなぁ。今後とも宜しくおねがいします。

YAPC::ASIAに初めて参加してきました。

印象に残っているトークの感想などなど。

大規模Perl初心者研修を支える技術

圧巻の71人個別指導。

最初から高トラフィックを想定してデータ設計やコーディングをさせるというのは、そういうノウハウがあるからこそできることで、すごく羨ましいですね。

あとは、自身でふりかえれるようにフォローアップしていくというのは、自立的に動けるメンバーを育てるという観点からもいいやりかただなぁと勉強になりました。

ちなみに、これに関係する話が聞ける師弟登壇・新米サムライの集い 2013というイベントが来月開催されるみたいですよ。

僕の考えたFuture Perl

Perl 6、噂話程度にどういう状況なのかは聞いていましたけど、今の状況を整理して聞くことができたのはとてもよかった。

また、Perl 6 の機能を Perl 5 でも使えるような CPAN が出てきていて、その中でよいものを Perl 5 のコアに取りいれていくというのもよいのではという話は、言語のコアでそういうことをやれるとしたらおもしろいなぁ。

YAPC::Asia Tokyo 2013 特別座談会 「Rubyの良いところ語ってください 〜そんなPerlで大丈夫か?〜」

言語の差よりも、プログラマ自身の能力の差の方がずっと大きいからみんながんばれという話。

Rubyだと普通にその辺に言語のコア開発者がぞろぞろしてるけど、これはかなり特殊というか特別な状況というのを実感した。

Railsの影響でRubyには経済圏が出来たというのと、モダンな有償サービスでPerlのサポートは少なくて自分達で働きかけないといけないというのはハッとした。

本当にあったレガシーな話

どこかで聞いたことがあるような大変そうな話だった。 最後のキーノートにも繋る話で、こういうことをやった人を評価する仕組みっていうのが大切なんだなぁと。

Keynote

マネージャーという役職(?)についていろいろと考えさせられるトークだった。

• 運動部のマネージャーと会社のいわゆるマネージャー
• 社内政治のハッカー
• ディレクション
• リーダーとマネージャー

Ikebeさんみたいなマネージャーのいる会社はきっと楽しい(だけじゃないだろうけど)と思いました。

Closing

なんとなく、そろそろYAPCに参加してみようかなぁと思ったら、「現行体制での最後のYAPCです」と言われて、嬉しいやら悲しいやらという感じ。

RubyKaigi(1stシーズン)の最後にも立ち合ってしまったし、この業界自体がそういう時期にきているのかなぁと、いろいろ考えてしまいました。

まとめ

はじめて参加したYAPCでしたが、

• インターネットでしか見たことない人の顔と名前がいっぱい一致した
• Perl ちょっとやってみようかな、という気になった
• 武蔵小杉の横須賀線からの乗り換え設計した人出てこい

という感じで、とても充実した二日間でした。ありがとうございました！

昨年からお仕事でお世話になっているSansan様にてNiigata.rbの再演をしました。

この発表を作る上で今のプロジェクトに影響されているところも沢山あるので、そのあたりの裏話を混ぜたりして話してみました。

発表後の質疑応答のときに「なかなか上手にテストが書けないんだけど、いいテストと悪い(?)テストは何がどう違うのか。どうやったらいいテストが書けるようになるのか」みたいなことを言われたのですが、私の思いとしては

• describeとcontextが整理されていること
• そのdescribeとcontextが嘘をついていないこと

で十分じゃないかなぁと思います。

1番目は、ここが整理されていると、エッジケースの漏れがないかとか、仕様のずれや漏れなどがないかとか、一目でわかるのでレビューが楽なんですよね。

2番目は、よくあるのがmockやstubを多用している(せざるをえない)ときですね。 shard_contextとかにも繋がるんですが、せっかく日本語(や英語)で状況を整理して書いているのに、実際にコード見たら「その騙し方はないだろう」みたいになるのがつらいよねという話。 で、多くの場合そういうテストコードは落ちてほしいときに落ちなくて、落ちないで欲しいときに落ちるよね、と。

他にもいろいろ質問をいただいたのですが、外と発表するのとは違ってコンテキストを共有できる状態でのディスカッションはやっぱり話が早いので、こういう機会を増やしていけるといいなぁと思ったのでした。

発表の機会をくださったSansan様ありがとうございました。