iTunes Hacking

{

So I am still coming to terms with how iTunes works, and trying to get the "philosophy" behind its organization system. My understanding is this: iTunes can scour the hard drive, if you allow it, and maintain a nice library of tracks, no matter where on your physical disk they are located. You can then sift through by artist, etc...

In my case I have ~30 GB of music and much of it isn't in mp3 files with ID3 tags - I've got a pot pourri of mixes and a ton of podcasts I've been listening to while I work. It's too much of a pain to manually create a playlist for all the folders or try to find unlabeled music in the library. Maybe it's because of winamp but I'm used to organizing my music physically, and then grabbing tracks out of a directory that I want to play, rather than by "artist" or "genre." For example, I've got the following:

-/Mp3
----/PodCast
--------/ITConversations
--------/KCRW
--------... and so on
----/Albums
--------/Interpol
-------- /Massive Attack
-------- ... and so on
----/Mixes
-------- /Jan2005
--------/Feb2005
-------- /Mar2005
--------... and so on

This scheme works well, but it doesn't seem to mesh with iTunes. So I wrote a little program using the iTunes COM SDK that takes a directory as a parameter and automatically creates a playlist for each folder that contains mp3 or other music files. In my case it worked perfectly (took seconds!) in creating playlists for all my folders and the files they contained. I put in a "Sync" button too, so it can synchronize with changes you make to file structure.




I've uploaded a *.zip along with source (it's written in VB6). I tested it with iTunes 4.7 and it works fine. I'm not sure whether this was unnecessary; perhaps iTunes has an option for doing just this, I don't know. But more deeply, I think, is an attitude, an approach of giving the user an interaction with a piece of software. In the PC world, one spends a lot more time "organizing" things than does on one on a Mac. I've heard and read often that systems should be able to manage themselves but find myself balking at the notion that the system can do as good of a job as I can. I download faster than I listen, so things must be organized, but the content of the audio is the archival attribute, not the date, artist, or genre. How this can be known outside of the user, I'm not sure.

If you do make a modification, or an improvement (many probably could be made), let me know. I'm also unaware of any plug-in architecture for iTunes, otherwise I'd try to just make it a couple of buttons or menu items in the program itself.

}

Supporting Each Other, VB6 in Longhorn

{

I posted a bit ago about Microsoft's MVP revolt with regards to supporting VB6. They've responded in kind with VBrun, "Visual Basic 6.0 Resource Center."

The product manager for Visual Basic, Jay Roxe, responded to the petition on his blog and, most importantly, has acknowledged support for VB6 in Longhorn:

"However, I want to highlight to you that Microsoft is still supporting Visual Basic 6 and will continue to for quite some time. In fact, the Visual Basic 6 runtime is slated to ship as a part of Windows Longhorn, which means that it will be covered under Longhorn’s support lifecycle."

I'm an unapologetic lover of VB6, and find myself still using it all the time for helpful utilities. Most recently I wrote a tool using the Apple iTunes COM SDK to sync my physical arrangements of mp3s and folders with the playlists that it created. It's a nifty tool, and I'll post about it soon along with source code.

}

Vasters on SOA

{

A small time ago I admitted that SOA is still a bit elusive to me as this ubiquitous need we were all unaware of having. Multiple marketing machines are in full swing with it, however, and it's hard to separate useful and useless facts, much less fact and fiction.

I found a lengthy article on java.sun.com which should prove to be more technical (and therefore more useful) but meanwhile I'm also beginning to find some other questions similar to my own.

Clemens Vasters writes in his blog:

" When you look at what’s being advertised as “serviced oriented architecture”, you see either the marketing-glorified repackaging of Ethernet, TCP/IP, and LDAP (“Enterprise Service Bus”), or architectural blueprints that looks strikingly similar to things that people have been doing for a long time with DCE, CORBA, J2EE, COM, or mainframe technologies. What’s different now is that it is easier, cheaper and likely more productive to create bridges between systems. "

A Bill Simser responds:

"Indeed at the lower levels of the architecture stack the base concepts of SO have been around as good practices for years. However, we as an industry haven't been applying these base concepts consistently or properly across solutions so it's somewhat academic. If calling them SOA means that people now pay attention to them and somehow feel better about using them, then that's reason enough for me to accept that SOA exists. "

And finally, visiting his blog, I read something that gels the concept a bit more clearly as he speculates on how SAP might have been implemented in a SOA world:

"But what if the architects for SAP had applied SOA from the get-go? The actual architecture would have been defined as several aggregations of financial capabilities (like accounts, money movements, and so on) with appropriate service contracts. It would have also included a collection of capability that would be needed by the finance functions of a typical organization, again with appropriate service contracts. It would have have included some UI capabilities (Web Parts if they were really on the ball) that could consume these services (and indeed other services from different providers) and have the "appearance" of a traditional "application". However, as architects we would recognize that what the user thinks is the "application" is really just a thin facade to the orchestrations of functions they need. An important additional capability is to easily orchestrate other services that are not part of SAP (for example, a service with AMEX to get your credit card statements that can augment expense reports)."

Definitely food for thought, with my own response as follows:

Relating to your speculating about SAP, however, a few things come to mind. First, a different way of thinking when it comes to enterprise applications. You are right when you say that "traditional" thinking lies around task automation rather than loosely coupled "services" that are stitched together by consuming applications (or environments).

But how much of development revolves around loosely coupled services versus automation? Has the nature of the application changed to justify all the force behind service orientation? In one sense I can see it: the elegance of separate, contractual, modular partners, on the other I see architecture astronauts [http://www.joelonsoftware.com/articles/fog0000000018.html] building a massive framework that ultimately doesn't propel us.

All this talk of "contracts" and "services" and so on, and I contrast this with Amazon ECS - making requests for XML formatted data over HTTP: simple, elegant, and effecient.

The journey continues, but it's midnight and tomorrow's coming fast.

}