Mapping network connections to Process ID's in Windows

One of the cool features in Linux is the ability to map network requests with process id's (PIDs). This can help any system administrator troubleshoot a number of things, such as "What process is using port 80?".

I struggled for a long time to do the same thing on Windows machines, but I have recently found out that with netstat, run in administrator mode, you can actually get something similar:

Microsoft Windows [Version 10.0.17763.592]
(c) 2018 Microsoft Corporation. All rights reserved.

C:\WINDOWS\system32>netstat -aon

Active Connections

  Proto  Local Address          Foreign Address        State           PID
  TCP                 LISTENING       4
  TCP                LISTENING       1072
  TCP                LISTENING       4
  TCP               LISTENING       4428
  TCP               LISTENING       11140
  TCP               LISTENING       10204
  TCP               LISTENING       6916
  TCP               LISTENING       4

Remove all Docker images and containers

Very handy and fundamental commands to delete ALL Docker images and containers:

First start by deleting the containers (since these are dependencies of images):
docker rm $(docker ps -a -q)

Then we can proceed to delete all the images:
docker rmi $(docker images -a -q)

Render Material-UI Modal in the center of the Screen

The Material-UI Modal component is a very powerful and commonly used component in the ReactJS community. Unfortunately it is badly documented. One of the most common questions is how to center the modal to the center of the screen. Well the solution is actually quite simple, just add a style prop as follows:

          style={{ alignItems: "center", justifyContent: "center" }}

Hot Reloading Node and React on Docker Windows

Ever since I moved my development environment to Windows, it has been a constant struggle to emulate the previous environment that I had built on OSX.

Probably one of the most critical components in my projects is the fact that all of my projects run on a Docker microservice architecture. In addition to the usual isolation and scalability advantages, development becomes a joy especially when you use filesystem watchers on NodeJS (nodemon) and ReactJS (react-scripts) that enable hot-reloading.

The problem is that, out of the box, these file watchers do not work on Windows 10. The reason is that to run Linux container on Windows 10, you need to have Hypervisor, which acts as a virtualization layer - hence all virtualization rules apply to hot-reloading!

In other words, in order for hot reloading to work on Docker Windows, you need to enable Chokidar polling.

How do fix Hot Reloading with Chokidar?

For NodeJS, just modify the package.json file to use the legacy mode when starting nodemon. This can be easily done using the -L flag.

  "scripts": {
    "server": "nodemon -L index.js"

For ReactJS, it is equally simple. Just add a .env file inside the project parent directory (/usr/src/app) with the following line:


Trigger TeamCity job when specific branch is merged to Master

Any DevOps who has been involved in some serious CI/CD pipeline architectures have met these particular requirements at least once in his life:

  1. Detect hotfix* branches that are merged to Master
  2. Detect feature* branches that are merged to Master
  3. Automatically trigger a job if (1) is true
Although most build systems support this feature (I know for a fact that this is the case for Bamboo and Jenkins) and the methodologies are similar, this blogpost will focus on Teamcity, probably because I saw a lack of documentation on the matter.

Teamcity is notorious for being tricky! The only way to trigger merges is by listening to the commit messages. With this in mind, we will bake our commit messages to reflect our needs.


We will assume that the commit message looks something like:
git commit -m "hotfix-*"

Trigger when HotFix branch merged to Master:

Trigger when Feature branch merged to Master:

In both cases, the VCS should be only monitoring the Master branch:

Calling setState() behind an async call in ReactJS

I have blogged about how dangerous it is to use setState() during component lifecycle methods or render() functions. This is because the component can end up in an endless nested deep render. Dan Abromovic and the creators of ReactJS have also talked a lot about this subject. This is why we associate setState() with an event, like a button click.

A similar design pattern exists in ReactJS when we try to use setState() after calling an async function. In Redux we would not have this problem of course. However let's say you are rendering a location pin inside Google Map without the complexities of Redux state management. So all we want is:

  1. Geocode an address by calling Google Maps API
  2. Wait for the API response
  3. Set the map marker state so you get the pin at the right location

If step (3), the setState() function, is called before we get the API response, ReactJS is most definitely going to throw an error? Why? Because calling setState() before the component has fully mounted, or is still rendering, or is re-rendering, is a cardinal sin in ReactJS. 

So to make sure that step (3) is always called at the very end, we can easily make use of the async functions. Note that in setState(), the common pattern to call it synchronously, is to bind it to a function. Checkout this working code below to understand what I am saying:

Chaining API requests with Redux Thunk

Recently I wanted to be able to gather an array of objects on the first API request, and then for each object, fire off another API request that will get the object data using each object id. As you can imagine, the challenge is chaining multiple API requests using Redux Thunk and Axios in an asynchronous fashion.

Although the problem seemed simple, I realised that the solution is not equally trivial. I also figured out why this kind of design pattern is not documented:

Scenario 1:
Most users don't approach this kind of problem in this manner. In fact, most users just stop at the first API request to render a list of objects. Then they wait for the user to click on one of the objects to render the subsequent object details.

Scenario 2:
Users use other technologies other than Redux Thunk... technologies such as Redux Saga, to chain multiple API requests. In fact, this is one particular use case for which Redux Saga was designed.

Nonetheless, I was convinced that Redux Thunk can be still used. Apart from that, I was in a tight timeline to deliver a project so learning a new technology was out of question. The use case was for a  new aggregator system (from Reddit) that first fires an API to get latest Reddit posts, and then fires another API request for each Reddit postID to get the comments on each post:

I was able to solve this in redux-thunk by making two actions; one to fetch all, and one to fetch each individually. And, to chain them together, we treat each action as a promise (they return axios promises), then let Redux Thunk do its magic.

Let me show you the code snippet:

Notice that I made use of the getState() method to get the array of objects from the first API request promise. The getState() method provides us with a very easy way to pass state values (in this case, the array of objects) to action creators. It is important to understand that we are dealing with promises here, so the getState() method is exactly what we need - once the promise is fulfilled, the second action creator (and therefore, API request) is kicked off.

This design pattern is extremely important and will give you more mileage in your React Redux projects. For posterity, this is how you can then render the data inside your component: