すえなみチャンス暑気払いに行ってきたのでメモ
各発表の感想
※資料スライドは見つけたら貼ります。
僕がアーキテクチャを考える時の考え方
昨日の #すえなみチャンス暑気払い の資料はあまり公開するつもりがありません。資料だけだと伝わらなかったり、誤解させたりしかねないし、懇親会でさらに話すこととかも前提にしてるので。
— CERO-METAL🦊🤘 (@cero_t) 2019年8月4日
またどっか別の機会で話します、って言いたいけど、アーキテクチャの考え方とか話す機会、あんまなさそうw
ということでメモだけ…
発表メモ
- コレは何なのかを捉える、物事を抽象化して捉える
- 5つのトピックの紹介があったが、今回は4つ「原則として非同期」「人に例えて考える」「選択肢を減らす」「何を諦めるか考える」という話での紹介があった
- 原則として非同期では同期か非同期可で考えるときは違う軸が入りがちなので本質の取り違えに気をつけるなどの話があった
- 人に例えて考えるでは、実際に人が動くとしたらで考えて動いたりとかコンウェイの法則にはなりがちなのでそこを考える
- 選択肢を減らすでは、誤った選択肢をしないように選択肢を減らす。
- 何を諦めるかを考えるでは、技術的には最善を尽くすが、アーキテクチャとサービスは一体なので、無理なものは無理とする
感想
- プロゲーマーでおなじみ、梅原さんが物事を抽象化して捉えるという話をしていたところに転じて物事を抽象化して捉える話はなるほどと思って聞いていた
- 非同期の本質、というところはかなり誤ってやりがちかもなと思ったので、本質を捉えるというのは大事だなと思った。
- 選択肢を減らす中で、チョイスの仕方が「ミスしない、ハマらないことが最重要、生産性が1割上がっても、1つのミスがあるだけでその生産性は吹き飛ぶ」というのはすごい真似したい着眼点だと思った。
関連リンク
Best practices in web API client development
connpassにも貼ったけど今日の発表資料ですhttps://t.co/SpADwcSG4P #すえなみチャンス暑気払い
— sue445 (@sue445) 2019年8月3日
感想
- RubyKaigi2019の再演セッション
- Rubyだったら1つしか利用箇所がないところでgem化するっていうのは普段からgem化してる文化圏にいたからならではの感じがした
- APIとセットでクライアントをつくっていくのが本当はいいんだろうなと思わされた
関連リンク
- [JA] Best practices in web API client development / Go Sueyoshi @sue445 - YouTube
- sue445/pixela: Pixela API client for Ruby
Atomic Architecture
言語やフレームワークの責務や設計思想がスイスイ頭に入ってくるようになる最高のスライドです。よろしくお願いします! / Atomic Architecturehttps://t.co/2HeUBI1bL0
— :craftsman/kawasima (@kawasima) 2019年8月3日
#すえなみチャンス暑気払い
感想
- データの構造の作り方を要素を分解して、どういう形でどういう表現をしているかということを話したスライド
- イミュータブル、というのを再代入不可としか捉えてなかったのでちょっと見直すべきだなと今回のスライドを見て思った。
- 変換のことをencode,decodeで示していたが、元ネタはElmだということでElm門外漢の私としては興味が湧いた
- 内容としては面白かったが、ちゃんと理解できてたかというとそうでもない感じがあったのであとでもう一回読み直したい
関連リンク
SwiftではDecodableというインタフェースがありますが、その責務はEntity+Decoder+Validatorと解釈できます
— takasek (@takasek) August 3, 2019
…と、さっきの川島さんの発表を踏まえるとこういう分析ができるようになるわけですね!#すえなみチャンス暑気払い
画像引用元: 2017年のApple WWDCの発表https://t.co/0yxasPLu4Y pic.twitter.com/jjMdkpNNdY
すえなみさんと歩んだ就活&入社後の所感
スライドないかも
感想
- sueさんに続くキュアエンジニアの話し
- 東京に来ることを目指した新卒一年目の方
- 会社は変わり続けるので面白い、サービスを作ることはマルチプレイングなどよいフレーズが色々あった
- Twitterみたら勉強会とかもやってるみたいで意欲的な方やった、見習いたい
関連リンク
TypeScriptでtype match的なことをする話
アップした // TypeScriptでType Match的なことをする話 #すえなみチャンス暑気払い - Speaker Deck https://t.co/pp5WYoPc2x
— kyo_ago (@kyo_ago) 2019年8月4日
感想
- 状態をクラス化する話
- いかにして表現力をカバーするかみたいな話だったので、ちょっとスライドが公開されたらデモコードをちゃんと読みたい
関連リンク
クソコード動画「Managerクラス」
昨日公開したクソコード動画「Managerクラス」に関する、 #すえなみチャンス暑気払い で用いた解説スライドです。
— ミノ駆動 (@MinoDriven) 2019年8月4日
本作中においてどういった設計がマズいのかを解説します。https://t.co/zJo98RoiSt
感想
- クソコード動画シリーズ
- 補足のスライドに刺さるものがあって「生産性や品質を向上させる設計業務を怠っている」など設計の不備に関しての心構えのようなものを感じた
関連リンク
クリーンアーキテクチャーをやっていく方法を考えてみた(N番煎じ)
すえなみチャンス暑気払いの LT 資料をあげました
— 石◯王 もちだ (@mike_neck) 2019年8月5日
クリーンアーキテクチャーを強制する方法を考えてみた(N番煎じ) #すえなみチャンス暑気払い by @mike_neck https://t.co/QKmoPuFyJs
感想
- クリーンアーキテクチャが求めているのは依存の方向性、そこに関してどう戦うかの話
- ArchUnitやGradleなどでカバーする方法論がJavaだと取れるという話だったが、Rubyとかだとあんま方法論なさそう
関連リンク
BAD_REQUEST = 400 をめぐる問い。マジックナンバーは可読性を下げるのか?
LT資料です https://t.co/UjJUEB5Ytr #すえなみチャンス暑気払い
— qsona (@qsona) 2019年8月3日
感想
- 可読性の話になると実は可読性の話してないよね、みたいな話
- 結構自分自身の体験に立ち戻って考えるとたしかになとか思わされることがちらほら
- HTTPステータスコードは題材としてちょっといろいろ考えることがありそうなので、エラーコードとか、スリープの値とか、デザインのちょっとしたパディングとかそういうネタのほうが合うのかもしれない
関連リンク
全体を通しての感想
- 実はこの勉強会の存在に気づかず、気づいたときには3日前だったので滑り込み参加だったが実りが多かった(たぶん焼き肉いけたのなら普通にお金払って行ってた。
- フレームワークに乗っかるにしろ、何にしろ、その作りの根本を理解し使い、ちゃんと言語の仕様の恩恵を受けているならその仕組を理解しながら使わないといけないんだろうなと感じた
- 言語の仕組みを設計にパワフルに使えるのすごい羨ましいし、そういうところでコーディングスキルもいろいろ上がるのかなと思ったので、趣味で何か静的型付きやりたいなと切実に思いました。。