56 episodes

Practical conversations about software development.

Software Sessions Jeremy Jung

    • Education
    • 5.0 • 3 Ratings

Practical conversations about software development.

    Mayra Navarro on Getting to RubyConf (RubyConf 2023)

    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


    Ruby Perú
    Atlanta Ruby


    Cody Norman
    Stefanni Brasil of hexdevs
    Dave Kimura of Drifting Ruby




    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

    • 27 min
    Mike Perham on Keeping it solo (RubyConf 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's blog
    From Employment to Independence


    The Practical Effects of the GVL on Scaling in Ruby

    You can help correct transcripts on GitHub.

    [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.

    [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 jus

    • 51 min
    Sara Jackson on Teaching in Kanazawa (RubyConf 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
    The forgotten maintainer

    Other links

    Sara's mastodon
    This Week in Open Source
    Ruby Central Scholars and Guides Program
    City Museum


    International College of Technology Kanazawa
    Applying mruby to World-first Small SAR Satellite (Japanese lightning talk) (mruby in space)


    Rochester Institute of Technology
    Electronic Gaming Society
    Strong National Museum of Play

    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 thin

    • 44 min
    David Copeland on Medium Sized Decisions (RubyConf 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

    You can help correct transcripts on GitHub.

    [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 Rai

    • 48 min
    ChaelCodes on The Joy of Programming Games and Streaming (RubyConf 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.

    Personal website

    Programming Games mentioned:

    Regex Crossword
    7 Billion Humans
    One Dreamer
    Code Rom@ntic

    You can help edit this transcript on GitHub.

    I'm here at RubyConf San Diego with Rachel Wright-Munn, and she goes by Chaelcodes online. Thanks for joining me today.

    Hi, everyone. Hi, Jeremy. Really excited to be here.

    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.

    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?

    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...

    Opus Magnum? Shenzhen I/O?

    Yeah, Shenzhen I/O.

    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?

    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.

    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.

    OK. That's some good world building there.


    Because in your professional life, you do software development work.
    So I wonder, what is it about being in a game format where you'r

    • 43 min
    Daniel Zingaro and Leo Porter on learning to program with LLMs

    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

    You can help edit this transcript on GitHub.

    Note the timestamps and audio for this transcript will not completely match.

    [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

    • 1 hr

Customer Reviews

5.0 out of 5
3 Ratings

3 Ratings

Top Podcasts In Education

Mel Robbins
Dr. Jordan B. Peterson
Mark Manson
Mscs Media Podcast

You Might Also Like

Matt Swanson
Emmanuel Hayford
Ben Orenstein and Adam Wathan
Changelog Media