Herding Code 227: Rob Ashton on Better Coffee Through Science

Download / Listen: Herding Code 227: Rob Ashton on on Better Coffee Through Science

While at NDC Oslo, Jon talked to Rob about how he and the Tame Baristas crew make amazing coffee.

Topics:

  • What’s the deal with Tame Baristas and making coffee at software conventions?
  • Ensuring consistency – precise weights, equipment
  • The imporance of a quality coffee grinder (he uses an EK43)
  • Freezing coffee – actually a good thing?!?
  • What’s the deal with pour over coffee?
  • What’s the best way to up your home coffee game on a budget?
  • What do you do when you’re not making coffee? Spoiler: Elm and Erlang.

Herding Code 226: Jon Skeet on .NET at Google and Feminism for Geeks

Download / Listen: Herding Code 226: Jon Skeet on .NET at Google and Feminism for Geeks

Show Notes:

  • .NET at Google
    • (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.

Herding Code 225: Glitch with Jenn Schiffer and Daniel X Moore

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.

Download / Listen: Herding Code 225: Glitch with Jenn Schiffer and Daniel X Moore

Show Notes:

  • Hello. Who are you and what is Glitch?
    • (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.
    • FIN

Herding Code 224: Jeremy Miller on Marten, Postgres and Alba

The gang talks to Jeremy Miller about some of his open source projects.

Download / Listen: Herding Code 224: Jeremy Miller on Marten, Postgres and Alba

Show Notes:

  • Marten
    • (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.
  • Alba
    • (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.
    • (51:22) Jon asks about Jeremy’s recent post: The Different Meanings of “I take pull requests”. Jeremy reviews them from the most positive to the most negative.
    • (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.