Septeni Engineer's Blog

セプテーニ・オリジナルのエンジニアが綴る技術ブログ

PlayFramework 2.6.X のDIについて

これはScala Advent Calendar 2017の11日目の記事です。

こんにちはセプテーニオリジナルの池田です。

弊社では社内勉強会が定期的に開かれており
先月 @kawachiさんより「DIを正しく知って便利に使おう」という発表がありました。

私自身社内での勉強会を受ける前までは、javax.injectGuiceのDIが使われる背景やメリットをあまり理解していませんでしたが、発表を聞いて、DIの歴史的な背景やPlayでのベストプラクティスな使い方など勉強になりました。

今回は、勉強会の復習にPlayFrameworkのDI周りについて書きます。

続きを読む

9/11に初めて登壇しました

こんにちは、たかこです。
社内でジョブチェンジしてScalaエンジニアになりました。

9/11に初めて登壇していて、登壇までの個人の流れを書きます。

会社として参加記事は @takashima0411 さんが書いてくれた、こちらをどうぞ。
Scala関西Summit2017に参加してきました! - Septeni Engineer's Blog

そもそもどうして発表しようと思ったのか。

社内でScala関西に参加する出張者を公募するチャットが流れていたのを見て、
下記の2点の理由で応募しようと思いました。
1. Scalaのイベントに参加して、色々社外でもScalaのことを学んでみたいと思った
2. 地元が和歌山なので大阪で務めている友達が多く久々に会えるなあと思った

ただ、この時点でScalaを学んで2ヶ月もたってなくて、わかるセッションがあるのか不安でした。
外部のScala講師の方に、私でもわかるレベルのものもあるのか確認して、
社内でも倍率高いんですと雑談していると
「発表者になれば大胸はっていけますよ」と言われ「確かに」と思って発表を申し込みました。

資料作成

8月中旬ぐらいから資料を作成して月末に参加者で社内練習会 + フィードバックをやりました。
社内のうちはマサカリ投げるよーと、たくさんご指摘いただきました。
その中で1番響いたのは、
Scalaを4ヶ月 *しか* やってないのではない、4ヶ月 ** やっているんだよ。」
という言葉で、資料の構成を作り直しました。

その間、最初からずっとレビューし続けてくれた
@morizo999 さんと @paralleltoさんには頭が上がりません。
いつも本当にありがとうございます。
(発表が終わってから、みんなでスタバのラテを楽しく飲みました)

登壇してみて

結果からいうと、時間が足りるか焦って、早めに終わってしまいました。
だめだったと思っているのは下記2点です。
1. 事前の練習では20分少し超えるぐらいだと思っていて、その20分に質疑応答が含まれていると思ってなかった。
2. ↑の原因で、早めに終わらさなきゃとすごく焦ってしまった。

次回がもしあれば、ちゃんと事前に確認して練習通りゆっくり話せるようにするか、
焦りを考慮してもう少し長めのスライドを作るようにします。

アンケート結果を見て

概ね満足していただけたようで、すごく嬉しかったです。
同時に勇気を出して挑戦してみて良かったなぁと思いました。

最後に

本当に社内・外を含めたくさんの方に助けていただきました。
ありがとうございました!

日本語とScalaでプロダクトを作る

LoLの世界大会から目が離せない高嶋(@takashima0411)です。
SKTvsRNGはあまりに熱い展開でした。
話は変わりますが、この度短命で規模の小さいプロダクトを作成する機会に恵まれたので、
普段は英語でコードを書いているところを日本語でコードを書いてみました。
とは言えすべてを日本語にしたわけではなく、DDDを意識し、ドメインモデルに相当しそうなとこだけ日本語にしました。
以下その感想をまとめてみました。
(注意: 筆者の英語力は英語ドキュメントなら辞書を引きながらなんとなく読める程度です)

環境

今回の開発環境は以下のような感じです。

  • 開発用マシン: MacOSX
  • IDE: IntelliJ 2017.3
  • 言語: Scala 2.12
  • ビルドOS: AmazonLinux (latest docker image)

ハマリポイント

弊社では現在CIにgitlabを導入試験中です。
gitlabからビルドさせるためにDockerを利用するのですが、ここでは少し注意が必要です。
AmazonLinuxのDockerイメージのlocaleに「ja_JP.utf8」が含まれていません。
なので入れてやらないとビルドが出来ないのでご注意ください。
今回はサボってyum updateで対応しました。
ちなみにエラーメッセージは以下のように日本語になっている部分が「????」となって表示されます。

/builds/Hoge/project/routes: 5: Compilation error[')' expected but '?' found]
GET      /fuga/     controller.Controller.index(????, ??????)

良かった点

変数名で迷わない

例えばSeqfilterした後、英語が堪能ではない僕は説明的な変数名を付けるのが下手なので甘えてfilteredとしたり、
そもそも変数にしなくても良いようにひねったり、できるだけ短い変数名にしてお茶を濁すことがあります。
言うまでもないですが、これはあまり褒められたものではありませんよね?
filteredという名前は後から見返したときに「filter」してんのは見りゃわかるんだよ!!!!ってなりますよね。
そうではなく、filterした後のSeqが何を表しているかなどがすっきりかけて快適でした。

POと同じ言葉を使える

今回はスピード優先であることもあり厳密にはPOと言葉の統一をできなかったのでここは感想です。
DDDではPOや顧客を始め業務に関わる人々がが話す言葉に耳を傾け、同じ言葉を用い、彼らと開発者の間で無駄な翻訳が発生しないようにすることが大事だとされています。
しかし、英語でプログラムを書いてしまった場合、POが日本人である限り絶対に日本語から英語への翻訳が発生してしまいます。
僕のように英語が堪能でない人が間に入った場合はそれはもう最悪で非常に小さいボキャブラリーからそれっぽい単語を選んでいくことになります。
本来必要であった意味が抜け落ち、POが見てももはや意味不明な物体が出来上がります。
さらにはPOに英語でいうとこれなんですかね?とかいい始めPOの仕事まで増えて本当に酷い感じですよね?
しかし、ドメイン周りだけでも日本語に統一すればそういった心配は一切なくなります。 普段はPOと一緒に言葉を決定していって、コード上の表現用の英語の対応表を用意したりしていますが、
後者のコストをなくすことが出来たらうれしいですね。

よくなかった点

拭えない違和感

今までやってこなかっただけに日本語の出現には違和感があります。
しかもScalaシンタックスでは英語が使われるため英語と日本語が混在するため強い意思がなければ全部英語にしたほうが良いと感じそうです。

IDEの操作性

日本語で入力する際に入力を切り替えることになりますが、結構な頻度で切り替えることになるので割りと面倒です。

Ubuntuとの相性

僕の設定不足もありますが、あまり相性がよくありません。
例えばIntelliJCtrl + Nでクラス名を検索する際に日本語が入っていると文字化けして□が表示されてしまうなど。
なおMacOSXでは特に問題ありません。(日本語設定で使ってる分には)

ビルドでハマる

基本的にはLANGなどを適切に設定しておけば問題ありませんが、場合によってはハマリポイントのように問題が発生する可能性があります。

まとめ

総合的に見ると多少面倒な部分もありますが、慣れれば解決する範囲ではないかと思います。
英語が堪能ではない僕にとっては変数名やクラス名で迷うポイントは減ったように感じます。
メンバーが日本人ばかりで、将来的にも日本語が扱えないメンバーが入る予定がなければいい選択肢になるのではないでしょうか?