When I attended college I observed some people around me that became satisfied with their status quo. They felt they had learned enough and that was the enough for them. They felt they knew everything they needed to know. Maybe that was hubris, maybe it was laziness, I'm not quite sure. The word I used was stagnation.

I knew I wanted to avoid at all costs. This has stuck with me to this day, but I've continued to evolve it by adding on little mental hacks and mantras as I went. I try to do what I can to keep hubris at bay because I've found it to be one of the warning signs of heading down an ill-fated path.

One of the things that's befuddled me in recent years is the concept of things that are the "best" or variations therof. In the software world one of the most …

I've spent the last 10 months working with AWS' CloudFormation service. I felt it would be useful to put my thoughts together on how I found the service to be for a small startup.

Pros

CloudFormation is great if you don't want to deal with the orchestration of your deployments. It runs over your configuration files and figures out what the delta changes are, applies them taking dependencies into account, and will also rollback if a failure occurs.

Overall, CloudFormation works well for offloading the execution of deployments.

Cons

There are a few places where CloudFormation begins to fall short for me.

The first is complexity. I'm not saying the service can't handle the complexity, but humans can't handle the complexity of the JSON that CloudFormation uses for configuration. Even a moderately complex environment can begin to clock in at thousands of lines of JSON. At that point, it starts …

I've spent the last week looking at various CI solutions. My main criteria were:

• create a flexible Continuous Delivery deployment pipeline
• ability to promote builds to various environments (QA, prod, etc)
• alerting to our team

It started with an attempt at wrangling the defacto tool, Jenkins into a usable system but that quickly proved to be an uphill battle. Overly complication configuration aside, the final straw with Jenkins was being unable to configure GitHub Web Hooks, however that capability was dependent on having GitHub configured as the authentication method for users.

That's a pretty flawed design that speaks to a poor separation of concerns; authentication strategy should not be tangled with an unrelated feature of the product. Overall, I think the legacy of Jenkins' plugin architecture is weighing it (and its users) down.

I also took a look at numerous open source competitors to Jenkins as well as SaaS-based solutions …

I'm a huge fan of keeping code complexity to a minimum. Note that I'm distinguishing code complexity from system complexity. I believe you can have a complex system built on simple code. In fact, that's what you want because such code is highly testable.

We've all run across examples of complex code: a class with too many concerns, a function that's doing too many operations, or an abstraction in a place where it's unnecessary.

A few days after his passing, I watched a video of Jim Weirich of Rake fame giving a presentation on the concept of connascence. I highly recommend you watch it if you're unfamiliar with the topic.

This topic really hit on one of those things that I'd previously vaguely categorized as a "code smell." Code that's highly coupled makes for painful points when you have to change a behavior in the overall system. It's nice to …

A few days ago I was trying to integrate the twitter-bootstrap Grails plugin into an app but was having difficulty getting the less sources to play nice with the lesscss-resources plugin.

It turned out that the most recent version of bootstrap used LessCSS syntax that is only available in the 1.3.3 version of the lesscss compiler. The lesscss-resources depends on version 1.3.1, so to work around that issue you can update your BuildConfig.groovy settings to the following to force a specific version of the lesscss compiler:

grails.project.dependency.resolution = {
    dependencies {
        runtime ('org.lesscss:lesscss:1.3.3')
    }
    plugins {
        compile(":lesscss-resources:1.3.1") {
            excludes "lesscss"
        }
    }
}

I've spent some time this weekend working on an entry for Mozilla's Dev Derby. You can find my entry hosted on the competition site. This is my first entry so please, go ahead and vote for it.

I also noted today before I submitted my entry that I'm not the only one who thought to make a clock. It's interesting to see our our visuals, animations, and implementations differ.

How I Did It

I've this entry available as a GitHub repo so you can browse the source yourself.

I wanted this to be a relatively quick weekend project and fun to do. A requirement of the competition is for it to work across various browsers, so I started with Sass and Compass to deal with generating a lot of the yuck that comes with browser specific code (particularly vendor-prefixed CSS). Sass was also very useful in generating the animations. Just …

This is my first time playing with building a Jekyll-based site for GitHub Pages. In the past I've used Wordpress and then Posterous, but with obvious recent events that wasn't going to be good for the long term. I honestly only ever wrote a single "First Post" on posterous, because I didn't have any personal investment in the site.

I had previously got sick of the maintenence around Wordpress (not to mention the PHP) and moved to Posterous for simplicity. I feel Jekyll/GHP balances my desire for simplicity with my need for control when I need it.