Studio3104::BLOG.new

uninitialized constant Studio3104 (NameError)

2012振り返り


もう1月3日になってしまいました。
あけましておめでとうございます。
2012年を振り返り、2013年はどういった年にしたいかということをまとめます。

勉強会

勉強会に参加するようになったのは、確か2011年の秋ごろからだったような気がします。
きっかけは、元同僚で今はN●N Japanの旧lived●●rのところにいる@に、「おまえエンジニアのくせに勉強会行かないとか死ぬかキャリアチェンジ考えろよ」的なハードなアドバイスをいただいたからですね。
まぁいずれにしても彼にハッパかけられたことをとても感謝しています。

LT

まとめてみると、5本しかライトニングトークしてませんでした。
もっといっぱいしているつもりでいたんですけどね・・・
ただ、人生初のライトニングトークが5月末のMySQL Beginners Talkでしたし、半年で5本というのは悪いペースではないかなという気もします。
2013年も同じペースでやっていこうと思います。

発表

ライトニングトークではない発表は2本。
Perl Beginnersは少し特殊で、ビギナーが思いのままに聴衆に質問できるビギナーズセッションというのがあり、それに参加しました。
Perlを始めて数ヶ月の頃で、手探りで書いたコードを晒して色々アドバイスをいただいたりリファクタリングしていただいたりしました。
Fluentd meetupでは、「ライトニングトークで参加出来たらしたいなー」とか思っていたところ、開発者の古橋さんに「ブログ見ました。発表しません?」みたいにお声がけいただき、25分お話させていただきました。
2013年はライトニングトーク以外の長時間の発表を2本やることを目標にします。

主催

もにかじの第二回と、おぺかじを主催しました。
勉強会の主催ってものすごく大変です。
開催側にまわってみて、いつも参加させていただいている勉強会を運営されている方々の苦労がわかり、感謝、尊敬せずにはいられません。
2013年も主催運営側で勉強会に携わろうと思います。最低1本。

Monitoring Casual Talk

もじかじは2012年で1番インパクトのあったイベントと言っても過言ではないかも知れません。
第一回のもにかじではじめましてした方々に、テクニカルなアドバイスをいただいたり、キャリアについての相談に乗っていただいたりしましたし、もにかじがなかったら起こらなかったことがありすぎるなぁと改めて振り返ると強く感じます。
第二回の主催は、第一回主催の@さんにIRCでムチャぶりされてイヤイヤ引き受けたのですが、コレが本当にいい経験になりました*1
コレがなかったらおぺかじをやろうというモチベーションは沸かなかったですし、そういえばおぺかじの登壇者はほとんどが第一回もにかじではじめましてでした。
色々といい影響を与えてくださっている@さんですが、僕と若干キャラがかぶってる感あるので2013年の早いうちに潰しておこうと思っています。

Fluentd

なんと言っても2012年はコレに尽きます。
MongoDBやRedisを気軽に使ってみるきっかけになりましたし、なによりFluentdドリヴンでコードを書くようになったことがデカイ。
最初はout_exec_filter用のフィルタリングスクリプトPerlで書くというところから始めて、最近ではAWS APIを叩くコードをRubyで書いたりしています。
pullreqを通して @kentaro さんに教わったこと - Studio3104::BLOG.newで本体のコードを読んで実装が少しわかるようになった気がしています。
間もなくv11がリリースされようとしていますが、いつか僕も本家にコミット出来るように、どんどんコード書きまくってコーディング能力を向上させたい次第です。

刺さった言葉

Openness is our driver for excellence

YAPC::Asia 2012での@さんのお言葉です。
オープンにすることで素晴らしいことに繋がるということを実体験を交えてお話してくださいました。
例えばPerl Beginnersでは、稚拙なコードを晒したことによってリファクタリングしていただいたり、色々なアドバイスをいただくことが出来ました。
僕の場合は、稚拙なコードやオペレーションを晒したことによって、優秀な方々に色々なアドバイスをいただくことが出来ましたが、@さんはSqale の裏側で、Sqaleの設計や実装について「そこまで話してまっていいの!?」というところまで語られていました。
2013年は僕も何かをオープンにすることによって人に影響を与えられたらいいなと思っておりますので、オープンマインドは常に意識しようと思います。

古典的でも地道にやる

YAPC::Asia 2012での@さんのお言葉です。
例えばなるべくIOさせないなど、古典的で地味と思われることを地道にやることで平均応答時間50msという大きな成果を得ることが出来たそうです。
そのころの僕は、なんとかく効果が出そうだという曖昧な理由で、適しているかどうかの検証も不十分なままRedisやMySQL Clusterをプロダクション環境で使おうと考えていたような気がします、、
この言葉を聞いて頭を思いっきりぶん殴られたような気がしました。
キャッシュを有効に使うとか、キューにまわすなど、なんとなくの理解でうまく使えていなかったのでコレをきっかけにしっかり勉強し直すなどしました。

自分を何と呼ぶか → 「自分は何をする人か」という自意識に影響を与える

おぺかじでの@さんのお言葉です。
「コード書くインフラエンジニアになりたい!カッコイイ!とか思ってない?」ってスライドがあって、ドキッとしました・・・思ってた・・・
「自分は"インフラエンジニア"なのだからコード書く必要はない」ではなくて、「自分は何をどう解決する人なのか」を考えるべきとのお話でした。
実際に僕はそうやってコードを書いている"インフラエンジニア"が特別でカッコイイと思っていましたが本質はそこじゃなかったんですね。
というかあの発表は運用系エンジニアだけでなく全ITエンジニアに観てもらいたいと思いました。
ので動画をどうぞ。意識酔い注意。Operation Engineers' Casual Talks - YouTube


2013年の目標

・技術的知見はTwitterなどで垂れ流し、教えてもらいっぱなしではなくてこまめにブログエントリにまとめる
ビジネスロジックを含まないコードはまずGitHubに上げる
・LT10本以上、トーク2本以上やる

以上を2013年の目標として設定します。
なんかゆるいような気もしますが、これらのことに気づき実行し始めたのが2012年の後半からなので引き続きでもいいかなと。
ブログ書くのとか、LTの資料作るのってものすごくエネルギーが必要ですし。
僕は文章力がないし、書くのが遅いのでそれによって修行できれば一石二鳥です。

海外でテックトークしたいという気持ちもありますが、僕一人の収入で家族4人がメシ食ってるので自費でやるのは経済的にかなり厳しい。
なので会社がスポンサードしてくれれば、2013年のどこかでやりたいと思っています。
会社がお金出せないよーということになる可能性は結構高いので、ブログや発表、GitHubなどでどんどんアウトプットして、2013年は厳しそうですが、2014年には呼んでいただけるように実績を積んでいく年にするのもいいかなーと思っていますが、まだ考えまだ甘いですかね・・・?

まとめ:他人に良い影響をあたえられるようなエンジニアを目指します。

*1:共催の@さんになにからなにまでほとんどやってもらったのが実際のところ