Why Use Email

Coding horror has a nice entry on why email is counter-productive. It takes a different view as to why this is so. Rather than assume that it is the need to respond to emails that is the counter-productive part, the entry states that it is the constant need to see if anything new has arrived. The chances of any important information arriving via email are quite slim. You might get one or to useful emails per day. So what is the contents of the other emails that arrive daily that you don't care about? Maybe smaller pieces of information that might be of some significance in the future, but not today. And being interrupted with these irrelevant pieces of information is what is counter-productive.

So how to deal with these irrelevant pieces of information? There are always social networks. Social networks are feature reach and are certainly more than common these days. But I find that even moving these smaller pieces of seemingly irrelevant data to social networks as the delivery medium does not solve the problem entirely. Sure, this would clean up your inbox and thus eliminate the need for you to constantly be checking it. But what about that nagging feeling that you are missing something on your social networks? They do suffer from the same productivity problems as email does. Something else that might be taken into account when considering social networks as a delivery medium for sending simple messages is the fact that they support many more features. These other bells and whistles can be even more distracting than email because email does one thing and one thing only.

Using a wiki for exchanging most types of information, both big and small pieces, often makes more sense. Larger, more static pieces of information can be created as wiki pages. Smaller pieces of information can be created as tickets in project management systems, most of which have wiki support. A threaded dialog can then be created on these tickets. The conversation is than public and persistent. It is also search ready. They key point here being that tickets and wiki pages for that matter, are not limited to a software development context. They are much more general purpose and do not require polling on the recipient's behalf.

Tomboy Wiki

Taking notes is an important activity for any professional that wants to get anything done. Whether you are jotting down notes for a blog entry or highlighting some aspect of a software component under development, using the right tool usually helps. The tomboy notes application is a nice little note-taking utility for Gnome. The power of this application lies in its' simplicity. It doesn't strive to be the next killer work processor disguised as something it isn't. It is designed for taking notes with a few additional features related to note-taking.

The notes that one may create with tomboy notes aren't limited to plain-text. But, keeping with the philosophy of simplicity, this feature set is minimal. You can bold, italicize, highlight, and create lists. Those are the most basic text-formatting features available and are realistically you you could ever need for taking notes. The focus of note-taking is on content, not form, as tomboy notes clearly understands this.

The wiki aspect of tomboy notes comes from its' ability to create links to other notes within the same system. I don't really consider these text links to other notes as part of the text-formatting feature set. It is really part of the wiki feature set and that set length is one. The reason these links have a wiki feel to them is because users have the option to automatically highlight works that are in camel case. Clicking these links will create a new note while retaining the link, just like a wiki.

How Trac Determines The Wiki Processor

Within Trac is a powerful wiki syntax engine that offers a wide array of tools to the author who creates wiki pages. Richly formatted Trac wiki pages can be created in several ways. Just using the default wiki syntax to format plain text is often enough to get started. However, Trac offers much more. There are two other key components to the Trac wiki syntax; processors and macros. Macros invoke specific Python functionality, possibly with supplied parameters, to inject dynamic page content. Processors on the other hand, wrap around a specific chunk of wiki text and manipulate it in controlled ways. For instance, a plain processor would wrap some wiki text in three curly brackets. Doing this would simply transform the wrapped text to pre-formatted output. Wiki page authors can also invoke more exotic processors, such as html or syntax highlighting processors. To use a specific processor, the first line in the curly brackets must specify the processor name. The name of the processor must also be preceded by #!. So, for example, an html processor definition in Trac might look like {{{#!html hello world}}}. So, how does Trac know about these specific types of processors? Under the hood, The WikiProcessor class takes on this responsibility. The key task of this class is to load the required processor rendering functionality. Illustrated below is an elided view of the WikiProcessor class, showing only key attributes.




The logic executed by the WikiProcessor class to determine which processor is to be used in the rendering process takes place in the constructor, which accepts a processor name parameter. First, the constructor will check if the specified processor name is part of the builtin processor set. The builtin processor set in actually hard-coded in the constructor. If the specified processor name is found in this set, the processor attribute of the WikiProcessor instance becomes the method associated with the builtin processor name. If the specified processor isn't a builtin processor, the processor could potentially be a macro. All the macro providers, which contain actual macros, are retrieved from the WikiSystem class and iterated over. Each macro provider is then checked, to see if the specified processor is a macro. If it turns out that the specified processor is a macro, the macro_provider attribute of the WikiProcessor instance becomes the macro provider containing the matching macro. Also, the processor attribute of the WikiProcessor instance will become a method for rendering the macro. Finally, if the specified processor isn't a builtin and isn't a macro, the default rendering functionality is used.

This is an extremely flexible way to determine where the extensible wiki processing functionality resides. The one issue in the WikiProcessor constructor is that there are three if statements, all in the same context with no else. This means that all three if statements are executed no matter what. Not only is this inefficient, but the else adds a grouping aspect to the code. However, this is trivially easy to remedy.