DB設計したいNight #2 に参加してきました
ども、いっせーです
昨日 DB設計したいNight #2 に参加してきました dbnight.connpass.com
業務でDB設計をするものの、あまり自信がなく力をつけたいなと思っていたところにタイムラインに流れてきたので参加ぽちーしました。
今回はイントロ、DB設計とER図の書き方の説明のあと、演習形式で行われました。
課題要件を20分程度で各自設計し、参加者の中から挙手1名と抽選2名の方に発表頂くといった形でした。
Q: お見合いサービス
要件は画像スライドの通り。
足りない要件は各自が想像して補完していくという形。
個人的には「お見合いサービス」と「マッチングアプリ」は違うと思っていて、
「マッチングアプリ」だと申請時にメッセージが送れたりするので、どう捉えるかでテーブル設計は変わってくるのかなと思いました。
どういう要件があるんだろうなぁとかER図ってどうやって書くんだっけとかいろんなことを考えている内に時間が来てしまい、ざっと書いたのが以下(字が汚いし、ER図として成り立ってないのはご容赦くださいませ
候補者テーブルがあって、申込者IDと受け取り側IDと承認フラグを持っているお見合いテーブルと、候補者とお見合いそれぞれに紐づくメッセージテーブルという形です。(羊文みたいなのは本文)
運よく発表者に選ばれたので、発表しコメントや質問をもらうことができました。
「この設計だとメッセージがきちんとお見合いが承認されたことが保証できないのでは?」みたいな質問だった気がします。
似たような設計の方もいたようで、なんだかほっとしました。
他の方の設計で「男性テーブル」「女性テーブル」と分ける案がでた時に「趣向性を管理するカラムやテーブルを考えたほうがいいかも」「多様性大事」という話も上がって気づきがあってよかったです。
Q: バスの時刻表
これも課題の受け取り方によって設計に差がでそうだなと思いました。
自分の設計を撮るのを忘れてしまったのですが、 記憶を辿るとこんな図を作った気がします
でもこれだとA停留所-B停留所-C停留所という路線でAから出発してCに行きたい時はループして取得するんかなどうするんだろうみたいになってうまくいかんなぁというお気持ちになっていました。
発表者の方は乗り換えを考慮していたりして要件を広げて捉えていてすごいなと感じていました。
その後 id:Soudai さんが「自分似たようなものを作ったことがあるので」という感じでホワイトボードでER図をかいてくださいました。
「こういうケースが想定されるからこういうテーブルが必要だよね」という風に納得感のある説明でした。
動画撮っておけばよかったなぁ。
感想
どちらも自分の経験したことがなかったドメインだったので、想定される要件が並べられず設計を広げることができなかったなぁという印象でした。
20分だとちょっと短いかもと思いました。
「もっと要件を示してほしい」ということではなく要件を考える時間が欲しかったかなぁ?
もっと設計の引き出しを広げたいなと感じました
テーブル設計、型(パターン)を知ってるかどうかって大事だし、逆に既知のパターンに引っ張られるので引き出し多く持つのが大事だと思う。
— そーだい@初代ALF (@soudai1025) January 25, 2019
で僕はt_wadaさんに教えてもらったこれをいっぱいみた。https://t.co/cLqfALp2XA#DBSekkeiNight
このツイートで紹介されているものを見るのはよさそうだなと。
#dbsekkeinight の資料です。@Nakunaru の資料は本来3日間掛けてやるような内容を無理やり10分に押し込んだもので一見の価値ありです。https://t.co/IIsqztwrZq
— ヽ(*゚д゚)ノkaiba (@kaiba) January 24, 2019
抽選で発表内容いただいた内容はこちら。https://t.co/opcFU3KU91
各種スポンサーなども募集中です🍻
次回も都合が合えば参加したいです!
builderscon に初めていってきました
builderscon tokyo 2018 に初めていってきました。
builderscon は
buildersconは「知らなかった、を聞く」をテーマとした技術を愛する全てのギーク達のお祭りです。
buildersconではトークに関して技術的な制約はありません、特定のプログラミング言語や技術スタックによるくくりも設けません。
という感じのカンファレンスです。
二年前くらいに自宅近くの大学で開催されていることを、開催中に知り、
「面白そうなものがこんな近くでやっているのに参加できないの残念だな」
去年も同じことを繰り返していました。
来年こそはビルダーズコンいきたいなぁ
— 87.1kg↓のいっせい🐷 (@issei126) August 5, 2017
builderscon 2018 https://t.co/lUJryHqnx4
— 87.1kg↓のいっせい🐷 (@issei126) June 3, 2018
今年こそ行きたい
なんやかんやありまして最近引っ越して会場が遠くなってしまったのですが、 3年越しに参加することができました。
結論からいうと、参加してよかったです!(小学生並みの感想
オープニングムービーもとても凝っていて「楽しんでもらおう、楽しもう」という意思を感じました。
知らなかったことを知れたり、知ったようで整理されていなかった知識が整理できたり。
「もっと頑張らなきゃ!」という意識をもつことができました(いつまで続くやら
セッションは動画撮影をしていたので、もし気になっていただけたセッションがあればぜひ動画を見ていただきたいと思います。
LTもテンポよく進んでいき、内容も面白く「いいLTがたくさんあるな」という感じでした
ただクロージングのベストスピーカー賞の発表のところは「みなさんご存知の」感をちょっと感じてしまい、
初参加のものとしてはちょっとむむっと思いました。
お名前とセッション名を教えてほしかったな〜という感じ。
(Twitter で運営の方がごめんなさいといっていた気がする)
とはいえ、ぜひ来年も参加したいですね!
今年はびびって懇親会は参加しなかったので来年は参加して周りの方とお話してみたいです。
あわよくば? LTかなにかで話せるくらいのインプットとアウトプットを積んでおきたいと思いました。
個人的なところでいうとオブジェクト指向/DDD/DB設計の知識が足りないと実感/再認識することができたのも収穫でした。
以下は聴いたセッションのメモです。
Day1
Envoy internals deep dive
https://builderscon.io/tokyo/2018/session/838113b5-ea55-40ae-8ef5-eb461e7b97a2
自分は業務では microservice に携わることがなく、言葉は聴いたことあるなというレベルでした。
セッションでは Envoy の細部の実装の話もありましたが、
導入部でスピーカーの会社のサービスのアーキテクチャがモノリシックから始まり、
microservice を運用しはじめてのつらみなどを話していただきました。
これから microservice を運用しはじめる方にはとてもいい情報だったと思います。
以下走り書きメモ
Envoy は microservice をやるときに便利なproxy らしい。ぜんぜん知らんかった。
microservice は運用が難しい、とくに監視運用
数年前のLyft ではmicroserviceに対しての信頼がなくなって、 モノリシックなものとが併存する状況になってしまった。
各言語でmicrosseriveのつなぎ込みを実装しなければならない そこで envoy
言語によらないように様々な機能を内包
envoy は api 経由で設定できるのが強み
xDS hogehoge Discovery Serive
整合性が重要
c10k
c10k に対応するために nginx などを用いいて非同期処理に向いていった event loop モデル
concurrent ????
RCU Read copy update リードがお多い環境だとロックなしで更新dけいる
(整合性たもてる理由がわからんかったぞ。)
更新前のリクエストは更新前の情報を見る 更新後のリクエストは更新後の情報を見る そういうことができる仕組みがあれば整合性をたもつことになる
istio ??
Envoy (Envoy proxy)、Istio とは? - Qiita
感想)ローレイヤーの話がすごくてついていけなかった悲しみ
開発現場で役立たせるための設計原則とパターン
会場B
https://builderscon.io/tokyo/2018/session/34027adb-d0a4-4dd7-9a44-8297a087dc44
最近設計で悩むことがあり、なにかヒントを得れればと思い参加。
「設計の正しさをどう判断するか?」のひとつの答えとして「設計原則に合致しているか検証する」というお話でした。 スピーカーのスライドと話のテンポもよく、聴いてて楽しいセッションでした。
スライドは後日公開されるようなのでもう一度読み直したい
走り書きメモ
最適な設計は問題による じゃどう最適と判断する?
抽象的な話がおおくないか? 人の考え方次第やんん?
全体感
設計とは?
マルチパラダイムデザインという本
ひとかたまりになった問題を分割して考える
どう分割するか?
-> 複数の分割構造の選択肢から最適を選び出すこと
デザインパターン 分割手法のカタログ
設計原則 その分割構造がよい構造か判断する指針 レビューとかの武器になる
実例
例題 ウォッチしている掲示板にポストがあったらそこお知らせくる お知らせにはポスト以外のお知らせくる
if lese 多発ーーやばい なぜ?言語化できないならそれは暗黙知 チームの底力
覚えてほしい原則3つ
- 単一責任原則
- 開放閉鎖原則
- 凝集度と結合度
単一責任原則
変更する理由が複数あったら仕事しすぎ
開放閉鎖原則
- 拡張に対して開いていて 拡張に他のクラスに影響がないように
- 修正に対して閉じている 修正時に他クラスに影響がないように
凝集度と結合度
結合度、依存しているものがかわったときにそれがかわらない
凝集度、関連処理が集まっていること
(わからんかった)
B パート
結合度、依存しているものがかわったときにそれがかわらない
凝集度、
C パート
設計原則は問題によってもかわる 問題を吟味する 変わりやすいところと変わりにくいところを見極める
(あとで単一責任原則と凝集度と結合度について整理する)
Webサービスにて200週連続で新機能をリリースする舞台裏
会場A
https://builderscon.io/tokyo/2018/session/eaaa57e7-0ca5-49b4-a4d4-da13ac969b27
はてなの方のセッション。
Mackerel がリリースしてから200週連続で新機能(ユーザーに価値のある変更。バグフィックスなどは除く)をリリースできたことについて。
メンバーの余力を残したタスク計画をすることで柔軟に対応できたというところにいいなと感じました。
常に100%ないし120%で走っていくというスタイルもあるけど、自分は余力あるスタイルのほうがすきです。
走り書きメモ
なぜ毎週リリースを行うのか
スピードが顧客に対して約束できる価値の一つであり、優位性だった
どうやってその体制を維持したか
当番 リリース当番
ユーザに告知する内容を考えつつ スプリント内で終わる短期タスクと長期タスクを組み合わせていく
エンジニアの稼働100%にしない。余力を残るようにして、自主的な活動をできるようにしておく
ボクが考える i18n の未来
https://builderscon.io/tokyo/2018/session/7b9a49a0-b288-439d-986a-c4baa0573dc2
国際化とローカライズについて、基礎から未来までお話しいただきました。 たしかにi18nのSaaSとかほしいなと思いましたね。 国際化たいへん。。。
走り書きメモ
Vue Fes Japan あるよ
i18nとl10nと関係
i18n 国際化 国際化のベースになる技術・基礎 l10n 言語の地域化、
真面目にやってる?w
翻訳の外注するときもi18nしとかないと難しくなる
i18n の問題
- ひとつの国に複数の言語ある場合
- 方言
- 敬称
- 法律
- ....
あー時間。。。
DX Developer Experience
SaaSもあればいいよね i18n フレームワークつくればいいのでは? 各人によって要不要あるし vuejs と同じ実装のプログレッシブフレームワークでよいのでは
Day2
二日目はわりと Twitter でつぶやくようにしていたのでメモは少なめ。
「Web とは何か?」 - あるいは「Web を Web たらしめるものは何か?」
https://builderscon.io/tokyo/2018/session/476a4a30-2f94-424c-bbc2-f6cb14f1c4cd
スピーカーの jxck さんのお話は 2015年くらいの CROSS でのLTを聴いた以来ひさびさ。
Web がどういう思想の元で生まれ、どのように進化してきたのか?
進化の際、何を守ってきたのか。
これからどうなっていくのか?
とてもきれいにまとまっていてめちゃめちゃよかったです(語彙力
やっぱり Web は面白いなと再認識できてワクワクしました。
話がとてもうまかった。。。
動画が公開されたらぜひ見ていただきたいなって思ったセッションです。
すべてが gem になる - サービス密結合からの段階的脱却
会場 B
https://builderscon.io/tokyo/2018/session/14c60fad-20fb-4fa1-af7c-f788b5fb8588
Wantedly で片方のRailsアプリの中に別のRailsアプリのロジックが混ざっていたカオス状況からどうやって一歩踏み出したか?
というようなお話でした。
正直最後のあたりでメリットがわからなくなってしまったので、スライドを読み返したいところ。
デザイナーとうまく協働する方法
https://builderscon.io/tokyo/2018/session/fd38108a-123f-4ef1-9a05-d50be4118df6
「言語化」と「明文化」が大事!
デザイナーもドキュメントかきましょう!
というお話。
「デザインの経緯を記録する」これはプログラマ側もやっていくべきだなって最近思う。「なんでこの実装なんだっけ」というのがたびだびある #builderscon #buildersconE
— 87.1kg↓のいっせい🐷 (@issei126) September 8, 2018
会場E
Using Chrome Developer Tools to hack your way into concerts
会場 A
https://builderscon.io/tokyo/2018/session/a9e04c66-219e-4d33-9315-f597b8f97829
がちがちの Chrome DevTools の発表かなと思ったら全然そうではなく、とても楽しい発表でした。
再生回数が上限のテイラー・スウィフトのチケットをとるためにDevToolsを使いまくった話 w いい話だw #builderscon #buildersconA
— 87.1kg↓のいっせい🐷 (@issei126) September 8, 2018
XHR リクエストをもう一回送ったり、そのリクエストを cURL で実行させたりできるなど知らないテクニックがありました。
RDB THE Right Way ~壮大なるRDBリファクタリング物語~
会場 E
https://builderscon.io/tokyo/2018/session/ddba9bd5-819e-489e-9123-04d2291d506e
RDBを正しく設計していくにはどうすればいいのか、リファクタリングする際にはどこに気をつければいいのかというセッション
去年の動画をぜひ見てほしいとのこと。
DB の知識は著名な本をいくつか読めば戦えると聴いたのでがんばってよみたいと思いました(語彙力