Adventures in Bad Coding

Ubuntu vs LinkedIn

2009-08-03T23:29:00.000-07:00

As the full story unfolds, this would definitely qualifies as an adventure, but not one of mine!

For some time it has bothered me that I can't use LinkedIn.

... That is to say, I can't use Ubuntu when running Linux.

Update: that really should read "I can't use LinkedIn when running Linux", but I do like the effect!

Oh! I can go to the site and log in. However, any query based request, and things just go to sleep.

??? I thought that the web was supposed to be platform neutral!!!

It is neutral, in theory, although try accessing a site running asp and see how far you get on a non-windows operating system. To even the score, using a Redmond produced browser will give you problems with clever styling (prior to IE 8, at least), and no visibility for any svg images (the latter being the case of a 400lb gorilla squishing a perfectly good standard that most other browsers support reasonably well.)

But why? Think 'Silverlight'

One day, I hope the penny will drop that having a non-neutral net is in nobody's interest! So, to get back to the LinkedIn issue.

For once, it doesn't appear to have anything to do with Microsoft conspiracy theories. Nobody, at this stage, appears to quite know just what the problem is!

I have no solution, but I admire the problem!

Happily, there does appear to be a workaround: just tweak the network layer so:

sudo ifconfig eth0 mtu 1360

I tried it and ... presto!

So I'm happy for now! However, I'm not sure which I find more mysterious: the problem itself, or the process that produced the workaround (which you can read more about on this forum)

In The Frame III: Creating a Project

2009-04-23T19:54:00.000-07:00

Sorry if anyone's been waiting, with baited breath, for this instalment. I had intended to post once a week. However, life intrudes on these plans. So, while I will try and stick to a weekly instalment, there will be no guarantees.

OK We've decided what we want to do. Now, how do we start going about it?
In this post, I will review what happens in the various frameworks when you create a project:

Rails
$ rails Enchant

This runs a script that generates a ruby project framework for your application under the folder named 'Enchant'. This was the name I chose for this project. Feel free to use something else.

Before proceeding to look at the results, I would like to comment that I long ago concluded that Tolkien had some sound advice for programmers: 'Do not meddle in the affairs of wizards! They are subtle and quick to lead you down the garden path before abandoning you behind the compost heap with all the fairies'.

What I mean by that should become clear when I describe the project structure that rails creates:

Enchant/
app/
controllers/
application.rb
helpers/
application_helper.rb
models/
views/
layouts/
config/
environments/
development.rb
production.rb
test.rb
initializers/
inflections.rb
mime_types.rb
boot.rb
database.yml
environment.rb
routes.rb
db/
doc/
API/
README_FOR_APP
lib/
tasks/
log/
development.log
production.log
server.log
test.log
public/
images/
javascripts/
stylesheets/
404.html
422.html
500.html
dispatch.cgi
dispatch.rb
favicon.ico
index.html
robots.txt
script/
performance/
process/
about
console
destroy
generate
plugin
runner
server
test/
fixtures/
functional/
integration/
mocks/
development/
test/
unit/
test_helper.rb
tmp/
cache/
pids/
sessions/
sockets/
vendor/
actionmailer/
actionpack/
activemodel/
activerecord/
activeresource/
activesupport/
rails/
railties/
Rakefile
README

Hello? Are you still there? I'm not surprised if you found all that a bit daunting. It is a bit of overhead for a simple 'hello world', isn't it?

Of course, you don't actually have to know the ins and outs of *all* these directories before you start doing some work, but it serves to show that Wizards, while thay may do a lot of useful things for you, become less useful when you actually start having to do your own work, and try to figure out what it is that they have actually done for you. (Look up 'Guru' as an anti-pattern). In fact, this tree has even more detail than I have shown, but I think the point is made, even without drilling further down into the depths of the directories, api/, public/, and vendor/.

Anyway, the folders we do need to concentrate on are:

app/: this is where the bulk of the application code will be placed. It is organised into sub-folders in a fairly intuitive way:

models/: for classes describing the application data models
views/: for classes handling the output displays
controllers/: for classes that handle the action prompts, interrogate the model, and return the appropriate view
helpers/: for classes that assist at the small-scale

script/: this contains a lot of useful utility scripts for maintaining and developing the project. You'll see these in use shortly.
vendor/: for third party software. By 'third party', I would include common code you develop and maintain yourself for use in multiple applications.

Django

By comparison, the structure that Django creates is laughably simple:
$ django Enchant

Enchant/
- __init__.py
- manage.py
- settings.py
- urls.py
- views.py

Whether this naive setup allows for good scaling, or is only good for naive applications, remains to be seen.

Cake

It is not immediately obvious how to set up a Cake project. Certainly, there is no 'Cake' me a baked project command. There does appear to be an underlying assumption that you operate with one cake application per server, so all you have to do is install Cake and get going in the 'apps' directory. The directory structure of cake appears to suggest this, and is similar to the Rails structure. Guess you have to copy the template to where you want it. (Was I grumbling about Wizards earlier?)

Next... Doing something visible.

In the Frame II: Intentions

2009-03-28T12:00:00.000-07:00

The Application:
Having announced my ambitions, I had better announce my intentions: what application shall I write?

My trusty Rails reference is Dave Thomas and David Heinemeier Honsson :'Agile Web Programming with Rails', which describes a simple shopping cart application. A little copycattish to do that again, I think.

Instead, since I am going to be developing the application in triplicate, I shall choose something that caters for multi-user interaction: I shall create a conversation whiteboard.

What this will allow is for each version of the application to interact with each other (in theory!).

Important stuff first
What to call it?

Well, it's a chat application with multiple varieties, so a starting point of 'N-chat' leads naturally to calling it:

Enchant

Analysis
How do I imagine it operating?

Starting with a conversation board, a user can select which of several groups they might like to join.
(There might even be a snatch of overheard conversation to help them decide)
On selecting that conversation, the user then sees a number of views*:

one for what is typed in
one for the general buzz of conversation
a few extracted streams, associated with user.

Oh yes, they will probably want to be able to leave as well!

There are any number of refinements that can be added to all this, but I think this will be more than enough for a training exercise (especially if muggins here is going to be doing it in triplicate!)

Design
OK, what we have already suggests a number of design issues:

two main displays: the main listing, and the conversation area
A database (which isn't strictly necessary for casual chit-chat forums, but which might prove useful for playback. This poses a small problem in that I don't actually have a database that is accessible online...so we may dispense with that. That would be a pity, since ORM is a major support feature of these frameworks)

Tackling the main listing first, it should handle the following use cases:

view conversations (default)
create conversation
join existing conversation

The conversation space should handle the following, at least:

add to conversation
update conversation
leave conversation

In the spirit of Agile programming, we will leave the list at that, and add to it as time and experience suggest.

*You will note a few mixed metaphors going on here, as I try and cram square pegs into round holes, and describe a visual application for what is, traditionally, an aural/oral activity. This isn't an idle observation: I think it's a major issue of chat sessions, which we will not be solving here)

In the Frame I: Ambitions

2009-03-21T14:00:00.000-07:00

After a prolonged absence from this motley collection of tidbits, and faced with a prolonged period of inactivity known as 'unemployment', I have decided to embark on a bit of self-education.

The focus of my interest is going to be web frameworks, and I shall be describing my efforts at creating an application.

The trick is, I shall be investigating, not one, but three:

PHP Cake
Python's Django
Ruby on Rails

They all purport to do the same things, and that is:

Provide a 'Model-View-Controller' (MVC) architecture for your (web) application
Provide 'Object-Relational Mapping' (ORM) by which your application can talk to its database.

While these are clearly useful and worthy things (after all, a number of people went to the effort of putting these things together, presumably for a reason) I am going to be taking a slightly different tack, and assess their friendliness, both to the seasoned developer, and to the newcomer who has to contemplate the height of the technological 'entry bar' that a proliferation of applications and their associated buzzwords appear to be doing nothing to keep low.

Tall order? Well, as a former supervisor once said to me, 'In order to develop, you need to exceed your comfort zone.' (It's a pity glass wall wielding recruitment agencies haven't heard that, but that's another story I will not dwell on here.)

My intention is that I shall be developing an application (the *same* application) using each of these frameworks, and describing how my attempts are going in these entries. How technical all this will get remains to be seen.

It may launch careers. It may peter out in an ignominious puddle of dazed confusion.

That is the nature of experiment! Finding out what works.

Learning to Love Being Test Driven

2008-02-28T21:44:00.000-08:00

Modern coders will, no doubt, find this little monologue hopelessly passe and babyish.

On the other hand, if your roots lie in the 'traditional waterfall' approach to software development, then there's a refrain that sounds nonsensical when said out loud:

'Test before you code'

Of course, the waterfall approach has been well and truly superceded in favour of cyclical development and the Agile Manifesto (although some would disagree, sotto voce ;-).

So, what is weird about the concept? The first thing that occurs to you is that effect precedes cause: if you test first, then you test...what?

Actually, if you look at the standard mantra (Analyse, Design, Code, Test) you will see that there is actually plenty to test: by the time you are ready to code even a couple of lines, you should have an idea of what you are coding those lines to do. You will some idea about how that code will be invoked. In short, you will have described an interface.

So, testing an interface sounds less ridiculous, doesn't it? Throw some parameters at it and see what happens. (of course, this assumes you or your client have put some requirements together in the first place so you know what it's meant to do. You have done that, haven't you? Of course you have!)

To encourage this desirable behaviour, a number of ancillary frameworks that support what is collectively referred to as 'unit testing' have recently become available. It's not hard to find a plugin for your language. They provide a base test class from which you derive your own suite, and define each test as a method of that class. The wonders of mirroring allows the base class to invoke all methods that fit a pattern like 'test*' (even non-mirroring languages like C++ can join in, although it requires a little more effort from the tester)

So, the *very* first bit of code you should write is your test cases, in the cheerful expectation that each and every test will report abject failure (although statistically, some random stub is bound to work by sheer fluke. Never mind, nothing is perfect!)

Actually, if you do this, your code will probably explode spectacularly, since you haven't written the interface stubs yet! Never mind, most unit test frameworks (and compilers) will take this in their stride, and let you know *precisely* what they think of your coding abilities (and common sense!)

OK. Take 2, you have now defined and written those interfaces, and the tests run; returning a dutiful set of 'F's. Abject failure is a given at this stage. That's good, because there's only one way things can go from here! Off you go! Busily re-writing your code to bring each and every one of those big F's to a full stop.

And, when your code is such that your test output is a green bar or chain of dots..... then you can rest from your labours, content that you have a set of reproducible results that prove your code meets the requirements, and that you will quickly know if any results subsequently become irreproducible as you start tinkering with the code to extend it, and make it look and work better (a pastime known as 'refactoring').

Now, while this is all very well, there is actually something else you can take away from all this. As you write your tests, you will occasionally come across an interface that is difficult to test comprehensively. When this happens, you can put your head down and write hundred of tests for every occasion. Or, you can rest your head in your hands, and have a think about why the interface is a tough one.

It may be that it's trying to do too much (so break it up). It may be that its effects are not immediately observable (so see how you can open things up). The point that may occur to you from this little piece of introspection is that your unit testing is actually encouraging you to think about your coding habits in a new and generally constructive way: the more open and modular your code is, the more readily testable it is. Well tested code can expected to be more robust code.

Like any infrastructure, it is always beneficial to provide unit testing. The most benefit is derived from installing it as early on in the project as possible. Like most infrastructures, there will be some who perceive this unproductive clutter as time consuming overhead. "Never mind these silly tests! We want to see measurable progress!" (usually measured by lines of code written* or number of features implemented)

Allow me to introduce such people to the concept of 'throughput', which sets the upper bound of your productivity as the value of goods/features/whathaveyous that have been passed on to the client.

The value of an untested feature, to a client, is ... zero. So, it doesn't matter how of these you have rattled off in the past week, your net throughput is effectively... zero.

Or, maybe that would be expressed as 'FFFFFFF Zero'?

When you think about it, zero Fs is the desired result.

* I would be profoundly depressed to hear that anyone is still using LOC as a serious measure of progress! But then, there is always something to be depressed about!

Internet Explorer: KT Dyslexia Bug

2007-10-29T17:04:00.000-07:00

This one's for anyone out there who's developing plugins for the KnowledgeTree Document Storage system. It serves as a placeholder for the following diagnostic image.

Full details of the problem, how to reproduce it, and (most usefully) the workaround, may be found in this KnowledgeTree forum entry.

Fun With AJAX

2007-06-21T18:10:00.000-07:00

Update: someone has come up with a slightly different solution to the problem discussed (See here)
Meanwhile...

... I mean, what other sort of experience would one have with Asynchronous Javascript And Xml?

Indeed, there's a lot to like about a technique that allows you to update your webpage with a snippet of information retrieved from the server *without* having to reload the whole sorry spectacle. It allows for much greater range of interaction with the user, as well. As I type this blog entry, a small message at the foot of the page is reassuring me that my draft is being stored automatically. How? Presumably a little java applet is being fired at regular intervals, which invokes an XMLhttpRequest (or XMLObject, if you're using IE 6 or earlier), and sends the current data back to the server.

Well, having eulogized the technique, what have I found to grouch about?

The Problem
As an old song put it: 'nice legs, shame about the face!'. One thing, in particular, has been annoying me about the callback mechanism. On just about every tutorial on the subject (and since there are plenty, rather than reinvent the wheel here, I suggest you go google 'Ajax tutorial'! ) you will see something like the following code:

var ajaxHandler = false;

onClick (element)
{try
{// Firefox, Opera 8.0+, Safari
ajaxHandler=new XMLHttpRequest();
}
catch (e)
{// Internet Explorer
try
{ajaxHandler=new ActiveXObject("Msxml2.XMLHTTP");
}
catch (e)
{try
   {ajaxHandler=new ActiveXObject("Microsoft.XMLHTTP");
}
   catch (e)
   {alert("Your browser does not support AJAX!");
}
}
}

if (ajaxHandler)
{ajaxHandler.open("GET", "http://www.etc.etc/myurl", true);
ajaxHandler.onreadystatechange = function()
                                                             {if (ajaxHandler.readyState == 4)
{// Handle the reponse!
}
}

ajaxHandler.send(null);
}
}

Perfectly workable as is, and quite adequate for a simple starting tutorial on how to make an AJAX call.

Except...

Except, how does the callback function know where to retrieve the results? It doesn't get provided as a call parameter. Nope! The callback function has to go grubbing around for a global variable! This is ugly, and I don't just mean in the cosmetic sense either.

It Gets Worse
As you gain confidence with javascript and Ajax, you will start to use the 'asynchronous' part of the technique more and more: making several Ajax calls simultaneously. Possibly making several calls to the same Ajax function simultaneously... using the same global object! As anyone familiar with multiple processing will attest, this situation is not just ugly, but downright bad.

While Quirksmode has an interesting account of what can happen, and how to avoid the worst of it, there is an astonishing paucity of advice on this topic. So, I had a bit of a tinker, and here is my solution.

Preliminary Tidying Up
First of all, I like a place for everything, and everything in its place. Just as a server process might create a short lived thread/process to handle each request it receives, I would like to see each Ajax call result handled by a single object.

If XMlhttpRequest passed itself to the call back function, we would have a solution (and I wouldn't have a topic). Can we simulate this?

Of course we can, by re-writing the above listing as a wrapper function that implements a chain of command. The main routine then becomes:

function MyCallback (handler)
{if (handler.readyState == 4)
{// Prettier, but!
}
}

function onClick (element)
{CallAjax (MyCallback, "http://www.etc.etc/myurl");
}

This separates the code handling AJAX, which now reads as follows.

var ajaxHandler = AjaxHandler ();

function AjaxHandler ()
{try
{// Firefox, Opera 8.0+, Safari
handler=new XMLHttpRequest();
}
catch (e)
{// Internet Explorer
try
{handler=new ActiveXObject("Msxml2.XMLHTTP");
}
catch (e)
{try
   {handler=new ActiveXObject("Microsoft.XMLHTTP");
}
   catch (e)
   {alert("Your browser does not support AJAX!");
}
}
}

return handler;
}

function CallAjax (callback, url)
{if (ajaxHandler)
{ajaxHandler.open("GET", url, true);
ajaxHandler.onreadystatechange = function()
                                                             {callback (ajaxHandler);
}

ajaxHandler.send(null);
}
}

An Obvious Solution...
Well, this might look a bit tidier but, apart from that, nothing much has been achieved: while the callback function proper now has a handler provided to it, it's still going to be the same handler each time a call is made. We want to create a request object each time we make a call.

So, would this do?

:

function CallAjax (callback, url)
{var ajaxHandler = AjaxHandler();

if (ajaxHandler)
{ajaxHandler.open("GET", url, true);
ajaxHandler.onreadystatechange = function()
                                                             {callback (ajaxHandler);
}

ajaxHandler.send(null);
}
}

...That Doesn't Work!
Unfortunately, no. The problem here is that, although a new handler object is being created, with its own callback object, the language is javascript, ie the command is interpreted, so the dummy function is referring to whatever the handler is at the time the callback was received, which probably isn't what you expected!

A Refinement...
However, there is a way around this: retain the global handler as an array, and refer to the required handler by its array index:

var ajaxHandler = new Array();

function AjaxHandler ()
{:
var handle = ajaxHandler.length;
ajaxHandler[handle] = handler;
return handle;
}

function CallAjax (callback, url)
{var handle = AjaxHandler();
if (handle >= 0)
{var handler.open("GET", url, true);
handler.onreadystatechange = function()
                                                             {callback (ajaxHandler[handle]);
}

handler.send(null);
}
}

Now we're beginning to cook! Each new request handler is stored in a static array, and the dummy callback function refers to it by its index. This is important because to refer to a handler specifically will cause the same problem as before: several callback functions referring to an indeterminate handler.

Why this is so has something to do with the way the dummy function is generated (it is a class) . To refer to the handler object itself is to refer to it by reference (ie the address of the temporary script variable) to refer to the array index is to refer to it by value (an integer). The latter approach ensures that each callback method refers to a specific handler.

Commentary
I haven't been using it long enough to give a definitive judgement but, so far, this technique seems to work well. I do have some qualms about that array of request objects growing in the corner like a stack of dirty dishes. It should get cleared away each time the page is refreshed. However, it may cause memory problems if the page persists for long. I am loath to suggest removing old objects from the array since it would upset the index references of current Ajax calls. If this is a concern, you could replace each object entry with an integer as it completes.

An Embellishment
One final embellishment to the procedure. Since we now have a single definition of a callback function, we can use it to perform useful universal tasks such as telling whether or not the server side script ran properly. eg, when returning the result as XML, this is readily done by checking to see whether or not the responseXML field was generated. If it wasn't, then the raw text may contain the warning diagnostics. Similar results can be achieved by searching the result Text field for error indicators.

function CallAjax (callback, url)
{var handle = AjaxHandler();if (handle >= 0)
{var handler.open("GET", url, true);
handler.onreadystatechange = function()
                                                             {var response = ajaxHandler[handle];
if (response.responseXML)
{callback (response );
}
else
{alert (response.responseText);
}
}

handler.send(null);
}
}

OK? Now go and play.

Final Listing
The following is the complete final listing:

var ajaxHandler = new Array();

function AjaxHandler ()
{try
{// Firefox, Opera 8.0+, Safari
handler=new XMLHttpRequest();
}
catch (e)
{// Internet Explorer
try
{handler=new ActiveXObject("Msxml2.XMLHTTP");
}
catch (e)
{try
   {handler=new ActiveXObject("Microsoft.XMLHTTP");
}
   catch (e)
   {alert("Your browser does not support AJAX!");
}
}
}

var handle = ajaxHandler.length;
ajaxHandler[handle] = handler;
return handle;
}

function CallAjax (callback, url)
{var handle = AjaxHandler();

if (handle >= 0)
{var handler = ajaxHandler[handle];
handler.open("GET", url, true);
handler.onreadystatechange = function()
                                                             {var response= ajaxHandler[handle];
if (response.responseXML)
{callback (response);
}
else
{alert (response.responseText);
}
}

handler.send(null);
}
}

Over Refresh

2007-05-30T18:24:00.000-07:00

Refresh is a nice feature on browsers to use when you've gone too far, or have updated the style in your page.

However, it can bite you on occasion.

What happens when you refresh a screen is that the browser resubmits the previous screen, and shows the result. This can cause a problem when the world has moved on. Such as when you've just clicked 'Add' to enter a new row of data to your database. On such occasions, the add request will be repeated, and a new and duplicate row will be added.

The first approach to fixing this problem might be to store the newly added row id in the form. If 'Add' has just occurred, and this id exists, then ignore the call.

...doesn't work. Remember, the refresh call is sending a cached set of post data. This will include the old values of any state flags you set to try and avoid the problem. What was right last time, therefore , will be right this time and...

The only solution to this that I have found is to store your state variables as a server side 'session' variable. Now, when your cached post data is received, it is checked against the current session state, which will have stored the fact that you just did an add with this data.

As someone once said: 'Life wasn't meant to be easy'

Spaced out variables

2007-05-20T21:08:00.000-07:00

As Jane Austen might have put it:

'It is a truth universally acknowledged that a young variable name in possession of a whitespace must be want of a bug correction report.'

It's a no-brainer. Something no programmer would contemplate doing, even in their most caffeine-crazed moments. So, when I got a complaint about an option which wouldn't work for a particular entry, I did quite a bit of head scratching and tracing before I spotted the problem.

The option in question was a piece of html representing a checkbox. It was generated via php as part of a report. Its value was taken from a database table, and was used to generate a variable.

This one entry was a reference code which just happened to have a space in it...

A case of what you don't know can hurt you!

Oops!

The Clayton's #if*

2007-04-13T00:28:00.000-07:00

Users of C++ will be familiar with the use of the pragma directive '#if' to optionally compile a section of code or, indeed, switch between two sections of code when debugging.

I've found an interesting little trick that allows you to achieve a similar effect using comments, so long as the language you're using supports both the line ('//') and block ('/*..*/') styles. The trick comes from how these two styles interact with each other.

Let's start by considering a simple 2 line statement block that has been commented out:

/*
printf ("Now you see it");
printf ("Now you don't!");
*/

What happens if the start of the comment block is, itself commented out?

//*
printf ("Now you see it");
printf ("Now you don't!");
*/ syntax error!

Not very promising, but let's comment out the end block as well:

//*
printf ("Now you see it");
printf ("Now you don't!");
//*/

Now, we see the two comment block markers are commented out, and the embedded block is active. It can be toggled on or off simply adding or removing an extra leading slash. So, to deactivate the block with one change:

/*
printf ("Now you see it");
printf ("Now you don't!");
//*/

The benefits of this are that you don't need to hunt through the code looking for the matching end of the comment block.

Now, we can extend this idea further. Let us split up the block so that one section or the other is not active. The trick here is to identify a character sequence that ends a comment and starts one:

//*
printf ("Now you see it");
/*/
printf ("Now you don't!");
//*/

In this case, the first block is active. The new line therefore acts as the start of a comment. However, simply by removing the first slash:

/*
printf ("Now you see it");
/*/
printf ("Now you don't!");
//*/

The first block is now commented out, and the second block is activated.

Have fun!

*For non-Australians, 'Claytons' is a brand of non-alcoholic beverage popular in the eighties. It was billed as 'the drink you have when you're not having a drink.'. The term 'a clayton's xxx' has passed into common use, with just about anything being substituted (literally!) for 'xxx'.

php: When ob_start Is Not Your Friend

2007-03-30T00:09:00.000-07:00

When programming for the web, you are sooner or later going to start having to look beyond the contents of <body> and messing about with html headers.

And, in php in particular, you will soon encounter the dreaded error which arises when you call 'header()' after having output some characters.

Fortunately, this problem is easily fixed by a call to ob_start, which turns on output buffering and stores and collates your html until it's all done. Headers are placed they're meant to be and all is sweetnes and light.

One common use of headers (which I have just started to get into) is to allow someone to view a file by streaming it through the browser rather than just setting up a url link. (as you might want to do when access to a particular set of files is restricted)

I'm not going to go into great explanation on how this is done; other and more experienced heads have done this very well already (eg: Leon Atkinson's 'Tricks of the Trade'). I'm more interested in describing a subtle but very annoying gotcha when you start doing this with output buffering in play.

You see, if you're streaming a binary file (like pdf or jpeg) for viewing, the binary data has to be very precise or the result will be unintelligible garbage. You must be very sure that no other data sneaks into the stream.

Data such as might be output prior to header calls...

With ob_start on, you will get no warning of this and, like me, you may spend a good deal of time scratching your head wondering why this stuff doesn't work and probably cursing IE (which is a bit more sensitive to this than is Firefox).

Without ob_start you will get an illuminating error saying that there already data in the output buffer. In this situation, *any* prior output is poisonous. Not just the result of print and echo statements, but anything that sits outside the <php? and ?> tags. html tags, spaces, carriage returns, anything.

Fortunately, the error message will usually give you enough information to track down and eliminate the rubbish.

Spurious output *after* the headers is probably less dangerous, but it's probably just as well to get rid of that as well.

Hope this helps someone out there.

The Links That Bind

2007-03-27T21:18:00.000-07:00

My daughter is usually driven to and from school during the week by her nanny. For this reason, the child seat usually stays in the nanny's car until the weekend.

This has been fine up until recently, when the nanny's car started going through a rough patch mechanically. Twice, in the last fortnight, I have received a call that the car has broken down, or won't start. Apart from the inconvenience of taking 'little Missy' to school ourselves before going to work, we have had to retrieve the means of getting her to school: ie the child seat! This, at a time when an already overloaded traffic system was thrown into chaos by the domain tunnel closure, made for even more time lost.

We've actually been pretty lucky wrt absences. If the nanny has called in sick, it's usually been at the start or end of the week, and we have had the seat. Not this time!

The simple interim solution has been to agree that the seat is to be left at our house in the evenings.

So, you might be wondering what this little domestic drama has to do with bad programming? Simply to point out that, while it might be convenient to have underlying links between class objects that have a lot to do with each other, greater flexibility is achieved when you define the links explicitly with each transaction.

Just as we now put in the child seat each morning and take it out again in the evening, always think about passing a reference to another class as a parameter and don't expect it to be stored, or picked it up from somewhere. The onus on providing the necessary information for an object^* to do its job should rest with the client program. That way, your objects can exist a little more independently of each other.

And so can you!

^*For the record, I do not consider my daughter's nanny as an object!

Ons Ain't Ons

2007-03-19T05:05:00.000-07:00

An interesting little javascript gotcha bit me just recently.

... only I'm not sure whether it was javascript, or Firefox, or (oh, surely not!?) Internet Explorer.

To begin at the beginning, I had a fairly straightforward piece of javascript code working quite nicely in Firefox. Then I tried it in IE, and encountered a truly bizarre disconnect (literally)

What it boiled down to was that the js script was delayed in execution after clicking a checkbox: You'd click on the checkbox and nothing would happen. Then you'd click on something else, and the script would wake up and hurry to the bus stop.

After a bit of poking around, I found the problem: for reasons that escape me now (probably taking the lead from another script meant for use in a combo box), I was using an 'onModify' event to trigger my script, rather than 'onClick'. The problem this was cauing me arises in the way that different browsers handle these events.

Firefox thinks you change the content of a checkbox when you click on it, so it runs the script immediately.

Explorer, on the other hand, decides that changes to data should be acted on when the control has lost focus (and no one's looking), so it waits.

Solution: use 'onClick' whenever you wish to react to changed content of a checkbox.

One is inclined to give in to the temptation to knock IE6 because it's the done thing but, to be honest, I couldn't call the IE behaviour explicitly wrong and I don't know what, if anything, the standards say about when event handling should occur.

What's This About?

2007-03-13T17:00:00.000-07:00

"To err is you, man!"

As part of my general online presence, I very occasionally print a couple of coding suggestions.

Prompted, in part, by Tim Bray's brief note about 'Beautiful Coding', I thought I'd start gathering these together in one spot.

They won't be anything to set the world abuzz, but there have been times when I've trawled the web looking for how to handle that 'obvious' situation, only to find my brain seems to operate in widely divergent ways to everyone else's.

Of course, this is an affectation: I'm sure there have been others that have asked some of the questions I have. So this is an attempt to answer them.

Now, I'm not sure whether it's better to do this as a blog, or as a wiki. At the time of writing, my thinking is obviously inclined to the former. Plus, it allows the passing traffic to offer the occasional friendly addendum and raspberry (..NB: I did say friendly!)

"Learn from other people's mistakes. It's less embarrassing that way."