「n月刊ラムダノート Vol.1」を読んだ

n月間ラムダノート Vol.1, No.1 2019を読みました。 n月刊ラムダノート Vol.1, No.1(2019)（紙書籍＋PDF版）www.lambdanote.com

こんな人におすすめ

今月号は(1) ネットワーク (2) コルーチン (3) 機械学習の3章で構成されており、コンピューターサイエンスの基礎が身についていてもっと知識を深めたい人や機械学習に携わっている人は読むと楽しいと思います。

私の事前知識

マスタリングTCP/IP入門はだいたい理解していて、コルーチンに関しても概要は分かっています。機械学習も、最近kaggleや研究でボチボチやっているので全くの素人ではありません。

#1 TCPの再送制御機構

読むにあたって前提としてマスタリングTCP/IP入門のトランスポート層辺りの知識が必要だと思います。たぶん「トランスポート層の役割」や「輻輳、輻輳制御とは」くらいの質問を聞いてなんとなく分かる人なら読んでて理解できるはずです。

この章はRFCの策定にまつわる歴史的背景に言及してあったりHTTPも意識して書かれていたりするのでとても楽しく読めました。また、タイムアウト値の計測式にマジックナンバーを入れて実測から調整するという話があるなど、結構決め打ちで数値を決めて後から調整するのが多いんかなと感じました。

実は私はここ辺りのネットワーク周りの話が好きなのですがどうやったら活きるんでしょうかね。そういえば動画配信サービスの裏側はこういうところしっかり頑張ってそうなイメージありますね。あとはネットワークハードウェアとかでしょうか。ハードウェア的な処理資源に制約がある分野ってなんか燃えますよね。そういえば知り合いがFPGAでネットワークカード作ってたな。すごい。

トランスポート層って結構分厚いイメージがあるんですよね。OSI参照モデルが役割の違うものを分割して開発しやすくすることがコンセプトだったのにこの層これだけ複雑になって大丈夫なんか更に2層に分かれないのかって感じました。

#2 「コルーチン」とは何だったのか？

コルーチンは、OS入門の参考書でよく出てくるやつです。この辺りの知識は実装ありきで書籍のみに頼った理解が結構難しい部分だと思ったのですが、さすがRubyコミッターとだけあって具体的な実装を交えて分かりやすく説明されています。更にJavaScriptやPythonでの実装への言及もあり、今まで読んだどのコルーチンの説明より分かりやすかったです。

#3 MLOpsの歩き方

この章では機械学習プロダクトの開発と運用に存在しうる問題点とその解決の糸口が紹介されています。

また、この章で「データサイエンティスト vs ソフトウェアエンジニア」としてデータサイエンティストとソフトウェアエンジニアのマインドセットの違いに関して言及されています。データサイエンティストは素早く目的の数値を得るためにクオリティの低いコードを書くことがままあって、ソフトウェアエンジニアはそれを許さず保守性が高いコードを好む人が多い、という違いですね。この溝を埋めるためにGoogleは同じチームにデータサイエンティストとソフトウェアエンジニアを配置しているそうです。

まとめ

とても楽しく読ませていただきました。

1章と2章は普段の開発ではきっと意識することのない部分だと思いますが、知的好奇心が大いに満たされたのでとても良かったです。3章は実際に機械学習プロジェクトを始めるにあたって大いに役立つと思います。ここは今の研究にうまく乗せると面白そうなので検討してみようと思ってます。

「りあクト！ TypeScriptで始めるつらくないReact開発」を読んだ

電子版で読みました。

booth.pm

本の情報

項目	情報
ページ数	188P
章数	全10章
著者	@oukayukaさん

全体的な感想

Webフロントエンドのとても良い教科書です。歴史的背景や思想に関してもしっかり触れられているので、これからWebフロントエンドを触る人は必読と言っても過言ではないのでしょうか。研修として使うのにも非常に有用だと思います。

Railsなどのフルスタックなフレームワークでよく使われるテンプレートエンジンを使ったフロントエンドの構築の限界と、その問題へ対処するためにReactを使うという選択肢に関して説明してあります。なお、RubyやRailsとの対比表現が多かったので、Ruby on Railsを使ったことがある人には読みやすいと思います。

こんな人が読むと良さそう

以下に挙げるキーワードに気になるものがある人は買うと楽しめると思います。

• Reactの思想
• 仮想DOM、コンポーネント指向、単方向データフロー
• HCO
• recompose
• Redux

この本を買った理由

実は、この本の登場人物である秋谷香苗そのままの理由です。サーバーサイドを主にやっていた私がReactを書くことになり、既知の知識では太刀打ちできなかったためです。

自分の開発経験

普段サーバーサイドを触ることが多い人です。が、最近フロントエンドを触る機会がやたらと増えています。

Reactを書いたことはあって、2016年くらいから1年半くらいBoostnoteというOSSでReactを書いてました。しかし「HOC？なにそれ？」みたいな感じのコードを思いつくままに書いていましたって感じだったので、「要件に沿った動作をするコンポーネントは書けるけど綺麗な設計のコードは書けない」というレベルです。なおここ2年くらいはずっとVue.jsを書いていました。

1章

環境構築の章です。create-react-appを使ってReact + TSの環境を構築しています。

2章

モダンJSの文法の章です。普通にJS書いていたらだいたい知ってると思います。「プロパティ名のショートハンド」は初めて名前を知りました。

3章

高階関数やカリー化など、関数型にまつわるよしなにごとが分かりやすく説明されています。最近普通に書かれているJSのコードもだいぶ関数型っぽいですよね。他にも実際に今やってるプロジェクトではHOC使っていますし。他にも最後の方にステートレスコンポーネントに関しても言及されてました。

関数型言語なんか書きたい気分になってきました。

4章

TypeScriptの章です。まず、RubyやPythonなどの動的型付言語と比較して、型付言語の有用性が説明されています。静的型付言語はVSCodeなどのIDEを使うと便利に補完などをしてくれます。これはvimにはない機能なので、私もVSCodeなどのIDEをいい感じに使いこなしたいと思っておもむろに起動するのですが気づいたらvimでコードを書いています・・・

この章は習うより慣れろな部分が多くて、読むだけではなく実際にTSを書いてみるのが早いです。

5章

Webアプリケーションのフロントエンド層におけるテンプレートエンジンの弱点と、コンポーネントに分割するという手法でこの弱点を克服することに関して説明されています。この章はやたらと熱が籠もっていてとても熱いです。 この章にはWebフロントエンドそのものに関する思想が入っているので、Webフロントエンドを書く人は必読です。この章は繰り返し読もうと思います。

6章

LintとPrettierの紹介です。省略。

7章

ようやくReactの章です。まず最初に仮想DOM、コンポーネント指向、単方向データフローに関する説明が書かれています。このあたりはReactを使うにあたって基礎となるReactそのものの基本思想なのでよく理解しておく必要があると思います。この章の前半は本当に読む価値が高いです。

後半はReactコンポーネントに関する話でpropsやライフサイクルの説明がされています。ここはReactを触ったことがある人ならサクッと読めると思います。最後にはちょこっとStateless Componentにも言及されています。

8章

Presentational Component(コンポーネント)とContainer Component(コンテナ)のお話です。ちなみにコンポーネントとコンテナの概念はもともとは以下の記事で言われていたもので、本文中でも言及されていました。簡単にまとめると、見た目がPresentational Componentで、見た目のためのふるまい(HTTPリクエストとか)を含むのがContainer Componentみたいです。

medium.com

この2つのコンポーネントの作り方に関して簡単に言うと、HOCでContainer Componentを作り、関数コンポーネントでPresentational Componentを作る、ということみたいです。そして本文では

「React らしくて一番きれいなやり方は、関数コンポーネントで Presentational Component を作り、HOC で必要な機能を追加していって Container Componentを作る形だというのが私の考え。交流のある他の開発者の人たちの話を聞いても、意識高くて技術力も高い会社ではそのやり方をやってるみたい」 (P111)

と書かれており、どうやらモダンな(?)Reactを書くための必修事項のようです。

ここでHOCなContainer Componentを作るためにはrecomposeというライブラリを使います。本文中では「Reactの技術書でrecomposeのことに言及している本は少ない」と言われているように、自分も現場のコードを見て初めて存在を知りました。

これらの2つのコンポーネントに関してざっくり言うと「stateを持ちたくないからstateを別のコンポーネントに分けて、かつそのコンポーネントも関数コンポーネントとして書けるようにrecomposeを使う」といった感じでしょうか。ここ辺りはたぶんReactの中でも慣れるのに時間がかかる部分なのでしょうが、きっと諦めずにコードを追い(書き)続けていれば綺麗さに気づく部分のはずだと思っています。

感想: コンポーネントとコンテナに分割すると、Clean Archtectureの分割とちょっと競合する気がするのでうまく乗せにくそうだなと思いました。そもそもReact自体に結構いろんな思想が乗っかっているのでやはりキツいんでしょうか。みんなどうやっているのだろう・・・

実際にrecomposeを使うにあたっては以下の記事を読んでました。

blog.kyanny.me

qiita.com

9章

SPAのルーティングの話です。ここ辺りの話はReactに限らずSPAでWebアプリケーションを構築するときには必須の知識です。歴史的敬意も含めて説明されていてとても分かりやすかったです。

10章

Fluxアーキテクチャの話です。まずMVCアーキテクチャとの対比でFluxの説明がされていました。MVCアーキテクチャには、ViewとModelで双方向に通信すると機能追加を続けた時複雑さが跳ね上がるという問題がありました。これを単方向データフローにして複雑さが跳ね上がることを防ぐのがFluxアーキテクチャです。で、このFacebookが提唱したアーキテクチャの実装において覇権争い`が起こった結果Reduxが勝ったみたいです。

さて出てきましたRedux。慣れが必要で最初は結構難しいReduxも、基本となる思想から実際の使い方まで分かりやすく説明されています。

業務で開発するアプリに、コンポーネントをまたいで共有したいデータがないことなんてまずないから、最初から Redux を入れておいたほうが後からの軌道修正コストもなくていい。 (P179)

そうですよね、「まあ最初は規模も小さいし学習コスト高いから使わなくていっか」ってなりがちですよね。。。やるなら最初からいれねば。

印象に残った文

読んでて思わずメモしてしまった文章です。

• 「あー、Rubyist は Vim 大好きだからねえ。でもウチでは VisualStudioCode、長いので略して『VSCode』って呼ぶけど、それを使ってもらいます」 (P14)
• 『オレが…、オレこそが関数型プログラミングだ！』 (P45)
• Rubyst の人たちは CoffeeScript に振り回された過去があるせいで、AltJS にあまりいいイメージを持ってないのかもしれないね (P48)
• Web コンポーネントがこの先、実用段階になって普及していけば、React も Vueも Angular もそこに吸収されていく、と主張する人たちもいる (P79)
• 『Model と View の間に双方向のデータフローが作られるため、新しい機能を追加しようとするたびに、システムの複雑度はが指数関数的に増大し、そのコードは《壊れやすくて予測不能なもの》になってしまう』 (P144)
• 本当に React って原則を徹底させますよね (P145)
• フロントエンド、特に React はドキュメントの和訳を待ってると技術の進歩についていけないよ。 (P149)
• バックボーンを理解していれば書かれたものは読みやすいし、テストやデバッグも容易だけど、自分で一から書くのは難儀する、それが React や Redux だから。 (P162)
• 業務で開発するアプリに、コンポーネントをまたいで共有したいデータがないことなんてまずないから、最初から Redux を入れておいたほうが後からの軌道修正コストもなくていい。 (P179)
• 「背景となった歴史やその思想、そしてその技術がもたらすメリットをきちんと理解もできないまま、短絡的に『React も Redux も不要だ、あんなのすぐ廃れる』などと主張する開発者が特に日本には多くて、私はつねづね憤慨しているのですよ」 (P180)

まとめ

技術的な部分の充実はもちろんのこと、本としての体裁も綺麗に整っていてとても良い本でした。大事だと思った部分はしっかり染み付くまで繰り返し読もうと思います。

最近は個人開発でVue.jsを使うことが多かったのですが、これからはReactも使ってみようかなと思います。

大学院に進学することにした

今年の4月から明治大学大学院先端数理科学研究科ネットワークデザイン専攻の博士前期課程に進学します。

この記事は私の近況報告的な意味だけでなく、大学院に進学するか迷ってる人が進路を考えるための材料にもなればいいと思っています。

学部生時代の私

自己紹介がてらちょっとだけ学部時代(まだ学部生だけどね)の私について書きます。

私は典型的な、インターンのしすぎで学問が疎かになる学生で、 好きなように好きなコードを書いてきました。

といっても大してすごいことを成し遂げているわけではなく、今就職してチームにぶち込まれてもまあ足手まといにならないくらいにはコード書けるかなあってくらいのレベル感です。分からないところが分かる、って感じ。

周りの反応

大学4年生になって「進路どうするの？」と尋ねられた時に「大学院へ行きたい」と言うと少なくない数の人に止められました。

一番多かった意見が「君は研究より実務のほうが向いていると思うから早く社会経験を積め」というものでした。

この意見に関しては私としても真っ向から否定する気はなくて、確かに私は過去の活動から実務のほうが得意だと思っています。

この、私の適正(?)に関しては院試の面接でも突っ込まれたり、10年近い付き合いになる政治学科の後輩くんも「僕先輩が院行くと思ってなかったんですよね、なんか企業の技術職としてヌルっと良いとこ就職しそうなイメージ」(原文ママ)と言ってたりと、ずっと私に付きまとっています。

なぜ大学院に行こうと思ったのか

こんな、実務の方が向いてそうな私が大学院に行こうと思ったのにはいくつか理由があります。

• (1)結局実務のためには学位が必要らしいことをアメリカで就職活動をしている中で感じた
• (2)理系なのに学会発表なく卒業してしまうのは嫌だった
• (3)今のうちに研究もやっておきたかった
• (4)専門性を高めたい
• (5)より少ないパイに身を置きたかった

(1)実務のためには学位が必要

少し前の記事に書きましたが、日本国外(特にUS)で開発者としての職を得ようと思ったら学位はあったほうがいいみたいですね。実際私も大学院を意識しだしたのはUS滞在中だったように記憶しています。

asmsuechan.hatenablog.com

Twitterで「学位」とかで調べると結構面白いツイートがヒットします。

大学院行くかどうか迷ってる学生さんがいたら何度でも言いたいが、修士持ってても変わらないとか言い放つのはグローバルに闘ったことがない人なので聞いちゃ駄目ですよ。国際的には学歴はとても大切です。特に技術者として生きたければ、その分野の修士くらいはあった方が良いよ。博士なら勿論尚良し。

— 上原 哲太郎/Tetsu. Uehara (@tetsutalow) December 18, 2017

実際、必要とされるのは学位だけではなく学位の先にある実務の経験だとは思いますが、雇用に関しては国や地域で事情が違うので下手に一般化出来る問題でもないですね。

(2)理系なのに学会発表なく卒業してしまうのは嫌だった

理系学生なのにまだ学会発表を1度もしたことがないというのは小さなコンプレックスだったりします。ですのでこのまま経験0の状態で卒業するのは嫌でした。

ちなみに学部生だからといって学会発表できないわけではなく、うちの研究室も1学年1-2人学会発表に行く人はいます。

(3)今のうちに研究もやっておきたかった

いろんな人に言われるように研究ではなく実務が得意な方の人なので、今のうちに研究もやっておきたかったです。

(4)専門性を高めたい

休学中の2017年秋頃のある日「俺が今書いているコード、誰でも書けるよなあ」ということに気づきました。どうせなら誰でもはできない事がしたくて、専門性を高めるために大学院を志望しました。

しかし開発者(志望)である以上は他の人が読んで分かるコードを書く必要があるので、この「誰でもはできないこと」をしたいという意見には自分事ながら少し考えさせられるものがありますね。

(5)より少ないパイに身を置きたかった

学部卒より修士卒の方が少ないのは明らかです。より少ないパイに身を置いて自分の希少性(?)を高めれば後々いいことが起こるかもしれないというぼんやりした期待があります。もっと数が少ないであろう博士は・・・ごめんなさい。

将来のことはあまり深く考えないのですが、tagomorisさんのこちらのツイートがとても強く印象に残っています。自由に生きていきたいですよね。

自分は常に学位の取得をお薦めしております、将来の自由度に大きな差ができるので

— tagomoris (@tagomoris) April 21, 2017

大学院選び

大学院選びというよりは研究室選びなんですけどね。

修士へ進学しようと思ったときまずやったのが研究室選びです。この研究室選びに、私は2つの要素を条件にしました。

まず1つがコンピューターサイエンス(以下CS)絡みの問題が試験に出ること。これは私がCSの基礎を身につけたかったためです。

次に、今の指導教員と同等もしくはより多くのものを自分が吸収できそうな研究室であること。これはどうせ外に出るのならば少なくとも現在の環境よりはいい場所に行きたかったためです。

この2つの条件から最終的に1つ研究室を見つけたので、ここに入るための勉強をはじめました。このとき2017年11月。試験の10ヶ月くらい前。結構勉強したつもりです。

ちなみに海外大学院も考えたのですがGPAが低すぎてかなり厳しそうだったので断念しました。

院試の話

夏に外部の大学院、冬に内部の大学院を受けました。夏は結局落ちましたが筆記試験は受かってたのでCSの基礎は身についたのかなと思います。結果は出なかったけど残るものはあったという感覚です。それでも、落ちた原因を内省するのならばそれは自分の勉強不足以外の何物でも無いと思っています。

大学院でやること

研究内容に関してはフラフラと迷走しましたが自律移動ロボット周りの研究を行うことにしました。

ロボット技術はこれから役に立ちそうな予感がしていますし、Web開発の経験があってロボットの研究をしている人は少ないみたいなので是非とも修士の2年間でロボット関連技術を身につけたいと思っています。

しかし所詮私大の修士であるので自分の行う研究の結果に関しては特に期待していません。研究に対して世のため人のためとかいう大義名分はなく言うなれば金と時間のかかる自己啓発といった気持ちです。要するに意義などはあまり深く考えず楽しくやれることをやっていくぞって事です。(もちろん必要な場面で求められる大義名分は引き出しますが)

そして大学院では国内外で学会発表できる事を期待します。これは自分の努力の次第に依るところが大きいかとは思いますが機会を逃さず発表経験を積んでいこうかと思っています。

将来の話

上で将来のことはあまり深く考えないと書いたのですが、浅くなら考えています。たぶん私は修士を卒業してからは世界のどこかで日本語だけじゃなく英語や中国語を話しながら開発者として活動すると思います。

私は先のことを早くから決断してしまうと視野狭窄になってダメになるタイプなのでこれくらいの塩梅がちょうどいいみたいです。とかいいつつ全然違うことやってたらそれはそれで面白いですよね。

2年間、時間とお金はかかりますがまあ私ならこの2年頑張れば15年後だかに元は取れるだろうな、という気持ちになったので最終的に自分へゴーサインを出しました。

終わりに

欲しい物リストです。よろしければ支援をよろしくおねがいします。 http://amzn.asia/gULRJ4O

本人の前では言いませんが、先日面談中に「うちの研究室でもoo大学(夏受けた大学院)に負けないくらいのいろんな機会を用意します」と言ってくださった指導教員の先生にはとても感謝しています。(ちなみに指導教員は夏受けた大学の卒業生)

これまで仲良くしてくださった方々、まだしばらく学生ですがこれからもよろしくおねがいします。

ドキッ！湯けむりだらけの開発合宿

2019/01/12から2019/01/14の2泊3日五十沢温泉ゆもとかん(http://www.ikazawaonsen.com/)に宿泊して開発合宿をしました。

mokumoku-onsen.connpass.com

私は大学生で、スポンサーされる枠で申し込んでスポンサーしていただきました・・・！

1日目

到着まで

旅館がある六日町駅には東京駅から上越新幹線と上越線を乗り継いで行くつもりでした。

しかし授業の都合で集合時間に間に合わなかった私は不幸にも黒塗りの高級車に追突してしまう・・・

電車乗り損ねて一時間駅で待つことになったポンコツ

— asmsuechan (@suenaga_ryota) January 12, 2019

浦佐駅待合室会場 #mokumoku_onsen pic.twitter.com/XjNNoKZQY9

— asmsuechan (@suenaga_ryota) January 12, 2019

虚無の味を味わっている

— asmsuechan (@suenaga_ryota) January 12, 2019

旅館到着

無事に22:10くらいに旅館でラストサムライをかましてしまった私はそのまま流れるようにフードファイトへ。

とてもおいしくて20分くらいで食べ終わりました。魚が・・・魚が・・・とてもおいしかった・・・！

1日目夜

命の水の吸引力に勝てなかった我々はノールックで開封してしまう。

自分がいた部屋はそのまま0時くらいには就寝しました。他の部屋ではスマブラやってたみたいです。

2日目

2日目の朝、部屋の窓を開けるとこんな景色が広がっていました。白い。

そういえば隣の宴会場にいる若いパパママwithキッズがカラオケ大会で盛り上がっていたのがガン聞こえでいいコンテンツになりました。普通に上手くてよかったです。

この日は結構マジメに作業をしたおかげかちょっとだけ進捗が出ました。よかった。

開発開始

1日目を大きく遅刻してきた私は2日目の午前中より開発を開始しました。コードを書く以外のタスクがあまりにも多かったのでそれを3連休のうちに片付けようとセコセコと頑張っていました。

が、しかしやはり日本酒の吸引力には・・・・勝てなかった・・・・・(ここで手記は途切れている)

3日目

さて最終日。

朝はとても軽快な音楽が流れる食堂でバイキング形式の食事です。明太子がおいしかったです。

午前中は温泉に入りアイスを食べ睡眠をとりました！進捗ですね。

昼ゴハンは他人丼さんでした。おいしくいただきました。

合宿でやろうと思っていたこと

• 卒論バリバリ書く
• 発表資料作成
• 期末テストの勉強(2教科)
• phpunit.xmlとの戦い

合宿で実際にやったこと

• 期末テストの勉強(1教科)
• 発表資料作成(半分)
• phpunit.xmlとの戦い
• アニメを見る
• 寝る
• 温泉
• 日本酒

あはーーーん。やはり計画通りにはいかないものですね。卒論はファイルを開くことすらしなかった・・・

しかし半分くらいはやったので良しとしたいです。

まとめ

楽しかったです！！！！！ありがとうございました！！！！！

私もカッコいい大人になっていきたいと思います(東京都/23歳/学生)

写真を取り忘れたのですが、甘酒がめちゃくちゃおいしかったです。

その他

そういえば玄関には熊がいました。

電話がなんかエモい

合わせて読みたい judeee-blog.hatenablog.com

takanakahiko.hatenablog.com

apolloオプション内でパスパラメーターを取得する

variables()とprefetchの両方でparamsに関する処理を書かなければ動かない。これは自分のNuxtやapolloに対する不理解が原因でもあると思うが、違和感がハンパない。

<template>
  <themecontent :research-theme="researchTheme" />
</template>

<script>
import ThemeContent from '@/components/atoms/ThemeContent'
import gql from 'graphql-tag'

export default {
  components: {
    'themecontent': ThemeContent
  },
  data() {
    return {
      researchTheme: {}
    }
  },
  apollo: {
    researchTheme: {
      prefetch: ({ route }) => {
        return {
          name: route.params.name
        }
      },
      variables() {
        return {
          name: this.$route.params.name
        }
      },
      query: gql`
        query researchTheme($name: String!) {
          researchTheme(name: $name) {
            name
            content
            thumbnail_url
            title
          }
        }
      `
    }
  },
  methods: {}
}
</script>

Vue.jsのいい感じなctagを生成する

定義場所に直接ジャンプできる便利なctagをVue.jsで使うときにちょっと困りました。

Vue.jsのコンポーネント名のctagが自動では生成されない

ctagを生成するときはctags -R --extra=+fqってやるとファイル名のctagを生成してくれて便利なのですが、このタグには拡張子が付いています。

生成されるctagは例えば

App.vue  src/App.vue 1;" F

って感じです。これだとコード中にAppがあってもジャンプできません。

App  src/App.vue 1;" F

ですので拡張子.vueを含めない上のような形式にして欲しいのです。

しかしctagsコマンド単体では拡張子無しのタグを生成する方法が見つからなかったので、vimの保存時にsedでtagsファイルを置換するようにしました。

" ~/.vimrc
function! _updateCtags()
  let tagsFile = getcwd() . '/tags'
  exec ":silent ! ctags -R --extra=+fq && sed -i -e 's/^\\([a-zA-Z0-9]*\\)\\.vue/\\1/' " . tagsFile
  " *.vueファイルの.vueの部分をsedで取り除く
endfunction
command! UpdateCtags call _updateCtags()
autocmd BufWritePost * :UpdateCtags

こんなコードを.vimrcに置けばvimの保存時にファイル名から生成したVueコンポーネントの名前のタグを自動生成できます。

(コンポーネントのnameオプションで別の名前を指定されると無理。また別の正規表現で抜き出す必要がある)

~/.ctagsはこれをちょっといじって使っています。

クラウドワークスで1年くらい開発インターンしてた話

この記事はex-crowdworks Advent Calendar 2018の23日目です。

2016年から2017年にかけて1年ほどクラウドワークスで開発インターンをしていた思い出話です。これから開発インターンする人にも参考になると思います。

きっかけ

このミートアップの懇親会で社員さん捕まえて「ここで働かせてください！！！！！」って言ったら「勢いのある若者がいる」と認識されてインターンすることになりました。

そういえばインターン始まって最初にメンターさんと1on1した時、「東京タワーよりジャンプする方法って知ってる？」って聞かれて「ん？？？」ってなってたら「東京タワーはジャンプできないでしょ？」って返されて微妙な空気になったのが面白かったです。

やったこと

クラウドワークスの開発インターンは結構しっかりしていて、「新卒0年目」みたいな扱いでちゃんと(?)仕事を振ってくれて普通にレビューもしてくれてかなり力がついたと思います。

• メッセージ周りに機能をちょっと追加
• ServiceWorkerによるwebPushの実装
• サポートチームからの要望による改修
• webPush周りのリファクタリング
• その他

最初はメッセージ改修チーム(メンバー1人+俺)に在籍して簡単なバグ修正や機能追加などメッセージ改修のお手伝いを少ししていました。

夏頃突然メンターさんに「メッセージが来た時にMessangerみたいな通知きたら嬉しいよね、やってみようよ！」みたいな感じの軽いノリで言われてからChromeで動くプッシュ通知の実装が始まりました。

「やってみようよ！」とは言われたもののメンターさんにはメンターさんの仕事があった(これとか)ので自分中心に分からないところは他の社員さん達に聞いて頑張って進めた結果、メンターさん曰く「気付いたらできてた」そうです。ドキュメントは頑張って残したつもりなんですがいやこれこの後誰がメンテすんねんって感じです。今誰がメンテしてくれてるんだろう・・・

クラウドワークスのwebPushは今も動いていて、来るたびちょっと嬉しいです。

バグらせた

開発にはバグが付きものです、と教わりました。私も一年の間にそこそこバグを生み出してしまいました。

• メッセージ周りのデータ構造壊してデータ不整合
• ServiceWorkerをインストールする際のハンドリングの凡ミスでIEで一晩動かなかった
• ↑の再発防止としてエラートラッキングツールを内製しようとしたがGoogle Chromeのシークレットモードだけで動かない

特に一晩動かなかった時は、書いた報告書の損害額が結構デカくて一日めちゃくちゃヘコんでました。。。

障害の次の日、あまりにもヘコんでいたのを見かねた社員さんたちが私の机の上にｽｯとお菓子を置いていってくれたりコーヒーご馳走してくれたりめちゃくちゃ励ましてくれて「めっちゃいい人たちだ・・・・」って思ったのを覚えています。

気になったこと

当時の会社全体の雰囲気は謎のバッチサーバーさんのエントリを読めばなんとなく分かりそうですが、まあ良く言えば体育会系のノリが結構強いところでした。

例えば、開発じゃない他のチームのインターン生が社員さんに激詰めされてる声が頻繁に聞こえてくるなど。辞める際にマネージャーさんには話したのですが結構声デカくてうるさかったし自分のメンターさんがあれだったらすぐ辞めただろうなって感想です。

総括

とても楽しい時間を過ごさせてもらいました。クラウドワークスでインターンしたことは今の開発者としての自分にかなり大きな影響を与えていて、当時関わった方々にとても感謝しています。

当時お世話になった人たちとは今もまだ交流があって、Twitterで話したりたまに飲みに行ったりしててみんな仲良くていい雰囲気でとても楽しいです。これからもよろしくお願いします。