As sequels go, they never outdo the first. And Yahoo's first London Hackday is legend. The second, far better organised, a brilliant venue (except for their below-par networking infrastructure) and excellent food. Congratulations are very much in order for Anil Patel and Sophie Major for pulling off a remarkable and well-run geek event.

The talky bits

The first day started off with tech talks. Dav Glass' overview of YUI3 was particularly insightful, and a well thought-out code example topped off a useful talk (has anyone ever seen Dav without a beanie?). Christian's talk was the best, showing off the potential of YQL, and billing it as the command line version of Pipes. I found the BOSS talk lacking in real substance.

Rasmus Lerdorf had interesting material. He offered useful snippets of code for doing typical things: curling, parsing RSS, caching, authentication, YQL, and even OAuth. Aimed primarily at new hackers, or non-hardcore developers. These are all very useful pieces of code for a hacker's toolkit. I feel the material would be far more useful as an online website, like a Hackday Manual.

My memories go back to the first installment and it's interesting to see the considerable change of technology. Back then YUI was just about to start gaining mindshare, Pipes (the forerunner to YQL) hadn't arrived. Ryan Kennedy did a fascinating talk about BBauth and the Yahoo Mail API. It's clear Yahoo is starting to be a leader on the technology front. They are listening and reacting in a way that is beneficial to us hackers, Yahoo employees or not.

Querying the web with YQL

YQL (Yahoo Query Language) is a brilliant conception. Fundamentally sound and it taps into the web developer mind share. They already deal with SQL queries, and here's something that then has a minimal learning curve and produces remarkable results fairly quickly. It almost just converts the web into a big queryable database.

I saw this magic first in SPARQL last year, but YQL is going to be a much bigger deal because it taps into an existing audience and fits naturally into their existing toolset. SPARQL is tarnished by the Semantic Web mumbo-jumbo and the prevalent belief they'll reinvent the Internet in it's image. YQL just works, with and without the datasource's help.

One of the subtler advantages of YQL is that when enough people find an API-less website useful to scrape via YQL, the site owner is going to notice a steady stream of requests from the YQL user-agents. That leads him into figuring out why YQL is making these requests, and hopefully encourage that developer to make the content open as an API. Using YQL is almost like voting to encourage a website owner to offer API access to the data that he's already making available as part of a website.

It was also particularly splendid to see David Filo in attendance again. I actually believe he has been to all the Yahoo Open Hackdays across the planet. Has he even missed one? I regard Filo as the technical heart of Yahoo, more than just a leader. An inspiring presence. And in his lifetime he is a legend, and along with Jerry Yang played a crucial role in the history of the Web that we have with us today.

Un-networking

When 250 geeks converge into one constrained space, Internet access is going to be problematic. The one particularly significant issue of this hackday has been the wonky wifi, and perhaps more scandalous or ridiculous, a dedicated line that's significantly well below average if compared to household broadband connections.

A bottom range broadband connection is just nowhere near acceptable enough to satisfy the data needs of two hundred and fifty geeks armed with multiple laptops, 3G auto-connecting mobile phones and other handheld devices. Despite the phenomenal effort of the Yahoo hackday crew, who requipped the venue with enterprise level wifi routers, there was nothing they could have do to alleviate the issue of a low-bandwidth connection.

Just as the lightning strike at Alexandra Palace was totally out of Yahoo's control, so was the internet connection. Except, it was a man-made error, and a mistake made perhaps months or years before hosting a hackday there became a possibility.

It's an organisation failure of the venue owners. The connection size might just be barely adequate in an audience of 250, and only a fraction are using their laptops for web requests. 250 data hungry geeks is a completely different story. We live, breathe and die on TCP/IP. There's not enough hours in the day to satiate our appetites for information on the web.

Hacking

As a result, my plan of building an application on top of Twitter was doomend from the start. Trying to debug Curl was a frustrating spiral, I just couldn't tell whether there was something wrong with my Curl request, or whether it was just the lousy connection. With the majority of webpages just timing out and showing a blank screen, it was a no-win situation for me. So I opted to leave early, and bailing out on the typical overnight hackday activities.

I was building an application because there was a room of like-minded geeks building their applications, so it was the natural thing to do. But, I'm building the app for me, because it's something I want to exist, and something that interests me. So after a pizza-hazed hacking session, and coding storms tempered all top frequently by Twitter's hourly limit, I decided that my idea was more valuable to me than building something in 24 hours.

Accessibility and Dundee University

I headed back into London on the Sunday to catch the end of the hacking session and for the hack presentations. I finally got to see the much-celebrated Dundee University winning hack team. They were flown from Dundee to participate in this hackday, and again they turned in a stunning application that really pushed the boundaries and conceptions around web accessibility.

Out of all the hacks, I felt that the Dundee University's Intellisearch was the most polished and well-executed hack there. It was basically a predictive interface for people with motor-related disabilities. Clicking a mouse button without the mouse moving is the one major frustrating barriers this audience has to deal with. So the Dundee guys implemented a clickless interface, and worked around the imprecision of mouse positioning by clever use of zoom.

By hooking into Yahoo BOSS and YQL, the interface offered multiple options that could be selected just by moving the mouse nearer the preferred option. The closer the mouse to an area, the larger that area became. This neatly solves the tradeoff problem of having large selectable region against the need to have as much information on the page as usability allows.

It was an awesome demonstration of creativity, an ingenious idea that was well executed. It used HTML Canvas for the interface, and I felt that the award of "Best Mozilla Hack" is an understatement. All A-Grade browsers support Canvas except for Internet Explorer. So it's not just Mozilla, but the Webkits and Operas that can make use of this immensely powerful interface conception.

I've praised Dundee University previous for turning out such talented, gifted and accessibility aware developers. And like a broken record, well done to the Dundee crew of Chris Brett, Laurence Hole and Matthew Ross. Exceptional work. And lots of credit to the staff at Dundee University for keeping up-to-date with modern web development techniques, and teaching them.

The presentations

Fifty hacks were presented. Many of them took advantage of YQL, and pulled off some nifty ideas. Jim O'Donnell demoed a marvellous YQL and Flickr hack on the significant number of astronomy pictures on Flickr (and won a Best YQL execute hack award). He pulled in astronomy data surfaced in Flickr machine tags into the YQL table, thus exposing it to future processing. So now it is possible to start at a picture of one region of the night sky and be able to calculate and find pictures of celestial bodies nearby.

The implications of surfacing such rich data is very similar to geo-location data already available for our tiny planet. Talking to Jim on Saturday he made a great point that geo-location is looking at a ball you are standing on, and what he is doing is looking from the inside of a bigger ball, the maths and logic is largely the same, and the newly-created opportunities equally so.

Jim has been an independent champion of YQL, and over the past few months has inadvertently demonstrated the unexpected benefits of making data easy to query. I doubt the YQL team ever imagined how beneficial their platform would be to the world of astronomy. A case of build it and see we comes? Jim has been applying YQL to both astronomy and maritime information, and it's splendid to see such a cutting edge technology being so useful to long-established professions.

Norm, James and Richard produced an exceptional idea, a Bayesian filtered news aggregator. By filtering stories based on user preference, you can remain subscribed to more general news feeds (like Top Stories feeds) and filter out topics you are not interested in in an automated fashion. I loved the concept, and the end result was splendid. Also, there's the broader implications of Bayesian filters for building a set of user preferences; the could be applied to other things like recommendation engines of various retailers. It could be Skynet.

The iPhone orchestra entertained us by playing the Doctor Who theme. It was awesome, and gave the Tesla Coil interpretation a run for it's money.

The other hack that caught my attention was the FireEagle temporary pass, which solves the issue of letting some people know where you are, but in an easily revocable way. That way some people can know where you are when you want or need them to know.

It has been an awesome weekend. Again, well done to Anil and Sophie, and the endless energy from the Yahoo support crew. They did a fantastic job, and the quality of hacks from the gathered geeks was very good. Perhaps better than the initial London Open Hackday.

Ubuntu success

I consider my migration to Ubuntu a complete success. I never missed Windows XP, I never felt I was languishing. The range of software with Ubuntu is superb, and always on tap through the Synaptic Package Manager.

I never did find a happy solution to my chess engines problem, but it doesn't strictly matter any more. I have a few Windows machines lying around that when I am compelled to spend days staring at pixelated chess pieces and cryptic messages I can do that. I just don't need it on my main laptop any more.

The tipping point for me was the ease of getting up to speed with writing code. My laptop is a productive source of turning ideas into real projects. Everything I need just seems to work.

Why switch?

So why switch? Well, I'm not really switching. Xubuntu is essentially Ubuntu, just with a different primary window manager. I'm really just moving from GNOME to Xfce, moving towards a lighter window manager.

What first turned me on to Xfce is the elegance of it on the Acer Aspire One. The Lupus Linux distribution on the Aspire One is basically Fedora running Xfce. And I've been coding away with the same development tools that I'm used to. That offered me some encouragement to try Xubuntu for real.

Performance

GNOME is feature rich and runs on top of the GTK graphics library. Xfce also runs on the GTK library, but the interface is far lighter.

Over the last 6 months leaving Firefox open 24 hours a day is keeping the laptop fan working furiously. I'm not sure whether that's because of the steady stream of system updates has taken it's toll, or whether the window manager is making too many demand of the humble Gigahertz and a bit CPU.

But after a couple of days of Xubuntu use the fan is noticeably quieter; it does kick in, just not as frequently or as loud as before.

Software choice

It turns out that the software I'm using heavily are all GTK based and not dependent on GNOME. Firefox, Bluefish, Pidgin, Twitux, Transmission, Filezilla, and any decent terminal. Everything else is either a command line program, or not essential to daily use. (And mono, the open source implementation of C#, is also GTK based; so that still tweaks my curiosity)

Since Xubuntu is built on the same foundations as Ubuntu, I still benefit from the remarkable package management system as well as the steady stream of updates and bugfixes. I haven't lost any functionality that I need or want.

Installation issues

I had just two issues installing Xubuntu from scratch, and both were resolved fairly quickly thanks to the ever brilliant Ubuntu forums.

The first problem was setting a static IP address on my laptop. Changes to the Network Connections dialogue were just being forgotten after a reboot. It turns out this is a known bug when updating these settings, and the workaround is just to remove the current connection details and create a new one from scratch. For a once-off task that's acceptable.

The second problem was that after a few minutes of running the display started showing odd artifacts and certain text characters started to disappear. A short investigation concluded that the default acceleration settings of the Intel graphics card were causing the issue, and setting the acceleration configuration in xorg.conf to the right value was sufficient to cure the problem.

Then it was just a case of getting my normal development stuff installed: bluefish, apache2, php5, mysql, git, curl, ssh, lynx, and a handful of php5 modules. My development environment is largely identical (although the text size is bigger, and I'm most certainly not complaining about that).

Conclusion

Ubuntu is a fantastic intermediate step away from Windows, and I would still heartily recommend it as the first step. Xubuntu is my next step towards a desktop environment that focuses more on what I need. That involves trimming out the unnecessary windowing features, getting more for my limited CPU resources, and generally being more Unixy. Xfce looks fabulous, and it succeeds on platforms just not beefy enough for Ubuntu, and be competitive on platforms that are adequate for Ubuntu's main GNOME system.

I made no real compromises moving to Xubuntu. I wasn't reliant on any GNOME dependencies. If there is something GNOMEish I need to run for a short period of time, it's just a few clicks away in the package manager.

Xubuntu is quickly becoming my distribution of preference. A modern linux distribution that still fits on a CD, that's a good sign. I'll try installing it in my kitchen sink next.

I get highly annoyed at the assertion that valid markup is essential for a page to be accessible. The argument lacks both substance and real world evidence, and there's a great example of the opposite: using the invalid embed element allows Flash to send updates to MSAA, which directly benefits people using screenreaders; while using the valid object element doesn't. Here I deliberately chose the invalid markup because it is more accessible.

CSS versus tables is another known permathread. It's only recently that the voice in favour of tables layout has improved it's position significantly. Unfortunately the same cannot be said about the rabid pro-CSS group. They continue to spout nonsense and hope no-one looks too deeply at the arguments, and hope enough commenters reply that it couldn't have been said better. Except there is large room for improvement, or perhaps reformulating the argument into something that is backed by real world evidence.

Matt Jurmann of Chromatic Sites published a blog post titled 13 Reasons Why CSS Is Superior to [tables]. How ironic, the CSS layout has prevented the full title from displaying! Even the abstract is horribly cropped. Even more ironic is the site tagline of web solutions that work.

Lets look at all 13 arguments and evaluate whether there's any substance. Or logic. Or common sense. Or anything substantial whatsoever.

1. Faster page loading

Apparently CSS layouts load quicker. But only if the CSS is not in an external file. Except no-one doing webstandards does this as a rule, and the benefit of visual consistency (argument 5) is thrown completely out of the window; and that has a knock-on effect on a number of follow-up arguments.

No web standards expert chooses to have the CSS embedded in the HTML page, it isn't a best practice. The only one compelling argument I've ever seen for CSS embedded in the page is when the Yahoo homepage is set as your homepage in IE6 it is actually quicker because it reduces the risk of the CSS not being cached locally. But that is merely an edge case.

In a website authored by best practices, the tables layout will be faster loading because there are less HTTP requests crossing the wire.

The CromaticSites.com site actually has eleven separate external CSS files. That's eleven additional HTTP requests before the browser has sufficient information to render or repaint the final version of the page (even if the response is just a 304 Not Modified). The performance overhead of a bigger HTML page for tables layout is minuscule in comparison.

2. Lowered hosting costs

This argument follows on from the previous discredited argument. Less bytes equals quicker download. Except again, web standards best practice uses CSS in external files, so the overhead of making an additional HTTP request dwarfs any single page size saving. This is an accepted tradeoff for site-wide consistency.

CSS can offer bandwidth savings, but this is solely down to caching. This caching is done by the browser, or intermediary caching servers. If you set proper Expires headers on your CSS, then you are likely to see a better cache-ability of your CSS. Even with proper server-set HTTP headers, the chances of caching are not as rosy as expected. The Yahoo! Exceptional Performance team has some very interesting (i.e. substantially lower than expected) statistics about caching that lead to the call of minimising HTTP requests.

But with 11 external CSS files the additional bandwidth costs of the extra HTTP requests and responses is going to consume more HTTP packets than the bigger HTML page size of tables layout.

3. Redesigns are more efficient

Apparently redesigns are easier with CSS. Unfortunately this is just theory. I've watched countless webstandards savvy bloggers redesign their blogs every once in a while. A substantial number of times this has involved changing or refactoring the markup before the styles can be applied.

With Wordpress the typical working process is to design your new site as a theme, so you have the ability to change the markup, and then author the new CSS rules. Then finally, just switch themes when you are ready to go.

In this case, the redesign efficiency of CSS isn't that immediately apparent. Tables layout can still be as efficient as CSS in this typical scenario.

The second point is that redesigns are typically site rethinks, and sites that redesign by changing the CSS alone are rare. Most especially commercial sites. An example is the Yahoo homepage redesign, they normally take 6 to 12 months, and that hardly qualifies as efficient.

4. Redesigns are less expensive

Another follow-on based on a previous discredited argument of redesigns being more efficient. A redesign is typically an overhaul of the existing site, and CSS layouts don't fare any better than their tables layout counterparts.

The theory sounds good, but in real-world practice, the argument isn't sustainable. Perhaps this only works on small trivial sites rather than the typical Alexa top-100 type sites.

5. Visual consistency maintained throughout website(s)

Matt finally gets to one of the real strengths of CSS; the ability to externalise an entire site's styles in a manner that is sharable across all pages on that site.

Yes, a great argument, except that it then contradicts all the arguments about download performance.

This advantage is also a disadvantage. Changing one style to fix a bug or improve the styling on one page can have a detrimental effect on other out-of-sight pages on the site. So a page you are not looking at can break without you immediately knowing.

Firebug only saves you on the pages you are looking at, and when your site is a couple of hundred pages it is difficult to figure out the risks involved in updating just one style rule. There's no simple way of figuring out the site-wide implications of changing one style rule. And when JavaScript is affecting what style rules apply it's an absolute nightmare to test.

Which means that developers tend to prefer adding new class names and new stylerules to try to limit the damage caused on the rest of the pages. And that results in styles that are page-specific, and thus the visual consistency of pages then degrades.

Visual consistency is a little better with CSS, but a well-planned tables layout built with real development tools has a much better chance than the typical web standards geek and their trusty text editor. Ask around how many CSS savvy web developers actually have a build and deploy process. Not many.

6. Better for SEO

Again, more nonsense with very little substance. Search engines aren't hindered by longer pages, and haven't been since the inception of the Web. Search engines index tabled layout pages as adeptly as CSS layouts, particularly with Google's preferred approach of disregarding markup semantics and heavily favouring actual text meaning.

Some search engines do stop at the first 100Kb of content, but that's regardless of whether the page is tables or CSS layout. And if you can't fit a page's content into 100Kb you have bigger issues than just tables for layout. Like Information Architecture issues.

An argument that could be considered in CSS' favour is that a semantic search engine could read more into a CSS layed out document (assuming that CSS is applied to an existing well-structured document). But this isn't what is happening with today's popular search engines. This is something that may prove beneficial in the future, but not today. But it is also a chicken and egg situation, there's not enough well-structured pages out there to make it worth relying on semantic structure, and semantic structure isn't useful to search engines today so there's no point spending too much time with them if that's the only argument for it. But that's neither here nor there, a table layout can just as easily use proper headings and markup for its content than a CSS layout; or both can be just as bad as the other.

Search engines ignore all markup by default, and whitelist certain constructs, like links, headers, bold, image elements. All of these structures are possible with both CSS and tables for layout.

Jurmann's point about rollovers is complete nonsense and has no bearing on the search engine visibility of the page.

7. Accessibility

Ah, the accessibility card. Except Jurmann picks the wrong definition of accessibility - the one about the availability or universality of a page (for example, server uptime). In this case CSS for layout doesn't do anything to preserve the uptime of a server.

Now turning to accessibility: as in making content and services perceivable, operable, understandable and robust for people with disabilities:

It is very possible to create an accessible website with tables for layout. Heck, two of the best accessibility books on the planet go into detail about how to minimise the accessibility barriers of using tables for layout. CSS can still create accessibility issues, and that still needs a watchful eye just like their counterparts.

CSS layouts are no more accessible than tables layout. Screenreaders have had to deal with layout tables since the inception of the web, and they do a fairly decent job at making them transparent to the visitor so much so that most of the time they do not realise the difference between CSS and tables layout.

All of the accessibility techniques the Chromatic piece talks about have nothing to do with CSS layouts, but of CSS styling. Font-sizing, styling of lists, these are all quite possible with tables layout too. This isn't an advantage of using CSS for layouts, it's an advantage of using CSS for styling content.

8. Competitive edge (job security)

And here is the ugly truth about CSS evangelism: the elitism. CSS layouts aren't as easy for the vast majority of people building websites. So obviously, people who can do CSS layouts, and write articles about 13 reasons why CSS layouts are better than tables, well this is the part where they assert that they, the CSS layout gods, are so much better than the typical site builder.

Job security for learning something asserted to be easy? That's an interesting contradiction. Where's the job security in knowing something that's easy? Surely the people working with tables based layouts have better job security because CSS is so much easier, and it requires more dexterity and skill to edit a tables layout?

And frankly, this dismissive 'CSS is easy' is disgusting. CSS is not easy. The learning curve is steep, and not well mapped. CSS layouts are very much stuck in the Dark Ages as alchemy was. A decent text about building reusable stable layouts with CSS is yet to appear, and that's more down to the immaturity of CSS itself. Building solid reliable layouts in CSS is a Black Art.

Learning how to use tables for layout is actually far simpler. The number of hacks and workarounds to render a reliable and stable non-trivial layout is actually far fewer and less complex than the CSS hacks and workarounds.

9. Quick website-wide updates

Another riff on the consistency across sites argument. Sure, updating one single style will affect all the pages on the site. But a proper build and deploy process also does that, so layout tables can have this feature too. No modern website with a sizable audience doesn't have an automated build and deploy process.

10. Easier for teams to maintain (and individuals)

Yet another riff on consistency across pages, and without mentioning the downside. Surely changing on thing that results in changes across thousands of pages also means those thousands of pages also need to be tested individually? This is the great risk with CSS, you can destroy a page you weren't intending on changing, and without knowing it.

CSS for site-wide styling is a double-edged sword, you can just as easily cut yourself with it. The testing burden alone is a sufficient reason not to use CSS for site-wide consistency.

And yet, site-wide CSS styling of content (as opposed to layout) can, and are, used in tables layout to style the content. The clean separation of presentation and layout means that in a tables layout site, site-wide changes to styles are less likely to trigger a degradation of a page layout because tables are so robust. So it is actually safer to use tables for layout.

Jeffrey Zeldman's original edition of Designing with Web Standards advocated a tables layout, and using CSS for the rest. CSS was deemed not to be mature enough when this book was written, and in layout terms it hasn't improved that much, and tables layout are still far more stable than CSS (for real world layouts).

11. Increased usability

Apparently the ability to have a print stylesheet means improved usability. Well well. With the typical automated build and deploy systems in use across most leading websites it is fairly trivial to create a printer friendly version of pages with very little effort or overhead. So the advantages of a print stylesheet are negligible.

The continual assertion that CSS downloads faster makes another appearance. Yawn.

12. More complex layouts and designs

Another baseless and unsubstantiated assertion. It took a long time for CSS to mature enough to be able to create layouts that were straight-forward to do with tables. The canonical example of a headered and footered three column layout with the middle column fluid (the 'Holy Grail' of layouts) is still remarkably simple to do with tables, and yet a minefield of issues for CSS. The CSS equivalent requires trade-offs and compromises to get into a reliable state.

CSS is starting to get an edge in pixel-specific layouts. So grid based layouts, those much praised by designers and the print world, that is almost doable in CSS now, whereas they've been relatively straightforward with tables for well over a decade.

Layouts that require overlaying, cropping or relative positioning are obviously not straightforward with tables. And yet, considering the accessibility and usability implications of such techniques, maybe that's a positive thing for tables. Considering the number of cropping and lost content issues with the Chromatic sites website, perhaps they'd be much better off using tables for layout instead? They certainly wouldn't have had their titles and abstract cropped!

13. No spacer gifs

Tables for layout doesn't automatically mean the use of spacer gifs. Designing with Web Standards by Jeffrey Zeldman detailed how to create table layouts without needing these.

The merits of evangelism

These kool-aid induced advantages of CSS lack substance or real-world experience. As a sceptical observer who is well versed in using CSS, I find the points raised underwhelming and unconvincing.

Why am I critiquing like this? Well, I find the level of discourse about CSS layouts low. There is too much back-patting and self-congratulations going on. These CSS are better than tables articles, as they are currently published, are doing nothing to improve web standards or encourage an interest in CSS.

ESPN, Wired and the Blogger redesign were three tremendous examples of the practical benefits of CSS layouts. These sites inspired people, encouraged people to give CSS a whirl.

Eric Meyer's books on using CSS in a practical manner are also as inspiring as they were instructive. I'd recommend both "Eric Meyer on CSS" and "More Eric Meyer on CSS" for people who are curious about what CSS can do. But they don't talk too much about actual page layout. Yes, there's coverage of simple layouts, but not those sort of layouts that make up the vast majority of corporate sites.

Evangelising CSS shouldn't be about my tools being better than your tools. People working on existing sites get paid to keep sites using tables for layout up and running. It is simply not cost-efficient to not support these sites. They are not going to be completely convinced by these arguments and start tomorrow off by deleting all layout tables - that's the quickest way to not having a job, and in the current economic climate, that's not a clever move.

Tables for layout work. Their deficiencies, and workarounds, are well understood and easy to learn. For the typical corporate web developer debugging a table layout is far easier than a CSS layout. The risk of unintentionally breaking other pages on the site by fixing one issue on one page is substantially smaller than site-wide CSS.

The core argument that CSS evangelists fail to acknowledge is that companies with big sites can't afford to change the entire site in one go. There is no clean-slate approach to revamping these sites. Projects are broken up into little phases of deliverables. Sometimes there's a three month project to change a tiny part of the page measuring not more than 250 pixels by 32 pixels. Full site redevelopment is practically a non-starter.

What is worse, is when these webdevelopers see lame articles about how CSS is much better than tables for layout, they only need to see though the nonsense of one single argument to realise that these articles lack substance and real world evidence. And when measured against the harsh realities of an existing website, these arguments are ridiculous and serve only to distance developers from using CSS. And so the status quo remains.

Advice for CSS evangelists

CSS evangelists, consider the merits of your arguments thoroughly. You'll find that CSS isn't better than tables for layout; it's just different. Just a different set of trade-offs and compromises. Deepen your understanding of CSS, especially it's shortcomings, limitations and it's compromises.

Belief doesn't build websites. Toil and sweat produce websites. Belief doesn't get things working. If you only believe CSS is better than tables for layout, then perhaps you aren't the person who should be evangelising to people who have a solid track record of delivering real websites with layout tables.

Be prepared to back up every single one of your arguments. There is nothing worse than an evangelist who doesn't have the knowledge, practical experience or evidence to back up his claims.

And most importantly, understand the web as it exists today. The past and the present cannot be forgotten. The future is something we can aim for, but not at the expense of a business continuity.

Maybe these CSS evangelists need a break from the kool-aid? That would be a start. Perhaps then a rationale dialogue will be possible.

The guys behind Chromatic sites perhaps should spend less time exhorting the perceived advantages of CSS and how easy it all is and spend more time fixing the CSS issues on their own site. Some people talk the talk, but don't walk the walk.

Disclaimer: I received a review copy of this book from Packt Publishing in December 2008.

Restful Web services is an often-heard buzzword on the Web, and it is fairly disappointing that the real essence of what makes a Rest web service is frequently misunderstood. Unfortunately Restful PHP Web Services doesn't get it right and is littered with errors that negatively impact the content itself.

Rest is not RPC

A book that asserts Flickr as an example of a Rest web service is going to start off on the wrong foot. Unfortunately the book spends several pages detailing how to operate with that particular service as a working example of a Rest-based service.

The API is basically one single endpoint (http://api.flickr.com/services/rest/), with a collection of parameters (including one called method) that dictate what operation is being performed on what resource. This is the typical Remote Procedure Call; the URL space is broken down by function, not resources.

The fundamental principle of Rest is that the HTTP methods define the operation to perform on a representation of a resource at a particular URL. Flickr gets it wrong because URLs don't map to representations of resources, nor uses HTTP verbs as the mechanism for performing operations. It is just Remote Procedure Call.

Why use Flickr, why not use a real Rest web service, like Wordpress' implementation of the Atom Publication Protocol? At best Flickr is an API over HTTP, at worst it is a Remote Procedure Call.

Rest is about hyperlinks

Rest is about mapping representations of resources onto URLs. The Flickr API fails to do this, and to actually retrieve an image from their API you have to manually construct a URL to that image; it isn't returned to you by the API. Witness the following logic:

$image_url = 'http://farm' . $attributes['farm'] . 
	'.static.flickr.com/' . $attributes['server'] . '/' .
	$attributes['id'] . '_' . 
	$attributes['secret'] . '.jpg';

If a client has to construct a URL in this way to obtain a representation of a resource, that API isn't Restful.

Post or Put

The book improves slightly by covering the principles of Rest, but not much. It specifies POST as a means for updating a representation, and PUT as the way to create resources. The real distinction is more complicated. PUT can do both create and update, POST is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI, which means it is suitable for adding new resources. Particularly Atom uses POST on a collection to create a new member, and PUT to update an existing member.

Content types

There is no mention of content types when dealing with Rest resources. This means that a Rest client has to know what kind of representation he is getting back, because the content-type information is useless for helping determine that. Just imagine how the web would work without content types - it would be a mess.

With Atom we had specific content types for an Atom Entry and Feed, and a different content type for the Atom Service Document that described the collections available.

Curl

A useful section of the book covers using CURL to talk to servers. It is fairly useful as a starting point, but either the material is out of date or just plain wrong. Doing a GET with the code supplied did work but emitted a warning on PHP5 that there wasn't a CURL option called CURLOPT_GET. Sure enough, checking the documentation and there is no mention of this option. The code only worked because GET is the default HTTP method.

Even worse is the sample code for doing a PUT, this involves writing out the data to the filesystem and then sending the filename as a parameter using CURLOPT_INFILE. Digging around I found the more natural solution of using CURLOPT_POSTFIELDS, so it is not clear why the author had offered the convoluted file creation method and not even noting the better methods.

However useful it is to have simple working code examples of both server and client aspects of Rest, it doesn't help to ignore Rest principles in doing so. In the code sample for a PUT the author has a PHP script that is used for the URL of the resource and then claims that a PHP script is a representation of the resource. Which it isn't. A representation of a resource is data, not a piece of code that executes on that data.

Building a Rest service

The example of a library is a decent worked example of implementing Rest clients and Rest servers. However, the design and implementation skimp on architectural correctness and the code itself is just below par.

The architecture is relatively straightforward, there's a collection for users, a collection of books, and a collection of books being leant out to users.

• Checking out a book involves a POST a book id to a collection inside the user collection. However, the content is the book id, and so there is no URL reference to the actual book. So one could not have a Rest client list the title of the book being leant to a user. Nor could you take any book and see if it had been checked out by anyone.
• The author can't decide whether he is writing HTML or XHTML, and the code examples regularly change from one to the other.
• The URL map presented actually differs from the URL map of the actual implementation. It felt like the author didn't get around to explaining mod_rewrite, and hoped that the Path info approach would be accepted unquestioningly.

Teaching by bad example

I tried hard to find something to like about this book. The Curl I found useful as a starting point, but I quickly realised that the author's knowledge, or working code was too sub-standard to be followed and eventually I had to sit with the PHP documentation to really figure out how to use Curl properly.

As a book about Rest web services in PHP this book falls short of any acceptable mark. I don't think it is acceptable to teach the wrong thing first until a certain level of understanding has been reached before then teaching them the right thing. This undoes any confidence or learning knowing that things need to be unlearned before continuing. Unfortunately this process isn't made clear, and many people will learn things about Rest that are not correct.

It does bother me when Rest is misrepresented in this way, because Rest is such an elegant architecture when it is allowed to be itself.

As an alternative to this book, I'd rather recommend RESTful Web Services by Leonard Richardson and Sam Ruby, and of course, anything written by Roy Fielding.