本を読む

読書やコンピュータなどに関するメモ

「宗像教授異考録」第12集

 古代史探検マンガ(?)の新作。海にまつわる「七人みさき」、山にまつわる「生と死の女神」「神の背中」の3編を収録。

 元ネタリストは、ネタバレなので「続きを読む」で。

続きを読む »

「新クロサギ」5巻

 「有名人詐欺」、「入札詐欺」、「環境開発詐欺」を収録。今回の手口は、ネタバレなので「続きを読む」で。

続きを読む »

「宇宙兄弟」8巻

宇宙兄弟 8 (モーニングKC)
小山 宙哉
講談社
そーいえば大事なこと言い忘れてたわ

 ついに選抜試験の結果発表! あいかわらず、ちょっとしたエピソードがうまいなぁ。バンソーコーとか公園とか、トイレのメールとか。

 で、後半、一転して緊迫の展開に。

めんどくせー場所だな
ここは

「ディアスポリス」15巻

ディアスポリス-異邦警察 15 (モーニングKC)
すぎむら しんいち リチャード・ウー
講談社
達者でな
これでお別れだ

 新宿を舞台にアジアの闇を描く物語も、これで最終巻。きれいにまとまったような、きれいにまとまりすぎたような気もするけど、全15巻面白かった。ラストシーンは、いい意味で様式美。

「Software Design」2010年1月号

 Endian Firewall UTMの紹介記事が載っててびっくり。ちょっと欲しくなった。

bash 4.1はヒストリーをsyslogにも記録する

 bash 4.1はヒストリーをsyslogにも記録する、という話をBash Hackers Wikiで見たので、試してみました。現在、bash 4.1はRC1のようです。

ソースを見てみる

 bash 4.1 RC1のソースをダウンロードします。

 手動で設定するconfig-top.hファイルを見てみます。

/* Define if you want each line saved to the history list in bashhist.c:
   bash_add_history() to be sent to syslog(). */
#define SYSLOG_HISTORY
#if defined (SYSLOG_HISTORY)
#  define SYSLOG_FACILITY LOG_USER
#  define SYSLOG_LEVEL LOG_INFO
#endif

 デフォルトでSYSLOG_HISTORYが定義されて有効になっていること、facilityがLOG_USERであること、levelがLOG_INFOであることがわかります。

 ちなみに、bashhist.cの該当箇所を見ると、コマンドや変数などでの制御はなく、ビルド時の設定で一律に有効無効が決まるようです。

試してみる

 とりあえず手元にあったDebian lenny環境でビルドして動かしてみます。

$ sudo apt-get build-dep bash
$ ./configure
$ make
$ ./bash

 このbash 4.1上で適当にコマンドを打ってから、/var/log/user.logを見てみます。

Dec 25 10:45:24 debiantest1 bash: HISTORY: PID=19211 UID=1000 ls
Dec 25 10:45:38 debiantest1 bash: HISTORY: PID=19211 UID=1000 ls
Dec 25 10:45:46 debiantest1 bash: HISTORY: PID=19211 UID=1000 echo hello, work
Dec 25 10:45:55 debiantest1 bash: HISTORY: PID=19211 UID=1000 cat config-top.h

 ばっちり記録されています。

用途と問題点

 なんでこんな機能が付いているかというと、Changelogによると:

Feature requested by many, and required by some national laws

 法令遵守ってやつでしょうか。なにそれこわい。

 ディストリビューションで採用するときにはさすがにオフにするだろうと思うのですが、自分でビルドしてマルチユーザー環境で使うときには注意が必要ですね。特に、wgetとかでコマンドラインでパスワードを指定するときとか。

「害虫の誕生」

害虫の誕生―虫からみた日本史 (ちくま新書)
瀬戸口 明久
筑摩書房
売り上げランキング: 17025

 本書によると、国語辞典が「害虫」という項目を載せるようになったのは、20世紀以降だとか。それまでは、農作物の虫害は天災の一種と考えてられていたという。

 それが、文明開化にともなう「上からの強制」によって害虫駆除や衛生化が進められて、「文明的」な町が作られていったというのが、本書による日本の害虫の歴史だ。ちょうど、上からの強制によって文明国となった明治期の日本のように。ただし、著者は単純な「近代化や自然改造は悪」という考えにも与しない。

 という観念的な面もありつつ、それ以上に、洋の東西を問わず、人間が害虫に悩まされてきた歴史や、その研究の歴史、駆除技術の歴史などが紹介されていて興味深い。19世紀まではハエはむしろ「小さくてかわいい動物」とされていた、というトリビアもあったり。

 ちなみに、本書のオビには「なぜゴキブリは嫌われるのか?」とあるが、ゴキブリが出てくるのは序文のみ。おそらく、現代でわかりやすい害虫ということでピックアップされたのだろう。

 以下は、本書を読まないとわからないだろう個人用メモ。

  • 国語辞典が「害虫」という項目を載せはじめるのは20世紀以降
  • 「蝗」:虫害全般を指す
  • 江戸時代
    • 虫油駆除法
    • 虫送り(祈祷)
  • 虫害は人間の力の及ぶものではなく、天災と考える自然観
  • 虫の自然発生説(日本でも西洋でも)
  • 欧米
  • 中世:動物裁判
  • 農業が学問となったのは19世紀ドイツ
    • それでも害虫を扱う学問はない
  • 応用昆虫学:19世紀後半のアメリカ
  • ハッチ法(1887年)
    • 州立農事試験場
  • 害虫防御技術の技術革新
    • 化学殺虫剤:パリス・グリーン、砒酸鉛
    • 天敵導入:ベダリアテントウ
  • 明治日本政府
  • 自然の管理
    • 虫害の「発見」
  • 農学研究体制
    • 内務省勧農局
    • 駒場農学校(現在の東大農学部)
    • 札幌農学校
    • 国立農事試験場
  • サーベル農政
    • 警察の取り締まりによって農業の近代化を実行
    • 反発
    • 筑後稲株騒動
    • 上からの文明開化、公益
  • 名和靖、名和昆虫研究所
    • 昆虫思想の啓蒙
    • 「昆虫に益と害あり。国家の経済に関すること頗る大なり。益虫助くべく害虫除かざるべからず」
  • 明治に日本を訪れた外国人は、蚤やシラミ、蚊の多さに悩まされた
  • 熱帯医学の成立(19世紀末)
    • パトリック・マンソン、象皮病患者の血を吸った蚊の体内で寄生虫フィラリアが成長していることを発見(1887年)
    • 病気が虫によって媒介されることが明らかに
    • 多くの植民地を持つ英国
  • 蚊を駆除しようとする対蚊法(ロナルド・ロス)と、キニーネによる対原虫法
    • 衛生害虫の根絶は不可能、という考え
  • 日本のマラリア(おこり)
    • 北海道:大正期には収束し、昭和初期まで。
    • 台湾
  • 明治・大正期の日本の寄生虫学者の多くは動物学者
    • 医学では周縁扱い
    • 西洋と同じく、植民地統治の学問として成立
  • 戦前期には蚊やハエを研究する昆虫学者はほとんどいなかった
  • 台湾
  • 1910年代まで マラリア対策が開始
  • コッホ法
    • 対原虫法重視
  • 対蚊法
    • 自然に勝てないとする考え
    • 住民へ蚊帳や蚊取り線香の啓蒙はした
    • タップノミー(カダヤシ)を放流
    •  日本で特定外来生物に指定されているのは、このときのもの
    • 竹林伐採、下水溝や用水路の対策
    •  生態系の改変
    • 警察権力、強制、悪評
  • ハエ
  • 19世紀以前のほとんどの人々にとって、小さくてかわいらしい生き物
  • 19世紀の戦場における感染症の蔓延
    • 腸チフス
  • 1910年代以降、「不潔なハエ」の根絶運動
    • 不潔な虫としてのイメージは希薄
    • 動物愛護団体が激しく抗議
  • アメリカでハエ取りキャンペーン
  • 連邦農務省の昆虫学者たち
  • イエバエをチフスバエと呼ぶキャンペーン
  • 日本
  • 江戸時代:ありふれた昆虫
  • 20世紀 コレラの媒介者として
  • 大正期にハエの駆除運動
  • 衛生展覧会
  • 関東大震災をきっかけに、賞金つき駆除競争
  • 寺田寅彦批判:生態系を崩す
  • スラム排除
  • 「清潔で美しい都市」づくり
  • 日本の戦後の農村
  • 土地改良、用水・排水の整備
  • 昆虫が媒介する病気も急速に消える
  • 1889年 カリフォルニア
    • イセリアカイガラムシを駆除するためにベダリアテントウを導入、劇的な効果
    • 各国で導入
  • 1927年 農林省 ニカメイガプロジェクト
  • 天敵導入
    • 古くからいる害虫は外から持ち込んだ天敵で防除するのは困難
    • 日本の天敵研究が急速に進展
  • 誘蛾灯
    • 東京芝浦電気が参加
    • 青色蛍光誘蛾灯
    •  戦争のため、普及は戦後
    • GHQによる奨励中止
  • 殺虫剤を含む日本の化学工業は第一次大戦により発達
  • 1923年 砒酸鉛の国産化
  • 多くの殺虫剤が生産される
  • クロリピクリン
  • 発疹チフス対策のシラミ駆除に、毒ガスから転用(米)
  • 現在でも土壌消毒用の農薬として使われる
  • 青酸ガス
  • 陸軍開発の殺虫剤 サイローム
  • 毒ガス兵器に転用
  • 戦後、帝人の殺虫剤テジロン
  • 有機リン化合物
  • 第二次大戦期ドイツ
  • サリン、タブン
  • もとは1930年代の農薬研究
    • そのまま化学兵器担当部局に送付
  • 除草剤2,4-D
  • 第二次大戦期アメリカ
  • ベトナム戦争の枯葉作戦
  • DDT
  • スイスで農業害虫向け殺虫剤として開発
  • シラミ駆除剤としても
  • 米軍がマラリアと発疹チフスの対策に採用して生産が飛躍的に伸びる
  • ノーベル医学生理学賞
  • 米国 戦争と害虫駆除のイメージが互いに比喩となる
  • 日本では昔から合戦を「虫と虫」の戦いにたとえて風刺する文化
  • 1940年、日本軍の飛行機が中国の寧波で飛行機から穀物や綿を投下
  • 大量のノミ、ペスト
  • 「西洋文明=近代科学=自然破壊」というテーゼ
    • 東洋への期待
    • 二元論?
  • が、江戸時代の人々も害虫に苦しめられていた
  • ウィルダネスから里山へ
  • 総合防除
    • 1950年代アメリカの昆虫学者
    • 一定以下の水準ならば駆除しなくていいという考え
      • コスト
  • 1990年代 生物多様性

Shibuya.pm TT #12で話を聴いた

recruit_night.jpg

 11月30日に、Perlプログラマの集まるイベント「Shibuya.pm Technical Talk #12」に参加して、発表を聴いてきました。

 中心となったのは「NoSQL vs. NoKVS ライトニングディスカッション」。実際に高速(分散)KVSやRDBMSを開発したり使ったりしている豪華メンバーが壇上に並んで、発表や議論を繰り広げました。

 そのほかの発表も含めて、実開発者による濃い話が面白く語られていました。全体的に、アプリの実行速度にこだわった話が多かったのが印象的です。あと、予定の9時ぴったりに終わったのにもびっくり。

 1週間たっちゃいましたが、以下、自分の復習として、メモをまとめておきます。

Tatsumaki" I/O bound HTTP clients in web frameworks(miyagawa)

 Shibuya.pmといえばこの人、miyagawaさんのセッションです。まず、YAPCで旋風を巻き起こしたPlack/PSGIのその後について解説しました。

 PSGIは、リファレンス実装のPlackのほか、nginxやmod_psgiなどに対応。WAFもCatalyst、Mason、Maypole、CGI::Applicationなど多数に対応。Middleware(モジュールとかプラグインのようなもの)もAccesslogやNYTProfなどさまざまなものが登場しているそうです。

 で、PSGIで非同期なNon-blockingのサーバーがやりたかったので、psgi.streamingを10月に仕様追加したそうです。用途としては、遅延レスポンスや、ストリーミング(twitter streaming API的な意味で)など、マッシュアップとリクエストへのレスポンスとを重ねる例が紹介されました。

 いわく、WebサーバーはたいていCPUバウンドじゃなくてI/Oバウンドで、I/O待ちで待ってる間にマッシュアップとかリアルタイムWeb(Comet等)とかの処理ができる、とのことでした。

 ただし、それ対応のWeb Application Frameworkが(ほぼ)なかったそうです。そこで、最近作ったという「Tatsumaki」が紹介されました。PythonのTornado相当で、AnyEventのepollによるシングルスレッドのイベントドリブン型サーバーです。Shibuya.lispで紹介されていたCommon Lispのteepeedee2もこの仲間かな。いずれも、爆速Webサーバーという評判ですね。

 これをなんと、miyagawaさんは最初1日で作っちゃったそうです。なお、TatsumakiはXSモジュールには依存していないPure Perl実装だそうです。

 使い方は、ハンドラーのクラスを作ってURLにマッピングする方式。そのほか、ほかのWebサーバーにリクエストを投げるTatsumaki::HTTPClient(AnyEvent::HTTPのラッパー)や、AE::timerを使ったComet(Long-poll)、Pure perlのMQであるTatsumaki::MessageQueue、サーバープッシュのエミュレートであるMultipart XHRなどを紹介していました。ただし、AnyEventサーバーがLinuxで固まるバグがあるそうです。

 最後に、59行で書いたというチャットサーバーと、そこにtwitterとのマッシュアップを入れるというのを会場で実際に動かしてデモしていました。twitterは回線の関係でうまく動かなかったようですが。

 最後に、今後の予定として、XMPP/IRC botをWebアプリのように書けるようにするとか、Comet Interfaceとかの計画が語られました。

NoSQL vs. NoKVSライトニングディスカッション

 今回のメインセッションです。いずれも用途を定めてチューニングしていて、どの人も「用途を考えて選んでほしい」と言っていたのが印象的でした。

Tokyo (Cabinet|Tyrant)(mikio)

 すでに名の通った、高速なDBM系(つまり永続化された連想配列)ライブラリであるTokyo Cabinetと、そのRPCラッパーであるTokyo Tyrantを、平林(mikio)さんが紹介しました。1台で6万qps以上さばける(250億PV)そうで、「これで足りないというなら、それ以上のPVを稼いでから」といった自信の発言もありました。mixiでは、カウンタや、データマイニングや転置インデックスの作業領域として使っているそうです。

 壇上では、fsyncしていないからサーバーが落ちるとデータも壊れるんじゃないか、というツッコミもありました。それに対しては、機能はあるが推奨してない、Tokyo Cabinetが必要なケースなら速度優先だろう、という回答でした。

Lux IO (mogwaing)

 全文検索エンジン「Lux」用に用途を絞って、転置インデックスに特化して開発したDBM系ライブラリです。「ラックスアイオー」と読むそうです。特徴は、B+木と配列のみで、ハッシュがないことだそうです。C++で書かれていて、PerlバインディングのLux::IOをantipopさんが作って、はてブの個人検索で使っているという話もありました。

 転置インデックスに特化ということで、非常に長い値(value)を扱うので、disk I/Oが支配的な状況を想定しているそうです。つまり、索引分の構造の違いは無視できるので、B+木ということでした。ほか、索引部は全部オンメモリに置いている(mmap使用)とか、ほかのDBMはclustered indexがほとんどなところをunclustered indexをメインに使っている、とか。

 今後としては、ほかの用途も少し考えて、トランザクション対応とか、mmap以外の方式もオプション対応とかいうことも考えているそうです。ちなみに、壇上のmikioさんがそれを受けて、mmapを使ったKyoto Cabinetというのを作っていると話していました。

毎秒11万回更新できるのはREDISだけ(halt)

 PHPで活躍するhaltさんが、KVSを使う側視点でKVSのREDISを紹介しました。まずREDISの機能を紹介するスライドを飛ばしてw、なにより「PHPプログラマーでも扱える」という部分を強調していました。インストールもwgetしてmakeするだけで、それはTokyo Tyrantでもそうだけど名前が短いぶん有利、とw

 機能としては、KVSなのにデータ型があるとか、値を直接操作するコマンド(加算など)が豊富にあるとか、キーにワイルドカードを指定できるという話が紹介されました。

 発表タイトルにある速度面については、50クライアント同時で10万リクエスト/秒を処理できて速い、同時接続が増えてもパフォーマンスが落ちない、といったデータが紹介されました。ただし、壇上からは、シングルスレッドなのでマルチコアではスケールしないという指摘もあり、対応予定はあるようなので生温かく見守ってほしいとう回答でした。

kumofs(frsyuki)

 えとらぼのfrsyukiさんが、SPFのない分散KVSであるkumofsを紹介しました。いつでもノードを追加できて、追加したぶんだけスケールするのが特徴だそうです。えとらぼのFiciaで使われているという話でした。

 kumofsには、Manager(管理)、Server(データを保存)、Gateway(読み書き)の3種類のノードがある構成だそうです。アプリからはmemcachedプロトコルでアクセスするそうです。ベンチマークでは、memcachedなどに比べてputが速くて、これはGatewayでリクエストをまとめているせいではないかとのことでした。

 本体はC++で書かれてマルチスレッド対応、管理ツールはRubyで書かれているそうです。デモでは、管理ツールのkumotopコマンドを使って、ノードを落としたり追加したりして動的に再構成されるところを見せていました。

Hadoop/hBase(kzk)

 Hadoopで知られるPFIの太田(kzk)さんが、Hadoop BigTableクローンのHadoop/hBaseを紹介しました。Google BigTableはもともとクローラのデータを保持するもので、hBaseも大量行での低レイテンシが特徴とのことです。サーバーを足すしただけ性能が向上するスケーラビリティが特徴で、全部をなめるのも得意だそうです。

 構造は、単純なKVSではなく、Column Storeというのがあるそうです。1つのレコードにrowとcolumn familiesがあって、rowがプライマリキー相当、column familiesがスキーマなデータ相当の部分で、ただし行ごとにスキーマがかわってよい、ということでした。

 Hadoopの分散FSの上で実装されていて、分散ロックシステムZooKeeperを利用。データはリージョンサーバーに保持され、まずmemstoreに書いてバックエンドでfilestoreにマージする構成。Hadoop FSのレイヤーで冗長化しているそうです。

 なお、インストールキットとしてCloudera Distribution for Hadoop 2というのもあって、yumで簡単にインストールできるという話もありました。あと、Amazon EC2でも簡単に使えるそうです。

GoでKVSを書けるのか(moriyoshi)

 ちょっと毛色が変わって、発表されたばかりのGo言語を使ってmoriyoshiさんが分散KVSを作ってみた話でした。はてダで好評だった話をプレゼンにしてみたそうです。

 分散KVSの要素としては、ソケット(リッスン)、セッション維持、プロトコルのハンドル、Key-Valueを保持するバックエンドがあります。まずソケットは、netパッケージで一発だったそうです。また、セッション維持は、pollerを使ったイベント駆動なサーバは(今のところ)書けないので、Goroutineを使ったそうでえす。プロトコルのハンドリングはCと同じくビット演算で、KVバックエンドにはビルトインのmapを使ってアクター指向風に1個のGoroutineとして実装したとのことでした。

 できたところでパフォーマンスをmemcachedのmemslapで計測。遅いけど、意外に善戦しているという結果だそうです。ただし、壇上では、ローカルでやってるからでは(ローカルではコンテクストスイッチが支配的になる)というツッコミもなされていました。

 Go言語で分散KVSを書いてみた感想としては、netパッケージがそうとう適当で、Poll serverにfdを登録する方式では性能が出ないんじゃないか、という話でした。

NoKVSなRDBMS sharding作ってみた(kazuho)

 ここからRDBMS側の発表です。サイボウズラボのkazuhoさんは、まず、KVSではなくRDBMSにする基準として、ACIDの必要性、クエリの種類の多寡、運用手法(KKDでいけるか、情シスが運用するか)、お金などを上げました。

 また、MySQLの単体性能は悪くなくて特にSELECTは十分高速、ただしスケールアウトが問題、と語りました。

 そして、企業システム(グループウェア?)の要件がSNSと違う点として、書き込みが多い、ソーシャルグラフが密、トランザクショナル、画面数が多い、情シス部門が管理できるといった点を上げました。

 それらをふまえて、RDB Shardingによって、RDBMSを分散KVS的に分散させつつACIDな更新を行うソフトとして開発したInclineを紹介しました。サーバーで定義ファイル(DDL)にJSONで記述しておくと、書き込み時のトリガーで自動的に非正規化して適切なshardのみにレプリケーションするそうです。更新は多段で伝搬、表示用の実体化ビューは非同期更新、とのことです。

 また、Inclineと組み合わせる、高速・安全なShard分割ツールとして開発したPacificも紹介しました。

 今後は、アプリの「書きやすさ」を向上するために、SalesForceなどを参考にクエリを抽象化することなどを考えているそうです。

 この発表にはなぜかダントツに質問が集まりました。それによると、キューはMySQLのInnoDB、性能は2層コミットやるよりは速い、書く先はDDLで決まり読む先は自分の属するところ(JOINを使いたいので)、SPF対策はノードのペアを組んで冗長性、とのことでした。

Spider Storage Engine作ってみた(shiba)

 kazuhoさんに続いてRDBMS側から登場。MySQLのストレージエンジンによるRDBMS shardingの「Spider」を紹介しました。利用例としてはチームラボのサグールテレビがあり、インデックスを作るときに1DBあたりの負荷を下げたそうです。

 特徴は、アプリケーションからは透過的に普通のMySQLのテーブルとして見えるので、shardingしても変わらないこと。shardingのサーバー探しなどをSPIDERが肩代りしているそうです。いわく、「RDBをRDBのままshardingするため」とのこと。

 さらに、Vertical Partitioningされたテーブルを透過的に管理する機能も作っていて、組み合わせると、スキーマ変更やreshardingをオンラインで動的にできるという話でした。

Lightning Talks

ああ、柔軟な言語Perlよ(tokuhirom)

 「Perlの柔軟性は異常」ということで、Perlの文法ハックを紹介しました。まず、prototype宣言によるブロック渡しや定数畳みこみを紹介。続いてソースフィルタでPerl中にSQLをそのまま書くFilter::SQLを紹介しました。

 そのまま、構文木組み立てをフックするPL_checkハックを紹介したあと、Perl 5.11.2(開発版)から採用されたPL_Keyword_pluginを紹介しました。これは、キーワードに反応して、そこから先のパース処理をフックできるそうです。

Metaprogramming in Perl internalss(gfx)

 tokuhiromさんに続いて登場したgfxさんもPerlの文法ハックねた。こちらはperly.yに手を加えるという話でした。

 題材は、メソッドコールにブロックを渡せるようにするというねた。「Foo->bar(...) { ... }」のブロックを最後の引数として解釈するというものです。結論は、高度に発達したPerlはRubyと見分けがつかない、とw

Ajax application testing(Yappo)

 Perlの作法でJavaScriptのテストが書けるJSTAPdを作ったという話でした。HTMLタグを書いたりする必要もなく、XHRのテストもできるそうです。JavaScriptのテストは、ブラウザを起動したり、起動しているブラウザに実行させたりして動かしていました。結果出力は、Test::*っぽい形式になるようです。

CouchDBで作ろう!! めちゃうすっレイヤーアプリケーション(z.ohnami)

 CouchDB JPのz.ohnamiさんが、KVSの一種であるCouchDBを紹介しました。RESTなURIによるHTTPメソッドで操作して、レスポンスはJSON。「ドキュメント指向」ということで、テキストや画像、音楽、ソースコードなど「紙一枚にまとめて不自然ではないデータはCouchDB向き」だそうです。データとしてJavaScriptのコードを入れておいて、ブラウザでアクセスしたときにWebアプリとして動作させることもできるというのを、「必殺仕分け人Z」というデモで見せていました。

「新 仮面ライダーSPIRITS」1巻

 掲載誌の終了にともない、「仮面ライダーSPIRITS」が「新」になって仕切り直し。風呂敷が広がって大掛りになった元のストーリーから離れて、1号ライダーと2号ライダーの出会いから始まっている。

 ストーリーがシンプルになったぶん、ライダーの内面や葛藤の部分に焦点が当たっていて、アツい村枝節がキマりまくってジーンとくる。村枝節のファンであれば忘れず読むべし(読んでるか)。

 あと、巻末の対談で、千葉治郎さんにNGシーンの話を教えるとは、どんだけマニアなんすか(笑)。

その体で生きることで…
人間のフリぐらいは出来るようになる
一文字隼人 俺と来るか

「Ubuntu Magazine vol.2」

Ubuntu Magazine Japan vol.02 (アスキームック)

アスキー・メディアワークス
売り上げランキング: 425

 Ubuntu 9.10のセットアップを、パターンごとの解説から便利ツールの紹介、トラブルシューティングまで、徹底的に解説。もちろん「うぶんちゅ!」も掲載。

TokyuRuby会議01とWEBrick-DOMとXCAP

 RubyイベントのTokyuRuby会議01に参加してきました。昼間からビールを飲みながらLTをしあうという、リラックスしたイベントでした。

発表したよ

 私は「エコなWebサーバー」という題で発表してきました。

 もっともらしいことを書いていますが、つまりは「X-Path」「WEBrick-DOM」というダジャレを言いたいがためのネタ発表です。そのわりにいまいちウケなかったのは反省点です。

 しょーもないシロモノですが、GitHubに上げておきます。

XCAPを知ったよ

 発表したあと、ほかの発表者の方に、XCAP(XML configuration access protocol)という規格を教えていただきました。

 XCAPは、XMLで保存されているデータに対して、HTTPとXPathを使って、GET/PUT/DELETEを実行する仕様だそうです。こちらはXPath式をURLに入れる方式なんですね。ITproの記事で解説されています。

 RFC4825にもなっていて、SIPのアドレス帳とかNGNの設定情報とかで使われている、メジャーな規格のようですね。

 目的やアプローチ(や、もちろん完成度も)は違えど、同じようなことを考えるものだな、と思いました。

 それにしても与太発表をしたおかげで、勉強になりました。

 | HOME | 

Categories

Recent Entries

Recent Comments

Recent Trackbacks

Appendix

emasaka

emasaka

フリーター。
連絡先はこのへん

Monthly