2022/6/22 @ MoneyForward 勉強会 で実施した A Philosophy of Software Design の話です。
![A Philosophy of Software Design 後半](https://cdn-ak-scissors.b.st-hatena.com/image/square/2edb8a1b54df85a68d6f91a07425655ba189a481/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F9f746342e8924659937f8bb475a29545%2Fslide_0.jpg%3F21833852)
2022/6/22 @ MoneyForward 勉強会 で実施した A Philosophy of Software Design の話です。
読者対象 ある程度データベースに関する知識を持っている,経験年数 1 年以上のバックエンドエンジニア 特定のプログラミング言語に依存する部分は含めないため,すべての SQL 使用者を対象とする また,ゼロからの丁寧な説明というよりは,リファレンス感覚で使える記事という形にまとめる。 RDBMS の対象バージョン PostgreSQL: 9.4 以降 MySQL: 8.0.28 以降 id (データ型と INSERT 時のデフォルト埋め) 導入 一般的に採用されやすいプライマリキー用の値として,以下を考える。 連番整数 MySQL では AUTO_INCREMENT, Postgres では IDENTITY や SERIAL と呼ばれるもの UUID v1: ハードウェアごとにユニークな単調増加値 UUID v4: ランダム値 UUID v7(ドラフト): 単調増加であるタイムスタンプとラ
わかりにくいシステム構成図とは こんなシステム構成図を書いてないでしょうか? このシステム構成図のわかりにくい点が3つあります。それは 製品名は書いてあるが「役割」が書いていない データと処理が区別できない データの流れと制御の流れが区別できない の3つです。 わかりやすいシステム構成図 これら3つのわかりにくい点を改善したわかりやすいシステム構成図が↓です ポイントを解説していきます ポイント1. 製品名称ではなく「役割」を書く システム構成図には製品名称ではなくシステムコンポーネントの「役割」を書きます。 役割とは、例えば〇〇データや〇〇処理といったことであり、それを読むだけでシステムの動きを理解できる文字列です。役割をかかずに製品名称のみを書いてしまうと、その製品を知らない人が見たときに理解できません。例えば「Cloud Pub/Sub」という製品はGCPというパブリッククラウドの分
モジュラモノリスにおけるトランザクション設計の考え方 / transaction design on modular monolith
エンジニアリング会社で、それなりに長い間、働いてきた。昨日、4月1日は入社式の日だ。自分のときもそうだった。考えてみるとずいぶん昔のことだが、なんだか、ついこの間のようにも感じる。 率直に言うと、同じ会社でこんなに長く働くとは思っていなかった。エンジニアリング会社は受注産業だ。仕事が取れなくなれば、すぐに倒産する。入社したときに、「この会社は3年もつだろうか」と思ったことを記憶している。 長く働く間に、わたしも人並みに「よそに転職しようか」と思わなかった訳ではない。だが、製造業にも建設業にも、コンサルティング会社にもIT企業にも転じなかったのは、やはり「エンジニアリング」という仕事に、それなりにこだわりをもっていたからである。
皆さん,こんにちは!機械学習エンジニアの柏木(@asteriam)です. 今回は前回のエントリーに続いてその後編になります. tech.connehito.com はじめに 後編は前編でも紹介した通り以下の内容になります. 後編:SageMakerのリソースを用いてモデルのデプロイ(サービングシステムの構築)をStep Functionsのフローに組み込んだ話 モデル学習後の一連の流れで,推論を行うためにモデルのデプロイやエンドポイントの作成をStep Functionsで実装した内容になります. 今回紹介するのは下図の青枠箇所の内容になります. 検閲システムのアーキテクチャー概略図 目次 はじめに Step Functionsを使ってサービングシステムを構築する方法 学習済みモデルを含んだ推論コンテナの設定(モデルの作成) エンドポイントの構成を設定 エンドポイントの作成とデプロイ 機械
はじめに タイトルのとおり、RDBのデータモデリング・テーブル設計を行う際に参考にしている考え方と関連資料をまとめました。 P.S. なんと本記事内でいくつか参考として挙げさせてもらっている増田さん・かとじゅんさん・奥野さん・そーだいさんからコメントいただくことができました。 本当にありがとうございます。 前提 RDBを採用するのは事実を無駄なく正しく記録するため 正規化、トランザクション、制約とデータ整合性 基本的には始めに理想として集合論・リレーショナルモデルに基づいて正規化を考え(論理設計)、パフォーマンスなどの現実問題に対して折り合いをつけていく(物理設計) 制約を最大限利用する cf: ↑P91〜 ↑P.29,41 ↑P56〜 ↑5章 ↑P347~ 情報とデータ データ:単なる事実の値→これを永続化して蓄えるものがRDB 情報:データから生み出される意味や目的のあるもの→RDBか
こんにちは、id:shallow1729です。最近はインフラ寄りなお仕事をよくやっていますがこれまでにいくつかデータ移行やデータ基盤構築などのバッチ処理のお仕事をしてきました。以前にも一度そういった経験を元に記事を書いたのですが、MySQLやシステムに関する知識が以前よりも増えた今もう一度書き直したいなと思いました。 なので今回はバッチ処理を書く時のテクニック2022版という感じです。今の仕事の関係でMySQLやrailsを前提にしている話が多いですが、おそらく他のデータベースを使っている人にも役に立つ話が多いのではないかと思います。ただ、今回の記事は経験に基づくものが多く、あまりよくないアイデアもあるかもしれません。改善点や間違いなどあればご指摘ください。 冪等性を持つように 冪等性とは端的に言えばある操作を複数回実行しても一回しか実行しなかった時と同じ結果になる性質の事です。長時間かか
There’s No Such Thing as Clean CodeのHacker Newsコメント経由でコードやシステム設計・最適化についての良いコメントを見つけた。どうやらHacker Newsで何度も引用されているらしいが日本語で言及された記事が見つからなかったので取り上げてみる。 コメントは2016年のSandi MetzのThe Wrong Abstractionに関するもので、発言者のcurun1rいわく「私は設計の優先順位をこの順序で学習することで、優れた開発者になれた」。*1 4つの基準と優先順位のガイドライン 状態 > 結合 > 複雑性 > コード量 私は状態 (state)、結合 (coupling)、複雑性 (complexity)、コード量 (code) の順に削減することでコードを最適化する。 コードがよりステートレスになるなら、結合を増やすこともいとわない 結
数年前、私はこんな絵を書いて、アジャイル開発やリーン開発のついての様々なプレゼンで用いた。 そこから、この絵は急速に広まっていった!記事、プレゼン、さらには本(Jeff Pattonの”User Story Mapping”という素晴らしい読み物なのだが)にまで至る所で姿を見せた。多くの人がこの絵は反復型開発、リーンスタートアップ、MVP(minimum viable product)の本質をよく捉えていると伝えてくれた。しかし、元の文脈から切り離して物事を捉える際にはごく自然なことであるのだが、この絵を誤解している人がいる。簡素化しすぎだと非難する人もいる。(正しい指摘である) この絵はあくまで比喩である。実際の車の開発の話ではなく、車を比喩とした一般的なプロダクトの開発の話なのである。 とにかく、これらのバズからこの考えの背景を話す時だと判断したのだ。 1つ目の例:not like
あけましておめでとうございます、になるはずだったのですが、後から読んだ『Googleのソフトウェアエンジニアリング』の方を先に記事にしたので新年2本目の更新です。 ky-yk-d.hatenablog.com さて、本題。最近のお気に入りポッドキャストであるe34.fmで激賞されていた『A Philosophy of Software Design』を読みました。初版は2018年に出ていて、今回は2021年に出た第2版を読みました。 スパゲッティコードを想起させる装丁 A Philosophy of Software Design, 2nd Edition (English Edition) 作者:Ousterhout, John K. Amazon scrapbox.io どんな本? 書籍のテーマはソフトウェアの複雑さです。複雑さとは、システムを理解したり変更したりするのを困難にさせるも
この記事は GMOアドマーケティングAdvent Calendar 2021 25日目の記事です。 はじめに こんにちは、GMOアドマーケティングの星野です。 今年のアドベントカレンダーも本日で最後となりました。 アドベントカレンダーを書いていると今年も終わりということを感じます。 GMOアドマーケティングではいくつかのプロダクトをGCPへと移行をしています。 移行では障害を起こさないことが優先されますが、最終的には単に移行するだけではなく、システムをクラウドネイティブな設計に変えていくことで、クラウドの恩恵を最大限に受けれるように改善していきたいと思ってます。 既存のシステムをクラウドネイティブな設計に変えていくにはコンテナ化が必要になります。 コンテナ化を行う際の設計指針の一つにコンテナ・デザインパターンというものがあります。 今回は、書籍の分散システムデザインパターン からいくつかの
Amazon DynamoDB の特性 フルマネージド型の NoSQL データベースサービス 3つの Availability Zone に保存されるので信頼性が高い 性能要件に応じて、テーブルごとにスループットキャパシティを定義するキャパシティの Auto Scaling、オンデマンドキャパシティといった設定も可能 ストレージの容量制限がない DynamoDB のテーブル DynamoDB におけるテーブルはRDBMSにおけるテーブルと概念が異なります。 テーブルを作成する際に、Primary Key を指定する必要があります。 Primary Key はテーブルの各項目を一意に識別するために使います。Primary Key は、Partition Key および Sort Key で構成されます。(Sort KeyがなくPartition Keyのみの場合もあります) Item は R
なぜエンジニアが作る画面はダサいのか…?「理由」と「対策」を徹底解説【エンジニア向け画面デザイン講座】UXUIDesignUIデザイン画面設計 1.はじめに エンジニアの私がデザインを本気で勉強した結果、デザイナーとエンジニアはそもそも思考が大きく違っているということがわかりました。 今回は「それ」をデザインに苦手意識のあるエンジニア方にも理解してもらえたらと思い、わかりやすくまとめてみました。 2.アプリの画面デザインを考えてみよう まず、こんなアプリを考えてみてください。 フィットネストレーナーが使うアプリ トレーニングルームでお客様とお話しながら使う 端末はタブレット そして 会員の個人情報確認 前回までのトレーニング状況の確認 次回の予約受付 といったことをします。 使える情報としては、こんな感じです。 あなたならどう画面デザインをするか、もしお時間があったら考えてみてください。
このブログはグロースエクスパートナーズ Advent Calendar 2021の10日目です。 社内メンバーから要望があったので、僕自身がどのようにシステム開発の初期段階において、どのように要望を整理し、形にしていっているのかについて書きたいと思います。 なお内容は弊グループの案件を前提にしているので、システム開発は以下のような状況が一般的です。 クライアントは直接契約(プライム) 要望を出すのはクライアント企業内で事業運営側の人で、システム開発にかかわった経験がないことがある 対象システムはSoE/mode2で、一般消費者や取引先などの外部ユーザーと、社内で業務を回す内部ユーザーがいる 相手の話を整理するフレーム まず、相手から得られる情報を4つの階層にわけて整理する必要があります。 目的:達成すべきこと 戦略:目的を確実・効率的に達成するためのシナリオ 戦術:戦略を実行するための具体
この記事はRust Advent Calendar 2021の12/8日の記事です。 Rust前提の記事として書きましたが、他の言語にも適用できる考え方なので、ほかの言語勢の方々もよければお付き合い下さい。 今回のテーマは「Rustで真に安全なプログラムを書く方法」についてです。 「真に安全なプログラム」の定義は以下とします。 挙動が安定し、結果が予測可能となる 正しさの基準に基づき、プログラムの間違いを検知することができる 「真に」とはドメイン知識に基づく正しさという意味です。詳しくは後述します。 それと「そもそもRustで実装されるプログラムは安全じゃないのか」という想定質問については「メモリの操作は安全。だが、それだけでは真に安全なプログラムにはならない」が答えになります。これについて興味がある方、ぜひ最後までお付き合いください。 「真に安全なプログラム」を実現するレシピとしては「関
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く