|« December 2004||February 2005 »|
I'm Ryan Lowe, a Software Engineering graduate living in Ottawa, Canada. I like agile software development and Ruby on Rails.
I write this blog in Canadian English and don't use a spell checker. Typos happen.
» Full-time Ruby on Rails freelancer
» Full-time with Rails since May 2005
» Former committer for RadRails (now Aptana)
» I also have a few Rails side-projects in development:
1. wheretogoinTO.com Toronto nightlife
2. Hey Heads Up! TODO list and sharing
3. Layered Genealogy family history research
4. foos for foosball scoring
5. fanconcert for music fans (on hold)
Hiring Rails developers? I can telecommute by the hour from Ottawa, Canada
»» Email: rails AT ryanlowe DOT ca
Now hosted on Hey! Heads Up -- check it out!
Derek Lowe's (Ryan's older brother) words at Ryan's funeral
firstname.lastname@example.org no more
Forging Email Headers: Good, Bad or Ugly?
Sarcastic Dictionary (Part 1 of Many)
Twisting Rails is Risky Business
Risky Business? My Take on Early Alphas
Whoa, it's August 2007
A Postscript to "Growth at the grassroots"
»» All Blog Posts
David Heinemeier Hansson
James Duncan Davidson
Signal vs. Noise
Amy Hoy: (24)slash7
Luis de la Rosa
# Next Year I'm Getting the Flu Shot
I tell you what -- I've never been hit that hard with a cold/flu before in my life. I never get headaches and I had one for three days straight. I had a moderate (101-102) fever for a few days and weakness, the chills, muscle pain and all of that fun stuff. Tons of congestion but no coughing, which was weird. And a sore throat in a pear tree.
All told I lost three and a half days of work. I probably slept 90% of the time. I feel almost better now but I'm worried I'll pass this miserable flu on to other people -- when do I get the all clear?
# Google responds to blog comment spam with rel="nofollow"
A month ago I made the blog post Google: Protect PageRank Against Blog Spammers. In it I proposed that Google should have a blacklist for comment spammer URLs so that these URLs don't benefit from the increased PageRank via blog spamming. My main point was that Google has an interest in protecting the integrity of their search results and therefore the PageRank algorithms and search database.
Google has responded another way and put the onus on the bloggers to mark URLs that could be exploited with the
I like the idea, especially that Google is doing it in collaboration with MSN and Yahoo. The disadvantage of putting the onus on the user is that it will take longer for blog spam to disappear -- spammers will still be able to exploit older blog systems until those systems are updated (which could be never).
The advantage of putting the onus on the user is that Google doesn't have to maintain a blacklist and put itself in a potential hot seat. Blacklists are a slippery slope -- just ask the people who tried to maintain a list of open email relays to prevent spam. I forget what that project was called (ORDB maybe?) ... but here's a list of blacklists.
I've updated both of my MovableType installations to add
# Durham File Synchronization Possibilities
There are lots of useful things that Durham could do for applications that use metadata so that they don't have to worry as much. One of those things is synchronizing the data in the files with the user interface or object cache used by the application.
When you're looking at metadata it's nice to see the most up-to-date information because it could have been changed by another application.
There are two ways to update: lazy and proactive. The lazy method just waits until the last minute -- maybe you select the file to see its properties -- to check the file timestamp to see if it has changed since the last time you read it.
The more proactive approach is to hook the metadata object into the operating system's notifications. The OS will notify a listener every time a certain file is modified. There seems like there would be more memory/processing overhead with this method.
Whether to be lazy or proactive could be configurable. The nice part is that to an application that uses Durham the objects will just be up to date automatically. The update mechanism can be abstracted away.
# Google Group for AudioMan and Durham
I made a Google Group for AudioMan and Durham discussions. Thanks for the suggestion Luis. I'll still be blogging about AudioMan/Durham issues here and I'll just point from here to the Google Groups web archives and vice versa.
The group is open to the public and is the place to give suggestions and report bugs until Bugzilla for AudioMan/Durham gets into full swing again (after 0.1.0).
# Durham Not Using Java 5
I'm going to have to backpedal on using Java 5 for Durham, one of the main reasons being that the Mac doesn't support Java 5 yet. Apple releases their own versions of Java instead of Sun and they usually trail the Sun releases by a few months. Java 5 (Tiger) is apparently going to be released with Mac OS X 10.4 (also called Tiger).
Since I'm trying to position Durham as metadata support for Eclipse RCP applications it doesn't make sense to not support the Mac, one of the three major platforms Eclipse/RCP is written to. Another reason is that people are still using Java 1.4 to make software and they may not be able to use Durham plugins because they haven't upgraded to Java 5 yet.
I can't wait to use Java 5 features but unfortunately Durham is not the right project to use them just yet.
# Properties Get More Difficult
Properties used to be simple. They used to be just a name and value pair, like these:
You could store these name-value pairs in a Java Map, and get the values using the name as the Map key. Then id3v2 came along and complicated matters. id3v2 has many properties using keys comprised of more than one value.
A simple example is the Comments frame of id3v2 -- frame ID of COM or COMM -- which can exist multiple times in an id3v2 tag as long as the language and description fields are different (Here's a list of all of the id3v2 frame types). Three fields then become the property key -- id, language, description -- and uniquely identify the property. An application like iTunes uses the key:
for the "default" comment -- the one that shows up in the UI. Possibly for other language versions of Mac OS X the language changes, I can't be sure about that. It also uses two other comments to store some iTunes-specific values:
WinAmp is lazy and just picks up the first Comment frame instead of looking for the one with the blank description. So the first could be the user-entered comment or one of this iTunes ones with data in it that doesn't make much sense to a user. The spec says that the comments should be sorted by importance.
Maps are handy for storing properties and I want to keep using them. But my property keys are going to have to get a little more complicated to handle these types of properties. I also want to keep it simple for simple situations though -- the Map should still support regular one string names for keys as well. Of course in a Map all of the keys need to be unique.
That's not all. The UI has to be able to know what a valid key looks like. To do that I have to be able to describe keys and the elements in them. In the example above valid id and language values come from a known set (ie. enumeration). The UI could display this set as a dropdown box. The description field is a little more free-form and can even be blank.
In other id3v2 properties some of the keys are numbers that have to be within a certain range or cannot be empty. Expressing these restrictions could be a little tricky...
I don't want to get too far ahead of myself but at the same time I don't want to trivialize metadata properties by thinking they are always easy name-value pairs.
It might be nice to start with a basic name-value pair-based GUI for Durham but at some point Durham is going to have to support these "advanced" kinds of properties as well somehow. Hopefully sooner than later because great id3v2 support could really be a killer feature of Durham and the next AudioMan.
I know Roy's definitely been clamoring for great id3v2 support. ;)
# More on the Quick Edit Perspective
Here are some ideas for the initial UI of Durham's Quick Edit Perspective. For a first run, minimum functionality is the most important -- something we can get comments on and iterate over. For now I just need something that works so that I can hook up all of the backend stuff dealing with the metadata itself. Here's the basic look again, copied from last week:
The Properties view is a list of the metadata properties from the file that's selected in the File List view. Only one file may be selected at a time (for now). The Properties view is tricky because depending on the file selected it may have a few metadata properties or none. A JFace TableViewer seems like the best choice for now, with columns for Property Name and Property Value.
There also has to be a way in the UI to save the properties back to the file, like an action for File --> Save Properties (ie. Ctrl-S). That seems simple enough.
Now onto the properties themselves, which I'm working on for MP3 files. MP3 files are special because they have three different types of metadata: id3v1, id3v2 and MPEG information.
I could combine all of these properties and display them in one table in the Properties view, but that might look cluttered. Initially it might be enough to just have something like
as the property columns. Later on the different types of metadata can each be on their own tab or something. Remember, there aren't advanced features in this perspective -- it's just for quick viewing and editing all different types of files, not just MP3.
Other file types that have much simpler metadata are pictures and Microsoft Office documents. Plugins could be made for these as well.
# Milestone 1: Ship Something
So the goal of the first milestone is to get a minimum amount of work done in order to ship Durham:
I'll be busy enough with the metadata stuff if someone wants to tackle the UI. The CVS details are on an old post and you can just send me patches.
Update: Actually, I've gotten a pretty good start on the UI. Check out the CVS repository to see the progress. Helpful: Eclipse RCP Browser Example.
# Newspaper Interview with National Post's Kevin Restivo
I'm mentioned in the National Post today in Kevin Restivo's article about Bell Mobility's recent billing issues.
My blog posts about my dissatisfied experience with Bell Mobility were picked up by Google and became a feedback point for many other dissatisfied people. Through their anecdotes I realised my experience was fairly minor.
I'm thinking my name was used just to give the story a personal angle. There wasn't much to it, really. Here's the text from the start of National Post January 5, 2005 Financial Post section FP6, Bell mired in billing morass (I can't find the article online yet).
Ryan Lowe is an unhappy Bell Mobility customer.
I think that the parts about me captured the essence of my situation. Unfortunately there are a few factual errors, which I'll chalk up to the over-the-phone interview and bad communication on my part. I'm not used to being interviewed by newspapers and I should have made things more clear.
First, I'm not a software engineer. I may have mistakenly told Mr. Restivo this or confirmed it, but technically I'm not. The Professional Engineers of Ontario want to protect the title "engineer" from dilution and only want licensed professional engineers (P.Eng.) to use it in their job titles. To become a licensed P.Eng. I need to be working for a few years and complete an ethics exam.
It would be more correct to call me a "software engineering graduate" or a "software developer". Sometimes engineers-to-be are called Engineers in Training, or E.I.T.
The only time I heard directly from Bell Mobility was when I called their 800 support number last summer and got an automated message saying that the support lines were very busy and that Bell Mobility was experiencing billing issues.
The automated message also promised that things would be cleared up soon and bills would be settled, so rather than wait on the line I decided to just wait a few months to see if things cleared up. They did, but I still didn't hear anything from Bell Mobility about the matter.
I don't remember making that quote about "unnecessary hassles", but I could have. The interview was over the phone. That's fine, I'll take responsibility for it. However I'll add to it: it wasn't only the hassle that was unnecessary, it was the lack of communication. That's what I was mostly unhappy about.
I can understand software problems and the complexity of upgrades, I'm a software engineering graduate. But the general public doesn't care, they just want things to work. When things don't work it would be nice to know why instead of being in the dark.
I'm glad this is getting attention from a software perspective. Technology can affect your company's reputation, so it's important to be careful as well as communicate with your customers when changing your core technology. People won't tolerate anything less -- I know a bunch of people who have switched away from Bell Mobility because of this, and I'm considering it myself.
# MP3 File Metadata and Durham
MP3 files present an interesting case study for metadata and a great starting point for Durham. Not that MP3s were the first files to use metadata but they have a lot of interesting conditions that need to be taken into consideration.
MP3 files are MPEG audio data. There's some metadata about the MPEG frames that can be derived from the file but cannot be modified. From Durham's perspective these properties can be read-only metadata.
Then we have id3v2 and id3v2 -- two metadata formats for MP3s that can exist on the same file. It's important to keep the information in both formats in synch as much as possible but the id3v1 format has severe limitations (the biggest properties are 30 characters maximum, for example) that can prevent this. The idea is to write the id3v1 tag to files for older/simpler applications that can't read the id3v2 tag.
Here's where Durham comes in: three different metadata formats being read but only two being written. Plus, the two being written should be written to the file at the same time for efficiency reasons instead of opening the file twice. Read-only properties (of course) are skipped and not written at all. Durham can manage all of this with a generalized metadata property API.
The plugins for the metadata formats MPEG, id3v1 and id3v2 will use the Durham API/interfaces to let Durham read and write for those formats. Durham will handle all of the file I/O -- the metadata format plugins just need to tell it where to read and write.
Third parties can add support for other file metadata formats by writing their own plugins.
# Starting Durham/AudioMan2
I have some setup code in place but development is just starting. Nevertheless here's how to get Durham with read-only CVS pserver:
I'm going to start with some modest goals for the first iteration. Here's what the UI will look like:
I'm going to try to stay on the bleeding edge by using:
- Java 5
That might introduce some problems, I know. But that's the fun part. Here are some basic features and anti-features:
- user can add files to the file list
Durham itself I'd like to position as a general metadata API for Eclipse RCP application. I'm thinking of licensing that part under the EPL so that it's on the same license as the rest of RCP. AudioMan will be built on top of Durham and will probably be licensed under the GPL.
Discussion of Durham can take place on this blog. I'm thinking it will be more public than a mailing list and have better exposure. I'm starting off small for this first release but I'm welcome to more ideas.
# My Top Music List of '04
Since I haven't talked about music here in a long time, here's a list of my most listened to songs of 2004 with some help from iTunes' play counter. I listen to albums mostly so my top 50 songs wouldn't be too interesting because songs would be clumped together by album.
My top albums of 2004 are pretty obvious from the play counts:
Definitely recommend picking those ones up. Next are some singles that I really liked in 2004. I often omit band-released singles from lists like these because they are somewhat obvious and I skip them when listening to albums anyway to avoid overlistening to them.
What did you guys like in 2004?