Back from a weeks holiday, I've decided to throw together a post which summarises some interesting but essential things about XSLT. That one will have to come a bit later, but there is space for a little something right now. I held a four day course a few weeks back, and from that I noted down what people struggled with the most, and the winner is;

The difference between an element and a node

It seems I keep coming back to this. People think in elements - because we're visual people who all read XML - when in fact the world of XSLT thinks in nodes. But what, then, is a node, if not an element? Well, it's an element, too. :) Ok, let's look at some XML;

Hooblas!

When this XML gets passed through and processed by the XSLT processor, it does not mean we've got an element node with some property or something with the text in it. It all becomes nodes;

node : element : "item"

node : element : "item" : text : " Hooblas! "

node : element : "item" : attributes : none

Both text and attributes (and a few others) become sub-nodes of the "item" element node, and they may or may not be empty. In our example, there is something in our text node, but nothing in our attributes node. That means that the following XSLT code;

does not mean that it selects "what's in the 'item' element" just because there will be that text in the output. Here, again as so often happens, the built-in (and hence, hidden from the aspiring XSLT sycophant) template rules kick in and selects sub-nodes, and tries to match on those, and since the built-in match for just text kicks in, people are lead astray thinking "selecting 'item' is selecting that text inside it". Not so. Try this rule somewhere in your template, and see what happens;

That's right; no text output. If we change our before given rule to;

and it magically appears again, simply because this time, we selected the sub-node of 'item' called 'text', and displayed the value of that. So, the tip of the day is; turn off built-in rules until you understand them by doing;

It just might save the day. The next tip will be about avoiding adressing the root node. Fun, fun, fun.

Permalink (Mon, 11 October 2004 13:00:00 GMT)| Comments (0) | Programming

As a follow-up to and closing of my journey through , I'd like to quote (quite a bit) from what I feel is its strongest and most shattering argument for why we need to stop the world for a moment and re-think our strategies;

The objectivist Legacy (pages 183-184, paperback edition, 1990)

According to the objectivist paradigm, true knowledge of the external world can only be achieved if the system of symbols we use in thinking can accurately represent the external world. The objectivist conception of mind must therefore rule out anything that can get in the way of that: perception, which can fool us; the body, which has its frailties; society, which has its pressures and special interests; memories, which can fade; mental images, which can differ from person to person; and imagination - especially metaphor and metonymy - which cannot fit the objectively given external world.

It is our objectivist legacy that we view rationality as being purely mental, unemotional, detached - independent of imagination, of social functioning, and of the limitations of our bodies and our memories. It is our objectivist legacy that leads us to view reasoning as mechanical and to glorify those kinds of reasoning that in fact are mechanical. It is our objectivist legacy that leads us to view machines that are capable of algorithmic computation as being capable of human reason. And it is our objectivist legacy that we view it as progress when we are able to structure aspects of our physical and social environment to make it more like an objectivist universe.

[...] People have been treated as numbers and collections of records for a long time, and they will be treated much more so in the future.

Such treatment serves an important function in our society. There is a major folk theory in our society according to which being objective is being fair, and human judgement is subject to error or likely to be biased. Consequently decisions concerning people should be made on "objective" grounds as often as possible. It is the major way that people who make decisions avoid blame. If there are "objective" criteria on which to base a decision, then one cannot be blamed for being biased, and consequently one cannot be criticized, demoted, fired, or sued.

Another reason for the attempt to construct our institutions according to objectivist metaphysics is that is is supposed to be efficent. In some cases it may be, in others it may not be. But an awful lot of time and effort goes into trying to make matters of human judgement fit what are supposed to be objective pigeonholes. If the classical theory of categorization is not correct, the then wholesale importation of objectivist metaphysics into our institutions may not only be inhumane, but it may in the long run be an inefficent way for human beings to function. At the very least we should be aware that our institutions are being structured in terms of a perticular metaphysics and a psychological theory of categorization which, as we shall see, is highly questionable.

One of the reasons why the classical theory of categorization is becoming more, rather than less, popular, is that it is built into the foundations of mathematics and into much of our current computer software. Since mathematical and computer models are being used more and more as intellectual tools in the cognitive sciences, it is not surprising that there is considerable pressure to keep the traditional theory of classification at all costs. It fits the available intellectual tools, and abandoning it would require the development og new intellectual tools. And retooling is no more popular in the academy than in industry.

For people working with SemWeb related technology this implies "taking a long hard breather" before continuing. Lakoff uses the rest of this book to crush the idea of classical categorization theory, giving strong evidence and use-cases and - probably most importantly - common sense and "Duh!" moments.

Permalink (Wed, 21 July 2004 13:00:00 GMT)| Comments (3) | Knowledge and information General Topic maps Programming

There are of course many different views on what the best programming language might be, or even might be like. There is the battle of the two major - Java vs. C# - and then the bickering of all the rest of them; strongly typed, loosly typed, OOP, functional, pragmatically structured, strict type, low syntax impact, semantic syntax, lingustic semantics, virtual engine, compiled to binary, interpreted, half-baked, and on and on.

Java is in the OOP camp, compiling to bytecode which is run in a virtual machine. And I'm back in the saddle after doing mostly XSLT, PHP, Python, JavaScript and HTML for the last year or so. Funny, but getting back to Java feels a bit limiting to me, but I'm sure that's only due to the strongly typedness of it all; I'm sure that will squash a few could-have-been bugs.

The funny thing about Java is how complicated it feels. Sure, I can work out exactly what is going on, where, why and how, but it just feel ... complex, and I mean in all the wrong places. Why should it be so hard to do string manipulation, anyways? Or even testing on types? Or converting between types? The strongly typedness of it all is my biggest ... uh, mumble about it right now. Don't worry; it'll pass in a day or so.

Oh, and this is also my posting number 100 to this blog, so happy anniversary to me.

Permalink (Tue, 13 July 2004 13:00:00 GMT)| Comments (4) | Programming

If you are interested - even remotely - in programming languages, you must read this piece; it is important. Bill de HÓra delivers a piece where he talks a lot about Lisp, how good it is and how it is the future pinnacle of programming languages, even though it is older than C++. It is also as much about infrastructure, corporate culture and community behavior as languages, and is a very interesting piece. it certainly makes me more curious about Lisp, although I have studied and worked with it in the past and discarded it because it didn't fit into my "easy to learn, easier to master" category. Anyway, blog this piece. it is good stuff, and well worth the read.

Permalink (Mon, 5 Apr 2004 13:00:00 GMT)| Comments (0) | Programming

Some say PHP ain't a serious tool. I can't agree with that, but the fact remains that PHP lends itself to horrible hacks. To avoid horrible hacks you need to be structured, disciplined and hasten slowly, three qualities not associated with the hoards of PHP programmers out there. Anyways, there is a handful of tricks I use in trying to keep my PHP lean and mean.

Now, the reason you hack is to get something up and running quickly. Very often we create a prototype that according to legend has it will be a prototype upon a new specification is molded. This never happens; the time we've got and the push we receive often result in the prototype code is refactored into whatever project have you. This lends to crap design and poor code.

Crap design

Every little PHP functionality I put in a file named appropriatly, even if the files name is "crap_workflow.php." Even the smallest modularity is gold when you refactor your crap bits into usable bits. I also create a set of global variables that store the place to where these files can be found. Hence, includes galore;

define ( "MY_MODULES", "/usr/local/b/bu/php/modules/" ) ;

require_once ( MY_MODULES."crap_workflow.php" ) ;

The MY_MODULES you define at the top-level PHP file can be used willy-nilly where you need it, and it will keep your nested directories from screwing up.

Error checking

PHP5 promises us better error checking, but until then (and given the vast amounts of existing PHP code out there) here's what I do; have all warnings, errors and notices ON. Yes, turn all flags on. Ahooogha! Ahooogha! This practice will yield heaps of messages about unset this and unassigned that that you know - deep inside - will still work, because that is the way PHP works. Which is a selfish stupid trap to fall into, of course. Here is the remedy;

Initialise all variables with blanks until used. In strongly typed languages like Java and C/C++ this is a must, and it has proven itself quite valueable to me over and over. Yeah sure, that you don't have to gives you the freedom not to. Luckily with all warnings and messages turned on, you'll see all the undefined clutter you've got lying around. Just initialise. And if you keep these to the top of your functions and methods, the better;

$someVariable = "" ;

Further, if you come to a spot where you know that often you will have errors but due to time restrictions (we are hacking at this point, you know) do this;

$someVariable = @someFunctionThatMightFail() ;

Notice the '@' in front of the function; this turns off errors and such for this function only. When you later refactor this, it is this very '@' that becomes the error handler. It makes it easy to catch future 'Oh, oh!'s.

OO

The dream of true Object Oriented programming falls slightly short in PHP up until the upcoming PHP5, but it is still a very nice way of abstracting data and interfaces. Keep your classes in seperate files (as explained above), and include at will. Now, dependencies is the biggest bum-biter here, so if you don't have to have one object depend on another, then don't. It is a source of many evil bugs.

Wrappers

The best way to survive a horrid prototype -> refactored working project is to put wrappers around things you don't understand or that is somewhat complex. (And complexity is metered in 'if I look at this code in a month, will I still understand it?' If no, then you need a wrapper around, so it is ready to undergo serious refactoring in the future;

function zxDefaultFactoryNose ( $factory, $trigger, $param, $diff ) {

... some horrid complex code here ...

}

You have the above, and need a wrapper;

function oneWayIKnowThisWorks ( $singleParameter ) {

$factory = getFactory ( $singleParameter ) ;

$trigger = "23;45;34" ;

$param = "" ;

$diff = "xt=trim(4)" ;

zxDefaultFactoryNose ( $factory, $trigger, $param, $diff ) ;

}

See? All ready to be refactored at a much later stage when the functionality of zxDefaultFactoryNose() a) gets figured out, and / or b) expands.

Comments

For super-geeks, there is JavaDoc that extract comments from source code, and builds source-code documents from them. You can do the same in PHP, wheter you'll actually use the extracting tools to get them; the comments are very handy, so even in a quick prototype, take your time to write something ;

/**

* oneWayIKnowThisWorks function; wrapper for complex function zxDefaultFactoryNose().

*

* @param string $singleParameter Explanation of this parameter

* @author Alexander Johannesen <>

*/

function oneWayIKnowThisWorks ( $singleParameter ) {

...

}

Naming

A pet burden amongst many geeks is the naming conventions of variables and functions/methods. Here is mine, in short;

$aListOfFish ; // Array

$sName ; // String

$vSomeValue ; // Value; int or otherwise

$oUser ; // Object

The names I try to make understandable as much as possible. Being into Topic maps and the semantic web, I try to create names that carry some semantic value. So instead of;

$i = 0 ;

for ( $i=0; $i<100; $i++) { ... }

I would do;

$currentItem = 0 ;

for ( $currentItem=0; $currentItem<100; $currentItem++) { ... }

Yes, I type a few more characters that way, but when you go back to your code - and especially considering the complexity inside your for loop (and given we're talking about prototyping here, I can only speculate to the horrors inside ...) - these more semantically valued names will make your code self-explanatory instead of a cryptography excercise. Oh, and this is one more variable you don't have to refactor later. Save yourself some time.

And there you have it; my quick and rough guide to quick and rough programming in PHP. Next; how to write short Java code. (Hmm, no wait; that is quite impossible. Nevermind.)

Permalink (Thu, 11 Mar 2004 13:00:00 GMT)| Comments (3) | Programming Methodology

Was browsing Andy's site - who's coding the MozWho - and found a reference to this nifty DHTML graphics library which is looking awfully impressive. I'm sure to experiment more with this very soon.

Permalink (Mon, 12 May 2003 13:00:00 GMT)| Comments (0) | Programming

The purpose of this article is to a) give people - like project managers, sales, customers and other developers - an insight into what a web user interface developer does and doesn't, shoulds and shouldn'ts, and b) give web user interface developers insight into methods, best-practices and decisions me and my colleagues at bekk not found. do every day.

Permalink (Mon, 28 Apr 2003 13:00:00 GMT)| Comments (1) | Interface and interaction design Project management Programming Methodology

Stumbled upon this item on Ben Meadowcrofts page from january where he found info on a thesis that dealt with "How many pages out there validates?" Shocked to know that less than 1% validates?

To be honest, I wasn't surprised with the results at all, and those numbers say a lot about the state of the net these days. People just don't care about validation, and I feel the need to increase the push on people in understanding the importance of it.

Permalink (Thu, 20 Mar 2003 13:00:00 GMT)| Comments (0) | Programming Standards

This excelent article, written by Marc de Graauw, is a great way of lending topic maps to people who live in the world of relational databases. Quite a few of the programmers at work came back with a "Aha!" after reading it, saying they finally understood what I have been talking about for the last year.

Permalink (Thu, 13 Mar 2003 13:00:00 GMT)| Comments (0) | Programming Topic maps Content management