Author: demensdeum

  • AirLLM: 弱いグラフィックス カード上の大規模な言語モデル

    通常、700 億のパラメータを持つ大規模な言語モデルを実行するには、数十ギガバイトのビデオ メモリが必要です。 AirLLM はこの問題にもっと冷静に取り組み、別の方法を提供します。つまり、このようなモデルは、量子化、蒸留、トリミングを行わずに、わずか 4 GB のメモリを備えたビデオ カード上で実行できます。このメモでは、AirLLM がどのように機能するか、どのように使用するかを急いで説明しようとします。また、このライブラリの操作をもう少し便利にする私の小さなプロジェクト AirLLM 実験を共有します。

    AirLLM とは

    AirLLM は、Gavin Li によって書かれた大規模言語モデル推論用のオープンソース ライブラリです。そのアイデアはシンプルでありながら洗練されています。ライブラリは、すべてのモデルの重みをビデオ メモリに一度に保存するのではなく、一度に 1 つのレイヤーだけを GPU にロードします。ウェイトはレイヤーに分割されたシャードの形でディスクに保存され、生成中に各レイヤーが順番にロード、処理、アンロードされます。

    したがって、必要なビデオ メモリの量はモデル全体のサイズではなく、そのレイヤーの 1 つのサイズに依存するということになります。そのため、70B モデルは 4 GB、671B の DeepSeek-V3 は約 12 GB、Qwen3-235B は約 3 GB に収まります。ただし、モデル自体のサイズは、ビデオ カードの機能ではなく、主にディスク容量によって制限されます。

    これらのメモリの節約には速度が犠牲になります。各トークンの生成時に各レイヤーがディスクから読み取られるため、出力は遅くなり、トークンあたり約秒になります。つまり、AirLLM は、簡単なインタラクティブなチャットというよりも、そうでなければハードウェアに適合しないモデルさえも起動できる機能に重点を置いています。

    インストール

    ライブラリは、通常のコマンドを使用して PyPI からインストールされます。

    pip install airllm
    

    初めて起動すると、Hugging Face からモデルがダウンロードされ、レイヤーに分解されます。このプロセスは時間がかかり、多くのディスク領域を消費するため、事前に空き領域を準備する必要があります。必要に応じて、4 ビットまたは 8 ビット圧縮を有効にすることができます。その場合、ブロック量子化が重みに適用され、ディスクからのレイヤーのロード速度が約 3 倍向上しますが、精度はかなり失われます。

    基本的な例

    AirLLM は、Transformers の通常のモデルとほぼ同じ方法で作業できます。 Hugging Face でモデル ID を 1 回入力するだけで十分です。その後、すべてが馴染みます。

    from airllm import AutoModel
    
    MAX_LENGTH = 128
    model = AutoModel.from_pretrained("Qwen/Qwen3-32B")
    
    input_text = ['What is the capital of United States?']
    
    input_tokens = model.tokenizer(
        input_text,
        return_tensors="pt",
        return_attention_mask=False,
        truncation=True,
        max_length=MAX_LENGTH,
        padding=False)
    
    generation_output = model.generate(
        input_tokens['input_ids'].cuda(),
        max_new_tokens=20,
        use_cache=True,
        return_dict_in_generate=True)
    
    print(model.tokenizer.decode(generation_output.sequences[0]))
    

    AutoModel クラス自体がモデル タイプを決定するため、同じ行を Llama、Qwen、DeepSeek に使用できます。また、671B パラメーターを備えた DeepSeek-V3 のようなモデルを使用すると、約 12 GB のビデオ メモリにも収まります。これが主に、このプロジェクトを魅力的なものにしています。

    macOS で起動

    AirLLM は CUDA だけでなく Apple Silicon でも動作します。 macOS では MLX バックエンドを使用するため、mlx と torch をインストールする必要があり、Apple チップのみをサポートします。また、小さな制限もあります。MLX 実装は Llama のようなアーキテクチャのみをサポートするため、Qwen および類似のモデルをこの方法で MacBook 上で起動することはできません。

    使用例

    AirLLM 実験は、大規模な言語モデルをローカルで実行するための 2 つの小さな対話型コンソール ユーティリティです。モデルをロードしてチャットを整理するために毎回同じコードを記述する必要がなくなります。

    最初のツール airllm-lib-usage.py は、AirLLM ライブラリを現在の Python プロセスで直接実行します。総合カタログのモデルの番号付きリストが表示され、必要に応じて不足している依存関係がインストールされ、チャット セッションが開きます。 MLX ランタイムは macOS で使用され、torch は他のプラットフォームで使用されます。

    2 番目のツール airllm-openai-server-client.py は、Docker で実行され、OpenAI 互換の API を提供する airllm-openai-server サーバーの操作に役立ちます。初めて起動すると、ユーティリティは設定を要求し、イメージを収集し、コンテナを選択して、実行中のサーバーへのストリーミング チャットを開きます。繰り返し起動すると、既存のコンテナーが見つかってそれを再利用し、モデルが再度ダウンロードされないようにモデル キャッシュを別の Docker ボリュームに保存します。

    利用可能なモデルのリストは共通モジュール model_catalog.py に含まれているため、両方のツールは同じセットで動作します。チャット コマンド /help、/clear、/exit も一般的です。ソース コードと手順はリポジトリにあります。

    https://github.com/zefir1990/AirLLM-experiments

    注意すべきこと

    最初の応答の準備には数分かかる場合があります。まず、AirLLM がモデルをダウンロードしてレイヤーに分割し、それから生成を開始します。ただし、速度も低いままです。これはメモリを節約するための意図的な妥協です。 metal-llama のようなゲート付きモデルの場合、Hugging Face の規約に同意し、アクセス トークンを渡す必要があります。ダウンロードしたモデルとシャードのキャッシュは削除しないことが最善です。削除しないと、すべてを再度ダウンロードする必要があります。

    リンク

    https://github.com/lyogavin/airllm
    https://github.com/mkamranr/airllm-openai-server
    https://github.com/zefir1990/AirLLM-experiments
    https://pypi.org/project/airllm/
    https://huggingface.co/

    ソース

    https://github.com/lyogavin/airllm
    https://github.com/zefir1990/AirLLM-experiments

  • OpenCodeのインストールとDeepSeekの接続

    OpenCode は、ターミナル内に常駐するオープン プログラミング エージェントです。プロジェクト ファイルの読み取り、コードの編集、コマンドとテストの実行、リポジトリの検索、git の操作が可能です。これは、Claude Code や他のコンソール エージェントが行うこととほぼ同じです。主な違いは、OpenCode が 1 つのモデル プロバイダーに関連付けられていないことです。DeepSeek を含む数十のプロバイダーを OpenCode 経由で接続できます。この投稿では、エージェントのインストールと DeepSeek への接続について説明します。

    必要なもの

    作業するには次の 2 つのことだけが必要です。

    • 最新の端末。 WezTerm、Alacritty、Ghostty、Kitty などの端末を使用できます。
    • プロバイダーの API キー。 この場合は、DeepSeek。

    標準のインストール スクリプトを使用してエージェントをインストールする場合、Node.js は必要ありません。バイナリは既製の状態で届きます。

    インストール

    最も簡単な方法は、公式のインストール スクリプトです。

    curl -fsSL https://opencode.ai/install | bash
    

    プラットフォーム自体を検出し、実行可能ファイルを PATH に配置します。インストール後、すべてが所定の位置にあることを確認する必要があります。

    opencode --version
    

    コマンドでバージョンが表示されれば、インストールは成功しています。

    他の方法を使用したインストール

    パッケージ マネージャーを使用したい場合は、いくつかのオプションがあります。 Node.js経由:

    npm install -g opencode-ai
    

    Bun、pnpm、Yarn でも同じことができます。

    bun install -g opencode-ai
    pnpm install -g opencode-ai
    yarn global add opencode-ai
    

    macOS と Linux には Homebrew があります。注意してください: これは開発者からの提案であり、公式の公式ではなく推奨されています。更新頻度は低くなります。

    brew install anomalyco/tap/opencode
    

    Arch Linux の場合:

    sudo pacman -S opencode
    paru -S opencode-bin
    

    最初のコマンドはリポジトリから安定バージョンをインストールし、2 番目のコマンドは AUR から最新バージョンをインストールします。

    Windows へのインストール

    Windows では、WSL を介して作業することをお勧めします。これにより、パフォーマンスが向上し、エージェントの機能との互換性が完全になります。ただし、ネイティブメソッドもあります。 Chocolatey、Scoop、または npm 経由:

    choco install opencode
    scoop install opencode
    npm install -g opencode-ai
    

    Docker コンテナーだけでなく、Mise を介したオプションもあります。

    mise use -g github:anomalyco/opencode
    docker run -it --rm ghcr.io/anomalyco/opencode
    

    最後に、完成したバイナリは、GitHub のリリース ページからいつでも取得できます。

    ディープシーク キー

    キーは DeepSeek 個人アカウントで作成されます。 platform.deepseek.com に移動し、API キーのセクションを開き、[新しいキーの作成] をクリックします。結果の文字列はすぐに保存することをお勧めします。表示されるのは 1 回だけです。

    ディープシーク接続

    その後、すべてがエージェント自体の内部で行われます。ターミナルで OpenCode を起動します。

    opencode
    

    インターフェイスで接続コマンドを実行します。

    /connect
    

    開いたプロバイダーのリストで DeepSeek を探し、選択して API キーを挿入します。この方法で追加されたキーはファイルに保存されます。

    ~/.local/share/opencode/auth.json
    

    接続後は、次のコマンドでモデルを選択するだけです。

    /models
    

    deepseek-v4-pro、deepseek-flash、deepseek-v4-flash などの DeepSeek モデルがリストで利用可能になります。リポジトリでの日常的な作業には、フラッシュ オプションで十分です。複雑なタスクの場合は、プロに切り替えるのが合理的です。

    config による設定

    マスターを介してキーを保存したくない場合、または独自の API アドレスを設定する必要がある場合は、プロバイダーは opencode.json 構成ファイルに直接記述されます。

    {
      "$schema": "https://opencode.ai/config.json",
      "provider": {
        "deepseek": {
          "options": {
            "baseURL": "https://api.deepseek.com"
          }
        }
      }
    }
    

    baseURL フィールドは、プロキシまたは独自のゲートウェイを経由する場合に便利です。この場合、キー自体を環境変数に転送すると便利です。

    export DEEPSEEK_API_KEY=ваш_ключ_deepseek
    opencode
    

    このオプションは CI および 1 回限りの起動に適しています。キーは最終的にストレージに保存されず、プロセスの環境内にのみ存在します。

    プロジェクトでの最初の起動

    プロジェクト ディレクトリに移動し、エージェントを起動します。

    cd ваш_проект
    opencode
    

    最初のステップはそれを初期化することです。

    /init
    

    OpenCode はプロジェクト構造を分析し、エージェントへの指示に相当するファイル AGENTS.md を作成します。このファイルは git にコミットする価値があります。エージェントがプロジェクトで採用されている規則とパターンを理解するのに役立ちます。

    使用方法

    この作業は他のエージェントとほぼ同じように構成されています。今すぐ知っておくべきいくつかのトリック:

    • 計画モード。 Tab キーは、エージェントを計画モードと組み立てモードの間で切り替えます。最初の例では、問題の解決方法を提案するだけで、何も変更しません。変更を加える前にアイデアを確認すると便利です。
    • ファイルへのリンク。 @ キーを使用すると、プロジェクト ファイルのあいまい検索が開き、コンテキスト内のエージェントに特定のファイルが転送されます。
    • 変更のロールバック。 /undo コマンドは最後の編集を取り消して元のリクエストを返し、/redo コマンドはそれらを返します。複数のステップを連続してロールバックできます。
    • 会話の共有。 /share コマンドは、現在の会話へのリンクを作成し、クリップボードにコピーします。デフォルトでは、会話はどこにも公開されません。

    単純な変更の場合は、計画モードに切り替える必要はなく、すぐに何を行う必要があるかを記述し、@ でファイルを指定します。

    注意すべきこと

    実践的なポイントをいくつか紹介します。 OpenCode はサブスクリプションを必要としません。トークンを使用するときにプロバイダーに直接料金を支払うため、DeepSeek での長時間セッションは上位モデルよりも予想通り安価です。キーはローカルの auth.json に保存されます。これは共有マシン上で検討する価値がありますが、他の人の環境では環境変数の方が信頼性が高くなります。

    そしてもう 1 つ、複雑なアーキテクチャ上の問題に対する答えの質は、異なるクラスのモデル間で異なるため、設計では、より強力なモデルを採用し、ルーチンを迅速で安価なモデルに譲るのが理にかなっています。

    リンク

    https://opencode.ai/
    https://opencode.ai/docs/
    https://opencode.ai/docs/providers/
    https://github.com/anomalyco/opencode
    https://platform.deepseek.com/api_keys
    https://api-docs.deepseek.com

    ソース

    https://opencode.ai/docs/
    https://opencode.ai/docs/providers/#deepseek
    https://github.com/anomalyco/opencode/releases
    https://models.dev/

  • M2プロセッサを搭載したMacBookにAsahi Linuxをインストールする

    Apple Silicon プロセッサを搭載した Mac では、通常の方法で Linux をインストールすることはできません。フラッシュ ドライブからの起動は不可能であり、ブートローダーは Apple によって署名されています。 ASAHI Linux プロジェクトはこれを回避することに取り組みました。参加者はリバース エンジニアリングを使用して、M1 および M2 ハードウェアを通常の Linux で動作できるようにしました。現在、このプロジェクトの主力ディストリビューションは Fedora Asahi Remix であり、M2 上で非常に確実に動作します。この記事では、インストールをステップごとに説明します。

    Asahi Linux とは

    このプロジェクトは 2020 年に始まり、Apple が独自のチップに切り替え、それに伴いクローズド ブート スキームが導入されました。つまり、デバイスは Apple が署名したコードのみを実行します。 ASAHI Linux の参加者は、m1n1 ブートローダーを作成し、その上に U-Boot と UEFI 環境を作成しました。次に、最も一般的な ARM64 システムがロードされますが、linux-asahi カーネルがロードされ、非標準の Apple ハードウェア (GPU、ビデオ、サウンド、カメラ ユニット) 用のドライバーが追加されます。

    実際には、次のようになります。macOS からインストーラーを実行すると、ディスクがパーティション分割され、ブート チェーンとシステムがインストールされます。 macOS はそのまま残り、デュアル ブートが可能になり、電源を入れるときにシステムを選択できます。

    要件

    • M2 チップを搭載した Mac – MacBook Air、MacBook Pro 13 インチ、M2 Pro および M2 Max を搭載した 14 インチと 16 インチ。 M1 車もサポートされています。
    • 現在の macOS。 インストーラーにはシステムの最新バージョンが必要なので、開始する前に更新してください。
    • 空き容量。 最小約 30 GB、快適であれば 100 GB 以上。このスペースは APFS コンテナから切り離され、自然に戻ることはありません。
    • macOS 管理者パスワード。 パーティション分割時と初めてリカバリ モードで起動する際の両方で必要になります。
    • バックアップ。 ディスクのパーティショニングは、新しいバックアップから始めるのが最適な操作です。

    ステップ 1. バックアップとアップデート

    Time Machine またはその他の方法でコピーを作成します。 macOS を利用可能な最新バージョンに更新し、再起動します。 FileVault が有効な場合、リカバリ モードでの起動段階でもそのパスワードが必要になります。インストーラーはドライブのロックを解除する必要があります。

    ステップ 2. インストーラーを起動します

    macOS でターミナルを開き、次のコマンドを 1 つ実行します。

    curl https://alx.sh | sh
    

    これはプロジェクトの公式インストーラーです。自動的にダウンロードされ、Mac のモデルが確認され、ディストリビューションの選択が求められます。 Fedora 用に直接オプションもあります。

    curl https://fedora-asahi-remix.org/install | sh
    

    最初のオプションが推奨されます。これは、現在利用可能なシステムを示し、デスクトップの選択肢も提供します。

    ステップ 3. ディスクのパーティション

    インストーラーは管理者パスワードを要求し、現在のレイアウトを表示します。するとダイアログは次のようになります。

    • r を押して macOS パーティションのサイズを変更します。
    • 新しい Linux パーティションのサイズを入力します。ギガバイト単位で指定することも、ディスクのパーセンテージで指定することも、分 と記述することもできます。その場合、可能な限り最小の部分が切り取られます。
    • 文字 y でマークを確認します。このステップは最も時間がかかります。システムはデータを APFS コンテナに物理的に移動します。大きなディスクでは、これには数分かかります。
    • f を押して、インストーラーが新しく作成された空きパーティションを指すようにします。

    何が起こっているのかを理解することが重要です。Linux は APFS 内ではなく、その隣の別のパーティションにインストールされています。これが、macOS が変更されずに残され、ロールバックがこのセクションの削除に短縮される理由です。

    ステップ 4. ディストリビューションとデスクトップの選択

    次に、インストーラーはシステムとデスクトップ環境を提供します。 Fedora Asahi Remix にはデフォルトで KDE Plasma が付属しています。これは最初にアップデートを受け取る主力オプションです。代替手段として GNOME があります。これは macOS に近い操作性を持っています。グラフィカル環境が必要ない場合には、最小限の画像もあります。

    ステップ 5. 最初にリカバリ モードで起動します

    パーティション分割後、インストーラーにより続行を求めるメッセージが表示され、Mac がシャットダウンされます。最も珍しい部分は次のとおりです。

    • 少なくとも 25 秒待ちます。これは、リカバリ モードに入る Apple の要件です。
    • 起動オプションが表示されるまで電源ボタンを押し続けます。
    • インストール ボリュームを選択し、macOS パスワードを入力します。

    このステップでは、ブート チェーンがサービス パーティション (m1n1、U-Boot、および UEFI 環境) にインストールされます。その後、マシンが再び再起動します。電源ボタンを再度押したままにして、新しいボリュームを選択し、今度はシステムにアクセスします。このような再起動は数回行われ、それぞれ手動で選択する必要があります。デフォルトでは、Mac は macOS をロードし続けます。

    ステップ 6. システムのインストール

    次に、システム名、ユーザー、パスワード、タイムゾーン、キーボードレイアウトの初期セットアップウィザードが開始されます。この後、インストール自体が開始され、すでにインターネットから来ています – 安定した接続が必要で、最終的には15分から30分かかります。

    インストールが完了したら、再起動し、ブート メニューから Linux を選択します。初めてログインすると、セットアップとアップデートを完了するように求めるメッセージが表示されます。

    何が機能し、何が機能しない

    インストールする前に、何が失われるかを冷静に評価する必要があります。 M2 ラップトップでは、状況は次のとおりです。

    作品:

    • Wi-Fi と Bluetooth – 制限なし
    • 統合された画面とグラフィックス – OpenGL や Vulkan などのハードウェア アクセラレーション
    • MacBook Air および MacBook Pro のウェブカメラ、マイク、スピーカー
    • スリープ モード – 正常に動作します。
    • ハードウェア ビデオ デコード – プレーヤーはプロセッサをロードしません。
    • USB ポート(Thunderbolt コネクタ経由の USB 2 および USB 3 を含む)

    動作しない、または部分的に動作する:

    • Touch ID。 指紋認証は Linux では使用できません – パスワードを使用してログインします。
    • Thunderbolt (USB4)。 ステータス – 開発中。残念ながら、特に Thunderbolt を必要とするデバイスは動作しません。
    • USB-C 経由の外部モニター。 DisplayPort Alt Mode も動作中です。 M2 ラップトップには HDMI ポートがないため、外部スクリーンを接続できません。 M2 Pro および M2 Max を搭載したモデルには HDMI があり、動作します。 USB-C の回避策は、以下の Fairydust コア セクションに記載されています。
    • ハードウェア ビデオ エンコードは計画にあり、デコードはすでに実施されています。

    簡単に言うと、コード、ターミナル、ブラウザ、ローカル モデルを操作する場合には優れたシステムですが、外部モニター ドックには適していません。

    フェアリーダスト コア経由の外部モニター

    USB-C イメージ出力は、Asahi Linux チームの実験的な Fairydust カーネル ブランチで利用できます。手動で組み立てると時間がかかるため、asahi-fairydust-display プロジェクトのラッパー スクリプトを使用する方が簡単です。

    git clone https://github.com/bharambetejas/asahi-fairydust-display
    cd asahi-fairydust-display
    chmod +x asahi-fairydust-build.sh
    ./asahi-fairydust-build.sh
    

    スクリプトは、fairydust ブランチのクローンを作成し、カーネルを構成してアセンブルし、それを標準のブランチの隣に配置して、GRUB を編集します。 15 GB の空き容量、USB-C → HDMI または DisplayPort アダプターが必要で、組み立てには 60 ~ 90 分かかります。再起動後、GRUB で -fairydust というラベルの付いたカーネルを選択し、アダプタを最前面の USB-C ポートに挿入します。

    ダウンロード後に確認してください:

    uname -r
    glxinfo | grep "OpenGL renderer"
    xrandr
    

    最初のコマンドは接尾辞 -fairydust の付いたバージョンを表示し、2 番目のコマンドは llvmpipe ではなく Apple M2 を表示し、3 番目のコマンドは接続された DP-1 出力を表示する必要があります。

    予約。このブランチは実験的なものであり、正式にはサポートされていません。出力は 1 つの USB-C ポート経由でのみ機能し、ホットプラグに常に耐えられるわけではありません。アダプターを既に挿入した状態で再起動する方が安全です。スクリプトは表示を自動的に構成しません。Wayland でログイン ループが発生したため、スクリプト内の対応するステップは無効になります。 dnf 経由でストック カーネルを更新すると、/boot/dtb シンボリック リンクが再配置されるため、出力が静かに動作を停止する可能性があり、その場合はビルドを繰り返す必要があります。

    標準カーネルには触れません。戻るには、GRUB メニューで選択するだけです。

    アップグレードの代わりに外付けドライブ

    ここが良い面です。 MacBook はアップグレードできません。メモリとストレージはボードにはんだ付けされており、それらの容量は購入時に一度選択されます。 macOS では、外付けドライブは外付けのままです。システムやアプリケーションをそこに実際に転送することはできません。

    Linux では、この制限がなくなりました。USB 経由の外付け SSD は通常のブロック デバイスであり、/etc/fstab 経由で任意のマウント ポイントを転送できます。ホーム ディレクトリ、Steam ライブラリ、仮想マシン イメージ、またはローカル モデルを転送したい場合は、そうしてください。まさにこの車にはないアップグレードが判明しました。

    こんな感じです。まず、目的のパーティションの UUID を確認します。

    lsblk -f
    sudo blkid
    

    次に、/etc/fstab に次の行を追加します。

    UUID=ваш-uuid  /home  ext4  defaults,nofail  0  2
    

    転送自体はコピーによって行われます。データは外部ドライブに移動され、その後、目的の場所にマウントされます。多くの場合、この方法では /home 全体が削除されるのではなく、個々の重いディレクトリが削除されます。この方法の方がリスクは少なくなります。

    いくつかの注意点があります。 nofail パラメータはオプションで設定する価値があります。パラメータがないと、ディスクが接続されていないとシステムは起動しません。 USB ドライブの速度は内蔵 NVMe よりもまだ遅いため、頻繁な I/O 操作のために内部ディスクにスペースを残しておくことをお勧めします。また、ディレクトリがマウントされている状態で移動中にディスクを取り出す必要はありません。まずディスクをアンマウントしてください。

    システムを切り替える方法

    電源を入れたら、電源ボタンを押し続けます。ブート メニューが表示され、macOS と Linux が含まれています。 macOS のデフォルトのシステムは、「システム環境設定」→「一般」→「システムディスク」から選択できます。 Linux にも対応する設定があるため、ターミナルを使用せずに双方向に切り替えることができます。

    リンク

    https://asahilinux.org/fedora/
    https://asahilinux.org/docs/
    https://asahilinux.org/docs/platform/feature-support/m2/
    https://fedoraproject.org/asahi-remix
    https://github.com/bharambetejas/asahi-fairydust-display
    https://github.com/AsahiLinux/linux/tree/fairydust

    ソース

    https://asahilinux.org/docs/platform/feature-support/m2/
    https://discussion.fedoraproject.org/t/fedora-asahi-remix-installation-guide/
    https://github.com/AsahiLinux/docs
    https://github.com/bharambetejas/asahi-fairydust-display/blob/main/README.md
    https://github.com/bharambetejas/asahi-fairydust-display/blob/main/asahi-fairydust-build.sh

  • ゲスト追加機能を備えた VirtualBox を ARM Mac にインストールする

    ARM64 プロセッサを搭載した Mac 上の VirtualBox に Ubuntu Server をインストールし、Guest Additions を接続する手順。

    VirtualBox のインストール

    VirtualBox の ARM64 ビルドをダウンロードし、イメージをマウントして、VirtualBox.app をアプリケーションに転送します。

    仮想マシンの構成

    新しいマシンを作成し、Linux の種類と Ubuntu のバージョン (64 ビット ARM) を指定します。設定では次のように設定します。

    • TPM – 無効にする
    • UEFI – 無効にする
    • RAM – 4096 MB。
    • グラフィック コントローラー – VMSVGA (VBoxLinuxAdditions 用)。
    • プロセッサ – 4 コア。

    Ubuntu サーバーのインストール

    ARM64 の Ubuntu Server ISO イメージを CD-ROM ドライブにマウントします。ダウンロードセクションで、光学式ドライブをリストの最初に入れます。マシンを起動し、Ubuntu Server のインストールを実行します。

    xubuntu-desktop のインストール

    XFCE グラフィカル環境をインストールします。

    sudo apt update
    sudo apt install -y xubuntu-desktop
    

    ログインマネージャーの選択ダイアログで、lightdmを選択します。

    ゲスト システムを再起動します。

    sudo reboot
    

    ゲストの追加

    最初の起動後、カーネル モジュールを構築するためのパッケージをインストールします。

    sudo apt update
    sudo apt install -y build-essential linux-headers-$(uname -r)
    

    VirtualBox メニューから [デバイス] → [ゲスト追加ディスク イメージのマウント] を選択して、ゲスト追加機能を含むディスクをマウントします。ディスクはゲスト内の /media/$USER ディレクトリに表示されます。

    Xubuntu でターミナルを開き、マウントされたディスクのディレクトリに移動してインストーラーを実行します。

    cd /media/$USER/*
    sudo ./VBoxLinuxAdditions-arm64.run
    

    ゲスト システムを再起動します。

    sudo reboot
    

    インストール後に機能するもの

    カーネル モジュールがロードされていることを確認します。

    lsmod | grep vbox
    

    出力には vboxguest と vboxsf が含まれている必要があります。

    マシンのプロパティに共有フォルダーを追加し、ゲスト内にマウントします。

    sudo mkdir -p /media/sf_shared
    sudo mount -t vboxsf shared /media/sf_shared
    

    動作機能:

    • 共有フォルダ – ホスト ディレクトリは vboxsf 経由でゲスト内に表示されます。
    • 共有クリップボード – ホストとゲストの間でテキストをコピーします。
    • マウスの統合 – カーソルはマシン ウィンドウの外に自由に広がります。
    • 自動解像度変更 – ゲスト画面はウィンドウ サイズに合わせて調整されます。
    • 時刻同期 – ゲストの時刻がホストの時刻に合わせて調整されます。

    ソース

    https://www.virtualbox.org/manual/topics/guestadditions.html
    https://forums.virtualbox.org/viewtopic.php?t=112886

  • DeepSeek を Claude Code に接続する方法

    Claude Code は Anthropic のコンソール エージェントで、プロジェクト ファイルの読み取り、コードの編集、コマンドとテストの実行、リポジトリの検索、git の操作を行うことができます。これを使用する際の主な不便な点はコストです。多くのコンテキストを含む長いセッションはすぐにサブスクリプション予算を使い果たしてしまいます。

    解決策はあります。 DeepSeek は、Anthropic API と互換性のあるエンドポイントを提供します。ベース アドレスとトークンを変更するだけで十分です。再インストールやパッチを必要とせずに、Claude Code が DeepSeek モデルで動作し始めます。この記事では、macOS、Linux、Windows でこれを設定する方法を説明します。

    これが必要な理由

    理由は異なる場合があります。
    – 価格。 DeepSeek モデルは Claude よりも著しく安価であり、プロジェクトのナビゲート、軽微な編集、テストの実行などの日常的なエージェントのタスクでは、常に最高の品質が必要なわけではありません。
    – 利用可能性。 サブスクリプションを持っていない場合、または何らかの理由で Anthropic カードでの支払いが利用できない場合は、DeepSeek が有効なオプションになります。
    – 実験。 異なるモデルが同じ環境で同じコードベースをどのように処理するかを比較するのは興味深いです。

    必要なもの

    Claude Code のインストールと DeepSeek API キーが必要です。 Claude Code がまだインストールされていない場合、順序は次のとおりです。
    1. Node.js 18 以降をインストールします。 Windows では、さらに Git for Windows が必要になります。
    2. 以下のコマンドを使用してClaude Code本体をインストールします。
    3. インストールを確認します。

    npm install -g @anthropic-ai/claude-code
    claude --version
    

    バージョンが表示されれば、インストールは成功しています。 API キーは、キー ページの DeepSeek 個人アカウントに作成されます。

    環境変数による設定

    すべての統合は環境変数によって決まります。 macOS と Linux の場合は次のようになります。

    export ANTHROPIC_BASE_URL=https://api.deepseek.com/anthropic
    export ANTHROPIC_AUTH_TOKEN=ваш_ключ_deepseek
    
    export ANTHROPIC_MODEL=deepseek-flash[1m]
    export ANTHROPIC_DEFAULT_OPUS_MODEL=deepseek-flash[1m]
    export ANTHROPIC_DEFAULT_SONNET_MODEL=deepseek-flash[1m]
    export ANTHROPIC_DEFAULT_HAIKU_MODEL=deepseek-flash
    export CLAUDE_CODE_SUBAGENT_MODEL=deepseek-flash
    
    export CLAUDE_CODE_EFFORT_LEVEL=max
    export CLAUDE_CODE_AUTO_COMPACT_WINDOW=786432
    

    Windows の PowerShell の場合、構文は異なりますが、変数名は同じです。

    $env:ANTHROPIC_BASE_URL="https://api.deepseek.com/anthropic"
    $env:ANTHROPIC_AUTH_TOKEN="ваш_ключ_deepseek"
    $env:ANTHROPIC_MODEL="deepseek-flash[1m]"
    

    ここで何が何であるかを理解しましょう。 「ANTHROPIC_BASE_URL」変数は、リクエストを Anthropic サーバーから DeepSeek にリダイレクトします。 `ANTHROPIC_AUTH_TOKEN` がキーの代わりになります。残りの変数は、どのモデルがどの役割で使用されるかを決定します。 `[1m]` 接尾辞が付いたモデルがあります。これは、約 100 万トークンのコンテキスト ウィンドウを備えたオプションであり、エージェントが一度に大幅に多くのプロジェクト ファイルを保持できるようになります。したがって、自動履歴圧縮があまりにも早く機能しないように、`CLAUDE_CODE_AUTO_COMPACT_WINDOW` はこのウィンドウのサイズに設定されます。

    変数を毎回手動でエクスポートするのではなく、クロードコードの設定に登録しておくと便利です。その後、設定は起動時に自動的に取得されます。

    {
      "env": {
        "ANTHROPIC_BASE_URL": "https://api.deepseek.com/anthropic",
        "ANTHROPIC_AUTH_TOKEN": "ваш_ключ_deepseek",
        "ANTHROPIC_MODEL": "deepseek-flash[1m]",
        "ANTHROPIC_DEFAULT_HAIKU_MODEL": "deepseek-flash",
        "CLAUDE_CODE_SUBAGENT_MODEL": "deepseek-flash"
      }
    }
    

    その後、プロジェクト ディレクトリに移動し、エージェントを実行します。

    cd ваш_проект
    claude
    

    VS Code のクロード コード

    Claude Code はターミナル内だけでなく、VS Code の拡張機能としても利用できます。これは通常の方法でインストールされます。Cmd+Shift+X を使用して拡張パネルを開き、「Claude Code」を見つけて「インストール」をクリックします。この拡張は Anthropic 自体によって行われます。

    拡張機能には CLI の独自のコピーが含まれており、ターミナル バージョンと同じ ~/.claude/settings.json ファイルを読み取ります。前のセクションの設定もここに適用されますが、ほとんどの場合混乱を引き起こすため、1 つ注意点があります。

    起動前に入力検証が行われます

    開始する前に、拡張機能は settings.json ではなく、独自の `claudeCode.environmentVariables` 設定から認証情報をチェックします。 settings.json の値は実行中のプロセスに到達します。つまり、API アドレスと選択されたモデルは正しく取得されますが、拡張機能自体のログイン チェックには合格しません。ターミナルですべてがすでに動作しているにもかかわらず、ログイン画面が表示される場合は、これが原因です。

    これは、VS Code 設定の数行で解決できます。`claudeCode.environmentVariables` 内の変数を複製し、ログイン要求を無効にします。

    {
      "claudeCode.environmentVariables": [
        { "name": "ANTHROPIC_BASE_URL", "value": "https://api.deepseek.com/anthropic" },
        { "name": "ANTHROPIC_AUTH_TOKEN", "value": "ваш_ключ_deepseek" },
        { "name": "ANTHROPIC_MODEL", "value": "deepseek-flash[1m]" }
      ],
      "claudeCode.disableLoginPrompt": true
    }
    

    macOS のニュアンス

    Dock または Finder から VS Code を起動する場合、~/.zshrc から環境変数を継承しません。これは macOS の標準的な動作であり、クロード コードのドキュメントで詳しく説明されています。つまり、拡張機能のシェルで「export ANTHROPIC_BASE_URL=…」を実行しても機能しません。この変数はその環境に存在しません。

    ここから得られる結論は 2 つあります。まず、`claudeCode.environmentVariables` の設定はシェル変数よりも信頼性が高くなります。次に、それでもシェルを使用したい場合は、変数がすでにエクスポートされているターミナルからエディターを起動します。

    code .
    

    うまくいかないこと

    サードパーティプロバイダーでは、claude.ai アカウントが必要なため、一部の拡張機能は利用できません。
    – クラウド セッションにはプラン使用量バー、音声入力、Web タブはありません。
    – ログアウト コマンドはメニューに表示されません。
    – `/usage` には、プランの制限ではなく、現在のセッションのトークンの消費量と数が表示されます。
    – ベース アドレスが Anthropic でない場合、リモート コントロールは機能しません。

    これは予期された動作であり、セットアップが失敗したことを示すものではありません。

    これとは別に、JetBrains には独自のプラグインがあることを付け加えておきますが、その設計は異なります。組み込みの CLI は含まれておらず、統合ターミナルにすでにインストールされているものを起動します。環境変数の設定はないため、エクスポート済みの変数を使用してターミナルから IDE を起動する必要があります。

    DeepSeek がクロード モデル名を理解する方法

    Claude Code は内部的にモデルを claude-opus、claude-sonnet、claude-haiku などの名前で参照します。 DeepSeek はこれらの名前をインターセプトし、独自の名前に置き換えます。
    – claude-opus で始まるものはすべて deepseek-v4-pro になります。
    – claude-sonnet または claude-haiku で始まるものはすべて deepseek-flash に送られます。
    – 不明なモデル名もディープシークフラッシュに短縮されます。

    これは、モデルを明示的に指定しなくても統合は機能しますが、どのモデルとどの料金でリクエストに応えるかを明示的に制御する方が良いことを意味します。そのため、上記の設定ではすべてのロールが手動で書き込まれます。

    注意すべきこと

    互換性は不完全なので、事前に知っておく必要があります。 DeepSeek は、Anthropic API の一部の機能を単純に無視します。

    – プロンプトのキャッシュ。 「cache_control」フィールドはサポートされていません。 Claude Code は、同じコンテキストを繰り返し送信することで過剰な料金が発生しないように、キャッシュを積極的に使用します。ここではこのようなことは起こらないため、長時間のセッションはトークンあたりの価格から予想されるよりも高価になります。古い対話を際限なく続けるのではなく、定期的に新しい対話を開始します。
    – 思考予算。 ` Thinking` パラメータはサポートされていますが、その中の `budget_tokens` は無視されます。
    – その他。 「top_k」、「service_tier」、「container」フィールド、および API からの MCP サーバーの接続も無視されます。
    – MCP。 エージェントの通常のツール (ファイルの読み取り、編集、コマンドの実行、検索) は正常に機能しますが、DeepSeek 側の組み込み MCP サーバー メカニズムは機能しません。

    これとは別に、プロキシについても言及する価値があります。コミュニティには「ds-cc-proxy」のようなプロジェクトがあり、Claude Code と DeepSeek の間に配置され、軽微な非互換性を解消し、メイン セッションとサブエージェントを異なるモデルに分離するタスクを引き受けます。標準設定の動作が不安定な場合は、このような中間層が役に立ちます。

    クロード コード ルーター

    上記の方法では、すべてのタスクに 1 つのモデルを配置します。しかし、エージェントはまったく異なることを行います。プロジェクトの構造を理解し、小さな点を修正し、時には本当に複雑な問題を解決します。作業の種類ごとに異なるモデルを使用するのは論理的です。これはまさに、クロード コード ルーター (CCR)、つまりクロード コードとモデル プロバイダーの間に立つローカル ゲートウェイが実行できることです。

    それは何をもたらしますか

    – ルールによるルーティング。 どのモデルがメイン セッションを担当するか、どのモデルがバックグラウンド タスクを担当するか、どのモデルがスケジュール モードを担当するかを設定できます。複雑な推論にのみ高価なモデルを使用し、ルーチンを安価なモデルに譲るのは理にかなっています。
    – バックアップ オプション。 プロバイダーがエラーを返した場合、リクエストはセッションをドロップせずに、チェーン内の次のモデルに送信されます。
    – 可観測性。 インターフェイスには、リクエスト ログ、遅延、トークン消費量、コストが表示されます。これらは、直接接続した場合のみ推測できます。
    – 複数のエージェントに 1 つのアドレス。 プロバイダー、キー、ルールは 1 か所に存在し、クライアントは 1 つのローカル アドレスに接続します。

    まずバージョンについて – これは重要です

    時間を節約できるので、ここで警告する価値があります。 CCR はその歴史の中で大幅に再設計されており、 検索で見つかる記事のほとんどが古い バージョンについて説明しています。

    古いバージョンでは、構成は Providers ブロックと Router ブロックを含むファイル ~/.claude-code-router/config.json にあり、すべては `ccr code` コマンドで起動されました。今はもうそのようには機能しません。現在のバージョン (3.x) は、設定を SQLite データベースに保存し、Web インターフェイス経由で管理します。データベースがまだない場合、古い config.json は移行ソースとして一度だけ読み込まれます。その後、編集しても何も影響しません。

    つまり、インターネットで config.json と「ccr code」コマンドを編集する手順を見つけても何も機能しなかった場合は、もう誰も読まないファイルを編集していることになります。それはあなたのせいではありません。

    インストール

    Node.js 22 以降が必要です。

    npm install -g @musistudio/claude-code-router
    ccr ui
    

    「ccr ui」コマンドは、バックグラウンドでサービスを起動し、ブラウザで管理インターフェイスを開きます。他のコマンドについても知っておくと便利です。`ccr start` はサービスを開始し、`ccr stop` はサービスを停止します。`ccrserve` はフォアグラウンドで動作し、ログを表示する必要がある場合に便利です。

    デフォルトでは、管理インターフェイスはポート 3458 に存在し、モデルのゲートウェイ自体はポート 3456 に存在します。

    設定

    ファイルを手動で編集することなく、すべてが Web インターフェイスで行われます。
    1. 「プロバイダー」セクションで、DeepSeek プロバイダーを追加し、そのキーを指定します。注意: ここではドメインだけでなく、チャット/完了ポイントまでの完全なアドレスが必要です。
    2. [モデル] セクションで、このモデルが何であるかを説明します。説明はルーティングに役立ちます。
    3. 「エージェント構成」セクションで、デフォルトのモデルを設定します。
    4. [ルーティング] セクションで、どのモデルがどのリクエストに応答するかというルールを設定します。
    5. [API キー] ページで、CCR クライアント キーを作成します。これは、DeepSeek キーではなく、Claude Code が使用するものです。

    この後は、クロード コードをゲートウェイに送信するだけです。インターフェイスに表示されるゲートウェイ アドレスをベース アドレスとして指定し、CCR クライアント キーをトークンとして指定します。

    良い点: ルーティング ルールは、フィールドだけでなく、ロジックが 1 つのフィールドを比較するよりも複雑な場合は、JavaScript スクリプトでも作成できます。

    使用する価値はありますか

    DeepSeek を Claude Code に接続することは、主に、便利なエージェント環境を犠牲にすることなくコストを削減する方法です。同じインターフェイス、同じツール、同じワークフローが得られますが、モデルは異なります。セットアップには数分かかりますが、完全に元に戻すことができます。環境変数を削除するだけで Anthropic モデルに戻ります。

    制限も明らかです。プロンプト キャッシュがなく、API フィールドに関する互換性が不完全で、複雑なアーキテクチャ タスクではモデルの品質が異なる可能性があります。リポジトリでの日常的な作業 (ナビゲーション、リファクタリング、テストの実行) には、これで十分です。

    例: Oni-Extended

    このような組み合わせの生きた例は、ゲーム Oni (Bungie、2001) の Apple Silicon への移植である私のプロジェクト Oni-Extended です。ゲームのソースは C で書かれており、20 年以上前から存在しています。テストは一度も行われておらず、ファイル サイズは数万行単位で測定されます。ただし、DeepSeek の Claude Code を介してプロジェクトに新機能が追加されました。F5/F9 による高速保存とロード、キーホールド ブロック、およびダメージを無効にする -nodamage 起動フラグです。

    これは上で述べたことをよく表したものです。すべてのタスクは、大規模なリポジトリでの日常的な作業に関連しています。エージェントは、アーキテクチャをゼロから設計するのではなく、他の人のコードを調べ、モジュール間の接続を見つけて仮説をテストします。 DeepSeek でのそのようなセッションのコストは、結果がプロジェクト独自のインフラストラクチャ (組み立て、水平実行スタンド、オフライン テスト) によって検証されているにもかかわらず、Anthropic モデルよりも著しく低いことが判明しました。

    リンク

    https://platform.deepseek.com/api_keys
    https://api-docs.deepseek.com
    https://docs.anthropic.com/en/docs/claude-code
    https://github.com/anthropics/claude-code
    https://github.com/musistudio/claude-code-router
    https://ccrdesk.top/en/guides/cli/
    https://github.com/zefir1990/Oni-Extended

    ソース

    https://api-docs.deepseek.com/guides/anthropic_api
    https://api-docs.deepseek.com/quick_start/agent_integrations/claude_code
    https://ccrdesk.top/en/routing/
    https://code.claude.com/docs/en/vs-code

  • maimat: 画像の一括圧縮とサイズ変更

    maimat (Mass Images Manipulation Tool) は、バッチ画像処理 (サイズ変更と圧縮) のために設計されたオープンソース ツールです。このアプリケーションは Python 3.10 以降で書かれており、処理エンジンとして ImageMagick を使用します。

    リンク

    https://github.com/zefir1990/maimat

  • Donki Hills は 1 年以上にわたって Steam に正式に登場しました!

    Donki Hills は 1 年以上にわたって Steam に登場しています。

    ちょうど 1 年前にこのプロジェクトが Steam ページに登場し、それ以来、ゲームは大きな進歩を遂げてきました。この間、ドンキヒルズがどのような方向に発展すべきかについて、多くの実験、変更、模索が行われました。

    ゲームプレイの作業は継続しており、現在、プロジェクトは徐々にその本当の姿を獲得しつつあります。ドンキ ヒルズは、コメディの一人称ローグライク パロディ サバイバル ホラーという本来の姿に変わり始めています。

    ホラーとユーモア、探検、そして予期せぬ状況が出会う奇妙な冒険。あなたは街に行き、物を探し、謎を解き、マリアにつながる秘密を徐々に明らかにしなければなりません。

    以下は、プロトタイプの次のプレイテストからの新しいスクリーンショットです。これはまだゲームの最終的な外観ではありませんが、街の雰囲気とプロジェクトが進んでいる方向性をすでに感じることができます。

    あなたの反応をとても楽しみにしています! 👀
    新しい方向性はどうですか?ゲームの雰囲気やアイデアについてはどのような印象をお持ちですか?

    ドンキヒルズをウィッシュリストに追加し、開発をフォローし、プロジェクトをサポートしてくださった皆様に感謝します❤️

    まだまだたくさんの実験、新しい仕組み、そして奇妙な冒険が待っています。

    https://store.steampowered.com/app/3476390/Donki_Hills/

  • ゲーム用ラップトッププロセッサのスロットリングをバイパスする

    最新のゲーム用ラップトップのメーカーは、プロセッサが負荷時に最大 90 度、さらには 100 度に達するようにシステムを構成していることがよくあります。この問題は、要求の厳しいゲームや重い作業を実行する夏に特に深刻です。

    極度の加熱により、スロットルが有効になり (物理的な損傷を防ぐためにプロセッサ周波数をリセットします)、パフォーマンスの急激な低下、フリーズ、FPS の低下につながります。過熱に対処する方法 (冷却パッドの使用から電圧低下まで) は数多くありますが、この記事では、Windows 11 以前のバージョンのオペレーティング システムに関連する最も簡単で最速の方法について説明します。

    この方法は、電源設定を通じてプロセッサの最大状態を制限することです。

    1. Windows 検索またはコントロール パネルから電源オプションを開きます。
    2. アクティブな電源プランで、追加パラメータを変更するセクションに移動します。
    3. プロセッサ電源管理 ブランチを見つけます。
    4. [最大プロセッサ状態] オプションを展開します。
    5.プラグインの値を 100% から 80% 以下に変更します。

    これらの設定を適用すると、プロセッサーは過剰な熱を発生させる極端な周波数まで自動的にオーバークロックしなくなります。最大ピークパフォーマンスは約 20% 低下しますが、プロセッサーが過熱することはなくなります。スロットリングを行わずに周波数を下げて安定した動作を行うことは、100 度未満の温度での過熱によるパフォーマンスの急激な急上昇よりもはるかに優れており、システムにとって快適です。

    ラップトップはそれぞれ固有であるため、ユーザーは実験して、過熱することなく望ましいパフォーマンスを提供できる最適なバランス (パーセンテージ) を見つけることをお勧めします。

  • Aleka は、Flutter に基づいて構築されたクロスプラットフォームの描画アプリです

    Aleka は、Flutter で書かれた軽量で高速な描画アプリです。ブラウザー、デスクトップ (Windows、macOS、Linux)、モバイル デバイス (iOS、Android) など、どこでも機能します。

    ボンネットの下にはピュアダーツ、マテリアル3と細部へのこだわりが詰まっています。

    チャンス

    • フリーハンド描画: 二次ベジェ補間による滑らかなストローク。
    • 15 色のパレット: 視覚的な表示で簡単に選択できます。
    • ブラシ サイズ: スライダーで 1 ~ 30 ピクセルの範囲で調整できます。
    • 元に戻す: ストロークを元に戻します。
    • ワンクリックでキャンバスをクリアします:
    • フラッド フィル: 滑らかなエッジに対する許容値を備えた BFS。
    • 保存: .aleka 形式(JSON)。
    • 読み込み中: 以前に保存した図面を開いて続行します。
    • PNG エクスポート: キャンバスを 3 倍の解像度でキャプチャします。
    • 🎬 アニメーション モード: タイムラインを使用したフレームごとのアニメーション:
      • それぞれ独自のデザインを持つフレームの追加と削除
      • フレーム期間は 50 ミリ秒から 5 秒までです。
      • FPS を変更します: 6、8、12、15、24、30、または 60。
      • MP4 にエクスポートします (デスクトップでは ffmpeg、ブラウザでは ffmpeg.wasm 経由)。
    • ダークとライトのテーマ: マテリアル 3、システムに従います。

    なぜフラッターするのでしょうか?

    Flutter を使用すると、コードを複製することなく 6 つのプラットフォームに対して 1 つのアプリケーションを作成できます。 Aleka は、Dart および Flutter SDK のネイティブ機能と最小限のサードパーティの依存関係のみを使用します: file_picker、塗りつぶし時にピクセルを操作するための image、ブラウザでビデオをエクスポートするための ffmpeg_wasm。

    アーキテクチャ

    このプロジェクトは、クリーン アーキテクチャとソリッドの原則に準拠しています。

    • PaintCanvasController – リスナー/オブザーバー パターンを通じてストロークと塗りつぶしの状態を制御します。
    • ペイントツールバー – パレット、スライダー、ボタンの UI コンポーネント。
    • AlekaFile – JSON でのシリアル化/逆シリアル化、PNG キャプチャ。
    • MovieController – フレームとアニメーション状態のモデル。
    • VideoExport – MP4 エンコード ロジック (デスクトップ/ウェブ) をカプセル化します。

    I/O 関数 (saveStrokes、loadStrokes、capturePng など) は注入可能になっており、テスト中にモックに置き換えることができます。このプロジェクトには 79 のテストがあります: シリアル化、キャンセル、読み込み/保存、PNG とビデオのエクスポート、フレーム モデルとタイムラインのチェック。

    ファイル形式 .aleka

    .aleka ファイルは、任意のテキスト エディタで開くことができる読み取り可能な JSON です。

      "aleka": "1.0",
      "strokes": [
        {
          "color": 4278190080,
          "strokeWidth": 3.0,
          "points": [[100.0, 200.0], [150.0, 250.0]]
        }
      ]
    }
    

    各ストロークには、色 (ARGB32)、太さ、および点の配列が格納されます。この形式は、aleka フィールドによってバージョン管理されます。

    アニメーション モード

    主な機能の 1 つは、組み込みのフレームごとのアニメーション エディタです。フレームを描画し、新しいフレームを追加し、次のフレームを描画する、ということを繰り返します。タイムラインにはサムネイルが表示され、フレームの順序と長さを変更できます。完成したアニメーションは MP4 にエクスポートできます。

    エクスポート アルゴリズムはすべてのフレームを反復処理し、RepaintBoundary 経由でフレームをキャプチャし、PNG バイトを収集してエンコーダに転送します。デスクトップではシステム ffmpeg と呼ばれ、ブラウザでは ffmpeg.wasm が使用されます。これは、ffmpeg を WebAssembly に完全に移植したもので、ブラウザのサンドボックスで直接動作します。

    塗りつぶし

    塗りつぶしの実装では、色の許容値 (_kFillTolerance = 1000) を持つ幅優先検索 (BFS) を使用します。これにより、ストロークの滑らかなエッジを正しく処理できるようになります。塗りつぶしは輪郭を超えて流れず、境界上の半透明のピクセルをキャプチャします。空のキャンバスの場合、不必要な計算を行わずに塗りつぶしが作成されます。

    試してみる

    Aleka は、Web 上およびネイティブ アプリケーションとして利用できます。

    demensdeum.com/software/aleka/

    ソース コードは MIT ライセンスの下で公開されています。

    github.com/demensdeum/Aleka

  • ママカレンダー – クロスプラットフォームのリマインダーアプリ

    Mama Calendar は、Node.js + MongoDB および PHP + MariaDB という 2 つのバックエンド実装を備えた React Native (Expo) で書かれたクロスプラットフォームのイベントおよびリマインダー アプリケーションです。

    このアプリケーションでは、絵文字を分類してイベントを作成し、繰り返しの種類 (1 回、毎年、毎月、毎週、毎日) を選択し、別の「重要なイベント」タブで今後 3 日間の重要なイベントを表示することができます。

    テクノロジースタック

    フロントエンドは、TypeScript、ナビゲーション用の Expo Router、アニメーション用の react-native-reanimated を使用した Expo SDK 57 を介して React Native 0.86 で作成されています。アイコンにはエキスポシンボルが使用されます(iOSではSFシンボル、Android/Webではマテリアルアイコン)。

    バックエンドは 2 つのバージョンで実装されています。

    • Node.js: Express 4、ネイティブ ドライバー経由の MongoDB 8、scrypt + Salt によるカスタム認証、手動トークン管理。 Docker Compose はクライアント (nginx)、サーバー、MongoDB を起動します。
    • PHP: フレームワークなしの PHP 8.2、PDO + MariaDB 11、パスワード ハッシュ用の bcrypt、独自のルーター、および Composer 経由の PSR-4 自動読み込み。

    アプリケーション関数

    • 登録と認可: ユーザー名/パスワードとベアラー トークンを使用したシンプルなシステム
    • CRUD イベント: 日付、絵文字、繰り返しタイプを使用してイベントを作成、表示、編集、削除します
    • スマート フィルタリング: [重要なイベント] タブには、繰り返しルールを考慮して、今後 3 日間のイベントが表示されます。たとえば、年次イベントには、最も近い年次イベントが、毎月 – 月の日ごと、毎週 – 曜日ごとに表示されます。
    • 絵文字ピッカー: イベントを素早く分類するための 20 個のプリセット絵文字
    • 今日のイベントのハイライト: 今日のイベントは赤い背景 (#B71C1C) でハイライトされます
    • ダーク テーマ: ライト テーマとダーク テーマの個別のパレットによるシステム カラー スキームの自動検出
    • 国際化: React Context を介したロシア語と英語
    • Анимации: анимированный сплэш-скрин с Keyframe API и упругой интерполяцией, анимированная иконка приложения с вращающимся свечением
    • 管理エンドポイント: ユーザー、トークンの管理、マスター トークンによるデータベースのクリア

    なぜ 2 つのバックエンド実装があるのですか?

    Node.js バージョンがメインですが、よりクラシックなホスティングの代替として PHP バージョンが存在します。 API は完全に同一であるため、クライアント コードを変更せずに API を切り替えることができます。

    インフラストラクチャ

    スタック全体は Docker Compose を通じて生成されます。クライアントはマルチステージ ビルド (Expo エクスポート → nginx alpine)、Node.js 上のサーバー、MongoDB 8 を通じて組み立てられます。PHP バージョンの場合は、MariaDB 11 とテスト用の phpunit を含む別の compose ファイルがあります。

    Web バージョンのアセンブリは、expo エクスポート の前に API_URL にパッチを適用し、後で元のファイルを復元する PowerShell スクリプトによって自動化されます。

    出力

    Mama Calendar は、React Native のモバイルおよび Web フロントエンドから 2 つのサーバー側オプションまで、全サイクルをカバーするフル機能のクロスプラットフォーム アプリケーションです。このプロジェクトは、そのアーキテクチャ、最新の Expo SDK 機能の使用、およびデュアル バックエンド実装において興味深いものです。

    リンク

    https://github.com/zefir1990/Mama-Calendar
    https://demensdeum.com/software/mama-calendar/events

  • Surreal Engine C++ を WebAssembly に移植

    この投稿では、Surreal Engine ゲーム エンジンを WebAssembly に移植する方法について説明します。
    https://demensdeum.com/demos/SurrealEngine/”
    超現実的なエンジン – Unreal Engine 1 の機能のほとんどを実装するゲーム エンジン、このエンジン上の有名なゲーム -アンリアル トーナメント 99、アンリアル、デウス エクス、アンダイング。これは、主にシングルスレッド実行環境で動作する古典的なエンジンを指します。
    私はもともと、妥当な期間内に完了できないプロジェクトに挑戦して、Twitch のフォロワーに私にもできないプロジェクトがあることを示すという考えを持っていました。最初のストリーム中に、Emscripten を使用して Surreal Engine C++ を WebAssembly に移植するタスクが実行可能であることに突然気づきました。

    1 か月後、WebAssembly でフォークとエンジンのアセンブリをデモンストレーションできるようになります。
    https://demensdeum.com/demos/SurrealEngine/
    オリジナルと同様に、コントロールはキーボードの矢印を使用して実行されます。次に、これをモバイル コントロール (タチ) に適応させ、Unreal Championship 99 レンダリングの正しいライティングやその他のグラフィック機能を追加する予定です。

    どこから始めればよいですか?

    まず最初に言いたいのは、Emscripten を使用すればどんなプロジェクトでも C++ から WebAssembly に移植できるということですが、唯一の問題は機能がどの程度完成するかということです。ライブラリ ポートがすでに Emscripten で使用できるプロジェクトを選択します。 Surreal Engine の場合は、エンジンが SDL 2、OpenAL – を使用しているため、非常に幸運です。図書館。どちらも Emscripten に移植されています。ただし、Vulkan はグラフィックス API として使用されており、現在 HTML5 では利用できません。WebGPU の実装作業は進行中ですが、これもドラフト段階であり、完全に標準化された後、Vulkan から WebGPU へのさらなる移植がどれほど簡単になるかも不明です。したがって、Surreal Engine 用に独自の基本的な OpenGL-ES / WebGL レンダラーを作成する必要がありました。

    プロジェクトのビルド

    Surreal Engine でシステムを構築 – CMake は、Emscripten がネイティブ ビルダーを提供するため、移植も簡素化します。えむけ、えむけ。
    Surreal Engine の移植は、Death-Mask と呼ばれる WebGL/OpenGL ES および C++ で作成した最新ゲームのコードに基づいていました。そのため、開発ははるかに簡単で、必要なビルド フラグとコード サンプルがすべて揃っていました。
    CMakeLists.txt の最も重要なポイントの 1 つは Emscripten のビルド フラグです。以下はプロジェクト ファイルの例です。

    set(CMAKE_CXX_FLAGS "-s MIN_WEBGL_VERSION=2 
    -s MAX_WEBGL_VERSION=2 
    -s EXCEPTION_DEBUG 
    -fexceptions 
    --preload-file UnrealTournament/ 
    --preload-file SurrealEngine.pk3 
    --bind 
    --use-preload-plugins 
    -Wall 
    -Wextra 
    -Werror=return-type 
    -s USE_SDL=2 
    -s ASSERTIONS=1 
    -w 
    -g4 
    -s DISABLE_EXCEPTION_CATCHING=0 
    -O3 
    --no-heap-copy 
    -s ALLOW_MEMORY_GROWTH=1 
    -s EXIT_RUNTIME=1")
    

    ビルド スクリプト自体:

    clear
    emmake make -j 16
    cp SurrealEngine.data /srv/http/SurrealEngine/SurrealEngine.data
    cp SurrealEngine.js /srv/http/SurrealEngine/SurrealEngine.js
    cp SurrealEngine.wasm /srv/http/SurrealEngine/SurrealEngine.wasm
    cp ../buildScripts/Emscripten/index.html /srv/http/SurrealEngine/index.html
    

    次に、プロジェクト ファイル システム プリローダーを含む index.html を準備しましょう。 Web にアップロードするために、Unreal Championship Demo バージョン 338 を使用しました。CMake ファイルからわかるように、解凍されたゲーム フォルダーがビルド ディレクトリに追加され、Emscripten のプリロード ファイルとしてリンクされています。

    メインコードの変更

    次に、ゲームのゲーム ループを変更する必要がありました。無限ループを実行することはできません。これによりブラウザがフリーズします。代わりに、emscripten_set_main_loop を使用する必要があります。この機能については、2017 年のメモ「SDL C++ ゲームの HTML5 (Emscripten) への移植」
    while ループを終了するコードを if に変更し、ゲーム ループを含むゲーム エンジンのメイン クラスをグローバル スコープに表示し、グローバル オブジェクトからゲーム ループ ステップを呼び出すグローバル関数を作成します。

    #if __EMSCRIPTEN__
    #include <emscripten.h>
    Engine *EMSCRIPTEN_GLOBAL_GAME_ENGINE = nullptr;
    void emscripten_game_loop_step() {
    	EMSCRIPTEN_GLOBAL_GAME_ENGINE->Run();
    }
    #endif
    

    この後、アプリケーションにバックグラウンド スレッドがないことを確認する必要があります。存在する場合は、シングルスレッド実行用に書き直す準備をするか、Emscripten の phtread ライブラリを使用します。
    Surreal Engine のバックグラウンド スレッドは音楽の再生に使用され、データは現在のトラック、音楽の再生の必要性、または音楽の不在に関するメイン エンジン スレッドから取得され、バックグラウンド スレッドはミューテックス経由で新しい状態を受け取り、新しい音楽の再生を開始するか一時停止します。バックグラウンド スレッドは、再生中に音楽をバッファリングするためにも使用されます。
    pthread を使用して Emscripten 用の Surreal Engine を構築する試みは失敗しました。SDL2 ポートと OpenAL ポートは pthread サポートなしで構築されており、音楽のために再構築したくなかったためです。そこで、BGM ストリームの機能をループを使用したシングルスレッド実行に移行しました。 C++ コードから pthread 呼び出しを削除することで、バッファリングと音楽再生をメイン スレッドに移動し、遅延がないよう、バッファを数秒増やしました。
    次に、グラフィックとサウンドの具体的な実装について説明します。

    Vulkan はサポートされていません!

    はい、Vulkan は HTML5 ではサポートされていませんが、すべてのマーケティング パンフレットでは Vulkan の主な利点としてクロスプラットフォームおよび広範なプラットフォームのサポートが紹介されています。このため、簡素化された OpenGL タイプの基本的なグラフィックス レンダラーを独自に作成する必要がありました。 ES はモバイル デバイスで使用され、最新の OpenGL のファッショナブルな機能が含まれていない場合もありますが、WebGL に非常によく移植されており、まさに Emscripten が実装しているものです。基本的なタイル レンダリング、最も単純な GUI 表示用の bsp レンダリング、およびモデルとマップのレンダリングの作成は 2 週間で完了しました。おそらくこれがこのプロジェクトで最も困難な部分でした。 Surreal Engine レンダリングの全機能を実装するには、まだ多くの作業が必要です。そのため、読者からのコードやプル リクエストの形での支援を歓迎します。

    OpenAL がサポートされています!

    幸運なことに、Surreal Engine はオーディオ出力に OpenAL を使用していることです。 OpenAL で単純な Hello World を作成し、Emscripten を使用して WebAssembly で組み立てたので、すべてがいかに単純であるかが明らかになり、サウンドの移植に着手しました。
    数時間のデバッグ後、Emscripten の OpenAL 実装にはいくつかのバグがあることが明らかになりました。たとえば、モノラル チャネル数の読み取りを初期化するときにメソッドが無限数を返し、無限サイズのベクトルを初期化しようとすると、C++ が例外 Vector::length_error でクラッシュします。
    モノラル チャンネルの数を 2048 にハードコーディングすることで、この問題を回避することができました。

    		alcGetIntegerv(alDevice, ALC_MONO_SOURCES, 1, &monoSources);
    		alcGetIntegerv(alDevice, ALC_STEREO_SOURCES, 1, &stereoSources);
    
    #if __EMSCRIPTEN__
    		monoSources = 2048; // for some reason Emscripten's OpenAL gives infinite monoSources count, bug?
    #endif
    
    

    ネットワークはありますか?

    Surreal Engine は現在オンライン プレイをサポートしていませんが、ボットでのプレイはサポートされていますが、これらのボット用の AI を作成する人が必要です。理論的には、Websocket を使用して WebAssembly/Emscripten 上にネットワーク ゲームを実装できます。

    結論

    結論として、Emscripten ポートが存在するライブラリの使用と、Emscripten 上の WebAssembly 用に C++ でゲームを実装した過去の経験のおかげで、Surreal Engine の移植は非常にスムーズに完了したと言えます。以下は、このトピックに関する知識源とリポジトリへのリンクです。
    も、も、も、モンスターを倒せ!
    また、できれば WebGL/OpenGL ES レンダリング コードでプロジェクトを支援したい場合は、Telegram で私に書いてください:
    https://t.me/demenscave

    リンク

    https://demensdeum.com/demos/SurrealEngine/

    https://github.com/demensdeum/SurrealEngine-Emscripten

    https://github.com/dpjudas/SurrealEngine

  • Chisel を介したクライアント間のポート転送: L3 を使用しない必要最低限​​のトンネル

    2 つのデバイスが NAT または厳格なファイアウォールの内側にあり、お互いを直接「見る」ことができない場合、VPN が標準的なソリューションであるようです。しかし、本格的な L3 トンネル (WireGuard や OpenVPN など) は冗長であることが多く、root 権限が必要で、仮想インターフェイスの設定が必要で、既存のルートと競合する可能性があります。

    このような場合、HTTP 上で実行され、データ転送に WebSocket を使用する TCP/UDP トンネルである Chisel を使用すると便利です。このノートでは、中間サーバーを介してあるクライアントから別のクライアントにポートを「転送」する方法を説明します。

    それはどのように機能しますか?

    状況を想像してください。クライアント A (ホーム サーバーなど)、クライアント B (職場のラップトップ)、およびパブリック IP アドレスを持つ VPS があるとします。クライアント A と B は VPS にアクセスできますが、相互にはアクセスできません。

    転送スキームは次のようになります。
    1.クライアント A は VPS に接続し、サーバー上で「リバース」ポートを開きます。これで、サーバーのポート X に送信されるすべてのものがクライアント A のポート Y に送信されます。
    2.クライアント B は VPS に接続し、ローカル マシンからポート Z をサーバーのポート X に転送します。
    3. その結果、クライアント B は localhost:Z にアクセスし、最終的に クライアント A:Y に到達します。

    このアプローチは、VPS との通信に L3 層が実装されていない場合、またはクライアント間のルーティングを構成する機能がない場合のソリューションの 1 つです。私たちはアプリケーションとポートレベルのみで作業します。

    ステップ 1: サーバーを起動する

    VPS では、Chisel をサーバー モードで実行するだけです。 --reverse フラグは、クライアントがサーバー側でポートを開くことができるようにするために必要です。

    chisel server --port 8080 --reverse
    

    ステップ 2: クライアント A (ソース) に接続する

    クライアント A がポート 3000 でローカル Web サーバーへのアクセスを開きたいとします。彼は VPS に接続し、「サーバー上のポート 2000 を予約して、それを私に 3000 に転送してください」と言います。

    chisel client vps-ip:8080 R:2000:127.0.0.1:3000
    

    これで、VPS のポート 2000 (ループバック インターフェイス上) がクライアント A につながります。

    ステップ 3: クライアント B (コンシューマー) の接続

    現在、クライアント B はこのリソースにアクセスしたいと考えています。同じ VPS に接続し、ローカル ポート 8080 をサーバーのポート 2000 に転送します。

    chisel client vps-ip:8080 8080:127.0.0.1:2000
    

    準備ができて!ここで、クライアント B で http://localhost:8080 を開くと、クライアント A でサービスが実行されていることがわかります。

    安全性とニュアンス

    Chisel は、--auth フラグによる認証をサポートしています。これは、パブリック サーバーを介して作業する場合に強く推奨されます。 TLS 証明書を使用してトラフィックを暗号化することもできます。

    このアプローチの主な利点は、TUN/TAP デバイスや複雑なルーティング テーブルが必要ないことです。これは、WebSocket 接続を介してポートをバインドするという 1 つのことだけを実行する必要最低限​​のトンネルです。 Chisel がポート 443 経由で動作するように設定されている場合、これは企業プロキシ経由でも機能します。

    出力

    Chisel は、特定のネットワーク タスク用のユーティリティです。本格的な VPN を設定せずに、分離されたノード間でポートを転送する必要がある場合、リレー サーバーを介した順方向トンネルと逆方向トンネルの組み合わせが完全に実行可能なソリューションであることがわかります。

    リンク

    https://github.com/jpillora/chisel

  • なぜバグを修正できないのですか?

    コードの作業に何時間も費やし、仮説を検討し、条件を調整しても、バグは依然として再現されます。おなじみですね?この欲求不満の状態は「ゴーストハンティング」と呼ばれることがあります。プログラムは、あなたの修正を無視して、独自の生活を送っているようです。

    この状況の最も一般的で最も迷惑な理由の 1 つは、アプリケーション内の完全に間違った場所でエラーを探していることです。

    「偽症状」の罠

    エラーを見つけると、エラーが「発生」した場所に注意が集まります。しかし、複雑なシステムでは、バグ (クラッシュまたは不正な値) が発生しても、それは長い一連のイベントの終わりにすぎません。結末を修正しようとすると、病気ではなく症状と闘うことになります。

    ここでフローチャートの概念が登場します。

    実際にどのように機能するか

    もちろんフローチャートを毎回紙に直接描く(描画する) 必要はありませんが、アーキテクチャのガイドとして頭の中に入れておくか手元に置いておくことが重要です。フローチャートを使用すると、アプリケーションの操作を結果のツリーとして視覚化できます。

    この構造を理解していないと、開発者はしばしば暗中模索になります。状況を想像してみてください。1 つの条件ブランチでロジックを編集している間に、アプリケーションは (特定のパラメータのセットにより) 考えもしなかったまったく別のブランチに移動します。

    <ブロック引用>
    結果: アルゴリズムの一部で「完璧な」コード修正に何時間も費やしましたが、当然のことながら、アルゴリズムの別の部分で実際に失敗した問題は何も修正されません。


    バグを克服するためのアルゴリズム

    閉ざされたドアを叩くのをやめるには、診断のアプローチを変える必要があります。

    • 結果ツリーで状態を見つける:コードを記述する前に、アプリケーションがたどったパスを正確に判断する必要があります。どの時点で論理が間違った方向に進んだのでしょうか?問題の原因となった特定の状態 (状態) は何ですか?
    • 再現は成功の 80% です: これは通常、テスターと自動テストによって行われます。バグが「浮遊」している場合、開発は条件を共同で検索するプロセスに関与します。
    • できるだけ多くの情報を使用する: ローカリゼーションには、ログ、OS バージョン、デバイス パラメータ、接続タイプ (Wi-Fi/5G)、さらには特定の通信事業者さえも重要です。

    エラーの瞬間を捉えた「写真」

    理想的には、バグを修正するには、バグが再現された時点のアプリケーションの完全な状態を取得する必要があります。インタラクション ログも非常に重要です。インタラクション ログには、最終ポイントだけでなく、ユーザー パス全体 (障害が発生する前にどのようなアクションが行われたか) も示されます。これは、同様の状態を再度作成する方法を理解するのに役立ちます。

    今後のヒント: 複雑なケースが発生した場合は、その状況が再び発生した場合に備えて、コードのこのセクションに拡張デバッグ ログ情報を追加してください。


    AI 時代の「とらえどころのない」状態の問題

    LLM (大規模言語モデル) を使用する最新のシステムでは、古典的な決定論 (「1 つの入力、1 つの出力」) が違反されることがよくあります。まったく同じ入力データを渡しても、異なる結果が得られます。

    これは現代の運用システムの非決定性が原因で発生します。

    • GPU 並列処理: GPU 浮動小数点演算は常に結合的であるとは限りません。スレッドの並列実行により、数値の加算順序が若干変更される可能性があり、結果に影響を与える可能性があります。
    • GPU の温度とスロットル: 実行速度と負荷分散は、ハードウェアの物理的状態に依存する場合があります。大規模なモデルでは、こうした微細な違いが蓄積され、出力時に異なるトークンが選択される可能性があります。
    • 動的バッチ処理: クラウドでは、リクエストが他のリクエストと結合されます。バッチサイズが異なると、カーネルでの計算の計算が変わります。

    そのような状況では、「同じ状態」を再現することはほぼ不可能になります。ここであなたを救うことができるのは、テストへの統計的アプローチのみです。


    ロジックが失敗した場合: メモリの問題

    「安全でない」言語 (C または C++) を使用している場合、メモリ破損が原因でバグが発生する可能性があります。

    これらは最も深刻なケースです。1 つのモジュールでエラーが発生すると、別のモジュールのデータが「上書き」される可能性があります。これにより、通常のアプリケーション ロジックを使用して追跡できない、完全に説明不可能な孤立した障害が発生します。

    アーキテクチャ レベルで身を守るにはどうすればよいですか?

    このような「謎の」バグを回避するには、最新のアプローチを使用する必要があります。

    • マルチスレッド プログラミング パターン:明確な同期により競合状態が排除されます。
    • スレッドセーフな言語: コンパイル時にメモリの安全性を保証するツール:
      • Rust: 所有権システムによりメモリ エラーが排除されます。
      • Swift 6 同時実行性:強力なデータ分離チェック。
      • Erlang: アクター モデルを通じてプロセスを完全に分離します。

    概要

    バグを修正するということは、新しいコードを書くことではなく、古いコードがどのように機能するかを理解することです。管理者が触れてもいないブランチを編集するのは時間を無駄にする可能性があることを覚えておいてください。システムの状態を記録し、AI の非決定性の要素を考慮して、安全なツールを選択します。

  • ドキュメントがあなたの親友である理由

    (更新後も機能し続けるソリューションを作成する方法)

    「アプリはパブリック API のみを使用でき、現在出荷されている OS 上で実行する必要があります。」 Apple アプリレビューガイドライン

    新しいフレームワークを使い始めて、「もうすべて自分で理解できるだろう、ドキュメントを読むのは長すぎる」と思ったことがあるのは、決して一人ではありません。私たちの多くは、最初に試してから指示を見るという自然な調査本能を持っています。それはまったく普通のことです。

    ただし、この段階では、調子に乗って、コードはうまく機能するものの、システムの明白ではない機能に依存しているという状況に陥りがちです。

    単に「自分で解決する」だけでは不十分な場合があるのはなぜですか?

    フレームワーク、特にクローズドなフレームワークは、複雑で多層のシステムです。多くの場合、次のような内部ロジックと最適化が隠蔽されます。

    * 公開ドキュメントには記載されていません。
    * 動作が将来も維持されることを保証するものではありません。
    * 新しいバージョンのリリースにより変更される可能性があります。
    * 開発者に知られている、まだ修正されていない機能が含まれている可能性があります。

    私たちが直感的に行動すると、文書化されたルールではなく、ランダムな観察に基づいてアーキテクチャを構築してしまうリスクがあります。これにより、コードが更新に対してより敏感になる可能性があります。

    ドキュメントは制限ではなく、信頼できるサポートです

    フレームワーク開発者は私たちを助けるマニュアルを作成します。ドキュメント内で動作すると、次の結果が得られます。

    * 安定性;
    * サポート;
    * 予測可能なシステム動作。

    これらの制限を超えると、さらなるリスクを負うことになり、そのようなコードの保守がより困難になります。

    実験?確かに。ただし、境界を理解した上で。
    好奇心は開発者にとって素晴らしい特性です。新しいことを探索して試すことは絶対に必要です。しかし、ここに小さな願いがあります。

    最も快適に実験できる方法は、ベスト プラクティスに頼ることです。

    ドキュメントは、どのパスが最も安全で作成者によってサポートされているかを示すマップです。

    外部の視点: 専門家のアドバイス

    私たちは経験豊富な同僚から次のことを学ぶことがよくあります。

    * 役立つ講座を開催しているので、
    * カンファレンスで講演する
    * 素晴らしい本やブログを書き、
    * 独自のビジョンを共有します。

    彼らの多くは本当に貴重な経験を共有しています。しかし、覚えておく価値があるのは、著者のアプローチが公式ドキュメントと矛盾している場合、それらは脆弱であることが判明する可能性があるということです。

    このような「経験的パターン」は、次のような場合があります。

    * フレームワークの特定のバージョンでのみ動作します。
    * アップデートに敏感です。
    * 異常な状況では予期しない動作をする可能性があります。

    コミュニティから学ぶことは素晴らしく、やりがいのあることです。ただし、アドバイスは、たとえ最も権威のあるものであっても、必ず公式マニュアルで注意深く確認する必要があります。

    SOLID について少し説明

    SOLID 原則からの 3 つのアイデアは、このアプローチを完全に補完します。

    * オープン/クローズの原則: パブリック API を通じて動作を拡張するように努め、可能であれば、隠れた実装に依存しないようにします。
    * リスコフ置換原則: 特定の実装ではなく、契約に依存します。そうしないと、内部での変更が予期せぬ問題を引き起こす可能性があります。
    * 依存関係の反転: 詳細ではなく抽象化に基づいて依存関係を構築します。

    実際には、これは、フレームワークの内部の文書化されていない詳細に結び付けられると、システムが脆弱になることを意味します。
    パブリック インターフェイスとコントラクトに基づいて、次の結果が得られます。

    * フレームワークの変更からコードをより適切に分離します。
    * テストの容易さ。
    * アーキテクチャの予測可能性と信頼性。

    バグがある場合はどうすればよいですか?

    すべてがルールに従って行われたにもかかわらず、結果が期待を満たさないことも起こります。フレームワークは進化しますが、常に完璧であるとは限りません。そのような場合:

    * 問題を再現する最小限のサンプルを構築します。
    * 文書化された API のみが使用されていることを確認してください。
    * バグレポートを送信してください – 開発チームはあなたの仕事に感謝し、支援しようと努めます。

    例が回避策に依存している場合、開発者がサポートを提供することは非常に困難になります。

    フレームワークを最大限に活用する方法

    *ドキュメントを参照してください。
    * 著者のガイドと推奨事項に従ってください。
    * 説明されている機能内で実験してください。
    * インターネットからのアドバイスを公式情報源で確認してください。
    * フレームワーク契約を尊重しながらバグをローカライズします。

    結論

    フレームワークは、独自のゲームルールを持つ強力なツールです。それらを忘れると、コードが過度に脆弱になる危険があります。しかし、私たちは皆、作成された製品が長期間存続し、マイナーアップデートのたびに緊急の修正を必要としないことを望んでいます。

    マニュアルとドキュメントは、真に信頼できるソリューションを作成するのに役立つ優れたサポートです。

    ソース

    https://developer.apple.com/app-store/review/guidelines/
    https://en.wikipedia.org/wiki/SOLID
    https://en.wikipedia.org/wiki/API
    https://en.wikipedia.org/wiki/RTFM

  • Linux 上で iOS 用の C++ SDL アプリケーションを構築する

    このノートでは、Linux 上で iOS 用の C++ SDL アプリケーションを構築し、有料の Apple Developer サブスクリプションなしで ipa アーカイブに署名し、ジェイルブレイクなしで macOS を使用してクリーンなデバイス (iPad) にインストールする手順について説明します。

    まず、Linux 用のビルド ツールチェーンをインストールしましょう。
    https://github.com/tpoechtrager/cctools-port

    ツールチェーンをリポジトリからダウンロードし、Godot Engine Web サイトの指示に従ってインストールを完了する必要があります。
    https://docs.godotengine.org/ru/latest/development/compiling/cross-compiling_for_ios_on_linux.html

    現時点では、Xcode dmg をダウンロードし、そこから SDK をコピーして cctools-port をビルドする必要があります。この段階は macOS で簡単に完了できます。インストールされている Xcode から必要な SDK ファイルをコピーするだけです。アセンブリが成功すると、ターミナルにはクロスコンパイラー ツールチェーンへのパスが含まれます。
    次に、iOS 用の SDL アプリケーションの構築を開始できます。 cmake を開いて、C++ コードをビルドするために必要な変更を追加しましょう。

    SET(CMAKE_SYSTEM_NAME Darwin)
    SET(CMAKE_C_COMPILER arm-apple-darwin11-clang)
    SET(CMAKE_CXX_COMPILER arm-apple-darwin11-clang++)
    SET(CMAKE_LINKER arm-apple-darwin11-ld)
    
    

    これで、cmake と make を使用してコンパイルできるようになりましたが、$PATH をクロスコンパイラー ツールチェーンに追加することを忘れないでください。

    
    PATH=$PATH:~/Sources/cctools-port/usage_examples/ios_toolchain/target/bin
    
    

    フレームワークと SDL と正しくリンクするために、それらを cmake で記述します。たとえば、Space Jaguar ゲームの依存関係です。

    
    target_link_libraries(
    ${FSEGT_PROJECT_NAME}
    ${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/libclang_rt.ios.a
    ${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/libSDL2.a
    ${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/libSDL2_mixer.a
    ${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/libSDL2_image.a
    "${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/CoreServices.framework"
    "${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/ImageIO.framework"
    "${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/Metal.framework"
    "${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/AVFoundation.framework"
    "${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/GameController.framework"
    "${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/CoreMotion.framework"
    "${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/CoreGraphics.framework"
    "${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/AudioToolbox.framework"
    "${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/CoreAudio.framework"
    "${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/QuartzCore.framework"
    "${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/OpenGLES.framework"
    "${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/UIKit.framework"
    "${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/Foundation.framework"
    )
    
    

    私の場合、SDL、SDL_Image、SDL_mixer ライブラリは、静的リンクのために事前に macOS 上の Xcode でコンパイルされています。 Xcode からコピーされたフレームワーク。また、libclang_rt.ios.a ライブラリも追加されました。これには、iOS 固有のランタイム呼び出し (isOSVersionAtLeast など) が含まれます。 Android と同様に、モバイル バージョンでサポートされていない機能を無効にして、OpenGL ES を操作するためのマクロが含まれています。
    ビルドの問題をすべて解決したら、arm 用にアセンブルされたバイナリを取得する必要があります。次に、ジェイルブレイクなしのデバイス上でアセンブルされたバイナリを実行することを考えてみましょう。
    macOS では、開発者プログラムの料金を支払うことなく、Xcode をインストールし、Apple ポータルに登録します。 Xcode でアカウントを追加します ->設定 ->アカウント、空のアプリケーションを作成し、実際のデバイス上に構築します。組み立て中に、デバイスは無料の開発者アカウントに追加されます。組み立てて起動した後、アーカイブをビルドする必要があります。これを行うには、[汎用 iOS デバイスと製品] -> [汎用 iOS デバイスと製品] を選択します。アーカイブ。アーカイブが構築されたら、そこからembedded.mobileprovisionファイルとPkgInfoファイルを抽出します。デバイスへのビルド ログから、正しい署名キーを含む共同設計行、拡張子 app.xcent を持つ資格ファイルへのパスを見つけてコピーします。
    アーカイブから .app フォルダーをコピーし、アーカイブ内のバイナリを Linux のクロスコンパイラーでコンパイルされたバイナリ (SpaceJaguar.app/SpaceJaguar など) に置き換えます。次に、必要なリソースを .app に追加し、アーカイブから .app 内の PkgInfo およびembedded.mobileprovision ファイルの整合性を確認し、必要に応じて再度コピーします。 codesign コマンド – を使用して .app に再署名します。 codesign には、署名用の入力キー、資格ファイルへのパス (.plist 拡張子で名前変更可能) が必要です。
    再署名した後、Payload フォルダーを作成し、拡張子 .app を持つフォルダーをそこに移動し、Payload を持つ zip アーカイブをルートに作成し、アーカイブの名前を拡張子 .ipa に変更します。その後、Xcode でデバイスのリストを開き、新しい ipa をデバイスのアプリケーションのリストにドラッグ アンド ドロップします。この方法では、Apple Configurator 2 によるインストールは機能しません。再署名が正しく行われると、新しいバイナリを含むアプリケーションが 7 日間の証明書とともに iOS デバイス (iPad など) にインストールされます。テスト期間にはこれで十分です。

    ソース

    https://github.com/tpoechtrager/cctools-port

    https://docs.godotengine.org/ru/latest/development/compiling/cross-compiling_for_ios_on_linux.html

    https://jonnyzzz.com/blog/2018/06/13/link-error-3/

    https://stackoverflow.com/questions/6896029/re-sign-ipa-iphone

    https://developer.apple.com/library/archive/documentation/Security/Conceptual/CodeSigningGuide/Procedures/Procedures.html

  • Ubuntu MinGW CMake で Windows 用にビルドする

    この投稿では、Ubuntu で MinGW32 ツールチェーンを使用して Windows 用のライブラリとアプリケーションを構築するプロセスについて説明します。
    wine をインストールします。

    sudo apt-get install wine mingw-w64
    

    これで、Windows 用の C/C++ アプリケーションを構築できるようになります。

    # C
    i686-w64-mingw32-gcc helloWorld.c -o helloWorld32.exe      # 32-bit
    x86_64-w64-mingw32-gcc helloWorld.c -o helloWorld64.exe    # 64-bit
     
    # C++
    i686-w64-mingw32-g++ helloWorld.cc -o helloWorld32.exe     # 32-bit
    x86_64-w64-mingw32-g++ helloWorld.cc -o helloWorld64.exe   # 64-bit
    

    収集したexeはwineで確認できます。
    次に、CMake ビルド、CMakeLists.txt ファイルへの変更を見てみましょう。MinGW 固有のものをビルド ファイルに追加します。

    if (MINGW32)
    set(CMAKE_SYSTEM_NAME Windows)
    SET(CMAKE_C_COMPILER i686-w64-mingw32-gcc)
    SET(CMAKE_CXX_COMPILER i686-w64-mingw32-g++)
    SET(CMAKE_RC_COMPILER i686-w64-mingw32-windres)
    set(CMAKE_RANLIB i686-w64-mingw32-ranlib)
    endif()
    
    // для сборки shared dll
    elseif (MINGW32)
    add_library(FlameSteelEngineGameToolkit.dll SHARED ${SOURCE_FILES})
    else()
    
    // обязательно линкуем со всеми зависимостями
    if (MINGW32)
    target_link_libraries(
                            FlameSteelEngineGameToolkit.dll 
                            -static-libgcc
                            -static-libstdc++
                            SDL2 
                            SDL2_mixer 
                            /home/demensdeum/Sources/cube-art-project-bootstrap/FlameSteelFramework/FlameSteelCore/FlameSteelCore.dll
                            /home/demensdeum/Sources/cube-art-project-bootstrap/FlameSteelFramework/FlameSteelBattleHorn/FlameSteelBattleHorn.dll
                            /home/demensdeum/Sources/cube-art-project-bootstrap/FlameSteelFramework/FlameSteelCommonTraits/FlameSteelCommonTraits.dll)
    
    set_target_properties(FlameSteelEngineGameToolkit.dll PROPERTIES
            PREFIX ""
            SUFFIX ""
            LINK_FLAGS "-Wl,--add-stdcall-alias"
            POSITION_INDEPENDENT_CODE 0 # this is to avoid MinGW warning; 
            # MinGW generates position-independent-code for DLL by default
    )
    else()
    

    私たちは以下を収集します:

    cmake -DMINGW32=1 .
    make
    

    出力は、収集している内容に応じて dll または exe になります。実際の例として、新しい Cube-Art-Project とそのライブラリのリポジトリをご覧ください。
    https://gitlab.com/demensdeum/cube-art-project

    https://gitlab.com/demensdeum/FlameSteelEngineGameToolkitFSGL

    https://gitlab.com/demensdeum/cube-art-project-bootstrap

    出典
    https://arrayfire.com/cross-compile-to-windows-from-linux/

  • Ubuntu OSXCros CMake 用の macOS アプリケーションの構築

    この投稿では、CMake と osxcross を使用して、Ubuntu ビルド マシン上で macOS 用のクロスプラットフォーム C++ アプリケーションをビルドする方法について説明します。
    まず、osxcross ツールチェーンをインストールします。
    https://github.com/tpoechtrager/osxcross
    インストールは 3 段階で行われ、依存関係をダウンロードします。

    cd tools
    ./get_dependencies.sh
    

    Apple 公式 Web サイトから XCode.xip をダウンロードし、XCode から SDK をダウンロードします。

    ./gen_sdk_package_pbzx.sh /media/demensdeum/2CE62A79E62A4404/LinuxSupportStorage/xcode111.xip
    

    最後のステップで XCode の使用許諾契約を読んでいただければ幸いです。次に、必要なプレフィックスを使用してツールチェーンを構築します。

    INSTALLPREFIX=/home/demensdeum/Apps/osxcross ./build.sh 
    

    これで、前の手順のプレフィックス ディレクトリから osxcross を使用できるようになります。 CMake の新しいビルド マクロを追加し、必要なものをすべて記述してみましょう。

    if (OSXCROSS)
    SET(CMAKE_SYSTEM_NAME Darwin)
    SET(CMAKE_C_COMPILER o64-clang)
    SET(CMAKE_CXX_COMPILER o64-clang++)
    SET(CMAKE_C_COMPILER_AR x86_64-apple-darwin19-ar)
    SET(CMAKE_CXX_COMPILER_AR x86_64-apple-darwin19-ar)
    SET(CMAKE_LINKER x86_64-apple-darwin19-ld)
    SET(ENV{OSXCROSS_MP_INC} 1)
    endif()
    

    動的リンクは私にとっては成功しなかったので、ライブラリを静的にエクスポートします。

    if (OSXCROSS)
    add_library(FlameSteelCore STATIC ${SOURCE_FILES})
    else()
    

    次に、osxcross に必要なライブラリがないという事実に直面するかもしれません。私は SDL2 を使用しているときにこれに遭遇しました。 osxcross は既製のライブラリ パッケージをサポートしています –マックポート。たとえば、SDL2-mixer をインストールすると、次のようになります。

    osxcross-macports -v install libsdl2_mixer
    

    この後、cmake-make リンクで通常どおりライブラリ/アプリケーションの構築を開始できます。必要に応じてライブラリの静的リンクを指定することを忘れないでください。

    ライブラリの手動アセンブリ

    現在、静的リンク中にライブラリが正しくアーカイブされないという問題に遭遇しました。最終的なアプリケーションをビルドするときに、次のエラーが表示されます。

    file was built for archive which is not the architecture being linked (x86_64)
    

    このチケットと非常に似ており、回避策を実装することができ、ビルドが正しく完了しました。静的ライブラリを解凍し、osxcross アーカイバを使用して新たにビルドしましょう。

    ar x ../libFlameSteelCore.a
    rm ../libFlameSteelCore.a
    x86_64-apple-darwin19-ar rcs ../libFlameSteelCore.a *.o
    

    また、私が個人的に考えている問題の 1 つは、Ubuntu 上で macOS アプリケーションを直接実行する機能 (少なくとも一部の機能) が欠如していることです。もちろん、darling というプロジェクトはありますが、サポートにはまだ不十分な点が多くあります。

    ソース

    https://github.com/tpoechtrager/osxcross

  • ローカル画像生成: ComfyUI および FLUX モデル

    現在では、クラウド サービスに依存する必要はなくなり、独自のハードウェアだけで高品質の画像を生成できるようになりました。この投稿では、ComfyUI を使用して最新の FLUX モデルをコンピューター上でローカルに実行する方法について説明します。

    ComfyUI はノードベースのアーキテクチャを使用します。これにより、次のことが可能になります。
    – 生成のあらゆる段階を完全に制御します。
    – 既成の「ワークフロー」を簡単に共有

    FLUX は大規模なモデルであるため、ハードウェア要件は SD 1.5 または SDXL よりも高くなります。
    – ビデオ カード (GPU): 12 GB VRAM 以上を搭載した Nvidia RTX (快適な作業用)。 8 GB 以下の場合は、量子化バージョン (GGUF または NF4) を使用する必要があります。
    – ランダム アクセス メモリ (RAM): 最低 16 GB (32 GB 以上が望ましい)。
    – ディスク容量: モデルとコンポーネント用に約 20 ~ 50 GB。

    FLUX を開始する最も簡単な方法は、既製のテンプレートを使用することです。ワークフロー ウィンドウで Flux text to image を検索してインストールするだけです。

    「Text to Image (Flux.1 Dev)」ノードに英語でプロンプトを書き、解像度 (FLUX は 1024×1024 以上で適切に動作します) を選択して、実行 を押します。

    第 1 世代では、モデルがビデオ カード メモリにロードされるため、時間がかかる場合があります。

    https://github.com/comfyanonymous/ComfyUI

  • Local Vibe コーディング: LM Studio、VS Code、Continue

    コード (いわゆる Vibe コーディング) の作成にニューラル ネットワークを使用したいと考えていて、たとえば Nvidia RTX ビデオ カードを備えたかなり強力なコンピューターを持っている場合は、環境全体を完全に無料でマシンに展開できます。これにより、有料サブスクリプションの問題が解決され、コードがどこにも送信されないため、NDA の下でプロジェクトを安全に作業できるようになります。この投稿では、LM Studio、VS Code、Continue 拡張機能のローカル バンドルを組み立てる方法について説明します。

    ローカル Vibe コーディング用ツール

    快適な作業のためには、次の 3 つの主要なコンポーネントが必要です。
    – LM ​​Studio: ローカル LLM をダウンロードして実行するための便利なアプリケーションです。 GGUF モデルの操作に伴うすべての複雑さを引き受け、OpenAI API と互換性のあるローカル サーバーを構築します。
    – VS Code: 人気があり、馴染みのあるコード エディタです。
    – Continue: ニューラル ネットワークを作業環境に直接統合する VS Code の拡張機能。チャットしたり、リファクタリング用のコードをハイライトしたり、オートコンプリートをサポートしたりできます。

    ハードウェア要件

    ローカル言語モデルはメモリを大量に消費します。
    – ビデオ カード (GPU): 8 GB VRAM 以上を搭載した Nvidia (70 ~ 80 億のパラメータを持つモデルで快適に作業するため)。重いモデルには 16 GB の VRAM が必要です。
    – ディスク容量: さまざまなダウンロード モデルを保存するために約 500 GB。

    リンクの構成

    セットアップ プロセスは非常に簡単で、ターミナルでの複雑な操作は必要ありません。
    1. LM Studioをダウンロードしてインストールします。組み込みの検索を使用して、Qwen Coder や gemma3:12b などの軽量モデルを見つけます。
    2. LM Studio で、「ローカルサーバー」タブに移動し、「サーバーの開始」をクリックします。デフォルトでは、「http://localhost:1234/v1」で起動します。
    3. VS Code を開き、プラグイン ストアからContinue 拡張機能をインストールします。
    4. Continue 構成ファイルを開き、LM Studio から「openai」プロバイダーとローカルサーバーのアドレスを指定して新しいモデルを追加します。

    その後、「続行」サイドバーでローカル LLM と直接通信し、コードについて質問したり、新しいコンポーネントを生成したりできます。

    なぜこれが機能するのでしょうか?

    前に書いたように、LLM はフラット構造と WET (Write Everything Twice) コードの方が優れています。ローカル パラメーター モデルは、複雑なアーキテクチャの設計に関しては GPT-4 のような巨大モデルに劣るかもしれませんが、ボイラープレート コードの生成、単純な関数のリファクタリング、およびラピッド プロトタイピングについては十分以上の能力を備えています。

    さらに、ローカル Vibe コーディングを使用すると、コードがマシンから離れることはありません。このため、この組み合わせは企業開発や機密データの取り扱いに最適です。

    出力

    ローカル ニューラル ネットワークは、プログラマーを完全に置き換えたり、複雑なシステムを設計したりすることはできません。ただし、LM Studio + VS Code + Continue の組み合わせにより、クラウド サービスからの独立性が提供され、プライバシーが維持されます。これは、小さなモデルの制限を我慢してプロジェクト アーキテクチャを独立して制御する意欲がある場合、日常的なタスクに完全に機能する補助ツールです。

    リンク

    https://code.visualstudio.com/
    https://lmstudio.ai/
    https://continue.dev/

    ソース

    https://youtu.be/IqqCwhG46jY
    https://www.youtube.com/watch?v=7AImkA96mE8

  • ローカルビデオ生成: ComfyUI および LTX-2.3

    以前は、ニューラル ネットワークを使用してビデオを作成することは、Runway や Luma などのクラウド サービスの特権でした。現在、最新の Nvidia グラフィック カードをお持ちであれば、コンピュータ上で高品質のビデオを生成できます。この記事では、ComfyUI と効果的なLTX-2.3 モデルを使用してローカル ビデオ生成を設定する方法を説明します。

    ビデオ生成用ツール

    仕事のためには次のものが必要です。
    – ComfyUI: ノードベースのアーキテクチャを備えた強力なインターフェイスで、生成プロセスを柔軟にカスタマイズできます。
    – LTX-2.3: Lightricks の最新モデル。比較的適度なビデオ メモリ要件でスムーズで詳細なビデオを作成するために最適化されています。

    ハードウェア要件

    ビデオの生成は、画像を操作するよりもはるかにリソースを大量に消費するプロセスです。
    – ビデオ カード (GPU): 768×512 の解像度には、8 GB VRAM を搭載した Nvidia RTX が最低限必要です。快適な操作とより高い解像度を実現するには、16 ~ 24 GB の VRAM を搭載することが非常に望ましいです。
    – ランダム アクセス メモリ (RAM): 最低 32 GB。ビデオ モデルと VAE は、ダウンロード時に多くのスペースを消費します。
    – ディスク容量: モデル自体と関連コンポーネント用に約 500 GB。

    セットアップと起動

    ComfyUI で LTX-2.3 を起動するプロセスは次のとおりです。
    1. ComfyUI を更新します: このモデルは比較的新しいため、最新バージョンのインターフェースがインストールされていることを確認してください。
    2. ワークフローのインストール: 最も簡単な方法は、LTX ビデオ用の既製の JSON テンプレートを見つけることです。このモデルでは、ビデオ潜在スペースを処理するには特定のノードが必要です。
    3. プロンプトとパラメータ: シーンの説明を英語で入力します。 LTX-2.3 は動きをよく理解していることに注意してください (例: 「カメラが周回する」、「速い動き」)。

    LTX-2.3 を選ぶ理由

    LTX-2.3 は、独自のクラウド サービスと同等の結果を提供しながら、ローカルで実行できるという点で注目に値します。これにより、次のことが得られます。
    – 完全なプライバシー: プロンプトや生成されたビデオが他の人のサーバーに送信されることはありません。
    – コントロール: 試行ごとに料金を支払うことなく、フレーム レート (FPS)、解像度、プロンプトの強度を試すことができます。

    ローカル ビデオ生成は現在も開発が進められており、LTX-2.3 は「ホーム ハリウッド」の世界への素晴らしい入り口となります。

    リンク

    https://github.com/comfyanonymous/ComfyUI
    https://huggingface.co/Lightricks/LTX-Video

  • ローカル音楽生成: ComfyUI および ACE-Step-1.5 モデル

    現在では、コンテンツを作成するためにクラウド サービスに依存する必要はありません。高品質の音楽をすべて自分のハードウェアで生成できます。この投稿では、ComfyUI を使用して最新の ACE-Step-1.5 モデルをコンピュータ上でローカルに実行する方法について説明します。

    ComfyUI はノードベースのアーキテクチャを使用します。これにより、次のことが可能になります。
    – オーディオ生成のあらゆる段階を完全に制御します。
    – 既成の「ワークフロー」を簡単に共有。

    ACE-Step-1.5 は、大量の計算リソースを必要とする音楽生成のための高度なモデルです。ハードウェア要件は、多くの単純なシンセサイザーの要件よりも高くなります。
    – ビデオ カード (GPU): 8 GB VRAM 以上 (12 GB 以上を推奨) を搭載した Nvidia RTX により、高品質で快適な作業が可能です。
    – ランダム アクセス メモリ (RAM): 最低 16 GB (32 GB 以上が望ましい)。
    – プロセッサ (CPU): AVX/CUDA コンピューティングを適切にサポートする最新のマルチコア プロセッサ。
    – ディスク容量: モデルとコンポーネント用に約 20 ~ 50 GB。

    ACE-Step-1.5 を実行する最も簡単な方法は、既製のオーディオ生成テンプレートを使用することです。ワークフローウィンドウで音楽テキストをオーディオに検索してインストールするだけです。

    ジャンルと雰囲気を説明するプロンプト (たとえば、「重低音のある高揚感のあるシンセウェーブ トラック」) を「プロンプト入力」ノードに書きます。希望の期間を指定して実行を押します。
    第 1 世代では、モデルがビデオ カード メモリにロードされ、複雑な音響パターンが処理されるため、時間がかかる場合があります。

    https://github.com/comfyanonymous/ComfyUI
    https://www.youtube.com/watch?v=UAlLD5fS7-c

  • ollamを使用したローカルニューラルネットワーク

    ChatGPT のようなものを起動したいと思っていて、たとえば Nvidia RTX ビデオ カードを備えたかなり強力なコンピューターを持っている場合は、ollam プロジェクトを実行できます。これにより、ローカル マシン上で既製の LLM モデルの 1 つを完全に無料で使用できるようになります。 ollama は、ChatGPT の方法で LLM モデルと通信する機能を提供します。最新バージョンでは、画像を読み込み、出力データをjson形式でフォーマットできる機能も発表されました。

    また、プロジェクト自体も Apple M2 プロセッサを搭載した MacBook で実行しましたが、AMD の最新モデルのビデオ カードがサポートされていることもわかっています。

    macOS にインストールするには、ollam Web サイトにアクセスしてください。
    https://ollama.com/download/mac

    「macOS 用のダウンロード」をクリックすると、ollama-darwin.zip 形式のアーカイブがダウンロードされます。アーカイブ内には Ollama.app があり、これを「アプリケーション」にコピーする必要があります。この後、Ollama.app を起動します。おそらく、最初の起動時にインストール プロセスが発生します。その後、トレイにオラマのアイコンが表示されます。トレイは右上の時計の隣にあります。

    その後、通常の macOS ターミナルを起動し、コマンドを入力して ollam モデルをダウンロード、インストールし、実行します。利用可能なモデル、説明、およびその特性のリストは、ollam Web サイトでご覧いただけます。
    https://ollama.com/search

    発売時にビデオカードに適合しない場合は、パラメータが最も少ないモデルを選択してください。

    たとえば、llama3.1:latest モデルを起動するコマンドは次のようになります。

    ollama run llama3.1:latest
    

    Windows と Linux のインストールは一般的に似ていますが、場合によっては ollam インストーラーがあり、さらに Powershell 経由でインストーラーを操作します。
    Linux の場合、インストールはスクリプトを使用して行われますが、特定のパッケージ マネージャーのバージョンを使用することをお勧めします。 Linux では、通常の bash ターミナル経由で ollam を起動することもできます。

    情報源
    https://www.youtube.com/watch?v=Wjrdr0NU4Sk
    https://ollama.com

  • ffmpegを使用したビデオ安定化

    ビデオを安定させて手ぶれを除去したい場合は、「ffmpeg」ツールが強力なソリューションを提供します。組み込みフィルター `vidstabdetect` と `vidstabtransform` のおかげで、複雑なビデオ エディターを使用せずにプロフェッショナルな結果を達成できます。

    仕事の準備

    始める前に、`ffmpeg` が `vidstab` ライブラリをサポートしていることを確認してください。 Linux では、次のコマンドでこれを確認できます。

    bash  
    ffmpeg -filters | grep vidstab  
    

    ライブラリがインストールされていない場合は、追加できます。

    sudo apt install ffmpeg libvidstab-dev  
    

    brew による macOS のインストール:

    brew install libvidstab
    brew install ffmpeg
    

    それでは、プロセスに進みましょう。

    ステップ 1: 動作分析

    まず、ビデオの動きを分析し、安定化パラメータを含むファイルを作成する必要があります。

    ffmpeg -i input.mp4 -vf vidstabdetect=shakiness=10:accuracy=15 transfile=transforms.trf -f null -  
    

    パラメータ:

    揺れ: ビデオの揺れレベル (デフォルトは 5、より複雑な場合は 10 まで増やすことができます)。
    精度: 分析精度 (デフォルトは 15)。
    transfile: モーションパラメータを保存するファイル名。

    ステップ 2: 安定化を適用する

    これで、変換ファイルを使用して安定化を適用できるようになりました。

    ffmpeg -i input.mp4 -vf vidstabtransform=input=transforms.trf:zoom=5 output.mp4
    

    パラメータ:

    input: 変換パラメータを含むファイル (最初のステップで作成) を指します。
    ズーム: 黒いエッジを除去するためのズーム係数 (例: 5 – アーティファクトが除去されるまで自動ズーム)。

  • チューリング コンピューティング マシン

    私は、1936 年のアラン・チューリングの論文「解像度の問題への応用による計算可能な数について」の最初のページの翻訳を紹介します。最初の章には、後に現代のコンピューティングの基礎となるコンピューターの説明が含まれています。

    この記事の完全な翻訳と説明は、アメリカの普及者 Charles Petzold による書籍「Reading Turing: A Journey through Turing’s Historical Article on Computability and Turing Machines」(ISBN 978-5-97060-231-7、978-0-470-22905-7) で読むことができます。

    元の記事:
    https://www.astro.puc.cl/~rparra/tools/PAPERS/turing_1936.pdf

    解像度問題への応用による計算可能な数値について

    午前チューリング

    [1936 年 5 月 28 日に受領 – 1936 年 11 月 12 日に読了]

    「計算可能な」数値は、小数としての表現が有限の方法で計算できる実数として簡単に説明できます。一見すると、この記事では数値を計算可能なものとして扱いますが、整変数、実数変数、計算可能な変数、計算可能な述語などの計算可能な関数を定義して調査することは、ほぼ同じくらい簡単です。ただし、これらの計算可能なオブジェクトに関連する基本的な問題は、どの場合でも同じです。詳細な検討のために、計算可能な数値を考慮する方法が最も面倒ではないため、計算可能なオブジェクトとして計算可能な数値を選択しました。計算可能な数値と計算可能な関数などの関係については、近いうちに説明したいと思っています。同時に、計算​​可能な数値で表現される実変数の関数理論の分野でも研究が行われます。私の定義によれば、実数は、その 10 進数表現が機械で記述できる場合に計算可能です。

    パラグラフ 9 と 10 では、計算可能な数値には、当然計算可能であると考えられるすべての数値が含まれることを示すために、いくつかの議論を示します。特に、いくつかの大きなクラスの数値が計算可能であることを示します。これらには、たとえば、すべての代数的数値の実部、ベッセル関数のゼロの実部、数値 π、e などが含まれます。ただし、次の計算不可能な定義可能な数値の例でわかるように、計算可能な数値には定義可能な数値がすべて含まれるわけではありません。

    計算可能な数値のクラスは非常に大きく、多くの点で実数のクラスと似ていますが、依然として数えることが可能です。 §8 では、反対と思われる特定の議論を検討します。これらの議論の 1 つが正しく適用されると、一見するとゲーデル* の結論と似た結論が導き出されます。これらの結果は非常に重要な応用分野を持っています。特に、以下に示すように (§11)、解像度の問題には解決策がありません。

    最近の記事で、アロンゾ・チャーチは「実効計算可能性」という考え方を紹介しました。これは私の「計算可能性」という考え方と同じですが、定義はまったく異なります。チャーチも解決の問題に関して同様の結論に達しています。 「計算可能性」と「効率的に計算可能」が同等であることの証明は、この記事の付録に示されています。

    1. コンピュータ

    計算可能な数とは、小数点以下の桁が有限の方法で数えられる数であることはすでに述べました。ここではより明確な定義が必要です。この記事では、§9 に到達するまで、ここで与えられた定義を正当化する実際の試みは行いません。今のところ、(このための)(論理的な)根拠は、人間の記憶には必然的に限界があるということだけを述べておきます。

    実数を計算する過程にある人間と、有限数の条件 q1、q2、…、qR のみを満たすことができる機械を比較してみましょう。これらの条件を「m 構成」と呼びます。この(つまり、そのように定義された)マシンには「テープ」(紙に似たもの)が装備されています。機械内を通過するこのベルトはいくつかのセクションに分かれています。それらを「正方形」と呼びましょう。このような各正方形には、何らかの「シンボル」を含めることができます。いつでも、「このマシン内にある」シンボルを含むそのような正方形は 1 つだけ、たとえば r 番目の正方形だけです。このような正方形を「スキャンされたシンボル」と呼びます。 「スキャンされた文字」は、いわばマシンが「直接認識している」唯一の文字です。ただし、m 構成を変更することで、マシンは以前に「見た」(スキャンした) 文字の一部を効果的に記憶できるようになります。いつでもマシンの可能な動作は、m 構成 qn とスキャンされたシンボル *** によって決まります。このシンボルのペアを qn、「構成」と呼びましょう。このように指定された構成によって、特定のマシンの可能な動作が決まります。スキャンされた正方形が空白である (つまり、文字が含まれていない) 構成の一部では、マシンはスキャンされた正方形に新しい文字を書き込み、その他の構成ではスキャンされた文字を消去します。このマシンは移動して別のマスをスキャンすることもできますが、この方法では右または左に隣接するマスにのみ移動できます。これらの操作に加えて、マシンの m 構成を変更することもできます。この場合、書かれた文字の一部は、計算される実数の小数部分である一連の数字を形成します。残りは「記憶を助ける」ための不正確なマークにすぎません。この場合、上記の不正確なマークのみを消去することができる。

    ここで考慮される演算には、計算で使用されるすべての演算が含まれると主張します。このステートメントの理論的根拠は、機械理論を理解している読者にとっては理解しやすいものです。したがって、次のセクションでは、「マシン」、「テープ」、「スキャンされた」などの用語の意味の理解に基づいて、問題の理論を展開していきます。

    *ゲーデル「プリンキピア数学 (1910 年、1912 年、1913 年にホワイトヘッドとラッセルによって出版) および関連システムの形式的に決定不可能な文について、第 1 部」数学ジャーナル。 『物理学』ドイツ語月刊誌第 38 号 (1931 年、173-198 ページ)。
    ** アロンゾ・チャーチ、「初等整数理論における決定不可能な問題」、American J. of Math.、第 58 号 (1936 年)、345-363 ページ。
    *** アロンゾ チャーチ、「解決の問題に関するメモ」、J. of Symbolic Logic、No. 1 (1936)、40-41 ページ

  • ドンキヒルズ

    Donki Hills は一人称視点のホラー コメディ アドベンチャーで、プレイヤーはサスペンスと予期せぬユーモアが組み合わさったミステリアスな物語を体験できます。
    主人公のジェームズは、オンライン上の友人マリアを探しに行きます。マリアとのつながりは突然切れました。唯一の証拠は、ノボシビルスク地方のドンキ・ヒルズという人里離れた村を示すランダムな写真です。真実を突き止めたいという欲求に駆られたジェームズは、マリアの失踪のすべての状況を明らかにするために独自の調査を開始します。

    ゲームは Steam で入手できます:
    https://store.steampowered.com/app/3476390/Donki_Hills/

  • 石積みAR

    Masonry AR は、秘密結社の世界に浸れる位置ベースのマルチプレイヤー拡張現実 (AR) ゲームです。あなたの街の通りを探索し、フリーメーソンの知識の本を集め、自分のロッジを見つけて、現実世界の地図上での影響力を競いましょう。

    主な機能

    • 地理位置情報ベースのゲームプレイ:デバイスの GPS を使用して現実世界を移動し、秘密の本やリソースを見つけます。
    • 自動ウォーク モード:GPS アクセスが制限されている場合は、世界の首都の 1 つを開始点として選択して自動ウォーク モードを開始できます。
    • ロッジの作成: 実際の地図上にフリーメーソンのロッジを設立し、教団の影響力を拡大します。
    • ゲーム内経済: ゲーム内通貨 (MOS) を獲得し、領土を開発し、友達と紹介リンクを共有します。
    • クロスプラットフォーム: Three.js に基づいたレンダリングを備えた Flame Steel Engine 2 ゲーム エンジンのおかげで、ゲームはモバイル デバイスや PC の Web ブラウザで直接実行されます。

    遊ぶ:
    https://demensdeum.com/games/masonry-ar/client/

    GitHub:
    https://github.com/zefir1990/Masonry-AR

  • テフレッチャー


    Teflecher は、Kotlin マルチプラットフォーム (KMP) と Compose マルチプラットフォーム 上に構築された、高速でインタラクティブなクロスプラットフォームのクイズ アプリケーションです。これにより、ユーザーはローカル JSON ファイルまたはリモート URL からクイズを直感的にロードし、多肢選択式の質問に回答し、正解に対する即時のフィードバックを確認し、結果を追跡することができます。

    ウェブ:
    https://demensdeum.com/software/teflecher/

    GitHub:
    https://github.com/zefir1990/teflecher

    また、イオン + キャパシタ テクノロジーに基づいた Teflecher Editor 形式のクイズ エディターでもあります。

    ウェブ:
    https://demensdeum.com/software/teflecher-editor/

    GitHub:
    https://github.com/zefir1990/teflecher-editor

  • ゴーストコンタクト


    ゴースト連絡先は、標準システム API や電話帳から連絡先を隠すように設計されたシンプルな Web アプリケーションです。すべての情報はブラウザ内でのみローカルに保存され、外部サーバーには転送されません。

    主な機能

    • システム API からの非表示:連絡先は、標準のシステム連絡先 API およびデバイスの電話帳と同期されません。
    • パニック パスワード: 特別なパスワードを入力すると、連絡先データベース全体が即座に取り消し不能に削除されます。
    • インポートとエクスポート: バックアップ コピーを作成するために、CSV ファイル経由で連絡先データベースを便利に転送します。

    オンライン申請:
    https://demensdeum.com/software/ghost-contacts/

    GitHub:
    https://github.com/demensdeum/GhostContacts

  • キューブアートプロジェクト2

    キューブ アート プロジェクト 2 へようこそ – 想像力を自由に働かせる瞑想的な 3D キャンバスです。ボクセル ペイントを作成し、色を試し、ブラウザ内でユニークな 3D モデルに命を吹き込みます。

    キューブアートプロジェクト2とは何ですか?

    これは、画面を 3D ペイント用のインタラクティブなキャンバスに変えるクリエイティブなゲームです。あなたの目の前には、あなたのアイデア、形、明るい色で満たされる、きれいな三次元空間が広がっています。

    主な機能

    • 3D 描画: ボクセル アートと 3D ジオメトリの作成に焦点を当てた、リラックスできるクリエイティブ プロセス
    • カラーピッカー: 便利な RGB スライダーを使用して、各ブロックの色合いを微調整します。
    • 動きの自由: 便利なカメラ制御を使用して、あらゆる角度から絵画を探索できます。
    • キャンバスの保存: 作業内容をファイルに保存し、いつでも描画に戻ったり、他のユーザーと作業内容を共有したりできます。

    管理

    • WASD – カメラの動き
    • マウス – カメラの回転と検査
    • インターフェース (GUI) – 色の選択と調整

    遊ぶ:
    https://demensdeum.com/software/cube-art-project-2/

    GitHub:
    https://github.com/zefir1990/cube-art-project-2

  • Raiden Video Ripper

    Raiden Video Ripper は、ビデオ編集とフォーマット変換のために設計されたオープンソース プロジェクトです。 Qt 6 (Qt Creator) を使用して作成されており、ビデオを編集して MP4、GIF、WebM 形式に変換できます。動画から音声を抽出してMP3形式に変換することもできます。

    マイクロソフト ストア:
    https://apps.microsoft.com/detail/9nvzjs98smgc

    GitHub:
    https://github.com/demensdeum/RaidenVideoRipper/releases

  • マーズマイナーズ

    赤い惑星の過酷な状況では、一秒一秒、すべてのセクターが重要です。コロニーの存続と貴重な火星の資源の管理を賭けて戦うターンベースの戦略ゲームであるマーズ マイナーズをご紹介できることを嬉しく思います。

    火星採掘者とは何ですか?

    マーズ マイナーズでは、火星の採掘会社を管理します。あなたの任務は、人工知能や他のプレーヤーとの激しい競争に直面して、基地を建設し、資源セクターを占領し、自律採掘ユニットの行動を調整することです。

    主な機能

    • 戦術戦略: 事前に敵の動きを計算し、基地の開発と領土の占領を計画します。
    • 自律ユニット: 採掘ロボットの動作を調整し、効率を最大化するためにロジックをカスタマイズします。
    • さまざまなモード: シングルプレイヤーの訓練場でスキルを磨いたり、マルチプレイヤー モードで他の入植者と競争したりできます。
    • 高度な AI: 戦術的なミスを許さないスマート オートマトンとリソースを奪い合います。

    マーズ マイナーズをプレイする

  • フレイムスティール:デスマスク2

    冷たい光があふれる工業用巨大構造物の果てしない廊下で、新たな挑戦があなたを待っています。古典的な美学と最新のリアルタイム ゲームプレイを組み合わせた 3D ダンジョン クローラーであるFlame Steel: Death Mask 2 をご紹介できることを嬉しく思います。

    フレイム スティール: デスマスク 2 とは何ですか?

    手続き的に生成された迷路で目が覚めると、「フィルター」と呼ばれる敵対的な存在が毎ターン潜んでいる可能性があることを想像してみてください。 Flame Steel: Death Mask 2 では、あなたはシーカーの役割を引き受け、Flame Steel Engine 2 (Three.js グラフィックス レンダリングを使用) 上に構築された世界を探索します。

    主な機能

    • プロシージャルダンジョン: それぞれの試みはユニークです。サーバーは秘密と危険に満ちた新しいマップを作成します。
    • ターミナル: 完全な制御を希望する場合は、組み込みのコマンド ライン インターフェースを使用してシステムと直接対話することができます。高度なアクションの実行、デバッグ、コマンドの送信などを行うことができます。
    • 戦闘とサバイバル: フィルターと戦ってビットを獲得し、それを使って宝箱を開け、ステータスを向上させます。健康に注意してください。生存が保証されているわけではありません。
    • 工業的な美学: 巨大な巨大構造物の高コントラストの視覚化と無菌的な雰囲気

    マスクの背後にあるテクノロジー

    ゲームはブラウザ用に作成されており、以下を使用します。

    • フロントエンド: スムーズな 3D レンダリングのための純粋な JavaScript と Flame Steel Engine 2 (Three.js グラフィックス レンダラー付き)。
    • バックエンド: サーバー側を実行するための Node.js。
    • インフラストラクチャ: 永続的なデータ ストレージ用の MongoDB とリアルタイムの空間インデックス作成用の Redis

    Flame Steel: Death Mask 2 をプレイ

  • ウシュキラジオ

    Ushki-Radio は、シンプルさと聴く楽しさに重点を置いて作られた、オンライン ラジオ用のクロスプラットフォーム ラジオ プレーヤーです。不要な機能やオーバーロードされたインターフェイスはなく、電源を入れて聞くだけです。


    https://demensdeum.com/software/ushki-radio

    このプロジェクトではオープンソースの Radio Browser を使用し、世界中の何千ものラジオ局をアプリケーションで利用できるようにしています。名前、ジャンル、または人気で検索し、お気に入りに追加して、お気に入りのステーションにすぐに戻ることができます。

    Ushki-Radio はバックグラウンド ラジオ プレーヤーの役割に最適です。最後の放送局を記憶しており、音量を制御でき、複雑な設定は必要ありません。インターフェイスは簡潔で理解しやすく、音楽、会話、放送の邪魔にならないようにすべてが行われています。

    技術的には、このプロジェクトは React Native と Expo に基づいて構築されているため、ブラウザーとネイティブ アプリケーションの両方で動作します。内部では、expo-av を使用してオーディオを再生し、ユーザー設定はローカルに保存されます。ロシア語や英語など、いくつかの言語がサポートされています。

    Ushki-Radio は、オープン、軽量、拡張可能、そして主にリスナーに焦点を当てた、最新のインターネット ラジオ プレーヤーがどのようなものであるかを示す好例です。このプロジェクトは MIT ライセンスに基づいて配布されており、個人使用だけでなく、オーディオ アプリケーションを使用した独自の実験の基礎としても最適です。

    GitHub:
    https://github.com/demensdeum/Ushki-Radio

    Googleプレイ:
    https://play.google.com/store/apps/details?id=com.demensdeum.ushkiradio

  • Glazki TV: インターネット テレビ用の最新プレーヤー

    Glazki TV は、React Native と Expo に基づいて構築された、インターネット テレビ (IPTV) 用の最新の高性能プレーヤーです。このプロジェクトは使いやすさと速度に焦点を当てており、モバイル デバイスとブラウザの両方で IPTV チャンネルを視聴するための便利なインターフェイスを提供します。

    主な機能

    • チャンネルの閲覧: 簡単にナビゲーションできるように分類された何千ものチャンネルを閲覧します。
    • 検索: 必要なチャンネルを名前ですばやく見つけます。
    • お気に入り: すぐにアクセスできるようにお気に入りのチャンネルを保存します (データはローカルに保存されます)。
    • ディープリンク: 自動的に開くチャンネルへの直接リンクを共有します。
    • テーマのサポート: インターフェースは、システムの暗いテーマまたは明るいテーマに自動的に適応します。
    • ウェブ サポート: プレーヤーは URL 同期によりブラウザで完全に機能します。

    テクノロジースタック

    このプロジェクトは最新の開発ツールに基づいています。

    • フレームワーク: React Native + Expo
    • Video Player: expo-video (замена устаревшему expo-av)
    • UI ツールキット: 反応ネイティブペーパー
    • プレイリスト パーサー: iptv-playlist-parser

    ウェブ版:
    https://demensdeum.com/software/glazki-tv/

    Google Play バージョン:
    https://play.google.com/store/apps/details?id=com.demensdeum.glazkitv

  • ゼフィール1990


    Zefir1990 – Ilia Prokhorov、私は商用開発で​​ 15 年以上の経験を持つ開発者です。モバイル、Web、デスクトップ システム用のゲームとアプリケーションを開発する Demens Deum スタジオの創設者。 Android 2 上の最初の 3D OpenGL ES 2 ゲーム Mad Racer は 2010 年にリリースされました。彼はこのプロジェクトにプログラマー兼ゲーム デザイナーとして参加し、開発には作曲家の Anton Dmitriev (coolspotdreamer) も参加しました。ゲームの発売が成功した後は、フルタイムのカスタム開発と契約に基づくプロジェクト開発に従事しました。クライアントには Decathlon、Playboy、Fitbit が含まれます。

    私はソフトウェア開発、ゲーム、デザイン パターン、アルゴリズム、AI に関する記事の著者でもあり、ソフトウェア エントロピーに関する本を書く予定です。

    推奨プログラミング言語: ASM、C、C++、ObjC、Python、Kotlin、Swift、Java、Rust、Go、TypeScript、JavaScript、C#、Dart、PHP。

    LinkedIn: linkedin.com/in/zefir1990
    GitHub: github.com/zefir1990
    電報: t.me/zefir1990
    電子メール: ceo@demensdeum.com
    Twitch: twitch.tv/zefir1990
    YouTube: youtube.com/zefir1990

DemensDeum
Privacy Overview

This website uses cookies so that we can provide you with the best user experience possible. Cookie information is stored in your browser and performs functions such as recognising you when you return to our website and helping our team to understand which sections of the website you find most interesting and useful.