Recently we've been working on other kinds of projects. Here are some pictures of the deck we built. We originally had a deck, but it was splitering and falling apart after only a year. The builder used some really rough materials and littered it with nails to try to get it to stay together. We took the opportunity to make an even bigger deck while we had it all disassembled. We went for a simple design, 16' by 16' with composite wood decking.

Pre-build

Some family friends came over and removed the old deck. They pulled everything off the house, leaving just the old footings and the ledger board. We ended up replacing this ledger board since it was all marred up from the old deck. This was almost all the materials. We ended up needing some more/different 2x4s since the onces that were picked out were in rough shape. I tried to dig the footings by hand and with an auger, but the home builder left/added in far too many large rocks, so I rented an excavator to make short work of that.

Build

Once the holes were dug, we started work on the frame of the deck. We first laid out the upper frame and the basis for the beam over where the footings were supposed to be, and then filled the footings with concrete. This made it a little harder to fill the tubes, but it made sure the deck was square before it was impossible to move them and let us get it level for the posts the beam rests of.

With the frame complete, we could work on adding the joists and decking. We first attached the joists to the ledger board with joist hangers, then nailed them through the rim joist. We then added the hanger on the rim joist side. After the joists were in, we could start adding the decking boards. We used hidden fastners since we were using composite boards. They took a bit more effort and technique upfront, but the markless boards look great.

After all the decking was in place, we could attach the railings and balusters. This math was a little difficult to make sure we did not exceed four inches between the balusters, but had as similar as possible gaps for all sections. Since the balusters needed to span inconsistent sized sections, this took a little while to convince ourselves the math was right.

Post-build

To shade ourselves during the summer heat, we added an awning overhead. Luckily, our family had just pulled one off of their house, so we could recycle it on to our own, and it roughly matched. To mount the brackets, we needed to get some nylon spacers so we didn't need to remove the vinyl siding. We found a thickness that was slightly larger than the depth of our vinyl siding and mounting it towards the top of each piece so it wouldn't squeeze the siding. After mounting the awning, it took a bit to actually get the awning balanced. Some set screws in the arms of the awning move each side up and down separately.

The deck remained empty through the winter, and in the Spring we finally added furniture. To get an idea of what could fit, I made a really rough model of the deck in SketchUp and tried to see if everything we were looking at buying would fit. It ended up working out pretty good, and our size estimates were even oversized which made it easier for everything to fit. We tried to match the furniture to the decking color since the awning and house took on the green color. We ended up moving the grill closer to the sliding door, but we kept the couch and sectional in those spots. We ended up adding extra padding to the sectionals pillows since they were incredibly lacking. Also, we added connectors to keep the sectional pieces together.

Bonus!

We added some lighting! I took an extension cord, cut it in half, wired it into an outdoor box and then plugged some lights from Target into the newly-switched extension cord. Adding this switch makes it match the controls for the awning (it's powered in and out).

We got hornets! This wasn't the only nest either. We had both yellow jackets AND bald face hornets. We ended up getting an exterminator to remove both nests since consumer spray didn't seem to be doing anything. They ended up getting in a full protection suit and spraying into the nest directly, ripping the nest out and spraying the remains. On the bright side, we haven't seen anything since!

Been recently working on a few ideas.

Rocker

For the past two years Docker has been the big thing in devops. At Swipely, we use it from local development all the way to production. To remove any reliance on the CLI, we wrote a wrapper around the remote API: docker-api. We’ve benefited greatly from docker-api and use it in dockly and other private projects.

With Docker 1.8 just on the horizon, support is being added to copy files into a container. With that, the Dockerfile build tool is no longer reliant on the engine and can be abstracted out to a separate tool.

Rocker is a Ruby image builder that looks a lot like the Dockerfile build tool. Currently it supports only a few commands, but adding the remaining Dockerfile commands is much simpler. My plan is to support parellel RUNing, and superior caching including pulling in previous caches and rerunning a command. Rocker will share a lot in common with Dockerfile, with just a few niceties that I find extremely helpful.

App Deployer

Now, I really just don’t have a good name for this project yet. I’ve started working on something similar to aerosol for container deployment. Using a similar setup to fig, I hope to support bring up containers on a remote cluster of instances or locally. By updating a remote or local nginx upstream file, it’ll redirect requests from an old web app to a new web app. After reloading nginx, it’ll take down the old containers. I’m trying to remove the logic required to map a container port to a specific host port by updating the load balancer with the correct port after the fact. It might even be possible to load balancer TCP instead of only HTTP with nginx as well.

This one is very much in the early stages, but the DSL work is already done.

Otherwise

Besides these two projects, I’ve had a couple other things I’ve been working on.

Amtrak Status

Along with my daily commute from Back Bay to Providence comes the annoyance of catching the train. While Amtrak is usually on time, some days it could be more than 45 minutes late. Enter Amtrak Status.

Originally just a hubot plugin, hubot would reply with train listing after scraping Amtrak’s status page when asked: hubot amtrak from pvd to bby. This helped immensely at the end of the day when you were itching to head home. But… you had to ask. We just wanted to know.

Having written an OSX System Bar application previously, I built an application that would poll the status page every minute, giving you up to the minute timings for all trains, always visible from the system bar. A few updates later and we added the time to the top bar next to the icon. Up to the minute train times. Woo!

Until Amtrak’s status page changes…

Since everyones application was scraping Amtrak’s status page independently, if the layout changed then everyones application needed to be updated. Instead of dealing with this hassle, I wrote a gem: amtrak. The gem is powering a website: amtrak endpoint. Now if the layout changes, a few quick changes to the endpoint and everyones happy. No more relying on updates.

And for fun, I wrote an Android application around the endpoint: Amtrak Status. It’s not the prettiest right now, but I’m hoping to get an update out soon that supports push notifications when your train is late which is paired with some UI updates. Maybe someday I’ll get a real icon too!

Goodbye Ruby! Hello Jekyll!

Since this a blog and completely static, I’m switching the platform over to jekyll.

I ported over all the posts, and soon I’ll get around to working on making the layout nice. For now, this is what I’ve got.

Yay, static websites!