Sot u hap një regjistrim i ri në në Moskë. Faza e parë e trajnimit do të zhvillohet nga data 7 shtator deri më 25 tetor. Studentët nga qytetet e tjera do të mund të marrin pjesë në të nga distanca ose personalisht - kompania do të paguajë për udhëtimin dhe akomodimin në një bujtinë. E dyta, edhe ajo finale, do të zgjasë deri më 3 dhjetor, mund të kryhet vetëm personalisht.
Emri im është Yulia Seredich, ne e shkruam këtë postim së bashku me Sergei Kazakov. Ne jemi të dy zhvillues ndërfaqesh në zyrën e Yandex në Minsk dhe të diplomuar në SRI nga vitet e mëparshme.
Me rastin e hapjes së regjistrimit në Moskë, ne po publikojmë një analizë të detyrave hyrëse në Shkollën e mëparshme - këtu në Minsk.
Nëse gjurmoni historinë e detyrave të SRI, nga viti në vit ne testuam tre aftësi të rëndësishme për një programues:
- Paraqitja. Çdo zhvillues duhet të jetë në gjendje të bëjë layout. Nuk ndodh që të kesh xhaxha Seryozha që dizajnon për të gjithë ekipin dhe ti shkruan vetëm skenarë. Ndaj çdo nxënës duhet të tregojë se si di të shtypë me shtypshkronjë.
- JavaScript. Nëse çështja do të kufizohej në paraqitjen, atëherë nuk do të kishim një Shkollë të Zhvillimit të Ndërfaqes, por një Shkollë të Dizajnuesve të Layout. Ndërfaqja e dizajnuar bukur duhet të ringjallet. Prandaj, ka gjithmonë një detyrë për JS, por ndonjëherë është gjithashtu një detyrë për algoritmet - ne i duam aq shumë.
- Zgjidhja e problemeve është ndoshta aftësia më e rëndësishme e një zhvilluesi. Kur bëhet fjalë për krijimin e ndërfaqeve, gjërat po ndryshojnë shumë shpejt. Është si Lewis Carroll: “Duhet të vraposh sa më shpejt që të mundesh vetëm për të qëndruar në të njëjtin vend dhe për të arritur në një vend tjetër duhet të vraposh dy herë më shpejt”. Çdo ditë hasim teknologji të reja - duhet t'i marrim parasysh dhe të jemi në gjendje t'i kuptojmë ato. Prandaj, në detyrën e tretë, ne propozuam të kuptojmë teknologjitë me të cilat një zhvillues fillestar zakonisht nuk është i njohur.
Në analizën e secilës detyrë, ne do t'ju tregojmë jo vetëm për procedurën e saktë, por edhe për gabimet e zakonshme.
Detyra 1: Portofoli
Detyra e parë u punua nga projektuesi i Yandex.Collections Alexey Cherenkevich, i cili di të bëjë layout, dhe kolegu i tij i shërbimit, zhvilluesi i ndërfaqes Sergey Samsonov.
Gjendja
Krijoni një faqe interneti portofoli: na tregoni për veten tuaj, punën tuaj dhe pritshmëritë tuaja nga Shkolla. Faqja duhet të korrespondojë sa më shumë që të jetë e mundur me paraqitjen e propozuar (lidhjet me paraqitjet: , , , ). Ne jemi të interesuar vetëm për paraqitjen, kështu që ju lutemi mos përdorni JavaScript.
Gjatë kontrollit do të kemi parasysh:
- madhësitë e dhëmbëzimit, korrektësia e ngjyrave, stili i shkronjave, madhësia e shkronjave;
- paraqitje semantike;
- prania e gjendjeve të ndryshme të elementeve: shfaqja e butonave dhe lidhjeve kur rri pezull kursorin, theksimi i fushave aktive të hyrjes, etj.;
- përputhshmëria e ndër-shfletuesve (e testuar në versionet më të fundit të shfletuesve të njohur).
Avantazhi do të jetë:
- përdorimi i zgjidhjeve moderne CSS: flexbox, grid, etj.;
- Struktura adaptive;
- përdorimi i para- dhe (ose) pas-procesorëve, montimi, minifikimi, optimizimi i kodit të daljes;
- Vlefshmëria e formës HTML, butoni i stilizuar i ngarkimit të skedarit.
Detyra është mjaft voluminoze, kështu që ju mund të kaloni atë që nuk do të funksionojë. Kjo do të ulë pak rezultatin tuaj, por prapë do të jeni në gjendje të demonstroni njohuritë tuaja. Kur të keni mbaruar, na dërgoni dy lidhje - në portofolin tuaj dhe kodin burimor në GitHub.
Paraqitjet e propozuara në detyrë nuk ishin vetëm me ekrane për pajisje celulare, tableta dhe desktop, por edhe me specifika reale.
Për të sjellë sa më shumë objektivitet në rezultatin e kontrollit të detyrës së parë, kishte shumë kritere për këtë kontroll.
kriteret
Faqja e dizenjuar. Kjo duket e qartë, por disa djem anashkaluan plotësisht disa blloqe - ose donin të kursenin kohë, ose nuk mund t'i bënin ato. Paraqitja mund të ndahet përafërsisht në katër ekrane kryesore: ekrani kryesor me një avatar, një bllok me një listë pritshmërish nga SRI, një bllok me një portofol dhe një bllok me informacion kontakti. Ato mund të bëhen në seksione ose thjesht duke përdorur div, gjëja kryesore është që të katër blloqet ishin të disponueshme.
Pajtueshmëria e paraqitjes me paraqitjen. Dizajneri bëri një specifikim të veçantë (duke përfshirë ngjyrat, tipografinë, gjendjet e butonave, etj.) për ta bërë më të lehtë për kandidatët. Në fund kishte një aluzion për dhëmbëzat dhe veçoritë e ekranit të parë. Isha shumë i kënaqur me djemtë që morën parasysh të gjitha dëshirat e stilistit: për shembull, ekrani i parë duhet të ishte jo më pak se lartësia e pamjes.
Paraqitja adaptive - kjo është kur ndërfaqja nuk është thjesht e vendosur në mënyrë që në tre rezolucione gjithçka të jetë pixel në pixel në paraqitje. Në gjendjet e ndërmjetme, as faqosja nuk duhet të prishet. Disa harruan të kufizonin gjerësinë maksimale të kontejnerit dhe vendosën gjithçka në 1920 piksel, disa ngatërruan sfondet, por në përgjithësi kandidatët e përballuan mirë këtë detyrë.
Paraqitja semantike. "Sa herë i kanë thënë botës" se lidhja duhet të dizajnohet si , butoni - si . Fatmirësisht, shumica e kandidatëve e përmbushën edhe këtë kërkesë. Jo të gjithë e njohën listën e fshehur në pritjet e SRI, duke e bërë atë duke përdorur etiketat div, por nuk është aq e keqe. Ishte një kandidat që futi të gjitha etiketat semantike që dinte - ku ishte e nevojshme dhe ku nuk ishte e nevojshme. Për shembull, në vend të një liste - dhe . Në fund të fundit, semantika - ka të bëjë me të kuptuarit e përbërjes së faqes suaj dhe qëllimit të secilit bllok (shumica e menaxhoi këtu), si dhe përdorimin e përpunuesve para dhe / ose pas (disa e arritën këtu, megjithëse kjo ishte gjithashtu në pikë - më së shpeshti përdornin më pak dhe scss) .
Rrëshqitësi i punës. Në detyrë kemi shkruar që JS nuk mund të përdoret. Këtu u testua aftësia për të zgjidhur problemet - një rrëshqitës mund të bëhej duke përdorur një tufë Dhe . E gjithë magjia ndodh në nivelin e përzgjedhësit #button-N:checked ~ .slider-inner .slider-slides. Kur klikojmë në një nga kutitë e kontrollit të hyrjes, ai kalon në gjendjen e zgjedhur. Ne mund të përfitojmë nga kjo dhe të caktojmë përkthimin që na nevojitet në kontejnerin me rrëshqitjet: transform: translate(-33%). Ju mund të shihni zbatimin e rrëshqitësit .
Listat rënëse. Këtu gjithçka zbriti gjithashtu dhe një përzgjedhës i ngjashëm: .harmonikë-artikull hyrje:kontrolluar ~ .accordion-item__content. Ju mund të shihni zbatimin .
Disponueshmëria e gjendjeve :hover, :active dhe :focu*. Një pikë shumë e rëndësishme. Komoditeti gjatë ndërveprimit me ndërfaqen varej prej tij. Përdoruesi duhet të marrë gjithmonë komente për veprimet e tij. Ky artikull u kontrollua gjatë gjithë ndërveprimit me pyetësorin. Nëse klikova butonin "Më telefono" dhe vizualisht nuk ndodhi asgjë (edhe pse kërkesa u dërgua), kjo është e keqe, sepse atëherë do ta klikoj përsëri dhe përsëri. Si rezultat, dhjetë kërkesa do të dërgohen dhe unë do të thirrem përsëri dhjetë herë. Nuk duhet të harrojmë se pajisjet celulare nuk kanë miun, që do të thotë se nuk duhet të ketë një rri pezull. Dhe një pikë tjetër që nuk preku ata që plotësuan pikën për semantikën. Nëse kontrolli juaj nuk është një element ndërveprues, atëherë kur kaloni pezull mbi të, kursori do të mbetet standard. Duket shumë e çrregullt, edhe nëse keni shkruar një reagim për të pezulluar. Mos e nënvlerësoni kursorin: treguesin.
Animacionet. Është e rëndësishme që të gjitha reagimet që ndodhin me elementët të jenë të qetë. Asgjë në jetë nuk është e menjëhershme, kështu që kalimi i tranzicionit në lëvizje dhe aktiv ishte i mjaftueshëm për ta bërë ndërfaqen më të këndshme. Epo, ata që animuan rrëshqitësin dhe listat janë përgjithësisht të shkëlqyer.
Duke përdorur teknologjinë më të fundit. Shumë njerëz përdorën flex, por askush nuk e përfundoi detyrën duke përdorur rrjetin. Pika numërohej nëse fleksi përdorej saktë. Nëse diku faqosja u nda për shkak të këtyre përkuljeve, mjerisht, nuk keni marrë asnjë pikë shtesë.
Vleresimi i formularit. Gjithçka që kërkohej ishte shtimi i atributit të kërkuar në çdo hyrje të formularit. Ne u shtuam pikë atyre që vërtetuan fushën e emailit si email.
Stilimi i butonit të ngarkimit të skedarit. Prisnim të shihnim një kombinim si: dhe Zgjidhni skedarin . Më pas na duhej të fshihnim hyrjen dhe të stilonim etiketën. Ekziston një mënyrë tjetër e zakonshme - të bëni një hyrje transparente dhe ta vendosni atë në krye të butonit. Por jo të gjithë shfletuesit lejojnë stilimin , dhe një zgjidhje e tillë nuk mund të quhet plotësisht ndër-shfletues. Dhe semantikisht është më e saktë të bësh një etiketë.
Pajtueshmëria me shfletues. Ne kontrolluam që gjithçka ishte në rregull në dy versionet më të fundit të shfletuesve modernë (pa IE - pjesëmarrësit ishin me fat), si dhe në Safari në iPhone dhe Chrome në Android.
Përkundrazi, ne zbritëm pikë nëse dikush përdorte JS ose Bootstrap: të dy do të mposhtnin qëllimin e gjithë detyrës. Për më tepër, pjesëmarrësit me Bootstrap jo vetëm që morën një minus, por humbën edhe shumë pikë për semantikën dhe elementët e zbatuar.
Ata që pritën faqen e tyre diku në internet nuk morën ndonjë avantazh të veçantë - por rishikuesit ishin shumë të lumtur kur nuk u duhej të shkarkonin depo dhe t'i përdornin ato në nivel lokal në kompjuterin e tyre. Pra, kjo shërbeu si një plus për karmën.
Detyra e parë ishte shumë e dobishme kryesisht për studentin. Ata që ne nuk i pranuam tani kanë një rezyme të përgatitur - mund t'ia bashkëngjitni me krenari të gjitha përgjigjeve ose ta postoni në faqet tuaja gh.
Detyra 2: Rruga e transportit
Autori i detyrës është kreu i grupit të ndërfaqeve të kërkimit Denis Balyko.
Gjendja
A keni një hartë me yje? Ai tregon emrin e çdo ylli, si dhe distancën prej tij në yjet e tjerë në sekonda dritë. Zbatoni funksionin e zgjidhjes, i cili duhet të marrë tre argumente: një objekt në të cilin çelësat janë emrat e yjeve, dhe vlerat janë distancat me yjet (trafiku me një drejtim në hapësirë), si dhe emrat e pikat e fillimit dhe të përfundimit të shtegut - përkatësisht fillimi dhe mbarimi. Funksioni duhet të kthejë distancën më të shkurtër nga ylli fillestar në yllin e përfundimit dhe shtegun që duhet ndjekur.
Nënshkrimi i funksionit:
const solution = function(graph, start, finish) { // Ваше решение }Shembull i të dhënave hyrëse:
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';Shembull i daljes:
{ distance: 90, path: ['start', 'A', 'D', 'finish'] }Shënim: Skeleti i zgjidhjes është në dosjen src/, vendoseni zgjidhjen tuaj në solution.js.
Verifikimi i detyrës së dytë ishte më i automatizuari dhe objektivi. Shumica e djemve menduan se ishte e nevojshme të zbatohej algoritmi i Dijkstra. Ata që gjetën përshkrimin e tij dhe zbatuan algoritmin në JS, kanë bërë mirë. Megjithatë, gjatë kontrollimit të detyrës, hasëm në shumë letra me të njëjtat gabime. Ne kërkuam në internet për fragmente kodi dhe gjetëm një artikull nga i cili pjesëmarrësit kopjuan algoritmin. Është qesharake që shumë njerëz kopjuan kodin nga artikulli së bashku me komentet e autorit. Punime të tilla morën një vlerësim të ulët. Ne nuk e ndalojmë përdorimin e asnjë burimi, por duam që një person të thellohet në atë që shkruan.
kriteret
Pikët kryesore janë dhënë për testet. Ndonjëherë ishte e qartë se djemtë po ngatërroheshin me depon, duke riemërtuar dosjet dhe testet do të dështonin thjesht sepse nuk mund të gjenin skedarët e nevojshëm. Këtë vit ne u përpoqëm të ndihmonim djem të tillë dhe u kthyem gjithçka në vendin e vet. Por vitin e ardhshëm ne planifikojmë të kalojmë në një sistem konkursi dhe kjo nuk do të falet më.
Kishte edhe kritere “njerëzore”, manuale. Për shembull, prania e një stili të vetëm kodi. Askush nuk zbriti pikë për përdorimin e skedave në vend të hapësirave ose anasjelltas. Është një çështje tjetër nëse alternoni thonjëza teke me thonjëza të dyfishta sipas një rregulli të njohur për ju dhe vendosni pikëpresje në mënyrë të rastësishme.
Qartësia dhe lexueshmëria e zgjidhjes u morën parasysh veçmas. Në të gjitha konferencat në botë ata thonë se 80% e punës së një programuesi konsiston në leximin e kodit të njerëzve të tjerë. Edhe nxënësit e shkollës i nënshtrohen rishikimeve të kodit - nga kuratoret e tyre dhe nga njëri-tjetri. Pra, ky kriter kishte peshë të konsiderueshme. Kishte vepra në të cilat nuk kishte variabla më të gjatë se një karakter - ju lutemi mos e bëni këtë. Komentet nga pjesëmarrësit ishin shumë inkurajuese - me përjashtim të atyre që ishin identike me komentet e Stella Chang.
Kriteri i fundit është prania e autotesteve. Vetëm disa njerëz i shtuan ato, por për të gjithë u bë një plus i madh në karmën e tyre.
Zgjidhja e duhur:
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);
};
};Detyra 3: Kalendari i Ngjarjeve
Ai u përgatit nga zhvilluesit e ndërfaqes Sergey Kazakov dhe Alexander Podskrebkin.
Gjendja
Shkruani një mini-kalendar për të shfaqur orarin tuaj. Ju mund të merrni çdo orar që ju pëlqen. Për shembull, orari i konferencave frontend në 2019.
Kalendari duhet të duket si një listë. Nuk ka kërkesa të tjera të projektimit. Bëni të mundur vendosjen e kujtuesve të ngjarjeve 3, 7 dhe 14 ditë përpara. Pas shkarkimit të parë nga Interneti, kalendari duhet të hapet dhe të funksionojë jashtë linje.
Burime të dobishme
Orari i konferencës frontend:
Punonjësit e shërbimit:
API-ja e njoftimeve:
Detyra e tretë ishte më interesante për t'u testuar, sepse kishte shumë zgjidhje të mundshme, secila me të vetën. Ne kontrolluam se si kandidati trajton teknologjitë e panjohura - nëse ai di të hulumtojë, nëse ai teston zgjidhjet e tij.
kriteret
Kalendari i palosur. Po, ende duhej të shtrohej. Kishte gjithashtu nga ata që e morën kushtin shumë fjalë për fjalë dhe nuk futën asnjë rresht të kodit CSS. Nuk dukej shumë tërheqëse, por nëse gjithçka funksiononte, pikët nuk u ulën.
Marrja e një liste ngjarjesh nga një burim. Kjo nuk është një detyrë e paraqitjes, kështu që lista e ngjarjeve të përfshira në të nuk u numërua. Mund të anuloni gjithmonë një konferencë, ta riplanifikoni atë ose të shtoni një të re. Pra, ishte e nevojshme të merreshin të dhëna nga jashtë dhe të jepej faqosja bazuar në JSON-in e marrë. Ishte e rëndësishme të merreshin të dhënat në çfarëdo mënyre (duke përdorur metodën e marrjes ose duke përdorur XMLHttpRequest). Nëse një person ka shtuar një polifill për fetch dhe ka shënuar zgjedhjen e tij në readme, kjo llogaritet si një plus.
Regjistrimi i punonjësit të shërbimit pa gabime dhe punoni jashtë linje pas shkarkimit të parë. punonjës shërbimi me caching të orarit në nisjen e parë. Detaje për punonjësit e shërbimit, aftësitë e tyre dhe mënyrat e punës me ta (strategjitë për të punuar me cache, puna jashtë linje) mund të gjenden këtu.
Aftësia për të vendosur një kujtesëkështu që në të vërtetë funksionon pas 3, 7, 14 ditësh. Ishte e nevojshme për të kuptuar API-në e Njoftimeve, ishte drejt në detyrë. Ne nuk prisnim ndonjë zbatim specifik për të kontrolluar nëse është koha për të nxitur. U pranua çdo opsion pune: ruajtja në localStorage, IndexDB ose votimi periodik nga një punonjës shërbimi. Madje ishte e mundur të bëhej një server shtytës (këtu ), por nuk do të funksiononte jashtë linje. Ishte po aq e rëndësishme për të marrë një shtytje pasi faqja u mbyll - dhe u hap pas disa kohësh. Nëse kujtesa vdiq në të njëjtën kohë që faqja u mbyll, zgjidhja nuk llogaritet. Shtë bukur kur djemtë menduan për recensuesit dhe bënë të mundur që të merrnin një shtytje tani - në mënyrë që të mos prisni 3 ditë.
Aftësia për të vendosur një ikonë në desktop (PWA). Ne kontrolluam praninë e dosjes me ikonat e sakta. Disa djem e bënë këtë skedar (ose e lanë të krijuar në CreateReactApp) - por nuk shtuan ikonat e sakta. Më pas, gjatë përpjekjes për të instaluar, ndodhi një gabim si "duhet një ikonë tjetër".
Kodi i stilit dhe struktura e projektit. Ashtu si në detyrën e dytë, ne shikuam një stil të vetëm kodi (edhe nëse nuk përkonte me tonën). Disa djem të vidhosur në linja - kjo është e mrekullueshme.
Gabimet e konsolës. Nëse kishte një tregues të drejtë në tastierë që diçka nuk ishte në rregull, dhe pjesëmarrësi nuk i kushtoi vëmendje, atëherë ne zbritëm pikë.
Rezultatet e
Çfarë është qesharake në lidhje me vendimet e pjesëmarrësve:
- Një pyetësor përmbante tekstin e mëposhtëm: “Një mik programues më ndihmoi të bashkoja një aplikacion React. E kam bombarduar me pyetje se si dhe pse, dhe ai më tha. Më pëlqeu shumë, dua të di më shumë për të.” Ne po përpiqeshim me gjithë zemër për këtë aplikacion, por për fat të keq, shoku i kandidatit nuk ishte shumë i dobishëm për funksionimin e aplikacionit.
- Një kandidat dërgoi një lidhje në GitHub, ku ndodhej arkivi RAR - është e vështirë të komentosh për këtë. 🙂
- Një tjetër kandidat, në komentin në rreshtin e parë të skedarit solution.js, pranoi sinqerisht se ai kopjoi algoritmin.
Kemi pranuar aplikime nga 76 kandidatë dhe kemi përzgjedhur 23 persona. Na dërguan pyetësorë jo vetëm nga Minsku, por edhe nga Moska, Shën Petersburgu dhe madje edhe Tatarstani. Disa nga djemtë na befasuan me profesionet e tyre aktuale: njëri prej tyre është ekspert i mjekësisë ligjore dhe tjetri student i mjekësisë.
Rezultati ishte një shpërndarje interesante e përqindjeve të suksesit në përfundimin e detyrave. Pjesëmarrësit e përfunduan detyrën e parë me një mesatare prej 60%, të dytën me 50%, dhe e treta doli të ishte më e vështira dhe u krye me një mesatare prej 40%.
Në pamje të parë, detyrat duken komplekse dhe kërkojnë kohë. Arsyeja nuk është se ne duam të heqim sa më shumë kandidatë të jetë e mundur. Gjatë trajnimit të tyre, studentët përballen me detyra të jetës reale - duke bërë një bisedë, Yandex.Music për fëmijë ose Yandex.Weather për njerëzit që varen nga moti. Për këtë ju nevojitet një bazë fillestare.
Mbaj mend që pashë detyrën time të hyrjes në SRI dy vjet më parë dhe mendova se nuk do ta zgjidhja kurrë. Gjëja kryesore në këtë moment është të uleni, të lexoni me kujdes kushtet dhe të filloni ta bëni atë. Rezulton se kushtet përmbajnë pothuajse 80% të zgjidhjes. Për shembull, në kushtin e detyrës së tretë (më e vështira), ne shtuam lidhje me punonjësit e shërbimit dhe API-në e njoftimeve në MDN. Nxënësit që studiuan përmbajtjen e lidhjeve e plotësuan pa vështirësi.
Do të dëshiroja shumë që ky artikull të lexohej nga kandidatët që planifikojnë të hyjnë në SRI në të ardhmen, të cilët nuk ishin në gjendje të hynin në Shkollën e Minskut ose që po fillojnë të bëjnë ndonjë detyrë tjetër testimi. Siç mund ta shihni, është mjaft e mundur për ta bërë këtë. Thjesht duhet të besoni në veten tuaj dhe të dëgjoni të gjitha këshillat nga autorët.
Burimi: www.habr.com