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.

A coding Christmas

The holidays make me a little reflective, and this year I realized something about my career that really blew my mind — for the first time since 1994, I am not directly responsible for production code or production systems! I can’t recall any particularly ruined holidays in the past (except a vicious DOS attack on July 4th one year), but in my past work, there has always been at least the possibility that a major system would have a problem and I would be responsible for dealing with it (or at least making the dreaded call to the person on my team who would have to deal with it). Right now (though I am super-busy), I don’t even have root on a single system at work. I might be lucky in that regard this year, but I will raise a virtual glass to all the people who keep the systems running during the holidays. . . . you deserve our thanks. Here’s hoping that your pagers and cell phones are silent during this holiday season.

I’ll be using the holiday opportunity to catch up on some non-tech reading, movies, guitar playing, etc., but Im also planning to get some hands-on time with some of the geek stuff I’m been too busy to play with lately, namely: Greasemonkey (using Mark Pilgrim’s Dive Into Greasemonkey), the super-cool new JSON stuff we’re offering at Yahoo!, and some miscellaneous blog tweaks. Yes, “fun” comes in many different forms.

The efficacy of time-constrained hacking

Friday’s successful “hack day” experience is still fresh on my mind and a couple of blog posts popped up on my radar today that
reflected some of the philosophical underpinnings of our event. A post from David Heinemeier on the 37Signals blog (“Constraints breed breakthrough creativity“) pointed me over to Kathy Sierra’s post entitled “Creativity on speed.” I’ll quote the same section that David did because it’s so on the mark:

One of the best ways to be truly creative — breakthrough creative — is to be forced to go fast. Really, really, really fast. From the brain’s perspective, it makes sense that extreme speed can unlock creativity. When forced to come up with something under extreme time constraints, we’re forced to rely on the more intuitive, subconscious parts of our brain. The time pressure can help suppress the logical/rational/critical parts of your brain. It helps you EQ up subconscious creativity (so-called “right brain”) and EQ down conscious thought (“left brain”).

I totally agree, and I’m glad that Kathy stated is so well. I feel fortunate that early in my engineering career (both as manager and coder), I worked in environments (like a big sports site that I and my team built from the ground up) where we weren’t shipping software as much as we were shipping experiences around very specific — and totally inflexible — events. When you’re dealing with sporting events, you can’t not ship. The World Series, Olympics, and Super Bowl happen whether your code to provide the experience is ready or not. In that environment, I learned that sometimes you really have to ship. Sometimes there literally is no more time — no one is going to postpone the World Series because your code isn’t quite ready. I also learned that if you have the right team in place, the team often does its best work under this intense time pressure. That’s why I had a strong hunch that some really cool things were going to happen at our hack day, and they did. As David writes: “Don’t worry about having more time, build less software.” If you can’t build less software (e.g. you have to have scoreboards for the World Series), build what you have to build in the simplest possible way — another practice that was clearly in effect at our hack day.

The end of Kathy’s post suggests a compelling structure for a two-day hacking event that I’m going to file away for future reference:

It would be fun to see a combination camp where the first half of the weekend was about actually making something, solo or collaboratively, and the other half was about exchanging ideas with the other participants (including the things you made during the first half, and lessons learned).

Sounds like a great idea. . . .

(Also, don’t forget to read Kathy’s “Build something cool in 24 hours“)

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.

Term Extraction API and

One of the most inspiring backend pieces of the Event Browser for me was the innovative use of the Content Analysis Term Extraction API, which Ed describes in his post about the Event Browser:

One of the problems we had were that there were no images in our event feed. We knew we wanted to get images from either Flickr or Yahoo Image Search but it wasn’t immediately obvious how we would get an image from a phrase like “Highlights of the Textiles Permanent Collection at the MH De Young Memorial Museum”. It was another Yahoo, Toby Elliott, who suggested that we use the Content Analysis API and then Image Search. Honestly, I didn’t even know Yahoo had term extraction as a public API. To get the images you see in the demo I concatenate the title and venue to get the most important terms extracted and then use that as the image query. The first thumbnail gets used as the photo for each event. It’s really simple code on my end and all the real work is done by the term extraction service. My favorite example for images is the De Young Museum’s list of events.

I’m a total news and politics junkie (when I worked at several years ago, it was like giving an alcoholic a job in a liquor store), so last week I started thinking about how using a tag cloud to represent breaking news from a set of RSS feeds that I choose. Last week being a big news week, I envisioned a dynamic tag cloud where words like “Scooter,” “Miers,” and “indictment” would get huge in breaking news situations to tip me off that something big was going on at that moment.

I started digging around and was getting ready to sit down and write the code, but then I found, which uses (you guessed it) the Yahoo! Term Extraction API to produce a tag cloud built from RSS feeds you specify in an interface that is nicer than anything I could build quickly myself. No need to re-invent the wheel, so I signed up and had my tag cloud in a few minutes, using these feeds: Top News, Fox News (to be fair and balanced), MSNBC, NY Times home page, Washington Post top news, and Yahoo! Top News.

Here is the resulting tag cloud from those sources. offers a nice “stop words” feature so you can remove common (but useless) words from the tag cloud display. I specified “full story” and “story” as stop words, for example, but I also specified “white” and “supreme” because they were generally represented in the phrases “white house” and “supreme court” (terms which were preserved in the tag cloud even though I specified words within those phrases as stop words). (And check out their implementation guide for simple instructions on how to put your TagClouds on your site in badge form).

Displaying this tag cloud more dynamically in a Konfabulator widget would be cool. . . . has already done the difficult work using the Term Extraction API, perhaps the most underappreciated API in the Yahoo! API arsenal. Sounds like a fun project.

Super-mashup with Yahoo! APIs: event browser

Event Browser In my twelfth week at Yahoo! I’m really happy to be able to finally point to something I have been working on with a small but incredibly talented team of engineers and UI designers (a couple of them even newer than me to Yahoo!) Check out the Event Browser, a super-demo of a bunch of Yahoo! APIs, with the exciting new Maps AJAX API we just announced as the foundation (and if you’re not in to AJAX there are many more Maps APIs to play with).

Frankly, I’ve been getting a little bored with maps mashups in general. Most are just a new set of points on a map from some newly-liberated set of data, which is cool but not as exciting as it used to be. This mashup is different, though. Instead of a standard query interface, the map becomes the center of the experience and your browse movement on the map determines the events you see in a very dynamic way. As you move around on the map, events taking place within your map space appear to the right of the map. All this goodness is happening completely client-side, i.e. Javascript making REST calls. There’s also a dynamic tag cloud with event categories that re-draw themselves as you move around. Very cool.

One more cool thing (hey, did someone use the word “cool”?) The images displayed for particular events take Yahoo! events output and pipe it through our Term Extraction API, then through the Image Search API to produce amazingly appropriate images for the event. Ravi Dronamraju, who put together the team that built this demo, provides his thoughts on this demo. A big thanks to Ed, Jonathan, Mirek, Karon, Sam, Nate, and Toby.

It’s a great team, and working with them on this reminded me of the concept of the “jelled team” from the truly excellent must-read software engineering management book Peopleware, which I wrote about at InfoWorld:

The jelled team is so tightly knit that the whole is greater than the sum of its parts. There is low turnover, a strong sense of identity, a sense of elitism, joint ownership of products, and enjoyment derived from participation.

Can’t wait to do more.

Update: Ed Ho writes in a little more detail about how the demo works, and kindly gives credit to his teammates.

Berkeley-area doctors map mashup

Mashup screen I was sorting through some old papers and found one of those thick health care provider directories that you used to get when you started a new job with new health insurance. While most providers disseminate that information online now, the display of the information is often close to useless — you run a search and get dozens of providers back, and even if you can drill down by specialty, you’re still looking at a bunch of addresses with no sense of where they are relative to where you live. And who wants that kind of aggravation when you’re already sick?

To get ahead of the game (while I’m not sick), I created a Berkeley-area doctors maps mashup using screen-scraped data from my health care provider. I’m not a great interface designer, so it’s Web 1.0-certified, complete with frames. What the interface lacks in pizzazz, it hopefully earns back in simplicity: there’s a list of medical specialties on the left, and when you click on one, the providers that match that speciality display on the map in the window on the right.

Getting the data in shape was the hardest part, and required quite a bit of Perl elbow-grease with a little MySQL database design thrown in. From there, a little PHP hacking leveraging the Yahoo! Maps API and voila! That pediatric gastroenterologist that I hope you will never need is just one click away.

While the data part of this equation was difficult (it would have been WAY easier if this information was available via RSS), I think the utility of such an application made the data parsing worth it.

Bill Gates: The Udell Interview

Dan Farber offers high praise for Jon Udell’s recent podcast interview with Bill Gates, saying that “it really shows the geeky Gates, and is one of the better interviews I have read/heard in covering Gates for more than two decades.” I agree (though I haven’t been following Gates for two decades yet myself). I listened to the podcast and enjoyed exchanges like this one (a big thanks to Jon for putting up a transcript — but you should listen anyway because a transcript doesn’t do justice to the palpable geeky excitement in Gates’ voice):

JU: Yeah, somebody had a nice quote that RSS is the human face on Web services. I kind of like that a lot and related to that is something that I’ve said a few times, which is that human beings are the exception handlers in all workflows. And so…

BG: Absolutely. That’s a really good way of capturing something I was saying about the boundary between structured and unstructured. Eventually you’ve got to know who in what role and how to communicate to them, because if software could just talk to software, we could get rid of all the humans. Everything that’s real, eventually there’s a human involved in. And there is a little bit of tension between very interpretive, simple-to-create stuff, like REST or POX, and very structured, tight stuff like Web services. And if the industry is smart, we can get the best of both worlds, where things that are not very complex, you just want to go get a stock quote, a weather thing, fine. Use REST. Even, you know, go to Wordpad and type in the ugly URL.

If this interview was a book, it would be much closer in spirit to an O’Reilly title than the relative fluff we got from Bill Gates in The Road Ahead, a book that surely helped thousands of businessmen achieve deep sleep on airplanes back in the day.

Site to watch:

I just subscribed to the blog, described by the site’s creator (John Musser) here:

So what’s the point of this site? Although still euphemistically ‘in beta’, the goal is to create a home page for Web 2.0 developers. Content to include news, reviews, comparisons, and examples. Formal APIs, unofficial APIs, and accidental APIs are all fair game. Anything ‘programmatic’ that’s publicly accessible online from sources including Amazon, Google, eBay, Microsoft,, Feedster, UPS, EVDB, WeatherBug, indeed, Blogger and others. [Hey John, don’t forget Yahoo! Actually, John does list Yahoo’s APIs here. – CD]

Why? Because going From Web Page to Web Platform is a big deal. It’s immature and a bit ill-defined but full of potential. To particpate as developers requires understanding, and to do that means to know what the parts are and how they work.

Another way to look at this site is from its genesis: frustration. I wanted to get the ‘big picture’ view of web apis. So I picked-up what books I could find (like Iverson). Pretty good start. But not enough. Then where? Everywhere. Despite what seems like an infinite number of social/web2.0 blogs, sites and businesses, I still couldn’t find the ‘go-to’ place I wanted.

Although it’s in the early stages, the site looks promising and I agree with John that the web-as-platform is a HUGE deal (why else would I leave my CTO gig to take a job at Yahoo! with the word “platform” in the title?) I actually met John when I was at InfoWorld since he used to be involved in the NY CTO Club that I wrote about and visited regularly. I’ll definitely be keeping an eye on his site.

Frederick Brooks / Ruby on Rails smackdown

Over at the 37Signals blog, there’s a post praising Frederick Brooks’ absolutely timeless Mythical Man-Month book (Wikipedia entry here), following up on a prior post espousing a “three people for version 1” philosophy, described as follows:

If you can’t build your version 1 with three people, then 1. you need different people, or 2. you need to slim down your version 1. Now, before I get yelled at, this doesn’t apply to every project, but I do believe it applies to the majority. And sure, if you are building a weapons system, a nuclear control plant, a banking system for millions of customers, or some other life/finance-critical system, then you may need a fourth.

But keep it in mind: three for version 1. Remember, it’s better to make version 1 half a product than a half-assed product. Three people will keep you closer to half a product and a cleaner, tighter, simpler base on which you can grow later.

The mysteries of the art of software development have always intrigued me, and I wrote about Frederick Brook’s amazing “No Silver Bullet” essay a couple of times in my blog and weekly column when I was at InfoWorld (man, that column about web services seems DATED now!) It’s one of those essays that’s worth re-reading every couple of years.

One of the comments to the post at 37Signals makes reference to the “No Silver Bullet” essay and puts it into the context of the Ruby on Rails phenomenon:

His essay called “No Silver Bullet” predicted that there would be no single significant development in programming that would increase productivity by an order of magnitude (whatever that means).

I’d be interested to hear JF/DHH’s opinion on that re: Ruby on Rails. Does RoR constitute an advancement of this type? Or, does RoR incorporate multiple technologies which collectively increase productivity (thus validating Brooks’ assertion).

Interesting question — I’ll stay tuned with my newsreader to see the response (and this isn’t really a Frederick Brooks / Ruby on Rails “smackdown,” I just liked the way that sounded as a title to this post!)

Incidentally, my friend and former colleague Scott Rosenberg is currently deep in the process of writing a book that touches on some of the issues he wrote about in one of his Salon columns — can’t wait to read it.