マルチテナントの実現におけるDB設計とRLS / Utilizing RSL in multi-tenancy# 実装の参考資料 - https://soudai.hatenablog.com/entry/2022/11/11/110825 # 類似の登壇内容の動画 - https://www.youtube.com/watch?v=PXy6I-AeI-I
AWSで”最小権限の原則”を実現するための考え方 /20240722-ssmjp-aws-least-privilege
ssmonline #43 での発表資料です。 (運用設計ラボ合同会社 波田野裕一)
見えないものに着目すると上手くいく、モデリングの勘所 / invisible-driven-design
こちらのイベントの登壇発表資料です。 アーキテクチャを突き詰める Online Conference https://findy.connpass.com/event/314782/
SaaS アーキテクチャ概要
SaaS をアーキテクトをするにあたって、どのような事を考えればよいのか？をまとめました。 このスライドでまとめているのは SaaS とは、ビジネスモデル x 技術であることを理解する SaaS アーキテクトでどのように SaaS を作っていくのか？を考える SaaS KPI で…
AWSコンテナ系アーキテクチャの選択肢を最適化する | 外道父の匠
これまでもコンテナ関連の記事はそれなりに書いてきましたが、改めて最新事情に合わせて練り直したり見渡してみると、大きなところから小さなところまで選択肢が多すぎると感じました。 コンテナ系アーキテクチャを丸っと他所の構成で真似することって、おそらくほとんどなくて、参考にしつつ自分流に築き上げていくでしょうから、今回は築くにあたってどういう選択肢があるのかにフォーカスした変化系で攻めてみようと思った次第です:-) 目次 今年一発目の長いやつです。半分は学習教材用、半分は道楽なテイストです。 はじめに 基盤 インスタンス or コンテナ ECS or EKS on EC2 or FARGATE X86 or ARM64 ロードバランサー メンテナンス：ALB or ECS Service 共有 or １環境毎 アクセスログ：ALB or WEBサーバー ECS / EKS デプロイ：Blue/Gr
【Terraform🧑🚀】tfstateファイルの分割パターンとディレクトリー構成への適用 - 好きな技術を布教したい 😗
この記事から得られる知識 この記事を読むと、以下を "完全に理解" できます✌️ Terraformのtfstateファイルを分割する目的と、オススメの分割パターンについて (★) Terraformのリポジトリやリモートバックエンドのディレクトリ構成の設計について 記事のざっくりした内容は、以下のスライドからキャッチアップできちゃいます！ この記事から得られる知識 01. はじめに 02. なぜ tfstate ファイルを分割するのか 分割していない場合 分割している場合 分割しなくていい場合 03. tfstate ファイルの分割 分割の境界 状態の依存関係図 依存関係図とは 依存関係の表現 ▼ 依存関係の表現記法 ▼ 依存関係がない場合 ▼ 依存関係がある場合 04. tfstate ファイルに基づくその他の設計 リポジトリ 🐱 の設計 リポジトリ分割 ディレクトリ 📂 構成 リ
private 関数にもテストを書きたいとき
「private 関数にはテストを書かない」というのが多数派だと思う。だが昨日、仕事で In-source testing を書いていたらふと private 関数にテストを書きたくなった。そこで、In-source testingができる環境下でもprivate 関数にテストを書くべきかを X で聞いてみたら何か盛り上がっていた。 (In-source Testing: https://vitest.dev/guide/in-source.html) 反応を見る限り、やはり「private 関数にはテストを書かない」の方が主流だった。Kent Beck先生の http://shoulditestprivatemethods.com を紹介するツイートにもそういった反応が寄せられていた。（ぶんぶんさん、教えてくれてありがとうございます。） （このサイト面白すぎますよね・・・） 自分の立場を
認可のアーキテクチャに関する考察（Authorization Academy IIを読んで）
みなさま、認可の設計に苦しんでいるでしょうか？私は苦しんでいます。苦しまなかった瞬間などありません。昔「アプリケーションにおける権限設計の課題」を執筆しましたが、あれから3年以上が経ちます。 当時は認可の設計に関する情報がうまくまとまっている記事などほとんど無く、調べに調べて得たナレッジを書き記したのが上記の記事です。3年以上経ちますが、苦悩が今も特に変わっていないことが驚きです。 ただし、世の中的には認可のライブラリであったりサービスというのは少しずつ増えてきている印象があります(Auth0の OpenFGA であったりOsoの Oso Cloud 、Asertoの Topaz )。 認可の設計に関する記事も少しずつ増えている印象があり、その中でも本記事で紹介したいのがAuthorization Academyです。 これは認可サービスである Oso Cloud やOSSのライブラリ o
翻訳: WebAPI 設計のベストプラクティス - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? これは Enchant の開発者である Vinay Sahni さんが書いた記事「Best Practices for Designing a Pragmatic RESTful API」1を、ご本人の許可を得て翻訳したものです。 RESTful な WebAPI を設計しようとすると、細かなところで長考したり議論したりすると思います。また、他の API に倣ってやってはみたものの、本当にそれでいいのか、どうしてそうしているのか分からない、何てことも少なくはないと思います。 この記事では、そのようなハマリどころについて Vinay さん
note 社の AWS 権限設計の変遷を辿る｜かとうかずや | kakato
いつの世も人々は権限設計に苦しめられている。そうは思いませぬか。 ご多分にもれず、ぼくも note に入ってからというもの AWS の権限設計をどうしてやろうかと、あれこれ思い悩みまくった人間でした。 組織が変われば権限も変わる。誰が何をしたいのかなんてとても把握しきれないし、かといって全員に Administrator を割り振るような豪胆さも持ち合わせておらず。組織再編が繰り返される中で、なんとか運用に耐えうる設計を考え、実装しようと試みた内容をまとめたのがこの note です。 note 社における AWS 権限設計の変遷と、その結果生まれた自動で AWS の権限を払い出す仕組みについて書いていきます。 ※この記事はnote株式会社 Advent Calendar 2022 の 25 目の記事です。 注意事項つらつらと書き連ねていたら 12,000 字超の大作 note となってしま
非エンジニアサイドに技術的負債や設計を説明するノウハウ - Qiita
こんにちは、リファクタリングが大好きなミノ駆動です。 この記事は READYFORアドベントカレンダー2022 、10日目の記事です。 これはなに？ ろくに設計せずにシステム開発を進めると技術的負債が蓄積し、変更が難しくなってしまいます。 しかし設計を推進しようにも、周囲が設計is何を知らないと、なかなか理解を得られません。特にビジネス側や経営側はプログラムの内部構造を知らないわけですから、輪をかけて説得が困難です。 この記事は、ビジネス側や経営側など、非エンジニアサイドに対して技術的負債や設計を分かりやすく説明するための例えや手法をまとめたものです。 私が非エンジニアサイドへ説明するとき実際に活用しているもので、聞き手からも「分かりやすい」と好評を得ております。 この記事のゴール 以下を知ることがこの記事のゴールです。 技術的負債や設計について、非エンジニアサイドに理解を促すノウハウ ユ
バッチ処理 プラクティス
バッチ処理は既に先人の方々が多くのナレッジを公開してくれていますが、それでもなお難しさが変わらないテーマだと思っています。 この記事は、筆者がこれまでの開発経験で気づいたバッチ処理の実装ナレッジを整理し、体系化を目指して文章にしました。 ここでの内容が、より良い課題解決に貢献できれば幸いです。 自身の断片的な思考整理(メモ書き)の延長で内容を整理したため、一部書き振りが統一されておらず、読みにくいかもしれません。ご了承ください。🙏 バッチ処理の難しさバッチ処理は難しい。 人によっては簡単なテーマかもしれませんが、自分は難しいテーマだと思っています。 「難しさの根源は何か？」を考えると、1. 考慮点が多様にあること 2. 解決する課題によって答えが大きく変わること に整理できました。 この2点は、どのソフトウェア開発にも当てはまる項目ではありますが、ことバッチ処理においては顕著に現れます。
LayerXの組織設計で考える4つのポイント｜Matsumoto Yuki
こんにちは。CTOの松本です。最近はスクワットを頑張っています、良い仕事は深いスクワットから、と書いてしまったので有言実行です。 今回はLayerXアドベントカレンダーの一環で、LayerXの経営会議で自分が意識するポイントの一つである組織設計についての話を書かせていただきます。 組織 > プロダクト > お金 スタートアップに限らず、組織を運営するにあたっては資源となるヒト・モノ・カネとの向き合い方について問われることも多いかと思います。この3つについて、特にソフトウェアを中心としたスタートアップでは人が最も大切なファクターとなりがちです。やはり、良い仲間を集めて初めて良いプロダクトが生まれるものです。 人とその集合である組織は、プロダクトの進化の起点であり、また文化を守りながらそれを変化させスケールさせるのがとても難しいと感じます。どんなに資本やその他リソースを持ったところで、この難し
並べ替えできるデータをデータベースに保存する方法
システム開発を行っているとよく、クライアントからデータを任意の順番に並び替えたいという要望があります。並び替えを実行するプログラムは、配列の順序を変えるだけなので簡単ですが、その順序をデータベースにどうやって保存するかという点についてはいつも迷ってしまいます。 これには色々なやり方がありますので、まとめてみました。 8つの方法 今回は8つの方法に分けてみましたが、いくつかの方法は組み合わせて使えると思いますし、さらに工夫した方法もあると思います。方法1～6は大きなくくりとしてよく見かけるものです。方法7方法8は私が考えたもので見たことがないし私自身も実装したことが無いのですが、飛躍したアイデアでもないので載せました。 対象のデータベースは主にRDBですが、KVSに向いているかどうかも（良い・普通・悪い）の3段階で書いています。 データ構造と使い方の説明は書いていますが、具体的な実装は書いて
アジャイル開発とデータベース設計 - 変化に対応するシンプルな実装のために必要なこと - Agile Journey
はじめまして。そーだい（@soudai1025）です。私は普段は技術コンサルティングや受託開発を請け負う合同会社HaveFunTechの代表として、また、予防治療の自社サービスを展開する株式会社リンケージのCTOという二足の草鞋を履き、日々、さまざまなWebサービスの開発に携わっています。 これまでの開発経験のなかで、データベース設計に関わるさまざまな問題に遭遇してきましたが、本稿ではとくに、アジャイル開発時に発生しやすい問題とその対処についてお伝えしたいと思います。開発の現場で目にしやすい実装におけるアンチパターンを示しつつ、アジャイルという指針を維持しながら、対処となるデータベース設計についてご紹介します。 会員登録のアンチパターンと処方箋 イージーな実装とシンプルな実装 Userと言う名の罠 拡張と破綻 データベースは変化に弱い 仕様変更とテーブル変更 Addで変化に追従する 正規化
GitHub ActionsにおけるStep/Job/Workflow設計論
この記事について GitHub Actionsには、以下3つの実行単位が存在します。 Workflow Job Step パイプラインを組む中で出てくる複数個の処理を、1つの実行単位でまとめてしまうか、それとも分割するのかというのは悩むポイントかと思います。 一つのstepのrunフィールドにコマンドを詰め込む？それともstepを分けた方がいい？ 一つのJobの中のstepとして記述した方がいい？それとも別のJobに定義した方がいい？ 一つのWorkflowの中にJobをたくさん定義する？それともWorkflowを別にする？ この記事では、Workflow・Job・Stepそれぞれの性質を踏まえた上で、ベストな処理単位の選び方を考察します。 使用する環境・バージョン GitHub Actions: 2022/5/15時点での機能をもとに考察 読者に要求する前提知識 GitHub Actio
Shopifyに学ぶ！GraphQL API設計5つのポイント
この記事の所要時間：12分 Shopifyは、ノーコードのオンラインショップ構築サービスを提供しています。 また、Shopifyは外部開発者向けのAPIも提供しており、”アプリ”と呼ばれる拡張機能を開発できます。 shopify app storeには、Shopify APIを使った多様なアプリが一般に公開されています。 Shopifyが対象とする事業領域は複雑ですが、洗練されたAPIや、それを活用した多様なアプリによって、柔軟なニーズに応えています。 この記事では、Shopify GraphQL APIの設計から、5つの設計プラクティスを導きます。 各章の最後に、設計プラクティスが1つずつ書かれています。 コネクションとページネーション グラフ理論では、オブジェクトをNode(ノード)といい、オブジェクト同士のつながりをEdge(エッジ)といいます。 GraphQLでは、NodeとEdg
プログラミングにおける設計力を高めるには 〜 良いコードを書くために | Social Change!
プログラミングとはコードを書くことだけではありません。どういった構造にするのか、データはどう扱うのか、どのライブラリを使うのか、いくつもの設計を踏まえてコードを書くのです。設計を表現したものがソースコードです。 設計の良し悪しは品質に影響します。では、良い設計を作るスキルは一体どうやって身につけることができるのでしょうか。プログラミング言語の文法は知識なので、独学でも学ぶことができますが、設計に関してはそうはいきません。 本稿では、プログラミングにおける設計力を高めるためにはどうすれば良いのかを考察します。ここで言う設計は、画面や仕様ではなく、ソフトウェア内部の設計ですが、抽象化するとクリエイティブな仕事全般に通じるかもしれません。 本稿の内容は「良い設計」について論じたものではなく、どうすれば身につくのかを考えたものになります。また、私たちソニックガーデンで行っている、良いコードを書ける
保守性の高いソフトウェア開発のTips集
保守性の高いソフトウェアの開発に役立つ様々なTipsを書いた。 特定の言語にとらわれずあらゆる場面で役立つことを集めた。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
7つの入金外部サービスと連携して分かった実践的な”状態管理”設計パターン3選
