« December 2004 February 2005 »
blog header image
# 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?

posted at January 29, 2005 at 06:51 AM EST
last updated December 5-, 2005 at 02: 2 PM EST

»» permalink | comments (3)

# 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 rel="nofollow" attribute.

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 rel="nofollow" to comment links. We'll see how well this technique works.

posted at January 19, 2005 at 01:26 PM EST
last updated December 5-, 2005 at 02: 2 PM EST

»» permalink | comments (5)

# 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.

posted at January 15, 2005 at 05:55 PM EST
last updated December 5-, 2005 at 02: 2 PM EST

»» permalink | comments (1)

# 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).

posted at January 14, 2005 at 07:16 PM EST
last updated December 5-, 2005 at 02: 2 PM EST

»» permalink | comments (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.

posted at January 13, 2005 at 01:20 PM EST
last updated December 5-, 2005 at 02: 2 PM EST

»» permalink | comments (8)

# Properties Get More Difficult

Properties used to be simple. They used to be just a name and value pair, like these:

firstName = Ryan
lastName = Lowe

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:

description="" (blank)

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. ;)

posted at January 11, 2005 at 03:29 PM EST
last updated December 5-, 2005 at 02: 2 PM EST

»» permalink | comments (3)

# 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:

File List
Properties view

The File List view will just be a JFace ListViewer. The user adds one or more files with a File Open dialog. This dialog opens from the File --> Add Files... menu item.

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

id3v2.artistName   |   Sugar Ray

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.

posted at January 10, 2005 at 03:56 PM EST
last updated December 5-, 2005 at 02: 2 PM EST

»» permalink | comments (0)

# 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:

  1. Make the Quick Edit Perspective (picture), with the File List view and Properties view. I need help here because I don't know much about Eclipse/RCP perspectives and views, though I do know a good amount of SWT/JFace
  2. Re-arrange the existing id3v1, id3v2 and MPEG libraries (from AudioMan 1) for Durham's API, which leads to...
  3. Make an initial API for Durham for metadata plugins, preferably based on Eclipse plugin extension points, which I don't know how to do yet

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.

posted at January 06, 2005 at 08:46 AM EST
last updated December 5-, 2005 at 02: 2 PM EST

»» permalink | comments (2)

# 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.

Mr. Lowe, an Ottawa software engineer, did not recieve bills for several months from Bell Canada's wireless arm. When the company finally sent him a bill two months later, he discovered he had been overcharged him[sic] for one month of services.

After months of back-and-forth discussions with Bell, Mr. Lowe, 26, said he was finally able to settle the matter with the company in October.

"It was six months of unnecessary hassles," said Mr. Lowe

...and the article continues, talking about the botched software upgrade from Amdocs. I like how Amdocs uses CMM Level 3. Didn't really help them here.

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.

I didn't have "discussions" with Bell Mobility. I've blogged my experiences already -- in an original post followed by an update and then a second update. It's not too hard to follow my story.

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.

posted at January 05, 2005 at 08:19 AM EST
last updated December 4-, 2005 at 15: 1 PM EST

»» permalink | comments (3)

# 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.

posted at January 04, 2005 at 05:25 PM EST
last updated December 5-, 2005 at 02: 2 PM EST

»» permalink | comments (4)

# 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:

repository path: /usr/local/cvsroot
user: anonymous
password: password

I'm going to start with some modest goals for the first iteration. Here's what the UI will look like:

File List
Properties view

This initial UI will be part of Durham project as the Quick Edit Perspective. The (track) Browsing Perspective that was the UI for AudioMan 1 will come later.

I'm going to try to stay on the bleeding edge by using:

- Java 5
- Eclipse 3.1 milestones as they are released
- RCP plugins from the 3.1 milestones

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
- the file list isn't persisent
- the properties view is a list of all of the metadata properties in the selected file
- only one file can be selected at a time
- MP3 id3v1 and id3v2 is supported
- OGG could be supported, but read only
- read only files have all read only properties
- display MPEG data (ie. bitrate, track length) as read-only properties

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.

posted at January 04, 2005 at 04:41 PM EST
last updated December 5-, 2005 at 02: 2 PM EST

»» permalink | comments (3)

# 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:

The Stills: Logic Will Break Your Heart
The Killers: Hot Fuss
Interpol: Antics

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.

Audioslave - Show Me How To Live
Billy Talent - Living in the Shadows
Billy Talent - This is How it Goes
Broken Social Scene - Looks Just Like the Sun
Death Cab for Cutie - The Sound of Settling
Doves - Crunch
Evening - Vieux Finder
Franz Ferdinand - 40'
Franz Ferdinand - Take Me Out
Groove Armada - Easy
Hail Social - Get in the Car
Hail Social - Track 01
Hot Hot Heat - Touch You Touch You
Hot Hot Heat - No, Not Now
Interpol - Narc
Interpol - C'mere
Jane's Addiction - True Nature
Jimmy Eat World - Pain
The Killers - Believe Me Natalie
The Killers - Smile Like You Mean It
Mae - All Deliberate Speed
Mae - This Time is the Last Time
Modest Mouse - Bury Me With It
Muse - Hysteria
Muse - Stockholm Syndrome
Muse - Falling Away With You
Pilate - The Travel Song
Projet Orange - Tell All Your Friends
Sam Roberts - No Sleep
The Secret Machines - Sad and Lonely
The Secret Machines - The Road Leads Where It's Led
The Shins - Mine's Not a High Horse
The Shins - Young Pilgrims
The Shins - So Says I
Snow Patrol - Somewhere a Clock is Ticking
Starsailor - Bring My Love
The Stills - Still In Love Song
The Stills - Changes Are No Good
The Stills - Of Montreal
The Stills - Lola Stars and Stripes
The Stills - Gender Bombs
The Stills - Love and Death
The Strokes - Reptilia
The Strokes - What Ever Happened
Teitur - Shade of a Shadow
Thornley - Bright Side
Thornley - Come Again
The Tragically Hip - Gus: The Polar Bear From Central Park
The Used - Take It Away
The Used - I Caught Fire (In Your Eyes)
The Used - Let It Bleed
The Yeah Yeah Yeahs - Y Control
The Yeah Yeah Yeahs - Maps
Yellowcard - Only One
Yellowcard - Empty Apartment

What did you guys like in 2004?

posted at January 03, 2005 at 06:19 PM EST
last updated December 5-, 2005 at 02: 2 PM EST

»» permalink | comments (5)

Search scope: Web ryanlowe.ca