depth-first search

Posted by anton
on Tuesday, December 23, 2008
  • decide to write a blog post
    • play with formatting
      • realize that there is a new version of a blogging tool
        • start upgrading blogging tool in test in vmware instance
          • realize that new vmware server is out
            • upgrade vmware
              • upgrade vmware tools (never easy!)
              • play with new vmware server options
          • realize that the new version of os is out
            • upgrade the os
          • notice that logrotate is not working correctly
            • fix log rotation
          • realize that rsync backups are b0rked
            • attempt to fix them, but fail
          • upgrade db while at it
          • upgrade web server while at it
        • screw around with formatting on the upgraded blog platform
          • fail to get pagination to work (like i fail every single time)
          • fix the theme since upgrade broke it
        • start upgrading prod and realize it does not have enough physical resources
          • consider switching hosting providers
            • really consider switching hosting providers
              • ...
                • ...
                  • ...
                    • ...
                      • no, no, no! there lies madness!
                        • stack overflow!
  • two days later write this blog post

why wiki

Posted by anton
on Monday, September 04, 2006

Over the years I have used various Wiki packages at work and for personal use/freelance. Currently I am using Trac for the freelance stuff, and at work I have tried a number of things, from JSPWiki and Daisy to Confluence. Currently I have been using SnipSnap at work for almost three years, and recently I have installed and configured Trac for our team.

I believe that the biggest benefit of the Wiki is its grass-roots nature, especially when it is being used by a small team on regular basis. I doubt it might ever grow to be "enterprise" in our company for various reasons (even with something like Confluence), but it is indispensable for department- and team-sized work.

Below is a small blog-like post justifying the Wiki for our team.

why wiki

wiki is the simplest possible content management system, collaboratively edited. it works best for creating and evolving documentation. it is not a document storage, but a website where each page is a document.

personally, as i work (do research, jot down ideas, document something), i take notes and evolve these notes using the wiki. i continuously refactor and connect these ideas, thus building content.

most people still do it on their own machines - they edit documents locally, and then they share with others through email and attachments. everyone knows how flawed this is - there are numerous versions floating around, no one knows which one is the latest, keeping track of edits is a nightmare if you have more than two people, finding these documents is hard, etc.

next logical step (which sharepoint took) is to store these documents in a central place. this seems like a good solution on the surface, but it is terribly inconvenient, since these documents are opaque, not being cross-linked together they lack context; in order to view them one must launch an office application, removing the context even further.

with wikis the approach is simpler - my documents are web pages; i edit them in place with simple syntax; i cross-link them easily, thus creating context; they are immediately published and available for others to see and edit. in other words, i build on the foundation that made internet happen using tools that make publishing trivial.

  • immediate tangible benefits are live documents - when i pass around the link to the wiki article, it is often self-describing, pointing to the latest version of the article, so i do not have to worry about people looking at the obsolete version of some word document in some email. as an example, when someone asks me a question, instead of putting the answer into an email, i put it in the wiki, then send them a link to it
  • i can easily see the difference between documents, since they are just text
  • it allows multiple people to easily edit documents simultaneously
  • it also allows me to easily build context - cross-link documents and, in this particular tool (Trac), supply them with tags

the idea is to keep content as open as possible, and its editing as simple as possible, lowering the barrier for entry for participants that can help evolve the content.

to summarize, i will quote ray ozzie once again (from his acm interview on social computing):
I think one of the big promises of all of this technology is to make it easy for people to leave trails of artifacts that can be used later when you don't really expect it.

trac

Trac is a Wiki engine tightly integrated with source control browser and ticketing/issues system that provides a very lightweight (in terms of process) and flexible software project management system. Its main benefit is the ability to put all software project artifacts in context, tying together source code view, changesets, tickets/issues, and documentation.

Trac instance is best scoped per project, thus somewhat limiting its use. With other wiki engines like Confluence, this is not an issue.

Trac architecture allows for a multitude of extensions; it has a vibrant user community, and it has been around for quite a while with a number of high-profile deployments. It is free.

why not sharepoint

sharepoint is a content management system (CMS). for simple "live" documentation described above sharepoint is an overkill - all i want is the simplest possible way to create ad-hoc documents, version them, and pass around simple self-describing references to them (not gargantuan sharepoint urls). i want a simple and easy way to build documentation (or artifacts, in a more general sense) as i work.

in case of documentation sharepoint is somewhat of an inversion of a problem. instead of keeping my existing word documents, what i want to do is create simple documents in place, evolve them, and version them as i work. thus when i browse the site, i want to see content, not opaque document containers. this approach bypasses the office suite, and i can see why microsoft has to be careful not to kill its cash cow by introducing wiki features into sharepoint.

if my needs go beyond simple documentation, sharepoint (especially with infopath) is a tool worth looking into. it makes it very easy to create applications on top of documents, provide workflow, complex user interfaces, etc without any need for coding.

the question really becomes how far you can go with the wiki before you need all the features of sharepoint (or other full-blown CMS). the answer is that for most people a wiki would be perfectly enough; start with the wiki and grow into CMS.

powered by

Posted by anton
on Monday, October 03, 2005

perhaps it is my vanity to blame for having chosen to run the blog software myself; of course this is an opportunity to waste an enormous amount of time tweaking the blog engine and themes, instituting a backup schedule, installing updates, fighting bugs - precisely what I have been doing with typo.

I've chosen typo over wordpress and mt, since I wanted to play with rails (and what blog-aware netizen is not guilty of drinking the kool-aid these days?). obviously it is still very much a beta software - I've spent a few hours trying to install it under www.domainname.com/blog, finally throwing in the towel and resorting to blog.domainname.com setup; the sidebar admin interface is buggy, not remembering the values, or populating them with defaults like "feed" and "null"; same goes for the comment posting interface under IE; not to mention that it is crazy resource pig - fcgi and all, it takes a few seconds to generate a non-cached page (I bet it is something to do with restarting processes and cgi and rails startup slowness in general - but I have not looked at it in details yet). oh and despite their oh-so-smug note, do not use trunk - a flurry of migration commits this weekend was a good lesson.

so now it is just a matter of time - either the newness wears off, pragmatism takes over and I switch to a proven platform, or typo matures enough to be usable.

it is a cute toy, buzzword-compliant, and still shiny and new to justify spending the time playing with it. I should try and track down a bug or two, to make up for all the bile in the paragraphs above.

i am yet to find out what kind of syntax it supports for the posts (it better not be a subset of straight html), useful wiki-like macros, uploading images, etc.

hello world / readme

Posted by anton
on Sunday, October 02, 2005

after about 4+ years of personal blogging, and 3 years of blog-like posts about music, i feel that it is necessary to create a medium for my tech posts, disconnected from my other online personalities.

a lot of the stuff that I want to place here would be notes to myself, resources, quick memory crutches, as well as rants and raves about the stuff I work on at the moment. hopefully this will not deteriorate into the incessant stream of faceless links or obscure one-off notes.

this is the stuff I like, this is the stuff I do as a hobby and for living. this blog is primarily for my own benefit, since writing for me is the best way of exploring a topic; at the same time over the years I realized that others' attention is the strongest motivator for continuing to write. unfortunately this very attention becomes a stifling force over time (at least with personal blogging) - one becomes cautious, aware of the readers' watchful gaze.

job hunting is another selfish motivation - it is so hard to judge someone based on a resume, and hopefully I can be open and confident enough to have this blog serve as a professional representation.

all the usual disclaimers apply - everything here is my opinion only and does not in any way reflect the opinions of any of my employers (past and present).