Turns out there are several folks working on rails-like functionality for PHP. I've looked at them. Sort of leaning towards 'cakePHP'. Only because it's got four or five people using it. The others have one or two. It isn't as many folks as are using ruby||rails by far. The advantage is - code re-use. I mentioned that programmers are lazy. We don't like to do the same things over and over. Re-writing what we've done in another language is even worse than re-writing it because just like human languages, something always gets lost in translation.

Anyway, back to cake for a minute. For programming web apps on top of a database, there's no turning back to the old days. This is so much faster. It's well organized. And if you don't like how it's organized you can change it. Name your project and create a schema. You have to do these things anyway. But with the new tools, this is all you have to do in order to provide basic functionality. It's called CRUD - create, read, update, delete - all from a web page. Once you name your project and define the schema, you've got CRUD. Can't think how many times I've re-written this part to deal with a changed schema. With the application architecture, you don't have to. It's already there. You've also got more. It's an application architecture. There are three layers, and they all have different code pages. One layer talks to the database and other physical resources. A middle layer contains what we call business logic. That's really the secret sauce for the application. The top layer is presentation. HTML, XML, text, whatever.

Unlike the old days, the secret sauce and database logic are removed from the file that gets changed the most - the presentation layer. We're always tweaking how a page looks. We tweak the way it works less often. We tweak the way it accesses data even less than that.

Got ruby (and the rails) installed and working and I've been doing my typical computer dialect quick learn. There was a language before that claimed to do things in less lines of code than what we were using before. It was called PERL. I don't use PERL anymore unless I have to. It is one of the most horrid language specifications I've ever seen.

Ruby looks pretty nice, but it's a bit obtuse. If you're a C or PHP or whatever programmer, you can't exactly read it without a reference nearby. You can read it, but there are a lot of subtle punctuations. I hate subtle punctuations. Yes, they make for a more powerful language, but they also make for subtle bugs. For instance,
  scaffold :event
is a valid statement, but
  scaffold : event
is not.You also apparantly cannot have a database table named 'date' because creating a 'date' class to access it will throw all kinds of errors. It collides with the existing date class which manipulates date information. Of course I have an existing database called 'date' that I cannot use with Ruby||Rails because of this. Sigh. I hate database conversions. I'll have to also change the other application which is using the date database. I made all of these discoveries within ten minutes of getting ruby working.

Looks like it's a wonderful language for discovery of how subtle things affect how the program runs. Perl was likewise a wonderful language for discovery. That's why I don't use it anymore.

We'll see. I use languages that make my work easier. The claim is that Ruby makes my work easier. I'll give it the benefit of the doubt until proven otherwise. But my initial impression is that it's destined to be a flash in the pan like java. Remember when everybody was programming in java? Where are they today?

It also wouldn't take much to put a database and view abstraction layer on PHP. Hint, hint.

One more reason to dump the iTunes DTD... it doesn't exist anymore! Observe the following RSS+XML feed:

<?xml version="1.0" encoding="iso-8859-1" ?>
<rss version="2.0" xmlns:itunes="http://www.itunes.com/DTDs/Podcast-1.0.DTD" >

The 'xmlns' declaration is supposed to give a 'dictionary' of the document language so that an absolute stranger to the itunes namespace can figure it out. I'd have to go dig up the xml spec, but I'm pretty certain they say in pretty strong language that if you sponsor a DTD, you kinda' gotta' haveta' put it at a URL that is never going to change. Ever. This URL comes straight from Apple's own Podcast spec (which coincidentally was invented by MTV veejay Adam Curry, who will soon be the father of the internet according to wikipedia).

Yet if you go to that web address and try and read the language definition, you'll find yourself instead at apple.com/itunes staring at an Apple eShopping mall and in my case telling me that I need a new operating system to install iTunes. Where's the DTD? In fact I'm just trying to extend RSS in another way and was going to use their DTD document as a template (since it's about the only existing extension onto the RSS space). Sigh...

As I've delved into the deepest pits of extending the eXtensible Markup Language (XML), I've found that it has been over-engineered to the point of absurdity. DOCTYPE's, DTD's, XSLT's, RDF, etc.

It's enough to drive an insane person crazy. Extensible? Try it sometime. You've no idea the can of worms you'll open. I think it's time to dispense with the whole mess and get back to what XML started out as. A means to convey information through a '<tag>content</tag>' syntax.

It is an implicit format to allow producers and consumers of information to talk the same language. In doing so, all of the information forms have been forced to be standardized so that the information language is discoverable through namespace declarations and associated style guides.

Why bother?

It's all well and good for something like a web browser which needs to display information, but it's overkill for the use of XML as a simple data exchange format. All you really need is for an information consumer to recognize an element that it knows about and deal with it.

So I'm proposing something new. FreeXML. A freeXML document can look just like an XML document. The only difference is that it doesn't care what it is presented with. Either it recognizes the data or it doesn't. Namespace declarations? We don't need no steenkin' namespaces.

<freeXML>
<html>
<head><title>a freeXML document which contains HTML</title></head>
<body>
Anybody can do it. See?
</body>
</html>
</freeXML>

Now let's go a step further -

<freeXML>
<animals>
<item><name>dog</name></item>
<item><name>cat</name></item>
</animals>
</freeXML>

Either you know what an 'animals' is and how to deal with it or you don't and you ignore it. This is what every XML consumer does now. The only difference is - No DOCTYPE, no namespace declarations with associated DTD, no XSLT. Either the information consumer can handle the data the producer produces, or it can't.

What about extensibility? What about it...

<freeXML>
<animals>
<item><name>dog</name><mypetname>Fido</mypetname></item>
<item><name>cat</name><mypetname>Fluffy</mypetname></item>
</animals>
</freeXML>

Again, either you know how to deal with <mypetname> or you don't. Validation? Why? If you've grabbed this 'animals feed' from a remote source and don't understand a particular element, it wasn't meant for you, and you can ignore it.

What can you do with freeXML? Anything you can do with XML. It's just another type of markup. Heck, you can embed XML into freeXML. Here's an RSS feed -

<freeXML>
<xml>
<?xml version="1.0" encoding="iso-8859-1" ?>
<rss version="2.0" >
<channel>
<language>en-us</language>
<title>Diary and Other Rantings</title>
<description>Life in Silicon Valley by a former software engineer who now runs a music store.</description>
<link>http://macgirvin.com/blog</link>
<lastBuildDate>Mon, 19 Dec 2005 11:57:51 -0800</lastBuildDate>
<generator>Note-a-Day Weblog - Version 2.2</generator>
<copyright>Copyright 2005 Mike Macgirvin</copyright>
<webMaster>mike@macgirvin.com (Mike Macgirvin)</webMaster>
<managingEditor>mike@macgirvin.com (Mike Macgirvin)</managingEditor>

<item>
<pubDate>Sat, 17 Dec 2005 12:00:00 -0800</pubDate>
<title>Goodbye, Ruby Tuesday..</title>
<description>Who could hang a name on you?&lt;p /&gt;Actually, the name is &apos;Ruby on Rails&apos;. It&apos;s quite an interesting moniker for a programming language. OK, the language is Ruby. The &apos;on rails&apos; part has to do with adding the programming language with database classes into a web server&amp;nbsp; and database environment. The example is an entire web-based recipe database in one line of code. That&apos;s impressive, and it&apos;s attracting a lot of attention. It was only a matter of time. Programmers are lazy folks. We don&apos;t like to write the same things over and over. So every time a new language pops up that includes more and more of the stuff that we&apos;ve written over and over again, it&apos;s bound to take off. &lt;p /&gt;But if you look under the hood, it&apos;s not quite one line of code to write a web based recipe database. In fact the tutorial takes three pages of system configuration and database mucking before you get to the one line of code. Some things never change. &lt;br /&gt;</description>
<link>http://macgirvin.com/blog/index.php/DEC-2005#article-17-DEC-2005</link>
<guid isPermaLink="true">http://macgirvin.com/blog/article.php?17-DEC-2005</guid>
<comments>http://macgirvin.com/blog/feedback.php?17-DEC-2005</comments>
<category>software</category>
</item>
</channel>
</rss>
</xml>
</freeXML>

It's hard to believe that it was only a week or two ago that I was extolling the virtues of the Drupal CMS. So much has changed since then. If you recall, I made it sort of work for my needs after fixing a lot of bugs. I was all set to contribute my fixes back to the Drupal development community. But then something happened. They released a new version. Cool! I thought. I'll just download it and get all the latest stuff and maybe they've fixed some of the bugs I uncovered. Doesn't work that way. More bugs. Things that I spent time fixing are now hopelessly broken. The fixes I made can't be applied to the new code. It's all different. And Drupal works on a 'module' framework. They only provide a core application, and others in the community add things to make it do more stuff. The problem is that every time they change the core, they make it incompatible with the existing modules. Nothing I added works anymore. I have to wait for all the different modules which I was using to be re-written. Or do it myself. No thanks. They have a nasty habit of making every existing contributed module break on every version release. So you can't just write a module or fix a module and be done with it. Writing a module makes you a lifetime contributor. You'll have to fix the module over and over again and over again and over again - everytime the core application changes. Looking at the development roadmap, this is going to happen a lot. Think I'll go find another CMS package.

Or see if I can write one in Ruby||Rails in a dozen lines of code... 

Who could hang a name on you?

Actually, the name is 'Ruby on Rails'. It's quite an interesting moniker for a programming language. OK, the language is Ruby. The 'on rails' part has to do with adding the programming language with database classes into a web server  and database environment. The example is an entire web-based recipe database in one line of code. That's impressive, and it's attracting a lot of attention. It was only a matter of time. Programmers are lazy folks. We don't like to write the same things over and over. So every time a new language pops up that includes more and more of the stuff that we've written over and over again, it's bound to take off.

But if you look under the hood, it's not quite one line of code to write a web based recipe database. In fact the tutorial takes three pages of system configuration and database mucking before you get to the one line of code. Some things never change.

Something that has really been starting to intrigue me is the potential for wanton internet identity theft. It works like this... you go to a cool new site and sign up with a username and password. Just like the other hundreds of sites you belong to. But unless the site has imposed a particular username on you (your first choice was already in use), aren't you going to use your 'standard login'? Same thing on Amazon, Google, eBay and everywhere else? Don't lie. Everybody does. And that's why it is interesting.

What about on stinkinidiotsinweirdclothes.com ? Wouldn't you use your standard login there as well? If you're like most people, of course you would. Do you know who has access to the database? Do you trust him/her/them? One well-placed internet site could collect thousands of logins. Every one of them would probably be good on 10-100 major sites and thousands of smaller ones. Credit cards, shopping, bank accounts. It's probably a hundred times as effective as a phishing scam.

Now that you're aware of the problem, what can you do about it? Start changing your passwords! Change something - anything. (Perhaps) add the first character of the site name into your standard password. The only thing that's preventing this from being a global crisis is that nobody has sufficiently exploited it for personal gain (yet).

Over in the XML playground I've been quite busy. Dang. I've fixed a lot of bugs. Really nasty mostly simply obvious bugs. Who's doing the QA for this thing? Oh that's right. Free software. Looks like I'm doing the QA - and fixing everything the young whippersnappers didn't learn in CS-101.

The next piece (which is probably going to take a few days) is to re-do the XML aggregator so that it supports something called 'My Feeds'. It's almost there, but not quite. It will already let folks administer XML resources, but they can only view a) an individual feed, or b) the whole universe. I want everybody to be able to build their own data streams.

You've no idea how pathetic is the state of the vast universe of XML feeds. Most of the sites that I'd like to get a feed from don't offer one, or they only offer teasers (a headline followed by 'go to the site to read the story'). That's hardly an information feed. Several overseas sources I tried are using Windows code page 1215 as their XML charset. Yuck. I don't have a UTF-8 convertor for that one. I also can't seem to load any Wordpress sites where somebody used an ampersand or tag element in their category name. Wasn't properly XML escaped. (Note to self: check my own code - I don't think mine escapes these either). So there you have it. For every ten potential feeds I've looked at, only one or two converse in a compatible XML dialect. Of those, only a small fraction offer any meaningful content.

During the last few months I've been installing and evaluating a bunch of the public domain Content Management Systems. I've mentioned previously that I'm not particularly impressed by them. They're pretty much geared towards idiots that want to launch full-featured websites. As a consequence they need to make every aspect of running a web portal appeal to the masses. So they can't call something 'keywords' or 'categories' - instead it's 'taxonomy'. Because 'taxonomy' is more understandable by the average human than 'keywords' or 'categories'. Right. On four out of five of these packages it took an hour of searching menus to find a place to set the site title. Free software. You get what you pay for.

But I found one that wasn't too bad. It's called 'Drupal'. It's got some bugs and quirks, and is similiarly obtuse, but it seems to do quite a bit. So I loaded it up over on the floozee site (that's dot com, hint hint).   Multiple blogs, discussion boards, event calendar, newsfeeds, buddylists, etc. Pretty nice little app (once I fixed a few bugs). Oh, and it's got a crude but functional XMLRPC interface. I would have said that it's the perfect launching pad for my next great blog idea - except that it pretty much embodies my entire next great blog idea. I've got some configuration work to do, but basically you build a community blog portal that's tied to an event calendar, latest newsfeeds, online discussion groups, etc. Sigh... guess it wan't such an original idea after all. But now I've got a framework with all the right code to do what I was thinking, so maybe I'll figure out a unique twist yet.

Having a cup while the operating system is being restored on the system that failed yesterday...

Yet another group of folks is scheduled to come out today and gaze at the bubbling brook outside my store and figure out if there's anything they can do about it. The first guys, at great expense - are going to run a series of high-tech tests to figure out where to dig.  The second group might actually start the excavation.

I looked at the dysfunctional hard drive. Western Digital. Gak... Let me tell you something. I've got a drawer full of old hard drives. Some of them go back twenty years. Every single Western Digital drive I've ever owned has failed,  and almost always have failed spectacularly. Most every other drive I've still got, and I can still access them given the right hardware. Draw your own conclusions.

2:00 PM

The operating system has been reloaded. Restored my most critical applications first. First things first... the printer drivers and the web browser. Then use the browser to grab the backups. The rental accounts recovered flawlessly. Then I open my financial account data. The most recent date on record is 2003. Ouch. Two years of lost data. Including this year. But I just backed up this two days ago. How could that be? Perhaps I loaded the wrong backup. I scanned the server directories. There's a problem... I have two versions of the backup on the Unix box. In one, the file extension is lower case. The other is upper case. And it was created two days ago. So I reloaded with the upper case version of the file.

The newest date is still 2003. Now I'm starting to sweat. My finances for the entire year - I don't seem to have them on backup. I check the other server. There's a file from Jan-2005. OK - let me try that one. I'll at least have a little more data than I do now. But I think the bank will only let you download three months into the past. I've still got a big problem. Doesn't look like there's any way to recover most of this year. I'm really sweating now. So I load the file from January. The newest date is still 2003. You'd think I'd be sweating buckets, wouldn't you? But no. Now I breathe a sigh of relief.

You see, I've used that particular backup before (the one from January). I know that it contains more recent information than 2003. The program migrated the data on the first file I used, and stored it somewhere else. It didn't even look at the two other backups I loaded.

So I deleted all the data from the program, and started fresh with the uppercase file from two day's ago. Bingo. Everything is there. Sync with the bank and everything is hunky-dory.

They found the leak. I've got jackhammers going 30 feet from me right now. Should be fixed in another hour. Glad it was outside the store...

 

Finally got some XML sources to talk XMLRPC to each other. As I mentioned on a prior occassion, this is distributed computing made easy. So why did this take so much time? It's software. Software is not easy. Software communication is even harder. First you need two different systems that even have the ability to converse with each other. Then you need to get them talking the same language. What is system A expecting to hear? What is system B saying? Now reverse the roles and try again. Analyze every byte of every conversation to find the source of the failure to communicate seemlessly. Finally found it. Was sending RSS items to one server, who only wanted  the elements of the item, not the items themselves. Grrr. Then the XML generator was double escaping  XML entities.  Fixed that. Then all of a sudden it started working. Great. I can edit my weblog and have it propogate to any place on the web that I might wish to have a weblog. That's what's cool about XMLRPC. And it's only the beginning. The proof of concept has been around for a few years now. But folks like me are just starting to actually use it. And the API's are still primitive. Let's take the weblog example. If I decide to update 20 weblogs from one page - I have to keep track of

• where each weblog resides
• my login credentials for each weblog
• the unique name of the weblog that I wish to edit
• for every message : the message-ID of that message for that server
• the category list for every server
• yada, yada

It's too much data to have to enter and keep track of. That's why using XMLRPC as a weblog tool won't survive except on systems with huge databases or as a remote data entry tool for one blog. But that's where XMLRPC came from. Proof of concept but less than a must have. It isn't where XMLRPC is going. It's a must have, but only after we get the infrastructure in place.

I've had about enough of the iTunes XML namespace DTD. Think I'll yank support from my codebase. Originally I thought it would be nice to be able to provide Apple compliant podcasts. But whoever came up with this DTD should be drawn and quartered. If you've been following the furor over podcasts over at Wiki, I think we'll probably find that Adam Curry invented this DTD. If you haven't been following - here's how it goes. Somebody has been editing all the references to podcasting on wikipedia. They've been over time removing reference to every name on the page except for Adam Curry. All the developers who actually made it work. Now here is where it gets interesting - all of these edits have originated from IP addresses that are owned or controlled by Mr. Curry.

But I digress. It's the DTD that I'm ranting about. They've got an element called <itunes:duration> - which gives the play length of a sound file. This is a wonderful thing to have on a podcast because the RSS spec only supplies the size of a media attachment in bytes; not in play length. But why - oh - why is <itunes:duration> an element of <item>, which is a description of an article ? It should be an element of <enclosure> - which is the data it describes. The problem arises if you have two such enclosures. Which playlength belongs to which file?

Turns out that this is only one issue with the iTunes DTD. There are hundreds more. After all, it wasn't designed to be a web standard. It was designed quickly as a means to sell Apple products, and coincidentally is a perfect one-to-one match for the iTunes.com database schema. Think I'll wait for a better attachment DTD to come along.