Objective-C has fallen

It's been quite a ride since the plethora of WWDC announcements yesterday. In addition to awesome new end user features in OS X and iOS, cool new frameworks like HealthKit and HomeKit, and some expected upgrades and enhancements to Xcode, Apple really threw everyone for a loop by announcing a new programming language, Swift. When Craig Federighi dropped the news it felt like getting hit by a brick wall. You could tell something big was happening when he started talking about how great Objective-C would be "without the baggage of C,"  but you had no idea what. Then it hit. Swift.

What's crazy to me is the fact that Objective-C developers were the hottest engineers on the market just 2 days ago, and now the technology has effectively had its fate sealed. Thought you were golden as an iOS dev, bought completely into Objective-C? Nope.

I'm not saying iOS developers are all of a sudden SOL and should start worrying for their jobs, but man it hits close to home that an industry I'm so entrenched in is completely upended in a day. Sean Hess put it well in our CocoaHeads google group that "framework and platform knowledge has always mattered more than language syntax. Syntax is really easy to pick up. So all the knowledge that matters you'll carry with you. It won't take much time to get up to speed for any good Obj-C dev." Indeed, there's much to look forward to as an iOS developer right now, not the least of which being the ability to build better apps in less time with Swift.

Windows going free for phones and small tablets

Microsoft announced today that they are cutting prices of Windows for manufacturers to spur adoption. And by cutting prices I mean to $0 for Windows Phone and tablets under 9". Is this big news? I don't know. In the world of Microsoft it's definitely big news, because Microsoft's original business model was almost exclusively built around Windows OS licensing agreements. Microsoft aficionados may be rejoicing, but in the greater world of mobile my read on the situation isn't so optimistic.

I feel it's somewhat contradictory to Microsoft's recent actions -- increasing vertical integration with the Nokia purchase and the forward play into manufacturing their own Surface tablets. It felt like the strategy was shifting towards emulating Apple's model of controlling the end-to-end experience by owning the software and hardware, differentiated by a heavy dose of business/productivity functionality. Now they want to compete with Android by becoming an open platform? I'm confused.

Overall I think it's probably good for the industry, so that companies like Amazon, Samsung, Pebble, Fitbit, or other OEMs have more options than just homegrown or Android if they want to start a line of phones, tablets, or watches... but as an outsider the read between the lines here is that MSFT can't make the money they want by licensing Windows Phone/Windows RT (under 9"), so they are going to try and go the open route and see if they can build the ecosystem and make money off the app store like Android. The problem with that approach is that they are 3 years too late to that game too.

Hackdance & Second Government

Dru and I participated in Hackdance this past weekend. It was a 48 hour hackathon at the Deer Valley Lodges in Park City as a part of Collective's Disruptfilm event at Sundance Film Festival. From the site:

Hackdance: the first celebrity-driven social impact hackathon kicks off on January 16th, & you're invited to take part in this historical event! Your mission: partner your tech skills w a celebrity passionate about changing the world to design apps/hacks that use technology to create social impact.

We took school and work off on Thursday and Friday, not quite sure what we'd gotten ourselves into. Dru brought her product management and design skills to the game and I came in with my iOS and Android background. The event started with the celebrities sharing their ideas for social impact. There were a lot of good ideas, including the use of Plexi APIs for reporting and preventing cyber-bullying, an ambitious but thoughtful idea for virtual second government, and a movement for improving the Plant-a-Fish donation collection, among other ideas. Dru and I liked a few of the projects, and ended up joining our first choice with Alex Ebert for the idea of Second Government.

Dru and I teamed up with two "serial hackathoners" who were invited out from Silicon Valley. I think they've done something like 15+ hackathons in the past year, placing top 3 in over half of them. It was pretty cool getting teamed up together...until I realized how serious about hacking they were. With no hackathons under my belt, my most similar experiences were the BYU Mobile App Competition and Startup Weekend. Joining with a team of hackers was quite an adjustment.

The main difference was that both the mobile app competition and SW had an end goal to build a complete product or business, not just put something together for demo purposes. We had significantly different theories on how to tackle the weekend, but overall ended up with a pretty good balance. We ended up creating a semi-functional Reddit- and Stack Overflow-inspired website and iOS app, featuring proposals for governmental change and a system of comments and upvotes.

The goal of the platform is to provide an open system for proposing governmental change without all the bureaucracy and pessimism. Ideas are then voted, vetted, and refined, with the most popular suggestions rising to the top. While most people don't bother voicing their opinions on government because of little hope it will ever be heard, SecondGov provides the platform to test out ideas in a virtual world without the worry of what can or can't be accomplished. Ultimately, proven, popular ideas from SecondGov can be taken (with their tens or hundreds of thousands of upvotes) to the real government to make real change happen.

The team

The team

Alex, who won a golden globe for best original score just last week, was awesome to work with. He was definitely the most hands-on and supportive of the celebrities from my perspective. He spent a lot of time working with us on the direction of the app, design, and prepping for our pitch. Plus, he's an artist, a writer, and a performer... he knows how to make a point with some conviction.

Dru making an awesome face

Dru making an awesome face

Our pitch to the judges went well. We definitely bit off more than we could chew by working on a web app, iOS app, exploring a virtual reality platform, and trying out a pre-release iOS motion-tracking SDK by Plantronics in the two days. Our demo included a piece from all four, but my personal favorite was the Plantronics concept headset. We used it in conjunction with the iOS app to view proposals hands-free and upvote or downvote them with a nod or shake of the head. It wasn't necessarily a cornerstone piece to the premise of SecondGov, but it was fun to work with one of the hackathon sponsors and brought a little wow factor into the pitch. I'll post a video later if I get my hands on it.

Pitching to the judges

Pitching to the judges

The result was awesome. We won first place for social innovation, including a 5k cash prize and a 10k investment from the Sorenson Global Impact Investing Center.

Alex sharing the vision

Alex sharing the vision

Awesome projects from every single team. Other final products included a Google Chrome extension for reporting cyber-bullying, YoungStarter, improvements to the Plant-a-Fish donation system, Rah Rah's tech truck, a SHFT mobile app, and a Lead and Pledge movement to end domestic violence.

Related links

Finding the Right iOS Dev

Over the past few weeks I've had a few friends and colleagues ask me about the iOS developer interview process -- both on the interviewer and the interviewee sides. Having sat on both sides of the table, this post is a collection of thoughts on how to find the right developer for the job. I should note that these opinions are entirely my own and are completely subjective.

First, I think there a few things to consider before diving straight into interview Q&As -- there's a lot more to it than just rattling off a list of Objective-C programming questions found from a Google search. Yes, that can help you find smart engineers, but it might not get you the whole picture. Here are a few main points to consider when looking at a candidate:

  • Published work
  • Knowledge of Objective-C and Cocoa Touch
  • The right ratio of hackerness vs convention-use
  • Online reputation*
  • Overall tech savviness

Published work

You'll want ask for examples of published work. While at Cocoa Camp last summer I noticed several things that Apple looks for in a perspective engineer. Here are two from my notes:

  1. Someone who is driven to learn - and ship.
  2. Someone who has an obsession with creating - and delivering.

There are lots of extremely talented computer scientists and web developers in the world, but it takes a unique blend of hard-skills and finishing ability to make a good iOS developer. While pet projects are nice, that alone shouldn't impress you. Half-baked ideas are just that, half-baked, and not something you want to publish as your company's next app. Looking at the candidate's apps on the app store will tell you more about their experience level than their resume ever could. If their work was written as a team effort, ask them which pieces they developed or what percentage contribution they made to the overall app.

Knowledge of Objective-C and Cocoa Touch

You'll want to be sure the person has a solid understanding of programming principles, design patterns, Objective-C, and the Cocoa Touch frameworks. The depth of knowledge and understanding required will vary depending on the experience level you're looking for and how much you want to pay, but here are my suggestions for a good junior-level iOS developer.

  • MVC pattern - Ask the candidate to include an example or explanation of how they've used it in an app. 
  • Protocols and delegates - Ask the candidate "why are delegates protocols?" (and not normal classes). What I would look for is that the candidate can explain that protocols are more flexible than a normal class, because they can be implemented by any class, allowing for greater reuse. If they can explain this to you, in addition to the general idea behind the delegation pattern, that's a good sign.
  • Strong vs weak pointers - What's the difference? When would you use one vs the other?
  • Check out Ray Wenderlich's post on iOS interview questions.
  • Any questions specific to your project, code base, or existing development team that can help determine if this person is the right fit.

Hackerness vs Convention-use

I'm not sure what else to call this one. Objective-C is a very convention heavy programming language. If the candidate is a recent transplant from another development stack or a hobbyist iOS developer turned professional, they may not have fully embraced the Objective-C way (no ill-will towards these groups, I came in with almost exclusive Java/Android experience when I started with Objective-C). There are always opinions when it comes to code formatting, design patterns, and naming conventions, but with iOS in many cases there is a recommended best practice that should be followed.

You might be thinking "so what if they do it their own way, so long as it works" (especially if you're just looking for a temporary contractor). Wrong! No matter how small you think your project will be, there are going to be changes to be made down the road. And who's going to read that code? It might be the original developer, or it might not. Use of conventions allows for easier readability and better maintainability, and will lower your switching costs if the original developer doesn't work out or decides to suddenly leave for another gig.

If you yourself have a good knowledge of iOS development, brush up on your Cocoa Coding Guidelines and ask for a code sample. Look at things like use of class prefixes, method names, constants, and categories. Ask the candidate about software design. Do they design their code for personal use, quick-and-dirty, never to be touched again, or do they design their code with reusability and efficiency in mind. One of the best signs of a modern programmer is that they design their code -- internal and external -- as if it were an externalizable service - taking a page of Amazon's book. A code sample can also be useful to see their design style and identify particular areas of focus (e.g. networking, UI, data persistence, animations, etc).

Online Reputation*

I put an asterisk next to this one because I think this might be the most debatable point. For me personally though, I give bonus points for active use of GitHub, StackOverflow, App.net, and Twitter (unless its to manage a Biebs fan handle). Open-source software is huge both in web and mobile. If the candidate is familiar with pulling code off GitHub (properly attributed of course), it could definitely come in handy in the future. Better still if the candidate has contributed to open-source projects or created one of their own.

Completely on the other side of the coin, I know several excellent developers who don't care much for social media or personal branding. It's no knock on them, it's just not in their interests. That's fine too, just be aware of it and make sure the candidate is a good cultural fit for your team. e.g. if you're launching a social network for chihuahuas and the candidate isn't active on Facebook, Twitter, or Instagram, it's probably not the best fit even if they are extremely smart.

Overall Tech Savviness

Lastly, and you've probably done this by now, Google search the person's name and see what turns up. In emails or an interview ask them what they like about programming, iOS, and technology. You know this, but design is HUGE in mobile app development. It should be a big deal to the interviewee. UI/UX will make or break your business, so make sure you value this appropriately. I love that in a mobile developer job posting for Alpine Replay, their "next steps" are simply:

  • "Send us an email. Please include some of your sample work, a collection of your favorite designs (not yours) and whatever else you feel may be applicable."

A savvy design enthusiast who's up on the latest trends and upcoming iOS 7.1 or iOS 8 features could help take your app's user experience to the next level.

Disclaimer

All the suggestions in this post are personal opinion. Any and all of it should be adjusted to fit your needs and your team's culture.

Five Word Tech Horrors

Got a kick out of this hashtag over the last 24 hours.

No, Apple didn't copy Android

I wanted to get this thought out about 2 months ago, but here it is now. Better late than never.

There's been a lot of talk around the interwebz about Apple knocking off Microsoft, Google, or __________ (fill in the blank) with the latest refresh of iOS. While it's easy to complain about how this or that already existed elsewhere, rather than pointing fingers and chalking everything up to someone copying someone else, to me the much more logical explanation is that Apple has simply updated its design to be more modern (as have others). To say that flat buttons belong to Android is somewhat naive, because certainly Windows Phone has been leading the way in flat UI when it comes to smartphone OSes over the last few years. Further, if you read into iOS 7 and get your hands on it you'll see that Apple did not simply flatten everything out.

In the developer keynote, Craig Federighi stated that the goals of iOS 7 included three overarching themes.

  1. Deference - The UI defers to the content. It's helpful and intuitive, but unassuming and out of the way. This is a big change from the skeuomorphic ways of the past.
  2. Clarity - Clean, precise UI as well as a major increase in accessibility support.
  3. Depth - This is where Apple has struck gold IMO. They were able to modernize the interface, yet kept a distinctly unique experience by focusing on depth and contextual awareness using blurs and realistic, physics-based animations.
The focus on these themes and the amount of detail included at each and every level of iOS 7 make it apparent how truly unique Apple's approach to a 2013 mobile OS is. And the best part, Apple didn't go sell their soul to the flat UI gods - it's still very much iOS. More at Designing for iOS 7.

No, Apple did not copy Android. Apple took their time in moving on from the iOS design of the old, but they did it in their own way. And if you look at it, all major platforms and companies have moved to simpler, cleaner UI over the past 2-3 years. It's not one company stealing another's idea, it's the major players realizing the direction of design trends and incorporating them how they see fit.

It took Apple two years longer than it should have in my opinion, but as usual they came through with a excellent product in iOS 7 and I highly recommend updating if you haven't already.

Why singletons are bad

Disclaimer: This isn't a total knock on singletons. Alternate title: "Why singletons can be bad".

Software Design

Yesterday I had a conversation about software design with an experienced colleague and found myself reaching when discussing design patterns. Specifically, we got onto the topic of the singleton pattern. 

Knowing from recent experience at Cocoa Camp that singletons are not the end all be all solution for object oriented programming (yes, I might have thought that at one point), I was careful not to sound overly enthusiastic that I used the singleton pattern. I first learned about the singleton pattern in an Android development college course that I took in Winter 2011. It sounded pretty cool then, and it was even a semi-significant part of the midterm. I later began learning Objective-C, and after using the pattern in a few iOS apps over the past year - including collaborative projects with other developers who hadn't ever mentioned any negatives in the singleton pattern - I had gradually assumed that they were a pretty solid way to go. Last month at Cocoa Camp the pattern came up and although we didn't get into any detailed discussions on it, I got the impression that singletons weren't as favorable as I had thought... 

Back to our conversation, I mentioned that I knew singletons had positives and negatives and explained a little more about why I'd used them in the past. He pried pried a little deeper, asking two questions that I want to expand on. "What are some of the downsides to the singleton pattern?" "What alternative design patterns would you suggest?" I mentioned a few things, including keeping the object in memory for the entire life of the application, rather than when specifically needed, and that an alternative method could be to pass the data between view controllers rather than via the shared singleton instance. Then we moved on.  Conversation over.

Why singletons are bad

Later (okay, ten minutes after the conversation ended), I found Steve Yegge's blog post, Singleton Considered Stupid:

Begin Quote 

Here's what most people got out of Design Patterns: "blah blah blah blah SINGLETON blah blah blah blah". I kid you not. I've seen this so many times that it's become a full-fledged pattern in its own right; patterns need a name, so let's call it the Simpleton Pattern.

The Simpleton Pattern unfolds like this:

Me: So! Have you ever heard of a book called Design Patterns?

Them: Oh, yeah, um, we had to, uh, study that back in my software engineering class. I use them all the time.

Me: Can you name any of the patterns they covered?

Them: I loved the Singleton pattern!

Me: OK. Were there any others?

Them: Uh, I think there was one called the Visitater.

Me: Oooh, that's right! The one that visits potatoes. I use it all the time. Next!!!

I actually use this as a weeder question now. If they claim expertise at Design Patterns, and they can ONLY name the Singleton pattern, then they will ONLY work at some other company.

End Quote

I really hope I didn't fall into this category in the mind of my colleague, but wow was I unprepared for those two questions. Especially the second question. There are few design patterns with a name as catchy as the singleton pattern. There certainly are other ways and methodologies to accomplish a programming objective, but what's the catchy name for instance classes, interfaces, and passing data between controllers?

I've done some more reading and in hopes of getting it right the next time, here are some of my thoughts.

What do you think are some of the downsides to the singleton pattern?

There are actually a ton. The reasoning is pretty straightforward and I don't know why I didn't think of these earlier.

  • A shared singleton class requires that memory be in use throughout the entire application, even when the object isn't needed.
  • Singletons hide dependencies!
  • As a result of these hidden dependencies you can lose track of the coupling. Instead of meticulously passing each object you need (and only the objects you need) into a function, you instead call [AppUser sharedAppUser] to access your shared instance. While it feels cleaner since it can mean less lines of code to get the access you need, you can end up with very tightly coupled code.
  • You can't (really) subclass a singleton
  • Singletons are hard to test! (1) With hidden coupling it's difficult to create mock objects and (2) singletons generally exist for the lifetime of the app which presents a problem for unit testing, as each unit test should run independently of other unit tests.
  • Just think of it as the "global-ton" pattern. The name isn't that far off. Does it still sound as sexy? 

There are some upsides too, but I'll save that for another time. 

What alternative design patterns would you suggest?

  • Object oriented programming. This isn't just a snarky answer. Use instance classes that are instantiated within the scope that they are needed and pass those objects between methods or controllers as necessary. 
  • Create the instance of your object only within the scope that is needed (be careful not to abuse the AppDelegate).
  • Use dependency injection to pass a single instance of the object to the components that need it (like your unit tests).

Takeaway

      Be smarter. Understand what is actually happening when you use the singleton pattern. As tempting as slapping in SynthesizeSingleton.h into an iOS project is (see http://www.cocoawithlove.com/2008/11/singletons-appdelegates-and-top-level.html), it is NOT the solution to all your problems. You may not need it at all. Tightly coupled code can be a major problem with singletons, and chances are you probably aren't unit testing (or not properly anything) whichever objects you've transformed into singletons ...which you should fix. Most of all, if you enjoy software design but can only list of the singleton pattern when trying to have an intelligent conversation about design patterns, you have homework to do.

      Sources / Related Material

      Xcode Shortcuts

      Wanted to create a collection of my favorite shortcuts for Xcode. Some of them are muscle memory, but there's many more that I'm not using yet that I wanted to list here, probably more to help me remember than for anything else.

      Xcode Navigation

      • cmd + shift + 2 - open organizer
      • cmd + option + return - show assistant editor
      • cmd + return - show standard editor (hide assistant editor) 
      • cmd + shift + o - quickly open or jump to a file
      • cmd + ctrl + up/down - switch between header and implementation file
      • cmd + ctrl + left/right - navigate to previous/next file
      • cmd + click - jump to method declaration
      • option + click - open quick documentation

      Inline

      • ctrl + spacebar (or escape) - show code completion suggestions
      • ctrl + a + k + k - delete line
      • cmd + ctrl + e - rename variable in scope
      • cmd + f - open find bar
      • cmd + option + f - open find & replace bar
      • cmd + e - copy selection to find bar (without copying to clipboard)
      • cmd + g - find next
      • cmd + shift + g - find previous
      • cmd + ] - indent
      • cmd + [ - outdent
      • cmd + / - comment/uncomment current line

      Also, just stumbled across this great info graphic created by Robert Saunders. 

       

      Trying out Android Studio

      logo.gif

      Note: this post assumes you have an existing knowledge of Android development, probably using Eclipse. 

      The first time you download Android Studio, before you head straight into creating or importing your first project, start by checking for updates. In my case I downloaded Android Studio 0.2.0 from the developer site, but 0.2.6 was available. Definitely update to the latest version!

      One of the big fundamental differences between Android Studio and Eclipse + ADT is that you will now be using Gradle for your build system rather than Ant. I'm no expert on build systems, but I do appreciate good build tools (like Rake) and hopefully Gradle. I've only done 20 minutes worth of Googling Ant vs Gradle, so feel free to do the same. Or, if you want just think of Gradle as a more flexible version of Ant with superior certificate signing and command line build tools. Also, its integration with Jenkins is solid, if CI is your sort thing.

      configuration.png

      With Android Studio updated and a little knowledge of Gradle under your belt, create a new Android project. (The new project wizard is so straight forward my mom could do it.) You'll notice that the project structure is mostly familiar in terms of java packages containing your source code and your res folder containing layout files and image assets. Good, right? One major difference, however, is that you no longer live within a workspace. Each Android Studio instance now belongs to its own project. I haven't gotten used to the multiple projects with dependencies workflow yet, but I trust it will be eons more logical than it is in Eclipse. Okay. now for another new feature look at the top bar towards your configurations (upper right). This is something new. Here you can setup build configurations with specific application/target combinations. It's an easy way to switch between multiple emulators and devices.

      Couple other things to point out in Android Studio. The undo functionality is really smart. In addition to all the things you would expect, it can undo file deletions, creations, and its memory is very impressive. Another small thing that makes you happy is that Android Studio will replace @string/label references with the actual string in manifest and layout files. Hover over it to see the code and click to access it. Another cool thing in layout files is that missing files or resources will show up as red! This is huge! For me anyway I would run the my app on the device and only then find out that I had typed in the image name incorrectly. This has the potential to be a major timesaver.

      Keyboard shortcuts rock. Far and away my favorite shortcut in Eclipse is cmd+D (or ctrl+D) to delete line. I miss it every day in Xcode. Here are a few tips and tricks I've discovered so far:

      • cmd+backspace - delete line (a little different, but I could get used to it)
      • cmd+d - duplicate line
      • cmd+o - quickly jump to any class in the project
      • cmd++ - fold code
      • cmd+- - expand code
      • ctrl+spacebar - code completion
      • ctrl+r - build and run (using last selected configuration)
      keyboardshortcuts.png

      It's not all peaches and cream though. Even with just a few hours under my belt, there are already a couple things that slowed me down which I'd like to see improved:

      • When adding a new activity, double click does not move to the next screen (currently you must to click next)
      • Also in the new activity wizard, changing the activity name does not automatically update the layout name (even eclipse did this!)
      • Creating a new activity defaults to a vanilla package (rather than the currently selected package)
      • Double clicking a "error: gradle: no resource found that matches [filename]" doesn't link to the place where the invalid resource is being referenced
      • The Android emulator hasn't changed a bit

      Android Studio is still not a perfect solution, but neither is Eclipse. Overall it feels like a solid start and if its progression is anything like the progression of Android (oh boy the dark days of Froyo), it's only going to improve significantly over the next couple years.

      Growing Pains is Making a Comeback

      If you know me personally, you probably knew that I worked on an app called Growing Pains for last year's BYU Mobile App Competition. It's a photo journal designed to help you easily capture photos of your growing child. The interface is designed to allow you to quickly browse through and see your child's growth over various time periods (ideal for newborns and toddlers -- or puppies). While Growing Pains was a success in the competition, winning over $2000 value in awards and placing 5th overall, unfortunately it has not yet seen the light of day.

      A partner on the project and I have been talking recently about bringing it back to life, and last week while at Cocoa Camp Apple challenged us to bring our own ideas to work on, so I did just that. On Monday of last week I ctrl+shift+N'ed a new project in Xcode and started clean. Did this for several reasons, firstly, because Cocoa Touch changes so much from year to year that I'm sure our existing code base would require some amount of updating to get in line with the latest conventions and best practices. Secondly, and the bigger reason, is that while SDK changes have been semi-significant, changes to iOS design patterns have been EXTREMELY significant. Take the example below.

      You've probably seen and heard all about iOS 7, so I'll save my personal thoughts on the change for another discussion, the important points to note are the focus on simplicity, utility, and depth. With the greater population generally familiar with smartphones, as an app designer & developer I can now eliminate the use of some of the more cutesy effects that previously communicated "tap here", "I am a menu", "this is a button", and so on. Apple has also stressed depth in the new design, despite it looking more flat than before. By adding blurs, realistic motion effects, and new levels of perspective, iOS 7 is inherently more realistic than before, albeit far less skeuomorphic.

      Growing Pains is now undergoing its own transformation from the old world to the new. Here are a few of the design concepts for the new UI, shown alongside the original designs. Please feel free to jump in if you have any thoughts or suggestions. These designs are being iterated on almost daily at this point.

       

      What do you think? Are there any elements of the old design that you like better, or feel are missing in the new versions? Is it any more or less intuitive than before?

      Maybe Microsoft is doing it right. Or maybe they're not.

      Dell Venue Pro, running Windows Phone 7.5

      Since I first began seeing concepts of Windows 8 I kept thinking, huh, maybe Microsoft is onto something here. Despite being both an Android and an iOS fanatic, I have been impressed with the Windows Phone OS since trying out Windows Phone 7.5 from Dec 2011 - March 2012 on an extra Dell Venue Pro my dad had available. The hardware was...a brick... to put it nicely, but the OS itself was excellent. 

      Over the last 18 months I've found myself continuously (and to my friends' amusement) defending Windows Phone as a viable mobile operating system, and, as an extension, defending Windows 8. I've gushed over the Lumia 920, HTC 8X, and now the Lumia 1020. I almost bought all three of these devices on numerous occasions (just ask Dru). While I maintain that Windows Phone is a great OS, I'm coming to terms with the idea that maybe Microsoft isn't doing it right and that they did in fact jump the gun on the idea of the convergence of the desktop and the mobile experience. Since MS's release of Windows 8 there's been talks of how revolutionary and visionary it is. Ahead of its time. Some referred to it as showing that Microsoft had not only caught up to Apple and Google, but far surpassed their ability to deliver innovative products that end users didn't even know they wanted until they tried it (take the iPad for example).

      Well, after a year of saying to myself, yeah, maybe they did get it right, maybe Windows 8 isn't as radical as all the critics say, maybe we will all be using touchscreen desktop computers in a couple years, I'm now saying maybe not. 

      The truth is that the people don't want the same experience on a tablet as they have on their desktop or laptop. Sure, they like familiarity, but at the core a user's interaction with a tablet and user's interaction with a desktop computer is just different. And people are fine with that. The design of an application on the desktop environment is (and should be) vastly different than the tablet and the phone representations of that same application. Probably one of the best examples of this is the Day One app for iPhone, iPad, and Mac. Ask any active Day One user if they'd like to combine either the iPhone and iPad experience or the iPad and Mac and they'd look at you like you were crazy.

      Day One for iPhone, iPad, and Mac

      Further evidence that people just don't want to merge desktop computing and mobile computing... look at this Acer commercial comparing their 8" Windows tablet to the iPad mini. This is my opinion, and I bet some Windows 8 fans view this commercial as a win for Acer and Windows 8 Pro, but firstly, who wants to play Halo on a tablet (not that they even look like they're actually playing...)? Don't get me wrong, I love iPad games... Plants vs. Zombies vasebreaker endless mode... that'll keep me busy for HOURS. But I don't really care for the idea of getting a dumbed down PC gaming experience on my iPad. Maybe if the entire game was reimagined for iPad, and it really was just a distant relative of Halo, but the ability to run full-fledged PC games on a tablet just doesn't do much for me. Okay, next flaw in the video, of all the things you can do on a tablet, why show someone accepting changes to a Word doc? I mean, seriously, of all the things I've used a tablet for (thinking my Kindle Fire, Nexus 7, and iPad), I have never once wanted to accept changes to a reviewed Word doc. And if I did, I wouldn't want to be using the traditional Word app to do it (see all those tiny touchpoints?!).

      UPDATE: I hadn't done my research on Halo Spartan Assault, and it looks like it very much is  the Halo experience reimagined for touch. That's cool. What I was trying to get at is the idea of playing traditional PC games on a tablet running Windows 8 Pro.

      What I'm getting at (and have probably repeated 20 times by now) is that I no longer believe that we are heading in the direction of an integrated desktop and mobile computing environment. Those who never got on the Windows 8 bandwagon are probably thinking, yeah, knew that all along. But for those who have seriously entertained the idea of everything converging into a single, universal experience, either the timing is wrong or the implementation is wrong. Either way, maybe Microsoft isn't doing it right after all.

      Configuring Xcode and Bamboo CI Server

      NOTE: This document was written with respect to Bamboo 4.4 and version 1.8 of the Xcode plugin. I'll update it to Bamboo 5 and v 2.1 soon.

      Here's the process, from top to bottom, including my little discoveries along the way.

      Install the Bamboo iOS, Cocoa and Xcode plugin

      • First off, note that Bamboo has its own marketplace (as opposed to one for your JIRA instance). In order to do this, you need to be an administrator in Bamboo (but not JIRA).
      • Navigate to Administration -> Plugins -> Find New Add-ons. Search Xcode and install the plugin. No additional configuration or plugin management needed here. This simply enables a few features like support for adding the iOS SDKs and Xcode tasks, which you'll get to later.

      Creating a remote agent in Bamboo

      • From the Administration tab, go to Agents and select install remote agent. You can install it wherever you'd like... I wouldn't recommend your downloads folder though. I put mine in /Documents/dev/bamboo-agent-home.
      • If you have problems running your remote agent to the tune "Could not load properties", you may need to explicitly set your port number or open a port on your firewall. This Atlassian Support Q&A was helpful for addressing this issue.
      • For more information see the Remote Agent Installation Guide.

      Configuring Capabilities for your Remote Agent

      • Agents use capabilities for two purposes, (1) to tell the agent what it can do, and (2) in order for jobs to identify which agents can run which build plans.
      • Regarding point 1, you will now create two capabilities that will allow you to build you project for iPhone and for the simulator.
        • From the Agents screen, select your remote agent
        • Select Add Capability
        • Select Xcode SDK as the compatability type
        • Enter Simulator - iOS 6.1 as the SDK Name
        • Enter iphonesimulator6.1 as the SDK Label. ****This part is what took so much time to figure out. In a couple of the blog posts out there it recommends using the command 

         

      • Regarding point 2, this is important because if you don't specify capabilities, your build plans will try to run on all agent that meet their basic requirements. In our case, our web team's build plan's requirements weren't set to the appropriate capabilities, so whenever a build occurred and the OSX remote agent was running, it would try to run on both agents, causing it to fail immediately on our remote agent. Note that custom capabilities are often used to control which jobs will be built by which agents, the most common one I've seen being an isLocal flag, which only allows the local agent to run the build plan.
      • For more information see Agents and capabilities.

      Connecting to your GIT repository

      • After you have configured your remote agent, create your plan. This part is fairly straightforward, which the exception of connecting to your GIT repo, which can be tricky.
      • In our case, a user named 'fisheye' has already been setup with the appropriate permissions and keys on neptune. Unless something has changed, don't worry about generating new ssh keys for yourself and putting them up on neptune. Have Jacob login and upload the private key for this user.
      • Note that the repository URL should include ".git" at the end, i.e. ssh://something@path.com/home/git/myapp.git

      Creating Tasks for Your Build Plan

      • Task 1 - Source Code Checkout
        • The first task you'll want to create is Source Code Checkout. Actually, it was probably done automatically. Make sure the repository is set to your project and run your build plan. You should be green.
        • At this point, if you run into a NoClassDefFound error, check out this support Q&A. Basically, the fix is to downgrade your Xcode plugin to v1.8 and try again. You can download it at the link at the top of this post. To install it, within Bamboo go to Administration -> Plugins -> Manage Add-ons -> Upload Add-on. My guess is that the latest version of the plugin targets Bamboo 5.0 and at the time of this posting we are running Bamboo 4.4.4. The plugin says it supports 4.4... but yeah...no dice.
      • Task 2 - Build the Xcode project
        • Next up we want to create a task to build the Xcode project. This is where those iOS SDK capabilities that we setup earlier come back into play. The first thing to keep in mind here is that essentially all this task will do is build your project, the same way you would if you built it from terminal using xcodebuild, e.g. xcodebuild -sdk iphonesimulator6.1 -project PRTablet.xcodeproj -alltargets -configuration Release. 
        • My personal suggestion here is to forget Bamboo for a minute and try building your project from the command line. In our case, command line builds failed with compile errors because the main PRTablet target can't see the RestKit subproject files (despite it building correctly in Xcode). To get around this, you'll want to setup a workspace and scheme rather than an xcodeproj and target, which will build all projects in the same directory, referred to as the workspace build directory. Now, all of these files are visible to each project. Verify it now builds successfully from the command line, e.g. xcodebuild -sdk iphonesimulator6.1 -workspace PRTablet.xcworkspace -scheme PRTablet -configuration Release.
        • Now that you know it will build successfully, create a second task under your build plan. Select Add Task -> Xcode. When you're done, it should look something like below.
        • Save and run your build plan. If you got a "possible compilation error" check the logs. If it's an xcodebuild error: "The workspace does not contain a scheme named," you need to go back into your workspace, go to Manage Schemes... and check the Shared box next to your scheme. Push your code and run your build plan again (Bamboo may even do it automatically this time). You should now be green.
      Screen Shot 2013-07-26 at 6.27.42 PM.png
      • Task 2.5 - Unit Tests
        • To run have your agent execute your unit tests, you'll need to check the "Include OCUnit Test results" box above. See the Xcode docmentation. Note: I've been unable to get this working so far, since Bamboo for some reason is unable to see our unit tests. The error message reads "Failing task since test cases were expected but none were found." I found a support Q&A for this problem and added comment asking if anyone has found the fix.
        • UPDATE: Looks like unit tests with a test host cannot be run in the simulator in v1.8 of the app. If you can, upgrade to v2.1. In versions 2.0+ of the plugin, you can use the ios-sim method to run application tests from the command line.

      Working (or not) with Git submodules

       A BYU CocoaHeads club member recently posted to our google group that she’s been having problems with Git and submodules. There were some great responses, suggestions, and tips, and this is my take on Git submodules.

      I’ve had some frustrations with submodules, git, and team projects. Now, whenever installing a third-party framework that has supports submodule installation I generally tend to skip that part, download the most recent stable source code, put it in my git repo, and install it w/o using any submodules. This also gives me the ability to update to new versions more selectively, which I prefer… one reason being that by default some of those submodules may be pointing at active development branches rather than stable, production quality/tested code. If you simply copy and paste their installation commands, later on you might get some buggy code when you update. Of course if you’re careful and read through the changesets before you update, double check the submodule branch is what you want, etc, submodules can be really helpful. I just got burned a couple times when I was starting out with git and since then my personal git workflow has progressed w/o using them for the most part.

      Testing in iOS

      I’ve been researching Continuous Integration (CI) and unit testing in iOS lately and learning a lot about testing your application. So far, I’ve learned how to write unit tests in Xcode, some basic guidelines for writing those tests, and experimented with Jenkins CI server to create automated builds, tests, email notifications, and archives. This post is meant to be a collection of my thoughts and takeaways.

      Two Types of Unit Tests

      The are two main types of unit tests in objective-c, logic tests and application tests. There also two general approaches to unit testing, which happen to correlate: bottom up and top down. In bottom up testing, you look test each method or class individually, entirely independently of each other. In top down testing, you test the functionality of the app as a whole.

      Because your logic tests are independent of each other, they can run without needing the context of your application’s controllers or views. Logic tests can only be run on the simulator. Application tests are (appropriately) run in the context of a host app, and can be run either on a device or in the simulator.

      Efficiency in Unit Testing

      After figuring out a how to create unit tests, run them, and seeing the little green checkboxes telling me they passed my first reaction was to get a little unit-test-happy. I was thinking oh, I can test this, and that, and all of that… Well I’m finding that there’s a balance between efficient, high-quality unit tests and simply testing every single input and output.

      When you test parsing a JSON response from your server, for example, ONE way to do it is to assert that the final property value is equal to the original value in the JSON. There are however, many more ways to test your parsing and relational mapping. You might try testing for valid data using character sets, checking string lengths are greater than zero, or that birthdates are before today’s date. Then, try 4 or 5 different data sets, rather than a single one.

      Basically, rather than test for a specific outcome with your logic tests, be a little more broad. Trying to test for a very specific output might be beneficial in some cases, but it can quickly become tedious and time-consuming. Testing for types of data, unsupported input characters, and invalid states can cover more errant cases in less time. Significantly less time.

      The Sweet Spot 

       

      image-thumb1.png

      I found this graphic in a blog post about unit testing best practices  about halfway through my research and was really glad I did. Essentially, unit tests should hit the sweet spot of testing individual units (bottom-up) or testing the entire system (top-down) and not fall into a dirty hybrid that only costs additional time and effort without proving much.

       

      RestKit - Load data from local json file

      I've found that it can be very helpful to be able to load data locally rather than from a server, especially for testing and for situations where you don't have control over the availability or stability of the server side. This code sample shows how, using RestKit, you can load json directly from a file. If you knew what the expected server response was, but didn't have access to the server, this would allow you to put all the object mappings in place and load your object in without requiring a live server. https://gist.github.com/kyleclegg/5846568

      Google Fiber coming to Provo

      Our pre-registrations paid off!

      Let's go utah... pre-register now. All of you. 1000Mb/sec #googlefiberfiber.google.com/about/

      — Kyle Clegg (@kyle_clegg) July 26, 2012

       

      gfiber2.png-fileId=19601385.png

      The #EpicProvoAnnoucement hashtag on twitter has truly turned out to be epic. Provo is getting Google Fiber and it makes sense for so many reasons:

      Screen Shot 2013-04-17 at 2.02.43 PM

      Screen Shot 2013-04-17 at 2.02.43 PM

      • Entrepreneurship - Provo is one of the best places for tech startups outside of Silicon Valley -- on the same level as Austin.
      • Infrastructure - There's an existing infrastructure in place, put there by the city of Provo nearly 10 years ago. It failed (IMO) due to the greed of who decided to limit the speeds to near cable-levels and charge only marginally lower than other providers. Stifling innovation in the pursuit of some extra $$s.
      • Data - Genealogy research is huge in Utah, with several large organizations likely to get on board ASAP.
      • Students - Provo is home to a major university in BYU, with another 25,000+ university ten minutes away in UVU.
      • Innovation - Utah IS Silicon Slopes!