Yandex.PracticumWebシミュレーター。使い方

教育プロセスを面白く、可能な限りインタラクティブにすることが重要です。特にテクノロジーに関しては、コードを書いて検査官から回答を得る機会がある場合に、はるかに便利です。彼らは、よくできていると言っていますが、すべてがうまくいくかどうか、わき柱はどこにあり、どのようにあなたは一般的にそれをしました。



同様のことを試みるために、Yandex MVPでWebシミュレーターを起動しました。このシミュレーターでは、ユーザーがコード、スクリプト、その他すべてをさまざまなタブに記述でき、隣にこれらすべてを最終結果として表示しました。

MVPはそれ自体をうまく示し、Yandex.Practiceで生徒の知識をテストするための本格的なツールのレベルにWebシミュレーターをもたらしました。私の名前はArtemです。Web開発を教えるためのシミュレーターをどのように作成したか、どのように機能し、何ができるかを説明します。



外から見ると、ここではすべてが単純なようです。すべてのカスタムコードをiframeに詰め込み、postmessageで投稿してから、可能な限りレンダリングすると、すべてが機能します。そのようなわずかにポンプされたオンラインコードプレビュー。



しかし、ニュアンスがあります。

使い方

最初に、考えられる問題に気づきました。たとえば、ワークショップ自体などのYandexドメインにシミュレーターをデプロイすると、ユーザーがもう少し好奇心をそそられる可能性がゼロではありません。つまり、彼らはいくつかのコードを取り込んでシミュレーターに投入し、シミュレーターはそれを熱心に処理します。また、コードは不正であることが判明し、既存のYandex Cookieを削除してサードパーティのサービスに挿入します。その後、詐欺師はYandexのユーザーの個人アカウントとすべての個人データにアクセスできるようになります。このiframeがyandex.ruドメインにある場合、これを実装するのは非常に簡単です。そのため、yandex.netにシミュレータ専用の別のドメインを作成し、Feynmanという名前を付けました。リチャードに敬意を表して、はい。



一般に、シミュレータは、バックエンドに送信するファイルをプレーンテキスト、json、および画像のbase64形式で保存します。次に、それらは実際のファイルに変換され、静的な形式ですでに配布されています。これをiframeに入れてレンダリングすることができます。



ただし、ここでは構文の強調表示を行うだけでなく、知識をテストするためのシミュレーターもあります。したがって、このコードをオンザフライでテストおよびチェックする必要があります。つまり、何らかの方法でiframeプロセスにウェッジし、ユーザーが変数に名前を付けた方法など、すべてが正しく行われたかどうか、またはすべてがdivで正常かどうかを確認する必要があります。







そしてここで再びドメインに遭遇します。私がすでに書いたように、ユーザーコードはFeynmanドメインのシミュレーターに入れられ、praktikum.yandex.ruドメインのYandexからチェックします。ブラウザの同じオリジンポリシーは警戒されており、異なるドメインがある場合はiframeの内部を改ざんすることはできません。



そのため、iframeをiframeに詰め込むことにしました。







次の状況が判明しました。

• 最初は実際には空のiframeを作成します。
• 彼はある種の空白のページを描きます。
• 私たちはフロントから、ファインマンが私たちに与えたものへのリンクを含むポストメッセージを投稿します（彼が統計をホストしている場所から）。
• 最初のiframeはこのリンクを取得し、内部iframeのsrcに置き換えます。

その結果、最初のiframeがコードを所有し、内部iframeで必要なことを実行できます。事実上、テストは、ドキュメント、ウィンドウなど、iframe内のすべてにアクセスできる単なる評価関数です。これにより、問題のテストを行い、特定のiframeのウィンドウで実行する機会が得られます。

テストだけではありません

次に、いくつかの便利な機能を追加したいと思いました。端末、コンソール、ログに書き込んだ内容に関するユーザーデータを表示する機能、その他の楽しみです。もちろん、スマートフォンやタブレットで結果がどのように表示されるかをユーザーが確認できるように、本格的なアダプティブモードを作成しました。

このために、必要なすべてのスタイルをロードし、応答モードをエミュレートする特別なライブラリが作成されました。また、元のiframeを少し変更し、ユーザーがconsole.logを画面に表示できるようにするすべてのものを追加します。いくつかの単純なオブジェクトだけでなく、本格的なドキュメントdomツリーも追加します。



これに加えて、予備テストの実行方法を学びました。これは、同じことをチェックする多くのテストがあるため便利です。たとえば、ユーザーがコード内のループでそれをやり過ぎたかどうか、ネストに夢中になったかどうかなどです。これを各テストで個別に説明することはあまり意味がないため、コードをチェックする一連の特別な事前テストメソッドを備えたテストライブラリを作成しました。この段階ですべてが正常であれば、メインテストと解決された問題はすでにチェックされており、その後、結果がユーザーに表示されます。



予備テストの結果をユーザーに返すために、postmessageも使用します。エラーがあるかどうかに関係なく、メッセージを送信します。ちなみに、Webシミュレーターの学生のコードも、ロシア語に翻訳されたes-lint linterを介してチェックされ、常に構文エラーが強調表示されます。

コードレビューの問題（だけでなく）

たとえば、ページにシステムまたはブラウザの通知がある場合、何かを入力するように提案されましたが、テストを実行すると、ユーザーは通知とデータ入力の要求を含むブラウザウィンドウを引き続き表示しました。このようにする必要がありました。ユーザーがコードを含むページを起動してすべてがどのように機能するかを確認する場合、このアラートも機能する必要があります。また、テストで検証のためにこのコードを実行すると、ユーザーの画面に引き続きアラートを表示する必要がなくなります。実際、これらすべてのアラートをテスト用の独自のスタブ（モック）に置き換え、アラート、プロンプト、ウィンドウ内の確認をオーバーライドしました。これを行わないと、無限のループまたは何もしない空のアラートが発生する可能性があります。



ちなみに、無限ループについて。ここでの主な問題は、ユーザーが故意に無限ループに入るコードを意図的に取得して書き込むことができ（ブラウザーにはjavascriptスレッドが1つしかない）、その結果、ブラウザー全体が横になることでした。



これに対抗するために、レビューのためにコードを送信する前に、最初にそのような無限ループを追跡することを学びました。これを行うには、何らかの方法でユーザースクリプトを作り直す必要がありました。次のようにしました。

• サイクルごとに、呼び出しの数をカウントする特定の関数を追加します。
• この呼び出し数が100,000を超えると、すぐに例外がスローされ、ポストメッセージで返送されます。さらに、念のため、サイクルが10秒を超えて実行された場合のタイムアウトを確認します。
• その過程で、例外が発生したため、ここで問題が発生し、テスト自体を実行する意味がなくなったことを追跡します。コードがループします。

リンクのある状況は別途注意する必要があります。コード内のユーザーが、ポートフォリオやgithubアカウントなど、新しいタブをクリックすると開くリンクがあるとします。また、iframe内で直接開くためにそのようなリンクは必要ありませんでした。そうしないと、iframeの代わりに、そのリンクを含むページが作成されます。Tabを介して、新しいタブでそのようなものを開く必要があります。通常、フレーム内ではなく親フレームでリンクを開くには、target = "_parent"を指定するだけです。しかし、私たちの場合、リンクが外部であるかどうかを決定するハンドラーを追加する必要がありました。



そして、すべてのリンクについて、特別なハンドラーを作成しました。リンクが外部であることがわかった場合は、ポストメッセージを送信し、リンクハンドラー自体を中断して（デフォルトを回避）、ポストメッセージが前面に戻ります。ここに外部リンクがあることがわかり、通知が表示されます-外部サイトにアクセスしてもよろしいですか？その後、新しいタブを開きます。



また、アンカーもあり、すべてがはるかに簡単でした。それらはiframe内では機能しませんでした。一般的に。したがって、小さなハックとして、任意のリンクのクリックイベントをサブスクライブしました。アンカーがある場合は、scrollIntoViewを特定の要素に設定しました。



すべてのメタデータ（たとえば、ユーザーがHTMLページにファビコンを登録している場合、または特定のタイトルを持っている場合）、iframeがロードされた後にポストメッセージを介して送信します。querySelectorを使用して、これら2つのタグを取得し、ポストメッセージを介してフロントに送り返します。フロント自体が、必要に応じてこれらすべてのアイコンを挿入します。些細なことのようですが、ユーザーはブラウザ内に本格的なブラウザを持っているような印象を受けます。

シミュレーターをバイパスしようとします

私たちのWebシミュレーターは、PythonやSQLなどで行ったシミュレーターとは異なり、バックエンドではなくフロントをチェックに使用します。したがって、ユーザーがテストを正しく完了すると、対応するPOST要求がバックエンドに送信されます。原則として、適切なスキルを持つユーザーは、同じことを実行して、そのような要求を手動で送信できます。



両刃の剣があります。一方では、人がこれを行うためのテクノロジーと基本的なハックに十分に興味を持っているのはクールです。一方、私たちのシミュレーターは正式に「OK、あなたは一般的に素晴らしいです、あなたはすべてをしました」を受け取るためではないので、それは足のショットに少し似ていますが、正常に動作する方法を学ぶために、間違いに気づいて修正してください。一般的には、ジムに行ってベンチプレスに5分間座ってから、Facebookに「100キロで3セットやりました」と書くようなものです。自尊心を楽しむことはできますが、成果はそこで止まります。



実際、このチェックをバックエンドに行わないのはそのためです。同様の問題が解決されます。人々は、仮想の成果ではなく、実際の仕事（おそらくワークショップ自体で）を得るために勉強するようになります。



独自のウィッシュリストとユーザーからのフィードバックの両方を使用して、Webシミュレーターを常に改善しているので、その開発について引き続き説明します。現在、特定のテクノロジーを求める学生のニーズを考慮して、最終決定中です。たとえば、ReactとNodeJSでの作業を追加しました。 Webシミュレーターが最も人気があり、Pythonシミュレーターがそれに続きます。これは主に、エントリのしきい値が低いことと、テクノロジー自体の人気の両方が原因です。技術的な部分に加えて、インタラクティブ理論を操作するためのシミュレーター内の多くのメカニズムもあります（そして私たちのすべてのコースでそれらの十分な数があります）。テスターが学習するクイズとスタンドの特別なセットを作成した、QA専門分野専用の個別のシミュレーターはありません。ちなみに、テスターのカップル、現在私たちがワークショップを行うのを手伝っているのは私たちの卒業生ですQAコース。



C ++用のシミュレーターと機械学習用のシミュレーターはもっと複雑です。興味があれば、次の投稿でそれらについて話そうとします。



読んでいただきありがとうございます。シミュレーターやワークショップ全般について質問がある場合は、書いてください。回答します。