Hodiaŭ malfermiĝis nova aliĝo en Moskvo. La unua etapo de trejnado okazos de la 7-a de septembro ĝis la 25-a de oktobro. Studentoj el aliaj urboj povos partopreni ĝin malproksime aŭ persone - la kompanio pagos por vojaĝoj kaj loĝado en gastejo. La dua, ankaŭ la fina etapo, daŭros ĝis la 3-a de decembro, ĝi povas esti plenumita nur persone.
Mia nomo estas Yulia Seredich, ni skribis ĉi tiun afiŝon kune kun Sergej Kazakov. Ni estas ambaŭ interfacaj programistoj en la Minska oficejo de Yandex kaj diplomiĝintoj de SRI de antaŭaj jaroj.
Okaze de la malfermo de la registriĝo en Moskvo, ni publikigas analizon de enkondukaj taskoj al la antaŭa Lernejo – ĉi tie en Minsko.
Se vi spuras la historion de SRI-taskoj, de jaro al jaro ni testis tri gravajn kapablojn por programisto:
- Aranĝo. Ĉiu programisto devus povi fari aranĝon. Ne okazas, ke vi havas Onklon Seryozha, kiu desegnas por la tuta teamo, kaj vi nur skribas skriptojn. Tial ĉiu studento devas montri kiel li scipovas komposti.
- JavaScript. Se la afero estus limigita al aranĝo, tiam ni ne havus Lernejon de Interfaco-Disvolviĝo, sed Lernejon de Enpaĝigaj Projektistoj. La bele desegnita interfaco devas esti revivigita. Tial, ĉiam estas tasko por JS, sed foje ĝi estas ankaŭ tasko por algoritmoj - ni tiom amas ilin.
- Solvo de problemoj eble estas la plej grava kapablo de programisto. Kiam temas pri kreado de interfacoj, aferoj ŝanĝiĝas tre rapide. Estas kiel Lewis Carroll: "Vi devas kuri kiel eble plej rapide nur por resti en la sama loko, kaj por atingi alian lokon vi devas kuri duoble pli rapide." Ĉiutage ni renkontas novajn teknologiojn - ni devas konsideri ilin kaj povi ilin kompreni. Tial, en la tria tasko, ni proponis kompreni teknologiojn, kiujn komencanta programisto kutime ne konas.
En la analizo de ĉiu tasko, ni rakontos al vi ne nur pri la ĝusta proceduro, sed ankaŭ pri oftaj eraroj.
Tasko 1: Portfolio
La unua tasko estis prilaborita de Yandex.Collections-projektisto Alexey Cherenkevich, kiu scipovas fari aranĝon, kaj lia servokolego, interfacprogramisto Sergey Samsonov.
Kondiĉo
Kreu biletujon retejon: diru al ni pri vi mem, via laboro kaj viaj atendoj de la Lernejo. La retejo devus respondi kiel eble plej multe al la proponita aranĝo (ligiloj al aranĝoj: , , , ). Ni interesiĝas nur pri la aranĝo, do bonvolu ne uzi JavaScript.
Dum kontrolo ni konsideros:
- indentgrandoj, kolorĝusteco, tiparostilo, tiparograndeco;
- semantika aranĝo;
- la ĉeesto de malsamaj statoj de elementoj: montrado de butonoj kaj ligiloj kiam ŝvebas la kursoron, reliefigante aktivajn enigkampojn, ktp.;
- inter-retumila kongruo (provita en la plej novaj versioj de popularaj retumiloj).
La avantaĝo estos:
- uzo de modernaj CSS-solvoj: flekskesto, krado, ktp.;
- Adapta aranĝo;
- uzo de antaŭ- kaj (aŭ) post-procesoroj, kunigo, minigo, optimumigo de eligokodo;
- HTML-formularo validigo, stiligita dosiero alŝuta butono.
La tasko estas sufiĉe granda, do vi povas preterlasi tion, kio ne funkcios. Ĉi tio malaltigos vian poentaron iomete, sed vi ankoraŭ povos pruvi vian scion. Kiam vi finos, sendu al ni du ligilojn - al via biletujo kaj la fontkodon en GitHub.
La aranĝoj proponitaj en la tasko estis ne nur kun ekranoj por porteblaj aparatoj, tablojdoj kaj labortabloj, sed ankaŭ kun realaj specifoj.
Por alporti kiel eble plej multe da objektiveco en la rezulton de kontrolado de la unua tasko, estis multaj kriterioj por tiu ĉi kontrolo.
Kriterioj
Desegnita retejo. Ĉi tio ŝajnas evidenta, sed iuj uloj tute transsaltis kelkajn blokojn - aŭ ili volis ŝpari tempon, aŭ ili ne povis fari ilin. La aranĝo povas esti proksimume dividita en kvar ĉefajn ekranojn: la ĉefa ekrano kun avataro, bloko kun listo de atendoj de SRI, bloko kun biletujo kaj bloko kun kontaktinformoj. Ili povus esti faritaj en sekcioj aŭ simple uzante divs, la ĉefa afero estas, ke ĉiuj kvar blokoj estis disponeblaj.
Konformeco de aranĝo kun aranĝo. La dizajnisto faris apartan specifon (inkluzive de koloroj, tipografio, butonŝtatoj, ktp.) por faciligi ĝin por kandidatoj. Malsupre estis sugesto pri la strekoj kaj trajtoj de la unua ekrano. Mi estis tre kontenta pri la uloj, kiuj konsideris ĉiujn dezirojn de la dezajnisto: ekzemple, la unua ekrano devus esti ne malpli ol la alteco de la vidpunkto.
Adapta aranĝo - jen kiam la interfaco ne estas nur aranĝita tiel ke ĉe tri rezolucioj ĉio estas pikselo al pikselo en aranĝo. En mezaj statoj, la aranĝo ankaŭ ne devas disiĝi. Iuj forgesis limigi la maksimuman larĝon de la ujo kaj agordi ĉion al 1920 pikseloj, iuj fuŝis la fonojn, sed ĝenerale la kandidatoj bone traktis ĉi tiun taskon.
Semantika aranĝo. "Kiom da fojoj ili diris al la mondo", ke ligilo estu desegnita kiel , butono - kiel . Feliĉe, la plej multaj kandidatoj ankaŭ plenumis ĉi tiun postulon. Ne ĉiuj rekonis la kaŝitan liston en la atendoj de la SRI, farante ĝin uzante div-etikedojn, sed ĝi ne estas tiel malbona. Estis kandidato, kiu enmetis ĉiujn semantikajn etikedojn, kiujn li konis – kie ĝi estis necesa kaj kie ĝi ne estis necesa. Ekzemple, anstataŭ listo - kaj . Post ĉio, semantiko - temas pri kompreni la konsiston de via paĝo kaj la celo de ĉiu bloko (la plimulto administris ĝin ĉi tie), kaj ankaŭ la uzon de antaŭ- kaj/aŭ post-procesiloj (kelkaj administris ĝin ĉi tie, kvankam ĉi tio estis ankaŭ en la punktoj - plej ofte ili uzis malpli kaj scss) .
Laboranta glitilo. En la tasko ni skribis, ke JS ne povas esti uzata. Ĉi tie la kapablo solvi problemojn estis provita - glitilo povus esti farita uzante kombinaĵon de kaj . La tuta magio okazas ĉe la elekta nivelo #button-N:checked ~ .slider-inner .slider-slides. Kiam ni alklakas unu el la eniga markobutonoj, ĝi iras en la kontrolitan staton. Ni povas profiti tion kaj atribui la tradukon, kiun ni bezonas al la ujo kun la diapozitivoj: transform: translate(-33%). Vi povas vidi la efektivigon de la glitilo .
Dropdown listoj. Ĉi tie ĉio ankaŭ venis al kaj simila elektilo: .accordion-item input:checked ~ .accordion-item__content. Vi povas vidi la efektivigon .
Havebleco de :ŝvebado, :aktiva kaj :focu* ŝtatoj. Tre grava punkto. Komforto dum interago kun la interfaco dependis de ĝi. La uzanto ĉiam devas ricevi komentojn pri siaj agoj. Ĉi tiu objekto estis kontrolita dum la interago kun la demandaro. Se mi klakis la butonon "Voku min" kaj videble nenio okazis (kvankam la peto estis sendita), tio estas malbona, ĉar tiam mi klakos ĝin denove kaj denove. Kiel rezulto, dek petoj estos senditaj kaj mi estos revokita dek fojojn. Ni ne devas forgesi, ke porteblaj aparatoj ne havas muson, kio signifas, ke ne devus esti ŝvebado. Kaj unu plia punkto, kiu ne influis tiujn, kiuj plenumis la punkton pri semantiko. Se via kontrolo ne estas interaga elemento, tiam kiam vi ŝvebas super ĝi, la kursoro restos norma. Ĝi aspektas tre malorde, eĉ se vi skribis reagon por ŝvebi. Ne subtaksu kursoron: montrilon.
Animacioj. Gravas, ke ĉiuj reagoj okazantaj kun la elementoj estu glataj. Nenio en la vivo estas tuja, do havi transirojn sur ŝvebado kaj aktiva sufiĉis por pli agrabla la interfacon. Nu, tiuj, kiuj vigligis la glitilon kaj listojn, ĝenerale estas bonegaj.
Uzante la plej novan teknologion. Multaj homoj uzis flex, sed neniu plenumis la taskon uzante kradon. La punkto estis kalkulita se flex estis uzata ĝuste. Se ie la aranĝo disiĝis pro ĉi tiuj mem fleksoj, ve, vi ne ricevis pliajn poentojn.
Formvalidigo. Ĉio, kio estis postulata, estis aldoni la postulatan atributon al ĉiu enigo de la formo. Ni aldonis punktojn al tiuj, kiuj validigis la retpoŝtan kampon kiel retpoŝton.
Stilado de la butono de alŝuto de dosiero. Ni atendis vidi kombinaĵon kiel: kaj Elektu dosieron. Poste ni bezonis kaŝi la enigon kaj stiligi la etikedon. Estas alia komuna maniero - fari travideblan enigon kaj meti ĝin sur la butonon. Sed ne ĉiuj retumiloj permesas stiligi , kaj ĉi tiu solvo ne povas esti nomata plene trans-retumilo. Kaj estas semantike pli ĝuste fari etikedon.
Inter-retumila kongruo. Ni kontrolis, ke ĉio estas en ordo en la du lastaj versioj de modernaj retumiloj (sen IE - partoprenantoj estis bonŝancaj), same kiel en Safaro ĉe iPhone kaj Chrome ĉe Androidoj.
Male, ni subtrahis poentojn se iu uzus JS aŭ Bootstrap: ambaŭ el ili malvenkus la celon de la tuta tasko. Krome, partoprenantoj kun Bootstrap ne nur ricevis minuson, sed ankaŭ perdis multajn poentojn por semantiko kaj efektivigitaj elementoj.
Tiuj, kiuj gastigis sian retejon ie en la Interreto, ricevis neniun apartan avantaĝon – sed la recenzistoj estis tre feliĉaj kiam ili ne devis elŝuti deponejojn kaj ruli ilin loke sur sia komputilo. Do ĉi tio servis kiel pluso por karmo.
La unua tasko estis tre utila ĉefe por la lernanto. Tiuj, kiujn ni ne akceptis, havas nun preparitan vivresumon - vi povas fiere kunligi ĝin al ĉiuj respondoj aŭ afiŝi ĝin sur viajn gh-paĝojn.
Tasko 2: Transportvojo
La aŭtoro de la tasko estas la estro de la serĉinterfaca grupo Denis Balyko.
Kondiĉo
Ĉu vi havas stelmapon? Ĝi montras la nomon de ĉiu stelo, same kiel la distancon de ĝi al aliaj steloj en lumsekundoj. Efektivigu la solvan funkcion, kiu devus preni tri argumentojn: objekto en kiu la ŝlosiloj estas la nomoj de la steloj, kaj la valoroj estas la distancoj al la steloj (unudirekta trafiko en la spaco), same kiel la nomoj de la komencaj kaj finpunktoj de la vojo - komenco kaj fino, respektive. La funkcio devus redoni la plej mallongan distancon de la komenca stelo ĝis la finstelo kaj la vojon por sekvi.
Funkcia subskribo:
const solution = function(graph, start, finish) { // Ваше решение }Ekzemplaj enigodatenoj:
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';Ekzempla eligo:
{ distance: 90, path: ['start', 'A', 'D', 'finish'] }Noto: La solvskeleto estas en la dosierujo src/, metu vian solvon en solution.js.
La kontrolo de la dua tasko estis la plej aŭtomatigita kaj objektiva. Plej multaj el la uloj konjektis, ke necesas efektivigi la algoritmon de Dijkstra. Tiuj, kiuj trovis ĝian priskribon kaj efektivigis la algoritmon en JS, estas bone faritaj. Tamen, kontrolante la taskon, ni trovis multajn artikolojn kun la samaj eraroj. Ni serĉis en Interreto kodfragmentojn kaj trovis artikolon el kiu partoprenantoj kopiis la algoritmon. Estas amuze, ke multaj homoj kopiis la kodon de la artikolo kune kun la komentoj de la aŭtoro. Tiaj verkoj ricevis malaltan poentaron. Ni ne malpermesas la uzadon de iuj fontoj, sed ni volas, ke homo enprofundu tion, kion li skribas.
Kriterioj
Ĉefaj punktoj estis aljuĝitaj por testoj. Foje estis klare, ke la uloj fuŝas kun la deponejo, renomante dosierujojn, kaj testoj malsukcesus simple ĉar ili ne povas trovi la necesajn dosierojn. Ĉi-jare ni provis helpi tiajn ulojn kaj redonis ĉion al sia loko por ili. Sed venontjare ni planas ŝanĝi al konkurssistemo, kaj tio ne plu estos pardonita.
Estis ankaŭ "homaj", manaj kriterioj. Ekzemple, la ĉeesto de ununura kodstilo. Neniu subtrahis poentojn por uzi langetojn anstataŭ spacojn aŭ inverse. Alia afero estas, se vi alternu unuopajn citilojn kun duoblaj citiloj laŭ unu regulo konata de vi, kaj metu punktokomojn hazarde.
La klareco kaj legebleco de la solvo estis konsiderataj aparte. En ĉiuj konferencoj en la mondo oni diras, ke 80% de la laboro de programisto konsistas el legado de la kodo de aliaj homoj. Eĉ lernejanoj spertas kodrecenzojn - de siaj kuratoroj kaj unu de la alia. Do ĉi tiu kriterio havis signifan pezon. Estis verkoj en kiuj ne estis variabloj pli longaj ol unu signo - bonvolu ne fari tion. La komentoj de la partoprenantoj estis tre kuraĝigaj – escepte de tiuj, kiuj estis identaj al la komentoj de Stella Chang.
La lasta kriterio estas la ĉeesto de aŭtotestoj. Nur kelkaj homoj aldonis ilin, sed por ĉiuj ĝi fariĝis grandega pluso en ilia karmo.
Ĝusta solvo:
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);
};
};Tasko 3: Eventa Kalendaro
Ĝi estis preparita de interfacprogramistoj Sergey Kazakov kaj Alexander Podskrebkin.
Kondiĉo
Skribu mini-kalendaron por montri vian horaron. Vi povas preni ajnan horaron, kiun vi ŝatas. Ekzemple, la horaro de fasadkonferencoj en 2019.
La kalendaro devus aspekti kiel listo. Ne ekzistas aliaj dezajnaj postuloj. Ebligu agordi memorigilojn pri evento 3, 7 kaj 14 tagojn anticipe. Post la unua elŝuto de la Interreto, la kalendaro devus malfermiĝi kaj funkcii eksterrete.
Utilaj Rimedoj
Frontend-konferenca horaro:
Servaj laboristoj:
Sciigoj API:
La tria tasko estis la plej interesa por provi, ĉar estis tiom da eblaj solvoj, ĉiu kun sia propra. Ni kontrolis kiel la kandidato pritraktas nekonatajn teknologiojn - ĉu li scias esplori, ĉu li testas siajn solvojn.
Kriterioj
Faldita kalendaro. Jes, ĝi ankoraŭ devis esti aranĝita. Estis ankaŭ tiuj, kiuj prenis la kondiĉon tro laŭvorte kaj ne enmetis eĉ unu linion de CSS-kodo. Ĝi ne aspektis tre alloga, sed se ĉio funkciis, la punktoj ne malpliiĝis.
Ricevi liston de eventoj de fonto. Ĉi tio ne estas aranĝotasko, do la listo de eventoj inkluzivitaj en ĝi ne estis kalkulita. Vi ĉiam povas nuligi konferencon, replani ĝin aŭ aldoni novan. Do necesis ricevi datumojn de ekstere kaj redoni la aranĝon bazitan sur la ricevita JSON. Estis grave akiri la datumojn iel ajn (uzante la fetch-metodon aŭ uzante XMLHttpRequest). Se persono aldonis plurplenigaĵon por preni kaj markis sian elekton en la legumi, tio estis kalkulita kiel pluso.
Servolaboristo registriĝo sen eraroj kaj laboru eksterrete post la unua elŝuto. servolaboristo kun horara kaŝmemoro ĉe la unua ekkuro. Detaloj pri servaj laboristoj, iliaj kapabloj kaj manieroj labori kun ili (strategioj por labori kun kaŝmemoroj, labori eksterrete) troveblas ĉi tie.
Kapablo agordi memorigilontiel ke ĝi efektive funkcias post 3, 7, 14 tagoj. Necesis kompreni la Notifications API, estis ĝusta en tasko. Ni ne atendis iun specifan efektivigon kontroli ĉu estas tempo por puŝi. Ajna laboropcio estis akceptita: stokado en loka Stokado, IndexDB aŭ perioda balotado de serva laboristo. Eblis eĉ fari puŝservilon (ĉi tie ), sed ĝi ne funkcius eksterrete. Same grave estis ricevi puŝon post kiam la paĝo estis fermita – kaj malfermita post iom da tempo. Se la memorigilo mortis samtempe kiam la paĝo estis fermita, la solvo ne estis kalkulita. Estas mojose kiam la uloj pensis pri la recenzistoj kaj ebligis akiri puŝon ĝuste nun - por ne atendi 3 tagojn.
Kapablo meti ikonon sur la labortablo (PWA). Ni kontrolis la ĉeeston de la dosiero kun la ĝustaj ikonoj. Iuj uloj faris ĉi tiun dosieron (aŭ lasis ĝin generita en CreateReactApp) - sed ne aldonis la ĝustajn ikonojn. Tiam, kiam oni provis instali, okazis eraro kiel "necesas malsama ikono".
Kodstilo kaj projekta strukturo. Kiel en la dua tasko, ni rigardis ununuran kodstilon (eĉ se ĝi ne koincidis kun la nia). Kelkaj uloj ŝraŭbis sur linters - tio estas bonega.
Konzolaj eraroj. Se estis indikilo ĝuste en la konzolo, ke io malbonas, kaj la partoprenanto ne atentis ĝin, tiam ni subtrahis poentojn.
Rezultoj
Kio amuzas pri la decidoj de la partoprenantoj:
- Unu demandaro enhavis la jenan tekston: “Amiko programisto helpis min kunmeti aplikaĵon React. Mi bombardis lin per demandoj pri kiel kaj kial, kaj li diris al mi. Mi tre ŝatis ĝin, mi volas scii pli pri ĝi." Ni enradikigis ĉi tiun aplikaĵon per ĉiuj koroj, sed bedaŭrinde, la amiko de la kandidato ne estis tre helpema por ke la aplikaĵo funkciis.
- Unu kandidato sendis ligon al GitHub, kie troviĝis la RAR-arkivo - estas malfacile komenti ĉi tion. 🙂
- Alia kandidato, en la komento pri la unua linio de la dosiero solution.js, honeste konfesis, ke li kopiis la algoritmon.
Ni ricevis kandidatiĝojn de 76 kandidatoj kaj elektis 23 homojn. Ni estis senditaj demandaroj ne nur el Minsko, sed ankaŭ el Moskvo, Sankt-Peterburgo kaj eĉ Tatarstano. Kelkaj el la uloj surprizis nin per siaj nunaj profesioj: unu el ili estas jurmedicina fakulo, kaj la alia estas medicina studento.
La rezulto estis interesa distribuo de sukcesprocentoj en plenumado de taskoj. La partoprenantoj plenumis la unuan taskon averaĝe je 60%, la duan je 50%, kaj la tria montriĝis la plej malfacila kaj estis plenumita mezume je 40%.
Unuavide, la taskoj aspektas kompleksaj kaj tempopostulaj. La kialo ne estas, ke ni volas forigi kiel eble plej multajn kandidatojn. Dum siaj studoj, studentoj alfrontas realajn taskojn - fari babiladon, Yandex.Music por infanoj aŭ Yandex.Weather por veterdependaj homoj. Por tio vi bezonas komencan bazon.
Mi memoras, ke mi vidis mian SRI-enirtaskon antaŭ du jaroj kaj pensis, ke mi neniam solvos ĝin. La ĉefa afero en ĉi tiu momento estas sidiĝi, atente legi la kondiĉojn kaj komenci fari ĝin. Rezultas, ke la kondiĉoj enhavas preskaŭ 80% de la solvo. Ekzemple, en la kondiĉo de la tria tasko (la plej malfacila), ni aldonis ligilojn al servaj laboristoj kaj Sciigoj API sur MDN. Studentoj kiuj studis la enhavon de la ligiloj kompletigis ĝin sen malfacileco.
Mi tre ŝatus, ke ĉi tiu artikolo estu legata de kandidatoj, kiuj planas eniri SRI estonte, kiuj ne povis eniri la Minska Lernejon, aŭ kiuj komencas fari ajnan alian testan taskon. Kiel vi povas vidi, estas tute eble fari tion. Vi nur bezonas kredi je vi mem kaj aŭskulti ĉiujn konsilojn de la aŭtoroj.
fonto: www.habr.com