インターフェース開発学校: ミンスクのタスク分析とモスクワの新しいセット

本日、新規入会受付を開始しました Yandex インターフェイス開発スクール モスクワで。 訓練の第7段階は25月3日からXNUMX月XNUMX日まで行われる。 他の都市からの学生もリモートまたは直接参加でき、交通費とホステルでの宿泊費は会社が負担します。 XNUMX 番目のステージも最終ステージで、XNUMX 月 XNUMX 日まで続きます。このステージは対面でのみ完了できます。

私の名前はユリア・セレディッチです。この記事はセルゲイ・カザコフと一緒に書きました。 私たちは二人とも、Yandex のミンスク オフィスのインターフェース開発者であり、SRI を前年に卒業しました。

モスクワでの登録開始を機に、私たちはここミンスクにある以前の学校への導入課題の分析を公開します。

SRI の割り当ての歴史をたどると、プログラマーにとって XNUMX つの重要なスキルが毎年テストされてきました。

• レイアウト。 すべての開発者はレイアウトを実行できる必要があります。 チーム全体のデザインを担当するセリョーザおじさんがいるわけではなく、あなたは脚本を書くだけです。 したがって、すべての生徒は植字の方法をどのように知っているかを示さなければなりません。
• JavaScript。 問題がレイアウトに限定されている場合は、インターフェイス開発学部ではなく、レイアウトデザイナー学部が存在することになります。 美しくデザインされたインターフェイスを復活させる必要があります。 したがって、JS のタスクは常に存在しますが、アルゴリズムのタスクである場合もあります。私たちはアルゴリズムをとても愛しています。
• 問題解決はおそらく開発者にとって最も重要なスキルです。 インターフェイスの作成に関しては、状況は非常に急速に変化しています。 それはルイス・キャロルのようなものです。「同じ場所に留まるためにはできるだけ早く走らなければなりませんが、別の場所に行くにはXNUMX倍の速度で走らなければなりません。」 私たちは毎日新しいテクノロジーに遭遇します。私たちはそれらを考慮し、理解する必要があります。 したがって、XNUMX 番目のタスクでは、初心者の開発者が通常馴染みのないテクノロジを理解することを提案しました。

各タスクの分析では、正しい手順だけでなく、よくある間違いについても説明します。

タスク 1: ポートフォリオ

最初のタスクは、レイアウトのやり方に詳しい Yandex.Collections デザイナーの Alexey Cherenkevich と、彼のサービス同僚であるインターフェイス開発者の Sergey Samsonov によって取り組みました。

状態

ポートフォリオ Web サイトを作成します。あなた自身、あなたの仕事、そして学校への期待について教えてください。 サイトは、提案されたレイアウトに可能な限り対応する必要があります (レイアウトへのリンク: 1000px, 600px, 320px, 仕様）。 レイアウトのみが目的なので、JavaScript は使用しないでください。

チェックする際には、次の点が考慮されます。

• インデントのサイズ、色の正確さ、フォント スタイル、フォント サイズ。
• セマンティックレイアウト。
• 要素のさまざまな状態の存在: カーソルを置いたときのボタンとリンクの表示、アクティブな入力フィールドの強調表示など。
• ブラウザ間の互換性 (一般的なブラウザの最新バージョンでテスト済み)。

利点は次のとおりです。

• 最新の CSS ソリューションの使用: フレックスボックス、グリッドなど。
• アダプティブレイアウト。
• プリプロセッサおよび（または）ポストプロセッサの使用、出力コードのアセンブリ、縮小化、最適化。
• HTML フォーム検証、様式化されたファイルのアップロード ボタン。

このタスクは非常に量が多いため、うまくいかないものはスキップしても問題ありません。 これによりスコアはわずかに下がりますが、それでも知識を証明することができます。 完了したら、ポートフォリオと GitHub 上のソース コードへの XNUMX つのリンクを送信してください。

課題で提案されたレイアウトは、モバイルデバイス、タブレット、デスクトップの画面だけでなく、実際の仕様も含まれていました。

最初のタスクのチェック結果にできるだけ客観性をもたらすために、このチェックには多くの基準がありました。

基準

デザインされたウェブサイト。 これは明らかなことのようですが、一部のブロックを完全にスキップした人もいました。時間を節約したかったか、実行できなかったかのどちらかです。 レイアウトは大きく XNUMX つのメイン画面に分けることができます。アバターが表示されるメイン画面、SRI からの期待リストが表示されるブロック、ポートフォリオが表示されるブロック、連絡先情報が表示されるブロックです。 これらはセクションで作成することも、単純に div を使用して作成することもできます。重要なのは、XNUMX つのブロックすべてが利用可能であることです。

レイアウトとレイアウトの準拠。 デザイナーは、候補者が理解しやすいように、別の仕様 (色、タイポグラフィ、ボタンの状態などを含む) を作成しました。 一番下には、最初の画面のインデントと機能に関するヒントがありました。 デザイナーの要望をすべて考慮に入れてくれた人たちにとても満足しました。たとえば、最初の画面はビューポートの高さ以上でなければなりませんでした。

アダプティブレイアウト - これは、インターフェイスが単にレイアウトされておらず、1920 つの解像度ですべてがピクセル単位でレイアウトされている場合です。 中間状態でも、レイアウトが崩れてはいけません。 コンテナの最大幅を制限するのを忘れてすべてを XNUMX ピクセルに設定する人もいれば、背景をめちゃくちゃにしてしまう人もいましたが、全体として候補者はこのタスクにうまく対処しました。

セマンティックレイアウト。 リンクは、ボタンは としてデザインされるべきだと、「彼らは何度世界に伝えたことでしょう」 。 幸いなことに、ほとんどの候補者はこの要件も満たしていました。 SRI が期待していた div タグを使用した非表示リストを誰もが認識したわけではありませんが、それほど悪いことではありません。 必要な場所と不必要な場所に、彼が知っているすべての意味タグを挿入した候補者がいました。 たとえば、リストの代わりに -と を使用します。 結局のところ、セマンティクス - ページの構成と各ブロックの目的 (大多数はここで管理しました) と、プリプロセッサおよび/またはポストプロセッサの使用 (ここで管理している人は少数でしたが、これはポイントにも含まれていました - ほとんどの場合、使用量は少なく、scss）。

作業スライダー。 課題ではJSは使えないと書きました。 ここでは問題を解決する能力がテストされました - 束を使ってスライダーを作ることができましたそして。 すべての魔法はセレクター レベル #button-N:checked ~ .slider-inner .slider-slides で発生します。 入力チェックボックスの 33 つをクリックすると、チェックされた状態になります。 これを利用して、必要な翻訳をスライドのあるコンテナに割り当てることができます:transform:translate(-XNUMX%)。 スライダーの実装が確認できます ここで.

ドロップダウンリスト。 ここでもすべてが終わりましたおよび同様のセレクター: .accordion-item input:checked ~ .accordion-item__content。 実装が見られます ここで.

:hover、:active、および :focu* 状態の利用可能性。 非常に重要な点です。 インターフェイスとの対話中の快適さはそれに依存していました。 ユーザーは自分の行動に関するフィードバックを常に受け​​取る必要があります。 この項目は、アンケートとのやり取りを通じてチェックされました。 [電話してください] ボタンをクリックしても (リクエストが送信されたにもかかわらず) 見た目には何も起こらなかった場合は、何度もクリックすることになるため、これはよくありません。 その結果、XNUMX 件のリクエストが送信され、XNUMX 回コールバックされることになります。 モバイル デバイスにはマウスがないことを忘れてはなりません。つまり、ホバーがあってはなりません。 そしてもう XNUMX つの点は、意味論に関する点を満たした人には影響しませんでした。 コントロールがインタラクティブ要素ではない場合、その上にマウスを移動すると、カーソルは標準のままになります。 ホバーへのリアクションを書いたとしても、非常に乱雑に見えます。 カーソル、つまりポインターを過小評価しないでください。

アニメーション。 要素で起こるすべての反応がスムーズであることが重要です。 人生において瞬間的なものは何一つありません。そのため、ホバー時やアクティブ時のトランジションがあるだけで、インターフェースをより快適なものにするのに十分でした。 まあ、スライダーとリストをアニメーション化した人は概して素晴らしいです。

最新のテクノロジーを使用して。 多くの人が flex を使用していましたが、grid を使用してタスクを完了した人はいませんでした。 フレックスが正しく使用されていればポイントがカウントされます。 これらの非常に柔軟なためにレイアウトがどこかで崩れた場合、残念ながら、追加のポイントは得られません。

フォームの検証。 必要なのは、フォームの各入力に必須の属性を追加することだけです。 メール欄をメールとして認証していただいた方にポイントを加算させていただきました。

ファイルアップロードボタンのスタイル設定。 次のような組み合わせが期待されていました。 ファイルを選択します。 次に、入力を非表示にし、ラベルのスタイルを設定する必要がありました。 もう XNUMX つの一般的な方法は、透明な入力を作成してボタンの上に置くことです。 ただし、すべてのブラウザでスタイル設定ができるわけではありません、そのようなソリューションは完全なクロスブラウザーとは言えません。 そして、ラベルを作成する方が意味的にはより正確です。

ブラウザ間の互換性。 最新の XNUMX つのブラウザー (IE なし - 参加者は幸運でした) の XNUMX つの最新バージョン、および iPhone の Safari と Android の Chrome ですべてが正常であることを確認しました。

逆に、誰かが JS または Bootstrap を使用した場合は減点しました。どちらもタスク全体の目的に反することになります。 さらに、Bootstrap を使用した参加者はマイナスを獲得しただけでなく、セマンティクスと実装された要素で多くのポイントを失いました。

インターネット上のどこかに自分のサイトをホストしている人には特にメリットはありませんでしたが、レポジトリをダウンロードして自分のコンピュータ上でローカルに実行する必要がなくなったので、レビュー担当者は非常に満足しました。 したがって、これはカルマにプラスとして機能しました。

最初のタスクは、主に学生にとって非常に役立ちました。 私たちが受け入れなかった人には、履歴書が用意されています。誇らしげにすべての回答に添付したり、GH ページに投稿したりできます。

タスク 2: 輸送ルート

このタスクの作成者は、検索インターフェース グループの責任者である Denis Balyko です。

状態

星図はありますか？ 各星の名前と、その星から他の星までの距離が光秒で表示されます。 解決関数を実装します。これは XNUMX つの引数を取る必要があります。キーが星の名前、値が星までの距離 (宇宙の一方通行)、および星の名前であるオブジェクトです。パスの開始点と終了点 - それぞれ開始点と終了点。 この関数は、開始星から終了星までの最短距離とたどる経路を返す必要があります。

関数シグネチャ:

const solution = function(graph, start, finish)  {
    // Ваше решение
} 

入力データの例:

const graph = {
  start: { A: 50, B: 20 },
  A: { C: 40, D: 20 },
  B: { A: 90, D: 90 },
  C: { D: 160, finish: 50 },
  D: { finish: 20 },
  finish: {}
};
const start = 'start';
const finish = 'finish'; 

出力例:

{
    distance: 90,
    path: ['start', 'A', 'D', 'finish']
} 

注: ソリューションのスケルトンは src/ フォルダーにあり、ソリューションを solution.js に置きます。

XNUMX 番目のタスクの検証は、最も自動化され客観的でした。 ほとんどの人は、ダイクストラのアルゴリズムを実装する必要があると推測していました。 その説明を見つけてアルゴリズムを JS で実装した人は、よくやったと思います。 しかし、課題を確認したところ、同じ間違いのある論文が多数見つかりました。 私たちはインターネットでコードの断片を検索し、参加者がアルゴリズムをコピーした記事を見つけました。 面白いことに、多くの人がこの記事のコードを著者のコメントとともにコピーしました。 このような作品は低いスコアを獲得しました。 私たちは出典の使用を禁止しませんが、個人が自分の書いたものを掘り下げてほしいと考えています。

基準

テストでは主なポイントが付与されました。 場合によっては、彼らがリポジトリをいじったり、フォルダーの名前を変更したりしていることが明らかになり、必要なファイルが見つからないという理由だけでテストが失敗することがありました。 今年、私たちはそのような人たちを助けようと努め、彼らのためにすべてを元の場所に戻しました。 しかし来年からはコンテスト方式に移行する予定で、これはもう許されない。

「人間的な」手動の基準もありました。 たとえば、単一のコード スタイルの存在です。 スペースの代わりにタブを使用したり、その逆を使用したりしても減点される人はいませんでした。 既知のルールに従って一重引用符と二重引用符を交互に配置し、セミコロンをランダムに配置する場合は、別の問題になります。

ソリューションの明瞭さと読みやすさは個別に考慮されました。 世界中のあらゆるカンファレンスで、プログラマーの仕事の 80% は他人のコードを読むことで構成されていると言われています。 学童ですら、学芸員や学芸員同士でコードレビューを受けます。 したがって、この基準は非常に重要な意味を持ちました。 XNUMX 文字を超える変数がない作品がありましたが、それはやめてください。 参加者からのコメントは、ステラ チャンのコメントと同じものを除いて、非常に勇気づけられるものでした。

最後の基準は自動テストの存在です。 それらを追加したのはほんの数人だけでしたが、全員にとってそれはカルマに大きなプラスとなりました。

正しい解決策:

const solution = function(graph, START, FINISH)  {
    // Всё не бесплатно в этом мире
    const costs = Object.assign({[FINISH]: Infinity}, graph[START]);

    // Первая волна родительских нод
    const parents = { [FINISH]: null };
    Object.keys(graph[START]).reduce((acc, child) => (acc[child] = START) && acc, parents)

    const visited = [];
    let node;

    // Ищем «дешёвого» родителя, отмечаем пройденные
    do {
        node = lowestCostNode(costs, visited);
        let children = graph[node];
        for (let n in children) {
            let newCost = costs[node] + children[n];

            // Ещё не оценена или нашёлся более дешёвый переход
            if (!costs[n] || costs[n] > newCost) {
                costs[n] = newCost;
                parents[n] = node;
            }
        }
        visited.push(node);
    } while (node)

    return {
        distance: costs[FINISH],
        path: optimalPath(parents)
    };

    // Возврат назад по самым «дешёвым» родителям
    function optimalPath(parents) {
        let optimalPath = [FINISH];
        let parent = parents[FINISH];
        while (parent && parent !== START) {
            optimalPath.push(parent);
            parent = parents[parent];
        }
        optimalPath.push(START);
        return optimalPath.reverse();
    }

    // Минимальная стоимость из текущей ноды среди непросмотренных
    function lowestCostNode(costs, visited) {
        return Object.keys(costs).reduce((lowest, node) => {
            if (lowest === null || costs[node] < costs[lowest]) {
                if (!visited.includes(node)) {
                    lowest = node;
                }
            }

            return lowest;
        }, null);
    };
};

タスク 3: イベント カレンダー

これは、インターフェイス開発者のセルゲイ・カザコフ氏とアレクサンダー・ポドスクレブキン氏によって作成されました。

状態

ミニカレンダーを書いてスケジュールを表示します。 好きなスケジュールで受講可能です。 たとえば、2019 年のフロントエンド カンファレンスのスケジュール。

カレンダーはリストのように見えるはずです。 その他の設計要件はありません。 イベントリマインダーを 3 日前、7 日前、14 日前に設定できるようにします。 インターネットから最初にダウンロードした後、カレンダーが開き、オフラインで機能するはずです。

役に立つリソース

フロントエンドカンファレンスのスケジュール:
confs.tech/javascript?topics=javascript%2Bcss%2Bux

サービスワーカー:
developer.mozilla.org/ru/docs/Web/API/Service_Worker_API/Using_Service_Workers
developers.google.com/web/fundamentals/primers/service-workers

通知API:
開発者.mozilla.org/ru/docs/Web/API/Notifications_API

XNUMX 番目のタスクは、考えられる解決策が非常に多く、それぞれに独自のものがあるため、テストするのが最も興味深いものでした。 私たちは、候補者がなじみのないテクノロジーをどのように扱うか、研究方法を知っているか、ソリューションをテストしているかどうかを確認しました。

基準

二つ折りカレンダー。 はい、まだレイアウトする必要がありました。 条件を文字通りに受け取りすぎて、CSS コードを XNUMX 行も挿入しなかった人もいました。 見た目はあまり魅力的ではありませんでしたが、すべてがうまくいけばポイントは減りませんでした。

ソースからイベントのリストを取得する。 これはレイアウト タスクではないため、それに含まれるイベントのリストはカウントされませんでした。 いつでも会議をキャンセルしたり、スケジュールを変更したり、新しい会議を追加したりできます。 そのため、外部からデータを受け取り、受け取ったJSONに基づいてレイアウトをレンダリングする必要がありました。 何らかの方法 (fetch メソッドまたは XMLHttpRequest を使用) でデータを取得することが重要でした。 ユーザーがフェッチ用のポリフィルを追加し、その選択を Readme にマークした場合、これはプラスとしてカウントされました。

Service Worker のエラーなしの登録 最初のダウンロード後はオフラインで作業できます。 これが一例です。 最初の起動時にスケジュールをキャッシュする Service Worker。 Service Worker、サービス ワーカーの機能、およびサービス ワーカーとの連携方法 (キャッシュの操作、オフラインでの作業の戦略) の詳細については、ここを参照してください。

リマインダーを設定する機能実際に機能するのは 3 日、7 日、14 日後です。 通知 API を理解する必要がありましたが、 どのリンクへのリンク 任務は正しかった。 プッシュする時期であるかどうかを確認するための特定の実装は期待していませんでした。 localStorage 内のストレージ、IndexDB、または Service Worker による定期的なポーリングなど、機能するオプションはすべて受け入れられました。 プッシュサーバーを作成することも可能でした（ここ 例)、ただしオフラインでは機能しません。 ページを閉じた後、しばらくしてから開いた後にプッシュを受け取ることも同様に重要でした。 ページを閉じると同時にリマインダーが終了した場合、ソリューションはカウントされません。 スタッフがレビュアーのことを考えて、3 日も待たずに今すぐプッシュできるようにしてくれたのは素晴らしいことです。

デスクトップにアイコンを配置する機能 (PWA)。 ファイルの存在を確認しました manifest.jsonを 正しいアイコンを使用してください。 このファイルを作成した (または CreateReactApp で生成されたままにした) 人もいますが、正しいアイコンを追加しませんでした。 そしてインストールしようとすると「別のアイコンが必要です」のようなエラーが発生しました。

コードスタイルとプロジェクト構造。 XNUMX 番目のタスクと同様に、(たとえそれが私たちのコードスタイルと一致しないとしても) XNUMX つのコードスタイルを調べました。 リンターをねじ込んだ人もいましたが、それは素晴らしいことです。

コンソールエラー。 何かが間違っていることを示すインジケーターがコンソールに表示され、参加者がそれに注意を払わなかった場合は、減点しました。

結果

参加者の決定の面白いところ:

• あるアンケートには次のような文章が含まれていました。「プログラマーの友人が React アプリケーションの作成を手伝ってくれました。 私は彼にその理由と方法について質問を浴びせました、そして彼は私に言いました。 すごく気に入ったのでもっと知りたいです。」 私たちはこの申請を心から応援していましたが、残念ながら、候補者の友人が申請の実現にあまり協力してくれませんでした。
• ある候補者は、RAR アーカイブが保存されている GitHub にリンクを送信しましたが、これについてコメントするのは困難です。 🙂
• 別の候補者は、solution.js ファイルの最初の行のコメントで、アルゴリズムをコピーしたことを正直に認めました。

76名の応募があり、23名を決定しました。 ミンスクだけでなく、モスクワ、サンクトペテルブルク、さらにはタタールスタンからもアンケートが送られてきた。 彼らの中には、現在の職業について私たちを驚かせた人もいます。XNUMX 人は法医学の専門家で、もう XNUMX 人は医学生です。

その結果、タスクの完了における成功率の興味深い分布が得られました。 参加者は最初のタスクを平均 60% で完了し、50 番目のタスクを 40% で完了しました。XNUMX 番目のタスクは最も難しく、平均 XNUMX% で完了しました。

一見すると、タスクは複雑で時間がかかるように見えます。 その理由は、できるだけ多くの候補者を排除したいということではありません。 学習中、学生はチャットの作成、子供向けの Yandex.Music 、または天候に左右される人々向けの Yandex.Weather など、現実のタスクに直面します。 このためには開始ベースが必要です。

80年前にSRIの入学課題を見て、絶対に解けないと思ったのを覚えています。 現時点での主なことは、座って条件を注意深く読んで、それを開始することです。 この条件では、溶液のほぼ XNUMX% が含まれていることがわかります。 たとえば、XNUMX 番目のタスク (最も難しい) の条件では、MDN 上のサービス ワーカーと通知 API へのリンクを追加しました。 リンクの内容を学習した学生は、難なく完了しました。

この記事は、将来SRIに入学しようと考えている受験生、ミンスクスクールに入学できなかった受験生、これから他の試験課題に取り組む受験生にぜひ読んでいただきたいです。 ご覧のとおり、そうすることは十分に可能です。 自分を信じて、著者からのヒントをすべて聞く必要があります。

出所： habr.com