メンバページ: tsu

tsu -- life with programming: イベント参加報告

イベントの参加報告です。参加したイベントの中から、このイベントだけはレポートを書いておかなきゃ、と思ったものについて、レポートを書いていこうと思っています。

2006年11月24日に開催された「第九回XML開発者の日」に参加しました。

以下のような講演が行なわれました。

  1. 開会挨拶
  2. 現実的なRESTの実践
  3. Ruby on Rails にみる RESTful アプリケーションの方向性
  4. カレンダーアプリへの GData 実装
  5. Plagger: the duct tape of the Web
  6. ODF と OOXML の標準化戦争
  7. microformats に触れてみよう
  8. Syndy Chronicle
  9. ブログエディタへの Microformats の実装
  10. まとめ

以下、各講演について、当日ノートにメモった内容を元に、レポートを書いてみます。 間違いを見つけた方はご指摘ください。

なお、このレポートは、あくまでも私(tsu)個人のレポートであり、当社(株式会社 OKIソフトウェア)の見解を示すものではありません。その点、よろしくお願いします。

(1) 開会挨拶

国際大学の村田真氏によるあいさつ。 「第八回XML開発者の日」のテーマ REST を受けて、さらに議論を深める。 今回のテーマは microformats。

(2) 現実的なRESTの実践

REST といったらこの人、という感のある山本陽平氏による講演。

  • WebサービスとWebアプリケーションを分ける必要はない
  • クールURI重要、フレームワーク重要、データ重要
  • クールURI → 変わらないURI
    • 変えない
    • 変えにくくする
      • 実装依存の URI (.pl とか .php とか .jsp とか .aspx とか .cgi とか) は使わない
      • リソースは「名詞」。action を URI に含めないようにしよう
      • セッションID が URI に含まれるのはもってのほか
      • いまどきのフレームワークを使う(ことで、自動的にクールURIになることが期待できる)
      • サービスごとに URI を分けない[同一ドメイン内の全サービスに関して、URI の生成規則を統一する]
        (どのサービスでもリソースの取得はリソース名に対する GET にする、リソースの登録はリソース名に対する POST にする、など)
    • 変わった場合は(旧URIへのアクセスは新URIへ)リダイレクト
    • あきらめる
  • URI はクライアント不透明
    ユーザに URI を推測させて、ブラウザのアドレス欄に打ち込ませて(もしくはアドレス欄に表示されているURIをいじらせて)アクセスさせるような UI は最悪
  • URI テンプレート
    元々はオープンサーチ由来。自分たちのアプリケーションでも使おう!
  • Web API
    • URI はプログラムからもアクセス可能なリソース
    • 悪い実装例: はてなブックマーク件数取得API
      • XML-RPC API を使っている
      • ブックマークができない
      • おそらく、パラメータが多いせいで、GET (で送信できるクエリストリングはサーバにもよるが、概ね256バイト) ではなく XML-RPC API (POST) を使うようにしたのではないか?
      • REST でも、クエリストリングを(GET ではなく) POST で投げるようにすることで実現可能
    • よい実装例: はてなブックマークの件数を画像で取得するAPI
      • シンプル、使いやすい
      • ブックマークができる → REST 的に正しいリソース
      • キャッシュできる (キャッシュは必ずしもしなくてもよいが、キャッシュできるところはキャッシュする)
  • 設計のヒント
    • リソースオリエンテッドな考え方
    • そのリソースに適した表現を考える
      • 決定的なものはない
      • 経験やセンスがものをいう
      • デファクト重要
      • 既存のいい API の真似をする
      • 例えば、GData や はてな のAPI (GData は純粋な REST ではないけど)
  • 最新動向
    • REST 本が、オライリーから 2007年5月頃に出るらしい?
    • SOA への対抗として ROA という表現を考えてみた
    • ROA: Resource Oriented Architecture
    • REST はアーキテクチャスタイルだったが、ROA はアーキテクチャ (ただし、ROA は buzzword)
  • REST vs WS-*
    • REST
      • シンプル
      • 統一インターフェース
    • WS-*
      • 大企業の思惑
      • 個別インターフェース
      • 複雑
  • エラーは microformats で
  • REST なサービスがどんどん増えている
  • ますます、データ重要
  • 「データを Web に解き放て」
  • おまけ
    • リソースと URI は 1対1 とは限らない。1対n の場合もある
      例えば、「天気予報」の場合
      • 今日の天気 (GET /weather/today)
      • 最新の天気 (GET /weather/now)
      は、リソースは同じ(現時点の天気)だが URI は異なる

(3) Ruby on Rails にみる RESTful アプリケーションの方向性

東芝ソリューション株式会社の川村徹氏による講演。

  • REST だと何がうれしいのか?
    • REST は Web のあるべきアーキテクチャスタイル
    • ステートレス → スケーラビリティの向上が容易
    • リソース指向
    • クッキーによるセッション管理は駄目 → しかし、世の中は personalized Web の時代
      • ユーザごとに違うレスポンス(画面)を返す → REST のメリットが生かせない
    • HTTP GET をもっと活用しよう
    • 統一インターフェース
    • シンプル、一貫性がある
    • リソースの操作は CRUD の4種類に制約
  • RESTful フレームワークとしての Rails
    • Ruby on Rails を使うことで、クールURIが可能になる
      • http://ほげほげ/コントローラ/アクション/id
      • 今までの Rails ではリソースが動詞 → 間違っていた!! → 次の Rails では、リソースが「コントローラ」(名詞)になる
      • とはいっても次期 Ruby on Rails にも例外的な URI がある
    • コンテントネゴシエーション
      • 単一 URI に複数の表現を割り当てる
      • GET /product/1
        httpリクエストヘッダの Content-Type に応じて、違うレスポンスが返る
        同一の URI で異なる API へのリクエストを表現可能
      • GET /product/1.xml
        という表記も可能。この場合、「XML形式で応答を GET したい」という意味になる
  • REST on Rails の例
    • ウィザード1
      次に遷移する画面に関する情報を「http レスポンスヘッダ(Location:)」に埋め込んでおく
      • ○ REST 的
      • × ブラウザの「戻る」ボタンが使えない
      • × 途中でブラウザを終了させてしまうと、二度と状態を復帰させることができない → ブラウザ側に状態を残す方法があれば復帰可能 (Dojo を使う?)
    • ウィザード2
      次に遷移する画面に関する情報を「hiddenパラメータ」に埋め込んでおく
      • ○ ブラウザの「戻る」ボタンが使える
      • ○ 途中でブラウザを終了させても、復帰可能
      • × パラメータが複雑になる
    • ウィザード3
      セッションを使う
      • × REST 的ではなくなる
      • × ブラウザの「戻る」ボタンが使えない
      • ○ 途中でブラウザを終了させても、復帰可能
  • おまけ
    • Ruby 以外の言語でも Rails のような方向性をもった REST 指向のフレームワークが出てきて欲しい
    • CSRF の問題は、今のところ Rails 本体では未対策のため、アプリケーションの方で対策する必要がある。CSRF 対策用のプラグインがあるらしい

(4) カレンダーアプリへの GData 実装

xfy CommunityMasa氏Tak氏による講演。

  • ジャストシステムの xfy 上で動くアプリケーションの例
  • xfy は、XML復号文書編集環境として登場したが、今では XML アプリケーション実行環境としても使われている
  • xfy は、マッシュアッププラットフォーム
  • Java プラグインあるいは XVCD スクリプトの形でアプリケーションを作成したり、既存のアプリケーションの機能拡張を記述したりする
  • XVCD は XSLT をベースにいろんな機能を拡張したもの(なので、ファイルの中身は XML 文書ファイル)で、例えばブログエディタを記述したりすることができる
  • RDF Calendar
    • ローカルPC上で動作
    • Google Calendar にも対応 (GET で取得、POST で登録)
    • GET 側は、magiccookie による認証後、userID + magiccookie を使って Atom PP で検索条件を指定してデータを取得
    • POST 側は Client Login API で認証後、userID + password + AuthToken を使って、データ(Atom形式)を POST
    • GData API はまだバグが残っている、エラーメッセージの意味がわかりにくい、など、苦労が耐えない
  • hCalendar in feeds
    • RSS/Atom フィード中に含まれる hCalendar 形式のデータを抽出して、カレンダー形式で表示するアプリケーション
    • 表示中のデータを Google Calendar に登録可能
    • データの編集機能はまだ開発途中

参考

(5) Plagger: the duct tape of the Web

Plagger の作者、miyagawa さんskypeBreeze 経由でサンフランシスコから参加(講演)

  • 今まで、いろんなところから html を拾ってきて、解析して、欲しい情報を出力するプログラムをたくさん書いてきた
  • 自分だけではなく、他にも同じようなことをしている人は大勢いる
  • いろんなスクリプトを書いていると、よく似た処理がどんどん出現

    ↓
  Plaggerの誕生

Plagger とは

  • UNIX のパイプのようなイメージ
  • RSS(や Atom) はインターネットの標準入出力であり、RSS を読み込んで RSS を出力するツールはパイプに相当する
    → Plagger は UNIX のシェルに相当?
  • Plagger の入力と出力の組み合わせは 35 × 37 = 1295 通り
  • Plagger は接着剤
  • フォーマットにとらわれず(RSS や Atom に限定しない)、何でも処理してしまおう! → フォーマットの差異を吸収したり、取り扱い方法を共通化したりする API を作ってしまえば、あとは簡単、つなぐだけ

(6) ODF と OOXML の標準化戦争

国際大学の村田真氏による講演。

  • ODF
    • Open Data Format
    • OpenOffice.org の文書フォーマット(Open Office XML)が元
    • Sun が仕様を決めて、OASIS で標準化。ISO に提出(まだ規格にはなっていないが、規格になることは決まっている)
    • 技術的には問題が多い(URI と IRI の問題など)が、文書フォーマットが一私企業のものではなくなるという観点から、各国が賛成
  • ODF
    • Office Open XML
    • Office 2007 の文書フォーマット
    • Microsoft が仕様を決めて、ECMA に提出。おそらく、ECMA で標準化されたあと、ISO に提出されるものと思われる
    • ODF だと、Microsoft Office の文書情報を完全に保存することができない(欠落する情報が発生する)ので、OOXML を作った

OASIS → ISO という経路での標準化

  • PAS
  • ISO 以外の標準化団体の規格を ISO 規格にするための手続き
  • OASIS で標準化された規格は、この経路を使って ISO 規格にする

ECMA → ISO という経路での標準化

  • Fast-track Procedure
  • 通常は、国が提出した規格案しかこの経路では流せないが、ECMA は特別にこの経路を使う権利を持っている
  • ECMA での標準化の敷居は低いので、ECMA でいったん標準化しておいて、ISO に提出、というのが増えている

参考

(7) microformats に触れてみよう

シックスアパートの上之郷谷氏による講演。自分の名前をネタにどんどん話題を膨らませていくところは面白かったです。

  • とにかく microformats を使ってみよう
  • XFN, hCard, hCalendar, などなど

プレゼンテーションがスタイリスティックで、さすがデザイナーの人は違う、と思いました。 CSS Nite も機会があったら、参加してみたいです。

(8) Syndy Chronicle

ジャストシステムの山口琢氏による講演。

  • マシン処理可能な「年表」
  • 今のところ、1970年以降しか扱えない(ので、歴史年表を扱えない)
  • Web 上から hCalendar 形式のデータを集めてきて、年表を作る
  • 複数の年表を合成して眺めて楽しむ
  • ○○というできごとと△△というできごとが同じ頃にあったことがわかる
  • 未来の予定も扱える
  • 実は hResume (イベントレポートとか)も扱える
  • XVCD で記述された xfy アプリケーション
  • オープンソース

Syndy Chronicle といい RDF Calendar といい、なぜか xfy 絡みのアプリケーションはカレンダー関連のアプリケーションが多いようです。私も個人的に、カレンダーアプリケーションには興味を持っているので、そのうち、何か作って発表することがあるかもしれません(ないかもしれません)。

(9) ブログエディタへの Microformats の実装

フィードパス株式会社の後藤康成氏と室田直匡氏による講演。

  • feedpath はフィードリーダ。ブログに投稿する機能もある。ソーシャルタギング機能内蔵
  • ユーザ数 12000人超、13万チャネル、3000万アイテム、10万タグ
  • 13万チャネルを30分で巡回できる性能
  • ブログエディタ機能
    • API のあるブログは API 経由で投稿
    • API のないブログは仮想的なAPIを用意して、その仮想API経由で投稿
      • 仮想APIを汎用的に記述する方法はまだ用意されていない
      • 各ブログの管理画面の html や画面遷移を自力で解析して、力ずくで仮想APIを書いている
      • 実は API のあるブログでも、レスポンスが独特だったり、独自処理が必要な場面があったりする
      • 例えば、アメーバブログの Atom API には苦労した
    • microformats 埋め込み機能
      • hReview (読んだ本の感想、など)
      • hCalendar
      • 地図情報 (GeoCoding.jp の形式を利用) [+ Google Maps API とマッシュアップ]
    • simpleAPI の(指定URIの)サムネール取得機能も利用している
    • ブログに投稿失敗しても、feedapth のデータベースに記事が残るので、後日再投稿を試みることが可能
    • Amazon Web Services を利用した、商品情報取得画面 (はてなダイアリーの「はまぞう」に似た感じの画面)
    • 将来は、hCard とかにも対応したい / rel 属性を使った microformats の採用も検討中

(10) まとめ

次回のテーマは「認証」でいくというのが有力みたいですね。今回は、「認証」関連の質問がいくつか出たものの、回答の方はずばりこれという決め手にかけていました。「認証」回りのあれこれは、今後の課題だと思われます。Google の GData API が1つの解決例でもありますが、他にもっといい解決策があるのではないか、という気もしますし。まだまだ研究の余地がありまくりだと思います。


関連リンク

目次

Tech・Ed 2008 Yokohama で発表したプレゼン資料を公開します
Tech・Ed 2008 Yokohama のライトニングトーク(3日目)で使ったプレゼン資料を公開します。 IEコンポーネントで AutoPagerize IEコンポーネントで AutoPagerize (PDF形式, 259 KB [265,709 バイト])...
Tech・Ed 2008 Yokohama
Tech・Ed 2008 Yokohama の参加レポートです。ライトニングトークでしゃべってきました。
WASForum Conference 2008 (2日目)
2008年7月5日に開催された「WASForum Conference 2008」(2日目)の参加レポートです。普段あんまり聞けない話が聞けて面白かったです。
Google Developer Day 2008
今年も Google Developer Day に参加してきました。実際に動いている Android を見ることができたのが最大の収穫ですね。
VSUG DAY 2008 Summer
昨年末の VSUG DAY 2007 Winter がまだ昨日のできごとのような感じがする中、VSUG DAY 2008 Summer に参加してきました。
第10回XML開発者の日
「第九回XML開発者の日」に続き、「第十回XML開発者の日」にも参加しました。
VSUG DAY 2007 Winter
VSUG DAY 2007 Winter の参加レポートです。Visual Studio 2008 の話が聞きたくて、参加しました。
VSUG DAY 2007 Summer
去年の VSUG DAY 2006 Winter に続き、2007年6月1日開催の VSUG DAY 2007 Summer にも参加してきました。Orcas が目玉の話題かと思いきや、どちらかというと Silverlight の話題の方が多かったです。
Google Developer Day 2007
Google Developer Day 2007 の東京会場開催分に参加してきました。Google Gears の発表をいち早く見ることができたのはよかったかも。
VSUG DAY 2006 Winter
2006年11月25日に開催された「VSUG DAY 2006 Winter」というイベントに参加してきました。the Microsoft Conference 2006 と一部内容がかぶってましたが、おもしろい話もちらほら。

過去記事一覧


Copyright (c) 2006, 2007, 2008 OKI Software Co., Ltd.