The Wikification of Sun Video

Danny Holland created a really awesome video about how publishing at Sun changed from a highly specialized profession accessible to only a few, to a super easy community-oriented model supported by wikis.sun.com



When you are ready, go ahead and create your wiki space or help out in existing wiki spaces. Anyone can now create missing documentation, FAQs, examples, best practices or anything else useful for Sun communities.

Thanks Danny!

SunWikis v1.0.5 released - We've got (a) space for everyone!

Today we released another upgrade to our wikis.sun.com, version 1.0.5.

Besides a few bug fixes and cosmetic changes in the UI, Sun employees are now allowed to create wiki spaces without having to submit requests.

So Sun employees, if you have a great idea that you want to share with a Sun community but were not able to find the right publishing platform, think no more! Creating a wiki space is super easy, just follow these instructions. Keep in mind that wiki is about collaboration. So before creating a space, look if a space for your desired topic already exists. If you find one, help it's creators instead of fragmenting information across multiple spaces.

Non-Sun folks, you can collaborate via comments or request write permission from space administrators.

Wikis and SCM Tools Can Contain Many Hidden "Treasures"

One thing that all the wikis and SCM (Source Code Management) tools have in common is that they keep change revisions (at least they should!). This feature makes it possible to go back in time and see events that happened in the repository even 4 years ago.

While working on some features for wikis.sun.com I stumbled upon an interesting discovery in the Atlassian's Seraph Subversion repository.



Well :), I know that a job in software development can be frustrating at times, and sometimes it is hard to overcome that sudden urge to express exactly what one feels. :-D

This is a good showcase of why the controlled ability to delete revisions in an SCM as well as in wikis is a really important feature.

Imagine that your wiki gets vandalized by a malicious user (or you accidentally publish confidential or private information). You can superficially fix the issue by reverting the page(s) to the last good state, but the vandalized revision will stay with you forever (visible for users willing to dig in the page history as well as to web crawlers and search bots, blindly crawling all links that they find). At least that's how it is in Confluence, which we use for wikis.sun.com. Someone foresaw this issue 3 years ago and created a JIRA issue requesting this feature (CONF-1573). Unfortunately Atlassian never got around to delivering it.

Maybe after today's lesson when forums.atlassian.com got vandalized by users who found a way to hijack forum visitors and send them to their web site, Atlassian will start to appreciate the ability to fully recover from these kinds of incidents. Atlassian?

For those of you who get into trouble with the inability to delete revisions, there is a workaround that is not pretty and requires some sacrifices:

1. Get the wiki markup code of the latest good revision (go to the edit view and copy the contents of the text area)
2. Delete the page
3. Create new page with exactly the same name as the page you just deleted
4. Paste the contents of the clip board into the editor and save the page

There are a few things to watch out for and understand:

• By doing this procedure you'll lose the page history, page level permissions, and most likely also watches that you and other users set for this page
• Make sure you don't accidentally lose content of the clip board between the copy and paste :)
• The name of the page should be exactly the same as the name of the old page, otherwise URL links within the wiki or from external sources will be broken

SunWikis 1.0.4 released - Is the Outage Really Necessary?

We just went through the first upgrade of wikis.sun.com since the launch a week ago.

The main highlight of the 1.0.4 release was the upgrade to Confluence 2.5.6 which contains many critical security fixes. Other than that, we fixed some UI issues that we found in the previous SunWikis release.

You might wonder why did we go offline for a little less then 30 minutes during the upgrade. The answer is that Confluence doesn't support "live" upgrades. As mentioned in the Confluence Cluster Upgrade HowTo, we had to take the site down in order to upgrade safely.

I don't like the idea of having an outage every time we upgrade Confluence. I'll see if we can get Atlassian to help us minimize the down time somehow.

It is usually safe to let nodes with different versions of software touch the same database, supposing that no changes to the data or the db schema happened during the upgrade. This should apply to Confluence as well and it could be the first step in minimizing the down time.

If Atlassian started differentiating between the upgrades that modify the underlaying database and those that don't, and this information would be available in the Confluence release notes, we could minimize the down time from 30minutes every 2-3 weeks down to 30 minutes every 2-3 months.

2-3 months is the usual release cycle for major Confluence versions. Changes to the db schema in such releases are expected, as opposed to minor releases which IMO should change the db only when it is necessary for fixing a high priority bug.

Atlassian has been pretty responsive to our requests so far*, so I hope that we can come up with some solution to this problem as well.

* though I haven't heard from them anything related to the request for Confluence roadmap yet

Is Atlassian (and the Code Base of Confluence) Really That Bad? I don't think so.

Rama in his recent blog entry defended Atlassian against the rough critique posted on the BileBlog. As an engineer working on wikis.sun.com, here is what I have to say about my experience with Atlassian and Confluence.

Confluence Code Quality

Yes, I did spend quite some time playing with things under the hood of Confluence, but I got access to the source code only recently so my opinion might be premature in certain points. This is what I think about the code, based on the portions of codes that I explored so far:

Overall the Java code is easy to read. I can't judge the architecture because I haven't been digging in the code for too long yet, but the bits and pieces that I needed to look at or modify were well formated, easy to read and absorb.

Having said that, I don't understand why I couldn't find one single JavaDoc comment in the source base. Is Atlassian allergic to JavaDocs? It would make my life much easier if things were properly documented in the code. In general the code documentation is lacking or nonexistent. When I needed to write a custom authenticator, it took me much longer to do it than expected, just because the documentation was missing, wasn't detailed enough, or was outdated.

One thing that surprised me a lot was the database schema. I usually try to make the db schema in my applications as tight as possible and I'm not happy unless all the table/column/constraint names follow certain (unified) naming conventions.

The first time I looked into the db after I got my Confluence up and running was "OMG! These people can't even decide on table name conventions". After digging deeper I found other flaws. Just to mention a few:

• when using MySQL, Confluence doesn't create InnoDB tables by default. It happily creates MyISAM tables, unless you configure your db to use InnoDB by default.
• FKs are not used as often as one would expect
• the "users.username" and not "users.id" is used all over the place as a reference to user accounts, which effectively makes username changes next to impossible (Atlassian knows about this problem and promised us to fix it by v2.7)
• lastly - is the db schema documented somewhere at all? I found a messy doc describing JIRA's db schema, but I couldn't find anything similar or better for Confluence.

Atlassian as a Company and its Processes

The things I like about Atlassian is that they are trying to be transparent towards its customers. JIRA where anyone can search existing bugs and submit new reports for all of their products is extremely helpful for everyone in the community. There aren't many commercial projects that practice such an openness. Did I mentioned all the tech and biz blogs that Atlassians have?

The other thing that I appreciate a lot is Atlassian's agile release cycle. We are getting new production builds every 2-3 weeks and these builds usually contain fixes for issues that we recently reported. One thing I miss here though, is some kind of roadmap. I don't need a very detailed roadmap, all I'd like to see is a list of all planned releases for the next 6 months, with approximate dates and key features. This would allow me to plan our releases better.

When it comes to support, in general I had a feeling that it wasn't as responsive as I'd like it to be, but we recently heard that Atlassian's about to expand its support team so I have faith that this will improve shortly. Having said that, I recently tried the live chat support option and it worked great, I got my question answered quickly and that helped me resolve some issues I had.

Atlassian got recently wet from the rain of security issues that we, as well as another customer, reported in the last few days and weeks. It didn't take relatively too long and all the issues were fixed in the recently released version 2.5.6.

I had a conversation with Chris Owen from Atlassian, who assured me that Atlassian is taking proactive measures to weed out all the easy to catch security issues from Confluence. In addition to that Atlassian is planning to make some changes to the process of how security issues are being handled. If he keeps his word and these things become reality then I'll be a happy camper :).

Conclusion

I think that the BileBlog's claims are far fetched and exaggerated (in a nasty way, so typical for him). Atlassian is not perfect, but they are better than the average in many aspects. As long as they listen to their customers and do their best to change things that are being constructively criticized (I read that that's what they like), they'll have my praise.

The Foreigner's Guide to Living in Slovakia - the Website Launch

As if the frenzy related to the wikis.sun.com launch was not enough, my wife and I launched our own project last week as well. A website called "The Foreigner's Guide to Living in Slovakia".

Three years ago my wife Margarete (girlfriend at that time), got an idea to write a book. A book about something that we share passion for. A book about the country that I come from and in which we met and lived for a few years. This country is called Slovakia, and is located in the heart of Europe - Central Europe.

When Margarete moved to Slovakia to live and work there for a year, she found that there weren't many resources in English that could help her to get around. Over the years (yes, she stayed longer than the originally planned one year) she learned and experienced a lot and captured a lot of the hard to find information and insider tips in her book The Foreigner's Guide to Living in Slovakia.

After a lot of hard work, the book recently went to print and now is available for anyone, especially those who are considering moving to Slovakia for a year or two, or just about anyone interested in learning more about what Slovakia is like, what kind of people live there, their history, customs and traditions, as well as tips on how to settle or just get by, should you visit or pass through the country.

To support the book and provide additional information that didn't make it into the already relatively thick (200 pages) book, Margarete and I put together a website with the same name which can be found at www.fgslovakia.com.

The www.fgslovakia.com website contains additional resources as well as a blog focused on anything Slovak, from how to cook some Slovak meals, to how to learn a little bit of Slovak language and use it in common situations.

Margarete seeded the site with some really good content and that's just the beginning. As time goes by, more and more blog entries about Slovak stuff will be added.

If you are interested in Slovakia and Slovak culture, this is definitely a site you want to keep an eye on.

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! :)