Once an organization transitions from a start-up to a more mature business, it often finds that its software development velocity stalls when it tries to add new features or attempts to refactor problematic code. This is because without solid, automated tests developers don't know if they've broken existing behavior.
Management then tries to ameliorate the crisis by prioritizing automated testing. Because higher-level end-to-end (e2e) testing promises more test coverage per line of test code written, it's often pushed as a silver-bullet. However, e2e testing comes with serious drawbacks. In addition, decision makers often overestimate the potential for e2e testing to find bugs, and underestimate the value of other types of automated tests and quality assurance strategies.
This post aims to describe some broad categories of automated testing and clarify why we write automated tests in the first place, so that developers and managers can make wise choices in implementing a testing strategy that works.
Continue reading "It’s the Journey, Not the Destination"
A recursive function solves a problem by solving smaller instances of the larger problem. It does this by calling itself with different parameters until a base case is reached, and the function simply returns vis-à-vis a non-recursive expression. Recursion is most commonly used to traverse data structures with indeterminate depth, such as multi-dimensional arrays and trees. However, it can be used to solve most any problem that is more typically solved with iteration and mutation (albeit with reservations).
Continue reading "Recursion"
Go is a newer-generation (2009) multi-purpose programming language developed by Google to address the challenges of software-development at-scale and concurrent programming.
The most well-known projects written in Go are Docker and Kubernetes, but many other essential cloud-native tools are also written in Go, including Terraform and influxdb.
Continue reading "Golang: a Python Killer?"
Most apps consume secret data (e.g. API keys, database passwords etc.). We explored managing configuration in the first part of this series using configmaps. However, configmaps are meant
for storing non-sensitive configuration data because they are unencrypted at rest and usually are set by a yaml file, which would likely be checked into source control.
Continue reading "Kubernetes Secret Management"
In this second post of my Exploring Kubernetes series we're going to make our k8s development environment less onerous. The code can be found here.
There's continuing debate whether you should local k8s development at all. One camp says that you should develop on a remote cluster in order to mimic production as much as possible. While this has merits, there are two big disadvantages to remote development: cost and availability.
Continue reading "Local Development in Kubernetes"
With cloud native and microservice architectures gaining traction, Kubernetes (k8s) has become the standard tool for managing deployments. But what is it, do I need it, and how do I most effectively get started with it? That's what this post aims to clarify.
I'm no k8s expert. I've been picking it up because I'm interested in the devops space and because I see the problem domain it solves in my daily work. I've found the best way to learn something is to simply start working with it. Even better, is to write about it, as writing reinforces what you learned. If you can't explain something clearly, then you don't really understand it.
In this series of posts we'll develop a basic expressjs server, use k8s to develop locally and deploy it to a production environment. We'll take it step-by-step. After the first post we'll have an expressjs server running and be able to deploy it via k8s to a development environment. In further posts we'll explore local development, secret management, production clusters and stateful components, like databases.
Continue reading "Exploring Kubernetes"
We rely on abstractions to make sense of the world. Your dog is not really a "dog." There's no such thing. The word is a generalization for a group of entities that share a similar genetic make-up. But it's easier to just say, "dog," and we all understand because we generally agree on the things the word stands for.
Continue reading "Abstractions"
A dilemma often faced by professional programmers is whether to work with what they have, or start fresh when inheriting others' code.
They say it's easier to write code than to read it (especially other people's code). Why is this?
- Unless the code is perfectly readable, it's challenging to put yourself in someone else's head.
- Every project has context and baggage that is often not documented.
- As a new developer you have the luxury to be a critic. The former developer had deadlines to meet, family crises etc. You will also, soon enough...
Continue reading "Evaluating an Existing Tech Project"
Continue reading "The Essence of Functional Programming"