Everything that I'm working on. Heavy on the programming; heavy on the opinionated commentary.

Why I returned Google Glass: A narrative

As a developer, I’ve had an idea for Glass for some time. I was disappointed to not get it in the first round of purchases and instead picked up an Oculus Rift to do some augmented reality dev.

However, a couple months ago I received an email with an invitation to purchase Google Glass! Now, I should say I’m still a huge believer in the tech, but since Glass is in the news again, I decided to type up this first-person account of why I returned Google Glass.


An invitation! Oh happy days! I’ve had an idea for Glass that I’ve been waiting to try. $1,650 (tax)? No problem, it’s that awesomeness!

I’ll have it shipped to me, please. I don’t need that circle jerk that is a visit the Google campus for a “fitting”… thanks though.

And now the beautiful box has arrived! I’m a kid on Christmas. Oooo… so shiny and nice and pretty and shiny!

Ok… this is kinda weird, it is just a tiny little screen in the upper right corner. And wait, if I flip it around, I can see the screen from the outside world. Hmm… Oh well, I just won’t look at pr0n on my awesome Glass.

Swipe, swipe, tap, swipe. “Define glass”. Great.

And now to get some directions to places I’m not going… that’s kinda cool.

Why is my temple getting warm? Oh, because this thing is getting hot after a few minutes of use. That’s not good.

Annndddd…. the battery is dead. Lame.

Oh well, you probably won’t be using it non-stop like that in the real world, and it didn’t even have a full charge to start. I’ll just charge it and wait for another go.

Time to do dishes, I’ll entertain myself with Glass now that it’s charged. This seems like the perfect use-case.

Both my hands are wet… “ok glass”. Nothing. “ok glass”. Nothing. Oh, I need to enable “head-tilt” to turn it on hands-free. Done. Ok, that kinda works… wait… I still need to swipe and tap? What the fuck? What good is this thing other than lording it over others? I’m returning this shit…

Yeah… your code is pretty. So what: Your code is disposable

Make it work. When doing clientside, that’s the only thing that should be on your mind. I see a lot of wasted time and energy devoted to making clientside code look beautiful. Why?

Clientside code is disposable. It’s the sad truth. Your code will be dead and gone in only a couple years time.

It was only two years ago this was the norm:

Fast forward to today:

  • Fuck IE6. Fuck it squarely in the ass.
  • Mobile first
  • Everything looks like Windows Metro — even apple.com

Wow, what a difference a couple of years makes!

This trend will only increase in speed as even MS is switching to a rapid release cycle amid stiff competition. You’ve heard of Moore’s law? Well this is the law of the web. Things move fast, and that speed is only set to increase.

Stop worrying about maintainability. Stop worrying about maintenance. Stop worrying about that warm feeling you get when you look at all your pretty spaced and indented code.

Yeah… your code is pretty, but so what. No one cares. Does it work? Does it look good while working? Is it going to be garbage in two years — tops?  

Meet Intelligent Design. Responsive Design for Users.

Why are you always designing for the dumbest kid in class?  Web pages are living documents.  Let’s design them like it!

An inherent problem that plagues all software is how do you build a UI that works best for users of all skill levels?

Here’s a technique I came up with that will allow you to design a UI for your users across all skill levels at once. 

Responsive Design is for dynamically adjusting the design to work best with the device. This technique dynamically adjusts the UI to work best with the user. 

It needs a name, so let’s call it… Intelligent Design. Hmm… where have I heard that phrase before?  No matter.

So what the hell is it?

It’s automatically hiding/showing content and UI components based on the level of knowledge that your visitor has.  

This way, your newest/dumbest users get the simplest UI and your more advanced users get the advanced UI with all the fancy bells and whistles.

Users can self-train, and move on to the next level when they’re comfortable.  Both user segments are happy, and the end result is better software. Yay.

How does it work:

Here’s an example written in javascript.  I’ve found it to be incredibly useful on stampr, where I use it in the user account pages.  

Stampr is a pretty complex/hard-to-explain bit of software that has received nothing but “easy to use!” feedback.  I call that a win.

I recommend letting users manually choose their level and giving them a way to toggle between the two.  

Warning: Using this technique on a public (crawlable) website might be ill-advised since the hidden text might trigger some search engine red flags.  


The inspiration for this comes from video games.  The best games have well-written training maps that bring you up to speed while you play. 

This is how we should be thinking about UI design.  Let the user play around, and move up when they’re ready.  

More happy users.  Less support requests.  Less time spent writing documentation… but who writes that anyway…

Promises, promises… in javascript

Promises are in the news lately because they just landed natively in Chrome

I was first introduced to promises when I built something with angular.  I loved them and they work great with angular. 

However, since then, I’ve been back and forth on whether or not I like promises. Yesterday I liked them, then this morning I didn’t… and now I’m back to liking them… I think. 

If you don’t know what promises are, read this.

I think my final position is: Promises have their place, but like all new-shiny will be overused.

Take a look at async.js which can achieve a lot of what you probably would want to do with promises, but a lot more simply and flexible.

The current state of complex clientside Javascript app development

If you’re looking to build a complex clientside javascript application (single page or otherwise), you really only have two choices.

  1. RequireJS
  2. Browserify
  3. Anyone that tells you GWT is an option is a dirty liar.
  4. Angular.js.  Meh… pass, even though it’s the new hotness.
  5. Polymer (pre-alpha) <== Go learn this now.  It’s the future.

I say complex, because most websites don’t use complex javascript.  (There isn’t really much structure needed to CRUD a few bits of data… do it however you wish.)

First… requirejs

It’s great and I’ve used it for a couple years and it has served me well.  It’s a bit convoluted, but it works, and for a while was the only solid choice.


IMO, the days of requirejs are over, and now we have browserify v2.

Browserify runs on node.js, which means you get all the fancy features of node — like mocha, headless browsers, DOM… oh, and you get the simple var module = require(‘module’) syntax.  Yum.

Browserify requires a build step (requirejs doesn’t), but it’s only marginally annoying.


There is also yeoman, which is for “managing workflow” which doesn’t exactly compare, but it can get you to the same ends and includes a package manager.  It’s a great place to start if you need to just-build-an-internal-html5-mobile-app.

I’ve used yeoman, but don’t use it anymore.  I find it easier to just build my own workflow out since it almost certainly changes between projects anyway.  Plus now that grunt doesn’t ship with since v1, I find it a bit cumbersome to set up…. maybe I’m crazy.

Yeoman also works well with angular.  In fact — I’d say it’s the best way to get started with angular.  

My favorite part of yeoman is it ships with livereload, but you can use livereload w/o yeoman.

Am I forgetting anything?

Oh yeah… a note about angular

I personally don’t like angular but know a lot of people do.  It seems like Yet Another Thing That Makes Javascript Work How I Want It To Work. (Looking at you CoffeeScript!)  

I question whether there is too much automagic going on — or if it’s all necessary.

Personally, I like javascript how it is, but as others have rightly pointed out: The great thing about javascript is that it’s flexible.  You can make it work how you want.  Just pick the tools that you like the best from the toolbox and go.

Weaknesses in gravatar. Nothing new.

I just noticed this article about politicians being unmasked via the gravatar service.

This is not news in my eyes.

About 6-7 years ago I was much younger and struggling to make ends. This lead me to (very) briefly consider alternate methods of earning some income.

Gravatar was the obvious target since the service uses md5(email) at it’s core — and this fact is so thoroughly entrenched in so many third-parties that they could never possibly change without imploding.

My plan was to:

  1. Get all the DNS zones to build a complete list of all domain names
  2. Filter the list by checking for mx records
  3. Generate a rainbow table for each domain name starting with most popular to least based on alexa traffic rank

This would’ve taken a long, long time to complete… but at the end of the day the list of quality email addresses is priceless.  

That list could be sold to spammers, or build a service around revealing gravatar email addresses at $1/ea.  Shit, you probably could still build that service if you wanted, and do pretty well for yourself.  

However, as I was about to put my plan into action, things picked up and the users of gravatar (myself included) remained safe for another day.

I’m surprised this is a new revelation and that more people didn’t see the obvious security/privacy implications of gravatar’s implementation.  It’s pretty dumb.

An update on my tommy thing-a-majig.  Originally, I planned to use voxel.js or minecraft as the simulator, but found them both too incomplete for my needs.

Instead, I grabbed an HTML5 maze game, ripped it open, and wired in tommy to control the blue square.  To do this, I just added some events, like a collision some movement related events.

Before you comment about how inefficient and poorly the maze is being navigated: The goal is not to solve the maze.  

Instead, the goal is to navigate a room of unknown size and with unknown obstacles, and bump into less things as time progresses.  

A maze is just a complex room or building, and I thought would make a good acid test for my idea.

As it stands, method 2 would probably make a pretty good replacement for the roomba algo, but isn’t exactly what I’m after.

That is why I’m working on an ANN version (brain.js).  I had it partially working… but have since broken something so it’s not included in the vid.

This is just step one.  I eventually would like to apply this concept to the other human senses such as sight, hearing and smell — and use it to be able to generate realistic responses to stimuli.

Loading... No More Posts Load More Posts