2012年を振り返る(後編) - コミュニティ活動について -

2012年を振り返るエントリ。前編は転職について書きました。
後編は、今年一年のコミュニティとか、勉強会活動とかプライベートについて。

■1月
12月に今の会社の内定をもらい、1月31日までが前職の勤務でした。
この月は勉強会は行ってなかったですね。本当は有休を消化したかったのですが、いろいろ理由もあって、27日まで前職の仕事をしていました。

転職エントリを書いたり、新卒で入った会社の社長さんが転職するという話を聞きつけてお祝いしてくださったり、the HIATUSのライブに行ったりしてました。

■2月
1日付けでフリュー株式会社に入社しました。

勉強会としては、以下の２つに参加しました。

・鍋駆動勉強会 (hoge駆動)
・勉強会初心者のための勉強会(2012年春の陣)

まだ転職直後だったので、この頃は新しい会社に馴染むのに必死でした。

■3月
勉強会参加は無し。

鹿駆動とか、関数型勉強会の準備をしてました。

やはり転職直後でしたので、プライベートにそれほどリソースをつぎ込む余裕はなかったです。と思ったけど、カレンダーを見たら友だちの名古屋マラソンの応援に行ったり、飲み屋の4sqチェックインがやたら多かったり、遊んでますねw

■4月

・Tech readers!! #3
・プログラマズナイト
・鹿駆動勉強会(hoge駆動)

今年のハイライトと言ってもいい、鹿駆動勉強会ですね。
500人キャパの能楽堂でLT大会とか、人類史上最初で最後のイベントだったと思います。

@ITさんで記事にもしていただきました。

世界遺産でIT勉強会を開催する方法――場所駆動勉強会のススメ

■5月

・オープンセミナー岡山@2012
・第1回関数型言語勉強会勉強会 大阪

大都会岡山の勉強会初参加。むちゃくちゃ楽しかったです。
関数型言語勉強会は、主催者という立場だったのですが、仕事が立てこんで参加できませんでした…。

■6月


hoge駆動メンバーで@backpaper0さんの結婚式の2次会に呼んでいただきました。

あとはエンジニアライフのオフ会に行ったりしましたね。

■7月

社員旅行でマカオに行きました。

・第3回 playframework 勉強会

今年の下半期の自分の発表テーマとなる、「乙女ゲーを支える技術」の初演でした。

■8月

勉強会参加は無し。

フェスに行ったり、夏を満喫してました。

■9月

勉強会参加は無し。

@mumoshuさんが執筆されたWEB+DB Pressのレビューをさせていただいてました。


■10月

・ITコミュニティ秋祭り リターンズ
・関西Javaエンジニアの会 '12 10月度
・やきに駆動2.0 (hoge駆動)

忙しかったですね。個人的にはITコミュニティ祭りが印象深いです。
カルカルさんでのイベントは、ぜひまたやりたいです。

■11月

・DevLOVE関西
・PlayFramework関西ビギナーズ
・第2回関数型言語勉強会 大阪

仕事にも慣れ、この頃はScalaなどの自分が新しい職場で扱う技術についての布教活動を熱心にやってます。
この辺りの活動は今後もこだわってやっていきたいです。

あとはエンジニアライフのエントリが週間・月間ランキング1位になり、@IT全体のランキングでも2位なったり、コラムニストとしての活動に一つの結果が出た時期でした。

■12月

・関西Javaエンジニアの会スペシャル！ JavaOne2012
・合同勉強会in大都会岡山 -2012 Winter -
・Scala関西ビギナーズ
・忘年会駆動(hoge駆動)

こしてみると、10月以降、勉強会行きまくってんな。

■2013年

今のところ、参加が決まってる来年のイベントはこんな感じ。

・TDDBC 大阪 for C#
・勉強会勉強会 (2月)

公募セッションの申し込みをして当落待ちのもの

 ・Scala Conference in Japan 2013

やりたいなーと妄想中のもの

・第3回関数型言語勉強会
・鹿駆動みたいなアホな大規模イベント (hoge駆動カンファレンス的な)

関数型言語勉強会は、いつも50人がすぐに満席になってしまうので、100人くらいの会場で規模をもっと大きくしてやりたいです。

あとはぼくの夢なのですが、雅叙園のデブサミに呼んでもらえるようなエンジニアになりたいですね。

来年もよい年になりますように。良いお年を！

2012年を振り返る(前編) - 転職してどうだった？ -

さて、年の瀬です。去年も1年間の活動を振り返ってみましたが、せっかくなので今年も振り返ろうとおもいます。

今年は、転職という大きなトピックがあったので、エントリを２つにわけます。
前編は転職について、後編は、1年間のコミュニティ活動と来年やりたいことについて。

と、いうわけでまずは前編です。

■ソフトウェアに対する姿勢の変化

今年の2月1日から、今の会社に入社し、ちょうど僕が入社した日から本格的な開発が開始されたソーシャルゲーム（乙女ゲー）の新規開発チームに配属されました。

5月末に無事リリースを迎え、その後別ラインで開発されていたもう一本の乙女ゲーチームと合流し、2本のゲームの運用、それと年末リリースの新規ゲームの開発を並行して行う、というのが今年の僕たちの主な仕事でした。

前職はいわゆるSIerで、受託開発の部門で仕事していました。受託の開発というのは、言ってしまえばリリースがゴールです。納品の検収をトリガーに、お客さんからお金を頂くことになります。

一方で、サービスの世界ではリリースがスタートとなります。リリースの時点で、そのサービスはまだ1円足りともお金を生み出しません。リリースし、そこから一定の月日を継続して運用することで、利益を積み上げていきます。

自分が開発・運用に携わるこうしたビジネスモデルの変化は、僕のソフトウェアに対する考え方を大きく変えてくれました。

「作って終わり」ではなく「使われることに意味がある」ということ。これはこの世のあらゆる製品に共通する本質ですが、作りきりの受託開発の世界で仕事をしていたときは、理屈としてはわかっていても、実感できたことがあまりありませんでした。

実際にお客さんから問い合わせがあり、納品後のシステムをメンテナンスすることは前職でもありましたが、それらは「忘れた頃にやってくる」突発的なものであり、継続的に行われるものではなかったからです。もちろん、SIでも運用に携わっておられる人からすれば、「お前、今更何を言ってるんだ」と言われてしまいそうですが、現実問題、運用にそれほど意識が向かなかったのだからこれは仕方がない。

運用の重要性を改めて今の会社に入って意識することで、自分の作ったシステムにより愛着が沸くようになりましたし、開発することがすごく楽しくなりました。
やはり、自分の作った製品が「使われている」という実感を得られるのは、作り手としてこのうえない喜びです。

■勉強会に対する姿勢の変化

勉強会に対する姿勢も変化しました。

それまで、勉強会はインプットする場でした。

参加して、なんとなく刺激を受けて、家でちょこちょこと手を動かして、それで満足。そんなちっぽけなインプットです。

時折、職場に導入したりもしましたし、周囲を巻き込もうと動いたこともありましたが、それでもそういったアウトプットよりも、インプットの方が圧倒的に多かったです。

今の会社に入り、幸運にもPlay FrameworkやScalaといった、注目を集めている技術に携わる機会を得ました。これをきっかけに、僕の勉強会への取り組みも、インプットからアウトプットに大きくシフトします。

勉強会でインプットして、職場にちょこっとアウトプットする、というスタイルから、職場でのインプットを勉強会でアウトプットし、またそこで得たフィードバックを職場に還元する、という循環になりました。

この循環は、今後も継続していきたいと考えています。

■ぶっちゃけ転職してどうよ？

この転職は正直なところ、不安でいっぱいでした。

もともといろんな勉強会で、弊社の同僚と以前から顔をあわせることも多く、「こんな人たちの中で自分は通用するのかな」と入社前はビクビクしていました。

入社直後はそれまで馴染みのないWebサービスの開発ということや、アジャイルなプロジェクト推進など、未経験のことばかりで、当初はチームメンバーに歯がゆい思いをさせてしまったこともあったかもしれません。

でも、結論から言うと、前向きに知識を吸収するマインドがあれば、まぁなんとかなります。

だって、僕らはエンジニアですから、新しい言語とか、新しいフレームワークとか、日々そういった事を身につけながらこれまでも仕事をしてきたじゃないですか。

入社して10ヶ月が経とうとしています。まだまだ自分に足りないスキルを思い知ることもありますが、これまでのSIでの経験を活かせる局面もわりとあったりして、まぁそれなりにチームの一員として楽しく仕事ができています。


と、いうわけで転職についての振り返りはこのくらいで。
年内にもうひとつ、コミュニティ活動についての振り返りと来年やりたいことのエントリを書いて、今年を締めくくろうと思います。

Scala関西ビギナーズに行ってきました

今年の夏ごろから『乙女ゲーを支える技術』という発表をあちこちでさせていただいていて、この発表の中で重点を置いているテーマに「Scalaは怖くないよ」というものがあります。

ぼく自信、業務でScalaを使っているわけですが、どうも「関数型言語」というワードで必要以上に敷居を高く感じてらっしゃる人が多いような印象を持っているからです。

そのような中、今日はScala関西ビギナーズという勉強会にお声かけいただき、サポートメンバーという立場でお手伝いさせていただきました。

主催の@aa7thさんから、当日はスピーカーの発表のあとに参加者にScalaでコードを書いてもらう時間を設けたいので、そのお題を提供してほしい、という依頼がありました。

そこで、Project Eulerをみんなで解いていこう、というお題にしました。

最初のProblem1だけ、15分のコーディング時間のあとに僕が解説をして、あとは自由に自分の解きたい問題を解いていく、という形式です。

サポート役という立場でしたので、今日はいつもの勉強会以上にいろんな人とお話することができました。

今回も、「この勉強会のおかげでScalaの敷居が下がりました」というフィードバックをいただき、目的を達成できたようでよかったです。

来年も引き続き、こういった勉強会に顔を出していくつもりですので、よろしくお願いします。

コミュ障でも大丈夫。サルでもわかる投票入門

選挙が近づいてきました。

若者は選挙に行くべき！　とTwitterなどでよく見かけますが、一方でいまさら投票に行こうと思ってもどうすればいいかわからない、という意見も聞きます。

そこで、20歳になって以降、投票権を持つ"選挙"と名がつくものはAKBのアレ以外すべて投票している、投票歴14年のわたしが、その手順などをお教えしましょう。


コミュ障な人でも全然大丈夫です。なぜなら、僕がそうだから！！



まず。自宅に投票用紙が送られているとおもいます。
とりあえずそれを持って、用紙に書かれている場所まで行きましょう。

だいたい地元の小学校とか、中学校だと思います。
普段なら、たとえ卒業生であっても我々の年代の人間が勝手に小中学校に入ったりしようものなら、問答無用で通報されるご時世ですが、この日ばかりは合法的に中に入れます。

中に入ったら、校庭などを見渡して懐かしい学生時代に思いを馳せるなどしても良いでしょう。


次に受付です。
投票のプロセスの中で、人と会話するのはこのタイミングのみです。
少し緊張する瞬間ですが、乗り切りましょう。

受付で用紙を渡すと、生年月日を聞かれます。
合コンなどと縁がない我々は、普段生年月日を聞かれることなど職質以外に無いですから、慌てそうになりますが、落ち着いて答えましょう。
これで最大の関門は突破です。


受付で投票用紙をもらえるので、それを持って、一蘭の味集中カウンターのようなボックスに行きます。そこにその選挙区の候補者の名前が書いた張り紙などがあるので、そういったものを参考に用紙に投票したい人の名前を書きましょう。

もうひとつ、政党名を書く欄もありますので、そこにも投票したい政党名を書きましょう。


あとは用紙を二つ折りにして、投票箱に入れます。
四つ折りとか複雑な折り方をすると、開票時に担当者がめんどくさいので、二つ折りで大丈夫です。
投票用紙は、箱の中で自動的に開く素材の紙で作られているので、二つ折りにしておけば開票時に紙を拡げる手間がないそうです。



これだけです。簡単ですよね。
それでは、よりよい国にするために頑張って選挙に行きましょう！

irof文が実装できたよ。そう、Scalaならね！

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

前日は、@megascus さんの「世界はいろふである #irof_history」でした。

さて、ITの某界隈ですっかり有名人になったirofさんですが、そろそろプログラム言語の構文として実装されてもいいのではないかと思うのです。だって、irofってifに似てるしね。

こんなイメージでしょうか。

  irof (hoge == 1) {
     println("いろふ")
  }

仕様はまぁ、面倒なのでif文と同じでいいでしょう。

if文が真であるときの制御があるなら、偽の場合の制御も必要です。if文が偽の場合はelseですから、ここはelofとしておきましょう。なんとなく変態っぽくて、そのまま変態アドベントカレンダーのネタにも使えそうですね。

イメージはこうなるでしょうか。

  irof(hoge == 1) {
    println("いろふ")
  } elof {
    println("おまえ、いろふじゃないな！？")
  }

プログラム言語っぽくなってきました。
さて、実装です。

irof文を、上記のイメージで完全再現するには、どうしましょうか。
Scalaなら、なんかやれそうな気がします。

さっそく実装してみましょう！！

Scalaは、def hoge (a: Boolean)(b: Int) のように引数リストを複数取れますから、この仕組みを使えばirof文のBooleanをとる引数と、blockをとる引数でそれっぽく実装できそうです。

ついでにirofをcase classにして２つの引数リストを取り、elofをそのメソッドとすれば、真の場合のブロックをコンストラクタで、偽の場合のブロックをelofメソッド内で実行するという形で、上記のirof文のイメージを完全再現できますね。

結果、下記のような実装になります。


できました！

これで、我々のよく知っているif文とまったく同じイメージで、irof文が使えます。

ただ、"irof"の実態はcase classであるため、これはirof文っぽく動くのですが、Scalaのifのような「irof式」ではありません。irof文の結果を引数に取ると、irofクラスのインスタンスを受け取ってしまいます。

このあたりが、どうにかならないかなー、と悔しいところではありますが、とりあえず、irof文は実装できたので、ヨシとしましょう。

さて、明日は@pocketberserker さんです。よろしくお願いします！

変態アドベントカレンダー2012【1日目】文字列の変態力を計ってみよう。

いよいよはじまりました、変態アドベントカレンダー 2012

トップバッターの@daiksyです！！

さて、初日ということでまずは小手調べ。

みなさんはある文字列が変態かどうか、気になることってありませんか？

Scalaなら、すごく簡単に調べることができます。

Scalaには、「暗黙の型変換」という機能があって、これを用いることで、既存の型を拡張することができます。とりあえずやってみましょう。


このhentaiConverterをextendしたクラス内で、文字列に対してisHentaiメソッドが使えるようになります。
例えば、"変態".isHentai はtrueを返します。

もう少し拡張してみます。
せっかくだから、文字列の変態力を調べられるようにしましょう。

Googleの検索で、「変態」に続いて文字列を指定した場合の結果件数を、変態力とみなしましょう。実装はこうです。

これで、hentaiConverterをextendしたクラス内でhentaiPowerメソッドを呼ぶことで、変態力を取ることができます。
ちなみに"だいくしー".hentaiPowerによる変態力は、10,700,000でした。

上記のコードですが、実は動きません。
Googleの検索は、ユーザエージェントが未指定だと403を返すからです。

実際にGoogleに対してスクレイピングを仕掛けると、たぶん規約に反すると思うので、それっぽいけど動かないコードにしてます。

Dispatchを使えば(ry)   絶対に動かしてはいけませんよ！

まぁ、動かないコードさらしてドヤ顔するあたりが、だいくしークオリティですな！！

さて、明日は@dproject21さんですね！
よろしくお願いします！

第2回 関数型言語勉強会を開催しました

第2回関数型言語勉強会を開催しました。

まずは、前回に引き続き会場を提供してくださったシナジーマーケティング株式会社さん、バリエーション豊かなお話で会場を盛り上げて下さった登壇者の皆さん、連休の中日にお集まりいただいた参加者の皆さん、準備段階から様々なご助力をいただいたスタッフの皆さん、本当にどうもありがとうございました。

さて、なにかと「コワイ」という噂の関数型言語ですが、わたしも開催直前まで謎のプレッシャーと戦っていましたw

実際には、今回の勉強会では「コワイ」要素などほとんどなく、楽しい勉強会だったわけですが。

「コワイ」と言われる要因はいくつかあると思っていて、その一つが関数型言語の奥深さにあるかと思います。

関数型言語を勉強すると、早い段階で「モナド」「カリー化」「圏論」などの耳慣れない言葉に出会います。

前回の第1回では、初心者向け（入門者向け）という名目での開催だったわけですが、この「初心者」という定義が実は曖昧で、そのために発表内容が多彩になりすぎ、関数型言語の奥深さが必要以上に強調されてしまったため、「コワイ」という評価になってしまったようです。

今回は、前回にいただいたそうしたフィードバックを反映して、具体的に関数型言語がどのように使われているのか、どのように使えばいいのか、「実用編」というテーマでの開催とさせていただきました。

もともとこの勉強会は、「関数型言語を勉強しているのだけど、もっといろんな人の話が聞きたい」というスタッフが集まって企画された会ですが、今回は我々のそういう願いが叶えられた素晴らしい勉強会になりました。

「コワイ」という印象があるせいか、発表者の皆さんが極力地雷を踏まないように気を使ってお話されている姿が微笑ましかったですが、マサカリも投げられてなんぼというか、それによって学ぶこともありますし、まぁ、あまり怖がらなくてもいいのかなーと思います。

少なくとも、僕自身が業務でScalaを使っていることもあり、「関数型言語」を実際の現場に広めたい、そのために、ハードルを下げたい、という目的は、今回は果たせたのではないかと思っています。

普段、僕もいろいろな勉強会を主催したり、参加したりしていますが、今回印象的だったのは他の勉強会に比べて研究職の方が多く参加してくださっていたことです。普段接点がないこうした人達のお話が聞けたのはいい経験になりましたし、関数型言語の位置づけがなんとなく見えた気がして面白かったです。

個人的なハイライトは以下の三点でした。

・@bleisさんの「関数型のパラダイムにシフトするための壁の話」

・@nakauさん「オープンソースプロジェクトはpull reqしなければどうということない」

・訳者の村主さんに『すごいHaskell』にサインをいただく

まだまだ需要がありそうな勉強会なので、来年も開催したいなーと思っています。

ソーシャルコーディングは楽しいねー。

毎週火曜日の定時後、弊社ではテーマ自由で当番の人がプレゼンをする社内勉強会が開催されています。

今日は@kuchitama さんがプログラミングコンテストをテーマにプレゼンしてました。

いろいろなプログラミングの腕試しの場を紹介してくださったのですが、個人的にその中のProject Eulerが面白そうだと思いました。日本語訳も充実していてとっつきやすいので、ちょっとずつ進めて自分のgistを充実させようと。

その中のproblem2 について、こんなコードを書きました。
ちなみに問題はこちら


なんか、力業感があるなー、と思いながらそれをTwitterでつぶやいて数分。
@xuwei_k さんがForkしてくださいました。



あー。そうかー。matchの"@"とか知識としては知ってたけど、それを使えるほど手に馴染んでなかったー、など面白い気づきがありました。

いやー、ソーシャルコーディングって楽しいですねー。

仕事でもペアプロなどをしていますが、他の人の意見を聞いて吸収していくというのは、本当に楽しいです。

DevLOVE関西2012 で発表しました

今日はDevLOVE関西で発表してきました。

Facebookなどでご縁があり、今回セッション枠をいただき、
『乙女ゲーを支える技術』という題でお話させていただきました。

今年の2月に今の会社に入って、乙女ゲーの新規開発から運用を、最初の段階から経験する機会に恵まれました。その際に、Play2.0やScalaといった、比較的新しい技術でプロダクトを作る、という幸運なチャンスをいただき、この経験を多くの人にシェアしたい、というのが今年の自分の大きなテーマの一つでもありました。

これまで、同じタイトルで、Playframeworkの勉強会とScalaの勉強会でそれぞれお話させていただき、今日のDevLOVEでその集大成的な位置づけで話をまとめて発表させていただきました。

みなさんからのフィードバックも概ね好評で、セッション後に質問に来て下さった方からも、自分たちの会社で新しい技術にチャレンジするにあたって参考にすると言っていただけて、ぼくの狙いがうまく伝わってよかったです。

懇親会では持ちネタのジョジョLTを飛び込みで披露し、安定の爆笑をいただきましたw

個人的には、ソニックガーデンの伊藤さんのセッションが、自分の転職経験と重なってすごく面白かったです。以前からブログなどを拝見していた方とお目にかかってご挨拶させてもらったり、幸せな一日でした。

みなさん、今日は本当にありがとうございました！

Dev love関西 forslideshare from Daisuke Kasuya

ITコミュニティ秋祭りを振り返る

以前から告知していた ITコミュニテイ祭りが無事終わりました。

平日にもかかわらずご来場くださった皆様、どうもありがとうございました。
そして、ステキなイベントの開催に尽力された中の人のみなさん、お疲れ様でした。

コミュニティの常連も、初心者の方も、みんなが楽しめるお祭りという事で開催されたこの企画。楽しんでいただけたようでなによりです。

ぼくは、パネルディスカッション第二部の「発表したらもっと世界が変わった」に登壇させていただきました。

思ったよりも緊張していて、落ち着く暇もなくあっという間に終わってしまったなー、というのが檀上からの感想です。

ただUSTを見なおしてみると、割りとちゃんとしたことを喋れていたので良かったかな、とも思います。個人的には若干消化不良気味ではありますが、これはひとえに己のコンテンツ力不足に起因するものなので、まだまだ精進せねば雅叙園には呼んでもらえないぞ、と決意を新たにしました。

今年は来月以降、関西Javaエンジニアの会とかDevLOVE関西とかLTではない長めのセッション機会をいただいているので、がんばっていこうと思います。

第二部はワールドカフェ形式で、第一部のパネラーと来場者の皆さんが語り合う、という企画。こちらはどちらかというと、パネラーメインではなく、来場者にいろんなお話をしていただく、という主旨でした。

ぼくもテーブルオーナーをさせていただき、「勉強会お花畑論」というテーブルを担当しました。

「勉強会お花畑論」とは、勉強会でいろんな刺激を受け、新しい知識や技術に触れ、意識が高まった状態で職場という現実に戻ってみると、そこにはうず高く積み重なったクソの山とか、レガシーコードとか、そういうものが存在していて、みんなどのようにそれと戦っていくべきなのか、というお話。

自分でもまだきちんとまとまっていないのですが、皆さんからいろんなお話を聞けて勉強になりました。
このお花畑論については、どこかできちっとまとめて、別枠で何か書こうと思っています。

しかし二回目ですが、このイベントはいいですね。
志を同じくする仲間と出会え、いろんな刺激を受け、人脈も拡がり、かつ楽しい。
特殊な技術とか知識とか、そういうものを超えて、マインドで繋がる仲間たち。
みなさんに出会えて本当に幸せです。

と、いうわけで、半年後くらいにもう一回やりたいなー。
あと雅叙園に行きたいなー。

P.S.
来場できなかったけど当日の雰囲気を味わいたい方。もう一度振り返りたい方、UST録画がありますのでこちらを御覧ください。



Video streaming by Ustream

10月5日。お台場のIT祭りのご紹介！

10月5日。お台場の東京カルチャーカルチャーさんでイベントをやります。

題して、「ITコミュニティ秋祭り・リターンズ！！」

・【お知らせ】今年もやります！ エンジニアのためのお祭り「ITコミュニティ秋祭り」【10月5日】 (via ＠IT自分戦略研究所)

・ ITコミュニティ秋祭り・リターンズ  (via ＠nifry TOKYO CULTURE CULTURE)

「リターンズ」の名前が示す通り、このイベントは去年に引き続き２回目になります。
DevLOVE, GLT, エンジニアライフ、というITコミュニティが合同で開催するお祭りです。

・DevLOVE
・GLT
・エンジニアライフ

ぼくも去年、エンジニアライフ代表として参加させていただきました。
去年の模様をお伝えしているblog記事をご覧いただくと、UST録画などもありますのでお祭りの雰囲気を感じとっていただけるかもしれません。

・去年の模様

去年は、勉強会初心者が勉強会について語ってみる、というスタンスでパネラーとして登壇しました。

あれから一年経ち、今年は「勉強会で発表したら世界が変わった」というスタンスでパネルディスカッションに登壇させていただきます。

実際、ぼく自身は勉強会に積極的に発表するようになった後で、転職をしたり、雑誌記事のレビューをさせてもらったり、それまでにない様々な経験をすることができました。その辺りのお話をいろいろさせてもらおうと思っています。

今年の真骨頂は、第一部のパネルディスカッションもさることながら、第二部の「お悩み相談室【野良バージョン】」にあります。

パネラーたちが、各テーブルで、お酒を飲みながら来場くださった皆さんと語り合うという企画。

勉強会での登壇者やソーシャル転職の成功者、個性豊かなパネラーたちに日頃の疑問や悩みをぶつけてみてください！

各パネラー紹介は、たのっちさんのブログが詳しいです。

・ITエンジニアの生き様を見よ！「ITコミュニティ秋祭り・リターンズ」の見どころを妄想紹介 全登壇者のスライド付

東京カルチャーカルチャーさんは、美味しいお酒やお食事を楽しみながら遊ぶ、という施設なので、多少の費用が必要になります。

チケットはeプラスで絶賛発売中。お食事券つきのペアチケットが大変オトクです。

・ITコミュニティ秋祭り・リターンズ (via eプラス)

みなさんとお会いできるのを楽しみにしています！！
ぜひ遊びに来てください！！！

iPhone5をゲットしたので、通信速度を比較してみた。

au版のiPhone5を手に入れました。

職場が京都なので、予約開始初日の14日に京都ヨドバシで予約。

仕事が終わった後の20時半頃に行ったのでほとんど並ばずに予約できました。

昨日まで東京ゲームショウに出張していたので、発売日ゲットはならず。

今日のお昼過ぎに受け取りに行きました。

受け取りもほとんど行列はできておらず、幸運な事にまったくお祭り的な混雑に合わずに早期ゲットを達成したわけです。

ひと通りの動作確認をしたところ、前回の4Sのときの初期不良のようなこともなく、無事に運用できそうです。

もちろんテザリング目当てで購入したので、今運用しているauのDATA08Wは解約しようと思っているのですが、せっかくなので通信速度の比較でもしてみましょうか。

■ DATA08Wの3G回線からのWiFi

WiMAXと3GのハイブリットのDATA08W。こちらの3G回線での速度です。

なるほど。まぁこんなものでしょうね。

■ DATA08WのWiMAX回線からのWiFi

続いてDATA08WのWiMAX。

意外な結果です。なんどかやり直したのですが、だいたいこんな結果から大きくブレませんでした。

自宅でのほほんと適当に測定してるだけですから、あらゆる不確定要素が絡むのでしょうが、下り速度は3Gより遅いですね。上りは速いですが。

ただ、普段使っている時の体感は3Gより圧倒的に速いので、別の場所で使ったらもっと速度は出るのかもしれません。

■ フレッツ光からのWiFi （プロバイダはOCN）

自宅のメイン回線です。当然有線だともっと速度は出ますが、とりあえず無線で。

圧倒的ですね。

PSNで映画やゲームをDLしたりするので、このくらい出てもらわないと困ります。

■ au LTE

さて。いよいよお待ちかねのLTEです。

速いです。普通にネットする分には光回線と体感での違いは無いです。

もちろん、映画とかDLしようと思うと差が出てくるのでしょうが、そんな事したら7GB制限に引っかかりますしねw

画面左上の「KDDI LTE」の文言がカッコいいですねー。

と、いうわけで通信品質に関しては今のところ満足しています。

あとは外での運用でどこまでストレス無く使えるかですねー。

安定の勉強会充を頑張ります

今年の活動予定

---

幸福なことに、今年もいろいろな勉強会やイベントに参加させてもらってる。

他にも同人誌への寄稿とか、雑誌記事のレビューとか、声をかけていただいてありがたい限りである。

ここで一つ、自分自身へのメモを兼ねて今年の活動をまとめておこうと思う。 すべてスピーカーとか、パネラーなどで登壇予定のものである。

---

■すでに終わったもの

• 2月25日 勉強会初心者のための勉強会
• 4月8日 Tech readers!! #3
• 4月28日 プログラマズナイト 第3夜
• 4月29日 鹿駆動勉強会 (hoge駆動)
• 5月12日オープンセミナー岡山(懇親会LT)
• 5月19日第1回関数型言語勉強会 主催するも参加できず…
• 7月14日 第3回 Playframework勉強会

---

■これからの予定

• 10月5日 ITコミュニティ秋祭りリターンズ
• 10月24日 関西Javaエンジニアの会
• 10月27日 やきに駆動2.0 (hoge駆動)
• 11月10日 DevLOVE関西
• 11月(詳細未定) 第2回関数型言語勉強会
• 12月15日 合同勉強会in大都会岡山 -2012 Winter-

みんながTwitterをはじめた日

夏休みもあと２日。

ワインを飲みながら、のほほんと土曜日の夜を過ごしていたら、@irofさんから謎のテロを受けた。

なぜだか知らないが、2年前のツイートがRTされている。
どうやらTwilogでいろんな人の過去ツイートを掘り起こして遊んでいるらしい。

仕返しにぼくもirofさんの過去ツイートをいくつかRTしてやった。

で、いろんな人のTwilogを見てたら、それぞれに個性があったり、今と考え方の違うツイートがあったりで面白かった。

せっかくなので、ほげ駆動な人々のツイッター開始日をまとめてみた。


@kiy0taka   2008/04/05
@tan_go238  2008/04/05
@irof       2008/06/01
@inaton   2009/02/21
@hakurai    2009/04/22
@kuchitama  2009/07/31
@bufferings 2009/08/26
@backpaper0 2009/09/11
@shumaro    2010/01/30
@s_kozake   2010/05/08
@daiksy     2010/05/23
@yukieen    2010/11/07
@NMura3     2011/01/19

なにか面白い傾向でも見られるかもしれないと思ったけど、別に何も見いだせなかったw

元SIerが休日にカレーを実装する - 要件定義 〜 詳細設計編

夏期休暇の前半が暇なので、カレーでも作るかと思い立った。
元SIerの経験を駆使して、質の高いカレーを作ろうとおもう。

まずは要件定義だ。

■要件定義 - 外部設計

今回の要件はこんな具合だ。

・カレーであること
・納期が短いため、それを考慮に入れること
・翌日のカレーうどんへの流用も考慮に入れた柔軟な設計であること

これらをシステム要件に落としこむとこうなるだろうか。

・カレーであること →
    カレーを最終成果物とする。

・納期が短いため、それを考慮に入れること　→
　スクラッチでの開発はせず、既存のライブラリを用いて組み上げる。

・翌日のカレーうどんへの流用も考慮に入れた柔軟な設計であること →
　4人前の分量を実装し、翌日への流用の余地を残す。

こんなところだろうか。外部設計書は別紙を参照のこと。※そんなものないけどね☆

■詳細設計

さて。詳細設計に移ろう。プログラムIDにKR0010001を採番する。

できあがった設計書はこれだ。

あとはこれを元に実装するだけ。
実装はオフショアに出して、あとは受け入れテストをするだけだ。

ちなみにここまでで0.2人日ほどの工数がかかった。

えっ？ こんなことしてる暇があったら早くカレー作れだって？
ははは。これだからWeb屋さんの理屈は。
ドキュメントが揃ってないのに実装なんてできるわけないでしょうがー。
それでどうやって品質を担保するんですかー。


さて。遊んでないでそろそろカレー作ろ。

素数のときにJoJo - scala -

定期的に話題になるFizzBuzz問題。
そんな中、こんなエントリを読んだ。

“素数のときだけ"JOJO!"って出力するプログラムを作ってみた
http://sue445.hatenablog.com/entry/2012/08/11/164950

Rubyスゲーなw
面白そうなのでScalaで書いてみた



もうちょっとエレガントに書けると思うので、他の人のも見てみたい。

夏フェスの友だちとの連絡手段はLINEがオススメ

ROCK IN JAPAN FES 2012に３日間すべて参加してきた。

会社の同僚と、有休をとって遊びにいったのであるが、フェスというのは基本自分でタイムテーブルを作って遊ぶもの。とくにロッキンのようにステージが複数あり、規模もデカイものだと自分好みのアーティストを渡り歩くので基本単独行動が多くなる。

とはいえ、ご飯を食べたり休憩するときなど、誰かと一緒に過ごしたい。
2,3人の参加なら、適宜電話やメールなどでやり取りをすればいいが、5, 6人となるとそうもいかない。

今回、ぼくらはLINEを使った。

LINEのグループ機能は、夏フェスのコミュニケーションには最適である。
基本、リアルタイムでメンバー全員に情報が通知される。

「次自分〇〇ステージに行くねー」とか、「今からご飯食べるけどいける人いるー？」と投稿すれば、タイミングの合うメンバーが反応を返してくれる。

通知機能は個別にオフにもできるので、3日間の期間中で1日のみ参加というようなメンバーも、参加期間以外は通知をオフにしておけばよい。

と、いうわけで、メンバーの連絡手段はLINEが有効だった。

ただ、難点もある。
フェス会場は人が多いので常に通信が安定しているわけではない。
「ご飯食べよう」メッセージを受信したら、すでにご飯は終わっていた、なんてこともあった。
どうしても緊急で連絡をとりたい場合は、電話に優るものはない。

あと、LINEで通知を飛ばしまくってると、バッテリーを消費する。
この3日間、フル充電のiPhone 4Sが午前中には20%くらいになっていた。
ぼくの場合はTwitterやFacebookに投稿しまくってたから、極端だと思うが、他の人もバッテリーには頭を悩ませていたので、モバイルブースターなどの携帯充電機器は必須だろう。

と、いうわけでこれから夏フェスに行くという人はご参考に。

scalaの変態的ライブラリ util-eval

Scalaのライブラリに util-evalというステキなものがあります。

Twitter社が提供するライブラリです。

実際に使い方を見てみましょう。

まず、build.sbtに以下を追記。

libraryDependencies += "com.twitter" % "util-eval" % "5.2.0" withSources()
resolvers += "T repo" at "http://maven.twttr.com/"

するとこういう事ができます。

val ret = (new com.twitter.util.Eval).apply[(Int => Int)]("{(x:Int) => x*2}")

ここで定義された"ret"を、"ret(2)"のように呼び出してやれば、{(x:Int) => x*2}が実行されてInt型の4という結果が帰ってきます。


なにが起きているのかというと、util-evalは、文字列として定義されている関数をコンパイルし、それを結果として返す、というライブラリなのです。


コード中に文字列で関数を定義してもたいして意味はありませんが、たとえば、configファイルとか、DBの項目に関数を定義できるという、実に変態的なライブラリであります。


当然、こういう事をするとせっかく静的型付けな言語を使っているのにもかかわらず、実行時エラーのリスクは高まりますし、都度コンパイルされるのでパフォーマンスは目に見えて劣化します。

乱用すると幸せになれないのですが、たとえば、ゲームのアイテムマスタにアイテムの効用を実装として突っ込むとか、消費税率の計算をconfigに式として記述するとか、そういうステキなことができます。

使いどころを見極めれば非常に強力なライブラリです。

今年の夏コミで薄い本デビューします

DevLOVE Pubの第三弾。『ライトニング・トークス 驚異のプレゼン さあ、プレゼンに目覚めよう』という薄い電子書籍に寄稿させていただきました。
http://www.devlove.org/devlove-pub/the_presentation_secrets_of_lightning_talks

少し振り返ってみると、ぼくのLT歴は2010年9月のエンジニアライフのオフ会以来、こんな感じになっています。

2010年09月 エンジニアライフオフ会
2010年12月 エンジニアライフオフ会
2011年06月 Twitter4jコードリーディング
2011年07月 OSC京都
2011年08月 playframework勉強会 （30分）
2011年08月 Javaらへん読書会
2011年08月 ITコミュニティ夏祭り （トークセッション & LT）
2011年09月 playframework勉強会
2011年11月 やきに駆動勉強会
2011年12月 忘年会駆動勉強会
2012年02月 鍋駆動勉強会
2012年02月 勉強会初心者のための勉強会 （30分）
2012年04月 TechReaders
2012年04月 プログラマズナイト
2012年04月 鹿駆動勉強会
2012年05月 オープンセミナー岡山懇親会
2012年06月 エンジニアライフオフ会
2012年07月 playframework勉強会（30分）
2012年07月 神戸らへんScala（30分）

合計で19回、LTやらセッションやらで発表を経験しているわけですが、こういった活動からライトニングトーカーとして認めていただけたのか、今回お声かけいただきました。

内容については、「LTをすると世界が変わるよ」というお話を少しセンシティブに書かせていただきました。タイトルは『人生を劇的に豊かにするいちばん簡単な方法』
ブログとか、コラムとかとは少し違った作風を意識して書いたので、読んでいただけると嬉しいです。

電子書籍ということで、表紙も何種類かパターンがあり、ぼくの表紙も作っていただきました。

by やまこ https://twitter.com/ywindish

コミックマーケット82 3日目 (2012/08/12 日曜日) 東地区“Ｕ”ブロック－04b DevLOVE Pubブースにて頒布を予定しています。

お立ち寄りの際は是非！！

自分のツイートが2,800RTされてるとき、ぼくのTLはこうなっていた

昨日、テレビを観ていて、何の気なしに感じたことをツイートしてみた。

報道ステーションで、反原発デモで「電気がなくても(ry」という論旨を紹介したあとで、九州の豪雨で避難してる人の「電気が来ないからなにもできない」というコメントを紹介していて、実にバランスのとれた素晴らしい報道だと思います（棒
— KASUYA, Daisukeさん (@daiksy) 7月 16, 2012

別に特段の思想があったわけでもなく、単にテレビ番組を揶揄するツイート。こんなものは今にはじまったことではない。

ただ、いつもと違うことが起きた。

ツイートした後、PCを閉じ、一時間ほど本を読んでいた。

再びPCを開くと、Growlがやたらと先ほどのツイートのRT通知をポップアップする。
FavStarを見てみると……。

まさかの600RT…。

えっ。

そこから、RT爆撃を受けることになる。

1時間に600RT。その勢いはさらに増してくる。
常に、誰かがRTをして、それが通知されてくる状況。

ぼくのデスクトップは終始こんな感じだった↓

止まらないGrowl通知。しばらくして、夜フクロウ（Twitterクライアント）がGrowlごと落ちた。

ここまでRTが拡散すると、公式RTだけでなく非公式RTまで大量に寄せられるようになる。まだ、なにがしかのコメントが入っていれば、意見として読もうかとも思うのだが、

とか

などというクソの役にも立たないツイートが面識のないアカウントから数十件押し寄せ、クライアントのMentionタブが使い物にならなくなる。

しかたなく、その日は諦めて寝ることにした。

翌朝、起きがけの頃はポツポツRT通知が来るものの、まぁ平穏。
ようやく落ち着いたか、と胸をなでおろす。

出社後、会社PCでSaezuriを起動。
世の中が稼働しはじめると、またもやRTが活発化しはじめる。

Saezuriは、TLにRTされたツイートも表示される。
会社PCのSaezuriは、夕方頃まで常にこんな状態。

どうやら、ついっぷるのトレンドに載ったらしい。

こうなってくると、不思議なことが起きる。
問題となっているツイートだけでなく、どこで掘り起こしたのか、ぼくの昔のツイートまでRTされる始末。

あげく、こんなものまで。

今日の22:45までにRTされた回数、腕立て伏せしまーす。 #daiksyTraining
— KASUYA, Daisukeさん (@daiksy) 1月 9, 2012

いや、これ、１月のツイートだし。 今更RTされてもやらねーよ！！！

あと、IT系を多くフォローしているぼくとしては、普段まったく絡まないクラスタの人からのマジレスなども寄せられる。
小沢一郎の支持者を名乗る人からのReplyは、華麗にスルーさせていただいた。
このツイートに政治的な意図は皆無なのでw

正直、ほぼ丸一日ぼくのTwitterはコミュニケーションツールとして機能しなくなった。
普段絡んでるフォロワーさんからのReplyは全部拾えないし。

と、いうわけで、

今現在のRT数は2,812。638Fav。
この２日で50人フォロワーが増えた。

なかなかワンダーな体験だった。

変態で学ぶ副作用

変態アドベントカレンダー in Summer(http://atnd.org/events/29918) 初日です。

今回は、変態を例にとって副作用について考えてみましょう。

一般的に副作用というと、お薬を連想しますね。

風邪薬を飲むと眠くなるとか、熱を抑える薬だけどその代わり少し吐き気がするかもしれないとか、そういうことです。

プログラミングにおいてもこの副作用というものは存在します。

wikipediaによると、「ある機能がコンピュータの(論理的な)状態を変化させ、それ以降で得られる結果に影響を与えることをいう」とあります。

副作用のあるメソッドは、その状態によって結果が変わるため、呼び出しには注意が必要なのです。例を見てみましょう。

まずは副作用のあるプログラムの場合。

Hentaiクラスがあります。この変態は、case classとなっており、クラスを生成するタイミングでSかMかの状態を列挙型で受け取ります。

slapメソッドを実行すると、この変態に対して平手打ちを実行するわけですが、ご覧のとおりクラスを生成する際に決定される状態により、結果が変わります。

val h = Hentai(SMKind.M) と宣言してから h.slap を実行すると、この変態は「もっと！！！」と変態じみた結果を返します。
一方、 val h = Hentai(SMKind.S)と宣言してからh.slapを実行すると、この変態は「てめぇ、なにするんだ！」とあろうことかマジギレしてしまいます。

このHentaiクラスの宣言部が、呼び出し部から離れたところで行われていた場合、この変態に平手打ちをかましたときに喜ばれるのか、キレられるのか、わかりません。

これでは怖くて、とてもじゃないですがこの変態に気軽に平手打ちなどできません。

では下記のコードではどうでしょうか。

このパターンでは、HentaiオブジェクトにそれぞれS用の平手打ち、M用の平手打ちが別々に定義されています。これらの結果は、状態に依存することはありません。

我々は気軽に、Hentai.slapToMと実行してこの変態を喜ばせてあげることができます。

これが副作用のないプログラムです。安心ですね。

と、いうことで明日は「真っ赤なレモン」さんですね。
よろしくお願いします。

第3回playframeworkで発表してきました

第3回 playframework勉強会に参加してきました。

ぼくは今のところ皆勤賞で参加させていただいています。

第1回の様子はこちら。
第2回の様子はこちら。

まず、会場のリクルートメディアテクノロジーラボさんのセミナールームが素晴らしかったです。
プロジェクタや、各島に置かれた液晶ディスプレイ、UST設備、WiFiなど、大変快適に過ごすことができました。どうもありがとうございます。

第2回のときも思ったのですが、主催の@ikeike443 さんの気配りが素晴らしく、進行などもたいへんスムーズですごく居心地のいい勉強会でした。
スタッフの皆さん、どうもありがとうございました。

勉強会については、@shinyaa31さんがtogetterにまとめてくださっています。
http://togetter.com/li/337676

USTの録画もあります。
http://www.ustream.tv/recorded/23977723

詳しい内容はこれらを見ていただくとして、簡単に感想を。

・@ikeike443さん「playアップデート」
play2.0についての概要のお話。中の人だけあって、play1.3やplay2.1についてのお話も聞くことができ、面白かったです。

・@i2keyさん「Play2.0+JavaでAPIサーバを開発しているiPhoneアプリの紹介 」
会場提供くださった、リクルートメディアテクノロジーラボの方。前日寝てないそうで、スピリチュアルな話なのだとかw
もともと「Excel方眼紙で自動生成してバーン」な世界からスピード感を求められるサービスの世界に来られたとのことで、親近感が湧きました。
紹介されていたアプリも素晴らしく、面白い発表でした。
印象に残った言葉「小規模開発は一人なのでクラスの責務とかどうでもいい」
素晴らしいですww

・@tototoshi さん「play2.0 + scalaについて」
play2.0 + scalaについて、デメリットを中心に紹介された発表。
あるあるネタ満載でステキでした。
勉強会というと結構「この技術すばらしい！スゲー！！」という観点の発表が多いので、こういう切り口はすごく勉強になります。よかったです。

・@kara_d さん「2.0Javaのオススメと、1.2からのアップグレード」
play1.xでの開発紹介。具体的なモジュールなど紹介していただきました。知らないことが多くて興味深かったです。
play2.0でGroovyTemplateが使える件は、ちょっと試してみようと思います。

・@daiksy 「乙女ゲーを支える技術」
ぼくの発表です。USTでは2:08:00頃からはじまります。

Play勉強会 第3回

View more presentations from Daisuke Kasuya

少しデモでとちってしまって、そこで軽くパニクって建てなおすのに苦労しましたw
少し練習不足だったようで、予定より10分も早く終わったので、たぶんネタをなにか一つ飛ばしてるとおもいますww

過去の勉強会は、単に勉強している立場としての参加でしたが、今回は実際にplayを使ってサービスインを一回やりとげた状態での参加でしたので、みなさんとお話させていただく情報の密度など、かつてないほど濃く感じました。

また関西でもplay勉強会を開催したいと思いますので、よかったらご参加ください。

また、今回発表した「乙女ゲーを支える技術」ですが、
「神戸らへんScala」という勉強会で、少しScalaよりに内容をアレンジして紹介させていただく予定なので、よかったらご参加ください。
http://atnd.org/events/30635

全体の感想としては、やはり翻訳に携われていたり、日本におけるplayの活動の中心となっている方が多く参加されていたので、たいへん内容の濃い勉強会でした。
かといって敷居が高いということもなく、リラックスして参加できる雰囲気なので、すばらしい勉強会だったと思います。

P.S.
勉強会後のビアバッシュで、いろんな人に「鹿駆動勉強会」ってなんだったんですか？と聞かれましたw

新しいMacBook Proがやってきた

発売日に注文していた新しいMacBook Proがようやく届いた！！

■ぼくが買ったスペック


・15インチ MacBook Pro Retinaモデル
・2.3GHz クアッドコアIntel Core i7
・メモリ 8GB
・フラッシュストレージ 256GB

■データ移行について


これまでMacBook Air(Late 2010)を使っていたが、それに比べるとまぁあたりまえだけど重い。ただ、Airを買う前に使っていたGatewayのラップトップと比べると圧倒的に軽いし、このあたりは買う前に充分検討したポイントなので問題なし。

Macからのデータ移行は初体験。Windows機のデータ移行は何度か経験しているから、あのノリで半日仕事だなと覚悟していたのだが、美容院に髪を切りに行っている間に勝手に終わってた。
具体的にはAirのデータをTime Capsuleに保存していたので、そこからの移行だったのだが、ダイアログに従って何度かクリックして放置してたら、Airの環境が何から何まで完璧に移行されててビビった。

あまりに完璧に移行されてるものだから、新しいMacに移行したという実感があまりわかないほど。

一点だけ問題があって、ぼくはターミナルでzsh使ってるのだけど、おそらくその影響で最初はターミナルが起動しなかった。
ここに書いてある通りに、zshにパスを通してやったらあとは問題なく動いている。
http://oshiete.goo.ne.jp/qa/5893430.html

■Retinaスゲー


新しいMBPの一番のポイントはなんといってもRetinaディスプレイだろう。
2880x1800の解像度は圧巻である。夜フクロウのツイートが遠くからでも読める！！

ただ、いくつかのアプリがRetina未対応で、フォントがもやっとしてる。ぼくが確認したのは以下のアプリ。

・Google Chrome (ただしCanaryだったら綺麗になってる不安定だけど)
・Google日本語入力の変換ダイアログ
・IntelliJ IDEA

あとはSafariやChrome Canary使ってても、Webサイトの画像とか、ニコニコ動画のフォントとか、ところどころもやる箇所はある。まぁそのうち綺麗になっていくでしょうな。
※追記：ニコニコ動画はZeroにしたら綺麗になった

iPhoneで撮った動画とか、普通に綺麗に見られるからビビる。
iPadより低い解像度のMacとかもう無理だわーって感じ。

■熱い


これはちょっと予想外だった。
ファンは凄く静かなのだが、本体が熱い。

手を置く場所はそれほど熱を帯びないので、机の上に置いて使うのはそれほど気にならないのだが、膝の上に置いてると膝が超絶熱い。。。


Airはこれほど熱くなることはなかったので、ラップトップコンピュータとしてはちょっとこれは減点要素かもしれない。まぁ15インチのコンピュータを膝に置くというのがそもそもどうかとも思うけど。


■オレたちの戦いはこれからだ！


あとは外に持ち運んだりしたときにどんな感じか気になるけれど、概ね新しいMacは気に入ってる。
なんか気になることとかこれから出てきたら、また都度まとめようと思う。

エンジニアライフのオフ会に行ってきたはなし

木曜日から会社の研修で東京に行ってきた。

研修後、そのまま滞在してエンジニアライフのオフ会に参加。
一昨年の9月にぼくがライトニングトークデビューを果たしたイベントで、今回で3回目の参加である。

旧知の人や新しい人など、いろいろな人とお話したが、やっぱりこのイベントが自分の原点かもなーと思う。


一昨年の7月に、エンジニアとしての自分のキャリアに漠然とした閉塞感を感じ、それを打開したいと思ってエンジニアライフのコラムニストになった。

その年の9月にイベントに参加し、いろんな人と出会った。その時に出会った人たちは、今でも付き合いの続く大切な友人だちだ。

その後、いろんな勉強会に参加して、いろんな人たちと出会ったけれど、やっぱりあの日エンジニアライフで出会った友人たちとの出会いが原点だなーと思う。

あれから2年弱ほど経って、自分も含めて多くの人が当時とは違う生活をしている。
会社が変わったり、住む場所が変わったり、結婚したり。

みんなの新しいチャレンジに刺激を受けて、ぼくも今はあのときと違う会社で仕事をしている。

一昨年の9月に、あのイベントに参加していなかったら、間違いなくぼくはこの場所にいないと思う。
Excel方眼紙と向きあう日々に嫌気がさしていたあの頃のぼくから2年弱経って、LTで「ソーシャルゲームの開発やってます」と自己紹介してる日がくるなんて想像もしてなかった。

なんだか不思議な縁だなぁと思う。おもしろい人生だなぁと思う。

これからもみんな、頑張っていこうぜ。

プログラム言語で詩を書くという試み.

ある本を読んでいて、エドウィン・モーガンという詩人と出会った。

グラスゴー大学で英文学を教えるかたわら、創作活動をした人物で、実験的な詩も多く残している。

その作品群の中に、"Message clear"という作品がある。
http://www.elgin.free-online.co.uk/misc/message.htm

1968年出版の詩集に含まれ、「コンピュータが文章を書いたらどうなるか」という当時流行した議論をテーマに書かれている。

この作品で人格を与えられたコンピュータが最終的に伝えたい言葉は、

"i am the resurrection and the life"

「ヨハネによる福音書」11章25節でつづられる「わたしは復活であり、命である」という言葉である。

この大変面白い詩にインスピレーションを受け、この詩をプログラム言語で表現してみたいと考えた。

しかし、プログラムは、モーガンの書いた「言葉にできずに迷う人格」を表現することはできない。なぜなら、プログラムは、コンピュータを決定論的に動作させるために用いられる言語だからである。

まぁ、それはそうなのだけれど、プログラム言語でその世界をなんとか表現しようと試みてみた。

"i am the resurrection and the life"という文字列のそれぞれの文字のインデックスに対して、どの文字を出力するか。その数列を、コンピュータの迷いの表現に見立てて書いてみた。

それがこれ。
https://gist.github.com/2900182

まぁ。なんとなくそれっぽくなったんじゃないだろうか。

大都会岡山にLTしにきた〜 オープンセミナー岡山@2012

勉強会界隈の情報をウォッチしていると、大都会岡山が熱いらしい。懇親会ではスタジアムみたいなところでLTやったり、なんか楽しそうな噂を耳にした。 で、岡山の勉強会に遊びに行きたいとTwitterでつぶやいたら、@razon さんが OSO2012というイベントを教えてくれた。 http://kokucheese.com/event/index/26302/

和田さんや小飼さんが来られるのか！　そしてその人たちにLT見てもらえるのか！！　これはもう行くしかないだろ！！　と、光の速さで懇親会LTと共に参加を申し込んだ。
岡山クラスタの方は何人か変態アドベントカレンダー に寄稿していただいたりもしたので、一度お会いしたかったし。

和田さんには今までお会いしたことは無かったのだけど、きのこ本を読んで自分も108番目のきのこを書きたい、と思い、ブログを書いたことがある。
http://daiksy.blogspot.jp/2010/12/108.html
このエントリは和田さんにも読んでいただいたらしく、そのご縁でTwitterでフォローしてもらったりしていたので、是非きのこ本にサインをいただきたいと思っていた。

そんなこんなで@irofさんと一緒に@Posauneさんの車に乗せていただき、岡山までやってきた！！

渋滞があって、少し遅れてしまったのだけど、受付で岡山クラスタの方たちとご挨拶。
「粕谷です。Twitterでお世話になってます＾＾」
「あー。変態アドベントカレンダー創始者だ！！」
「ええ、そうです ///」
「ぼく、Twitterで筆頭変態と呼ばれている者です（笑」
「おお！あの！！！」
という謎の自己紹介を繰り広げ、はやくもテンションが上がる。

会場は岡山県立大学。広い階段上の教室で、学生時代を思い出す。

発表はどれもすごく面白く、岡山のITエンジニアたちの熱さを感じた。
スタッフさんの運営も見事だし、どの発表もクオリティ高いし、すごくいい勉強会だと思う。

個人的にはKinectが面白かった。長らく使っていないWindowsを起動させるときが来たか。。。

休憩時間のサイン会で、和田さんと小飼さんに念願のサインをいただいた。
来て良かった。。。。。本当に。。。。

関西に住んでいて、和田さんと小飼さんの講演を一度に聴ける機会はめったにないので、すごく贅沢な時間を過ごすことができた。

本編終了後は、噂の懇親会である。
会場が元映画館を改造した居酒屋だそうで、スクリーンに向かって階段上に座席が並んでいる座・スタジアムという会場。

ぼくもそこでLTを披露した。わりとウケたけれど、司会の方から「少し笑い要素が少なめでしたね」という手痛い批評。もう一回リベンジしに来る！！！

懇親会では、エンジニアライフのコラムニスト仲間であるひでみさんの会社の社長さんがお越しになっていて、挨拶してくださった。業界狭いなー。

それにしても、初の岡山勉強会はめちゃくちゃ楽しかった。
熱くて、ユーモラスで、楽しくて、すごく雰囲気の良いコミュニティで、全然アウェイな感じが無いステキな勉強会だった。

また遊びに来るお！

メソッドチェーンなクラスをScalaで書いたらこうなった。

Play2.0でATNDをゴニョゴニョするアプリを作ろうと思い、コードを書いていた。

まず手始めに、ATND APIを叩くためのクラスを作っていたのだが、いかんせんパラメータが多い。

検索の関数が大量の引数を受け取るというのはあまりにも不細工だ。

そこでふと、Effective Javaの第2章 項目2 を思い出した。

メソッドチェーンな感じでパラメータを受け取ればいいんだなと。

で、書いてみた。

https://gist.github.com/2584254

なるほど。できた。

しかし、ミュータブルな変数多すぎ。。。。

Twitterでいろいろ悩んでいると、こんなアドバイスが。

@daiksy @dproject21 割り込みですいませんが、Type Safe Builder Pattern blog.rafaelferreira.net/2008/07/type-s… とか(の応用でも)使えたりしないですかね？

— Kota Mizushimaさん (@kmizu) 5月 3, 2012

なるほど。
http://blog.rafaelferreira.net/2008/07/type-safe-builder-pattern-in-scala.html
を参考に書きなおしてみる。

https://gist.github.com/2585850

パラメータをセットする関数が、必要なパラメータのみを書き換えた自身のクラスの新しいインスタンスを返すので、ミュータブルな変数がいらないということか。
うーん。でも、なんか微妙。。。

.@daiksy 参照先のURLはたしかScala2.8以前で、まだcase classのcopyがなかったからだと思いますけど、今だったらだったらcopyメソッド使ったほうが短く書ける気が

— Kenji Yoshidaさん (@xuwei_k) 5月 3, 2012

なるほど！ case classのcopyメソッドか！ で。書きなおしてみる。

https://gist.github.com/2586213

ちょびっとスッキリした。

鹿駆動勉強会とはなんだったのか

プログラマーズナイトからその流れで鹿駆動勉強会というハードな二日間が終了しました。
blogを書くまでが勉強会なので、まとめておこうと思います。

■プログラマーズナイト #3


http://atnd.org/events/27094

プログラマーが集まって、DJとかLTとか夜通し騒ぐ、というイベント。
なんかもう、とにかくやばかったです。

ぼくもテキーラ・レッドブル飲みながらJoJo LTしてきました。
http://www.slideshare.net/daiksy/jojo-8930790
あのネタをやるのはこれで3回目なのですが、今回も好評で、完全にぼくの持ちネタです。

初演を見て下さった人から、コピペ開発はよくないよという主旨にもかかわらず、スライドをコピペしてるじゃねーか、という辛辣なツッコミをいただきましたw

■そして鹿駆動


同僚の家で仮眠をとらせてもらい、奈良へ鹿駆動勉強会に参加しに行きました。
こちらはスタッフとしての参加です。
ATND： http://atnd.org/events/24587
告知記事： http://el.jibun.atmarkit.co.jp/topics/2012/04/post-8fd1.html

当初は完全に勢いだけのスタートでした。

参考「Togetter：奈良で勉強会しようず」http://togetter.com/li/244813

ただ、同じ方向を向いてる仲間が何人かいて、みんなが本気を出せばこんな勢いだけの企画も成立してしまうんですね。

結果100人を超える参加希望者と、20人のスピーカーと、奈良の能楽ホールというあり得ない勉強会が実現してしまいました。

ぼくたちはITのプロとして仕事をしています。数人から数十人のチームを組んで、要望を具体化し、手順を経てコンピュータソフトウェアという成果物を作り出します。

今回の鹿駆動では、当初の思いつきから実現にいたるまで、いろいろなことがありました。
当初は思いつきで、10人くらいで奈良で勉強会をしたいといういつもの仲間うちの勉強会のノリでした。
そこへ、能楽ホールというエッセンスが加わり、能楽ホールでなら発表してみたいというスピーカーが集まり、次第に形を変えて規模も大きくなりました。
時間が経つごとに状況が変わり、ぼくたちスタッフも何度か打ち合わせをして、その変化する状況に対応しながらコツコツと実現へのステップを組み立てて行きました。

これらのプロセスは、ITのプロとしての経験があってこそやり切れたという側面はあると思います。

そして何より感謝したいのは、IT勉強会はほんとうにすべての参加者の善意で成り立っているということです。

スピーカー、参加者、スタッフ。彼ら全員が「面白そうだからやってみよう」「楽しそうだから行ってみよう」というモチベーションで少しずつの善意を持ち寄って、ここまで大きな企画が実現したのです。

企業スポンサーがついたわけでもない、個人の善意の集まりだけで、鹿駆動勉強会みたいな企画が実現できてしまうITという業界をぼくは誇りに思います。

懇親会もすごく盛り上がったし、すごい勉強会でした。
みなさん、本当にありがとうございました。

「Togetter：鹿駆動勉強会」http://togetter.com/li/295148

ニコニコ超会議の裏でTitterトレンドに#shikadrivenが上がるとかありえないだろJK

■もうひとつの奇跡


今回の鹿駆動勉強会は、遠方からお越しの方がたくさんおられました。
その中のお一人から、とてもステキなフィードバックをもらいました。

去年、東京カルチャーカルチャーでITコミュニティ夏祭りというイベントを開催しました。
http://daiksy.blogspot.jp/2011/09/it.html

このイベントをきっかけに勉強会に参加するようになり、その流れで鹿駆動に遊びに来た、という人がいらしたのです。

小さなことですが、自分たちの活動が他の人になにかしらの影響与えているのだなー、と幸せな気持ちになれた出来事でした。

【Scala】コンストラクタ実装したtraitをobjectにmixinしたらなるほど、こうなるよな、という話

あるリクエストを受け取ったときに、ユーザに関連する情報を一括で削除したい、という要件があった。

対象のテーブルがたくさんあったので、いちいちhoge.deleteみたいな記述を羅列するのは避けたい。削除対象テーブルは今後の開発で余裕で増えるだろうし。

で、こんなコードを書いてみた。

    object CleanerContainer {
        import scala.collection.mutable.ListBuffer
        private val list: ListBuffer[Cleaner] = new ListBuffer[Cleaner]

        def append(cleaner: Cleaner) = this.list.append(cleaner) 

        def execute(userId: String): Unit = list.foreach(_.clean(userId))
    }

    /**
    * コンストラクタで自分自身をCleanerContainer に追加するので、
    * これをmixinするだけでCleanerContainer.executeの処理対象になるはず。
    */
    trait Cleaner {
        CleanerContainer.append(this)

        def clean(userId: String): Unit
     }

     /** DBのCRUDを実装したmodelのコンパニオンオブジェクトと仮定  */
     object hogeModel extends Cleaner {
         override def clean(userId: String) = {
             hoge.delete(userId)
         }
         // (以下の実装は省略)
     }

CleanContainerは、一括削除の対象となるmodelをListで保有し、executeでそれらのcleanメソッドをまとめて実行する。

CRUDを実装しているmodelのコンパニオンオブジェクトが、Cleanerというtraitをmixinすることで、Cleanerのコンストラクタで自分自身をCleanContainerに追加しているから、hogeModelのようにclean関数に自信の対象レコードを削除する処理を記述すれば、CleanContainer.executeを任意のタイミングで実行することで、対象のデータを一括で削除できるはず！！！

で、意気揚々と実行してみたが、全然データが消えない。

…あ！ objectにmixinしたtraitのコンストラクタ実装って、objectが最初に呼ばれたタイミングでないと実行されないじゃん！！ シングルトンオブジェクトなんだからそりゃそうじゃん！！！

てっきりobjectってアプリケーションが起動したタイミングでオブジェクトが生成されるものだと勘違いしていたという、失敗談でした……。

play2.0でtwitter4jを使ってdaiksyプラグインを作ってみた.

play2.0でプラグインを作って遊ぼうと思いたち、とりあえず自分のユーザタイムラインを取得する誰得プラグインを作ってみた。

twitter4jを使ったのだが、もっといろいろ詰まると思ったらすごく簡単にできたので、とりあえずまとめておく。

play2.0でプロジェクトを作る。

https://github.com/playframework/Play20/wiki/Anatomy によるとアンマネージなjarとかはlibに置くんだよ、と書いてあったので、libディレクトリを作ってtwitter4j-coreをそこに置く。

コンソールでeclipsifyしたら、参照ライブラリに追加された！

あとはhttp://twitter4j.org/ja/index.html とか https://github.com/playframework/Play20/wiki/Scalaplugin とか見ながら作るだけ！！

ちなみに今回書いたコードはこちら。

https://github.com/daiksy/daiksyPlugin/blob/master/daiksyPlugin.scala

さて。何して遊ぼうかなー。

ぼくがいかにしてコミュニティ活動をはじめたかについて

最近、いろいろな人とお会いする機会があるのだが、必ず聞かれることがある。

いつ頃から、勉強会とか、社外活動を始められたんですか？

きっかけはなんだったんですか？

自分自身の振り返りの意味も込めて、一度それについてきちんと書いてみよう。

最近、SIerがあらゆるところでdisられているが、おおむねそこで論じられているような理由から、当時のぼくも仕事に対して閉塞感を抱いていた。

ITエンジニアという仕事に対する考え方について、それをライフワークとする人と、完全にお仕事と割りきっている人と、おおまかに分けて考えた場合、当時のぼくはどちらかと言えば後者に近いマインドだったと思う。その時に勤めている会社は3社目だったが、わりと真剣にその会社で定年を迎えるだろうと漠然と考えていたし、出世的な部分も意識して、「いわゆるサラリーマン」的なマインドで仕事をしていた。

しかし会社の業績は他のSIerと同様芳しくないし、手当やらなんやらは削減されるし、お昼休みにはオフィスの照明を切るべし、みたいな、エコを建前とした経費削減のお達しが出るしで、いかんともしがたい閉塞感に苛まれていた。

当時所属していた部署は、割りと自由な風土だったこともあり、なにかこの閉塞感を打破しようといろいろと行動に移すことにした。

部門の風土もあって、そういった試みに何人か賛同してくれる人もいて、いろいろなチャレンジをした。

具体的にどういう事をすれば、閉塞感を打ち破れるのかは分からなかったけれど、とりあえず前向きになれそうな、楽しそうな事は思い付く限りなんでもやってみようと思った。

Redmineのような新しいツールを導入してみたり、社内SNSを立ち上げてコミュニケーションの活性化をはかってみたり、新規事業の企画書を書いて会社に提出したり。

Twitterを始めたのも、ちょうどこの頃だった。相変わらず閉塞感はあったけれど、それなりに仕事は楽しかった。

ただ、そういった社内での活動と並行して、そろそろ会社に依存しない生き方を模索するべきだとも考えていた。将来のキャリアを想像した場合、当時の会社内で出世をしたり、定年まで働く、というルートに対して現実感を持てなくなっていたからだ。

サラリーマンというマインドではなく、エンジニアというライフワークを満喫するような、そういう生き方をしよう。そう思った。

しかし、どうすればそういう生き方ができるか分からない。とりあえず、会社という閉ざされた世界に篭るのではなく、外に出てみよう。そう思ってエンジニアライフのコラムニスト募集に申し込んだり、勉強会に行くようになった。

初めてのコミュニティデビューは2010年の9月。エンジニアライフのオフ会だった。

そこではじめてLTをした。

いろいろなフィードバックをもらえたし、友人も増えた。これ以上ないほど明確に、自分の世界観が変わった瞬間を実感した。

とりあえず、LTというものが楽しかったから、そういう機会を探して積極的に活動をはじめた。LTという文化は、手を挙げさえすれば、資格も何もなくてもやらせてもらえる素晴らしい文化である。そういう文化のおかげで、いろいろなところに出ていくことができた。

ぼくは、別にずば抜けた才能やスキルを持っているわけではないが、継続して活動を続けていると、いろいろな人に顔や名前を覚えてもらえるようになる。そうするといろいろな会に呼んでもらえたり、人を紹介してもらったりするようになる。こうして世界がどんどん拡がっていった。

2011年の4月に、部門異動があった。

それまで、社内でいろいろなチャレンジをしていた仲間と、違う部門の配属になった。

その部門は、どちらかといえば規律を重んじるリーダの率いる部門だった。

Twitterの発言がモラルに欠ける、と会議室に呼び出されて怒られたり、そういったことを考課に反映してぼくの評価を下げる、というな議論が起こったりした。

社外活動の前向きな部分はちっとも評価されないのに、そういうマイナスのフィードバックばかりがやけに具体的に寄せられる。

正直、その息苦しさに耐えきれなくなり、転職を決意した。

転職を目的として社外活動をしていたわけではないが、結果的に社外活動の成果は転職活動にとってプラスに作用した。

会社に依存せずに生きていく、という当初思っていた方向性は、その意味で間違っていなかったといえるかもしれない。

いろいろな活動をしていて思ったのは、人生にとって最も重要なのは、人間関係なのかもしれない。いろいろな人との出会いが、自分の世界を拡げてくれたし、生活を豊かにしてくれている。

ぼくにとっての社外活動とは、そういう人間関係を多方面で構築すること、というのが今の認識である。

はじめてたかだか1年半ほどだけれど、たくさんの友人と巡り会えたし、人生は間違いなくより豊かになったと思う。

何かをはじめるのに遅すぎるということは無いので、社外活動に対して興味はあるけど踏み出せない、という人は、恐れずに踏み出すべきだと思う。

勉強会って怖くないよってお話をしてきた #study4bg

エンジニアライフのコラムニスト仲間であるあずKさんが主催されている勉強会、「勉強会初心者のための勉強会 #study4bg」にゲストスピーカーとして呼ばれたので行ってきた。

ATND
http://atnd.org/events/25214
公式サイト
https://sites.google.com/site/study4bg/home

会場はエンジニアライフでお世話になっているアイティメディアさんの会議室。
ここは2010年の9月に、エンジニアライフのオフ会でぼくがオフ会デビューをした思い出の場所である。その後の勉強会などの社外活動にのめり込むきっかけとなった会だったので、そういう場所で1年半後に、今度はぼくが勉強会初心者の皆さんに向けてお話をするということで、少し感慨深かった。

勉強会ではこういうお話をさせてもらった。

勉強会初心者向け勉強会 Study4bg

View more presentations from Daisuke Kasuya

Ustはこちら

Togetterまとめ
http://togetter.com/li/263403

ゆかりんのーとのまとめ
https://yukar.in/note/ckFoD9

参加者の方のブログ or コラム
・するめご飯日記
http://show-surumegohan.blogspot.com/2012/02/blog-post_25.html
・ノート
http://mocha-cocoa.blogspot.com/2012/02/study4bg-2012.html
・zakiharaの日記
http://d.hatena.ne.jp/zakihaya/20120226/1330229570
・わはー↑
http://ermellino.org/design/2012/02/study4bg/
・It's Party Time!
http://el.jibun.atmarkit.co.jp/azk/2012/02/--2012---8414.html

30分のセッションということで難しかったが、皆さん真剣にお話を聴いてくださった。
笑いもそこそことれたし。

セッション後はみんなでLTの練習ということで、2分で自己紹介をするというワークショップを実施。
LTのお手本ということで、ゆうこりんLTを披露してきた。

今回、本当に勉強会が初参加、という方が何人もいらして、懇親会などで「来てよかったです！」と言っていただけたり、本当にやってよかったと思う。

懇親会でも話題になったが、最近はITだけでなく、法務の世界でLTの文化がはじまったりと勉強会文化の裾野が拡がっているようである。

ぼくも「自称勉強会エバンジェリスト」的な感じでそういう流れに関わっていけたらな、と思う。

今回の機会を与えてくださったすべてのみなさんに感謝。どうもありがとうございました。

Play 2.0-RC2 のSpecs2によるテストで、InMemoryDatabaseを参照する方法について

Play2.0での開発において、DBはサーバ上のOracleやMySQLなどに接続しているけれど、Modelのテストなどはサーバのデータに影響を与えたくないのでIn Memory Databaseに接続したい、という要望があるかと思います。

今日、それについて少し調べていたので、メモがてらまとめます。

Play2.0でテストを実装する場合、標準でSpecs2を使うかと思いますが、その場合にIn Memory Databaseに接続する際は、下記の記述をします。

import org.specs2.mutable._

class TestSample extends Specification {
      "connect InMemoryDatabase" in {
          running(FakeApplication(additionalConfiguration = inMemoryDatabase())) {
               1 must beEqualTo(1)
         }
      }
}

ここでのポイントは

additionalConfiguration = inMemoryDatabase()

です。

additionalConfigurationは、application.configから読み取った値を上書きしたり追記したりします。

ここで、Play2.0のinMemoryDatabaseの実装を見てみましょう。

 def inMemoryDatabase(name: String = "default"): Map[String, String] = {
     Map(
         ("db." + name + ".driver") -> "org.h2.Driver",
         ("db." + name + ".url") -> 
             ("jdbc:h2:mem:play-test-" + scala.util.Random.nextInt)
     )
 }

このように引数なしでinMemoryDatabaseを呼ぶことで、additionalConfigurationに対して"db.default.driver"と"db.default.url"の値をMapとして渡す形になり、テスト時のDBの参照先がIn Memory Databaseになるというわけです。

みんなで鍋食べて、ついでにLTとかしてきた。

今日は鍋食べてきました！　
http://atnd.org/events/24580

で、なんかみんなお店の予約時間の5時間も前に集まったもんだから、
焼肉とか忘年会とかの例によってついでに発表とかしてきました。

TDDのお話とか、開発のマネージメントについてのお話とか、Seleniumのお話とか、強いられてる話とか、QuickJunitとか、Spockとか、どれも楽しい話ばかりでした。

まとめ：
http://togetter.com/li/260584

ぼくも発表してきました。

鍋駆動

View more presentations from Daisuke Kasuya

いやー。楽しかったー。

ランニング初心者が2ヶ月ちょっとで10kmマラソンを完走したはなし

今日、神戸で開催された「神戸バレンタインラブラン」というマラソン大会の10kmコースを完走しました。

大阪マラソン、神戸マラソンのクォーターにエントリーしたものの落選し、せっかくなので一回くらい走りたいと思いエントリしたのが去年のこと。

それまで、まったく走っていなかったわけですが、2ヶ月ちょっとのトレーニングで、わりと余裕をもって10kmを完走できるくらいになりました。

最初は3km走っただけでゼエゼエいうし、足は死ぬほど痛いし、10kmなんて途方もないように感じていたのですが、継続というのは偉大なもので、たぶんペースさえ守れば今なら10km以上の距離も走れるような気がします。

下記の図が、ぼくが決意してから、今日の本番を含めた全ランニングの記録です。

回数にして22回、総距離は約130kmです。

だいたい週に1-2回のペースで、途中少しサボりながらも徐々に走る距離を増やしていき、10kmに到達した感じです。

当然人によって個人差はあるでしょうが、10kmくらいなら健康な人ならこのくらいのトレーニングで走れるようになると思います。たぶんですけど、その気になれば20kmいけるんじゃないでしょうか（笑

マラソンは、全力で走ったり、瞬発力を競うスポーツではなく、いかに自分のペースを一定に、長時間保つか、というスポーツです。

継続によって自分の能力が上がり、かつそれを持続するという観点で、肉体的な部分だけでなく、精神的な面でも得るものは大きいです。
途方もない目標でも、続けていればやれるようになる、という実感を得られた事実は、ぼくの自己啓発に対する考え方にも良い影響を与えてくれました。

最終的にはハーフマラソンを一回走って、あとは仮装して10km走る感じの大会のにぎやかしランナーあたりに転身しようかと考えています。

SIerからWeb系へ転職するためにぼくがしたことのすべて

2012年1月末をもって、今の会社を退職することになりました。

2006年に、それまで勤めていた会社の倒産をきっかけに入社し、5年半ほどお世話になりました。
ぼくの社会人キャリアの中ではいまのところ最も長く在籍した会社であり、エンジニアとして大切な多くの事を学ばせていただきました。

在職中にお世話になった皆様方、本当にいろいろとありがとうございました。そして今後ともよろしくお願いします。

今回のエントリーでは、ぼくが転職をするにあたって具体的にどういうことをし、そして成功したのか。そういったことを書こうと思います。

■SIerからWeb系へ

ぼくは今回、いわゆるSIerからいわゆるWeb系へ転職することになりました。厳密にいうと少し違う部分もあるので、「いわゆる」と表現しています。ただ、きのこる先生の記事でSIerとWebの定義を行なっている図でいうと、「左上」から「右下」の系統への転身となるので、おおざっぱな意味で「SIerからWeb」と言って差し支えないでしょう。

ぼくの転職活動も、この図にのっとった形での会社を志望し、活動を続けました。

■書類選考の通過ゼロ時代

昨年の夏ごろから、なんとなく転職活動をスタートさせました。
転職サイトに登録し、情報収集して気になった企業に職務経歴書を送ったりしていました。

このころから、いわゆるWeb系をターゲットにしていましたが、書類選考がまったく通りません。なんらかのアドバイスをもらおうと、転職エージェントに相談することにしました。

最初に面談を受けたエージェントには、「あなたではWeb系への転職はできません」とはっきりと言われました。ぼくの職務経歴書では、SIerに対してはリーチできるけれど、Web系での書類選考は通らない、というのです。

そのエージェントからは結局ぼくの要望に反して、SIerの求人ばかり紹介されました。
紹介していただいた求人は大手ばかりだったので、SIを志望するならそれはそれでよい転職ができていたかもしれません。しかしそれはぼくの希望ではありませんでした。

その後、エージェントを介さずに企業に直接書類を送ったりもしましたが、やはり面接までこぎつけた会社はゼロでした。

■ブログやコラムのURLを書いてみることに


あるとき、某大手検索サイトが関西に開発拠点を設けるため、大量のエンジニアを採用しようとしている、という求人を目にしました。

これほどの大量採用なら、チャンスがあるかもしれないと思い、エントリーをしてみたのですが、これまでと同じではどうせ書類選考に通るわけはないので、少し工夫をすることにしました。

よく、「Web系に行きたければコード書いてgithubにUpして、そのURLを会社に見せろ」というようなアドバイスを目にします。ぼくもそのアドバイスにしたがって、このブログや、エンジニアライフのコラムなどのURL、勉強会での登壇歴などを、職務経歴書の最後に自己PRとして記載してみたのです。

結局、そのエントリーも書類選考は通りませんでしたが、その会社の求人を担当しているというエージェントから「会いたい」と連絡を貰いました。

このエージェントからのアドバイスが、ぼくの転職に大きな転機を与えてくれました。

■書類選考通過率100%

エージェントからのアドバイスは次のようなものでした。

あなたの会社業務についての職務経歴でははっきりいってWeb系にリーチできない。しかし、自己PRに書いてあるような社外活動は大きなアピールポイントになる。
なので、最後にちょこっと書くのではなく、職務経歴書の先頭に、目立つように書きましょう。

このアドバイスにしたがって職務経歴書を書きなおし、紹介された求人にエントリーしてみました。

結果的に、その後2社に対してエントリーしたのですが、2社とも書類選考は通過しました。2社目で入社が決まったのでサンプル数は少ないですが、職務経歴書改良後の書類通過率は100%です。

勉強会や、コミュニティ活動に対するマインドが評価されたのでしょうか。

■ソーシャル転職


最近、ソーシャル転職という言葉をよく聞きます。
TwitterやFacebook、LinkedInなどのソーシャルメディアを利用して転職を行う、というもの。

ぼくも、こういったソーシャルな繋がりの人から、「弊社に来ませんか」と声をかけていただいたことが何度かあります。結局いろいろな理由があってソーシャル経由での転職には至りませんでしたが…。

しかし、今回の転職でも、こういうソーシャルな繋がりによって助けられた部分があります。

勉強会などをきっかけにTwitterなどで交流のある方や、エンジニアライフのコラムニスト仲間がたまたま転職先に勤めているという事が、エントリー後にわかりました。

そのおかげで、求人票にはあらわれない現場のお話や、そこで働く方のマインドなど、多くの情報を得ることができ、「この会社で働きたい」という気持ちを固める非常に強いきっかけとなったのです。

ぼくは今回の転職は会社に在籍しながらの活動だったので、いろいろな会社からお話を聞き、本当に納得できたところに入ろう、と考えていました。
その「納得」に至る部分において、SNSや勉強会でのつながりが大きな役割をはたしてくれました。

■不安もたくさんあるけど頑張る


長くなりましたが、以上がぼくの転職活動のすべてです。
同様の道をたどろうと悩んでいる方に、少しでもお役にたてれば幸いです。

SIerからWeb系という、すこし異なる世界への転身ですから、不安はたくさんあります。
ただ、こうして強い縁で巡り会えた会社ですから、貢献できるように精一杯がんばろうと思います。

2月から新しい職場での仕事となりますが、今後ともよろしくお願いします。

最後に、お約束のウィッシュリストを…｜д゜）チラッ
http://www.amazon.co.jp/registry/wishlist/1BG8FLXXG4PWB

三谷幸喜の「90ミニッツ」を観てきたのでレビューっぽいことを書いてみる

部屋には二人の男。
彼らは人生を、そして
生き方を懸けた戦いに臨もうしている。
許された時間は、90分間 

    --公演パンフレットより--

シアター・ドラマシティで三谷幸喜作の舞台、『90ミニッツ』を観た。

三谷幸喜といえば喜劇の印象が強いが、今作は「倫理」をテーマとしていることもあって笑いは抑えめ。 90分間、暗転が一度もない、西村雅彦と近藤芳正の二人だけの会話劇である。

この二人の会話劇といえば、おなじく三谷幸喜作の『笑の大学』が素晴らしかったが、今作もたいへん素晴らしい作品だった。


ネタバレの無い程度にまずは簡単にあらすじを紹介しよう。
西村雅彦演じる医者のもとに、近藤芳正演じる「少年の父親」が訪ねてくる。
ある少年が交通事故にあい、手術を必要としているのだ。

医者はすべての準備を整え、あとは父親が承諾書にサインをするだけ。
ところが、父親はサインを拒否する。

手術には当然輸血が必要であり、少年は自らが生活する地域の古くからの慣習によって、輸血を禁じられているのだ。

少年の命が救えるリミットまで、90分。

人の命を救うという立場の医者と、自分たちの信念を貫こうとする父親との答えの見えない論理のぶつかり合いが展開されていく。

舞台上はいたってシンプル。白を貴重としたセットに、椅子が二脚置かれている。
舞台中央には天井から一筋の水が絶え間なく流れている。
会話劇の途中、二人が無言で見つめ合う場面などで、この水の流れる音が緊張感を演出する。また、この水の流れは少しずつ削られていく少年の命を暗喩している。
劇中、音楽や暗転は一度もなし。場面によってごくわずかに照明の強弱がつけられる。

『笑の大学』や『12人の優しい日本人』などをイメージすると、今回は少し物足りないかもしれない。かなり実験的な作品であったように思う。

ただ、映画へと仕事の軸足を移し、大河ドラマ以来、「人間」を描くことに重きを置いている三谷幸喜という作家の、ひとつの着地点であるように思った。

脚本にも彼特有の終演時の爽快感はなく、深く、沈み込むように物語が終わる。

賛否のある作品だと思うが、僕は面白かった。

数メートル四方に世界を切り取った「舞台」という箱庭で繰り広げられる二人のやりとりは、やはりライブでしか味わえない趣に満ちていたし、生の役者の演技から揺さぶられる感動も味わえたし。

二日酔いで皇居ランをしてみるなど

ふと、思い立ってこの土日は東京に遊びに行っていた。

せっかく行くので、皇居ランでもしてみようと思い、朝から走ることに。

朝7時に起きて、八重洲のホテルを出る。
前日、友人と午前2時くらいまで飲んでおり、やや二日酔い気味。

ホテルを出てまっすぐ歩くと、ちょうど二重橋のところに出たので、そこをスタート位置とすることに。とりあえず記念に写真を撮り、iPhoneのNIKE+ GPSを起動してランニング開始！！

皇居は一周約5km。今の僕の無理のないペースがだいたい7min/kmなので、35分で一周できる計算である。5kmならば練習でいつも走っている距離なので、多少二日酔いでも問題なかろう。

事前調査で、皇居ランは反時計回りに走るのがマナー、とのことだった。なるほど。だいたいみんな反時計回りに走っているので、僕もそれにあわせて走る。

実際に走ったコースと、記録はこんな感じ。

しかしそれにしても、ランナーが多い。
ランニング用ではない普通の歩道である。割りと狭い道を常に多くのランナーが走っており、互いに抜きつ抜かれつしながらであるので、ペースの維持が難しい。

また、思いの外高低差が激しい。

たかが5kmと甘くみていたが、いつもは河川敷のフラットなコースを走っているので、この高低差は正直ハードだった。特に後半、少し長い下り坂が続くので足への負担が大きい。

皇居ランは、東京の行政の中心地を走ることになるので、観光地感がすごい。

国会議事堂や警視庁、最高裁判所など、テレビなどでお馴染みの建物を眺めながら走るのはなかなかお上りさん的には楽しかった。

土地勘が無いので、コース取りを間違ったりしないか不安だったのだが、常に視界に数人見えているほどランナーが多いので、彼らの後ろをついていけば絶対に道を間違えることはない。

日常的に練習に使うコースとしては正直あの人の多さは微妙な気がしたが、観光気分で走るのにはいいコースだと思う。