Tweetこんにちは。今日は、先日行われたアジア最大のScalaカンファレンスであるScalaMatsuri2017の参加レポートです。レストランの検索機能を始めとしていくつかのプロジェクトでは部分的にScalaの導入を始めており、今回も検索機能に携わるメンバー数名で参加してきました。私自身、まだそれほどScala経験豊富ではないので、若干理解が浅いところもあるかもしれませんが、以下はいくつか参加したセッションのうち、印象に残っているものの簡単なまとめと所感になります。Scala先述の通り、ぐるなびではScalaは部分的に使い始めていますが、Scalaエンジニアの数は、PHPのエンジニアに比べてはるかに少数派です。PHPなど他言語のエンジニアと話している中で、「Scalaって、なんだか複雑で読みづらくない...?」という声を聞くことがたまにあります。Scalaのどの辺りが「読みづらい」か、というのは人によってまちまちだと思いますが、このセッションでは、「読みやすい(Readable)」コードを、名著「リーダーブルコード」に則り、「どれだけ早くそのコードを理解できるか」と定義し、一見複雑に見えるScalaのコードが、Scalaの作法に則って書かれているものである限り、実は読みやすい(Readable)ものである、というお話でした。Scalaに関して「読みづらい」と槍玉に挙げられる三つの文法について解説が行われていました。記号識別子について時々メソッド名などに記号が使われる事について。読み手が記号の意味について理解さえしていれば、メソッド名等を英文で定義するよりも、記号の方がコードを早く理解することが可能ということでした。b」と書くのと、「a.multiply(b)」と書くのでは、どちらが「早く理解できる」か。Parametersの目的は、「何(What)を実現したいか」と「どうやって(How)実現したいか」を分離すること。それによって「何(What)」が端的に表され、コードがReadableにできるという話でした。Parametersの用い方は、コードをReadableではなくしてしまうので注意が必要ということです。conversionsの目的は、定義を変更できないクラスにメンバを追加すること。conversionsでメンバを追加した方が、読みやすさは向上するということでした。所感としては、記号識別子についてもimplicit修飾子にしても、確かにReadableである事に寄与しているかと思うのですが、Readableであるためには、開発者間でScalaの様々な思想が前提として共有されている必要があって、これからScalaエンジニアを社内で育成する場合、それをどうやったら伝達いけるか、というところに課題感を持ちました。Scala/登壇者:中村学(がくぞ)さん新サービスをゼロから開発してローンチするのに大切だった3つのことTwitter社の事例。Railsで作られていたモノリシックなアプリケーションを、マイクロサービスに分割していく中で得られた知見の紹介でした。モノリシックなアプリケーションをサービス単位に分解してScalaで書き直し、個々のサービスを一つの関数としてみなし、非同期に呼び出して、再度合成するという、「関数的な」アーキテクチャを採用したという話です。同日に行われたChatWork社の事例についてのセッションもそうですが、サービスのスタート当初にLLでスピード優先で作られた巨大なアプリケーションが、技術的負債によって、性能やメンテナンス性の限界に達して、マイクロサービスの形に作り直していく、というのは、ぐるなびのサービスも同様の問題を抱えているため、興味深い内容でした。いう部分が特に印象に残っています。技術的負債が増える原因を、システムに関して何かしら間違った想定をもとに開発してしまうこと(おそらくそれは机上の空論に基づいて開発に着手してしまう事だと思うのですが)として、それを避けるために、プロダクトマネージャーからの新しい要求に答える際には、なるべく早く、上流から下流までのすべてのサービスをつなげてとにかく動かし、想定をしなければならない事をなるべく減らす、というアプローチを取っているという話が印象に残ってます。いった形の一種のプロトタイピングは、手が早い人が多いからできるんだろうな、とも思います。チーム全体としてどうやって生産力を高めているのか、もっと深く聴いてみたいセッションでした。Niwaさんメタメタにしてやんよ。すすめ)ちょっとしたフレームワークのようなものを作ろうとして、Scalaのマクロと格闘したことがあるので、個人的に興味深いセッションでした。ボイラープレートを減らすこと等を目的にしてメタプログラミングを行う時に、scala.metaなどを使うのも良いですが、場合によってはShapelessというライブラリを使うとよりスマートにできる、という話でした。Shapelessは、うまく使えば確かにボイラープレートを減らすことができるのだと思いますが、個人的には「ここが使いどころだ!」という勘を身につけるまでが時間かかりそうな気がしました。こちらのガイドを(英語ですが)頑張って読むところから始めようと思います。[GitHub]underscoreio/shapeless-guideスライドはこちらメタメタにしてやんよ。Architectureについての論議が盛んですが、Scalaで実現するにあたって良いプラクティスはあるのかと、かねてから疑問があったので個人的に興味深いセッションでした。特定のプラットフォームへのロックインを避けるために、何かしらの形でドメインロジックをプラットフォームに依存するコードと切り離す必要があるのかな、とは漠然と考えていましたが、このセッションではヘキサゴナルアーキテクチャによってそれを実現したという実例を聞けて参考になりました。ArchitectureをScalaで構築するぞ/登壇者:藤井善隆さんまとめ先述の通り、ぐるなびはまだScalaに関してはそれほど多く知見があるわけでなく、今回一緒に参加したメンバーも実務経験一年未満の人間が多かったのですが、そんな中で、この道の先駆者の方々の話を聞けて非常に勉強になりました。26日には板前さんがその場で握ったお寿司がでましたセッション自体も興味深いのですが、当日は美味しいお弁当が出たりお寿司が出たり、至れりつくせりで、非常に楽しい時間を過ごすことができました。Scalaのお祭りですね。来年もぜひ参加したいと思います。お知らせぐるなびでは一緒に働く仲間を募集しています。google.setOnLoadCallback(initialize);スターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。