Ngayon ay isang bagong enrollment ang nagbukas sa Moscow. Ang unang yugto ng pagsasanay ay magaganap mula Setyembre 7 hanggang Oktubre 25. Ang mga mag-aaral mula sa ibang mga lungsod ay makakalahok dito nang malayuan o nang personal - magbabayad ang kumpanya para sa paglalakbay at tirahan sa isang hostel. Ang pangalawa, pati na rin ang huling yugto, ay tatagal hanggang Disyembre 3, maaari lamang itong tapusin nang personal.
Ang pangalan ko ay Yulia Seredich, isinulat namin ang post na ito kasama si Sergei Kazakov. Pareho kaming mga developer ng interface sa opisina ng Minsk ng Yandex at mga nagtapos ng SRI mula sa mga nakaraang taon.
Sa okasyon ng pagbubukas ng pagpaparehistro sa Moscow, naglalathala kami ng pagsusuri ng mga panimulang gawain sa nakaraang Paaralan - dito sa Minsk.
Kung susuriin mo ang kasaysayan ng mga takdang-aralin sa SRI, bawat taon ay sinubukan namin ang tatlong mahahalagang kasanayan para sa isang programmer:
- Layout. Dapat magawa ng bawat developer ang layout. Hindi mangyayari na mayroon kang Tito Seryozha na nagdidisenyo para sa buong koponan, at sumusulat ka lamang ng mga script. Samakatuwid, dapat ipakita ng bawat mag-aaral kung paano siya marunong magtypeset.
- JavaScript. Kung ang usapin ay limitado sa layout, hindi tayo magkakaroon ng School of Interface Development, ngunit isang School of Layout Designer. Kailangang buhayin ang magandang dinisenyong interface. Samakatuwid, palaging may gawain para sa JS, ngunit kung minsan isa rin itong gawain para sa mga algorithm - mahal na mahal namin sila.
- Ang paglutas ng problema ay marahil ang pinakamahalagang kasanayan ng isang developer. Pagdating sa paglikha ng mga interface, ang mga bagay ay nagbabago nang napakabilis. Ito ay tulad ni Lewis Carroll: "Kailangan mong tumakbo nang mas mabilis hangga't maaari upang manatili sa parehong lugar, at upang makarating sa ibang lugar kailangan mong tumakbo nang dalawang beses nang mas mabilis." Araw-araw ay nakakatagpo tayo ng mga bagong teknolohiya - kailangan nating isaalang-alang ang mga ito at maunawaan ang mga ito. Samakatuwid, sa ikatlong gawain, iminungkahi naming maunawaan ang mga teknolohiya na karaniwang hindi pamilyar sa isang baguhang developer.
Sa pagsusuri ng bawat gawain, sasabihin namin sa iyo hindi lamang ang tungkol sa tamang pamamaraan, kundi pati na rin ang tungkol sa mga karaniwang pagkakamali.
Gawain 1: Portfolio
Ang unang gawain ay ginawa ng Yandex.Collections designer Alexey Cherenkevich, na nakakaalam kung paano gawin ang layout, at ang kanyang kasamahan sa serbisyo, ang developer ng interface na si Sergey Samsonov.
Kundisyon
Gumawa ng portfolio website: sabihin sa amin ang tungkol sa iyong sarili, iyong trabaho at iyong mga inaasahan mula sa Paaralan. Ang site ay dapat tumugma hangga't maaari sa iminungkahing layout (mga link sa mga layout: , , , ). Interesado lang kami sa layout, kaya mangyaring huwag gumamit ng JavaScript.
Kapag sinusuri, isasaalang-alang namin:
- laki ng indentation, tama ng kulay, estilo ng font, laki ng font;
- layout ng semantiko;
- ang pagkakaroon ng iba't ibang estado ng mga elemento: pagpapakita ng mga pindutan at mga link kapag ini-hover ang cursor, pag-highlight ng mga aktibong input field, atbp.;
- cross-browser compatibility (nasubok sa pinakabagong bersyon ng mga sikat na browser).
Ang kalamangan ay magiging:
- paggamit ng mga modernong solusyon sa CSS: flexbox, grid, atbp.;
- Adaptive na layout;
- paggamit ng mga pre- at (o) post-processors, assembly, minification, optimization ng output code;
- HTML form validation, naka-istilong pindutan ng pag-upload ng file.
Ang gawain ay medyo malaki, kaya maaari mong laktawan kung ano ang hindi gagana. Bahagyang babaan nito ang iyong marka, ngunit maipapakita mo pa rin ang iyong kaalaman. Kapag tapos ka na, padalhan kami ng dalawang link - sa iyong portfolio at ang source code sa GitHub.
Ang mga layout na iminungkahi sa pagtatalaga ay hindi lamang sa mga screen para sa mga mobile device, tablet at desktop, kundi pati na rin sa mga tunay na detalye.
Upang magdala ng mas maraming objectivity hangga't maaari sa resulta ng pagsuri sa unang gawain, mayroong maraming pamantayan para sa pagsusuring ito.
criteria
Dinisenyong website. Mukhang halata ito, ngunit ang ilang mga lalaki ay ganap na nilaktawan ang ilang mga bloke - maaaring gusto nilang makatipid ng oras, o hindi nila magawa ang mga ito. Ang layout ay maaaring halos nahahati sa apat na pangunahing screen: ang pangunahing screen na may avatar, isang bloke na may listahan ng mga inaasahan mula sa SRI, isang bloke na may portfolio at isang bloke na may impormasyon sa pakikipag-ugnayan. Maaari silang gawin sa mga seksyon o simpleng paggamit ng mga div, ang pangunahing bagay ay magagamit ang lahat ng apat na bloke.
Pagsunod ng layout sa layout. Ang taga-disenyo ay gumawa ng isang hiwalay na detalye (kabilang ang mga kulay, palalimbagan, mga estado ng pindutan, atbp.) upang gawing mas madali para sa mga kandidato. Sa ibaba ay may pahiwatig sa mga indent at feature ng unang screen. Tuwang-tuwa ako sa mga lalaki na isinasaalang-alang ang lahat ng mga kagustuhan ng taga-disenyo: halimbawa, ang unang screen ay dapat na hindi bababa sa taas ng viewport.
Adaptive na layout - ito ay kapag ang interface ay hindi lamang inilatag upang sa tatlong mga resolusyon ang lahat ay pixel sa pixel sa layout. Sa mga intermediate na estado, hindi rin dapat masira ang layout. Nakalimutan ng ilan na limitahan ang maximum na lapad ng lalagyan at itakda ang lahat sa 1920 pixels, ang ilan ay ginulo ang mga background, ngunit sa pangkalahatan ay nakaya ng mga kandidato ang gawaing ito.
Layout ng semantiko. "Ilang beses na nilang sinabi sa mundo" na ang link ay dapat na idinisenyo bilang , ang button β bilang . Sa kabutihang palad, karamihan sa mga kandidato ay natupad din ang kahilingang ito. Hindi nakilala ng lahat ang nakatagong listahan sa mga inaasahan ng SRI, ginagawa itong gumagamit ng mga div tag, ngunit hindi ito ganoon kalala. May isang kandidato na nagpasok ng lahat ng semantic tag na alam niya - kung saan ito kinakailangan at kung saan ito ay hindi kinakailangan. Halimbawa, sa halip na isang listahan - at . Pagkatapos ng lahat, semantics - ito ay tungkol sa pag-unawa sa komposisyon ng iyong pahina at ang layunin ng bawat bloke (pinamamahalaan ito ng karamihan dito), pati na rin ang paggamit ng mga pre- at / o post-processors (ilang pinamamahalaan ito dito, kahit na ito ay din sa mga puntos - madalas na ginagamit nila mas kaunti at scss) .
Gumaganang slider. Sa assignment na sinulat namin na hindi magagamit ang JS. Dito nasubok ang kakayahang malutas ang mga problema - maaaring gumawa ng slider gamit ang isang bungkos At . Ang lahat ng magic ay nangyayari sa selector level #button-N:checked ~ .slider-inner .slider-slides. Kapag nag-click kami sa isa sa mga checkbox ng input, napupunta ito sa naka-check na estado. Maaari naming samantalahin ito at italaga ang pagsasalin na kailangan namin sa lalagyan na may mga slide: transform: translate(-33%). Maaari mong makita ang pagpapatupad ng slider .
Mga listahan ng dropdown. Dito rin napunta ang lahat at isang katulad na tagapili: .accordion-item input:checked ~ .accordion-item__content. Maaari mong makita ang pagpapatupad .
Availability ng :hover, :active at :focu* states. Isang napakahalagang punto. Ang kaginhawahan sa panahon ng pakikipag-ugnayan sa interface ay nakasalalay dito. Ang user ay dapat palaging makatanggap ng feedback sa kanilang mga aksyon. Ang item na ito ay sinuri sa buong pakikipag-ugnayan sa questionnaire. Kung na-click ko ang pindutang "Tawagan ako" at biswal na walang nangyari (kahit na ipinadala ang kahilingan), ito ay masama, dahil pagkatapos ay i-click ko ito nang paulit-ulit. Bilang resulta, sampung kahilingan ang ipapadala at tatawagin ako pabalik ng sampung beses. Hindi natin dapat kalimutan na ang mga mobile device ay walang mouse, ibig sabihin ay hindi dapat magkaroon ng hover. At isa pang punto na hindi nakaapekto sa mga tumupad sa punto tungkol sa semantics. Kung ang iyong kontrol ay hindi isang interactive na elemento, kapag nag-hover ka sa ibabaw nito ang cursor ay mananatiling karaniwan. Mukhang napakalinis, kahit na nagsulat ka ng reaksyon sa pag-hover. Huwag maliitin ang cursor: pointer.
Mga animation. Mahalaga na ang lahat ng mga reaksyon na nagaganap sa mga elemento ay makinis. Walang bagay sa buhay na madalian, kaya sapat na ang pagkakaroon ng mga transition sa hover at aktibo upang gawing mas kaaya-aya ang interface. Well, ang mga nag-animate sa slider at mga listahan ay karaniwang mahusay.
Gamit ang pinakabagong teknolohiya. Maraming tao ang gumamit ng flex, ngunit walang nakakumpleto sa gawain gamit ang grid. Ang punto ay binibilang kung ang pagbaluktot ay ginamit nang tama. Kung sa isang lugar ang layout ay nagkahiwalay dahil sa mga napaka-flex na ito, sayang, hindi ka nakatanggap ng anumang karagdagang mga puntos.
Pagpapatunay ng Form. Ang kailangan lang ay idagdag ang kinakailangang katangian sa bawat input ng form. Nagdagdag kami ng mga puntos sa mga nag-validate sa field ng email bilang email.
Pag-istilo sa pindutan ng pag-upload ng file. Inaasahan naming makakita ng kumbinasyon tulad ng: at Piliin ang file . Susunod na kailangan naming itago ang input at i-istilo ang label. May isa pang karaniwang paraan - upang gumawa ng isang transparent na input at ilagay ito sa tuktok ng pindutan. Ngunit hindi lahat ng browser ay nagpapahintulot sa pag-istilo , at ang gayong solusyon ay hindi matatawag na ganap na cross-browser. At ito ay semantically mas tama upang gumawa ng isang label.
Cross-browser compatibility. Sinuri namin na maayos ang lahat sa dalawang pinakabagong bersyon ng mga modernong browser (nang walang IE - maswerte ang mga kalahok), pati na rin sa Safari sa mga iPhone at Chrome sa mga Android.
Sa kabaligtaran, ibinawas namin ang mga puntos kung may gumamit ng JS o Bootstrap: pareho nilang matatalo ang layunin ng buong gawain. Bukod dito, ang mga kalahok na may Bootstrap ay hindi lamang nakatanggap ng minus, ngunit nawalan din ng maraming puntos para sa mga semantika at ipinatupad na mga elemento.
Ang mga nagho-host ng kanilang site sa isang lugar sa Internet ay hindi nakatanggap ng anumang partikular na kalamangan - ngunit ang mga tagasuri ay napakasaya nang hindi nila kailangang mag-download ng mga repositoryo at patakbuhin ang mga ito nang lokal sa kanilang computer. Kaya ito ay nagsilbing plus para sa karma.
Ang unang gawain ay lubhang kapaki-pakinabang lalo na para sa mag-aaral. Ang mga hindi namin tinanggap ay mayroon na ngayong nakahanda na resume - maaari mong buong kapurihan na ilakip ito sa lahat ng mga tugon o i-post ito sa iyong gh-pages.
Gawain 2: Ruta ng transportasyon
Ang may-akda ng gawain ay ang pinuno ng pangkat ng mga interface ng paghahanap na si Denis Balyko.
Kundisyon
May star map ka ba? Ipinapakita nito ang pangalan ng bawat bituin, pati na rin ang distansya mula dito sa iba pang mga bituin sa mga light seconds. Ipatupad ang function ng solusyon, na dapat tumagal ng tatlong argumento: isang bagay kung saan ang mga susi ay ang mga pangalan ng mga bituin, at ang mga halaga ay ang mga distansya sa mga bituin (one-way na trapiko sa espasyo), pati na rin ang mga pangalan ng ang simula at pagtatapos ng mga punto ng landas - simula at tapusin, ayon sa pagkakabanggit. Dapat ibalik ng function ang pinakamaikling distansya mula sa start star hanggang sa finish star at ang landas na susundan.
Lagda ng function:
const solution = function(graph, start, finish) { // ΠΠ°ΡΠ΅ ΡΠ΅ΡΠ΅Π½ΠΈΠ΅ }Halimbawa ng data ng pag-input:
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';Halimbawang output:
{ distance: 90, path: ['start', 'A', 'D', 'finish'] }Tandaan: Ang solution skeleton ay nasa src/ folder, ilagay ang iyong solusyon sa solution.js.
Ang pag-verify ng pangalawang gawain ay ang pinaka-automated at layunin. Karamihan sa mga lalaki ay nahulaan na kinakailangan upang ipatupad ang algorithm ng Dijkstra. Mahusay ang mga nakahanap ng paglalarawan nito at nagpatupad ng algorithm sa JS. Gayunpaman, nang suriin ang takdang-aralin, nakatagpo kami ng maraming papel na may parehong mga pagkakamali. Naghanap kami sa Internet ng mga fragment ng code at nakakita ng artikulo kung saan kinopya ng mga kalahok ang algorithm. Nakakatuwa na maraming tao ang kinopya ang code mula sa artikulo kasama ang mga komento ng may-akda. Ang ganitong mga gawa ay nakatanggap ng mababang marka. Hindi namin ipinagbabawal ang paggamit ng anumang mga mapagkukunan, ngunit gusto namin ang isang tao na bungkalin ang kanyang isinusulat.
criteria
Ang mga pangunahing puntos ay iginawad para sa mga pagsusulit. Minsan ay malinaw na ang mga lalaki ay nakikigulo sa repository, pagpapalit ng pangalan ng mga folder, at ang mga pagsubok ay mabibigo dahil lamang sa hindi nila mahanap ang mga kinakailangang file. Sa taong ito sinubukan naming tulungan ang mga ganoong lalaki at ibinalik ang lahat sa lugar nito para sa kanila. Ngunit sa susunod na taon plano naming lumipat sa isang sistema ng paligsahan, at hindi na ito mapapatawad.
Mayroon ding "tao", manu-manong pamantayan. Halimbawa, ang pagkakaroon ng isang solong istilo ng code. Walang nagbawas ng mga puntos para sa paggamit ng mga tab sa halip na mga puwang o vice versa. Isa pang bagay kung papalitan mo ang mga solong quote sa mga dobleng quote ayon sa isang panuntunang alam mo, at maglalagay ng mga semicolon nang random.
Ang kalinawan at pagiging madaling mabasa ng solusyon ay isinasaalang-alang nang hiwalay. Sa lahat ng mga kumperensya sa mundo sinasabi nila na 80% ng trabaho ng isang programmer ay binubuo ng pagbabasa ng code ng ibang tao. Kahit na ang mga mag-aaral ay sumasailalim sa mga pagsusuri sa code - mula sa kanilang mga tagapangasiwa at mula sa bawat isa. Kaya ang pamantayang ito ay nagdala ng makabuluhang timbang. May mga gawa kung saan walang mga variable na mas mahaba kaysa sa isang character - mangyaring huwag gawin iyon. Ang mga komento mula sa mga kalahok ay lubhang nakapagpapatibay - maliban sa mga katulad ng mga komento ni Stella Chang.
Ang huling criterion ay ang pagkakaroon ng mga autotest. Ilang tao lang ang nagdagdag sa kanila, ngunit para sa lahat ay naging malaking plus ito sa kanilang karma.
Tamang solusyon:
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);
};
};Gawain 3: Kalendaryo ng mga Kaganapan
Inihanda ito ng mga developer ng interface na sina Sergey Kazakov at Alexander Podskrebkin.
Kundisyon
Sumulat ng isang mini-kalendaryo upang ipakita ang iyong iskedyul. Maaari kang kumuha ng anumang iskedyul na gusto mo. Halimbawa, ang iskedyul ng mga frontend conference sa 2019.
Ang kalendaryo ay dapat magmukhang isang listahan. Walang ibang mga kinakailangan sa disenyo. Gawing posible na magtakda ng mga paalala sa kaganapan 3, 7 at 14 na araw nang maaga. Pagkatapos ng unang pag-download mula sa Internet, dapat na buksan at gumana nang offline ang kalendaryo.
Kapaki-pakinabang na mapagkukunan
Iskedyul ng kumperensya sa harapan:
Mga manggagawa sa serbisyo:
Notifications API:
Ang pangatlong gawain ay ang pinaka-kawili-wiling subukan, dahil napakaraming posibleng solusyon, bawat isa ay may kanya-kanyang sarili. Sinuri namin kung paano pinangangasiwaan ng kandidato ang mga hindi pamilyar na teknolohiya - kung alam niya kung paano magsaliksik, kung sinusubukan niya ang kanyang mga solusyon.
criteria
Nakatuping kalendaryo. Oo, kailangan pa itong ilatag. Mayroon ding mga masyadong literal na kinuha ang kundisyon at hindi nagpasok ng isang linya ng CSS code. Hindi ito mukhang kaakit-akit, ngunit kung ang lahat ay gumana, ang mga puntos ay hindi nabawasan.
Pagkuha ng listahan ng mga kaganapan mula sa isang pinagmulan. Hindi ito isang gawain sa layout, kaya hindi binilang ang listahan ng mga kaganapang kasama dito. Maaari mong kanselahin anumang oras ang isang kumperensya, muling iiskedyul ito, o magdagdag ng bago. Kaya kinailangan na makatanggap ng data mula sa labas at i-render ang layout batay sa natanggap na JSON. Mahalagang makuha ang data sa anumang paraan (gamit ang paraan ng pagkuha o paggamit ng XMLHttpRequest). Kung nagdagdag ang isang tao ng polyfill para sa pagkuha at minarkahan ang kanyang pinili sa readme, mabibilang ito bilang plus.
Ang pagpaparehistro ng manggagawa sa serbisyo nang walang mga pagkakamali at magtrabaho offline pagkatapos ng unang pag-download. service worker na may schedule caching sa unang boot. Ang mga detalye tungkol sa mga service worker, kanilang mga kakayahan at paraan ng pakikipagtulungan sa kanila (mga diskarte para sa pagtatrabaho sa mga cache, pagtatrabaho offline) ay matatagpuan dito.
Kakayahang magtakda ng paalalaupang ito ay talagang gumana pagkatapos ng 3, 7, 14 na araw. Kinailangan itong maunawaan ang Notifications API, ay tama sa gawain. Hindi namin inaasahan ang anumang partikular na pagpapatupad upang suriin kung oras na upang itulak. Tinanggap ang anumang opsyon sa pagtatrabaho: imbakan sa localStorage, IndexDB o pana-panahong pagboto ng isang service worker. Posible pa ring gumawa ng push server (dito ), ngunit hindi ito gagana offline. Parehong mahalaga na makatanggap ng push pagkatapos isara ang pahina - at mabuksan pagkaraan ng ilang oras. Kung namatay ang paalala sa parehong oras na isinara ang pahina, hindi binibilang ang solusyon. Ang cool kapag naisip ng mga lalaki ang tungkol sa mga reviewer at ginawang posible na makakuha ng push ngayon - upang hindi maghintay ng 3 araw.
Kakayahang maglagay ng icon sa desktop (PWA). Sinuri namin ang presensya ng file gamit ang tamang mga icon. Ginawa ng ilang lalaki ang file na ito (o iniwan itong nabuo sa CreateReactApp) - ngunit hindi nagdagdag ng mga tamang icon. Pagkatapos, kapag sinusubukang i-install, naganap ang isang error tulad ng "kailangan ng ibang icon".
Codestyle at istraktura ng proyekto. Tulad ng sa pangalawang gawain, tumingin kami sa isang solong codestyle (kahit na hindi ito nag-tutugma sa atin). Ang ilang mga guys screwed sa linters - iyan ay mahusay.
Mga error sa console. Kung mayroong isang tagapagpahiwatig mismo sa console na may isang bagay na mali, at hindi ito pinansin ng kalahok, pagkatapos ay ibinawas namin ang mga puntos.
Mga resulta ng
Ano ang nakakatawa sa mga desisyon ng mga kalahok:
- Ang isang talatanungan ay naglalaman ng sumusunod na teksto: "Tinulungan ako ng isang kaibigang programmer na bumuo ng isang React application. Binomba ko siya ng mga tanong tungkol sa kung paano at bakit, at sinabi niya sa akin. Nagustuhan ko ito, gusto kong malaman ang higit pa tungkol dito." Buong puso naming pinag-uugatan ang application na ito, ngunit sa kasamaang-palad, hindi masyadong nakatulong ang kaibigan ng kandidato sa paggawa ng aplikasyon.
- Isang kandidato ang nagpadala ng link sa GitHub, kung saan matatagpuan ang RAR archive - mahirap magkomento dito. π
- Ang isa pang kandidato, sa komento sa unang linya ng solution.js file, ay matapat na inamin na kinopya niya ang algorithm.
Nakatanggap kami ng mga aplikasyon mula sa 76 na kandidato at pumili ng 23 tao. Kami ay pinadalhan ng mga questionnaire hindi lamang mula sa Minsk, kundi pati na rin mula sa Moscow, St. Petersburg at maging sa Tatarstan. Ang ilan sa mga lalaki ay nagulat sa amin sa kanilang kasalukuyang mga propesyon: isa sa kanila ay isang forensic expert, at ang isa ay isang medikal na estudyante.
Ang resulta ay isang kawili-wiling pamamahagi ng mga rate ng tagumpay sa pagkumpleto ng mga gawain. Nakumpleto ng mga kalahok ang unang gawain sa average na 60%, ang pangalawa ay 50%, at ang pangatlo ay naging pinakamahirap at natapos ng average na 40%.
Sa unang sulyap, ang mga gawain ay mukhang kumplikado at matagal. Ang dahilan ay hindi dahil gusto nating tanggalin ang pinakamaraming kandidato hangga't maaari. Sa panahon ng kanilang pag-aaral, ang mga mag-aaral ay nahaharap sa mga gawain sa totoong buhay - paggawa ng chat, Yandex.Music para sa mga bata o Yandex.Weather para sa mga taong umaasa sa panahon. Para dito kailangan mo ng panimulang base.
Naaalala kong nakita ko ang aking gawain sa pagpasok sa SRI dalawang taon na ang nakakaraan at iniisip na hindi ko ito malulutas. Ang pangunahing bagay sa sandaling ito ay umupo, maingat na basahin ang mga kondisyon at simulan ang paggawa nito. Lumalabas na ang mga kondisyon ay naglalaman ng halos 80% ng solusyon. Halimbawa, sa kondisyon ng ikatlong gawain (ang pinakamahirap), nagdagdag kami ng mga link sa mga service worker at Notifications API sa MDN. Ang mga mag-aaral na nag-aral ng mga nilalaman ng mga link ay nakumpleto ito nang walang kahirapan.
Gusto ko talagang basahin ang artikulong ito ng mga kandidato na nagpaplanong pumasok sa SRI sa hinaharap, na hindi nakapasok sa Minsk School, o nagsisimulang gumawa ng anumang iba pang gawain sa pagsubok. Tulad ng nakikita mo, ito ay lubos na posible na gawin ito. Kailangan mo lang maniwala sa iyong sarili at makinig sa lahat ng mga tip mula sa mga may-akda.
Pinagmulan: www.habr.com