TheCodestReview #4 - veckovis juice för mjukvaruutveckling

(I nästa avsnitt kommer jag att följa upp ämnet humor på arbetsplatsen för att utveckla det lite mer, bara för att jag kan. "Varför är du så allvarlig?").

På tal om tid, 2 veckor har gått sedan min senaste publicering och därför är det dags för det 4:e avsnittet av vår #TheCodestReview serie.

Lista över ämnen som vi tar upp den här veckan:

1. Att bli beroende av React
2. Allt du någonsin velat veta om View Caching i Rails
3. Den tekniska chefen som huvudrekryterare

Kommentaren om cachning av vyer levererades av vår fullstack-utvecklare och teknikchefens podcast kommenterades av min ödmjuka jag.

Som en allmänt känd Paint-app-mästare och beundrare av GIF:ar och memes, som är som Merci-choklad - som säger mer än 1000 ord, bestämde jag mig för att från och med nu lägga till en smak av det här. Och gissa vad?

Darth Sidious Du tror att du kan stoppa mig GIF från Darthsidious GIFs

Förra gången bestämde vi oss för att sätta lite strålkastarljus på StimulusReflex som får uppmärksamhet i Ruby-communityn som ett nytt barn på blocket, som ett alternativ till att använda moderna Javascript ramverk i Rails-projekt för att undvika överdrifter.

Se: StimulusReflex aka ReactiveRails

För att göra det till en kamp på lika villkor ville jag låta React ta en sväng tillbaka på Stimulus. Eftersom jag också är en välkänd hedersman, som alltid gör vad jag säger och håller vad jag lovar, så här kommer det:

I nästa avsnitt är det mitt nöje och jag är glad att kunna meddela att vi kommer att ha ett gästinlägg av React ingenjör från Vinted.com. För de av er som aldrig har hört talas om Vinted (låga odds, men fortfarande möjligt), Vinted är en modemarknadsplats med ursprung i Vilnius, Litauen som nådde en enhörningsvärdering redan 2019. Plattformen är byggd på en solid Ruby on Rails-grund som backas upp av React på frontend-delen.

Sidnot: min fru älskar absolut Vinted och hon slutade nästan helt att använda OLX som sin primära destination för att rensa vår garderob och sälja begagnade kläder (var ett riktigt die hard fan) = ... NI GÖR DET RÄTT!

Det är mitt privilegium att välkomna en första gästbidragare i vår serie:

Meryl Streep Ja GIF från Merylstreep GIF:ar

Ugnė Kryževičiūtė - React ingenjör från Vinted

Att bli beroende av React av LadyBug Podcast

När jag läste titeln på den senaste LadyBug-podcasten ("Getting Hooked On React") förväntade jag mig att den mest skulle handla om React Hooks. Men även om den inte djupdykte i Hooks, gav podcasten en utmärkt introduktion till grunderna i React-biblioteket för JavaScript.

Ali och Emma från LadyBug-podden diskuterar React:s fördelar och nackdelar - från bibliotekets allmänna layout och dess fördelar till livliga diskussioner om komponenter, datahantering eller React:s livscykel, allt presenterat med en nypa personlig erfarenhet. Det är värt att lyssna på för alla frontend-utvecklare som inte har haft chansen att prova React:s underverk.

Mitt första möte med React var för cirka tre år sedan när jag började min resa som utvecklare. Även om Ali och Emma föreslår att React kan verka förvirrande i början, tyckte jag av egen erfarenhet att det var relativt enkelt att börja med och förmodligen det enklaste att gå vidare i jämförelse med andra front-end-ramverk. Det finns gott om tutorials, artiklar, open source-bibliotek och andra typer av läromedel tillgängliga överallt. Man bör dock vara medveten om den aktiva utvecklingen av React när man går igenom sådana resurser. Detta avsnitt av LadyBugs podcast är inte ett undantag - vissa aspekter och metoder som nämns har redan föråldrats under en tid. Därför är det bäst att följa råd från Emma själv och titta på den senaste dokumentationen.

React har utvecklats och mognat mycket, vilket gör kod att skriva ännu enklare med Hooks, som låter dig använda tillstånds- och livscykelmetoder utan att skriva klasskomponenter. Men för nybörjare - som Ali mycket riktigt påpekar - innebär de många olika sätten att skriva React (t.ex. klass-/funktions-/Hooks-komponenter) ytterligare komplexitet, eftersom det ibland kan vara svårt att visualisera vad som händer. Det kan också vara svårt att destillera vad man behöver och hitta relevant information om kodimplementering.

Som en av React:s främsta fördelar pekar Ali på att det är komponentbaserat, vilket möjliggör kodmodularisering och gör det lättare att arbeta tillsammans med andra utvecklare. Dessutom är möjligheten att använda JSX ett bra visuellt hjälpmedel när man arbetar med UI i JavaScript-kod - du behöver inte ha separata HTML-filer!

Ali och Emma sammanfattar också på ett bra sätt den flexibilitet som det ger att ha ett komponentsystem. Ett utmärkt exempel från praktiken är mitt företag Vinted, som har haft en snabb tillväxt under de senaste åren. Produkt såväl som utvecklingsteam arbetat med det under de senaste åren. React har gett oss enorma fördelar - det har gjort det möjligt för oss att skriva mycket renare kod, använda återanvändbara UI-komponenter och gjort vår kod enklare att testa.

Sammantaget ger detta LadyBug-podcastavsnitt en livlig och charmig diskussion om React:s viktigaste aspekter. Jag rekommenderar det till alla som börjar sin resa med React. Avsnittet är fullt av roliga exempel och analogier till det verkliga livet och "fångar" sömlöst varje lyssnares uppmärksamhet, inklusive min.

Cachelagring av Rails-vyer av Jonathan Miles från Honeybadger

Vyerna i Rails blir tyvärr långsammare med tiden. Det beror på att mängden objekt som lagras i databasen växer. Detta orsakar längre frågetider och naturligtvis längre bearbetning om du gör något med vart och ett av objekten. När det händer lämnas du inte utan någon chans eftersom det finns Rails vyer caching.

Tack vare detta kan du spara en hel del tid genom att ladda databastunga data från cacheminnet (ladda en enda sparad html-liknande fil istället för att fråga databasen och bearbeta objekt). Du kan också göra det billigare när det gäller olika partialer och objekt - naturligtvis om objekten inte ändras alltför ofta. Du kan också försöka hålla de cachade objekten i en separat partials - och spara t.ex. 19 av 20 inlägg som renderas (eventuellt med många fält).

Som standard använder Rails cachelagring file_store och håller cachade data i mapparna. Men den raderar inte gamla cacheposter (som kan ha löpt ut för länge sedan). Detta kan leda till att filmängden överflödar eller till och med att det blir slut på ledigt utrymme på en server. Den andra metoden är memory_store som också har vissa nackdelar (eftersom cachen förvaras på en enda server). Det kan också överskrida mängden RAM som finns på servern (eller brist på cache om den kommer att raderas hela tiden). Det är därför den bästa högskaliga cachemekanismen är Memcached/Redis-metoden. Detta ger dig en chans att använda en separat maskin som håller cacheminnet som kan användas av alla servrar. Tack vare det kommer det inte att finnas några problem med brist på cache eller avslutande diskutrymme på en server.

Cachen i Rails hålls baserad på en identifierare - som kan ges direkt som en sträng eller genereras automatiskt när du skickar ett objekt till cache-funktionen. När det gäller objekt är det oftast attributet updated_at. Du kan också tillhandahålla en statisk nyckel från objektparametrar.

En annan metod för cachelagring är att använda Javascript för att uppdatera ett fält som ändras en gång om dagen. På så sätt kan du ha ett giltigt datum som visas hela tiden, utan att uppdatera webbplatsen - som kan vara ganska stor eller långsam att köra.

Teknisk chef som huvudrekryterare av Mentoring Club

Jag vill inte skämma bort er för mycket, men paneldiskussionen om teknikchefens roll i rekryteringsprocessen är mycket värdefull för alla er som undrar när det är rätt tid för teknikchefen att kliva in i intervjun. På KodestVi praktiserar det som paneldeltagarna predikar och våra CTO är den första kontaktpunkten för ingenjörer som ansöker till oss, medan intervjuerna i nästa steg görs av Team chefer som de potentiella nya medarbetarna kommer att arbeta nära med. Några konkreta råd som du kan tillämpa direkt för att uppgradera din rekryteringsprocess som teknisk chef:

1. Se över din process och se till att du kommer med i flödet så tidigt som möjligt, helst som den första kontaktpunkten för kandidaterna eftersom första intrycket spelar en viktig roll för hur ditt företag uppfattas av topptalanger.

2. Kontakta mycket effektiva rekryterande chefer i din organisation (kanske den som anställde dig en gång i tiden) och fråga om du får följa med på några av deras planerade intervjuer, se hur de arbetar och be om tips. Titta och lär. Gå in i varje intervju med en genuin nyfikenhet på kandidaterna.

3. Leta efter potential och anställ för potential och förmåga att växa snabbt.

4. Prata igenom dina jobbannonser med alla dina ingenjörer och fråga om de skulle ansöka om jobbet. Om inte, fråga vad som suger och använd deras feedback i den 2.0-byggda jobbannonsen som du är på väg att trycka ut på jobbsajter. 

5. Se den första intervjun som en möjlighet att skapa en bra relation med dina potentiella framtida kollegor.

Jag uppmuntrar dig att titta på hela videopanelen, men om du gillar podcasts och gillar att lyssna medan du kör bil, tränar eller diskar, här har du också en Spotify länk. 

Tack så mycket för att du läste och om du har kommit så långt uppskattar jag din tid och all feedback (oavsett om det är coolt eller trashar mig) är mer än välkommen på LinkedIn eller till min e-post. 

Vi återkommer med nästa avsnitt inom kort(ish)! 

Yippie Vi ses snart Dansande GIF från Yippieiwillseeyousoon GIF:s

Läs mer om detta:

TheCodestReview #3 - veckovis juice för mjukvaruutveckling

TheCodestReview #2 - veckovis juice för mjukvaruutveckling

TheCodestReview #1 - veckovis juice för mjukvaruutveckling