I own two standalone MP3 players, both bought largely on the basis of price. I don't listen to music much (I generally find it a distraction that gets in the way of my thinking), but I am keen on listening to what are now tending to be called "podcasts". I have found some problems, though, and I'm wondering if it's just my poor choice of player, or whether all MP3 players are the same.

My problem stems from the length of many podcasts. Typical enclosures from IT Conversations or RSS radio shows such as Thomas Edison's Attic are often an hour or so long. Unfortunately, my time is not neatly divided up into one-hour slots, so sometimes I only have time to listen to part of a podcast. For example, a few weeks ago I went to have a haircut. Sometimes I can get seen straight away, but usually there is a queue of two or three other men waiting ahead of me. I had planned ahead and loaded up a bunch of IT Conversations. I got about 90% through one of the shows when it was my turn for the chop. So I paused my player for the 15-20 minutes it took.

When I came out, I picked up the player again, to find that it had "timed out" from pause. When I pressed "play", it started the whole hour-long track again. I was so annoyed that I have never bothered to try and find what was at the end, even though I was enjoying listening to the first part. This kind of behaviour is no big deal with short tracks like most music downloads, but it can make or break podcasts.

I've tried looking at manufacturers specs, but this sort of behaviour is not something that's ever mentioned in feature lists. Even though storing the precise track and position where a player was stopped or paused should be trivial in a flash-based player. After all, it's natural behaviour for any old tape-based walkman!

If anyone reading this has had similar problems, or knows of any players that get this right, I'd appreciate a comment or email. Thanks.

I just read an article about REST vs SOAP in Joel's Cup o' Java. In general it seems a reasonable (if simplistic) treatment of the advantages of a REST architecture.

The bit I have problems with is where Joel follows:

Say you've got customer 99 in a database, and a client that wants to retrieve customer 99 via your REST service. The client sends an HTTP GET to a URL like this one:
http://ws.joelsburgerhut.com/Customer/99

with this:

I avoid 50 versions of the same method... getCustomerByID, getCustomerByFirstName, getCustomerByMotherInLawsAddress, getCustomerByFavoriteVacationSpot....

Code running behind a REST interface doesn't magically gain any insight into what the client code needs. If the REST client wants to find out all customers who like to spend their vacation time in the Norfolk Broads, there still needs to be some kind of getCustomerByFavoriteVacationSpot, and some way mapping the request to a REST URL. Call it what you like, the method will still need to exist. If your application needs to make those 50 different types of request, your server still needs to be able to recognize and process them.

Or have I missed the point of what Joel was trying to say?

My software development and expert systems students are also currently facing an assignment deadline for a web design module. This means that I've been getting the tail end of their frustration in the form of "why doesn't this work" questions during my classes. It seems that Robert Niles and Dennis Jerz are also ruminating about this topic.

Our web design course uses Dreamweaver. Although I have a copy of Dreamweaver that came with Macromedia Studio, I've never used it beyond clicking buttons to see what happens - I create all my own web sites using a text editor. One upshot of this difference in approach is that I can often spot what's wrong with the generated HTML, but remain baffled by why/how Dreamweaver decided to make it that way.

To give a concrete example. A student came to me with the following problem: He had added an applet to his page design, and wanted it to appear in the corner of all the pages on his site. If he opened a page directly with a browser the applet appeared, but if he went there using a button from another page in the site the applet was missing. He was baffled. I saw the problem by simply looking at the address bar of the browser - clicking a button took the browser to a completely different URL. Examining the HTML "page source", showed that the links attached to the button images were to hard-coded absolute URLs. Getting Dreamweaver to use sensible relative URLs instead was strangely tricky.

The difference between relative and absolute URLs is one of those details that using a page-generation tool hides from you. But without the knowledge of such details you can't build a mental model of the system, and will find it very hard to predict behaviour or fault-find problems. This might be OK if the business need is to get a "one off" task done with the minimum of learning, but in an educational context it's crazy. The learning experience is the whole point of attending the course, and hiding the details doesn't seem to help that aim.

While trying to think of analogies for this, it occurred to me that this is a problem often faced by computer courses, but resolved long ago in other disciplines. Teachers and students accept that they will not really need to dissect a frog, or solve quadratic equations, or whatever, in the great majority of workplaces. Yet these kinds of tasks are done as learning exercises to help gain understanding. Surely the extra effort of hand coding web pages is an equivalent exercise.