TORNA INDIETRO
They say time flies fast when you are having fun. For me personally, the fun part is especially important in everyday startup and business growth ride. It makes me enjoy myself no matter how much of my inner energy resources are eaten out by week to week hustle.
(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.
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?
Darth Sidious You Think You Can Stop Me GIF da Darthsidious GIFs
Last time we have decided to put some spotlight on StimulusReflex that is getting the attention in the Ruby community as a new kid on the block, being an alternative to using modern Javascript frameworks in Rails projects to avoid overkill.
See: StimulusReflex aka ReactiveRails
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:
Nel prossimo episodio ho il piacere e l'onore di annunciare che avremo come ospite l'ingegnere React di Vinted.com. Per coloro che non hanno mai sentito parlare di Vinted (probabilità bassa, ma ancora possibile), Vinted è un mercato della moda originario di Vilnius, in Lituania, che ha raggiunto una valutazione da unicorno nel 2019. La piattaforma si basa su solide fondamenta Ruby on Rails supportate da React sulla parte frontend.
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:
Meryl Streep Yes GIF da Merylstreep GIFs
Ugnė Kryževičiūtė – React engineer from Vinted
When reading the title of the recent LadyBug podcast (“Getting Hooked On React”), I expected it to be mostly about React Hooks. Yet, while it didn’t dive deep into Hooks, the podcast provided an excellent introduction to the basics of the React library for JavaScript.
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 codice 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.
As one of React’s main benefits, Ali points out that it’s component-based, enabling code modularization and making it easier to work together with other developers. Besides, the ability to use JSX is a great visual aid when working with UI in JavaScript code – you don’t need to have separate HTML files!
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 prodotto as well as the team di sviluppo 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.
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.
A different method of caching is using Javascript to update a field that is changed once a day. This way you can have a valid date displayed all the time, without refreshing the website – which might be quite huge or slow to be run.
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 squadra 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.
Thanks a lot for reading and if you’ve come that far, I appreciate your time and any feedback(whether cool or trashing me) is more than welcome on LinkedIn or to my email.
Coming back to you with the next episode soon(ish)!
Yippie IWill See You Soon Dancing GIF da Yippieiwillseeyousoon GIFs
Per saperne di più:
TheCodestReview #3 – weekly software engineering juice
TheCodestReview #2 - succo settimanale di ingegneria del software
TheCodestReview #1 - succo settimanale di ingegneria del software
Italian 
English 
German 
Swedish 
Danish 
Norwegian 
Finnish 
French 
Polish 
Arabic 
Japanese 
Korean 
Spanish 
Dutch