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.

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

      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?

      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

      Tidy JSON Formatting with TextWrangler

      This script can be used to format JSON. Place the script in your TextWrangler Text Filters folder. For me the path was /Library/Application Support/TextWrangler/Text Filters. You can name the script whatever you want, just make sure to give it a .py extension. I called mine TidyJSON.py.

      #!/usr/bin/python

      import fileinput
      import json

      if name == "main":
      jsonStr = ''
      for aline in fileinput.input():
      jsonStr = jsonStr + ' ' + aline.strip()
      jsonObj = json.loads(jsonStr)
      print json.dumps(jsonObj, sort_keys=True, indent=2)

      After saving the file, restart TextWrangler and go to Text -> Apply Text Filter -> TidyJSON. Your garbage-looking JSON will look like a million bucks!

      Use LogCat to Debug for Android

      To use LogCat you need to import the Log library in the java code import android.util.Log;

      Then, where you would normally print something, replace “System.out.println(“HERE”);” with:

      Log.d(“LOGCAT”, “HERE”);

      Now when you run your app on the emulator or a device it'll print out to logcat, which can be viewed right in Eclipse (might need to go to Tools and click LogCat or something similar) or in the terminal in the directory where the android sdk has been installed, in the <sdk>/platform-tools/ folder.

      Run adb logcat from that directory location to view the logs.

      This prints out a log of everything that's happening, so if it's on the phone there's probably going to be a lot of stuff going on continuously, which is why it's helpful to use good tags so you can just browse or search for "LOGCAT" and you'll find what you're looking for.

      java.util.Date to java.sql.Date conversion error

      For a database project (building a full retail store system) I've tried passing a java.util.Date to a Java prepared statement.  The problem is that the prepared statement expects java.sql.date, and converting it isn't working for me.  Here's the errant code: ps.setDate(2, emp.getDate()); which results in this error: no suitable constructor found for Date(java.util.Date) constructor java.sql.Date.Date(long) is not applicable (actual argument java.util.Date cannot be converted to long by method invocation conversion) constructor java.sql.Date.Date(int,int,int) is not applicable (actual and formal argument lists differ in length) The fix is to create an SQL Date using the java.util.Date as follows: java.sql.Date sqlDate = new java.sql.Date(emp.getDate().getTime()); Then, the prepared statement accepts the date. ps.setDate(2, sqlDate);

      Visual Studio Keyboard Shortcuts

      Navigation Shortcuts

      • Ctrl + ] - Moves the cursor to the matching brace in the source file
      • Ctrl + Hyphen (-) - Moves cursor to its previous position
      • Ctrl + Shift + Hyphen (-) - Moves cursor to the next browsed line of code
      • Shift + F7 - Switch between the Design and Source View of the document
      • Ctrl + Tab - Displays the IDE Navigator with the current document selected. Allows you to navigate open documents. Also try Alt+W+2
      • Ctrl + Shift + F - Displays the ‘Find in Files’ tab of the ‘Find and Replace’ dialog box
      • Ctrl + I - Activates Incremental Search by searching for the next occurrence of the input text. You can even use F3
      • Shift + F12 - Displays a list of all references for the symbol selected
      • Ctrl + / - Moves focus to the Find/Command box

      Editing Shortcuts

      • Ctrl + K + C - Comment a Line or an entire selected block
      • Ctrl + K + U - Uncomment a Line or an entire selected block
      • Ctrl + L - Cuts the current line
      • Ctrl + C, Ctrl + V - Duplicate a line

      Window Shortcuts

      • Shift + Alt + Enter - Toggle Full Screen Mode
      • Ctrl + M + O - Collapses all Regions to provide a high level overview of the types and members in the source file
      • Ctrl + M + L - Toggles all previously collapsed Regions
      • / Collapses all tabs in a Toolbox
      • * Expands all tabs in a Toolbox. If * does not work, use Shift + 8 for ENU keyboards as explained here
      • Shift + Esc - Closes the current Tool Window with focus

      Code Completion Shortcuts

      • Ctrl + Period (.) - Expands the Smart Tag Menu (Usually when you rename a method or need to add a ‘using’ statement). You can also use Alt+Shift+F10
      • Tab - Inserts expanded code snippet using a shortcut (for example enter the keyword ‘class’ and hit Tab twice)
      • Ctrl + Space - Completes the current word in the completion list

      Other Shortcuts

      • Ctrl + Shift + B - Build the solution. You can even try F6
      • F5 - Start the application with Debugging
      • Ctrl + F5 - Start the application without Debugging
      • F9 - Sets or Removes a breakpoint at the current line
      • Ctrl + Shift + S - Save all unsaved files
      • Ctrl + Alt + L - Show Solution Explorer
      • Ctrl + Shift + A - Displays the Add New Item dialog box
      • Alt + Shift + A - Displays the Add Existing Item dialog box