More Related Content
Similar to Scala/Scrum/DDD 困ったこと50連発ガトリングトーク!! (20)
Scala/Scrum/DDD 困ったこと50連発ガトリングトーク!!
- 10. 解決法
Driver / Executorのどちらで実行されるかを意識する
// 各ExecutorNodeで一度だけ実行される
lazy val unserializableObj = createUnseriarizable()
// DriverNodeで一度だけ実行される
val serializableOneObj = createSeriarizable()
sc.parallelize(1 to 1000).map(v => {
// RDDの操作の処理はExecutorの中でレコードの数だけ実行される
val temporaryObject = createTemporary()
exec(unserializableObj, serializableOneObj, temporaryObject)
}).saveAsTextFile("s3://my-bucket/object")
10Sparkでserializableじゃないオブジェクトを転送してしまう - opt(発表者:柴田)
- 27. 異種のモナドをまとめてシンプルに扱いたい - opt(発表者:岡田) 27
shapeless・・・型の力を活かしてboilerplateを排除できたりす
る(悪名高い)便利ライブラリ
例えばLabelledGenericを使うと、case classに値を追加して
別の型のcase classにcopyみたいなことが(runtime
reflection使わずに)書ける
- 34. Implicit conversionは Ctrl + Shift + Q (Linux)
・1はDurationIntに変換されてるらしい。
34doc見てもこんなメソッド定義されてないよぅ(implicit conversion)- opt(発表者:柴田)
- 35. Implicit parameterは Ctrl + Shift + P (Linux)
・?がtimeoutをimplicitで使ってるらしい。
(言うまでもないが「?」はactorのメソッドでドットと括弧が省略されてる)
(ちなみにこのactorもActorRef → AskableActorRef へ変換されている)
(sender()もimplicit parameterだが、ここではデフォルト値なので無視)
(vim/emacsはどうすればいいですか? → 知らんがな)
35doc見てもこんなメソッド定義されてないよぅ(implicit conversion)- opt(発表者:柴田)
- 41. playframework 2.2だったGANMA!を2.5にするとき死ぬほど大変
だった
41playframeworkのバージョンアップが辛い - セプテーニ・オリジナル(発表者:杉谷)
2.2 -> 2.3(あんまり大変じゃない)
○ コマンドが play -> activator。 ビルド・デプロイ周りを修正した。
○ MigrationGuideに従うだけであんまり苦労しない
2.3 -> 2.4、2.5(超大変)
○ Java8化 。Java8環境でパッケージ作成 → Java7環境にデプロイ → 死
○ DI導入。 Objectを使いまくっていると死ぬ。import play.api.Play.currentでお
茶を濁せるが、2.5でdeprecated指定
○ anormの文法ががっつり変わる。ConnectionPoolがHikariCPに変わり、設定
も挙動もがっつり変わる
○ GlobalSettingsが滅ぼされる
○ confの記述が結構変わる
- 42. 実際にやったときの大変さ
● なんだかんだで1ヶ月くらい修正にかかった
● 全てのファイルが書き換わった
● 現行コードの修正は日々進むので git pullっては2.5化する
日々
● リリース時に問題は大量に発生した
○ 意外とコード本編の移行は問題はあんまりなかった。
○ 殆どはconfの構造変更時の移植ミス。confの記述が変わるからと、ついでにリ
ファクタリング(環境別に1ファイル → ファイルを分割してincludeする方式)に
したのがまずかった…
得られた教訓
フレームワークの更新は素早く小刻みにやりましょう!!!
42playframeworkのバージョンアップが辛い - セプテーニ・オリジナル(発表者:杉谷)
- 44. DAO実装のボイラープレート化- セプテーニ・オリジナル(発表者: 木村) 44
(困った)
scalaプロダクトが2,3個立ち上がったところで、同じような実装をし
ていることが検出された
(解決)
DAOの実装コード/テストコードを自動生成できないかを模索し、
具体的なストレージ技術に依存しない(ただし、JDBC依存)自動生
成ツールを企画・開発
sbt-dao-generator
- 2つのプロダクトで動作中(3プロダクト目検討中)
- テーブル定義が固まれば、generateしてDAOができる
- 筆者のプロダクトではSkinny-ORMで利用するORM生成して
いる
- 67. ◆解決法
認定済みベンダーに 4th party tracking してもらう
(当たり前)
◆背景(おまけ)
ユーザーのプライバシーを守りながら、
企業のマーケティングを推進するために、
インターネット広告業界には色々な取り組みがあります。
- 広告入稿時の審査
- 各プラットフォーマーによる認定制度
- 国際業界団体(IAB)による標準規格策定
- 業界団体(JIAA)によるリテラシー向上施策(勉強会や分科会)
- オプトアウトの標準化(NAI, DDAI)
674th party tracking ができなかった - opt(発表者:平岩)
- 76. DynamoDB Table (RCU 120, WCU 60)
AWS DynamoDB はパーティション毎にシャーディングされて
データが格納されており、キャパシティ(RCU/WCU)はパーティ
ション数で分割される
- パーティション数はデータ量などで決まる(ぐぐれば計算式出
てきます)
- どのパーティションに格納されるかはHashKeyで決まる
- HashKeyがランダムでないと、特定のノードに偏って格納され
る
パーティション
RCU 20
WCU 10
パーティション
RCU 20
WCU 10
パーティション
RCU 20
WCU 10
パーティション
RCU 20
WCU 10
パーティション
RCU 20
WCU 10
パーティション
RCU 20
WCU 10
データ
HashKey
76DynamoDBのキャパ問題 - opt(発表者:平岩)
- 77. DynamoDB Table (RCU 120, WCU 60)
パーティションがたくさんある状況で、アクセスが特定のパーティ
ションに偏ると、設定しているキャパシティよりも遥かに低いI/O負
荷でキャパオーバーとなってしまう
<解決法>
HashKeyがランダムでない場合
→設計を見直して、ランダムにしましょう
HashKeyがランダムなのに集中してしまう場合
→厳しい。かなり余裕をもってキャパシティを設定する、
祈る、設計を根本的に見なおす、自前でさらにシャーディングする etc…
パーティション
RCU 20
WCU 10
パーティション
RCU 20
WCU 10
パーティション
RCU 20
WCU 10
パーティション
RCU 20
WCU 10
パーティション
RCU 20
WCU 10
パーティション
RCU 20
WCU 10
RCU 20, WCU 10 に
収まらなければキャパオーバー
77DynamoDBのキャパ問題 - opt(発表者:平岩)
- 142. セプテーニ・オリジナルの場合
1. PHPでイケイケで作った結果破綻し、”ちゃんとやる”の気運が高まる
2. GANMA!を当時の流行(Scala / DDD / TypeScript / etc …) で作成
3. GANMA!チームに別チームから留学
4. 留学終了。 かとじゅん氏(前職の同僚・DDD伝道師)にアドバイザー※として参加し
てもらいつつ新規プロダクトをScala + DDDで作成
5. どんどん株分けが進み、全てがScala + DDDとなった
6. 新しい方ではヘキサゴナルアーキテクチャを採用するなど進化も進む。GANMAが
古くさく見える勢い…
※ぼったくりにあいお金に困ったかとじゅんが、杉谷に相談をしたことから始まった副業。
絶讃ご依頼承り中とのこと。 ご依頼は@j5ik2oまで。 (土日可動前提)
142言語・技術に対する宗教論争・普及の道のり - セプテーニ・オリジナルの場合(発表者:杉谷)
全アクティブプロダクト
Scala ・ DDD採用率
【100%】