Developing on Staxmanade

Starting to build an Xbox One Podcast Player


I'm writing this email to announce an early sneak peek into a project I've recently started to put some of my free time towards. Here's a preview from a small landing page I've recently put together.

If you, like myself, felt like the Xbox One platform was missing an essential Podcast player app, then you have come to the right place.

Have any interest in following along with me in this journey?

At the bottom of this page is a form, if you share your name and email, you'll get early access and an insider's view of the process of building an Xbox One application.

Learn More here...


In-App Unit Tests


How often do you run your unit tests? Do you even have a test project? Is running your test suite automatic or does it only run when you choose to run them? If the latter is true, then how often do you run them?

For most, running tests is a simple command line tool like gulp test or rake test or a builtin function in your IDE. You may even have your system covered by a Continuous Integration server, or if you want to catch issues earlier possibly even a git pre-commit hook.

One thing we all probably know is the more difficult it is to run your tests, the less often they get run.

What if you're building in an environment that does not allow for easy test automation? What if there are no current command line task runners for the environment you're developing in?

You could spend way too much of your free time/life building a tool that can get the job done for you (cough - long live StatLight/Silverlight - cough). I would not necessarily recommend this approach unless you have the spare cycles to contribute a project like this to the broader community.

So, given that there are no external tools to rely on, and you don't want to spend however long it will take to create one for the development environment you are in, how about finding a way to integrate some sort of test run within your existing application?

I have always wanted to setup some unit tests that could run inside of an existing application. If you developed an app that had to ship on lots of devices (thinking android or iOS) and you could ask your users out in the wild to go to the settings page of your app and press a "run tests" button, how awesome would it be if this test run could collect data and send the test results back to you?

This is not a new idea, nor terribly unique, but I've pondered this for quite some time and until recently have not had a project were I was forced to execute on it, until now...

I'm playing with an app that is currently living inside a WinJS (Windows 8) (Metro - err do they call it that anymore?) environment and there are not any CLI tools out there that can be used to automate tests. However, it was easy enough to get Mocha running within the app.

With MochaJS in place, I proceeded to setup a WinJS Hub in my hub-based application, after make this testing hub the first hub in my project I now have test that run after every F5 (run) of the application.

This will eventually have to be something I move out of the main landing U.I. when I get closer to shipping my app, but I'm liking the idea of being able to toggle my test U.I. and have them run right within my application, instantly on startup.

A few benefits of this approach:

  • It allows me to actually write tests in an application that doesn't natively support a testing runner.
  • Fewer test gotch-ya's because of environmental reasons
  • Instant feedback on each run
  • It's an easy reminder to keep using and driving my development through tests, because the workflow is enabling it (and encouraging it).
  • (this could be considered a down side but...) since the tests are living within the actual application, I have to be careful to construct my components no to depend too heavily on the environment or configuration as we wouldn't want unit tests to mess up the running application. While it could be seen as a bit of a pain, I'm really liking how this is forcing me to write loosely coupled, highly compossable components that can be easy to swap in/out.

Will I Actually Ship In-App Tests?

This one is up in the air, but so far I'm of the mind-set that I'll hide the unit-test run from the main hub, place a button deep in some about or setting page and modify the reporter to send send any failed test results, along with some metadata about the environment or system it's running on, like versions, screen size, or whatever is needed...

Happy Testing!


Build Command with Auditory Feedback


Here's a short and fun little ditty I'm going to throw up here so I can find it later... (because why would I try to memorize something so simple when I can put it here and share with you all?).

My Builds Are Speaking to Me

Running this command from my Mac command line window gives a nice audio feedback when builds are complete.

(gulp && say 'super!') || say "what the what?" -v Albert

Some Context

While doing some project work on my Mac lately I'm in the situation where I am constantly running gulp at the command line. This workflow could apply to any CLI build tool like gulp, rake, make, etc and ya I know I need to spend the time getting gulp watch to work but let's not worry about that for now...

The build is not slow, but it's not fast (taking about 6) seconds. That's just enough time for me to see a squirrel and by the time I realize the build is done, I've forgotten if I actually recently kicked off the build or if the most recent run is out of date from the latest code I've worked on...

So I searched for a quick way to get some auditory feedback when my build was done so I could more efficiently continue the development flow...

I first stumbled upon this gist which has a NodeJS implementation console.log("\007");, but this produces the same beep I get when my unit tests fail - which I don't want when everything's good to go.

Then I found someone mention the mac say command which is WAY better for my needs and I settled on the following little command.

(gulp && say 'super!') || say "what the what?" -v Albert

Whats cool about this pattern is I can replace gulp with any other build tool on other projects like rake, grunt, make, etc...


Mac Equivalent of the Windows Registry - ish


If you're a long time Windows power user and are recently switching over to the Mac, you may have wondered if there was something analogous to the Windows Registry .

However, if you've always been more of a Mac user, don't run away just yet as you may learn something.

In case you don't know what the Windows Registry is, here is a short definition from our good ol' friend Wikipedia.

Windows Registry is a hierarchical database that stores configuration settings and options on Microsoft Windows operating systems. It contains settings for low-level operating system components and for applications running on the platform that have opted to use the Registry.

You have probably already figured that since it's called the Windows Registry that there is likely not a Mac Registry that looks/operates the same way.

You are correct; however, where do all of the system and applications settings get stored if there is no registry?

If the Windows Registry is a place where system and application settings are stored, then the Mac equivalent of the Windows Registry would be a series of .plist files in several preferences folder on the Mac.

While researching how to automate bootstrapping my Mac development computer, I stumbled upon large number of .plist files in several folders that correlate to the installed applications and system settings. And boom BOOM boom just like that I discovered the holy grail of my Mac's system and application settings - kind of like the first time lift up the curtain and discover the Windows Registry.

What are .plist files?

A .plist file is a configuration file that contains a list of properties in either plain text or binary format. I'll go into more later about how to read and update values in these files later in the post.

For more info on plist files, check out the Wikipedia page...

Where can I find plist files?

I know of at least 2 locations that host the common system and application .plist files.

The first one is user specific and is in the following location:


In my case (since my user name is jason)


The second location one is at the root of the system:


If you look into these folders you'll see a large number of plist files that follow reverse domain name convention (like

Here are some (not all) examples of system configuration plist files:

In the same folder as the sample configuration files listed above are where you can find plist files that are associated to applications installed on the system.

Now that we can find system and application configuration plist files, if you try to open them in a text editor you may notice that many of them are in a binary format which would be challenging to read and understand, let alone edit.

How do I read these files?

The Mac comes with a command line utility called defaults for reading and writing to these .plist files.

If you take an example from the above list of plist files, you can, at the command prompt type the following:

defaults read<tab> (where <tab> is the tab key that allows tab completion of the rest of the property list format) and be sure to exclude the .plist of the end so:

defaults read

will print out all of the properties to the console so you can inspect what's there.

You can pipe this output to grep and filter for a setting name when doing searches. Once you've found a property name you want to look at you can pass it into the defaults read command to get the value of that specific property.

Example reading a single property:

defaults read AppleShowAllExtensions

How to change property list settings?

warning WARNING warning

Just like modifying the Windows Registry can mess up your system, you need to take care modifying system or application plist settings.

warning WARNING warning

Most of these settings can be changed by navigating to the application or system's respective preferences U.I. and just changing settings manually. However, the whole reason I ran down this path was to learn how to automate these setting changes.

When I first tried to change the settings I tried manually modifying the plist files with a GUI tool built into the Xcode developer tools.

However, and I have yet to understand the internals of this, after I made the changes to the plist file they would automatically get overwritten after a few seconds. So it seems that there is some official source of these values somewhere that for some reason overwrite the ones in these folder. I probably have that all wrong - but was an observation I had.

So if my understanding above is somewhat correct, how did I update the source?

Similar to reading property list values you can use the defaults command line tool to write changes back to the .plist files.

As an example, here's how I update Finder to show file extensions.

defaults write AppleShowAllExtensions -boolean true

The configuration options are now endless.

In summary:

Using my new knowledge that app and system settings can be found in both /Library/Preferences and ~/Library/Preferences and I can use the command line tool defaults to read/write to understand and update settings.

I can now create a simple .sh script that allows me to pre-configure a new development machine with all of the settings I would like.

Now, each time I catch myself trying to use an application's preferences U.I. I stop myself and try to find that setting in a plist file and create a CLI command that I can save into my development setup script.

Happy Mac Settings Hacking!


Fail Fast With iOS Images


Problem: iOS app has unwieldy, unorganized and poorly named images

I've been working on a team that took over a good sized legacy iOS project where it's usage of images became a little unwieldy. Between the various app clones (targets), shared images, and images that aren't even used we'd like to reorganize, rename and just clean up the app in general.

But, one thing that makes me nervous is how easy it is to rename an image, forget or miss a magic-string that tries to load that image and now we've introduced a bug that may be difficult to diagnose or even discover that we introduced it.

Let's fail fast?

Failing fast in this context means, how can we, during development and testing time quickly fail when running the app to determine where an image attempting to be loaded does not.

Ideally we wouldn't even have these magic-strings to deal with. Using some tool to automatically generate a compile-time safe construct that we can use to load images. However until both A) I find the darn tool that I once-upon stumbled across that does this (please leave a comment to remind me if you find it before I do...) and B) we get sed tool integrated, I threw this little helper to quickly fail fast and help us find broken image references within our iOS applications.

How does it work?

It's a simple little Category that overrides the imageNamed: selector of UIImage and if the original cannot load an image (returns nil) then it will fail with a helpful assertion message.

This utility allowed us to quickly find images that were missing while doing our big clean sweep.

How to integrate?

It should be as simple as adding the .h & .m files to your project and their respective targets and you should be off to the races.

For DEBUG mode only...

If you look closely you'll notice #if DEBUG wraps the implementation so when we ship to the app store we don't end up causing a crash in production if a missing image sneaks by.

Happy Missing Image Bashing!


How to Diff Two Xcode Targets


If you've ever used different Xcode targets to manage different version or clones of a similar app and then had to debug why one target builds while another doesn't, finding a way to diff two targets was always challenging.

Sometimes it's because you forgot to check a box including a new class in multiple targets, or maybe you've integrated a new framework with targetA but forgot to include the framework reference in the Build Phases for targetB.

I'm actually hoping that I just haven't learned the obvious way to resolve these problems and you (dear reader) will leave a comment telling me how simple it is to do with the built in tools. Until then, here's something that I hope will help others that are trying to see what two Xcode targets have different between them.

How about a little CLI tool: diffXcodeTargets

diffXcodeTargets is a command line utility I threw together that allows you to visualize the differences between two Xcode project targets using a diff tool.

Install it with npm

npm install -g diffxcodetargets

How to use it?

You can first call it by passing in the path to your project file and no targets and it will print out what targets are available.

> diffXcodeTargets ./myProject.xcodeproj/project.pbxproj

Could not find TargetA ''. Possible targets are:
  - targetA
  - targetB

Now you know your available targets and you can call it with the two targets you want to diff:

diffXcodeTargets ./myProject.xcodeproj/project.pbxproj targetA targetB

How does it work?

If you're curious how this tool does it's job it is actually quite simple and would love to hear any feedback...

diffXcodeTargets uses the xcode npm module to read/parse xcode projects and then approvals to show a difftool with two different files.

What's missing?

I threw this together quickly to help diagnose some issues with a project I was working on. It does not yet support all of the various scenarios that may be needed when diffing two Xcode targets, but if you have any suggestions or ideas feel free to leave a github issue.

Happy Diffing!


How to Remove Files in Git that Should Have Been Ignored


If sometimes come upon existing applications that use Git where files were added to the repository that should have originally been ignored. Sometimes this is because the .gitignore file is missing, or because certain rules were not include that probably should have been from the start.

There are ways in git to completely rewrite history to remove all traces of the file, however most of the time, it's good to leave a commit saying removed files that should have originally been ignored as a good starting point (depending on the project/repo).

Here is a small workflow I've found to be pretty effective in helping to clean up a repository, or at least let you know what files would have originally been ignored had you setup a .gitignore file with some project standards...

Create a well meaning .gitignore file

You can go to and type some words like xcode, node, osx, or whatever platform/IDE you use for development and generate a pretty good .gitignore base file.

Create or Update local .gitignore

Once you've update your local .gitignore file with the rules you'd like to use, you can use the below to commit your changes;

git add .gitignore
git commit -m 'updating .gitignore'

Remove the files that should have originally been ignored.

Now we want to figure out what files may have been added originally that shouldn't be there. You can run the following two commands to see which files to find this out.

git rm --cached -r .
git add .

Now if you git status you can see what files should probably be deleted from the git repo and using the newly updated .gitignore file will now be ignored going forward.

Go ahead an commit these changes (assuming you're happy with what is being deleted and ignored).

Happy Gitting!


Approval Tests - Command Line Tool (CLI)


In my previous post I introduced Approval Tests using the Approvals.NodeJS variant of the tool.

In this post I'd like to go over how you can use the command line version of Approvals.NodeJS for several different scenarios.

First thing first (How to Install)

Globally install approvals via npm.

npm install -g approvals

Now that you have it installed, let's go over some scenarios that you can use the approvals tool.

Scenario 1: Compare JSON files downloaded from a web server.

Let's say you want to see a quick file diff between two api requests.

You can use curl to download the file and pipe (|) it to the approvals CLI tool. We give it a name parameter which is used to generate the file name used to save to.

So if you were to run:

curl | approvals githubOrg

This would generate two files:

githubOrg.received.txt which at the time of this writing would look like:

  "login": "approvals",
  "id": 36907,
  "url": "",
  "repos_url": "",
  "events_url": "",
  "members_url": "{/member}",
  "public_members_url": "{/member}",
  "avatar_url": "",
  "description": null,
  "name": null,
  "company": null,
  "blog": "",
  "location": null,
  "email": null,
  "public_repos": 13,
  "public_gists": 0,
  "followers": 0,
  "following": 0,
  "html_url": "",
  "created_at": "2008-11-27T06:03:58Z",
  "updated_at": "2014-12-28T03:02:33Z",
  "type": "Organization"

and an empty githubOrg.approved.txt file.

Note when you first run this command you are prompted with the received file compared to the empty approved files; however, on an initial run, you can use the --forceapproveall argument to avoid the diff step and force all the contents of the received file into the approved file.

Now if the remote file were to change on you and you run the below command again:

curl | approvals githubOrg

You would get a diff between the the originally approved file and the newly downloaded file.

Scenario 2:

Ok, well I actually have another great scenario for using the approvals CLI, but I believe it deserves it's own post as I'm going to introduce some nifty configuration on a Mac that I've used to setup my own development servers automatically.

Until next time...


Approval Tests - Overview


I first started using the .Net version of Approval Tests and found so much value in it, I created a port of the tool that I can use in Node.JS. This post is intended as a rough overview of Approval Tests, and will be using the NodeJS port in my examples below.

There is support for other programming languages, so head over to the Approval Tests site at and check them out.

What are Approval Tests?

At it's core, Approval Tests are a very different way to execute the assertion step of a unit test.

Think of this as another tool in the bag and not a replacement for the good old fashion assert.equal(...) or your favorite assertion tool. But for certain types of tests, it IS the best tool to grab.

Typically, when we create assertions in our unit tests, we assert on very specific things. This property equals that value.

With Approval Tests, you can take whatever output you're wanting to Assert against, turn it into either a string representation or an image (say screenshot of app), and use our favorite diff tool to compare it with the previously approved version.

The diff tool is a great way to visualize change between failing/approved data which can help to raise the level of abstraction of your test. Instead of comparing a single value in an assertion, we can serialize an entire object graph to a string and use the diff tool to review any changes to the diff of the previously approved version.

The work to find and start up your favorite diff tool comparing previously "approved" files is where the libraries provided by Approval Tests come in handy.

Let's walk through an example

If you've done any testing before, by now you have probably heard of the AAA (Arrange, Act, Assert) style of tests. Below I've contrive a sample test using the AAA style in JavaScript.

var assert = require('assert');
describe("when testing something", function(){
    it("should do something special", function(){

        // Arrange
        // setup the initial state for the test
        var obj = { valueA: "test", valueB: 1234 };

        // Act - Do some business logic on the object
        obj.valueC = true;

        // Assert - verify the state of the item under test
        assert.equal(obj.valueA, "test")
        assert.equal(obj.valueB, 1234);
        assert.equal(obj.valueC, true);

At a high level, if you are writing tests with an object, and have a way to translate that object's state into a text or image representation, wouldn't it be great if you could save that state into a file, essentially locking down the state of the test?

This would allow future runs of the test to easily detect a change by comparing the previous state with the new state (strings of course) - but using the power of our diff tools to quickly highlight what is different.

Let's turn our AAA test above into an Approval Test

var approvals = require('approvals');
describe("when testing something", function(){
    it("should do something special", function(){

        // Arrange
        // setup the initial state for the test
        var obj = { valueA: "test", valueB: 1234 };

        // Act - Do some business logic on the object
        obj.valueC = true;

        // Assert - verify the state of the item under test
-        assert.equal(obj.valueA, "test")
-        assert.equal(obj.valueB, 1234);
-        assert.equal(obj.valueC, true);
+        approvals.verifyAsJSON(__dirname, "sampleTest", obj);

Notice how the 3 assert's turned into 1 approvals.verifyAsJSON?

How Approval Tests Work

Approval Tests works by taking the object or value you're trying to verify, serializing it to a text file (or image) and saving it to a file labeled with the name of your test and *.received.txt. It will then try to compare this *.received.txt file with a *.approved.txt file. If the file doesn't exist, then we will see a diff tool present with our received file on the left and an empty approved file on the right.

At this point we have to choose between a number of options:

  • We could take the received output and copy/save it to the approved file. Essentially approving the test.
  • We may only want parts of the received file, and copy over just the parts of what we want to the approved file.
  • Or we do nothing as we want to start over...

Now we run our test again and if the test passes - then we know that we've finished as what was re-generated in the received file matches the approved file. But if we see our diff tool appear, we can analyze the differences in the diff tool and determine if we need to either adjust the approved file or adjust our code that generates the received file.

If the above explanation still isn't clear, I'd recommend watching @LlewellynFalco's video's on the topic that can be found at He does a good job describing the concepts.

Next Steps!

Browse the github org, watch videos or read documentation on

Happy Approving!


Setting Jenkins up to run XCTool and Xcode Simulator Tests


We recently migrated an older Jenkins C.I. server over to a newer one, and struggled to get XCTool or xcodebuild to run unit tests where the simulator was needed.

There are quite a number of blog posts out there that describe how to setup a C.I. Jenkins server on a Mac, but many of them don't include the last bit (that worked for me), so I hope this helps you...

Why Can't I run the Xcode Simulator on a Jenkins server?

Some Error Messages I Encountered Along the Way:

Tried to install the test host app 'com.myapp.test' but failed.

Preparing test environment failed.

There was a problem starting the test bundle: Simulator 'iPhone 6' was not prepared: Failed for unknown reason.

Test did not run: Simulator 'iPhone 6' was not prepared: Failed for unknown reason.

2015-01-21 12:02:19.296 xcodebuild[35135:875297]  iPhoneSimulator: Timed out waiting 120 seconds for simulator to boot, current state is 1.

Testing failed:
Test target MyProjectTests encountered an error (Timed out waiting 120 seconds for simulator to boot, current state is 1. If you believe this error represents a bug, please attach the log file at /var/folders/yf/49df70js2xn524f9c3835zx0000087/T/

Need to run a GUI user.

The Simulator needs to run in the context of an actual user where it can get a window handle and render it's U.I...

Below is a great resource to get you most of the way there.

iOS CI with Jenkins

Once you've followed the instructions in the above post and you still can't get the Jenkins CI server to run your simulator tests, then check this last item which got it working for me.

Open up your Jenkins plist file in the LaunchAgents folder. (If you don't have one in LaunchAgents, then go back to the linked blog post and follow that first).

The key for me to get it working was to remove the CreateSession key from the plist.

-       <key>SessionCreate</key>
-       <true />

Once I removed this key, restarted the server, everything started building/working correctly.

In summary:

  1. Auto-login with a jenkins user
  2. Get your plist moved over to the LaunchAgents folder (see post linked above)
  3. Remove the SessionCreate key