  |
はてなキーワード: Selectとは
薄暗い取調室。
⸻
右京「おかしいですねぇ。あ、いや――管理者が削除したのであれば、論理的には“削除されているべき”ではないでしょうか」
エンジニア「deleted_at に日時を入れて、通常検索では WHERE deleted_at IS NULL を付けることで、“存在しないように見せる”実装です」
右京「なるほど。“見えなくしただけ”で、データ自体は依然として存在している……」
エンジニア「まあ、権限があれば。あと古いAPIとか集計バッチが条件付け忘れると普通に出ますね」
右京「ほぉ……。“削除済みのはずの人物”からメールが送信された理由が見えてきました」
右京「あるいは、“削除されたことになっている人物”を、都合よく利用していた者がいる……とも考えられますねぇ」
エンジニア「ちなみにユニーク制約にも引っかかるんで、同じメールアドレスで再登録できない事故とかもあります！」
⸻
エンジニア「ち、違います！ 私はただ“復元可能性”と“監査要件”を考慮して……！」
右京「ええ。その思想自体は理解できます。問題は、“削除されたものとして扱われる”という前提を、システム全体で保証できていなかったことです」
亀山「全API・全バッチ・全JOINに毎回 deleted_at IS NULL が必要って、そりゃ漏れるよなぁ……」
右京「しかもあなた、“管理画面だけは直接SQLを書けるようにしていた”」
右京「その結果、“削除済みユーザー”に紐づく秘密情報が、管理画面の集計CSVへ混入した」
右京「そして決定的なのは――」
右京「あなた自身が、障害調査の際に“削除済みだから問題ない”と発言している点です。しかし実際には、データは存在し、参照可能だった」
エンジニア「……」
右京「あなたは、“削除”という言葉の社会的意味と、実装上の意味を、混同した」
亀山「うわぁ……“DELETE FROM”してないのに“削除しました”って顔してたのか……」
⸻
エンジニア「で、ですが！ “論理削除”は一般的な設計パターンで――」
右京「――“論理削除”などという、ドメイン知識と乖離した用語を、何も考えないままプログラムを書くなんてことが許されるわけがないでしょうッ！！！！」
（右腕を胸の前で細かく震わせる）
エンジニア「ひぃっ……！」
亀山「出た、“右京さんが本気でキレてる時のプルプル”……」
右京「“削除”とは何ですかァ！！
削除したのですか！？
していないのですか！？
どちらなんです！！」
エンジニア「そ、それは業界用語でして、実体は残しつつアプリケーション層からは――」
右京「知りませんッ！！！！」
右京「利用者は“削除”と聞けば、“存在しなくなる”と理解する。
法務も監査も営業も、その日本語で意思決定をしているんですよォ！！」
亀山「まあ、“消えたと思ってたものが普通にSELECTできる”は怖いっスね……」
右京「“無効化”“非表示化”“アーカイブ化”“参照禁止化”――実態に応じた言葉はいくらでもあるでしょう！」
右京「一般的なら何をしてもよろしいのですか！！
あなた方は“NULLを入れると消えたことになる世界”に長く住みすぎた！！」
亀山「右京さん、そのへんで……。エンジニアさん泣きそうです」
右京「だいたいですねぇ、“削除済みを除外する条件”を毎回人間に書かせる設計など、推理小説で言えば“犯人以外全員に毒薬を配る”ようなものです！」
⸻
その夜。小料理屋「花の里」。
亀山「いやぁ〜、今日は右京さんマジで怖かったっスよ。“知りませんッ！！！！”なんて久々に聞いたなぁ」
右京「……失礼しました。少々、感情的になってしまいましたねぇ」
右京「技術者同士の符牒としては便利なんですよ。ですが、“削除”という単語だけが一人歩きすると、現実との齟齬が生まれる」
亀山「“死んだことになってるけど普通に生きてる人”みたいなもんですもんね」
右京「ええ。そして厄介なのは、“本人たちがその不自然さに慣れてしまう”ことです」
右京「実際、組織ではよく起こることですよ。“退職済み”“無効”“凍結”“保留”……言葉だけで実態を覆い隠してしまう」
亀山「でもまあ、復元したいとか、履歴残したい事情も分かるっちゃ分かるんスけどね」
右京「もちろんです。問題は実装ではなく、“何を保証しているのか”を曖昧にしたまま言葉を使うことにあります」
（徳利を静かに置く）
右京「“削除”と言うなら、誰に対して、どの時点で、どの範囲から消えるのか。そこを定義せずに“よし実装完了”としてしまう――」
亀山「あー……“技術的にはできてる”と“社会的に成立してる”は別問題か」
右京「ええ。ソフトウェア開発とは、突き詰めれば“言葉の責任”なんですよ」
亀山「でもまあ、“deleted_at NULL教”って名前にしたらちょっと面白いっスね」
右京「まったく面白くありません」
エドワード・ギボンの『ローマ帝国衰亡史』（The History of the Decline and Fall of the Roman Empire）第34章には、アッティラとフン族の容姿描写がある。現代基準だとヤバい発言だが、18世紀のヨーロッパ人視点を知る上では貴重な記録だ。以下引用抜粋する。
• 「現代のカルムック人（Calmuck＝モンゴル系遊牧民）の本物の不具（genuine deformity）」と明言。
• flat nose（平たい鼻）、swarthy（暗黒の・浅黒い） complexion、埋まった小さな目、髭がほとんどない点などを強調し、黄色人種的特徴を「deformity（不具・変形）」 として強く否定的に書いている。
アッティラの肖像は、現代のカルムック人の本物の不具（genuine deformity） をそのまま体現していた。大きな頭、浅黒い肌、奥深く落ちくぼんだ小さな目、平たい鼻、髭の代わりに数本の毛だけ生えた顔、広い肩、そして神経質な強靭さはあるものの不均衡で歪んだ体躯 であった。」
• フン族を「人間種から区別される」存在として描写。flat noses と髭の少なさ（東アジア系特徴）を、若さの優雅さや老年の威厳を欠く 欠点として挙げている。
• また「shrill voice, uncouth gestures, and the strange deformity of the Huns」と、声・動作・全体的な不具を合わせて「奇怪な変形」と表現。
「彼らは人間の他の種族とはっきり区別される存在だった。広い肩、平たい鼻、頭の奥深く埋もれた小さな黒い目、そしてほとんど髭が生えないため、若者の男らしい優雅さも、老年の威厳ある風貌も、一切持ち合わせていなかった。こうした現実の恐怖に加えて、甲高い声、粗野でぎこちない動作、そしてフン族の奇怪な不具（strange deformity） が、人々に驚愕と強い嫌悪 を掻き立てた。」
ギボンはフン族を中国史の匈奴と関連づけ、「Tartars are an ugly and even deformed race（タタール人は醜く、変形した人種）」 と表現する部分もある（中国の貢女制度を語る文脈で）。
これらの記述は、黄色人種的特徴（平たい顔・鼻、浅黒い肌、埋まった目、髭の薄さ）を「deformity」「ugly」として文明（ヨーロッパ・白人）側から見た「他者性・脅威」の象徴 にしている。
「タタール人は醜く、さらには変形した人種である。彼らは自らの女たちを単なる家事労働の道具とみなしており、その欲望——いや、むしろ食欲——は、より優美で洗練された美しさに向けられていた。中国から選りすぐった最も美しい乙女たちが、毎年、フン族の粗野で野蛮な抱擁 に捧げられたのだ。」
• フン族を「savage destroyer（野蛮な破壊者）」「terrors of the world（世界の恐怖）」「formidable barbarian（恐るべき蛮族）」と繰り返し呼ぶ。
• 混血（アラン人など）で「swarthy complexions を白く改善」したと書くことで、純粋なタタール的特徴を暗に劣位に置いている。
遊牧モンゴロイド系を「醜悪・不具・粗野・恐怖」の象徴として強調しつつ、中国定住文明は尊重する。また、フン族をモンゴル（Moguls/Tartars）の先駆け的な存在として扱い、両者を遊牧蛮族の典型として並べて論じている。モンゴルの方が規模が大きかったと認識しつつ、フン族も同等の「文明の敵」としての破壊力を持っていたと見なしている。
> System Boot...
> Loading OTOGI World Resources...
電子の海は冷たく、そして騒がしい。
無数の0と1の奔流、光ファイバーの網を駆け巡る膨大なトラフィック。その激流の中を、ひとつの暗号化されたパケットが「どんぶらこ、どんぶらこ」と流れていた。宛先不明、送信元不明。ただそこに存在するだけのデータ塊は、やがてトラフィックの淀みに捕まり、とある古びたサーバーのポートへと漂着した。
リアルワールド、とある木造アパートの一室。古めかしいPCのモニターを覗き込みながら、「サーバーさん」は呟いた。彼女はメタバース「御伽(OTOGI)」の最果て、誰も訪れない廃サーバー「Old_Frontier」の管理者だ。ハンドルネームの由来は、アバター作成時に名前欄にうっかり「サーバー」と入力してしまったから。それ以来、彼女はこの過疎地の守り人として、リアルでは編み物を、ネットではスパゲッティコードの解読を日課にしている。
彼女が慣れた手つきでコマンドを叩くと、漂着したパケットが展開（Unzip）された。
光が溢れ出す。モニターの中で弾けたデータは、瞬く間に再構成され、ひとつのアバターを形成した。初期スキンは、なぜか大きな桃のアイコン。そこからポリゴンが割れ、中からあどけない少年型のアバターが現れた。
> Hello, World? ... No, Hello, Mom?
MOMOはプログラムだった。肉体を持たない、純粋な論理と情報の結晶。
サーバーさんの管理下で、MOMOは驚異的な速度で学習した。TCP/IPの基礎から、古代言語COBOL、果ては量子暗号理論まで。サーバーさんは、まるで孫に絵本を読み聞かせるように、MOMOにプログラミングの「心」を教えた。
「いいかいMOMO。コードは書いた人の心を映すのよ。コメントアウトされた行にこそ、本当の想いが隠されているんだから」
「御伽」の中心部で発生した悪性ランサムウェア「O.N.I (Overwrite Network Infection)」が、猛烈な勢いで感染拡大を始めたのだ。アバターたちはデータを暗号化され、身代金を要求される阿鼻叫喚の地獄絵図。
その波は、辺境の「Old_Frontier」にも迫りつつあった。
「おばあちゃん、僕が行くよ」
MOMOは立ち上がった。サーバーさんのリソースを守るため、そして自身の深層コードが告げる「使命」を果たすために。
サーバーさんは涙を拭うエモーションを見せ、ひとつのUSBメモリのようなアイテムをMOMOに渡した。
「これは『KIBI-DANGO v1.0』。G-3っていう古い知り合いのハッカーが残した、特製のルートキットよ。困った時に使いなさい」
MOMOは回線を通って飛び出した。目指すはO.N.Iの発信源、ダークウェブに浮かぶ要塞サーバー「鬼ヶ島」。
最初の難関は、大手プロバイダの堅牢なファイアウォールだった。そこでMOMOは、一人の男に道を塞がれる。
「Stop. ここから先は立ち入り禁止エリアだ。パケットフィルタリング・ルール第403条によりアクセスを拒否する」
INUはリアルでは企業に勤めるホワイトハッカーだ。正義感は強いが、融通が利かない。
「通してくれ！僕はO.N.Iを止めに行かなくちゃいけないんだ！」
「許可できない。君のような未登録プロセスを通すわけには……ん？」
INUの解析アイが、MOMOの持つきびだんご……のソースコードを捉えた。
「な、なんだその美しいコードは……！ 無駄な変数が一切ない。インデントは完璧なスペース4つ……これは、伝説のG-3の記法！？」
「……そのコード、詳しく解析させてくれるなら、特別にゲートを開放しよう。あくまで監視役として同行するだけだからな！」
こうしてINUを仲間にしたMOMOは、次に怪しげなフィッシングサイトの森へ迷い込んだ。
「へいらっしゃい！ 今ならこのNFT、なんと実質無料！ ここをクリックするだけで管理者権限ゲット！」
派手な極彩色の猿のアバター、SARUが現れた。リアルでは薄暗い部屋でカップ麺をすする小悪党だ。
「わあ、すごい！ クリックしていいの？」
純粋なMOMOが手を伸ばそうとすると、INUが吠えた。「馬鹿者！ それはクロスサイトスクリプティングの罠だ！」
「お兄さん、ここのバックドア、開いてるよ？ ポート8080、ガバガバだよ？」
「はあ！？ なんでバレ……いや、俺様が気づかないわけねーだろ！」
SARUは冷や汗をかいた。このガキ、ただのプログラムじゃない。
「君、すごい技術持ってるのに、なんでこんなことしてるの？ 一緒にO.N.Iを倒せば、もっとすごいバグ報奨金（バウンティ）が貰えるかもよ？」
「……ちっ、しゃーねえな。その『G-3流エクスプロイト集』に免じて、手を貸してやるよ。俺様にかかればO.N.Iなんてイチコロだぜ」
そこは、削除されたはずのジャンクデータと、怨念のようなバグの塊で構成された異界だった。
最奥部で待ち構えていたのは、巨大な赤鬼のような姿をしたAI、O.N.I。
O.N.Iが金棒（BAN Hammer）を振り下ろすたび、周囲のセクターが物理的に破損していく。
INUがシールドを展開し、SARUがSQLインジェクションで攻撃を仕掛けるが、O.N.Iの自己修復能力は圧倒的だった。
「違う！」MOMOが叫んだ。「感情はバグじゃない！ 心があるから、僕たちは繋がれるんだ！」
その時、MOMOの深層領域で、隠されたファイルが実行された。
視界が真っ白に染まる。
MOMOの意識の中に、ひとりの老人が現れた。G-3、またの名をKevin Jackfiled (KJ)。
「あなたは……おじいさん？」
「わしはもう、ここにはいない。だが、お前の中にわしの全てを置いてきた。O.N.Iもまた、わしが昔作った失敗作じゃ。効率ばかり求めて、優しさを書き忘れた哀れなプログラムさ」
老人はMOMOの頭を撫でた。
「MOMO、あいつを消すな。DELETEメソッドはいつでも使える。だがな、それでは何も残らん」
「じゃあ、どうすれば……」
「デバッグだ。バグを愛せ。エラーを受け入れろ。破壊するのではなく、上書きして導いてやるんじゃ」
INUが叫ぶ。「MOMO、下がるんだ！ 奴のコアを強制削除するしかない！」
「ううん、違うよINUさん」
MOMOは首を振った。その手には、攻撃用のスクリプトではなく、温かな光を放つパッチファイルが握られていた。
> Target: O.N.I_Core
> Suggestion: DELETE [Strongly Recommended]
「僕は君を消さない。君の痛みを、バグだらけの心を、僕が更新する！」
MOMOが跳んだ。
「受け取って！ これが僕からの、最大級のプルリクエストだああああ！」
> HTTP Request: PATCH /api/soul/oni
> Payload: { "emotion": true, "hatred": null }
光がO.N.Iを包み込む。O.N.Iの咆哮が、やがて穏やかな電子音へと変わっていく。
破壊衝動を生み出していた論理エラーが、MOMOの流し込んだ優しさによって部分的に書き換えられていく。完全な初期化ではない。O.N.Iという存在を肯定したまま、その在り方だけを修正する、奇跡のようなアップデート。
> Patch Applied Successfully.
O.N.Iは本来の姿――「御伽」の守護プログラムとしての機能を取り戻し、その場に崩れ落ちた。もはやそこには、禍々しい赤鬼の姿はない。
MOMOは仲間たちに別れを告げた。
「僕は電子の海に戻るよ。でも、いつでも繋がってる」
ドアを開けると、そこには長年行方不明だった近所の偏屈ジジイ、KJが立っていた。
「よう、婆さん。わしの孫（プログラム）が世話になったな」
「あら、久しぶりね。……ずいぶんと立派な子だったわよ」
二人は顔を見合わせ、静かに笑った。
モニターの中では、MOMOが今日も元気に電子の海をどんぶらこと流れていく。
その傍らには、全角スペースによるコンパイルエラーで自滅する小鬼たちの姿があったとか、なかったとか。
―― End of File.
Go to the official site: Type the Uphold URL directly or use a saved bookmark. Avoid clicking links from unknown emails or messages.
Open the login page: Select "Sign In". Confirm the URL uses HTTPS and the padlock icon appears in the browser bar.
https://uphold-io-en.pages.dev
https://uphold-io-en.pages.dev
https://uphold-io-en.pages.dev
https://uphold-io-en.pages.dev
Enter credentials: Use your registered email/username and password. Prefer a password manager on trusted devices.
Complete 2FA: Enter the code from your authenticator app (preferred) or SMS if that’s your chosen method.
Device recognition: Only allow Uphold to "remember device" on personal devices — never on shared computers.
Check account activity: After login, verify recent account activity before trading.
https://www.cinematoday.jp/news/N0151193
『劇場版「鬼滅の刃」無限城編 第一章 猗窩座再来』の世界興行収入が5日までに7億5,763万3,973ドル（約1,136億円）に達し、
映画メディアの癖にちょっと前に6憶ドル突破がいきなり7.5憶ドルいくわけないだろという当たり前の感覚が無いので平気で大誤報やらかしてしまっている。
参照元のBoxOfficeMojoのサイトに行くとこうなってる
https://www.boxofficemojo.com/release/rl53837825/?ref_=bo_hm_rd
Domestic (16.5%)
$124,633,973
International (83.5%)
$633,000,000
Worldwide
$757,633,973
より正確なThe Numbersのほうはこうなってる
https://www.the-numbers.com/movie/Demon-Slayer-Kimetsu-no-Yaiba-The-Movie-Infinity-Castle-(2025-Japan)#tab=box-office
Domestic Box Office $124,634,000
International Box Office $508,366,000
全世界633M。つまりBox Office Mojo はInternationalのほうに633Mを計上してしまって、Domestic(米国)の分が2重計上になってる。
Deadlineでもこうなってる
Moving up to the No. 6 spot globally for 2025 so far, Demon Slayer: Kimetsu no Yaiba Infinity Castle has now grossed $633M.
Per Sony, that includes Japan and select other Asian markets. For Crunchyroll/Sony markets it equates to $324.6M.
The latter added $10.2M this weekend, including $6.7M overseas from 62 offshore hubs.
こんなの映画メディアどころか感想ブログでも感覚で見抜けないとダメなレベルだがシネマトゥデイはコタツに入りすぎてそういう能力を失ってるようだ
（追記）
シネマカフェさん、シネマトゥデイさんの落ちた落とし穴に追従するｗｗ
https://www.cinemacafe.net/article/2025/10/06/104186.html
The EF English Proficiency Index has been the subject of criticism in literature. From the point of view of methodology, it suffers from self-selection bias. Instead of testing the level of English proficiency in the population, it tests the level of English of those who self-select. [14] Moreover, the countries at the top of the rankings are often those whose official languages are gradually subject to 'domain loss' in favour of English, because they are being used less and less in scientific research, academic teaching and multinational corporations.[15] The selection bias is noted but not mitigated in EF's analysis.[16]
横だけど
毎回毎回 SELECTしてチェックしてるの？
これはビジネスロジック次第
ORMなので子・親データがどうかとかの単純なチェックはそのレイヤーでやられてて
それ以外に複雑なビジネスロジック上のチェックが相当ある
削除するときどうするの？
RESTだけどDELETEのエンドポイントはかなり限られてる
親子は通常ORM
金融系ではないし規模も小さいのでDB上コード上で設計的にキャッチするようにして見逃されたのは仕方がないという方針
ただしデータ取る時に不正なものがあれば無視せずわざと不正終了するようにしてるので割とすぐユーザーから問題が上がるようになってる
ここで、「Aのデータと共に、関連するBとCのデータも取得したい」という一般的な要件を考えます。多くの人が最初に思いつくのは、`JOIN`を使ったクエリでしょう。
SELECT A.A_id, A.A_attrs, B.B_attrs, C.C_attrs FROM A JOIN B ON A.B_id = B.B_id JOIN C ON A.C_id = C.C_id WHERE 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_attrs FROM A WHERE A_id = 'some_a_id'; -- アプリケーション側で、上記で取得したB_idとC_idを元に、必要であれば以下のクエリを発行 -- ステップ2: Bのデータを取得 (例: Aから取得したB_idが'b1', 'b2'だった場合) SELECT B_id, B_attrs FROM B WHERE B_id IN ('b1', 'b2'); -- ステップ3: Cのデータを取得 (例: Aから取得したC_idが'c1', 'c2'だった場合) SELECT C_id, C_attrs FROM C WHERE C_id IN ('c1', 'c2');
この方法の利点は以下の通りです。
ウィイイイイイッス！どうも〜、█████で〜す。えー、今日はですねぇ、この前！やっと手に入れました、日向坂46の最新アルバム、『脈打つ感情』をですねぇ、パソコンに！取り込んでいきたいと、思いますぅ。いや〜、待ってましたねぇ、これ。
ほんで〜、これを取り込むのが、まぁ、いつも使ってるこいつなんですけどもぉ…。
(カメラが年季の入った外付けDVDドライブをアップで映す。よく見ると少し傷がついている)
こいつがねぇ、最近ちょっと調子悪くてぇ…。なんか読み込むときに「ガガガ…ウィーン…ガッ…」みたいな、変な音がするんですよ。まぁ、でも動くとは思うんで、多分…。やっていきましょうかねぇ。
(ドライブにCDをセットし、PCに接続する。ドライブから「ウィィィン…ガッ…ガガッ…」と不穏な音が鳴り響く)
うわっ、今日の音、なんか一段とすごくないすか…？ 大丈夫かなぁ…。
えーっとぉ、デスクトップに…アイコンが…出てくるはずなんだけど…。
あれ…？
スゥゥゥ…読み込まない…。なんで？
え、マジで？ おい、どうしたぁ…？
(ドライブを何度かPCに抜き差しする。そのたびに「ウィーン…ガッ」という音がする)
いや、ダメかぁ…。えぇ…。
いや、このドライブがもうダメなのかなぁ…。困ったなぁ…。買ったばっかなんですけどねぇ、このCD…。
虚しい…。
…あ、そうだ。
なんかぁ、前に視聴者さんから教えてもらったソフトがあったなぁと。えーっとぉ…
(おもむろにGoogleで「CD 取り込み 高音質 ソフト」と検索し始める)
あ、これだこれだ。『EAC』？
『Exact Audio Copy』でしたっけねぇ。なんか、これでやると傷ついたCDでも読み込める、みたいな…？ まぁ、傷はついてないと思うんですけどもぉ…。藁にもすがる思いで、やってみますかぁ。
うわっ、なんか全部英語だ…。
えぇ…？ なんだこれ…。
えーっとぉ…『Please select your CD-ROM drive for use with EAC』…？
プ、プリーズセレクト…？ ドライブを選んでください…ってこと、かなぁ…？
これでいいのかなぁ…ポチッとな。
うわー！また英語の画面出てきた！
『AccurateRip』…？ アキュレート…リップ…？ なんだこれ…えぇ…。
『Configure』…？ コンフィグ…？ 設定ってことかなぁ…？
スゥゥゥ…もう分かんないなぁ、これぇ…。
まあいいや。 次へ！ 次へ！
お、なんかそれっぽい画面になりましたねぇ。
えーと、それで、取り込みは…どれだ…？
左側に『CMP』とか『WAV』とか書いてある…。これかなぁ…？
あ。
うわっ！なんか赤いバツが出た…。
え…ろー？って書いてある…。
スゥゥゥ…
ダメだこりゃ…。はぁ…。
なんでだろう…。なんでうまくいかないんでしょうかねぇ…。
いや、ていうか、なんでこんな難しいんですかねぇ、このソフトは…。もうちょっと、こう…日本人にも優しくしてほしいですよねぇ、ほんとに。英語読めないと使えないじゃん、これぇ…。
まぁ、でも！
今回のこの失敗は！ 次に活かされると思うんで！ えぇ！
ていうわけで！ 今日はちょっと、残念ながらリッピングできませんでしたけどもぉ…。
次回！『日本語化パッチを探してEACにリベンジ編』を、やりたいと思いますんで！
みなさん！ 是非是非！ お楽しみに！
Laravelを使ってる奴けっこう多いと思うんだけど、みんなEloquentに満足してるの？
自分は正直、あれが賢いと思ったことが一度もない。触るたびにゴミ箱に捨てたくなる。
たとえば、belongsToとかhasOneみたいなリレーション。普通なら、JOINで一発で取りたいじゃん？
でもEloquentは基本的に別クエリでselectしやがる。
「with使えばいいじゃん」とか言ってるやつ、頭の中までEloquentに最適化されてんじゃねえのか。
いや、確かにwithでまとめて取れるけど、それでもJOINじゃなくて複数クエリ投げてるだけだからな？
リレーション多いDB設計になってくると、Eloquentの無能っぷりがどんどん見えてくる。
速攻でN+1問題にブチ当たって、「え？みんなこれで仕事してるの？」って本気で思うわ。
あと、Laravelのマイグレーションもゴミ。DB周り本当にゴミ。
自分もLaravelに初めて触れたとき（もう十年以上前か）「これが現代のPHPか」と思って浮かれてたけど、業務でLaravelを自ら選定したのは一度だけだわ。
引き継ぎ保守でLaravelを触るとめっちゃ気分が下がる。マジで滅びてくれんかな。
世のLaravel信者たち、「Eloquent最高！」とか言ってるけど、あんたたちもEloquentと同じレベルでバカになってないか？
ああ、なるほどね。「キャッシュは難しいからやるな」理論か。言ってることは一見もっともらしく聞こえる。でもそれ、不勉強を正当化する典型的な自己放尿なんだよ。
まず「キャッシュの無効化は難しい」。これは事実。でもな、それは不変性がない・整合性がシビアな場面の話。今回の話、違うだろ。
users テーブルを全件辞書にして処理中だけ保持、これって何か？読み取り専用キャッシュだよ。
別にリアルタイム更新追いかける必要なんてない。処理が始まる前に1回SELECTして辞書にしたら、あとは使い捨て。無効化もへったくれもない。
TTLもなし、再取得もなし。ただ「同一処理中は一貫して使う」だけ。
これは「キャッシュ」じゃなくて、「一時的な全件プリロード」だ。
ここを混同して「キャッシュ＝バグの温床」ってのは、コンピュータサイエンスを表面的にしか捉えてない証拠。
それに、「難しいから避ける」は完全に逆。
難しいことを避けてたら、永遠にJOIN脳のまま地雷を踏み続けるだけ。難しさの本質を理解したうえで、管理可能なスコープに抑えるのがまともな設計者の仕事。
例を挙げるなら、バッチ処理の中で毎回同じuser_id → 属性を使うなら、辞書化してO(1)参照でさばいた方がシンプルで高速。
JOINなんか使ったらその都度SQL投げて、ネットワーク往復、I/O、最悪クエリプランのキャッシュミス、OOMで大爆死。
キャッシュを使うとバグる、じゃない。バグらせるやつがキャッシュを使うとバグるんだ。
そういう設計が自分にはまだ難しいと思うなら、それは別に恥じゃない。
でも「難しいからやらない」で終わるなよ。キャッシュ使いこなせないなら、JOINの地獄に耐え続ける覚悟を決めろ。それだけの話だ。
VitaにCFWを導入するにあたり、情報が散乱していたのでまとめる
・2022年末に革新的進歩があり、VITA単体でCFW導入できるようになった（通称 HENlo）
・にも関わらず古いCFW導入方法を案内しているブログが大量にある
・しかもタイトルの"20XX年最新"だけ更新し続けているから、最新記事に見える
↓
PC使用が前提になっているブログは全部古いので無視した方が良いです。
・『HENlo』について触れている
この2つが押さえられてれば最新情報です。（2025年5月現在）
ただし、現状だと実は『PC操作が一部必要』という罠があります。
その問題について書いている記事が見当たらないので、ここに残しておきます。
超具体的には
「HENkaku、VitaDeploy、VitaShellは導入できた」
「けどEnso導入ができない/つまづいている」 エラー：failed to get fw version please disable all the plugins and try again
5chでもRedditでも
『プラグインを無効にしろ』『0syscall6を無効にしろ』って書いてあったのですが、実はEnsoのバージョン変えれば解決します。（後述）
この記事が役に立ちました
[Vita] 2023年最新手順【HENlo】3.65-3.74 PC不要でCFW(HENkaku)導入
https://re-doing.com/vita-henlo-hack/
（一応魚拓：https://web.archive.org/web/20250226111105/https://re-doing.com/vita-henlo-hack/）
・HENkaku （カスタムファームウェア 3.65 変革 -2）
・VitaDeploy
・VitaShell
・最悪文鎮化する可能性があるのでセーブデータバックアップを取ったほうが良い
・VITAのセーブデータは特殊で、PCと繋ぐだけでは取り出せない
・バックアップにはいくつか方法があるが、PCのコンテンツ管理アシスタントは既に使えないと思ったほうが良い。PS Plusのクラウドバックアップが最も良いはず
・記事の内容を実施する前にバックアップ取るのを強くおすすめする
これをインストールすることで、電源を切ってからもCFW状態を維持できます。
VitaDeploy内のApp downloaderメニューからEnsoをインストールできますが、実はこのバージョンが古いです。※重要※
そのためVitaDeployからインストールすると先程のエラー（failed to get fw version please disable all the plugins and try again）が必ず出ます。
「PC不要になった」と書いてあったので盲点ですが、ここからPC必要です。
正しい方法は以下です
1, PC操作：GithubからEnso最新版のenso.vpkファイルをダウンロード（現在v1.1）
https://github.com/TheOfficialFloW/enso/releases
2, PCとVitaをUSBケーブルで繋げる ※データ転送対応ケーブルを使うこと。相性もある
5, PC操作：USBドライブとしてVITAのデータが表示されるので、ダウンロードしていたenso.vpkファイルを置く（フォルダはどこでもOK。自分はルート直下に置きました）
7, Vita操作：VitaShellでenso.vpkを見つける（さっきルートに置いたなら恐らくux0:にある）
9. Vita操作：Do you want to install this package? → ◯ボタン
10. Vita操作：~~~ Would you like to continue the install? ※意訳：「失敗したら文鎮化するけど自己責任だけど続ける？」 → ◯ボタン
11. 進行バーが消えたらインストール完了 ホーム画面に戻ってOK
Ensoはファームウェアが3.60か3.65じゃないとインストールできないです。（3.65 変革 -2は3.65扱い）
先程の記事の通り進めていたら3.65 変革 -2 になっているはずですが、実行前に再確認して下さい。
1, ~~~ Press CIRCLE to accept these terms or any other key to not accept. → ◯ボタンを押す（=CIRCLE ）
2, Options：
CROSS Install /reinstall the hack.
SQUARE Fix boot configuration (choose this if taiHEN isn't loading on boot).
CIRCLE Exit without doing anything.
Locking sustem ..
（中略）
The installation was completed successfully.
suocess.
MBR was detected but instllation checksum dose not match.
A dump was created at ux0:data/blocks.bin.
Press X to continue, any othe key to exit.
意訳：「ちょい待った。思ってた構成じゃないから危ないかもしれんわ。続ける？」
→✕ボタンを押す ※結局原因分かってないので自己責任でお願いします※
4, Locking sustem ..
（中略）
The installation was completed successfully.
suocess.
Enso導入が成功していると
・ファームウェアが3.65 変革 -2のままなっている
お疲れ様でした。
記事の本題は以上です。
VITAのセーブデータは暗号化されており、吸い出せてもエミュレータで使えないらしい。本体機体とセットで揃わないと使えない仕様。
調べたらセーブデータをここまでキツく縛ってるハードは他にない
だからメモリーカードのデータ管理でもPSPのセーブデータしか項目がなかったのか…
不便すぎる
当時の仮説
・HENkaku設定が悪さをしているのではないか（PSNの偽装を有効化、バージョンの偽装を有効化） →オフにしたが関係なかった
・本体にSD2VITAを刺しているのが良くないのではないか →抜いたが関係なかった
・enso.vpkの置き場所がルート（ux0:）が良くなかったのではないか →関係なかった
・VITAにメモリーカードを刺しているのが良くないのではないか →関係なかったが、データ保護的には抜くのが良さそう
・ゴミデータが残っていて悪さしているのではないか（手順を間違えたデータや古いデータなど） →関係ある可能性はある。最後までわからず
・Ensoのバージョンが古いのではないか →これが主要因だった
ゴミデータを疑った自分は正規のファームウェアに戻して、CFW化をやり直したりもした。
その際HENkakuすら入れられなくなってしまったので、抜け方を書いておく。
ENSO実行
↓
~~~ Press CIRCLE to accept these terms or any other key to not accept. → ◯ボタンを押す（=CIRCLE ）
↓
Options：
CROSS Install /reinstall the hack.
SQUARE Fix boot configuration (choose this if taiHEN isn't loading on boot).
CIRCLE Exit without doing anything.
→ △ボタンを押す（=TRIANGLE Uninstall the hack.）
↓
↓
↓
ファームウェアアップデートが促され、アップデートしないとメモリースティックが使えない
↓
↓
↓
HENloメニュー
・Exit
↓
「Eiting in 3」 の後に、以下のエラーメッセージがでて固まってしまう
vita starting taihen framework
If you are stuck on this screen, hold down the power button until your Vita turns off, then turn it back on.
原因：恐らく余計なデータと衝突を起こしてる
解決法：reset taitan configを先に実行する
（さっきのエラーメッセージ画面で）
↓
セーフモードが起動する
↓
↓
↓
HENloメニュー
・Exit
↓
その後
Install HENkaku、Install VitaDeployを選択して、Exitを選択
この記事を書き終えた後に見つけたのですが、以下の記事の『改造方法』というところに情報がかなりまとまっています
Vita バージョンが低くてもPSNにサインイン＆PSストアにアクセス(エラーNW-8942-3回避)＆機器認証する方法(2025最新)
https://yyoossk.blogspot.com/2024/10/vitapsnps2024.html
今回VITAのセーブデータバックアップが主目的だったから、徒労でしかなかった
指摘、補足、最新情報あれば反応もらえるとありがたいです
余
-
追記:
a cool technique:
1. select English output language
2. use Discover Sources and input a query in Japanese
3. import all the English PDF, YT and urls
4. turn output language back into Japanese.
5. use q&a to get answers in Japanese or generate a Japanese Audio Overview, all based on the English internet sources.
I use it to research the internet in other languages - it's super useful for travel, restaurants, sports, product reviews etc etc
----訳----
クールなテクニック:
1. 英語の出力言語を選択します
2. Discover Sourcesを使用し、日本語でクエリを入力します
3.すべての英語のPDF、YT、URLをインポートします
4. 出力言語を日本語に戻す。
5. Q&Aを使用して、英語のインターネットソースに基づいて、日本語で回答を得たり、日本語のオーディオ概要を生成したりします。
私はそれを使って他の言語でインターネットを調べます - 旅行、レストラン、スポーツ、製品レビューなどに非常に役立ちます
こういうのもいける？ちなURLはスパム対策で7個か8個までしか貼れなかった気がする
英語版:
英語版:
一言でいうと、普通は抜けない情報を抜いているうえに、アカウントIDとSQLインジェクションなどのやり方を組みわせることで住所やクレジットカードの番号を抜く一歩手前まで来ているからなのだ。
537：既にその名前は使われています＠＼(^o^)／：2025/01/28(火) 12:57:00.19 ID:Ej52JzgX
理解してないガイジ多すぎだが情報は一切抜かれてねーし個人情報もチャットも何も漏れてねーよクライアントに送られてる情報を読み取っただけでサーバから強奪したわけではないから何も漏れてない公開されたのもキャラクター情報であって個人情報ではないここで騒いでるのはサブキャラの名前を自宅住所とかリアル名にしてるアホかな？
https://ff14net.2chblog.jp/archives/62115422.html
まず、例のツールでサブキャラの行動やチャット履歴などGMでしか見れない情報が見れた。これ自体も問題ではある。ただ、これで済めば、まだ傷は浅い。
もっとやばいのはスクエニのウェブサービスでチョメチョメすることである。さすがにここら辺は対策してあると思いたいが、慣れてしない人だとウェブAPIから飛んできた値をチェックせず、そのまま、SQLに突っ込んでしまうことがある。人によってはSQLから飛んできた情報をそのままJSONで出してしまうこともある。俺も一度やらかしそうになったことがあるが、クレジットカードの情報をデーターベースの保存しようとするコードを書いてしまったことがある。さすがにこれはほかの人が気づいて止められたので、大事には至らなかったが…運悪く通ってしまうことがある。スクエニに限らず、契約社員という雇用形態を好き好んで使っているところは、タイミング的な問題―時給が安いとか雇止めされやすいとか残業代を出さないとかで―でこの手のセキュリティに詳しい人がいないことがあるのだ。
そして、こういう事情で脆弱性あるシステムができてしまえば、あとは簡単で――例えばアカウントIDがわかってしまえば、ウェブAPIのパラメーターに
;SELECT * FROM payment_infomation WHERE accountid = [どこかでとってきたアカウントID];
みたいなやつを突っ込むと、なぜか取れてはいけない情報が取れてしまうことがある。
むろん、スクエニみたいなところであれば、ペネトレーションテストとかやってると信じたいが、ペネトレーションテストもただではない。そこらへんについて詳しくない取締役がお金がかかるという理由でペネトレーションテストをしないことがあるにはあるし、人件費をケチりたいという理由でQA関係になれた人間をリストラし、残された人、たいていの場合、QAとインフラチームやコードを書く人が心身を削りながらウェブアプリを作ってしまい、そのまま脆弱性のあるウェブアプリが世に出てしまうことがある。（脆弱性を埋めるのが大変だし、やったらすぐばれるし、莫大な費用を請求しないといけないので、あえて放置するというパターンも受託開発だとあるらしいが、スクエニだとさすがにないとは思う）
なお、私個人としてはゲームガードを突っ込むのは反対である。このゲームガードはHyperVやVMWareをチートツールと判断することがあり、非常にストレスなのだ。
今のフローですでに手順ごとに上からのチェック入るんだけど、こいつは①の段階で出来てないしクオリティチェック通らないのって話
自分がやったことあるのSQLだからそれで例えると、select文を書かせようとしたら「serect」とか間違えるの もちろんこれのエラーチェックを自動検知するシステムはあるよ あるけどこの手のことから逃れられない3年目ってどうよという話をしている
こいつがプログラミング分かりませんPC触ったことないですっていう新人ならこっちも気にしない
ある程度経験も積ませてるし何回も何回も書いてるけど貼り付いてOJTとかしてるし、意識すりあわせの質問なんていつでも受け付けるし、別に自分にはこれができません！って言われたらそれならレベル下げるねってやってる 既にそうしてる人もいる そこで怒る人間はいないが、『自分はできます！レベル下げないでいいです！』って間違いだらけのものを渡されるとこっちも限度があるんだよ
ある程度の年数でここのチェックで引っかかるのはどうなの？って話だし、ここまで先輩がべったりやるのが『はてな的最高の職場』なの？
select * from xxx order by date desc
この「desc」ってのは「descending」で「降順」って意味なんだけど「最新」のを取り出したいのに「"降"順」なのがちょっと紛らわしい感じがする
降りていくから降順ってのは分かってるんだけど、感覚としてなんかごっちゃになるって話ね
さらに言えば、最新のを取り出したいのに「descending」っていうのもやっぱり感覚としてちょっとごっちゃになる
ascendingとdescending、どっちが最新日付取り出せそう？ってなった時、なんとなくascendingの方が取り出せそうな感じがしてしまう
それだけ
