We recently relaunched our website and with that we changed how we manage content on the site. Before, the website code (Java classes, JSP pages, HTML, images, CSS, etc) was checked in to source control and usually one developer (sadly, me) would have to make all kinds of changes. It was a really inefficient process and not sustainable the bigger we grew. We needed a system where non-engineers could edit the pages, see their changes easily and deploy the changes to the site without my help.

First, we use an open source template framework called Sitemesh. This allows our guys to write very basic HTML and not worry about things like the header, footer, sidebar, etc. Sitemesh takes the output of a JSP page (or anything that serves up HTML), parses it then merges it with a template.  You can have any number of templates in the system, all mapped to patterns or various other things. This is a pretty simplified description of Sitemesh -- overall, it's a very powerful and extremely simple framework. As I mentioned, it'll handle anything that produces HTML so it's compatible with PHP, Perl, ASP, etc. We use it in our products to make templating easy and to keep the JSP pages clean.

Next, I created a Subversion hook to do automatic deployments of our content when a check-in is received. (I got the idea for this from an Ars Technica article.) Subversion is our source control and a hook is a way to execute a script based on an event like a check-in, update, etc. Local to the jivesoftware.com machine is a checkout of our site code. From there, the hook script calls an Ant target to deploy the latest JSP/HTML code. I only deploy JSP or HTML in this step and not Java classes or config files. Doing updates to the core source is less frequent and ususally requires a server restart.

Finally, we have a checkout of the site project on our internal file server (Linux + Samba). I also use that checkout as the web root for an internal staging site. Since changes are picked up automatically, our guys can edit the files on the file server then reload the page immediately in their browser. After they make their changes, code is checked in and automatically deployed.

Earlier this week, I attended IBM Partnerworld.  The show was hosted at the beautiful Mandalay Bay hotel in Las Vegas.  Both IBM DeveloperWorks and IBM Partnerworld divisions use our software, so we wanted to attend to show our support.  DeveloperWorks has implemented Jive Forums and PartnerWorld has implemented Spark FastPath (formerly Jive Live Assistant) product to allow partners to contact technical support for server implementations.

The ironic part of the show was that the network on the show floor kept losing connections, and even worse was the performance of the network in the hotel rooms.  Not sure why this happens at conferences. Maybe it's the thousands of attendees clogging the lines.

While the booth traffic was underwhelming (thanks to being blocked by a big map of the show floor), the people who stopped by understood the value of having a good internal community solution.  In addition, when I explained the value of Spark Fastpath and being able to route internal IM questions to the appropriate people, their faces immediately lit up and could see their thought process going on how their organization could use that type of functionality.

Most tradeshows give out bags and reams of paper, but not IBM.  They handed out free cellphones with Windows Mobile technology.  The phone came embedded with a web application allowing the attendee to view their customized schedule (via the web), provide feedback on sessions, and view all the possible activities at the show.  At the end of the show, attendees were able to keep their phone and just drop in a SIM card to use it as their normal cellphone. A paperless conference, how cool is that?

Guy Kawasaki's recent post on naming hit home, where we've been scrambling to come up with new names for the products. Much like naming a new child (which I'm also struggling with right now), every name sounds ridiculous when you repeat it a few times. In our experience, the arc of a brainstorming process leads to the following types of names:

• The practical: Names that aren't the most exciting, but get the point across, like our renaming of Live Assistant (also practical) to Spark Fastpath. We leverage the Sparkbrand and add a literal extension (a "fast path" to the right person or answer).

• The evocative: Names that are more creative, but evoke feelings that you want associated with the product. Wildfirefits into this category -- it fits into fire theme and gets across the feeling of spreading quickly.

• The "Left Field": Some of the coolest brainstorms are have nothing or very little to do with the subject, but happen when people pick up a magazine and point to words like "foghorn" or "gargoyle" (which I just did).

• The "mildly humorous": As the brainstorm reaches its limit, the process gets goofier and people will riff on the fire theme with names like "Two Sticks".

• The Insane: Finally, as the donut sugar crash occurs, the brainstorm fades into oblivion. My favorite names to come out of this process were "Fire Beaver" (Beavers are big in Oregon) and "Purple Unicorn". Some of the Web 2.0 companies might actually start at this part of the process.

[http://www.flickr.com/photos/50884898@N00/110236129/|photo sharing]To celebrate exceeding 2005's growth goals, we all hit the slopes last Friday in what may end up being our First Annual Ski Trip. A quick bus-ride later, everyone geared up and spent the whole day snowboarding, drinking and scarfing buffalo wings. Well, that is, except the Marketing guy who's bum knee stranded him in the clubhouse with the laptop (not to mention a wireless router configured to prohibit HTTPS access...hello!).

Have a look over our ski pics.

!http://jivesoftware.com/blog/wp-content/uploads/2006/03/Spark1.1Logo.gif!A major new release of the free Spark instant messaging client will available this Thursday, Feb. 9. Spark 1.1 introduces a powerful framework for creating plugins (called Sparkplugs). The entire Jive Software engineering team participated in Sparkplug Day to test out the new API and to develop some interesting sample plugins. Highlights include a translation engine, a multi-player Reversi (Othello) game, and enhanced security for file transfers. Check out the full report on Sparkplug Day, which includes screenshots of the plugins.

Other major changes in this release include support for Linux and many improvements to the Mac version. One new feature I'm particularly excited about is enhanced file transfer. Most IM clients get file transfer wrong with confusing UI's and by simply not working reliably behind firewalls. We've worked hard to create file transfer that "just works" and that's a pleasure to use. You can read details about these changes in the enhanced file transfer article.