Posted on

Herding Code 170: NDC Geekout with Richard Campbell and Rob Conery

At NDC, Jon and Rob Conery quizzed Richard Campbell about books, nanotech, graphene, cooking, travel, explosions and more.

Download / Listen:

Herding Code 170: NDC Geekout with Richard Campbell and Rob Conery

Show Notes:

  • Cryptonomicon and other Neal Stephenson books
    • (00:55) Rob Conery says he’s been rereading Cryptonomicon. Richard, Jon and Rob talk about their favorite Neal Stephenson books.
  • Nanotech
    • (02:26) Richard mentions nanotech in the context of Diamond Age. Jon asks Richard what’s going on with nanotech.
    • (03:31) Richard describes graphene – what it is, how it’s made, and what we can do with it.
  • BBQ!
    • (07:38) Jon asks Richard what he uses to barbecue things. No surprise, he’s got three different BBQ devices, electrical modifications and Excel spreadsheets. Intense food chemistry discussions ensue.
  • Turing and Electromechanical computing
    • (11:32) Rob talks about the Enigma machine discussion in Cryptonomicon. Jon and Richard talk about how the Enigma code was broken.
  • Quantum computing
    • (14:37) Jon asks Richard about quantum encryption and computing. Richard explains  quantum effects with the two slit experiment.
  • My Drunk Kitchen
    • (18:10) Jon asks Richard how it came to pass that he hosted an episode of My Drunk Kitchen. Richard tells the history of My Drunk Kitchen and how french toast turned into some kind of sourdough frittata.
  • Home brewing and stills
    • (22:37) Jon asks Richard if he’s done any home brewing. Richard owns a still but has not used it in anger yet. Richard lists the dangers of moonshining and one-upmanship contests with Carl Franklin. 
  • The geekiest house ever
    • (25:38) Jon asks how Richard handles his intensely instrumented house and Rob asks for more details about Richard’s house. Richard says he’s only been raided as a suspected drug grow-op house once and talks about all the server infrastructure he’s got at his house.
    • (29:50) Rob asks about Richard’s generator setup.
  • Modern media management
    • (31:23) Jon asks Richard how he handles the hardest problem in modern life: managing media. Richard talks about his media shares, networking, media center, and how he gets all the good stuff.
  • Favorite books
    • (34:28) Jon asks Richard for five book recommendations. Richard recommends Existence, Daemon and Freedom. Jon and Richard discuss the believability of Daemon and Richard talks about how some authors are good story tellers, others are good universe builders, and authors who do both are incredibly rare. Richard also recommends Lean Startup and The Phoenix Project. Rob recommends Ender’s Game and talks about Arthur C. Clarke; Jon says he liked The Fiction Author’s Guide To Time Travel and that got him into Heinlein. Rob and Richard liked Dan Simmons – especially Hyperion. Rob and Richard discuss the difficulty of ending a story well and Richard says Harry Potter put The Matrix to shame in that regard.
  • Travel tips
    • (41:45) Jon asks Richard for some travel tips. Richard starts with recommending local SIM cards and knowing your power plugs.
    • (42:33) Richard recommends beating jet lag using light and timing your meals. Rob has been pretty happy with some homeopathic jetlag whatsihoosie and likes baking soda too.
    • (45:08) Jon likes compression bags and big batteries with USB outputs. Jon and Richard discuss the frustration of the VGA to HDMI conversion.
    • (47:33) Rob always maps out the nearest Apple store before travelling.
    • (47:57) Jon has USB video adapters for both VGA and HDMI and figures he’s covered.
    • (48:15) Richard mentions wireless video in Windows 8.1. Rob mentions AirPlay and Jon talks about Windows PlayTo, but they’re all too fiddly for now.
  • Pretend ending
    • If you don’t like background noise, this is the end. Bye!
  • More stuff in the outtake
    • We had some more discussion that’s pretty hard to hear because of background noise, but we’re throwing it in just in case you want to listen through it.
    • (50:44) Rob talks about Benford’s Law. Rob talks about the application in detecting voter fraud, Rob talks about the application in counterespionage in Cryptonomicon.
    • (52:14) Rob wants to talk about submarines. Jon talks about some of the complexities of torpedo seek patterns. Rob talks about Russian supercavitation and mine hunting. Jon talks about old Russian wing-in-ground effect vehicles and ski-ramp carriers.
    • (55:30) Richard talks about rail guns, which reminds Jon of fuel air explosives. Jon and Richard tell FAE stories.
    • (58:47) Rob tells a story about big explosions at a YMCA camp on Catalina Island.

Show Links:

Posted on

Herding Code 169: Tom Dale and Rob Conery on the EmberJS / AngularJS Cage Match at NDC

At NDC, Jon and K Scott sat down with Tom Dale (co-founder of Ember.js) and Rob Conery to recap their cage match battle, compare Ember.js and AngularJS, and hear from Tom about where Ember.js is headed.

Download / Listen:

Herding Code 169: Tom Dale and Rob Conery on the Ember.js / AngularJS Cage Match at NDC [audio://herdingcode.com/wp-content/uploads/HerdingCode-0169-NDC-Ember-Angular-Cage-Match.mp3]

Show Notes:

  • Intro
    • (00:18) K Scott and Rob asks Tom and Rob to introduce themselves and recap the Cage Match.
    • (01:22) Tom describes the challenge and thanks Peter Cooper for moderating. Rob describes the scenario – start with installation and creating a new project, then move to routing and navigation between views.
  • Demo vs. Reality
    • (02:28) Rob says it’s fun to do a demo with Angular, but once you need to do more structured things you have to start over and reimplement with modules, etc.
    • (02:43) Tom says that seeing the TekPub screencast about AngularJS informed a lot of their design for Ember.js. The result is a framework that gives you the same simplicity in getting started, but also grows with your application pretty easily.
  • You Just Don’t Do That
    • (03:22) K Scott asks if they pretty much match up if you’re looking at a feature checklist, and if it’s more about how you implement things. Rob says AngularJS is much more component based and talks about some things that came up during the cage match which were tricky in Angular, because "you just don’t do that".
    • (04:18) Jon asks if there’s an overall effect to how you build your application because it’s just not how the framework works. Tom says it’s unacceptable when your designer comes to you with a user interaction design for you to tell them it’s just too hard to do in your framework, so you won’t do it. As framework developers, they spend a lot of effort on composability. Rob says that he sees Ember.js as more prescriptive, while AngularJS provides more building blocks. Rob says it seems like Rails to him, in that it just goes a lot better for you if you give in and go with the framework’s opinions.
    • (06:13) Jon asks about how customization works in Ember.js, compared with Angular’s use of directives and filters. Tom says that’s done via helpers, referencing an example from the cage match.
  • Client-side MVC implementation and The Importance of URLs
    • (06:34) Rob asks Tom if it makes sense to say that "if you can think of it in a server-side framework like ASP.NET MVC or Rails, you can think of it in Ember.js". Tom says it’s not the same, because server-side MVC requests are short-lived compared to client-side applications. The real challenge is how you manage that state over time.
    • (07:17) Tom says that they think URLs are really important. Their challenge has been how to marry the concepts of desktop MVC with the fact that they have a URL, and he thinks they’ve nailed it. Jon asks how that compares to Angular; Rob says that it’s not a primary concern in AngularJS or Backbone.
    • (08:37) Tom says he considers your web application broken if he hits refresh and doesn’t see the same thing he saw before. Everyone screws this up, not because they’re idiots but because it’s hard, and if you don’t have this built into the framework you’re using you’ll mess it up. (09:06) K Scott asks what kinds of applications are the sweet spot for Ember.js. Tom says his first real professional programming gig was working on MobileMe / iCloud apps. They were big apps written in SproutCore. He says it’s important to be able to add features without breaking old features. Functional reactive programming and strong conventions help support this.
  • State and Scope
    • (10:38) Jon asks about the difference in maintaining state between Ember.js and AngularJS. Tom talks about how the Ember.js controller is similar to Cocoa and explains how the the controller presents the model to the template. Rob describes the $scope in AngularJS and compares the way AngularJS handles things more explicitly, whereas Ember.js is more conventional.
    • (12:19) Tom says that he thinks the way AngularJS leverages JavaScript’s prototypal inheritance is really elegant, but it breaks down when you have very deeply nested UI’s pushing you into directives and more complex decisions. Rob says that you can share scope between AngularJS controllers, but the isolated scope situation is one of the things you struggle with in Angular.
  • Testing, testing
    • (13:54) Jon asks Tom about his comment on testability. Tom says that Angular’s Karma test support is really nice, and they’re working on catching up in Ember. Rob says that in AngularJS you’re just working with basic objects, which is really nice when you’re testing.
    • (16:08) Tom says Ember.js requires you to do things correctly from the beginning; they won’t give you any foot guns to make things easier. Helpers help.
    • (16:42) K Scott asks how change detection works. Tom explains the differences – AngularJS uses dirty checking against the DOM, while Ember.js uses accessors (like Backbone). Tom says that the performance is better in Ember.js. Angular’s situation will improve when they get object.observe, which ironically will happen at the same time Ember’s situation improves due to support for object proxies.
    • (18:37) K Scott says he’d like to be able to conventionally wire up events. Tom talks about event delegation in Ember.js.
  • The SEO Elephant in the Room
    • (19:53) Tom says the biggest issue with JavaScript client-side applications today is SEO and describes why he’s not happy with the SEO solutions the other frameworks provide. They’re working on a solution that uses leverages the fact that they use Handlebars for templating to run a server-side process to generate SEO friendly content without any PhantomJS dependency.
  • Using Ember.js When You’re Not Tom
    • (22:28) Jon says that one issue with highly conventional frameworks is that it can be hard when you’re getting started and don’t know the conventions. Tom agrees and says that you’ll be frustrated if you experience learning difficulty before you feel the power and says the solution is documentation and good tooling. He mentions a coming Chrome extension that will show you what controller and model are backing content on the screen when you hover over it. K Scott says he’s pretty impressed with the Ember.js documentation.
  • What’s Next? How about some Prollyfills?
    • (24:45) K Scott asks about what’s coming out next. Tom talks about Polymer and Web Components. Jon asks if this was related to something he saw on Twitter the other day and Tom says it’s #extendthewebforward. The idea is that browsers should express primitives so browser vendors can innovate at the JavaScript level – rather than building speculative features into the browser, shipping a JS library that works cross-browser and can function as a polyfill (or "prolly"fill) if the feature doesn’t ship.
  • So who won? Any missed opportunites?
    • (29:45) K Scott asks who won the cage match and Rob admits to having been destroyed. K Scott asks why Rob keeps challenging framework authors to cage matches.
    • (30:52) Jon asks Tom about the curveball that he threw at Rob during the cage match. Rob and Tom agree that coding a directive on the fly is not easy.
    • (31:42) Jon asks Tom if there’s something that Rob could have asked Tom that would be hard in Ember. Tom says that they just added a competitor to filters using bound helpers, but if Rob had thrown list sorting at him he’d have had a hard time.
    • (32:54) Jon asks about a viewer question on the emphasis on getting started vs. maintainability. Rob says that they’d first focused on composability, but nobody wanted to use it until it was easy to get started. Framework libraries don’t get the luxury of forcing a difficult learning experience on developers – if he can’t show value in 5 – 10 minutes, you’ll leave.
  • Wrap?
    • (34:42) K Scott asks Rob and Tom what else they’ve got going on. Rob plugs some TekPub videos (listed below) and Tom plugs some upcoming classes he and Yehuda will be offering (also listed below).

Show Links:

Posted on

Herding Code 168: John Sheehan on Runscope

This week on Herding Code, the guys talk to John Sheehan about the recent launch of his new API developer tools company, Runscope.

Download / Listen:

Herding Code 168: John Sheehan on Runscope [audio://herdingcode.com/wp-content/uploads/HerdingCode-0168-Runscope.mp3]

Show Notes:

  • Intro
    • (00:30) "What is Runscope and why should I care?"
    • (00:55) Runscope is the ultimate API integrator developer’s toolbox. It helps you solve the problems you encounter in dealing with API’s from a consumption standpoint. It takes invisible API traffic and makes it visible, then helping you do all sorts of things with it: debugging, sharing, retry a request from the website, testing features like response playback without hitting the API, webhook debugging, etc. When you rely on an API, you’re not just taking on a service dependency – it’s code code that’s running on someone else’s service, and you should treat it like it’s code that’s under your control. You should apply the same testing rigor and should have the same debugging facilities.
    • (03:25) Jon asks about the launch. Anyone can try it out now at runscope.com. John talks about the internal preview (shoutout to Kevin Dente, the first beta tester) and the launch at GlueCon and press at TechCrunch and TheNextWeb.
  • (04:35) Overview of features:
    • Traffic Inspector
      • (04:55) In your code, instead of calling an API directly, you create a Runscope URL by including a Runscope bucket key and replacing dots with dashes. Essentially you’re pointing your API calls at Runscope, which then extracts the hostname and makes the API request for you. A lot of other tools require you to change your API calls by modifying your authentication, adding parameters, etc. Runscope doesn’t require any changes outside of the hostname, and all of your original headers and request parameters stay intact. This means you can just flip it on by changing your hostname and turn it off when done. You can then view all your requests in the Runscope website, filter to only show errors, All your requests show up in
      • (07:45) Scott says this is essentially a reverse proxy. John agrees that’s technically correct, but they avoid the term because they’re doing a lot more.
      • (08:13) Scott asks if Runscope adds headers to allow filtering or other things. John says the only modification they make is to add a Runscope message id header to allow lookup. They’re thinking of some things in the future like caching credentials to apply to a lot of requests and other features that benefit performance, security, etc.
      • (09:27) Jon asks about the security concerns, as Runscope is kind of like a man in the middle. John says they’re very concerned with security, and points to https://www.runscope.com/docs/security for a lot more information about their security practices. They’re looking at future things like encrypted storage, and currently if you make an SSL request to Runscope they will forward it over SSL to the API provider.
      • (11:45) Jon asks about cases like multi-legged auth. John says everything just flows through Runscope, with one exception – if a response comes back with a location header then Runscope will modify the location to a Runscope url so if the client follows it it’ll be captured.
      • (12:40) Scott asks about how geolocation works, since Runscope is making the request from a different location. John says that currently they’re making requests from US East Coast, but in the future they want to allow requests from specific geographic areas.
      • (14:10) Scott asks about a current app he’s working on which requires a custom certificate to connect to an API and asks if that would be supported. John says that they’re looking at both support for custom certificates as well as on -premises installations to support those scenarios.
      • (15:35) Scott asks about support for non-standard ports. John says they support that using a Runscope request port header.
    • Request Editor
      • (16:09) Jon asks about the Request Editor. John explains that they really wanted to make it possible to edit and create requests as easily as any other code. Their original inspiration was the hurl.it site. Jon interjects that he loves using hurl.it to see where shortened or dodgy urls will take him before clicking on them. John says they’ve taken the idea of hurl.it and really filled it out to include storage, advanced editing, etc. They also built in some helpers for basic auth, digest authentication, OAuth 1, OAuth 2 token generators, etc.
      • (19:45) Scott asks if they’ve looked at integrating OWASP tests to run some automated security inspection for things like SQL injection, XSS, redirect attacks, etc. John says he’d like to let people create collections and share them with others.
    • Shared Requests
      • (21:11) Jon says that when he was testing during the beta and hit a question, John just had him share the request with him. John says that he really wanted that feature when he was at Twilio, and they currently use it all the time internally.
      • (22:39) Jon asks if there’s a way to download or otherwise privately share a request. John says the best way to do that now is use team account, which allows for privately share requests within the team. They’re also looking at allowing redacting some fields in shared requests, so you can share a request without revealing your password or other sensitive information.
    • Passageway
      • (22:48) Passageway was based on the localtunnel project. It installs an agent on your local machine which forwards requests to a specific port to Runscope, and Runscope then creates a public URL. You can use Passageway to show off code running on your local machine, but you can also use it for debugging webhooks and testing API’s used in a mobile application (by pointing it at the public Runscope URL). Scott says he sees this as being useful in a continuous integration environment, and John says that a current customer is already doing this.
      • (27:33) Jon asks about the installation via pip, and John explains how pip relates to other package managers. They plan to provider other installers, and later the agent will do more than just Passageway – right now it also supports automatically creating Runscope urls for requests.
      • (29:27) Jon says that Passageway is the first place on the site where he sees something about paid accounts and asks John how they’re going to get rich. John says there are three reasons (access to passageway, team sharing and volume) to upgrade from a free account to a starter or team account. Jon asks about the naming of the starter account, and John says that naming and pricing are really hard. Scott offers some advice on enterprise friendly pricing.
  • Starting a business
    • (32:47) Jon asks about the experience of moving from being a developer to founding a company. John says he’s started several small companies, and writing software has always been a way to solve problems for businesses. He tells his recent job history at Twilio and IFFT and how he and his co-founder Frank got really fed up with the lack of good API developer tools and how they got started, funded, and launched. Getting funded was both a finish line and a starting line.
    • (41:33) Scott and Jon talk about positive response they saw to the GlueCon launch: John spent the majority of the time describing the problem, then unveiled the solution. Scott compares John to Steve Jobs.
  • What’s next
    • (43:05) Jon asks what’s next. John says they’re first focusing on dev-time troubleshooting. Next they’ll be focused on production use, especially high volume use cases. Long term they’re thinking about mitigating problems – handling or proactively monitoring for problems.
  • Python
    • (45:14) Jon asks about John’s experiences building Runscope in Python and how he compares it to .NET. John says he’s really come around to significant whitespace and standard
    • (46:59) Scott asks if John’s noticed that there are fewer ways to solve a problem, as opposed to C# or JavaScript. John says that’s true for the most part. He comments on how he likes the small libraries and ecosystem.
  • Runscope vs. other network tools like Fiddler and Wireshark
    • (49:19) Scott asks why you’d use Runscope rather than use things like Fiddler, Wireshark, etc. John explains proxies and applications modify the way the application works and doesn’t work well on servers – it’s cloud-native. It’s also social – sharing is built in. Thirdly, it’s not a desktop application.
    • (52:30) John says he’d like to write a Fiddler plugin to make the two work well together. Scott says that there’s one advantage to desktop applications – it can interact directly with the network stack. John agrees that developers need tools that work at all layers of the stack. Scott recounts a harrowing tale in which Fiddler had to be installed on a server for an application to work.
    • (55:20) Jon says he was wondering about integrating with Glimpse but that would require an API – does Runscope have an API? John says one’s on the way soon.
  • Lightning Round inspired by John’s Traffic and Weather podcast (with Steve Marx)
    • (57:00) Jon says he’s really been enjoying the Traffic and Weather podcast, and the John and Steve have convinced him that API’s really can be interesting.
    • (57:50) JSON API – what is it, and is it good?
    • (59:34) What are webhooks, and why have you been talking about them?
    • (1:01:52) Should we stop writing REST SDK clients?
    • (1:04:29) Where is API security going? Is it OAuth 2 from here on out?
    • (1:05:21) Eric Williams (@motowilliams) asks "Ping Pong or Foosball? #gooooooaaaaaallll"
    • (1:06:17) Where are you speaking next (answer: API Days and API World, both in San Francisco)
    • (1:07:32) Do you support the HTTP 418 teapot response?

Show Links: