Tag Archives: development

Learning iPhone Development

Every time I’ve started to work on a new project I’ve been fortunate enough to have the opportunity to learn a whole new set of technical skills. At Frogmetrics it was Python, Pygame, Maemo Linux, and the world of early stage mobile performance constraints. In the early days of JumpPost and Hyperpublic it was web development – Ruby, Rails, Javascript, server administration. As Hyperpublic’s data platform grew and we moved on to join Groupon it was higher performance/scale data processing tools like Storm, the Java ecosystem, and a variety of databases and data processing techniques. And this time around, as we’ve been getting started on Wildcard, I’ve picked up iOS development, in order to tackle the problem of creating the fastest way to interact with the internet on your phone.

So far it’s been good times. Apple has created a great platform that makes it possible for developers to create beautiful, fast, polished applications that live up to the promise and expectations created by all of the great apps you interact with every day. However, getting up to speed, getting comfortable, and getting confident with iOS development has definitely been a different process and different challenge than getting up to speed on some of the other mobile, data, and web challenges that I’ve tackled in the past – in particular, the process has been more isolating than usual.

Why is learning iOS development more isolating than web, api, or data processing based development? Because it is just as much an art as it is a science, and as many artists will attest – the creativity must come from within.

When you’re trying to learn science you can surround yourself by the reference material of a previous generation of scientists – in this case books, stack overflow posts, IRC channels, github repositories. The actions that you’re trying to take when you build a web application are largely mechanical. You read in a request, interpret it, load data from a database, and plug it into your response. The interesting code you write is your business logic, and you let the framework handle the rest. You can always piece this together via all the available reference material, and if you’re confused as to whether you’re doing it “the right way”, you can always fall back to your basic knowledge of the internet and databases (HTML, CSS, SQL). Failing to understand all of Rails doesn’t mean that you’ll fail to produce a web application that does what you need it to.

But when you’re trying to learn an art form, equal parts design, user experience, and engineering – and the bar for an impressive user experience is set really high – there’s nothing to fall back on. Implementing the business logic is still a requirement that should be fairly straightforward, but creating beautiful UI, custom controls and actions, transitions, and animations are not something you can follow directly from a blog post or stack overflow thread. Programmatically creating and keeping the UI up to date based on a series of gestures, user actions, and external notifications within the rules and frameworks that Apple has made available is not something you got experience with doing anything else. There are a series of great meetups, events, and a bulk of material available online and in print to try and teach you the basics, but when it comes down to implementing the experience that you want for your users, the reference material won’t help. You and your team are on your own.

That’s why I believe that a more effective way to learn iOS development is the mentor-mentee relationship. The ideal pairing is a developer with good fundamentals and a confidence that they’ll be able to pick up the basics of any technology, working closely with someone who’s gone through the trials and tribulations of learning the nitty gritty details, design patterns, various techniques for impacting the “art form” of iPhone development. I think pair programming is always a good idea when reasonable, however in an early stage startup it’s not always possible due to limited resources and developers needing to split responsibilities across skill-sets. However in the case of iOS development, I believe that as much pair development as feasible in the early days is the most efficient way to learn.

Now that I’ve gone through the struggles of getting myself up to speed over the past few months, I’d love to bring on an aspiring entrepreneurial engineer to work closely with me to own mobile product development at Wildcard. If you believe in our vision, and you see yourself as someone who wants to learn mobile development, and one day start your own tech company, then I believe this is a great place to learn. Please get in touch.

HipChat

As we’ve been getting started with development at our new company I have taken the opportunity to re-evaluate developer tools and workflow. At Hyperpublic I had the chance to try a lot of the tools that emerged as part of “make everything a cloud service” trend that was sweeping the late 2008-2010 era. I have stuck with many of the old stalwarts – Github (source code hosting), Pivotal Tracker (feature and bug tracking), Dropbox (files haring) – however one welcome new addition to the workflow is HipChat.

HipChat is a private group chat client developed by Atlassian, the company who brought us Jira (ticket tracking) and Confluence (information collaboration). It runs natively as an Adobe Air application, and there’s a browser based UI for search and history should you need to access a piece of information on the go. It supports multiple rooms for group chat, one on one private chat, file and link sharing, and has a useful API for integrating with other services in the workflow.

A nice benefit of integrating our other services with HipChat is the activity stream that is produced which helps everybody observe progress. When code is pushed to Github, a new pull request is issued, new comments are left, new stories are created, Chef finishes running, integration tests fail….everybody is kept up to date on progress in a way that isn’t obtrusive and doesn’t clog the inbox. I’ve noticed an increase in engagement with code reviews and an increased commitment to our intended workflow – both huge benefits. If you’re looking for a team alternative to Campfire, IRC, or even iChat I’d recommend checking out HipChat.

* Hat tip to our team member Jamie for bringing HipChat to the team.

iOS 7 Background Updates

When Apple releases iOS 7 this fall there will be a few features that capture users attention immediately: the newly designed flat UI, AirDrop, Siri improvements, and an updated Camera + Photos interface.  While all of these are welcome improvements, the features that I’m most excited about are the background update capabilities.

Background updates will allow applications to update their content when the app is not running. This means that when the user opens Mailbox his new email will be waiting for him, and he won’t have to wait for it to load. When he opens Twitter he won’t have to pull to refresh and he’ll automatically be taken to the most recent tweets. And when a friend shares a Youtube video with him it can automatically download in the background so it can begin playing immediately upon the user clicking the notification.

This may not sound like a major feature, but it has the potential to improve user experience across nearly every single application on the phone. Weather, stocks, sports scores, driving directions, media, and more can all be kept up to date and made accessible immediately whether online or offline. In a world where data and services live in the cloud, and people interact across multiple devices, background updates will allow the phone to always contain the freshest content personalized for the user.

From a product development perspective, I strongly urge developers to wow their users via creative uses of background push. Apple gives developers the option to check at certain intervals for updates if they expect updates frequently (though they’ve built intelligence to optimize for battery life, usage patterns, and connectivity), or the option to push updates to users only when they become available, in the case of less frequent updates or in response to events. From this point forward, if an app icon is badged, I’m going to expect to see some new content the second I click to launch. Away with the expectation of web latency and onto the era of responsiveness becoming the norm.

Hyperpublic Developer Challenge Stats and Recap

Last Thursday over at Hyperpublic we launched The Hyperpublic Developer Challenge. It consisted of two programming problems, one of easy/medium difficulty, and one which was slightly harder. We built it for fun, because we’re developers, and we love when there’s a fun problem around to work on if we get bored or need a distraction. The response to the challenge was phenomenal. We had thousands of developers from around the world working on the problems, and hundreds submit correct solutions. Here’s a summary of the response, the problems, the winners, and some observations.

The Response

Screen_shot_2011-03-01_at_9

To our amazement, 5,759 people landed on our challenge start page. From there 2/3rds of them, or 3,856, were feeling brave enough to at least look at the first problem. I’m sure it didn’t hurt that we were giving away free Dropbox and Github accounts, so even the non-programmers who landed on the page at least wanted to take a look at the first problem. The response peaked out with 400+ people viewing/working on the challenge concurrently.

The first problem, summarized below, proved to be a strong filter. Only 446 people, or 11.57% of people who looked at the problem, submitted a correct response. 4,860 incorrect answers were submitted, meaning that the successful submission rate was under 10%.

Problem 2, the more challenging problem, received 231 correct submissions. This means that of the 446 people who made it through question 1, only 51.79% of people made it through problem 2. There were 753 incorrect submission attempts.

All in all, 4.01% of people who viewed the challenge made it through to completing both problems.
Screen_shot_2011-03-01_at_9

The Problems
Problem 1 asked developers to calculate the influence of fictitious users in Hyperpublic based upon the influence of the users which they have added to the system. The data was given as a text file, but it could easily be converted into a 2-D array representing which users added which other users to the system.

The most common approach was to use the input as a matrix representation of a directed graph. For each user in the input, traverse the graph recursively to sum up the number of users that the initial user was responsible for. Then find the three users with the highest scores, and use them to compute your answer to problem 1.

While we won’t be posting code examples here because we’ll leave the contest up for others to try, there are various solutions available around the internet and github, which can be found quite easily be googling/searching github.

Problem 2 assigned point values to various tasks around Hyperpublic and gave 4 users point totals. It asked the developer to compute the minimum number of tasks required in order to reach their exact point totals. This proved a bit trickier, in that many people’s first instinct was the use a greedy algorithm in which they always executed the task with the largest point total before moving on to tasks with smaller point totals. This would lead to an incorrect submission and developers to rethink their solutions.

The best way to write this program for inputs and point values of any size is using dynamic programming. This is analogous to the optimal solution coin changing problem which asks what the optimal way to make change for a given amount of money is using coins of various values. It uses a technique called memoization, where you compute the optimal ways to make change for values 1, 2, 3…up to your highest amount, and you use the previously computed values to compute the next unknown values in k attempts, where k is the number of distinct values of coins.

The other way common way in which people solved this problem efficiently was by solving 4 different linear equations. There were some one line solutions using Mathematica and Matlab linear solvers. 

Fortunately, the problem size was limited enough in that a brute force solution would run quite quickly if people really got stuck as well.

The Winners
From the 231 correct submissions, we randomly selected winners of the following prizes:

Github “Medium” account free for one year – Norbert Fekete. Norbert hails from Mosonmagyarovar, Hungary, and submitted his solutions in C++. He’s new to github, so follow him over there and suggest some repos for him to fork.

Dropbox “Pro 100” account free for one year  – Brian Barthel. Brian is from Memphis, Tennessee, submitted a C# solution, and runs an independent software company called Zoasoft. 

Free desk for a month for two hackers to work on their own project at Hyperpublic HQ – Martin Czygan. Martin is from Leipzig, Germany, submitted a python solution, and since he can’t take advantage of a free desk in NYC anytime soon he has graciously donated the prize to an NYC based hacker who can use it. You can find him on github and twitter.

Other Observations
The most common language that we saw in submissions was Python. We haven’t run exact numbers, but eyeballing it, Ruby, PHP, Java, and C++ were the next most common. There were submissions in a wide range of languages though including Groovy, Scala, Clojure, L, Ocaml, C, Javascript, Haskell, Matlab, Mathematica, and others. Haskell in particular was popular among people who self identified as students or researchers.

Many people who submitted commented that the problems were too easy, and they would have preferred a harder challenge. We think that judging by the number of people who made it through, the number of people who emailed for help, and the number of people who submitted incorrectly, that the difficulty was about right. The majority of responses were very positive in that they said “this was a fun way to kill an hour or two.” We wanted the problems to take only an hour or two, and as such I think we got the difficulty right. People got to brush up on their dynamic programming or linear solving, they got to construct a graph, or they got to get their hands dirty with a new language. We think people had fun.

The last thought, is that we did this for fun, and we’re glad people enjoyed it. We also wanted to meet more developers and make them aware of Hyperpublic. We’re working on structuring data around every “local object” in the world, which is a big technical problem. If you’re interested in working on this with us, or hearing more about it. Don’t hesitate to contact me.

Looking forward to the next programming challenge.

 

Thank You Heroku, or “How To Eliminate Sysadminning”

Picture_3

I need to take a couple minutes here to do something I've been meaning to for along time: Thank Heroku for being so baller.

For those of you not in the know, Heroku is an all-in-one Ruby platform built on top of Amazon web services. If you're a Ruby developer, and you are creating a web application, I highly recommend checking it out.

I've been using Heroku on two applications, including JumpPost, which officially launched today via a nice writeup on the Thrillist NYC site and newsletter. I'd like to share a couple reasons why I love the Heroku platform and would advise any agile startup to consider using it to get their product launched quickly.

Heroku is fast
The same could be said for any well configured EC2 instance, but don't underestimate the words well configured. The smart folks at Heroku have fine tuned every layer of the stack from using the fastest web servers (nginx), caches (Varnish, Memcache), and load balancing strategies.

Heroku is scalable
At the core of Heroku's architecture is a pre-compiled version of your application called a "slug" which is ready to be deployed in seconds to as many instances as you desire. Expecting a big press hit, or noticing your request queue filling up, just type a simple command and add more resources in seconds. Your users won't even know.

Heroku is easy
To deploy you literally type one command at the command line. They provide add-ons for caching, email, DNS, performance monitoring, custom domains, etc…many of them free. 

Heroku provides killer support
Not only does the staff respond to tickets and support requests within minutes, but they go overboard to support the latest and greatest Ruby features. They're very active on the newsgroup, and they even provide sample code for how to best utilize their architecture. 

Heroku is cost-effective
People may argue me on this one, because at face value the cost is actually rather expensive (think 2x the regular price of AWS). But these people aren't taking into account the cost of their own time when it comes to sysadminning, troubleshooting, not the mention the cost of downtime. Heroku never goes down, and it eliminates the need to pay a sysadmin (or the time value of sysadminning yourself).

Heroku is beautiful
Don't believe me? Check out their pricing page (yes they know their demographic are samurai loving programmers). Navigating their site to manage add-ons, monitor performance, and scale up and down resources is a pleasure.

With all of the above, there are a couple downsides that people should be aware of. Proper SSL is expensive, and should your app face custom scaling needs or challenges then you are locked into their stack. Fortunately their stack is designed for large scale use. The Heroku folks are well aware of these concerns, and they're very open about what they're doing to improve the experience for all of their customers. For startups getting their product off the ground, the time savings early on far outweigh the cost of figuring out a custom solution later should your product achieve grand scale. In case you couldn't tell, I'm a big fan.

If you have any questions about the platform, don't hesitate to email me at petkanics@gmail.com.