Amazon MP3 have a download limit

Note - the Amazon free MP3 downloads have a limit per-song. Something like five downloads. So you had better use a caching client or manually download and store the songs. Linking is going to break. (I'll go talk to some people and make myself annoying.)

Compulsory License for cover songs

Cool - this note on Digital Distribution shows one way for digital music to be freely distributed - just get a band together and perform it and record it. I wonder if there will soon be Internet scale competition of cottage-industry scale musicians for covers of classic or well known songs.

If you record a cover version of a song, (meaning your performance of a song that has been released in the U.S. with consent of the copyright owner), you are entitled by law to release your recording commercially, and the owner of the copyright to the song cannot prevent you from doing so.

Webjay - "Amazonia" by mdierken

This WebJay thing Lucas has cooked up is pretty cool. I finally figured out how to integrate with Amazon - they have free downloads of great songs. So... check out "Amazonia" by mdierken - my playlist.

(I just love Alison Krauss)

Microsoft Money users locked out

Ouch. Looks like MS misconfigured an authentication server and many MS-Money users were locked out on Monday - and continue to be locked out of their own files. I like the fact that they are talking in the open though.

Saw this on a Microsoft newsgroup:

Here at the Money team we are sorry that we have caused this problem, and we are working as quickly as possible to fix this unfortunate situation.

Let me take a moment to explain what the Money team is doing about this problem. First, let me assure you that none of your financial data has been lost, and none of your personal information has been compromised. In fact, the result of the situation has been that your information has been locked up more tightly.

Can't wait till everybody is doing Web Services...

Schneider on BEA

Jeff Schneider has a very cogent piece on Bosworth and BEA :
He also says something interesting about service oriented architectures that I'll need to think about:

Here are a couple more things to chew on:

• web services and service networks increase the complexity of the enterprise I.T. stack


• the more moving parts there are the more it costs to bring them together


• not all buyers need the same level of complexity (if only we had J2EE Beginners version, J2EE advanced version, etc.)


• service oriented infrastructure will be most beneficial to very large I.T. shops


• if you refactor software out of the application and into the network, you should be able to reduce the development and integration time - if you didn't; you failed.


• Remember - dBase, PowerBuilder and ColdFusion. Developers like when you make them look like rock stars - give them the tools to beat expectations.

History of XML, abridged

Doing some research on XBRL and came across this gem from XBRL: Implications for the Accounting Industry:

The beginnings of XBRL can be traced to the early 1990s when an engineer discovered that HTML (Hypertext Markup Language) was not adequate for all uses.

Bosworth Leaves BEA for Google

Wow - Bosworth Leaves BEA for Google - I actually think this is a big deal. But who is going to champion disconnected use and HTTP servers on the desktop/laptop/palmtop for us?

This is quite the shift - not just one person moving between companies, but a shift from a 'product' company (write software to sell) to a 'service' company (operate software used every day). I wonder what other big 'software service' companies are out there and hunting up talent.

Was it just two months ago he commented on Google's GMail and said Google is clearly trying to think outside the box? Does this mean BEA isn't?

Programmatic access to XML data

Mark makes a nice connection:

Ninety-nine out of a hundred developers would have made this an object or a set of function calls; instead, Kimbro Staken has us treating XML as a data structure. This is a subtle but important difference with echoes of RESTfulness

I also like the code snippet example he has bridging low-level code and network requests.

Rifkin riffs on Personal Servers

In Personal Servers and Information Clients, 2004 Adam revives hope for an HTTP server on every desktop...

It's been about a year since I've thought about personal servers and Web Services Intermediaries and Mojito, and now that I'm spending a lot of time with Rohit I'm starting to think about them again.

Da boyz are at it again.

Main Page - SeattleWiki

A friend from work has set up a SeattleWiki which is very cool looking. All local Seattleites should check it out.

TIBCO's RFID strategery

TIBCO's RFID strategery (via ADTmag.com via mod-pubsub)

Clearly, in the RFID world the killer apps will be written by the companies themselves because they would understand their business better,” Pandya told Application Development Trends in a recent interview. Those in-house developers have the infrastructure and access to information to actually create those killer apps based on the standards for RFID and companion technologies such as Web services, he noted.

I think you can effectively strike out mention of RFID - the actual point is that killer apps can and will be written by in-house developers.

Here's something interesting about RFID (which I know nothing about but probably should learn Real Soon Now):

"The thing with RFID is that if you keep it very simple, all you know is what, where and when,” Pandya said. “But what that means is that I know nothing about why. The critical information around why doesn’t exist.”

GMail inbox URIs showing up in HTTP referrer headers

Oh, this is interesting. When I was browsing Dare's comments area on his blog that avoided deciding whether XmlTextReader is or is not compliant with the spec (or behaving merely 'by design') I notice a bunch of wacky URIs like these:

• http://gmail.google.com/gmail?view=cv&search=cat&cat=Mono-devel-list&th=fdc3c2ea6e52696&zx=e20c659d877b0e4e1611868589 [Referral]


• http://gmail.google.com/gmail?view=cv&search=cat&cat=mono&th=fdc40f131e1b3cf&zx=9937ac711a81292a1129829958 [Referral]




This doesn't look limited to GMail, but I'm curious about whether there are Web apps that approach security through obscurity and are getting exposed because of it.

eBay and downloadable music

eBay plugs into digital-music market (CNET News.com) - Oh yeah, I can see where this is going... It's all about DRM or avoidance of DRM.

Under the pilot, eBay said the actual transaction between buyer and seller will be executed on a Web page controlled by the download vendor, which will be co-branded by eBay. The company specifically stated that individuals buying music would not be allowed to relist or resell any content they purchase through its auctions.

Drop our RPC battle axes

Werner Vogels says:

To build scalable systems we have to step away from what our programming preferences dictate us and involve ourselves in a thinking adventure about how components really need to and can interact on a global scale. I have read many papers and articles on this topic, but I consider Pat Helland almost be the only person who really graps what the complexity of enterprise systems design is going to by like if you really need to scale systems. See for example his "SOA is like the night sky" article. This is the kind of visionary thinking that should motivate all of us to drop our RPC or multicast battle axis' and start thinking about how large systems really should look like.

Amazon still hiring like crazy

Amazon is on a recruiting spree, which is wonderful thing. Right now I'm only doing a handful of phone screens and interviews a week, but my boss is doing probably two or three times that. Recently he went on a recruiting trip to Texas - came back with one hire.

We have a pretty nice 'pipeline' for recruiting, but there is a lot of competition for incoming resumes. We've gotten in the habit of checking the page that lists the recent candidates two or three times an hour - a new resume doesn't last for more than an hour or two before being tagged by other groups. After two groups tag the person, they are out of the pipeline, so we have to be quick.

The 'bar' at Amazon is pretty high which is both good and bad. We've been self-educating ourselves on interview skills. As many people are seasoned engineers, they've been through phases of hiring at other companies and are somewhat familiar with the process and what to look for. There are also some good resources for engineer-types - like The Guerrilla Guide to Interviewing. This is a good guide to the kind of hiring Amazon is doing.

 
 

Here's a good article on using GMail from Boxes and Arrows.

One interesting thing in GMail is the SLAT principle - Star it, Label it, Archive it, Trash it. This is very similar to the advice from a 'personal productivity' book that I bought earlier this year Getting Things Done, by David Allen. Part of the advice from that book dealt with the day-to-day process of managing and organizing email.

Something else I noticed is the threading that GMail does. This is similar how the latest version of Outlook automatically organizes message. I really enjoy it and believe it helps keep my mail organized at work.

Here's a good real-world Web developer question about sessions, cookies, etc

Hi. I'm an e-commerce developer for a couple web sites. We have long
been bugged about the whole issue with session ids. It seems that too
many of our visitors are simply turning things like Javascript and
Cookies off. Javascript we can live without. Cookies is another
issue. So we developed the system to not rely on cookies. Now wherever
you go on our site, a session id follows you via the url. While this
seems to work, it just isn't pretty. I've checked out Amazon and a few
others and they use the same technique.

This got me thinking that some REST-aware folks might want to join the mailing list and start fielding questions or concerns near the protocol and Web architectural level - but without being preachy or presenting a "you just don't understand" attitude. It would be nice to see someone say "Well, let's see what happens if we do it that way..." discussion.

I noticed the WHAT-WG last month and was initially interested in seeing some simple advancements in HTML happen in my lifetime. More and more people are talking about their approach - some positive, some negative - and I hope the hyped expectations don't get out of hand. It'll be a tricky balance between adding user interaction control and consistent and commonplace implementations. The next milestone will be a response from Microsoft, and after that actual participation from Microsoft.

I'm not sure I actually want good ole HTML to have absolutely every feature discussed by WHAT-WG. I'd like to see the basic improvements that are pretty uncontroversial - slider bars for example and some of the forms handling ideas - taken up by the W3C. Maybe that was already tried and failed for some reason.

The Zen of caching by Lucas:

A half decent cache will still work when you're offline, the content goes away, or you don't feel like downloading! One difference is that the download and rename becomes invisible to the user. But the other, really crucial, difference is you can keep referring to a cached song by its URL, which allows you to share pointers to it with other people. If you cache rather than download, the song is still part of the web.

I like that - If you cache rather than download, the song is still part of the web. I had never thought of it so clearly, until Lucas said it so simply.

I just spent a nice evening with some friends and for a while talked about REST, but in a roundabout way. But the interesting thing was that on the way home, I explained all this to my nine year old daughter and she understood the fundamentals right away. For generic interfaces, the analogy she had was "It doesn't matter if you are buying cat food or dog food, you are still buying something." (That's because she knows I work at Amazon and buying is an important concept.) Another analogy she made was that the delete key on the keyboard works regardless of what you are deleting. It would be nice if professional programmers were so open minded in their exploration of large scale networked architectures and REST.

Dare Obasanjo is raining on the W3C parade...

Either way the primary mechanism the W3C uses to produce technology specs is to take a bunch of contradictory and conflictiong proposals then have a bunch of career bureaucrats try to find some compromise that is a union of all the submitted specs

Damn those career bureaucrats that built XML. Or is it the SOAP design process that caused the grief? And where did that technology come from anyway?

It seems many vendors amd individuals are realizing that the way to produce an innovative technology is for the vendors that will mostly be affected by the technology to come up with a specification that is satisfactory to the participants as opposed to trying to innovate by committee.

The 'many vendors and individuals' claim paints the community with a fairly broad brush. I know that 'rough consensus and working code' is the by-word of several organizations.
So, which particular groups are doing the 'learning'?

Also, what's with this 'vendor' stuff? This frames the whole software industry as an "offer-to-sell/offer-to-buy" community. Why is it against the rules for the users of the technology to come up with the innovations in that technology all on their own?

Ben Hammersley has whipped up a Google to RSS tool. I really need to get SearchAlert up and running again...

plasticbag.org talks about developing a URL structure for broadcast radio sites...

[...] I think the issue of how we map broadcast programming to web URLs is a really interesting one, and because I think we've done some good work here that other people might find useful or interesting.

Sharing is good - everybody, pay attention:

So the first thing to explain is that Radio 3's new site is particularly interesting and ground-breaking because it doesn't just have a page for every broadcast, it has a page for every episode. This is way cooler than having a page for every broadcast, but the full implications of it aren't immediately easy to digest. Basically it means that there would only be one page for any documentary no matter how many times that documentary is repeated. That one specific page then becomes the definitive home for that episode of that documentary on the BBC and all subsequent information or supplementary material that is relevant to that episode can be stuck onto that page at any point in time. Imagine it as being a bit like having an entry in IMDB for that particular radio episode. It's like creating the basis for an ever growing encyclopaedia of Radio 3 programming, and it should make it really easy to search for information about a programme without getting overwhelmed by dozens of versions of the same page, each containing little odds and sods of information, none of which are aware that they're all talking about the same thing.

As your lawyer, I recommend that your site do the same thing.

ARCHI-TECH Magazine looks cool. Love the font. And remember "... this magazine has been created specifically for architects and designers of high-tech buildings."

Lucas Gonze explains in more detail what's up (or not up) with mime types:

The reason this is needed is that figuring out mime types is hard enough that it requires specialists, and the specialists need to be able to draw on resources too big to be packaged as software. You can't package up a big database and related CPU to travel around the net. This is a job for a web service.
[...]
They have other responsibilities. The creator of a video has to know about cinematography and editing. The server operator has to know about routing and caching. The browser user has to know about their own job, whatever that might be. They have their specialties, I have mine. How can we work together?

I think that the question "How can we work together?" should be answered at the architectural level. I also believe that content should be tagged with its content-type - which implies that it is in a response or in a PUT or POST request. I think the problem is not one of architecture but in the realm of software tools, server configurations and application design (both client-based and server-based applications).

I'm not sure I undestand this statement:

The client and server need to be able to defer to my web app to find out what type of object it is, meaning that it has to be possible for me to coerce mime types of external objects.

From what little I know of WebJay (pretty neat idea), the server provides links to media which the client then retrieves - presumably to play in a media player. The issue seems to be that the 'industry' (the collection of low budget multimedia hosting parties) hasn't figured out multimedia and mime types - which is similar to the HTML scene ten years ago. Everybody knows to sent 'text/html' nowadays, but back then client apps tended to 'sniff' the content to guess at what should happen. Microsoft liked doing that because they know better than the content owners. They forget that the community learns and their software stays dumb.

Another wrinkle (I'm guessing) is the client to WebJay maintains a mapping of mime types to helper applications. This mapping isn't able to deal with wrong or unknown mime types - although I'm guessing that Internet Explorer probably still does some content sniffing and prompts the user with a best guess.

The goal of 'coercing the mime type' is intended to bypass or foil this client (i.e. web browser) behavior. Which is a losing battle since that is an area of security concern - and we all know how much Microsoft focuses on security in it's browsers.

Anyway - the answer while staying within the architectural boundaries are to clean up all the multimedia hosting servers, and have the multimedia clients do some content sniffing. Hmmm, perhaps a new mime type of 'audio/guess' could be used and have just everybody use it and let the client do the guessing...

MarkN talks about XML Language Bindings Done Right - nifty stuff. A friend I used to work with worked on some reference implementation stuff. Kinda makes me jealous, I love the mix of JavaScript and XML.

Lucas says something silly:

My conclusion is that the architectural principle behind mime types provided by web servers is wrong. Web servers have barely any more ability than the rest of us to guess content type, [...]

The design approach of server provided content types is an attempt to avoid guessing. Lucas' assumption that the server is or should be guessing is just plain wrong. If there is guessing going on, then the server should not provide a content type header in a response.

I just saw that Lucas saw my post I made & I apologize if what I said came off as flippant - reading it now I shouldn't have said 'silly' - that was unprofessional. Sorry.
My only excuse was that it was really really late...

Rohit got married and I missed it (was in Montana), but Tim blogged it. Congratulations Rohit! You two look fabulous!

Jeff Schneider points to a report that WebMethods is hurting in the stock price department - too bad, as they purchased a company last year that I used to work for and there are good people there doing good work (at least in the Portal division).