Read
- Why Functional Prgramming
アドリング
- CPUバウンド
- Future
- Akka Actor
- I/Oバウンド
- コッチが大変
- AWSのDinamoがauto shardingしてくれる。
Twitterのサービス自体はシンプル。 だけど、ユーザが増えるごとにそれに伴ってスケールさせることでかなり苦労した。
micro serviceっていう考え方はTwitterでは当たり前だった。 こういう考え方でやらないと、Deployが大変だった。少し直しただけで、 全部Deployし直さないといけなかった。 なので、こういう考え方が良いと良いというわけではなくて、そうせざるを得なかった。
Futureの良い所は、コアを限界まで使う。 24コア使ってたけど、均等に限界まで使っていたのは感動した。 Futureの威力はすごかった。
implicit でContextを引き回すか、FPのテクニック(Reader monad)で解決するか？
Readerを使い出すと、ほかのFPとの関連も考えていかなければならない。 中途半端に使用するともっとひどいことになる。
implicitを使うと、コンパイル時間が多くなるがその辺は気にしているか？
Scalaのコンパイル時間を気にしたことはない。かとじゅんさん Framework作っててコンパイル時間が遅いから設計を変更するということまでやってない。せらさん GoogleやFBはそれぞれ巨大なバイナリを作ってdeployするっていうことに比べたら、Scalaのコンパイル時間を気にする程でもないかと niwさん コンパイル時間気にしながら書くよりも良いマシンを買うほうが費用対効果が良いのでは。 良いマシン買ってもらってます。ありがとうございます。
Scala Conf 2014のSessionの中に、Repository PatternのReader monad使って書いた例が紹介されていた。 https://www.dropbox.com/s/rl55ucna5a2ev3p/reader-monad-for-di.pdf
IntelliJでやっていてだんだん重くなるのがつらい。 そもそもIntelliJを頼っていないのでそんなにがっかりしない。(吉田さん) TwitterではIntelliJはよく使われている。けど遅いし、間違いも多い。 scala packageをimportしたがるのをコードレビューで消すっていうのが定番。gitのhookにあるくらい。 良い点は、大規模・大人数でひとつのRepositoryを触るには今のところベストなツール。 TwitterではMavenのかわりにPantsっていう自社ビルドツール作って使ってる。(niwさん)
Scalaはマルチパラダイムなので、書き方をどう同一するかは問題になるか？ app, infra, domainと各層に分けて全体のアーキテクチャを提案して、レビューしてフィードバックをもらってFixしてチームの設計方針を決めていた。(かとじゅんさん) varは甘え。関数型的な書き方が出来ないからvar使うのではなく、varを使うときは局所的に最適化したい時だけ。言語の想定している文化をリードが理解していることが大事。
OSSでJavaプログラマとRubyプログラムでチームを組んでいる。機能ごとにタスクを降っていたので、ある部分はRuby way、別の部分はJava wayっていうことはあった。 レビューで減らしていくのが良いとは思うが、現実的に理解を得るしかない。リーダーシップを取る人間が必要。(せらさん)
TwitterでもRuby, Java系の人がScalaを始めた。コードレビューで不毛な議論がある。 Repositoryごと単位ごとに一貫性を持たせる方が良いと思う。各側がコードを読んで、空気も読むことが大事。 一部分でコッチの書き方のほうが早いとかしても、全体で得られる効果は小さい。アメリカでも空気を読むことをやる。
いろんなBackgroundを持つ人がいるので、それぞれ好きな書き方がある。 勉強会（Functional Programming）をやっている。その上で、こういう書き方が良いのではというような合意をとりながら進めている。(あどてくの人)