Entertainer Media Center

While Javascript-centric, I think it applies to communities in general, and Free Software communities specifically. I'm now thinking more about how I'm treating the shared property of the communities I participate with.

In an effort to broaden my horizons beyond writing code, I've been reading a lot of business books lately. Coming from a mostly Free Software background, it's been an enlightening experience1. One thing sticks out the most: Processes matter, and ... [More] they matter more than I ever thought. It's common for me to contribute to random projects. Launchpad and Github and the like make it easy (can we get a Launchpad version of this shirt2?). However, I'm not likely to contribute to a project that has a HACKING document longer than any source file in the entire tree. If it takes me longer to figure out how to send a patch than it takes to write the patch, there might be some problems. Here's what Brandon Hays says in his blog post Why I Still Don't Contribute to Open Source: Guidelines often make a maintainer’s life easier, and mine harder. Yes, maintaining an open-source project is an arduous, thankless task. But I’ve looked at contribution rules/guidelines that turn a simple idea for a fix into a bureaucratic brick wall worthy of Microsoft. Now, when projects grow large, processes are a necessity. Launchpad, for instance, has a good culture of code reviews and a relatively strong emphasis on testing. I've only heard war stories about what it was like to hack on Launchpad before those processes and guidelines were in place. I don't have enough fingers and toes to count how many times code reviews and testing prevented me from doing something insanely stupid in a proposed patch to Launchpad. Processes aren't bad. We need them, sometimes to maintain quality, more often to maintain sanity. Here's a personal example of a not-so-good process: Not long after Launchpad started putting more thought into how we use javascript (back in late 2008), we put together this process of UI reviews3. We already had a good culture for code reviews, and we wanted to do the same with UI. We started with one or two people who seemed to have a good handle on what good UI is, and we worked to train and graduate new UI reviewers. This seemed like a good idea, because we could gradually get everyone on the same page with regards to what good UI was. We trained a handful of developers, and then interest waned in becoming a UI reviewer. Some people still attempted to get UI reviews, others would just ignore the process entirely if they could get away with it (and I don't blame them: attempting to get multiple reviews can be a PITA). It wasn't until a chat with Aaron Bentley that I realized the real problem with this process: We were inadvertently telling experienced Launchpad developers they didn't know enough about UI. In some cases, that was true, but in most cases, we were missing out on some great suggestions for good UI in Launchpad. Recently, Curtis Hovey proposed that UI reviews be discontinued and it was instantly ratified. Launchpad's UI has grown leaps and bounds since then. The Patch Pilot program that the bzr team created is a perfect example of a process that promotes the Bazaar culture. One core developer takes a time out from his/her regular duties (slowing velocity) to help guide patches from the community. "Hey, we have a process for patches (and even a HACKING document, but don't worry if you don't know it all just yet. <developer> will personally guide you through the process." Now, every time someone proposes a new process, I spend some time thinking about it more. How would this process affect culture? Is the proposed process in-line with the goals and values of the project? Personally, I think it's best to choose people over process, but I also don't maintain any projects that have an abundance of contributors. When in doubt, ask Zed Shaw. 1 The best book I've read this year was Harvard Business Review's 10 Must Reads: The Essentials 2 Seriously, I want one that says "Merge Proposal or GTFO" Maybe even get a picture of dobey scowling to go on the back. 3 I liked the idea of UI reviews. I'm also relatively impetuous, so it's to be expected. [Less]

For the last six months, I've been working closely with Zac Bir on really polishing the web frontend for Ubuntu One. I thought I'd sit down and write a bit about what we're doing and how we're doing it. I was tired of not having a very good way of ... [More] reporting feedback and errors to the user. The error message doesn't have to be that complicated, and sometimes the feedback just needs to be enough to say "Hey, I saw your click, and I'm working on it, but it'll take an indeterminate amount of time." I didn't like Launchpad's spinner, because it forces heavy page reflows (and sometimes repaints!). I searched/experimented with this for a while before I came to a conclusion. What you see above is the culmination of two ideas I'd been playing with for a while. Essentially, instead of having the spinner show up underneath what you clicked on (forcing the repaint/reflow), the spinner sits over the content. This is a problem in cases where we don't want to block the user while we do something, but in the case of the video, we do (we don't want them adding contacts while we're trying to find duplicates). If there's a error, we have a nice error box that also doesn't reflow, sits "over" the contact (it's actually absolutely positioned), and reports the error back to us. I should also add that we kiped this look from Landscape. They've really by putting effort into UI sexiness. Now, the UX porn is okay (it'll get better as we iterate). The best part (obviously in my opinion, but I wrote this so grain of salt and all that) is the API we're using to do all of this. It's entirely asynchronous and event driven. For instance, here's what an io call would look like: YUI().use('io', function(Y) { Y.Global.fire('one:busy'); Y.io('/ajax_endpoint', { on: { success: function(id, response) { /* Do your thing here... */ Y.Global.fire('one:idle'); }, failure: function(id, response) { /* Do failure things here */ Y.Global.fire('one:idle'); Y.Global.fire('one:error', {message: 'An error occurred. We suck.', error: response.responseText}); } } }); }); Now, ideally we should be firing 'one:idle' in the 'complete' handler, except that complete executes after success and failure, so you can get some weird bugs that way. The end result is the same though: the user gets a friendly message, and we report the error to the server side to be dealt with in our error reports (this part is still getting ironed out, however). [Less]

Every time want to create a YUI 3 Plugin, I always run into this same problem. I'm sick of forgetting this, so I'm going to blog about it, in hopes that it will help me remember. Here's my code until a few minutes ago: YUI.add('formPlugin' ... [More] , function(Y) { var FormPlugin = Y.Base.create('formPlugin', Y.Plugin, [], {}, {}); }, '1.0', {requires: ['base', 'plugin']}); This makes YUI very angry. What's worse is that it gets swallowed in YUI's error handling, so you don't even get good line numbers. The console spits out Uncaught TypeError: Cannot read property 'constructor' of undefined--It kinda provides hints, but it required me to get out ye ol' debugger to figure it out. The problem is actually very easy. Don't extend Y.Plugin You should be extending Y.Plugin.Base, and the documentation says that, but I keep forgetting. Don't let it happen to you. [Less]

When confronting users with forms, you need two things: (1) simplicity, because your user is being hassled for information, and (2) clarity, because the user needs to understand why they need to give up this information. If these two criteria are ... [More] not met, the only users you're going to get are really determined ones who will spend their entire time hating your app and looking forward to the day they get to dump it or you're going to get idiots who have nothing better to do. I prefer to have awesome people use my software. [Less]

I found this little diddy while registering my new audio recording station that I got as a replacement for the one that was recently damaged. Naturally, when I see "Username" I instantly start typing in "rockstar" (and it's available more times than ... [More] you would think...). Then I saw the small, grey letters above. What the heck? Why say "Username" then? It's not a username. It's an email address! Just say "Email address" and make sure it also says that on the login screen. And can we please get rid of that stupid pattern where you have to put your email address in twice? It makes me twitch violently every time I see it. [Less]

While I was hoping that the next Tarmac release would include support for merge queues, things haven't gone according to original plans. I'm pleased to announce the release of Tarmac 0.5, codename "Matches". Launchpad deals really well with all the ... [More] minutiae of doing releases, so if you want to know what changed, go look at the bugs targetted to the milestone. A PPA build of tarmac for Lucid, Maverick, and Natty can be found in the Tarmac PPA. [Less]

For the last three years, I've been working on the Launchpad Code team. Launchpad has changed a lot since I started working on it. Particularly, on the code team we've seen code imports, code reviews, source package branches and source package ... [More] recipes. It's been a fantastic three years, and I've loved the opportunity to work with the members of the Launchpad Code team. For the past few months, I've been "on loan" working with Ubuntu One team on the Web and Mobile team. I've had a great time working on the web interface for Ubuntu One. If you use the web interface for Ubuntu One Notes, you'll notice it's changed pretty dramatically, and that's because I re-wrote most of it recently. I'm currently working on doing something similar for the Contacts part of the the web interface. After all this work, I've decided to take a permanent position on Ubuntu One. It's a bittersweet decision, but I feel it's the right one. I'm ready for new challenges and new adventures! [Less]

Note: For every book I read this year, I'm going to write a good old-fashioned book report about it. Since I don't have to worry about grades, it won't necessarily be anything long or detailed, but just a "I read this book" sort of thing. I just ... [More] finished Universal Design for Web Applications. I picked this book up specifically because I know absolutely nothing about how to design websites for people with disabilities. The book tries really hard to convince us that we all have "disabilities" and that we should stop thinking in terms of "us vs. them." In fact, the second chapter of the book is where they start selling the idea of accessible websites (which I originally found annoying, because I was reading the book, indicating that I was already "sold"). I made sure to note down a few quotes from the book that really stuck out to me when trying to explain why accessible websites are important. For instance, on the topic of convincing businesses to make accessible web sites, the authors wrote: "What we usually encounter is hesitancy, if not hostility, to the idea of increasing a site's accessibility. Why should we fix the site for disabled users? We don't even have any disabled users!" That got me thinking about my own attitudes towards accessibility. Often, I have this same attitude, or something similar, like "Well, the site's probably not visited often enough by people with disabilities, so I should balance cost of development with benefits the site would get." The big thing I took away from this book is that we all have a preferences and tendencies that could be considered disabilities, and we often don't think of changing settings by clicking on that wheelchair sign. I am now committed to being more open to helping people out not because they are "disabled" but because it brings more configurability to the web. [Less]

A few months ago, I acquired a PC that has served me well as in my living room. It has Boxee on it, which is a really neat little media center application. Having it as a resource has allowed us to get rid of cable TV entirely, so we've been quite ... [More] happy with it. Earlier this week, I thought "I wish I could stream my Ubuntu One music onto this machine." Enter the Ubuntu One Boxee App. After a bit of hacking (and a lot of help from Stuart Langridge to figure out Ubuntu One's authentication methods, I now have streaming Ubuntu One in my living room. This is good for me, since the living room is the entry point for the music every where else in the house. This also means that, should you have a Boxee Box, you can still stream your music even though you lack a hard drive. There's still work to be done! As you can see from the screenshots, none of the Boxee UI widgets come with any sort of default look (argh!), so I've been busy creating buttons and the like (which I've rather enjoyed, because I want to get better with Inkscape anyway). When I get the UI experience all sorted out (and gain the ability to fetch album art through the Ubuntu One streaming service!), I'll be submitting the app to Boxee's app repository for public consumption. [Less]