בית ספר לפיתוח ממשקים: ניתוח משימות עבור מינסק ומערכת חדשה במוסקבה

היום נפתחה הרשמה חדשה בית הספר לפיתוח ממשק Yandex במוסקבה. השלב הראשון של ההכשרה יתקיים מה-7 בספטמבר עד ה-25 באוקטובר. סטודנטים מערים אחרות יוכלו להשתתף בו מרחוק או באופן אישי - החברה תשלם עבור נסיעות ולינה באכסניה. השני, גם השלב הסופי, יימשך עד ה-3 בדצמבר, ניתן להשלים אותו רק באופן אישי.

שמי יוליה סרדיץ', כתבנו את הפוסט הזה ביחד עם סרגיי קזקוב. שנינו מפתחי ממשקים במשרד מינסק של Yandex ובוגרי SRI משנים קודמות.

לרגל פתיחת ההרשמה במוסקבה, אנו מפרסמים ניתוח משימות היכרות לבית הספר הקודם - כאן במינסק.

אם אתה עוקב אחר ההיסטוריה של מטלות SRI, משנה לשנה בדקנו שלוש מיומנויות חשובות למתכנת:

• מַעֲרָך. כל מפתח צריך להיות מסוגל לעשות פריסה. לא קורה שיש לך את הדוד סריוז'ה שמעצב לכל הצוות, ואתה כותב רק תסריטים. לכן, כל תלמיד חייב להראות כיצד הוא יודע להגדיר כתיבה.
• JavaScript. אם העניין היה מוגבל לפריסה, אז לא היה לנו בית ספר לפיתוח ממשקים, אלא בית ספר למעצבי פריסה. צריך להחיות את הממשק המעוצב להפליא. לכן, תמיד יש משימה עבור JS, אבל לפעמים זו גם משימה עבור אלגוריתמים – אנחנו כל כך אוהבים אותם.
• פתרון בעיות הוא אולי המיומנות החשובה ביותר של מפתח. כשזה מגיע ליצירת ממשקים, דברים משתנים מהר מאוד. זה כמו לואיס קרול: "אתה צריך לרוץ הכי מהר שאתה יכול רק כדי להישאר באותו מקום, וכדי להגיע למקום אחר אתה צריך לרוץ מהר פי שניים." בכל יום אנו נתקלים בטכנולוגיות חדשות – עלינו לקחת אותן בחשבון ולהיות מסוגלים להבין אותן. לכן, במשימה השלישית, הצענו להבין טכנולוגיות שמפתח מתחיל בדרך כלל לא מכיר.

בניתוח של כל משימה, נספר לך לא רק על ההליך הנכון, אלא גם על טעויות נפוצות.

משימה 1: תיק עבודות

על המשימה הראשונה עבדו מעצב Yandex.Collections, אלכסיי צ'רנקביץ', שיודע לעשות פריסה, ועמיתו לשירות, מפתח הממשקים סרגיי סמסונוב.

מצב

צור אתר תיק עבודות: ספר לנו על עצמך, על עבודתך ועל הציפיות שלך מבית הספר. האתר צריך להתאים ככל האפשר לפריסה המוצעת (קישורים לפריסות: 1000px, 600px, 320px, מפרט). אנחנו מעוניינים רק בפריסה, אז נא לא להשתמש ב-JavaScript.

בעת הבדיקה ניקח בחשבון:

• גדלי הזחה, נכונות הצבע, סגנון הגופן, גודל הגופן;
• פריסה סמנטית;
• נוכחותם של מצבים שונים של אלמנטים: הצגת לחצנים וקישורים בעת ריחוף עם הסמן, הדגשת שדות קלט פעילים וכו';
• תאימות בין דפדפנים (נבדקה בגרסאות האחרונות של דפדפנים פופולריים).

היתרון יהיה:

• שימוש בפתרונות CSS מודרניים: flexbox, רשת וכו';
• פריסה אדפטיבית;
• שימוש במעבדי קדם ו(או) פוסט-מעבדים, הרכבה, מזעור, אופטימיזציה של קוד הפלט;
• אימות טופס HTML, כפתור העלאת קובץ מסוגנן.

המשימה די נרחבת, אז אתה יכול לדלג על מה שלא יעבוד. זה יוריד מעט את הציון שלך, אבל עדיין תוכל להפגין את הידע שלך. כשתסיים, שלח לנו שני קישורים - לתיק העבודות שלך ולקוד המקור ב-GitHub.

הפריסות שהוצעו במשימה לא היו רק עם מסכים למכשירים ניידים, טאבלטים ומחשבים שולחניים, אלא גם עם מפרט אמיתי.

על מנת להכניס כמה שיותר אובייקטיביות לתוצאה של בדיקת המשימה הראשונה, היו הרבה קריטריונים לבדיקה זו.

קריטריונים

אתר מעוצב. זה נראה מובן מאליו, אבל כמה בחורים דילגו על כמה בלוקים לחלוטין - או שהם רצו לחסוך זמן, או שהם לא יכלו לעשות אותם. את הפריסה ניתן לחלק באופן גס לארבעה מסכים עיקריים: המסך הראשי עם אווטאר, בלוק עם רשימת ציפיות מ-SRI, בלוק עם תיק עבודות ובלוק עם פרטי התקשרות. הם יכולים להיעשות בקטעים או פשוט באמצעות divs, העיקר שכל ארבעת הבלוקים היו זמינים.

התאמה של פריסה עם פריסה. המעצב עשה מפרט נפרד (כולל צבעים, טיפוגרפיה, מצבי כפתורים וכו') כדי להקל על המועמדים. בחלק התחתון היה רמז על הכניסות והתכונות של המסך הראשון. הייתי מאוד מרוצה מהחבר'ה שלקחו בחשבון את כל רצונותיו של המעצב: למשל, המסך הראשון היה צריך להיות לא פחות מגובה התצוגה.

פריסה אדפטיבית - זה כשהממשק לא סתם פרוש כך שבשלוש רזולוציות הכל פיקסל לפיקסל בפריסה. במצבי ביניים, גם הפריסה לא אמורה להתפרק. חלק שכחו להגביל את הרוחב המרבי של המיכל ולהגדיר הכל ל-1920 פיקסלים, חלק פישלו את הרקע, אבל בסך הכל המועמדים התמודדו עם המשימה הזו היטב.

פריסה סמנטית. "כמה פעמים אמרו לעולם" שהקישור צריך להיות מעוצב כ- , הכפתור - כ- . למרבה המזל, רוב המועמדים מילאו גם דרישה זו. לא כולם זיהו את הרשימה הנסתרת בציפיות של ה-SRI, מה שהופך אותה באמצעות תגי div, אבל זה לא כל כך נורא. היה מועמד שהכניס את כל התגיות הסמנטיות שהכיר – איפה זה נחוץ ואיפה לא היה צורך. לדוגמה, במקום רשימה - ו . אחרי הכל, סמנטיקה - מדובר בהבנת ההרכב של הדף שלך ומטרת כל בלוק (הרוב ניהלו את זה כאן), כמו גם השימוש במעבדי קדם ו/או פוסט-מעבדים (כמה מהם הצליחו כאן, למרות שזה היה גם בנקודות - לרוב השתמשו בפחות וב-scss) .

מחוון עובד. במשימה כתבנו שלא ניתן להשתמש ב-JS. כאן נבדקה היכולת לפתור בעיות - ניתן ליצור סליידר באמצעות חבורה ו . כל הקסם מתרחש ברמת הבורר #button-N:checked ~ .slider-inner .slider-slides. כאשר אנו לוחצים על אחת מתיבות הסימון של הקלט, היא עוברת למצב מסומן. אנחנו יכולים לנצל את זה ולהקצות את התרגום שאנחנו צריכים למיכל עם השקופיות: transform: translate(-33%). אתה יכול לראות את היישום של המחוון כאן.

רשימות נפתחות. כאן הכל הסתכם גם ובורר דומה: .accordion-item input:checked ~ .accordion-item__content. אתה יכול לראות את היישום כאן.

זמינות של מצבי :רחף, :active ו-:focu*. נקודה חשובה מאוד. הנוחות במהלך האינטראקציה עם הממשק הייתה תלויה בו. המשתמש צריך תמיד לקבל משוב על פעולותיו. פריט זה נבדק לאורך כל האינטראקציה עם השאלון. אם לחצתי על כפתור "התקשר אלי" ומבחינה ויזואלית לא קרה כלום (למרות שהבקשה נשלחה), זה רע, כי אז אני אלחץ עליה שוב ושוב. כתוצאה מכך יישלחו עשר בקשות ואחזור אלי עשר פעמים. אסור לשכוח שלמכשירים ניידים אין עכבר, מה שאומר שלא צריך להיות ריחוף. ועוד נקודה שלא השפיעה על מי שהגשים את הנקודה לגבי הסמנטיקה. אם השליטה שלך אינה אלמנט אינטראקטיבי, אז כאשר תרחף מעליו, הסמן יישאר סטנדרטי. זה נראה מאוד לא מסודר, גם אם כתבת תגובה לרחף. אל תזלזל בסמן: מצביע.

אנימציות. חשוב שכל התגובות המתרחשות עם היסודות יהיו חלקות. שום דבר בחיים אינו מיידי, כך שמעברים על ריחוף ופעילים הספיקו כדי להפוך את הממשק לנעים יותר. ובכן, אלה שהנפישו את המחוון והרשימות הם בדרך כלל נהדרים.

שימוש בטכנולוגיה העדכנית ביותר. אנשים רבים השתמשו ב-flex, אבל אף אחד לא השלים את המשימה באמצעות גריד. הנקודה נספרה אם נעשה שימוש נכון ב-flex. אם איפשהו הפריסה התפרקה בגלל הגמישות האלה, אבוי, לא קיבלת נקודות נוספות.

אימות טופס. כל שנדרש היה להוסיף את התכונה הנדרשת לכל קלט של הטופס. הוספנו נקודות למי שאימת את שדה האימייל כמייל.

עיצוב כפתור העלאת הקובץ. ציפינו לראות שילוב כמו: ובחר קובץ . בשלב הבא היינו צריכים להסתיר את הקלט ולעצב את התווית. ישנה דרך נפוצה נוספת - לבצע קלט שקוף ולשים אותו על גבי הכפתור. אבל לא כל הדפדפנים מאפשרים עיצוב , ולא ניתן לקרוא לפתרון כזה חוצה דפדפן. ומבחינה סמנטית זה נכון יותר לעשות תווית.

תאימות בין דפדפנים. בדקנו שהכל בסדר בשתי הגרסאות האחרונות של הדפדפנים המודרניים (ללא IE - למשתתפים היה מזל), וכן בספארי באייפון וכרום באנדרואידים.

להיפך, גרכנו נקודות אם מישהו השתמש ב-JS או ב-Bootstrap: שניהם יביסו את מטרת המשימה כולה. יתר על כן, משתתפים עם Bootstrap לא רק קיבלו מינוס, אלא גם איבדו נקודות רבות עבור סמנטיקה ואלמנטים מיושמים.

מי שאירח את האתר שלהם איפשהו באינטרנט לא קיבל יתרון מיוחד - אבל הסוקרים שמחו מאוד כשלא נאלצו להוריד מאגרים ולהפעיל אותם באופן מקומי במחשב. אז זה שימש יתרון לקארמה.

המשימה הראשונה הייתה מאוד שימושית בעיקר עבור התלמיד. למי שלא קיבלנו יש עכשיו קורות חיים מוכנים - אתם יכולים לצרף אותם בגאווה לכל התגובות או לפרסם אותם ב-gh-pages שלכם.

משימה 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.

האימות של המשימה השנייה היה האוטומטי והאובייקטיבי ביותר. רוב החבר'ה ניחשו שיש צורך ליישם את האלגוריתם של דיקסטרה. מי שמצא את התיאור שלו והטמיע את האלגוריתם ב-JS כל הכבוד. עם זאת, בעת בדיקת המטלה, נתקלנו במסמכים רבים עם אותן שגיאות. חיפשנו באינטרנט קטעי קוד ומצאנו מאמר שממנו העתיקו המשתתפים את האלגוריתם. זה מצחיק שאנשים רבים העתיקו את הקוד מהמאמר יחד עם הערות המחבר. עבודות כאלה קיבלו ציון נמוך. אנחנו לא אוסרים על שימוש במקורות כלשהם, אבל אנחנו רוצים שאדם יתעמק במה שהוא כותב.

קריטריונים

נקודות עיקריות הוענקו למבחנים. לפעמים היה ברור שהחבר'ה מתעסקים עם המאגר, משנים את שמות התיקיות והבדיקות ייכשלו פשוט כי הם לא מצאו את הקבצים הדרושים. השנה ניסינו לעזור לבחורים כאלה והחזרנו עבורם הכל למקומו. אבל בשנה הבאה אנחנו מתכננים לעבור למערכת תחרויות, וזה כבר לא ייסלח.

היו גם קריטריונים "אנושיים", ידניים. לדוגמה, נוכחות של סגנון קוד יחיד. אף אחד לא הוריד נקודות על שימוש בטאבים במקום ברווחים או להיפך. זה עניין אחר אם אתה מחליף מרכאות בודדות עם מרכאות כפולות לפי כלל אחד המוכר לך, ומציב נקודות פסיק באקראי.

הבהירות והקריאות של הפתרון נלקחו בחשבון בנפרד. בכל הכנסים בעולם אומרים ש-80% מהעבודה של מתכנת מורכבת מקריאת קוד של אנשים אחרים. אפילו תלמידי בית ספר עוברים ביקורות קוד - מהאוצרים שלהם וזה מזה. אז לקריטריון זה היה משקל משמעותי. היו עבודות שבהן לא היו משתנים ארוכי טווח מתו אחד - נא לא לעשות זאת. ההערות של המשתתפים היו מאוד מעודדות - למעט אלו שהיו זהות להערותיה של סטלה צ'אנג.

הקריטריון האחרון הוא נוכחות של בדיקות אוטומטיות. רק כמה אנשים הוסיפו אותם, אבל עבור כולם זה הפך ליתרון עצום בקארמה שלהם.

ההחלטה הנכונה:

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 של התראות:
developer.mozilla.org/ru/docs/Web/API/Notifications_API

המשימה השלישית הייתה המעניינת ביותר לבדיקה, כי היו כל כך הרבה פתרונות אפשריים, לכל אחד משלו. בדקנו איך המועמד מתמודד עם טכנולוגיות לא מוכרות – האם הוא יודע לחקור, האם הוא בודק את הפתרונות שלו.

קריטריונים

לוח שנה מקופל. כן, זה עדיין היה צריך להיות פרוס. היו גם כאלה שלקחו את התנאי בצורה מילולית מדי ולא הכניסו ולו שורה אחת של קוד CSS. זה לא נראה מאוד אטרקטיבי, אבל אם הכל עבד, הנקודות לא ירדו.

קבלת רשימת אירועים ממקור. זו אינה משימת פריסה, ולכן רשימת האירועים הכלולה בה לא נספרה. אתה תמיד יכול לבטל ועידה, לתזמן אותה מחדש או להוסיף ועידה חדשה. אז היה צורך לקבל נתונים מבחוץ ולעבד את הפריסה על סמך ה-JSON שהתקבל. היה חשוב להשיג את הנתונים בכל דרך (באמצעות שיטת האחזור או באמצעות XMLHttpRequest). אם אדם הוסיף פוליפיל להבאה וסימן את בחירתו ב-readme, זה נחשב כתוספת.

רישום עובד שירות ללא שגיאות ועבוד במצב לא מקוון לאחר ההורדה הראשונה. הנה דוגמה. service worker עם מטמון לוח זמנים באתחול הראשון. פרטים על עובדי שירות, יכולותיהם ודרכי העבודה עימם (אסטרטגיות לעבודה עם מטמונים, עבודה לא מקוונת) ניתן למצוא כאן.

אפשרות להגדיר תזכורתכך שזה באמת עובד אחרי 3, 7, 14 ימים. היה צורך להבין את ה-API של התראות, קישור לאיזה עמד בדיוק במשימה. לא ציפינו ליישום ספציפי שיבדוק אם הגיע הזמן לדחוף. כל אפשרות עבודה התקבלה: אחסון ב-localStorage, IndexDB או סקר תקופתי על ידי עובד שירות. אפילו היה אפשר ליצור שרת פוש (כאן דוגמה), אבל זה לא יעבוד במצב לא מקוון. לא פחות חשוב היה לקבל דחיפה לאחר סגירת הדף - ונפתח לאחר זמן מה. אם התזכורת מתה באותו זמן שהדף נסגר, הפתרון לא נספר. זה מגניב כשהחבר'ה חשבו על הסוקרים ואפשרו לקבל דחיפה כבר עכשיו - כדי לא לחכות 3 ימים.

יכולת הצבת אייקון על שולחן העבודה (PWA). בדקנו את נוכחות הקובץ גלובלי עם הסמלים הנכונים. כמה חבר'ה יצרו את הקובץ הזה (או השאירו אותו שנוצר ב-CreateReactApp) - אבל לא הוסיפו את הסמלים הנכונים. לאחר מכן, בעת ניסיון ההתקנה, התרחשה שגיאה כמו "דרוש סמל אחר".

סגנון קוד ומבנה פרויקט. כמו במשימה השנייה, הסתכלנו על סגנון קוד בודד (גם אם הוא לא עולה בקנה אחד עם שלנו). כמה חבר'ה דפוק על רצועות - זה נהדר.

שגיאות קונסולה. אם היה אינדיקטור ממש בקונסולה שמשהו לא בסדר, והמשתתף לא שם לב לזה, אז קזזנו נקודות.

תוצאות של

מה שמצחיק בהחלטות המשתתפים:

• שאלון אחד הכיל את הטקסט הבא: "חבר מתכנת עזר לי להרכיב אפליקציית React. הפצצתי אותו בשאלות על איך ולמה, והוא אמר לי. מאוד אהבתי את זה, אני רוצה לדעת יותר על זה". חיפשנו את הבקשה הזו בכל ליבנו, אך למרבה הצער, חברו של המועמד לא עזר במיוחד בהפעלת הבקשה.
• מועמד אחד שלח קישור ל-GitHub, שם נמצא ארכיון ה-RAR - קשה להגיב על זה. 🙂
• מועמד אחר, בהערה בשורה הראשונה של קובץ solution.js, הודה ביושר שהעתיק את האלגוריתם.

קיבלנו פניות מ-76 מועמדים ובחרנו 23 אנשים. שלחו לנו שאלונים לא רק ממינסק, אלא גם ממוסקבה, סנט פטרסבורג ואפילו טטרסטן. חלק מהחבר'ה הפתיעו אותנו עם המקצועות הנוכחיים שלהם: אחד מהם הוא מומחה לזיהוי פלילי, והשני הוא סטודנט לרפואה.

התוצאה הייתה חלוקה מעניינת של אחוזי הצלחה בביצוע משימות. המשתתפים השלימו את המשימה הראשונה בממוצע של 60%, השנייה ב-50%, והשלישית התבררה כקשה ביותר והושלמו בממוצע של 40%.

במבט ראשון, המשימות נראות מורכבות וגוזלות זמן. הסיבה היא לא שאנחנו רוצים לנכות כמה שיותר מועמדים. במהלך הלימודים, התלמידים מתמודדים עם משימות מהחיים האמיתיים - יצירת צ'אט, Yandex.Music לילדים או Yandex.Weather לאנשים תלויי מזג אוויר. בשביל זה אתה צריך בסיס התחלתי.

אני זוכר שראיתי את משימת הכניסה שלי ל-SRI לפני שנתיים וחשבתי שלעולם לא אפתור אותה. העיקר ברגע זה הוא לשבת, לקרוא בעיון את התנאים ולהתחיל לעשות זאת. מסתבר שהתנאים מכילים כמעט 80% מהתמיסה. לדוגמה, במצב המשימה השלישית (הקשה ביותר), הוספנו קישורים ל-Service Workers ול-Notifications API ב-MDN. סטודנטים שלמדו את תוכן הקישורים השלימו אותו ללא קושי.

אני מאוד רוצה שהמאמר הזה ייקרא על ידי מועמדים שמתכננים להיכנס ל-SRI בעתיד, שלא הצליחו להיכנס לבית הספר מינסק, או שמתחילים לבצע כל משימת מבחן אחרת. כפי שאתה יכול לראות, זה בהחלט אפשרי לעשות זאת. אתה רק צריך להאמין בעצמך ולהקשיב לכל הטיפים של המחברים.

מקור: www.habr.com