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などを適切に設定しておけば問題ありませんが、場合によってはハマリポイントのように問題が発生する可能性があります。

まとめ

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

Eコマースサイトを作るチーム研修を受けました

はじめに

こんにちは、2017年BNの張です。

四月からセプテーニ・オリジナルに入社しました。

入社してから半年も経ち、毎日充実した研修生活を送っています。

色々な研修がありましたが、その中でも2ヶ月で行ったチーム開発について書きたいと思います。

チームメンバーは新卒3名、それぞれに先輩のメンターがついてPOも別でいます。

開発内容 - Eコマースサイトを作る

チーム開発の課題は、Eコマースサイトを作ることでした。あらかじめ最低限の要求(ストーリー)が用意されていましたが、フレームワークアーキテクチャなど、どのように開発を進めるのかは全部自分たちで決めました。

目標は「2ヶ月でとにかく動くものを作る」でした。

最初心配していたこ

  • Scalaの研修が終わったばかりなのに、ちゃんとプロジェクトでScalaを書けるのかが心配でした。

  • PlayFrameworkの使い方がわかりませんでした(そもそもフレームワークに触れたことがほとんどない)。

  • 開発の経験がないので、全く土台のない状態で一からどうプロジェクトを始めればよいのかが想像できませんでした。

  • チームワークなので、うまく進めるのか、自分がやっている作業が時間内に終わらせることができるかどうかが心配でした。

開発準備

  • 開発に入る前

PlayFrameworkの勉強を一週間かけてやりました。主にDocumentを読みながら、サンプルコードを読んで、手を使って実際に動けるものを作ってみました。

BootstrapのDocumentも読んで、Viewをどうやって作っていくかを学びました。

  • 全体的なプランニング

三人で初めてのチームミーティングを開きました。

やり方はほとんど経験の一番ある人が決めてくれました。(PlayFrameworkを使うや、Viewの方はBootStrapを使うなど)。POと定期的に相談することで、アドバイスなどをもらいました。

開発の流れ

  • 設計

  • チケットの追加:ストーリを分析し、チケットを追加し、サブタスクを作りました。

  • 画面の設計:実際にどんな画面を作っていくのを決めます。紙に書いて、POにみてもらって確認してもいました。

  • データーベースの設計:テーブルを全部羅列し、テーブルの内容まで決めました。

  • 見積もり:一つ一つのチケットにどのくらい時間がかかるのかを見積もり、プロジェクト完了までにかかる時間を予測して計画を立てました (全てやると8月21日に終わり、省エネプランなら8月14日に終わる予定でした。予定通りでしたらちょうど8月中旬に終わりそうでした)。

  • スプリント決めとタスクの振り分け

タスクの重さを整理してから、スプリントも決めました。今回のスプリントはほとんど一週間を1イテレーションとしました。(コーディングとレビュー、レビュー修正の時間も含まれてます)

一つのスプリントが終わり、次に入る前にミーティングをし、振り分けをします。振り分けは、機能や内容に合わせてタスクを振り分けていきます。

  • コーディング開始

  • 最初の作業:自分は最初にViewの部分を触りました。BootStrapのDocumentを読みながら、最初はサイトのヘッダーを作りました。しかし、それはViewの部分だけで、実際にデーターベースコントローラの部分は触っていません。

  • 未経験の作業に入る:一つの機能を全部やらないとこの研修の意味もないと思い、商品部分の機能をやってみました。まずは商品の登録機能でした。まずPlayFrameworkのサンプルコードを読んで実際に書いてみることから始めました。動くまでは色々なエラーが出てきて、最初はどこから手をつけていけばよいのかわかりませんでした。メンターさんに助けてもらい、エラーの原因を一緒に探し出し、直しました。そのあとは商品の編集、削除など、それに商品カテゴリーに関する機能も実装しました。作業を進めるにつれてだんだんと理解が深まり、より早く実装ができるようになりました。自信がつき、不安が少し消えました。それからは新しいスプリントに入り、自分は商品名とカテゴリーで商品を検索する機能の実装をしました。そこまで割と順調でした。

  • 二人のチームになった:8月中旬にメンバーの一人が先に配属され、残った一つのスプリントは二人でやることになりました。リーダーが抜けてしまったので、また不安になりました。残った機能は主にメッセージ機能と、購入する時にポイントを使用する機能でした。自分はメッセージ機能をやりました。メッセージはアプリケーション内で完結する機能だったので、これまでに得た知識を生かすことで案外早く実装を終えることができました。そのあとは色々バグを探し出し、直したりバックログのチケットをやりました。最後の発表は順調でした。

躓いたこ

  • Documentを読んでも実際に書かないとわからないことが多かったです。

  • チケットのやり方のイメージがなかなかつかなかったです。

  • パラメータの数が多くて、途中書き忘れがちで、エラーが出てきます。

  • エラー処理の種類が多くて、どのようにViewにうまく表示させるのに工夫しました。

どのように解決したのか

自分の場合、要するには勉強すること、サンプルコード読むこと、自分で調べること、人に聞くことです。うまくやっていくためには勉強することが必要で、勉強する方法も重要です。時間が少ないため、サンプルコード読むのが一番早いと思います。サンプルコードを読み、真似しながらやっていくと割とスムーズでした。もちろんそのあと、なぜそうなるのかを説明できるように勉強する必要もあります。エラーが出る時は、直接に聞くと早いと思いましたので、メンターさんにエラーの解決法を教えてもらいました。結果、自分もエラーを解決することができるようになりました。

開発で学んだこと

  • やる前に設計をちゃんとやる:今回の開発でスムーズに進めることができたのは、きちんと設計を行ってからコーディングに入ったおかげだと思います。

  • プログラミングスキル:学んだScalaの知識は応用できてよかったと思います。それに、昔はコードの書き方や命名規則など全然気にしていなかったのですが、今回のチーム開発を通し、「分かりやすいコードを書く」を意識しながら書きました。これから、綺麗なコードが書けるように頑張っていきたいと思います。

  • 他人の力を借りること:時間は有限です。今回は他人に聞かずに長時間自分で調べたりして、失敗してしまう経験がありました。もちろん自分が考えて調べるのが非常に重要ですが、時間を浪費するより先輩に聞いた方がいいと思います。

感想

大変な二ヶ月でしたが、貴重な経験をすることができて本当によかったと思います。

未経験の作業ですが、なんとか勉強してから完成できましたので、少しでも達成感を感じました。

確かにコミュニケーション不足やわかっていないことを共有できていなかったという色々な問題点もありましたが、今後の作業で注意できると思います。今回の開発から学んだこと、少しでも身につけたスキルなど、今後の開発で活用できればと思います。