/blog

Here’s a funny story: I have around 70 unpublished articles in various stages of evolution — from only an outline and a title all the way to fully fledged articles. I also have four book ideas out of which two are almost done, five or so courses that are fully outlined as well as a host of product ideas. Now, I’m not saying all of them are good. I’m not the first or the last person with a highly active brain.

Here are some of my thoughts on microservices. It’s a small rant, but if you bare with me, you’ll also get some value from it. We’ve come to believe that some microservices rules are set in stone. The microservices cargo-cult is getting bigger and bigger. You need to have 30 services and each of them should be no bigger than a couple of functions. You shouldn’t use a single database for multiple services.

“I want to code!” It’s the little voice in your head, constantly pestering you to get productive. Replace code with any technology-related hard skill and you have the tech person’s productivity dilemma. But what does it mean to be productive? What does it mean to be productive as a solo professional? If you’re a freelance developer and you don’t code, you might feel like you’re not doing the right thing. You might feel like you’re being unproductive.

A lot of mixed feelings may grow on you while working as a junior developer. You have the choice of feeling powerless and less smarter than your peers or full of energy and desire to learn from people who know more than you do. You can look at others, compare yourself to them and grow frustrated, or look up to them and strive to become a better version of yourself.

Indeed! Why can’t we just get along and use one single JavaScript framework? Or two!? Here’s what I think about this situation that a lot of people consider a problem. I think it’s a huge opportunity, actually! This whole disagreement is actually one of the things that made JavaScript so popular! What follows is a dichotomy between two world views on the same topic. Part 1: The Pessimistic View There is a lot of personal preference involved, along with ignorance, hype and superficiality.

This is a question I’ve struggled with a lot, while trying to optimise the way I interview people. I don’t want to misjudge people, or evaluate them the wrong way, so I took some time and dug through my head, scoured the Internet for resources and narrowed down to a simple list. This is not a definitive list, I must state this loud and clear, before you even start reading. None of the points outlined here should be taken in isolation.

If you’re looking to revamp your website and you’re serious about this, you probably found mentions of static site generators, static sites and the JAMStack, on the Internet. Unfortunately, for every article that tries to explain what are the benefits of using a static site generators, there are other 10 explaining why static sites are not good. In theory: HTML, data and CSS are served from the same place So Adrian, what’s a static site and why do I need one?

The title of the article is from a question I was asked to answer on Quora. Below, is my attempt to explain what do the three dots do in JavaScript. Hopefully, this removes the fog around the concept, for people who will find this article in the future and have the same question. Updates Added more explicit usage of Array.prototype.slice.call(arguments). Thanks @gabriel for commenting and providing feedback. Added resources section with useful links.

Most software developers know that keeping hardcoded strings in your code is bad form. For the most part of our working life, we pester our colleagues to extract stuff in variables, make strings constants, so on and so forth. Text/translation file management became an interesting topic for me in the second year of my software development career. I was building apps that had a lot of repetitive text and I was frustrated because I couldn’t use the same approach I had with my code, that of extracting strings into constants.

Recently, there was an issue with eslint-scope that gave the JavaScript community a good scare. I wrote about it one day after it happened os feel free to go and read the article here. The gist was that some malicious third party was exfiltrating NPM auth tokens that it would probably later use to infect more packages in a ripple-like manner. What’s even funnier is that while I was listening to Ryan Dahl’s 2018 JSConf presentation, I heard him complain about a similar hypothetical situation with ESLint, namely, that it could take over your computer, due to Node’s non-restrictive model with filesystem and network access.