Guy's Blog Blog from April, 2008

I'm sat waiting for Microsoft Visual Web Developer 2008 to download so I can do some decent, hopefully, debugging in MSIE, so it's blog time...

I was going to wait until April 2nd to post this, but due to MS VWD taking an age to install and me being really exhausted (can't stay up after midnight as I'm just too tired) I thought I'd post now. This is probably going to be a ramble, but what the heck...

Licensing

I'm coming to loathe the licensing module in our plugins. It's something we needed to do for a long time, but man alive, has it been painful!

Since Theme Builder was first launched, way back in the 4th month of Adaptavist, we've gone from paper invoicing and using MS Word documents, to having the online PayPal cart and a custom built invoicing system for accepting payments via practically every possible method from around the world.

The net result is that we have hundreds (if not thousands, I lose track) of customers that purchased Theme Builder before we put the licensing module in. We've had to centralise all the accounts data - which resulted in us having to build a custom accounts system first and then write a new version of our internal control panel software, followed by literally weeks of wading through databases checking over details, just to get to the point where we can start properly creating license keys in a consistent manner.

We've run in to all kinds of problems along the way - in particular tying old bank transactions and old paper invoices together. In the early days, paper made sense - we only had a few customers, but within a few months of Theme Builder going on sale we had customers in 37 countries and if you read my blog you'll know what effect that had on all our internal systems - they crumbled under the logistics of rapid growth.

So, we started by getting a list of all the Theme Builder licenses from all the different sources in to one place. We then realised we needed a way to link the data to actual payments as well as the actual license details being sent out - this was no trivial task.

I don't know about elsewhere in the world, but here in the UK all the financial systems are firmly stuck in the dark ages. For example, we tried several of the leading accounts packages and none of them had a usable API and none could handle multiple currencies and PayPal.

So, we started developing an accounts package that would suit our needs. What started out as a 2 week project has so far taken over 2 months - the system is turning out far better than we imagined, but it's taken a heck of a long time.

We decided to use Ruby on Rails as a Java based system of that complexity wouldn't even be out of the design phase by now. It's amazing how quickly you can develop apps in RoR, the main time creep has come from us realising just how complex our accounts are.

We've had to build in lots of validation routines, reports and all kinds of other stuff that are all able to handle multiple transactions for multiple cost centers spread across multiple bank accounts and currencies, etc. Pain, lots of pain, but we're getting there.

So, with accounts system in place (well, it's still being worked on but the hard stuff is done) and a veritable herd of people working on the data in it on an ongoing basis, our attentions started to turn to the actual license key generation and the ability for the plugins to do the right thing based on the license key installed.

We decided that rather than issue free license keys (for personal, community, non-profit, developer, evaluation, etc) we'd just make the plugin run in free mode when it's installed on to a Confluence instance that has a free license of some type. That part was relatively easy.

We've had to spend a lot of time on the UI of the license details screen in the plugins (the licensing code is also in Community Bubbles which we've quietly released) to make sure that it's easy to read and understand. We're still making tweaks to that screen even now.

In the plugin we've had to deal with all kinds of license scenarios. For example, you can't upgrade to a version of the plugin that was released after your maintenance period expired. There are certain types of license that prevent use of the plugin after expiry (eg. an evaluation) and other types that continue to run after expiry (eg. commercial licenses). We're still fine-tuning that aspect of the plugin. Then there's the checking that the license in use is sufficient for the Confluence installation it's installed on.

Anyway, with all that done, we then come to the license key generation. We ran in to several nightmares with this aspect of the system...

Because accounts systems are generally designed for accountants and not the rest of the business, we had to find some way of linking payments to licenses that had been sent out. This initially involved putting our list of existing licenses in to a new database and then linking to the usernames on our website associated with the license keys. However, that's no easy task as many licenses were purchased before we moved our support and tracking over to JIRA - we used a product called Kayako eSupport but it utterly crumbled under load and was completely separate to the rest of our Crowd-linked architecture.

So... We've had to manually retrace all the license keys that were sent out and try and link them to payments and invoices, etc. Utter nightmare. If we'd known our company was going to be successful from the outset, we'd have done things very differently, but alas, we had no idea that we were going to grow so quickly.

We also ran in to issues with clustered licenses - for example, you could purchase an initial license key, then upgrade your Confluence install to a cluster thus require a new "node" license key, then add another node, etc. You end up with licenses and bits of licenses spread throughout the year making things utterly confusing, not to mention that Confluence has separate licenses for an Enterprise Node and an Unlimited Node which we'd originally mirrored in our licensing model. Due to the chaos this caused, we decided to simplify our clustered licensing and just have a single "Cluster" license that will work on any Confluence cluster regardless of number of nodes.

We were hoping to launch the new license generator yesterday, but then we ran in to yet more problems. We'd overlooked one small but vital aspect of the way things can be purchased - a single payment can be used to buy both a new Theme Builder license and also a Maintenance Extension for it - effectively making the maintenance period 24 months instead of 12.

This means that the system now has to not only keep track of how many months maintenance a license has, it also needs to be clever enough to work out when a single payment includes both the license and a maintenance extension :o

So, we've now got a custom-built accounts database, a custom built license database (used as a staging area) and have had to write a custom license key generator (we used AppFuse for this as it needed to be in Java and linked to Crowd for SSO). Hopefully by next Monday we'll be up an running with the new systems and things can start getting back to normal (and Dan, Paul, Emma and others can start doing something other than wading through databases all day).

If you're planning on adding licensing to your plugins, do it from the outset!

Debugging

To useful bits of info if you need to debug in Safari or MSIE:

• Debugging in Safari
• Debugging in MSIE... for free!

We've grown!

I'm delighted to announce that Adaptavist has doubled in size of the past few weeks (literally). We've taken new staff on in support, development, accounts, documentation and design and will likely be taking more staff on later in the year if things pan out the way we expect them to.

The new recruits are already helping to ease some bottlenecks that had been causing trouble over the past few months. As a start-up we can't afford to take on the wrong people so we had to do a fair bit of hunting to find people who were "on the ball" and fit in to our company culture.

Anyway, VWD has finally finished installing so I'm off to do some debugging before midnight (which isn't so far away...)

One of the unforeseen benefits of doubling our company size recently is that the new recruits bring with them many hidden skills... Like being able to provide support in the native language of customers...

Nice one Emma! Although I think my use of emoticons was a pretty inventive way of getting the "Don't use Confluence 2.6 as it's horribly broken" message across...

Looking through our staff records it seems we can now do native language support (albeit with varying degrees of fluency) in the following languages:

• English (obviously)
• Urdu (fluent)
• Welsh (fluent, and no doubt with lots of swearing!)
• German (almost Fluent)
• French (basic)
• Spanish (basic)

I believe we'll soon have someone starting who can speak fluent Chinese, and almost fluent Cantonese and Mandarin.

We've got that whole diversity thang goin' on!

I think I've just found Windows' killer app - Digsby - which is IM + Social Network + Email all rolled in to one (slightly bloated) app...

If you've not seen Digsby before, go check out their site...

It's not quite as reliable as some of the other IM's I've used, but it has one absolute killer feature I've never seen in anything else - the ability to reply to IM messages in the notification pop-up:

I'd never have imagined that such a simple feature would change the way I interact with IM, hopefully one day all IM notifications will provide this feature - if Adium implements this I will be much happier to transition to my Mac Mini.

As a growing company, our wiki is starting to really pull its weight and facilitate collaboration - here's some things I've noticed recently...

Forums

Add forums to your wiki - whether they are in a staff intranet, customer extranet or public parts of the wiki, they encourage collaboration on a whole new level.

Some of our new recruits ([~sodonovan] and Emma Rush) have started a "Help! Newbie Questions" forum in our staff intranet - an excellent idea!

It's going to quickly become a key resource for new staff members, getting them used to the wiki from their very first day at Adaptavist.

The topics cover things that more established members of staff would never think about - eg. "How should we answer support tickets in JIRA" or "What skills to staff have", etc.

It's a perfect example of people taking over part of the wiki for their own needs and by the very nature of questions asked it also pulls in more experienced members of staff to answer them - instant collaboration between new and existing members of staff, awesome!

If you've not got a "newbie questions" forum in your staff intranet, ask your next recruit to set one up, it's a superb resource!

Targeted Spaces

When we first started using a wiki for our website, everything was in one space. We then added a private space for our staff intranet and a public space for our user guides, however over the years we've realised the value of having a space for each distinct thing - be it a public space for a product or service, extranet's for customer projects, or staff intranets for various departments, it really helps, and here's why...

If you have too few spaces, it's difficult to find stuff - you end up with a completely random mixture of stuff thrown in to one place.

By having dedicated spaces for various things, you instantly say "this is where everything relating to X lives" and people interested in whatever "X" is congregate there which in turn facilitates discussions and collaboration.

We've recently been reorganising our entire site this way (apologies for any navigation issues caused, we'll have those sorted our pretty soon!) and it's already working like a charm.

Intranet Spaces

Any space with "Intranet" in it's title is staff only - to be seen only by Adaptavist staff. Knowing that only Adaptavist staff can see and contribute to the space, discussions can be far more frank/blunt, fun, etc., making such spaces super productive.

Examples of our intranet spaces:

• Marketing Intranet
• Accounts Intranet
• Staff Intranet
• Developer Intranet

Each intranet becomes the hub of activity for that area of the business - it means that if I'm interested in one area of the business (ok, I'm the boss so I'm interested in them all!) then you can watch it's space and get a constant feed of activity for that area of the business.

When we used to just have one intranet space, you'd get all kinds of email notifications about things that you often weren't interested in.

It should be noted that not all staff have access to all intranet spaces - some spaces contain confidential information and are restricted to specific people that need to work with that information.

By setting up user groups in Confluence (or in our case, Atlassian's Crowd software) it becomes easier to manage access rights throughout the site.

Extranet Spaces

Any space with "Extranet" in it's title indicates that although the space is not publicly accessible, specific people outside Adaptavist are able to access it.

There are generally four types of extranet in use by Adaptavist:

• Specific customer projects - a wiki space is a great way to collaborate on larger projects, but it's always accompanied by tickets in JIRA (again, sometimes in a client or project specific area) to keep track of deliverables and issues.
• Resellers and partners - or competitors in any other industry! Adaptavist has a long history of working closely with "competitors" and we often share code and ideas with them and regularly direct customers to them if we think they can fulfil the customers' needs better than we can.
• "Run Books" - this is a fairly recent development and probably merits a blog post in it's own right. A run book is basically a set of procedures usually specific to one project or system.
• Company planning - Adaptavist are increasingly collaborating with industry professionals with a view to making our business better and planning for the future and these spaces make it far easier to collaborate whilst retaining information.

We've realised that customer extranets are an excellent way to collaborate on larger documents - such as legal contracts and technical specifications. Because Confluence tracks changes, and allows deletions and insertions to be marked up within content, we can easily keep track of changes and updates.

Company planning extranets have shown us just how useful a wiki is at capturing tacit knowledge - for example, we'll be discussing things with our lawyer or business advisor in a forum within the extranet and they'll mention things that we would never have thought of. Such things are instantly captured so we can see how business decisions or clauses in contracts were arrived at, and because of email notifications that knowledge is automatically distributed out to other members of staff.

Public Spaces

As I mentioned earlier, we're creating a space for every single product and service that our company offers. The best example to date is our Theme Builder community which is an absolute hive of activity.

By having tabbed navigation down the side, it makes it easy for people to find the section of the space they are interested in, be it forums, tutorials, support, documentation, etc.

When you search in a community space, the search is automatically restricted to that space by default (you can easily widen the search using the options on the search results page) so you're more likely to find what it is you're looking for.

As more and more of our Theme Builder customers (and there are lots!) find out about that space, the community surrounding the product grows and becomes more active.

The forums are already proving to be a success - if we answer a common question in the forums, it instantly reduces the workload of our support staff (which is everyone in the company) because future support tickets can just be directed to a URL. Because our support system is secured, you can't search for solutions in tickets created by other people or organisations - our forum enables useful information like that to be brought out in to the public where it can be searched and commented on by anyone.

Recently, we've even had customers providing additional documentation - for a long time we'd been wondering how to depict all 800+ icons that come with Theme Builder until suddenly a customer uploaded a ready made solution

At Adaptavist, we perceive staff value by the contributions they make to the business. Because we all work from home, from locations all over the UK, visibility of online presence is vital...

I can't remember whether it was Stewart Mader (from Atlassian / Wiki Paterns) or Peter Reiser (from Sun Microsystems), but recently I read an article that indicated some staff feel that they are "losing power" by publishing their knowledge for other staff to see - they feel that if all their "secret" knowledge becomes easily accessible by others, they'll become expendable and may lose their job.

Organisations that have started using wikis or other forms of collaboration already know this to be the complete opposite of the truth - if a company had to lay off workers, they'd lay off the people that have not made a visible contribution to the company, the people who try not to get noticed. Staff who regularly share knowledge become more widely known within the organisation and thus their status as a guru within the company increases and their jobs are more secure as a result. They're also more likely to be asked to participate in prestigious projects and are often seen as thought leaders or experts within their area of the business.

In an online distributed company like Adaptavist, this is especially true - if a member of staff isn't contributing to some online resource they literally aren't doing any work!

Obviously, some staff will contribute more frequently than others depending on job role. For example, Emma is currently doing some screencasts showing how to use Theme Builder - they take a while to develop so it's important that people are aware of that. Regular communications about work in progress therefore becomes important to ensure that other staff know progress is being made.

One of the key benefits of online contributions is they are easy to highlight as examples of "this really impressed us" - like Emma speaking Japanese, Sandra setting up a newbie forum or James adding tutorials. When such contributions are highlighted, it boosts the status of the people involved in those contributions within the company and promotes others to do the same.

Atlassian have FedEx Day, Adaptavist have...

This email conversation with Karen, my wife, reminded me of the early stages of a software project...

Karen: Make sure sausages are ready

Me: What needs doing with them? oven, frying pan, etc?

Karen: CUT UP AND PUT IN FRYING PAN

Me: Do you actually want them frying, or just left ready for when you get home? How do you want them cutting? Does the pan need any oil in, etc?

Karen: OH FOR GODS SAKE GUY SLICE IN HALF NOT OIL IN PAN AND COOK THEM

Now, as you can imagine, Karen is quite irate at all my seemingly stoopid questions, however until I know what the specifications are for the sausage preparation, I can't really do much more. Currently only Karen knows how she wants them preparing and as we've only got a limited window of availability for preparing the sausages I can't afford to get it wrong otherwise they won't meet her rigid specifications and dinner will be a disaster resulting in me sleeping in the spare bedroom.

All software and design projects tend to go through this phase. The customer (usually) knows what they want but they have to specify enough information before the project can proceed - if they don't, we have to start asking seemingly stupid questions to ensure that the project we start working on is actually what the customer wants, otherwise we could end up delivering something that works perfectly as far as we are concerned but isn't remotely close to what the customer was expecting.

Due to experience, we can do a lot of accurate guess work and reduce the number of questions we ask, but the more information the customer can provide up-front (pictures help!) the better as it allows us to quickly get through the fact-finding process and on to production.

Right, I'm off to cut some sausages in half (is that end-to-end or across the middle?) and fry them without oil (but for how long?) so they are ready for Karen getting home (at what time?)... Wish me luck!

Anyone who knows me personally will be aware that I'm on a mission to remove Internet Explorer 6 from the face of the earth - so I'm urging everyone to support "Save the Developers!" and spread the word...

You'll notice a familiar logo on the supporters page

Internet Explorer 6 is so full of bugs that almost every project involving web development has timescales (and therefore costs) increased by around 60% due to developers having to hack the interface to make it work in this most buggy of web browsers.

Although Internet Explorer 7 isn't much better, it's much easier to develop for than IE6 which is terminally broken.

Many large corporates believe that by mandating the use of IE6 within their organisation that they are actually somehow saving money - there's just a few issues with such a disastrous remit:

• It is technically impossible to secure Internet Explorer 6 - how can leaving huge gaping security holes on all your computers possibly be deemed cost effective?
• The rest of the world has long ago moved towards standards compliance - you're now left behind trying to maintain legacy software, which gets increasingly expensive
• Modern browsers are significantly faster than IE6, in particular Opera 9, Safari/Webkit 3 and Firefox 3 to name but a few - does having your staff work more slowly really save you money?

The main reason many large organisations stick to IE6 is because they are scared that their internal web based systems will break on more modern browsers, in particular legacy company intranets developed in FrontPage or, *shudder*, Microsoft Word saved as HTML! Yak!

This is one of many reasons why wikis are becoming increasingly popular - it's time to do away with the old intranets and let the staff take control of them using a wiki. Many thousands of the leading organisations from all sectors have already made this move and drastically improved internal communication and collaboration as a result.

With Microsoft releasing Internet Explorer 8 running in "Standards Mode" by default, the days of IE6 and non-standard HTML are pretty much over. Do you really want to be left in the dark ages while all your competitors move forward at increasingly fast pace?

Just seen this after reading about it on John Resig's twitter...

Take one background image:

Then add 20 lines of JavaScript and native Canvas support in modern browsers (yeah, this won't work in crappy old IE, no surprise there heh) and you get this awesome effect.