yohei-y:weblog: Atom で件数取得
なんか催促されちゃったみたいなので :-) 詳しく書いてみます。 はてなのブックマーク件数取得 API いいですね。 今さら xml-rpc かよ! というツッコミは置いておいて、 データ重要な世の中で有用なコンテンツ(メタデータ)にリーチする 方法が増えるのは喜ばしいことです。 そうそう、こういう API を AtomPP で実装するとしたらどんな感じなんだろう。そもそもうまくフィードで定義できるのか。教えて偉い人! 偉い人じゃないけど、結論からいえば、 Atom Publishing Protocol (APP) そのままじゃ無理です。 やってもいいけどどうしても無理が出てしまいそう。 そもそも目的が違うのだから、ここは野良 XML/プロトコルでいいのでは。 ただ、結果をフィードで取れるとそれなりに嬉しいかもしれない。 普通 REST で検索するときは query string を使っ
ブックマーク件数取得APIをリリースしました。 - naoyaのはてなダイアリー
exist API を使えば HTML をスクレイピングするより高速な実装が可能ですが、それでも一画面に 50 件検索結果があったりすると 50 回 exist API を叩くことになって HTTP のオーバーヘッドが大きいでしょうし、サーバー側も SQL が 50 回走ったりして嫌なので、前から考えてた複数 URL を与えてブックマーク数をまとめて取得する API を作ってます。来週にはリリースしたい。 ということで、はてなブックマーク件数取得APIをリリースしました。相変わらず名前がださい。JSON版とかMD5で問い合わせられるようにとかはまた後ほど。 はてなブックマークはそんなにサーバーの台数もまだないので、連続リクエストはすこし間隔あけてもらえたりすると助かります。 そうそう、こういう API を AtomPP で実装するとしたらどんな感じなんだろう。そもそもうまくフィードで定義で
2005 年 8 月の履歴もしくは日誌 / おのひろきおんらいん
どのように他の人の感情や思考を認知しているか まず最初に謝るべき事は，本来は私信でも良さそうな文を Web に出し，第三者の理解の為に十分な配慮が無かった事です．しかし公開した文章に対して反応がいろいろあったので，それはそれでぼくは面白かったのですが，最初にちゃんと伝えるべき事がうまく伝わらなかった感じがあります．ますは最初の失敗の修復を試みるところから始めましょう．まず話の流れが第三者に全く見えないのでそれを補完し，ぼくが挙げた例示での「共感できない」の意味と，それによる誤解が生じた背景を説明します． 事のはじまりは数人での茶飲み話で，コミュニケーションには共感を求める「共感型コミュニケーション」と情報交換を求める「情報交換型コミュニケーション」があるのではないかという話をしたのがきっかけです．ある女性は仕事では「情報交換型コミュニケーション」であっても，仕事以外では「共感型コミュニケー
コメントアウトはやめてくれ - 檜山正幸のキマイラ飼育記 (はてなBlog)
naoyaさんの「そのページが誰のものなのかを示す識別子を埋め込む仕様を考えています」に対する僕の反応の趣旨は、「HTML（XML）コメント内に意味のある情報を記述する」という選択肢は良くない、ということです。PIは「まだしもマシ」と引き合いに出しただけです（特に推奨はしない）。 その後いろいろあって結局、「続々 Hatena ID Auto-Discovery」の最後において、TrackBackTechnical Specificationのコメントアウトに関するくだりを引用した後で： "This is not a perfect solution, but it works as a temporary fix." だそう。これをよしとするかどうか、ってとこですね とのこと。また、コメント案がぁー、、、 僕はそれを“よしとしない”わけだけど、現実的な事情からやむにやまれぬ場合でももう一
XML::Feed で XML::RSS::LibXML を使う - naoyaのはてなダイアリー
はてなRSSではフィードの Auto-Discovery や parse にCPANモジュールのXML::Feedを使っています。XML::Feed は XML::Atom と XML::RSS を抽象化したユニバーサルな parser で、且つ Feed Auto-Discovery の機能も実装されている便利モジュールです。作者は Six Apart の Ben Trott 氏。 これまではてなではあまり積極的に XML 関連モジュールは使ってこなかった(正規表現でぶっこ抜き)のですが、はてなRSS に関しては巡回時にフィードを parse するだけなので、一時的なアクセス増に対する parse 回数の増加などはないだろうと判断して、XML::Feed を採用しています。 もとい、先日ベンチを取ったりしていた XML::RSS::LibXML は動作も安定していそうだし、速度的には X
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
