ブラックジャックを使用し、ニューロンを使用しないpix2codeを所有する

ニュートン-ライプニッツ、ロバチェフスキー-ガウス、ベル-グレー、ボンド-ラッセル...これらの姓のペアには共通点が1つあります。これらは、いわゆる複数の発見の例として引用することができます。



私のプロジェクトでも同様のことが起こりました。 1年ほど前に、ラスターイメージに基づくレイアウト-HTML生成システムの開発を開始しました。 しばらく経ち、2017年5月に、pix2codeという名前で作品が公開されましたが、専門メディアでの良好な配信を得ました。 時間が経っても、私は絶望せず、自分の道に沿って移動しました。 しかし、最近、恐ろしいことが起こりました。pix2codeに基づくFloydHubの開発者は、ニューラルネットワークを作成し 、写真に基づいてWebサイトを作成しました 。 RuNetでは、このニュースが取り上げられ、多くの人々がFloydHubのリリースに気付きました。 これは、以前に設定した計画に従って、デモをリリースしなければならなかった瞬間です。 しかし、ご存知のように、最善は善の敵であり、プロジェクトを「ますます」改善したいという願望がリリースを無期限に延期しました。



その瞬間、私は気づきました：コーディング、これはもちろん良いことですが、あなたは自分の仕事を明らかにする必要があります。 会う：くるみ割り人形は、ブラックジャックを使用したpix2codeの代替手段ですが、残念ながらニューロンは使用していません。



まず第一に、私は自分自身を修正したい。 くるみ割り人形の多重発見（これまでのプロジェクトの名前の履歴は括弧で囲まれていない）、pix2codeを呼び出すことはできません。タスクの実装は根本的に異なります。 しかし、両方のシステムの目的は完全に一致します。単純なラスターイメージを受け入れ、受け入れ可能なhtml / cssレイアウトを返すアルゴリズムを作成します。一方で、元のイメージを正確に再作成し、一方で、吐き気とさらにメンテナンスに非常に適しています。

くるみ割り人形の予約

セットに近い問題を解決するために、すでに製品があります（特定のサービスには広告を出しませんが、Googleは非常に簡単です）。

1. PSDからhtmlを生成します。 サイト構築の世界にとって理想的なスキームのように思えます。デザイナーがPhotoshopでレイアウトを作成し、プログラマがhtmlコードを受け取ります。 問題は、そのようなレイアウトの品質が適切なレベルである必要があることです。デザイナーはページがどのようにレイアウトされているかを理解する必要があり、この理解を独自のレイアウトを構築するロジックに入れる必要があります。 基本的に、適切に作成されたpsdレイアウトは半分完成したサイトです。 理想的な世界では、そのようなWebデザイナーのスキルは基本です。 現実の世界では、残念ながら、そのような能力を持つデザイナーの割合は、望まれることを多く残しています。
2. サイトコンストラクター。 プログラミングの経験のない人がプログラムに入り、ドラッグアンドドロップで要素を投げ、最終的にファッショナブルなスタイル、作業スクリプト、および最新のWebのすべての魅力を備えた実際のWebサイトを取得します。 おそらく適応的です。 おそらくクロスブラウザです。 短所、私はあなたがすべてを自分で知っていると思います。 結果のコードの品質と、それ以上のサポートの複雑さも省略します。 私がここで目にする最大の問題は、役割の組み合わせです。 デザイナーがHis下のPhotoshopを疑わしいデザイナーと交換することを想像するのは、建築家がLEGOを使用してモデルを作成するのを想像するのと同じくらい困難です。 そのため、専門家のチームとして働く代わりに、サイトは「あなた自身のデザイナー/フロントエンド/ソスペシャリスト」を作成することがわかりました。
3. ウェブサイトのテンプレートデザイン。 コンストラクターの修正バージョン。 テンプレートを選択-フィールドに入力-完了。 決定論により、高品質のコードを期待できます。 しかし、選択肢は限られています。

サイトをすばやく取得するこれらの各方法は、特定の条件でタスクに完全に対処します。 それについてのこれ以上の話は意味をなさない。 それらに触れたのは、img-> htmlアルゴリズムの目的がどのように見え、どのようなコンテキストでそれらを検討する価値があるかをより正確に明確にするためだけです。



FloydHubの作品に関する出版物へのコメントでは、「さようなら、レイアウトデザイナー」、「-フロントエンダー」などのようなものがよく見られます。 絶対に、これは真実ではありません。 そのpix2code、Nutcracker、その他の類似物はフロントエンド開発者の職業のキラーと見なされるべきではありません。 フロントエンド開発者は真空では機能しません-顧客の要求、企業標準、論理、専門的な才能、そして最終的には才能があります。 これらのコンポーネントを最新レベルのAIに組み込むことは不可能です。



では、なぜそれが必要なのですか？ 最後に要点を説明し、くるみ割り人形の要件を定義します。 アルゴリズムは画像構造を認識し、この構造内のオブジェクトの可能な限り多くの特性（色、フォント、インデント...）を選択し、認識された構造の構築を実装するコードを生成する必要があります。



必要ありません：

• すべての属性を認識する
• ピクセル間の画像を再作成する

理想的には、任意のスキルのコーダーが残りの15％を簡単に追加できるように、アルゴリズムがコードの約85％を正しく生成することで十分です-ここでは、テキストのフォントを正しく示し、背景に画像を配置し、重要でないケースを「信頼」することができます-主なことは、コードの構造を根本的に変更する必要がなく、たとえば、フッターのこれら3つの列を高さで揃える方法について考える必要があることです。



繰り返しになりますが、言い換えると、目標：明白な要素を実行してhtml / css組版を作成する作業を自動化し、アルゴリズムが間違っていたり自明ではない非常に単純なケースを残して、天才を見せることを可能にすることです。



ご覧のとおり、このようなモデルは次の場合に役立ちます。

• 大きな障害の時代のウェブエージェンシー-他のジュニアやアウトソーシングを雇うよりも安くて速い。
• デザインのプロトタイピングおよび/または「テスト」のため-フロントエンドソリューションをより柔軟にチェックすることが可能になります。
• 「私は彼らのようなサイトが欲しい」-はい、はい、スティックには両端があります。ここでは、盗難のリスクなしで行うことはできませんが、そのような瞬間を予測する必要があります。

pix2codeについて少し

私の潜在的な競争相手についていくつかの言葉を言います。 私は敬意を持って行われた仕事を尊重し、明らかに賢明で才能のある人々を「責める」ことすらないことをすぐに予約します。 私は彼らが何をしたかについての私の意見を表明するだけであり、さらに重要なことは、現在の記事について、なぜ私がそれを違うようにしたのかについてです。



私が最初にタスクを引き受けたときに頭に浮かんだ最初の考えは、「ニューロン」です。 実は、インターネットから膨大な数のページを取得し、（大まかに言って）スクリーンショットと対応するhtmlコードからデータセットを作成し、ニューロンを構築します...より良い回帰ニューロン...、いや、より良いベイジアンニューロン...、いや、より良いニューロンの構成...はい、たくさんのニューロン、深く深く。 トレーニングサンプルに対して設定-利益！ だから？



そうでしょうが、そうではありません。 この道を進むほど、問題が多く見えました。 問題は技術的なものではなく、概念的なものです。 トレーニングサンプルを作成することから始めましょう。 ご存知のように、1つのボリュームが高度な機械学習ではありません。 もちろん、ディープラーニングを適切に適用するには、サンプルを大幅に大きくする必要があります。 しかし、それが代表であることも同様に重要です。 しかし、これには問題があります。 サイトの90％が...控えめに言っても、借りたくないレイアウトを持っていると言っても、私はあまり間違えないと思います。 視覚的に類似したサイトは、構文的に根本的に異なる植字を持つことができるという事実により、状況はさらに複雑になります。 この状況になるには？ 方法論ごとに、フレームワークごとに個別のサンプルを作成しますか？ 独自のトレーニングセットを生成しますか？ これらの質問を解決するためのオプションがあることを理解していますが、私の意見では、実装の複雑さはニューラルネットワークを使用する利点を上回ります。



また、もう1つ注意が必要です。 ここでは、機械学習のすべての支持者の目に触れる危険があります。 入力データを処理するためのpix2codeの操作を説明する記事の紹介で書かれているように、「エンジニアリング」特性を抽出するプロセスも専門的なヒューリスティックも設計されていません。 これが機械学習の本質であると思われます。専門家によって事前に設定されたルールに依存するのではなく、データに直接含まれるものに基づいて、既存の自然法則を復元します。 しかし、ここで私は議論しなければなりません。 先ほど言ったように、有能な専門家がガイドするすべてがマークアップコードに埋め込まれているわけではありません。 業界には時間とともに変化する他のメタパラメータがあり、生成されたコードの品質が適切なレベルに維持されるように監視する必要があります。 あなたは私に嫌悪感を与えることができますが、このタスクで専門家の発見的手法の要素を拒否することはできません。



しかし、それらを使用することの根本的な不可能性や誤りではなく、ニューラルネットワークの道から遠ざかったのではなく、強力で複雑なツールを使用する平凡な怠inessと不十分な資格を認めなければなりません。 他方、私は、仕事のオリエンテーションにおいて、目標ではなく、労働手段に対して最も間違っていると考えています。 したがって、私は私にとってより論理的なパスから始めることにしました。これについては以下で説明します。 もし私がこの仕事を放棄せず、状況が本当にそれを必要とするなら、おそらくニューラルネットワークも使用するでしょう。



しかし、pix2codeとFloydHubの開発に戻ります。 私はすべての公開された資料を読みましたが、上記で説明した問題の解決策を見つけることができませんでした。 さて、コードが実際に機能する場合、これはそれほど重要ではありませんか？ そもそも、例で示されているものを除き、画像で結果を得ることができませんでした。 これがプロトタイプであることを考えると、あなたは許すことができます。

しかし、私が理解できなかった最も重要なこと。 私は本質を深く掘り下げなかったことを正直に認めており、コメントで説明してくれれば感謝しますが、550回の反復後に元のものとまったく同じコードが得られることをどのように説明できますか？ それは完全に、100％です。 同じコメントがどのようにそこに終わったかは理解できますが、まったく同じ画像名とまったく同じ相対パスが非常に驚いています。



ここに私は2つの考えがあります：これは詐欺（私は心から信じたくない）、またはこれは私が見た中で最も厳しい再訓練です。 繰り返しますが、プロジェクトを圧倒する目的はありません。これは、セクションの冒頭で説明した問題が考慮されていないという事実の結果である可能性が高いと言いたいだけです。 開発者はこの状況を修正すると信じていますが、現時点では私の議論に対する反論はありません。 そのアーキテクチャに私を導いた議論は、最終的にくるみ割り人形の基礎になりました。

建築

ある賢い人は、問題を解決する方法を探しているとき、この問題に影響を与える5-6の人気のある記事を見つけ、これらの記事で最も批判されている方法を選択すると言いました。 この記事には、最新のアプローチと驚くべきノウハウは含まれていません。 すべてが非常に平凡でシンプルです。 それにもかかわらず、幸運なことに、これをやればやるほど、アプローチの正しさを確信します。



レイアウト作成の自然なプロセスを理解することから始めることにしました。 正直に言って、ほとんどのコーダーは永遠の、唯一無二のコピーアンドペースト方式を使用しています。 最初は、コピーアンドペーストが文字通り使用されます。 私は空腹の学生として、最初にお金を稼いだ後、グーグルに「フッターをページの一番下まで押してください」、「ブロックを垂直に揃えて」、「同じ高さの列」と入力する方法を覚えています。 なじみのないブロック配置パターンに遭遇した場合、検索バーで自然言語で記述し、次のチュートリアルでサンプルコードを見つけて、最終的にニーズに合わせて変更します。 さらに、経験があれば、グーグルへの呼び出しはますます少なくなりますが、原則はなくなりません。次のテンプレートに直面すると、頭から適切な例を取り出して、現在の状況に適応させます。



科学では、そのような考え方は先例と呼ばれます。 また、ITには、このプロセスの実装があります。ケースベースの推論または「ケースベースの推論」です。 この方法は非常に古く（ただし、ニューラルネットワークを幼児とも呼ぶことはできません）、前世紀の70年代に歴史的に衰退し、確かに、現在では開発のピークからはほど遠い状態です。 ただし、この状況では、説明したプロセスに完全に適合します。



このアプローチに慣れていない人のために、まず、たとえばJanet Kolodnerの記事を読むことをお勧めします。次に、この記事を読み続けることをお勧めします。



CBRを1つの文で説明すると、これは古いソリューションを同様の状況に適応させることで問題を解決する方法であると言えます。 CBRの重要な概念はユースケースです。 ユースケースは要素のトリプルです：

• 問題は、「解決する」必要がある世界の状態です。
• 解決策は、問題を修正する実際の方法です。
• 結果は、問題を解決した後の世界の状態です。

ユースケースは、リポジトリまたはデータベースに保存されます。 保存方法、索引付け、構造-未解決の質問：適切なツールを使用できます。



事例ベースの推論で最も重要な点は、いわゆるCBRサイクルです。 実際、このサイクルは問題を解決する方法です。







サイクルは4つのステップ（4つのRE）で構成されます。

• 検索：問題の問題に最も近い（類似の）ユースケースが、ユースケースデータベースから取得されます。
• 適応（再利用）：抽出されたソリューションは、新しい問題によりよく適合するように適応されます。
• 改訂：適応されたソリューションは、その適用前または適用後に評価できます。 いずれにせよ、ソリューションが適合しない場合は、再度適合させるか、追加のソリューションを抽出する必要があります。
• 保持：ソリューションがテストに成功した場合、新しいユースケースがデータベースに追加されます。

この問題を解決するためにケースベースの推論がどのように適用されたかを正確に説明する前に、システムの一般的なアーキテクチャを説明する価値があります。



グローバルな意味では、処理は2つの部分で構成されます。

1. 画像認識
2. HTMLコード生成

最初の段階の主なタスクは、イメージからすべての重要なブロックを抽出し、添付ファイルに関してそれらからツリー構造を構築することです。



画像処理はいくつかの段階で行われます。

1. すべてのテキストが認識され（ここではtesseractが助けになります）、それに関連するすべてのプロパティ（フォント、色、サイズ、スタイルなど）が抽出されます。 -そして、さらに干渉しないように、背景色で完全に上書きされます。
2. すべての写真が取得されます-つまり その後、すべてがimgタグまたはブロックの背景画像になります。 それらも上書きされます。
3. 最後に、すべてのブロックが認識され、そこから階層、つまりツリーが組み立てられます。

各ノードが潜在的なdom要素であるこのようなツリーを組み立てることは、最初の段階のタスクです。 各ノードは、一連の定義済みパラメーターによって記述されます。 一般に、ツリーの組み立ては簡単な作業ではありません。 ただし、現時点ですべてのアーキテクチャについて、この段階が最適に実装されていると言わなければなりません。デザインがてんかんではなかった場合、画像構造の非常に正確な記述がほとんど常に保証されます。



ツリーの準備ができたら、2番目の段階に進みます。 プレフィックスの方法でツリーを歩き回り、cbr-loopを使用して各ノードを処理します。



The Nutcrackerの事例ベースの推論の実装をもう少し詳しく説明する時が来ました。



くるみ割り人形のユースケースの構造は次のとおりです。

• 問題：ノードの一連のプロパティと、json形式の最も近い子孫のプロパティ。
• 解決策：記述された構造のレイアウトを実装するjinja2-template htmlおよびcssコード。
• 結果：特定のケースのソリューションテンプレートから生成されたHTMLおよびCSSコード。

ユースケースは、MongoDBデータベースのJSON表現で保存されます。 これを「グローバルリポジトリ」と呼びます。 ローカルストレージもあります-それについては少し後で。 グローバルストレージでは、ユースケースには問題と解決策しかありません。 結果はありません-結局、テンプレートが特定の状況に適用されたときにのみ表示されます。



そして今、画像の構造を記述するjsonオブジェクトと、各ノードの作成方法に関する情報を含むユースケースベースがあります。 前に言ったように、ツリーのトラバースはプレフィックスです。つまり、ルートから開始します。 ルート自体のプロパティを取得し、それに最も近い子孫のプロパティを追加します-ここに問題があります。



抽出段階が来ました。 最も類似した問題の前例を見つける必要があります。 mlスペシャリストの創造性の範囲は次のとおりです。 実際、マルチクラス分類の古典的な問題があります。オブジェクトのプロパティがあり、n個のクラスがあります（データベースにはn個のユースケースがあります）。 なじみのないオブジェクトをいずれかのクラスに関連付ける必要があります。 ロジスティック回帰を試したいですか？ どうして！ たぶんRandomForestの方がいいですか？ そうです！ 結局、誰もニューラルネットワークをキャンセルしませんでした！



しかし、最初の反復では、k個の最近傍の方法で管理しました。 さらに、kは1に等しくなります。正しく理解できました。ユークリッドメジャーを使用して、最も近いオブジェクトを見つけました。 すでにこのシンプルなアプローチのすべての欠点に直面していますが、許容できる品質を達成し、この時点で行き詰まることなく、徐々にすべての面に沿って動き、全体像を終わらせることができます。



最も近いユースケースを受け取ったら、処理中のノードにそのソリューションを適応させる必要があります。 ここにはいくつかのタスクがあります。

1. jinja2のテンプレートから実際のコードを取得します。
2. cssクラスの処理：ほとんどの場合、前の手順で、この名前のクラスに既に対応しています。 この状況を処理するためのオプションがいくつかあります。完全に新しいクラスを作成するか、htmlで必要な置換を行います。 オブジェクトのプロパティを指定する別のクラスを作成し、必要に応じてHTMLに追加します。 または、これは前の結果の特殊なケースであり、何もしないことを理解してください。したがって、すべてが素晴らしいです。

事例ベースの推論の規範によれば、次のステップは結果を評価することです。 そして、ここで、私は告白します、私は停滞しています。 レイアウトが本当にあなたが望むものであると評価する方法は？ どのような基準を思いつくことができますか？ 苦痛に満ちた苦痛と洞察力の探求により、私は関数に「return True」という改訂版を書き、先に進みました。 私はまだ評価を実施していません。 そして、おそらく、私は決して気付かないことを教えてくれます。抽出段階で適切な分類器を作成し、適切な適応を行うだけで十分です。



最後のステップは保存することです。 最初は問題のみを含んでいた先例は、その解決策と結果を受け取りました。 後でリポジトリに記録して、同様のブロックを作成しやすくする必要があります。 しかし、ここで私はトリックを思いつきました。 ユースケースは「グローバルストレージ」ではなく、ローカルストレージに記録されます。 ローカルストレージは、特定のイメージの一種のコンテキストです。 現在のドキュメントに既に存在するブロックが含まれています。 これにより、第1に、類似の前例をより簡単に見つけることができ、第2に、適応に費やすリソースが少なくなり、同じ構造が異なる場合にエラーを最小限に抑えることができます。 次のツリーノードを処理するとき、ローカルストレージから同様の問題を最初に抽出しようとし、その後、類似するものが見つからない場合にのみ、アルゴリズムはグローバルストレージに移動します。



これらのすべての手順があまり正式ではない方法で記述されている場合、本質は次のような推論に要約されます。

1. 最高レベルの抽象化の観点からレイアウトを検討します。
2. たとえば、これは3列のレイアウトであることがわかります。 このようなレイアウトをどのように作成するのでしょうか？
3. 最適なケースについては、ユースケースデータベースを探しています。
4. htmlおよびcssテンプレートを取得します。
5. このテンプレートでは、問題のケースの特定の値（幅、色、インデントなど）を使用します。
6. 次に、各子孫を再帰的に処理します。
   
   
   
   
   1. ここにあるのは...左の列には、5つのブロックが縦に並んでいます。 作り方 ベースを見てみましょう...
      
      
      
      
      1. ...
      
      
      
   2. 中央のブロックには、垂直に配置された3つのブロックがあります。最初のブロックは高さの20％、2番目-70％、3番目-10％を占めています。
   3. など

例

手紙にうんざりしていませんか？ 今、写真があります。 そしてコード。



個人的には、単純なものから複雑なものへと移行します。 たくさんの要素を含む意図的に複雑なサイトをとることは、あなたの精神を殺し、眠りを失い、結果と失敗の原因を掻き立てる方法です。 ですから、私の「Hello World」は基本的に典型的なサイトのモジュラーグリッドです。







このレイアウトを準備しました。コンテンツの幅が固定されたサイト、ゴム製のキャップ、ページの下部に押し付けられた地下室、およびサイドバーです。 くるみ割り人形がどのように対処するかを見てみましょう。



最初のステップはパターン認識です。 結果は次のとおりです。





ここでの主要なプロパティは、タイプ（ノード、テキスト、または画像）と整列（0-子は水平方向、1-垂直方向）です。 json分析は自分で行うことができますが、わかりやすくするために、アルゴリズムが構築したツリーを表示しました（ブロックの背景色は円の色に対応し、黒い円は構成ブロックに対応し、円内の数字は位置合わせパラメーターに対応します）：







ツリーウォークを開始します。 ルートノードの説明から問題を形成します。





ユースケースデータベースは、最も類似した問題のあるユースケースを検索します。 次の使用例が取得されます。





ご覧のとおり、htmlコードを生成するには、子孫からcontentプロパティを取得する必要があります。これを行うには、現在のノードと同じ方法で各子孫を処理する必要があります。 したがって、内容が空の文字列であるすべての葉に到達するまで、ツリーを一周します。



cssに関しては、テンプレートから生成されたすべてのコードは単一のファイルに書き込まれ、競合は途中で処理されます。



その結果、次のコードが取得されました（それぞれ大きな画像が処理され、そのような大きな値が取得されました）。

 <!DOCTYPE html> <html> <head> <title> </title> <meta charset="utf-8"/> <link href="reset.css" rel="stylesheet" type="text/css"/> <link href="style.css" rel="stylesheet" type="text/css"/> </head> <body> <div class="wrapper"> <header> </header> <div class="content container"> <aside class="left"> </aside> </div> </div> <footer class="container"> </footer> </body> </html>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 aside.left { background : rgb(14, 126, 18); height : 1000px; width : 400px; float : left; } html,body,.wrapper { height : 100%; } footer { background : rgb(11, 36, 251); height : 160px; margin-top : -160px; } .container { width : 1960px; margin-left : auto; margin-right : auto; } header { background : rgb(252, 13, 28); height : 178px; margin-bottom : -178px; z-index : 10; position : relative; } .content { box-sizing : border-box; min-height : 100%; padding-top : 178px; padding-bottom : 178px; background : rgb(128, 128, 128); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

結果

現時点では、くるみ割り人形は次のタスクに対応しています。

1. 画像から構造を抽出します。
2. テキスト、フォント、サイズ、スタイルの認識。
3. スクリーンショットから写真を抽出します。
4. マージンとマージンを認識します。
5. 最も近いユースケースを検索します。
6. cssファイルのコンパイル時の競合処理。

近い将来、以下を実装する予定です。

1. 境界認識：色、タイプ、幅、丸め。
2. テーブルの認識。
3. 勾配認識。
4. 固定ブロックの処理（表示：固定および表示：絶対）

私の意見では、多くの成長ポイントを備えたかなり有望なシステムであることがわかりました。 最も原始的な方法であっても、くるみ割り人形は簡単なタスクに対処します。 画像認識の点でも、最も近い先例を抽出する場合でも、よりインテリジェントな方法でパッケージ化すると、プログラムは大部分のデザインレイアウトで動作することができます。



もう1つの優れた機能は、レイアウトレイアウトです。 ユースケースデータベースのいくつかのバージョンを使用すると、たとえばbem-methodologyに従ってくるみ割り人形タイプセットを作成したり、特定のバージョンのブートストラップを使用したりできます。 また、企業は企業標準を追加することができ、企業の従業員として自分自身をタイプセットできるだけでなく、生成されたコードと比較することにより、このレイアウトまたはそのレイアウトが標準にどの程度準拠しているかを評価することもできます。



このようなデータベースにデータを入力することは、非常に時間のかかるプロセスのように思えるかもしれません。 もちろん、これを議論することは困難ですが、私は個人的には、約100の前例でほとんどのタスクをカバーできると考えています。 そして、そのような量を満たすことは、原則として、標準プロジェクトの時間に見合っています。 したがって、フロントエンドのスペシャリストは、データベースを一杯にするために時間をかけることで、生産性を劇的に向上させることができます。



この記事の目標の1つは、コミュニティからフィードバックを得ることです。 今、私はこのプロジェクトを深く掘り下げて、木の後ろに森が見えないかもしれないという明確な感覚を持っています。 したがって、私は建設的な批判に感謝します。