(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.
(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.
(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.
(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.
(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 graphql.nodal.com 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.
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.
(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.
Deploying ASP.NET applications to Windows Containers with Docker
(00:30) Ben Hall gave a talk at NDC London in which he deployed Nerd Dinner and MVC Music Store 2.0 to Docker using Windows Containers.
(00:52) Jon says that Docker has been primarily Linux focused and asks how Windows fits in here. Ben explains the history of Docker and Windows Docker support on Windows Server.
(01:40) Jon asks how this works if you’re not developing on Windows Server.
(02:23) Jon asks why anyone would want to deploy Windows based applications using Docker. Ben talks about some advantages, including automation, tooling, and a standard approach to packaging and deploying applications – including applications that weren’t built with any thought of containers or automated deployment.
(04:30) Jon says that all the hype he’s seen related to ASP.NET on Docker are talking about ASP.NET Core. Ben talks about why non-Core apps on Docker are relevant.
(05:29) Jon asks how this compares to the traditional approach to just deploying using Hyper-V and full virtual machines. Ben describes some of the inefficiencies and just general heaviness around deploying an entire VM for an application, vs. lightweight container. Ben and Jon talk about some of the benefits, including deployment documentation as executable source code. Ben talks about the advantages of automating deployment of a set of resources using Docker Compose, as well.
(09:32) Jon asks about the different choices he’s got, including Windows Server Core and Windows Nano Server. Ben sorts him out.
(11:20) Jon asks how Hyper-V containers fit in. Ben talks about the security and isolation advantages due to having a separate kernel, especially when you’re dealing with a multi-tenant scenario.
(13:20) Jon asks about Ben’s recent experience with this due to deploying Katacoda. Ben describes how Katacoda, an online interactive learning platform for software developers. It leverages Docker to allow you to give you a terminal in a web page to let you start hacking and learning quickly.
(14:14) Jon asks about the business model for Katacoda. Ben explains that their main model is working with vendors, making it easier for their customers or potential customers to try out products with no install. They’re also working on versions for training, which eliminates the time and uncertainty of getting everyone’s machine configured.
(15:18) Jon asks what’s next, and Ben says the next big thing is Azure Container service – using Kubernetes to configure clusters across operating systems, optimizing for cost, etc.
What do you do for fun?
(16:20) Jon asks what Ben does for fun, and Ben reminds him that he runs a startup.
(00:30) Jon asks Rob about his presentation at NDC London. Rob’s talk started by describing how he got fired from a job by trying to do something that was NP-Hard. This past year he dug into understand complexity theory, mostly from the point of view of just recognizing the pitfalls. He once wrote a co-occurrence query for just two products (two products that are bought together frequently), and that worked just fine. However, trying to write a co-occurrence query for three or four products doesn’t work because it’s exponentially hard.
(02:23) Jon asks about the different classes of problems. Rob explains the terms, starting with polynomial time (P) problems, then talking about exponential and factorial complexity.
(04:10) Jon talks about how Rob’s co-occurrence query was exponentially hard, but for just two products it worked fine. Rob continues with his example from his talk about finding the best place for a group of people to go – that’s NP-Hard. But if there are only two people, you can handle it. You can get into solving some harder problems using concurrency and throwing machines at the problem, but you should understand it.
(5:10) Rob explains how ideas like page rank fit in, by using authority as a heuristic. Heuristics can be use used for other problems, like the travelling salesman – they won’t give you the provably best solution, but they will reliably give you a very good answer.
(7:45) Jon asks about the difference between decisions and optimizations. Rob explains that decision problems are NP-Complete problems – if you can represent a problem as a long boolean statement, it’s a boolean satisfiability problem. He describes how optimization problems
(10:12) Jon asks about Rob’s recent book, The Impostor’s Handbook. Rob explains why he wrote it, and the current audio / video updates he’s making for it.
(11:40) Jon mentions how there’s a lot more to the book than complexity theory, and Rob explains how it’s all related – complexity theory, foundations of computing, lambda calculus, etc. Jon asks Rob why he likes lambda calculus so much, and Rob talks about a presentation he really liked by Jim Weirich in which he built a y combinator, and he talks about some examples from his book using a y combinator in ES6 to do things like fibbonaci series.
(14:00) Rob’s book, The Impostor’s Handbook, is available at bigmachine.io.
(02:00) Jon comments on the star power among the contributors to HT. Richard calls out Shawn Wildermuth’s contributions and how he’s been applying his version update experience from his coursework to the project. HT got its start as the example project for the Visual Studio 2015 launch.
(04:04) Jon remembers to ask Richard to explain what HT is: open source software for disaster relief organizations. Richard was motivated by the realization that it’s hard for software developers to donate their skills to charity because software comes with an ongoing maintenance cost.
(05:35) Scott asks for a description of what the software does. Richard says Humanitarian Toolbox is a collection of projects, and they’re initially focused on the allReady project. allReady started to help the Red Cross organize and coordinate smoke detector installation efforts to prevent home fire disasters. Software can help through things like mapping, mobile apps, and Twilio based notifications. Just the simple addition of reminder notifications before going out to install smoke detectors has raised their install rate from about 30% to about 80%.
(09:00) AllReady is an ASP.NET Core web application using some default Bootstrap theming, and could definitely use some designer help. They work with the Red Cross to provide domain expertise. They’ve had some field trials, but are just now rolling it out broadly to the field now.
(11:35) Scott says that it sounds like HT is a little different from the drive by pull request model that’s common in the open source world. Richard says that pull requests really should start as an issue and a discussion before the pull request. They’ve consciously grouped issues so they can be managed at hackathons as well as milestones for releases.
(13:12) Jon notes that many open source projects evolve a pull request at a time and often don’t have a clear high level architecture. Richard says they’ve put some effort into architecture and hosting, with the realization that they’ll probably be hosting and maintaining the applications. He says that it’s great to be able to work directly with folks like Dominick Baier for IdentityServer, Jon Skeet for NodaTime, etc.
(14:55) Scott asks about a point Richard had made in his keynote about all the IoT devices we’ve got, but not enough software to go around. Richard says he doesn’t want the disaster relief heroes spending money on software. They don’t understand the impact mobile and cloud can have on their work, and we can help them. He talks about the possibilities for crisis check-in and citizen disaster evaluation using things like social media for things like bridge damage evaluation. There’s so much to be done, the job requires prioritization and building things in a sustainable way.
(18:32) Scott asks about how people can get involved; Richard points to htbox.org.
(19:12) Jon doubles back to the interaction pattern Richard talked about earlier with issues leading to discussion, then pull requests. Richard also refers to the weekly hangouts, where discussion and collaboration also happen.
(20:39) Scott asks what kind of help they could use. Richard says they’ve got a lot of people working on the ASP.NET Core side of things, but need more mobile development help.
Gadgets and Idle Chatter
(22:00) Scott asks Richard what his latest gadgets are. Richard talks about his new Dell 43 inch 4K monitor.
(23:30) Jon asks about Richard’s office remodel project, including LED lighting.
(25:30) Scott asks Richard what he’s doing when he’s not working. Aside from running a charity, he likes to get off the grid an hike in the Himalayas.
Jon and Kevin talk to Gary Ewan Park and Mattias Karlsson about Cake, a cross platform build automation system with a C# DSL to do things like compiling code, copy files/folders, running unit tests, compress files and build NuGet packages.
(01:48) Jon asks about the integrations and CI support. Gary says that’s a key feature: the build you run on your development machine is going to be as close as possible, if not identical to, the build you’re going to run on your CI server. Right now, Cake is set up with at least 10 online CI servers, which has the added benefit of providing them with a ton of badges for their GitHub readme.
(03:15) Jon says that he cloned the getting started repo and ran a script and some magic happened… but what exactly was that magic doing? Mattias explains that the bootstrapper (either build.ps1 or build.sh) fetches Cake from NuGet, then it launches the build.cake file.
(04:07) Jon asks if PowerShell on Linux will have an impact on Cake, or if the build.sh is simple enough that they’ll just stay with that. Gary says that the bootstrappers are very lightweight and normally don’t need to be changed (although you can if you want), so there’s no real advantage to moving to PowerShell since people who are building on Mac and Linux will probably prefer to just run a shell script.
(05:17) Kevin flips it around and asks if it matters for Bash on Windows. Gary says they’ve got this one covered, too, as they’ve already tested out Cake on Bash on Windows. Mattias says the hard part is the platform specific dependencies, and Gary agrees, saying that Cake is just a wrapper around the tools – there’s an expectation that the tools are either installed or available as a NuGet package.
(06:55) Jon asks if tools are well segmented per-project. Mattias confirms that everything is project specific – you can share if you want, but the default is that you can just clone a repository and build without thinking about dependencies.
(07:50) Jon asks how Cake works with Docker. Mattias talks about the preconfigured Docker images for Cake, which make it easy to easily test builds, handle integration tests, etc. He’s currently testing against Nano Server. Nano Server is very stripped down requires you to install a lot of prerequisites for Cake, so it’s nice to have a preconfigured Docker image for testing. Mattias talks about how versioning with tagged containers help them with integration testing. Gary talk about how they’re using Docker with Bitbucket Pipelines to really speed up their Travis build tests.
(10:25) Jon asks what a Cake script is – is it just C# code? Gary describes some of the additional build DSL features they’ve added, but other than that it’s just standard C# code.
(13:30) Jon said that he opened the Cake file in Visual Studio code and saw there was an extension for syntax highlighting, and asks if there’s additional tools for IntelliSense. Gary talks about the current status of OmniSharp when running against Cake. Note that since this podcast was recorded, this has improved as explained in this blog post: How to debug a Cake file using Visual Studio Code.
(15:28) Jon asks about debugging a Cake script. Mattias says they’ve added a debug switch to the Cake exe, which waits for you to attach so you can debug. Jon says it sounds great to have debugging support for a build script. Mattias says it’s nice, but since your build scripts are often running on build server it’s also important to have good logging support.
(17:02) Jon asks what the logging support is. Mattias says there’s a built-in abstraction for logging as well as an exception handler, so to break the build you can just throw an exception. Gary say that the default is just to log to the build server like AppVeyor, but if you want to log to something like logstash you can. Mattias says that they log to standard output and standard error, and every build system integrates well with that.
.NET Core support, DI and Modules, Cross-platform Support
(18:06) Jon asks more about the .NET Core port. Mattias says they’re just about done, just working with integration tests. For the most part it’s pretty straightforward, but you can run into things like differences between kernel versions on Linux. The biggest issue has been waiting for dependencies to be available on .NET Core. In the past they’ve relied on Mono for Linux and Mac, and there are slight differences compared to the .NET Framework, so it will be good to be on Core CLR everywhere. (note: the port to .NET Core has since been completed).
(19:52) Jon says he notices they’re using Autofac. Mattias says they use it for dependency injection throughout the codebase, but they’ve replaced it in some places for things like their module system.
(20:33) Jon asks how the module system works. Mattias says you just add a module folder in your tools and implement some attributes on your interfaces that indicate what your module should replace. (22:17) Jon asks about any issues they ran into with the .NET Core cross-platform port. Mattias says there are a lot of dependencies you don’t think about – for instance nuget.exe isn’t available cross-platform or on Nano Server, since it only has the Core CLR. Gary says they made a conscious decision not to implement .NET Core early, so they avoided some of the early adopter pain that some other projects ran into.
(23:47) Jon asks if they’re doing anything specific to handle platform differences. Mattias says that there are a few IFDEFs, but for the most part issues are around tools support, in which case it just won’t launch at all. Gary talks about platform specific criteria you can use in your build scripts to make platform specific decisions.
Cake Tasks, Parallel Tasks, Build System Integration, Unit Tests
(26:36) Jon asks how task names are used in a script. Mattias says that those labels are used to determine task dependencies. Gary says you can also use the labels as entry points which are specific to the build server.
(28:22) Jon asks if tasks are run in parallel. Mattias says it’s not currently multithreaded because logs would be difficult to follow. When you define a task, it’s just added to the graph, and nothing’s actually executed until you call RunTarget. Gary said there is an open issue to allow parallel execution of tasks, but they’re still working on a good story around debugging and logging. Mattias says it’s standard C# so there’s noting stopping you from running async tasks using the standard C# async methods.
(31:46) Jon says he sees support for several build systems and asks about how you integrate with them. Mattias explains how CI systems can call commandline options, and Gary says that all build systems have provisions for environment variables, and Cake provides a typed wrapper around that, so you get a strongly typed object from the build-specific provider to make informed decisions. For instance, when running on AppVeyor their script pushes the NuGet packages to the prerelease MyGet feed from the development branch and the official NuGet feed when running on release.
(34:09) Jon asks about assembly info patching and versions. Cake can update based on version info. It’s got file hash support, which is important for pushing to Homebrew.
(34:55) Jon asks about unit test integration. Gary says they have method aliases for calling common unit test frameworks, and you can easily extend for other frameworks. Unit test harnesses have published return values, so you can make informed decisions based on specific unit test results.
Publishing, Installers, Release Notes
(36:46) Jon asks about publishing options. Cake can build the nuspec for you, you can use your own if you want, or on Core CLR you can use dotnet pack. Jon asks about some of the different ways NuGet is used as a deployment package. (38:42) Jon asks about other installers like WiX, NSIS, etc. Gary says that Cake is really just wrapping tools with strongly typed classes, which makes it easier to pass in property values to tools. There’s no real magic, it’s just bringing it up an abstraction layer, so you don’t have to remember the command semantics of each tool. Jon asks if, in addition to simplifying how you interact with tools, the abstraction makes it a little easier to switch between tools. Gary says that’s true, and describes how this works in practice.
(41:44) Jon asks about the release note parsing feature. Gary says there’s an included release notes parser, which can extract version numbers and bulleted release features from a markdown file assuming it’s in a known format. This allows you to stamp your assembly with the version number, and use the bulleted release notes in your NuGet or Chocolatey release notes. There are also Git Release Notes and Git Release Manager which can be used to generate release notes from issues in a milestone based release on GitHub. Gary says they use this with Cake releases, so just tagging a release gives them an end to end publish process which sets version numbers and writes release notes for all their release endpoints (NuGet, Chocolatey, GitHub release, etc.).
(44:54) Jon asks about the social network support. Gary and Mattias explain how the different addins can announce builds to Twitter, Slack, Gitter, Hipchat, etc. They describe how things like this that are useful but not essential are available as addins.
(46:28) Kevin asks if there are any addins that they see as missing. Gary says there aren’t at the moment. He’s got a generic build script for all of his addins, so adding to the script rolls out to all of his addins.
(48:08) Jon asks about the discussion in their repo: How do we prevent Addin’s becoming stale? Gary talks about the problem (a community member creates a useful addin, then stops maintaining the addin). Their plan is to set up a cake-contrib organization which can help with long-term ownership and support for community addins, allowing them to push NuGet updates as required if the original creator is no longer available or involved. The plan is to ask users to move their addins into the new cake-contrib organization and make the cake contrib user a co-maintainer. Note: Since this was recorded, they’ve set up this organization, as discussed in the wrap-up after the show.
Open Source Project Case Studies: NancyFx and IdentityServer
(53:14) Jon asks about some of the open source project build conversions to Cake, starting with NancyFx. Mattias explains some of the challenges, as well as the clear payoff: build script pull requests very soon after the conversion. Jon asks some nitpicky details about why the NancyFx build script script is spawning a process instead of using a Cake wrapper. Mattias explains the process by which build scripts are refined, and Gary points out the advantage of always being able to spawn a process if you need to do something Cake doesn’t yet support.
(57:43) Jon asks about the IdentityServer migration. Gary said the IdentityServer team had already done the .NET Core port running under PSake and just wanted to migrate to Cake to get cross-platform builds going. It’s also a lot simple of a build process because it’s doing less.
(58:50) Jon asks about ilmerge suport. Mattias says it’s pretty popular for tools, to allow you to distribute the tool as a single exe. Gary says he uses Fody Costura instead to handle assembly merging. Jon says he doesn’t think any assembly merging support is available yet for .NET Core. Gary agrees, and Mattias says that .NET Native support will be helpful when it arrives.
Future Plans and Getting In Touch
(1:00:08) Jon asks about future milestones and what’s on the horizon after the .NET Core release. Gary hints at some upcoming releases, which are covered in the post-show wrap-up.
(1:01:20) Gary talks about some upcoming speaking engagements, and Mattias mentions the Gitter chat, Twitter and GitHub issues as ways for users to ask any questions.
(1:03:10) Cake Contributions organization The Cake Contributions organization (cake-contrib on GitHub) is now in full motion. It’s a common place where people can put their Cake addins & modules, if they want. They still maintain and for all purposes “own” the code, but they get access to resources like CI services, common build scripts, better exposure and the Cake core team can assist with merging pull requests, fixing issues and pushing to NuGet if addin grows stale or the author just too busy with life in general. It’s been well received and quite a few projects has moved over.
(1:03:52) 0.16 Release with .NET Core support So in addition to full .net Framework support, Cake now supports .NET Core (netstandard 1.6). There have been a few patch releases following this, so as of Oct 11 they’re up to 0.16.2. Also, due to adding .NET Core support, it’s now possible to debug a Cake file with Visual Studio Code. That’s cool, because there’s now cross platform debugging support for Cake. There’s a blog post showing how to do that.
(1:04:25) Frosting Frosting is a stand-alone .NET Core runner and host for cake. Cake uses the Roslyn scripting API and provides a DSL for fetching dependencies like tools and addins. Frosting uses the .NET core SDK to handle dependencies, and your cake build script is really just a .NET Core console app. Both are running against the same Cake.Core and Cake.Common packages, they’re just being hosted differently. This gives you some advantages – you’ve got full Visual Studio IntelliSense and tooling support, use the standard methods to package your build as a NuGet package, etc. Frosting also includes a dotnet CLI tool, so you can call dotnet cake.
(1:05:46) Cake for Yeoman support This adds a cake generator which makes it easy to bootstrap Cake, including a build script, bootstrapper scripts and config files in the current directory just by typing yo cake. There’s also scaffolding support to create a new .NET Core project using Frosting with yeoman.
(1:06:18) Cake for Visual Studio This is the first release of the Cake for Visual Studio extension. It includes syntax highlighting, Task Runner Explorer integration, bootstrapper commands in the Build menu, project templates for Cake addins, Cake Addin unit test projects, and Cake Modules
Rob’s advice would be great if people wrote stored procedures the same way they wrote normal statically typed code using C# or Java. But they don’t, they tend to cram every possible path for the business logic can take into a single stored procedure, making it hard to understand, hard to maintain, and fragile.
Everyone has heard or had to deal with that kind of stored procedure. Written years ago, the authors have moved on to another job, everyone shudders at the thought of having to modify it. Then one day, it stops working, maybe it’s due to a change in the underlying table, maybe a new business requirement came up that requires a new kind of data to be passed to the procedure.
ORM’s were originally created so that:
a) We could stop writing 4 different stored procedures for every object in our programs.
b) So that we could normalize our data in the database and then create object models in our application code that represented business concerns rather than the most efficient way to store data.