2013年に読んだ本

2013年の振り返りということで、今年読んだ本を読んだ順にまとめてみる。

amazonの購入履歴と後は個人的な記憶に基づいてまとめるので多少の過不足はご勘弁を。こうやって見ると今年はあまり本を読んでなかった。ネットの情報に非常に頼りまくっていた感がある。

紙媒体でしか得られない知識はまだ沢山あるので来年はもっと読まなないとなーと思う。

Java関係

 Effective Java

EFFECTIVE JAVA 第2版

2012年12月頃に購入。

javaやってる出来る人はみんなこの本読んでるイメージ。ピアソン社の日本撤退により日本語版が絶版になってしまったが、また来年２月に丸善出版から再販されるらしい。

昨年１２月に今の会社に転職して初めてまともにjavaを書き始めたのできちんとjavaを勉強しようと思ったのだが、javaの入門書は大体がプログラミング初心者をターゲットとしているので、説明過多で自分が知りたい「他の言語との違い」みたいな所が掴みづらい本が多かった。なので初心者向けじゃなくて、ちょっと知ってる人向けのjavaの本が欲しかった。

 なんていうリクエストを職場の先輩にぶつけてみたら紹介してもらったのがこの本。頭から読まず、ジェネリクスとアノテーションの章から読み始めた。この章だけはjava1.5からの新機能ということもあって、入門的に丁寧に書いてあった。

なぜジェネリクスとアノテーションが必要か？そもそもそれらはどういう役割なのか？どう使うのか？みたいなことが書いてあって非常に分かりやすかった。これ読まなかったら「Eclipse先生に叱られるから」程度の理由でジェネリクス使ってたし、アノテーションは「おまじない」ぐらいにしか思わなかったと思う。まぁ自分でclassからアノテーションを参照するコード書いてみればおまじないじゃないってことぐらい分かるけど、業務ロジックだけ書いてるとそういう機会も殆ど無いのでアノテーションの仕組みを一度はきちんと勉強してみることは大事だと思う。

それ以外の章については始業の１時間ぐらい前に会社に来て黙々と読み進めて１ヶ月で半分ぐらいまで読んだのだが、段々１人では理解がしんどくなってきて、そもそも自分の理解が正しいのか自信が持てなくなってきた。そこで今年の春ぐらいから週一回、業務時間外に社内読書会という形で同僚と一緒に読み進めることにした。参加していたのは自分と同じぐらいのスキルのメンバーだったので、何でもわかってる先生という感じでもないので「これはこういう意味じゃね？」「これは作者言い過ぎじゃね？」とかあーだーこーだと議論しながら進めた。あと、Effective javaの読書会議事録はネットの至るとことにアップされているのでそれらを参照することもあった。

中々これは楽しかったのだが、参加メンバーは自分含めて最初５人ぐらいいたはずが、１人来なくなり２人来なくなり、今では自分ともう一人しかいない。別に退職したとかじゃなくて、仕事が忙しいとか朝早く来るのがしんどいとか、そんな理由でモチベーションが落ちてしまったのだと思う。自分は「継承よりコンポジションを選ぶ」に衝撃を受けて、今までガンガン継承使って共通処理をまとめる実装をしてたのを、デザパタを適用する時以外は殆んど継承を使わないようになるとかの影響を受けているのだが、クラス設計レベルの話に興味が無い人には面白く無い本なんだと思う。

OOP言語使ったプログラミングにおいて、クラス設計・インターフェース設計が一番大事だと個人的には思っているので、Effective javaを来年以降も読み込んでもっと良い設計が出来るようになりたい。

Seasar 2 徹底入門 SAStruts/S2JDBC 対応

Seasar 2 徹底入門 SAStruts/S2JDBC 対応

2012年12月頃に購入。

入社してからずっと関わっているプロジェクトはStruts2なのだが、Struts2の日本語本が無かったのと、他のプロジェクトではSAStrutsを拡張したフレームワークを使ってたり、社内にSeaserコミッタの人がいたりもするので勉強のために買った。

大体コレ一冊でSeaser2のDIコンテナの仕組みからSAStruts使ったwebアプリの開発までいける。2010年と古めの本だが今でもSASturtsでwebアプリを作るならまだまだ使える本。

ただ、書籍内ではDolteng使ってSASturtsプロジェクトのひな形を作る方法が紹介されているが、今作るんだったらMavenのarchetype使った方がいいと思う。
そっちのがラクなのと最初からmavenプロジェクトとしてimportできるので何かと良い。自分の環境では、Doltengで作ってからMavenプロジェクトにコンバートしたらプロジェクト自体がおかしくなったことが何度かあった。Maven使わないでアプリ作るとか昨今のjavaではあり得ないので何でも最初からgenerate : archetypeで作るようにしている。

Spring2.0入門 Java・オープンソース・Web開発自由自在

Spring2.0入門 Java・オープンソース・Web開発自由自在

2012年12月頃に購入。関わっているプロジェクトでSpringのDIコンテナだけ使っているのだが、Springのbean.xmlの定義複雑過ぎワラタwwwということで購入。bean定義のオプション書く時にリファレンス代わりに使っている。上記のリンクはSpring2.0だが、今は新しくSpring3.0入門が出ているので、今買うならSpring3.0で良いかも。自分は関わっているプロジェクトのバージョンに併せてSpring2.0の方を買った。

sprint mvcは使ってないのでスルーしてるがぼちぼち使ってる人がいるみたいなのでそのうちやってみようかと思う。

実装パターン

実装パターン

2013年5月ぐらいに購入（多分）。

java-ja DDDの講演資料のスライド↓で紹介されてたので購入。javaを書くようになってオブジェクト指向が何となく板に付いてきたが、それでもやっぱり自信なかったのでクラス設計やメソッドの分割粒度の決め方について知りたくて購入した。

書籍の内容については初心者に毛が生えた程度～中級者向がOOPを使いこなして良い設計や実装をするためのノウハウ集といった形。最初の第一章～第四章まではプログラミング全般において設計に気を付ける目的とか理由といったことが書いてあって、第五章からは各論（クラス、コレクション、例外等）について書いてある。

良い所として、全章を通じて、理論上の話だけでなく具体例を上げて説明しているので解りやすい。第三章なんかは、メソッドの名前付けについて実際のコードを例にダメな点と改良すべき方向について述べた上で、段々とサンプルのコードが改良されていく流れの構成になっており、名前付けに関して著者がどういう思考をしているのかトレースできる。

余談になるが、この「誰かの思考をトレースする」ことは技術学習においては大事だと思っていて、例えば「名前付けはより具体的な名前を付けた方が良い」という情報があっても、それを受け取った人が「具体的な名前ってなんだ？どうやって自分のコードを改善していけばいいんだ？」となるわけで、大事なのは「具体的な名前を付けるべき」ということではなく、「どういう観点で具体的な名前を探していけば良いのか」ということである。この書籍の良い所は後者の点が凄く丁寧に述べられている点である。納得しながら読み進めることができるので頭にすんなり入るし、作者の思考をトレースして背景がしっかり分かっているから応用を効かせやすい。

読み物系

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

2013年7月に購入。

「チームビルディング」や「チームマネジメント」の話。開発がしんどくて行き詰っていた頃に読んでいたが、これを読んでから何となくチーム内での自分の立ち位置とか、動かない人を動かす方法とか、周りからの見られ方とか考えるようになった。色々書いてあったけど、結局はエンジニアも人間なのよというお話。多分エンジニア以外の人が読んでも面白い。

 Webサービスのつくり方 ~「新しい」を生み出すための33のエッセイ

Webサービスのつくり方 ~「新しい」を生み出すための33のエッセイ (Software Design plus)

 2013年夏ぐらい？

ゆーすけべーさんの書籍。Webサービスを作るためのアイデアの考え方から実装のコツ、宣伝、運用まで。一冊あればWebサービス作って回せるぐらいにはなりそうな本。

何か作りたいーけど作るものがないーという人は是非「第一章　心構えと下準備」を読んで欲しい。最初の一歩を踏み出すきっかけをくれるんじゃないかなーと思う。技術的には最後の章のtwitter APIを例にしたOAuth認証の実装はなかなか細かく書かれていてOAuth認証するアプリを書いたことない人には凄くためになると思う。

そういや今年はGithub認証なんかも試して会社のエンジニアブログに書いたりした。

 Yコンビネーター シリコンバレー最強のスタートアップ養成スクール

Yコンビネーター シリコンバレー最強のスタートアップ養成スクール

少なくとも2013年中には買った。

 読み物。「ハッカーと画家」や「On Lisp」で有名なポールグレアムがたちが上げたベンチャーファンドである「Yコンビネーター」の取材記録のような形でまとめられている。このファンド、ただ資金提供するだけでなく、有望なスタートアップ（或いはスタートアップになりそうなサービスを作ってる学生グループ）を集めて、住む場所と少額の資金提供を行って自立したスタートアップとして育てるという珍しい取り組みをしている。タイトルに「スタートアップ養成スクール」と入っているのはそのため。

本書内では、面接の様子から始まり、実際に「授業」としてポール・グレアムとの問答をしている場面や定期的に行われる「夕食会」様子を通して、Yコンビネーターや昨今のスタートアップに関する事情を述べている。

所感としては、自分自信は起業に興味がある訳ではなかったが、スタートアップのメンバーがどういうことを考えてサービスを開発しているかという点で色々勉強になることが多かった。

BtoCオンリーのサービスは非常に難しいので資金繰りを考えたらBtoBでスタートすべきだ、というグレアムの言葉が印象的だった。自分も思いつくのは大体BtoCだが、マネタイズの部分でいつも詰まってそこで「アイデア」レベルで止まってしまう事が多い。BtoBでマネタイズまで含めて考えて、そこからBtoCに拡大することも出来るわけで、そういう考え方をしないとビジネスとしてサービスを作るのは難しいと感じた。

デザイン

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

ノンデザイナーズ・デザインブック [フルカラー新装増補版]

2013年９月ぐらい。

フロント側の実装案件が増えて、いい加減自分でもまともなUIが組めないといけなくなったのでデザインの原則を学びたくて購入。

デザインってセンスだと思ってたけどどちらかと言えば「パターン」や「原則」をいかに多く知っていて、それらをどういう時に使うかを知ってるかどうか、だと感じた。色の意味やフォントの効果は確かにセンスかも知れないが、全体の構成とかは完全にパターンがあるのでそれを守ってUIを作ることが大切だと感じた。

 Ruby関係

 今年に入ってから、個人的な勉強に始まり、自分で作ってるサービス、会社でのちょっとした社内システムでRuby + Railsを書いている。

Railsの本は。例によって例のごとく「プログラミング初心者向け」の本ばかりだったので一切買わなかった。それにバージョンが3.x系ばかりだったし、rubyも1.8系前提が多かった。ナウなヤングである自分はRuby2.0系とRails4.x系を使い、最初Macports + rbenvで挑んでドハマりしたものである（遠い目）。それ以来brewとrvmの組み合せが最もトラブルが無く、gemsetも使えて最高だということに気づいた。

自分はRailsチュートリアルとRailsの日本語ドキュメントとGithubでpublicになっているRailsプロジェクトのソースを読んで勉強した。

Railsは大きなプロジェクトになった時にどこに何のファイルを置けばよいのかが最初よく分からなかったが、クックパッドの中村さんのソース等を参考に色々考えてやっている。（来年もお世話になります！qchan期待してます！）

勉強に使った書籍をも何冊かあるのでまとめておく。 

パーフェクトRuby (PERFECT SERIES 6)

初めてのRuby

プログラミング言語 Ruby

Rubyアプリケーションプログラミング

元々自分はPHPerなので（このブログの過去記事がPHPネタだらけなのもそういう理由）javaよりも取っ付き易く、それでいてPHPよりOOPの原則を守っていて例外もちゃんと投げてくれるし（PHPの大体の組み込み関数は未だにエラー時に例外を投げてくれない）、型指定が不要な分、javaより簡潔にいろんなのが書ける。
何よりブロックを引数として渡せるのが凄く便利でコードを完結にしてる。java8はよ来い。

というような感じでこれからも長く付き合って行きたい言語である。

エンジニアの心の闇を祓うマサカリ療法

この記事は闇 Advent Calendar 2013の４日目です。

@seri_k 闇Advent Calendar書きましょう

— ıɯǝɥɔʇoɥ (@hotchemi) 2013, 12月 2

 心の闇なんてのは大体エンジニアに限らず社会人なら少なからずだれでも貯めこんでしまうものだと思う。どうすれば解決できるかなんて分からない。
４日目の記事では、過去の自分が経験した心の闇の話と、それを祓う方法についてそれとなく書いてみる。

今いる会社のエンジニアは割りと生き生き働いている方だと思うけれど、それでもやはりどこか、斜に構えた考え方や、何かについての強いトラウマみたいなものを会話の中から垣間見ることがある。若いころに辛いデスマを経験した話だったり、顧客が会社に怒りに燃えて乗り込んできた話だったり、特定のミドルウェアのバグで大変な目にあったり、会社や顧客に理不尽な要求をされて喧嘩したり、とかなんとか、色々な闇が垣間見える。今でも一緒に仕事をしていて、その手の地雷をうっかり踏むと、普段は穏やかな先輩が突然人が変わったようになることがある。

かくいう自分も、闇という程でもないが、SEとして働きながら心療内科に通っていた時期がある。新卒で就職した最初の会社にいた頃で、その頃は「仕事がつまらなすぎ」て体を壊すという珍しい経験をした。別に激務だった訳じゃない。ほぼ定時で帰ってた。それなのに、毎日の仕事が退屈過ぎて、周りが全然技術に興味がなくて、ホントにアイティー企業かここは！？みたいな青臭い苛立ちを抱えていた。手を動かしたいけど当時の俺はマネジメント側でコードの１行も書けない。協力会社のバグ調査を手伝う振りしてこっそり書いていたけど、堂々とコードを書かせてもらえない環境に凄く嫌気が差していた。あの時は「心の闇」みたいなものが相当溜まっていたのだと思う。

しかしその状況もいつまでも続いた訳ではなく、体を壊しつつもプライベートで黙々と初心者本を写経しまくり、cakephpでしょっぱいwebサービスを書いて、転職してプログラマとして働き始めた頃にはもう闇は無かった。とにかくコードを書くこと。これが自分にとっての闇を払う方法だった。やりたい事を堂々と仕事としてやれることが何よりも大事だった。

当時はそれで解決した。しかし人は贅沢なもので、どんどん出来る事が増えてくるとやりたい事も出来てきて、それに対する欲求不満みたいなものが大きくなる。自分の場合はそれもまたプライベートでコードを書いて欲求不満を回避する策に出た。プライベートで勉強していたことを仕事に還元できたものもある。サービス作ったり、勉強会に出たりして新しいネタを拾ってそれをまた身に付けたり、勉強会を自分で開催してみたりして闇を祓ってきた。仕事はどうしたって思い通りになんてならない。やりたいサービスがあったって採算が合わなければできるはずがない。だからプライベートでやるんだ、なんてことを考えた。

しかしそれでも闇が拭いきれなくなる時もある。大体そういう時は変な勘違いとかで自分を過信しているような時で、都合が悪いことを色々なことを周りのせいにしていた。少し仕事を覚えてくるとそういうことがあるらしい。自分が尊敬している先輩が同じチームからいなくなってしまった場合なんかにもよくあるらしい。

そんな折、新しい心の闇の払い方を覚えた。「マサカリをぶん投げられて流血する」である。鼻っ柱を折られる、とも言う。たまに勉強会やその後の懇親会でベテランエンジニアと話をしているとたまにこれを食らう。ものによるが、大体凹む。特に基礎レベルの話で「あ、俺これ普段やってることなのに説明できない…」と思ってしまった瞬間がやばくて、自分は所詮仕事で使ってるコードをメンテして動かしてるだけの人間でゼロからものを作ることなど出来ぬ人間なのだ、とか色んなネガティブなことをその場では感じる。

でもこのマサカリこそが大事なのだ。マサカリを投げられることで、投げられたマサカリを投げ返せるようにそ突っ込まれた分野を必死勉強し始めて、次に会った時に少しは成長したなと思われたいと思い始めることが出来た。今だと「webを支える技術」を行き帰りの電車や昼休みに読み直したりしている。

社内ではレビューを受けていてもマサカリは飛んでこない。しかし一歩外に出れば容赦なく刺される。自分がいかに愚かであるか、会社から一歩出たら全く通用しないエンジニアであることが分かると会社でも謙虚になれる。今できることの範囲で、少しでも優れたエンジニアになってもっと良いアウトプットを出そうと思える。

こんなことをしていると大分気持ちがラクになった。自分が何がしたいか分からない、どういうエンジニアを目指せばいいか分からない、というのもここ半年ぐらいずっと悩んでいて禿げそうになっていたが、たまたま最近受けた数回のマサカリにより、まずはエンジニアとして恥ずかしくない仕事が出来るようになろう、と思えるようになって、大分目の前がスッキリしてきた気がする。

10年続くwebサービスを作るために

最初のロンチ時点で長く使えるシステムを作りたい、と思う。

スタートアップだから

時間がないから

お金がないから

「とりあえず」のやっつけ対応で後のことは後の人に任せる。

人も金も無いベンチャーはそうしなきゃ勝てない。凄く分かる。

スタートが凄く大事だ。知名度を得るためにも、資金を調達するためにも。

けど、だからといって一年後に絶対止まるようなリスクを持ったシステムを作って、リスクを共有せずに後継の人に引き継いで、最初に作ったメンバーはごっそり抜けて、他の事業をやっていて「あとよろしく」って。

それが本当に健全なのか凄く疑問に思うようになった。

また、それを「健全だ」と言えないとベンチャーでやっていくのに向いてないのかも知れない、とも思った。

或いは職業エンジニアとしても向いていないのでは、とも思って最近凄く悩むようになった。

データで探る2012年度のIT戦略 - 基幹系の寿命は14.6年に、大規模プロジェクトの3割強で予算超過：ITpro

あるシステムの寿命がどのくらいかなんて誰にもわからない。

半年ぐらいで役目を終えるかも知れないし、１０年経ってもベースがそのまま使われるかも知れない。

でも、だからといって１年後にめちゃくちゃreadが遅くなるのが目に見ているテーブル設計や、データファイルがディスクを食い尽くしてクリティカルな機能が止まり、全システムが突然止まるようなことが目に見えているようなものを作って、そのリスクを一切共有しない。回避策も考えない。

それが本当に正しいのか。

いくら早くサービスを作ってリリースして高い収益を上げられたとしても、後継のエンジニアを不幸にするようなシステムを作ってはいけない。

ユーザーに不快感と迷惑を与えるようなサービスを作っちゃいけない。

いつか会社を不幸にするようなサービスを作っちゃいけない。

最初からユーザーがどこかで増えても簡単には落ちないシステムを最初から設計すべきだ。

いくらAWSを使ってインフラをスケールできるようにしても、根本の設計が間違っていたらいくらインスタンスに投資しても足りない。

ここは実装クラスを差し替えられるようにインターフェース作って抽象化しとくか、実装がばらつかないように早い段階でサンプルを作っておくか、ログは定期バックアップを取るかfluentでどっかに集めてAPサーバのディスクサイズが一定以上超えないようになっているか、使っているミドルウェアのデータファイル増加ペースはこんなもんで、Nagiosで監視する項目はコレで十分か、とかのノウハウ。

沢山貯めて、最初からユーザーが想定の倍以上増えても、スケールする時に全くビビリ必要がない設計のシステムを作って、安定したサービス運用ができるようにしたい。

エンジニアとして、この辺のことを全部把握できるようになりたい。

インフラは相変わらず苦手だが、一つのライブラリのようにミドルウェアをサービスベースで使えるようになった時代なので、それらを活用したシステム設計を身に付けていきたい。

いつか自分が仕事で新しいサービスをゼロから作ることになった時、出来る限りの人を不幸にさせないサービスを作りたいと思う。

興味

自分自身は好きでエンジニアをやっている。

SIerを飛び出したのもプログラミングが好きだったからだ。

毎日誰かの技術ブログやTechcrunchを読んでいるのも好きだからだ。

家にいても気になることがアレばすぐにエディタを立ち上げてコードを書き始めるのも好きだからだ。

好きでやっているもので、好きでないのにエンジニアの仕事をしている人の気持ちが理解出来ない。正直な所。

正直な感想であれど、それでは済まないことも世の中多々あって、どうしても会社に所属していればそういう「好きでない人達」と仕事をしなければならず、それがまぁ辛い。正直な所。

「自分の担当は○○だから××は知らない」とか「これは習ってないからわかりません」とか、そういう感覚が分からなくて、それを注意する正当な理由もないから、「そうですか」とだけ言って、チケットの内容だけを説明して、チケットの担当者をその人に変える。今の会社でに入社してまもない頃、仕様を理解するために始業１時間半前に出社してソースを読んでテーブル定義書を読んで、EffectiveJavaを読み続けた俺には分からない。誰よりも出来ることを多くしようとして、当時１人の担当者がやってたインフラ周りの構成まで覚えて、自社のサービスで使ってるミドルウェアは全部触れるようになった俺には分からない。

何かおかしい。そう思っても何も言えないし、もしかしたらおかしいのは俺の方なんじゃないか？って思う。なんでこんなに技術に興味があるのか、なんでこんなに少しでも「分からないこと」があると許せなくて自分で調べてしまうのか。周りと違いすぎてついて行けない。

かつて自分の周りはそういう人達だけだった。そういう人達に、この会社で今の俺は育ててもらって、色んなことを教えてもらった。

今はそういう人達はもういない。同じ会社にはいる。でもどんどん違う事業に行ってしまった。今は「理解できない」人達だけと仕事をしている。

そういう人達に仕事を振るのが今の俺の仕事。

矛盾

とあるタスクに対して

「ここは○○使って☓☓にした方が将来的に拡張できるし機能的にイケてるからそうしたい」

という思考と

「ここを直してもKPI改善効果は低い他のタスク優先すべきだ」

という思考とがよくぶつかり合うようになった。

それがとてもつらい。

仕事としてコードを書いている以上、後者の視点を常に持ってタスクの優先度を決定していくべきなのだが、それってエンジニアじゃなくても掃除のおばちゃんでも出来るじゃん？っていうケースが多々あって、例えばとあるフォームのtextareaのrowを10から5にすることで、ユーザーが「沢山入力しなきゃいけないの？めんどくせー、ニコ動でも見よ」→"離脱"になるケースを減らして離脱率を上げるとか、デザイナの修正したhtmlをjspやvmに書き換えるお仕事とか、大量のレビューとテストとか、まぁそんなお仕事に毎日忙殺されてて、正直エンジニアとしての自分を持て余してる。(レビューとテストは重要だけども）

自分以外のエンジニアもこの問題に直面するケースってあると思うんだけど、そういう場合は業務外でOSSの開発をしたり、自分のサービスを作ったりして解消するんだろうけど、なんかそういう所で発散されるパワーって世の中をより良く出来る可能性の損失と考えれば勿体無いなと思ったり。

そのパワーを仕事にすることは出来ないのだろうか。つまり、自分が一番パフォーマンスを発揮できることを仕事に出来ないのだろうか。最近そんなことをずっと考えてて、というのも自分の人生、特に脳みそが元気で大量にインプットできる若い時期なんて時間が限られてるわけで、「やりたくねぇことやってる暇はねぇ」な訳。

自分の場合、20代の時間はもうあと３年もなく、30にもなればどういう価値を出せるかがもっとシビアに問われるようになる。正直まだ何もできていないので焦っている。

とりあえずは今自分が作ってるslidesearch.jpでSEO含めた実験とかGAを使うノウハウをためてみたり、railsの不便だと思うところでgemを書いてみたりと、とにかく手を動かす時間を確保しつつ、どうすれば矛盾を解消できるかを考えたい。空き時間をとにかくエンジニアとしての価値を磨くことにコミットする。

そんなことを思った2013年度下期のスタート

YAPC::Asia 2013に参加してきた

会社より与えられし夏休みの最後の１日分を使ってYAPC::Asia2013に参加してきた。

↓写真とかはここにまとまってる

 gihyo.jpのレポート

普段perl書かないし書く予定無いけど何故参加したか

別言語のコミュニティでどういう事が話題になっているか知りたかったというのが主な動機。perlについては過去に某歌い手が使ってたニコ生で曲リクエストに使うCGIの機能追加を依頼されて直したことがあるぐらいで、全然詳しくないし仕事でも書いてない。仕事は相変わらずjavaとjsしか書いてない。

けどなんかperlって昔から勉強会やらカンファレンスやが盛んな印象があったので、どういうコミュニティでどういう活動をしているのかについてはずっと興味があった。

ただ、やっぱりperlの深いところは全然わからないのであんまりperl絡まないセッションに絞って聞きに行くことにした。

初日(9/20)

会場の５分ぐらい前の良い時間に会場到着。

オープニングに続いて午前中は３つのセッションを聞く。

Postcards from the Edge: The State of Perl 5 Development

memcachedプロキシサーバの開発と運用

OpenID Connect ~ これが最新のOpenID仕様だッ！~

perl5言語仕様の話以外はタイトルだけ見るとperlと関係ない。というかまぁ内容的にも殆んどperl絡まなかったんだけど、普通にweb屋として興味深かった。

memcachedプロキシサーバの話は今の仕事でも悩みどころになっていたkvsが単一障害点になって止まったらどうしよう問題についての話。ソース自体はgithubで公開されているので割りとクリティカルな所にmemcachedプロキシ使ってるkvs使う機会あったら使いたい。

neoagent

ランチセッションでご飯食べながらSix ApartとMicrosoftのセッションを聞く。

Azureでもperl使えるようになったとか。ほほー

午後も引き続きセッションを聞いて回った。

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

ぼくがかんがえたさいきょうのMVC

個人で出来る！PerlによるWebアプリケーションの作り方

CPAN Testers Reportの情報を上手に使おう！

Perlは他言語(から|に)何を(学んだ|教えた)か

大規模Perl～はDeNAの2013年新卒71人のエンジニアをどのように教育したかについてのセッション。

今自分も2013新卒のOJTを担当してるので色々と考えるところがあった。今年のDeNAの新卒研修の目標は「自走できるエンジニアを育てる」だったらしく、内容もそれに見合ったかなり厳しいものだったなぁという印象。

あとGithubの使い方をしっかり教えたのが現場で好評だったというのを聞いて、ツールの使い方って以外と漏れやすいけど現場で教えるのが割りと大変な部分だし、そういう所を最初の集合研修でしっかりやることは価値があることだと思った。

今現場で新卒に対してgitやredmineやeclipseプラグイン系の使い方のフォローをしていることが実際に多い。来年はこの辺のツールの使い方をしっかり研修内容に入れなければと思った。

ぼくがかんがえたさいきょうのMvc from karupanerura </xmp>

MVCの話は会場が満員で立ち見出まくりだった。やっぱり皆色々と思うところがあるのだろうか。セッションの内容的には「MVCと言っても適用するアプリケーションによって最適な設計は異なるから、適用するアプリケーションの形態に併せてカスタマイズすることが大事」というものだった。これは全くその通りだと思うし、Webアプリにしてもシンプルな場合と超絶複雑な場合とで設計思想が異なってくある。

1Controller１Model で完結するようなScafolldingで作ったみたいなシンプルなWebアプリと、1Controllerに5Model(テーブル５個）ぐらい関連してきて複雑なデータモデルを扱うWebアプリとではModelの中でもモジュールの分割レベルが異ってくるし、逆にそこを規模に関わらず同一のアーキテクチャでやろうとすれば当然無理が出る。

複雑すぎてもメンテコストが高くなるだけだし、シンプルにすると例外的なクラスが量産されて結局カオスになる。

だから、MVCはパターンに過ぎないので、自分が作るアプリの内容に合わせた最適なアーキテクチャを自分の頭使って考えようよ、っていう話は凄く納得がいく話だった。アーキテクチャ超大事。

なんてことを考えた。

とりあえず初日はこんな感じ

あともらったノベルティ

YAPC でもらったノベルティ一式。Tシャツの裏側にはpixivのロゴがでかでかと書いてあるので着てたらpixiv社員と間違われそうな感じ(笑)

２日目(9/21)

洗濯とかしてたら遅れたので午前中は２セッションしか聞けなかった。

というか２日目はperlにフォーカスした内容が多いので聞いても分かりそうなのが少なかった。

Perlで書く結合テスト

Perl 6 オブジェクト指向プログラミング

結合テストの話はPerlに限らず他の言語でも使えるお話で良い復習になった。

Perl6でコードを書くことは余程の理由がない限り無いだろうと思った。

そしてまたランチセッション

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

午後はこれだけ聞いて帰った。生伊藤直也さん久々に見た。

PerlとRubyの座談会。disり合いの殴り合いにならなくてよかった。

Perlのカンファレンスの様子です pic.twitter.com/okpblHNgLO

— レジャスポ太郎 (@rejasupotaro) 2013, 9月 21

 個人的には卜部さんのRuby開発にまつわる話が興味深くて、小飼弾さんの「Rubyのバージョンアップ時に旧バージョンとの互換性テストはしてるのか」という質問に対して、卜部さん

「バージョン上げるといろんなものが壊れるのは分かってる。それでもやってくんだぜ、っていう姿勢」

と回答してた。

Webサービス業界でRubyが良く使われ、SI業界でRubyが殆んど使われない理由がわかった気がする。

最近RailsでWebアプリを書いてる関係でRubyを書くようになったが、凄く気持ちが良い言語だと思ってる。最初はその謎ルールに戸惑うが、一度覚えてしまうと自分の思考をそのままスッとコードに落とし込めるので凄く気持ちいい。ジャバやPHPとかの硬い言語をルール通りに書くのとはまた違う快感がある。

その利便性や「気持よさ」を大事にするために後方互換性を捨ててでも新しいことをやり続ける。そういやRailsもそんな感じで、Rails2はもはや別物なのでググってひっかかった情報が殆んど役に立たないが、ちゃんとRails４の情報が山ほどあるからあまり困らない。使う側もそういう文化なのだろう。サポートの体制含めてみんなで作り上げているというか。そういう在り方がOSSっぽくて凄くいい。

自分はRubyのそういう姿勢を支持したい。

 

二日目は残りのセッションにあまり興味がなかったのでここで会場を後にし、自分の初YAPCは終わった。

何でも有りのごった煮カンファレンスであるが故に、興味があるセッションとそうでないものの差が大きいので、興味が無いものだらけになった枠に黙々開発とか自由にLT出来るハッカソンスペースみたいのがあってもいいかなぁとか思った。

とはいえこんだけ色んな界隈の人が集まるカンファレンスもなかなか無いので、これはこれで楽しかったかなと思った。来年も時間があれば参加したいし、こんだけフィードバックがもらえる場であればネタがあればセッションしたいと思った。

 

YAPC感想エントリーまとめ

ロールモデル

もう年も年でアラサーで、なんか小さなチームのリーダーとかやってるせいで社内ではワカモノという感じも薄れつつあり、上司と話をすれば「お前は何がしたいんだ」と問い詰められる次第。そろそろ有象無象のエンジニアではいられなくなってきた訳だ。
しかし、そんなに周りから何がしたいか分からないように見えるのかね。

本音を吐露してしまえば、「何がしたい」も何も、

「やりたいのはwebサービスのネタを考えてコアを作れる伊藤直也みたいな人間になってサービスを成長させまくって沢山作りまくって、少しでもwebで人の役に立つことです。今はそれがが出来ないので、エンジニアとしてスキルを磨く一方で、マーケティングチームと一緒に仕事をする中でweb広告について研究したりGAの活用方法と数値のみかたを必死に勉強している所です」

になるのだが、

「要するになりたいのはマネージャーか？プロデューサーか？スペシャリストか？」

みたいなことを聞かれて、

いやいや分類できません、今の会社にもそういうロールモデルはおりません、目標にしたいエンジニアは伊藤直也です、っていう話になってしまい、「やっぱりこいつは何がしたいか分からない人間」と思われてしまうのではなかろうか。
そもそもweb屋なんてもともと色んなスキルセットが必要なのだから、SIみたいに役割やなりたい像みたいのを括ることが難しい。とりあえず、自分はエンジニアとして働いているのでITスペシャリストとでも言っておけばいいのか？ってなるとなんかもっと抽象的で分かりにくい。

当の本人たる俺だって上手く分類できないし、最近はグロースハッカーなんて言葉まで流行っているのでもっと分からなくなってきた。
例えば、前職の社長は一応営業なのに、フォトショやフラッシュでweb広告のクリエイティブを自分で直しちゃうような人だった。彼は一応営業上がりなのだが、デザンにめちゃくちゃこだわりがあって、丸ごとデザイン外注するよりこの人がワイヤー書いて仕上げだけ外注に出した方がはえぇんだろうなと思うことが多々あったり、なんか趣味でプログラミングしたいとか言ってる人だったり、なんか多彩な人だった。

自分の短いweb屋経験からいくと、そういう人がweb屋には多いし、ベンチャーにおいては人材が多様化してる方が強いと思うんだが、どうだろう。
ひとりひとりの役割が大きい訳で、ぱっと見て「ロールが分かりやすい人」よりは、何でもこなせる人の方が少ない人数でやる中では重要なことだと感じるし、会社としても多芸な人がいる方が面白いと思うんだけど、今自社の社内を見渡すと、大体の人が「俺はこれで飯を食ってるんだ」っていうコアを持ってる。だから、○○については誰それに聞けば詳しい、というぐらいになっている。一方、俺なんてのは特にそういうのはなく、たまにレコメンドの話とかPHPの話を聞かれるぐらいだ。今はGoogle Analyticsをいじりまくってるので数値の取り方とかについては聞かれるようになったけど、やっぱり器用貧乏という感じがしてしまう。

それなりに何をやらせても出来るが、何かに秀でてる訳じゃないのでどういうポジションに付けたら良いか分からない、というのが俺の上司の本音なのではないかと思うようになった。だからコアスキルを育てなければ、と考えているのだが、やはり何か特定のことに興味があるのではなく、最初に書いたように多方面に興味が向きまくってるせいでコアスキルが育ちにくい。良く言えば好奇心旺盛、悪く言えば飽き症。

今は仮設を立てた上でのUIやサイトの速度改善等の修正によるKPI改善（いわゆるグロースハックってやつ）が面白くて、エンジニアよりはマーケの人と話をしてあーだこーだと議論してアイデアを出し合ってる時間が一番充実感を感じるし、自分でその修正を実装して、リリース後にを見て次の施策を考えるのが面白い。自分で直して自分で数値を見て検証する。

これが今のところ一番仕事としてはやりがいを感じてるので、しばらくこっち方面のスキルを伸ばしながら、自分の価値をどこに置いていくか考えていこうかなと思う。なんかまとまりがない文章になったけど、まぁ良い。とにかく一生懸命やろう。webは大好きだし。