PostgreSQLとMySQLのメジャーバージョンアップのためのチートシート作った - そーだいなるらくがき帳中国地方DB勉強会 in 岡山の登壇資料です。 そのうちここで登壇動画が公開されることでしょう。 肝心なチートシートは以下のとおり。 PostgreSQL gist.github.com MySQL gist.github.com チートシートだけじゃわからない！困ってる！ Have Fun Techがバージョンアップのサポートしますのでお気軽にご相談ください。 have-fun.tech まとめ やっぱ中国地方DB勉強会は最高だぜ！
退職...そして独立へ...... - そーだいなるらくがき帳
私信ですが今日、最終出社日なのでご連絡します。 以下の通りです。 From: オミカレ 副社長/CTO To: 合同会社 Have Fun Tech 代表社員 関係各位に感謝を申し上げます。 ありがとうございました。 以上です。 よろしくお願いします。 なぜ オミカレ を辞めるのか 今年の抱負の中にも書いたけど、大学進学とチームが次のステップに行くタイミングであるということ。 そしてチームにとって、自分が重要な要素であるとは理解しているけど、敢えてそのポジションが空くことで次の成長があると思う。 実際に前回の転職エントリの中の目標が思ったよりも早く達成できた。 なので現状では僕自身がコードを書くこと、インフラを触ることがあるのだけど最終目標は「僕が何もしなくても会社が回るようになる」がゴールです。 soudai.hatenablog.com 正直、 曽根壮大じゃないと出来ない仕事 はかなり
PostgreSQLのレプリケーションの監視 - そーだいなるらくがき帳
この記事は PostgreSQL アドベントカレンダー の25日目です。 qiita.com 基本的なPostgreSQLのモニタリングについては下記に纏めました。 soudai.hatenablog.com 本日はここで扱っていないレプリケーションの監視についてまとめようと思います。 なおPostgreSQLのストリーミング・レプリケーション (Streaming Replication) は、PostgreSQL 9.0 移行に使える機能です。 本ブログで説明するレプリケーションはこのストリーミング・レプリケーションを対象とします。 そのためここでは8.4とかで Slony-I 使ってるケースや pgpool-II でレプリケーションモードを使ってるケースは対象外です。 レプリケーションの仕組み PostgreSQLのレプリケーションは変更履歴であるWAL(ログ先行書き込み)を使ってい
MySQLの0000-00-00 00:00:00は使ってはならない - そーだいなるらくがき帳
結論 何がいいたいかといいますと0000-00-00 00:00:00があるとORMも死ぬし、DBマイグレーションツールも死ぬし、そもそもMySQLからポスグレにデータを持っていくこともFDWをすることも出来なくて死ぬのじゃ。— そーだい@初代ALF (@soudai1025) 2018年4月25日 色々困るので使わない。 理由 以下に理由を述べる SQL標準ではない 正論で殴った場合。 0000-00-00 00:00:00の仕様が難しい 0000-00-00 00:00:00 はMySQLの独自な仕様で NOT NULL制約のカラムではNULLと等価であり、NULLではない という仕様がある。 "NOT NULL として宣言された DATE および DATETIME カラムでは、次のようなステートメントを使用することで、特殊な日付 '0000-00-00' を検索できます"https:
ユーザ情報を保存する時のテーブル設計 - そーだいなるらくがき帳
はじめに ※この発言は個人の見解であり、所属する組織の公式見解ではありません 用法用量を守り、個人の責任で業務に投入してください 参考資料 2024/02/14追記 実際のテーブル設計の詳細はこちらを参考にどうぞ。 agilejourney.uzabase.com 要件 User情報を保存するときにどのようなテーブル設計を行うか 今北産業で頼む テーブルに状態を持たせず状態毎のテーブルを作る 状態が変わればレコードを消して別のtableに作る tableの普遍的な情報は別に持たせる 僕の考えた最強のDB設計 PostgreSQLをベースの雑なER図を作った。 これを元に話を進める。 table構成 users 親tableであり、すべてのユーザはここに属する。 基本はINSERTのみでUPDATE、DELETEを考慮しない。 user_detail userに付随する詳細の情報がここに登録
そーだいさんの転職のお知らせ - そーだいなるらくがき帳
私信ですが今日、最終出社日なのでご連絡します。 以下の通りです。 From: はてな CRE To: オミカレ 副社長/CTO 関係各位に感謝を申し上げます。 ありがとうございました。 以上です。 よろしくお願いします。 なぜ はてな を辞めるのか まぁ１年ちょっとで出戻りなんでネガティブに見えがちなんだけどHatenaって会社にネガティブな感情は全然無くて感謝の気持ちでいっぱいです。 じゃあそれに勝るくらいオミカレが魅力的だったか？というとそれも違って、エンジニアとしてみて、プレイヤーとしてみて、Hatenaの方が魅力的だし、そもそも国内でも有数の優良企業です。 むしろオミカレはスタートアップだし課題が多い会社です。 僕はオミカレ起業当初のスターティングメンバー（CTO）なのである程度内情を知っている上で比較しても多くの人はHatenaを選ぶと思います。 それでも僕がオミカレを選んだのは
ソフトウェアエンジニアが当たり前にやるべき事 - そーだいなるらくがき帳
manabusakai さんの下記の記事を読んだ感想。 blog.manabusakai.com Twitterにも書いたけど僕は信頼されるエンジニアをずっと目指してきたし、そのために僕に必要なことがここには詰まっていた。 ほんとみんなに読んでほしい。 このエントリーの中の信頼を得ているエンジニアの姿を引用する。 有言実行である 仕事の納期をきっちり守る どんな仕事でもムラがない 困ったときに快く相談に乗ってくれる 皆がやりたがらないタスクを拾ってくれる チームの雰囲気を良い方向に導いてくれる etc... まさに。 ではソフトウェアエンジニアとしてこの他に当たり前にやるべき事って何があるだろう？ ソフトウェアエンジニアとしてやるべき事 僕らは技術で問題を解決することで価値を高めたり、対価を頂いている。 例えば使っているOSSにバグがあったらどうだろう？ これは自戒をかなり含むが不満をSN
DBリファクタリングの勘所と所感 - そーだいなるらくがき帳
表題についてそーだいなる見解を書き残します。 今年の夏に id:koemu さんにbuilderconの懇親会で下記のような話をいただいていました。 懇親会で、DB側ばかりでなくプログラム側でも適切なドメインモデルの設計ができていれば、リファクタリング時の影響範囲がさらに小さくできるのでは？という話をしたところ、この辺りはアンサーブログを書いてくれるかもしれないってことなので期待しています！！！ www.koemu.com 忘れてないんですよ！しっかり覚えています。 結論 仰る通りだと思うし、適切なドメインモデルはRDBに限らずデータストア層のリファクタリングの負担を大きく減らすと思います。 ここから先は僕なりの考え方を書きます。 実は似たような話を PHPの現場 っていうポッドキャストでも触れています。 php-genba.shin1x1.com システムの柔軟性 勿論、コードの綺麗さや
PostgreSQLの内部構造と監視の話 - そーだいなるらくがき帳
Geeks Who DrinkとPostgreSQL Conference Japan 2017での資料です。 nulab.connpass.com PostgreSQL Conference Japan 2017 (2017-11-03) | 日本PostgreSQLユーザ会 詳しく知りたい人は下記の本がおすすめです。 ただし注意点は9.3相当なのでプロセスの仕組みがちょっと違います。 待望の新刊出ました！10系ベースなのでぜひ読んでみてください。 ※2018/10/07 追記 読み応えのある内容になったかなと思います。レベル感で言えばOSS DB Goldの試験出る範囲です。特に内部構造は覚えて置いて損は無いでしょう。 speakerdeck.com 内部構造の中で取り扱っていないところにAUTOVACUUM、TOASTとレプリケーションがあります。AUTOVACUUMはPostgre
早くチームにマッチするために気をつけてる事 - そーだいなるらくがき帳
新入社員として1週間が過ぎた。 ブルックスの法則的に考えても私はまだチームにとって生産性をマイナスさせる存在でしかない。 ブルックスの法則 - Wikipedia だからいち早くチームにとって必要な存在になる必要があるし、そのために気をつけてる事をメモする。 これを見て「もっとコレした方がいいよ」ってアドバイス、逆に「それは不要だよ」ってアドバイスを期待してる。 チームやプロダクトを好きになる これはとても大切なことだ。 嫌いな人とは仲良くできないし、嫌いなプロダクトは育てれない。 もし、コレを読んでる人が職場のチームもプロダクトも嫌いなら転職した方がいい。 ただ好きの反対は無関心なので無関心の場合は条件付きでやっていけると思う。 この辺の話は主旨が変わるのでまた別の機会があれば話したい。 コミュニケーションについて 新しいチームに合流してまず一番大事なのはコミュニケーションコスト。 自分
株式会社はてなに入社しました - そーだいなるらくがき帳
あけましておめでとうございます。 2017年1月1日付で株式会社はてなに入社しました。 はてなに入社するということでやっぱりはてなブログに移行しました。 そーだいなるらくがき帳は移行出来たらします。 はてなにはMackerelのセールスエンジニアとしてジョインしました。 なぜ「はてな」なのか WebサービスのスタートアップのCTOを辞めてなぜ「はてな」なの？という疑問があると思います。 理由としては勿論前職を離れるのに良いタイミングだったってのも大きいのですが PostgreSQLがそこにある セールス部門でチャレンジ出来る エンジニアの全体のレベルが高い などです。 でも1番はMackerelチームに一緒に働きたい人が沢山いるって言うのが大きいです。 そして広島から東京に転居してまでチャレンジしたい価値がMackerelにはあると思っています。 初出社日の所感 初めての東京転居（まだして
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
