アプリケーションプロトコル設計のベストプラクティス (over TCP) - kazuhoのメモ置き場
みたいなものを誰かまとめてないのかな、と思ってる。ないのかな。とりあえず自分用メモ。 概要 接続後最初の電文は client => server であるべき 理由: syn_cookies, dataready, パケット数削減 (w. SYN ACK) 最初の電文は、プロトコルの magic で始めるべき 理由: gopher://host:25/ attack バージョン番号も含めるべき 何がコンパチで何が非互換か、最初からバージョン番号の解釈を明確にしておくこと 例: HTTP extensibleな構造化の手法は３種類 デリミタ方式 TLV ASN.1 PER デリミタ方式 テキストプロトコル系で一般的。ペイロード内にデリミタが出現する場合はエスケープ。 問題は遅いこと メタ情報のみデリミタでコンテンツは length というモデルも (HTTP) デリミタの定義をはっきりさせるこ
Webサービスの設計：Webの状態遷移図の描き方 - 檜山正幸のキマイラ飼育記 (はてなBlog)
前置きも書いたことだし、実質的な話を進めましょう。 以前の2つの記事をザッと読んでおいて欲しいのですが、ホントに大事なところはこのエントリー内でも繰り返します。 Webサービスを設計するための単純明快な方法 Webサービスの設計： ハイパーオブジェクトとトリガー 内容： 画面遷移とはクライアント側の状態遷移のこと アクションが起動して結果を返すまで ハイパーオブジェクトとしての状態 アクションノードの内部構造 リクエスト辺と内部辺の切断 ログイン処理の例 状態遷移をモジュールにする 状態遷移モジュールの意義 画面遷移とはクライアント側の状態遷移のこと ここで状態遷移と呼ぶのは、Webクライアント（典型的な例はブラウザ）の状態遷移のことです。サーバー側の状態（リソース状態）は、今は考えないので注意してください。クライアント側の状態をアプリケーション状態と呼ぶこともあります（あんまり適切な用語
サロゲートキーは強制されるべきものではない - 設計者の発言
複合主キーに代えてサロゲートキー（単独主キーの代替キー）を導入すべきかどうか。それはDB設計上の重要な判断事項である。なにしろレコードのアイデンティティである主キーの設定にかかわる問題だ。さまざまなメリットやデメリットを考慮してそれは判断される。その結果、サロゲートキーを導入することもあるし、しないこともある。 ところが、サロゲートキーを強制する（あるいはサロゲートキーを導入しないと開発しにくい）開発基盤がいくつか存在する。具体的には、全テーブルの識別子が"ID"等のフィールド名を持つ単独主キーであることが求められたりする。私に言わせれば、そういう開発基盤は「大盛を強制する牛丼屋」である。メニューにあるはずの「並」を頼むと、あれこれイヤガラセをされる牛丼屋。 この問題に関連して、「サロゲートキーを使わなかったから、ひどい目にあった」という開発者の声を聞いたことがあるかもしれない。心配はいら
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
