Two events of late that should serve as a warning to businesses looking to just start a business blog utilizing free services:

1. Journalspace is dead, and so is their content

Journalspace is no more. Countless bloggers have lost all of their content because the folks behind Journalspace were convinced that RAID drives were an appropriate backup methodology.  Ouch.  The only recommendation on the site is to try to get back content via Google Cache.  Double-ouch.

2. Google Feedburner has significant latency issues
Feedburner is having severe caching issues where feeds are not updating for 30 minutes to several hours.  For retailers and businesses with initiatives that are time-dependent, this is unacceptable!

The architecture of Compendium Blogware is built for a business.  We have backups, off-site backups, redundant databases and even an off-site replicated system in the event of disaster recovery.  Our amazing development and architecture teams have even implemented Amazon Web Services and Amazon EC2 Cloudbursting in the event that our client gets an unprecedented bump in traffic.

When they host their blog on a freebie site, businesses assume that these kinds of things are taken care of.  Typically, they are not.

This is a follow-up to my first post on Why host on a subdomain versus a subdirectory.

Matt Cutts of Google has some interesting feedback on this, and promotes the use of a subdirectory due to the complexities involved in subdomain configuration.  I believe that when you're blogging for business and tracking conversions, the advantages of a subdomain become a bit clearer.
  1. Organizing subdomains used to be difficult but is now pretty mainstream in hosting administration panels.
  2. Utilizing subdomains opens you up to utilize third party Software as a Service applications that are best suited to do the job.  Delegating your email subdomain to an email service provider, for example, is a great way to monitor and maintain your email reputation.
  3. A subdomain can be pointed anywhere, internally or externally, providing you a lot more flexibility in moving your blog between providers or changing your website's content management system, etc. without impacting each.
  4. Most importantly, utilization of a subdomain allows you to control, monitor and adjust your corporate blogging strategy seperate than your other marketing initiatives.
If you start a business blog, I still believe that hosting the blog on a subdomain is a best practice.

Joe Wilcox at Ziff Davis' Microsoft Watch blog has written a scathing post about Microsoft's corporate blogging program, using a blog post by Forrester Research analyst Josh Bernoff as the basis for his argument.  Bernoff was making the case that the level of public trust in company blogs is low because people view them largely as self-promotional vehicles.

I won't spend any space critiquing Bernoff because fellow Compendium team member Doug Karr has already done an excellent job of that in another post

It's also worth noting that Robert Scoble, whom Wicox praises in his post, has been largely unsuccessful as a market influencer since leaving Microsoft.  People may be interested in what Scoble has to say, but they aren't buying from his sponsors.

I took umbrage with the latter part of Wilcox's post where he starts to smear corporate blogging with a broad brush (emphasis mine):
I predict that with the economy going to hell, people will find more reasons to distrust company blogs. A car salesman by any other name is a corporate blogger. He's trying to sell something. She has an agenda.
While there are a good number of posts on my blog that talk about the benefits of corporate blogging, not everything I write about in this space is targeted toward selling our hosted blog software.  If you go back through the archives you'll find content on things like:
  • technologies that pertain to blogging, like RSS feeds and search
  • technologies that interest me, such as prediction markets and social graph applications
  • issues in software development, like programming practices, bugs, and security problems
  • what life is like here at the office
As a company that prides itself on eating its own dog food, Compendium leads by example in letting blogging staff drive the content of their posts.  Even though every post I write goes through an approval process, I get a lot of latitude in choosing what I want to write about and how I choose to express myself.  This blog is anything but a continuous hard sell.

Seeking Alpha has a post by Peter Cooper which addresses whether the recent traffic surge seen by finance blogs is sustainable.  Noting that traffic on his own blog has increased tenfold since the summer, Cooper comments on the limitations of blog content reliability and then wonders if mainstream financial publications should make some sort of commitment to hosting blogs of their own.

The reason he gives for the traffic increase is credible:
The response time of conventional news services, and even the financial newswires like Bloomberg is simply too slow in highly volatile markets. A humble blogger close to the information and a PC can deliver a faster service.
I think that this hunger for more indepth and up-to-date information has been out there for a while.  In 2007, I found myself hitting the sites on the financial blogosphere, Seeking Alpha included, for a couple of reasons. 
  • My employer at the time was trying to secure deals with corporations which were in a state of shareholder turmoil.  This helped my coworker and I get some perspective on whether the deals were likely to go through.  We wound up doing a better job of predicting where the deals would go than our upper management.
  • My job search included several publicly traded companies.  Some of them were in the financial services sector, with exposure to the subprime meltdown.  This helped me understand why some potential employers were being loopy in their hiring process, and it even saved me from accepting an offer from a company that was turning toxic.
In each case, blog posts gave me the information necessary to construct a narrative about the raw numbers, like stock prices and earnings, from which I could make an informed decision.

If journalism is the first draft of history, then blogging is closer to the scrawlings of the reporter's notebook.  In some cases it's raw and tentative, but when balanced against multiple sources, the noise usually gets filtered out, and you're left with a mental model that has greater depth than the short blurbs delivered by the wire services.  In times of uncertainty, that kind of understanding is truly valuable.  That's a lesson that mainstream journalism needs to understand as it tries to adapt to a changing market for information.

Almost any regularly updated website, including this blog, hosts RSS feeds. Over the past seven or eight years, the use of the format has exploded. Search engine services support RSS as an output format, so that you can monitor new results that rise to the top over time. Online stores support feeds that allow loyal customers to track new special promotions.

Although there are many applications and users of RSS, the format is still widely misunderstood, largely because services have been created to consume and process RSS in ways that aren't covered by the specification.

So what is RSS? It's a document format that is expressed in terms of XML, a general purpose language for transmitting hierarchical information in a way that (hopefully) is self-describing.  The document is delivered to the consumer over the same protocol that is used to serve up web pages -- HTTP.

Central to RSS is the notion of a channel, which refers to the source of the information transmitted further on down in the document. In here you can find information about the HTML version of the website that is represented by the feed, contact information for the publisher, and date information on when the feed was generated.

In addition to all of descriptive data discussed above, a channel will have a collection of items. An item corresponds to a content unit, such as a post, an article, a comment, a search result, or a product that's on sale.

The item will contain information about its date of publication, a title, a link to the original content unit, and a snippet of the content itself. Some feeds will provide the full content, but a feed is not required to do this. Most advertising supported sites will not provide the full content in the feed because they want the reader to follow the link back to the original website so that ads can be served to the reader.

The content can be plain text or HTML, although most feeds in practice serve out only a limited subset of HTML because the reader may not be capable of rendering complicated HTML.

In the early days of RSS, most readers consumed the format using a standalone program that could parse and display the feed, although most people now use a hosted service like Bloglines or Google Reader. There are even console based readers like snownews, that render the feeds as minimally formatted text.

That's what RSS is, now let's cover some misconceptions about RSS.

  • Any web browser should display RSS in a way that looks like a regular webpage -- RSS is an XML-based format. Most browsers released within the last five years are capable of parsing XML, but since XML does not address on-screen formatting, many of the older browsers, such as Internet Explorer 6, will display the XML with indentation to show the hierarchy of data within the document. Firefox has supported a basic level of rendering RSS feeds in a visually appealing manner, but it does not render all of the HTML formatting faithfully. For example, if you have style attributes on an image that resize an oversize image, Firefox will ignore the settings.
  • RSS feeds should be tightly integrated with my web-based reader -- Some users have come to expect that clicking on the RSS chiclet graphic on a webpage should result in the loading of another web page that offers you the opportunity to add the feed to an online reader. This functionality is provided neither by RSS nor the browser. Rather, it is usually achieved via a proprietary XSL transform (a language for converting XML into something else), which is no trivial undertaking. Google's FeedBurner is an example of a service that makes use of this technology.
  • I want RSS feeds delivered to my e-mail address -- As we learned earlier, RSS is delivered using the same protocol as web pages.  An e-mail is transmitted between mail servers using a different protocol altogether -- STMP, and the content is then accessed via either an open standard, like POP3 or IMAP, or a proprietary protocol like Microsoft Exchange or Lotus Notes.  Moreover, most e-mail programs don't have a built-in XML renderer for message bodies.  In reality, the person isn't really wanting an XML file, they want something like an e-mail newsletter subscription or message digest, which is something that has been around for a lot longer than RSS.  RSS feed reading has a couple of advantages over the traditional newsletter.  First, RSS readers track which items you have read and which items haven't been read.  Second, RSS readers, like Google Reader have deep caching history that can be searched, so you can quickly retrieve things that you may have read, but can't quite remember where.
Now that we've tried to clarify what RSS is and is not, it's worth noting that new technologies are springing up that blur the lines between RSS and other modes of data propagation.  The productivity website Lifehacker today had a pair of posts, by different authors, that underscores this point very well.
  • MailOnFeed -- This free online service allows you to follow incoming e-mails via an RSS reader, essentially transforming complete e-mail messages into RSS channel items.
  • Notify.me -- This service allows you to conume RSS feed items via completely different channels, like e-mail, cell phone text message, and instant message.
Perhaps this is a sign that RSS is becoming sort of a lingua franca for time-sensitive data?

Sometimes you want to go
Where everybody knows your name

-- Gary Portnoy and Judy Hart Angelo,
"Where Everybody Knows Your Name" (a.k.a. Theme from Cheers)
Over at Dr. Dobbs Code Talk, Christopher Diggins has an excellent post about the importance of coming up with good names when writing code.  He opens up with a brief anecdote to make his point:
It seems much of my time programming is spent trying to come up with meaningful names for things. I recently observed a problem that arose when two things were given the same name in a library, but that were in fact different. I was trying to document the library's functionality, and it turns out that virtually everyone on the development team was confused as to what it really was. Breaking apart the concept into two names, instantly cleared everything up.
I've seen this problem come up many times in my 11 years as a software engineer.  It's  a side-effect of the imprecision of everyday language. 

The eight years I spent developing software at Wolfram Research exposed me to a corporate culture where the precise use of terminology was heavily emphasized. 

Their flagship product, Mathematica, is a high end technical computing package that has at its foundation a vast, eclectic programming language.  Not only does it support different programming paradigms (procedural, functional, and rule-based), it also has to straddle concepts from disparate domains like computer science, applied mathematics, physics, graphics, and typesetting.

As a simple example, consider the term trace.  In linear algebra, "trace" refers to the sum of the elements of a matrix's diagonal.  In software development, the same term refers to a record of function calls by a program.  Since Mathematica is a program that can record its evaluation history and do matrix algebra, the language had to support both notions. 

To resolve the collision, there was a compromise, with the keyword Trace becoming the function that was used to track the execution history of an expression evaluation, and the keyword Tr being used to denote the linear algebra operation.  It's worth noting that in making this distinction, the developers had to make an exception to another rule for the language, which was to shun the use of abbreviations in keyword names.

In my last job, I had interaction with members of the complex event processing community, an emerging field of applied computer science which deals with the modeling and creation of algorithms that can make decisions based on patterns of observed data.  They are only beginning to coalesce around some common terminology for things that we don't give much thought to, such as what exactly is an event?

Here at Compendium, we grapple with getting the terminology right in the day-to-day design and implementation of our blog hosting software.  Usually these are things we can hash out with quick meetings and a whiteboard.  At other times, there is a need to be more formal. 

For example, during one of our strategic sprints, we did a complete redesign of the default template used for our customer blogs.  To make the style sheet easy to learn for web designers, we sat down and mapped out the layout of our pages and standardized the terminology of the elements, creating an ad hoc, yet very useful, ontology.

Going back to my previous post about web APIs, the need for consistency and precision in terminology is very important.  APIs have both functions and parameters that serve as inputs to the application, and they have names to identify them.  When a group of APIs uses names inconsistently, it makes the learning curve much steeper, and opens up the possibility of bugs due to programmer confusion.

As for Diggins' post, it wraps up with the following recommendations:
As a closing thought, the following are some of the different naming sins that I frequently see in big libraries in no particular order:
  • overloading of names - sharing a name between two different items
  • incomprehensible names - "quux"
  • vague names - "Object", "Do", "Run"
  • missing names (e.g. using ints instead of enum, using literals instead of constants)
  • using comments instead of names
In the field of software development, a good name can sometimes seem like everything.

blog content can work for you
You know, a lot of people ask me, hey man, I was wondering, can my blog content work for me?

In short, heck yes it can. When you integrate blogs and business, you turn everyday blabber about your company/ organization into working marketing material.

Can you get any more efficient with your marketing dollars? Bang for buck.

If you want the longer more expert answer, packed with blog tips, trades and secrets, tune in to Compendium's upcoming webinar, "Simple Tips to Make Blog Content Work for You," hosted by Blog Aficionado's Chris Baggott and Doug Karr.

This one should be sweet. If you don't know much about blogging for business, or are looking for the right blog software as a service to get your company found online, this is an outstanding opportunity for you to see what exactly blog content can do for your organization. ENJOY!