Even though I have been at this “dad thing” for ten months now (is he really that old already?), I am still learning new things about myself everyday. The latest thing I have learned about myself is the cause of my frustration when Max is upset: I am focused on doing something else. I believe that when I am thinking of something else I need to do (whether it be work or housework) I am more likely to become frustrated when he is fighting a nap or his bedtime. I am out of the moment. I am missing this time because I have something else on my mind.

I need to stop becoming so frustrated. I need to stop missing moments.

Today, I read an interesting article regarding what not to say to developers who are just getting started. This topic has been on my mind as of late. I totally agree with this sentiment. Developers (and I am including myself in this) can be condescending toward other developers. We criticize other developers’ taste in technologies; we criticize his or her choice in tools, languages, and platforms. My brother-in-law, who has recently started working as a mobile developer, was ostracized by a few developers at his new company because he uses an iPhone. “Why would you use an iPhone? Android is what real developers use,” they chided. Instead of supporting a fellow developer who was just getting started in the field, they insisted on chastising him for the device he chose to use.

I believed that this negative behavior stemmed from arrogance, ignorance, and callousness. After reading the aforementioned article, however, I have switched my line of thought: I now believe this negative behavior stems from a deep insecurity that developers have of being wrong. I believe that we constantly fight to prove our methods (tools, languages, or platforms) are the correct choice. I also believe that this behavior is not necessary and that most developers will eventually grow out of it as though it were a juvenile phase in our adolescence that we will, hopefully, look back upon in embarrassment. I am at the embarrassment stage in my career now. I feel bad for the negative behavior that I exhibited in my development youth. I was not only negative, but borderline belligerent at times. I think this behavior started and manifested itself due to the environment in which I started working. We need to take our environment and who we surround ourselves with into consideration. You eventually become what with which you surround yourself. I am glad that I am starting to surround myself with positivity.

About six months ago, I started using Git through the CLI rather than through a GUI. I did not really have a reason for doing this other than the desire to know more about the tools I use day to day. My Git-fu is still weak, but it is getting better.

I recently decided that my Git CLI experience would be greatly approved with the aid of spellcheck. Luckily, I stumbled across a post detailing how one can enable spellcheck in Vim (my default editor). Unluckily, it did not work for me with Yosemite’s default version of Vim in Terminal. After struggling with this for a bit, I finally decided to upgrade to the latest version of Vim via Homebrew:

$ brew install vim

After installing the latest version of Vim, I created my ~/.vimrc (I am guessing this is not created by default as I did not see it on my machine) with the following content:

set backspace=2
syntax on
autocmd Filetype gitcommit setlocal spell textwidth=72

The first line enables what I believe to be the correct behavior of the Backspace (Delete on Mac) key: while in insert mode, the character immediately to the left of the cursor is removed and the cursor moves to that position (along with the text shifting to the left). I stumbled across a post indicating that this is not the default behavior in Vim, but it is the behavior I expect.

The second line turns on syntax highlighting. What I found to be unique about this feature is that it will actually highlight your Git commit message in such a way that the “title” of your message is highlighted to indicate when your title is too long (the recommended length, according to Github, is 50 characters). It also helps highlight comments in your commit messages.

The third line is the “money” line. This line enables spellcheck for gitcommit files. This line also includes a nice little extra to wrap our commit message bodies at 72 characters per line, which is the recommended length according to Github.

One other little tidbit I came across is you can use the following to ensure that Git uses your preferred editor (meaning the version of Vim I have installed via Homebrew):

$ git config --global --replace-all core.editor $(which vim) -f

I am not sure if this change is strictly necessary; it may just be belts and suspenders, but I would rather be safe than sorry.

If you want to know more about my setup, be sure to follow along under my Environment section.

I have been asked to participate in a panel. The panel will be a debate/discussion between mobile developers on which mobile platform is the best. I have been tapped for the iOS side. Leading up to tonight’s event, I have been jotting down my notes on the talking points I was given by my team. I have decided to post my notes for posterity. Each section title will be a question that I was given by the iOS team, followed by my notes. Enjoy.

What Problems with the iOS Platform Still Need to be Addressed?

I find that there are many developer APIs in iOS 8 that do unexpected things or are broken. I believe that Apple could probably use a development cycle to just clean up the platform and make it a bit more robust. I think it’s atrocious that Apple still offers flagship iPhone models with 16GB of storage. I don’t really care about expandable storage, but the fact that the baseline model comes with a paltry 16GB is ridiculous. I can’t recommend that device to anyone. I also feel that it’s time for Apple to increase the amount of RAM found in iPhones. New iPhone models currently come with 1GB of RAM. I honestly don’t see a performance hit from this in day-to-day operation, but there are times when I notice it (mostly when I have had Safari in the background for a while and upon returning to Safari, my open tabs reload since they are no longer in memory).

How Long Would it Take to Become a Competent iOS Developer? An Expert Developer?

I honestly feel that both platforms are fairly equal in the length of time it would take for you to become a competent or expert developer. There are so many great resources out there for both platforms (the developer documentation for each platform is top notch and you can usually always find an answer to your question on Stack Overflow, which has a very active community for both platforms). I think the community behind iOS development is probably larger at this time, but its fairly comparable. I think you can probably become a competent developer for either platform in 2-3 months. You can become an expert developer in a year. The key is to have someone who can review what you write to keep you honest and to ensure that you are observing good coding practices (specifically for that platform).

Where do You See iOS as Superior?

I feel that iOS is superior in a few different areas (although I’ll admit that some of those gaps are closing and some of the ways I feel iOS is superior are purely subjective). These areas are developer tools, the development language/system, user experience, and the camera.

Developer Tools

I feel that the developer tools that Apple provides are still better than the tools provided by Google. I believe Google has closed that gap significantly with Android Studio (IntelliJ users rejoice!). My first Android development experience involved Eclipse and, while Eclipse is what is is, it always felt a bit hackie to me. I feel Google is still lagging behind when it comes to user interface layout. The Interface Builder piece of Xcode is so easy to work with and what you see is pretty much what you get. I think Instruments is far and away better than any of the profiling tools provided to Android developers by Google.

Development Language/System

I believe the iOS development language du jour (Swift or Objective-C) is superior to Java. While language preference is purely subjective, there are some objective features where I feel like the iOS development platform is head and shoulders above the Android development platform. One of those is iOS’s Automatic Reference Counting (ARC) vs Android’s Garbage Collection. Garbage collection is an old idea that Android has implemented. It’s a methodology of reclaiming unused memory. It essentially scans the devices memory and determines which objects are currently being referenced and which objects are not. It then deallocates any objects that are not being referenced to reclaim memory (this is a very elementary example of how garbage collection works, so please forgive its crudeness). The issue with garbage collection is that it’s horribly inefficient. It’s slow (the length of the scan varies depending on the amount of memory in the system and how much of that memory is being used), requires more memory than other systems, and isn’t foolproof (it may be fixed by now, but I once knew of a way to guarantee memory leaks while writing Android code).

iOS has a thing called Automatic Reference Counting. ARC is not garbage collection (and to call it garbage collection is an insult). It’s a clever way of automatically managing your memory. It keeps track of how many references an object has (how many owners). When you reference an object, that object’s retain count increments. When you dereference an object, that object’s retain count decrements. Once an object’s retain count hits zero, it is released or deallocated. It is not foolproof, but it is definitely more efficient and requires less overhead.

User Experience

For my money, the iOS user experience exceeds that of Android’s user experience for the majority of users. On iOS, the only variability in user experience comes from the hardware. If you’re using an older device, your experience can be different than it would be on the latest and greatest hardware. Your experience can vary wildly on Android as you have different hardware manufacturers. Not only can your experience change based on the manufacturer’s build quality or the hardware specifications, but Android manufacturers are also able to “customize” (read: make it shitty) the operating system so that their devices may stand out amongst the numerous other Android devices on the market. You can, of course, install a different Android mod on your device. To me, that can be a bad user experience. I’m going to have a very difficult time explaining the steps of that process or why a person should even attempt to do that. Of course, I realize that one of the features or selling points of Android is the freedom for a more knowledgable user to customize his or her device. My opinion though is that the default experience that most users will have is a bad one. I doubt that first time, non-technical Android buyers are buying Nexus devices. I would guess that those first time, non-technical Android buyers are buying what the Verizon or AT&T sales person is recommending to them, which in many cases is an inferior product. I personally like the experience of stock Android Nexus devices. It’s just a shame that you can’t get that stock Android experience on most devices (it’s also a shame that Google no longer makes a normal sized device.

Camera

The last area where I find that iOS is superior is in the photos and the videos you can take with an iOS device. For my money, the cameras in iPhones produce better quality images than their Android counterparts. Android is closing the gap, but for the longest time I could usually take a look at two pictures (one snapped with an iPhone and one snapped with the leading Android device) and I could identify which one was captured with the iPhone and which one was captured with the Android device. Historically, pictures snapped with Android devices have always looked grainy or cloudy. When I’m at the park with my wife and son and I want to capture a moment, I’m never worried about getting a good shot with my iPhone. I know I’ll get a good shot with my iPhone.

Would You Ever Switch to Android? If So, What Would it Take?

I would possibly switch. I have used Android in the past as my daily driver. I just wasn’t “in love” with it. Certain components of the UI worked just differently enough (and, in my opinion, incorrectly) that it became irksome to use an Android device. I used a Nexus One (yeah, I’m one of the ten people who bought one of those). This was back in the 2.1, 2.2, and 2.3 days (fro-yo for life!). Out of quite a few UX things that irked me, two still stand out in my mind: tap targets and that damn back button.

I never became comfortable with the default Android keyboard (I’m aware I could have installed a third party keyboard, but I’m not a fan of that; I haven’t even installed a third party keyboard in iOS 8). My keyboard theory is that the default iOS keyboard placed the touch targets somewhere below the key view (and these would dynamically resize based on what you were typing). It felt as though the Android keyboard placed the touch targets right on top of the key view. I’ve always heard that when we tap on touch screens that we are actually tapping slightly below where we think we are tapping, so this theory always made the most sense to me.

The back button, in Android, is such a wildcard. What does it do? The simple answer is that it literally takes you back an activity (to use Android terminology). The OS keeps a history stack and as you navigate around your phone, it adds entries to that stack. If you hit the back button, it simply pops the top activity (the one you are currently viewing) off the stack and the activity that is now on top of the stack is the activity you’ll see. I always found this unnerving because if you don’t remember your navigation history, you don’t really have a way of knowing where the back button will take you. iOS always seemed a bit simpler to me. Each app is in control of its own navigation history. You’ll have a back button present if you have views in your history. If you reach the bottom of stack, there is no back button. To leave the app, press the home button.

For whether or not I would switch back to Android: it would really be a matter of Apple dropping the ball on what they have going. In my tastes and in my usage, my allegiance is Apple’s to lose. I’m a bit concerned about the quality of the operating system after some of the huge strides Apple has made in the past two versions of iOS, but, overall, it’s been reliable for me.

[1]: A memory leak is when an allocated object can not be deallocated until the process that owns the object is terminated or the system is restarted (depending on what owns the said object).

[2]: I just want a reasonably sized device and even the 4.7” iPhone 6 feels too large for me.

My ten year high school reunion is scheduled for this Saturday. I am, begrudgingly, attending. Why begrudgingly? It’s none of your stereotypical reasons. I wasn’t bullied in high school. I was relatively well liked. This is before I started spending most of my time in front of a computer screen, so I was fairly social. I actually had a few close friends and was friendly with everyone. The question remains: why am I begrudgingly attending?

At first, I thought my reluctance was rooted in my feeling of separation from my fellow graduates. Out of the approximately eighty students in my graduating class, I regularly talk with two to four of them. I recently deactivated my Facebook account, but even before then I rarely communicated with anyone else. They were doing their thing and I was doing mine. Separation seemed inevitable. We had our own lives to live and I was busy living mine.

Earlier this week, while driving to work and listening to Pink Floyd’s Dark Side of the Moon, I was hit with these lyrics:

You are young and life is long and there is time to kill today

And then one day you find ten years have got behind you

- Lyrics from Pink Floyd’s Time from Dark Side of the Moon

I slowly realized that my reluctance was not from the separation: it is from sadness. We spend most of our childhood after a certain age, looking forward to our high school years. I can remember wishing away my childhood for those four years. Before I realized it, that time was gone. I was heading off to college. With, what in retrospect feels like, a blink of the eye that time, too, quickly passed.

Earlier this year, there was a bit of a kerfuffle regarding filing bugs for Apple’s APIs and whether or not us developers should file them. In the past, I never really took the time to file them. I was either too lazy or assumed that the bug was in my code. I’ve always been pretty skeptical of faulting the tools for faults, but I’ve learned that occasionally we are charged with faulty tools and that this is okay. It’s part of development.

At Lonely Planet, we recently came across a particularly nasty bug that we determined to be an issue with iOS APIs. I created a sample project and filed a bug report with Apple. This is only my second filed bug report. Maybe it’s the newness of it all, but I’m not quite as jaded as some of the other developers out there. I hope I never fall victim to that, but I realize it’s all in context of past experiences.

Whenever I take the time to file a report, it makes me feel as though I am doing something good. I would want someone to file a report with me if I were to have a fault in my code. Why shouldn’t I return the favor?

America is all about speed. Hot, nasty, badass speed. -Eleanor Roosevelt, 1936

Yesterday was kind of a crummy day. My back hurt. I forgot paperwork for my son that his daycare needed, which led me to me making two trips to his daycare (don’t worry, I picked up some nice coffee along the way). I had to sit in traffic. There were lots of little things that nagged at me yesterday. However, there was one big thing: I didn’t feel as though I accomplished much.

If you were to look at my commit history for yesterday, you might believe that I actually accomplished many things. You’d be mistaken. My commits were jumbled and incoherent. I wasn’t outlining my thoughts. I didn’t have a clear path. I kept hammering on my keyboard and slamming my head into that proverbial wall, but brute force was failing me. After hitting a teeth-gritting breaking point, the quote above came into my head. Here is my full commit message from when I hit that breaking point:

Nasty Commit to Save Work Attempting to add tests to verify that the link -> entity relationship is working correctly; Cleaning up some stringified keys and using NSStringFromSelector instead.

America is all about speed. Hot, nasty, badass speed. -Eleanor Roosevelt, 1936

That commit message makes absolutely no sense (and yes, I actually did include that quote in the message). I was frustrated. That commit touched fourteen files, contained two hundred and seventy-three additions, and disregarded fifty-nine deletions. It was a mess. Quite frankly, I’m ashamed of it.

I have been striving for small, granular commits. I want my commit messages to be concise. If I can fit an adequate description in the title portion of the commit log, that’s even better. This commit was cumbersome. It touched way to many files and made no sense. I can’t even begin to describe what I changed.

Today was much better. My commit history reads like a diary (albeit a confusing diary). I’m improving, but I’m not there yet. I’ve been debating on how I can go about making sense of what I do. Maybe I should keep a diary of what I’ve been working on. This could be beneficial as I encounter problems that seem familiar (Have I encountered these problems before? What did I do last time?) or even help shed light on what I should be doing or the path I should be taking. It would cause me to stop and think about what I’m doing or what I’m trying to accomplish instead of hammering as hard as I can on my keyboard.

The older I get, the more sure I become that humanity is devolving. I can only assume that Idiocracy is actually a “futurementary”: a documentary to warn humanity about the dangers of what lies ahead if we continue on our current trajectory.

I have recently been stunned by what we in the technology field choose to spend our time doing and what investors insist upon funding. A recent application received $1.5 million for doing less than current messaging applications. That’s right: an application that does nothing except send a one word message to your friends has raised $1.5 million. The New York Times piece links to a press release announcement from Blonde 2.0 (the self proclaimed world’s leader of digital marketing) which is riddled with mindless drivel that attempts to glorify one of the single worst ideas I’ve ever heard. The press release refers to Yo as “[an] incredibly simple communications app”. The application, as it stands today, literally allows you to send “Yo” to your friends or family. Are you fucking kidding me?

The New York Times piece quotes John Borthwick, the Chief Executive of Betaworks (an early backer of Yo), as saying,

We are fascinated by these uses of simple yes/no on/off communications tools. There is no payload in Yo — no pictures, no text, just a deceptively simple on/off state that over time has the potential to become a platform.

I hate to burst your bubble, but there is nothing “deceptively simple” about this platform or this application. I am not stupid. I fucking realize how simple this entire idea is. I’m just at a loss for words that the equivalent of a Facebook poke is being invested in so heavily. It’s shit like this that makes me embarrassed to tell people that I write software.

As I age, I am perturbed that my mood is directly tied to what I feel that I am either accomplishing or not accomplishing at work or, rather, in software development. I have recently found that I can be quite foul if I encounter a problem in software that I am writing. I encounter many problems that do not affect me, but I have found that the ones that do affect me tend to have the same earmarks: an unfamiliarity with a framework or an API, a misunderstanding of how a framework or API is intended to function, or, my biggest fear, unexplained behavior of a framework or API. I was recently plagued many hours on an issue at work that I feared fell into the latter category.

I have worked with Core Data on many occasions now. We are using it in our project at work. However, I started noticing odd behavior in some of our tests. There were NSManagedObjects that were not updating as expected when importing example server responses. The tests were passing and unexpectedly not passing later. This was bothersome. I ended up stepping backward through our commit history until I narrowed it down to a particular commit (actually, a particular pull request being closed). My first inclination was to expect an issue with our .xcdatamodeld file (the backing of our Core Data model). All of the changes in this commit seemed innocuous enough. We were adding relationships and parameters to objects, but none of them should affect our import logic. After introducing these changes one by one into a detached HEAD state in our repo, I came to a startling conclusion: None of the data model changes actually broke our data import. This was terrifying. I was stumped. My mood was quite foul.

When you’re stymied by a problem, everything is stupid. Your computer is stupid. Your tools are stupid. The language is stupid. The framework causing you grief is stupid. Stackoverflow is stupid. Everything.

With the recommendation of a coworker, I took an early lunch. He rightly pointed out that I needed to step away from the problem. Once you’ve had your head down on a problem for an extended period of time with little progress, you become stuck. I was most definitely stuck. During our lunch break, we actually spit-balled ideas on what the issue might be. We came up with a few theories. I was reenergized. After being back in the office for a bit, my energy was zapped again. All of our theories were bunk.

I went back to the drawing board. Something finally caught my eye. It was a category for one of our NSManagedObjects that was overriding willChangeValueForKey:. I just happened to notice that this method was not calling super. Someone had forgotten to call super. I was vaguely aware that Core Data and MagicalRecord (a library to simplify the Core Data layer that we are using) use these methods for updating relationships. I am much more aware of that now. I added the super call. BOOM. I was back in business.

I believe the frustrating piece of this episode is the concern that something is now broken that had been working and there is no clear stressor at what triggered the issue. After making this fix and verifying the fix, I was elated. Not only had I fixed a particularly nasty defect, but I learned more about Core Data in the process.

I recently purchased a new 13” MacBook Air (which is a truly wonderful machine). Before I booted the machine for the first time, I started to contemplate what was needed for the machine to be setup for my development needs. I have, regrettably, avoided keeping track of what my environment looks like. I decided to change that. I have started tracking my environment setup on a static page on this site. It may not be the ideal setup for everyone, but I have found that it is the bare minimum of what I need (it is a work in progress and I plan to keep it updated as my methods and needs evolve).

If you have any questions about my setup, please feel free to ask.