Category Archives: interview

Herding Code 223: Keith Horwood on StdLib, Nodal, and Functions as a Service

The gang talks to Keith Horwood about stdlib, nodal, and lots more!

Download / Listen: Herding Code 223: Keith Horwood on StdLib, Nodal, and Functions as a Service

Show Notes:

  • Standard Lib (stdlib)
    • (00:44) Standard Lib is a registry for serverless microservices. It’s kind of like a mix between npm and heroku, so there is a central registry, but rather than just installing the services locally, they handle deployment for you. There are command line tools available via npm that make it easy to create (lib create) and deploy microservices (lib up).
    • (02:23) Jon says he’s pretty impressed with the interactive experience on the website, where you can very quickly deploy a service. Keith explains how they set up a service that handles the tarball packaging to allow creating a service in the browser. They expect that developers will usually start with the cli tools, but the browser based onboarding experience is nice for new users to get familiar with the service.
    • (04:22) K Scott says that essentially he can just write a javascript function and have it running as a service. Keith agrees, but says it’s also set up so you don’t need to manage servers – it automatically scales and self-heals.
    • (05:34) K Scott asks about how the monitoring and exception handling works. Keith says they work with several monitoring systems. Currently the output is just a text dump, but they’re working to improve that.
    • (06:15) K Scott asks about how you handle persistance. Keith says that currently they don’t offer their own persistence layer, and he recommends just using compose or Dynamo or RDS. They’re talking to some companies doing some neat stuff with GraphQL and gives a shoutout to Graphcool who runs a really cool GraphQL backend as a service.
    • (07:48) K Scott asks about their pricing model. Keith says they’re going to be going with a Twilio-style system where you fill up a wallet and pay per compute, so you only pay for what you use.
    • (09:09) K Scott asks how they differentiate from AWS Lambda and Azure Functions. Keith explains how they’re providing another layer of abstraction. The existing infrastructure and infinite scalability are great, but the workflows are too complex, so stdlib provides a nice layer on top of that.
    • (10:42) K Scott asks about their versioning system, in which development is mutable but releases are immutable. Keith explains that service immutability is a point of trust for API consumers. When you’re developing, you’re not supporting consumers, so you can continue to change your service, but once you deploy your service can’t be changed.
    • (12:42) K Scott asks how clients will reference an API by version. Keith talks about the syntax for referencing a specific version and says if you don’t specify a version number you’ll just get the latest.
    • (13:55) Jon asks what to do if he deploys a package with a really bad error. Keith explains how you can use “lib down” on a package, and discusses the monitoring and notification systems they’ve got in place to communicate with consumers.
    • (15:17) Jon asks about the view templates. Keith says that they started building view templates for internal use as backends to single page applications, then realized they’d be very useful to other developers. They also have templates for Alexa apps including a Delores Abernathy (WestWorld) sample app.
    • (16:44) K Scott asks about what some of the biggest challenges they faced putting it together. Keith says that AWS Lambda can be a black box and talks about the process of finding the right developer abstraction.
    • (18:36) K Scott asks about Keith’s blog post titled Using “Server-less” Architecture to Massively Parallelize DNA Sequence Alignment via StdLib and Node.js. Keith explains what DNA sequence alignment is, and how you can use massive parallelization to go from an n-squared problem to operate with a time complexity of one.
  • NtSeq
    • (21:35) Jon asks about Keith’s NtSeq library for DNA sequencing. Keith actually dropped out of grad school in bio chem, so he had the background and some code lying around.
  • Collaboration, Dependencies, and Documentation
    • (22:50) Kevin says that a lot of function as a service samples are petty simple, but real solutions will require multiple collaborative services. Are there thoughts on how to assemble collaborating services effectively? Keith explains that these were some of the design goals for stdlib.
    • (25:22) Kevin asks if there are ways to track service dependencies. Keith talks about the static analysis opportunities, and mentions that all dependent services you’ve been calling will show up in your dashboard.
    • (26:15) Jon is pretty impressed with the service documentation and asks how it’s created. Keith talks about the markdown and service json based documentation.
  • nodal
    • (27:25) K Scott asks about what prompted Keith to create stdlib. Keith talks about the history, starting with the nodal platform. nodal has been pretty popular as a platform, but many really liked the workflows for deployment and service management, but didn’t necessarily want to learn a new platform, and many didn’t have data persistence needs.
    • (29:40) K Scott says that he finds the Nodal sample very easy to read – ES2015 classes that extend a base controller. Keith talks about the unique time in JavaScript history when Nodal started. He’d made a bet on io.js during the Node / io.js split, and had leveraged ES2015 syntax. When io.js and Node merged back up, Nodal was the one of the first mature Rails-like frameworks.
    • (31:35) K Scott asks about the ORM. Keith talks about why he built the query composer. Nodal’s ORM is called the composer, and it uses method chaining, then reduces everything down to one query. That gets around the n+1 issues you’ll run into with ORMs like Active Record. There’s a GraphQL example at which can take a GraphQL query and translate it down to a single Postgres query. They’re looking at breaking the composer out to allow use in other GraphQL applications. K Scott asks more about the join syntax and lazy / eager loading.
    •  (35:21) K Scott asks about the extends keyword and object orientation. Keith says that the JavaScript community is growing so quickly that as long as developers can read the code easily, they’re just happy that it’s there. A lot of these newer developers aren’t that opinionated, and developers are happy to work with opinionated frameworks.
  • What do you do for fun, music apps, what’s next?
    • (36:35) K Scott asks Keith what he does when he’s not working on stdlib and nodal. Keith says it’s the majority of his time now. Keith says he used to run.
    • (37:28) Jon noticed Keith’s audiosynth.js lib on GitHub. Keith says that audiosynth was done before webaudio and webmidi, and he stumbled on someone who was generating simple sine wave audio files in JavaScript, and he extended it to use some more interesting string synthesis algorithms to make some more advanced tones. There are some more advanced audio APIs available now. Keith says that the most interesting outcome of that work was the connection he made to the first engineer they hired at stdlib.
    • (40:22) K Scott asks what’s coming up. Keith talks about the authentication and authorization layers as well as multi-language SDKs and support that are coming out soon. K Scott asks about the current auth story, and Keith says that currently you code it all yourself.

Herding Code 213: Sean Trelford on Composing 3D Objects with F# and OpenGL

At NDC Oslo, Sean Trelford did a lightning talk on composing 3D objects using F# and OpenGL. Oh, and he’s 8 years old. Sean (and his dad, Phil) talk to Jon about learning coding with Small Basic and F#, and how it’s fun to learn coding by building video games.

Download / Listen: Herding Code 213: Sean Trelford on Composing 3D Objects with F# and OpenGL

Show Notes:

    • Hello
    • Sean’s Talk
      • (1:13) Jon asks Sean whether he showed slides or did live coding.
      • (1:39) Sean made an army from one 3D man model.
      • (2:09) Jon asks how difficult it is to call OpenGL from F#. Sean’s dad, Phil, explains how Sean used a domain specific language – about 50 lines of code. You can use it to create shapes like cubes and spheres, color them, transform them, etc.
      • (3:30) Phil explains how Sean used the F# REPL to create and modify 3D objects interactively, then used functional composition to put the parts (head, arms, legs) together to build the army man, the used functional composition and aggregation to create the army.
    • Learning Small Basic and F#
      • (4:37) Jon asks Sean if F# is his first computer language; Sean says he started with Small Basic. Jon asks if he found it difficult to move from Small Basic to F#, Sean and Phil explain how F# is actually a pretty natural step from Small Basic. Small Basic has no functions with parameters, so when they had a project that ran into that limitation they just moved the code from Small Basic to F# and used the Small Basic library to construct 2D shapes (leveraging WPF).
    • Fun Basic
      • (7:02) Phil said that last year he and Sean rewrote Small Basic as Fun Basic (available free in the Windows Store). It’s an IDE with IntelliSense, code completion, etc. It’s got backward compatibility with Small Basic, but includes function with arguments, pattern matching, etc.
    • Learning programming with video games
      • (8:02) Jon asks about what next for Sean. Recently they went to a game jam and made a platform game. Phil says the REPL environment is huge for game building.
      • (9:04) Jon mentions the IoT lab at NDC and asks Sean if he’s done anything with IoT; Sean says no. Jon says it seems like people try to get kids interested in coding with IoT, but maybe games are more fun to get started. Phil says that Sean’s got a Minecraft channel on YouTube. Jon asks Sean about making videos about making games.
      • (10:38) Phil says he got started on computers with games – he made his first game when he was 11, but his first commercial game was when he was 14 – Flint Eastwood.
      • (11:44) Jon asks Sean if this is his first time in Olso, and his first conference. It’s his first time in Oslo, and his first "speaking" oriented conference.
      • 11:28 Jon asks if they’ve got any last messages, maybe to encourage kids to get started with coding. Phil recommends the Hour of Code, as well as other resources online. Phil says his older son got into programming by adding levels to games, then writing scripts for AI’s, etc. Phil says that’s how he got started – looking at other peoples’ code and going from there. Don’t necessarily get hung up on fancy coding concepts, just script something and have fun!

Herding Code 211: James Mickens on The State of Computer Security and Bitcoin and Thomas Jefferson and Internet of Terrible Things and Prawns and Oslo’s Terrible Secret

While at NDC, Jon talks to James Mickens about his terrifying computer security keynote presentation.

TLDR you are doomed.

Download / Listen: Herding Code 211: James Mickens on The State of Computer Security and Bitcoin and Thomas Jefferson and Internet of Terrible Things and Prawns Oslo’s Terrible Secret

Show Notes:

  • Hello
    • (00:24) All is lost. Listen to Danzig.
  • Stop putting your money in Bitcoin
    • (01:00) James says it’s not a good place to put all your money unless you want to be poor.
    • (01:42) Bitcoin is a commodity, not a currency. Investing in commodities is hard. It’s not a stable place to put money. When it’s going up, the smart people are taking money out.
  • The legal system – and specifically Thomas Jefferson – won’t help you
    • (03:56) Judges and lawyers are very far removed from modern technology. Analogies to older forms of communications doesn’t work.
    • (04:44) Emojis are not telegrams. They’re incredibly terrible, though.
    • (06:30) Thomas Jefferson wouldn’t help with issues relating to iPhones. If your phone broke, would you take it to a really old person for help? Because Thomas Jefferson is a really, really old person.
  • The Internet of Terror
    • (08:10) The internet of things is the new cool buzzword, but nobody wants to reboot their house.
    • (09:17) The security story for the internet of things world is cartoonish. When your refrigerator starts sending spam, James will laugh at you.
    • (11:52) The first several generations of IoT houses will be terrible. Things will get better on a relative scale, but will always be terrible on an absolute scale.
  • Node.js
    • (13:32) James knows he’s in danger for dissing Node.js, but he can’t help himself.
    • (15:08) We’ll see the rise of the JavaScript Full Stack Developer, which could be powerful, but it’s also what Sauron wants.
  • Oslo
    • (16:10) Oslo is a wonderful city. It never gets dark, which makes you feel safe but if James was a criminal he would be all over the extended working hours.
    • (16:54) Shrimps are prawns, and unlike American shrimp they have legs and heads.
    • (18:06) French fries cost approximately one mortgage payment.
    • (19:42) James speculates on whether Oslo harbors some terrible secret. The condos look like lairs for James Bond villains.
    • (21:11) Jon saw a building with a big sign that said Edderkoppen, which he had recently learned means The Spider. Perhaps that is Oslo’s terrible secret?

Show Links:

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 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: