Hey! We’re still here. We had some technical difficulties, were waiting to release some shows for a sponsorship, the dog ate our collective homework. Sorry about that! We’ve got some good episodes ready for you, so this is just heads up.
(01:20) Jeremy’s shops really like using document databases because there’s a lot less friction to develop and ship your applications. They were having trouble with their document databases in production, though, so when they saw Postgres has JSON support they decided to build a client library on top of it so they’d have the developer productivity of a document database, but with the stability and tools that come with Postgres.
(03:24) K Scott mentions Jeremy’s recent blog post comparing the simplicity of building applications using a document database as opposed to using an ORM. Jeremy explains how document databases allow you to have a more evolutionary design that’s able to handle changes.
(04:35) K Scott asks about their recent use of Marten as an event store. Jeremy says they’re building up view projections that express the read side state of the application. The advantage of having them in Marten is that they’re just documents, and you don’t need additional infrastructure on top of your application document database.
(06:07) K Scott remarks on the great documentation and API design. Jeremy says that after years of abuse over his StructureMap documentation, he’s decided to make documentation a much bigger emphasis for this project.
(06:45) K Scott asks about how the documents are stored in the database. Jeremy says each document type has an underlying table with some metadata columns, and the main document is in a single JSONB column. JSONB is a Postgres data type that’s a binary representation of a JSON document that’s much more efficient for searching and querying.
(08:12) Jon asks about differences between BSON, JSONB, etc.
(12:22) Jon asks if he’d looked at Entity Framework. Jeremy says that due to differences in data structures, it’s a pretty different model. There’s nothing that prevents you from using Marten for documents in a Postgres database alongside EF or Dapper for relational tables in the same database.
(13:51) K Scott asked where Marten falls in transactional support, since document databases take pretty different views on that. Jeremy says that Marten is ACID all the way down – you can query for a document as soon as it’s committed, and you don’t need to deal with eventual consistency unless you opt into it for event store.
(15:12) K Scott asks about the testing story. Jeremy talks about his shop’s integration testing strategy, and that document databases are a lot easier to integration test than relational databases. From a unit testing perspective, they do some minimal mocking, but he recommends integration testing rather than unit testing in most places.
(17:42) Kevin asks about JSON patching support, since Postgres has support for that.
(18:48) K Scott asks about their use of Sqitch. Jeremy explains how it’s a simple database migration system using SQL semantics.
(22:02) Jon asks about the release notes mention of lowering memory usage. Jeremy says the main work was in minimizing serializing to JSON strings and using object pooling.
(24:04) K Scott mentions the successful release and active Gitter channel. Jeremy says this is the smoothest experience he’s had with an open source release.
(25:05) Kevin asks if there are other libraries out there that are making it easier to work with Postgres, and asks if there’s any hope of standardization across Postgres, Oracle, and SQL Server.
(27:22) Scott K asks about the main selling points of Marten on top of Postgres.
(28:22) Scott K asks if they’ve looked at cloud document databases as well, like DocumentDB. Jeremy explains that it’s pretty tied to Postgres.
(29:40) Scott K asks about best practices on querying. Jeremy says they invested a lot of time in performance optimizations, and talks about calculated indexes, calculated fields for complex structures, and Marten’s compiled queries in C# code (which bypass compiling LINQ queries). The npgsql library they run on top of also supports batching, which can give you big boosts in chatty applications. There’s also support for including related fields in one database roundtrip.
(34:04) K Scott asks about Alba. Jeremy talks about the need their shop has for unit tests that run the full HTTP request cycle without hitting a webserver. This allows you to test the full end to end output for cases where you have filters, caching, middleware, etc. It was originally inspired by the Play framework in Scala.
(38:33) Jon asks when it makes sense to move from the ASP.NET Core test host to use Alba. Jeremy says that it’s mostly a matter of preference, but Alba does a good amount of legwork for you for things like routing.
(39:52) K Scott asks how Alba fits in with integration tests with Selenium. Jeremy says he’d really just want to use Selenium when there’s some significant UI functionality, but for the most part he’d avoid it as much as possible and use Alba.
(41:00) Jon asks about Jeremy’s experiences in porting to .NET Core. Jeremy says that the newer projects were straightforward, but his older projects that had a good amount of reflection were really hard. He’s sorry to see project.json go, and he things the dotnet CLI is worth upgrading just about on its own since it makes automation almost trivial.
Changes in the .NET Open Source world
(43:47) K Scott circles back to ask about Jeremy’s comments about Marten being the most positive experience he’s had with .NET open source. Jeremy says the .NET open source ecosystem is a lot more positive and helpful. Marten fills a pretty good niche that many people found helpful. Jeremy says that he’s seen the user community become a lot more collaborative compared to previously treating open source maintainers as product support. Jeremy says he also gets pull requests for documentation, which is something he’d never expect a few years ago.
(46:26) Kevin asks about Jeremy’s thoughts on turning StructureMap over to someone else. Jeremy says it’s been 14 years, people use it in ways he wouldn’t expect, ASP.NET Core has a built-in IoC Container, and it’s hard to make StructureMap work with the ASP.NET Core IoC requirements. The project is still viable and continuing, it’s just going to be better for everyone under new ownership.
(49:15) Frank asks on Twitter “Why so much hate for Scrum?” Jeremy talks about the ceremony and tracking in Scrum take all the joy out of Agile programming. Jeremy says Scrum is the Scrappy Doo of the Agile Programming world.
(54:05) K Scott asks about Jeremy’s post: Thoughts on Agile Database Development. Jeremy says that relational databases have long been the final frontier of agile development, and the database community has resisted agile development.
(56:42) K Scott asks what Jeremy’s up to, and Jeremy talks about his next release in May: a human.
(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.