Dan’s Little Space in the Cyber: In Exile

OK, just a few days late. Such is life.

I have still been playing with these fractal triangles, but not in your average programming language. Work’s been pretty busy, so lunchtime Scheme has taken a back seat to cleverly disguising the fact that I’m eating a sandwich while on the phone by pretending it’s a bad line. So, my limited evening space has been used to throw together a triangle using a tool that pretty much everybody has on their computer, but probably has no idea what it is. I’m talking about XSLT, that bastard child of the XML revolution.

XSLT, or eXtensible Stylesheet Language Transformations, are a method of turning one XML document into another XML document. That may seem about as useless as giving Tim a book on Ruby, but there are lots of different XML documents out there. I’ve used it before to transform XSD and WSDL files into XHTML, the form of XML a lot of us are actually used to. I also hear people build proper websites with it.

As I’m more interested in the technology than actual facts, I’m going to use Wikipedia for research here. Apparently, the language’s design is heavily influenced by functional languages, and “text-based pattern matching languages like SNOBAL and awk”. I’m not entirely how much of that you should take without salt, but I do know it’s powerful once you’re used to it. Oddly, it’s one of those technologies that Internet Explorer implemented before anyone else, although it’s first attempt rather far removed the actual specification of the format.

In this particular case, I had the brain wave that, you know what also is an XML based format? SVG! Yes! Now, can XSLT do recursion? It can? Hell yeah! In fact, a little research reveals that XSLT is fucking awesome. It’s like html on crack, really. Some playing around built a working model, and some further research revealed somewhere in the region of 2000 other people have had the idea before me.

Odds are on you’d like to see this baby. Or not. But trust me, it’s pretty cool! Grab this file, and this one. DO NOT LEFT CLICK THEM! Save them. On your desktop, home directory, whatever. Then, load the XML file in a convenient text editor. The ‘depth’ option is the crucial one here. ‘3′ loads in a second on my computer, ‘5′ takes a few moments, ‘10′ took enough time for me to get another beer… looked damn cool when finished though! To be honest, anything above 9 won’t yield much of an improvement. Anyway, to actually view the triangle of doom open the XML file in Firefox. It should find the stylesheet, generate an SVG file, and display it. IE can do it too, but it gets confused by SVG. Close the window once your done marveling, ’cause it’ll eats memory like an elephant eats peanuts.

It’s pretty cool, but it’s not great. The algorithm is pretty memory hungry, and it’s certainly not an L-System. That’s kinda my holy grail, but I think I’ll share this with the world:

What it says is: ‘Free meal to the first person to draw a sierpinski triangle using Lisp, Zelda ML, Scheme, VB, Python, Ruby, BrainFuck, C++, Perl, Java’. Basically, I’m offering to cook (or purchase, depending on the person. Work that one out, bitches) a meal for the first person to knock one of these babies up, in any language. In theory, it’s not particularly difficult, but it’s quite a cool little challenge involving recursion. Enjoy!

As a sideline, I’m altering the last bit. Instead of ‘BONUS POINTS: Draw one using XSLT & SVG or Postscript’, I’ll give a pint to the person who builds a more efficient triangle than mine using XSLT. The Postscript bit is covered in the first challenge.

PS: Ben raised the point that he’d like to do it in Lisp (or whatever it was, I was drunk at the time), but he doesn’t know any drawing libraries for the language. Well, on one hand learning a new library is always informative. On the other, knock together a quick function that draws lines using asterisks and bob’s your uncle.

Food is on offer here people! Hop to it!

Over the last few lunchtimes at work, I’ve been idly learning Scheme, using the ‘Dr Scheme‘ learning environment. Learning the basics of Scheme can be done in an afternoon, but learning to think in Scheme, takes ages. I’ve been looking for something to code that allows me to get really familiar with the language that doesn’t require me to learn a load of libraries as well. I decided to try and draw a cool little bit of maths.

The Sierpiński triangle, named for it’s creator Wacław Sierpiński, is a fractal. It’s long been a favourite shape of mine, and I have a tendency to idly doodle it when I’m bored. It’s super-easy to draw, it basically being a load of nested triangles. I’m not going to detail it here, but imagine the TriForce from Zelda. Now, replace each triangle with another TriForce. Then replace each resulting triangle with another TriForce. Then replace … you get the idea. It’s a fractal, so for the actual Sierpiński triangle you must go on for infinity, but given that people have important things to do (grow moustaches, for example) you normally bug out after a few iterations.

Fractals tend to be very pretty; take a look at the Wikipedia page about them. They also tend to very simply defined, normally some kind of mathematical functional that you apply recursively. These two properties made me think that these would be lovely little problem to solve using Scheme. It’s not exactly trivial, and forces you to think about how Scheme, works in order to do it efficiently. Scheme, by the way, is much more efficient than many other languages when it comes to recursion. There’s something you didn’t know before.

I decided to do a little research (read: wandered around Wikipedia) on the Sierpiński triangle, and fractals in general. And, my god, fractals are fucking crazy. They are closely related to things like chaos theory, wherein complexity arises from simple actions. Things like Pascal’s Triangle have crazy mathematical relationships within the numbers. I could read for hours about them, and some the images you can generate are simply mind blowing. In what other academic field could you produce an image like this and not be either a) an arts major, b) working for NASA, c) on psychedelic drugs or d) all fucking three? For pity’s sake, not only do we have fractals inside us, we live on one.

There is a related widget in Mathematics known as Lindenmayer Systems. Basically, you define an initial state and a set of rules, and then these are applied to the initial state. The trick is that the rules are defined so that they contain references to other rules, or to themselves: they are recursive rules. L-Systems tend to produce self-similar patterns, and fairly fractal patterns. You can write an L-System that generates a Koch curve, or a Dragon curve, or even something that resembles a Sierpiński triangle.

I love complexity coming from simplicity. If you think about it, it is what computing is largely about: from ones and noughts we have Half-Life 2. Non-trivial programming languages are basically just an over-defined rewrite system, much like an L-System after a manager has been through it.

So what happens when you design a programming language that strips away the crap; that returns to the purity of the L-system? What happens if you surrender completely to the power of recursion as your only programming function?

You get Scheme, that’s what.

And once I’d discovered this coolness, I was determined to write something in it. That’s tomorrow’s blog post.

OK, again I’m not writing the thought provoking post I was intending to send out into the ether today. Normally, I don’t like just linking-and-leaving, preferring to have at least a little analysis of whatever weirdness I have discovered, but today’s find is just pure, unadulterated genius:

http://www.ugcs.caltech.edu/~wenz/

Bonus points/pintage for the first person to work out how I got to this site from reading about Lily Allen. In a bizarre twist, it’s probably not how you think.

This isn’t the post I was going to write today. It isn’t even a post at all, merely a short story with an ending that is probably rather unsatisfactory for anyone but me.

For Christmas, my brother bought my mum a microphone and headset, with the intention of communicating via Skype. After a couple of false starts it worked, and she is now a little bit more online. Still no concept of what her ‘homepage’ is (despite having an ECDL), but there we go.

Now, I have never used Skype before. I’ve always been a bit wary of the company and it’s software, and I don’t particularly like making phone calls anyway. However, orders were given from on high and now I own a particularly shit microphone. I wandered over to the Skype website, and was delighted to find a download for linux; in fact, there are a variety of builds for different distributions, and the one I’m using is for Ubuntu Feisty Fawn. I’m actually using Gutsy Gibbon, but it seems to work.

The problems came when I actually tried to sign up. ‘Pick a username’ it said. So I did: I chose my name, danbjorn. BUT:

Who what now? Someone has my name? At first I assumed that I must already have an account, and spent a blind five minutes randomly trying likely passwords, but to no avail. It appears that some little tyke has taken my name.

Now I know that I share my name with a newfoundland dog, and a particularly fetching class of ice breaker, but I’ve always assumed that ‘danbjorn’ was unique in the world of names!

I was particularly non-plussed by the whole idea. I really want to find out who this person is, and ask them to politely change their name. I never will, I’m sure, but it’s still quite aggravating.

The upshot of all this is that on Skype, my name is ‘therealdanbjorn’. Hah! Take that, namesake.

I haven’t actually made a call yet; that is an adventure for another time. I may even tell you about it!

I’ve been playing a lot recently with GreaseMonkey. The product that produce at work has a couple of niggling UI issues, which I fixed using GreaseMonkey, and from then on I started seeing problems everywhere. Practically every site I visit now is hacked apart using Stylish and GreaseMonkey so they show me what I want to see, not what the author thinks I want to see.

I’ve also been playing with the new Google Charts API. If you haven’t come across it, then it’s a really nifty web service that generates an PNG image of a chart for you, using only parameters supplied in a simple (if lengthy) URL.

I also read Planet Termisoc, if only to see what Ben is ranting about this week.

What happens when you put all three together? A GreaseMonkey script that generates a bar chart of how many posts each person has made in this particular Planet feed. Here it is:

Ben ass-whoops us all, with a stonking 34 posts. Gem and I have somehow find ourselves beaten by the podcast…

The script itself is a complete and total hack: it collates the data through a series of painful XPath queries. If I get some time, I’d like to hack the Planet code a little so that this graph can be generated by the server, and then we can have a constant little reminder of who the blogging king is.

If any wants to take a look at the script, it’s currently here, but I intend to make it a bit less of a hack soon. Still cool though.

danbjorn out.

I finally got around to reading the Encourage Women in Linux FAQ that Ben blogged about the other day. It certainly made me think; especially when I actually stick my head up and notice that my department (admittedly only ten people) is completely male. In fact, less than a quarter of the staff in the entire company is female. Evidently something has gone wrong somewhere.

Some introspection revealed that yes, I am also a horse’s arse. I think it would be a good New Year’s resolution to take the issues raised in the FAQ to heart.

However, I do believe that Ben failed to note the most important part of the FAQ: the link to LinuxChix, which has possibly the best logo of any website. It’s a giant robot penguin, that you can drive! I must own one; with it, I shall control the world! Buahahaha!

Last Monday, Tim did a tutorial on Borland’s Delphi programming language. While it wasn’t perfect (bear in mind it was his first tutorial) it showed promise. Less focus on boring stuff and things we already know next time, Tim.

What the tutorial highlighted to me was the importance of widgets. GUI widgets are developer conveniences that allow you to knock together a GUI in minutes. Borland has their own Visual Component Library (along with open source efforts like JVCL and JCL) to give Delphi and their other products graphical interfaces, but they are largely just object wrappers around existing Windows components. One should note that such wrappers are needed for newbies: coding in raw Win32 API takes some practice (I can’t do it without a long run up…).

However, when using these toolkits, you must remember to not allow the widgets to force a particular design of your user interface, nor your code. True, they provide conveniences, but you should not be acting as a crutch for your code. If you’re doing heavy validation in the UI layer without also checking it at the model level, then there is something seriously wrong with your architecture. I’m not saying that your code should dictate your HCI plan, just that the specific brand of widgets you are using should not be dictating anything.

There’s one widget in particular I wanted to talk about today: MaskEdit. In theory, it’s a nice little control. Basically, it’s an edit box which only allows entries formatted a certain way. It will actually enforce this as you are entering data, the idea being to restrict your entry to minimise the need for validation. For example, you could set up a MaskEdit control to only accept dates like dd/mm/yyyy.

The problem is that you are asking the user to do more work (format data a particular way) to alleviate the amount of code you have to write. There is almost no excuse for asking the user to do something the computer should be doing for her.

It’s bad enough when you get an error on a form saying ‘please format your phone number like this, but the MaskEdit control will actually do it on the fly. Trying to enter a number where a letter should be? Bad user, you shall have a beep! Missed out a space? Ooh, you’re just naughty. You are physically restricting the user from doing something they should be able to do: an edit box looks just like any other edit box, so reducing what you can input is removing control from the user. Anyone who has taken a HCI course will know that removing control is going to increase frustration in the user, and make them hate your program.

So, what should I do instead? There are two options. One, validate properly! Use a proper edit box, or even better use a control that fits the context of your data. People shouldn’t have to type a date, they should be using a calendar. Don’t ask them to enter a county, give them a list. Don’t ask for a number, give them something to drag¹. Validate at the model level - never validate at the view level, and try and delegate as much as you can at control². You will need to handle input from a date field completely differently from a text field; from number field looking for a time compared to one looking for a voltage. Think about how your controls relate to data, and design the connections accordingly.

Even better though, is to follow Postel’s law:

be conservative in what you do, be liberal in what you accept from others

I would argue that this approach is dodgy when writing, say, command line programs or APIs, but it is an absolute law when it comes to user interface design. Don’t dictate dd/mm/yyyy; what if the user is American? Even worse, what if they just want tomorrow? Or every three days? A control that can accept natural language input is the perfect control, on that can guess input from the context. I should be able to enter 19/11/07, or 19th Nov, or ‘tomorrow’, and the program should accept them all as the same date. Stick a default of ‘today’ in.

This means a lot of work for the programmer, and of course every situation is different. But please, never lump work on the user when you should be doing it in your code. Please, never use MaskEdit, or any equivalent in another toolkit.

For the good of mankind!

1: Before anyone jumps on me for favouring mouse over keyboard, I would suggest that the best widgets are ones that accept a variety of inputs. Even better, if you don’t need a control, get rid of it - extra fluff confuses the situation.

2: Bearing in mind speed and efficiency concerns: acting in a responsive manner is more important at the UI level. If you can gain some responsiveness by checking at the view level, go for it; just bear in mind that you should check at the model level as well.

Straight JSP has always been a pain in the ass, but one good thing that came out of it was the notion of custom tags: little bits of functionality stored either as excerpts of more JSP, or powered by classes. Coupled with the Expression Language, a java bean backed means of getting data from your app into a webpage, you have a damn fine method of building data-backed websites while maintaining the model/view boundary. JSF is even better: everything is tag-based, and the document is formed by building a tree of these tags. Easy to validate, easy to compile, easy to modify, and suprisingly difficult to get it to produce invalid markup.

But custom tags alone are not enough. The only way to do conditionals in JSP is to embed Java straight into your pages, and you end up with the ugly markup that plagues languages without a clear separation of model and view (I’m looking at you, PHP). Or is it?

The JSP Standard Tag Library is small library of common programming functionality, such as loops and conditionals, built as tags. They have been specifically designed from the ground up as presentation level components, and so lack some advanced features (you should, of course, be doing complex things inside a bean, not your JSP page), but they are lightweight, data- and locale-aware. Everything is easier with the JSTL.

This doesn’t mean they are without fault. I recently completed a large site for a client; for one reason or another, it had to be straight JSP rather than a JSF site, which meant lots of fiddling around. We delivered the site on time, and it was beautiful. JSTL tags were used heavily throughout the site, because they make the code much cleaner, and work well with the API onto our CMS.

In the footer of each page, there is a copyright notice of the form ‘© 1997-2007 Such-and-Such ltd’. One tiny line in the spec said that this notice must never be out date, so the second year must dynamically update when we jump to 2008. Fine, I thought:

<c:set var="now" value="<%= new java.util.Date() %>"/>
<p>© 1997-<fmt:formatDate value="${now}" pattern="yyyy"/>Such-and-Such ltd</p>

Worked beautifully, so I cracked on. The site moved from dev to test, and all worked. The day came for the entire thing to be shifted to the client’s dev server, which was also completed without a hitch. But just yesterday, I received an email from the client complaining that when they tried the site on their live server for a few minutes, instead of the date appearing as ‘2007′, it appeared as ‘Wed Oct 31 10:57:56 GMT 2007′. Obviously this was not what we wanted.

fmt:formatDate is a wonderful tool. It is basically a tag version of SimpleDateFormat, and so supports the full gamut of letter codes to build a date exactly how you want it. It is also locale-aware, so you can just ask for ‘date’, and it’ll give the date in the local format. Tell it you’re in ‘en_us’ and you’ll get ‘11/01/07′; ‘en_gb’ and you’ll get ‘01/11/07′. But if it’s so good, why is it failing with something so simple?

The culprit turned out to be the localisation. If you tell Java you’re in ‘us_US’, it gives up entirely, and fmt:formatDate will just return the full date and time. I’m not sure I like this default behaviour, but not sure what would be suitable.

The work around is simple. JSTL has a fmt:setLocale tag, which you can use to force the current page to use a particular locale, fixing the problem. However, what I don’t know is where it is getting the incorrect locale from. Java is supposed to get it’s localisation data from the operating system; maybe it is failing there? I don’t have access to the clients boxen (SUSE Enterprise 9 boxes, if I recall) so I can’t check. Any other ideas?

I’m a day out. It’s Thursday, I thought is was Wednesday. This is a bad thing because it means I haven’t written today’s post, and it means I have less time than I thought to prepare for the podcast recording, which is tonight.

Damn damn damn. Tonight and tomorrow are both write-offs writing wis, so it’ll have to be the weekend.

That pint is still up for grabs by the way. Ben had a go, but he underestimated the power of Tomcat, the JSP compiler and eclipse’s debugging tools.

danbjorn out.

The java implementation of the software we sell at work renders all it’s pages using fairly modern JSP. In fact, it doesn’t look much like old school JSP, as pretty much all logic is performed using the nifty Standard Tag Library, and our own pretty hefty tag libraries. This means almost no code is written in the pages themselves, everything is handled by the back end classes. Presentation and Design.

In order to render differently styled pages however, poses a couple of problems. You can’t just have one gigantic JSP page; nor is it particularly smart to have each page include bits and relevant points. Instead, we have a home built templating system. There are a series of common pages, tags, css and javascript files. Then, each template lives in it’s own directory with it’s own images and css etc. A short definition file instructs the templating system on how to stick all the bits together. It works really well.

All the files are in XML. This is a handy feature of JSTL and XHTML: we can have nice XML files that validate in seconds, and practically write themselves because our editors can be context aware.

There is, however, a problem with this system. The first one to work out the problem with XML validation in this particular templating system, and leave a comment, will win a pint. I’ll explain the issue, and the brand new shiny solution, tomorrow.

Thinking caps on, people!