husband, dad, steelers fan and software engineer

If you don't read anything else, check out:

SwS: I hated shaving

by Stan Lemon

Today's post on Shave with Swagger discusses why I hated shaving.  Keep an eye out, later this week Mark and I will cover "the basics" of what you need to get started wet shaving.

Against Setter Injection

by Stan Lemon

I recently read Richard Miller's post  Avoiding Setter Injection and I in large part agree with his sentiments. My conversion to constructor injection over setter injection is a fairly recent one and when I was initially deliberating the differences I found a lot of explanations online with little concrete code to show why this practice is less productive to good object oriented design. I thought I would try to illustrate with some concrete code examples I agree with Miller that ultimately constructor injection is a more worthy approach and why you should avoid using setter injection whenever possible.

First, let's consider two interfaces FooService and FooNotifier. FooService will use a FooNotifier which contains a method notify(). We have two implementations of FooNotifier the BarNotifier and the BazNotifier.  Fundamentally they do two completely different things, though they agree to the same contract.  Here's what these things look like:


Now let's take a look at our constructor injection implementation FooServiceConstruct:


And also our setter injection implementation FooServiceSetter:


The argument goes that with constructor injection you create an object with all of it's dependencies. This means that you minimize side effects caused by the dependency not being injected, or worse changing on you after your object has been created. It makes your object fundamentally more predictable. Think of it this way, this is the only way that we can use our FooServiceConstruct:


But with FooServiceSetter we can actually do a couple of things with that implementation...


You'll see that we can create a FooService that either does not work or that can have it's internal behavior completely changed out from under us.  Neither of these options is good. The alternative is that with constructor injection we have an object that stands on it's own, the functionality of which cannot be changed in runtime after it has been instantiated. If you want to avoid buggy software, make your objects predictable.

This is a simple example, but it illustrates the nature of an object that uses setter injection. It creates the potential for volatility in your object that you don't want to occur.  Now I'm not saying you should never inject via setter. There may be times that you actually want the behavior I've illustrated, however I think you will find that most of the time you simply don't want that. Subsequently as a general rule I inject by constructor unless compelled otherwise during the design of my software. I make it the exception, not the rule when writing objects.

Shave with Swagger

by Stan Lemon

I'm really excited to share a new blogging endeavor with my friend Mark Buetow, Shave with Swagger and Good morning! is our first post.  What should you expect in the future? Posts about shaving, product reviews, blade analysis and random pontifications about our honest devotion to the pleasurable indulgence of a decent wet shave in the morning.

For awhile now I've wished that Bamboo had an app, or something that could deliver a push notification when a build starts or finishes. Sure there is email, but that means my build notifications will get lost in all of the other junk I am quietly ignoring in my inbox.  What I want is a targeted notification for my builds. So I got to thinking, why not leverage Pushover?

I decided to setup some inline script tasks on one of my bamboo plans using the following code (supply your credentials accordingly), in order to give Bamboo push notifications.


Of course you can kick this up a notch by changing the message, using additional variables and throwing other notifications in at very stages of your build plans.

I use Atlassian's Bamboo for continuous integration on a lot of projects. I'm a huge fan, it's a solid product with a lot of flexibility and the OnDemand service coupled with EC2 instances and custom EBS volume make for a really robust cloud based solution to continuous integration. Almost every project I put into Bamboo involves a call to load composer and install dependencies. Many of the projects I dabble with belong to other people and so they're locked down with some form of authentication and not normally in Packagist. In the past this has created some challenges with installing my composer dependencies, but this past weekend I think I finally found a tolerable solution to my dilemma.

In addition to being a big fan of Atlassian's Bamboo I also really like Atlassian Bitbucket. I became a heavy Bitbucket user back before Atlassian bought the product because I was a heavy Mercurial user and it was the only hosted solution available. When they were bought and added git I kept using them because they offer free private repositories, whereas competitor GitHub does not. I've had problems when I develop a private package and then want to use it in an application. My workaround up until this weekend was to create a "deployment" user and give them access to my private repository, finally including it's username/password on my vas url in the repository block of my composer.json. This is all sorts of ugly and I have never been satisfied with it. In addition to not being safe or secure it also chews up one of the sacred five users you can team up with on a private repository.

So this weekend I set out to find a different approach to private Bitbucket packages in composer. One that wasn't so ugly and didn't make me feel so insecure about my setup.

BitBucket (and GitHub for that matter) have this concept of a deployment key. It's a private/public ssh key combination that grants read-only access to your repository without chewing up a user account to do so.  It's specifically geared toward the problem I was trying to solve. In my case Bamboo executes it's tasks as the 'bamboo' user.  The trick is getting the private portion of your deployment key into a place that Bamboo can use it.  Bamboo OnDemand creates EC2 instances when it needs to run a build and then terminates it after its done.  This is great because it keeps costs low and it means you don't have to worry about a machine getting gunked up with stuff between builds. It also means there's no shared state between runs, so sticking a private key on your EC2 instance only helps you for a little while.  But wait a minute... what if I set that up with a task in my job when it runs?

I wound up creating an initial task to setup my private deployment key like this:


Fortunately Bamboo lets you lock down your user's ability to see these sort of things and the logs don't show anything indicating what's going on, which makes it relatively secure - at least seemingly more so than sticking a plain text password in my composer.json file.

Now if you're familiar with Bamboo at all you know that the initial repository setup does not allow you to clone using ssh. This is limited only to the Java implementation of git that Bamboo uses to poll the repository. The default EC2 images ship with a full first class git, and so that means if you declare your package in the repositories block like "[email protected]:team/project.git" it'll use the aforementioned key and load just fine.

Life is a lot easier with an on-premise install of Bamboo where your disk persists between builds and you can set that key up permanently, but for those of us living in the cloud this will do the trick. You can use this approach on-premise too though and you can even use it with Jenkins if that's your preferred continuous integration implementation.