One of the more interesting technological developments I've been following in the past year has been 3D printing. The promise of this technology is to allow normal people to produce complex and useful items at home, preventing the numerous costs and logistical issues associated with traditional manufacturing. And in my brief experiment with 3D printing thus-far, the technology appears to be taking great leaps forward towards this vision, and the prospect of being able to print your very own tools and art both greatly excites and interests me.

My first experiment with 3D printing was something I had in my mind for a while. My primary camera is the Panasonic GF-1, which is quite fantastic for a number of reasons, except for the fact that Micro Four Thirds (MFT) lenses are generally much, much more expensive than their Four Thirds counterparts (namely supply/demand). For example, the cost of a MFT macro lens can easily fall north of $500 – which is too expensive when I only take the occasional shot. I had also previously stumbled upon how to create a make-shift macro lens using the properties of an inverted lens (which works by focusing items at a distant focal length onto the camera's sensor) by simply flipping the lens around. However, the inverted lens does not fit into the threads on the camera body and is difficult to hold stable, which results in poor image quality. Any sort of shaking and movement is a problem, especially considering how shallow the depth of field is when you invert the lens (for my 14-45mm zoom lens, likely at the native aperture of f3.5) and how little light there is when you are up close to the object you are shooting.

Having previously bought a make-shift pinhole camera lens for my camera, I also knew that it was possible for a non-official lens adapter to be inserted into the body. And using that as a starting point, I began construction of a similar adapter which would have threads to bind the camera and the inverted lens (via the threads normally used for the lens hood).

Concept design of the inverted lens adapter including various dimensions

Look of the adapter from the front and back

What made this a great starter project was the fact that the design was relatively simple, which meant it was easy to create a 3D model. And after a few short hours in Maya, aside from some small issues with dimension conversion (I accidentally uploaded the object at 0.6cm vs 6cm the first time), it was soon on its way to Shapeways' 3D printers.

Model of the adapter in Maya

A couple of weeks later, my model finally arrived in my mailbox in a smaller, more unassuming box than I imagined. The Strong & Flexible Plastic material looked rough to the touch, and although it felt rather weak due to its feathery weight, putting it to real world use proved that it was about as sturdy a construction as I needed it to be. Unfortunately, it was also at this point that I noticed that I had made a fundamental flaw in the design! In my haste to get this to the printers, I failed to notice one small piece on the camera – a push-pin on the base of the lens frame that when pressed, triggers the internal electronics to expect a proper lens to be attached. In particular, when this push-pin is depressed, it allows the camera to take pictures while there is no actual lens attached, and since this part of my adapter was solid, it kept the push-pin pressed, preventing the camera from being able to take any pictures at all.

Picture of the adapter on the camera (sans lens)

Luckily, I was able to borrow a power drill in relatively short order from Adam and make a hole for the pin – a process that both confirmed the sturdiness of the construction and also revealed the white plastic resin under the outer black surface.

And with the lens attached (noticed how the lens is attached backwards)

With everything constructed, it was now possible to take some pictures!

Close up of the drill bit that saved my design :)

More macro pictures will be uploaded to the in the gallery.

Overall, despite current limitations in the types of materials that can be printed, the precision of the printers, and the whole process of having to model your object, everything came out better than I had hoped or expected. 3D printing appears to be a very promising technology, and the prospect of being able to personalize my tools to solve my specific problems is fascinating and exciting.

I am looking forward to making more stuff!

Side projects are fickly things and when you are working on something that you can’t always schedule consistent time for, I've found that having an environment that allows you to resume work as quickly as possible is really important. While migrating to AWS and EC2 last year, I came to the realization that the cost of having to synchronize between server and local development environments would quickly become a nuisance, dissuading me from putting in the little bits of time between work and class to finish my side projects.

Instead, by creating a single setup on the server, I could strike two birds with one stone by reducing the overhead of spinning up as well as tightening up the development iteration cycle (also very important). The immediate question of connectivity was a potential deal-breaker, but the combination of ever-pervasive wifi and the ability to fall back to tethering to my Galaxy Nexus meant that it has been a non-issue in my experience this past year. I’ll explain a bit of how my setup works below.

My EC2 servers run Ubuntu and a large part of working effectively in Linux is getting comfortable with the command line. As tmux and vim are two of the largest parts of my setup, I’ll elaborate a bit more of how I use them in this particular post. Both tools have great documentation (and user support) and both share the same positive characteristic of not trying to get in the way of your workflow.

Firstly, tmux is a terminal multiplexer that allows you to create, organize and manipulate virtual terminals. Instead of having multiple terminal windows open in your primary OS, you can instead keep a single tmux session open on the server that can be shared across all your different devices. I personally run tmux in my bash profile, which means that I’m never in the default Ubuntu shell, and the convenience of being able to come back to the exact same set of terminals with the exact line I was on after a week away is immeasurable. Most commonly, I find that I have between three and six virtual terminals open; one for mysql, one for vim, and the rest scattered throughout various project directories. Naming them early will help you prevent future headaches, and because I work from smaller 13” laptops, I’ve found that keeping each of them at full screen works out well. Having a full screen also facilitates my heavily usage of split panes in vim. There are a few downsides to using tmux though, it is a little harder to switch terminals (Ctrl+b,n/p), and scrolling a virtual terminal in OSX does not seem to be fully supported out of the box... but after a short period of use, the benefits of using tmux were clear.

The primary tool that I use is of course vim, which is where “all the magic happens”. I’m sure I could dedicate an entire post to what vim is, the various modes and how to use it, etc., so for the sake of brevity, I’m just going to explain a few of the tips that I use to reduce the pain of developing without an IDE (or a mouse).

In no particular order:

• Enable sane search options including incremental search (incsearch), highlighting the search results (hlsearch), and case insensitive searching (ignorecase)
• Remap A (Shift+a) to jump to insert mode at the front of the line, and I (Shift+i) to the end, you’d be surprised how many cases those two keystrokes cover
• Remap Tab and Shift+tab to effectively shift-and-reselect in visual mode to mimic modern IDEs (ie. and >gv)
• Learn to use, and love, Ctrl+u/d to page up and down in visual mode (it gets you around quicker and does not wear on your sanity)
• Set timeoutlen to 250ms to enable you to remap double keystrokes (ie. ,, to escape input mode, or ,s to save overwriting changes, etc.)

And perhaps the most useful tip I’ve learned over the years working in vim:

• Map Ctrl+v to vertically split panes on the fly, and Ctrl+h/l to jump left and right between panes. It is incredible how seamless it is to be able to quickly pop up two or three different files side by side, makes some related changes, and close them back down without losing your previous context.

That said, there are still a few small frustrations with working in vim that I need to fix on (partly spurred by this article), namely, “find”ing files in the project is still a pain (since there are often similarly named files, like controller/search.php, views/search.php, cs/css/search.css and I don’t particularly like the idea of adopting a full project-style-plugin). In addition, splitting aside, general text editing is still easier with an IDE where you are also less likely to wipe out a part of your buffer when you accidentally rest a book on your keyboard while in visual mode :).

Lastly, it is important to keep in mind that working on the server doesn’t mean you stop using best practices. My projects are still organized into development and production environments on the server, versioned using git with periodic backups to local machines. But working on the server does allow you to minimize the iteration loop (writing, testing and deploying code), and investing a bit of time up-front to set up such an environment can result in a simpler, untethered development process.