  |
はてなキーワード: オブジェクトとは
画像を生成するAIによる無断学習や利用を防ぐために、以下のような対抗手段を講じることが可能です。
1.透かし（ウォーターマーク）の埋め込み:
画像に目に見えるまたは見えない透かしを入れることで、無断利用や生成AIの学習に対して抑止効果を期待できます。特に、目に見えない形で画像データに暗号的な透かしを埋め込む「デジタル透かし」技術が有効です。
画像データに著作権情報や「AIによる無断学習を禁止する」といったメタデータを埋め込み、ウェブサイトには robots.txt ファイルで画像クローラーのアクセスをブロックする設定を追加します。これにより、クローリングや収集の抑制が期待できます。
ステガノグラフィを用いて、画像に気づかれにくい形で識別情報を隠すこともできます。これにより、画像の流出経路や利用先を追跡でき、無断利用の発見に役立てることができます。
4.法的な警告表示や利用ポリシーの明示:
ウェブサイトや画像の配布先に、AIによる無断利用や学習を禁止する旨の法的警告や利用ポリシーを明示することも有効です。利用条件をはっきりと示すことで、AI企業や研究者が慎重になる可能性が高まります。
AIが利用しにくいように、画像に人間には気づきにくいパターンやノイズを挿入する技術もあります。たとえば、AIにはノイズとして認識されるが、人間には問題なく見える小さな変形やカラーパターンを追加することで、AIによるデータ学習が困難になる場合があります。
生成AIの学習を混乱させるための手段には、以下のような方法が考えられます。
1.ノイズや歪みの追加:
画像に目立たない程度のノイズや歪みを加えることで、アノテーションモデルが境界や特徴を正確に認識しにくくする手法です。たとえば、ピクセルレベルでランダムなノイズを追加する、わずかに画像をぼかす、あるいは境界線付近に小さな変化を加えるといった手法が有効です。
アノテーション処理は、対象物の輪郭や特徴を正確に捉えることが重要です。そのため、背景や対象物の輪郭にわずかな不規則性を加えることで、アノテーションツールが対象物の境界を正確に判断しにくくすることができます。たとえば、背景に模様や偽の輪郭を挿入する方法です。
画像に人間には視認しづらい形でテキストやラベルを埋め込むと、AIのアノテーションプロセスが混乱する場合があります。これにより、AIが意図しない領域を注視することがあり、誤認識を誘発します。
4.色や明るさのランダム変化:
画像の色や明るさを部分的に変化させ、一定のパターンを持たないようにすることもアノテーション処理の混乱を招く一手です。これは、オブジェクトの検出や認識が色や明暗の差異に依存している場合に有効です。
5.擬似的なオブジェクトの追加:
画像内に小さな擬似的なオブジェクトや模様を追加することで、AIがそれらを誤って主要なオブジェクトと認識し、アノテーション精度が低下する可能性があります。特に、背景に似たオブジェクトを散りばめることで、AIはどの部分が対象なのか判断しにくくなります。
AIの認識を誤らせるために用いられる「アドバーサリアル（敵対的）な例」を使う方法もあります。特定のピクセルパターンや色の配列を配置することで、AIのアノテーションが意図的に誤作動するよう誘導できます。この技術は深層学習モデルに対して特に効果があります。
画像全体にわずかなカモフラージュパターンを重ねることで、AIの認識を混乱させる方法です。この手法では、人間が見た場合には問題なく認識できるものの、AIが対象を捉える際に誤って検出するようなパターンを画像に追加します。
・思考実験として、danbooruなどアノテーションの元データとして使われているサイトのタグが荒られたら画像生成AIのモデル作成にダメージはありますか？
思考実験として、Danbooruといったアノテーション元データのタグが荒らされた場合、画像生成AIのモデル作成に与える影響は以下の通りです。
Danbooruは、イラストや画像に対して詳細なタグが付与されており、これらのタグ情報は画像生成AIの学習にとって非常に重要です。タグが荒らされることで、画像とタグの対応関係が崩れ、モデルが正確な特徴を捉えにくくなるため、生成精度が低下します。
例えば、特定のキャラクターやテーマに関連するタグが荒らされ、誤った内容のタグが付与されると、モデルはその誤った情報を学習し、キャラクターの特徴や設定が再現されにくくなる可能性があります。
タグが荒らされると、モデルの訓練にノイズデータが増えるため、学習効率が悪化します。たとえば、「黒髪」のタグが誤って「金髪」などに変更された場合、モデルは同じ画像に対して異なる特徴を学習することになり、結果として生成画像の一貫性が失われることが考えられます。
また、同じ画像に異なるタグが付与されることで、モデルが過学習や誤学習を引き起こし、生成された画像が本来の意図からかけ離れたものになる可能性もあります。
Danbooruでは、特定のキャラクターやアートスタイルを識別するタグが多く存在します。これらが荒らされると、特定のキャラクターやスタイルのデータが混乱し、モデルが正確にキャラクターの特徴を把握できなくなるため、ユーザーが期待する生成結果が得られにくくなります。
例えば、あるキャラクターのタグが「髪型」「服装」「色彩」などで荒らされると、そのキャラクターの再現が曖昧になり、モデルが正しいビジュアルを生成できなくなることがあります。
タグが荒らされると、データセット全体の信頼性が低下します。信頼性の低いデータをもとに学習したモデルは、特定の条件で異常な出力を生成することが多くなり、モデル全体の品質が低下します。これは、生成AIが学習中に「どの情報を信頼すべきか」を判断できなくなるため、生成結果が不安定になったり、多様性が失われたりすることが考えられます。
AIモデルを利用するユーザーは、タグを通じて希望する画像を生成したり、条件に合った画像を探します。タグが荒らされると、AIモデルの検索・フィルタリング機能の精度も低下し、生成プロンプトが期待通りに機能しなくなる可能性があります。たとえば、「風景」タグが荒らされ、異なるジャンルの画像が混入するようになると、風景画像を生成したいユーザーの要求が満たされにくくなります。
Danbooruなどのタグが大規模に荒らされた場合、生成AIモデルの精度低下や一貫性の欠如が発生しやすくなり、特にキャラクターや特定のスタイルに依存する画像生成モデルに大きなダメージを与える可能性が高いです。
すでに学習済みのモデルを使って汚染されたデータのクレンジングや異常値検出を行うなど対策される可能性がありますが、それらを阻害する手段はありますか？
無断での学習を妨害し、学習コストを増加させるために、上記の方法を阻害する手法には以下のようなアイデアがあります。これらの手法は、意図的にデータセットの品質や一貫性を崩すことで、学習モデルの精度を低下させ、データクレンジングや異常値検出のプロセスを複雑化することが目的です。
意図的に誤ったタグや無関係なタグを画像データに付与し、データセットの信頼性を低下させます。これにより、転移学習やラベルノイズ検出が困難になり、正確な特徴量を学習するコストが増加します。
例えば、キャラクター画像に全く無関係なタグ（「動物」や「風景」など）を追加することで、モデルがどのタグが信頼できるか判別しにくくなり、誤ったラベルがノイズとして学習されるリスクが増えます。
2. 特徴量をぼかす／微妙な変更を加える
特徴量ベースのクレンジングや類似度分析に影響を与えるため、画像の特徴がわずかに異なるように加工を施します。具体的には、色調を微妙に変える、ランダムなピクセルの位置でノイズを追加する、または特定の部位を意図的にぼかすことで、モデルが抽出する特徴量の安定性を低下させます。
この方法により、同じキャラクターやスタイルであっても類似度分析が困難になり、正確なクレンジングが行いにくくなるため、データ処理のコストが増加します。
特徴が異なるバリエーションや擬似的な異常データを大量に追加することで、異常検出アルゴリズムの信頼性を下げます。たとえば、キャラクターのデザインや背景を少しずつ変えた画像を意図的に作成することで、異常値検出が頻繁に誤検出されるようにします。
こうしたデータが混在することで、オートエンコーダーやアンサンブルモデルを使った異常検出が混乱し、正確な異常サンプルの抽出が困難になります。
4. 高頻度で微小なラベル変更を行う
学習済みモデルの転移学習やラベルノイズ検出を阻害するために、同じ画像に対してラベルを定期的に変える手法です。微小な変更を行うことで、モデルは正しいラベルを安定的に学習することが難しくなり、モデルの信頼性が低下します。
例えば、ラベル「黒髪」を「暗めの髪」や「濃い色の髪」などに頻繁に切り替えることで、学習に不確実性を持ち込むことが可能です。
データセット内で非常に類似した画像を複数の異なるタグで登録することで、モデルの学習を混乱させます。特定のキャラクター画像を少しずつ変化させて複数のタグを付けると、モデルは「どのタグがどの特徴に対応しているのか」を判別しにくくなり、データセットのクレンジングが複雑化します。
特に、タグの一貫性が失われるため、類似度分析やアンサンブルモデルによる異常検出の効果を低下させることが期待できます。
AIモデルが認識を混乱させるように、アドバーサリアルノイズ（敵対的な例）を追加します。人間にはほとんど気づかれないレベルのノイズを画像に追加し、モデルが特定の特徴を正確に認識できないようにすることができます。
このノイズにより、モデルの特徴量ベースの学習が混乱し、意図した通りに学習できないため、クレンジングの精度も低下し、データ処理の手間が増加します。
特定のルールではなくランダムにタグをつけたり、特定のカテゴリ間でランダムにラベルを入れ替える方法です。これにより、ラベルと画像の関連性が薄れ、アノテーションの一貫性が失われます。この乱数による偽ラベルの付与は、ラベルノイズ検出やアノマリー検出において、真のラベルを見極めるコストを大幅に増加させます。
まとめ
これらの手法は、AIの学習やクレンジングを意図的に妨害し、無断学習にかかるコストを増加させるために有効です。特に、「微小な変更」や「アドバーサリアルノイズの付与」といった手法は、見た目の品質に影響を与えずにモデルにノイズを持ち込むため、非常に効果的です。
＞＞カードゲームについて語る奴らの多くが「MTGが始祖」と勘違いしてる
カードゲームについて語る奴らの多くが「カードゲーム＝TCG」の意味で使ってるから間違ってない。この風潮は個人的にもどうかと思うが普及してるので仕方ない。
それは分類としてはカードゲームではなくボードゲームなんや。ドミニオンもボードゲーム。
＞＞そしてそういうゲームは売上が伸びると定期的に拡張パックでカードを増やしていた。
＞＞MTGはこのシステムをトレーディングカードとくっつけただけ。
逆。拡張パックでカードを増やすトレーディングカードが先にあり、それに本格的なゲームをつけたのがMTG。
＞＞MTGのマナのシステムも別に画期的ではなく、MTGがベースにしたカードゲームよりも更に以前から、そもそもボードゲームという文化の中にコストという概念があった。
＞＞デッキという概念はそれこそカードがまだゲームとして遊ばれてもいないタロットカードの時代からあった。
＞＞手持ちの兵隊をぶつけあうのなんてのはボードゲームの初期の初期からあるものだし、そこに特殊なオブジェクトを加えるのは軍棋などでは当たり前の要素だ。
マナシステムの画期性はデッキやその中の”兵隊”と合わさっってのものだから、これらを分けて論じるのはマナシステムの何が画期的だったのか解ってない。
＞＞MTGが本当に発明したのはカードゲームのルールではなく、トレーディングカードをゲームとして本格的に遊ぶというフォーマットぐらいなんだよ。
MTGが発明した「デッキ構築」はカードゲームのルールでしょう。
＞＞ソイツは元から無電源ゲームの世界に無数にあった要素を上手い具合に再配置しただけなんだ。
無電源ゲームの世界に無かった「トレーディングカード」という要素を持ち込んだからMTGは「TCGの始祖」であり、「カードゲーム＝TCG」と認知される程に流行してるんだ。そこが分かってからアレコレ喋ってほしい。
そしてそういうゲームは売上が伸びると定期的に拡張パックでカードを増やしていた。
MTGはこのシステムをトレーディングカードとくっつけただけ。
つまり、トレーディングカードとカードゲームを、カードという共通点を足がかりにして一つにしただけなんだよね。
MTGのマナのシステムも別に画期的ではなく、MTGがベースにしたカードゲームよりも更に以前から、そもそもボードゲームという文化の中にコストという概念があった。
ある行動を起こすには、ある駒やチップをいくつか使う必要があるとかなんとかって形でだ。
デッキという概念はそれこそカードがまだゲームとして遊ばれてもいないタロットカードの時代からあった。
手持ちの兵隊をぶつけあうのなんてのはボードゲームの初期の初期からあるものだし、そこに特殊なオブジェクトを加えるのは軍棋などでは当たり前の要素だ。
MTGが本当に発明したのはカードゲームのルールではなく、トレーディングカードをゲームとして本格的に遊ぶというフォーマットぐらいなんだよ。
それなのにカードゲームについての大枠を語る奴らはすぐに「知っての通りMTGこそがあらゆるカードゲームの始祖なんですが」みたいに言う。
違う違う。
ソイツは元から無電源ゲームの世界に無数にあった要素を上手い具合に再配置しただけなんだ。
そこが分かってからアレコレ喋ってほしい。
おいお前ら表題の件につきまして、ご覧になりまして？
https://shonenjumpplus.com/episode/17106567256672633938#
・このマンガは鳩っちという陰の者、なれどストイックな求道者がそのストイックさで衆生に影響を与えることがメインのプロット
・たまきn先輩がらみのバンドには銀杏BOYZを取り入れてるが、流石にキラキラカワイイ系のたまきn先輩に銀杏BOYZはエグみが強いだろ、と思ったら、たまきn先輩の人生そのものがエグみが強くて銀杏BOYZを当てることがニンニクしょうが並の、カロリーを臭みで消す二郎レシピになってる
・出内先生の、クワハリ先生が表現したいことへの理解力と、キャラ作画だけではなくモブや背景、物品オブジェクトに至る全てがクワハリストーリーの文脈にドンピシャにハマっている
・そしてこの回で不敵に嗤う鶴先輩（と怪僧厘ちゃんさん）
「ふつうの軽音部」の「ふつう」とは何か、ふつうの高校生衆生が触れるのは、般若心経ならぬどんな「軽音」なのか、はたまた「恵音(Amazing grace)」なのか。
「ふつうの」青春群像劇から、宗教的説話に跳ね上がるターニングポイント回だったと思う。
ところで宗教用語っぽいものを散りばめているが、「スヤスヤ教」ぐらいの娯楽と思ってね。たかがRock'n'Roll(Acid Black Cherry)だもの。
現在も隆盛を極めるリズムゲームのルーツ…のひとつであるビートマニア。
（もちろん、1年先にリリースされたパラッパラッパーの方が「すべての音楽ゲームのルーツ」だが、
「上から降ってくるオブジェクトに合わせてボタンを押す」フォーマットを完成させたという意味では直接のルーツにあたる）
その第1作に、最高難度を誇るいわゆる「ボス曲」として収録されて人気を博した「20,november」。
ただ闇雲に難しいわけではなく、「曲を覚えて、メロディやリズムを理解し、練習を重ねれば攻略できる」という絶妙な難度で音楽ゲームの楽しさを世に知らしめた点でもその功績は大きい。
（ちなみに、曲名の「11月20日」は作曲者の DJナグレオ こと 南雲玲生の誕生日である）
ビートマニアの象徴ともいえる存在で、数多くのバージョン違いも作られた。
本エントリではそれを紹介する。
（収録されたゲームやCDによって曲名、アーティスト名ともに表記ゆれが多い（カンマの後のスペースの有無、大文字/小文字など）が、基本的にそのバージョンの初出での表記にしている）
https://www.youtube.com/watch?v=RMNtlYObHCw
初代 beatmania (1997) 収録の 元祖 20,november。
……なのだが、「20,novem v er」と盛大に誤字をやらかしている（もちろんその後のバージョンでは修正されている）。
ジャンルは「HOUSE」。曲名ではなく、こちらで覚えている人も多いかもしれない。
https://www.youtube.com/watch?v=4XX2BdNtJyU
同じく初代 beatmania 収録。single mix とは曲構成が異なる。
2人プレイ、もしくはダブルプレイ（左右の鍵盤とターンテーブルを1人で操作するモード）だとこちらのバージョンになる。
https://www.youtube.com/watch?v=YR3oKco-Xp8
3作目「beatmania 3rdMIX」(1998) で追加された、いわゆるアナザー譜面（オブジェクトの配置を変えて高難度化したバージョン）。縦連がいやらしい。
初出の 3rdMIX ではゲーム内に「nagureo kidding style」の表記はなく、後のバージョンで追加された。
https://www.youtube.com/watch?v=v0N_fHRgdJM
同じくアナザー譜面。鍵盤の数が 5つから 7つに増えた姉妹作、 beatmania IIDX の 1.5作目「beatmania IIDX substream」(1999) で登場。
substream と「beatmania IIDX 2nd style」(1999) の 2バージョンにしか収録されておらず、家庭用への移植版でも遊べないレア譜面。
https://www.youtube.com/watch?v=Qmu7nL3pH6g
こちらもアナザー譜面。第7作「beatmania completeMIX 2」(2000) で追加。
completeMIX 2 を含む一部のバージョンと 一部の CD では、アーティスト名義が「n.a.r.d.」や「N.A.R.D.」になっている。
https://www.youtube.com/watch?v=pEFg3EMWAFU
第4作「beatmania completeMIX」(1999) に収録されたリミックスバージョン。
それに伴ってジャンルがオリジナル版の「HOUSE」から「HARD HOUSE」に変更。
オリジナルの 20,november のロング版は存在しないが、この hard mix のロング版は beatmania 4thMIX のサントラに収録されている。
https://www.youtube.com/watch?v=lPOU2pmzvnY
第9作※「beatmania CORE REMIX」(2000) に収録された、西脇辰弥によるリミックスバージョン。
ボーカルが新録され、オリジナル版よりも生っぽい音作りになっている。
（※「beatmania featuring DREAMS COME TRUE」(2000) は番外作として、ナンバリングに含めなかった場合）
https://www.youtube.com/watch?v=QJd9NbQrVv4
「DanceDanceRevolution 2ndMIX」(1999) に収録されたリミックスバージョン。
2ndMIX では STEP BATTLE という特殊なモード専用の曲だったが、3rdMIX 以降では通常のモードで遊べるようになった。
リミキサーは NAOKI こと 前田尚紀。オリジナルにあったボーカルは使われておらず、FINAL EDIT とは対照的にシンセが強調されている。
ちなみに DDR にはオリジナルの方の 20,november も移植されている。
https://www.youtube.com/watch?v=QLlHi1uioBk
PS版「beatmania APPEND GOTTAMIX」(1999) に収録。
人気の 4曲をメドレーにしたトラック。20,november はそのトリを飾っている。
他の 3曲は e-motion (RAVE)、LOVE SO GROOVY (SOUL)、La Bossanova de Fabienne (BOSSA GROOVE)。
MCは、発売当時「HEY! HEY! HEY!」でおなじみ……だった 武居 “M” 征吾。
ttps://www.youtube.com/watch?v=K8wpyrpi3jc
このバージョンのみ、ゲームに収録されたものではなく、CDのために作られたリミックス。
5鍵ビートマニア最後のベストアルバム「beatmania THE BEST PROMINENT」(2003) に収録。
……なのだが、原曲の面影がほとんどない。果たしてこれを 20,november と呼んでもいいのか…？
リミキサー名でググってもほとんど情報がない。一説には、ナグレオ自身が手掛けたとも言われているが…
非公式なリミックスはおそらく無数にあるんだろうけど、今回は公式縛りにした。
10個で足りないくらいバージョン違いが多いかと思ってたらそこまででもなくて、ぶっちゃけアナザー譜面で数を埋めたのは否定できない…
もっと足りなかったら、ビーマニポケットの音源 (ttps://www.youtube.com/watch?v=51BPfKfzpAw?t=250 ) とか、
いちおう非公式だけど半公式…？みたいな Hommarju Remix ( ttps://www.youtube.com/watch?v=oCSO1iZg98I ) とか、
曲名が似てるだけで全然別の曲の「19,November」( ttps://www.youtube.com/watch?v=XhPq3NOYRnw ) でお茶を濁そうかとも考えてたけど、それはせずに済んだぜ。
変態パズルゲームメーカー（誉め言葉）で知られるZachtronicsの最終作『Last Call BBS』を全実績解除するまでやり尽くしたので感想を書く。
私にとって『Last Call BBS』は、3作目に遊んだZachtronicsゲームである。
1作目は『Opus Magnum』、2作目は『SpaceChem』であった。
SpaceChemを全実績解除するまでプレイした時の感想はこちら → https://anond.hatelabo.jp/20240315235948#
いやー、それにしても楽しかった。
ゲーム全体の雰囲気としては、レトロな雰囲気が気に入った。HDDのカリカリ音だったりダイヤルアップ接続のピポパ音だったりもいい。
ただ、日本語訳されていないので、BBSや主人公（？）のテキストメモにおいて英文読解があまりできなかったのが残念だ。とはいえこれは私の英語能力が低いせいなので仕方がない。
『Last Call BBS』に収録されている各ゲームの難易度は、私にとってちょうど良かった。ギリギリクリアできる難易度のものが多かったから、当ゲームの開発者は難易度調整にさぞ力を入れたことだろう。
ゲームの紹介についてはネットで検索すればわかることだから他で参照してもらって、ここは日記なので私の感想を中心に書くことにする。ちなみに当ゲーム内にある各ゲーム（全部で8つ）の感想はクリア順（実績解除順）に並べる。
他のパズルゲームで頭脳を酷使した後のリフレッシュにちょうどいいのでついつい繰り返しプレイして、必要ないのに50勝以上もしてしまった。（10勝で実績解除）
初めの頃はルールを理解するのに苦労した。最初はとりあえず升目を空けてステージクリアしたが、なぜステージクリアになったのかがわからなかった。しかし、次第にルールが理解できるようになると、楽しくステージ進行できるようになった。とはいえ、終盤のほうはなかなか難しくて頭を抱えたりもした。
オブジェクトを運んで加工してと、まさにZachtronicsらしいパズルゲーム。ステージクリア後にコストとステップ数のランキングがグラフで表示されるので（SpaceChemなどでもおなじみだ）、クリア後もついつい効率化を図ってしまうのもまさにZachtronicsだ。コスト低減のためにコンベヤやセンサの設置をシンプルにして、代わりにロジック部分を配線まみれにしてしまうのが楽しくて仕方がない。
難易度の上昇幅もちょうどよく、ステージの終盤になるとロジック部分がギチギチで配線グチャグチャになったりしたのも楽しかった。
ステージクリア後の利用客のレビューも面白い（英文がちょっと難しかったけど）。コーラの製造ステージでコークやペプシを作るのだが、「全部同じじゃないですか」（意訳）というレビューがあって笑った。カップのデザインが違うだけで中身が同じだからだ。
あっさりと最高難易度までクリアして実績解除できた。しかし、クリアしても適切な戦略が良くわからなかった。クリアしても初期配置が良かったからとしか思えなくて達成感は無かったし、失敗してもやはり初期配置が悪かったからとしか思えなかった。ようするに運ゲーにしか感じなかった。やたらめったらカードを動かして積み重ねては駄目なようだけど、さりとてカードを積み重ねることでしかカードを動かせないのだからいったいどうすれば、という感じだった。
おなじく運ゲーなソリティアであるSawayama Solitaireは滅茶苦茶はまったのに対して、Kabufuda Solitaireにはあまりはまらなかった。これは、カード操作で戦略的思考を持てるか否かの違いだろうか。
ゲームというより作業シミュレーター？ 無心になって、ニッパーでプチプチとパーツを外してパーツをはめ込むのは、禅の境地だろうか。
ゴア的ホラーな雰囲気を漂わせたパズルゲーム（ゴア表現は無い）。この雰囲気でパズルゲーム？ と思ったが、スライム状のオブジェクトを増殖して変化させるパズルは、ゴアな雰囲気がふさわしい。プレイと共に雰囲気が好きになってきた。
難易度の上昇幅もちょうどよく、序盤はテンポよく次々とステージクリアできるが、終盤になると頭を抱えるほどに難しくなる。実績解除してこれで全ステージクリアかと思ったら、まだまだステージがたくさんあることに気づいて愕然とした。どれも難しそうなので、やらずに放置している。
PNPとNPNってどう違うんだっけ？ ベース・コレクタ・エミッタってなんだっけ？ いまだによくわかっていないが、PNPとNPNを組み合わせて問題解決するのは楽しかった。特に楽しかったのは自己保持回路だ。どうすれば自己保持できるんだと悩んだが、試行錯誤の末に実現して動作を眺めるのが楽しかった。
難易度上昇幅もやはりちょうどよく、終盤は頭を抱えたり奇声を上げるほどに難しかったが、それだけに達成感も大きかった。Zachtronicsおなじみの、ステージクリア後のランキングもやはりいい。ランキング上位を目指そうとステージクリア後も回路を小さくするよう、ついつい改良してしまう。
『パネルでポン』を彷彿させるパズルゲーム。ブロックが消えている間にブロックを投げ込んで連鎖できるのも、パネルでポンにおけるアクティブ連鎖を彷彿させる。
このゲームの攻略は、3ステージ目がなかなかクリアできずに後回しにしていた。
3ステージ目は、運悪く盤面ブロックの種類がバラつくとブロックを消すのに手間取ってしまい負けてしまう。また、プレイが長引くと爆弾ブロックが邪魔になって負けることが多かった。爆弾は発動させても相手にダメージを与えられないので、メリットは無い。逆にブロック配置の運が良いと連鎖を簡単に組めたり、あるいは勝手に連鎖になって相手に大ダメージを与えることができる。
3ステージ目は何度もコンティニューして、運良く連鎖が繋がった時に勝つことができた。
4ステージ目（最終ステージ）はコンティニュー1回で勝てたが、これも運良く画面外で連鎖が繋がったのが主因だ。
このゲームは、ブロック操作の速さやテクニックよりも、運の良さに左右されるゲームだと思う。
全実績を解除した時点の感想としては、とにかく楽しくて苦痛でもあった。それだけに達成感もまた大きかった。さすがはZachtronicsだ。
Last Call BBS内のどのゲームも面白かったが、その中でも『20th Century Food Court』が一番良かった。次に『ChipWizard Professional』だ。
もう当分の間パズルゲームはやりたくないのでしばらくは他のジャンルのゲームをするだろうが、何か月もすると禁断症状が出てまたパズルゲームをやりたくなるだろう。その時には『SHENZHEN I/O』をやろうと思う。
なんかAIでさ
LLMと動画生成を組み合わせればまぁ…いつかは
これはmetaが最近作ってたAIに、動画と同時にシーンに合わせた効果音も生成するのがある
テキストから効果音生成ならもうあるのでVLMと組み合わせればそれで行けなくもない
3dは、深度+形状+法線+テクスチャ…みたいなメッシュ生成だと若干進化が遅いけど、軽さと詳細のバランスがすごい点群の生成が今めっちゃ有望でAdobeがSubstanceにテスト実装してた
これは中国でかなり凄いのが出来てる
中割り（フレーム補完）もあるし、1枚着色すれば中間も着色するのもある
現実から無限に採取できるデータと違って、アニメとかイラストってのは適切なデータ集めが大変なんよ
だからいまだに自動選択とかオブジェクト認識、背景除去すら微妙な性能のしかない
ちな音声は正直言っていつでも声優の99%を置き換えられるしオリジナル声のまま外国語展開できるくらいにはなってる
残ってる1%は演技要員
描く人は変わんないと思う
注１（大事）：以下の文章は一般的な実務慣行や規則を適当に述べたもので、法的なアドバイスではない
注２：深夜テンションで書いたので文章がわかりにくい、ゆるして
ぺーぺーの弁理士。一応、知的財産の専門家ということになってる（弁理士法1条）。普段は特許を取れるように文章を書いたり特許庁の人を説得したりしてる。
今回の件で「はじめは泳がせていたけど調子に乗ってきたからブチぎれて訴訟を提起した」みたいな話が聞こえてきたけど、そんな感情で急に動くわけではないと思う（発言主もそのつもりはないかもだけどそういう風に解釈した人がいた）。
・（公にしない状態で）警告状を送ったんだけども、
という段階を踏むのが（たぶん）よくある流れだけど、この「調査」というのが手間と時間と金がかかる。
特に弁理士事務所の鑑定とか使うと結構な金額になってくる（中小企業だと気になるくらいの金額）。
あと、訴訟は失敗するとしっぺ返しを食らうし、相手が小さいと勝っても「弱い者いじめ」みたいになってしまうしお金も取れない。
なので、「特許侵害を確信できて」、「ある程度大きくなった状態で」、「こちらの警告に従わなかった」という条件がそろったのが今なんじゃないかな～と勝手に思ってる。
現時点でたぶんなんもわかってないので、今は勝てそうか勝てなさそうかを予想することは無駄だと思う。オープンにされない交渉や和解の検討もあるだろうし。
あと、どの特許権か分かっても、特許権の権利範囲の認定や、侵害認定（アウト・セーフのライン決め）、特許自体の無効理由の有無とかの判断もケースバイケースなことも少なくなくてしかもその判断も簡単じゃない。
少なくとも実務経験なかったら知財管理2級通った程度では絶対無理。
ましてや原告が同じだけの事件を引き合いに出しているのは相手にしないほうがいい。たぶんその人マジのガチでなんもわかってない。
ざっくりだけど、相手方（被告）はこれから以下を検討するだろうと思う。
①②検討して勝てなさそうだったら③かな。
そんなに間違ったことは言ってないハズですが、おかしなところがあったら言ってください。
主な反響に対する回答をしたい
特許侵害訴訟は、商標や著作権と比較して、相手の行為が嫌だからってすぐできるものじゃなくて、戦略を練って綿密な準備するのが普通だよ～って話がしたかっただけです。
「お気持ち」というのは、カッとなってすぐにやる、くらいの意味で使ってました。
A. 「箇条書きマジック」が何を指すのかはよくわからないけど、特許の侵害認定ってむしろ「箇条書き」をぶつけ合うイメージがある。
特許の権利範囲（どこまでセーフか、アウトかの基準）は基本的に「特許請求の範囲」という文書の記載で決めるとされていて（特許法70条1項）、特許侵害訴訟では、そこに被告の製品が入るかどうかを争う、ということになる。
それで、「特許請求の範囲」で発明を特定する事項（発明特定事項）は、箇条書きに近い形式で記載されることが多くて（特に最近の特許）、
その発明特定事項が曖昧で、被告の製品がそれに当てはまるか微妙であればあるほど、その発明特定事項の解釈が裁判で大きな争点となる可能性が高い。
その曖昧さを見抜くこと、そしてそれに基づいて自分に有利な主張を組み立てるには、どうしても多少の実務経験は必要だと思っているんで、そういう点で簡単じゃない、資格（条文の知識）だけでは無理、と言わせてもらいました。
（もちろんその難易度も技術分野や具体的な特許の内容によって大きく変わってくると思う）
ちょっと具体例で説明を。◆忙しい人は読み飛ばしてOKです。◆
例として、弁理士の嵐田先生が紹介してるこちら↓の特許で考えます。
https://x.com/IP_Arashida/status/1836641385476403289?t=OGHEYc6cYKuG2NqadszuSQ&s=06
この特許の「特許請求の範囲」の請求項１は、プレイキャラが地上用の乗り物と空中用の乗り物を交互に乗り換えることを可能にするゲームプログラムの発明を示している。
この特許では、以下すべての条件（発明特定事項）を満たすゲームプログラムは特許の権利範囲に入る（実施する権利なければ特許侵害）ということになる。
で、特許侵害訴訟では、その用語の意味の解釈が争点になることが少なくなくて、例えばこの記載だけを見るとこういう疑問が考えられます。
とまあイチャモンな気もするが、こういう語句の解釈のいかんによっては、被告の製品が原告の特許を侵害するかどうかが変わってくることも少なくない。
なので、権利解釈・侵害認定に上手く対応できることは特許を専門とする弁護士・弁理士にとって大事な資質の一つだと思う。
書いたときは、実施開始から設計変更までの賠償責任が残るので、対処として適切ではないと思って外していましたが、和解の過程でその責任をどうにかできれば、設計変更をするというのは、差し止められるよりかはビジネスへのダメージも少なくて良い方法だと思います。
A. ソフトウェア特許が本当に何でもアリなのかどうかは私の力ではコメントできない。普段の案件では扱っていないし、権利の広さが回避が容易でないレベルなのか、審査がほかの分野と比べて甘いかどうかもよくわかっていないので…
ただ、個人的な意見になるけど、特許の制度自体が本当に産業の発達に寄与しているのか疑問に感じることはある。
例えば、特許の主な役割として「技術の公開を代償に独占権を得て、他の人は公開された技術に基づいて技術を発展させる」（公開代償説）という考えがあるけど、
特許文章って内容の真実性について第三者のチェックも基本無いし、ノウハウを公開しないために発明を実現するのに必要な技術を特許庁に指摘されない程度に省くことも少なくないので、この考えには甚だ疑問がある。
あと、権利として使える特許をいっぱい取るには、良い明細書を良い弁理士にたくさん書いてもらう必要があるから、どうしても資金力がある大企業に有利だし、独占を加速させる制度ではあると思う。
今は技術を文章でまとめたり特許庁と文章でケンカしたりするのが楽しくてこの仕事をやれているけど、この疑問には向き合わないといけないんだろうな。
https://type.jp/et/feature/26796/
この発言にもあるように「コードを綺麗にする＝読みやすくする」ってことだと勘違いしてる
コードを綺麗にするのは「バグを少なくする」ためであって読み手のためじゃない
グローバルに一文字変数を使って困るのは「どこでそれを触ってるか分からないから」であって「読みにくいから」ではない（まぁ読みにくいけど）
特に昔だとLintもないし変数の参照先を探すのはgrepぐらいしかなくて
$iとかだと$iiもひっかかるし$iの後ろにスペースがあったり無かったりするともう探すのは不可能に近くなる
それでも動いているなら最悪問題無いんだがバグの修正時にめちゃくちゃ困って
「作り直すしか無いな」
ってなるのでビジネス的にも大きな影響が出る
「どんなコードでも動くコードを作るのが正しい」「done is better than perfect（完璧を目指すよりも、まずは終わらせることが重要） 」のスタンスが効率的だろうなぁ、、と思うおいらです。
これも元の言葉の意味を曲解していて、「終わらせることが重要」というのはバグがあって良いわけじゃない
例えばログインボタンを実装したときに、ユーザー名とパスワードに何を入れてもログインできる状態にするのも「終わらせること」だし
ただこのままリリースできるわけではないし、プロダクトとしては「終わっていない」
パスワードを平文で保存して実装するのも「終わらせること」ではあるけれどそのままリリースしていいわけではないし
下手に動いてしまうとそのままリリースされたりもするのでよりタチが悪い
この言葉の重要なのは「better than perfect」の方であって「done」の方ではない
全てを完璧にする必要は無い（し、そもそも完璧は定義できない）ので「perfectでなくていいよ」というだけ
バグがあったり不十分だったりセキュリティ不備があって良いわけではない
毎日論理構成の中に浸ってる人は、推理小説は向いてるかもしれないですね。初期にちょろっと設定したグローバル変数が、最終的な結果に大きく影響してくるとか、「ここで使われてるのかー」みたいな感慨とか。
残念ながら「ああ、まともなコードしか読んできてないんだな」としか思えない
例えば「ユーザーの名前と住所は設定できてるから、性別を設定できるようにして」という依頼があって
コードを確認してみるとuser1, user2, user3という変数が100個用意されていて、user1.name = 'hoge', user2.name = 'gaga' って感じで100行書いてあって、更に住所で100行あって、性別も同じように100行追加しろっていうコードを読んだことが無いんだろう
そしてそのコードのどこかで住所設定が間違えているから確認しないといけないような作業をしてないんだと思う
小説で言うと同じ文章が100ページ続いていて、その中のどこかの漢字が違っていて、そいつが犯人、みたいな推理小説、面白いか？
他にも足したり引いたりこねくり回された変数値が最後に定数値で上書きされてたり、UserのオブジェクトがいきなりWeatherのオブジェクトに置き換えられていて、name属性に晴れとか雨のデータが入ってたりしたことがないんだと思う
汚いコードは伏線を回収しないし最終的に犯人も分からないし無駄に長いので推理小説には全く向いてない
で、やっぱりこういう汚いコードの問題は「バグが混入しやすいかどうか」であって「読みやすいかどうか」ではない
下手するとuserオブジェクトを100行ずつ書いてくれてる方が読みやすさはあるかもしれないが
「user36だけ住所が設定されていない」といったバグが混入し得るし、それを確認するのに多大な労力を必要とする
人間は誰もが間違いを犯すので誰もがバグを混入させる危険性があるんだけれど
その危険性は最大限まで下げるように努力するべきだし、インシデントを引き起こすことでビジネス的なインパクトも大きい
以下は、M理論と超弦理論の幾何学を抽象化した数学的枠組みでのモデル化について述べる。
まず、物理的対象である弦や膜を高次の抽象的構造としてモデル化するために、∞-圏論を用いる。ここでは、物理的プロセスを高次の射や2-射などで表現する。
∞-圏 𝒞 は、以下を持つ：
これらの射は、合成や恒等射、そして高次の相互作用を満たす。
次に、デリーブド代数幾何学を用いて、空間や場の理論をモデル化する。ここでは、デリーブドスタックを使用する。
デリーブドスタック 𝒳 は、デリーブド環付き空間の圏 𝐝𝐀𝐟𝐟 上の関手として定義される：
𝒳 : 𝐝𝐀𝐟𝐟ᵒᵖ → 𝐒
ここで、𝐒 は∞-グルーポイドの∞-圏（例えば、単体集合のホモトピー圏）である。
物理的なフィールドやパーティクルのモジュライ空間は、これらのデリーブドスタックとして表現され、コホモロジーやデリーブドファンクターを通じてその特性を捉える。
非可換幾何学では、空間を非可換代数 𝒜 としてモデル化する。ここで、スペクトラルトリプル (𝒜, ℋ, D) は以下から構成される：
作用素 D のスペクトルは、物理的なエネルギーレベルや粒子状態に対応する。幾何学的な距離や曲率は、𝒜 と D を用いて以下のように定義される：
∞-トポス論は、∞-圏論とホモトピー論を統合する枠組みである。∞-トポス ℰ では、物理的な対象やフィールドは内部のオブジェクトとして扱われる。
フィールド φ のグローバルセクション（物理的な状態空間）は、次のように表される：
Γ(φ) = Homℰ(1, φ)
ここで、1 は終対象である。物理的な相互作用は、これらのオブジェクト間の射としてモデル化される。
ゲージ対称性やその高次構造を表現するために、L∞-代数を用いる。L∞-代数 (L, {lₖ}) は次元付きベクトル空間 L = ⊕ₙ Lₙ と多重線形写像の族 lₖ からなる：
lₖ : L⊗ᵏ → L, deg(lₖ) = 2 - k
∑ᵢ₊ⱼ₌ₙ₊₁ ∑ₛᵢgₘₐ∈Sh(i,n-i) (-1)ᵉ⁽ˢⁱᵍᵐᵃ⁾ lⱼ ( lᵢ(xₛᵢgₘₐ₍₁₎, …, xₛᵢgₘₐ₍ᵢ₎), xₛᵢgₘₐ₍ᵢ₊₁₎, …, xₛᵢgₘₐ₍ₙ₎) = 0
ここで、Sh(i,n-i) は (i, n - i)-シャッフル、ε(sigma) は符号関数である。
これにより、高次のゲージ対称性や非可換性を持つ物理理論をモデル化できる。
安定ホモトピー理論では、スペクトラムを基本的な対象として扱う。スペクトラム E は、位相空間やスペースの系列 {Eₙ} と構造写像 Σ Eₙ → Eₙ₊₁ からなる。
πₙˢ = colimₖ→∞ πₙ₊ₖ(Sᵏ)
ここで、Sᵏ は k-次元球面である。これらの群は、物理理論における安定な位相的特性を捉える。
物理的な相関関数は、コホモロジー類を用いて以下のように表現される：
⟨𝒪₁ … 𝒪ₙ⟩ = ∫ₘ ω𝒪₁ ∧ … ∧ ω𝒪ₙ
ここで、ℳ はモジュライ空間、ω𝒪ᵢ は観測量 𝒪ᵢ に対応する微分形式またはコホモロジー類である。
先に述べた抽象数学的枠組みを用いて、M理論の重要な定理であるM理論とIIA型超弦理論の双対性を導出する。この双対性は、M理論が11次元での理論であり、円 S¹ に沿ってコンパクト化するとIIA型超弦理論と等価になることを示している。
時空間の設定：
H•(ℳ₁₁, ℤ) ≅ H•(ℳ₁₀, ℤ) ⊗ H•(S¹, ℤ)
これにより、11次元のコホモロジーが10次元のコホモロジーと円のコホモロジーのテンソル積として表される。
C-場の量子化条件：
M理論の3形式ゲージ場 C の場の強度 G = dC は、整数係数のコホモロジー類に属する。
[G] ∈ H⁴(ℳ₁₁, ℤ)
デリーブド代数幾何学では、フィールド C はデリーブドスタック上のコホモロジー類として扱われる。
非可換トーラスの導入：
円 S¹ のコンパクト化を非可換トーラス 𝕋θ としてモデル化する。非可換トーラス上の座標 U, V は以下の交換関係を満たす。
UV = e²ᵖⁱθ VU
非可換トーラス上のK-理論群 K•(𝕋θ) は、Dブレーンのチャージを分類する。
K•(ℳ₁₁) ≅ K•(ℳ₁₀)
𝕊ₘ ≃ Σ𝕊ᵢᵢₐ
ここで、Σ はスペクトラムの懸垂（suspension）函手である。
デリーブド代数幾何学、非可換幾何学、および安定ホモトピー理論の枠組みを用いると、11次元のM理論を円 S¹ 上でコンパクト化した極限は、IIA型超弦理論と数学的に等価である。
(b) 非可換性の考慮
「なんだって!!?」
クリーニング屋の息子であり僕の友人であるロバートダウニーJr.からその話を聞いたとき、僕は我が耳を疑った。
「今度、新しいお祭りを始めんだ。良かったら帰ってこいよ」とロバートダウニーJr.はエッジの利いた訛り言葉で話し、どんなお祭り? と僕が尋ねるとロバートダウニーJr.は夏の熱風に当てられたかのような「ふふぅん!」という鼻息を聞かせ、それから「スマートフォン祭りだ」と言った。
僕の故郷は過疎が進んだ限界集落で、"集"という言葉を用いるのが憚られるほど毎年人が減っており若者は逃げ出すような、そんな場所だ。
かくいう僕も脱走した若者の一人であり、しかし"スマートフォン祭り"なるものが気になり(ネットで調べてもまるで出てこない。情報ゼロだ)、今夏は久々に帰省することにした。
着いたのはちょうどお祭りの当日、その昼間だった。夕方から始まる祭りに備え、ロバートダウニーJr.に会おうとクリーニング屋に向かいながらぶらぶら村の中を歩いていると、見慣れないオブジェクトが目に入った。
この村にはひとつだけ特に大きな広場があり、どうやらそこに何がある。僕はドリンクバーで好奇心と猜疑心をミックスしたジュースを飲むような心地でその広場に向かった。
は…? なんだこれ…?
そこにはモニターを模したような巨大な石像があり、「ほっほっほ、驚いたかのぉ、よし坊」と声をかけられ振り替えると村長が居た。
僕は挨拶するのも忘れて「なんだよこれは!?」と尋ねた。
村長はニタァ…と笑って「すまーとふぉん、じゃよ」と得意気に言った。僕は絶句した。いやこれiPadだよね?
喉元まで出かかった言葉を飲み込むと
数学的宇宙仮説を説明するには、宇宙をどのようにモデル化するかを考え、各理論の役割を明確にする必要がある。
以下に、各概念を説明し、物理宇宙を数学的にどのように捉えるかを示す。
数学的宇宙仮説の中心にあるのは、宇宙が数学的構造そのものであるという考え方である。数学的構造は、集合とその上で定義される関係や演算の組み合わせである。
具体例として、微分多様体を考える。微分多様体は、局所的にユークリッド空間に似た構造を持ち、滑らかな関数が定義できる空間である。物理学では、時空を微分多様体としてモデル化し、一般相対性理論の基盤としている。このように、宇宙全体を一つの巨大な数学的構造として捉え、その性質を研究する。
集合論は、数学の基礎を形成する理論であり、すべての数学的対象を集合として扱う。特に、Zermelo-Fraenkel集合論（ZFC）は、集合の存在とその性質を定義する公理系である。数学的宇宙仮説では、宇宙を集合として捉え、その集合上の関係や演算が物理法則を表現していると考える。
モデル理論は、形式的な論理体系が具体的な構造としてどのように実現されるかを研究する。数学的宇宙仮説では、物理宇宙がある論理体系のモデルであると仮定する。具体的には、物理法則を公理とする論理体系のモデルとして宇宙を捉える。これは、ペアノ算術の公理系のモデルとして自然数が存在するのと類似している。
カテゴリ理論は、対象（オブジェクト）とそれらの間の射（モルフィズム）を扱う理論である。カテゴリ 𝒞 は次のように定義される：
射は合成可能であり、合成は結合的である。さらに、各対象に対して恒等射が存在する。
数学的宇宙仮説では、宇宙を一つのカテゴリとして捉えることができる。カテゴリの対象は異なる数学的構造であり、射はそれらの間の変換や関係を表す。これにより、異なる「宇宙」間の関係性を数学的に探求することが可能になる。
トポス理論は、集合論の一般化であり、論理と空間の概念を統一する枠組みである。トポスは、論理体系のモデルとして機能し、異なる数学的構造を統一的に扱うことができる。
数学的宇宙仮説では、宇宙をトポスとして捉えることができる。トポスは、論理体系のモデルであり、異なる物理的現実を表現するための柔軟な枠組みを提供する。トポス理論を用いることで、宇宙の数学的性質をより深く理解することが可能になる。
数学的宇宙仮説を抽象数学で説明するためには、数学的構造、公理系、集合論、モデル理論、カテゴリ理論、トポス理論といった数学的概念を用いることが必要である。
これにより、物理的現実を数学的に厳密に記述し、数学と物理の深い関係を探求することができる。
この仮説は、数学的対象が物理的実体として存在するという新しい視点を提供するが、現時点では哲学的な命題としての性格が強く、数学的に証明可能な定理ではない。
ロックに条件持たせる
やりたいことはできてるように見えるが、うーんしんどい
# Entity Relation Diagram
# ```mermaid
# ---
# title: Rental Office example
# ---
# erDiagram
# OFFICE ||--|{ ROOM : x
# OFFICE {
# number office_id
# }
# ROOM {
# number office_id
# number room_id
# }
# ROOM ||--|{ SCHEDULE : x
# SCHEDULE {
# number room_id
# datetime start_at
# datetime end_at
# }
# OFFICE ||--|{ BUSINESS_HOUR : x
# BUSINESS_HOUR {
# number office_id
# enum week_of_day
# datetime start_at
# datetime end_at
# }
# ```
# Directed Acyclic Graph
#
# ```mermaid
# graph LR
# A[OFFICE] --> B[ROOM]
# B --> C[SCHEDULE]
# A[OFFICE] --> D[BUSINESS_HOUR]
# D --> C
# A --> C
# ```
# 基底クラス: EntityLock
class EntityLock
attr_accessor :entity_name, :entity_locked, :attribute_locks
def initialize(entity_name)
@entity_name = entity_name
@entity_locked = false # エンティティ全体のロック状態を保持
@attribute_locks = {} # IDに対するロックを管理するハッシュ
end
def lock_entity
@entity_locked = true
puts "Entity '#{@entity_name}' is now locked."
end
def unlock_entity
@entity_locked = false
puts "Entity '#{@entity_name}' is now unlocked."
end
def lock(attributes)
entity_id = attributes["#{@entity_name.downcase}_id"]
if entity_id && !@attribute_locks[entity_id]
@attribute_locks[entity_id] = true
puts "#{@entity_name} with ID '#{entity_id}' is now locked."
end
end
def unlock(attributes)
entity_id = attributes["#{@entity_name.downcase}_id"]
if entity_id && @attribute_locks[entity_id]
@attribute_locks.delete(entity_id)
puts "#{@entity_name} with ID '#{entity_id}' is now unlocked."
end
end
def locked?(attributes)
# まずエンティティ全体がロックされているかチェック
return true if @entity_locked
# 次に特定のIDがロックされているかチェック
entity_id = attributes["#{@entity_name.downcase}_id"]
if entity_id && @attribute_locks[entity_id]
return true
end
# ロックされていなければfalseを返す
false
end
end
# 子クラス: OfficeLock, RoomLock, ScheduleLock
class OfficeLock < EntityLock
def initialize
super("Office")
end
end
class RoomLock < EntityLock
def initialize
super("Room")
end
end
class ScheduleLock < EntityLock
def initialize
super("Schedule")
end
end
# 子クラス: BusinessHourLock
class BusinessHourLock < EntityLock
def initialize
super("BusinessHour")
@attribute_locks = [] # BusinessHour用のロックを配列で管理
end
def lock(attributes)
start_at = attributes["start_at"]
end_at = attributes["end_at"]
if start_at && end_at
@attribute_locks << [start_at, end_at]
puts "BusinessHour from '#{start_at}' to '#{end_at}' is now locked."
end
end
def unlock(attributes)
start_at = attributes["start_at"]
end_at = attributes["end_at"]
if @attribute_locks.include?([start_at, end_at])
@attribute_locks.delete([start_at, end_at])
puts "BusinessHour from '#{start_at}' to '#{end_at}' is now unlocked."
end
end
def locked?(attributes)
# まずエンティティ全体がロックされているかチェック
return true if @entity_locked
# 次に特定の時間範囲がロックされているかチェック
start_at = attributes["start_at"]
end_at = attributes["end_at"]
if start_at && end_at
@attribute_locks.each do |(locked_start, locked_end)|
if locked_start <= start_at && end_at <= locked_end
return true
end
end
end
# ロックされていなければfalseを返す
false
end
end
# TreeNodeクラス
class TreeNode
attr_accessor :name, :children, :parents, :lock
def initialize(name, lock)
@name = name
@children = []
@parents = [] # 複数の親ノードを保持する配列
@lock = lock # TreeNodeにロックを持たせる
end
def add_child(child_node)
child_node.parents << self # 子ノードにこのノードを親として追加
@children << child_node
end
def display(level = 0)
indent = " " * (level * 4)
puts "#{indent}#{@name}"
@children.each { |child| child.display(level + 1) }
end
def has_dependency
return false if @parents.empty?
@parents.each do |parent|
puts "#{@name} is dependent on #{parent.name}"
return true
end
@parents.any?(&:has_dependency)
end
def locked?(attributes = {})
# 自身がロックされているか確認
return true if @lock.locked?(attributes)
# 親ノードがロックされているか再帰的に確認
@parents.any? { |parent| parent.locked?(attributes) }
end
end
# 木構造の組み立て
# ロックオブジェクトの作成
office_lock = OfficeLock.new
room_lock = RoomLock.new
schedule_lock = ScheduleLock.new
business_hour_lock = BusinessHourLock.new
# ノードの作成
office_node = TreeNode.new("Office", office_lock)
room_node = TreeNode.new("Room", room_lock)
schedule_node = TreeNode.new("Schedule", schedule_lock)
business_hour_node = TreeNode.new("BusinessHour", business_hour_lock)
# ノード間の依存関係の設定
office_node.add_child(room_node) # Office -> Room
room_node.add_child(schedule_node) # Room -> Schedule
office_node.add_child(business_hour_node) # Office -> BusinessHour
business_hour_node.add_child(schedule_node) # BusinessHour -> Schedule
# 木構造の表示
office_node.display
# ロックの確認
puts "Case 1. Office全体がロックされた場合"
puts "Is office_node locked? #{office_node.locked?({})}" # false
puts "Is schedule_node locked? #{schedule_node.locked?({})}" # false
office_lock.lock_entity
puts "Is office_node locked? #{office_node.locked?({})}" # true
puts "Is schedule_node locked? #{schedule_node.locked?({})}" # true
office_lock.unlock_entity
puts "Case 2. Room id:1 がロックされた場合"
puts "Is schedule_node locked? #{schedule_node.locked?({ "room_id" => 1 })}" # false
puts "Is schedule_node locked? #{schedule_node.locked?({ "room_id" => 2 })}" # false
room_lock.lock({ "room_id" => 1 })
puts "Is schedule_node locked? #{schedule_node.locked?({ "room_id" => 1 })}" # true
puts "Is schedule_node locked? #{schedule_node.locked?({ "room_id" => 2 })}" # false
room_lock.unlock({ "room_id" => 1 })
puts "Case 3. BusinessHour start_at:0 end_at:5 がロックされた場合"
puts "Is schedule_node locked? #{schedule_node.locked?({ "room_id" => 1, "start_at" => 0, "end_at" => 5 })}" # false
puts "Is schedule_node locked? #{schedule_node.locked?({ "room_id" => 1, "start_at" => 5, "end_at" => 10 })}" # false
business_hour_lock.lock({ "start_at" => 0, "end_at" => 5 })
puts "Is schedule_node locked? #{schedule_node.locked?({ "room_id" => 1, "start_at" => 0, "end_at" => 5 })}" # true
puts "Is schedule_node locked? #{schedule_node.locked?({ "room_id" => 1, "start_at" => 5, "end_at" => 10 })}" # false
business_hour_lock.unlock({ "start_at" => 0, "end_at" => 5 })
FANZAの検索結果から熟女を除外するブックマークレット がうまく動いたので、気を良くしてはてなブックマークのコメント欄をスター数順にソートするブックマークレットを作りました。
作った動機は、「注目コメントに入りきれなかったちょっといいコメント」をサクサク探したいから。結果として建設的コメント順位付けモデルを無効化していますが、あのアルゴリズムには特に不満は特にありません。
javascript: (async () => {
const wait = ms => new Promise(resolve => setTimeout(resolve, ms));
document.querySelector('.js-bookmarks-sort-tab[data-sort="recent"]').click();
window.scrollTo(0, document.body.scrollHeight);
await wait(1000);
window.scrollTo(0, 0);
await wait(1000);
const p = document.querySelector('.js-bookmarks-recent');
let l = Array.from(p.querySelectorAll('.entry-comment-contents'));
const g = e => {
let n = e.querySelectorAll('.hatena-star-star').length;
const c = e.querySelector('.hatena-star-inner-count');
return c ? n + Number(c.textContent) : n
};
l = l.filter(e => g(e) > 0);
l.sort((a, b) => g(b) - g(a));
p.replaceChildren(...l);
})();
ミニファイしたもの ※コードに一部誤りがありましたので訂正しました（2024-08-16 11:47）
javascript:(async()=>{const wait=ms=>new Promise(resolve=>setTimeout(resolve,ms));document.querySelector('.js-bookmarks-sort-tab[data-sort="recent"]').click();window.scrollTo(0,document.body.scrollHeight);await wait(1000);window.scrollTo(0,0);await wait(1000);const p=document.querySelector('.js-bookmarks-recent');let l=Array.from(p.querySelectorAll('.entry-comment-contents'));const g=e=>{let n=e.querySelectorAll('.hatena-star-star').length;const c=e.querySelector('.hatena-star-inner-count');return c?n+Number(c.textContent):n};l=l.filter(e=>g(e)>0);l.sort((a,b)=>g(b)-g(a));p.replaceChildren(...l)})()
FANZAの検索結果から熟女を除外するブックマークレット 参照
javascript:
ブックマークレットに必要な、URLの種類を示すスキーム名です。
(async () => {
// 処理
})();ページに元々ある変数たちとバッティングしないように、まず無名関数でラップします。処理の中で await を使いたいので async 宣言しています。
const wait = ms => new Promise(resolve => setTimeout(resolve, ms));
document.querySelector('.js-bookmarks-sort-tab[data-sort="recent"]').click();
window.scrollTo(0, document.body.scrollHeight);
await wait(1000);「新着コメント」タブをクリックし、ページの一番下までスクロールダウンしてから少し待つ動作です。新着コメントの後半部分（スクロールきっかけの遅延読み込みになっているところ）の読み込みをうながしています。
window.scrollTo(0, 0);
await wait(1000);
ページの先頭に戻ってまた少し待ちます。合計2秒の待ち時間は雰囲気で決めていますので、これでなければならない・これで過不足ないという値ではありません。単にコメントの読み込み完了を判定する処理を書くのがめんどうだっただけです。
const p = document.querySelector('.js-bookmarks-recent');
新着ブコメの親要素です。繰り返し呼び出すので名前をつけています。
let l = Array.from(p.querySelectorAll('.entry-comment-contents'));
const g = e => {
let n = e.querySelectorAll('.hatena-star-star').length;
const c = e.querySelector('.hatena-star-inner-count');
return c ? n + Number(c.textContent) : n
};
コメントのはてなスター数をカウントして返す関数です。たくさんスターがついてる ★256★ みたいなやつの数字も足します。
l = l.filter(e => g(e) > 0);
ソートする前に、無スターのコメントを消去しています。してもしなくてもいいことですが。
l.sort((a, b) => g(b) - g(a));
残ったコメントをスター数で降順ソートします。.querySelectorAll() で収集した要素を配列に入れ直したのは、この .sort() メソッドを使いたいからです（.querySelectorAll() が返す配列風の NodeList オブジェクトは、配列と共通のメソッドもいくつかあるものの、大半は使えないのです）。
p.replaceChildren(...l);
親要素の内容を、並び替えの終わったコメントでそっくり入れ替えて、処理完了です。画面を見ると新着コメントの中身が「スターのついたコメントのみ・スターの多い順」に並んでいます。元に戻す方法はないので、原状回復にはリロードします。ソート状態を示すフラグを立てておいてスター数ソート⇔日付ソートをかわりばんこに行うようにすればできそうだなと思ったけど実装はしません。連打スターを省く処理を追加してＵＵ数でソートできればもっと厳正なランキングになるなーと今思いつきましたがそれも実装はしません。
以下に、ドゥボールの「スペクタクルな社会」とアートの役割に関する主張を詳しく説明します。
ドゥボールの「スペクタクルな社会」は、現代社会におけるメディアや広告の支配、消費文化の広がり、そして個人の疎外といった問題を鋭く指摘しています。この考え方は今日においても、情報過多の社会やデジタルメディアの影響下での社会問題に対する批判的視点を提供しています。
アートの役割についても、商業化が進む現代のアートシーンにおいて、再び批判的かつ革新的な力を取り戻すべきだという視点は、アーティストやキュレーターにとって重要な示唆となるでしょう。