Posted on

Herding Code 192: Jackson Harper on the CodeReview iOS app

The guys talk to Jackson Harper about CodeReview, his iPad application for reviewing GitHub pull requests. As Jackson describes the episode on Twitter: "…hear me talk about: @johnsheehan, @codereviewapp, and my one weird trick for writing better code."

Download / Listen: Herding Code 192: Jackson Harper on the CodeReview iOS app

Show Notes:

  • Hello. What is CodeReview?
    • (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.
    • (1:00:32) Jon asks for some promo codes, Jackson gives away ten free promo codes (below)!

Show Links:

Promo Codes for show listeners (please just take one, leave a comment when they’re all gone):

Posted on

Herding Code 191: Derick Bailey on SignalLeaf and Getting Started Podcasting

The guys (joined by guest host Rob Conery) talk to Derick Bailey about his new podcast audio hosting venture, SignalLeaf.

Download / Listen: Herding Code 191: Derick Bailey on SignalLeaf and Getting Started Podcasting

Show Notes:

  • What is SignalLeaf?
    • (00:18) Kevin introduces the show and warns listeners that Rob Conery is present.
    • (01:00) Kevin asks Derick what SignalLeaf is. Derick explains that SignalLeaf is a podcast audio hosting service. He explains how his service compares to big players like Libsyn.
    • (02:05) There’s a discussion of Libsyn. Jon confesses that Herding Code still runs off WordPress on an "unlimited hosting" account.
  • Bandwidth costs
    • (02:52) Jon asks Derick if the main cost is bandwidth. Derick explains that SignalLeaf runs on Heroku, but all the storage goes directly to Amazon S3 storage. He agrees that bandwidth is the main cost, and is planning to just make sure the overall subscribers balance out some of the more expensive bandwidth costs.
    • (04:52) Jon asks Derick what else he provides outside of audio hosting. Derick says he provides audio hosting, an RSS feed and stats, but he limits it at that. He also provides a blog with a lot of good information. The goal isn’t a big all-in-one service, just keeping it simple for people who want to get started.
    • (06:31) Rob gives the example of the rapid takeoff of This Developer’s Life and asks how Derick’s planning to handle pricing for unpredictable bandwidth. Derick says the model’s focused on unlimited uploads, but limited in how many releases a podcaster makes in a month. He’s relying on the law of average to pay for the popular podcasts.
    • (09:18) Rob talks about the huge streaming bills he was getting from Amazon for TekPub, which he almost eliminated by switching to Vimeo. He asks Derick if he’s looked into services like that. Derick says the backend is abstracted so he can move to other services if needed.
  • What does SignalLeaf run on? (Part 1)
    • (11:10) Jon asks about what SignalLeaf runs on. Derick mentions MongoDb (running on MongoLab), Keen.io  for analytics and CloudAMQP.com for RabbitMQ.
  • What services does SignalLeaf provide?
    • (13:25) Kevin asks more about the services SignalLeaf offers. Derick mentions storage, bandwidth, storage and analytics. Something he offers beyond what many other similar services provide is – if you use his RSS feed and embedable audio player – he can tell you where your listeners are coming from.
    • (14:50) Derick mentions his blog post showing that about 50% of listeners don’t listen via RSS. Jon said he’s seen the same thing with the Herding Code site.
  • Stats and advertising services
    • (17:25) Jon says advertisers are always asking for stats, and the kind of stats that advertisers want are hard to find. Derick mentions a service (blubrry) that inserts audio ads, but doesn’t think that sounds like a good idea. He mentions a business podcast running on a free service which had some off-color ads included as an example.
  • Getting started in podcasting: What equipment and software do you need?
    • (20:40) Rob asks how a developer should get started with creating a podcast. Derick says just hit record and get started. Don’t buy equipment, just record something and upload it and get started. He talks about professional podcasters who put artificial barriers up by focusing on radio quality recording; he disagrees.
    • (23:56) Jon mentions Derick’s recent post on getting started. He agrees with Derick and says don’t start by buying equipment, get started and buy equipment as you need it.
    • (26:11) Jon says he doesn’t use his high end condenser microphone because it picks up lots of noise and sounds strange compared to guests and other hosts. Rob asks Derick what people getting started should buy to start with. Derick recommends starting with a $26 Logitech headset, then looking at a $50 Audio Technica ATR 2100, a $90 Blue Yeti, $220 Rode podcaster mic etc.
    • (30:15) Rob asks about recording software. Derick mentions Garageband, Skype Call Recorder and Audacity. Jon uses a free Skype call recorder from scribie.com, Audacity and Reaper.fm. Jon and Derick both love the noise removal feature in Audacity.
    • (33:26) Jon says another thing to figure out at the beginning is how much you want to edit. Jon tries to focus on removing ums and repeated words and things, but leave it sounding natural. Both Jon and Derick say that Rob’s the easiest guest to edit.
    • (35:40) Jon asks K. Scott what he uses for recording. He uses Audacity and Camtasia. Jon tells a story about how how he spliced in audio from a previous call when one of the hosts couldn’t make a show. It didn’t make sense, but no one seemed to notice.
    • (36:50) K. Scott asks what kind of formats don’t work on a podcast. Derick says that visual features and visual cues obviously don’t translate.
  • What does SignalLeaf run on? (Part 2)
    • (38:21) Rob asks everyone to guess about the technology Derick’s running on. Turns out it’s all Node.js. Derick talks about how he got started with Node.js. Jon asks about what other libraries he’s using. Derick mentions Express, S3 restful API’s for upload and host, raygun.io for exceptions, keen.io for analytics, stripe.com for billing, MongoDb for data, Mandrill App for SMTP. Derick talks about how little it takes to build up a service now – he’s able to stitch a lot of services together to build what he needs. (45:30) K. Scott asks what text editor he uses. Derick’s a big VIM fan, having started with a Visual Studio VIM extension a while ago.
    • (47:20) Kevin asks about JavaScript libraries and testing. Derick talks up Backbone, Q and RSVP for promises, Underscore for utilities, and moment.js for date / time math.
    • (50:07) K. Scott asks whether Derick uses Grunt or Gulp. Derick says he’s thought about looking at Gulp, but Grunt works for him, although he doesn’t like .
  • Discussion about managing small, application specific Node modules
    • (50:55) Derick says he doesn’t like the way NPM wants you to have a separate git repository for each module – he wants to have all of his modules in one repo. He works around that by using different repositories for development and deployment. Kevin says that his company uses softlinks to work around that, but Derick’s not happy with that. Rob thinks you can do file references, but Derick and Kevin disagrees. Jon asks if submodules would work. Rob and Derick discuss cases where it does and doesn’t make sense to use different repos for different small modules which are specific to a project. Rob talks about using grunt to run an npm install command, or npm init or start scripts (set in package.json), or npm init.
  • Fin
    • (1:01:55) Kevin asks Derick if there’s anything else he wants to mention. Derick starts to mention WatchMeCode.com but the calls keep dropping and the show spontaneously combusts.

Show Links:

Posted on

Herding Code 190: Rob Ashton on NodeJS vs C#, Clojure and Cooking Constraints

In our final interview from NDC London, Jon and K. Scott talk to Rob Ashton his cage match with Jeremy Miller on NodeJS vs. C#, some functional languages he’s been learning, and cooking just enough curry.

Download / Listen: Herding Code 190: Rob Ashton on NodeJS vs C#, Clojure and Cooking Constraints

Show Notes:

  • The NDC Cage Match: Testing! NodeJS vs. C#
    • (00:18) K Scott asks Rob about the cage match he just had with Jeremy Miller comparing testing in NodeJS and C#. Rob’s got a lot of good things to say about what Jeremy showed, but is pretty sure he won.
    • (02:40) K Scott asks Rob to explain why he doesn’t like monkey patching. Rob mentions how QuickCheck helps, then talks about how code structure obviates the need for monkey patching.
    • (05:16) Jon asks how he bootstraps his application to inject dependencies and explains how he avoids deep dependency chains.
  • Clojure?
    • (06:40) K Scott asks what led him to Clojure.
    • (07:39) Jon asks Rob what he likes about Clojure. Rob says a better question is what he likes about functional programming languagues, then explains.
    • (09:25) K Scott asks about some of the learning project Rob’s been working with to learn Clojure. Rob talks about some of the games he started with, then the RavenDb reimplementation he’s been building with Clojure called Craven.
  • What do you do in your free time?
    • (12:56) K Scott asks Rob what he does in his free time. Rob starts by talking about Clojure, then talks about some of the complicated cooking things he’s been working on. He talks about some of the similarities between cooking and coding, and some of the constraint he deals with in ambitions cooking projects.
  • The future
    • (14:58) K Scott asks Rob about some of his plans for early 2014.  Erlang away!

Show Links:

Posted on

Herding Code 189: Gary Bernhardt on The Birth and Death of JavaScript

At NDC London, Jon and K Scott talk to Gary Bernhardt about his talk, The Birth and Death of JavaScript.

Download / Listen: Herding Code 189: Gary Bernhardt on The Birth and Death of JavaScript

Show Notes:

  • (00:15) The talk occurs in the year 2035. JavaScript is now pronounced differently, and there has been another world war.
  • (01:20) Jon ran over to the talk when he heard (via Twitter) that Gary was (or will be, it’s all so confusing) mentioning Singularity.
  • (02:20) Jon asks about Gary’s references to the performance improvements gained by turning off hardware protection. Gary and Jon discuss how Singularity and the (yet to be developed) Asm language offer high performance due to this approach.
  • (04:10) Jon asks why JavaScript has died, since Asm is universal. Gary mentions some of the problems – many historical – with JavaScript. And Gary should know, he’s famous for the "wat" talk showing several JavaScript insanities.
  • (05:37) Jon asks for some reasons why JavaScript had to die. Gary explains how it’s really just running on inertia now, and that it’d be preferable to use a better designed language like Clojure.
  • (06:30) Jon asks what we’re writing our code in, now that it’s compiling to Asm. Gary doesn’t specify that – it’s not really necessary to pick one, and he doesn’t need to alienate anyone unnecessarily.
  • (07:45) Jon asks if Asm is a binary format. Gary clarifies that it’s the JavaScript subset that was proposed in 2012.
  • (08:54) Jon asks if Asm is perfect, or just good enough. Gary talks about how both Asm and the HTML DOM (which also has become universal in 2035) are full of flaws, but they’re better than fragmentation. Jon and Gary talk abouthow
  • (10:45) K Scott says this all sounds plausible, all that’s needed is time. So, why 2035? Gary talks about his reasoning… it could happen faster. He talks about some core services moving into operating system kernels, and Jon and K Scott agree.
  • (12:55) Jon applauds Gary’s 25-30 minute talk length.
  • (13:15) Jon mentions some of the interesting audience questions at the end of the talk. Gary talks about some of the most interesting. All of them were pretty easy except for the question of parallel execution.
  • (15:20) There’s a discussion about the limitations of x86 architecture and parallelism.
  • (16:10) Jon asks about some of the other things Gary’s up to – there are the Destroy All Software screencasts and a consumer product Gary’s working on but isn’t ready to announce yet.
  • (16:40) K Scott asks Gary about relaxation and recreation. Gary says that he’d become really preoccupied with things that were bad in software, and it was stressing him out. He’s made three changes: intentional social interactions, crossfit and playing guitar. All three have helped him be less angry about the state of software… which is all hacks on x86, when we get down to it.

Show Links:

Posted on

Herding Code 188: Pete Smith on Superscribe

At NDC London, Jon talks to Pete Smith about Superscribe, a library which brings graph based routing to ASP.NET, Web API and OWIN.

Download / Listen: Herding Code 188: Pete Smith on Superscribe

Note: There’s a little bit of background noise due to the conference recording.

Show Notes:

  • Intro to Superscribe
    • (00:20) Jon asks Pete to explain what Superscribe’s graph-based routing means. Pete explains how traditional routing needs to check each route for a match, one at a time. Graph-based routing stores using a structure, so there are some performance gains due to only matching routes with a matching structure rather than using string matching.
    • (02:17) Pete explains that graph based routing is language agnostic, so there’s also a JavaScript implementation.
  • Extensibility due to strongly typed route nodes
    • (02:37) Each node in the graph is a strongly typed entity, so you can use an activation function for each node in the graph to determine if it’s a match rather than just using a simple regex match. You can write custom activation functions for any node. For parameter matching, Superscribe uses TryParse rather than regex matches.
    • (04:22) There are three guiding principles behind Superscribe: composability, efficiency and extensibility.
  • The OWIN connection
    • (05:22) Jon asks where Superscribe can be used. Pete says it’s currently usable in Web API and OWIN, with NancyFx and possibly MVC on the way.
    • (06:02) In addition to activation functions, you can also define an action function which says what should happen when a node is matched. This allows running different OWIN middleware based on route matches. This means you can hook up authentication middleware using an action function which will only operate on a specific node.
  • Graphs vs. Trees
    • (08:16) You can hook up optional nodes, which would allow things like an optional /debug/ route prefix which would hook up tracing middleware. Pete says this is something that wouldn’t be possible with tree-based routing (available in NancyFx).
    • (09:00) Jon asks what the difference is between tree-based routing and graph-based routing. Both are connected nodes, and trees are a type of graph in which the node connections branch out and ever reconnect, whereas in a graph any node may connect to any other node.
  • API options: Different ways to define route graphs
    • (09:53) Jon asks how developers will define nodes in Superscribe. Pete talks about the difference between economy and expressivity: economic design has fewer options but is easy to learn, while expressive design offers many options but a steeper learning curve. Superscribe is currently more expressive, using a domain specific language using operator overloads. It overloads the / symbol to add segments and the | operator to allow defining multiple routes (or the entire graph) in a single line.
    • (12:28) Jon says that you can always add an economic API layer over an expressive one. Pete agrees and says that since everything’s strongly typed underneath, you can configure it explicitly or fluently  as well (if you don’t like the DSL).
    • (13:14) Jon asks about how to hook in action functions or activator functions. Pete says they’re currently not available in the DSL, so you’d need to build those notes out by hand at this point.
  • Miscellaneous questions and pretend ending
    • (15:08) Jon asks about using routes for localization. Pete talks about some options for doing that.
    • (16:28) Jon asks what’s next on the list. Pete lists some features: syntax improvements and OWIN middleware ideas.
    • (19:12) Jon asks how people can learn more and keep up, Pete talks about Superscribe.org.
    • (20:12) Jon asks about the use case for Superscript in JavaScript. Pete talks about how activation functions are really useful in single page applications and how he’s using this in a production application. He’s working on packaging this up as Superscribe.js.
  • Update on the 0.4 release (follow-up phone call)
    • (22:11) Jon asks what’s new in the 0.4 release. Pete starts by describing some improvements to the routing syntax.
    • (23:02) You can now combine Web API replacement routing, traditional routing, Attribute Routing and Superscribe in the same application, so you can pick and choose.
    • (23:24) You can wire it up with an IOC container, so you can compose different components based on routes. You can also use route information in OWIN middleware.
    • (23:56) Everything about the new release is up on the Superscribe.org site.

Show Links: