※この記事にはちょっとした誤りが含まれています。追記:2009.07.24(2)を参照してください。 このテの情報があまり出回ってないようなので書いておく。 AutoPagerizeには、その動的に読み込んだページを継ぎ足すときに、特定の処理をそのページに対して適用する仕組みがちゃんと用意されている。 先日公開したグリモン jaro.user.js でもその仕組みを利用している。 if (window.AutoPagerize) { window.AutoPagerize.addDocumentFilter(function(doc) { setOpacity(sites, doc); }); } 上記のように、AutoPagerize.addDocumentFilterに特定の処理を行う関数を渡してあげると、動的に読み込んだページを継ぎ足すときにその関数を実行してくれるようになる。 もう
以前書いた、AutoPagerizeにインクリメントモードとURLフィルターを追加するプラグインを書いてみた - 0xFFがevalの第2引数廃止により動かなくなっていたので、本体に手を入れるという反則技で対応しました。さっぱりメンテできてないので、消しました。すみません。 404 · GitHub http://github.com/os0x/autopagerize/raw/master/autopagerize.user.js http://github.com/os0x/autopagerize/raw/master/miscautopagerize.user.js 2つともインストールして、miscのほうが先に実行されるように調整してください。 てか、元々は「インクリメントモードとURLフィルターを追加」してたのだけど、今では、Google画像検索への対応と英辞郎 on the
AutoPagerize を常用するようになってから初めて CodeRepos の Trac を見に行って気づいた。 何もせずに changeset を遡れる！ AutoPagerize のメリットは理解していたつもりだったけど、今回がいちばん感動した。なんでかなと思ったんだけど、普段 AutoPagerize の対象になるページは ニュースサイトの分割記事（最近これ多すぎ）検索結果一覧くらいで、実はこの二つは AutoPagerize がなくてもある程度の分量の情報を一目で確認できる。 しかし changeset の場合は極端な話、ほとんど情報量のない changeset が途中で混ざっていたりする1ので、一つずつめくらなければいけない状態が結構ストレスだったようだ。自覚はなかったけど、AutoPagerize が利いたときの驚きのでかさがそれを示している。なるほど、これが「ゼロクリック
FirefoxのAutoPagerize（id:swdyhさん作）がうらやましくなったのでw3m版も作ってみた。 というか、AutoPagerizeが生まれる前から「次のページ」ボタンが欲しくなってワンタッチでLocal CGIを起動して次のページリンクを見つけて押すようなものを作っていたのだ。だけど対応すべきサイトが膨大すぎるため自分が見るサイトしか対応していなくて公開してなかった。正直万人に使える代物ではなかった。 だが、AutoPagerizeの登場と最新版AutoPagerizeの設定データ（SITEINFO）がwebで公開されていることで状況が変わった。そこのデータを流用してしまえば、定番サイトは対応できるだろうと考えた。 しかし、壁はまだ残っていた。HTMLを解析してXPathで抜き出すまともなRubyのライブラリが存在しなかった。HpricotはいちおうXPathにも対応して
AutoPagerize – Userscripts.org http://userscripts.org/scripts/show/8551 SITEINFOの取得先につながらない場合の処理を追加 application/xhtml+xml のページへの対応の修正(0.0.33) wedataに繋らないせいで動かなくなってしまっていました。すいません。しばらく(30秒)繋らない場合、もう1日同じSITEINFOを使うようにしました。最初だけしばらく待つ必要がありますが、SITEINFOのキャッシュが残っていればwedataが繋らなくても動くようになります。 キャッシュがなくなっている場合や新規のインストールの場合は、wedataがもとに戻るまでもうしばらくお待ちください。どうしても早くなんとかしたい方は、os0xさんの記事を参考にソースを書き換えてください。 wedataのダウンでAut
wedataが落ちているためAutoPagerizeが動かないという状態が年末から断続的に続いています。 追記(2009/01/09):wedataが復旧し、正常にSITEINFOを取得できるようになった模様です。これに伴い、http://ss-o.net/databases/AutoPagerize/items.json の中身は空の配列になっています。うちのミラーを使用したいという方は、 http://ss-o.net/json/wedataAutoPagerize.json のJSONを利用いただけます。静的ファイルでgzipにも対応しているので、wedataより軽いはずです。ただし、wedataとの時間差があり、callback指定(JSONP)もできません。どっちが良いか分からない場合はとにかく最新のAutoPagerizeを使っておけばOKです。 追記(2008/12/24 1
2008-12-22 10:40:04 いまだ wedata.net が、復活しないので Constellation が、autopagerize の SITEINFO のキャッシュサーバを appjet.net に立ててくれました。 http://utatane.appjet.net/databases/AutoPagerize/items.jsonautopagerize 0.0.33 で言うと、autopagerize.user.js の31行付近の SITEINFO_IMPORT_URLS に var SITEINFO_IMPORT_URLS = [ 'http://utatane.appjet.net/databases/AutoPagerize/items.json', // 'http://wedata.net/databases/AutoPagerize/items.jso
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message Hello -- (I am sorry for the English.) I love Autopagerize VERY much! I think it is broken in Firefox 3.0.5. Can anyone tell me where I should start looking? Is there a better place to post about it? Can someone tell me if I can fix it myself? I would be happy to
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
Autopagerizeについて教えてください。 url: 'http://diary.jp.aol.com/(?:applet/)?juicyfruits/', nextLink: '//div[@id="mainbox"]/p[@class="item"]/a[last()]', pageElement: '//div[@id="mainbox"]/div[@class="section"]', exampleUrl: 'http://diary.jp.aol.com/juicyfruits/', このSITEINFOをちゃんと動くようにしたいんですが、どうすれば良いのでしょう。後、「オートスクロールを使わずに少ない動作で全てのページを継ぎ足す方法」や「pageElementで読み込む要素に次に継ぎ足したいページへのリンクがなくても良い理由」なんかも教えていただければ幸いです。
thinkのScrapBook: AutoPagerize用SITEINFO + SITEINFOの書き方 まとめ
かねてより試してみたかったGreaseMonkeyスクリプト「AutoPagerize」が非常に便利だったのでWedata未登録のSITEINFOを書いてみました。 AutoPagerize用SITEINFO var SITEINFO = [ { name: 'ブラック会社に勤めてるんだが、もう俺は限界かもしれない', url: '^http://ueharasan\.y\.ribbon\.to/html/', // Unicodeエスケープ前の文字列 (Wedata登録時はエスケープしなくてもOK) // nextLink: '//a[starts-with(text(),"次") or contains(text(),"進む")][1]', nextLink: '//a[starts-with(text(),"\u6B21") or contains(text(),"\u9032\u3
情報を能動的に集める人のためのキューレーションツール、Live Dwango Reader（旧 livedoor Reader）とLDR Pocketは、ブログやメディアに貢献できるサービスを目指して参ります。 ※LDRトップなどへのアクセスで「Internal Server Error」と表示される方は、一度、http://www.livedoor.com でログアウトしてから、再度ログインをお試しください。 livedoor Readerをご利用いただきありがとうございます。 担当の齊藤です。 フィードの登録数ランキングのページが、Greasemonkey用スクリプトAutoPagerize / LDRizeに対応いたしました。 FirefoxでAutoPagerize / LDRizeを導入されている方ならば、ページ遷移することなく次ページの内容が自動的に連結され、「j」「k」などの
document.evaluate の第二引数に適切なノードを指定していても， XPath expression が "/" で始まるとルートノードから走査されるので， 意図通りの結果が得られない可能性が高い． ありがちなのは AutoPagerize で 2 ページ目以降を処理しようとして XPath に "//" を使ってしまい，結局ページ内の全ノードを舐めてしまうとか． 面倒でも "descendant::" もしくは "descendant-or-self::" を使用されたい． もしくは， getElementsByTagName で済む場合であればそちらを使えば意図通りの結果が得られるし， なにより速いはず． 一応，実験 (要 javascript/)．IE では動作しない．
Cold Brew (水出し) 2.0 アイスコーヒー 2.0を書いたのが 2020 年の夏なので、そこから 2 年も経ってしまったなんて驚きだ。 今回も懲りずに「2.0」シリーズを書いていくんだけど、なんで Cold Brew なのかというと、ここ数ヶ月通っている Definitive. が出す Cold Brew によって自分の中の常識が変わってしまったから。 これまで豆のポテンシャルを最大限味わいたいならフィルター（ホットのドリップ）を選ぶことが多かった。 だけど Definitive.の Cold Brew はフィルターで淹れたコーヒーと同じくらい複雑なアロマと様々なフレーバー、アフターの複雑さ、温度変化によるフレーバーの変遷も楽しむことができる。 ということで、お店の味を完全再現！とまではいかないものの、豆に応じて好みの Cold Brew を作れるようになってきたので、レシピと
まず言っておく。以下のページにログが残っている修正、具体的にはAutoPagerizeではてなダイアリー・はてなグループの日記を継ぎ足す処理を「最新の日記」だけで行われるようにしたのは私です。 アイテム: はてなダイアリー・はてなグループ - データベース: AutoPagerize - wedata リビジョンログ 以前からAutoPagerizeを使っていて不満に思っていたのは、例えばブログなら、トップページやカテゴリーページといった複数記事が一覧されるページだけでなく、各記事ページでもAutoPagerizeされる、つまり過去の記事が継ぎ足されるよう設定されていることがしばしばあったことだ。もちろん「続きを読む」で分割されている場合は継ぎ足して欲しいが、それでもその「1つの記事」の範囲内に抑えて欲しいと思っていた。 なぜ、そのような個別ページでも過去の記事を継ぎ足すようにする必要があ
http://github.com/ganaware/autopagerize/tree/master AutoPagerize は便利なのですが、最近そのスクロール時の遅さが気になってきました。カーソルキーでスクロールさせたり、マウスのホイールでスクロールさせたりすると非力なマシンではけっこう遅くなります。 少々調査してみたところ、AutoPagerrize はステータスを表示するためにページの右上に緑色の■を表示しますが、そのスタイルが position:fixed に設定されているのが原因でした。推測ですが、このスタイルを利用すると画面の再描画量が多くなるため遅くなると思われます。 そこで、position:fixed を position:absolute に変更しスクロール後 1 秒たったら、バーの位置に合わせて top: を修正するようにしてみました。 とりあえず手元のマシンで
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
