Weekly Reading List #4

The theme for my reading this week had to do with automating testing for iOS. You can build an iOS app (xcodebuild), install it on the device (I prefer to use PhoneGap’s ios-deploy), and then run Instruments (instruments) with only a single Terminal. While figuring all of this out, I needed to learn bash’s flow control, which a good introduction to bash helped me learn pretty well.

Xcodebuild Destination Cheatsheet

While this post only talks about a certain aspect of the xcodebuild arguments (-destination), the post is full of enough working examples for me to get a build that I could install on a device. For the purposes of iOS device building, you want your -destination in one of three forms:

  • "platform=iOS,name=Device Name"
  • 'platform=iOS,id=device_udid'
  • generic/platform=iOS

The first two should generate a build for the device’s architecture (if you have “Build Active Architecture Only” set to YES in the Build Settings). The last one can build without a device attached and should generate a product with both the 32- and 64-bit binaries included. Building both 32- and 64-bit binaries takes longer, a lot longer if you have a lot of code and/or libraries.

By default, the build products end up in your DerivedData folder, if you want them going to a custom location you can either:

  • Specify a new -derivedDataPath. Specifying -derivedDataPath build will place all the derived data in your current directory and the app will be either in build/Build/Products/Release-iphoneos or build/Build/Products/Debug-iphoneos depending on your -scheme.
  • Specify a custom CONFIGURATION_BUILD_DIR path with an absolute path. So, CONFIGURATION_BUILD_DIR=~/build would place the app file in the build directory of your home directory.

For reference for all of xcodebuild‘s options, you can go to the corresponding man page.


Not an article or a blog post, but a very useful GitHub repository to install and launch (if you wish) app files to a device. Older versions had difficulty with both the latest OS X (El Capitan) and iOS 9, but the latest version of this repository fixes these issues making this one of the better command line iOS installation tools.

iOS Automated Tests with UIAutomation

This post is coming up on 4 years old and mostly talks about UIAutomation, but it also describes launching Instruments through the command line. If your goal is testing specific simulators, jc has another post for this. While instruments can handle installing the app file to a simulator automatically, if you want to run instruments on device, you have to already have the app installed on the device.

Another useful command: instruments -s devices will list all connected devices and simulators. For other options, you can refer to its man page.


I wanted to make a shell script to run my custom build-install-instrument flow. However, I have never actually written a shell script before. LinuxCommand.org has two good tutorial series Learning The Shell and Writing Shell Scripts that goes through basic bash command line usage and basis script writing, including flow control. Bash syntax, especially how bash does conditions, is strange.

Weekly Reading List #3

The articles I read this last week were more technical in nature. I’ve looked into Xcode Bots, including the Apple documentation, read up a refresher on Grand Central Dispatch (Apple’s library that supports concurrent code execution in iOS and OS X), and read up a way to turn your laptop into a radio transmitter.

Using Xcode Bots

Michael Tsai writes about his learnings from his experience using Xcode’s continuous integration feature. Xcode Bots make many tasks that are easy to do into things that are automatically run every commit or every night. On a code push, a separate computer can build for both 32-bit and 64-bit (usually I only do 64-bit because it saves a lot of time), run static analysis, and run tests (even across multiple projects, which is very useful for shared libraries).

On the other hand, Michael shows how the experience is not as seamless as you would hope. A lot of features didn’t work as expected or at all. Michael hoped it would have been easier to use Xcode Bots than Jenkins, but in the end it seems to have a different set of difficulties.

Some of the commenters recommend TeamCity, a JetBrains continuous integration tool, and I plan to look into that the coming week.

Xcode Server and Continuous Integration Guide

Apple makes it sound so straightforward. I have been looking for a way to automatically run game performance tests (is a reasonable fps maintained throughout gameplay, are there any crashes or warnings, are there any graphical distortions). It doesn’t look like Xcode Bots is the solution for this problem, but it does make a lot of good development hygiene automatic.

Xcode Bots can also show you changes in time and when new issues arose. So, it would be easier to see which commits introduced issues rather than relying on somebody to investigate the bug.

System Bus Radio

A fun GitHub trending repo that uses writing to memory and nanosecond timing to turn an Apple computer into a low power AM radio transmitter.

Grand Central Dispatch Tutorial for Swift

Two part tutorial based off of the original GCD Tutorial for Objective-C. I’ve used GCD for years, and I found that this tutorial taught me concepts I should have already known:

  • GCD queues can be either serial or concurrent. Serial queues take blocks in order and don’t allow more than one block to run at a time. Therefore, tasks are guaranteed to occur one after the other. Concurrent queues still guarantee that tasks are started at the same time, but tasks can run in parallel. Therefore, tasks can be finished out of order, and you cannot make any guarantees about code running order.
  • dispatch_get_global_queue() returns one of four different concurrent queues depending on the Quality of Service (QoS) class. Apple’s APIs can also use these queues, so be careful of blocking any of them.
  • Barriers and custom concurrent queues are great to implement the “multiple read-single write” behavior for a variable access. The second argument in dispatch_queue_create is how you specify DISPATCH_QUEUE_CONCURRENT.
  • Dispatch groups are a convenient way to wait for the completion of multiple asynchronous tasks. dispatch_group_enter and dispatch_group_leave pretty much increment and decrement a counter of jobs, so balancing is critical. dispatch_group_wait blocks the current execution until the dispatch group count reaches 0, while dispatch_group_notify will call a block upon the the dispatch group emptying.
    • While generally better, dispatch_group_notify is likely harder to debug if you have a group never emptying bug. dispatch_group_wait will show in a stack trace as a thread blocked by the wait call.
  • Apparently you can use dispatch_source_create to monitor and respond to Unix signals, file descriptors, Mach ports, VFS Nodes, and other stuff. Listening to Unix signals can be interesting…

Weekly Reading List #2

Answering technical questions helpfully

This post by Jon Skeet, one of the most well-known contributors to StackOverflow, is a useful checklist for technical writing that is useful, in StackOverflow, blogging, and anywhere else really.

Shorter Feedback is not Always Bett

Not an incidental typo to the quick post by John Boyd. Watch out for making the observation loop shorter than the time useful feedback can be generated. An observation loop that’s too small can create poor short-term optimizations that hurt long-term outcomes.

Running a learning hour

Creating a culture of learning is a holy grail for engineering organizations. Having engineers run workshop-style classes every month is a good idea.

Creating a career path

The ideas remind me of Run the Runway’s engineering ladder shared last year (strongly recommended). While Run the Runway felt more like fitting qualifications to a traditional engineering ladder (engineer I/II, senior I/II, staff, principle), Alexander Grosse followed the Dreyfus model of skill acquisition where he split his four criteria into levels from entry to expert. I found both ways reasonable. And I bet Alexander Grosse would agree the most important thing is to have some ladder that engineers can respect and plot their course on.

What Makes a Good Engineering Culture?

Another management/culture building post. Edmond Lau gives a lot of concrete advice that a manager or even an engineer can instill to improve the team.

Weekly Reading List #1

These are some of the articles I’ve read this last week, and what stuck with me from each of the articles. This week the articles span using Xcode instruments to Github’s code testing tool Scientist to programming blogs talking about programming blogs.

What every iOS Developer should be doing with Instruments

This article is a very good introduction to the Profiler and Allocations Instruments. It goes through a simple walkthrough of each. While not useful for a new engineer, it’s a good article to show an engineer that is needing to use Instruments for the first time.

What stuck?

In Xcode, ⌘6 opens up the Debug navigator. For general reference, the left panel is the navigator and each of its views can be accessed by ⌘ plus a number. Staring from the left:


  • ⌘1: Show Project Navigator: Shows all of the files in a directory-like (groups) hierarchy.
  • ⌘2: Show Symbol Navigator: Shows all the symbols in your project. Not a navigator I’ve used very much.
  • ⌘3: Show Find Navigator: Find and replace by text matching, containing, starting, or ending or even by regular expression.
  • ⌘4: Show Issue Navigator: Shows diagnostics, warnings, and errors when building or analyzing your project. Normally I’m here when the app doesn’t compile or to see what static analyzer is complaining about.
  • ⌘5: Show Test Navigator: Create, manage, and run units tests.
  • ⌘6: Show Debug Navigator: Shows running threads and performance information.
  • ⌘7: Show Breakpoint Navigator: Set breakpoints from here.
  • ⌘8: Show Report Navigator: Shows build and running logs.
  • ⌘0: Hide Navigator

Profile with an actual device. A simulator has different performance characteristics than an actual device.

CPU Profiling defaults to 1ms samples, which can be changed.

Instruments’s Inspectors (the settings that show at the bottom-right of the window) can also be accessed by ⌘#.

Following the retain/release history is possible with the Allocations Instrument, but I have generally found it cluttered with a lot of retains and releases. However, the advice to look for libsystem_blocks (blocks are a common source of leaks) or your application and to skip anything UIKit is a good suggestion.

Move Fast and Fix Things

Found this article through laboratory: a GitHub trending repository of a Python port of GitHub’s Scientist. Scientist: Measure Twice, Cut Over Once discusses Scientist and their open-sourcing this tool, while Move Fast and Fix Things discusses how they used Scientist to transition their pull request merge tool safely and quickly. They were able to test with real users, fix any issues, deploy, and continue testing with a minimal overhead to their users.

While most applicable to web environments where deployments can be done quickly and easily controlled, this “Verify Branch By Abstraction” design pattern is useful even for iOS application development. It would allow introducing refactoring and improvements to code while keeping the original implementation active until the candidates have been fully tested on real-life edge cases.

Starting a Programming Blog

Some good advice about writing a non-specialized programming blog from William Shields when he was at 1 month in his blog (part 2 is when he was at month 2). The list of advice that stuck with me as still needing to be done for this blog:

  • Turn off “Convert line breaks”,
  • Make sure you have a contact form,
  • Link any relevant profiles like LinkedIn, StackedOverflow, etc., and
  • Use Feedburner for RSS feeds. If you change your domain name this will also help a lot since you won’t lose all of your subscribers.

Using Markdown with WordPress

While looking for other blogs’ takes on starting a programming blog (there’s quite a bit of posts about this), I found that Markdown was a popular way to write posts. I find using WordPress’s default Edit Post about as pleasant to use as Atlassian’s Confluence, so I am up for finding something better.


What was surprising about creating a first blog?

What did I learn while trying to get this blog setup?

  • Installation is trivial, but there are lots of decisions to be made after that.
  • There’s a lot of good reference material, but at some point you’ve got to get started.
  • I’m definitely forgetting something…

Pretty much there’s a lot you can do out there, too much if you want to be certain you’re making a good decision. Definitely, look at some of the material you find, you’ll quickly learn a lot that’ll help you understand and make content. At some point though, you have to start writing.

Easy to do, but lots of decisions

Hosting services

One of the first things to do is to find what you’ll be blogging from. It appears WordPress is the de facto standard for blog content management systems. For the web hosting, you can use free services, but if you’re hoping for some professional aspirations, self-hosted platforms that host your blog from a shared server and include purchasing your own domain are universally considered a good choice. I found HostingAdvice.com had a good list, but you’ll find a lot of information and recommendations. Be careful of upsells, you’ll need to decide whether each one is actually useful for you or not.

Domain name

This is an easy paralysis point. If you plan on attaching your identity to the blog name, then you should ensure that the name is also free on social networking. KnowEm can quickly tell you if the name is taken on other networks. For this blog, rakkatama was already taken on other networks, but I didn’t know this until after I set everything up.

WordPress Theme

From here it gets somewhat easier because it’s easier to backtrack on. Changing hosting services and domain names can be done with transfers, so it’s not impossible, I hope. As of this writing, I’m using the Decode theme, but changing shouldn’t be too terrible except for some formatting changes that might need to be required on old posts

What to write about?

The hard part. My opinion is to start small. I don’t actually find the idea of writing particularly pleasant. However, like many things that are unpleasant, it’s good for you. Start small. “Things I Learned” (til) are a good way to start writing short helpful learnings.

Lots of Reference Material

After the hosting services rankings, I read through the First Site Guide How to Start a Blog. Many hosting services will also have documentation and links to how to get started with setting up their services (email, installation of products like WordPress, etc.) and setting up WordPress.

I’m definitely forgetting something

I am definitely forgetting things a first blogger needs to do. I assume it’ll hit me in the next few weeks or months. They might be annoying, but hopefully, they won’t be irrecoverable.

So, this is what stuck with me as I’ve been setting this up. I’d be curious to know if your thought processes and sticking points were different.

Mistakes will be made. I just have to hit the Publish button.