今天開始新的招生 在莫斯科。第一階段培訓將於7月25日至3月XNUMX日進行。來自其他城市的學生將能夠遠端或親自參加——公司將支付旅費和宿舍住宿費。第二階段，也是最後階段，將持續到XNUMX月XNUMX日，只能親自完成。
我的名字是 Yulia Seredich，我們和 Sergei Kazakov 一起寫了這篇文章。我們都是Yandex明斯克辦公室的介面開發人員，也是SRI往年的畢業生。
在莫斯科開始註冊之際，我們將發布對前一所學校（明斯克）的介紹任務的分析。
如果你追溯 SRI 作業的歷史，我們每年都會測試程式設計師的三個重要技能：
- 佈局。每個開發人員都應該能夠進行佈局。不可能有謝廖扎叔叔為整個團隊做設計，而你只寫劇本。因此，每個學生都必須表現出他如何懂得排版。
- JavaScript。如果只限於版面的話，我們就不是介面開發學院，而是佈局設計師學院了。設計精美的介面需要復興。因此，總是有 JS 的任務，但有時這也是演算法的任務 - 我們非常喜歡它們。
- 解決問題可能是開發人員最重要的技能。在創建介面時，事情變化得非常快。就像劉易斯·卡羅爾（Lewis Carroll）所說：“你必須盡可能快地跑才能留在同一個地方，而要到達另一個地方，你必須跑得快兩倍。”我們每天都會遇到新技術 - 我們需要考慮並理解它們。因此，在第三個任務中，我們建議了解新手開發人員通常不熟悉的技術。
在每個任務的分析中，我們不僅會告訴您正確的步驟，還會告訴您常見的錯誤。
任務 1：作品集
第一項任務是由懂得如何進行佈局的 Yandex.Collections 設計師 Alexey Cherenkevich 和他的服務同事、介面開發人員 Sergey Samsonov 完成的。
健康）狀況
建立一個作品集網站：向我們介紹一下您自己、您的工作以及您對學校的期望。該網站應盡可能符合建議的佈局（佈局連結： , , , ）。我們只對佈局感興趣，所以請不要使用 JavaScript。
檢查時我們會考慮：
- 縮排大小、顏色正確性、字體樣式、字體大小；
- 語義佈局；
- 元素不同狀態的存在：懸停遊標時顯示按鈕和連結、反白顯示活動輸入欄位等；
- 跨瀏覽器相容性（在流行瀏覽器的最新版本中測試）。
優點將是：
- 使用現代 CSS 解決方案：flexbox、grid 等；
- 自適應佈局；
- 使用預處理器和（或）後處理器、彙編、縮小、最佳化輸出程式碼；
- HTML 表單驗證、風格化檔案上傳按鈕。
該任務相當龐大，因此您可以跳過那些不起作用的內容。這會稍微降低您的分數，但您仍然能夠展示您的知識。完成後，請向我們發送兩個連結 - 您的作品集和 GitHub 上的原始程式碼。
作業中提出的佈局不僅適用於行動裝置、平板電腦和桌上型電腦的螢幕，而且還具有真實的規格。
為了讓第一個任務的檢查結果盡可能客觀，這次檢查有許多標準。
標準
設計網站。這似乎是顯而易見的，但有些人完全跳過了一些區塊——要么他們想節省時間，要么他們做不到。佈局大致可分為四個主螢幕：帶有頭像的主螢幕、帶有 SRI 期望清單的區塊、帶有投資組合的區塊和帶有聯絡資訊的區塊。它們可以分段製作，也可以簡單地使用 div，最主要的是所有四個區塊都可用。
佈局與佈局的一致性。設計師制定了單獨的規範（包括顏色、排版、按鈕狀態等），以方便應徵者。底部有關於第一個螢幕的縮排和功能的提示。我對那些考慮到設計師所有願望的人感到非常滿意：例如，第一個螢幕不小於視口的高度。
自適應佈局 - 這是當介面不僅僅是佈局以便在三種解析度下一切都是像素到像素的佈局時。在中間狀態下，佈局也不應該崩潰。有些人忘記限制容器的最大寬度並將所有內容設為 1920 像素，有些人弄亂了背景，但總的來說，候選人很好地應對了這項任務。
語意佈局。 「他們告訴世界多少次了」連結應該設計為 ，按鈕應該設計為 。幸運的是，大多數候選人也滿足了這項要求。並不是每個人都認識到 SRI 期望中的隱藏列表，使其使用 div 標籤，但也沒有那麼糟糕。有一位候選人插入了他所知道的所有語義標籤——哪裡需要，哪裡不需要。例如，代替列表 - 和 。畢竟，語義 - 它是關於理解頁面的組成和每個區塊的目的（大多數人在這裡管理它），以及預處理器和/或後處理器的使用（有些人在這裡管理它，儘管這也是重點- 最常見的是他們使用較少和scss）。
工作滑桿。作業中我們寫到不能使用JS。這裡測試了解決問題的能力 - 可以使用 和 的組合來製作滑桿。所有的魔法都發生在選擇器等級#button-N:checked ~ .slider-inner .slider-slides。當我們點擊其中一個輸入複選框時，它就會進入選取狀態。我們可以利用這一點，將我們需要的翻譯分配給帶有幻燈片的容器：transform：translate(-33%)。可以看到滑桿的實現 .
下拉清單。在這裡，這一切都歸結為 和一個類似的選擇者： .accordion-item input:checked ~ .accordion-item__content。你可以看到實現 .
:hover、:active 和 :focu* 狀態的可用性。非常重要的一點。與介面互動過程中的舒適度取決於它。用戶應該始終收到有關其行為的回饋。在與問卷互動的整個過程中都檢查了該項目。如果我單擊“打電話給我”按鈕，但視覺上沒有任何反應（即使請求已發送），這很糟糕，因為這樣我會一次又一次地單擊它。結果，將發送十個請求，我將被回電十次。我們不能忘記，行動裝置沒有滑鼠，這意味著不應該有懸停。還有一點並不影響那些滿足語意這一點的人。如果您的控制項不是互動式元素，那麼當您將滑鼠懸停在其上時，遊標將保持標準狀態。即使你寫了懸停反應，它看起來也很混亂。不要低估遊標：指針。
動畫。重要的是，與元素發生的所有反應都要順利。生活中沒有什麼是瞬時的，因此在懸停和活動狀態下進行轉換足以使介面更加令人愉悅。好吧，那些為滑桿和清單設定動畫的人通常都很棒。
使用最新技術。很多人使用flex，但沒有人使用grid完成任務。如果正確使用了flex，則得分會被計算在內。如果佈局在某個地方因為這些彎曲而分崩離析，唉，您沒有收到任何額外的分數。
表單驗證。所需要做的就是將 required 屬性新增到表單的每個輸入中。我們為那些將電子郵件欄位驗證為電子郵件的人添加了積分。
設定文件上傳按鈕的樣式。我們期望看到這樣的組合： 和 Select file。接下來我們需要隱藏輸入並設定標籤的樣式。還有另一種常見的方法 - 製作透明輸入並將其放在按鈕頂部。但並不是所有瀏覽器都允許 進行樣式化，這種解決方案不能稱為完全跨瀏覽器。而且做標籤在語意上更正確。
跨瀏覽器相容性。我們檢查了兩個最新版本的現代瀏覽器（沒有 IE - 參與者很幸運）以及 iPhone 上的 Safari 和 Android 上的 Chrome 中一切正常。
相反，如果有人使用 JS 或 Bootstrap，我們就會扣分：這兩者都會破壞整個任務的目的。此外，使用 Bootstrap 的參與者不僅得到了減分，而且在語意和實作元素上也丟了很多分。
那些將網站託管在互聯網上的人並沒有獲得任何特別的優勢 - 但審閱者非常高興他們不必下載存儲庫並在計算機上本地運行它們。所以這對業力來說是一個加號。
第一個任務主要對學生來說非常有用。那些我們沒有接受的人現在已經準備好了簡歷 - 您可以自豪地將其附加到所有回復中或將其發佈到您的 gh 頁面上。
任務2：運輸路線
任務的作者是搜尋介面小組的負責人 Denis Balyko。
健康）狀況
你有星圖嗎？它顯示每顆恆星的名稱，以及它與其他恆星的距離（以光秒為單位）。實現解決方案函數，該函數應採用三個參數：一個對象，其中鍵是星星的名稱，值是到星星的距離（太空中的單向交通），以及路徑的起點和終點- 分別是起點和終點。此函數應傳回從起始星到結束星的最短距離以及要遵循的路徑。
函數簽名：
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 中。
第二個任務的驗證是最自動化、最客觀的。大多數人猜測有必要實作 Dijkstra 演算法。那些找到它的描述並用 JS 實現該演算法的人做得很好。然而，在檢查作業時，我們發現許多論文都有同樣的錯誤。我們在網路上搜尋了程式碼片段，找到了一篇文章，參與者從中複製了演算法。有趣的是，很多人複製了文章中的程式碼以及作者的評論。此類作品得分較低。我們不禁止使用任何來源，但我們希望人們深入研究他所寫的內容。
標準
測試主要得分。有時很明顯，這些人在搞亂儲存庫、重命名資料夾，而且測試會失敗，只是因為他們找不到必要的檔案。今年，我們試圖幫助這些人，並將所有東西歸還給他們。但明年我們計劃改用競賽制，這將不再被原諒。
還有「人類」的手動標準。例如，單一代碼風格的存在。沒有人因為使用製表符而不是空格而被扣分，反之亦然。如果您根據您已知的規則將單引號與雙引號交替，並隨機放置分號，那就是另一回事了。
解決方案的清晰度和可讀性是單獨考慮的。在世界上所有的會議上，他們都說程式設計師 80% 的工作就是閱讀別人的程式碼。甚至小學生也接受來自他們的管理者和彼此之間的程式碼審查。因此，這項標準具有重要意義。有些作品中變數的長度不超過一個字元 - 請不要這樣做。除了與 Stella Chang 的評論相同的評論之外，參與者的評論都非常令人鼓舞。
最後一個標準是自動測試的存在。只有少數人添加了它們，但對每個人來說，這都成為他們業力的巨大加分。
正確的解決方案：
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：活動日曆
它是由介面開發人員 Sergey Kazakov 和 Alexander Podskrebkin 編寫的。
健康）狀況
寫一個迷你日曆來顯示您的日程安排。您可以選擇任何您喜歡的時間表。例如2019年前端會議行程。
日曆應該看起來像一個清單。沒有其他設計要求。可以提前 3、7 和 14 天設定事件提醒。首次從互聯網下載後，日曆應打開並離線運行。
有用的資源
前端會議行程：
服務人員：
通知API：
第三個任務是測驗中最有趣的，因為有很多可能的解決方案，每個都有自己的解決方案。我們檢查了候選人如何處理不熟悉的技術——他是否知道如何研究，是否測試了他的解決方案。
標準
折疊日曆。是的，它仍然需要佈置。還有一些人過於字面地理解了這個條件，沒有插入一行 CSS 程式碼。看起來不太吸引人，但如果一切順利的話，積分並不會減少。
從來源取得事件列表。這不是一個佈局任務，因此其中包含的事件清單沒有被計算在內。您隨時可以取消會議、重新安排會議或新增會議。所以需要從外部接收數據，並根據接收的JSON來渲染佈局。以任何方式取得資料（使用 fetch 方法或使用 XMLHttpRequest）都很重要。如果一個人添加了一個用於 fetch 的 polyfill 並在自述文件中標記了他的選擇，這被算作一個加號。
Service Worker 註冊沒有錯誤 並在第一次下載後離線工作。 Service Worker 在首次啟動時進行規劃快取。有關服務工作線程、其功能以及使用它們的方式（使用快取、離線工作的策略）的詳細資訊可以在此處找到。
能夠設定提醒所以它實際上在 3、7、14 天後起作用。有必要了解通知 API， 是正確的任務。我們並不期望有任何具體的實作來檢查是否是時候推送了。任何工作選項都被接受：儲存在 localStorage、IndexDB 中或由服務工作者定期輪詢。甚至可以製作一個推播伺服器（這裡 ），但它無法離線工作。在頁面關閉後以及一段時間後打開後接收推送同樣重要。如果提醒在頁面關閉的同時消失，則解決方案不計算在內。當這些人考慮到審查者並讓現在就獲得推送成為可能時，這真是太酷了 - 以免等待 3 天。
能夠在桌面上放置圖標 （PWA）。我們檢查了文件的存在 使用正確的圖示。有些人製作了這個檔案（或讓它在 CreateReactApp 中產生） - 但沒有添加正確的圖示。然後，在嘗試安裝時，出現「需要不同的圖示」之類的錯誤。
程式碼風格和專案結構。與第二個任務一樣，我們研究了單一程式碼風格（即使它與我們的程式碼風格不一致）。有些人搞砸了短絨 - 這太棒了。
控制台錯誤。如果控制台上有一個指示器表明出了問題，而參與者沒有註意到它，那麼我們就會扣分。
結果
參與者的決定有什麼有趣的地方：
- 一份問卷包含以下文字：「一位程式設計師朋友幫我建立了一個 React 應用程式。我連珠炮般地問他如何以及為什麼，他告訴了我。我真的很喜歡它，我想了解更多。”我們全心全意地支持這個申請，但不幸的是，候選人的朋友對申請的成功並沒有多大幫助。
- 一位候選人發送了一個 RAR 存檔所在的 GitHub 連結 - 對此很難發表評論。 🙂
- 另一位候選人在solution.js文件第一行的評論中誠實地承認他複製了該演算法。
我們收到了 76 位候選人的申請，最後選定了 23 人。我們不僅收到了來自明斯克的問卷調查，還收到了來自莫斯科、聖彼得堡甚至韃靼斯坦的問卷調查。其中一些人目前的職業讓我們感到驚訝：其中一個是法醫專家，另一個是醫學生。
結果是完成任務的成功率的有趣分佈。參與者平均完成了第一個任務的 60%，第二個任務完成了 50%，第三個任務是最困難的，平均完成了 40%。
乍一看，這些任務看起來既複雜又耗時。原因並不是我們想淘汰盡可能多的候選人。在學習期間，學生面臨現實生活中的任務 - 聊天、為兒童設計 Yandex.Music 或為依賴天氣的人設計 Yandex.Weather。為此，您需要一個起始基地。
我記得兩年前看到我的 SRI 入學任務並認為我永遠無法解決它。此時最主要的是坐下來，仔細閱讀條件並開始做。事實證明，這些條件幾乎包含了 80% 的解。例如，在第三個任務（最困難的）的情況下，我們在 MDN 上新增了 Service Worker 和Notifications API 的連結。研究了連結內容的學生毫無困難地完成了它。
我非常希望將來計劃進入 SRI、無法進入明斯克學校或開始執行任何其他測試任務的考生閱讀這篇文章。正如您所看到的，這樣做是完全有可能的。您只需要相信自己並聽取作者的所有提示。
來源： www.habr.com