私がSCADAに書いたように。 パート8 ...

すべての人に良い一日を! 今日は金曜日であり、Habrの最高の伝統です。私の今日の投稿が週の終わりに良いトピックになることを願っています。 前回の出版から1年以上が経過しており、この間、非常に多くの新しい興味深いイベントがありました。このトピックについて引き続き関心のあるすべての人々に伝えたいと思います。



このトピックに関する以前の記事はすべて検索で見つけることができます。



昨年の終わりにいくつかのクリティカルマスが成熟したという事実から始めたいと思います。そのため、座って、スカッドシステムの新しいバージョンをリリースするプロセスを開始する必要がありました。 この間に蓄積された経験とベストプラクティスは、完全に新しい製品コンセプトの基礎となりましたが、そのアーキテクチャの整合性とイデオロギーが維持されていれば提供されました。 それで、私のスクーダの新しいバージョンである2.0のリリースの準備ができました!



それは非常に真剣に再設計されましたが、単純なコンセプトさえ好むでしょう-それは書き直されました。 はい、アイデアがあり、プロトタイプがあり、戦闘テストと実際のアプリケーションで機能し、証明された既製のアーキテクチャと製品がありました。 これに加えて、私の新しいクレイジーなアイデアに基づいて、完全に新しいシステムが作成されていますが、上記のすべてを考慮しています。



単一のプロジェクトエディターを作り直すために私の手をかゆみ-MDIの概念にそれをもたらす必要があった。 これには、使いやすさ、そして実際には常識が必要でした。 また、まったく新しいグラフィカルインターフェイスエンジンのアイデアは、長い間空中にありました。 過去の記事では、これについて少しメモを取り、サンプルのプロトタイプを示しました。 現在、これらのアイデアとプロトタイプは、グラフィックエンジンの新しいアーキテクチャとグラフィックエディタ自体の基礎を形成しました。 スケジュールの稼働時間を使用して-もちろん、アルゴリズムのエディターが変更されました。グラフィック(FBD)とスクリプト(C#)の両方です。 これまでのところ、すべては使いやすさと小川に限定されていましたが、新しいシステムのアルゴリズムエンジンの基礎としてその機能をさらに拡張するためのアイデアを出し始めましたが、これは今後の記事のトピックになります(願っています)。



私が新しいバージョンの開発に着手することを真剣に妨げた最も重要なことは、そのようなシステムの多くの開発者が新しいバージョンの開発と開発の段階になるときに犯す間違いです。 これは非常に深刻なつまずきのブロックであり、滑らかな道路では深刻な障害となり、ほとんどの人がそれに沿ってつまずきます。 古いものを否定したり、サポートしない新しいものを作ることは非常に困難です。多くの場合、古いものは本当に新しく、古いものをこの新しい概念の枠組みに詰め込むことができないためです。 しかし、ほとんどのユーザーは古くて新しいものではありませんが、製品開発者が新しいものはそのようなものであり、すべての古いものをやり直すか放棄することを決定したため、古いものから新しいものに伸びるだけの連続した線です。彼。 この問題は私を非常に深刻に遅くさせました。 しかし、私はそれについて少し議論し、1つの興味深い方法を試してみることにしました。これは、新しいシステムに切り替える際の問題を最小限に抑えることができるように思えます。 さらに、新しいシステムはプロジェクトの既存の古いバージョンに統合でき、段階的に徐々に開発者に既存および既存のシステムの新しいバージョンにスムーズに移行する機会を与えます。 しかし、このアイデアの詳細は本文でもう少し詳しく説明しています。



MDIサポートを備えた単一の開発環境。



開発環境をマルチドキュメントアーキテクチャに移行するには多少の手間が必要でしたが、これらのケースの現在の状態から判断すると、ささいなことでの手間はまともです。 しかし、少なくとも、システムのウィンドウの構成とそのドッキングは、人間のように見えて機能します。 残念ながら、今はあまり暇がないので、この記事は写真やビデオでいっぱいではないので、少しだけ具体的に説明します。







新しいグラフィックエンジン



最初から書き直されたシステムの最も基本的な部分。 そして、書き直されただけではありません。実際、私は新しいテクノロジーに基づいて、システムの完全に新しいグラフィックエンジンを作成しました。 同時に、実際にエンジニアリングと設計の作業を2つの別々の領域に分割するための基礎となるアイデアを彼に組み込んでみましたが、ユーザーインターフェイスの開発における単一の結果を目指しました。



エンジニアの実践者として、私は長い間、創造的な要素はトレーニングやトレーニングの対象ではなく、持続的な骨の折れる開発から才能は生まれないと考えています。 それで、習得は生まれて、改善されることができます。 フォークで私を選んでも、誰も才能を注入して改善できると私を納得させないでしょう。 私は、美しく、最も重要な便利なインターフェースを描く有能なエンジニアを信じていません! 実際には、私はこれを見たことがない。 その便利さのアイデアを思いつく-はい! ドロー-いいえ! カテゴリー的に! これは才能です! そして、彼はエンジニアリングとの組み合わせでは珍しいです。 そのため、グラフィックインターフェイスの開発作業が常に2つの領域(設計、実装)に分割されるように常に努めました。 彼らが言うように:シーザー-シーザー、錠前屋-...そしてそれを便利で、美しく、機能的にする唯一の方法。 そして、これらのコンポーネントは両方とも、職種によって、デザイナー(設計)とエンジニア(実装)の2つの異なる人を作る必要があります。 新しいグラフィックシステムでは、クロスカットを実現するために、デザインレイアウトから実装へ、またはその逆への移行のサポートを簡素化することにしました。 つまり、エンジニアがスケッチで作成したものをそのまま(ベクターではなくベクターで)デザイナーに転送し、デザイナーからそのまま(ベクターではなく写真で)スカッドに戻して、スカッドを使用してグラフィックの編集を続けることができます。デザイナーがしたことを壊すことなく。 今日、このようなインターフェース開発の方法に関しては、デザイナーとの相互交換はグラフィック画像のレベルでのみ実行されます。グラフィック画像は、基板として、またはバックグラウンドとして最大で使用されます。 エンジニアがアーティストであるのをやめてタスクを実行し、アーティストがモデルを最も適切に受け入れてエンジニアに返すことができるようにしたいと思います。 これは、将来のシステムの目標の1つです。



そして、新しいシステムのグラフィックスの2番目の主なタスクは、プロセッサの負荷を減らすことです。 私のスカッドの現在の最初のバージョンでは、すべてのグラフィックスはプロセッサーに依存しているため、これは大規模なソリューションに現れ始めていました。 また、グラフィカルインターフェイスのインタラクティブ機能にも影響を及ぼし、ユーザーとの対話の可能性の一部を制限していました。







新しいアルゴリズムエディター



この部分では、すべての改善は主にディスプレイの外観とアルゴリズムを操作する便利さのみに関係していました:視覚言語、新しいグラフィカルシェルとレンダリング、およびテキスト言語、独自のスタジオスタイルのパンを持つ新しいエディター。 また、新しいバージョンの一部として、ユーザーが求めたいくつかの新しい作業に取り組み始めましたが、これまでは計算機のコアのレベルでのみ行っており、まだ取り出していません。 スクリプト言語に基づいて独自のFBDブロックを開発し、スクリプト言語をグラフィック画面に接続して、コンテンツを直接操作したり、ユーザーコンポーネントでインターフェイスを補完したりできるようになります。



以前のバージョンとの互換性。



前述のとおり、ほとんどのScad開発者に共通する問題の1つは、新しいバージョンへの移行中に開発の継承をサポートすることです。 誰もが、継承と新しいものに転送できるものはすべてあると言いますが、実践が示すように、「ニュアンス」と「制限」のリストはしばしばそのようなステートメントを否定します。 「遊びましょう。」 私はこれが一般的なtrapだとは言いませんが、-あるべき場所があり、非常に頻繁にあります。



私自身は、このことを多少なりとも有能に行うことで、システムプロジェクトのネイティブの新しい形式での開発時の読み込みと保存を禁止し、プロジェクトの読み込みを前のバージョンの形式でのみ行うことを許可することにしました。 一部の機能をデバッグする場合でも、まずバージョン1.0でプロジェクトを作成してから、バージョン2.0でそれを開いてチェックを実行する必要があります。 そして、機能が完全に新しい場合-チェックして、ゼロから簡単なプロジェクトを作成します。



少なくとも、この制限により、新しい形式への変換で古い開発のサポートを正確に実行する必要があり、今のところうまくいくようです。



今月末までに、システムのユーザー間でテスト用の予備バージョンを配布し、フィードバックを受け取る予定です。 しかし、これは現在、システムの現在の第1バージョンで実際に作業している人の間でのみ行われます。



互換性に加えて、ネットワークプロトコルレベルで、新しいバージョンは第1バージョンの仕様に完全に準拠することが決定されました。 これにより、最初のバージョンで動作時間が終了し、新しいバージョン2.0で開いて、たとえばAWPノードを変換したり、新しいグラフィックで新しいノードを追加して、実際に動作するシステムのフレームワーク内で既に起動したりすることができます。 同じ仕様のサポートのおかげで、この手順は、すべてを壊すことなく、システムの新しいバージョンへのスムーズな移行を提供し、グローバルシャベルとすべてを連続してやり直します。 私の考えがそれを正当化するかどうか見てみましょう。 開発者とユーザーからのフィードバックだけでなく、練習も表示されます。



All Articles