(In next episode, I will follow up on the topic of humor in the workplace to elaborate a bit more on it, just because I can. "Why so serious?").
Speaking of time, 2 weeks have passed from my last publication therefore it's about time for the 4th episode of our #TheCodestReview series.
List of topics we cover this week:
- Getting Hooked on React
- Everything You Ever Wanted To Know About View Caching In Rails
- The Engineering Manager as a master recruiter
The comment on view caching delivered by our fullstack developer and the engineering manager podcast commented by my humble self.
As a popularly known Paint app master and admirer of GIFs and memes which are like Merci chocolates - saying more than 1000 words, I decided that from now on I will add here a flavour of it. And guess what?
To make it an equal terms battle, I wanted to let React take a swing back at Stimulus. Since I'm also a well known man of honour, always doing what I say and delivering on my promises, here it goes:
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.
Side note: my wife is absolutely loving Vinted and she almost completely stopped using OLX as her primary destination for decluttering our wardrobe and selling used clothes (was a true die hard fan) = YOU GUYS ARE DOING IT RIGHT!
It's my privilege to welcome a first guest contributor into our series:
Getting Hooked on React by LadyBug Podcast
Ali and Emma from the LadyBug podcast discuss React’s ins and outs - from the general layout of the library and its benefits to lively discussions on components, data handling, or the React lifecycle, all presented with a pinch of personal experience. It’s a worthwhile listen for any front-end developer who hasn’t had the chance to try out the wonders of React.
My first encounter with React was around three years ago when I began my journey as a developer. Even though Ali and Emma suggest that React might seem confusing at first, from my own experience, I found it relatively easy to begin with and probably the easiest to advance in comparison to other front-end frameworks. There are plenty of tutorials, articles, open-source libraries, and other kinds of learning materials available everywhere. However, one should be aware of the active development of React when going through such resources. This episode of LadyBug’s podcast is not an exception - some aspects and methods mentioned have already been deprecated for some time. Thus, it’s best to follow advice made by Emma herself and look at the most recent documentation.
React has evolved and matured a lot, making code writing even easier with Hooks, which lets you use state and lifecycle methods without writing class components. But for beginners - as Ali accurately remarks - the variety of ways you could write React (such as class/functional/Hooks components) adds additional complexity, as sometimes it can be difficult to visualize what’s going on. Also, having to distill what you need and finding relevant information regarding code implementation might be challenging.
Ali and Emma also nicely summarize the flexibility that having a component system gives. An excellent example from practice is my company Vinted, which has experienced rapid growth regarding the product as well as the development teams working on it over the last several years. React has provided tremendous benefits - it has enabled us to write much cleaner code, use reusable UI components, and has made our code easier to test.
Overall, this LadyBug podcast episode provides a lively and charming discussion about React’s main aspects. I recommend it to anyone starting their journey with React. Full of funny examples and analogies to real life, the episode seamlessly “Hooks” every listener’s attention, mine included.
Rails view caching by Jonathan Miles from Honeybadger
The views in Rails are unfortunately getting slower with time. That is because the amount of objects stored in the database grows. This causes longer query times and of course longer processing if you are doing something with each of the objects. When it happens you are not left without any chance as there exists Rails views caching.
Thanks to this you can save quite a lot of time by loading database-heavy data from the cache (loading single saved html-like file instead of querying database and processing objects). You can also make it less expensive in case of different partials and objects – of course if the objects do not change too often. You can also try to keep the cached objects in a separate partials – and save eg. 19 out of 20 posts being rendered (possibly with a lot of fields).
By default Rails caching uses the file_store and keeps the cached data in the folders. But it is not deleting old cache entries (which might have expired a long time ago). This can lead to file amount overflow or even running out of free space on a server. The other method is memory_store which also has some downsides (as the cache is kept on a single server). It also can exceed the amount of RAM kept on the server (or lack of cache if it will be deleted all the time). That's why the best high scale caching mechanism is the Memcached/Redis method. This gives you a chance to use a separate machine keeping the cache that can be used by all of the servers. Thanks to that there will be no problem with lack of cache or finishing disk space on a server.
The cache in Rails is kept based on an identifier – which can be given straight away as a string or generated automatically when you pass an object to the cache function. In case of objects it is most often the updated_at attribute. You can also provide a static key from object parameters.
Engineering Manager as Master Recruiter by Mentoring Club
Not to spoil you too much, the panel discussion covering the topic of the role of engineering manager in the hiring process is highly valuable for all of you wondering when it’s the right time for the tech leader to step into the interviewing cycle. At Codest, we kind of practice what the panelists preach and our CTO is the 1st point of contact with engineers applying to us, while at the next stage the interviews are sit by team managers whom the potential new joiners will work closely with. A few actionable pieces of advice you can apply right away to upgrade your hiring game as an engineering manager:
Review your process and make sure you join the flow as early as possible, ideally being the 1st touch point for candidates as first impressions play a key part how your company is seen by top talents.
Reach out to highly effective hiring managers in your organisation(perhaps the one who hired you back in the days) and ask if you could shadow some of their planned interviews, check their techniques, ask about tips. Watch and learn. Enter every interview with a genuine curiosity in the candidates.
Look for potential and hire for potential and ability to grow fast.
Talk through your job ads with all your engineers and ask if they would apply for the job. If not, ask what sucks and apply their feedback into the 2.0 build job ad you are about to push to prod on job boards.
See the 1st interview as an opportunity to create a great relationship with your potential future colleagues.
I encourage you to watch the whole video panel, but if you are into podcasts and like to listen while driving, working out or washing dishes, here you have also a Spotify link.
Coming back to you with the next episode soon(ish)!