【ココログ】「みんなで解決!広場」過去ログ検索のUpdate
みんなで解決!広場検索で、“記事についたコメントは最新の10個のみが検索対象”という制限がありましたが、なんとかこの制限をとりはずして過去のコメントも検索対象となるようにしてみました。
サーバ側(検索用データ)の修正なので、ユーザの方は特に変更する必要はありません
例えば(検索フォームの“□はじめる前”にチェックがついた状態で)、「メンテナンスはいつまで」というキーワードで検索すると、
【はじめる前】165.メンテナンスはいつまで?
という記事が現状2件ヒットしますが、この上側が2ページ目(過去のコメント)、下側が1ページ目(最新のコメント)にそれぞれリンクしています。
最新のコメント(10件)内にのみ存在するキーワード(例えば「障害報告ブログ」)で検索すると1ページ目のみが、過去のコメントにのみ存在するキーワード(例えば「メンテナンスがまだ続いているようです」)で検索すると2ページ目のみが、それぞれヒットすると思います。
これで全文検索に近づいた、かな?
それにしても、ナニ?この2ページ目のURI……
それにしても、ナニ?この2ページ目のURI……
« ちょっと宿酔気味... | トップページ | 【ココログ】「みんなで解決!広場」過去ログ検索のバグFix他 »
「ウェブログ・ココログ関連」カテゴリの記事
- 久しぶりの投稿がココログへの苦言というのもなんなのですが……(2019.03.20)
- ココログをTwitterカードに対応させてみる(2016.11.23)
- 【覚書】風柳亭(ココログプロ)をレスポンシブWebデザイン化(Bootstrap3使用)(2015.10.09)
- ココログ用全文検索 - ココログ最強検索を jQuery を使って作り直してみた(既知の不具合の幾つかに対応)(2015.09.01)
- 現在に生きるということ。(2013.01.05)
「覚書」カテゴリの記事
- 鍛高譚 ~ カレイにまつわる物語(2018.05.25)
- ココログをTwitterカードに対応させてみる(2016.11.23)
- 神使の兎 ~宇治神社にて~(2016.07.10)
- Twitter 原寸びゅー:PC版ブラウザ用・Twitterの画像閲覧と保存がはかどる拡張機能の紹介(2016.02.12)
- スマートフォンをPC上の音楽を再生するためのリモコンとして使いたい(2016.01.10)
お知らせありがとうございました。
バージョンアップで、ますます便利になりますね~!
>それにしても、ナニ?この2ページ目のURI……
うわっ、ほんとだ。
なんなんでしょう、この無意味に長いURIは。
投稿: KOROPPY | 2006/06/26 16:46
>それにしても、ナニ?この2ページ目のURI……
やっぱりここですね、ツッコミどころは(爆笑)
ところでupdate、ありがとうございます。暴想さんのやつは富豪的なんで、全文じゃないとマイナスが勝っちゃうかなあと思ったんですよ。これで心置きなく使えます。
まあ、検索結果に同じ番号が並ぶのはちょっと気持ち悪いですけど、そのうち広場もリニューアルするみたいですし、これで十二分でしょう(なんか偉そうでスミマセン)。お疲れ様でした!
ところで、「全文検索に近づいた」ってことは、まだ全文検索じゃないってことですか?
投稿: facet | 2006/06/26 17:06
KOROPPYさん、どうもです。
| バージョンアップで、ますます便利になりますね~!
そっちに気をとられるあまり、余計なバグを仕込んでしまいました。すみません(^^;。
| なんなんでしょう、この無意味に長いURIは。
いくらなんでも、もっと簡単にリンクする方法があるんじゃないかと思うんですよね。
でも、私が色々試した中では、このようにしないと表示できなかったんですが……。
投稿: 風柳>KOROPPYさん | 2006/06/26 22:43
facetさん、どうもです。
| やっぱりここですね、ツッコミどころは(爆笑)
実際に広場のHTMLを見てもらうと分かるのですが、何故だか知りませんが、2ページ目以降はJavaScriptでformに値(page)を設定した上で、submit(post)しているのですよね。
で、そのformの方でhidden属性で設定されているのが、このむやみに長い呪文……2ページ目以降の表示だけにキーが必要、って、なにか意味はあるのでしょうか?
| 富豪的
って、一般用語なんでしょうか(^^;。
まぁ、昔に比べればメモリも帯域も広がったとは言うものの、本来はあまり望ましい姿じゃないですわね。特に検索用のデータが大量の場合。
頼むから、公式な検索機能は、サーバ側で処理するようにしてね>ニフティさん。
#といいつつ、自分のサーバに検索の負荷をかけたくないので、CGIにしなかった自己中な私(^^;(開発の手間もありましたが)
| 検索結果に同じ番号が並ぶのはちょっと気持ち悪いですけど
というわけで、2ページ目以降はタイトル横に(Page x)と表示するようにしてみました(^^;。
| まだ全文検索じゃないってことですか?
ads(あず)さんの定義にもありますように、真・全文検索はその瞬間の最新記事までを含めたものでしょう、やはり(^^;。
それに、規約に伴って経過時間により過去ログが消されてしまったときのバックアップは考慮していませんし。
#それ以前に、もれが無い自信が無いというのも。
投稿: 風柳>facetさん | 2006/06/26 23:00
>頼むから、公式な検索機能は、サーバ側で処理するようにしてね>ニフティさん。
既に第一報を受けているんですが、そのようになっているようです。
ただ、検索精度は今のところは何とも言えません。ちょっと不安も(ん?)。
近日中に改善保留事項を含めた正式回答をいただけるので、
うちのblogで展開する予定でいます。
ところで、うちが「ほぼ全文検索」なら、
こちらは「限りなく全文検索」ですか?(笑)
ニフティ提供分が、その「真・全文検索」になってくれれば・・・。
投稿: ads(あず) | 2006/06/27 01:01
なるほど。そういう意味でしたか。<「全文検索に近づいた」
そういう意味だと、真の全文検索はDB保持者じゃないと無理ですね。
しかし、SennaとかHyper Estraieとか既に出回っている全文検索システムを使うだけで結構いいものが作れる気がするんですけどねえ。
というか、Google Mini 買えばいいんじゃないかという気も。(笑)
あと、「富豪的」に付いては、用語を間違えてるかもしれませんが、ニュアンスはよく伝わるんじゃないかと思って。
# 原典→http://pitecan.com/articles/Bit/Fugo/fugo.html
広場のこれはまだいいんですけど、facet-diversの全文検索をつけたときなんか、ウチの回線だと(ADSL1.5Mbpsだけど日本から遠いので)読み込みに3分も4分もかかるんですよね。いくらAjaxでもこれはさすがにダメだろう、と。
何かいい解決方法があるといいんですが。
そういう意味で、笹錦さんのcocohore!はよくやってるなあと今でも感心します。cocohore!のデータを各人の空きスペースに置けたらなあ…と思うんですけどね。
投稿: facet | 2006/06/28 07:11
ads(あず)さん、どうもです。
| 検索精度は今のところは何とも言えません
まぁ、これまでの@searchより落ちるということはないでしょう……と思いたい(苦笑)。
| うちのblogで展開する予定でいます。
宜しくお願いします。楽しみにしております。
| 「真・全文検索」
確かに全文を対象にはしているけど何故かひっかからない……というお粗末なことは無いようにして欲しいものです……さすがにそこまではない、かな?(^^;
投稿: 風柳>ads(あず)さん | 2006/06/28 18:31
facet さん、どうもです。
| 真の全文検索はDB保持者じゃないと無理
ですね。
そもそもDB自体が最初から検索することまで意識した作りになっていれば、問題無いわけなんでしょうけれど……。
ま、意識した作りとなっていなくても、クロール型の検索エンジンの導入という手段はもちろんあるわけですが……って、各発言の2ページめのコメントみたいに、JavaScriptで捏造して遷移しているようなケースは困りそうだ(笑)。
#やっぱり、DB見直ししないと厳しいかな?
富豪的、リンク先を見ました。極論ともいえますが、頷ける部分も多々ある……とはいえ、貧乏性プログラム的考えもやっぱり必要なわけで。結局はケースバイケース、なんですよねぇ。中庸でいたい、というか。
いくら使えるリソースが増えて処理にかかる時間が短くなっても、けしてそれらは∞になるわけでも、0になるわけでもないので。
ただ、PC以上の環境の場合なら、重箱のスミをつつくようなせこい工夫をするより、おおざっぱに作っておいてからボトルネックのみ解消する方が効率がよいのは確か、かも。
#本当は最初からボトルネックと総合的な性能を意識した設計を行った上で製作すべき、なんだけれども、個人で作る場合そこまでやる人は少数派でしょう。
| 何かいい解決方法があるといいんですが。
プロコースなら、テンプレートを使ってJSON化したデータベース作れるので、archive.html から辿って取得するよりは高速化できますね。
または、やっぱり自分で設定できるサーバ立てて、記事を定期的にチェック&取得してデータベース作成、しかないかなぁ。
cocohoreは調べたことないですが、やっぱり似たようなことをやっているのかな?
投稿: 風柳>facetさん | 2006/06/28 19:15
WebはADSLでようやく富豪的にできるようになってきたので結構よく似た段階なのかなあと。で、発想は富豪的にしておかないとBreakThroughできないという話だと私は捉えていて、だから、まず富豪的であってよいと思ってますが、GoogleMapsが100x100の未表示画像だけを徐々に読み込んでいるように、実用に絶え得るための工夫をしていくことが仰る通り大切かな、と。風柳さんのように ?timestamp= をつける、とか。1ページ1月に限定してページングして検索するようにする、とか。
>記事を定期的にチェック&取得してデータベース作成、しかないかなぁ。
個人的には、定期的にチェックじゃなくても、管理画面で一定の動作をしたとき(記事編集終了後とか)にDB更新のトリガーを出せるんじゃないかとか思ったりしてました。GMとか使わないとダメなんで敷居が高いかもですけど。
cocohoreは、自宅サーバなんですけど、たぶん新着pingからリンクを辿って根こそぎHTMLをスクレイピング、かと思います。ココログルもそうですけど、自前でよくそこまでやるなあと。
投稿: facet | 2006/06/29 17:46
とりあえずアイデアは出してみて、実現・実装方法は後から考える、と(^^;。
そういう意味では、出発点は富豪的であってもよいとは思いますね。
#やっぱり基本は『こんなこといいな、出来たらいいな』なわけで。
ただ、逆説は常に考えておかないと。不自由な/制限された環境だからこそ、浮かぶアイデアもあるということ。
ほら、ココ○グが使いづらいという不自由な状態だからこそ、工夫が生まれるわけじゃないですか(爆)。
#身を捨ててこそ浮かぶ瀬もあれ……ちょっと違うかな。
| 管理画面で一定の動作をしたとき(記事編集終了後とか)にDB更新のトリガーを
実はこれ、やりかけで放ってある、記事ID→記事URLのリスト(DB)更新でやりたいなとちょっと考えていたことだったりします。
ただ、Webの管理画面から送信する記事はともかく、コメントやTB、それにツールから送信する記事なんかの場合はどうするか、とか考え出すと、頭が痛くて(^^;。
自前サーバがあると、いろいろ出来るのは確かですね。
自分のところで完結する分には、まだいいのですが、一般に提供するとなると壁がいろいろあって一筋縄では行きません(^^;。
投稿: 風柳>facetさん | 2006/06/29 23:41
なんか「コメントジャック」になってますが…(^^;
>ほら、ココ○グが使いづらいという不自由な状態だからこそ
ココ□グ?←四角(笑)
…スミマセン。←だって思いついちゃったんだもの
>実はこれ、やりかけで放ってある、記事ID→記事URLのリスト(DB)更新でやりたいなとちょっと考えていたことだったりします。
実は私もそのことを念頭におきながらあの時やりとりしてました~←本当です
>ただ、Webの管理画面から送信する記事はともかく、コメントやTB、それにツールから送信する記事なんかの場合はどうするか、とか考え出すと、頭が痛くて(^^;。
あー。ツールは痛いですね。←放っておけばいい気もしますが(笑)
で、いま思ったんですけど、管理画面じゃなくてやっぱりブログに仕込む方が良さそうですね。←それなら user script 不要ですし
コメントは、送信ボタンを乗っ取る。←これは前からの考え
記事は、管理画面からのリファで覚醒。←いま思いつき
TBは、……要らないんじゃないですか?←適当(笑)
>一般に提供するとなると壁がいろいろあって
ですよね。それが私がサービスに踏み出せない理由でもあったり。←いいわけ
まあ、ビビリすぎって話もあるんですけど。←小心者
↑以上、矢印で遊びすぎ←ですな。
投稿: facet | 2006/06/30 08:40
ココ■グじゃなくて?(^^;
#■Guildとしては……とか
| 記事は、管理画面からのリファで覚醒。
あ、これよくわからない……どういう手段ですか?
| 私がサービスに踏み出せない理由
でも準備はされているみたいだし、期待してます。
私もサーバ側スクリプトも勉強しないとなぁ。
Perlはちょっとだけ使ってますがかじった程度だし、Rubyも何年も前からRuby使いの知人に進められながらも手を出していないし、PHP?Python?なにそれ?状態だし……。
投稿: 風柳>facetさん | 2006/07/01 06:24
>#■Guildとしては……とか
あー。スクリプト復活させないとJAROに訴えられちゃうな…w
>| 記事は、管理画面からのリファで覚醒。
スミマセン。イメージしてたのは、document.referer(リファ)を見て、それが自分の管理画面からの物だったら、DB更新のトリガーを発動させる、という感じです。
投稿: facet | 2006/07/03 19:31
ああ、なるほど。
そうすると、管理画面から自分のサイトを開くことが前提……うーん、あんましそういう使い方はしないからなぁ……(別タブで既に開いてあるのをリロードする場合がほとんど)。
#それにNorton Internet Securityなんか入れていたらデフォルトreferer無効だし(__;)/
サイトの方を覗かせてもらったら……いろいろと興味深いことをなさってますね。また参考にさせてもらいます(^^)。
投稿: 風柳>facetさん | 2006/07/10 20:15