結果に git commit する

技術的なことはあまり書きません

【Mac向け】ソフトウェアエンジニアから見た卒論執筆環境

はじめに

先日、大学の卒業論文を書き終えました。
高専時代にも卒業論文を書いていますが、そのときからの成長は研究データの管理や執筆環境の運用レベルが上がったことくらいでした。
ソフトウェアエンジニアとして仕事をしていることが良くも悪くも卒業論文に影響した感じですね。
せっかくなのでその卒論執筆環境をブログにまとめておきます。

まとめ

最後まで読んで「なんだそれだけか」とならないように、先に何をやったかまとめておきます。

  • LaTeXとGitを使ってバージョン管理した
  • Dockerを使って環境構築を楽にした
  • 自動でタイプセットしてくれるようにした
  • Google ScholarBibTexを使って参考文献の管理を楽にした
  • 使い慣れているエディタを使った
  • CircleCIを使って論文を自動で配布するようにした(していない)

やったこと

それではここから、何をやったか説明していきます。

LaTeXとGitを使ってバージョン管理した

ソフトウェア開発にはバージョン管理は欠かせないものです。
論文の執筆にもバージョン管理を導入すると、過去の時点に戻すことができたり、共著であれば共同作業が簡単にできたりします。

そこで、Gitを使ってバージョン管理を行いました。
また、Gitを使ってバージョン管理をするにはテキストファイルが好ましいため、LaTeXで論文を書きました。
さらに、バックアップのためにGitHubなどにPushしておくと、もし作業中のファイルを失うことがあっても、最後にGitHubにPushした時点に復帰することができたりもします。

Dockerを使って環境構築を楽にした

ソフトウェア開発では、環境構築を楽にするために(もちろんそれだけではありませんが)Dockerがよく利用されます。
また、LaTeXの環境構築はいろいろインストールしないといけなくて結構大変なものです。

そこで、LaTeX環境がすでに整っているDockerイメージを利用することで環境構築の手間をほぼゼロにしました。
幸いなことに、そのようなDockerイメージを公開してくれている方がいるので、圧倒的感謝をしながらそれを利用させていただきました。
どのように利用したかは次節で話します。

github.com

自動でタイプセットしてくれるようにした

ソフトウェア開発では、開発を円滑に進めるために、ファイル保存をトリガーにコード整形やコンパイルなどの様々な処理が行われるように設定することがよくあります。
論文執筆でも、TeXファイルの保存をトリガーに自動でタイプセットを行い、PDFファイルを生成してくれるようにすると書いたものがすぐに見れてとても良いです。

そこで、ファイルの変更を監視して自動でタイプセットしてくれるlatexmkを利用しました。
latexmkは先程のDockerイメージに入っているのでそのまま利用できます。
また、タイプセットする前に句読点を変換(「、。」→「,.」)してくれるようにしました。
具体的には、

#!/usr/bin/env perl
$pdf_mode         = 3;
$latex            = 'ls *.tex chapters/*.tex | xargs sed -i "" -e "s/。/./g; s/、/,/g"; uplatex -halt-on-error';
$latex_silent     = 'uplatex -halt-on-error -interaction=batchmode';
$bibtex           = 'upbibtex';
$dvipdf           = 'dvipdfmx %O -o %D %S';
$makeindex        = 'mendex %O -o %D %S';

というファイルを.latexmkrcという名前で保存し(chapters/とかのディレクトリ構成は僕の環境のものなので適宜変えてください)、

docker pull paperist/alpine-texlive-ja

を実行してDockerイメージをダウンロードしたあと(dockerコマンドは必要であればインストールしてください)、

version: "3"
services:
  tex:
    container_name: tex
    image: paperist/alpine-texlive-ja
    volumes:
      - ./:/workdir
    command: latexmk -pvc main.tex

というファイルをdocker-compose.ymlとして保存して、

docker-compose up

を実行するとmain.texというTeXファイルがタイプセットされ、PDFが出力されます。
実行したままにしておくとTeXファイルを変更して保存するたびにタイプセットとPDF生成が行われます。
Ctrl+Cを押すとそれを停止することができます。

Google ScholarBibTexを使って参考文献の管理を楽にした

ソフトウェア開発では、見通しを良くするためなどのためにファイルを分割したりすることがよくあります。
論文執筆でも、章ごとにファイルを分けたり、参考文献を別ファイルに分けたりすると、執筆が楽になります。

そこで、章ごとにファイルを分けてメインのTeXファイルから読み込むようにしました。
また、参考文献はBibTexを利用して別ファイルで管理し、体裁を自動で整えてくれるようにしました。

具体的には、introduction.texとかのファイルを

\begin{document}

	\input{chapters/introduction.tex}

\end{document}

のようにmain.texから読み込むようにして、章の内容はintroduction.texに書くようにしました。
また、main.bibというファイルに参考文献の情報を書いて、

\begin{document}

	\input{chapters/introduction.tex}

	\bibliography{main}
	\bibliographystyle{junsrt}

\end{document}

とすると自動的に体裁を整えた参考文献ページを作ってくれます。
どのように文献の情報を書けばいいかですが、Google Scholarというページで文献を検索し、検索結果の文献の下にあるダブルクオーテーションマークをクリックしてBibTexを選択して表示される情報をそのままコピペして、それを論文中で参照するだけでOKです。
例えばこんな感じのが表示されます。

@inproceedings{le2018persistence,
  title={Persistence fisher kernel: A riemannian manifold kernel for persistence diagrams},
  author={Le, Tam and Yamada, Makoto},
  booktitle={Advances in Neural Information Processing Systems},
  pages={10028--10039},
  year={2018}
}

使い慣れているエディタを使った

ソフトウェア開発では、開発者それぞれが使い慣れたエディタを使えるように、開発環境をエディタに依存しないようにすることがよくあります。
論文執筆でも、普段使い慣れたエディタにTeXの補完とかをしてくれるプラグインを入れて執筆したほうが楽になると思います。

といっても特にすることはなく、ここまで説明してきたことをやっていれば自然とどのエディタでも問題ないような環境になっているはずです。

CircleCIを使って論文を自動で配布するようにした(していない)

ソフトウェア開発では、開発した製品を自動的にテストしたり配布したりするように設定することがよくあります。
論文執筆でも、ある程度まで完成した論文を研究室の方々に見ていただくための配布を自動化できると嬉しいことがあるかもしれません。

そこで、CircleCIなどのCIツールをGitHubと連携し、masterブランチにマージされたときにPDFを生成して研究室のSlackなどに共有されるように自動化すると良いかもしれません(僕は執筆期間が短いのでやりませんでした)。
もし英語論文なのであれば、スペルチェックなどをCIで行うことも良いと思います。
僕がやっていないので具体的な方法は他のブログなどを見ていただければと思いますが、latexmkでタイプセットしてPDFファイルを生成し、そのファイルをSlack APIを使ってSlackに投稿するようにCIのジョブを組めばできると思います。

おわりに

今回は、ソフトウェアエンジニアとして働く中で学んだ概念を論文執筆にも応用する形で(こじつけながら)論文執筆環境を構築する方法を紹介しました。
大きくは、

  • 普段の環境を汚さない
  • 構築と運用が楽
  • 再利用性が高い

という3つの点を意識した感じになります。
皆さんの論文執筆に役に立てば幸いです。

2018年を振り返ってみる

はじめに

このブログを開設して2回目の1年を振り返るエントリーです。
今年は、今までハッカソンや短期インターンなどで勉強してきた技術をベースにしつつ、
比較的大きなサービスの開発をスクラッチから経験することで(今もしています)、
今まで身につけてきたサービス開発技術が全体的に底上げされる1年でした。
そしてプライベートもとても充実していました。
さて、振り返っていきましょう。

今年の目標はなんだったか

snowman-mh.hatenablog.com

今年の目標は↑に書いてあるとおり、「もっとプログラミング以外のことをする」でした。
そして、続いてこんなことを言っていました。

大学を卒業します(正確には2019年卒ですが)。
友達と遊びます。スノボに行きます。彼女を作ります。
漫画を読みます。映画を見ます。テレビを見ます。
PS4を買います。モンハンをします。
もちろんプログラミングも引き続きやります。

2017年を振り返ってみる - 結果に git commit する

果たして達成できたのでしょうか。

余裕で達成していた

順番に見ていくと、

  • 大学はもうちょっとで卒業します(絶賛卒業研究遂行中)。
  • 友達と遊びました。スノボにたくさん行きました(今シーズンは年明けにいきます)。
  • 彼女ができました。
  • 漫画を読みました(約束のネバーランドにハマりました)。
  • 映画を見ました(今度は愛妻家、Every Day、アンドリューNDR114、リメンバーミー、とかがとても良かったです)。
  • テレビはあんまり見なくなってしまいました(NetflixAmazon PrimeYouTubeに負けました)。
  • PS4を買ってモンハンを飽きるほどやりました。その後さらにNintendo Switchも買っていろいろゲームしました(Switchは2人でやると楽しいソフトが多くてオススメです)。
  • プログラミングは引き続きやっていました。

という感じで、プログラミング以外の部分はまぁほとんど完璧といっていいでしょう。

そしてプログラミングの関してですが、今年は2つの企業にお世話になりつつ、サーバ・インフラをスクラッチから構築していく仕事をしていました。
特にいま働いているCAmotion(↓の記事参照)では、サイバーエージェントの技術資産にお世話になりつつとてもレベルの高い開発経験を積ませてもらっています。
ということで、プログラミングのほうも予想以上に完璧でした。

要するに完璧な1年でした。

snowman-mh.hatenablog.com

月ごとに振り返っていく

それでは去年の振り返りエントリーと同様に、今年を月ごとに振り返っていきます。

1月:ひたすらスノボとモンハン

1月はひたすらスノボにいっていました。
そして、1月26日に発売したモンハンを友達と一緒に17時間ぶっ続けでやったりしていました。
大学3年後期の期末テストもありましたが、何も記憶に残っていません。
4年前期で1単位とる必要があったくらいなので、そこまで落としたりはしなかったのでしょう。
あと、本格的に関わり出したのは2、3月からですが、株式会社ventusという友達が起業した会社でサーバサイドエンジニアとして働き始めました。

ventus-inc.com

2月:スノボと大阪帰省

2月もスノボにいっていました。どうせ3月もいくでしょう。
そして、大阪に帰省して地元の友達と遊んでいました。
あんま覚えてないですけど同窓会もあったらしいです、Googleカレンダー曰く。
それ以外の時間は株式会社ventusでサーバサイドを開発していました。
Go+GCPで開発していたのですが、スクラッチから開発したのは初めてで、苦戦することも多かったですが、チームメンバーと協力して開発を進めていました。
リリースまで関わることはできませんでしたが、whooop!というサービスがリリースされていますので、ぜひチェックしてみてください。

whooop.jp

3月:スノボとダラダラ

3月も当たり前のようにスノボにいっていました。
5日間北海道のニセコに滑りにいっていたのですが、最高でしたね。
それ以外はGoogleカレンダーにほとんど何も書いていないので多分ダラダラしていたのでしょう。
1年に1ヶ月くらいは何も記憶がない時期があることは大事なことです。

4月:大学スタート、スケボー練習し始めた

大学が始まり、研究室にも配属されました。
そして、ペニーには乗っていましたが、ストリートタイプのスケボーも買ってオーリーとかの練習をはじめました。
正直今はまったく練習できておらず、今年の唯一の残念ポイントと言えます。来年はやっていきたい。
この頃から今働いているCAmotionの話を聞くようになっていきました(本格的なジョインは5月です)。

5月:CAmotionと彼女

ゴールデンウィークあたりからCAmotionに本格的に関わるようになりました。
詳しくは冒頭の記事を読んでください。
そして、彼女ができました。
とてもかわいいですね。
スケボーの練習もしていました。

6月:Nintendo Switchを買った

引き続きCAmotionに関わりつつ、彼女と遊んでいました。
この頃からスケボーをあんまりやらなくなってしまいました。
代わりにNintendo Switchを買いました。
最初にやったゲームは「ドンキーコング トロピカルフリーズ」でした。
2人でプレイするのがめっちゃ楽しかったです。

7月:特に変わったことはなかった

引き続きCAmotionに関わりつつ、彼女と遊んでいました。
高専のときの友達が東京に遊びにきて一緒に遊んだりしました。
7月24日は誕生日で、みんなに祝ってもらいました。
ドンキーコングは1ヶ月程度で全ステージをクリアし、次に買ったのは「マリオオデッセイ」でした。
ドンキーコングよりは難易度が下がりましたが、すべてのスターを集めるくらいには2人でハマりました。

8月:CAmotion本格始動

CAmotionでの開発が本格的に始動したあたりでした。
ソフトウェアアーキテクチャについて考えたり、インフラ構成について考えたり、とても楽しかったです(今も楽しいです)。
それ以外はいつもの日常で、新しいゲームには「星のカービィ スターアライズ」が選ばれました。
カービィはさらに難易度が下がって、一瞬でクリアしてしまいました。
なので次のゲームまでのツナギとして「いっしょにチョキッとスニッパーズ」を買いました。

9月:卒研の中間報告会

夏休みなので大阪に帰省しつつ、いつもどおりバイトしていました。
9月頭には誕生日にCAmotionのメンバーにもらったチケットで彼女とディズニー・シーにいきました。
新しく「太鼓の達人 Nintendo Switchば〜じょん」を買って彼女と2人で太鼓を叩いていました。
卒業研究をほとんど進めていなかったのですが、急に中間報告会がやってきました。
それに向けて何か進捗を出していました。
まぁ中間報告やしこんくらいでいいっしょ精神が大事なことを学びました。
中間報告が終わったあとは静岡にさわやかを食べに行く旅行にいきました。おいしかったです。

10月:いつもの日常に戻った

中間報告が終わってまた研究をなかなか進めない日々が戻ってきました。
今月(正確には9月末)は「みんなでワイワイ!スペランカー」というちょっとマイナーなゲームを買いました。
ドンキーコングくらいの難易度でとても楽しかったです。
しかし途中でやめてしまったので、続きをいつかやりたいですね。

11月:特に変わったことはなかった

いつもどおりバイトをして、彼女と遊んでいました。
このくらいからゲームをあまりしなくなりました。
代わりにNetflixに課金し、アニメとか映画を見ていました。
平和な日々でした。

12月:卒研がやばいことに気づく

卒研がやばいです。
まぁ卒業できないレベルではないですが、やばいです。
この記事は卒研を進めている途中の休憩で書いています。
遊びや仕事などの他の活動に影響が出ないように雰囲気でやっていきたいと切実に思っています。

おわりに

来年の目標は「幸せに暮らす」です。

思いつかなかったわけではありません。

幸せになるために、もっとプログラミングの勉強をしてイケてるエンジニアになります。
とりあえずは月に1つくらいは何か記事を書いていきたいですね。

そして、彼女と仲良くしていきます。
隔月くらいで旅行にいきたいですね。

あとスケボーの練習したいですね。

それでは皆さん、良いお年を。

CAmotionで学んでいるチーム開発で大事な7つのコト

はじめに

adventar.org

このエントリーは、CyberAgent 19新卒 エンジニア Advent Calendar 2018の1日目の記事です。

株式会社サイバーエージェントの2019年度新卒内定者として内定者バイトをしている僕が、内定者だけの子会社である株式会社CAmotionで、エンジニアとしてチーム開発をしていく中で学んでいることを残したいと思います。
エンジニア視点とはいっても、絶賛開発中ということもあり、具体的な使っている技術などの話はしません。

株式会社CAmotionで働いています

www.cyberagent.co.jp

現在、株式会社サイバーエージェントの2019年新卒内定者として、内定者バイトをしています。
働いているところは、19卒内定者だけで立ち上げた株式会社CAmotionという子会社です。
↑の記事に載っている4名が、選抜型インターンシップ「DRAFT」で事業を提案し、子会社を設立することになりました。

僕はサーバサイド・インフラを主に担当しています。
サーバサイドは僕含め2人、iOSエンジニアが2人、デザイナーが1人、そしてビジネスサイドが3人というメンバー構成になっています。

www.cyberagent.co.jp

最高の環境です

基本的に自分たちだけで仕様決定やサービス開発を進めていくので、何から何まで全部自分たちでやっています。

ですが、内定者だけの子会社とはいえ、サイバーエージェントの子会社であり、他のチームと同じビルで仕事をしていて、社員さんのサポートもあります。
インフラ、iOS、サーバサイドともに技術的な相談ができるメンターさんがついてくれています。
そのおかげで、サイバーエージェントの技術資産を利用しながら0からサービス開発をできて、とても有意義です。
実際に動いているサービスの技術や、もうクローズしてしまったサービスのソースコード、インフラなどを中心とした知見を容易に得ることができるのはとても助かっています。
そして技術だけでなく、ビジネスの面でも様々な知見を利用できていると思います。

また、メンバーが19卒内定者だけということもあり、とても仲良しです。仲良し最高。
そのメンバーがとても優秀です。自分ができない仕事を安心して任せることができています。

チーム開発で大事な7つのコト

そんな環境でエンジニアとしてチーム開発をする中で、学んでいることを話していきたいと思います。

ビジネス職、デザイナー職との仕事を通じて

まずは、ビジネス職、デザイナー職のメンバーと一緒に仕事をしていく中で学んでいることを話していきます。

①チームビルディングはとても重要

心理的安全性という言葉はときどきTwitterなどで見かけますが、心理的安全性が保たれたチームが一番生産性が高いそうです。Googleさんが言っていました。
ちゃんと理解できているかは分かりませんが、心理的安全性とは要するに「なんでも言える」ことだと思っています。
CAmotionでは、ビジネスサイドのメンバーが率先してチームビルディングをやってくれて、遠慮することなくみんな意見を言える雰囲気で仕事ができています。
これはサービスを開発・運用していく中でとても重要なことだと思います。
そして、チームに新しいメンバーがジョインするたびにチームビルディングの時間をしっかり取っているのもすごいことであり、重要なことだと思います。
どんなことをやっているかについては、いつかビジのメンバーの誰かがブログでも書いてくれると思います。

②仕様決めではエンジニア的目線でフィードバックする

サービスの仕様を決める際のエンジニアの役割は、仕様に対して技術的なフィードバックをして、技術とのギャップを埋めることだと思っています。
機能の仕様を考えるとき、どのようなエラーが起きうるかなどのエンジニア以外には馴染みのないケースを示して、想定していない状況が発生しないようにします。
そうすることで、ビジネスサイドやデザイナーには機能のコア部分をより良くすることに集中してもらうことができます。
ビジネスサイドやデザイナーが、技術的な考慮漏れをまったく不安に思うことなく進める世界にしていきたいですね。

③技術を知り、実装方法の幅を広げる

仕様と実装の工数との間にはギャップがつきもので、例えば2つの候補があり、仕様的にはそこまで変わらなくても工数が大きく変わったりすることは少なくありません。
その際に、仕様と工数を照らし合わせて、何をどこまでやるかをチームで決めていく必要があります。
ときには工数と相談して妥協(目的を変えずに手段を代替)する必要もあります。
そのとき、エンジニアが複数の選択肢を提示できたり、工数を正確に提示できたりすることはとてもプラスになってきます。
そのためには、エンジニアが日頃から様々な技術を知り、実装方法の幅を広げていくことが大事だと思いました。

エンジニアとの仕事を通じて

④お互いのタスクがボトルネックにならないようにする

複数人での開発では、互いのタスクどうしがボトルネックになることを避けることが大切なのはよく知られています。
さらに、僕たちは内定者なので、みんな大学があり、他のバイトをしている人もいて、出勤日が合うことがとても少ないです。
そのため、互いのタスクがボトルネックにならないようにできるかどうかがよりクリティカルになっています。
タスクの担当を振り分けるとき、お互いのタスクが依存しないように意識し、一方の手が止まってももう一方に影響を与えないことに注意して担当を決めています。

⑤並行して進められるタスクを選択する

とはいえ、いくら自分たちで依存し合わないタスクを選択できても、何らかの申請が通るのを待ったり、社内システムについての質問の回答を待ったり、なにかと外部に依存してしまうことはよくあります。
そのようなときでも、それ以外のタスクを進めて手を止めないために、依存し合わないタスクを個人が同時に担当するよう選択したりすることも重要になってきます。

⑥簡単なタスクも並行して進める

手を止めないことはとても大事ですが、頭を使いすぎると人間は疲れます。
そのため、簡単なタスクをところどころに挟んで脳を休ませることが大切です。
これは地味にけっこう大事で、こうすることで他のタスクの効率が上がったりすることがあると実感しています。
あと、ときには簡単なタスクすらやめて、休みましょう。
これもとても大事です。
特に僕はしんどいときはまじで何もしてません。

⑦誰が書いても同じコードになるアーキテクチャ

これはどのチームにも当てはまるものでもないですし、どんな事業にも当てはまるものでもありません。
ですが、僕のチームではフィットしているので紹介したいと思います。
サーバサイドでは、Go言語を使ってDDDライクのアーキテクチャに則って開発しています。
責務の分離や依存関係の明確化ができており、どこに何を書けばいいのか、迷わない状況を作ることができています。
そして、どう書くかもほぼ迷わないので、メンバーのコードが自然とほぼ同じになり、レビューのコストなどが大幅に削減できています。
詳しいアーキテクチャなどは別の記事に書きたいと思っていますが、責務の分離や依存関係の明確化ができ、チームメンバーがどこに何を書くか迷わないようにする、というアーキテクチャ選定の一番の目的を達成することは非常に重要だと実感しています。

おわりに

もちろんこれだけではありませんが、チーム開発で重要だと感じていることを紹介してきました。
今後はチームで使っている技術やアプリケーションアーキテクチャ、さらにインフラ設計・構築などの技術的なアウトプットもしていければと思います。

自分たちで新規サービス開発のすべてを行い、技術面でもビジネス面でもメンターさんを含めた社員さんにフィードバックをもらいながら開発を進められる、そんな素晴らしい環境での0→1の新規サービス開発に興味のある方がいらっしゃればお気軽にご連絡ください(特にCA19卒内定者)。

twitter.com

それでは、最後までお読みいただきありがとうございました。

明日は、CAmotionで一緒にサーバサイドエンジニアとして仕事をしている、

twitter.com

の担当です。お楽しみに。

2017年を振り返ってみる

はじめに

今年はプログラミング漬けの年でした。
このブログも今年の夏から始めました。
せっかくなので今年1年を振り返ってみようかと思います。

振り返ってみる

1月

Swiftはじめた

2016年の12月にYahoo! JAPAN主催のハッカソン「HACK U」に参加しました。
それ以来サービス開発に興味を持ち、プログラミング学習を開始しました。
たまたまiPhoneMacBook Airを持っていたという理由から、SwiftでのiOSアプリ開発についての学習をはじめました。
詳細! Swift 3 iPhoneアプリ開発 入門ノート Swift3 + Xcode 8対応という技術書を読んでiOS開発の概要を学びました。

大学の期末試験

大学の期末試験がありました。
9科目くらいありました。

2月

Swiftつづけた

引き続きiOS開発について学んでいました。
TODOアプリや家計簿アプリなどを自分で作ってみて練習しました。
デザインやリリースの経験もできて良かったです。
本を読むだけではなく、実際に何か作ってみることは上達の近道になったと思います。

実際の業務でSwiftを使ってみた

ある程度Swiftを勉強して、次は実際に世に出ているアプリに触ってみたくなりました。
そこで、SwiftでiOSアプリを開発しているところでインターンとして受け入れてもらえないか探しました。
その結果、2月から半年ほどスタートアップ企業でインターンすることになりました。
SwiftによるiOSアプリ開発Ruby on Railsによるバックエンド開発の経験を積むことができました。

3月

引き続きSwift

引き続きインターンでSwiftとRubyを勉強していました。
給料が低くて大変でした。
1月までに家庭教師をして貯めていたお金でなんとかしていました。
この頃は大きなイベントもなくあんまり記憶がありません。

4月

インターン

SwiftとRubyのお勉強。

家庭教師を再開した

ちょうど依頼が来たので、週1で家庭教師を再開しました。
経済的にしんどかったのでちょうど良かったです。
42歳のおじさんに中学数学を教えるというなかなか面白い体験をすることもできました。

5月

インターン

引き続きSwiftとRubyのお勉強。
給料が上がって少し余裕ができました。

サマーインターン応募開始

5月末くらいから各社のサマーインターン応募が始まってきました。
有名どころに10社ほど応募して5社合格くらいでした。
合格したのは、はてな楽天WantedlyGREEサイバーエージェントでした。
不合格だったのは、VOYAGE GROUP、クックパッド、LINE、DeNAでした。
選考を途中で辞退したのはYahoo!でした。

6月

インターン

引き続きSwiftとRubyお勉強。

サマーインターン選考

サマーインターンの面接や選考課題に時間を割いていました。

7月

インターン

引き続きSwiftとRubyのお勉強。
このインターンも夏休み前に終了することになりました。
約半年間お世話になりました。

サマーインターン選考

ほとんど6月に終わっていましたが、7月前半に少し残っていたものがありました。

大学の中間試験

大学の中間試験が7月末にありました。
10科目くらいありました。

8月

はてなサマーインターン

株式会社はてなのサマーインターンに参加させていただきました。
Webサービス開発のいろはを学べたとともに、自分のiOS開発力をさらに磨くことのできた良い機会になりました。

snowman-mh.hatenablog.com

9月

楽天ハッカソン形式インターン

楽天株式会社の短期サマーインターンに参加しました。
ハッカソン形式のインターンで会社のことはあまり分かりませんでしたが、iOS側をもう1人のメンバーと一緒に開発し、少ない日数でチーム開発する良い経験になりました。

snowman-mh.hatenablog.com

Wantedlyのサマーインターン

Wantedly株式会社のサマーインターンに参加しました。
Xcode9から大幅に機能が追加されたUITestについてキャッチアップしていたことを活かすことができて良かったです。

snowman-mh.hatenablog.com

iOSDCに参加した

iOSDCというiOSカンファレンスに参加しました。
とても楽しいカンファレンスでした。

snowman-mh.hatenablog.com

10月

ダラダラした

夏休みにいろいろサマーインターンに参加させていただき、とても充実した夏休みを送ることができました。
でもとても疲れたので10月はダラダラしていました。

JPHACKS

10月終わりにJPHACKSというハッカソンイベントに大学の友人と一緒に出場しました。
当日の朝にアイデアが変わったり、実装できる人が少なかったりと大変でしたが、良い経験になりました。

11月

サイバーエージェントでのインターン

11月中旬頃から1ヶ月ほど、サイバーエージェントFRESH!というサービスを開発しているチームのサーバサイドにインターンとして参加させていただきました。
このチームは、サイバーエージェントの中でも特に技術に攻めているチームで、サーバサイドKotlinを採用していたりしました。
もう一人のインターン生と協力して、gRPCで通信しているマイクロサービスのうちのKotilnで書かれているサービスにAPIを追加したり、あるバッチ処理を行うマイクロサービスをGoで開発したりしました。
今まで触ったことのない技術をたくさん触ることができて、非常に刺激を受けました。

12月

DeNAでのインターン

12月終わりにDeNAのSWETグループで7日間インターンをさせていただきました。
Swift Package Managerを使ってCLIアプリケーションを開発しました。
勉強会などで登壇されている方が多いグループで、以前から興味のあったグループだったのでとても楽しかったです。
SWETグループの特徴も相まって、今まで考えたことがあまりない部分について気を配る必要があり、とても新鮮でした。

ボードを買った

前シーズンに生まれて初めてスノボに行きました。ハマりました。
今シーズンもいっぱい行きたいです。
ウェアとかは去年買ったのですが、今年ついにボードを買ってしまいました。

2018年の目標

2018年の目標は「もっとプログラミング以外のことをする」です。

大学を卒業します(正確には2019年卒ですが)。
友達と遊びます。スノボに行きます。彼女を作ります。
漫画を読みます。映画を見ます。テレビを見ます。
PS4を買います。モンハンをします。
もちろんプログラミングも引き続きやります。

高専から東大に編入すると強制的に留年する話

この記事は留年生 Advent Calendar 2017 - Qiitaの21日目の記事です。

はじめに

こんにちは、東京大学 工学部 電気電子工学科というところに通っている学部3年生です。
僕は「明石工業高等専門学校(明石高専)」という学校を卒業したあと、東京大学に「編入学」という形で入学しました。
現在22歳で大学4年生の歳ですが、大学3年生に所属しています。
今回はその謎を解き明かしていきましょう。

高専とは

高等専門学校」を省略して「高専」と呼ばれています。
日本全国で50個くらいあります。
僕は兵庫県明石市にある「明石高専」というところに通っていました。

高専は、中学校を卒業したあと、高校に入学するのと同じタイミングで入学する学校です。
そして、普通高校と違って高専は5年間通います。

歴史的には、終戦後に日本は技術者が少ない状況に陥り、専門技術を持った人間を素早く社会に放出するために高専という教育機関が作られたという経緯があったりします。

高専で学ぶこと

高専では、高校1年生の歳から専門的な知識を学ぶことができます。
専門分野は様々なものがあり、高専によっても違います。
僕が通っていた明石高専では、

の4つがあり、僕は電気情報工学科に所属していました。
電気情報工学科では、

  • 電気回路
  • 電子回路
  • ディジタル回路
  • 電気磁気学
  • プログラミング(C言語)
  • 電気情報工学実験

などの専門教科を1年生から学ぶことができます(一部1年生では履修しない科目もあります)。

高専生の進路

高専には5年間通うことになるので、卒業する頃には20歳、大学2年生の歳です。
その後の進路はどのようなものがあるのでしょうか?

結論から言うと、

  • 大学へ編入学
  • 就職
  • 専攻科に進学

の3つがあります(他にあったっけな…)。

大学へ編入学する際には大学1年生ではなく、途中の年次に編入することになりますが、詳細は後述します。
また、高専が技術者の早期育成のために作られたとだけあって就職率はほぼ100%となっており、求人が毎年たくさん来るので就職する人もいます。
さらに、高専は5年間通いますが、さらに2年通って専門技術をより深く学び、学術研究に活かすことを目的に専攻科というところに進むという進路もあります。

進学と就職の割合は高専によって大幅に変化し、僕が通っていた明石高専は進学:就職=7:3くらいですが、別の高専ではその割合が逆になったりします。

東大に編入すると留年する?

やっと本題ですね。
高専は5年間通うので、卒業する頃には20歳、大学2年生の歳です。
よって、だいたいの大学では大学へ編入すると3年生になります。

しかし、東京大学京都大学に編入した場合は2年生に編入することになります。
1年ずれて留年したみたいになるってことですね。
その謎を解き明かしましょう。
ちなみに、京都大学に編入すると2年生になる理由は知らないので誰か教えてください。

東大の教養学部進振り制度

東京大学に入学した学生は全員「教養学部」という学部に所属することになります。
教養学部ではスペイン語や社会生態学などの文系科目から微分方程式やベクトル解析などの理系科目を履修してそれぞれの単位を取得する必要があります。
そして、大学2年の夏に「進振り」という制度があり、今までの成績をもとに「工学部」や「理学部」、「文学部」などに進学することになります。

謎の真相

教養学部で単位を取ったあと進振り制度で学部に配属されることを前述しました。
しかし、高専からの編入生は「教養学部で取得する単位」を全部は持っていません。
それらを取得するために2年生から編入学する必要があったってのが2年次に編入する必要のある謎の真相でした。
高専で取得した単位がいくつか認められるので、1年生ではなく2年生からになる感じです。

実は3年生を2回やっている

あ、2年生に編入学すると言いましたが、あれは嘘です。
3年生に編入学します。
なぜなら、高専生は編入学という形で入学しますが、編入を管轄しているのは工学部で、教養学部のせいで工学部の最低学年が3年生になってしまうからです。
ということで、教養学部に入るというのも嘘です。工学部に入ります。

でも前述したように、1年目で教養学部の単位は取得する必要があるので、結果的に3年生を2回やることになります。
これは実質2年次編入しているのと同じなので、2年次編入と呼ばれています。
3年生の学生証を持った状態で1年生、2年生がいる教室に授業を受けに行くことになるので、ちょっとつらいですね。

高専に行って

高専から東大に編入すると強制的に留年する謎の真相を解き明かしました。
ここからは僕が高専に入って良かったこと・悪かったことを紹介したいと思います。
謎の真相が知れて満足した人はこの先は読む必要なかったりします。

良かったこと

寮が楽しかった

僕の実家は大阪にあるので、明石高専に入学するときに寮に入りました。
高専は5年間通うので、寮には5年間も住むことになります。
5年間も同じ人と一緒にいるととても仲良くなります。
たのしいですね。

卒業研究ができた

高専普通高校と違って「卒業研究」をして「卒業論文」を書かないと卒業することができません。
卒業研究をする時間が必要なので大学編入試験は夏に行われるくらいです。
大学での研究などに比べるとレベルは低いかもしれませんが、研究活動を体験できるのは良い経験になったと思います。

東大に行けた

東大の編入試験は「数学・英語・物理」の3教科のみです。
大学2年までの内容が受験範囲になるので範囲こそ広いですが、そこまでひねった問題が出たりはしません。
広く浅くみたいな感じですね。
この傾向と5年間という余裕のある期間のおかげで東大に入ることができたと思います。
普通高校から普通に東大を受験していたら受かっていた気がしません。高校生の東大受験問題を見たことありませんが。

悪かったこと

女子が少ない

女子が少ないです。
全体で3割ほど。
僕が所属していた電気情報工学科では45人中3人とか。
かなしいですね。

誰も知らない

高専のことは誰も知りません。
知っているのは高専の近所に住んでいる人くらいです。
なのでどんな学校かとかを説明するのがとても大変です。
でも、これからはこの記事を読んでと言えば大丈夫になりますね。

東大に行って

次に、高専を卒業して東大に編入して良かったこと・悪かったことを紹介します。

良かったこと

環境が変わった

まず単純に、自分の身を置く環境を変えるというのは人生を豊かにすると思います。
東大に入らなくても環境を変えることはできますが、環境を変えると価値観の違う人たちに出会うことができます。
東大は何かと優秀な人が多いですしね。
アホな友達もいっぱいできて、そいつらとアホなことをするのもとても楽しいです。

プログラミングを学習する期間が取れた

東大は2年次編入です。
大阪大学などの他の大学に編入した人は3年生から始まるので、すぐに院試です。すぐに研究室配属です。

僕は院へは進学せず就職しようと思っています。
2年生からスタートだったので好きなことを勉強できる期間があり、そこでプログラミングを本格的に勉強しました(今もしていますが)。
様々な会社でインターンをさせていただきながらプログラミングを学習したりする中で、これを仕事にしたいと思うようになりました。
3年生からのスタートだとすぐに院試ですぐに研究室配属って感じで自分のキャリアをゆっくり考える時間がなかったと思います。
大学院へ進むのはもちろん良いことだと思いますし、就職することも良いことだと思います。
でも自分には就職があっているかもということを発見できたので、2年次編入で良かったと思っています。
まぁ就職したことがないのに就職が自分に合っていると思えたのは、ほぼ社員のように受け入れてくれた数々のインターン先のおかげなので、とても感謝しています。

ネームバリュー

やっぱり東大にはネームバリューがあります。
最終的に大事なのはもちろん自分のスキルですし、僕が入ろうとしている世界はその傾向が比較的強い業界です。
でも、第一印象が良いに越したことはありませんからね。

悪かったこと

女子が少ない

女子が少ないです。
全体で3割ほど。
僕が所属している電気電子工学科と電子情報工学科は130人中10人くらい?とか。
かなしいですね。

取得単位が多すぎる

詳細は省きますが、僕が所属している学科、通称EEICは取得する必要のある単位が多いです。
たくさん授業を履修しています。
全部に出席しているわけではないですが、僕はバカなので少なからず負担になっています。
まぁ頑張って卒業しないと就職できないので頑張ります。

おわりに

今回は「高専から東大に編入すると強制的に留年する謎の真相」と「高専・東大に行って良かったこと・悪かったこと」を紹介しました。
僕は自分の選択をまったく後悔していませんし、むしろ正解だったと思っています。
これからも頑張っていきたいと思います。

ワタシハFirefoxチョットデキル

目次

はじめに

この度、私 id:snowman_mh は、FirefoxJavaScriptエンジンである「SpiderMonkey」のコミッターになりました。
この記事では、その経緯やコントリビュートの方法などをまとめたいと思います。
何をしたか早く読みたい方は「やったこと」まで飛んでください。

自己紹介

僕は、「東京大学工学部電気電子学科」というところの学部3年生に所属しています。
大学の授業やインターンシップで日々プログラミングの勉強をしています。電気系の勉強もしています。
そして、僕が所属する電気電子学科および電子情報学科には「電気電子情報実験」という、欠席すると留年する授業があります。
今回は、その実験の一環でOSSにコントリビュートする経験ができましたので、実験報告書を兼ねたブログを書いている次第であります。

大規模ソフトウェアを手探る

実験というからには様々なテーマがあり、その中から自分の好きなテーマをある程度選択することができます。
今回僕が参加したのが、その中の1つである「大規模ソフトウェアを手探る」というテーマの実験です。

実験の目的

「『演習レベルの小さなプログラムが作れること』と『実用規模のプログラムが作れること』のギャップを埋める(ための知識と経験を得る)」ことを目的として実施されている実験です。
また、ソフトウェアを改良するためのアイデアを出し合ってみて、whatとhowを考える力を養うことも目的とされています。

実験の内容

超簡単に説明すると、この実験では「10日間(1日4時間程度)かけて、OSSとして公開されている大規模なソフトウェアに手を入れる作業を体験してみる」ということをします。
僕はFirefoxJavaScriptエンジンである「SpiderMonkey」というソフトウェアを題材にしました。
他のチームは

  • Slackライクなチャットサービス「Gitter」
  • 仮想暗号通貨の「zcash」
  • 無料オフィスソフトの「LibreOffice
  • 皆さんご存知「Google Chrome (Chromium)」

などを題材としていました。

実験の報告書

さらに、この実験でのいわゆる報告書、レポートは「ブログ」という形で提出することが認められています。
この実験を担当している田浦先生の、「『やったことを10日間も顔を合わせた先生やTAにだけ見てもらう』のではなく、『全世界の同じようなことをしたい人たちに見てもらう』ほうが有意義である」という考えによるものらしいです(かっこいい)。

SpiderMonkeyについて

WebブラウザであるMozilla FirefoxJavaScriptエンジンの名前です。

ECMAScriptとは

JavaScriptは主にブラウザで動作する言語なので、処理系がブラウザに依存するという特徴があります。
しかし、ブラウザごとに書いたコードを動作が違うとプログラミングやめたくなります。
それを防ぐために(それだけではないが)、ECMAScriptという規格でJavaScriptの標準が定められています。
その標準に従ってそれぞれのブラウザがJavaScriptの処理系を実装しています。

JavaScriptエンジン

前述したように、JavaScriptエンジン(JavaScriptの処理系)はブラウザによって違います。
Google ChromeはV8という名前だったり、SafariJavaScriptCoreという名前だったりします。
そして今回コントリビュートしたMozilla FirefoxJavaScriptエンジンはSpiderMonkeyという名前です。
SpiderMonkeyでは、JavaScriptコードをコンパイラバイトコードと呼ばれる中間言語に変換し、インタプリタが解釈し、CPUがネイティブコードを実行する、という順序で処理されます。

コミッターがいた...

この実験には学部生をサポートするTAが数名います。
なんとその中にSpiderMonkeyに日頃からコントリビュートしているコミッターの方がいました。
Mozillaからウチで一緒にやらないかと言われているとかいないとか。
今回この題材を選んだのも、そんな凄腕コミッターのサポートが受けられるから、というのが大きいです。
なんてったってそのTAさんがIssueをアサインすることも、コードをレビューすることも、マージすることもできますからね。
自分の力だけでは絶対にここまでの成果を出すことはできませんでした。
TAさんには感謝してもし切れません。

やったこと

この実験で実際に行ったことをまとめます。

チュートリアル

最初に全員の共通課題として「gnuplot」というグラフ描画ソフトに変更を加えることをチュートリアルとして行います。
gnuplotでは、

gnuplot> plot sin(x)

とするとsin(x)が描画されますが、これを

gnuplot> sin(x)

とするだけで描画されるように変更するという内容でした。
詳しい手順はこちらにまとまっているので、体験したい方は読んでみてください。

SpiderMonkeyを手探る

さて、ここからやっと本題ですが、SpiderMonkeyのコードを手探っていこうかと思います。

まずは何よりも環境構築をする必要があります。
前述しましたが、この実験のTAにはSpiderMonkeyのコミッターがいます。
その方がまとめてくれている資料を参考にして環境構築を行いました。
そして、実験で僕が行ったコントリビュート手順の詳細は別記事にまとめました。
実験の背景とかはどうでも良いからコントリビュートする手順だけ知りたい人のためです。

qiita.com

エラーメッセージを改善する

僕は今回の実験のテーマとして「SpiderMonkeyのエラーメッセージを改善する」というのを選びました。
このページに改善すべきエラーメッセージがまとめられていて、比較的小さな変更から大きめの変更まで様々なBugがあり、小さなタスクでコントリビュートを体験してみて、最後に大きめのタスクに挑戦できそうというモチベーションで選びました。
結果として3つのIssueを解決することができたので、それぞれの詳細を紹介したいと思います。

その1 - クラスを再宣言したときのエラーメッセージ

JavaScriptでは、変数を定義するためのキーワードとしてvar, let, constなどがあります。
varで定義された変数は同名変数を定義することができますが、let, constは同名変数を定義することができません。

js> var a; var a;    // 問題なし
js> let b; let b;
SyntaxError: redeclaration of let b
js> const c = 1; const c = 1;
SyntaxError: redeclaration of const c

同様にclassも同名クラスを定義することができませんが、そのエラーメッセージを見てみましょう。

js> class Foo {}; class Foo {};
SyntaxError: redeclaration of let Foo

なんと、classなのにletとか言っちゃってます。
これを、

SyntaxError: redeclaration of class Foo

って言ってくれるように変更しました。
このバグレポートページはこちらです。
最後に僕の名前が入ったコミットページへのリンクもコメントされています。

変更内容としては5行程度でした。
軽い変更でコントリビュートが体験できたとともに、これだけで解決するIssueがあるんだなと思いました。
誰にでもコントリビュートのチャンスってあるんですね。

詳しい変更内容や、どのように変更点を探したのかは別記事にまとめました。

qiita.com

その2 - super();を呼ばなかったときのエラーメッセージ

JavaScriptではクラスを継承することができます。
以下のJavaScriptコードを見てください。

class B {};
class A extends B {
    constructor() {
        this.someValue = 'value';
    }
}
new A();

このコードはReferenceError: |this| used uninitialized in A class constructorというエラーを吐きます。
これは継承先のコンストラクタで、継承元のコンストラクタを呼ぶ前にthisにアクセスしていることによって起きているエラーですが、とても分かりにくいという問題が報告されていました。
以下のコードのようにsuper();を呼ぶ必要があります。

class B {};
class A extends B {
    constructor() {
        super();
        this.someValue = 'value';
    }
}
new A();

これで正常に動作します。
同様に、継承元のコンストラクタでアローファンクション内でthisにアクセスしても似たようなエラーを吐きます。

class B {};
class A extends B {
    constructor() {
        (() => {
            this.someValue = 'value';
        })()
    }
}
new A();
ReferenceError: |this| used uninitialized in arrow function in class constructor

こちらも同様にアローファンクションの前にsuper();を呼ぶと解決します。
これらのエラーメッセージを次のように表示されるように変更しました。

ReferenceError: must call super constructor before using |this| in A class constructor
ReferenceError: must call super constructor before using |this| in arrow function in derived class constructor

このバグレポートページはこちらです。

変更内容としてはこちらも5行程度でした。
っていうか1個目のIssueよりも簡単でした(文字列を変えただけなので…)。
しかし、1個目と違ってテストにも変更を加えたので、3個目に活きる体験ができました。

詳しい変更内容や、どのように変更点を探したのかは別記事にまとめました。

qiita.com

その3 - in演算子に関するエラーメッセージ

JavaScriptでは、in演算子という二項演算子があります。
inは、右辺のオブジェクトが左辺の名前のプロパティを持っているかどうかの真偽値を返します。

js> class A {};
js> let a = new A();
js> "hello" in a;
false
js> a.hello = "hello world";
js> "hello" in a;
true

inの右辺にオブジェクトでない値(文字列や真偽値など)を持ってきてしまった場合、次のようなエラーを吐きます。

js> 'hello' in 'hello world';
TypeError: invalid 'in' operand "hello world"

オペランドにオブジェクト以外を取ることができないので当たり前ですね。
しかし、Pythonを書いていた人から見ると、「なんで文字列をオペランドに取れないの!?」となります。
なぜならPythonでは、'hello' in 'hello world'と書くとTrueが返ってくるからです。
そう、Pythonでは、in演算子というと、部分文字列が文字列内に含まれるかどうかの真偽値を返す演算子なのです。
ここでは、右辺にオブジェクト以外の値を持ってきたことが悪いと伝わりにくいエラーメッセージを出力していたことが問題となっていました。

そこで、次のようなエラーメッセージが出力されるように変更しました。

js> 'hello' in 'hello world';
TypeError: cannot use 'in' operator to search for 'hello' in 'hello world'

また、非常に長い文字列を両辺に取った場合、文字列が省略されて表示されるようにしました。
Google Chromeでは長い文字列のまま表示されているので、Firefoxの勝ちですね!!!

js> 'hello'.repeat(100) in 'hello'.repeat(100)
TypeError: cannot use 'in' operator to search for 'hellohellohelloh...' in 'hellohellohelloh...'

このバグレポートページはこちらです。

変更内容としては90行程度でした。
比較的大きな変更を加えることができて嬉しいです。

詳しい変更内容や、どのように変更点を探したのかは別記事にまとめました。

qiita.com

おわりに

大学の授業やインターンシップでプログラミングを勉強していますが、ここまでガッツリOSSにコントリビュートしたのは初めてで、非常に刺激的で有意義な経験ができました。
今回の実験で得た大規模なソフトウェアを手探るコツのようなものはこれからも活かすことのできる貴重なスキルになっていくと思います。
今回僕が行ったことのすべては本記事およびリンク先の別記事にまとめてありますので、それを読めば誰でもFirefoxSpiderMonkeyのコミッターになれるはずです(?)。

また、ひよっこエンジニアの僕がここまでの成果を出すことができたのも、ひとえにSpiderMonkeyのコミッターであるTAさんが手取り足取り指導くださったおかげです。
本当にありがとうございました!

最後になりますが、このような貴重な体験のできる実験を用意してくださった先生にもとても感謝しています。
今までの実験レポートは前日に徹夜で書くことが多かったのですが、このレポートは実験終了前に書き始めたくらい楽しかったです。

リリースパーティ (2017/11/25 追記)

後日、Mozilla日本オフィスの近くで開催されたFirefox Quantumのリリースパーティに招待していただきました!
Firefoxのアニメーションまわりの開発に日本から参加していた方や、Firefoxのアドオンを開発しまくっている方などにお会いすることができました。


GitHubのコミット (2017/12/24 追記)

GitHubミラーリングされているリポジトリから自分のコミットを発掘したので貼っておきます。

github.com

github.com

github.com

CyberAgentのAdTech Challengeに参加してきた

はじめに

10月21日、22日に開催された株式会社サイバーエージェントの「AdTech Challenge」に参加してきました。
そこで学んだことを残したいと思います。

f:id:snowman_mh:20171024223610j:plain

インターンの内容

位置情報データを秒間2000リクエストで流すサーバが用意されていて、その膨大な位置情報データを処理して集計する基盤をGoogle Cloud Platformを利用して作成しました。
その位置情報データに基づく問題が用意されていて、その問題に対する解答の精度を7チーム(1チーム = 学生3人 + 現場社員1人)で競うという内容でした。

僕は順番に流れてくるデータを処理してBigQueryやCloud Datastoreに保存する部分の実装をCloud Dataflowを利用して行いました。
Goを使うと思って勉強していったのにDataflowのストリーミング用SDKJavaにしか対応していなくて2日でJavaをマスターすることになりました。
このインターンでGoとJavaが使えるようになりました。笑

学ぶことに投資してくれる文化

サイバーエージェントは学ぶことに投資してくれる文化が根付いているなと思いました。
「既に技術が身に付いていて、実務経験もあって、そういう人が生み出す成果に期待する」のではなく、「学ぶ力があって吸収力の高い人に、学ぶところから投資して、その人が企業に還元することを期待している」そうです。
あくまで社員さんと話して僕が感じたことで、社員さんが上記のことを明言したわけではないですよ。
うまく説明できているか分かりませんが、そういう文化はとても好きだなぁと思いました。

長期インターンなどを探していても、既に持っている技術を活かして業務に参加するパターンが多くてなかなか新しい技術に挑戦できないことが多いと思うので、学ぶことに投資してくれるところで働きたいと思いました。
まぁ長期インターンは出勤時間がそんなに多くない中で成果を出す必要があるのである程度は仕方ないとは思いますが…。

変化の激しい技術についていく

今回のインターンで僕が担当した部分はCloud Dataflowを利用したデータ処理部分で、JavaSDKを利用して開発しました。
そのSDKがかなりの頻度で変更されており、GitHubの誰かのプロジェクトに12日前にコミットされたコードですら動かないということがあったくらいです。
公式リファレンスも更新されていなかったり情報が不十分だったりしました。

そんな状況の中で、最初はどうやって動くコードを書くのか全然分かりませんでした。
メンターさんがどうやって最新のコードを探しているのかを見ていると、GitHubにプッシュされている意識の高い人のリポジトリから同じような動作をしているコードを探していました。
それをマネして、メンターさんに手助けを頂きながらGitHubから最新の動くコードを探していきました。
GitHubで最新の実用的なコードを探すコツみたいなものを少しは盗めたかなと思います。
エンジニアをやっているとよくやることだとは思いますが、今までできていなかったことだったので、これからも絶対に役に立つスキルを身に付けることができて良かったです。

おわりに

今までに触ったことのない技術にたくさん触れることができた楽しいインターンでした。
成果物に満足することはできませんでしたが、成果物を作るまでのチーム開発の過程には満足することができたので良かったと思います。
とても良いチームでした。
また、サイバーエージェントという興味のあった企業について少しでも知ることができたのも良かったです。

せっかくGoの勉強をしたのでGoを使う長期インターンみたいなのがあったら参加したいですね。