Bartek Tatkowski

IDG.se recently reported that 24timmarsbloggen conducted a study of the websites of different IT suppliers that have contracts with the Swedish government. This study is meant to chart how well the websites conform to the guidelines set out by 24-timmarswebben, which is a standard all public service websites in Sweden have to conform to. The test includes 5 different subtest:

• How well the code validates against W3C’s (X)HTML specs
• Header structure
• Tables
• MetaData
• Frames

The result are not very convincing. All, except two, of the major consulting firms have serious validation errors, lack header structures and/or use tables for parts of the layout. The authors of the study are obviously outraged at this, and call it a “serious problem” (my translation). They go on ranting about how they want that “websites [they] visit should be accessible for everyone, and that means following standards and best practices“.

When I read this, my knee jerk reaction was “Yeah, how dare they (well, we) not conform to standards! It’s the least we could expect from professionals!”. It’s reasons like this we can’t have nice things Sharepoint will probably not be the go-to-guy for government agencies for a foreseeable future. In a previous job, I developed accessibility software and believe you me that non-validating HTML/anything that doesn’t perform to spec is a pain in the tuccus. Also, I am a strong believer in the reworded Postel’s Law - “be conservative in what you send, be liberal in what you receive”.

My second reaction was: BWAHAHAHAHAHAHAHAHAHHA *snort* HAHA

Semirelated bonus giggles here.

My third, and more composed reaction is as following: 24hbloggen did a terrific jobs conducting a scientific study, meticiously measuring - the wrong thing. Listen, guys, I agree with you a 100% - websites that carry vital social information and serve as an interface to government and public services MUST BE ACCESSIBLE TO ALL, including people with screen readers and other accessibility software that relies on well formed markup. However, the websites of the suppliers are not carriers of vital social information. The goal of those website is to convey information about the company, what their areas of expertise are and how cool their boat is. In order for the report to have any validity whatsoever, Björn Hagström et. al. should’ve reviewed sites CREATED by the suppliers.

Nice try guys, thanks for the heads up on the abysmal state of our HTML, but better luck next time.

As long as there has been internet, people have been trying to peddle stuff on it. Wait, let me start again; as long as I’ve been on the internet (since 1995 or so), people have been trying to peddle stuff - with varying degrees of success. My personal experience is that the technological and interactional aspect of online shopping hasn’t changed much since the millenium shift. It’s still mostly the shopping cart design pattern that ends with the submission of credit card information. Considering how simple this pattern is, I’m suprised with how much effort some vendors go through to obfuscate it and make it hard for me to give them money. On avarage I have to go through 4 pages of creating accounts, entering information, verifying information and confirming information before they finaly let me send some green their way. Sidetrack: why do some sites insist on me providing a saluation? I guess they get a lot of pissed emails from PhD’s.

Enter Spotify. As opposed to a lot of other recent startups it solves a real problem, and it’s a problem people are willing to pay Spotify to solve. I very strongly doubt that there’s any mumbo jumbo in Spotify’s business plan about magical advertisement money falling from the sky and making the venture profitable, no siree.

Spotify solves the following problem: I’m at my computer and I remember a song I heard several years ago, and I want to hear it Right Now. Now, I have four options:

1. Try and find the video on Youtube and hope that it’s not a third generation tape rip with a anime video playing in the foreground.
2. Purchasing a DRM-ridden mp3/wma/aac for ~1€ which sucks, because I probably just want to listen to that neat horn hook a couple of times and then retire the song.
3. Get on a certain website that rhymes with “bale of hay” and use a protocol that rhymes with “search warrant” to obtain the track I want to listen.
4. Spotify

1 and 3 are of pretty dubious legal status. 2 and 3 take 5 minutes from idea to sweet music sounding in my ears, and that’s the best case scenario. 2 will probably inherit the problems of online shopping as well. We’re left with Spotify, and boy is it a pleasure. After a 2 page registration (a grand total of 12 input fields) which includes account creation and payment you’re presented with a 2 meg installer package. All in all, you should be able to go from going to http://spotify.com to listening to some kickin’ tunes in three minutes.

tl;dr version:

Spotify rules because it allows me to listen to music online, legally with minimal hassle. I’m willing to pay for minimal hassle. If they figure out how to make this whole shebang portable, I’ll give them more money.

When XML came out back during the millennium shift, I was thrilled. Everyone was thrilled, I’ll bet you were too. A general purpose file format and markup language that was easily parsable by both man and machine and could be persuaded into accepted binary data, how could we lose? Boy, were we all naivë or what! Since it’s inception XML has been mangled and coerced into doing some unspeakable things.

It started pretty tame, with people using XML for storing data that would be 50% smaller, 99,9% easier to parse and didn’t require a bunch of extra code to handle if it was stored as a normal CSV file. Configuration files, flat data structures, freakin’ binaries, everything was mashed into XML, whether you needed it or not. However, things were still manageable, it was data in a standardized format and parsers were included in all major frameworks.

This wasn’t enough for some people though. Someone thought of the brilliant idea that “hey, maybe we can represent queries with XML!”. Said and done, Microsoft created CAML, or Collaborative Application Markup Language which is used extensivly in Sharepoint. It’s bascially SQL expressed in XML; the condition “where (Field1 >= 1500) or (field2 <= 500) ” becomes

<Where>
  <Or>
     <Geq>
         <FieldRef Name='Field1'/>
         <Value Type='Number'>1500</Value>
     </Geq>
     <Leq>
        <FieldRef Name='Field2'/><Value Type='Number'>500</Value>
     </Leq>
  </Or>
</Where>

(borrowed from here). So what we’re doing here is transforming an expression into a tokenized parse tree. Gee, that kinda sounds like something that could easily be automated and performed by a computer, because lexical parsing by humans is time-costly and error-prone. You know, like a compiler.

My latest discovery in the field of XML perversion, comes from Sun and in order to make it nicer to read, I’ve concocted a pleasant backstory. Imagine, if you will, the Sun campus. It’s a beautiful sunny day, and a couple of Sun employees are sitting in the grass, relaxing after a hearty lunch. Suddenly, they see Steve (it’s almost always Steve) running towards them, frantically waving his arms. “Guys! Guys!”, he yells, “I just thought of something! We should make XML Turing-complete!”. Thus came into existence XPRESS, a “…a functional language that uses syntax based on XML. Every statement in the language is a function call that takes zero or more arguments and returns a value.” Go ahead and read the rest of it. It reads like a bad joke, or a DailyWTF. Come to think of it, it reads exactly like this article by Charles Petzold, only his article is an elaborate April Fools joke. Which brings me to the moral of todays post and a new personal guideline of mine: If Charles Petzold puts considerable effort into making fun of something, you’re doing it wrong.

In the project I’m currently working on, we have a penalty system set up - for each gaffe you commit, you’re awarded with a penalty point. Four penalty points and you get to treat the whole team to some danish during fika-time. The purpose of this penalty system is of course to promote good behavior such as attending the daily scrum meeting on time, or turning your cell phone on silent when talking to customers. It is also used to deter bad behavior such as yelling at the compiler or forgetting to check in files into Sourcesafe.

We eat a lot of danish.

Anyone who’s worked with VSS will know why this is the case - if you check out foo.cs, edit it and don’t check it back in, no one else on the team can edit it until you’ve checked it back in (there’s a way of working around this but it requires some serious shenanigans) The reasoning behind this behavior is due to the fact that VSS uses a version control model know as lock-modify-unlock. While LMU is simple to understand and implement, it comes with several severe drawbacks. As the free svnbook explains:

The problem with the lock-modify-unlock model is that it’s a bit restrictive, and often becomes a roadblock for users:

• Locking may cause administrative problems. Sometimes Harry will lock a file and then forget about it. Meanwhile, because Sally is still waiting to edit the file, her hands are tied. And then Harry goes on vacation. Now Sally has to get an administrator to release Harry’s lock. The situation ends up causing a lot of unnecessary delay and wasted time.
• Locking may cause unnecessary serialization. What if Harry is editing the beginning of a text file, and Sally simply wants to edit the end of the same file? These changes don’t overlap at all. They could easily edit the file simultaneously, and no great harm would come, assuming the changes were properly merged together. There’s no need for them to take turns in this situation.
• Locking may create a false sense of security. Pretend that Harry locks and edits file A, while Sally simultaneously locks and edits file B. But suppose that A and B depend on one another, and the changes made to each are semantically incompatible. Suddenly A and B don’t work together anymore. The locking system was powerless to prevent the problem—yet it somehow provided a false sense of security. It’s easy for Harry and Sally to imagine that by locking files, each is beginning a safe, insulated task, and thus inhibits them from discussing their incompatible changes early on.

Yikes! Doesn’t sound that great, does it? So what can you do to avoid all this headache? Well, the simplest way is to avoid any source control system that operates on the LMU principle, and more preferably avoid VSS, period. The lazy way out is to adapt your team practices around it, but I find it fundamentaly wrong to adapt yourself to your tools instead of picking the best tools for the job.

Enough ranting for this time, I need to go burn of some calories. We had chocolate muffins today, my treat.