(00:17) Jon G asks Jon Skeet about what he does at Google and how it relates to .NET. Jon’s working to make the Google Cloud Platform great for .NET developers. This is two-fold: if you’re a .NET developer he’d like GCP to be a great place for you to host applications, and if you’re a GCP developer he’d like .NET to be an obvious choice for you to build your applications.
(01:50) Jon G asks about what languages GCP supports, and how .NET fits in. Jon Skeet says it’s an obvious fit on the server-side, and he also sees that .NET has a great cross-platform and device story for clients. .NET Core landed at a great time for them to embrace it.
(03:59) K Scott asks what came first: the decision to embrace .NET, or .NET going open-source / cross-platform.
(05:15) Jon G asks for a quick Google Cloud Platform for Azure developers overview.
Feminism for Geeks
(08:22) K Scott asks about Jon Skeet’s “Code Like A Girl” shirt. Jon S talks about his recent interest in feminism. Jon Skeet talks about
(12:35) Jon G talks about worries about “doing the wrong thing” in trying to help. Jon Skeet talks about lessons he’s learned and gives some great advice.
Note: This was recorded several months ago. Our site was offline for a while, the dog ate our collective homework, etc. Sorry about that. The main thing that’s changed since we recorded was the addition of user profiles.
(00:17) Kevin introduces the Daniel X Moore and Jenn Schiffer and asks what Glitch is. Daniel explains how Glitch is different: you can create or remix a web app instantly without needing to setup or configure anything.
(03:38) Jon likes the way that the getting started video references the whole view-source culture of the early web. Jenn talks about the value of removing the fear of breaking things when you’re getting started.
Why did you make Glitch, and why now?
(04:20) Kevin asks what led to the creation of Glitch. Daniel talks about how he’s been tinkering with pixel editors and online tools to make weird things for a long time, but finally the tools, browsers, and community have matured to a point where tools like Glitch are viable. Jenn points out that at least three members of the team that have made art editor apps and like to make weird stuff that you didn’t know you needed but you really do.
User experience overview of building a new Glitch app
(06:40) Jon asks about the experience of creating a Glitch app. Daniel talks us through as he creates a Slack bot app live while we listen in a few seconds. He points out that you start with some working code rather than having to build up from nothing.
GitHub integration
(09:10) Jenn says that there are apps like simple static site generators that are useful even if you don’t know anything about coding, don’t want to deal with deploying, etc.
(10:30) Daniel says you don’t need to set up an account and log in to get started. Jenn says that you can log in with GitHub or Facebook, and you can easily import from and export to GitHub so you’re not locked into anything. Daniel says anything that works well on Glitch should work on Heroku, AWS, etc.
(13:06) Kevin asks if the GitHub import is live, so changes to the repo will affect the live site.
(13:40) Kevin asks about the live update features. Daniel says that they’ve got things down to around 1 second latency to see your changes live, and how the development experience has changed as the latency improved.
Nerdy tech stuff about how they actually built it
(15:10) Jon asks for more info about how recent browser technology changes have made it possible to build Glitch.
(16:32) Jon asks about the backend. Daniel explains how things are wired up using Docker containers, web socket connections and magic.
(19:30) Jon asks about how things are sandboxed so one app doesn’t affect others users.
(20:55) Kevin and Jon ask for information about how many apps have been built, how many are actively used, etc. Daniel gives some high level info and talks about some popular apps like a Twitch proxy.
Glitch for teaching new users
(24:25) Jon asks if people use Glitch to teach coding at in-person classes. Jenn talks about some examples of courses, including online courses like A-Frame. Jenn says that she likes focusing on teaching one thing rather than complicating it with also teaching deployment. Daniel talks about the excitement of making a change, seeing the result, and having a positive feedback cycle quickly. Daniel and Jenn talk about how the simplicity of Glitch lets people build things that people would even build otherwise.
(29:22) Jon asks how Glitch fits in with tools like Codepen. Jenn talks about different ways people use Glitch for sketching and sharing app ideas.
Nerdy stuff like licenses, rollback, secret storage, embedding
(30:55) Jon asks if there’s a license for the code and how it works with remixing. Jenn says you can include a license file, but they don’t want to complicate people early on.
(33:25) Kevin asks if there’s support for rolling back in case you break a live app.
(35:30) Jon asks how things like API keys and passwords are handled so you’re not accidentally checking them in to GitHub. Jenn and Daniel talk about Glitch features to integrate with APIs and services.
(40:20) Jon asks if it’s possible to just iframe a Glitch app to build something like a Twitter app.
The Glitch logo is friendly and approachable. They’ve put a lot of thought into being friendly to new users.
(41:20) Jon asks for more detail about the Glitch fish logo. Jenn and Daniel talk about it, then go on to explain how they’ve designed the Glitch interface to make it friendly and approachable. There’s an interesting discussion of how that goes into tutorials, teaching. Daniel talks about how there’s so much stuff out there that no one is an expert, and Jenn talks about she thrives on being overwhelmed and loves to be able to sketch and prototype in Glitch to experiment with new things.
(51:35) Jon says he’d like to be able to click on users names to see their profile information. Daniel and Jenn talk about things they’re working on in that space. UPDATE: User profiles on Glitch have shipped since we talked.
(53:25) Jon says he really likes that their getting started tutorials have a lot of games, and he’s seen that kids really like to learn with games. Jenn says that kids are natural storytellers, and gravitate to games and art focused apps.
A JavaScript joke
(55:00) Jon asks if they have any JavaScript jokes.
What’s next and wrapup
(56:15) Jon asks what’s next. Jenn is heading out on the road to talk to people and thinking about community things like making it easy to ask for help. Daniel is working on new features like versioning, rollbacks, branching, etc.
(58:20) Jon asks if there’s something like Glitch Enterprise on the way that will result in features being turned off or something. Jenn references Anil’s post on How we won’t screw up Glitch. Daniel and Jenn talk about some potential additional features that people might want to pay a reasonable amount for, in the “pennies a month” range.
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.
(09:12) Jon asks what the main reasons for using Marten over just storing documents in JSONB. Jeremy says the LINQ provider is a lot more user friendly and productive than parsing through JSON yourself. There’s also the unit of work which gives you transactional semantics, there’s database migration tooling that handles things like foreign key changes. Strong expression typed support, calculated indexes, and working with the in-database JavaScript support to map data in the database.
(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.
(20:35) Kevin has a question about data migrations for updating existing documents. Jeremy recommends using their patching API for that; if you can’t do that use JavaScript in the database.
(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.
StructureMap
(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.
Misc Questions
(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.
(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.
(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.
(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 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.
 (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.