2012/08/29


もう僕が知ってる twitter じゃなくなってきてる。
Twitter、開発者向けガイドラインとAPI変更について説明 ユーザー数制限など厳しい内容 - ITmedia ニュース

米Twitterは8月16日(現地時間)、数週間後に予定しているTwitter APIのバージョン1.1へのアップデートと開発者向けガイドライン「Developer Rules of the Road」の改定について説明した。クライアントアプリのユーザー数に上限を設けるなど、サードパーティーにとって厳しい内容になっている。

http://www.itmedia.co.jp/news/articles/1208/17/news037.html
Twitter のことと P3:PeraPeraPrv について - とかいろいろ

彼らはこのユーザーの「好みのクライアントアプリを選ぶ自由と権利」を奪うという決定をしました。

http://d.hatena.ne.jp/lynmock/20120828/p1
ちょっと昔話をしようと思う。僕は 2007年4月から使い出してるので、結構古参の部類に入ると思う。gtktwitter という linux と windows で動く twitter クライアントをソース付きで公開した。
Big Sky :: TwitterのGTKクライアント作りました
http://mattn.kaoriya.net/software/twitter/20070412093406.htm
作った本人があまり力を入れていなかったというのもあり、gtktwitter はクライアントとしてではなく、どちらかというと WebサービスをC言語で扱う時のコード例として一部のユーザに広まった。
その他、僕のブログには twitter API を使った物が数多くあり、その多くは今後動かなくなるかもしれない。
当時の twitter の API 戦略は革新的だったしデータが溢れ出てくる泉だった。業界をリードしていた。そこらのWebエンジニアが味わう事が出来ないデータ量を twitter がどうさばいたかというのはデファクトスタンダードも覆す物であったと記憶している。 その後、twitter はクライアントに「twitter」という文言を含める事を禁止し、basic認証も廃止した。
Big Sky :: TwitterのBasic認証廃止は約半分のデスクトップクライアントを殺した。
http://mattn.kaoriya.net/web/twitter/20100908165946.htm
twitter サポートに色々問い合わせ、エコシステムという時代の流れに納得した。
Big Sky :: Twitterが考えるAPI認証とは
http://mattn.kaoriya.net/web/twitter/20100910121212.htm
色々変わったが twitter はこのまま僕らエンジニアにとっての道しるべの一つになっていくのは揺ぎ無いと思っていた。しかし今の twitter もビジネス。twitter 自身が統制の取れない物は排除して当然だと思います。

でも、僕の知ってた twitter はどこかに行ってしまった気がする。
エンジニアがインターネットリソースを使って何かを試したい時、twitter は格好の題材だった。
curl コマンドでユーザとパスワードさえ指定すれば幾らでも動的なデータが得られ、REST構造の良い題材だった。
今でもそれは変わらない。しかし今の twitter はどう見ても API を使わせない様に動いていると僕には感じられる。その内、API 有料なんて事になるんじゃないかと思ってもみる。
認証が OAuth に変わって以来、簡単にインターネットリソースを使って何かする為の良い題材として twitter は少し遠のいた。もちろんbasic認証がプライバシーを守るに値する認証方法であるとは言わないが、こうやって過去を振り返ると twitter の API 戦略はここで役目を終えてしまったと言っていいだろう。

この事は Google についても同じ事が言えるな。もうあの頃の twitter では無くなってしまったのだ。
Posted at by



2012/08/24


Yahoo! Pipes万歳
Yahoo! Pipes はてなブックマークの「サイト内新着ブックマーク」(のフィード)のdelicious版を作ってみました。
構成は2段になっていて
  • 指定フィードのエントリを以下のPipesに渡すPipes
  • 指定URLのdelicious上のユーザブックマークフィードを出力するPipes
となっています。

まず親側のPipes

Pipes: delicious bookmarks in your feed
delicious-feed1
人によっては一つのサイトで複数のフィードを吐いていて、そのエントリのリンクで末尾(例えばフラグメント)を変えたりしている人もいるだろうからオートディスカバリはしていません。
この「For Each: Replace」で次のPipesを呼び出しソートしています。

そして子側のPipes
Pipes: delicious bookmarks in the url
delicious-feed2
ここではちょっと裏技を使っていて、本当ならばdeliciousのブックマークページはURLをMD5したページにあるのですがここのフォームターゲットをGETで呼んでリダイレクトしています。 この遷移先のページにはフィードが出力されており、ユーザ単位のブックマークエントリが含まれています。
これを親側でreplaceするのです。ただしページによってはブックマークされていない場合もあります。この場合deliciousのブックマークフィードはトップ画面のブックマークフィードを返してしまうのでitem.linkを使って本当に正しいかを確認しています。


はてなブックマークにはサイト内ユーザ単位の新着ブックマークフィードがあるのになんでdeliciousには無いんだろう...と前々から思っていたので作ってみました。
よろしければご利用下さい。

追記
オートディスカバリする版も作った。
Pipes: delicious bookmarks in your site
Posted at by




microformats 前回はmicroformatsを簡単に説明する事で、microformatsとは何か?、microformatsで何が出来るのか?を説明しました。
今回は、microformatsを利用して実際にWebページにメタデータを埋め込む手順を示して行きます。
microformatsのメタデータ構造はXHTMLで記述され、microformatsを利用するアプリケーションはDOMを使用する事で簡単にメタデータを扱う事が出来る様になります。

前回の記事を書く時点で、この記事を記述する前に、以下のmicroformatsをこのサイトに埋め込みました。
  • hCard
  • rel-tag
  • XFN
今回はその作った過程を説明していきます。

hCard

hCardの作成にはhCard Creatorや、hCard生成ツールでベースを作成し、自分のサイトのスタイルに合わせ修正するのが手っ取り早いです。
class属性には「class="fn"」といった単独の記述も出来れば、「class="url fn"」のように記述して <a class="url fn" href="http://example.com/">ExAmPlE</a>
と組み合わせで記述する事も出来ます。

rel-tag

rel-tagは、そのサイトドキュメントが関連するタグを指し、ブログであれば各ブログツールによって生成されるものと思われます。利用するアプリケーション側は、このタグ情報を自身のサイトで抽出させたり、del.icio.usで検索させたりする事が出来ます。
このサイトでは、blosxomというブログツールのプラグインを使用してでタグを生成しており、本サイトの右側に表示されているタグ表示に使っています。
ただ、前回ご紹介したmicroformats Operatorでは、URLの最終部分をタグとして扱う仕様(technorati仕様)になっている為、例えば <a href="http://example.com/weblog.cgi?tag=microformats" rel="tag">microformats</a>
等といったURLでOperatorを使うと、タグには「webblog.cgi」が表示されてしまいます。
これを回避するには <a href="http://example.com/weblog.cgi?tag=microformats&-technorati-hack=/microformats" rel="tag">microformats</a>
という風に、無効なパラメータ(-technorati-hack)を使用して無理矢理フォルダ階層を作るの事でOperatorに扱わせる事が出来ます。(バッドノウハウ?)
このサイトでもblosxom.cgiというCGIがそのまま表示されますので、同様の修正で対応しています。

XFN

実は前回の記事には少し宜しくない部分があり、実際にはブログのエントリタイトルに対して「rel="bookmark"」を付けるべきだったと後で気づいた為、現在は修正してあります。
これから前回の記事を読む方は、記事本文を読み替えて下さい。

さて、今回は前回作成したmicroformatsに加え、「rel-license」を埋め込みました。
rel-licenseは、その文書の免責情報が記述されている文書へ、リンクを生成する際にrel属性に対して設定する値で、本記事のHTMLを参照して頂くと最下部あたりに <a rel="license" href="http://example.com" title="...">rights reserved</a>
と書かれた部分が見当たるかと思います。
このリンクは、本サイトがCreative Commonsの指定の文書に従ってコピーライトされている事を意味しています。
例えば、皆さんが訪れたサイトがどんなライセンスなのかを見るには、このrel-license属性を見る事で確認する事が出来ます。
Creative Commons限定ですが、cc licenseというブックマークレットを使用すると、そのサイトがCreative Commonsライセンスなのかを確認する事が出来ます。
本サイトも、本記事をポストするにあたり、rel-licenseを追加したので、「cc license」でCreative Commonsライセンスである事が確認出来るようになっています。(bookmarklet)

microformatsには色んな拡張があり、現在も尚Draftへ新しい拡張が追加されていっています。

その中でも私が興味深いと思ったのは、「hPlaylist Profile」というXMDP(XHTML Meta Data Profiles)形式のmicroformatsを利用したプレイリスト公開フォーマットで、曲の
  • タイトル
  • 作者
  • 注釈
  • 情報
  • 情報元URL
  • 画像(おそらくジャケ写真?)
  • プレイリスト公開日
  • 属性
  • その他トラック情報...
を格納する事が出来ます。例えばもしAmazonがこれに対応すると、CDの曲情報をmicroformatsで配信する事が出来るのでは?と思いました。
また、再生した曲目リストを公開する事で人と繋がりあうSNS、PLAYLOGもこれに対応する事で、現在のようなアルバム名、曲名、作者だけでなく、上記の補足情報(SONYに関連したものだけしか公開出来ないかもしれませんが...)を公開する事が出来るようになるかと思います。
未だ、私はhPlaylistを本格的に使ったサービス、アプリケーションを見つけられていませんが、AmazonでCDの紹介ページを閲覧した際にオフィシャルサイトへのリンクが表示されたり、ブログに現在再生曲情報を付加する「Now Playing」等で利用出来るのはないかと思います。

可能性が広がり、夢がありますね。
Posted at by