Google i/o fail

Google i/o registration was today. Google completely screwed it up. Again. Is that 3 or 4 years running?

It’s really hard to understand how Google can screw this up year after year. It’s a terrible way to promote things like Google Wallet to developers.

It’s all the more disturbing, not to say pathetic, because this feels like a classic case of optimizing for the wrong problem.

This year’s registration page replaced last year’s browser timeouts and F5 pounding with more new code, this time in the form of a javascript spinner that had a planned timeout after 6 minutes.

There are so many ways to solve this problem in a way that leaves everyone feeling a lot better about the process.

The notion of first-come first-served makes almost no sense in an oversubscribed internet queue. It’s one thing to serve the first person standing in line outside a store, it’s another thing to pretend that this is meaningful when the queue is 100,000 people around the world all of whom were all in line at 10:00:00am.

It would have been more fair, less annoying and generally less embarrassing to formally recognize that this is effectively a random lottery. As such, have everyone pre-register over a period of days or weeks and then on the magic day, randomly select winners.

They wouldn’t even need to do the credit card processing until the winners have been found and any winners whose card fails are dropped and the next random winner wins. This entire process would take less than an hour and could run on an laptop in VicG’s office.

Even punting this entire mess to ticketmaster would have been better. And that’s saying something.

I’ve tried attending virtually in the past and it’s just not the same. I can watch the videos of the talks anytime but it’s the random conversations in the halls that really bring it all together.

Of course there’s a possibility that Google actually wants to maintain an aura of hype and unavailability for its premiere developer event. The continued high value gadget giveaway certainly makes the ticket worth the $900. Does Google actually need to do this? Do they benefit from putting these devices in developers hands? Would the conference be as popular without the swag? We’ll probably never know.

In developer relations there’s a big difference between hype and engagement.

Javascript: assembly language for the web

Javascript has been called the programming language of the web. This is almost true. Javascript is more like an assembler. Almost every meaningful framework is dominated by a layer of infrastructure to manage modules, references, dependencies and so on.

The result is always very noisy code that is just harder to read.

What a world it would be if Javascript had macros and eschewed the Algol syntax and opted for Lisp style parens. JSON? It’s all Lisp.

Angular Dependency Declarations: too many ways to screw it up

Because Angular’s modules and dependencies are layered on top of the Javascript language they suffer from a fairly verbose form. There are several ways to declare a dependency and they are documented in the obvious-in-retrospect $injector documentation.  However, only one of these is acceptable in my book.  The one true way to declare an Angular provider:

angular.module("SomeModule").service("SomeService", ["Dep1", "$rootScope", "Dep2", function SomeService(Dep1, $rootScope, Dep2) {
// your code here
}]); // such an elegant way to close the declaration!

This is almost DRY.  At least the repeated declarations are close to each other and could probably be verified by a lint checker.

Why do the other forms exist at all?  The Angular devs correctly realized that for someone’s first experience with Angular the above is just too syntactically noisy. They came up with a very clever trick that works well for fiddles and plunks but breaks confusingly when used in any real production environment. The trick is to check if the dependency list passed to module.service is an array or a function. If it’s an array then it’s presumed to have a list of dependencies and a function. Oh the overloading! Why not just put the function as a 3rd parameter? If it’s just a function then Angular gets the source of the function (yes, you can call fn.toString()) and then parses out the declared argument names and treats those as dependencies to be injected.

module.controller("MyController", function ($scope) {
// some code
});

It would be great if this just worked all the time. Unfortunately minifiers will replace all argument names with single letter arguments and Angular will spit out a confusing error message:
Error: Unknown provider: aProvider at Error ()

The “aProvider” here is the function argument name “a” and “Provider” (which gives you a hint as to how Angular manages its namespace).

Angular Module Declarations Are Error Prone

Sometimes it’s the little things that can really trip you up. This particular one comes up on IRC often enough that I decided to write it up.

The most common error is:

Error: Unknown provider

The most common cause is an incorrectly declared or referenced Angular module.

Angular is built on a system of modules, providers and dependency injection.  As always with Javascript this is all done using functions to construct internal data structures that have no special meaning to the language itself.  This means that errors are usually opaque and deep inside angular code.

Here’s how you declare an Angular module.

angular.module("ModuleName", ["ModuleImport1", "ModuleImport2"], optionalConfigFn);

And here’s how you reference a module so you can declare providers (e.g. services):

angular.module("ModuleName")

The above is necessary when a module’s providers are in multiple files.

The reality is that many developers have only one module and so their module declaration looks like this:

angular.module("ModuleName", [])

And so a very common mistake is to reference a module as follows:

angular.module("ModuleName", []);

I think this is because many people also declare a module the same way, with no other module references. If you do this then Angular will moronically create another module and lose the original module. I’d love to understand for which scenarios this makes sense. My first pull request to Angular will be to turn that into an exception.
Another solution would be to avoid overloading:

angular.declareModule("ModuleName", dependencyArray, optionalConfigFn);

angular.findModule("ModuleName").service("myService", [function() {}]);

I for one, can’t wait for our robot drivers

Robotic quad copters notwithstanding, the most important area of robotics is that of self-driving cars.  I predict that self-driving cars will become common within a decade.  The changes will be significant:

  • Fewer people will bother to own cars.  Most of us use our cars for less than an hour a day.  That’s just poor use of capital.  When cars can come to you on their own then you just reserve one on demand.
  • The differences in car ownership between urban and rural areas will extend into suburban areas.
  • Taxi drivers will cease to exist.  Professional drivers will become very rare and specialized.
  • Parking facilities will shrink.
  • Transit systems will become integrated with car networks.
  • Traffic management will become a real time management problem and opportunity.  A central authority may not control your car but it will certainly be able to virtually close some roads.
  • Access to cars becomes more like airline travel.  Unlike most airline travel however, individuals have very predictable patterns of normal usage.  Daily commutes will become an auction process optimizing for finite resources.
  • Staggered working hours will become even more common.  What works for school buses will certainly work for everyone else. 
  • Cars will become more utilitarian.  Today’s cars are a major personal style and status symbol.  Some people will be willing to pay more for a luxury on-demand car but most will stop caring so long as the car has internet.
  • Fuel efficiency will finally improve.  Most cars today are over-powered.  Their engines are optimized for user satisfaction rather than efficient travel.  Take the driver away and give her a book and driving 5 to 10 mph slower won’t matter much.
  • Law enforcement will start pre-emptively gathering travel data and investigating exciting correlations.

I can’t wait.

Robot quad copters

I’ve been fooling around with and thinking about various forms of robotics lately.

It started with an Arduino and some basic electronics parts.  As a kid I was always fooling around with electrical relays, making alarm systems for my room and other fun stuff but I never quite made the transition to electronics.  Now I dabble.  I recently got a motor shield for my Arduino and built a small autonomous tank.

Then I got an ArDrone quadcopter.  It’s lots of fun to fly but I really wanted to hack it.  When my friend Tim dropped by from Paris we set aside a day and had some fun.  OpenCV, node.js and before you know it we have copter than can identify and follow faces.  The experimenting inside quickly resulted in some new policies involving a Flight Safety Officer.  I haven’t returned to the scene of the crime since but I can’t wait to do more with this.  More quadcopters are coming.  How long before we have quadcopters that can autonomously take off, patrol, return and recharge?

 

Coding again

I’ve rolled up my sleeves and started coding again.

My development team on Crisply really doesn’t like front-end work.  We’re solving some very interesting problems on the back-end and those problems are truly the make or break for the product.  This made it easy to ignore the UI or at least to spend as little time as possible.

The current app is a split between traditional rails views and a Backbone front-end. The Backbone front-end is itself a hybrid with ERB generated templates and javascript.  It’s generally no fun to maintain.

So I decided to roll up my sleeves and make a fool of myself.  I’ve been playing around with Javascript since 1995 when I first started working on Internet Explorer.  Many things have changed but Javascript is still both great and awful.  It’s like assembly language Scheme.  No macros and a messy syntax.

After looking at many frameworks I concluded that the good ones had a bad case of language envy.  Like Java beans things like properties are explicit methods on top of the language.  This is where Javascript sucks.  It’s very difficult to create abstractions that feel language integrated.  Instead it feels like you’re reading the output of a compiler.  All the time.  ECMAScript 5 will help a lot.

The one framework that stood out was Angular.js.  It reminds me a lot of the data binding features in IE that my friend Sam Bent worked on.  After much experimentation I feel that my initial instincts were valid.  Although Ember.js is almost certainly more mature than Angular, I think Angular is a better fit for me and my team.  It allows all us to write code that all of us can extend and maintain.

I’ll be most posting more as I continue to learn and hopefully master Angular but the primary goal is of course a working UI for Crisply.

I’m back

I’ve had a few requests to blog about this or that.  Obviously these are people who have yet to actually read my blog but it’s as good a reason as any to start writing again.

Of course a small post like this without a decent backlog of stuff to write about is akin to getting everyone’s attention by saying “watch this” and attempting some crazy trick with a frisbee where the most likely outcome is that the disc ends up perfectly centered under a car, just out of reach.

Your service, my data

This is was also posted on Google+

Your service, my data.

Recently there have been a few high profile stories about users whose Google accounts were suspended for ToS violations. I’m sure that some were more justified than others. That’s not the big problem. The problem is the impact of these decisions.

Your services, my data.

Google’s own Data Liberation Front agrees.  Here’s their mission statement:

Users should be able to control the data they store in any of Google’s products. Our team’s goal is to make it easier to move data in and out.

Cloud providers are landlords. In this case, Google is the landlord of my Google+ profile. Under certain circumstances the landlord has the right to terminate my lease. Under no circumstances can the landlord hold or destroy my data.

When Google (or any cloud provider) decides to terminate a user’s service they should make all the user’s data available for download for a reasonable period. Google is already 80% there with Google Takeout.

+Eugene Spafford nailed it in a discussion yesterday. Cloud providers had better start behaving like reasonable landlords or sooner or later they will find themselves regulated.