Makerbot Part 2

The second Round of  making the um.. makerbot has been underway. I’ve been put at a stand still while I wait for the motor that feeds the plastic in the extruder.

Small Dino: What relic is this? Big Dino: Relic?! Boy when I was your age this was top of the line plastic extruding nozzle. Relic HA Kids…

In the mean time I’ve made some good progress towards my goal and can’t wait to get this thing online.

Big Dino: For behold little one THE MONOLITH! Small Dino: *GASP*

Telecom Museum

I finally made it out to the telecom museum this week after being on my todo list for nearly two years.

We got the grand tour from a nice man who showed us some of the museums more creatively acquired pieces.

Hearing the mechanical switches and relays clicking and clacking as a call was being routing was an amazing experience. I could have only wished there was more volume of calls to hear the machines at full tilt. It must have been deafening to work in those rooms.

Amoung the dust I spotted a magnetic core memory module and our tour guide and I geeked out about early memory designs and weaving.

Westward

JonM and I spent the better part of Saturday finishing up his house for sale. I haven’t scrubbed that many floors since my days at Bob Evans.

We headed west with the destination of Ruby Beach in mind for some pictures and to get out of Seattle for a while.

We the took the edmonds ferry headed westward.

After a short stop in Port Glen we moved onto Dungeness Spit.

Sadly like in many of my hobbies both Time and Euclid were against us and it appeared if we weren’t going to make Ruby Beach before sundown. We pulled into the spit for some pictures.

This fellow kept an ever watchful eye while we took pictures of the sunset.

As it turns out he wasn’t alone.

Jon and I moved on to the larger spit and caught the sun as it was setting over Canada.

We stayed the night in Port Angelous and headed home way of this infernal machine.

It was an great way to chill out for a day and  geek out with our cameras. We plan to head west again in search of Ruby Beach and other destination with more time in tow.

Makerbot Part 1

I’ve had a bit of spare time these last two days and decided to tackle the Makerbot I ordered back in April. The kit comes completely disassembled down to the parts on the circuit boards.

The first part was to spray paint the body of the bot black. I’m planning to do green accents before final assembly. I can’t have my mini cnc looking like everyone elses now can I?

Next was the large task of soldering together the 11 circuit boards.

Here are the three stepper motor driver boards parts.

This was way more surface mount soldering than I was willing to do! The makerbot instructions page recommends using the “hotplate reflow technique”. The short of it involves squirting paste onto the circuit board carefully placing the components and cooking the board until the paste lightly sizzles. I was skeptical at first but $25 worth of hot plate and solder paste later it would seem this was the way to go.

The soldering went well until I lost a single surface mount capacitor which aren’t things you can just run down to your local 5 and dime to pickup. I had some electronics laying around to gut looking for an identical one. In this case an XBox 360 HD-DVD drive was scalped for the replacement part. While I was there I pulled out a few limit switches and the laaaazor! I’ll play with those another day.

Thus on I went with my reflowing. What happened late in the night I can’t even begin to calculate the odds of. I lost this part

On this floor.

When I finally got all 11 boards assembled I dropped one on the floor. And the missing cap jumped up at me having been shaken loose by the gods!

I quickly snatched up the cap and my board! I don’t know how much karma I burned but I’ll take my cap back!

With all the boards ready to go I’m moving on to the software testing then assembling the main unit

JRuby, RMI, and Turd Burritos

I’m pretty sure if I add up the “side projects” or the “can you look at this for a minute” time it is something close to 8x of my actual billing time. Not that I mind helping friends out. A fellow asked for some help on an application and these always tend to be a lot of fun.

Leviathan had been contracted to look at an old as in “your mom” application build on infrastructure dating all the way back to before there were keyboards and code was hammered out with chisels on stone tables. This particular application designer decided that the simplest route was to create a set of RMI request and bundle them into a Desktop client. A Java desktop client.

For those of you playing at home RMI is Remote Method Invocation. Think of it like shouting across the internet and telling a server to do something.

Java in all of its write once run anywhere glory has this funny way of being easily decompiled into source code. Thus once you distribute the client to a customer they basically can look at the internal guts of the application a lot easier than one would look at an application compiled in C or C++. Not that C/C++ can’t be decompiled Java just makes it trivial to do.

Now my coworker has the client, the source code, and a valid account on the server in question. The world is basically his oyster, right? Well as it turns out some oysters don’t like being opened.

Queue: The enterprise turd burrito. Turd Burrito or ETB for short. If you have a turd that you want your enterprise infrastructure to swallow than you just keep wrapping it in beans, rice and salsa until the IT guys that payed $9.50 don’t realize “it’s not meat”.

To make RMI easier to use and more firewall friendly many J2EE providers wrapped RMI in multiple transport layers. Most notably HTTP, SSL, and some special sauce we’ll call “Voodoo magic” This makes the IT guy happy. “I only have to open one port”, the security guy shrug, and the developer only marginally less happy. They have to make sure all of their objects really cleanly Serialize (get turned into one long string), but they were going to have to do that anyways.

So just to make sure you’ve got all of the above in your head.

Client
-> Takes an object
-> Makes it serialize
-> Calls a method
-> RMI voodoo magic happens
-> Unknown Magic
-> HTTP
-> SSL
-> Turd burrito is flung across the internet at whatever server is supposed to eat it.

The way RMI is built it is supposed to make everything past “calls a method” look like magic. You aren’t supposed to know where or how your method is being called or passed. This could be on the box next to your feet or calling a method on the Mars Rover. As a developer you’re just supposed to call a function and get a value back. This is great if you are a J2EE developer that wants to take out that hottie from accounting. Bad if want the control required to tinker with the thing.

Proxying the RMI methods was not something I was willing to do. I wasn’t peeling that many layers of beans and rice, then only to deal with serialization issues. I had the turd sitting right in front of me with the source and methods quietly mocking me. What I needed was a ETB eating machine.

Enter JRuby.

JRuby is the bastard child of a ruby interpreter written in Java and is my new very bestest friend. JRuby is the kind of friend that drools on you occasionally, has a gimp eye, but LOVES to chew up turd burritos. As a note Matasano wrote about using RMI via JRuby a while back.

Now what used to look a task of proxying.

Client
-> Takes an object
-> Makes it serialize
-> Calls a method
-> RMI
-> Unknown Magic
-> Http
-> SSL

Becomes one line of code.

com.XXXX.XXX.ui.net.Request.new(com.XXXX.XXX.ui.user.gadgets, cd, com.XXXX.XXX.ui.Function.DOSOMETHING, new Object[] { com.XXXX.XX.Thing.new(1) }).send();

Instead of unwrapping and rewrapping my ETB. I can inject my own chili peppers hoping the server can’t handle the heat and pukes.

Thus like magic my drooling friend JRuby has given me all the control of a hacker, but the comfort and “going home at 5pm on the dot” developers view. Now if I can just find someone to take out in accounting…

So the lesson to be learned is.
1. Less is often more.
2. JRuby rocks my socks even if it does drool a bit.
3. Don’t trust your users.
4. Yes someone will take the time to
Decompile the application. -> Find the right remote request -> Hook in with JRuby -> Make fake objects -> Send them off to the server -> Profit!