Google I/O 2018 Day 2
5 月上旬に行われた Google I/O 2018 に参加してきた。 この記事は Google I/O 2018 の 2 日目の記事である。
Code beautiful UI with Flutter and Material Design
Material Theming と flutter の話。
Flutter はマテリアルデザインのファーストクラスプラットフォームとなっているそうで、
import 'package:flutter/material.dart';
をいれるだけで、Material Theming に関するあれこれが使えるようになる。
MaterialApp
などのマテリアルデザインができるクラスがあって、
それに手を加えていけばマテリアルデザインにアプリが作れる。
デモでもやっていたがコードを変更するたびに、VM 上のアプリがホットリロードされるので イテラティブな開発が非常にやりやすくなっている。
Codelab で flutter のコースがいくつかあるので、flutter 触りたい人はそこから始めるのがおすすめ。
Microservices in the Cloud with Kubernetes and Istio
Kubernetes + Istio によるマイクロサービスとサービスメッシュの話。
Microservice が 2000 を超えるようなことも多々ある状況だと 管理が大変になる。そういう場合に使うのが Istio で、 これはサービスメッシュというインフラストラクチャとサービスデプロイメントを統一したレイヤを提供してくれる。 Istio を使うとコードを変更することなくマイクロサービスのルーティングを変更したりするなど、 オペレータがマイクロサービスを扱うのに便利なことができる。
デモではistioctl
コマンドでルーティングルールを記述した yaml を元にマイクロサービスに色々な変更を加えていた。
GUI も提供されていて、マイクロサービスの状況が簡単にわかるようになっている。
Android Jetpack: what's new in Architecture Components
Android Jetpack の Architecture Component の話。
新しく追加されるのは Navigation, WorkManager, Paging。
Paging ライブラリは RecyclerView 向けの遅延読み込みリストを提供するもので、 データベースやネットワークなどをデータソースにするのが主な使い方になる。 RxJava もサポートしている。
WorkManager はこれまで複数あったグラウンドジョブのライブラリをまとめたインターフェースとなるもので、 タスクのチェーンや制約条件の指定などをつかって柔軟にバックグラウンドジョブを登録することができるようになる。 制約条件にネットワークにコネクションがはられた場合にひとつだけジョブを開始するというような設定もできる。
Navigation は画面遷移の設計を簡単にするもので、GUI 上から簡単に画面遷移を設計することができる。 また DeepLink を貼って、本来複数回の画面遷移後に表示される画面にジャンプした場合のバックスタックも自動的に作ってくれる。 なお Navigation での画面遷移は Fragment を使っているので、Acitivity は単なるエントリーポイントとして使って Fragment で画面遷移しようという意図が感じられる。
プロジェクトの目標としては Architecutre Component がデフォルトになるようにしたいらしい。
TensorFlow for JavaScript
TensorFlow が JavaScript で使えるようになるというだけだが、 それが嬉しい点としてブラウザで動かせるとカメラとかセンサとか機械学習に役立つものが使えるから、というが個人的に非常に腑に落ちた。 ブラウザというとPCから使うものというイメージを自分は持っていたが、最近ではスマホ上のものの方が多いもんな。
普通の TensorFlow からモデルをインポートする使い方もできるし、node.js で動かすこともできる。 パフォーマンスとしては普通の TensorFlow と遜色ないレベルにまでなっているそうだ。
Introducing AIY: Do-it-yourself Artificial Intelligence
AIY の紹介。AIY は ダンボールと Rasberry Pi に加えて色々部品がついて、自分で組み立てる IoT グッズ。 AI と付いている通り、TensorFlow が入っていて、現在は画像認識ができる Image Kit と、音声認識ができる Voice Kit がラインナップされている。
Google I/O が終わった後にサンフランシスコの Target までいって買おうとしたが売り切れだった。 展示はしていたので、販売自体はしている様子。 秋月電子でも扱っているので、一応日本でも買うことはできるようだ。
Android Jetpack: what’s new in Android Support Library
Support Library が Android Jetpack に含まれたことによる変化の話。
Support Library でバージョンがわかりづらくなっていたのを整理して、1.0.0 に巻き戻した上でこれからは Semantic Versioning に従ってバージョニングする。
後ライブラリとしては androix という名前空間になるので、これまでは support.*
だったのが androidx.*
になる。
androidx へのマイグレーションは Android Studio 上から行える用になっているが、これはまだバギーでバックアップを取るのが望ましいようだ。 また AAR/JAR のバイナリをマイグレーションする Jetifier というツールもある。
ML Kit: Machine Learning SDK for mobile developers
ML Kit の紹介の話。
ML Kit は iOS/Android どちらでも使える SDK でモバイルフレンドリー、つまりネットワークのオン・オフにかかわらず使えるようになっている。 ネットワークがオフ時にはオンデバイスで推論して、オンの場合には Google Cloud AI の推論 API が使える。 Firebase は必須。
使える API はテキスト認識、バーコード認識などモバイルで使えそうな基本 API がある他、カスタムモデルもサポートしていて好きな推論をすることができるようになっている。
ML Kit も Codelab でコースがありすぐに試すことができる。やってみると簡単に推論ができるのがわかる。 ML Kit の API 呼び出しは、機能別に月 1,000 回までは無料なので、codelab はお金をかけずにできるはずだ。
Community Groups - Northeast Asia and Oceania
北東アジアの開発者向けのミートアップにもちょっと行ってみた。 写真撮影をしていたので入ってみたが、なんか全然関係ないところの撮影だったかも。 一応ちょっと名刺とか今作ってるサービスのシールとか配ってきた。
Codelabs
Codelabs の待機列が少なくなってきていたので、自分も並ぶことにした。 このとき手をつけたのは、Flutter 2 コースと Slices 1 コース。 その場で Googler に質問できるのは思っていたより良かった。 結構時間かかるのもあったが、あまり Codelab の終了時間まで少しだったので短いものばかり選んでしまった。 もうちょっと早めに始めたほうが良かったかとちょっと後悔。
After Party
二日目の After Party では Amphitheatre でライブがあった。 サイリウムのような、 LED が入った棒をもらったので振ってきた。 これ自宅まで持って帰ってきてしまって処分に困っている。
その他
この日に Google Home mini と Android Things Starter Kit をもらってきた。
Google Home mini は現在部屋に設置して使っているが、このブログを書いている時点でまだ Android Things の方に触れてないという体たらく。さっさと 3 日目のも書いたら手を着けたい。
Google I/O 2018 Day 1
5 月上旬に行われた Google I/O 2018 に参加してきた。 この記事は Google I/O 2018 の 1 日目の記事である。
今回の Google I/O の自分の方針としては
後で社内で発表するので、まとめやすいセッションを中心に聞いておこう考えてたが、 実際やってみると codelabs が結構良くて観るつもりだったセッションもいくつかスルーしてしまった。 まあ youtube で見られるとわかっていたので、ここでしかできないような体験の方をやっておいてよかったと思う。
次回行く機会があったらもっと codelabs とか Office hour とか参加するようにしたい。 また今作っているサービスのステッカーとかも持ってきたので少しでもいいから配っておくのが小目標。 エンジニアはそういうの主張してなんぼのもんだとようやく最近思うようになってきた。無論自分には苦手なことではあるが…
2016 年と比較になるが、 待機列、給水、などなど非常に運営が非常に改善されていてしんどいイベントにならなくて本当に良かった。
キーノート
残念なことに前日の疲れと目覚ましの設定ミスがあって少し寝過ごしてしまった。 ただその時点では 9 時のシャトルバス乗れるし、流石にキーノートには間に合うかと思っていたが、 実際バスに乗ってみると渋滞がひどくて結局キーノートの開始には間に合わなかった。 前日のシャトルバスから 30 分くらいでつくかと思っていたのが、結局 1 時間 30 位は掛かってしまったので 朝は早めに出たほうがいいんだろうな。
前の方の席にも座れず、結局後ろの芝生席から観ることになってしまった。 ただ天候は穏やかで、2016年の経験から恐れていたよりも気温・日光ともに強くはなく 日陰ではなかったが割と快適に観ることができた。
キーノートで特に印象に残ったのが Google Duplex。会場の反応もかなり大きかった
デベロッパーキーノート
こちらは開発者向けのキーノートで、開発者が聞いてて楽しいのはこっちの方だと思う。
Android から機械学習まで、今回の Google I/O の目玉が一通り聞ける。
Android P はまだベータのまま。 popcycle になるという予想が出ていたし、てっきり Google I/O で正式名称が発表になるかと思っていたが、ベータの発表だった。
後で調べてみると他のメーカのがベータを使えるのは結構意義があることだったらしい。 いままでは Google Pixel とかの Google 端末が対応してから他のメーカーが追随するという形だったのが、 これからは他のメーカもベータ版の時点で対応できるようになる。 ということは新しい Android への対応もしやすくなるので、Android がアップデートされるまでの期間が短くなるかも。
Android Jetpack があるので、今回の Google I/O でまた Android の開発環境が結構変わるんじゃないかと思う。
あと Kotlin も昨年の Google I/O で公式に Android 開発の言語になってから、 けっこう浸透してきたようで、 発表された限りではすでにアプリの 35 % を Kotlin が占めているらしい。
セッションで使われるサンプルコードも Kotlin がほとんどだった。
Android Bundle も結構重要そうで、今後の Android 開発ではモジュール化を考えるもの求められてきそう。
Matrial Design も Material Theming に更新されたし、本当に変化が大きい業界だなとおもったり。
What's New In Android
Android API の新機能を紹介するセッションであり、今後のセッションの紹介をするセッションでもある。 ブログにまとめるときにちょっと見なおしてみたが、やっぱり量が多い。
紹介されていたのは:
- Android app bundles
- Android Jetpack
- Jetpack Architecture 関連の変更
- Lifecycle, Room,
- Core platform
- battery
- app standby buckets
- background restrictions
- Background input & privacy
- バックグラウンドジョブのセキュリティ改善
- Kotlin
- Mockito
- 発音は「モヒート」と同じ感じ
- Mockable Framework
- Activity などシステムオブジェクトのモックも可能に
- Background Text Mesurement
- テキスト長計測の改善
- Magnifier
- テキスト選択の改善
- API も提供
- Baseline Distance
- フォントベースラインの設定が柔軟になった
- Smart Linkify
- Linkify より賢い
- テキストを解析して単語からリンクを生成する機能
- Location
- 室内の位置取得のための WiFi Round-Trip-Time APIs
- Accesibility
- ナビゲーション周りの変更
- Security
- 指紋認証あたりの変更
- Enterpise 向け機能
- noch
- slices
- Android actions
- Google Assistant 向けの改善
- Deep links int o your app
- a visible Intent, shourtcuts with parameters
- Notification
- Deprecation Policy
- 2018 夏から API 26 が必要になる
- Native Componens -> 64 bit 対応が必要になる
- App Compatibility
- NDK
- Camera
- ImageDecoder
- Media
- HDR VP9 のビルトインサポート
- HEIF のサポート
- Vulkan
- Vulkan 1.1
- Neural Networks API
- API 1.1
- ARCore
- AR 用のエミュレータ
- ChromeOS
- Android Studio が動く
What's New in Firebase
Firebase の現状と新機能を発表するセッション。
大きい発表としては ML Kit がある。 ML Kit は現在 5 つの基本 API と、カスタムモデルに対応している。 認証周りも更新があり、電話番号での認証とパスワードレスログイン対応が追加された。
What's New in Android Developer Tool
Android Studio の改良色々。
ビルド時間など性能面が改善された他、機能的には Navigation といった Jetpack の新機能や Android App Bundle に対応し、プロファイラも改善された。 プロファイラはCPU, メモリ, ネットワークのよくみる指標に加え、消費電力のプロファイルが取れるようになった。
The future of app
https://www.youtube.com/watch?v=0raqVydJmNE
Android App Bundle 周りの話。 Android App Bundle によって、端末ごとに必要最低限のモジュールだけはいった apk を配布できるようになるし、一部のモジュールはオンデマンドで配布することもできる(Dynamic Feature)。
機能的には Google Play が aab 周りの世話をするようで、古い Google Play を使う場合は従来通りに全部入りの apk が配布されてくる。
また Android App Bundle は、将来的には Instant App との統合されるらしい。
Modern Android Development
https://www.youtube.com/watch?v=IrMw7MEgADk&t=241s
最近とこれからの Android 開発ツール・手法の話。最近の Android アプリはどうやって開発するといいのか、というのを知りたいときは見るといいかも。 それらが年を追うごとにどんどん変化しているのが紹介された。
今後は Single Activity にして、Activity はエントリーポイントとして利用される事になりそう。 アーキテクチャについては ViewModel + LiveData が良さそう。
After Party
お楽しみの After Party。 1 日目の After Party では Google I/O 会場全体がパーティー会場になって、さまざまな催しが行われる。
社内 Google I/O 参加報告会
6/7 に社内で Google I/O の参加報告会をしてきた。
発表者自分だけなので、 Google I/O の雰囲気が伝わればと思って広く浅くという方針で作ったが、 やっぱりアンケート見ると紹介できなかった範囲が聞きたかったという反応が割と多い。 Firebase の話とかあっても良かったが、流石に対して聞いていないセッションの話をするのはやめておいた。
slides.com
個人で買った Office 365 のライセンスが切れたので、別のプレゼン資料を作るのに良さそうなサービス探していて見つけたのがこれ。 最初は Google Slides 使ってみようとしたが、コードの貼り付けができるようには見えず、結局他の人が使っていたこのサービスにしてみた。 完全とは言えないが、そこそこシンタックスハイライティングが効いているのでこれで良しとした。
とはいえ発表の一週間前に使うスライドツールを変更したのはあまり良くなかったんじゃないかとは思う。まだ使い方に慣れてない。
Google I/O 2018 Day 0
5 月上旬に行われた Google I/O 2018 に参加してきた。 Google I/O は 2016 に参加してから 2 回目の参加になる。今回も抽選での当選だった。
Google I/O の開催期間は 5/8 から 5/10 の 3 日間で、その間は朝から夜まで Google の技術にどっぷり浸かれる素晴らしいイベントである。
今回はなるべくキーノートを前の席で聞きたかったのと、前日に Intel のイベントがあるらしいと知ったため、バッジピックアップの前日 5/6 に到着する予定を立てた。 本来は 5/6 の昼ごろ到着の予定だったが、飛行機が遅延したのもあり、結局ホテルへの到着は 5/6 の夜頃になってしまった。
バッジピックアップ
バッジピックアップ、要するに参加登録は 5/7 の本番前日から開始していて、早めに登録したほうがキーノートを前の方で聞くことができる。 自分の到着は 11 時頃だったが、もうすでにかなりの人がバッジを受け取っており 自分は 103 グループの席(かなり前の方の席)を確保できた。
その後はすぐ近くの Google 本社とギフトショップを見てから一度サンフランシスコまで移動し、夕方にある Intel のイベントまで時間を潰した。
Intel's Google I/O Day Zero Party 5.0
Intel's Google I/O Day Zero Party は、 Intel による Google I/O 参加者向けの パーティで、食事と飲み物のほかに Intel の開発者による実機を使ったデモを見ることができる。 デモの解説をしているのは Intel の技術者なので、直接 Intel の技術者に質問をする機会がある。
なお参加は無料で、Intel のノベルティグッズ etc もおみやげにもらえる。 以前の Day 0 パーティーだと Chrome book がおみやげに出たこともあったらしいが、今回はそれほど豪華な景品は出なかった。
今回のデモで紹介された内容としては:
- AI 関連
- IoT
- ゲーム
- レンダリングのサーバ側処理のデモ
- AR・VR
- Chrome OS と Chromebook
といった感じで Intel も色々な分野に手を出しているのがわかる。
特に機械学習には力を入れているようで、組み込みと合わせたデモが多かった。
目立っていたのが Intel Movidius で、これがあれば Tensor Flow などのディー+ プラーニングを行えるようになる。 デモでは Rasberry Pi とこの USB スティックを組み合わせて機械学習や物体検出のデモを行っていた。 Movidius は後で調べたら秋月でも扱っているくらいなので、日本でも楽に手に入れられるようだ。 それ以外でも IoT + 機械学習の実例のようなデモが多く結構興味深いものが多かった。
食事も良かったので文句ないイベントだったが、ちょっと失敗だったのはホテルに帰ったのがかなり遅い時間になってしまったことで、翌日以降に結構響いてくることになる。
以下 Day 1 に続く。
ScalaMatsuri2018 3日目 メモ
Scala Matsuri 2018 の 3 日目。この日はアンカンファレンス形式だった。
結局圏論が理解出来なかった俺達の復習
圏論の話。 圏論を学ぶ理由として、「抽象」の見方が変わるという話があった。
- proper value -> 即値みたいなもの
- first order value ->
\x -> x + 1
- OR function
high order value(function)
圏論がなぜ良く出てくるか
- 上記のものを型でやる
proper type = 値を入れることができるもの
- 型コンストラクタ = 1 order kinded type
- 型は
- 数学的には「*」と書くことが多い
- Scala 的には「A」とだけ書いたり
- Option の型
- F[A]
* -> *
- Either
F[A1, A2]
- `* -> * -> *
- Functor
- `( -> ) -> *``
- 高カインド型
- 型コンストラクタを受け取る型コンストラクタ
F[G[A]]
- 型は
- Scala は higher kinded type を扱えるので、より関数型言語っぽいことができる
- See 型システム入門
- parametricity -> 多相性のひとつ?
- 圏論を学ぶ理由
- Product, 積 -> tuple, Co Product, 余積 -> Either
依存型プログラミング入門
- 次の点でHaskell と違う
- default eager evauation
- type annotation
- etc
- 機能
- Dependent type
- Type depends on value 型の中に値を持っている
- types are first class
- Proof with dependent type
Idris 入門
- Vect 型
- list which contains number of elements in this type
Vect n a
- n: number of elements
- a: type of elment
Vect : Nat -> Type -> Type
Nil : Vect 0 elem
Vect に対する tail 関数は次のようになる
my_vect_tail : Vect (S n) a -> Vect n a my_vect_tail (x :: xs) = xs
Vect に対する zip 関数は次のようになる
my_vect_zip : Vect n a -> Vect n b -> Vect n (a,b) my_vect_zip [] [] = [] my_vect_zip (x :: xs) ( y :: ys) = (x,y) :: my_vect_zip xs ys
これだけで定義完了。 長さが等しいことをコンパイラがしっている
index 関数
my_index : Fin len -> Vect len elem -> elem my_index FZ (x::xs) = x my_index FS (x::xs) = index k xs
Fin len
とすると、 0 以上 len 未満になるmy_index
never fail
実際に my_vect_zip
を呼ぶ際には、ユーザ側で引数のVect
同士の長さが等しいことを示してあげる必要がある
ここらへんあまり追えてないが、EqNat
というものを使ってどうにかしていた。
data EqNat : (num1 : Nat) -> (num2 : Nat) -> Type where Same: (num : Nat) -> EqNat num num
- EqNat のコンストラクタは Same のみ
- Same では型引数はひとつしかない。
- -> EqNat の型引数 num1 と num2 は同じもの
以上のような自分でzip
関数を書いてみるのはチュートリアルのなかであるらしい。
実践ScalaでDDD(改訂版) @crossroad0201
Scala での DDD の話。
たこ焼き屋に並んでたため、途中からしか見てない…
- データと動作を分離させる
- implicit で動作を分離させる
- コーディング
- 名前をちゃんとつける
- prefix で型を知らせる (ex.
maybeUser
で option に包んだ User とか) - formatter を使う
- レイヤー
- 依存性の逆転を使う
- Onion Architecture
- Clean Archiitecture, Hexagonal Architecture
- 原理は一緒(と思われる)
- Error Handling
- 例外は基本使わない。 Option を使う
DDD compmonents by Scala
- Application Service
- Entity
- 1 Entity in 1 Aggregation
- Value Objects
- type alias
- extens AnyValue
- Role
- DDD にはないモデル
- リレーションを拡張する仕組み
- 例えば、ユーザにたいして Author という関係が惹かれていた場合、 User にメソッドを入れるのではなく、Author とうロールを作って、 そこにメソッドを追加したい
- implicit でうまくやる
Scala Design Patterns @gakuzzzz
- Builder Pattern → Scala では必要なし
- 条件に合わない初期化をコンパイルエラーにする Type-safe Builder Pattern は finagle とかで使われている
- Concept Pattern → 型クラス
- Loan Pattern
- リソースのクローズなど、処理忘れをしたくない時にやる
- 言語機構としては try, finally
- リソースのクローズなど、処理忘れをしたくない時にやる
- a la carte import
- Aux パターン
あと3日でJava 10がリリースですが、興味ある人いますか?
Java 10 の話。
Java 10 はとりあえずいれてみた。 Docker aware になるのは 10 からで、それまでどうやってたか気になって調べたが、cpu を指定するオプションがあるもよう。
Dottyの新機能 @amaya382
Dottyの話。型推論が賢くなるのはいいね。
ScalaMatsuri 2018 に参加してきた (2日目)
今年で参加4回目のイベント。 それほど Scala は書いていないが、関数型言語、DDDあたりの話を聞きに行っている。
今回は 3 日間の開催で、1 日目はトレーニングデー、2 日目は普通のセッション形式、3 日目はアンカンファレンス形式になっている。 1 日目は不参加(あるのに気付いてなかった)で 2, 3 日目に参加した。
以下は 2 日目のメモ、ただし後から調べたこともちょっと入っている。
Why Composability matters @gakuzzzz
http://gakuzzzz.github.io/slides/why_composability_matters/
Scala と他の言語を分けるのは Composability。 Composability は同じ概念の異なる要素を特定の方法で組み合わせて同一概念の別要素を作ること
このセッションでの定義として、「Composability が高い」という場合は合成する手段が多いということを指す。
では、なぜ「Composability が高い」と嬉しいかというと、分割統治をするのに複数の手段があるということになるから。
Functional Performance @mjpt777 Martin Thompson
- https://github.com/mjpt777/presentations/blob/master/FunctionalPerformance.pdf
- 別のカンファレンス用に用意された資料なので、正確には違う資料かもしれないが大体内容は同じなはず
関数型言語の向けのパフォーマンスの話。とはあったが関数型言語でなくても通じる話だと思う。 メモリあたりの低レイヤの話から、関数型言語向けのデータ構造の話まで出てくる。
資料に出ていた Unified Reservation Station が気になって調べたが、これは命令のアウトオブオーダー実行のための仕組みで、キューに溜まった命令に対して必要なオペランドが揃ったら実行される。 1GB の long 配列の和を Haswell 上で計算する例に出されているが、 周波数を3GHzとして、1サイクルは0.3 nsで、マニュアルをみると 256bit のロード・ストアは 1 サイクルで済むように書いてあるので、 うまくキャッシュに乗っていればベンチマーク結果にある 0.83 ns/op というのもすごく有り得そうな数字に見えてくる。
パフォーマンスのための式としてM/D/1の待ち行列式と、Universal Scalability Law が紹介されている。
M/D/1 の待ち行列式
USL 個人的にはアムダールの法則をよく使うが、コヒーレンシを考える必要がある場合はこっちのほうが適当か。
CRDTs
モダンな分散環境ではメッセージのやり取りに TCP より UDP の方が向いている。 ただし UDP によるメッセージングだと順序の保証がないので、データ構造も良く考える必要がある 関数型言語が使うデータ構造だと skip list, tree, scoreboard があるが、実装としてはポインタの参照地獄になってしまう。 Immutability のため、また Concurrent Tree Update をしようとすると Path Copy をすることになってパフォーマンスが問題になる。またガベージコレクションも大変になる。
そこで CRDTs = Conflict-Free Replicated Data Type
CRDTs は時間効率、空間効率ともによいデータ構造 CRDTs には 2 種類あり、オペレーションをコピーする CmRDT = Commputative Replicated Data Types とステートをコピーする CvRDT = Convergent Replicated Data Types
CmRDT * オペレーションを複製 * オペレーションは可換 * オペレーションはべき等でない
CvRDT * ステートを複製 * ステートアップデートは単純増加 * つまり追記のみで、削除には特別な操作が必要 * マージ処理は結合的,可換,べき等
Aeron の Log Buffer が上記の CRDT になっているらしく、オペレーションが中断した場合なども
Publishers, Senders, Receivers, Subscribers が単調増加だけするカウンタを持っていてる。 ステートを持つのは悪かもしれないが、単調増加だけする場合は許容できる。
Monad Transformaers Down to Earth , Gabriele Petronella
モナド変換子の話。モナド変換子自体は前から知っていたが説明が抜群にうまかった。見習いたい。
型クラスが入れ子になっているときは Monad の flatmap を使う。
flatpmap: F[F[A]] -> F[A]
なら異なる型クラスで包まれていたら?モナド同士は合成できないので困ったことになる。
F[G[A]]
こういう場合に使うのがモナド変換子で、合成の代わりに変換をする。
F[G[A]] -> GT[F[_], A]
モナド変換子はモナド名+T
という名前にする(Option モナドならモナド変換子は OptionTになる)
実用的な圏論入門 @DanielaSfregola
圏論のハンズオン。途中から別のセッションを聞きに行った。 かなり初心者向けで、手を動かしながら聞けるのでわかりやすい。
Building Distributed System with Akka @anildigital , Anil Wadghule
分散システムと Akka の話。
- 背景
- size of internet growing
- concurrent connections, big data, respoinse time
- high require
- reactive prinsiples
- Distrubuited system をスケールさせるには
- 読み込みの複製
- 複雑、一貫性に問題
- シャーディング
- これも複雑、データモデルに制限
- Consistent Hasing
- 読み込みの複製
- CAP 定理
- Distributed computation strategy
- fault tolerant system
- Resilence
- Akka
- Actor model on JVM
- 方針として「Let it crash」
- Normal flow and Fault recovery flow
Scalaらしいオブジェクト指向プログラミング @tototoshi
Scala でのオブジェクト指向プログラミング Tips。 Scala には合成の方法が複数があるが、それぞれ長所・短所がある。
Scala と Java に対して Immutability と Composability へのサポートが多くて、 Case
クラスや、 trait
を使える。
- Case Class
- 代数的データ型として使える
- trait
- Java の interface に相当。 mixin や cake pattern に使える
- object
- companion object でデザインパターンでいうところの singleton を作れる
DI についても Scala では次のような手法がある
* コンストラクタインジェクション
* コンストラクタで渡すパターン
* Cake Pattern
* with
句でtrait
を渡していくパターン
* 関数型プログラミングスタイルなら Reader Monad, Free Monad + tagless final
Extensible Effects in Dotty @halcat0x15a
Dottyの新機能と、Dotty で使えるようになる Extensible Effects の話。 この日のセッションのうち一番話が難しかった。 正直このあたりの話はあまり理解できているとは言いがたいので、手を動かして確認したい。
Dotty は Scala の新しいコンパイラで DOT = Dependent Objectt Types という理論に基づいている。その新機能のひとつに Extensible Effects で使う Open Union がある。
Extensible Effects は複数の操作?を効率的に合成してくれるもので、モナド変換子をネストして使った場合にパフォーマンスが落ちる問題を解決してくれる。
この Extensible Effects に至るまでの話が複雑で、まず Free Monad が出てくる。 Free Monad は Functor を Monad にしてくれるが、Functor にしか適用できない。 これに対して Coyoneda を使って Functor 以外にも適用できるようにしたのが Freer Monad。 ただし Freer Monad は flatMap を複数回適用するため重いという問題がある。 これを解決するために Type-Aligned Queue というものを使って、 早くしたのが Fast Freer Monad。 で、Open Union に Fast Freer Monad を適用したものが Extensible Effects であるらしい。
話の流れだけはなんとなく把握したが、実際どういうことをしているのかがわかっていない。
システムパフォーマンス勉強会第8回
www.slideshare.net
社内で行ったシステムパフォーマンス勉強会の第8回。 下半期で終わらせるつもりだったので、一通り重要そうなところはよんだということでとりあえず終わり。
全体としてコードを書く時に知っておくと良いことも多々あったが、全体としてはパフォーマンスエンジニア向けの内容だった。 正直作った後のチューニングとか、機器選定とかインフラ周りとか自分はあまりやらんだろうし。
また社内でやった意味もあったと思う。メモリとかCPUとか低レイヤだが知っておいたほうがいい知識と、並列処理まわりのパフォーマンス関連の話が多少でも共有できたのは良かったと思う。 もうちょっと人を集められるとよかったが…
4月からはなにやろうか?