/blog

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.

This video shows you how to enable JWT authentication for the Wordpress REST API. You will first create a kickass Wordpress development using the official MySQL and Wordpress images from the Docker hub and then go through the whole plugin setup and testing process. Below are the links to everything used in this video Info about JSON Web Tokens and the JWT Authentication Plugin https://jwt.io/ https://enriquechavez.co/ https://wordpress.org/plugins/jwt-authentication-for-wp-rest-api/ https://wordpress.org/plugins/search/jwt/ How to access the Wordpress Rest API (permalink structure setup) https://stackoverflow.

Last week I saw this very interesting Twitter thread, about CI/CD strategies for multiple teams. The question was whether or not one should go on a centralized, or a decentralized strategy for setting up continuous integration for multiple teams inside the same organization. This article tries to distil the key points of that discussion. The centralized model You might be right, thinking that going centralized is the best choice. Everybody uses the same infrastructure, the same technologies and future, cross-cutting projects can look like a breeze.

You want to be a freelancer and you would like to have a stable stream of income. You read it all over the web that you need to specialise. But you’re afraid that if you work with only one front-end framework, you won’t be able to get enough clients. I totally understand where you’re coming from, I’ve been a generalist for the biggest part of my career as a JavaScript developer and it is precisely because of this.

I’ve been working a lot with microservices in the past couple of years. It is during this time that I found how many issues can arise from putting an accent on delivery while disregarding architecture. This is why I decided to create MONOLITHSPL/T. I want to help businesses migrate their monolithic Node.js applications to a microservices architecture, improve the quality of their products as well as their overall delivery. My goal is to provide clear, actionable steps, to move away from poor architectural decisions made under pressure.