The problem with most technology conferences is that they devolve into cliques.
Game developers don’t interact with mobile developers. Mobile developers don’t interact with web developers. Web developers don’t interact with systems developers. And on and on it goes.
PolyglotConf is a one day unconference designed to get 200 of the smartest developers around in the same room. An uncoference is a participant-driven, self-organizing meeting. The people that show the day of the conference are the ones that get drive the agenda. The job of the organizers is to facilitate.
PolyglotConf Vancouver 2012
SFU Harbour Centre
555 West Hastings
Vancouver, BC
Saturday, May 26, 2012
Conference Day
8:30AM - 9:00AM : Registration
9:00AM - 9:15AM : Introduction
9:15 - 9:45AM : Final Session Selection
9:45AM - 12:30PM : Morning Sessions
12:30PM - 2:00PM : Lunch (out on the town)
2:00 - 5:15PM : Afternoon Sessions
5:15pm - 5:30PM : Closing Session
7:30 - Until You Drop : PARTY!
Tutorials
One of the sponsors for PolyglotConf is Github. Git is a distributed version control system. It makes it easy to branch and then merge projects across many members of a team that may be distributed throughout the world. Github is thee place to put your central git hub.
Github will be putting on a full day git tutorial on that Friday. You will want to attend if you have used Subversion or Perforce in the past and git kind of confuses you. It will also be a great tutorial if you haven’t used source control at all.
There are a couple other tuturials on Erlang and HTTP servers that are also scheduled.
There is a session suggestion forum. I can speak about Grand Central Dispath oniOS. However, I’d like to see someone from the game development community talk about concurrency on the Sony PS3.
In Lean Manufacturing, inventory is waste. Inventory is product that you have built but have to store because you can’t get it into the hands of customers.
There is a similar concept in Lean Development. Any code that has been written but is not in the hands of users is inventory. And inventory is waste.
Continuous Deployment is the process of getting code that is written in to the hands of users as quickly as possible. It is one layer of discipline on top of Continuous Integration.
Continuous Deployment is difficult for iPhone Apps because of the App Store approval process. It is also difficult to automatically test and code sign Apps. There are a number of tools to help with this process: KIF, Github, Jenkins, xcodebuild, and TestFlight.
Integration Tests
Square has a great integration testing framework called KIF: Keep It Functional. The source code is available on Github. There is also a great Google Group. The README file should have enough information to get KIF up and going with your Xcode project.
KIF uses the accessibility functionality of iOS to to automatically test the UI. You do make your App accessible, right? Right.
Once you have accessibility labels for your controls you can write test cases that automatically exercises the UI.
Github
You should be using git for source code revision control. And if you are using git then you should be storing your code at Github. Github has a number of web hooks that will POST to a URL when code is pushed to a repository.
This web hook can be pointed at Jenkins.
Jenkins
Jenkins (formerly Hudson) is a continuous integration server. My favourite way to install Jenkins on a Mac is to use Homebrew.
Now you need to tell Jenkins to execute a bash script for every build.
I’ve XXXX’d out some variables. You should fill those in with correct App name, Scheme, Target, etc. Also, you will want to keep your .mobileprovision file in your git repository.
The build script relies on xcodebuild and xcrun to build and sign the App.
$ man xcodebuild
$ man xcrun
TestFlight
The last piece of the puzzle is TestFlight. TestFlight is an App management dashboard. It manages a list of your Apps and your testers. It sends out emails to testers whenever a new build is available.
Testers are able to install Ad Hoc builds directly from their iPhone.
It lets you creep on your testers. You know exactly when a tester last installed a build. This allows you to yell at your testers when they have been slacking off.
The build script uploads the .IPA file up to TestFlight. TestFlight has fairly good documentation for their Upload API.
It also uploads the .dSYM symbol file. TestFlight will symbolicate crashes that are uploaded to their servers. You need to integrate the TestFlight SDK to take advantage of this functionality.
Conclusion
Continuous Deployment is key for eliminating waste in your development process. It is key if you want to keep moving fast as you scale up the size of your code base and the size of your team. It is best to implement it sooner rather than later. Frankly, you should implement Continuous Deployment before you write a line of code.
There is an excellent article in this week’s Sunday New York Times: The Default Choice, So Hard to Resist. Thinking about defaults is an important exercise in design. However, the interesting underlying story here is about distribution.
In a Senate hearing last month about Google, Jeremy Stoppelman, the chief executive of Yelp, pointed to that reality in his testimony. “If competition really were just ‘one click away,’ as Google suggests,” he said, “why have they invested so heavily to be the default choice on Web browsers and mobile phones?”
Yelp depends upon Google for distribution. The classic way that a user ends up on Yelp’s site is through a Google search. Either the user ends up at Yelp organically (SEO) or they end up their because Yelp purchased placement (SEM).
Distribution Arbitrage
The second key point to note is that Google themselves purchase distribution from AOL, Mozilla, and others.
Today, Google pays an estimated $100 million a year to Mozilla, coming from shared ad revenue, to be the default search engine on Mozilla’s popular Firefox Web browser in the United States and other countries. Google has many such arrangements with Web sites.
Google purchases distribution for a dollar and then sells this distribution for more than a dollar. That is essentially Google’s business model.
Channel Conflict
Google attempted to purchase Yelp and failed. The two parties could not come to an agreement and as a result Google has “gone gangster” on Yelp. Yelp’s review pages were pushed further down the search results page. Google started creating their own Google Places pages. Then Google went and bought Zagat.
Google has gone increasingly vertical the last few years. They have released the Chrome web browser in an effort to be less reliant on their search deals with Mozilla and Safari.
But that is only the top part of Google’s sales funnel. In the past, Google pushed everyone through their sales pipe and generated revenue whenever someone clicked an ad. Google is no longer happy being just in this business.
They have chosen to find other sources of revenue. This puts Google in direct conflict with partners like Yelp.
Get Distribution or Die Tryin’
Good products that can’t get in front of users will end up dying. It is important for a business to have multiple sources of customers. Yelp is beholden to Google for customers and Google has decided that they themselves want to keep these customers. Yelp needs to diversify its distribution.
Enter: Siri.
Beating Search
The way to beat a product is not to compete with the product. (I’m looking at you Bing.) The way to beat a product is through disruptive innovation.
For sustaining innovations, incumbents nearly always win.
For disruptive innovations, new entrants nearly always win.
If you ask Siri to make a restaurant reservation for you, it looks this request up using Yelp. This is the type of task that users currently do a Google search for.
AI Distribution
I’ve been digging through the private frameworks that come with iOS 5.0. Unfortunately, I haven’t found an API yet to hook into Siri. But I’m going to guess that there eventually will be an API.
I’ve been quiet for the last little while, but I can finally announce that I am joining App Social as Director of Development.
Our main product, currently in private BETA, is Tingle. Tingle is a mobile dating application that helps users find local singles. We are heads down building an awesome product supported by a fantastic team of developers, management, and investors.
As Director of Development, I am heading up mobile App development, building and managing a team, and guiding the product. As Director of Technology, Patrick Chin is building our platform features and scalability. As CEO, Ian Andrew Bell is building a great team of investors, managing marketing and spearheading business development.
Please do me a favour. Sign up to be notified when Tingle is released. We will be releasing very, very soon.
We are also looking for developers. Email me (PK AT APPSOCIAL DOT CA) if you have iPhone, Android, Blackberry development experience or if you have development or developer ops experience. (Our backend is written in Rails.)
It’s once again time for DemoCamp. DemoCamp 11 was a huge success and we are hoping to build on that momentum. We had almost 20 presenters put together a 30 second pitch. The final 6 minute presentations were quite good, too.
And we are listening. The previous venue was great for mingling and networking. The one issue that we have been consistently hearing is that it can be difficult to see the presenter’s screen and hear the presentation. So, we’ve found a new venue that has a better layout and equipment for the presentations while the crowd can still mingle and network.
Here are the details:
DemoCamp Vancouver 12
The Lounge at The Caprice
Wednesday, November 3
5:30 PM
The event starts at 5:30pm with 30 second pitches starting at about 6:00pm.
We want to be TJ Watson Jr’s IBM. … We are not going in the hardware business. We have no interest in the hardware business. We have a deep interest in the systems business.
– Larry Ellison
This is why Oracle purchased Sun Microsystems.
httpv://www.youtube.com/watch?v=rmrxN3GWHpM
(Forward to the 26:50 mark)
And today it looks like Oracle will take a run at ARM.
Oracle gets it.
Facebook
There have been rumours this week that Facebook may be building a phone. Mark Zuckerberg did an interview with TechCrunch this week.
There’s the Apple approach of really designing all the hardware – I don’t think that they manufacture it themselves, but they probably work very closely with Foxconn – but they do have chip design and all of that in-house, I’ll bet we’ll never do anything like that. That is different from what we do.
…
I mean, who knows, 10 years down the road, maybe we’ll build our own operating system or something, but who knows. That is more history than we’ve had so far with the company, so it is really hard to predict that far out. But for now, I think, everything is going to be shades of integration, rather than starting from the ground up and building a whole system.
– Mark Zuckerberg
I don’t know if Facebook gets it. Let’s see what happens when both Google and Apple get more social.
First there was the iPhone and iPod Touch. Then the iPad. Then iOS 3.0. Then 3.2 but iPad only. Then 4.0 but some of the features aren’t available on older models. Then there is the 4x3 versus 3x2 aspect ratio to worry about. And then 480x320 versus 1024x768 versus 960x640. The Media Player framework changes at every single point release.
All of this fragmentation means that iOS Apps crash. CrashKit catches uncaught exceptions, traps signals, and sends them to developers by email or straight to your bug database.
Foursquare
Foursquare dumps a stack trace whenever it crashes. It then asks the user to email the crash report to the developers the next time they launch the App.
The problem is that the user may not ever launch your App ever again.
We can do better than this.
What CrashKit Does
CrashKit catches uncaught NSExceptions.
NSSetUncaughtExceptionHandler(&uncaughtExceptionHandler);
It also traps signals that the operating system sends when the App touches memory that doesn’t belong to it or executes illegal operations.
The signal handlers unwind the stack frame and try to find out exactly where the crash happened. This bug report can then be emailed or sent to FogBugz.
FogBugz
FogBugz exposes a BugzScout API that accepts bug reports using HTTP GET/POST methods. It buckets similar bugs together and appends them to existing bug reports.
Pump That Run Loop
There are a number of subtle issues with catching and reporting crashes. In general, UIKit is not re-entrant. Also, UIKit methods should only be called on the main thread. Exceptions and signals are usually trapped on a thread that is not the main thread. And the main thread usually gets evicted once something catastrophic happens to the App.
CrashKit jumps back to the main thread after catching a crash and grabbing the stack frame. It then pumps the main run loop until an email message can be sent or a HTTP method can be completed.
12345678910111213141516
-(void)pumpRunLoop{self.finishPump=NO;CFRunLoopRefrunLoop=CFRunLoopGetCurrent();CFArrayRefrunLoopModesRef=CFRunLoopCopyAllModes(runLoop);NSArray*runLoopModes=(NSArray*)runLoopModesRef;while(self.finishPump==NO){for(NSString*modeinrunLoopModes){CFStringRefmodeRef=(CFStringRef)mode;CFRunLoopRunInMode(modeRef,1.0f/120.0f,false);// Pump the loop at 120 FPS}}CFRelease(runLoopModesRef);}
LLVM and LLDB
LLVM and LLDB are the future. I’ve only tested CrashKit with LLVM. There are some LLDB features I would like to add in the future. CrashKit probably works with GCC but I haven’t really tested it.
GitHub
The best way to download CrashKit is to check out the GitHub page. Go put a fork in it. Crash reporting is hard so patches welcome.
I install and try a lot of iPhone Apps. That means I have to Sign In or create a new account for a new service quite often. I create a unique password for each web service for extra security.
I’ve also implemented Sign Up screens many times. Here are a few things to considering when designing an iPhone Sign Up screen.
The Best Sign Up is no Sign Up
Does your services really need a Sign Up screen? A perfectly reasonable strategy is to identify a user by the device identifier and then allow the user to create a full account later. Two examples are Instapaper and Posterous.
[UIDevice currentDevice].uniqueIdentifier
Both Instapaper and Posterous use your email address on the web to automatically create an account. On the iPhone, Instapaper uses the device identifier.
Sign In and Sign Up
Leah Culver has a great post on why Sign In and Sign Up should be the same. Typing on the iPhone and managing passwords is more difficult than on a desktop machine. It is important to minimize the amount of user error by design.
How the UI flow will be designed has be specific to how your service works. One way to do this one screen is to use a Segmented Control and toggle between a Sign In and Sign Up state.
Embed a Table View
The best way to create a form in an iPhone App is to use a Table View. Here is a screenshot of the Skype iPhone App. It uses a table view to display the Skype Name and Password fields.
The key insight to the design of this page is that a table view does not have to take up the entire view. This is how you can setup your view controller to handle this:
Instead of inheriting your view controller from UITableViewController, inherit from a regular UIViewController and then implement the UITableViewDelegate and UITableViewDataSource protocols.
Embed a Text Field into a Table Cell
The next task is to embed a text field into a table view cell. Most designs embed a descriptive label and a text field. This is not required. A text field has both a text and placeholder property. The placeholder property can be used to describe the field. This is especially important for the password field. I tend to use very long passwords that tend to trail off the edge of a text field.
I am helping host the next DemoCamp Vancouver. DemoCamp is an opportunity for designers, developers, and marketers to get together and show off the projects that they have been working on. It is an unconference style event that allows people to gather and meet in an informal manner.
<code>DemoCamp Vancouver 11
Thursday, July 22nd 2010
5:30 PM
Ceili's Irish Pub & Restaurant
670 Smithe Street
Vancouver, BC
</code>
This is a great opportunity to meet other people in the technology industry in Vancouver. What are the benefits for presenting?
PR
This is a great place to build some buzz around your project. TechVibes and a number of bloggers are always hanging out looking for new, interesting stories to write.
Cofounders
Mingle with likeminded entrepreneurs. Maybe you are a technical person that is looking for the business person to help you build the demo into a business. Maybe you are a business person and your demo is held together with duct tape and chicken wire and your looking for that technical person to take the idea to the next level.
Friendly First Contact
Find that group of friendly first contacts to test out your demo. Good BETA testers are hard to find. This is a great event to find those people that will try your service.
