Blog – Allain Lalonde

While testing a library I’m writing I found that I needed to pass in a simple mock object with a small set of methods and track how many times and with what values each of the methods gets called.

The following snippet of code is what I came up with.

function mock() {
    var mockMethods = arguments;
 
    var dummy = {}
    dummy.calls = [];
 
    for (var i=0; i< mockMethods.length; i++) {
        var methodName = mockMethods[i];
        dummy.calls[methodName] = [];
        dummy[methodName] = (function(methodName) {
            return function() {
                //Convert function arguments into an array
                var args = [];
                for (var i=0; i<arguments.length; i++) 
                    args[i] = arguments[i];
 
                this.calls[methodName].push(args);               
            }
        })(methodName);
    }
 
     return dummy;
}

And in an qunit test I’d use it like this:

test("fills rect when bounds and fillStyle are good", function() {
    var n = new PNode({
        bounds: new PBounds(0, 0, 20, 20),
        fillStyle: "rgb(255,0,0)"
    });
 
    var mockCtx = mock("fillRect");
    n.paint(mockCtx);
 
    same(mockCtx.calls.fillRect[0], [0,0,20,20]);
})

I hope someone finds this useful.

Agile Development, JavaScript JavaScript, mock objects, qunit, unit testing

So, you’ve learnt your first programming language and you’re feeling pretty comfortable with its syntax. What should you learn next?

A couple years ago I’d have recommended you pick up the gof patterns book and learn as many software patterns as you could. This is like learning to play the piano by learning how composers think. I honestly didn’t think you’d be able to apply most of what you’d learn, but i thought being exposed to higher order development ideas would raise the quality of your own.

Boy was I wrong. If a developer isn’t ready for them, patterns just make them over-architect everything. Unless a developer has a problem that would benefit from the application of a particular pattern, they’ll never internalize it. The problem must preceed the pattern before the pattern is seen in future problems.

These days I’d flatly point them towards Test Driven Development (TDD for short). Now, before you think that I’ve jumped on the agile bandwagon because it’s trendy, you should know that I was a hold out. I thought that applying TDD was a waste of programming time. I now think that it uses only slightly more time than an ad-hoc approach, but that time is better spent and the resulting software is of better quality for it.

So, why TDD for novices? It’s simple. By trying to write software that is testable, you end up requiring patterns. You can get away with not knowing them (for a while), but your ignorance causes you in pain; The perfect catalyst for true learning. Eventually one of three things is likely to happen:

1. you give up, finding the problem too hard
2. you search for and find an existing pattern (there are so many now that the chances of you not finding one are quite small)
3. you solve the problem by reinventing the wheel and then possibly discover a name for it later

I think all 3 are good things.

If you give up because you found the problem too hard, then you’ve just discovered that you aren’t cut out for solving technical problems for the rest of your life. At least you won’t be just another miserable coder. Go paint, go write, at least you’ll be happier for it.

If through your research you discover a pattern that solves your problem exactly, the act of refactoring things (changing your code for the better) will make you perceive the beneftis of the pattern anyway. The need for a solution will make it that much sweeter when it’s received.

If you’ve reinvented the wheel… at least you own that wheel and the act of carving it out has made you better at thinking through similar problems in the future. I wouldn’t belittle a carpenters brand new chair simply by saying that he could have bought one for less at Walmart. Plus, should you discover a name for it later, you will always understand it better than had you just read about it.

TDD done right can be a hard thing to do well. It’s more subtle than at first it appears, allowing beginners hit the ground running, subtlety be damned. Long time TDDers will often say crazy things like “It’s not about the tests” and If you’re into that kind of high brow thinking, which I am, you’ll appreciate the sentiment. But for a beginner, TDD can be all about the tests. Eventually by becoming better at the practice of testing, they’ll start to appreciate the higher order lessons that it is revealing. If not, so what, they’ve still learnt a new skill. They may never be masters, but they won’t necessarily be bad at it either.

So, what should you learn after TDD?

It’s very simple, there’s only one thing worth learning and you’ll have have to discover it for yourself. But when you do, would you please write an opinionated blog post about it for me.

Thanks.

Agile Development, Programming Agile Development, learning, patterns, tdd

Facebook applications is to OpenSocial  as Amazon’s EC2 is to …… Google App Engine. Google ftw!

Some things I like about it:

•  It’s free to start… the startup bar just got lower again
• Scales up well (from the reading I’ve done)… you just pay more.
• The data is backed up better than a home grown solution because of the the GoogleFS’ redundancy

I’ll be learning it soon. Time to bear down and learn Python.

Agile Development, Programming

Just a thought… Has anyone ever applied the ideas of Extreme Programming to Business Development.

I wonder what applying them in the business context would do, or if it makes sense for projects in general?

The following is culled from the XP practices guide and changed to apply to business where possible.

The Planning Process, sometimes called the Planning Game.

The planning process allows customers to define the business value of desired features, and uses cost estimates provided by the company’s employees, to choose what needs to be done and what needs to be deferred. The effect of this kind of planning process is that it is easy to steer the project to success.

Small Releases.

Agile teams give the client a working product, and update it frequently on a very short cycle.

Simple Design.

A product built in an extreme way should be the simplest solution to customer’s current requirements. There is not much building “for the future”. Instead, the focus is on providing business value. Of course it is necessary to ensure that you have a good design, and in this extreme system it is brought about through “refactoring”, discussed below.

Testing.

Extreme teams focus on validation of the product at all times. Employees develop products by identifying ways in which the product does not match a customer’s need and then design a minimal change to the product that would make it do so. Customers provide acceptance tests that enable them to be certain that the features they need are provided.

Refactoring.

Extreme teams improve the design of the system throughout the entire development. This is done by keeping the process free of duplication, communicative, simple, yet complete.

Pair Programming.

All employees work in teams. Two employees to one position.

Collective Ownership.

Everyone owns all the product designs. This lets the team go at full speed, because when something needs changing, it can be changed without delay.

Continuous Integration (May not be practical with brick and mortar designs)

Quick prototyping is key. And it should be possible to prototype the system at least daily. This keeps all the product developers on the same page, and enables very rapid progress.

40-hour Week.

Tired employees make more mistakes. Extreme teams do not work excessive overtime, keeping themselves fresh, healthy, and effective.

On-site Customer.

An extreme project is steered by a dedicated individual who is empowered to determine requirements, set priorities, and answer questions as the programmers have them. The effect of being there is that communication improves, with less hard-copy documentation – often one of the most expensive parts of a product process.

Standards.

For a team to work effectively in pairs, and to share ownership of the products, all the employees need to document designs in the same way, with rules that make sure the product designs communicate clearly.

It’s interesting to see how these rules sound when placed in a Business context.

Agile Development agile, business