(00:18) Kevin introduces Jackson and asks about CodeReview. Jackson talks about how he missed

(01:25) Kevin asks about some of the specific features in CodeReview.

(02:05) Jon asks what the CodeReview app adds to the mobile web experience on GitHub. One of the big features is that CodeReview allows for completely working completely disconnected.

Nerdy Implementation Details

(04:10) Kevin asks if Jackson’s working against the GitHub API’s. Jackson says he debated working using Git directly, but so far he’s been using the GitHub API. Internally the code is abstracted so in theory it could work against other source code hosts like CodePlex. There’s a brief discussion of Google Glass

(05:45) Jon asks about Jackson’s development stack. Jackson says he’s working directly in Objective-C and some C as well for the Markdown parser. There’s some discussion of the joy of writing parsers in C. Jackson talks about how some old formats like diff are so much simpler to parse than even newer formats like XML and JSON.

(08:15) Jon asks why Jackson didn’t use Mono for this application. Jackson says he’s writing Objective-C for his day job, so it’s good for him to write as much Objective-C as possible. Kevin said it seemed like working with Mono would require learning Objective-C to read the documentation. Jackson agrees, but says that learning the iOS APIs using Mono made the transition a lot easier for him.

(10:46) Jon asks about the BetterFetch feature. Jackson talks about he’d originally modeled the application more like a Twitter stream, so he’d been using the stream API. Over time, it became obvious that an e-mail client was a better application model, so he’s moved off the steam API.

Business Model and Pricing

(12:47) Jon asks about the business model and pricing. Jackson said he and JB originally thought that they’d use a freemium model, but they figured out that it really was more applicable for business users who can’t as easily do in-app purchasing. He’s switched to a flat rate to allow for group purchases and generally work better for business scenarios. Kevin says $20 is pretty steep for an app, but Jon says it says it seems completely reasonable for the right application with one of his favorite Android applications which cost $20. Jackson says it’s a perpetual license, iPad apps often sell for a little more, and since it offers a lot of value to businesses he thinks it’s worth it. They’d originally looked at $4.99, but that’s hard to make any money off. Jon says he thinks that the price sensitivity between $4.99 and $19.99 is probably a lot less than between free and 99 cents. Jackson says he wants to sell and support a quality application that’s sustainable.

Services? Nope, just more repos.

(18:03) Kevin asks if it’s all run off GitHub or if there are some hosted background services. Jackson says it’s all running off GitHub. He supports storing additional profile data in an optional GitHub repository. Since he knows you’ll have a GitHub application, he can include support for retina quality profile images (and potentially other information) stored in GitHub.

Design issues

(20:54) Kevin asks if he’s been working with a designer or doing it himself. Jackson talks about how he’s worked with a few designers and it’s really helped.

(22:50) Kevin asks if the application’s design reflects GitHub’s design. Jackson says it’s similar, but explains some important differences between the application and the website.

(24:27) Jon asks about the full screen experience. Jackson explains how it both frees up screen real estate and allows you to focus.

Code Reviews and Separating the Creative and Editorial Process

(25:24) Twitter question from Elijah Manor: "Do you use the CodeReview app to review code for the app itself?" Jackson says yes and explains how a bit inspiration for the application was Stephen King’s writing workflow: bang out a bunch of pages in the morning, edit in the evening. Separating the creation and refining steps allow for a lot more productivity. Jon’s very interested and asks Jackson for tips on how to do that. Jackson talks about setting small goals and working in a coffeeshop without bringing his power adapter, so he’s constrained on time and internet use. K. Scott says that the iPad form factor probably helps for this, and Jackson agrees – he sees it as really good for focus.

(30:41) Jon asks if there are other features he could add by gathering intelligence about my codebase and workflow. Jackson mentions some ideas like hotspots and detecting patch impact. He’s been watching GitHub’s career page hoping to see that they’ll be hiring data scientists to start providing this kind of information. Jon agrees that it’d be great for GitHub to start investing in data science. Jackson says that you could get a pretty good start on patch impact just by manually flagging a few files as important. Kevin says this would have been useful in the case of OpenSSL.

Code Reviews and Git Workflows

(34:29) Jon asks about workflow support for larger teams and team hierarchy. Jackson talks about some of the different Git workflow methodologies. He says he might eventually add support for code review tools like Gerrit, although he feels that some of these tools give code review a bad name because they force you to look for minutia as opposed to the big picture.

When Does it Ship

(37:56) Jon asks how close he is to shipping. Jackson talks about the beta and some of the challenges of running a beta. [Note: the application is now up on the app store]

Metrics, Tracking and API Profiling

(37:35) Jon asks if he’s tracking metrics or tracking. Jackson says he’s gathering crash reports and doing some very basic analytics using localytics because he doesn’t want users to be concerned. Jon says he likes applications give checkboxes to allow for extended tracking. Jackson talks about how he’s using Runscope and would like to allow users to optionally turn Runscope on. Jackson and Jon rave about Runscope; Jackson talks about how a few hours of API profiling helped him significantly improve the application performance. Jon talks about how we don’t think about server interactions, and there’s all kinds of crazy, scary things going on behind the scenes. Jackson tells a horror story about how the Mono site used to return the logo image when you tried to download, and they didn’t find it out until they looked at the server logs. Jon talks about a case where someone requesting the Herding Code RSS feed several times a second.

What’s Next?

(48:39) Jon asks what’s next for the app. Jackson talks about the difficulty in cutting off the features and shipping a version.

(49:29) Kevin asks if he’s got big vision for more than code review. Jackson says he just wants to ship it and will probably start looking at other features eventually. Kevin talks about a polititian who’s put all of his information on GitHub. Jackson says he’s worked with a lawyer in setting up the company and wished they he could work in Markdown. Jon talks about how it would be nice if Markdown had review and change tracking that were similar to Word’s. Jon says that the recent hosted Sharepoint releases are getting close. Kevin, Jackson and Jon talk about how foreign the idea of versioning and change tracking is to most professions.

Random questions

(55:35) "Who is the best canadian you know" (Wayne Gretzky)

(55:55) "What type of dog is your favorite" Labrador

(55:57) "When will you stop lying about your tweets" There’s a short discussion about deleting tweets and Jackson’s feature request for Tweet focus testing. Jackson talks about a time when Twitter asked users to stop deleting tweets for performance reaons

Epilogue

(59:20) The app is now live on the app store! You can find out about it at CodeReview.io.

This entry was posted
on Monday, June 16th, 2014 at 4:15 pmand is filed under podcast.
You can follow any responses to this entry through the RSS 2.0 feed.
You can leave a response, or trackback from your own site.

Jim

Thanks for the talk, thanks for the promo. My iPad is too old for ios 7, so I’m not taking a code, just thanks for making them available.

Iman Mahmoudi-Nasab

Thanks for preparing nice podcasts.

Daniel Williams

The discussion about specs review was right on. BUT what on earth are you talking about that there is no good solution for creating specs that have version history and collaboration? That is google docs. We use it for all of our specs and once I bought into it I never want anyone to email me a word document ever again.

In Google Docs it is easy to view history and “roll back” changes as needed. We use comment to collaborate and I get notifications on new comments and comment resolution.
Trust me- this problem has been solved and once you realize it then myriad problems go away and you can get back to creating excellent code.

Daniel, viewing history and rolling back changes are the easy problems. They’ve been handled for a long time by Google Docs, Office Online, and other services. No need to e-mail docs, good version and rollback, etc.
The bigger problems come up when you want review with comments, diffs between versions, etc. Word handles that, but doesn’t convert cleanly to HTML.