Builder 3 - Niiiice!

Note: I'd originally posted this a week or so ago but in my haste posted it as a page and not news. So here is the blog version.

A few months ago, I would have said I was the busiest person alive, but things just keep getting more and more hectic.

Amongst the chaos of a rapidly growing company, I've managed to work on a couple of really tasty projects involving Builder 3 (still in Beta as we've not found time to add the licensing code yet *sigh*).

This post could be seen as blatant promotion for one of our products (well, I guess it is really) but that's not why I'm writing it. I'm genuinely excited about this upcoming release of Builder because the plugin has definitely become what I envisaged when we first started out developing Builder shortly after Adaptavist was founded a few years ago.

The plugin is now mature. It's rock solid, very fast and packed full of amazing features. It's some of these new features that really make it rock my world (and hopefully clients will feel the same).

There won't be any screen grabs in this post because I just don't have time, but I'll try to link to pages in our user guide where you can see a bit more. Some of the user guide pages aren't complete yet but I'll link to them anyway heh.

Centralised Layouts

One of the biggest gripe about Builder 2.x was that if you wanted to use the same layout on more than one space, you needed to download the theme config from one space and upload it to the next space and so on.

Not only was this a tedious process, but it meant that if you changed the theme in one space you then had to repeat the whole darn process. Not nice!

To completely erase this issue, Builder 3 now uses centralised "layouts" (essentially theme configs stored centrally rather than on a space by space basis).

When you want to apply a layout to a space, you can use the Layout Chooser to simply pick from the list of available layouts (complete with live preview of what your space will look like!) or use the awesome new Manage Spaces tool which allows you to centrally administer theme settings and even do bulk updates.

Because the layouts are centralised, changing one instantly updates all the spaces that are using it

Layout Inheritance

Oh my, this feature really does rock my world. It saves so much time!

Layouts can inherit settings from their parent layout - this means that I can create a master "look and feel" layout and then have other layouts which are based on it but change various things, eg. add side bars or different navigation.

It's probably easier to understand by reading our page on Layout Hierarchy.

Space-level customisations

In Builder 2.x, to customise the theme at space level you had to do just that - customise the theme. For most space admins, being dumped in to the fully blown theme customisation tool is a tad overwhelming to say the least.

When we centralised layouts in Builder 3, we realised that space admins no longer had any customisation options - sure, they could select a layout, but what if they wanted to change the colours or add extra navigation, etc?

So, after much internal hair pulling and chin scratching one of my all time "most wanted" feature requests got added in - the ability to use colours defined in the Confluence "Colour Scheme" within the layout visual editor and custom CSS settings.

One one of the projects I've been working on, this instantly cut my workload by two thirds - instead of having to make 3 layouts just to handle different colours, I now only had to make one and set it up so that the colours could be defined using the colour scheme.

I then started investigating how to make the navigation more customisable and thanks to things like the "include" and "import" macros, that became really easy - just as you can customise the navigation in Atlassian's "left navigation" theme, you can now do the same in Builder layouts, only with far more flexibility.

I've been able to create a layout which, with very little effort on my part, allows space admins to easily add items to the menu bars, sidebars and elsewhere.

Performance

Oh my, we've excelled ourselves! Some of our larger clients were running in to problems with performance. Builder tends to use lots of macros and lots of CSS, JavaScript and image files.

Our first major breakthrough came when we realised just how much overhead there is to process a Confluence macro. Any macro. It doesn't matter how simple or fast the macro itself is, there's a fairly big overhead for Confluence just to render it.

We decided to create a new compound-menuitem macro which combines all the features of the menuitem, menulink and menuicon macros. Furthermore, it has no "body" so as well as shrinking three macros in to one it also removes two "body" renders. The result - menus are instantly three times faster!

Next, we decided to take a long hard look at caching all the various resources. Caching has always been a problem for plugin resources because the "resources servlet" generally doesn't output the headers the browser would need to do caching.

To start with, we combined lots of the CSS and JavaScript resources - so instead of needing something like 11 external files only 3-5 were needed. That instantly takes a fair chunk of latency out of the equation.

We were able to add much improved "cache expire" headers to our CSS files but struggled with the other resources pulled from the plugin. Sure, we could easily have written our own servlet but this seemed insane - surely there was something lurking deep within Confluence that would already provide this functionality...? And there was!

In just a couple of days, we had extreme caching applied to practically every resource imaginable. You still need to load the resources the first time you visit the site, but after that they are well and truly cached by the browser.

We also looked at the internals of the plugin and even the placement of various things in the output HTML (eg. move CSS to the very top, move JS as far down as possible).

The net result is that for a page which would take 11 seconds to load on Builder 2.x, the equivalent page in Builder 3 takes 1.8 seconds to load. It feels fast!

Read more: Performance Tuning 3.x

Search Engine Optimisation

No, not Confluence's search engine, public ones like Google and Yahoo!

With Theme Builder appearing on more and more public-facing sites, SEO had started to become an issue.

Amongst other things, we've now added new features for controlling "robots" - for example, should pages be indexed, should their snippets come from public directories, should links be followed?

Theme Defaulting

Oh the joy. In our theme admin you can now set the default layouts to use for global and personal spaces. Create a new space using Builder as it's theme and the relevant layout is automatically applied. Sweet.

Gah, the phone rings - looks like that's all for now! You probably won't hear from me again until Builder 3 is released but you can keep track of where things are up to in our user guides.

Just quick note about some proposed pricing changes that are happening at Adaptavist over the coming months...

Not only do I want to give existing clients advance warning of the hikes, I also want to explain why they have arose. A key company goal at Adaptavist is to keep prices low enough so that smaller companies are not priced out of the enterprise wiki arena and we're making sure these price hikes are in keeping with that goal.

Even though our company is growing quickly, it's not growing fast enough to keep up with demand. As such, there are going to have to be some price hikes in various areas

Currently we maintain a good level of balance within our company by not having a sales team. In order to get more new clients, our staff have to take a break from their usual activities to deal with sales enquiries, etc.

The benefit here is that when our staff are very busy supporting existing clients, we're less able to take on new clients - the result is that existing clients (who keep giving us more work) are well looked after.

For Adaptavist, looking after existing clients is more important than getting new clients. It's the reason we have 1000+ clients in 50+ countries - happy clients are our sales team.

But, even though we don't do any real advertising, the number of sales enquiries we are getting is rapidly increasing. In many cases we're turning down work because we don't have the resource to do it but even the time spent turning down work is starting to cause a major drain on our resources.

We normally try and find one of our competitors and introduce them to prospective clients that we've declined on the basis of being too busy.

A quick "aside":

Unlike any other market sector, we've actually become great friends with our competitors. We don't see each other as competing, merely as working towards the same goals. We even share code and ideas with competitors to reduce the amount of duplication in our efforts.

The problem is that all our competitors are also now too busy to take on much more work.

In short: Demand is exceeding supply.

I've noticed recently that Atlassian have hiked prices for their bespoke services (which are often outsourced to companies like Adaptavist) and unfortunately we're going to have to do the same.

We're not looking to bring in a sales team - that would break the balancing effect of our sales process and start to impact our commitment to existing clients.

Instead we'll be looking to bring in more developers who can actually do the work. As our support desk is manned by those same developers this will also further improve our highly-acclaimed customer support services.

We've recently taken on Huw Evans to help out on the hosting side of our business (which is also growing rapidly) and will be looking for Java developers over the next year who can help with plugins and some of the more complex areas of application support.

Skilled people come with skilled price tags. So, what's the effects going to be on our prices?

Summary

• Bespoke Solutions - discounts removed, possible increase in hourly rate next year
• Confluence Support - prices to stay the same, but with the addition of a new "fix now, price is not an issue" tier for our largest customers
• Hosting - prices to remain the same for foreseeable future
• Plugins - sliding scale licensing model, generally more expensive

Bespoke Solutions

The observant amongst you may have already noticed that we've had to ditch our discounts for 3+ days of bespoke work.

We originally offered those discounts because a project that lasts for more than 3 days has already covered the cost of sale.

However, as we've grown, we've found that project management and client communication overheads have increased and the discounts were having an adverse impact on those activities. The removal of discounts should have a direct benefit on that service.

Confluence Support

There are no planned price changes to our Confluence Support (which will likely get renamed to "Application Support" at some point) at present.

That being said, it's possible that a new tier will be added to our support services for our very largest clients who need even more responsiveness than our current support contracts provide. For example, we have clients who need any number of tasks "completing now, price is no barrier" - this includes support and also plugin development, etc. We're currently discussing this internally but if you have any feedback, let us know.

Hosting

The prices for our Dedicated hosting aren't going to change for quite some time. Although energy costs have increased and will continue to do so, we've worked very hard with our energy provider (via our up-stream providers) to keep the costs below market average. That being said, we're investing heavily in additional equipment for our hosting environment - our own UPSs (uninterruptible power supplies with inline power filtering), PDUs (power distribution units), out-of-band terminal servers, etc. However to balance that servers are getting cheaper and are using less power.

Our Shared Hosting and Remote Hosting pricing is also likely to remain at current prices for the foreseeable future for the same reasons.

By foreseeable future I mean "at least a year, most likely 2 or more".

Theme Builder and Community Bubbles

Sales of Theme Builder are going crazy. We're roughly doubling the number of sales on a month-by-month basis.

Interest in Community Bubbles (as yet unreleased but already in use by some of our larger clients) is soaring and we have a long waiting lists of clients who want to purchase the plugin the second it's released.

The amount of developer time that's being going in to these two plugins is immense.

Because we subject our plugins to extensive beta testing (both internally and with clients worldwide), the support load per-client is very low. Generally we expend roughly 2 days of support time for every 20 new clients. A small percentage of the clients are pushing the limits of the plugins and submit feature requests plus the occasional bug. Once the client has the plugin set-up, we generally don't hear from them again until they come to extend the maintenance period (support and upgrades).

With each successive release of our plugins, more bugs are fixed, performance is improved as is usability, etc. - so the support time per 20 new clients actually decreases as the plugin matures.

However, sales are doubling each month! Back in the days where we used to only get 20 new clients per month, we'd spend a few days supporting them. Now, however, we're spending weeks.

This has had a very significant impact on the rate at which we release new versions of existing plugins and roll out completely new plugins (like Community Bubbles). If sales continue to grow at their current rate, it will also start having an impact on support and sales. We'll effectively collapse under the weight of our own success.

As such, there are going to be some pretty major price hikes for the plugins, but on a sliding scale so that smaller deployments will actually become less expensive whereas the biggest deployments (for which a lot of the more advanced features were developed) are more expensive.

To implement this sliding scale, we've decided to create a licensing model almost identical to that of Atlassian.

So, here is our current proposal (feel free to contact us with any comments or ideas):

As you can see, Workgroup licenses and above are now more expensive. The smaller licenses are the same price or cheaper. As usual, the plugins will be free for any clients Shared-hosting with us.

The site license is still under heated discussion.

Our website is feeling a bit under the weather. With such excessive workload at the moment (sales are now doubling every 2 weeks!) we've just not had time to look after the site. There's a bunch of broken plugins after a recent upgrade, we've not added additional RAM to the server for ages and we never did get round to optimising our single sign-on.

To make matters worse, a few hours ago we had some data loss (probably due to the site running out of memory) and all our "user macros" and some other things got nuked. You probably won't have noticed because all our plugins are built like "A-10 Tank Killers" - a US fighter plane that can still keep flying even with 90% damage. That's how we like our plugins to work

From what I can tell, the google-analytics macro and the macros on the Builder price list are the only visible signs of the data loss at present. At some point the lack of RAM will nuke the cached data and lots of other things will break, but hopefully we'll have got round to restoring the data from the backup by then.

This does have one benefit though - we'll have a whole day without any Builder sales. It'll be like a company holiday!

I was recently looking at our site stats and noticed that we were getting 4000 unique visitors a day on average. They were creating something like 20,000 page views every single day (yes, some of those users were Google, Yahoo and other search engines re-indexing our entire site on a daily basis - grrr!). Considering that we're still running in about a gig of RAM, I'm amazed the site is running at all. Kudos to Dan and the server team for making Confluence use so little RAM!

We're also starting to graze the upper limits of the capacity of one of our suppliers that provides email hosting. When we started Adaptavist, we decided to outsource email hosting because it was just too much hassle for a small company to be dealing with internally. Our supplier has done an amazing job of dealing with ever-growing email load we place on them, but we'll soon have to look for either another supplier or start bringing email services in-house.

Anyway, I'm off to bed (finally!) as I have a very busy day tomorrow.

Up to my eyeballs in work as usual, but I just had to blog about this...

Recently I've been involved in lots of front-end work and have obviously encountered lots of javascript frameworks.

So far, only one framework has impressed me – jQuery. But let's find out about the others first...

Prototype

URL: prototypejs.org

This is probably one of the worst frameworks out there. Not only is it bloaty but it commits the cardinal sin of putting all sorts of cruft on all my JS objects.

Unfortunately, Prototype is at the very heart of Confluence - remove it and chunks of Confluence functionality suddenly stop working as do several of the more advanced plugins.

I know Prototype has been around for a fair while, but it's implementation is conceptually wrong. You can't just go around adding methods to core "primary citizen" JS objects! Wrong, wrong, wrong!

Suddenly, you find yourself iterating through arrays or objects and having to deal with all kinds of unwanted things appearing. So then every iteration needs to have a list of "crap that prototype added" to remove from the list. Nasty.

Confluence is particularly problematic in this respect because it appears to contain two copies of Prototype! The first seems to be pulled in via script.aculo.us and the second is a "customised" version in labels-javascript. Really nasty!

Including protoype in your web app is like using a sledgehammer on a watermelon. Overkill and very messy.

Script.aculo.us

URL: script.aculo.us

I liked this library for quite a long time. It adds some nice effects to your web pages and that's why most people use it.

But, there are some issues. First and foremost, it requires the terrible prototype library. So now your apps are all bloated and virally infected by conceptually misguided ideas.

The second issue, at least in my experience, is that it seems to give rise to memory leaks. Whenever I've worked with script.aculo.us I've always had to tread really carefully to avoid such issues.

That being said, I find their UI control library to be very reliable. But that's really not enough of a reason for me to infect my web pages with Prototype.

Dojo, Dijit, Dojox

URL: dojotoolkit.org

Hrm. Ok, there are some good things and bad things about this toolkit.

The thing I like most is dojox - the incubator for all the latest crazy ideas. Having this separate incubator where each idea gets its own project seems really nice to me. It certainly helps promote the incubator projects which would otherwise just be hidden away in the background.

Next, dijit - Dojo's widget library. To be honest, I find the widgets uninspiring and very buggy, and the authors agree.

Which brings us to dojo itself. Ah man, what can I say. HTML with custom attributes splattered all over the place. Don't get me wrong - there is some useful stuff in there, it's just too darn messy to use though.

ExtJS

URL: extjs.com

One day, this will be the JS toolkit, especially for web apps. It looks great, it's being developed at a very fast pace, but...

We've used it on a number of projects so far (including Theme Builder 3 and the Confluence Translation plugin) and have come to realise that it's just too "new" to be used in a production environment.

I think Dan Hardiker recently summed up the problem nicely: It shrank 90% of the work from 10 days in to 1 day. But the other 10% exploded from being 1 day to 22.

That's dangerous. If we'd taken a more conventional approach, we might of ended up with something that was more visually boring, but it would have been completed in 11 days. Ext makes some hugely complex things really, really simple. But it also makes some simple things hugely complex and you can't predict what those things are.

The ExtJS docs all appear to be marketing led - "look at this cool thing you can do with ExtJS". But when it comes to doing basic things you'll find yourself spending insane amounts of time wading through the source code (and there's lots of it) trying to find out what to do.

Keep your eye on this library - in a year or two it will be amazing, but for now don't use it on any time critical projects - there are nasty holes in the documentation and functionality.

jQuery

URL: jquery.com

I've been developing in ECMA based scripting (JavaScript and ActioScript) since the languages first appeared on the net. This library made me jump with joy. Literally. It's taken over a decade, but finally the Eureka! moment that JavaScript has been so desperately waiting for has happened.

First, the library is tiny (14kb packed!) and unobtrusive. It doesn't start infecting all your JS objects with garbage, it doesn't have any memory leaks that I'm aware of and it doesn't have 2834792387 separate JS files to include.

It's a library that you can use when you want to use it. All the other libraries force you down a path - to get the most from them you have to extensively use them not just in the places where you want to use them, but generally everywhere else.

jQuery is different. I can use it in my own code anywhere I want without hesitation. Just because I use it in one area within my code, doesn't mean I have to start converting vast swathes of other stuff over to using it.

jQuery encourages you to properly separate behaviour from content, just like CSS encourages you to separate design from content. I can't think of words to accurately convey just how important this is.

You start off with a basic interface built out of semantic HTML, then make it look nice with CSS, then make it play nice with jQuery. The concept - and implementation - are absolutely spot on.

The default library contains an astonishingly simple way to locate HTML elements and perform actions on them. If you love CSS, the chances are you'll love jQuery.

It's very simple to create your own plugins for jQuery - with just a few lines of code you can fully integrate your own functionality in to the framework and a quick look at their plugin library is testament to how easy it is to do.

jQuery is currently up to version 1.2.1 and it feels mature. Everything is rock solid stable. You can abuse it and it just comes back begging for more. That's something that's missing from all the other JS libraries I've tried.

Now, it should be noted that unlike most of the other libraries/toolkits, jQuery wasn't designed to create snazzy web app interfaces. While there are lots of UI plugins available for it, don't expect to be creating an online version of your desktop apps any time soon.

That being said, now the core jQuery functionality is well and truly perfected, their focus has shifted to the UI layer. It'll take another year or so for them to get it right, maybe longer, but expect amazing things from them!

Clients are pinging me on IM so gotta go. But one last word - start playing with jQuery! If you don't understand it then the chances are you don't understand front-end development

Hmmm, seems I'm blogging more these days. Anyway...

Just wanted to jot a quick note on something I've found rather unique about the development of our Community Bubbles plugin (yeah, it's still not released). There are several things that differentiate this plugin from any other development task we've ever encountered, but there is one in particular...

Conceptual Workload

This is the primary reason why the plugin has taken over 18 months to develop so far. We've spent vast, vast amounts of time just getting the concepts right.

You'd think we could just look to the interweb (kudos to Ask a Ninja!) and use the plethora of concepts that are already in use on bewildering number of social networking sites...

No.

You see, there are some reahhhly big problems with those sites.

First, they have high churn rate - once you've done your social networking thing and added all your friends and 89482394 people you've never even met, they become utterly pointless. I mean, what use do they really have other than defining who your friends are?

The sites rely on a constant influx of new people to replace the people who have already got bored and left. They don't have a future.

You certainly don't want that to happen in a corporate environment.

Notable exceptions are Facebook and LinkedIn (you can find pretty much everyone at Adaptavist, Atlassian and most of our clients on these sites).

The next problem is that the vast majority of social networking sites are, erm, social networking sites. This is kind of the same problem as the point I made above, just looked at from a different angle (and possibly from behind a shrubbery).

For corporate (or other organisational) use, the social aspect has to be there, but it has to work differently. You're not going to be seeking out old college friends and making lists of potential second wives or anything like that. It's got to tie in to what the company/organisation is doing in some way. It has to be contextual.

Then comes the killer - social networking within an organisation has to take in to account that not all end-users are going to be tech-savvy. This is a problem that really doesn't exist with any social networking sites on the interweb where you can simply ignore anyone that "doesn't get it" because there are millions more people who "do get it".

In an organisation the terminology, user interaction model and generally everything else needs to accommodate people who a) don't even want to use it but have to for some reason and b) have never used anything like this before. But, you also have to try and meet the high expectations of all the people who do use social networking. Pain, lots of pain.

And, finally (well, at least for this blog), Confluence isn't built from the ground up as a social networking portal.

It's a wiki and the social networking (as we've learnt from the projects we've worked on so far) is actually a secondary requirement.

There are two issues with this:

• We've had to develop lots and lots of stuff from the ground up, but all the time trying to fit within the way things are done within Confluence
• Making the user interface of a wiki and social networking features (like portals, widgets, friends lists, communities, etc) consistent has been exceedingly difficult

On that last note I should point out that people see social networking as one of the key elements of Web 2.0. But if you look at practically any Web 2.0 site you'll find that it specialises in one area and one area alone. If you look at a Wiki, it's specialisation is in being a wiki - but the wiki is getting so important for organisations worldwide that customers want lots more things to be merged in to it.

When you have an interface that's specialised in one area, it's very easy to add functionality relating to that one specialist area because that's what it's designed for.

When you start adding in very different use cases you find that the interface isn't suited for them. You can't just flip over to a completely different interface tailored to the new "purpose" because that causes problems with the existing functionality. You have to find some way to make it all fit together both visually and also in terms of navigation and user interaction.

Anyway, that's enough for now. My brain hurts just trying to explain this stuff using words, hopefully by the time the plugin is released you'll be able to see a real-life working example on our website which will hopefully illustrate some of what I've described above.

A seagull in Scotland has developed the habit of stealing crisps from a neighbourhood shop.

The seagull waits until the shopkeeper isn't looking, and then walks into the store and grabs a snack-size bag of cheese Doritos.

Once outside, the bag gets ripped open and shared by other birds.

The seagull's shoplifting started early this month when he first swooped into the store in Aberdeen, Scotland, and helped himself to a bag of crisps. Since then, he's become a regular. He always takes the same type of crisps .

Customers have begun paying for the seagull's stolen bags of chips because they think it's so funny.

I've just been having a heated discussion with a client where the term "javascript zoo" was born.

The argument constructive discussion arose over an issue with a plugin they are developing (based on our rate plugin).

A JavaScript zoo

I suggested using the awesome jQuery plugin instead of dealing with issues regarding the prototype plugin (see later).

The client said this would be a "zoo of javascripts" with multiple versions of multiple libraries.

In some respects it would, which is why I think all the other animals should be killed and fed to jQuery.

Note: The client also has Dojo, Dijit and a herd of custom JS scripts in their widgets so adding jQuery would be barely noticable heh.

The real "zoo" is prototype (and any other non-namespaced, bloaty library)...

Prototype is the Zoo!

The client wanted to use Prototype 1.5.1.1. Unfortunately Confluence for some reason is using version 1.4.0_pre11 - that's like an ancient preview release of 1.4. (Why oh why don't Atlassian upgrade this? Rargh!)

As I mentioned in my recent blog post about JavaScript Frameworks, prototype is a very messy library.

First, it inflicts it's horror on every single javascript object. This means that whether I want to use prototype or not, every JS object is now infested with methods and properties that aren't part of the ECMA 262 specification. I'm no longer working with JavaScript, I'm working with a prototype-infested scriptmare.

In something like Confluence there are lots of different developers, plugin authors, etc., who all need to send their stuff to the browser. They are all forced to live with the mess that prototype creates. The temptation to start using prototype, therefore, is high - it's caused you pain by messing up your iterators and other stuff, you might as well try and take advantage of some of the mess it offers. Now you start getting all sorts of functionality - both native to Confluence and third party plugins, etc., being assimilated by the prototype virus of doom.

Also, because prototype isn't namespaced you run in to some painful problems when you try and include two versions of it at the same time. You end up overwriting some, but not all, of the old methods, objects, etc. Anything that accommodated bugs in the old version will now break as the new version won't have those bugs (or have new bugs). There's no way for me to say: actually, my code needs the latest version but I want the old version as well for compatibility with other peoples' code.

To make matters worse, we found that prototype 1.4.x is included twice in Confluence - once in labels-javascript and once as a dependency of script.aculo.us. Now the clients' adding in a third copy (albeit 1.5.1.1) so to view a single page you now have to load painful prototype death 3 times! And it all gets mingled together causing untold problems.

Adaptavist don't use it

The client was very surprised to see that Adaptavist's rate plugin doesn't use the "excellent prototype library which is a very good solution". Heh.

Yeah, and with good reason.

First off, we avoid being overly reliant on what Confluence delivers to the browser. We never know when Atlassian will make changes to their HTML, JS or CSS so generally we avoid it like the plague. This is why Theme Builder and our other plugins generally survive Confluence upgrades.

Second, we don't want to spread the prototype virus of doom. If our plugins used it, then we'd just be another reason never to remove it.

Adding jQuery to the zoo!

By default, jQuery is not enabled in Theme Builder 3 - we don't want people downloading yet another JS library unless it's actually getting used. A simple switch in the layout manager turns it on (and related switches allow you to also include some hand-picked jQuery plugins) - all on a layout by layout basis so it doesn't have to be used throughout the entire site, you could just apply it to a single page if desired.

Anyway, the client found it odd that we would prefer to use jQuery over prototype, considering several versions of prototype are already being loaded

We'd prefer to use jQuery because it's namespaced. It doesn't inflict itself on everything else. If we ever had a scenario where we needed multiple versions of jQuery, it would be really easy to do.

Also, jQuery doesn't try to do too much. A lot of people don't appreciate how important this is.

jQuery is aimed at being picked up and used whenever it makes sense to do so, but then doesn't get in the way when you don't want to use it. It's not sitting around on all the JS objects just in case it's needed. It's tucked away inside a very well behaved namespace.

Anyway, just needed to vent my spleen. Back to coding...

Our up-stream email provider is receiving 8 million emails a minute. Their servers currently contain 25 terrabytes of email.

If our emails seem to be taking a while to get to you, this is why.

80% of the 8 million email messages each minute are spam.

We've also had a sharp increase in the number of emails being bounced due to customers having full or badly configured email accounts.

If you want to get in touch with us, please use our secure online tracker.

We're now looking to bring email hosting in house or maybe shift to another provider. However this is a big logistical change and it's going to take a fair bit of planning and time to implement.

Well, 2.6 was just released but this does highlight a really big problem for us.

Like all developers, we got access to Confluence 2.6-dr1 some time ago on the Early Access Program (EAP) so that we could start testing with it.

This is useful because it allows us to see some of the glaring bugs well in advance and get working on them. But as it's not the final release, things will change.

So, we do some testing, find some bugs, report them.

We then see rc2 and rc3 appearing on http://confluence.atlassian.com, however we don't get access to them. So if bugs are being fixed, and things getting changed as a result, we have no way to test.

Next thing we know, 2.6 is formally released. We didn't get any advanced warning of this, even though we'd been asking regularly to get hold of rc2 and rc3. It just suddenly appears in public as the final release and clients get it at the same time as we developers get it. As a partner of Atlassian, we know nothing more than you do about the release date.

The problem here is that we now have to start our testing all over again. We've no idea what changed from rc1 to the formal release of 2.6.

But clients will already be upgrading. So mid way through our testing, before we've been able to check everything for compatibility, we'll start getting bug reports "hey, I've upgraded and XYZ has broken". So now, as well as trying to find and fix any bugs, we also have increased support load.

The thing is, our clients will assume this is down to us being crap. But there's simply no way we can test on the final version if Atlassian don't let us have it prior to release.

Because this happens every time there is a new Confluence release (admittedly most don't even have a EAP) it's impossible for us to align our plugins and services to each new release of Confluence.

It's been discussed with Atlassian quite a few times, but is obvious the message isn't being received. So I'm posting here, quite bluntly, for everyone to see.

We try hard, but when the supplier makes it impossible for us to test against new releases of their products before them becoming publicly available there is very little we can do.

Don't get me wrong, the EAP is very useful. But the final release candidate needs to go in the EAP, with at least a week or two to test it, before being released publicly.

You will be finding bugs when you upgrade to Confluence 2.6. We're working on them already but, like you, we've only just got hold of 2.6 final release. You'll just have to wait for the fixes. Sorry.

My recommendation: Wait for Confluence 2.6.1 before upgrading. You'll encounter less bugs in third party plugins because the developers will have been able to test them.

If you're adding me to Skype, please make sure you use "guy.fraser" (as selected below) and not "greatolaf" LOL:

This little IM conversation impressed me - a Client was doing some heavy testing on one of their servers (new plugins and stuff) and inadvertently crashed it...

(16:33:29) Guy Fraser: *********.com - site has crashed after trying to export a page as pdf - got ******* on the phone

(16:33:35) Guy Fraser: apparently she can't ping it

(16:33:45) Dan Hardiker: logging in

(16:34:15) Dan Hardiker: conf is still running, not doing much

(16:34:41) Guy Fraser: she can't access it :s or even ping it - maybe it's something on their network changed preventing them access to that ip?

(16:34:52) Dan Hardiker: looking at the logs

(16:35:15) Dan Hardiker: java.lang.OutOfMemoryError: PermGen space

(16:35:16) Guy Fraser: she was exporting to pdf when it chimped

(16:35:22) Dan Hardiker: to be expected with lots of reloading of plugins

(16:35:27) Guy Fraser: yup

(16:40:58) Dan Hardiker: increase perm gen and its on its way up

(16:41:00) Dan Hardiker: its now 256

(16:44:10) Dan Hardiker: *** (********) is back up and running

That's why our Confluence Support and Remote Hosting services are sold out! Within 30 seconds of the client phoning our SLA (Service Level Agreement) support desk, Dan was logging in and within 10 minutes the fault was diagnosed, resolved and the server back up and running.

Admittedly, it was a simple fault to fix, but starting diagnosis within 15 seconds of the client calling is why our SLA clients love us

Note: This sort of speedy resolution is obviously only possible if we have remote access to the server - without that we have to start asking questions, wait for the client to check things and answer, etc. It takes much longer (sometimes days) if we don't have remote access to the server.

And yes, "chimped" is a technical term here at Adaptavist