/blog

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.

On Thu, July 12 2018 at 1:17PM GMT Andrei Mihailov — @pronebird reported the following issue with the eslint-scope module: Virus in eslint-scope?. The gist of it is that there was some malicious code added to the module’s codebase and the affected version was 3.7.2. I’m saying it was because the ESLint team took it head-on and got to the bottom of the problem in record time — Thank you!

I recently had a discussion with an off-shore team mate who was supposed to add a new environment variable to a client-side app and re-deploy it. He had some trouble doing this, and after talking to him and illustrating how frontend apps use env vars in contrast with Node.js APIs, he finally understood the nuances His misunderstanding was about the way Webpack manages environment variables. Being an ops person, he assumed that environment variables work the same way they do for our Node.

So here’s the deal. I started listening to some podcasts related to content marketing and social media, since I want to up my game a bit. One of the things that bothered me the most is the continuous bickering of the podcast hosts about how they avoid to go to developers because it always takes a lot of time to get stuff done with devs. So I thought I would write an article detailing the struggles of developers when they get “work” that’s supposed to be ready yesterday.