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