  |
はてなキーワード: REDとは
http://business.nikkeibp.co.jp/article/nmg/20071008/136857/
そもそもmixiにせよyahooにせよ見る側からすると広告ってウザい。
だから、広告サーバを騙して、広告を出さないようにする、その簡単な方法を紹介する。
この方法って、ネットに詳しい人には至極当然で当たり前に
何年も前から行われてることなんだけど、この方法が広がっちゃうと
自分の首を絞めることになるから、あんまり言いたがらないし、雑誌やネットでも書かれていない。
だから、一般ユーザはいつまでたってもこれを知ることができず
いまもウザい広告を見せ付けられ続け、ある意味「搾取」されている。
私はネット業界にいない人間なので、タブーはない。あえてここで書いてしまう。
この方法のデメリットとしては、面白いウェブ広告を見落とすことかな。
ちなみにXP用なので。ほかのOSはhostsファイルを各自探して。
スタート→「ファイル名を指定して実行」で下のをコピペ実行する
notepad c:\windows\system32\drivers\etc\hosts
メモ帳がでてきたら、ファイルの最後にしたのをコピペ追記して保存。こんだけ。
0.0.0.0 adserver.yahoo.co.jp ard.yahoo.co.jp ai.yimg.jp 0.0.0.0 bizad.nikkeibp.co.jp ads.nikkeibp.co.jp 0.0.0.0 ads.mixi.jp 0.0.0.0 click.adv.livedoor.com image.adv.livedoor.com 0.0.0.0 ad.doubleclick.net
これをやるのとやらないのとでは大違い。お試しあれ。
発祥: http://ex23.2ch.net/test/read.cgi/morningcoffee/1188654905/
Scheme という Lisp 語族の言語を用いて ℃-ute の相関関係をプログラムし、様々な角度から関係性を分析する手法を紹介していきます（ソースコードは最後に張ります）。
まずは、メンバー間の関係を「リスト」というデータ型で表現します。例えば「栞菜->愛理」という関係は
(kanna . airi)
という形で表すことができます。これに、「大好き」という情報を付加し、ついでにその関係の性質を数値化したものを加えると
((kanna . airi) (desc "大好き") (score . 1))
のようになり、関係図における一つの矢印の情報をデータ化できたことになります（暫定的に、好意は 1、良好・中立は 0、険悪は -1 の３段階で表すことにします）。
メンバー間の全ての関係性をこのデータ単位で定義し、データベース化しておくことで、色んな条件に基づいた検索やスコア計算などが可能となります。
ここで相関関係図における矢印を「リンク」と呼ぶことにして、あるメンバーから他のメンバーへどのようにリンクし、またリンクされているかを調べることができます。
(sort-nodes (number-list (from-links)))
結果:
((kanna . 6) (saki . 5) (maimi . 4) (erika . 3) (mai . 3) (chisato . 3) (airi . 2))
栞菜ちゃんがメンバー全員にリンクを張っていることが分かり、℃-ute ラブっぷりが伺えます。なっきーにも同様の事が言えます。例の「女の子が好き」発言を数値的に裏付ける結果と言えるかもしれません。
ただ、データ不足でリンク件数がまだ少ないのと、リンクの性質（好意／反感など）までは分からない点を考慮する必要があるでしょう。
同様に、リンクの終点の件数を調べてみます。
(sort-nodes (number-list (to-links)))
((chisato . 5) (erika . 5) (kanna . 4) (maimi . 4) (airi . 4) (mai . 3) (saki . 1))
えりかちゃんと千聖ちゃんが高ポイントです。メンバーからの人気や注目度の高さを示すデータですが、千聖ちゃんの場合敵対的なリンクが２件含まれている点に注意してください。
なっきーの被リンク数が極端に少ないですが、単純にデータ不足のためだと思われます。はぶら(ryとか言わないようにお願いします。
リンクに付随するスコアを計算することで、愛情の度合いを測ることができるのではないか、という考えに基づく研究です。
まず、全ての関係性を対象として、スコアがマイナスの関係を抽出してみます。
(filter-nodes (lambda (n) (< (score-relation n) 0)))
結果:
(((kanna . chisato) (desc "愛理に手出すんじゃねぇよ") (score . -1)) ((saki . chisato) (desc "愛理に手出すんじゃねぇよ") (score . -1)))
件数だけを得ると
(length (filter-nodes (lambda (n) (< (score-relation n) 0))))
2
僅か２件です。
良好・中立的な関係は
(length (filter-nodes (lambda (n) (= (score-relation n) 0))))
8
愛に満ちた関係は
(length (filter-nodes (lambda (n) (> (score-relation n) 0))))
16
非常に多いです。舞美ちゃんの「℃-ute同士でラブラブなんですよ」発言（例のラジオ）を数値的に裏付ける結果と言えるんじゃないでしょうか。
次に、メンバーごとのスコアを算出してみます。Lisp 的には以下のようにフィルタリングと畳み込み (fold) で計算することができます。例えば
(foldr (lambda (n acc)
(+ (get-score n) acc))
0
(filter-nodes (cut to? <> 'kanna)))
3
上式を一般化して一挙にメンバー全員に適用してみると
(sort-nodes (map (lambda (x) (cons x (score-loved x))) (all-members)))
結果:
((airi . 4) (kanna . 3) (mai . 2) (erika . 2) (maimi . 2) (saki . 1) (chisato . 0))
愛理ちゃんが好意を寄せられやすい傾向が伺えます。
今度は逆方向のスコアを計算してみると
(sort-nodes (map (lambda (x) (cons x (score-loving x))) (all-members)))
((kanna . 3) (maimi . 3) (chisato . 2) (airi . 2) (saki . 2) (mai . 1) (erika . 1))
まいまいとえりかちゃんが特に堅い・一途だという傾向を読み取ることができます。
今度は組み合わせ（カップリング）の評価です。
２点間相互のリンク・スコアを加算したものを「相性」と考えられるものとします。最大値 (互いに好意を寄せている場合の数値) は現在のスコアリング方式では 2 です。例えば
(score-between 'kanna 'airi)
の値は
2
となります。1 であれば一方通行と考えます。
関係性が未定義の場合もあるので 0 のものを除外して算出すると
(sort-nodes (filter (lambda (n) (not (= (cdr n) 0))) (map (lambda (n) (cons n (apply score-between n))) (all-combinations))))
(((chisato mai) . 2) ((chisato airi) . 2) ((airi kanna) . 2) ((saki kanna) . 2) ((kanna maimi) . 2) ((erika maimi) . 2) ((saki airi) . 1) ((saki erika) . 1) ((kanna mai) . 1) ((maimi airi) . 1) ((saki chisato) . -1) ((kanna chisato) . -1))
となります。若干ピンとこない部分もあるかも知れませんが、計算上は矛盾無くデータの内容を表しています。
(map (lambda (p) (find-relation (cons (caar p) (cadar p)) identity)) (filter (lambda (n) (= (cdr n) 1)) (map (lambda (n) (cons n (apply score-between n))) (all-combinations))))
(((kanna . mai) (desc "喰ってやるよ") (score . 1)) ((saki . airi) (desc "好き") (score . 1)) ((maimi . airi) (desc "良き妹") (score . 1)) ((saki . erika) (desc "彼氏にしたい") (score . 1)))
のようになります。
以上の調査を経て気になった問題点を列挙してみます。
特に最初の点に関して、「百合的」なるものの質的評価がなかなか難しいと感じました。例えば「大好き」も「良き妹」も同じ 1 と評価してしまっているのが妥当かどうか、といったことです。
また、スレにて与えられた情報を評価・分析する方法としては有効だとしても、逆方向のフィードバックの手段がなかなか見つからないというのが三つ目の問題です（技術力不足とも言います）。（注：画像化の方法が分かりました。追記参照）
最後に、プログラムのソースを示します。実行には PLT Scheme が必要です。文字コードは UTF-8 で保存した上で、(load "c-ute.ss") としてください。文字化けする場合はターミナルが UTF-8 を表示できるよう設定する必要があります。がんばってください。
c-ute.ss:
(require (lib "etc.ss") (lib "list.ss") (lib "26.ss" "srfi") (lib "delete.ss" "srfi" "1")) ;;; Utilities (define true? (compose not not)) (define (ignore _) #f) (define fif (case-lambda ((predicate consequent) (fif predicate consequent ignore)) ((predicate consequent alternative) (lambda (x) (if (predicate x) (consequent x) (alternative x)))))) (define (concat! xs) (apply append! xs)) (define (mapconcat f lst sep) (let lp ((str (f (car lst))) (lst (cdr lst))) (if (null? lst) str (lp (string-append str sep (f (car lst))) (cdr lst))))) (define (slice-string str len) (let lp ((res '()) (str str)) (if (<= (string-length str) len) (reverse! (cons str res)) (lp (cons (substring str 0 len) res) (substring str len))))) (define (break-string str len) (mapconcat identity (slice-string str len) "\\n")) ;; NOTE: input and output ports have to be either file-stream or #f ;; (i.e., cannot be a string port) (define (run exe opt in out) (let-values (((p p-i p-o p-e) (subprocess out in #f exe opt))) (subprocess-wait p) (close-input-port p-e))) ;;; Database ;; http://ja.wikipedia.org/wiki/%E2%84%83-ute (define names '((erika . "えりか") (maimi . "舞美") (saki . "早貴") (airi . "愛理") (chisato . "千聖") (mai . "舞") (kanna . "栞菜"))) (define (symbol->name sym) ((fif true? cdr) (assq sym names))) (define nodes '()) (define edges '()) (define (relate from to desc score) (let ((n (cons from to))) (or (find-relation n (lambda (r) (let ((d (assq 'desc r)) (s (assq 'score r))) (set-cdr! d (cons desc (cdr d))) (set-cdr! s (+ score (cdr s)))))) (begin (set! nodes (cons n nodes)) (set! edges (cons (cons n `((desc ,desc) (score . ,score))) edges)))))) (define (find-relation n k) ((fif true? k) (assoc n edges))) (define (related? x y) (find-relation (cons x y) (lambda (_) #t))) (define (from? n x) (eq? (car n) x)) (define (to? n x) (eq? (cdr n) x)) (define flip-relation (case-lambda ((n) (and (related? (cdr n) (car n)) (cons (cdr n) (car n)))) ((n k) ((fif true? k) (flip-relation n))))) (define (get-score n) (cdr (assq 'score n))) (define (get-description n) (cdr (assq 'desc n))) (define (describe-relation n) (find-relation n get-description)) (define (score-relation n) (or (find-relation n get-score) 0)) (define (print-node . ns) (for-each (cute find-relation <> (lambda (r) (display (format "| ~a => ~a (~a)~%" (caar r) (cdar r) (mapconcat (lambda (s) (string-append "\"" s "\"")) (cdr (assq 'desc r)) ", "))))) ns)) (define (iter-nodes k) (let lp ((nodes nodes)) (unless (null? nodes) (k (car nodes)) (lp (cdr nodes))))) (define (filter-nodes p) (let ((ns '())) (iter-nodes (fif p (cut find-relation <> (lambda (n) (set! ns (cons n ns)))))) ns)) (define (from-links) (map car nodes)) (define (to-links) (map cdr nodes)) (define (all-members) (delete-duplicates! (from-links))) (define (all-pairs) nodes) (define (ordered-pairs) (concat! (map (lambda (x) (map car (sort (filter-nodes (cute to? <> (car x))) (lambda (x y) (> (get-score x) (get-score y)))))) (sort-nodes (map (lambda (x) (cons x (score-loved x))) (all-members)))))) (define (all-combinations) (let lp ((cs '()) (ns nodes)) (if (null? ns) cs (let ((n (car ns))) (lp (if (member (list (cdr n) (car n)) cs) cs (cons (list (car n) (cdr n)) cs)) (cdr ns)))))) ;; number-list :: [a] -> [(a . Int)] (define (number-list ls) (let lp ((ns '()) (ls ls)) (if (null? ls) ns (let ((x (car ls))) (lp ((fif not (lambda (_) (cons (cons x 1) ns)) (lambda (n) (set-cdr! n (add1 (cdr n))) ns)) (assq x ns)) (cdr ls)))))) ;; sort-nodes :: [(a . Int)] -> [(a . Int)] (define (sort-nodes ns) (sort ns (lambda (x y) (> (cdr x) (cdr y))))) (define (diff-nodes ms ns) (let lp ((ds '()) (ns ns)) (if (null? ns) (sort-nodes ds) (lp (let* ((n (car ns)) (m (assq (car n) ms))) (cons (cons (car n) (- (cdr m) (cdr n))) ds)) (cdr ns))))) (define (get-total-score x p) (foldr (lambda (n acc) (+ (get-score n) acc)) 0 (filter-nodes (cut p <> x)))) (define (score-loved x) (get-total-score x to?)) (define (score-loving x) (get-total-score x from?)) (define (score-between x y) (+ (score-relation (cons x y)) (score-relation (cons y x)))) (define (-> x) (display (format "~%Links from [~a]~%" x)) (iter-nodes (fif (cut from? <> x) print-node))) (define (<- x) (display (format "~%Links towards [~a]~%" x)) (iter-nodes (fif (cut to? <> x) print-node))) (define (<-> x) (display (format "~%Reciprocal links for [~a]~%" x)) (iter-nodes (fif (cut to? <> x) (lambda (n) (flip-relation n (lambda (m) (print-node m n))))))) (define (<=> x) (display (format "~%Reciprocal matches for [~a]~%" x)) (iter-nodes (fif (cut to? <> x) (lambda (n) (flip-relation n (lambda (m) (if (ormap (lambda (x) (ormap (lambda (y) (equal? x y)) (describe-relation m))) (describe-relation n)) (print-node m n)))))))) (define (<?> x) (let ((to (assq x (number-list (from-links)))) (from (assq x (number-list (to-links))))) (display (string-append (format "~%Link statistics for [~a]~%" x) (format "| ~a => ~a (love ~a)~%" x (cdr to) (score-loving x)) (format "| ~a => ~a (love ~a)~%" (cdr from) x (score-loved x)))))) (define (info x) (for-each (cut <> x) (list <- <-> <=> -> <?>))) ;;; GraphViz (http://www.graphviz.org/) support (define graphviz "C:/Program Files/ATT/Graphviz/bin/dot.exe") (define (nodes->dot ns) (string-append "digraph cute {\n" ;;"\tordering=out;\n" ;;"\trankdir=LR;\n" "\toverlap=true;\n" "\tnode[fontname=\"msgothic.ttc\"];\n" "\tedge[fontname=\"msgothic.ttc\",fontsize=9];\n" (let lp ((str "") (ns ns)) (if (null? ns) str (let* ((n (car ns)) (s (score-relation n))) (lp (string-append str (format "\t\"~a\" -> \"~a\"" (symbol->name (car n)) (symbol->name (cdr n))) (format "[label=\"~a\",color=\"~a\"," (break-string (car (describe-relation n)) 7) (cond ((> s 0) "red") ((= s 0) "green") (else "blue"))) (format "style=\"bold~a\"];\n" (if (and (not (= s 0)) (< s 1) (> s -1)) ",dashed" ""))) (cdr ns))))) "}")) (define (write-dotfile dot file) (and (file-exists? file) (delete-file file)) (with-output-to-file file (lambda () (display dot))) file) (define (dot->png dot png) (call-with-input-file (write-dotfile dot "c-ute.dot") (lambda (in) (and (file-exists? png) (delete-file png)) (call-with-output-file png (lambda (out) (run graphviz "-Tpng" in out))))) 'done) ;;; Setup database ;; Based on: ;; http://ex23.2ch.net/test/read.cgi/morningcoffee/1188654905/116-142 (begin (relate 'maimi 'erika "大好き" 1) (relate 'maimi 'kanna "良き妹" 1) (relate 'maimi 'airi "良き妹" 1) (relate 'maimi 'mai "姉妹" 0) (relate 'erika 'maimi "一番可愛いよ" 1) (relate 'erika 'kanna "仲間" 0) (relate 'erika 'chisato "おソロパジャマ" 0) (relate 'kanna 'erika "仲間" 0) (relate 'kanna 'maimi "好き" 1) (relate 'kanna 'saki "喰ってやるよ" 1) (relate 'kanna 'mai "喰ってやるよ" 1) (relate 'kanna 'airi "大好き" 1) (relate 'kanna 'chisato "愛理に手出すんじゃねぇよ" -1) (relate 'saki 'maimi "荷物整理" 0) (relate 'saki 'erika "彼氏にしたい" 1) (relate 'saki 'kanna "興味がある" 0.5) (relate 'saki 'chisato "愛理に手出すんじゃねぇよ" -1) (relate 'saki 'airi "好き" 1) (relate 'airi 'kanna "受け入れる" 1) (relate 'airi 'chisato "最近親密" 1) (relate 'mai 'erika "保護者" 0) (relate 'mai 'maimi "姉妹" 0) (relate 'mai 'chisato "恋人" 1) (relate 'chisato 'erika "おソロパジャマ" 0) (relate 'chisato 'mai "恋人" 1) (relate 'chisato 'airi "最近親密" 1)) ;; query relations / draw graphs (if (file-exists? graphviz) (dot->png (nodes->dot (ordered-pairs)) "c-ute.png") (for-each info (all-members)))
Graphviz というソフトによって関係図を可視化できる、ということを教えていただきました（既に上プログラムを実行すると自動的に関係図画像を作成するようにしてあります）。ここでは技術的な観点から幾つか注意点を挙げておきます。
まず、Scheme プログラムから Graphviz を動かす方法について。コマンドラインからの起動のように、プログラムへのオプション文字列で入出力ファイルを指定する方法ではどうも上手く行きませんでした。調査の結果、入出力ファイルのポートを Scheme 側で用意しておく必要があるようです。処理系によって異なりますが、PLT Scheme の場合 subprocess という関数を次のように呼び出します。
(subprocess output-port input-port #f "/path/to/dot.exe" "-Tpng")
ここで output-port は png 等画像ファイルへの出力ポート。input-port は dot ファイル（グラフの定義ファイル）の入力ポートです。エラーポートは必要無いでしょう (#f)。
dot という名前の実行ファイルが、関係図のような有向グラフを描画するプログラムです。最後にオプション文字列として出力形式を指定します（png, jpeg, gif, etc.）。
次に dot ファイルを Scheme で書く方法ですが、以下の基本的な有向グラフの書式
digraph g {
A -> B;
B -> C;
C -> A;
}
を理解すれば、後は実直に Scheme のデータを当てはめて format 関数等で変換するだけです。
(string-append "digraph g {" (format "~a -> ~a;" (car node) (cdr node)) "}")
問題は、ノードを配置する順番によって出来上がる画像が変わってくる、ということです。
より見た目に分かりやすくするための工夫としては、相互にリンクするノード同士が dot ファイル上でも近接して出力されるようにすると良いでしょう。関連の強いものが画像の上でも近くに表示されるようになります。
また上述（特に例３）のスコアの概念を応用し、スコアの低いものが後に出力されるようにすることで、重力感覚に一致するような関係図を得ることができるでしょう。
ならばそれは起るべくして起ったのであって、別段問題ではないように思うのだけれど。
たとえ外部から貧弱に見えようとも、それで当事者たちが困っていないのなら、それは貧弱なのではなく最適化されていると考えるべきだと思う。
例えば、文化によって虹の色数は違うし、色自体の概念も異なっているというのは有名な話だけれども（極端な話、かつての日本の「赤」と、英語の「RED」が同じであったとは思えないように）、そこに何らかの色が欠けているからといって貧弱とは言い得ない。現在のPCでの色表現は普通一色素あたり8ビットを使っているけれど、これが128ビットになったところで、ぶっちゃけ視覚的に大した差はないだろう。こういうのをリソースの無駄という。
同じように、たとえ外部から見てボキャ貧に見えても、彼らにとってそれは必要十分であり得る。またそのことが必ずしも低脳を意味するわけでもない。むしろ豊富なボキャブラリを持つことが、無駄となりうることさえある。個々人が別々の環境に生きている以上、それを考慮すべきでもある。深海魚が肺を持つ必要性は何処にもない。
20070629230000改定
20070702125800バグ発見：スクリプト中にある「&&」が、「&&」になっている。増田の仕様らしい。
20070827224900改定
// ==UserScript== // @name anond pickup // @namespace http://anond.hatelabo.jp/20070608230645 // @description pickup trackback tree top section at Hatelabo::AnonymousDiary // @include http://anond.hatelabo.jp/* // ==/UserScript== (function() { var threshold_bm = 1; var threshold_tb = 1; var ignoreList = { "/20070801172335": 33, "/20070806163721": 10, }; var firstPager_l = document.evaluate("//div[@class='pager-l']",document,null,XPathResult.FIRST_ORDERED_NODE_TYPE,null).singleNodeValue; function Hide(){} Hide.prototype.setup = function() { this.style = document.createElement("style"); this.style.id = "hide"; this.style.type = "text/css"; document.getElementsByTagName("head")[0].appendChild(this.style); var self = this; this.a = new Object(); this.a.visible = document.createElement("a"); this.a.visible.id = "visible"; this.a.visible.href = "#"; this.a.visible.innerHTML = "visible hide section"; // this.a.visible.setAttribute("onclick","document.getElementById('hide').innerHTML = 'div.hide {display: block}';document.getElementById('visible').style.display = 'none';document.getElementById('unvisible').style.display = 'inline';"); this.a.visible.addEventListener("click", function(){self.visible()}, false); firstPager_l.parentNode.insertBefore(this.a.visible, firstPager_l); this.a.unvisible = document.createElement("a"); this.a.unvisible.id = "unvisible"; this.a.unvisible.href = "#"; this.a.unvisible.innerHTML = "unvisible hide section"; // this.a.visible.setAttribute("onclick","document.getElementById('hide').innerHTML = 'div.hide {display: none}';document.getElementById('visible').style.display = 'inline';document.getElementById('unvisible').style.display = 'none';"); this.a.unvisible.addEventListener("click", function(){self.unvisible()}, false); firstPager_l.parentNode.insertBefore(this.a.unvisible, firstPager_l); if (GM_getValue("visible", 0)) { this.visible(); } else { this.unvisible(); } } Hide.prototype.visible = function() { this.style.innerHTML = "div.hide {display: block}"; this.a.visible.style.display = "none"; this.a.unvisible.style.display = "inline"; GM_setValue("visible", 1); } Hide.prototype.unvisible = function() { this.style.innerHTML = "div.hide {display: none}"; this.a.visible.style.display = "inline"; this.a.unvisible.style.display = "none"; GM_setValue("visible", 0); } Hide.prototype.append = function(section) { if (section.className.match(/hide/)) { return; } section.className += " hide"; } Hide.prototype.clear = function(section) { section.className = section.className.replace(/ hide/g, ""); } Hide.prototype.is = function(section) { return section.className.match(/hide/); } var hide = new Hide(); hide.setup(); var target = document.evaluate( "//div[@class='section' and child::*[not(@class='sectionfooter') and descendant::a[starts-with(@href,'http://anond.hatelabo.jp/2') or starts-with(@href,'/2') and not(child::span[@class='sanchor'])]]]", document,null,XPathResult.UNORDERED_NODE_SNAPSHOT_TYPE,null); for (var i=0; i<target.snapshotLength; i++) { hide.append(target.snapshotItem(i)); } var tbs = document.evaluate( "//p[@class='sectionfooter']/a[2]", document,null,XPathResult.UNORDERED_NODE_SNAPSHOT_TYPE,null); for (var i=0; i<tbs.snapshotLength; i++) { var tb = tbs.snapshotItem(i); if (tb.innerHTML == "\u30c8\u30e9\u30c3\u30af\u30d0\u30c3\u30af(0)") { // hide.append(tb.parentNode.parentNode); bookmark(tb, 0); } else if (! hide.is(tb.parentNode.parentNode)) { trackback(tb, 1); } else { bookmark(tb, 1); } } function trackback(tb, callback) { GM_xmlhttpRequest({ method: "GET", url: "http://anond.hatelabo.jp/" + tb.pathname.match(/\d{14}/), onload: function(result) { var link = result.responseText.match(/<a name="tb">(.|\s)*/)[0].match(/<li>\s*<a href="http:\/\/anond.hatelabo.jp\/\d{14}"/g); var n = link.length; for (var l in link) { var m = "/" + link[l].match(/\d{14}/); if (m in ignoreList) { n -= ignoreList[m]; } } if (n < threshold_tb) { tb.innerHTML = tb.innerHTML.replace(/\)$/, "/"+n+")"); if (callback) { bookmark(tb); } } else { tb.innerHTML = tb.innerHTML.replace(/\)$/, '/<span style="color: red;">'+n+"</span>)"); } } }); } function bookmark(tb, callback){ GM_xmlhttpRequest({ method: "GET", url: "http://b.hatena.ne.jp/entry/rss/http://anond.hatelabo.jp/" + tb.pathname.match(/\d{14}/), onload: function(result) { var r = result.responseText.match(/<rdf:li rdf:resource=/g); if (r && r.length >= threshold_bm){ hide.clear(tb.parentNode.parentNode); if (callback) { trackback(tb); } } else { hide.append(tb.parentNode.parentNode); } } }); } })();
今はスッキリしているのは古いやつ
/// ==UserScript== // @name anond pickup // @namespace http://anond.hatelabo.jp/20070608230645 // @description pickup trackback tree top section at Hatelabo::AnonymousDiary // @include http://anond.hatelabo.jp/*?page=* // ==/UserScript== (function() { var target = document.evaluate( "//div[@class='section' and child::*[not(@class='sectionfooter') and descendant::a[starts-with(@href,'http://anond.hatelabo.jp/2') or starts-with(@href,'/2') and not(child::span[@class='sanchor'])]]]", document, null, XPathResult.UNORDERED_NODE_SNAPSHOT_TYPE, null); for(var i=0; i<target.snapshotLength; i++) { target.snapshotItem(i).style.display = "none"; } var trackback = document.evaluate( "//p[@class='sectionfooter']/a[2]", document, null, XPathResult.UNORDERED_NODE_SNAPSHOT_TYPE, null); for(var i=0; i<trackback.snapshotLength; i++) { if (trackback.snapshotItem(i).innerHTML == "\u30c8\u30e9\u30c3\u30af\u30d0\u30c3\u30af(0)") { trackback.snapshotItem(i).parentNode.parentNode.style.display = "none"; } else if (trackback.snapshotItem(i).parentNode.parentNode.style.display != "none") { count(trackback.snapshotItem(i)); } } function count(tb) { GM_xmlhttpRequest({ method: "GET", url: "http://anond.hatelabo.jp/" + tb.getAttribute("href").match(/[0-9]{14}/), onload: function(result) { var n = result.responseText.replace(/\n/g,"").match(/<a name="tb">.*/)[0].match(/<li>/g).length; if (n < 10) { tb.innerHTML = tb.innerHTML.replace(/\)$/,"/"+n+")"); } else { tb.innerHTML = tb.innerHTML.replace(/\)$/,'/<span style="color: red;">'+n+"</span>)"); } } }); } })();
今時font color=""はなぁと思って書いてみたら妙に長くなってしまった。我ながらなんという資源の無駄。日付を手打ちしてるなら、むしろ日付全体を生成するほうが全然楽だけど、一応この形で足掻いてみた結果。コメント入れまくってるから省けば多少は見やすくなるかもよ。
なお文書内のh1は全て同一フォーマットの日付であることが前提。形式は多少変わってもOKで、右から何文字目が曜日かって部分だけを書き換えれば動くはず。
<html> <head> <title>曜日テスト</title> <style type="text/css"><!-- span.sun{ /* 日曜日 */ color: red; } span.sat{ /* 土曜日 */ color: blue; } --></style> <script type="text/javascript"><!-- // 日付フォーマット中、右から何文字目が曜日か（曜日1文字の場合にしか対応してない） var DAY_POSITION_FROM_RIGHT = 2; /* * <h1>yyyy年mm月dd日（曜）</h1> を * <h1>yyyy年mm月dd日<span class="xxx">（曜）</span></h1> に変換する。 * onloadで実行して塗り替え。 */ function colorDay(){ var targetList = document.getElementsByTagName("h1"); // h1要素のリストを取る for(i=0; i<targetList.length; i++){ // h1の数だけぶん回す // h1の中身を三枚に下ろす（左側、曜日部分、右側） var nodeValue = targetList[i].firstChild.nodeValue; // h1の子であるテキストノードの値（日付）を取る var nodeValueLeft = nodeValue.substring(0,nodeValue.length - DAY_POSITION_FROM_RIGHT); // 左側 var day = nodeValue.charAt(nodeValue.length - DAY_POSITION_FROM_RIGHT); // 曜日 var nodeValueRight = nodeValue.substring(nodeValue.length - DAY_POSITION_FROM_RIGHT + 1, nodeValue.length); // 右側 var dayType = ""; // 曜日に付与するクラス名を算出（平日なら空） if(day == "日"){ dayType = "sun"; } else if(day == "土"){ dayType = "sat"; } var dayObj = document.createElement("span"); // 曜日を入れるspanノードを生成 dayObj.appendChild(document.createTextNode(day)); // 中身文字列は三枚の真ん中（曜日） dayObj.className = dayType; // クラスを付与 // h1の中身作り直し targetList[i].firstChild.nodeValue = nodeValueLeft; // 元々の値を三枚の左側部分のみにする targetList[i].appendChild(dayObj); // その後ろに作った曜日のspanを足す targetList[i].appendChild(document.createTextNode(nodeValueRight)); // その後ろに三枚の右側を足す } } //--></script> </head> <body onload="colorDay();"> <h1>2007年05月25日（金）</h1> <h1>2007年05月26日（土）</h1> <h1>2007年05月27日（日）</h1> <h1>2007年05月28日（月）</h1> </body> </html>
anond:20070218150508のあと、 機能変更、お知らせなど - はてなブックマーク日記 - 3/19(月) のはてなブックマークのメンテナンスについて とかあったので、変化を調べてみた。
% diff resolve.old resolve.txt | grep '[<>]' | sort < 125.206.202.66: mgw.hatena.ne.jp. < 61.196.246.69: b.hatena.ne.jp. < 61.196.246.70: b.hatena.ne.jp. > 59.106.108.71: mgw.hatena.ne.jp. > 59.106.108.72: b.hatena.ne.jp.
?Bの他、関連のmgwも。着々と移転は進む。次はcounter辺りだろうか、それとも？Gとかだろうか。何にせよ、？Dの移転が最大の山場でしょうな。
以下メモ。
% dig -f host.txt | grep '^[^;]' | awk '{print $5, $1}' | sort | uniq | sed 's/ /: /' > resolve.txt
host.txt
a.hatena.ne.jp anond.hatelabo.jp b.hatena.ne.jp counter.hatena.ne.jp d.hatena.ne.jp f.hatena.ne.jp g.hatena.ne.jp graph.hatena.ne.jp hatelabo.jp hatena.ne.jp i.hatena.ne.jp mail.hatelabo.jp map.hatena.ne.jp mgw.hatena.ne.jp mobile.hatena.ne.jp music.hatelabo.jp q.hatena.ne.jp r.hatena.ne.jp red.hatena.ne.jp red3.hatena.ne.jp rimo.tv ring.hatena.ne.jp screenshot.hatena.ne.jp search.hatena.ne.jp searchplus.hatelabo.jp serif.hatelabo.jp sns.hatelabo.jp sv.hatelabo.jp sv.hatena.ne.jp wordlink.hatelabo.jp world.hatelabo.jp www.hatelabo.jp www.hatena.ne.jp
resolve.txt
125.206.202.66: graph.hatena.ne.jp. 125.206.202.66: i.hatena.ne.jp. 125.206.202.66: map.hatena.ne.jp. 125.206.202.66: q.hatena.ne.jp. 125.206.202.82: search.hatena.ne.jp. 125.206.202.83: d.hatena.ne.jp. 216.52.184.230: dns2.name-services.com. 219.99.160.180: ns0.future-s.com. 219.99.160.181: ns1.future-s.com. 221.186.129.146: d.hatena.ne.jp. 221.186.129.147: counter.hatena.ne.jp. 221.186.129.147: ring.hatena.ne.jp. 221.186.129.148: g.hatena.ne.jp. 221.186.146.26: mail.hatelabo.jp. 221.186.146.26: sv.hatena.ne.jp. 221.186.146.27: hatena.ne.jp. 221.186.146.27: www.hatena.ne.jp. 221.186.146.28: a.hatena.ne.jp. 221.186.146.28: anond.hatelabo.jp. 221.186.146.28: hatelabo.jp. 221.186.146.28: music.hatelabo.jp. 221.186.146.28: searchplus.hatelabo.jp. 221.186.146.28: serif.hatelabo.jp. 221.186.146.28: sns.hatelabo.jp. 221.186.146.28: sv.hatelabo.jp. 221.186.146.28: wordlink.hatelabo.jp. 221.186.146.28: world.hatelabo.jp. 221.186.146.29: d.hatena.ne.jp. 59.106.108.67: red.hatena.ne.jp. 59.106.108.67: red3.hatena.ne.jp. 59.106.108.68: mobile.hatena.ne.jp. 59.106.108.69: f.hatena.ne.jp. 59.106.108.70: rimo.tv. 59.106.108.71: mgw.hatena.ne.jp. 59.106.108.72: b.hatena.ne.jp. 61.196.246.67: d.hatena.ne.jp. 61.196.246.68: r.hatena.ne.jp. 61.196.246.68: screenshot.hatena.ne.jp. 63.251.92.193: dns3.name-services.com. 64.74.96.242: dns4.name-services.com. 69.25.142.1: dns1.name-services.com. 70.42.37.1: dns5.name-services.com. dns1.name-services.com.: rimo.tv. dns2.name-services.com.: rimo.tv. dns3.name-services.com.: rimo.tv. dns4.name-services.com.: rimo.tv. dns5.name-services.com.: rimo.tv. ns0.future-s.com.: hatelabo.jp. ns0.future-s.com.: hatena.ne.jp. ns1.future-s.com.: hatelabo.jp. ns1.future-s.com.: hatena.ne.jp. sv.hatelabo.jp.: www.hatelabo.jp.
Dude！
それがカルトだっていうんだ！
そんなに教祖様が好きなら、自分のおケツに寵愛でもなんでもしてもらえばいいさ！
マジメに考えて損した！アンタまったくイケてないよ！！
冗談はさておき、もしキミの質問が釣りじゃないのなら、アニメ「サウスパーク」のいくつかのエピソードがキミの悩みに大して重要な示唆を与えてくれると思う。
残念ながら、ぜひ観て欲しいシリーズ5以降のDVDが日本では発売されていないのだけれど、もしニコニコ動画のアカウントを持っているなら、幸いなことにファンサブ(字幕）付動画を見ることができる。（ファンサブの善悪についてはこの際議論しない）
シリーズ5第4話「Super Best Friends」
シリーズ6第8話「Red Hot Catholic Love!」
シリーズ7第12話「All About the Mormons?」
シリーズ8第4話「The Passion of the Jew」
シリーズ9第7話「Erection Day」
シリーズ9第12話「Trapped in the Closet」
シリーズ10第1話「The Return of Chef」
こいつは一見本当にふざけたアニメだが、キミの真面目な性格でもって、そのエピソードの真意を汲み取ってくれたら、今後の人生にとって役に立ってくれるに違いないだろう。
久しぶりにwhoisなんて使ったかもんだから。
inetnum: 59.106.0.0/16 (59.106.0.0 - 59.106.255.255) netname: SAKURA inetnum: 59.106.108.64/26 (59.106.108.64 - 59.106.108.127) netname: HATENA 59.106.108.67: red.hatena.ne.jp red3.hatena.ne.jp 59.106.108.68: mobile.hatena.ne.jp 59.106.108.69: f.hatena.ne.jp 59.106.108.70: rimo.tv inetnum: 61.192.0.0/13 (61.192.0.0 - 61.199.255.255) netname: JPNIC-NET-JP inetnum: 61.196.246.64/29 (61.196.246.64 - 61.196.246.71) netname: HATENA 61.196.246.67: d.hatena.ne.jp 61.196.246.68: r.hatena.ne.jp screenshot.hatena.ne.jp 61.196.246.69: b.hatena.ne.jp 61.196.246.70: b.hatena.ne.jp inetnum: 125.200.0.0/13 (125.200.0.0 - 125.207.255.255) netname: OCN inetnum: 125.206.202.64/29 (125.206.202.64 - 125.206.202.71) netname: HATENA inetnum: 125.206.202.80/29 (125.206.202.80 - 125.206.202.87) netname: HATENA 125.206.202.66: graph.hatena.ne.jp i.hatena.ne.jp map.hatena.ne.jp mgw.hatena.ne.jp q.hatena.ne.jp 125.206.202.82: search.hatena.ne.jp 125.206.202.83: d.hatena.ne.jp inetnum: 221.184.0.0/13 (221.184.0.0 -221.191.255.255) netname: OCN-JPNIC-JP inetnum: 221.186.129.144/29 (221.186.129.144 - 221.186.129.151) netname: HATENA inetnum: 221.186.146.24/29 (221.186.146.24 - 221.186.146.31) netname: HATENA 221.186.129.146: d.hatena.ne.jp 221.186.129.147: counter.hatena.ne.jp ring.hatena.ne.jp 221.186.129.148: g.hatena.ne.jp 221.186.146.26: sv.hatena.ne.jp mail.hatelabo.jp 221.186.146.27: hatena.ne.jp www.hatena.ne.jp 221.186.146.28: a.hatena.ne.jp hatelabo.jp anond.hatelabo.jp music.hatelabo.jp searchplus.hatelabo.jp serif.hatelabo.jp sns.hatelabo.jp wordlink.hatelabo.jp world.hatelabo.jp sv.hatelabo.jp (www.hatelabo.jp) 221.186.146.29: d.hatena.ne.jp
[追記]