giantneco’s blog

技術メモ

新宿 Geek Lounge 第2回に参加してきた

9/5に新宿で行われた新宿 Geek Lounge に参加してきた。 新宿 Geek Lounge はセプテーニオリジナルさん主催のイベントで、今回が2回目の開催になる。

Future of Reactive Architectures

今回の目玉はこの Jamie Allen さんのセッション。Jamie Allen さんは Lightbend(Scalaの考案者が創業したところ)からスターバックス(コーヒーを飲むところ)に移られて、現在ディレクターとして活躍されている方である。

タイトルは上記の通りだが、Scala と Reactive について詳しく触れるわけではなく、内容としては次のようなものだった

スターバックスでのソフトウェア部門の立ち上げ

  • スターバックスでのソフトウェア部門を立ち上げる際には、
    • ビジネス上の価値を出すことに重点を置いた
    • 未経験者も多かったため、どのように学ばせるかを模索していく必要があった
    • Scala関数型プログラミングスタイルで書くか、リアクティブプログラミングスタイルで書くかなどを部門のスタンダードで決めなかった
      • これは最初に集まったメンバーが何を得意としているか把握していなかったため
      • また FP も Reactive のどちらも大事にいsたかったため
    • 実装にあった手はメンバにとって一番やりづらい方式を採用するようにした
      • たとえば通信は Restful スタイルにした
      • 当然時間はかかったが、勘所をつかむことができた
    • チーム全体に関数型プログラミングやリアクティブをいきわたらせるのは難しい
      • とはいえ完全に理解していてもそれで価値を出せるわけではないのでそれでよい
    • チームをどうつくればいいか?
      • TypeSafe では、新しい人を加えられないチームがたくさんあった
      • 前提となる知識が深すぎて、新しい人を受け入れることができない

Starbucksのデータベース

  • データはどうしているか
    • Starbucks では AWS で構築し、IaaC を推進している(=自動化は進んでいる)
    • セキュリティはしっかり組み込まれている
      • Starbucksは銀行としての役割もある。これはプリペイドカードに結構お金が使われているため
    • Cassandra はいい
      • 一貫性には問題あり
      • アプリケーション側で担保している
      • 他のデータベースも検討中

最近のデータベース

  • CAP定理
    • 分散DBに関する制限
    • 一貫性をとるか、可用性をとるか?をこれまでは考えないといけなかった
  • Google Spanner
    • CAP 定理を克服している
    • 「TrueTime」という仕組みにより分散した状態でも一貫性を保っている
  • CockrouchDB
    • OSS版の Google Spanner
    • TrueTime はないが、NTP を使ってノードでどちらが先に起こったかを調べる
    • ただし、NTP は完全ではないので注意
  • CAP定理が間違っているという前提に立つと
    • 可用性に注意してから一貫性をやれば良さそう
  • FaunaDB というのがある
    • Calvin Fauna のペーパー
      • ネットワークパーティションは「相対的に」大した頻度で起きない
      • Calvin によると、分散したログに書き込むことはできる
      • そのあと順番を見ればいい
      • そのあとで一貫性をすべてのノードにPUSHすればよい
    • CAP定理でなく、CAP else?

線形コンシステンシー

  • 線形コンシステンシー
    • 分散 DB が 5 つで、write consistency が 3 とすると
      • 3つのノードで合意を立てないといけない
      • 残りのノードに read が行行われていると、どんな値が読みだされるかわからない
    • read も同じように consistency をもつ
    • 時間で見て一貫性を担保するのも難しい
      • これは 100 % まではうまくいかないが十分信頼できる
    • Starbucksで気にしているのは順序
      • すべてのノードで値を読みだす必要がある
        • これに必要なのが線形 consistency

メモ:線形コンシステンシーについてはちょっとよくわかってない。後で調べておきたい。

まとめ

  • どこでも Reactive は必要か?
    • まあ、そう
    • しかし必要以上の苦労をしょい込む必要はない
    • ひとつのツールに固執するのは避けたほうがよい
    • 価値をだすためになにができるかをよく考えよう

LT

今回の LT は 1 つで、Scala の Future による並列・並行プログラミングの話だった。 - Future は ExecutionContext を定義して渡すことで挙動を制御できる - 例えばデフォルトではスレッドプールとキューの上限が両方溢れたらエラーになるが、 上限をなくしてしまうこともできる

感想

Jamie さんの話は思ってたのと違って Reactive の話はそれほどなかったが、 最近の分散 DB の話は追っかけていなかったので聞けて良かった。 特に Google Spanner は名前は知っていたが、CAP 定理を克服しようとしているというのは知らなかったので、これは結構驚いた。 Fauna DB と線形コンシステンシーの話はあまりよくわかっていないので、できれば調べておきたい。

Fortran 2003 の PROTECTED

相変わらず仕事で実装しているFortranコンパイラの話。

で、その時の作業としては他の開発者が実装したPROTECTEDの実装を確認しておかしい部分があったら修正する、くらいのものだった。 PROTECTEDっていったらJavaPROTECTEDみたく、継承した側でしかアクセスできないようにする修飾子でしょ?と思いつつ実装部分を見るとおかしそうなところはない。 ちゃんとPUBLICPRIVATEとは排他になっているみたいだし…

一応次のコードを書いて gfortran とエラー出力を比較してみることにした。

MODULE m
   INTEGER, PUBLIC, PROTECTED :: i
END MODULE m

ところがこのコードはパスしてしまう。Fortran の仕様書を見てみると次のようにあった。

A nonpointer object that has the PROTECTED attribute and is accessed by
use association shall not appear in a variable definition context (16.6.7) or
as the data-target or proc-target in a pointer-assignment-stmt.

要するに、参照結合した(つまり USE して見えるようになった)変数にPROTECTEDが付いていると代入が出来なくなるとのこと。 結局最初にされていた実装はかなり仕様から外れていることが分かったのでそこそこの量を修正することになった。

やっぱりどうも Fortran は名前が直感に反する用語が多い気がする。

buildersocn に参加してきた 2

その 1 の次の日に参加してきたセッション。

静的解析とUIの自動生成を駆使してモバイルアプリの運用コストを大幅に下げた話

https://www.slideshare.net/takuyaueda967/ui-78581401

@tenntenn さんによる Go の話。

複雑な配信条件を記述するために Go 言語を DSL として使用している。

Googleが開発したニューラルネット専用LSITensor Processing Unit」

@kazunori_279 さんによる TPU の話。

第1世代 TPU の話で、発表中に説明された特徴としては

  • NN の計算ではメモリへのロード・ストアを非常に少なくできる
  • 精度が重要ではないので、浮動小数を整数に量化している
  • 演算回路をパイプライニングして計算を行っている

以前に、TPU は 1 CPU サイクルで 16x16 の行列計算をしている、という話を聞いたことがあったが、 今回の話を聞く限りはスループットでの話のようだ。

Make you a React: How to build your own JavaScript framework.

https://docs.google.com/presentation/d/1qh5ZCMI2e45Z4YZBcI62NMDt-1H2Uwx0sZ3T8ScNStk/pub?start=false&loop=false&delayms=60000

@jbucaron さんによる JavaScript で Reactive フレームワークを作る話。

Reactive フレームワークで使われる仮想 DOM の仕組みと、それを実装する場合どうなるか、とうことをコードを交えて説明してもらえたので非常にわかりやすかった。

仮想 DOM の裏側ではやっぱり結構泥臭いことしているんだな。

OSS貢献超入門

https://www.slideshare.net/shigemk2/oss-78585757

@shigemk2 さんによる OSS に貢献するにはどこから始めるのがおすすめかという話。

結論は、好きなリポジトリを watch しよう。そのためには gitter などをスマホに入れておくのがおすすめらしい。

builderscon に参加してきた 1

builderscon に参加してきた。

オープニングセッションによると YAPC::ASIA の精神的後継であるとのこと。 セッションに統一したジャンルはないということだったが、 もともと Web 系のカンファレンスが前身だったらしくセッションもその傾向が強いようだ。

自分は若干門外漢な感じだが、カンファレンスのテーマ自体「知らなかった、を聞く」なのでまあいいんじゃないかと思う。実際、行ってきたセッションではとりあえずはずれはなかった感じである。

以下行ってきたセッションの感想。

DeepLearningによるアイドル顔識別を支える技術

speakerdeck.com

@sugyan さんによる発表。 テーマとしては、Deep Learning 自体より、 それを実施するまでに使用した技術を紹介するようなセッションだった。

アイドル顔画像のクローリングから始まり、画像の回転のための OpenCV のために Docker で環境構築したり、ラベル付けを簡単にするためにWebアプリを作ったりと、ほぼ0から顔認識の実施までにどういうことをしたかが分かる良い発表だった。継続大事。

マイクロチームでの高速な新規開発を支える開発・分析基盤

speakerdeck.com

@timakin さんの発表。

少人数・短期間でアプリのリリースをするためにどういうことをしたか、という内容で、 自分にとってはかなり知らない世界の話だった。 何をどう組み合わせればやりたいことが実現できそうか、というノウハウもすごいが、 それを手早く実現するために Infrastructure As Code を組織で実践できているのもすごい。

自分が同じようなことをやるとしたら環境構築の部分ですぐつまずくと思う。

あと CircleCI は相当すごいらしい。

複雑なJavaScriptアプリケーションに立ち向かうためのアーキテクチャ

speakerdeck.com

@Shinpeim さんの発表。

ちょうど DDD を勉強していたので、 割と近い内容の話を実例を見ながら聞けたのはタイミングとしてもよかった。

State の部分についてはイメージがちょっとつかめなかった。単にモデルとして持っておくのとどうちがうのか。 コードは公開されてたと思うので後で目を通しておきたい。

あと Helper としていたのは DDD だと Service に当たるものなんだろうか。

Building high performance push notification server in Go

speakerdeck.com

@cubicdaiya さんによる発表。

Notification の push 先が遠い場所にあるため高レイテンシになり、Go の非同期な並行処理で性能が出せたという話。 コード上ですごい特別なことをしているわけではないようだったので、やっぱり Go すごいなという結論になるか。

その他

ランチセッションは部屋が人でいっぱいだったので行かなかった。弁当も受け取り損ねた。仕方ないね。

社内 DDD 勉強会 #5

www.slideshare.net

社内で行う予定だった DDD 勉強会のスライド。 来週に延期になったので後で修正するかもしれない。 DDD本をとりあえず浅くカバーしたのでこれで一区切りつけたい。 もうちょっと技術的な話の方が人集められたんだろうか?

読んでで思ったが相当わかりづらい気がする。

社内 DDD 勉強会 #4

www.slideshare.net

社内で行った勉強会の資料。

内容としてはほぼ DDD に書いてあるとおり。 DDD 本自体は若干古いので、紹介されているリファクタリングの手法は割と古いのかもしれない。

DDD としてリファクタリングは必須だろうが、リファクタリング手法としては特に DDD 独自の変わったことをしているわけではないようだった。

新宿 Geek Lounge 第1回に参加してきた

7 月 6 日に新宿で行われた新宿 Geek Lounge に参加してきた。 新宿 Geek Lounge はセプテーニオリジナルさん主催のイベントで、今回が最初の開催になる。 Scala を使っている会社なだけあって、今回のテーマも Scala だった。

開始時間が割りと遅めだったので、夕飯をがっつり食べてきてしまった。

Akka の話

OE_uia さんの VoIPScala + Akka で作った話 資料はここ https://www.slideshare.net/TaisukeOe/real-world-android-akka-77574727

  • Scala + Akka を Android 上で使用して、ステートフルな非同期ストリームである VoIP にうまく対処した
    • Akka で状態を Actor 内に隔離したり、Actor ヒエラルキーで子の監視をしたり
  • ScalaAndroid で使うにはビルドなどで工夫が必要になるが、いろいろツールは用意されている
    • ただやはり 64K 制限の対策が必要だったり、AndroidJava バージョンに起因する問題などもある

個人的には Android ではもう Kotlin でいいんじゃないかとも思うが、確かに Actor を使えるのは便利かも。

Scala Colletion Method 入門

parallelto さんによるコレクションメソッドの話。 資料はここ https://speakerdeck.com/parallelto/scalakorekusiyonmesotudoru-men

内容てしては、コレクションメソッドを使う上での注意点や、あまり使われていないが便利なコレクションメソッドの紹介がされていた。

コレクションメソッドはやはり便利だが注意すべき点もあるので、ここら辺ハマる人は多そうだな。