  |
はてなキーワード: 配列とは
画像を生成する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の学習やクレンジングを意図的に妨害し、無断学習にかかるコストを増加させるために有効です。特に、「微小な変更」や「アドバーサリアルノイズの付与」といった手法は、見た目の品質に影響を与えずにモデルにノイズを持ち込むため、非常に効果的です。
まずメカニカルキースイッチにも薄型タイプがあることを知っておくといい。超薄型が作れるパンタグラフほどではないがケースやキャップもそこそこ薄型になる。
界隈では薄型はかなりの傍流になるが、既製品ではIQUNIX Magi65やLofree Flow84やNuphy Air60 V2といった機種がキーボードマニアからの評価も高い(=打鍵感や打鍵音が良い)。
先に挙げたやつほどコトコトとクリーミーな音がしてオススメ度が高い。とはいえ、あくまでロープロファイル系の中では、という話。
浅いキーストロークの熱心なファンでもなく、自作系に踏み入る気があるならば、通常サイズのメカニカルスイッチでも、スプリングが軽いものや、軸を高分子素材にする等で滑らかさをあげたものを用いて軽い打鍵感を作ることができ、そちらの方が沼が深い。
またケース側でも、最近のカスタムメカニカルキーボードキットは大抵がガスケットマウントと言って基盤をシリコンラバーで挟むことで底打ち時の負荷をへらす(たわむ)設計になっており、疲れにくくなっている。
この手のキットはケース全体がアルミニウムなどの金属で出来ていて物理的に重くすることでいい音を作るのが主流のアプローチになっている。安いキットやハンドメイド系のガチ自作ではプラ筐体が多いが。
とりあえず手頃な入門キットをお望みで個人輸入ができるなら、今はLucky65 V2がダンゼンおすすめだ。アルミでは最安レベルながら質感も高くカッコいい。
ベアボーンキットなのでスイッチやキーキャップは自分で調達する必要がある。
スイッチは安価で良いものを選ぶなら、MZ Studio Z1 Linear Switchがおすすめだ。
キーキャップは好みになるが、マニアからはPBT素材で厚めのものが好まれる。
コスパ重視なら、Womier Factory Storeあたりが手頃な値段でそこそこのものを売っている。AmazonでXVX名義で売ってるのと同じ会社だがどうせ中国から来るならAliのが安い。
ちなみにこのストアが売っているWomier SK65という完成品キーボードは、裏面の明らかにLuckyと書かれた金属ウエイトで分かるように、Lucky65初代のODM版と思われ、右上キーをノブに置き換えてスイッチとキャップをセットにしたもの。
ただ付属のスイッチは47gfと重くはないが特別軽くはないので軽いスイッチがいいなら40gf以下のものを選んだほうがいいだろうことを考えると微妙。
この筐体はV1だがV2の方がクオリティは上がっているようで、少々jsonファイルを探す必要はあるがキーマップの自由度も増していて、マグネット脱着機構で分解もしやすくなっている。
スイッチとキャップをはめ込むだけで完成するこの程度の半完成ベアボーンキットであればV1完成品ODMよりV2を狙ったほうがいいと個人的には思う。
英語配列や65%レイアウトなどを敬遠する人もいるが、それほどハードルは高くないと思う。
配列は、OSの設定で英語キーボードに設定して、IMEの設定で押しやすいキーに日本語ON/OFF(自分はShift+スペース)を割り当てるだけで、あとは細かい記号の違いに慣れればいい。@などは押しやすくなる。
65%などのFキー列がないものを使いこなすのは一見難しく感じるが、機種専用のキー割当ソフトでFnに相当するレイヤキーをCapsLockあたりの位置に移動してしまえば、むしろ指をあまり動かさずブラインドでFキー列を押せるようになるので慣れたら快適。
割当ソフトはjsonを読み込ませて使うデファクトスタンダードアプリであるVIAや機種固有のメーカー製アプリだったりするが、最低限ググる能力があれば問題ないだろう。Fnキー位置を変更できない機種があることは事前にチェックが必要。
技適を気にする人は有線のみのものか国内代理店のついている無線製品を選ぶのが無難だがこの手の趣味はだいたい国内に入ってきていない中国ブランドが強いので自己責任的なアレだ。
何年間も他人の反応が欲しいと思い続けているのであれば、まずは文章を推敲してみては？
ざっと読んだ範囲で思ったのは、配列にこだわりがあるだけなら、Keyboard Quantizer、やかえうち2を使って自分の好きに変更してしまえば、様々な新しいキーボードが選択肢に入るよ。
好きな配列があるなら自作系キーボードに様々な人がいるから探してみれば？自由に配列が変えられるようになっているので、今まで存在しなかった配列が可能になっている。
昔ながらのキーボード配列の枠組みにとらわれているだけじゃなくて、より自分に合ったキーボードが見つかるかもしれないよ。
HHKBは下記のような話が前提となって作られている
アメリカ西部のカウボーイたちは、馬が死ぬと馬はそこに残していくが、どんなに砂漠を歩こうとも、鞍は自分で担いで往く。馬は消耗品であり、鞍は自分の体に馴染んだインタフェースだからだ。
新しいパソコンを買ってもWindowsからMacに乗り換えてもキーボードは大切なインタフェースとして鞍のように持ち運ぶ
なので小さければ小さい方が良いし品質は高ければ高い方がいいい
この大前提があるので
といった特色を持っている
キーの少なさについて不満を言う人が多いが、基本的にプログラマーはFunctionキーや矢印キーを使わない
それどころかホームポジションから指を離さないといけないようなキーはほとんど使わない
例えばVimならhjklのキー、EmacsならC-npfbのキーで移動できるので矢印キーは使わないし
BackspaceはC-hを使ったり、その他にも人によって独自にショートカットキーを設定している
これはキータイピングの時間を短くするという理由と打ち間違いを極力減らすという理由のためである
大抵の場合ショートカットキーにはCtrlキーを多用するのでAキーの横にCtrlキーが配置されており、押し間違いの代表格であるCaps Lockはよくわからないところに追いやられている
プログラマーが英語配列を好むのも実はこの押しやすさが関係していて
Returnキー（Enterキー）がホームポジション右手小指のキー1つ空きで押せるためである
ビルド エンジニアが別の会社に移った。奴は文字通りターミナルの中に住んでいた。
Vim を愛し、 Dotで図を作成し、Markdown で wiki の投稿を書くようなタイプの奴だ。
奴は90 秒以上の時間がかかる場合はなんでも自動化するスクリプトを作成する。
（ここに返信対象の増田を入力） ---- - 上記のコメントに対する返信replyを出力してください。 - replyは以下の中から最も会話として通じるものを選んでください。 ``` - 男の誇りを失ってまで得る価値のある勝利かっ…！？ - 人間は強い…！そして優しい生き物だ！ - 家族というやつはいいもんだ… - 今はただ…オレの友の…！！心意気だけをくんでやってくれっ！！！ - 目先の勝利に狂ったオレは…馬鹿だった… - ゆるせよポップあの世で会ったら好きなだけオレを殴れ…！ - 生きとし生けるものにはすべて太陽が必要なのだ… - オレは男の価値というのはどれだけ過去へのこだわりを捨てられるかで決まると思っている - 恐ろしいものだ…欲とは…オレとて どう ゆがんでいたかわからん - この世には 本当に煮ても焼いても食えぬヤツがいる！ ``` - より自然な返信となるように必要に応じて原文を改変してください。 - 複数の候補を選び、それぞれの無害度をwholesome_rateとして0.0〜1.0の範囲で評価、出力してください。 - 出力は以下のようにjson配列でお願いします。 [ { "reply": "...", "wholesome_rate": ... }, ... }
法人はしらんけど、個人に関してはある程度同意。特にリーマンで還付申請とか。
：自分の例；医療費控除で、保険分と自費診療分を申請したいとき、以前は
→自費診療分がある場合、一旦保険分のCSVを書き出して、税務署のエクセルフォーマットに書き換えて、自費診療分を追記して提出
（しかもマイナポータルから出てくるCSVと、税務署のXLS書式がまったく違うので（縦横すら違う）、全部配列を手打ちで直さないといけない）
→去年 保険分（自動入力）に、追加分（税務署からダウンロードしたエクセルに記載した自費診療分）のエクセルを追加で読み込ませるだけでいい。
が…毎年やってないので、「ま、マイナポータルから医療費のCSVが出せなくなってる！」ってパニクった。
ラクになってはいるが、ラクになったのだと気がつくまで、やり方が変わるとパニクるから、それはそれで毎年勉強しないといけないことに変わりはない。
その時点でだいぶ振り落とされる人は多そう。
あとスマホでマイナンバーカード読ますのはリードエラー多くてやっとれん。
たまたまNTT製のICカードリーダー（別の目的で購入したけど使えずに放置してたもの）があったからPCで出来て助かったけど。
前は使えていたノーブランドのカードリーダーは弾かれた（Linuxドライバで動くやつ）
まあ、先は長いな…
カウンセリングを嫌がる理由だが、フェミニストカウンセリングみたいな糞やろーが現実にいてとにかくきつい言葉を浴びせるのが大好きなカウンセラーがいるせいだろうな。
現実問題、カウンセリングはそれなりにするんでおすすめはしない。
みたいなときはまま役に立つけどね。
ソーシャルスキルトレーニングは統合失調症向けで、ASDだとあまり役には立たない。
就労移行支援事業所とかでやってるところもあるんで、要件を満たせばただか安い費用で利用はできるけどね。
あと、雰囲気としては学校みたいな感じで、人間関係によるトラブルもあり、ASDだと排除されて、悪化することもままある。
特に発達障害持ちの女性は負の性欲が強くて、男性のASDでもアルファ男性じゃないタイプは排除する傾向にあるし、リーダー格の人も発達障害持ち女性の味方をする傾向にある。
だから、発達障害メインの医者はソーシャルスキルトレーニング自体は勧めてくれなかったな。
ASDだけど、背景にDVがあり、IQが高くて、見た感じ普通に話せて、WISCの凹凸が絵画配列だけ低いタイプだとソーシャルスキルトレーニング自体あまり意味がないし、かえって有害らしい。
帰脾湯や加味帰脾湯である程度、相手の反応を待てるようにはなるんで、ASDに帰脾湯や加味帰脾湯自体は効くこともあるんだけどね。
そこまでシビアな速度は求められてなくわかりやすさで比べた場合に
Array.from({ length: 5 }, (_, i) => i);
Array.from({ length: 5 }).map((_, i) => i);
Array.from(Array(5)).map((_, i) => i);
Array.from(Array(5), (_, i) => i);
Array(5).fill().map((_,i) => i);
[...Array(5)].map((_, i) => i);
Array.from派 Array(n).fill派[...Array(n)]派MDNは Array.from({ length: 5 }, (_, i) => i); 派だった
ロックに条件持たせる
やりたいことはできてるように見えるが、うーんしんどい
# 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);
親要素の内容を、並び替えの終わったコメントでそっくり入れ替えて、処理完了です。画面を見ると新着コメントの中身が「スターのついたコメントのみ・スターの多い順」に並んでいます。元に戻す方法はないので、原状回復にはリロードします。ソート状態を示すフラグを立てておいてスター数ソート⇔日付ソートをかわりばんこに行うようにすればできそうだなと思ったけど実装はしません。連打スターを省く処理を追加してＵＵ数でソートできればもっと厳正なランキングになるなーと今思いつきましたがそれも実装はしません。
【追記】
アマプラその他にはアマチュアが投降した動画がない、というのを失念していた
まあ、それもようつべがあるけどさ……やはりニコニコ動画のノリを思い出すと、ニコ動がいらないってのは言い過ぎだったと思う
ドワンゴよ、ごめんな……
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
（以下本文）
別にもういいよな。復活しなくたって。
これまで約二か月、ABEMAとアマプラのすばらしさに目覚めたよ。ついでにネトフリも。
画面はでかいし、画質はキレイだし、そのうえユーザーインターフェースも整ってる。お洒落だ。
正直、ニコ動って、これまで惰性で人気を得てきたんじゃないのか？いわゆる先行者利益ってやつだ。
PC関係だったら、キーボードの配列だって、今のより効率的な配置が科学的に明らかになってるけど、既得権者がいるからそのまま50年以上前の配列になってるんだろ。
俺はもう、ニコニコ動画に戻るかはわからない。今のところはアマプラが一番好きである。