magpiebrain

Sam Newman's site, a Consultant at ThoughtWorks

Posts from the ‘Development’ category

For some time now I’ve been using “@DateFormat@(DateFormat JavaDoc)”:http://java.sun.com/j2se/1.4.2/docs/api/java/text/DateFormat.html (actually “@SimpleDateFormat@(SimpleDateFormat JavaDoc)”:http://java.sun.com/j2se/1.4.2/docs/api/java/text/SimpleDateFormat.html) to parse user inputted dates it situations where a decent date chooser wasn’t available. Some simple bit of code like this would normally suffice:


private static final SimpleDateFormat DATE_FORMAT = new SimpleDateFormat("dd/mm/YYYY");

...

try {
  DATE_FORMAT.parse(someString);
} catch (ParseException pe) {
  //date is invalid
}

I learnt two things about this approach. Firstly, @DateFormat@ is _not_ thread safe. This fact was only documented in Java 1.4 despite it having never been thread safe. This is one of those things you learn, and is easily put right.
Continue reading…

I have long since come to the conclusion that JSP pages are evil. Not just bad, oh no. Nothing which can result in such unmaintainable crufty code can be considered merely bad – only evil will suffice. This opinion has been reinforced over the last few days, and this single gem stands out.
I was using a struts logic tag (asshats, I have no choice in this – the first person to tell me to use webwork instead is getting eaten by rats) to assert a boolean condition. It looked a little something like this:


  I hate JSP

For some reason even if @boolProperty@ returned @false@, “I hate JSP” was still being printed out. It being late in the day (and a Monday) I was slow to spot the closing @/@ on what I took to be an opening @logic:equal@. Despite the fact that I had a closing @logic:equal@, no parse error was thrown. Apart from the fact that a @logic:equal@ tag is of no use to man nor beast without a body (and therefore a validation error should of been thrown by Evil Struts) I would of expected the JSP compiler to notice an extra closing @logic:equal@. Of course assumptions are a dangerous thing when it comes to JSP…

Whilst leaving a comment over at “Jon Hicks”:http://www.hicksdesign.co.uk/ site, I noticed his excellent live preview for comments. As you type it displays how your comment will look, all in real time. I would love to do something similar for this site, however Jon uses HTML for comments so lets the browser do the parsing – I’ve decided to use textile which means I’d have to do the parsing myself in Javascript, which doesn’t sound too easy…

One of the few benefits of a long commute, is the fact that I’m not doing it alone. The time afford to me each morning on the train to and from work also provides and opportunity for discussion on all kinds of topics, ranging from the poor state of journalism in the daily free newspaper the Metro, to some more esoteric issues at least tentatively connected with work. One discussion which fell between these two concerned the notion of naming – be it the naming of classes, methods or packages.

One of my colleagues asserts that naming is actually one of the hardest things he has to do as part of his day-to-day development. I agree tentatively with that statement – however the problem is not a lack of vocabulary, more that when naming is a problem we often just don’t understand what we are trying to name. The more we mentally consider the code to be an amorphous blob, the more naming becomes difficult. Once our understanding of the code coalesces into something more concrete, naming often becomes trivial.
Continue reading…

Now that this site properly “validates (W3C Markup Validatior – validation results)”:http://validator.w3.org/check?verbose=1&uri=http%3A//www.magpiebrain.com/ as XHTML 1.0 Strict (with a little help from some PHP and the “W3C validator”:http://validator.w3.org/) I’m now starting to look at the markup itself. As you may know, the idea is that the XHTML should contain the semantic markup, and the CSS the presentation, which is a pattern I have used here. I have become concerned however about the quality of my markup. Lets look at a simple example. Currently, the links for each post are marked up like this (I’ve omitted @href@’s or the MT tags that generates this content):


May 4th in General | Permalink | Comments

Continue reading…

Each language feature introduced that tries to enforce safety of some kind invariably introduces some reduction in the power of the language. Some of these tradeoffs’ seem acceptable. The Java security model is an example of a limiting factor in the deployment and execution of a Java application which makes perfect sense to me. Java also hides memory management and pointers from you, which for the majority of applications also makes sense, however sometimes you really want to get hold of the underlying memory model and do nasty things with pointers and that is why C and C++ are still used for writing OS API’s.

Other limitations just become more frustrating over time. Java’s strongly typed language provides a great deal of compile-time checking, at the cost of program flexibility – Python, Ruby et al provide a richer, dynamically typed language which gives the programmer much more power (And anyone saying “You get dynamic typing with Groovy” is going to get smote with the cluestick of death, +1.). At this point I’d like to borrow a phrase from Spiderman (uh oh – nerd alert!) “With power comes responsibility”. Such dynamic languages with their more flexible typing can also get you into a bit of a mess. These dynamic languages can be seen primarily as enabling languages – they make the assumption that developer actually know what they are doing. As a result, they will on occasion let them shoot yourself in the foot. C and C++ likewise let you shoot yourself in the foot – they also however let you shoot the guy next to you, blow your car up, drink your beer and steal your girlfriend, but that perhaps is a discussion for another day.
Continue reading…

As I “mentioned before(Generate footnotes for printing)”:http://www.magpiebrain.com/archives/000231.html, I recently wrote some Javascript code to produce a more printable version of my pages. Since then I’ve updated the code a little, added a link to each page and refined my printing CSS. The Javascript code handles two tasks – firstly it extracts selected links and creates a footnote for each one. Secondly, it extracts any print stylesheets and displays them in the browser so you can get a better idea of how the printout will work. A couple of niggles still remain – I cannot skip links in blocks which use @id@ rather than @class@, and the markup for the footnotes is horrible. Once I’ve cleaned the code up and fixed the last few remaining issues I’ll post a proper writeup soon.

Now that the code is properly integrated in the new design, I though I’d ask for some feedback.(the ‘Print this page’ link can be found in the top-right hand corner) – you don’t actually have to print, just click the link and see how it looks. I’m especially keen to hear from people with browsers other than Firefox and IE.

As you may of noticed, I’ve been having some problems with the “@overflow@(w3c – Overflow and clipping)”:http://www.w3.org/TR/REC-CSS2/visufx.html#overflow-clipping property and IE. Simply put, @overflow@ should define how content outside the displayable area is handled. Using the @auto@ value should display scrollbars when required – and this works perfectly on Mozilla. On IE however I couldn’t get it to work at all.

The problem is seems is that IE isn’t bright enough to work out the width of the on screen element – if I give my @pre@ blocks a width (which I can now do with a fixed-width layout) it correctly displays horizontal scrollbars and stops playing havoc with my layout. Its not all plain sailing however – when it adds the horizontal scrollbar, it doesn’t correctly resize the @pre@, and therefore also displays vertical scrollbars! Oh well, such is life…

OK, I finally got around to the redesign this weekend, and its gone fairly well. I’ve moved from a liquid to a fixed layout, as the site was almost unreadable on high resolution monitors and many of the design changes I wanted to make become overly complex. One downside to moving to a fixed-width layout occurs with preformatted blocks of text. @

I sent some experimental code live today which I’ve been working on a little over the last couple of days. Now visible on the individual entry pages is a ‘Printable Version’ link that can be seen on the bottom left of the post’s content, which when clicked extracts (nearly) all links and creates a series of footnotes with the URL’s displayed. It also extracts any printing stylesheets and displays them so you get a better idea as to how it will print. Hopefully this technique will make printing from sites with many hyperlinks more useful.

The code is completely written in Javascript, and I hope to publish a full writeup on how it works in the next few days. The idea was inspired by an “IE-only bookmarklet”:http://www.kokogiak.com/gedankengang/default.asp#12012200393, although it has been completely rewritten to be supported in more browsers. In the meantime I’d appreciate it if you could let me know of any problems with the technique, especially if there are any problems with Safari or Opera (neither of which I have to hand right now). Known problems include:

* Some links probably shouldn’t be extracted as footnotes – for example the next/last post controls. I am filtering some out already so thats an easy fix.
* No effort has gone into styling the footnote section
* the printing stylesheet is quite primitive – it hides the side menu for example by doesn’t expand the main column to take advantage of the extra space which is available.
* It seems to break the automatic citation links for block quotes, although I have a good idea as to what’s causing that
* The location of the ‘printable version’ is a little out of the way – my aim is that when the code is finished the ‘printable version’ will be available on every page.
* The only way to get back to the non-printable version is using the back button.
* I need to see if there is some proper semantic markup to be used for footnotes

Whilst the technique is being used here for printing, it can easily be applied just to fit in with a site’s editorial style.

_Update_ 1: Oh, and I’ve just noticed the Javascript is stopping the document from validating as (X)HTML Transitional…

_Update_ 2: Also if the text for a link contained other HTML elements, the text is being displayed unformatted – again this is a fairly easy fix.

_Update_ 3: Priting broke when I uploaded the new design, so I’ve taken it off line for the moment until the issues are resolved.