Dual-Display Battletop

Meet my new battletop.

I’m using the Mountie with an iPad Air 2 and a maxed out current generation Retina Macbook Pro.


The Mountie from Ten One Design is the ultimate Macbook accessory, because it enables you to mount an iPhone or iPad to your Macbook!


Duet Display is my software of choice to turn the iPad into an extra display. Instead of bluetooth, Duet Display requires the lightning cable. This is ok because it eliminates any noticeable lag.


My Battlestation

Welcome to my workspace. This is where I build and support the mission-critical service Status.io


Using fake views (for security) to mimic my environment

The hardware

Machine: Apple Mac Pro (6-core, 64GB, 1TB, D300) — My first pro Apple desktop since the Power Mac G4.

Almost every review of the Mac Pro is focused on working with video. But this machine is fantastic for developers and sysops too. This beast outputs to 6 displays and the 64GB RAM not only allows you to spawn dozens of virtual machines, but you may also keep all of your apps and tools running and in your desired state forever.

Why 6 displays? Because I love my users.

3 of the displays are my main focus areas. The 2 top displays are primarily for monitoring purposes (graphs, logs, alerts, etc) and the left vertical display is more monitoring plus communications. I do frequently use all 6 displays to perform a task. For example, when I’m troubleshooting I use many tools and I need them all open and visible to eliminate mistakes made from trying to remember what I just saw in a view that’s now hidden.

I was skeptical at first, but the 6 display setup has caused my productivity to sky rocket.

Display 1: Apple Thunderbolt

Display 2: Apple Cinema LED

Display 3: Asus PA248Q (24” 1920×1200 LED IPS)

Display 4: Asus PA248Q (24” 1920×1200 LED IPS)

Display 5: Asus PA248Q (24” 1920×1200 LED IPS)

Display 6: Samsung 2433BW (24” 1920×1200 LCD) + Neo-Flex Stand

Camera: Logitech C930e

Inputs: Apple Wireless Keyboard and Magic Trackpad

Battery Backup Belkin 1500VA UPS

Storage: 12TB external (I use various economy drives)

USB Hubs

Internet Pipe (primary): Cable 150 Mbps / 15 Mbps

Internet Pipe (backup): LTE 40 Mbps / 7 Mbps

Other stuff on my desk


UTC Clock – HighStar USB (I can’t program it, I just wait until 12:00 UTC to plug it in)

Chair: Steelcase Leap (Forever comfy)

Desk: IKEA Galant (Adaptable and holds all of my gear with plenty of space left over)

Monitor Stand: Vivo Quad LCD Heavy Duty (I use this for the top displays only)

Paper: Rhodia dotPad

Pen: Pentel Rolly C4

Eyewear: Gunnar Weezer Onyx

Headphones: Bose SoundTrue with Sennheiser HH-10 holder (Always playing trance from Digitally Imported)

Mobile Machine: 15” rMBP (In case I need to step away)

More views

The back of my system and the front of @supersuperjessi‘s setup.


And 1 more…


Thanks for checking out my battlestation!

Follow me @joet3ch

Announcing Status.io


I’ve finally decided to follow my passion and build the status page platform that I have been dreaming of.

The most frustrating experience for a user is when there are service issues and they don’t know when things will return to normal. This causes support requests to spike and damages user trust. I want to make it simple for companies to maintain a system status page.

Check out Status.io

Monitoring your API with Python and SES

I needed a quick and simple script to monitor some of the API’s I manage. Since I already build in methods that fully test the webservice and backend database, I just had to wrap a single call and check the results from this method. Also I don’t want to rely on my servers being able to send mail, so I added support for AWS SES.

And the code…

Using EC2 Auto-Scaling Groups with Fabric

Trying to deploy fabric recipes to an auto-scaling group on EC2 could prove pretty painful, except if you have this slick code snippet to define your server group in Fabric.

Basically I’m using boto to list all of the instances currently running in a specific security group, and then populate env.hosts.

This solves the problem for pushing to running hosts. In order to pull the latest codebase when a new instance fires up, we just stuck some scripts in /etc/rc.local — more on that later.

A few minutes with DNSCrypt

I checked out DNSCrypt today, a new tool to help secure DNS resolution by encrypting the lookups from your machine to the DNS server.


The tool was developed by OpenDNS and is currently a preview release.

I just wanted to see the DNS traffic, so I performed a few lookups while capturing the packets…


Here is an example of a non-encrypted query:


And an encrypted query:


If you enable the lookups to traverse port 443, there will be tons of packets and I didn’t look at them.

One note worth mentioning — The client app creates a bunch of connections back to OpenDNS whenever you modify the settings.

This is some great technology and it is open-sourced. I’m assuming the networks who want total control of their users will just block the OpenDNS IP blocks to prevent users from encrypting their lookups.

You can fetch the source on GitHub — The entire Mac OS app is there!