Well, decent equipment, nice offices, ping pong tables and all that—these things pale into utter insignificance when it comes to one, relatively simple change, that organisations can make:

Ensure that your test environments mirror those used in production.

It really is that simple, and you will save countless hours of frustrated troubleshooting for your developers, testers, infrastructure and support teams. In organisations large and small I have lost count of the number of times working through an issue has resulted in the same root cause: the deployment to live actually meant testing a particular configuration or integration for the very first time.

This sort of thing is insane. Sort it out, and you will have your developers’ admiration for life.

A great tool, well worth the (small) price. And it does Linux too.

(Talking of Coda 2, if you use it be sure to check out the tips on the Panic blog: Top 20 Secrets of Coda 2).

It’s always good to compare with fellow developers, and I always like to hear what kit people are using. I’ll start: here’s the current tool-set getting the love chez Foo…

Sublime Text 2 (all main platforms)

Great programming editor, loads of syntax files built-in, and cross-platform in a good way. Really like using this, and it’s my PHP / Ruby editor of choice at the moment (not that I do much Ruby, but I can dream).

Coda (OS X)

Venerable editor for all things web plus a few others. Still a big favourite but needs a version bump—and soon.

A terminal

So flexible, oh the things you can do! It has its own range of editors (my fave is vi) plus git, ssh, svn, maven, phing, all the rest… :-)

—Oh yes, the main languages and environments I’m flailing at with these tools are PHP, HTML, CSS, and Javascript (including the splendiferous Jasmine—more on that later).

John Barton’s RFC.

Hevery’s document contains a number of tips designed to make code more testable, but really it goes wider than that. Hevery picks out four basic flaws, gives examples of each, how to detect them (“warning signs” if you will), and of course, how to address them.

The four flaws:

1. “Constructor does real work” (don’t do any more than basic assignment, and certainly don’t do any static “initialisation” method calls)
2. “Digging into collaborators” (avoid a deep chain of wrapper objects)
3. “Brittle global state & singletons” (globally-accessible elements can / will cause havoc when trying to test and debug)
4. “Class does too much” (remember the classic principle of “single responsibility.” Also, spaghetti code is blummen’ hard to test)

Read more… Guide: Writing Testable Code.

1. The “How would I test for xyz” mind-set, and;
2. A fast simple development environment

That’s it, that’s all you need. The first comes with practise, and the second is pretty straightforward nowadays. Of late I have been writing a lot of PHP in Eclipse, Coda and the new kid on the block, Sublime Text 2 (check it out: very nice). All of these tools make it easy to write test-able code, because one simply pulls in the unit testing framework of choice, and then one writes code: job done, very low barrier to entry.

As a small aside, I am constantly amazed at how much PHP stuff goes out the door with minimal-to-no tests, especially when one considers the fluid nature of the language (its typing and such). This contrasts sharply with the mind-set we see amongst Rubyists, who regard their language’s dynamism as raison d’être for excellent test coverage.

So a diligent approach to testing is one thing, but contrast my comments about editors above with other recent experiences writing Java in an Eclipse-based editor called Domino Designer (some of you may be familiar with it). Making that code test-able has been more problematic, given DDE’s reluctance to play nice with plug-ins like JUnit, and the way a typical Java agent is structured. So, a couple of tips:

1. Abstraction is key: write as much of your Java code as you can abstracted away from the Domino object model. This way you can code in a proper Eclipse instance, and you can write easy test cases. Break up big problems into small solvable components, and test them. Your Java agents should be very “light”—minimal code perhaps just looping a collection or whatever. Let your custom, tested classes do the heavy lifting.
2. If you’re like me, and not at Lotusphere, you will be missing out on a session from Messrs. Myers and Robichaux covering effective Java in the Domino environment. As soon as their presentation is made available, I have it on good authority that you will want it, and that the Wookiee has some tricks up his sleeve when it comes to JUnit :-).

(Finals words of “wisdom”: it is a lot quicker, and simpler, to write test-able code up-front. Adding tests after the fact is always more burdensome).

]>http://benpoole.com/weblog/201201170736testing, programmingBen Poolehttp://benpoole.com/weblog/201201170736http://benpoole.com/weblog/201201170736#commentsThu, 5 Jan 2012 18:45 +0100Yesterday I posted about Code Year, an initiative to get people learning the gentle (chortle) art of programming. But what of the seasoned professional, the much-maligned code monkey, the long-suffering developer?

Well, Matt Might has a splendid list of twelve resolutions for the rest of us:

Matt Might, 12 Resolutions for Programmers.

]>http://benpoole.com/weblog/201201051845programming, matt might, resolutionsBen Poolehttp://benpoole.com/weblog/201201051845http://benpoole.com/weblog/201201051845#commentsWed, 4 Jan 2012 22:30 +0100After checking out the Code Year site recently launched by Codecademy, I moved on to read an interesting post from that site’s designer, Sacha Greif: How I Designed CodeYear.com in 1 Hour. Definitely check this post out: Sacha deftly guides the reader through the over-arching thought processes behind an effective site re-design. There are some handy tips and links along the way for any budding designers, or coders like you and I who simply want to to create more pleasant web experiences.

As for Code Year, what a great initiative!

If you are not a programmer, you are one of the programmed. It’s that simple.

Douglas Rushkoff says it best.

]>http://benpoole.com/weblog/201201042230codeyear, douglas rushkoff, programming, codecademyBen Poolehttp://benpoole.com/weblog/201201042230http://benpoole.com/weblog/201201042230#commentsFri, 9 Sep 2011 16:41 +0100Recent projects have meant lots and lots of Javascript. Other work has led to a need to really study the language, and look into more than the odd jQuery plugin and wot-not. This has been a rewarding experience: challenging received wisdom, ensuring that I know more about all those concepts that spend years just floating out there on the edge of one’s understanding.

To that end, here are a few interesting tid-bits which I have found—typically whilst researching more involved stuff like prototypical inheritance and closures :-). It’s amazing how much we think we know…

A couple of the more involved posers have specimen answers attached; the others are too easy for me to do that! It’s all interesting though:

// What do these two alerts produce, and why?
alert('1' + 3);
alert('3' - 1);

// If expressed as tests, what do each of these return?
"1" == 1;
"1" === 1;
"1" == true;
"1" === false;

// What do these calls produce?
parseInt("05");
parseInt("010");
parseInt("09");

// What are the five main data types in Javascript?

// How would you create a class in Javascript, with a private method?
function MyClass()
{
    function somePrivateMethod() {
        console.log("this is a private method");
    }
}

//… how would you add a public method to this class?
MyClass.prototype = {
    somePublicMethod: function() {
        console.log("This is a public function, whoop!");
    }
}

]>http://benpoole.com/weblog/201109091641javascript, programming, fun, tipsBen Poolehttp://benpoole.com/weblog/201109091641http://benpoole.com/weblog/201109091641#commentsThu, 18 Aug 2011 11:44 +0100If you’ve been following some of my recent posts on off-line apps, Web SQL and all that, you will have seen that all my mark-up snippets were in HTML5. And no doubt you have seen a lot of the brou-ha-ha around HTML5 too, and probably know that introduces some more field types and attributes.

Rather than go into a whole exposition of HTML5 (which others have already done brilliantly) I want to take a moment at some real-life applications of some of this HTML5 lark. I’ve already talked about off-line web apps and using local storage options (in the form of Web SQL), so let’s take a brief look at fields. I’ve coded a few production sites and applications so far that take advantage of the new types offered in HTML5 (specifically email, number, range and date fields), and having these expanded options in one’s arsenal is not to be sniffed-at. What I especially like in HTML5 is the in-built support for the new “placeholder” attribute. No more do we have label and Javascript onfocus() hacks (at least, not in some browsers). Instead, this wee bit of mark-up does everything we need, with the placeholder text disappearing and re-appearing as the field contents are changed (you will have seen this in my previous demo):

<label for="winklename">Your winkle’s name</label>
<input name="winklename" id="winklename" placeholder="Winkle's full name, e.g. 'Pansy Trueshell'"/>



Isn’t that smashing ladies and gentlemen? Of course, it’s not (yet) all roses in the HTML5 garden: some browsers simply don’t support every bit of this emerging standard. A fine idea is to make use of something like Modernizr for feature detection, but if placeholder support is a feature you need to test for explicitly, something like this should help:

function placeholderSupport(){
  return 'placeholder' in document.createElement('input');
}

(This function returns true for sensible browsers like Safari, Chrome and Firefox, and false, predictably, for things like IE8). Now, what I really like is that by introducing new data types for fields, HTML5 also allows the easy manipulation of said fields in the app framework of your choice. So, if I want a whizzy date-picker for my date fields, or a lovely slider for my range fields, it all becomes a hell of a lot easier to apply with a decent framework. For example, here’s an HTML5 date field which is rendered using the DateBox plugin alongside jQuery Mobile:



A corollary of these new field types is that many mobile devices support them. So, for example, if I want my mobile device’s keyboard to show an @ sign when filling in an email field, I just need to ensure the field type is set appropriately—iOS / Android / You Name It will do the rest for me. You’ve probably seen this in action yourself. So, make sure your apps play nice—mobile is crucial!

]>http://benpoole.com/weblog/201108181144html5, web design, mobile, html, tipsBen Poolehttp://benpoole.com/weblog/201108181144http://benpoole.com/weblog/201108181144#comments