Soft & Games
現在、人気のあるLLMサービスプロバイダーはすべて、jsonlファイルを使用して微調整を使用しています。これは、モデルの入力と出力を記述し、Gemini、Openaiなど、形式はわずかに異なります。
特別に形成されたJSONLファイルをダウンロードした後、指定されたデータセット上のLLMモデルの専門化のプロセスが始まります。
Ollamaを使用してローカルマシンで微調整するには、YouTube Channel Techの詳細なビデオに頼ることをお勧めします。
https://www.youtube.com/watch?v=pTaSDVz0gok
すべての電報メッセージのエクスポートからJSONLデータセットの準備を備えたJupyterラップトップの例は、ここで入手できます。
https://github.com/demensdeum/llm-train-example
React Nativeは、モバイルおよびWebアプリケーションのクロスプラットフォーム開発のための強力なツールとしての地位を確立しています。 AndroidおよびiOSのネイティブアプリケーション、およびJavaScript/Typescriptの単一のコードベースを使用してWebアプリケーションを作成できます。
React National Architectureは、JavaScript/Typescriptのネイティブバインディングに基づいています。これは、基本的なビジネスロジックとアプリケーションのアプリケーションがJavaScriptまたはTypeScriptに記述されることを意味します。特定のネイティブ機能（たとえば、デバイスやGPSカメラ）へのアクセスが必要な場合、これらのネイティブバインディングが使用されます。これにより、iOSのSwift/Objective-Cで書かれたコードまたはAndroid用のJava/Kotlinを呼び出すことができます。
結果として生じるプラットフォームの機能は異なる場合があることに注意することが重要です。たとえば、特定の機能は、AndroidとiOSでのみ使用できますが、プラットフォームのネイティブ機能に応じて、Webでは使用できません。
ネイティブバインディングの構成は、プラグインキーを介して実行されます。安定した安全な開発のために、Reactネイティブコンポーネントの最新バージョンを使用し、常に現在のドキュメントに目を向けることが重要です。これにより、互換性の問題を回避し、最新の更新のすべての利点を使用するのに役立ちます。
Reactネイティブは、特定のプラットフォーム（AndroidフォルダーやiOSフォルダーなど）の結果として生成されるプロジェクトを生成できます。これにより、開発者は、必要に応じて、結果として生じるプロジェクトのファイルに手動でパッチして、微細な最適化または特定の設定を実現することができます。これは、パフォーマンスへの個別のアプローチを必要とする複雑なアプリケーションに特に役立ちます。
典型的で簡単なアプリケーションの場合、ネイティブのバインディングで構築されたエキスポバンドルを使用するのに十分な場合があります。ただし、アプリケーションに複雑な機能がある場合、または深いカスタマイズが必要な場合は、反応ネイティブカスタムアセンブリを使用することをお勧めします。
Reactネイティブの重要な利点の1つは、開発中のTypeScript/JavaScriptコードのホットリロードサポートです。これにより、コードの変更がアプリケーションに即座に表示され、開発者が結果をリアルタイムで確認できるため、開発プロセスが大幅に加速します。
React Nativeは、Google PlayとApple App Storeのプロセスをバイパスする「サイレントアップデート）もサポートしていますが、これはTypeScript/JavaScriptコードにのみ適用されます。これにより、アプリケーションストアを通じて出版物の完全なサイクルを通過する必要なく、エラーまたは小さな機能の更新をすばやくリリースできます。
TS/JSコードは、フィンガープリントを使用してネイティブ依存関係の特定のバージョンで覆われていることを理解することが重要です。これにより、JavaScript/TypeScriptパーツとアプリケーションのネイティブ部分との調整が保証されます。
LLM（大規模な言語モデル）との共同採用は可能ですが、モデルがトレーニングされた潜在的に時代遅れのデータセットのために、その適合性は必ずしも高いとは限りません。これは、生成されたコードが、Reactネイティブまたはベストプラクティスの最新バージョンに対応しない場合があることを意味します。
React Nativeは開発を続け、開発者にクロスプラットフォームアプリケーションを作成するための柔軟で効果的な方法を提供します。開発の速度と、ネイティブ機能へのアクセスの可能性を組み合わせて、多くのプロジェクトにとって魅力的な選択肢になります。
Raidenvideoripperを使用してビデオからサウンドを抽出する方法についてのRaidenvideoripperのチュートリアル、ビデオフラグメントからGIFを作成します。
https://www.youtube.com/watch?v=T_6Bm-1RWN8
https://www.youtube.com/watch?v=7x8LFlVjzKs
インターフェイス開発の世界では、共通の概念があります – 「ロッジに完璧なピクセル」。これは、デザインマシンの最小ピクセルへの最も正確な複製を意味します。長い間、それは、特に古典的なウェブデザインの時代において、ゴールドスタンダードでした。しかし、宣言的なマイルの到着とさまざまなデバイスの急速な成長により、「Pixel Perfect」の原則はより一時的になりつつあります。理由を把握してみましょう。
従来、多くのインターフェイス、特にデスクトップは、編集者の命令的なアプローチまたはwysiwyg（あなたが見るものです）を使用して作成されていました。このようなツールでは、デザイナーまたは開発者は要素を直接操作し、ピクセルに正確にキャンバスに配置します。それはグラフィックエディターとの作業に似ています – あなたはあなたの要素がどのように見えるかを見ることができ、あなたは間違いなくそれを配置することができます。この場合、「Pixel Perfect」の達成は非常に現実的な目標でした。
ただし、現代の開発は、宣言マイルにますます基づいています。これは、コンピューターに「このボタンをここに置く」ように指示するのではなく、取得したいものを説明することを意味します。たとえば、要素の特定の座標を示す代わりに、そのプロパティについて説明します。「このボタンは赤く、すべての側面から16pxのインデントを持ち、容器の中心にある必要があります。」 Freimvorkiは、React、Vue、Swiftui、Jetpackのようなものです。この原則を使用するだけです。
iPhone 15 Pro Max、Samsung Galaxy Fold、iPad Pro、および4K解像度で等しく見栄えの良いアプリケーションを作成すると想像してください。これらの各デバイスには、画面解像度、ピクセル密度、パーティ、および物理サイズが異なります。
宣言的アプローチを使用する場合、システム自体は、すべてのパラメーターを考慮して、特定のデバイスに説明されたインターフェイスを表示する方法を決定します。厳しい座標ではなく、ルールと依存関係を設定します。
* 適応性と応答性：宣言マイルの主な目標は、適応的で応答性のあるインターフェイスを作成することです。これは、読みやすさを壊して維持せずに、インターフェイスが画面のサイズと方向に自動的に適応する必要があることを意味します。各デバイスで「Pixel Perfect」を試みた場合、同じインターフェイスの無数のオプションを作成する必要があります。
* ピクセル密度（DPI/PPI）：デバイスのピクセル密度は異なります。スケーリングを考慮しない場合、高密度のデバイス上の100の「仮想」ピクセルのピクセルの同じ要素は、低密度デバイスよりもはるかに小さく見えます。宣言的なフレームワークは、物理的なピクセルによって抽象化され、論理ユニットを使用します。
* 動的コンテンツ：最新のアプリケーションのコンテンツは、しばしば動的です – その体積と構造は異なる場合があります。ピクセルに激しくぼろぼろにした場合、テキストや画像の変更はレイアウトの「崩壊」につながります。
* さまざまなプラットフォーム：さまざまなデバイスに加えて、異なるオペレーティングシステム（iOS、Android、Web、デスクトップ）があります。各プラットフォームには、独自の設計、標準コントロール、フォントがあります。すべてのプラットフォームで完全に同一のピクセル完璧なインターフェイスを作成しようとすると、不自然なタイプとユーザーエクスペリエンスの低下につながります。
インターフェイスへのアプローチは、「必須」と「宣言」の間のバイナリ選択ではないことを理解することが重要です。歴史的に、各プラットフォームには、インターフェイスの作成に対する独自のツールとアプローチがありました。
* ネイティブインターフェイスファイル： iOSの場合は、Android-XMLマーキングファイルのXIB/ストーリーボードでした。これらのファイルは、ピクセルに最適なWysiWygレイアウトであり、エディターと同様に無線に表示されます。このアプローチはどこにも消えておらず、開発を続けており、最新の宣言的なフレームと統合されています。たとえば、AppleとJetpackのSwiftuiはAndroidで構成され、純粋に宣言的なコードのパスで出発しましたが、同時に古典的なレイアウトを使用する機会を保持しました。
* ハイブリッドソリューション：多くの場合、実際のプロジェクトでは、アプローチの組み合わせが使用されます。たとえば、アプリケーションの基本構造は宣言的に実装できます。特定のために、要素の正確な位置決めを必要とするため、プラットフォームの詳細を考慮して、より低レベルの命令的な方法を使用するか、ネイティブコンポーネントを開発できます。
モノリスから適応性への
デジタルインターフェイスの世界は、過去数十年にわたって大きな変化を遂げてきました。固定許可を持つ固定コンピューターから、さまざまなユーザーデバイスの指数関数的な成長の時代になりました。今日、当社のアプリケーションは次のことで等しくうまく機能するはずです
* すべてのフォームファクターと画面サイズのスマートフォン。
* タブレット独自の方向モードと分離画面があります。
* ラップトップとデスクトップさまざまな許可証のモニター。
* テレビとメディアセンター、リモートで制御されています。テレビでさえ、最小限のボタンを備えたApple TVリモートのように単純なものになる可能性があることは注目に値します。インターフェイスは、特定のリモートコントロールと対話する「方法」を追加することなく、「まるでそれ自体のように」機能するはずです。
* ミニマルな画面を備えたスマートウォッチとウェアラブルデバイス。
* 仮想現実ヘルメット（VR）。空間インターフェイスに対するまったく新しいアプローチが必要です。
* 拡張現実デバイス（AR）、現実世界に関する情報を適用します。
* 自動車情報およびエンターテイメントシステム。
*そして、家電製品：感覚スクリーンを備えた冷蔵庫と、スマートオーブンとスマートハウスのシステムへのインタラクティブなディスプレイを備えた洗濯機から。
これらの各デバイスには、物理的寸法、パーティー比、ピクセル密度、入力方法（タッチスクリーン、マウス、コントローラー、ジェスチャー、ボーカルコマンド）、および重要なことに、ユーザー環境の微妙さ。たとえば、VR Shleshには深い浸漬が必要であり、外出先でのスマートフォンの高速で直感的な作業が必要ですが、冷蔵庫のインターフェイスは簡単で大きくて、迅速なナビゲーションを使用する必要があります。
デスクトップの優位性と最初のモバイルデバイスの時代において、通常のビジネスは、個々のインターフェイスファイルのの作成とサポートでした。
* iOS に基づく開発は、xcodeでストーリーボードまたはxibファイルを使用する必要があることが多く、Objective-cまたはswiftのコードを作成しました。
* android XMLマーキングファイルとJavaまたはKotlinのコードが作成されました。
* WebインターフェイスはHTML/CSS/JavaScriptをオンにしました。
* c ++アプリケーションの場合さまざまなデスクトッププラットフォームで、特定のフレームワークとツールが使用されました。
* Windows では、これらはMFC（Microsoft Foundationクラス）、手動描画要素を備えたWin32 API、またはダイアログウィンドウとコントロール要素のリソースファイルを使用していました。
*グラフィックインターフェイスを直接制御するためのココア（Objective-C/Swift）または古いカーボンAPIが macos で使用されました。
* linux/unixのようなシステムでは、GTK+やQTなどのライブラリがよく使用され、XMLのようなマーキングファイル（QTデザイナーの.UIファイルなど）または要素の直接ソフトウェアの作成を介して、インターフェイスを作成するためのウィジェットとメカニズムのセットを提供しました。
このアプローチにより、各プラットフォームを最大限に制御できるようになり、特定のすべての機能とネイティブ要素を考慮することができます。しかし、彼には大きな欠点がありました。努力の複製とサポートのための途方もないコスト。設計または機能のわずかな変更には、実際には独立したコードベースがいくつかの権利を導入する必要がありました。これは、開発者チームにとって本当の悪夢になり、新しい機能の出力を遅くし、エラーの可能性を高めました。
宣言マイルが支配的なパラダイムとして登場したのは、この急速な複雑さに対応していました。 React、Vue、Swiftui、Jetpackのようなframwsはを構成します。
宣言的アプローチの主なアイデア：システムがすべての要素を描画する方法（命令）を「どのように」（命令したいか（宣言）」と説明する代わりに。インターフェイスのプロパティと条件を設定し、フレームワークは特定のデバイスに最適に表示する方法を決定します。
これは、次の重要な利点のおかげで可能になりました。
1。プラットフォームの詳細からの抽象化：宣言的なfraimvorkiは、各プラットフォームの低レベルの詳細を忘れるように特別に設計されています。開発者は、単一の転送されたコードを使用して、より高いレベルの抽象化でコンポーネントとその関係を説明します。
2。自動適応と応答性： freimvorki 自動スケーリング、要素のレイアウト、およびさまざまなサイズの画面、ピクセル密度、入力方法へのレイアウトと適応の変更について責任を負います。これは、FlexBoxやグリッドなどの柔軟なレイアウトシステムの使用、および「論理ピクセル」や「DP」に似た概念を使用して達成されます。
3。ユーザーエクスペリエンスの一貫性：外部の違いにもかかわらず、宣言的アプローチにより、デバイスのファミリー全体で行動と相互作用の単一のロジックを維持できます。これにより、テストプロセスが簡素化され、より予測可能なユーザーエクスペリエンスが提供されます。
4。開発とコスト削減の加速：多くのプラットフォームで作業できるのと同じコードを使用すると、開発とサポートの時間とコストによってが大幅に削減されます。チームは、同じインターフェイスを繰り返し書き直すことではなく、機能と設計に焦点を合わせることができます。
5。 Freimvorkiは新しいテクノロジーをサポートするために更新でき、すでに書かれたコードがこのサポートを受け取ることは比較的シームレスです。
宣言的なマイルは、単なるファッションのトレンドではなく、モノのインターネット（IoT）やスマート世帯家電などのユーザーデバイスの急速な開発によって引き起こされる必要な進化ステップです。これにより、開発者と設計者は、各プラットフォームの無限の特定の実装にownれなくなることなく、複雑で適応的で均一なインターフェイスを作成できます。各ピクセルの命令制御から目的の状態の宣言的記述への遷移は、将来のインターフェイスの世界では、表示される画面に関係なく、柔軟で、転送され、直感的であるであるべきであるという認識です。
プログラマー、デザイナー、ユーザーは、この新しい世界で生きる方法を学ぶ必要があります。 特定のデバイスまたは解像度に合わせて設計されたPixel Perfectの追加の詳細は、開発とサポートのために不必要な時間コストにつながります。さらに、このような過酷なレイアウトは、限られた入力テレビ、VR、ARシフトなどの標準以外のインターフェイスを備えたデバイスや、将来の他のデバイスでも機能しない場合がありますが、今日でもわかりません。柔軟性と適応性 – これらは、現代世界で成功したインターフェイスを作成するための鍵です。
Microsoft StoreでのRaidenvideoripperリリース-MP4、WebM、GIF形式へのビデオと変換の迅速なインストールのためのアプリケーション。
https://apps.microsoft.com/detail/9nvzjs98smgc?hl=en-us&gl=GE&ocid=pdpshare
Raidenvideoripperの新しいバージョン-1.0.2.0
Windows 11の暗いテーマのサポートを追加しました。
Raiden Video Ripperは、WebM、GIF形式でのシンプルなビデオカットのアプリケーションです。
リリースページにアクセスして、最新の問題と更新に遅れないようにしてください。
https://github.com/demensdeum/RaidenVideoRipper/releases
今日、ニューラルネットワークはどこでも使用されています。プログラマーはそれらを使用して、コードを生成し、他のソリューションを説明し、ルーチンタスクを自動化し、アプリケーション全体をゼロから作成します。これにより、効率の向上、エラーの減少、開発の加速につながるはずです。しかし、現実ははるかに普及しています。多くはまだ成功していません。ニューラルネットワークは重要な問題を解決しません – 無知の深さを照らすだけです。
主な理由は、多くの開発者がLLMに完全に依存しており、彼らが働いているツールを深く理解する必要性を無視していることです。ドキュメントを勉強する代わりに、チャットリクエスト。エラーの理由を分析する代わりに、決定をコピーします。建築ソリューションの代わりに、説明に従ってコンポーネントの生成。これはすべて表面的なレベルで機能しますが、非標準タスクが発生するとすぐに、実際のプロジェクトとの統合または微調整の必要性が必要であり、すべてが崩れます。
ニューラルネットワークは、一般化されたコードを生成します。彼らは、あなたのプラットフォームの詳細、図書館のバージョン、環境制限、またはプロジェクトの建築ソリューションを考慮していません。生成されるものはしばしばもっともらしいように見えますが、実際のサポートされているコードとは何の関係もありません。それらが時代遅れのバージョンのフレームワークに属している場合、または長い間効果のないまたは安全でないと認識されてきたアプローチを使用する場合、単純な推奨事項でさえも機能しない場合があります。モデルはコンテキストを理解していません – 統計に依存しています。これは、オープンコードで人気のあるエラーとアンチパットターンが何度も何度も再現されることを意味します。
生成されたAIを生成するコードは、多くの場合冗長です。不要な依存関係、ロジックの複製、抽象化を不必要に追加します。サポートが困難な効果的で重い構造が判明しました。これは、ギャングのサイズ、応答時間、エネルギー消費が重要であるモバイル開発では特に深刻です。
ニューラルネットワークはプロファイリングを実施せず、CPUとGPUの制限を考慮していないため、メモリの漏れを気にしません。コードが実際にどれほど効果的であるかを分析しません。最適化は依然として手作りであり、分析と検査が必要です。それがなければ、アプリケーションは、構造の観点から「正しい」ように見える場合でも、遅く、不安定でリソース集中的になります。
安全を忘れないでください。 LLMを使用して部分的または完全に作成されたプロジェクトが正常にハッキングされた場合、すでに既知のケースがあります。理由は典型的なものです。危険な関数の使用、入力データの検証の欠如、承認の論理のエラー、外部依存関係の漏れです。ニューラルネットワークは、オープンリポジトリで見つかったという理由だけで、脆弱なコードを生成できます。セキュリティスペシャリストの参加と完全な改訂がなければ、このようなエラーは攻撃の入力ポイントに簡単になります。
パレートの法律は、ニューラルネットワークではっきりと機能します。努力の20％のために結果の80％が達成されます。このモデルは、大量のコードを生成し、プロジェクトの基礎を作成し、構造を広げ、タイプをアレンジし、モジュールを接続できます。ただし、これはすべて時代遅れであり、現在のバージョンのライブラリまたはフレームワークと互換性があり、重要な手動改訂が必要です。ここでの自動化は、プロジェクトの特定の現実にチェックされ、処理され、適応する必要があるドラフトとして機能します。
それにもかかわらず、未来は励みに見えます。トレーニングデータセットの絶え間ない更新、現在のドキュメントとの統合、自動化されたアーキテクチャチェック、設計およびセキュリティパターンへのコンプライアンス – これがすべてゲームのルールを根本的に変更する可能性があります。おそらく数年後には、コードをより速く、より安全で、より効率的に書くことができ、LLMに真の技術的な共著者として依存することができます。しかし、今のところ – 悲しいかな – 多くのことをチェックし、書き直し、手動で修正する必要があります。
ニューラルネットワークは強力なツールです。しかし、彼があなたに反対するのではなく、あなたのために働くためには、いつでもコントロールするための基盤、批判的思考、意欲が必要です。
Demensdeum Challenge 1の要約1。
私たちの勝者は、Snkbp95からの手動で書かれたアセンブラーのオプションです。これは、50kbと一緒に実行可能ファイルのサイズです。
勝者におめでとうございます！
https://github.com/snkbp95/DemensDeum-Coding-Challenge-1/
私はあなたの注意フォーク・ケイトのテキストエディターをGingeritaと呼んでいます。なぜフォーク、なぜ、目標は何ですか？修正を待たないように、ケイトチームからの機能を追加したり、メインブランチへの修正を採用したりするように、自分の仕事に必要な機能を追加したいと思います。
現時点では、Windows用のプロトタイプバージョンが現在利用可能であり、最小限の変更を伴うケイトのほとんどバニラバージョンです。 Gingeritaの場合、2つのプラグを開発しました。エディターとビルドインブラウザーからの画像の画像、Webプロジェクトのデバッグ、またはChatGptなどのアシスタントとAIと対話するための画像です。
Windows用のバージョンは、以下のリンクでテストできます。
https://github.com/demensdeum/Gingerita/releases/tag/prototype
サポートページへようこそ！
質問がある場合、Demensdeum製品の問題、または改善を提供したい場合は、常にお手伝いします。
私たちに連絡する方法：
support@demensdeum.com
3〜5営業日以内に控訴に答えようとしています。
手紙で何を示すべきか：
製品の名前
バージョン（既知の場合）
問題の詳細な説明
スクリーンショットまたはビデオ（可能であれば）
問題が発生したデバイスとオペレーティングシステム
私たちの製品を使用してくれてありがとう、そしてあなたの経験を可能な限り便利で快適にするよう努めています。
心から、
Demensdeumチーム
CHATGPTなどの大規模な言語モデル（LLM）の開発により、ますます多くの開発者がそれらを使用してコードを生成し、設計アーキテクチャを生成し、統合を加速します。ただし、実用的なアプリケーションでは、それは顕著になります。建築の古典原則 – 固体、乾燥、清潔 – LLMコドゲンデーションの特性とうまくやっていません。
これは、原則が時代遅れであることを意味するものではありません – それどころか、それらは手動開発と完全に連携しています。しかし、LLMでは、アプローチを適応させる必要があります。
なぜLLMが建築原則に対処できないのか
インクシレーションでは、システムの一部間の境界、開発者の意図に関する知識を理解し、厳格なアクセス制限に従う必要があります。 LLMは、多くの場合、構造を簡素化したり、理由もなくフィールドを公開したり、実装を複製したりします。これにより、コードはエラーに対してより脆弱になり、アーキテクチャの境界に違反します。
抽象的な工場や戦略などの設計パターンには、システムの全体的な見方が必要であり、そのダイナミクスを理解する必要があります。モデルは、実装を保証せずに明確な目的なしでインターフェイスを作成したり、レイヤー間の接続に違反したりできます。結果は、過剰または非機能的アーキテクチャです。
LLMは、繰り返しコードを最小限に抑えようとはしません – それどころか、一般的なロジックを作成するよりもブロックを複製する方が簡単です。リクエストに応じてリファクタリングを提供できますが、デフォルトでは、たとえ冗長性につながる場合でも、「自己適切な」フラグメントを生成する傾向があります。
Cleanは、厳格な階層、フレームワークからの独立性、指向性の依存性、およびレイヤー間の最小のつながりを意味します。このような構造の生成には、システムのグローバルな理解が必要です。また、LLMは、建築の完全性ではなく、単語の確率のレベルで機能します。したがって、コードは混合され、依存の方向に違反し、レベルへの単純化された分割が違反されます。
乾燥する代わりに濡れています
WET（すべてを2回書く）アプローチは、LLMでの作業においてより実用的です。コードの複製は、保持のモデルからのコンテキストを必要としません。つまり、結果は予測可能であり、正しく修正しやすくなります。また、非自明なつながりやバグの可能性を減らします。
さらに、複製はモデルの短いメモリを補うのに役立ちます。いくつかの場所でロジックの特定の断片が見つかった場合、LLMはそれをさらなる生成で考慮に入れる可能性が高くなります。これにより、伴奏が簡素化され、「忘却」に対する抵抗が増加します。
複雑なカプセル化を回避し、コードの部分間のデータの直接送信に依存すると、生成とデバッグの両方を大幅に簡素化できます。これは、MVPの迅速な開発または作成で特に当てはまります。
プロジェクトのシンプルでフラットな構造は、最小量の依存関係と抽象化を備えており、発電中はより安定した結果をもたらします。モデルはこのようなコードを簡単に適応させ、コンポーネント間の予想される接続に違反することが多い場合があります。
ほとんどの言語モデルは、時代遅れのバージョンのドキュメントでトレーニングされています。したがって、SDKをインストールするための手順を生成する場合、エラーがよく表示されます。時代遅れのコマンド、無関係なパラメーター、またはアクセスできないリソースへのリンク。練習のショー：公式のドキュメントと手動チューニングを使用して、LLMを補助的な役割にします。たとえば、テンプレートコードや構成の適応を生成します。
固体で乾燥した清潔から清潔からの困難は、LLMを介したコドヘゲエネーションに懸念していることを理解することが重要です。開発者がコードを手動で書き込むと、これらの原則は引き続き価値を示し続けます。つながりを低下させ、サポートを簡素化し、プロジェクトの読みやすさと柔軟性を高めます。
これは、人間の思考が一般化する傾向があるという事実によるものです。私たちはパターンを探しています。個々のエンティティに繰り返し論理を持ち込み、パターンを作成します。おそらく、この動作には進化的なルーツがあります。情報の量を減らすと、認知リソースが節約されます。
LLMは異なる行動をとる：彼らはデータの量から負荷を経験せず、貯蓄を努力しません。それどころか、複雑な抽象化を構築および維持するよりも、それらが重複した断片化された情報を使用して作業するのが簡単です。そのため、繰り返し構造と最小限のアーキテクチャの重大度を備えた、カプセル化なしでコードに対処する方が簡単です。
大規模な言語モデルは、特に初期段階で、または補助コードを作成する際に、開発において有用なツールです。ただし、アプローチを適応させることが重要です。アーキテクチャを簡素化し、抽象化を制限し、複雑な依存関係を避け、SDKを構成する際にそれらに依存しないようにすることが重要です。
固体、乾燥、きれいの原則はまだ関連していますが、人の手に最善の効果をもたらします。 LLMで作業する場合、手動で簡単に完成できる信頼できる理解可能なコードを取得できる簡素化された実用的なスタイルを使用することが合理的です。そして、LLMが忘れる場所 – コードの複製は彼が覚えておくのに役立ちます。
私の新しいプロジェクトである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
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は、現代のDevopsと開発に不可欠なツールになりました。包囲を分離し、衣装を簡素化し、アプリケーションをすばやく拡大することができます。ただし、デフォルトでは、Dockerにはルートが必要であり、これは潜在的に危険なゾーンを作成します。これは、初期段階ではしばしば無視されます。
Dockerは、Linuxの機能を使用しています。Cgroups、名前空間、iptables、マウント、ネットワーキング、その他のシステム機能を使用しています。これらの操作は、スーパーユーザーのみが利用できます。
それが理由です：
* dockerdデーモンはルートから始まります、
* Dockerコマンドはこの悪魔に送信されます。
これにより、作業が簡素化され、システムを完全に制御できますが、同時に潜在的な脆弱性が開かれます。
断熱材が弱いと、攻撃者はchrootまたはpivot_rootを使用してホストに入ることができます。
実際の攻撃の例：
* CVE-2019-5736-RUNCに対する妨害性により、アプリケーションを書き換えてホストのコードを実行できました。
* CVE-2021-3156-sudoに対する妨害性により、容器内にルートを取得して出て行くことができました。
コンテナ内のアプリケーションが脆弱で、rootから始まる場合、RCE =ホストの完全な制御。
これらのリスクを最小限に抑えるために、dockerにはルートレスモードが表示されました。このモードでは、demonとコンテナの両方が、ルートと特権のない通常のユーザーに代わって起動されます。これは、攻撃者がコンテナの制御を受け取ったとしても、ホストシステムに害を及ぼすことができないことを意味します。
制限があります。1024未満のポート（たとえば、80および443）を使用することはできません。 -Privilegedモードと一部のネットワークモードは使用できません。ただし、ほとんどの開発シナリオとCI/CD Rootless Dockerでは、タスクに対処し、セキュリティのレベルを大幅に向上させます。
最初から、最小の特権の原則がUNIX/Linuxの世界に適用されてきました。プロセスが少ないほど、害が少なくなります。 Dockerは当初、ルートアクセスを要求していましたが、今日では潜在的な脅威と見なされています。
https://docs.docker.com/engine/security/rootless/
https://rootlesscontaine.rs/
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を開始します
賞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
GhostContactsアプリでは、シークレットリストに連絡先を追加し、CSV連絡先の暗く明るいトピック、ローカリゼーション、エクスポート、インポートのサポートがあります。ユーザーが突然入力するために通常のパスワードが必要な場合、連絡先のリストをリセットするための緊急パスワードがサポートされます。
オンラインでアプリケーション：
https://demensdeum.com/software/ghost-contacts/
Github：
https://github.com/demensdeum/GhostContacts
2015 年に自分のブログを始めようと考え始めたとき、どのプラットフォームを選択すべきかという疑問に直面しました。いろいろ探して比較した結果、WordPressに決めました。これはランダムな選択ではなく、プラットフォームの機能、長所と短所を分析した結果です。今日は、WordPress を使用した私の考えと経験を共有したいと思います。
WordPress は、シンプルさとパワーの完璧なバランスを提供するツールです。私にとっては、特に欠点を克服するための解決策が多数あることを考慮すると、利点は欠点を上回ります。 WordPressのおかげで、自分のニーズにぴったり合ったブログを作成することができました。
最近、あなたにお勧めしたい速読アプリを見つけました。
速読は、生産性を大幅に向上させ、読解力を向上させ、時間を節約できるスキルです。市場には、このスキルを習得するのに役立つと約束されたアプリがたくさんありますが、際立ったものの 1 つは Wordex for iOS です。この記事では、Wordex とは何なのか、どのような機能があるのか、誰に適しているのか、なぜ注目に値するのかを説明します。
Wordex は、速読スキルを向上させるために特別に設計された iOS アプリです。これにより、ユーザーはテキストをより速く読み、重要なアイデアに集中し、気が散ることを避けることができます。このプログラムは科学的なアプローチに基づいており、読書速度を向上させる便利なツールを提供します。
<中央>
Wordex は次のような用途に最適です。
<中央>
<中央>
Wordex は速読を教えるためだけのツールではありません。これは集中力を養い、語彙を増やし、生産性を向上させるプログラムです。一度 Wordex を試してみると、読書がもはや面倒ではなく、エキサイティングなアクティビティに変わることに気づくでしょう。
速読を学びたい、または既存のスキルを向上させたい場合は、Wordex が最適です。使いやすく効果的なこのアプリケーションは、目標を達成し、貴重な時間を節約するのに役立ちます。 App Store から Wordex をダウンロードして、今すぐトレーニングを始めましょう!
アプリストア:
https://apps.apple.com/us/app/speed-reading-book-reader-app/id1462633104
DRY のトピックに関する記事は数多くありますが、オリジナルのソースである Andy Hunt と Dave Thomas による「The Pragmatist Programmer」を読むことをお勧めします。しかし、ソフトウェア開発におけるこの原則について疑問を抱いている開発者がいかに多いかがわかります。
DRY 原則では、同じことを繰り返してはいけないと定められており、これはコードとプログラマーとして実行するプロセスの両方に当てはまります。 DRY に違反するコード例:
class Client {
public let name: String
private var messages: [String] = []
init(name: String) {
self.name = name
}
func receive(_ message: String) {
messages.append(message)
}
}
class ClientController {
func greet(client: Client?) {
guard let client else {
debugPrint("No client!")
return
}
client.receive("Hello \(client.name)!")
}
func goodbye(client: Client?) {
guard let client else {
debugPrint("No client!!")
return
}
client.receive("Bye \(client.name)!")
}
}
挨拶メソッドと別れのメソッドでわかるように、Client クラスのオプションのインスタンスが渡されます。これは nil かどうかをチェックする必要があり、それから作業を開始できます。 DRY メソッドに準拠するには、クラス インスタンスの重複した nil チェックを削除する必要があります。これはさまざまな方法で実装できます。1 つのオプションは、インスタンスをクラス コンストラクターに渡すことで、その後はチェックが必要なくなります。
ClientController を単一の Client インスタンスに特化することで DRY を維持します。
class Client {
public let name: String
private var messages: [String] = []
init(name: String) {
self.name = name
}
func receive(_ message: String) {
messages.append(message)
}
}
class ClientController {
private let client: Client
init(client: Client) {
self.client = client
}
func greet() {
client.receive("Hello \(client.name)!")
}
func goodbye() {
client.receive("Bye \(client.name)!")
}
}
DRY は、ソフトウェア開発中に発生するプロセスにも関係します。開発チームが独自にリリースを市場にアップロードし、ソフトウェア開発から気をそらさなければならない状況を想像してみましょう。これも DRY 違反です。この状況は、開発者が満たす特定の条件に従って、リリースが自動的にリリースされる CI/CD パイプラインに接続することで解決されます。
一般に、DRY はプロセスとコードの両方に繰り返しがないことを意味します。これは人的要因の存在によっても重要です。繰り返しが少なくノイズの多いコードが含まれるコードは、エラーのチェックが容易です。自動化されたプロセスでは、人間が関与しないため、プロセスの実行中に間違いを犯すことがなくなります。
スティーブ・ジョブズの格言は、「書く必要のなかったコード行は、デバッグする必要のないコード行です。」です。
https://pragprog.com/titles/tpp20/the-pragmatic-programmer-20th-anniversary-edition/
https://youtu.be/-msIEOGvTYM
私は現在、Fiverr で iOS 開発者としてのサービスを提供していることをお知らせします。高品質の iOS アプリの開発や既存のプロジェクトの改善にサポートが必要な場合は、私のプロフィールをご覧ください。
https://www.fiverr.com/s/Q7x4kb6
あなたのプロジェクトに携わる機会があれば嬉しいです。
電子メール: demensdeum@gmail.com
電報: https://t.me/demensdeum
本日、macOS および M1/M2/M3/M4 プロセッサ (Apple Silicon) を搭載した Apple デバイス用の RaidenVideoRipper のバージョンをリリースしました。 RaidenVideoRipper は、ビデオ ファイルの一部を新しいファイルに切り取ることができる迅速なビデオ編集アプリケーションです。 gif を作成したり、オーディオ トラックを mp3 にエクスポートしたりすることもできます。
次に、これを実現するために使用したコマンドについて簡単に説明します。ここで何が起こっているかの理論、ユーティリティのドキュメントは、次のリンクで読むことができます。
https://www.unix.com/man-page/osx/1/otool/
https://www.unix.com/man-page/osx/1/install_name_tool/
https://llvm.org/docs/CommandGuide/llvm-nm.html
https://linux.die.net/man/1/file
https://www.unix.com/man-page/osx/8/SPCTL/
https://linux.die.net/man/1/chmod
https://linux.die.net/man/1/ls
https://man7.org/linux/man-pages/man7/xattr.7.html
https://doc.qt.io/qt-6/macos-deployment.html
開始するには、macOS に Qt をインストールし、Qt デスクトップ開発用の環境もインストールします。この後、たとえば Qt Creator でプロジェクトをアセンブルし、アプリケーションをエンド ユーザーに配布するときに外部動的ライブラリとの依存関係が正しく処理されるようにするために必要なことについて説明します。
アプリケーションの YOUR_APP.app/Contents フォルダーに Frameworks ディレクトリを作成し、その中に外部依存関係を配置します。たとえば、RaidenVideoRipper アプリケーションのフレームワークは次のようになります。
Frameworks
├── DullahanFFmpeg.framework
│ ├── dullahan_ffmpeg.a
│ ├── libavcodec.60.dylib
│ ├── libavdevice.60.dylib
│ ├── libavfilter.9.dylib
│ ├── libavformat.60.dylib
│ ├── libavutil.58.dylib
│ ├── libpostproc.57.dylib
│ ├── libswresample.4.dylib
│ └── libswscale.7.dylib
├── QtCore.framework
│ ├── Headers -> Versions/Current/Headers
│ ├── QtCore -> Versions/Current/QtCore
│ ├── Resources -> Versions/Current/Resources
│ └── Versions
├── QtGui.framework
│ ├── Headers -> Versions/Current/Headers
│ ├── QtGui -> Versions/Current/QtGui
│ ├── Resources -> Versions/Current/Resources
│ └── Versions
├── QtMultimedia.framework
│ ├── Headers -> Versions/Current/Headers
│ ├── QtMultimedia -> Versions/Current/QtMultimedia
│ ├── Resources -> Versions/Current/Resources
│ └── Versions
├── QtMultimediaWidgets.framework
│ ├── Headers -> Versions/Current/Headers
│ ├── QtMultimediaWidgets -> Versions/Current/QtMultimediaWidgets
│ ├── Resources -> Versions/Current/Resources
│ └── Versions
├── QtNetwork.framework
│ ├── Headers -> Versions/Current/Headers
│ ├── QtNetwork -> Versions/Current/QtNetwork
│ ├── Resources -> Versions/Current/Resources
│ └── Versions
└── QtWidgets.framework
├── Headers -> Versions/Current/Headers
├── QtWidgets -> Versions/Current/QtWidgets
├── Resources -> Versions/Current/Resources
└── Versions
簡単にするために、ネストの 2 番目のレベルのみを出力しました。
次に、アプリケーションの現在の動的依存関係を出力します。
otool -L RaidenVideoRipper
RaidenVideoRipper.app/Contents/MacOS にある RaidenVideoRipper バイナリの出力:
RaidenVideoRipper:
@rpath/DullahanFFmpeg.framework/dullahan_ffmpeg.a (compatibility version 0.0.0, current version 0.0.0)
@rpath/QtMultimediaWidgets.framework/Versions/A/QtMultimediaWidgets (compatibility version 6.0.0, current version 6.8.1)
@rpath/QtWidgets.framework/Versions/A/QtWidgets (compatibility version 6.0.0, current version 6.8.1)
@rpath/QtMultimedia.framework/Versions/A/QtMultimedia (compatibility version 6.0.0, current version 6.8.1)
@rpath/QtGui.framework/Versions/A/QtGui (compatibility version 6.0.0, current version 6.8.1)
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 2575.20.19)
/System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/Metal.framework/Versions/A/Metal (compatibility version 1.0.0, current version 367.4.0)
@rpath/QtNetwork.framework/Versions/A/QtNetwork (compatibility version 6.0.0, current version 6.8.1)
@rpath/QtCore.framework/Versions/A/QtCore (compatibility version 6.0.0, current version 6.8.1)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
/System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/UniformTypeIdentifiers.framework/Versions/A/UniformTypeIdentifiers (compatibility version 1.0.0, current version 709.0.0)
/System/Library/Frameworks/AGL.framework/Versions/A/AGL (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1800.101.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1351.0.0)
Qt の RaidenVideoRipper と dulahan_ffmpeg の依存関係に見られるように。 Dullahan FFmpeg は FFmpeg のフォークであり、その機能を動的ライブラリにカプセル化し、C ルーチンを使用して現在の実行の進行状況とキャンセルを取得する機能を備えています。
次に、install_name_tool を使用して、アプリケーションと必要なすべてのライブラリのパスを置き換えます。
このためのコマンドは次のとおりです。
install_name_tool -change old_path new_path target
使用例：
install_name_tool -change /usr/local/lib/libavfilter.9.dylib @rpath/DullahanFFmpeg.framework/libavfilter.9.dylib dullahan_ffmpeg.a
正しいパスをすべて入力すると、アプリケーションが正しく起動するはずです。ライブラリへのすべてのパスが相対パスであることを確認し、バイナリを転送して、再度開きます。
エラーが表示された場合は、otool を使用してパスを確認し、install_name_tool を使用して再度変更します。
依存関係の混同によるエラーもあります。置き換えたライブラリにテーブル内にシンボルがない場合は、次のようにシンボルの有無を確認できます。
nm -gU path
実行すると、ライブラリまたはアプリケーションのシンボル テーブル全体が表示されます。
間違ったアーキテクチャの依存関係をコピーした可能性もあります。次のファイルを使用してこれを確認できます。
file path
ファイル ユーティリティは、ライブラリまたはアプリケーションがどのアーキテクチャに属しているかを示します。
Qt では、YOUR_APP.app ディレクトリの Content フォルダーに Plugins フォルダーも必要です。プラグインを Qt から Contents にコピーします。次に、アプリケーションの機能を確認します。その後、Plugins フォルダーの最適化、このフォルダーからの要素の削除、およびアプリケーションのテストを開始できます。
すべての依存関係をコピーし、動的リンクのパスを修正した後、開発者の署名でアプリケーションに署名し、さらに公証のためにアプリケーションのバージョンを Apple に送信する必要があります。
開発者ライセンスの 100 ドルを持っていない場合、または何も署名したくない場合は、アプリケーションの起動方法についてユーザーに指示を書きます。
この手順は RaidenVideoRipper でも機能します。
隔離フラグによるエラーは通常、ユーザーの画面に「アプリケーションが破損しています」というエラーが表示されて再現されます。この場合、メタデータから隔離フラグを削除する必要があります。
Apple Silicon 用の RaidenVideoRipper をビルドするためのリンク:
https://github.com/demensdeum/RaidenVideoRipper/releases/download/1.0.1.0/RaidenVideoRipper-1.0.1.0.dmg
ビデオを安定させて手ぶれを除去したい場合は、「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 – アーティファクトが除去されるまで自動ズーム)。
プロジェクトのソース コードを分析する必要があるが、プロセスを自動化し、コンピューターのローカル機能を使用したい場合は、Bistr ユーティリティが優れたソリューションとなります。この記事では、このユーティリティが Ollama 機械学習モデルを使用したコード分析にどのように役立つかを見ていきます。
Bistr は、コード分析と処理のために Ollama などのローカル LLM (大規模言語モデル) モデルを統合できるソース コード分析ユーティリティです。 Bistr を使用すると、Python、C、Java、JavaScript、HTML などのさまざまなプログラミング言語でファイルを解析できます。
Bistr は、このモデルを使用して、特定のクエリに対してファイルをチェックします。たとえば、コードまたはその一部の機能に関する質問に対する答えを見つけます。これにより、プロジェクトの開発、テスト、保守に役立つ構造化分析が提供されます。
Bistr を使用するには、ローカル マシンに LLM モデルを提供するプラットフォームである Ollama をインストールして実行する必要があります。 macOS、Windows、Linux 用の Ollama をインストールする手順を以下に説明します。
Bistr の最新バージョンを git からダウンロードします。
https://github.com/demensdeum/Bistr/
Ollama と Bistr をインストールした後、コード分析を実行できます。これを行うには、ソース コードを準備し、分析するファイルが含まれるディレクトリへのパスを指定する必要があります。このユーティリティを使用すると、中断したところから分析を続けることができ、さらに分析を容易にするために結果を HTML 形式でエクスポートする機能も提供します。
分析を実行するコマンドの例:
python bistr.py /path/to/code --model llama3.1:latest --output-html result.html --research "What is the purpose of this function?"
このチームでは:
–model は、分析に使用するモデルを指定します。
–output-html は、解析結果を HTML ファイルに保存するパスを指定します。
–research を使用すると、コードを分析して答えてほしい質問をすることができます。
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
