Why is Our Community Important

Why is Our Community Important

At Upverter we want to make the world a better place. And we think we can do this by making electronics more accessible to hobbyists. The problem with hobbyist electronics is the tools suck and that makes the electronics part a lot scarier than it really is. Better tools = friendlier = more people hacking on hardware = better world!

So why the focus on community? Its a little self explanatory – but at some point hacking alone in your basement gets lonely and demotivating. How many more projects would you finish if you had a group of people cheering you on, and helping you solve the hard problems? Like most things, hardware is better in a community.

A while back I worked on a solar charger for my laptop, it was going to be more efficient and cheaper then what was on the market (and I got to play with solar cells!). The only problem was that I had not actually made a real circuit from start to finish before, and retrospectively, did not know many of the real world problems with putting together a piece of hardware.

Luckily I lived with one of the best hardware engineers that I know,


. He took one look at what I had and told me that transients would kill me. After much help from him (thanks Zak!), we eventually came up with a design that would not fry my components, or my laptop (and would maybe help power it too).

So what is the point of this story? Simple: after reading textbooks, looking up on-line, and even having a reasonable amount of education in the field, I needed help from someone with a different perspective and a lot more experience. Without him I would have been on my own in my basement banging my head against the wall, maybe solving the problem, maybe not.

Either way I would not have enjoyed the experience. So the reason that we need a community, and the reason we are building one, is so that you too can have a Zak, and we all won’t have to be alone in our basements. Upverter is going to help make more people into hobbyists, hackers and engineers, because we are going to make it really easy to help each other. After all its the people that make hardware special.

Building Better Javascript (Through Testing)

Building Better Javascript (Through Testing)

Last week I talked about our Javascript tool chain. One piece of our chain that we’ve invested quite a bit of time in so far, is testing. Our reason for spending so much time: making tests easy to write, run, and manage increases the odds they’ll actually get used. We looked at a few different unit testing libraries when we were getting started. Our requirements for a unit testing library were:

  • able to be run from the browser and the command line
  • cleanly written (to make extension and modification easier)
  • not tied to a particular framework (didn’t depend on a specific JS library)
  • low on boilerplate

The best fit that we found was QUnit. It’s the unit testing library used by jQuery. It’s a very cleanly written library that already has some hooks for integration with browser automation tools. QUnit has a very minimalistic interface. Knowing the functions ’test’, ’equals’, and ’ok’ is all you need to get started. Here’s an example:

test('point in middle of granular region', function() {
  var map = new up.common.BucketMap(10);
  var point = new up.common.Point(5, 4);
  var keys = map.locationKeys_(point);
  equal(keys.length, 1, "Only one key for point locations");
  equal(keys[0], up.common.BucketMap.BucketKey_(0, 0));

QUnit on it’s own is great. But there are some very real points of friction that we found with our process and other tools. The big ones are:

  • Managing dependencies with tests
  • Dealing with overrides/ injecting mocks
  • Keeping test HTML in sync with the JS
  • Being able to run tests in one click/command

The first and second points come from our embracing Google’s Closure library. Being able to break up our application into proper namespaces and classes has been great for development. When you go to run a test however, you need to make sure that all of the right dependencies get loaded. The third issue crops up when you have tests that need to interact with the DOM. They may need certain elements or structures to be present to effectively test a unit of code. In most examples that we found a separate js and HTML get created. The HTML files is used to bootstrap the testing environment with the correct dependencies and DOM. The last issue is dealing with lowering the friction to test. If you have to type in 5 commands to run a test, chances are you’re not going to test very often. To solve all of these issues we’ve cooked up a QUnit/closure testing harness. It’s main features are:

  • test’s are a single js + HTML + list of custom dependencies
  • dependencies get dynamically loaded and overrides are used to allow for easy injection of mocks
  • can run multiple tests in a row, cleaning the environment and dependencies in between
  • has hooks for running from the command line as well as the browser
  • the entire set of unit tests can be kicked off with a single ‘scons jstest’

It still has some issues when the tests contain syntax errors, and the command line version still blows up occasionally, but it’s helping to make the Upverter testing process smoother.

UI/UX Design

UI design has reared its (yet to be beautiful) head here at Upverter. Whenever I think of UI/UX, and especially right now, while creating the look and feel of the soon to be community, I am reminded of Steve Krug. Krug wrote two of my favorite UI/UX books, Don’t Make Me Think and Rocket Surgery Made Easy. They are simple, straight forward, down to earth, quick reads and if you have anything to do with UI/UX (or even if you just want to know why you hate software) you should go read them now!

Don’t Make Me Think is about UI/UX design, and it has, and will continue to influence our design. So I thought I would share a few principles that I found to be particularly helpful when I was wrapping my head around this stuff.

  1. Users are on auto pilot, they are not thinking about your fancy navigation, or Tron inspired color scheme. They are very often looking for something specific, and if they don’t find it, they WILL leave.
  2. Breadcrumbs are a good thing; designing your site like it’s Home Depot is not a good thing. On websites you can enter anywhere, and jump to a completely different location in the site. And worst of all its like teleporting, not like wondering around a store. So always make sure that the user has a good way to know where they actually are.
  3. Assume that the user is going to scan your page, not read it. (HUGE!)

Rocket Surgery Made Easy on the other-hand is about usability testing. It’s basically a how-to guide on doing a self run usability test (where you strap a person to a chair, and talk them through using your website while you watch the difficulties encountered). And we are just starting to do our very first batch of these here at Upverter (which is why I’m talking about it today).

The thesis of the book is that you should absolutely be doing usability testing, throughout the entire design, early and often, and even when all you have is a picture on a napkin. For me, the number one takeaway is: Anything is better than nothing, and usability testing can be done in half a day; so there is absolutely no reason that we should not be doing it! This was a new idea for me.

I had always believed that usability testing was a huge project, a time sink, and only worth doing when the site was polished. But with my newly opened eyes, I highly recommend everyone take the time to get user feedback and make the web a friendlier place. There are a lot of good UI/UX books out there, and if you are interested in the subject (or have no idea what users actually think of your software) you should start with Steve Krug; his books are definitely worth the read!

Intro to Open Source Hardware

Intro to Open Source Hardware

WTF is open source hardware?

Why “open source hardware” instead of just “open hardware”?

Do I care?

Open source hardware is on the rise, and enormously. At the bottom of this post you’ll find a bunch of great links to content on open source hardware topics created over the last couple years, which will give you another few perspectives. And I’m going to do my best to explain the subject and a little bit on our involvement in it here at Upverter.

First off, open source vs. open. I’m not sure how big a debate this really is anymore, but it comes down to intent and language, as they do mean different things. Think of the word “open” as describing the word immediately to its right. For example, open software is software that is easy to interface with, or that saves to XML files, or that provides a really kick-ass API – basically, the software is open to being hacked on. Add the word source to the mix and its a different story, open source means that all the bits i need to build my very own, hack in a feature, or debug an issue, are public and available. In the software example the program is probably also very open, but the important part is that the source (the stuff required to build one) is open and accessible; and its the exact same in hardware land. Open = good documentation, lots of programmable IO, open standards, open communication, etc; While open source means usable schematics, CAD files, firmware, etc, etc, all the bits needed for a user to build their own. Expect to see lots of established businesses releasing under open hardware licenses, while the hackers and hobbyists will use the open source hardware licenses.

Now before I tell you what this word game is all about, I want to give you a couple of reasons why you probably care. The first big one, is the absolutely tiny number of leaps in human understanding and knowledge made through closed information. Open information and shared knowledge allows us to “stand on each other’s shoulders, not each other’s toes.” (Dennis Allison), and while we accept the need for the commercial electronics market, and understand their need to privacy and competition, remarkable things can be done through working together. We are also nearing a point of critical mass (it happened with computers and open source software a decade ago) where there are enough people with enough great ideas that they can start providing the market with competitive and open alternatives (Apache, MySQL, etc in the open source software world). And lastly because not every great idea or invention exists to make money. These are ideas that can only exist in an open and shared environment, these projects are peoples passions not their day jobs, and they should be encouraged. So you care because you’re a hacker and you want to exist in an environment with open and available knowledge and designs, or you’re a bookie and you want to know what to bet on next, or you’re a consumer with pain points and you realize that a community enabled to solve your problems, just might, given the right tools and the right critical mass.

So, cut the flowery shit – what is OSHW? Open source hardware is a label given to an electronics project that is released and made public in such a way that you, average Joe hacker, could build your own. There is a bit of variance here, but purely speaking that means publishing everything: all the manufacturing details, CAD files, firmware, HDL code, schematics, and even the source code running on the widget. Not at all unlike tweaking, compiling and installing your very own port of Apache – you should be able tweak, and create your own port of an OSHW design.

OK cool so I just copy and paste one of those license file things and I’m good to go?

Thats the idea! Now being all squishy and new the licenses are still catching a bit of flack, and its not clear which license to use, and there is no good way to share your design files… BUT! Zipping all your bits and pieces together and saying its OSHW is a pretty damn good start. And even still, I’d wager we aren’t too far away from seeing a lot of unification on these last few issues.

Note: From a legal perspective you aren’t really well protected from people pillaging your designs. Unlike source code, copyright does less to protect a schematic and the instantiation of it (a circuit board) from being taken, manipulated or mass-produced. So a big part of the holdup is finding ways to protect businesses so they can release their products without too much risk. But individual hackers should be good to go. For most hackers, at the end of the day its all about sharing knowledge anyway!

Where does Upverter fit?

We have always been garage hackers. I’ve personally torn apart, hacked, blown up and gotten fried by more appliances, toys and household widgets than any child could, and still expect to make it to adulthood intact… But as a business I guess we, a little bit, stumbled into this space. We thought it would be great to try and build some tools that improve the hacker experience; and sure enough right around the time that we’re thinking this is a great idea, the scene is exploding with projects, ideas and neat new labels. So, in a sense, we’re riding the wave along with all the hackers out there. However, you can count on us to make the collaboration, sharing and shoulder standing a whole pile easier. We like to think our tools will be a catalyst to make this market explode (in a good way!).

In the coming weeks I’ll try to talk a bit more about the movement, how our space is developing, and where we fit. But for now: check out the links, buy a $20 kit and a soldering iron, build something cool, and share it with the world. I promise, once you get started your inspirations will be limitless.

Open Source Hardware Articles





Our Javascript Toolchain

Our Javascript Toolchain

Javascript is a language that imposes very little on the developer. The web is littered with Javascript that looks like it was taken from Enterprise Javascript. To bring some sanity to our lives we’ve assembled a set of tools to help in our development efforts. The Javascript tool chain here at Upverter is comprised of:

  • customized qunit and testing harness
  • SConstruct build files for linting, compiling, unit tests, documentation generation

You’ll notice the list is quite Google heavy. When we were starting in we had a discussion about how much of the Closure coolaid we wanted to drink. There were a few concerns we had:

  • It could marry us to the compiler and library. If something better came along it could be painful to switch.
  • The overhead from annotating our code would drive us insane

It has some pretty big positive aspects going for it too:

  • Type annotations encourage documentation
  • Static analysis lets us shake bugs out faster and helps us refactor more confidently
  • There isn’t anything remotely comparable out there for static analysis and compilation

In the end the pros outweighed the cons and we dove in. It’s worked out well so far. Having those tools in place is helping us write better, faster code. (although gjslint’s whiny, inflexibility has resulted in more threatening of an inanimate object than is probably healthy) Lastly there are a couple of resources that I’d like to share in case you haven’t ran into them. Javascript can be a tough language to search for. These links are great starting points to find good answers:

‘Tis the Season to do Hardware

‘Tis the Season to do Hardware

Back in the day (ie. before I quit my job to start Upverter) I worked at what was once a software/hardware start-up in Waterloo, Ontario (they’re still there – just too big to still be a start-up). A lot of people, especially those in Waterloo, like to sell how smart and vibrant the tech center is there. And I think that’s great, you gotta sell what you love; and you gotta love where you live. But it really is a pretty tiny industry by comparison to Boston, or the Bay area. That being said, they sure do niche hardware pretty well, RIM being the best example I guess, despite how mainstream their devices became.

So, I worked for one of these hardware companies and we built some pretty seriously kick-ass network devices. These boxes, on all accounts, pushed the limits of speed, traffic, wattage, and weight. We were doing 10GB/s multiplied-by maybe 50 links throughout the device, with 16X11 cores and 16x11GB of RAM. We had a couple tons of AC running full tilt in the winter just to keep the building bearable, there was the time we punched a hole in the dumpster tossing a couple junkers out (they’re like 120lbs each!), and we fit it all in 4RU and 2K watts. Like I said: bad-ass.

Anyway, you don’t just get lucky when you try and build a box like that. The signal integrity, power-distribution and green-gremlin-voodoo-black-magic shit that goes into one of those devices actually doing what its supposed to is, well, overwhelming. But that’s the price you pay for being on the bleeding edge – the alternative was probably 16 odd 1RU PCs and a fuck-ton load of networking equipment = gross. But where am I going with this? Well its getting on to Christmas. We have about a meter and a half of snow outside the Upverter office windows, the stores are rockin’ jingle bells and somewhere, at some small hardware startup, there is a hacker furiously working away on making some piece of hardware work the way its supposed to, just minutes before the shipping deadline, which happened to be last Tuesday. I cant really explain it (year end? tis’ the season to buy hardware? I dunno), but for a lot of us hardware guys, Christmas = shipping deadlines = all-nighters = eggnog, spiced rum and soldering irons.

And not to rag on the startup companies – because really, you gotta do whatever it takes. But I want to give my nod to those hackers. Having been one of them, I know how hard it is to stay focused, to hack despite the million better things to do, and probably biggest of all, to hack despite being away from your family at just the wrong time of year. Its hard, and it sucks, so kudos to you guys – and like they say where I come from: good on ya. I hope you’re working at the right kind of startup, that they get it, and that they are taking good care of you. And if they aren’t, I say just make a stand that you won’t solder without the proper supply of eggnog and rum – they might not get it, but it’ll be easier to handle drunk… haha.

Perhaps my favorite personal story of a Christmas shipping crisis (and I’m gonna do my best to obfuscate it a little, as I’m probably not allowed to talk about it) was one year when right before our December 12th shipments we not only ran out of everything we needed to ship, but we found an epicly bad power bug (ie. shit blows up randomly during normal operation, but just outside of our window of test. and worst of all, caused by the design). We ended up shipping, I think on the 24th, but it was pretty down to the wire. I think there is a picture of me in a Santa hat loading boxes on to a truck, or kissing them goodbye or something – it was a pretty big deal. In the end we were able to order replacement parts, setup a half dozen soldering stations running 24/7 and hack 500 or so boards through in a few days, in time to assemble, test, triage and ship. probably the worst part was the few days between the 12th and the material delivery where there was zero to do. Just sitting around waiting for the tidal-wave to hit. And when it did, it hit HARD! Thankfully the guys I was working for at the time were pretty great about making sure we were tended to and happy, which made it all the more bare-able! and in the end we won. Which I guess, gives me another story to tell!

Invite me out for beers sometime and I’ll tell you all the gory details, but for here and now – have a good holiday. And I hope you’re not huddled over a soldering iron, but if you are: good on you, good luck, and get home soon if you can!