181: Databases and Interfaces

Sponsored by Sentry.io

Relying on customers to report errors is not good. It's rude to customers and bad for business.

Ideally, this would be solved easily with tests. Why not just cover every scenario with a test? Then life would be perfect and fine and great. Because here in reality, humans are pretty bad at writing tests. Not just because we’re all kinda lazy and maybe a little dumb, but also because we can’t anticipate every single way users are going to interact with our product. They might do something really, really, really stupid (or something really, really, really smart) that we didn’t think about.

That’s why Sentry tells you about errors in your code before your customers have a chance to encounter them.

Not only do we tell you about them, we also give you all the details you’ll need to be able to fix them. You’ll see exactly how many users have been impacted by a bug, the stack trace, the commit that the error was released as part of, the engineer who wrote the line of code that is currently busted, and a lot more.

Your code is broken. Let’s fix it together. Sentry.io.

Database design for mere mortals
Queries for mere mortals
Domain driven design
Crudry
Elixir macros
Elixir use
Elixir behavior (A set of common elixir functions)
Elixir protocol
Elixir module attributes
Bodyguard
Pundit
Ruby mixins
Metaprogramming Elixir by Chris McCord
Elixir 1.9
Exq
Declarative vs. Imperative programming
Elixir in Action

Leave us a review

Last but not least, if you haven't rated or reviewed the show yet and you'd like to do us a huge favor, you can do so by clicking here!

If you're looking for a link we've mentioned in the past, head on over to the Does Not Compute site! We've even included a search tool for you to use to find episodes that touch on specific topics.

If you have enjoyed the show so far, reach out to us on twitter at @seanwashbot and @Schrockwell, or join us in the Spectrum community at https://spectrum.chat/specfm/does-not-compute!