How I Manage my Day

Darryl Daniel — Sun, 16 Aug 2020 14:30:58 +0000

Cover image by Icons8 Team on Unsplash

You probably have busy days. Kids, work, household chores and maintenance, finding gifts for birthdays. Time is our most valuable resource and we're expected to manage it all. In software development, this can get tricky. We're often pulled in multiple directions on a daily basis - there's a bug in production, someone needs you to review their code, there's a new feature for you to design. I find context switching (amongst other things) to be a major productivity killer. What follows are a few simple techniques I use to manage my day.

I find there's generally 3 things I need out of a day manager:

The ability to reduce the effects of context switching
Not missing anything important I need to remember
Handle recurring and ad-hoc admin

I've been using Notion for over a year now and I find it extremely useful. It's flexibility (although it comes with a steep learning curve) allows me to create as simple or as complex a system as I want. It's helpful to view how others have set up their systems in Notion. I recommend Marie Poulin or August Bradley's YouTube videos (links at the end). Of course, any other app (even pen and paper) would work perfectly fine here. Here's a demo of my setup in Notion:

The task list

Firstly, it's important at the start of your week to map out what you need to accomplish for the week and the tasks needed to get you there. This process is important and will save you a lot of time later. At the start of each day you should have a list of things that you need to get done for the day. Prioritize these as you see fit.

The main benefit of having this done up front is that you don't waste time deciding what you have to do for the day. It's easy just to pick the highest priority task and do it. The added benefit is that when you're inevitably interrupted, once you've handled whatever has demanded your attention, you don't have to think about what you were doing. It's front and centre.

Reminders

I like to have a space somewhere to record things that I need to remember. This used to be sticky notes for me. Sticky notes are great. They're always visible, small enough that you don't add too much detail and colourful so it draws your attention whenever you stop focussing on a task. Recently, though, I've found myself needing them less and less.

I've added an area right above my task list where I can write out things I need to remember. I can even colour code them or add a date reminder if they're really important. Like a virtual sticky note. Any time I've completed a task and I come back to my task list to see what's next, there my reminders are. I can choose whether or not to act on something.

This space is particularly helpful in managing interruptions or context switching. For example, if I'm interrupted but it's not urgent, I can leave myself a reminder to handle it later. I'm free to go back to focussing on a more important task without worrying that I'll forget.

Admin tasks toggle

I keep a space with admin things that I need to do but don't have a specific time frame. I put this behind a toggle so that it's out of sight. The best thing about this is that it's no longer in my face screaming that it needs to be done and I have peace of mind knowing that it won't be forgotten. When I have a break or some spare time, I can just sort out as many as I want. It's also helpful having a centralized place where I can add tasks as I see things that need to be done.

In conclusion

There's a lot more going on behind the scenes here. For example, I have a process that I utilize to plan out my entire week which lets me look at the projects that I have on the go and plan the tasks I'm going to execute on each day of the week. If I don't finish those tasks, they automatically roll over to the next day. I also have a method for handling monthly / weekly recurring tasks which I'll share in a future post. I hope this has helped in some small way to bring a little bit more order to the usual chaos.

Amazing Notion resources

August Bradley Notion life operating system
Marie Poulin Notion office hours

How to health check multiple PM2 processes with NGINX

Darryl Daniel — Fri, 05 Jun 2020 13:59:46 +0000

Production node apps require multiple instances for reliability. One possible configuration that achieves this uses PM2 to manage the app instances and lifecycle and NGINX for the load balancing. When running in this configuration, however, it can become tricky to check the health status of each instance individually.

As you can see in the above diagram, when one of the PM2 instances has shut down, NGINX's load balancer will see that the first instance is dead and route the request to the instance that is up and running. You won't be able to check on the status of the dead instance until it is restarted and NGINX will continue to tell you that everything is fine despite one of the app instances being down.

In this post, I'd like to demonstrate a method of configuring NGINX such that each instance can be checked independently and the above scenario avoided.

Start with a basic node server:

const Koa = require('koa');
const Router = require('@koa/router');
const app = new Koa();
const router = new Router();

// PM2 will set the NODE_APP_INSTANCE when it spins up an instance
const portOffset = parseInt(process.env.NODE_APP_INSTANCE);

router.get("/health", async ctx => {
    const healthServerNumber = portOffset + 1;
    ctx.body = "health status server " + healthServerNumber + " -> ok";
    ctx.status = 200;
});

router.get("/", async ctx => {
    ctx.body = "default route";
    ctx.status = 200;
});

app.use(router.routes());
app.listen(9001 + portOffset);

The process.env.NODE_APP_INSTANCE variable is set by PM2. Each app instance will be assigned it's own port based on the value set by this variable. This will make each app instance accessible via it's own port. The PM2 config looks like this:

const app = {
    "name": "health-checks-app",
    "script": "./index.js",
    "max_memory_restart": "100M",
    "watch": true,
    "log_date_format": "YYYY-MM-DD HH:mm:ss.SSS",
    "env": {
        "NODE_ENV": "production"
    },
    "exec_mode": "cluster",
    "instances": "2",
    "kill_timeout": 5000,
};

module.exports = {
    "apps": [app]
};

Add the following to the NGINX config on the server:

upstream health_check_servers {
    server localhost:9001;
    server localhost:9002;
}

upstream health_check_server_1 {
    server localhost:9001;
}

upstream health_check_server_2 {
    server localhost:9002;
}

server {
    listen 80;
    server_name localhost;

    location ~ ^/health/instance-(.+)$ {
        rewrite ^/health/instance-(.+)$ /health break;
        proxy_pass http://health_check_server_$1;
    }

    location / {
        proxy_pass http://health_check_servers;
    }
}

There are 3 separate upstream definitions. One for the pool where NGINX will pick a server for each request based on a round robin and one each for each instance. Each time a new instance is added, this will have to be updated.

So how does this all fit together? When a request is made to /health/instance-1, NGINX will route that request to the health_check_server_1 upstream which will make a request to the instance on port 9001. Likewise, when the url is /health/instance-2 the second instance will receive the request. The rewrite is important here otherwise the url that is requested on the app will be http://localhost:9001/health/instance-1 which does not exist. We rewrite this to /health to get the correct endpoint.

This configuration enables us check the status of each app separately. The benefit here compared to having some kind of monitoring directly on a server is that your application is tested end-to-end and you can be confident in the fact that it is accessible reliably from the outside world.

Example repo can be found here.