Hej och tack för att du kom hit för att kontrollera det tredje avsnittet i vår TheCodestReview-serie. Det betyder mycket för oss och hoppas att det kommer att vara en väl spenderad tid.
Eftersom vi lever och andas Ruby on RailsDenna vecka har vi beslutat att sätta lite fokus på StimulusReflex som får uppmärksamhet i samhället som ett nytt barn på blocket, vilket är ett alternativ till att använda moderna Javascript ramverk i Rails-projekt för att undvika överdrifter. Dessutom tar vi en sväng om när Scrum inte fungerar och integritetsutveckling i fintech projekt baserade på Plaid (https://plaid.com/eu/)
Ordlista över aspekter som vi tar itu med:
- React är död. Länge leve StimulusReflex!
- När Scrum inte fungerar?
3 Privacy engineering i fintech-produkter baserade på Plaid
StimulusReflex- och Scrum-kommentarerna den här veckan levereras av vår Ruby-ingenjör och Projekt Chef.
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.
(HUMOR ALERT)
Kontroversiell titel, eller hur? Jag måste erkänna att det var lika chockerande för mig, så jag var ivrig att läsa och kontrollera vad som finns bakom sloganen eller om det bara är ännu ett klickbete. Jag var skeptisk men också full av hopp för att vara rättvis. Missförstå mig inte nu. Jag har inga problem med React och Javascript i allmänhet men när jag läste "Reactive Rails" blev min fantasi galen. Nog om mina känslor, låt mig sammanfatta vad som är saftigt i den här artikeln.
Den här humoristiska artikeln såg kaotisk ut vid första anblicken, men jag gav den ett försök eftersom jag gillar den här typen av humor och de första styckena gav mig hopp och ännu mer energi.
Obie Fernandez förklarar vad som ligger bakom namnet "Reactive Rails". För att ge dig en snabb överblick är det mestadels att arbeta med StimulusReflex och ViewComponent. Dessa två kraftfulla verktyg övertygade utvecklaren om att React inte längre behövdes. Han skrev till och med där att "det finns absolut inget tekniskt behov för Rails-utvecklare att använda React längre". Trubbigt, eller hur?
Naturligtvis lämnar författaren oss inte med denna slogan. För att bevisa sina ord (om någon inte tror på dem) sammanfattar han Reactive Rails tillvägagångssätt i punktform. Han guidar oss också genom sitt äventyr med att skriva om vissa delar av sitt sidoprojekt som använde Vanilla Rails och lite jQuery kod att följa Reactive Rails-metoden. Han upptäckte att installationen var relativt smärtfri och att det gick väldigt snabbt att bli produktiv efter att inte ha lagt så mycket tid på att lära sig nya verktyg. Allt följs naturligtvis av kodexempel så att vi får en bättre bild av vad som hände under denna process.
För att inte få dig uttråkad övertygar jag verkligen er alla att läsa den här artikeln. För att vara ärlig är jag verkligen upphetsad och hypad efter att ha läst den. Sättet Obie Fernandez introducerade Reactive Rails slog mig mycket och gav mig hopp om att något stort händer i Ruby-communityn. Han köpte mig med den här artikeln, jag kommer säkert att utforska detta nya tillvägagångssätt.
Codest-rekommendation - StimulusReflex kan vara värt ett försök om du är ett nystartat företag som har en Ruby Team och brist på frontend-kapacitet. Om användargränssnittet för din plattform vänder sig till B2C-användare och du behöver göra det snyggt och glänsande redan från början, kan du överväga att ge StimulusReflex en chans över jQuery klassisk kod. Om du vill lägga till en känsla av en modern applikation till det befintliga Rails-projektet som saknar modern JS, bör du hitta StimulusReflex ett solidt och tidseffektivt alternativ (tar din Rails-version är uppdaterad). Att implementera det i ditt befintliga projekt bör vara relativt smärtfritt.
Felaktiga tolkningar från organisationens sida
Feltolkningar av utvecklingsteamet
Även om reglerna verkar vara mycket enkla är det en svår nöt att knäcka när de ska tillämpas. Det kräver arbete och engagemang från alla teammedlemmar. Du har inte råd att ha någon som bara gör ingenting. När Scrum-uttalandena överensstämmer med dina medarbetares övertygelser blir hela processen lätt som en plätt. Medarbetarna tar gärna på sig mer ansvar och deras samarbete blir mycket effektivt. Men om deras tankesättet har inget gemensamt med Scrum-metoden kommer det att bli en ansträngande uppgift och det mesta av arbetsbördan kommer att ligga på Scrum Master:s axlar. Trots alla hinder kan du fortfarande lyckas om teamet är tillräckligt engagerat. Specifikationerna för Produkt typ kan också vara en faktor som gör att Scrum stjälper snarare än hjälper. Det handlar främst om projekt som rör konkreta produkter, till exempel hårdvara. Det finns vissa projekt som kräver ett annat angreppssätt än Agility. Anledningen kan vara de människor som ingår i ett projekt. Scrum kräver produktägarens och Scrum Master:s närvaro.
Du kan också läsa: Varför vinner Agile?
Men..: En mördare av Scrum av Dirk Bolte
Tankar om privacy engineering och att se till att säkerheten är inbyggd redan från början i en produkt.
Hur pandemin har påskyndat människors digitala upplevelser.
Hur du kan anpassa dig när ingenjörsteamet växer bortom den punkt där du kan känna alla individuellt.
Bland ett par intressanta ämnen berör Jean integritet och integritetsteknik baserat på sina erfarenheter som ett fintech-företag. Frågor om härledda data, god praxis för radering av data, anonymisering av data och återförsäljning till tredje part på annonsteknik karusell. Vilket ansvar har företag gentemot sina användare när det gäller integriteten för deras uppgifter? Vilka är de bästa dataskyddsrutinerna för fintech-företag? Jean understryker också vikten av att den privata sektorn samarbetar med regeringar och tillsynsmyndigheter i processen för att skapa en välbalanserad PPP för att följa GDPR och samtidigt inte döda innovationerna.
Sammanfattning
Tack för att du läste och vi återkommer med nästa avsnitt inom kort!
Läs mer om detta:
TheCodestReview #2 - veckovis juice för mjukvaruutveckling
TheCodestReview #1 - veckovis juice för mjukvaruutveckling
Hur kan man förbättra Vue.js-appar? Några praktiska tips