Just a quick note to let people know I'm currently swamped in end-of-year accounts tasks and will be scarce for the rest of the month.

I'll still be around for existing projects (SCE, etc) but the rest of my time is reserved for tedious accounts reviews, etc.

A while back I posted a link to the awesome DateJS library on my JavaScript page. Around that time I also looked at the code to see if there was any way to reduce the file size and possibly tweak the performance a little...

Geoffrey McGill from Coolite (where DateJS was developed) asked me if I'd blog about some of my findings but I never got round to finishing my post - so here it finally is, mostly compiled from emails that were exchanged at the time.

Performance

I'll start with this as it's the shortest topic in the blog and one that will possibly freak some people out. It's a trick I used back in the days of ActionScript 5 (slow performance) programming to get both surprising performance gains and also reduce the amount of typing I was doing!

A nice trick

See if you can spot the performance hit with the following code:

Date.prototype.clone = function () { ... };

Date.prototype.compareTo = function (date) { ... }

Date.prototype.equals = function (date) { ... }

Date.prototype.between = function (start, end) { ... }

Date.prototype.addMilliseconds = function (value) { ... }

It's a trick question, there are actually two performance hits, both of which we can quickly eradicate:

1. The first is that each time you reference Date that global object has to be located.
2. The second is that each time you reference the .prototype object on Date, you're forcing the JS engine to go find .prototype.

So, how do we fix this? Simple:

var DP = Date.prototype;

DP.clone = function () { ... };

DP.compareTo = function (date) { ... }

DP.equals = function (date) { ... }

DP.between = function (start, end) { ... }

DP.addMilliseconds = function (value) { ... }

Because DP is a local variable, it's faster to reference. Because you're not looking for the .prototype object repeatedly, it's faster still. As an added bonus, you generally type fewer characters and the file size also shrinks.

Give it a try - you'll be surprised, especially on big libraries.

Here's what Geoffrey says:

Your original suggestion re: var DP = Date.prototype made a big impact on the size (and performance) of the library. ....just changing to holding a reference to the Date.prototype, we shaved approx 1.2k off the total library size. That translates to ~4.5% size reduction. And, it's faster!

You can apply the technique to all sorts of things. You could argue that it can somewhat obfuscate your code, which it probably would if you use it excessively, however it should be possible for automated tools to implement the optimisation at build/runtime leaving your development code unaltered.

Running backwards (might be out of date)

Another trick I used to use was, where possible, iterating through arrays backwards using a while loop. For example:

var x = someArray.length;
while (-1<--x) {
 // do stuff
}

The variable x is used for aesthetic purposes, (-1<--x) just looks sweet IMHO, there's a "backwards flow" to it which I find strangely relaxing.

This was generally quicker than most other types of loop back in the day, but I've not had chance to test it against modern JS engines - if you test it, please let me know the results!

Shrinking the file size

My next mission was to see if I could shrink the file size of DateJS. I started with core-debug.js from the following URL:

http://datejs.googlecode.com/svn/trunk/src/

As the files will have changed a fair bit since then, I've attached them to this post.

1. Manual Filesize Reduction

I edited the file to replace some verbose repetitive code with while loops and also created a shortcut to Date.prototype. Diff the files to see what's changed. This resulted in core-guy.js:

Result: New version is a bit smaller

NB: I've not tested the core-guy.js version so it could contain bugs - if there are any they should be easy to fix.

2. JSMIN vs. /Packer/ (No, it's not what you think, don't jump to conclusions!)

Before instantly assuming /packer/ is bad: THIS IS A LIKE FOR LIKE COMPRESSION - ie. /Packer/ doing the same sort of things as JSMIN, nothing more, no Base62 or variable shrinking.

I downloaded the core.js file which used JSMIN (so I renamed it to core-jsmin.js for clarity) and compared it to Dean Edwards's /packer/ at http://dean.edwards.name/packer/ using the most basic packing (whitespace, etc).

Result: Packer versions are smaller

Again, I've not checked the packer versions - it's quite strict on syntax but any bugs should be easy to fix.

3. Even smaller: /Packer/ + Shrink Variables - gzip friendly!

The /packer/ also has a "shrink variables" option, which isn't available in JSMIN as far as I know...

Result: Packing + Shrinking is even better

There's no performance hit - all it does is intelligently shrink internal variable names.

The packed + shrunk variables version is perfect for use with gzip compression (ie. gzip will make it even smaller). This has been proven by jQuery and many jQuery plugins - yet most developers think that using "Shrink Variables" will make the gzip compression less effective.

4. Super-small for non-gzip scenarios

For scenarios where gzip isn't available (for whatever reason) the /packer/ also has a Base62 encode option:

Obviously, the Base62 option does have a performance hit - anything up to 200ms while it "unpacks", but then again in scenarios where you can't use gzip shaving a few more Kb's off the file size will probably make up for that. Once the unpacking is done there's no further performance hit.

Whether you use my tweaked core or the original core, the /packer/ gives a much smaller file for non-gzip use.

And finally...

I also used CompressorRater (http://compressorrater.thruhere.net/) to check core-guy.js against various other compression methods and /packer/ still gave the best results.

Some tips for packer

Don't discredit it because of the bad things you've heard about Base62 compression - that's an optional feature that you'll very rarely need and should you need it, you'll be thankful it exists!

Always put a semicolon on a new line at the start of your script to allow it to be safely merged and packed with other scripts.

Always put a semicolon at the end in scenarios like the following:

// bad:
var foo = function { ... }

// good:
var bar = function { ... };

Packer could chimp otherwise.

I was speaking to Peter Reiser earlier today about jQuery performance and mentioned a couple of tips that he asked me to blog about...

Give the latest nightly build a try

People testing the latest nightly builds are all saying that jQuery 1.2.2 is definitely faster than 1.2.1.

More info on the nightly builds and SVN here: http://docs.jquery.com/Downloading_jQuery

Tune your selectors

If you've got big web pages it's well worth making your CSS selectors more specific so they do less work.

First, try and limit them to a sub-section of the DOM, for example:

jQuery('.foo',context).whatever();

Where context is either a DOM element or a jQuery object. This instantly shrinks the number of elements jQuery has to wade through.

Second, think about the actual selector - is there something more specific you could use to reduce the number of elements searched?

For example, if you use '.foo' as shown above, jQuery has to search every element just to see if it has a "foo" class. If you know that you only want to find <div> elements with the "foo" class, use this instead:

jQuery('div.foo',context).whatever();

Learn from the speed tests

Before doing this, please note that the speed test results are very easily misinterpreted. People often think one library is worse than another if it seems to have poor speed test performance which is a naive assumption to make - the speed tests don't show real-world scenarios for which jQuery is superb and possibly only beaten by ExtJS.

Here's the speed test: http://www.kenzomedia.com/speedtest/

What you're looking for are the selectors that take the shortest time in jQuery - identify the trends and find out what's faster and slower in terms of the selector syntax then see if you can use that to improve your selectors.

As you can probably guess by the three-in-a-row blog posts, the tedium of doing the end-of-year accounts as well as the painstaking process of beta testing new versions of Theme Builder and Community Bubbles has taken me to the point where I could just scream. That would wake the wife up (it's nearly 5am) and she'd scream at me and probably throw something at me too. For the sake of everyone involved, I'm blogging!

We've had plans to revamp our website design for a while and as you can now see, the transition is pretty much complete. The page graphics have been floating around for almost a year but we've only just got round to implementing it. This time we decided to do a tutorial of the four stages.

Which brings me nicely on to...

New Community Spaces

We've been wanting to set these up for ages and get them in to a fit state for public consumption, and we've finally made some progress.

We set up our Theme Builder forum space a while ago, but it was a bit sparse. If you've not checked it since, go take a look now: Theme Builder community

Likewise, we've also added a Community Bubbles community which is worth a look because for the first time we're doing some of our development work publicly so customers can participate in the process and make sure we don't mess up what is a small but surprisingly difficult development task (it looks simple on the surface, especially now most of the concept pondering is complete, but it's been a real nightmare to do).

In addition, we've revamped the Scriptix community, adding a forum and some improved navigation.

We're hoping to achieve the following with the the new community spaces:

• Allow users of the plugins to more readily communicate and share ideas
• Provide a single source for the latest news and information
• Make it easier to find resources related to a specific plugin
• Hopefully offload some of our huge customer support workload in to the public forums (seriously, this would really help us roll out product updates far more quickly if you start chatting in the forums!)

By watching the community spaces, you effectively join a mailing list and hook in to all the latest tutorials, forum discussions and news for the associated plugin.

I'm giving serious consideration to moving the user guides for the Builder and Bubbles plugins in to their respective spaces to really bring everything together, but I'm not sure if it would lead to too much noise in terms of change notification emails for people watching the space. What do you think?

As part of the recent community space binge, I've also turned my blog in to a forum/community too!

Right, I'm probably going to be in "Monk Mode" for the rest of January, locked away in a dark room chanting and performing strange rituals... Unless said activities once more drive me to a blogging frenzy!

Blame Charles Miller for this one (and Dan Hardiker for telling me about it)...

How to create your album cover:

1. Your band name is the title of your first hit on Wikipedia's random page
2. Your album name is taken from the end of the last quote on this random quotes page
3. Your album cover must be made from the fourth picture on Flickr's interesting photos page

For me, that was:

1. Circuba
2. Some mornings it just doesn't seem worth it to gnaw through the leather straps.
3. I sublimate my rage through needlework

I decided to leave the whole quote intact, although I suppose "Gnaw through the leather straps" would have been equally satisfying.

@Charles Miller: What is it with you and cheese anyway? You sure you didn't fudge your album cover? Are you perhaps trying to convince computers that it is they who like cheese?

A growing nightmare here at Adaptavist comes in the form of support tickets not being handed to the customer or support team at the right time. This is down to the UI in JIRA making it less than obvious how to hand a ticket over - so Dan Hardiker decided to start hacking with jQuery... (NB: 2MB video file in this post)

There are two times when a ticket needs to be handed over...

1. When a customer posts a comment that needs our attention, the ticket should be handed to Adaptavist
2. When we post a comment for the customers' attention, it should be handed to Customer

The problem is that we can't just automate this - there will be many times when we post comments but aren't yet ready to hand back to the customer and vice versa. That would cause even worse problems (we know, we tried).

This might sound like no big deal, but it's getting to the point where we've got one member of staff spending hours each day handing tickets back and fourth so that the support team can get on with, erm... supporting! If we grow our customer base by another 100% this year, we're going to need to take on full time staff just to hand tickets over. Not good.

What we really needed was some way to prompt the user when the add a comment, asking them whether the ticket needs handing over. This reminds the user and also puts them in control. And more importantly, it saves us several hours a day to get on with more productive tasks.

We used jQuery and it's Impromptu plugin (we might switch over to the Facebox plugin for the final version) and dumped the magic in to a custom field as this was a quick hack.

We work out if the logged in user is from Adaptavist or one of our customers (using JIRA API via a velocity template) and then work out if they need to be prompted to hand the ticket over.

We use jQuery to bind an onclick event handler to the "Add" button - when it's clicked, the prompt is shown if applicable and depending on what choice the user makes we fire their comment to the relevant back-end script.

Our hack is still in the early stages, but already working like a charm. It's only active on one specific issue in our support system, that you can't access, so for now you'll have to make do with this video:

P.S. Famke Janssen is officially at the top of my "Future Wives Wishlist", especially if she's dressed as Jean Grey from X-Men. Mmmm, tasty goodness.

P.P.S. This should really have gone in Dan's blog as he did the hack, but he's still not got round to setting it up. Grr!

Just as plugin developers are catching up with Confluence 2.7, Confluence 2.8 throws another set of tasks our way...

Confluence 2.7 introduced some changes to system administrator permissions that caused some pain for any plugins that make extensive use of permission checking. Most plugins in the repository, however, have now caught up with the changes but there may still be a few that haven't.

In Confluence 2.8, there's another change - this time to the Velocity templating engine that's extensively used by virtually every plugin out there that has any form of user interface.

Atlassian are moving up to Velocity 1.5 which is stricter in a number of areas - typos that would be ignored or accommodated in earlier versions will need fixing.

For avoidance of doubt, this move is a good thing! Velocity 1.5 has better error checking (it doesn't swallow exceptions by default) making it easier to detect and fix errors that were previously going unnoticed.

Atlassian have done a sterling job of getting documentation out about the updated well in advance of the public release of Confluence 2.8. For more information, check out Migrating to Velocity 1.5 on Atlassian's wiki.

At Adaptavist the race is now on to release Theme Builder 3.0 before Confluence 2.8 lands. We need to get a 3.x version released that's compatible with Confluence 2.5.x-2.7.x (and then a possible bugfix release should our 24 beta releases have missed anything).

Due to the changes coming in Confluence 2.8, it's possible that a version of Builder for 2.8 won't work on earlier versions of Confluence.

There are other changes planned for Confluence 2.8 that are noteworthy:

• Java 1.4 support will likely end - if it does, this will be a dream for developers as Java 1.4 and associated application servers are really starting to show their age.

• More of the UI is being styled using CSS. Atlassian started the process of kicking the UI in to shape in Confluence 2.6 and there is another big drive on this in Confluence 2.8 from what I hear. It's great news for Theme Builder as it's going to make it possible to customise Confluence more than ever before

• Tangosol (the clustering stuff) is being upgraded to fix a memory leak. As a company that provides hosting to lots of customers, Adaptavist love it when memory leaks are fixed.

• Space keys with hypens bug fixed (this was one I reported) - sweet!

For the full list, see the 2.8 roadmap.

Anyway, that's all for now. Been a really long day wading through accounts, checking over our 2008 legal documents (NDAs, EULAs, etc.) and setting up yet more community spaces on our site including a new Host Service space and revamping our Partner Network Extranet with much needed tools like forums and improved navigation.

A new study has shown that jQuery is the fastest loading mainstream JavaScript library...

Check out the stats

I'm not sure if their packed tests were using /packer/ but would assume they are. As I've said before, packed JavaScript files are only there as a last resort if you can't gzip things (in which case the reduction in download time generally outweighs the time it takes to unpack). Otherwise you should stick to minified + gzip for best results.

Just some random photos of life at Adaptavist...

Atlassian, Adaptavist, netoCiety, Thales
Thales Confluence User Group

GeekUp Christmas Dinner
Velvet, Manchester

Huw Evans
Hosting Services

Alain Moran and his better half, Jo
Theme Builder, Community Bubbles

Dan Hardiker
Bespoke Solutions, Confluence Support

Brussel Sprout
The wife is banned from eating these

Server Work
Greenhays, 28 December 2007

What happens when you mix Java Developers, BeJUG, Atlassian, Google, a woman in sexy boots, mechanised carpet cleaners, and Belgian Beer with Adaptavist...?

I'm not even going to try captioning these pics...

Been a grim day so decided to write a search plugin for my browser...

Wading through accounts all day has been tedious and to top it off, some mods to our latest beta of Bubbles corrupted data on a development server and when I tried restoring a backup it died horribly but I don't have enough access to the server to go in and fix it. Rargh!

So, I'd been discussing the idea of search plugins with Dan earlier in the day (anything to try and keep accounts work interesting) and one thing I wanted to try was adding a search plugin to the browser.

Luckily, it just so happens that Firefox supports open search. There's even a handy tutorial on the FF dev site

The only problem is - their docs are wrong. And to make matters worse, Firefox gives utterly useless error messages when your XML is wrong, or indeed anything else - it's like they just trap for any exception and spit the exact same error message out regardless of exception.

So, to save anyone else trying to make an open search plugin that works in Firefox 2 or above and Internet Explorer 7 or above, here's the XML I used:

<?xml version="1.0" encoding="UTF-8"?>
<OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/">
  <ShortName>Adaptavist</ShortName>
  <Description>Search Adaptavist Website</Description>
  <Tags>adaptavist wiki</Tags>
  <Contact>help@adaptavist.com</Contact>
  <Url type="text/html" 
       template="https://www.adaptavist.com/dosearchsite.action?searchQuery.spaceKey=conf_global&amp;searchQuery.queryString={searchTerms}"/>
  <LongName>Adaptavist Website</LongName>
  <Image height="16" width="16" type="image/png">https://www.adaptavist.com/download/attachments/918/icon16.png</Image>
  <Query role="example" searchTerms="builder" />
  <OutputEncoding>UTF-8</OutputEncoding>
  <InputEncoding>UTF-8</InputEncoding>
</OpenSearchDescription>

I attached the XML file to our home page as a file attachment so it's publicly available.

I then added an auto-discovery link to the <head> section using Confluence's Custom HTML feature:

<link rel="search" type="application/opensearchdescription+xml" title="Adaptavist" href="https://www.adaptavist.com/download/attachments/918/adaptavist.xml">

And viola! If you are using a modern browser, check the little arrow in (or next to) it's search box for a list of search engines...

Now you can quickly search our user guides, forums, communities, tutorials and everything else you have access to on our site from the comfort of your own browser search box (obviously you need to select Adaptavist as the search engine before doing the search)

I'm rapidly coming to the conclusion that all the dire issues with banks, accountants and indeed anything in the financial sector is by design, not incompetence.

Let's take OFX files for example. These could have quite simply been standard XML files, XML arguably being the worlds most widely adopted text-based data transfer format.

But oh no, not in the financial sector, where doing things correctly is against the law (literally I believe).

An OFX file starts with something like this:

OFXHEADER:100
DATA:OFXSGML
VERSION:102
SECURITY:NONE
ENCODING:USASCII
CHARSET:1252
COMPRESSION:NONE
OLDFILEUID:NONE
NEWFILEUID:NONE

WTF is that? Why not just have that data expressed as XML?

Then you get to the actual transaction data itself, let's take a look at an example:

<STMTTRN>
<TRNTYPE>DEBIT
<DTPOSTED>2006102*******
<DTUSER>2006102*******
<TRNAMT>-1424.95
<FITID>20062991859260*****
<NAME>ATLASSIAN SOFTWARE
</STMTTRN>

(asterisk's added by me to mask data)

Again, WTF is that? Why not just use normal XML? XML that could have a strict DTD and be easily translated with XSLT? Oh wait, that would require common sense and the ability to do things in a simple, logical and correct manner. Can't be doing that in the financial sector now, can we?

This level of insanity cannot come from incompetence alone, it has to have been designed in to the OFX format. There's no way any techie born since 1970 would have implemented something as insane as the OFX file format.

I know money is just an instrument of population control for the central bank, but making people wade through crap like this just to tie up brain cycles is pushing it too far.

Microsoft have devised a new way to prevent open standards from taking over the Internet...

If don't know what the fuss is about, read Beyond DOCTYPE: Web Standards, Forward Compatibility, and IE8.

In this post I refer to the meta tag as "hack tag" because that's exactly what it is, and also for reasons that will become apparent later in this post.

A friendly alternative to get started...

If you've read the article and are sat there thinking Hey, that's a good idea!, please humour me and think of an amicable alternative...

Why don't they make IE8 be standards-compliant by default (it's not caused problems with all the other browsers, has it?) and have a hack tag that says "run as IE7" for bug-dependant sites?

A great number of sites that work on IE7 will already work on IE8 and therefore not need the tag at all. Some might need subtle CSS changes and the really bad offenders can beg for IE7 with the hack tag.

This would:

• reduce the number of sites that need the hack tag, as I dare say the vast majority will just continue to work
• clearly flag bug-dependant websites for all browsers, allowing all browsers to be standards-compliant by default
• let the site owner know that they are falling behind the rest of the world, but give them plenty of time to address that issue

I think free software would appear very quickly to add the "beg for IE7 hack tag" to all HTML files in a folder structure and any form of CMS can very quickly be tweaked to add it in as well.

There are a finite number of existing web pages on the internet. There are an infinite number of future web pages that will appear for the rest of time. Why is the hack tag being imposed on the latter when it would only be needed on a fraction of the former?

Ok, now let's get on to the more contentious issues...

Let's clear some stuff up...

The article posted on A List Apart makes some very misleading as John Resig points out in his blog:

What is he referring to?

• The article states that Microsoft worked with the Web Standards Project - misleading
• The article gives the impression that other browsers are somehow taking part in this madness - unlikely

Make no mistake, this is a Microsoft only feature designed to generate Internet Explorer lock-in and disadvantage other browsers, but I'll discuss that in more detail later.

Worse still, Microsoft also try and pin the blame for this on to existing web developers, as isolani points out:

Ok, so it's us web developers who've been crying out for standards compliance in Internet Explorer for years that are to blame? I think not! If IE wasn't utterly broken from the outset, the problem would never have existed in the first place!

But there is some truth in Chris's statement...

How did we get to this sorry state?

One of the biggest mistakes of the web development community was to struggle to try and make sites work on old or buggy browsers.

You see, we're all really determined to give our end-users the best experience possible, even if it causes us vast amounts of pain trying to hack around Internet Exploder to try and convince it to do things properly.

We start by developing websites and online applications based around open standards. Then, about 60% of our project time is spent trying to make them work on Internet Exploder - a process that mandates adding all kinds of hacks and cludges in to our markup, style sheets and code.

Unfortunately, our efforts have backfired on us. By supporting buggy browsers, we've actually prolonged the life of them and the sites that came to rely on those buggy browsers.

We've created a rod for our own back. A self-fulfilling prophecy of doom and despair. As web developers, we have to accept some of the responsibility for these problems.

But then again, every single web developer I know develops for standards-compliance first and foremost. We are only forced to add cludgy and crufy hacks because Internet Explorer still has the dominant market share (because it's installed by default on the dominant operating system, Windows).

Imagine for a minute...

If we all stopped supporting browsers with bugs, across the board, guess what will happen...

If the browser used to view the site is broken, then the person using that broken browser will be seeing lots of "broken" sites. They're quickly going to realise it's not the sites that are broken, but their browser. That's going to be a rather good incentive to upgrade to a browser that isn't broken.

That in turn will make people with sites that break on standards-compliant browsers wake up and think "hey, I need to fix my site ... now!". It's not going to take as long as you think for the world to adapt to a standards compliant nirvana.

This creates a positive feedback cycle: Users switch to standards-compliant browsers, more sites become standards-compliant, more users make the switch to standards-compliant browsers...

Do you take the blue pill or the red pill?

So, Microsoft have been raving about standards-compliance in Internet Explorer 8... It's strange, then, that Microsoft would do all that work at great expense and then by default run the browser in non-standard mode.

Why would anyone do that? There must be a reason...

So which pill do you think Microsoft took?

Why would you take the blue pill? It's obviously the wrong option. Well, as with so many "wrong options" that get taken, there's ulterior motives behind it.

You see, Internet Explorer is losing market share because all the other browsers are innovating at an ever increasing pace. That's bad for Microsoft.

But what if Microsoft could slow down the adoption rate of other browsers? Perhaps they can – if they can keep the internet filled with bug-dependant sites that don't adhere to the open standards...

With practically all web developers now utterly sold on the idea of standards-compliance and semantic markup, there needs to be some incentive to make them do things that they don't want to do?

Enter the hack tag - the nemesis of standards-compliant nirvana.

This tag does three key things:

• it allows Microsoft to say they have a standards-compliant browser (when in reality, 99% of sites won't have the meta tag and therefore still be viewed in the buggy IE7 mode),
• it allows Microsoft to assure worried business men that their existing web pages will still work (when in reality, most of those sites will still work in IE8 regardless), and most importantly of all...
• it promotes the retention of bug-dependant web pages long past their sell-by date, thus calming the desire to promote standards-based design and hindering progress of competing browsers which thrive on standards.

Oh, there's actually a couple more things:

• you'll only be able to view those bug-dependant websites using Internet Explorer
• most sites won't use the tag, and therefore run in "buggy" mode, but you can bet that all the Microsoft platforms use it - then you'll start hearing how you have to use Microsoft technologies like .net and ASP, etc., to make reliable sites

I'm starting to see why Microsoft took the blue pill. It works out great for them and real bad for everyone else.

Some show-stoppers

Here's just a brief summary of the blatantly obvious nightmares that are going to ensue should Microsoft actually include the opt-in standards support:

We are not amused

As you'll see from the vast amounts of comments on the article (and indeed practically everywhere else on the web that discusses the proposal new proprietary standard Microsoft is forcing on us), web developers are less than amused by the idea.

As a web developer, I'm not prepared to keep wasting 60% of each major project on "making it work in IE" and I'm sure as hell not going to implement anything that prolongs the existence of broken sites and broken browsers.

This is a blatant divide and conquer technique from Microsoft. They are actively going to screw up the Internet in a bid to reclaim their once total monopoly on the browser market.

The entire web development community needs to come together and say:

What can you do to help?

Simple...

For developers:

• Avoid using the hack tag in your sites, instead use the HTML5 DOCTYPE (which Microsoft tell us is dead, but then quietly confirm is alive and kicking)
• Develop your sites for standards-compliant browsers. Only change things if people complain - and when they do, ask them to try a modern browser and see if that helps.

For end-users:

• Stop using Internet Exploder NOW! Use Firefox, Opera, Safari, Konqueror or any other standards compliant browser.
• When you see a site that only works in IE, complain to the site administrator

Yay! Manchester is finally having a BarCamp and Adaptavist are sponsoring the beer!

Yes, it's been a long time coming and although Leeds beat us to it, BarCamp Manchester is finally happening on March 1st 2008.

NB: That's not the official logo, I just threw that together to celebrate beer

Speaking of which... Because we liked drinking lots of beer at the Leeds BarCamp we decided to sponsor the post-camp beer at the bar

The event is already fully booked so it looks like it's going to be a great day!