IAmTheRockstar

Achievement Unlocked: Contribute to Twisted

Tue, 13 Mar 2012 11:32:42 -0600

That is all.

Juju on OS X

Sun, 11 Mar 2012 01:07:19 -0600

I've been playing with Juju to deploy servers in the cloud. This means that Juju has come up in regular conversations with my devops friends (admittedly, I'm more dev than ops...). I had lunch with some devops folks from an unnamed startup while at PyCon, and I mentioned it to them. They use Ubuntu in the cloud very heavily, but the systems they use for deployments, etc. were running OS X (as glorified ssh terminals)1.

This wasn't the first time I'd had a conversation about Juju result in questions about its compatibility with OS X. After that lunch discussion, I decided it'd be my last. I sat down with two devops guys with those ~~super expensive netbooks~~Macbook Air laptops and sorted out how to get Juju working on OS X.

First, install Zookeeper. The devops guys used Homebrew to do that. It looks like there's also a source distribution at the Zookeeper site, but I'm not familiar enough with OS X to know about anything outside of Homebrew.

brew install zookeeper

Once Zookeeper is installed, download Juju and go into the new branch.

bzr branch lp:juju
cd juju

Install juju dependencies2.

pip install pyOpenSSL pyyaml twisted txaws txzookeeper zkpython

Once that's complete, install juju.

python setup.py install

Now you've got Juju running on OS X. I suggest starting with the tutorial, and then moving on to writing your own charms.

1 The Mac builds of Precise nightly are most excellent, so if you've got a Mac, running Ubuntu on it without all the pain that usually comes with running Linux on a Mac. I highly recommend it.

2 I've submitted a patch to Juju so that juju knows about its own dependencies. As soon as that lands, this step can be skipped.

Ubuntu One: Cloud Storage for Human Beings

Tue, 06 Mar 2012 12:55:56 -0600

While on my weekly phone call with the rest of the Ubuntu One Web and Mobile team, my wife walked into my office and gestured for me to mute the phone so she could talk to me.

"Hey, I'm uploading my portfolio to Ubuntu One and it's taking a long time. It's a lot of files. Ubuntu One can handle a lot of files, right?"

"Wait, what?"

"I'm meeting someone today to talk about doing some art, and I need to send my portfolio to her. I'm putting it in Ubuntu One. Is that okay?"

"Absolutely! If you want, you can then put it on your tablet too, so you can have it mobile. Just install the app"

...an hour goes by...

"My tablet can't read my portfolio, so I uploaded the individual pictures, and now I have my portfolio on my tablet."

The original "portfolio" was a zip file, and her tablet didn't know how to open zip files. She soon had her phone and tablet syncing their pictures to Ubuntu One.

Sometimes I spend so much time working on Ubuntu One that I forget that I'm contributing to making cloud storage accessible to "normal people".1 Moriah doesn't care about filesystems and protocols and desktop environments. She just wants the artwork she did on the computer to be available to her on her tablet when she goes to meet someone at a coffee shop. She wants to be able to easily get to her phone's pictures on her computer (she's always taking pictures of things that she finds inspiring, to refer to later). I'm glad to be part of the movement to help facilitate that.

The Ubuntu One team has a lot of work ahead of us, but little encouragements like this go a long way. I'm now being accosted with feature requests from my wife, which is a good problem to have.

As a final note, sure, there's Dropbox and iCloud and all sorts of things. Moriah was familiar with Ubuntu, so Ubuntu One became the obvious choice for her. In fact, she had iCloud enabled on her iPhone and they were causing side-effects that caused her to curse profusely on a regular basis.

1 I use the term "normal people" because it's a running joke in our house that geeks are not normal. We do very peculiar things. This has become the subject of her weekly webcomic Citation Neeeded.

Announcing Pariah: Web comics for Django

Sun, 04 Mar 2012 18:29:21 -0600

I've just cut and released Pariah 0.2, a reusable Django app for working with web comics. It's a small piece of code, but focuses on doing one thing and doing it well. You can download the source on Github, or you can install it from pypi with pip install django-pariah.

It's still a very early-stage release, but is now in production use on Citation Needed, which was previously using Comicpress, which is both terrible software and also apparently no longer maintained.

Why call it Pariah? Because my wife, for whom this software was written (the author of Citation Needed), is named Moriah. My name is Paul. If we were a celebrities, the tabloids would refer to us as "Pariah", which I find pretty fitting.

My Love Affair with ChromeOS

Sat, 03 Mar 2012 23:29:12 -0600

A few months ago, I traded my XO laptop for a CR-48 laptop. I've fallen in love with this little gadget. It's simplicity is what appealed most to me originally. It's just a browser. That's it. If it's not a webapp, it doesn't matter. What hooked me, however, is the new perspective on computing that I wouldn't have gotten had I kept working with the same tools that I always work with.

I've been an Ubuntu user for a long time. I've recently also started using OS X for tasks that require a Mac. I've always considered myself a pretty forward thinking guy. I like the direction that Ubuntu is going, including the polarizing Unity project¹. Using ChromeOS on the CR-48 showed me that I'm not forward-thinking enough.

Before ChromeOS, webapps were this cute thing that I could use when I didn't have a native app that did the job much better. Now I look at webapps as the default, and see my usage of native applications as a failure of the internet-makers to fill the need (this failure has sparked quite a fun little side project that I hope to do something with soon).

Sure, webapp performance will never beat native performance, but there's more to a User Experience than performance. They may not cover all cases. I suspect, though, that all those edge cases are usually people that want to "use computers" rather than just get things done.

Screw Android. When can I have a ChromeOS phone?

¹Unfortunately, I've recently "outgrown" Unity, which I think is okay. The addition of the second launcher on dual monitor screens did it. I have no desire to have a second launcher right at the seams of my two monitors.

Update (6 Mar 2012): thumper and I chatted about the Unity problem I was having on my dual monitor setup, and we've come to a solution that will work for both of us. I'm looking forward to going back to Unity, because Xfce and LXDE and all the other minimalist environments don't have nearly the polish that Unity has, and Ubuntu has spoiled my for so long that I don't feel like polishing anything myself.

Pretty URLs and HTML5 pushState

Tue, 28 Feb 2012 23:42:04 -0600

When the Django/Rails revolution hit the scene years ago, I was working for a small development shop building something similar to the Ellington product that Django came from (or something like that). We were building a CMS using PHP for a small newspaper in California¹. The day we rolled out prettified URLs in our completely re-written version was the day we started to see our sites climb the Google ladder.

Django and Rails and CakePHP and all those other has-been-hipster frameworks all adopted prettified URLs and everyone rejoiced. Now you could guess URLs like twitter.com/rockstar_ or facebook.com/yourmom; you could actually read a URL out loud to someone and it wouldn't be that hard to replicate by hand somewhere else (I witnessed this happen in a college dorm a few years ago).

There's only one problem: Those URLs don't really match with the HTML5 APIs.

HTML5's History keeps track of state (and if you're not using it while building web apps, I hate you). The mismatch comes from the fact that History keeps track of state in key/value pairs. So, if you were looking at a Contacts app, and you clicked on a Contact, it might do something like this:

history.pushState(
    {contact: 'ipfreehly', view: 'contact'},
    'I.P. Freehly', '/contact/ipfreehly');

The third argument to pushState is a new url (with the same origin). How do you take those two key/value pairs and update a pretty URL accordingly? If you can use querystrings, it's easy, since querystrings are just key/value pairs as well.

The only sane solution (because reproducing URL building logic in the client-side is not sane) that I've been able to come up with is to make sure the href attributes of anchor tags are set correctly, and to just update the url to be the same as the href of the link. But what about actions that are not a:link, like buttons? In that case, we use any number of other attrs, or create our own data attribute for it.

I'd be curious to know if there are any cleaner solutions for the mismatch between pretty URLs and History.

¹ The software was called "Bakomatic" and from what I hear, it is no longer being maintained or implemented. It was funded by the Bakersfield Californian (thus the 'bako' name). It was a good experience to work in publishing, even if it was only for about 18 months.

The Death of Ubuntu One Notes on the Web

Mon, 27 Feb 2012 15:40:37 -0600

Pre-cursor note (just in case): This isn't an official Ubuntu One post. For those, go to the Ubuntu One blog. I just work for them, and I have my own opinions.

Today I submitted and landed the branch that will kill the web UI for Ubuntu One notes. Users can still use Tomboy to sync, but you won't be able to access them from the web. I know a vocal minority is upset about this. To those, it's unfortunate. I'm sorry. However, I think the decision was a great one.

The work was done in two branches. The first removed the links on the website and python views and entries in urls.py (it's no secret that our web app uses Django). The second one removes everything else: css, javascript, javascript dependencies, and the rest of the python files. Here's the diffstat of that second branch: 103735 lines (+3/-103093) 92 files modified

Think about that: more than 100k lines of code removed there. Sure, we didn't write some of that, but we sure as hell needed to maintain it (it's our attitude that we own the stack). Think about all the hidden bugs in there. Speaking as someone who knew that code intimately (it was one of my first tasks to re-factor it when I first came to Ubuntu One), there's also a lot of technical debt there¹.

If code is liability, that's a lot of liability.

We didn't see that much usage of the Web UI for Notes. One of the reasons I was re-factoring it a year ago was so that we could make it less fragile. It broke a lot. Automated tests probably would have caught that, but the fact that users didn't notice when it broke is indicative of a feature that isn't being used. Even after it was refactored, there were browser bugs that would occasionally surface, but no one seemed to notice.

If features are an asset, Notes on the web were an asset that few people valued.

I'm not a business guy, but it makes total sense for us to reduce the liability with little real cost. Our team is small (but quick and amazing), so the less time we spend maintaining unused features, the more time we can spend making things that are awesome (and we are doing amazing things; stay tuned).

The last thing that I want to address is this question that keeps getting asked in some form or another: Why not make it open source and have the community maintain it? Here's how I respond to that: You don't get bored of a piece of software and punt it to open source. You also can't think "Oh, the community will pick this up." They won't. You can't just assume there will be a "community" for it. If you can't hold someone responsible for its maintenance, you can't expect it to be maintained.

¹ Technical debt is a fact of life on any development team, and specifically one a team that moves as quickly and kicks as much ass as the Ubuntu One team. We try to mitigate it where we can, but it's a balancing act.

Node.js and Socket.io: Authentication All The Way Down

Tue, 14 Feb 2012 21:01:55 -0600

I have a little weekend-project that I've been working on since December. It started as tinkering, got really ambitious, and then settled down into something I was just playing with to learn some new things. Learn new things I have. This new project is built on Node.js using the Express and Socket.io libraries to make things a little easier. I wrote the account creation/authentication code, and backed it with MongoDB. However, when it got to honoring that login, things got a little tricky.

The first thing you'll read about is the MemoryStore object in Express. It's used to store sessions. Take that MemoryStore object and throw it out the window. Let's use Redis instead (separation of concerns FTW). First, install the connect-redis library.

npm install connect-redis

...and stick it in your app.js...

var express = require('express')
    ...
  , RedisStore = require('connect-redis')(express)
  , sessionStore = new RedisStore()

...

app.configure(function() {
    <snip>
    app.use(express.cookieParser());
    app.use(express.session({
        secret: 'YOURSOOPERSEKRITKEY',
        store: sessionStore
    }));
});

Now you should have a session property on each routes' request object. I only stick the user id in the session and then just look it up when I need it. Here's the rub: if you're using Socket.io, your socket doesn't have access to that cookie by default. That's a real bummer. The Socket.io wiki talks about this a bit, but it's not entirely clear on how to hook it to the existing session store, and who wants to re-implement code.

One that I really like about Node is that basically everything is middleware. All we do is set the authorization function to add the session object to the socket's handshakeData.

var app = express.createServer()
  , io = require('socket.io').listen(app)

io.configure(function() {
    io.set('authorization', function(data, callback) {
        if (data.headers.cookie) {
            var cookie = parseCookie(data.headers.cookie);
            sessionStore.get(cookie['connect.sid'], function(err, session) {
                if (err || !session) {
                    callback('Error', false);
                } else {
                    data.session = session;
                    callback(null, true);
                }
            });
        } else {
            callback('No cookie', false);
        }
    });
});

Now, when you add your socket connection handler, you can do this:

io.sockets.on('connection', function(socket) {
    var session = socket.handshake.session;
    ...
});

Hooray, now you can fetch session data in the web socket.

Tech Tasks for a High School Intern

Mon, 13 Feb 2012 11:53:46 -0600

I'm planning on "hiring" my younger brother to do some work for me during his Spring Break in a few months. He's 16, and has some tech skills, but his school is not very technical and so he could use more opportunities to learn from folks. I thought I'd have him do some QA and some light programming (he's a fairly new but competent pythonista). I say "hire" because I want to add some incentive to learning enough to get a summer job.

Can you think of tasks that might be good for him to do? Maybe you have an open source project that you could mentor him on, and in so doing, gain a contributor. If you can think of something that you wished you had known when you started hacking, I'd appreciate if you'd please leave me a comment.

Announcement: YUI 3 Nightlies

Tue, 13 Dec 2011 11:19:06 -0600

I'd like to announce the general availability of a YUI 3 Nightly combo server. Each night, it will check out and create a new build of the YUI 3 source code, and serve it via a combo handler. In order to use it, just point your YUI_config to the new combo loader. Information about it can be found at the main page at YUI Nightly Doc Page.

Why did I do this? There are a few reasons. First, Ubuntu One can't use the Yahoo! CDN because we're using SSL. This means we have to run our own combo loader. The problem with this is that it's a pain to go out and get new YUI and plug it into my dev environment just to get surprised by something that broke or something that changed, etc. With the nightlies, I can regularly just point YUI to this combo loader and let it run.

I'm using this in "production" for a small personal site, but I wouldn't recommend it be used it any production site that actually has uptime requirements.

Comments, questions, and pull requests welcome.

Update: The URL has now been changed to http://yuinightly.com/.

YUI and PhoneGap Sitting in a Tree

Fri, 09 Dec 2011 12:05:56 -0600

...K-I-S-S-I-N-G

The Web and Mobile Ubuntu One team is in Buenos Aires, Argentina (along with most of the rest of the Ubuntu One teams) exploring the boundaries we may experience merging the Web and Native App experiences. I realized very quickly in this exploration project that I needed an end goal. Since we are already using YUI on the web part of Ubuntu One, I figured that I needed to figure out where the limitations of YUI would be there.

Enter PhoneGap.

It became very clear that it'd be much better to use one of these "glue" frameworks than to roll our own (the important reason being that we'd rather do more fun things). One of the first things I noticed is that the default PhoneGap doesn't really "compile" out of the box, which annoys me. Once I linked in the www folder properly, I had a good stub.

Using the YUI Loader in PhoneGap is not impossible, but it's relatively impractical. It stores a whitelist of URLs that you can get to, and even then, javascript is so required on the site that we can't afford to not have javascript. At this point, I realized that all the front-end tweaking/ricing I've been doing for the last year or so gets thrown out the window. I broke down and made giant rollup files for yui.js and yui.css.

As a sidenote, I also took the time to actually explore the YUI App Framework by coding rather than reading about it (which I've done a lot). There is an example Todo app (thus, the reason why I made a todo app). So I essentially cargo-culted that code.

Sometime during this cargo-culting, I realized one very important thing: Debugging PhoneGap apps is a pain in the ass. It really is. It resulted in this late night tweet (which I was at least half serious about). Unless you're a human jslint machine (and if your name is not Doug Crockford, I assert that you are not a human jslint machine), you're bound to make typos and syntax errors and such. You don't really get a decent access to the console1. I tried running the app in a normal desktop browser but I found that events I was expecting either weren't firing or weren't being handled (without a console, I don't know). I eventually went digging into the PhoneGap js that comes with the default template, and realized that I needed to just kill the PhoneGap js when testing in my browser. The browser only takes you so far, but it at least helped me to get the YUI toolchain sorted out.

I then took a bit of time sorting through the touch-specific interface and adapting the App example to that interface. For instance, hover events are useless on mobile. I also found that the "keypress" event for the Enter key in an input wasn't firing with the keyboard "return". Apparently, the iPhone wants the form input wrapped in a form itself, and then it'll show the "Done" button in the on-screen keyboard, which will send the right event (make sure that the form doesn't actually submit).

The end result is MoarTodo2. It's a really ugly app, but it's academic and I just wanted to learn about the toolchain. I can't imagine not using something like PhoneGap (it doesn't have to actually be PhoneGap) to build a mobile web app to be distributed through the various app stores. I expect there will be more to the debugging story, but it's still a learning curve.

I still feel pretty strongly that the Native vs. Web argument will continue, and that they'll still have their various places. I look forward to a day when that argument is settled, but I also look forward to the Year of the Linux Desktop, the rapture, and Santa Claus.

1 I didn't try Weinre because I had switched to using iWebInspector a few weeks ago (when I wasn't using a PhoneGap container), and so didn't have it immediately on my system. I'll probably have to go back and try it out in a PhoneGap context.

2 Xcode creates new projects with Git. I'm not making a political statement here. I just pushed it where it was easiest. Don't hate.

THE Ubuntu Success Story

Wed, 30 Nov 2011 12:50:21 -0600

Last night, I came home from a meeting, kissed my wife, and was walking back upstairs when my coat started vibrating. I pulled my phone out to see that I was too late, and wasn't able to answer a phone call from my dad. I called him back, and here's a summary of the beginning of that conversation.

Me: "Hi dad."

Dad: "Hi"

Me: "Did you call? What did you need?"

Dad: "I did. I installed Ubuntu and now I'm trying to figure out how to install the driver for my video card."

Me: "Waaaaaaaaaaitaminute. There's a backstory here that I have to know before we go any further."

My dad is "technical". I remember as a little kid realizing how excited my dad was when he was installing Windows 95 the day it came out. I spent summers and school holidays making money at the company he worked for by being the floppy swapper when installing software. He was also the person who introduced me to the term "freetard". He's always been pretty resistant to free software, and sometimes for good reason (ever tried sending a document back and forth between on OpenOffice environment and a MS Office environment multiple times?). Last year for Christmas, my little brother Matt received a netbook that got infected before Christmas Day was over. I offered to put Ubuntu on it (something he wanted) but my dad was so resistant that he went out and bought a USB CD-ROM drive just so he could make sure Windows stayed on the machine.

For me, Ubuntu has never been about "So easy my mom can use it", but "So simple my dad doesn't have a reason not to use it".1

As the story unfolded, my dad had been exploring the idea of virtual machines for a client, and had installed Ubuntu in a Virtual PC environment on Windows 7 host. Unfortunately, his video would only give him 800x600, when his Windows XP guest would fill his dual-monitor setup easily. He expected this to be a driver issue (Virtual PC apparently doesn't have a driver pack for guests like VirtualBox and VMWare do). I found this article, but as I looked at the instructions, I thought "Holy crap. I wouldn't even do this." It became pretty clear that Microsoft Virtual PC was a pretty hostile environment to anything non-Windows.

At this point, my dad starts asking about the Windows installer he saw for Ubuntu (Wubi). Most of his concern centered around whether or not it was going to screw up his Windows partition (it doesn't). After a bit of talk about Wubi, we ended the phone call.

This morning, I get an email from him that says:

Installed 32-bit Ubuntu on my system last night (Wubi). Booted this morning and found that my USB keyboard/mouse combo is not recognized at Ubuntu login screen. No time to troubleshoot this morning before work and probably won’t spend a great deal of time on it, but wondered if you had any ideas of things I could try this evening.

Sounds like he's got a bluetooth keyboard/mouse combo that is having problems. It's not a happy ending just yet, but it's a giant step in the right direction.

The Chasm. Ubuntu is crossing it.

1 I gave my mom my old laptop, running Ubuntu, and connected to Landscape so I can manage it for her. She's not technical, and Ubuntu satisfies most of her computer needs (the only one that it doesn't satisfy is that she has no genealogy software that's compatible with the other software she uses).

Using Mustache templates in Express Apps

Mon, 21 Nov 2011 20:41:54 -0600

Tonight I decided to hack on a quick little webapp and use the opportunity to explore some tech that I've only gotten to tinker with so far. I wanted to build a small webapp with express, but I hate jade templating (I realize this may make me a javascript heretic). Since I'd rather just write HTML, I decided to use Mustache (plus, I have previous experience with Mustache).

The biggest problem with Node.js in general is that development is too fast. Blog posts get out of date really quick. I found a few blogs that show how to do it, but they're more than a year old, and at that point, it's almost worthless. Then I found stache. The docs there helped out to get me most of the way there. Here's what I did to get a basic express app using mustache.

First, install express and stache, and then create a new express app named myApp:

sudo npm install -g express stache
express myApp

Now change into the myApp directory. Edit app.js.

var stache = require('stache');

...import stache and then configure the app to use stache (you'll replace the existing jade config)...

app.set('view engine', 'mustache');
app.register('.mustache', stache);

In this case, I'm using a .mustache extension for my templates, and then passing stache to it as the handler for mustache templates.

In your views/ folder, you should see two files that the express command created by default: layout.jade and index.jade. We want to replace these with mustache stubs similar to these files. Let's start with layout.mustache.

<html>
    <head>
        <title>{{title}}</title>
    </head>
    <body>
        {{{yield}}}
    </body>
</html>

In stache, {{{yield}}} seems to be a special keyword for using the subtemplate. Make sure you remember all three suspenders around it, or you'll spend 20 minutes scratching your head and wondering why the HTML is being escaped (a behavior I hadn't ever used in mustache).

Now in index.mustache, we add the following:

<h1>{{title}}</h1>
<p>Welcome to {{title}}</p>

At this point, we've got a similar layout and template to the jade templates. The last thing left to do is change the data structure of the context we pass (since mustache wants the template context in a different format). Crack open routes/index.js and change the res.render call to look like this:

res.render('index', {
    locals: {
        title: 'Express'
    }
});

Now fire up the app with node app.js and hit /. Does everything work? Hooray! If not, uh, sorry. I'd be interested to know what didn't work, so I can fix the post.

In fact, since Node.js posts tend to get out of date, if this one does, please let me know and I'll update it accordingly.

YUIConf 2011 Day 2

Tue, 08 Nov 2011 10:48:55 -0600

A few days late, sure...

Once again, I pity the fool who looks at my notes expecting them to be coherent. They make sense to me, and that's why I took the notes. Here's the highlights:

Andrew Wooldridge - YUI Hidden Gems

I didn't expect to take many notes here, since I'd taken my fair share of dives into the YUI source code (I generally no longer care to read the online docs), but Andrew pointed out a few things I had glanced over and missed the value of. Among them, he mentioned:

Y.Frame - this is a wrapper for using the IFRAME element. It creates a YUI instance inside the IFRAME, so there's sandboxing, etc. but without the complications that come from IFRAME communication. There are quite a few places that we could use this in Ubuntu One. In particular, I think we could use it for the multi-file upload that we've been wanting to do for a long time.
Y.DOM.inViewPortRegion - The previous day, I went looking into the ImageLoader source to see how it worked, since the NFL talk mentioned a WidgetFold that only rendered the widget when it came into the viewport, and I was curious how it did it. Even though I had found this hidden gem the day before, it's worth noting its value in all sorts of cases. What I'd like to do is make a synthetic event for Node such that we can hook eventHandlers into "enterViewPortRegion" and "exitViewPortRegion" or something similar.
Y.on('hover') - How did I miss this? It's a synthetic event that YUI provides, since mouseOver and mouseOut can be a bit of a fun house of edge cases. Quite useful.
Y.on('clickoutside') - I use this in my little phazr library to close on Overlay or Dialog. It's fantastic.
Y.Later - A wrapper for setTimeout and setInterval. I made specific notes to play with this in some of the U1 things that I'm working on right now.

Eric ForRealYo - The App Framework

This talk Melted. My. Brain. A common theme that I heard repeatedly was that people tend to implement things in YUI, and right when they're finished, the YUI team announces the exact same thing in YUI. I did this recently with the App Framework.

The App Framework in YUI 3.4 leaves just a bit to be desired, but Eric's talk made it clear in his talk that all those desires will be available in YUI 3.5 (with a promised pr release in December). Eric had mentioned earlier in the week that he kind of looked at the iOS UI framework API when designing the App Framework, and I can see that connection. It's got a pretty good disconnect between data and presentation, which can often be kind of painful if you don't give it some thought. A nice API like the one the YUI team has designed makes it easy to design things correctly without putting too much thought into it.

One of the things I'm looking forward to the most in YUI 3.5 is the addition of support for Handlebars templating. This templating will be directly connected into Y.View, but won't be compulsory, so you can use any template system you'd like, and aren't forced in to Handlerbars.

As it stands now, YUI 3.4 has some of the App Framework stuff, and in particular, it has Model and ModelList, which have events that can be hooked into. To me, that's the best way to start using the App framework. Create widgets that handle events in your Model and ModelList instances. At the very least, that means that I have a clear upgrade path from my app framework to YUI's (so I don't have to maintain code, I can just file a bug and complain... :)

After all of this, it became clear that I've been neglecting the YUI Gallery, both in contributing to it and using it. I need to remedy that.

YUIConf 2011 Day 1

Fri, 04 Nov 2011 00:56:37 -0600

Day 1 of YUIConf 2011 is over. I didn't keep copious notes that are coherent to anyone but myself. Here is a congealed version of my notes (hopefully they aren't too hard to follow).

Dav Glass - Keynote

Dav said something that seemed to ring very true to me about the "Graded Browser Scale". Instead of talking about browser support, he started referring to it as a list of platforms to test on. If everything works on that list of platforms, it should work on everything. This is usually the way that I think about testing my own projects, and probably the way we should start thinking about Ubuntu One (granted that we don't see too much IE 6/7 on Ubuntu One currently).

The YUI team is starting to think more about time based releases. Having worked for Canonical for so long, I love the "cadence" that time-based releases bring. I hope this means new YUI features are available in a faster manner, but mostly I'm looking forward to the promise of being more open with what features are being worked on. It seems that we at Ubuntu One aren't the only ones implementing things that the YUI team end up releasing right after we finish writing it.

Luke Smith - From one, many; From many, one

One of the hardest and most overwhelming things about YUI is figuring out how to implement features. Should I use a Plugin, a Widget, or an Extension. Along with that, if you're used to class-based inheritance, inheritance (or the oddities thereof) of javascript is a little awkward. In general, for what I'm building, I don't need to worry about how the constructors link together, so I usually just build off of Y.Base and everything is fine.

One really important thing I had previously personally asserted and Luke confirmed to me is this: Unless you have a valid reason, use Y.Base.create.

Jeff Craig - Demystifying Loader

This was easily the best talk I went to today. The YUI Loader is a fantastic little piece of YUI, but it's also a black hole for documentation and isn't something most people grok. At Ubuntu One, we use convoy for combo loading YUI, and our configuration is a bit complicated. I've known about some of the things we could do to make it less complicated, but this was pretty beneficial for me. Particularly, the Loader can conditionally load modules, which should help in cases where we use modules to "monkey-patch" other modules in certain cases coughIOcough.

Ryan Cannon - There is no off-season.

Ryan talked about implementing YUI on NFL.com. This is very similar to a talk I proposed for YUIConf this year as well. Essentially, I like the stories of "This is how we got our site all working in YUI". They wrote a really neat sounding widget they called WidgetFold that only rendered the widget once the user scrolled down to see the widget. I can think of all kinds of uses for that kind of widget.

The highlight of Ryan's talk was "Are you writing scripts or building applications?" He used it in the context of picking the right tool for the job. I often bring up this theme when people ask "Why not just use jQuery?", but the way Ryan phrased it is pretty excellent.

I bypassed taking notes for the last two talks of the day. After dinner, Douglas Crockford spoke. My notes would make absolutely no sense, in that they are all over the place. The talk was about jslint (which Doug wrote). As a summarizing quote (although it doesn't nearly do the talk justice), I noted "use of good style can help reduce errors".

Afterwards, someone pointed me to the github issues page for jslint. Doug's responses are pure comedy. Next time I'm having a bad day, instead of going to laugh at bad Craigslist personals, I'm going to laugh at jslint issues on Github.