Scuola di sviluppo dell'interfaccia: analisi dei compiti per Minsk e una nuova serie a Mosca

Oggi si sono aperte nuove iscrizioni Scuola di sviluppo dell'interfaccia Yandex A mosca. La prima fase della formazione si svolgerà dal 7 settembre al 25 ottobre. Gli studenti di altre città potranno parteciparvi a distanza o di persona: l'azienda pagherà il viaggio e l'alloggio in un ostello. La seconda, anch'essa fase finale, durerà fino al 3 dicembre e potrà essere completata solo di persona.

Mi chiamo Yulia Seredich, abbiamo scritto questo post insieme a Sergei Kazakov. Siamo entrambi sviluppatori di interfacce presso l'ufficio Yandex di Minsk e laureati in SRI negli anni precedenti.

Scuola di sviluppo dell'interfaccia: analisi dei compiti per Minsk e una nuova serie a Mosca

In occasione dell'apertura delle iscrizioni a Mosca, pubblichiamo qui a Minsk un'analisi dei compiti introduttivi alla scuola precedente.

Se ripercorri la storia degli incarichi SRI, di anno in anno abbiamo testato tre competenze importanti per un programmatore:

  • Disposizione. Ogni sviluppatore dovrebbe essere in grado di eseguire il layout. Non succede che tu abbia lo zio Seryozha che progetta per l'intero team e tu scrivi solo sceneggiature. Pertanto, ogni studente deve dimostrare come sa impaginare.
  • JavaScript. Se la questione si limitasse al layout, non avremmo una Scuola di Sviluppo di Interfacce, ma una Scuola di Layout Designer. L'interfaccia dal design accattivante deve essere rilanciata. Pertanto, c'è sempre un compito per JS, ma a volte c'è anche un compito per gli algoritmi: li amiamo così tanto.
  • Il problem solving è forse l’abilità più importante di uno sviluppatore. Quando si tratta di creare interfacce, le cose cambiano molto rapidamente. È come Lewis Carroll: "Devi correre più veloce che puoi solo per restare nello stesso posto, e per arrivare in un altro posto devi correre due volte più veloce". Ogni giorno ci imbattiamo in nuove tecnologie: dobbiamo tenerne conto ed essere in grado di capirle. Pertanto, nel terzo compito, abbiamo proposto di comprendere le tecnologie con cui uno sviluppatore alle prime armi di solito non ha familiarità.

Nell'analisi di ogni attività ti parleremo non solo della procedura corretta, ma anche degli errori comuni.

Compito 1: Portafoglio

Al primo compito hanno lavorato il designer di Yandex.Collections Alexey Cherenkevich, che sa come realizzare il layout, e il suo collega di servizio, lo sviluppatore di interfacce Sergey Samsonov.

condizione

Crea un sito portfolio: raccontaci di te, del tuo lavoro e delle tue aspettative nei confronti della Scuola. Il sito dovrà corrispondere il più possibile al layout proposto (link ai layout: 1000px, 600px, 320px, specificazione). Siamo interessati solo al layout, quindi per favore non utilizzare JavaScript.

Durante il controllo prenderemo in considerazione:

  • dimensioni del rientro, correttezza del colore, stile del carattere, dimensione del carattere;
  • disposizione semantica;
  • la presenza di diversi stati degli elementi: visualizzazione di pulsanti e collegamenti quando si passa il cursore, evidenziazione di campi di input attivi, ecc.;
  • compatibilità tra browser (testato nelle ultime versioni dei browser più diffusi).

Il vantaggio sarà:

  • utilizzo di moderne soluzioni CSS: flexbox, grid, ecc.;
  • Disposizione adattiva;
  • utilizzo di pre e (o) post-processori, assemblaggio, minimizzazione, ottimizzazione del codice di output;
  • Convalida del modulo HTML, pulsante di caricamento file stilizzato.

Il compito è piuttosto voluminoso, quindi puoi saltare ciò che non funzionerà. Ciò abbasserà leggermente il tuo punteggio, ma sarai comunque in grado di dimostrare le tue conoscenze. Quando hai finito, inviaci due link: al tuo portfolio e al codice sorgente su GitHub.

I layout proposti nell'incarico non erano solo con schermi per dispositivi mobili, tablet e desktop, ma anche con specifiche reali.

Per conferire la massima obiettività possibile al risultato del controllo del primo compito, c'erano molti criteri per questo controllo.

criteri

Sito web progettato. Sembra ovvio, ma alcuni ragazzi hanno saltato del tutto alcuni blocchi: o volevano risparmiare tempo, oppure non potevano farlo. Il layout può essere approssimativamente suddiviso in quattro schermate principali: la schermata principale con un avatar, un blocco con un elenco di aspettative da SRI, un blocco con un portafoglio e un blocco con le informazioni di contatto. Potrebbero essere realizzati in sezioni o semplicemente utilizzando div, l'importante è che tutti e quattro i blocchi siano disponibili.

Conformità del layout con il layout. Il designer ha creato specifiche separate (inclusi colori, tipografia, stati dei pulsanti, ecc.) per facilitare il compito ai candidati. In basso c'era un accenno ai rientri e alle caratteristiche della prima schermata. Sono rimasto molto soddisfatto dei ragazzi che hanno tenuto conto di tutti i desideri del designer: ad esempio, il primo schermo avrebbe dovuto essere almeno pari all'altezza del viewport.

Disposizione adattiva - questo è quando l'interfaccia non è semplicemente strutturata in modo che a tre risoluzioni tutto sia pixel per pixel nel layout. Anche negli stati intermedi il layout non dovrebbe crollare. Alcuni hanno dimenticato di limitare la larghezza massima del contenitore e di impostare tutto a 1920 pixel, altri hanno incasinato gli sfondi, ma nel complesso i candidati hanno affrontato bene questo compito.

Disposizione semantica. “Quante volte hanno detto al mondo” che il collegamento dovrebbe essere progettato come , il pulsante come . Fortunatamente, la maggior parte dei candidati soddisfaceva anche questo requisito. Non tutti hanno riconosciuto la lista nascosta nelle aspettative dell’SRI, realizzandola utilizzando i tag div, ma non è poi così male. C'era un candidato che ha inserito tutti i tag semantici che conosceva: dove era necessario e dove non era necessario. Ad esempio, invece di un elenco - e . Dopotutto, la semantica riguarda la comprensione della composizione della tua pagina e lo scopo di ciascun blocco (la maggior parte lo ha gestito qui), nonché l'uso di pre e/o post-processori (alcuni lo hanno gestito qui, anche se questo era anche nei punti - molto spesso usavano less e scss).

Dispositivo di scorrimento funzionante. Nel compito abbiamo scritto che JS non può essere utilizzato. Qui è stata testata la capacità di risolvere i problemi: è possibile realizzare un cursore utilizzando un mazzo e . Tutta la magia avviene a livello del selettore #button-N:checked ~ .slider-inner .slider-slides. Quando facciamo clic su una delle caselle di input, passa allo stato selezionato. Possiamo approfittarne e assegnare la traduzione di cui abbiamo bisogno al contenitore con le diapositive: trasforma: traduce(-33%). Puoi vedere l'implementazione dello slider qui.

Elenchi a discesa. Anche qui tutto si riduceva a e un selettore simile: .accordion-item input:checked ~ .accordion-item__content. Puoi vedere l'implementazione qui.

Disponibilità degli stati :hover, :active e :focus*. Un punto molto importante. Il comfort durante l'interazione con l'interfaccia dipendeva da questo. L'utente dovrebbe sempre ricevere feedback sulle proprie azioni. Questo elemento è stato controllato durante tutta l'interazione con il questionario. Se ho fatto clic sul pulsante "Chiamami" e visivamente non è successo nulla (anche se la richiesta è stata inviata), non è corretto, perché in tal caso lo cliccherò ancora e ancora. Di conseguenza verranno inviate dieci richieste e verrò richiamato dieci volte. Non dobbiamo dimenticare che i dispositivi mobili non hanno un mouse, il che significa che non dovrebbe esserci il passaggio del mouse. E un altro punto che non ha influenzato coloro che hanno soddisfatto il punto sulla semantica. Se il tuo controllo non è un elemento interattivo, quando ci passi sopra, il cursore rimarrà standard. Sembra molto disordinato, anche se hai scritto una reazione al passaggio del mouse. Non sottovalutare il cursore: puntatore.

Animazioni. È importante che tutte le reazioni che si verificano con gli elementi siano fluide. Niente nella vita è istantaneo, quindi avere transizioni al passaggio del mouse e attive era sufficiente per rendere l'interfaccia più piacevole. Bene, quelli che hanno animato lo slider e gli elenchi sono generalmente fantastici.

Utilizzando la tecnologia più recente. Molte persone hanno utilizzato Flex, ma nessuno ha completato l'attività utilizzando la griglia. Il punto veniva conteggiato se il flex veniva utilizzato correttamente. Se da qualche parte il layout si rompesse a causa di queste stesse flessioni, ahimè, non riceverai punti aggiuntivi.

Convalida del modulo. Tutto ciò che era necessario era aggiungere l'attributo richiesto a ciascun input del modulo. Abbiamo aggiunto punti a coloro che hanno convalidato il campo email come email.

Designazione del pulsante di caricamento del file. Ci aspettavamo di vedere una combinazione come: e Seleziona file . Successivamente dovevamo nascondere l'input e definire lo stile dell'etichetta. Esiste un altro modo comune: creare un input trasparente e posizionarlo sopra il pulsante. Ma non tutti i browser consentono lo styling e tale soluzione non può essere definita completamente cross-browser. Ed è semanticamente più corretto creare un'etichetta.

Compatibilità tra browser. Abbiamo verificato che tutto andasse bene nelle due ultime versioni dei browser moderni (senza IE - i partecipanti sono stati fortunati), così come in Safari su iPhone e Chrome su Android.

Al contrario, sottraevamo punti se qualcuno utilizzava JS o Bootstrap: entrambi vanificherebbero lo scopo dell'intero compito. Inoltre, i partecipanti con Bootstrap non solo hanno ricevuto un segno negativo, ma hanno anche perso molti punti per la semantica e gli elementi implementati.

Coloro che hanno ospitato il proprio sito da qualche parte su Internet non hanno ricevuto alcun vantaggio particolare, ma i revisori sono stati molto contenti quando non hanno dovuto scaricare repository ed eseguirli localmente sul proprio computer. Quindi questo è servito come un vantaggio per il karma.

Il primo compito è stato molto utile soprattutto per lo studente. Coloro che non abbiamo accettato ora hanno un curriculum preparato: puoi allegarlo con orgoglio a tutte le risposte o pubblicarlo sulle tue pagine gh.

Compito 2: percorso di trasporto

L'autore del compito è il capo del gruppo delle interfacce di ricerca Denis Balyko.

condizione

Hai una mappa stellare? Mostra il nome di ciascuna stella, nonché la distanza da essa alle altre stelle in secondi luce. Implementare la funzione di soluzione, che dovrebbe accettare tre argomenti: un oggetto in cui le chiavi sono i nomi delle stelle e i valori sono le distanze dalle stelle (traffico unidirezionale nello spazio), nonché i nomi delle stelle i punti iniziale e finale del percorso - rispettivamente inizio e fine. La funzione dovrebbe restituire la distanza più breve dalla stella di partenza alla stella di arrivo e il percorso da seguire.

Firma della funzione:

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

Dati di input di esempio:

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'; 

Esempio di output:

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

Nota: lo scheletro della soluzione si trova nella cartella src/, inserisci la soluzione in solution.js.

La verifica del secondo compito è stata quella più automatizzata e obiettiva. La maggior parte dei ragazzi ha intuito che fosse necessario implementare l'algoritmo di Dijkstra. Coloro che hanno trovato la sua descrizione e implementato l'algoritmo in JS hanno fatto bene. Tuttavia, durante il controllo del compito, ci siamo imbattuti in molti documenti con gli stessi errori. Abbiamo cercato frammenti di codice su Internet e abbiamo trovato un articolo da cui i partecipanti hanno copiato l'algoritmo. È divertente che molte persone abbiano copiato il codice dall'articolo insieme ai commenti dell'autore. Tali lavori hanno ricevuto un punteggio basso. Non vietiamo l'uso di alcuna fonte, ma vogliamo che una persona approfondisca ciò che scrive.

criteri

I punti principali sono stati assegnati per i test. A volte era chiaro che i ragazzi stavano scherzando con il repository, rinominando le cartelle e i test sarebbero falliti semplicemente perché non riuscivano a trovare i file necessari. Quest'anno abbiamo cercato di aiutare questi ragazzi e abbiamo riportato tutto al suo posto. Ma l’anno prossimo prevediamo di passare al sistema dei concorsi, e questo non ci sarà più perdonato.

C’erano anche criteri “umani”, manuali. Ad esempio, la presenza di un unico stile di codice. Nessuno ha detratto punti per aver utilizzato le tabulazioni al posto degli spazi o viceversa. Un'altra questione è se alterni virgolette singole con virgolette doppie secondo una regola a te nota e inserisci i punti e virgola in modo casuale.

La chiarezza e la leggibilità della soluzione sono state prese in considerazione separatamente. In tutti i congressi del mondo si dice che l’80% del lavoro di un programmatore consiste nel leggere il codice degli altri. Anche gli scolari vengono sottoposti a revisioni del codice, da parte dei loro curatori e tra loro. Quindi questo criterio aveva un peso significativo. Ci sono stati lavori in cui non c'erano variabili più lunghe di un carattere: per favore non farlo. I commenti dei partecipanti sono stati molto incoraggianti, ad eccezione di quelli identici a quelli di Stella Chang.

L'ultimo criterio è la presenza di autotest. Solo poche persone li hanno aggiunti, ma per tutti è diventato un enorme vantaggio nel loro karma.

La soluzione corretta:

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);
    };
};

Attività 3: Calendario degli eventi

È stato preparato dagli sviluppatori dell'interfaccia Sergey Kazakov e Alexander Podskrebkin.

condizione

Scrivi un mini-calendario per visualizzare il tuo programma. Puoi prendere qualsiasi programma tu voglia. Ad esempio, il programma delle conferenze frontend nel 2019.

Il calendario dovrebbe apparire come un elenco. Non ci sono altri requisiti di progettazione. Permetti di impostare promemoria di eventi con 3, 7 e 14 giorni di anticipo. Dopo il primo download da Internet, il calendario dovrebbe aprirsi e funzionare offline.

Risorse utili

Programma della conferenza frontend:
confs.tech/javascript?topics=javascript%2Bcss%2Bux

Addetti ai servizi:
Developer.mozilla.org/ru/docs/Web/API/Service_Worker_API/Using_Service_Workers
sviluppatori.google.com/web/fundamentals/primers/service-workers

API di notifiche:
Developer.mozilla.org/ru/docs/Web/API/Notifications_API

Il terzo compito è stato il più interessante da testare, perché c’erano tantissime soluzioni possibili, ognuna con la propria. Abbiamo verificato come il candidato gestisce le tecnologie sconosciute, se sa fare ricerca, se testa le sue soluzioni.

criteri

Calendario piegato. Sì, doveva ancora essere strutturato. C'è stato anche chi ha preso la condizione troppo alla lettera e non ha inserito una sola riga di codice CSS. Non sembrava molto attraente, ma se tutto funzionava i punti non diminuivano.

Ottenere un elenco di eventi da una fonte. Questa non è un'attività di layout, quindi l'elenco degli eventi in essa inclusi non è stato conteggiato. Puoi sempre annullare una conferenza, riprogrammarla o aggiungerne una nuova. Quindi è stato necessario ricevere i dati dall'esterno e renderizzare il layout in base al JSON ricevuto. Era importante ottenere i dati in qualsiasi modo (utilizzando il metodo fetch o utilizzando XMLHttpRequest). Se una persona aggiungeva un polyfill per il recupero e contrassegnava la sua scelta nel file readme, questo veniva conteggiato come un vantaggio.

Registrazione del lavoratore del servizio senza errori e lavorare offline dopo il primo download. Ecco un esempio. addetto al servizio con memorizzazione nella cache pianificata al primo avvio. I dettagli sugli addetti ai servizi, sulle loro capacità e sui modi di lavorare con loro (strategie per lavorare con le cache, lavorare offline) possono essere trovati qui.

Possibilità di impostare un promemoriain modo che funzioni effettivamente dopo 3, 7, 14 giorni. Era necessario comprendere l'API delle notifiche, collegamento a cui era proprio nel compito. Non ci aspettavamo alcuna implementazione specifica per verificare se è il momento di spingere. È stata accettata qualsiasi opzione di lavoro: archiviazione in localStorage, IndexDB o polling periodico da parte di un addetto al servizio. Era anche possibile creare un server push (qui esempio), ma non funzionerebbe offline. Era altrettanto importante ricevere una spinta dopo che la pagina veniva chiusa e aperta dopo un po' di tempo. Se il promemoria moriva nello stesso momento in cui la pagina veniva chiusa, la soluzione non veniva conteggiata. È bello quando i ragazzi hanno pensato ai revisori e hanno permesso di ottenere una spinta in questo momento, in modo da non aspettare 3 giorni.

Possibilità di posizionare un'icona sul desktop (PWA). Abbiamo verificato la presenza del file manifest.json con le icone corrette. Alcuni ragazzi hanno creato questo file (o lo hanno lasciato generato in CreateReactApp) - ma non hanno aggiunto le icone corrette. Quindi, durante il tentativo di installazione, si è verificato un errore del tipo "è necessaria un'icona diversa".

Stile del codice e struttura del progetto. Come nel secondo compito, abbiamo esaminato un singolo stile di codice (anche se non coincideva con il nostro). Alcuni ragazzi hanno fregato i linter: è fantastico.

Errori della console. Se proprio nella console c'era un indicatore che qualcosa non andava e il partecipante non vi prestava attenzione, allora detraevamo punti.

Risultati di

Cosa c'è di divertente nelle decisioni dei partecipanti:

  • Un questionario conteneva il seguente testo: “Un amico programmatore mi ha aiutato a mettere insieme un'applicazione React. L'ho bombardato di domande su come e perché, e lui me lo ha detto. Mi è piaciuto molto, voglio saperne di più.” Facevamo il tifo per questa candidatura con tutto il cuore, ma sfortunatamente l'amico del candidato non è stato di grande aiuto nel far funzionare la candidatura.
  • Un candidato ha inviato un collegamento a GitHub, dove si trovava l'archivio RAR: è difficile commentarlo. 🙂
  • Un altro candidato, nel commento alla prima riga del file solution.js, ha onestamente ammesso di aver copiato l'algoritmo.

Abbiamo ricevuto candidature da 76 candidati e selezionato 23 persone. Ci sono stati inviati questionari non solo da Minsk, ma anche da Mosca, San Pietroburgo e persino dal Tatarstan. Alcuni ragazzi ci hanno sorpreso con la loro attuale professione: uno di loro è un esperto forense e l'altro è uno studente di medicina.

Il risultato è stato un’interessante distribuzione delle percentuali di successo nel completamento delle attività. I partecipanti hanno completato il primo compito in media del 60%, il secondo del 50% e il terzo si è rivelato il più difficile ed è stato completato in media del 40%.

A prima vista, i compiti sembrano complessi e richiedono molto tempo. Il motivo non è che vogliamo eliminare il maggior numero possibile di candidati. Durante gli studi, gli studenti devono affrontare compiti della vita reale: chattare, Yandex.Music per bambini o Yandex.Weather per persone dipendenti dal clima. Per questo è necessaria una base di partenza.

Ricordo di aver visto il mio compito di ingresso SRI due anni fa e di aver pensato che non l'avrei mai risolto. La cosa principale in questo momento è sedersi, leggere attentamente le condizioni e iniziare a farlo. Si scopre che le condizioni contengono quasi l'80% della soluzione. Ad esempio, nella condizione della terza attività (la più difficile), abbiamo aggiunto collegamenti agli addetti ai servizi e all'API Notifiche su MDN. Gli studenti che hanno studiato il contenuto dei collegamenti lo hanno completato senza difficoltà.

Mi piacerebbe davvero che questo articolo venisse letto dai candidati che intendono entrare nell'SRI in futuro, che non sono riusciti ad entrare alla Scuola di Minsk o che stanno iniziando a svolgere qualsiasi altro compito di prova. Come puoi vedere, è del tutto possibile farlo. Devi solo credere in te stesso e ascoltare tutti i suggerimenti degli autori.

Fonte: habr.com

Aggiungi un commento