I’ll be at Mashup Camp on Monday and Tuesday. Hope to see some of you there. If you want to meet up, e-mail me at chad at chaddickerson with the usual dot com at the end.
Technorati tag: mashupcamp
If the technology itself wasn’t cool enough already, check out that generous BSD license — “free for all uses.” Getting your hands on the Y! UI Library is incredibly straightforward, too. I just downloaded the zip file and the zip file unzipped with no funny business.
I always like playing with real examples, and there are plenty of those (these are just a few that caught me eye — there is much more and all these are backed up by detailed documentation):
All I can say is: have fun.
Although I’m not as engaged with the topics of software and services for the enterprise as I used to be, I’m still keeping up with what’s going on at Salesforce.com. I was a customer in my InfoWorld days and also wrote some nice things about their web services platform early on in its development. When it comes to APIs and “web as platform,” Salesforce has always been a trailblazer.
A recent post from Adam Gross on the sforce blog provides a glimpse of the mix of API usage vs. the web application itself and the numbers are really exciting:
. . . from our modest beginnings with Sforce 1.0, we’ve seen the Sforce Web service API grow to account for over 40% of all of salesforce.com’s total traffic. Think about that for a minute – the API is almost as heavily used as the salesforce.com Web application.
(A hat tip to Charlie Wood for pointing this out in his blog)
David Berlind is working on a simple but killer concept for an “unconference” he’s calling “Mashup Camp” (and he’s already got the domain mashupcamp.com, so it’s not just an idle idea):
My goal for Mashup Camp is to do the opposite of what all these other Web 2.0-esque conferences are doing. It won’t be invitation only. The pilot event will be modest in size guaranteeing intimacy and low or perhaps even no cost to attend (perfect for some of the people doing the real innovation on a low budget). And, it will involve a mix of open networking time, leader-facilitated discussions that address some of the most important issues and concerns that the API providers and the mashup artists actually need to work out, and fun (for example, a hottest mashup contest with an even hotter prize).
I think David’s concept nails a clear deficiency in some “Web 2.0” events: beyond all the talk about good ol’ RSS, there’s a deeper story about what’s happening in the broader world of APIs that is often glossed over. RSS is still important, but we need to expand the discussion. APIs are where the action will be in the coming months. The “mashup” theme broadens the discussion in all the right ways without losing sight of the technical guts that make everything work. I think the mashup concept is also something both business people and API providers can get their heads around. It’s a nice hook.
If you want to help David put this together, be sure to read the rest of his post about the idea drop him an e-mail. (Full disclosure: David is a friend from my InfoWorld days, but knowing and talking to David about this just makes me even more enthusiastic about the idea.)
(Technorati tag: MashupCamp)
Back in my old gig, I wrote a feature-length story entitled “Top 20 IT Mistakes” and wrote a followup blog post in which I referenced the excellent Facts and Fallacies of Software Engineering by Robert Glass, writing:
The book contains 55 facts ranging from the people-specific (“Fact 1: The most important factor in software work is the quality of the programmers”) to more specific rules of thumb about the process (“Fact 21: For every 25 percent in problem complexity, there is a 100 percent increase in solution complexity”). There are also 10 fallacies (e.g. “Fallacy 3: Programming can and should be egoless”). Both the facts and the fallacies are organized in a uniquely readable way — each one is a self-contained unit (cross-referencing the others when appropriate) that is divided into “discussion” (an outline of the collected wisdom behind the fact or fallacy), “controversy” (a description of why it is controversial), “sources” (a discussion of the source material available on the subject), and “references” (a traditional bibliography for that particular fact or fallacy).
These days, I’m thinking more about platforms than avoiding IT mistakes, and Glass’ book has helped clarify my thinking once again. Recently, I was thinking about what made a technology a “platform” technology (particularly in the context of the Web 2.0 “web as platform” concept) and I had decided that the platform test was simple: if a piece of technology served two or more separate systems, then it’s a platform, so platform technologies should be designed to do that. With that in mind, I looked into Glass’ book again and this time, Fact 18 suggested that my minimum was one short:
There are two “rules of three” in reuse: (a) It is three times as difficult to build reusable components as single use components, and (b) a reusable component should be tried out in three different applications before it will be sufficiently general to accept into a reuse library.
This sort of language seems very particular to writing code libraries/modules for use inside an organization, but I think the thinking clearly extends to web services that are intended to be “platforms.” Glass goes on to say that the skill set and approach required in building reusable code (and therefore “platform” code in my mind) is unique:
It is no wonder that knowledgeable experts say it takes three times as long. It is also worth pointing out that, although most people are capable of thinking about problems in a generalized way, it still requires a different mindset from simply solving the problem at hand. Many advocate the use of particularly skilled, expert generalizers.
The second rule of thumb is about being sure that your reusable component really is generalized. It is not enough to show that it solves your problems at hand. It must solve some related problems, problems that may not have been so clearly in mind when the component was being developed. Once again, the number of three — try your component out in three settings — is arbitrary. My guess is that it represents a minimum constraint. That is, I would recommend trying your generalized component in at least three different applications before concluding that it truly is generalized.
Those three applications don’t have to be huge, of course, and not all companies even have three products, but the “rule of three” seems reasonable when you’re thinking about building platforms. Maybe you won’t build those three apps to leverage your platform immediately, but you better be thinking about what those three apps might be.