IAmTheRockstar

The Death of Ubuntu One Notes on the Web

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

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 -0700

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 -0700

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 -0700

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 -0700

...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 -0700

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 -0700

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 -0700

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 -0700

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.

Skeleton Jump is out!

Tue, 25 Oct 2011 10:22:19 -0700

Last night, Skeleton Jump got published to the App Store. Download it!

I've been working on this game for about a month, having had no previous iPhone development experience (outside of tinkering, really). I've been terrified of putting this out there, knowing about some heinous bugs that still exist in the game (but I can't find the cause for). It doesn't look like many people have problems with them, so I've been afraid for no reason.

Hooray for releasing code!

Thoughts on Mobile Development Platforms

Mon, 24 Oct 2011 21:04:20 -0700

I've been thinking about writing this post for about a month now. I should preface it by saying that I've found myself internally conflicted between software freedom and making a living. This is a fact that I'm reminded of every time I point out to a member of the Ubuntu community that I've moved from working on Launchpad to working on Ubuntu One. Let me be straight about this: I love Ubuntu, and I love software freedom. I also love fistfuls of cash. Some days, this internal conflict is maddening.

I have loved games since I was young enough to remember. My interest in technology came from learning to repair my NES console when I was 5. Last month, I met a fantastic artist named Jess Smart Smiley. He and I conspired to make a Halloween themed game in our spare time.

I don't have much of a desire to create games professionally, so I'm more interested in designing and creating games classified as "indie". Having blogged about the potential ecosystem for indie games before, I already had a head start on what our first target would be.

The first thing we thought about is existing and mature development libraries. The most popular mobile game framework is cocos2d. It was originally a framework for iOS, but also has an Android port. I also considered Ansca Mobile's Corona framework, but its high cost for both platforms (iOS and Android) made me eliminate it. The Android port of cocos2d had it's last commit Nov 15, 2010.

After looking at software, we started looking at the hardware. I have never owned an iPhone, but I've owned every one of Google's official Android phones. My wife has also had Android phones for a number of years now. She's not a gadget person, but she recently fell in love with an Android tablet (the Asus Transformer) and so we have a number of Android devices around the house. The only iOS device we had was my iPad. As I looked at the form factors and various hardware for Android, I thought "Oh man, this is going to be a QA nightmare." I tried out a number of Android devices and they each had their own quirks/lag/bugs. With the exception of a weird home screen bug in my Android devices, I never had that "lag" that everyone seems to be complaining about on my Nexus phones, but my wife's first Android phone was a huge piece of junk with a plastic touchscreen and Android 1.6. There are basically 4 different hardware configurations for iOS, and only 4 (currently).

We decided that our first game would target iOS.

After we decided on iOS, I had lunch and/or !coffee with a few local mobile game developers. All but one had experience with both Android and iOS. They all had the same problem with the Android market: people decompiling/recompiling their apps and putting them on the Android Market for free. It's basically an arms race at that point, where you spend your days sending takedown notices to various Android stores instead of developing new stuff. The developers who were still committed to Android said that the only way they've made money is by using ads. I don't like that, since your mobile's screen is small enough already without ads taking up part of the screen (or dealing with artificial load times while you show ads).

We'll probably move into Android in the future, especially with its market share growing like it is. However, for the our first game, I feel confident iOS was the best platform to deploy to.

If you're interested in our game, become a fan of Skeleton Jump on Facebook!

UPDATE: Lucio points out on Twitter that cocos2d is actually originally a python implementation. I knew this, but didn't see much connection between the two.

Confusing UX: Facebook's Lists

Tue, 11 Oct 2011 19:17:08 -0700

One thing I really like about Google+ is the ability to limit your posts to a "Circle" of people. Facebook recently added a similar feature. I decided to try it out and share a post with all my roller derby friends (including my wife). So I start exploring the UI and hit this:

I had no idea what to put in the "Hide this from" text box. Maybe "everybody else"? Turns out, you can ignore it, and it'll be limited to just that single list. I assume that box is so that you can add a list and then exclude someone. Please to hide that away, or even take away the feature entirely.

I Hate the Android Back Button

Tue, 13 Sep 2011 12:33:59 -0700

Android's Back button (whether in hardware or software) is braindead. I can understand the technical reason for its behavior. It's supposed to take you to the previous Intent...

...unless the current app has overridden the Back button.

Here's an example: Yesterday I attended BLDR.UX11. When I got into Boulder, I pulled over and pulled up my email with the ticket confirmation in it (using my Nexus S phone, not an Android phone with crapware on it). From there, I opened the conference web site. I then found an address for the venue and clicked on it, opting to open it in Maps. Once there, I had Maps give me directions to the venue, and then hit the Navigate button for turn-by-turn navigation. When I got to the Boulder Events Center, I grabbed my phone and hit back, which took me to the Maps app (from Navigation). I hit back again and it went to the BLDR.UX11 page in the browser. I hit back again. WTF? Now I'm looking at an article I read on my phone while waiting in the doctor's office a week ago. At this point, I repeatedly mashed the back button out of frustration until I was at the Home Screen (I realize I can use the Home button-I blame muscle memory).

While at BLDR.UX11, I met lots of folks who feel that having a single unified experience across mobile devices is a myth, and almost all of them cited the Back button as the reason. Some people go as far as to create their own back button in the app, which just makes the matter worse: now you have TWO back buttons.

Cancelling my Safari Books Subscription

Sun, 04 Sep 2011 20:20:10 -0700

I subscribed to Safari Books Online a few months ago. I like the idea of monthly subscription access services à la Netflix, and I tend to read a lot of technical books, so it seemed like a good idea. I just went through the flow for canceling that subscription, and I thought I'd document the reasons why, in case anyone else was curious.

Safari subscriptions have tiers, and you pay a monthly amount based on the tier you pick. I took the cheapest route, and opted for the 10-book "bookshelf". I thought it'd be fine, since I try real hard not to read more than 2 books at the same time (and usually I try and make one a fiction book). I went through and found a set of books I wanted to read, and added them to my bookshelf, essentially creating a backlog.

In order to start reading, I had a few choices: read on my computer, download a chapter at a time, or read on a mobile device with the app. Since I sit in front of a computer all day, I didn't want to spend my relaxing time in the same place. Downloading a chapter at a time wasn't at all economical, since it was quite painful to assign a "download token" to the download, and I was limited in the number of download tokes I could have every month. I installed the app on my iPad, and went to reading.

The iPad app crashes constantly. It requires an internet connection, so that limits where you can read it. If the iPad went to sleep at all, I had to re-authenticate the app with my account, often making it lose my place in the book in the process. When I turned pages, there was a latency that made the first-gen Kindle look blazing fast. Some of the books were essentially glorified PDFs, so you couldn't resize text or even highlight it. It was really painful.

By the time I finished two books, I wasn't really interested in reading any more of the books I'd put on my bookshelf. When I went to remove them, I found that they had to stay on my bookshelf for a minimum of a month. If a book takes me a month to read, it had better be a freakin' HUGE page-turner. At this point, the higher tiers started making more sense to me. It was obvious why someone would want a larger bookshelf now. I had gotten so trigger happy that I added books as a backlog that I never read, but sat in my shelf because I had to have them there for 30 days.

The one saving grace is that I had added some instructional/tutorial videos. I would regularly put these on while I cooked dinner or washed dishes in the evenings. There was one about gamification and one about Cassandra that I particularly enjoyed. I was never able to get the videos playing on my iPad, so I'd just prop my laptop on the microwave and play them. There were some bugs with playback on my laptop, but I chalked most of them up to Flash just being extra stupid (which is always a safe assumption).

Recently, Safari released a new mobile site, so I thought I'd give it a chance. I read an entire book using the mobile site. It too requires an internet connection (obviously). There is a "Remember Me" checkbox when logging in, which I was pleased to see, since the app didn't have one. I guess the mobile site has Alzheimer's though, since it would forget who I was even if I merely switched to another "tab" of the browser. There was also a section of the book that was mostly code or diagrams, so I'd flip through the "pages" pretty quickly. If I did it too quick, the site had to verify that I was human by prompting me with a captcha, which isn't very accessible, but also is a terrible thing to have to sort out on a mobile device.

I understand the need for DRM on content I don't own. If I check a book out of the public library, I'm not against the library putting protections to make sure I bring the book back. Netflix requires DRM to stream, and I don't mind that. The kicker here is that in both cases I don't notice the restrictions while enjoying the content. Safari, on the other hand, always had fiery hoops for me to jump through. After getting a singed a few times, I think I'll pass.

Ubuntu One and YUI: "Stale" events

Mon, 22 Aug 2011 13:59:44 -0700

A common pattern in any asynchronous web app is creating an item asynchronously, and updating the page to reflect that new item. This is pretty core functionality of Ubuntu One's Manager widgets.

What we started doing is something like this:

onSubmitForm: function(e) {
    var name = this.get('nameNode').get('value');
    Y.io('/notes/new', {
        method: 'POST',
        on: {
            success: Y.bind(this.onNewNoteSuccess, this)
        }
    });
},
onNewNoteSuccess: function(id, response) {
    Y.io('/notes/list', {
        on: {
            success: Y.bind(this.onNoteListSuccess, this)
        }
    });
},
onNoteListSuccess: function(id, response) {
    this.set('noteList', response.responseText);
}

This is obviously asynchronous. The problem is that once you start doing this six or seven times (or ten) times, it starts to get pretty messy. It becomes a pain to come back even a few weeks later and trace your steps through the code again. Part of this is asynchronous code in general, but you can make some very easy changes that make it a little easier to keep context in place.

One of my absolute favorite things about YUI is that it creates an API on top of the browser specific APIs, and thus allows for fun "middleware", such as YUI's support for custom events. With these events, you can do things like:

Y.fire('stupidMadeUpEvent');

...but, of course, that would be a no-op unless we had previously done...

Y.on('stupidMadeUpEvent', function(e) {
    Y.log('The stupid event I made up just fired');
}

Once you start to see the vision behind it, it actually allows you to do some pretty clever things. For instance, I like to be able to mark page fragments as stale, and have an event listener go and update that page fragment when needed. The above code then looks closer to this:

bindUI: function() {
    this.on('noteListStale', this.onNoteListStale, this);
},
onSubmitForm: function(e) {
    var name = this.get('nameNode').get('value');
    Y.io('/notes/new', {
        method: 'POST',
        on: {
            success: Y.bind(function() { this.fire('noteListStale'); }, this)
        }
    });
},
onNoteListStale: function(id, response) {
    Y.io('/notes/list', {
        on: {
            success: Y.bind(this.onNoteListSuccess, this)
        }
    });
},
onNoteListSuccess: function(id, response) {
    this.set('noteList', response.responseText);
}

This actually doesn't seem to be any more asynchronous or any faster, but I will say that it makes our code a bit more maintainable. Your mileage may vary.

You can fire an event on any event target in scope (which includes Widget, Node, and EventTarget objects). Between attribute change events and custom events, I find that most of my entry points for code are specified in bindUI.