GoogleのDesign Docsから学ぶソフトウェア設計 - Qiita
概要 Design Documentと聞くと何を想像しますか？ 一般的にDesign Documentが指すのは設計書であることが多いのではないでしょうか。 設計書、簡単に説明するのであればソフトウェアを「どうやって作るの？」を説明したドキュメントです。 Googleではソフトウェアエンジニアリング文化における重要な要素として、今回お話ししていくDesign Docsと呼ばれるものがあります。 Design Docsとは？ Design Docsとは、開発者がコーディングに着手する前にソフトウェアシステムまたはアプリケーションの開発する人が作成するドキュメントです。 => ソフトウェア設計における仕様書や設計書とは別物と捉えた方がよいです。 仕様書、設計書は作成した上でのDesign Docsの作成となるようです。 このドキュメントには、高レベルの実装戦略と主な設計の決定事項がまとめられて
ログ設計指針
概要 このドキュメントは、効率的かつ安定した、システム開発/運用をするためのログ設計指針です。 的確かつ無駄のない、ログ出力を目指します。 ログレベル ログの緊急度や用途により、以下のようにログレベルを設定する。 Log4j のログレベルを踏襲しているため、運用の状況によっては Critical などのレベルを適宜追加すると良い。 PHP における PSR-3 では、さらに細分化され emergency, alert, critical, error, warning, notice, info, debug となっている。 「出力先」「運用時の対応」は、各プロジェクトのポリシーに準じてください。 レベル 概要 説明 出力先 運用時の対応
エンジニアのための情報設計入門
今こそ変化対応力を向上させるとき 〜ログラスが FAST に挑戦する理由〜 / Why Loglass is Talking on the Challenge of Agile Framework FAST
バッチ処理の採用と設計を考えてみよう | メルカリエンジニアリング
こんにちは。メルペイで、決済・振込申請のバックエンドソフトウェアエンジニアをしている id:koemu です。 今日は、バッチ処理を行う理由について、考察を深めて設計に活かしていく話をしたいと思います。 はじめに バッチ処理とは、ある決まったタイミングで1つのプログラムが複数のデータを 一括処理 することを指します。この反対の言葉として、オンライン処理があります。オンライン処理とは、お客様の操作を初めとしたイベントをもとに 逐次処理 されるものです。OLTP(Online Transaction Processing)とも言います。 本エントリでは、バッチ処理を採用するにあたり、どういったユースケースが適切なのかを整理して、今後のソフトウェアの設計の指針にできることを目指しています。今回は、「バッチ処理を採用するとき」と「バッチ処理の設計」の2つについて取り上げます。 バッチ処理を採用する
履歴テーブルについて - 一休.com Developers Blog
この記事は一休.com アドベントカレンダーの25日目の記事です。 レストラン事業部エンジニアのid:ninjinkunです。 一休.com及び一休.comレストランはユーザー向けのシステムだけではなく、店舗や一休内の管理者向けの業務システムという性格も持っています。 業務システム経験の無かった自分が一休に転職して最初に驚いたのが、DBに履歴を保持するための履歴テーブルが大量にあることでした。 そこから履歴テーブルの存在に興味と疑問を持ち、社内外のエンジニアと履歴テーブルについて議論してきました。このエントリではそれらの議論をまとめた結果について書いていきます。 履歴テーブルのパターン まず以下の図をご覧ください。 込み入った図かつ事例が一休特化で恐縮ですが、左上の起点から始まって、右のオレンジの部分が最終的な実装パターンです。 図にあるとおり、たいていのユースケースでは以下の3パターンの
タグ機能を実現するための便利なデータベース設計を３つ紹介 | colori
AND検索 「CSS+HTML+JavaScript」で検索する場合は以下のようにします。 SELECT * FROM `delicious` WHERE tags LIKE "%CSS%" AND tags LIKE "%HTML%" AND tags LIKE "%JavaScript%" OR検索 「CSS|HTML|JavaScript」で検索する場合は以下のようにします。 SELECT * FROM `delicious` WHERE tags LIKE "%CSS%" OR tags LIKE "%HTML%" OR tags LIKE "%JavaScript%" 引き算検索 「CSS+HTML-JavaScript」で検索する場合は以下のようにします。 SELECT * FROM `delicious` WHERE tags LIKE "%CSS%" AND tags LI
ハイボールと、本質的安全設計の教え | タイム・コンサルタントの日誌から
『本質的安全設計』という言葉を聞いたことがあるだろうか。世間ではよく安全とか安心とかいったことを話題にするが、安全の意味をつきつめて考えている人は、必ずしも多くない。本質的な安全設計とは、われわれがモノや仕組み（システム）を作る上で、欠くことのできない概念である。今日はこれについて少し述べてみたい。 機械の安全設計については、そのものずばり「機械類の安全性―基本概念，設計のための一般原則」という名前の国際規格 ISO12100 が存在する。このISO規格によれば、機械類の安全は、『設計者対応』と『操作者対応』に分けられる。つまり、作る側による配慮と、使う側（消費者・操作者）による注意の、両方がいるというわけだ。ここまではいいだろう。 では、肝心の作る側（設計者）の対応は、どのように行うべきか。ISO12100は、 （１）本質的安全設計によるリスクの低減 （２）安全防護によるリスクの低減 （
トランザクションデータ（とマスターデータ）について思うところ - 急がば回れ、選ぶなら近道
業務系のデータ処理では、大きくはトランザクションとマスターに分かれる。 マスターデータは特に、モデルや制御の方法が何かと面倒くさいので、よく議論になる。「マスターデータの管理の手法」というセミナーまで定期的に普通に開かれることも多い。他方、トランザクションデータ（以下TXデータ）は、普通に受け渡しのデータなので、フラットにダラダラ書いておけばよい、という扱いが大抵になる。そもそもER志向でモデルを設計すると、ほとんどは図面はマスターで占められ、TXデータはやたらなんか大量のフィールドを持つ大きなクラスがあるわいね、という扱いも多い。 あと、設計の観点からいうと、ERベースだとマスター設計が花形になる。まぁわかりやすいし、設計作業がしやすい。マスターは「構造」になり、TXデータは「構造」になりにくい。設計者は「構造」が好きだ。良くできた設計は確かに堅牢で、一定の変化にも追随できる。ある種の「
大量データをスムーズに処理 失敗しないバッチ処理のアーキテクチャ設計、5つのポイント
バッチ処理とは 前回はWebアプリのアーキテクチャ設計の基礎を解説しました。今回はバッチ処理を円滑に行うためのアーキテクチャ設計のポイントを紹介します。 バッチ処理とは、蓄積された複数件のデータを、まとめて一括処理する処理形態のことを指します。このような処理形態においては、大量データの処理を一定時間以内に完了させるためのアーキテクチャを、さまざまな角度から検討していく必要があります。 また、画面オンライン処理とは異なり、ユーザーとの対話なく処理が進められます。よって、バッチ処理の途中でエラーが発生した場合の対応を考慮して、アーキテクチャを設計しなければなりません。バッチ処理の基本についてより深く知りたい方は、下記参考記事をご参照ください。 参考リンク:鉄板焼のお店から学ぶ、バッチ処理"超"入門（＠IT） バッチ処理におけるアーキテクチャ設計時の検討ポイント バッチ処理のアーキテクチャを考え
システム間連携のアーキテクチャ、4つの基本パターンと正しい適用のポイント
システム間連携のアーキテクチャ、4つの基本パターンと正しい適用のポイント：徹底解説！ ITアーキテクトとは何か？（4）（1/2 ページ） ITアーキテクトの役割を、具体的かつ分かりやすく解説する本連載。今回は一連の業務処理遂行のために、複数のシステムを連携させ機能を組み合わせていく「システム間連携」の処理方式を徹底解説する。 あらゆる業務プロセスに最適なシステム間連携を設計するためには？ 前回は大量データをスムーズに処理するためのバッチ処理のアーキテクチャ設計を解説しました。今回はシステム間連携のアーキテクチャを紹介します。 ビジネス上の要求を達成するために、複数のシステムを連携させ機能を組み合わせていくことで業務処理を遂行していくことは少なくありません。このような「システム間連携」の処理方式はさまざまですが、ここでは次の4つの基本パターンに分類します。 リソース共有（データベース共有、デ
続・リトライと冪等性のデザインパターン - リトライはいつ成功するか - Blog by Sadayuki Furuhashi
三度の飯よりエラー処理。古橋です。 大変好評をいただいた序章リトライと冪等性のデザインパターンの続編です。 前回はほぼ前置きでしたが、今回は冪等でない操作を冪等にする具体的なテクニックもまとめていきます。 パターン２：エラーを区別してDELETEを冪等にする リソースに常に一意なIDが振られていれば、Deleteを冪等にするのは難しくない。そもそも同じリソースを2度削除することはできない。 一つ注意するべきなのは、削除されたリソースのIDが再利用されるケースでは、Deleteの冪等性は保証されない。例えば、kill -KILL <pid> コマンドはDelete系のAPIと考えられるが、pidは再利用されるので、何度も繰り返すと意図しないプロセスを殺してしまう可能性がある。 一般にIDの生成は非常に難しい問題だが、Deleteに関してのみ言えば再利用されなければいいので、単調増加する整数（
Webアプリ構築で、まず考えるべきアーキテクチャの検討ポイント（基礎編）
Webアプリ構築で、まず考えるべきアーキテクチャの検討ポイント（基礎編）：徹底解説！ ITアーキテクトとは何か？（2）（1/4 ページ） 連載目次 ユーザーの要求をアーキテクチャに落とし込む方法とは？ 前回は、アーキテクトの役割とタスクについて解説しました。今回からは、アーキテクチャ設計の話に入っていきたいと思います。アーキテクチャ設計の最初の段階で重要なのは、エンドユーザー／ユーザー企業の要求を見極めて、それをアーキテクチャに落とし込むことです。システムを設計する上で、ベストオブブリードでシステムを構成できる現在のようなオープンな環境の中では、さまざまな選択肢が存在します。その選択肢から選ぶ際に優先されるのは、「ユーザー要求」だということです。 例えば、顧客が「リアルタイムな情報反映と、その活用」を望んでいるにもかかわらず、バッチ処理中心型のシステムを設計・構築することは、エンドユーザー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Worse Is Better - 過去を知り、未来に備える。技術選定の審美眼 2019 edition / Worse Is Better - Understanding the Spiral of Technologies 2019 edition
それはYAGNIか? それとも思考停止か?
設計の「なぜ」を考える | タイム・コンサルタントの日誌から