t_wの輪郭

最短知名原則への転換を進めたい。

「引き入れがあるので長い知名でも扱える」というのはあるが、それでも、検索した後に輪結を辿る一手が必要になる。

正式名称は本文に書いておけば良い。全文検索も使えるようになったのでそちらで探し出すこともできる。

前景・後景に置かれる際においても、知名は短い方がすっきりする。

デライトにおいては知名の重複が許容されるため、短縮語を知名としても問題がない。

前景・後景から、知名が意味するところを暗示できる。

長い知名を描出に輪結として記載するときも、「会社名 製品名」のような知名は冗長すぎたし、自然な文章とは思えなかった。

他人の輪郭を読みたいとなったときにいろいろ出てくるので面白い。特に、引き入れがされていない宇田川さんの輪郭を見つけられるので、こんなのあったのかとなる。
自分の輪郭を探すなら全知検索で十分なので、全文検索を今の今まで使い込めていなかった。

AIとのやり取りをばかすか投稿し始めてから、全文検索しかないことのほうが、「正気なのかな？」と感じるようになってきた。

AIに限らず、文章量が多くなってくると、常識的な全文検索だと、ノイズになるのを気にして書くことをやめてしまう。「意味がありそうかどうか」を事前に判断するようになってくる。

デライトはその辺を気にせずかけるので、一見ノイズだらけになる。

この疑問に答えたい。

全文検索がない。全知検索では知名の完全一致で検索される。これは確かに正気ではない、あるいは超然的な正気の沙汰だが、そこに大きな利点を有していることを説明したい。

は？やべぇ。攻撃来てるかも。攻撃戦だ。

nginxのログみたら、SQLっぽいクエリで検索めっちゃされてる。
nginxでIPをはじくようにした。
IPをBANしたら、一旦攻撃は止んだ。

攻撃の対策どうしよう、fail2banのnginx-403-404は設定してるけど、サイト内検索を連打されるとこれ効かないんだよな。
WAF入れるのが手っ取り早いんだろうけど、勉強にならないし、お金かかるしで、もうちょっとほかの手段を検討したい。

①fail2banでSQLインジェクションを検知してBANする
②nginxで高頻度の検索を検知してBANする
あたりかしら

設定するのめんどくせー
ちゃんと設定できてるか検証するのもめんどくせー

①検証用の被攻撃サーバーと攻撃用サーバーを立ててそこで対策が有効かを検証
②本番環境に反映したら攻撃用サーバーから攻撃してみて、ちゃんと対策されているか検証

って感じで進めるとお行儀が良さそう。
めんどくせー
本番環境でペペぺって設定して、自宅のPCから実際攻撃して検証したい。そして自宅のPCから本番環境にアクセスできなくなるワナ。

こういうのって制定された手順とかあるんかな。ありそう。先に調べよう。

そもそもサイト内検索が大変重たいという問題も解決したい。
自作の検索機能がDBにインデックス張ってないわ、title LIKE %hogehoge% OR body_text LIKE %hogehoge%とかやって全文検索走るわでイケてない。
DBにちゃんとインデックス張ればいいんだろうけど、PostgreSQLの日本語のインデックスって、PGroonga入れたり、pg_bigm入れたりで、これまた検証サーバー立てないと怖いのよね。
めんどくせー。

ウェブサイトのコンテンツを事前にHTMLファイルに変換しておいて、静的サイトとして配信する手法

利点：

• 閲覧時の速度が速い
• 閲覧時のサーバーの負荷が小さい
  • 安価にシステムを運用できる
• セキュア
• スケールしやすい
  • 複数台のサーバーによる負荷分散がしやすい
    • RDBサーバーに負荷が集中したりしない

欠点：

• 動的なコンテンツを配信できない
• 静的サイトの生成に時間がかかる
• コンテンツの全文検索ができない

• 課題：全文検索にしてあるはずなのに、検索結果に出てこない輪郭がある
• 原因：@@演算子を使っていた
  • @@演算子は何もせずともインデックスを使用すると誤認しており、LIKEよりも大幅に高速だと誤認していた。
  • @@演算子で全文検索できると誤認していた。
• 対策：LIKEを使用する。
• 付記：将来的に検索速度が問題になるようであれば、pg_bigmやPGroongaの利用を検討する。

https://www.fujitsu.com/jp/products/software/resources/feature-stories/postgres/article-index/pg-bigm/

　2022年4月30日
　あれやあれに書かれているように全文検索が鬱陶しくなるということを検証するためだけに全文検索を実装してみる。
　知名完全一致のみの全知検索が問題ないことは実体験済みだが、全文検索が鬱陶しくなるというのはまだ体験していない。

　実装したものの、クロールをやり直さないといけない作りになってしまった。まあ放置しておけばなるようになるだろう。

　2022年4月30日
　postgresqlのLIKEを使ったが、貧弱なサーバーではやはり重たいらしい。いけるかなと思ったけどいけなかった。いったん全文一致に作り替えよう。良くわかってないけど、そっちならインデックスが効くので処理の負荷が小さいはず。

　2022年4月30日
　Postgresqlの全文検索は@@演算子を使うといいらしいので、@@演算子による全文検索に切り替えた。

https://www.postgresql.jp/document/13/html/textsearch.html

全文検索がデライトの起爆剤となる可能性がある。

■全知検索の場合
デライトの中で検索する
→輪郭がヒットしない（しづらい）
　→デライトはわかりにくいという印象になる

■全文検索の場合
デライトの中で検索する
→何かしら輪郭が出てくる
　→無限活字沼にはまる

　全文検索がデライトの起爆剤となる可能性がある。と書いたものの、じゃあSNSで検索が重要なのかというとそうでもない。マストドンでは検索されにくいことに価値を見出している人もいるぐらいだ。
　デライトのSNSとしての成功を考えるなら、全文検索はさほど重要じゃない可能性もある。

　「待欄に前景用の輪郭が並ぶ」のが見る人を驚かせてしまうのなら、最初に待欄を見せなければいいのではないか。
　いや、でもトップページから検索できるようになってるしなぁ……。あそこから検索してみたいものを見て回るはずだろう……。検索が引っかからなかったらそれで去ってしまうのかもしれない。全文検索があればまた違ってくるだろう。全文検索がデライトの起爆剤となる可能性もある。

デライトの全文検索が楽しみだ。検索のための輪郭が減って、よりSNS的になるだろうか。

検索キーワード site:dlt.kitetu.com
で検索

自分の輪郭だけを検索するときは
検索キーワード　site:https://dlt.kitetu.com/利用者番号
例：検索キーワード　site:https://dlt.kitetu.com/KNo.9-EDD2
のようにすると検索できる