Käyttöliittymäkehityskoulu: Minskin tehtävien analyysi ja uusi joukko Moskovassa

Tänään avattiin uusi ilmoittautuminen Yandex-käyttöliittymän kehittämiskoulu Moskovassa. Koulutuksen ensimmäinen vaihe järjestetään 7.-25. Muiden kaupunkien opiskelijat voivat osallistua siihen etänä tai henkilökohtaisesti – yritys maksaa matkat ja majoituksen hostellissa. Toinen, myös viimeinen vaihe, kestää 3. joulukuuta asti, sen voi suorittaa vain henkilökohtaisesti.

Nimeni on Julia Seredich, kirjoitimme tämän viestin yhdessä Sergei Kazakovin kanssa. Olemme molemmat käyttöliittymäkehittäjiä Yandexin Minskin toimistossa ja valmistuneet SRI:stä aiemmilta vuosilta.

Ilmoittautumisen avaamisen yhteydessä Moskovassa julkaisemme analyysin edellisen koulun - täällä Minskissä - johdantotehtävistä.

Jos seuraat SRI-tehtävien historiaa, testasimme vuodesta toiseen kolme tärkeää ohjelmoijan taitoa:

• Layout. Jokaisen kehittäjän pitäisi pystyä tekemään layout. Ei tapahdu, että sinulla on Seryozha-setä, joka suunnittelee koko tiimille, ja sinä kirjoitat vain käsikirjoituksia. Siksi jokaisen opiskelijan on näytettävä, kuinka hän osaa ladontaa.
• JavaScript. Jos asia rajoittuisi layoutiin, meillä ei olisi rajapinnan kehittämisen koulua, vaan taittosuunnittelijoiden koulua. Kauniisti suunniteltu käyttöliittymä on saatava henkiin. Siksi JS:lle on aina tehtävä, mutta joskus se on myös algoritmien tehtävä - rakastamme niitä niin paljon.
• Ongelmanratkaisu on ehkä kehittäjän tärkein taito. Mitä tulee käyttöliittymien luomiseen, asiat muuttuvat hyvin nopeasti. Se on kuin Lewis Carroll: "Sinun täytyy juosta niin nopeasti kuin pystyt vain pysyäksesi samassa paikassa, ja päästäksesi toiseen paikkaan sinun täytyy juosta kaksi kertaa nopeammin." Joka päivä kohtaamme uusia teknologioita – meidän on otettava ne huomioon ja kyettävä ymmärtämään niitä. Siksi kolmannessa tehtävässä ehdotimme tekniikoiden ymmärtämistä, joita aloitteleva kehittäjä ei yleensä tunne.

Kunkin tehtävän analysoinnissa kerromme paitsi oikeasta menettelystä myös yleisistä virheistä.

Tehtävä 1: Portfolio

Ensimmäisen tehtävän työskentelivät Yandex.Collections-suunnittelija Aleksei Tšerenkevitš, joka osaa taittaa, ja hänen palvelukollegansa, käyttöliittymäkehittäjä Sergei Samsonov.

Kunto

Luo portfoliosivusto: kerro meille itsestäsi, työstäsi ja odotuksistasi koululta. Sivuston tulee vastata mahdollisimman paljon ehdotettua ulkoasua (linkit asetteluihin: 1000px, 600px, 320px, erittely). Olemme kiinnostuneita vain ulkoasusta, joten älä käytä JavaScriptiä.

Tarkistaessamme otamme huomioon:

• sisennysten koot, värin oikeellisuus, kirjasintyyli, kirjasinkoko;
• semanttinen asettelu;
• elementtien eri tilojen läsnäolo: painikkeiden ja linkkien näyttäminen vietäessä kohdistinta, aktiivisten syöttökenttien korostaminen jne.;
• Selainten välinen yhteensopivuus (testattu suosittujen selainten uusimmissa versioissa).

Etuna tulee olemaan:

• nykyaikaisten CSS-ratkaisujen käyttö: flexbox, grid jne.;
• Mukautuva asettelu;
• esi- ja (tai) jälkiprosessorien käyttö, kokoonpano, minimointi, tuloskoodin optimointi;
• HTML-lomakkeen vahvistus, tyylitelty tiedoston latauspainike.

Tehtävä on melko suuri, joten voit ohittaa sen, mikä ei toimi. Tämä laskee pisteitäsi hieman, mutta pystyt silti osoittamaan tietosi. Kun olet valmis, lähetä meille kaksi linkkiä – portfolioosi ja lähdekoodiin GitHubissa.

Tehtävässä ehdotetut asettelut eivät olleet pelkästään mobiililaitteiden, tablettien ja pöytätietokoneiden näyttöjä, vaan myös todellisia määrityksiä.

Jotta ensimmäisen tehtävän tarkastuksen tulokseen saataisiin mahdollisimman paljon objektiivisuutta, tässä tarkastuksessa oli monia kriteerejä.

kriteerit

Suunniteltu verkkosivusto. Tämä vaikuttaa itsestään selvältä, mutta jotkut kaverit ohittivat osan lohkoista kokonaan - joko he halusivat säästää aikaa tai eivät pystyneet tekemään niitä. Asettelu voidaan jakaa karkeasti neljään päänäyttöön: päänäyttö avatarilla, lohko, jossa on luettelo SRI:n odotuksista, lohko portfoliolla ja lohko yhteystiedoilla. Ne voitiin tehdä osioissa tai yksinkertaisesti diveillä, pääasia, että kaikki neljä lohkoa olivat saatavilla.

Asettelun yhteensopivuus asettelun kanssa. Suunnittelija teki erillisen määrityksen (mukaan lukien värit, typografia, painikkeiden tilat jne.) helpottaakseen ehdokkaiden käyttöä. Alareunassa oli vihje ensimmäisen näytön sisennyksistä ja ominaisuuksista. Olin erittäin tyytyväinen tyyppeihin, jotka ottivat huomioon kaikki suunnittelijan toiveet: esimerkiksi ensimmäisen näytön olisi pitänyt olla vähintään näkymän korkeus.

Mukautuva asettelu - Tämä on silloin, kun käyttöliittymä ei ole vain aseteltu niin, että kolmella resoluutiolla kaikki on pikselistä pikseliin asettelussa. Välitiloissa layout ei myöskään saa hajota. Jotkut unohtivat rajoittaa säiliön enimmäisleveyttä ja asettaa kaiken 1920 pikseliin, jotkut sotkevat taustat, mutta kaiken kaikkiaan ehdokkaat selviytyivät tästä tehtävästä hyvin.

Semanttinen asettelu. "Kuinka monta kertaa he ovat kertoneet maailmalle", että linkki pitäisi suunnitella muotoon , painike - muotoon . Onneksi useimmat ehdokkaat täyttivät myös tämän vaatimuksen. Kaikki eivät tunnistaneet piilotettua luetteloa SRI:n odotuksissa, tehden siitä div-tageja, mutta se ei ole niin huono. Siellä oli ehdokas, joka lisäsi kaikki semanttiset tunnisteet, jotka hän tiesi - missä se oli välttämätöntä ja missä ei. Esimerkiksi luettelon sijaan - ja . Loppujen lopuksi semantiikka - kyse on sivusi koostumuksen ja kunkin lohkon tarkoituksen ymmärtämisestä (enemmistö onnistui sen täällä), sekä esi- ja/tai jälkikäsittelyohjelmien käytöstä (muutama onnistui täällä, vaikka tämä oli myös pisteissä - useimmiten he käyttivät vähemmän ja scss) .

Toimiva liukusäädin. Tehtävässä kirjoitimme, että JS:ää ei voi käyttää. Täällä testattiin kykyä ratkaista ongelmia - liukusäädin voitiin tehdä ja yhdistelmällä. Kaikki taika tapahtuu valitsintasolla #button-N:checked ~ .slider-inner .slider-slides. Kun napsautamme yhtä syöttövalintaruutua, se siirtyy valittuun tilaan. Voimme hyödyntää tätä ja määrittää tarvitsemamme käännöksen säilöön dioilla: transform: translate (-33%). Näet liukusäätimen toteutuksen täällä.

Pudotusvalikot. Tässä kaikki johtui myös ja vastaavasta valitsimesta: .accordion-item input:checked ~ .accordion-item__content. Voit nähdä toteutuksen täällä.

:hover-, :active- ja :focu*-tilojen saatavuus. Erittäin tärkeä kohta. Mukavuus käyttöliittymän kanssa vuorovaikutuksessa riippui siitä. Käyttäjän tulee aina saada palautetta toimistaan. Tämä kohta tarkistettiin koko vuorovaikutuksen ajan kyselylomakkeen kanssa. Jos napsautin "Soita minulle" -painiketta ja visuaalisesti mitään ei tapahtunut (vaikka pyyntö lähetettiin), tämä on huono asia, koska napsautan sitä uudestaan ​​​​ja uudestaan. Tämän seurauksena kymmenen pyyntöä lähetetään ja minulle soitetaan takaisin kymmenen kertaa. Emme saa unohtaa, että mobiililaitteissa ei ole hiirtä, mikä tarkoittaa, että siellä ei pitäisi olla hiiri. Ja vielä yksi kohta, joka ei vaikuttanut niihin, jotka täyttivät semantiikan kohdan. Jos säädin ei ole interaktiivinen elementti, kun viet hiiren sen päälle, osoitin pysyy vakiona. Se näyttää erittäin epäsiistiltä, ​​vaikka olisit kirjoittanut reaktion leijumiseen. Älä aliarvioi kursoria: osoitin.

Animaatiot. On tärkeää, että kaikki elementtien kanssa tapahtuvat reaktiot ovat tasaisia. Mikään elämässä ei ole välitöntä, joten siirtymät leijumaan ja aktiiviseksi riittivät tekemään käyttöliittymästä miellyttävämmän. No, ne, jotka animoivat liukusäädintä ja luetteloita, ovat yleensä mahtavia.

Käyttämällä uusinta tekniikkaa. Monet ihmiset käyttivät flexiä, mutta kukaan ei suorittanut tehtävää ruudukon avulla. Piste laskettiin, jos flexiä käytettiin oikein. Jos jossain layout hajosi näiden joustojen takia, et valitettavasti saanut lisäpisteitä.

Lomakkeen validointi. Kaikki mitä vaadittiin, oli lisätä vaadittu attribuutti jokaiseen lomakkeen syötteeseen. Lisäsimme pisteitä niille, jotka vahvistivat sähköpostikentän sähköpostina.

Tiedoston latauspainikkeen muotoilu. Odotimme näkevämme seuraavan yhdistelmän: ja Valitse tiedosto. Seuraavaksi meidän piti piilottaa syöte ja muotoilla etiketti. On toinenkin yleinen tapa - tehdä läpinäkyvä syöttö ja laittaa se painikkeen päälle. Mutta kaikki selaimet eivät salli -tyyliä, eikä tätä ratkaisua voida kutsua täysin ristiinselaimeksi. Ja on semanttisesti oikein tehdä etiketti.

Selainten välinen yhteensopivuus. Tarkistimme, että kaikki oli kunnossa nykyaikaisten selaimien kahdessa uusimmassa versiossa (ilman IE:tä - osallistujat olivat onnekkaita), sekä iPhonen Safarissa ja Android-laitteiden Chromessa.

Päinvastoin, vähennimme pisteitä, jos joku käytti JS:ää tai Bootstrapia: molemmat kumosivat koko tehtävän tarkoituksen. Lisäksi Bootstrapin osallistujat eivät saaneet vain miinusta, vaan myös menettivät monia pisteitä semantiikasta ja toteutetuista elementeistä.

Ne, jotka isännöivät sivustoaan jossain Internetissä, eivät saaneet erityistä etua - mutta arvioijat olivat erittäin iloisia, kun heidän ei tarvinnut ladata tietovarastoja ja suorittaa niitä paikallisesti tietokoneella. Joten tämä oli plussa karmalle.

Ensimmäinen tehtävä oli erittäin hyödyllinen ensisijaisesti opiskelijalle. Niillä, joita emme hyväksyneet, on nyt valmis ansioluettelo - voit ylpeänä liittää sen kaikkiin vastauksiin tai lähettää sen gh-sivuillesi.

Tehtävä 2: Kuljetusreitti

Tehtävän kirjoittaja on hakurajapintojen ryhmän johtaja Denis Balyko.

Kunto

Onko sinulla tähtikartta? Se näyttää kunkin tähden nimen sekä etäisyyden siitä muihin tähtiin valosekunneissa. Toteuta ratkaisufunktio, jossa tulee olla kolme argumenttia: objekti, jossa avaimet ovat tähtien nimet ja arvot etäisyydet tähtiin (yksisuuntainen liikenne avaruudessa) sekä tähtien nimet. polun aloitus- ja loppupisteet - alku ja maali, vastaavasti. Toiminnon tulee palauttaa lyhin etäisyys lähtötähdestä maalitähteen ja seurattava polku.

Toiminnon allekirjoitus:

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

Esimerkki syöttötiedoista:

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

Esimerkkituloste:

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

Huomautus: Ratkaisurunko on src/-kansiossa, laita ratkaisusi tiedostoon solution.js.

Toisen tehtävän todentaminen oli automatisoiduin ja objektiivisin. Useimmat kaverit arvasivat, että Dijkstran algoritmi oli tarpeen toteuttaa. Ne, jotka löysivät sen kuvauksen ja toteuttivat algoritmin JS:ssä, ovat hyvin tehneet. Tehtävää tarkasteltaessa törmäsimme kuitenkin moniin papereihin, joissa oli samoja virheitä. Etsimme Internetistä koodinpätkät ja löysimme artikkelin, josta osallistujat kopioivat algoritmin. On hauskaa, että monet ihmiset kopioivat koodin artikkelista yhdessä kirjoittajan kommenttien kanssa. Tällaiset teokset saivat alhaiset arvosanat. Emme kiellä minkään lähteen käyttöä, mutta haluamme, että ihminen syventyy kirjoittamaansa.

kriteerit

Pääpisteet jaettiin kokeista. Joskus oli selvää, että kaverit sekaisivat arkiston kanssa, nimeävät kansioita uudelleen ja testit epäonnistuivat yksinkertaisesti siksi, että he eivät löytäneet tarvittavia tiedostoja. Tänä vuonna yritimme auttaa tällaisia ​​tyyppejä ja palautimme kaiken heidän puolestaan ​​paikoilleen. Mutta ensi vuonna aiomme siirtyä kilpailujärjestelmään, eikä sitä enää anneta anteeksi.

Siellä oli myös "inhimillisiä", manuaalisia kriteerejä. Esimerkiksi yhden koodin tyylin olemassaolo. Kukaan ei vähentänyt pisteitä sarkaimien käytöstä välilyöntien sijaan tai päinvastoin. On toinen asia, jos vaihdat yksittäisiä lainausmerkkejä kaksoislainausmerkeillä yhden tuntemasi säännön mukaan ja sijoitat puolipisteitä satunnaisesti.

Ratkaisun selkeys ja luettavuus otettiin huomioon erikseen. Kaikissa maailman konferensseissa sanotaan, että 80 % ohjelmoijan työstä koostuu muiden ihmisten koodin lukemisesta. Jopa koululaiset käyvät läpi koodiarvioinnit - kuraattoriensa ja toisiltaan. Joten tällä kriteerillä oli huomattava painoarvo. On ollut töitä, joissa ei ole ollut yhden merkin pidempiä muuttujia - älä tee niin. Osallistujien kommentit olivat erittäin rohkaisevia - lukuun ottamatta niitä, jotka olivat identtisiä Stella Changin kommentin kanssa.

Viimeinen kriteeri on automaattisten testien läsnäolo. Vain harvat lisäsivät niitä, mutta kaikille siitä tuli valtava plussa karmassa.

Oikea ratkaisu:

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

Tehtävä 3: Tapahtumakalenteri

Sen valmistivat käyttöliittymäkehittäjät Sergey Kazakov ja Alexander Podskrebkin.

Kunto

Kirjoita minikalenteri näyttääksesi aikataulusi. Voit valita minkä tahansa aikataulun. Esimerkiksi frontend-konferenssien aikataulu vuonna 2019.

Kalenterin pitäisi näyttää luettelolta. Muita suunnitteluvaatimuksia ei ole. Mahdollista tapahtumamuistutusten asettaminen 3, 7 ja 14 päivää etukäteen. Ensimmäisen Internet-latauksen jälkeen kalenterin pitäisi avautua ja toimia offline-tilassa.

Hyödyllisiä resursseja

Frontend-konferenssin aikataulu:
confs.tech/javascript?topics=javascript%2Bcss%2Bux

Palvelutyöntekijät:
developer.mozilla.org/ru/docs/Web/API/Service_Worker_API/Using_Service_Workers
developers.google.com/web/fundamentals/primers/service-workers

Ilmoitussovellusliittymä:
developer.mozilla.org/ru/docs/Web/API/Notifications_API

Kolmas tehtävä oli mielenkiintoisin testata, koska mahdollisia ratkaisuja oli niin monia, jokaisella omansa. Tarkastimme, kuinka ehdokas käsittelee tuntemattomia teknologioita - osaako hän tutkia, testaako hän ratkaisujaan.

kriteerit

Taitettu kalenteri. Kyllä, se piti vielä selvittää. Oli myös niitä, jotka ottivat ehdon liian kirjaimellisesti eivätkä lisänneet yhtään riviä CSS-koodia. Se ei näyttänyt kovin houkuttelevalta, mutta jos kaikki toimi, pisteet eivät laskeneet.

Tapahtumaluettelon saaminen lähteestä. Tämä ei ole asettelutehtävä, joten siihen sisältyviä tapahtumia ei laskettu. Voit aina peruuttaa neuvottelun, ajoittaa sen uudelleen tai lisätä uuden. Joten oli tarpeen vastaanottaa tiedot ulkopuolelta ja tehdä asettelu vastaanotetun JSONin perusteella. Tietojen hankkiminen oli tärkeää millä tahansa tavalla (hakumenetelmällä tai XMLHttpRequestillä). Jos henkilö lisäsi hakuun polyfillin ja merkitsi valintansa readme-luetteloon, tämä laskettiin plussaksi.

Palvelutyöntekijän rekisteröinti ilman virheitä ja työskentele offline-tilassa ensimmäisen latauksen jälkeen. Tässä on esimerkki. palvelutyöntekijä, jolla on aikataulun välimuisti ensimmäisessä käynnistyksessä. Tietoja palvelutyöntekijöistä, heidän kyvyistään ja heidän kanssaan työskentelytavoistaan ​​(välimuistien kanssa työskentelyn strategiat, offline-työskentely) löydät täältä.

Mahdollisuus asettaa muistutusniin, että se todella toimii 3, 7, 14 päivän kuluttua. Ilmoitussovellusliittymän ymmärtäminen oli välttämätöntä, linkki mihin oli oikeassa tehtävässä. Emme odottaneet mitään erityistä toteutusta tarkistaaksemme, onko aika työntää. Mikä tahansa toimiva vaihtoehto hyväksyttiin: tallennus localStorageen, IndexDB tai huoltotyöntekijän säännöllinen kysely. Oli jopa mahdollista tehdä push-palvelin (täällä esimerkki), mutta se ei toimi offline-tilassa. Yhtä tärkeää oli saada push sivun sulkemisen jälkeen - ja avata jonkin ajan kuluttua. Jos muistutus kuoli samalla kun sivu suljettiin, ratkaisua ei laskettu. On siistiä, kun kaverit ajattelivat arvostelijoita ja mahdollistivat työntämisen jo nyt - jotta ei jouduttaisi odottamaan 3 päivää.

Mahdollisuus sijoittaa kuvake työpöydälle (PWA). Tarkistimme tiedoston olemassaolon manifest.json oikeilla kuvakkeilla. Jotkut kaverit tekivät tämän tiedoston (tai jättivät sen luotuksi CreateReactAppissa) - mutta eivät lisänneet oikeita kuvakkeita. Sitten, kun yrität asentaa, tapahtui virhe, kuten "toinen kuvake tarvitaan".

Koodityyli ja projektin rakenne. Kuten toisessa tehtävässä, tarkastelimme yhtä koodityyliä (vaikka se ei olisi sama kuin meidän). Jotkut jätkät päihittivät - se on hienoa.

Konsolivirheet. Jos konsolissa oli osoitin, että jotain oli vialla, eikä osallistuja kiinnittänyt siihen huomiota, vähennimme pisteitä.

Tulokset

Mikä on hauskaa osallistujien päätöksissä:

• Yhdessä kyselylomakkeessa oli seuraava teksti: ”Ohjelmoijaystävä auttoi minua kokoamaan React-sovelluksen. Pommitin häntä kysymyksillä siitä, miten ja miksi, ja hän kertoi minulle. Pidin siitä todella, haluan tietää siitä lisää." Kannatimme tätä hakemusta koko sydämestämme, mutta valitettavasti ehdokkaan ystävä ei auttanut hakemuksen toiminnassa.
• Yksi ehdokas lähetti linkin GitHubiin, jossa RAR-arkisto sijaitsi - tätä on vaikea kommentoida. 🙂
• Toinen ehdokas myönsi ratkaisu.js-tiedoston ensimmäisen rivin kommentissa rehellisesti kopioineensa algoritmin.

Saimme hakemukset 76 hakijalta ja valitsimme 23 henkilöä. Meille lähetettiin kyselylomakkeita paitsi Minskistä myös Moskovasta, Pietarista ja jopa Tatarstanista. Jotkut kaverit yllättivät meidät nykyisellä ammatilla: yksi heistä on oikeuslääketieteen asiantuntija ja toinen lääketieteen opiskelija.

Tuloksena oli mielenkiintoinen onnistumisprosenttijakauma tehtävien suorittamisessa. Ensimmäisen tehtävän suoritettiin keskimäärin 60 %, toisen 50 % ja kolmas osoittautui vaikeimmaksi ja suoritettiin keskimäärin 40 %.

Ensi silmäyksellä tehtävät näyttävät monimutkaisilta ja aikaa vieviltä. Syynä ei ole se, että haluamme karsia pois mahdollisimman monta ehdokasta. Opiskelijoiden edessä on opintojensa aikana tosielämän tehtäviä - chatin tekeminen, Yandex.Music lapsille tai Yandex.Weather sääriippuvaisille. Tätä varten tarvitset aloitusalustan.

Muistan nähneeni SRI-pääsytehtäväni kaksi vuotta sitten ja ajattelin, että en koskaan ratkaisisi sitä. Tärkeintä tällä hetkellä on istua alas, lukea ehdot huolellisesti ja aloittaa se. Osoittautuu, että olosuhteet sisältävät lähes 80% liuoksesta. Esimerkiksi kolmannen tehtävän (vaikeimman) tilassa lisäsimme linkkejä palvelutyöntekijöihin ja Notifications API:iin MDN:ssä. Linkkien sisältöä tutkineet opiskelijat suorittivat sen vaikeuksitta.

Haluaisin todella, että tämän artikkelin lukevat hakijat, jotka suunnittelevat siirtymistä SRI:hen tulevaisuudessa, jotka eivät päässeet Minskin kouluun tai jotka ovat aloittamassa jotain muuta testitehtävää. Kuten näet, se on täysin mahdollista tehdä niin. Sinun tarvitsee vain uskoa itseesi ja kuunnella kaikkia kirjoittajien vinkkejä.

Lähde: will.com