Skip navigation

Sixty photos sounded like a good, round number for the final photo in this project.

Now I need to figure out what to do for my next photo-related project. Hmm.

We had six show up for last night’s meeting (6/10/09) at Granite City in Clive, IA. It was mostly a social occasion, so there wasn’t a lot of Virtualization content to record. Here are a few points which stood out in my mind:

  • SuperMicro now offers blade servers which integrate a miniature SAS SAN on the back plane. Sounded pretty cool.
  • Josh More discussed some basic security concepts around Internet-accessible servers — Virtual or otherwise.
  • Had an impromptu “Name That Tune” competition between an iPhone and a G1. The iPhone won. This time. . .
  • Laserdisc video is analog, as I pointed out to some peoples’ dismay.

The conversation was, as usual, quite random so there were many, many more topics discussed than I’ve presented here. I guess you’ll just have to attend the next meeting so you don’t miss out!

Sun Tzu’s The Art of War is considered essential reading in many disciplines, but is not typically a requirement for students of Information Technology. I posit, however, that Sun Tzu’s teachings can be applied across many disciplines (I’ll even go as far as to claim any discipline), including IT.

With this series of posts, I intend to pull out key phrases from The Art of War and show how their principles can be applied within various IT disciplines. Not all of Sun Tzu’s wisdom can be directly applied, so I will not be performing a verse-by-verse analysis. There are, however, some sections or verses which should lend themselves to certain IT situations such as building and maintaining infrastructure, security strategies (lots there) and disaster recovery tactics. Here I intend to share with you my IT-focused ideas, as inspired by Sun Tzu.

For this series, I will read through this translation available from Project Gutenberg. All of my section/verse references will refer to that translation. Note that the translator’s notes are included in this version.

As an aside, I highly encourage everyone to explore Project Gutenburg’s catalog of works, as it is the largest repository of public domain e-texts that I know of, and has many classics available to download for free.

Next time: The core of Laying Plans.

Nothing I’ve presented in this series has been particularly earth-shattering. Wikis are just another Web-based tool out there for collecting and presenting information. Wikis are well-suited for some types of data, ill-suited for others, and there is a huge gray space in between.

Some examples of well-suited purposes are:

  • Encyclopedias.
  • Reference manuals.
  • Infrastructure guides or references.
  • Collaborative writing or other creative projects.

Some examples of ill-suited purposes are:

  • Large databases with somewhat static or homogeneous formatted data.
  • Content Management System (though it could work, just not ideal).
  • Web log or blog.

With proper research and some time taken to think about your community and purpose, you may find that a Wiki fits the bill. Just keep in mind that it will become an on-going project requiring a fair amount of care, feeding and community cultivation. Be ready to dedicate the necessary time to get it off the ground.

The main advantage of a Wiki is that it is a free-form database.

The main disadvantage of a Wiki is that it is a free-form database.

Being a free-form database, a Wiki allows contributors to format their pages and create their content almost without limit to form. This is both a good thing and a bad thing at the same time.

Without the constraints of a traditional forms-based database, contributors can build pages which better suit the data which they are trying to present — especially if that data differs slightly from the “standard” presentation. For example, in a structured database that catalogs computing devices in an environment you may have it set up to catalog various types of devices such as printers, workstations and laptops. What happens, however, when you get an influx of new devices which don’t fall under those categories or have additional properties which cannot be captured under one of the existing categories (let’s say, a bunch of new iPhones)? Well, you need to spend some development time to create a brand new form for the new devices which accounts for their special attributes (like an extra field for the iPhone’s GSM SIM card number). In a Wiki, there is no development effort required. Because the Wiki is not constrained with forms and fields, the person entering the data can simply note the relevant attributes directly and immediately.

On the flip side, though, you do need to enforce some semblance of structure or else it will eventually become impossible to locate any data at all — even with a good search function. Extending the example above, consider ten different contributors documenting new devices. If each one places their notes in a different section in the Wiki there will be ten different places to check if you want information on the various devices. Even a good search engine will lead users astray if the information is scattered across the Wiki like this.

The solution is to enforce firm, but flexible style guides for organizing information. The style guides should only go as far as to tell where various types of information should be located within the Wiki and what information should be captured, but they should not dictate exactly how it is presented (unless the volume of information requires it). Templates for new pages can assist with ensuring the rough “outline” of the Wiki stays consistent, but still allow individual contributors to be flexible with how they present data.

Community enforcement of the style guides becomes important, too. You should encourage contributors to edit each others’ work when they notice that something isn’t in quite the right place. If there are any disagreements on where something should be placed, be sure to resolve those as a community so you can all agree to a standard.

Think of the Wiki as a very large reference manual with many writers contributing (because it is, really). When writing papers for college, you typically had to conform to a style guide such as the AP Stylebook or one of the MLA Handbooks. Similarly, professional writers are often issued a style manual particular to the publications or projects to which they will be contributing. Your Wiki style guide does not need to be as formal as those, but it does need to exist in some form or another to prevent (or at least minimize) total chaos.

Next time: Final Thoughts.

This meeting’s theme: Programming

Eclipse IDE presented by Dan Juliano

  • http://www.eclipse.org
  • UI layer runs on top of SWT libraries, so it should be more responsive.
  • Engineered differently than most other IDEs
  • Fairly memory-intensive. Just launched, it took 135 MB of RAM on Dan’s demo system (an Intel Mac).
  • IBM has put a lot of support behind this project.
  • Primarily supports Java development, but there are versions and plugins for other languages.
  • Aptana http://www.aptana.com is an online web dev environment that fits nicely with Eclipse.
  • Good code validation plugin which will validate various languages.
  • Standard IDE stuff like syntax highlighting.
  • Has a large undo feature that remembers every change made since you started the session and can revert to any point. That causes a lot of the memory usage.

Several random discussions took place at this point in the meeting.

Hudson (https://hudson.dev.java.net/) presented by Dan Juliano

  • Billed as an “Extensible continuous integration engine”
  • Tons of plugins.
  • Dan exploring using this for automated scheduled jobs as a replacement for doing the same with cron.

Several members of the group adjourned to Hessen Haus for food and beverages.

So, you’ve picked out a Wiki platrform, successfully beta-tested it with a small group of users and have rolled out your final production version. Unless you are an exceptional individual possessing an encyclopedic volume of knowledge which you can dump into the Wiki, you will need other people to help you.

Building that community, however, could prove to be the most difficult task. In a business environment, it is important to get management to buy in to the idea of building the Wiki, but it is most important to build a base of content contributors. Without that content, the Wiki will have no value at all.

In my experience, I found that the “old guard” was a very large obstacle to implementing a Wiki as a documentation system. Most people, by nature, are averse to change. Change requires them to learn a new way of doing what they already know how to do the old way. At first, they won’t be proficient at the new way so they will be strongly tempted to revert back to the old way. And they did. For quite some time, I felt I was the sole contributor to our Wiki.

It took an influx of new employees before the Wiki really came into its own at our company. These new employees were able to see both the old ways and the Wiki way in action. From that experience they were able to experience the virtues of recording and sharing information through the Wiki. Most of them enthusiastically adopted the Wiki as their preferred method for documenting their activities.

Did that leave the “old guard” behind? Yes, it did. That is a challenge we need to deal with going forward. Hopefully, building a critical mass of usable documentation within the Wiki itself will eventually bring them around. Eventually, they will have little choice left as the old methods become impossible to maintain and others start asking, “Why isn’t this information in the Wiki?”

Next time: The double edges of the Wiki blade.

OpenSourceCMS.com lists nine Open Source Wiki implementations. Three of them are based on ASP and six on PHP. That is by no means a comprehensive list, but OpenSourceCMS hosts live, working demos of each Wiki listed. A more comprehensive list (but without the live demos) is available from Wikipedia (which runs on MediaWiki).

Another technique for identifying which Wiki is best for you, is to think about the goal of your Wiki and look for existing Wikis which have a similar goal. A good way to find existing Wikis is to perform a Google search with the term wiki.

Between the two techniques listed above, you should now have a very short list of candidates. Now is the time to download and install a beta test of each one on your own server. Load it up with data similar to what you that which you will put in your production Wiki. If you can, get some actual users to help with this process and get their input on which Wiki they like best.

After all that, you should have it narrowed down enough to pick your final candidate for a production Wiki. Get it installed and running on your production server, then work on getting that Critical Mass needed to make it a success.

Next time: Building your Wiki community.

My 4:20 Picture Of The Day project is now up to 35 posted photos. With captions. Yay!

There are many well-known examples of Wikis in action. There is, therefore, little argument against Wikis presenting a viable, living document to any size community.

A quick Google search with the simple query wiki returns over 400 Million results as of this writing. Many of the results on the first few pages are long-standing Wiki-based sites.

From gigantic Wikis such as WikiPedia to small personal Wikis, this technology has been adopted and adapted by a wide variety of users. Because most Wikis are (and are built on top of) Free, Open Source Software technologies, they are not going to fade away any time soon.

Next Post: Which Wiki Works for You?