Friday, October 27, 2017

Leave a comment (0)

Saturday, September 16, 2017

Reverse insomnia: when you wake up too early but can't go back to sleep

This FFT is inspired by real life and articles I've read over the years about how you shouldn't make decisions when you're not in the right state of mind (confusion, anger, sadness). I agree, and I'm going to try explaining it in a quantifiable manner.

As the saying goes,

You can't control what happens to you, but you can control how you react to them.

There have been uncountable situations where I've done or said something I've regretted after thinking about it moments, days, weeks later. I could've done better if I just took my time to calm down and think about it. Now, before everyone starts trying to over-rationalize everything that happens to them, I'll like to add that your choices made under duress isn't necessarily wrong. The problem is that we can never replay that exact moment and how we feel at that point in time.

A simple example would be when your life is threatened by some external force, say, a robbery where the assailant has a knife. In this example, you happen to own a gun and you're in a position where you can either shoot him, make a warning shot or run. It would not be surprising that a good number of people would choose to shoot him instead of giving a warning shot, not because some people just wants to shoot people; but because they're not in the right state of mind to make the rational choice of giving a warning shot.
(I understand the caveats where the victim is well-trained like a soldier, but their mental state is different from a normal person so the point still stands)

If you belong to the group who shot the robber, would you have regretted your actions if he died? Would you think that you're wrong?

It depends.

Whatever you feel about the goodness/evilness of your actions, it's pretty much universal that if you have had more time, you could've made a choice where you would feel better in the long run. Feelings don't last forever, when all that adrenaline/serotonin/dopamine finally balances out, you're faced with the stark truth of your actions. Which brings me to this graph.

x-axis: time / y-axis: satisfaction

Disclaimer: there's absolutely no statistical evidence backing this up, just plotting how I feel about it

The red line starts off with a really high satisfaction level (point 0), and it's usually the thing we end up doing; because it seemed like a really great idea at that point of time. Compared to the blue option at point 0, it feels leaps and bounds better. But the red line dips dramatically after the initial moments as you start wondering, "why did I do this?", "what if?", "maybe I should've tried something else". It will still feel like a great idea while you're still being fueled by emotions; until it finally hits you at that magical break-even point.

It was at this moment that you realize you fucked up.

The solution is simple, when you're not in a clear state of mind, if you can afford to, hold off on any decision making. Sounds simple and common sense, but applying it in real life is a difficult practice of restraint. Being aware that you're not calm is probably the first step.

Unfortunately, even when I'm aware of my state of mind, I'm not able to always make the best choices.

to err is human

(to forgive, divine)

The way I keep myself moving forward and not be bogged down by the countless of regrets that may arise from some bad choices is simply to write my thoughts down. Put it down in a tangible form that you can experience again, to feel the similar emotions you've felt. In my case, >90% of time I still feel like I have made the right call.
(p.s. the rightness of your choices depends on what you value, will probably write about it some other day)

And life goes on.

Labels: food for thought

Leave a comment (0)

Tuesday, August 22, 2017

When I close my eyes because soap got in while bathing, my hands will be searching for the tap to wash the soap way. Sometimes I'm afraid that instead of a tap, I'll touch another hand.

Leave a comment (0)

Saturday, August 19, 2017

Woah, the past week was insane and I just felt like I needed to rant about it.


Attended the Amazon Web Services Solutions Architect course because it's what I chose as an external certification (prerequisite for graduating from my course). Of course, it doesn't have to be this specific course but it's what I've always been interested in so it's perfect.

However the amount of content is insane, >200 slides each day and an average of 2 labs per day. Starting from 9am to 5pm everyday. Thankfully the lunch provided is actually decent and there are 2 small breaks between the sessions.

Fortunately, as this was my area of interest, I've had exposure to most of the concepts that they had to offer. The only tough part is translating all those concepts into the actual services that they provide. Many of the things that they talked about is similar to the things I've done in this post. Or it was something I learnt during my poly days, just in a more advanced form.

Studying about these made me think hard about what kind of job I want to do in the future. Currently I'm moving towards the (web) developer side of things; which is really high in demand. But it's definitely not as cool as being the one to architect a highly available system that is able to survive failures across multiple nodes. So many things to consider with the internship coming up in a couple of months, hope I can figure something out.

p.s. bought my dream keyboard, a new speaker system, extra storage

Labels: life

Leave a comment (0)

Friday, August 04, 2017

Labels: music

Leave a comment (0)

Thursday, June 22, 2017

It's like having a vital piece of functioning code ripped out of my program suddenly.

Analogy time.

I started out as a normal program with code required to function and perform day to day tasks. One day, I was introduced a small piece of new code, it became part of me; but it wasn't doing any critical function yet.

Over time, more and more functions and code are added to that block of code. My program started relying heavily on it and it made me run faster, tasks was shared with it and generally all was good. But no program is bug free, so I spent a lot of time debugging the errors and working out the kinks. But some bugs never really went away, hotfix patches would resolve those bugs, only for them to surface again after an arbitrary amount of time. It was a lot of work to keep up with the patch work.

After many rounds of careful analysis, it was decided that the code needed to be removed.

Even though the prep work has been done, deleting a huge block of code that has been supporting the program is a painful move. Unsurprisingly, the program crashed, and it crashed hard. Turns out that block of code was doing a lot more than the comments specified. Vital operations were disrupted and errors were throwing up everywhere, constant stack/heap overflows.

The best course of action is to start going through all of the error messages and addressing them one by one, which I did. Slowly but surely, I started writing out little functions that handles all the memory leaks. But they are pretty much just

emotions > /dev/null 2>&1 ?

In summary, the program still works. It's a little confused on what files to import, wishing that the missing block had adopted an adapter pattern. But

It'll continue to run, just a little different from now.

Leave a comment (0)

Tuesday, May 02, 2017

It has been no secret that I've been working on a few personal projects of my own. My friends know how fucking excited I've been getting lately when I hit my milestones.

Since I've been repeating myself a lot lately and it's quite hard to explain quickly without the aid of diagrams, I created some diagrams.

Firstly, I'm using an open source solution called Docker for hosting my services and it's amazing and I urge you devs out there to check it out. In simple terms, it's a way of virtualizing services rather than the OS itself. The benefits are that there is less overhead, starting and stopping services are just a few simple commands away and you can duplicate as many services as you want across a cluster(swarm).

Right now I have a few services that are always turned on.

1. Automated torrent downloading
2. Google Drive-like service for files
3. Internal DNS service
4. Service manager for docker containers
5. VPN service

I also have some development sites that runs on and off based on changing needs (eg. web, database service).

Secondly, I've been reading up quite a lot about reverse proxy and I've been wanting to set them up for months/years(?!) but just haven't had the time to get to them. In simple terms, a reverse proxy is kind of like a seamless way of redirecting users to the correct server based on the URL. It could be used for load balancing, or in my case, used as a transparent way for end users to access the services*.
* | why not DNS? Because DNS only resolves IP but cannot resolve port numbers. My services are only exposed by port and are (mostly) on a single machine so I had to do it this way.

However, I still have a DNS service running because I need to be able to resolve URLs to a physical machine. (no messing with host files anymore)

An overview of how it works is shown in the diagram below.



When the reverse proxy server (aka. nginx) is hit with a URL query, eg. (http://torrent.service), it looks in the configuration where to redirect the user to seamlessly in the background. The seamlessness/transparency is a very powerful tool. I will explain it in more detail after illustrating how the general flow of logic of this setup.


* | client machine must be configured to use my DNS server (forced over VPN)

When user visits any site ending with .service or .dev, the DNS service will return the address of the services. Because most of the services are hosted on one physical machine, the nginx (reverse proxy) service resolves the incoming request to the corresponding service/dev.
* | if user visits another site eg. google.com, it will be resolved normally to the internet (albeit with a very slight latency overhead)

Going back to why nginx (reverse proxy) is a powerful tool, it's really the transparency that makes it awesome. When the user visits http://torrent.service, the DNS resolves it to the machine (eg. 172.16.1.66:80*). The nginx service listening on port 80 takes that query and forward it to the service (eg. 172.16.1.50:12345). However, to the end user, the URL never changes, the visible IP never changes, it all works seamlessly in the background.
* | IP and port number separated by semi-colon

eg. You navigate to the "downloads" page. The visible URL changes to http://torrent.service/downloads, it looks like it's 172.16.1.66:80/downloads to the system, but it's actually 172.16.1.50:12345/downloads. It all takes place automagically.

It's great when everything comes together but I definitely had my fair share of problems when setting it up and have to combine multiple sources of answers online before I could get my services running the way that I want them to. There is still 2 amazing projects that I'm looking to tackle before school starts proper, my fingers are crossed.

I'll like to clarify that when I say service, it may be made up of one or more services. For example http://torrent.service is made up of Transmission (the downloader service), and Flexget (the background service that searches for latest episode).

To end it off, everything is hosted either on my secondhand Thinkpad X200 (released in 2008), or on a Raspberry Pi 3. So if there's anyone who's interested in sponsoring me for anything (I can even make a video about it), contact me.

Labels: featured, geek, lordofgeeks, server

Leave a comment (1)