Yahoo! User Interface Library: amazing and free

In my very first days at Yahoo! working with the team that made the Local Events Browser demo using a bunch of Yahoo! APIs, I was really amazed at the Javascript/CSS talent assembled at Yahoo! As of today, a huge chunk of it is out there for anyone to use and the people who created all of it have started a blog. By any standard of openness, you have to admit that the release of the Yahoo! User Interface Library is incredible:

The Yahoo! User Interface Library is a set of utilities and controls, written in JavaScript, for building richly interactive web applications using techniques such as DOM scripting, HTML and AJAX. The UI Library Utilities facilitate the implementation of rich client-side features by enhancing and normalizing the developer’s interface to important elements of the browser infrastructure (such as events, in-page HTTP requests and the DOM). The Yahoo UI Library Controls produce visual, interactive user interface elements on the page with just a few lines of code and an included CSS file. All the components in the Yahoo! User Interface Library have been released as open source under a BSD license and are free for all uses.

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

Aside from the UI Library, there’s the Yahoo! Design Pattern Library and an article on Yahoo’s Graded Browser Support by Nate Koechley.

All I can say is: have fun.

Salesforce.com and API metrics

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.

Wow.

(A hat tip to Charlie Wood for pointing this out in his blog)

Mashup Camp: a cool idea

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

Platforms and the rule of three

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.

Syndicate Conference next week

The Syndicate conference is next week in San Francisco, and I think it’s well worth checking out. Last year, the conference was an interesting mix of traditional media types who wanted to know what all the RSS/blogs/syndication fuss was about along with the folks who were creating the new world. This year, Doc Searls is the conference chairperson, so you know it will be both thoughtful and entertaining. Here’s the schedule and how to register.

I’ll be there both days, so if you want to meet up, drop me an e-mail (chadd -at- yahoo-inc -dot- com).

(Disclosure: I am on the Syndicate advisory board, though not nearly as active as last year when I moderated two panels and wrote a bunch of the session descriptions.)

We're hiring: join one of the most innovative teams at Yahoo!

If you thought the Event Browser was kick-ass like I did, here’s your chance to actually work with the team that built it. Ravi Dronamraju is adding to Team Edison (a team he put together) and just sent this job description over:

Do you have what it takes to build, prototype, innovate? Are you the über-geek who can think in multiple programming languages? Do you write more lines of code than email? Well, come join Team Edison at Yahoo! As part of the Search and Marketplace organization you will get a chance to put your brain through daily exercise of creativity and innovation, laying the foundation for Web 2.0 and beyond.

Ideally you thrive in a team-first environment, enjoy problem-solving and learning new technologies. You should have MSCS or equivalent with 5+ years of experience in building Web applications. At the core, you can express yourself competently in any of the following: Perl, PHP, C/C++, JavaScript and CSS. Solid understanding of technologies like HTTP, Apache, RDBMS/MySQL, Unix is a plus.

I work very closely with this team, so if you’re interested in this role, send me an e-mail with your resume (and tell me what you like to do and why you want to join the team). Please put “Team Edison position” in the subject line. My Yahoo! e-mail is chadd -AT- yahoo-inc -DOT- com. (No recruiters or agencies, please.)

Job descriptions rarely do justice to a position, so here’s my informal scoop. . . this team is heavily-focused on API development, both internal and external, so the work itself really couldn’t be more fun. The team is also small and nimble (very much on purpose) — a great group to join if you want to have an immediate impact (just ask Ed, who started working on the Event Browser on his second day, I think). And Yahoo! really is a great place to work — I’ve been here barely over three months now and it’s a blast. Come join the fun.