Category Archives: interview

Herding Code 210: Ian Cooper on Microservices and the Brighter library

While at NDC Oslo, K Scott and Jon talked to Ian Cooper about Microservices and using the Brighter library for Command Dispatcher / Command Processor patterns.

Download / Listen: Herding Code 210: Ian Cooper on Microservices and the Brighter library

Show Notes:

  • Why Microservices?
    • (0:48) Ian explains that "micro" doesn’t imply number of lines of code but "A bounded concept/business capability within your Domain" (put forth by Martin Fowler and James Lewis)
    • (1:20) Ian talks about breaking the domain problem down further and further for simpler testing, better fault tolerance and incremental releases.
    • (2:20) "If you can’t QA everything you need to be able to monitor and respond to issues rapidly."
    • (2:42) Scott Allen asks if Devops is a driver for Microservices rather than physical deployment or team size.
    • (3:00) Ian talks about the scale limits of developers and teams and how component based architectures.
  • Have we been here before?
    • (4:00) Ian talks about how Microservices is the next generation of component-based architectures after DCOM, CORBA, SOA and the importance of understanding what worked, what didn’t and why.
    • (4:49) Asking a component for a cup of tea vs telling something how to make tea highlighting the difference between Microservices vs RPC. RPC was very coupled to behavior which lead to fragile APIs.
  • Finding the "micro" sweet spot
    • (5:50) Jon asks how you manage the complexity of orchestrating many smaller pieces.
    • (6:15) Ian advises against going too small – Nanoservices – where the overhead of a service overshadows the utility value of it.
    • (6:30) "It’s really hard to get a feel in a new domain of where those points are that you can slice effectively" – one solution is to start exploring the domain in a traditional monolithic way and to break the parts apart at the seems to get the tradeoff right.
  • Tooling and support
    • (7:06) Jon asks what a good way to manage these services including profiling and monitoring.
    • (7:20) Ian recommends some tools to help:
      • New Relic for introspective monitoring and diagnostics.
      • Logstash or Splunk for log analysis and the usefulness of adding a GUID to a request that flows through messages and logs to correlate the activity.
      • Zookeeper or Consul for service registration and discovery.
    • (8:28) Scott Allen and Ian talk about how Microservices take forward SOA principles such as autonomous services, not sharing types and stable interfaces.
    • (9:00) Scott Allen asks what options for communications between the services are and Ian compares HTTP, Sockets and message queues like RabbitMQ.
  • Ian’s Brighter .NET lightweight Microservices project
    • (10:20) Basic two parts of Brighter are:
      • Command Dispatcher/Processor – Maps a command to a processor with a pipeline where you can insert orthogonal operations like logging and monitoring
      • Task Queue – Allows some commands will be handled asynchronously elsewhere
    • Very simple for the developer – just write a command and a handler.
    • Easy to embed in your existing Windows service if using something like Topshelf.
    • Provides timeouts, retries and a circuit breaker inspired by Netflix’s Hystrix in a declarative manner.
    • (12:45) Scott Allen clarifies how easy it is to get two services talking to each other using this via RabbitMQ.
    • (13:00) Ian talks about future support for Azure Service Bus and the possibility of producing one for Redis – RabbitMQ and Amazon SQS are already supported.
    • (13:30) Scott Allen asks if this is used in production and Ian explains how Huddle started with using RX on the server and had difficulties managing subscriptions.
    • (14:20) Brighter is on ThoughtWorks Technology Radar and evangelized by ex-Huddlers at their new roles.
    • (14:40) Ian talks about the importance of good documentation and welcomes feedback on theirs.
    • (15:10) Ian mentions they facilitate hexagonal architecture.
    • Scott Allen asks if you can use in-process and Ian explains the subtleties
  • Wrap-up
    • (16:00) Ian’s time is sucked up by being a a new dad, congratulations!
    • (16:30) The one job of a parent is keeping children alive.
    • (16:40) Thank-you and goodbye.

Show Links:

These show notes were contributed by Damien Guard. Thanks!

Herding Code 203: Rob Eisenberg on Aurelia

The guys talk to Rob Eisenberg about Aurelia.

Download / Listen: Herding Code 203: Rob Eisenberg on Aurelia

Show Notes:

  • [Sponsor Message]
  • Hello There
    • (01:15) Kevin introduces Rob.
    • (02:05) Kevin asks Rob about his Xaml platform work with Caliburn.Micro. Rob says he’s transferred that work to Nigel Sampson, and it’s alive and well.
  • Comparing Aurelia with Angular
    • (03:22) Kevin mentions Rob’s history on the Angular team and asks what’s different about Aurelia. Rob says that he’s focused on vanilla Javascript code and minimizing configuration and metadata. Rob says that’s unique compared to most common frameworks, not just Angular.
    • (05:25) Rob also wanted to target transpiled languages so it worked well with ES6, ES5, TypeScript and Coffeescript. By comparison, Angular was pretty focused on Dart and AtScript.
    • (06:12) Jon references Rob’s post comparing Angular and Aurelia code and asks about conventions. Rob describes how conventions work, how you can create your own conventions, and how you can override conventions by providing metadata (but only for overrides, not all the time).
    • (08:56) Rob describes how binding and the templating syntax work. Aurelia minimizes additional markup for binding, whereas he sees Angular syntax focused on theoretical tooling experiences that could be built, but nobody’s committed to. Also, while Angular’s syntax is technically valid, it doesn’t work with cases like SVG. There’s a secondary binding syntax to work around that, but having two syntax doesn’t seem like a clean solution.
    • (12:31) Kevin asks for examples of conventions in Aurelia. Rob explains how custom elements work with EcmaScript 6 modules and exports. No metadata is required, as compared to Angular which requires specifying metadata in all cases even if you’re not using them. Rob also explains custom attributes (again using a simple exported class). Naming conventions set up the mappings so no metadata is required. Value converters are yet another example – the naming convention assumes that any class ending in ValueConverter is automatically registered and configured.
    • (16:24) Jon asks if Angular’s metadata requirements and verbosity are all for tooling support. Rob says yes for the HTML side, he doesn’t see a reason for it on the JavaScript side.
    • (16:43) Rob says that in Angular you need to declare all directives you’re using in your view models. That really bugs Rob because the implementation details in the view shouldn’t be reflected in the viewmodel. That was required for lazy loading, but he sees it as a design problem and a maintenance problem. Rob says that Aurelia uses an import in the view and doesn’t touch the viewmodel, using the EcmaScript 6 loader. Rob says that this design makes some conventions impossible.
  • The Aurelia Pitch
    • (21:08) Scott K says he likes the class-based design in Aurelia and asks Rob for a quick pitch for Aurelia to sell it to a team. Rob talks about the clean, standards based design that allows decomposing complex screens without requiring extra configuration. It’s easy to build, extend and maintain. Rob also talks about the binding syntax, and the ability to plug in other binding strategies by dropping in an adapter. The binding strategy system has been tested out with Breeze.js and Knockout, allowing you to use your existing models without requiring unnecessary dirty checks.
    • (26:42) Scott K asks how object.observe works with tranpilers. Rob says there’s a polyfill that generates getter / setter pairs if object.observe isn’t available. Rob explains how this works with the micro task queue, and how it allows for queued tasks to handle queued work efficiently. Rob talks about the task-queue in Aurelia, and how it can be used outside of Aurelia as well. Rather than directly observing DOM elements, the task queue allows for batching changes for efficiency.
  • Persistance
    • (35:15) Kevin asks if Aurelia handles a persistence layer. Rob says that rather than building that, they’ve worked to make it easy to plug popular persistence libraries in. He also discusses the validation system they’re working on.
    • (38:22) Jon asks if Rob’s looked at PouchDb and references Herding Code 181, in which Max Thayer explained PouchDb.
  • Why not write my own framework?
    • (39:40) Jon says he frequently hears people who are tired of JavaScript frameworks and decide to just write their own. Rob describes how it’s easy to get started but quickly falls apart. He describes some of the gotchas he’s run into in building Aurelia, with examples from aria, svg, data- attributes. Rather than writing your own framework, Rob says you should just contribute to Aurelia.
  • SVG use
    • (44:40) Jon asks if Rob thinks people will use SVG. Rob says it’s more about building a production-quality framework, then gives some possible usecases like graphs, mapping and custom elements. Rob says that people do all kinds of things you might not expect when they use a framework, and building a real framework requires it. Kevin says at his last job they’d started converting image sprites to SVG, and it was a pretty good use-case.
  • React
    • (49:05) Kevin asks about Rob’s thoughts on React. He says it’s a good renderer, but it’s not a framework. He and Scott K agree that React is a library, not a framework. Rob says he wrote a blog post in which a custom Aurelia element uses React as a custom renderer. The Babel transpiler allows mixing JSX with ES6 code, and this allows continuing to use Aurelia binding. In general, Rob says really smart, but if you need a framework you’ll end up cobbling a bunch of things together to use it. Instead, he’d recommend using a framework like Aurelia and just pulling in React when it’s required.
    • (53:22) Kevin asks if Rob’s considered adding a virtual DOM to Aurelia. Rob says it’s not clear that there would be an advantage in most cases.
  • Isomorphic rendering
    • (54:17) Kevin brings up the other JavaScript buzzword of the day: Isomorphic rendering. Rob says Aurelia doesn’t support this, he doesn’t see this sticking around. Jon says he still sees a pretty clear distinction between websites and web apps, and Rob agrees, saying he wouldn’t use Aurelia for websites.
  • Questions from Twitter
    • (57:25) Question from Twitter (@cecilphillip): "What’s the rendering perf like compared to ReactJS?" Rob says that React is going to be a lot faster for initial render time, whereas Aurelia is probably going to be faster for updates. It’s hard to give an accurate comparison; Rob says they’re mostly focused on being fast enough rather than the fastest. He says Aurelia’s not slow now, but they’re focusing on some upcoming performance enhancements that he’s expecting big results from.
    • (1:02:09) Question from Twitter (@csharpfritz): "can you talk about what lead to the choice of architecture with JSPM?" Rob explains how JSPM integrates package management with module loading. Aurelia isn’t directly dependent on JSPM, so you can use other package managers and loaders if you want. Jon says the one thing he wants JSPM to integrate rate limiting so he doesn’t hit the GitHub rate limit; Rob says this is being addressed in a future release since most cases don’t require the hitting the rate limited API.
  • Scott K’s Packaging Rant(tm)
    • (1:08:11) Scott K has a "short rant" about NPM, JSPM and all package managers in general: they all use existing config files (like gitconfig) and should be tested behind corporate firewalls and proxies. And then there’s the nested package thing, which doesn’t work well on Windows due to path length limits. Jon says he uses the flatten-packages package. There’s a short group rant about the file path length limit on Windows.
  • Final questions and wrapup
    • (1:13:40) Jon asks if there are any patterns or thoughts on server-side development for Aurelia. Rob says there are starter kits on the way, and people are using Aurelia with lots of back ends (.NET, node, MEAN, etc.). He talks about samples on the way, including a Todo app (even though he thinks Todo apps aren’t useful for application frameworks).
    • (1:17:15) Kevin asks where Aurelia’s at in a release cycle. Rob says it’s currently in preview / alpha phase but targeting a beta around June or later. Don’t go to production with it now, but get ready for the release after that.

Show Links:

Herding Code 198: Damian Edwards on ASP.NET vNext, Tag Helpers and SignalR

The guys talk to ASP.NET team member Damian Edwards about ASP.NET vNext (the next version of ASP.NET), Tag Helpers, and what’s new with SignalR.

Download / Listen: Herding Code 198: Damian Edwards on ASP.NET vNext, Tag Helpers and SignalR

Show Notes:

  • Hello. What is ASP.NET vNext?
    • (00:18) ASP.NET vNext is the next version of ASP.NET. It’s not just ASP.NET MVC 6 or Web API 3, it’s a total rethink of the ASP.NET platform. In some ways, it’s a bigger change than the move from classic ASP to ASP.NET. In other ways, it can be pretty seamless depending on what you’re doing.
    • (01:29) Jon asks Damian to talk about what’s crazy and brand new. Damian describes the full stack in a web application, from the operating system up to the code that you write in your application and the libraries you bring in. Starting at the bottom of the stack, ASP.NET vNext is cross platform, meaning it will work and be supported on Linux and Mac.
  • Cross platform
    • (02:36) Jon asks Damian to clarify what that means – is it supported cross-platform, or does it just kind of work? Damian says that it’s first class support – they’ll ensure that it works cross-platform, there will be cross-platform documentation, and there will be cross-platform tooling (Damian mentions the Sublime plugin for ASP.NET vNext). They’ll support building and deploying ASP.NET vNext applications cross-platform.
  • Core CLR
    • (03:41) Damian continues up the stack, talking about how .NET framework is booted up. In vNext, there is a native code custom CLR loader that is decoupled form the operating system’s .NET loader. Even when you’re running on Windows, you’re not relying on the standard .NET loading mechanism.
    • (05:56) Jon mentions having seen demos where code was written on one laptop, copied onto a USB drive, and executed on another laptop, asking if the custom .NET loader is what makes that work. Damian explains that’s half of why it works – the next layer of the platform is the managed runtime itself, which is the other half of the magic. There is a new CLR based on core CLR. Damian explains how the .NET runtime runs on a core CLR and the base class libraries. The core CLR is based on the .NET CLR for Silverlight – it was already a lightweight version that ran cross-platform. There are now two options for the CLR you can run on – the full .NET CLR, or the new "cloud optimized" CLR. It’s important because it’s smaller – so small that it can be deployed with your application. Also, because it can be self-contained, multiple versions can run on the same server.
    • (10:01) Scott K asks what prevents bundling the entire application up into a single EXE. Damian talks about how .NET Native is being used in Windows Store applications and says they’re intending to look at that for ASP.NET vNext in the future. For now they’re achieving isolation by shipping the core CLR and libraries as NuGet dependencies.
    • (12:30) Scott K asks if you need to have the .NET framework installed at all if you’re running ASP.NET vNext. Damian says no, and if .NET is installed it has no bearing on your application.
    • (12:12) Jon asks how this affects IT shops that want full control over .NET framework installations on their servers. Damian says this question requires more context on what administrators would be afraid of. He describes how ASP.NET vNext will support servicing, so any urgent vulnerabilities can be patched globally on a server.
  • How does this affect existing apps? What changes?
    • (14:50) K Scott brings up a Twitter question from James on how this will affect ASP.NET MVC and Web API applications. Damian says that ASP.NET MVC 6 will include both ASP.NET MVC and Web API. Damian explains how ASP.NET MVC is on version 5 and there are some things they’d do differently today. It also previously depended on System.Web, which dates all the way back to before 2000. ASP.NET MVC 6 has DI built in. It’s OWIN compatible, so you can run it on any OWIN compatible server and run any OWIN middleware. Global configuration (web.config and System.Configuration) are gone, replaced by code-based configuration influenced by Katana. There’s also Entity Framework 7, which is a complete rewrite that doesn’t have ObjectContext or System.Entity – instead it makes model first (DbContext) foundational. EF7 also works with non-relational databases. If you have an existing application with ASP.NET MVC 5 or Web API 2, it should port over pretty seamlessly as long as you’re not working directly with underlying components like System.Web or HttpContext.
  • Development experience
    • (19:39) Scott K asks about the development experience – will this work in a new Visual Studio version, or can he just create applications in a text editor? Damian says both will work. This both allows cross-platform development and a more flexible development stack, allowing for things like cloud-based development. Of course, ASP.NET will work work great on Visual Studio. They use Roslyn to do all the code compilation either at design or compile time. This allows for deploying the entire application as source, and eliminates the need for a separate compile step during development (since the code is constantly being compiled as you work).
    • (25:15) K Scott asks how much churn he should expect if he starts developing with ASP.NET vNext today. Damian says there’s a lot of churn still right now. It won’t release until well into next year some time.
  • Questions from Twitter
    • (26:34) Iris Classon asks what features they weren’t able to include that they’d have liked to. Damian says it’s too early to answer that question, since they’re still in pretty early development.
    • (27:00) Iris Classon also asks where they looked for inspiration. Damian mentions web frameworks like Rails and Node as well as module loading in Java.
    • (27:38) Ben Maddox asks how Damian sees this improving the feedback loop for code, UI and tests. Damian says it speeds up UI feedback since all of your code is compiled as you type it and continuous testing is enabled due to the continuous compile. Both are available today with other tools or things you set up yourself, but it will be simpler in future.
    • (28:55) Steen R. asks when we’ll see cross-platform Visual Studio. Damian says there are no plans he’s privy to.
    • (29:05) Filip Woj. asks if F# will have first class support – released and supported. Damian says not for version one, although there are demonstrations of F# providers.
    • (30:40) Steen R. asks how webroot will work in practice. Damian describes how webroot works – it’s a separate directory from which your application is served. Any files not in the webroot folder will not be served by the web server. Your application or uploads folders will be separate from your webroot, so they can’t be served.
  • Portable areas?
    • (33:49) K Scott asks about portable areas. Damian says he’s not aware of something like that for ASP.NET MVC.
  • Tag Helpers
    • (35:18) Jon asks what tag helpers are. Damian describes how Razor is a templating language that’s designed to allow mixing C# and HTML. It falls down a bit when you’re using HTML Helpers and want to change the output – for instance, if you want to pass in an HTML class to an element. C# gets in the way due to things like class being a reserved word, and you miss out on any HTML IntelliSense or HTML editor smarts, because you’re just working with C# strings. Tag helpers allow you to just write HTML tags with attributes that Razor understands. These can do things like access the model metadata to emit appropriate form HTML.
    • (41:27) K Scott asks when he can start using it. Damian says that it’s in a separate feature branch now and explains how to use them and says you can ping Taylor Mullen for help – or just wait a few weeks and it’ll be in the main branch.
    • (42:59) Jon comments on how the Spark view engine provided something similar, and Damian says that Lou works right next to him and has helped with the design. They’re not trying to change the core of how Razor works or feels, just make it easier to work with HTML helpers.
  • SignalR
    • (44:10) Jon asks what’s new with SignalR. Damian runs down some of the recent releases and mentions SignalR 3 for ASP.NET vNext. He also mentions the C++ client that’s currently in development.
    • (45:28) Jon asks if ASP.NET vNext makes some things simpler for SignalR. Damian says the main impact is that things like configuration and tracing are now shared between components like Web API and MVC.
  • Wrap Up
    • (46:56) Jon asks Damian what’s coming up for him. Damian mentions some of the talks he’ll be doing at NDC London, including load testing SignalR and ASP.NET vNext.
    • (47:50) Jon asks Damian how people can keep up with ASP.NET vNext, mentioning the asp.net/vnext page. Damian also recommends the weekly ASP.NET vNext Community Standup meetings, being run as a public weekly Google Hangout hosted by Scott Hanselman and Jon Galloway.

Show Links:

Herding Code 195: Michael Mahemoff on Player FM

The guys talk to Michael Mahemoff about Player FM, a cloud based podcast application which is focused on discovery and multi-device synchronization that he recently showed off at Google I/O.

Download / Listen: Herding Code 195: Michael Mahemoff on Player FM

Show Notes:

  • Hello. What is Player FM?
    • (00:48) K Scott asks Mike for a quick introduction. Mike has studies both psychology and software engineering and has worked on a variety of applications, focusing lately on HTML5 web applications. He’s been working for the past few years on Player FM, a cloud based podcast application which is focused on discovery and multi-device synchronization.
    • (01:55) K Scott asks about the technologies used to build Player FM. Mike talks about the advantages of moving feed fetching to the cloud, the web site (using a PJAX implementation which pushes markup rather than data and HTML5 history) and an API.
  • Player FM API
    • (04:33) K Scott asks more about the API. The server is running Ruby on Rails using controllers that supply different format based on the extension in URL. The API is publicly available for experimentation but isn’t officially supported. Mike’s set up using a spectrum of detail levels (none, id, medium and full) rather than allowing clients to select specific fields. This allows you to be efficient in your API requests for hierarchies but is still cachable. He’s created a framework to support that.
    • (09:10) Jon mentions some of the URLs he’s seeing in browsing the API for listeners who want to play along at home. He asks Mike about the balance of a self documenting API vs the full hypermedia smart client approach. Mike says he thinks the API needs to be pretty mature for that to work and points out some of the curated lists in the feed.
    • (11:33) K Scott asks if the curation is community based. Mike says that’s the eventual goal, but for now he’s doing that.
    • (12:23) K Scott asks about the difficulty in tracking when all the feeds have been last updated. Mike says that originally it was a simple loop using feedzilla. Now it’s using sidekick and the PubSubHubbub standard (using the superfeeder service and webhooks). The clients are still polling now, but he’s going to be updating the clients to use Google Cloud Messaging (on Android) and iCloud Messaging (on Apple) so the updates will be realtime from publisher to client.
  • Native clients for Android and iOS
    • (14:30) K Scott asks if Mike’s building native clients. Mike says the iOS client is still in development and the Android app is native. K Scott says he’s wanted to do some Android dev but it’s always seemed like the most difficult platform. Mike says that it’s gotten easier lately due to the new application services and gives an example of the Google Wear Services. Jon asks for some more info on the Google Wear integration and Mike explains how any media framework application automatically gets some support, and they’ve extended it to create a phone application to allow episode browsing on the watch.
    • (17:15) K Scott says he was surprised by Mike’s blog post about the demand for Chromecast support for audio applications and asks about the work required to build that support. Mike explains the API integration and says that the hardest part was complying with the look and feel guidelines.
  • Advanced podcast support with Podlove
    • (20:02) Jon asks if there are things that podcasts can add to enable podcast applications to give a better experience. Mike talks about emerging standards like Podlove which adds support for chapters, time based links, attributions and related feeds. Jon says he’s been including timestamps in the show notes for a while so that seems pretty easy to implement. Mike talks about how TimeJump and Podlove could allow for deep linking into content.
    • (22:18) K Scott asks what’s been frustrating in dealing with feeds. Mike talks about the difficulty in feed parsing and the differing standards and implementations. Jon says he’s always just used Feedburner. Mike likes Feedburner and appreciates the built-in support for PubSubHubbub and would like to see Google pay more attention to it.
  • Misc: Business plan, mobile web support and Google I/O
    • (24:24) K Scott asks if Player FM is Mike’s full time job. Mike says it is. They’re not monetizing it yet, but he’s building out a freemium service with advanced features like unlimited subscriptions and advanced syncing across devices.
    • (26:16) Jon asks if Mike has plans for a Windows Phone application. Mike says he’d love to support it eventually, but right now his support for other platforms is via the mobile optimized website and the Player FM feeds.
    • (27:06) K Scott asks about Mike’s experience in bringing Player FM to Google I/O. Mike talks about the experience – it was his 4th Google I/O, and he’s been both an attendee and speaker in the past, but this time he was too busy to attend.
  • User Experience
    • (28:43) K Scott asks how Mike’s psychology degree has helped him in software development. Mike talks about the applications in user interface design and machine learning. Jon asks about Mikes thesis about human computer interaction; Mike talks about user interface design patterns for consistency.
    • (32:20) K Scott says he’s happy the Player FM site doesn’t use the ubiquitous cheeseburger menu. Mike talks about some of the UI design features in the web application.
  • API Optimization
    • (33:19) K Scott asks about optimizations in the API. Mike talks about timestamps in the API responses so the mobile applications can keep aware of which channels have been updated and get the responses from edge servers.
    • (36:10) Jon asks about using JSON LD and E-Tags. Mike says he hasn’t needed that since he’s building the clients and they’re doing the same checking.
    • (37:39) Jon asks how Cloudflare has worked for Mike. Mike says it’s been great, but there were a few surprises like caching of error responses.
    • (38:40) K Scott asks if it’s possible to remove things from the cache. Mike explains some of the options. Jon talks about some of the difficulties in diagnosing content problems when you’ve got multiple levels of caching and Mike agrees that it’d be nice if there were some visibility via HTTP headers.
  • Search and Discovery
    • (40:48) Jon asks if Player FM has additional markup to light up in search results. Mike says they were one of the early sites to be included in the Google app indexing setup, which supports deep linking in Android applications.
    • (42:30) K Scott says he’s looking forward to the recommendation features and Mike describes some of the things they’re including.
    • (43:30) Mike talks about Player FM support for full text search using Elastic Search to allow for easier discovery.
    • (44:25) Kevin asks if transcripts could be included in the full text search. Mike talks about some of the standards support.
  • Wrap Up
    • (45:49) K Scott asks what Mike does when he’s not working on Player FM.
    • (46:47) K Scott asks Mike what’s coming up for him in the near future. Mike talks about some Player FM features he’s excited about working on like intelligent discovery, collaborative filtering, server-side play tracking, analytics and platform support including an desktop form factor that will work offline. The desktop application is based on an open source project they’re working on that will compile a Chrome application and cross-compile native applications for Windows, Apple and Linux (based on node webkit).
    • (48:20) K Scott asks for any last words; Mike says he’s happy for any questions at mike@playerfm.com.

Show Links:

Sponsor

This show is brought to you by Runscope – find out more at http://runscope.com/herdingcode

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:

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: