GO BACK
Hello and thank you for coming over here to check the 3rd episode of our TheCodestReview series. That means a lot to us and hope it will be a time well spent.
Since we live and breathe Ruby on Rails, this week we have decided to put some spotlight on StimulusReflex that is getting the attention in the community as a new kid on the block, being an alternative to using modern Javascript frameworks in Rails projects to avoid overkill. Additionally, we take a swing on when Scrum doesn’t work and privacy engineering in fintech projects based on Plaid (https://plaid.com/eu/)
3 Privacy engineering in fintech products based on Plaid
The StimulusReflex and Scrum comments this week are delivered to you by our Ruby engineer and Project Manager.
In the next episode it is my pleasure and I’m excited to announce that we will have a guest post by React engineer from Vinted.com. For those of you who have never heard of Vinted (low odds, but still possible), Vinted is a fashion marketplace originating from Vilnius, Lithuania that has reached a unicorn valuation back in 2019. The platform is built on solid Ruby on Rails foundation backed up by React on the frontend part.
(HUMOR ALERT)
Controversial title, isn’t it? I have to admit that it was equally shocking for me, so I was eager to read and check what’s there behind the slogan or if it is just another clickbait. I was skeptical but also full of hope to be fair. Don’t get me wrong. I don’t have problems with React and Javascript in general but when I read „Reactive Rails” my imagination went crazy. Enough about my feelings, let me summarize what is juicy in this article.
This full of humor and hype article looked chaotic at first sight but I gave it a try, because I enjoy this sense of humor and the first paragraphs boosted my hope and hyped me even more.
Obie Fernandez explains what stands behind the name „Reactive Rails”. To give you a quick view it is mostly working with StimulusReflex and ViewComponent. These two powerful tools convinced the developer that React was no longer needed. He even wrote there that „there is absolutely no technical need for Rails developers to use React anymore”. Blunt, right?
Of course the author doesn’t leave us with this slogan. To prove his words (if someone doesn’t believe them) he summarizes Reactive Rails’ approach in bullet points. He also guides us through his adventure of rewriting some parts of his side project that used Vanilla Rails and some jQuery code to follow the Reactive Rails approach. He found out that the setup was relatively painless and it was really quick to get productive after not so much time spent on learning new tools. All is of course followed with code examples so we get a better view on what happened during this process.
Not to get you bored I really convince all of you to read this article. To be honest I am really excited and hyped after reading it. The way Obie Fernandez introduced Reactive Rails hit me a lot and gave me hope that something big is happening in the Ruby community. He bought me with this article, I will for sure explore this new approach.
Codest recommendation – StimulusReflex could be worth a try if you are an early stage startup having a Ruby team and lack of frontend capacity. If the UI of your platform is facing B2C users and you need to make it fancy and shiny right from the start, you may consider giving a go to StimulusReflex over jQuery classic code. If you wanna add a feel of a modern application to the existing Rails project lacking modern JS, you should find StimulusReflex a solid and time efficient alternative (taking your Rails version is up to date). Implementing it to your existing project should be relatively painless.
Even if the rules seem to be very simple, their implementation is a hard nut to crack. It requires the work and engagement of all team members. You cannot afford to have someone who just does nothing. When the Scrum statements are convergent with your employees’ beliefs, the entire process is easy as a piece of cake. People will gladly accept additional responsibilities and their cooperation will be highly efficient. But if their mindset has nothing in common with the Scrum approach, it is going to be a strenuous task and most of the workload will be on the Scrum Master’s shoulders. Despite all the obstacles, you can still succeed if the team is sufficiently engaged. The specifics of the product type can also be a factor in why Scrum hinders rather than helps. These are mainly projects regarding tangible products, such as hardware. There are some projects which require a different approach than Agility. The reason might lie in the people included in a project. Scrum demands the Product Owner and Scrum Master’s presence.
You can also read: Why Agile is winning?
But: A Killer of Scrum by Dirk Bolte
Thoughts on privacy engineering and making sure security is built in from the beginning of a product.
How the pandemic has accelerated peoples digital experiences.
How to scale yourself as the engineering team grows beyond the point where you can know everyone individually.
Among a couple of interesting subjects, Jean touches upon privacy and privacy engineering based on their experiences as a fintech company. Issues of derived data, good data deletion practices, data anonymization and reselling it to 3rd parties on the adtech carousel. What is the responsibility of companies towards their users about the privacy of their data? What are the best data privacy practices for fintechs? Jean also underlines the importance of cooperation of the private sector with governments and regulators in the process of creating a well balanced PPP to comply with GDPR and not kill the innovations at the same time.
Thanks for reading and coming back to you with the next episode soon(ish)!
Read more:
TheCodestReview #2 – weekly software engineering juice
English 
German 
Swedish 
Danish 
Norwegian 
Finnish 
French 
Arabic 
Italian 
Japanese 
Korean 
Polish