suicaは実はたまに落ちている - 紅茶屋くいっぱのあれこれ日記
suicaのサーバーはみんなの知らないところで、実はたまに落ちているそうだ。 だがシステムが止まることはない、計算上センターは3日ぐらいは止まっていても大丈夫だそうだ。 だからサーバーが落ちたなどとニュース沙汰になることは殆ど無い。 suica開発陣頭指揮をされていたかたが、その実績をまとめてと頼まれ、博士論文にしたそうだ。 suicaの実例を述べるだけだと技術論文になってしまうので、一般化して論文を書きあげたそうなのだが、審査に携わった専門家の人達はそんなものが動くわけないだろうといったらしい。しかし現実問題としてsuicaは動いてしまっている。 本人いわく、だってそれで動いちゃってるんだもん。だそうだ。 実装は時として奇妙に見えるかもしれない。 フィールドには神がいる。 …その意や、なんで落ちても大丈夫かなどはまた後ほど。 スイカのセミナー 昨日はスイカのセミナーだった。 JR東でスイ
テーブル設計 データモデリングのエッセンス（２） | システム設計日記
テーブルのタイプ データベースに記録する情報の性格から、テーブルを三つのタイプに分類する。 ・ビジネスイベント：受注、出荷 ・ビジネスリソース：商品、顧客、店舗 ・ビジネスルール：価格表、手数料、 これは、Eric Evans の Domain-Driven Design (DDD) の Responsibility Layers の考え方と同じです。 今回は、ビジネスイベント系のテーブルの設計原則をとりあげる。 ビジネスイベントの記録 受注や出荷は、ビジネスイベントが発生した時点の記録です。このタイプのテーブル（情報）は、過去の事実の記録ですから、一度作成（インサート）したら、後から、更新や削除はしない。このテーブルに許される操作は、インサートと参照のみにする。 受注取消は、受注取消テーブルに記録する。受注テーブルに論理削除フラグを作って更新したり、受注テーブルの物理削除はしない。過去の
2007年7月20日を持ちまして社名変更致しました。
2007年7月20日を持ちまして社名変更致しました。 また、この社名変更に伴い、弊社ホームページのURLも以下の通り変更致しました。 http://www.robotics-e.co.jp 10秒後に自動で新サイトへ移動します。 もし移動しない場合は、恐れ入りますが上のURLより移動をお願い致します。
『ドメインモデルに対する日米の温度差』
マーチン・ファウラー氏によれば、アプリケーションの中核部であるビジネスロジックを構築する方法には、Transaction ScriptパターンとDomain Modelパターンの2通りがあるという。Domain Modelパターンは、データと振る舞いを1つのオブジェクトにまとめ、オブジェクト指向のテクニックを駆使するやり方だ。一方のTransaction Scriptパターンでは、データと振る舞いは別々のオブジェクトに分け、振る舞いをスクリプト的に淡々とプログラミングしていく。 日本ではTransaction Scriptが優勢 この2通りのうち、日本ではTransaction Scriptパターンの方が優勢だ。日本のオピニオンリーダーも軒並みTransaction Scriptを薦めている。 たとえば、Seasarの開発者であるひがやすを氏は、古くからデータと振る舞いを分離するアプローチ
第36回 画面設計書を書くための手法とツール：ITpro
画面設計書について，前回に引き続き，それを書くツールや手法について考えてみましょう。 画面設計書の基本 まずは，画面設計書の中にあるべき情報から見てみましょう。これらすべてがそろっていなければならない，というわけではありませんが，望ましいのではないかと私自身は考えています。 header ページIDやタイトルなど，一目でそのページがどの画面仕様を記述しているかがわかるような「ヘッダー」部分。細かく書くならば，文字コードや対象ブラウザまで記述する場合もある。また，プロジェクトの名前（プロジェクト・コード）や版番号なども記し，似たようなドキュメントの中からも引き出せるようにしておく。 footer 制作サイドのコピーライトやページ番号などを記す。最終的には，クライアントのコピーライトに置き直して，最終納品とする場合もある。 Page Layout 画面内に配置する「ユーザー・インタフェース（U
システム設計 設計の考え方
要件定義、基本設計、詳細設計、プログラム設計、テスト、運用というシステム構築の手順が一般的に浸透しているが、このプロセスは 実践ではほとんど守られておらず、要件定義の中で、ユーザと一緒に一部分を掘り下げて行っているうちに混合されることが多い。 ここではその区別について考える。ただし、実践手順が多少、イレギュラーに設計されるのは全体の合理化を促進しようとするためであり、必ずしも良くないこととは言い切れない。 基本的には必要とされるアクターを考えることが重要だと思われる。 外部設計（システム設計） ＝システム方式設計+ソフトウェア設計 内部設計 ＝コンポーネント設計 詳細設計 ＝プログラム設計 （IPA） １．システム方式の決定：アーキテクチャーとして、H/
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
higaさんによるダイコン時代の設計方法 - tpircs