Programming, and all that goes with it

Disclaimer: This is by no means an exhaustive list nor should it be taken as one. This is what I chose, with a few brief reasons as to why.

Like most languages still trying to find its legs, Clojure web stacks are plentiful. Beyond the basics of Tomcat vs. JBoss (and others) you have to ask yourself should I go with Ring? What about Compojure? Maybe I want to try something more advanced an rails-like? There’s a lot to consider, and few clear winners. I’m going to declare a few here, but this is my own opinion and not necessarily the opinion of the Clojure using masses.

Before I get started naming winners I want to point out that the Clojure community is very young indeed. The language itself was written by Rick Hickey and made its first appearance in 2007 after almost three years of development. Five years is not a long time for a new language, particularly a lisp-style functional language, to build communities and toolsets.

That doesn’t mean the communtiy hasn’t been hard at work though. So let’s go bottom up.

Read more

I’ve got 99 problems but thankfully clojure dependencies aren’t one, at least not anymore.

Yesterday Clojure dependencies failed me completely, leaving me unable to load Noir, MySql or any other project dependencies using lein deps. Googling was nearly fruitless and the problem didn’t seem to be a global one. Special thanks to Kyle Gann for the solution to my problems.

rm -rf ~/.m2/repository/org/clojure/clojure/

And that’s all there is to it. Next time you run your lein commands it will retrieve Clojure and all of the dependencies you need and you’ll be good to go.

Kaizen:

Japenese for “Improvement” or “Change for the better”.

More than that Kaizen, in the agile world, is the concept of aggressive continuous improvement. Defined by the process Plan, Do, Check, Act. It is a simple, straight-forward approach to improvement that requires the acknowledgement of problems, and the willingness to act on them. Acknowledgment is the clincher though.

Read more

I like to preach language agnosticism, I believe in it with a religious fervor. But the truth is I do Ruby, I’ve done Ruby for a long time and I’m comfortable in it. It’s a structure I understand, I know the libraries the features and the communities.

So it’s time to kick myself in the ass and get on the Clojure train before it leaves the station, because I don’t want to be that guy who just knows Ruby.

Read more

RunningWithRails.com will be moving to a regular update schedule of Mon/Wed/Fri. While you’re at it please check out my new blog NovelDiscourse.com, a travel/writing blog which will feature interviews with writers and journeys to inspirational places!

I’ve decided to let everyone in on the dirty secret of software developers everywhere. It’s a fact a lot of people will have trouble believing.

What we do isn’t magic.

It can be time consuming, tedious and boring. It can also be entertaining, challenging and exciting. But very little about it is beyond the capabilities of a moderately intelligent person.

Every time I tell someone I’m a software developer they react the same way, “So you’re some kind of genius”. I don’t have the heart to tell them no.

There are software engineers who are geniuses, but that doesn’t make it a prerequisite of the job. We like to feel special, like we’re above the dirty peasants, but what we do is actually pretty simple. I’ve always thought the best analogy for what we do is language. In language you learn syntax, grammar and structure along with a list of words and phrases. Programming is a lot like that, so much so that I would argue anyone who can learn a second language could easily learn to program. Read more

Ah, and we’ve made it to another segment of this little series. Today we’ll focus on the architect, what he is, what he does and why he matters.

In some situations the architect may be replaced by a generic manager, but I will state straight out that if your manager is not/was not a developer in their career, you’re better off letting your developers fill the role ad-hoc. The architect has to be able to see all the angles, but without a strong technical background it is nearly impossible to understand the development position.

The architect ultimately makes decisions and argues the case of the development process to any interested business units. It is a particularly demanding job requiring a mix of political acumen and people skills. Read more

So far there’s a word I’ve used sparingly in this series, and have mostly avoided when I could. That word has been agile. Agile represents a huge range of skill sets, suggestions and best practices. It’s a phrase that has been bastardized by many to simply mean “We can wing it”. That isn’t what agile is about. I’ll state this very clearly, agile is about creating a workflow that can reasonably and quickly adapt to user and business needs by uncovering those needs as early as possible.

Agile does not mean “I know you just launched this yesterday, but I need you to add a few features by tomorrow”. We attempt to create a workflow, to get input and feedback in a constant loop from users, and to never need to push out features that are created under highly undesirable circumstances, such as all nighters ending in a early A.M. release.

Why? Because those circumstances suck for the code quality, the developer and ultimately for the business. Bugs are introduced, mistakes are made and sometimes tiny, hidden inconsistencies can create very serious results. The process is not there simply to make us happy, it is there to make what we produce better.

The reason for this rant is that I’ll be using the word agile a lot more in this and future posts in this series. I wanted to get that out of the way before I started.

On to the Business Analyst now. Read more

Every GUI project has a user of some sort. Whether enterprise or commercial there is always someone who, in the end, will interact with your system in a very real way. The user is the purpose of the software, and it is the user, or a user advocate, that usually gives final approve on whether or not the software does what it is meant to do.

Commercial software in particular makes use of user advocates like product specialists and business analysts. Their job is to behave for certain parts of the workflow in the exact manner that an enterprise user might behave when internal software is being built. Beyond this introduction I will refer simply to the user, which will refer to whichever is applicable to your situation.

The User Timeline:

The user is involved in nearly every aspect of the ideal software development lifecycle. By involving the user all the way through, with no long gaps in user interaction, a software team is able to take a more agile approach to development and changes.

Because of this, the user has the longest timeline of anyone, they see the start and finish of the software development lifecycle, and continue to partake in it even after most of the software team has moved on, providing information for improvements, bug reports and the like.

Read more

Okay, yeah, the title is a little bit of link bait, I admit it. Deal with it.

Internet Explorer has started to gain a small following in what I can only guess is some sort of developer-hipster hybrid community, and I’ve got a bone to pick with those people.

Internet Explorer 6, which born in the summer of 2001, and still exists as a force, albeit a shrinking force, in the world of website design. There have been three new versions of Internet Explorer released in this nine years since.

That’s my history lesson. Read more