Desktop 3D Printing

There’s interesting work going on in 3d printing now.  The technology is being brought from the high end right down to the hobbyist.

Most fabrication processes that we think of, machining or sculpture, involve removing material from a piece. Think of Michelangelo chipping away at a block of marble over the course of months and years. With 3d printing you can design a model (usually a CAD drawing) and translate that model into instructions of where and when to add plastic till you have a completed sculpture. If sculpture isn’t your thing, you could also print a water bottle, blocks for a child, or an iPad cover.

With less than $1,000 you can build a 3d printer that will output small items made of plastic. The RepRap Project is an open source movement to put 3d printing in the hands of hobbyists worldwide.

Early stage companies, such as Makerbot, have released a couple of iterations of 3d printers.  Makerbot has their own Thing-O-Matic available.  The RepRap Project is an open source movement to put 3d printing schematics in the hands of hobbyists worldwide.  LulzBot is selling kits to build your own RepRap printer.  They also sell the parts to build a MendelMax, a new RepRap variant.  I’m going to build a MendelMax in the next couple of weeks to get a foot into this world.  Here’s to some entertainment.

Living with Node.JS in the world of Ops

This post comes out of some retrospective thinking this month.  I worked on a middling sized Node.JS install for the last three quarters.   We had a whole pile of javascript that ran in a web browser and a handful of Node.JS processes running to deliver that javascript and answer all the API calls it made.

The first thing to note is, we did not use Node to do the heavy lifting.  If it involved touching a database it was shoved out to a LAMP app.  A lot of folks will probably ask why we didn’t use something like MongoDB or another similar DB.  Short answer, we couldn’t find anyone who was using it with the kind of volume we expected who had great things to say about it.  There was one really scary response which amounted to ‘we have a dedicated Ops guy keeping MongoDB running for this app.’  If the choice is to hire an Ops guy solely to keep a single DB running or to spend the same money on an engineer writing new features on a well understood DB,  then it’s a pretty easy choice in my view.

Node acted as a middle layer to process a number of API calls.  The company had tons of data in a few different locations, Redis, MySQL, HBase, etc.  After grabbing it and parsing it up it would get shoved out to a connection.  We learned quickly that the way we were going caused Node to crash on us regularly.  In goes Forever, this little Node module restarts Node when it crashes.  You’ll need it quite a bit early on.  We also put Nginx in front of all our node processes.  Nginx is a great tool for reverse proxy load balancing.

From an Operations POV the app was a black box.  Requests were made, stuff happened, a response occurred.  Sometimes it was a HTTP 200 with valid data, sometimes it was a 500 and we had no idea what was going on.  To deal with this I ended up implementing lots of StatsD checks.   StatsD is a small, lightweight Node server and accompanying libraries to allow you to implement a few basic types of checks on events and network calls.  It sends the results out in UDP packets.  This has the advantage of being very low overhead and not requiring the receiver to be alive.  I updated a version of the StatsD library for JS that Steve Ivy wrote.

From here we could trend everything happening inside the app.  New release is a little slow?  Oh, look!  It’s making 50% more calls to Redis, something is up.  In the Ops game this is great data, I can use all those finely honed visual processing skills to see behavior changes in the app quickly.  That’s about it, I’ll be fleshing this out later.