Kasa

Kasa  © 2010 Darren DeRidder.
Umbrella detail, Kinosaki, Japan

When Agile Went Off the Rails

Whenever I hear a company say "We follow an agile development process", I can't help but wince a little. The core ideas of agile development are excellent, but somewhere along the way it accumulated quite a lot of codified process, and became its own formal methodology - almost the same thing the Agile Manifesto was trying to counteract. It's not too surprising, since the agile manifesto didn't prescribe any particular project management methodology for implementing its guidelines. So naturally it wasn't long before management professionals began to formalize agile philosophy into a methodology of their own.

Now one of the original authors of the Agile Manifesto has come out with a piece, originally titled "Time to Kill Agile", in which he makes this point that a formal methodology runs counter to the original goals of the agile development concept. Dave Thomas has been hugely influential in the software development field. Aside from being one of the authors of the agile manifesto, he's written a lot of other stuff, and he's the guy who coined the phrases "code kata" and "DRY" (Don't Repeat Yourself - the maxim developers follow to effectively organize their code).  He later renamed the piece "Agile Is Dead (Long Live Agility)!", which is a better reflection of his current thinking on Agile processes vs agile development's underlying goals.

Being a critic of Agile is risky; in many cases it seems to have improved the effectiveness of teams a lot. It's working for a lot of people, and they like it.

But having one of the original authors of the Agile Manifesto come out with this kind of criticism of agile methodology makes a certain amount of healthy skepticism seem appropriate.

Agile software development, according to Dave Thomas, can't be implemented as a set of methodologies, and the managers, consultants and companies that have sprung up around Agile have shown a certain level of disregard for what the authors of the Agile Manifesto intended in the first place.

Dave Thomas has some good advice for teams that want to develop software with agility. He advocates an iterative approach to development, and choosing options that enable future change. He recommends thinking of "agile" in the form of an adverb (agilely, or "with agility"). Programming with agility. Teams that execute with agility.

I've found that when it comes to managing a project, simple is usually better. What's worked best in my experience is, in a nutshell, to simply encourage communication. Make sure everyone understands the overall objective, how they can contribute to it, what progress has been made and what challenges remain, and importantly, give everyone the opportunity to have their work fully recognized and appreciated on a regular basis. Given the opportunity to work on a challenging project and the chance to have their contributions seen and appreciated by colleagues, most developers will bend over backwards to do their best.

One technique I found effective was a brief (timed with a hard stop) Monday morning meeting where we laid out the objectives for the week ahead, a quick information-gathering hike around the office at the end of the week, and an email re-cap on Friday afternoon highlighting the team's progress. Showing the percentage-towards-completion of major tasks was also a big motivator, as developers began to take pride in seeing their areas of responsibility make steady, visible progress towards completion.  We didn't formalize or get locked into one way of doing it, so when our company got acquired and our management structure changed, we adapted pretty easily.

Perhaps this isn't too far away from the way agile methodology is practiced "by the book". Regardless of the methodology, it's worth noting that the Agile Manifesto wasn't really a call to implement any particular process. It had broader goals in mind:

• People over processes.
• Working software over documentation.
• Collaboration over contracts.
• Adaptability over planning.

Itsukushima Jinja

UNESCO World Heritage Site, Itsukushima Shrine, Hatsukaichi, Hiroshima Prefecture, Japan.

Itsukushima Jinja
© 2014 Darren DeRidder. Originally uploaded by 73rhodes

Node.JS Module Patterns using simple examples

Slides for a recent talk at Ottawa.JS on "Node.JS Module Patterns using simple examples" are available. The slides have been updated to include a brief intro to Common.JS, examples for exporting named and anonymous functions, objects and prototypes, and an explanation of "exports" vs. "module.exports".

JavaScript Efficiencies

I'm working on an article about patterns for structuring Express.JS apps, which is taking too long, so I decided to write this instead: Here are a few tips and tricks for JavaScript programming that I like.

Comment switches

Comment switches let you comment out entire blocks of code with a single character, or switch between two different blocks of code with a single character, which can be useful when prototyping.

//* 
console.log("Hello!\n"); 
/*/  
console.log("Goodbye!\n"); 
// */

Removing the first slash '/' toggles between these two print statements. See the original post for more examples of comment switches.

Iterate by Counting Down

You can iterate n times concisely, like this:

var n = 1000;
while (n--) { ... }

Defaulting Arguments

This is a handy way to provide a default value for undefined arguments in a JavaScript function.

function foo(bar) {
   var bar = bar || "Some default";
   ...
}

Kenka Matsuri II

Kenka Matsturi - the Battle Festival, Himeji, Japan. ©2012 Darren DeRidder

Testing Express.JS REST APIs with Mocha

My post on Testing REST APIs with RESTClient and Selenium IDE has been getting some attention, but you might also want an automated testing solution to be part of your build process.

This post will cover testing REST API's built with Express.JS, using Mocha as the test framework. Express and Mocha are both by the same author and work well together.  This technique can also be used to test Express apps in general.

In a nutshell, we'll create a test suite in Mocha that does the following:

1. instantiates and runs our REST API server (an Express app)
2. sends HTTP (or HTTPS) requests to the REST API
3. checks the responses for appropriate values

So, let's say you've written an Express app that works as a REST API server, and now you want to automatically test it over HTTP. Assuming you have Mocha installed, and are somewhat familiar with how to use it, building a suite to test your Express app over HTTP is relatively simple.

Our example test suite is a file located at test/app_test.js. The first thing you'll need to do is include the Express app you want to test. Mine is simply called app.js, so this is what the start of my test suite looks like:



Before we can start testing our API server app we need to start it. We can create a test suite called "app" for this. Before anything, we'll start the app. Then we'll check to make sure it is running. Here's what it looks like:



There are a couple of pieces missing from the test case above. We're using Node's build-in http library, so we need to include that at the top of our file as well:



And, there's a function defaultGetOptions, which is just a little helper utility to format our request:



Lastly, you can see that there's a variable called sessionCookie. This is how we maintain a session with our REST API, in case your API requires an authenticated session. You can simply declare this variable at the top of the file:



And set the cookie value whenever you get a response from the API server. Here is an example of setting the sessionCookie value when logging in:



As you can see, I'm using a few extra variables or functions - there are some test-user parameters, and a function to format the headers for a POST request. Having seen the example for a GET request, you should have no problem creating similar functions for POST, PUT, and DELETE (check out the Node docs for HTTP).

Finally, to make this all work you might need to modify your Express app to make sure that it does not start up automatically on the default port, if it is being included as part of a test suite. You do this by checking for module.parent.

Above, you can see that the app will only start actively listening if it is being run directly, but if it has been included in a test suite like ours, it won't automatically start up. This let's us start the app on a port of our choosing from within our test suite, like we did in the example above.

Hope that helps...