wikis.sun.com Is Live - the Engineering Perspective

Hooray! We made it! It's finally out there!



What a week! After weeks of preparation (4 months to be exact) we finally launched wikis.sun.com last Friday, just after going through the screen name drama (that I have to blog about later) and launching a site for my wife's project, The Foreigner's Guide to Living in Slovakia.

Linda and Rama already blogged a bit about the launch here and here, so now it's my turn to blog about Sun Wikis from an engineering perspective.

wikis.sun.com is powered by Confluence, a wiki platform created by Atlassian. Why Confluence and not something else? I hear that question a lot. Well, the decision was made even before I joined the project, but I'm not afraid to say that it was a good decision.

Confluence is a scalable (content-wise via wiki spaces, and performance-wise via clustering) and extensible, feature-rich application, with a strong community. And let's not forget that it's a Java app ;-). Having said that, we certainly do miss some features and we also are bothered with some bugs. But these are things that can be fixed, and we are working hard on our own, as well as in cooperation with Atlassian, to get things fixed and to deliver the missing features.

In the last couple of weeks, our focus was on establishing the right infrastructure for the application, and making sure that the platform is relatively secure and stable. There is still some work to be done in these areas, but I believe that we will soon start to look more and more into delivering the missing features.


So what have we done to Confluence so far:

• Sun.com theme - this is by far the most visible change. Confluence uses Velocity templates for views, and supports creating themes packaged as plugins. So thanks to Greg from our UX team and his CSS skills, the theme was created in almost no time.
• Custom authenticator - I remember days when I needed many different accounts to get into many applications on the .sun.com domain. Fortunately this has changed and these days you can use a unified "Sun Online Account" to get into most of our apps. So a custom authenticator that taught Confluence how to talk to our custom Single SignOn infrastructure was one of the first things I had to develop on this project. It wasn't as easy as I thought it would be. Judging by the poor documentation, it seems that this isn't something that many Confluence customers do. But after a lot of experimentation and hitting a few dead ends, a functional authenticator was created.
• Customization of a few views - "Wikis Home" and "Report an Issue" links, and some other parts of the view needed to be added, removed, or customized.
• Content seeding - we launched the site internally quite some time ago and we called this period the "Wiki Pilot". We got in touch with some great folks who saw this soon-to-be-public wiki as a good opportunity to get their job done. Brian Keith is working on a great Sun Cluster Wiki and Paul Kasper and the BigAdmin team are also getting ready to show off at wikis.sun.com.
• Patching security holes - there were certain issues that we didn't want to have unresolved for our launch, so some last minute patching was necessary.
• Many other small fixes or customizations.

For those of you that want to know all the tiny implementation details, we run Confluence on Sun Java System Webserver 7.0u1 with a MySQL backend. In the dev environment I was able to run Confluence on the latest Glassfish v2 without any problems as well.

Atlassian has a very agile release cycle with minor releases shipping every 2-3 weeks and major releases shipping every 2-3 months. This means that things are getting fixed quickly, which is very good, but it also means that we need to reapply our customizations to the main source code very often. When I realized that we need to make modifications to the core code, and that we also want to stay in sync with Atlassian's release cycle, I started to look for a solution that would make this as easy as possible. I looked at Subversion's vendor branches, but the solution felt clunky. By chance I heard or read somewhere that the SCM system Mercurial (used on OpenSolaris and OpenJDK projects)is very good at managing patches. I dived into reading about Mercurial and it was one of those love-at-first-sight encounters. Mercurial Queues totally blew me away and are saving me huge amounts of time when working on wikis.sun.com.

So what does the final result look like? Here is the compulsory screen shot:


What's next? We certainly don't feel like we are done; quite the opposite is true. Launching wikis.sun.com is just the beginning of our wiki journey, so you can expect things to get even better, and we expect from you to create some great content for all of us to benefit from.

This is the first community-oriented project that I've ever worked on, and I'm doing my best to work with the community on achieving our common goals. Therefore, I'll try to blog often about Sun Wikis, about our progress, new features, and current problems on this blog (entries will be labeled with the SunWikis label). Stay tuned and go participate! :)