データ基盤チームに所属しているデータエンジニアの吉田(id:syou6162)です。10X社内のデータマネジメントの仕事をしています。 最近、社内でディメンショナルモデリング勉強会を行なったですが、なぜ勉強会を行なったのか、どのように行なったのか、勉強会を行なった結果何が得られたかについてまとめます。 ディメンショナルモデリング勉強会開催の背景 勉強会の進め方やスコープ 勉強会の参加者 勉強会で学んだ内容 Four-Step Dimensional Design Process キーの設計について 複数スタースキーマを適切に利用し、ファントラップを避ける コンフォームドディメンション まとめ: 勉強会で得られたもの ディメンショナルモデリング勉強会開催の背景 前回のエントリにまとめた通り、10Xのデータマネジメントの課題の中でも「データウェアハウジングとビジネスインテリジェンス」は優先度が
SQLは滅ぶべきか｜ミック
でかい釣り針が来たので釣られてみる。とりあえず以下の資料を読んでいただきたい。そんなに長くないのでサクッと読める。 SQLの記述順序と思考の順序が違うので書きにくいし、エディタの補完機能の恩恵が受けられないのが嫌だ、という意見はもう大昔からある。何度も何度も何度も繰り返されてきた議論である。以下の2011年のスレッドでも「SQLはFROM句が最初に来るべきではないか？」という問いが提起されている。すぐに出てこないが、筆者はこれより古い文書も見た記憶がある。
tl;dr はじめに 2024 年の 4 月 24 日に Node.js 22 がリリースされました。ESM を 条件付きで require する機能や、--run フラグによる npm スクリプトのパフォーマンス改善などが v22 で追加され、2009 年に Ryan Dahl が Node.js をリリースしてから 15 年が経つ今も、Node.js は進化を続けています[1]。 こうして Node.js 自身が強化されていくにつれ、以前はサードパーティーのパッケージを使用して実現することが一般的であった機能が Node.js のみで実現可能となり、当該パッケージが不要となるような場合があります。冒頭に引用した Ben Holmes の動画では、そのように不要となったパッケージとして dotenv node-fetch chalk mocha が挙げられていますが、この記事では「これら
切り替える理由 自社の主力製品で利用している技術(WebRTC / WebTransport)がブラウザベースのため TypeScript を利用する Go を採用したのは sqlc が使いたかったという理由 sqlc-gen-typescript が出てきたのでもう Go を使う理由がなくなった 自社サービスチーム全員が Go にまったく興味が無い sqlc 自体は便利 そもそも自社に Go への興味がある人がいない 自社サービスの規模ではボトルネックになるのはデータベースであって言語ではない もしアプリでスケールが必要なときは Rust や Erlang/OTP に切り替えれば良い コネクションプールは PgBouncer を利用すればいい TypeScript からは 1 コネクション 1 接続で問題無い どうせフロントエンドでは TypeScript を書く 自社では React
止まらないLinuxシステムを構築する!高信頼性クラスタ入門 クラウド、オンプレどちらの環境でも障害は不意にやってきます。 そんなときもサービスを継続提供するためのHAクラスタ。 今回は高信頼性を実現するクラスタの考え方の基本から、具体的にLinuxクラスタを設計/構築するコツについて解説します! こんな方にオススメ ・Linux初心者の方 ・Linuxが好きな方 ・高信頼性、高可用性クラスタに興味ある方
【ソフトウェア設計】例外処理を考える
はじめに 最近書いてるソフトウェア設計シリーズです。今回は例外に関して。以前、以下のような記事を書いたのですが、もう少し深堀して書いてみました。 ちなみにソフトウェア設計シリーズは他には以下を書いています。 モジュールになぜ分けるのか？ モジュール、依存、そしてカプセル化 モジュールをどう分割するのか？ 簡潔さは力なり？ 予測可能な振る舞いと簡潔さについて ドキュメントとしてのコメント TL;DR 例外は「原則」キャッチしない 業務例外や必ずハンドリングさせたい例外はOptionalなど戻り値の方が便利 だいたい以下の図が言いたい事のすべて 例外処理とは？ 「例外処理(Exception Handling)」は言語に依らず普遍的な関心事です。端的に言えば例外処理は異常やシステムの動作に不備が発生した際の特別な分岐処理です。リカバリやリソースの解放、あるいはユーザへの通知などがありますね。
はじめにこんにちは、PIVOTでソフトウェアエンジニアをしている裾分です。PIVOTは2024年2月にアプリ・Webを本格始動しました。私はPIVOTにジョインして以降、サブスクリプション機能の開発をしてきたので設計の概要と決済プラットフォームが係る実装の難しさについてまとめてみました。 本題冒頭のリリースの通り、PIVOTはYouTubeからプロダクトに集中するにあたり、サブスクリプション機能をリリースしています。 サブスクリプションを実装するにあたり考慮すべき点として、以下の状態を考慮する必要があります。 自サービスで管理する状態 ユーザーのサブスクリプション ユーザーのプラン 他サービスで管理する状態 ユーザーへの課金を行うプラットフォームに登録されているサブスクリプションの状態 決済状態（成功 | 失敗 | …） PIVOTの場合では、決済プラットフォームとして App Store
コードなしでWeb3コンテンツなどを開発することができるプラットフォーム・thirdwebの創設者であるadammaj氏が、「経験なしで2週間でゼロからGPUを構築した」と報告しています。 I've spent the past ~2 weeks building a GPU from scratch with no prior experience. It was way harder than I expected. Progress tracker in thread (coolest stuff at the end)👇 pic.twitter.com/VDJHnaIheb— adammaj (@MajmudarAdam) ◆ステップ1：GPUアーキテクチャの基礎を学ぶ adammaj氏はまず、最新のGPUがアーキテクチャレベルでどのように機能しているのかを理解しようとしたそうで
はじめに 本記事は、今年発売された書籍『データモデリングでドメインを駆動する――分散／疎結合な基幹系システムに向けて』を読んだ感想と、QAエンジニアである私*1が日々の業務で役立ちそう（既に役立った）部分を紹介します。今のところ、本書籍は2024年のベストバイな気がします。 gihyo.jp 本記事で一番伝えたいこと データモデリングについての考えが深まるぞ 開発者が読むともっと役立てることができると思うぞ QAエンジニアである私が読んでも役立つぞ 読み始めてすぐに「良い買い物だった」と思って思わずポストしている様子 目次 はじめに 本記事で一番伝えたいこと 目次 本書籍で良かったこと：データモデリングをするにあたっての整理と用語の提案がすごい SoAとSoMという整理 「残」という概念 データベース設計とは違う「データモデリング」という考え方 QAエンジニアとして、業務に役立てそうなこと
Starting to write code without proper planning is like trying to build IKEA furniture with a blindfold on. If against all odds, you somehow manage to assemble something resembling a dresser, there’s a good chance you’ve forgotten a crucial piece and you’ll be throwing the whole thing out in a week and heading to Pottery Barn (like you should have in the first place). [1] When getting to know a new
連載「設備設計現場のあるあるトラブルとその解決策」では、設備設計の現場でよくあるトラブル事例などを紹介し、その解決アプローチを解説する。連載第1回は「若手エンジニアにありがちな強度設計ミス」をテーマに取り上げる。 本連載は、前回シリーズ「いまさら聞けない 製品設計と設備設計の違い」をイントロダクションと位置付け、設備設計の現場でよくあるトラブル事例などを紹介し、その解決アプローチを解説していきます。 今回のテーマ：若手エンジニアにありがちな強度設計ミス 新年度が始まり、設計現場は「これから会社に貢献できるよう設計を頑張るぞ！」と意気込む若手エンジニアと、「今後の活躍が楽しみだ」と若手に大きな期待を寄せるベテランエンジニアとで活気づいていることかと思います。皆さんの現場はいかがでしょうか？ この春から、あなたの現場にもやる気みなぎる若手エンジニア（Aくん）が配属され、ベテランの立場であなたが
TDDを実践する中で身につけてた「設計に関するスキル」を3つ - Mitsuyuki.Shiiba
TDDを実践する中で身につけた「設計に関するスキル」があるなぁと思ったのでメモを残しておくことにする。TDDをやるときのスキルではなく設計をするときのスキル。 染み込んでいる TDDは以前に書いたように（ってもう7年も前か・・・）あんまり使わなくなっている。でも心の中にある。ウェブアプリケーションエンジニアとしての自分にとても大きな影響を与えている。 bufferings.hatenablog.com TDDから学んだ設計に関するスキル 3つ思い浮かんだ まずは動くものを作る 必要な分だけ作る 「ありえない」の処理を考える 注意 ウェブアプリケーションを書くときのことを考えながら書いている。ライブラリやフレームワークのようないろんなユーザーから利用されるものは、今回の話の対象ではない。 1. まずは動くものを作る TDDで実装を書くときは「キレイじゃなくてもいいからテストがグリーンになる（
はじめに 私は2023年10月より、内定直結型エンジニア学習プログラム「アプレンティス」に2期生として参加しています。 アプレンティスの課題としてオリジナルプロダクトを開発したので、その内容をまとめようと思います。 今回はその「要件定義・設計編」となります。 続きの「実装編」はこちらから ↓ 目次 1.テーマ(エレベーターピッチ) 2.課題定義 3.要件定義 4.業務フロー 5.画面遷移図 6.ワイヤーフレーム 7.デザインカンプ 8.プロトタイプ 9.テーブル定義 10.ER図 11.使用技術 12.システム構成図 13.学んだこと 1. テーマ(エレベーターピッチ) 自身のベジタリアンの種類に対応したレシピやレストランを見つけたいあらゆる種類のベジタリアン向けのVegEvery (べジェヴリー)という"食"の情報サイトです。 ベジタリアンレシピやフード、レストランの情報を投稿・閲覧する
Google Cloudで実践！ クラウドネイティブな開発 サービスメッシュを活用して、クラウドアプリケーションのオブザーバビリティを高める 本連載は、Google Cloudのアプリ開発とDBプロダクトにおけるスペシャリスト達が、Google Cloudプロダクトを利用した、クラウドネイティブな開発を実践する方法を解説しています。 第6回では、サービスメッシュについて紹介します。 主に対象となる読者は、クラウドを利用してアプリケーションを開発するエンジニア、またはその基盤を構築するエンジニア、サービス開発に携わるプロダクトマネージャーを想定しています。 マイクロサービスアーキテクチャの課題 これまでの連載ではクラウドネイティブなアプリケーションの開発について紹介しました。小さい独立して動作するサービスが連携するマイクロサービスアーキテクチャは、スケーラビリティ、独立した開発の容易さ、
みずほ銀行のシステム開発裏話、なんかもう俺らからすると当たり前すぎて、逆に何言ってるか解らなくなるまである→「これはひどい」
𝕏 𝕃（おおきなえる）🌸⚒️ @ellnore_pad_267 雑談垢だよ。 ホロ沼にハマッているよ。 消費税を納税しているよ。 ふぁぼは既読マークだよ。 ＲＴは賛同じゃあないよ。 フォロバはしないよ。 Amazon アフィプログラムに参加してるよ。 ホロ箱推し member of 🌸⚒️🐏🌽🥐 sugaryo-pad.hatenablog.com
デザイナーの帽子をかぶったわたしが、プロダクト開発するうえでスクラムチームに提供したいこと / what I want to provide to Scrum teams when developing products
2024年4月5日、江崎グリコは基幹システムの切り替え後にシステム障害が発生し、同社や販売委託を受けている一部の冷蔵食品の出荷に影響が生じていると公表しました。ここでは関連する情報をまとめます。 障害後緊急対応するも在庫数合わず業務停止 今回システム障害が起きたのは江崎グリコの基幹システムで2024年4月3日の新システムへの移行に伴い発生した。物流、販売、会計などを一元管理するERPパッケージ SAP社製「SAP S/4HANA」で構築されており、「顧客への継続的価値創出を可能にするバリューチェーン構築と経営の迅速な意思決定を目的とした、調達・生産・物流・ファイナンスなどの情報を統合する基幹システム」と同社では説明している。障害原因の詳細は同社から開示されてはいないが、システム障害の問題個所の特定は済んでいる。なおサイバー攻撃によるものではないと取材に答えている。*1 システム障害の影響に
以前に アプリケーションを停止させずにRDBのスキーマ変更する話 を書きました。 developer.feedforce.jp 今日は、その実践編というか、実例として EC Booster というサービスで請求関連テーブルのスキーマを変更した話をしようと思います。 はじまりのテーブル 元々、 EC Booster の請求を管理するテーブルは、このような形でした。 create_table "monthly_charges", id: :uuid, default: -> { "gen_random_uuid()" }, force: :cascade do |t| t.uuid "shop_id", null: false t.integer "year", null: false t.integer "month", null: false t.datetime "created_at"
はじめに こんにちは、バックエンドエンジニアの@zawaです。 私は入社以来、1年ほどショップオリジナルの「メンバーシップ」（会員制度）を開設できる「メンバーシップApp」の開発に携わってきました。 少し前になりますが、2024年2月末にメンバーシップAppの特典交換機能をリリースしました。 リリース内容の詳細はぜひこちらをご覧ください！ baseu.jp メンバーシップAppは、モジュラーモノリスのアーキテクチャ上に構築しており、モジュール内部ではドメイン駆動設計（以下、DDD）を採用しています。 先日公開された動画の中でも紹介していますので、ご興味がある方は是非ご覧ください。 【前編】クリーンアーキテクチャの柔軟性を生かしたメンバーシップAppの開発の道筋 - YouTube 【後編】クリーンアーキテクチャの柔軟性を生かしたメンバーシップAppの開発の道筋 - YouTube 本記事で
SOLID原則完全に理解した！になるための本
SOLID原則を学び、完全に理解した！になるための本
マイクロサービスからモジュラーモノリスを経て新マイクロサービスへ - Techtouch Developers Blog
バックエンドエンジニア兼万年ダイエッターの taisa です。テックタッチは、以前マイクロサービスからモジュラーモノリスを経て新マイクロサービスへの切り直しを実施しました。本記事では、マイクロサービス・モノリスについて簡単に触れながらテックタッチがどういったプロセスでマイクロサービスの切り直しを実施したかを紹介します。 はじめに マイクロサービスとモノリス マイクロサービスとは マイクロサービスの利点 モノリスとは 単一プロセスモノリス モジュラーモノリス 分散モノリス テックタッチの場合 初期の頃の構成イメージ マイクロサービス切り直し前 特徴 モジュラーモノリス化 サービスの移行 別ドメイン境界でサービス切り直し イベントストーミング マイクロサービス切り直し後 DB 統合へ続く まとめ 参考 はじめに テックタッチは初期の頃からマイクロサービスアーキテクチャを採用していますが、一部の
Webページを作成する時に役立つ、HTMLをはじめとする必要最小限のファイルをまとめたシンプルな基本テンプレート一式を紹介します。 最新版は、最近の実装に合わせた設計にアップデートされました。 HTML5 Boilerplate -GitHub HTML5 Boilerplateの特徴 HTMLの基本テンプレート HTML5 Boilerplateの使い方 HTML5 Boilerplateの特徴 HTML5 Boilerplateは、Webサイトやアプリを実装するためのプロフェッショナルなフロントエンド用のHTMLの基本テンプレートです。 実践的な基本のテンプレート 200人を超える貢献者による10年間の分析・研究・実験を元にしています。 ブラウザの見え方を最適化 プログレッシブエンハンスメントを念頭において設計されています。 インクルード 推奨されるmetaタグやその他の利点を備えたH
はじめに 本記事ではレベルアップしたいエンジニアが読んでおくべきQiita記事を紹介します。厳選に厳選を重ねた43記事です。全ての記事を読んでおく必要はありませんが、ちょっとでも「分からないな」「興味あるな」など思ったタイトルがあれば読んでみてください。 次の4種類に分類して紹介しています。参考にしてください。 フロントエンド バックエンド インフラ・Linux周りの知識 その他 それでは、早速紹介していきます！ 弊社Nucoでは、他にも様々なお役立ち記事を公開しています。よかったら、Organizationのページも覗いてみてください。 また、Nucoでは一緒に働く仲間も募集しています！興味をお持ちいただける方は、こちらまで。 フロントエンド まず最初はフロントエンドエンジニアに読んでおくべきとおすすめできるQiita記事を11個選びました！フロントエンドエンジニアとしての基礎が身に付く
こんにちは。Findy Freelanceの開発チームでエンジニアをしている2boです。 この記事では私が開発生産性を上げるために開発をする前に考えていることについて書きます。 ここで「開発をする前」というのは次のようなタイミングを指します。 PdMなどから新規施策の仕様について相談を受けたとき 起票された開発Issueを最初に確認するとき 自分がIssueを作成するとき なぜこのタイミングで考えるかというと、開発を進める上での方向性を間違える可能性を減らし後から軌道修正をしやすくするためです。 なおこの記事においては、開発生産性を「開発成果物の提供価値を投入リソースで割ったもの」とします。 いくら頑張って開発をしても、そもそもやるべきことの方向性を大きく間違えると提供価値が0に近づくため開発生産性が低下します。 特に開発が高速なチームで方向性を誤ると高速に間違った方向へ進んでしまうことに
React のルール – React
様々な概念を表現する方法がプログラミング言語によってそれぞれ異なるように、React にも、理解しやすい方法でパターンを表現し高品質なアプリケーションを産み出すための慣用的な記法、ないしルールが存在します。 このセクションでは、自然な React コードを書くために従うべきルールを説明します。自然な React コードを書くことで、安全で整理されており、組み合わせ可能なアプリケーションを作成することができます。以下に挙げる特性により、アプリは変更に対して頑健になり、他の開発者やライブラリやツールと連携しやすくなります。 以下のルールは React のルールとして知られています。これらを守っていないならアプリにバグがある可能性が高い、という意味で、これらは単なるガイドラインではなくルールです。またこれらを守らない場合、あなたのコードは不自然で、理解や推測が難しいものになるでしょう。 Reac
サーバーレスの次はなんなんだ
はじめに この記事は、同人誌サークル「めもおきば」から不定期刊行している技術解説本「めもおきばTecReport」に書いたものを公開用に再編集したものです。 ⇒ めもおきばTecReport 2023.12 この記事のほかにも「私もSecHack365に参加したい！」や、「2023年振り返りと2024年技術予想」としてこんなキーワードを取り上げているので、気になったらぽちっとしてください！ メガクラウドと特化型クラウド／ハイパーバイザーのSoC化／ライセンスとクラウドベンダー／イベント駆動型API／LLM時代のAIペアプロ力／生活必需品としてのGPU・NPU／Passkey／ウェブアクセシビリティ／リアルイベントの再開 サーバーレスの次はなんなんだ サーバーレスと呼ばれる技術ムーブメントが盛り上がり始めて8年近くが経ちました。各クラウドベンダーのFaaS（Function-as-a-Ser
Yahoo! 知恵袋のフロントエンドには26000行を超えるユニットテスト(1つのcontrollerのユニットテスト)や、多くのロジックを含むcontrollerがあります。これらによって追加実装・保守が難しい状況です。この問題を解決するために、リアーキテクトを行いました。以下について主に話そうと思っています。 ・リアーキテクトで取り組んだこと ・リアーキテクトの結果・学び・反省点
「業務システムの画面デザインを作るときに参考になるサイトってある？」 「使いやすいUIにするにはどのようなポイントに注意したら良い？」 業務システムは操作性が命。システムの画面デザインが優れていないと、ユーザーが不便に感じてしまうかもしれません。使いやすいシステムを構築するには完成しているデザインやUIを参考にし、開発中の業務システムにうまく取り入れる必要があるでしょう。 そこで本記事ではデザイン・エンジニアリング両面からサービスの設計・開発を行っているFlowzが以下の内容について詳しく解説します。 業務システムの画面デザインサンプル7選 画面デザインにおける5つのポイント 改善すべき画面デザインの特徴 デザインのサンプルを探している方はもちろん、画面を設計する際に意識すべきポイントについても解説するので、ぜひ最後までお読みください！ なおFlowzではデジタル領域でのサービス設計、プロ
コーナンの作業台、コストカットの鬼みたいな薄い鉄板性だけど脚のプレスの入れ方に驚いた「これどんな神が設計したんですか？」【追記あり】
Akihiro Komori @comocc コーナンの作業台買ったんです。薄い鉄板で出来ててコストカットの鬼みたいな雰囲気。なんだけど、この脚のプレスの入れ方をみて驚いた。これどんな神が設計したんですか？この加工だけで強度と安定性爆上がりですよ。大学は機械系だったけど、こんなの授業じゃ習わなかったなあ。惚れ惚れする。 pic.twitter.com/vMDuBeXdJ6 2024-04-17 10:32:24
ゲーム企画書の作り方。製作の参考例。考え方｜うきょう|フリーゲームプロデューサー兼マーケッター（株スタジオデルタ代表）
サバイバルホラーアクション『あけておねがい』を製作した際の企画設計の 流れをご紹介します。 ゲームの企画書を製作する方の参考になれば幸いです。 まずは企画書 続いて企画書を設計する際の流れ、考え方をご紹介 １｜企画書の紹介（完成形） 2｜企画書設計時の流れ、考え方ゲーム制作、企画設計、マーケティングの会社をしています。 お仕事のご相談は info@studiodelta.co.jp または X までご連絡ください。 https://twitter.com/home
近年、AIの進化によりソフトウェア開発のプロセスが大きく変化しています。これまで手作業で行われてきた画面設計やプログラミング作業も、AIの登場により驚異的なスピードに進化しています。今回は、その中でも私が実際に使っている2つのAIツール、UizardとUI Sketcherについて紹介します。 なお、本記事では医師と患者を繋ぐマッチングサービスという架空のサービスを例に話を進めます。 Uizard: サービス概要からUIデザインを自動生成 Uizardは、画面設計作業を劇的に短縮する革新的なAIツールです。このツールを使えば、サービス概要を入力するだけで、わずか数分で美しく洗練されたUIデザインが生成されます。つまり、開発者は時間をかけてUIデザインを考える必要がなくなり、その時間を他の重要な作業に集中することができます。 Uizardの使い方 メニューから Generate with A
NewSQLはデータベースに革命を起こすか - NetflixにおけるCockroachDBのユースケース｜ミック
近年のデータベースの新潮流にNewSQLと呼ばれる一群のデータベース製品群の登場がある。そのコンセプトを一言でいうと、RDBとNoSQLのいいとこどりである。SQLインタフェースと強いデータ一貫性（ACID）というRDBの利点と水平方向のスケーラビリティというNoSQLの長所を兼ね備えた夢のようなデータベースである。下図に見られるように、RDBとNoSQLが鋭いトレードオフを発生させていたのに対して、NewSQLではそれが解消されているのが分かる。 RDB vs NoSQL vs NewSQL本当にそのような夢の実現に成功しているか、というのはまだ議論が続いているが（クエリのスループットを出すためにレイテンシを犠牲にしているので本当にトレードオフを解消はしていない、などの問題が指摘されている）、商用でも利用可能な製品としてGoogle Spanner、TiDB、YugabyteDB、Coc
PHPカンファレンス小田原2024での発表資料です https://fortee.jp/phpconodawara-2024/proposal/4d39c7ef-058c-4648-b1d7-5510497e0d81
オブジェクト指向の本では「自転車をモデリングしてみましょう」「鳥をモデリングしてみましょう」ということが、どういうシステムで使うか規定せずによく書かれています。 けれども、モデリングではどういうシステムで使うかということが大事で、それを決めずにモデリングを考えても意味がありません。モデリングすべきはモノではなくシステムのプロセスです。 よく、オブジェクト指向では現実をモデリングするのようなことが言われますね。 例えば鳥が鳴くとして、その一種であるニワトリをどうモデリングするか、ということを考えるとします。 そうすると、まず void 鳴く() { print("コケコッコー"); } のようなメソッドを考えるのですけど、コケコッコーとうまく鳴けるのは鳴き慣れたニワトリです。そのため、鳴くメソッドにカウンターを用意してどんどんうまくコケコッコーになるようにしたくなります。 いや、そもそも、コ
はじめに 今回は私が3年間で読んだ技術書をひたすら紹介します。 私は2021年4月に新卒でSIerに就職し、2024年4月でエンジニア4年目となりました。 そんな私の入社時のスキル感はどうだったかというと... 非情報系学部卒の理系 学部4年生の時に研究室で少しPythonを触ったことがある程度 HTTP?なにそれ？ でした。 こんな感じでほぼゼロからのスタートでしたが、3年間でどのくらいのスキル感になったかというと、ざっくりと 基本的に一人称で開発業務ができる 小規模のシステム開発なら技術選定やアーキテクチャの検討も可能 某(若手向け)技術コンテストで入賞経験あり OSSコントリビューション経験あり IT関連の資格7つ取得 くらいには成長することができました。 これから紹介する技術書を読むだけでこのくらいのスキル感になれますという話ではなく、当然日々の業務であったり、その他のインプット/
OpenShift.Runで登壇した資料です。
はじめに 「テーブル・DBを設計するときのさいきょうの極意」を完全に理解したので 初心者（私）向けに共有する記事です。 どうぞ揉んでいただければ幸いです。対戦よろしくお願いします。 さいきょうの極意 初心者が「テーブル・DB設計して」と言われると、 「アソシエーションってあったよね・・・バリデーションも？中間テーブルを使うときと使わないときと・・・」と大変に混乱し、何から手をつけていいかわからなくなります。 そんなあなたにこれ！ テーブル・DB設計は「属性」と「関係」の２つだけ 「属性」は必要なものを書くだけ 「関係」は 1:1 / 1:N / N:N しかない（しかも、ほとんど 1:N） これが極意だ！！！ 一般的な、「ユーザーがいて、投稿ができて、コメントといいねができるサービス」で考えてみましょうか。 users / posts / comments / likes のテーブルが必要
君たちの知らないAPIデザインパターンの話をしよう
このように、RESTの設計原則に従ってAPIを構築することで、ほとんどのAPI設計は直感的に、かつ問題なく行うことができます。 デザインパターンの紹介 ここからが本題です。大抵の場合、上の例で示したようなAPI設計で十分です。 ただ、複雑な要件では、上のような典型的なAPI設計のみでは良いAPIを設計するための4つの特性を満たせないことがあり、そのような場合のためにデザインパターンが有効です。 カスタムメソッド 概要 カスタムメソッドは、標準的なCRUD操作（作成、読み取り、更新、削除）では対応できない特定の操作が必要になる場合に便利です。例えば、メールの送信や即時の文書翻訳など、通常の create や update メソッドでは処理が難しい操作がこれに該当します。 参考までに、以下にGoogleが出しているカスタムメソッドの記事を示します。 実装例 以下は、カスタムメソッドを扱うAPI
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ディメンショナルモデリング勉強会を実施しました - 10X Product Blog
Node.js の進化に伴い不要となったかもしれないパッケージたち
自社サービスのバックエンドを Go から TypeScript へ切り替えるための整理
止まらないLinuxシステムを構築する_高信頼性クラスタ入門
プレミアムプランの状態管理と決済ハンドリングの難しさ｜tsusowake
「ゼロからGPU開発」に経験なし＆わずか2週間で成功した猛者が登場
QAエンジニアから見た『データモデリングでドメインを駆動する』書評 - ブロッコリーのブログ
Domain Modeling: What you need to know before coding
若手エンジニアにありがちな強度設計ミス【前編】
初めての個人開発 ①要件定義・設計編 - Qiita
サービスメッシュを活用して、クラウドアプリケーションのオブザーバビリティを高める | gihyo.jp
生成AIを活用したサービス設計のススメ〜仮説構築編〜
江崎グリコの基幹システム移行トラブルについてまとめてみた - piyolog
請求関連テーブルのスキーマ変更をした話 - Feedforce Developer Blog
メンバーシップAppの開発とDDDの実践から得た学び - BASEプロダクトチームブログ
2024年版最近の実装に合わせた、HTMLでWebページを実装するための必要最小限をまとめたテンプレート一式
シスコ製のネットワーク構成図の作成・管理ツール「Network Sketcher」v2.2.0 ほか ～16件を掲載（4月22日のダイジェストニュース）【ダイジェストニュース】
レベルアップしたい人必見 Qiita記事43選 - Qiita
開発生産性を上げるために開発をする前に考えていること - Findy Tech Blog
Yahoo! 知恵袋フロントエンドをリアーキテクトしている話
ドコモがスマートリング「EVERING」を発売へ、5月上旬以降
【定石】業務システムの画面デザインサンプル7選！UIを改善するポイントも紹介 - Keeperz
AIによる爆速開発：画面設計からプログラミングまで自動化！？ - Qiita
単体テストを書かない技術 #phpcon_odawara
目的を規定せずにモデリングを考えても意味がない - きしだのHatena
新入社員に向けて私が3年間で読んだ技術書を紹介する - Qiita
「共通基盤」を超えよ！ 今、Platform Engineeringに取り組むべき理由
テーブル・DB設計するときの極意 - Qiita