GÅ TILBAGE
Man siger, at tiden flyver hurtigt, når man har det sjovt. For mig personligt er den sjove del særlig vigtig i den daglige opstart og vækst af virksomheder. Det får mig til at hygge mig, uanset hvor meget af mine indre energiressourcer, der bliver ædt op af den ugentlige travlhed.
(I næste episode vil jeg følge op på emnet humor på arbejdspladsen for at uddybe det lidt mere, bare fordi jeg kan. "Hvorfor så alvorlig?").
Apropos tid, så er der gået 2 uger fra min sidste udgivelse, og derfor er det ved at være tid til 4. afsnit af vores #TKodestAnmeldelse serie.
Kommentaren om view caching blev leveret af vores fullstack-udvikler, og teknikchefens podcast blev kommenteret af min ydmyge person.
Som en populært kendt Paint-app-mester og beundrer af GIF'er og memes, der ligesom Merci-chokolader siger mere end 1000 ord, besluttede jeg, at jeg fra nu af ville tilføje en smagsprøve af dem her. Og ved du hvad?
Darth Sidious Du tror, du kan stoppe mig GIF fra Darthsidious GIF'er
Sidste gang besluttede vi at sætte fokus på StimulusReflex, der får opmærksomhed i Ruby-samfundet som en ny dreng i klassen, der er et alternativ til at bruge moderne Javascript frameworks i Rails-projekter for at undgå overkill.
Se her: StimulusReflex aka ReactiveRails
For at gøre det til en kamp på lige vilkår, ville jeg lade React slå tilbage på Stimulus. Da jeg også er en velkendt hædersmand, der altid gør, hvad jeg siger, og holder, hvad jeg lover, kommer det her:
I den næste episode er det mig en fornøjelse at kunne annoncere, at vi får et gæsteindlæg af React-ingeniøren fra Vinted.com. For dem af jer, der aldrig har hørt om Vinted (lave odds, men stadig muligt), er Vinted en markedsplads for mode fra Vilnius i Litauen, der nåede en værdiansættelse som enhjørning tilbage i 2019. Platformen er bygget på et solidt Ruby on Rails-fundament, der bakkes op af React på frontend-delen.
Sidebemærkning: Min kone er helt vild med Vinted, og hun er næsten helt holdt op med at bruge OLX som sin primære destination til at rydde op i vores garderobe og sælge brugt tøj (var en ægte die hard fan) =. I GØR DET RIGTIGT!
Det er mig en ære at byde velkommen til den første gæstebidragyder i vores serie:
Meryl Streep Ja GIF fra Merylstreep GIF'er
Ugnė Kryževičiūtė - React ingeniør fra Vinted
Da jeg læste titlen på den seneste LadyBug-podcast ("Getting Hooked On React"), forventede jeg, at den mest ville handle om React Hooks. Men selv om den ikke dykkede dybt ned i Hooks, gav podcasten en fremragende introduktion til det grundlæggende i React-biblioteket til JavaScript.
Ali og Emma fra LadyBug-podcasten diskuterer React's ins og outs - fra bibliotekets generelle layout og dets fordele til livlige diskussioner om komponenter, datahåndtering eller React's livscyklus, alt sammen præsenteret med en knivspids af personlig erfaring. Det er værd at lytte til for enhver frontend-udvikler, der ikke har haft mulighed for at afprøve React's vidundere.
Mit første møde med React var for omkring tre år siden, da jeg begyndte min rejse som udvikler. Selvom Ali og Emma siger, at React kan virke forvirrende i starten, er det min egen erfaring, at det er relativt nemt at komme i gang med og nok det nemmeste at komme videre med sammenlignet med andre front-end frameworks. Der er masser af vejledninger, artikler, open source-biblioteker og andre former for undervisningsmateriale til rådighed overalt. Man skal dog være opmærksom på den aktive udvikling af React, når man gennemgår sådanne ressourcer. Denne episode af LadyBugs podcast er ikke en undtagelse - nogle af de aspekter og metoder, der nævnes, har allerede været forældet i nogen tid. Derfor er det bedst at følge Emmas egne råd og se på den nyeste dokumentation.
React har udviklet og modnet sig meget, hvilket gør Kode Det er endnu nemmere at skrive med Hooks, som lader dig bruge tilstands- og livscyklusmetoder uden at skrive klassekomponenter. Men for begyndere - som Ali præcist bemærker - tilføjer de mange forskellige måder, man kan skrive React på (f.eks. klasse/funktionelle/Hooks-komponenter), yderligere kompleksitet, da det nogle gange kan være svært at visualisere, hvad der foregår. Det kan også være en udfordring at skulle destillere, hvad man har brug for, og finde relevante oplysninger om kodeimplementering.
Som en af React's største fordele påpeger Ali, at det er komponentbaseret, hvilket muliggør modularisering af koden og gør det lettere at arbejde sammen med andre udviklere. Desuden er muligheden for at bruge JSX et godt visuelt hjælpemiddel, når man arbejder med UI i JavaScript-kode - man behøver ikke at have separate HTML-filer!
Ali og Emma opsummerer også fint den fleksibilitet, det giver at have et komponentsystem. Et glimrende eksempel fra praksis er min virksomhed Vinted, som har oplevet hurtig vækst med hensyn til produkt såvel som udviklingsteams arbejdet på det i de sidste mange år. React har givet enorme fordele - det har gjort det muligt for os at skrive meget renere kode, bruge genanvendelige UI-komponenter og har gjort vores kode lettere at teste.
Alt i alt giver denne LadyBug-podcast-episode en livlig og charmerende diskussion om React's vigtigste aspekter. Jeg anbefaler den til alle, der begynder deres rejse med React. Episoden er fuld af sjove eksempler og analogier til det virkelige liv og "fanger" problemfrit enhver lytters opmærksomhed, også min.
Visningerne i Rails bliver desværre langsommere med tiden. Det skyldes, at mængden af objekter i databasen vokser. Det medfører længere forespørgselstider og selvfølgelig længere behandling, hvis du skal gøre noget med hvert enkelt objekt. Når det sker, er du ikke uden chance, for der findes caching af Rails-visninger.
Takket være dette kan du spare en hel del tid ved at indlæse databasetunge data fra cachen (indlæse en enkelt gemt html-lignende fil i stedet for at forespørge i databasen og behandle objekter). Du kan også gøre det billigere i tilfælde af forskellige partialer og objekter - selvfølgelig hvis objekterne ikke ændres for ofte. Du kan også prøve at holde de cachelagrede objekter i en separat partials - og spare f.eks. 19 ud af 20 indlæg, der gengives (muligvis med mange felter).
Som standard bruger Rails caching file_store og opbevarer de cachelagrede data i mapperne. Men den sletter ikke gamle cache-poster (som måske er udløbet for længe siden). Det kan føre til, at filmængden bliver for stor, eller at man endda løber tør for ledig plads på en server. Den anden metode er memory_store, som også har nogle ulemper (da cachen opbevares på en enkelt server). Den kan også overskride mængden af RAM på serveren (eller mangle cache, hvis den bliver slettet hele tiden). Derfor er den bedste caching-mekanisme i stor skala Memcached/Redis-metoden. Det giver dig mulighed for at bruge en separat maskine til at opbevare cachen, som kan bruges af alle serverne. Takket være det vil der ikke være noget problem med mangel på cache eller færdig diskplads på en server.
Cachen i Rails holdes baseret på en identifikator - som kan gives direkte som en streng eller genereres automatisk, når du sender et objekt til cache-funktionen. I tilfælde af objekter er det oftest attributten updated_at. Du kan også angive en statisk nøgle fra objektparametre.
En anden metode til caching er at bruge Javascript til at opdatere et felt, der ændres en gang om dagen. På den måde kan du få vist en gyldig dato hele tiden uden at opdatere webstedet - som kan være ret stort eller langsomt at køre.
Jeg vil ikke afsløre for meget, men paneldiskussionen om ingeniørchefens rolle i ansættelsesprocessen er meget værdifuld for alle jer, der spekulerer på, hvornår det er det rigtige tidspunkt for teknologilederen at træde ind i interviewcyklussen. På CodestVi praktiserer, hvad paneldeltagerne prædiker, og vores CTO er det første kontaktpunkt for ingeniører, der ansøger hos os, mens samtalerne i næste fase varetages af hold ledere, som de potentielle nye medarbejdere kommer til at arbejde tæt sammen med. Et par konkrete råd, som du kan bruge med det samme til at opgradere dine ansættelsesmuligheder som teknisk leder:
Gennemgå din proces, og sørg for, at du kommer med i flowet så tidligt som muligt, ideelt set som det første kontaktpunkt for kandidaterne, da førstehåndsindtrykket spiller en vigtig rolle for, hvordan din virksomhed opfattes af de bedste talenter.
Tag kontakt til meget effektive ansættelseschefer i din organisation (måske den, der ansatte dig i sin tid), og spørg, om du må følge nogle af deres planlagte samtaler, tjekke deres teknikker og spørge om tips. Se og lær. Gå ind til hver samtale med en oprigtig nysgerrighed på kandidaterne.
Se efter potentiale, og ansæt efter potentiale og evne til at vokse hurtigt.
Tal dine jobannoncer igennem med alle dine ingeniører, og spørg, om de vil søge jobbet. Hvis ikke, så spørg, hvad der er dårligt, og brug deres feedback i den 2.0 build-jobannonce, du er ved at sende ud på jobsites.
Se den første samtale som en mulighed for at skabe et godt forhold til dine potentielle fremtidige kolleger.
Jeg opfordrer dig til at se hele videopanelet, men hvis du er til podcasts og kan lide at lytte, mens du kører bil, træner eller vasker op, har du også en Spotify her Link.
Mange tak, fordi du læste med, og hvis du er kommet så langt, sætter jeg pris på din tid, og al feedback (uanset om den er cool eller nedgør mig) er mere end velkommen på LinkedIn eller til min e-mail.
Vi vender snart tilbage med den næste episode(ish)!
Yippie Vi ses snart Dansende GIF fra Yippieiwillseeyousoon GIF'er
Læs mere om det:
TheCodestReview #3 - ugentlig software engineering juice
Danish 
English 
German 
Swedish 
Norwegian 
Finnish 
French 
Polish 
Arabic 
Italian 
Japanese 
Korean 
Spanish 
Dutch 
Estonian 
Greek