ワタシハFirefoxチョットデキル
目次
はじめに
この度、私 
id:snowman_mh は、FirefoxのJavaScriptエンジンである「SpiderMonkey」のコミッターになりました。
この記事では、その経緯やコントリビュートの方法などをまとめたいと思います。
何をしたか早く読みたい方は「やったこと」まで飛んでください。
自己紹介
僕は、「東京大学工学部電気電子学科」というところの学部3年生に所属しています。
大学の授業やインターンシップで日々プログラミングの勉強をしています。電気系の勉強もしています。
そして、僕が所属する電気電子学科および電子情報学科には「電気電子情報実験」という、欠席すると留年する授業があります。
今回は、その実験の一環でOSSにコントリビュートする経験ができましたので、実験報告書を兼ねたブログを書いている次第であります。
大規模ソフトウェアを手探る
実験というからには様々なテーマがあり、その中から自分の好きなテーマをある程度選択することができます。
今回僕が参加したのが、その中の1つである「大規模ソフトウェアを手探る」というテーマの実験です。
実験の目的
「『演習レベルの小さなプログラムが作れること』と『実用規模のプログラムが作れること』のギャップを埋める(ための知識と経験を得る)」ことを目的として実施されている実験です。
また、ソフトウェアを改良するためのアイデアを出し合ってみて、whatとhowを考える力を養うことも目的とされています。
実験の内容
超簡単に説明すると、この実験では「10日間(1日4時間程度)かけて、OSSとして公開されている大規模なソフトウェアに手を入れる作業を体験してみる」ということをします。
僕はFirefoxのJavaScriptエンジンである「SpiderMonkey」というソフトウェアを題材にしました。
他のチームは
- Slackライクなチャットサービス「Gitter」
- 仮想暗号通貨の「zcash」
- 無料オフィスソフトの「LibreOffice」
- 皆さんご存知「Google Chrome (Chromium)」
などを題材としていました。
実験の報告書
さらに、この実験でのいわゆる報告書、レポートは「ブログ」という形で提出することが認められています。
この実験を担当している田浦先生の、「『やったことを10日間も顔を合わせた先生やTAにだけ見てもらう』のではなく、『全世界の同じようなことをしたい人たちに見てもらう』ほうが有意義である」という考えによるものらしいです(かっこいい)。
SpiderMonkeyについて
WebブラウザであるMozilla FirefoxのJavaScriptエンジンの名前です。
ECMAScriptとは
JavaScriptは主にブラウザで動作する言語なので、処理系がブラウザに依存するという特徴があります。
しかし、ブラウザごとに書いたコードを動作が違うとプログラミングやめたくなります。
それを防ぐために(それだけではないが)、ECMAScriptという規格でJavaScriptの標準が定められています。
その標準に従ってそれぞれのブラウザがJavaScriptの処理系を実装しています。
JavaScriptエンジン
前述したように、JavaScriptエンジン(JavaScriptの処理系)はブラウザによって違います。
Google ChromeはV8という名前だったり、SafariはJavaScriptCoreという名前だったりします。
そして今回コントリビュートしたMozilla FirefoxのJavaScriptエンジンは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のコミッターがいます。
その方がまとめてくれている資料を参考にして環境構築を行いました。
そして、実験で僕が行ったコントリビュート手順の詳細は別記事にまとめました。
実験の背景とかはどうでも良いからコントリビュートする手順だけ知りたい人のためです。
エラーメッセージを改善する
僕は今回の実験のテーマとして「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があるんだなと思いました。
誰にでもコントリビュートのチャンスってあるんですね。
詳しい変更内容や、どのように変更点を探したのかは別記事にまとめました。
その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個目に活きる体験ができました。
詳しい変更内容や、どのように変更点を探したのかは別記事にまとめました。
その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行程度でした。
比較的大きな変更を加えることができて嬉しいです。
詳しい変更内容や、どのように変更点を探したのかは別記事にまとめました。
おわりに
大学の授業やインターンシップでプログラミングを勉強していますが、ここまでガッツリOSSにコントリビュートしたのは初めてで、非常に刺激的で有意義な経験ができました。
今回の実験で得た大規模なソフトウェアを手探るコツのようなものはこれからも活かすことのできる貴重なスキルになっていくと思います。
今回僕が行ったことのすべては本記事およびリンク先の別記事にまとめてありますので、それを読めば誰でもFirefox、SpiderMonkeyのコミッターになれるはずです(?)。
また、ひよっこエンジニアの僕がここまでの成果を出すことができたのも、ひとえにSpiderMonkeyのコミッターであるTAさんが手取り足取り指導くださったおかげです。
本当にありがとうございました！
最後になりますが、このような貴重な体験のできる実験を用意してくださった先生にもとても感謝しています。
今までの実験レポートは前日に徹夜で書くことが多かったのですが、このレポートは実験終了前に書き始めたくらい楽しかったです。
リリースパーティ (2017/11/25 追記)
後日、Mozilla日本オフィスの近くで開催されたFirefox Quantumのリリースパーティに招待していただきました！
Firefoxのアニメーションまわりの開発に日本から参加していた方や、Firefoxのアドオンを開発しまくっている方などにお会いすることができました。
Firefox Quantumのリリースパーティたのしかった pic.twitter.com/z3NAsdDrn2
— はや氏 (@snowman__mh) 2017年11月14日
CyberAgentのAdTech Challengeに参加してきた
インターンの内容
位置情報データを秒間2000リクエストで流すサーバが用意されていて、その膨大な位置情報データを処理して集計する基盤をGoogle Cloud Platformを利用して作成しました。
その位置情報データに基づく問題が用意されていて、その問題に対する解答の精度を7チーム(1チーム = 学生3人 + 現場社員1人)で競うという内容でした。
僕は順番に流れてくるデータを処理してBigQueryやCloud Datastoreに保存する部分の実装をCloud Dataflowを利用して行いました。
Goを使うと思って勉強していったのにDataflowのストリーミング用SDKがJavaにしか対応していなくて2日でJavaをマスターすることになりました。
このインターンでGoとJavaが使えるようになりました。笑
学ぶことに投資してくれる文化
サイバーエージェントは学ぶことに投資してくれる文化が根付いているなと思いました。
「既に技術が身に付いていて、実務経験もあって、そういう人が生み出す成果に期待する」のではなく、「学ぶ力があって吸収力の高い人に、学ぶところから投資して、その人が企業に還元することを期待している」そうです。
あくまで社員さんと話して僕が感じたことで、社員さんが上記のことを明言したわけではないですよ。
うまく説明できているか分かりませんが、そういう文化はとても好きだなぁと思いました。
長期インターンなどを探していても、既に持っている技術を活かして業務に参加するパターンが多くてなかなか新しい技術に挑戦できないことが多いと思うので、学ぶことに投資してくれるところで働きたいと思いました。
まぁ長期インターンは出勤時間がそんなに多くない中で成果を出す必要があるのである程度は仕方ないとは思いますが…。
変化の激しい技術についていく
今回のインターンで僕が担当した部分はCloud Dataflowを利用したデータ処理部分で、JavaのSDKを利用して開発しました。
そのSDKがかなりの頻度で変更されており、GitHubの誰かのプロジェクトに12日前にコミットされたコードですら動かないということがあったくらいです。
公式リファレンスも更新されていなかったり情報が不十分だったりしました。
そんな状況の中で、最初はどうやって動くコードを書くのか全然分かりませんでした。
メンターさんがどうやって最新のコードを探しているのかを見ていると、GitHubにプッシュされている意識の高い人のリポジトリから同じような動作をしているコードを探していました。
それをマネして、メンターさんに手助けを頂きながらGitHubから最新の動くコードを探していきました。
GitHubで最新の実用的なコードを探すコツみたいなものを少しは盗めたかなと思います。
エンジニアをやっているとよくやることだとは思いますが、今までできていなかったことだったので、これからも絶対に役に立つスキルを身に付けることができて良かったです。
おわりに
今までに触ったことのない技術にたくさん触れることができた楽しいインターンでした。
成果物に満足することはできませんでしたが、成果物を作るまでのチーム開発の過程には満足することができたので良かったと思います。
とても良いチームでした。
また、サイバーエージェントという興味のあった企業について少しでも知ることができたのも良かったです。
せっかくGoの勉強をしたのでGoを使う長期インターンみたいなのがあったら参加したいですね。
シゴトでココロオドル人を増やしてきた
はじめに
9月19日〜22日の4日間の期間でWantedly株式会社のサマーインターンに参加してきました。
Wantedly Visitを開発しているチームに配属されました。
そこで学んだことを残したいと思います。
インターンの内容
Wantedlyのインターンは実際のサービス開発に参加することができ、Wantedlyでの仕事を体験することができます。
インターンをしている目的が自分に合う企業を探していることが一番の僕にとっては良い環境でのインターンでした。
もちろん、2番目の目的である技術力をつけるというのも達成することができるインターンでもありました。
初日にインターン期間中に達成できそうなタスクをいくつか教えてもらって、その中から自分がやりたいタスクを選んで開発を始めるという感じでした。
僕は今回、ディープリンクからアプリに飛んできたときに意図した画面が表示されているかどうかを検証するUI Testを導入しました。
GitHubに残す文化
Wantedlyでは、GitHubに情報を残す文化が定着しています。
GitHubに口頭で話したことや実装の方針を残すことは様々な会社で実践されていると思いますし、インターンをしてそのようなところを見てきました。
しかし、Wantedlyではそれが本当に徹底的に行われていました。
僕もそれをマネして、実装を進めるに当たってリサーチしたことや決定した方針などをできるだけ残すようにしました。
その際、「これは残すべき内容か」「これで残す内容として過不足はないか」などを考えるのが難しかったですが、勉強になりました。
また、GitHubに残すことに集中しすぎて口頭でのコミュニケーションが減らないように気をつけないとと思いました。
新しい技術へのキャッチアップ
上の記事にまとめていますが、WWDCで発表されたXcode9からの新APIについて勉強していた経験がありました。
その知識が今回のタスクを進めるのに非常に役に立ちました。
「新しい技術にキャッチアップすること」は「選択肢の多様化」に繋がるので、実装の方針を考える際に良い選択ができる可能性が高くなります。
まぁなんか良いことあるやろ、と思って勉強していたことですが、今回それが役に立つことを体験できたので、これからも続けようと思いました。
OSSを読む
メンターの方に質問すると、RxSwiftなどのOSSのコードを参考にした解決策を提示してくれることが多くありました。
今まで分からないことを検索するときに英語を使うのは結構意識してやってきましたが、OSSのコードを参考にすることはありませんでした。
これから意識してやってみようと思いました。
しかし、同じような要件を実装しているコードをOSSから探すのは結構難しいと思うので、話題になったリポジトリや有名なライブラリのコードを日頃から読むことが大切だと思います。
大切だと思ってるだけで実際にできていませんが。。。
そういえば、先日のiOSDCでもOSSコードリーディングを勧めているLTがありましたね。
iOSDC 2017にタダで参加させていただいてきた
iOSDC 2017に行ってきました
9月16日、17日に開催された「iOSDC 2017」に参加してきましたので学んだことを残そうと思います。
素晴らしいカンファレンスでした
まず初めに、素晴らしいカンファレンスを開催してくださったスタッフの皆さん、ありがとうございました！
僕はこのようなカンファレンスに参加したのは初めてでしたが、とても楽しめました。
スタッフの人がすべてのブログを読むと言っていたので、これも読んでくれているはずです。
来年も参加したいと思います！
スタッフ側で参加できたらいいなぁ
Wantedlyのスカラシップスポンサー
今回のiOSDC 2017は、Wantedly株式会社が提供していたスカラシップスポンサー枠として参加させていただきました。
タイトルはなんか軽い感じで書いてしまいましたが、安くはないチケット代を負担していただけるのは学生としてとても嬉しいことで、とても感謝しております。
僕は東京に住んでいるので当てはまりませんでしたが、他の参加者は会場までの交通費や宿泊費なども援助されていたようです。
プレゼンについて学んだこと
いくつもセッションを聞いた中で、技術的な話の前に、プレゼンをするに当たって気をつけるべきと学んだことを残します。
理解してほしいことと理解しなくてもOKなことを明確にする
このような場でセッションをすると、限られた長くはない時間の中で、伝えたいことを伝えて理解してもらう必要があります。
そのためには、「この部分は雰囲気が分かれば良い」「ここはしっかり理解してほしい」「ここは名前だけ覚えておいてほしい」などを明確にすることが大事だと思いました。
今聞いている部分はどのあたりまでの理解度であれば問題ないのかがオーディエンスにオープンになっていると聞きやすいと思いました。
コードは最小限に、大きな文字で見やすく
技術カンファレンスではコードをスライドに含めることは多いと思います。
その際に、必要なコードのみ、必要なタイミングでのみ、最適なサイズで見せることが大切だと思いました。
コードをスライドに出すと、オーディエンスはそれを読み始めるので、読む必要がある分だけ出しながら話すのがベストです。
また、先程の「どのくらい理解してほしいか明確にする」に共通している部分はありますが、理解してほしいコードのみを出しながら、コードをどれくらい理解してほしいかを示しながら話すとオーディエンスは聞きやすいと思いました。
技術的な学び
本当に素晴らしい内容のセッションばかりでした。
qiita.com
このような素晴らしいまとめ記事がQiitaに上がっているので、内容についてはそちらを参照すると良いと思います。
ここでは、数あったセッションの中から、特に「なるほど勉強になった！」と個人的に思ったことを一言で紹介していきたいと思います。
「Build high performance and maintainable UI library」より
- 「アプリと違ってライブラリは様々な状況で使用されることを想定する必要がある」
- 「可読性とパフォーマンスのようなトレードオフを知る、優秀なエンジニアほどその見極めができる」
「結婚式を支えた技術 Firebaseを活用したサーバレスiOSアプリケーション開発」より
- 「やらないことを決めた」
- 「チームメンバーに無力感を与えない」
「Human Interface Guidelinesから滲み出る限界感を考える」より
- 「HIGが作った指針を崩さない程度にHIGを逸脱するオリジナルを加えていくと魅力的なデザインになる」
- 「AppleがどのようにHIGを逸脱しているかを参考にする」
おわりに
インターンでお世話になった方や、Qiitaやブログなどでアイコンだけ見たことある人に会えたりしました。
知っている人が結構いて、自分もこの世界で勉強できてるのかなと思えてちょっと嬉しかったです。
これからも頑張っていこうと思いました。
楽天サマーインターンで優勝してきた
目次
インターンの内容
楽天O-netや楽天競馬などを開発しているOSPDという名前の部署で、平日5日間を利用して行われる短期インターンでした。
「高齢者と若者をつなげるWebアプリ」というテーマでチームごとにプロダクトを作り、最後にプレゼンをして順位を決めるという形式でした。
4人のチームにリードエンジニアレベルのメンターの方が3人ついてくださり、サービス企画から実装、プレゼンまでずっとフィードバックを与え続けていただけるという贅沢な環境でした。
サービス開発の醍醐味を感じられたと思います。
参加人数は学生12人で、4人1チームとして3チームに別れて競う形式でした。
サービス企画
まずは最初の1日と2日目の夕方くらいまでをサービス企画の時間に使いました。
いつも使わない脳を使ってとても疲れましたが、得るものも多かったです。
チームメンバーでアイデアをまとめ、メンターの方々にフィードバックをもらってブラッシュアップしました。
そして、2日目の午前にOSPDのプロデューサー陣にプレゼン形式で発表し、またフィードバックをもらってブラッシュアップしました。
コンセンサスを取ることの難しさと重要性
4人のチームで1日半という短期間でどのようなサービスを作るかを考えるには、「コンセンサス」を取ることがとても大事になってきます。
サービス企画に慣れていなかったので、アイデアを固めるのはとても難しかったですが、それよりも難しかったのは、「細かい部分でみんなの意見を一致させる」ことです。
大枠の意見は一致していても、細かい部分まで確認していくと、「あれ、そうやったっけ？」とメンバー同士が疑問を持ち合うことは珍しくなかったです。
とことんチームで話して細かい部分まで一致させていく必要がありました。
そのあたりをどこまで確認し、一致させ、コンセンサスをチームで取ることの重要性とその難しさを学びました。
煮詰まったときの対応
アイデアが煮詰まったときには「第三者の意見を聞く」のと「課題から見つめ直す」というのが大事だな、と学びました。
言葉にすると当たり前に聞こえますが、これが意外と難しく、そして大事でした。
第三者の意見を聞く場合は、「今まで自分たちがどのように考えて、どのような結論に至っているが、どのような問題があるか」を言葉にして説明する必要があります。
さらに、課題を見つめ直し、その課題を解決するようなアプローチを考えることが一番良いサービス企画のやり方です。
チーム開発
サービス企画が終了すると、2日目の夕方から4日目の午前中までの期間で実装に落とし込みました。
チーム開発の経験はありましたが、0からチーム開発をスタートした経験はあまりなかったので良い経験になりました。
0からのチーム開発
4人チームのうち僕を含めた2人はSwiftでクライアントサイドを開発し、他の2人はサーバサイドをPHPで開発しました。
チーム開発自体は初めての経験ではありませんでしたが、学生だけで0からチーム開発を「始める」経験は初めてでした。
.gitignoreの設定などのiOS開発の一般的な知識を共有せずに開発を始めてしまったため、コンフリクトが頻発してしまったりしました。
自分だけが理解していても、チームメンバーが知らなかったり、いくつかのスタイルがあったりするので、開発を開始する前にコーディングスタイルや.gitignoreについて共有・確認するべきでした。
「妥協する」ことの意味
「妥協する」とは、「目的を達成するために手段を代替する」という意味で、目的を変えてしまうものは妥協ではありません。
妥協したために最初に設定した目的が達成されない場合、それは妥協ではありません。
妥協することの意味を今まで理解しているようで理解していなかったと思いました。
短い実装期間であったため、時間の都合で実装できない部分がいくつかありました。
そのとき、妥協して実装しない部分を決めることは珍しくありませんでした。
しかし、そのとき、本当の意味での妥協をして、期間内に収まるように調整することが大切だと学びました。
snowman_mhとして生きてゆく
はじめに
変えてゆくぞ
以前までは、「@bilimboy」というスクリーンネームでTwitter活動をしていました。
YouTuberのバイリンガールという人の動画が好きで、ガールの部分をボーイにしたってのが由来でした。
これからは「snowman_mh」で生きてゆくので、スクリーンネームを「snowman_mh」を変更しよう、と思ったら、既に使われてました。
しかも凍結されてる。。。何をしたんだ先代snowman。。。
とりあえずアンダースコアを2つにした「@snowman__mh」にしました。
以前までの「@bilimboy」にメンションしてくれたツイートとかからもリダイレクトしたかったので、テスト用に作っていたアカウントのスクリーンネームをbilimboyにして、そこからsnowman__mhに飛べるようにしました。
GitHub
以前までは、「MasayaHayashi724」というなんとも面白くないusernameでGitHub活動をしていました。
GitHubのusernameはアンダースコアが使えないということなので、「snowman-mh」とハイフンを使いました。
リポジトリへのリンクは新しいusernameへGitHubが勝手にリダイレクトしてくれるそうですが、一応いろいろなところに置いていたリンクは新しいusernameに更新しておきました。
めんどくさかった。
リポジトリへのリンクをリダイレクトしてくれるので、ローカルリポジトリに登録しているリモートリポジトリのURLなどは変える必要はないそうですが、「MasayaHayashi724」というusernameのユーザが新しく登録されるとそのリダイレクトは切れてしまいます。
$ git remote set-url origin [新しいURL]
で変更することができるのでやっておいたほうが良いですね。
.gitconfigのuser.usernameは変更後のusernameに変更しておく必要があります。
Qiita
QiitaはGitHubと連携してアカウントを作っていました。
連携してるんだからGitHubのusername変わったら追従してくれるんじゃね、とか思ってましたが、それはさすがにありませんでした。
普通にQiitaのusernameは「snowman_mh」にしました。
連携しているGitHubはハイフンですが、気にしない気にしない。
Speaker Deck
Speaker DeckもGitHubと連携してアカウントを作っていました。
もちろん自動でusernameが変わることはありません。
こちらも「snowman_mh」にしました。
スライドへのリンクが変わってしまうので、リンクをどこかに置いていた場合は修正しないといけません。
connpass
connpassもGitHubと連携して登録していたので、connpassのusernameもsnowman_mhに変えようと思ったのですが、connpassはusernameを変更できない仕様になっていました。。。
表示名は変えられるのですが、usernameは変更できないことが公式で明記されていました。
残念です。
connpassはこれからもMasayaHayashi724で生きていくことになりました。
アイコン
アイコンはとりあえず、とてもおもしろいコレに統一しました。
はてなインターンで身につけた一生の財産
目次
はじめに
「はてなサマーインターン2017」の「ブックマークアプリコース」に参加してきました。
はてなインターンのいいところの1つに「体験談が豊富」というところがあるので、僕も学んだことをまとめたいと思います。
あ、応募するのを悩んでいる方がこれを見ているのなら、さっさと応募してからこのエントリーを読みましょう😃❗
インターンの内容
はてなのインターンは平日20日間で開催されるため、約1ヶ月間京都に住むことになります。
前半の10日間が講義パート(超楽しい)で、後半の10日間がチームに配属されての実践パート(超楽しい)になります。
前半と後半に分けて学んだことを残しておきます。
前半過程
すべてが繋がっていた
前半過程はPerlを使って日記サービスを作りながらサービス開発について学んでいく、という感じでした。
前半の内容はすべてが繋がっていて、独立した部分がほとんどありませんでした。
カリキュラムがよく設計されていてすごいなと思いました。
講義形式のインターンは最近増えてきていますが、さすが10年目の講義形式インターンなだけあるなぁと感じました。
講義や課題の詳細は他のインターン生が書いてくれるはずなのでここでは割愛します(お願いします、書いて)。
Perlは良い言語です
はじめに、Perlを触ったのは事前課題と前半過程の合わせて3週間くらいなので、そういうレベルのやつが喋っていることをご理解ください。
Perlについて思った印象は「全部俺たちがやらなあかんやん」です。
オブジェクト指向もWeb Application Frameworkも自分で(先人のすごい人たちの手を借りて)実現してあげないといけません。
しかし別にこれは悪いことではありません。
プログラミングの根幹部分となる基礎知識をしっかり身につけることができるため、プログラミング学習に向いていると思いました。
よってPerlは良い言語です。
実際のサービス開発をする上で良い言語かどうかは、残念ながら僕の経験では判断することはできませんでした。
学び方を学ぶ重要性
このIT業界は新しい技術がどんどん出てきて、今持っている技術がいつ廃れるかは誰も予想できません。
そんな世界で優秀なエンジニアとして活躍するには「学び方」を習得するのが一番簡単です。
はてなインターンの前半過程では、全体を通して様々なことを学びますが、それらすべてが綿密に設計されており、「学び方」が学べるようになっています。
「Perlを使ったサービス開発」を学べるのではなく(もちろん学べますが)、「サービス開発をする上で必要な知識と手法」を学ぶことができます。
つまり、言語や技術が変わったとしても、サービス開発を行うための知識や手法はずっと活きるということです。
はてなでPerlがたまたま利用されているから前半過程でもPerlを使っているだけです。
大事なのは言語ではありませんでした。びっくりです。
後半過程
最高のチームでした
後半過程は「はてなブックマーク」を開発しているブックマークアプリチームにお世話になりました。
同じコースに配属された
id:ishikawa_proと一緒に「クイックブックマーク」という新機能を追加しました。
実装やプレゼン、すべてにおいてサポートしていただいたチームの皆さんにはとても感謝しています。
チームのスピード感
毎日チームでランチ前に会議を行うのですが、たった15分という短い時間でその日やることを共有してチームの方向性を決めていくスピーディーな感じがとてもかっこよかったです。
小さいチームなので一度にできることは少ないですが、それでもあの開発スピードを維持しているのは、このような効率的な意識共有を行っているからだろうと思いました。
チームの規模にもよるとは思いますが、チームメンバー全員がそれぞれの力を最大限活かせるような情報共有の方法を考えるのが大事なんだと学びました。
コミュニケーション
ブックマークアプリチームでは、ディレクターとプランナー、デザイナーの方が基本的には東京で勤務しています。
そのため、コミュニケーションがとても重要になってきます。
Slackで会話をすることが多いのですが、僕たちインターン生も発言しやすい空気作りがされていました。
そのため僕たちインターン生も議論に参加しやすく、力を発揮できるような環境がしっかり築かれていました。
さらに、僕が開発を担当した部分がビューまわりを触ることが多かったため、実装したものを東京に勤務しているデザイナーの方に確認していただき、修正を行う、という作業を数回行いました。
もちろんデザイナーの方が見やすいようにGIFアニメに出力してGitHubに貼ったりすることは大切ですが、フォーマットの確認を行うこともさらに大切でした。
つまり、デザイナーの方がデザインを行うときに使用した画面・画像サイズを把握した上でそれに合わせたスクリーンショットなどを共有する必要があります。
また、iOSアプリにはiPhoneからiPadまで様々な画面サイズが存在するので、デザイナーの方がデザインを行う際に使用した画面サイズ以外のサイズでの見え方も共有し、デザインの修正などを行っていただく必要もあります。
デザイナーの方(リモート勤務含む)と連携してプロダクトを作っていくノウハウを学ぶことができました。
プレゼンの重要性
高専時代から英語プレゼンテーションコンテストなどに出場したり、KAKEHASHIプロジェクトに参加して企業の前でプレゼンを行ったりしていたので、プレゼンの重要性は十分理解しているつもりでした。
しかしその重要性は自分が思っていたよりも高かったことに気づきました。
前半過程の最後には自由課題として自分たちが作ってきた日記サービスにオリジナル機能追加を行いました。
そして、それについてのプレゼンを社員の方々に行い、投票によって順位を決めました。
僕は、「日記を書くと、日記の本文の応じて勝手にいい感じのオシャレな写真を添付してくれる」という機能を実装しました。
結果は8人中2位でした。とても嬉しかった。
技術的には僕よりもすごいことをしていた人はたくさんいました。
それでも良い順位をいただけたのは丁寧に作ったプレゼンのおかげだったと思います。
どのようにプレゼンを作れば良いプレゼンになるかを明確にできたわけではありませんが、プレゼンの重要性を再認識することができたのは良かったと思います。
自分のレベルが少し分かった
はてな以外にもサマーインターンはいくつか応募しましたが、受かったところもあれば落ちたところもありました。
今まで頑張って学習してきたけど、自分のエンジニアとしてのレベルはどのくらいだろうといつも思っていました。
今回のはてなサマーインターンに参加してみて、ほかのインターン生やはてなの優秀なエンジニアの方とたくさん交流しました。
その中で、自分のレベル感というものが少し分かったような気がしました。
簡単に言うと、高くも低くもないかな、という感じですが、自分の位置づけがなんとなく分かった気がして、モチベーションに繋がりました。
これは自分にとっては結構大きな進歩でした。
様々な環境に身をおいて、自分の実力を正確に判断することの大切さを学びました。
おわりに
まず、はてなのサマーインターンは最高でした。
最高という言葉では足りないくらい最高でした。
エンジニア人生をこれから送っていく上で死ぬまで役に立つ力がついたと思います。
僕が主に学んだことはこのエントリーに書きましたが、人によって学ぶことも違うと思います。
ぜひ他のインターン生のエントリーも読んでみてください。
そして、将来はてなインターンに参加する方がいましたら、ぜひ僕が学んだ以上のことを学んできてください。
余談たち
関モバ
はてなを会場として開催された「関西モバイルアプリ研究会」に発表者として参加しました。
人生初のLTをしました。
これからもチャンスがあれば勉強会に登壇していきたいと思います。
発表資料
speakerdeck.com
ホテル
今年から全員が一人部屋に泊まれるようになったみたいです。
来年は知りませんが、来年の人も一人部屋になるようにここに「一人部屋は最高だった」と書いておきます。
オフィスまで徒歩3分なところも最高。
疲れて帰ってきて汚い体で寝落ちしても、次の日にホテルに帰ってくると綺麗なベッドに戻っているのも最高。
晩ごはん
はてなインターンが今年で10年目なだけあって、オフィスの近くのうまいごはん屋さん情報が溜まっていて、インターン生に公開されています。
仕事が終わったらそのリストから今日はどこにしようか決めて食べに行くという感じでした。
ときどき社員さんに連れていってもらってご馳走してもらったりもしました。
全部うまかった。
飲み物とお菓子
はてなのオフィスにはボタンを押すだけで無限に飲み物が出てくる魔法の自販機があります。
もう何本「つぶたっぷり贅沢みかん」を飲んだのか分かりません。
https://www.pokkasapporo-fb.jp/products/fruit/other/GV48.htmlwww.pokkasapporo-fb.jp
さらに、いろいろな種類の軽食も食べ放題です。
朝出社すると、こんにゃくゼリーと豆乳を飲むのがルーチンになっていました。
傘
京都では「雨」という水みたいなものがときどき空から降ってきます。
そのときに「傘」というものを頭上に置くと濡れずに済みます。
京都に来る前に荷物に「折りたたみ傘」という折りたためる傘を入れましょう。
忘れてしまった方はご安心ください。
僕が現地で買った傘をはてなに寄付してきましたので、お使いください。
