Software Sessions
Jeremy Jung
Subscribe
Practical conversations about software development.
Available episodes
Newest first
Oldest first
Mar 2, 2023
Luca Casonato on Deno
Luca Casonato is the tech lead for Deno Deploy and a TC39 delegate.
Deno is a JavaScript runtime from the original creator of NodeJS, Ryan Dahl. Topics covered:
* What's a JavaScript runtime
* How V8 is used
* Why Deno was created
* The W3C WinterCG for server-side JavaScript
* Why it's difficult to ship new features in Node
* The benefits of web standards
* Creating an all-inclusive toolset like Rust and Go
* Deno's node compatibility layer
* Use cases for WebAssembly
* Benefits and implementation of Deno Deploy
* Reasons to deploy on the edge
* What's coming next Luca
* Luca Casonato
* @lcasdev Deno
* Homepage
* Deploy
* Showcase
* Subhosting
* Fresh web framework
* The anatomy of an Isolate Cloud Deno Users
* Netlify Edge Functions
* Deno at Slack
* GitHub Flat Data
* Shopify Oxygen Other related links
* Cache Web API
* V8 (JavaScript and WebAssembly engine)
* TC39 (JavaScript specification group)
* Web-interoperable Runtimes Community Group (WinterCG)
* Cloudflare Workers (Deno Deploy competitor)
* How Cloudflare KV works
* CockroachDB (Distributed database)
* XKCD Standards Comic Transcript
You can help edit this transcript on GitHub.
[00:00:07] Jeremy: Today I'm talking to Luca Casonato. He's a member of the Deno Core team and a TC 39 Delegate.
[00:00:06] Luca: Hey, thanks for having me. What's a runtime?
[00:00:07] Jeremy: So today we're gonna talk about Deno, and on the website it says, Deno is a runtime for JavaScript and TypeScript. So I thought we could start with defining what a runtime is.
[00:00:21] Luca: Yeah, that's a great question. I think this question actually comes up a lot. It's, it's like sometimes we also define Deno as a headless browser, or I don't know, a, a JavaScript script execution tool. what actually defines runtime? I, I think what makes a runtime a runtime is that it is a, it's implemented in native code.
It cannot be self-hosted. Like you cannot self-host a JavaScript runtime. and it executes JavaScript or TypeScript or some other scripting language, without relying on, well, yeah, I guess it's the self-hosting thing. Like it's, it's essentially a, a JavaScript execution engine, which is not self-hosted.
So yeah, it, it maybe has IO bindings, but it doesn't necessarily need to like, it. Maybe it allows you to read the, from the file system or, or make network calls. Um, but it doesn't necessarily have to. It's, I think the, the primary definition is something which can execute JavaScript without already being written in JavaScript. How V8 and JavaScript runtimes are related
[00:01:20] Jeremy: And when we hear about JavaScript run times, whether it's Deno or Node or Bun, or anything else, we also hear about it in the context of v8. Could you explain the relationship between V8 and a JavaScript run time?
[00:01:36] Luca: Yeah. So V8 and, and JavaScript core and Spider Monkey, these are all JavaScript engines. So these are the low level virtual machines that can execute or that can parse your JavaScript code. turn it into byte code, maybe turn it into, compiled machine code, and then execute that code. But these engines, Do not implement any IO functions.
They do not. They implement the JavaScript spec as is written. and then they provide extension hooks for, they call these host environments, um, like environments that embed these engines to provide custom functionalities to essentially poke out of the sandbox, out of the, out of the virtual machine. Um, and this is used in browsers.
Like browsers have, have these engines built in. This is where they originated from. Um, and then they poke holes into this, um, sandbox virtual machine to do things like, I don't know, writing to the dom or, or console logging or making fetch calls and all these kinds of things. And what a runtime essentially does, a JavaScript runtime is it takes one of these engines and.
It then provides its own set of host APIs, like essentially its own set of holes. It pokes into the sandbox. and depending on what the runtime is trying to do, um, the weight will do. This is gonna be different and, and the sort of API that is ultimately exposed to the end user is going to be different.
For example, if you compare Deno and node, like node is very loosey goosey, about how it pokes holds into the sandbox, it sort of just pokes them everywhere. And this makes it difficult to enforce things like, runtime permissions for example. Whereas Deno is much more strict about how it, um, pokes holds into its sandbox.
Like everything is either a web API or it's behind in this Deno name space, which means that it's, it's really easy to find, um, places where, where you're poking out of the sandbox. and really you can also compare these to browsers. Like browsers are also JavaScript run times. Um, they're just not headless.
JavaScript run times, but JavaScript run times that also have a ui. and. . Yeah. Like there, there's, there's a whole Bunch of different kinds of JavaScript run times, and I think we're also seeing a lot more like embedded JavaScript run times. Like for example, if you've used React Native before, you, you may be using Hermes as a, um, JavaScript engine in your Android app, which is like a custom JavaScript engine written just for, for, for React native.
Um, and this also is embedded within a, like react native run time, which is specific to React native. so it's also possible to have run times, for example, that are, that can be where the, where the back backing engine can be exchanged, which is kind of cool.
[00:04:08] Jeremy: So it sounds like V8's role, one way to look at it is it can execute JavaScript code, but only pure functions. I suppose you
[00:04:19] Luca: Pretty much. Yep.
[00:04:21] Jeremy: Do anything that doesn't interact with IO so you think about browsers, you were mentioning you need to interact with a DOM or if you're writing a server side application, you probably need to receive or make HTTP requests, that sort of thing.
And all of that is not handled by v8. That has to be handled by an external runtime.
[00:04:43] Luca: Exactly Like, like one, one. There's, there's like some exceptions to this. For example, JavaScript technically has some IO built in with, within its standard library, like math, random. It's like random number. Generation is technically an IO operation, so, Technically V8 has some IO built in, right? And like getting the current date from the user, that's also technically IO
So, like there, there's some very limited edge cases. It's, it's not that it's purely pure, but V8 for example, has a flag to turn it completely deterministic. which means that it really is completely pure. And this is not something which run times usually have. This is something like the feature of an engine because the engine is like so low level that it can essentially, there's so little IO that it's very easy to make deterministic where a runtime higher level, um, has, has io, um, much more difficult to make deterministic.
[00:05:39] Jeremy: And, and for things like when you're working with JavaScript, there's, uh, asynchronous programming
[00:05:46] Luca: mm-hmm. Concurrent JavaScript execution
[00:05:47] Jeremy: So you have concurrency and things like that. Is that a part of V8 or is that the responsibility of the run time?
[00:05:54] Luca: That's a great question. So there's multiple parts to this. There's the part, um, there, there's JavaScript promises, um, and sort of concurrent Java or well, yes, concurrent JavaScript execution, which is sort of handled by v8, like v8. You can in, in pure v8, you can create a promise, and you can execute some code within that promise.
But without IO there's actually no way to defer time, uh, which means that in with pure v8, you can either, you can create a promise. Which executes right now. Or you can create a promise that never executes, but you can't create a promise that executes in 10 se…
playlist_add
Jan 10, 2023
Megan Cutrofello on Leaguepedia
Leaguepedia is a MediaWiki instance that covers tournaments, teams, and players in the League of Legends esports community. It's relied on by fans, analysts, and broadcasters from around the world.
Megan "River" Cutrofello joined Leaguepedia in 2014 as a community manager and by the end of her tenure in 2022 was the lead for Fandom's esports wikis.
She built up a community of contributing editors in addition to her role as the primary MediaWiki developer.
She writes on her blog and is a frequent speaker at the Enterprise MediaWiki Conference Topics covered:
* When to use MediaWiki
* Visual vs code editor
* MediaWiki's rough syntax
* Templates and markup
* Limiting user input to simplify pages
* Choosing not to transliterate long player names in certain languages
* Handling mobile clients
* Building aliases for search results
* Creating a single source of truth
* Roster changes and caching
* Cargo (Query data in MediaWiki templates using SQL)
* Hiding implementation details from editors
* Optimizing for the editor, not a clean codebase
* Training your users to use workarounds
* MediaWiki only supports es5
* The wiki aesthetic
* Who is working on the wiki + onboarding
* Who is using the wiki
* The future of Leaguepedia
* How Megan got into wiki development
* Issues as opportunities to onboard Related Links
* River Writes - Megan's Blog
* Leaguepedia - League of Legends esports wiki
* MediaWiki
* VisualEditor
* VueJS in MediaWiki
* Open issue to support ES6 in MediaWiki
* Whitespace programming language
* Lua MediaWiki extensions
* CharInsert - Add code snippets into the MediaWiki editor
* Semantic MediaWiki (SMW) - Store and query data inside Wiki pages
* Cargo - Replaced SMW at Leaguepedia Conference Talks
* Usage of Cargo with Lua on LoL Gamepedia
* Mediawiker SublimeText plugin
* Cargo/Lua Best Practices, and When Not To Use Them
* MediaWiki Lua Tutorial
* Editing your wiki with Python is easier than you think Other podcast appearances
* Between the Brackets Transcript
You can help edit this transcript on GitHub.
[00:00:00] Jeremy: Today I'm talking to Megan Cutrofello. She managed the Leaguepedia eSports wiki for eight years, and in 2017 she got an award for being the unsung hero of the year for eSports. So Megan, thanks for joining me today.
[00:00:17] Megan: Thanks for having me.
[00:00:19] Jeremy: A lot of the people I talk to are into web development, so they work with web frameworks and things like that. And I guess when you think about it, wikis are web development, but they're kind of their own world, I suppose. for someone who's going to build some kind of a site, like when does it make sense for them to use a wiki versus, uh, a content management system or just like a more traditional web framework?
[00:00:55] Megan: I think it makes the most sense to use a wiki if you're going to have a lot of contributors and you don't want all of your contributors to have access to your server.
also if your contributors aren't necessarily as tech savvy as you are, um, it can make sense to use a wiki. if you have experience with MediaWiki, I guess it makes sense to use a Wiki.
Anytime I'm building something, my instinct is always, oh, I wanna make a Wiki (laughs) . Um, so even if it's not necessarily the most appropriate tool for the job, I always. My, my first thought is, hmm, let's see, I'm, I'm making a blog. Should I make my blog in in MediaWiki? Um, so, so I always, I always wanna do that. but I think it's always, when you're collaborating is pretty much, you always wanna do MediaWiki
[00:01:47] Jeremy: And I, I think that's maybe an important point when you say people are collaborating. When I think about Wikis, I think of Wikipedia, uh, and the fact that I can click the edit button and I can see the markup right there, make a change and, and click save. And I didn't even have to log in or anything. And it seems like that workflow is built into a wiki, but maybe not so much into your typical CMS or WordPress or something like that.
[00:02:18] Megan: Yeah. Having a public ability to solicit contributions from anyone. so for Leaguepedia, we actually didn't have open contributions from the public. You did have to create an account, but it's still that open anyone can make an account and all you have to do is like, go through that one step of create an account.
Admittedly, sometimes people are like, I don't wanna make an account that's so much work. And we're like, just make the account. Come on. It's not that hard. but, uh, you still, you're a community and you want people to come and contribute ideas and you want people to come and be a part of that community to, document your open source project or, record the history of eSports or write down all of the easter eggs that you find in a video game or in a TV show, or in your favorite fantasy novels.
Um, and it's really about community and working together to create something where the whole is bigger than the sum of its parts.
[00:03:20] Jeremy: And in a lot of cases when people are contributing, I've noticed that on Wikipedia when you edit, there's an option for a, a visual editor, and then there's one for looking at the raw markup. in, in your experience, are people who are doing the edits, are they typically using the visual editor or are they mostly actually editing the, the markup?
[00:03:48] Megan: So we actually disabled the Visual editor on Leaguepedia, because the visual editor is not fantastic at knowing things about templates. Um, so a template is when you have one page that gets its content pulled into the larger page, and there's a special syntax for that, and the visual editor doesn't know a lot about that.
Um, so that's the first reason. And then the second reason is that, there's this, uh, one extension that we use that allows you to make a clickable, piece of text. It's called (https://www.mediawiki.org/wiki/Extension:CharInsert) CharInserts, uh, for character inserts. so I made a lot of these things that is sort of along the same philosophy as Visual Editor, where it's to help people not have to have the same burden of knowledge, of knowing every exact piece of source that has to be inserted into the page. So you click the thing that says like, um, insert a pick and band prefill, and then a little piece of JavaScript fires and it inserts a whole bunch of Wiki text and then you just enter the champions in the correct places. In the prefills of champions are like the characters that you play in, uh, league of Legends.
And so then you have like the text is prefilled for you and you only have to fill in into this outline. so Visual Editor would conflict with CharInserts, and I much preferred the CharInserts approach where you have this compromise in between the never interacting with source and having to have all of the source memorized.
So between the fact that Visual Editor like is not a perfect tool and has these bugs in it, and also the fact that I preferred CharInserts, we didn't use Visual Editor at all. I know that some wikis do like to use Visual Editor quite a bit, and especially if you're not working with these templates where you have all of these prefills, it can be a lot more preferred to use Visual Editor.
Visual Editor is an experience much more similar to editing something like Microsoft Word, It doesn't feel like you're editing code. and editing code is, I mean, it's scary. Like for, and when I said like, MediaWiki is when you have editors who aren't as tech savvy, as the person who set up the Wiki.
for people who don't have that experience, I mean, when you just said like you have to edit a wiki, like someone who's never done that before, they can be very intimidated by it. And you're trying to build a sense of community. You don't want to scare away your potential editors. You want everyone to be included there.
So you wanna do everything possible to make everyo…
playlist_add
Jan 2, 2023
Victor Adossi on Yak Shaving
Victor is a software consultant in Tokyo who describes himself as a yak shaver. He writes on his blog at vadosware and curates Awesome F/OSS, a mailing list of open source products. He's also a contributor to the Open Core Ventures blog.
Before our conversation Victor wrote a structured summary of how he works on projects. I recommend checking that out in addition to the episode. Topics covered:
* Most people should use Dokku or CapRover
* But he uses Kubernetes anyways
* Hosting a Database in Kubernetes
* Learning technology
* You don't really know a thing until something goes wrong
* History of Frontend Development
* Context from lower layers of the stack and historical projects
* Good project pages have comparisons to other products
* Choosing technologies
* Language choice affects maintainability
* Knowing an ecosystem
* Victor's preferred stack
* Technology bake offs
* Posting findings means you get free corrections
* Why people use medium instead of personal sites Victor
* VADOSWARE - Blog
* How Victor works on Projects - Companion post for this episode
* Awesome FOSS - Curated list of OSS projects
* NimbusWS - Hosted OSS built on top of budget cloud providers
* Unvalidated Ideas - Startup ideas for side project inspiration
* PodcastSaver - Podcast index that allows you to choose Postgres or MeiliSearch and compare performance and results of each Victor's preferred stack
* Docker - Containers
* Kubernetes - Container provisioning (Though at the beginning of the episode he suggests Dokku for single server or CapRover for multiple)
* TypeScript - JavaScript with syntax for types. Victor's default choice.
* Rust - Language he uses if doing embedded work, performance is critical, or more correctness is desired
* Haskell - Language he uses if correctness and type system is the most important for the project
* Postgresql - General purpose database that's good enough for most use cases including full text search.
* KeyDB - Redis compatible database for caching. Acquired by Snap and then made open source. Victor uses it over Redis because it is multi threaded and supports flash storage without a Redis Enterprise license.
* Pulumi - Provision infrastructure with the languages you're already using instead of a specialized one or YAML
* Svelte and SvelteKit - Preferred frontend stack. Previously used Nuxt. Search engines
* Postgres Full Text Search vs the rest
* Optimizing Postgres Text Search with Trigrams
* OpenSearch - Amazon's fork of Elasticsearch
* typesense
* meilisearch
* sonic
* Quickwit JavaScript build tools
* Babel
* SWC
* Webpack
* esbuild
* parcel
* Vite
* Turbopack JavaScript frameworks
* React
* Vue
* Svelte
* Ember Frameworks built on top of frameworks
* Next - React
* Nuxt - Vue
* SvelteKit - Svelte
* Astro - Multiple Historical JavaScript tools and frameworks
* Underscore
* jQuery
* MooTools
* Backbone
* AngularJS
* Knockout
* Aurelia
* GWT
* Bower - Frontend package manager
* Grunt - Task runner
* Gulp - Task runner Related Links
* Dokku - Open source single-host alternative to Heroku
* Cloud Native Buildpacks - Buildpacks created by Heroku and Pivotal and used by Dokku
* CapRover - An open source PaaS-like abstraction built on top of Docker Swarm
* Kelsey Hightower's tweet about being cautious about running databases on Kubernetes
* Settling the Myth of Transparent HugePages for Databases
* Kubernetes Container Storage Interface (CSI)
* Kubernetes Local Persistent Volumes
* Longhorn - Distributed block storage for Kubernetes
* Postgres docs
* Postgres TOAST
* Everything I've seen on optimizing Postgres on ZFS
* Kubernetes Workload Resources
* Kubernetes Network Plugins
* Kubernetes Ingress
* Traefik
* Kubernetes the Hard Way (Setting up a cluster in a way that optimizes for learning)
* How does TLS work
* Let's Encrypt
* Cert manager for Kubernetes
* Choose Boring Technology
* A Linux user's guide to Logical Volume Management
* Docker networking overview
* Kubernetes Scheduler
* Tauri - Build desktop applications with web technology and Rust
* ripgrep - CLI tool to recursively search directory for a regex pattern (Meant to be a rust replacement for grep)
* angle-grinder / ag - CLI tool to parse and process log files written in rust
* Object.observe ECMAScript Proposal to be Withdrawn
* Ruby on Rails - Ruby web framework
* Django - Python web framework
* Laravel - PHP web framework
* Adonis - JavaScript
* NestJS - JavaScript
* What is a NullPointerException, and how do I fix it?
* Mastodon
* Clap - CLI argument parser for Rust
* AWS CDK - Provision AWS infrastructure using programming languages
* Terraform - Provision infrastructure with terraform language
* URL canonicalization of duplicate pages and the use of the canonical tag - Used by dev.to to send google traffic to the original blogpost instead of dev.to Transcript
You can help edit this transcript on GitHub.
[00:00:00] Jeremy: This episode, I talk to Victor Adossi who describes himself as a yak shaver. Someone who likes trying a whole bunch of different technologies, seeing the different options. We talk about what he uses, the evolution of front end development, and his various projects.
Talking to just different people it's always good to get where they're coming from because something that works for Google at their scale is going to be different than what you're doing with one of your smaller projects.
[00:00:31] Victor: Yeah, the context. Of course in direct conflict with that statement, I definitely use Google technology despite not needing to at all right? Like, you know, 99% of people who are doing like people like to call it indiehacking or building small products could probably get by with just Dokku. If you know Dokku or like CapRover. Are two projects that'll be like, Oh, you can just push your code here, we'll build it up like a little mini Heroku PaaS thing and just go on one big server, right? Like 99% of the people could just use that. But of course I'm not doing that. So I'm a bit of a hypocrite in that sense.
I know what I should be doing, but I'm not doing that. I am writing a Kubernetes cluster with like five nodes for no reason. Uh, yeah, I dunno, people don't normally count the controllers.
[00:01:24] Jeremy: Dokku and CapRover, I think those are where it's supposed to create a heroku like experience I think it's based off of the heroku buildpacks right? At least Dokku is?
[00:01:36] Victor: Yeah Buildpacks has actually been spun out into like a community thing so like pivotal and heroku, it's like buildpacks.io, they're trying to build a wider standard around it so that more people can get involved.
And buildpacks are actually obviously fantastic as a technology and as a a process piece. There's not much else like them and you know, that's obvious from like Heroku's success and everything. I know Dokku uses that. I don't know that Caprover does, but I haven't, I haven't really run Caprover that much.
They, they probably do. Like at this point if you're going to support building from code, it seems silly to try and build your own buildpacks. Cause that's what you will do, eventually. So you might as well use what's there.
Anyway, this is like just getting to like my personal opinions at this point, but like, if you think containers are a bad idea in 2022, You're wrong, you should, you should stop. Like you should, you should stop. Think about it. I mean, obviously there's not, um, I got a really great question at an interview once, which is, where are containers a bad idea?
That's probably one of the best like recent interview questions I've ever gotten cause I was like, Oh yeah, I mean, like, you can't, it can't be perfect everywhere, right? Nothing's perfect everywhere. So it's like, where is it? Uh, and of course the answer…
playlist_add
Oct 1, 2022
Xe Iaso on Tailscale
Xe Iaso is the Archmage of Infrastructure at Tailscale and previously worked at Heroku.
This episode originally aired on Software Engineering Radio but includes some additional discussion about their blog near the end of the episode.
Topics covered:
* Use cases for VPNs
* Simplifying service authentication by identifying users via IP
* Peer-to-peer vs centralized "Virtual Pain Networks"
* Tailscale's tech stack and why they forked the go compiler
* DERP relay servers
* Struggling with the iOS network extension size limit
* The surprisingly small amount of infrastructure required to run a VPN
* Running your company on your own product
* Working at Heroku vs Tailscale
* Using the socratic style of debate in technical blog posts
Related Links
* @theprincessxena
* Xe's Blog
* ACL samples
* Go links origin story
* How Tailscale works
* Tailscale SSH
* How Tailscale assigns IP addresses
* Hey linker, can you spare a meg?
* My Blog is Hilariously Overengineered to the Point People Think it's a Static Site
* The Sheer Terror of PAM
Transcript
[00:00:00] Jeremy: Today I'm talking to Xe Iaso, they're the archmage of infrastructure at tailscale, and they also have a great blog everyone should check out.
Xe, welcome to software engineering radio.
[00:00:12] Xe: Thanks. It's great to be here.
[00:00:14] Jeremy: I think the first thing we should start with, is what's a, a VPN, because I think some people they may have used it to remote into their workplace or something like that. But I think the, the scope of what it's good for and what it does is a lot broader than that. So maybe you could talk a little bit about that first.
[00:00:31] Xe: Okay. a VPN is short for virtual private network. It's basically a fake network that's overlaid on top of existing networks. And then you can use that network to do whatever you would with a normal computer network. this term has been co-opted by companies that are attempting to get into the, like hide my ass style market, where, you know, you encrypt your internet information and keep it safe from hackers.
But, uh, so it makes it really annoying and hard to talk about what a VPN actually is. Because tailscale, uh, the company I work for is closer to like the actual intent of a VPN and not just, you know, like hide your internet traffic. That's already encrypted anyway with another level of encryption and just make a great access point for, uh, three letter agencies.
But are there, use cases, past that, like when you're developing a piece of software, why would you decide to use a VPN outside of just because I want my, you know, my workers to be able to get access to this stuff.
[00:01:42] Xe: So something that's come up, uh, when I've been working at tailscale is that sometimes we'll make changes to something. And it'll be changes to like the user experience of something on the admin panel or something. So in a lot of other places I've worked in order to have other people test that, you know, you'd have to push it to the cloud.
It would have to spin up a review app in Heroku or some terrifying terraform of abomination would have to put it out onto like an actual cluster or something. But with tail scale, you know, if your app is running locally, you just give like the name of your computer and the port number. And you know, other people are able to just see it and poke it and experience it.
And that basically turns the, uh, feedback cycle from, you know, like having to wait for like the state of the world to converge, to, you know, make a change, press F five, give the URL to a coworker and be like, Hey, is this Gucci?
they can connect to your app as if you were both connected to the same switch.
[00:02:52] Jeremy: You don't have to worry about, pushing to a cloud service or opening ports, things like that.
[00:02:57] Xe: Yep. It will act like it's in the same room, even when they're not it'll even work. if you're at both at Starbucks and the Starbucks has reasonable policies, like holy crap, don't allow devices to connect to each other directly. so you know, you're working on. Like your screenplay app at your Starbucks or something, and you have a coworker there and you're like, Hey, uh, check this out and, uh, give them the link.
And then, you know, they're also seeing the screenplay editor.
[00:03:27] Jeremy: in terms of security and things like that. I mean, I'm picturing it kind of like we were sitting in the same room and there's a switch and we both plugged in. Normally when you do something like that, you kind of have, full access to whatever else is on the switch. Uh, you know, provided that's not being blocked by a, a firewall.
is there like a layer of security on top of that, that a VPN service like tailscale would provide.
[00:03:53] Xe: Yes. Um, there are these things called access control lists, which are kind of like firewall rules, except you don't have to deal with like the nightmare of writing an IP tables rule that also works in windows firewall and whatever they use in Mac OS. The ACL rules are applied at the tailnet level for every device in the tailnet.
So if you have like developer machines, you can put people into groups as things like developers and say that developer machines can talk to production, but not people in QA. They can only talk to testing and people on SRE have, you know, permissions to go everywhere and people within their own teams can connect to each other. you can make more complicated policies like that fairly easily.
[00:04:44] Jeremy: And when we think about infrastructure for, for companies, you were talking about how there could be development, infrastructure, production, infrastructure, and you kind of separate it all out. when you're working with cloud infrastructure. A lot of times, there's the, I always forget what it stands for, but there's like IAM.
There's like policies that you can set up with the cloud provider that says these users can access this, or these machines can access this. And, and I wonder from your perspective, when you would choose to use that versus use something at the, the network or the, the VPN level.
[00:05:20] Xe: The way I think about it is that things like IAM enforce, permissions for like more granularly scoped things like can create EC2 instances or can delete EC2 instances or something like that. And that's just kind of a different level of thing. uh, tailscale, ACLs are more, you know, X is allowed to connect to Y or with tailscale, SSH X is allowed to connect as user Y.
and that's really different than like arbitrary capability things like IAM offers.
you could think about it as an IAM system, but the main permissions that it's exposing are can X connect to Y on Zed port.
[00:06:05] Jeremy: What are some other use cases where if you weren't using a VPN, you'd have to do a lot more work or there's a lot more complexity, kind of what are some cases where it's like, okay, using a VPN here makes a lot of sense.
(The quick and simple guide to go links https://www.trot.to/go-links)
[00:06:18] Xe: There is a service internal to tailscale called go, which is a, clone of Google's so-called go links where it's basically a URL shortener that lives at http://go. And, you know, you have go/something to get to some internal admin service or another thing to get to like, you know, the company directory and notion or something, and this kind of thing you could do with a normal setup, you know, you could set it up and have to do OAuth challenges everywhere and, you know, have to put and make sure that everyone has the right DNS configuration so that, it shows up in the right place.
And then you have to deal with HTTPS um, because OAuth requires HTTPS for understandable and kind of important reasons. And it's just a mess. Like there's so many layers of stuff like the, the barrier to get, you know, like just a darn URL, shortener up turns from 20 minutes into three days of effort trying to…
playlist_add
Sep 9, 2022
Jonathan Shariat on Tragic Design
Jonathan Shariat is the coauthor of the book Tragic Design and co-host of the Design Review Podcast.
He's currently a Sr. Interaction Designer & Accessibility Program Lead at Google.
This episode originally aired on Software Engineering Radio.
Topics covered:
* How poor design kills in medical environments
* Causing harm with features meant to bring joy
* Considerations during the product development cycle
* Industry specific checklists and testing requirements
* Creating guiding principles for a team
* Why medical software often has poor UX
* Designing for crisis situations
* Why dark patterns can be bad in the long term
Related Links
* @designuxui
* Tragic Design
* How Bad UX Killed Jenny
* Design Review podcast
* Deceptive Design
Transcript
You can help edit this transcript on GitHub.
[00:00:00] Jeremy: Today I'm talking to Jonathan Shariat, he's the co-author of Tragic design. The host of the design review podcast. And he's currently a senior interaction designer and accessibility program lead at Google. Jonathan, welcome to software engineering radio.
[00:00:15] Jonathan: Hi, Jeremy, thank you So much for having me on.
[00:00:18] Jeremy: the title of your book is tragic design. And I think that people can take a lot of different meanings from that. So I wonder if you could start by explaining what tragic design means to you.
[00:00:33] Jonathan: Hmm. For me, it really started with this story that we have in the beginning of the book. It's also online. Uh, I originally wrote it as a medium article and th that's really what opened my eyes to, Hey, you know, design has, is, is this kind of invisible world all around us that we actually depend on very critically in some cases.
And So this story was about a girl, you know, a nameless girl, but we named her Jenny for the story. And in short, she came for treatment of cancer at the hospital, uh, was given the medication and the nurses that were taking care of her were so distracted with the software they were using to chart, make orders, things like that, that they miss the fact that she needed hydration and that she wasn't getting it.
And then because of that, she passed away. And I still remember that feeling of just kind of outrage. And, you know, when we hear a lot of news stories, A lot of them are outraging. they, they touch us, but some of them, some of those feelings stay and they stick with you.
And for me, that stuck with me, I just couldn't let it go because I think a lot of your listeners will relate to this. Like we get into technology because we really care about the potential of technology. What could it do? What are all the awesome things that could do, but we come at a problem and we think of all the ways it could be solved with technology and here it was doing the exact opposite.
It was causing problems. It was causing harm and the design of that, or, you know, the way that was built or whatever it was failing Jenny, it was failing the nurses too, right? Like a lot of times we blame that end user and, and it caused it. So to me, that story was so tragic. Something that deeply saddened me and was regrettable and cut short someone's uh, you know, life and that's the definition of tragic, and there's a lot of other examples with varying degrees of tragic, but, um, you know, as we look at the impact technology has, and then the impact we have in creating those technologies that have such large impacts, we have a responsibility to, to really look into that and make sure we're doing as best of job as we can and avoid those as much as possible.
Because the biggest thing I learned in researching all these stories was, Hey, these aren't bad people. These aren't, you know, people who are clueless and making these, you know, terrible mistakes. They're me, they're you, they're they're people. Um, just like you and I, that could make the same mistakes.
[00:03:14] Jeremy: I think it's pretty clear to our audience where there was a loss of life, someone, someone died and that's, that's clearly tragic. Right? So I think a lot of things in the healthcare field, if there's a real negative outcome, whether it's death or severe harm, we can clearly see that as tragic.
and I, I know in your book you talk about a lot of other types of, I guess negative things that software can cause. So I wonder if you could, explain a little bit about now past the death and the severe injury. What's tragic to you.
[00:03:58] Jonathan: Yeah. still in that line of like of injury and death, And, you know, the side that most of us will actually, um, impact, our work day-to-day is also physical harm. Like, creating this software in a car. I think that's a fairly common one, but also, ergonomics, right?
Like when we bring it back to something like less impactful, but still like multiplied over the impact of, multiplied over the impact of a product rather, it can be quite, quite big, right? Like if we're designing software in a way that's very repetitive or, you know, everyone's, everyone's got that, that like scroll, thumb, scroll, you know, issue.
Right. if, uh, our phones aren't designed well, so there's a lot of ways that it can still physically impact you ergonomically. And that can cause you a lot of problem arthritis and pain, but yeah, there's, there's other, there's other, other ways that are still really impactful. So the other one is by saddening or angry.
You know, that emotional harm is very real. And oftentimes sometimes it gets overlooked a little bit because it's, um, you know, physical harm is what is so real to us, but sometimes emotional harm isn't. But, you know, we talk about in the book, the example of Facebook, putting together this great feature, which takes your most liked photo, and, you know, celebrates your whole year by you saying, Hey, look at as a hero, you're in review this, the top photo from the year, they add some great, you know, well done illustrations behind it, of, of balloons and confetti and, people dancing.
But some people had a bad year. Some people's most liked engaged photo is because something bad happened and they totally missed. And because of that, people had a really bad time with this where, you know, they lost their child that year. They lost their loved one that year, their house burnt down. Um, something really bad happened to them.
And here was Facebook putting that photo of their, of their dead child up with, you know, balloons and confetti and people dancing around it. And that was really hard for people. They didn't want to be reminded of that. And especially in that way, and these emotional harms also come into the, in the play of, on anger.
You know, we talk about, well, one, you know, there's, there's a lot of software out there that, that, um, tries to bring up news stories that anger us and which equals engagement. Um, but also ones that, um, use dark patterns to trick us into purchasing and buying and forgetting about that free trial. So they charge us for a yearly subscription and won't refund us.
Uh, if you've ever tried to cancel a subscription, you start to see some real their their real colors. Um, so emotional harm and, uh, anger is a, is a big one. We also talk about injustice in the book where there are products that are supposed to be providing justice. Um, and you know, in very real ways like voting or, you know, getting people the help that they need from the government, or, uh, for people to see their loved ones in jail.
Um, or, you know, you're getting a ticket unfairly because you couldn't read the sign was you're trying to read the sign and you, and you couldn't understand it. so yeah, we look at a lot of different ways that design and our saw the software that we create can have very real impact on people's lives and in a negative way, if we're not careful.
[00:07:25] Jeremy: the impression I get, when you talk about tragic design, it's really about anything that could harm a person, whether ph…
playlist_add
Aug 17, 2022
Randy Shoup on Evolving Architecture at eBay
This episode originally aired on Software Engineering Radio.
Randy Shoup is the VP of Engineering and Chief Architect at eBay. He was previously the VP of Engineering at WeWork and Stitch Fix, a Director of Engineering at Google Cloud where he worked on App Engine, and a Chief Engineer and Distinguished Architect at eBay in 2004.
Topics covered:
* eBay’s origins as a single C++ class
* The five-year migration to Java services
* Sharing a database between the old and new systems
* Building a distributed tracing system
* Working with bare metal
* Why most companies should stick to cloud
* Why individual services should own their own data storage
* How scale has caused solutions to change
* Rejoining a former company
* The Accelerate Book
* Improving delivery time.
Related Links:
@randyshoup
OpenTelemetry
LightStep
Honeycomb
Accelerate Book
The Memo
Value Stream Mapping
The Epic Story of Dropbox’s Exodus from the Amazon Cloud Empire
Transcript:
[00:00:00] Jeremy: Today, I'm talking to Randy Shoup, he's the VP of engineering and chief architect at eBay.
[00:00:05] Jeremy: He was previously the VP of engineering at WeWork and stitch fix, and he was also a chief engineer and distinguished architect at eBay back in 2004. Randy, welcome back to software engineering radio. This will be your fifth appearance on the show. I'm pretty sure that's a record.
[00:00:22] Randy: Thanks, Jeremy, I'm really excited to come back. I always enjoy listening to, and then also contributing to software engineering radio.
Back at, Qcon 2007, you spoke with Markus Volter he's he was the founder of SE radio. And you were talking about developing eBay's new search engine at the time.
[00:00:42] Jeremy: And kind of looking back, I wonder if you could talk a little bit about how eBay was structured back then, maybe organizationally, and then we can talk a little bit about the, the tech stack and that sort of thing.
[00:00:53] Randy: Oh, sure. Okay. Yeah. Um, so eBay started in 1995. I just want to like, you know, orient everybody. Same, same as the web. Same as Amazon, same as a bunch of stuff. So E-bay was actually almost 10 years old when I joined. That seemingly very old first time. Um, so yeah. What was ebay's tech stack like then? So E-bay current has gone through five generations of its infrastructure.
It was transitioning between the second and the third when I joined in 2004. Um, so the. Iteration was Pierre Omidyar, the founder three-day weekend three-day labor day weekend in 1995, playing around with this new cool thing called the web. He wasn't intending to build a business. He just was playing around with auctions and wanted to put up a webpage.
So he had a Perl backend and every item was a file and it lived on this little 486 tower or whatever you had at the time. Um, so that wasn't scalable and wasn't meant to be. The second generation of eBay's architecture was what we called V2 very, you know, creatively, uh, that was a C++ monolith. Um, an ISAPI DLL with essentially well at its worst, which grew to 3.4 million lines of code in that single DLL and basically in a single class, not just in a single, like repo or a single file, but in a single class.
So that was very unpleasant to work in. As you can imagine, um, eBay had about a thousand engineers at the time and they were, you know, as you can imagine, like really stepping on each other's toes and not being able to make much forward progress. So starting in, I want to call it 2002. So two years before I joined, um, they were migrating to the creatively named V3 and V3 architecture was Java, and.
you know, not microservices, but like we didn't even have that term, but it wasn't even that it was mini applications. So I'm actually going to take a step back. V2 was a monolith. So like all of eBay's code in that single DLL and like that was buying and selling and search and everything. And then we had two monster databases, a primary and a backup big Oracle machines on some hardware that was bigger, you know, bigger than refrigerators and that ran eBay for a bunch of years, before we changed the upper part of the stack, we, um, chopped up the, that single monolithic database into a bunch of, um, domain specific databases or entity specific databases, right?
So a set of databases around users, you know, sharded by the user ID could talk about all that. If you want, you know, items again, sharded by item ID transactions, sharded by transaction ID... I think when I joined, it was the several hundred instances of, uh, Oracle databases, um, you know, spread around, but still that monolithic front end.
And then in 2002, I wanna say we started migrating into that V3 that I was saying, okay. So that's, uh, that was a rewrite in Java, again, many applications. So you take the front end and instead of having it be in one big unit, it was this, uh, ER file, EAR, file, if run and people remember back to, you know, those stays in Java, um, you know, 220 different of those.
So like here is the, you know, one of them for the search pages, you know, so the, you know, one application be the search application and it would, you know, do all the search related stuff, the handful of pages around search, uh, ditto for, you know, the buying area, ditto for the, you know, checkout area, ditto for the selling area...
220 of those. Um, and that was again, domain, um, vertically sliced domains. And then the relationship between those V3, uh, applications and the databases was a many to many things. So like many applicants, many of those applications interact with items. So they would interact with those item databases. Many of them would interact with users.
And so they would interact with a user databases, et cetera, uh, happy to go into as much gory detail as you want about all that. But like, that's what, uh, but we were in the transition period. You know, when I, uh, between the V2 monolith to the V3 mini applications in, uh, 2004, I'm just going to pause there and like, let me know where you want to take it.
[00:05:01] Jeremy: Yeah. So you were saying that it was, um, it started as Perl, then it became a C++, and that's kind of interesting that you said it was all in one class, right? So it's wow. That's gotta be a gigantic
[00:05:16] Randy: I mean, completely brutal. Yeah. 3.4 million lines of code. Yeah. We were hitting compiler limits on the number of methods per class.
[00:05:22] Jeremy: Oh my gosh.
[00:05:23] Randy: I'm, uh, uh, scared that I have that. I happen to know that at least at the time, uh, Microsoft allowed you 16 K uh, methods per class, and we were hitting that limit.
So, uh, not great.
[00:05:36] Jeremy: So it's just kind of interesting to think about how do you walk through that code, right? You have, I guess you just have this giant file.
[00:05:45] Randy: Yeah. I mean, there were, you know, different methods. Um, but yeah, it was a big man. I mean, it was a monolith, it was, uh, you know, it was a spaghetti mess. Um, and you know, as you can imagine, Amazon went through a really similar thing by the way. So this wasn't soup. I mean, it was bad, but like we weren't the only people that were making that, making that a mistake.
Um, and just like Amazon, where they were, uh, they did like one update a quarter (laughs) , you know, at that period, like 2000, uh, we were doing something really similar, like very, very slow. Um, you know, updates and, uh, when we moved to V3, you know, the idea was to get to do changes much faster. And we were very proud of ourselves starting in 2004 that we, uh, upgraded the whole site every two weeks.
And we didn't have to do the whole site, but like each of those individual applications that I was mentioning, right. Those 220 applications, each of those would roll out on this biweekly cadence. Um, and they had interdependencies. And so we rolled them out in this dependency order in any way, lots of, lots of complexity associated w…
playlist_add
May 11, 2022
Ant Wilson on Supabase
This episode originally aired on Software Engineering Radio.
A few topics covered
* Building on top of open source
* Forking their GoTrue dependency
* Relying on Postgres features like row level security
* Adding realtime support based on Postgres's write ahead log
* Generating an API layer based on the database schema with PostgREST
* Creating separate EC2 instances for each customer's database
* How Postgres could scale in the future
* Monitoring postgres
* Common support tickets
* Permissive open source licenses
Related Links
* @antwilson
* Supabase
* Supabase GitHub
* Firebase
* Airtable
* PostgREST
* GoTrue
* Elixir
* Prometheus
* VictoriaMetrics
* Logflare
* BigQuery
* Netlify
* Y Combinator
Postgres
* PostgreSQL
* Write-Ahead Logging
* Row Security Policies
* pg_stat_statements
* pgAdmin
* PostGIS
* Amazon Aurora
Transcript
You can help edit this transcript on GitHub.
[00:00:00] Jeremy: Today I'm talking to Ant Wilson, he's the co-founder and CTO of Supabase. Ant welcome to software engineering radio.
[00:00:07] Ant: Thanks so much. Great to be here.
[00:00:09] Jeremy: When I hear about Supabase, I always hear about it in relation to two other products. The first is Postgres, which is a open source relational database. And second is Firebase, which is a backend as a service product from Google cloud that provides a no SQL data store.
It provides authentication and authorization. It has a functions as a service component. It's really meant to be a replacement for you needing to have your own server, create your own backend. You can have that all be done from Firebase. I think a good place for us to start would be walking us through what supabase is and how it relates to those two products.
[00:00:55] Ant: Yeah. So, so we brand ourselves as the open source Firebase alternative
that came primarily from the fact that we ourselves do use the, as the alternative to Firebase. So, so my co-founder Paul in his previous startup was using fire store. And as they started to scale, they hit certain limitations, technical scaling limitations and he'd always been a huge Postgres fan.
So we swapped it out for Postgres and then just started plugging in. The bits that we're missing, like the real-time streams. Um, He used the tool called PostgREST with a T for the, for the CRUD APIs. And so
he just built like the open source Firebase alternative on Postgres, And that's kind of where the tagline came from.
But the main difference obviously is that it's relational database and not a no SQL database which means that it's not actually a drop-in replacement. But it does mean that it kind of opens the door to a lot more functionality actually. Um, Which, which is hopefully an advantage for us.
[00:02:03] Jeremy: it's a, a hosted form of Postgres. So you mentioned that Firebase is, is different. It's uh NoSQL. People are putting in their, their JSON objects and things like that. So when people are working with Supabase is the experience of, is it just, I'm connecting to a Postgres database I'm writing SQL.
And in that regard, it's kind of not really similar to Firebase at all. Is that, is that kind of right?
[00:02:31] Ant: Yeah, I mean, the other thing, the other important thing to notice that you can communicate with Supabase directly from the client, which is what people love about fire base. You just like put the credentials on the client and you write some security rules, and then you just start sending your data. Obviously with supabase, you do need to create your schema because it's relational.
But apart from that, the experience of client side development is very much the same or very similar the interface, obviously the API is a little bit different. But, but it's similar in that regard. But I, I think, like I said, we're moving, we are just a database company actually. And the tagline, just explained really, well, kind of the concept of, of what it is like a backend as a service. It has the real-time streams. It has the auth layer. It has the also generated APIs. So I don't know how long we'll stick with the tagline. I think we'll probably outgrow it at some point. Um, But it does do a good job of communicating roughly what the service is.
[00:03:39] Jeremy: So when we talk about it being similar to Firebase, the part that's similar to fire base is that you could be a person building the front end part of the website, and you don't need to necessarily have a backend application because all of that could talk to supabase and supabase can handle the authentication, the real-time notifications all those sorts of things, similar to Firebase, where we're basically you only need to write the front end part, and then you have to know how to, to set up super base in this case.
[00:04:14] Ant: Yeah, exactly. And some of the other, like we took w we love fire based, by the way. We're not building an alternative to try and destroy it. It's kind of like, we're just building the SQL alternative and we take a lot of inspiration from it. And the other thing we love is that you can administer your database from the browser.
So you go into Firebase and you have the, you can see the object tree, and when you're in development, you can edit some of the documents in real time. And, and so we took that experience and effectively built like a spreadsheet view inside of our dashboard. And also obviously have a SQL editor in there as well.
And trying to, create this, this like a similar developer experience, because that's where Firebase just excels is. The DX is incredible. And so we, we take a lot of inspiration from it in, in those respects.
[00:05:08] Jeremy: and to to make it clear to our listeners as well. When you talk about this interface, that's kind of like a spreadsheet and things like that. I suppose it's similar to somebody opening up pgAdmin, I suppose, and going in and editing the rows. But, but maybe you've got like another layer on top that just makes it a little more user-friendly a little bit more like something you would get from Firebase, I guess.
[00:05:33] Ant: Yeah.
And, you know, we, we take a lot of inspiration from pgAdmin. PG admin is also open source. So I think we we've contributed a few things and, or trying to upstream a few things into PG admin. The other thing that we took a lot of inspiration from for the table editor, what we call it is airtable.
And because airtable is effectively. a a relational database and that you can just come in and, you know, click to add your columns, click to add a new table. And so we just want to reproduce that experience again, backed up by a full Postgres dedicated database.
[00:06:13] Jeremy: so when you're working with a Postgres database, normally you need some kind of layer in front of it, right? That the person can't open up their website and connect directly to Postgres from their browser. And you mentioned PostgREST before. I wonder if you could explain a little bit about what that is and how it works.
[00:06:34] Ant: Yeah, definitely. so yeah, PostgREST has been around for a while. Um, It's basically an, a server that you connect to, to your Postgres database and it introspects your schemas and generates an API for you based on the table names, the column names. And then you can basically then communicate with your Postgres database via this restful API.
So you can do pretty much, most of the filtering operations that you can do in SQL um, uh, equality filters. You can even do full text search over the API. So it just means that whenever you obviously add a new table or a new schema or a new column the API just updates instantly. So you, you don't have to worry about writing that, that middle layer which is, was always the drag right.
When, what have you started a new project. It's like, okay, I've got my schema, I've got my client. Now I have to do all the connecting code in the middle of which is kind of, yeah…
playlist_add
Apr 4, 2022
Testing with Jason Swett
Jason Swett is the author of the Complete Guide to Rails Testing. We covered Jason's experience with testing while building relatively small Ruby on Rails applications. Our conversation applies to just about any language or framework so don't worry if you aren't familiar with Rails.
A few topics covered:
- Listen to advice but be aware of its context. Something good for a large project may not apply to a small one
- Fast feedback loops help us work quicker and tests are great for this
- If you don't involve things like the database in any of your tests your application may not work at all despite your tests passing
- You may not need to worry about scaling at the start for smaller or internal applications
- Try to break features into the smallest pieces possible so they can be checked in and reviewed quickly
- Jason doesn't remember the difference between a stub and a mock because he rarely uses them
Related Links:
- Code with Jason
- The Complete Guide to Rails Testing
- Code With Jason Podcast
Transcript:
[00:00:00] Jeremy: today I'm talking to Jason Swett, he's the author of the complete guide to rails testing, a frequent trainer and conference speaker. And he's the host of the code with Jason podcast. So Jason, welcome to software sessions.
[00:00:13] Jason: Thanks for having me.
[00:00:15] Jeremy: from listening to your podcast, I get a sense that the size of the projects you work on they're, they're relatively modest.
Like they're not like a super huge thing. There, there may be something that you can fit all within your head. And I was wondering if you could talk a little bit to that first, so that we kind of get where your perspective is and the types of projects you work on are.
[00:00:40] Jason: Yeah. Good question. So that is true. Most of my jobs have been at small companies and I think that's probably typical of the typical developer because most businesses in the world are small businesses. You know, there's, there's a whole bunch of small businesses for every large business. And so most of the code bases I've worked on have been not particularly huge.
And most of the teams I've worked on have been relatively small And sometimes so small that it's just me. I'm the only person working on the application. I, don't really know any different. So I can't really compare it to working on a larger application. I have worked at, I worked at AT&T so that was a big place, but I was at, AT&T just working on my own solo project so that wasn't a big code base either.
So yeah, that's been what my experience has been like.
[00:01:36] Jeremy: Yeah. And I, I think that's interesting that you mentioned most people work in that space as well, because that's basically where I fall as well. So when I listened to your podcast and I hear you talking about like, oh, I have a, I have a rails project where I just have a single server and you know, I have a database and rails, and maybe I have nginx in front, maybe redis it's sort of the scale that I'm familiar with versus when I hear podcasts or articles, you know, I'm reading where they're talking about, oh, we have 500 microservices or we have 200 instances of the application.
That's, that's not a space that I've, I've worked in. So I, I found it helpful to, to hear, you know, from you on your show that like, Hey, you know, not everybody is working on these gigantic projects.
[00:02:28] Jason: Yeah. Yeah. It's not terribly relatable when you hear about those huge projects.
And obviously, sometimes, maybe people earlier in their career can get the wrong idea about what's applicable to their situation. I feel like one of the most dangerous kinds of advice is advice that's good advice, but it's good advice for somebody else.
And then I've, I've. Been victim of that, where I get some advice and maybe it's genuinely good advice, but it's not good advice for me where I am doing what I'm doing. And so, I apply the advice, but it's not the right thing. And so it doesn't work out for me. So I'm always careful to like asterisk a lot of the things I say where it's like, Hey, this is, this is good advice if you're in this particular situation, but maybe not for everybody.
And really the truth is I, I try not to give advice these days because like advice is dangerous stuff for that very reason.
[00:03:28] Jeremy: so, so when you mentioned you try not to give advice and you have this book, the complete guide to rails testing, would you not describe what's in the book as advice? I'm kind of curious what the distinction is there.
[00:03:42] Jason: Yeah, Jeremy, right after I said that, I'm like, what am I talking about? I give all kinds of advice. So forget, I said that I totally give advice. But maybe not in certain things like like business advice or anything like that. I do give a lot of advice around testing and various programming things.
So, yeah, ignore that part of what I said.
[00:04:03] Jeremy: something that I found a little bit unique about rails testing was that a lot of the tests are centered around I guess you could call it like a full integration test, right? Because I noticed when working with rails, if I write a test, a lot of times it's talking to the database, it's talking to if, if I.
Have an API or I have a website it's actually talking to the API. So it's actually going through all the layers and spinning up a database and all that. And I wonder if you, you knew how that work, like each time you run a test, is it creating a new database? So that each test is isolated or how does all that stuff actually work?
[00:04:51] Jason: Yeah, good question. First. I want to mention something about terminology. So I think one of the most important things for somebody who's new to testing to learn is that in our industry, we don't have a consensus around terminology. So what you call an integration test might be different from what I call an integration test.
The thing you just described as an integration test, I might call an acceptance test. Although I happen to also call it an integration test cause I use that terminology too, but I just wanted to give that little asterisk for the listener, because if they're like, wait, I thought an integration test was this.
And not that anyway, you asked how does that work? So. It is true that with those types of rails tests, and just to add more terminology into the mix, they call those system tests or system specs, depending on what framework you're using. But those are the tests that actually instantiate a browser and simulating user input, exercise, the UI of the application.
And those are the kinds of tests that like show you that everything works together. And mechanically how that works. One layer of it is that each test runs in a database transaction. So when you, you know, in order to run a certain test, maybe you need certain records like a user. And then I don't know if it's a scheduling test, you might need to create an appointment and whatever. All those records that you create specifically for that test that's happening inside of a database transaction. And then at the end of the test, the transaction is aborted. So that none of the data you create during the test actually gets persisted to the database. then regarding the whole database, it's not actually like creating a new database instance at the start of each test and then blowing it away.
It's still the same database instance is just the data inside of each test is not being persisted at.
[00:07:05] Jeremy: Okay. So when you run. What you would call, I guess you called it an acceptance test, right? Where it's going, it's opening up your website, it's clicking through the website, creating records, things like that. That's happening in a database instance that's created for, I guess, for all your tests that all your tests get to reuse and rails is automatically wrapping your test in a transaction.
So even if you're doing five or 10 database queries at the end of all, tha…
playlist_add
Nov 10, 2021
Taking Notes on Serverless
Swizec is the author of the Serverless Handbook and a software engineer at Tia.
Swizec
* Swizec's personal site
* Serverless Handbook
AWS
* Lambda
* API Gateway
* Operating Lambda (The cold start problem)
* Provisioned Concurrency
* DynamoDB
* Relational Database Service
* Aurora
* Simple Queue Service
* CloudFormation
* CloudWatch
Other serverless function hosting providers
* Gatsby Cloud Functions
* Vercel Serverless Functions
* Netlify Functions
* Cloud Functions for Firebase
Related topics
* Serverless Framework
* Jamstack
* Lighthouse
* What is a Static Site Generator?
* What is a CDN?
* Keeping Server-Side Rendering Cool With React Hydration
* TypeScript
Transcript
You can help edit this transcript on GitHub.
[00:00:00] Jeremy: Today, I'm talking to Swiz Teller. He's a senior software engineer at Tia. The author of the serverless handbook and he's also got a bunch of other courses and I don't know is it thousands of blog posts now you have a lot of them.
[00:00:13] Swizec: It is actually thousands of, uh, it's like 1500. So I don't know if that's exactly thousands, but it's over a thousand.
I'm cheating a little bit. Cause I started in high school back when blogs were still considered social media and then I just kind of kept going on the same domain.
Do you have some kind of process where you're, you're always thinking of what to write next? Or are you writing things down while you're working at your job? Things like that. I'm just curious how you come up with that.
[00:00:41] Swizec: So I'm one of those people who likes to use writing as a way to process things and to learn. So one of the best ways I found to learn something new is to kind of learn it and then figure out how to explain it to other people and through explaining it, you really, you really spot, oh shit. I don't actually understand that part at all, because if I understood it, I would be able to explain it.
And it's also really good as a reference for later. So some, one of my favorite things to do is to spot a problem at work and be like, oh, Hey, this is similar to that side project. I did once for a weekend experiment I did, and I wrote about it so we can kind of crib off of my method and now use it. So we don't have to figure things out from scratch.
And part of it is like you said, that just always thinking about what I can write next. I like to keep a schedule. So I keep myself to posting two articles per week. It used to be every day, but I got too busy for that. when you have that schedule and, you know, okay on Tuesday morning, I'm going to sit down and I have an hour or two hours to write, whatever is on top of mind, you kind of start spotting more and more of these opportunities where it's like a coworker asked me something and I explained it in a slack thread and it, we had an hour. Maybe not an hour, but half an hour of back and forth. And you actually just wrote like three or 400 words to explain something. If you take those 400 words and just polish them up a little bit, or rephrase them a different way so that they're easier to understand for somebody who is not your coworker, Hey, that's a blog post and you can post it on your blog and it might help others.
[00:02:29] Jeremy: It sounds like taking the conversations most people have in their day to day. And writing that down in a more formal way.
[00:02:37] Swizec: Yeah. not even maybe in a more formal way, but more, more about in a way that a broader audience can appreciate. if it's, I'm super gnarly, detailed, deep in our infrastructure in our stack, I would have to explain so much of the stuff around it for anyone to even understand that it's useless, but you often get these nuggets where, oh, this is actually a really good insight that I can share with others and then others can learn from it. I can learn from it.
[00:03:09] Jeremy: What's the most accessible way or the way that I can share this information with the most people who don't have all this context that I have from working in this place.
[00:03:21] Swizec: Exactly. And then the power move, if you're a bit of an asshole is to, instead of answering your coworkers question is to think about the answer, write a blog post and then share the link with them.
I think that's pushing it a little bit.
[00:03:38] Jeremy: Yeah, It's like you're being helpful, but it also feels a little bit passive aggressive.
[00:03:44] Swizec: Exactly. Although that's a really good way to write documentation. One thing I've noticed at work is if people keep asking me the same questions, I try to stop writing my replies in slack and instead put it on confluence or whatever internal wiki that we have, and then share that link. and that has always been super appreciated by everyone.
[00:04:09] Jeremy: I think it's easy to, have that reply in slack and, and solve that problem right then. But when you're creating these Wiki pages or these documents, how're people generally finding these. Cause I know you can go through all this trouble to make this document. And then people just don't know to look or where to go.
[00:04:30] Swizec: Yeah. Discoverability is a really big problem, especially what happens with a lot of internal documentation is that it's kind of this wasteland of good ideas that doesn't get updated and nobody maintains. So people stop even looking at it. And then if you've stopped looking at it before, stop updating it, people stop contributing and it kind of just falls apart.
And the other problem that often happens is that you start writing this documentation in a vacuum. So there's no audience for it, so it's not help. So it's not helpful. That's why I like the slack first approach where you first answered the question is. And now, you know exactly what you're answering and exactly who the audiences.
And then you can even just copy paste from slack, put it in a conf in JIRA board or wherever you put these things. spice it up a little, maybe effect some punctuation. And then next time when somebody asks you the same question, you can be like, oh, Hey, I remember where that is. Go find the link and share it with them and kind of also trains people to start looking at the wiki.
I don't know, maybe it's just the way my brain works, but I'm really bad at remembering information, but I'm really good at remembering how to find it. Like my brain works like a huge reference network and it's very easy for me to remember, oh, I wrote that down and it's over there even if I don't remember the answer, I almost always remember where I wrote it down if I wrote it down, whereas in slack it just kind of gets lost.
[00:06:07] Jeremy: Do you also take more informal notes? Like, do you have notes locally? You look through or something? That's not a straight up Wiki.
[00:06:15] Swizec: I'm actually really bad at that. I, one of the things I do is that when I'm coding, I write down. so I have almost like an engineering log book where everything, I, almost everything I think about, uh, problems I'm working on. I'm always writing them down on by hand, on a piece of paper. And then I never look at those notes again.
And it's almost like it helps me think it helps me organize my thoughts.
And I find that I'm really bad at actually referencing my notes and reading them later because, and this again is probably a quirk of my brain, but I've always been like this. Once I write it down, I rarely have to look at it again.
But if I don't write it down, I immediately forget what it is.
What I do really like doing is writing down SOPs. So if I notice that I keep doing something repeatedly, I write a, uh, standard operating procedure. For my personal life and for work as well, I have a huge, oh, it's not that huge, but I have a repository of standard procedures where, okay, I need to do X.
So you pull up the right recipe and you just follow the recipe. And if you spot a bug in the recipe, you fix the recipe. And then…
playlist_add
Oct 27, 2021
Robotic Process Automation with Alexander Pugh
Alexander Pugh is a software engineer at Albertsons. He has worked in Robotic Process Automation and the cognitive services industry for over five years.
This episode originally aired on Software Engineering Radio.
Related Links
* Alexander Pugh's personal site
Enterprise RPA Solutions
* Automation Anywhere
* UiPath
* blueprism
Enterprise "Low Code/No Code" API Solutions
* appian
* mulesoft
* Power Automate
RPA and the OS
* Office primary interop assemblies
* Office Add-ins documentation
* Task Scheduler for developers
* The Component Object Model
* The Document Object Model
Transcript
You can help edit this transcript on GitHub.
[00:00:00] Jeremy: Today, I'm talking to Alexander Pugh. He's a solutions architect with over five years of experience working on robotic process automation and cognitive services.
Today, we're going to focus on robotic process automation.
Alexander welcome to software engineering radio.
[00:00:17] Alex: Thank you, Jeremy. It's really good to be here.
[00:00:18] Jeremy: So what does robotic process automation actually mean?
[00:00:23] Alex: Right. It's a, it's a very broad nebulous term. when we talk about robotic process automation, as a concept, we're talking about automating things that humans do in the way that they do them. So that's the robotic, an automation that is, um, done in the way a human does a thing.
Um, and then process is that thing, um, that we're automating. And then automation is just saying, we're turning this into an automation where we're orchestrating this and automating this. and the best way to think about that in any other way is to think of a factory or a car assembly line. So initially when we went in and we, automated a car or factory, automation line, what they did is essentially they replicated the process as a human did it. So one day you had a human that would pick up a door and then put it on the car and bolt it on with their arms. And so the initial automations that we had on those factory lines were a robot arm that would pick up that door from the same place and put it on the car and bolt it on there.
Um, so the same can be said for robotic process automation. We're essentially looking at these, processes that humans do, and we're replicating them, with an automation that does it in the same way. Um, and where we're doing that is the operating system. So robotic process automation is essentially going in and automating the operating system to perform tasks the same way a human would do them in an operating system.
So that's, that's RPA in a nutshell,
Jeremy: So when you say you're replicating something that a human would do, does it mean it has to go through some kind of GUI or some kind of user interface?
[00:02:23] Alex: That's exactly right, actually. when we're talking about RPA and we look at a process that we want to automate with RPA, we say, okay. let's watch the human do it. Let's record that. Let's document the human process. And then let's use the RPA tool to replicate that exactly in that way.
So go double click on Chrome, launch that click in the URL line and send key in www.cnn.com or what have you, or servicenow hit enter, wait for it to load and then click, you know, where you want to, you know, fill out your ticket for service. Now send key in. So that's exactly how an RPA solution at the most basic can be achieved.
Now and any software engineer knows if you sit there and look over someone's shoulder and watch them use an operating system. Uh, you'll say, well, there's a lot of ways we can do this more efficiently without going over here, clicking that, you know, we can, use a lot of services that the operating system provides in a programmatic way to achieve the same ends and RPA solutions can also do that.
The real key is making sure that it is still achieving something that the human does and that if the RPA solution goes away, a human can still achieve it. So if you're, trying to replace or replicate a process with RPA, you don't want to change that process so much so that a human can no longer achieve it as well.
that's something where if you get a very technical, and very fluent software engineer, they lose sight of that because they say, oh, you know what? There's no reason why we need to go open a browser and go to you know, the service now portal and type this in when I can just directly send information to their backend.
which a human could not replicate. Right? So that's kind of where the line gets fuzzy. How efficiently can we make this RPA solution?
[00:04:32] Jeremy: I, I think a question that a lot of people are probably having is a lot of applications have APIs now. but what you're saying is that for it to, to be, I suppose, true RPA, it needs to be something that a user can do on their own and not something that the user can do by opening up dev tools or making a post to an end point.
[00:04:57] Alex: Yeah. And so this, this is probably really important right now to talk about why RPA, right? Why would you do this when you could put on a server, a a really good, API ingestion point or trigger or a web hook that can do this stuff. So why would we, why would we ever pursue our RPA?
There there's a lot of good reasons for it. RPA is very, very enticing to the business. RPA solutions and tools are marketed as a low code, no code solution for the business to utilize, to solve their processes that may not be solved by an enterprise solution and the in-between processes in a way.
You have, uh, a big enterprise, finance solution that everyone uses for the finance needs of your business, but there are some things that it doesn't provide for that you have a person that's doing a lot of, and the business says, Okay. well, this thing, this human is doing this is really beneath their capability. We need to get a software solution for it, but our enterprise solution just can't account for it. So let's get a RPA capability in here. We can build it ourselves, and then there we go. So there, there are many reasons to do that. financial, IT might not have, um, the capability or the funding to actually build and solve the solution. Or it it's at a scale that is too small to open up, uh, an IT project to solve for. Um, so, you know, a team of five is just doing this and they're doing it for, you know, 20 hours a week, which is uh large, but in a big enterprise, that's not really. Maybe um, worth building an enterprise solution for it. or, and this is a big one. There are regulatory constraints and security constraints around being able to access this or communicate some data or information in a way that is non-human or programmatic. So that's really where, um, RPA is correctly and best applied and you'll see it most often.
So what we're talking about there is in finance, in healthcare or in big companies where they're dealing with a lot of user data or customer data in a way. So when we talk about finance and healthcare, there are a lot of regulatory constraints and security reasons why you would not enable a programmatic solution to operate on your systems.
You know, it's just too hard. We we're not going to expose our databases or our data to any other thing. It would, it would take a huge enterprise project to build out that capability, secure that capability and ensure it's going correctly. We just don't have the money the time or the strength honestly, to afford for it.
So they say, well, we already have. a user pattern. We already allow users to, to talk to this information and communicate this information. Let's get an RPA tool, which for all intents and purposes will be acting as a user. And then it can just automate that process without us exposing to queries or any other thing, an enterprise solution or programmatic, um, solution.
So that's really why RPA, where and why you, you would apply it is there's, there's just no capability at enterprise for one reason or another to solve for it.
[00:08:47] Jere…
playlist_add
Sep 16, 2021
Deployment from Scratch with Josef Strzibny
Josef Strzibny is the author of Deployment from Scratch and a current Fedora contributor. He previously worked on the Developer Experience team at Red Hat.
This episode originally aired on Software Engineering Radio.
Links:
* Deployment from Scratch
* @strzibnyj
* systemd
* Introduction to Control Groups
* SELinux
* Fedora
* Rocky Linux
* Puma
* AppSignal
* Datadog
* Rollbar
* Skylight
* Bootstrapping a multiplayer server with Elixir at X-Plane
* StackExchange Performance
* Chruby
* Password Safe
* Vault
* Rails Custom Credentials
Transcript:
You can help edit this transcript on GitHub.
[00:00:00] Jeremy: Today, I'm talking to Josef Strzibny.
He's the author of the book deployment from scratch. A fedora contributor. And he previously worked on the developer experience team at red hat.
Josef welcome to software engineering radio.
[00:00:13] Josef: Uh, thanks for having me. I'm really happy to be here.
There are a lot of commercial services…
playlist_add
May 29, 2021
Quality Assurance Testing
Michael Ashburne and Maxwell Huffman are QA Managers at Aspiritech.
This episode originally aired on Software Engineering Radio.
Related Links:
* Aspiritech
* Section 508 Test for Accessibility
* ANDI Accessibility Testing Tool
* Windows Hardware Compatibility Program
* Audio over Bluetooth
Transcript
You can help edit this transcript on GitHub.
Jeremy: [00:00:00] Today I'm joined by Maxwell, Huffman and Michael Ashburn. They're both QA managers at Aspiritech. I'm going to start with defining quality assurance. Could one of you start by explaining what it is?
Maxwell: [00:00:15] So when I first joined Aspiritech, I was kind of curious about that as well. One of the main things that we do at Aspiritech besides quality assurance is we also, give meaningful employment to individuals on the autism spectrum. I myself am on the autism spectrum and that's what, initially attracted me to the company.
quality assurance in a nutshell is making sure that, products and software is…
playlist_add
Mar 23, 2021
Scott Hanselman on What's .NET?
Scott is the Community Program Manager for the .NET team at Microsoft and the host of the Hanselminutes podcast.
This episode originally aired on Software Engineering Radio.
Personal Links and Projects:
* @shanselman
* Hanselminutes
* Blog
* YouTube Channel
Related Links:
* .NET (How to get started)
* What is .NET?
* Common Language Runtime (CLR) Overview
* NuGet (package manager)
* Techempower Benchmarks (ASP.NET core)
* Mono runtime (Cleanroom .NET implementation)
* Unity (Write games using C#)
* Xamarin (.NET Mobile apps)
* .NET nanoFramework (embedded devices / microcontrollers)
* .NET foundation
* .NET interactive
* Blazor (Client web apps with .NET)
* Single file deployment and executable
* All About Span: Exploring a New .NET Mainstay
* Virtual Desktop is what VR needs
* SE Radio 394 Chris McCord on Phoenix LiveView
Transcript:
You can help edit this transcript on GitHub.
Jeremy: [00:00:00] Today I'm talking to Scott Hanselman. He'…
playlist_add
Feb 25, 2021
Distributed Systems and Careers with Shubheksha Jalan
Shubheksha is a Software Engineer at Apple. She previously worked at Monzo and Microsoft.
Personal Links and Projects:
* @scribblingon
* Lessons learnt in year three as a software engineer
* Personal Site
* Systems Recipes
* Computers Illustrated
Other interviews about getting into open source:
* Code Newbie
* Software Engineering Daily
Related Links:
* Monzo Service Graph
* Go context
* An Illustrated Proof of the CAP theorem
* Apache Cassandra
* Distributed System Building Block: Flake Ids
* Protocol Buffers
* Go rpc
* Consul
* Envoy
* What is a Runbook?
* Error Budgets Explained
* Kubernetes
* Go by Example: Errors
Music by Crystal Cola.
Jeremy: This is Jeremy Jung and you're listening to software sessions. Today, I'm talking to Shubheksha Jalan about working with distributed systems, the go programming language and some of the lessons she's learned being a software engineer for the last three years. Previously, she worked as a backend…
playlist_add
Dec 17, 2020
React Authentication with Ryan Chenkie
Ryan is the author of Advanced React Security Patterns and Securing Angular Applications. He picked up his authentication expertise working at Auth0. Currently, he's a GraphQL developer advocate at Prisma.
Related Links:
* @ryanchenkie
* React Security
* Stop using JWTs for Sessions
* What are cookies and sessions?
* Learn how HTTP Cookies work
* JSON Web Token Introduction
* Refresh Tokens: When to Use Them and How They Interact with JWTs
* Critical Vulnerabilities in JSON Web Token Libraries
* RS256 vs HS256: What's the difference?
Music by Crystal Cola.
Transcript
You can help edit this transcript on GitHub.
Jeremy: [00:00:00] Today, I'm talking to Ryan Chenkie. He used to work for Auth0 and he has a new course out called advanced react security patterns.
I think authentication is something that often doesn't get included in tutorials, or if it's in there, there's a disclaimer that says, this isn't how you do it in production. So I thought it would be good…
playlist_add
Dec 2, 2020
iOS Development with Timirah James
Timirah is an iOS developer, developer advocate, founder of the TechniGal LA meetup group, and instructor for O'Reilly and Coursera.
Related Links
* @timirahj
* Swift Optionals
* Stanford CS193p - Developing Apps for iOS
* Hacking with Swift
* Ray Wenderlich
* Swift
* Objective C
* Xcode
* Flutter
* Dart
Music by Crystal Cola.
Transcript
You can help edit this transcript on GitHub.
Jeremy: [00:00:03] Today I'm talking to Tamirah James. She's been an iOS developer for... how many years has it been?
Timirah: [00:00:09] Oh my goodness. Since I first started iOS, I want to say ooh (whispering) oh my gosh seven years.
Jeremy: [00:00:15] Seven years. Where did that time go?
Timirah: [00:00:17] My goodness. Oh yeah. Seven years. Wow.
Jeremy: [00:00:21] I think a lot of people listening have written software before, but maybe not for iOS. So I'm interested to hear what your experience is and how you think people should get into it.
Timirah: [00:00:31] Absolutely.…
playlist_add
Nov 18, 2020
Object Relational Mappers with Julie Lerman
Related Links:
* @julielerman
* The Data Farm (Julie's blog)
* Entity Framework
* Dapper
* Automapper
* Pluralsight Courses
This episode was originally posted on Software Engineering Radio.
Transcript
You can help edit this transcript on GitHub.
Jeremy: [00:00:00] Today I'm talking to Julie Lerman. She's a frequent conference speaker, an independent consultant and a Pluralsight course author. Today we're going to talk about her experience working on ORMs and Entity Framework.
Julie, welcome to software engineering radio.
Julie: [00:00:16] Hey, Jeremy. Thanks so much for having me.
Jeremy: [00:00:18] For those who aren't familiar with ORMs what are they and why do we need them?
Julie: [00:00:23] The first thing is the definition so ORM stands for object relational mapper. It's a software idea and implementation in many aspects for taking the concepts that we describe as classes and transforming them into the structure of a relational database. So you can get the dat…
playlist_add
Nov 3, 2020
Fixing a Broken Development Process
John Doran is the CTO of Phorest, an application for managing salons and spas.
We discuss:
- Transitioning a desktop application to a SaaS
- Struggling with outages and performance problems
- Moving away from relying on a single person for deployment
- Building a continuous integration pipeline
- Health monitoring for services
- The benefits of docker
- Using AWS managed services like Aurora and ECS
This episode originally aired on Software Engineering Radio.
Transcript
Jeremy: [00:00:00] Today I have John Doran with me. John is the director of engineering at Phorest, a Dublin based SAAS company, that processes appointments for the hair and beauty industry. He previously worked as a technical lead at Travelport digital, where he supported major airlines and hotel chains with their mobile platforms.
I'll be speaking with John about the early days of their business, the challenges they faced while scaling and how they were able to reshape their processes and team to overcome these c…
playlist_add
Oct 7, 2020
Building Maps using Leaflet
We cover:
* Choosing Leaflet vs other mapping libraries
* Sources for mapping layers
* Using GeoJSON to store data
* Raster vs vector data
* Working with live positions such as car data
* Picking a database with geospatial queries
* Using frontend frameworks with Leaflet
* Leaflet plugins
* Desktop vs Mobile
* His work on the Leaflet-Geoman plugin
Related Links
* Leaflet
* Leaflet-Geoman
* GeoJSON
* Geoman
* Mapbox
This episode was originally on Software Engineering Radio.
Transcript
You can help edit this transcript on GitHub.
Jeremy: Today, I'm speaking with Sumit Kumar. Sumit is the head of engineering at Share Now, which is previously car2go. He's also the creator of an open source plugin called leaflet-geoman, which provides drawing tools for the leaflet mapping library.
I'll be speaking with Sumit about his experience working with leaflet and how developers can build mapping applications with it. Sumit, welcome to software engineering radio.…
playlist_add
Sep 22, 2020
WebAssembly on the Server with Krustlet
Taylor Thomas is an Engineer at Azure, the core maintainer of the Kubernetes Package Manager Helm, and a member of the Krustlet team.
Timestamps
* [00:55] - Kubernetes
* [07:37] - WebAssembly
* [12:06] - WebAssembly Runtimes and WASI Specification
* [15:42] - WebAssembly vs Containers vs Native Binaries
* [25:11] - Krustlet and the case for writing it in Rust
* [30:52] - Missing APIs in WASI
* [33:38] - Wascc vs Wasmtime runtimes
* [38:15] - Rust ecosystem for Kubernetes and WebAssembly
* [40:23] - Comparing other languages to Rust
* [45:09] - Rust learning curve, experiences as a beginner
* [53:16] - Next steps for Krustlet and WebAssembly
Related Links
* @_oftaylor
* Krustlet
* Kubernetes
* Open Container Initiative
* WebAssembly
* WASI
* Wasmtime
* waSCC
* WebAssembly meets Kubernetes with Krustlet
* Introducing Krustlet, the WebAssembly Kubelet
* Kubernetes: A Rusty Friendship
* The Safety Boat: Kubernetes and Rust
* A Heaping Hel…
playlist_add
Sep 9, 2020
Building the Lucky Web Framework in Crystal with Paul Smith
Paul Smith is a Software Engineer at GitHub and the creator of the Lucky web framework. He previously worked at heroku and thoughtbot and has experience building applications using Rails and Phoenix. He's also the creator of the Bamboo e-mail package and the co-creator of the ExMachina test data package for Elixir.
We discuss:
* The tradeoffs of object oriented and functional programming
* How a lack of compile time guarantees slow down ruby and elixir development
* Creating conversational error messages
* Ways fast languages can change how you write applications
* Writing templates with Crystal instead of HTML
* Choosing what to include in a web framework
* The Crystal community and ecosystem
Related Links:
* @paulcsmith
* The Crystal programming language
* The Lucky web framework
* HTML2Lucky
* AlpineJS
This episode originally aired on Software Engineering Radio.
Transcript:
You can help edit this transcript on GitHub.
Jeremy: Today I'm talking with Pa…
playlist_add
Aug 26, 2020
Life after JPEG with Henri Helvetica
Henri is a frequent conference speaker and organizer of the Toronto Web Performance and JAMStack meetups.
We discuss:
* Managing images with features like lazy loading and the picture tag
* Handling varying network conditions on mobile
* Making designers a part of the performance conversation
* The WebP image format that could replace JPEG and PNG
* Ways the GIF can be an MP4 in disguise
* How lighthouse has given websites a visible target for performance
* What we can learn from "lite" news sites
Conference Talks
* A Decade of Disciplined Delivery
* Shape Of The Web
* Moving Pictures: A Snapshot At the Future of Web Media
Related Links
* @HenriHelvetica
* Cloudinary
* Picture tag
* Network Information API
* WebP
* Responsive images done right: a guide to picture and srcset
* Use srcset to automatically choose the right image
* Mozilla: Improving JPEG Image Encoding (Mozilla explains why they want to stick with JPEG in 2014)
* The Great JPEG…
playlist_add
Aug 12, 2020
The battle for your privacy on the web with Pete Snyder
Pete is the senior security researcher at Brave Software and the co-chair of the W3C Privacy Interest Group.
We discuss:
* The differences between academic research and product development
* How websites track us with cookies, fingerprinting, and other techniques
* The surprising amount of data your browser gives up without a permission prompt
* What features should go in the browser vs being native only
* The confusion behind what incognito or private modes do
* The role of EasyList and the underappreciated people behind it
* Building tools like PageGraph to identify and rewrite tracking code
* Replacing resources at page load to preserve privacy without breaking websites
* Developing web standards at the W3C while preserving privacy
* Brave's plan to fund websites with ads instead of paywalls while preserving user privacy
* Getting involved in privacy and web standards
Related Links
* @pes10k
* Personal Site
* Privacy Interest Group (PING)
* W3C Priv…
playlist_add
Jul 29, 2020
Functional Programming in Enterprise Applications with Vladimir Khorikov
Vlad is a Pluralsight course creator and the author of Unit Testing: Principles, Practices, and Patterns.
We discuss:
* Immutability
* Error handling
* Avoiding null
* Preventing invalid state
* Updating existing applications
This episode originally aired on Software Engineering Radio.
Related Links
* @vkhorikov
* Enterprise Craftsmanship
* Is Entity the same as Value Object?
* Combining ASP.NET Core validation attributes with Value Objects
* Error handling: Exception or Result?
* Applying Functional Principles in C#
* F# for Fun and Profit
Transcript
You can help edit this transcript on GitHub.
Jeremy: [00:00:05] Hey, this is Jeremy Jung for Software Engineering Radio. Today. I'm talking with Vladimir Khorikov. Vladimir is the author of the book Unit Testing: Principles, Practices and Patterns he's a Microsoft MVP, and he's the author of many Pluralsight courses including Applying Functional Principles in C#, and today we're going to be talking about fu…
playlist_add
Jul 15, 2020
Open Source Onboarding with Brian Douglas
Brian is a Senior Developer Advocate at GitHub and was previously a Developer Advocate at Netlify.
We discuss:
* Unintentional gatekeeping
* Formal onboarding for your projects
* The value of discord communities for newcomers
* Streaming issue triage and programming on twitch
* How Open Sauced helps developers get involved with open source
Related Links
* @bdougieYO
* Open Sauced
* ExpressJS Triager Guide
* GraphiQL
* Babel's contributing guide (Gives suggestions on familiarizing yourself with codebase)
* Webpack's funding page
* SE Unlocked episode with Dan Abramov
* Explore GitHub
* Changelog Nightly
* Code Triage
* Figma
* Discord
Twitch Streams
* bdougieYO
* jlengstorf
* Noopkat
Music by Crystal Cola: 12:30 AM / Orion
You can help edit this transcript on GitHub.
Jeremy: [00:00:00] This is Jeremy Jung and today I'm talking to Brian Douglas, he's a senior developer advocate at GitHub, the host of JAMstack radio and the creator of open…
playlist_add
Jul 1, 2020
Senior engineers and baby managers with Lauren Tan
Lauren is a Software Engineer on the React Organization's Web Core team at Facebook and was previously an Engineering Manager at Netflix.
We discuss:
* Being empowered to say "no" as a senior engineer
* Straddling the line between engineer and manager
* The programmer's midlife crisis
* Resisting the urge to use clever abstractions
If you enjoyed this discussion with Lauren, be sure to check out her episode on the Changelog.
Music by Crystal Cola: 12:30 AM / Orion
Related Links
* @sugarpirate_
* Personal Site
* The Engineer / Manager Pendulum
* Should I Become a Tech Lead?
* Does it Spark Joy?
* Changelog Episode - Engineer to Manager and Back Again
* Dan Abramov's Redux twitter post
Transcript
You can help edit this transcript on GitHub.
Jeremy: [00:00:00] Hey, this is Jeremy. Usually when software developers are talking career progression, it moves in the direction from being a software engineer to becoming an engineering manager. And today I'm talking…
playlist_add
Jun 17, 2020
Learning in Public with Swyx
Swyx is a senior developer advocate at AWS, an instructor at Egghead, and the author of The Coding Career Playbook.
We discuss:
* Getting help without having a big following
* Remixing and summarizing what others create
* Creating Friendcatchers
* Betting on technologies
* His new book "The Coding Career Playbook"
Music by Crystal Cola: 12:30 AM / Orion
Related Links
* @swyx
* Personal Site
* The Coding Career Playbook
* 1% rule
* Lindy Effect
* Learn in Public
* The Ultimate Hack for Learning in Public
* The Day I Became a Software Engineer
* Developer's Guide to Tech Strategy
* Every Public Engineering Career Ladder
* Friendcatchers
* React Typescript Cheatsheet
* Steve Yegge's Google Platforms Rant
* DynamoDB Book
* Egghead
* Frontend Masters
* How I Write Backends
Transcript
You can help edit this transcript on GitHub.
Jeremy: I did a computer science bachelor's.
Swyx: [00:00:45] Nice.
Jeremy: [00:00:46] It's interesting seeing…
playlist_add
Jun 3, 2020
Writing for Software Developers with Philip Kiely
Philip Kiely is the author of Writing for Software Developers and has written for companies like Smashing Magazine, CSS-Tricks, and Twilio.
We discuss:
* Doing research beyond the first page of search results
* Writing e-mails people will read
* The "get it done" and "learning" modes of readers
* Making articles easily skimmable
* Long form articles vs Stack Overflow
* Promoting and launching a book
* Borrowing the reputation of others
Related Links:
* Writing for Software Developers
* Personal Site
* @philip_kiely
* Stripe documentation example (Complete code sample with switchable frontends, backends, and walkthrough as you scroll)
* Go by Example (Straightforward samples readers can copy/paste)
* Tailwind UI (Sustains Tailwind CSS open source project by providing prebuilt components)
Music by Crystal Cola: 12:30 AM / Orion
Transcript
You can help edit this transcript on GitHub.
Jeremy: [00:00:35] This episode, I'm talking to Phillip Kiely. He's the…
playlist_add
May 19, 2020
Localizing and Porting Japanese Games with Sara Leen
Sara Leen is a localization programmer for XSEED Games on titles like Ys, Trails in the Sky, and Corpse Party. She got her start reverse engineering and fan translating games.
We discuss:
* What makes games different
* How games store and encode text
* Rewriting Corpse Party (and not being able to run it for a year!)
* Porting and modernizing games
* Reverse engineering raw assembly
This episode originally aired on Software Engineering Radio.
Related Links:
* @SaraJLeen
* Personal Site
* Corpse Party PC Programming Blog
* Trails in the Sky Second Chapter Localization Blog 5
* Mojibake (Garbled text when text is decoded using the wrong encoding)
* Shift JIS (Japanese character encoding used in older games)
* Hot Soup Processor (Obscure programming language used for Corpse Party)
* XSEED Games
Music by Crystal Cola: 12:30 AM / VHS Skyline
Transcript
You can help edit the transcript on GitHub.
Jeremy: Hey, this is Jeremy Jung. This episode, I'm talking…
playlist_add
May 7, 2020
Creating Tuple using WebRTC with Spencer Dixon
Spencer Dixon is the CTO and cofounder of Tuple, a pair programming application for remote developers.
We discuss:
* How WebRTC works
* Capturing audio and video
* Choosing a video codec
* NAT traversal
* Choosing a native application over Electron
* Diving into C++ and MacOS development
* Getting expert help
This episode was originally on Software Engineering Radio.
Related Links:
* @spencercdixon
* Tuple
* WebRTC
* Introduction to WebRTC Protocols
* WebRTC Mozilla Docs
* WebRTC Hacks
* Discuss WebRTC Google Group
* WebRTC by Dr Alex
* Cosmo Software
* High Performance Browser Networking
playlist_add
Apr 23, 2020
Building Indie Hackers with Courtland Allen
Courtland Allen is the founder of Indie Hackers, a community for people who want to start bootstrapped and profitable businesses. It was acquired by Stripe in 2017.
We discuss:
* Why a SPA was the wrong choice
* Caching strategies
* Using firebase and algolia
* Fighting spam
* Why he hasn't hired another engineer
* Focusing on the right problems
* Being a part of Stripe
Related Links:
* Indie Hackers
* @csallen
* Stripe
* How to Build a Life You Love by Quitting Everything Else with Lynne Tye of Key Values (One of Courtland's favorite podcast episodes)
* Ember (SPA framework)
* Ember fastboot (Server Side Rendering)
* Firebase (Authentication provider and NoSQL database)
* Algolia (Provides search for posts)
* Render (Web Host)
* Dribbble (Site to find design inspiration)
* Egghead (Developer video courses, got started selling zip files of videos to mailing lists)
* Balsamiq (Wireframing tool, added inspirational quotes to their loading screen…
playlist_add
Apr 8, 2020
League of Legends Gameplay Engineering with Iris Zhang
Iris Zhang is a gameplay engineer at Riot Games on the League of Legends Champions Engineering team. She previously worked on backend services at Microsoft.
We discuss:
* Working at Microsoft and Riot Games
* Finding a role and team that fits you
* Backend services vs gameplay engineering
* Building features, testing, and debugging gameplay
* Using internal tools to create game logic
Related Links:
* Personal Site
* @riotnyanbun
* Clean Code (Book used by Microsoft team)
* Spring Framework (Java web framework used by League of Legends)
* Chef (Deployment tool used at Riot)
* Hazelcast (Cache that Riot Games switched to)
* What it's like to work on League of Legends
* Sylas (Champion that can steal ultimates)
* Clash (Public facing mode worked on by backend team)
Music by Crystal Cola: 12:30 AM / Orion
playlist_add
Mar 25, 2020
Async Programming and TCP Sockets in C# with Stephen Cleary
Stephen Cleary is the author of the Concurrency in C# Cookbook and a Microsoft MVP. He has also written many blog posts on asynchronous programming.
We discuss:
* Why he calls manual thread creation legacy code
* Using Async/Await and the Task Parallel Library instead of Threads
* APIs to avoid when writing concurrent applications
* Why you shouldn't write TCP Sockets
* Continuously reading from a socket to detect errors
* Building state machines to manage socket connections
Related Links:
* @aSteveCleary
* Getting Started with Async/Await
* TCP/IP Sockets
* There is no Thread
* Concurrency in C# Cookbook
Music by Crystal Cola:
* Intro: 12:30 AM
* Outro: Orion
playlist_add
Mar 11, 2020
How I write backends with Federico Pereiro
Federico has been writing backends for web applications since 2012 and is the co-founder and chef of alto;code. He wrote a post on GitHub named "How I write backends" that summarizes his process.
We discuss:
* His current stack
* Redis as a primary data store
* Reducing the number of layers in your software
* How duplicating input validation makes code harder to understand
* Integration tests over unit tests
* Minimizing dependencies
* Why you should never normalize alerts
Federico Pereiro
* Personal Site
* How I write backends
* Our company
* ac;pic, our pictures application
* ac;tools, our backend services
Related Links
Fred Brooks & The Mythical Man Month (conceptual integrity)
Steve Yegge - Code's worst enemy
Steve Yegge - Platforms rant (no backdoors, all services talking through the wire as if they were external actors)
Book of Hook - Suffer no jankiness
Taiichi Ohno & the Toyota Production System
Auto-activation in software
playlist_add
Feb 26, 2020
From agency to startup with Noah Labhart
Noah is the CTO and cofounder of Veryable, an on-demand marketplace for manufacturing, logistics, and warehousing labor.
He's also the host of the Code Story podcast where tech leaders reflect on the path they took to create their products.
We talk about:
* Leaving the corporate world
* How poor estimation and scoping nearly sunk his agency
* Why bad software is worse than no software
* Hiring for an agency vs a startup
* Validating ideas and finding your first customers
Noah Labhart
* Personal Site
* LinkedIn
Other Links
* Code Story (Noah's podcast)
* Veryable (Current startup)
* Touchtap (Mobile app agency being wound down)
* Alcon (Previous employer)
* Dev Mountain Bootcamp (Bootcamp that Noah hired from)
Music by Crystal Cola
playlist_add
Feb 12, 2020
The good parts of AWS with Daniel Vassallo
Daniel is the co-author of the book "The Good Parts of AWS" and previously worked at AWS on the CloudWatch team. He left last year after over 8 years at Amazon to work on his own projects.
He's currently working on an end-to-end encrypted user database SaaS called Userbase. Daniel is also openly sharing his experiences building an audience, writing a book, and building Userbase on twitter.
We talk about:
* Why AWS has so many services
* His default AWS stack and how he chose it (Dynamo, SQS, S3 and EC2)
* Why he uses EC2 over ECS or EBS
* Why services like RDS and ElastiCache aren't in his book
* The difference between SQS and Kinesis
* Why AWS will probably never build a Heroku-like service
* The future of AWS
Daniel Vassallo
* Personal Site
* @dvassallo
Other Links
* The Good Parts of AWS
* Userbase
* Only Intrinsic Motivation Lasts
playlist_add
Jan 29, 2020
A decade long retrospective with Ben Orenstein
Ben is the CEO of Tuple, a pair programming application for remote developers.
He currently co-hosts The Art of Product with Derrick Reimer.
We talk about:
* His first crazy programming job
* Why you should speak at conferences
* The trade-offs of remote work
* Why great coworkers should be the #1 priority for new developers
* How these are "the good old days" of Tuple
* Ben's favorite smash bros character
* ...and much more!
Ben Orenstein
* Personal Site
* @r00k
Podcasts
* The Art of Product
* Giant Robots (Ben hosted this podcast until episode 240)
Other Links
* Tuple (Remote pair programming application)
* Refactoring Rails (Ben's video course)
* How to talk to developers (Fantastic talk for anyone giving presentations)
* Upcase (Rails, vim, and tmux video tutorials)
playlist_add
Jan 15, 2020
Bringing GeoCities Back with Kyle Drake
Kyle is the creator of Neocities a free web hosting site that encourages people to build creative personal websites in the spirit of GeoCities. He's currently working on restorativland where people interested in the history of the web can discover websites originally hosted at places like GeoCities and Myspace Music.
Kyle Drake
* Personal Site
* @kyledrake
Projects
* Neocities
* restorativland
Other Links
* Yahoo! Geocities - Wikipedia
* What is BGP?
* What is Anycast?
* Vultr (Neocities hosting provider)
Timestamps
* [00:00:50] What GeoCities was
* [00:06:45] Why the old web failed
* [00:15:06] Reasons to create Neocities
* [00:21:04] Fighting phishing, spam, and DMCA takedowns
* [00:27:17] Purchasing an IPv4 address block and building an Anycast CDN
* [00:43:28] Why create your own CDN? (Takedown requests come directly to you, reduced chances of hosting provider shutting you down)
* [00:51:09] The costs of running a CDN ($130 a month)
* [01:07:…
playlist_add
Jan 1, 2020
Rebuilding Fathom Analytics on Serverless Infrastructure with Jack Ellis
Jack Ellis
* Personal Site
* @JackEllis
Fathom Analytics
* Fathom Analytics (SAAS version, Affiliate link with $10 discount)
* Fathom Lite (Open-source, original Golang version)
* We rebuilt Fathom Analytics from the ground up and moved to Laravel Vapor
* How we built a GDPR compliant website analytics platform without using cookies
Laravel
* Laravel (PHP web framework)
* Laravel Vapor (Serverless provisioning and deployment tool)
Hosting Providers
* Digital Ocean (Host for Open-source version)
* Heroku (Host for 1st rewrite)
* AWS (Host for 2nd rewrite)
AWS Services Used
* ElastiCache (Redis)
* Elastic Load Balancing (Handles web requests and triggers Lambda functions)
* Relational Database Service (MySQL)
* Simple Queue Service (Message Queue)
* Lambda (Run functions without managing a server)
Other Links
* Things you should never do (Post Jack mentions on never rewriting software)
Timestamps
* [00:00:58] What's Fathom Analytics and ho…
playlist_add
Dec 19, 2019
Creating Static Sites in Rust with Vincent Prouillet
Vincent is the creator of Zola (Formerly Gutenburg), a Static Site Generator built with Rust and Tera, a Jinja2-like template engine.
If you create a site with Zola, Vincent would appreciate you adding your site to the EXAMPLES file in the repository.
You can also take a look at the source for this website which is currently built with Zola.
Vincent Prouillet
* Personal Site
* @20100Prouillet
Zola
* Zola Website
* Zola Forum
Tools/Crates used by Zola
* pulldown-cmark (Markdown)
* syntec (Syntax highlighting using Sublime Text definitions)
* rayon (Parallel computation)
* heaptrack (Memory Profiler)
Static Site Hosts
* Github Pages
* Netlify
Crates for Web Applications
* jsonwebtoken
* Bcrypt
* Validator
Compiled Template Engines
* askama
* maud
* horrowshow
Runtime Template Engines
* Tera (Jinja2-like HTML template engine)
* ramhorns
* rust-mustache
Static Site Generators
* Hugo
* Jekyll
* Pelican
Other links
* Forestry…
playlist_add
Dec 6, 2019
Load Balancing and HAProxy with Daniel Corbett
Daniel is the Director of Product at HAProxy Technologies.
This episode originally aired on Software Engineering Radio.
Theme music is 12:30 AM by Crystal Cola.
Links
* HAProxy Community Edition
* HAProxy Technologies Blog
* @danielcorbett_
* Keepalived
* Linux Virtual Server
* Nginx
* Envoy
Timestamps and Transcript are coming soon.
playlist_add
Nov 20, 2019
Choosing the Right Job with Cassidy Williams
Cassidy is a developer and instructor at React Training and the Director of Outreach at cKeys, a Seattle based organization that promotes learning electronics through mechanical keyboards. She previously worked at Amazon, CodePen, L4 Digital, Clarifai, and Venmo. However, she's probably best known for promoting diversity in tech, creating cool mechanical keyboards, and making memes.
Cassidy
Personal Website
@cassidoo
Current Work
React Training
cKeys
Keyboards
Follow your dreams (literally): How I designed and launched the Official Scrabble Keyboard
Astrolokeys (Collaboration with Amy Wibowo)
Notes App
Bear
Resources for new conference speakers
@CallbackWomen
You've got this!
Theme music is 12:30 AM by Crystal Cola.
Timestamps
* [00:36] Organizing and completing side projects
* [05:08] Choosing and quitting jobs
* [09:03] Joining React Training
* [12:31] Why Amazon was a poor fit and figuring out what's important
* [17:46] Leaving a company with a smooth transition…
playlist_add
Nov 6, 2019
Building Scalable Systems Safely in Ruby with Samuel Williams
Samuel is a member of the Ruby core team. He's working on making it safer and easier to write scalable applications in Ruby.
Conference Talks:
Fibers are the Right Solution
The Journey to One Million
Posts:
Asynchronous Ruby
Fibers Are the Right Solution
Early Hints and HTTP/2 Push with Falcon
2019 Ruby Association Grant
Source with comments on why the Global VM Lock exists
Ruby gems:
Async
Falcon
Contact:
@ioquatix
Samuel's website
Timestamps:
* 0:51 - What's concurrency? What's parallelism?
* 5:49 - Piping commands between Unix processes provides easy parallelism
* 6:58 - Some types of applications abstract out threads/processes,
* 9:27 - Many Ruby gems have thread safety issues
* 10:44 - The CRuby Global VM Lock hides thread safety issues
* 11:24 - The problems with threads and shared mutable state
* 13:58 - Examples of mutexes causing problems in Ruby gems.
* 19:09 - What a deadlock is and how it causes problems
* 19:51 - Running separate processes to get pa…
playlist_add
Oct 24, 2019
How the Ruby Runtime Works with Aaron Patterson
Aaron is on both the ruby and rails core teams. He's best known for making puns, teaching others, and his contributions to the internals of ruby. Lately he's been focusing on a compacting garbage collector for ruby.
This episode originally aired on Software Engineering Radio.
Timestamps:
* 00:40 - What Aaron likes about Ruby
* 04:43 - Interpreted vs Compiled
* 07:00 - Why the ruby interpreter is written in C
* 11:00 - Other good languages to write virtual machines?
* 15:20 - Moving from an Interpreter (MRI) to Virtual Machine (YARV)
* 18:50 - Why there's no manual compilation step in Ruby
* 23:28 - Why compile to bytecode instead of directly to machine code?
* 26:34 - Stack based vs Register based VM
* 28:00 - Differences between Core and Standard Library
* 29:46 - Do you program more in ruby or C as a member of the ruby/rails core teams?
* 30:30 - The Global Interpreter Lock (GIL / GVL)
* 37:40 - Concurrency options in Ruby
* 45:55 - Just in Time Compilati…
playlist_add
Oct 10, 2019
Pod Hunt and Side Projects with Mubashar Iqbal
Mubs is an amazingly prolific creator. He's built 85 side projects which are all listed on his website and was Product Hunt's Maker of the Year in 2016. His output is inspiring and he offers great advice on how to approach building side projects of your own.
Mubashar Iqbal
* Personal Site
* @mubashariqbal
* Projects
Projects
* Pod Hunt
* Hacker News Day
* Will Robots Take My Job?
Pod Hunt Stack
* Laravel
* Laravel Forge
* Tailwind CSS
* VueJS
* MySQL
Timestamps
* 01:14 - What's Pod Hunt?
* 03:42 - How are people using Pod Hunt?
* 08:42 - Why Pod Hunt isn't a native app yet
* 11:25 - How long to build the prototype?
* 15:50 - Pod Hunt's Stack
* 16:55 - Why Pod Hunt isn't a Single Page Application
* 22:18 - No CDN yet
* 23:24 - MySQL as the datastore
* 24:24 - Laravel Forge for hosting
* 28:13 - What's Hacker News Day?
* 34:06 - Choose a side project that solves your own problem
* 40:43 - The difference between projects for fun vs mon…
playlist_add
Sep 27, 2019
How to Teach Programming with Felienne
Felienne is an associate professor at Leiden University who brings a unique perspective on programming education backed by scientific research. She also runs the Programming Education Research Lab (PERL) in order to study the best ways to teach programming.
Keynote at Strange Loop
* How to Teach Programming (and other things?)
Related Research Papers
* How is Programming Taught at Code Clubs
* The Effect of Reading Code Aloud on Comprehension: An Empirical Study with School Students
* Code Phonology
* Why Minimal Guidance During Instruction Does Not Work
* Cognitive Architecture and Instructional Design: 20 Years Later
* Papers by Brianna Morrison
Felienne
* Blog
* Twitter
* Publications
* Software Engineering Radio Podcast
Bonus
* St. Louis City Museum
Timestamps
* 00:56 - Spreadsheets as programming
* 04:57 - When do you build software vs use what's already there?
* 10:14 - Direct instruction vs independent learning
* 20:28 - How should you s…
playlist_add
Sep 16, 2019
How HTTP Works with Julia Evans
Julia Evans is best known for her zines and blog posts that break down technical topics in a friendly way. She has written educational material on everything from Linux system calls to working with managers.
She joins us to talk about what she learned while writing her latest zine: HTTP: Learn your browser's language.
Timestamps:
* 0:50 - Why write a zine about HTTP?
* 1:21 - What's a header that could break your site?
* 2:50 - What does HTTP look like?
* 5:58 - What headers are most important?
* 8:39 - Response Codes
* 12:26 - Authentication
* 14:57 - Cookies
* 18:37 - Using browser development tools
* 19:46 - Caching and CDNs
* 25:46 - Referrer Header and Hotlinking images
* 27:34 - Resuming file downloads
* 30:00 - URLs
* 32:11 - Why webpages show different languages
* 34:34 - Same Origin Policy / CORS
* 43:42 - Compression / GZIP
* 45:58 - Intermediate Programming Education
* 49:35 - Picking topics for blogs and zines
* 57:10 - Picking an audi…
playlist_add
Sep 13, 2019
Rust in Production with Armin Ronacher
Topics:
* Deciding when to use Rust
* Concurrency in Rust
* When to create a separate service
* Introducing Rust at Sentry
* Challenges of writing Python modules in Rust
* Creating Symbolicator, a Rust web service that processes debug files
* Using Actix to create Symbolicator
* Why Rust doesn't need a Django or Rails equivalent
* Concerns about the stability of the Rust ecosystem and the lack of shared solutions
* What's missing in the Rust ecosystem
* Why developers need better debugging tools
If you're interested in helping Armin build an open source debugging community, reach out to him via e-mail or twitter.
This episode is part of the Rustacean Station feed. Check it out if you're interested in Rust podcasts.
Links:
* Armin's Twitter
* Armin's Blog
* Sentry
* Actix
* Rocket
* Building Sentry: Symbolicator
* Symbolicator
* Semaphore
* Milksnake
* Wasmer
* Existential Types
* Tokio Tower
* RFC to add Backtraces to standard error…
playlist_add