  |
はてなキーワード:joinとは
I have a dream thatone dayon thered hills ofGeorgia, the sons of former slaves and the
sons of former slave ownerswill be able tosit downtogetheratthe table ofbrotherhood.
I have a dream thatone day even thestate of Mississippi, astate swelteringwith theheat
of injustice, swelteringwith theheat of oppression,will be transformed into anoasis of
I have a dream that my fourlittle childrenwillone daylive in anation where theywill not
be judgedby thecolor of theirskin butby the content of their character.
I have a dream thatone day, down in Alabama, withits vicious racists, withits governor
havinghislips drippingwith the words of "interposition" and "nullification" --one day right
there in Alabamalittleblack boys and black girlswill be able tojoin hands withlittlewhite
（Verse 1 / Diggy-MO'風）
Yo 昔々 その遥か昔
育ったBoyは武闘派StyleでElectric
腹減ったら “黍団子（ギビダンゴ）” 片手に
「ついてきなキミ 俺の旅路」
Dog,Monkey, Pheasant──Join thesynergy!
悪を討つぜ！ 桃太のスキルで！
（Verse 2 /Bro.Hi風）
チェケラ！鬼退治は任しとけ
宝ごっそりPeaceに戻し
村人ハッピー 叫べ “おかえり！”
俺らのBeatで島が揺れる
鬼の城もBreakin’ down withflare
伝説超えたら “昔話” Back！
悪を討つぜ！ 桃太のスキルで！
語り継げよ 千年先まで
Chrome系ブラウザには増田を快適に閲覧するためのコンパクトな増田 という古い拡張機能があったが、Chromeの更新に対応し切れておらず、既にChromeには新規インストールできなくなってしまっている。Edgeにはまだインストール可能だが、いずれ対応しなくなる可能性が高い。
そこで、「増田のトップページで、言及エントリ(返信・トラバ)を一覧から除外することで、新規エントリだけを一覧できる」という機能に絞ってコンパクトな増田を再現、ついでにいくつかのおまけ機能を付与したスタイルシート(CSS)を今年の4月に公開していたのだが、今回改めて英文スパム対策を追加したので公開する。
これを導入するにはStylus という拡張が必要で、少し気軽さには欠けるが、増田以外にも活用できるので、この機会にぜひ導入してみてほしい。拡張をインストールしたあとは、下記のコードをコピペして新規スタイルとして導入する方法もあるが、スタイルシートを公開できるuserstyles.world の増田CSSページから [Install]ボタンでインストールするほうが、自動更新にも対応するので便利かもしれない。
/*トップページで言及エントリを除外 *//*via:最近ファーストブクマカが静かhttps://anond.hatelabo.jp/20250326171302 */h1/*はてな匿名ダイアリー*/ + #intro/*名前を隠して楽しく日記。*/ + #body div.section:has(h3 > a/*■*/ + a:not(.keyword, .edit)/*anond:YYYYMMDDhhmmss*/){ display: none;}/* うっかりクリックしがちなキーワードリンクを無効に */a.keyword{ pointer-events: none;}/*執筆時のテキストエリアを広く */textarea#text-body{min-height: 50vh !important;}/*執筆時に特殊記号のヒント(疑似要素なので選択してコピペできないのがもどかしいけど) */p.post-submit >span.explain::after{margin-left: 1em;padding-left: 1em; content: "特殊記号: &[&] <[<] >[>]";background:url(/images/common/outsite-wh.gif) 0 3px no-repeat;}/*スパム対策部分は下記URLの [Install]ボタンで事前確認できます(随時更新中) *//*https://userstyles.world/style/23028/ */
なお、このCSSを適用すると、NGワードを含むこの増田自体も、増田トップページからは消えてしまう(この増田単体の個別ページなら閲覧できる)。
念のため、PC・スマホにCSSを適用する方法の解説にもリンクしておく。
PC: 【Stylus】ウェブサイトにCSSを適用できる拡張機能。自由にカスタマイズ！ |ナポリタン寿司のPC日記
https://www.naporitansushi.com/stylus/
iPhone: MaKeoverアプリでiPhoneSafariのCSSをカスタマイズ！万博パビリオン予約結果一覧を見やすくする使い方
https://gintachan.com/makeover-app-css-change-safari-how-to/
(7/21追記) また、スパムが特に多い時は、1ページまるごとスパムということもあるので、PCならuAutoPagerize (Chrome) やweAutoPagerize (Firefox) などの拡張を使うと、自動でページが継ぎ足されて快適に読み進められる。ただし、継ぎ足ししまくるとメモリ不足などでブラウザが重くなることがあるので、そうなったら page:20 などのページ番号をクリックしてから続きを読もう。
また、スパム対策の簡易NGワードは、下記のスクリプトを使って抽出した「直近の増田の頻出キーワードリンク上位20件」から、誤判定しそうなline とuser を除いた18件を用いた。10件だと生き残る英文スパムがあったので20件にしたが、それでもわずかに洩れはある。しかし日本語による真っ当な(?)増田の直近の誤判定はなかった。はてなキーワードのリンクだけを対象にしているので、URLにはこれらのキーワードが入っていても大丈夫だ。ただし、スパムのトレンドが変われば話は変わってくるかもしれないし、過去や未来の増田の誤判定は当然あるだろう。気になる人は前掲のCSSを行単位で編集してほしい。
//AutoPagerizeでまとまった数のページを読み込ませた後に実行するとよい。(function(){constkeywords = []; //はてなキーワードの集計 document.querySelectorAll('a.keyword').forEach(a => { // 4文字未満は誤検出の可能性が高まるので除外 if(a.textContent.length < 4) return; letindex =keywords.findIndex(k => k.keyword === a.textContent); if(index >= 0)keywords[index].count += 1; elsekeywords.push({keyword: a.textContent, count: 1}); });keywords.sort((a, b) => a.count < b.count); //ランキング配列の出力console.log(keywords); //CSS埋め込み用に上位キーワードのみをURIエンコードして出力console.log(keywords.slice(0,20).map(k => encodeURIComponent(k.keyword)).join('\n'));})();
anond:20250326171302 ←元はこの増田がきっかけでした。
anond:20250701194328 ←キーワード判定に踏み切る後押しとなりました。
ここで、「Aのデータと共に、関連するBとCのデータも取得したい」という一般的な要件を考えます。多くの人が最初に思いつくのは、`JOIN`を使ったクエリでしょう。
SELECT A.A_id, A.A_attrs, B.B_attrs, C.C_attrsFROM AJOIN BON A.B_id = B.B_idJOIN CON A.C_id = C.C_idWHERE A.A_id = 'some_a_id'; --特定のAレコードを取得する場合
このクエリは、B,Cの重複が大量発生し、さらに属性のデータサイズが大きい場合は非効率になる可能性があります。
データベースは`JOIN`を行う際に、結合条件に合うレコードを探すために複数のテーブルをスキャンしたり、一時的な結合結果を作成したりするオーバーヘッドが発生します。
特に、`JOIN`するテーブルの数が増えたり、それぞれのテーブルのレコード数が多かったりすると、このオーバーヘッドは顕著になります。
また、「JOIN乱用するなら第三正規形にする必要ないんだよな」という点も重要です。
第三正規形はデータの冗長性を排除し、データの一貫性を保つための設計原則です。
しかし、その結果としてデータが複数のテーブルに分散され、結合が必要になります。
もし結合による性能劣化が許容できないレベルであれば、データの一貫性を犠牲にしてでも、冗長性を持たせる（非正規化する）方がパフォーマンス上のメリットがあるというジレンマに陥ることもあります。
しかし、それは正規化のメリット（データの一貫性、更新時の不整合防止など）を失うことにもつながります。
主張されているのは、以下のようなアプローチです。
1. まずAのデータを取得する。
2. Aのデータから得られた`B_id`と`C_id`を使って、必要に応じてBとCのデータを個別に取得する。
--ステップ1: Aのデータを取得SELECT A_id, B_id, C_id, A_attrsFROM AWHERE A_id = 'some_a_id';--アプリケーション側で、上記で取得したB_idとC_idを元に、必要であれば以下のクエリを発行--ステップ2: Bのデータを取得 (例: Aから取得したB_idが'b1', 'b2'だった場合)SELECT B_id, B_attrsFROM BWHERE B_id IN ('b1', 'b2');--ステップ3: Cのデータを取得 (例: Aから取得したC_idが'c1', 'c2'だった場合)SELECT C_id, C_attrsFROM CWHERE C_id IN ('c1', 'c2');
この方法の利点は以下の通りです。
Laravelを使ってる奴けっこう多いと思うんだけど、みんなEloquentに満足してるの？
自分は正直、あれが賢いと思ったことが一度もない。触るたびにゴミ箱に捨てたくなる。
たとえば、belongsToとかhasOneみたいなリレーション。普通なら、JOINで一発で取りたいじゃん？
でもEloquentは基本的に別クエリでselectしやがる。
「with使えばいいじゃん」とか言ってるやつ、頭の中までEloquentに最適化されてんじゃねえのか。
いや、確かにwithでまとめて取れるけど、それでもJOINじゃなくて複数クエリ投げてるだけだからな？
リレーション多いDB設計になってくると、Eloquentの無能っぷりがどんどん見えてくる。
速攻でN+1問題にブチ当たって、「え？みんなこれで仕事してるの？」って本気で思うわ。
あと、Laravelのマイグレーションもゴミ。DB周り本当にゴミ。
自分もLaravelに初めて触れたとき（もう十年以上前か）「これが現代のPHPか」と思って浮かれてたけど、業務でLaravelを自ら選定したのは一度だけだわ。
引き継ぎ保守でLaravelを触るとめっちゃ気分が下がる。マジで滅びてくれんかな。
世のLaravel信者たち、「Eloquent最高！」とか言ってるけど、あんたたちもEloquentと同じレベルでバカになってないか？
まだ2桁来場にはとどいてない、通期パス持ちの金なし増田。一度くらいは9時入場してみたいなぁと思って。最短で取れた9時入場は6/5だった。
かなりだらだらと冗長に書いたので、気になる所だけ読んで欲しい。あとで、ポイントごとにAIに要約させた記事も投稿するつもりだ。
[:contents]
東ゲート予約でチャリンコ圏内在住なのでチャリンコでゆく。メトロより安上がりだし、なにより有酸素運動ができる！おまけに行きや帰りの夢洲駅～メトロ中央線の人込み回避までできる！ひとごみにいるだけでMP減っていく人間だからこれは小さくない。
万博会場へのサイクリングロードとして、「淀川リバーサイドサイクルラン」というのが設定されているのだが、本来淀川本流左岸をまっすぐ走れたはずが、左岸線工事の遅れのせいで、毛馬から大川沿いに逸れて中之島経由という遠回りになっている。大川沿いはまだしも、天満橋あたりから高見でまた淀川左岸の堤防に戻るまではただの市内の道路と変わりないし、無駄にアップダウンもあったりで実体験からはこのゾーンはお勧めできない。
軽く朝飯食って7時過ぎに家をでて、昼飯・おやつにローソンの大盛チャレンジを買っていく。お気に入りの高菜明太が1件目になかったが2件目には山盛りあった。あとまい泉のカツサンドとを買ってゆく。興味が無いわけではないが万博飯は俺には高すぎる。
高見で淀川左岸堤防上を走り始めると、そこから数kmは信号が無い。今日は風もなく快適だ。ここは大体川をさかのぼる方向(西から東)に風が吹いていて、それが強いとチャリンコ漕ぐのがめっちゃ大変になるのだ(経験者語る)。ユニクロのドライEXUVカットハーフジップTシャツでひやけたいさくもばんぜんだ！(そこまでじゃないかも)
万博会場の夢洲に行くまでに常吉大橋と夢舞大橋の2つをわたる必要があるのだが、「世界で一番美しいごみ処理施設」(kwskはggr)が見え始める最初の常吉大橋をのぼり始めたところで腹具合に異変が……朝起きて飯食って水を大量に飲んで一応出すものは出してきたんだが、かなり控えめな量しか出なかったので、これは予想されていた事態だ。俺の膀胱と肛門の防御力に俺は自信がない。万博行って帰ってきたらおパンツが血まみれだったこともある。冷や汗かきながらチャリンコを漕ぎ進める。夢舞大橋の上りは割と急なのでいつも押して上がる。真ん中あたりにいたオッチャンが「下でポリさんみはってんで！」って声をかけてくれる。基本押して歩きましょうって事になってるんだけど、下りとか押して歩きたくないよね、普通。歩行者が多いならわかるけど勿論そんな事は無いし(徒歩でこの橋を渡る人、通るたびに1組位ははいてはる)。
とりあえずポリさん見えるまではチャリンコ乗ったまま。橋の終わりと次かつ最後のの交差点の真ん中位にパトライト盛大に光らせ、ポリさんが3人たってこっち向いてるのが見えた時点で、はやくはやくとせがむ腹をなだめながらチャリンコを押しておりていく。長い坂で出そうと思えばいくらでもスピードは出るうえに、それを遮るための自転車用車止めもある。チャリンカーがケガしない様に見張ってくださってるんだと思えばありがたいことである。
車止めを抜けたところで再度ライドオンしてトイレに向かってペダルを漕ぐ。幸いポリ公はなんも言ってこなかったし、横を通り過ぎる時も大して注意を払ってこなかった。
駐輪場着が8:30。そのままトイレへ急行、出すものを出す。今度は十分な量出たので安心して東ゲートへと向かう。ゲートが見える場所までくるとうんざりするほどの人が歩いてる。トイレで5分ロスしたとすると、その間にメトロが2回弱到着してる。この時間は乗った事ないが、平日10時入場の時でも電車はそこそこ混んでるので、最低でも同じくらいだろう。ggってみると1編成は6両で定員1000名(座席定員750)。トイレのせいで2000名程度に先行を許してしまった(西ゲートの分も合わせたらその2倍かも)が、うんこ増田扱いされないためには避けられないないコストであった。
ぐねぐねと歩かされる(もしかしたらグリッチ利用でショートカットできる可能性もあるのだが悪用されると嫌なので書かない)ゲート前、早足でこれ以上動かないところまで来たら8:40だった。これなら9:20位には入れてるかな？と思ったが大間違いだった。万博はとにかく並び、待ち時間が大量に発生するので(同行者がいない場合は)暇をつぶせるものを持参する事をお勧めする。携帯でもいいけど、電池切れると大変なのでモバイルバッテリーは必需品だ。今回は文庫本持ってきたが、周りの会話が聞こえてきて普段の1/3位の速度でしか読めない。集中力が欲しい。
この日は快晴で、降水確率すら一日オールゼロ。9時前でも日差しが強かったが、さらにどんどんキツくなってくる。まだまだ梅雨前で湿度は低めなのにご覧の有様なのは、梅雨以降の事を考えると本当に心配である。自分はまだいいやと思って刺さなかったが、日傘をさす人もそこそこいた。自分の前の人の横に周りを気にせず日傘をさしてる気づかいの足りない人がいて、何度も顔にあたりそうになって気の毒だった。日傘をさすときは周りに配慮しましょうね。ほとんどの人は出来てるだけにこういうの見かけると残念すぎる。
手荷物検査は9時の少し前から始まり、少しずつ列は進んでいく。流れの都合か、無理やり割り込んだりしてるわけでもないのに、最初自分の後ろにいた人が自分の4人前とかに居るのをみる。そんなに自分の番が遅れるわけでもないだろうがなんか嫌な気がしてしまう自分に嫌気がさす。逆に真横にいたはずの人がゲート前で数人後ろにいたり、とかもあるので気にしないのが一番なのだが気になっちゃうよね。
ゲートが近づいてきて(ゲートが動くわけじゃないが)、ゲート上の屋根の陰に入れると一気に体感温度が下がる。二十度半ばなので寒くなったりはしないが、たまに涼しい風が流れてきたりと、直射日光下とは雲泥の差でにじんでいた汗が引いていく。
「ポケットのなかの鍵などは荷物の中におしまいください」との声が聞こえてくる。これは初めて聞く案内だ。手荷物検査まわりの効率化だろう。鍵とか忘れやすかったり直すのに時間とったりするのを削減したいのだろう。鞄に鍵をつっこむ。(9時台だけやってる可能性もある？)
いよいよ入場！時間は9:50。70分も並んだのか……並ばない万博とはなんだったのか
本エントリは(万博会場で近くにいた人にも)特定される情報が無いように書くつもりだが、例外的にパビリオン等万博運営にはあの人だろうなって分かるレベルの情報は出すことにする。そこから名前特定まではかなり遠いはずなので。
最初に向かったのは東ゲートから一番近い外国パビリオンのアイルランド館。これまでも何度か入ろうとしたものの、既にもう並んでも予約券の枠がありません、とか並べませんとか言われたところだ。公式ふくめ、いかなる予約も受け付けていないところ。
なんとか並べたので列にjoinしたのだが、観られたのは展示の2部屋だけ。9時と13時20分に4回ずつのエキシビジョンツアー&ライブミュージックの整理券を配布しているのだが、9時の配布は自分が入場する前にとっくに終わっており、最初のエキシビジョン(10:45)までつなぎの入館だったようだ。こういう情報はちゃんと聞かないとわからないorスタッフにちゃんと聞けば確認できる。ネットにも情報があるのかもしれないが、ここに関しては下調べをしていなかった。展示に関してはこの後エキシビジョン&ライブに参加したのでそこで書こう。
並んでる間にちらっと紙チケットで入場したという年配のご夫婦の話が聞こえてきて、しゃべってる相手の若い人が「万博IDを予約しないと並ぶことしかできないんですね」って言ってて少し驚いた。そういやそんなのありましたね。そいや、あれって予約しないでも入れるから、あれ買えば満員でも9時入場できるんじゃないの？？？と、今これを書きながら調べてみたら、紙チケットで予約なし入場できるのは11時以降となっていた。「6か月前」に販売開始される「日時指定引換券」であれば、9時入場もできるっぽいので、このご夫婦はおそらくそれで入場されたんだろう。万博IDの作成なしには当日予約すらできないの、本当にデジタルディバイドの深刻さを感じさせてくれる。もしかすると「当日予約センター」とかでなんとかなったりするのかな？と「紙チケット 当日予約センター」でggってみるもそれらしいページはヒットせず。
アイルランド館からリング下を歩いてTechWorld館へ。10:30の予約には間に合った。道すがらみるパビリオンは今まで殆ど観たことないレベルの行列の少なさで(9時入場の威力)、次はいつもリング下まで並んでるサウジアラビア館に決めた。
先日togetterがホッテントリに入ってたが、「s/台湾/テックワールド/」された世界に迷い込んだかのようだった。主催の会社名「玉山デジタルテック株式会社」でggっったらでてくる日経のサイトとか、id:entry:4771086957407295329、id:entry:4771081046455224641あたりみても、まぁ殆ど万博用のダミー会社ですよねこれ。
この世に「テックワールド」という島or国が存在するのは当然、という感じでスタッフ案内や映像は作られてる。
ちなみに、これが3日前のキャンセル枠で取れた、本日唯一の予約だった。7日前予約はイタリア館だったか忘れたが超人気のパビリオンに全振りして全落選しました。欲張ると全落選普通にあるのでみんな注意しようね！遠くから宿泊込みでの来場だとリセマラもできないもんね。
最初に心拍数計測用(その場でこの説明はされない)のスマートウォッチ的なデバイスを渡される。
大きくわけてLife, Future,Natureの3つの展示があるが、そのどこで一番心拍数が上がったかを測定し、それを元に台湾ツアープランを提示するという流れなのだ。
Lifeゾーンでは最初にでかい樹(幹が液晶か何かの表示デバイスになってる)とその下に生える草をイメージしたのか、たくさんのChromeBookがロボットアームでなびくように動き、それぞれに違う映像が表示される。総合的にみたらすごいはずなんだけど、興味が無いだけかもしれないが表示される映像自体のクオリティはあまり高いとは思えず、今回の各国パビリオンで見せられる(映画とかと比べるとしょぼい)CG動画としか思えなかった。テックワールドにたくさんの種類が居る蝶をスワイプして樹の幹に飛ばす演出もあったが、その蝶もあまり精細さに欠けて個人的にはうーんという感じだった。
Natureゾーンでは最初に4K高精細レーザープロジェクタとやらで、丸い壁にそった巨大なスクリーンに高精細な台湾の自然の映像が流される。これは結構好みだったんだが、途中で一度処理落ちなのかガクっと映像が乱れるところがあっておいおいってなりました。
次に台湾……じゃなくてテックワールドの特産品で輸出業としても存在感のある蘭の展示。蘭自体は綺麗だったんだが、台湾……じゃなかったテックワールド技術のナノスプレーというもので花にTechWorldやEXPO2025等がプリントされており、その部分が自分からは大不評でした。いや印刷はとても綺麗できっと凄い技術なんだろうけども。
次は8Kアートディスプレイとやらが5つほど並んだ部屋で、台湾の芸術家の作品を学習させたAIでそれを動かす展示。ガイドの方が「近づいてみても、本物の絵のようにみえませんか？」とおっしゃってたが、光の反射とかは抑えられて綺麗ではあったが、近づいてよくみると「あー、液晶ですねぇ」という感じでした。AIで静止画や彫刻に動きを出す、というのも好みではなかった。
最後にFutureゾーン。台……テックワールドの「(半導体)チップ」が世界を救う！レベルのチップ推し動画で正直引いた。使われてた合成音声も2025年としては少し不自然なところが気になったし。
すっごいダメだししてるけど、台湾は好きですよ。ほんとに。ただなんか、90年ごろの日本の傲慢さの焼き直しみたいなのを見せられてる気がしてなんだかなぁってなったんです。将来今の日本みたいにならないといいですね。
あー、すみません、大して中の展示覚えてないです。記憶力なさすぎて自分にうんざりだ。
TechWorld出てから即来たのに、リング下にまで列ができていた。が、思ったよりもするする動いて、20分も待たずに入れたように思う。9時入場パワー恐るべし。
スークを模した建築は物凄く雰囲気があってよかった。映画の中に入ったような感覚があった。暗くなってからは壁面にプロジェクションマッピングされるそうで、それはそれで綺麗そうだ。
最初にラクダの毛から織物を織る実演？をしていた。目だけ出てる衣装で下向いて織ってたので、もしかしたらロボットがそれっぽい動きしてただけとかの可能性もあるかもしれない。(多分ない)
あと、自分では行ってないんだけどなんだかトイレを褒める発言が複数回聞こえてきた。
次の万博開催国でもあり(登録博と呼ばれる万博で、EXPO2025もそれ)、金回りがよさそうだみたいな声も複数回聞こえてきた。
サウジアラビア館の3つとなり、いつも見かけるよりも待ち行列が少ないので並んでみる。展示は量的にも結構すくなくて、それに比べて奥のギフトショップがデカすぎでうーんってなりました。あまり心に残るものが無かった……音楽やらの実演ショーがあれば観てみたいんだけども、やってるのかなぁ？
13時20分のチケット配布に何時から並べるのか？と聞いてみたところ、熱中症対策もあってそれは言えない事になっているとの事だった。常識的に考えて1時間前位なんだろどうせ、とあたりをつけて、マイボトルに水を入れるために給水機まで歩いて行った。実はアイルランド館の目の前にも給水機あるのに、ちょっと遠くのところまで……。
戻ってくるころに丁度12時になったので、いわゆる「ガンダム方式」と呼ばれる定時に開放される当日予約枠を抑える。何時にどのパビリオンの枠が解放されるかはggってください。この時に自分がとったのは落合陽一のnull2インスタレーションモードというもの。2時半の予約。携帯ポチポチしながらアイルランド館の前に戻ってきたらなんとまぁ、もう待機列ができ始めてる。1時間前じゃないのかよ！と慌てて自分も並びにゆく。
個人的なアドバイスだが、本万博は待つこと並ぶことを恐れてては良い体験はできない。自分の9時入場も、トイレで無駄(では勿論ないが)にした5分で2000人に先を越された。下手すると20分位は入場が遅れたわけだ。5分の到着の遅れで。「並ばない万博」なんて誰が言ったかしらないが、無責任極まりないデマでしかない。長時間並ばなくて良いのは何らかの手段でとれた予約(2か月前・1週間前・3日前と、各パビリオンの独自予約)だけで、それ以外は全て並ぶ覚悟が必要だ。なので、自分(やその一団)が興味あるものみたいものを公式ページの「イベントカレンダー」なども駆使してきちんと絞り、戦略的に動かないといけない。パビリオン以外にも色々楽しめるイベントは開催されている。
正面の前の方でみるとなると待つことが必要でも、通りがかってみるだけで楽しめるようなものもある。例えば東ゲートからリングに向かっていくとある、大阪ヘルスケアパビリオンリボーンステージという半屋外ステージでは色んな音楽などのショーを頻繁にやっている。6/5も「きいやま商店」という沖縄ロックのグループがやっていた。後ろの方から少し見ていたが、前列真ん中あたりはほぼファンが埋めていたように見えた。タオルを頭上で振るように演者が促すと迷いもせずみんなそうし始めたので。ただ、これをヘルスケアパビリオンが一体どこで告知してるのかよくわからない。「きいやま商店万博」「きいやま商店リボーンステージ」などで検索しても、きいやま商店による告知しか出てこない。リボーンステージの予定表とか無いのかよ？流石に無いわけ無いと思うものの、ggっても見つからないのも事実で、あまりにヘタクソだなぁと言わざるを得ない。
他にも、南ポップアップステージで同日開催されていた、『伝統の中にある未来 -Japanese Spirituality -（伝統文化未来共創Project）』なんかもチラ見したが、時間があればじっくりみたかった。伝統芸能の踊りとかやってた。未来の技術より伝統芸能とかの方が興味あるんだよね。
各国パビリオンの展示、なんかもう似たり寄ったりの所が多くて。テーマに沿ってやるとどうしても似かよるというのもあるんだろうが、それでも。
話がズレすぎたので、アイルランド館の方に戻ろう。
12時過ぎに待ち行列解禁され、パビリオン敷地の砂利道にならぶ。配布は1時間以上後なので、皆砂利の上とか置いてある石の上に座る。そして30分もしない間に待ち行列が配布チケット分を越え、行列末尾でスタッフが「これ以上並んでもチケットもらえない可能性があります」と案内し始める。傍から見ても行列があるから並べるんだろうと思うのだろう(実際自分も以前そう思った)、ひっきりなしに同じ事を繰り返すスタッフ。なんかもうちょっと良いやり方があるんじゃないの？と思うのだが。
そこから10分程したらもう完全に「今から並んでもチケットはもらえません」と、「NO MORE TICKET」とかかれたボードを持ってとお断り状態に。このお断り状態パビリオンが一番ストレスたまるんだよね。自分も数々のお断りをくらいまくってきただけによーくわかる。有志マップなどにある「先着」や「自由入場」を信じて行ってみても「今は並べもしません」、と言われ、いつになったら並べるようになるの？って聞いても大体「わかりません」しか返ってこない。公式サイトの「予約なしで楽しめる」て案内も、実際の所「そこそこ並べば参加できます」なことが殆どだ。割と広い範囲からみえるものな事も有りはするが。
その2へつづく
お前の反論、自分が引き算の美学で事業コストを語れてると勘違いしてるパターン。
でも実態は、事業規模に対する思考スコープの狭さがにじみ出てる。
まず最初に、
それ、論点でもロジックでもなくて、ただの願望自己放尿。中身が一切ない。
これは一見合理的に見えるが、実際は「過剰な単純化」の自己放尿にハマってる。
言ってるのはただ1つ。「JOINを安易に使うな。構造が持つリスクには最初から備えろ」。
将来のトラブルを「避けられる形にしておく」ってだけの話。
たとえば、JOIN構造を避けて辞書キャッシュを設けるのは、初期では数行のコード差。その数行で未来の地獄が避けられるなら、やる価値はある。
JOINを使った全クエリの洗い出し、クエリの再設計、DBインデックス再構成、アプリコードの再配備、キャッシュ整備、パフォーマンステスト、ロールバック対応。
事業全体の工数で見たら、圧倒的に最初に避けとくほうが安いんだよ。
それが見えてない時点で、「事業全体のコスト」とか語らないほうがいい。
言ってることが逆。
しかもね、「事業の初期だから雑でもいい」って、それ本気で言ってるならプロダクトの成功を前提にしてないってこと。
リクエスト数が伸びたら死ぬ設計でリリースして、「伸びたらそのとき直せばいいでしょ」とか言うやつに限って、死んでる間に顧客も信用も消えてる。
初期だからこそ、「伸びたときに対応できる構造」は最低限持たせる。
「JOINは便利だが地雷になりやすい」というのは経験則に基づいた設計判断。
「初期はシンプルに」というのは同意だが、それは未来を無視していいという免罪符じゃない。
「将来の死を回避する設計」＝「複雑化」ではなく、保険と投資。
事業全体のコストを考えるなら、障害で燃える運用コスト・再開発工数も含めろ。
それ、お前の妄想上の素人に向かって自己放尿してるだけで、俺の話には一切当たらない。
こっちは負荷試験そのものの限界性と、それを補完する構造設計の重要性を冷静に語ってるのに、いきなり人格攻撃してくるあたり、論理で勝てないのわかってて感情で殴りにきてるのが丸わかり。
問題は、「それですべて検出できる」と過信して、構造的リスクを無視したJOIN地獄を平気でリリースする思考なんだよ。
負荷試験ってのは後段の保険。設計でリスクを減らした上で、最後の検証として行うもの。
設計段階で「将来のJOIN負荷が怖いから別構造にしよう」と言った人間に向かって、「負荷試験しない素人」呼ばわりは完全に筋違い。手段の順番を取り違えてる。
しかも「マトモな負荷試験やったことない奴が多い」とか言ってるが、それってつまりマトモな設計ができないやつらに向かって、「とりあえず負荷試験で何とかしろ」って押し付けてるだけ。
それこそ素人の発想。
JOINはスキーマ構造の問題、負荷試験は挙動確認の手段。レイヤーが違うんだよ。
さらに言うと、どんなに「マトモな負荷試験」したつもりでも、本番の非線形なデータ増加、スキューのかかったアクセスパターン、ランダムなクエリ負荷、システム全体の複合的ボトルネック、全部再現不能。
わかってる奴は知ってる。負荷試験は通過点であって保証じゃない。
「負荷試験ちゃんとやる」ことと「JOINの構造的地雷から目を逸らさない」ことは両立する。「JOINにリスクがある」と言ったら「素人」と決めつけてくる時点で、お前の設計思考はJOIN脳の自己放尿サーキットで無限ループしてる。
あー、出た出た。「負荷試験で全部検出できる」っていう過信系エンジニアの典型的自己放尿ね。
それっぽい口ぶりしてるけど、中身はかなり雑。
それ、現実では成立しないことのほうが多い。
実データの複雑さ、偏り、スパイク、タイミングの揺らぎ、全部再現不能。
とくにJOINが関わると、クエリプランはデータ量や分布に応じて変化する。
たとえば初期はNestedLoopで爆速だったJOINが、数百万件超えるとIndex Mergeになり、さらにデータが偏ると一気にフルスキャンに堕ちる。「その場では平気」でも、翌月には地獄が来る。
それに、負荷試験では「時間の経過による蓄積的劣化」は測れない。
たとえばバッチ処理や月次分析クエリ、広告配信ログなど、JOIN対象が少しずつ増えていく処理では、初期の負荷試験では一切異常が出ない。半年後、1年後に突然クエリ1本でサーバが沈む。
つまり、「リリース前に大丈夫だった」は、将来の保証にはならない。時間は最強の敵だ。
本当に経験積んでるエンジニアは、「負荷試験で詰めきれないものが必ずある」ことを理解して、そもそもそういう危うい構造を最初から作らないようにする。
JOINを避けるのは、「MySQLがいけてないから」じゃない。「JOINという構造自体が後から効いてくる爆弾だから」。
どんなDB使ってようが、JOINのスケール問題は必ず起きる。
逆。JOINを無警戒に使って設計して、死んだときに「こんなにデータ増えるとは思わなかった」とか言い出すやつが素人。
こっちは、死ぬとわかってる構造を未然に潰してるだけ。その結果が、辞書化・プリロード・キャッシュ・パーティション・非正規形の併用設計。
「JOINのせいにしてる」んじゃない、JOINの限界を理解してるから設計で回避してる。それだけ。
というわけで、負荷試験万能説、JOIN無罪論、MySQLディスり、全部現場経験不足と理屈のすり替えから来てる自己放尿である。
知識の断片で語るな。
JOINは便利。でも無敵じゃない。
あー、それ完全に自己放尿のマジックワード連打だな。「現実として〜」「破綻しません」「シンプルにしましょう」中身ゼロ。
こっちが挙げた定量的リスク（件数増加、I/O負荷、JOINの実行コスト）は無視して、「不安が大きいだけ」「思い込みで複雑にするな」って、論理じゃなくて態度の話にすり替えてる。話をそらすな。
その時点で設計ミスが確定する。ソフトウェア設計ってのは「今小さい」ことよりも、「将来の拡張性に備える」ことの方が重要なんだよ。
仮に今1万件しかなくても、1年後に50万件、3年後に1000万件になる可能性がゼロじゃない。「大きくならない保証」を誰が出してる？お前の感覚か？それただの希望的観測な。
JOINが破綻しない？それ、どこまでのスケールを見て言ってる？MySQLで1000万件×100万件のJOINやってみろよ。スワップ地獄で死ぬ。HashJoinでインメモリに乗らなければディスクIOに落ちて、temptable爆発して終了だ。
「破綻しない」って言葉は、実際に巨大データをJOINさばいた経験があるやつだけが使っていい。少なくとも、現場で何度も「JOINがボトルネックで死ぬシステム」見てきた人間に対して、よくそんな軽く言えるな。
で、「シンプルに書くことが大事」ってのも、すり替え。簡単に書けることと正しく設計することは別。短く書けば正しいって話じゃない。
「JOINで1行で済むからシンプル」って、それは設計放棄の自己放尿でしかない。本当の「シンプル」ってのは必要十分な安全性・効率・拡張性を満たした構造だよ。
「不安が大きい」「思い込み」「シンプルに」全部自己放尿ワード。
こっちは不安を語ってるんじゃない。実測に基づいた将来への備えを語ってる。
そういうのを無視して設計するのはただの怠慢だし、シンプルでもなんでもない。
それ、先送りされた複雑さでしかない。後から破綻して、「なんであのときちゃんと設計しなかったんだろう」って後悔するのがオチだよ。
そうよね
リリース前に負荷試験で危ないクエリ洗い出しておけば安心してリリース迎えられるのに
ああ、なるほどね。「キャッシュは難しいからやるな」理論か。言ってることは一見もっともらしく聞こえる。でもそれ、不勉強を正当化する典型的な自己放尿なんだよ。
まず「キャッシュの無効化は難しい」。これは事実。でもな、それは不変性がない・整合性がシビアな場面の話。今回の話、違うだろ。
usersテーブルを全件辞書にして処理中だけ保持、これって何か？読み取り専用キャッシュだよ。
別にリアルタイム更新追いかける必要なんてない。処理が始まる前に1回SELECTして辞書にしたら、あとは使い捨て。無効化もへったくれもない。
TTLもなし、再取得もなし。ただ「同一処理中は一貫して使う」だけ。
これは「キャッシュ」じゃなくて、「一時的な全件プリロード」だ。
ここを混同して「キャッシュ＝バグの温床」ってのは、コンピュータサイエンスを表面的にしか捉えてない証拠。
それに、「難しいから避ける」は完全に逆。
難しいことを避けてたら、永遠にJOIN脳のまま地雷を踏み続けるだけ。難しさの本質を理解したうえで、管理可能なスコープに抑えるのがまともな設計者の仕事。
例を挙げるなら、バッチ処理の中で毎回同じuser_id →属性を使うなら、辞書化してO(1)参照でさばいた方がシンプルで高速。
JOINなんか使ったらその都度SQL投げて、ネットワーク往復、I/O、最悪クエリプランのキャッシュミス、OOMで大爆死。
キャッシュを使うとバグる、じゃない。バグらせるやつがキャッシュを使うとバグるんだ。
そういう設計が自分にはまだ難しいと思うなら、それは別に恥じゃない。
でも「難しいからやらない」で終わるなよ。キャッシュ使いこなせないなら、JOINの地獄に耐え続ける覚悟を決めろ。それだけの話だ。
あー、なるほどね。「JOINが難しくて避けてるだけなんじゃね？」ってわけか。
甘い。構造わかってない奴ほどそういう浅い自己放尿をしたがる。
まず前提を修正しろ。JOINの動きなんてとっくに分かってる。
SQLの実行プラン追って、NestedLoopかHashJoinか、インデックス使うのかフルスキャンになるのか、そのあたりの判断も含めて運用設計に組み込んでる。
こっちはわかった上で避けてんだよ。JOINを理解してないから避けてるんじゃない、JOINの実コストと限界を知ってるから回避してるの。
JOINってのは便利だけど代償がでかい。たとえば、数千万件のトラフィックログに対して、ユーザー属性をJOINするとしよう。
属性テーブルが1万件程度でも、JOIN時のI/OとCPU負荷は無視できない。結合条件次第ではインデックスも効かなくなる。クエリキャッシュも効かない、結合後にさらにGROUPBYやWHERE使えばオプティマイザの想定外の地雷も踏む。
こっちはそれを全部経験済み。痛みを知ってるから最適化してる。JOINの怖さを知らない素人が、理解できない設計を「逃げ」と断じるのは自己放尿だな。
それに「JOINがわかりづらい」なんて次元じゃない。JOINなんて構文としては簡単だろ？
問題はそれを巨大なスケールで運用したときのトラブルを想定してるかどうかだ。
JOINが原因で1時間かかるクエリになって死ぬとか、JOINが原因でMySQLのtemporarytable溢れてswapに突っ込んでサーバ落ちるとか、JOINが原因でインデックスの設計ミスってテーブルスキャン発生して数億件走査するとか、そういうのを踏んでから語れ。
わかりやすくしとこうか？
JOINを盲信してるのは、「地雷原を地図だけ見て走り抜けようとしてる奴」と同じ。
JOINを避けてるのは、「地雷があるの知ってるから事前に地ならししてる奴」だよ。
「難しいから避けてる」んじゃない。
危険なの知ってるから、先回りして別ルートを構築してるだけだ。
何も知らないで「逃げてる」ってレッテル貼って自己放尿するの、やめとけ。
お前のJOIN観、浅すぎて逆に危ない。
まず、もしテーブルが小さいならそれこそJOINなんてそもそも無駄。
usersが1万件くらいのサイズなら、最初に全件引いて辞書にしておけば、処理時は全部O(1)。
一方JOINはどうなる？SQL構文パース、オプティマイザ、プランの生成と実行、インデックス参照、場合によってはソート・一時テーブル、何重にもコストがかかる。JOIN使うのは、全力で自己放尿してるのと同じ。
「今後も巨大にはならない」
これ、現実逃避の典型な。開発初期で小さくても、プロダクトってのは使われてナンボ。使われればデータは自然に増える。
さらに「本当に巨大なら辞書は無理」って言ってるけど、じゃあJOINならいけると？
脳ミソの冷却ちゃんと回ってるか？
JOINってのは重いんだよ。リレーショナル演算のコスト、現場でまともに見積もったことあるか？
JOINするたびに何十万、何百万件ってレコード舐めて、インデックス使って、それでもI/Oボトルネック起きる。
そういうの避けるためにRedisとか列指向DBとかプリマテリアライズするんだろ。JOINは最適解じゃない、最後の逃げだよ。
結局、JOINを正当化する理由が「JOIN以外知らない」ってだけじゃねえの？
設計手段を学ばず、「それしか知らない」ことを自信に変えるな。
知識の不足を理屈で補うのは無理がある。JOINを使うなとは言わん。でも、JOINが最適って言うなら、それ相応の読み、キャッシュ設計、オプティマイザとの対話が必要だ。
また自己放尿か？
巨大なusersやitemsテーブルを無思慮にJOINすれば地獄の開始だ。
ハッシュ構造で事前展開すれば1回の探索で済むものを、何度もJOINすれば、データベースに無駄なI/OとCPUコストを強いる。
これはもう設計の怠慢であり、JOIN教信者の自己放尿と言っても過言ではない。
あえて君を責めるわけではない。恐らく君は「何も考えなくて済む」設計のほうが精神的に楽だったのだろう。それは理解できる。
だが、システムとは慈悲ではなく要件に応じて応えるべき存在だ。安易なjoin信仰は、時にシステム全体を腐らせる。
最後に言っておく。君も変われる。もしパフォーマンスの地獄を一度でも体験すれば、安易なJOINが気持ちよく出るものではなく、破滅の前兆であることを知るはずだ。
このネット投稿は、データ分析ライブラリであるPandasとAIを組み合わせたデータ処理について、その効率の悪さを強く批判しています。投稿者は、特に以下の点に言及しています。
この投稿は、PandasとAIを用いてデータベースから取得したデータを扱う際に、データの正規化を無視して不必要に結合したり、非効率なデータ構造を選択したりすることへの強い反発と、処理効率を重視するべきだという主張をしています。データベースやプログラミングにおけるデータ処理のベストプラクティスを理解していない、あるいは無視している実装に対しての批判と解釈できます。
令和7年4月1日以降、官報の帰化情報が90日経過で閲覧不可になった。
「プライバシーに配慮」とのことだが、最近の不自然な戸籍不要発言などと合わせて考えると嫌な予感しかしない。
そこでとりあえず官報を保存できるプログラムを作った。自分でダウンロードして保存すること自体は全く問題ない行為。
官報は平日の8:30に公開されるので、cronで8:31とかに実行すると良いのでは。
#官報のPDFデータを入手して保存するimport requestsimportosimporttimefrom bs4 import BeautifulSoupfromurllib.parse importurljoin#対象URLindex_url = "https://www.kanpo.go.jp/index.html"base_url = 'https://www.kanpo.go.jp/'#ダウンロード先フォルダdownload_dir = 'pdfs'os.makedirs(download_dir, exist_ok=True)# ページ取得response = requests.get(index_url)response.encoding = 'utf-8'text =response.text#HTMLを解析soup = BeautifulSoup(text, "html.parser")results = []# 「本日の官報」を対象にPDFの情報を取得するtoday_box = soup.find('div', class_='todayBox')if today_box:dl = today_box.find('dl')dt =dl.find('dt') ifdt: # 日付の抽出date_text =dt.get_text(strip=True).split('\n')[0].replace(" ","").replace("全体目次はこちら","").replace("※インターネット版官報","").strip()dd =dl.find('dd') ifdd: for li indd.find_all('li', class_='articleBox'):title_tag = li.find('a', class_='articleTop')pdf_link = li.find('a', class_='pdfDlb') iftitle_tag andpdf_link:title =title_tag.decode_contents().replace("<br/>", "").strip()url =pdf_link['href'] results.append({ '日付':date_text, 'title':title, 'url':url })# 結果の表示for r in results:date = r['日付']title = r['title']url = r['url'] #pdfファイルのURLを作成url_parts =url.rsplit("/", 1)url_base =url_parts[0] filename =url_parts[1].replace("f.html", ".pdf") converted_url = f"{url_base}/pdf/{filename}" #pdfのURLとファイル名を作成 full_url =urljoin(base_url, converted_url) base_filename =date + "_" +title + "_" + filename.replace("f.html", ".pdf") #ダウンロードして保存print(f'Downloading {full_url} ...')try:response = requests.get(full_url)response.raise_for_status() withopen(os.path.join(download_dir, base_filename), 'wb')as f: f.write(response.content)print(f'Saved: {base_filename}')time.sleep(10) except Exceptionas e:print(f'Failed todownload {full_url}: {e}')
ゆみめに在籍していた頃、自分なりにいろんなことに挑戦してきました。
フルリモート環境での開発、顧客と伴走するプロジェクト推進、スピード感と柔軟性を求められる日々。
ある意味では、技術力だけでなく“人としてどう動くか”が常に問われていた気がします。
あの特有のカルチャーの中で得た経験は、今でも自分の血肉となっています。
そんな中、アセンクチュアという次のフィールドを選んだのは、単なるキャリアアップや待遇の話だけではありません。
もっと深く、組織や産業構造にまで踏み込んだ課題解決に携わりたかった。
アセンクチュアにJoinして最初に感じたのは、「視点の違い」でした。
何を優先するか、どこまで詰めるか、誰を巻き込むか──その一つひとつの判断軸が、これまでとは微妙に、でも確実に異なっていて、正直最初は戸惑いました。
でも、そこでふと気づいたのです。
ゆみめで培った「変化を楽しむ姿勢」と「自走する力」が、実はここでも武器になるということに。
もちろん、すべてがスムーズだったわけではありません。
自分の“当たり前”が通用しない瞬間もあったし、「なぜこうするのか」を徹底的に問われて思考が止まったこともありました。
でも、それを繰り返すうちに、徐々に自分の解像度が上がっていく感覚がありました。
ああ、ここでもやっぱり「学び直し」が求められるんだなと。
これからアセンクチュアにJoinされる皆さんに伝えたいのは、「これまでの自分を疑うことを恐れないでほしい」ということです。
ゆみめでの経験はきっと、あなたの中ですでに強固な土台になっています。
でも、その土台の上に何を積むかは、これからのあなた次第です。
そして何より、「アセンクチュアに入ったからこそ見える景色」が必ずあります。
これは社外からはなかなか見えないし、社内でもポジションによって見えるものが違う。
だからこそ、自分の目で確かめて、自分の言葉で語れるようになるまで、とことん向き合ってほしい。
最後に。
迷ったときには、ぜひ原点に立ち返ってください。
「なぜ、この世界を選んだのか？」
