Every other day it seems, I have to suffer an assault of stupidity in one form or another. This time around, I am suffering the foolishness of shipping companies.

I send and receive packages on a regular basis … you’d figure that this common task would (and should) be a trivial thing by now …

-

Stupid shipping company #1: Canpar.

When receiving packages, it is rare that I can choose the shipper. But when I do have the choice, I ask for anyone but Canpar.

Why does Canpar suck?

1. They only make two deliver attempts (all the others make 3) and then they’ll ship your package back.
2. They cannot give you a time of delivery during the day – they can’t even give you a ball park time!
3. They have no easy to access pickup location to get packages – unlike the post office.

My story:

I get a delivery notice on Monday saying they missed me and that they will back Tuesday in the afternoon. So I wait all day Tuesday because if I miss this 2nd attempt, the package gets shipped back.

Tuesday comes and goes with not so much as a phone call. I call them and make arrangements for the package to come Friday. Friday comes and I wait all morning and into the afternoon, with still no word when the package will arrive, so I give them a call.

I figure that in the age of cell phones, they could call the driver and we could coordinate … nope: Canpar tells me that they can’t reach the driver! That high-tech capability (of calling drivers via cell phone,) seems is only for the local pizza delivery guy.

So I sit here waiting, wondering, if Canpar will stiff me yet again!?

The Post Office Rocks

It’s sad to see when a government entity (the post office,) is able to provide a far superior service than a commercial entity. We all know that government is insanely wasteful and inefficient. But let me tell you, the local post office kicks most private /commercial shipping companies asses:

• The post office has easy to find (they give you an address on the slips) locations to pick up packages.
• Pick up locations are always close by.
• Shipping via the post office is much cheaper.

-

I wonder if I will get my package today?

Stefan Mischook

It’s common to hear a lot of talk in the Java community about the importance of:

• scalability
• re-usability
• maintainability

These are important goals (often never reached in real projects btw,) but I wonder why no one ever talks about something that should be considered at least as important: understandability.

Some people might say that understandability would fall under the maintainability category. After all, for code to be maintainable, it should be easy to understand … right? Unfortunately in the real world, Java folk (seems to me) must have forgotten this all too important rule of good programming.

No, not another XML document!

These days, to get even the simplest of Java applications going, you need to do a lot of plumbing work which often includes setting up property files …

When I start filling in XML property and descriptor files, it feels like filling in acquisition forms to buy a new pen … I get this nagging feeling that I’ll have to fill out the XML files in triplicate and get them ok’d by 3 different people.

-

It shows that Java has been designed by huge corporations in a committee process (JCP) – Java ‘feels’ like a big giant corporation!

In it’s youth, Java was nimble language full of possibility and optimism. But like hippies from the 60’s, over time the oppression of corporate reality has turned this spritely language into a pedantic sloth.

So what’s next?

I don’t know what the next big language is going to be. But I do know it will be a scripting language that will:

• Have dynamic typing.
• Have a rapid feedback loop – thus not compliled.

Stefan Mischook

One of the disturbing mindsets in software development and web design today, is the sacrifice of practical concerns in favor of theoretical constructs.

Case in point:

Recently a young friend of mine (who is studying computer engineering,) told me an interesting story about a class project where each student had to produce a piece of software … the results, and the professors reaction to the results, are interesting.

Sad but true:

When all things were said and done, only one student was able to produce a working application. The irony was that this student got a failing grade because his code did not meet certain theoretical constructs!

The above example illustrates a problem in the way many programmers think: putting theory over practicality.

With that failing grade, the professor has sent the wrong message to his students: that results are not as important as being true to the theory. And people wonder why so many Java projects fail…

Why theory over practicality is total bull:

1. Broken but theoretically correct software, doesn’t pay the bills.
2. Theories are constantly revised; so don’t be to quick to marry them.

I think the first point is self evident, so let’s look at the 2nd point and consider one of the fundamental theories of modern software development: inheritance.

At one time in the distant past (5 years ago,) design-by-inheritance was the theoritically correct method of software development. At some point though, people began to discover that inheritance had its’ problems and now (in many cases,) design-by-interface* is the preferred method.

Theories change

The shift from design-by-inheritance to design-by-interfaces is but one example of how theories are constantly updated to reflect practical realities.

If anything is consistent of about software development, it’s that theories change. So don’t sacrifice practical application today, to satisfy some theoretical construct that may very well be discredited tomorrow.

-

Stefan Mischook

1. ‘bull’ is a technical term that conveys a complex meaning in a terse and well understood format.
2. In Java, interfaces are classes void of method implementations.

Using XHTML instead of HTML to build web pages is one of today’s web design fads. Like other silly practices promoted by the web standards zealots (using CSS hacks for example,) this is something that will create extra work for no real PRACTICAL advantage and may even create problems for you!

People have been sold on XHTML with the typical web standards arguments that have a tendency to ignore the ‘reality in the field’. In this article I explain why you should stick to using good old HTML for the time being.

First, what is the reality today?

1. Internet Explorer 6 and 7 (among other browsers,) will NOT render XHTML.
2. If you use XHTML, DOM scripting and AJAX will be much more trouble.
3. The supposed advantage (if ever realized,) are really minor at best.

Let’s consider these points:

BROWSERS AND XHTML

1. When you serve XHTML to most browsers, your crazy-cool XHTML will be treated like ordinary HTML, thus loosing all the supposed advantages of XHTML.
2. If you want browsers to treat XHTML as XHTML, you need to set the MIME type to: application/xhtm+xml. The problem is that IE6, IE7 and other browsers, will give you the ‘download this document’ pop-up box instead of displaying the page in the browser window.
3. If you’re really intent on using XHTML, you could use scripting to sniff out browsers and change the MIME type accordingly, but this would lead to script-branching – if you wanted to use any DOM / AJAX scripts … more headaches.

HOW DOM SCRIPTING IS MADE HARDER WITH XHTML

The issue that stands out the most for me (and is enough for me to not use XHTML,) is that you can’t use ‘document.createElement’ to create new elements with the DOM if you are using XHTML.

In case you don’t know, ‘document.createElement’ is one of the key methods of DOM programming and by extension AJAX.

-

This topic was recenty discused on the message board:

XHTML OR HTML

Stefan Mischook