About Adam Young

Once upon a time I was an Army Officer, but that was long ago. Now I work as a Software Engineer. I climb rocks, play saxophone, and spend way too much time in front of a computer.

Docker without sudo on Centos 7

I have been geting prepped to build the OpenShift origin codebase on Centos 7.  I started from a fairly minimal VM which did not have docker or Development Tools installed.  Once I thought I had all the prerequisites, I kicked off the build and got

Cannot connect to the Docker daemon. Is the docker daemon running on this host?

This seems to be due to the fact that  the ayoung user does not have permissions to read/write on the domain socket.  /var/run/docker.sock

Continue reading

Adding External IPs for Minishift

In the interest of simplifying the development and deployment of Kubevirt, we decided to make sure it was possible to run with minishift.  After downloading and running the minishift binary, I had a working minishift cluster.  However, in order to deploy the api-server to the cluster, I needed an external IP;  otherwise I’d get the error:

Error: service "" is invalid spec.externalIPs: Forbidden: externalIPs have been disabled

Here is how I got around this error.

Continue reading

Jury Duty

I spent the past six work days in a courthouse as a juror.  It was a civil case, involving a house repair after a burst pipe flooded it. Verdict went in at around 3 PM (Aug. 2) 

There is so much you don’t know on a jury. You can only consider the evidence placed before you…and sometimes you have to forget something you learned before the witness reacts to the word “Objection.”

It was a construction case, and, despite having grown up as the son (and sometimes employee) of a construction contractor, they chose me anyway. I don’t think it colored my reasoning anyway.

Based on this incomplete information, we had to award money to one or the other; doing nothing was, in effect, awarding money to the client who had not paid.

While I did not agree with the other eleven people on the jury about all of the outcomes (there were several charges both ways) I was very thankful to have all of them share the burden of making the decision. I can only imaging the burden carried by a judge in arbitration.

On the other hand, in arbitration, the judge can do research. We couldn’t. We had to even forget things we know about construction (like you postpone work on the outside to get the people back inside) if it was not presented as evidence.

I was very thankful to have my dad to talk this over with afterwards as he has fifty plus years in the construction industry. He clarified some of my assumptions (based on the incomplete information I gave him) and I think I can let go of my doubts. I can sleep soundly tonight knowing I did the best I could, and that, most likely, justice was served.

The number one thing I took away from this experience is, with anything involving contracting, or money in general, is to get everything in writing, communicate as clearly as possible. Aside from covering you for a future lawsuit, it might help prevent that lawsuit by keeping the other person on track. Run your business such that someone else could step in and take over from you, and know exactly what you were doing…or you can hand over what you want to a brand new contractor and they could take over. Obviously, that is a high bar to clear, but the better you do, the better for all involved.

Constructor Dependency Injection in Go

Dependency Injection

Organization is essential to scale. Compare the two images of cabling a data center:

A well organized wiring approach to the data center.

One of the less egregious cabling systems.

Obviously, the top image appears much more organized. I don’t think it is accidental that the better organized approach is visible in the larger data center. In order to scale, you need organization. If you have a small number of servers, a haphazard cabling scheme is less likely to impact your ability to trace and fix network problems. Such an approach would not work for a million-node data center.

The same is true of code. Without many of the visual cues we use to navigate the real world, tracking code can be very difficult. Thus, code can degenerate into chaos as fast or faster than physical devices. Indeed, the long standing name for poorly organized code is “Spaghetti Code” which is an analogy to the same kind of linear mess we can visualize with the network cables.

Dependency injection provides a tool to help minimize the chaos. Instead of wires run across the data center direct from one machine to another, the well organized scheme routes them to intermediate switches and routers in a standardized way. Just so, dependency injection provides an mediator between components, removing the need for one component to know the approach used to create the specific instance.

The guiding rule is that dependency injection separates object use from object construction.

Constructor Dependency Injection

Of the three forms of Dependency Injection that Martin Fowler enumerates, only the constructor form enforces that an object always meets its invariants.   The idea is that, once the constructor returns the object should be valid.  Whenever I start working with a new language, or return to an old language, I try to figure out how best to do dependency injection using constructors.

I have a second design criteria, which is that I should continue to program exclusively in that language.  Using a marshaling language like XML or YAML as a way to describe how objects interact breaks a lot of the development flow, especially when working with a debugger.  Thus, I want to be able to describe my object relationships inside the programming language.

With these two goals in mind, I started looking in to dependency injection in Go.

Continue reading