著者: MoeJue(xxx@example.com)

最近、コードを書くときに奇妙な感覚がある。

書けないわけでもなく、書きたくないわけでもない。
だが——
自分の書くことがどんどん不要になっているような気がする。

かつては、機能を実装する際の流れはこうだった。

要件を理解する → 設計を考える → コードを書く → デバッグ → バグ修正 → リリース

今はどうなっている？

要件を説明する → AIがコードを書く → AIがバグを直す → 確認するだけ → リリース

その間にあった「コードを書く」という大きな部分が、突然薄くなり、ほぼ存在しなくなる。

最初はそれがすごく楽だった。
だが、楽しくなるにつれて少し不安になる。

かつてのプログラマーは、「タスクを完了する」ことで得られる達成感に加え、コードを書く過程そのものにも多くの喜びを感じていた。

コードを書くことって、もはや重要じゃない？

かつて私はプログラマーの最も核となる能力は「コードを書くこと」だと思っていた。

速さ、美しさ、抽象化の度合い——これらが「レベル」の差を作っていた。

だが、今ではこの基準がだんだん通用しなくなってきている。

多くのコードは、人間よりAIの方が早く、あるいは同じくらい良く書ける。

特に以下のようなもの：

• CRUD
• API連携
• 通常のロジック処理

AIは圧倒的な効率でこなしてしまう。

時々自分で書いたコードをAIに投げるようになる。

「ちょっと見直して」

すると、単に改善されただけでなく、自分が気づかなかったケースまで補ってくれる。

その瞬間、微妙な違和感がある——
このコード、誰が書いたのか区別できない。

さらに奇妙なのは、自分で書くのをやめてしまうこと

これが本当に危険だ。

かつてはコードを書くことは「制御感」だった。

一行一行自分が打ったし、なぜそう書いたのか理解していたし、どこに問題があるかも把握していた。

だが、AIに任せることに慣れてくると、自分で書くことが逆に遅くなることに気づく。

そしてこう感じるようになる：

「なぜ自分で書かなきゃいけないのか？」

これは怠惰ではなく、効率の自然な選択だ。

大きな整数を手計算しないように、自動で生成できるコードを自分で書く必要もなくなる。

プログラマーは、別の役割へと変貌している

だんだんと毎日の業務内容が変わってきていることに気づく。

もはや：

• どれだけコードを書くか
• どんなデザインパターンを使うか
• コードがきれいかどうか

ではなく、

• この要件は何をしたいのか？
• AIにどう伝えると誤解されないか？
• 結果は正しいか？

ということに時間を費やすようになる。

この記事は2026-05-05に阿珏酱のBlogで公開され、最終更新日は2026-05-05です

著者: MoeJue(xxx@example.com)

最近、個人ブログに「大改修」を施しました。 単一言語バージョンから多言語サイト（簡体字中国語、繁体字中国語、英語、日本語）にアップグレードし、 その全プロセスを自動化しました。💪

主な内容は以下の通りです。

• メインサイトの記事を自動同期
• コンテンツを自動AI翻訳
• 多言語サイトの自動構築とデプロイ

なぜ Hugo を選んだのか？

それは、その自信に満ちたスローガンがあったからです。

“The world’s fastest framework for building websites.”

—— この一言で、これに決めました 😆。

しかし、私は「一つのテーマで多言語を切り替える」という伝統的な方法ではなく、 各言語に独立したテーマを持たせることにしました。 これにより、各言語バージョンが独自のデザインとレイアウトスタイルを保持し、 真に「文化的なローカライゼーション」を実現できます。

設計目標と制約 🎯

• 言語: 簡体字中国語、繁体字中国語、英語、日本語をサポートし、将来的に拡張可能。
• テーマ: 各言語に最適な Hugo テーマを使用し、無理に再利用しない。
• コンテンツ同期: 全言語で一つのコンテンツリポジトリを共有し、必要に応じて翻訳。
• デプロイ戦略: 各言語を独立して構築・公開し、異なるブランチやドメインにデプロイ可能。
• カスタムページ: 「友だちリンク」、「書斎」、「アーカイブ」などのページは、多言語で一貫した体験を維持する。

多言語設定戦略 🧩

各言語用に個別の設定ファイルを用意しました。 config/<lang>.toml で、主に以下の役割を担います。

1. テーマの指定（例: theme = "PaperMod"）。
2. その言語固有の title / description / keywords の定義。
3. 異なるテーマのナビゲーション構造に合わせるためのメニュー設定 [[params.menu]] の上書き。
4. 全体的な視覚的一貫性を保証するためのカスタムスタイルの注入。

この構造は非常に明確で、将来的にさらに多くの言語バージョンを拡張するのにも便利です。

GitHub Actions 自動デプロイマトリックス ⚙️

CI/CD 部分は完全に GitHub Actions に任せています。 .github/workflows/hugo.yml では、マトリックスビルドを使用し、 各言語を独立して構築・公開しています。

この記事は2025-11-02に阿珏酱のBlogで公開され、最終更新日は2025-11-02です

著者: MoeJue(xxx@example.com)

皆さんが使い倒したあのランダム画像APIを覚えていますか？本日、それがアップデートされました！過去数年間、ランダム画像APIは多くのフロントエンド開発者、二次元サイト運営者、さらにはデスクトッププラグイン愛好家にとっての「おもちゃ」であり「常用ツール」でした。

🥇 第一世代：シンプルだが扱いにくい出発点

当時のランダム画像APIは、正直なところ——単なるPHPスクリプトと1台のクラウドホストでした。当時の目標はシンプルでした：ランダムな画像を返すAPIを提供すること。

特徴は以下の通りです：

• すべてのリクエストが1台のサーバーに集中していました；
• 画像ストレージとAPIサービスが密結合していました；
• キャッシュなし、スマートな分散なし、単一ポイントのパフォーマンスに完全に依存していました；
• ピーク時にはCPUが急上昇し、502エラーが発生し、アクセスが遅く、トラフィックとストレージを消費していました；

[クライアント] ---> [中央サーバー(唯一)] ---> [画像ファイル]

🥈 第二世代：クラウド化とキャッシュの過渡期

第二世代に入ると、ランダム画像APIは「クラウド化」の段階へと移行しました。サービスはクラウドへ移行し、キャッシュ、CDN、ロードバランシングが導入されました。

主な変更点：

• 画像は第三者の画像ホスティングサービス（例：新浪図床）に一元的にホストされました；
• APIはクラウドホストまたは軽量アプリケーションサーバー上で動作しました；
• 基本的なキャッシュロジック（例：RedisまたはNginxキャッシュ層）が追加されました；
• サービス全体がより安定し、アクセス速度も大幅に向上しました。

[クライアント]
   ↓
[クラウドサーバーAPI層] --> [CDN キャッシュ] --> [画像ホスティングサービス(Sina)]

• アクセスは依然として中央サーバーを経由する必要があり、高負荷時や地域ネットワークの分布が不均一な場合、遅延は依然として顕著でした。
• すべてのリクエストはやはり「中央サーバー」を経由する必要があり、
• 一度サーバーがダウンすれば、全体が巻き添えを食らいました 💀。

🚀 第三世代ランダム画像APIが登場！

✨ 主要なハイライト

第三世代ランダム画像APIは、アーキテクチャレベルでの再生です。

Tencent Cloud EdgeOneの3200以上のエッジノードの強力な能力に支えられ、リクエストはグローバルに自動的にスケジューリングされ、ユーザーに最も近いノードで実行されます。これにより、真の非中央集権型分散アーキテクチャが実現されました。

⚡️ 主な変更点：

• 🌐 EdgeOneエッジノードネットワークに依存；
• 🧠 スマートなスケジューリング、近接応答；
• 🧱 エッジ関数をトリガーし、ノードで直接ロジックを実行；
• 📉 アクセス遅延が大幅に削減され、安定性と可用性が大幅に向上。

                            ┌────────┐
 [クライアント]  ──▶      │ 最も近いエッジノード │
                             └───┬─────┘
                                    ↓
                              [エッジ関数がリクエストを処理]
                                    ↓
                            [ランダム画像リンクを応答]

🗂 システムアップデート

• ✅ 2.8万枚の画像を追加し、コンテンツがより豊富に；
• ✅ システムアーキテクチャを完全に再構築；
• ✅ 旧バージョンのアクセス制限を削除；
• ⚠️ 画像は引き続き新浪図床にホストされています（歴史的および周知の理由により）、一時的に中継アクセスを介しています。

📡 アクセス体験アドレス：

👉 https://random.moejue.cn 注：周知の理由により、グローバルアクセラレーションゾーン（中国大陸を除く）

この記事は2025-10-15に阿珏酱のBlogで公開され、最終更新日は2025-10-15です

著者: MoeJue(xxx@example.com)

✨ 緒山まひろの隠れ家 ✨

🌸 緒山まひろの隠れ家へようこそ 🌸

わぁ！私の秘密基地を見つけちゃったんだね！(*≧ω≦)

ここは緒山まひろの個人サイトだよ。かわいいアニメーションと面白いコンテンツがいっぱい！ ここでは、私のお気に入りのアニメ、マンガ、ゲーム、そして日常のささやかな幸せをシェアしていくね～

💕 私について 💕

私は緒山まひろ。エロゲを愛する引きこもりのダメニートだよ。 アニメ、マンガ、ライトノベル、そしてかわいいものが大好き！ 好きな色はピンクと水色！

  ∩∩
（･ω･）  <- 私だよ！
＿|　⊃／(＿＿
／ └-(＿＿＿／

🎀 サイトコンテンツ 🎀

• 🌟 素敵なアニメーション
• 📚 私のプライベートフォト
• 🎵 おすすめの音楽
• 📷 日常のワンシーン

🌈 関連リンク 🌈

• 🎭 デモ: 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.

💌 スペシャルサンクス 💌

緒山まひろを好きでいてくれるみんな、ありがとう！(●’◡’●)

この記事は2025-08-23に阿珏酱のBlogで公開され、最終更新日は2025-08-23です

著者: MoeJue(xxx@example.com)

始める前に、まず基本的な概念を簡単に理解しましょう。以下のいくつかの点にまとめました。Web3.0とは何か、ブロックチェーンとどのような関係があるのか？（前回の記事がここで役立ちますね）

要件：PythonベースのWeb 3.0画像アップロードシステムを開発します。このシステムは、ユーザーが画像をアップロードし、その画像を分散型ネットワークに保存し、同時にトランザクション情報をブロックチェーンに記録することを可能にします。もともとは遊びで書いていたもので、ユーザー認証やファイル操作を統合した完全な管理システムにして、「画像アップロードサービスの最終的な解決策」にしようと考えたこともありましたが、実際にやってみるとあまり現実的ではないことに気づき、断念しました。しかし、私は昔から画像にこだわりがあるのです。

ステップの概要

1. 環境設定：Pythonを使用して開発し、必要なPythonライブラリをインストールします。
2. IPFS統合：画像をIPFSにアップロードし、画像のCID（Content Identifier）を取得します。
3. ブロックチェーン統合：IPFSのCIDをブロックチェーンに記録します。
4. Webインターフェース：Flaskを使用して、ユーザーが画像をアップロードできるWebインターフェースを作成します。

詳細なステップ

1. 環境設定

必要なPythonライブラリをインストールします：

pip install flask web3 ipfshttpclient

2. IPFS統合

IPFS（InterPlanetary File System）は、ピアツーピアのファイルストレージプロトコルです。ipfshttpclientライブラリを使用してIPFSネットワークと対話できます。

まず、IPFSノードをインストールして実行していることを確認してください。まだIPFSをインストールしていない場合は、IPFS公式サイトでインストールガイドを見つけることができます。

以下は、画像をIPFSにアップロードするコード例です：

import ipfshttpclient

def upload_to_ipfs(file_path):
    client = ipfshttpclient.connect('/ip4/127.0.0.1/tcp/5001')
    res = client.add(file_path)
    return res['Hash']

3. ブロックチェーン統合

web3.pyライブラリを使用してIPFSのCIDをブロックチェーンに記録します。ここではイーサリアム（Ethereum）をサンプルブロックチェーンとして使用します。

以下は、IPFSのCIDを保存するための簡単なスマートコントラクトの例です：

pragma solidity ^0.8.0;

contract IPFSStorage {
    mapping(address => string[]) public userCIDs;

    function storeCID(string memory cid) public {
        userCIDs[msg.sender].push(cid);
    }

    function getCIDs() public view returns (string[] memory) {
        return userCIDs[msg.sender];
    }
}

このコントラクトをコンパイルしてデプロイした後、以下のPythonコードを使用してスマートコントラクトと対話します：

この記事は2024-06-17に阿珏酱のBlogで公開され、最終更新日は2025-07-06です

著者: MoeJue(xxx@example.com)

初めてのマルチチェーンウォレット統合の実践的考察

ようやく時間ができてコードを整理できるようになりました。Web3プロジェクトでマルチチェーンウォレット接続機能を導入する際、主にEthereum、Polygon、BSC、Solanaが関わってきます。一見すると「互換性のあるロジックをいくつか追加するだけ」のように思えますが、実際に実装してみると、多くのことが思ったほど単純ではないと気づきました。

this.networkConfigs = {
    ethereum: {
        chainId: '0x1', // 1
        chainName: 'Ethereum Mainnet',
        nativeCurrency: {
            name: 'Ethereum',
            symbol: 'ETH',
            decimals: 18
        },
        rpcUrls: ['https://eth-mainnet.public.blastapi.io'],
        blockExplorerUrls: ['https://etherscan.io']
    },
    polygon: {
        chainId: '0x89', // 137
        chainName: 'Polygon Mainnet',
        nativeCurrency: {
            name: 'MATIC',
            symbol: 'MATIC',
            decimals: 18
        },
        rpcUrls: ['https://polygon-rpc.com'],
        blockExplorerUrls: ['https://polygonscan.com']
    },
    bsc: {
        chainId: '0x38', // 56
        chainName: 'BNB Smart Chain',
        nativeCurrency: {
            name: 'BNB',
            symbol: 'BNB',
            decimals: 18
        },
        rpcUrls: ['https://bsc-dataseed.binance.org'],
        blockExplorerUrls: ['https://bscscan.com']
    }
}

マルチチェーンは単に「複数のウォレットをサポートする」ことではない

最も強く感じたのは、チェーンが異なればウォレットのインタラクション方法も異なり、SDKの考え方すら違うということです。イーサリアムエコシステムでは統一されたWeb3.jsで多くのロジックを処理できますが、Solanaになると、完全に別のシステムであることがわかります。プロバイダーの接続、接続フロー、PublicKeyの構築方法が異なり、ネットワークの遅延や安定性までもがユーザー体験に影響を与えます。

この記事は2025-07-05に阿珏酱のBlogで公開され、最終更新日は2025-07-05です

著者: MoeJue(xxx@example.com)

プロジェクト概要

今日のWeb開発分野において、ユーザーエクスペリエンスとインターフェースデザインはますます重要になっています。

Mac Web Vue Templateは、macOSのデザインにインスパイアされた、モダンでエレガントなVue.jsのWebテンプレートです。Vue.jsをベースにした現代的なWebアプリケーションテンプレートであり、そのデザインはmacOSの優雅なインターフェースから着想を得ています。このプロジェクトは、美しいUIデザインだけでなく、完全なプロジェクト構造とベストプラクティスも提供します。

オンラインデモ

WebAi にアクセスすることで、このテンプレートの実際の効果を体験できます。招待コード(MoeJue)

主な特徴

1. macOS風のUIデザイン

   • macOSのデザイン言語を採用
   • 洗練されたすりガラス効果
   • エレガントなアニメーショントランジション

2. モダンな技術スタック

   • Vue.jsをコアフレームワークとして使用
   • Viteをビルドツールとして使用
   • Piniaによる状態管理
   • Vue Routerによるルーティング処理
   • SCSSプリプロセッサ
   • ES6+のモダンな機能

3. レスポンシブデザイン

   • あらゆる画面サイズに完璧に対応
   • スムーズなモバイル体験

プロジェクト構造の解説

プロジェクトは、明確でモジュール化されたディレクトリ構造を採用しています：

src/
├── assets/          # 静的リソース
├── components/      # Vueコンポーネント
│   ├── common/     # 共通コンポーネント
│   ├── system/     # システムコンポーネント
│   └── apps/       # アプリケーションコンポーネント
├── views/          # ページビュー
├── router/         # ルーティング設定
├── stores/         # 状態管理
└── utils/          # ユーティリティ関数

この構造設計により、プロジェクトは良好な保守性と拡張性を備えています。

この記事は2025-05-11に阿珏酱のBlogで公開され、最終更新日は2025-05-11です

著者: MoeJue(xxx@example.com)

近況

前回の雑談からもう2ヶ月以上も経ってしまいました。そろそろ自分の考えを整理する時が来たようです。前回は色々と感慨を述べたきり音沙汰がなかったので、少し急ぎすぎたかもしれません。その後の作業が追いつかなくなってしまいました。

また国慶節の季節がやってきました。やはり私の国慶節は「独身の日（ダブルイレブン）」のようなものです。以前所有していた3つのドメイン（52ecy.cn, moeins.cn, moeins.com）は、復活戦には勝ったものの、装備がなくなってしまいました。

そのため、ドメインを新規購入するしかありませんでした。同時にもブログを復旧させました。やはり自分でいじりたいのでしょう。博客园（cnblogs）に間借りするのは、どうも居心地が悪く感じます。

以前からずっと使っていたemlogですが、この機会に思い切ってシステムをWordPressに移行し、同時に新しいテーマに切り替えました。このテーマは专收爆米花さんが21年頃にリリースしたもので、当時locで見かけてすぐにstarを付け、私のGitHubで4年間眠っていましたlolimeow。当時はずっとemlogを使っていたので、いじるのが面倒だったのです。この機会に乗じて、徹底的にやろうと決め、データの移行やテーマの調整など、かなりの手間をかけました。

作者の方がずっとテーマの更新を積極的に進めてくれていたおかげで、使用中に大きな問題はありませんでした。しかし、私が以前使っていたシステムの機能がいくつか欠けていたので、私もこのテーマを更新し、元のリポジトリにプルリクエストを送りました。上に貼ったGitHubのリンクは私が更新した後のものです。 最も面倒だったデータ移行の部分ですが、ネットで長いこと探し回ってもexe版しか見つかりませんでした。exe版はなんとなく不安な感じがする上に、私は今Macを使っているので、直接実行することもできません。「ないなら自分で作ればいい」ということで、時間をかけて移行スクリプトを自作するしかありませんでした。GitHubのアドレスは記事の最後に載せてあります。emlogのデータをWordPressに完璧に移行できます。さすが俺！

画像はこれまで通り、一部はバックアップとして七牛云（Qiniu Cloud）に、もう一部は新浪图床（Sina Image Hosting）に保存しています。移行してみると、市場には私に適した使いやすい七牛云プラグインがなかったので、また自分で一つ作りました。

新ドメイン

あまり気は進みませんでしたが、またドメインを変更するしかありませんでした。以前のドメインは他人の肥やしになってしまいました。萌音シリーズ：MoeKot.cn。「萌音ノート」「萌音カード」「萌音コミュニティ」「萌音ストア」などを含む萌音シリーズは、今後このドメインの下に置かれます。メインサイトシリーズ：MoeJue.cn。これは私のメインサイトで、ブログやシリーズに属さないプロジェクトなどがこのドメインの下に置かれます。

解説

Moe: 日本語の「萌え」の読み方で、ローマ字表記です。中国語では一般的に「萌」と訳されます。 Kot: 日本語の「声（こえ）」を意味する言葉で、ローマ字表記です。 Jue: 阿珏（A Jue）ちゃんの簡単な音訳です。

ブログ

私はとても昔を懐かしむ情に厚い人間なので、以前のブログもすべて残してあります。Xlog cnblogs emlog Blog 関連サイトのドメインも移行しましたが、すべてをリストアップするのはやめておきます。もちろん、一部のリンクが完全に置換されていない可能性もあります。

すべてのデータは元のままで、誰一人のデータも欠けていません。ブログの登録ユーザーのデータさえも一緒に移行したので、新しいシステムで直接ログインできます。パスワードも同じです。

ぜひstarを付けてください！

使い方もREADME.mdに書いておきました。何か問題があれば、直接issueを立ててください。

emlogからWordPressへの移行スクリプト

私のブログは間もなくTencent Cloud開発者コミュニティにも同期される予定です。皆さんのご参加をお待ちしています：https://cloud.tencent.com/developer/support-plan?invite_code=15kxzzid10tgx

この記事は2024-10-03に阿珏酱のBlogで公開され、最終更新日は2024-10-26です

著者: MoeJue(xxx@example.com)

ArticleSync - マルチプラットフォーム記事同期プラグイン

ArticleSyncは、ユーザーが複数のソーシャルプラットフォームに記事を簡単に同期・公開できるブラウザ拡張機能です。ローカルの下書きから、知乎（Zhihu）やBilibiliなどの主要プラットフォームに記事を公開することをサポートしています。これにより、異なるソーシャルメディアプラットフォーム間で記事を同期する作業が、シンプルかつ効率的になるワンストップソリューションを提供します。

ブラウザ拡張機能の仕組みに基づき、ローカルでログインしているアカウントを自動的に検出し、アカウント情報の漏洩や環境の異常といったリスクを防ぎます。

Chrome Manifest V3ブラウザ拡張機能の標準に基づいて開発されており、カーネルのバージョン要件にご注意ください。

背景

ご存知の通り、私は最近、いくつかのブログプラットフォームと多くのソーシャルサイトを新たに使い始めました。もし、それらすべてで活発に更新を続けたいと思ったらどうすればいいでしょうか。（私がまだ生きていることを証明するために）ついでに、ワンクリックで記事を転載することもできます。

私が最も頻繁に更新するのは自分の小さなサイトですが、他のプラットフォームはたまにしか更新しません。しかし、毎回手動で投稿するのは面倒です。そこで、ローカルでログインしているアカウントを自動検出し、自動で投稿してくれるプラグインが作れないかと考えました。

「自分のことは自分でやる」ということわざの通り、数日間いじくり回して、なんとか使えるものができました。残りの部分は時間があるときに更新します。お金をくれるなら話は別ですが。

このプラグインにはまだ多くの未完成な部分があり、本番環境で複数のプラットフォームでのテストも行っていません。エラーが発生するのはごく普通のことですので、その際はIssueを提出するか、自分で修正してPRを送ってください。てへぺろ〜

話の邪魔にならないように、スクリーンショットは最後に載せておきました。

それと、オープンソースは大変なので、スターを付けてくれると嬉しいです。へへへ〜

本当は、私のコミュニティプラットフォームを自動でフォローするような、個人的な機能を追加しようかとも思いました。

機能と特徴

• マルチプラットフォーム対応：知乎（Zhihu）、Bilibiliなどの主要プラットフォームや、自作のオープンソースCMSシステムをサポートしています。
• ステータス追跡：プラグインのインターフェースで記事の同期状況を確認できます。
• アカウント管理：プラグインに連携されている各プラットフォームのアカウント情報を確認できます。
• 高い拡張性：開発者はアダプターパターンを通じて、簡単により多くのプラットフォームに拡張できます。
• 安全性と信頼性：ブラウザ拡張機能の仕組みに基づいているため、アカウントの安全性を確保し、情報漏洩などのリスクを回避します。

Todoリスト

• [ ] 独立した記事エディタ
• [ ] 画像のワンクリック同期
• [x] MarkdownとHTMLの相互変換
• [ ] サードパーティの画像ホスティングサービス
• [ ] 複数アカウント管理
• [ ] マルチOSクライアントバージョン
• [ ] ワンクリックAI要約
• [ ] 動画の同期
• [ ] タグ、カテゴリのサポート
• [ ] より親切なエラーハンドリング
• [ ] より多くのプラットフォームへの対応

対応プラットフォーム

インストール手順

1. リポジトリをローカルにクローンします：

   ---

   この記事は2024-10-16に阿珏酱のBlogで公開され、最終更新日は2024-10-17です

   ]]> 折腾代码