いま見てるページに対するsiteinfoをfirebug consoleに出すbookmarklet - ロックスターになりたい
var d=document;var s=d.createElement('script');window.WeDaTACLB=function(json){ console.log( json.filter( function(i){ return d.location.href.match(i.data.url); } ) ); }; s.src="http://wedata.net/databases/AutoPagerize/items.json?callback=window.WeDaTACLB"; s.type="text/javascript"; void(d.body.appendChild(s)); 軽快な動作や自動バックアップが好評の「その場編集モード」を自分の日記で体感できるようになりました 自分の日記じゃないところで体験できたの? よーわからん
stock.xchngのSITEINFO - os0x.blog
oAutoPagerizeのSITEINFO追加 - 0xFFで書いたstock.xchngのSITEINFOはoAutoPagerizeでは問題ないんだけど、Firefoxではbase要素のせいで3ページ目でエラーが。。 というのも、nextを取得する際に、その要素はページには追加されていないので、base指定による影響を受けない。 そのため、http://www.sxc.hu/category/1091/2の最後の/を基点として、http://www.sxc.hu/category/1091/category/1091/3というURLを取得してしまう。 残念ながら、こういうのはXPathをどうこうしても解決できない。 というわけで、AutoPagerizeをhackしてgetNextURLを書き換えてしまうGreasemonkeyを書いてみた。 // ==UserScript== //
LDR Full Feedのsiteinfoを使ってフィードを全文入りにupgradeするPlagger::Plugin::Filter::EntryFullText::SiteInfo（2008/2/27仕様変更） - fubaはてな
LDRでgを押せば全文出てくるべんりなLDR Full Feedだけど、個人的には自作の自動抽出のをつかってるのでいいなーと思いながら指をくわえてその進化を見つめています。ただ本文XPathのsiteinfoはものすごく使えそうなので、とりあえず試しにPlaggerでただのりさせてもらうことにしました。siteinfoはキャッシュしてないのでちょっとまずいかもしれないけど、たぶんこのプラグインを使う人はほとんどいないので大丈夫でしょう。siteinfoの取得もPlagger::UAを使うようにしました。これでキャッシュできてる！ と思う…。 lib/Plagger/Plugin/Filter/EntryFullText/SiteInfo.pm 元のEntryFullTextは継承して全機能がそのまま動くようになってるはずです。今つかってるconfig.yamlのmodule: Filter
json2infogami siteinfo format converter « ku
jsonで書いてあるSITEINFOを、infogamiのフォーマットにあわせるの、いつも手作業でやっててアホだったのに気がついた。 function json2infogami(firstarg) { var infogamiEscape = function (v) { return v.replace(/([_\*])/g, "\\$1" ) }; var textfilter = infogamiEscape ; var a = (firstarg.constructor.name == "Array") ? firstarg : arguments; var r = []; for(var i = 0; i < a.length; i++) { var siteinfo = ""; for ( var n in a[i] ) { var v = a[i][n]; siteinfo
どこでもスター - ロックスターになりたい
There was a problem posting your writeback.(007) っていわれてコメントが入らなかったので。 Big Sky :: どこでもスターグリースモンキーは開発者を殺す？ クリックしたところにどこでもスターをつけるためのセレクタを生成して自動でsiteinfoに書き込んでくれるグリースモンキースクリプト、みたいなかんじで介入していけますよ! CSSセレクタの方が分かる人が多いからCSSセレクタにしたのはたしかに正しい選択なのかも。XPathを書ける人はあんましいない。ただ、ここの要素っていうのをXPathですら表現し難い場合がおおいのでCSSセレクタだと"どこでも"といえるほどどこでもにはつけられないのでは。 あれこれjsonにコード書かれたりしても大丈夫なようにどこで担保してるんだろう。 wikiに書かれたコードをサーバでパース(siteconfig
LDRize専用のmicroformatsについて | 3.14
先に結論LDRize専用のオレオレフォーマット案には反対です．その理由を書きます．ついでに今後の展望について書くつもりでしたが，疲れたので途中まで． 今までの話の流れ - 内部向けのサイトなので，公にSITEINFOを書きたくない - 「v」「o」で開くようなリンクはなく，「j」「k」のスクロール操作だけを利用したい ちょっと特殊なケースですね． 実は，これは今まで見えにくかっただけで，LDRizeの一番の利点を生かしたケースじゃないかと思っています．ちょっとだけTumblrに書いたやつやちょっとだけTwitterに書いたやつ1ちょっとだけTwitterに書いたやつ2以外はまだオンラインにあげてないので，詳しくはまた今度書きますが(多分)，LDRizeの利点は以下の３つだと考えています． 読み飛ばせる 位置を調整できる 記事単位でなんらかの操作ができる じゃあ，今回のケースのようなサイトで
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SITEINFOが書かれてないか(おおざっぱに)検索するbookmarklet - ロックスターになりたい
403 アクセス禁止
