タグ

ブックマーク / yohei-y.blogspot.com (9)

  • yohei-y:weblog: 『Webを支える技術 ── HTTP、URI、HTML、そしてREST』という本を書きました

    このブログ、1年近くご無沙汰していました。その間なにをやっていたかというと、実はずっとを書いていました。『Webを支える技術 ── HTTP、URI、HTML、そしてREST』というなんとも挑戦的な題名のです。技術評論社さんのWEB+DB PRESS Plusシリーズの11冊目で、来月発売される予定です。 Webを支える技術 ── HTTP、URI、HTML、そしてREST山 陽平技術評論社 2010-04-08 このは、WEB+DB PRESSで連載していた「RESTレシピ」という連載がベースになっています。実は連載が1年経ったくらいから、技評さんからは書籍化のオファーをもらっていました。ただ、その時点では書いた分量も少ないし、そもそも自分に雑誌記事とは比べ物にならないくらい分量のあるが書けるとは思っていなかったので、書籍ではなく連載継続という形でトータル2年間連載をしました。

    hirose31
    hirose31 2010/03/04
    上梓おめでとうございますー!
  • yohei-y:weblog: CAPのCとACIDのC

    CAP 定理と BASE の概念を考えたのは UCB の Brewer 先生で、彼は inktomi の偉い人だったというのは前回述べた。 当時のinktomiはYahoo!Microsoft、それにgooにも検索エンジンを提供していて、1億以上のWebページ(テラバイト級のデータ)を扱っていたようだ。 手元のWEB+DB PRESS Vol.49 のはてなブックマークリニューアル記事によると、現在のはてなブックマークは1160万URLと100GBのHTMLデータ(圧縮済み)を扱っているらしいので、ざっくりいって98年の時点でinktomi は現在のはてブの10倍のデータを扱っていたといってもいい。inktomiで使っていたコンピュータの性能は現在のPCサ ーバに比べれば1/10程度の性能なので、システム全体でみると現在のはてブの100倍の規模になるだろうか。 結果的には、inktom

  • yohei-y:weblog: CAP と BASE について調べたこと

    時系列で 1990年代後半: Eric Brewer (UCB)が inktomi でいろいろ作る CAPとBASEの基礎ができる http://www.ccs.neu.edu/groups/IEEE/ind-acad/brewer/ 2000年7月19日: Eric Brewer が PODC (Principles of Distributed Computing) の基調講演で CAP 定理?と BASE を発表 CAP は Brewer 予測として知られるようになる この時点で、inktomiと同等スケールのWebサービスの問題に対処していた人はあまりいなかったのかもしれない 2002年 MIT の Seth Gilbert と Nancy Lynch が CAP を形式化 ここで Brewer の CAP が晴れて定理となった この間、よくわからず 2007年-: eBay の

    hirose31
    hirose31 2009/03/03
    つづく
  • yohei-y:weblog: RESTレシピ ―― クールなWebシステムへの道しるべ【最終回】リソースモデリング

    2年間 WEB+DB PRESS で連載してきましたが、今回ついに最終回となりました。 正直 REST ネタでこんなにも書くことがあるのかと今でも不思議です。 ほとんどコードが登場しないで文字ばかりという異色な連載を載せ続けてくれた編集部さんに感謝です。 あと毎回締切ギリギリになってすんませんでした。 ところで最終回のネタですが、連載を始める前からずっと書きたかったリソースモデリングについてやっと書くことができました。 まだまだ確立された手法とは言い難いですが、僕なりにまとめてみたものです。 みなさんの Web システムを RESTful にするお手伝いができればいいなと思っています。 ありがとうございました。 WEB+DB PRESS Vol.49WEB+DB PRESS編集部技術評論社 2009-02-24

    hirose31
    hirose31 2009/02/16
    おつかれさまでしたー
  • yohei-y:weblog: AtomPub が RFC 5023 に/日本語訳を公開します

    AtomPub がついに RFC になりました! RFC 5023 The Atom Publishing Protocol RFC 5023 The Atom Publishing Protocol(HTML) 関係者のブログ Joe Gregorio: RFC 5023 - The Atom Publishing Protocol Sam Ruby: <appdraft>no<app:draft> RFC になるまでずいぶんと長かったように感じますが、 その分完成度は上ったのだと思います。 interop もすでに何回も開催されており、その結果も良好です。 AtomPub は全ての、とはいかないまでも、多くの Web サービスのベースとなることが できるプロトコルです。 たとえば blog 、何らかのデータベース、画像/映像リポジトリ、 Wiki、カレンダー、ソーシャルブックマークなど

  • yohei-y:weblog: いろいろ改め AtomPub の話と、パターンの話と、消費電力の話と、古くて新しい開発環境の話と、Tim Bray のインタビューと、Dave Thomas のTシャツプレゼントが載ってる WEB+DB PRESS Vol.40

    WEB+DB PRESS の Vol. 40 が届きました。どうもありがとうございます。 僕は Atom API 改め AtomPP 改め APP 改め AtomPub/Atompub な Atom Publishing Protocol の解説を REST の連載で書きました。 記事のドラフトではずっと APP で通してきたのですが、 最後の最後で AtomPub に切り替えました。 いろいろ考えたんですが AtomPub で統一して呼んでいこうかと。 今回は 40号記念だからか、すごく充実した内容です。 パターンの特集はここまでまとまってるのは今までなかったし、 サーバの消費電力の話なんて、他にどこで読めるのかわからないような記事でした。 僕はどちらかというとソフトウェアの抽象レイヤをいつも考えているので、 たまにこういう物理的な話を読むととても勉強になります。 それにしても id:n

    hirose31
    hirose31 2007/08/21
    うほっ
  • yohei-y:weblog: APP の標準化作業がほぼ終了

    Tim Bray からアナウンスがあったとおり、 APP の標準化作業がほぼ終了しました。 RFC 番号が付くのはしばらく先だと思いますが、 現状の仕様を実装してもう問題ありません。 最後の draft-17 ベースの仕様が RFC になります。今後の修正は editorial なものだけのはずです。 この先、Web API を設計する人は、まず APP が利用できないか検討しましょう。 APP を採用すれば自然と REST スタイルを採用することになります。 これまで悩みがちだった Web API の設計が、かなり楽になると思います。 Web API を設計する人は、オレオレXMLを設計する前に、Atom/APP をベースにしたらどうなるか、 を考えて見ましょう。きっと Atom/APP は良い選択肢になってくれるはずです。 日では AtomPP で定着しつつあった Atom Publ

  • yohei-y:weblog: WEB+DB PRESS Vol. 38

    WEB+DB PRESS Vol. 38 で REST 周りのことについての連載を始めました。 ちょうど1年前に REST の解説を書いたんですが、 その直後に naoya さんが連載で、と書いてくれて それを見た技評の中の人が mixi で「連載しませんか」というメッセージくれたんだけど、 ちょっと1年続くネタに困りそうなのでやんわりと断ったのでした。 んで、1年後、技評の中の人がもう一度話を持ってきてくれて、 今年は APP もついに RFC になりそうだし、 連載してもいいかなーと思って連載することにしました。 ということで何が言いたいかというと、naoya さんの影響力と 技評の中の人の企画力はすごい、ということでした。 肝心の今回の内容ですが、円グラフで表現すると、こんなかんじです。

  • yohei-y:weblog: 良い URI の設計

    URI は綺麗であるべき、と常々思っているんですが、よいページを発見しました。 Michael Eakes のこのエントリです。 Tanya Rabourn がリストアップしている文献一覧からエッセンスをまとめてくれています。 曰く、よく設計された URI とは 変らない(don't change) 人間が推測可能(are human guessable) 論理的(ファイルシステムを反映する必用がない) (are logical (no need to mirror a filesystem)) サイト構造をビジュアライズするのに役立つ(help visualize the site structure) 短い(are short) 小文字を使う(use lowercase) 予期されない記号を使わない(don't use unexpected punctuation) 問合せパラメータな

    hirose31
    hirose31 2006/09/29
    よいURL
  • 1