Shipped!

For those who haven't been reading along (and even if you have, we've been busy working on Prethink, so there haven't been a lot of details on my weblog), there's more info here.

• Prethink works like a search engine for small offices, home offices, workgroups, or individuals.
• Prethink doesn't poke around your network looking for documents. Instead you feed it documents that you want available for search.
• You can send Prethink email. It will index your email and make it available for searches.
• Prethink can listen to weblogs (RSS feeds). It will index posts and make them part of its search database.
• You can import entire directories of files.
• Prethink does not run in a browser. It is a regular Windows application.
• You can drag and drop files onto Prethink's client window and they will be added to the search database.
• Prethink saves you time, energy, and a few brain cells every time you don't have to hunt around your network or your hard drive looking for a document that "you know you have here somewhere".
• When you don't have to remember where you saved things, you can remember much more important stuff.
• By freeing up room in your head and preserving brain cells, Prethink can make you smarter.¹
• If you have Microsoft Word installed on your computer, Prethink can understand Word documents. It will index the contents of these just like any other file.
• Prethink consists of a server and clients. A server running on one machine on your network stores all the documents, handles the indexing, and processes search requests from the clients.
• Even though Prethink has a server and clients, it is very easy to set up. You can get it running in fifteen minutes or less.
• The underlying architecture (called Arsenal) is designed to be open and extensible. We haven't published the SOAP or Python interfaces yet because they haven't been sufficiently frozen. Look for this sometime this spring.
• Prethink is not open source, but you will have a significant portion of the source available. It is written in Python and the interface between client and server is SOAP, so many people will be able to customize its behavior without much trouble.
• Prethink only costs $50 per user. Volume discounts are available: talk to us.
• $50 gets you a year of support and upgrades. Support is through our website. Upgrades will be automatic beginning with v1.1. If, after a year, you no longer wish to get support and upgrades, you can still use the software.
• We host our bug database online, out in front of everyone. We've tried to make it easy for you to report bugs and make feature requests.
• You aren't locked in. Files are stored (unmangled) on the server. Data is stored unencrypted in a standard database format. Although we don't recommend it, you could extract all of your data with a simple Python program. (We don't recommend it because, while it is trivial to reverse-engineer, the database schema is unpublished and subject to change.)
• Backing up your Prethink database is a piece of cake.

¹ Note: this statement has not been evaluated by the FDA and is not a guarantee. Prethink may not actually raise your IQ. But at least people will think you're smarter, and that doesn't hurt, right?

I just read Rahul Dave's essay on Loving Software. I very much like this idea.

One comment that I'd give is that sometimes it isn't always practical to document, for example, data formats or protocols. There are often pieces of software that are designed to change. So documenting these formats would be pointless, perhaps even harmful. So, in keeping with the basic philosophy of respect for the user, I think these should be documented as: "Intentionally undocumented -- subject to frequent and heavy revision," or something along those lines. This allows users to know how the thing works, while they still get the benefits of the upgrade stream because everything doesn't have to be backwards compatible.

I just saw this reply and essay to my post on bootstrapping. Interesting concept. Seems like it might require a lot of coordination, although if all the players have "interoperable business processes" then maybe it could work.

I just uploaded a free demo for those who want to try Prethink before they make a purchase. If you have any questions while you're testing it, please email me (brian at silverback-software.com).

I said here and here that it was time for a change, and here goes. This is a list of how I switched from Radio to blosxom, and a couple of tools I built along the way.

Part One, Setting up Your New Weblog

1. Convert all of your old Radio posts to blosxom-style posts. A blosxom-style post is simple: a text file, first line is the title. This script might come in handy. I stole it from somewhere and hacked it so it would work for the majority of my old posts. You might need to tweak it some more if your posts behave differently than mine.
2. Install blosxom. This is a piece of cake.
3. Get your templates in order. In my case, the rest of my site uses PHP. To include the output from blosxom in a PHP page (overkill? perhaps), use the following snippet of code.

$blogbody = shell_exec("/path/to/cgi-bin/blosxom.cgi?flav=fp");
$blogbody = preg_replace("/Content-Type:.*\n/", "", $blogbody);
echo $blogbody;

4. Note the use of the "fp" flavor in that code. This is an empty head.fp and foot.fp: you'll already have head/foot for the page you're creating in PHP. Of course, if you're not stuck with PHP already, you can skip this.
5. Upload your templates, old posts, and make sure everything works. (Honestly, at this point you should be making sure everything still works -- test out your basic blosxom installation before doing any of this.)

Part Two, Aggregation

This was the biggest hurdle I had to figure out. I like the way Radio is set up: I read news in the aggregator and occasionally post them to my weblog with commentary. Sometimes I use RadioExpress to post items while I'm surfing. How to get the same effect with blosxom?

I'm using a slightly-hacked version of blagg for aggregation.

Hacks to blagg include:

1. Decode ', which is a Radio-generated entity in many feeds.
2. Place downloaded items into separate directory for each feed. This allows you to browse posts from a single source in blosxom.
3. Lastly, the main enabling hack: Blagg saves posts in files called TITLE.txt, based on the title of the item. If TITLE.txt exists, it ignores the item. I added a check for "TITLE.txt_del", so that there's a way of effectively marking items deleted (blosxom won't display files that don't end in .txt) without blagg continually re-creating an old post.

Part 3, Editing and Posting

I decided to use a simple uploader script I wrote a while back to send posts to my server.

I'm editing posts in emacs.

My next hack: blwip. (Say "bullwhip".) The bl is blosxom, the wip is work-in-progress. It is a CGI post manager that runs on your local webserver. (You do have apache installed on your computer, right?) blwip is a little (ok, very) rough around the edges, but it works as follows. You have three directories: posts, wip, and agg. Posts are where your blog posts live -- this is the directory that gets uploaded to your server. Wip is where your work in progress lives. These are posts that you've started but haven't yet published. Agg is where incoming aggregator posts live. blwip has several modes: create a new wip post based on an agg post; delete an agg post; delete a wip post; publish a wip post to "posts"; list posts in progress; show a particular post in progress; and list the subscriptions you have configured for your aggregator. blwip works closely with blosxom and blagg, and requires that both are installed. The preceding sentences are all that exists for documentation right now. I'll get around to adding more in the near future.

Did I mention that, since blwip runs on the local machine, it takes the liberty of launching your editor with new posts? Yes, a wonderfully ugly hack. I love it.

Did I also mention that I'm am NOT a perl hacker and that blwip probably does many things the wrong way (although I have heard that TMTOWTDI or something like that).

This is all running on my windows machine with cygwin installed and uses a bizarre amalgam of native and cygwin tools. With any luck it might run somewhere else. Blosxom sets up and runs in 15 minutes. This may take slightly longer. If you let me know what parts suck, I can try to fix them.

1. Anyway, to set it up put the blwip and blosxom scripts in your local machine's cgi-bin.
2. Install (my modified) blagg, set up an rss.dat and run blagg to populate the aggregator.
3. Use head, foot, and story based on mine.
4. Point your browser at blosxom and you will see the news from your subscriptions along with "post" and "delete" controls. These items will call blwip to delete an agg post or create a wip post.
5. If you're using my basic templates, there are also two nav items along the bottom: a pointer to your subscriptions list, which allows you to browse the news by provider, and a pointer to your posts in progres which allows you to manage your pending posts.

Here are the pieces. converter.py to convert Radio posts to blosxom posts. A slightly modified blagg for use with blwip, which is a CGI script to manage posting from your news reader. And a set of templates for use with blwip.