I have several email accounts and send/receive so much email that Thunderbird and Outlook are pretty much the only clients that don't crash on a regular basis.

Recently, I started a new job working remotely and I'm realizing more than ever that emails and IM's are starting to get really annoying.

An email every few minutes and desktop alert + sound to go with it makes it to easy to lose focus on my task at hand and look at my inbox. While I loved this feature, it's become the Achilles heel of my productivity.

Email is inherently designed to queue messages so you can get to it at a time of your convenience. But in practice, this never seems to be the case.

If you like getting work done, like I do, you learn to appreciate inspired laziness as the positive character trait it can be. And I take this one step further: I turn off notifications entirely, checking them only during breaks.

There are a few ways that you can use this to your advantage and harness it for maximum productivity.

Choosing what not to do

Today's world is a combinatorial explosion of possibilites. The signal-to-noise ratio keeps increasing, and unlike computers; we can't simply upgrade our minds.

Choosing what not to work on is just as important, and arguably more important than choosing what to work on. This is laziness being used to increase efficiency.

Why spend days doing in-depth research on ten different approaches to solving a problem when you could've easily discarded eight of them based on some key criteria?

Cut to the key goals. Cultivate the skill of discarding approaches as quickly as you can. It's a lot faster to download code than it is to write it.

Balance communication with isolation

Every day, constant communication is the norm - via phones, email, video calls, you name it. The price of this constant communication is a serious uptick in interruptions.

For some fields, like management, interruption is how things get done. But for computer science, specifically software development, it's poison. If we can't get into a flow state, it's difficult to be productive; so communication has to be carefully managed and often, deferred.

This is something I believe holds true for most kinds of work, especially those that involve a lot of "brainwork" - like writing, for example.

People don't scale

Truly lazy developers let their machines do the work for them. This is partially motivated out of self-interest; but smart developers know that people don't scale; machines do. If you want something done the same way every time, and with any semblance of reliability, you want the human factor removed as much as is reasonably possible.

On an interview with n8n, community member Tephlon said something that I think captures the essence of this:

Do things exactly three times; once to learn it, the second time to perfect it, and the third time to automate it.

For every problem I encounter, I ask myself – how can I make sure that I never have to deal with this ever again? If I can fix it so that nobody else has to, then that's a wonderful side-effect too.

Like I've stated in the past:
Don't celebrate the creation of code, celebrate the creation of solutions.

Don't delude yourself

Now, there's a fairly clear distinction between inspired laziness, as described above – it makes everyone's lives easier, and just plain not getting off your butt.
And only you know what you are.

I don't usually talk about my personal life here, but I have to make an exception in this case. I wrote this days ago in preparation for today and fervently debated in my head whether to put it up (#desifamily) or to leave it sitting in my Soul Journal.

If you're (South) Indian, then you know how brave I'm being right now.
You can thank these guys for that.

Today is the birthday of someone very special to me and it's caused me to think about all the "love" that I have experienced in my life so far. During the last decade (basically my entire teen/adult life), I have been in three serious relationships, with completely different, but similarly amazing, people.  I wanted to take a moment to fully acknowledge and appreciate my past.

While most people do nothing but complain about their ex’s, have a negative memory of their relationships, and often times, don’t talk to them anymore — I feel fortunate to not have had that experience with any of these three women. In matter of fact, I don’t even feel comfortable calling any of them an “ex”, as that has a negative connotation when they were really the loves of my life. They met me exactly where I was ready to be met at that point in my life. Perhaps “former partner” is more accurate.

To me, the success of a relationship isn’t based on how long it lasted, but rather how deeply you loved when you were in it, and how much love and growth you still experienced after it.

It is not based on the chemicals that you thought meant love when you first got into the relationship, but rather the actual love that was still there when you got out of it.
Did you forgive them and did you forgive yourself? Did you still find a way to love them as a person even after all the pain? How are you a different person after being with this person? Do you wish nothing but the best for your former partners or do you still have bitterness that it didn’t work?

Unconditional love is you wanting them to be happy, even if it’s not with you.
The truth is, I never had a failed relationship. They were all unbelievably successful. And the testament to that is this simple fact:  Not only do I still talk to (nearly all) my ex-girlfriends, but I am still in absolute love with each and every one of them, even though we don’t talk as much anymore.

What kind of person would want to hear their current partner say they’re still in love with their ex’s? One who understands what Love actually means. Often times, we confuse Love with life compatibility, intimacy, and relationship status. They are not mutually exclusive. Just because a relationship dynamic has shifted doesn’t mean that the love is not there. And just because we’re not sharing this life together in a romantic way and don’t talk everyday, doesn’t mean that they are no longer a part of who I am. The only reason that I’m able to love as deeply as I do now is because of my shortcomings in the past…because of the heart ache I experienced. Each person that we fall in love with is directly part of the butterfly effect of each person we fell in love with in the past, and how that relationship ended…all guiding us to our next teacher.

I’ve been able to experience such freedom in the love that I now have for my former partners. When I explore a new love interest, I'd like to think that my former partners would not react with jealousy or anger, but rather with support and appreciation. All three of them would get genuinely excited, and even want to meet the person who’s making me happy. It makes me feel so humbled that I’ve been with such powerful women in my life that truly want to see me fully loved and appreciated. I sometimes don’t even know what I did to deserve this, and why I’ve been so lucky in love, but I am deeply grateful for it.

When things ended, I can't recall a time when I had the “You’ll never find someone better than me” attitude. Instead, I told them that I HOPE they find something even more expansive than what we had. As we are all constantly shifting, I acknowledge the fact that who they were when we dated, is not who they are today. It doesn’t take away from what we had — it actually gives more value to it.
Because we loved each other the best way we knew how to at that time, we were able to grow as individuals. One partner isn’t “better” than the other. They are all connected to each other. They are all a part of each other. The ceiling of each relationship is the basement of the next one.

They all taught me what I want and didn’t want. What I value and what I can let go of. I am now only able to love as deeply as I do, because my former partners loved me as deeply as they did. Our lives are inter-connected.  With all three of my former partners, I'd like to think that we didn’t “break up” because we hated each other, but rather because we loved each other enough that we knew it was time to set each other free. We knew that we already served our purpose in each other’s lives, and it was time to expand individually. This is why we are still in each other’s lives. It is because we loved each other unconditionally, and still do.

Remember, love is an infinite source and no one person has a monopoly on it in your life. You have found it in the past and you will find it again.

I will never forget how my relationships helped me grow. Not from a place of attachment to the past, but from a place of honoring the beautiful times we had together. I carry all the past experiences I’ve had deep within my heart, as one accumulated energy of pure love. Each experience has expanded my heart and it is only because of the growing (and constant) pains of that expansion, that I am now able to love fearlessly and deeply. It is because of them that I am the man who I am today. If you're reading this, I love you and thank you. Thank you for your forgiveness, and your apologies. Thank you for loving me through my darkest times. Thank you for honoring what you felt at that time, for being in my path and for trusting your own path. You have been my soul mates and my angels of spiritual evolution. For the rest of this life, I will always care about you, love you, and wish you all the happiness and love that this life has to offer.

These days, however - I am my own person. Living the single life in the recent past has given me the chance to focus on myself and explore other interests - it's been a truly exhilarating experience so far and I look forward to everything that the world has to offer. Maybe I'll write about that someday too!

You couldn’t just roll down the street leaving huge piles of garbage everywhere you go, making life slower for everyone as they climb over your mountains of junk, just to get on with their life. You’d feel bad about it, right?

That’s how I feel about the digital things we put out into the world: websites, apps, and files.

I prefer coding everything by hand, wherever I can; because I don’t like the huge piles of garbage that the automated generators create. These programs that generate a website, app, or file for you spit out thousands of lines of unnecessary junk when really only 10 lines are needed. Then people wonder why their site is so slow, and they think it’s their phone or connection’s fault.

Yesterday, I needed to make a little vector logo. Two lines and two triangles. I tried to use a couple different vector drawing programs but they saved it as hundreds of lines. I knew it could be simpler, so I read up on SVG and made exactly what I wanted:

<svg height="54" width="54">
<defs><style type="text/css"><![CDATA[line,polygon{stroke:black;stroke-width:4} polygon{fill:black}]]></style></defs>
<line x1="2" y1="2" x2="2" y2="52" />
<line x1="52" y1="2" x2="52" y2="52" />
<polygon points="2,2 27,27 2,27" />
<polygon points="52,2 27,27 52,27" />
</svg>

Netflix is, in my eyes, a world-leader in video delivery, so I figured if they can use AWS to serve their content, why can't I? I mean, sure, they're an international multi-billion dollar powerhouse, and I am but one man. Still, I thought to myself if anything else, it'd make an interesting case-study to deploy an EC2 instance and fire up Plex. So, here's what I did.

• The components
• EC2 - The Server
• EBS - The Storage
• Getting everything in order
• And breathe...
• Time to build
• The CLI
• The script
• Deploying!
• Configuring Plex Remotely
• Uploading Content
• Performance
• Cost
• TL;DR - Is it worth it?

The components

Firstly, I had to understand what it was I needed in order to get my solution up and running. It was clear I would require two things:

• A running virtual host, preferably Linux
• Some form of storage for the media content

It really only boils down to those two components when it comes to Plex. Once I'd worked out that obvious list of requirements, I fired up my old, disused AWS account and checked out what the free tier would provide for me. I tried my best to see what was possible while staying within the confines of the always-free tier for AWS accounts.

AWS is a veritable supermarket of tools, from databases to AI, but in my case all I needed was an EC2 instance and an EBS volume.

EC2 - The Server

EC2 (Elastic Compute Cloud) is where the server will be deployed - it's in my eyes, the heart of AWS. There are quite a lot of options made available by Amazon, but I decided on the following:

• Image: Amazon Linux AMI 2017.03.1 (HVM), SSD Volume Type
• Instance Type: t2.micro
• 1 vCPU at 2.5 GHz, Intel Xeon Family
• 1 GiB memory
• Only allows EBS storage
• Region: eu-west-1
• Availability Zone: eu-west-1b

I figured "when in Rome" (EU region, get it?) and opted for the Amazon-flavoured version of Linux for no reason other than these were the first options on the list. It also helps that installing Docker is a bit easier as the AWS repositories haven't caught up with Docker's change to Docker CE.

The only instance type I was allowed to use under the free tier was t2.micro so my hands were a bit tied. I could have used something more powerful but I figured this would be a good starting point.

EBS - The Storage

A running server isn't really any good if there's no storage assigned to it for my media, so I decided on EBS (Elastic Block Storage) as my solution. By default, creating an EC2 instance will automatically create an 8GB EBS volume and assign it as the root partition - quite handy. While that's nice, much like my home solution, I didn't want to mix up my application data with my static media data, so I decided I'd create my own:

• Volume Type: gp2 (a.k.a General Purpose SSD)
• Partition Size: 20GB

Remember, I'm trying to stay within the limits of the free tier, so I'm not allowed any more than 30GB of EBS storage at any given time. Considering just having an EC2 instance creates a default 8GB volume, I've only got 22GB left to play around with - 20 is a nice round number.

Getting everything in order

I'd decided on what I needed at a basic level, so it was time to start thinking about actually building them and deploying them in AWS. Unfortunately it's not quite as simple as clicking "GO" and sitting back, waiting for it all to magically show up on the Internet. While there is certainly an aspect to that, I did need to consider some aspects of the deployment that are both specific to AWS and should be considered generally speaking when it comes to networking.

I spent some time reading up on how AWS handled things like VPCs, subnets, Availability Zones, and Security Groups, as this would impact the way I approached deployment of my solution.

And breathe...

By this point you're probably wondering if this is really worth my time and whether or not I have anything better to do. The answer to both questions is definitely "no". This exercise was nothing more than a way of helping me understand how AWS works (I've been a Google Cloud user for as long as I can remember), and whether or not a basic running instance has what it takes to run Plex. I'd not even considered the long-term cost issues (which I'll cover later on).

Time to build

I'm a technophile at heart, so I would be remiss if I didn't at least attempt to automate this! It's quite easy to use AWS's web console to create everything, but there's no fun in that, so instead I looked at CloudFormation - AWS's stack deployment framework. It's great because it meant I was able to test out small incremental bits and pieces of my deployment without having to manually go through all of the steps each time - I just typed in a command and let it do the work for me.

The CLI

Before I could think about automation, I needed to install the AWS CLI tool so I could push up my scripts to CloudFormation. It is of course possible, again, to do this via the web console, but that would be too boring.

After installing, I configured it to use the Access Key and Secret Access key of an IAM user I created that had permissions for CloudFormation and EC2. Amazon likes to hint at you to do everything via users with the least amount of privilege, which I think is a very good idea. Best keep my root credentials safe.

$ aws configure
AWS Access Key ID [None]: <AWS_KEY>
AWS Secret Access Key [None]: <SECRET_KEY>
Default region name [None]: eu-west-1
Default output format [None]: json

The script

CloudFormation is a wonderful tool. Much like the way Ansible automates the creation of a machine, CloudFormation automates the creation of an entire ecosystem within AWS. In my case, I used it to create three things: an EC2 Instance, an EBS Volume, and a Security Group. Complete overkill for my end goal - I could have done all of this manually - but very fun and worth learning.

So, let's get sucked in.

First, I needed to define a volume:

"PlexServerStorageVolume": {
    "Type": "AWS::EC2::Volume",
    "Properties": {
        "Size": "20",
        "VolumeType": "gp2",
        "AvailabilityZone": {
            "Ref": "AvailabilityZone"
        }
    }
}

Nice and easy: I wanted a 20GB size volume, that's a General Purpose SSD (the kind allowed by the free tier), and it should be in my given Availability Zone. Note: I'm using { "Ref": "AvailabilityZone" } rather than hard-coding the value because it means I can change it on a whim if I ever decide to redeploy this somewhere else. The reference is to a parameter defined at the top of the script. An Availability Zone is a distinct location within a Region and reflects the physical placement of my volume.

Next came my Security Group, which would define the inbound/outbound firewall rules for my instance:

"PlexServerFirewallRules": {
    "Type": "AWS::EC2::SecurityGroup",
    "Properties": {
        "GroupName": "PlexServerFirewallRules",
        "GroupDescription": "Restrict inbound access only to the Plex and SSH ports",
        "VpcId": {
            "Ref": "AccountVPCId"
        },
        "SecurityGroupEgress": [
            {
                "CidrIp": "0.0.0.0/0",
                "IpProtocol": "-1"
            }
        ],
        "SecurityGroupIngress": [
            {
                "CidrIp": "0.0.0.0/0",
                "IpProtocol": "tcp",
                "FromPort": "22",
                "ToPort": "22"
            },
            {
                "CidrIp": "0.0.0.0/0",
                "IpProtocol": "tcp",
                "FromPort": "32400",
                "ToPort": "32400"
            }
        ]
    }
}

I defined the firewall rules (to only allow ports 32400 and 22 inbound), and linked it to a VPC (my default). The EC2 instance is linked to the VPC via its allocated subnets, so this group must also link to the same VPC, although in this case, it does it directly.

Lastly, the really fun bit, the EC2 Instance:

"PlexServerInstance": {
    "Type": "AWS::EC2::Instance",
    "DependsOn": [ "PlexServerFirewallRules", "PlexServerStorageVolume" ],
    "Properties": {
        "ImageId": { "Ref": "PlexInstanceImageId" },
        "InstanceType": { "Ref": "PlexInstanceType" },
        "KeyName": "PlexServer",
        "AvailabilityZone": {
            "Ref": "AvailabilityZone"
        },
        "NetworkInterfaces": [
            {
                "AssociatePublicIpAddress": true,
                "DeviceIndex": 0,
                "SubnetId": { "Ref": "AccountSubnet" },
                "GroupSet": [
                    {
                        "Ref": "PlexServerFirewallRules"
                    }
                ]
            }
        ],
        "Volumes": [
            {
                "Device": "/dev/sdk",
                "VolumeId": {
                    "Ref": "PlexServerStorageVolume"
                }
            }
        ],
        "UserData": {
            "Fn::Base64": {
                "Fn::Join": [
                    "\n",
                    [
                        "#!/bin/bash -v",
                        "fstype=`file -s /dev/xvdk`",
                        "if [ \"$fstype\" == \"/dev/xvdk: data\" ]",
                        "then",
                        "    mkfs -t ext4 /dev/sdk",
                        "fi",
                        "mkdir -p /data/plex",
                        "mkdir -p /data/media",
                        "chmod 750 /data/plex",
                        "chmod 750 /data/media",
                        "mount /dev/sdk /data/media",
                        "mkdir -p /data/media/movies",
                        "mkdir -p /data/media/tv",
                        "chmod -R 750 /data/media",
                        "chown -R ec2-user:ec2-user /data/media",
                        "chown -R ec2-user:ec2-user /data/plex",
                        "echo \"/dev/sdk /data/media ext4 defaults,nofail 0 2\" >> /etc/fstab",
                        "yum update -y",
                        "yum install -y docker",
                        "service docker start",
                        "usermod -a -G docker ec2-user",
                        "docker create --name=plex --net=host -e VERSION=latest -e PUID=$(id -u ec2-user) -e PGID=$(id -g ec2-user) -v /data/plex:/config -v /data/media/tv:/data/tvshows -v /data/media/movies:/data/movies --restart=always linuxserver/plex",
                        "docker start plex"
                    ]
                ]
            }
        }
    }
}

There's quite a bit to take in with this configuration but it's all relatively trivial. I needed my instance to be based off an image, which I provided via "ImageId": { "Ref": "PlexInstanceImageId" } - again, another parameter reference. The instance type is much the same, as is the availability zone. The parameterisation of AvailabilityZone is useful here because my EC2 Instance and EBS Volume need to be in the same place.

Naturally I wanted my instance to be publicly accessible on the Internet, so I added a Network Interface and set it to use one of the three default subnets that AWS gave me. It made sense to choose the subnet that belonged to the same availability zone as the instance and volume (I'm not sure if using another one would have even worked). I also referenced my Security Group and Volume.

For security purposes, I also defined the KeyName, which references an EC2 Key Pair. I generated this in the AWS Management Console manually (I could have used the CLI but I figured this was just as good) and downloaded the generated .pem file. This would later be used to allow me to SSH in to my instance.

I could have stopped there and that would have been enough to have a fully functional EC2 Instance, but it would have been an empty shell, with nothing running in it. That's where the UserData section came in.

The UserData script runs when the instance initialises for the first time. It can include pretty much anything you want/need to finalise the deployment of the instance. In my case, I needed firstly to check the integrity of the attached volume by seeing if it was formatted. If not, then I made it an ext4 filesystem. Then I could create my data folders and mount the volume to the corresponding mount location (/data/media). After ensuring the directories have the right permissions, I added a mount line to fstab and proceeded to install Docker.

The final thing to do before attempting to deploy this bad boy was to grab our Plex image and start it up in Docker. The command is no different to how we'd ask anyone to run our containers, with the slight exception of how I obtained the PUID and PGID of the instance's user (which is defaulted to ec2-user).

-e PUID=$(id -u ec2-user) -e PGID=$(id -g ec2-user)

I did all of this manually but AWS also provides a template builder to help you visualise the stack you're creating. Here's what my very simple stack looks like:

If you'd like to see the script in full, I have uploaded it here.

Deploying!

Now I can finally put this on AWS! It only took me about 13 hours of research and scripting (mostly because I kept getting things wrong; yay for trial-and-error). It would have probably taken me about half an hour to do it all manually but I'm an idiot and like to over-complicate things in the name of science (and boredom).

I went back to the CLI and used the following command to deploy my stack:

aws cloudformation create-stack \
    --stack-name PlexMediaServer \
    --template-body file://C://Users/Amudhan/Desktop/awsplex.json \
    --parameters ParameterKey=PlexInstanceType,ParameterValue=t2.micro ParameterKey=PlexInstanceImageId,ParameterValue=ami-d7b9a2b1 ParameterKey=AccountVPCId,ParameterValue=<MY_VPC_ID> ParameterKey=AccountSubnet,ParameterValue=<SUBNET_2_ID> ParameterKey=AvailabilityZone,ParameterValue=eu-west-1b

After which I then went to the CloudFormation console in AWS and watched my server get created. Once it had finished deploying, I went over to EC2 and checked the status of my instance:

I could see that it was in a state of "Initializing", which told me that my UserData script was running. It took a few minutes for that to change to "2/2 checks passed".

That was it. My instance was running, the volume had been mounted, and most importantly, it had been assigned a public IP address for me to use! So, that's what I did:

IT'S ALIVE!

Configuring Plex Remotely

Now this is something that I didn't see coming.

One of the security features of Plex is that you can't just log in to the application and set up the server configuration if you're not on the same network as the application. This meant that I needed to create an SSH tunnel to my new instance and map the port locally. This was relatively easy to do.

Using the .pem file I generated previously, I imported it in to PuTTY and created a tunnelling rule:

When I then navigated to http://localhost:8888/web, I was directed to my running instance, which saw me as coming from its own local network, allowing me to start the set up process once I'd logged in:

I gave it a simple name called "aws" for the time being just to get through the setup process. I did notice that my first attempt at creating a name failed, although a second attempt passed.

Using the directory I had created in the CloudFormation script, I added a "Films" library and finished the setup process.

The final piece of configuration was to ensure that the library was being shared over the correct port, so I went to Settings -> Server -> Remote Access and checked "Manually specify public port", setting the port value to 32400.

For some strange reason, the first attempt at this failed, but another attempt (without changing anything) worked fine.

Uploading Content

Well, I had a running Plex server, which was nice, but it was no good without something to stream from it. My next quest was to find a way of getting some content to it. In the end I settled on using SFTP (with my .pem file as authentication) and transferring data directly to my mounted volume. Using FileZilla, I uploaded a couple of films to test and then scanned my library.

Performance

The real question I'm sure you'll have now is whether or not this solution is performant enough to deal with the heavy task of video transcoding and network streaming.

Video

While watching a movie, I could clearly see in the usage logs that transcoding a 1080p movie at 8 Mbps 1080p caused the CPU usage to jump to 100%. This can be problematic if it remains at this level for an extended period of time because 100% utilisation consumes CPU credits, which will eventually run out if usage is left high for too long. While this doesn't cost anything, it'll choke-hold your instance so that the credits can replenish.

The above graph shows how the CPU was happily idling until I started watching a film that required transcoding. The usage quickly shot up and remained between 90%-100% until I switched the quality level to Original, which promptly released the strain from the CPU. Usage dropped because a quality level of Original bypasses the server's need to transcode the video on-the-fly, instead opting to stream the video as-is to the client, which takes on the responsibility of transcoding instead. Below is the rate of consumption of CPU credits based on my usage:

Network

It seems that even the modest network speed of a t2.micro instance is enough to deal with streaming at least a single video to a client. For anyone sharing libraries with multiple people, it is likely it'll choke under the demand.

The network usage is interesting to observe as in this case I can see that throughout my viewing, EC2 sent out just under 750MB of data to my PC. The movie I watched is a 1GB 1080p MKV, so it's clear that Plex is quite efficient at dropping the overall file size to suit different connection speeds. This particular transfer size reflects the whole film's duration.

Cost

The last question you may now have is "how much is this going to cost me?". The answer, anticlimactically, is probably "it depends". AWS's pricing model is relatively competitive but the costs can very quickly add up, especially once you're out of the grasp of the Free Tier (which expires after 12 months).

My EC2 instance is on "On-Demand" pricing, which means that it's an hourly fixed rate, regardless of the CPU usage (credits notwithstanding). It's a pretty inefficient pricing model for something designed to always be on. Let's break it down:

1. A t2.micro instance costs $0.013 per hour*, or $0.312 per day. That's $113.88 per year. Already that's a high price to pay for something you're likely going to use maybe a few hours a day.
2. However, the caveat to this is you can just turn it off when you're not using it. So, assuming you only have it running when you want to use it - say, four hours a day - your costs drop down to $18.98 per year. That's a bit more like it.
3. If you set up a task rule in AWS to automatically shut down your instance overnight, or while you're at work, you can have it running at times you know you're going to want it, while still reducing overall compute costs.

* Pricing is in USD because that's how old my AWS account is :/

But that's not all! The instance has been costed, but we've still got the storage to think about. I used a small 20GB SSD for the sake of my test, but some people may want more. EBS does provide much larger volumes but at a cost.

AWS charges you for how much storage space you provision, not how much you use. For streaming, I believe "Throughput Optimized HDD (st1) Volumes" to be the best option as they provide a good balance of storage space and read speeds. The pricing model for EBS is a bit more confusing than EC2 because the costs are prorated on an hourly basis, but the general idea is the same:

1. EBS storage (st1) costs $0.05 per GB-month, so if we provision 1TB (1000GB) and have it attached to an instance (regardless of whether or not it's running), the monthly cost for that storage is $50.00! Utterly mental and in no way cost effective!
2. However, this is for provisioned storage, so costs can be reduced by creating a snapshot of the volume, then deleting the provisioned storage when the instance isn't running. AWS's pricing for snapshots is different as it charges for used storage, rather than provisioned. If you have only used 300GB of your volume, your monthly cost drops to $15 for the snapshot. Still a bitter pill to swallow.

So, we've established that it's the storage that's a real kicker regarding costs. The problem is, we've not even thought about transfer costs. That's right, AWS also charges for network activity!

Thankfully, AWS doesn't charge for inbound Internet -> EC2 traffic, so getting the data into the instance isn't a problem. The costs start accruing when data leaves EC2 back into the wilds of the 'net. Thankfully, the rates are easy enough to figure out:

1. The first GB of outbound traffic is free.
2. For the next 9999GB of data, the rate is $0.09 per GB.
3. The next 30TB are a tiny bit cheaper at $0.085 per GB.

So, let's say I watch a few episodes of my favourite shows on a daily basis. Each episode is roughly 1.5GB in size, and I stream at Original quality, so no change to the file size during streaming. Per day, my outbound traffic is 4.5GB, so that'll cost me $0.32 per day. That's $9.45 per month just for the luxury of streaming! Yeesh. That doesn't even account for the occasional movie.

The total monthly cost for an instance running for four hours a day, plus 500GB of provisioned storage (without snapshot), streaming around 4.5GB per day comes in at:

$1.56 + $25.00 + $9.45 = $36.01 per month

TL;DR - Is it worth it?

No. Just get Netflix.

My writing here is mostly focused on people and technology in all aspects. However, being generally interested in all sorts of subjects and thought, sometimes an idea just sticks in your head and needs to be written.

I don't know the genesis of the idea forming in my head, probably watching sci-fi shows too late (or maybe it's the exam I have in two hours), but my mind has been musing on the concept of time. Specifically, how we measure it, account for it, and place meaning on it despite a limited view of it.

The idea in my head when I'm stating limited view of time is focused on the fact that every method we use to measure time is relative. It's relative to the rotation of the earth, relative to our orbit around our sun. All the significance we place on its passage is not measured the same without this relative constant of earth.

An example to elaborate this can focus on something as core to most of us as our age. Let's say I am nearing my thirty fifth birthday, but that is still an arbitrary number based on when I was born followed by thirty five rotations of the earth around our sun. What if as humanity expands I was born and raised on Mars? Following the same relative basis I would be only half way through my eighteenth year (my current age) of existence! So does my age as a number really mean anything? How old am I, really?

One could attempt to make the argument that humanity as we know it originates from earth, and as such, any expansion we would logically still keep time based on our home world. But would we? Carry on the Mars thought. What if we're in a situation like The Expanse (interesting fact: the show is based off of these books) and Earth and Mars do not really get along, and have fought wars in the past to form very different cultures. Why would anyone born on Mars measure time as it occurs on Earth, a planet that they've never been to and maybe even have conflicts with?

The concept and thoughts are still developing and expanding even as I write, and I expect will continue to do so.

The argument holds for all measurements of time that we use. The length of a day is based on the earths rotation, and in near expansion, Mars is similar, other planets a day may be longer or shorter. The division of a day into smaller and smaller units from hours to minutes is an arbitrary and universally agreed to standard simply invented by powerful governments or religions through history.

In summary, at least for now, all of time is measured only by relative means. I'm certain quantum science or other think tank machines have and continue to dissect these concepts in significant detail. That however does not preclude my own exploration on the subject. Maybe time really is just wibbly-wobbly, timey-wimey stuff...

As I watch (a rather large subset of) my peers headed towards job interviews and starting a career; I see that a lot of them face existential crises about the relevance of their education with respect to their interests and passion.

It can take a long time to figure out what you want out of your work life; despite the amount of time invested in what seems to be an outdated "get-a-job" degree that focuses little on the parts of computer science that matter; atleast where I come from. (This is a discussion for another day.)

I watch the tribulations unfold - the degree (is supposed to have) opened up many opportunities for him, but I don't think he ever found exactly what he was looking for. Instead, he's spent years after college flitting from job to job. Although, he had nothing to complain about. He was making a great living. He was never on the market for particularly long before some new opportunity would come up. But he wasn't choosing a career path. He was letting happenstance determine what was, and what he was becoming.

At some point in your career, you have to stop floating through life like the symbolic feather.

Unfortunately, I don't think my friend ever figured out what he loved to do. He never determined the colour of his feather. But I got lucky. A few years ago I realised that what I loved to do, what I really loved to do more than anything else, was build things and fool around with computers. Seems obvious, I know, but you have the advantage of not being me. Self-awareness is a perplexingly difficult thing from here on the inside.

Life is too short to stay at a job where you're not doing the things you want to do, where you're not enjoying yourself. And yet here I was, a guy hopelessly in love with all things computer and software, working with people that considered to be a byproduct, a cost center, a necessary evil.

A  friend of mine works for a company that has experienced a mass exodus of developers. The best left first, the mid-range followed. What's left are the people who clock in 9 to 5 for the paycheck and don't take pride in what they're building. The company now has what they asked for: a team of low-level code jockeys. The people with initiative, energy, and passion have left.

Enterprises that consider developers "commodities and low level craftsmen" are doomed to have (at best) average developers working for them.

The work was interesting, but it was abundantly clear that software was not the lifeblood of this organization. Nobody was quite as obsessed with the software as I was; nobody saw it's potential to simplify, organize and streamline all the mundane tasks of the everyday routine. My passion for software, and everything around it, was clearly not shared.

I set out to change that. That's why, when I had the chance to run a small IT team; I chose to work with the people that share the same philosophy. I'm surrounded by incredibly talented people who are all passionate about software and recognize the potential it holds. Dammit, we have fun.

Joel Spolsky describes the guiding philosophy behind his software company:

Frankly, the main reason I had to start this company was to have fun at work. Working at Fog Creek is intentionally designed to be pleasant. We started the business because we wanted a great place to work, to spend our daylight hours. And we have a disturbing tendency to try to do a lot of things ourselves, especially if it's going to be fun or if we think we can do a better job. It takes us a little longer that way, but I figure the journey is the reward.

If you love computers as much as I do, you deserve to work at a company where people come to work not to punch a clock, but because they love computers, too. You deserve to work at a company where software engineering is respected. You deserve to work at a company where peers meet to enjoy building software together.

Choose wisely. And remember, this stuff is supposed to be fun.

Is your Macbook Air overheating? Here’s a technique I’ve been using for the last couple of years; works everytime. I suspect it still works on the new models – I *suspect* they have the same basic design flaws as the original, from looking at the case.

Problem: vents in wrong place

Those vents along the rear underside of the case … don’t work. I don’t know how they ended up there, but I suspect it was a triumph of “looks” over “not breaking the expensive laptop” (until Apple patched OS X, just running Flash was enough to cause OS shutdowns on a regular basis).

Solution: What to not do

Don't hurry up and listen to what everyone says. Read the rest of this before you decide to throw away good money on yet another snake oil solution such as:

• Cooling pads
• Ventilated stands
• Height increasing suction cups (yep, confused me just as it did you)
• Cooling fans
• Cleaning services
• Fan upgrades

The Real Solution: assume launch position…

Grab your MacBook, hold it at the hinge (so the lid doesn’t slam down and switch the laptop off), and tilt it towards you 90 degrees.

i.e. the keyboard half of the laptop should be vertical, resting on the long, bottom, edge.

The vents now vent air straight up – unimpeded – instead of down-and-out (impeded by the case itself).

This brilliant technique also works for most other laptops as well!

Result: fast cooling

I can usually get my Air that’s been running “hot” (fans very loud and noisy) for minutes / hours to cool down in under 60 seconds using this technique.

Why does this matter?

Well … once an Air is cool, it tends to stay cool. i.e. it’s crap at bringing it’s own temperature down, but it’s got enough oomph to *keep* it at whatever temp is current. So, manual intervention fixes the problem.

Super-fast cooling (a.k.a. “PANIC!”)

What do you do if your Air starts beeping?

(hint: this is the never-actually-explained-to-you hardware warning that “your CPU is about to melt. Cool it down NOW or buy a new laptop”. I wonder how many people realise what’s happening when they hear that screeching, high-pitched beep and think “WTF?”)

As above, only shut the lid too.

This may seem counter-intuitive – after all, this will reduce the air-surface of the Air by about 50%, reducing it’s ability to cool down.

In practice, although that’s true at low temperature, at high temperature the heat is already concentrated in the top-left corner of the keyboard (where the CPU sits) – and most of the case is too far away to help.

In practice, closing the lid causes OS X to suspend processes, which normally takes enough load of the CPU that the laptop / hardware is able to cool itself MUCH faster – but only if you’re holding the whole laptop vertically, with the vents pointing upwards.

I’ve found this normally cools my Air from “max fans” to “silent” in under 15 seconds.

As I’ve evaluated contradicting opinions in different areas of software engineering and development like bootcamps vs college degrees, this framework vs that, or a MacBook Pro butterfly keyboard vs an 1850’s typewriter, I‘ve found an analogy that helps me make decisions. It boils down to one central idea:

Your life is an open source project, and you are its maintainer.

Hear me out through a few parallels:

• Just like open source software benefits from a roadmap, having life goals with specific dates coerces you into improving
• An open source code of conduct is like your individual values and morals that dictate your behavior
• Being frugal in what is added to a project’s API is sort of like saying no to that bowling league your friend wants you to join

When it comes to how the roadmap is outlined, how the code of conduct is established, and what changes are made to the API, the buck stops with the maintainer(s). Along the same vein, what decisions you make in how to develop and grow are ultimately up to you, the maintainer.

You’ll be presented with amazing opportunities and everyone else will chime in with an opinion as to what you should do, but only you have the context necessary to answer them.

Because great open source maintainers tend to also be great people (which I don’t think is coincidental), I want to outline why I think planning, building, and maintaining a great open source project relates to developing a great life.

Plan

Just like with open source, you need to start with a plan, and you have a community of individuals that have a vested interest in what you do. They’ll sometimes have great advice and they’ll sometimes have this advice:

What other people suggest you should do might not align with what vision you have for the future at all!

Have a Roadmap

Good open source software will have a roadmap that outlines a timeline of what will be developed next, and by what dates.

From a code standpoint, right off the bat and no matter what you’re working on, you should prioritize your goals. What is most important to do next? Sometimes what is important may not be what is exciting. Maybe being able to edit your spreadsheets in VR can wait while you refactor that code you wrote years back when you thought float: right !important was a good idea.

With expectations from life, set goals, give yourself deadlines, and then be accountable. Sometimes the most rewarding feelings come from abstracting away the simple chores like paying bills. You’ll start feeling like your own psychotic fitness coach and you’ll save yourself ₹1200/month for the gym membership.

Then with unfailing resolve, the evangelists of all things new-and-improved will come knocking at your door expecting to you to bend to their demands.

“We need support for Rock Band Guitars if this library is going to be used!” they’ll say.
“This is a string parsing library.” you’ll respond.
“Who’s going to use that without Rock Band Guitars?” they’ll retort.
“Sorry AFK” you’ll reply.

Prioritize attention to items on your roadmap, and be ready to filter out noise from the periphery.

Have a Code of Conduct

Open source projects often adopt a code of conduct that contributors must abide by to work on the codebase. Take a code of conduct from a popular project out of the context of software and you’ll often find it’s still relevant. One open source code of conduct gives these points to follow:

• be friendly and patient
• be welcoming
• be considerate
• be respectful

If you squint your eyes and slowly move your head away from your monitor you can almost see the bullet points above forming the text of the Sermon on the Mount from the New Testament.

Consider adding similar characteristics to your personal code of conduct and then commit to live by it.

Nobody enjoys being around a negative Nelly (except other negative Nelly’s). Welcome diversity, make new friendships, spread optimism, and extend the positive reach of open source. Just like people are drawn to projects that are accepting and welcoming of newcomers, people will be drawn to individuals that are friendly and start opening doors for you if you treat them fairly.

Adopting guiding principles like these also mitigate your individual contribution to the dumpster fires of unhelpful Reddit and HackerNews threads (a noble cause indeed).

Build

To actually make an open source project, you probably need to know how to code [citation needed].

Learn a thing or two and keep iterating!

Learning and Development

The services your project offers should be important to you. Will your app offer a broad variety of functions, or do just a few things particularly well? Will you be Samsung and crank out 45 subpar phones every year, or be Apple, do the iPhone and own it?

Like me, I’m sure you’ll encounter articles with titles like “200 Free Courses you can Start Today” or “Why you should learn X”. There is an overwhelming wave of content, and no one has the time to absorb it all. Technologists and developers are hard-pressed to always be learning and adopting new technologies and trends, but it’s hard to know what to do next. You’re going to have to make decisions about what you ignore and what you choose to specialize in.

Making the colossal mountain of content more approachable is the concept of the anti-library from Nassim Taleb. In his book The Black Swan, he tells the story of Italian writer Umberto Eco:

He is the owner of a large personal library (containing thirty thousand books), and separates visitors into two categories: those who react with “Wow! Signore professore dottore Eco, what a library you have! How many of these books have you read?” and the others — a very small minority — who get the point that a private library is not an ego-boosting appendage but a research tool.

Read books are far less valuable than unread ones.

This concept is related to the vast expanse of tutorials and blog posts that live online. The greater the unread content, the greater potential for learning.

If there is something that a tutorial can be written for, you can probably find it. Dora the Explorer could probably even find it, and she has to have 6 year olds point out where the banana tree is to her.

Decide what you want to learn and go learn it, but don’t feel crippled by not knowing, your anti-library (these days, Google) could be one of your finest assets.

Individual Growth

Ralph Waldo Emerson famously said:
"The height of the pinnacle is determined by the breadth of the base."

This can be interpreted to mean how high you are capable of growing is first determined by how well grounded and strongly rooted your core values are.

If you want to become an expert, start by rooting yourself in fundamentals and even developing simple traits like perseverance and diligence. Being really good at something can often be boiled down to simply working hard and managing your time well.

A big part of marketing for an open source project is the organic growth from maintainers helping users resolve issues while using their libraries. Being helpful and supporting others using their project starts to become a part of who they are, and it feeds into loads of people wanting to use their libraries as a result.

I believe if you just start becoming a good person — no matter what you do — people will want to work with you.

Maintain

As a library grows, it’ll (hopefully) see contributions from the community supporting it more, and the question of how the project moves forward becomes more complex.

Similarly, as you become more and more capable throughout your career, more and more opportunities will surely present themselves and give you even more choices. If you haven’t started establishing a roadmap you’ll find it even harder to turn down that freelance WordPress gig someone on LinkedIn reached out to you about.

Learn to Say No

Because decisions only get more complicated with time, it can be especially important to learn to say no.

David Heinemeier Hansson wrote:

Use the power of no to get your priorities straight. Take the brief discomfort of confrontation up front and avoid the long regret down the line.

You won’t have time to meet everyone else’s edge case, so you have to prioritize. A maintainer will have to disappoint someone, and it’s easier to articulate a message that disappoints if you have a roadmap in writing already.

In the recent movie Christopher Robin, the story follows Christopher who has become over-absorbed in his work such that his family begins to feel distanced from him. Christopher Robin struggles as his work becomes his first priority, but his family is what he values most.

Christopher gets advice from an uncharacteristically wise plush bear

During one scene, innocent Roo has the following pointed exchange with Christopher while he’s away from family, referring to his briefcase he always carries with him:

Roo: What’s a Madeline? Is it more important than your case of important things?

Christopher: Madeline’s my daughter, so, yes, of course. Absolutely. She means the world to me.

Roo: Then why isn’t she with you?

If work is what you value first, then taking on more work will likely be valuable to you. However, if you are like 91.6% of respondents to the World Values Survey (hi! 👋), then you very likely put your family first too.

Work is likely also “Very important” or “Rather important” to you according to the results of the survey, but these results demonstrate the general prioritization of family as one of the most valued categories.

Refactor and Simplify

Time to work on open source doesn’t come free. Perhaps you’ll find the silver bullet of time management one day, but until then resist the urge to rewrite everything on a blockchain.

Dead code is dangerous to keep around, keeping it in repositories means more to maintain and more potential to break things. Similarly, the more responsibilities you are balancing between family, career, religion, and health means more to manage and more that can stress you.

A popular analogy about work life balance being similar to juggling glass and rubber balls demonstrates the necessity of simplification in personal growth. The balls represent different responsibilities in your life. If you drop a rubber ball you can pick it back up no problem, but glass balls can shatter when dropped. You decide which responsibilities represent glass balls and which represent rubber balls — as well as how many of them you are juggling at any given point. If you need to let something drop, dropping a rubber ball can be more easily recovered from. Decide what your glass balls are and focus on keeping them in the air.

According to Bruce Lee:
"It’s not the daily increase but daily decrease. Hack away at the unessential."

Developers worry about cutting bundle sizes so small they could fit through a coffee straw. Have you ever considered the bundle size comprised of all the priorities you’re balancing in your life? If cutting bundle sizes makes the web experience faster and smoother, perhaps removing some fluff from the edges of your life could do the same for it.

Measure your Growth

Everything scales, and so does your influence.

As a library grows and more users adopt it maintainers get stretched thinner and thinner trying to meet the needs of a growing community of users.

Some species of bamboo demonstrate how difficult it can be to measure growth, but also the importance of being strongly rooted. Some of these species of bamboo can grow at astronomical rates of 4cm (1.6in) an hour. It’s easy to watch peers and friends around you growing at those speeds and wondering what you are doing wrong. That kind of growth is possible because bamboo can take a long time to get established where it’s planted, and your current growth might be more focused on your roots, which is okay too.

The visible signs of growth come in time. Your metric of choice to keep track of progress on your goals might be obfuscated by all sorts of other variables, but trust that your impact will still be there.

Do you just want better Wi-Fi in every room? Consider buying a Plume or Google Wifi or other similar plug-n-go mesh system. On the other hand, are you a technically proficient network kind of person who wants to build an enterprise-lite configuration at home? Do you dream of VLANs and port profiles and lovingly tweaked firewall rules? Does the idea of crawling around in your attic to ceiling-mount some access points sound like a fun way to kill a weekend? Is your office just too quiet for your liking? Buy some Ubiquiti Unifi gear and enter network nerd nirvana.

There is a moment of perfect stillness after the cable slips through my fingers and vanishes back up the hole in the ceiling like an angry snake. Then the opening stanza of a rich poem of invective leaps from my lips and my mom stares up at me from below, eyes wide, frozen just as I am, ready to catch me if I rage too hard and lose my balance.

But perched precariously on the top step of an inadequate and shaky ladder in the corner of my living room, drenched in sweat and speckled head to toe in dust, body aching with dull red heat, I just can’t maintain the torrent of swearing. I’m too tired. The words die on my lips and I drop my burning arms to my side. Sweat stings my cut hands—“man hands", hands that seem to always sport an ever-changing collection of cuts and dry spots and calluses and torn nails as house or computer projects come and go. Tiny drops of blood ooze from shredded cuticles.

Maybe I’ll just stand here for a few hours and not move, I think, mind going blank rather than face the thought of climbing back up into the baking attic and fishing out the cable from underneath mountains of insulation. Maybe I don’t even need Wi-Fi anymore. Maybe I don’t even need computers anymore. Maybe I should throw away everything I own and live in the mountains and grow my own food and never think about technology ever again.

But let’s back up a bit.

What was going on

In mid-2015, I retired my rats-nest of random routers and repeaters and upgraded my home’s Wi-Fi with a set of wireless access points from New York-based networking company Ubiquiti. I was trying to accomplish two things: first, to eliminate some persistent Wi-Fi dead spots that I just couldn’t reach, even by extending my network with a couple routers and repeaters. Secondly, and perhaps more importantly, I wanted some new homelab gear to tinker with so that I could get some hands-on time with an enterprise grade (or at least “enterprise-lite” grade) Wi-Fi system, because playing with the big toys is fun.

The Ubiquiti access points delivered on both points. The individual devices weren’t even particularly expensive—strategically placing a few of the APs can be cheaper than buying a single monster consumer-grade AP/router. The monster consumer router can (usually) deliver higher single-client performance in synthetic benchmarks, but the distributed Ubiquiti APs are far better at delivering consistent multi-client performance (and they’re not all bottlenecked behind a single backhaul, either).

More importantly, having multiple access points means that instead of having to take a “make my one base station scream as loud as possible” approach to whole-house coverage, you have the opportunity to fine-tune each individual AP’s 2.4GHz and 5GHz radio strengths and channel selections to create a series of interlocking cells that together offer vastly more consistent coverage—especially in the 5GHz range, which is almost certainly where you want your wireless clients connecting whenever possible.

As it turns out, this kind of network tuning is a lot like sailing: it’s relatively easy to learn the fundamentals in an afternoon, but mastering it probably takes more time than you’re willing to commit unless you just really freaking love sailing. Or screwing around with your Wi-Fi. (Or, alternately, you can get paid to do it at your job.)

"I will admit that configuration mistakes were made."

The upside, though, is that I learned a lot by screwing up so much, and the only person I hurt was myself. Well, and the family, whenever my weekend tinkering sessions resulted in no Wi-Fi for a few hours. This piece is intended to let you laugh at my mistakes as much as anything else.

Unifi my Wi-Fi

Ubiquiti makes all manner of stuff, ranging from wired gear to full-on heavy-duty WISP equipment. I became interested in the company’s Unifi line of Wi-Fi networking primarily because of the price—the gear seemed exceedingly cheap for the capabilities it offered, especially considering how the access points stacked up against consumer offerings.

There’s more to the Unifi product line than just wireless access points, though—it’s at this point a vertical that includes switching and routing, too, using hardware adapted from Ubiquiti’s more mature EdgeMAX line. Unlike Unifi, EdgeMAX kit isn’t centrally managed (well, sort of, but no.). EdgeMAX is meant to be standalone, used for enterprise switching and routing, without the software defined special sause exclusive to the Unifi line.

Flying too close to the sun, repeatedly

After being lured in by the price, I quickly decided I wanted Unifi APs in my house because of the huge amount of cool stuff they’d let me do. Being a sort-of-nearly-sysadmin, and although at the time I've never been in charge of administering the guts of a large network, I picked up the ins and outs of enterprise network administration through countless collaborations and hallway conversations over the years.

From that sprung grand designs for my home WLAN: I didn’t just want to set up Wi-Fi with a guest network—that’s so pedestrian. No, I wanted to emulate the things I used to have at work. I wanted multiple segments and VLANs. I wanted to sequester my IoT crap on its own little isolated chunk of space. I wanted complex packet filter rules. I wanted WPA2 Enterprise Wi-Fi, with cryptographic certificate-based client authentication via RADIUS that I could control and revoke, rather than a lame-ass WPA passphrase. I wanted metrics, deep packet inspection, intrusion detection, charts and graphs and data everywhere. I wanted something to play with.

I eventually got all of these things, and more. But the biggest takeaway from my still-ongoing Unifi experience is this: enterprise networking gear in the home is a drug, and you can overdose.

It’s easy to add Unifi access points—addictively so. They’re not terribly expensive, and if you’re like me, you can over-plan your deployment because no one who knows any better is there to stop you. Much like with heroin, it’s pretty easy to go too far—sure, you can buy five APs to cover a 2600-square-foot house, but you probably shouldn’t. Which is how I found myself on a ladder in my living room, caked in sweat and attic filth, questioning my life choices and sanity. (Past Amudhan, if you’re somehow reading this article via some kind of space-time vortex or causality loop, please pay particular attention to this section.)

“I want to set up a bunch of VLANs” is a great weekend project to dream about. It’s nowhere near as great when it’s 3am and you’ve broken everything and you can’t go to bed until you at least get the Internet working again.

“I’m going to set up freeRADIUS” sounds like a worthy way to spend some quality time with your servers. It’s a little different when Chrome crashes because you have too many tabs open because you have to keep looking up new arcane error messages because setting up freeRADIUS is actually more complex than building a 1:1 scale reconstruction of St. Peter's Basilica out of matches and tin foil. (It’s still easier than setting up OpenLDAP, but that’s another article.)

“I can mount a fourth AP right there and push 5GHz into the bedroom” sounds simple enough, until it’s six hours later and you’ve almost fallen through your ceiling four times and you can’t stop bleeding from your forehead from where you scraped yourself on roof nails and you’ve got dust in both eyes.

I eventually got all of these things, and more.

The freedom to choose

That sounds like a heap of bitching about the gear, but it’s not, not really—it’s bitching about my dumb choices. More to the point, it’s bitching that demonstrates why enterprise Wi-Fi deployments at real companies are (or at least should be) the product of careful consideration of requirements, with a planful deployment and appropriate back-out procedures to follow in case things don’t go how they should. When I’m at work, I do those things. But when I’m at home, I do what I want—and then I have to face the consequences for being crazy.

So, now that I’ve done with the bitching, let me state this unequivocally: I am thrilled with how well my Unifi setup works, and I love having it. I love the look on visitors’ faces when they see my guest Wi-Fi login page. I love finally having solid Wi-Fi coverage in every nook and corner of the house and backyard. I love the security of being able to really and truly shove all the IoT crap into its own isolated and firewalled segment. I love, ultimately, having the freedom to tinker—to do what I want, how I want, when I want, without being shackled to my ISP’s (or anyone else’s) Wi-Fi configuration whims.

Where we go from here

I like to think that I’ve finally, after more time and cost than I care to admit, achieved homelab nerd nirvana. But who’s kidding whom? Scratching the urge to tinker is not unlike scratching a mosquito bite—you get some temporary relief, but man, the itch comes back quick.

For now, though, I think I’m done buying networking gear. The configuration I’ve landed in checks a whole hell of a lot of boxes—available optical or copper 10-gigabit Ethernet, fast 5GHz Wi-Fi in every room, and a reasonably secure network with appropriate client segregation. The cost wasn’t inconsiderable, but it wasn’t that over the top—creating a similar setup with another OEM’s components would likely incur similar or higher cost if I were going for near-absolute feature parity.

If it’s not clear by now, I really, really like my Unifi gear. It’s always possible that in a couple of years I’ll rip it out and try something else—gotta scratch that itch, after all—but at least for now, I’m pretty damn happy.

The Good

• This is the Wi-Fi setup I’ve always wanted.
• AP pricing is, for the most part, excellent and makes the gear extremely accessible.
• Extremely in-depth Wi-Fi options for exact cell size and performance tuning.
• Single pane of glass is elegant and easy to use.
• AP integration with switches and router via SDN makes complex config tasks incorporating both wired and wireless gear extremely easy.
• Products are in active development and new features regularly appear.

The Bad

• You need to know what you’re doing because it’s easy to overcomplicate your setup. (Note: I might not know what I’m doing.)
• Current USG product lineup is problematic if you're not at the high-end.
• Controller software required for that SDN goodness.
• You will need to spend time planning and configuring to get the most out of this gear—plug-n-go is possible, but full functionality requires work.
• Wireless uplink is still, in my experience, not reliable enough for production use (but your mileage may vary).
• The Wi-Fi side is great, but there’s an annoying lack of GUI-exposed features on the routing and switching side.
• If all you care about is single-host raw Wi-Fi speed in benchmarks, you can do better elsewhere.
• Homelabbers or folks obsessed with the perfect setup might spend more money than they’re comfortable with once the Unifi gear gets a foot in the door.

The Ugly

• The reality is that you probably don’t need this at home. I know I don’t. But “need” and “want” are very different animals.

Lately I've been delving into the WordPress ecosystem, as it seems to be the most popular CMS platform around at the moment. I've built several sites with it so far. In the process, I've gotten quite comfortable with the setup, interface, and overall operation of WordPress.

I've been thoroughly impressed with the community around WordPress, and the software itself is remarkably polished. That's not to say that I haven't run into a few egregious bugs in the newest release, but on the whole, the experience has been good bordering on pleasant.

Or at least it was, until I noticed how much CPU time the PHP FastCGI process was using for a modest little website.

This is an incredibly scary result; this website is getting, at best, a moderate trickle of incoming traffic. It's barely linked anywhere! With that kind of CPU load level, this site would fall over instantaneously if it got remotely popular, or God forbid, anywhere near the front page of a social bookmarking website.

For a bare-bones site which is doing approximately nothing, this is a completely unacceptable result. It's appalling.

As evidence of what a systemic problem this is, there's an entire cottage industry built around shoehorning better caching behavior into WordPress. Take your pick: WP-Cache, WP-Super-Cache, or Bad Behavior. The caching add-ins don't work very well under IIS because they assume they're running on a *NIX platform, but they can be coerced into working.

Does it work? Does it ever. Here's what CPU usage looks like with basic WP-Cache type functionality enabled:

I'm not alone; just do a web search on WordPress CPU usage or WordPress Digg Effect and you'll find page after page of horror stories, most (all?) of which are solved by the swift and judicious application of the WP-Cache plugins.

It's not like this a new issue. Personally, I think it's absolutely irresponsible that WP-Cache like functionality isn't already built into WordPress. I would not even consider deploying WordPress anywhere without it.

A default WordPress install will query the database twenty times every time you refresh the page, even if not one single element on that page has changed. Doesn't that strike you as a bad idea? Maybe even, dare I say it, sloppy programming?

I understand that users may have umpteen thousand WordPress plugins installed, all of which demand to change on every page load. Yes, the easiest path, the path of least resistance, is to mindlessly query the database every time you're building a page. But I cannot accept that a default, bare-bones WordPress install hasn't the first clue how to cache and avoid expensive, redundant trips to the database.

It's frustrating, because caching is a completely solved problem in other programming communities. For example, the .NET framework has had page output caching and page fragment output caching baked into ASP.NET for years.

I sure am glad I started this blog with Ghost, but I shudder to think of the number of times the Failed Machine web server would have been completely incapacitated by the naive -- no, that's too tame -- brainlessly stupid dynamic rendering approach WordPress uses.

What I just don't understand is why, after all these years, and all these documented problems, WordPress hasn't folded WP-Cache into the core. If you're ever planning to have traffic of any size on a WordPress blog, consider yourselves warned.

Just a few days before this post; a friend pointed out that the Query Cache is extremely important to performance, and for some reason it defaulted to off (zero size) on my installation. You may also want to look into innotop and mysqlreport to ensure that all your MySQL caches are functioning at appropriate levels. It is badly needed.

As my role at the South Indian Model United Nations grows increasingly more complex, I draw parallels with yet another excerpt that a fellow redditor posted:

I was part of a team writing an web-based job application and screening system (a job kiosk the customer called it) and my team and our customer signed on to implementing this job kiosk using Windows, Apache, PHP5, and the ZendFramework -- everyone except one of our team members, who I will refer to as "Joe". Joe kept advocating the use of JavaScript throughout the technology deliberation phase, even though the customer made it quite clear that he expected the vast majority of the job kiosk to be implemented using a server-side technology and all the validation should be done using server-side technology.The fact that the customer signed off on this, however, did nothing to deter Joe from advocating JavaScript -- abrasively. Every time our project hit a bump in the road, Joe would go off on some tirade on how much easier our lives would be if we were only writing this job kiosk in JavaScript. Joe would constantly bicker about how we were all doing this all wrong because we weren't doing it in JavaScript, not even bother to learn the technologies we were actually using, and, whenever fellow teammates would try and gently bring him back into the fold (usually via email), Joe would just flame the poor guy. At the height of Joe's pro-JavaScript bigotry, he would regularly belt off comments like, "Well, if we had only done it in JavaScript," to such an extent that the team would have been better off if he had just quit (or was reassigned or fired.)

After reading this story, I had to resist the urge to lean forward, hand placed thoughtfully under my chin, brow furrowed, and ask -- have you tried designing?

I first thought this story was a cautionary tale about technology dependence, but now, I see something else: a problem team member, a classic bad apple.

I'm sure "Joe" had the best of intentions, but at the point where you're actively campaigning against the project, and working against your teammates -- you're a liability to the project.

The cost of problem personnel on a project is severe, from personal experience:

If you tolerate even one person whom the other people think is a problem, you'll hurt the morale of the good people. You are implying that not only do you expect your team members to give their all; you expect them to do it when their co-workers are working against them. In a review of 32 management teams, Larson and LaFasto found that the most consistent and intense complaint from team members was that their team leaders were unwilling to confront and resolve problems associated with poor performance by individual team members. (Larson and LaFasto 1989). They report that, "more than any other single aspect of team leadership, members are disturbed by leaders who are unwilling to deal directly and effectively with self-serving or noncontributing team members." They go on to to say that this is a significant management blind spot because managers nearly always think their teams are running more smoothly than their team members do.

How do we identify problem personnel? It's not difficult as you might think. I had a friend of mine once describe someone on his team as -- and this is a direct quote -- "a cancer". At the point which you, or anyone else on your team, are using words like cancer to describe a teammate, you have a serious project pathology. You don't have to be friends with everyone on your team, although it certainly helps, but a level of basic personal and professional respect is mandatory for any team to function normally.

Here's an outline of a few warning signs that you're dealing with a bad apple on your team:

1. They cover up their ignorance rather than trying to learn from their teammates. "I don't know how to explain my design; I just know that it works." or "My rationale is too complicated for you to understand." (These are both actual quotes.)
2. They have an excessive desire for privacy. "I don't need anyone to review my work."
3. They are territorial. "No one else can fix it. I'm too busy to fix them right now, but I'll get to them next week."
4. They grumble about team decisions and continue to revisit old discussions long after the team has moved on. "I still think we ought to go back and change the design we were talking about last month. The one we picked isn't going to work."
5. Other team members all make wisecracks or complain about the same person regularly. Team members often won't complain directly, so you have to ask if there's a problem when you hear many wisecracks.
6. They don't pitch in on team activities. On one project I worked on, two days before our first major deadline, a teammate asked for the day off. The reason? He wanted to spend the day watching a new movie that had just come out in a nearby city -- a clear sign he hadn't integrated with the team.

Let me be quite clear on this point: if your team leader or manager isn't dealing with the bad apples on your project, he/she isn't doing her job.

You should never be afraid to remove -- or even fire -- people who do not have the best interests of the team at heart. You can develop skill, but you can't develop a positive attitude. The longer these disruptive personalities stick around on a project, the worse their effects get. They'll slowly spread poison throughout your project, in the form of design, code, relationships, and contacts.

Removing someone from a team is painful; it's not fun for anyone. But realizing you should have removed someone six months ago is far more painful.

As my formal education in computer science progresses, I have now discovered an unexpected relationship between coding and writing.

There is perhaps no single greater way to articulate and delve deeper into one's thoughts than writing. It's one of those essential feelings you discover in high school or college, and then spend the rest of your life wondering why people waste time using other less-efficient forms of media to get their point across.

This is all well and good if you plan to become a writer, but what's the connection between this timeless little book and writing a computer program?

Writing programs that the computer can understand is challenging. That's why so few people, in the big scheme of things, become competent programmers. But writing paragraphs and sentences that your fellow humans can understand -- well, that's even more difficult. The longer you write programs and the older you get, eventually you come to realize that in order to truly succeed, you have to write programs that can be understood by both the computer and your fellow programmers.

/*Code Readability*/

if (readable()){
    be_happy();
}else{
    refactor();
}

Of all the cruel tricks in software engineering, this has to be the cruelest. Most of us entered this field because the machines are so much more logical than people. And yet, even when you're writing code explicitly intended for the machine, you're still writing. For other people. Fallible, flawed, distracted human beings just like you. And that's the truly difficult part.

I think that's what Knuth was getting at with his concept of Literate Programming. (link to a pdf)

The practitioner of literate programming can be regarded as an essayist, whose main concern is with exposition and excellence of style. Such an author, with thesaurus in hand, chooses the names of variables carefully and explains what each variable means. He or she strives for a program that is comprehensible because its concepts have been introduced in an order that is best for human understanding, using a mixture of formal and informal methods that reinforce each other.

This is, of course, much easier said than done. Most of us spend our entire lives learning how to write effectively. I'd like to highlight one (very popular) rule that I keep coming back to, over and over again; I think it serves as a helpful guidepost for great code:

Omit Needless Words

Vigorous writing is concise. A sentence should contain no unnecessary words, a paragraph no unnecessary sentences, for the same reason that a drawing should have no unnecessary lines and a machine no unnecessary parts. This requires not that the writer make all his sentences short, or that he avoid all detail and treat his subjects only in outline, but that every word tell.

What does this say to you about your writing?About your code?
Coding, after all, is just writing.

How hard can it be?

Before I begin, I've given this topic a fair bit of thought; and at the expense of welcoming controversy and haters; here goes.

It's been just over a decade since the launch of the first industry-changing eBook reader - The Kindle in 2007.
So why aren't we all using eBooks already?

I adore words, but let's face it: books suck in a lot of ways.

More specifically, so many beautiful ideas have been helplessly trapped in physical books for the last few centuries.

How do books suck? Let me make a list:

• Books are heavy.
• Books take up a lot of space.
• Books have to be printed.
• Books have to be carried and shipped in trucks.
• Aren't always available at a library.
• Must be purchased at a bookstore.
• Difficult to find
• Books are difficult to search within.
• Some books are too expensive.
• Books aren't interactive.
• They cannot be updated for errors and addendums.
• Books are often copyrighted.
• The worst of them all: Books can go out of print entirely.

What is the point of a bookshelf packed with books other than an antiquated trophy case of amazing ideas, trapped in awkward, constantly-deteriorating, temporary physical relics?

I've now convinced myself that books should not be celebrated. Words, ideas and concepts should be celebrated. Books were necessary to store these things, simply because we didn't have any other viable form to contain them. But now, we do.

Words Belong on the Internet

At the risk of stating the obvious, if your goal is to get a written idea in front of as many human beings as efficiently as possible, you shouldn't be publishing dead-tree-books. You should be editing a wiki, writing a blog, or building a website.
That's exactly why Encyclopedia Britannica officially went out of print in 2012, after a 244 year print run.

In a straight-up battle between paper and web, Britannica lost. Big time.
This is why book scanning efforts of The Internet Archive and libraries around the world are so important - to unlock the knowledge trapped in those books and place it online so the entire world can benefit.

In the never-ending human quest for communication, bits have decisively won over atoms. But bits haven't completely replaced atoms - Yet. That will take a few more decades.

An Argument for the eBook

While the Internet is perfectly adequate for basic printed text juxtaposed with images, videos and tables, it is a far cry from the eye-catching, beautiful, complex layout and typography of modern books.

Sometimes, the medium is part of the message. That's what led computer science to create PostScript and TeX, systems of representing the printed page using code and mathematics that can scale infinitely - packaging written content as a special file format preserves those beautiful layouts so you can read the text as the author intended.

It's also fair that writers should be paid for their work. Nobody is going to pay a rupee for every webpage. The commercial model of packaging content into a book and selling it has existed for longer than most people would admit.

You can't always rely on the Internet being available. What if you have a bad/unusable connection? You could periodically download what you need as a packaged file. Local files have built in, persistent offline availability.

I don't think the Internet will kill the book. But it will radically transform their form permanently. Books will no longer be pages printed with atoms; but rather files printed with bits: eBooks. This is already apparent in the fact that most writers these days use a computer to write their books - instead of pen and paper; why not publish the same way as well? Right?

The Problem with using Bits

The journey of migrating from atoms to bits is not easy, and we're only looking at the beginning of this journey. eBooks are vastly more flexible than printed books, but they come with their own set of tradeoffs:

• They require a reading device
• eBooks cannot be loaned to friends
• Cannot be resold to others
• You can't really donate an eBook to a library
• Copy protection
• They might come in a format that your eBook reader doesn't understand
• Incomplete, obsolete or broken page layouts
• They may have low resolution images that are worse than print
• They may have a substantially worse reading experience than print except on very high resolution reading devices.

I'd say that the copy protection is the worst of them all. With eBooks, book publishers now have an unprecedented level of control over when, where and how you can read their books.

In the world of atoms, once the book is shipped out, the publisher cedes all control to the reader. Once you buy that physical book, you can do whatever you will: read it, burn it, and here's a popular one: photocopy it (for personal use), share it, resell it, loan it, donate it, use it as a monitor stand (guilty as charged) and even throw it at a burglar's face as a weapon.

In the world of bits, the publisher has an iron grip over their eBook and it isn't sold to you as it is "licensed for use", maybe even only on their specific devices (ahem...Kindle). And they can silently remove the book from your device at their whim.

In the brave new world of eBooks, publishers are waking up drunk with new power. And I can't say I blame them. After an eternity of publishers having virtually no control over the books they publish, they've now been given near total control.

How much do eBooks cost?

Consider one of my favorite books, Don't Make Me Think. How much does it cost to buy, as an eBook or otherwise?

Amazon print - ₹450
Amazon eBook - ₹475
Publisher print - $45 (which is ₹3150 at the time of writing)
Publisher eBook - $36 (which is ₹2520 at the time of writing)

Strangely enough, the Amazon eBook is more expensive than the print version. This...makes no sense. How can bits in the digital version, that require no printing, no shipping and no physical storage whatsoever, be more expensive than the atoms?

And what do eBooks look like?

Don't even get me started on this one. What you end up reading when you buy an eBook can vary wildly. And here's where you'll understand why it's worth buying the publisher's version of the eBook.

Here's a a couple of scanned pages from my copy of the book:

If you buy the eBook from the publisher, you get a PDF which is based on the exact, same data used to print the book. The footnotes, layout, typography and text are almost completely left intact. It's almost like a scanned copy of a physical book.

Buy the eBook from Amazon however, and you're presented with a proprietary eBook format which contains very little (or none) of the original formatting. Footnotes are missing. Font colors and styles are lost. And for the strangest reason, it now take 4 pages to read one page worth of content from the print book. It's almost as though the pages of the book were broken.

So eBooks suck as well, now what?

I intentionally chose a book that highlights the remaining gap between atoms and bits. I've read dozens of other eBooks and the experience is great. For books that are entirely text, with very little layout, the various eBook formats do a great job. This is the majority of books in the world.

All eBook formats handle text and basic fonts perfectly fine. But then, so does the Internet. If an eBook can't outperform the Internet at layout, it loses the strongest argument in it's favor.

Even so, there's no way that Amazon's version of eBooks are suitable replacements for the print version. Worse, you won't even know what you're missing out on until you compare it with a print version.
That's disappointing.

We, as readers, are giving up just as much as we're getting in the transition from books made of atoms to eBooks made of bits. To make it worthwhile, I think publishers and resellers (like Amazon) need to do two things:

1. eBooks should be inexpensive. I can't lend them, I can't resell them, I can't buy a cheaper used copy, because I can only read them on all "supported" (basically their own) readers under whatever terms the publisher will allow me to, an eBook simply has less utility and value to me. Right now, eBooks are far less flexible than physical books and therefore a worse value. Yet, they are far cheaper to produce and sell for everyone involved. The pricing absolutely has to reflect this. If I can get a new copy of a book for less than the eBook, no sale and screw you.

2. eBooks should be a near-perfect replica of the print book. With the advent of high-resolution displays; it's possible for eBook readers to have high visual fidelity - almost just as good as the print book. I don't want to spend money on an overpriced eBook reader with a crappy display and pay extra for a worse, broken reading experience. Give me an eBook that I would be confident in handing to my children with the same confidence my dad gave me his.

Why?

Because I love words. I want to love eBooks. I want to buy lots and lots of eBooks. But unless the publishers are willing to treat eBooks with the same respect and care they give to printed books - and most of all, adjust their pricing to reflect the new economy of bits and not the economy of atoms - they're destined to eventually suffer the same fate as Encyclopedia Brittanica.

I'm fast approaching the end of the first semester of my CS course at college and it seems to me that the whole "everyone should learn programming" has gotten out of control. Nearly every course has to have a programming class - even the ones that don't seem to benefit from it whatsoever.

Definitely a great step to improve technological awareness; although if a person designing buildings actually needs to commit JavaScript code to do his job, something is deeply, horribly, terribly wrong with the methods people use to design buildings. The education definitely seems to be at fault here.

10 PRINT "I have no clue why I need programming"
20 GOTO 10

Fortunately, the odds of something like that happening - even in jest are near-zero for good reason. Designers and creators will hopefully spend their time doing real work instead. To those who argue programming is an essential skill that everyone should learn, right up there with reading, writing and math: can you explain to me how an aerospace engineer would be better at his day to day job of designing better airplanes if he woke up one morning as a crack Java coder? It's obvious to me (and you) how being a skilled reader, writer and basic high-school math are fundamental to the job of an engineer. Or any job for that matter. But understanding variables, functions, pointers and recursion? I can't see it.

Look, I love programming. I believe it is important...in the right context, for some people - probably a computer person. But so are a lot of skills. CS students aren't forced to learn how to analyze structural stresses. In fact, I would no more urge everyone to learn programming than I would urge everyone to learn plumbing. That'd be ridiculous, right?

"If we don't learn to plumb, we risk being plumbed ourselves...plumb, or be plumbed."

The "everyone should learn to code" movement isn't just wrong because it falsely equates coding with essential life skills like reading, writing and math. I wish. It is wrong in so many other ways.

• It assumes that more code in the world is an inherently desirable thing. In my experience, I have found this...not to be the case. Should you learn to code? No, I can't answer that for you. You should be learning to write as little code as possible. Ideally none.
• It assumes that coding is the goal. "Non-programmers" like to think that software developers and programmers are addicts who just write code. But it's not. Their job is to solve problems. Don't celebrate the creation of code, celebrate the creation of solutions.
• It puts the method before the problem. Don't get me wrong. I love computers - they are the single most powerful tool in solving problems. But that's exactly what they are - a tool. Before you go rushing out to learn to code, figure out what exactly you're going to solve. Do you even have a problem? Have you researched it and it's possible solutions? Does coding solve that problem? Are you sure?
• It assumes that adding naive, novice, not-even-sure-if-they-like-this programmers to the workforce is a net positive for the world. I guess that's true if you consider that one bad programmer can easily create two new jobs a year. The truth is, there are few great programmers out there.
• It implies that there's a thin, easily permeable membrane between learning to program and getting paid to program. While programming is an egalitarian field where degrees and certifications are irrelevant in the face of experience, you still gotta put a lot of hours behind honing your skill before even thinking about getting paid to program.

I can support everyone learning a tiny bit about programming just so you can recognize when code might be the most appropriate way to solve a problem. But then again, I can recognize a plumbing problem without any prior training in the area. The average Joe could benefit a lot more from a basic understanding of how computers and the internet work; being able to navigate on the internet is becoming a basic life skill and we should be worried about fixing that first.

The tech around us has achieved Clarkian levels of magic for the vast majority of people, and most of us still don't understand how it all works. You don't learn to build a car to get your driving license; you learn to drive it.

Please don't advocate learning to code just for the sake of learning how to code. Or worse, for the promises of fat paychecks. Instead, I humbly suggest that we spend our spare time learning how to...

• Try and understand the fundamentals of how things around us work.
• Communicate with other human beings.
• Other skills that extend far beyond coding and will help you in every aspect of your life.

I recently read Letter from a Birmingham Jail by Martin Luther King Jr. and what I absolutely love about the letter – beyond the incredible emotion – is that it illustrates just how powerful of a force persuasion really is. In the hands of a madman or demagogue, dangerously powerful. It works so well that it exposes the unavoidable truth: to have any hope of influencing others, you must be able to persuade them.

An engineer that I found on Reddit - VP at a software firm, thinks of himself not as a CEO or boss, but as the Lobbyist-in-Chief. I believe that could be re-written as Persuader-in-Chief with no loss of meaning or nuance.

I was recently asked how I run our development team. I said, “Well, basically I write about something I think we should do, and if the blog post convinces the developers, they do it. If not, I lobby for it, and if that fails too, the idea falls on the floor. They need my approval to launch something, but that’s it. That’s as much ‘running things’ as I do, and most of the ideas come from other people at this point, not from me and my posts. I’ve argued against some of our most successful ideas, so it’s a good thing I don’t try to exert more control.”I’m exaggerating somewhat; of course I haven’t written about all of our ideas yet. But I do think of myself as Lobbyist-in-Chief, and I have lots of good examples of cases where I failed to talk people into an idea and it didn’t happen as a result. One person I said this to asked, “So who holds the product vision, then?” and I replied, “Well, I guess I do,” but really that’s not right. We all do. The product is the result of the ideas that together we’ve agreed to pursue. I recruit people based on their interest in and enthusiasm about the ideas and then set them loose, and we all talk and listen constantly. That’s how it works — and believe it or not, it does work.

So how do we persuade? Primarily, I think, when we lead by example. Even if that means getting down on your knees and cleaning a toilet to show someone else how it's done. But maybe you're not a leader. Maybe you're just a lowly peon. Even as a peon, it's still possible to persuade your team and those around you. A commenter summarized this grassroots method of persuasion nicely:

• His ideas were, on the whole, pretty good.
• He worked mostly bottom-up rather than top-down.
• He worked to gain the trust of others first by dogfooding his own recommendations before pushing them on others.
• He was patient and waited for the wheels to turn.

Science and data are among the best ways to be objectively persuasive, but remember that data alone isn't the reductionist end of every single topic.

If measured by click data alone, all Internet advertising should have breasts in it. Incorporate data, by all means. But you need to tell a bigger, grander, more inspiring story than that to be truly persuasive.

I believe that letter from a Birmingham jail is the single best persuasive essay I've ever read. It is remarkably persuasive without ever resorting to anger, incivility, or invective. But do more than just read; study it. How does it work? Why does it work? Does it cite any data? What techniques make this essay so incredibly compelling?

Nobody ever changed anything by remaining quiet, idly standing by, or blending into the faceless, voiceless masses. If you ever want to effect change, in your work, in your life, you must learn to persuade others.