Thoughts on “Getting Things Done”

I finally finished reading “Getting Things Done” by David Allen. This has been on my reading list for years so I am glad that I finally got a chance to scratch it off of that list. Overall, it was a good read and I learned how to approach an overwhelming number of tasks with Allen’s proven methodology.

My biggest takeaways from the book were:

  1. Get things out of your head and somewhere where you will look at them later. Big or small, short or tall, write it down.
  2. Identify what success, or “done” actually looks like right away.
  3. Identify the next step instead of worrying about the scope of a large project.

I’ve been using Kanboard to manage my day to day work for both professional and personal projects. Before that, when I was using OS X I used a program called OmniFocus which does an amazing job at allowing you to capture items from any context. Using a simple shortcut (Super + Space) it let you get things out of your brain quickly.

No other tool that I know of does this, and its a real shame because the biggest barrier to feeling relaxed about the pile of things you have to do is being able to trust that a specific item is going to be looked at again from any context. When adding a task to an app feels like work (i.e you have to go to a webpage, open an app, etc) then you may not do it.

I attempted to reproduce the magic of OmniFocus with a simple desktop app that I wrote called TaskAdder. When mapped to a keyboard shortcut (Ctrl + Space for me) it lets you add a task to your Kanboard from any context. Using this app for the last few weeks while reading GTD has changed my life.

Overall, the book was great. My only gripe is that it was a bit verbose. Many chapters repeated the same ideas, and the same examples. In addition, although these methods could apply to any human being a lot of the examples and anecdotes that Allen offers come from big wig executives who have secretaries, offices, and enough money to afford his one on one consulting work. My eyes began to roll after the third time that I was reminded to talk to my secretary (which I have never had) about helping me with my workflow.

If you don’t like reading verbose books, I still think that looking into the GTD methodology is worth doing. The main website is full of great examples, diagrams, and resources.

Argument Against an SPA

Gitlab released a great blog post describing some major changes to how they build their frontend. This mostly consists of using Vue and Webpack, which is a great workflow that I have been enjoying lately while hacking some various Laravel projects.

For example, the profile page could be potentially very light, and there would be no reason for that if someone is linked directly to the profile page; it should load every single piece of Javascript in our project.

Unlike pretty much every other large project, they are not currently making an SPA (single page application). Their reasoning is solid and is one of the best argument against using an SPA that I have heard yet.

I think they have the right idea. The magic of javascript (with vue and webpack) coupled with the speed of “traditional” apps seems like a winning strategy.

Resources for Humans

I do 10 1:1s per week, after reading The Hard Thing about Hard Things, I took a look at some of the suggestions that Ben Horowitz gives for how to run 1:1’s effectively and am still working on improving the process for my own team.

I started reading some of the resources on the Lattice website and they are really great!

I love the title “Resources for Humans”.  They provide a great guide on Why 1:1s are important and how to run one and also have an excellent section the defines what OKRs are.

Looking forward to seeing more great resources from the Lattice team.

Standard Notes is a Better Project than Braindump

I released braindump to the world last year to much fanfare. After the initial excitement from being on HN died down, and the PR’s stopped rolling in, it became a personal project once again with very few users. Over the last few weeks I have made several attempts to fix the spaghetti mess that is the current code base by refactoring the current Flask implementation, then rewriting it completely in Django, and even started a branch to investigate rewriting the whole app in PHP using Laravel. Other commitments took precedence and Braindump remains in a fairly usable but not that special state.

Today on HN I read about a new project called Standard Notes which is the most exciting note related project that I have seen in a long time. It solves so many of the problems around cross platform compatibility that plague many other note tools. In addition its goals are to create a standard file format for simple, secure, and durable notes. Even more it has already created a platform, an ecosystem, that allows anyone to come and create additional applications, plugins, and use cases for notes.

These are some of the problems that I set out to tackle when I started braindump. After reading about Standard Notes, and using it for a few hours, I have decided that my time would be better spent contributing to that project instead of continuing to work on Braindump.

Working on Braindump has been amazing. I learned a ton, became a better programmer, and most of all had a lot of fun. I want to thank everyone who tried it, provided feedback, and sent patches. The source code for braindump will remain on GitHub but I would encourage you to try and contribute to the Standard Notes project along with me.

100% Uptime*

I have been a customer of Vultr on and off since March 2015. I have been running a VPS (Virtual Private Server) server on one platform or another since 2011 and I spent some time working in operations for a large VPS provider. In addition I briefly started my own VPS service last year. My experience with Vultr has been mostly good. Their support is responsive, service is mostly stable, and aside from a few expected hiccups related to abuse on a shared host, things have been great. Recently while browsing their home page I noticed that they offer a 100% uptime SLA.

I was pretty intrigued by this. My previous experience has led me to believe that achieving a true 100% SLA is practically impossible. Hosting is a frustrating and difficult business where something will always go wrong and there are way too many variables beyond any one companies control to be able to promise 100% uptime. So I thought to myself, what is Vultr doing that no one else can?

Well, based on my most recent interaction with their account management team, the short answer is “Nothing”. As far as I can tell this 100% Uptime* guarantee is just a marketing ploy that is intended to make Vultr look like a great value without actually being one in the same way that mail in rebates (remember those?) made things seem very cheap until you had to actually go through the process of sending in the rebate and hoping that the return check actually arrived.

Recently I got the following email from Vultr:

We have detected a system issue with the node hosting the instances listed above. Our engineering team applied system updates and scheduled a brief maintenance window to perform a node restart. Date and Time: Jan-13-2017 11:00 UTC (Jan-13-2017 03:00 Local Time) Please note: This event will reboot your affected instances. Your data and configurations will not be affected by the reboot.

There is nothing surprising here. If you have had a VPS turned on for more than 90 days from pretty much any VPS provider in the world you have probably received a very similar email. This seemed like a great opportunity to put their 100% uptime SLA to the test. The server in question runs about a dozen websites served by Apache, MySQL, and Redis. When a server reboots most of these services come back online thanks to systemd without any user intervention. However, I always like to double check that everything is up and running after a reboot so this means that I needed to be awake at 3AM to check to make sure that the server was in good shape.

The total downtime was less than 5 minutes (awesome!) and everything came back online without incident (double awesome!). According to their SLA chart I would be eligible for 12 hours of credit. I opened a ticket (on Saturday morning) and asked how the SLA process worked. I was informed that this question had to be answered by a member of the account management team and they would get back to me on Monday. No worries, totally get that, I thanked the support engineer for their time and waited patiently until Monday.

This morning I get the following email from their account management team:

If you experience any disruption in service that is not scheduled maintenance you would have to open a ticket to request SLA credit. Further information can be found here:
https://www.vultr.com/legal/sla/

I read the linked content and a couple questions immediately popped into my head.

In order to receive any credit offered under this SLA, You must initiate a support ticket related to the event AND expressly request that We issue a credit. DO NOT ASSUME THAT WE ARE AWARE OF YOUR OUTAGE. Your outage may be wholly unrelated to Vultr’s services, so unless You contact Us via a support ticket, We may not be aware any problem exists.

Why are they yelling at the customer? How can they possibly “not be aware that any problem exists” when their marketing page says “our engineering team utilizes active monitoring to proactively detect problems and take preventative measures, minimizing any impact failing host node hardware could have on your environment.”

If Vultr needs to perform scheduled maintenance on your node, this is exempt, unless of course it takes us more than 10 minutes!

In what universe is 100% – 10 minutes (or any number for that matter) = 100%?

In accordance with the procedure outlined below, you must initiate a support ticket and request that a credit be applied to your account. Merely initiating a support ticket related to an outage will not result in any credit to your account.

Why?

The most important questions that I had were why couldn’t the support team send me that link and why isn’t there an asterisk next to the 100% SLA on the marketing site?

To be honest, I could care less about the actual reimbursement. The server itself costs a trivial amount of money per month, and the downtime was not that disruptive to me. The thing that really makes me frustrated is this deceptive and seemingly marketing driven SLA copy. Its makes me feel that I cannot in good conscience recommend this service to anyone else. If you are going to make such a grand claim as a 100% SLA you should either live up to it (which includes not making the customer jump through hoops in order to use it) or not make these types of promises at all.

Outstanding Tutorial on writing GTK+ 3 GUI Applications with Python

GUI programming has always been a black art to me. The idea of event-driven applications with an endless infinite loop listening for events boggles my mind a bit and runs counter to my traditional understand of what algorithms look like.  This is something that I struggle the most with Javascript (which has the benefit of having most of the details abstracted away by the browser), and something that I have never been able to quite grasp using traditional GUI tools like GTK, Qt, and even .NET.

The trend these days is to just use Electron. It seems like more and more apps (Slack, WordPress, Ghost, Postman, Visual Studio Code, etc.) are drinking the cross platform cool aid. I read this article which discusses some of the negative aspects of choosing Electron as a GUI framework. Drew makes some great points and the following paragraph inspired me to once again take a stab at actually learning a proper GUI framework.

Learn how to use GTK or Qt. Maybe Xwt is more up your alley. How about GNOME’s Vala thing? Learn another programming language. Learn Python or C/C++ or C#. Fun fact: it’ll make your JavaScript better, and once you have it in your toolbox you can make more educated decisions on the appropriate tool to use when you face your next problem.

Source: Electron considered harmful – Drew Devault’s Blog

PyGObject (aka PyGI) is the new way of developing GTK+ 3 GUI applications in python. On Ubuntu, installing the python3-gi package is enough to get started making your application “do something”. I found an excellent tutorial on using PyGI which does a great job explaining both basic and advanced concepts.

This tutorial gives an introduction to writing GTK+ 3 applications in Python.

Source: The Python GTK+ 3 Tutorial — Python GTK+ 3 Tutorial 3.4 documentation

In addition, this tutorial also has a section on how to use Glade, which is a GUI tool for building GUIs. For any substantial project hard coding the UI is going to get old pretty quickly.

The Python GObject Introspection API is massive. It solves a lot of common problems and also lets you work with a lot of existing GNOME applications. Looking forward to making something useful soon.

An Ode to Linux Desktop Users Everywhere

Here’s to the crazy ones, the misfits, the rebels. The package makers, the man page writers. The rounded windows in Qt mixed with the less rounded windows of GTK. The ones who literally see things differently because of missing proprietary fonts.

They’re not fond of rules, installation wizards, double clicking and have no respect for the status quo.

You can downvote them, disagree with them, glorify or vilify them. About the only thing you cannot do is ignore them. Because they ship your bug fixes.

They invent. They imagine. They heal. They explore. They create. They inspire. They push the human race forward.

Maybe they have to be crazy. How else can you stare at an empty screen and know that you have to blacklist your video card driver? Or sit in silence while tweaking alsamixer on the command line? Or write bash aliases to reload your network driver kernel module each time your laptop resumes from suspension? We make tools for these kinds of people.

While some may see them as the crazy ones, we see genius. Because people who are crazy enough to think that they can run Linux on the desktop, are the ones who change the world.

Amazon LightSail: Simple Virtual Private Servers on AWS

Amazon introduced LightSail today in a move that might signal the slow death of “Cloud Hosting Providers” such as Digital Ocean, Vultr, and Linode.

Blast off with Lightsail; Everything you need to jump start your project on AWS—compute, storage, and networking—for a low, predictable price.

Source: Amazon LightSail: Simple Virtual Private Servers on AWS

Users of these services have historically been frustrated by AWS’s unpredictable pay as you go pricing that can at times reach astronomical rates. A good example is network transfer; the other day we moved a 120GB image from one server to another data center and it cost upwards of $17 for the transfer itself. This would have been free on the lowest plan of any other smaller cloud hosting provider.

You can check out an excellent run down of LightSail on the Linux Academy Blog.

LightSail is somewhat competitively priced, but Linode and Vultr are both still better deals for now. I think this is great from a competitive perspective. Smaller companies will need to up their game in order to compete with Amazons mind and market share. I am looking forward to seeing how this plays out.

 

Getting Started with Laravel on Ubuntu

I’ve really been digging Laravel lately. Especially due to the wonderful documentation and amazing resources provided by Laracasts .

Below are some notes on getting going on a local Ubuntu install. I am running Ubuntu 16.10 and these notes assume a fresh install.

Install PHP 7.0 and additional dependencies

sudo apt install php7.0 php7.0-zip php7.0-mbstring phpunit

Install Composer (Globally)

curl -sS https://getcomposer.org/installer | php
sudo mv composer.phar /usr/local/bin/composer

Install the Laravel CLI (Globally)

composer global require "laravel/installer"

Add globally installed composer commands to the PATH

Add the following to the end of your ~/.bashrc file

# Add Composer to the PATH
export PATH=$HOME/.config/composer/vendor/bin:$PATH

You can either source the ~/.bashrc file or open a new terminal window.

Verify everything works

You can do this by running laravel new test_project. Then go to the directory where the new test_project is created with cd test_project. Once you are in the new project directory install all local dependencies with composer install and then run it with php artisan serve.

I ran into an issue right away that had to do with the APP_KEY. The error manifested itself as:

The only supported ciphers are AES-128-CBC and AES-256-CBC with the correct key lengths.

A great explanation is shown here but the steps to get a fully functional base install going are:

# Copy the .env.example file to .env
cp .env.example .env

# Generate App Key
php artisan key:generate

Now if you run php artisan serve you will see a fully running Laravel app. Happy Hacking!

Polarr; Professional Photo Editing on Linux

One of the most frustrating things about being a desktop Linux user is that a lot of software is either:

  1. Half Baked, Buggy, and Free
  2. Half Baked, Buggy, and Completely Overpriced
  3. Unavailable

This is why I was so pleased when Aosheng introduced me to Polarr. This app is written in Electron and is a very simple and powerful tool. As I continue to make abundantly clear, I am not an artist, designer or photographer. Despite this, I keep taking a ton of photos during my adventures and I need a tool to edit them with.

On Ubuntu the choices are either to use the built in Shotwell app which is just OK. You can fumble through GIMPs incomprehensible menus and feature sets, or you can move sliders around in darktable. I don’t mean to poke fun at these tools. I truly appreciate all of the hard work that has gone into developing them, and I am certian that for a professional designer who actually understands what they are doing they are worth learning. But for someone like me, who just wants to click a button and make a photo not look awful nothing on Linux comes close to Polarr.

I love how Electron has made creating cross platform desktop applications completely painless. I think it allows application developers to enable Linux support by default and opens them up to a huge and often overlooked market.

Polarr is free to use with a basic feature set, and you can get the full version for an astonishingly low price of $9.99. If you do anything with Photos on Linux, go buy this right now.