Rails Developers Meetup 3/22 個人用メモ

Rails Developers Meetup 2019
詳細: https://railsdm.github.io/

個人用メモ誤字とかたくさんあると思う。気がついたら直すかも。

1030 DHH質疑応答
全英語なので理解度薄い
質問内容：　https://railsdm.herokuapp.com/issues/110

翻訳ありがたい

https://twitter.com/_yasaichi/status/1108907660085067777

https://twitter.com/m4buya/status/1108909638227886081

https://twitter.com/m4buya/status/1108911818255196160

あとで映像配布するらしい。

11:50 アプリケーションを作るときに考える25のこと　session-A

https://togetter.com/li/1330555

価値があるか　難しいかの二つの軸で考えて4つに分ける　それぞれでフレームワークを考える
API特化などはRailsが得意なので簡単に作れる

Railsの基礎
リクエストの流れ　Generatorを利用

Slimの良さ

狩野モデル
当たり前品質
充足品質のグラフ

kaminariのページネーション
pagy gem　ページネートオブジェクト用gem
kaminari without_count
kaminariの中は読むと良い

ファイルストレージgem
dependents gem
githubでスター数高いもの調べてgemfile調べていくとgemに詳しくなる。

ActiveSupport::CurrentAttributes
default_scopeの罠

論理削除
acts_as_paranoid paranoia discard
deleted_atをつける
削除テーブル
削除したら別テーブルに写す　数ヶ月後に物理削除する的なことができる
削除ろぐを作成する　不必要テーブルが多すぎるときろぐに逃がす
確認するときはログを見る

ランキング
redisのsorted setを使いたい
zuhionstore RUby
boffin gem

github検索して全部見る
ライセンスより推薦に振りたい

markdown
commonMark
方言の多い言語
commonmarkで統一しよう
一覧でまとまる
redcarpet kramdown
HTML Piperine

編集履歴　audit_log 監査ろぐ
ActiveModel::Dirty
User.changed?とか
監査ログ

12:30 DevOps, Immutable Infrastructure, microservices そして Chaos Engineering
DevOps, Immutable Infrastructure, microservices and Chaos Engineering

https://speakerdeck.com/yoshiori/devops-immutable-infrastructure-microservices-and-chaos-engineering

タイトルのアレの全体の流れ
Fowler
immutable Infrastructure chadFowker 情熱プログラマー
サーバーの普遍性
インフラをimmutableにしようね
あとでchefに開いておくだと忘れるから　不変にしておこう

microservices
martin fowler
超巨大な組織から　小型化していこうね
実は組織パターンの話
急速に流行り過ぎた
あんまりマイクロサービスにしすぎるのはダメだよ

クックパッド
spec 20000以上
rrrspec
mamiya

docker
Aplicationもimmutableを意識することを強制
アプリケーションコードも意識していかなければならない

container Orchestration
k8s ECS
実行を抽象化 docker run
microservices化で多数のコンテナ化されたアプリケーションを管理する
contrainer orchestration

serviceMesh
serviceはMesh構造になってるよね
envoy
アプリケーションごとにプロキシを立てる
サービルの通信状況を把握
タイムアウトリトライサーキットブレーカーをアプリケーションから外す
全てenvoyに任せちゃう

chaos Engineering
分散システムにおいてシステムが不安定に耐える環境を構築すること
サービス　インスタンスを落とすことではない！！

steady state
pact
正常状態を計測する
毎秒どれくらいのユーザーが動画を見ているのかログインしているのかを判別する。
レシピの閲覧数:検索数
Envoyによるstateがfailedのテストを確認
どうなるかを確認して影響範囲を調べる

microservicesはユーザーの影響を常に考える
steady stateも考えていく

14:00 サーバーサイドエンジニアも知っておくべきフロントエンドの今

フロントエンドのエコシステム
JS ⇨ TS
TSを導入すべきか
TS強いから以降が進んでる
コンパイル　IE11は切ってもいい
ES2015以上を洗濯してもいいよね
DOM 宣言的View
React Vue etc
仮装DOM　手続き的DOm
JQueryよか仮装DOM系
lit-html
仮装DOMではないけれどdiff取れる
editer vscode
Linteer ESLint一強
formetter prettier
prettier-rubyの開発が進んでる
rubocopとどうなるか
module bundler
webpack 🌟
Rollup
pika
test
jest
jest + Puppetter
selenium離れがきてる
非同期処理
axiosがbetter

web components
polyfill
一応使える技術になってる
githubも導入
でもいくらか注意が必要
仮想DOMが死ぬことはない
昨日が足りてないので現状下位互換
webcomponentsは使い続ける流れではある

最近注目のものから1つ
CDN worker
micro frontends
pwa
レンダリング最適化
webpyments
CDN Worker とは
CDNへのレスポンスをフック
AWS LAmbda@Edge CloudFront
Firebase Hosting
BFFをエッジロケーションにおける
担うところ
認証
APIAggergation
Server Side Rendering
Cache
SPA技術で用いた環境でこれまでやりたかったことと課題
FMP SEO を最適化したい
できるだけ早く描画したい
そのためにはレンダリング済みHTMLをクライアントに送る
SSRしたい
課題
SSRにはJSの実行環境が必要
RTT通信距離を最短に
エッジロケーションで通信を完結したい
動的サイトの場合はオリジンサーバーでHTMLを作って送ってもらう
CDNworkerなら解決できるかも
RTT FMP SEO
自前でNodejsサーバー建てなくても良い
オリジンサーバーへのリクエスト数を最小化できる
リージョン変えて値段が安く
cloud flear service
CDN Woeker

エコシステムの成熟
開発体験が良くなってる　ライブラリ乱立が落ち着く
UXに直結する話題が多い
最適な設計にはフロント知識も必須
TS 宣言的View flax Vuex View flax Vuex

14:40 SQLQL は GraphQL にとって、何なのか

https://www.slideshare.net/yancyajp/sqlql-graphql

what is SQLQL
https://qiita.com/yancya/items/4b7979d83cbf6af9b819
APIに直接SQLを投げる。JSON形式で帰ってくる
RDBMSを使いたいPostgreSQLを使いたい
物理的に直接テーブルを触れさせたくはない。流石に
sqlql_sample github　https://github.com/sqlql/sqlql_sample
例 ツイッターのファボ　鍵機能付き
CTE インラインのView
問題点
Mutation　DELETE関係
スキーマ就職
無限ループ
再起クエリ
Mutations の除外　Rails6.0
replica属性のサブコネクションから簡単に描ける
replica: true でmutationが除外
CTEのWITHも弾いてしまう
モンキーパッチで対応できるが、そもそもWITHをなくした理由があれ
副作用が起こせる
DBのreadonlyユーザーを作る他ない
無限ループ対策
タイムアウト
DOSに弱い
SQLQLを使って何がしたかったのか
インピーダンスミスマッチ
JSONからExcel形式とかやりたくない
Relation to Object
JSON_TO_RECORD
JSON_TO_RECORD_SET

15:20 休憩

16:00 我々はマイクロサービスとどう向き合うべきか session-c

https://speakerdeck.com/ota42y/how-should-we-face-with-microservices

マイクロサービス構成
事業が幅広いので初期から携わっている
50ほど
疎結合にはなってる
railsdm day4
事業が大きくなるほどに肥大化していく
カオスコード化していく
リファクタリングより昨日開発が優先されてしまう
新機能が多くなるにつれてさらにカオスに
それぞれのアプリチームがPDCAを回せるように
マイクロサービスはそしてパターン
新機能をやったり既存機能をマイクロサービス貸したり
マイクロサービスの良かった点
CIのすぐ終わる
日々の開発速度が大幅に上がる
クラス依存が少なくなる
影響範囲が小さくなる
チームごとにPDCAがしやすくなる
することしないことが明確化しやすくなる
キャッチアップもし安い
ただし、マイクロサービスが増えすぎると
エンジニア数よりも多いマイクロサービスがでる
れい：ランキングマイクロサービス
最初の分割はいいマイクロサービスだった
<!-- モノリシックな分割 -->
セキュリティ対応が手薄になる
バージョンアップが遅くなる
githubのsecutity alartが出てようやっと対応
一人で兼任しているとアップデートの困難
気づきにくくなる
対応はアップデートしやすいのでマイクロサービスは良いてん
チーム街の対応は大変
モノリシックは大変だが漏れにくい
マイクロサービスは簡単だが漏れやすい
漏れを減らす対応が必要
gemicoma
週にの割れ窓直す時間を確保
warningを消す
ビルド環境を整える
ドメインが成長して変わることがある
他企業との連携
あるコミュニティとの紐付け
communityというマイクロサービスとの関連
マイクロサービスごとに違いがある
ドメインも切りにくい
community ranking chat
結果としてドメインが変わってしまう場合もある。
回避法は難しい。
完璧なドメイン分割はDHHでも難しい
二つのマイクロサービスを同時に変更することが多いのならば一つに統合するのも手である。
これも辛いのでベストアンサーが欲しいところ
トランザクション処理
インフラ
チーム連携
サービスをまたいたオーバーヘッド
でもこれらはマイクロサービス特有の問題ではない
チームならよくある問題
ただそれがマイクロサービスなら何倍にも膨れ上がる
リファクタも多くなる
人数＜サービス数　だとさらに辛い
サービス数　連携の数によってツラミが増える
人数が多ければ対応できることは多い。
組織の成長が大事
組織の強さとマイクロサービスの数がちょうどいい堆肥が良い
対策
ラッパーマイクロサービス
新サービスは旧サービスをラッピングしていく
新機能はBFFに追加していく
エクソダスサービス
新機能はベット作っていく
マイクロサービスにおけるRails
小中規模に止めると良い
しかし、密結合になりやすい
将来的なマイクロサービス
CI/CDほどに成熟はしていない
周辺ツールが発達しているのでその辺の動きによりよくはなっていく
BAllerina マイクロサービス用のプログラミング言語
将来的にマイクロサービスの辛い領域を小さくしていきたい
用法用量を守って正しくマイクロサービス
Railsのマイクロサービス知見もっと欲しい

16:40 AskDoctorsの13年目を支える技術 session-b

M3 サービス多数
askDoctors コンシューマー向けサービス
いつでも体の悩みをお医者さんに相談できる　医者6000にん
2005 ~ 2019
JQueryが2006年から
PC向け　App向け　女性向けでそれぞれ分けていた
委託していたのでコードも別々
コンテンツの共有をしたい
CoreAPI
見た目の速度改善
3つ分けるのはあれなので統合したい
Railsで統合
13年間やっていると使用を全くわからない
DBの統合
CoreAPIのデメリット
データ生合成の問題
少ない人数で多くのサービスを進める
リプレースが一つ一つになる
ゾンビサービスが増える
ある程度サービスが落ち着いてから　UIUXの改善を目指すようになる
キャッシュ
DBスケール
Docker k8s
メリットがあるかどうか
週一でエンジニアが自由にやっていい時間がある
ひどいコードを見たときにどういう経緯でやってきたのかを考える
時系列に元ずいた全体像が見えてくる

17:20 Rails meets Protocol Buffers - For Schema First Development session-b

ゲーム開発でのRails
APIモード
ランタイムの許容可能なオーバーヘっどが確保
rails を使える人が多い
コーディング規約がすでに定まっている
ボイラープレートが少ない
必要な部分だけ開発すれば良い
Rails Engine
スキーマfirst開発
フロントとバックエンドで忙しいタイミングが異なる
差し戻しで両方忙しくなり炎上
ドキュメントで管理するとコストがかかる
スケジュール管理も面倒
ドキュメントの時間小さくしたい
swagger openapi
スキーマ定義
お互いの合意を取る
自動でコードを生成
モックも作成
お互いが作業に集中できる
変更はスキーマに変更すれば良い

2010年で選んだもの protbuf ln-house schema
スキーマfirst開発は
プロダクトを良くすることであり、スキーマを完璧にすることではない
Rails とprotobufの関係
protobuf簡単に覚えられる
restfullAPI
シンプルな開発が行エル

18:00 疲れた。休憩

18:40 毎日の開発に役立つRailsプラグインづくりの秘訣 session-a

gem書いた話
http://github.com/amatsuda/丸々
現場の問題を解決するためにgemを作る
現場の問題のために道具を作る
E2Eテスト書くの面倒くさい
普段描かない人も楽にかけるといいなー
heavens_door
READMEにgif
昔作ったものの書き直し
hocus_pocus
趣味で作った
path直打ちでscafford
localhost動かすことでコードの生成をする
構想はあったけれど、進まなかった
実際に問題を解決するものでないとやる気が続かない
スモールスタートがいい
機能は少なくした方が良い
READMEもかけない
READMEのアニメgifは良い
現場の問題
ER図が見たい
erd　gem
status of erd
画面遷移図を見たい
画面遷移図の素材はrails app に全部ある
gemで作れる
pdfか
e2eテストから遷移を記録してER図に表す
カバレッジにもなる
テスト資産を増やす
still_life
テスト中に描写されたrenderをhtmlで書き出す
自作テンプレートエンジン
Himl
Haml の良さ　閉じタグを描かなくても良い　絶対に安全
どこにでも問題はある
それを解消するためにgem作るというのもある

19:20 まだ40代後半のプログラマの話、あるいは50代プログラマについて考える

40代後半としてのプログラミング
30代はまだ競争できる
40代は競争から降ろされる
蓄積で生きるか別の道で生きるか
３５歳プログラマ定年説
人の人生は人のもの
自分とは違う
50,60だと難しい
自分以外が全員年下。
相手にとってやりズラくないかどうか
定年を強いる圧力
年齢が上がると後進を育てるべきではという圧力
老害か
対策
実力で倒す
別の道を探す　matz
後進に譲る
なんのためにプログラミングするのが
楽しいから　問題解決　金のため
人生について考える
後進がいないところに行く
未来を広げていこう
railsは武器になる
フルスタック
これで完結する
EPUBCheck
Javaせい　lint
電子書籍はアーカイブできるのか
青空文庫
20年
著作権終了した文庫を公開
専属のエンジニアがいない
青空文庫をRubyか
変換ツールをgem化
事業継承問題

所感
マイクロサービス多い
matzがきててびっくりみんな普通に話してて、このコミュニティの雰囲気を感じた
1セッション30分だけれども、内容が50分くらい必要なものを圧縮してるのが多い感じがするし、休憩10分だけなので、とても疲れた。

明日はこういうメモ取らないかもしれぬ…