最近はGithub会議に参加したりRailsの勉強したり色々としている。
RailsのERDをModelから自動生成するrails-erdで生成されるERがあまり良い感じではないのでもう少し良くできないか、テーブル情報取れるんならテーブル定義書みたいなものを自動生成できるんじゃいの？とか色々調べたりサンプル作りまくったり。
#渋谷java を運営し始めて一年ぐらいが過ぎた
#渋谷javaという勉強会を去年の6月から２ヶ月置きぐらいの頻度で自社の会議室を使って開催している。つい先日の土曜日に第六回を行った。稚拙ながら自分もゆるふわなLTをさせてもらった。
なんだかんだで一年近く続けてきた訳だが、この勉強会を始めた動機はたいそうなものではない。
javaでweb開発する会社に入社し、オフィスを引っ越して、３０人ぐらいは入れそうな広い会議スペースが出来たのが去年の丁度６月ぐらいの時期。
折角広いスペースが出来たのでなにかやりたい、ということで上司に頼んで勉強会をさせてもらうことにした。javaを選んだのは弊社がjavaでweb開発をする会社だったので多少なりとも自社のアピールが出来ればと思ったのと、自分がLTしたかったのと、shibuya.rbやshibuya.pmがあるのにjavaは無かったのでじゃあ作ってしまえと思った程度の理由だ。
気がつけば、毎回募集すると定員の35名を大きく超える応募があって補欠待ちが常にいたり、１日で全枠埋まったりとそれなりに好評をいただいている。
「○○.java」とかいう今どきのチャラい名前をつけたので若者しか来ないかなと思ったら、初回から「java歴10年です」「java歴15年です」「java1.1から触ってます」「mavenセントラルで公開してるjavaのOSSコミッタです」「Seaserの某ORMのコミッタです」、とかいうマサカリ担いだモヒカンレベルの人がゴロゴロやってきて超絶コアな話をしてくれている。その一方で自分は細々とライブラリやフレームワーク紹介をしたりポエムを披露したりしているので恐ろしくしょっぱい。。
果ては「groovyコミュから来ました」「scalaコミュから来ました」「JJUG運営から来ました」「kotolinエヴァンジェリストです」みたいな感じで色んな所から色んな人が訪れるようになって、毎回想像もつかない多様な内容のLTをして頂き大いに刺激になっている。そのうちの何人かとは仲良くなってプライベートで飲んだりするようになったのだから人の縁とは不思議なものである。
他言語の勉強会だとこういうコアな話をしまくる勉強会って結構あるものだが（特にrubyは)、javaにおいては他に自分は知らないし行ったことがない。そんなせいもあってか、普段からjavaを使い倒してる人達にとっては情報共有をするための場が不足していて、その飢餓感みたいなものが渋谷javaに集中しているのではなかろうか、と勝手に想像していて、その役割を担えているのであれば光栄なことだと思う。
ただ、java自体にそれほど新しい話題が無いのは事実で、java8が出てもいまいち盛り上がらないし、真新しいWeb Frameworkやライブラリがある訳でもないので、どこまでこの勢いが持続できるか分からない。ただ、まだまだ来る人来る人ネタを沢山お持ちのようなので、人がいなくなるまでは続けていきたいし、若者を呼びこむために初心者向けっぽいネタも体を張って提供していけたらと思っている。
人にプログラミングを出来るようにする方法
新卒教育でjavascriptを担当してたりするのだが、どうにもこうにも、自分が全くの初心者だった頃に、どうやって覚えたのか全然分からなくて困っている。
記憶にあるのは、初めてまともに勉強したプログラミング言語であるPHPの勉強ととほぼ平行して「javascript実践入門」を頭から読みまくってサンプルコードを片っ端から写経しまくって、prototypeこえー、window.onloadっておまじないじゃなかったんだー、と思った記憶ぐらいで、あとは必要に応じてググったり、jQueryだけは他の本を読んだりしてカバーしてきた。何だかんだ言ってwebのフロントエンドjsしか書いてこなかったせいもあるのかも知れないが、殆んどjsでつまづいた記憶が無い。そのせいで「jsなんぞ本読んどけば勝手にできるようになるじゃろ」という認識だったのだが、人間都合の良いことしか覚えてないだけなのだろうか。
そもそもプログラミングで躓いたというか挫折したみたいな経験をした記憶が無く、自然と他の人や本やwebで知識を得たり、人のコードを読んで自分で書いて動かして、実際のプログラムの動作と理論をリンクさせていき、そこからさらに抽象化した概念マップみたいなものを頭のなかで充実させていく作業の繰り返しみたいなことを通じて身についていったものなので、まっさらな人にどうやって教えればできるようになるのか。これが非常に難しく感じている。
プログラミングに限らず自分の場合はIT全般のスキルはみんなそうやって身に付けてて、例えばDBにしてもNWにしても、新卒で入った会社の詰め込みスパルタ教育を受けていた時も、「楽しいー！やっべー！ITすげー！」みたいな感じで勉強しまくってて、毎日やっている確認用ペーパーテストとプロジェクト演習の成績で同期で1位の成績だったらしいのだが（勿論現場に入れば分からないことだらけで凹んだが）、苦労して覚えるというか、イヤイヤ覚えるというか、そういう経験をITに関してはほぼしたことがない（強いて言えば情処の為に簿記を覚えたぐらいか）。
全くプログラミングの経験がない人間に教える事ができないのは自分の大きな課題とも言える。まずは目の前の新卒に、現場で困らないレベルの最低限のjsのレベルまで引き上げることが第一歩だろうと考えている。
近況
特に大きな変化はないのだけれど書いておく。
今
開発現場から離れてプロジェクト横断的に技術サポートをしたり今どきのプロダクトを検証したりしている。あとは細々とした雑用。
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で多くの人に「こいつぁすげぇや！」と驚き、喜んでもらえると凄く嬉しい。
だから「この道を行こう」と決めた。
「好きだから」でどこまで行けるか分からないが、今は新人教育やインフラ側・アプリ側双方での技術検証とかの仕事も始めて、前よりは仕事の幅が広がりつつある。その中で、自分が今どういうアウトプットが出来る人間かを考えて、そこからどうなりたいかということを模索していきたいと思う。
