Category Archives: Technical



We believe that Functional Programming (FP) is going to be, and is currently, a disruptive force in mainstream programming. We want to help shape the community around that force to improve the larger software community. We will do this by building an open and safe community where newcomers and veterans can explore FP- their love of it, and how to use it to build awesome software. If you believe in this please sign up on the mailing list at

@Functcon is a #FunctionalProgramming #Conference built around a community of #safety. Click To Tweet

Our Value Statements

To promote a culture of success and safety to a growing community of functional programmers, we believe the following things:

  • Functional Programming is disruptive and will continue to be so.
  • Psychological safety is the most important thing to build a successful community.
  • Excellence in programming makes changing code safe.
  • Processes of continual improvement are necessary to achieve excellence.

Functional Disruption

Kate, my wife, and I believe very much that Functional Programming is a disruptive force in the programming industry. This old technology is seeing increasing attention as we are needing different approaches to solve today’s problems.

The simplest computers are gaining more cores and an application’s ability to use those cores determine its success. Not to mention the kinds of thoughts needed to solve the problem of analyzing the increasing mountains of data we are accumulating by the minute. These problems are a couple of examples of problems that have been difficult to solve using Object Oriented Programming (OOP) or Procedural Programming.

We see it as every mainstream OOP language starts to gain FP language constructs.  FP is appearing increasingly in podcasts. Functional Programming conferences are starting to appear and be successful with multiple hundreds of attendees.

We do not know if it will ever displace OOP, but we believe it will become as important. This means that to prepare for the future the industry will need people training in this skill set right now. The Dark Matter Developers are currently not learning this skill. You can see this by looking for accredited courses. Companies are not paying for accreditations in FP.

Dark Matter Developers are the strong majority of developers out there. That means there is currently a building skill deficit. As this skill becomes more in demand the culture surrounding that skill will become in demand. As a community, we can build a culture of success and safety.

Psychological Safety

Psychological Safety was defined by Amy Edmonson as the shared belief that a team is safe for interpersonal risk. She discovered teams that had this trait were the highest performing teams. Later Google found in their research that one of the most important traits to define a successful team was Psychological Safety.

For Functcon, we want to expand that definition from team to community. We believe by focusing first on Psychological Safety, we will build the most successful community.

Excellence in Programming

Excellence is not a word I like, as I state here. So, let me define what I mean by excellence. Excellence is the application of the most current knowledge about the best techniques and practices with understanding that the most valuable part of a project is its maintenance.

We believe by focusing on the very best of FP with this understanding of maintenance we can grow a valuable community.

Continual Improvement

It is virtually impossible to make something perfect, especially when you are dealing with a complex system. Everything you do is going to involve tradeoffs. Everything you do is going to be relevant to a given context which will move on and change under you.

So, we believe that Functcon needs to be about the continual improvement of the community, the code, functional programming, and itself. This will allow us to adapt and always remain at the top of the game.

Tying it together

If we manage to be the most successful community, with the most valuable practices, and we can adapt… Well nothing will be able to stop us. However, we don’t need to be the best to make an impact. If we even start to approach these things we will make for a better industry. Let’s do it together.

Call to Action

If you like what we are trying to do, please sign up for our mailing list. These names help us attract companies to help pay for the conference. Please tell your friends about us. Our page is And, of course, we won’t sell your information. Come hang out with us today!

I joined @Functcon mailing list. #Awesome #FunctionalProgramming #Conference Click To Tweet

The Things We Say

I want to retire certain phrases from programmer parlance.


We are not clear in what we say. We use incorrect metaphor. We choose vague terms instead of better ones. Let us trim some of the excess terminology and jargon.

We use incorrect metaphor. We choose vague terms instead of better ones. Click To Tweet

Technical Excellence

This terms vagueness is its undoing. Almost everyone I meet has a different definition of what Technical Excellence means. To some it is a synonym for Extreme Programming. To others it is learning design patterns or continuous improvement.

The above assumes that the person saying the term has good intentions. I have also heard this term used as a passive aggressive way of saying that someone is a poor programmer, by telling them to strive for technical excellence without specific feedback. Calling someone a poor programmer without giving guidance on what needs improvement is useless at best, discouraging and defeating at worst.

Instead of using technical excellence, let’s say what we mean. If that is Extreme Programming, let’s say Extreme Programming. If it is adherence to corporate coding standards, then document the standards and talk about the standards document. If we want to critique someone, take the time to critique them in a way that is helpful. Encourage growth and improvement rather than attacking.


Again, simple is an extremely vague term. What is worse is that we acknowledge how vague this term is by modifying it with: Simple isn’t easy. As if this sound byte could explain what we mean. This suffers from all the problems of “Technical Excellence” and really doesn’t say anything useful.

We spend so much time talking about making things simple and then engaging in a long conversation quantifying what we mean. Why do we do this? The term “simple” just causes confusion, debate and eventually is shortly forgotten.

It is amazing to me how much energy we spend saying nothing rather than what we mean. If we could talk specifically about the types of complexity we want to avoid, we allow for improvement. We start the conversation that moves us into a better place.

Remove confusion, add clarity and forget simple.

Technical Debt

Technical debt was a good metaphor. Past tense. It was created for a specific reason, it was to explain the causal effect of decisions to bankers. It was not created to discuss the state of the code between developers. So, let’s stop using it for such communications!

Instead of technical debt, let’s talk about Anti-patterns or Code Smells. Both have names for specific things that can be addressed. They can be researched and understood. Better yet, there are know ways to move from these potential problems to good patterns.

Lastly if we are talking about the state of code caused by a ignoring problems over a long time, then even the team “Code Rot” is better at describing what needs to be said. There is real meat in using directed language to discuss the state of a codebase between developers.

In Short

Stop being vague right now. Don’t mix your metaphors. Be clear and intentional. If there is better language that can be used to describe what you want to say, then use it. Increase your ability to be understood by thinking about what you are saying.

Stop using 'Technical Excellence', 'Simple', and 'Technical Debt'. Start communicating effectively. Click To Tweet

Let’s Encrypt AWS Lightsail with WordPress

SSL all things is a good thing, especially if you allow for user interaction. This includes clicking on links, writing comments or simply navigating your sight.


Let’s Encrypt is a free service that allows you to add Transport Layer Security (TLS) to any website for free. When you see the green padlock, this means that the sight is protecting its users from malicious scripts that inject them selves between the user and the sight. The documentation is well written but does not cover the what is needed to get it working on AWS Lightsail.

The Basics

I found this article that really describes the first half of the problem. It tells you how to enable TLS through the use of a Let’s Encrypt certificate:

What it doesn’t do is tell you how to ensure that only the encrypted version of your site is used.


The rest of this article is assuming you are in an SSH shell.

To force redirection from http to https, there are some settings you need to change and delete.

First thing is to make a backup of your configuration. This way you can recover if you make a mistake.

sudo cp -I /opt/bitnami/apache2/conf/bitnami/bitnami.conf /opt/bitnami/apache2/conf/bitnami/bitnami.conf.bak

Then you are going to edit the config file. I will use ‘Nano’ to do this as it is a reasonably friendly editor for most people.

sudo nano /opt/bitnami/apache2/conf/bitnami/bitnami.conf

Once editing you will delete lines from the file. This can be done by using the arrow keys to move to the line and then pressing Ctrl+k.

You will want to delete everything between the <VirtualHost _default_:80> and the closing </VirtualHost> tags.

You will want to replace them such that the tag now looks like:

<VirtualHost _default_:80>
ServerName [your server name eg:]
ServerAlias *.[your root domain eg:]
Redirect / https://[your sever name]

Then you will exit Nano by hitting Ctrl+x. You will be asked “Save modified buffer (ANSWERING “No” WILL DESTROY CHANGES) ?” Type a capital ‘Y’. Then when you are asked “Name of File:” just hit Enter.

Restarting Apache

Lastly you will need to restart Agache.

sudo /opt/bitnami/ restart apache

Now to test your site.


Your certificate is only valid for 3 months. So you will want to setup a Cron job to renew it.

Kerney’s Hierarchy of Good Design

Talking with a friend made me think about what I use to classify my software architecture designs as good designs and why. I realized I have a hierarchy of design I apply to every solution to rate how good of a solution it is. The more it conforms to this list the better the design is. The items at the top are more important than the items at the bottom. Not every design meets all criteria. In applying these criteria to a design I will never give up an upper item to make a design that satisfies a lower item. For example, if in removing duplication I make a class less explicit, I will not remove that duplication until I find a better design.

Here is my hierarchy, my reasons follow below:

  1. Tested Coded is better than untested code
  2. Explicit code is better than non-explicit code
  3. Non-repetitive code is better than duplicated code
  4. SOLID code is better than code that is not SOLID
  5. Uncluttered Code is better than Cluttered Code

The reasons that follow all boil down to one fact: a good design is one that is easily changed to handle new requirements or lessons about how the system should behave.

My Reasons:

A.                 Tested Code is better than untested code

I believe that code under test is inherently better designed than code which is not tested, even if it is badly designed code that is hard to read and inappropriately abstracted. The reason for this is that if the code is tested, I can change it. I have some degree of certainty that my changes do not break intended functionality.

I seldom see the correct architectural solution the first time I do some something. In fact, I seldom have it by the third. However, if I have a complete suite of tests backing me up, I can, and have, changed the architecture drastically based on new understanding and need. The architecture I choose initially seldom resembles what I end up with.

So having tests verifying that the behavior does not change is invaluable to me. It lets me ensure my solution is correct without reliance to the architecture I am using.

B.                  Explicit code is better than non-explicit code

Code that clearly states what it is doing in English, or your native language, is a better design over anything that requires interpretation of commands. If a programmer can read a method as if it was a paragraph and gain insight to its intent, than the programmer is better armed for changing that method.

Being explicit about intent reduces a large number of errors by reducing what a programmer has to keep track of in their head. The more things that someone has to juggle to understand the impact of a change the more likely that person is to make a mistake.

C.                  DRY code is better than duplicated code

DRY stands for “Do not Repeat Yourself” and is about not having duplicated lines of code. Having 100% DRY code is often impossible and striving for that is often a waste of time. However, my general rule is that removing duplication is always better than having it there. I go to great lengths to remove duplication when I find it.

The reason is that duplication often means that my code may change in unexpected ways. If one piece of logic changes and subsequent ones do not, I may not understand the full impact of my change. I may forget something and leave a lingering bug. Worse yet is this bug may take years to find.

When I have all similar logic in a single place then everything that touches that code changes every time that code does. I have a better understanding of the impact of a change. I can ensure that everything changes as needed when all the changes happen in a single place.

D.                 SOLID code is better than code that is not SOLID

SOLID is a quality of “Object Oriented Programming” defined by Robert (Uncle Bob) Martin. Any code that adheres to each of the principles is said to have the qualities that make it object oriented. Each principle has its own reason for being on my hierarchy, but the whole is here as it defines if something is actually well-behaved object oriented design.

Just as with the DRY code, it is not reasonable to expect something to conform 100% of way. But things that do adhere to these principles are better designed in my book.

1.                  Single Responsibility Principle

Single Responsibility Principle (SRP) states that any piece of code should have one and only one reason to change. If the constructor of a class changes that should not cause code using other parts of that class to change.

SRP is about appropriately isolating dependencies. It is used to measure good design because code that has the appropriate level of isolation required by SRP is easier to understand and easier to change.

2.                  Open Closed Principle

Open Closed Principle (OCP) states that an object should be open to extension and closed to modification. The heart of OCP is that if new behavior is required in the system the programmer is able to extend the base objects to get this behavior without modification of that base object.

When a design adheres to the open closed principle then it allows for easier modification that does not ripple through the system. Those changes are isolated to the new subclasses and their introduction can be controlled.

3.                  Liskov Substitution Principle

Liskov Substitution Principle (LSP) states that any class must be able to be substituted with its base class. The easiest way to explain this principle is by giving an example of breaking this principle. If square inherits from rectangle this principle is violated because some calling code may try to set the length and width separately. With a square this is not possible, but with a rectangle it is.

A design that adheres to the LSP is better than one that does not. Since LSP eliminates a large potential for bugs and the code that defends against them. Since defense code disappears the code becomes easier to understand.

4.                  Interface Segregation Principle

Interface Segregation Principle (ISP) states that no class shall accept an interface with methods on it that the class does not use. Simply put it is better to have many specialized interfaces rather than lesser numbers of generic ones.

Many specialized interfaces are better design than a less generalized interfaces as it limits the number of reasons a piece of code may have to change. If a code relies on a more generalized interface, when that interface changes, it may impact that code without reason. It also clearly divides the use cases and makes code more readable.

5.                  Dependency Inversion Principle

Dependency Inversion Principle (DIP) states that classes should not directly depend on other classes, but instead depend on interfaces.

If classes depend on interfaces instead of classes, they are easier to modify and do not change because implementation changes. Instead a change must be made to the interface for a change to affect a piece of code.

E.                  Uncluttered Code is better than Cluttered Code

There are a lot of things that clutter code. Poor formatting, unnecessary comments, bad variable naming along with a whole host of other things. Clutter confuses intent and therefore represents bad design. When code is uncluttered it is easier to understand and therefore easier to change.

F.                  Honorable Mention

An honorable mention needs to be given to design patterns. The reason why they only get honorable mention is that they into of themselves do not represent good design. Instead they are a side effect of good design.

I should probably explain what a design pattern is. A design pattern is a common way people have solved similar problems in software. If the architecture was found in a number of successful projects it is deemed a pattern.

The risk here is that design patterns are a side effect of good design not a measure of a good design. If we identify a problem that has a pattern and then we architect our solution from that pattern we run the risk of over engineering our solution.

However, if we apply the filters listed above and when we are done we notice a design pattern… Well that could be an indication of being on the correct path.

Knowing design patterns is helpful and useful. They allow us to recognize a path once we are on it. They are good for navigation during the journey. We should not use them as the goal of the journey.


These represent the measures I use for determining the validity of my designs. As a friend of mine use to say: “Everything in moderation even moderation.” I do not use these like law. Instead I use them like shading in a picture. They are applied with enough vigor to enhance what I am working on and no more.