Author: thoean

Two kinds of batteries

There are two kinds of batteries. Those that come fully charged and can be used once. And those that come half-charged and are meant to be used many times.

I was surprised those very same approaches exist for trust.

My world view assumed that trust starts neutral (or half-charged). You do good things together, and trust builds up. And it goes down when things go bad. Once you have charged the trust battery close to 100%, projects succeed, no matter what. If it’s down to 30% or less, projects start to fail.

Recently I learned from a close co-worker, that his world view assumes full trust at the start. That is, 100% charged. Everytime the other person screws up, it goes down a bit. Never up.

It’s useful to me to understand that this other world view exists. It’s also useful for those to understand that most others think differently.

Principles

I started to develop a principles-oriented way of working. Those have paid off in my team, and I believe are applicable broader. With principles-oriented way I mean that “those are the inner believes of the team” and manifests in behavior such as “we don’t discuss about those, but this is the very nature how we develop our software”.

Here are my current two principles, easy to understand, hard to get there, but then easy to maintain and provide a true accelerator to the team by reducing errors on production software:

  1. No errors in production. True, we’ll always have errors. But we do everything to detect them early, fix them before the customer notices them, and iterate towards very stable software.
  2. Automate everything. Again, we won’t automate 100%. But my team’s cloud account has only 3 things that have been manually created (and those are fully documented). A specific outcome of that is that hitting the “merge button” on a pull request will automatically deploy a service to production (while we drink a cup of coffee, or more likely, already work on the next task).

The long-term

Imagine the following scene. You’re at the Friday after-work beer. You tell one of your co-workers about your side project. You’re excited.

Then your co-worker provides you feedback. Honest feedback. The feedback you need to get better. It’s not a confirmation or alignment. It’s a brutally honest critique to make you better. Not to make you feel cozy.

You’re destroyed. Someone isn’t in agreement with your passion.

You defend. You raise your voice. You shut down the person who provides the valuable feedback. End of conversation.

That’s the short-term. Shutting down opinions of others. Avoiding people who are not agreeing with you.

A better short-term is to listen to the feedback. Acknowledge it. Take it home. It just made you better.

The long-term however is to focus on the conversation. To build a relationship with your co-worker. To ask and listen to the excitements of your co-worker. To see the content of the conversation as a side-product while aiming for a long-term relationship.

The long-term will bring more candid feedback, honesty, and shared excitement. You wanted this to happen today. But today is not the long-term.

Reading list 2017

I was lazy the previous years. In 2017 I re-started to read a bit more regularly. It’s not a lot, but hey – here’s what I got to.

I started the year with The Outsiders: Eight Unconventional CEOs and Their Radically Rational Blueprint for Success by
William Thorndike. It is a great read to understand Capital Allocation, how some companies work within that framework, and get insight into how challenging it is, as well as understanding benefits for those who believe in it long-term.

The I moved into something more practical. Turn The Ship Around!: A True Story of Building Leaders by Breaking the Rules by L. David Marquet. It was practical and at the right time for me since the idea presented in this book was a hype at the organization I was part of. But independently of it, the book contains a lot of hands-on ideas for leaders at any level. Especially the early sections where Marquet elaborates on his failures in leadership.

Originals: How Non-conformists Change the World by Adam Grant gives insight into some success stories that are never told. He frames them in how those people had to bypass conventional methods and surprise their surroundings with their approach. He calls this group of people Originals.

The 7 Habits of Highly Effective People: Powerful Lessons in Personal Change by Stephen R. Covey is my favorite read from 2017. It influenced me a lot. It made me talk a lot about it in my family. Like the habit of Begin with the End in Mind, which asks the challenging question of what your friends will talk at your funeral. It’s a must read for those who want to think deeply of what they want to achieve in their life, and also have a framework at hand to make the first step.

Radical Candor: Be a Kick-Ass Boss Without Losing Your Humanity by Kim Scott is a reminder how important it is to give honest and useful feedback. Actually not just a reminder, but clearly giving you a lot of reasons for feedback. The verdict is, the more you like a person, the more honest and frequent should be your feedback. This helps your friends to advance.

The title says it all, I just had to get it – Finding My Virginity: The New Autobiography by Richard Branson. I already read Screw It, Let’s Do It: Lessons In Life a few years back, and Finding My Virginity continues where it left off. Typical Branson style, it’s an amusing read, but also very inspiring what a single person can achieve – from holding various world records to starting over 400 companies to becoming a good friend of Nelson Mandela.

I concluded the year with Hit Refresh: The Quest to Rediscover Microsoft’s Soul and Imagine a Better Future for Everyone by
Satya Nadella. I already admired Satya Nadella on his achievements to turn around the image of such a large company in his first months as CEO at Microsoft. The story gives insight how he achieved it. And the insights from his personal life explain a lot why he acts the way he acts.

Deploying a Single Page App to AWS S3

There are a million ways to deploy a Single Page App (SPA) to S3. However, this is a very lightway way, and is based on aws-architect.js. I don’t want to repeat the great readme of this repository, but nevertheless, some introduction.

Bootstrap the deployment

To bootstrap the deployment, run the following code:

After that, adjust package.json and make.js to only contain the S3 relevant options since aws-architect.js would also allow to create AWS Lambda based web services.

Add AWS CloudFront distribution

The most declarative way with a straight forward deployment option is to leverage AWS CloudFormation to configure additional resources, notably an SSL Certificate attached to your domain, as well as the AWS CloudFront distribution. An easy way is to add that to the deploy command of make.js, but since it’s rarely changing items, you could as well apply those manually.

First, you’ll need an AWS Certificate that can be used for AWS CloudFront later. The CloudFormation template could look like this, allowing for multiple domains, for example to deploy a test or pull request as well as the production version to the same AWS S3 Bucket:

Now we can take the ACM Certificate, and create an AWS CloudFront Distribution with it, which includes two URLs, one for production, and one for test or pull requests. In this example, it’s assumed that pull requests are deployed to S3 using a path that starts with PR. The configuration looks like this:

That’s all. Slightly painful to get the ACM Certificate and CloudFront distribution settings correctly set to your needs. But afterwards, just execute make.js as part of your build, and aws-architect.js does the rest for you.

Delete your local master

I’ve been involved in many pull requests where the pull request got discarded and re-created from scratch with a reason of “merge conflicts”. Or people taking half a day to solve “unexpected” or “weird” behavior in their git repository. While reasons are various, one pattern emerged: Most of the time people were committing to the local master, potentially pushing it and having an out-of-sync master on their fork repository, and further along merging from a branch called “master” that doesn’t represent what they think master should represent.

One of the simplest solution is to just not have a local master.

Further, besides a lot of git features that can be leveraged, I usually get along with the following commands to get the essntial branching right:

There are some repositories where I keep a local master, for example when working with forked repositories on GitHub. But even then, I only use the master to merge the latest changes from upstream, but follow the pattern described abover.

Using Nginx on Docker to redirect HTTP to HTTPS

I had a website running using HTTPS behind a load balancer, and didn’t want to bother setting up HTTP as well. Instead, I configured the load balancer to point to a very simple Nginx webserver that does nothing else than redirecting HTTP to HTTPS. So from the application side I only had to take care of HTTPS and could ignore additional configuration. As a nice side-effect, the Nginx redirection is generic so that I only need to run a single instance for all my applications.

Since I don’t need anything else than Nginx on the Docker image, I used Alpine Linux as a base and added Nginx, or more precisely the preconfigured Nginx alpine-stable docker image from https://hub.docker.com/_/nginx/. The Dockerfile looks like the following:

And the related nginx.conf file, which gets copied when the docker image is created like this:

Assuming the Dockerfile and nginx.conf are in the same directory, a simple docker build command creates the docker image which can be loaded into your docker host. Writing a simple script to include this step in your build automation should be fairly trivial, depending on your needs.

LambdaWrap blog post at LifeInVistaprint

LambdaWrapRecently, I’ve worked on LambdaWrap as part of deploying an AWS Lambda based microservice. LambdaWrap is an open source ruby gem that allows to easily publish Lambda functions and its associated API Gateway configuration during automated deployment when using rakefiles.

I got the opportunity to write a larger blog post than this note at LiveInVistaprint. The blog post “LambdaWrap, a Ruby GEM for AWS Lambda” is available at http://lifeinvistaprint.com/techblog/lambdawrap-ruby-gem-aws-lambda/.

xUnit2NUnit web service

There are various easy ways to convert one XML file into another XML file, usually through an XSL transformation. Most languages support this with little code. For example, in C# it could be something like this (simplified):

However, I decided to create a simple web service to achieve a few things. For one, to demonstrate that such repetitive code can be wrapped into a service and accessed from everywhere, for example as part of build scripts. Other reasons include that I wanted to play with ASP.NET 5, experimenting with more complex options than just request-response despite the simple use case and host the service on an Azure Web App.

The current version of the service can be found on github at https://github.com/thoean/xUnit2NUnit. It builds with AppVeyor and as part of the build, I start the web service in the background and run a very basic service level test against it (I’ve written a dedicated blog post on service level testing recently).