Hi all, how is it going?
Well, I’ve decided to take my dev writing activity to dev.to for now, so if you want to keep tapping to any dev related posts I write be sure to check (and subscribe to):
Take care and see you there!
A coder’s take on Baz Luhrmann’s “Everybody’s free (to wear sunscreen)”
Ladies and gentlemen of the abstract class
If I could offer you only one tip for the future, testing would be it
A long-term benefits of testing have been proved by scientists
Whereas the rest of my advice has no basis more reliable
Than my own meandering experience, I will dispense this advice now
Enjoy the power and beauty of your product, oh, never mind
You will not understand the power and beauty of your product
Until you moved on, but trust me, in 3 years, you’ll look back
One of the cool features of npm is the ability to run procedures which can be defined under the project’s package.json file.
I’m pretty sure that if you are reading this post you also have a few npm scripts under your project’s package.json file and are wondering what “mapping” them means…
Large projects usually contain large number of npm scripts. You have a script for testing, for building, for linting, etc. …
If you are a front-end developer using ReactJS, you’ve probably caught a lot of buzz about render props and how they are supposed to be this great solution for situations where your components become too complex to work with, but like me, never have realized how it comes to play in real life.
In the following story I will walk you through the phases of understanding how the need for render props arises, and when it does, how to make them work for you.
ReactJS is all about components, and R&D organizations which adopt ReactJS as their client side technology…
This post is not about the many benefits of practicing code reviews within a development organization. I found that many articles deal with these benefits but tend to neglect the way code reviews should be conducted.
To be honest, I’m still learning how to give and receive code reviews myself. It is an on going process for me, but I managed to gather some rules along the way to form a basic code of conduct that I try (yes, try. I don’t always succeed) to follow.
In this post I would like to share these with you —
In Part 1 of this article we’ve talked about the motivations and challenges involved in migrating Capriza’s Designer build from Grunt to NPM.
In this part we will dive a little bit into the details of implementation to get a sense on what it actually means to migrate the build process of a matured front-end process to NPM.
All ready? here we go…
There is a lot of buzz around using NPM scripts as a task runner driving build processes, but most of the content out there speaks in slogans without really touching real project aspects and challenges, so we at Capriza decided to really dive into it and see if our Designer product’s front-end build process can benefit from it.
Here is what we’ve learned…
If you have been coding Front-End long enough you’ve probably came across this annoying statement— “Front End cannot be unit tested”.
This statement, to put mildly, is a complete and utter BS. The truth is Front-End can (and should be) unit-tested. The reason that developers avoid it by saying it cannot be tested is mainly due to the fact that what they think should be unit-tested is really hard to do, but the real problem here is not the unit test tools but rather what “they” think should be tested. …
Whether it is variables or functions, naming has a crucial part in debugging and understanding code, and since we spend more time reading code than writing it, it’s important that we pay attention to this (somewhat neglected) aspect of coding.
The value of correct code naming is so evident in every hour I spend reading code and in this post I would like to share with you my practices and code naming rules of thumb.
Everybody create variables, but very few take the time to really name them correctly. The reasons for it may vary but mostly it’s because we…
Do you still write code comments?
I used to be a true believer in code comments not too long ago, but I recently found out that there is always* a better option than polluting the code with it.
The shift for me came when I started bumping into my own comments and ranted like crazy. Later on I found out that my comments can be categorized into a several main types, but all of which share the same uselessness.
What do I mean by that? …