あらみそかもすぞ

まじめにふまじめ

YAPC::Asia Tokyo 2015 に行ってきた！

ペパボの新卒5期生エンジニアは全員YAPC::Asiaに参加させていただきました！わっしょい、ありがとうございます。

YAPC::AsiaはPerlのカンファレンス、ときき初参加のわたしは「Perl全然知らないんだけど大丈夫なのかな…」と非常に心配だったんですが、杞憂でした！ エンジニアのためのお祭り、という雰囲気で、言語に縛られないようなセッションもたくさんあったので、学びしかない3日間になりました。 ブログを書くまでがYAPCということで、感想をつれづれ書きます。

前夜祭

言語開発の現場@hsbtさん

Rubyにまつわるあれこれ話をされていました。

Rubyの他に、JRubyやRubiniusといったものがあるという話は知っていましたが（新卒研修で初めて知った）、普段よんでいるRubyはCでかかれたものでCRubyなるものだった、という話は知らなかったので、とても衝撃をうけました。 また、Rubyコミッターのスタンス（領域は特にわけず、やるなら最後まで面倒をみる）や機能追加のときはエンジニアがどう嬉しいかといったところから始まる、という中の人ならではのお話がたくさん。

日頃お世話になっている技術も、誰かが開発してくれてその恩恵をうけているんだ、ということを改めて認識しました。 今はたくさんの恩恵をうけるばかりですが、小さなコントリビュートチャンスを探すところからはじめて、少しずつ貢献できるようなひとになりたいなあ。イカしたエンジニアになりたいなあ。

はてなブックマークのトピックページの裏側@skozawaさん

トピックページをどうやったらうまくまとめることができるかという話。

たくさんの記事から、うまく共通点をみつけだしてまとめていったり、タイトルをつけたり、ということを解決するのですが、現場のエンジニアさんがどういうことに困って、どうやって立ち向かったかということが順を追って説明されていたので、わかりやすくとてもおもしろかったです。 こういったアルゴリズムを考えるのは苦手分野なので、その試行錯誤の過程をきけるのは嬉しいです。 YAPCすごいなあ〜。

技術ブログを書くことについて語るときに僕の語ること@yuukiさん

はてブをいかに稼ぐか、という話と思ってたら、ブログによってどれだけエンジニアが幸せになれるか、というとてつもなくエモい話でした。 とても面白い発表でじっくりきいていたら全然メモが残っていなかった挙句、資料がない…うーん冷や汗。 書いたものを1日寝かせて、というものは今のわたしには無理そうなので、ブログにかけそうなネタをきちんとためておく、というのを真似しようと思いました！

1日目

メリークリスマス!@Larry Wallさん

Perlの歴史をトールキンの作品を例えにして話をされていました。 Perlのことも、トールキンの作品のこともあまり理解できていなかったので、会場が笑っていてもわからず…たいへんだめだめでした（そもそもPerlの祭典なのにPerlのこと全然知らないのが絶対まずかった！）。 でも同時通訳で発表が進められているのにはとても感動しました。 突然コードリーディングがはじまっても、通訳さんがきちんと翻訳してくださっていて、びっくりです。 技術者な通訳さんがいらっしゃるんでしょうか…すごい！

Web由来の組み込みエンジニアの半年間のすべて 〜WebとiOSとBLEとハードウェアデバイスのこと〜@Kazuhiro Hommaさん

「世の中で一番ハックされてないものはなに？」「鍵じゃない？」という点からはじまったという、Akerunの開発についてのお話でした。

もともとWeb開発を行っていたエンジニアが組み込みエンジニアとして仕事をこなしていくときに工夫した点や、必要な知識といったところが主だったところだったのですが、「わからないこと・自信のないことはプロに相談する」という点が一番わたしにひびきました。 普段、話をききたいエンジニアさんがいても声をかけることができなくても、仕事で困っていて解決の糸口になりそうなエンジニアさんがいるなら、何が何でも声をかけるくらいがんばれます（仕事だから解決できないととても困る…！）。 この、気になるエンジニアさんに会う理由ができるというのにはなるほどな〜と思いました。

TBD@Matzさん

Rubyじゃない話かと思ったらやっぱりRubyの話だった話。

いろいろなことをきいたのですが、一番印象に残ったのは振り子の話です。 パフォーマンスと生産性は振り子の関係になっている、というものです。 昔は早く動くためならなんでもやっていて、次に人間が書きやすい言語が求められた。 すると今はパフォーマンスのよい言語が求められて…。 パフォーマンスと生産性の2つをジグザグしながら徐々によりよくなっていくのかなあ。

TBDってなんだろう？あたらしい技術用語かな？って思ってたんですが、未確定なものにつけるものなんですね。それでTBDのままだ！ってみなさんワイワイしてたのか、と今更気づきました。オソイ。

Perlの上にも三年 〜 ずっとイケてるサービスを作り続ける技術 〜@hitode909さん

はてなブログのフレームワークの歴史を辿りながら、設計について考えていく話。

3回コピペしたら共通化してコピペ解消会場へ送る、といったどんな風に開発をしていたという話がきけてとても新鮮でした。

それからユビキタス言語(チームで共有する言語)の話が好きでした。 チームでの、普段の会話もコードでも同じ言葉を使うのだそうです。 そういえば、よく日本語の機能のものを無理やり英語になおして機能をつくったりしたけど、どの機能のことがわからなくなって混乱した記憶があるので、もうそんなことは少なくなるのかな、と思うとドメイン駆動開発がとても気になってきました。 名前しか聞いたことなかったのだけれど、ちょっと勉強してみようかな！

うっかりをなくす技術@karupaneruraさん

うっかりミスは人間だから誰にでもおこるから、なんとかそのうっかりを管理する話でした。

うっかりミスは以下の3つの要因によっておこり、 - 人的要因 - マネジメント要因 - 環境要因 このうち、環境要因は技術と相性がよいそうです。 マネジメント要因はワークフローを改善したり、自動化によって抑えることができます。 次に環境要因は手段をシンプルにするように改善することで抑えることができます。 ニアミス、ヒヤリ・ハットを防ぐことで、重大なミスを防ぐことに繋げていくのがよいそうです。

リーダブルコード、また読もう。その前に手元にないからとりあえず、ぽちろう。 また、すぐうっかりミスをやらかしてしまうので、linterいれたりうっかりを機械が少しでも軽減してくれるように環境を整備しておかなければ、と思いました。

2日目

3分でサービスのOSを入れ替える技術@hsbtさん

3ヶ月でCMを打っても耐えられるようなインフラを整える話。

実際の現場ではどのようになっているか、というものを知ることができたのでとても面白いセッションでした。 はじめから自動化するのではなく、秘伝のタレをコードにしてから自動化するといった、それぞれの段階で必要な技術を投入するという方針は変わらないんだなあと気づけたので、エンジニア研修ではきっと大事なことを学んだんだと改めてふりかえるきっかけになりました。

辛いことをやめる！から始まる業務改善とInfrastructure as Code@koemuさん

時代遅れが増えるとつらくなる→新しいことをはじめるのがつらくなる→より時代遅れつらい→…という悪循環がきまるととてもつらくなる。ということでつらいことをやめて、業務改善をはかっていく話。

新しいことをはじめるとき、抵抗勢力はつきもの。 そういうときには対立するのではなくて、変化するとどんなメリットがあるのか説明をしたり、うまく重要人物を巻き込んでいったり、とうまく立ちまわっていこう、というスタンスがとても好きでした。 いっしょに仕事をしていく仲間ですし、やっぱりうまくのびのび働いた方が健全で素敵だなあと思うのです。

それから、導入から本編から質疑応答まで、ほんとに洗練されたセッションでした…とてもモチベーションがわきました。これが巻き込み力なのかな…かっこいいな〜！！

しょかん

とてもエモくてあつくて最高な3日間でした。 たくさんかっこいいエンジニアさんをみてきいて、最高にテンションMAXになれました。 LTも楽しかったな〜、あんなにお祭りさわぎなLTはじめてみた。スリスリ。

そういえば、セッションを選ぶとき、面白そうなやつ！という軽い気持ちで選んでいたのですが、けっこうインフラまわりのセッションをきいていることに気づいて驚きでした。 エンジニア研修をうける前のわたしだったら（サッパリ何もわからなかったのもあるけど）避けてしまっていたと思います。 この数カ月でほんのちょっぴりでも幅を広げられてるのかなあと実感することができて、モチベーションあがりました〜！

最後になりましたが、スタッフのみなさま、ほんとうにお疲れさまでした〜！最高の3日間をありがとうございました！！