August 2003 Archives

Moved by the news of the suicide of a regular on the #joiito IRC channel, Elizabeth Lane Lawley shares about coping with depression.:

The depression had come on slowly, insidiously. I hadn’t realized how very deep into it I was until the medication boosted me back out. After I rejoiced in that for a while, though, new fears arose. “What if I need to be on this forever?” That scared me—I didn’t want to be dependent on a drug for my well-being.

She continues…

When someone develops diabetes, or anemia, or high blood pressure, we don’t expect them to “deal with it,” to show enough personal strength to overcome their problems. We don’t see them as weak for turning to medication to deal with their symptoms. I slowly came to see depression in the same light, and it helped me a lot to understand my initial resistance to the medication, and my fear of taking it on an ongoing basis.

Today Meg Hourihan writes:

I usually keep quiet during the myriad technology debates that flood certain web circles, preferring to just do my coding and building of things. So when I do dig into some technology or other – often way after all the geeks have argued and hashed to death some obscure techie implementation tidbit – I'm shocked to discover just how messed up it is. This week's struggle lies with OPML.

Keeping keep quiet during the myriad technology debates is probably very wise and more productive thing to do, but I'm not smart enough to listen.

She continues…

Unfortunately OPML has a DTD that says you can extend OPML anyway you want (which is crazy talk to me, a DTD you can change? What's the point?), meaning you can add more elements, or more attributes to your elements. So when someone (me) tries to implement something with various OPML outputs, you (again me) realize that one tool outputs an attribute url while another outputs htmlUrl and a third htmlurl – all to signify the same thing! Sure, some RegEx can clean this up, but weren't we trying to avoid all that with XML in the first place? Argh! I just want to be able to develop something and have a strong contact defined. Is that too much to ask? No extends XYZ, no I changed this just this is how you express X and that's it. Maybe if the format you're using requires you to change it to represent your data, you're not using the right format in the first place.

Reading Megnut's post pains me as I've experienced exactly what she writes when it comes to OPML. One of my first MovableType plugin attempts was to develop the ability to display OPML blogroll data in an MT layout. Astounded by the lack of a spec or any clear guidance and beguiled by the differing implementations I gave up and never finished it. (I took up the RSS plugin for MT which was and still equally frustrating, but is far more useful and important in concept then OPML or blogrolls.) One Internet standards pundit once refers to it as the ghetto of XML. I have to agree. It's pretty absurd and insane. It is also unnecessarily difficult to develop software for.

It's times like these though, that I feel a bit vindicated when an intelligent and normal person like Meg comes to experience, first hand, something that agitates and bedevils me on a regular basis as a career developer and made me quite very outspoken about. Developers exists for users and not the other way around. Absolutely agree. Technical implementation should be transparent and irrevelant to the user. Absolutely agreed again. What is lost in these idealistic view, is the indirect effect a poorly designed and documented specifications has on the user experience.

(There are a great many shared issues between OPML/blogrolls and RSS 0.9x/2.0. Is it any coincidence that the same genius is behind both?)

As a developer I only have so much time and energy. If I am forced to write and test extensive amount of bozo code to protect users from such messiness spilling over into their experience that means less time for me to implement new features. There is also good chance new and unaccounted for bozo will come along that could make the software that was once working as it should becoming unreliable or simple break.

Here is a small example of what I mean. The mt-rssfeed plugin I wrote and released last year before RSS 2.0. It worked as advertised until the new and unneighborly backwards compatibility hostile <guid isPermalink> was introduced. Thanks to unfunkification of RSS feeds like Mark Pilgrim's and Jason Kottke's my plugin doesn't know how to find the link to insert into MT layouts. (Click here for more of the funky RSS stupidity.)

I admit that my code could have been better and I need to fix it, but I don't have time for what is not a quick fix unfortunately. It doesn't help that such careless and poor design decisions of a specification is behind this breakage.

What's more ridiculous is that these specifications have been declared frozen and unchangeable. We now have to hobble along or suffer through the reinvention of the wheel.

Meg concludes:

Which makes me realize that I think some of the problems we've had in the weblog community around formats like RSS and OPML might stem from the fact that we use them in manners for which they weren't designed.

I don't know if I entirely agree with this assessment. If a specific is designed properly for extensibility – a simple core and the ability to extend it with namespaced modules – it can grow and adapt in a sane and reliable manner. These specifications were not and we see where that has gotten us. The problem is only compounded by a specification being frozen to address new common uses and shortcomings in its predecessors. Unlike meat, freezing a specification doesn't mean it will resist rot and decay.

We need to come up with better ideas and formats that work and can handle change and adaption. That is my rant for another day though.

Preface: This is another of the hacks that I had contributed to the O'Reilly Blog Hacks projects until it was pulled from production. An addendum has been added to update the piece.

One of the major aspects to Movable Type's smart system design is that its content is rendered when created or modified to static files. It makes a great deal of sense when you consider weblog content is created often, but is infrequently updated or modified other then the index or archives. Static files can be served much faster and with less system resources then dynamic content. Even index files and archive indices may only change once every couple of hours on the busiest weblog.

Static rendering of content is generally good in maximizing response times and getting the most out of your server's resources however, there is a catch if you want to incorporate some content that updates frequently such as an RSS feed. MT only renders content when manually told to do so by an author using their browser. In the case of an RSS feed, links would not appear in your MT weblog until you make another entry or decide to execute a rebuild. Content is likely to shown long after its been published or perhaps could be skipped over entirely if a feed is active enough.

Using Movable Type's Object-Oriented Perl API I developed a hack to rebuild templates, or even your whole weblog, on a regularly scheduled automatic basis using Unix's cron utility.

I've package up this functionality into a script, dubbed mt-rebuild, that is available under the Artistic license here.

The script comes with embedded documentation that covers the full range of features and options, but we'll cover a few of its most common uses below. Before we do that, you will need to know the ID of the weblog you want to automatically rebuild.

In these examples, I use a weblog with a system ID of 0, which is only for demonstration purposes. A weblog cannot have an ID of 0 in MT. It's likely that the ID of your weblog would be 2 or higher as MT creates a sample weblog with an ID of 1 at installation. Most users delete this weblog. To determine the ID of your weblog, log into the MT CMS tool, click Manage Weblog and look at your browsers URL for a string like blog_id=(some number). That number is this weblog's ID.

Now that we have that covered, lets look at a few common uses of mt-rebuild.

To rebuild an entire weblog use a directive like this:


mt-rebuild.pl -mode="all" -blog_id=0

Rebuilding an entire weblog is system intensive especially if your weblog is of any size. One way to trim back the amount of processing is to selectively rebuild a specific archive, index or entry. Let's say we want to just rebuild the Category archives in order to refresh some content that is included in that template. We'd use the following directive:


mt-rebuild.pl -mode="archive" -blog_id=0 -archive_type="Category"

Note that the archive_type must be one of the following values and is case sensitive: Individual, Daily, Weekly, Monthly, Category.

If you wanted to rebuild a specific Movable Type index template, say your main index page, you could do that with the following:


mt-rebuild.pl -mode="index" -blog_id="0" -template="Main Index"

Like the archive_type argument in the example above, the template name is case sensitive.

The script also allows for you to rebuild a specific entry and apply other advanced options. See the embedded documentation in mt-rebuild for more details.

If you have content that appears through out your site and is constantly updated, you should consider placing that piece in a separate index template and use a little bit of server side scripting technology such as XSSI or PHP to include the content generated from that template. While the advantage of static rendering is lost, the impact of this type of dynamic rendering is marginal. The big savings is that it only requires you to regularly rebuild one file and not your entire weblog.

Addendum

Since this piece was first written a new version of mt-rebuild (v 0.2) has been released. With this new version all weblogs in the system can be rebuilt with this directive:


mt-rebuild.pl -all

This is a very resource intensive operation that, depending on the number and size of the weblogs on your system, could take a long time to fully run. However, if you are managing multiple weblogs that share content or templates, this new option can save you a lot of hassle of rebuilding each individually.

Via Anil Dash. Tanya Rabourn (aka pixelcharmer) has posted an interesting and creative way in which she organizes her weblog using faceted categorization to achieve a simple hierarchical relationships between posts. (Hierarchical relationships is currently not supported in MT.) She details how she does it concluding This is additional evidence to back up my observation that most problems in life can be solved with the creative use of regular expressions.

I agree, but regular expressions inside of Movable Type templates make me cry though.

I've developed a proper MT plugin as a more elegant alternative. mt-categoryfaceted can be downloaded through my mt-plugins page.

If you can grok regular expressions then with a little extra effort you can create develop your very own plugin. It only takes a read of my Developing Movable Type Plug-ins article, some cut and paste and a wee bit of extra perl knowledge to achieve. The end result is that your solution is easy to update if you find a bug or want to add a feature and it's easily shared with others.

To demonstrate I'll take this opportunity to walk through the code of this plugin and show how I ported Tanya's solution into a plugin. I purposefully wrote this code in longhand so it's easier to read and to promote best practices.


package MT::Plugin::CategoryFaceted;

This line helps avoid any conflicts with other installed plugins. CategoryFaceted would be replaced with the name of your plugin.


use MT::Template::Context;

Load the MT module that houses all of the template tag functionality. This is all that it needed for a simple template tag plugin.


use vars qw( $VERSION );
$VERSION = '0.02';

Makes the version discoverable by other perl programs and modules. Not necessary, but a practice I recommend plugin developers do.


MT::Template::Context->add_global_filter(faceted => \&faceted );
MT::Template::Context->add_conditional_tag(CategoryIfFaceted => \&if_facet ); 

This is where the meat of a plugin starts. In these two lines we let MT know about the tags we are implementing and associate them to subroutines found later in the code. In the first, I'm registering a global filter named faceted and associating it (through a reference that the prepended \ provides) to the faceted subroutine. In the second, I'm registering a conditional tag CategoryIfFaceted (MT is assumed by the system) and associating it to the if_facet sub routine.


sub facet_split {
	my $label = shift;
	$label=~m/^([^:]+):\s+(.*)$/;
	return $1, $2;
}

Perhaps I was being a bit anal rententive here, but I create a utility subroutine so me the regular expression resides in one place and can be shared by all other subroutines. Unlike the pixelcharmer implementation, I don't get explicit about what facet I'm looking for in my regular expression. This adds flexibility to use facets other then PMEST and supports other languages.

In the first line I declare my subroutine and open it. In the second line I assign the first parameter passed into the routine to the variable label. (my causes $label to only be recognized inside of the subroutine.) In the third line we do our regular expression match. (I'll assume you understand your regular expressions already.) In the fourth line I return to values to the whatever called the routine in the first place. The variables $1 and $2 are system variables the hold the matching content of the first and second set of parenthesis (respectively) in the matching regular expression. In the last line we close the subroutine with a curly bracket.


sub faceted { 
	my ($text, $arg_value, $ctx) = @_;
	return $text unless ($arg_value);
	my ($facet, $label) = facet_split($text)
		if ($ctx->stash('tag')=~m/CategoryLabel|ArchiveCategory/);
	return $label || $text;
}

This routine is what is behind out global filter faceted. The second line we receive three variables that MT passes all global filters. The text (contents) of the tag the global filter is being applied to, the value that the global filter was assigned, and a reference to the context. Context gets a bit deep. To keep it simple lets say it's an object that holds the data MT is working with at the moment.

The third line is more anal rententiveness – if the global filter is called with 0 or is blank, don't do anything and pass back the text untouched. In the fourth line and fifth line (note: it's one command) we pass the text to our utility routine and get back the facet and category label only IF the tag is MTCategoryLabel or MTArchiveCategory. (Why? Because I don't want to have to support for some unattended use I'm not prepared for.) In the next line we return the label or, if the label is null the text we were originally passed. Passing a null value back will generate an error in MT and all processing will stop.


sub if_facet {
	my ($ctx, $args) = @_;
	$ctx->error('MT'.$ctx->stash('tag').' tag outside of the proper context.') 
		unless defined( $ctx->stash('category') ); 
	$ctx->error('facet is a required argument of '.$ctx->stash('tag').'.')
		unless defined( $args->{'facet'} ); 
	my ($facet, $label) = facet_split( $ctx->stash('category')->label );
	return $facet eq $args->{'facet'};
}

Next is the routine that is behind the conditional tag of MTCategoryIfFaceted. Second line we assign the context and any arguments (a hash reference who know what that is) that where declared with the tag from MT assigning them to variables. In the third through sixth lines we do two error checks. The first error check is to make sure the tag is being used within the context of a category. The second error check I make sure an argument of facet has been passed in because I can't continue processing without that. (In my error messages I like to use the tag variable $ctx->stash('tag') instead of just typing out the tag name. This way if I change the name of my tag I don't have to worry about changing it in the error message or potentially confusing a user when they get a message for a tag they aren't using. I also have the flexibility of having one subroutine backing multiple tags if necessary. But I digress.)

In the seventh line, once again, I call the utility method and get back the facet and category as separate values. In the eighth line I use a piece of perl shorthand (sorry I couldn't help myself) where I return the result of the comparison between the value of the facet argument and the facet of the current category being processed. Conditional tags expect either a 0 (false) or 1 (true) response. If they match, then a true (1) valued is return and MT processes the contents of the tag. If they don't match, then a false (0) value is return and MT does not process its contents and strips it form the output.


1;

This just lets perl know that all the code is loaded and properly.

This is a bit more involved then the solution that inspired it, but I think the benefits are worth the extra effort. I encourage any motivated and curious person to give it a try. It may be easier then you think.

UPDATE: Here is an example of the plugins usage. Taken from the synopsis of the embedded POD documentation.


	<MTArchiveCategory faceted="1" />

	<ul><MTCategories>
	<MTCategoryIfFaceted facet="Time">
	<li><MTCategoryLabel faceted="1"></li>
	</MTCategoryIfFaceted>
	<MTCategories></ul>

Preface: This is one of the hacks that I had contributed to the O'Reilly Blog Hacks projects until it was pulled from production. For awhile, I've been meaning to release what I did through my weblog like the legenary Tom Coates did in his. Today I put my foot down and take some action.

Back in November 1997 I read a Webmonkey article by Jeffery Veen entitled Object-Oriented Publishing on the Web. In the article Veen notes that building a Web site should not be redundant activity. Rather then cutting-and-pasting markup, content and links throughout your templates or pages, he suggests that developers think of a sites as chunks of content that can be assembled in various ways to form pages. He goes on to explain that these chunks are compartmentalized elements in your page layouts, such as header, footer, navigation, sidebars, and the page body, are the functional equivalent of objects in object-oriented programming. (He later went on to dedicate an entire chapter to the concept of object-oriented publishing in his book The Art & Science of Web Design and later excerpted in another Webmonkey article.)

Generally speaking, object-oriented techniques eliminate redundant effort, ease maintenance and future modification, increase reuse and improve quality. Object-oriented techniques also better support evolutionary, iterative and incremental development then other means. For those not familiar with object-oriented development theory we will not be able to go into the topic any further. There are dozens of books and scholarly papers written on the topic if you're interested.

Being a programmer that was already familiar with the principles of object-oriented design, the notion of applying them to web publishing resonated with me though I hadn't considered it until I had read Veen's article. Since then I've always tried to apply these object-oriented publishing principles to any website I've built including weblogs.

So how do we apply object-oriented publishing to weblogs? It depends on the tool you are using as to how and to what extent. Here I'll cover how I do it with my weblogging tool of choice, Movable Type. To demonstrate that this notion is adaptable to other environments, I will also walk through another method using Apache's XSSI (Extended Server Side Includes) – the one Veen used to illustrate his principles in the original article. Its one that I've used in the past before the various publishing tools and page generation technologies we have today were readily available. (I've personally adapted these principles to ColdFusion and I'm confident they are applicable to PHP, ASP, JSP and any many others.) While not as elegant, the XSSI method that can be applied to weblogging tools such as Blogger that can write static files that are being served up with the Apache web server. Let's discuss these approaches to object-oriented publishing.

Movable Type (MT) structures your content and keeps it separate from its display via templates. What it lacks in the grand scheme of object-oriented publishing is a facility for applying a global layout template – a single template that can wrap the layout of any other page's content with the common elements (header, footer, navigational links) used throughout.

Ideally you would create a module that is a global layout template with placeholders for various pieces of content to be plugged into. Each template would create the body of content and set other meta data variables before calling in the global layout template to assemble the page. I initially found that there is a catch to doing this in MT though. While MT allows for variables to be set and retrieved in templates using <MTSetVar> and <MTGetVar> tags, it only permits small bits of static text to be stored – not paragraphs with markup and links. It also meant you could not capture the output of a block of MT template code, which is precisely what is needed for inserting the content body into the global layout template.

In trying to work within MT's capabilities initially, I broke my content objects into MT modules and used <MTInclude> tags to call them into each template. While this helped minimize a certain amount of redundancy and provide some reuse, adding a new element or reshuffling the order of objects in the layout still required making the same change multiple times.

With the later introduction of plugins to MT, I was able to create a better and more elegant solution for implementing a global page template and achieving a better object-oriented publishing effect.

I created a very simple container tag plugin, <MTSetVarBlock>. (The mt-setvarblock plugin is freely available under the Artistic License.) This tag is similar to <MTSetVar>, but instead of taking in its value as a tag argument, it stashed the output of what was between its start and end tags. Now any amount of text, markup and, most importantly, MT template tags could be included and its output captured into a variable. The block of content could be retrieved with a <MTGetVar> tag just as you would output a variable set with <MTSetVar>. With this added bit of functionality, I could create a consistent look and feel for my entire weblog with a modicum of template code by reusing the common elements.

First I created a global layout template with the elements that appear throughout the site and frame the various content layouts. You may want to break the various elements into their own separate modules and use <MTInclude> to bring them into the global template. It depends on your situation and personal preference whether you will want to do this. In many cases I have elected not to because these elements where only used solely by the global template.

One word of caution. As Movable Type users know, MT statically renders its content to files. This is generally a very good thing, however there are a few side effects of this feature that my impact the implementation of technique. In order to avoid having to needless rebuild the entire site each time new content (an entry, comment or ping) is published, MT attempts to selectively rebuild files based on tags usage that it has mapped and the template type. MT does not map modules and it does not allow you to directly nest templates. Suppose you want to render a list recent entries and include it in your global page layout. Movable Type will not recognize that all of the templates using the global layout template module needs to be rebuilt. You probably don't want your whole site rebuilt every time you make an entry anyway. In these situations you should generate a file using a standard template, like an index template. Then by including some dynamic scripting code such as XSSI or PHP in your template, include that generated file into the layout.

Here is a simple example of a global layout template module.


<html>
	<head>
		<title><MTGetVar name="title"/></title>
	</head>
	<body>
 	<h2><MTGetVar name="title" /></h2>
		<MTGetVar name="body" />
	</body>
</html>

With the global layout stored as a module, I created my various index and archive templates. Since there was no need repeat all of the elements that was in the global layout, these templates consisted of creating a layout for the body of that specific template and wrapping it in a
<MTSetVarBlock> tagset with a name of body.

I also set variables with information (meta data) that needed to be inserted into the template. While these are optional and will vary based on what you are doing in your global template, I've found them helpful in refining my template by giving me more control on a template-by-template basis. At a minimum, I tend to create and store a variable that contains at least part of the page title. You can have as may or as few as you like. You may also want to set a variable for controlling a conditional statement inside your global layout.

Finally I include the global layout module. MT retrieves the module and processes it, inserting the content where I had placed my markers using <MTGetVar>.

Here is a simple example of a master archive listing of hyperlinked entry titles for a blog in reverse chronological order using the global layout template.


 <MTSetVarBlock name="title"><MTBlogName/>  Archive</MTSetVarBlock>
 <MTSetVarBlock name="body">
 	<MTEntries>
 		<a href="<MTEntryLink/>"><MTEntryTitle/></a><br />
 	</MTEntries>
 </MTSetVarBlock>
 <MTInclude module="Global Layout Template"/>

Rebuild your blog and you have a consistent layout throughout your site with a minimum of template coding necessary. Want to give your weblog a different look? Change the global layout template, save, rebuild all and viola! Your whole weblog has a different look.

As I mentioned earlier, object-oriented publishing is adaptable to other weblog tools. How and to what extent varies. Now we'll look at how you may apply these principles to other weblogging tools using static files and the Apache Web server's XSSI capabilities.

XSSI is a set of built-in commands for (as its name implies) inserting files and doing basic if-else conditionals in addition to setting and output variables. The commands are quite limited and only provide the most rudimentary of functions – they're no loops nor there any type of lists/arrays to work with. Creating extensions or plugins means modifying C code and recompiling the server – not a trivial task though some have made valiant attempts with some success. Despite all of this, a remarkable amount can be done with XSSI including web publishing in an object-oriented style.

Unlike the Movable Type example, XSSI does not have the ability to set variable with a block of content and requires two files and some file naming conventions to achieve. Since its not connected to a database all data must be loaded in variables or individual files. While it's not ideal, it's not so laborious when you have a tool to do all of the hard work. XSSI does allow for your changes to be seen immediate since the pages are assembled dynamically.

Let's look at how XSSI can be applied.

Each piece of content would require two smaller files. The first file is the file users will retrieve. It defines the meta data for the content before finally calling the global layout that we'll look at momentarily. Here is a simple example file we'll call foo.shtml.


<!--#set var="title" value="My foo title." -->
<!--#set var="description" value="This is an excerpt of the content that will be inserted." -->
<!--#include file="global_template.shtml" -->

In order to accommodate inserting the body content into the global layout template, we place it into a separate file and give it the same name as its meta data mate and a .body appended. This way we can use the built-in DOCUMENT_URI HTTP server variable in our global template to programmatically make the association between the two content files. So this example file, foo.shtml.body, is just the main body of content – plain text and markup.


<p>This is a simple example to demonstrate body copy being inserted into a template using just Apache XSSI.</p>
<p>These are not the droids we are looking for. Move along. Move along.</p>

You can include XSSI commands in this file if necessary though I wouldn't advise it. Besides you'll have to configure the server to parse files with .body extensions.

The final piece is the global layout where we output (echo) meta data and include the body of content. Here is a sample global layout template in XSSI loosely based on the one used in the Movable Type solution.


<html>
	<head>
		<title><!--#echo var="title" --></title>
		<meta name="description" content="<!--#echo var="description" -->" />
	</head>
	<body>
 	<h2><!--#echo var="title" --></h2>
		<!--#include virtual="${DOCUMENT_URI}.body" -->
	</body>
</html>

That's all. Like I said using XSSI is not as ideal, but with Apache's widespread deployment it provides virtually any tool the can output static files a means of applying an object-oriented style to publishing.

I've been meaning to write about this about this sooner, but I've been so busy helping take action and dealing with the blackout that I haven't found the time till now.

I'm obviously not a woman, but hear me out on this one as it's a matter that has hit quite close to home.

My wife works at Elizabeth Seton Childbearing Center in Manhattan as a Nurse Practitioner. It was started 30 years ago and was the first in the US and is the only out of hosiptal birthcenter of its kind in Manhattan. (It shouldn't be the only one, but it is.)

They are being forced to close September 1st. Their current malpractice insurer refused to renew their policy with weeks left on their policy and the best quote any other would give would be a substantial increase (like 250-300% plus as I understand it), into the millions annually, for 1/6th the coverage they used to have. They simply cannot operate under those terms – they are a small not-for-profit organization with 30% of patients on medicaid that delivers about 400 children annually.

My obvious bias aside, this is rather sad and a great loss to the NYC area community. Historically, ESCbC has provided not just prenatal care, but care to women throughout their life span. The birth center’s philosophy is based on the principle that women have the right to health care that is safe, fits their life-style, and recognizes and respects their individual, physical, social, spiritual, psychological and economic needs. In addition to childbearing the center offers other services that include childbirth education, prenatal support groups, prenatal yoga, massage, acupuncture, post partum support groups, mothers groups, post partum depression support group, baby and toddler play groups, and a Spanish language toddler play group. It is also the home for Childbirth Education Association of Metropolitan New York and Metropolitan Doula Group.

The loss of my wife's job is unfortunate, but a highly trivial matter in the grand scheme of things. We'll be fine. The loss of this resource to women's choice in healthcare is not – especially when it's at the hand of insurance companies and skyrocketing premiums. There are now dozens of women and their partners expecting to deliver children at the birthcenter scrambling. Less then 4 weeks is not enough time to find adequate alternative care for the women who have been counting on birthing at the center.

They aren't going out with a whimper and are organizing various forms of various forms of activism to bring this situation to light while trying to help patients make alternate arrangements. They want to keep these type of healthcare options available to women and their families.

I've helped them setup a weblog to communicate to their patients and the public. (BTW: Kristen Stehle is my wife.) Please link to it, pass the word along to anyone you know in the NYC area that may be interested and encourage them to sign the petition and get involved if they can.

My wife and I amongst many others would appreciate it.

Like many in the NYC area we lost power (twice) yesterday afternoon and into the evening. We're still trying to clean up from the unexpected kink it put into life. (Living in a large apartment complex we lost water also. We had what looked like watered down iced tea coming out of the tap this morning.) Being in NJ we had power back just after midnight and all seems to have returned to normal. Can't say the same for Manhattan quite yet, but the recovery seems to be on its way.

I have to say looking out my window and across the river to Manhattan last night was the second most surreal thing I've seen from here – the outline of skyscrapers shrouded in darkness against the evening sky. No lights of the Empire State Building, or the illuminated oblesik of 30 Rockefeller Center with its orange neon GE atop it or the orb-like glow of Times Square's lights. Just the occasional fluorsent lights of ferry boat cabins like on the Hudson and a few lights from building with emergency generators – most of which are downtown around the former site of the World trade Center towers.

I would have taken a picture, but there would be nothing to see – exactly what made it so surreal for me.

Wikis Suck.

| No Comments | No TrackBacks

Well at least large scale active ones do.

Elizabeth Lane Lawley notes a backlash building on wikis citing the activity surrounding the !(echo/atom/pie) project's wiki and a conversation started by Phil Ringnalda. I will add my lessor known name to the list of people who were put off by the use of a wiki and have disengaged from participating.

I think Elizabeth really gets to the root of the issue when she concludes…

>I'm not yet at the point where I see wikis as adding sufficient value to any process I'm involved with to justify the installation, configuration, and learning curve for users necessary to add another tool to my social software arsenal. Like Phil, I continue to be troubled by the inherent ahistoricism built into the wiki environment; like Shelley I find the lack of social cues to tell me if I'm treading on someone's toes by changing content to be inhibiting; like Dare, I find that large-scale active wikis are often too chaotic and disorganized, making it difficult for me to find what I'm looking for. But I'm still willing to be convinced.

Me too. Elizabeth's comment in response to Sam Ruby's post defending his use of the wiki is equally as articulate and well done. Dare Obasanjo and Shelley Powers also have offered their views.

I'm not against wikis, but in the case of the !(echo/atom/pie) project I don't think it was the best or appropriate tool – it's a lot of work for little gain. What gains are made cannot be fully understood since the history and context is lost or as the say in wiki parlance refactored. Large scale active wikis are too chaotic and disorganized. I had time that I was willing to devote to the conversation and did initially – I have a lot to say on the matter. Alas they are absent as I quickly discovered that my time could be better spent elsewhere doing something more meaningful.

About this Archive

This page is an archive of entries from August 2003 listed from newest to oldest.

July 2003 is the previous archive.

September 2003 is the next archive.

Find recent content on the main index or look in the archives to find all content.

Powered by Movable Type 4.2rc2-en