编程

ルール： マークダウン構造を保護する。 URLやコードを翻訳しない。 追加のコメントなしで翻訳された内容を返す。 阿珏Blog十周年活動が無事に終了しました。 今年の参加者は私の予想を超えていました。活動期間中、群グループで手がかりやヒントを交換し、多くの人々が無事に最終的な報酬を手に入れました。2年前から計画を立てていたものが本当に誰かが真剣に遊んで終わったことに、とても嬉しいです、AIのサポートがあったとはいえ。 もしまだ遊んだことがない場合は、まず活動原文を見てください。これはすべての答えを直接公開し、以下は完全なストーリーです。ゲーム中にはあなたの認識を覆すような多くの知識内容があります。 全体フロー 拆弾専門家 → エントリーポート → ブラックアウト画像の調整 → ログインとキャプチャー → 偽Cloudflareページ → PDFにZIPを隠す → GalGame対話で手がかりを見つける → 数字を推測 → 二次元コードをスキャン → 異なるものを見つける → 明暗モードのアルバム → パズル → 保险庫。 第0関：拆弾専門家 最初の関節は小さな前菜です。ページには4本の異なる色の線とカウントダウンがあり、どの一本を切るかを慎重に判断するように見えます。 しかし、正しい答えはありません。どの一本を切っても爆発します。爆発後、ページは貴重なアルバムが粉々になったことを示し、片付けるよう指示します。 次にやるべきことは明確です：支線タスクを引き出し、後のエンディングで散らばったパズルのピースを見つけることです。 したがって、4本の線に時間を割く必要はありません。爆発効果を見るために一本を切るだけで十分です。 第1関：活動ウェルカムエントリーページ 公式エントリーページに到着すると、画面中央の「今すぐ参加」ボタンは普通のジャンプボタンではなく、画像のホットスポットを通じて実現されています。手形の光標が見えたら、その位置を直接クリックすると次のエンディングに進みます。このエンディングは観察力を試し、HTML画像のホットスポット機能を少し使っています。 クリックすると、ページがまず黒くなり、次にロードが停止しているように見えるページにジャンプします。このブラックアウトはロード失敗ではなく、少し待つと問題が解決します。 第1.5関：ブラックアウト中のロード ページはほぼ完全に黒いです。複雑なソースコードを確認する必要はありません。ページのスクリーンショットを画像エディタに投入し、露出、影、コントラストを調整するだけで十分です。目的も明確で、画像の処理、露出の調整、低コントラスト情報の観察力を試すだけです。 明るくすると、2つの重要な情報が見えます： 開催コード：blog10years 次のエンディング：/level/googleLogin/login.html 第2関：ログインページ ログインページにはユーザー名、パスワード、招待コードが必要です。ユーザー名は自分で入力できますが、招待コードは前のエンディングで見つけた blog10years です。 本当に厄介なのはパスワードです。開発者ツールを開き、Consoleで buildLoginHash 処理が既に定義されていることを確認します。直接呼び出すだけでよいです： buildLoginHash("阿珏", "blog10years") ユーザー名が変更された場合は、処理内のユーザー名も変更してください。HMAC-SHA256文字列として返される処理をコピーし、パスワードとして使用します。パスワードを手動で計算する必要はありません。 ログイン前にキャプチャーを完了する必要があります。正しいを選択すると本当にログインできます。 このエンディングは、ソースコードを確認する習慣や開発者ツールの使用を試しています。パスワードは長い暗号化テキストのように見えますが、ページは生成方法を目の前で提供しています。 ps:阿珏酱が使ったアイコンはこの数年で何度も明かされてきました。 ...

ルール： マークダウン構造を保護する。 URLやコードを翻訳しない。 追加のコメントなしで翻訳された内容を返す。 # MoeKoe Music Mobile オープンソースでシンプルで高颜值のサードパーティーKuGou Musicのモバイル端末プレイヤー Expo / React Nativeに基づいて構築され、MoeKoeMusicデスクトップ版のモバイル版実装です 🌎 GitHubリポジトリ | 📦️ ダウンロードパッケージ | 💬 ブログアクセス | 🏠 プロジェクトホームページ オープンソースでシンプルで高颜值のサードパーティーKuGou Musicのモバイル端末プレイヤー Expo / React Nativeに基づいて構築され、MoeKoeMusicデスクトップ版のモバイル版実装です ✨ 特徴 🎵 サーバー自建不要 — KuGou APIのアダプテーションレイヤーが直接公式に直結し、すぐに使用可能で、外部APIアドレスに依存しません 🏠 ホームページの推薦 — 毎日の推薦、選定歌単、ランキング 🧭 発見ページ — カテゴリ別歌単、新曲速報などのコンテンツ探索 🔍 検索 — 歌曲や歌単、アルバムの迅速な検索 📀 歌単 / アルバム / ランキング — 完全な詳細ページと曲リスト 🎧 プレイヤー — ロールシャッター歌詞、プレイリスト、ミニプレイヤー（MiniPlayer）、バックグラウンドプレイ 🎚️ 音質検出 — 利用可能な音質を自動的に検出し、選択 📱 電話番号ログイン — KuGouアカウントの收藏と歌単の同期 🌗 ダークモード — システムに従って明暗テーマを自動的に切り替え 📝 Todoリスト [x] ホームページの毎日の推薦 / 選定歌単 / ランキング [x] 発見ページのカテゴリ別内容の閲覧 [x] 歌曲や歌単、アルバムの検索 [x] 歌単 / アルバム / ランキングの詳細ページ [x] プレイヤー：ロールシャッター歌詞、プレイリスト、ミニプレイヤー、バックグラウンドプレイ [x] 音質検出と自動選択 [x] 電話番号ログイン [x] 認証情報ログイン [x] スキャンログイン（他のデバイス） [x] いいね / 收藏の同期 [x] ユーザー歌単管理（作成 / 收藏 / 編集） [ ] 通知バー / ロックスクリーンプレイコントロール [ ] 歌曲詳細の閲覧 [ ] テキストから歌詞の検出 [ ] タブレットと横画面の対応 [ ] パフォーマンス最適化 📸 プレビュー 🚀 快速スタート 環境要件 Node.js ≥ 22 Git iOSシミュレータ / Androidシミュレータ、または開発版クライアントがインストールされた実際のデバイス 開発と実行 # リポジトリをクローン（api submoduleを含む） git clone --recurse-submodules https://github.com/MoeKoeMusic/MoeKoeMusic-Mobile.git cd MoeKoeMusic-Mobile # 依存関係をインストール npm install npm --prefix api install # モバイル端末APIエントリを生成（api/ 更新後は再実行が必要） npm run generate:mobile-api # 開発サーバーを起動 npx expo start クローン時にsubmoduleが欠けている場合は、git submodule update --initを実行して補完できます。 ...

ルール： Markdownの構造を保護する。 URLやコードは翻訳しない。 翻訳された内容のみを返す。 MoeKoe Music エクステンション MoeKoe Music ブラウザエクステンション版は、MoeKoeMusic Webをベースに構築され、ブラウザエクステンション内でAPIルートの互換性を完了しています。 🌎 GitHubリポジトリ 特徴 ブラウザエクステンションのアイコンをクリックして、独立したウィンドウでMoeKoeMusicを起動します。 ユーザーがAPIアドレスを設定する必要はなく、ローカルのAPIサービスを追加で起動する必要もありません。 MoeKoeMusicのオリジナルWebページとインタラクションを保持し、ブラウザエクステンションの運行環境に互換性があります。 快速スタート 環境要求 Node.js 20以降 Git Chrome / EdgeなどのChromiumコアブラウザ 依存関係のインストール git submodule update --init --recursive npm install npm run install:app npm run install:appは、MoeKoeMusicとMoeKoeMusic/apiの依存関係をそれぞれインストールします。インストール後は、子モジュールのワークスペースを確認し、アップストリームのlockfileの非期待の変更をコミットしないようにしてください。 エクステンションの構築 npm run build 構築物は以下に输出されます： dist/extension ブラウザにインストール chrome://extensionsまたはedge://extensionsを開きます。 「開発者モード」を有効にします。 「既に解凍されたエクステンションをロード」をクリックします。 プロジェクトのdist/extensionディレクトリを選択します。 extensionソースディレクトリをロードしないでください。そうすると、ブラウザはマニフェストやバックグラウンドスクリプトの読み込みに失敗を通知します。 APIの実行方法 MoeKoe Music Webバージョンに比べて、このプラグイン版はユーザーにAPIアドレスを入力させることはありません。MoeKoeMusicのフロントエンドは、HTTPルートに基づいてリクエストを送信し、ビルド時にAxiosリクエストをエクステンション内部のメッセージチャネルに適用します。 リクエストフローは以下の通りです： MoeKoeMusic Web -> extension/app/api-adapter.js -> extension/api/service-worker.cjs -> extension/api/generated/modules.cjs -> extension/api/generated/modules.cjs -> MoeKoeMusic/api/module/*.js -> 酷狗関連インターフェース extension/api/generated/modules.cjsは生成ファイルで、scripts/generate-extension-api-entry.mjsがMoeKoeMusic/api/moduleをスキャンして生成します。APIモジュールを追加または更新した場合、以下のいずれかの命令を再実行します： ...

ルール： マークダウン構造を保護。 URLやコードを翻訳しない。 追加のコメントなしで翻訳された内容を返す。 ルール： マークダウン構造を保護。 URLやコードを翻訳しない。 追加のコメントなしで翻訳された内容を返す。 ルール： マークダウン構造を保護。 URLやコードを翻訳しない。 追加のコメントなしで翻訳された内容を返す。 在做插件市场之前，先有的是 MoeKoe 的普通插件系统。 当時我想解决的问题不是某一个具体功能，而是一个更通用的问题：播放器里总会冒出很多小需求，有些人想改界面，有些人想加一个工具弹窗，有些人想接自己的服务。如果每个想法都往主程序里塞，主程序会越来越重，也越来越难维护。 所以我一开始给插件系统定的方向很明确：主程序只提供插件运行环境和管理入口，具体功能交给插件自己做。插件能独立安装、独立卸载，坏了也尽量不要影响播放器本体。 上一篇我写的是 MoeKoeMusic-Plugins 这个插件登记仓库。那边解决的是“插件市场的数据怎么产生”：用户用 Issue 提交，Action 校验，维护者审核，通过后写进 plugins.json。 但光有登记仓库还不够。真正对用户来说，插件市场不是 GitHub 上的一份 JSON，而是客户端里一个能看、能搜、能安装、能更新的入口。 所以这篇就换到 MoeKoe Music 主项目里，专门聊客户端的插件市场部分。 为什么选 Chrome Extension 这一套 MoeKoe は Electron アプリであり、Electron 自身に拡張の読み込み能力があります。既に Chrome Extension が動作する底層があるので、新しいプラグインフォーマットをゼロから設計する必要はありません。 この方法はいくつかの利点があります： 第一，プラグイン作者は完全に新しいフォーマットを学ぶ必要がありません。manifest.json、popup.html、background.js はすべてブラウザ拡張でよく使われる概念です。 第二，プラグインには天然のリストファイルがあります。主プログラムはまず manifest.json を読み取り、プラグイン名、バージョン、説明、権限、ポップアップエントリ、最低サポートバージョンなどの情報を判断します。 第三，Electron はプラグインディレクトリを直接読み込むことができます。私がサンドボックススクリプトを書く必要はありません。 展示、検索、分页と状態 プラグイン市場はインストールできるだけでなく、迅速に判断する必要があります： このプラグインは何をしていますか 私はこれをインストールしていますか 私がインストールしているのは旧バージョンですか このプラグインにはより高いバージョン要求がありますか それがネットワーク、ファイルアクセス、ローカルバイナリなどのリスクポイントを持っていますか 分页、検索、更新、状態 したがって、市場カードには「インストール」ボタンだけでなく表示されます。 プラグインディレクトリが存在することを確認 Electron を呼び出してダウンロード、インストール、旧バージョンをアンインストール、新しいバージョンをインストール プラグイン関連の IPC を登録 Chrome 拡張をロード Native Host インデックスと認証システムをロード 已安装插件 プラグイン管理ページの「已安装插件」は、現在読み込まれている Electron 拡張だけでなく、二つの情報を統合します： ...

ルール： マークダウン構造を保護する。 URLやコードを翻訳しない。 翻訳された内容のみを返す。 MoeKoe Music 插件エコシステムを最初に作成した時、オンラインプラグイン市場という機能はまだありませんでした 後にコミュニティの提案により、このプラグイン市場が誕生しました 公式/コミュニティプラグインリポジトリを追加して製品機能を拡張 プラグインはコミュニティで開発されるので、プラグイン市場はどう管理すべきか？ 最も直接的な方法は、すべてのプラグインソースコードを一つの大リポジトリにまとめることです。しかし、この案は考えれば考えるほど不自然に感じられました。それぞれのプラグインには、それぞれの作者、それぞれのリリースリズム、それぞれのビルド方法があります。これらをすべて公式リポジトリにまとめると、メンテナンスコストが高くなるだけでなく、責任範囲も曖昧になります。 したがって、このリポジトリは最終的には「プラグインソースコードリポジトリ」として設計されず、代わりに「プラグイン登録とインデックスリポジトリ」となりました。それは以下の数点を行います： プラグインの上架、更新、下架、および報告の申請を受け取る 基本的な検証と静的認識を自動的に行う 人工的に承認されたプラグインのスナップショットを記録する クライアントが読み込める plugins.json を維持する READMEにプラグインリストを更新する、人々が読みやすくする 追跡可能な登記簿：誰が提出したか、どのバージョンが承認されたか、ダウンロード先はどこか、ネットワークやファイルの権限はどうか、すべて明確なデータにまとめられます。 市場インデックス、ソースコードリポジトリではなく リポジトリのルートディレクトリで最も重要なファイルは plugins.json です。これがプラグイン市場が実際に消費するデータソースです。 { "id": "custom-app-background", "name": "カスタム背景画像", "description": "MoeKoe Musicにカスタム背景画像機能を提供し、透明度調節をサポート。", "iconUrl": "...", "version": "1.0.0", "minversion": "1.6.1", "...":"....", "buildRequired": false, "networkAccess": false, "fileAccess": false, "binaryContent": false, "snapshot": { "iconUrl": "...", "repository": "MoeKoeMusic/custom-app-background-plugin", "commitSha": "dbf72d38c8cf6b1d1cefdf8ce15798d565678995", "downloadUrl": "hxx.zip", "release": null } } 私は市場が「プラグインリポジトリの「現在の最新コード」を常に記録するようにしないことを望んでいます。なぜなら、作者が今日提出したコードと、承認当日に見たコードが同じものではなかったかもしれないからです。プラグイン市場が本当に認めるべきは、承認されたバージョンです。 したがって、このプロジェクトには以下の核心原則があります： 上架されるのは、動き回るリポジトリのアドレスではなく、既にロックされたスナップショットです。 コンパイル不要のプラグインの場合、スナップショットはデフォルトブランチの当時のcommitにロックされます。コンパイルが必要なプラグインの場合、スナップショットは対応するReleaseタグと发行附件にロックされます。これにより、実際に問題が発生した場合でも、当時どのバージョンが承認されたかを振り返ることができます。 アクションが先に動く、人間が最後に決定する ユーザーがIssueを提出する際には、以下の選択を行う必要があります： 「新規上架」または「プラグインの更新」 GitHubリポジトリのアドレス インストール前にコンパイルが必要かどうか Actionが自動検証を行い、結果をIssueのコメントに書き込むと同時に、check-passedまたはcheck-failedタグをIssueに付ける。 ...

続き：《同じアニメーション、3つの技術スタックで実装したらどう違うの？》 WebGL による二次元じゃんけんゲーム。 ルールは普通： グー > チョキ チョキ > パー パー > グー でも面白いのはここ： 負けると服を脱ぐ。 ええ、それだけです。単純かつストレート。 きっかけは「スプライトシートを研究したかった」 最初はゲームを作るつもりなんてなかった。 ただ研究したかっただけ： atlas sprite レイヤー合成 アニメーションカット こんな技術要素。 それで考えたんです：「実際に使える場面がないと？」 そして思い付き： じゃあ、二次元脱衣じゃんけんにすればいいと。 そしたらプロジェクトが暴走し始めた。 このプロジェクトで一番大変だったのはゲームロジックじゃない じゃんけんのルールはシンプルすぎる。 本当に大変だったのは：服のレイヤー管理 キャラクターは「1枚の完成した画像」ではなく： ベース画像 (全裸バレ防止のため、わざと暗号化済み) 服 A 服 B 服 C アクセサリー 遮蔽レイヤー 重ね続ける。 「脱衣」の正体はレイヤー管理 プレイヤーが勝った： 設定された順番で服を1枚除去 コンピュータが勝った： 逆順で服を着せる 聞こえるのは簡単。 実際は山のような問題にぶつかる： 例えば「ベース画像が一瞬見えてはいけない」 これは特に重要。 もしこうすると： 古い服を先に消す 新しい服を後で追加する その一瞬ベース画像がチラ見えする。 見た目がすごく変になる。 なので後で：reveal カバーロジックを使うことにした。 新しいレイヤーが即座に上に被さる。 極力避けたい： 「裸が1フレーム映り込む」 プロジェクト自体は不真面目に見えるけど 少なくとも技術的には美しくありたい。 WebGL はここで本当に心地いい このプロジェクトは最終的に WebGL で実装した。 理由はシンプル：レイヤーが多すぎる。 ...

最近、なかなか面白い小実験をやってみました。 二次元キャラクターのちょっとしたアニメーション効果を、それぞれ： WebGL Canvas 2D 純 DOM + CSS の3つの方法で実装し直しました。 効果自体は複雑ではありません： まばたき 眉毛/下まぶたの連動 汗のゆらゆらした揺れ アホ毛の振り動き でも本当に面白いのは、「作れた」こと自体ではなく： 同じものを、3つの技術スタックで実装したとき、どれくらい差が出るのか？ というところです。 本質的には「フロントエンドグラフィクス色の濃い」再現実験でした。 最初はただアホ毛アニメーションを再現したかった インスピレーション元：https://tamanidamani.itch.io/nijikas-ahoge 当時のシンプルな思い：「自分だったらどう実装する？」 そしてやるほどに熱中してしまい、最終的にこうなりました： じゃあ、WebGL、Canvas2D、DOM の3パターン全部作ってみよう。 そうしてリポジトリは今の形になりました： canvas/ canvas2D/ dom/ 同じ効果を3つのバージョンで実装しています。 まず結論 一言でまとめるなら： WebGL が最強だけど、Canvas2D が一番書きやすくて、DOM がビジネス向け 1. WebGL バージョン：「本当のゲーム開発」に一番近い このバージョンが一番手間がかかります。 なぜなら本質的には「フロントエンドアニメーション」ではなく：GPU グラフィクスプログラミング だからです。 どう実装しているのか？ コアとなる考え方は： 背景レイヤー1枚 スプライトを重ねていく shader で描画制御 JS でアニメーションパラメータを動かす 例えば： アホ毛の回転 まばたきの切り抜き alpha ブレンド これらはすべて GPU 側で処理されます。 だんだんとこういうものに触れるようになります： uniform texture shader UV 頂点座標 テクスチャ座標 そして笑顔が消えていきます。 でも WebGL は本当に強い 要素が増えてくると、WebGL の「全然平気」という感覚が際立ちます。 特に： ...

最近、コードを書くときに奇妙な感覚がある。 書けないわけでもなく、書きたくないわけでもない。 だが—— 自分の書くことがどんどん不要になっているような気がする。 かつては、機能を実装する際の流れはこうだった。 要件を理解する → 設計を考える → コードを書く → デバッグ → バグ修正 → リリース 今はどうなっている？ 要件を説明する → AIがコードを書く → AIがバグを直す → 確認するだけ → リリース その間にあった「コードを書く」という大きな部分が、突然薄くなり、ほぼ存在しなくなる。 最初はそれがすごく楽だった。 だが、楽しくなるにつれて少し不安になる。 かつてのプログラマーは、「タスクを完了する」ことで得られる達成感に加え、コードを書く過程そのものにも多くの喜びを感じていた。 コードを書くことって、もはや重要じゃない？ かつて私はプログラマーの最も核となる能力は「コードを書くこと」だと思っていた。 速さ、美しさ、抽象化の度合い——これらが「レベル」の差を作っていた。 だが、今ではこの基準がだんだん通用しなくなってきている。 多くのコードは、人間よりAIの方が早く、あるいは同じくらい良く書ける。 特に以下のようなもの： CRUD API連携 通常のロジック処理 AIは圧倒的な効率でこなしてしまう。 時々自分で書いたコードをAIに投げるようになる。 「ちょっと見直して」 すると、単に改善されただけでなく、自分が気づかなかったケースまで補ってくれる。 その瞬間、微妙な違和感がある—— このコード、誰が書いたのか区別できない。 さらに奇妙なのは、自分で書くのをやめてしまうこと これが本当に危険だ。 かつてはコードを書くことは「制御感」だった。 一行一行自分が打ったし、なぜそう書いたのか理解していたし、どこに問題があるかも把握していた。 だが、AIに任せることに慣れてくると、自分で書くことが逆に遅くなることに気づく。 そしてこう感じるようになる： 「なぜ自分で書かなきゃいけないのか？」 これは怠惰ではなく、効率の自然な選択だ。 大きな整数を手計算しないように、自動で生成できるコードを自分で書く必要もなくなる。 プログラマーは、別の役割へと変貌している だんだんと毎日の業務内容が変わってきていることに気づく。 もはや： どれだけコードを書くか どんなデザインパターンを使うか コードがきれいかどうか ではなく、 この要件は何をしたいのか？ AIにどう伝えると誤解されないか？ 結果は正しいか？ ということに時間を費やすようになる。 コードを書く時間よりも、むしろ—— 問題を明確にする時間がかかる。 ...

これは100%分散型のブロックチェーンお年玉（レッドパケット）アプリケーションです。ユーザーはウォレットを接続し、金額と数量を設定してお年玉を送信し、リンクを通じて他の人と共有して受け取ることができます。すべてのデータと操作はブロックチェーンに基づいており、中央集権型サーバーは一切不要で、プロセス全体が安全、透明、追跡可能です。 興味があれば、GitHubで私のコードをご覧ください：redpacket‑dapp 機能ハイライト 🧧 お年玉の送信: ウォレットを接続後、金額と数量を設定してブロックチェーンにお年玉を送信します。 🎁 お年玉の受け取り: 共有リンクを通じて、他の人はウォレットを接続してブロックチェーンから直接お年玉を受け取ることができます。 🔗 スマートコントラクト: Solidityで書かれた安全なスマートコントラクトがすべてのロジックを処理します。 🌐 マルチチェーン対応: ローカルテストネットとBSCテストネットをサポートします。 💼 Web3統合: MetaMaskウォレットを使用して接続します。 🚀 完全分散型: バックエンドサーバーがなく、すべてのデータはブロックチェーンに保存されます。 技術スタック フロントエンド：React 19、React Router 6、TypeScript、Vite、Ethers v6 コントラクト層：Hardhat、Solidity 0.8.x ツール：ESLint、Prettier バックエンド不要: サーバーへの依存なし ❌ クイックスタート # 1. プロジェクトの依存関係をインストール npm install cd react-dapp && npm install && cd .. # 2. ローカルブロックチェーンノードを起動 npm run node # 3. スマートコントラクトをコンパイル npx hardhat compile # 4. スマートコントラクトをデプロイ npm run deploy # 5. フロントエンドを起動 npm run frontend ディレクトリ構造 redpacket-web3/ ├─ contracts/ # Solidity スマートコントラクト │ └─ RedPacket.sol ├─ react-dapp/ # React + Vite フロントエンド │ ├─ src/ │ │ ├─ components/ # 共通コンポーネント（ウォレットボタン、作成フォームなど） │ │ ├─ config/ # ABI、コントラクトアドレス設定 │ │ ├─ hooks/ # カスタムフック（useWallet） │ │ ├─ pages/ # ページ（Home、ClaimPacket） │ │ ├─ styles/ # グローバルスタイル │ │ ├─ utils/ # Web3 ユーティリティ関数 │ │ └─ App.tsx # ルーティングとレイアウト │ ├─ .env.example # フロントエンドに必要な環境変数説明 │ └─ package.json ├─ scripts/ │ └─ deploy.js # Hardhat デプロイスクリプト（自動的にフロントエンド設定に書き込みます） ├─ hardhat.config.js └─ package.json # ルートディレクトリのスクリプト（Hardhat + フロントエンドをワンクリックで起動） 使用ガイド お年玉の作成 フロントエンドを開き、右上の「ウォレットを接続」をクリックします。 お年玉の総額と個数を入力すると、アプリケーションがフロントエンドで金額をランダムに分割します。 送信後、MetaMaskでトランザクションを確認し、ブロックの承認を待ちます。 成功後、システムが生成した受け取りリンクをコピーして友人と共有できます。 お年玉の受け取り 共有リンク（URLに /claim/{packetId} が含まれる）を開きます。 同様にまずウォレットを接続し、「クリックして受け取る」をクリックします。 署名確認後、ブロックのパッケージングを待ち、ページに結果と残り個数が表示されます。 環境変数 dapp/.env（開発環境では自動的に無視されます。.env.exampleを参照してください） VITE_RPC_URL：フロントエンドが直接接続するノードRPC、デフォルトは http://127.0.0.1:8545 VITE_CONTRACT_ADDRESS：デプロイスクリプトによって書き込まれたアドレスを上書きできます。 VITE_CHAIN_ID：フロントエンドが使用するチェーンID（16進数） root/.env：Hardhatで秘密鍵やBSC RPCを参照する必要がある場合は、既存の記述をそのまま使用できます。 スマートコントラクト（RedPacket.sol） コアメソッド： ...

✨ 緒山まひろの隠れ家 ✨ 🌸 緒山まひろの隠れ家へようこそ 🌸 わぁ！私の秘密基地を見つけちゃったんだね！(*≧ω≦) ここは緒山まひろの個人サイトだよ。かわいいアニメーションと面白いコンテンツがいっぱい！ ここでは、私のお気に入りのアニメ、マンガ、ゲーム、そして日常のささやかな幸せをシェアしていくね～ 💕 私について 💕 私は緒山まひろ。エロゲを愛する引きこもりのダメニートだよ。 アニメ、マンガ、ライトノベル、そしてかわいいものが大好き！ 好きな色はピンクと水色！ ∩∩ （･ω･） <- 私だよ！ ＿|　⊃／(＿＿ ／ └-(＿＿＿／ 🎀 サイトコンテンツ 🎀 🌟 素敵なアニメーション 📚 私のプライベートフォト 🎵 おすすめの音楽 📷 日常のワンシーン 🌈 関連リンク 🌈 🎭 デモ: https://mahiro.moejue.cn/ 🏠 個人ブログ: https://MoeJue.cn/ 🐱 GitHub: https://github.com/iAJue/Mahiro 📧 公式サイト: https://onimai.jp/ 📝 著作権情報 📝 このサイトは @Moejue によってデザイン・開発されました サイト内で使用されているすべてのアニメーション、マンガの画像、キャラクター、および関連コンテンツの著作権は、原作者（ねことうふ）およびその発行元（スタジオバインド、一迅社）に帰属します 著作権侵害の可能性がある場合は、上記の連絡先までお知らせください。速やかに関連コンテンツを削除いたします GNU GENERAL PUBLIC LICENSE Version 2 Copyright © 2025 MoeJue. All rights reserved. 💌 スペシャルサンクス 💌 緒山まひろを好きでいてくれるみんな、ありがとう！(●’◡’●) ...