ローカルビデオ生成: 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

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

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 Codergemma3: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 および 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

Wi-FiルーターとしてのRaspberry PI 3

Raspberry Pi (RPI) から Wi-Fi ルーターを作成する方法については、インターネット上にたくさんの記事があります。この記事では、Sing-Box を搭載した Wi-Fi ルーターを作成する方法を簡単に説明します。ここで説明した方法は現時点では機能しますが、将来的には大きく変更される可能性があります。したがって、このメモは、これから直面する問題の大まかな概要として使用してください。

SSH

OpenWrt の操作方法がわからない人には、dietPI をインストールすることをお勧めします。
RPI を eth0 経由で現在のルーターに接続し、そこに SSH 経由で接続します。 RPI IP アドレスは、ルーターの dhcp パネルで確認できます。たとえば次のように root に直接接続します。

ssh root@[IP_ADDRESS]

アクセスポイント

root のデフォルトの DietPI パスワードは Dietpi です。接続すると、dietPI インストーラー/コンフィギュレーターが表示されます。完了したら、デバイスが再起動するため、再度接続する必要があります。

まず、デバイスがアクセス ポイントを認識できるように hostapd を構成する必要があります。 hostapd がインストールされていない場合は、apt 経由でインストールします。

次に、hostapd の構成を記述する必要があります。私の構成の例:

interface=wlan0
driver=nl80211
ssid=MyPiAP
hw_mode=a
channel=157
wmm_enabled=1

auth_algs=1
wpa=2
wpa_passphrase=your_password
wpa_key_mgmt=WPA-PSK
rsn_pairwise=CCMP
ieee80211n=1
ieee80211ac=0
ieee80211ax=0
country_code=RU

hostapd 設定の意味についてはマニュアルを参照してください。ただし、重要なのは、チャネル (2.4 GHz または 5 GHz)、国コードを自分で設定することです。これがないと、ローカライズされたデバイスがアクセス ポイントで正しく動作できません。私はすでにこれを行っており、知っているので、必ず国を設定してください。

DHCP

次に、dnsmasq をインストールして構成し、DHCP を実装します。これは、接続されたコンピュータが IP アドレスと DNS サーバーを決定するために必要です。
私の構成の例:

interface=wlan0
dhcp-range=172.19.0.10,172.19.0.200,255.255.255.0,12h

dhcp-option=3,172.19.0.1

dhcp-option=6,1.1.1.1,8.8.8.8

no-resolv

server=1.1.1.1
server=8.8.8.8

これは、アクセス ポイントに接続して IP アドレスを取得できるようにするための最小限の構成です。次に、ルーティングと NAT を構成する必要があります。これは、接続されたコンピュータがインターネットにアクセスできるようにするために必要です。

ここでのメモは、インターネット上に多くの記事がある、通常の Debian 互換システムでの典型的なルーティング設定のカテゴリに属します。その後、すべては追求する目標によって異なります。たとえば、システム内の新しいインターフェイスとして外部サーバーに接続するか、単に wlan0 <-> eth0 を実行するか、これで RPI の詳細は終了し、好みに合わせて設定します。

また、systemctl を介してカスタム システム サービスを構成する必要性についても触れておきたいと思います。サービスをチェーンで接続する必要がある場合があります。これはすべて、ネットワーク上の systemctl マニュアルに記載されています。サービス レベルで問題がある場合は、journalctl のログを確認してください。

Wi-Fi アダプター

内蔵のRPI3は正直弱く、5GHzをサポートしていないことが判明しました。したがって、USB 2 経由で Realtek RTL8811CU チップセット上の RITMIX RWA-150 アダプターを接続しました。ドライバーは、私の DietPi バージョンの Linux カーネルに追加されました。次に、dietpi-configを使用して、内蔵Wi-Fiを完全にオフにしました。その結果、wlan0 USB アダプターは 1 つだけ残りました。

結論

速度測定から、Wi-Fi 経由で RPI3 から約 50Mbps を引き出すことができました (5GHz アダプターの接続後)。これは、ルーターに直接接続した場合と比較して速度が半分低下することを意味します。生産性の高い RPI モデルを使用すると、より良い結果が得られることは認めますが、専用の OpenWrt デバイスや既製のソリューションがニーズに適している可能性もあります。

ソース

https://forums.raspberrypi.com/viewtopic.php?t=394710
https://superuser.com/questions/1408586/raspberry-pi-wifi-hotspot-slow-internet-speed
https://www.youtube.com/watch?v=jlHWnKVpygw

ローカル画像生成: 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

マーズマイナー v2

[休憩:レッドホライゾン惑星間通信]

ホスト: おやすみ、マース!ドームのメインニュースサービスがあなたとともにあります。本日、マーズマイナーコロニーの管理者は、すべての入植者と戦略モジュール向けの大規模なソフトウェアアップデートを発表しました。

主なイベント:

1. オートマトンの神経回路の更新 サイバネティクス部門は、すべての自律採掘ユニットの更新が成功したことを確認しました。戦略的思考のための新しいプロトコルにより、開発ロジックの重大なエラーが排除されます。今後、リソースをめぐる競争のシミュレーションはさらに予測不可能かつ困難なものになるでしょう。入植者は AI パートナーの戦術分析時間を個別に設定できます。

2. 仮想訓練場の統合 新しく到着した入植者は個人訓練シミュレーターにアクセスできます。火星の鉱山をめぐる実際の戦いに入る前に、シングル プレイヤー モードでセクター占領スキルを磨くことができます。このシステムには、最新のトレーニング プロトコルが装備されています。

3. ドーム間の通信チャネルの安定化 通信技術者は衛星群の校正を完了しました。リモート前哨基地間のマルチプレイヤー インタラクション インターフェイスが遅延なく動作するようになりました。戦略的作戦中に接続中断を引き起こした異常は解消されました。

4. 潜在意識の計算: ニューラルトリガーの更新 技術部門は並列コンピューティング システムを導入しました。 AI 戦術データ処理は、個人端末の CPU に負担をかけずにバックグラウンドで実行されるようになりました。ゲームの重要な局面で一時停止する必要はもうありません。

ホスト: 管理者は、ゲーム シミュレーターの新しいバージョンがすでに中央端末にロードされていることをお知らせします。データを同期するには、ローカル インターフェイスを再起動することをお勧めします。

火星の未来はあなたの手の中にあります。 Red Horizo​​n 周波数を引き続きお楽しみください。

https://demensdeum.com/games/mars-miners/

Docker で macOS を実行する

不可能だという人々の反対にもかかわらず、Docker で macOS を実行することは可能であり、おそらく macOS にはこれに抵抗できるある種の保護システムがあると考えられます。

PC マシンで macOS を実行する古典的な方法には、これまで次のようなものがありました。
*ハッキントッシュ
* VMWare を使用した仮想化など

Hackintosh は、オリジナルの Mac と同様または非常に近いハードウェアの存在を前提としています。仮想化ではハードウェアに特定の要件が課されますが、一般的には Hackintosh の場合ほど厳格ではありません。ただし、仮想化の場合、macOS は仮想環境での作業用に最適化されていないため、パフォーマンスの問題が発生します。

最近ではDocker上でmacOSを実行できるようになりました。これは、Docker 上で実行する既製の macOS イメージを提供する Docker-OSX プロジェクトによって可能になります。 Docker-OSX は Apple の公式プロジェクトではなく、サポートされていないことに注意してください。ただし、Docker 上で macOS を実行し、それを使用してアプリケーションの開発とテストを行うことができます。

Docker で macOS を実行する最初のプロジェクトの 1 つ:
https://github.com/sickcodes/Docker-OSX

ただし、完全に起動することはできませんでした。 Recovery OS にロードした後、キーボードとマウスが外れてしまい、インストールを続行できませんでした。同時に、最初のブート メニューではキーボードが機能します。おそらく実際には、このプロジェクトはあまり積極的にサポートされておらず、Windows 11 + WSL2 + Ubuntu で実行すると特定の問題がいくつか発生します。

現在最も活発なプロジェクトの 1 つ:
https://github.com/dockur/macos

Docker で macOS を実行できるようにします。インターフェイスは VNC(?) 転送を介してブラウザ経由で動作します。起動後、macOS は http://localhost:5900 で利用可能になります。

このプロジェクトを実行し、Windows 11 + WSL2 + Ubuntu に macOS Big Sur (2020 分) をインストールすることができましたが、構成ファイルを変更するだけで済みました。

environment:
    VERSION: "11"
    RAM_SIZE: "8G"
    CPU_CORES: "4"

バージョン: 「11」は macOS のバージョンです。この場合は Big Sur
RAM_SIZE: 「8G」は、macOS に割り当てられた RAM の量です。
CPU_CORES: 「4」は macOS に割り当てられた CPU コアの数です。

現時点では、macOS tahoe (16) を実行することも可能ですが、プロジェクト開発者が勇敢に解決しようとしている問題が数多くあります。

macOS を起動するこの独自の方法を使用すると、Mac 以外のハードウェアで macOS を試し、十分に苦労した後、Mac を購入することができます。ただし、古いシステムでのソフトウェアのテストや一般的な開発には役立ちます。

WSL2 で Swift を構築する (Linux)

Swift エコシステムは Apple プラットフォームの外で積極的に開発されており、現在では Windows Subsystem for Linux (WSL2) を使用して Windows 上で Swift エコシステムに書き込むのが非常に快適です。 Linux/WSL でのアセンブリの場合、独自の Apple フレームワーク (SwiftUI、UIKit、AppKit、CoreData、CoreML、ARKit、SpriteKit、その他の iOS/macOS 固有のライブラリなど) なしで、Swift の軽量バージョンが利用可能であることを考慮する価値がありますが、コンソール ユーティリティとバックエンドの場合はこれで十分です。この投稿では、環境を準備し、WSL2 内のソース コードから Swift コンパイラーを構築するプロセスを段階的に説明します (例として Ubuntu/Debian を使用)。

パッケージのリストとシステム自体を更新します。

sudo apt update && sudo apt upgrade -y

ビルドに必要な依存関係をインストールします。

sudo apt install -y \
  git cmake ninja-build clang python3 python3-pip \
  libicu-dev libxml2-dev libcurl4-openssl-dev \
  libedit-dev libsqlite3-dev swig libncurses5-dev \
  pkg-config tzdata rsync

コンパイラとリンカー (LLVM と LLD) をインストールします。

sudo apt install -y llvm lld

すべての依存関係を含む Swift リポジトリのクローンを作成します。

git clone https://github.com/apple/swift.git
cd swift
utils/update-checkout --clone

`swiftly` と既製の swift を swiftc でインストールする

curl -O https://download.swift.org/swiftly/linux/swiftly-$(uname -m).tar.gz && \
tar zxf swiftly-$(uname -m).tar.gz && \
./swiftly init --quiet-shell-followup && \
. "${SWIFTLY_HOME_DIR:-$HOME/.local/share/swiftly}/env.sh" && \
hash -r

ビルドを開始しましょう (これには長い時間がかかります)。

utils/build-script \
  --release-debuginfo \
  --swift-darwin-supported-archs="x86_64" \
  --llvm-targets-to-build="X86" \
  --skip-build-benchmarks \
  --skip-test-cmark \
  --skip-test-swift \
  --skip-ios \
  --skip-tvos \
  --skip-watchos \
  --skip-build-libdispatch=false \
  --skip-build-cmark=false \
  --skip-build-foundation \
  --skip-build-lldb \
  --skip-build-xctest \
  --skip-test-swift

ビルドが完了したら、コンパイラーへのパスを PATH に追加します (ビルド フォルダーへのパスを指定します)。

export PATH=/root/Sources/3rdparty/build/Ninja-RelWithDebInfoAssert/swift-linux-x86_64/bin/swiftc:$PATH

インストールされている Swift のバージョンが動作していることを確認します。

swift --version

テスト ファイルを作成して実行します。

echo "print(\"Hello, World!\")" > hello.swift
swift hello.swift

バイナリをコンパイルして実行することもできます。

swiftc hello.swift
./hello

ソース

テフレッチャー

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

パターンインタープリターの実践

前回の記事では、インタープリター パターンの理論を検討し、AST ツリーとは何か、終端式と非終端式を抽象化する方法を学びました。今回は、理論から離れて、このパターンが私たち全員が毎日使用する本格的な商業プロジェクトにどのように適用されるかを見てみましょう!

ネタバレ: ブラウザでこのテキストを読んでいるだけで、あなたは今 Interpreter パターンを使用している可能性があります。

業界におけるこのパターンの使用例の中で最も印象的で、おそらく最も重要なものの 1 つは JavaScript です。もともと「膝の上で」作成されたこの言語は、今日ではまさに解釈という概念のおかげで何十億ものデバイスで動作します。

インターネットを変えた 10 日間

JavaScript の歴史には伝説がたくさんあります。 1995 年、ネットスケープ コミュニケーションズで働いていたブレンダン アイヒは、ブラウザ (Netscape Navigator) で直接実行して Web ページをインタラクティブにする簡単なスクリプト言語を作成するという任務を与えられました。経営陣は、当時非常に人気があった Java に似た構文を持つものを望んでいましたが、プロのエンジニアではなく、Web デザイナーを対象としていました。

Eich がこの言語の最初のプロトタイプを書くのにわずか 10 日しかありませんでした。この言語は当時 Mocha と呼ばれていました (その後 LiveScript になり、マーケティング上の理由から JavaScript のみになりました)。このラッシュは偶然ではありませんでした。Microsoft はそれに熱心に追随しており、同時に Internet Explorer ブラウザに埋め込むための独自のスクリプト言語VBScript を積極的に準備していました。 Netscape は、迫り来るブラウザ戦争に負けないよう、早急に対応策を発表する必要がありました。

複雑なコンパイラをマシンコードに記述する時間がありませんでした。アイヒにとっての明白かつ最速のソリューションは、古典的なインタプリタのアーキテクチャでした。

最初のインタープリター (SpiderMonkey) は次のように機能しました:

<オル>

  • ページからスクリプトのテキスト ソース コードを読み取ります。
  • 字句アナライザーはテキストをトークンに分割しました。
  • パーサーは抽象構文ツリー (AST) を構築しました。インタプリタ パターンの観点から見ると、このツリーは終端式 (文字列、42 などの数値) と非終端式 (関数呼び出し、If や While などのステートメント) で構成されていました。
  • その後、仮想マシンはこのツリーを段階的に「走査」し、ツリーに埋め込まれた命令を各ノードで実行します (Interpret() と同様のメソッドを呼び出します)。
  • コンテキストとオブジェクト

    従来の実装では Interpret(Context context) メソッドに渡す必要があった Context オブジェクトを覚えていますか?インタプリタは現在のメモリ状態を保存するためにこれを必要とします。

    JavaScript の場合、トップレベルでのこのコンテキストの役割はグローバル オブジェクト (ブラウザのウィンドウなど) によって実行されます。 AST ノードが、たとえば document.write(“Hello”) 経由で画面にテキストを書き込もうとすると、インタプリタはそのコンテキスト (ドキュメント オブジェクト) にアクセスし、目的の内部ブラウ​​ザ API を呼び出します。

    JavaScript が DOM (ドキュメント オブジェクト モデル) と簡単にやり取りできるのは、インタープリタのおかげです。これらはすべて、ツリー ノードによってアクセスされるコンテキスト内の単なるオブジェクトです。

    インタプリタの進化: JIT コンパイル

    歴史的に、ブラウザの JS は長い間「純粋な」インタープリタであり続けてきました。そして、これには速度が遅いという大きな欠点がありました。スクリプトが実行されるたびにツリーを解析し、各ノードをゆっくりと走査すると、複雑な Web アプリケーションの速度が低下しました。

    2008 年の Google の V8 エンジン (Chrome に組み込まれている) の登場により、革命が起こりました。エンジニアは、現代の Web には 1 人のインタプリタでは不十分であることに気づきました。エンジンはより複雑になりました。引き続き AST ツリーを構築しますが、JIT (ジャストインタイム) コンパイルを使用するようになりました。

    最新の JS エンジン (V8、SpiderMonkey) は、複雑なパイプラインのように動作します。

    <オル>

  • 高速かつダムなベース インタープリターは、コンパイルを待つことなく、即座に JS コードの実行を開始します (ここでも古典的なパターンが機能します)。
  • 並行して、エンジンはコードの「ホット」セクション(何千回も呼び出されるループまたは関数)を監視します。
  • これらのセクションは、遅いインタープリタをバイパスし、JIT コンパイラによって最適化されたマシンコードに直接コンパイルされます。
  • インタプリタの即時起動とコンパイルの計算能力の組み合わせにより、JavaScript は世界を席巻し、サーバー (Node.js) やモバイル アプリケーション (React Native) の言語になりました。

    ゲーム業界の通訳

    ヘビー コンピューティングでは C++ が優勢ですが、インタプリタ パターンはゲーム開発におけるゲーム ロジック作成の業界標準です。何のために?これにより、ゲーム デザイナーはエンジンを「ドロップ」するリスクやエンジンを常に再コンパイルする必要がなく、ゲームを作成できます。

    歴史的な優れた例は、UnrealScript です。これは、Unreal Championship および Gears of War ゲームのロジックが Unreal Engine 1、2、3 で記述された言語です。テキストはコンパクトな抽象マシン バイトコードにコンパイルされ、エンジンの仮想マシンによって段階的に (解釈) されます。

    ビジュアル グラフ スクリプト (ブループリント)

    現在、テキストはビジュアル プログラミング、つまり Unreal Engine 4 および 5 のブループリント システムに置き換えられています。

    Unreal Engine でブループリントを開いたことがあれば、多くのノードがワイヤで接続されているのを見たことがあるでしょう。アーキテクチャ的には、ブループリント グラフ全体が画面上に描画される巨大な抽象構文ツリー (AST) です

    <オル>

  • ターミナル式: 定数ノード。たとえば、単純に数字 42 または文字列を格納するノードです。解釈されると特定の値を返します。
  • 非端末式: 計算ノード (追加) またはフロー制御ノード (分岐)。これらには引数入力があり、インタープリタは結果を出力ピンとして生成する前に、最初に再帰的に評価します。
  • ここでのコンテキストの役割は、特定のゲーム オブジェクト (アクター) のインスタンスのメモリによって果たされます。インタプリタ マシンはこのグラフ内を安全に「ウォーク」し、データをリクエストして遷移を実行します。

    インタープリタは他にどこで使用されますか?

    インタプリタ パターンは、動的な命令を実行する必要があるほとんどすべての複雑なシステムに見られます。以下に商用ソフトウェアの例をいくつか示します。

    • インタープリタ型プログラミング言語 (Python、Ruby、PHP)。 ランタイム全体は古典的なパターンに基づいています。たとえば、CPython リファレンス実装では、まず .py スクリプトを AST に解析し、バイトコードにコンパイルしてから、巨大な仮想マシン (コンピューティング ループ) がそのバイトコードを段階的に解釈します。
    • Java 仮想マシン (JVM)。 最初、Java コードは機械語命令ではなくバイトコードにコンパイルされます。アプリケーションを実行すると、JVM はインタープリターとして機能します (ただし、V8 と同様に積極的な JIT コンパイルが行われます)。
    • データベースと SQL PostgreSQL または MySQL で SQL クエリ (SELECT * FROM ユーザー) を発行すると、データベース エンジンがインタープリタとして機能します。字句解析を実行し、AST クエリ ツリーを構築し、実行プランを生成して、テーブルの行を反復処理することでこのプランを文字通り「解釈」します。
    • 正規表現 (RegEx)。 正規表現エンジンは内部で文字列パターン (^\d{3}-\d{2}$ など) を解析して状態グラフ (NFA/DFA オートマトン) にし、内部インタープリタがそれを通過させて、各入力文字をこのグラフの頂点と照合します。
    • Unity シェーダー グラフ / アンリアル マテリアル エディタ – ビジュアル ノードをモジュラー シェーダー コード (GLSL/HLSL) に解釈します。
    • Blender ジオメトリ ノード – 数学的および幾何学的演算を解釈して、リアルタイムで手続き的に 3D モデルを生成します。

    合計

    Interpreter パターンは、「独自の計算機を作成する」という範囲をはるかに超えています。これは最も強力な業界標準です。毎日ブラウザの舞台裏でギガバイトのコードを実行する JavaScript エンジンから、C++ の知識がなくても複雑なロジックを構築できるゲーム デザイナーに至るまで、インタプリタは依然として現代の IT 開発において最も重要なアーキテクチャ概念の 1 つです。

    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

    プロジェクトは開発を続けており、フィードバックをお待ちしております。

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

    In the dim, neon-flickering depths of the digital underworld, a new challenge awaits. We are excited to pull back the curtain on Flame Steel: Death Mask 2, a multiplayer 3D dungeon crawler that blends retro-cyberpunk aesthetics with modern real-time gameplay.

    🕹️ What is Flame Steel: Death Mask 2?

    Imagine waking up in a procedurally generated maze where every shadow could be another player or a hostile “Filter” entity. Flame Steel: Death Mask 2 puts you in the boots of a Seeker, navigating a world built on the Flame Steel Engine 2 and Three.js.

    The game is currently in its early stages of development, but the core experience is already live and ready for exploration.

    🚀 Key Features

    • Multiplayer Exploration: You aren’t alone in the grid. See other players in real-time as you navigate the labyrinthine corridors.
    • Procedural Dungeons: No two runs are the same. The server generates fresh maps filled with mystery and danger.
    • The Terminal: For those who prefer a more “hands-on” approach, an integrated command-line interface allows you to interact with the system directly—perform advanced actions, debug, or simply chat with fellow Seekers.
    • Combat & Survival: Face off against Filters to earn bits, then use those bits to unlock Chests and upgrade your stats. Keep an eye on your health; survival isn’t guaranteed.
    • Retro-Cyberpunk Aesthetic: High-contrast visuals and a gritty atmosphere that pays homage to the classic cyberpunk era.

    🛠️ The Tech Behind the Mask

    Built for the browser, the game leverages:

    • Frontend: Vanilla JavaScript and Three.js for smooth 3D rendering.
    • Backend: Node.js and WebSockets (ws) for lightning-fast multiplayer synchronization.
    • Infrastructure: MongoDB for data persistence and Redis for real-time spatial indexing.

    🗺️ What’s Next?

    We are just getting started. As an early-access project, Death Mask 2 will receive frequent updates, including:

    • New entity types and complex combat mechanics.
    • Deeper lore and environmental storytelling.
    • Enhanced terminal commands and social features.
    • Visual and performance polish.

    🔗 Join the Grid

    Want to test your mettle? Enter your codename and initialize your identity today:

    👉 Play Flame Steel: Death Mask 2

    Stay tuned for more updates as we continue to expand the digital frontier. Welcome to the service. It requires you.

    ウシュキ ラジオ Google Play

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

    Google Play でのリリース:

    https://play.google.com/store/apps/details?id=com.demensdeum.ushkiradio

    ウシュキラジオ

    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

    カバー

    Coverser – LLM を使用したインテリジェントなプロセス オブザーバー

    Coverseer は、プロセスをインテリジェントに監視し、自動的に再起動するための Python CLI ツールです。従来のウォッチドッグ ソリューションとは異なり、LLM モデルを使用してアプリケーションのテキスト出力を分析し、終了コードだけでなくコンテキストに基づいて決定を行います。

    このプロジェクトはオープンソースであり、GitHub で入手できます。
    https://github.com/demensdeum/coverseer

    カバーサーとは

    Coverseer は、指定されたプロセスを開始し、その stdout と stderr を継続的に監視し、出力の最新のチャンクを (Ollama 経由で) ローカル LLM に供給し、プロセスが正しい実行状態にあるかどうかを判断します。

    モデルがエラー、フリーズ、または不正な動作を検出した場合、Coverseer はプロセスを自動的に終了し、再度プロセスを開始します。

    主な機能

    • 出力のコンテキスト分析 – 終了コードをチェックする代わりに、LLM を使用してログ分析が使用されます
    • 自動再起動 – 問題または異常終了が検出されるとプロセスが再起動されます
    • ローカル モデルの操作 – データを外部サービスに転送せずに、Ollama を使用します
    • 詳細なログ – すべてのアクションと決定が後続の診断のために記録されます
    • スタンドアロン実行 – 単一の実行可能ファイル (.exe など) にパッケージ化できます

    仕組み

    <オル>

  • Coverser は CLI 経由で渡されたコマンドを実行します
  • プロセスからのテキスト出力を収集してバッファリングします
  • 最後の行を LLM モデルに送信します
  • プロセス状態のセマンティック評価を取得します
  • 必要に応じて、プロセスを終了して再起動します
  • このアプローチにより、標準の監視ツールでは検出できない問題を特定できます。

    要件

    • Python 3.12 以降
    • Ollama がインストールされ実行中
    • ロードされたモデル gemma3:4b-it-qat
    • Python の依存関係: リクエストollama-call

    使用例

    <コード>
    python coverseer.py “ここにコマンドを入力してください”

    たとえば、Ollama モデルのロードを観察すると、次のようになります。

    <コード>
    python coverseer.py “ollama pull gemma3:4b-it-qat”

    Coverers はコマンド出力を分析し、失敗やエラーに自動的に対応します。

    実際の応用

    Coverers は、標準のスーパーバイザ メカニズムが不十分なシナリオで特に役立ちます。

    • CI/CD パイプラインと自動ビルド
    • バックグラウンド サービスとエージェント
    • 実験的または不安定なプロセス
    • 大量のテキスト ログを含むツール
    • 自己修復が重要な開発環境

    LLM アプローチがより効果的である理由

    従来の監視システムは症状に対応します。 Coverser は行動を分析します。 LLM モデルは、プロセスが形式的に動作し続けている場合でも、エラー、警告、繰り返される障害、論理的な行き詰まりを認識できます。

    これにより、監視がより正確になり、誤警報の数が減少します。

    結論

    Coverseer は、DevOps および自動化タスクにおける LLM の実際的な応用例です。これは、プロセス監視の従来の理解を拡張し、よりインテリジェントなコンテキストベースのアプローチを提供します。

    このプロジェクトは、AI ツールを実験し、インフラストラクチャを複雑にすることなくシステムの安定性を向上させる方法を探している開発者にとって特に興味深いものとなるでしょう。

    フレームスチール: マーズマイナーズ

    Flame Steel: Mars Miners は、異常なペースと反射神経よりも意思決定に重点を置いた戦術的戦略ゲームです。このゲームは火星で行われ、プレイヤーは限られた情報とライバルからの絶え間ない圧力に直面しながら、資源と領土の支配をめぐって競い合います。

    ゲームプレイは、遠征のインフラを形成するハブ ステーションの建設に基づいています。ノードを使用すると、リソースを抽出し、影響範囲を拡大し、兵站を構築できます。すべての配置が重要です。1 つのミスが敵の主要セクターへの道を開いたり、戦略的優位性を奪ったりする可能性があります。

    ゲームのリズムは意図的にコントロールされており、激しいものです。これはチェス、囲碁、海戦の中間のようなものです。ここでは位置取り、相手の行動の予測、そして不確実性を扱う能力が重要です。マップの一部と敵の意図は隠されたままなので、成功は計算だけでなく状況の読み取りに依存します。

    Flame Steel: Mars Miners はオンライン プレイをサポートしており、それが各ゲームをユニークなものにしています。戦略は進化し、メタは現在形成されています。このゲームは開発の初期段階にあり、これがこのゲームの強みです。プレイヤーには、最初に新しい非標準プロジェクトに飛び込み、その開発に影響を与え、ジャンルの通常のテンプレートをコピーしないメカニズムを発見する機会があります。

    深み、実験的なデザイン、思考力を重視した戦術ゲームに興味があるなら、Flame Steel: Mars Miners を今すぐチェックする価値があります。

    ゲームルール

    * プレイフィールドは、プレイヤーがオブジェクトを 1 つずつ配置するセルで構成されます。各ターン、プレイヤーは 1 つの建設アクションを実行できます。

    * ハブ ステーションと鉱山の 2 種類のオブジェクトのみを建設できます。あらゆる構築は、既存のプレイヤー ノードの垂直方向または水平方向に隣接する 1 つのフリー セル上でのみ可能です。斜めに配置することはできません。

    * ハブステーションはテリトリーコントロールの基礎を形成し、拡張ポイントとして機能します。地雷は同じルールに従って配置されますが、リソース オブジェクトとしてカウントされ、パーティーの最終結果に直接影響します。

    * プレイヤーが自分のノードステーションを縦または横に連続したラインを構築すると、そのラインは自動的に武器に変わります。この武器により、敵を攻撃し、インフラを破壊することが可能になります。

    * 銃を発砲するには、プレイヤーは自分の銃に属する 1 つのセルを選択し、フィールド上の任意の敵ノード ステーションをポイントします。選択した敵ノードステーションは破壊され、プレイフィールドから削除されます。地雷を直接攻撃することはできません。地雷へのアクセスを提供するノードを破壊することによってのみ可能です。

    ※ゲームは設定されたゲーム終了まで継続します。勝者は、現時点で競技場上に最も多くのリソース鉱山を持っているプレーヤーです。互角の場合は、縄張り制圧やゲームモードによる追加条件が決め手となる場合がある。

    https://mediumdemens.vps.webdock.cloud/mars-miners

    反重力

    数日で、Antigravity の助けを借りて、Masonry-AR バックエンドを PHP + MySQL から Node.js + MongoDB + Redis -> Docker に移行しました。 AI の機能は本当に驚くべきもので、2022 年に ChatGPT 経由で shadertoy.com で最も単純なシェーダーを作成したときのことを覚えていますが、このおもちゃではそれ以上のことはできないように思えました。
    https://www.shadertoy.com/view/cs2SWm

    4 年後、私は、約 10 回のプロンプトで、プロジェクトをあるバック プラットフォームから別のプラットフォームに簡単に移行し、コンテナ化を追加する様子を観察しました。
    https://mediumdemens.vps.webdock.cloud/masonry-ar/

    かっこいい、本当にかっこいい。

    カバンボード

    KabanBoard は、カンバン形式でタスクを管理するためのオープンソース Web アプリケーションです。このプロジェクトは、シンプルさ、理解しやすいアーキテクチャ、およびチームまたは個々の開発者の特定のタスクに合わせた変更の可能性に焦点を当てています。

    このソリューションは、小規模プロジェクト、内部チーム プロセス、またはサードパーティの SaaS サービスに縛られない独自の製品の基盤として適しています。

    プロジェクト リポジトリは GitHub で入手できます。
    https://github.com/demensdeum/KabanBoard

    主な機能

    KabanBoard は、カンバン ボードを操作するための基本的かつ実用的な関数セットを実装しています。

    • さまざまなプロジェクトに複数のボードを作成する
    • タスクのステータスを含む列構造
    • 編集および削除できるタスク カード
    • 列間でのタスクの移動 (ドラッグ アンド ドロップ)
    • カードの色分け
    • ダークインターフェーステーマ

    機能は過負荷ではなく、タスクを伴う日常的な作業に重点を置いています。

    使用されているテクノロジー

    プロジェクトは、共通でわかりやすいスタックに基づいて構築されています。

    • フロントエンド:Vue 3、Vite
    • バックエンド: Node.js、Express
    • データ ストレージ: MongoDB

    クライアント部分とサーバー部分が分離されているため、プロジェクトのサポートとさらなる開発が簡素化されます。

    プロジェクトの展開

    ローカルで実行するには、標準環境が必要です。

    • Node.js
    • MongoDB (ローカルまたはクラウド経由)

    プロジェクトは、npm を介して通常モードで起動することも、Docker を使用して起動することもできます。これは、テスト環境または内部環境での迅速なデプロイメントに便利です。

    実際の応用

    KabanBoard はさまざまなシナリオで使用できます。

    • 社内タスク管理ツール
    • カスタム カンバン ソリューションの基礎
    • SPA アーキテクチャを学ぶためのトレーニング プロジェクト
    • 重要なプロジェクトまたはポートフォリオの開始点

    結論

    KabanBoard は、カンバン ボードを操作するための洗練された実用的なソリューションです。このプロジェクトは大企業システムを置き換えるものではありませんが、小規模チーム、個人での使用、特定のタスクのさらなる開発に適しています。

    ゴフィス

    Gofis は、ファイル システム内のファイルを迅速に検索するための軽量のコマンド ライン ツールです。
    Go で書かれており、並列処理 (ゴルーチン) を多用しているため、特に効率的です。
    大規模なディレクトリやプロジェクトを操作する場合。

    プロジェクトは GitHub で入手できます。
    https://github.com/demensdeum/gofis

    🧠 Gofis とは

    Gofis は、名前、拡張子、または正規表現でファイルを検索するための CLI ユーティリティです。
    find のような古典的なツールとは異なり、gofis は独自に設計されました
    速度、読みやすい出力、およびディレクトリの並列処理に重点を置いています。

    プロジェクトは MIT ライセンスに基づいて配布されており、自由に使用できます
    個人的および商用目的。

    ⚙️ 主な機能

    • ゴルーチンを使用した並列ディレクトリ トラバーサル
    • ファイル名と正規表現で検索
    • 拡張子によるフィルタリング
    • 重いディレクトリ (.git、node_modules、vendor) を無視する
    • 人間が判読できるファイル サイズの出力
    • 最小限の依存関係と高速なビルド

    🚀 インストール

    動作するには Go がインストールされている必要があります。

    git clone https://github.com/demensdeum/gofis
    cd gofis
    go build -o gofis main.go
    

    ビルドしたら、バイナリを直接使用できます。

    リリース ページには、Windows の最新バージョン用のスタンドアロン バージョンもあります。
    https://github.com/demensdeum/gofis/releases/

    🔍 使用例

    ファイルを名前で検索します。

    ./gofis -n "config" -e ".yaml" -p ./src
    

    クイック位置検索:

    ./gofis "main" "./projects" 50
    

    正規表現を使用して検索します。

    ./gofis "^.*\.ini$" "/"
    

    🧩 仕組み

    Gofis は Go の競争モデルに基づいています。

    • 各ディレクトリは個別の goroutine で処理されます
    • セマフォを使用してアクティブなタスクの数を制限します
    • チャネルは検索結果の送信に使用されます

    このアプローチにより、CPU リソースを効率的に使用できます。
    また、大きなファイル ツリーの検索が大幅に高速化されます。

    👨‍💻 Gofis は誰に適していますか?

    • 大規模なリポジトリを扱う開発者
    • DevOps およびシステム管理者
    • 端末から簡単に検索する必要があるユーザー
    • Go での同時実行性の実践的な使用法を学習している人向け

    📌 結論

    Gofis は、1 つのことをうまく実行できる、シンプルですが効果的なツールです。
    大規模なプロジェクトでファイルを頻繁に検索し、速度を重視する場合は、
    この CLI ツールは一見の価値があります。

    オラマコール

    Ollama を使用していて、毎回独自の API ラッパーを作成したくない場合は、
    ollama_call プロジェクトにより、作業が大幅に簡素化されます。

    これは、1 つの関数でローカル LLM にリクエストを送信できる小さな Python ライブラリです。
    JSON 形式などの応答をすぐに受け取ります。

    インストール

    pip install ollama-call
    

    なぜ必要なのか

    • モデルを操作するための最小限のコード;
    • さらなる処理のための構造化された JSON レスポンス;
    • ラピッドプロトタイプや MVP に便利です。
    • 必要に応じてストリーミング出力をサポートします。

    使用例

    from ollama_call import ollama_call
    
    response = ollama_call(
        user_prompt="Hello, how are you?",
        format="json",
        model="gemma3:12b"
    )
    
    print(response)
    

    特に役立つ場合

    • Ollama 上でスクリプトまたはサービスを作成します。
    • 予測可能な応答形式が必要です。
    • 重いフレームワークを接続する必要はありません。

    合計

    ollama_call は、Python から Ollama を操作するための軽量で明確なラッパーです。
    シンプルさと迅速な結果が重要な場合に適した選択です。

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

    SFAP: 最新のデータ取得と処理のためのモジュール式フレームワーク

    自動化と人工知能の積極的な開発の文脈において、効果的に収集するタスクは、
    データのクリーニングと変換が重要になります。ほとんどのソリューションは閉じるだけです
    このプロセスの別々の段階では、複雑な統合とサポートが必要になります。

    SFAP (シーク・フィルター・適応・公開) は、Python のオープンソース プロジェクトです。
    これは、ライフサイクルのすべての段階でデータを処理するための総合的かつ拡張可能なアプローチを提供します。
    ソースの検索から完成した結果の公開まで。

    SFAP とは

    SFAP は、データ処理パイプラインの明確な概念に基づいて構築された非同期フレームワークです。
    各ステージは論理的に分離されており、独立して拡張または置換できます。

    このプロジェクトは責任連鎖アーキテクチャ パターンに基づいており、次の機能が提供されます。

    • パイプライン構成の柔軟性
    • 個々のステージの簡単なテスト
    • 高負荷に対するスケーラビリティ
    • コンポーネント間の責任を明確に分離する

    パイプラインの主なステージ

    シーク – データ検索

    この段階では、Web ページ、API、ファイル ストレージなどのデータ ソースが検出されます。
    または他の情報の流れ。 SFAP により、変更せずに新しいソースに簡単に接続できます
    システムの残りの部分。

    フィルタ – フィルタリング

    フィルタリングは、無関係なコンテンツ、重複、技術的要素などのノイズを除去するように設計されています。
    そして低品質のデータ。これは後続の処理ステップにとって重要です。

    適応 – 適応と処理

    適応ステージは、正規化、構造化、データ変換などのデータ変換を担当します。
    セマンティック処理と AI モデル (生成モデルを含む) との統合。

    発行 – 出版

    最終段階では、データはデータベース、API、ファイル、外部サービスなどのターゲット形式で公開されます。
    またはコンテンツプラットフォーム。 SFAP は、結果の配信方法を制限しません。

    プロジェクトの主な特徴

    • asyncio に基づく非同期アーキテクチャ
    • モジュール性と拡張性
    • 複雑な処理パイプラインのサポート
    • AI/LLM ソリューションとの統合の準備ができている
    • 高負荷のシステムに適しています

    実際の使用例

    • ニュースソースの集約と分析
    • 機械学習用のデータセットを準備する
    • 自動化されたコンテンツ パイプライン
    • 大規模なデータ ストリームのクレンジングと正規化
    • 異種ソースからのデータの統合

    SFAP を使ってみる

    始めるために必要なのは次のとおりです。

    <オル>

  • プロジェクト リポジトリのクローンを作成します。
  • Python の依存関係をインストールします。
  • 独自のパイプライン ステップを定義します。
  • 非同期データ処理プロセスを開始します。
  • プロジェクトは特定のビジネス タスクに簡単に適応でき、システムとともに成長することができます。
    一枚岩にならずに。

    結論

    SFAP は単なるパーサーやデータ コレクターではなく、構築のための本格的なフレームワークです。
    最新のデータ パイプライン システム。を重視する開発者やチームに適しています。
    スケーラブルで、アーキテクチャ的にクリーンで、データ対応が可能です。
    プロジェクトのソース コードは GitHub で入手できます。
    https://github.com/demensdeum/SFAP

    FlutDataStream

    デバイス間の高速データ ストリーミングのために、あらゆるファイルを機械可読コードのシーケンス (QR および DataMatrix) に変換する Flutter アプリ。

    特徴
    * デュアル エンコーディング: 各データ ブロックを QR コードと DataMatrix コードの両方として表します。
    *高速ストリーミング: 最大 330ms の自動切り替え間隔をサポートします。
    * スマート チャンク: ファイルをカスタム チャンクに自動的に分割します (デフォルト: 512 バイト)。
    * 詳細スキャナ: デバッグと即時フィードバックのためにリアルタイムで ASCII コードを読み取ります。
    * 自動回復: ファイルを即座に回復し、ダウンロード ディレクトリに保存します。
    * システム統合: 完了後、デフォルトのシステム アプリケーションを使用して保存されたファイルを自動的に開きます。

    https://github.com/demensdeum/FlutDataStream

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

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

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

    「偽症状」の罠

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

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

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

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

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

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


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

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

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

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

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

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


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

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

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

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

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


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

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

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

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

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

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

    概要

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

    フェラル

    Ferral は、大規模言語モデル (LLM) からコードを生成するために特別に設計された高レベルのマルチパラダイム プログラミング言語です。従来の言語は人間工学を念頭に置いて設計されていましたが、Ferral は大規模言語モデル (LLM) が論理を推論、トークン化し、推論する方法に最適化されています。

    名前は 2 つの R で綴られており、AI によって生成されたコードの予測不可能な性質に対する「再考された」アプローチを示しています。

    https://github.com/demensdeum/ferral

    ドリーチャット

    DoryChat は、保持ゼロのアーキテクチャ モデルに基づいて構築された、安全で永続的なインスタント メッセージング プラットフォームです。メッセージは一時的にエンドツーエンドで暗号化され、60 秒後に自動的に削除されるため、中央インフラストラクチャに会話の痕跡は残りません。

    https://github.com/demensdeum/DoryChat
    https://mediumdemens.vps.webdock.cloud/dorychat-app