Software Sessions
Jeremy Jung
Subscribe
Practical conversations about software development.
Available episodes
Newest first
Oldest first
3 days ago
Mayra Navarro on Getting to RubyConf (RubyConf 2023)
Mayra Navarro is an organizer of WNB.rb and Ruby Perú.
Mayra shares how the Ruby community helped her get to RubyConf, going from project manager to developer, and the different ways people learn and communicate.
This is the final interview recorded at RubyConf 2023 in San Diego.
--
* Mayra's Github
* Peruvian Digital Platform
* Codeable bootcamp Groups
* Ruby Perú
* WNB.rb
* Atlanta Ruby People
* Cody Norman
* Stefanni Brasil of hexdevs
* Dave Kimura of Drifting Ruby Conferences
* RubyConf
* RailsConf
-- Transcript
You can help correct transcripts on GitHub.
[00:00:00] Jeremy: I hope you've been enjoying the conversations from RubyConf. Before we get started. I just want to say thank you to everyone. I met at the conference, all the guests who were so generous with their time. And to Irene from RubyConf for arranging a space and helping me connect with guests.
[00:00:16] This final interview is with Mayra Navarro. She's an organizer of the Ruby community in Lima, Peru and a member of the women and non-binary Ruby online community. She's going to tell us how the community pulled together. Both friends of hers and strangers she had never met. To get her to RubyConf this year, we start the story in April where she's just finished attending the Ruby on rails conference, RailsConf in Atlanta. Getting to RubyConf
[00:00:44] Mayra: So the thing is, in the last RailsConf, the last day that I was in the US, um, the day that I was returning to Peru, I got fired. (laughs) Yes. So I was with all the stress.
[00:01:01] All the luggages that I had to pick or maybe overweight or something like that. And then I received that
[00:01:08] Jeremy: Oh my gosh.
[00:01:09] Mayra: And I, oh my gosh, what I can do?
[00:01:13] Jeremy: That's terrible.
[00:01:15] Mayra: It was awful. Since that, I think it was May 1st or something like that. And I was looking for job like everybody else who were fired all these times It was a difficult time for me. my plan was just before September I get a job so I have enough money and not using my, my savings for, for going to the RailsConf. Sorry, the RubyConf. but, uh, eventually at the end of September, October, I didn't get anything.
[00:01:44] I'm Christian. So I, well, God doesn't want me to come here.
[00:01:50] it there must be a reason, but there was something inside me that. I just to have to do something else. and I thank to my mom because she's someone that is always fighting for what she wants.
[00:02:02] So I say, okay, I went to sleep that day that I say, okay, maybe I don't want to go. So next day I have the idea. Maybe you didn't use your last card. There is something else. That is something that I have from my mom. I can feel that. I say, what if you ask for money? Well, like a fundraising, I learned about that word later, and I say what, what else could you lose you don't have anything to lose right now.
[00:02:30] So I say, okay, I'm going to write something. I asked Cody Norman, that is someone that I really appreciate right now. I asked him about suggestions, if that's a good idea or no, maybe not. He said, yes, you can do it. Uh, and I asked him if he could help me with the speech because I tried to write something and also I'm not good at writing things on Twitter and especially asking for money because I had to be open myself and be vulnerable to do that.
[00:03:02] And it was like, uh, the last break for myself
[00:03:05] a... I sent the speech to Cody, he helped me to update some things that I have to just improve. And I did it. I, also, I didn't know how to open a GoFundMe campaign because that's only for the US and Mexico. I think it doesn't exist in Peru.
[00:03:23] So he said, Oh, there is another page that you can go.
[00:03:27] I did it. So I just published that. I didn't open that until three, four hours later, because I was like, no, I don't want to see. And then I, I open it and I started to contact with the people who.
[00:03:44] Well, who knows me because I like to be connected with a lot of people. I'm part of the FL RB even being in Peru, I am part of the FL RB. I go attend to the Atlanta Ruby Group. I go, I, I know a lot of people because of the conference. I try to help to the woman and non binary community also. I am organizer of the Ruby Peru, but I didn't want to ask them money for them, but I have some close friends from the conference that I, that I go for all.
[00:04:13] All these two years. So they helped me to share that. And in two days, I got the money.
[00:04:20] It was like a, I can't believe it. It is what, and I'm not good open myself for things like that. I love helping people, but it's difficult when I, you have to help yourself. So. All these people who I could see their names because it's, it's transferred to PayPal.
[00:04:39] So I could see their name is like, uh, I really appreciate the thing that they don't know me. Some people, they don't know me, but, but I know them. I know who you are, if you're listening to this and I thank you appreciate for doing that. I also had the opportunity because I need to talk about this. I got a ticket from HexDev, uh, from Stephanie.
[00:05:01] Jeremy: Oh... Hexdevs. Yeah.
[00:05:02] Mayra: Yes. And, also I applied for the volunteer positions, just in case But I got the volunteer position. So what I did is, besides all my expense, I mean, that trip and also the hotel, expenses, I don't know, does it work? I, I said, I'm going to give this ticket that I have left to one of the women in the wnb community.
[00:05:25] So I did that and say, I have a ticket and also I can share the room. I don't want to say her name because She's trying not to be too connected to social media, but she, she accepted sharing the room with me.
[00:05:40] Jeremy: Yeah.
[00:05:43] Mayra: So she's already here with me and I feel so happy because People not only helping me, they helping me to help and it feel like, wow.
[00:05:53] Yeah. And that is, that is my story. And I still, well, I accepted to come to talk about this today because I received a job offer in the morning that I accepted.
[00:06:06] So I wanted to. Send a happy ending for all my story about this. Yeah. And especially because I know that in the next conference I'll be with my own money, I could say, expenses. Asking for help
[00:06:20] Jeremy: So was this all this year, the RailsConf? That was this year where you, you went to the conference, you enjoyed the talks and you were employed. And so it was the day that it was over that you, you found out that you got laid off. Wow. it's this, you have this high, right, you've met all your friends and, you know, you're learning all this stuff and you're really excited.
[00:06:42] And then you get this notice and it's like, what, what happened?
[00:06:47] Mayra: Yeah. That is what's happening.
[00:06:50] Jeremy: then you, you kind of, like you said, you opened yourself up but yeah, it takes courage to say like, Hey, I need, you know, I need some help.
[00:06:57] Mayra: Yeah, it's, this is something that I learned about this is always asking for help. This is something that I have been I bring into my life is always asking for help. I know as a woman, uh, as a woman, I have the thing that Try to be strong sometimes. I can do it by myself. I don't need help.
[00:07:16] I don't need help, but sometimes you need, as human, you can open yourself. It's not something related to
[00:07:23] gender it's more like humanity. That's how I feel right now. That is the feeling that I have and that is what is going to keep with me. For the rest of my life, I know. (laughs)
[00:07:33] Jeremy: Yeah. Cause I, I think when, when people don't know, they, they might assume because you're so involved, right. With your, your local community and then the community internationally where people just assume that, Hey, Mayra is doing great. Right? She's, she's got no problems, no issues, and, there's just no way for peopl…
playlist_add
Nov 21, 2023
Mike Perham on Keeping it solo (RubyConf 2023)
Mike Perham is the creator of Sidekiq, a background job processor for Ruby. He's also the creator of Faktory a similar product for multiple language environments.
We talk about the RubyConf keynote and Ruby's limitations, supporting products as a solo developer, and some ideas for funding open source like a public utility.
Recorded at RubyConf 2023 in San Diego.
-- A few topics covered:
* Sidekiq (Ruby) vs Faktory (Polyglot)
* Why background job solutions are so common in Ruby
* Global Interpreter Lock (GIL)
* Ractors (Actor concurrency)
* Downsides of Multiprocess applications
* When to use other languages
* Getting people to pay for Sidekiq
* Keeping a solo business
* Being selective about customers
* Ways to keep support needs low
* Open source as a public utility Mike
* Mike's blog
* mastodon
* Sidekiq
* faktory
* From Employment to Independence Ruby
* Ractor
* The Practical Effects of the GVL on Scaling in Ruby Transcript
You can help correct transcripts on GitHub. Introduction
[00:00:00] Jeremy: I'm here at RubyConf San Diego with Mike Perham. He's the creator of Sidekiq and Faktory.
[00:00:07] Mike: Thank you, Jeremy, for having me here. It's a pleasure. Sidekiq
[00:00:11] Jeremy: So for people who aren't familiar with, I guess we'll start with Sidekiq because I think that's what you're most known for. If people don't know what it is, maybe you can give like a small little explanation.
[00:00:22] Mike: Ruby apps generally have two major pieces of infrastructure powering them. You've got your app server, which serves your webpages and the browser. And then you generally have something off on the side that... It processes, you know, data for a million different reasons, and that's generally called a background job framework, and that's what Sidekiq is.
[00:00:41] It, Rails is usually the thing that, that handles your web stuff, and then Sidekiq is the Sidekiq to Rails, so to speak.
[00:00:50] Jeremy: And so this would fit the same role as, I think in Python, there's celery. and then in the Ruby world, I guess there is, uh, Resque is another kind of job.
[00:01:02] Mike: Yeah, background job frameworks are quite prolific in Ruby. the Ruby community's kind of settled on that as the, the standard pattern for application development. So yeah, we've got, a half a dozen to a dozen different, different examples throughout history, but the major ones today are, Sidekiq, Resque, DelayedJob, GoodJob, and, and, and others down the line, yeah. Why background jobs are so common in Ruby
[00:01:25] Jeremy: I think working in other languages, you mentioned how in Ruby, there's this very clear, preference to use these job scheduling systems, these job queuing systems, and I'm not. I'm not sure if that's as true in, say, if somebody's working in Java, or C sharp, or whatnot. And I wonder if there's something specific about Ruby that makes people kind of gravitate towards this as the default thing they would use.
[00:01:52] Mike: That's a good question. What makes Ruby... The one that so needs a background job system. I think Ruby, has historically been very single threaded. And so, every Ruby process can only do so much work. And so Ruby oftentimes does, uh, spin up a lot of different processes, and so having processes that are more focused on one thing is, is, is more standard.
[00:02:24] So you'll have your application server processes, which focus on just serving HTTP responses. And then you have some other sort of focused process and that just became background job processes. but yeah, I haven't really thought of it all that much. But, uh, you know, something like Java, for instance, heavily multi threaded.
[00:02:45] And so, and extremely heavyweight in terms of memory and startup time. So it's much more frequent in Java that you just start up one process and that's it. Right, you just do everything in that one process. And so you may have dozens and dozens of threads, both serving HTTP and doing work on the side too. Um, whereas in Ruby that just kind of naturally, there was a natural split there. Global Interpreter Lock
[00:03:10] Jeremy: So that's actually a really good insight, because... in the keynote at RubyConf, Mats, the creator of Ruby, you know, he mentioned the, how the fact that there is this global, interpreter lock,
[00:03:23] or, or global VM lock in Ruby, and so you can't, really do multiple things in parallel and make use of all the different cores. And so it makes a lot of sense why you would say like, okay, I need to spin up separate processes so that I can actually take advantage of, of my, system.
[00:03:43] Mike: Right. Yeah. And the, um, the GVL. is the acronym we use in the Ruby community, or GIL. Uh, that global lock really kind of is a forcing function for much of the application architecture in Ruby. Ruby, uh, applications because it does limit how much processing a single Ruby process can do. So, uh, even though Sidekiq is heavily multi threaded, you can only have so many threads executing.
[00:04:14] Because they all have to share one core because of that global lock. So unfortunately, that's, that's been, um, one of the limiter, limiting factors to Sidekiq scalability is that, that lock and boy, I would pay a lot of money to just have that lock go away, but. You know, Python is going through a very long term experiment about trying to remove that lock and I'm very curious to see how well that goes because I would love to see Ruby do the same and we'll see what happens in the future, but, it's always frustrating when I come to another RubyConf and I hear another Matt's keynote where he's asked about the GIL and he continues to say, well, the GIL is going to be around, as long as I can tell.
[00:04:57] so it's a little bit frustrating, but. It's, it's just what you have to deal with. Ractors
[00:05:02] Jeremy: I'm not too familiar with them, but they, they did mention during the keynote I think there Ractors or something like that. There, there, there's some way of being able to get around the GIL but there are these constraints on them. And in the context of Sidekiq and, and maybe Ruby in general, how do you feel about those options or those solutions?
[00:05:22] Mike: Yeah, so, I think it was Ruby 3. 2 that introduced this concept of what they call a Ractor, which is like a thread, except it does not have the global lock. It can run independent to the global lock. The problem is, is because it doesn't use the global lock, it has pretty severe constraints on what it can do.
[00:05:47] And the, and more specifically, the data it can access. So, Ruby apps and Rails apps throughout history have traditionally accessed a lot of global data, a lot of class level data, and accessed all this data in a, in a read only fashion. so there's no race conditions because no one's changing any of it, but it's still, lots of threads all accessing the same variables.
[00:06:19] Well, Ractors can't do that at all. The only data Ractors can access is data that they own. And so that is completely foreign to Ruby application, traditional Ruby applications. So essentially, Ractors aren't compatible with the vast majority of existing Ruby code. So I, I, I toyed with the idea of prototyping Sidekiq and Ractors, and within about a minute or two, I just ran into these, these, uh...
[00:06:51] These very severe constraints, and so that's why you don't see a lot of people using Ractors, even still, even though they've been out for a year or two now, you just don't see a lot of people using them, because they're, they're really limited, limited in what they can do. But, on the other hand, they're unlimited in how well they can scale.
[00:07:12] So, we'll see, we'll see. Hopefully in the future, they'll make a lot of improvements and, uh, maybe they'll become more usable over time. Downsides of multiprocess (Memory usage)
[00:07:19] Jeremy: And with the existence of a job queue or job…
playlist_add
Nov 18, 2023
Sara Jackson on Teaching in Kanazawa (RubyConf 2023)
Sara is a team lead at thoughtbot.
She talks about her experience as a professor at Kanazawa Technical College, giant LAN parties in Rochester, transitioning from Java to Ruby, shining a light on maintainers, and her closing thoughts on RubyConf.
Recorded at RubyConf 2023 in San Diego.
-- A few topics covered:
* Being an Assistant Arofessor in Kanazawa
* Teaching naming, formatting, and style
* Differences between students in Japan vs US
* Technical terms and programming resources in Japanese
* LAN parties at Rochester
* Transitioning from Java to Ruby
* Consulting
* The forgotten maintainer
* RubyConf Other links
* Sara's mastodon
* thoughtbot
* This Week in Open Source
* testdouble
* Ruby Central Scholars and Guides Program
* City Museum Japan
* International College of Technology Kanazawa
* RubyKaigi
* Applying mruby to World-first Small SAR Satellite (Japanese lightning talk) (mruby in space) Rochester
* Rochester Institute of Technology
* Electronic Gaming Society
* Tora-con
* Strong National Museum of Play Transcript
You can help correct transcripts on GitHub.
[00:00:00] Jeremy: I'm here at RubyConf, San Diego, with Sara Jackson, thank you for joining me today.
[00:00:05] Sara: Thank you for having me. Happy to be here.
[00:00:07] Jeremy: Sara right now you're working at, ThoughtBot, as a, as a Ruby developer, is that right?
[00:00:12] Sara: Yes, that is correct. Teaching in Japan
[00:00:14] Jeremy: But I think before we kind of talk about that, I mean, we're at a Ruby conference, but something that I, I saw, on your LinkedIn that I thought was really interesting was that you were teaching, I think, programming in. Kanazawa, for a couple years.
[00:00:26] Sara: Yeah, that's right. So for those that don't know, Kanazawa is a city on the west coast of Japan. If you draw kind of a horizontal line across Japan from Tokyo, it's, it's pretty much right there on the west coast. I was an associate professor in the Global Information and Management major, which is basically computer science or software development. (laughs) Yep.
[00:00:55] Jeremy: Couldn't tell from the title.
[00:00:56] Sara: You couldn't. No.. so there I was teaching classes for a bunch of different languages and concepts from Java to Python to Unix and Bash scripting, just kind of all over.
[00:01:16] Jeremy: And did you plan the curriculum yourself, or did they have anything for you?
[00:01:21] Sara: It depended on the class that I was teaching. So some of them, I was the head teacher. In that case, I would be planning the class myself, the... lectures the assignments and grading them, et cetera. if I was assisting on a class, then usually it would, I would be doing grading and then helping in the class. Most of the classes were, uh, started with a lecture and then.
Followed up with a lab immediately after, in person.
[00:01:54] Jeremy: And I think you went to, is it University of Rochester?
[00:01:58] Sara: Uh, close. Uh, Rochester Institute of Technology. So, same city. Yeah.
[00:02:03] Jeremy: And so, you were studying computer science there, is that right?
[00:02:07] Sara: I, I studied computer science there, but I got a minor in Japanese language. and that's how, that's kind of my origin story of then teaching in Kanazawa. Because Rochester is actually the sister city with Kanazawa. And RIT has a study abroad program for Japanese learning students to go study at KIT, Kanazawa Institute of Technology, in Kanazawa, do a six week kind of immersive program.
And KIT just so happens to be under the same board as the school that I went to teach at.
[00:02:46] Jeremy: it's great that you can make that connection and get that opportunity, yeah.
[00:02:49] Sara: Absolutely. Networking!
[00:02:52] Jeremy: And so, like, as a student in Rochester, you got to see how, I suppose, computer science education was there. How did that compare when you went over to Kanazawa?
[00:03:02] Sara: I had a lot of freedom with my curriculum, so I was able to actually lean on some of the things that I learned, some of the, the way that the courses were structured that I took, I remember as a freshman in 2006, one of the first courses that we took, involved, learning Unix, learning the command line, things like that.
I was able to look up some of the assignments and some of the information from that course that I took to inform then my curriculum for my course,
[00:03:36] Jeremy: That's awesome. Yeah. and I guess you probably also remember how you felt as a student, so you know like what worked and maybe what didn't.
[00:03:43] Sara: Absolutely. And I was able to lean on that experience as well as knowing. What's important and what, as a student, I didn't think was important. Naming, formatting, and style
[00:03:56] Jeremy: So what were some examples of things that were important and some that weren't?
[00:04:01] Sara: Mm hmm. For Java in particular, you don't need any white space between any of your characters, but formatting and following the general Guidelines of style makes your code so much easier to read. It's one of those things that you kind of have to drill into your head through muscle memory. And I also tried to pass that on to my students, in their assignments that it's.
It's not just to make it look pretty. It's not just because I'm a mean teacher. It is truly valuable for future developers that will end up reading your code.
[00:04:39] Jeremy: Yeah, I remember when I went through school. The intro professor, they would actually, they would print out our code and they would mark it up with red pen, basically like a writing assignment and it would be like a bad variable name and like, white space shouldn't be here, stuff like that. And, it seems kind of funny now, but, it actually makes it makes a lot of sense.
[00:04:59] Sara: I did that.
[00:04:59] Jeremy: Oh, nice.
[00:05:00] Sara: I did that for my students. They were not happy about it. (laughs)
[00:05:04] Jeremy: Yeah, at that time they're like, why are you like being so picky, right?
[00:05:08] Sara: Exactly. But I, I think back to my student, my experience as a student. in some of the classes I've taken, not even necessarily computer related, the teachers that were the sticklers, those lessons stuck the most for me. I hated it at the time. I learned a lot.
[00:05:26] Jeremy: Yeah, yeah. so I guess that's an example of things that, that, that matter. The, the aesthetics or the visual part for understanding. What are some things that they were teaching that you thought like, Oh, maybe this isn't so important.
[00:05:40] Sara: Hmm.
Pause for effect. (laughs) So I think that there wasn't necessarily Any particular class or topic that I didn't feel was as valuable, but there was some things that I thought were valuable that weren't emphasized very well. One of the things that I feel very strongly about, and I'm sure those of you out there can agree. in RubyWorld, that naming is important.
The naming of your variables is valuable. It's useful to have something that's understood. and there were some other teachers that I worked with that didn't care so much in their assignments. And maybe the labs that they assigned had less than useful names for things. And that was kind of a disappointment for me.
[00:06:34] Jeremy: Yeah, because I think it's maybe hard to teach, a student because a lot of times you are writing these short term assignments and you have it pass the test or do the thing and then you never look at it again.
[00:06:49] Sara: Exactly.
[00:06:50] Jeremy: So you don't, you don't feel that pain. Yeah,
[00:06:53] Sara: Mm hmm. But it's like when you're learning a new spoken language, getting the foundations correct is super valuable.
[00:07:05] Jeremy: Absolutely. Yeah. And so I guess when you were teaching in Kanazawa, was there anything you did in particular to emphasize, you know, these names really matter because otherwise you or…
playlist_add
Nov 17, 2023
David Copeland on Medium Sized Decisions (RubyConf 2023)
David was the chief software architect and director of engineering at Stitch Fix. He's also the author of a number of books including Sustainable Web Development with Ruby on Rails and most recently Ruby on Rails Background Jobs with Sidekiq.
He talks about how he made decisions while working with a medium sized team (~200 developers) at Stitch Fix.
The audio quality for the first 19 minutes is not great but the correct microphones turn on right after that.
Recorded at RubyConf 2023 in San Diego.
A few topics covered:
* Ruby's origins at Stitch Fix
* Thoughts on Go
* Choosing technology and cloud services
* Moving off heroku
* Building a platform team
* Where Ruby and Rails fit in today
* The role of books and how different people learn
* Large Language Model's effects on technical content Related Links
* David's Blog
* Mastodon Transcript
You can help correct transcripts on GitHub. Intro
[00:00:00] Jeremy: Today. I want to share another conversation from RubyConf San Diego. This time it's with David Copeland. He was a chief software architect and director of engineering at stitch fix.
And at the start of the conversation, you're going to hear about why he decided to write the book, sustainable web development with Ruby on rails. Unfortunately, you're also going to notice the sound quality isn't too good. We had some technical difficulties. But once you hit the 20 minute mark of the recording, the mics are going to kick in. It's going to sound way better.
So I hope you stick with it. Enjoy. Ruby at Stitch Fix
[00:00:35] David: Stitch Fix was a Rails shop. I had done a lot of Rails and learned a lot of things that worked and didn't work, at least in that situation.
And so I started writing them down and I was like, I should probably make this more than just a document that I keep, you know, privately on my computer. Uh, so that's, you know, kind of, kind of where the genesis of that came from and just tried to, write everything down that I thought what worked, what didn't work.
Uh, if you're in a situation like me. Working on a product, with a medium sized, uh, team, then I think the lessons in there will be useful, at least some of them. Um, and I've been trying to keep it up over, over the years. I think the first version came out a couple years ago, so I've been trying to make sure it's always up to date with the latest stuff and, and Rails and based on my experience and all that.
[00:01:20] Jeremy: So it's interesting that you mention, medium sized team because, during the, the keynote, just a few moments ago, Matz the creator of Ruby was talking about how like, Oh, Rails is really suitable for this, this one person team, right? Small, small team. And, uh, he was like, you're not Google. So like, don't worry about, right.
Can you scale to that level? Yeah. Um, and, and I wonder like when you talk about medium size or medium scale, like what are, what are we talking?
[00:01:49] David: I think probably under 200 developers, I would say. because when I left Stitch Fix, it was closing in on that number of developers. And so it becomes, you know, hard to...
You can kind of know who everybody is, or at least the names sound familiar of everybody. But beyond that, it's just, it's just really hard. But a lot of it was like, I don't have experience at like a thousand developer company. I have no idea what that's like, but I definitely know that Rails can work for like...
200 ish people how you can make it work basically. yeah.
[00:02:21] Jeremy: The decision to use Rails, I'm assuming that was made before you joined?
[00:02:26] David: Yeah, the, um, the CTO of Stitch Fix, he had come in to clean up a mess made by contractors, as often happens. They had used Django, which is like the Python version of Rails.
And he, the CTO, he was more familiar with Rails. So the first two developers he hired, also familiar with Rails. There wasn't a lot to maintain with the Django app, so they were like, let's just start fresh, fresh with Rails. yeah, but it's funny because a lot of the code in that Rails app was, like, transliterated from Python.
So you could, it would, it looked like the strangest Ruby code in the world because it was basically, there was no test. So they were like, let's just write the Ruby version of this Python just so we know it works. but obviously that didn't, didn't last forever, so.
[00:03:07] Jeremy: So, so what's an example of a, of a tell?
Where you're looking at the code and you're like, oh, this is clearly, it came from Python.
[00:03:15] David: You'd see like, very, very explicit, right? Like Python, there's a lot of like single line things. very like, this sounds like a dig, but it's very simple looking code. Like, like I don't know Python, but I was able to change this Django app.
And I had to, I could look at it and you can figure out immediately how it works. Cause there's. Not much to it. There's nothing fancy. So, like, this, this Ruby code, there was nothing fancy. You'd be like, well, maybe they should have memoized that, or maybe they should have taken that into another class, or you could have done this with a hash or something like that.
So there was, like, none of that. It was just, like, really basic, plain code like you would see in any beginning programming language kind of thing. Which is at least nice. You can understand it. but you probably wouldn't have written it that way at first in Ruby. Thoughts on Go
[00:04:05] Jeremy: Yeah, that's, that's interesting because, uh, people sometimes talk about the Go programming language and how it looks, I don't know if simple is the right word, but it's something where you look at the code and even if you don't necessarily understand Go, it's relatively straightforward.
Yeah. I wonder what your thoughts are on that being a strength versus that being, like,
[00:04:25] David: Yeah, so at Stitch Fix at one point we had a pro, we were moving off of Heroku and we were going to, basically build a deployment platform using ECS on AWS. And so the deployment platform was a Rails app and we built a command line tool using Ruby.
And it was fine, but it was a very complicated command line tool and it was very slow. And so one of the developers was like, I'm going to rewrite it in Go. I was like, ugh, you know, because I just was not a big fan. So he rewrote it in Go. It was a bazillion times faster. And then I was like, okay, I'm going to add, I'll add a feature to it.
It was extremely easy. Like, it's just like what you said. I looked at it, like, I don't know anything about Go. I know what is happening here. I can copy and paste this and change things and make it work for what I want to do. And it did work. And it was, it was pretty easy. so there's that, I mean, aesthetically it's pretty ugly and it's, I, I.
I can't really defend that as a real reason to not use it, but it is kind of gross. I did do Go, I did a small project in Go after Stitch Fix, and there's this vibe in Go about like, don't create abstractions. I don't know where I got that from, but every Go I look at, I'm like we should make an abstraction for this, but it's just not the vibe.
They just don't like doing that. They like it all written out. And I see the value because you can look at the code and know what it does and you don't have to chase abstractions anywhere. But. I felt like I was copying and pasting a lot of, a lot of things. Um, so I don't know. I mean, the, the team at Stitch Fix that did this like command line app in go, they're the platform team.
And so their job isn't to write like web apps all day, every day. There's kind of in and out of all kinds of things. They have to try to figure out something that they don't understand quickly to debug a problem. And so I can see the value of something like go if that's your job, right? You want to go in and see what the issue is.
Figure it out and be done and you're not going to necessarily develop deep…
playlist_add
Nov 15, 2023
ChaelCodes on The Joy of Programming Games and Streaming (RubyConf 2023)
Episode Notes
Rachael Wright-Munn (ChaelCodes) talks about her love of programming games (games with programming elements in them, not how to make games!), starting her streaming career with regex crosswords, and how streaming games and open source every week led her to a voice acting role in one of her favorite programming games.
Recorded at RubyConf 2023 in San Diego.
mastodon twitch Personal website
Programming Games mentioned:
* Regex Crossword
* SHENZHEN I/O
* EXAPUNKS
* 7 Billion Humans
* One Dreamer
* Code Rom@ntic
* Bitburner Transcript
You can help edit this transcript on GitHub.
Jeremy: I'm here at RubyConf San Diego with Rachel Wright-Munn, and she goes by Chaelcodes online. Thanks for joining me today.
Rachael: Hi, everyone. Hi, Jeremy. Really excited to be here.
Jeremy: So probably the first thing I'll ask about is on your web page, and I've noticed you have streams, you say you have an interest in not just regular games, but programming games, so.
Rachael: Oh my gosh, I'm so glad you asked about this. Okay, so I absolutely love programming games. When I first started streaming, I did it with Regex Crossword. What I really like about it is the fact that you have this joyful environment where you can solve puzzles and work with programming, and it's really focused on the experience and the joy. Are you familiar with Zach Barth of Zachtronics?
Jeremy: Yeah. So, I've tried, what was it? There's TIS-100. And then there's the, what was the other one? He had one that's...
Rachael: Opus Magnum? Shenzhen I/O?
Jeremy: Yeah, Shenzhen I/O.
Rachael: Oh, my gosh. Shenzhen I/O is fantastic. I absolutely love that. The whole conceit of it, which is basically that you're this electronics engineer who's just moved to Shenzhen because you can't find a job in the States. And you're trying to like build different solutions for these like little puzzles and everything.
It was literally one of the, I think that was the first programming game that really took off just because of the visuals and everything.
And it's one of my absolute favorites. I really like what he says about it in terms of like testing environments and the developer experience.
Cause it's built based on assembly, right?
He's made a couple of modifications. Like he's talked about it before where it's like The memory allocation is different than what it would actually look like in assembly and the way the registers are handled I believe is different, I wouldn't think of assembly as something that's like fun to write, but somehow in this game it is. How far did you get in it?
Jeremy: Uh, so I didn't get too far. So, because like, I really like the vibe and sort of the environment and the whole concept, right, of you being like, oh, you've been shipped off to China because that's the only place that these types of jobs are, and you're working on these problems with bad documentation and stuff like that. And I like the whole concept, but then the actual writing of the software, I was like, I don't know.
Rachael: And it's so hard, one of the interesting things about that game is you have components that you drop on the board and you have to connect them together and wire them, but then each component only has a specific number of lines. So like half the time I would be like, oh, I have this solution, but I don't have enough lines to actually run it or I can't fit enough components, then you have to go in and refactor it and everything. And it's just such a, I don't know, it's so much fun for me. I managed to get through all of the bonus levels and actually finish it. Some of them are just real, interesting from both a story perspective and interesting from a puzzle perspective. I don't wanna spoil it too much. You end up outside Shenzhen, I'll just say that.
Jeremy: OK. That's some good world building there.
Rachael: Yeah.
Jeremy: Because in your professional life, you do software development work. So I wonder, what is it about being in a game format where you're like, I'm in it. I can do it more. And this time, I'm not even being paid. I'm just doing it for fun.
Rachael: I think for me, software development in general is a very joyful experience. I love it. It's a very human thing. If you think about it like math, language, all these things are human concepts and we built upon that in order to build software in our programs and then on top of that, like the entire purpose of everything that we're building is for humans, right? Like they don't have rats running programs, you know what I mean? So when I think about human expression and when I think about programming, these two concepts are really closely linked for me and I do see it as joyful, But there are a lot of things that don't spark joy in our development processes, right? Like lengthy test suites, or this exhausting back and forth, or sometimes the designs, and I just, I don't know how to describe it, but sometimes you're dealing with ugly code, sometimes you're dealing with code smells, and in your professional developer life, sometimes you have to put up with that in order to ship features. But when you're working in a programming game, It's just about the experience. And also there is a correct solution, not necessarily a correct solution, but like there's at least one correct solution. You know for a fact that there's, that it's a solvable problem.
And for me, that's really fun. But also the environment and the story and the world building is fun as well, right? So one of my favorite ones, we mentioned Shenzhen, but Zachtronics also has Exapunks. And that one's really fun because you have been infected by a disease. And like a rogue AI is the only one that can provide you with the medicine you need to prevent it. And what this disease is doing is it is converting parts of your body into like mechanical components, like wires and everything. So what you have to do as an engineer is you have to write the code to keep your body running. Like at one point, you were literally programming your heart to beat. I don't have problems like that in my day job. In my day job, it's like, hey, can we like charge our customers more? Like, can we put some banners on these pages? Like, I'm not hacking anybody's hearts to keep them alive.
Jeremy: The stakes are a little more interesting. Yeah, yeah.
Rachael: Yeah, and in general, I'm a gamer. So like having the opportunity to mix two of my passions is really fun.
Jeremy: That's awesome. Yeah, because that makes sense where you were saying that there's a lot of things in professional work where it's you do it because you have to do it. Whereas if it's in the context of a game, they can go like, OK, we can take the fun problem solving part. We can bring in the stories. And you don't have to worry about how we're going to wrangle up issue tickets.
Rachael: Yeah, there are no Jira tickets in programming games.
Jeremy: Yeah, yeah.
Rachael: I love what you said there about the problem solving part of it, because I do think that that's an itch that a lot of us as engineers have. It's like we see a problem, and we want to solve it, and we want to play with it, and we want to try and find a way to fix it. And programming games are like this really small, compact way of getting that dopamine hit.
Jeremy: For sure. Yeah, it's like. Sometimes when you're doing software for work or for an actual purpose, there may be a feeling where you want to optimize something or make it look really nice or perform really well. And sometimes it just doesn't matter, right? It's just like we need to just put it out and it's good enough. Whereas if it's in the context of a game, you can really focus on like, I want to make this thing look pretty. I want to feel good about this thing I'm making.
Rachael: You can make it look good, or you can make it look ugly. You don't have to maintain it. After it runs, it's done. Right, right, right. There's this one game. It's 7 Billion Humans. And…
playlist_add
Sep 20, 2023
Daniel Zingaro and Leo Porter on learning to program with LLMs
Dr. Daniel Zingaro and Dr. Leo Porter are co-authors of the book Learn AI-Assisted Python Programming.
Leo will teach an introductory computer science course this quarter at UCSD using this book. We discuss how tools like GitHub Copilot let people new to programming focus on breaking down problems instead of language syntax.
Dr. Zingaro is an Associate Professor of Computer Science at University of Toronto Mississauga and Dr. Porter is an Associate Professor at University of California San Diego.
This episode was originally posted on Software Engineering Radio. Topics covered:
* Making programming more accessible
* Teaching problem decomposition instead of language syntax
* The importance of reading and testing untrusted generated code
* The rise of throwaway or one-off code
* Concerns about relying on commercial tools
* Rethinking how to assess students Related Links
* Learn AI-Assisted Python Programming
* Leo Porter
* Daniel Zingaro
* GitHub Copilot Transcript
You can help edit this transcript on GitHub.
Note the timestamps and audio for this transcript will not completely match. Intro
[00:00:00] Jeremy: Today I'm talking to Dr. Leo Porter. He's an associate teaching professor of computer science at the University of California San Diego, and he co-founded the computing education research laboratory there.
I'm also joined by Dr. Daniel Zingaro who is an associate teaching professor of computer science at the University of Toronto. And he's also the author of the book, learn to Code by Solving Problems and the Book, Algorithmic Thinking. They are co-authors of the book, learn AI Assisted Python programming.
Leo and Dan, welcome to Software Engineering Radio.
[00:00:37] Leo: Thank you for having us, Jeremy. I really appreciate your podcast, so thanks. Great to be here.
[00:00:41] Dan: Thanks Jeremy. Writing a book for Leo's CS1 class
[00:00:43] Jeremy: The first thing we could start with is, is why this book? And, and why now? How did you decide on like, okay, this is the thing we need to do now.
[00:00:51] Leo: So, uh, this is Dan. Uh, so Dan, um, like really early when LLMs first kind of were coming out and being seen on the scene for programming, uh, he started playing with them, uh, for programming projects. And I think Dan really quickly realized that they'd had this, a big impact on how we teach programming. so he reached out to me, uh, and said, I really need to give em a try.
And, uh, after I played with them for a little while, I had the exact same realization that this is gonna change, uh, how we teach programming, uh, in a pretty dramatic way. So having realized that, having realized that we had to change our, uh, introductory CS1 courses, we knew we needed to do that, but in order to teach that class, we'd have to have a book that we could assign our students that that would go along with the class.
And so we knew we had to change the class, but we also knew we had to have a book for it. And given the, the timeline to write books, we started in the book first. Um, and so that's how it got started. LLMs for Syntax, Humans for breaking down problems
[00:01:45] Dan: I guess we figured out that our course had to change first, before we knew exactly, um, how it had to change. One thing we, um, learned early on was that the kinds of assignments we give in our introductory courses, they're just solved by, by these tools like ChatGPT and copilot.
So, uh, we knew something had to change, and then it is just a matter of figuring out what. And so we spent, um, quite a bit of time with these tools and we started to realize that what's gonna change is the skills that our students need to learn, uh, to be effective using these tools. So like b before these tools, we would spend a lot of time teaching syntax.
Um, and students struggle quite a bit with learning syntax, which I mean, it's very, it's, it's very frustrating, right? Cuz you can't even do anything until you get the syntax right? And you're getting all these errors like missing colons and, you know, mismatched braces and stuff like that. Uh, so it's actually good, that, the LLMs are doing the syntax for the students.
But you know, just because that skill's, uh, not needed as much, uh, doesn't mean that there aren't still skills for students to learn. So instead of syntax, other things become more important. Uh, so for example, uh, Leo and I, realize that reading code is gonna be extremely important even more so than before.
I think if, if that, if that's even possible. Uh, and that's because sometimes you're gonna get back code that just doesn't work. And so we realized that students are gonna need to be able to read, the response that they get to see if the code looks reasonable, or not, right? And then if the code, uh, I is unreasonable, then they need to read more code, uh, and look at other solutions, right, that they get from the, uh, LLM.
Uh, there are other, uh, things they can do as well, like messing around with the prompt and so on. But they're gonna need to be able to read code, uh, throughout the process. And then, so we just kind of kept on using these tools and documenting the skills that students are gonna need.
And we just kinda realized that all the skills students are gonna need are skills we would want to teach anyway. So like, uh, one more example is testing, right? So, students may now not have, uh, an understanding of every last detail of, you know, the Python language like they would before. And so then that makes testing even more important, right?
Than it was they need to verify that the code they're getting is correct. And so they have to be very good at writing test cases. and, and, you know, similar, similar for debugging, we need our students to have strong debugging skills, again, even potentially stronger than before, right? Because if the code isn't working, they need to first determine what the code is doing to be able to fix it. And then I guess one more I'll mention is problem decomposition. And this is a big one. I think this is gonna come up a couple times probably in our talk today, but LLMs struggle when you give them tasks that are too large and students need to know how to break problems down into small components so that, that, LLM can solve each one and, you know, have a good chance of getting it right.
[00:04:56] Leo: Yeah, I, I think, um, kind of to, to piggyback off of that, you, you may be hearing these skills and saying, oh, these are absolutely essential skills. Every software engineer should know, uh, these are being taught right now. Right? Um, and the answer is not really, like these aren't core topics in a lot of introductory CS classes because so much time is spent on syntax.
And so fairly early on when we kind of realized these skills would be so essential, Uh, we got really excited because these are skills we want to teach in our classes, and the LLMs are now giving us the ability to do that more.
[00:05:27] Dan: Mm-hmm.
[00:05:28] Jeremy: I think that's interesting about the syntax comment because you were saying how reading is gonna be more important than ever because you have LLM generating the code. Um, and you need to understand that code that's being generated and understand that it does what it, uh, you think it does.
And so I wonder if when you say you spend less time on syntax, is it because you feel like they're gonna generate this code and they're sort of organically gonna pick up syntax that way versus having to focus on it at the start? I'm just trying to picture what you see changing there.
[00:06:05] Dan: Yeah, Jeremy. So, uh, I, I was, I guess speaking specifically about syntax errors, which don't generally happen when you're using LLMs, and I also agree with you, you need to know what the code is doing, but, um, you can do that without worrying about each specific piece of syntax. Like, um, you're gonna need to know what the keywords do for sure, but, missing, you kno…
playlist_add
Jun 14, 2023
Anita Zhang and Alvaro Levia on systemd at Meta
systemd is a service manager for Linux. It is the first process that runs on many Linux distributions and manages all other user processes. It includes utilities for logging, process isolation, process dependencies, socket activation, and many other tasks.
psystemd is a python library to communicate with systemd over dbus from python as an alternative to shelling out from an application to control services.
Anita Zhang is an engineerd managerd at Meta and Alvaro Levia is a production engineer at Meta.
I attended their systemd workshop at the Southern California Linux Expo. Topics covered:
* What's systemd?
* Giving talks and workshops
* cgroups and namespaces
* systemd timers vs cron
* Migrating from CentOS 6 to 7
* Production engineers need to go lower in the stack to debug applications
* Meta's Linux userspace team
* Use of public cloud at Meta
* Meta's bootcamp
* Pystemd Mastodon
* Anita Zhang
* Alvaro Leiva Workshop
* systemd workshop Conference talks
* Journey into the Heart of systemd - Scale 19x
* Systemd: why you should care as a Python developer - PyCon 2018
* Move Fast without Breaking things - Scale 18x
* Solving All the Problems with systemd - LISA18
* Using systemd to high level languages - All Systems Go!
* The Curious Case of Memory Growth - Scale 19x Related Links
* systemd
* psystemd
* systemd-run
* systemd-timers Transcript
You can help edit this transcript on GitHub. Introductions
[00:00:00] Jeremy: So today I'm talking to Avaro Leiva and Anita Zhang. Avaro is the author of the pystemd library and he's a production engineer at Meta. And Anita is an engineerd managerd at Meta, and I'll let her explain that further.
[00:00:19] Jeremy: But thank you both for joining me today.
[00:00:21] Anita: Yeah, thanks for having us.
[00:00:24] Jeremy: I guess where we could start, Anita, maybe you could explain a little bit your, your title that I just gave you there. engineerd managerd
[00:00:31] Anita: Yeah, so by default I, I should be a software engineering manager, but when I transitioned to management, I was not, Ready to go public with, um, my transition.
So I kind of hid it by, changing the title. we have some weird systems in place that grep on like the word engineer. So I had to keep engineer in there somehow. and so I kind of polled my friends what I should change my title to, and they're like, oh, you're gonna support the systemd team, so you should change it to like managerd.
So I was like, sounds good. engineerd, managerd.
I didn't wanna get kicked out of any workplace groups, for example, that required me to be an engineer.
[00:01:15] Jeremy: Oh, okay.
[00:01:17] Anita: Or like engineering function, I guess.
[00:01:19] Jeremy: Yeah. Yeah. And you just gotta title it yourself, so as long as you got engineer in it, you're good.
[00:01:24] Anita: Yeah, pretty much. Some people have really fun titles like Chief Potato Officer and things like that.
[00:01:32] Jeremy: So what groups does the, uh, the potato officer get to go in?
[00:01:37] Anita: Yeah. Not the C level ones. (laughs) What's systemd?
[00:01:42] Jeremy: I guess maybe to, to start, we should explain to people who aren't familiar, uh, what systemd is. So if either of you wanna wanna take that one.
[00:01:52] Alvaro: so people who doesn't know, right?
So systemd is today is your init system, right? Is the thing that manage your, your process. and the best way to understand this, it is like when your computer, it needs to execute something. And that's something is what we call pid one. And that pid one is the thing that is gonna manage everything from now from there on, right?
Uh, in the most basic level, if you remember how to, how does program start, how does like an idea becomes a program? Uh, you need to fork exec, right? So that means that something has to be at the top of that tree and that is systemd. now that can be anything, right? So there was a time where that was like systemv and there was also like upstart, uh, today's systemd is the thing that, uh, it's shipped in most distributions.
[00:02:37] Jeremy: Yeah, because I, I definitely remember when I first started working with Linux, uh, it was with CentOS 6, and when I would want to run a service, I would have to go and write a bash script and kind of have all these checks for, is this thing running?
Does it have permission to these things, which user is it running as, and so there was a lot of stuff that I remember having to do before systemd came out.
[00:03:08] Alvaro: The good old days as we call them,
[00:03:11] Jeremy: Or the bad old days.
[00:03:13] Anita: Yeah. Depending on who you ask.
[00:03:15] Alvaro: Yeah. So, so that is super interesting because, um, During those time, like you said, you have to write a first script.
That means that you were basically yourself, your own service manager, right? So ideas as simple as, is my program running? There was no real answer. You have to figure it out, right? So if you run a program, uh, you maybe would create a pid file which hold the p or the pid of the process, of the main process, right?
And then something needs to check, oh, is this file exist? Does the file exist and does the content of this file actually match to a process? And then you grab the process. So it was all these ideas that you had to do, and then for, you have to do it for every single software that you would deploy on your machine, right?
That also makes really hard to parallelize stuff, right? Because you have no concept of dependencies. So if your computer has to put, uh, I, I dunno if you remember like long time ago, like Linux machine would, takes like five minutes to boot like your desktop. I remember like openSUSE. I can't remember, like 2008, 2007.
Uh, it would take like five minutes to boot and then Ubuntu came and, and it start like immediately. And it was because, you can parallelize things, but you cannot do that if all you're running are bash script. Why was systemd chosen to be included in Linux distributions?
[00:04:26] Jeremy: I remember before the Linux distributions didn't include it.
And I wonder if you have any insight into how systemd got chosen to be the thing to manage our processes and basically how we got to where we are today.
[00:04:44] Anita: I mean, we can kind of speculate a little bit. at the time when Lennart started systemd, um, with. Kai Sievers probably messed up his name there. Um, they were all at Red Hat and Red Hat manages fedora these days and I believe fedoras kind of like the bleeding edge for a lot of the new software ideas. Um, and when they picked up systemd as the defaults, um, eventually it started to trickle down to the rest of their distributions through RHEL and to CentOS and at the same time, I think other distributions started to see how useful it was in terms of managing all the different processes and services.
Um, I know Debian at one point had kind of a vote on like whether they should make systemd either default or like, make it easy to switch between both. And then they decided to just stick with systemd because it's, I mean, the public agrees that it's like easy to use and it's more useful.
It abstracts away a lot of things that they had to manually do before Who is interested in systemd? Who comes to your talks and workshops?
[00:05:43] Jeremy: Something I've been kind of curious about. So just this year at SCaLE uh, you ran a, a workshop teaching people how to use systemd and, and sort of what it is about. I guess when, when you get people coming to these workshops, what are they typically, where are they typically coming from? Are they like system administrators or are they software developers?
Like when you run these workshops, who are you looking for as your audience?
[00:06:13] Alvaro: To be fair, this was the first time that we actually did a workshop for this. But we have like, talk about this in, in many like conferences. here's w…
playlist_add
Jun 14, 2023
David Cramer on Application Monitoring with Sentry
Sentry is an application monitoring tool that surfaces errors and performance problems. It minimizes the need to manually look at logs or dashboards by identifying common problems across applications and frameworks.
David Cramer is the co-founder and CTO of Sentry.
This episode originally aired on Software Engineering Radio. Topics covered:
* What's Sentry?
* Treating performance problems as errors
* Why you might no need logs
* Identifying common problems in applications and frameworks
* Issues with Open Telemetry data
* Why front-end applications are difficult to instrument
* The evolution of Sentry's architecture
* Switching from a permissive license to the Business Source License Related Links
* Sentry
* David's Blog
* Sentry 9.1 and Upcoming Changes
* Re-Licensing Sentry Transcript
You can help edit this transcript on GitHub.
[00:00:00] Jeremy: Today I'm talking to David Kramer. He's the founder and CTO of Sentry. David, welcome to Software Engineering Radio.
[00:00:08] David: Thanks for having me. Excited for today's conversation. What's Sentry?
[00:00:11] Jeremy: I think the first thing we could start with is defining what Sentry is. I know some people refer to it as an error tracker. Some people have referred to it as, an application performance monitoring tool. I wonder if you could kind of describe in, in your words what it is.
[00:00:30] David: You know, as somebody who doesn't work in marketing, I just tell it how it is. So Sentry started out doing error monitoring, which. You know, dependent on who you talk to, you might just think of as logging, right? Like that's the honest truth. It is just logging just a different shape or form. these days it's hard to not classify us as just an APM tool that's like the industry that exists.
It's like the tools people understand. So I would just say it's an APM tool, right? We do a bunch of things within that space, and maybe it's not, you know, item for item the same as say a product like New Relic. but a lot of the overlap's there, so it's like errors performance, which is like latency and sort of throughput.
And then we have some stuff that just goes a little bit deeper within that. The, the one thing i would say that is different for us versus a lot of these tools is we actually only do application monitoring. So we don't do any since like systems or infrastructure monitoring. Meaning Sentry is not gonna tell you when you need to replace a hard drive or even that you need new hard, like more disk space or something like that because it's just, it's a domain that we don't think is relevant for sort of our customers and product. Application Performance Monitoring is about finding crashes and performance problems that users would associate with bugs
[00:01:31] Jeremy: For people who aren't familiar with the term application performance monitoring, what is that compared to just error tracking?
[00:01:41] David: The way I always reason about it, this is what I tell new hires and what I would tell, like my mother, if I had to explain what I do, is like, you load Uber and it crashes. We all know that's bad, right? That's error monitoring. We capture the crash report, we send it to developers. You load Uber and it's a 30 second spinner, like a loading indicator as a customer.
Same outcome for me. I assume the app is broken, right? So we also know that's bad. Um, but that's different than a crash. Okay. Sentry captures that same thing and send it to developers. lastly the third example we use, which is a little bit more. I think, untraditional, but a non-traditional rather, uh, you load the Uber app and it's like a blank screen or there's no button to submit, like log in or something like this.
So it's kind of like a, it's broken, but it maybe isn't erroring and it's not like a slow thing. Right. Same outcome. It's probably a bug of some sorts. Like it's what an end user would describe it as a bug. So for me, APM just translates to there are bugs, user perceived bugs in your application and we're able to monitor and, and help the software teams sort of prioritize and resolve those, those concerns.
[00:02:42] Jeremy: Earlier you were talking about actual crashes, and then your second case is, may be more of if the app is running slowly, then that's not necessarily a crash, but it's still something that an APM would monitor.
[00:02:57] David: Yeah. Yeah. And I, I think to be fair, APM, historically, it's not a very meaningful term. Like I as a, when I was more of just an individual contributor, I would associate APM to, like, there's a dashboard that will tell me what's slow in my application, which it does. And that is kind of core to APM, but it would also, none of the traditional tools, pre sentry would actually tell you why it's broken, like when there's an error, a crash.
It was like most of those tools were kind of useless. And I don't know, I do actually know, but I'm gonna pretend I don't know about most people and just say for myself. But most of the time my problems are errors. They are not like it's fast or slow, you know? and so we just think of it as like it's a holistic thing to say, when I've changed the application and something's broken, or it's a bug, you know, what is that bug?
How do we help people fix it? And that comes from a lot of different, like data signals and things like that. the end result is still the same. You either are gonna fix it or it's not important and you ignore it. I don't know. So it's a pretty straightforward, premise for us. But again, most companies in the space, like the traditional company is when you grow a big company, what happens is like you build one thing and then you build lots of check boxes to sell more things.
And so I think a lot of the APM vendors, like they've created a lot of different products. Like RUM is a good example of another acronym that lives with an APM. And I would tell you RUM is completely meaningless. It, it stands for real user monitoring. And so I'm like, well, what's not real about monitoring the application?
Well, nothing's not real, but like they created a new category because that's how marketing engines work. And that new category is more like analytics than it is like application telemetry. And it's only because they couldn't collect the app, the application telemetry at the time. And so there's just a lot of fluff, i would say.
But at the end of the day too, like developers or engineering teams, it's like new version of the application. You broke something, let's tell you about it so you can fix it. You might not need logging or performance monitoring
[00:04:40] Jeremy: And, and so earlier you were saying how this is a kind of logging, but there's also other companies, other products that are considered like logging infrastructure. Like I, I would think of companies like Paper Trail or Log Tail. So what space does Sentry fill that's that's different than that kind of logging?
[00:05:03] David: Um, so the way I always think about it, and this is both personally true, and what I advise other folks is when you're building something new, when you start from zero, right, you can often take Sentry put it in, and that's good enough. You don't even need performance monitoring. You just need like errors, right?
Like you're just causing bugs all the time. And you could do that with logging, but like the delta between air monitoring and logging is night and day. From a user experience, like error monitoring for us, or what we built at the very least, aggregates the errors. It, it helps you understand the frequency. It helps you when they're new versus old.
it really gives you a lot of detail where logs don't, and so you don't need logging often. And I will tell you today at Sentry. Engineers do not use logs for the most part. Uh, I had a debate with one of our, our team members about it, like, why does he use logs recently? But you should not need them because logs serve a different…
playlist_add
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 Ove…
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 inte…
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:0…
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…
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…
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 po…
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…
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