文脈、背景や問題点の説明 マルチテナントを実装するうえで企業情報（以下company）単位で最小限の情報を扱うようにしたいがcompany単位にTableを作ったりDatabaseを作るのはALTERなどの運用が大変。 そこでRLSを採用するために実際の技術検証をした上での注意点と実際の運用について必要な情報をまとめる。 PostgreSQL 14を前提としている 公式ドキュメント CREATE POLICY 必ず一読はすること。 困ったとき、わからないときはまずは公式ドキュメントを都度見ること。 このドキュメントのゴール RLSの概要をつかめる RLSの最低限の注意点を理解し、実装時に罠を踏まない 自分たちでRLSのポリシー自体をメンテナンスすることができ、デバッグできる テーブル構成 create table if not exists company ( id uuid defaul

クライアント先の社内ポエムだけど必要になることがあったので転記した。 @nekoya さんにお願いしたらそちらも公開してくれた。:圧倒的感謝: @nekoya さんの話がとても良かったので僕もポエムを書いてみる。 zenn.dev 僕もその昔はもちろん駆け出しのエンジニアで自信が無くて自分を低く見積もったり、ある程度自信があっても 謙虚であることが美徳 と思って自分を敢えて卑下するなんてことをよくやっていた。 脳ある鷹は爪を隠す、なんていうけど確かに周囲に低能力だと思われていたほうが便利なシーンもあるにはある。 しかし少なくとも社会で働く上で 自分の能力を適切に評価する ことは自分にとっても会社にとっても重要なことだ。 その前提の上で、自分を過小に評価することは、あなたの仕事の成果に対して高評価し、認めてくれている人たちにとっては裏切り行為と言える。 例えばとても良い仕事をしたのにも関わら

判断と決断の話の違いはこのツイートの通り。 判断の話で言うとぼくはそーだいさんがしてくれた「判断と決断は違う」という話がだいぶ実になっていて、「情報を集めれば理屈で答えが出せるのが判断、今は情報を集めることができない中で答えを出さないといけないのが決断、リーダーがやらなければならないのは決断」という話をかなり大事にしている— しんぺいくんさん (@shinpei0213) 2021年12月10日 決断のコツ 結論から言えば、決断のコツは失敗できるようにすることだ。 失敗できる状態なら決断することができる。 そして素早くアクションして、失敗のフィードバックを受け取ることで新しい決断をすることができる。 そーだいさんがぼくに教えてくれた二大大事なこと「判断と決断は違う」と「ロールバック可能なことはどんどん試せばいい、ロールバックが難しいことは慎重に」です— しんぺいくんさん (@shinpei

VOYAGE GROUP でお手伝いしているとmakeに詳しくなる。 Makefileなにもわからん。 読むのはまだしも、スラスラ書けんな。— そーだい@初代ALF (@soudai1025) 2020年12月22日 嘘、やっぱなにもわからん。 アイスブレイクはこれくらいにしておいて、本題に入る。 同じ処理を繰り返し、実行したいことは多々ある。 更にその処理を並列にしたいことも多々ある。 そんなとき、makeが便利なので使い方を紹介する。 やりたいこと 例えば次のような処理。 CSVファイルを読み込む INSERT文に変換してDBに取り込む CSVファイルは経理データだったり、アクセスログだったりで、この処理を書くことは日常的にあると思う。 この場合にCSVファイルが例えば日付別にあって、一度で取り込みたい場合にどうするだろう？ 一番シンプルなのはファイル名の一覧を取得し、その一覧をもとに

東京に出てきて3年が経った。 前回、1年のタイミングで感じたことからの差分を今回まとめる。 soudai.hatenablog.com 移動費が思っているよりもお金が掛かる JR、バス、地下鉄など東京の交通網はとても便利で車は必要ない。 しかし逆にいえばどこに行くにも移動費が掛かる。 誰かと飲みに行くような集まりの場合、渋谷か新宿になることが多い。 その場所が通勤定期の範囲なら良いがそうでない場合はコストが掛かる。 ちなみに自分はどちらも対象では無い。 地方の車暮らしと比べると車の維持費やガソリン代が交通費に変わるだけではあるのだけど、家族で出かける時にこの差は結構出る。 例えば自分の場合は5人家族なのでバスに乗ると片道 220円*3.5(子供3人は半額なので1.5人分） かかるし、さらにそこから電車に乗るとプラスアルファ。 そのため電車に乗るような遠出をすると往復で2000円くらい掛かる

2020年も始まりました。 2019年、色んなチャレンジを通じて成長を感じる反面、 35歳定年説を考えたりする程度には 心技体の限界を感じたりもしました。 しかし周囲の叱咤激励や自分自身を振り返ってみる *1 と、結果的に小さくまとまってしまい、爆発的な成長に必要な大きなチャレンジが出来てないという結論になりました。 これは弊社の恵まれた環境や東京と言う立地、コミュニティの方々の多くの支援を受けている現状の縁によるものが大きく、感謝しても感謝しきれないほどありがたいことなのだけど、そこに甘えるにはまだ早いなと考えています。 だからこそ2020年は自分自身の積み重ねたモノを一度リセットするくらいの覚悟で大きなチャレンジをして行きます。 そこで今日はその大きなチャレンジを抱負として明記し、宣言の力によって前に進む覚悟を決めたいと思います。 今北産業で頼む そうだ、大学に行こう オミカレを退職

赤十字への振込 西日本豪雨の時に知ったのだけど、手数料をなるべく減らして直接振り込みたい場合は赤十字が良いです。 転載元 ※ 台風19号はまだ無さそうなので分かり次第追記します www.jrc.or.jp 台風19号の義援金も始まったので追記しました（2019/10/16 追記） 台風19号の義援金 www.jrc.or.jp ゆうちょ銀行・郵便局 口座記号番号　00190-8-515005 口座加入者名　日赤令和元年台風第19号災害義援金 ※ゆうちょ銀行の振込用紙の半券が、受領証の代わりとして、税制上の措置が受けられます。（詳しくはこちら） ※窓口でのお振り込みの場合は、振込手数料は免除されます。 （ATMによる通常払込みおよびゆうちょダイレクトをご利用の場合は、所定の振込手数料がかかります） 銀行振込 三井住友銀行 すずらん支店] 普通 2787555 三菱UFJ銀行 やまびこ支店 普

正確には コントロールされたフォルダーアクセス をオンにするとgitが使えなくなる。 これをオンにすると fatal: could not create work tree dir ~ ってerrorがでてgitが使えない。 もちろんパーミッションは合わせても駄目。 offにすると元に戻り、通常通り使える。 WSL、PowerShell、git bashで試したが全て同じerrorになるのでOSレベルで弾いていそう。 なのでonにすると、どうにも出来ない気がする。 こういうのは知らないとドハマリする可能性があるのでWindowsで同じエラーがが出たら一度確認してみてほしい。

34位でフィニッシュ。 isucon.net 棄権を合わせると予選突破に200イスコインちょっと足りなかった。 ハイスコアは9850だっただけにあと1つなにかできれば予選を突破できてたことになる。 当日の流れは id:sugyan さんが用意してくれてるのでそっちを読んでほしい。 memo.sugyan.com ここからはただただ、自分に対する反省をまとめる。 主な担当であるインフラについての反省 準備したつもりでも準備不足だった。 複数台構成、普段RDSやALBに甘えている弊害が出て、Nginxやアプリケーションの複数台構成のやり方を知っているが普段していないので詰まったって感じ。具体的にはMySQLに接続できなくて時間をかけた。 あとnginxのチューニング、特にルーティングで配信をまとめるみたいなところもかなり時間をかけてしまった。 普段、S3とCFにURLをすれば良いって感じで生き

結論 何がいいたいかといいますと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に付随する詳細の情報がここに登録

この記事は、MySQL Casual Advent Calendar 2017の20日目の記事です。 煽り気味のタイトルですがみなさん SHOW ENGINE INNODB STATUS 読んでますか？ SHOW ENGINE INNODB STATUS \G 見づらいのなんとかならんのか。— そーだい@初代ALF (@soudai1025) 2016年12月20日 わかる。でもMySQLの振る舞いを知る中でSHOW ENGINE INNODB STATUSを読まざる得ない場面はそこそこあります。 どんな時に必要になるのでしょうか？ そこでSHOW ENGINE INNODB STATUSにまつわる話を書きます。 SHOW ENGINE INNODB STATUS をまず読みやすくする まず末尾に \G を付けましょう。 これで3倍読みやすくなります。 次に pager less -S を