いい加減読まないとブラウザのタブを圧迫し続けるので消化する。
【とらのあな主催】オタクがKotlinを追うライトニングトークイベント2回目 - connpass
Kotlinあまり知らないのに結構発展的な機能の話を読んでいて、うん、概念レベルであんまり理解できてない！ッテ気持ちになった。
Javaを今から書くよりはKotlinやったほうがまだ実りあるかなあと思いつつ、あんまり勉強できてないので、来年くらいには触りたいな。（今年はTypeScriptをしたい気持ちなので）
Kotlinのコルーチンについて - Speaker Deck
Kotlinでのコルーチン処理は軽いのをいっぱい投げたりすることができるのがわかった。自分自身がコルーチンどこで使うべきなのかはまだよくわかってないけど。。。
【LT資料】ラムダ式でDSL - Speaker Deck
結構複雑なことをしてる感じがする。レシーバー付きラムダ式は便利そうな半面、乱雑に使うとあとが確実にヤバそう。
サーバサイドKotlinへの入門 Ktor編 - Speaker Deck
個人的にサーバーサイドKotlinは結構気になるところなので、大変勉強になった。KtorというWebフレームワークがある。で、Quick Start - Quick Start - Ktor も紹介されていたので、本当にKotlinやろう！と思ったときに読み返してみたいスライドだなあと思った。
俺得フロントエンド (1) LT会 - connpass
これは行きたかったのだが、いろいろあっていけなかった。
Lighthouse performance 100点のサイトから0点を目指す
ファイルとgzip圧縮は偉大なんだと感じました。パフォーマンスが出なかったら効果が高い対応がわかったので学びが多い。
外部ライブラリもインストール・型解釈できるTypeScript playgroundを作った
実現されているものは何となく分かるんだけど、裏側で使っている要素がいろいろすごいなと思った。ここまでやれる気がしないけど、テキストエディタくらいはなんか良さげなライブラリ使って投稿できるやつとか作ってみたい気持ちになるなあ。（それと自分のMBAでは画面が小さいためか、スライドが切れているので、大きいディスプレイで後で見てみようと思う）
BPStudy#141〜DDD(Domain Driven Design)実践の現場 - connpass
資料が多い。コンテンツ量が多そうだ。
ドメイン駆動設計の正しい歩き方
（今丁度読んでる本の著者さんらしい）
ドメイン駆動開発の話。ビジネスルールの複雑さがソフトウェアの複雑さになってしまうのは非常にわかるなあという気持ち。。。。
事例に上がっているホテルの料金体系はすごいいい題材だなあと思った。あまりに複雑すぎるので、分割しなきゃ、でもどの単位で？というのを考えるのに調度がいい単位だなあと思う。実開発でもどれくらいの単位で分割しよう？っていうのは、もっと意識的にやっていかないとモノリシックになりそうだなあと自らを振り返る良い機会になった。
あと自分自身実践が足りてない部分はあるなあと思っていて、35ページ以降の資料の紹介は手を付けたいところ。エヴァンズ本も積んでいるので、まず抜粋されている読むべきページを読まないとなあ。
いま自分が足りてない設計能力について、よくインプットできたような気がする。あともっと書いて実践していくことが大事。
モデル駆動型開発によるビジネスをソフトウェアに落し込む１つのやり方 - Speaker Deck
上の資料と同様にモデリングの重要性と、顧客のドメインの分析がよくなされていて良いなあと思った。自分もまだまだ研究不足なところがあるので、現職にいるうちにもっと顧客動向を学ばねば… と反省した。
Fun Fun Functional (1) 関数型言語初心者向けLightning Talks!! - connpass
これも行きたかったのだが…（行きたかったのだが、しか書いてないぞ）
てかスライドが全体的に濃い。
Scalaで始める競技プログラミング
なるほどと思いつつ（Scala使うことのメリットが知りたいような気もする）
How did Clojure change my life - Speaker Deck
久々にClojureを聞いた。どうして書き始めたのか、みたいなところがエモい。ライブラリが比較的小さめっていうのもなかなか面白いかなあと思った。
そして絶望的なのがClojureの日本語の本、ほぼ出てないらしい。僕も学生時代に少しだけ読み書きしたことがある程度だけれども、このスライドによると日本語の本は2014年以降出ていないようだ…。マジか…。（英語は数冊出てるらしい）
個人的には結構興味深いスライドだった。
PlayFrameworkでFuture［Either［A, B］］どうするのか問題/ PlayFramework return type problem - Speaker Deck
ちょっと話題がピンポイント過ぎたのであんまりわかってない（すんません）
ScalaエンジニアがElmで 初めてのフロントエンド入門 - Speaker Deck
最近聞くことが多いElm言語だけれども、このスライドを見てそのシンプルかつ強力な記述方法は良いなあと思ったので、やっぱり近いうちに頑張って触ろうな、というお気持ちになりました。（やっぱ良さそう・・・！）
GHCJS Miso による Haskell + Firebase 10 分間クッキング #funfunfunctional / Fun Fun Functional 1st - Speaker Deck
えっ、こんなのあるんだ！？ っていうのを知れて、こういうことできるならHaskellベースでまずは入ったほうがいいのか…？ みたいなことをちょっと思った。
ClojurianからみたElixir
言語比較と、使っている資料が興味深くてよかった。（資料の方で出てる言語全然知らないな… と思った）
【増枠！】開発のこだわり LT会〜Super Developer Experience〜 - connpass
これも行きたかったのだが（なんかこいついっつも行きたかったのだが、と言ってないか？）
鍵盤のお伴に注目する/Pay attention to attendant of the keyboard - Speaker Deck
持ち方に着目したことがなかったので意外でした（そもそも自分自身があまりマウス使ってないのでは疑惑はあり、あまり意識してないという説がありますが・・・ そもそも普段どう持ってるのかもわかってない）
サイドボタン付きのマウスを会社では使ってるけれども、自宅でも使おうかなと少し思いました。あと会社にはマウス用のアームレスト買っとかなきゃ…。
まだキーボード分割してないの？ - Speaker Deck
キー配列特殊なやつにしてみたいなあと思いますね、確かに普段は小指が仕事をしすぎて僕もよく指を痛めている気がします。
あと格子配列とか、いろいろなオレオレ配列試せそうなのも楽しそうです。（だけどペアプロやモブプロするとき大変そう…）
vimは尊い - Speaker Deck
（トップのウガンダの貧しい子どもたちを助けて、そういえば出ていましたねっていうのをいまさっき思い出しました（はい））
設計と教育を助けるホワイトボードノート
そろそろこれ自分も買おうかなーと思っているので（今日LTの懇親会でも話題に上がっていた）、参考にしようと思う。
BPLL #34 - connpass
Pythonistaのためのコードレビューが気になった。
タイの コワーキングスペース 視察してきた話 - Google スライド
（無理やりURL引っ張ったので間違ってるかも）
物価の問題もあるのかもしれないが、安い。すごい良いなあ。
日本食が多いのも良さそう。
PythonistaのためのコードレビューTips - slideship.com
レビューに関して抱えがちな問題わかるわかる…
人間がすべきレビューはLinterレベルのことじゃなくて、エッジケースや後日読み直したときの実装の簡潔さとかなんだよなあという話、自分ももっとやっていかないとなあと思いながら個人でコード書くときに思っています。
設計のオープン化も大事で、巨大PR（MR)は本当に避けるべきだと思う。細かくレビューし合うことで、小さくて戻るのがアジャイル的だし結果的にバグが少ないコードになりそう。
must, IMO(In my Opinion), nits, ask とかもルールとして取り入れられると良さそう。僕はこう思うなのか、これは直さないと（サービスとして出たときに）終わるなのかの判断がコメントを読んだ人になるべく委ねられないようにする仕組みは大切だなあと思う。
（褒めるのが大事なのは本当にそう）
JBUG (札幌#4) プロジェクト管理について、もっと学ぼう！ - connpass
札幌でもJBUGあるんだなーと思って資料を眺める。（札幌ってどういうIT企業があるのか自体知らないけど…）
「さぁ困った」をbacklogで解決！
東京で作ったアプリケーションを札幌でテストする、というニアショアパターンの実例の話。
バックログの通知が多くなりすぎると、ステータスや全体としてのタスク進行度がわかりにくくなったり、集計が大変だったりする。これをなんとかスプレッドシートに落とすためにAPIを活用したという話。いい話だ…。（最近のプロジェクト管理ツールにはAPIが生えてて自分で必要なデータをまとめ上げられるの本当に良いと思う）
APIで自分の業務を楽にしていくのは大事なので、僕もRedmineでなにかやれないか試してみたいなあとふんわり思った。
プロマネ視点のリスクマネージメントについて.pdf - Speaker Deck
プロジェクトの約半数が失敗するらしい（この業界でつらそうなことになっている人の話を聞いているとおおよそ正しそうな値に聞こえる）。それをどう回避するかが主題。
アジャイルはいつでも仕様変更できること、と捉えられると終わるなあというのはわかるなあ。とにかく曖昧なことを潰すというのは大事。プロジェクトのゴールや進行状況を明確にしていくことは大事だなあとつくづく思います。（わかるなあしかかけない）
チケットにしていつ決めるかを決める、これによって何が課題として残っているのかを明確にしていくスタイルはとても良いなと思いました。
まとめ
まとめなし。（関数型勉強する時間がほしい）
