クフでダローバルな日記

タフでもグローバルもない

AWS Summit Tokyo 2019 に行ってきた

2019/6/14 に AWS Summit Tokyo 2019 day 3 に行ってきました。 雑に感想とかを書きます。

備えあれば憂いなし!AWS上のシステム本番稼働前に必ずチェックしたい4つのポイント

Scrapbox メモ

内容

本番環境で可動を始めた際によくある失敗3パターンについてその原因を4つのテーマに分類。それらに対する応急処置方法と備え方。

感想

稼働後だと手遅れになりがちなミスについてよくまとまっている。今後、自分でなにかを AWS 上で動かす際には参考にしたい。

また、S3のバケットに対するブロックパブリックアクセス機能などの新機能の紹介も参考になった。本番稼働前にチェックすべき項目は今後も増えていきそうなので、毎年見直したい気持ちになった。

サービスメッシュは本当に必要なのか、何を解決するのか

Scrapbox メモ

内容

マイクロサービス化に伴う辛さとその解決方法としてのサービスメッシュについての考察

感想

あまりマイクロサービス知見がなかったので、今回見た中で一番おもしろかった。というのも、モノリスの状態からマイクロサービスに夢を見て、結局楽園がないことを知るというストーリーがわかりやすかったので。 では楽園がない中でどうするのか?という問に対し、サービスメッシュに限らず複数の選択肢が提示されていて良い。

マイクロサービスアーキテクチャを採用するのであれば、つらさ知見がまとまり始めた今見る資料としてかなり参考になると思う。

EC2 スポットインスタンスのすべて

Scrapbox メモ

内容

スポットインスタンスはどれくらい安いのか?どのようなユースケースで使えるのか?使い方は?

感想

中断しうるものであればかなり安く済みそうだが、中断しうるという要件はかなり大変そうな気がする。紹介されていたように、機械学習などで使うのはまあ分かる。

スポットインスタンス事例を集めて、自分に当てはまるユースケース見つけてみようかなあという気持ちになった。

めざせ!サーバーレスプロフェッショナル

Scrapbox メモ

内容

AWS Serverless の各要素は管理が大変なので AWS SAM を使って管理しましょう。

感想

サーバーレスのプロというよりは、 AWS Serverless 管理のプロという感じで、今あまり AWS Serverless を使っていない自分にはあまり良さがわからんかった。弊社でも terraform で管理してるので、コード管理したいというモチベーションはわかる。

最後にちらっと紹介されてた Serverless デザインパターンはかなり有用そう。むしろあれだけで別に40分話してほしかったレベル。

その他感想

  • Startup Architecture of the year が面白そうだった。来年は見たい。
  • サイレント講演、かなり聞きやすくて好き。
  • お昼の時間はみんな弁当目当てで部屋入ってるので、企業ブースとかが空いてる。

積極採用中です

DevOpsで顧客に素早く価値を届けたいSREエンジニア募集! - 株式会社HERP 日本の採用を変えるプロダクトを作るPMを募集! - 株式会社HERP

HERPY HOUR みたいなお酒飲むイベントもあるので来てね。

東京大学大学院を退学し、株式会社HERPにエンジニアとして就職しました

経緯

  • 2017年4月に東京大学工学系研究科に入学したが、同10月から休学していた
  • 12月17日に株式会社HERPに社員としてジョインした
  • 7月30日をもって同研究科を正式に退学した

はじめに

伝えたいことはほとんどタイトルで終わっています。30文字を目安にタイトルを決めているため簡潔にしてありますが、字数制限を気にしないタイトルを付けるのであれば、「東大院に入った俺が研究室から逃げ出してスタートアップで無双してる件」といった感じでしょうか。
この記事を書こうと思い立ったときにはちゃんとポエティックに自分の感情の移り変わりを書こうと思っていたのですが、エモい文章を書くのが苦手なので、このエントリでは自分のキャリア選択における後悔および自分への祝福を中心に、この1年ほどの話を述べます。
なお、記事を公開する目的はすべて「おわりに」に書いてあるので、以下の2節は読み飛ばしてくださって構わないです。

なお、このエントリは私用の Scrapbox で(酒を飲みながら)書いたものをほとんど流用しており、箇条書きを多用した形式になっているため、はてなブログとして読みやすい形式ではないと思われます。ご了承下さい。

後悔

  • 自分の好みと自分のキャリア選択を一致させるべきだった
    • これが最大の後悔
      • 僕は高校一年のときくらいに eeic (東京大学工学部電子情報工学科)に進学することを心に決めていた
      • そのために、本来東京大学のメリットであるはずの進学振り分け(2016年度からは進学選択)前のキャリア見直しを全く享受できなかった
      • 自分で想定しているキャリアパスがあったとしても、自分の嗜好の変化を前提として様々な観点から検証すべきだった
    • 研究室選択においては顕著
      • 自分はモノづくりが好きだと思っていたので HCI という分野を選んだ
      • 実際に始めてみるとプロトタイピングやユーザーインタビューが主であるHCIより、プログラミング言語それ自体の良し悪しやソフトウェア工学といった、歴史的/理論的バックグラウンドが深そうな分野のほうが好きなのだと思った
        • これは単純に勉強は好きだけど研究は苦手という「大学までの人」らしい性質の発露であることは否定できない
        • ここで挙げた二分野であっても、研究を始めた見たら無理になって退学する未来が容易に見える
      • 研究分野の向き不向き以前に、研究という行為自体への向き不向きを、大学院進学前に検証すべき
  • 自分の目標とその達成手段を頻繁に見直すべきだった
    • 前項をより一般化した後悔かも
    • 自分の一旦の目標は中学3年生の頃から昨年に至るまで、Googleにソフトウェアエンジニアとして就職することだった
    • 昨年度、Google でエンジニアインターンと働けた
      • エンジニアとしては天国みたいな環境だと思った
      • しかし自分の能力や指向性を鑑みると、能力の高いエンジニアが無数にいる Google では、自分が前に出て何かをやるのは不可能だろうと思われた
        • ただ、チームリーダーの方から「普通インターン生はもっとナーバスになるものだけど、君は初週から緊張してなくてすごいね」と言われたのは嬉しかった。
        • メンターの方は(少し変わった方だったが)とてもいい人だったしいろいろ学ばせていただいたと思う。周囲の方もめちゃくちゃ勉強になる話をしてくれたのでとても充実した3ヶ月だった。
        • 最高の環境だったけど、自分が力になれる気がしなくて怖気づいてしまった
    • そもそも中3時点の目標は夢でしかなく、その先の夢や目標も都度更新しないとどこかで頭打ちになると思い知った
  • 退学したいという反動から気軽にスタートアップ企業を選んでしまった
    • スタートアップは無数にある
      • 無数にある中でも有望そうなスタートアップはたくさんある
        • 自分がなんでそのスタートアップを選んだのかは、入社前に自分で明確化しておいたほうが良い
    • 自分がそのスタートアップで勉強したい分野をはっきりさせておくべきだった
      • スタートアップは、確かに勉強になる
      • だが、下手すると流されて自分のしたくない作業をすることになるので、前もってはっきりさせておいたほうが良い
        • 幸いなことに僕は、会社にとって必要だろうと思われたことと僕が個人的に興味を持ったこととが一致していたので特に不満はないが、運が良かっただけ
        • 多くのキャリアについて述べた言説は生存バイアスが強いので話半分に聞くしか無い

祝福

  • パッと就職先を選んだ
    • HERP のエンジニア組織は、より良いプログラミングパラダイムへの探究心が強い
      • Functional Programing や Reactive Programming などの先進的なパラダイムを取り入れている
      • 僕が学習者ながらも採用を提案した、テスト駆動にするための DI/Hexiagonal Architecture も導入してくれた
    • 不完全な組織ではあった
      • 創設1年目のスタートアップなので仕方ないことではあるが、組織として不十分なところはあったと思う
      • たまたま自分の入社直後にそれを振り返る機会があったし、そもそも「振り返り」という手法自体もなかったので、自分が先導をとってXPやアジャイルの手法を取り入れられたのはいい経験になったと思う
    • HERP の実現しようとしている世界が、キャリアに悩むエンジニアとして魅力的だった
      • エージェントや媒体企業が過剰な(と僕は感じる)利潤を得ており、企業や転職者が相対的な損失を被る仕組みは間違ってるように思った
  • 担当教官は最高だった
    • 純粋に自分の能力がなく、かつ分野にもマッチしていなかっただけで、担当教員のサポートは手厚かった
    • 担当教員はこれまでの人生で出会った中で最も能力的にも人格的にも尊敬する人のうちの一人
      • だからこそ、自分の無能さを感じるところがあったと同期が言っていたがたしかにそうかも
  • 学科で知り合えたメンバーは最高だった
    • 一緒に勉強しようと言えば一緒に勉強してくれ、かつ教えてくれる友人というのはなかなか見つけづらいのではないかと思う
      • 最近過去の自分の供養のために数学を勉強しているが、色んな人が教えてくれるので良い
    • これは主観だけど、進学してから気づいた自分と分野とのミスマッチについても共感してくれる人が多いように思う
      • これについては、学科も研究室も就職先も一緒でしかもライバルであり一緒に切磋琢磨できる同期のエンジニアであるところのAzoson(id: Tak_Yaz)がいたのも大きい
    • コネクションとかネットワークづくりの重要さを痛感した

おわりに

公開前に素面で読み直している今ですら恥ずかしいので、知り合いの各位は適宜飲み会とかに呼んでいじってください。
なお、この記事は一応 退学AdventCalentder 2017 の 21日目の記事です。かなり遅れてしまったことをお詫び申し上げます。

退学祝待ってます http://amzn.asia/dIIBTiz 🙏🙇‍♂️🙏🙇‍♂️🙏🙇‍♂️🙏🙇‍♂️。

また、副業探してるのでWeb軽技術に造詣があってアジャイルなプロダクト開発・ソフトウェアアーキテクチャに知見のある人材が欲しい人、もしくは今はいらないけどいつか手伝って欲しい人はどんどん twitter.com に声かけてください!!!!

ブラウザ拡張の開発をTypeScriptで爆速で始めるやつ作ったので紹介

先日、動画に突然「熱盛」を表示するとかいうクソChrome拡張を作って公開しました。

めっちゃバズって結構インストールしていただけました。うれしい。 やっぱりこういうのは鮮度が大事で、思いついてから公開までを数日にとどめたいところですね。

とはいえ、Chrome拡張機能をシュッと作るためには

  • Chrome拡張の作法に則った設定ファイルの作成 (manifest.jsonなど)
  • ES6/TypeScript や Less/Scss などのトランスパイル自動化
  • 開発版とリリース版の分離

などなど、設定事項が多くてかなり面倒です。

この記事は、 Yeoman を使ってコマンド一発でChrome拡張の雛形を作成する方法の紹介と、そのためのツールをTypeScriptに対応したバージョンを作ったよというお話です。 さっさと試したいって人は chrome-extension-kickstart-typescript を見てください。

Yeoman + Chrome extension kickstart

アプリケーションを作成するために設定が色々必要だという問題は、他の多くのフロントエンドアプリでも共通しています。

この問題を解決するために、Yeoman というプロジェクトがあります。 Yeoman が提唱する “Yeoman workflow” では npm + build system (Gulp/Grunt) + Scaffolding Tool (yo) という3つの要素を用いることで、アプリの雛形をコマンド一発で作成することができます。

$ rails new みたいなものですね。

yo では npm 上に公開されている generator を利用でき、その中にはChrome拡張のためのものもいくつかあります。 特にポピュラーなものは、公式の chrome-extensionchrome-extension-kickstartです(名前がまぎらわしい)。 ただし、後者の方が更新も頻繁であり機能も豊富なので、そちらを使うのが良いかと思います。

Chrome extension kickstart + TypeScript

Chrome extension kickstart では、ES2015をJavascriptに変換してくれるのですが、TypeScriptには対応していません。 ただ、chrome extension は結構 TypeScript との相性が良いので、ぜひとも TypeScript を使いたいところです。
(参考: TypeScript での Chrome 拡張機能開発 Tips - Qiita

今までは、Chrome extension kickstart で雛形を作成し、「generator-chrome-extension-kickstartをtypescriptで使えるようにする - Qiita」を参考にしながらTypeScript用に設定を変更するというステップを踏んでいました。 しかし、そもそもTypeScriptに対応した雛形を作れるべきですよね。

そこで chrome-extension-kickstart をforkして chrome-extension-kickstart-typescriptというものを作成しました。 2017/09/02現在、npmで公開しているのでインストールして使うことができます
(ES2015の雛形との両立ができるようなら本家の方にPRを送るつもりなので、いつか元の方にマージしてもらえてるかもしれません)。

以下で簡単に使い方を紹介するのでぜひ使ってみてください。

使い方

ほぼREADMEに書いてありますが一応書いておきます。

  1. $ npm install -g yo generator-chrome-extension-kickstart-typescript
  2. mkdir my-new-chrome-extension && cd $_
  3. yo chrome-extension-kickstart-typescript (--skip-install)
    --skip-install をつけると自動で npm install が走らないので、yarnとか使いたい人は付けると良いかと思います。

3の yo コマンドを実行すると、いくつか質問が出てくるのでそれに答えればChrome拡張の基本設定は完了です。

設定事項は順に以下のとおりです(公式ドキュメントへのリンクを張ってあります)。

  1. Chrome拡張の名前
  2. Chrome拡張の説明
  3. 使う UI Action (Browser Action or Page Action or 特になし)
  4. Chromeのデフォルトページを書き換えるか? Override Pages
  5. その他の機能を追加するか?
    1. No
    2. Options Page
    3. Devtools Page
    4. Content Scripts
    5. Omnibox
  6. manifest.json に追加する permissions

自分がどのような拡張機能を作りたいのかによって設定も変わってくるので、各設定事項については公式ドキュメントを読むとよいかと思います。 日本語の情報としては、Chrome拡張の開発方法まとめ その1:概念編 - Qiita がとても分かりやすいです。

以上の設定を追えると、雛形が作成されます。 READMEも作成されているので、あとはREADMEを読めば分かるかと思います。 ES2015版の chrome-extension-kickstart とほとんど同じなので、node.jsのモジュールを使ってChrome拡張機能を作る - Qiita が分かりやすいです。

「たまに熱盛が出てしまうextension」はコードをmazamachi/atsumori_chrome_extension - Github で公開しているので、よろしければ参考にしてください。

所感

  • TypeScript 使わないと JS を読み書きできない体になってしまった。
  • 初めて npm に公開したけど $ npm publish としたら一瞬で公開されたのでややびびった。
  • このあいだ誕生日だったので何か買っていただけるとうれしい → ほしいものリスト

学科で Advent Calendar をするということ

この記事は、eeic2015 の自称イベンター(not イベ長)であるところの僕が、次世代のイベンターを募集するための啓蒙ポエムです。

eeic Advent Calendar 2016 その2 の最終日の記事でもあります。

qiita.com

eeic Advent Calendar 2016 総括

eeic Advent Calendar 2016 は今日で終了となります(この文は2016年12月25日に書かれました)。 参加してくださった皆さん、ご協力ありがとうございました & お疲れ様でした。

せっかくなので今年の Advent Calendar について少しだけ振り返ってみようと思います。

学年ごとの延べ参加者数

個人的に気になったので、把握できる範囲で参加者を年度ごとにまとめてみました。 合計が50にならないのは、上の方の世代の方で僕が世代を知らない人が多かったためです。 来年以降は自分の年代書くの必須にしたい。

学年 その1 その2 合計
eeic2010 0 1 1
eeic2011 0 0 0
eeic2012 4 0 4
eeic2013 6 1 7
eeic2014 0 0 0
eeic2015 12 5 17
eeic2016 1 2 3
eeic2017 1 13 14

僕の同期にあたる2015が多いのは納得ですが、2017が想像以上に多くて怖いです。 eeic2017 は技術的にも強そうな記事が多くて本当に怖いのですが一言老害として苦言を申し上げておくと、やや日本語が怪しい傾向にあるのでキレられたくない人は『日本語の作文技術』と『理科系の作文技術』くらいは読みましょう(より具体的に言うならば、この段落を読んで日本語が怪しいと思わなかった人、もしくは怪しいと思っても直し方がわからない人は必ず読んで下さい)。

お忙しい中記事を書いてくださった先輩方、ありがとうございました。eeic2014の方々は僕のこと嫌いなんでしょうか。

ジャンルごとの記事数

記事のジャンルを勝手に分類しました。

ジャンル その1 その2 合計
技術 13 13 26
生き方 5 4 9
eeic・東大関 3 4 7
オタク 2 2 4
その他 2 2 4

ジャンルのばらつきはその1・その2で意外と均等ですね。 今年はオタク枠が少なくてやや悲しい気もします。

話題になった記事

今年の Advent Calendar で一番人気を博した記事は、 id:aerith7 さんの apollo11号のソースコードを読みつつ - aerith7’s blog であることは誰もが認めるところでしょう。 2016年12月26日16時57分時点ではてなブックマーク数は1657記事にも上り、メディア掲載劣化版無断パクリ記事の登場魚拓はこちら) にまで至っています。しゅごい。

eeic Advent Calendar をはじめたワケ

eeic Advent Calendar も二年目を終え、来年以降も続いていくと良いなと思いつつ、定番化すると当初の目的意識が曖昧になることもよくある話なので、ここで僕が Advent Calendar という文化を eeic に輸入した理由を記述として遺しておこうと思います。
理由は大きく分けて3つあるので、以下ではそれらを順番に語っていきます。

学科民にパブリックな記事を書いてほしい

eeicの後期実験の一つである「大規模ソフトウェアを手探る」では、ブログ記事をレポートとして認めることで外部に知見を共有し、自分の苦労とスキルを公開できるという面白い特徴があります。 @Kriver1 の 「LibreOfficeCalcに関数候補表示機能を付けるまで 最終回 LibreOfficeにコミットしてみる - Qiita」 では、この記事を公開したことで LibreOffice のmini Conferenceに招待されています。
この経過を控室で見ていたことや僕自身もブログによって恩恵を得ていたことから、大学外部への発信を通して得られる利益を他の人にも得てほしいという思いがありました。

なので、少し話はそれますが、ブログを書くこと・それが"バズる"ことのメリットについて話したいと思います。

エンジニア向けの自己啓発書として最近話題の『SOFT SKILLS ソフトウェア開発者の人生マニュアル』の第1部「キャリアを築こう」第5章「面接をハッキングするコツ」に次のような一節があります。

次のようなシナリオを想像してみよう。あなたは面接会場に入っていく。面接官と握手すると、面接官があなたを見たあと、一瞬、間をおいてあなたを認識し、顔をほころばせる。「ああ、あなたのことは知っていますよ。ブログで写真を見てますからね。あなたのブログポストはずいぶん読んでいますよ」

面接中にそういうことが起きたら、合格の可能性はどうだろう。(中略)ポイントは、一般に考えられていることとは裏腹に、ほとんどの面接官は、技術以外のあらゆる要素に基づいて人を採用するということである(有名ブログを持つための具体的な方法については第2部で説明する)。

早い話が、ブログがバズると就活などで使えます。
何を意識の高いことを言っているんだと思われるかもしれませんが、多くの人に読んでもらう技術記事を書くために必要な能力は文章力・構成力・テーマの発見能力などなど実用的なスキルセットです。 そういったスキルを身につけられるだけでなく、面接官に自分の強みを履歴書以外の部分でアピールできるのがブログなどの自己発信メディアの強みでしょう。

実体験の話もしておきます。僕はB3の夏にはてなのサマーインターンに行くことを目標にeeic生活を過ごすことにしていたのですが、大量に課せられる課題の影響もありB3の春時点での僕の開発スキルはほとんど初心者レベルで、技術的に自信のある領域などは全くありませんでした。 そこで僕が取った戦略は、はてなapiを使ったWebサービスを作ってブログに公開することでした。 結果的に多くのはてなユーザーの方に使っていただけた上に記事もそこそこバズり、念願のはてなインターンに参加に至ることができました。
実際にこのブログが合格にどれほど作用したのかは聞けませんでしたが、はてな社員の方からこの作ったサービスと記事の話を振られること何度かあったので、「技術以外のあらゆる要素」の一部をアピールできたのではないかと思っています。 技術に自信がない人こそ、ブログなど技術以外の面で自己アピールしていくのは戦略としてアリだと思います。

今年は Advent Calendar に参加を断念した方も、こんなメリットがあることを念頭に置いて来年以降は参加していただけたら企画者冥利に尽きます。 ただしもちろん、そんな意識の高い記事ばかりになってしまうのも面白くないですし、eeicの実態を全く反映しないので、趣味と情熱が振り切れた記事やコンプレックスを露出する記事などもぜひぜひ書いてほしいところです。

外部に eeic を知ってほしい

東大では進学振り分けというシステムによって、学科の人気が如実に可視化されます。 近年の eeic の人気は概ね右肩上がりであり、「人気回復期」であるといえますが、過去の変遷を見る限り、今後もその傾向が続くとは限りません(参考: 東大電気系(eeic)の人気の変遷をたどる - nakachanのブログ)。

eeic の人気回復のために有効だったのは、先生方の尽力ももちろんですが、五月祭における学生主体の展示が大きいと僕は考えています。 だからこそ、今後の人気を維持していく、なおかつ進振り学生と学科のミスマッチを防ぐためにも、eeicがどんな学科なのかを学生主体で発信していくことが必要だと考えました。
今のB2に昨年のAdvent Calendar を読んでいた人がどれほどいるのかは存じ上げないので、結局どれほど効果があったのかはわかりません。 ただ、今年の Advent Calendar を見れば、どんな人が eeic にいるのかが進振り説明会などよりも如実に伝わるのではないでしょうか。

※もし、進振り前から eeic Advent Calendarを見たという人がいたら、聞きたいことがあるので教えてください。

たのしい

僕はよく「理学部情報科学科に行けば良かッた!!」などとたまに愚痴っていますが、結局eeicが好きです。 僕が思う eeic の一番良いところは「他者を楽しませようという気持ちがある」という点で、これは他の学科より明らかに勝っているのではないかと考えています。
これはG3実験やBDMのように講義で発揮されるだけでなく、今年MFAwards学術部門で5連覇を達成した近未来体験でも如実に発揮されています。

この他者を楽しませる・他者の役に立つという性質は、「媚びている」と称されることもあるものの、モノを作って現実社会に還元しようとする工学部の精神に呼応したものでしょう。
僕は今までに学科同期でハッカソン・LT大会・ラボ紹介などを企画していますが、同期が作ってくれるものが楽しみだからこそ企画するモチベーションになっています。 来年以降の Advent Calendar も、楽しい記事を読めることを楽しみにしています。

イベンター募集

上の項で学科でイベントを企画することの楽しさを述べましたが、オタクは場を与えれば参加してくれるものの実際に場を作ろうとする人はあまりいません。 なので誰かが場を設置する必要があるのですが、eeic2016以降の後輩にそういった企画者がいるのかは知りません。
というわけで、いろいろ場所をお膳立てする縁の下のイベンターをこの場で募集しておきます。 やることは大変ではないのですが、僕がこの2年いろいろやった結果オタクを動かすノウハウも少し蓄積されてきたので、今後何かしたいけどやり方がわからんというときはぜひ僕に声をかけてください。出来る限りの協力はします。

ちなみに僕が開催したイベントの振り返りがwikiの僕のページに書いてあるので、そちらも御覧ください。