HTTPの仕様書に「副作用」の定義がないのは不親切じゃね？ - 岩本隆史の日記帳（アーカイブ）
『Webを支える技術』の101ページに、こう書かれています。 リソースの状態に変化を与えることを副作用（Side Effect）と言います 僕の読み落としでなければ、この定義の出典は同書には明記されていません。ただ、HTTPメソッドの冪等性や安全性を解説する文脈で紹介されているので、HTTP/1.1の仕様書であるRFC 2616が出典なのだろうと思います。 RFC 2616の本文には、「副作用」（side-effects あるいは side effects）という言葉が9回出てきます。最初に出てくるのは「9.1.1 Safe Methods」においてです。橋本英彦さんによる日本語訳を引用します（強調は岩本、以下同じ）。 本質的に、サーバが GET リクエストを実行した結果として副作用を起こさないという事を保証するのは不可能であり、事実、いくつかの動的なリソースはそれが特徴であると考えている
Haskell初心者の僕が試したことをまとめてみた - 岩本隆史の日記帳（アーカイブ）
なぜHaskellに興味をもったのか 僕がHaskellに興味をもったきっかけは、『まつもとゆきひろ コードの世界?スーパー・プログラマになる14の思考法』（通称「ホスト本」）でした。 ホスト本の第14章「関数型プログラミングについてなど」では、関数型プログラミングの特徴が4つ挙げられています。 関数そのものをデータとして捉える（ファーストクラス関数） 関数を引数として取る高階関数 同じ引数を取る関数は同じ結果となる参照透明性 参照透明性を実現するための副作用の忌避 このうち「参照透明性」が特に興味深く感じました。「同じ引数を取る関数は同じ結果となる」のですから、きっとテストが書きやすいはずです。「状態」によって結果が変わるオブジェクト指向言語ではテストが書きづらいと日頃から思っていたので、この参照透明性は福音のように感じられました。 その「参照透明性を実現するための副作用の忌避」が徹底さ
続・こんなURI 設計、どう？ - 岩本隆史の日記帳（アーカイブ）
先日書いた「こんなURI 設計、どう？」の続きです。 例：商品ブックマークサービス URI設計の例として、商品ブックマークサービスを対象に考えてみます。提供するおもなリソースは、以下の5つです。 リソース名 パンくずリストのイメージ トップレベルリソース トップ ユーザ登録画面リソース トップ＞ユーザ登録 ユーザ別ブックマークリソース トップ＞iwamotのブックマーク ブックマークリソース トップ＞iwamotのブックマーク＞Webを支える技術 商品リソース トップ＞Webを支える技術 うち商品リソースについては、はてなブックマークのエントリページ（例：http://b.hatena.ne.jp/entry/twitter.com/）みたいなものとお考えください。商品ブックマークサービスでは、entry以下のURI断片の代わりに、Amazonの商品コード（ASIN）を用いることにします。
こんなURI設計、どう？ - 岩本隆史の日記帳（アーカイブ）
先日書いたように、作りたいWebサービスがあります。当然ながら、まずは設計から始めなければなりません。 設計にあたっては『Webを支える技術』の第15章で紹介されているサービス設計手法を用いることに決めたのですが、URI設計のステップで、はたと考え込んでしまいました。 以下、第15章に掲載されているURI例で違和感の原因を探ってみます。 郵便番号リソースのURI http://zip.ricollab.jp/1120002これは違和感ありません。 検索結果リソースのURI http://zip.ricollab.jp/search?q=小石川ここで若干の違和感を覚えます。郵便番号データのキーである「1120002」と「search」が同列に並んでいるのが原因です。 いや、とくに気にする必要はないのかもしれません。「search」という郵便番号は今後も現れないでしょう。もし現れたとしても、ク
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
