Blog - Airspeed Consulting

There is Such a Thing As Too Much Sharing

bowl of tomatoes served on a person's hand — Photo by Elaine Casap on Unsplash

As we grow our application portfolio, we soon discover common bits of code used by two or more applications. Often our first reaction is to break these common bits out into shared libraries. If you’re still using an application server, you might even put these libraries in the server itself so other applications can pick them up. After all, why repeat yourself? Certainly there are situations where that makes a lot of sense. Improved application startup time is one benefit. But not always. Sometimes these shared libraries actually hinder your team’s ability to deliver working software. Here I’ll explain why there is such thing as too much sharing.

Share this:

Make Your Code More Readable With Functional Programming

by Brian Schalme

Woman reading a book while seated on a black leather couch — Photo by Seven Shooter on Unsplash

I had heard about functional programming since Java made it available in 2014 with the release of version 1.8 of the JDK. I had been to several user group meetings where the speakers spoke glowingly of pure functional languages such as Scala and Haskell. It sounded promising, but I didn’t give it much thought until around 2018. That’s when I started seeing Java Streams being used more often in code examples. Recently, I was writing a simple integration solution, and the resulting code looked horrible. That’s when I gave functional programming an honest try. To my amazement, it indeed made my code cleaner. I’ll share my experiences with you and show you how you can make your code more readable with functional programming.

Share this:

Choose the Simplest Git Workflow For Your Team

by Brian Schalme

screenshot of a Git graph — Photo by Yancy Min on Unsplash

Git has become the ubiquitous source code management since its introduction in 2005. Along the way, a number of branching strategies (“workflows”) have evolved. As with anything in software architecture, there is no one right way to do anything; it all depends on context. In this post I’ll describe three common workflows to help you choose the simplest Git workflow for your team.

Share this:

Get Organized With a Simple Development Approach

by Brian Schalme

bicycle leaning on an organized shelf — Photo by Roman Mager on Unsplash

As a software development team grows and adds more members, what worked with one or two people no longer works as effectively. The team realizes they need to set up some sort of standard process for developing software. It need not be complicated, just a lightweight process will do. All they need is a way to get organized with a simple development approach. Here is what has worked well for my teams. Adapt it according to your team’s circumstances.

Share this:

The Further You Go the More Those Relationships Matter

by Brian Schalme

Two people shaking hands — Photo by Cytonn Photography on Unsplash

The other day I read a Pluralsight article titled Leadership guide: Your first 60 days as a CIO (registration required), and it made me think. While relationships are a big deal for CIOs, they also matter for everyone in IT. They matter to varying degrees based on your job role; nevertheless who you know and how well you know them makes a difference in your job and your career. Here is why I think in your career or your business, the further you go, the more those relationships matter.

Share this:

Control Your Deployments With Feature Flags

by Brian Schalme

Control your deployment with feature flags

Application deployments have usually meant deploying a new version of an artifact to Production, with stops along the way in Test, Staging, etc. All the new features and bug fixes become active when you deploy this new version. Although you’ve thoroughly tested the application with automated unit tests, functional tests, load tests, and performance tests, you’ve only reduced the risk of something going wrong in Production. If and when something does go wrong, you may need to rollback to the previous version. But what if the fix wasn’t as dramatic as a rollback? What if you could revert the one mis-behaving feature? Even better, what if you could select which features to activate? In this article I’ll explain how you can control your deployments with feature flags.

Share this:

How to set up a Continuous Delivery Pipeline

by Brian Schalme

Man in green t-shirt and blue denim jeans holding brown cardboard box

Suppose your client or your employer comes to you and says “We need you to help us understand how to set up a continuous delivery pipeline.” They assure you they are committed to the goals and benefits of Continuous Delivery, also known as Continuous Integration/Continuous Deployment (CI/CD):

The software development teams want to reduce deployment risk.
They like the idea of frequent small deployments during the workday instead of huge deployments once or twice a year.
Teams no longer want to dedicate a full weekend to a massive deployment, with all the attendant stresses and risks that brings.
The business is less tolerant of waiting months before they see even the smallest change; they want a faster time to market.

They have acquired all the tooling, and all they need is your guidance and leadership for how to set up a continuous delivery pipeline.

How would you approach this? What sequence of steps or phases would you use? In this article I’ll present some of my thoughts and suggestions.

Share this:

How to Design an Effective REST API

by Brian Schalme

Two people touching each others finger tips

History of Representational State Transfer

Roy Fielding coined the term Representational State Transfer (REST) in his 2000 doctoral thesis Architectural Styles and the Design of Network-based Software Architectures. In essence, he argues an API should use the existing HTTP verbs, and it should focus on representations of business objects rather than backend implementations. An example might be to model a Customer object the way the business knows and interacts with it rather than how it’s stored on the customer database table. In this post I’ll describe how to design an effective REST API using some of the concepts Fielding pioneered.

Share this:

So What Does A Software Architect Do Anyway?

by Brian Schalme

Most software development teams have one person with the role of Architect. Small teams of one or two people may not, but someone is thinking about architecture. This person’s title may be Solution Architect, Application Architect, Data Architect or Systems Architect. For now let’s consider all of them under the collective name of Software Architect. In this article I’ll talk about the characteristics of a good architect, and I’ll explain what a software architect does. I’ll also address the evolution of the role of software architect, and where it is today. By the end I hope you’ll have an answer to the question “so what does a software architect do anyway?”

Share this:

When to use the Pipeline Architecture Style

by Brian Schalme

What is it?

The pipeline architecture is one of the most common architecture styles used in designing software systems. Also known as pipes and filters, it consists of a series of discrete steps performed in a predictable sequence. This is different from the model-view-controller pattern in a layered architecture. In this article I’ll define what it is and when to use the pipeline architecture style.

Share this: