Xcode 6.3 c++ std library compiler errors

After updating Xcode today, I started getting a whole lot of errors that I knew were not my fault. The first one in the list was:
error: unknown type name '_LIBCPP_BEGIN_NAMESPACE_STD'
It took me a bit to track down the problem. The compiler had started to include c++/v1/experimental/__config from within std system header files that intended to include c++/v1/__config. For whatever reason, it was searching the subdirectory for that header file first. The solution I came up with was to simply exclude the experimental directory. Add “experimental” to the list of “Sub-Directories to Exclude in Recursive Searches” in your Xcode project’s build settings.

The Communiqué

A long time ago, in what seems like another life, I went to high school. In this time of growth, I wrote my first extracurricular article in a publication some friends and I dubbed “The Communiqué.” It was to be a publication that focused on the social and political issues we thought most needed to be discussed. We only ever printed one issue. I took quite the trip down memory lane tonight when my dad showed me the copy he had kept all this time. I decided to immortalize it, as much as anything is immortalized by internet presence. So, without further ado, The Communiqué, issue #1

Pet peeve #3

Pet peeve: When I send someone an invitation to do something (generally a text message these days) and I don’t hear back from them at all. If someone asks you if you want to do something, the answer needs to be one of three things: yes, no, or I’ll have to get back to you. When there is no reply at all, I am left wondering whether I should invite someone else, wait for a reply, or maybe even find another activity altogether. My feelings aren’t hurt at all by knowing someone is not sure yet because there are other potential plans he or she is considering. Planning can become stressful when no one knows how many people are involved.

DIY Camera Strap

I recently discovered a camera strap manufacturing company called BlackRapid through froknowsphoto.com, a great beginner photography resource. BlackRapid make straps that attach to the camera via the tripod mount as opposed to the two standard strap connection points at either side of the camera body. The real stroke of brilliance, however, is the way the camera slides up and down the strap instead of being held in place. This means that when you grab the camera and bring it up to your face, you don’t need to fuss with the strap at all — my strap would always snag around my neck and be a real annoyance. BlackRapid straps do not come cheap, though, and there was no way I could justify buying one as a hobbyist photographer. So I made my own.

A strap like mine could easily be made for under $10. Mine cost me around 3x that because I used almost all full-strength climbing gear to make it, both for the novelty and because if I ever find myself in dire need of the gear I used in this strap I can just take the strap apart and use the gear. You can read about the process below and see pictures of most steps at the bottom of this post.

What you will need

  • 2 pieces of webbing (or any other strap material); one for the shoulder strap (at least 7′ long — I wish I had made mine 8′) and one for the underarm strap (can be much shorter).
  • 2 small carabiners (or any alternative less expensive clips).
  • 2 rappel rings (again, could have been less expensive rings found in a hardware store).
  • 1 eye bolt and nut w/ the standard US tripod mount diameter/threading of 1/4×20.
  • 1 or 2 rubber washers with 1/4″ inner diameter.

The mount

I measured how far the eye bolt screwed into my camera (via the tripod mount) and hacksawed the eye bolt down to that length. It is important to measure from the nut when cutting. The nut should be screwed on to the eye bolt all the way to the top; it serves as the head of the bolt, providing friction against the rubber washers and in turn the camera body. Then I added a couple of rubber washers. I super glued the rubber washers together and then the top one to the nut to keep them in place.

The shoulder strap

I wanted the strap to be adjustable but if you want to just tie the shoulder strap into a loop you could save some time and money. I tied the two rappel rings to one end of the shoulder strap webbing. In the images below you can see how the other end of the shoulder strap gets fed through the rings to make an adjustable system that locks off under load. Add a clip or carabiner to the shoulder strap, and it is already usable. I went a step further and added an underarm strap that keeps the shoulder strap from moving around when the camera is moved.

The underarm strap

My underarm strap is just more webbing tied into a small sling. The loop is tied around the shoulder strap on front and clips into the second carabiner where the two ends of the shoulder strap are joined by the rappel rings. Once I had the length of the shoulder strap and underarm strap where I wanted them, I used tape to mark where I wanted the underarm strap to be attached to the shoulder strap in front. I took the shoulder strap apart, tied an overhand knot around the underarm strap at the tape mark, and then reattached the shoulder strap to the rings.

Shoulder padding

I am still deciding on a design for a pad on this strap. It is certainly usable without one, but if I were to wear the strap with a camera for a long time, I think the spot on my back where the rappel rings rest and the spot on my chest where the underarm strap attaches would both start to feel… neglected.

View on Flickr

Please specify a Flickr ID for this gallery

Pro-tip for searching text on a mac

The below shortcuts are global (any application that does not explicitly override them, supports them).

Cmd+E will copy text to the find/replace clipboard. This is separate from the regular clipboard. This means you can copy some text with Cmd+C, and then execute a search on a different piece of text, maintaining the original clipboard value for pasting purposes. Cmd+G will search through text with the value copied using Cmd+E, and Cmd+Shift+G will search in the reverse direction. This means that searching through text can be a LOT easier than Cmd+C to copy, Cmd+F to open find dialog, Cmd+V to paste, and Enter to perform the search.

Javascript/Typescript watch and break on variable value change

This is ground breaking for me. I have to give credit to the following StackOverflow answer: http://stackoverflow.com/a/1269692/650350

That will get you a watch method like the one Firefox provides to the root Object JS class. I modified the code slightly so that I could add a watch method to the BaseObject TypeScript class that Vadio uses (see code below). Once you have the watch method, you can obviously print out whatever information you want within the function you pass in to it. I wanted a call stack, though. That’s easy enough; just open chrome, load the page and view the script your JS is within, search for the call to watch, and break on any line within the callback method. Now you can have the chrome JS interpreter break when any variable is modified. Awesome.
public watch(prop : string, handler : Function) {
	var oldval = this[prop];
	var newval = oldval;
	var getter = function () {
		return newval;
	var setter = function (val) {
		oldval = newval;
		return newval = handler.call(this, prop, oldval, val);
	if (delete this[prop]) { // can't watch constants
		if (Object.defineProperty) { // ECMAScript 5
			Object.defineProperty(this, prop, {
				'get': getter,
				'set': setter
		} else if (Object.prototype['__defineGetter__'] && Object.prototype['__defineSetter__']) { // legacy
			Object.prototype['__defineGetter__'].call(this, prop, getter);
			Object.prototype['__defineSetter__'].call(this, prop, setter);

public unwatch(prop : string) {
	var val = this[prop];
	delete this[prop]; // remove accessors
	this[prop] = val;

Browser Benchmarking (third installment)

It occurred to me that it has been quite a while since I benchmarked browsers on my laptop. The last two times I ran PeaceKeeper, I wrote about it here (12/4/2009) and here (10/1/2010). This time I decided to benchmark a few more lesser-used browsers as well. In the screen capture below, the browsers in black are mine and the browsers in green are averaged results for other users.
Top 3 browsers: Chrome, Safari, Stainless.

Browser Benchmarks on my laptop

Some of the titles grabbed by PeaceKeeper are misleading. In the chart above, the following name substitutions apply:
Safari 5.11.2 -> OmniWeb 5.11.2
Firefox 3.6.28 -> Camino 2.1.2
Safari 6.0 -> iOS 6/iPhone 5
So, it appears that Chrome would once again take the cake for me, if only I was not so attached to the new shared browser tabs between Safari on my desktop and Safari on my phone.

The epitome of adventure

Adventure: An unusual and exciting, typically hazardous, experience or activity.

Adventures come in many forms. The story I am about to tell is not one of near-death experiences or exposure to the harshest environments. It is the story of how two guys, who set out to have an "adventure," discovered what adventure really means and how rewarding a true adventure can be. It is a long story. Wherever there is more to be read you will see a title to the right of a down arrow. Click the arrow or title to expand the text.

A friend and I took June and July of 2012 off work to hike the Pacific Crest Trail (PCT) for two months. I wanted hiking to become a way of life, not just a hobby. I wanted the most complex thing going through my mind for most of the day to be my wandering thoughts about the plants I saw and the animals I heard. To some extent, I got that; but I did not spend two months hiking the PCT.

The Plan

The Backstory

In the summer of 2011, I had just graduated from college and I was backpacking over most weekends. I only worked 20 hours a week at the time and I used that flexibility to get outside as much as possible. Almost every trip that summer was a collaboration with a good buddy of mine, Colin. We had recently discovered that we shared a passion for pushing ourselves to overcome fatigue and soreness in search of new and beautiful remote locations. Late in that summer, we backpacked up Nick Eaton Ridge out to Wahtum Lake in the Columbia River Gorge. On the second day, we woke up early and hiked to the top of Chinidere Mountain to catch the end of a breathtaking sunrise.

Chinidere at sunrise

Chinidere Mountain at sunrise

As we started our return hike, I turned to Colin and said, "If we ever somehow manage to get the same couple of months off work, want to spend it on the Pacific Crest Trail?" Colin said, "Yes!" without hesitation. It remained nothing more than an exciting thought for quite a while.

In late 2011, Colin (who had become my most trusted adventure buddy), told me that he would be unemployed in June and July of 2012. Entirely by coincidence, the gap between his current job and his next job would last the same amount of time as the Pacific Crest Trail hike we had previously dreamt about doing*. In the first five months of 2012, the trip went from an exciting idea to an imminent reality.
*This is not how long it takes to hike the whole trail; we wanted to hike a small section of it.

Where My Two Months Came From

When Colin and I first started planning for our PCT hike, I was working my 20 hour per week job as a contracted iOS developer. I figured I would simply stop taking contracted work for the months of June and July. I had also been working with a startup company called DuroCast since my freshman year of college but it had always been difficult to put much time towards it, so the project progressed very slowly. In early 2012, however, DuroCast started working on a new and exciting product we called Vadio.

By May, I had quit doing contracted iOS work and started putting more than 40 hours a week toward Vadio. This put me in a very difficult position. I had decided that the PCT trip was something I needed to do or I would risk regret for the rest of my life over turning the opportunity down. I would also be throwing away the time, energy, and money that both Colin and I had put towards preparing for the trip. Unfortunately, leaving for the trip meant that DuroCast (soon to become known simply as Vadio) would be down a developer and a co-founder for two whole months in the early stages of development. The other members of the team were incredibly understanding when I explained I had made the difficult decision to hike the PCT despite Vadio's infancy.

By the third week in May, Colin and I had researched trail food and resupply points, picked up light trail runners for long days of hiking, decided where to begin our trek, and purchased train tickets from Portland, OR to Dunsmuir, CA. Colin's newt research had delayed the trip's start a few days -- never depend on a newt's punctuality -- but once I had a ticket confirmation for June 8th, I knew the trip was really happening.

The plan was to start hiking in Castle Crags State Park on June 9th and be in Etna, CA seven days later to resupply on food and possibly take our first rest day. From there we had a few more resupply points planned out but no specifics. It did not make sense to us to plan too far in advance when we were sure that our daily milage would diverge from the itinerary anyway. We were in the favorable position of not needing to make any deadlines on the PCT; what mattered was that we would hike almost every day for 2 months and that would become a way of life. I was so excited to get to the point where every morning I woke up and hiked simply because hiking was as subconscious of an action as breathing. We did venture a guess that our trek would end somewhere near the border of Oregon and Washington.

continued on next page

How search engines may be hurting your debugging skills

I am embarrassed to have fallen into the trap I am about to describe, but perhaps it will enlighten others before they waste as much time as I have.

Search engines have made so many things easier, not the least of which is finding answers to coding questions. They are such a fantastic resource when you wonder how to string a series of functions together to produce a desired output or you want to figure out why the output you have produced is not what you expected and you are stumped.

BUT, they can be overused, and I recently realized I was using search engines when just reading the documentation would have been easier.

If you find yourself searching google for what inputs a function takes, or what they mean, or what the function is returning, or what an error code means, you are probably wasting time. Read the documentation first. READ, not skim.

I will give you two very specific examples of what I am talking about from personal experience.

  1. I recently wrote some encryption code that required me to split my input data up into blocks of size x. I found that the encryption function I was using (from an Apple library) returned an error whenever my input data blocks were larger than (x-11). Note that I already spent a lot of debugging time just figuring out that (x-11) was the magic number. I posted on StackOverflow after doing quite a bit of googling, only to have someone point out to me that another argument I was passing to this encryption function dictated that I should subtract 11 from my block size -- and it said so right in the documentation for the function. I had skimmed the documentation numerous times, but never read it thoroughly enough to catch that.
  2. I am currently working with a function right now that has return type OSStatus (which is really just a signed long). Whenever the function returned errors, I went to google and searched for "OSStatus [x]" where [x] was the returned error value. All I wanted to know was the meaning of the integer I was looking at, but often I had to dig through numerous google results to find out. Wouldn't you know it, those OSStatus values are also enumerated in the documentation for the function... duh.

iOS 5 vs. iOS 6 SecKeyEncryption code compatibility note

Wow. What a pain. I recently wrote code that encrypted some text on an iOS device using a server public key and the SecKeyEncrypt() function provided by Apple. The result was sent to the server to be decrypted using the server private key and the PHP function openssl_private_decrypt(). I am working with text that is longer than can be encrypted in one block using RSA public-key cryptography, so I needed to split the input into blocks and combine the encrypted results. The results were split again on the server, decrypted, and then combined.

The following code produces no errors on iOS 6 or iOS 5 — note that the copyPublicKeyForTag: definition has been omitted to simplify the example and focus on the bug. The server decryption of the data works when text is encrypted with this code on iOS 6, but not iOS 5. The fix for this problem is not difficult, but as far as I can tell it is only necessary because the iOS 5 SecKeyEncrypt() is buggy. The fix is explained below the following code block.

+ (NSData*)encrypt:(NSString*)data usingPublicKeyWithTag:(NSString*)tag
    OSStatus status = noErr;
    size_t cipherBufferSize;
    uint8_t *cipherBuffer;
    // [cipherBufferSize]
    size_t dataSize = [data lengthOfBytesUsingEncoding:NSUTF8StringEncoding];
    const uint8_t* textData = [[data dataUsingEncoding:NSUTF8StringEncoding] bytes];
    SecKeyRef publicKey = [Encryption copyPublicKeyForTag:tag]; //custom function to get public key from string tag
    NSAssert(publicKey, @"The public key being referenced by tag must have been stored in the keychain before attempting to encrypt data using it!");
    //  Allocate a buffer
    cipherBufferSize = SecKeyGetBlockSize(publicKey);
    // plain text block size must be 11 less than cipher buffer size because of
    // the PKSC1 padding used:
    const size_t blockSizeMinusPadding = cipherBufferSize - 11;
    cipherBuffer = malloc(cipherBufferSize);
    NSMutableData* accumulatedEncryptedData = [NSMutableData dataWithCapacity:0];
    for (int ii = 0; ii*blockSizeMinusPadding < dataSize; ii++) {
        const uint8_t* dataToEncrypt = (textData+(ii*blockSizeMinusPadding));
        const size_t subsize = (((ii+1)*blockSizeMinusPadding) > dataSize) ? blockSizeMinusPadding-(((ii+1)*blockSizeMinusPadding) - dataSize) : blockSizeMinusPadding;
        // Encrypt using the public key.
        status = SecKeyEncrypt(publicKey,
        [accumulatedEncryptedData appendBytes:cipherBuffer length:cipherBufferSize];
    if (publicKey) CFRelease(publicKey);
    return accumulatedEncryptedData;
Notice that on line 21, the size of each block is set to the size of the public key being used minus 11. Apple’s documentation explains that this is necessary because the PKCS1 padding takes up 11 bytes of the output data for each block. If you choose to encrypt just one fewer byte of data in each block, the encrypted data is accurate on both iOS 5 and iOS 6. Don’t ask me why; I believe it is a bug in the iOS 5 implementation of SecKeyEncrypt().

Line 21 changes to:

// plain text block size must be 11 less than cipher buffer size because of
// the PKSC1 padding used and 1 byte less again bc of Apple iOS 5 bug:
const size_t blockSizeMinusPadding = cipherBufferSize - 12;