市場への興味
7月に開催された Yahoo! Japan の Hack Day では最優秀賞は「日米為替における予測モデルの提案と評価 – 機械学習による為替予測AIの実装」というテーマのチームが選ばれたという記事を読んだ。どのような結果をだして最優秀賞に選ばれたのかとても気になるところである。
「異例中の異例? モノをつくらずに受賞」(Hack Day最優秀賞編) - Yahoo! JAPANコーポレートブログ — 「異例中の異例? モノをつくらずに受賞」(Hack Day最優秀賞編)
最近は市場が面白くて、金融についての書籍を気の赴くままに読んでいたりする。 数字の上下とそれを統一的に説明するような構造の理解には興味をそそられる。 直近読んだ書籍で面白かったのはこちら
- 作者: 松葉育雄
- 出版社/メーカー: シーエーピー出版
- 発売日: 2014/10
- メディア: 単行本
- この商品を含むブログを見る
千葉大工学部の先生の書かれた本で、日経平均の過去データを使いながらそれがどのような統計的性質を持っているかを教科書然として分かりやすく説明している。 例えば、株式市場の値動きは基本的にはほぼランダム・ウォークであるということは広く知られているが、それを実際に確認する。 日経平均や為替やトヨタの株価などの自己相関関数をプロットしてみても、95%の信頼区間の中に収まるという。その程度ではランダムに相場は上下しているのである。
現代のポートフォリオ理論の前提となる考え方に「効率的市場仮説」というものがある。市場は効率的であり、すべての情報は一瞬のうちに価格に織り込まれてしまうという考え方だ。 価格決定モデルとしても有名なブラック・ショールズ・モデルもランダム推移を前提としている。
それでは、株取引における経験則やテクニカル分析などは全てデタラメなのだろうか。 そのような疑問を解消しようというのがこちらの本の目的の一つでもある。
テクニカル分析が成功するのは、データに時間相関があり、その時間相関を引き出せるようなテクニカル指標が利用できる場合に限られる。従来の指標がそのような性質を持ち合わせたものだろうか、この疑問に答えるのが本書の1つの目的である。時間相関があるからこそ、将来がある確率でもって見通せる。 (中略) 本書では、テクニカル分析に利用価値があるのか、どのような場面で価値があるのかを数学的に調べた結果を著した。最も重視したことは、テクニカル分析は金融デーtあに対していったい何をしているのか、売買のタイミングの適切な出し方を算出しているのか、時間相関を通してこれらの疑問に答えることである。
テクニカル分析に用いられる指標には大きく分けて2つあり、本書ではその中でも幾つかの指標について定義を与え、その指標が実際の市場でどの程度有効かを確認している。
まあ、もちろん、これらの指標が完璧にワークして今直ぐ市場で大儲け出来るような話にはならない。 しかし、このように市場がどのような性質をもって動いているのかを数学的に記述する試みは面白く、正に自分が読みたかった本だったというわけだ。
「効率的市場仮説」を前提にしたランダム・ウォークで全ての動きが説明出来るわけもなく、直感的にもそれは分かる。 例えば本書の中では、ランダム・ウォークから外れる動きをイベントやアトラクターなどと呼んで信号処理分野のインパルス応答に見立ててモデル化している。 リーマン・ショック後にブラック・スワンなんて書籍が流行ったのもまさにそのその脱効率的市場仮説的な流れだろう。
冒頭の Hackathon の為替予測みたいに、昨今の機械学習の発展と共に市場の適用も増えていくのだろうか(現状どれほど導入が進んでいるのかは知らない)
一方で、自動取引が加熱しすぎた結果についての批判も生まれていて、これはオンゴーイングな議論の的でもある。
- 作者: マイケルルイス,Michael Lewis,渡会圭子,東江一紀
- 出版社/メーカー: 文藝春秋
- 発売日: 2014/10/10
- メディア: 単行本
- この商品を含むブログ (14件) を見る
ねーこ on Twitter: "PTSのアルゴこれだからね。他社を誘因する以外ほかにどんな目的があるの?っていう https://t.co/kHjYv2R6DI"
市場が面白いなと感じるのは、ある手法が一般的になるとそれが陳腐化してしまう所にもある。 例えば今後 Deep Learning を使う手法が有効と見做されて一般化されたとしても、それはいずれ有効で無くなる。
未来には市場の動きやそれで儲けるための手法がどのような結果に行き着いているのだろうか。 それを見られる日が楽しみである。
狭小邸宅を読んだ
不動産クラスタでちょくちょく引き合いに出されるので気になっていた狭小邸宅を読み終えた。 ペンシルハウスを売る消費者向け不動産会社の営業をしている主人公とその業界の話である。
雰囲気は以下のbotを参照
「おい、お前、今人生考えてたろ。何でこんなことしてんだろって思ってたろ、なぁ。なに人生考えてんだよ。てめぇ、人生考えてる暇あったら客みつけてこいよ」
— 狭小邸宅bot (@kyosho_teitaku) September 1, 2016
「いや、お前は思っている。自分は特別な存在だと思っている。自分には大きな可能性が残されていて、いつかは自分は何者かになるとどこかで思っている。俺はお前のことが嫌いでも憎いわけでもない、事実を事実として言う。お前は特別でも何でも無い。何かを成し遂げることはないし、何者にもならない」
— 狭小邸宅bot (@kyosho_teitaku) September 3, 2016
「売るだけだ、売るだけでお前らは認められるんだっ、
— 狭小邸宅bot (@kyosho_teitaku) September 2, 2016
こんなわけのわからねえ世の中でこんなにわかりやすいやり方で
認められるなんて幸せじゃねえかよ。最高に幸せじゃねえかよ」
ほかの人のレビューはこちらの総論と各論が面白かった。
そちらから参照されているように、このコメントはとても共感出来る。
なぜならどこからそうなったのかわからないが、仕事ができるようになった「僕」は終盤の友人たちに会う場面などからわかるように、確実にどこかが狂っているからだ。つまり狂った営業マンだけが「狭小」な家を「邸宅」として売ることができ、その狂気に感染した人間が「狭小邸宅」に住む。そんな怖ろしい日本の現在を鮮やかに描く、実力派のデビュー作だ。
『狭小邸宅』 (新庄耕 著) | 今週の必読 - 週刊文春WEB
探している住宅はその人の人生の投影である。Amazonなどのレビューでは小説の終わり方はあまり評価されていないが、物理的な住宅に投影される「狭小」な自分と「邸宅」な自分の無自覚な自意識を描いたラストシーンは個人的にはとても強烈だった。
スノーボール〜ウォーレン・バフェット伝〜を読んだ
伝説的投資家、ウォーレン・バフェットの伝記を読んだ。文庫で上中下の大作。
スノーボール(改訂新版)〔上〕 ウォーレン・バフェット伝 (日経ビジネス人文庫)
- 作者: アリス・シュローダー,伏見威蕃
- 出版社/メーカー: 日本経済新聞出版社
- 発売日: 2014/06/03
- メディア: 文庫
- この商品を含むブログ (2件) を見る
スノーボールというタイトルが付いている。初めはどういう意味かわからなかったが、これは資本が雪だるま式に膨らんでいく様を表しているらしい。Like a Rolling Stone的な趣がある。
恥ずかしながら投資についての知識はからきしだったので、とても長い書籍だったが全ての出来事が新鮮で終始飽きずに読むことが出来た。バフェットはバークシャー・ハサウェイのCEOだったという事実は知っていたが、会社の起こりが紡績事業を行っていた会社だったということは驚きだった。IT銘柄が嫌いな割にはビル・ゲイツと親交が深く、自分の財団の資産をビル・ゲイツ財団に寄付するくだりなどはなるほどという感じだった。
伝記なのでもちろん彼の人間的な部分にも触れられており、特に妻のスーザンが亡くなったシーンは物語のクライマックス的な趣があった。
この著作をきっかけにバリュー投資についての勉強してみようかなと思うようになった。
世紀の空売りを読んだ
マネー・ショートが映画化されて話題だったので原作の方を読んだ。
- 作者: マイケル・ルイス,東江一紀
- 出版社/メーカー: 文藝春秋
- 発売日: 2013/03/08
- メディア: 文庫
- 購入: 1人 クリック: 30回
- この商品を含むブログ (20件) を見る
金融用語の知識があったほうが映画が楽しめると聞いたので、それならばテキストで楽しんだ方が良いなと思ったので書籍を先に楽しんだ。最近はある程度話題になった金融界隈の文庫を読んでいる(リーマン・ショック・コンフィデンシャル、ウォーレン・バフェット伝の二冊だけだけど)。
リーマン・ショック・コンフィデンシャル(上) (ハヤカワ・ノンフィクション文庫)
- 作者: アンドリュー・ロスソーキン,Andrew Ross Sorkin,加賀山卓朗
- 出版社/メーカー: 早川書房
- 発売日: 2014/02/07
- メディア: 文庫
- この商品を含むブログ (6件) を見る
金融界隈の物語はそのスケールの大きさが読んでいてSFのように面白いし、今回読んだ本もこれまで読んだ本の登場人物が出てきて点が線になる感じ、スピンオフ作品的な感じが尚更良い。マネーは誰しもにも関わるテーマだし、その延長線上にあのファンタジーのような世界が広がっていると思うと感慨深い。
また、とは言っても現実の世界の話なので、リーマン・ショックとは何だったのか、いかに債券市場が暴走したのか、その中でウォール・ストリートの投資銀行たちはどう立ちまわったのか、サブプライム・ローンとは、モーゲージ債とは、CDOとは、CDSとはなどなどの知識も得られるのでお得な体験になっている。
M・ルイス氏は同様に金融界隈についての著作をいくつか書いているらしい。ライアーズ・ポーカーと迷ったが、次に読む本はブーメランに決めた(リーマン・ショック後の欧州危機について著作)。フラッシュ・ボーイズ(HFTに関する著作)もOmiさんが面白いって言っていたので早く読みたい(しかしまだ文庫になっていない。ハードカバーは買う気にはならないし、Kindle版を買うのもいまいち好きではないというか文庫という形態が好きすぎるので文庫で読みたい)。
- 作者: マイケルルイス,Michael Lewis,東江一紀
- 出版社/メーカー: 文藝春秋
- 発売日: 2014/09/02
- メディア: 文庫
- この商品を含むブログ (4件) を見る
- 作者: マイケルルイス,Michael Lewis,東江一紀
- 出版社/メーカー: 早川書房
- 発売日: 2013/10/04
- メディア: 新書
- この商品を含むブログ (6件) を見る
作品の中で好きなシーンは、医師から個人投資家に転身した天才マイケル・バーリが、自分がアスペルガー症候群だったと気づき愕然とするシーンです。
embulkでgithubからpluginをインストールする方法
ビルド(Java)
./gradlew gem
ビルド(Ruby)
rake build
pkgの下にgemファイルができるので、
embulk gem install pkg/xxx.gem
する。
@satoshihirose こんにちは、git cloneして、javaなら./gradlew gem ; rubyならrake buildです。pkgの下にgemファイルができるので、embulk gem install pkg/xxx.gemとすれば良いです。
— hiroyuki sato (@hiroysato) April 22, 2016
@hiroysato @satoshihirose 手前味噌ですが、 https://t.co/9qDNGlNQ0O という方法もあります。
— joker1007に宜しく (@joker1007) April 22, 2016
Hadoop / Spark Conference Japan 2016
概要
Hadoop / Spark Conference Japan 2016に参加したチラ裏レポ、感想です。Hadoopカンファレンス初参加でした。途中仕事のメールが入ったためかなり適当にメモったので適当なこと言っていたらすみませんm(__)m
基調講演
Hadoopを取り巻く環境2016
- 濱野 賢一朗 (日本Hadoopユーザー会, NTTデータ)
- Spark Conference 2016初開催!
- Hadoop10周年!このカンファレンスは6回目、7年目。
- 去年1299名→今年1347名。今回は63%が初参加。
- 「Hadoopはひとつのものではなくなった」
- 昔はHDFSとMRだけだった。どこからどこまでがHadoopかわかりにくくなってきた。
- 昔のLinuxも同じことを言われてきた。少しずつ修練されていくと思っている。
- 今どんな変化があるのかを良く知ることが大事。
Hadoopの現在と未来
Yahoo! JAPANのデータプラットフォームの全体像と未来
- 遠藤 禎士(ヤフー)
- マルチビックデータカンパニー。
- Variety。100以上のサービス。
- Volume。649億PV。8300万ユニークブラウザ。
- Velocity。一秒間に5万アクセス。
- 全体像
- これから
- Hadoopに関する技術チャレンジ。
- データ容量が年率四倍になっている。5年後の1024倍は稟議が降りないでしょう(笑)
- 3000台のHadoopクラスタリソースを8ヶ月で使い切る。
- 広告レポートのチャレンジ。毎日13億行が追加される。10万クエリ/hour,、年3.3倍している。
- Hive on Tez。Metastoreがボトルネック。RemoteからLocalへ変更で性能が二倍。
- リソースマネージャー。アプリケーションマネージャのランチャースレッド数を2倍に。
- ハートビート数にRMが耐えられなかったので間隔を伸ばした。結果二倍。
- 他ノードのコンテナ再利用。レプリケーションファクタの増加。ラストアワープロブレム。直近のデータのレプリケーション数を増やした。10万クエリ捌けるようになった。
- NameNode。同時クエリ数を調整する。上げれば良いものでない。
- ジョブ終了時にランダムスリープを入れると良い:ジョブが一斉に終わるとログを書き込む処理がボトルネックになる。
- 今後のYahoo Japanの方向性
- USEからMAKEへ
Hadoopのストレージの現状と展望
- Todd Lipcon(Cloudera)
- HDFSの初期からの開発者。Kudoのリードエンジニア。
- 「エンジニアだからグラフが好きだ」
- 2012年からKudo開発。
- Hadoopには現在800以上のコントリビュータ。コンポネントも2→26へ。
- Basics 2006-2007。Early adapterだけ。Facebook、Yahoo。
- Producion 2008-2011。HDFS HA。HBaseがTLPに。:ランダム・アクセス
- Enterprise 2012-2015。アクセスコントロール。障害復旧。暗号化。SQLonHadoop。HBase1.0。クラウドステレージの対応。
- Next-Gem 2016-2020 RAMが安くなった。ランダム・アクセスが早くて、アナリティクが早くなるようなストレージとしてのKudo。
- Prediction。Kudoのエンプラ対応。HDFSが進化していく。クラウドストレージの重要性が増してくる。
Spark Conference Japanの開催にあたって
- 猿田 浩輔(Apache Sparkコミッタ)
- Spark熱が高まっている。
- 55%以上の人がSparkSQL, Dataframe。MLlibやStreamingも40%に近い結果に。
Spark 2.0: What's Next
- Reynold Xin(Databricks)
- SparkのPMCでTangsutenプロジェクトのリーダー。
- speed, ease of use, sophisticated analytics。オープンソースデータ処理エンジン。
- 2015は1000のコントリビュータ。R。幅広い業界に採用。
- environment, standalone48%, yaron40%, mesos11%, public cloud51%
- BI, DWH, Recommendation、ログ処理、ユーザー向けサービス、不正検出などに使われる。
- Spark2.0
- API Foundation in Spark 2.0はどうなるか。Steraming、DataFrameの成熟。ANSI SQL。
- ストリーム処理が難しい理由は、長期間のアウトプット、遅延処理、障害、分散。これが複雑なオペレーションにわたって機能しないといけない。
- SQL/DF performanceが10倍になる。
- Spark2.0は4、5月にリリース
- [余談] Fortuneのこの記事を日本ローカライズしたネタ笑った。北川景子をXin氏に伝えたの誰だったんだろ。
さくらインターネットが構築した、Apache Sparkによる原価計算システム
- 須藤 武文(さくらインターネット)
- 規模を追求する「持つ経営」なので、資産が増加していく。
- どのくらいコストが掛かっているのか。を知りたい。
- これまでの方法は。手作業に時間がかかる。十分なデータ収集が出来ない。コスト計算の明確なルールが整備不足だった。
- 原価計算の精緻化・迅速化。データ整備と社員の意識向上。分散処理基盤の構築・運用に関する知見を溜める。
- データ量は300GB/day。
- 物理サーバーは30台。総メモリ量は1.6TB。アドホックに増設している。利便性が高くて良い。
各論
YARN: Resource Manager for Analytic Platform
- 小沢 健史(NTT)
- YARNの機能
- 計算機クラスタ内におけるリソース管理
- YARNアプリケーション実行履歴
- 動作中のサービスの場所を知るための仕組み
- なぜYARNを使うのか。
- リソースマネジャー。マスタがクラスタ全体のリソースを管理。
- ノードマネージャー。スレーブが計算機毎のコンテナを管理。
- 課題:割り当てられたコンテナのリソースが全て使い切れているとは限らない。
- 実行履歴の管理。パフォーマンス・チューニング。
- TimelineServer。アプリケーション固有の情報を利用することでリッチな性能解析が可能。例:TezUI
- ServiceRegistory。ある意味サービスディスカバリー。HivemallのMixServerみたいな用途。
- YARN上におけるMR派生の並列分散処理基盤。
- Spark, Tez(Hiveの下で動く)、Flink。汎用的で非循環有向グラフ(DAG)
- MapMapReduceみたいな感じでジョブの数を減らせる。シャッフルが増えると並列性が行かせない。
- Tezは、HivePigといった高水準言語を前提に、シャッフル時のソートがないようなDAGを記述することが可能。
- コンテナの再利用で、コンテナの立ち上げ時間を減らせる。
KuduによるHadoopのトランザクションアクセスと分析パフォーマンスのトレードオフ解消
- Todd Lipcon(Cloudera)
- Why Kudo?
- TimeSeries。ファイナンシャルマーケット。
- Online reporting
- Xiaomiのユースケース。100億/day
- Kafka->Storm->Kudo
- table is horizontally partitioned into tablets. replicas 3 or 5 , Raft consensus. fault tolerance 5 seconds.
- don't need ZK or some module.
- How to work.
- カラムなストレージ。
- データはテーブルに格納する。
Project Tungsten. Bringing Spark Closer to Bare Metal
- Reynold Xin(Databricks)
- 独自のメモリ管理でJVMのオーバヘッド(空間的、GC)を克服する。(四文字のストリングも48バイトになってしまう)
- Janinoコンパイラを使用して、コードの生成時間を減らした。
- アルファソート。キャッシュフレンドリーなソート。プレフィックスを付けることで、短絡化する。
- Spark as a Compilerの話。複雑なIOはコンパイル出来ない。
感想
- Spark、HadoopやKuduのCommiter氏各位の話、分散処理基礎に始まり機能紹介やらコミュニティ今昔やら比較やらが聞けるのでとてもためになる。
- 濱野氏が最初の挨拶で言っていたようにまだまだHadoopコンポーネントは発展していくのだろうし、開発者が良い判断することは暫くは難しいままだろう。
- Maintainable Cloud Architecture of Hadoop聞きたかった😣
- データドリブン企業における、Hadoop基盤とETL ~niconicoでの実践例~も聞きたかった😣
- DynamoDBの話がどこかでされていたようで、聞きたかった😣
現在の弊社にどう活かせるか
S3/Riak上にPlazmaDBを構築して、そこにデータを貯める。HDFSなどをデータ置き場に使わないことで、運用負荷を下げて、更新しやすくなる #hcj2016
— Mr. Fiber (@repeatedly) February 8, 2016
- こう言う意見も全然わかる。
でも、SQLならBigQueryでいいような気もするけど。
— Kazunori Sato (@kazunori_279) 2016, 2月 8
- 「YARNはデータを動かさずに複数のデータ処理基盤を同居させる思想」みたいなものがデータ処理をスケールさせるためには必要であって、そのためにはストレージを中心にデータ処理周りのコンポーネントの開発が活発なHadoopエコシステムにbetするのは長期的に見て間違いない(別にストレージはAWSとかGoogleとかでも良いんだけど)
- Sparkはもちろん銀の弾丸って訳ではないのでって当たり障りのない話になってしまうのだけれど、課題に対してメリット(自分でスケールする分散処理の仕組みを用意するより楽)やデメリット(学習コスト運用コストが増える、cronとかダサい)とかを鑑みて最終的な判断する必要がある。
ScalaMatsuri 2016
概要
ScalaMatsuri 2016に参加した感想です。
DAY 1
Refactoring in Scala
僕のスライドこちらです。スクリーンが見づらい場合はお手元でご確認ください https://t.co/MtTi7m7DE5 #ScalaMatsuri #sm_a
— がくぞ (@gakuzzzz) January 30, 2016
- Tagged Type便利そう。
- IsoやPrismの概念、関数型っぽい。
- 確かにLong型よりもUserId型(Value Type)を定義すると分かりやすかったりbugの埋め込みを減らせる気もするけれども、それが原因でDBとの境界に気を使ってコード量を増やしたりパフォーマンスに気を使ったする箇所を増やしたりするのトレードオフだなって感じだった。
なぜリアクティブは重要か
本日の資料です。毎度ながら詰め込み過ぎなのでバンバン流していきます…。ぜひお手元で見ながらお聞き下さい。 https://t.co/anE0sH8mFc #ScalaMatsuri #sm_a
— Yuta Okamoto (@okapies) January 30, 2016
- okapiesさんのスライドわかりやすい。
- Reactiveなシステムって文脈をProgramming model, Runtime Engine, Architectureに分けて説明したの良かった。
- Reactiveなシステムの設計の概要とそこにおけるApache Dataflowのポジションがクリアーになったのが良かった。これから標準化がどう進むのか見ものだ。
- 分散処理系はまだまだ発展の余地があってとても話を聞いていて楽しい。
- WebサービスのオーケストレーションにもReactiveなシステムの適応余地があるのでは?って話の詳細聞こうと思っていたけど忘れてた。
- この発表聞いていたおかげでTypesafeメンバーのパネルディスカッションの話も分かりやすくなったと思う。
猫という考え方
「猫という考え方」 の発表資料です #ScalaMatsuri #sm_c - https://t.co/LWC5f6Xhqq
— eugene yokota (@eed3si9n_ja) January 30, 2016
- トークの最初にHardとSoftの話半分くらいしますと言っていたように、環境を含めたCatsの概要を理解するのに良かった。
- 「softwareは真空状態にあるものではない」
- Scalaで関数型で行うための障壁を取り除くのがCatsの目標。それは技術的な複雑さ、職場で未知への恐怖、社会的な障壁。 長期的で協力的なコミュニティを促進していく。
- スライド中に猫が箱に頭突っ込んでいる画像が頻出するのウケた。
- 最初に聞いたとき、型を指定しないことで実装が制限させるところがよくわからなかった。
@satoshihirose Intには値があるから値を元に分岐できるけど、値がなければ分岐できないのです。(関数型としてはキャストは考えないので、型がわからないと同じ型を返す実装はそのまま返すしかないです。)
— かず(原材料に小麦粉を含む) (@kazzna) January 30, 2016
- Constraints Liberate, Liberties Constrainが印象的。制限と自由の話、Typesafeの人が好んで使っていた。
バッチを Akka Streams で再実装したら100倍速くなった話
13:40〜の講演資料はこちらです! | バッチを Akka Streams で再実装したら100倍速くなった話 https://t.co/Dc9VPKXWF1 #ScalaMatsuri #sm_a
— Negoro Kazuki (@negokaz) January 30, 2016
- TISとTypesafeの関係知らなかった。
- レガシーなバッチ処理をAkka Streamsで置き換えたら295倍になったとのこと。
- これ別にAkka Streamsじゃなくても100倍とかにはなっていたんじゃないかという気はするけれどまあご愛嬌。
ScalaコードはJVMでどのように表現されているのか
#ScalaMatsuri 2016 1/30(土) 14:30 - 14:45 「ScalaコードはJVMでどのように表現されているのか」で使用したスライドを公開しました!https://t.co/yJvz4EhAqF
— じゅくちょー Koichi Sakata (@jyukutyo) 2016, 1月 30
- javapの話。
- バイトコード読んだ経験特になかったのでまあ勉強になった。
- こんな使い方するとのこと。他にどんなとき読みたくなるんだろうか。パフォーマンスとか気にするとき?
Scala使いは皆、javapにも習熟するものと思っていたけど違うようだ。例えばSparkのnon-serializable系のエラーの解決には、javapでコード確認して$outerに紛れ込んでいるオブジェクトを見つけるなどが必要 #ScalaMatsuri
— Taro L. Saito (@taroleo) January 30, 2016
レジリエンスが無ければ、他は無いも同じ
Here is the full 1 h version of my #ScalaMatsuri talk today (without translation) /cc @momotas210 https://t.co/NRbrKXVjuM
— Jonas Bonér (@jboner) January 30, 2016
- TypesafeのCTOのトークが今回一番印象深かった。システム論っぽい感じ。思想的。
- ドメイン知識がシステムそのものなんだろうなって感じ。
- レジリエンスは設計方針。
- Actorとベンディングマシーンの例わかりやすかった。(よく使われる例なのだろうか?)
- 造船時の防水隔壁パターンの話。タイタニックは障害のカスケーディングの典型例。事故の原因は故障した部品ではなく、部品どうしの関係性にある。
- システムのレジリエンスをどうやって実現するかって話。actorごとにboundaryを設けて、障害の伝搬を防ぐ。threadでもmachineでも良い。
- トークの最初と最後にロッキーのテーマを流してたけど好きなのかな。
The Zen of Akka
Published my slides for the #zen of #akka talk at #ScalaMatsuri, どぞ: https://t.co/lE8it9l2hx
— Konrad Malawski (@ktosopl) January 31, 2016
- Zen。味があるトークだった。
- Akkaのロゴを山水画の山に透過させて描いていたのウケたんだけど、ロゴの由来だったりするの???
- Actorは1つの責務に特化させるべし。他と強調して動くべし。
- Errorはビジネスロジックの問題。Failureはインフラの問題。
- Akka Clusterの話も一般的な問題の話っぽくて面白かった。
- AkkaはFrameworkではなくToolkit。適切に使え。
- Constraints Liberate, Liberties Constrain(制限は私達を自由にする。自由は私達を制限する)
- 元ネタ
- Happy HAkking, Community!
DAY 2
Kafka Tuning
#ScalaMatsuri #sm_b 資料ですhttps://t.co/rQuUaTLGZj
— Kenji Yoshida (@xuwei_k) January 31, 2016
"Apache Kafkaを使ったマイクロサービス基盤"
- ドワンゴの社内マイクロサービス基盤?ではAt Least Once。Exactory Onceや順序保証はなし。
- RabbitMQやめた理由。そこまでスケールを意識していない設計になっている?
- 既存のクライアント(Reactive-kafkaとか)は要件を満たさず使っていない。
- 通信は独自のバイナリプロトコル。httpアダプタを自作。既存のhttpアダプタは無いの?コンフルエントが出しているけれど、機能少ないという判断で使うの辞めた。
- kafka 0.8当時consumerのjarが作りかけなのにmaven centralにpublishされていた…?(ガクブル)
- コードの辛みと運用の設定値チューニングの辛み。ブログとかMLとか読み込んだとのこと。
- 最後の質問でクラウドサービスは検討しなかったの?って聞いたら、オンプレあるししなかったって言われた。ですよね。
Scalaz入門
- よしださんともみあげさんとがくぞさんのハンズオン?パネルディスカッション?
- 最初はEitherとかFolderbleとかValidation
- Scalazは道具だから目的になるなって話でとりあえず釘をさしていた。
- FP in Scalaの第一章は素晴らしいのでそれだけでも読みましょうとのこと。
- 関数型プログラミングではサブタイピングによるポリモーフィズムを避けようって話があるので、OOPと組み合わせるとimplicitがバッティングすることがあったりもするとのこと。
- 参考
リアクティブシステム入門
Typesafe Reactive Platformで作るReactive System入門https://t.co/ukCt8ltzdX
— にわタコ (@niwatako) January 31, 2016
#ScalaMatsuri #sm_c
- 昨日のJonas氏のトークを日本語で要約した感じ。Reactive Platformのコンポーネントのその中での役割をちょっと具体的に説明している。
- デモ。ソーラーファームを運営しているお客様。一万枚のパネルの発電状況をモニタ。故障検知。1msも無駄にしたくない。リアルタイムで。MQTT, Akka, Play, WebSocket。
- TISはSIでもTypesafe Reactive Platformを適用出来ないか頑張っているとのこと。すばらし。
Typesafeの人にリアクティブについて聞こう/Reactive adoption with Typesafe members
- Typesafeの四人が登壇して、質問に答える形式。
- 質問:金融とかクリティカルなとこではどうなの?
金融業界ではReactiveSystemという概念が出る前からそのような仕組みが作られていた #ScalaMatsuri #sm_a
— にわタコ (@niwatako) January 31, 2016
#ScalaMatsuri 分散トランザクションを求められるが、実際は金融ではそうではないと。各金融機関間でメッセージのやり取りをして決済をするので、実は非常にReativeに向く。
— Kimura Sotaro (@kimutansk) January 31, 2016
#ScalaMatsuri システム全体として重複を除去できれば問題ないと。そういう考えは面白い。トランザクションで思考停止していた感があります。
— Kimura Sotaro (@kimutansk) January 31, 2016
- 質問:GoogleもDataflowとか標準化しようとしているけれどどう戦ってくの?
#ScalaMatsuri GoogleのDataflowとどう伍する?>GoogleのDataflowとSparkと補完的な立ち位置にある。Akka Streamの本質は適切なBack Pressure。サポートチケットの大半はロード超過
— Kimura Sotaro (@kimutansk) January 31, 2016
- okapiesさんのReactive Streamに関する質問とスライド使ったファシリテーション素晴らしかった。
- これ期待
@huntchr Thanks for participating the panel discussion! I'm looking forward to blog posts about "reactive database" about ES #scalamatsuri
— Yuta Okamoto (@okapies) 2016, 1月 31
- 録画見てちゃんと理解したい。
Scala.js コンパイル・パイプライン
- どうやってScalaのコードをJSに理解させるコードに置き換えているかの講義だった。
- 後半はよくわからなかった。
- 同じ感想。いきいきと話す人だった。
今回の #ScalaMatsuri の一番大きい収穫は、Scala.jsの開発者は相当本気で、やっぱりProduction readyだったということがわかったことですね。
— はちさん (@armorik83) January 31, 2016
パネルディスカッション:Scala社内教育
- Scalaは色んなレベルの人が色々な書き方が出来るので、その人の背景とかレベルに応じた教育方針がそれぞれあって面白かった。
- 一日目にドワンゴの新人研修資料が公開された。
- hatenaの新人研修資料は最初の年に海外の秋採用の新人を使ってdebugしたとのこと。 github.com
大学教育とScala
- 最近から弊社にインターンシップに来始めた学生が発表していたので顔出してみた。
「大学教育とScala」の発表スライドです https://t.co/fmIAJkTfCu #ScalaMatsuri
— みっちょん (@3tty0n) 2016, 1月 31
Scala 転職・年収
- 各社の年収状況
ScalaMatsuri来場者の年収分布(左端列が海外) #ScalaMatsuri #sm_h pic.twitter.com/9ZKPAwqp1r
— りあくてぃぶ (@nyamngo) January 31, 2016
全体の感想とまとめ
Typesafe
- Typesafeの方々のトークを直に聞けたのがとても良かった。
- またeed3si9nさんにTypesafeの概要とかの話を聞けたのも良かった。
運営
- 一日目の最初に技術カンファレンスの行動規範についてののビデオが流れたけれどもとても良く出来ていた。
技術カンファレンスの行動規範の講義始まったいた。 pic.twitter.com/FB4rKjbGVE
— さとしお (@satoshihirose) January 30, 2016