Startup Reading List

Read? What are you crazy? We’ve got work to do!!!

That sounds a little like me harassing the troops, but don’t worry I’m smiling! Haha. As a bit of lite and fluffy Christmas reading I thought I would diverge from my hardware stories and my OSHW rant to share a bit of startup wisdom. This is the as-official-as-it-gets Upverter Startup Reading List. Back before we started Upverter there was a fairly enormous Google Wave that for a couple months seemed to be growing exponentially. It was basically a dumping ground where we all put our personal reading lists and then any new finds we stumbled across. Maybe because there was a lifetime worth of reading on it, or maybe because we had exhausted the ISBN index, I’m not quite sure, but the list eventually stopped growing.

Personally I’m maybe 1/10 through the list, Steve is probably close to half way, and Mike is a lost cause, haha. But either way, I wanted to share our favorites from the monster list. The stuff we think you absolutely need to read if you ever decide to do the startup thing. The list is a little software oriented, and that’s really just because we are building a startup that builds software, and so that’s a focus for us; but you could absolutely trim the software titles and kick-ass with your revolutionary pet rock business!

Upverter Must Read List:

Basically you’re off the team if you haven’t read these.

  • Code Complete, Second Edition This book is on more programmer book lists than should be fair. Its a must.
  • Rapid Development Right up there with Code Complete, this one normally seems to rank second on the book lists. Again a software book. Also a must.
  • The Pragmatic Programmer Don’t fix something that isn’t broken, this book often scores around 3rd. Again a software book. Also a must.
  • Peopleware This book is probably the most important management book of all time. Ever. If you ever have to work with another human being, ever, you should read this book.
  • The Mythical Man Month This book goes hand in hand with Peopleware. If you ever, in your working life, will have to make a schedule – read this book.
  • Don’t Make Me Think This book is down to earth usability. If anyone ever has to use something you build – this will explain why they hate it or get lost inside.
  • The Art of the Start This book is pitched as for anyone starting anything. And thats a pretty good take on it!
  • The Tipping Point Epidemics, viruses and human behavior. Another great read!

Upverter Reading in Progress:

The books on our kindles and iPads at this very moment.

Upverter Next in the Queue:

If I ever make it there, I have to conquer these next…

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,

Zak

. 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


Communities


Shops


Twitter


Licenses

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: