Category Archives: Work

Xcode Server Slack Integration

After spending a day last week struggling to get a working integration of Xcode Server and Slack (the popular messaging platform) I finally have arrived upon a reliable solution. What started out as a long bash script (and sed, and cut, and tr) that eventually called a Python program, is now just a Python program run by the Xcode ‘Trigger Script’ functionality. Read on for how I did it.

Working with a client on an iOS app we wanted to keep everyone aware of the project’s progress and the current state of all tests, both server and iOS. So, our team added the client as a Slack single-channel guest and got to work integrating our server-side Strider Continuous Integration server and Xcode Server.

Not knowing any better I dove into the output of the Xcode Build located in /Library/Developer/XcodeServer/IntegrationAssets and poked around. I found the file buildService.log which contained build output detailing everything I needed to know about the build, looking like this:

Which, I immediately thought, “I know, I’ll tackle it with bash and sed!”. So I got to work writing a script to parse these entries and ultimately distribute them out to our Slack channel so everyone can see progress as we go along. Here’s the bash script I wrote:

This seemed to work! But, however, proved problematic as I discovered (only after I’d written the script!) that there lies a chicken-and-egg problem with when Xcode will execute a script versus when it’s all done packaging up the buildService.log files. The pattern that Xcode follows is: run the project tests, run the post-process script, then build the buildService.log files. So, the script above was running on a previous build, not the most current one.

I poked around a bit more but ultimately couldn’t come up with a solution of how to solve this. So, I searched around on Twitter and found @mjmoriarity, a wonderfully helpful Apple engineer who pointed me towards my ultimate solution of using Xcode’s set environment variables. Using these, my script was now reduced to a handful of lines and is wonderfully reliable:

Peripheral Intimidation

Driving from Seattle to Portland with some regularity gives me a chance to stop (and go, and stop) and think for a bit. As with every car drive I begin to mull over what’s been on my mind recently – usually development-related issues. The last drive I stumbled across a comparison that helps explain a distraction I’d been experiencing recently in my work. The analogy? Software and semi’s.

Being a part of any development community means being exposed every day to amazing work done by amazing people. Continuously seeing all the cool things people are doing it’s hard not to draw comparisons to your own work. The feelings of inadequacy and Impostor Syndrome, unless carefully monitored and controlled, are inevitable and intense. Because the names of the people creating these apps all seem to blend together after a while, it feels like one single, impressive, superhuman coding all these apps, sites, and documenting every step of the way. Someone more talented, thoughtful, creative, and with more perseverance than you could ever dream of. In essence, a hulking semi of app-creating power rocketing down the information superhighway (see what I did there).

It’s natural to feel small compared to these semi’s. In fact, it’s probably healthy as it pushes us to continue to sharpen our saws and elevate our skills.

But it’s so critical to remember that each cool thing being churned out of this great internet machine was created by regular people. People who found a niche, pounded hard at it, and after many failures and false starts arrived at something close to the final product.

Mike Lee, a developer I’ve long respected for his talent and design skills, was recently interviewed and outed that he’s a just regular guy, not superhuman. If you haven’t yet seen it (or listened to the MP3) it’s well worth your time. One of the smartest guys running in Mac/iOS development circles is an ordinary dude. It doesn’t get much more inspiring than that.

So, just as you continue to suck it up and drive down freeways past the hulking semis, development should continue as well.

Access Headless Local Machine With Dropbox

Last Friday, 7/8/2011, just before closing time, my monitor on my primary development machine broke. The screw attaching the monitor’s arm to the base snapped clean in half, leaving a perfectly good monitor with no way to stand on its own. An unfortunate circumstance but one that is easily remedied with a new screw (or, in the case of Amazon’s customer service, a brand new monitor).

This left me in an unfortunate position come Monday morning when trying to get into my machine to start my day. Luckily, I had brought another computer and had Dropbox installed on the now headless development machine.

All I needed to do until the new monitor arrives is to SSH into the machine, with the possible exception of running a VNC client to access some of the Eclipse GUI elements. However, in order for SSH to work properly, one needs an IP address of the target computer. How would I get this? After running an uninformative NMAP scan (too many machines on the network to pinpoint mine) I realized I had already installed Dropbox on the machine. Following are the steps I used to gain the IP address of my development box in order to SSH into it:

1. After booting the machine, login (hit ‘Enter’ then type password – will depend on how your login process is configured)

2. Press keys ‘cntrl-alt-T’ (This will open a Terminal window)

3. Type ‘cd Dropbox’ (this too will depend on how you’ve installed Dropbox – I’ve set mine to the default location)

4. Type ‘ifconfig > ipaddr.txt’ (without the ‘ character)

You should now have a .txt file in your Dropbox folder with the IP address of the development machine! From here you can use that IP address to SSH into the development box! It’s an easy and clever little trick to get the IP address of a headless machine (provided you have Dropbox installed. If you don’t, you may want to look into piping ‘ifconfig’ into a ‘sendmail’ command).

First Days

I’ve officially started work as a professional developer. Surprisingly, it’s been somewhat of an easy transition from unstructured life (world travel and apartment lounging) to waking up at 6am and resuming using my brain all day. This first week has primarily been spent on a combination of tasks: learning the existing power systems and how the various pieces interact with each other, and also setting up my development machine.

I’m extremely excited that I get to spend some time working on two of my favorite parts of computer science: networking aspects (which is important in the power field as many plants and substations are connected to each other) and operating system-like coding. Perhaps these two fields are far more prevalent in the professional world than it first appears to be, but I consider myself lucky that I get to spend time in such interesting areas.

One of my primary initiatives as a newly professional programmer is to spend a significant amount of time reading. I had a conversation via email with my cousin the other week asking him to recommend to me any books on programming that he thought would be helpful at the beginning of a career. He responded that it depends on whether a person wants to spend their time on the higher-level “theory” versus “tech-specific” kinds. In my mind both can be helpful at the beginning of a career depending on how you apply the techniques and the technology stack one works with. So, with that in mind, I’d like to keep my time nearly equally divided between the two categories.

Books that I’ve found to be highly recommended and I have plans to read in the coming months are:

  • Code Complete: A Practical Handbook of Software Construction
  • Pragmatic Programmer: From Journeyman to Master
  • And not programming specific but still a good read: Zen and the Art of Motorcycle Maintenance.

These, along with some JavaScript tutorials should keep me occupied for some time to come. Here goes nothin’!