受信実体。†

これ自体は、実は大した課題はありませんでした。

pukiwikiの仕組み上、受信をプラグインで行う方針にした時点で 「普通の action処理」とあまり差がなく。
実施内容も「要求元URLがフェイクでないことを確認」する以外は、単に受信内容を保存するだけです。

受信したデータ領域に「任意」フィールドがいくつかあるのが問題ではありますが。
任意である以上、こちらも「無いなら無いなり」のルールでいいわけです。

受信後の管理処理†

使い方を考えたとき、トラックバック受信はどちらかというと 『受信結果をどうコントロールするか』のほうが重要、という結論に至りました。
ユースケースを整理した結果、以下のような機能を作ることにしています。

• 当該ページへの「トラックバック件数」がひと目でわかる機能。
  • イメージ：各ページのどこか、たぶんフッターのほうで、「Trackback xx件」というような表示ができる。
  • スキンから呼び出されて、対応するhtmlを出力するような仕組みがいる。
• 当該ページへの「トラックバック詳細」が一覧でわかる。
  • イメージ：上記「件数」からリンクされているページで、表として示す。
    • ポイント：以上の２つについては、「受信したけど承認されていない要求」は対象外にする必要がある。
• 当該ページへの「トラックバック要求全て」を管理するような仕組みがいる。
  • 上記「トラックバック詳細」に近いが、「要求の承認」「削除」ができる。
  • 管理者限定にすべき。
• pukiwiki全体での「トラックバック受信状況の一覧」を示す。
  • イメージ：「トラックバックを受けたページへのリンク」を時刻順にソートして表表示。

わかりますよね。
トラックバックスパムを考慮すると、受けたトラックバックを無条件に受け入れるのは問題あるので。

• 受信したら「未承認」状態で保存
• 後で管理者が「承認」か「破棄」する。
  • 「承認」されるまでは、管理者以外からは「トラックバックなんてない」ようにふるまう。
• トラックバックは個別ページにたまる。
  
  • 管理者といえども全てのページを１つずつチェックなんてできないので。
    どこかで「最近トラックバックを受けた」ことを一覧的にチェックしたい。

という感じなわけです。

結果

• 通常の「特定ページへのトラックバック」一覧作成表示
• 管理者用「特定ページへのトラックバック」一覧作成表示
  • 含：管理者用の承認・削除アクション
• 管理者用「全ページのトラックバック」一覧作成表示

・・・という４つの表示系が必要になってます。

めんどくさい（笑）

1点懸念：rssモード。†

上記の「一覧」の延長ともいえるのが、rssモード。
当該ページ＆それに対するトラックバックのリストを、rssで取得できるようにする、というもの。

これはトラックバック仕様で定義されているものなんですが・・・description に概要を無条件に出しちゃだめ、って気づきまして。
pukiwiki で read禁止にしているページのデータも出ちゃうんだよな。

あえて出さない、という選択肢もあるかも。

ご意見などがあれば。

• なんか調べてると、トラックバックの_rssモードって廃止されているっぽい。なんか頭を使って損した気がする（笑） -- ともせ％管理人。 2017-02-23 22:41:02 (木)
• あ〜。でもよく考えたら、通常のrss でも似たような問題あるのか＞非公開ページでも一部見えちゃう。
  どうしようかな。 -- ともせ％管理人。 2017-02-22 06:42:03 (水)

とりあえず†

インラインプラグイン形式に変更実施しました。

送信まわり†

できていなかった、以下の部分の作成をしました。

• 送信する title, excerpt 部分の対応。
  • 先日の記事に書いた通り、ページ情報生成用のプラグインを作りました。
• トラックバックpingの取得処理詳細化。
  • rdf書式の解析処理の見直しですね。
• 結果通知の解析＆表示処理
  • 要求にNG返答だった場合に、プラグイン内にエラー系の情報を埋め込むようにしました。

受信のための情報表示†

人間の目には見づらいのですが、基本的にすべてのページにおいて以下の情報を埋め込む必要があります。

• rdfファイル
  • 他サイトに対するトラックバックping情報。
    コメントなのでページ詳細表示しないと見えません。
• そのページのトラックバック情報表示＆詳細ページへのリンク
  • 各ページの一番下にある「Trackback(0)」というようなリンク。

この２つの生成アルゴリズムの作成中。

一応両方とも作ってあるのですが、まだ「ｘ件あり」部分はこれから。

とりあえずそんな感じ。

ご意見などがあれば。

まず、目的に立ち戻る。†

トラックバックでは、トラックバック元からトラックバック先に対して、以下の情報を送ることになっています。

引用元：http://pentan.info/doc/trackback.html

そのうち、blog_name や url には疑問・問題もないのですが。
title, excerpt は、どうすべきか考慮の余地があります。

title について†

例えば友瀬のこの日記ページ。
このページの左にある最新履歴から見ればわかるように、ページタイトルは

日記/yyyy-mm-dd

・・・という形式になっています。
これは pukiwiki にあるカレンダー系のプラグインを使うと自然とそうなります。
そして pukiwiki という「wiki理念のページ管理システム」としても妥当です。
「日記のページ」として作ったものなのですから。

ですが、トラックバックの意図から考えると、これを title に使うのはちょっと迷いがあります。

例えば先日の『日記/2017-02-15』というページ。
これ、pukiwiki でのトラックバック実装に関わるページなので、外部のサイト： 例えば『トラックバックの技術仕様』とか『pukiwiki開発室のトラックバック系仕様』とかのページにトラックバックを撃ってもおかしくないです。
が、もし『日記』というタイトルで撃つと、受けた上記サイト側から見るとどう思えるか。
やや、あるいは相当、不自然です。

この観点で考えると、本来送るべきタイトルは、例えば『Pukiwiki：トラックバックの検討、その２。』という日記内の見出し部分であるべき、と考えられます。

ただ逆に。
例えば左メニューにもある『Pukiwiki 関連。』というページの場合は、この『pukiwiki関連』をtitleにして、何の問題もない。
そう考えると、pukiwikiページとしてのタイトルを解析して、『日記』のような内容を反映していないページだけ特殊処理、ということが必要そうです。

excerptについて†

excerptについては、『元記事の先頭250文字程度』を機械的に切り出す、というのがデファクトになっているようです。

これ自体は、それなりに理解・納得できる仕様です。
さすがに『ソフトウェアに要約させる』なんてのは（少なくとも友瀬が細々とやっている環境では）無理。
記事として『はじめに』的な導入を書くのは割と普通なことを考えれば、それなりにリーズナブル。 ただこの仕様だと、前述の title での検討とちょっとかぶるんですね。

前述の通り、例えば日記では『見出し部分』をtitleとして抜き出しているので。
excerpt 用に先頭のほうを切り出すと、それなりの率で『見出し』も含まれてしまい、結果二重に表示している感じになる。
これはあまり格好良くない。

でもこれも前述の通り、『pukiwiki関連』のページであれば、そのまま先頭部分だけでよい。 こっちもやっぱり、ページ名に応じた処理が必要そうです。

さらに考察†

例えば、pukiwiki公式ページの質問箱。
（例 https://pukiwiki.osdn.jp/?%E8%B3%AA%E5%95%8F%E7%AE%B15/242)

これも、友瀬の「日記」と同様に、ファイル名としてのタイトルとその記事内の「実質タイトル」とがかみ合わない仕組み。
また、文章の最初には「質問の種類」に関する情報が表形式で記載されるフォーマット。

この場合、例えば

• 最初の表内の「サマリ」行を titleに。
• その先の「質問」見出しの次の行からを excerpt に。 ・・・とするのが、趣旨からすると適切に見える。

いろいろ考えた結果。†

上記事例に個別に対応することは可能ですが。
pukiwiki記事内はフリーフォーマットである以上、サイトごとに条件は違いそう。

管理者が正規表現で指示できるようにする、方法で実験中。

例えば友瀬のサイトでは、友瀬が

• 「日記/」で始まるページでは。
  • title は見出し部分。
  • excerpt は見出し直後からｘ文字。 ・・・という条件を記載する。

例えばpukiwiki質問ページについては、pukiwiki公式管理者が

• 「質問箱」で始まるページでは
  • titleは表内のサマリ行。
  • excerpt は「質問」見出し直後からｘ文字。 ・・・という条件を記載する。

というわけで、実験中のプラグインがこちら。
とりあえずそれっぽく取れているっぽい。

・・・正直めんどくさいんで。
思い切って、初めから 「タイトル」「概要」というセクションを書き込むプラグインを作ってしまう、というやり方もあるかも。

ご意見などがあれば。

方針としては？†

「送信ボタン」を押したらトラックバック送信する、プラグイン。
書式は以下のような感じ。

&tbsend(URL,text,flg);

pukiwiki プラグイン的には 〜inline()とか 〜convert() とかの動きでいうと。
URLが、接続先の記事URL。
text が表示用テキスト。これは省略可能で、その場合 URL文字列が指定されているとみなして動く。
flg はプラグインが勝手につけるもので、ユーザは意識しなくて良い。

上記のように書くと、wiki記事ページ上には以下の２要素が表示される。

• 「text」というホットスポット。クリックすれば URL のページが開く。
  • pukiwikiの下記記載と同じように見えるはず。

    [[text>URL]]

• 「Send Trackback」というボタン。押すとトラックバック送信する。 一度ボタンを押してトラックバック送信すると、プラグイン自身が自分の flgパラメータを「送信済み」状態に変更、ページをリロードする。
  「送信済み」であれば、上記「textのホットスポット」は表示されるが、「Sendボタン」は表示されなくなる。
  結果、普通に触っている限りにおいては、１つの&tbsend からは１回しかトラックバック送信しない。

トラックバックスパムの対策として、管理者認証が必要に思う。
自由編集できる wiki で「攻撃者が &tbsendを書いてping送信」できてしまうと、攻撃用に悪用されてしまうため。
管理者認証ができるかは要調査。

具体的な設計としては、既存の voteプラグインあたりを参考にしてます。
１つのページに複数置かれるとか、ボタンを押すと元画面を書き換えるとか、そういう振る舞いが近い。

ボタンを押したあとの動き詳細。†

「送る」ボタンを押したあとの処理。
pukiwiki プラグイン的には 〜action() の処理。

こんなアルゴで実装中。

1. プラグインで指定された「リンク対象のURL」を取得。
   
2. 上記URL先に接続、対象記事 Get。
   • もし当該記事がなければ、エラー。
3. 取得した記事内を解析し、rdf領域内にある「trackback:ping=xxxx」で指定されるURLを取り出す。
   • もしなければ、トラックバック未対応と判断して送らない。
4. trackback URL にtrackback ping送信。
5. ping 結果のレスポンス解析、OKかどうかチェック。
   • Okなら、前述の通り、プラグイン部分に「送信済み」フラグを反映する。
   • エラー動作は未定。

というわけで、現時点での進捗。†

実は、基本的なメカニズム部分は作成・テスト済みで、以下のようなことはできています。

• 最初の表示（URLリンクとボタン表示）処理。
• ボタンを押したあと、フラグを書き換えて「ボタン表示しない」状態になる仕組み。
  • ただ voteプラグインベースで作ったので inline ではなくブロックプラグインになっている。
    「どの位置のプラグインか」の特定処理は attachref()を参考に見直したほうがよい。
• 送信処理の基本メカニズム。
  • 実際に「はてなブログ」へのトラックバック送信には成功してます：
    そちらの記事で「トラックバック受領、承認待ち」の状態になったことを確認できた。
  • 具体的な実装としては：rdfの（簡易）解析→URL取得実施と、上記URLへの送信。
    

以下、いくつかは前述とかぶりますが、今後のToDo。

• プラグイン自体の inline()化。
  • これができないと、1行に複数のURLを書けない。
• 「送信」を管理者のみ実施可能にする。
  • これがないと、トラックバックスパムへの悪用ができてしまう。
  • 別の言い方をすると、このプラグインを置く場合には、少なくとも「特定の管理者」の定義を必須にするつもり。
• ページをincludeされた状態でのトラックバック送信への対処仕様の検討・決定
  • 例えば友瀬の日記ページのように『複数の日記をまとめて表示』するような画面がある。
    ここにおいてトラックバック送信がどう動くべきか。
  • 本質的には「元ページのURL」で送信するのが筋。
    だがたぶん「まとめたページのURL」で送ってしまうと思う。
    
    • 正直ここについては、管理者の人的責務でやるしかないと思っている。
      
• 相手サーバの trackbackping URLの解析方法の追加改善
  • 仕様上は

    『<.... trackback:ping="http://---"; ....>』

    となっているが。
    「はてな」では

    『< .... trackback:ping="http://---" ....>』

    となっていて、多少緩い。
    検索正規表現だけの話なので、やればいいだけではあるかも。
• トラックバックping 仕様自体の隙間に関わる部分への対応決定
  • 明確な定義がないので、「自分ルール」でもできちゃうけど・・・という部分。
    実際、2/15時点でのテスト版では、自分のブログ対象なのをいいことに、わりといい加減な内容で送っている。
  • 「記事概要」の文字コードについて。統一された仕様がないっぽい。
    • 例えば EUC で送っていいのか。UTF-8 MUSTなのか。
      現状友瀬の wiki がEUCなので、ちょっと悩む。
      RSSなど UTF-8で作るのが前提なので、それにあわせるのが筋っぽくはある。
  • 「記事概要」の内容。
    • 本文を250文字くらいでぶった切るのがデファクトっぽいけど、それもどうよ。
• トラックバックURLを利用者が直接指定する方式は必要か。
  • 「はてな」ではそんな感じの機能があった。
  • パラメータを指定すれば実現は簡単なので、決めるだけではある。
• 「Blog Name」の内容。
  • pukiwiki開発室談義のメモでは「システム名でいいんじゃね」的なことがあるが、ほんとにそれでいい？
    素直に「呼び出すブログの名前」じゃないのか。
    もしシステム名でよいとしても、「3rdベンダー製」であるプラグインが「pukiwiki」を名乗るのはまた問題。
• 各種通信エラーの扱い
  • 捨てちゃってもいいんだけど、残す意味があるかな。
    意味があるなら、例えば元ページのソース内にコメント形式で残す、という手は使えないこともない。
  • 「トラックバック未サポートでした」は残す意味があるかもしれない。
    • 前述の「トラックバックpingURLを直指定」の機能との兼ね合い。
      少なくとも「はてな」は（理由不明だが）rdfの自己解析をしていない節がある。
      rdf 記載なしand/or rdf解析でトラックバックpingが読み取れないようなときに、という可能性は・・・あるのかなぁ。

ご意見などがあれば。

肝となるのは、やはり魔力に応じて何ができるか、というところだと思うので。
以下のようなチットや表を使っての管理運用方法を検討してみた。

• 新しいアイテムとして、カードorチットをいくつか準備する（以下チットとして記載）。
  
  • チットは、背面からは区別がつかないもので、表面で下記の区別がつくようになっている。
  • 「移動」「攻撃」「防御」、それぞれ3個ずつ。
    
  • 「銃撃」を１つ。
  • 「行動なし」を４つ。
    • この「行動なし」は、プロットでのブラフに用いる。詳細後述。

• 通常の機動カード＆速度プロットの際に、イゼッタはこれらのチットによって「この手番に魔力をどう配分するか」もプロットする。
  • 上記のチット群から、４つを選んでコンソールに伏せておくこと。
    これによって選んだチットの数によって、そのターンのイゼッタの性能が変化する。
    
  • チットを選択する際には、以下の制限がある。
    • 「移動」「攻撃」「防御」の合計数は、その場所の魔力濃度に依存して最大量が決まる。
      通常濃度においては、最大3個。
      
    • 特定種類のチットを１つも選ばない選択は許容される。
      例えば『攻撃を一つも選ばない』こと。これは、そのターンは移動と防御に専念していることになる。
      同様に例えば『一切移動魔力を使わず、墜落しつつも銃撃する』『移動も攻撃もせずに完全防御』なども可能。
    • 前述の通り、チットは『４つ選ぶ』必要がある。
      上記濃度依存で『４つ選べない』分については「行動無しのチット」を選んで数をそろえる。
      つまり、『通常濃度』の戦闘においては基本的に「行動無し」が最低１個選ばれることになる。
    • これにより『部分的に魔力濃度が異なる』マップにおいても、魔女が力を得た/失ったということを外部からは観測しづらくなる。

• 移動に配分した魔力によって、以下のように処理する
  • 0：落下する。必ず「降下」カード。魚雷は自動的に「放棄」される
  • 1：特に制限なし。
  • 2：制限なし、かつヘビーロードの制限も無視できる。
    • 上記以外に、付随装備（魚雷や剣など）を一定数持つたびに追加トークンが必要、というような条件・方法もあるか。
• 攻撃配分
  • 0：装備攻撃は行えない
  • 1：装備攻撃1回
  • 2：装備攻撃2回
    • 『魚雷の任意移動』も、1回分にカウントする。
    • 『銃撃』をプロットした場合、銃による射撃だけが可能。攻撃配分で選んだチットは全て無視される。
      

• 防御配分
  • 0：防御行動不可
  • 1：装備による防御可能
  • 2：装備による防御＋切り払い可能

• イゼッタの魔力プロットは、実際にその行動を行うときに公開する。
  • 例えば『降下以外の機動カード』を使用したら、移動チットを公開する必要があるし、ヘビーロードなのに高速移動したら2個目の移動チットも見せないとならない。
    • これによって当該チットを見せられない場合、ただちに『降下カード』に変更すること。
  • 例えば『剣マーカーを地図上に置く（剣で攻撃する）』ときに、攻撃チットを公開する。
  • 例えば『装備防御』するなら防御チット公開。加えて『切り払い』するときには2個目の防御チットを公開。

• 魔女の石による追加処理。
  • 魔女の石は一種の燃料タンクと考え、DoWにおける『燃料』ルールに近い処理で対応する。
  • 具体的には：魔女の石を持つ魔女は、『魔力ｘ点』を事前に持った状態で戦闘開始する。
  • 石を持つ魔女は、通常ルールに従った『魔力濃度による使用可能チット数』を無視して、任意数（最大４つ）のチットを使用してよい。
    ただし、これによって余計に使ったチット１つにつき、保持している魔力１点を消費する。
    • 例えば『魔力濃度：薄い（チット１個使用可能）』の場所においても、 魔力２点を使うことで『魔力濃度普通（3個使用可能）』と同じように行動できる。
    • プレイアビリティ上、これを『魔力無限点』持ち、というやり方も許容すべきだろう。
      もともとDoWでも基本『燃料無限』でゲームをしているはず。

正直、面倒くさいことこの上ないので（笑）

こんな細かいことをせずに、魔力濃度にあわせて全体を変化、というようなやり方を標準ルールにするのでは。

ご意見などがあれば。

とりあえず、技術仕様がこちらにありました。

http://www.nurs.or.jp/~sug/mt-static/docs/mttrackback.html

これを見ると、ざっくり以下のような仕組みが必要そうです。

トラックバックを受け取る仕組み。†

1. Trackback Ping を受け取る仕組み。
   • 個々のwikiページに対応する「トラックバックURL」を作って、外部サイトはそのURLに対して情報を入れてくる。
   • 上記入力された内容を解析して、記録する仕組みがいる。
2. 「そのページへのトラックバックのリスト」を参照する仕組み。
   • 各ページの表示時に、そのページに対応する、上記で記録した「外部からの入力」のリストを拾い上げて表示する。
3. 各ページに「そのページに対応するトラックバックURL」を埋め込む仕組み。
   • rdf形式で、ソースに埋め込むだけ。
4. 受け取ったトラックバックping を一時保留する仕組み。
   • 直反映してもいいのですが、いわゆる『トラックバックスパム』への対策。
     自動的に反映するのではなく、一度受信しても『管理者承認』して初めて反映する。

トラックバックを依頼する仕組み†

1. リンク先のトラックバックURLを獲得する仕組み。
   • 上記：こちらのページに「トラックバックURLを埋め込む」のと同様に、こちらから上記「Trackback pingを送る」処理の前に、ページ解析してトラックバックURLを取り出す。
     別の言い方をすると、記事を書く友瀬は、「参照先ページのURL」だけを考えればいい。
2. Trackback Ping URLを送る仕組み。
   • リンク先のページのトラックバックURLに、Trackback ping を送信する。
   • 送信するデータは、当該ページにある各種情報。
   • 「いつ」送信するかの検討が必要。

もやっと考えるとこれくらい？

pukiwiki の場合、プラグインを使えば機能拡張は容易。
受信については専用のプラグインを作って、トラックバックURLを『専用プラグインをたたく』形式にすればたぶん大丈夫。

トラックバックURLを埋め込むには、スキンに手を入れる必要があるかな。

送信がネックになりそう：URLを書き込んだら無条件に、とかしてしまうと、スパムを飛ばしまくることになりそう。
管理者限定操作とか、pukiwiki でできるのかなぁ。

・・・あきらめて、管理者ページに「トラックバックする元ページURL」を指定して「実行」、当該ページを解析して ping用情報を生成して ping発行、とかしたほうが簡単かも。

ご意見などがあれば。

寝ている親の指で指紋ロック解除、6歳児がポケモン商品を大量購入
http://japan.cnet.com/news/society/35094384/

タイトルどおり：スマートフォンを指紋ロックしていたところ、子供が親の手を使って勝手に解除してた、という話。

ソードアートオンライン作中での『睡眠PK』の話題を思い出したよ（笑）
ともあれ、生体認証のリスクの一つだよね。これは穏便だけど、例えば『指を切り落として』なんてのはある。
それを受けて、切り落としたらダメな静脈認証などが使われているけど、それだって。
『脳味噌の中にしかないパスワード』とは、強度が違うわけだ。

ピースサインの写真から｢指紋盗難｣の恐怖
http://toyokeizai.net/articles/-/154086

続けて指紋認証まわり。写真画像の指から指紋を解析できて、指紋認証を突破されるという話。

これ、似たような話に記憶があったのですが、確かに以前に記事にしてますね＞日記/2015-06-17
1年半前の話なので、ある意味いまさらというか、本格的に可能になったというか。
ともあれ、やはり『単純に外から見える』生体認証は、所詮は『印鑑と同じ』程度のリスクはあるというところ、か。

spnxさんのオートトレーサーの性能を見たAA職人と周りの反応
https://togetter.com/li/1068562

AA（アスキーアート）を、ディープラーニングのAIでやろうとしている、という話。

結構いい感じ：実施者は『何度か試行して良かったものだけを見せている』==まだまだ、という評価のようですが。
そういう試行錯誤は人間がやったってあるし、やり直しも認められる分野の話。
職人芸的な部分をAIが吸収できていると考えてみれば、すごいでしょう。
ただ、このあたり、いわゆる『トレス作画』の話に近づくところなので、結構どきどきしている。

IT大手がしのぎを削る音声アシスタント、なぜAlexaが評価されているのか?
http://news.mynavi.jp/column/svalley/691/

Amazon 主導の「Alexa/Echo」という音声認識アシスタントの話。
日本ではあまり話題になっていないが、海外では結構なことになっているとか。
画面がなく。「10分のタイマーをセット」「音楽をかけて」「止めて」「あと何分?」といった、声だけで操作する。

変I/F大好き＆スマートフォンでは音声入力を使っている身、興味深くはあるが、やはり誤検出が心配。
だけどその検出ミス対応まで含めて高評価みたいなので、実際に試したいけど、いかんせん先立つものが（笑）

ご意見などがあれば。