要件におけるユーザーストーリーの利点 - winplusの日記
これの続きというか、Mike CohnのProject Advantages of User Stories as Requirementsを適当訳しておく。たんにまだ『User Stories Applied: For Agile Software Development』に手を出しかねているのだけなのだが。 ■要件におけるユーザーストーリーの利点 エクストリームプログラミング(XP)は、ユーザーストーリーの形式で要求を表現するというプラクティスを導入します。ユーザーストーリーは利用者の視点から語られた機能要件の短い説明です。機能要件とはソフトウェアの利用者あるいはソフトウェアの顧客のどちらかにとって価値があるものです。人材募集・検索サイトのための典型的なユーザーストーリーをあげましょう。 利用者は自身の履歴書をウェブサイトに掲示できます。 利用者は仕事を検索できます。 企業は新しい求人
Why using REST will kill your project - winplusの日記
タイトルに釣られて、Rant 3000: Why using REST will kill your projectを適当に翻訳しました。 RESTはおもしろい。でも、おもしろいものはたいてい、あなたを死なせることができます。まず最初に、RESTが何であるかを知らないのなら（恥ずかしいことではありません、というのも私はRESTが現われてから数年間、流行にとり残されていました）wikipediaの記事を見てください。RESTはクールなアイデアのように見えました。そして、私はRESTに従っていくつかのAPIを設計しました。しかしながら、RESTにはダークサイドがあったのです。それは致命的な場合があり、死なせることができて、たいていの場合、死なせてしまいました。大きなプロジェクトでも小さなプロジェクトでも。ここでは実際の例を使いますが、会社あるいは関係者の名前はふせておきます。 いまどきの２つの
UIとしてのリソース - winplusの日記
id:yoheiさんの『Webを支える技術 -HTTP、URI、HTML、そしてREST』の発売記念トークセッションをustで鑑賞。いろいろ面白かったんだけど、いちばん「なるほど」と思った点をひとつだけ。 これまで「ユーザインターフェイスとしてのURIを設計するということ」を、読み取り可能なURI（いわゆるキレイなURI）をつくることだと理解していた。（CRUD型RESTの欠点と、読み取り可能なURI - winplusの日記）昨日の中継をみて、やっとそれが誤解であることに気づいた。 ただ一つだけ調子が異なった章になっているという「第17章 リソースの設計」。id:t-wadaさんいわく『RESTful Web サービス』にはリソースの見つけ方が書かれていないという致命的な欠点があって、id:yoheiさんがそれを誰でも出来るようにメソッド化した章らしい。で、id:yoheiさんは、リソー
CRUD型RESTの欠点と、読み取り可能なURI - winplusの日記
「CRUD型RESTの欠点」として挙げられている以下の点。 外部に見せているのは内部的なデータベース構造ないしデータであって、考え抜かれた契約ではありません。 本当のサービスを迂回して直接データにアクセスすることを助長します。 CRUDはRESTにとって良くないのか？ テーブルを知らないとSQLは使えない訳で、それをそのままマッピングするのはテーブルを公開しているのと同じ。これを利用するには、クライアント側が、すべてのビジネスロジックを把握する必要がある。 羊の皮をかぶったクライアント−サーバでしかありません。 CRUDはRESTにとって良くないのか？ 確かにね。 ちゃんとしたRESTfulなWebサービスであれば、クライアント側は一切のビジネスロジックを把握する必要がなくなると。そうであれば、必要かつ十分なWebサービスは、すべてハイパーリンクで提供される。つまり、クライアントがハイパー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
