/blog

Just found this very interesting feature in Visual Studio Code. It turns out that if you break a style rule, and you get a warning from ESLint, if you click on the lightbulb that appears on the gutter, near the line number where the error is, you get a “Fix problem” option. At first, I wasn’t sure if this was built into VSCode or in the the ESLint extension I’m using.

I created a short video to help you understand the basics of using the docker cp command. It is meant to help people who are using Docker understand how to copy a file from a running Docker container to their host machine. In my case, I’m using a container I built for a personal project, which creates PDF documents from websites. The generated document, resides exclusively inside the container. It is then copied using docker cp to my host machine, where I can open and inspect it.

In this short article I plan to share with you a simple trick I use to make my Node.js code read better. It’s not wizardry so don’t get discouraged by the “trick” in the title. Here’s a regular Expressjs route handler executing a database interrogation using Mongoose: router.get('/user/:userId',(request, response) => { User.find({ id: req.params.userId }, (error, data) => { if (error) { return response.status(500).json({ status: 500, error: 'The query failed', }); } if (!

TL;DR Stop creating monoliths. Stop the brainless, head-first dive into development. Buy the cheapest notebook and some pens and start scribbling. You’ll thank yourselves! The story From time to time, I get the chance to interact with tech startups and I formed the nasty habit of asking about their codebase. Whenever I ask this question, I get two types of answers depending on who’s answering: The CEO, or any non-technical C-level person, almost always complain they’re moving too slow because of poorly written code.

It wasn’t very long ago when we didn’t have all these generators, scaffolders, bootstraps etc. Not long since we used to include a small library into every project. You got it right, people, I’m talking about jQuery. Actually, the article is not about jQuery. The title can be regarded as a clickbait but I had to draw your attention to something important. Consider this article a parallel between jQuery and the web platform’s current state of affairs.

For quite some time I wanted to help developers better understand Docker containers. I’ve been working with containers for the past 2.5 years and like most of you, I was just a full stack JavaScript developer. I had to learn how to use Docker containers with no previous knowledge and little or no guidance. It was like being thrown off a plane with an umbrella instead of a parachute. This wasn’t necessarily a bad thing.

Long story short: I’ve never worked with React Native and wanted to give it a spin. Setup was a breeze, and I was able to get the app to work in the iOS simulator in a matter of minutes. What came after, is a story about bad habits. A couple of stack traces and some style updates later, I said to myself: “Does this thing have navigation?”. So I found NavigatorIOS in the docs.

I wanted to work with Vue.js on a “real” project for quite some time. Last night, I decided to migrate a very small portion of a larger project to Vue. In the next week or so, I plan on publishing a small series of articles about this experience. Setup Very quick setup, no headaches. The guide is straightforward and the fact that they also offer a CLI makes the experience more enjoyable for command-line junkies like myself.

I’ve been asked this question countless times during mentorship meetings, meetup networking sessions and forums. – What is the difference between assigning an anonymous function to a variable and a regular function? To know this difference the only requirement is to know how hoisting works in JavaScript. TL;DR – Hoisting The main difference between a function expression and a regular function is the following: Regular functions are hoisted to the top of the scope, with their full body whilst function expressions are hoisted like regular variables.

One of the biggest issues that plagues teams doing some form of Continuous Integration / Delivery / Deployment is execution time. If the pipeline is slow, then the feedback loop is slow. If the code takes 30 minutes to pass through the pipeline and build only to fail in UAT or even worse, production, precious time is wasted (and money). Going fast is not only about shipping fast but also about failing fast.