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#commentsThu, 30 Jun 2011 22:11 +0100In my last post on this topic, we looked at how one might use Web SQL in a local web application, and I supplied some code which initialised a local database and pulled data from its lone table. All well and good, but what about the realities of using this data? Specifically, let us look at how one re-loads, edits and saves the data.

“Eh?” I hear you ask. “Surely you just load up data in the normal way, and then, um, well put it somewhere…” (reader tails off quietly, and there is a momentary embarrassed silence). Yes, in my last post the provided code shows how to do a basic save and bulk load from the fabled winkles table, I grant you, but that in and of itself isn’t that much use. Sure, you can iterate query results and present them in a page, but what about editing said data? This is where the fun starts. You’re running a local web app remember: no web server, no box to which you may post forms for processing! But that won’t stop us, dear me no! I will show you how you can save a form within a web page to your database table, and then how you can load that data back into the same web page for editing and more saving. No server tricks! Splendid.

First up, grab a shiny new Javascript source file from a new gist I created here: Web SQL javascript (it’s the JS we used in my previous post, broken out into its own source file, with some added goodies). The gist tells you what to call the file. Then, in the same directory, create a new HTML page and whack the following mark-up into it. It’s a simple HTML5 page, with a wee bit of Javascript injection, a tiny form, and that’s about it (note: as with my other examples, this page requires jQuery in addition to the supplied Javascript).

<!DOCTYPE HTML>
<html>
 <head>
  <meta charset="UTF-8" />
  <title>Winkles! Form a line!</title>
 
  <style type="text/css">
   body {font-family: Helvetica, sans-serif; font-size: 100%; line-height: 1.4em}
   input, button {width: 25em; font-size: 100%; padding: .25em}
   label {display: block; margin-top: 1em}
  </style>
 
  <script type="text/javascript" src="jquery.js"></script>
  <script type="text/javascript" src="winkling.js"></script>
  
  <script type="text/javascript">
  $(function(){
   var form = $("#winkle-form");
   form.submit(function(event){
    event.preventDefault();
    var values = form.serializeJSON();
    saveWinkle(values, function(){
     alert($('#winklename').val() + "'s data has been saved, thanks.");
     location.reload(true);
    })
   });

   loadWinkles("", updatePageWithLinks);
   $('#clear-btn').click(function(){resetWinkle();});
  });
  </script>
 </head>

 <body>
  <h1>Winkles! Form a line!</h1>
  <p>Here’s where you enter some winkle-related data. And it gets saved. And you can load stuff too.</p>
  
  <form id="winkle-form" action="" method="POST">
   <label for="winklename">Your winkle’s name</label>
   <input name="winklename" id="winklename" placeholder="Winkle's full name, e.g. 'Pansy Trueshell'"/>
   <label for="location">Your winkle’s location</label>
   <input name="location" id="location" placeholder="Type in a location here, e.g. 'Ayrshire'" />
   <input type="hidden" name="id" id="id" />
   <p><input type="submit" value="Save Winkle" /><input type="button" id="clear-btn" value="Clear form" /></p>
  </form>
  
  <h2>Previously-saved winkles</h2>
  <p>Tap or click on a link below to load that winkle’s data into the form above:</p>
  <ul id="winkle-list"></ul>
 </body>
</html>

All done. Now for some testing in your browser! As with my previous local SQL example, there are a couple of gotchas to bear in mind when previewing this stuff locally:

1. Don’t preview with the file:// protocol, you will hit strange security exceptions in your browser. Use a proper web server, something that can serve up as http://. (I use OS X, so I preview in the bundled local Apache 2 installation, which is handy).
2. I have only tested this code in Chrome and Safari. It should work in Opera, but I make no warranties for it working anywhere (and it most certainly will not run in Internet Explorer ;-)).
3. There’s no validation: it is entirely possible for you to save empty winkle data (shocker).

Let’s look at the code in this web page. First, we override the form’s default onSubmit action so that it doesn’t actually try to POST anywhere, it just triggers saveWinkle(), a function which grabs all the data in the form (yes, all two fields of it. Well, OK, all three fields, what with the hidden one), saves it to the winkles table, and then kicks off a callback function (a grand term for a simple alert call, I think you will agree). Easy-peasy.

Where things get a little more interesting is with the other bits of Javascript you see triggered when the page is ready. The first function, loadWinkles() comprises some Web SQL Javascript which SELECTs every winkle in the table, and then passes the SQLResultSet over to a callback, updatePageWithLinks. That function iterates the resultset, and writes the data out to the bottom of the web page (the winkle-list unordered list to be precise). Now, this code is all familiar from my previous post. Where things diverge is in what that function writes out: it’s not plain text as before, it’s a list of links.

(Oh yes, I also add a click event to a form reset button, but that’s not very interesting, so I shan’t talk about it).

If you take a look at updatePageWithLinks in the Javascript source provided, you will see that the links are written out to the page with reference to a new function, loadMe. This takes a single parameter, which is the relevant winkle’s database record “id”, so that loadMe knows which winkle’s details to load up.

loadMe, surprise surprise, is callback-mungous, like a lot of the other code here. First, it triggers a routine to perform the SELECT and pull back the relevant record. Then this SQL result is passed over to a small function called loadFormWithData… and you can guess what that does.

There you have it. Loading and saving data to and from a web page, no server required. Now, I grant you, this form injection stuff all seems a bit fiddly. Why not use querystring parameters and the like to pass round the record ID required? Well, that’s where you hit one of the limitations of local web applications: as soon as you start involving things like href hashes, or querystrings, your web client will assume a server is involved. And if you’re running off-line (remember how this series of posts started!), that’s a no-no, and your browser will forget all about appcaches and the like, and will attempt to contact the (potentially unreachable) server. Doh!

]>http://benpoole.com/weblog/201106302211websql, html5, javascriptBen Poolehttp://benpoole.com/weblog/201106302211http://benpoole.com/weblog/201106302211#commentsWed, 22 Jun 2011 22:27:24 +0100So, you know how to take our site off-line: events are triggered, caches are swapped, and even though you still have that (apparent) server-based URL going on in your address bar, you are off-line! Yes! Stick your device in airplane mode and revel in how your website is still doing its thing. Clever.

However, your world is incomplete. You have some pages going on, some links between them, stylesheets—maybe some whacked-out Javascript doing wondrous things—but something is still missing. And that something is persistence, a proper local data store that goes beyond the capabilities of the humble, fragile wee cookie.

Until the newer browser technology started to become mainstream (arguably aided by the early efforts of things like Google Gears), this was a big sticking point for off-line sites and apps, because there was nowhere to store one’s data. Now though? Sea-change, oh yes. Depending on your browser of choice, you have two options: 1) an embedded local relational database (the generic “Web SQL” standard, that in practice actually means SQLite) or Web Storage, which is a simple key-value store.

IndexedDB is one for another day. For now, we’re thinking about a local instance of SQLite with a Javascript framework to access it, which can be found in all up-to-date WebKit-based browsers, and also in Opera. “Web SQL” works well, and is surprisingly well-featured, but we hit the main hiccup with its uptake when we consider the supporting web clients: Chrome and Safari (including mobile variants thereof) are golden of course. Opera is popular, and includes a mobile instance too—again, good—but Firefox and Internet Explorer are out in the cold, with no Web SQL support (in fairness to Mozilla, Firefox instead supports IndexedDB which appears to be the preferred local data store going forward anyway—see “Further reading” section). Only you can decide whether this is an issue, but seeing as I’m been coming from the mobile web dev. angle, I’m OK with it :-)

On to the code

The Javascript API that overlays all this SQLite goodness is pretty simple to use. It is callback-mungous though, so if you’re not used to coding your JS that way, you soon will be. Here is a snippet of Javascript which opens a database for logging periwinkles. The code creates the main table (if it doesn’t already exist), which is a simple three column affair: a generated id, plus two text values for a given winkle’s name and location:

/* Open & initialise our database. Note the required parameters, 
   which comprise a short name, a version, a display name 
   & expected maximum size (in bytes)
*/
var db = openDatabase("winkles", "1.0", "Winkles Of The World", 32678);

/* Create the winkles table (if it doesn't already exist), with 
   an automatic id key, plus two columns for name & location
*/
db.transaction(function(transaction){
  transaction.executeSql("CREATE TABLE IF NOT EXISTS winkles (" +
    "id INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT," + 
      "winklename TEXT NOT NULL, location TEXT NOT NULL);");
});

So the database and table exist (and will still be there when you close your browser session of course), and now we want to do stuff with the table. Assuming we’ve magically generated some winkle data, let’s say I now want to see the names of all winkles found in Ayrshire. Here’s how it’s done:

var showWinkles = function(location, successCallback){
  db.transaction(function(transaction){
    transaction.executeSql(("SELECT * FROM winkles WHERE location=?"), [location],
      function(transaction, results){successCallback(results);}, errCallback);
    });
  };

A few things to note here: the SQL statement is wrapped in a transaction instance, which is asynchronous. As such, the call to showWinkles is expected to pass over two things. One is the location we want data for (“Ayrshire”), and the other is a callback (successCallback). This should be a function that the SQL results get passed to for onward processing. Finally, you can see reference to some random thing called errCallback. This is optional, but recommended, and in this instance it’s a reference to an error state callback function. You can define this in your main Javascript code, something along these lines perhaps:

// Generic error callback
var errCallback = function(){
  alert("Oh noes! There haz bin a datamabase error!");
}

Well you get the idea.

Is this thing on?

A quick aside: let’s fire up the Web Inspector found in all WebKit browsers, and see just what we’ve got there:



Not bad eh? There’s our database, our winkles table, and some data, right there. In fact, the Web Inspector window is quite powerful: highlight the databases icon, and the pane to the right becomes a console into which you can type SQL directly—perform updates, queries, drops, anything you want (you even get some auto-complete on your SQL).

Success

Back to the code. Let’s look at a typical “success” callback in more depth. How might one usefully call showWinkles within a web page? How about a button (with the id show-me), that when clicked, retrieves all the winkle data for a given area and presents it in a list? Anyone familiar with the “subversive injections” presentation I did with the Wookiee at UKLUG 2009 will know I like to inject code into web pages willy-nilly (dirty devil). So, when your document’s ready, bind some code to our button like so (note: all the following snippets use jQuery for brevity, selectors, and a couple of other things):

$('#show-me').click(function(){showWinkles('Ayrshire', updatePage);});

Now, let’s write the routine mentioned above as the callback we pass to showWinkles—we’re calling it updatePage. This function needs to get a handle on our HTML list (to which I have granted the imaginative epithet winkle-list), iterate our SQLResultSet, and write out a list item for each row in said results (or not, if there’s no data). Again, I’m using jQuery here, both for selectors and for $.each (which I like very much):

var updatePage = function(results){
  var winkles = $("#winkle-list");
  winkles.empty();  // Clear down before re-creating
  if (results.rows.length==0){
    // Nothing in the table
    alert("Alas, there be no winkles here.");
  } else {
    // Iterate the SQLResultSet
    $.each(results.rows, function(i){
      var row = results.rows.item(i);
      // Write out a list item for each row
      winkles.append("<li>" + row.winklename + " who resides in " + 
        row.location + "</li>");
    });
  }
};

All done! So there, in a nutshell, is how to query data in a SQLite database running in your WebKit browser. Now, the more astute amongst you will have noted that this isn’t the whole story—I’ve not listed any code to save my winkles for a start, nor is the mark-up I’m tinkering with detailed. Do not fear, the complete source code for this post (a single HTML page with all the required Javascript) is available on GitHub, in a thing called a “gist”:

gist - Javascript & Web SQL example

Now, this code is a simple introduction to Javascript and SQLite in a local web page. It is not production-ready for a number of reasons, not least that it’s all just straight Javascript function calls and wot-not. Any developer worth his or her salt would rip this apart and create a nice DAO which can then be used as a “service class” of sorts, tucking away all those nasty brackets and SQL statements (in fact, that’s just what I did for a client project recently ;-)), so there’s some homework for you right there!

]>http://benpoole.com/weblog/201106222227html5, javascript, websqlBen Poolehttp://benpoole.com/weblog/201106222227http://benpoole.com/weblog/201106222227#commentsThu, 16 Jun 2011 10:24:38 +0100What ho! Just over a week ago I picked up on this opinion piece from Hutch Carpenter, in which there is much discussion about mobile apps—specifically why enterprises should look at the mobile web route, rather than native applications. Carpenter makes a number of points supporting his case, and I can’t say I disagree. Of course there are scenarios when a native app is the only way to go, but for a lot of this stuff the web is spot-on (and the web can still have a part to play in native apps—think cross-compilers such as those in Appcelerator and PhoneGap). Anyway, here is one of Carpenter’s clinchers:

Indeed, designing for a mobile experience is actually a great exercise for enterprise software vendors. It puts the focus on simplicity and the most commonly used functions. It’s also a chance to re-imagine the UX of the software. It wouldn’t surprise me if elements the mobile optimized HTML [a strange sentence, but I’m sure you get his point - BP] find their way back to the main web experience.

Hutch Carpenter: Four reasons enterprise software should skip native mobile apps.

There’s a parallel here; look at where Apple are going with iOS, OSX (and the respective app stores) with noticeable feature and paradigm exchanges between the Mac and its iBrethren. The interplay between iOS and OSX has come to the point that the forthcoming release of the Mac’s operating system (“Lion”) will include a number of innovations originally seen in iOS. It’s clear that this is happening in the mobile space too. Constraints in screen real estate, functionality and memory have all led to some real innovation. The provision of decent mobile browsers (mainly courtesy of WebKit) now means that we have some amazing frameworks for all major devices. And what technologies do some of these frameworks base themselves on? Why, good old HTML and Javascript! Look at the aforementioned Appcelerator and PhoneGap, or the web frameworks jQuery Mobile and Sencha if you don’t believe me (heck, look at the demonstration of Windows 8 that’s out there).

So developers, if you’re looking for some new stuff to learn, by all means roll with Ruby, partake of some Python, simper with Scala… but don’t neglect trusty mark-up and its pal Javascript—in case it’s not become clear yet, you will need your web skills more and more.

Shameless plug: if you need some mobile web development for your organisation, get in touch. We fellows at the London Developer Co-op are doing more and more in this space).

]>http://benpoole.com/weblog/201106161024mobile, frameworks, mobile+webBen Poolehttp://benpoole.com/weblog/201106161024http://benpoole.com/weblog/201106161024#comments