TheCodestReview #4 - ukentlig juice for programvareutvikling

(I neste episode vil jeg følge opp temaet humor på arbeidsplassen for å utdype det litt mer, bare fordi jeg kan. "Hvorfor så alvorlig?").

Apropos tid, det har gått to uker siden forrige publisering, og det er derfor på tide med den fjerde episoden av vår #TTheCodestReview serie.

Liste over temaer vi dekker denne uken:

1. Å bli hekta på React
2. Alt du noensinne har ønsket å vite om View Caching i Rails
3. Engineering Manager som en mesterlig rekrutterer

Kommentaren om visningsbufring levert av vår fullstack-utvikler og podcasten til teknisk sjef ble kommentert av min ydmyke person.

Som en populært kjent Paint-app-mester og beundrer av GIF-er og memes som er som Merci-sjokolade - som sier mer enn 1000 ord, bestemte jeg meg for at jeg fra nå av vil legge til en smak av det her. Og gjett hva?

Darth Sidious Du tror du kan stoppe meg GIF fra Darthsidious GIF-er

Sist gang har vi bestemt oss for å sette søkelyset på StimulusReflex, som har fått mye oppmerksomhet i Ruby-miljøet som et alternativ til å bruke moderne Javascript rammeverk i Rails-prosjekter for å unngå overkill.

Se her: StimulusReflex aka ReactiveRails

For å gjøre det til en kamp på like vilkår, ville jeg la React slå tilbake mot Stimulus. Siden jeg også er kjent for å være en ærens mann, som alltid gjør det jeg sier og holder det jeg lover, så her kommer det:

I neste episode er det min glede og jeg er spent på å kunngjøre at vi vil ha et gjesteinnlegg av React ingeniør fra Vinted.com. For de av dere som aldri har hørt om Vinted (lave odds, men fortsatt mulig), er Vinted en markedsplass for mote fra Vilnius, Litauen, som nådde en enhjørningsverdi tilbake i 2019. Plattformen er bygget på et solid Ruby on Rails-grunnlag støttet av React på frontend-delen.

Sidebemerkning: min kone elsker absolutt Vinted, og hun sluttet nesten helt å bruke OLX som sin primære destinasjon for å rydde opp i garderoben vår og selge brukte klær (var en ekte die hard fan) = ... DERE GJØR DET RIKTIG!

Jeg har gleden av å ønske en første gjestebidragsyter velkommen i serien vår:

Meryl Streep Ja GIF fra Merylstreep GIF-er

Ugnė Kryževičiūtė - React ingeniør fra Vinted

Å bli hekta på React av LadyBug Podcast

Da jeg leste tittelen på den siste LadyBug-podcasten ("Getting Hooked On React"), forventet jeg at den skulle handle mest om React Hooks. Men selv om den ikke gikk dypt inn i Hooks, ga podcasten en utmerket introduksjon til det grunnleggende i React-biblioteket for JavaScript.

Ali og Emma fra LadyBug-podcasten diskuterer Reacts inn- og utsider - fra bibliotekets generelle oppsett og fordeler til livlige diskusjoner om komponenter, datahåndtering eller Reacts livssyklus, alt presentert med en klype personlig erfaring. Det er verdt å lytte til for alle frontend-utviklere som ikke har hatt sjansen til å prøve ut underverkene i React.

Mitt første møte med React var for rundt tre år siden, da jeg begynte min reise som utvikler. Selv om Ali og Emma antyder at React kan virke forvirrende til å begynne med, er min egen erfaring at det er relativt enkelt å komme i gang med, og sannsynligvis det enkleste å komme videre med sammenlignet med andre frontend-rammeverk. Det finnes massevis av veiledninger, artikler, åpen kildekode-biblioteker og andre typer læringsmateriell tilgjengelig overalt. Man bør imidlertid være oppmerksom på den aktive utviklingen av React når man går gjennom slike ressurser. Denne episoden av LadyBugs podcast er ikke et unntak - noen av aspektene og metodene som nevnes, har allerede blitt utdatert for en tid tilbake. Derfor er det best å følge rådet fra Emma selv og se på den nyeste dokumentasjonen.

React har utviklet seg og modnet mye, noe som gjør kode enda enklere med Hooks, som lar deg bruke tilstands- og livssyklusmetoder uten å skrive klassekomponenter. Men for nybegynnere - som Ali så riktig bemerker - gjør de mange ulike måtene du kan skrive React på (for eksempel klasse-/funksjons-/Hooks-komponenter) det ekstra komplisert, ettersom det noen ganger kan være vanskelig å visualisere hva som skjer. Det kan også være utfordrende å destillere det du trenger, og å finne relevant informasjon om kodeimplementering.

En av de største fordelene med React er at det er komponentbasert, noe som muliggjør modularisering av koden og gjør det enklere å jobbe sammen med andre utviklere. Dessuten er muligheten til å bruke JSX et flott visuelt hjelpemiddel når du jobber med brukergrensesnitt i JavaScript-kode - du trenger ikke å ha separate HTML-filer!

Ali og Emma oppsummerer også på en fin måte fleksibiliteten som et komponentsystem gir. Et utmerket eksempel fra praksis er mitt eget selskap Vinted, som har opplevd en rask vekst når det gjelder produkt i tillegg til utviklingsteam Vi har jobbet med det i flere år. React har gitt oss enorme fordeler - det har gjort det mulig for oss å skrive mye renere kode, bruke gjenbrukbare UI-komponenter og gjort det enklere å teste koden vår.

Alt i alt gir denne LadyBug-podcastepisoden en livlig og sjarmerende diskusjon om de viktigste aspektene ved React. Jeg anbefaler den til alle som skal begynne sin reise med React. Episoden er full av morsomme eksempler og analogier til det virkelige liv, og den fanger oppmerksomheten til alle lyttere, inkludert meg.

Caching av Rails-visning av Jonathan Miles fra Honeybadger

Visningene i Rails blir dessverre tregere med tiden. Det skyldes at mengden objekter som lagres i databasen vokser. Dette fører til lengre spørringstider og selvfølgelig lengre behandling hvis du gjør noe med hvert av objektene. Når det skjer, er du ikke sjanseløs, for det finnes caching av Rails-visninger.

Takket være dette kan du spare mye tid ved å laste inn databasetunge data fra hurtigbufferen (ved å laste inn en enkelt lagret html-lignende fil i stedet for å søke i databasen og behandle objekter). Du kan også gjøre det billigere med forskjellige partialer og objekter - selvfølgelig hvis objektene ikke endres for ofte. Du kan også prøve å holde de hurtigbufrede objektene i en separat partials - og spare f.eks. 19 av 20 innlegg som blir gjengitt (muligens med mange felt).

Som standard bruker Rails caching file_store og lagrer hurtigbufrede data i mappene. Men den sletter ikke gamle cache-oppføringer (som kan ha utløpt for lenge siden). Dette kan føre til at filmengden blir for stor eller til og med at det blir tomt for ledig plass på en server. Den andre metoden er memory_store, som også har noen ulemper (ettersom hurtigbufferen oppbevares på én enkelt server). Den kan også overskride mengden RAM som finnes på serveren (eller mangel på cache hvis den slettes hele tiden). Derfor er Memcached/Redis-metoden den beste mekanismen for hurtigbufring i stor skala. Dette gir deg muligheten til å bruke en separat maskin som holder hurtigbufferen som kan brukes av alle serverne. Takket være det vil det ikke være noe problem med mangel på cache eller etterbehandling av diskplass på en server.

Cachen i Rails holdes basert på en identifikator - som kan oppgis direkte som en streng eller genereres automatisk når du sender et objekt til cache-funksjonen. For objekter er det oftest attributtet updated_at. Du kan også oppgi en statisk nøkkel fra objektparametere.

En annen metode for hurtigbufring er å bruke Javascript til å oppdatere et felt som endres én gang om dagen. På denne måten kan du få vist en gyldig dato hele tiden, uten å måtte oppdatere nettstedet - som kan være ganske stort eller tregt å kjøre.

Teknisk sjef som hovedrekrutterer av Mentoring Club

For ikke å skjemme deg bort for mye, men paneldiskusjonen om rollen som teknisk leder i ansettelsesprosessen er svært verdifull for alle dere som lurer på når det er riktig tidspunkt for den tekniske lederen å gå inn i intervjusyklusen. På CodestVi praktiserer det paneldeltakerne prediker, og vår CTO er det første kontaktpunktet med ingeniører som søker seg til oss, mens intervjuene i neste fase gjennomføres av team ledere som de potensielle nye medarbeiderne vil jobbe tett med. Her er noen konkrete råd du kan ta i bruk med en gang for å oppgradere dine rekrutteringsrutiner som teknisk leder:

1. Gå gjennom prosessen og sørg for at du kommer med i flyten så tidlig som mulig, og vær gjerne det første kontaktpunktet for kandidatene, ettersom førsteinntrykket er avgjørende for hvordan selskapet ditt oppfattes av de beste talentene.

2. Ta kontakt med svært effektive rekrutteringsansvarlige i organisasjonen din (kanskje den som ansatte deg i sin tid) og spør om du kan få følge noen av de planlagte intervjuene deres, sjekke teknikkene deres og spørre om tips. Se og lær. Gå inn i hvert intervju med en genuin nysgjerrighet på kandidatene.

3. Se etter potensial, og ansett for potensial og evne til å vokse raskt.

4. Gå gjennom stillingsannonsene med alle ingeniørene dine og spør om de kunne tenke seg å søke på jobben. Hvis ikke, spør hva som er dårlig, og bruk tilbakemeldingene deres i stillingsannonsen for 2.0-byggingen som du er i ferd med å legge ut på jobbtavlene. 

5. Se det første intervjuet som en mulighet til å skape en god relasjon til dine potensielle fremtidige kolleger.

Jeg oppfordrer deg til å se hele videopanelet, men hvis du liker podcaster og liker å lytte mens du kjører bil, trener eller vasker opp, har du også en Spotify her lenke. 

Tusen takk for at du leser, og hvis du har kommet så langt, setter jeg pris på tiden din, og enhver tilbakemelding (enten det er kult eller trashing meg) er mer enn velkommen på LinkedIn eller til min e-post. 

Vi kommer tilbake til deg med neste episode snart! 

Jippie Vi ses snart Dansende GIF fra Yippieiwillseeyousoon GIF-er

Les mer om dette:

TheCodestReview #3 - ukentlig juice for programvareutvikling

TheCodestReview #2 - ukentlig juice for programvareutvikling

TheCodestReview #1 - ukentlig juice for programvareutvikling