wedata:400でcount()を使用した意図


>単一の article 要素まで取得しているのは意図的なんでしょうか？
完全にミスです。すみませんでした。

そもそもなぜ手を入れたかですが、多野さん(Tanookirby)が自分の編集案（rev=153802）を強く押すのであれば、私は手を入れるつもりはありませんでした。しかし結果的に多野さんは村雨さん(apuser4)のロールバックを受け入れています。

これを見て400の管理に対して情熱を失っていると判断しました。そこで私なりに多野さんの意図を引き継げるよう解釈して分かりやすくシンプルにできないかやってみたのですが、難しいですね。

count()を使用した意図としては、誤って適用されるのを防ぐため前回説明したパターン１とパターン２、そしてその重複の３パターンいずれに適用するかを明確にしたいです。当初の条件式はこうでした。

[count(//article)=count(//*[starts-with(@id,"post-")]) or count(//article)=0 or count(//*[starts-with(@id,"post-")])=0]

count(//article)=count(//*[starts-with(@id,"post-")])なら重複、count(//article)=0ならパターン２、count(//*[starts-with(@id,"post-")])=0ならパターン１です。

これに今日以下の条件を付け加えています。

count(//article)=count(//*[starts-with(@id,"post-")])*2

85453を見て//article[starts-with(@id,'post-')][count(.//article)=1]へ対応したいと考えました。
アイテム: VOZ Next - データベース: AutoPagerize - wedata
本来適用されるべきでないケースに偶然適用される可能性も考えられますが、この程度なら大丈夫だろうと判断しています。

以上です。結果多野さん案よりごちゃごちゃしていますね。力量不足です。

何切る

Twitterが凍結されてしまって手持ち無沙汰なので、麻雀の話をします。

福地先生のnoteで見かけました。ドラは9sです。

東一局２巡目親
46679m34479p59s北北

ここから北を切って、その理由がタンヤオ。すごすぎるわ(;・∀・)　最初から俺の想像力の範疇からは絶対に出てこない答えだった。

なお、俺が切ったのは９ｍ。ドラの９ｓを切ってもいい。その２つ以外は俺的にはない。

ふんわり勢の麻雀観｜福地誠「現」天鳳名人位｜note

「その２つ以外は俺的にはない。」と福地先生はおっしゃっていますが、私なら5sや4pを候補に入れたいです。ブロックは足りていますし456や345の三色は少し苦しいはずです。

一人麻雀練習機の結果です。5sが期待値最大で、その次が9mです。4pは下から２番目かあ。4pはともかく5sは打牌候補として、十分に可能性があると言って構わないのではないでしょうか。

結果論ですがもし5s切りだと、次順9mツモで

466799m34479p9s北北

この牌姿です。ここから4m切りで本譜より戦えそうな気がします。

個人批判するようでやはり何切るは苦手ですね。麻雀の話をするなら、もっと別のやり方を考える必要がありそうです。

wedata:400のexampleUrlを分割した

wedata.net
まだ他のコーダーの皆さんに受け入れられるかわかりませんが、意図を書いておきます。

pageElementを基準に分割しています。以前述べたように、400のpageElementはざっくり３つに大別されます。
tanyao.hatenadiary.jp
パターン１

//article

パターン２

//*[starts-with(@id,'post-')]

パターン３

id('content')/div[contains(@class,'post')]

この３つですね。ならば３つに分ければいいのではと思われるでしょうが、重複を考慮する必要があります。具体的には１と２、２と３が両者とも同時に適用される可能性がありますから計５パターンの分岐が存在します。XPathで書くと
exampleUrl_a

//article

exampleUrl_b

//*[starts-with(@id,'post-')]

exampleUrl_c

//article[starts-with(@id,'post-')]

exampleUrl_d

id('content')/div[contains(@class,'post')]

exampleUrl_e

id('content')/div[starts-with(@id,'post-')][contains(@class,'post')]

こんな感じです。exampleUrl_cがexampleUrl_a（パターン１）とexampleUrl_b（パターン２）の重複、exampleUrl_eがexampleUrl_b（パターン２）とexampleUrl_d（パターン３）の重複です。nextLinkに関してはまったく考慮していません。

従来通りだと多すぎて管理に支障が出ると判断しました。かなりの数を削除しています。見落としがあるかもしれません。

wedata:650のアイデア 

//*[contains(@class,"hentry") or contains(@class,"h-entry")][not(./following-sibling::* or ./preceding-sibling::*)]/ancestor::*[./following-sibling::* or ./preceding-sibling::*][1][count(//*[contains(@class,"hentry") or contains(@class,"h-entry")])>1]

http://plsk.net/wedata_650_idea
wedata.net
gist.github.com
codepen.io

アンカーリンクの生成

r.gnavi.co.jp

頼むからアンカーリンクをつけてくれ！！

tenjinjinのブックマーク / 2020年7月29日 - はてなブックマーク

対応しているのはChromeのみですが、こちらの方法でページ内リンクを生成しました。
www.suzukikenichi.com
【（各都道府県名）】の箇所にリンクを貼っています。DOMノードの関係で大阪は諦めました。近隣の都道府県から飛んでください。

北海道
青森
岩手
宮城
秋田
山形
福島
茨城
栃木
群馬
埼玉
千葉
東京
神奈川
新潟
富山
石川
福井
山梨
長野
岐阜
静岡
愛知
三重
滋賀
京都
兵庫
奈良
和歌山
鳥取
島根
岡山
広島
山口
徳島
香川
愛媛
高知
福岡
佐賀
長崎
熊本
大分
宮崎
鹿児島
沖縄

Generic Posts Rule pageElement(wedata:400)を解説？


お役に立つとは思えませんが他にも気になっている方がいるかも知れません。私なりにごく簡単な解説を入れます。

(//article[not(contains(../@class,'widget'))][not(contains(@class,'columns four'))][not(contains(@class,'side-contents'))][not(ancestor::*[starts-with(@class,'sidebar')])][not(ancestor::*[contains(@class,'featured') and not(self::body)])]|//*[starts-with(@id,'post-')][not(contains(@id,'nav'))][not(contains(@id,'post-rating'))])[not(.//*[contains(@class,'admz')])][not(self::h2)][not(self::h3)][not(ancestor::*[@id='side' or @class='pickup'])][not(ancestor::aside)][not(id('load-more-posts') or @id='fpost' or contains(@class,'carousel'))][parent::node()[not(@id='side')][not(contains(@class,'thumbnail'))][not(following-sibling::*[not(@id='side')][article or *[starts-with(@id,'post-')]])]/*[self::article or starts-with(@id,'post-')]/following-sibling::*[self::article or starts-with(@id,'post-')][not(contains(@id,'nav'))]]|id('content')[count(div)>1]/div[contains(@class,'post')][not(contains(div/@class,'breadcrumb'))][not(contains(div/@class,'nav'))]

とんでもなく長いXPathですが構造自体はそれほど複雑ではない…はずです。多分。条件式を省いていけば

//article
//*[starts-with(@id,'post-')]
id('content')/div[contains(@class,'post')]

の３つです。実際に更新履歴から２０１６年の原型をたどると
http://wedata.net/items/400?rev=140619

(//article|//div[starts-with(@id,'post-')])[not(id('load-more-posts') or ancestor::article or ancestor::*[starts-with(@id,'post-') or @id='fpost'])]|id('content')/div[contains(@class,'post')]

これくらいならかわいいものですね。（メガトン構文で）前述したようにここから多野さん（Tanookirby）はデザインへの影響を抑える目的で複雑な条件式を付け加えざるを得ませんでした。その努力の結果、影響は最小限に抑えられています。現状は400の存在を前提にsiteinfoの管理が行われています。

つまりは400のXPathを下手に削ればデザインへ影響が出る可能性が高く、400自体を削除すれば機能しないサイトが大量に出ます。

現状がそれほど問題だとは思っていません。400へのダミーコードはGrieverさんのおかげで２つまでに減りました。*1もし不具合のあるサイトがあれば教えてほしいですが、実用上は拡張側の設定で各個URLを無効化してしまえば十分でしょう。

以上です。意欲のある方は頑張ってください。

*1:2020.7.21現在は３つです