お前らがModelと呼ぶアレをなんと呼ぶべきか。近辺の用語(EntityとかVOとかDTOとか)について整理しつつ考える - Qiita
お前らがModelと呼ぶアレをなんと呼ぶべきか。近辺の用語(EntityとかVOとかDTOとか)について整理しつつ考えるmodelDDD設計 みなさんは、Modelと言われたときに何をイメージしますか？ こんなアレを思い浮かべた方も多いかと思います。 マサカらせてください。やはりお前らのModelは間違っている。 アレをModelと呼ぶと何が不味いのか すみません、早速言い過ぎました。半分は正しいです。MVCの発明者、Trygve Reenskaug氏による1979年の説明によると、 Models represent knowledge. A model could be a single object (rather uninteresting), or it could be some structure of objects. 1 このように「Modelは単体のオブジェクトであっても
機能要件の合意形成ガイド バッチ編
Information-technology Promotion Agency, Japan Software Engineering Center Software Engineering Center Copyright © 2010 ＩＰＡ, All Rights Reserved 機能要件の合意形成ガイド(ver.1.0) ～「発注者ビューガイドラインver.1.0」改訂版～ 分冊６ バッチ編 2010年3月31日 独立行政法人 情報処理推進機構 ソフトウェア・エンジニアリング・センター 要求・アーキテクチャ領域 機能要件の合意形成技法ＷＧ 1 Software Engineering Center Copyright © 2010 ＩＰＡ, All Rights Reserved 機能要件の合意形成ガイド 分冊６ バッチ編 使用条件 <ガイドをご使用になる前にお読みください> 機
Web系の自分が想像と障害で学んだバッチ処理・設計の基本 - コンポツさん
バッチ処理というのはそれ単体で勉強しようとするとなかなか何を勉強したらいいのかわからないことが多い。 特に経験がWeb系ばっかりだと、いざバッチ処理を実装しようとした時に基本的なノウハウを知らないままに書いてしまうことが多い。 バッチ処理というのは実態を整理すると「何らかのトリガーを期に起動し、データをロード・加工・変換・集計してから、出力する」という事になる。 まぁ、INがあって処理してOUTがあるという点では関数だと考えてもいいだろう。 システムの利用者(人に限らない)のアクションとは直接関係ない処理であったり、利用者のアクションをトリガーとしていても、即時にレスポンスがいらないor返せない場合に バッチ処理を選択する事が多い。 実現方式はシェルスクリプト、LL言語、実行可能バイナリだったりするし、デーモンとして立ち上げる場合もある。 利用者の操作に対して対話的・同期的な処理はオンライ
DockerでサクッとDBからER図を作成する - Qiita
SchemaSpyというDBのスキーマを解析してテーブルの一覧やER図を出力してくれるツールがあります。 このツールの公式Dockerイメージが公開されており、非常に使いやすいので紹介させて頂きます。 https://hub.docker.com/r/schemaspy/schemaspy/ コマンド docker run -v "$PWD/schema:/output" --net="host" schemaspy/schemaspy:snapshot \ -t <DB種類> -host <DBホスト名/IP>:<ポート> -db <DB名> -u <DBユーザー名> -p <DBパスワード> このコマンドを実行するとカレントディレクトリのschemaディレクトリに解析結果のHTMLが出力されます。 （コンテナは自動的に終了します） docker run のオプション -vオプションで指
詳細設計書が滅亡しない理由 - kagamihogeの日記
IT 業界というか SIer の枠組みの中で働いている人であれば、一度は詳細設計書ないし詳細仕様書というドキュメントを見たか書いたことがあるだろう。 Excel 方眼紙の悪夢 詳細設計書の話の前にちょっと触れておきたいのが「Excel 方眼紙」 これまでのプロジェクト経験とネットの情報を見る限り、詳細設計書はほぼ 100% コレで書かれている。Excel 方眼紙がどのようなものかは こんな感じ である。典型的な使われ方は 【図解!!コレが方眼紙Excelだ！】:島国大和のド畜生 がわかりやすい。 「Excel 方眼紙」でググるとわかのだが、コイツは猛烈に嫌われている。一発作り捨てならば、図や表を交えたドキュメントをそこそこ作りやすいという利点はある。プレゼンや紙印刷を考えないならば、個人差はあれど PowerPoint 並の使い勝手を覚える人はいる。 がしかし、Excel 方眼紙はそのメリ
DB論理設計のノウハウ - Qiita
DB設計の概要を簡単におさらいした後、論理設計について主にまとめていきます。 DB設計の全体手順のおさらい DB設計は、大きく論理設計と物理設計に分けられます。 概念スキーマを定義します。 エンティティの抽出 エンティティの定義 正規化 ER図の作成 物理設計 論理設計の結果を受けて、データを格納するための物理的な領域や格納方法を決めます。 テーブル定義 インデックス定義 ハードウェアのサイジング ストレージの冗長構成決定 ファイルの物理配置決定 テーブルの構成要素のおさらい 行と列 行(レコード)：横のデータの組 列(カラム)：縦のデータの組 キー キーとは、DBのテーブルから特定のデータを引き出すための鍵です。 主キー：その値を指定すれば、必ず一行のレコードを特定できるような列の組み合わせのこと。一意にレコードを識別するためにある 外部キー：2つのデーブル間の列同士で設定するもの。参照
非機能要求グレードの研修教材と利用ガイド[活用編]を公開：IPA 独立行政法人 情報処理推進機構
非機能要求とは、情報システムにおけるセキュリティや性能、業務の手順などといったシステムの機能以外に関する要件で、システムの安定・安全な稼動のために必要な要件のことです。 金融や交通、水道、電力などをはじめとして、情報システムは国民生活や生命にかかわる社会性の高い分野で幅広く活用されており、その安定した稼動の確保は極めて重要です。また、情報システムの運用環境に対してもクラウドの普及や災害対策の必要性が再認識されている中で、情報システムがどのような環境下で利用されるかを想定して、非機能要求を適切に設定することが重要です。 そこでIPAでは、従来より普及を推進してきた非機能要求の定義手法である「非機能要求グレード」(*1)を活用したシステム構築をより一層推進し、システム障害低減につなげるための非機能要求の具体的な利用方法が体得でき、一般企業や民間のIT分野の研修機関等で自由に使える、演習付きの教
第3回 設計段階で性能を見積もろう
Webアプリケーションの画面を設計するとき、皆さんは性能について意識していますか。機能面の要望を取り込むことに集中するあまり、性能は二の次になっていないでしょうか。 あとになって性能が問題になるプログラムは、設計時に過ちを犯していることが少なくありません。そのような性能トラブルは、チューニングで簡単に解決しないことが多いものです。設計時に性能リスクを明らかにして早めの対策を打っておけば、致命的な性能トラブルの多くを防げます。 今回は設計段階で性能リスクを早期に発見するための性能見積もり手法について紹介します。設計段階で性能を作り込む手法には、多様なものがありますが、今回解説するのはその前段階として必要になるものです。どの機能に対して、工数をかけて性能を作り込むべきかを明らかするのが狙いです。 性能を見積もるメリットは二つ 設計段階では動作するプログラムが存在しないので、性能評価においては、
第13回 ［データモデル編］発注者が確認しやすいようにCRUD図をアレンジする
CRUD図を利用して発注者とレビューをされたご経験はありますか？ CRUD図というと一般的には以下のような図をイメージされるのではないでしょうか。 このCRUD図を使って，機能とデータの抜け・漏れや処理の集中，不完全な分割などがないかどうかを検証する「CRUD分析」で発注者に確認したいことが発生したときに，CRUD図をそのまま見せても，発注者はなかなか理解しずらいものです。 確認したい内容に絞り込んだ表を作成する そこでCRUD図をそのまま発注者に見せるのではなく，以下のようにアレンジしたCRUD図を作成してみましょう。 この図のポイントは以下の通りです。 ・申請書作成や承認といった処理のタイミングごとに，各エンティティの作成，参照，更新，削除があるかどうかを表した表形式にする。 ・確認したいエンティティとタイミングのみ記載する。 ・エンティティの数が多い場合は分類する。 ・作成，参照，更
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
