はじめに
2019年4月に株式会社L is B（エルイズビー）に新卒として入社しました、石川です。
この記事では、定期的なアウトプットによる知識定着向上のため、入社してから 1 週間の間に学んだことをまとめています。 （本当は入社してから 2 週間目なのですが、初週は入社式があったり、AI・人工知能 EXPO に 3 日間駆り出されていたりとエンジニアらしい業務は全然していませんでしたので…）
弊社の平成最初で最後の新卒の新入社員は2名でした！わざわざ入社式を開いて下さりありがとうございます！
====
自分はサーバーチームの配属なので、開発に使用している Docker、Java についての勉強からです。
さっそく教育係の持田氏と阿部氏がビシバシ教育して下さりました！ありがとうございます！これからもよろしくお願いします！
以下学んだこと。
- Twitter アカウント作成
- Docker
- コマンドの基本操作
- イメージの起動・作成
- Docker Compose
- Java
- TDD (JUnit4)
- DI (Guice)
- Lambda 式
- Stream
- Optional
Twitter アカウント作成
持田氏「とりあえず Twitter アカウント作ろう」
今時のイケてるエンジニアになるには Twitter が必須らしい。 最新技術の動向や勉強会の情報などはここで手に入るそうな。 今まで Twitter や Instagram、Facebook などの SNS はやったことなかったのでわくわくどきどき。
そんなわけで Twitter アカウント作成しました。 （https://twitter.com/comecouji）
Docker
コンテナと呼ばれる実行環境を構築し、その中でアプリを実行させる。そのコンテナを起動するのに必要な設定ファイルをまとめたものをイメージという。一度作成したイメージは Docker がインストールされている環境ならどこでも同じように動作する。
持田氏が用意してくれた Docker 入門（https://github.com/mike-neck/start-docker）を使用。
以下思ったこと。
- 実行内容と実行環境をひとまとめにして利用するという発想がすごい
- 研究室にいたとき、複数のサーバーをたちあげては一つ一つ環境設定してたけど、Docker さえいれればそんな手間はいらない（もっと早く知っていれば…）
- もうこれからは全部 Docker でいいじゃん（でもコンテナが死んだり色々問題もあるらしい）
Java
TDD (Test Driven Development)
日本語でいうと、テスト駆動開発。
ふつうプログラムをつくるときは先に実装をかいて、あとでデバッグやテストをするけど、TDD では最初にテストをかいて（テストファースト）、そのテストが動作する必要最低限な実装をとりあえずおこなったあと、コードを洗練させるという工程を繰り返してプログラムをつくっていく。
持田氏が用意してくれた入門（https://github.com/mike-neck/java-training-book/tree/master/junit4）を使用。
実際に問題をモデル図にかいて、テストとその実装をつくりました。問題は会津大学のオンラインジャッジ Volume5 – 0513（http://judge.u-aizu.ac.jp/onlinejudge/description.jsp?id=0513）を使用。
以下思ったこと。
- 先にテストをかいてから実装をかくという発想がすごい。違和感ある。（でも要件をきっちり満たすテストをかいて、それがすべて通るように実装をかけば、自動的に要件もすべて満たすことができるという理屈はなるほどと思った。）
- RED -> GREEN -> Refactoring のサイクルを繰り返していくけど、最初にあえて失敗するコードをかくというのはなかなか慣れなかった
DI (Dependency Injection)
日本語でいうと、依存性の注入。（なんのこっちゃ。）
大きなアプリケーションをつくると、クラスの依存関係が非常に複雑になってくる。 例えば、クラス A はフィールドにクラス B のインスタンスをもっていて、クラス B はフィールドに クラス C とクラス D のインスタンスをもっていて、クラス E はフィールドに…(以下略)といった感じ。
ほかのクラスに強く依存しているクラス（この例だとクラス B ）をインスタンス化しようとすると、クラス B が依存しているほかのクラスもインスタンスをつくらなくちゃいけないので面倒。
ほかにも、外部の API に依存している場合、本番環境での API とテスト環境での API を切り替える必要があり、これまた面倒。
これらの面倒を解消してくれるのが DI 。
持田氏が用意してくれた入門（https://github.com/mike-neck/java-training-book/tree/master/dependency-injection）を使用。
以下思ったこと。
- 練習問題は解いたけど、本当に便利だなあと実感するには、実際の開発のようにもっと複雑なコードでやってみないとわからないと思う
- DI の日本語訳はやっぱりよくわからない
Lambda 式
Override するメソッドが一つのみの interface を FunctionalInterface と呼ぶ。Lambda 式はそれを簡潔に記述できる仕様のこと。
以下思ったこと。
- 前に JavaScript をちょこっとやったことがあるけど、似たような書き方をしていたような
- これ単体ではあまり威力は実感できない。真骨頂は次項目の Stream と組み合わさったとき
Stream
大量データを逐次処理するストリーム処理を効率的に記述できる手段のこと。コレクション操作も効率的に行える。
以下思ったこと。
- Linux のパイプ処理はよく使っていたので、データを加工・フィルタリング・出力するという流れはすんなり受け入れられた
- 前述の Lambda 式の威力を実感できた。（コードの記述量が減るのもだけど、直感的にかけるのはすごく便利）
- プリミティブ型のストリームだけ特例的な扱い(IntStreamとか)でやらなくちゃいけないのは解せない（Java の後方互換とか昔の仕様のしがらみが原因らしい）
Optional
null が入りそうな変数をラップして、安全に使用できるようにしてくれるクラス。
以下思ったこと。
- null を if 文でチェックせずにスマートなコードがかけるのは良いと思った
- Optional#get() は絶対使っちゃだめ（null のときいい感じに処理してくれるための Optional なのに、生のデータを取り出すのは本末転倒。ifPresent とか使おう）
- どの言語でも null の扱いは厄介だと思う
まとめ
- 弊社のサーバーチームが開発に使用している Docker、Java についての勉強をした
- まだ数えられるほどしか触れてないけど、学んだ技術の便利さを実感できた（DI 除く）
- 技術を理解する能力も大事だけど、技術の存在自体を知っていることも同じくらい大事だと思った
- せっかく便利な技術があっても、知らなきゃ使えない
- Twitter などで情報収集しよう
- 教育係のお二人が博識すぎて話についていけない（技術と雑学の両方面において）
- 精進します