Sanotaan, että aika kuluu nopeasti, kun on hauskaa. Minulle henkilökohtaisesti hauskanpito on erityisen tärkeää jokapäiväisessä startup- ja yrityskasvatusajattelussa. Se saa minut nauttimaan itsestäni riippumatta siitä, kuinka paljon sisäisiä energiavarojani syö viikoittainen kiire.
(Seuraavassa jaksossa käsittelen huumoria työpaikoilla hieman tarkemmin, ihan vain siksi, että voin tehdä niin.) "Miksi niin vakavasti?").
Ajasta puheen ollen, 2 viikkoa on kulunut viimeisimmästä julkaisustani, joten on aika julkaista 4. jakso meidän #TheCodestReviewReview sarja.
Luettelo aiheista, joita käsittelemme tällä viikolla:
- Koukkuun jääminen React:hen
- Kaikki mitä olet koskaan halunnut tietää View Caching Railsissä
- Insinööripäällikkö rekrytoinnin mestarina
Näkymän välimuistitallennusta koskeva kommentti, jonka toimitti fullstack-kehittäjämme ja tekniikan päällikön podcast, jota kommentoi nöyrä itseni.
Tunnettuna Paint-sovelluksen mestarina ja GIF:ien ja meemien ihailijana, jotka sanovat enemmän kuin 1000 sanaa, kuten Merci-suklaa, päätin, että tästä lähtien lisään tänne makua niistä. Ja arvaa mitä?
Darth Sidious Luuletko voivasi pysäyttää minut GIF osoitteesta Darthsidious GIFit
Viime kerralla olemme päättäneet laittaa valokeilaan StimulusReflexin, joka on saamassa huomiota Ruby-yhteisössä uutena lapsena lohkolla, joka on vaihtoehto nykyaikaiselle Javascript kehyksiä Rails-projekteissa, jotta vältetään liiallista käyttöä.
Katso: StimulusReflex alias ReactiveRails
Jotta taistelu olisi tasaväkinen, halusin antaa React:n iskeä takaisin Stimulukseen. Koska olen myös tunnettu kunniamies, joka tekee aina, mitä sanoo ja pitää lupauksensa, tässä se tulee:
Seuraavassa jaksossa minulla on ilo ja ilo ilmoittaa, että meillä on vieraana React-insinööri Vinted.comista. Niille teistä, jotka eivät ole koskaan kuulleet Vintedistä (pieni todennäköisyys, mutta silti mahdollista), Vinted on Liettuan Vilnasta peräisin oleva muotimarkkinapaikka, joka on saavuttanut yksisarvisen arvostuksen vuonna 2019. Alusta on rakennettu vankalle Ruby on Rails-perustalle, jota tukee React frontend-osassa.
Sivuhuomautus: vaimoni on aivan rakastava Vinted ja hän melkein kokonaan lopettanut käyttämällä OLX hänen ensisijainen määränpää siivoaminen meidän vaatekaappi ja myydä käytettyjä vaatteita (oli todellinen die hard fani) = TE TEETTE SEN OIKEIN!
Minulla on kunnia toivottaa tervetulleeksi ensimmäinen vieraileva kirjoittaja sarjaamme:
Meryl Streep Kyllä GIF osoitteesta Merylstreep GIFs
Ugnė Kryževičiūtė - React-insinööri Vintediltä
Kun luin hiljattain julkaistun LadyBug-podcastin otsikon ("Getting Hooked On React"), odotin sen käsittelevän lähinnä React-koukkuja. Vaikka podcastissa ei syvennytty koukkuihin, se tarjosi kuitenkin erinomaisen johdannon React-kirjaston perusasioihin JavaScript:lle.
LadyBug-podcastin Ali ja Emma keskustelevat React:n yksityiskohdista - kirjaston yleisestä ulkoasusta ja sen eduista aina vilkkaisiin keskusteluihin komponenteista, tietojenkäsittelystä tai React:n elinkaaresta, ja kaikki nämä keskustelut on esitetty ripauksella henkilökohtaista kokemusta. Se on kuuntelemisen arvoinen kaikille front-end-kehittäjille, jotka eivät ole vielä päässeet kokeilemaan React:n ihmeitä.
Ensimmäisen kerran kohtasin React:n noin kolme vuotta sitten, kun aloitin matkani kehittäjänä. Vaikka Ali ja Emma viittaavat siihen, että React saattaa vaikuttaa aluksi hämmentävältä, oman kokemukseni perusteella pidin sitä suhteellisen helppona aloittaa ja luultavasti helpoimpana edetä muihin front-end-kehyksiin verrattuna. Tutoriaaleja, artikkeleita, avoimen lähdekoodin kirjastoja ja muunlaista oppimateriaalia on saatavilla kaikkialla. Tällaisia resursseja selatessa on kuitenkin syytä olla tietoinen React:n aktiivisesta kehityksestä. Tämä LadyBugin podcastin jakso ei ole poikkeus - jotkin mainituista näkökohdista ja menetelmistä on poistettu käytöstä jo jonkin aikaa. Näin ollen on parasta noudattaa Emman itsensä antamia neuvoja ja tutustua uusimpaan dokumentaatioon.
React on kehittynyt ja kypsynyt paljon, mikä on tehnyt koodi kirjoittaminen on vielä helpompaa Hooksin avulla, jonka avulla voit käyttää tila- ja elinkaarimenetelmiä kirjoittamatta luokkakomponentteja. Mutta aloittelijoille - kuten Ali osuvasti huomauttaa - React:n kirjoitustapojen moninaisuus (kuten luokka/toiminnalliset/koukut-komponentit) lisää monimutkaisuutta, sillä joskus voi olla vaikea hahmottaa, mistä on kyse. Lisäksi voi olla haastavaa, että täytyy tislata se, mitä tarvitsee, ja löytää asiaankuuluvaa tietoa koodin toteutuksesta.
Yhtenä React:n tärkeimmistä eduista Ali mainitsee sen komponenttipohjaisuuden, joka mahdollistaa koodin modulaarisuuden ja helpottaa yhteistyötä muiden kehittäjien kanssa. Lisäksi JSX:n käyttömahdollisuus on erinomainen visuaalinen apuväline, kun JavaScript-koodissa työskennellään käyttöliittymän kanssa - erillisiä HTML-tiedostoja ei tarvita!
Ali ja Emma kiteyttävät myös hienosti sen joustavuuden, jonka komponenttijärjestelmä antaa. Erinomainen käytännön esimerkki on yritykseni Vinted, joka on kokenut nopeaa kasvua koskien tuote sekä kehitystiimit työskennellyt sen parissa viime vuosina. React:stä on ollut valtavasti hyötyä - sen avulla olemme voineet kirjoittaa paljon siistimpää koodia, käyttää uudelleenkäytettäviä käyttöliittymäkomponentteja ja tehdä koodistamme helpommin testattavaa.
Kaiken kaikkiaan tämä LadyBug-podcast-jakso tarjoaa vilkkaan ja viehättävän keskustelun React:n tärkeimmistä näkökohdista. Suosittelen sitä kaikille, jotka aloittavat matkansa React:n kanssa. Jakso on täynnä hauskoja esimerkkejä ja analogioita tosielämään, ja se "koukuttaa" saumattomasti jokaisen kuulijan huomion, myös minun.
Railsin näkymät valitettavasti hidastuvat ajan myötä. Tämä johtuu siitä, että tietokantaan tallennettujen objektien määrä kasvaa. Tämä aiheuttaa pidempiä kyselyaikoja ja tietysti pidempää käsittelyä, jos teet jotain jokaisella objektilla. Kun näin tapahtuu, et jää ilman mitään mahdollisuuksia, sillä on olemassa Rails-näkymien välimuistitallennus.
Tämän ansiosta voit säästää paljon aikaa lataamalla tietokantapainotteisia tietoja välimuistista (lataamalla yhden tallennetun html-muotoisen tiedoston sen sijaan, että kysyisit tietokannasta ja käsittelisit objekteja). Voit myös vähentää kustannuksia, kun kyseessä ovat erilaiset osat ja objektit - tietenkin jos objektit eivät muutu liian usein. Voit myös yrittää pitää välimuistiin tallennetut objektit erillisissä osissa - ja säästää esim. 19:n 20:stä renderöitävän viestin (jossa on mahdollisesti paljon kenttiä).
Oletusarvoisesti Railsin välimuistitallennus käyttää file_storea ja pitää välimuistitiedot kansioissa. Se ei kuitenkaan poista vanhoja välimuistimerkintöjä (jotka ovat saattaneet vanhentua jo kauan sitten). Tämä voi johtaa tiedostojen määrän ylivuotoon tai jopa vapaan tilan loppumiseen palvelimelta. Toinen menetelmä on memory_store, jolla on myös joitakin haittoja (koska välimuisti säilytetään yhdellä palvelimella). Se voi myös ylittää palvelimella säilytettävän RAM-muistin määrän (tai välimuistin puutteen, jos sitä poistetaan koko ajan). Siksi paras suuren mittakaavan välimuistimekanismi on Memcached/Redis -menetelmä. Tämä antaa sinulle mahdollisuuden käyttää erillistä konetta, joka pitää välimuistia, jota kaikki palvelimet voivat käyttää. Tämän ansiosta palvelimella ei ole ongelmaa välimuistin puutteesta tai levytilan viimeistelystä.
Railsin välimuisti säilytetään tunnisteen perusteella, joka voidaan antaa suoraan merkkijonona tai luoda automaattisesti, kun välität objektin välimuistifunktiolle. Objektien tapauksessa se on useimmiten updated_at-attribuutti. Voit myös antaa staattisen avaimen objektin parametreista.
Erilainen välimuistitallennusmenetelmä on Javascriptin käyttäminen kentän päivittämiseen, joka muuttuu kerran päivässä. Tällä tavoin saat näkyviin koko ajan voimassa olevan päivämäärän ilman verkkosivuston päivittämistä - joka saattaa olla melko suuri tai hidas.
Paneelikeskustelu, jossa käsitellään teknisen johtajan roolia palkkauksessa, on erittäin arvokas kaikille niille, jotka miettivät, milloin on oikea aika teknisen johtajan astua haastatteluprosessiin. Osoitteessa Codest, me tavallaan harjoitamme sitä, mitä panelistit saarnaavat ja meidän - CTO on ensimmäinen yhteyspiste meille hakevien insinöörien kanssa, kun taas seuraavassa vaiheessa haastattelut tekee joukkue johtajat, joiden kanssa mahdolliset uudet työntekijät tekevät tiivistä yhteistyötä. Muutamia toimivia neuvoja, joita voit soveltaa heti ja parantaa palkkauspeliäsi insinöörijohtajana:
-
Tarkista prosessisi ja varmista, että pääset mukaan virtaan mahdollisimman varhaisessa vaiheessa, mieluiten ehdokkaiden ensimmäisenä kosketuspisteenä, sillä ensivaikutelma on avainasemassa siinä, miten huippuosaajat näkevät yrityksesi.
-
Ota yhteyttä organisaatiosi erittäin tehokkaisiin rekrytointipäälliköihin (ehkä siihen, joka palkkasi sinut aikoinaan) ja kysy, voisitko seurata joitakin heidän suunniteltuja haastattelujaan, tarkistaa heidän tekniikkansa ja kysyä vinkkejä. Katso ja opi. Lähde jokaiseen haastatteluun aidosti uteliaana ehdokkaita kohtaan.
-
Etsikää potentiaalia ja palkatkaa potentiaalin ja nopean kasvukyvyn perusteella.
-
Käy työpaikkailmoitukset läpi kaikkien insinöörien kanssa ja kysy, haluaisivatko he hakea työpaikkaa. Jos eivät, kysy, mikä on huono juttu, ja ota heidän palautteensa huomioon 2.0-rakentamisen työpaikkailmoituksessa, jota aiot työntää työpaikkatauluihin.
-
Pidä ensimmäistä haastattelua tilaisuutena luoda hyvä suhde mahdollisiin tuleviin kollegoihisi.
Kannustan sinua katsomaan koko videopaneelin, mutta jos pidät podcasteista ja haluat kuunnella ajon aikana, treenatessasi tai tiskatessasi, tässä on myös Spotify. linkki.
Kiitos paljon lukemisesta ja jos olet tullut niin pitkälle, arvostan aikaasi ja kaikki palaute (oli se sitten siistiä tai haukkua minua) on enemmän kuin tervetullutta. LinkedIn tai minun sähköpostiosoite.
Seuraava jakso tulee pian (suurin piirtein)!
Yippie Nähdään pian tanssimassa GIF-tiedosto osoitteesta Yippieiwillseeyeyousoon GIFit
Lue lisää:
TheCodestReview #3 - viikoittainen ohjelmistotekniikan mehu
TheCodestReview #2 - viikoittainen ohjelmistotekniikan mehu
TheCodestReview #1 - viikoittainen ohjelmistotekniikan mehu