Pixel Perfect:宣言性の時代の神話または現実?

インターフェイス開発の世界では、共通の概念があります – 「ロッジに完璧なピクセル」。これは、デザインマシンの最小ピクセルへの最も正確な複製を意味します。長い間、それは、特に古典的なウェブデザインの時代において、ゴールドスタンダードでした。しかし、宣言的なマイルの到着とさまざまなデバイスの急速な成長により、「Pixel Perfect」の原則はより一時的になりつつあります。理由を把握してみましょう。

Imperial Wysiwyg vs.宣言コード:違いは何ですか?

従来、多くのインターフェイス、特にデスクトップは、編集者の命令的なアプローチまたはwysiwyg(あなたが見るものです)を使用して作成されていました。このようなツールでは、デザイナーまたは開発者は要素を直接操作し、ピクセルに正確にキャンバスに配置します。それはグラフィックエディターとの作業に似ています – あなたはあなたの要素がどのように見えるかを見ることができ、あなたは間違いなくそれを配置することができます。この場合、「Pixel Perfect」の達成は非常に現実的な目標でした。

ただし、現代の開発は、宣言マイルにますます基づいています。これは、コンピューターに「このボタンをここに置く」ように指示するのではなく、取得したいものを説明することを意味します。たとえば、要素の特定の座標を示す代わりに、そのプロパティについて説明します。「このボタンは赤く、すべての側面から16pxのインデントを持ち、容器の中心にある必要があります。」 Freimvorkiは、React、Vue、Swiftui、Jetpackのようなものです。この原則を使用するだけです。

なぜ「Pixel Perfect」が多くのデバイスで宣言的なマイルで動作しない

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シフトなどの標準以外のインターフェイスを備えたデバイスや、将来の他のデバイスでも機能しない場合がありますが、今日でもわかりません。柔軟性と適応性 – これらは、現代世界で成功したインターフェイスを作成するための鍵です。

なぜプログラマーはニューラルネットワークを使用しても何もしません

今日、ニューラルネットワークはどこでも使用されています。プログラマーはそれらを使用して、コードを生成し、他のソリューションを説明し、ルーチンタスクを自動化し、アプリケーション全体をゼロから作成します。これにより、効率の向上、エラーの減少、開発の加速につながるはずです。しかし、現実ははるかに普及しています。多くはまだ成功していません。ニューラルネットワークは重要な問題を解決しません – 無知の深さを照らすだけです。

理解する代わりにLLMへの完全な依存性

主な理由は、多くの開発者がLLMに完全に依存しており、彼らが働いているツールを深く理解する必要性を無視していることです。ドキュメントを勉強する代わりに、チャットリクエスト。エラーの理由を分析する代わりに、決定をコピーします。建築ソリューションの代わりに、説明に従ってコンポーネントの生成。これはすべて表面的なレベルで機能しますが、非標準タスクが発生するとすぐに、実際のプロジェクトとの統合または微調整の必要性が必要であり、すべてが崩れます。

コンテキストと時代遅れの慣行の欠如

ニューラルネットワークは、一般化されたコードを生成します。彼らは、あなたのプラットフォームの詳細、図書館のバージョン、環境制限、またはプロジェクトの建築ソリューションを考慮していません。生成されるものはしばしばもっともらしいように見えますが、実際のサポートされているコードとは何の関係もありません。それらが時代遅れのバージョンのフレームワークに属している場合、または長い間効果のないまたは安全でないと認識されてきたアプローチを使用する場合、単純な推奨事項でさえも機能しない場合があります。モデルはコンテキストを理解していません – 統計に依存しています。これは、オープンコードで人気のあるエラーとアンチパットターンが何度も何度も再現されることを意味します。

冗長性、非効率性、プロファイリングの欠如

生成されたAIを生成するコードは、多くの場合冗長です。不要な依存関係、ロジックの複製、抽象化を不必要に追加します。サポートが困難な効果的で重い構造が判明しました。これは、ギャングのサイズ、応答時間、エネルギー消費が重要であるモバイル開発では特に深刻です。

ニューラルネットワークはプロファイリングを実施せず、CPUとGPUの制限を考慮していないため、メモリの漏れを気にしません。コードが実際にどれほど効果的であるかを分析しません。最適化は依然として手作りであり、分析と検査が必要です。それがなければ、アプリケーションは、構造の観点から「正しい」ように見える場合でも、遅く、不安定でリソース集中的になります。

脆弱性とセキュリティに対する脅威

安全を忘れないでください。 LLMを使用して部分的または完全に作成されたプロジェクトが正常にハッキングされた場合、すでに既知のケースがあります。理由は典型的なものです。危険な関数の使用、入力データの検証の欠如、承認の論理のエラー、外部依存関係の漏れです。ニューラルネットワークは、オープンリポジトリで見つかったという理由だけで、脆弱なコードを生成できます。セキュリティスペシャリストの参加と完全な改訂がなければ、このようなエラーは攻撃の入力ポイントに簡単になります。

法律はパレートであり、欠陥の本質

パレートの法律は、ニューラルネットワークではっきりと機能します。努力の20%のために結果の80%が達成されます。このモデルは、大量のコードを生成し、プロジェクトの基礎を作成し、構造を広げ、タイプをアレンジし、モジュールを接続できます。ただし、これはすべて時代遅れであり、現在のバージョンのライブラリまたはフレームワークと互換性があり、重要な手動改訂が必要です。ここでの自動化は、プロジェクトの特定の現実にチェックされ、処理され、適応する必要があるドラフトとして機能します。

注意楽観主義

それにもかかわらず、未来は励みに見えます。トレーニングデータセットの絶え間ない更新、現在のドキュメントとの統合、自動化されたアーキテクチャチェック、設計およびセキュリティパターンへのコンプライアンス – これがすべてゲームのルールを根本的に変更する可能性があります。おそらく数年後には、コードをより速く、より安全で、より効率的に書くことができ、LLMに真の技術的な共著者として依存することができます。しかし、今のところ – 悲しいかな – 多くのことをチェックし、書き直し、手動で修正する必要があります。

ニューラルネットワークは強力なツールです。しかし、彼があなたに反対するのではなく、あなたのために働くためには、いつでもコントロールするための基盤、批判的思考、意欲が必要です。

ジンジャータプロトタイプウィンドウ

私はあなたの注意フォーク・ケイトのテキストエディターをGingeritaと呼んでいます。なぜフォーク、なぜ、目標は何ですか?修正を待たないように、ケイトチームからの機能を追加したり、メインブランチへの修正を採用したりするように、自分の仕事に必要な機能を追加したいと思います。
現時点では、Windows用のプロトタイプバージョンが現在利用可能であり、最小限の変更を伴うケイトのほとんどバニラバージョンです。 Gingeritaの場合、2つのプラグを開発しました。エディターとビルドインブラウザーからの画像の画像、Webプロジェクトのデバッグ、またはChatGptなどのアシスタントとAIと対話するための画像です。

Windows用のバージョンは、以下のリンクでテストできます。
https://github.com/demensdeum/Gingerita/releases/tag/prototype

Demensdeum製品のサポート

サポートページへようこそ!

質問がある場合、Demensdeum製品の問題、または改善を提供したい場合は、常にお手伝いします。

私たちに連絡する方法:
support@demensdeum.com

3〜5営業日以内に控訴に答えようとしています。

手紙で何を示すべきか:

製品の名前
バージョン(既知の場合)
問題の詳細な説明
スクリーンショットまたはビデオ(可能であれば)
問題が発生したデバイスとオペレーティングシステム

私たちの製品を使用してくれてありがとう、そしてあなたの経験を可能な限り便利で快適にするよう努めています。

心から、
Demensdeumチーム

バイブコアトリック:なぜLLMが固体、乾燥、きれいに動作しないのか

CHATGPTなどの大規模な言語モデル(LLM)の開発により、ますます多くの開発者がそれらを使用してコードを生成し、設計アーキテクチャを生成し、統合を加速します。ただし、実用的なアプリケーションでは、それは顕著になります。建築の古典原則 – 固体、乾燥、清潔 – LLMコドゲンデーションの特性とうまくやっていません。

これは、原則が時代遅れであることを意味するものではありません – それどころか、それらは手動開発と完全に連携しています。しかし、LLMでは、アプローチを適応させる必要があります。

なぜLLMが建築原則に対処できないのか

カプセル化

インクシレーションでは、システムの一部間の境界、開発者の意図に関する知識を理解し、厳格なアクセス制限に従う必要があります。 LLMは、多くの場合、構造を簡素化したり、理由もなくフィールドを公開したり、実装を複製したりします。これにより、コードはエラーに対してより脆弱になり、アーキテクチャの境界に違反します。

要約とインターフェイス

抽象的な工場や戦略などの設計パターンには、システムの全体的な見方が必要であり、そのダイナミクスを理解する必要があります。モデルは、実装を保証せずに明確な目的なしでインターフェイスを作成したり、レイヤー間の接続に違反したりできます。結果は、過剰または非機能的アーキテクチャです。

dry(donolt繰り返し自分で繰り返します)

LLMは、繰り返しコードを最小限に抑えようとはしません – それどころか、一般的なロジックを作成するよりもブロックを複製する方が簡単です。リクエストに応じてリファクタリングを提供できますが、デフォルトでは、たとえ冗長性につながる場合でも、「自己適切な」フラグメントを生成する傾向があります。

クリーンアーキテクチャ

Cleanは、厳格な階層、フレームワークからの独立性、指向性の依存性、およびレイヤー間の最小のつながりを意味します。このような構造の生成には、システムのグローバルな理解が必要です。また、LLMは、建築の完全性ではなく、単語の確率のレベルで機能します。したがって、コードは混合され、依存の方向に違反し、レベルへの単純化された分割が違反されます。

LLMを使用するときにうまく機能する

乾燥する代わりに濡れています
WET(すべてを2回書く)アプローチは、LLMでの作業においてより実用的です。コードの複製は、保持のモデルからのコンテキストを必要としません。つまり、結果は予測可能であり、正しく修正しやすくなります。また、非自明なつながりやバグの可能性を減らします。

さらに、複製はモデルの短いメモリを補うのに役立ちます。いくつかの場所でロジックの特定の断片が見つかった場合、LLMはそれをさらなる生成で考慮に入れる可能性が高くなります。これにより、伴奏が簡素化され、「忘却」に対する抵抗が増加します。

カプセル化の代わりに単純な構造

複雑なカプセル化を回避し、コードの部分間のデータの直接送信に依存すると、生成とデバッグの両方を大幅に簡素化できます。これは、MVPの迅速な開発または作成で特に当てはまります。

簡略化されたアーキテクチャ

プロジェクトのシンプルでフラットな構造は、最小量の依存関係と抽象化を備えており、発電中はより安定した結果をもたらします。モデルはこのようなコードを簡単に適応させ、コンポーネント間の予想される接続に違反することが多い場合があります。

SDK統合 – 手動で信頼できる

ほとんどの言語モデルは、時代遅れのバージョンのドキュメントでトレーニングされています。したがって、SDKをインストールするための手順を生成する場合、エラーがよく表示されます。時代遅れのコマンド、無関係なパラメーター、またはアクセスできないリソースへのリンク。練習のショー:公式のドキュメントと手動チューニングを使用して、LLMを補助的な役割にします。たとえば、テンプレートコードや構成の適応を生成します。

なぜ原則がまだ機能しているのか – しかし、手動開発で

固体で乾燥した清潔から清潔からの困難は、LLMを介したコドヘゲエネーションに懸念していることを理解することが重要です。開発者がコードを手動で書き込むと、これらの原則は引き続き価値を示し続けます。つながりを低下させ、サポートを簡素化し、プロジェクトの読みやすさと柔軟性を高めます。

これは、人間の思考が一般化する傾向があるという事実によるものです。私たちはパターンを探しています。個々のエンティティに繰り返し論理を持ち込み、パターンを作成します。おそらく、この動作には進化的なルーツがあります。情報の量を減らすと、認知リソースが節約されます。

LLMは異なる行動をとる:彼らはデータの量から負荷を経験せず、貯蓄を努力しません。それどころか、複雑な抽象化を構築および維持するよりも、それらが重複した断片化された情報を使用して作業するのが簡単です。そのため、繰り返し構造と最小限のアーキテクチャの重大度を備えた、カプセル化なしでコードに対処する方が簡単です。

結論

大規模な言語モデルは、特に初期段階で、または補助コードを作成する際に、開発において有用なツールです。ただし、アプローチを適応させることが重要です。アーキテクチャを簡素化し、抽象化を制限し、複雑な依存関係を避け、SDKを構成する際にそれらに依存しないようにすることが重要です。

固体、乾燥、きれいの原則はまだ関連していますが、人の手に最善の効果をもたらします。 LLMで作業する場合、手動で簡単に完成できる信頼できる理解可能なコードを取得できる簡素化された実用的なスタイルを使用することが合理的です。そして、LLMが忘れる場所 – コードの複製は彼が覚えておくのに役立ちます。