技術調査はググる前が肝心

概要

■「プログラミングは自分で調査しながら覚えた方が上達が早い」という意見は非常に同意

■でも出来ている人少ないよね。調査中に挫折しちゃう。

■それは「わからないこと」をブレークダウンして整理しないで調査し始めて欲しい情報をピンポイントで調べられてないから

■調査をする前に「何をしたいか」「何がわからないか」を徹底的に時間をかけて整理してから調査した方が結果的に早く答えに辿り着くからオススメ

プログラミングが上達しない or 勉強が続かない人へ:とあるIT系社長のブロマガ - ブロマガ

凄く共感できる内容だった。

特に以下の部分

実はプログラミングを"勉強する"ってこと自体ちょっとオススメできない。

どういうことかというと、僕が思うに
・何か作りたいものがある（アイデア）
・それはどうやったら作れるのか（調査）
・実際に作り出す（実行）
っていうプロセスが一番上達が早いと思うんだよね。

全くその通りだと思う。

しかしこれらをきちんと実践出来ている人は現実ではかなり少ないように思う。

何か分からない事があった時に、なんでも自分で調べてホイホイ作れてしまう人もいるが、多くの人は調査の段階で立ち止まってしまうことが多い。「調べたけど分からなかったから挫折した」みたいな。

自分は元々独学でプログラミングを覚えて、過去の仕事でもエンジニアが自分１人しかいないような状況で開発をしていたこともあってか、自分で調べて解決するのには割と慣れている。

例えば何か作業しててハマった場合、自分は下記のような感じで調査している。

 後半のググって見つかるまでキーワード変えてググるってのはみんなやっているのだが、前半のオレンジで書いた部分のフローを端折って

・何がしたいのか

・自分がどこまで分かっていて何が分からないのか

・どういう情報が欲しいか

を明確にしないまま、何となくエラーメッセージでググったりする人が多い。

これをやると、気が付くと的外れなことを調べていたり、漠然とググり続けて延々と時間をかけてしまったり、途中でそもそも何がしたいのか分からなくなってしまう。んなことを現場でやってると先輩から怒られること必須である。

ググっても分からず、最終的に誰かに質問する場合も、何が分かっていて何が分かっていないかを明確にしておかないと、聞かれた相手もどう答えていいか分からず、お互いの時間を無駄にすることになってしまう。
んなことやってると段々「あいつは自分で調べずにすぐ聞いてくるめんどくさい奴だ」とチームのメンバーに思われて、段々相手してもらえなくなる。現実は厳しい。

また、開発コストという観点からもなるべく短時間で調査できるようになることを常に心がけるべきだと思う。

調査を行う時間が初めから開発スケジュールに含まれているなら良いが、そうではない突発的な調査が必要になった場合の調査は長引けばスケジュールに影響を与える。

ハマりそうなポイントがハナから見えているのであれば、調査かプロトタイプを作って検証するスケジュールを最初から入れておくことを検討しといた方がいい。

あと調査とは関係ないけど、手元で得られる情報をきちんと集めるのは調査以前の大前提になるので、javaの長ったらしいスタックトレースもめんどくさがらずちゃんと読もうね、ってのもいつも思う。

参考：デバッグ手順(スタックトレース重要) - jfluteの日記

組織の中で新しいことをする勇気

長いこと多くのエンジニアに保守され続け、機能拡張を続けたシステムにありがちな話。初期の設計思想が無視され、付け焼き刃の設計と実装でどんどんコードが汚くなっていく。

適当なパッケージに適当な名前のクラスが量産され、似たような処理のメソッドや、やたらと多くのことをやり過ぎるメソッドが増えまくる。当然コメントなんて一言も書いてない。

急ぎで作ったから仕方がない、なんて場合もあるのだが、大抵は一つの理由に行き着く。「安易に似た実装をコピペするから」。

他の実装をパクるのはラクだ。すでに動いているのだから間違いがないし、何より自分の頭を使わなくていい。メソッドが新たに増える分には副作用が無いケースが多い。だからバグを埋め込む可能性も低い。良いことづくしだ。

その結果どうなるか。後から触る人が泣くことになる。

コピペした本人はコピペ元がなにをやってて何の為にコピペしたのが分かっているから迷うことはないが、後からコピペした辺りを触る人はそんな経緯は知らない。だからなんでほぼ同じで少しだけ違う処理をコピペして持ってきたのかわからない。このメソッドがなぜこのクラスにいるのか分からない。そもそもこの処理、このパッケージに書いていいんだっけ？？？等々。ソースを読みながらそんなことを悩んでいるうちに日が暮れる。無駄に工数を消化する。スケジュールが遅れてマネージャーに怒られる。。良いことなし。

どうするか。「根拠のあるコード」を常に書くようにする。レビューで問い詰めてコードの根拠をはっきりさせる。経験上、大体これぐらいしかない。

根拠がはっきりしていれば、他とは違うクラスの設計をしても良い。そのクラスの責務はそのシステムで初めて発生したものかも知れない。だから無理やり他の実装と合わせる必要はない。

オブジェクト指向の原点に立ち返って、「このクラスの責務は何だろうか？このメソッドはこのクラスの責務を超えてはいないか？」と自問して、「この処理はこのクラスがするのはおかしい。別の名前のクラスがやるべきだ」と感じたら、堂々と新しいクラスを作ればいい。

こういうパターンの名前は今いじっているシステムには無い？でも散々考えた挙句、あなたはその名前がふさわしいと思ったんでしょ？根拠があるんでしょ？だったら堂々とレビューに出せばいい。何でもかんでもHogeLogic , FooServiceでピッタリハマる訳じゃない。

新しいことをやるとレビュアーに突っ込まれる？根拠を堂々と述べればいい。それが出来ないならきちんと設計ができていない。自信が無ければ作業中でも他の人にクラス設計をレビューしてもらえばいい。

実装に手一杯で設計まで手が回らない、なんて言うケースもたまに見かけるけど、それでも設計には時間をかけるべきだし、設計に時間がかかるんならチケットを切る段階でそれを見越して見積もりを立ててスケジュールを切ればいい。それくらい設計フェーズは大事だ。ここを疎かにすると後の人が泣く事になり、いずれ自分も泣く羽目になる。

必要ならば新しいことをする勇気を出して欲しい、といつも思う。確かに新しいことは怖い。リスクも大きい。でも、他と同じような感じで何となくコードを書いて飯を食ってたらいつまでもスキルは上がらない。

仮にそれをやって他から突っ込まれても、きちんと根拠を説明して議論することもエンジニアにとっては重要なスキルだと思う。自分が知る限り、説明が下手なエンジニアに良いエンジニアはいない。優秀になればなるほど完結な言葉で端的に説明できる人が多い。議論好きである必要はないけど、きちんと自分の頭で考えて、「これがベストだ！」と思える設計・実装をして、それを周囲に認めてもらいながらものを作り続けられるようにしたい。

ボ カ ロ で 懐 か し い 名 曲 は

【動画】ボ カ ロ で 一 番 の 神 曲 は：ひまねっと

便乗して書いた。反省はしていない。

自分が一番ボカロを聞いてた2007年～2009年の頃に好きだった曲（一部）を集めてみた。

本当はplay!2.1.1 + DBFluteの構成でアプリを作ってみたエントリーを書こうと思ったが次回に持ち越しである。

2013年振り返り

今年は社会人として、エンジニアとして色々と「初めて」なことの多い１年だった。

社会人として

フラットな関係で仕事を依頼する、されるようになった

今まではSIer,web制作会社にいたので、仕事の依頼はお客様からの「受注」でやっていて、何かを依頼する時はこちらから「発注」する形で他社のエンジニアやデザイナと一緒にやってきた。なので、どことなく金銭のやりとりが発生することから「上下」関係みたいなものがあって、その中でコミュニケーションを取って仕事をしてきた。別に下請けに傲慢な態度を取るとかってことはしなかったけど（お客様から見たら自分だって下請けだ）、それでもなんか一定の距離というか遠慮というか、そっちの事情はそっちの事情、みたいな所があって、同じものを作ろうとしてるのに違和感というか残念な感じがあった。

それが今年からは事業会社に転職し、営業・マーケ・デザイナ・エンジニアが全て自社の人間になった。その中で仕事をお互いに依頼する/されるようになり、そのコミュニケーションの仕方に最初戸惑った。どのように依頼すればいいのか、されればいいのか。入社した直後は他部署に何かを頼む場合（例えばこれこれの画面の確認をしてくれ、とか）も随分と堅苦しいもの言いをしていたように思うし、何が何でも期日を守らなければならないとか、言われたことは無理でも全部やらなきゃならないとか、受託開発で食ってきた人間のクセが抜け切れていなかった。

でもやってくうちに、事業会社の場合はみんなが同じ方法で利益を追い求めるのだから、個々の都合ではなく全体最適でタスクを捉えてどう進めるかを議論すべきだ、ということに気づいた。つまり、言われたから全部やる、ではなく、それが会社の為にどういう意味があるのか？を考えて議論して、やる内容や優先順位付けをできるようになってきた。他の部署もそういうものの考え方をして話をしてくれる。たまにそうでない人もいたりするが、その上司は分かってくれるので非常にやりやすい。一方で、受託開発と違ってその施策をやって、必ずしも売上が上がる訳ではないので、本当に効果があるかどうかビビりながらやったり、逆に数値が下がって慌てて切り戻すなんてこともある。それでも、今のフラットな関係で、みんなで同じ目的を達成するために議論しながら仕事を進める今のスタイルが好きだと思う。

 新卒氏のOJTをした話

今年の夏頃から諸事情で営業から異動になった今年入社の新卒のOJTを担当した。

後輩を持つのもOJTを担当するのも、社会人になってから５年目にして初めての経験で、仕事として人からプログラミングを教えてもらった経験が殆んど無かった自分としては色々不安があったのだが、その分得るのものが大きい経験だった。

最初の一ヶ月半は教育期間ということでjava初心者本の写経、webアプリ開発のための基礎知識として自分が講師をやった座学を数回、webアプリ開発課題をやってもらった。

本当はjavaの基礎に加えて、webサーバ・APサーバ・DBの連携部分などのwebアプリの基礎をじっくり教えてから課題に取り組んでもらいたかったけど、すでに他の新卒は業務に入っていた時期で時間がなかった。なので、Webアプリケーションの登場人物や、静的なホームページとWebアプリケーションの違い、データーベースの概要なんてのを座学でわずかにフォローしたに過ぎなかった。課題がギリギリ出来る程度の。

しかし、後に業務に入ってもらってから、この辺はもっと時間をかけてじっくりやっておけば良かったと感じた。業務に入ってからの共通言語になるこれらのレイヤーの知識が頭に入っていないと、タスクの内容も正しく把握できないこともあるし、「何となく」ロジックを直して動いた、で終わってしまっていたなと思うこともあった。この辺は反省材料として来年の新卒教育カリキュラムに活かしていく予定。

業務に入ってからは、スキル差というかベースとなるIT関係の知識の無さが問題になることが多かった。元々中途入社で固めてきた会社だったので、「エンジニアとしての常識」みたいなものがあることを前提に業務を回してきたけどそういうのが全くないメンバーへの対応は非常に難しいものがあった。主に自分がチケットを管理して新卒氏に振って自分がレビューする、スケジュールも管理する、みたいなことをやっていたが、Webアプリというものはサーバ側もフロント側のhtml,js,css、さらには使ってる外部のミドルウェアまで広く知らないといじれないもので、その辺をつまみ食いしながらタスクをこなしてもらっている状態で中々体型づいた知識の蓄え方をさせてやれなかった。

毎日３０分その日のタスクの振り返りをして、技術的に足りない部分はQA形式や自分個人が必要だと思うことを教える形でフォローしたけど、本当はここも週単位でテーマを決めてそれに基づいて講義形式で技術を叩き込むべきだったのだと思う。あまりにも言語の知識も足りてなかったし、コードを書く上での「作法」とかコードを追う上での勘所が分かっていないようだった。自分が激務で週２，３は終電帰りとかで時間がなかったと言い訳をしてしまえばそれまでなんだけど、申し訳ないことをしたと思う。教育担当になったのだから、自分のタスクを減らすことを上司に交渉してでも教育に専念すべきだったのだと思う。けど自分の仕事の裁量が大きくなってきた時期とも重なっていて、責任ややり甲斐が大きくなってきた中で、自分の業務を減らしたくないという思いもあった。結果として、中途半端になってしまって申し訳ないことをしたと思う。

結局そんな状況だったので、見かねた会社の教育＋サポート専門で入ってもらっているフリーランスのエンジニアにサポートをどっぷり頼む形となった。自分の至らなさを認めなくてはならず凄く辛かったけど、結果としては新卒氏のスキルアップという意味では良かったのだと思う。１２月末頃までにはwebアプリの機能保守という点では業務が出来るようになった。まだゼロベースで作れるほどではないが、前より大分総合的なスキルが深まったように思う。

11月末頃にエンジニア内でチーム再編があって、新卒氏は自分とは違うチームになって業務的にチケットを振ることは無くなって実質お役御免になった。ただ、週１でフォローアップをする時間を作ってそこでのフォローは続けている。そこでは、今やってるチケットの相談とか、チームの愚痴を聞いたりとか、UI設計やjsやフロントの実装がまだ弱いのでその辺の技術的なフォローをしたり、その新卒氏と他のエンジニアも交えて「javascript本格入門」の読書会を初めたりした。決して良いOJTトレーナーではなかったけど、次の新卒が入ってくる頃まではフォローを続けて、自分自身の「教えるスキル」の向上に努めたい。

エンジニアとして

人のソースをレビューするようになった

前職ではほぼ１人デコードを書いて自分でテストして自分でリリースするような感じだったのだが、現職からは１０数名のチームで開発している。

そこで当然のごとくお互いのソースをレビューするのだが、初めての経験だったのでどこまで突っ込んだレビューをしていいのか戸惑った。

とりあえず目的を満たしていればいいのか、クラス設計の適切さやメソッド名や変数名の適切さとかの細かい部分まで突っ込むべきのか、時間の成約があるなかでどこまでやるべきか迷った。明確な基準がある訳ではなく、個々人の裁量に任されていたので自分でそこは決めなければならない。

最初はチェックアウトしてローカルで動作させて問題なければ大方OK、ソースを見て「まぁこんなもんだろ」でLGTMとしていて、動作がおかしければ「大体ここがおかしいでーす」とかの大雑把な指摘で今年前半は良かった。メンバーのスキルも仕様理解度も高いメンバーで構成されていたからツーカーの会話で大体済ませられたし、どちらかと言えばこの頃は俺の方がマサカリを投げられまくっていた。

それが、チーム内のメンバーがどんどん他事業に行ったり中途で入ってきたりして入れ替わってきて、今年初頭と比べて殆んどのメンバーが入れ替わった今年後半においては、プログラミングのスキルが低かったり仕様の理解が不十分なメンバーが増えて、レビューでの突っ込みどころが凄く増えてきた。このクラスはこのパッケージに置いちゃダメなルールなの！Wikiに書いてあるでしょーが！とか、この処理はApache CommonsのUtil使って～みたいなレベルのツッコミをしなければならないことが増えたので、スキル底上げも兼ねて細かい実装レベルでレビューをするようになった。

先に書いた新卒氏のレビューなんかもそうである。レビューする時にRedmineのチケットのソースに延々と細かい駄目だしとなぜそれが必要なのか？を書くようになった。jsのイベントのbindの仕方がミスってて「ここでonでbindしたらajaxでリロードした時にbindされないから$(document).onでやった方がよくて、その場合もさらに。。」みたいな感じのことを書いたり。

他にも何度も使用するmatcherをクラスのフィールドで初期化しないとダメな理由を本人とっ捕まえてコンコンと説明したりしなくちゃいけないような場面も増えたが、結局チーム全体のスキルを底上げしていかないと良い仕事なんて出来ないので、レビューは今後も「細かく」「地道に」やる方針で続けていこうと思う。

オブジェクト指向をちゃんと意識するようになった

javaをガッツリ書くようになって、ポリモーフィズムの重要さとかデザインパターンの有用さとかがようやく分かった気がする。１年前まではクラスはせいぜい処理を一定の単位でまとめたものぐらいにしか思ってなくて、インターフェース？美味しいのそれ？って感じだったのだが、今は特定の機能を「いかに差し替え可能な実装にするか」を考えてクラス設計したり、必要に応じてインターフェース作ったり、ということが自然にできるようになった。たまに、今触ってるソースでも過剰に抽象化し過ぎているクラスもあったりもするが、抽象化し過ぎたものを具象化し直すのはそれ程難しくないが、その逆は凄くめんどくさい。一度、「こうやって作ったけど処理の最初の方で実装クラス分けて処理書くようにしたら内部の分岐がシンプルになるじゃん」みたいなケースがあって、ほぼ終わってたがそこからインターフェース書いて実装クラス作りなおしてやり直したみたいなことをしたことがある。テストも全部やり直しでめんどーくさいのだが、後から保守していく上では業務ドメインを細かく分けておいた方がやりやすくなった。ドメイン分析大事。けどDDDはまだ良くわからないので来年勉強して、部分的でも取り入れていきたい。

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で監視する項目はコレで十分か、とかのノウハウ。

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

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

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

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