warning: technical rant follows. NSFPWL (not safe for people with a life).

When I worked at techies.com back in the day, the developers had this habit of describing the code base as "very OO" (oh, oh). Deciphered as very object oriented. The techies code base was bloated and slow and completely unstable. As a system administrator I had written a script to loop and wait until the main java servlet process crashed, and then it would start it again. This happened about every ten minutes or so. If you would ask the developers about the development methodologies of the techies application they would inevitable say, "It is all very OO."

Saying something is very OO when asked about the inner workings of an application is like a mechanic answering "We made it go fast" when asked about the engine of a stock car. This answer is so general and vague it is like saying, "Well, we used a combustion engine in this car, cause, well, combustion engines are the new exciting engines, and they make the car go forward."

This leads me to Movable Type(MT). I have helped implement a few systems with MT, and helped manage and maintain a high volume web site that is published using MT. From a users perspective MT is a clean and nicely designed weblog publishing system. It is fairly easy to install, and has a decent feature set to get a weblog off the ground and running. It also provides a plugin API, and there are a wealth of plugins out there that extend the app in many interesting ways. It is easy to understand why end users like MT.

When I first started hearing about MT people would mention how great the code base was. "It's clean Object Oriented Perl." they would say. When I questioned why MT wasn't open source I was told by one user that the main developer was concerned about accepting any code into his pristine code base (note: I am fairly sure that this was inaccurate, but I mentione it to note people's perception of the MT code). When a company I contract for was discussing moving to Wordpress (another weblog publishing tool) a concern of one of the adminstrators was that it wasn't truly "OO" like MT.

To be clear, I will draw a line in the sand. These are all perceptions of end users and people who have not done much development with object oriented languages, or with MT proper. These are comments from people who have used, and are using, MT.

After working with MT for a while I started to peek in under the covers to see what was what. Most MT installations run as perl CGI, and if you have had any experience running a high traffic site you will understand what that implies. CGI is not very scalable, and perl CGIs add even more overhead to the problem. Add some OO (very OO) perl on top, and you have built yourself a three-toed sloth for a web application. Mind you, MT was built primary for personal publishing (I am assuming here), so for most, this isn't an issue.

This leads me to a "very OO" aspect of MT, MT's CMS class. This class implements a very basic anti-pattern, the god class. It is over five thousand lines of perl code with over 100 methods. CMS handles much of the core content management calls for the web application, at least I assume it does as I didn't read through all of the five thousand lines of code. It is a behemoth of a class, and bloated is a nice way to describe it. It is a grand example of a god class.

[mark@louis App]$ wc -l CMS.pm
   5203 CMS.pm

I have written a god class (a few to be honest), every developer does at some point. Being a good developer is about learning from mistakes, and improving on your design the next time. Do I fault the developers at techies for their badly written code? I do not. I eventually became a developer at techies and helped introduce my share of badly designed code. They key is, of course, not repeating the past, learning from your mistakes. This is what, in my mind, makes a good developer.

I don't write this to bash the MT developers. They have done a lot of interesting work, and we all implement bad designs along the way. It is all part of the process of being a developer.

So why the rant about MT? When people tout a bad design as an elegant design it is a misdirection, a lie. People who do not know better will accept it as good, and will propagate it. Movable Type is an acceptable weblog publishing tool for some users, but as an example of good object oriented design and implementation it falls far short.

Brian sent me an email today about a simple HTTP API for making calls with vonage (our voice over IP phone service).

Third party call control allows third party developers to write their own software applications to initiate a call from their Vonage phone to any other phone in the world.

For example, an Outlook plug-in could be created that would initiate a call by clicking on a phone number in the Outlook contact list. Another example would be a browser plug-in that would place a call to a phone number on any web page.

- Vonage Third Party Call Control

I thought it'd be nice to be able to select a phone number in Apple's Addressbook.app (where I keep my contacts) and have it call that number. After a bit of looking around I found just such a script for skype. I did a couple of small modifications, and now it works for vonage.

Just save the following code as a script in "~/Library/Address Book Plug-Ins/", and modify the variable 'thispage' url to match your vonage username, password and phone number:

'username=vonage_username&password =***&fromnumber=15551212'

applescript:

using terms from application "Address Book" on action property return "phone" end action property on action title for p with e return "Dial with Vonage" end action title on should enable action for p with e return true end should enable action on perform action for p with e set phone_num to the value of e set prefix to "" set cutoff to 0 set taster to character 1 of phone_num set taster to taster & character 2 of phone_num if taster is "00" then set prefix to "+" set cutoff to 2 end if if taster is in {"01", "02", "03", "04", "05", "06", "07", "08", "09"} then set prefix to "+44 " set cutoff to 1 end if set new_num to prefix repeat with i from cutoff + 1 to the number of characters in phone_num set new_num to new_num & character i of phone_num end repeat set phone_num to new_num vonage_out(phone_num) end perform action end using terms from on vonage_out(phone_num) tell application "Safari" set call_string to phone_num set thispage to "https://secure.click2callu.com/tpcc/makecall?username=vonage_username&password=****&fromnumber=7125551212&tonumber=" & call_string make new document at end of documents set URL of document 1 to thispage end tell end vonage_out

Once installed just right click on any number displayed for a contact and select 'Dial with Vonage'.

All that picking up the phone and dialing crap, it was making me tired. Yet another great example of how the modern age has turned me into a lazy bastard.

Due to the public's overwhelming distrust of Instant Messaging and Robots, the Federal Ministry of Instant Messaging Fear and Robot Distrust has forced me to disassemble mwilkiebot and scatter the bytes to the four corners of the globe (how a globe can have corners I'm not quite sure). In the end, mwilkiebot was charged with breaking the unspoken fourth law: Do something worthwhile.

Farewell mwilkiebot, your glorious and inspired automated responses shall be missed.

the only known photo of mwilkiebot

Super Human Intelligence Trans-global Inc. is proud to announce MWilkieBot 1.0* **.

MWilkieBot, where the future was yesterday.

Afters years of research and development at SHIT laboratories, we have perfected the mwilkiebot prototype and are now prepared to preview it to the public.

The researchers at SHIT Inc. have spend years perfecting a highly sophisticated user interface called "iCommand Line® " and we have brought this dramatic new technology to the Instant Messaging sphere. Why just IM your friends to say 'hey', IM MWikieBot and say "HEY!"

MWikieBot 1.0 supports the exciting new feature: search movies by title.

How do I get in on the ground floor of this exciting new technology you may ask? Open your AIM client and start a chat with mwilkiebot, and then prepare yourself to be blown away by the power of "iCommand Line®".

MWikieBot 1.0 - in stores nowhere near you.

* MWilkieBot may have various similarities to N4CHL1N BOT 1.4, but any, or most, similarity is purely coincidental.

** MWilkieBot my cause extensive bleeding from the rectum and /or massive coronary infarction.

added a couple of new bot commands tonight.

1. hal ?
2. showtimes 'zipcode' list movie theatres and showtimes for a particular zipcode

Capitalizing on all of Jim's hard work, I stole...err, borrowed his AIM chatbot code to hack up my own chatbot.

Jim leveraged the very nice perl Net::OSCAR AIM APIs, which makes it very easy to write up an AIM chatbot.

In the future I will use the bot to do exciting things like, well, I don't really know, but it'll be great. For now the bot responds to a few simple commands, one of which will let you read the latest post here at bitterpill.org. So instead of reloading this page every day for a month or so waiting for a post, you can send a simple IM chat command to see that I haven't posted. Ah technology, it really is making our lives better.

Send an AIM message to mwilkiebot for loads of hot bot on bot action.

Send an AIM message to N4CHL1N to chat up Jim's bot.

Jim uses the Acme::Wabby APIs to make for some interesting bot conversation.

There has been a proliferation of web apps released in beta form in the past few years. For those who aren't exactly sure what beta means, basically beta is a term used for software that is not quite ready for release. It means that there are still some known bugs, and most likely some unknown bugs in the software. The software is in the need of some bug fixing and tweaking before it can go prime time.

Back in my early days of system administration, many of the GPL/open source software tools we used were quite usable in their beta stage, and it was very common for us to run beta software on our production servers. Most software projects had an alpha release that was, oddly enough, pre beta, and most alpha releases were quite buggy and unstable. Eventually these alpha products would become beta, and these beta products would become release versions. Alpha and beta versions were and are a way to release software to the masses for feedback and testing with the aim to produce a release quality version.

It seems many modern web based software products are using the beta label a little too freely and for other purposes. We labeled kinja.com a beta product when it was initially released, and rightly so as it was a new product just out of the gate. I left kinja well over a year ago, and yet kinja is still in beta. Google News, gmail and flickr are all still labeled beta well over a year from their initial releases. Its hard to believe that these companies have not been actively developing these products, and are unable to hammer out any of the bugs and features in the software at this point.

It is invaluable to release software early to your users so they can use it, touch it, and give you feedback on a work in progress. I think the idea of releasing alpha/beta software to users for feedback is an excellent tool that will help produce quality, bug free software. However, companies are using the beta label to excuse flaws in their web based software beyond just getting initial development feedback. What else can explain beta versions of web applications that have been in production use for over a year.

It seems that software companies think that adding a beta graphic to their webapp's logo gives them a bit of leeway in the quality of their wares. Maybe this is true, but how long can you label your live webapp as beta when people are using it as production software. Usually a beta release is followed by more advanced pre-release products, and maybe even release candidates, which eventually evolve into an actual released product, a 1.0 version of your software if you will. In the old days, if a product remained in a beta stage for overly long periods it meant that the software was most likely no longer being actively developed. I find it hard to believe that gmail has gone idle.

The beta label is being used to excuse flaws in software as opposed to being used as a tool to help expose flaws in software before final release. In the end it dilutes the value of releasing beta software if software is labeled beta without the intention of using feedback to produce release quality software. I imagine there is overlap in most cases, and most companies do wish to expose and fix flaws, but non the less, it still seems disingenuous when obviously production ready webapps remain beta for overly extended periods.

"Google believes that users should have a choice in what applications they use for editing text files. Built to support industry standards, Google Text enables Google users to press letters on their keyboard, and those letters will then appear in a Google Text document. Users can string these letters together to form whole words, even complete sentences. Google says that users will be able to create entire paragraphs of words and sentences, and, for the advanced computer users, complete documents.

Google Text uses industry standard ASCII text and provides innovative features such as 'cut and paste' and the 'deleting' of mistyped characters.

Google Text currently only has client support for Windows, but Google reportedly said that a web based client is in the works. The web client will provide support for Apple OS X and Unix platforms, but the web client will only support a limited subset of the characters that users can type in the windows based client. It has been reported that the web client will support the letters 'a', 'f', and 't', and the numbers '2' and '7'. Google says they are not planning any other characters at this point, but reminded that Google Text is in beta.

Yahoo has stated that their competing product "Yahoo Pad" is set to be released in a few months...

The XMLHTTPRequest object in javascript with safari does, on occasion, set the status for the return request as 'undefined'. It seems this is a problem with safari 1.3, and I do believe in 2.0 as well, when trying to retrieve pages from the browser cache using XMLHTTPRequest or AJAX as the kids are calling it these days.

I have been loading static XHTML template files for dynamic rendering as a way to make simple reusable dynamic UI components, and to avoid having to generate HTML within javascript. These templates are static XHTML, and they do indeed become cached. When an attempt to retrieve these cached pages using XMLHTTPRequest within safari 1.3 the status is defined as, well, undefined.

So my code was dumping errors left and louie:

if (req.status != 200) {
   alert("http connect error\nstatus: " + req.status);

and the alert looked kinda like:

There was a problem retrieving data from the server
status: undefined

It took me forever to figure it out. Finally, I found a post from an apple mailing list archive that solved the problem for me.

"Basically you want to add something like the following before the call to send."

xmlReq.setRequestHeader('If-Modified-Since', 
         'Wed, 15 Nov 1995 00:00:00 GMT');

lists.apple.com/archives/dashboard-dev

This tells the client (safari) to retrieve any document who's modified date is later the Nov 15, 1995 from the server, none of this new fangled cached document stuff...now, if your fetching an XML document from 1994, well you're out of luck my friend.

update: I should of mentioned that this does in fact stink, as the client is forced to retrieve the document over the network when it has a version of the document cached locally.

warning: incoherent and mind numbingly boring technology rant follows:

The comment form here at bitterpill.org is set up to send me an email when, in the rare occurrence, someone posts a comment. However, the email functionality has been broken for some time. Why? To be honest, I have been too lazy to figure it out, and frankly, this wasn't a bug high on my list of bugs to fix. Today I gathered up the gumption to sort it out. It turns out that the least likely of culprits was to blame. I imagine many a reader now pondering, "You mean it wasn't your crappie code or your even crappier system configuration that was causing your mail problems?" On most days this thought would be right on the money, but today my dear friends my incompetence was not to blame. It turns out it was was those Stanford brianiacs at google.

Google, in their infinite wisdom, decided to bundle the java.mail API in their google API jar, and in the process broke my mailing code. The java.mail API doesn't take too kindly to having multiple instances of its self in the class path, it's selfish that way. It took me forever to figure out why it was failing, and only after Nick pushed me in the right direction by convincing me to look through all the java APIs in the bitter pill webapp to see if some dope had bundled the mail APIs in their code. Google was the culprit, those bastards!

For posterity, a quick glance at some saving grace bash scripting:

for file in `ls`; do
    echo $file; jar -tf $file | grep mail;
done