GÅ TILBAKE
Hei og takk for at du kom hit for å sjekke den tredje episoden av TheCodestReview-serien vår. Det betyr mye for oss, og vi håper det vil være en vel anvendt tid.
Siden vi lever og ånder Ruby on RailsDenne uken har vi bestemt oss for å sette søkelyset på StimulusReflex, som får oppmerksomhet i samfunnet som et nytt barn på blokken, og som er et alternativ til å bruke moderne Javascript rammeverk i Rails-prosjekter for å unngå overkill. I tillegg tar vi en svingom om når Scrum ikke fungerer, og om personvern i fintech prosjekter basert på Plaid (https://plaid.com/eu/)
3 Personvern i fintech-produkter basert på Plaid
StimulusReflex- og Scrum-kommentarene denne uken er levert til deg av vår Ruby-ingeniør og Prosjekt Leder.
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.
(HUMOR ALERT)
Kontroversiell tittel, ikke sant? Jeg må innrømme at det var like sjokkerende for meg, så jeg var ivrig etter å lese og sjekke hva som ligger bak slagordet, eller om det bare er nok et clickbait. Jeg var skeptisk, men også full av håp for å være rettferdig. Ikke misforstå meg. Jeg har ikke problemer med React og Javascript generelt, men da jeg leste "Reactive Rails" gikk fantasien min amok. Nok om følelsene mine, la meg oppsummere hva som er saftig i denne artikkelen.
Denne humoristiske og hype-artikkelen så kaotisk ut ved første øyekast, men jeg ga den et forsøk, fordi jeg liker denne sansen for humor, og de første avsnittene økte håpet mitt og hypet meg enda mer.
Obie Fernandez forklarer hva som ligger bak navnet "Reactive Rails". For å gi deg en rask oversikt er det for det meste arbeid med StimulusReflex og ViewComponent. Disse to kraftige verktøyene overbeviste utvikleren om at React ikke lenger var nødvendig. Han skrev til og med at "det er absolutt ikke noe teknisk behov for Rails-utviklere å bruke React lenger". Stump, ikke sant?
Selvfølgelig forlater forfatteren oss ikke med dette slagordet. For å bevise sine ord (hvis noen ikke tror på dem) oppsummerer han Reactive Rails' tilnærming i kulepunkter. Han guider oss også gjennom sitt eventyr med å skrive om noen deler av sideprosjektet sitt som brukte Vanilla Rails og litt jQuery kode til å følge Reactive Rails-tilnærmingen. Han fant ut at oppsettet var relativt smertefritt, og at det gikk veldig raskt å bli produktiv etter ikke å ha brukt så mye tid på å lære seg nye verktøy. Alt er selvfølgelig fulgt opp med kodeeksempler, slik at vi får en bedre oversikt over hva som skjedde i løpet av denne prosessen.
For ikke å kjede deg, overbeviser jeg dere alle om å lese denne artikkelen. For å være ærlig er jeg veldig spent og hyped etter å ha lest den. Måten Obie Fernandez introduserte Reactive Rails traff meg mye og ga meg håp om at noe stort skjer i Ruby-samfunnet. Han kjøpte meg med denne artikkelen, jeg vil helt sikkert utforske denne nye tilnærmingen.
Codest-anbefaling - StimulusReflex kan være verdt et forsøk hvis du er en oppstartsbedrift i en tidlig fase og har en Ruby team og mangel på frontend-kapasitet. Hvis brukergrensesnittet på plattformen din er rettet mot B2C-brukere og du trenger å gjøre det fancy og skinnende helt fra starten, kan du vurdere å gi StimulusReflex en sjanse over jQuery klassisk kode. Hvis du vil legge til en følelse av en moderne applikasjon til det eksisterende Rails-prosjektet som mangler moderne JS, bør du finne StimulusReflex et solid og tidseffektivt alternativ (forutsatt at Rails-versjonen din er oppdatert). Det bør være relativt smertefritt å implementere det i ditt eksisterende prosjekt.
Selv om reglene ser ut til å være enkle, er det en vanskelig nøtt å implementere dem. Det krever arbeid og engasjement fra alle teammedlemmene. Du har ikke råd til å ha noen som bare gjør ingenting. Når Scrum-utsagnene stemmer overens med de ansattes holdninger, går hele prosessen som en lek. Folk tar gjerne på seg ekstra ansvar, og samarbeidet blir svært effektivt. Men hvis deres tankesettet har ingenting til felles Med Scrum-tilnærmingen blir det en krevende oppgave, og det meste av arbeidsmengden vil ligge på skuldrene til Scrum Master. Til tross for alle hindringene kan du likevel lykkes hvis teamet er tilstrekkelig engasjert. Spesifikasjonene i produkt type kan også være en faktor som gjør at Scrum stjeler mer tid enn det hjelper. Dette er hovedsakelig prosjekter som gjelder håndfaste produkter, for eksempel maskinvare. Det finnes prosjekter som krever en annen tilnærming enn Agility. Årsaken kan ligge i menneskene som inngår i et prosjekt. Scrum krever tilstedeværelse av produkteier og Scrum Master.
Du kan også lese: Hvorfor vinner Agile?
Men..: En morder av Scrum av Dirk Bolte
Tanker om personvern og om å sørge for at sikkerhet er innebygd fra begynnelsen av et produkt.
Hvordan pandemien har fremskyndet folks digitale opplevelser.
Hvordan du skalerer deg selv etter hvert som ingeniørteamet vokser utover det punktet hvor du kan kjenne alle individuelt.
Blant et par interessante emner berører Jean personvern og personvernteknikk basert på deres erfaringer som fintech-selskap. Spørsmål om avledede data, god praksis for sletting av data, anonymisering av data og videresalg av data til tredjeparter på adtech karusell. Hvilket ansvar har selskaper overfor brukerne når det gjelder personvern? Hva er den beste personvernpraksisen for fintech-selskaper? Jean understreker også viktigheten av at privat sektor samarbeider med myndigheter og regulatorer i prosessen med å skape et godt balansert offentlig-privat partnerskap for å overholde GDPR og samtidig ikke drepe innovasjonene.
Takk for at du leser, og vi kommer snart tilbake med neste episode!
Les mer om dette:
TheCodestReview #2 - ukentlig juice for programvareutvikling
TheCodestReview #1 - ukentlig juice for programvareutvikling
Norwegian 
English 
German 
Swedish 
Danish 
Finnish 
French 
Arabic 
Italian 
Japanese 
Korean 
Polish