正しいデータは正しい設計に宿る - そーだいなるらくがき帳
って話をbuilderscon 2018でします。 builderscon.io 当日利用する資料はこちら。 speakerdeck.com 私のセッションはbuildersconの最終セッション。 皆さん素晴らしいセッションが並ぶ中で選択肢に迷ってる方も居ると思います。 だから先に公開しておきますのでこれをご覧になって、他のセッションに行くというのも有りだと思います。 あと事前に去年のトークを見てくれると当日はより理解が深まると思います。 同じ話を2回しても皆さんにとって勿体無いのでリファクタリングの細かい前提の話は当日はしません。 soudai.hatenablog.com 動画はこちら。 www.youtube.com これを見て、面白そうだなって思ったらぜひ、遊びに来てください。 僕が知ってるRDB設計、そしてRDBの歩み方を全てお伝えします。 あなたの新しい道の一歩目をご用意しま
Google SpreadsheetからTrelloに自動登録する。 - そーだいなるらくがき帳
GoogleSpreadsheetに定期的に登録したいタスク一覧を書いておくとGoogle Apps Scriptで自動登録されるようにした。 GASをチョイスした理由は2つ。 定期実行されるためのサーバが不要 スプレッドシートとスクリプトが対になるので「この処理してるスクリプトどこ？」ってなりにくい GASを使ったので一覧管理はスプレッドシートしたとも言える。 スプレッドシートだとそれなりにセキュアな環境で簡単にチームに共有出来るのもメリットだし、メンテナンスがエンジニア以外でも出来るってのがメリット。 細かいところはチームのフローに合わせて調整するとそれなりに使えるんじゃないかな。 ちなみにGASは下記のような時間トリガーで実行できる 指定日時 毎日の指定の時間 毎週の指定曜日と指定日時 毎月の指定の日時 なのでそれ毎にスプレッドシートのシートを作ってGASもそれぞれ作る想定。 あんま
ユーザ情報を保存する時のテーブル設計 - そーだいなるらくがき帳
はじめに ※この発言は個人の見解であり、所属する組織の公式見解ではありません 用法用量を守り、個人の責任で業務に投入してください 要件 User情報を保存するときにどのようなテーブル設計を行うか 今北産業で頼む テーブルに状態を持たせず状態毎のテーブルを作る 状態が変わればレコードを消して別のtableに作る tableの普遍的な情報は別に持たせる 僕の考えた最強のDB設計 PostgreSQLをベースの雑なER図を作った。 これを元に話を進める。 table構成 users 親tableであり、すべてのユーザはここに属する。 基本はINSERTのみでUPDATE、DELETEを考慮しない。 user_detail userに付随する詳細の情報がここに登録される。 一般的にusersにカラムを増やしたいような内容はここに登録する。 なぜusersにカラムを増やさないのか？ それはusers
そーだいなる2017年のアウトプットを振り返る - そーだいなるらくがき帳
今年を振り返り。 まとめ（2017/12/27現在） ブログ 75本 登壇 23回 OSC長岡とCloudGarage Release Tour in OkayamaのLTは入れてない 資料も特に公開する予定はない ベストスピーカー or ベストトーカー 2回 総被はてなブックマーク数 4323個（ブログのみ） 自分で企画したイベントは特にまとめてない。 それはまぁアウトプットというよりは別の軸だと思うので。 というわけで以下月別。 2017-01 ブログ 4本 登壇は特にしてない。 毎日飲み歩いてた。 2017-02 ブログ書いてない。 登壇 3回 毎日飲み歩いてた。 soudai.hatenablog.com soudai.hatenablog.com PostgreSQL勉強会 | Tottoring PostgreSQL勉強会はホワイトボード駆動だったので資料無いです。 2017-
RDBアンチパターン リファクタリングについて話をしてベストスピーカー賞を取ってきた #builderscon - そーだいなるらくがき帳
Builderscon 2017で登壇してきました。 builderscon.io 登壇資料はこちらです。 今回も僕が超絶リスペクトしてる id:t-wada さんと そこそこリスペクトしてる 空前絶後のォォ！！！！超絶怒涛にリスペクトしている上司の id:onishi さんの名言を引用させてもらいました。これはテストコードやモニタリングで品質が見える化されますが「見える化されるだけでは問題は解決しない」という本質をお伝えしています。我々はエンジニアなので技術で問題を解決していくわけですし、問題を解決するためには手を動かすしかありません。ですのでまさに今の現場を改善していくのはあなた自身です。 あとは今年、話をしてきたデータベースリファクタリングの総集編って感じです。ホントは実例のRDBアンチパターンを元にリファクタリングしていきたかったんだけど60分では短すぎて「続編に期待」みたいなレベ
早くチームにマッチするために気をつけてる事 - そーだいなるらくがき帳
新入社員として1週間が過ぎた。 ブルックスの法則的に考えても私はまだチームにとって生産性をマイナスさせる存在でしかない。 ブルックスの法則 - Wikipedia だからいち早くチームにとって必要な存在になる必要があるし、そのために気をつけてる事をメモする。 これを見て「もっとコレした方がいいよ」ってアドバイス、逆に「それは不要だよ」ってアドバイスを期待してる。 チームやプロダクトを好きになる これはとても大切なことだ。 嫌いな人とは仲良くできないし、嫌いなプロダクトは育てれない。 もし、コレを読んでる人が職場のチームもプロダクトも嫌いなら転職した方がいい。 ただ好きの反対は無関心なので無関心の場合は条件付きでやっていけると思う。 この辺の話は主旨が変わるのでまた別の機会があれば話したい。 コミュニケーションについて 新しいチームに合流してまず一番大事なのはコミュニケーションコスト。 自分
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
