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

また更新しました。Grieverさんのコメントを私なりに生かそうとしています。
アイテム: Generic Posts Rule - データベース: AutoPagerize - wedata

今日もGrieverさんからのコメントにお答えします。

関連記事を取得したくないのではなく、関連記事を取得しそうな場合は AutoPagerize を動作させないという意図ですよね?

wedata:400でcount()を使用した意図 その2 - 1300

そもそもsiteinfoの作成に関しては優先順位をつけています。通常通り機能できればベストですが、ワーストはsiteinfoの適用によりデザインが崩れる場合です。ダミーコードが必要になるような事態は極力避けたいですね。
tanyao.hatenadiary.jp
サイトデザインの崩壊が想定される場合は機能自体を避けるべきだと考えています。機能はしませんがその分悪影響もありません。ベターと言えるでしょう。表にしておきます。

機能 優先順位
通常どおり機能 1
機能しない 2
誤ったsitienfoが機能(デザインの崩壊) 3

count()を使用したのはワーストの3を回避しベターの2にするためです。ご指摘のcaseAに関しては.sub側(サイドバー)のノードが適用されるのを避けて、機能自体をしないようにしています。もしサイドバー側へ適用されれば、デザインが崩れダミーコードが必要になる可能性が高いからです。
codepen.io
当然ながら通常通り機能させたいのはやまやまですが、下手に弄ればどう転ぶものかと腰が引けています。まず最初にここから説明するべきだったのかもしれません。

追記

なんとかもっとわかりやすくできないかと弄っていたのですが、こういうケースで異常動作を防げない事に気が付きました。
codepen.io
count(//*[./article[starts-with(@id,"post-")]])=1で条件式のチェックを通ってしまいます。どうしたものでしょうか。

追記2

なんとか対応したつもりです。これだけ頭を使うのは久しぶりですね。
http://wedata.net/items/400?rev=154714

追記3

Grieverさんからこのエントリにコメントをいただきました。

数える対象を間違えている気がします。
取得するのは『article が複数ある場合』なので数えるべきは『article を複数もつ親』では無いでしょうか?

テストケースと『article を複数もつ親』が複数ある場合は動作しない例を用意しました。
https://codepen.io/Griever2/pen/YzqGNNQ

wedata:400でcount()を使用した意図 その4 - 1300

ありがとうございます。これだけ多くのテストケースを書かれている労力を考えると私より大変な思いをされている気がします。お疲れさまです。

articleとidの関係が2倍で取得する場合の条件式をより厳しくしました。
アイテム: Generic Posts Rule - データベース: AutoPagerize - wedata
article 4 id 2やarticle-id 4 article 2に関してはこれで対応できるはずです。問題はEntry + subとEntry 非 article + subですね。少しだけ覚悟を決める時間をください。

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

よく考えてみると、現状の私案だとこういうケースに対応できない事実に気が付きました。Grieverさんはこれにも対応させたいのかもしれません。
codepen.io
多野さん案なら対応可能なはずです。

どうしたものでしょうか。アイデアをお持ちの方はぜひ教えて下さい。とりあえずいい考えが浮かぶまでは、誤って動作させるのが怖いので現状を維持しようと思います。

追記

更新しました。また長くなりましたがこれなら上記のケースもどうにかなりそうです
アイテム: Generic Posts Rule - データベース: AutoPagerize - wedata

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

前回のエントリにGrieverさんからコメントを頂きました。

前回の記事も読ませていただいきましたが、私は items/400 は 2 パターンだと解釈しています。
(//article | //*[starts-with(@id, 'post-')]) と id('content')/div[contains(@class,'post')] ですね。


article も starts-with(@id, 'post-') も単体ではどこにマッチするかわかりませんが、兄弟が複数存在する場合に限定することで「記事一覧」にマッチするように仕組まれています。(ときどき個別記事の関連記事一覧を取得して誤爆していますが…)
実際に div[@id='post-1234'] や article[@id='post-1234'] のような使われ方のページが非常に多く、区別する必要がないと思っています。


id('content')/div[contains(@class,'post')] は別パターンですが一応 div を数えて複数存在する場合に動作させようという意図が見えます。


この「複数存在する場合」という条件が Generic Post"s" Rule の要だと思います。


また重複を気にされてますが、同じ要素を二重に取得するわけではないので重複しても問題ないですが…。

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

さきほどupdateを行いました。しつこいようですがこれしかできません。
http://wedata.net/items/400?rev=154703

コメントありがとうございます。//articleと//*[starts-with(@id,"post-")]のいずれか、あるいはこの重複に適用されるかを明確にしなければどこに適用されるか怖いと思うのですが…単に私が小心者なだけでしょうか。

exampleUrlを5ケースに分離したのはそれなりに意義があると言わせてください。なぜ骨を折ったのかと悲しくなります。機能上は構わないのかもしれませんがexampleUrlを整理したのが無駄とは考えたくありません。

同一階層内に複数存在するかどうかの見落としに関しては、完全に私のミスです。親ノードから見てこんな条件式を付け加えました。

count(./article)>1 or count(./*[starts-with(@id,"post-")])>1

一応提示していただいたテストケースには対応しているようです。まだおかしな点があれば遠慮なくおっしゃってください。

追記

以下の条件式で適用を回避したいケースを簡単に書きました。意図が伝わるでしょうか。

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

codepen.io

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


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

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

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

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

[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ならパターン2、count(//*[starts-with(@id,"post-")])=0ならパターン1です。

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

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

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

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

何切る

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

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

東一局2巡目親
46679m34479p59s北北

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

なお、俺が切ったのは9m。ドラの9sを切ってもいい。その2つ以外は俺的にはない。

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

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

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

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

466799m34479p9s北北

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

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

wedata:400のexampleUrlを分割した

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

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

//article

パターン2

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

パターン3

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

この3つですね。ならば3つに分ければいいのではと思われるでしょうが、重複を考慮する必要があります。具体的には1と2、2と3が両者とも同時に適用される可能性がありますから計5パターンの分岐が存在します。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(パターン1)とexampleUrl_b(パターン2)の重複、exampleUrl_eがexampleUrl_b(パターン2)とexampleUrl_d(パターン3)の重複です。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