  |
はてなキーワード: クエリとは
技術的な内容を増田に書くという実験のために、試しに検索エンジンの仕組みについて書く。
検索エンジンは、大雑把に言ってクロールするパート、インデクシングするパート、検索インターフェイスを出力するパートに分かれる。
インデクシング時に使っている基本手法は「転置インデックス」と呼ばれ、文書内のngramを文書IDと対応付ける辞書を保存する。
インデクシングの別の種類としては、文書をエンコーダからベクトルへ変換し、それを近似最近傍検索できるようにするものもある。
インデクシングされたものがキーワードマッチ的に絞り込まれると、さらに精密な手法が使われる。
クエリとドキュメントから特徴量設計し、関連性の高いものを引っ張るような訓練をする方法はLearning to rankという。
Learning to rankの中に使われる特徴量の一つにPage Rankがあるが、これは初期の検索エンジンで画期的とされた量で、「リンクされるページの価値は高い」「高価値ページにリンクされると価値が高い」という基準からマルコフ連鎖で計算する。
Page Rankは人間が論文を評価するときと似たような評価手順であるとされる。
Learning to rankの中にエンコーダからのベクトルを特徴量として組み込むことも可能であり、そのようなエンコーダの初期の例がBERTである。
こうやって絞り込まれた文書に対して、さらに有用な情報を表示するモデルがいくつか使われる。
情報抽出モデルでは、クエリを質問と見做してその回答を文書から抽出することがある。
あるいはクエリが人物名や組織名、場所名などであれば、そのエンティティの詳細情報をデータベースから取得することもでき、これはナレッジグラフとも呼ぶ。
SEやっててパワークエリもVBA使うくらいだったらコード書いちゃうんでそれらを触ったことない。
この前、職場の事務職（月21万円）の面接に無職のおっさん（48）が来たんだが
そのおっさんが「パソコン得意です。Excelできます」ってドヤ顔で言ったんだよね
おっさんが「できません…」って言い出して呆れた😅
ExcelなんてそれこそパワークエリやVBaできてなんぼなのに
じゃあ何ができるんですか？って聞いたら関数とか…って言い出してドン引きしたわ
そんなん教えたら誰でもできるもんやん
ので、感想を書き残す。
スネイルズハウスくん、DJ下手なんやね。ぶつ切り繋ぎ、アンセム連発、DJ歴半年の子かと思った。
いい曲かくし、remix上手いのにまさかmixが下手やとは意外だった。
モエショップ、好き。曲が好きなのが大きいけどBPM低めでノリやすいし、計算されたセトリに丁寧なmix、わかりやすい煽りで安心感があった。
ぴっこさん、やるやん。正直あんまり曲知らんというか、前にちょっと聞いてみた時は未来茶系サウンドの焼き直し感があって、またkawaii系のフォロワーか、もうおなか一杯やわと思ってたけど、生で通しで聞いてみたらええやんと思ったね。
あれだけ可愛いで埋め尽くすセトリ、エリアのテーマにぴったり合ってて仕事できるなと思った。
まあでも一番キてたのはkawaii系からハカハカの潰れたサウンドへの流れ。この日を通して一番トべるポイントだった。
ネコハカ、煽るのが上手い、安定感しかない。でも曲が全く刺さらんのよね、ごめんなさい。どうしてもギターが邪魔に聞こえる。
これは俺の好みの問題でしかないのでネコハカのお二人には何の非もないです。パフォーマンス力は文句なしのトップ。
norくん。客のレスがイマイチなことにキレて、音止めてやり直したところで、おいおいやってんねえ！となった。数十人規模の小さい箱ならよくやるけど、企業主催の公式のホールイベントであれやる度胸ない。さすがだわ。バカ広い会場でいつも通りのクラブのDJやってくれる安心感よな。
Yunomi大先生、コンテンポラリーアートっすか？
うごくちゃんのミニマルミュージック風remixからの枕もとにゴースト。
たぶん何か意味があるんだろうけどそれを読み解けるほどうごくちゃんのこと知らないんよね。
何年前だったか、京都の南座に🍵見に行ったら、デカマスクにデカグラサンの青髪の女性が歌ってて、そのときはへー、この人人気の配信者なんや、くらいにしか思わなかったけど、そのあと何年かして自ら命を絶ったってニュースを目にして、少し悲しくなった。そんなことを、思い出したわ。
そんなスタートだったからか、全体的に重く、悲しい雰囲気があったね。明るくキラキラした曲も素直に楽しめないというか。まあ夜の部のコンセプト的に間違ってはいないと思うけど。
それにしてもYunomi大先生はどこに向かってるんやろね。俺はまだフォローしてくつもりだが、ここ数年の転向以降ついてけないオタクも多いんじゃないか。
電音部史上最高やないか？昼の部の小道具大道具モリモリで視覚的にハラジュクをわからせにくるのよかったし、夜の部は夜の部で変化がわかりやすかった。照明、音響文句なし。
ライブパートで字幕が出てくるの、ありがたかったな。新曲でも言葉がスッと入ってきて、ミュージカルみたいに楽しめた。
そう、ミュージカルみたいに楽しめたのが大きい。
原作？の物語を舞台上で表現するっていう一本の筋が通ったことで、全体が一つにまとまってて、いい感じやった。
いままでの電音部のイベントって正直な話、いろんな界隈のオタクを集めてわーわー騒いでるだけっていう、なんかよくわからんもんやったけど、今回のは違ったね。
ようやくバンナムが電音部をやる意味が出てきたんやないかと思ったわ。
アニソンフェスみたいなもんは文脈を共有してるから成立してるわけで、アニメ化ゲーム化してない小説だけの電音部は文脈が薄すぎてなんかようわからんかった。
もちろんオタクが集まってわーわー騒ぐのも楽しいけど、そんなもんはバンナムがやるまでもなく、いろんなオーガナイザーが低コストでやってくれてるし、バンナム謹製のお高いチケットには見合わんのよな。
なんにせよ光明が見えてきた感あるし今後が楽しみやわ。
環境構築はできてる
みたいなのも分かる
けど
そっから先のTwitterみたいなの作ろうとした時どういうテーブル作ってどういうクエリでSELECTすれば良いのか分からん
chatgptで
「sqlite3でtwitterみたいなサイトのテーブル設計をして。
上記のTwitterのようなサイトで特定のユーザーのタイムラインを表示するクエリの例を教えて」
って聞くと、こういうの表示されるけど、こんなの絶対パッと思いつかんやろ!!
特にJOIN2回使うのが全然分からん。なんならJOIN1回の部分も分からん
っていうか、hatena君、sqlのシンタックスハイライトするとインターナルサーバーエラー返してくるんだが...
class Foo def bar'baz' # return baz end end
sqlだけっぽい......
CREATE TABLE users ( id INTEGER PRIMARY KEY AUTOINCREMENT, username TEXT NOT NULL, email TEXT NOT NULL UNIQUE, password TEXT NOT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE tweets ( id INTEGER PRIMARY KEY AUTOINCREMENT, user_id INTEGER NOT NULL, body TEXT NOT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, FOREIGN KEY (user_id) REFERENCES users (id) ); CREATE TABLE follows ( follower_id INTEGER NOT NULL, followed_id INTEGER NOT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (follower_id, followed_id), FOREIGN KEY (follower_id) REFERENCES users (id), FOREIGN KEY (followed_id) REFERENCES users (id) ); SELECT tweets.id, tweets.body, tweets.created_at, users.username FROM tweets JOIN follows ON tweets.user_id = follows.followed_id JOIN users ON tweets.user_id = users.id WHERE follows.follower_id = [特定のユーザーID] ORDER BY tweets.created_at DESC;
もしも掲載雑誌が既知じゃない状態でかぐや様と五等分の花嫁をさらっと提示されて、さてどっちが青年漫画でどっちが少年漫画か当ててみよと言われたら多分俺は答えられないだろう。
青年漫画かどうかの判断基準を少年漫画と比べたときの内容の大人っぽさに据えてみたとしても、どっちの方が大人っぽいか良く分からん。答えを知ってる立場で見るなら確かにかぐや様には時事ネタや政治経済的な文脈での人間の汚さを描いてるところがあるという点で、少年漫画と比べて大人っぽいのかなあと言えなくもないが、どうも後付けな感じがする。五等分の方がフィクトセクシャルに向けて性をより押し出そうという点ではそっちの方が大人向けなのではないかという感じもする。
なんでこんなことを考えているかというと、新しく面白い漫画を発掘しようと思ったところなのだが、経験上俺が面白いと感じるツボを押さえた内容を持った漫画が出されてるジャンルというのは少年漫画と青年漫画の双方にかなりの重なりをもってまたがっているからだ。そして少年漫画と青年漫画の内容上の区別が思いのほか難しいときてる。
ならこれらをいっしょくたにして探したいと欲するところなのだが、電子書店で受け付けるクエリというのはグーグルやツイッターほど融通が利くものではなく、or検索すらできない。
「男性向け」というタグを用いてる書店もあるが、このタグには18禁でない程度の白塗りお色気漫画が多数含まれている。
その気が無いときにお色気漫画ばっか出てきて検索上ノイズでしかなく著しく発掘効率が落ちるというわけだ。
ああ、別に学園漫画やラブコメに限って面白いと感じるわけではないのであしからず。
社畜ちゃんは少年漫画なのに社畜となんとかの１０００何日だっけ？は青年漫画とかってのもみるとほんと内容的から論理的にそう区別された根拠を説明できるものじゃなくて便宜上の区別でしかないなあ。
このChatGPTのJavaScriptの説明がどうしても分からない。解説あってる？
var idx は、現在開いているWebページのURL文字列に ? が含まれている場合に、その位置を取得するために使用されます。これは、クエリ文字列の開始位置を特定するために必要な処理です。
たとえば、以下のようなURLが現在開いているWebページのURLであった場合、
https://example.com/search?q=keyword&page=1
var idx = url.indexOf('?'); というコードを実行することで、変数 idx には 8 という値が代入されます。これは、? の位置がURL文字列の8文字目にあることを示しています。
var idx はURLの文字列の何番目に？があるかって意味だとは分かった。でも例文のURLだと？の位置はhから数えて27番目だよね。聞いてみた
おっしゃる通り、指定されたURL https://example.com/search?q=keyword&page=1 において ? の位置は h から数えて 27 番目の文字です。
しかし、ブックマークレットのコード中では idx の初期値として url.indexOf('?') を設定しています。この indexOf() メソッドは、指定された文字列が最初に現れる位置を返します。もし文字列が見つからなかった場合は -1 を返します。
したがって、ブックマークレットのコード中で url.indexOf('?') を実行すると、? の位置が返されます。指定されたURLにおいて ? は https:// の直後に出現するため、url.indexOf('?') の実行結果は 8 になります。
つまり、ブックマークレットのコード中では ? の位置ではなく、? の次の文字（q）の位置が idx として設定されていることになります。
なんか意味がわからない。その後もどっから数えた数字がidxになるのかいくつか聞いてみたが堂々巡りになってしまって明確な答えが分からない
昇進したらどうしたい？
みたいなこと聞かれてさ、
「紙の伝票とか台帳とか、報告書とか、そういうのやめたい。」
って答えたらさ、
「具体的にどうしたらいいと思うか？」
とか聞いてくるわけ。
技術的な話しようかと思ったんだけど、その、ジジイさ、パソコン音痴なわけ。
「会議開きたいから添付のExcelにマルバツつけてメール返信してくれ」
って感じの、日付とその隣にマルバツをつけるセルが用意されたファイルを送ってくるような人なわけ。
他にも、社内数百人に自由記載のアンケートとかもそういう送り方してくる人でさ。
返信されてくるメールに添付されたExcelファイルを全部別の名前をつけて保存して、一つ開いてはコピペ、一つの開いてはコピペしてる人なの。
まあ、仕方ないから思うことを話したさ。
後から検索できないデータなんて不良債権だから、わざわざ印刷してから保存はやめろ。
世の中にはデータベースっていうものがあってだな、そこに行く前に絶対必要になるからデータもデータの繋がりもリレーションで書き出せ。
っとひとしきり。
それで、返ってくる言葉が
「抽象的でわからない。もっと具体的に、ファイル名で分類するとか、どうやって台帳で管理するとか、なんかあるだろ？」
とか言ってくるわけ。
いや、技術的な話を聞いたのはお前だろと。
「もっと、会社のシステムみたいな壮大な話じゃなく、自部署をどう解決したいかを教えてくれるか？」
みたいな返しをしてくるから
って答えても、よく理解してくれないわけ。
終始すれ違い。
あー、失敗した。
はてブではたまにこういうことが起こる。👇
全国のパン好きのみなさん、一生かけて回るので推しパン屋さんを教えてください→地域別で分けてみた
https://b.hatena.ne.jp/entry/s/togetter.com/li/2064362
全国のパン好きのみなさん、一生かけて回るので推しパン屋さんを教えてください→地域別で分けてみた
https://b.hatena.ne.jp/entry/s/togetter.com/li/2064362?page=2
全国のパン好きのみなさん、一生かけて回るので推しパン屋さんを教えてください→地域別で分けてみた
https://b.hatena.ne.jp/entry/s/togetter.com/li/2064362?page=3
それぞれ何が違うかというと、分割されているページの位置だ。
ページごとにURLが異なるので（?page=nの部分）、はてブからは個別のコンテンツと認識されてしまっているのだ。
Togetter以外にも記事をページ分割するサイトはいくらでもあるが、このようなことが起こることは少ない。
はてブのシステムは、ページ分割されているどのページをブックマークしても親ページ（先頭ページ）がブックマークされるように作られているからだ。
ただし、それにはブックマークされる側のページで「カノニカルURL」が正しく設定されている必要がある。
カノニカルURLとは、「この記事っていろんなURLのバリエーションがあるけど、SNSとかで拡散する時はこのURLを使ってね」という「代表URL」のことだ。
WebページのURLには、（まさにこの例のように）ページ分割位置を示すクエリパラメーターがくっついたり、効果測定やアフィリエイトのためにクエリパラメーターが勝手にくっついたりすることがよくある。同じページでもURLに無限のバリエーションができてしまうが、それぞれが別個のコンテンツだと認識されてしまうと不便なこともある（まさにこの例のように）。
そうならないように、アクセスを本来のまっさらな親ページ（先頭ページ）に集約するのがカノニカルURLの役割だ。
はてブも、分割の途中ページがブックマークされてもカノニカルURLの記述に従って先頭ページがブックマークされる仕組みになっている（この仕組みが実装されたのはわりと最近なんだけど）。
それなのにTogetterのブクマが👆あんな風になっちゃうのは、ひとえにTogetter側のカノニカルURLが正しくないからだ。
カノニカルURLの記述じたいがないのかと思って調べてみると、そんなことはない、ちゃんとある。
＜link rel="canonical" href="https://togetter.com/li/2064362?page=3"/＞
なんと、クエリパラメーターをくっつけたバリエーションURLのほうをそのままカノニカルURLにしてしまっている。本末転倒な使い方だ。
もろちん、クエリパラメーターがくっついたままのURLをカノニカルとしなければならないケースもあるだろう。クエリパラメーターが記事IDになっているようなサイトはいくらでもある。
しかしTogetterに関しては違うと思う。なぜなら、分割の途中ページでもSNS拡散ボタンは先頭ページのURLを登録するようになっているからだ。
つまり拡散アクセスを記事の先頭ページに集約したいという意思がちゃんとうかがえるのだ。SNS拡散ボタンとカノニカルURLに矛盾がある。
文句のついでにカノニカルURLの解説をしてしまったのでちょっと長くなったけど、とにかくTogetterはカノニカルURLの設定をとっとと見直してほしい。
