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.
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.
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.
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.
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…