近況

特に大きな変化はないのだけれど書いておく。

今

開発現場から離れてプロジェクト横断的に技術サポートをしたり今どきのプロダクトを検証したりしている。あとは細々とした雑用。

seleniumについて

いい加減、画面が止まると直接売上に影響がある部分ぐらいは自動テストしようよということで、今の部署に移ってから最初に着手した仕事。以前はこれをやりたくてもタスクの優先順位的にできなかった。そういう足の裏についた米粒みたいなタスクって考えてみると結構沢山あるんだと初めて知った。

Ajaxゴリゴリで描画する画面のテストケースだったのでSelenium studioは使わずにフルスクラッチでSeleniumのテストシナリオを書いた。jqueryのanimateが完了するまで待たせたり何故かクリックが空振りするのでjsでDOMを指定してクリックさせるようにしたり、それでもダメならthread.sleepを入れたりと、かなりの職人技の世界だったが、その辺のハマりポイントをラップしまくったライブラリ群みたいなものが出来たので、それを使えば今後の修正は大分楽できるだろう、という所まで持っていった。

最終的にはJenkinsからWindowsのEC2 instanceを起動してjenkins slaveとして登録し、そのinstance上でSeleniumを実行して結果をjenkinsに返す所までこぎつけた。自分はSeleniumのテストシナリオだけ書いてJenkinsに設定する所は他のメンバーに託した。最近は出来るだけ他の人に任せるようにしている。以前の自分なら全部１人でやってしまっていたが、それでは組織の成長のために良くない。

fluentd + elasticserach + kibanaについて

会社で「MySQLのslow_query_logとかjavaのStacktraceちゃんと後から見返せるようにしたいよね」という話が今年初頭からあり、手元のmacで検証した上でマニュアルをせっせと社内wikiに書いた。Elasticsearchは未だによく分かってない部分が多いのだが、fluentのelasticsearchプラグインを使うことで、es側は特に何もせずともfluentのinputプラグインで定義したformat通りにmapを定義してくれて、かつtype名に日付が入れたりも出来るので、勝手にログを日別にindexやtypeを分けられたりとかで結構便利だ。まだ検証してないけど、index単位にログが分かれていた方が、後で古くなったindex毎削除した時にちゃんとデータファイルも一緒に消せるとかっていう挙動を期待している。この編はそのうち調べたい。

最近一部プロジェクトで導入でき、早速slow_queryの肥やしになっている激重SELECTを複数発見して潰すことに貢献した。この際、slow_queryのsql_textは改行混じりで複数行になるデータなので、それを一つのkey-valueとしてhashに格納するためにTail-Multilineなるプラグインを使用した。これは同僚が見つけてきてくれた。感謝。これを使用することで複数行のsqlやjavaのStacktraceなど複数行に渡るログファイルを綺麗にパース出来る。

ソースを見ると、通常のformatに加えて「１行目」を識別するための正規表現パターンを定義し、１行目が出てくるまでのテキストを全行繋げてbufferしておき、次に１行目が出てきた時にbufferした文字列をまとめてパースしている。中々豪快な実装でメモリの管理が少し心配になったが、このpluginで10万行ぐらいあるslow_queryログをfluentに食わせても全く問題がなかった。

これをそのまま使っても良いのだが、sqlには個人情報が乗る可能性があるので、取り急ぎforkしてconfigで指定したformatにマッチする文字列を置換する機能を追加した。例えばupdate文のset句やinsert文のvalue句などで、シングルクォートでくくられた部分を****で置換する、といったユースケースを想定している。これは取り急ぎの実装ということでinputプラグインに積んだが、本来であればoutput pluginに詰むべきだと思うし、inputプラグインでは複数のプラグインを適用できない（多分）ので、独立したoutputプラグインとして書いた方がほかのプラグインと一緒に使うには良いだろうと思う。大した実装ではないのでそのうちやりたい。gemのネタにもなるし。

slidesearch.jpについて

自分以外使ってる人がいるか怪しいサービスだが、以前一度CakePHPで書き上げたものを全てRailsで書き直した。理由は自分がRailsを勉強するためのネタとして、自由にいじれるプロダクトを一つ運用したかったから。

元々DBアクセスもなく、ただ単にslideshareのAPIを叩くだけなので別にサーバサイドが何で作られていようと関係ない移植性の高いプロダクトだった。なのでAPI叩くところでライブラリ化して、普通ならただのPure Rubyのオブジェクトのインスタンス変数となるところを、個々のプロパティ毎にクラス定義したりしてDDDっぽい感じで作ってみたり、Httpリクエストの部分をMock化してrspecでテストを書いてみたり、色々とRubyを知るために実験しながら３ヶ月ぐらいかけて作り直した。あとmemcachedで検索条件からキーを組み立ててキャッシュするようにしたり。まだ中途半端なのでもう少し手を入れてから次のサービスを作りたい。

ちょっとしたサービスネタが溜まりつつある。これがPHPを１人で書いていた３年前だと、何のサービスを作っていいか分からず、結局twitterもどきみたいな良くわからないものを作って黒歴史化してしまう所なのだが、流石に時間が経つと色々とアイデアも溜まってくるものである。

最近考えていること

残りの人生をどう生きるか

自分は２０代後半で大して人生も生きていない。

生きていないのだが、大学を卒業して就職して何年か経って、毎日満員電車に乗って出勤して仕事をして夜遅くに帰宅する、という同じような日々が続き、毎日ほぼ同じような体験をしている。エンジニアという仕事は毎日が変化のように見える人もいるかも知れないし、実際そういう仕事をしていればそうなのだろうけど、自分の場合はもう何の変化も刺激も感じなくなってしまった。誰のために手を動かしているのかすら分からなくなって、必死になって何かの為にできることを考えている。

休日になれば少し遠出したりギターを弾いたりコードを書いたりしているのだけど、それでもどこか、「また同じようなことをしている」という感覚に捕らわれる。１年を通して大体何が起きて自分が何をしているか想像が出来てしまう。

だから残りの何十年かは、ひたすら同じ体験を毎日繰り返すような感覚なのではなかろうか。そう思うようになった。何がきっかけかは分からないが。

それと共に、自分の人生は本当にそれでよいのだろうかとか何とか、まるでプロジェクト半ばに来て本当にこのプロジェクトの要件定義は正しかったのか、みたいなことを考え始めてしまった。この手の思索はどれもそうなのだが、一度考え出すと仕事中もずっとそんなことを考えてしまって止まらなくなって困っている。

散々に考えた挙句出てきた一つの明確な答えが、「自分が好きな場所で暮らして一番やりたいと感じていたことを人生でやったと実感して死にたい」ということだった。今自分が住み、働いている場所は、自分が好きな場所とは言い難い。自分は田舎生まれ田舎育ちのせいか、ずっと東京に馴染めないでいる。５年も毎日満員電車に乗って通勤してきたのに一向に慣れないし、寧ろ最近はストレスでしかなくなった。あと人が多いのにも慣れない。東京で遊びたいと思わない。休日に突然実家である栃木に帰ったり、大学時代を過ごした盛岡に行ったり、会津若松に行ってみたり、箱根に行ってみたり、足柄の山奥にフラっと行ってみたりするのもそういうことに対する反動なのだろうと思う。

薄々感付いてはいたのだけど、やっぱり自分は地方に住みたい。

でも地方に住めば、今のエンジニアとしての仕事を失う可能性が高い。IT系と行っても地方のSIerでは今時の開発をすることは難しいし、プログラマよりSEやPMの方が（単価が高いという理由で）求められるだろう。そのせいで躊躇している。

結局、今みたいにバリバリコードを書ける環境が都会にロックインされている。そのことが少なからず自分は辛く感じ始めている。それが最近色々悶々としている理由なのだと思う。

ここまで書いて少しスッキリした。

話は変わるが、ソニックガーデン代表の倉貫さんのブログを良く読んでいるのだが、こういう会社でこういう働き方が出来たらいいなと感じている。

リモートワーク（在宅勤務）を導入するためのポイントと残された課題 | Social Change!

自分がすぐそういう働き方ができるとは思っていないけど、それでもいつかそれを実現することを目標にして動こうとしている。

それを活力に少しでも前向きに生きられたらいいなと思う。

技術サポート業務の難しさ

今年１月から、入社以来所属していたチームを離れて社内全体の技術サポートをするようになった。

今の所メンバーは自分しかいない。

だからリソースはかなり少ないのだが、社内のサービス開発でのお困り事の調査だったり、上司が気になる技術の調査をしてサンプルコードを書いて上司に報告したり、ある問題に対してどういうライブラリを選択するべきかを議論したり、ひたすら社内wikiにまとめたりしている。取り扱う内容は、フレームワーク・ミドルウェアの検証から、使う可能性があるWeb APIの仕様のとりまとめまで様々である。javaでiphoneアプリを作るライブラリなんてのも検証して実際に作ってみたりした。

調べた内容については、週１回社内共有会という形で自分がLTみたいなことをして共有している。大体２０分自分が話して残りは雑談しながら質疑応答という感じだ。

こんなことを２ヶ月近くやってきたが、ずっと開発ばかりしてきた人間なので色々と壁にぶつかり始めるようになった。

１つ目は「自分がきちんとアウトプットが出せているか」が分からない点。

前に所属していたチームではスクラムっぽい開発をしていて、１回のスプリントでこなすべきチケットが決まっていて、それを達成することがとりあえずのアウトプットの形で、自分で達成度合いを確認することができた。

それが今は、タスクを積み上げてそれに対してスケジュールを大体で決めて進めているけど、別にそれが遅れたからといって誰も困る訳ではないので、スケジュールを守ろうとが守るまいが、あまりインパクトがない。もちろん同じスケジュールならアウトプットは多い方がいいのだろうが、それによって何か変わるようなことは今は出来ていない。そういうものを自分でコミットしてやらないといけないのだろうなぁと思うのだが、方法がまだ確立出来ていない。

２つ目は「社内にシェアしてもそれが現場で本当に意味があるのか」が分からない点。

特に社内で共有会をやっていて思うのだが、基本的に社内のエンジニアにシェアしても大して反応は無いし、それがすぐに社内のサービスに影響を与えるということもない。

もちろん、仮に社外の勉強会に参加した所でそれがすぐに仕事に影響することなんて無いわけで、長期的に見て資産になれば良いだけのことである。それでも、業務に直接関係しなさそうなImmutable Infrastructure系の話とかCIの話だったりをしても全然反応がないのが若干辛い。基本的には社内で使ってないが、選択肢として覚えておいてもらいたい話題をチョイスしているのだが、業務時間にやっている以上は、もう少し現場に近いものをやった方がいいのか、それとも今のサービスが大きくなって負荷分散やソースの整理をしなければいけない事態になった時のことを考慮して選んだ方がいいのか。

いずれにせよ、自分は今の会社では若造の方なので、自分より年上のエンジニア達に話を聴いてもらうのは色々と工夫が必要であるということはよくわかった。基本的に３０を過ぎたエンジニアに新しい技術をインプットさせるのは相当な工夫がいるようなので、今後は巻き込み方とか、会の在り方とか色々考えていかなければいけないと感じている。

世の中の企業の研究職やR&D職の人もこんなジレンマと闘いながら業務にあたっているのだろうか。

10年後もプログラマとして働き続けるために考えていること

クロノトリガーは、確か自分が中１だか中２だかの頃に、偶然ハードオフで見つけて中古で買い、何周も何周もプレイした思い入れのある作品だ。

当時、既に発売から何年も経っていたから、周りの同級生とクロノトリガーを話題にしたことはなかったが、テキストとドット絵の、今考えたら制約の多い手法で表現される、時には熱い戦いに胸が踊り、時には辛い別れに涙する素晴らしい世界観に自分はめちゃくちゃハマり、主要な台詞を殆んど覚えるほどやりこんだ。気がつけば全員のレベルを★★（カンスト値）にするまで何周もやり込んだ。

そんなクロノトリガーで、今でも時々思い返す台詞（というかスクリプト）がある。物語序盤、中世で攫われたリーネ王妃を救うために向かったマノリア修道院のドア横に突然現れる「はりがみ」にこんなことが書いてある

行こうと心に決めた者のみが行ける道がある。

 物語の本筋と関係があるんだか無いんだか、良く分からない形で突然現れるこのはりがみ。

誰が、一体何のために書いたのかは劇中で触れられていないが、この言葉だけは初プレイから何年経っても時々思い返す。思い返すどころか、年を取れば取るほど重く感じるようになってきている。

突然話が変わるが、プログラマというのは特殊な職業なのだろうか、ということをよく考える。プログラマをどう定義するのかによるが、ここでは「業務としてコードを書く機会がある」人のことをプログラマとして定義したい。つまり、ITエンジニアという肩書だが、業務で全くコードを書かない人はそれに該当しないとしたい。

自分は今は仕事としてコードを書いている。最近、サービス開発の現場からは一歩退いて、プロジェクト横断で後方支援的なことをメインにやるようになったため、以前より書く量は減ったが、技術検証やテストコードの整備などで毎日何がしかコードを書いてコミットしている。また開発現場に戻るかも知れないが、少なくともプログラマとしてコードを書いて仕事をし続けたり、新しい技術を学び続けることに何の疑いもないし、１０年、２０年経っても続けていくつもりでいる。

しかし、１０年、２０年とプログラマをやっている人って、自分が知るかぎりではかなり少ない。自分の身近な存在で挙げると、17年プログラマとして働いている先輩が１人いるくらいだ。業界自体が若い、なんて話もあるが、仕事としてプログラムを書いていた人は1960年代から存在していたようなので（「闘うプログラマー」参照）、10年間仕事でコードを書き続けている人がいてもおかしくはない。

一方で、「元プログラマ」とか「元SE」みたいな人は大勢いる。別にそれが悪いということは無い。一度でもコードを書いて飯を食うことで見えてくることは沢山あるだろうし、それを元に別の分野で活躍できるのは素晴らしいことだと思う。

また、３０代、４０代になった時に、プログラマという立場でどういうアウトプットができればいいのかが今時点では分からない。前述の通り、ロールモデルが殆んど無いし、かといって今（プログラマ歴は丸2年と少し）と同じアウトプットで良い訳がない。もしそうなってしまったら他の人に取って代わられるだけだ。

そういう意味で、プログラマは続けるのが難しい「特殊な仕事」なのではないか、なんてこと考えるようになった。サラリーマンというよりはスポーツ選手のような印象を持っている。常に自分を磨き続けなければ脱落していく。1年後に仕事で今以上の高いアウトプットを出そうと思ったらこの1年間相当量のインプットとアウトプットを残さなければならない。そうしないと少なくともプログラミングのスキルは伸びないからだ。

例えば、今業務でやっているサービスの保守は出来ている。

しかし、新しい事業が立ち上がって、そのチームの唯一のプログラマとしてアサインされた時、1人でサービスの根幹を作ることが出来るか？使うフレームワークを自分で選べるか？AWSでVPC設定してEC2とELBとRDSを設定して最小限のインフラを構築できるか？出来ないとしたら、素早く習得できるだけの土台があるか？考えだすとキリがない。

今の仕事が出来ているから1年後も安泰、なんての昨今IT業界全般で言われる通り幻想である（これはITに限らないだろうけど）。ITエンジニアにとってどんどん必要なスキルは増えていく。必死で着いていかなければならない。辛いと思う人もいるだろうし、昨年入社したうちの会社の新卒諸氏は覚えることが多すぎて早くもしんどそうだ。

それでも自分は、プログラマとして働き続けようと思う。

なんでそう思えるのかと長いこと色々考えたけど、結局「好きだから」、に尽きるように思う。

自分は上流SEからプログラマに「転職」してからまだ2年と少ししか経ってないが、コードを書くこと、使ったことがないミドルウェアを使えるようになること、チームのタスクをマネジメントすること、誰かの問題を解決をするために頭を悩ませること、他のメンバーを育てること、全部含めてプログラマとしての仕事が心底好きだし、何よりwebで多くの人に「こいつぁすげぇや！」と驚き、喜んでもらえると凄く嬉しい。

だから「この道を行こう」と決めた。

「好きだから」でどこまで行けるか分からないが、今は新人教育やインフラ側・アプリ側双方での技術検証とかの仕事も始めて、前よりは仕事の幅が広がりつつある。その中で、自分が今どういうアウトプットが出来る人間かを考えて、そこからどうなりたいかということを模索していきたいと思う。

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

概要

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

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

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

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

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

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

特に以下の部分

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

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

全くその通りだと思う。

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

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

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

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

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

・何がしたいのか

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ボ カ ロ で 懐 か し い 名 曲 は

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

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

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

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