テレビヘッドNFTを損なう

私の新しいプロジェクトであるNFTコレクション「Demens TV Heads」を共有したいと思います。

これは一連のデジタルアート作品であり、Demensdeumのロゴのスタイルで、さまざまなキャラクターや職業の人々を反映しています。
最初の作品は激しい「グロズニー」です。

私は毎月12個のNFTのみをリリースする予定です。

各作業は、Ethereumブロックチェーンだけでなく、MetadanとともにDemensdeumのWebサイトやGithub-Roadsでも利用できます。

興味がある場合は、視覚的に見た場合、または単に評価してください。
https://opensea.io/collection/demens-tv-heads
https://github.com/demensdeum/demens-tv-heads-collection
https://demensdeum.com/collections/demens-tv-heads/fierce.png
https://demensdeum.com/collections/demens-tv-heads/fierce-metadata.txt

スーパープログラマー

彼は誰ですか – この神秘的ではかない、ほとんど神話上のスーパープログラマーですか?コードが初めてコンパイルされた人がハーフパイクから起動し、すぐに製品に入ります。伝説は、SenorからJunにバイトで送信されました。他の人が退屈しないようにバグを具体的に書く人。正直に言って、暖かさと皮肉なことに、彼がこのデジタルマントを着用するために必要な超大国を把握します。

1.統一された脆弱性なしでC/C ++について書いてください
バッファオーバーフロー?聞いたことがない。
C ++のスーパープログラマーには、不便な変数がありません。それら自体は尊重から初期化されています。彼はNew Char [256]を書いており、コンパイラは境界のチェックを静かに追加します。他の人がブレークポイントを置く場所 – 彼は一目で。そしてバグは消えます。

2。バグやテストのないフィッチを書いてください
彼はテストを必要としません。彼のコードは、彼が眠る夜に自分自身をテストします(ただし…彼は眠りますか?)。任意のラインは最終的な安定したバージョンであり、すぐに12の言語とNASAアクセス可能なレベルをサポートします。そして、バグがまだ出くわした場合、宇宙は彼をテストしています。

3. AIよりも速く動作します
ChatGptが「なんて良い質問だ!」と印刷している間、スーパープログラマーはすでに新しいOSをロックし、それをトースターに移植し、図でマークダウンのすべてを文書化しました。彼はStackoverflowを尋ねません – 彼は未来からの彼の質問で彼をサポートします。 GPTは彼のコミュニティで勉強しています。

4。彼は著者よりも他の誰かのコードをよく理解しています
「もちろん、私はそれを書きました…しかし、私はそれがどのように機能するのか理解していません。」 – 普通の著者。
「ああ、これは894行目の再帰コールによるものです。これは、正規表現フィルターの副作用に関連しています。スマート。」 – 点滅することなくスーパープログラマー。
彼は最初の試みでPerlを読み、変数の名前の略語を理解し、カーソルの振動によってバグをキャプチャします。

5.アセンブラーにクロスプラットフォームコードを書き込みます
純粋なx86、arm、risc-vにすぐに錆を書くのはなぜですか、「どこでも機能する」旗が旗がありますか?彼は彼自身の敵のテーブルを持っています。 CPUでさえ、彼の指示を台無しにする前に考えています。彼は最適化しません – 彼は超越します。

6.彼は締め切りについての質問に1秒まで答えます
「いつ準備ができているの?」
「2時間後、17分8秒後。そして、はい、これはチャットでのバグ、煙の休憩、1つの哲学的な質問を考慮に入れています。」
誰かがより速くするように頼むなら、彼は単に時空をmake -jivesで再構築します。

7.独自のフレームワークの逆転と修復
独自のSDKは、ドキュメントなしでAPIから落ちました。すべてがbase92とCoughs segfaultの暗号化されていますか?スーパープログラマーにとって、これは普通の火曜日です。彼はバイナリ、吸入16進を開き、1時間後に修正、パフォーマンスの改善、ダークモードを追加したパッチがあります。

8。デザイナーとUXスペシャリスト自身
UIは、人々が美しさで泣き、ボタンが直観によって推測されるという彼のために出てきます。猫でさえ対処します – 検証されました。彼はインターフェースを描きません – 彼は大理石の彫刻家のように彼の内なる本質を開きます。各プレスは喜んでいます。

9。コミット間でマーケティング調査を実施します
Git PushとCoffee Breakの間に、彼は市場分析を収集し、販売目標到達プロセスを構築し、収益化戦略を再考することができます。週末のテスト仮説。彼はラップトップを開くとA/Bテストが自動的に起動されます。

10。Microsoftを単独で繰り返します
金曜日の夕方と良いピザ。 Windows11? Windows12。Office?すでにそこに。エクセル?彼は音声管理に取り組んでおり、休暇を計画するのに役立ちます。すべてがうまく機能し、重量が少なくなります。

11. 100万人のユーザーのインフラストラクチャを展開およびサポートします
彼の自家製NASはクベルネテスの崖です。監視?ミームのあるグラファナ。一部の人が郵便配達員を開くことができるよりも速くAPIを展開します。彼は、ソビエトのティーポットのように、すべてを文書化し、自動化し、確実に文書化しています。

12。技術サポートは必要ありません
ユーザーはそれについて文句を言いません。彼らはただ敬意を持ってそれを使用します。よくある質問?必要ありません。チュートリアル?直感がわかります。彼は、感謝のページに「ヘルプ」ボタンを持っている唯一の開発者です。

13。彼は眠らず、食べず、気を散らしません
彼はカフェインとコードを書きたいという純粋な欲求を食べています。睡眠の代わりに、リファクタリング。食べる代わりに、debianパッケージ。彼のライフサイクルは継続的な開発サイクルです。 CI/CDはパイプラインではなく、これはライフスタイルです。

14.痛みのない顧客とコミュニケーションをとる
「私たちは2日間でUberを作る必要がありますが、より良いだけです。」 – 「見てください:ここにロードマップがあります。ここにリスクがあります。ここにMVPがあります。最初に目標を決定しましょう。」
彼は、顧客が答えてくれるように「いいえ」と言う方法を知っています。「ありがとう、今私は私が欲しいものを理解しています。 「

15.即座に原子炉をプログラムします
ウラン核が分割されているとき、どのくらいの熱が放出されますか?スーパープログラマーは知っています。そして、彼はそれを錆、c、迅速で、さらにはエクセルで盗む方法を知っています。その原子炉は安全であるだけでなく、OTAによって更新されます。

16。すべての可能な分野で知識を持っています
哲学、物理学、モンゴルの税報告 – 彼の頭の中のすべて。彼は彼がリーダーであるクイズに参加しています。彼が何かを知らない場合、彼は単に新しい知識のためのスペースを作るために一時的に記憶をオフにしました。今、それは戻ります。

17.すべてのアルゴリズムと設計パターンを知っています
*、dijkstra、またはSingletonがどのように機能するかを彼に説明する必要はありません。彼は彼らを思いついた。彼と一緒に、パターンは正しく動作します。アンチパットターンでさえ、恥から自分で修正されます。

18。Apple、Google、およびLeft Boredomで働いていました
彼はどこにでもいました:Apple、Google、NASA、IKEA(キャビネットインターフェイスをテストしました)。それから私はそれがすでにあまりにも良すぎることに気づき、喜びのために無料のオープンソースプロジェクトを開発しに行きました。彼はお金を必要としません。

19。彼はポンティッドビットコインを持っていて、彼は中本at島です
はい、それは彼です。言うだけではありません。何百万ものBTCを備えたすべての財布は、実際には彼のフラッシュドライブにあり、コンクリートで囲まれています。それまでの間、彼は「Kotlin Multiplatformを試してみるのは面白かった」ので、アウトバックの農民協同組合のためにバックエンドを書いています。

結論:少し深刻さ
実際、プログラマーは普通の人です。
私たちは間違っています。疲れます。時々、私たちは自分自身に非常に自信を持っているので、私たちは明らかなことを見ません – そして、その歴史の中で最も高価な間違いがなされているのはそうです。

したがって、覚えておく価値があります:

*すべてを知ることは不可能です – しかし、どこを見るべきかを知ることが重要です。
*チームで働くことは弱点ではなく、より良い決定への道です。
*私たちを保護するツールは「松葉杖」ではなく、鎧です。
*質問は正常です。疑うことは正しいです。間違いを犯すことは避けられません。学習が必要です。
*皮肉は私たちの盾です。コードは私たちの武器です。責任は私たちのコンパスです。

そして、スーパープログラマーについての伝説は、私たち全員が時々不可能のために努力していることを思い出させます。そして、これはまさにこれにあります – 本当のプログラミングマジック。

なぜドキュメントがあなたの親友であるのか

(そして、更新後にアドバイスが機能することをやめない第一人者にならない方法)

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

新しいフレームワークの作業を開始して、「今、私はすべてを理解します、ドキュメントはボアのためのものです」と考えているなら、あなたは間違いなく一人ではありません。多くの開発者には自然な本能があります。最初に試してみるだけです – 読んでください。これで問題ありません。

しかし、この段階では、正しい道を簡単にオフにして、コードが機能する状況にいることに気付くことができます…しかし、今日だけ、「私は持っています」。

なぜ「把握する」のが簡単なのはなぜですか?それだけでは不十分ですか?

Freimvorkiは、特に閉じた独自のもので、複雑で多層です。彼らは多くの隠されたロジック、最適化、および実装機能を持っています。

*文書化されていません。
*保証されていません。
*いつでも変更できます。
*商業的な秘密であり、特許によって保護できます
*フレームワークの開発者にのみ知られているバグ、欠陥が含まれています。

「Hunchで」行動すると、明確に記載されているルールをサポートする代わりに、ランダムな観測でアーキテクチャを簡単に構築できます。これは、コードが更新やエッジケースに対して脆弱になるという事実につながります。

ドキュメントは制限ではありませんが、サポート

フレームワークの開発者は、理由でマニュアルを作成します – これはあなたとそれらの間の合意です。あなたがドキュメントの一部として行動している間、彼らは約束します:

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

あなたがこのフレームワークを超えているなら、次に起こるすべてがあなたの責任のみになります。

実験?確かに。しかし、ルールのフレームワークでは。
好奇心は開発者のスーパービアです。探索、標準以外のテスト境界を試してください – これはすべて必要です。しかし、重要な「しかし」があります:

ドキュメントとベストプラクティスのフレームワークで実験する必要があります。

文書は刑務所ではなく、カードです。彼女は、どのような機会が本当に計画され、サポートされているかを示しています。有用であるだけでなく、安全なのはそのような実験です。

注意:第一人者

時々あなたは本当の「専門家」に出会うかもしれません:

*彼らはコースを実施します
*会議で演奏する、
*本やブログを書く、
*フレームワークに「彼らのアプローチ」を共有しました。

しかし、たとえ彼らが説得力があるように聞こえたとしても、覚えておくことが重要です:
彼らのアプローチがドキュメントに反している場合、彼らは不安定です。

このような「経験的パターン」は次のとおりです。

*フレームワークの特定のバージョンでのみ動作します。
*更新に対して脆弱になります。
*予測不可能な状況で壊れます。

グルはマニュアルを尊重するときはかっこいいです。それ以外の場合、彼らのヒントは公式の文書を通してフィルタリングする必要があります。

少し固体

堅実な原則からの3つのアイデアがここで特に関連しています:

*オープン/クローズド原理:パブリックAPIを介して動作を拡張し、内側に入らないでください。
* Liskov Sustitionの原則:実装に依存せず、契約に依存してください。障害 – 実装を交換すると、すべてが破壊されます。
*依存関係の反転:高レベルのモジュールは、低レベルモジュールに依存してはなりません。両方のタイプは抽象化に依存する必要があります。抽象化は詳細に依存してはなりません。詳細は抽象化に依存する必要があります。

これは実際にはどういう意味ですか?フレームワークを使用し、その内部の詳細に直接結び付けられている場合、この原則に違反します。
代わりに、フレームワークが公式にサポートするパブリックインターフェイス、プロトコル、契約への依存を構築する必要があります。これは次のとおりです。

*フレームワークの変更からのコードの最良の分離。
*依存関係を簡単にテストして置き換える機能。
*アーキテクチャの予測可能な動作と安定性。

コードが抽象化ではなく詳細に依存している場合、いつでも消えたり変更されたりする可能性のある特定の実装に文字通り自分自身を埋め込みました。

そしてバグの場合は?

あなたがすべてを正しくしたことが起こることもありますが、それは間違って動作します。これは起こります – フレームワークは完璧ではありません。この場合:

*最小の複製例を収集します。
*ドキュメントされたAPIのみを使用していることを確認してください。
*バグポートを送る – 彼らは間違いなくあなたを理解し、おそらく助けになるでしょう。

この例がハッキングまたはバイパスに基づいて構築されている場合、開発者はそれをサポートする必要はなく、おそらくあなたのケースは単に見逃します。

フレームワークから最大を絞る方法

*ドキュメントをお読みください。真剣に。
*著者からのガイドと推奨事項に従ってください。
*実験 – ただし、説明されています。
*マニュアルからヒント(最も有名なスピーカーでさえ!)を確認してください。
*最小限のケースと契約の尊重でバグを折ります。

結論

Freimvorkiはブラックボックスではなく、使用規則を備えたツールです。それらを無視するということは、「ランダムに」コードを書くことを意味します。しかし、私たちはコードを長い間生き、ユーザーを喜ばせ、マイナーなアップデートから脱却しないようにしたいと考えています。

だから:信頼しますが、チェックしてください。そして、はい、マニュアルを読んでください。彼らはあなたの超大国です。

ソース

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

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

会う – キューブアートプロジェクト2

Station Editorの2番目のバージョンは、WebAssemblyなしでPure JavaScriptで完全に書き換えられました。
軽く、高速で、ブラウザで正しく開始します – それ以上のものはありません。

これは実験です:キューブ、色、自由、そして少し瞑想的な3Dジオメトリ。
RGB-Slodersを使用して色を変更し、シーンを保存してロードし、スペースを移動して遊ぶことができます。

コントロール:
-WASD-カメラを移動します
– マウス – 回転
-GUI-色設定

オンライン:
https://demensdeum.com/software/cube-art-project-2/

Githubのソース:
https://github.com/demensdeum/cube-art-project-2

このプロジェクトは、Three.jsを使用して純粋なJavaScriptに書かれています。
フレームワークなし、コレクターなし、WebAssemblyなし – WebGL、シェーダー、ピクセルジオメトリへの少しの愛のみ。

シーンを保存してロードすることができます – あなたの世界を作成し、JSONとして保存し、後で洗練に戻すか、戻ってきてください。

Dockerの安全:なぜルートの発売が悪い考えなのか

Dockerは、現代のDevopsと開発に不可欠なツールになりました。包囲を分離し、衣装を簡素化し、アプリケーションをすばやく拡大することができます。ただし、デフォルトでは、Dockerにはルートが必要であり、これは潜在的に危険なゾーンを作成します。これは、初期段階ではしばしば無視されます。

なぜDockerはルートから機能するのですか?

Dockerは、Linuxの機能を使用しています。Cgroups、名前空間、iptables、マウント、ネットワーキング、その他のシステム機能を使用しています。これらの操作は、スーパーユーザーのみが利用できます。

それが理由です:
* dockerdデーモンはルートから始まります、
* Dockerコマンドはこの悪魔に送信されます。

これにより、作業が簡素化され、システムを完全に制御できますが、同時に潜在的な脆弱性が開かれます。

なぜ危険なのか:コンテナブレイクアウト、CVE、RCE

コンテナブレイクアウト

断熱材が弱いと、攻撃者はchrootまたはpivot_rootを使用してホストに入ることができます。

実際の攻撃の例:

* CVE-2019-5736-RUNCに対する妨害性により、アプリケーションを書き換えてホストのコードを実行できました。
* CVE-2021-3156-sudoに対する妨害性により、容器内にルートを取得して出て行くことができました。

rce(リモートコード実行)

コンテナ内のアプリケーションが脆弱で、rootから始まる場合、RCE =ホストの完全な制御。

rootless docker:問題の解決策

これらのリスクを最小限に抑えるために、dockerにはルートレスモードが表示されました。このモードでは、demonとコンテナの両方が、ルートと特権のない通常のユーザーに代わって起動されます。これは、攻撃者がコンテナの制御を受け取ったとしても、ホストシステムに害を及ぼすことができないことを意味します。
制限があります。1024未満のポート(たとえば、80および443)を使用することはできません。 -Privilegedモードと一部のネットワークモードは使用できません。ただし、ほとんどの開発シナリオとCI/CD Rootless Dockerでは、タスクに対処し、セキュリティのレベルを大幅に向上させます。

歴史的に、root -antipattern から起動

最初から、最小の特権の原則がUNIX/Linuxの世界に適用されてきました。プロセスが少ないほど、害が少なくなります。 Dockerは当初、ルートアクセスを要求していましたが、今日では潜在的な脅威と見なされています。

ソース

https://docs.docker.com/engine/security/rootless/
https://rootlesscontaine.rs/

Dockerコンテナの非自明な問題:隠された脆弱性

Dockerコンテナの非自明な問題:隠された脆弱性

「Depenensky Hell」(DH)とは何ですか?

「Dependency Hell」(DH)は、ソフトウェアの依存関係を管理するときに発生する問題を示す用語です。その主な理由は、バージョンの競合、さまざまなライブラリを統合することの難しさ、およびそれらの間の互換性を維持する必要性です。 DHには次の側面が含まれています。

– バージョンの競合:プロジェクトは多くの場合、特定のバージョンのライブラリを必要とし、異なるコンポーネントは同じライブラリの互換性のないバージョンに依存する可能性があります。
– 更新の困難:依存関係の更新は、新しいバージョンに修正または改善が含まれている場合でも、予期しないエラーや互換性の故障につながる可能性があります。
– 周囲:環境を分離して安定させたいという欲求は、依存管理の簡素化を目的とした仮想環境、コンテナ化、その他のソリューションの使用につながりました。

脆弱性の排除は、更新されたバージョンのライブラリをリリースする理由の1つですが、DHの主要な原動力ではないことに注意することが重要です。主な問題は、各変更 – バグを修正したり、新しい機能を追加したり、脆弱性を排除したりするかどうかにかかわらず、アプリケーションの安定した開発とサポートを複雑にする一連の依存関係を引き起こす可能性があることです。

DHとの戦いはどのようにしてDockerの作成につながりましたか?

問題を解決するために、DHの問題を解決するために、開発者は、アプリケーションのために孤立した安定した環境を作成する方法を探していました。 Dockerはこの課題への対応でした。コンテナ化により:

– 環境を分離する:すべての依存関係とライブラリは、アプリケーションとともにパッケージ化されます。これにより、Dockerがインストールされている場所で安定した作業が保証されます。
– 展開を簡素化する:開発者は一度環境を構成し、それを使用して追加の設定なしでサーバーにデプロイすることができます。
– 競合の最小化:各アプリケーションは独自のコンテナで機能するため、さまざまなプロジェクトの依存関係の間の競合のリスクが大幅に減少します。

したがって、Dockerは、DH問題に対抗するための効果的なソリューションを提案し、開発者が環境のセットアップの難しさではなく、アプリケーションの論理に集中できるようにしました。

Dockerの時代遅れの依存関係の問題

Dockerのすべての利点にもかかわらず、問題の新しい方向が現れました – 中毒の陳腐化。これはいくつかの理由で起こります:

1.容器は時間とともに凍結します

Docker画像を作成すると、すべてのパッケージとライブラリの特定の状態が修正されます。基本的な画像に組み立てられた後(例えば、 `ubuntu:04.20、` python:3.9`、 `node:18-alpine`)、脆弱性が見つかりました。または、新しいバージョンが生成された場合、コンテナは最初にインストールされたバージョンで動作し続けます。画像が送信されない場合、アプリケーションは何年もの間、時代遅れで潜在的に脆弱なコンポーネントで動作できます。

2。自動更新の欠如

システムマネージャーを介して自動パッケージの更新を構成できる従来のサーバー(たとえば、「Aptアップグレード」または「NPMアップデート」)とは異なり、コンテナは自動的に更新されません。更新は、規律と定期的な制御を必要とする画像を再選する場合にのみ発生します。

3.依存関係を修正しました

安定性を確保するために、開発者はしばしば「Redirements.txt」または「package.json」などのファイルで依存関係のバージョンを修正します。このアプローチは予期しない変更を防ぎますが、同時に、エラーや脆弱性がその後検出されたとしても、依存関係の状態を凍結します。

4.時代遅れの基本画像の使用

コンテナ用に選択された基本的な画像は、時間とともに時代遅れにすることもできます。たとえば、アプリケーションが「ノード:16」の画像に基づいて構築されており、開発者がすでに改善と修正のために「ノード:18」に切り替えている場合、すべてがコード内で正しく機能していても、環境は時代遅れのバージョンにとどまります。

時代遅れの依存関係の問題を回避する方法は?

CI/CDプロセスに時代遅れの依存関係と脆弱性について定期的な検査を含めます。

-Pythonの場合:

pip list --outdated

-Node.jsの場合:

npm outdated

– たとえば、「Trivy」など、ツールを使用して脆弱性を分析します。

trivy image my-app

基本画像の更新を監視します

重要な修正と更新についてタイムリーに学ぶために、Docker Hubの基本画像の更新またはGitHubの対応するリポジトリを購読します。

結論

依存関係の問題は、脆弱性を排除する必要性だけでなく、依存関係の管理と更新の困難の結果としても発生しました。 Dockerは、DHと戦うための効果的なソリューションを提案し、アプリケーションに孤立した安定した環境を提供しています。しかし、コンテナ化の出現により、新しいタスクが生じました – 依存関係の陳腐化と重大な脆弱性の外観を防ぐための画像の定期的な更新の必要性。

最新のDevOpsスペシャリストにとって、バージョンの対立の問題を解決するだけでなく、依存症の関連性のために定期的に自動化された制御慣行を導入して、コンテナが安全で効果的なままであることが重要です。

ビルダーパターン:時間内にオブジェクトを作成する段階的

導入

最後の記事では、ビルダーパターンを使用する一般的なケースを調べましたが、オブジェクトが時間内に作成されたときにオプションは触れられませんでした。
ビルダーパターン(ビルダー)は、複雑なオブジェクトを徐々に作成できる生成デザインテンプレートです。オブジェクトに多くのパラメーターまたはさまざまな構成がある場合に特に役立ちます。その使用の興味深い例の1つは、時間内にオブジェクトを作成するプロセスを分離する能力です。
オブジェクトをすぐに作成できない場合があります – そのパラメーターは、プログラムのさまざまな段階で知られるようになります。

Pythonの例

この例では、車のオブジェクトが段階的に作成されます。まず、データの一部がサーバーからロードされ、ユーザーが欠落情報を入力します。

import requests

def fetch_car_data():
    response = requests.get("https://api.example.com/car-info")
    return response.json()

builder = CarBuilder()

# Backend API data
car_data = fetch_car_data()
builder.set_model(car_data["model"])
builder.set_year(car_data["year"])

# User input
color = input("Car color: ")
builder.set_color(color)

gps_option = input("GPS feature? (yes/no): ").lower() == "yes"
builder.set_gps(gps_option)

car = builder.build()
print(car)

API呼び出しを想像してください。データ入力は、アプリケーションのさまざまな部分、または異なるライブラリでも発生します。次に、ビルダーパターンの使用は、上記の簡単な例よりも明白になります。

利点

– 出力は、一時的なアセンブリのためにオプションのデータを保存する必要のない免疫構造です
– オブジェクトは徐々に収集されます
– 複雑なデザイナーを避けます
– オブジェクトのアセンブリコードは、ビルダーの1つの本質でのみ不完全です
– コードを理解する利便性

ソース

https://www.amazon.com/Design-Patterns-Object-Oriented-Addison-Wesley-Professional-ebook/dp/B000SEIBB8
https://demensdeum.com/blog/2019/09/23/builder-pattern/

Demensdeum Coding Challenge#1

Demensdeum Coding Challenge#1を開始します
賞100 USDT
1. Windows1164ビットのレンダリング写真を書く必要があります
2。レンダリング
https://demensdeum.com/logo/demens1.png
3.画像はアプリケーションに統合する必要があります
4。グラフィックAPI -Direct3DまたはDirectDraw
5.そのアプリケーションがバイトが最小のサイズであることが判明したことに勝ちます
6.画像はオリジナルとして1分の1に1つになり、色を保存する必要があります
7.言語/フレームワークでは、追加のインストールを必要としないため、アプリケーションからすぐに開始できます。たとえば、ソリューションが1つのPythonスクリプトのみである場合、そのようなソリューションは適切ではありません。 Python、Pygame、および手動での起動のインストールが必要です。良い例:Pythonスクリプトは、PythonとPygameでExeでラップしました。これは、追加のインストールなしで開始されます。
8。ソースコードを使用して、パブリックリポジトリへのリンクの形式、アプリケーションを組み立てる手順を示します。良い例:Visual Studioコミュニティエディションでのアセンブリの指示があるプロジェクト

締め切り:6月1日、コンテストの要約

Zig + SDL3 + SDL3_IMAGEの参照ソリューション:
https://github.com/demensdeum/DemensDeum-Coding-Challenge-1