ブログ移転のお知らせ

転職に伴い、ブログも自社サービスである"はてなブログ"に移転しました。
http://daiksy.hatenablog.jp/

今後ともご愛顧お願いします。

退職のご報告

10月20日に、フリュー株式会社を退職することになりました。
10月7日に最終出社日を終え、今は有給消化期間をのんびり過ごしています。

今回の退職エントリ、書くかどうか迷っていたのですが、数人の友人たちから「読みたい」とリクエストを貰ったので、その友人たちやコミュニティでお世話になった人向けに書こうと思います。

■お前誰よ?
2012年2月から、フリューという会社で乙女ゲームの開発に携わっていました。
Scalaコミュニティの各種イベントとか、DevLOVE関西とか、関西ソーシャルゲーム勉強会なんかによく出没してます。

あと、今年は「トイレに閉じ込められた人」として一時期のインターネットを賑わせていました。

■なんで辞めるの？
今年に入ってから、いろいろと自分のキャリアについてじっくり考える事が多くなりました。35歳を過ぎていわゆるプログラマ定年を超えたことや、会社の組織変更などもきっかけになりました。

自分自信のキャリアのこと。ソフトウェア開発に関わるのを一生の仕事としていくために必要なもの。いろいろなことを考え、悩みました。

今年のゴールデンウィークには、東京旅行の途中で友人を頼っていくつかの会社を訪問し、そこでも様々なお話をさせてもらいました。(東京会社訪問ツアー[pixiv, はてな, ドワンゴ])

こういった形で、社内外を問わず様々な人たちと対話を重ねる中で、自分のやりたい事の輪郭が見えてくるようになり、転職を決意しました。

もう少し詳しい話を聞きたい、という人はまた飲みにでも誘ってください。

■次はどうするの？
2年半ほど、ソーシャルゲームの開発をしてきましたが、しばしゲームからは離れることになります。ただ、インターネットの世界でソフトウェアの開発に引き続き関わっていくことになるかと思います。次の会社には11月からジョインする予定です。

関西ソーシャルゲーム勉強会、というコミュニティについては、ゲームの世界を離れてしまうのでやれる事は限られるでしょうが、引き続きなんらかの形でコミュニティ自体にはコミットメントして行きたいと思います。

あと、依然としてScala大好きなことには変わりないので、こちらのコミュニティにも積極的に関わっていきたいです。

11月までしばらく有給消化 & 無職期間があり、平日は微妙に暇だったりするので飲みに誘ってくれると嬉しいです。

恒例のウィッシュリストはこちらになります。

今後共よろしくお願いします。

#ScalaMatsuri に参加してきた

日本最大級のScalaのカンファレンス、ScalaMatsuri に参加してきました。
※ 去年のScalaConferenceの模様はこちら

スポンサーでもあるドワンゴさんのご好意により、各セッションの模様はニコ生のアーカイブでご覧いただけます。

去年に引き続き、今年も所属会社であるフリューがスポンサーとなっていて、会場では弊社のノベルティも配られていました。

■今年は一歩引いて参加してみた
今年は、自分なりに意図があり、あえて一歩引いた立ち位置で参加していました。
フリューに入社してScalaを扱うようになり、去年のScalaConferenceではスポンサーセッションに登壇する、というチャンスをもらいました。そのおかげで、僕もそれなりにScalaコミュニティの中でいろいろな人に名前を覚えてもらい、今年のScalaMatsuriでもコミュニティの中心で活躍されている様々な人と交流することができました。

今年もフリューがスポンサーになるということで、今年は、去年の自分が活かすことができたこの機会を、若手のエンジニアに譲り、彼らをフォローする立場として参加しようと思いました。

去年のScalaConferenceで当時まだフリューにいらした@mumoshuさんと参加した時は、僕自身がまだ不慣れであったり、参加者に知人がそれほどいなかったことなどもあり、懇親会などで少し自分が孤立してしまう場面もあったので、今年は僕がコミュニティとの間を取り持って、今回参加してくれた自社のエンジニアに楽しんでもらおうと思いました。

僕のこういった心配は実は完全に杞憂で、@kuchitamaさんは当初からボランティアスタッフとしてイベントの運営に携わっていたし、@osunuさんはスポンサーLTで実に堂々したプレゼンを披露していました。

おそらく今回の参加で、彼らもScalaコミュニティの多くの人に名前を覚えてもらっただろうと思います。

■去年との違い
去年のScalaConferenceの熱気も凄かったですが、今年もまた去年と少し空気は異なりつつもものすごい盛り上がりを見せていました。

去年は、Scalaをこれまで支えてきたコアな人達が中心となって盛り上がっていた印象でしたが、今年はさらにオープンに開かれていた印象でした。

Scalaを実際に扱っている、という企業も去年から飛躍的に増えており、わずか1年ですごいことになったなー、という気持ちです。

■小田好先生
自分が普段仕事で使っているプログラム言語の、言語設計者に実際に会う事ができるプログラマというのは、世界でもそう多くは無いはずです。

今回のイベントにMartin Odersky先生が来てくださったことで、僕はそういう幸運なプログラマの１人になることができました。

この写真は一生の思い出です。著書にサインもいただきました。

あと、「今年は一歩引いて参加する」と言っておきながら結局我慢できなくて、LTに登壇していましたw

ScalaMatsuri 2014 LT from Daisuke Kasuya

来年も同様のカンファレンスがあるとするなら、また今回とは違った立場で参加することになるでしょうから、次回はコミュニティに対してきちんと貢献できるような参加の仕方をしたいな、と思っています。

今年のこの時期に、チームの仲間とこうしてイベントに参加できたことは、自分にとってものすごく大きな意味のある体験でした。

このような機会を与えてくださったスタッフの皆さんには感謝の気持ちしかありません。本当にありがとうございました。

超交流してきた

京大の超交流会に参加してきた。

はてなの栗栖さんから「京都で働く」をテーマにしたパネルディスカッションのメンバーに誘っていただき、"京都大学"なんて自分の人生においてこれまで何の接点もなかったし面白そう！ と二つ返事で参加させていただくことに。

京大なんて何の接点も無い、と書いたものの、参加してみれば前年度に採用の仕事をしているときに知り合った学生さんが声をかけてくださったり、企業ブースには普通に知ってる人が何人かいらしたり、案外自分の人生と微妙に重なっている部分はあったようだ。

とはいえ、今回知り合った人たちの多くは、このイベントに来なかったら接点がなかっただろうな、という方たちばかりで、そういう人のお話を聞けたのは本当に良かった。

今回は、パネルディスカッションということで、栗栖さん、いろいろデザインの長山さん、ヌーラボの染田さんと4人で登壇した。パネルディスカッション自体は人生で3回目。しかも今回は普段から付き合いのある人と一緒の登壇だったので、少しはうまくやれるだろう、と思っていたのだが、やっぱりパネルディスカッションは難しかった。

普段の生活や、いつも参加するコミュニティとは違った世界に触れられたのは、ほんとうにいい経験だった。

僕ももう少し、「いつもと違う世界」を意識してちょっといろいろチャレンジしてみてもいいのかな、と思った。

転職活動で心を病まない方法について

はてなの増田で興味深いエントリを読んだ。

転職活動で心を病んだ件について
http://anond.hatelabo.jp/20140510231402

このエントリの内容の是非はともかくとして、率直な感想は「すごい数にエントリしてるな」だった。

この人の転職活動の経緯は知らないけど、たぶん転職エージェントに手当たり次第にエントリしろ、と言われたんだと思う。僕もそう言われた経験があるからわかる。

転職エージェントは、求職者が転職先企業に入社が決まってはじめてお金を貰えるビジネスだ。と、なると、エージェントとしても採用される確率の高い人に注力したい。確率の低そうな人は、数で勝負して少しでも確度を高めたい。当たり前の話だと思う。

つまり、エージェントに「エントリ数を増やせ！」と言われたということは、「あなたには一押しできる個性がない」と言われたのと同義だろう。

僕の経験を書く。

最初、転職活動をはじめたとき、とりあえず大手の転職エージェントに複数申し込んだ。ネットで申し込み、個人的な面談を受ける。このときにエージェントに履歴書とか職務経歴書を送るわけだが、当時の職務経歴書ははっきり言って無個性だった。

常駐型ビジネスで、常駐先企業に送るような、「会計システム構築 C# Oracle 200n年〜200n年」みたいなのが羅列されてるやつ。

いろいろなエージェントに言われたのは、「とりあえず50社に書類を送りましょう。それで1割ほど書類選考が通れば儲けものです」ということ。

新卒じゃあるまいし、そんなに書類送る時間あるかよ、と思い、エージェントに頼るのはやめることにした。

このとき、某大手Web企業が大阪に開発部隊を新設する、ということで、エージェントを通さずに直接申し込んだ。

自分の職務経歴書が無個性だということは、エージェントに「数を撃て」と言われたことでなんとなく察していたので、個性を出そうと思った。はっきりと覚えてないが、blogのURL、SNSのアカウント、勉強会やカンファレンスの登壇経験と発表資料のリンク、とかを書いたように思う。

数日して、電話がかかってきた。大手の転職エージェントからだった。曰く、ぼくが直接応募したWeb企業は、かなりの大規模採用だったため、自社で採用活動をまかなえないのでこの転職エージェントに採用業務を委託しているのだという。

電話の内容は、「採用は見送り」というものだった。書類選考だし、メールで合否が来るものと思っていたので、なぜ電話などしてきたのだろうと思ったら、エージェントが続けてこう言う。

「今回、この企業の選考ではスキルがマッチせず採用を見送りました。ただ、あなたの経歴はとても魅力的で、おそらく欲しい企業はたくさんある。なので、引き続きわたしの方であなたの転職活動をお手伝いさせていただきたい」

悪い話ではなさそうだったので、とりあえず会ってみることにした。

面談の場でそのエージェントは、数を撃て、とは一言も言わなかった。実はこのエージェント、最初に数を打て、と僕に言った会社だったのにもかかわらず（当然担当者は別）
。

そこから、エージェントはものすごく詳細に僕の資料をレビューし、応募先企業も厳選して選択してくれた。

結果的にそのときに紹介された企業に入社が決まった。

職務経歴書に個性を出すのは、やり方しだいでいくらでもできるんじゃないかと思う。特にIT系の仕事なら。

エージェントに数で勝負しろ、と言われたら、方針転換して書類を工夫して、別のエージェントに相談してみるのもいいかもしれない。

以上、僕の経験による「転職活動で心を病まない方法」でした。

東京会社訪問ツアー [pixiv, はてな, ドワンゴ]

■ きっかけ

今年で35歳になり、なにかと自分のキャリアであるとか、そういうものを深く考えることが多くなった。

エンジニアとしての自分自身のこととか、自分たちチームのあるべき形とか、そういうことを悶々と考えていると、隣の芝が青く見えたりもする。

そんな折、今年のゴールデンウィークに11連休という未曾有の大型連休の取得に成功。社会人生活史上でも類を見ないこの長期休暇を有意義に過ごすために、今回の旅を計画した。

そもそものきっかけは、以前@bash0C7さんがTwitter上で「今度うちの会社に遊びに来ていいよ」と言ってくれていたのを思い出したからである。
暦で平日にあたる期間に数日にわたって休みが取れることなどめったにないので、もし@bash0C7さんの会社のアポが取れれば、これをとっかかりにいろんな会社を見学しよう、と思った。幸い、これまでのコミュニティ活動の賜物として、主要なIT企業にはだいたい知ってる人がいる。この人脈を活かさない手はない。

お願いしたところ、@bash0C7さんから快くOKをいただき、さっそくその他いくつかの会社にも同様のお願いを申し出ることにした。

扱っているプロダクトであるとか、採用している開発プロセスとか、そういった部分で自分が個人的に話を聞いてみたいと思ういくつかの企業をピックアップ。その中で、「平日に訪問して1時間ばかり時間をいただき、社内の見学とか、お話を伺うとかしたい」というビジネスとまったく関係ない依頼をお願いできるくらいに仲の良い人がいる企業に絞り込んだ。会社として気になりつつも、使っている言語やプロダクトがあまりに自分たちと異なっている会社さんは、さすがに自分は話を聞けてもこちらからお話できる情報が無さ過ぎてご迷惑だろうと思い、そういうところは対象から外したりした。

調整の結果、pixivさん、はてなさん、ドワンゴさんの3社のご都合がつき、今回訪問させていただくことになった。完全に僕個人のわがままみたいな依頼だったのにもかかわらず、各社さんすべて真摯に対応していただいた。感謝してもしきれないくらいにありがたい。

■ ツアーその1: pixivさん訪問

4月30日。東京は雨。なんでも、場所によっては傘も役に立たないほどの豪雨となるらしい。以前デブサミで東京に来た時は歴史的な大雪だったな、と思いつつ山手線を代々木駅で下車。そこから明治神宮を横目にみつつ、歩くこと数分。オシャレオフィスで有名なpixivさんに到着した。

pixivさんといえば、めざましテレビで紹介されるほどのオフィス。訪問すると、壁一面が絵馬で埋め尽くされており、これまでゲストとして訪れた人の書いた絵とか、コメントが貼られている。

pixivさんには毎週水曜日にゲスト枠というのがあり、社外からゲストを招いて皆でランチを食べるという制度があるらしい。僕も今回そのゲスト枠に入れていただき、社員の皆さんと一緒にお弁当をご馳走になった。

オフィスに入ると、共有スペースにプロジェクタで座席表が映し出されている。どうやらランチの席順らしい。よく見ると、僕のTwitterアイコンが入っていた。

自己紹介をし、会社で乙女ゲームを作っている事を話すと、さっそく皆さんダウンロードして遊んでくださった。お礼をしないといけないので、このエントリを読んだ人は今すぐpixivのアプリをダウンロードしてください。

ちなみにご馳走になったお弁当はこんな感じ。

どうもごちそうさまでした。お弁当、すごく美味しかったです。

pixivさんのオフィスは、ものすごくオープンである。客先常駐プログラマ時代に、入口で携帯電話などの私物をロッカーに預けないと職場に入れないような世界を経験した僕など、想像もできないほどオープンだ。なんと、ランチ後のエンジニアの全体会議を見学させていただけた。

この会議。想像以上にガチで、「僕、ここにいて大丈夫なんだろうか・・・」とハラハラしてしまうほど。当然内容はここには書けないけれど、pixivエンジニアたちのサービスにかける熱さを垣間見ることができた。

全体会議参加後、絵馬を書かせていただき、名残惜しくも訪問時間が終了。社員犬のチョビと遊びたかった。

絵馬はエンジニアゾーンに飾らせてもらった。@kyon_mmさんの絵馬の近くであることが、写真からもお分かりいただけると思う。

pixivさん、ありがとうございました！

■ツアーその2: はてなさん

pixivさんを後にし、東京メトロで表参道へ行く。続いての訪問先は、はてなさん。

DevLove関西で出版した電子書籍に寄稿したご縁をきっかけに、開発部隊が同じ京都にあるということもあって、最近ははてなエンジニアの皆さんと仲良くさせていただいている。先日の勉強会で京都オフィスにお邪魔しているが、東京オフィスに伺うのはこの日がはじめてだ。

京都で行きつけの居酒屋で飲んでいるとばったりはてなエンジニアと出会う、というような事もあるほど、縁の深い会社である。

表参道駅を出て根津美術館方面へ歩き、はてなさんのオフィスを目指す。SIer時代から考えると、これまで数えきれないくらい色々な会社を訪問した経験があるが、会社に着くまでのお洒落さは自分の会社訪問史上最高だった。一歩ごとにドラクエの毒の沼のごとく、自分の中の何らかのパラメータが削られていくほどのお洒落さだ。

写真は、はてなさんの入っているビルの隣にある、根津美術館を囲む竹林。僕のような人間がこうしてカメラを構えていると、職質されるのではと思うほど、自分とは場違いな世界だった。

はてなさんも僕が勤めているフリューと同じく、開発部隊は全て京都にある。東京オフィスは営業、企画、編集、といった機能であるとのこと。知り合いの編集さんに応対していただいた。

（追記：東京にもディレクター、デザイナーさんがいらして、"開発すべて京都"ではないとのご指摘をいただきました)

以前京都オフィスにお邪魔したときは、やはり開発部隊のオフィス、という趣きだったが、東京オフィスはまたずいぶん雰囲気が違う。

はてなさんのサービスについてであるとか、開発時のコミュニケーションをどのようにしているか、であるとか、そういったお話をたくさん伺った。

同じ京都に開発を持ち、企画機能が東京にある、ということで自分のチームの状況と似たところもあり、ためになるお話をたくさん伺った。

（追記2：京都にも企画機能があり、完全にロケーションがわかれているわけではないそうです）

はてなさん、どうもありがとうございます！ 京都出張の際は是非飲みに行きましょう！！

■ツアーその3: ドワンゴさん

翌日の5月1日。ニコニコ超会議の興奮冷めやらぬ中、歌舞伎座タワーへ。会社訪問ツアーのラスト、ドワンゴさんだ。

Scalaプログラマ的にドワンゴさんと言えば、最も気になる会社。デブサミでの講演を楽しみにしていたのだが、初日にインフルエンザを発症して結局そのまま大阪に帰ってしまったので、講演に参加できず、今回はそのあたりのお話も伺いたかった。

歌舞伎座に着くと開演前の大混雑。ふとこんな事を思った。

D社さんに勤めたら、歌舞伎の優待チケットとか貰えたりするんかな？ #あるわけない
— Daisuke,Kasuya (@daiksy) 2014, 5月 1

半分冗談だったのだが、予想外のリプライをいただく。

@daiksy 福利厚生の一環で、年に1回ぐらい歌舞伎見に行けますよー。解説&お弁当付きで。
— Toshihiro Shimizu (@meso) 2014, 5月 1

マジか！！ Scalaといい、歌舞伎といい、心惹かれる会社である。

ちなみに、このツアーを公言してから、いろんな人に「だいくしーさん、転職活動してるんですか？」と言われたのだが、さすがにこんなに堂々と転職活動はしません。今のチームに持って帰るためにお話を伺っていますw

ドワンゴさんでは、主にScalaの話や、採用についてのお話、話題になった超チューニング祭りの事など、2時間近くお話を伺うことができた。

軽くオフィスも見学させてもらい、今度は女子マネがいるときに遊びにきたいなーと思った。

僕の訪問を聞きつけて@kmizuさんもお時間をとってくださり、ランチまでご一緒させていただいた。

@kmizuさんとはTwitterでは交流があったり、去年のScalaカンファレンスですれ違ったりはしていたけれど、ゆっくりお話させていただいたのは今回は初めてで、お会いできてよかった。

■ まとめ

普段、仕事をしていると、「自分たちの方向性とかやり方は本当にこれでいいのだろうか」と不安になることがある。今の僕がまさにそういう状態にあったのだけれど、各社さんでお話を聞き、自分が正しいと思っている方向性とか、価値観はどうやら間違っていないようだ、ということを再確認することができた。

コミュニティ活動を通じて、いろんな会社の人と交流を持ち、こうして実際に会社に伺ったりすることのできる自分の仕事は、素晴らしい仕事であるなぁ、と本当に思う。

今回の旅は、僕が一方的にいろいろなものを受け取る旅だったけれど、お返しに自分も皆さんに何かの価値をお渡しできるようにならないといけない。

完全に僕のわがままみたいなご依頼に快く応対してくださった皆さん、本当にありがとうございました。

京都にお越しの際は、ぜひ弊社にも遊びに来てください！！

プログラマ35歳定年説勉強会を開催しました。 #DevKan

先日の土曜日に、プログラマ35歳定年説勉強会(Doorkeeper) を開催しました。

講演をお願いした仙石さん、谷口さんのお二方のお話も素晴らしく、ディスカッションの時間には参加者の皆さんも熱心に議論してくださり、良い勉強会だったと思います。

内容や感想については参加者のどなたかが書いてくれると期待して、僕は主催者目線でこの勉強会を振り返ってみたいと思います。

そもそも、この勉強会を企画した動機は、自分自身が今35歳という年齢をオンタイムで生きていることにつきます。

20代が終わって、30歳になった瞬間には特になんの感慨もなかった僕ですが、去年の9月に35歳になった瞬間は何やら色々なものが重くのしかかったような気がしました。

それは、若い頃から「35歳定年説」を聞かされてエンジニア人生を送ってきた刷り込みのようなものが原因だったのかもしれません。

32歳のときに、僕は当時勤めていたSIを退職し、今の会社に来ました。Excel方眼紙と向かい合い、徹夜で見積もり資料を作ったり、オフショアからの成果物をチェックしたりと、このままでは「プログラマ」と名乗ることは永遠にできなくなると危惧した僕は、今の会社に入り、幸い35歳を迎えた今でも毎日Scalaでプロダクトコードを書き続けています。

では、今の会社でこのままプログラマとしてコードを書いていけるかというと、そう簡単なものではありません。

今年に入って組織変更があり、上司が新しくなり、僕は日々、「お前もそろそろマネジメントを覚えるべし」という圧力にさらされています。今の開発プロジェクトではリーダーというポジションに置かれ、会議の出席やらスケジュール管理などでコードを書く時間は以前より減りました。

そんな状況にあって、世の中の35歳という時を生きているエンジニアの皆の話を聞きたい、というのが、この勉強会を主催した意図でした。

ただ、この勉強会は企画当初から大きな矛盾をはらんでいる事は認識していました。

それは、「こんな休日にわざわざ勉強会に来て議論するような人間は、そもそも自力で35歳定年説など克服することができるはずである」ということです。

勉強会後の懇親会で、ある人がこんなことを言っていました。「この勉強会におけるディスカッションが本来の意味で成功、となるには、35歳定年を克服できる人間と、それに抗えない人間がお互いに怒号を飛ばし合うことであるはずだ」

これはある意味で真理です。今回の勉強会は、実際には「35歳定年説など信じていない人達が、その正体が実はなんであるのかを探りにくる会」でしかなかったといえます。

ただ、それはそれで良かったのだと思います。少なくとも、いくつかの問題提起はできたはずだし、参加者の皆さんもなにかを持ち帰ることはできたでしょう。

僕自身、１人で悶々と35歳定年について悩んでいるだけでなく、様々なコンテキストの人の考え方に触れることができて少し気分が楽になりました。

僕自身があの勉強会で得た結論はあえてここには書きませんが、この勉強会が参加者の皆さんのエンジニアライフに何かをもたらすことができたのなら、嬉しいです。

COVERALLSのバッジがGithub上で更新されない問題

dmm4sというライブラリを作ってる。

ライブラリ自体は、DMM APIを叩いて結果のXMLをScalaのcase classにマッピングしているだけの多愛のない物だ。

このライブラリを作ったテーマは、「ライブラリとしてちゃんと作る」ということ。
Maven Centralリポジトリへの登録であるとか、CIを構築するとか、テストを書く、とか。そういう「OSSとしてちゃんと作る」という事を自分のテーマとしてやってみた。

そういうテーマを課して作ってみたので、GithubのREADMEにその証としてTravis CIとCOVERALLSのバッジを貼ってみた。

しかしこのせいでドハマりすることになる。

まずはこちらのスクリーンショットを見ていただこう。

これはdmm4sの0.1-SNAPSHOTをリリースした時のREADMEのスクリーンショットである。COVERALLSのバッジの色が赤いのが御覧いただけると思う。このバッジが示すカバレッジは71%。COVERALLS的にはテスト足りてないんじゃないの？ と警告されているわけである。

しかし、実際にはこの時、COVERALLS上でのカバレッジは96%であった。お疑いのようならこちらのサイトへおもむき、「0.1-SNAPSHOTリリース」とコメントのついた履歴をご覧頂きたい。

カバレッジ71%というのは、dmm4sにCOVERALLSをはじめて導入した際のカバレッジである。つまり、GithubのREADMEとCOVERALLSとが連動していないのである。

しばらく待っていればそのうち連動されるだろう、と思いつつ数日を過ごすも一向に変わらない。READMEを更新してみたり、バッジを一旦削除してみたりしても変わらない。

行き詰まった僕は、COVERALLSにissueを投げてみた。

https://github.com/lemurheavy/coveralls-public/issues/209

結果、中の人からは「youのバッジは最新になってるYO！」とのこと。どうやらこちらの意図がうまく伝わらなかったのだろうか。
issueのコメントには「Please re-open the issue if you see it happen again.」と書いてあるのだが、re-openのボタンがどこにも見当たらない。

オレのアカウントにre-openできる権限ねーじゃねーか！！！！

ふと思い立ち、ChromeでREADMEに貼ってあるバッジ部分のコードを読んでみる。

するとこのバッジ、HTML上はgithubのキャッシュを参照しているようだ。

僕がREADMEに貼っている実際のリンクは次のコードである。

https://coveralls.io/repos/daiksy/dmm4s/badge.png?

このリンクが変われば、キャッシュも更新されるだろう、と思い、"https"を"http"に変えてコミットしてみた。そうすると…。

更新されたああああああ！！

しかし、次にカバレッジが変わった場合にはもう一度"https"にしたらなおるんだろうか…。

sbt 0.13.1でMaven Centralリポジトリに登録する方法

今日の第3回 Scala関西ビギナーズに間に合わせようと、先週から毎日少しずつコードを書き進めて、dmm4sというライブラリを作った。

SNAPSHOT版とはいえなんとか勉強会当日にリリースが間に合い、そこそこの笑いを取ることができた。

sbt はご存知の通り、ver間の互換性に難があり、sbt 0.13.1でのライブラリ開発はちょくちょく詰まりポイントがあった。Travis CI, Coverallsの利用など、多くはsbtのverによる依存関係の問題で、基本的には各pluginやライブラリの最新版を使うことで解決することができた。

Maven Centralリポジトリへの登録も、基本的にはsbtのドキュメントの通りで問題なかったのだが、ちょくちょく苦労したポイントがあったのでまとめておこうと思う。

環境は

sbt version: 0.13.1

scala version: 2.10.3
Mac OS X 10.9.1

1. Sonatype OSSRHでJIRA登録

まずはSonatype JIRAにユーザ登録し、ログイン。その後画面の左上あたりにある"create issue"をクリックし、必要事項を記入する。

Issue Type: "New Project"を選択

Summary: プロジェクトの概要

Group Id: build.sbtなどに設定している、organizationの値

Project Url: プロジェクトのサイトURL（githubのURLで良い）

SCM Url: githubのURL

ちなみにdmm4sのチケットはこちら

https://issues.sonatype.org/browse/OSSRH-8682

しばらく（1日くらい？）待っていると、中の人が設定終わったよ、という返信をくれる。

僕は深夜にJIRA登録したのだが、登録後10分くらいで返信が来てビビったw

2. PGPキーの作成

gpg --gen-key

コマンドでPGPキーを作る。gpgが入って無ければ、

brew install gpg

でインストールできる。

gpg --lisy-key

で作成されたキーを確認し、

gpg --keyserver http://pool.sks-keyservers.net --send-keys {キーID}

でkeyserverに公開鍵を登録する。

3. sbtのセッティングとpublish

http://www.scala-sbt.org/0.13.1/docs/Community/Using-Sonatype.html

上記のドキュメントに従い、sbtに各種設定を追記する。
基本的にはここに書かれているコードをコピペしつつ、sonatypeのパスワードとか、自分のプロジェクトのURLなどを書き換えればいいのだが、publish時にPGPキーの署名をする部分でうまくいかなかった。

sbt 0.13 でPGPキーの署名をしつつpublishするには、SBT PGP Pluginをインストールし、sbtで

publishSigned

のコマンドを実行する。

上記のsbtドキュメントにもSBT PGP Pluginへのリンクが貼ってあり、ここに"~/.sbt/plugins/gpg.sbt"ファイルを作成して、"addSbtPlugin("com.typesafe.sbt" % "sbt-pgp" % "0.8.1")”と書け、とある。

僕もそれに従ったのだが、sbtで"publishSigned"のコマンドを認識してくれない。

これは、ファイルの作成場所が間違っており、正しくは"~/.sbt/0.13/plugins/gpg.sbt"が正しい。

4.リリースの処理を実行

https://oss.sonatype.org/index.htmlにアクセスし、sonatype JIRAと同じアカウント、パスワードでログインする。

左側の一覧から"Staging Repositories"をクリックすると、一覧が表示され、自分のプロジェクト選択。"close"を実行する。ここで成功したら"release"を実行。

あとはJIRAに、リリースした旨をコメントすれば、中の人がCentralリポジトリに同期させてくれる。

とまぁ、こんな感じ。

命がけのリアル脱出ゲーム - トイレに閉じ込められたはなし -

■トイレのドアノブが壊れる

2014年1月25日 22時頃。友人たちと楽しんだベルギービールの余韻に浸りつつ、帰宅。
突然の雨に体を濡らし、熱いシャワーでも浴びたいところだったが、ビールの摂取に起因する尿意を解決するため、とりあえず部屋着に着替えてトイレに入る。

用を足し、水を流し、外に出ようとドアノブに手をかけて右に回すが、手応えがない。
訝しみつつそのままドアを開けようとするが、当然ドアノブに手応えがない以上、ノッチが引っかかったままで開くはずがない。

ん？ 何かがおかしい……。

酔っていてドアの開け方を忘れたのかな？ 右回しかと思ったけど左回しだったかもしれん。

もう一度、次はドアノブを左に回す。…が、手応えなし。

うっかり鍵をかけてしまったのかもと思い、鍵のつまみを回すも、やはり空回りするばかりで手応えがまるでない。なにをどうやってもドアのノッチが開いてくれない。

これは…まさか…閉じ込められたのか…。

長い闘いのはじまりである。

■自力脱出を試みる

我が家は妻と２人暮らしである。土曜日の夜、普通なら妻がいる。さして広い家でもなし、大声で彼女を呼べば通常ならかけつけてくれるはずである。

が…しかし…。

妻はIT業界の闇、デスマーチに巻き込まれ、休日出勤の只中にあった。22時にもなるというのに帰ってきていない。デスマ滅んでしまえ。ブラック企業ごと滅べ。この世から。跡形もなく。

雨に濡れて体も冷えている。いつ帰ってくるともしれないデスマーチ中のITエンジニアの帰宅など待っていられない。まずは自力脱出を試みる。

脱出の鍵はやはりドアノブである。ドアノブが故障しているのはもはや明白であるが、これをなんとかしないことにはドアは開けられない。現状確認だ。

どう回しても空回るこのドアノブは、調べてみると左にいっぱい回した状態から、右にいっぱい回した状態まで300度ほど回転する。1回転より若干少ない。
そして、ドアノブの中心に鍵をかけるためのつまみがついている。これも空回りするが左右に回転する。

これらの組み合わせで、なにか運良く一瞬でもノッチとドアノブが連動しないだろうかと試してみる。

左にいっぱい回した状態で、鍵のつまみを左右に動かす。次に右にいっぱい回した状態で、鍵のつまみを左右に。これをドアノブを少しずつ動かしながら根気よく組み合わせを試していく。直交表が手元にほしいところであるが贅沢はいえない。頭にExcel方眼紙を思い浮かべながら全てのパターンを網羅する。

…が…開かずっ…！？

空回りしているのだから当然か。ドアノブの組み合わせによる解放は早々と諦める。

次にガチャガチャと力任せにドアノブを乱暴に扱ってみるが、なにも起こらない。刑事ドラマで、密室殺人発生時に強引にドアをぶち破っているシーンを思い浮かべ、肩から力任せにドアに体当たりしてみるが、肩を痛めただけでドアはびくともしない。

…なんて堅牢なドアだ…。たかだか室内のトイレのドアをここまで頑丈にする必要がどこにあるんだ……。

少し心を落ち着けて、冷静に現状を確認して脱出の手立てを検討することにする。

■トイレの密室感は異常

脱出するために、自分になにができるのか。今ぼくの手元にはどのようなカードが配られているのか。それを確認する。

外部との通信手段さえあればどうとでもなるはずだが、大便のときならともかく小便をするだけのためにわざわざ個室にiPhoneを持って入らない。

外部との通信手段は皆無である。

次に室内を見回す。

まず、トイレ清掃用のブラシが便器の脇に設置されている。あとは予備のトイレットペーパー、そのトイレットペーパーを設置するために芯を貫く棒。トイレクリーナー的なもの。これだけ。

……そう…これだけ…。

トイレの室内に工具などあるはずもない。ドライバーの一本でもあればドアノブを外すこともできる。しかし、何もない。

一般家庭のトイレの個室の中には、何一つとして脱出に使える道具はないのである。

ここで、子どもの頃に読んだ冒険小説を思い出す。冒険小説の主人公は、一見するとなんの関係もない道具をうまく応用して使うことで、サバイバルを切り抜けていた。ぼくにもやれるはずだ。考えろ。極限まで思考を巡らせろ。

まず、何か硬いカードのようなものをドアの隙間に押し込んで、ノッチを外せないかと考えた。

トイレットペーパーの芯は結構硬い。これをある程度の強度を確保しつつ平らに加工し、使えないものだろうか。

結論からいうと、ダメ。外側からならともかく、内部側は、ドアがこれ以上内側にいかないように枠がはめられていて、それが邪魔をしており、ドアのサイド側の隙間になにかを差し込むことができないようになっている。

トイレットペーパーはどうやら脱出には使えそうにない。

次にトイレットペーパーを設置する棒をなにかに使えないかと考えた。

ドアを見ると、下部に手のひら程度なら通過できるくらいの大きな隙間が開いている。ここに棒を押しこみ、テコの原理でドアの一部でも破壊できないものか。

……えいや！！

勢いにまかせて棒に力を込めると、バキッ、という音とともに手応えが…！？

……棒が折れた。

もうだめだ…。密室すぎる…。残されたトイレクリーナーとトイレブラシをどう応用したらドアを破壊することができるというんだ……。こんなもの、トイレ掃除する以外の使い道なんて思いつかない…。

床にしゃがみ込み、絶望に打ちひしがれる。もう妻の帰りを待つしか無い。ドアの下部にあるこの隙間。ここからドライバーさえ渡してもらえたら、ドアノブを外すことができるし、脱出の手段は劇的に増えるだろう。iPhoneだって手に入る。

しかし、これがもし1人暮しだったらどうか。脱出の手段はゼロ。我が家にたずねてくる人など、Amazonからのお届け物を持ってくる配達員以外いない。しかも今はAmazonに注文しているものも無い。

…餓死するしか無いじゃないか！？

突然襲い来る死の恐怖。寒い。喉が渇いた。トイレの水って飲んでも平気なんだろうか。飲んでお腹を壊しても、トイレだしそこは大丈夫そうだな。

様々な思考が脳内を駆け巡り、トイレの床に体育座りでリアルに泣く、35歳の男の姿がここにあった……。

■妻の帰宅。ついに脱出にむけて光明がさす

永遠にも思える時を、トイレの個室の中で過ごす。時折隣の部屋の住人がトイレを利用するする音や、外の廊下を別の部屋の住人が歩く音などが聞こえ、その度にドアや壁を叩いて存在を主張してみるが、何の反応もない。

気が狂いそうだ。

どれくらい経っただろう。我が家の玄関が解錠される音が聞こえる。

！！！！？？ 妻が帰ってきた！！！！

立ち上がり、ドアを力いっぱい叩く。「助けてくれ！！！！ 閉じ込められた！！！！！」

事情を説明し、例のドアの下の隙間からiPhoneとドライバーを手に入れることに成功。

これで勝てる！！！！！

少し余裕が出てきたので、iPhoneを使ってTwitterにつぶやく。

トイレのドアノブが壊れてかれこれ2時間近く閉じ込められている。
— Daisuke,Kasuya (@daiksy) 2014, 1月 25

瞬く間に大量のRT。
お前らRTしてる暇があったら助けろ！ ksg！！

しかし、さっきまでのぼくとは違う。今は手元にドライバーがある。
慎重にネジを外し、ドアノブをドアから取り外す。これでなにか手がかりが得られるはずだ。

ドライバーを手に入れてドアノブ外したけど、どうにもならない。。。 pic.twitter.com/vdti4I5Z4d
— Daisuke,Kasuya (@daiksy) 2014, 1月 25

結果がこうである。
真ん中の四角い穴。これをどう回しても、ドアにはなんの反応もない。どうやら完全に壊れているようだ。
僕はドアノブを外して何がしたかったのだろう。完全に詰みだ。内側からできることはもう何もない。

なんなのだこれは。いくらなんでも密室すぎるだろう。もっと安全側に倒して設計しろよ。トイレのドアをここまで堅固にして、いったい誰が得をするのだ。もうだめだ。自力でできることなど何もない。ここはもう、業者を呼ぶしか無い。

業者に連絡する。深夜ということもあって、到着まで4, 50分かかるという。ここからさらに１時間弱待つのか…。

ここからの1時間は妻を待っているときの絶望感とは打って変わって心穏やかだった。脱出の糸口が見えていたし、TwitterでRTされまくって100近い励ましのリプライをもらっていた。もうぼくは１人ではない。あと50分。耐える！ そして生還してみせる！！

■神の使い。業者がやってくる

玄関のチャイムが鳴る。深夜2時。閉じ込められて4時間近く経過していた。

やっと業者がやってきた。妻と金額の話をしている。

払う…！金ならいくらでも…！！ ここから生きて出ることさえできたなら…！！ 払う！ 払わざるをえない…っ！

業者の話によると、ドアは完全に壊れており、ドリルを使って内部の金属を破壊するしかないという。なんだそれ。自力では無理ゲーすぎるじゃないか。１人暮らしだったらマジで詰んでるぞ……。

深夜のマンションに響き渡るドリルの音。ご近所の皆さんに申し訳ない。しかし仕方がないじゃないか。こっちは生き死にがかかっているんだから。

金具が完全に破壊され、ドアが開く。やっと外の世界に出られる。生還だ。まだもう少し、人生を生きることができる…。

鍵屋の仕事。こうなってた。 pic.twitter.com/25tQz4oSGM
— Daisuke,Kasuya (@daiksy) 2014, 1月 25

見事な業者の仕事ぶり。プロの仕事である。神すぎる。

こうして、ぼくは脱出することができた。
最初の閉じ込めツイートのRTは300を越え、いつのまにかフォロワーが40人増えている。

…お前ら……。

最後に記念に作成した悪循環コラを掲載し、このエントリを終えようと思う。

応援してくれたみんな。本当にありがとう。

トイレに閉じ込められる悪循環 pic.twitter.com/Xat5hT2n0M
— Daisuke,Kasuya (@daiksy) 2014, 1月 25

2013年を振り返る

今年も残すところあと僅かとなりました。毎年恒例の振り返りエントリです。

■プログラマ定年
今年の9月に35歳になりました。
以前勤めていたSIerでは、30歳を過ぎたあたりから少しずつ仕事でコードを書く機会が減ってきており、顧客調整とかスケジュール管理などの仕事が多くを占めるようになっていました。その後そういった状況が嫌で今の会社に転職し、幸いなことに35歳を数ヶ月過ぎた今でも毎日Scalaコードを書き続けています。

将来的にいつまでこの状態が続くかはわかりません。僕も今の会社で職位が上がり、開発リーダーなど任されるような日が来るかもしれませんし、そうなるとやはり自分が直接コードを書く機会は減るでしょう。ただ、そうなった後でも、今のマインドを捨てず、あくまでも「プログラマ」としてそういったリーダー業に従事できるようになりたいです。

"SE"とか"PL"とか"PM"とかではなく、限界ぎりぎりまで自分は"プログラマ"を名乗って仕事をしていきたい、ということを考える良いきっかけになりました。

■訃報
今年は身の回りに訃報が多い１年でした。
自分に大きな影響を与えた著名人だったり、同級生だったり、コミュニティの人だったり。まだ皆さんが亡くなられてから日も浅いですし、自分の中できちんと整理もできていないのでここでは多くを書きませんが、本当にいろいろな事を考えました。

■コミュニティ活動など
去年に比べると、勉強会などの参加数はかなり減ったと思います。
今までは手当たり次第にいろいろ顔を出していたのですが、勉強会でHP/MPを回復する、というような「勉強会お花畑」な状態では無くなったので、自分がどのようにコミュニティに対して貢献するか、どのように自分のキャリアを積むか、ということに少し悩んでいました。

自分がスタッフやスピーカーなど、「中の人」として関わった勉強会をまとめます。

1月

・ TDDBC 大阪 for C#（Visual Studioハッカソン事前勉強会）
現場でのペアプロについてお話させていただきました。風邪を引いて翌日のハッカソンを欠席するなど、少し迷惑をかけてしまった記憶があります。

2月

・DevLOVE関西「勉強会勉強会」
勉強会について勉強する、というメタな勉強会です。
ビアバッシュでのQAコーナーのファシリテーターをしました。

3月

・Scalaカンファレンス
今年の社外活動の中で最も印象に残っているカンファレンスです。
最初、公募セッションに応募したものの落選し、その後いろいろあって会社がスポンサーになってくれたので、スポンサー枠で発表させていただきました。
こちらのエントリにも書きましたが、ものすごい熱気で、この時代にあの場所にいれた事をとても幸福に思います。

・ステーキ駆動勉強会(hoge駆動)
いつものhoge駆動でした。

4月

勉強会参加はなし。

5月

・第4回 関西ソーシャルゲーム勉強会
会社で、ソーシャルゲーム関係者を招いての交流会をやったのがきっかけでスピーカーとして呼んでいただきました。これをきっかけにスタッフとして第５回のお手伝いをすることになります。

6月

お世話になった某社の編集者さんが留学されるということで、送別会に行ったりしました。あとはプログラマーズナイトでLTをやったり。

7月

・IT英語勉強会 第1回
Scalaカンファレンスで英語のスライドを作ったことで少し自信がついて、参加してみました。生まれてはじめて、英語でLTをしました。ネイティブの人に、聴きやすい発音でしたよ、と言っていただけて嬉しかったです。また行きたい勉強会の１つなのですが、他の予定と被たりしてなかなか参加できずにいます。

・アジャイルラジオ 前編 後編
Webラジオに出演しました。めちゃくちゃ緊張して、何を喋ったのかあまり覚えていないです。だいたい雰囲気がわかったので、もう一回やりたいです。

・日経コンピュータ 奇跡のJava
ある日仕事をしていたら、本社の広報から自分のデスクに電話がかかってきました。普段広報から内線が来ることなどないので、SNSでNGな話題でも書いてしまって怒られるのかと身構えていたら、この記事の取材申し込みについての連絡でした。Scalaカンファレンスでの登壇がきっかけだったようです。
雑誌の取材を受けるのは当然人生初体験だったので、いい経験をさせてもらいました。

・夏のhoge駆動☆カレーの王子さまリターンズ
いつものhoge駆動でした。

8月

勉強会参加はなし。仕事がむちゃくちゃ忙しかった記憶があります。関西に遊びに来た@zer0_uさんとランチ食べたりしました。

9月

・デブサミ関西
憧れのデブサミに登壇することができました。自分戦略セッションが公募制で、自薦も可、とあったのでダメ元で申し込んでみました。たぶんムリだろうと思っていたのですが、なんと人気投票1位ということでびっくりしました。

10月

・高速ITコミュニティ秋祭り
初回から参加しており、今年で3回目の開催になります。
これまでは登壇者としての参加でしたが、今回はスタッフとしての参加です。といってもあまり大したお手伝いはできなかったのですが…。

こういう、「お酒と食事を楽しみながらのトークイベント」という形式は個人的に大好きで、関西でもこういう企画をやりたいなー、と常々思っています。来年あたり実現したいです。

・怖くないScala勉強会
Twitterでの会話をきっかけに、日経コンピュータさんの奇跡のJavaの記事とも絡めて開催したイベントです。
Scala関連の勉強会の盛り上がり方は本当に驚くばかりです。こういうコミュニティの盛り上がりを絶やさず、現場の普及も着実に拡げていきたいものです。

個人的には、持ち時間に対して大幅に早く発表が終わってしまう、という大失態をやらかしてしまい、反省点の多い勉強会でした。

11月

・第9回 RxTStudy
DVCSについて話してほしい、というご依頼をいただいたので、以前関Javaで話したgitの失敗事例の後日談をお話してきました。

・開発現場に伝えたい10のこと
達人出版会さんから出版されている電子書籍です。DevLOVE関西にゆかりのメンバー10人で書きました。5月のGWに執筆し、11月に出版という長期プロジェクトでした。

・第5回関西ソーシャルゲーム勉強会
主催という立場でやらせていただきました。会場提供やスピーカーへの呼びかけなどアマゾンデータサービスさんにものすごくお世話になりました。
こちらの勉強会も継続してお手伝いさせてもらおうと思っています。

12月

・合同勉強会 in 大都会岡山 -2013 Winter-
毎年恒例の岡山での勉強会。LTでは途中でマシンがフリーズしてしまい、「自己紹介を2回やる」というネタにあふれたLTでした。

・Far East Developer Review
DevLOVE Pubが冬コミで頒布する同人誌に寄稿させていただいてます。
これもずいぶん前に書いた文章なのですが、ようやく陽の目を見られました。

・忘年会駆動
いつものhoge駆動でした。

■まとめと来年の抱負

来年に向けて、デブサミの公募セッションに応募したのですが、落選しました。一度雅叙園で登壇してみたいので、機会があればまたチャレンジしたいです。

今年１年間、コミュニティ活動をしてきて、実に様々な人と関わりを持ちました。そのような中で、自分たちの開発が、決して他社に引けをとらない、という自信も持ちました。

僕が勤める会社は、まだまだネームバリューが高いとはいえません。全国的に名を売ろうと思えば、大ヒットのサービスをローンチするなど自分個人では難しい部分もあるでしょう。しかし、エンジニア界隈でバリューを上げる、ということなら、今までコミュニティに対してコミットメントしてきた自分もある程度貢献できるのではないかと思い始めました。

これまでは自分個人のバリューアップのみに焦点を絞っていろいろな活動をしてきましたが、2014年は自分と会社双方のバリューアップに貢献できるような動きをしていきたいなー、と思っています。

いろふさんとの思ひ出

いろふアドベントカレンダー 18日目です。昨日はみうみうの「いろふさん絵描き歌」じゃないヤツ、歌ってみた #irof_history でした。

技術的なネタの構想もあったのですが、こちらは動画を撮ったりいろいろ仕込が必要で、今日は自分の番だということをすっかり忘れていてついさっきまで先斗町の鉄板焼き屋でぼっち日本酒を嗜んでおり、気づいたら準備する時間が無くなってしまいました。元々のネタはhoge駆動で発表しようと思います。

と、いうことでいろふさんとの思い出話でも。

いろふさんと初めて出会ったのは、2011年4月のScala本読書会でした。

こうして振り返ると今や同僚となった塾長がいたり、後にほげメン（hoge駆動メンバー）と呼ばれる人達のほとんどが集まっていたり、僕自身当時の会社を辞めてScalaで仕事してたり、今の僕のある意味で原点みたいなところだなぁ、と思います。

いろいろ思うところあって勉強会に行き始めたところでもあり、Scalaに興味を持ち始めた初期の頃でもあり、当時の同僚だったs_kozakeさん以外は全員初対面でした。
（この次に参加した勉強会がイケメンと初めてお会いしたTwitter4j読書会だったと思う）

そんな中にいろふさんもいました。

この時にいろふさんとの接点はほとんど無かったと思うのですが、この読書会のすぐ後に僕がこんなイベントを企画しました。

第1回 業務前モクモク会

同僚のs_kozakeさんと、会社の近くの喫茶店で始業前に勉強してから会社行こう、という会で、もともと２人でやればいいや、と思っていたのですが、他に来れる人がいたら皆で集まって各自で勉強しましょう、ということでATNDをたてました。

そこにいろふさんが来てくれました。いろふさん自身も当時思うところあって、いろいろな場に積極的に顔を出そうとされていたところだったようです。今の「いろふ複数インスタンス」の最初期だったのでしょう。

そういったところで、お互い「勉強会にとりあえず手当たり次第に顔を出す」みたいな最初の時期に接点があって、僕はなんとなくいろふさんを近い存在として感じていました。

で、なんやかんやあって今に至るわけです。

なんやかんやの部分はまた気が向いたらまたどこかで。

DevLOVE Advent Calendar 2013 【29日目】「現場における正しさとは」

DevLOVE Advent Calendar 2013 の29日目です。

昨日は瀬宮新さんの「始まらなかったアジャイルを一人でもう一度始めようとした話」でした。

去年のDevLOVEアドベントカレンダーでは「仕事とプライベートがウェットってブラックなの？」でその年のDevLOVEブログで最も読まれた記事、に選ばれましたので、今年も頑張って書こうと思います。

■きっかけはある人の質問

先日、第9回RxTStudyで、チームにおけるgitの失敗事例と、その改善までのお話をさせていただきました。(そのときのスライド)

僕たちのチームでは、結成当初からgitを使ってソースコードのバージョン管理を行っています。導入当初はメンバー全員がほぼgitを扱うのが初めて、という状態で、幾度と無くトラブルにも見舞われました。

運用を安定化させるために、チームではいろいろな試みがなされました。様々なGUIツールを試したり、ブランチ戦略を検討したり。

そのような中で、最も効果が高かったのは、『入門Git』などを読んで「正しい知識を身につける」ということでした。

僕はRxTStudyでの講演を、「ツールを使いこなすには、まずは正しい知識をきちんと学ぼう」という結論で締めくくりました。

講演後、ある方から質問をいただきました。

「正しい知識、というキーワードがお話の中で何度も出てきましたが、正しさの定義とはどのようにお考えですか？」

なるほど。これは辛辣な質問です。

僕は「正しさの定義」はそれぞれのチームや現場によって異なると考えています。この時にいただいた質問でも、そのような主旨の事を回答しましたが、それをもう少し具体的に書いてみよう、というのがこのエントリのテーマです。

■現場における正しさの定義は「チームメンバーが合意すること」

「gitの使い方」というような場合における「正しさ」の定義は簡単です。そのツールの仕様が、正しさの前提だからです。

では、チームでコードレビューなどをする場合における「正しさ」はどうでしょう。「正しいソースコード」などと言われても実に曖昧で、正解などないような気がします。

僕はこういう曖昧なものに正解を求める必要があった場合、「チームメンバー全員が合意する」という事を軸に考えます。

コードレビューにおける「正しさ」は、最終的にチームメンバー全員が「それで良い」と判断すれば、それが「正しいコードである」とみなします。

ペアプログラミングでのプログラマ同士の議論、あるいはチーム全体でのレビュー。こういった、度重なる議論を経て、僕たちが書いたソースコードは最終的にプロダクトとして世に放たれます。ならばチーム全員の合意を「正しさ」の定義に据えるのが、最もわかりやすい考え方ではないでしょうか。

■「チームメンバーの合意」が間違っていることもある・・・

しかしこの考え方には危うさがあります。

ここである架空の現場を想像してみましょう。

彼らは仕様書をExcelで書いており、それを以下のように管理していました。

・認証システム設計書_20131208.xls
・最新版_認証システム設計書.xls
・最新版_認証システム設計書_bkup.xls

チーム全員が合意の上で、彼らはこのような管理をしているわけですが、これは本当に「正しい」と言えるでしょうか？

現場における正しさの定義には、「チームメンバーの合意」に、もう一つ付け加える必要がありそうです。

■正しさとは、「チームメンバーが合意」しており「困っていないこと」

メンバーが合意した方法や考え方であっても、チームとしてその運用が困難であったり、なにか問題がある場合、それは正しいとは言えないでしょう。

さきほどの設計書の例で言えば、メンバーの合意があっても、結局本当の最新版はどれか、という問題が生じてしまうのであれば、それは正しいとはいえません。

チームにおける「正しさ」とは、チームメンバーが合意しており、その運用において解決すべき問題が無い状態が望ましいです。

こういう正しさの定義は、チームの成熟度によって当然変化します。

今まで問題とされていなかったような事柄が、チームの成長にしたがって問題として顕在化することもあります。その場合はチームが成長して「正しさの定義」に変化があったということですから、その問題と向き合って新しい「正しさ」を見つければよいだけのことです。

僕たちは個人ではなく、チームで仕事をしています。
で、あるならば、その中で生じるいろいろな事柄はチームとして定義されるべきです。

僕からは以上になります。

明日は@shinyorkeさんです。

いろふインスタンスの最大数を探る。

いろふアドベントカレンダー3日目です。

昨日は@kawakawa さんのirofさんとAR（拡張現実）で遊んでみよう♪ でした。

ちなみに去年はこんなの書いてました。

さて。いろふさんと言えば、複数インスタンスですよね。昨日大阪の勉強会でご一緒したと思ったら、次の日は東京にいる、とかしょっちゅうで、いろふ複数インスタンス説が唱えられて久しいわけです。

と、いうことで、いろふインスタンスははたしていくつまで作ることができるのか、僕のMBP上のScalaのREPLで試してみましょう。ちなみにREPLはなんのチューニングもしていない、デフォルト状態です。

まずはいろふクラスを作りましょう。これが、すべてのインスタンスの元になります。

case class Irof(name:String, age:String, place: String)

型がすべてStringなのは、まぁ、ご愛嬌。

とりあえず、いくつかインスタンス作ってみましょう。

val irofs = List("osaka", "tokyo", "nagoya", "hokkaido").map(Irof("hirofumi nozaki", "unknown", _))

このくらいなら余裕です。
地名を指定するのも面倒なので、とりあえずこうして1000個くらい作ってみましょうか。

val irofs = (1 to 1000).map(p => Irof("hirofumi nozaki", "unknown", p.toString))

余裕です。

どうせなら、無限の世界に突入しちゃいましょう。いろふインスタンスに上限など設けてはいけません。

def xs(n: Int): Stream[Int] = n #:: xs(n + 1)
xs(1).map(p => Irof("hirofumi nozaki", "unknown", p.toString))

無限リストのmapですから、概念上、これでいろふインスタンスは無限に存在することになります。これでこそ僕らのいろふさんです。

ぼくも執筆に加わったDevLOVE本が出版されました

昨日、DevLOVE関西 -Decision- の開催に合わせて、「開発現場に伝えたい10のこと」という電子書籍が出版されました。

開発現場に伝えたい10のこと【電子書籍】

DevLOVE関西
達人出版会
発行日: 2013-11-16
対応フォーマット: PDF, EPUB

詳細を見る

ぼくも、「第二章 アジャイルな乙女ゲーム開発のおはなし」を執筆させていただきました。

今年のゴールデンウィークに数日かけて初稿を書いていましたから、ものすごい長期プロジェクトでした。

プロジェクト自体はBacklogで管理されていて、原稿はMardown形式で書き、gitで共有されていました。各担当者からのレビュー結果などがBacklogにチケット登録され、それを反映してgitにpushしてチケットをクローズする、というエンジニアにとって取っ付き易い形で作業を進められたので、楽しかったです。

前述のとおり、原稿を書いていたのは今年のゴールデンウィークの頃ですので、今とはチームの状況や仕事の進め方など変化している部分もありますが、チームのマインドはこれを書いていた頃と何も変わっていません。

皆さんの現場について考える小さなきっかけにでもなれば、嬉しいです。

このプロジェクトを立ちあげ、長期間牽引してくれた、@papandaさん、@yohhatuさん。達人出版会の高橋さん。執筆陣の皆さん。レビューに協力してくれた弊社技術ブログライターの皆さん。ステキな挿絵を提供してくれた@issps2009さん。本当にどうもありがとうございました。

デブサミ関西へのAction #kansumi

デブサミ関西 に参加してきた。


◆ラウンジスポンサー

デブサミといえば、開発者のお祭り。いろいろ都合があわなくて、これまで参加できておらず、今回が意外にも(?) 初参加である。

そんなデブサミが今年も関西で開催されると聞き、今年こそ、と意気込んでいた。
しかし実行委員の面子を見ると、知っている人ばかり（最近は関西の勉強会で知っている人がいないものの方が少ないけど)。そういうところへ、ただの一般参加者として行くのはなんだか勿体無いなーと思った。

自分もこれまで、関西のIT系勉強会やコミュニティに対していろんな貢献をしてきたし、その発展に少なからず寄与できていると自負している。だからこそ大きなお祭りであるデブサミに参加するからには、なんらかの形で手伝いたい、と思っていた。

するとラウンジスポンサーということで、参加者の電源つき休憩スペースを確保するためのスポンサーを募集しているということだったので、その場でクリックして申し込んだ。

これで心置きなくデブサミに遊びに行ける。

◆自分戦略

やはりデブサミでの登壇は勉強会クラスタにとっての憧れだ。
去年、東京のデブサミで「公募セッション」という枠があり、一般公募されていたので応募するかどうか悩んだ。
しかし当時、同じ時期にScalaカンファレンスの開催があって、そこに登壇する予定であったので、さすがにどちらか一本に絞るべき、と思って諦めた。

そんな折、デブサミ関西で今年も自分戦略セッションがあるという。去年、盟友の@irofさんが登壇してたやつだ。

これは一般からの投票の結果、上位者に登壇機会が与えられる。当初の実行委員選抜者の中に僕の名前は無かったのだが、自薦も可、ということで応募してみた。

すると、結果はなんと1位。 投票してくださった皆さん、本当にありがとうございました。

当日の資料はこちらになります。

デブサミ関西 自分戦略 2013 from Daisuke Kasuya

◆Action!

今年のデブサミ関西のテーマは「Action!」これは今回の自分の発表でも言いたかったことなのだが、僕の今回のデブサミに対する関わり方そのものが、僕のActionだ。

僕たちITエンジニアは、少し外の世界に目を向けるだけでいろんなActionの場が存在している。僕自身、エンジニアとしてのスキルはそれほど高いわけではないけれど、こうしてイベントなどで登壇したりできているのはActionの結果だ。

コミュニティとか、勉強会とか、イベントとか、そういうところに飛び込むことへのリスクはそれほどない。僕が今回、デブサミの自分戦略に自ら手を挙げて、投票の結果登壇できなかったとしても、別に失うものなんてなにも無い。事実、今回は半分くらい自分は選ばれないだろうと思いながら応募のクリックを押した。

今回のようにうまくチャンスを与えられた場合もあれば、逆にチャレンジしてみたけれどダメだった場合も星の数ほどある。でも僕は別にその失敗の結果何一つ失ってなどいない。

なので、みんなもっと物怖じせずにいろんなチャレンジをすればいいと思う。

◆プログラマ定年

こんなチャレンジを続けた結果、今日でプログラマ定年(35歳)になったわけだが、まだプログラマを続けることができている。
（ウィッシュリストをこっそり：  http://www.amazon.co.jp/gp/registry/wishlist/ref=wish_listhttp://www.amazon.co.jp/gp/registry/wishlist/ref=wish_list)

次はやっぱり雅叙園で登壇したいなー　(/ω・＼)ﾁﾗｯ

leapmotion sdkをsbtで動かしてみた

LeapMotionを購入して、いろいろ遊んでいる。

で、SDKを見ると、javaのSDKがあったので、せっかくだからScalaで実装して遊ぼうと思い、まずはSBTでLeapMotion SDKが動く環境を作ってみた。

まずはLeapMotionのDeveloperサイトでユーザ登録し、SDKをダウンロードする。

次にSBTプロジェクトを作成し、libディレクトリに"LeapJava.jar", "libLeap.dylib", "libLeapJava.dylib"を置く。

SDKにJava用のサンプルコードが入っているので、それをScalaで書きなおす（IntelliJ IDEAでコピペしたら勝手にScalaに変換してくれるw)。

ここまでは順調に行ったのだが、僕はここで詰まった。

lib配下に置いた "libLeap.dylib", "libLeapJava.dylib"はネイティブライブラリであるので、普通のjarファイルと違ってlibに置いただけではSBTでロードすることができない。

"-Djava.library.path"で明示的にlibディレクトリを指定する必要がある。

SBTでrunコマンドを実行すると、通常はSBTが動いているのと同じJVMで実行されるから、単純に考えるとSBTの起動時に"-Djava.library.path"オプションを指定してやればよさそうなのだが、これではうまく動かなかった。

なので他の方法を。

build.scalaにいくつかの設定を加えてやることで、runコマンドでの実行時に使用するJVMをSBTが動いているのとは別のものにすることができる。

Forking

そこでbuild.scalaに以下の設定を入れてみる。

fork := true

javaOptions ++= Seq(
   "-Djava.library.path=.:./lib"
)

これで実行してみたが、コンソールからの入力を受け付けてくれず、思った通りに動かない。fork run時に、標準入出力の設定をきちんと書いてやらないといけないようだ。

そこで次の設定を追加。

connectInput in run := true

これで動いた！！

ちなみにこれらの設定を入れたsbtプロジェクトのテンプレートをgithubに上げといた。

leapmotion-sbt

さて。やっとスタートラインに立ったので、なにを作ろうかなー？

デュシャンの「大ガラス」に出会った不思議な旅

この土日に東京に行っていた。

目的は土曜日の夜に、某オフ会に参加するためだ。

彼らとは２年ほど前からの付き合いで、年に1, 2度会うだけなのだが、会えば昔からの友人同士のように語り合える。この2年、いろいろなコミュニティに参加してきたが、ここが今の僕の原点で、人生で最初に参加した「コミュニティ」でもある。

彼らとは出会う前からオンライン上の付き合いがあったためか、初めて顔を合わせた時から、旧知の友人同士のような関係が築けていたような気がする。

彼らとの出会いで、僕はIT系コミュニティという存在を知り、はじめてのライトニングトークを経験し、多くの仲間と出会えた。

去年、僕が転職した当時、このコミュニティで知り合った友人の二人が京都にいた。僕も京都の会社に就職したので、これで彼らとしょっちゅう飲みに行けるぞ、と思っていたが、結局それが叶わないまま、二人とも時期は異なるものの、仕事の都合で東京に行ってしまった。このオフ会は彼らと久しぶりに再開した場でもあった。

オフ会の主旨自体は、コミュニティのメンバーだった一人と、諸事象によりしばらく会えなくなってしまうため、その前にみんなで会おう、という集まりだった。

なんだかみんな、遠くに行っちゃうなー。そんな事を思いながら、その夜はお酒を飲んだ。

翌日。ホテルを出て、このまままっすぐ帰ろうかと思ったのだが、なにげに道路に設置されていた周辺地図を見ると、近くに大橋ジャンクションがあるというので見学して帰ろうと思った。僕は洋の東西や規模の大小を問わず、珍しい「建築物」が好きなのだ。

ひとしきり大橋ジャンクションの威容を愛でたあと、帰りの時間は特に決めていなかったので、周囲を散歩してみようと思った。

特にあてもなく住宅街を歩いていると、なにやら緑の深い一帯が見える。公園でもあるのかと思いそちらに行ってみると、そこは公園ではなくて、東大だった（笑）

駒場キャンパスだ。

一人で日曜日に大学キャンパス内を歩いていて、不審者と思われたらやっかいなので、とっとと立ち去ろうと思ったが、そういえばここにはアレがあったんじゃないか？ とある記憶が頭をよぎった。

僕はマルセル・デュシャンが大好きで、死ぬまでに必ずフィラデルフィア美術館で彼の遺作を見ようと心に決めている。そんなデュシャンの代表作『花嫁は彼女の独身者達によって裸にされて、さえも』（通称大ガラス）の東京バージョンが、駒場の美術博物館に常設されていたはずだ。

いつか観た来たいと思っていたが、東大のキャンパスやその近くに来る用事などあるはずもなく、また、わざわざこのために来るというのもはばかられていたので、ずっと機会を伺っていたのだ。

キャンパス内を探すと、美術博物館はすぐに見つかった。中に入ると、展示ホールの中央にそれはあった。去年、マン・レイの写真展で、彼の「埃の培養」という作品越しに観た、ガラス板（埃の培養に写っているのはオリジナル版で東京バージョンではない）。
あの、作品を象徴するガラスのヒビが入っていない、フラットな表面。念願の「大ガラス 東京バージョン」だ。

これを観た瞬間、すごく不思議な気持ちになった。昨夜、なんとなくさびしい気持ちでお酒を飲んで、その翌日にまったくの偶然に、ここにたどり着いた。この作品が向こうから僕に近づいてきてくれたような、そんな感覚だった。

この土日は、なんだが不思議な旅だったが、来てよかったと思った。

関西ソーシャルゲーム勉強会は超熱い勉強会だった

第4回関西ソーシャルゲーム勉強会 で発表してきました。

先日、ソーシャルゲーム会社の交流会 に参加した折に登壇の依頼をいただいてお話をしてきたのですが、想像以上に熱い勉強会でした。

80名近い人が参加する、という大盛況ぶりで「関西にソーシャルゲーム関係者ってこんなにいるのか！？」と驚きました（そりゃいるだろうけどもw）

今回はDeNAの川上さんが登壇されるということも、楽しめたポイントでした。これまで、GREEさんとか、サイバーエージェントさんの人とは他の勉強会で交流する機会がありましたが、DeNAさんの中の人とお会いするのははじめてだったので。

僕はいつものごとく「乙女ゲーム」の話をしてきました。
以前、Scalaカンファレンスで発表した際に、「発表タイトルに"乙女ゲーム"と入っていたから期待してたのに、あまり乙女ゲーム成分がなかった」というフィードバックをいただきまして、その反省を踏まえて構成を考えました。

ご依頼があればどこにでも喋りに行きますので、オファーお待ちしておりますw


今回の勉強会では、広告戦略の話などで具体的な金額の話なども飛び出し、「えっ！ そこ言っちゃうの！？」というこれぞ関西のノリ、という濃い勉強会だったと思います。おそらくは「ソーシャルゲーム関係者の集まり」という会場のコンテキストだからこそ実現できた内容なのだろうと思います。Google相手に金額交渉で値切る、というのはすごい話でしたw

懇親会は、LTを交えながらビアバッシュ形式で行われました。
僕らが普段よく参加する勉強会は、エンジニアの集まりがほとんどなので、懇親会でも技術の話が多いです。しかし、今回はデザイナさんや営業さんなど「ソーシャルゲーム」に関わるいろんな職種、業種の方が集まっていました。そのため懇親会でも、開発会社さんやデータセンター事業者さんからの売り込みがあったり、すごく新鮮な感じでした。

普段、「ソーシャルゲーム」という枠組みの中で、各社が交流する機会というのがまだまだ少ないですから、こういう懇親会もいいなー、と思います。

ソーシャルプラットフォーム各社さんも関西に進出してきていますし、もっと業界を盛り上げていきたいです。

DevLOVE関西「SQLアンチパターン・レトロスペクティブ関西・リターン 」 に参加しました。

DevLOVE関西「SQLアンチパターン・レトロスペクティブ関西・リターン 」 に参加しました。

「SQLアンチパターン」の監訳者である和田さん親子を招いての勉強会です。



最初に、和田卓人さん の講演で25のパターンに関する説明を受け、その後グループディスカッションで自分たちの経験を25のパターンに当てはめて議論し、最後に26個目のパターンを見つけて名前をつける、という流れでした。

個人的には「SQLアンチパターン」に書かれてある内容は、ほとんどすべて見たことがあります。実際に自分がデータベース設計をするにあたって、やってしまったパターンもいくつもありました。

ただ、最近はソーシャルゲーム開発に携わっていることもあって、あまり設計時にガチガチにER図とにらめっこすることが無くなりました。DB側で制約をつけすぎると、柔軟性が損なわれるので、DBは最低限の「入れ物」と見なす事が多いからです。

また、ORMなどを使うのであまりアプリ側でSQLを直接書いたりしませんから、複雑なSQLクエリを書いて仕事をさせる、というよりは最低限のWhere句でデータの塊をとってきて、実装側で加工することが多いです。特にScalaのコレクションAPIはそれをしやすい機能だったりするので。

そのため、最近はここに書かれているアンチパターンは、特に意図せずとも遭遇する機会が減ったなー、という印象でした。

そういう話をしていたら、「RDBネイティブとNoSQLネイティブの世代間ギャップを最近感じる」という意見が出されたりして、興味深いディスカッションになりました。

最後に、いつも会場提供くださる楽天さん、ありがとうございます！
毎回おもしろい勉強会を開催してくださるDevLOVE関西スタッフの皆さん、ありがとうございます！