I dag åpnet en ny påmelding i Moskva. Første trinn i opplæringen vil finne sted fra 7. september til 25. oktober. Studenter fra andre byer vil kunne delta i det eksternt eller personlig - selskapet vil betale for reise og opphold på et herberge. Den andre, også den siste fasen, varer til 3. desember, den kan kun gjennomføres personlig.
Mitt navn er Yulia Seredich, vi skrev dette innlegget sammen med Sergei Kazakov. Vi er begge grensesnittutviklere på Minsk-kontoret til Yandex og nyutdannede fra SRI fra tidligere år.
I anledning åpningen av registrering i Moskva, publiserer vi en analyse av introduksjonsoppgaver til den forrige Skolen - her i Minsk.
Hvis du sporer historien til SRI-oppdrag, har vi fra år til år testet tre viktige ferdigheter for en programmerer:
- Oppsett. Hver utvikler bør kunne lage layout. Det skjer ikke at du har onkel Seryozha som designer for hele teamet, og du skriver bare manus. Derfor må hver elev vise hvordan han kan sette.
- JavaScript. Hvis saken var begrenset til layout, ville vi ikke hatt en skole for grensesnittutvikling, men en skole for layoutdesignere. Det vakkert utformede grensesnittet må gjenopplives. Derfor er det alltid en oppgave for JS, men noen ganger er det også en oppgave for algoritmer – vi elsker dem så høyt.
- Problemløsning er kanskje den viktigste ferdigheten til en utvikler. Når det gjelder å lage grensesnitt, endrer ting seg veldig raskt. Det er som Lewis Carroll: "Du må løpe så fort du kan bare for å holde deg på samme sted, og for å komme til et annet sted må du løpe dobbelt så fort." Hver dag møter vi nye teknologier – vi må ta hensyn til dem og kunne forstå dem. Derfor, i den tredje oppgaven, foreslo vi å forstå teknologier som en nybegynnerutvikler vanligvis ikke er kjent med.
I analysen av hver oppgave vil vi fortelle deg ikke bare om riktig prosedyre, men også om vanlige feil.
Oppgave 1: Portefølje
Den første oppgaven ble jobbet med av Yandex.Collections-designer Alexey Cherenkevich, som vet hvordan man gjør layout, og hans tjenestekollega, grensesnittutvikler Sergey Samsonov.
Tilstand
Lag et porteføljenettsted: fortell oss om deg selv, arbeidet ditt og dine forventninger fra skolen. Nettstedet skal samsvare så mye som mulig med den foreslåtte layouten (lenker til layouter: , , , ). Vi er kun interessert i oppsettet, så vennligst ikke bruk JavaScript.
Ved kontroll tar vi hensyn til:
- innrykkstørrelser, fargeriktighet, skriftstil, skriftstørrelse;
- semantisk layout;
- tilstedeværelsen av forskjellige tilstander av elementer: visning av knapper og lenker når du holder markøren, fremhever aktive inndatafelt, etc.;
- kompatibilitet på tvers av nettlesere (testet i de nyeste versjonene av populære nettlesere).
Fordelen vil være:
- bruk av moderne CSS-løsninger: flexbox, grid, etc.;
- Adaptiv layout;
- bruk av pre- og (eller) post-prosessorer, montering, minifisering, optimalisering av utgangskode;
- HTML-skjemavalidering, stilisert filopplastingsknapp.
Oppgaven er ganske omfangsrik, så du kan hoppe over det som ikke fungerer. Dette vil senke poengsummen din litt, men du vil fortsatt kunne demonstrere kunnskapen din. Når du er ferdig, send oss to lenker – til porteføljen din og kildekoden på GitHub.
Oppsettene som ble foreslått i oppgaven var ikke bare med skjermer for mobile enheter, nettbrett og desktop, men også med reelle spesifikasjoner.
For å få mest mulig objektivitet inn i resultatet av kontroll av den første oppgaven, var det mange kriterier for denne sjekken.
kriterier
Designet nettside. Dette virker åpenbart, men noen gutter hoppet helt over noen blokker - enten ønsket de å spare tid, eller så klarte de det ikke. Oppsettet kan grovt sett deles inn i fire hovedskjermer: hovedskjermen med en avatar, en blokk med forventningsliste fra SRI, en blokk med en portefølje og en blokk med kontaktinformasjon. De kunne lages i seksjoner eller ganske enkelt ved hjelp av divs, det viktigste er at alle fire blokkene var tilgjengelige.
Overholdelse av layout med layout. Designeren laget en egen spesifikasjon (inkludert farger, typografi, knappetilstander osv.) for å gjøre det enklere for kandidatene. Nederst var det et hint om innrykk og funksjoner på den første skjermen. Jeg var veldig fornøyd med gutta som tok hensyn til alle designerens ønsker: for eksempel burde den første skjermen ikke vært mindre enn høyden på utsikten.
Adaptiv layout – dette er når grensesnittet ikke bare er lagt slik at ved tre oppløsninger er alt piksel til piksel i layout. I mellomtilstander bør heller ikke oppsettet falle fra hverandre. Noen glemte å begrense den maksimale bredden på beholderen og sette alt til 1920 piksler, noen rotet til bakgrunnen, men totalt sett taklet kandidatene denne oppgaven bra.
Semantisk layout. «Hvor mange ganger har de fortalt verden» at lenken skal være utformet som , knappen – som . Heldigvis oppfylte de fleste kandidatene også dette kravet. Ikke alle gjenkjente den skjulte listen i forventningene til SRI, noe som gjorde at den brukte div-tagger, men det er ikke så ille. Det var en kandidat som satte inn alle de semantiske taggene han kjente – der det var nødvendig og hvor det ikke var nødvendig. For eksempel, i stedet for en liste - og . Tross alt, semantikk - det handler om å forstå sammensetningen av siden din og formålet med hver blokk (de fleste klarte det her), samt bruken av pre- og/eller post-prosessorer (noen få klarte det her, selv om dette var også i poengene - oftest brukte de mindre og scss) .
Fungerende glidebryter. I oppgaven skrev vi at JS ikke kan brukes. Her ble evnen til å løse problemer testet – en glidebryter kunne lages ved hjelp av en haug og . All magien skjer på velgernivået #button-N:checked ~ .slider-inner .slider-slides. Når vi klikker på en av avmerkingsboksene for inndata, går den inn i avmerket tilstand. Vi kan dra nytte av dette og tilordne oversettelsen vi trenger til beholderen med lysbildene: transform: translate(-33%). Du kan se implementeringen av glidebryteren .
Nedtrekkslister. Her kom det hele også til og en lignende velger: .accordion-item input:checked ~ .accordion-item__content. Du kan se gjennomføringen .
Tilgjengelighet av :hover, :active og :focu* tilstander. Et veldig viktig poeng. Komfort under interaksjon med grensesnittet var avhengig av det. Brukeren skal alltid få tilbakemelding på sine handlinger. Dette elementet ble sjekket gjennom hele interaksjonen med spørreskjemaet. Hvis jeg klikket på "Ring meg"-knappen og visuelt ingenting skjedde (selv om forespørselen ble sendt), er dette dårlig, for da vil jeg klikke det igjen og igjen. Som et resultat vil ti forespørsler bli sendt og jeg blir ringt tilbake ti ganger. Vi må ikke glemme at mobile enheter ikke har mus, noe som betyr at det ikke skal være sveving. Og ett punkt til som ikke påvirket de som oppfylte punktet om semantikk. Hvis kontrollen din ikke er et interaktivt element, vil markøren forbli standard når du holder musepekeren over den. Det ser veldig uryddig ut, selv om du har skrevet en reaksjon på å sveve. Ikke undervurder markøren: pekeren.
Animasjoner. Det er viktig at alle reaksjoner som skjer med elementene er jevne. Ingenting i livet er øyeblikkelig, så å ha overganger på sveve og aktiv var nok til å gjøre grensesnittet mer behagelig. Vel, de som animerte glidebryteren og listene er generelt gode.
Bruker den nyeste teknologien. Mange brukte flex, men ingen fullførte oppgaven med grid. Poenget ble telt dersom flex ble brukt riktig. Hvis oppsettet gikk fra hverandre et sted på grunn av nettopp disse bøyningene, fikk du dessverre ingen ekstra poeng.
Skjemavalidering. Alt som var nødvendig var å legge til den nødvendige attributten til hver inndata i skjemaet. Vi la til poeng til de som validerte e-postfeltet som e-post.
Styler filopplastingsknappen. Vi forventet å se en kombinasjon som: og Velg fil . Deretter trengte vi å skjule input og style etiketten. Det er en annen vanlig måte - å lage en gjennomsiktig inngang og legge den på toppen av knappen. Men ikke alle nettlesere tillater styling , og en slik løsning kan ikke kalles fullstendig på tvers av nettlesere. Og det er semantisk riktigere å lage en etikett.
Kompatibilitet på tvers av nettlesere. Vi sjekket at alt var bra i de to siste versjonene av moderne nettlesere (uten IE – deltakerne var heldige), samt i Safari på iPhone og Chrome på Android.
Tvert imot, vi trakk fra poeng hvis noen brukte JS eller Bootstrap: begge ville beseire hensikten med hele oppgaven. Dessuten fikk deltakere med Bootstrap ikke bare et minus, men mistet også mange poeng for semantikk og implementerte elementer.
De som hostet siden deres et sted på Internett, fikk ingen særlig fordel - men anmelderne var veldig glade da de slapp å laste ned depoter og kjøre dem lokalt på datamaskinen. Så dette fungerte som et pluss for karma.
Den første oppgaven var svært nyttig først og fremst for eleven. De som vi ikke godtok har nå en utarbeidet CV - du kan stolt legge den ved alle svar eller legge den ut på gh-sidene dine.
Oppgave 2: Transportvei
Forfatteren av oppgaven er leder for søkegrensesnittgruppen Denis Balyko.
Tilstand
Har du et stjernekart? Den viser navnet på hver stjerne, samt avstanden fra den til andre stjerner i lyssekunder. Implementer løsningsfunksjonen, som skal ta tre argumenter: et objekt der nøklene er navnene på stjernene, og verdiene er avstandene til stjernene (enveis trafikk i rommet), samt navnene på stiens start- og sluttpunkt - henholdsvis start og mål. Funksjonen skal returnere den korteste avstanden fra startstjernen til målstjernen og banen som skal følges.
Funksjonssignatur:
const solution = function(graph, start, finish) { // Ваше решение }Eksempel på inndata:
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';Eksempel utgang:
{ distance: 90, path: ['start', 'A', 'D', 'finish'] }Merk: Løsningsskjelettet er i src/-mappen, legg løsningen din i solution.js.
Verifikasjonen av den andre oppgaven var den mest automatiserte og objektive. De fleste av gutta gjettet at det var nødvendig å implementere Dijkstras algoritme. De som fant beskrivelsen og implementerte algoritmen i JS er godt utført. Men ved kontroll av oppgaven kom vi over mange papirer med samme feil. Vi søkte på Internett etter kodefragmenter og fant en artikkel som deltakerne kopierte algoritmen fra. Det er morsomt at mange kopierte koden fra artikkelen sammen med forfatterens kommentarer. Slike verk fikk lav poengsum. Vi forbyr ikke bruk av noen kilder, men vi ønsker at en person skal fordype seg i det han skriver.
kriterier
Hovedpoeng ble tildelt for prøver. Noen ganger var det tydelig at gutta rotet rundt med depotet, ga nytt navn til mapper og tester ville mislykkes rett og slett fordi de ikke kunne finne de nødvendige filene. I år prøvde vi å hjelpe slike karer og returnerte alt til sin plass for dem. Men neste år planlegger vi å bytte til et konkurransesystem, og dette blir ikke lenger tilgitt.
Det var også "menneskelige", manuelle kriterier. For eksempel tilstedeværelsen av en enkelt kodestil. Ingen trakk poeng for å bruke tabulatorer i stedet for mellomrom eller omvendt. Det er en annen sak om du veksler enkelt anførselstegn med doble anførselstegn i henhold til en regel kjent for deg, og plasserer semikolon tilfeldig.
Løsningens klarhet og lesbarhet ble tatt i betraktning separat. På alle konferanser i verden sier de at 80 % av en programmerers jobb består i å lese andres kode. Til og med skoleelever gjennomgår kodegjennomganger - fra kuratorene og fra hverandre. Så dette kriteriet veide betydelig vekt. Det har vært verk der det ikke var variabler lengre enn ett tegn - vennligst ikke gjør det. Kommentarene fra deltakerne var svært oppmuntrende – med unntak av de som var identiske med Stella Changs kommentarer.
Det siste kriteriet er tilstedeværelsen av autotester. Bare noen få personer la dem til, men for alle ble det et stort pluss i karmaen deres.
Riktig avgjørelse:
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);
};
};Oppgave 3: Aktivitetskalender
Det ble utarbeidet av grensesnittutviklerne Sergey Kazakov og Alexander Podskrebkin.
Tilstand
Skriv en minikalender for å vise timeplanen din. Du kan ta hvilken som helst timeplan du vil. For eksempel planen for frontend-konferanser i 2019.
Kalenderen skal se ut som en liste. Det er ingen andre designkrav. Gjør det mulig å sette hendelsespåminnelser 3, 7 og 14 dager i forveien. Etter den første nedlastingen fra Internett, skal kalenderen åpne og fungere offline.
Nyttige ressurser
Frontend-konferanseplan:
Servicearbeidere:
Notifications API:
Den tredje oppgaven var den mest interessante å teste, fordi det var så mange mulige løsninger, hver med sine egne. Vi sjekket hvordan kandidaten håndterer ukjente teknologier – om han vet hvordan han skal forske, om han tester løsningene sine.
kriterier
Brettet kalender. Ja, det måtte fortsatt legges ut. Det var også de som tok tilstanden for bokstavelig og ikke satte inn en eneste linje med CSS-kode. Det så ikke veldig attraktivt ut, men hvis alt fungerte, ble ikke poengene redusert.
Få en liste over hendelser fra en kilde. Dette er ikke en layoutoppgave, så listen over hendelser inkludert i den ble ikke talt. Du kan alltid avbryte en konferanse, planlegge den på nytt eller legge til en ny. Så det var nødvendig å motta data fra utsiden og gjengi oppsettet basert på den mottatte JSON. Det var viktig å få tak i dataene på noen måte (ved å bruke hentemetoden eller ved å bruke XMLHttpRequest). Hvis en person la til en polyfill for henting og markerte valget sitt i readme, ble dette regnet som et pluss.
Servicearbeiderregistrering uten feil og arbeid offline etter første nedlasting. servicearbeider med tidsplanbufring ved første oppstart. Detaljer om servicearbeidere, deres evner og måter å jobbe med dem på (strategier for å jobbe med cacher, arbeid offline) finner du her.
Evne til å stille inn en påminnelseslik at det faktisk fungerer etter 3, 7, 14 dager. Det var nødvendig å forstå Notifications API, hadde rett på oppgaven. Vi hadde ikke forventet noen spesifikk implementering for å sjekke om det er på tide å presse. Ethvert arbeidsalternativ ble akseptert: lagring i localStorage, IndexDB eller periodisk polling av en servicearbeider. Det var til og med mulig å lage en push-server (her ), men det ville ikke fungere offline. Det var like viktig å få et push etter at siden ble lukket – og åpnet etter en stund. Hvis påminnelsen døde samtidig som siden ble stengt, ble ikke løsningen regnet med. Det er kult når gutta tenkte på anmelderne og gjorde det mulig å få en dytt akkurat nå - for ikke å vente i 3 dager.
Evne til å plassere et ikon på skrivebordet (PWA). Vi sjekket tilstedeværelsen av filen med de riktige ikonene. Noen karer laget denne filen (eller la den generert i CreateReactApp) - men la ikke til de riktige ikonene. Så, når du prøver å installere, oppstod en feil som "et annet ikon er nødvendig".
Kodestil og prosjektstruktur. Som i den andre oppgaven så vi på en enkelt kodestil (selv om den ikke falt sammen med vår). Noen karer skrudde på linters - det er flott.
Konsollfeil. Hvis det var en indikator rett i konsollen på at noe var galt, og deltakeren ikke tok hensyn til det, trakk vi poeng.
Resultater av
Hva er morsomt med deltakernes avgjørelser:
- Ett spørreskjema inneholdt følgende tekst: «En programmerervenn hjalp meg med å sette sammen en React-applikasjon. Jeg bombarderte ham med spørsmål om hvordan og hvorfor, og han fortalte meg det. Jeg likte det veldig godt, jeg vil vite mer om det.» Vi heiet på denne søknaden av hele vårt hjerte, men dessverre var ikke kandidatens venn veldig hjelpsom med å få søknaden til å fungere.
- En kandidat sendte en lenke til GitHub, hvor RAR-arkivet var plassert - det er vanskelig å kommentere dette. 🙂
- En annen kandidat, i kommentaren på den første linjen i filen solution.js, innrømmet ærlig at han kopierte algoritmen.
Vi mottok søknader fra 76 kandidater og valgte ut 23 personer. Vi fikk tilsendt spørreskjemaer ikke bare fra Minsk, men også fra Moskva, St. Petersburg og til og med Tatarstan. Noen av gutta overrasket oss med sine nåværende yrker: en av dem er rettsmedisinsk ekspert, og den andre er medisinstudent.
Resultatet var en interessant fordeling av suksessrater i å fullføre oppgaver. Deltakerne fullførte den første oppgaven med et gjennomsnitt på 60 %, den andre med 50 %, og den tredje viste seg å være den vanskeligste og ble fullført med et gjennomsnitt på 40 %.
Ved første øyekast ser oppgavene komplekse og tidkrevende ut. Grunnen er ikke at vi ønsker å luke ut så mange kandidater som mulig. I løpet av studiene blir studentene møtt med virkelige oppgaver - å lage en prat, Yandex.Music for barn eller Yandex.Weather for væravhengige mennesker. For dette trenger du en startbase.
Jeg husker at jeg så SRI-inngangsoppgaven min for to år siden og tenkte at jeg aldri ville løse den. Det viktigste i dette øyeblikket er å sette seg ned, lese forholdene nøye og begynne å gjøre det. Det viser seg at forholdene inneholder nesten 80 % av løsningen. For eksempel, i tilstanden til den tredje oppgaven (den vanskeligste), la vi til lenker til servicearbeidere og Notifications API på MDN. Studenter som studerte innholdet i lenkene fullførte det uten problemer.
Jeg vil virkelig at denne artikkelen skal leses av kandidater som planlegger å gå inn i SRI i fremtiden, som ikke var i stand til å komme inn på Minsk-skolen, eller som begynner å gjøre noen annen testoppgave. Som du kan se, er det fullt mulig å gjøre det. Du trenger bare å tro på deg selv og lytte til alle tipsene fra forfatterne.
Kilde: www.habr.com