Archives

Music and the web have a long history, from Napster through the iTunes Store to the MP3 blogs of today. For Web 2.0 hackers, however, the availability of public APIs proves pretty hit or miss. Cool mash-ups do exist – for instance, TuneGlue MusicMap, which provides nice visualization to data from Last.fm and Amazon. But lots of the big music databases don’t offer public web services. Indie download site eMusic used to, but stopped, while big commercial entities such as Muze and the All Music Guide keep their data stores proprietary and pricey. (Full disclosure: I frequently write freelance music reviews for AMG’s sister site, the All Movie Guide.)

If you do a little hunting, however, you’ll discover lots of web services that deliver powerful music content. Licensing terms vary, but the following 15 links should provide enough content to power tons of cross-pollination:

Besides providing a useful tool to other developers, my chief interest in taking over Brad Neuberg’s Really Simple History was to test the limits of my own JavaScript and browser-hacking skills. Version 0.6 was basically a maintenance release designed to acquaint the library with the browsers that had come of age since its initial 2005 release. The forthcoming 0.8 will be more of a redesign, adding new functionality while taking advantage of more modern JavaScript programming idioms. Lazy function definitions will improve performance, while closures and internal functions will lock down several methods that are currently public but need to be private.

Andrew Mattie is also hard at work modernizing his own Ajax history library: dsHistory, which just came out with a new release. I’ve been playing around with dsHistory, and I have to say I’m impressed. The differentiating feature of Really Simple History is its ability to maintain history states even after the user navigates away to other sites and back again. The unique thing about dsHistory, however, is its ability to bind the back button to arbitrary JavaScript functions without touching the URL fragment identifier. It’s always interesting to see how other developers solve the same problems, often by slightly reframing them. Their differing outlooks make the two libraries suitable for different audiences, but there’s also a lot of common ground.

The endless hand-wringing over browser version targeting in IE8 illustrates what’s wrong with the web standards community. For every sane, rational discussion about the practicalities of future-proofing the web, we get a couple knee-jerk anti-Microsoft screeds and at least one accusation that A List Apart – the standard-bearer of web standards – has somehow sold out by signing on to Redmond’s plan.

First, a little background: Howls of protest echoed across the ‘net a few weeks ago when Microsoft announced that Internet Explorer 8 would implement a new type of meta tag to enable both forward and backward compatibility in web pages. Once IE8 is out, users will be able to target rendering of their pages to a specific version of IE so that changes to the rendering engine of IE9 (or IE10 …) won’t subsequently "break" those pages. Basically, from IE8, onward, Explorer will include multiple rendering engines and display individual pages based on the browser version targeted by this new meta tag. The markup will look something like this:

<meta http-equiv="X-UA-Compatible" content="IE=8" />

I have no interest in debating whether or not it’s "semantic" and "standards compliant" to include the name and version number of a specific user-agent in my markup. That’s already been debated to death (on the 200,000+ pages Google currently reports for the keywords "IE8 meta tag"). What I want to know is this: Will Microsoft’s move make my job as a web developer easier or harder? At this point, the jury’s still out, but I think the answer is probably "easier."

ARCHITECT, n. One who drafts a plan of your house, and plans a draft of your money.

Ambrose Bierce, The Devil’s Dictionary

I’m a faculty brat and have a certain idea of what it means to be a professor. Both of my parents are Mathematicians, so I thought that they did research largely on their own and occasionally mentored graduate students on their way to earning a Ph.D. When I met my wife, she was studying with the renowned spectroscopist Takeshi Oka. To me it seemed a very different way to be a professor — he had maybe a dozen post-docs and graduate students toiling away in labs — it just didn’t seem possible that he could also be involved with day-to-day research.

In fact he was very involved, spending time with each graduate student and post-doc, mentoring them and strongly influencing the quality and direction of the research. I’ve seen other professors over the years, in physics and in biochemistry, with much bigger labs, with dozens upon dozens of collaborators. Those professors are really just administrators, writing grants and managing office space and payrolls. Put a scientist in charge of a large organization and they cease being a scientist. As it turns out, I think Professor Oka had the size of his team — a dozen — about right. Just as in Agile software development, too large of a team becomes unwieldy and decreases productivity and quality.

So, what does this have to do with architects? Some people have asked me why we only advertise developer positions and no architect positions. First, I don’t believe in title inflation. “Architect” is most times another way of saying “senior senior developer.” Second, the software architect who ponders how to design applications and how they should be hooked up to an enterprise software ecosystem is a creature of the enormous corporation. I’ll concede that you may need one or two of these rarefied creatures in a company of tens of thousands, but not a department of dozens. I’ve seen that in action. That’s the sort of company that generates five year plans, runs their business like the Soviet Union did, and throws software products over the wall to more nimble acquisitions at the first opportunity.

So no, we don’t hire architects. We hire developers. In a small team, there is no room for management deadwood. Everybody pays their own freight. The more senior you are, the more you get to help and coach and mentor others. Leading means enabling others to do their job and make good decisions on their own, not cutting their food and handing off work.

If you’ve made the transition from a hierarchical environment to an agile, self-organizing team, you know what I’m saying. You won’t ever want to go back.

Technorati Tags: agile, developer, architect

Chicago isn’t Silicon Valley, so it’s always interesting to see tech start-ups putting down roots in Midwestern soil. Last night I hit the launch party for Mpayy, a mobile payment start-up that launched just last week. Over a hundred prospective customers, potential investors, and tech and banking professionals hit Fulton Lounge for cocktails, networking and, of course, a product demonstration. Afterwards, I chatted via email with Trace Johnson, Mpayy’s product VP, about the launch, the company’s future, and the state of Chicago’s entrepreneurial culture. (Full disclosure: Johnson and I were once colleagues at Orbitz, one of the Windy City’s big tech start-up success stories.)

Agile Ajax: First off, can you tell me the basics about Mpayy? What’s the one-minute pitch?

Trace Johnson: Sure, but there are different pitches for consumers, online merchants and mobile merchants:

• Consumers get online and mobile payment processing. Shop online or send money to your friends from your checking account for free and get cash back when you buy.
• eCommerce companies get a secure payment solution with 0% fraud liability and they save 40-50% vs. credit card processing.
• Mobile merchants – taxis, fruit vendors at a farmer’s market, Avon ladies, shirt vendors at a concert – get turn their mobile web enabled cell phone into a retail point of sale system.

It’s been a while since the last installment of JSONP. Lots of good stuff has happened in the meantime to make our lives easier, but some things are still brutish, ugly and complex. One of the nice things in the more recent version of the JDK is the ever improving support for XML processing. Long gone are the days when you had to hunt around for libraries and hope that your version of the JDK worked with your third party libs. There are still reasons, like performance and extended features, that would cause you to pick an alternate library, but if you just want to add a little bit of XML processing into your apps, things couldn’t be easier.

Chris Jones of YesMail has written a pretty slick rolodex widget (see the Google groups thread about it).

Right now the animation images are generated by hand, but with a little bit of Java 2D, this can happen at compile time. You can kind of see some of the issues here of Flash v.s. DHTML. Flash has all sorts of image transformation goodness, while DHTML is a little handicapped here. You could use something like Reflex instead of compile time image transformation, though I haven’t tried out how well it performs when animating.

Anyhow, nice work Chris. It’s nice to see folks pushing the boundaries of what one can do with DHTML widgets.

Technorati Tags: ajax, gwt, yesmail, widgets

In many development processes, team members are organized by functional group. A project might have a team of developers building the code, and then down the hall or across the globe, a separate team of designers working on the visual and usability aspects of the application. The two sub-teams are walled off in their own silos, and communication between the two sides is minimal.

This structure is not compatible with an Agile software process — it’s too hard to get rapid feedback between the teams that make a process truly Agile. Worse, if the two teams are separated, the odds that they will have a common conception of the project, or even a common set of terms for discussing the project.

The most important step in tearing down the silos in your project is just switching your mindset from function-based teams to project-based teams. Continuous integration spreads from being just something the developers do to a way of making sure that all aspects of the project are in synch.

At the most basic logistical point, the designers and developers should share a common code repository. There’s a certain amount of overlap in the tools used for web applications on both sides. If designers can see the latest version of the application when making CSS or HTML changes, then developers can see those changes and work with the most current design as quickly as possible.

In order for this structure to work well, each side needs to move out of its silo and toward the other. Developers need to have an awareness of usability and design issues, and be able to discuss potential problems with the designers. Developers also need to be willing to do any rework that will be needed as the design changes.

Designers need to be willing to work at least some of the time in the developer toolkit, working with source control, able to make CSS or HTML changes directly in the code files (even better if the designers and developers can make it easy to make tweaks at the JSP or ERB level). Not everything that a designer does can be captured this way, but using common tools and files where available increases the team’s ability to work together. Sharing knowledge makes the team more able to notice potential problems, and makes teams more stable over time.

Last week, I wrote about how a user proxy can help integrate Agile and User Experience Design.

Once again, let me mention the upcoming book Professional Ruby on Rails. Available mid-February.

I’m still absorbing the densely packed information from "Ajax Security," the first-rate book by Billy Hoffman and Bryan Sullivan that I recently recommended in these pages. Here, in no particular order, are three of the most surprising lessons imparted by Messrs. Sullivan and Hoffman:

Web aggregators and SSL

This is probably a great big "duh" to some developers, but web aggregators such as iGoogle and NetVibes often compromise the security of otherwise SSL-encrypted web applications when funneling content from them to your personalized homepage:

Now, consider what happens when you use a Gmail widget on an aggregate site like NetVibes. Sharp-eyed readers will notice the URL for NetVibes … is http://www.netvibes.com. This is not an encrypted connection! NetVibes sends user data in the clear from the aggregate to the user…. NetVibes makes an SSL connection to Gmail, and then NetVibes degrades the level of security by transmitting the data over an unencrypted connection. Our attacker … can steal the data much more easily now. NetVibes is not providing the same level of security that a user would receive if he accessed Gmail directly. This situation is not unique to NetVibes and Gmail…. At the time of publication, every major aggregate Web site the authors examined downgraded security on data from secure sources. [emphasis theirs]

Last week I posted my interview with Stephen Lau, developer evangelist for the Songbird open-source music player. Afterward, I had some follow-up questions, which appear at the bottom of this post.

During my conversation with Lau, he tipped me off to the imminent launch of a new music service that would be white-labelling the Songbird core. The accouncement came this weekend from new peer-to-peer download service Qtrax, which promises major label-approved P2P access to a music catalog of 25 million tracks. The Wired News report on Qtrax provides plenty of interesting background information. But now UK newspaper the Guardian is reporting that Qtrax’s music-label support is far from final.

As the music labels continue their quest to usurp the iTunes monopoly, it seems like Qtrax would have as much leverage as any other alternative distribution channel. It’ll be interesting to see how this plays out. In the meantime, here are our follow-up questions to the original interview with Stephen Lau