Podcasts about rubyists

On this episode, I'm joined by Adarsh Pandit, Executive Director of Ruby Central.  We discuss men's fashion, Adarsh's path to becoming a developer, the distinction between contracting and consulting, defining what you do as a consultant, keeping yourself top of mind to potential consulting clients, how Ruby Central is building community among Rubyists, the current state of Ruby meetups & conferences, and my conference, Sin City Ruby.Derek Guy on TwitterRubyConfRailsConfrubycentral.orgAdarsh Pandit on LinkedInadarsh@rubycentral.orgSin City Ruby

Over the last year, the Rails Foundation has been hard at work on several initiatives. After a successful Rails World last year, they've been working on the program for this year's Rails World in Toronto. The Rails Foundation has also been working on several other initiatives that are very important to our community. Amanda Perino, Executive Director of The Rails Foundation joins the show to talk about the Foundation's work on the Rails Guides, Rails Girls Brazil, Tropical.rb, tutorials, working with Rails Core, and Rails World Show Notes Rails Foundation Website - https://rubyonrails.org/foundation Rails Guides - https://edgeguides.rubyonrails.org/ Rails Girls - https://railsgirls.com/ Rails World - https://rubyonrails.org/world/2024 Ridhwana Khan - https://github.com/Ridhwana Bhumi Shah - https://github.com/bhumi1102 Petrik de Heus (Rails Issues team) - https://github.com/p8 Carlos Antonio da Silva (Rails Core) - https://github.com/carlosantoniodasilva Blog: https://rubyonrails.org/2024/2/6/documentation-update-work-has-begun John Athayde - https://meticulous.com/ Blog: https://rubyonrails.org/2024/3/20/rails-guides-get-a-facelift Rails Girls São Paulo - https://railsgirls.com.br/ Debora Fernandes - https://www.linkedin.com/in/debborafernandess/ Camila Campos - https://www.linkedin.com/in/camposmilaa/ Tropical.rb - https://www.tropicalrb.com/en/ Cirdes Henrique - https://www.linkedin.com/in/cirdesh/ Doximity - https://www.doximity.com/ Bruno Miranda - https://www.linkedin.com/in/brunomiranda/ Blog: https://rubyonrails.org/2024/2/27/rails-foundation-doximity-sponsor-rails-girls-sao-paolo Planet Argon - https://www.planetargon.com/ Robby Russell - https://www.linkedin.com/in/robbyrussell/ Campus Code - https://www.campuscode.com.br/ Joāo Almeida - https://www.linkedin.com/in/joaorsalmeida/ Sponsors Honeybadger (https://www.honeybadger.io/) As an Engineering Manager or an engineer, too much of your time gets sucked up with downtime issues, troubleshooting, and error tracking. How can you spend more time shipping code and less time putting out fires? Honeybadger is how. It's a suite of monitoring tools specifically for devs. Get started today in as little as 5 minutes at Honeybadger.io (https://www.honeybadger.io/) with plans starting at free! Blue Ridge Ruby (https://blueridgeruby.com/) Are you ready to break away from your routine and immerse yourself in the vibrant world of Ruby? Join us at Blue Ridge Ruby, a friendly regional conference nestled in the picturesque mountains of western North Carolina, happening on May 30th and 31st, 2024, in the heart of downtown Asheville. Blue Ridge Ruby isn't just another tech conference; It's a gathering of passionate Ruby developers and community members. Join us at a cozy venue for a single track conference with an intimate atmosphere and connect with Rubyists of all levels to share ideas. Explore downtown Asheville during the open lunch break, sampling its eclectic food scene and cozy cafes and during the post conference weekend to see our vibrant city. Visit BlueRidgeRuby.com for registration and speaker information and secure your spot today!

I am very excited for today's episode! Twitch is a livestreaming service where users can stream themselves to the internet. Twitch is known for video game streaming. But, people stream all kinds of things, including software development. Today's guest is Rachael Wright-Munn who livestreams Rails development on Twitch Show Notes Rachael's Twitch: https://www.twitch.tv/chaelcodes Find Rachael online: https://chael.codes/links Nerd or die: https://nerdordie.com/ Sponsors Honeybadger (https://www.honeybadger.io/) As an Engineering Manager or an engineer, too much of your time gets sucked up with downtime issues, troubleshooting, and error tracking. How can you spend more time shipping code and less time putting out fires? Honeybadger is how. It's a suite of monitoring tools specifically for devs. Get started today in as little as 5 minutes at Honeybadger.io (https://www.honeybadger.io/) with plans starting at free! Blue Ridge Ruby (https://blueridgeruby.com/) Are you ready to break away from your routine and immerse yourself in the vibrant world of Ruby? Join us at Blue Ridge Ruby, a friendly regional conference nestled in the picturesque mountains of western North Carolina, happening on May 30th and 31st, 2024, in the heart of downtown Asheville. Blue Ridge Ruby isn't just another tech conference; It's a gathering of passionate Ruby developers and community members. Join us at a cozy venue for a single track conference with an intimate atmosphere and connect with Rubyists of all levels to share ideas. Explore downtown Asheville during the open lunch break, sampling its eclectic food scene and cozy cafes and during the post conference weekend to see our vibrant city. Visit BlueRidgeRuby.com for registration and speaker information and secure your spot today!

There are so many Ruby events happening recently, that it can be hard to know which one to go to. Today we're going to talk about a rather unique event in the Ruby community. What if you could go to an event that was just the Hallway Track? And that event happened at a summer camp? Show Notes Rails Camp West Website - https://west.railscamp.us Big Nerd Ranch - https://bignerdranch.com/ Sponsors Honeybadger (https://www.honeybadger.io/) As an Engineering Manager or an engineer, too much of your time gets sucked up with downtime issues, troubleshooting, and error tracking. How can you spend more time shipping code and less time putting out fires? Honeybadger is how. It's a suite of monitoring tools specifically for devs. Get started today in as little as 5 minutes at Honeybadger.io (https://www.honeybadger.io/) with plans starting at free! Blue Ridge Ruby (https://blueridgeruby.com/) Are you ready to break away from your routine and immerse yourself in the vibrant world of Ruby? Join us at Blue Ridge Ruby, a friendly regional conference nestled in the picturesque mountains of western North Carolina, happening on May 30th and 31st, 2024, in the heart of downtown Asheville. Blue Ridge Ruby isn't just another tech conference; It's a gathering of passionate Ruby developers and community members. Join us at a cozy venue for a single track conference with an intimate atmosphere and connect with Rubyists of all levels to share ideas. Visit BlueRidgeRuby.com for registration and speaker information and secure your spot today!

Joël talks about his difficulties optimizing queries in ActiveRecord, especially with complex scopes and unions, resulting in slow queries. He emphasizes the importance of optimizing subqueries in unions to boost performance despite challenges such as query duplication and difficulty reusing scopes. Stephanie discusses upgrading a client's app to Rails 7, highlighting the importance of patience, detailed attention, and the benefits of collaborative work with a fellow developer. The conversation shifts to Ruby's reduce method (inject), exploring its complexity and various mental models to understand it. They discuss when it's preferable to use reduce over other methods like each, map, or loops and the importance of understanding the underlying operation you wish to apply to two elements before scaling up with reduce. The episode also touches on monoids and how they relate to reduce, suggesting that a deep understanding of functional programming concepts can help simplify reduce expressions. Rails 7 EXPLAIN ANALYZE (https://www.bigbinary.com/blog/rails-7-1-adds-options-to-activerecord-relation-explain) Blocks, symbol to proc, and symbols arguments for reduce (https://thoughtbot.com/blog/blocks-procs-and-enumerable) Ruby tally (https://medium.com/@baweaver/ruby-2-7-enumerable-tally-a706a5fb11ea) Performance considerations for reduce in JavaScript (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/Reduce#when_to_not_use_reduce) Persistant data structures (https://www.youtube.com/watch?v=gTClDj9Zl1g) Avoid passing a block to map and reduce (https://thoughtbot.com/blog/avoid-putting-logic-in-map-blocks) Functional Programming with Bananas, Lenses, Envelopes and Barbed Wire (https://ris.utwente.nl/ws/portalfiles/portal/6142049/meijer91functional.pdf) monoids (https://blog.ploeh.dk/2017/10/06/monoids/) iteration anti-patterns (https://thoughtbot.com/blog/iteration-as-an-anti-pattern) Joël's talk on “constructor replacement” (https://www.youtube.com/watch?v=dSMB3rsufC8) Transcript:  STEPHANIE: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Stephanie Minn. JOËL: And I'm Joël Quenneville. And together, we're here to share a bit of what we've learned along the way. STEPHANIE: So, Joël, what's new in your world? JOËL: I've been doing a bunch of fiddling with query optimization this week, and I've sort of run across an interesting...but maybe it's more of an interesting realization because it's interesting in the sort of annoying way. And that is that, using ActiveRecord scopes with certain more complex query pieces, particularly unions, can lead to queries that are really slow, and you have to rewrite them differently in a way that's not reusable in order to make them fast. In particular, if you have sort of two other scopes that involve joins and then you combine them using a union, you're unioning two sort of joins. Later on, you want to change some other scope that does some wares or something like that. That can end up being really expensive, particularly if some of the underlying tables being joined are huge. Because your database, in my case, Postgres, will pull a lot of this data into the giant sort of in-memory table as it's, like, building all these things together and to filter them out. And it doesn't have the ability to optimize the way it would on a more traditional relation. A solution to this is to make sure that the sort of subqueries that are getting unioned are optimized individually. And that can mean moving conditions that are outside the union inside. So, if I'm chaining, I don't know, where active is true on the outer query; on the union itself, I might need to move that inside each of the subqueries. So, now, in the two or three subqueries that I'm unioning, each of them needs to have a 'where active true' chained on it. STEPHANIE: Interesting. I have heard this about using ActiveRecord scopes before, that if the scopes are quite complex, chaining them might not lead to the most performant query. That is interesting. By optimizing the subqueries, did you kind of change the meaning of them? Was that something that ended up happening? JOËL: So, the annoying thing is that I have a scope that has the union in it, and it does some things sort of on its own. And it's used in some places. There are also other places that will try to take that scope that has the union on it, chain some other scopes that do other joins and some more filters, and that is horribly inefficient. So, I need to sort of rewrite the sort of subqueries that get union to include all these new conditions that only happen in this one use case and not in the, like, three or four others that rely on that union. So, now I end up with some, like, awkward query duplication in different call sites that I'm not super comfortable about, but, unfortunately, I've not found a good way to make this sort of nicely reusable. Because when you want to chain sort of more things onto the union, you need to shove them in, and there's no clean way of doing that. STEPHANIE: Yeah. I think another way I've seen this resolved is just writing it in SQL if it's really complex and it becoming just a bespoke query. We're no longer trying to use the scope that could be reusable. JOËL: Right. Right. In this case, I guess, I'm, like, halfway in between in that I'm using the ActiveRecord DSL, but I am not reusing scopes and things. So, I sort of have the, I don't know, naive union implementation that can be fine in all of the simpler use cases that are using it. And then the query that tries to combine the union with some other fancy stuff it just gets its own separate implementation different than the others that it has optimized. So, there are sort of two separate paths, two separate implementations. I did not drop down to writing raw SQL because I could use the ActiveRecord DSL. So, that's what I've been working with. What's new in your world this week? STEPHANIE: So, a couple of weeks ago, I think, I mentioned that I was working on a Rails 7 upgrade, and we have gotten it out the door. So, now the client application I'm working on is on Rails 7, which is exciting for the team. But in an effort to make the upgrade as incremental as possible, we did, like, back out of a few of the new application config changes that would have led us down a path of more work. And now we're kind of following up a little bit to try to turn some of those configs on to enable them. And it was very exciting to kind of, like, officially be on Rails 7. But I do feel like we tried to go for, like, the minimal amount of work possible in that initial big change. And now we're having to kind of backfill a little bit on some of the work that was a little bit more like, oh, I'm not really sure, like, how big this will end up being. And it's been really interesting work, I think, because it requires, like, two different mindsets. Like, one of them is being really patient and focused on tedious work. Like, okay, what happens when we enable this config option? Like, what changes? What errors do we see? And then having to turn it back off and then go in and fix them. But then another, I think, like, headspace that we have to be in is making decisions about what to do when we come to a crossroads around, like, okay, now that we are starting to see all the changes that are coming about from enabling this config, is this even what we want to do? And it can be really hard to switch between those two modes of thinking. JOËL: Yeah. How do you try to balance between the two? STEPHANIE: So, I luckily have been pairing with another dev, and I've actually found that to be really effective because he has, I guess, just, like, a little bit more of that patience to do the more tedious, mundane [laughs] aspects of, like, driving the code changes. And I have been riding along. But then I can sense, like, once he gets to the point of like, "Oh, I'm not sure if we should keep going down this road," I can step in a little bit more and be like, "Okay, like, you know, I've seen us do this, like, five times now, and maybe we don't want to do that." Or maybe being like, "Okay, we don't have a really clear answer, but, like, who can we talk to to find out a little bit more or get their input?" And that's been working really well for me because I've not had a lot of energy to do more of that, like, more manual or tedious labor [chuckles] that comes with working on that low level of stuff. So yeah, I've just been pleasantly surprised by how well we are aligning our superpowers. JOËL: To use some classic business speech, how does it feel to be in the future on Rails 7? STEPHANIE: Well, we're not quite up, you know, up to modern days yet, but it does feel like we're getting close. And, like, I think now we're starting to entertain the idea of, like, hmm, like, could we be even on main? I don't think it's really going to happen, but it feels a little bit more possible. And, in general, like, the team thinks that that could be, like, really exciting. Or it's easier, I think, once you're a little bit more on top of it. Like, the worst is when you get quite behind, and you end up just feeling like you're constantly playing catch up. It just feels a little bit more manageable now, which is good. JOËL: I learned this week a fun fact about Rails 7.1, in particular, which is that the analyze method on ActiveRecord queries, which allowed you to sort of get SQL EXPLAIN statements, now has the ability to pass in a couple of extra parameters. So, there are symbols, and you can pass in things like analyze or verbose, which allows you to get sort of more data out of your EXPLAIN query, which can be quite nice when you're debugging for performance. So, if you're in the future and you're on Rails 7.1 and you want sort of the in-depth query plans, you don't need to copy the SQL into a Postgres console to get access to the sort of fully developed EXPLAIN plan. You can now do it by passing arguments to EXPLAIN, which I'm very happy for. STEPHANIE: That's really nice. JOËL: So, we've mentioned before that we have a developers' channel on Slack here at thoughtbot, and there's all sorts of fun conversations that happen there. And there was one recently that really got me interested, where people were talking about Ruby's reduce method, also known as inject. And it's one of those methods that's kind of complicated, or it can be really confusing. And there was a whole thread where people were talking about different mental models that they had around the reduce method and how they sort of understand the way it works. And I'd be curious to sort of dig into each other's mental models of that today. To kick us off, like, how comfortable do you feel with Ruby's reduce method? And do you have any mental models to kind of hold it in your head? STEPHANIE: Yeah, I think reduce is so hard to wrap your head around, or it might be one of the most difficult, I guess, like, functions a new developer encounters, you know, in trying to understand the tools available to them. I always have to look up the order of the arguments [laughs] for reduce. JOËL: Every time. STEPHANIE: Yep. But I feel like I finally have a more intuitive sense of when to use it. And my mental model for it is collapsing a collection into one value, and, actually, that's why I prefer calling it reduce rather than the inject alias because reduce kind of signals to me this idea of going from many things to one canonical thing, I suppose. JOËL: Yeah, that's a very common use case for reducing, and I guess the name itself, reducing, kind of has almost that connotation. You're taking many things, and you're going to reduce that down to a single thing. STEPHANIE: What was really interesting to me about that conversation was that some people kind of had the opposite mental model where it made a bit more sense for them to think about injecting and, specifically, like, the idea of the accumulator being injected with values, I suppose. And I kind of realized that, in some ways, they're kind of antonyms [chuckles] a little bit because if you're focused on the accumulator, you're kind of thinking about something getting bigger. And that kind of blew my mind a little bit when I realized that, in some ways, they can be considered opposites. JOËL: That's really fascinating. It is really interesting, I think, the way that we can take the name of a method and then almost, like, tell ourselves a story about what it does that then becomes our way of remembering how this method works. And the story we tell for the same method name, or in this case, maybe there's a few different method names that are aliases, can be different from person to person. I know I tend to think of inject less in terms of injecting things into the accumulator and more in terms of injecting some kind of operator between every item in the collection. So, if we have an array of numbers and we're injecting plus, in my mind, I'm like, oh yeah, in between each of the numbers in the collection, just inject a little plus sign, and then do the math. We're summing all the items in the collection. STEPHANIE: Does that still hold up when the operator becomes a little more complex than just, you know, like, a mathematical operator, like, say, a function? JOËL: Well, when you start passing a block and doing custom logic, no, that mental model kind of falls apart. In order for it to work, it also has to be something that you can visualize as some form of infix operator, something that goes between two values rather than, like, a method name, which is typically in prefix position. I do want to get at this idea, though: the difference between sort of the block version versus passing. There are ways where you can just do a symbol, and that will call a method on each of the items. Because I have a bit of a hot take when it comes to writing reduce blocks or inject blocks that are more accessible, easier to understand. And that is, generally, that you shouldn't, or more specifically, you should not have a big block body. In general, you should be either using the symbol version or just calling a method within the block, and it's a one-liner. Which means that if you have some complex behavior, you need to find a way to move that out of this sort of collection operation and into instance methods on the objects being iterated. STEPHANIE: Hmm, interesting. By one-liner do you mean passing the name of the method as a proc or actually, like, having your block that then calls the method? Because I can see it becoming even simpler if you have already extracted a method. JOËL: Yeah, if you can do symbol to proc, that's amazing, or even if you can use just the straight-up symbol way of invoking reduce or inject. That typically means you have to start thinking about the types of objects that you are working with and what methods can be moved onto them. And sometimes, if you're working with hashes or something like that that don't have domain methods for what you want, that gets really awkward. And so, then maybe that becomes maybe a hint that you've got some primitive obsession happening and that this hash that sort of wants a domain object or some kind of domain method probably should be extracted to its own object. STEPHANIE: I'll do you with another kind of spicy take. I think, in that case, maybe you don't want a reduce at all. If you're starting to find that...well, okay, I think it maybe could depend because there could be some very, like, domain-specific logic. But I have seen reduce end up being used to transform the structure of the initial collection when either a different higher-order function can be used or, I don't know, maybe you're just better off writing it with a regular loop [laughs]. It could be clearer that way. JOËL: Well, that's really interesting because...so, you mentioned the idea that we could use a different higher-order function, and, you know, higher-order function is that fancy term, just a method that accepts another method as an argument. In Ruby, that just means your method accepts a block. Reduce can be used to implement pretty much the entirety of enumerable. Under the hood, enumerable is built in terms of each. You could implement it in terms of reduce. So, sometimes it's easy to re-implement one of the enumerable methods yourself, accidentally, using reduce. So, you've written this, like, complex reduce block, and then somebody in review comes and looks at it and is like, "Hey, you realize that's just map. You've just recreated map. What if we used map here?" STEPHANIE: Yeah. Another one I've seen a lot in JavaScript land where there are, you know, fewer utility functions is what we now have in Ruby, tally. I feel like that was a common one I would see a lot when you're trying to count instances of something, and I've seen it done with reduce. I've seen it done with a for each. And, you know, I'm sure there are libraries that actually provide a tally-like function for you in JS. But I guess that actually makes me feel even more strongly about this idea that reduce is best used for collapsing something as opposed to just, like, transforming a data structure into something else. JOËL: There's an interesting other mental model for reduce that I think is hiding under what we're talking about here, and that is the idea that it is a sort of mid-level abstraction for dealing with collections, as opposed to something like map or select or some of those other enumerable helpers because those can all be implemented in terms of reduce. And so, in many cases, you don't need to write the reduce because the library maintainer has already used reduce or something equivalent to build these higher-level helpers for you. STEPHANIE: Yeah, it's kind of in that weird point between, like, very powerful [chuckles] so that people can start to do some funky things with it, but also sometimes just necessary because it can feel a little bit more concise that way. JOËL: I've done a fair amount of functional programming in languages like Elm. And there, if you're building a custom data structure, the sort of lowest-level way you have of looping is doing a recursion, and recursions are messy. And so, what you can do instead as a library developer is say, "You know what, I don't want to be writing recursions for all of these." I don't know; maybe I'm building a tree library. I don't want to write a recursion for every different function that goes over trees if I want to map or filter or whatever. I'm going to write reduce using recursion, and then everything else can be written in terms of reduce. And then, if people want to do custom things, they don't need to recurse over my tree. They can use this reduce function, which allows them to do most of the traversals they want on the tree without needing to touch manual recursion. So, there's almost, like, a low-level, mid-level, high-level in the library design, where, like, lowest level is recursion. Ideally, nobody touches that. Mid-level, you've got reducing that's built out on top of recursion. And then, on top of that, you've got all sorts of other helpers, like mapping, like filtering, things like that. STEPHANIE: Hmm. I'm wondering, do you know of any performance considerations when it comes to using reduce built off a recursion? JOËL: So, one of the things that can be really nice is that writing a recursion yourself is dangerous. It's so easy to, like, accidentally introduce Stack Overflow. You could also write a really inefficient one. So, ideally, what you do is that you write a reduce that is safe and that is fast. And then, everybody else can just use that to not have to worry about the sort of mechanics of traversing the collection. And then, just use this. It already has all of the safety and speed features built in. You do have to be careful, though, because reduce, by nature, traverses the entire collection. And if you want to break out early of something expensive, then reduce might not be the tool for you. STEPHANIE: I was also reading a little bit about how, in JavaScript, a lot of developers like to stick to that idea of a pure function and try to basically copy the entire accumulator for every iteration and creating a new object for that. And that has led to some memory issues as well. As opposed to just mutating the accumulator, having, especially when you, you know, are going through a collection, like, really large, making that copy every single time and creating, yeah [chuckles], just a lot of issues that way. So, that's kind of what prompted that question. JOËL: Yeah, that can vary a lot by language and by data structure. In more functional languages that try to not mutate, they often have this idea of what they call persistent data structures, where you can sort of create copies that have small modifications that don't force you to copy the whole object under the hood. They're just, like, pointers. So, like, hey, we, like, are the same as this other object, but with this extra element added, or something like that. So, if you're growing an array or something like that, you don't end up with 10,000 copies of the array with, like, a new element every time. STEPHANIE: Yeah, that is interesting. And I feel like trying to adopt different paradigms for different tools, you know, is not always as straightforward as some wish it were [laughs]. JOËL: I do want to give a shout-out to an academic paper that is...it is infamously dense. The title of it is Functional Programming with Bananas, Lenses, and Barbed Wire. STEPHANIE: It doesn't sound dense; it sounds fun. Well, I don't about barbed wire. JOËL: It sounds fun, right? STEPHANIE: Yeah, but certainly quirky [laughs]. JOËL: It is incredibly dense. And they've, like, created this custom math notation and all this stuff. But the idea that they pioneered there is really cool, this idea that kind of like I was talking about sort of building libraries in different levels. Their idea is that recursion is generally something that's unsafe and that library and language designers should take care of all of the recursion and instead provide some of these sort of mid-level helper methods to do things. Reducing is one of them, but their proposal is that it's not the only one. There's a whole sort of family of similar methods that are there that would be useful in different use cases. So, reduce allows you to sort of traverse the whole thing. It does not allow you to break out early. It does not allow you to keep sort of track of a sort of extra context element if you want to, like, be traversing a collection but have a sort of look forward, look back, something like that. So, there are other variations that could handle those. There are variations that are the opposite of reduce, where you're, like, inflating, starting from a few parameters and building a collection out of them. So, this whole concept is called recursion schemes, and you can get, like, really deep into some theory there. You'll hear fancy words like catamorphisms and anamorphisms. There's a whole world to explore in that area. But at its core, it's this idea that you can sort of slice up things into this sort of low-level recursion, mid-level helpers, and then, like, kind of userland helpers built on top of that. STEPHANIE: Wow. That is very intense; it sounds like [chuckles]. I'm happy not to ever have to write a recursion ever again, probably [laughs]. Have you ever, as just a web developer in your day-to-day programming, found a really good use case for dropping down to that level? Or are you kind of convinced that, like, you won't really ever need to? JOËL: I think it depends on the paradigm of the language you're working in. In Ruby, I've very rarely needed to write a recursion. In something like Elm, I've had to do that, eh, not infrequently. Again, it depends, like, if I'm doing more library-esque code versus more application code. If I'm writing application code and I'm using an existing, let's say, tree library, then I typically don't need to write a recursion because they've already written traversals for me. If I'm making my own and I have made my own tree libraries, then yes, I'm writing recursions myself and building those traversals so that other people don't have to. STEPHANIE: Yeah, that makes sense. I'd much rather someone who has read that paper [laughs] write some traversal methods for me. JOËL: And, you know, for those who are curious about it, we will put a link to this paper in the description. So, we've talked about a sort of very academic mental model way of thinking about reducing. I want to shift gears and talk about one that I have found is incredibly practical, and that is the idea that reduce is a way to scale an operation that works on two objects to an operation that works on sort of an unlimited number of objects. To make it more concrete, take something like addition. I can add two numbers. The plus operator allows me to take one number, add another, get a sum. But what if I want to not just add two numbers? I want to add an arbitrary number of numbers together. Reduce allows me to take that plus operator and then just scale it up to as many numbers as I want. I can just plug that into, you know, I have an array of numbers, and I just call dot reduce plus operator, and, boom, it can now scale to as many numbers as I want, and I can sum the whole thing. STEPHANIE: That dovetails quite nicely with your take earlier about how you shouldn't pass a block to reduce. You should extract that into a method. Don't you think? JOËL: I think it does, yes. And then maybe it's, like, sort of two sides of a coin because I think what this leads to is an approach that I really like for reducing because sometimes, you know, here, I'm starting with addition. I'm like, oh, I have addition. Now, I want to scale it up. How do I do that? I can use reduce. Oftentimes, I'm faced with sort of the opposite problem. I'm like, oh, I need to add all these numbers together. How do I do that? I'm like, probably with a reduce. But then I start writing the block, and, like, I get way too into my head about the accumulator and what's going to happen. So, my strategy for writing reduce expressions is to, instead of trying to figure out how to, like, do the whole thing together, first ask myself, how do I want to combine any two elements that are in the array? So, I've got an array of numbers, and I want to sum them all. What is the thing I need to do to combine just two of those? Forget the array. Figure that out. And then, once I have that figured out, maybe it's an existing method like plus. Maybe it's a method I need to define on it if it's a custom object. Maybe it's a method that I write somewhere. Then, once I have that, I can say, okay, I can do it for two items. Now, I'm going to scale it up to work for the whole array, and I can plug it into reduce. And, at that point, the work is already basically done, so I don't end up with a really complex block. I don't end up, like, almost ending in, like, a recursive infinite loop in my head because I do that. STEPHANIE: [laughs]. JOËL: So, that approach of saying, start by figuring out what is the operation you want to do to combine two elements, and then use reduce as a way to scale that to your whole array is a way that I've used to keep things simple in my mind. STEPHANIE: Yeah, I like that a lot as a supplement to the model I shared earlier because, for me, when I think about reducing as, like, collapsing into a value, you kind of are just like, well, okay, I start with the collection, and then somehow I get to my single value. But the challenge is figuring out how that happens [laughs], like, the magic that happens in between that. And I think another alias that we haven't mentioned yet for reduce that is used in a lot of other languages is fold. And I actually like that one a lot, and I think it relates to your mental model. Because when I think about folding, I'm picturing folding up a paper like an accordion. And you have to figure out, like, what is the first fold that I can make? And just repeating that over and over to get to your little stack of accordion paper [laughs]. And if you can figure out just that first step, then you pretty much, like, have the recipe for getting from your initial input to, like, your desired output. JOËL: Yeah. I think fold is interesting in that some languages will make a distinction between fold and reduce. They will have both. And typically, fold will require you to pass an initial value, like a starting accumulator, to start it off. Whereas reduce will sort of assume that your array can use the first element of the array as the first accumulator. STEPHANIE: Oh, I just came up with another visual metaphor for this, which is, like, folding butter into croissant pastry when the butter is your initial value [laughs]. JOËL: And then the crust is, I guess, the elements in the array. STEPHANIE: Yeah. Yeah. And then you get a croissant out of it [laughs]. Don't ask me how it gets to a perfectly baked, flaky, beautiful croissant, but somehow that happens [laughs]. JOËL: So, there's an interesting sort of subtlety here that I think happens because there are sort of two slightly different ways that you can interact with a reduce. Sometimes, your accumulator is of the same type as the elements in your array. So, you're summing an array of numbers, and your accumulator is the sum, but each of the elements in the array are also numbers. So, it's numbers all the way through. And sometimes, your accumulator has a different type than the items in the array. So, maybe you have an array of words, and you want to get the sum of all of the characters and all the words. And so, now your accumulator is a number, but each of the items in the array are strings. STEPHANIE: Yeah, that's an interesting distinction because I think that's where you start to see the complex blocks being passed and reduced. JOËL: The complex blocks, definitely; I think they tend to show up when your accumulator has a different type than the individual items. So, maybe that's, like, a slightly more complicated use case. Oftentimes, too, the accumulator ends up being some, like, more complex, like, hash or something that maybe would really benefit from being a custom object. STEPHANIE: I've never done that before, but I can see why that would be really useful. Do you have an example of when you used a custom object as the accumulator? JOËL: So, I've done it for situations where I'm working with objects that are doing tally-like operations, but I'm not doing just a generic tally. There's some domain-specific stuff happening. So, it's some sort of aggregate counter on multiple dimensions that you can use, and that can get really ugly. And you can either do it with a reduce or you can have some sort of, like, initial version of the hash outside and do an each and mutate the hash and stuff like that. All of these tend to be a little bit ugly. So, in those situations, I've often created some sort of custom object that has some instance methods that allow to sort of easily add new elements to it. STEPHANIE: That's really interesting because now I'm starting to think, what if the elements in the collection were also a custom object? [chuckles] And then things could, I feel like, could be really powerful [laughs]. JOËL: There's often a lot of value, right? Because if the items in the collection are also a custom object, you can then have methods on them. And then, again, the sort of complexity of the reduce can sort of, like, fade away because it doesn't own any of the logic. All it does is saying, hey, there's a thing you can do to combine two items. Let's scale it up to work on a collection of items. And now you've sort of, like, really simplified what logic is actually owned inside the reduce. I do want to shout out for those listeners who are theory nerds and want to dig into this. When you have a reduce, and you've got an operation where all the values are of the same type, including the accumulator, typically, what you've got here is some form of monoid. It may be a semigroup. So, if you want to dig into some theory, those are the words to Google and to go a deep dive on. The main thing about monoids, in particular, is that monoids are any objects that have both a sort of a base case, a sort of empty version of themselves, and they have some sort of combining method that allows you to combine two values of that type. If your object has these things and follows...there's a few rules that have to be true. You have a monoid. And they can then be sort of guaranteed to be folded nicely because you can plug in their base case as your initial accumulator. And you can plug in their combining method as just the value of the block, and everything else just falls into place. A classic here is addition for numbers. So, if you want to add two numbers, your combining operator is a plus. And your sort of empty value is a zero. So, you would say, reduce initial value is zero, array of numbers. And your block is just plus, and it won't sum all of the numbers. You could do something similar with strings, where you can combine strings together with plus, and, you know, your empty string is your base case. So, now you're doing sort of string concatenation over arbitrary number of strings. Turns out there's a lot of operations that fall into that, and you can even define some of those on your custom object. So, you're like, oh, I've got a custom object. Maybe I want some way of, like, combining two of them together. You might be heading in the direction of doing something that is monoidal, and if so, that's a really good hint to know that it can sort of, like, just drop into place with a fold or a reduce and that that is a tool that you have available to you. STEPHANIE: Yeah, well, I think my eyes, like, widened a little bit when you first dropped the term monoid [laughs]. I do want to spend the last bit of our time talking about when not to use reduce, and, you know, we did talk a lot about recursion. But when do you think a regular old loop will just be enough? JOËL: So, you're suggesting when would you want to use something like an each rather than a reduce? STEPHANIE: Yeah. In my mind, you know, you did offer, like, a lot of ways to make reduce simpler, a lot of strategies to end up with some really nice-looking syntax [chuckles], I think. But, oftentimes, I think it can be equally as clear storing your accumulator outside of the iteration and that, like, is enough for me to understand. And reduce takes a little bit of extra overhead to figure out what I'm looking at. Do you have any thoughts about when you would prefer to do that? Or do you think that you would usually reach for something else? JOËL: Personally, I generally don't like the pattern of using each to iterate over a collection and then mutate some external accumulator. That, to me, is a bit of a code smell. It's a sign that each is not quite powerful enough to do the thing that I want to do and that I'm probably needing some sort of more specialized form of iteration. Sometimes, that's reduce. Oftentimes, because each can suffer from the same problem you mentioned from reduce, where it's like, oh, you're doing this thing where you mutate an external accumulator. Turns out what you're really doing is just map. So, use map or use select or, you know, some of the other built-in iterators from the enumerable library. There's a blog post on the thoughtbot blog that I continually link to people. And when I see the pattern of, like, mutating an external variable with each, yeah, I tend to see that as a bit of a code smell. I don't know that I would never do it, but whenever I see that, it's a sign to me to, like, pause and be like, wait a minute, is there a better way to do this? STEPHANIE: Yeah, that's fair. I like the idea that, like, if there's already a method available to you that is more specific to go with that. But I also think that sometimes I'd rather, like, come across that pattern of mutating a variable outside of the iteration over, like, someone trying to do something clever with the reduce. JOËL: Yeah, I guess reduce, especially if it's got, like, a giant block and you've got then, like, things in there that break or call next to skip iterations and things like that, that gets really mind-bending really quickly. I think a case where I might consider using an each over a reduce, and that's maybe generally when I tend to use each, is when I'm doing side effects. If I'm using a reduce, it's because I care about the accumulated value at the end. If I'm using each, it's typically because I am trying to do some amount of side effects. STEPHANIE: Yeah, that's a really good call out. I had that written down in my notes, and I'm glad you brought it up because I've seen them get conflated a little bit, and perhaps maybe that's the source of the pain that I'm talking about. But I really like that heuristic of reduce as, you know, you're caring about the output, as opposed to what's going on inside. Like, you don't want any unexpected behavior. JOËL: And I think that applies to something like map as well. My sort of heuristic is, if I'm doing side effects, I want each. If I want transformed values that are sort of one-to-one in the collection, I want map. If I want a single sort of aggregate value, then I want reduce. STEPHANIE: I think that's the cool thing about mixing paradigms sometimes, where all the strategies you talked about in terms of, you know, using custom, like, objects for your accumulator, or the elements in your collection, like, that's something that we get because, you know, we're using an object-oriented language like Ruby. But then, like, you also are kind of bringing the functional programming lens to, like, when you would use reduce in the first place. And yeah, I am just really excited now [chuckles] to start looking for some places I can use reduce after this conversation and see what comes out of it. JOËL: I think I went on a bit of an interesting journey where, as a newer programmer, reduce was just, like, really intense. And I struggled to understand it. And I was like, ban it from code. I don't want to ever see it. And then, I got into functional programming. I was like, I'm going to do reduce everywhere. And, honestly, it was kind of messy. And then I, like, went really deep on a lot of functional theory, and I think understood some things that then I was able to take back to my code and actually write reduce expressions that are much simpler so that now my heuristic is like, I love reduce; I want to use it, but I want as little as possible in the reduce itself. And because I understand some of these other concepts, I have the ability to know what things can be extracted in a way that will feel very natural, in a way that myself from five years ago would have just been like, oh, I don't know. I've got this, you know, 30-line reduce expression that I know is complicated, but I don't know how to improve. And so, a little bit of the underlying theory, I don't think it's necessary to understand these simplified reduces, but as an author who's writing them, I think it helps me write reduces that are simpler. So, that's been my journey using reduce. STEPHANIE: Yeah. Well, thanks for sharing. And I'm really excited. I hope our listeners have learned some new things about reduce and can look at it from a different light. JOËL: There are so many different perspectives. And I think we keep discovering new mental models as we talk to different people. It's like, oh, this particular perspective. And there's one that we didn't really dig into but that I think makes more sense in a functional world that's around sort of deconstructing a structure and then rebuilding it with different components. The shorthand name of this mental model, which is a fairly common one, is constructor replacement. For anyone who's interested in digging into that, we'll link it in the show notes. I gave a talk at an Elm meetup where I sort of dug into some of that theory, which is really interesting and kind of mind-blowing. Not as relevant, I think, for Rubyists, but if you're in a language that particularly allows you to build custom structures out of recursive types or what are sometimes called algebraic data types, or tagged unions, or discriminated unions, this thing goes by a bajillion names, that is a really interesting other mental model to look at. And, again, I don't think the list that we've covered today is exhaustive. You know, I would love it for any of our listeners; if you have your own mental models for how to think about folding, injecting, reducing, send them in: hosts@bikeshed.fm. We'd love to hear them. STEPHANIE: And on that note, shall we wrap up? JOËL: Let's wrap up. STEPHANIE: Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeee!!!!!!! AD: Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Stephanie shares her task of retiring a small, internally-used link-shortening app. She describes the process as both celebratory and a bit mournful. Meanwhile, Joël discusses his deep dive into ActiveRecord, particularly in the context of debugging. He explores the complexities of ActiveRecord querying schemas and the additional latency this introduces. Together, the hosts discuss the nuances of package management systems and their implications for developers. They touch upon the differences between system packages and language packages, sharing personal experiences with tools like Homebrew, RubyGems, and Docker. Transcript: JOËL: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Joël Quenneville. STEPHANIE: And I'm Stephanie Minn. And together, we're here to share a bit of what we've learned along the way. JOËL: So, Stephanie, what's new in your world? STEPHANIE: So, this week, I got to have some fun working on some internal thoughtbot work. And what I focused on was retiring one of our just, like, small internal self-hosted on Heroku apps in favor of going with a third-party service for this functionality. We basically had a tiny, little app that we used as a link-shortening service. So, if you've ever seen a tbot.io short link out in the world, we were using our just, like, an in-house app to do that, you know, but for various reasons, we wanted to...just it wasn't worth maintaining anymore. So, we wanted to just use a purchased service. But today, I got to just, like, do the little bit of, like, tidying up, you know, in preparation to archive a repo and kind of delete the app from Heroku, and I hadn't done that before. So, it felt a little bit celebratory and a little bit mournful even [laughs] to, you know, retire something like that. And I was pairing with another thoughtbot developer, and we used a pairing app called Tuple. And you can just send, like, fun reactions to each other. Like, you could send, like, a fire emoji [laughs] or something if that's what you're feeling. And so, I sent some, like, confetti when we clicked the, "I understand what deleting this app means on GitHub." But I joked that "Actually, I feel like what I really needed was a, like, a salute kind of like thank you for your service [laughs] type of reaction." JOËL: I love those moments when you're kind of you're hitting those kind of milestone-y moments, and then you get to send a reaction. I should do that more often in Tuple. Those are fun. STEPHANIE: They are fun. There's also a, like, table flip reaction, too, is one that I really enjoy [laughs], you know, you just have to manifest that energy somehow. And then, after we kind of sent out an email to the company saying like, "Oh yeah, we're not using our app anymore for link shortening," someone had a great suggestion to make our archived repo public instead of private. I kind of liked it as a way of, like, memorializing this application and let community members see, you know, real code in a real...the application that we used here at thoughtbot. So, hopefully, if not me, then someone else will be able to do that and maybe publish a little blog post about that. JOËL: That's exciting. So, it's not currently public, the repo, but it might be at some point in the future. STEPHANIE: Yeah, that's right. JOËL: We'll definitely have to mention it on a future episode if that happens so that people following along with the story can go check out the code. STEPHANIE: So, Joël, what's new in your world? JOËL: I've been doing a deep dive into how ActiveRecord works. Particularly, I am debugging some pretty significant slowdowns in querying ActiveRecord models that are backed not by a regular Postgres database but instead a Snowflake data warehouse via an ODBC connection. So, there's a bunch of moving pieces going on here, and it would just take forever to make any queries. And sure, the actual reported query time is longer than for a local Postgres database, but then there's this sort of mystery extra waiting time, and I couldn't figure out why is it taking so much longer than the actual sort of recorded query time. And I started digging into all of this, and it turns out that in addition to executing queries to pull actual data in, ActiveRecord needs to, at various points, query the schema of your data store to pull things like names of tables and what are the indexes and primary keys and things like that. STEPHANIE: Wow. That sounds really cool and something that I have never needed to do before. I'm curious if you noticed...you said that it takes, I guess, longer to query Snowflake than it would a more common Postgres database. Were you noticing this performance slowness locally or on production? JOËL: Both places. So, the nice thing is I can reproduce it locally, and locally, I mean running the Rails app locally. I'm still talking to a remote Snowflake data warehouse, which is fine. I can reproduce that slowness locally, which has made it much easier to experiment and try things. And so, from there, it's really just been a bit of a detective case trying to, I guess, narrow the possibility space and try to understand what are the parts that trigger slowness. So, I'm printing timestamps in different places. I've got different things that get measured. I've not done, like, a profiling tool to generate a flame graph or anything like that. That might have been something cool to try. I just did old-school print statements in a couple of places where I, like, time before, time after, print the delta, and that's gotten me pretty far. STEPHANIE: That's pretty cool. What do you think will be an outcome of this? Because I remember you saying you're digging a little bit into ActiveRecord internals. So, based on, like, what you're exploring, what do you think you could do as a developer to increase some of the performance there? JOËL: I think probably what this ends up being is finding that the Snowflake adapter that I'm using for ActiveRecord maybe has some sort of small bug in it or some implementation that's a little bit too naive that needs to be fine-tuned. And so, probably what ends up happening here is that this finishes as, like, an open-source pull request to the Snowflake Adapter gem. STEPHANIE: Yeah, that's where I thought maybe that might go. And that's pretty cool, too, and to, you know, just be investigating something on your app and being able to make a contribution that it benefits the community. JOËL: And that's what's so great about open source because not only am I able to get the source to go source diving through all of this, because I absolutely need to do that, but also, then if I make a fix, I can push that fix back out to the community, and everybody gets to benefit. STEPHANIE: Cool. Well, that's another thing that I look forward to hearing more on the development of [laughs] later if it pans out that way. JOËL: One thing that has been interesting with this Snowflake work is that there are a lot of moving parts and multiple different packages that I need to install to get this all to work. So, I mentioned that I might be doing a pull request against the Snowflake Adapter for ActiveRecord, but all of this talks through a sort of lower-level technology protocol called ODBC, which is a sort of generic protocol for speaking to data stores, and that actually has two different pieces. I had to install two different packages. There is a sort of low-level executable that I had to install on my local dev machine and that I have to install on our servers. And on my Mac, I'm installing that via Homebrew, which is a system package. And then to get Ruby bindings for that, there is a Ruby gem that I install that allows Ruby code to talk to ODBC, and that's installed via RubyGems or Bundler. And that got me thinking about sort of these two separate ecosystems that I tend to work with every day. We've got sort of the system packages and the, I don't know what you want to call them, language packages maybe, things like RubyGems, but that could also be NPM or whatever your language of choice is, and realizing that we kind of have things split into two different zones, and sometimes we need both and wondering a little bit about why is that difference necessary. STEPHANIE: Yeah, I don't have an answer to that [laughs] question right now, but I can say that that was an area that really tripped me up, I think, when I was first a fledgling developer. And I was really confused about where all of these dependencies were coming from and going through, you know, setting up my first project and being, like, asked to install Postgres on my machine but then also Bundler, which then also installs more dependencies [laughs]. The lines between those ecosystems were not super clear to me. And, you know, even now, like, I find myself really just kind of, like, learning what I need to know to get by [laughs] with my day-to-day work. But I do like what you said about these are kind of the two main layers that you're working with in terms of package management. And it's really helpful to have that knowledge so you can troubleshoot when there is an issue at one or the other. JOËL: And you mentioned Postgres. That's another one that's interesting because there are components in both of those ecosystems. Postgres itself is typically installed via a system package manager, so something like Homebrew on a Mac or apt-get on a Linux machine. But then, if you're interacting with Postgres in a Ruby app, you're probably also installing the pg gem, which are Ruby's bindings for Postgres to allow Ruby to talk to Postgres, and that lives in the package ecosystem on RubyGems. STEPHANIE: Yeah, I've certainly been in the position of, you know, again, as consultants, we oftentimes are also setting up new laptops entirely [laughs] like client laptops and such and bundling and the pg gem is installed. And then at least I have, you know, I have to give thanks to the very clear error message that [laughs] tells me that I don't have Postgres installed on my machine. Because when I mentioned, you know, troubleshooting earlier, I've certainly been in positions where it was really unclear what was going on in terms of the interaction between what I guess we're calling the Ruby package ecosystem and our system level one. JOËL: Especially for things like the pg gem, which need to compile against some existing libraries, those always get interesting where sometimes they'll fail to compile because there's a path to some C compiler that's not set correctly or something like that. For me, typically, that means I need to update the macOS command line tools or the Xcode command line tools; I forget what the name of that package is. And, usually, that does the trick. That might happen if I've upgraded my OS version recently and haven't downloaded the latest version of the command line tools. STEPHANIE: Yeah. Speaking of OS versions, I have a bit of a story to share about using...I've never said this name out loud, but I am pretty sure that it would just be pronounced as wkhtmltopdf [laughs]. For some reason, whenever I see words like that in my brain, I want to, like, make it into a pronounceable thing [laughs]. JOËL: Right, just insert some vowels in there. STEPHANIE: Yeah, wkhtmltopdf [laughs]. Anyway, that was being used in an app to generate PDF invoices or something. It's a pretty old tool. It's a CLI tool, and it's, as far as I can tell, it's been around for a long time but was recently no longer maintained. And so, as I was working on this app, I was running into a bug where that library was causing some issues with the PDF that was generated. So, I had to go down this route of actually finding a Ruby gem that would figure out which package binary to use, you know, based off of my system. And that worked great locally, and I was like, okay, cool, I fixed the issue. And then, once I pushed my change, it turns out that it did not work on CI because CI was running on Ubuntu. And I guess the binary didn't work with the latest version of Ubuntu that was running on CI, so there was just so many incompatibilities there. And I was wanting to fix this bug. But the next step I took was looking into community-provided packages because there just simply weren't any, like, up-to-date binaries that would likely work with these new operating systems. And I kind of stopped at that point because I just wasn't really sure, like, how trustworthy were these community packages. That was an ecosystem I didn't know enough about. In particular, I was having to install some using apt from, you know, just, like, some Linux community. But yeah, I think I normally have a little bit more experience and confidence in terms of the Ruby package ecosystem and can tell, like, what gems are popular, which ones are trustworthy. There are different heuristics I have for evaluating what dependency to pull in. But here I ended up just kind of bailing out of that endeavor because I just didn't have enough time to go down that rabbit hole. JOËL: It is interesting that learning how to evaluate packages is a skill you have to learn that varies from package community to package community. I know that when I used to be very involved with Elm, we would often have people who would come to the Elm community from the JavaScript community who were used to evaluating NPM packages. And one of the metrics that was very popular in the JavaScript community is just stars on GitHub. That's a really important metric. And that wasn't really much of a thing in the Elm community. And so, people would come and be like, "Wait, how do I know which package is good? I don't see any stars on GitHub." And then, it turns out that there are other metrics that people would use. And similarly, you know, in Ruby, there are different ways that you might use to evaluate Ruby gems that may or may not involve stars on GitHub. It might be something entirely different. STEPHANIE: Yeah. Speaking of that, I wanted to plug a website that I have used before called the Ruby Toolbox, and that gives some suggestions for open-source Ruby libraries of various categories. So, if you're looking for, like, a JSON parser, it has some of the more popular ones. If you're looking for, you know, it stores them by category, and I think it is also based on things like stars and forks like that, so that's a good one to know. JOËL: You could probably also look at something like download numbers to see what's popular, although sometimes it's sort of, like, an emergent gem that's more popular. Some of that almost you just need to be a little bit in the community, like, hearing, you know, maybe listening to podcasts like this one, subscribing to Ruby newsletters, going to conferences, things like that, and to realize, okay, maybe, you know, we had sort of an old staple for JSON parsing, but there's a new thing that's twice as fast. And this is sort of becoming the new standard, and the community is shifting towards that. You might not know that just by looking at raw stats. So, there's a human component to it as well. STEPHANIE: Yeah, absolutely. I think an extension of knowing how to evaluate different package systems is this question of like, how much does an average developer need to know about package management? [laughs] JOËL: Yeah, a little bit to a medium amount, and then if you're writing your own packages, you probably need to know a little bit more. But there are some things that are really maybe best left to the maintainers of package managers. Package managers are actually pretty complex pieces of software in terms of all of the dependency management and making sure that when you say, "Oh, I've got Rails, and this other gem, and this other gem, and it's going to find the exact versions of all those gems that play nicely together," that's non-trivial. As a sort of working developer, you don't need to know all of the algorithms or the graph theory or any of that that underlies a package manager to be able to be productive in your career. And even as a package developer, you probably don't need to really know a whole lot of that. STEPHANIE: Yeah, that makes sense. I actually had referred to our internal at thoughtbot here, our kind of, like, expectations for skill levels for developers. And I would say for an average developer, we kind of just expect a basic understanding of these more complex parts of our toolchain, I think, specifically, like, command line tools and package management. And I think I'd mentioned earlier that, for me, it is a very need-to-know basis. And so, yeah, when I was going down that little bit of exploration around why wkhtmltopdf [chuckles] wasn't working [chuckles], it was a bit of a twisty and turning journey where I, you know, wasn't really sure where to go. I was getting very obtuse error messages, and, you know, I had to dive deep into all these forums [laughs] for all the various platforms [laughs] about why libraries weren't working. And I think what I did come away with was that like, oh, like, even though I'm mostly working on my local machine for development, there was some amount of knowledge I needed to have about the systems that my CI and, you know, production servers are running on. The project I was working on happened to have, like, a Docker file for those environments, and, you know, kind of knowing how to configure them to install the packages I needed to install and just knowing a little bit about the different ways of doing that on systems outside of my usual daily workflows. JOËL: And I think that gets back to some of the interesting distinctions between what we might call language packages versus system packages is that language packages more or less work the same across all operating systems. They might have a build step that's slightly different or something like that, but system packages might be pretty different between different operating systems. So, development, for me, is a Mac, and I'm probably installing system packages via something like Homebrew. If I then want that Rails app to run on CI or some Linux server somewhere, I can't use Homebrew to install things there. It's going to be a slightly different package ecosystem. And so, now I need to find something that will install Postgres for Linux, something that will install, I guess, wkhtmltopdf [laughs] for Linux. And so, when I'm building that Docker file, that might be a little bit different for Mac versus for...or I guess when you run a Docker file, you're running a containerized system. So, the goal there is to make this system the same everywhere for everyone. But when you're setting that up, typically, it's more of a Linux-like system. And so running inside the Docker container versus outside on the native Mac might involve a totally different set of packages and a different package tool. As opposed to something like Bundler, you've got your gem file; you bundle install. It doesn't matter if you're on Linux or macOS. STEPHANIE: Yes, I think you're right. I think we kind of answered our own question at the top of the show [laughs] about differences and what do you need to know about them. And I also like how you pointed out, oh yeah, like, Docker is supposed to [laughs], you know, make sure that we're all developing in the same system, essentially. But, you know, sometimes you have different use cases for it. And, yeah, when you were talking about installing an application on your native Mac and using Homebrew, but even, you know, not everyone even uses Homebrew, right? You can install manually [laughs] through whatever official installer that application might provide. So, there's just so many different ways of doing something. And I had the thought that it's too bad that we both [chuckles] develop on Mac because it could be really interesting to get a Linux user's perspective in here. JOËL: You mentioned not installing via Homebrew. A kind of glaring example of that in my personal setup is that I use Postgres.app to manage Postgres on my machine rather than using Homebrew. I've just...over the years, the Homebrew version every time I upgrade my operating system or something, it's just such a pain to update, and I've lost too many hours to it, and Postgres.app just works, and so I've switched to that. Most other things, I'll use the Homebrew version, but Postgres it's now Postgres.app. It's not even a command line install, and it works fine for me. STEPHANIE: Nice. Yeah. That's interesting. That's a good tip. I'll have to look into that next time because I have also certainly had to just install so many [laughs] various versions of Postgres and figure out what's going on with them every time I upgrade my OS. I'm with you, though, in terms of the packages world I'm looking for, it works [laughs]. JOËL: So, you'd mentioned earlier that packages is sort of an area that's a bit of a need-to-know basis for you. Are there, like, particular moments in your career that you remember like, oh, that's the moment where I needed to, like, take some time and learn a little bit of the next level of packages? STEPHANIE: That's a great question. I think the very beginnings of understanding how package versions work when you have multiple projects on your machine; I just remember that being really confusing for me. When I started out, like, you know, as soon as I cloned my second repo [laughs], and was very confused about, like, I'm sure I went through the process of not installing gems using Bundler, and then just having so much chaos [laughs] wrecked in my development environment and, you know, having to ask someone, "I don't understand how this works. Like, why is it saying I have multiple versions of this library or whatever?" JOËL: Have you ever sudo gem installed a gem? STEPHANIE: Oh yeah, I definitely have. I can't [laughs], like, even give a good reason for why I have done it, but I probably was just, like, pulling my hair out, and that's what Stack Overflow told me to do. I don't know if I can recommend that, but it is [chuckles] one thing to do when you just are kind of totally stuck. JOËL: There was a time where I think that that was in the READMEs for most projects. STEPHANIE: Yeah, that's a really good point. JOËL: So, that's probably why a lot of people end up doing that, but then it tends to install it for your system Ruby rather than for...because if you're using something like Rbenv or RVM or ASDF to manage multiple Ruby versions, those end up being what's using or even Homebrew to manage your Ruby. It wouldn't be installing it for those versions of Ruby. It would be installing it for the one that shipped with your Mac. I actually...you know what? I don't even know if Mac still ships with Ruby. It used to. It used to ship with a really old version of Ruby, and so the advice was like, "Hey, every repo tells you to install it with sudo; don't do that. It will mess you up." STEPHANIE: Huh. I think Mac still does ship with Ruby, but don't quote me on that [laughter]. And I think that's really funny that, like, yeah, people were just writing those instructions in READMEs. And I'm glad that we've collectively [laughs] figured out that difference and want to, hopefully, not let other developers fall into that trap [laughs]. Do you have a particular memory or experience when you had to kind of level up your knowledge about the package ecosystem? JOËL: I think one sort of moment where I really had to level up is when I started really needing to understand how install paths worked, especially when you have, let's say, multiple versions of a gem installed because you have different projects. And you want to know, like, how does it know which one it's using? And then you see, oh, there are different paths that point to different directories with the installs. Or when you might have an executable you've installed via Homebrew, and it's like, oh yeah, so I've got this, like, command that I run on my shell, but actually that points to a very particular path, you know, in my Homebrew directory. But maybe it could also point to some, like, pre-installed system binaries or some other custom things I've done. So, there was a time where I had to really learn about how the path shell variable worked on a machine in order to really understand how the packages I installed were sometimes showing up when I invoked a binary and sometimes not. STEPHANIE: Yeah, that is another really great example that I have memories of [laughs] being really frustrated by, especially if...because, you know, we had talked earlier about all the different ways that you can install applications on your system, and you don't always know where they end up [laughs]. JOËL: And this particular memory is tied to debugging Postgres because, you know, you're installing Postgres, and some paths aren't working. Or maybe you try to update Postgres and now it's like, oh, but, like, I'm still loading the wrong one. And why does PSQL not do the thing that I think it does? And so, that forced me to learn a little bit about, like, under the hood, what happens when I type brew install PostgreSQL? And how does that mesh with the way my shell interprets commands and things like that? So, it was maybe a little bit of a painful experience but eye-opening and definitely then led to me, I think, being able to debug my setup much more effectively in the future. STEPHANIE: Yeah. I like that you also pointed out how it was interacting with your shell because that's, like, another can of worms, right? [laughs] In terms of just the complexity of how these things are talking to each other. JOËL: And for those of our listeners who are not familiar with this, there is a shell command that you can use called which, W-H-I-C-H. And you can prefix that in front of another command, and it will tell you the path that it's using for that binary. So, in my case, if I'm looking like, why is this PSQL behaving weirdly or seems to be using the old version, I can type 'which space psql', and it'll say, "Oh, it's going to this path." And I can look at it and be like, oh, it's using my system install of Postgres. It's not using the Homebrew one. Or, oh, maybe it's using the Homebrew install, not my Postgres.app version. I need to, like, tinker with the paths a little bit. So, that has definitely helped me debug my package system more than once. STEPHANIE: Yeah, that's a really good tip. I can recall just totally uninstalling everything [laughs] and reinstalling and fingers crossed it would figure out a route to the right thing [laughs]. JOËL: You know what? That works. It's not the, like, most precise solution but resetting your environment when all else fails it's not a bad solution. So, we've been talking a lot about what it's like to interact with a package ecosystem as developers, as users of packages, but what if you're a package developer? Sometimes, there's a very clear-cut place where to publish, and sometimes it's a little bit grayer. So, I could see, you know, I'm developing a database, and I want that to be on operating systems, probably should be a system-level package rather than a Ruby gem. But what if I'm building some kind of command line tool, and I write it in Ruby because I like writing Ruby? Should I publish that as a gem, or should I publish that as some kind of system package that's installed via Homebrew? Any opinions or heuristics that you would use to choose where to publish on one side or the other? STEPHANIE: As not a package developer [laughs], I can only answer from that point of view. That is interesting because if you publish on a, you know, like, a system repository, then yeah, like, you might get a lot more people using your tool out there because you're not just targeting a specific language's community. But I don't know if I have always enjoyed downloading various things to my system's OS. I think that actually, like, is a bit complicated for me or, like, I try to avoid it if I can because if something can be categorized or, like, containerized in a way that, like, feels right for my mental model, you know, if it's written in Ruby or something really related to things I use Ruby in, it could be nice to have that installed in my, like, systems RubyGems. But I would be really interested to hear if other people have opinions about where they might want to publish a package and what kind of developers they're hoping to find to use their tool. JOËL: I like the heuristic that you mentioned here, the idea of who the audience is because, yeah, as a Ruby developer who already has a Ruby setup, it might be easier for me to install something via a gem. But if I'm not a Ruby developer who wants to use the packages maybe a little bit more generic, you know, let's say, I don't know, it's some sort of command line tool for interacting with GitHub or something like that. And, like, it happens to be written in Ruby, but you don't particularly care about that as a user of this. Maybe you don't have Ruby installed and now you've got to, like, juggle, like, oh, what is RubyGems, and Bundler, and all this stuff? And I've definitely felt that occasionally downloading packages sort of like, oh, this is a Python package. And you're going to need to, like, set up all this stuff. And it's maybe designed for a Python audience. And so, it's like, oh, you're going to set up a virtual environment and all these things. I'm like, I just want your command line tools. I don't want to install a whole language. And so, sometimes there can be some frustration there. STEPHANIE: Yeah, that is very true. Before you even said that, I was like, oh, I've definitely wanted to download a command line tool and be like, first install [laughs] Python. And I'm like, nope, I'm bailing out of this. JOËL: On the other hand, as a developer, it can be a lot harder to write something that's a bit more cross-platform and managing all that. And I've had to deal a little bit with this for thoughtbot's Parity tool, which is a command-line tool for working with Heroku. It allows you to basically run commands on either staging or production by giving you a staging command and a production command for common Heroku CLI tasks, which makes it really nice if you're working and you're having to do some local, some development, some staging, and some production things all from your command line. It initially started as a gem, and we thought, you know what? This is mostly command line, and it's not just Rubyists who use Heroku. Let's try to put this on Homebrew. But then it depends on Ruby because it's written in Ruby. And now we had to make sure that we marked Ruby as a dependency in Homebrew, which meant that Homebrew would then also pull in Ruby as a dependency. And that got a little bit messy. For a while, we even experimented with sort of briefly available technology called Traveling Ruby that allowed you to embed Ruby in your binary, and you could compile against that. That had some drawbacks. So, we ended up rolling that back as well. And eventually, just for maintenance ease, we went back to making this a Ruby gem and saying, "Look, you install it via RubyGems." It does mean that we're targeting more of the Ruby community. It's going to be a little bit harder for other people to install, but it is easier for us to maintain. STEPHANIE: That's really interesting. I didn't know that history about Parity. It's a tool that I have used recently and really enjoyed. But yeah, I think I remember someone having some issues between installing it as a gem and installing it via Homebrew and some conflicts there as well. So, I can also see how trying to decide or maybe going down one path and then realizing, oh, like, maybe we want to try something else is certainly not trivial. JOËL: I think, in me, I have a little bit of the idealist and the pragmatist that fight. The idealist says, "Hey, if it's not, like, aimed for Ruby developers as a, like, you can pull this into your codebase, if it's just command line tools and the fact that it's written in Ruby is an implementation detail, that should be a system package. Do not distribute binaries via RubyGems." That's the idealist in me. The pragmatist says, "Oh, that's a lot of work and not always worth it for both the maintainers and sometimes for the users, and so it's totally okay to ship binaries as RubyGems." STEPHANIE: I was totally thinking that I'm sure that you've been in that position of being a user and trying to download a system package and then seeing it start to download, like, another language. And you're like, wait, what? [laughter] That's not what I want. JOËL: So, you and I have shared some of our heuristics in the way we approach this problem. Now, I'm curious to hear from the audience. What are some heuristics that you use to decide whether your package is better shipped on RubyGems versus, let's say, Homebrew? Or maybe as a user, what do you prefer to consume? STEPHANIE: Yes. And speaking of getting listener feedback, we're also looking for some listener questions. We're hoping to do a bit of a grab-bag episode where we answer your questions. So, if you have anything that you're wanting to hear me and Joël's thoughts on, write us at hosts@bikeshed.fm. JOËL: On that note, shall we wrap up? STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeee!!!!!!! AD: Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Stephanie is hosting a holiday cookie swap. Joël talks about participating in thoughtbot's end-of-the-year hackathon, Ralphapalooza. We had a great year on the show! The hosts wrap up the year and discuss their favorite episodes, the articles, books, and blog posts they've read and loved, and other highlights of 2023 (projects, conferences, etc). Olive Oil Sugar Cookies With Pistachios & Lemon Glaze (https://food52.com/recipes/82228-olive-oil-sugar-cookies-recipe-with-pistachios-lemon) thoughtbot's Blog (https://thoughtbot.com/blog) Episode 398: Developing Heuristics For Writing Software (https://www.bikeshed.fm/398) Episode 374: Discrete Math (https://www.bikeshed.fm/374) Episode 405: Sandi Metz's Rules (https://www.bikeshed.fm/405) Episode 391: Learn with APPL (https://www.bikeshed.fm/391) Engineering Management for the Rest of Us (https://www.engmanagement.dev/) Confident Ruby (https://pragprog.com/titles/agcr/confident-ruby/) Working with Maybe from Elm Europe (https://www.youtube.com/watch?v=43eM4kNbb6c) Sustainable Rails Book (https://sustainable-rails.com/) Episode 368: Sustainable Web Development (https://www.bikeshed.fm/368) Domain Modeling Made Functional (https://pragprog.com/titles/swdddf/domain-modeling-made-functional/) Simplifying Tests by Extracting Side Effects (https://thoughtbot.com/blog/simplify-tests-by-extracting-side-effects) The Math Every Programmer Needs (https://www.youtube.com/watch?v=wzYYT40T8G8) Mermaid.js sequence diagrams (https://mermaid.js.org/syntax/sequenc) Sense of Belonging and Software Teams (https://www.drcathicks.com/post/sense-of-belonging-and-software-teams) Preemptive Pluralization is (Probably) Not Evil (https://www.swyx.io/preemptive-pluralization) Digging through the ashes (https://everythingchanges.us/blog/digging-through-the-ashes/) Transcript: JOËL: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Joël Quenneville. STEPHANIE: And I'm Stephanie Minn. And together, we're here to share a bit of what we've learned along the way. JOËL: So, Stephanie, what's new in your world? STEPHANIE: I am so excited to talk about this. I'm, like, literally smiling [chuckles] because I'm so pumped. Sometimes, you know, we get on to record, and I'm like, oh, I got to think of something that's new, like, my life is so boring. I have nothing to share. But today, I am excited to tell you about [chuckles] the holiday cookie swap that I'm hosting this Sunday [laughs] that I haven't been able to stop thinking about or just thinking about all the cookies that I'm going to get to eat. It's going to be my first time throwing this kind of shindig, and I'm so pleased with myself because it's such a great idea. You know, it's like, you get to share cookies, and you get to have all different types of cookies, and then people get to take them home. And I get to see all my friends. And I'm really [chuckles] looking forward to it. JOËL: I don't think I've ever been to a cookie swap event. How does that work? Everybody shows up with cookies, and then you leave with what you want? STEPHANIE: That's kind of the plan. I think it's not really a...there's no rules [laughs]. You can make it whatever you want it to be. But I'm asking everyone to bring, like, two dozen cookies. And, you know, I'm hoping for a lot of fun variety. Myself I'm planning on making these pistachio olive oil cookies with a lemon glaze and also, maybe, like, a chewy ginger cookie. I haven't decided if I'm going to go so extra to make two types, but we'll see. And yeah, we'll, you know, probably have some drinks and be playing Christmas music, and yeah, we'll just hang out. And I'm hoping that everyone can kind of, like, take home a little goodie bag of cookies as well because I don't think we'll be going through all of them. JOËL: Hearing you talk about this gave me an absolutely terrible idea. STEPHANIE: Terrible or terribly awesome? [laughs] JOËL: So, imagine you have the equivalent of, let's say, a LAN party. You all show up with your laptops. STEPHANIE: [laughs] JOËL: You're on a network, and then you swap browser cookies randomly. STEPHANIE: [laughs] Oh no. That would be really funny. That's a developer's take on a cookie party [laughs] if I've ever heard one. JOËL: Slightly terrifying. Now I'm just browsing, and all of a sudden, I guess I'm logged into your Facebook or something. Maybe you only swap the tracking cookies. So, I'm not actually logged into your Facebook, but I just get to see the different ad networks it would typically show you, and you would see my ads. That's maybe kind of fun or maybe terrifying, depending on what kind of ads you normally see. STEPHANIE: That's really funny. I'm thinking about how it would just be probably very misleading and confusing for those [laughs] analytics spenders, but that's totally fine, too. Might I suggest also having real cookies to munch on as well while you are enjoying [laughs] this browser cookie-swapping party? JOËL: I 100% agree. STEPHANIE: [laughs] JOËL: I'm curious: where do you stand on raisins in oatmeal cookies? STEPHANIE: Ooh. JOËL: This is a divisive question. STEPHANIE: They're fine. I'll let other people eat them. And occasionally, I will also eat an oatmeal cookie with raisins, but I much prefer if the raisins are chocolate chips [chuckles]. JOËL: That is the correct answer. STEPHANIE: [laughs] Thank you. You know, I understand that people like them. They're not for me [laughs]. JOËL: It's okay. Fans can send us hate mail about why we're wrong about oatmeal cookies. STEPHANIE: Yeah, honestly, that's something that I'm okay with being wrong about on the internet [laughs]. So, Joël, what's new in your world? JOËL: So, as of this recording, we've just recently done thoughtbot's end-of-the-year hackathon, what we call Ralphapalooza. And this is sort of a time where you kind of get to do pretty much any sort of company or programming-related activity that you want as long as...you have to pitch it and get at least two other colleagues to join you on the project, and then you've got two days to work on it. And then you can share back to the team what you've done. I was on a project where we were trying to write a lot of blog posts for the thoughtbot blog. And so, we're just kind of getting together and pitching ideas, reviewing each other's articles, writing things at a pretty intense rate for a couple of days, trying to flood the blog with articles for the next few weeks. So, if you're following the blog and as the time this episode gets released, you're like, "Wow, there's been a lot of articles from the thoughtbot blog recently," that's why. STEPHANIE: Yes, that's awesome. I love how much energy that the blog post-writing party garnered. Like, I was just kind of observing from afar, but it sounds like, you know, people who maybe had started posts, like, throughout the year had dedicated time and a good reason to revisit them, even if they had been, you know, kind of just, like, sitting in a draft for a while. And I think what also seemed really nice was people were just around to support, to review, and were able to make that a priority. And it was really cool to see all the blog posts that are queued up for December as a result. JOËL: People wrote some great stuff. So, I'm excited to see all of those come out. I think we've got pretty much a blog post every day coming out through almost the end of December. So, it's exciting to see that much content created. STEPHANIE: Yeah. If our listeners want more thoughtbot content, check out our blog. JOËL: So, as mentioned, we're recording this at the end of the year. And I thought it might be fun to do a bit of a retrospective on what this year has been like for you and I, Stephanie, both in terms of different work that we've done, the learnings we've had, but maybe also look back a little bit on 2023 for The Bike Shed and what that looked like. STEPHANIE: Yes. I really enjoyed thinking about my year and kind of just reveling and having been doing this podcast for over a year now. And yeah, I'm excited to look back a little bit on both things we have mentioned on the show before and things maybe we haven't. To start, I'm wondering if you want to talk a little bit about some of our favorite episodes. JOËL: Favorite episodes, yes. So, I've got a couple that are among my favorites. We did a lot of good episodes this year. I really liked them. But I really appreciated the episode we did on heuristics, that's Episode 398, where we got to talk a little bit about what goes into a good heuristic, how we tend to come up with them. A lot of those, like, guidelines and best practices that you hear people talk about in the software world and how to make your own but then also how to deal with the ones you hear from others in the software community. So, I think that was an episode that the idea, on the surface, seemed really basic, and then we went pretty deep with it. And that was really fun. I think a second one that I really enjoyed was also the one that I did with Sara Jackson as a guest, talking about discrete math and its relevance to the day-to-day work that we do. That's Episode 374. We just had a lot of fun with that. I think that's a topic that more developers, more web developers, would benefit from just getting a little bit more discrete math in their lives. And also, there's a clip in there where Sara reinterprets a classic marketing jingle with some discrete math terms in there instead. It was a lot of fun. So, we'd recommend people checking that one out. STEPHANIE: Nice. Yes. I also loved those episodes. The heuristics one was really great. I'm glad you mentioned it because one of my favorite episodes is kind of along a similar vein. It's one of the more recent ones that we did. It's Episode 405, where we did a bit of a retro on Sandi Metz' Rules For Developers. And those essentially are heuristics, right? And we got to kind of be like, hey, these are someone else's heuristics. How do we feel about them? Have we embodied them ourselves? Do we follow them? What parts do we take or leave? And I just remember having a really enjoyable conversation with you about that. You and I have kind of treated this podcast a little bit like our own two-person book club [laughs]. So, it felt a little bit like that, right? Where we were kind of responding to, you know, something that we both have read up on, or tried, or whatever. So, that was a good one. Another one of my favorite episodes was Episode 391: Learn with APPL [laughs], in which we basically developed our own learning framework, or actually, credit goes to former Bike Shed host, Steph Viccari, who came up with this fun, little acronym to talk about different things that we all kind of need in our work lives to be fulfilled. Our APPL stands for Adventure, Passion, Profit, and Low risk. And that one was really fun just because it was, like, the opposite of what I just described where we're not discussing someone else's work but discovered our own thing out of, you know, these conversations that we have on the show, conversations we have with our co-workers. And yeah, I'm trying to make it a thing, so I'm plugging it again [laughs]. JOËL: I did really like that episode. One, I think, you know, this APPL framework is a little bit playful, which makes it fun. But also, I think digging into it really gives some insight on the different aspects that are relevant when planning out further growth or where you want to invest your sort of professional development time. And so, breaking down those four elements led to some really insightful conversation around where do I want to invest time learning in the next year? STEPHANIE: Yeah, absolutely. JOËL: By the way, we're mentioning a bunch of our favorite things, some past episodes, and we'll be talking about a lot of other types of resources. We will be linking all of these in the show notes. So, for any of our listeners who are like, "Oh, I wonder what is that thing they mentioned," there's going to be a giant list that you can check out. STEPHANIE: Yeah. I love whenever we are able to put out an episode with a long list of things [laughs]. JOËL: It's one of the fun things that we get to do is like, oh yeah, we referenced all these things. And there is this sort of, like, further reading, more threads to pull on for people who might be interested. So, you'd mentioned, Stephanie, that, you know, sometimes we kind of treat this as our own little mini, like, two-person book club. I know that you're a voracious reader, and you've mentioned so many books over the course of the year. Do you have maybe one or two books that have been kind of your favorites or that have stood out to you over 2023? STEPHANIE: I do. I went back through my reading list in preparation for this episode and wanted to call out the couple of books that I finished. And I think I have, you know, I mentioned I was reading them along the way. But now I get to kind of see how having read them influenced my work life this past year, which is pretty cool. So, one of them is Engineering Management for the Rest of Us by Sarah Drasner. And that's actually one that really stuck with me, even though I'm not a manager; I don't have any plans to become a manager. But one thing that she talks about early on is this idea of having a shared value system. And you can have that at the company level, right? You have your kind of corporate values. You can have that at the team level with this smaller group of people that you get to know better and kind of form relationships with. And then also, part of that is, like, knowing your individual values. And having alignment in all three of those tiers is really important in being a functioning and fulfilled team, I think. And that is something that I don't think was really spelled out very explicitly for me before, but it was helpful in framing, like, past work experiences, where maybe I, like, didn't have that alignment and now identify why. And it has helped me this year as I think about my client work, too, and kind of where I sit from that perspective and helps me realize like, oh, like, this is why I'm feeling this way, and this is why it's not quite working. And, like, what do I do about it now? So, I really enjoyed that. JOËL: Would you recommend this book to others who are maybe not considering a management path? STEPHANIE: Yeah. JOËL: So, even if you're staying in the IC track, at least for now, you think that's a really powerful book for other people. STEPHANIE: Yeah, I would say so. You know, maybe not, like, all of it, but there's definitely parts that, you know, she's writing for the rest of us, like, all of us maybe not necessarily natural born leaders who knew that that's kind of what we wanted. And so, I can see how people, you know, who are uncertain or maybe even, like, really clearly, like, "I don't think that's for me," being able to get something out of, like, either those lessons in leadership or just to feel a bit, like, validated [laughs] about the type of work that they aren't interested in. Another book that I want to plug real quick is Confident Ruby by Avdi Grimm. That one was one I referenced a lot this year, working with newer developers especially. And it actually provided a good heuristic [laughs] for me to talk about areas that we could improve code during code review. I think that wasn't really vocabulary that I'd used, you know, saying, like, "Hey, how confident is this code? How confident is this method and what it will receive and what it's returning?" And I remember, like, several conversations that I ended up having on my teams about, like, return types as a result and them having learned, like, a new way to view their code, and I thought that was really cool. JOËL: I mean, learning to deal with uncertainty and nil in Ruby or maybe even, like, error states is just such a core part of writing software. I feel like this is something that I almost wish everyone was sort of assigned maybe, like, a year into their programming career because, you know, I think the first year there's just so many things you've got to learn, right? Like basic programming and, like, all these things. But, like, you're looking maybe I can start going a little bit deeper into some topic. I think that some topic, like, pretty high up, would be building a mental model for how to deal with uncertainty because it's such a source of bugs. And Avdi Grimm's book, Confident Ruby, is...I would put that, yeah, definitely on a recommended reading list for everybody. STEPHANIE: Yeah, I agree. And I think that's why I found myself, you know, then recommending it to other people on my team and kind of having something I can point to. And that was really helpful in the kind of mentorship that I wanted to offer. JOËL: I did a deep dive into uncertainty and edge cases in programs several years back when I was getting into Elm. And I was giving a talk at Elm Europe about how Elm handles uncertainty, which is a little bit different than how Ruby does it. But a lot of the underlying concepts are very similar in terms of quarantining uncertainty and pushing it to the edges and things like that. Trying to write code that is more confident that is definitely a term that I used. And so Confident Ruby ended up being a little bit of an inspiration for my own journey there, and then, eventually, the talk that I gave that summarized my learnings there. STEPHANIE: Nice. Do you have any reading recommendations or books that stood out to you this year? JOËL: So, I've been reading two technical books kind of in tandem this year. I have not finished either of them, but I have been enjoying them. One is Sustainable Rails by David Bryant Copeland. We had an episode at the beginning of this year where we talked a little bit about our initial impressions from, I think, the first chapter of the book. But I really love that vocabulary of writing Ruby and Rails code, in particular, in a way that is sustainable for a team. And that premise, I think, just gives a really powerful mindset to approach structuring Rails apps. And the other book that I've been reading is Domain Modeling Made Functional, so kind of looking at some domain-driven design ideas. But most of the literature is typically written to an object-oriented audience, so taking a look at it from more of a functional programming perspective has been really interesting. And then I've been, weirdly enough, taking some of those ideas and translating back into the object-oriented world to apply to code I'm writing in Ruby. I think that has been a very useful exercise. STEPHANIE: That's awesome. And it's weird and cool how all those things end up converging, right? And exploring different paradigms really just lets you develop more insight into wherever you're working. JOËL: Sometimes the sort of conversion step that you have to do, that translation, can be a good tool for kind of solidifying learnings or better understanding. So, I'm doing this sort of deep learning thing where I'm taking notes as I go along. And those notes are typically around, what other concepts can I connect ideas in the book? So, I'll be reading and say, okay, on page 150, he mentioned this concept. This reminds me of this idea from TDD. I could see this applying in a different way in an object-oriented world. And interestingly, if you apply this, it sort of converges on maybe single responsibility or whatever other OO principle. And that's a really interesting connection. I always love it when you do see sort of two or three different angles converging together on the same idea. STEPHANIE: Yeah, absolutely. JOËL: I've written a blog post, I think, two years ago around how some theory from functional programming sort of OO best practices and then TDD all kind of converge on sort of the same approach to designing software. So, you can sort of go from either direction, and you kind of end in the same place or sort of end up rediscovering principles from the other two. We'll link that in the show notes. But that's something that I found was really exciting. It didn't directly come from this book because, again, I wrote this a couple of years ago. But it is always fun when you're exploring two or three different paradigms, and you find a convergence. It really deepens your understanding of what's happening. STEPHANIE: Yeah, absolutely. I like what you said about how this book is different because it is making that connection between things that maybe seem less related on the surface. Like you're saying, there's other literature written about how domain modeling and object-oriented programming make more sense a little bit more together. But it is that, like, bringing in of different schools of thought that can lead to a lot of really interesting discovery about those foundational concepts. JOËL: I feel like dabbling in other paradigms and in other languages has made me a better Ruby developer and a better OO programmer, a lot of the work I've done in Elm. This book that I'm reading is written in F#. And all these things I can kind of bring back, and I think, have made me a better Ruby developer. Have you had any experiences like that? STEPHANIE: Yeah. I think I've talked a little bit about it on the show before, but I can't exactly recall. There were times when my exploration in static typing ended up giving me that different mindset in terms of the next time I was coding in Ruby after being in TypeScript for a while, I was, like, thinking in types a lot more, and I think maybe swung a little bit towards, like, not wanting to metaprogram as much [laughs]. But I think that it was a useful, like you said, exercise sometimes, too, and just, like, doing that conversion or translating in your head to see more options available to you, and then deciding where to go from there. So, we've talked a bit about technical books that we've read. And now I kind of want to get into some in-person highlights for the year because you and I are both on the conference circuit and had some fun trips this year. JOËL: Yeah. So, I spoke at RailsConf this spring. I gave a talk on discrete math and how it is relevant in day-to-day work for developers, actually inspired by that Bike Shed episode that I mentioned earlier. So, that was kind of fun, turning a Bike Shed episode into a conference talk. And then just recently, I was at RubyConf in San Diego, and I gave a talk there around time. We often talk about time as a single quantity, but there's some subtle distinctions, so the difference between a moment in time versus a duration and some of the math that happens around that. And I gave a few sort of visual mental models to help people keep track of that. As of this recording, the talk is not out yet, so we're not going to be able to link to it. But if you're listening to this later in 2024, you can probably just Google RubyConf "Which Time Is It?" That's the name of the talk. And you'll be able to find it. STEPHANIE: Awesome. So, as someone who is giving talks and attending conferences every year, I'm wondering, was this year particularly different in any way? Was there something that you've, like, experienced or felt differently community-wise in 2023? JOËL: Conferences still feel a little bit smaller than they were pre-COVID. I think they are still bouncing back. But there's definitely an energy that's there that's nice to have on the conference scene. I don't know, have you experienced something similar? STEPHANIE: I think I know what you're talking about where, you know, there was that time when we weren't really meeting in person. And so, now we're still kind of riding that wave of, like, getting together again and being able to celebrate and have fun in that way. I, this year, got to speak at Blue Ridge Ruby in June. And that was a first-time regional conference. And so, that was, I think, something I had noticed, too, is the emergence of regional conferences as being more viable options after not having conferences for a few years. And as a regional conference, it was even smaller than the bigger national Ruby Central conferences. I really enjoyed the intimacy of that, where it was just a single track. So, everyone was watching talks together and then was on breaks together, so you could mingle. There was no FOMO of like, oh, like, I can't make this talk because I want to watch this other one. And that was kind of nice because I could, like, ask anyone, "What did you think of, like, X talk or like the one that we just kind of came out of and had that shared experience?" That was really great. And I got to go tubing for the first time [laughs] in Asheville. That's a memory, but I am still thinking about that as we get into winter. I'm like, oh yeah, the glorious days of summer [laughs] when I was getting to float down a lazy river. JOËL: Nice. I wasn't sure if this was floating down a lazy river on an inner tube or if this was someone takes you out on a lake with a speed boat, and you're getting pulled. STEPHANIE: [laughs] That's true. As a person who likes to relax [laughs], I definitely prefer that kind of tubing over a speed boat [laughs]. JOËL: What was the topic of your talk? STEPHANIE: So, I got to give my talk about nonviolent communication in pair programming for a second time. And that was also my first time giving a talk for a second time [laughs]. That was cool, too, because I got to revisit something and go deeper and kind of integrate even more experiences I had. I just kind of realized that even if you produce content once, like, there's always ways to deepen it or shape it a little better, kind of, you know, just continually improving it and as you learn more and as you get more experience and change. JOËL: Yeah. I've never given a talk twice, and now you've got me wondering if that's something I should do. Because making a bespoke talk for every conference is a lot of work, and it might be nice to be able to use it more than once. Especially I think for some of the regional conferences, there might be some value there in people who might not be able to go to a big national conference but would still like to see your talk live. Having a mix of maybe original content and then content that is sort of being reshared is probably a great combo for a regional conference. STEPHANIE: Yeah, definitely. That's actually a really good idea, yeah, to just be able to have more people see that content and access it. I like that a lot. And I think it could be really cool for you because we were just talking about all the ways that our mental models evolve the more stuff that we read and consume. And I think there's a lot of value there. One other conference that I went to this year that I just want to highlight because it was really cool that I got to do this: I went to RubyKaigi in Japan [laughs] back in the spring. And I had never gone to an international conference before, and now I'm itching to do more of that. So, it would be remiss not to mention it [laughs]. I'm definitely inspired to maybe check out some of the conferences outside of the U.S. in 2024. I think I had always been a little intimidated. I was like, oh, like, it's so far [laughs]. Do I really have, like, that good of a reason to make a trip out there? But being able to meet Rubyists from different countries and seeing how it's being used in other parts of the world, I think, made me realize that like, oh yeah, like, beyond my little bubble, there's so many cool things happening and people out there who, again, like, have that shared love of Ruby. And connecting with them was, yeah, just so new and something that I would want to do more of. So, another thing that we haven't yet gotten into is our actual work-work or our client work [laughs] that we do at thoughtbot for this year. Joël, I'm wondering, was there anything especially fun or anything that really stood out to you in terms of client work that you had to do this year? JOËL: So, two things come to mind that were novel for me. One is I did a Rails integration against Snowflake, the data warehouse, using an ODBC connection. We're not going through an API; we're going through this DB connection. And I never had to do that before. I also got to work with the new-ish Rails multi-database support, which actually worked quite nice. That was, I think, a great learning experience. Definitely ran into some weird edge cases, or some days, I was really frustrated. Some days, I was actually, like, digging into the source code of the C bindings of the ODBC gem. Those were not the best days. But definitely, I think, that kind of integration and then Snowflake as a technology was really interesting to explore. The other one that's been really interesting, I think, has been going much deeper into the single sign-on world. I've been doing an integration against a kind of enterprise SAML server that wants to initiate sign-in requests from their portal. And this is a bit of an alphabet soup, but the term here is IdP-initiated SSO. And so, I've been working with...it's a combination of this third-party kind of corporate SAML system, our application, which is a Rails app, and then Auth0 kind of sitting in the middle and getting all of them to talk to each other. There's a ridiculous number of redirects because we're talking SAML on one side and OIDC on the other and getting everything to line up correctly. But that's been a really fun, new set of things to learn. STEPHANIE: Yeah, that does sound complicated [laughs] just based on what you shared with me, but very cool. And I was excited to hear that you had had a good experience with the Rails multi-database part because that was another thing that I remember being...it had piqued my interest when it first came out. I hope I get to, you know, utilize that feature on a project soon because that sounds really fun. JOËL: One thing I've had to do for this SSO project is lean a lot on sequence diagrams, which are those diagrams that sort of show you, like, being redirected from different places, and, like, okay, server one talks to server two talks, to the browser. And so, when I've got so many different actors and sort of controllers being passed around everywhere, it's been hard to keep track of it in my head. And so, I've been doing a lot of these diagrams, both for myself to help understand it during development, and then also as documentation to share back with the team. And I found that Mermaid.js supports sequence diagrams as a diagram type. Long-term listeners of the show will know that I am a sucker for a good diagram. I love using Mermaid for a lot of things because it's supported. You can embed it in a lot of places, including in GitHub comments, pull requests. You can use it in various note systems like Notion or Obsidian. And you can also just generate your own on mermaid.live. And so, that's been really helpful to communicate with the rest of the team, like, "Hey, we've got this whole process where we've got 14 redirects across four different servers. Here's what it looks like. And here, like, we're getting a bug on, you know, redirect number 8 of 14. I wonder why," and then you can start a conversation around debugging that. STEPHANIE: Cool. I was just about to ask what tool you're using to generate your sequence diagrams. I didn't know that Mermaid supported them. So, that's really neat. JOËL: So, last year, when we kind of looked back over 2022, one thing that was really interesting that we did is we talked about what are articles that you find yourself linking to a lot that are just kind of things that maybe were on your mind or that were a big part of conversations that happened over the year? So, maybe for you, Stephanie, in 2023, what are one or two articles that you find yourself sort of constantly linking to other people? STEPHANIE: Yes. I'm excited you asked about this. One of them is an article by a person named Cat Hicks, who has a PhD in experimental psychology. She's a data scientist and social scientist. And lately, she's been doing a lot of research into the sense of belonging on software teams. And I think that's a theme that I am personally really interested in, and I think has kind of been something more people are talking about in the last few years. And she is kind of taking that maybe more squishy idea and getting numbers for it and getting statistics, and I think that's really cool. She points out belonging as, like, a different experience from just, like, happiness and fulfillment, and that really having an impact on how well a team is functioning. I got to share this with a few people who were, you know, just in that same boat of, like, trying to figure out, what are the behaviors kind of on my team that make me feel supported or not supported? And there were a lot of interesting discussions that came out of sharing this article and kind of talking about, especially in software, where we can be a little bit dogmatic. And we've kind of actually joked about it on the podcast [chuckles] before about, like, we TDD or don't TDD, or, you know, we use X tool, and that's just like what we have to do here. She writes a little bit about how that can end up, you know, not encouraging people offering, like, differing opinions and being able to feel like they have a say in kind of, like, the team's direction. And yeah, I just really enjoyed a different way of thinking about it. Joël, what about you? What are some articles you got bookmarked? [chuckles] JOËL: This year, I started using a bookmark manager, Raindrop.io. That's been nice because, for this episode, I could just look back on, what are some of my bookmarks this year? And be like, oh yeah, this is the thing that I have been using a lot. So, an article that I've been linking is an article called Preemptive Pluralization is (Probably) Not Evil. And it kind of talks a little bit about how going from code that works over a collection of two items to a collection of, you know, 20 items is very easy. But sometimes, going from one to two can be really challenging. And when are the times where you might want to preemptively make something more than one item? So, maybe using it has many association rather than it has one or making an attribute a collection rather than a single item. Controversial is not the word for it, but I think challenges a little bit of the way people typically like to write code. But across this year, I've run into multiple projects where they have been transitioning from one to many. That's been an interesting article to surface as part of those conversations. Whether your team wants to do this preemptively or whether they want to put it off and say in classic YAGNI (You Aren't Gonna Need It) form, "We'll make it single for now, and then we'll go plural," that's a conversation for your team. But I think this article is a great way to maybe frame the conversation. STEPHANIE: Cool. Yeah, I really like that almost, like, a counterpoint to YAGNI [laughs], which I don't think I've ever heard anyone say that out loud [laughs] before. But as soon as you said preemptive pluralization is not evil, I thought about all the times that I've had to, like, write code, text in which a thing, a variable could be either one or many [laughs] things. And I was like, ooh, maybe this will solve that problem for me [laughs]. JOËL: Speaking of pluralization, I'm sure you've been linking to more than just one article this year. Do you have another one that you find yourself coming up in conversations where you've always kind of like, "Hey, dropping this link," where it's almost like your thing? STEPHANIE: Yes. And that is basically everything written by Mandy Brown [laughs], who is a work coach that I actually started working with this year. And one of the articles that really inspired me or really has been a topic of conversation among my friends and co-workers is she has a blog post called Digging Through the Ashes. And it's kind of a meditation on, like, post burnout or, like, what's next, and how we have used this word as kind of a catch-all to describe, you know, this collective sense of being just really tired or demoralized or just, like, in need of a break. And what she offers in that post is kind of, like, some suggestions about, like, how can we be more specific here and really, you know, identify what it is that you're needing so that you can change how you engage with work? Because burnout can mean just that you are bored. It can mean that you are overworked. It can mean a lot of things for different people, right? And so, I definitely don't think I'm alone [laughs] in kind of having to realize that, like, oh, these are the ways that my work is or isn't changing and, like, where do I want to go next so that I might feel more sustainable? I know that's, like, a keyword that we talked about earlier, too. And that, on one hand, is both personal but also technical, right? It, like, informs the kinds of decisions that we make around our codebase and what we are optimizing for. And yeah, it is both technical and cultural. And it's been a big theme for me this year [laughs]. JOËL: Yeah. Would you say it's safe to say that sustainability would be, if you want to, like, put a single word on your theme for the year? Would that be a fair word to put there? STEPHANIE: Yeah, I think so. Definitely discovering what that means for me and helping other people discover what that means for them, too. JOËL: I feel like we kicked off the year 2023 by having that discussion of Sustainable Rails and how different technical practices can make the work there feel sustainable. So, I think that seems to have really carried through as a theme through the year for you. So, that's really cool to have seen that. And I'm sure listeners throughout the year have heard you mention these different books and articles. Maybe you've also been able to pick up a little bit on that. So, I'm glad that we do this show because you get a little bit of, like, all the bits and pieces in the day-to-day, and then we aggregate it over a year, and you can look back. You can be like, "Oh yeah, I definitely see that theme in your work." STEPHANIE: Yeah, I'm glad you pointed that out. It is actually really interesting to see how something that we had talked about early, early on just had that thread throughout the year. And speaking of sustainability, we are taking a little break from the show to enjoy the holidays. We'll be off for a few weeks, and we will be back with a new Bike Shed in January. JOËL: Cheers to a new year. STEPHANIE: Yeah, cheers to a new year. Wrapping up 2023. And we will see you all in 2024. JOËL: On that note, shall we wrap up the whole year? STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeee!!!!!!! AD: Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. More info on our website at tbot.io/ referral. Or you can email us at referrals@thoughtbot.com with any questions.

In this episode, the focus is on RubyConf, the upcoming conference dedicated to the Ruby programming language. They start by talking about the origin and evolution of RubyConf, highlighting its growth in attendance and its impact on the Ruby community. Chelsea details how the conference has adapted to the digital format due to the COVID-19 pandemic but points out the value of in-person connections. They are looking forward to the Community Day event, which will feature various activities to encourage community interaction and an acknowledgment of scholarships that would help more people attend. The event will offer various programming options, workshops, and talks to cater to newcomers and seasoned professionals. There will also be some level of hands-on learning through hacking activities. The conference aims to be inclusive, offering opportunities for mentorship and growth, regardless of one's career stage. Towards the end, the discussion shifts to Ruby Central, the organizing body behind RubyConf and RailsConf. Chelsea and Allison describe multiple avenues for community engagement, ranging from board membership to open-source contributions. They also encourage donations and corporate sponsorships. Don't miss your chance to register for RubyConf and engage with the fantastic Ruby community! RubyConf (https://rubyconf.org/) Follow RubyConf on LinkedIn (https://www.linkedin.com/company/ruby-central-inc/), X (https://twitter.com/rubyconf), YouTube (), or Mastodon (https://ruby.social/@rubyconf). Learn Academy (https://learnacademy.org/) Follow Learn Academy on Facebook (https://www.facebook.com/LEARNSD/), X (https://twitter.com/SDLEARN), LinkedIn (https://www.linkedin.com/school/sd-learn/), or Instagram (https://www.instagram.com/sdlearn/). Follow Chelsea Kaufman on LinkedIn (https://www.linkedin.com/in/chelskaufman/) or X (https://twitter.com/ChelsKaufman). Follow Allison McMillan on LinkedIn (https://www.linkedin.com/in/apmcmillan/) or X (https://twitter.com/allie_p). Visit her website at daydreamsinruby.com (https://daydreamsinruby.com/). Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! Transcript: VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Allison McMillan and Chelsea Kaufman, Board Directors, and RubyConf '23 Co-chairs. Thank you for joining me. ALLISON: Hi, thanks for having us. CHELSEA: Thanks for having us. VICTORIA: Yes, I'm glad that you were able to make time to come on the show today. I understand, Allison, that you've been having very full weeks with family over the last month. Do you want to tell us a little bit more about that? ALLISON: Yeah, it's...we have just ended what I call the gauntlet of Jewish holidays. But, basically, there are four Jewish holidays starting with Rosh Hashanah, which many folks know that's the Jewish New Year. But what a lot of folks don't know is that there are actually four holidays that are all in a row, each about a week apart. And you do different celebratory things for each of them. And so, it's been really amazing and fun, and lots of, like, sharing our home with others and meals and seeing lots of people. But it is also exhausting. And they basically all fell on weekends this year, which was nice from sort of a scheduling perspective but was exhausting in the fact that I basically have not had a weekend in over a month. So, it was wonderful and tiring. And I am, I guess, both happy and sad that they're over now. VICTORIA: Yeah, that does sound like a lot of quality family time, which has its pros and cons [laughs], right? So, after going through that, do you feel more rested? Or what do you feel like you need to do in order to recuperate and return to your normal energy levels after having every weekend full after that? ALLISON: Oh, that's a great question. I've been looking at my calendar to be like, I should take a day off. I should take a break. I'm working for myself and [inaudible 02:02] entrepreneur consultant. So, I do have the flexibility to do so, but it is hard to look at my calendar and be like, yes, I will take this day off because I deserve it. But, ideally, I would take a day or multiple days off. VICTORIA: Yes. And some of us are lucky enough to have a reason to travel for work purposes and to sneak in a little vacation and be productive [laughs] in our companies. So, I'm curious, Chelsea, if you can tell me a little bit about the option for people to come to San Diego in November and take a restful vacation by the beach and learn a little bit more about Ruby. CHELSEA: Yeah, so RubyConf will be in San Diego this year. As a native San-dieagan, I am a bit biased, but November is a beautiful time to be in San Diego. And we're going to be at the Town and Country, which feels a little bit like we're going to be in a, like, Palm Springs resort. They just went through a major renovation. And there's these really awesome, like, lounge areas with fire pits and just places for people to gather, which really kind of aligns itself with some of the stuff that we're planning because we're really trying to focus in on just connecting Rubyists together. So, to me, it feels like the perfect place because I think San Diego is, one, we're a little bit more low key, a little chill. And it's a great place to just gather and connect and share with people that have, you know, similar interests. VICTORIA: Yes, I live in San Diego now, but I was from Washington, D.C., And I would come and visit my family in San Diego once a year. And they would always go on about how great it is and how beautiful, and everyone is so happy and chill. And I was like, sure, whatever. And then we [chuckles] had the opportunity to move here, and now I'm one of those people who says that [laughs]. Like, it's great, especially in November. Everywhere else is getting a little cold and fall. And San Diego has a little bit of fall, but it's still 75 degrees out. I forget what that is in Celsius. But yes, I'm also super excited. CHELSEA: We have, like, fake fall activities that you can go do. Like, Allison, when you're talking about doing all the family activities and things like that, you know, this is when we start thinking about, oh, we need to go to, like, the pumpkin patch and apple picking and do all these things, but it's not cold or, like, fall weather at all. So, you want to get all, like, bundled up in your cute fall clothes or, like, put my kids and bundle them up in cute things. But then they're, like, sweating and trying to do [laughs] all these funny activities. But I think that there's so many beautiful things to do here that we, like, try and do these, like, fall activities. But then we just end up at the beach and play in the sand [laughs]. VICTORIA: Yeah, I will go out in, like, shorts and a T-shirt because it's that kind of weather. And my neighbors will be wearing full puffy jackets and [laughs], like, long pants and a hat. And they're like, "You're not from around here, are you?" [laughs]. It's like, you guys are silly. But it's fun. Yeah, there's seasons, I think, you know, in November...I made a list of suggested activities for my team members since thoughtbot is sponsoring RubyConf this year. And we're going to have a couple of speakers at the event. And we'll have other thoughtboters available at our booth for people to come up and chat with us. So, I'm really thrilled to be hosting everyone. And I made a list of, like, activities, and most of them were about where to see cool animals [laughs]. I was like, of course, there's the zoo, which is the obvious one, but then there's baby leopard sharks, and there's a season for them. I think they will still be around in November; I'm curious if you know, Chelsea, actually. And then there's, like, the safari parks, and whale watching, and the sea lions at La Jolla and, like, just a bunch of cool animals to see that I think it makes San Diego really special. CHELSEA: I agree. The zoo, the safari park are great places to just hang out and see some really cool exhibits. Balboa Park, the museums there are amazing. Liberty Station is one of my favorite places to go; that it's an old historic naval training center that's been converted into an arts and culture area. So, they have, like, little shops. They have...there's museums. There's brew pubs. There's coffee shops. And then there's beautiful, like, grassy areas, and right by the water, it's one of my favorite places to just go and hang out. ALLISON: This is great. I've done zero research on San Diego so far. So, just, like, I'm writing notes of what things to do and see while I'm there. CHELSEA: Yeah, I know the San Diego Ruby group is trying to put together some, like, local events and things that people can gather and do together. I know that there was a talk about doing a taco crawl. I think if I say that on the podcast, it might actually push them to do it because there are some amazing tacos in San Diego to be had. VICTORIA: Yes, I love that taco crawl. I'll reach out to them because I'll help put something like that together. I'm writing a blog post right now about all of these things and about all the other kind of events that are coming up in San Diego this fall. Great location, great time of year to be here. Tell me a little bit more about RubyConf specifically. And what are you all trying to do different this year than in past events? ALLISON: There are a bunch of things that we're doing differently. Our goal this year with this RubyConf is really to sort of focus on more ways to bring the community together. I think in the last little bit so much excitement around Ruby and Ruby Central and just sort of the community in general. It's a hard time in tech. I think people need to be sort of choosier about sort of what they attend and why they're attending something. And so, we really wanted to help folks connect with each other, help folks get to know other people, help folks sort of reconnect to ways that they love Ruby and the Ruby community and being a Ruby programmer. So, one of the things that we're doing differently is we have a three-day conference. And the way that that sort of broken down is the first day is a Community Day. And the first day is comprised of the workshops, as well as sort of this Hack Day, where people can bring their own projects. We're going to have people there that folks can hack with, sort of open-source projects that folks can work on, all sorts of different stuff. So that people can really sort of get to know one another, work with one another, work with people that they might, you know, admire or have followed in the community for a while, and have that sort of really special experience that doesn't feel as conference-y, right? It feels a little bit more sort of organic in terms of the way that the day will flow and, the options that people have, and sort of what that day looks like. And then following that, we have two days of sort of RubConf with talks and speakers, et cetera. And I'll let Chelsea add anything to Community Day and then also jump into some of the sort of new and different things we're doing at RubyConf. CHELSEA: I agree with Allison in that we've really wanted to focus in on the connection side of things. But I think coming out of the last few years, out of even the last year that's been tough in the industry, just finding ways for people to connect, support, lift up each other, I think that that was something we really wanted to do. And we didn't want it to just be about going and seeing speakers. We wanted to find more ways for people to learn from each other, to connect. And so we added in quite a few of these community connection points. So, on that first day, there's a lot of community aspects to it. We have a lot of learning happening with our workshops and also working on projects, hacking together, showing off what you're working on, connecting with people in the community. It's going to be really focused in on everyone's own skills and talents and coming together and supporting each other in where we're at in our careers, in our learning. And then, the next couple of days will look a little bit familiar in the way that it is structured with some new aspects kind of woven in. We'll have our Community Room, where we're bringing different community groups together so that people can learn more about what is going on in the community, how they can support, how they can connect. And in addition to seeing and learning about some of the new things happening in the Ruby community, we'll also have our Career Pathways room again, which will be a place for people to support their own careers. And that room was really set up so that it wasn't just about early career, but also about folks in their mid and senior careers, and finding the advice, finding the resources, finding the mentorship that they might need in whatever stage of their career that they're at, and figuring out how we can together as a community grow as a whole. VICTORIA: I really appreciate the focus on community. And, for me, as managing director at thoughtbot, in deciding to invest in which conferences we want to attend and sponsor, we find more value in groups that are trying to bring people together around a common passion and purpose versus a particular product. But I'd like to hear from each of you if you can tell me, what does the community mean to you? And I'm looking for, like, a personal story on how you've benefited or how you've engaged with the Ruby community in the past. And what makes you motivated as CEOs and founders of your own companies [laughs] to spend all this time organizing a conference? ALLISON: Many, many, many years ago, I did a Rails Girls workshop. It was actually my first introduction into the tech community, into programming in general. And, for me, really, I did Rails Girls. I did not actually expect to like programming. But I was sort of launching a startup, and I wanted to learn more about tech and blah, blah, blah. And at the end of the day, I was, like, so energized and so excited about what I had built and what I had done. The Ruby community in D.C., who I always think is just a group of really special individuals, was so supportive, was so wonderful, was so, like, "Here's where we co-work on Wednesdays. Come to this coffee shop. Here's how you can keep learning," just was so encouraging. You know, I went to the local Ruby meetup sort of really not knowing anything. And they were excited about, you know, newbies being there and asking questions and, you know, really sort of getting to know folks who are just starting out in their programming journey. And really, through that, I mean, I went to my first RubyConf as a scholar. Was strongly encouraged to do a lightning talk, did a lightning talk. That's how I, you know, sort of ended up having a whole bunch of informational interviews and having conversations with folks. And really, that's how I got my first real job in tech. And so, you know, I want people that are coming into the industry now to have that same support, to have those same opportunities, to have that same encouragement. And, for me, sort of planning RubyConf, planning these conferences, being a part of Ruby Central is really me giving back to the community that has gotten me to where I am today, right? And it's amazing, also, to just...I'm still in touch with the people that were at my table, sort of guiding and mentoring at that first Rails Girls session or the people who I met at the first-ever Ruby meetup that I went to. I still talk to them. I'm still in touch with them. We still get together. I still ask them for, you know, advice and guidance sometimes. And sometimes, they ask me, at this point, for advice and guidance, which is fun. But yeah, it just means so much to me that I have really been able to get to where I'm at because of the support and encouragement of the community. CHELSEA: I have a similar story. I guess over, gosh, over a decade ago, I also went to my first RailsBridge and got introduced to the community there at RailsBridge. And, you know, at the time, I wasn't in tech. I was in the theater. I come from the performing arts. I had spent a very long time executive leadership in the theater. And I got introduced to this community that was so warm and welcoming to people wanting to learn and grow. And I was so interested in how communities are built and how people connect together that I started getting more and more involved in the Ruby community here in San Diego. And just like Allison was saying about the welcoming and warmth that she felt from the D.C. community, I felt the same way here in San Diego. Before that, you know, I had spent so many years being the only woman in a room. I had been in an industry that made me feel like my voice was not always heard. And when I walked into this room, I felt like I mattered. I felt like people wanted to hear what I had to say. And they wanted to learn from my experiences. And in 2014, San Diego hosted RubyConf here. And at that point, my business partner and I launched our business, LEARN Academy, and it's still running strong today. But it was about creating that on-ramp for people and a launchpad into this industry where they could make a difference and they could have their voice heard. And they could be a part of a conversation, even if they hadn't been a part of that community for many, many years, that their background mattered, that their growth mattered. And helping people find their voice at a table is something that is so important to me that I love being able to bring that into the planning of this conference, into a lot of the work that I've done with Ruby Central, with LEARN academy. And really just helping people understand that just because you don't have the traditional background, maybe you didn't start programming at the age of two, you can have a different background and a different path and still provide so much value. And I think that that is the thing that I wanted to continue to be a part of and to make sure was a part of the conversation, that we need so many different types of people at the table. And I want to make sure that our community is responsive to that, that it's inclusive to that, that it's equitable as best we can, and just allows people to share their own experiences. And so, you know, I feel like, for me, we're, you know, almost at our 10-year mark at LEARN academy and that we were launching the company at RubyConf in 2014. To have it here again this year is so special to me. I remember being at the conference many years ago; you know, we spend a lot of time helping companies figure out how to work with early-career developers and to create those pipelines for them so that there's career growth for them. And, you know, I remember sitting around the table and just saying, "Hey, who wants an internship? Who wants to, you know, help these early-career developers?" And everyone raised their hand, and we found some of our very first partners at that conference. And it's always been such a warm and welcoming community that has allowed me to feel like I have a voice and then allows me to help other people find theirs. VICTORIA: Wow, thank you both for sharing that. I totally relate to that feeling of a welcoming community and just getting the sense that, like, wow, everyone who does Ruby is really nice [laughs]. And I think that you know, for me, same as Allison, starting in D.C., there were quite a few people who were involved in Women Who Code who were running Ruby meetups. And that's where I met Valerie Woolard, who I think is also coming to San Diego for RubyConf. I'm excited to see her again. And it's interesting for me coming from that perspective and hearing that from both of you because I've also heard a viewpoint on Ruby community as being highly opinionated and causing certain amounts of consternation. So, I'm curious if you have any comments on that. If not, otherwise, I'm grateful that there are people working to bring that better community in the community that I'm more familiar with more to the forefront and making it more inclusive and open for everyone. So, to, like, bring the question all the way back, it's like [chuckles], do you have any comments on, like, if there's a tendency for Rubyists to be really highly opinionated? Or what else can we do to make it more open and inclusive for people to join the community? CHELSEA: I mean, I think that people are going to be opinionated about something that they care a lot about. And I think that the thing that I've noticed in the Ruby community is people love this language. They love programming in this language, and I think that there's something very powerful about that. And it does, you know, lend itself to people [laughs] having very strong opinions about what they think needs to be out there. And, to me, it's not a matter of, like, whether we have strong opinions or not. It has more to do with whether we're listening or not. But I think it's really important for those of us who are leading to be the listeners, and that we should be there to make sure that there is space for people to be heard, whether their opinion is loud or not. And I think that there are people that are going to be louder than others; that is going to be true no matter where we go. But I think that as long as there is intention around making sure that we are listening to even the quietest voices and that we are creating space for the quietest voices, that's where we're going to find more collaboration. But if we're only going out there and saying, "This is the way it needs to be," and we're not willing to listen to anything else, then I think that growth will stop happening because we need to listen to everyone. We need to be able to create some kind of place for people to come together and share ideas; you know, you don't get the perspectives of all these amazing people in the industry. So, that's why I feel like, you know, I've been on the board at Ruby Central for about a year now, and the biggest thing that I feel like I can contribute is to simply listen. If I can help in any way of filtering ideas or creating connections with people because I've been putting my ear to the ground and saying, "Okay, these people are talking about this, and we're expanding here." And we just want to make sure that we're doing the best we can at being open to all different kinds of ideas and not closing anyone off. Maybe your opinion is really strong. It doesn't mean that we should shut you down. It just means that we need to make sure that there's space for other people, too. And I think that that's the part that, you know, as someone who has always been a bit of an introvert, a bit of a wallflower, I understand how hard it is to get my voice out there. And so, I often fight for the quiet people. I think in every language and any space where it's a craft, it's something that we're creating, people get really passionate about it. And that's going to happen. And I think there's something powerful in that because there's going to be change that happens from that. But if we're not doing our part in the listening and making sure that there isn't just one voice, that there's a collective voice, that's the part that I felt so powerful when I joined the community so many years ago was that, even though I had, you know, months of experience, my questions mattered. And as long as we hold on to that, the community will continue to grow. But those of us at Ruby Central and some of the other organizations, if we're creating space to allow people to question, allow people to speak their opinions and listen, then I think that the industry, the community will just continue to thrive because of that. But we have to be open, and we have to be compassionate when we're doing our listening. ALLISON: Yeah, I agree with all of that. And I would just add in safe places, in a way that we're creating sort of safe structures and safe places for folks to communicate. MID-ROLL AD: Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features? We know maintaining your own servers can be costly and that it's easy for spending creep to sneak in when your team isn't looking. By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer. Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops. VICTORIA: What, if you could tell me, what does Ruby really have going for it? Like what makes Ruby a good choice for tech founders or for new companies would make someone decide they want to build with Ruby? ALLISON: First, it's a little bit about just sort of the ease of the language to jump into and to understand, right? There's a lot that you can get done very quickly with Ruby and Rails. And in addition to sort of individuals being able to work in it, there's a whole community of resources, and support, and podcasts, and tutorials, and all sorts of stuff. I know that as an engineering leader at any company, when engineers are coming to me with, like, the desire to use a new language or try something new, part of what I look at is, if I'm going to hire, like, what would hiring look like? What does it look like for engineers to have to ramp up in this area? How long does that take? What resources are available? What sort of community am I pulling from and looking at? And that's both community in terms of sort of technical experience, expertise, years, et cetera, but also non-technical skills, right? What does the community look like in terms of some of those ideals around communication, collaboration, just sort of general pieces like that? And so, I think that, given sort of the strength of open source, strength of community, community contributions, ways to contribute, etcetera, I think that's one of the reasons that it still makes Ruby a really strong choice for folks to build in and to work with. VICTORIA: What type of people, what personas do you think will be the most interested in attending RubyConf? Is it all just going to be, like, senior or super Ruby developers, or what? CHELSEA: Oh, I don't think so. I mean, this RubyConf, in particular, is great for anyone on a learning journey. We've worked really hard to make sure there's a good breadth of programming for different folks in different stages of their careers. I think that, you know, those of you that are maybe earlier on there, this is a great opportunity to meet people who are maybe even a step or two ahead of you. I think that the best mentorship that you can find is someone who is only maybe a year ahead of you because they're going to recognize where you're at and help you along the way. And I think that there's a lot of opportunities here for that. I think that with our Community Day, the hacking that's going to be involved, like, maybe, as a new developer, you wouldn't be able to come in and, like, get your hands really dirty. But you'll get to sit next to somebody who has been through all the different stages and get to watch, and explore, and learn. I think that making those connections could be really great for anyone's career. I think that our mid-level developers, folks that are our management, there's great resources for them to connect with other developers in similar stages. There's great workshops. Because of our focus on the community, I think that it's going to be a place where you can really connect with other Rubyists. And so, if you are at a stage in your career that you want to figure out what that next spring is, where that next ladder step is, this is a good place to see all the different options because you're going to be surrounded by people in all different stages of their careers. And what we've, I think, said now quite a few times is so many people there are just so excited to help people continue that growth. And so, I think that no matter what stage you're in, you're going to find people there that are excited to help you along the way. That being said, I think for our more senior, more advanced, our executive leadership, this is going to be a great place to, one, meet some really great talent, and, two, I think, learn from other folks in the industry of, like, where people are at, what we're struggling with, and how we're changing and doing things differently. So, I really do think there's going to be a little bit of everything for people. And what I love about that is really that it gets to the core and heart of the Ruby community because we're so excited about new folks coming in that that growth continues, that you have folks like Allison who started out as a scholar and want to give back. And then because we have folks at all those different stages, you can find people that are, you know, maybe a step or two ahead of you that are going to be able to help bring you up to that next level. So, I think it's an exciting opportunity for people to really meet new people, learn some new things, maybe find a little bit of encouragement, empowerment on where you're going to go next on your career. VICTORIA: Yeah, absolutely. And it reminds me of an article I read while I was at RailsConf earlier this year about why we do conferences and what's the whole point. And, you know, for me, all of those things are true, like, all those values. As an executive, I'm going to meet a lot of great talent. I'm going to connect with other companies. I'm just going to get to show up and say hi to people and ask them questions in a way that's very informal. And that's so valuable to have that. I think where I was going to go next with this was with Ruby Central, which I believe organizes both RailsConf and RubyConf. (And you can correct me if I'm wrong on that.) I'm curious if there are anything else you want to talk about with, like how the community can engage in support and how other companies could get involved with the community and show their support. CHELSEA: I think that there's quite a few different ways for folks to get involved. We are currently recruiting board members. We just finished a round just now. But I know that in our planning, that we're likely going to bring on at least one, maybe two more, in the next six months. So, I definitely...for folks in the community that want to get involved, that is a really great place to really get involved with Ruby Central. We also have a really strong open-source community. And we're working, oh gosh, with quite a few different companies now that are really helping to support our open-source efforts. And those are also good ways to get involved. You know, we do plan both RailsConf and RubyConf. RailsConf will be in the spring again. And, you know, it takes a village to put on a conference like this and that, you know, we also look for programming committee members to help us shape the program of the conferences. So, if you are interested in any of that, that's also another great way to get involved in the community. We have an amazing programming committee that's helped us with RubyConf. And I'm excited to see what we do next with RailsConf. And I think that you know if you're one that's going to the conference and are saying, "Man, I wish that they would do this," or "I wish I could see that," come and talk to us because that's the best way for us to learn, that we want to hear all of those pieces. But don't be surprised if we then send you an email and say, "Hey, you want to be on our programming committee with us?" ALLISON: I'll add that we also, through our website, we take donations. So, if you want to help monetarily, there's the option to do that on the website. And if you're a company, I mean, we're always looking for conference sponsorships. But if your company also is interested in getting involved in sort of more of a corporate sense of sponsoring or supporting Ruby Central, we are always open to those conversations. You can send an email to contact@rubycentral.org. VICTORIA: That's great. I have a fun question about the conference because I'm leading the event with thoughtbot since I live here. And I'm thinking about some fun swag to give away. Rank your preferences on what kind of swag you'd like to see at the thoughtbot sponsor booth: a thoughtbot-branded surfboard or, a boogie board, a bucket hat, or a pickleball paddle. Any of those interesting for you? ALLISON: Wait, when you say surfboard, like, how am I going to get a surfboard back to D.C.? [laughter] VICTORIA: Okay. I think it's, like, kind of funny because if you win it, it's like, well, what do you do? [laughter] You got to shake it back. That sounds like maybe a boogie board. CHELSEA: Yeah, I'm down for a boogie board. VICTORIA: Thank you so [laughs] much for entertaining me on that one. Is there anything else that you would like to promote today? ALLISON: We would love to see everybody at RubyConf. You can register. Check out the program speakers, et cetera, at rubyconf.org. You can learn more about Ruby Central at rubycentral.org. Those are, I think, the two things that we'd love to make sure everybody knows about. CHELSEA: And if you're here in San Diego, come say hello. VICTORIA: Yes, I have met up with a few random people from the internet [laughs] who have said like, "I'm in San Diego. Who should I say hi [inaudible 34:02]?" I was like, "Me, me, me," [laughter]. So, yes, I'm very happy to meet up for drinks. Chelsea, you and I will have to get together sometime soon before the conference. And I'm super excited for RubyConf. And thank you both so much for being here today. ALLISON: Thanks for having us. CHELSEA: Thank you. VICTORIA: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantsrobots.fm. And you can find me on Twitter @victori_ousg. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time. AD: Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions. Special Guests: Allison McMillan and Chelsea Kaufman.

Jesse chats with Gavin Carew, 2207 BE Alum and Jack In the Box Software Engineer about his Turing story, his tips for being a successful Turing student, his job search, coming up to speed on Kotlin, his current work, advice for current prospective students, asking questions, and optimism for the future. A few classic Jim Weirich conference talks are What all Rubyists should know about Threads - https://youtu.be/4zbN29UkNQw?si=s9v1kqIg22K2v0iu and SOLID Principles in Ruby - https://youtu.be/1BVFlvRPZVM?si=nJ05gm2wI1kOSFHf If you or someone you know are code curious, we encourage you to attend a Turing Try Coding Event. You can register for a Try Coding class at turing.edu/try-coding.  

Stephanie is joined by very special guest, fellow thoughtboter, Senior Developer, and marathon trainer Mina Slater. Mina and Stephanie had just been traveling together for two weeks, sponsored by WNB.rb for RubyKaigi in Matsumoto, Japan, and together, they recount their international adventure! RubyKaigi (https://rubykaigi.org/2023/) WNB.rb (https://www.wnb-rb.dev/) Understanding the Ruby Global VM Lock by observing it by Ivo Anjo (https://rubykaigi.org/2023/presentations/KnuX.html#day1) gvl-tracing (https://github.com/ivoanjo/gvl-tracing) Justin Searls' RubyKaigi 2023 live coverage (https://blog.testdouble.com/field-reports/ruby-kaigi/) Prioritizing Learning episode (https://www.bikeshed.fm/362) Transcript: STEPHANIE: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Stephanie Minn and today. I'm joined by a very special guest, fellow thoughtboter Mina Slater. Mina, would you like to introduce yourself to our audience? MINA: Yeah. Hi, everyone. I am Mina. I am a Senior Developer on Mission Control, which is thoughtbot's DevOps and SRE team. STEPHANIE: So, Mina, what's new in your world? MINA: Well, I start marathon training this week. So I hope that this conversation goes well and lasts you for three months because you're probably not going to see or hear from me all summer. STEPHANIE: Yes. That sounds...it sounds hard, to be honest, marathon training in the summer. When I was doing a bit more running, I always thought I would wake up earlier than I did and, you know, beat the heat, and then I never would, and that really, like, was kind of rough. MINA: Yeah, actually, I was thinking about my plans for today. I didn't wake up early enough to run in the morning. And so I was calculating, like, okay, by midday, it's going to be too hot. So I'm going to have to wait until, like, 6:00 p.m. [laughs] STEPHANIE: Yeah, yeah. Or, if you're like me, there's a very real chance that you just skip it altogether. [laughter] MINA: Well, I have a deadline, so... [laughs] STEPHANIE: That's true. When is your marathon race? MINA: This is actually the first year I'm doing two in a calendar year. So I'm doing Berlin in September. And then, three weeks after that, I'm going to run one in Detroit. STEPHANIE: Nice. At least you'll be ready. You'll, like, have done it. I don't know; it kind of sounds maybe a bit more efficient that way. [laughs] MINA: Theoretically. But, you know, ask me in October. I'll let you know how it goes. STEPHANIE: That's true. You might have to come back on as a guest. [laughs] MINA: Just to talk about how it went. [laughs] STEPHANIE: Yeah, exactly. MINA: So that's what's new with me. What's new in your world, Steph? STEPHANIE: So, a while back on a previous Bike Shed episode, I talked about joining this client team and, in their daily team syncs, in addition to just sharing what we were up to and what we were working on, we would also answer the question what's something new to us. And that was a space for people to share things that they learned or even just, like, new things that they tried, like food, or activities, or whatnot. And I really enjoyed it as a way to get to know the team, especially when I was new to that client project. And recently, someone on the team ended up creating a random question generator. So now the question for the daily sync rotates. And I've been having a lot of fun with that. Some of the ones that I like are, what made you laugh recently? What's currently playing on your Spotify or YouTube? No cheating. MINA: [laughs] STEPHANIE: And then, yesterday, we had what's for dinner? As the question. And I really liked that one because it actually prompted me to [chuckles] think about what I was going to do for dinner as opposed to waiting till 5:00 p.m. and then stressing because I'm already hungry but don't have a plan [chuckles] for how I'm going to feed myself yet. So it ended up being nice because I, you know, kind of was inspired by what other people mentioned about their dinner plans and got my stuff together. MINA: That's shocking to me because we had just come off of two weeks of traveling together. And the one thing I learned about you is that you plan two meals ahead, but maybe that is travel stuff. STEPHANIE: I think that is extremely correct. Because when you're traveling, you're really excited about all the different things that you want to eat wherever you are. And so, yeah, we were definitely...at least I was planning for us, like, two or three meals [laughs] in advance. MINA: [laughs] STEPHANIE: But, when I'm at home, it is much harder to, I don't know, like, be motivated. And it just becomes, like, a daily chore. [laughs] So it's not as exciting. MINA: I think I'm the same way. I just had a whole bunch of family in town. And I was definitely planning dinner before we had breakfast because I'm like, oh, now I have to be responsible for all of these people. STEPHANIE: Yeah. I just mentioned the questions because I've been really having fun with them, and I feel a lot more connected to the team. Like, I just get to know them more as people and the things they're interested in, and what they do in their free time. So, yeah, highly recommend adding a fun question to your daily syncs. MINA: Yeah, we started doing that on Mission Control at our team sync meetings recently, too, where the first person...we actually have an order generator that somebody on the team wrote where it takes everyone's first and last name and scramble them and then randomizes the order. So you kind of have to figure out where in the queue you are and who's coming up next after you. But the first person that goes in the queue every day has to think of an icebreaker question. STEPHANIE: That's kind of a lot of pressure [laughs] for a daily meeting, especially if you're having to unscramble names and then also come up with the icebreaker question. I personally would be very stressed [laughs] by that. But I also can see that it's...I also think it's very fun, especially for a small team like yours. MINA: Yeah, yeah, just seven of us; we get to know really well what letters are in everyone's names. But I was first today, and I didn't have an icebreaker question ready. So I ended up just passing. So that's also an option. STEPHANIE: That's fair. Maybe I'll link you to our random question generator, so you can find some inspiration. [laughs] MINA: Yeah, it's a ChatGPT situation. STEPHANIE: So you mentioned that you and I had just been traveling together for two weeks. And that's because Mina and I were at RubyKaigi in Matsumoto, Japan, earlier this May. And that's the topic of today's episode: Our Experience at RubyKaigi. And the really cool thing that I wanted to mention was that this was all possible because Mina and I were sponsored by WNB.rb, which is a global community of women and non-binary people working in Ruby. And I've mentioned this group on the show before, but I wanted to plug it again because I think that this was something really special that we got to do. WNB runs a lot of initiatives, like, meetups and panels supporting people to speak at conferences and book clubs. And, you know, just many different programming events for supporting women and non-binary Rubyists in their career growth. And they are recently beginning a new initiative to sponsor folks to attend conferences. And Mina, you and I were the first people to get to try this out and go to an international conference. So that was really awesome. It was something that I don't think I would have done without the support from WNB. MINA: And you almost didn't do. I think there was a lot of convincing [chuckles] that went on at the beginning to kind of get you to, like, actually consider coming with me. STEPHANIE: It's true. It's true. I think you had DMed me, and you were, like, so, like, RubyKaigi, like, eyeball emoji. [laughs] I was, I think, hesitant because this was my first international conference. And so there was just a lot of, like, unknowns and uncertainty for me. And I think that's going to be part of what we talk about today. But is there anything that you want to say about WNB and how you felt about being offered this opportunity? MINA: Yeah. When Emily and Jemma, the founders of WNB, approached us with this opportunity and this offer, I think I was...taken aback is not really quite the right words but, like, surprised and honored, really, I think it's a better word. Like, I was very honored that they thought of us and kind of took the initiative to come to us with this offer. So I'm really grateful for this opportunity because going to RubyKaigi, I think it's always something that was on my radar. But I never thought that...well, not never. I thought that I had to go as a speaker, which would have been, like, a three to five-year goal. [laughs] But to be able to go as an attendee with the support of the group and also of thoughtbot was really nice. STEPHANIE: Yeah, absolutely. That investment in our professional development was really meaningful to me. So, like you, I'm very grateful. And if any of our listeners are interested in donating to WNB.rb and contributing to the community's ability to send folks to conferences, you can do so at wnb-rb.dev/donate. Or, if you work for a company that might be interested in sponsoring, you can reach out to them at organizers@wnb-rb.dev. MINA: I highly recommend doing that. STEPHANIE: So, one of the questions I wanted to ask you about in terms of your RubyKaigi experience was, like, how it lined up with your expectations and if it was different or similar to what you were expecting. MINA: Yeah, I have always heard that when people talk about RubyKaigi as a conference and about its contents, the word that everyone uses to describe it is technical. I have already had sort of a little bit of that expectation going in. But I think my interpretation of the word technical didn't really line up with how actually technical it was. And so that was one thing that was different than what I had expected. STEPHANIE: Could you elaborate on what was surprising about the way that it was technical? MINA: Yeah. I think that when I hear technical talks and having been to some Ruby and Rails confs here in the States, when I hear about technical talks, it's a lot more content about people using the technology, how they use Ruby to do certain things, or how they use Rails to achieve certain goals in their day-to-day work or side projects. But it seems at RubyKaigi; it is a lot more about the language itself, how Ruby does certain things, or how interpreters implement Ruby, the language itself. So I think it's much more lower-level than what I was expecting. STEPHANIE: Yeah, I agree. I think you and I have gone to many of Ruby Central conferences in the U.S., like RubyConf and RailsConf. So that was kind of my comparison as well is that was, you know, the experience that I was more familiar with. And then, going into this conference, I was very surprised that the themes of the talks were, like you said, very focused on the language itself, especially performance, tooling, the history and future of Ruby, which I thought was pretty neat. Ruby turns 30, I think, this year. And one thing that I noticed a lot was folks talking about using Ruby to reflect on itself and the possibilities of utilizing those capabilities to improve our experience as developers using the language. MINA: Yeah. I think one of the things I was really fascinated by is...you had mentioned the performance. There were several talks about collecting how Ruby performs at certain levels. And I thought that that was quite interesting and things I had never thought about before, and I'm hoping to think about in the future. [laughs] STEPHANIE: Yeah. One talk that I went to was Understanding the Ruby Global VM Lock by Ivo Anjo. And that was something that, you know, I had an awareness of that Ruby has this GVL and certain...I had, like, a very hand-wavy understanding about how, like, concurrency worked with Ruby because it hasn't been something that I've really needed to know too deeply in my day-to-day work. Like, I feel a little bit grateful not to have run into an issue where I had to, you know, dive deep into it because it was causing problems. [laughs] But attending that talk was really cool because I liked that the speaker did give, like, an overview for folks who might be less familiar but then was able to get really deep in terms of, like, what he was doing workwise with improving his performance by being able to observe how the lock was being used in different threads and, like, where it might be able to be improved. And he shared some of his open-source projects that I'll link in the show notes. But, yeah, that was just something that I was vaguely aware of and haven't yet, like, needed to know a lot about, but, you know, got to understand more by going to this conference. And I don't think I would have gotten that content otherwise. MINA: Yeah, I agree. The talk that you are referencing is one of my favorite as well. I think, like you, kind of this vague idea of there's things going on under the hood in Ruby is always there, but to get a peek behind the curtain a little bit was very enlightening. I wrote down one of the things that he said about how highly optimized Ruby code can still be impacted and be slow if you don't optimize GVL. And he also shared, I think, some strategies for profiling that layer in your product, if that is something you need, which I thought was really cool. STEPHANIE: Yeah. I think I had mentioned performance was a really big theme. But I didn't realize how many levers there were to pull in terms of the way Ruby is implemented or the way that we are able to use Ruby that can improve performance. And it's really cool to see so many people being experts at all of those different components or aspects of making Ruby fast. [laughs] MINA: Yeah. I think that part of the work that we do on Mission Control is monitoring performance and latency for our clients. And while I don't expect having to utilize some of the tools that I learned at RubyKaigi, I expect being aware of these things helping, I think, in the long run. STEPHANIE: Yeah, absolutely. Joël and I have talked on the show about this idea of, like, push versus pull learning. So push, being you consume content that may not be relevant to you right now but maybe will be in the future. And you can remember, like, oh, I watched a talk on this, or I read something about this, and then you can go refer back to it. As opposed to pull being, like, I have this thing that I don't understand, but I need to know right now, so I'm going to seek out resources about it. And I think we kind of landed on that both are important. But at Kaigi, especially, this was very much more push for me where there's a lot of things that I now have an awareness of. But it's a little different, I think, from my experience at Ruby Central conferences where I will look at the schedule, and I will see talks that I'm like, oh, like, that sounds like it will be really relevant to something I'm working through on my client project or, like, some kind of challenging consulting situation. And so the other thing that I noticed that was different was that a lot of the U.S. conferences are more, I think like business and team challenges-focused. So the talks kind of incorporate both a technical and socio-cultural aspect of the problems that they were solving. And I usually really like that because I find them very relatable to my day-to-day work. And that was something that was less common at Kaigi. MINA: Also, that I've never been to a conference that is more on the academic side of things. So I don't know if maybe that is more aligned with what Kaigi feels like. STEPHANIE: Yeah, that's true. I think there were a lot of talks from Ruby Committers who were just sharing, like, what they've been working on, like, what they've been thinking about in terms of future features for Ruby. And it was very much at the end of those talks, like, I'm open to feedback. Like, look out for this coming soon, or, like, help contribute to this effort. And so it was interesting because it was less, like, here are some lessons learned or, like, here are some takeaways, or, like, here's how we did this. And more like, hey, I'm, you know, in the middle of figuring this out, and I'm sharing with you where I'm at right now. But I guess that's kind of the beauty of the open-source community is that you can put out a call for help and contributions. MINA: Yeah, I think they call that peer review in the academic circles. STEPHANIE: [laughs] That's fair. MINA: [laughs] STEPHANIE: Was there anything else that you really enjoyed about the conference? MINA: I think that one of my favorite parts, and we've talked about this a little bit before, is after hours on the second day, we were able to connect with Emori House and have dinner with their members. Emori House is a group that supports female Kaigi attendees specifically. I think it's that they, as a group, rent out an establishment or a house or something, and they all stay together kind of to look out for each other as they attend this very, I think, male-dominated conference. STEPHANIE: Yeah. I loved that dinner with folks from Emori House too. I think the really cool thing to me is that it's just community and action, you know, like, someone wanted to go to this conference and make it easier for other women to go to this conference and decided to get lodging together and do that work of community building. And that social aspect of conferences we hadn't really talked about yet, but it's something that I really enjoy. And it's, like, one of the main reasons that I go to conferences besides learning. MINA: Yeah, I agree. At the Ruby Central conferences, one of my favorite parts is always the hallway track, where you randomly meet other attendees or connect with attendees that you already knew. And like I mentioned, this dinner with Emori House happened on the second night. And I think by midday second day; I was missing that a little bit. The setup for RubyKaigi, I noticed, does not make meeting people and organizing social events as easy as I had been used to, and part of that, I'm sure, is the language barrier. But some places where I had met a lot of the people that I call conference friends for Ruby Central conferences had been at the lunch table. And Kaigi sets up in a way where they send you out with food vouchers for local restaurants, which I thought was really cool. But it doesn't make meeting people and organizing groups to go out together with people you don't already know a little more difficult. So meeting Emori House on the second night was kind of exactly what I had been missing at the moment. STEPHANIE: Yeah, agreed. I also really thrive off of more smaller group interactions like organically, you know, bumping into people on the hallway track, ideally. I also noticed that, at Kaigi, a lot of the sponsors end up hosting parties and meetups after the conference in the evenings. And so that was a very interesting social difference, I think, where the sponsors had a lot more engagement in that sense. You and I didn't end up going to any of those drink-ups, are what they're called. But I think, similarly, if I were alone, I would be a little intimidated to go by myself. And it's kind of one of those things where it's like, oh, if I know someone, then we can go together. But, yeah, I certainly was also missing a bit of a more organic interaction with others. Though, I did meet a few Rubyists from just other places in East Asia, like Taiwan and China. And it was really cool to be in a place where people are thinking about Ruby differently than in the U.S. I noticed in Japan; there's a lot more energy and enthusiasm about it. And, yeah, just folks who are really passionate about making Ruby a long-lasting language, something that, you know, people will continue to want to work with. And I thought that was very uplifting because it's kind of different from what the current industry in the U.S. is looking like in terms of programming languages for the jobs available. MINA: It's really energizing, I think, to hear people be so enthusiastic about Ruby, especially, like you said, when people ask me what I do here, I say, "Developer," and they say, "Oh, what language do you work in?" I always have to be kind of like, "Have you heard of Ruby?" [laughs] And I think it helps that Ruby originated in Japan. They probably feel a little bit, like, not necessarily protective of it, but, like, this is our own, and we have to embrace it and make sure that it is future-facing, and going places, and it doesn't get stale. STEPHANIE: Right. And I think that's really cool, especially to, you know, be around and, like, have conversations about, like you said, it's very energizing. MINA: Yeah, like you mentioned, we did meet several other Rubyists from, like, East Asian countries, which doesn't necessarily always happen when you attend U.S.-based or even European-based conferences. I think that it is just not as...they have to travel from way farther away. So I think it's really cool to hear about RubyConf Taiwan coming up from one of the Rubyists from Taiwan, which is awesome. And it makes me kind of want to go. [laughs] STEPHANIE: Yeah, I didn't know that that existed either. And just realizing that there are Rubyists all over the world who want to share the love of the language is really cool. And I am definitely going to keep a lookout for other opportunities. Now that I've checked off my first international conference, you know, I have a lot more confidence about [laughs] doing it again in the future, which actually kind of leads me to my next question is, do you have any advice for someone who wants to go to Kaigi or wants to go to an international conference? MINA: Yeah, I think I have both. For international conferences in general, I thought that getting a buddy to go with you is really nice. Steph and I were able to...like, you and I were able to kind of support each other in different ways because I think we're both stressed [laughs] about international travel in different ways. So where you are stressed, I'm able to support, and where I'm stressed, you're able to support. So it was really nice and well-rounded experience because of that. And for RubyKaigi specifically, I would recommend checking out some of the previous year's talks before you actually get there and take a look at the schedule when it comes out. Because, like we said, the idea of, I think, technical when people use that word to describe the content at RubyKaigi is different than what most people would expect. And kind of having an idea of what you're getting into by looking at previous videos, I think, will be really helpful and get you in the right mindset to absorb some of the information and knowledge. STEPHANIE: Yeah, absolutely. I was just thinking about...I saw in Ruby Weekly this week Justin Searls had posted a very thorough live blogging of his experience at Kaigi that was much more in the weeds of, like, all of the content of the talks. And also had tips for how to brew coffee at a convenience store in Japan too. So I recommend checking that out if folks are curious about...especially this year before the videos of the talks are out. I think one thing that I would do differently next time if I were to attend Kaigi or attend a conference that supports multiple languages...so there were talks in Japanese and English, and the ones in Japanese were live interpreted. And you and I had attended, like, one or two, but it ended up being a little tough to follow because the slides were a little bit out of sync with the interpretation. I definitely would want to try again and invest a little more into attending talks in Japanese because I do think the content is still even different from what we might be seeing in English. And now that I know that it takes a lot of mental energy, just kind of perhaps loading up on those talks in the morning while I'm still, you know -- MINA: [laughs] STEPHANIE: Fresh-faced and coffee-driven. [laughs] Rather than saving it for the afternoon when it might be a little harder to really focus. MINA: I think my mental energy has a very specific sweet spot because definitely, like, late in the afternoon would not be good for that. But also, like, very early in the morning would also not be very good for that because my coffee hasn't kicked in yet. STEPHANIE: That's very real as well. MINA: Do you think that there is anything that the conference could have done to have made your experience a little tiny bit better? Is there any support that you could have gotten from someone else, be it the conference, or WNB, or thoughtbot, or other people that you had gone with that could have enhanced this experience? STEPHANIE: Hmm, that's an interesting question. I'm not really sure because I was experiencing so many new things -- MINA: [laughs] STEPHANIE: That that was kind of, like, what was top of mind for me was just getting around even just, like, looking at all the little sponsor booths because that was, like, novel for me to see, like, different companies that I've never heard of before that I think when I asked you about expectations earlier, like, I actually came in with not a lot of expectations because I really was just open to whatever it was going to be. And now that I've experienced it once, I think that I have a little more of an idea of what works for me, what I like, what I don't like. And so I think it really comes down to it being quite a personal experience and how you like to attend conferences and so -- MINA: For sure. STEPHANIE: At the end of the day, yeah, like, definitely recommend just going if that opportunity is available to you and determining for yourself how you want that experience to be. MINA: Certainly. I think just by being there you learn a lot about what you like in conferences and how we like to attend conferences. On a personal level, I'm also an organizer with Ruby Central with their scholarship committee. And that's somewhere where we take new Rubyists or first-time conference attendees and kind of lower the barrier for them to attend these conferences. And the important part I wanted to get to is setting them up with a mentor, somebody who has attended one of these conferences before that can kind of help them set goals and navigate. And I thought that someone like that would...at RubyKaigi, being both our first times, might be useful. STEPHANIE: Yeah, absolutely. I think that's totally fair. One thing I do really like about the Ruby Central conferences is the social support. And I think you had mentioned that maybe that was the piece that was a little bit missing for you at this conference. MINA: Yeah. I know that someone had asked early on, I think, like, the night before the conference officially kicked off, whether there is a Slack or Discord space for all conference attendees so that people can organize outings or meals. And that is definitely something that at least the Ruby Central conferences have, and I imagine other conferences do too, that was missing at Kaigi as well. STEPHANIE: I'm wondering if you would go to Kaigi again and maybe be that mentor for someone else. MINA: I think so. I think I had different feelings about it when we were just leaving the conference, kind of feeling like some of these things that I'm learning here or that I'm being made aware of rather at RubyKaigi will come up important in the future, but maybe not right away. So then I was kind of walking away with a sense of, like, oh, maybe this is a conference that is important, but I might deprioritize if other opportunities come up. But then I started to kind of, like, jot down some reflections and retroing with myself on this experience. And I thought what you mentioned about this being the sort of, like, the push learning opportunity is really nice because I went in there not knowing what I don't know. And I think I came out of it at least being a little bit aware of lots of things that I don't know. STEPHANIE: Yeah, yeah. Maybe, like, what I've come away with this conversation is that there is value in conferences being different from each other, like having more options. And, you know, one conference can't really be everything for everyone. And so, for you and I to have had such a very different experience at this particular conference than we normally do, that has value. It also can be something that you end up deciding, like, you're not into, and then you know. So, yeah, I guess that is kind of what I wanted to say about this very new experience. MINA: Yeah, having new experiences, I think, is the important part. It's the same idea as you want to get a diverse group of people in the room together, and you come out with better ideas or better products or whatever because you have other points of view. And I think that attending conferences, even if not around the world, that are different from each other either in academia or just kind of, like, branching out of Ruby Central conferences, too, is a really valuable experience. Maybe conferences in other languages or language-agnostic conferences. STEPHANIE: Yeah, well said. On that note, shall we wrap up? MINA: Let's do it. STEPHANIE: Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeeeee!!!!!!!!!! ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Tobi works at Shopify and is the author of benchee, an Elixir-language benchmarking suite. He runs RUG:B, a Berlin-based Ruby group, maintains SimpleCov and... Lots of stuff. I always feel tired looking at all the stuff Rubyists do :-) Tobi had a pretty extensive formal computer science education, and it's served him well. We also talk about a lot of different Ruby implementations, and various Ruby folks he's met. We also manage to cover a ridiculous variety of different languages and topics, and lots of older software history. He's a very computer-history-literate fellow! http://justtheusefulbits.com/jtub/tobi-pfeiffer-so-many-languages/

Nick is officially an influencer! After Nick accidentally launched a co-host of Rubyists learning Japanese (including Brittany!), the duo chat about learning styles and recommended podcasts. Oh, and upgrade your Rails applications, listeners! Show Notes & Links: Duolingo (https://www.duolingo.com/) akr / all-ruby (https://github.com/akr/all-ruby) Leetcode (https://leetcode.com/) Naming Things (https://www.namingthings.org/) Rubber Duck Dev Show (https://www.rubberduckdevshow.com/) Rails Versions 7.0.3.1, 6.1.6.1, 6.0.5.1, and 5.2.8.1 have been released! (https://rubyonrails.org/2022/7/12/Rails-Versions-7-0-3-1-6-1-6-1-6-0-5-1-and-5-2-8-1-have-been-released) Sponsored By: Honeybadger (https://www.honeybadger.io/) Honeybadger makes you a DevOps hero by combining error monitoring, uptime monitoring and check-in monitoring into a single, easy to use platform. Go to Honeybadger.io (https://www.honeybadger.io/) and discover how Starr, Josh, and Ben created a 100% bootstrapped monitoring solution. AppSignal (https://www.appsignal.com/rorpodcast) Monitor your apps from A to Z: error tracking, performance insights, server metrics, uptime pages, custom dashboards, and more. AppSignal works for all popular Ruby frameworks and automatically instruments and creates beautiful dashboards for Sidekiq, Active Job, and other integrations. As a listener of The Ruby on Rails Podcast, you get a 10% discount and a box of sweet treats. Start your 30-day free trial at https://www.appsignal.com/rorpodcast (https://www.appsignal.com/rorpodcast).

Design patterns on the frontend: this is a subject far too little discussed from what I can tell, yet with a fundamental awareness and regular usage of design patterns, you can dramatically uplevel your frontend code. Rubyists in particular will have a major leg up here over devs coming from communities which are more FP (functional programming) in nature, because the view layer of the web is inherently object-oriented.Ruby developers are well-trained in the ways of object-oriented programming and using design patterns. This is probably why many Rubyists instinctively look askance at certain modern paradigms of frontend programming. It's overly complicated, poorly architected, and rarely understood from a proper OOP perspective. You view source on many websites and it's “div tag soup”. It's a nightmare. You look at how people will write heaps of functional React components, and it's a buggy spaghetti code mess.Well guess what? We can change all that.Web components, and simple libraries like Lit—combined with an understanding of how the DOM works natively plus MVVM (Model-View-ViewModel)—lets us reason about our frontend in similar ways to how we reason about the backend using the OOP paradigm. A web component is simply the "VM" of MVVM, and you easily add in the V part via a declarative template library or just manipulate the DOM (that is, the View) directly in an imperative fashion.So Rubyists, stop feeling like the frontend is out to get you, or you need to avoid it, or contain it. Embrace it! The frontend can be just as fun and rewarding as the backend—if you know what to do with it.CORRECTION: in the recording I said Stimulus doesn't provide view bindings. That's not actually true — you can use data-action attributes so that the events triggered get handled by the controller. However, you can't bind reactive data back into the template. You get targets of course, but it's entirely up to you how you make use of those targets to update the DOM via your Stimulus controller.Links:Model–view–viewmodel - WikipediaModel ← (from server connection or client data store) → ViewModel ← (bindings) → ViewKnockout (web framework) - WikipediaWeb Components - MDNLit: Simple. Fast. Web Components.Article: HTML is a Serialized Object GraphBecome a part of the Fullstack Ruby community and learn how to put your Ruby skills to work on the backend AND the frontend. Know somebody who's a JavaScript developer but is interested in learning more about Ruby? Share the site, podcast, or newsletter with them!The Fullstack Ruby Podcast is a production of Whitefusion, a boutique web studio based in Portland, OR.Theme music courtesy of Epidemic Sound.

This week the Rogues talk to Felipe Vogel about how he's using Bridgetown and pros of using it over Jekyll. Bridgetown is a modernized blogging and static site generator platform forked from Jekyll to provide updated capabilities and a webpack based JavaScript asset pipeline for more modern applications. It also expands up on the work done on JAMstack applications to provide Rubyists with a stable launchpad for their applications. For more on Bridgetown, listen to the November 2021 update and AMA by Bridgetown creator Jared White Panel Charles Max WoodDarren BroemmerValentino Stoll Guest Felipe Vogel Sponsors Top End DevsCoaching | Top End Devs Links Build a blog with BridgetownBuild a blog with Bridgetown - New Updategithub.com/fpsvogel/learn-ruby-and-cs 1The Era of Bridgetown v1 Has Begun. Welcome to the “Pearl”My first Rails app, Plain ReadingRuby for the self-taught developerFelipe Vogel: Rubyist in TrainingGitHub: Felipe Vogelf ( psvoge )Twitter: Felipe Vogel ( @fpsvogel ) Picks Charles- XeroCharles- Author | Top End DevsDarren- RUBY ON RAILS DEVELOPER Demographics And Statistics In The USFelipe- Bridgetown FundraisingValentino- letter_opener_web Special Guest: Felipe Vogel.

This week the Rogues talk to Felipe Vogel about how he's using Bridgetown and pros of using it over Jekyll. Bridgetown is a modernized blogging and static site generator platform forked from Jekyll to provide updated capabilities and a webpack based JavaScript asset pipeline for more modern applications. It also expands up on the work done on JAMstack applications to provide Rubyists with a stable launchpad for their applications. For more on Bridgetown, listen to the November 2021 update and AMA by Bridgetown creator Jared White Panel Charles Max WoodDarren BroemmerValentino Stoll Guest Felipe Vogel Sponsors Top End DevsCoaching | Top End Devs Links Build a blog with BridgetownBuild a blog with Bridgetown - New Updategithub.com/fpsvogel/learn-ruby-and-cs 1The Era of Bridgetown v1 Has Begun. Welcome to the “Pearl”My first Rails app, Plain ReadingRuby for the self-taught developerFelipe Vogel: Rubyist in TrainingGitHub: Felipe Vogelf ( psvoge )Twitter: Felipe Vogel ( @fpsvogel ) Picks Charles- XeroCharles- Author | Top End DevsDarren- RUBY ON RAILS DEVELOPER Demographics And Statistics In The USFelipe- Bridgetown FundraisingValentino- letter_opener_web Special Guest: Felipe Vogel.

Sebastian Wilgosz joins the Rogues to discuss Hanami, a web framework for Rubyists. He discusses how it works and how it differs from other Ruby based web frameworks. He also discusses what's coming down the pipe and how to get started. Check out his website at https://hanamimastery.com Panel Charles Max WoodDarren Broemmer Guest Sebastian Wilgosz Sponsors Top End DevsCoaching | Top End Devs Links HanamiSebastian Wilgosz Twitter: Sebastian Wilgosz ( @sebwilgosz )Twitter: Hanami Mastery ( @HanamiMastery ) Picks Charles- Viscounts of The West KingdomCharles- Author | Top End DevsDarren- Developing Games With RubyDarren- DragonRuby | DragonRubySebastian- Polished Ruby Programming Special Guest: Sebastian Wilgosz.

Sebastian Wilgosz joins the Rogues to discuss Hanami, a web framework for Rubyists. He discusses how it works and how it differs from other Ruby based web frameworks. He also discusses what's coming down the pipe and how to get started. Check out his website at https://hanamimastery.com Panel Charles Max WoodDarren Broemmer Guest Sebastian Wilgosz Sponsors Top End DevsCoaching | Top End Devs Links HanamiSebastian Wilgosz Twitter: Sebastian Wilgosz ( @sebwilgosz )Twitter: Hanami Mastery ( @HanamiMastery ) Picks Charles- Viscounts of The West KingdomCharles- Author | Top End DevsDarren- Developing Games With RubyDarren- DragonRuby | DragonRubySebastian- Polished Ruby Programming Special Guest: Sebastian Wilgosz.

Show notes:Links:Mike MondragonCRDTShip of TheseusExceptional CreaturesShiba Inu Full Transcript:Ben:I'm just gonna dive on in there. I'm so eager. I'm so excited. It's actually weird because Starr is the one that typically starts us off. Josh:Yeah. I thought we were just going to start with our just general banter, and then not introduce the guest until 30 minutes later.Ben:By the way.Josh:It is also our tradition.Ben:Yeah. Well we're getting better at this thing.Josh:Where we say, "Oh, by the way, if Starr doesn't sound like Starr..."Ben:Right, yes. Today Starr doesn't sound like Starr because today's star is Mike Mondragon instead. Welcome Mike.Josh:Hey Mike.Mike:Hey.Ben:Mike is a long time friend of the show, and friend of the founders. Actually, Mike, how long have we known each other? It's been at least 10, maybe 15 years?Mike:Probably 2007 Seattle RB.Ben:Okay.Josh:Yeah. I was going to say you two have known each other much longer than I've even known Ben.Ben:Yeah.Josh:So you go back.Ben:Way back.Mike:Yep.Josh:Yeah.Ben:Yeah.Josh:Because I think Ben and I met in 2009.Ben:Mm-hmm (affirmative).Josh:Or something.Mike:Okay.Ben:Yeah, Mike and I have been hanging out for a long time.Mike:Yeah.Ben:We've known each other through many, many different jobs, and contracts, and so on. It's been awesome.Josh:Yeah, Mike, I feel like I've heard your name since... Yeah, for the last, at least, 10 years just working with Ben. You've always been in the background. And we've realized this is the first time we've actually met face to face, which is crazy. But it's great to... Yeah.Mike:Yeah.Josh:... have a face to put with the little... What is it, a cat avatar? Is a cat in your avatar? You've had that avatar for a really long time I feel like.Mike:Yeah, that's Wallace.Josh:Okay.Mike:So I'm Mond on GitHub and Twitter, and that cat avatar is our tuxedo cat, Wallace. And he is geriatric now. Hopefully he'll live another year. And if you remember in that era of Ruby, all of the Japanese Rubyists had cat icons. And so that was... I don't know. That's why Wallace is my icon.Josh:Yeah. Nice.Ben:So, so do Wallace and Goripav know each other?Mike:No, no, they don't. They're like best friends, right? They had to have met at Seattle RB.Ben:Yeah. Internet friends.Mike:Internet friends, yeah.Ben:Yeah. So, Mike is old school Ruby, way back, way back, yeah. But the other funny thing about the old Rubyists, all those Japanese Rubyists, I remember from RubyConf Denver... Was that 2007? Somewhere around there. I remember going to that and there were mats and a bunch of friends were sitting up at the front, and they all had these miniature laptops. I've never seen laptops so small. I don't know what they were, nine inch screens or something crazy.Mike:Mm-hmm (affirmative).Ben:I was like, "How do you even type on that thing?" But it's a thing. So I guess... I don't know. I haven't been to Japan.Mike:There are laptops that you could only get in Japan and they flash them with some sort of Linux probably.Ben:Yeah. Yeah.Mike:Mm-hmm (affirmative).Josh:Okay. I wonder how long it took them to compile C on there.Mike:Yeah. So, about the orbit with the founders. So, I think I'd put it in my notes that I... And I consider myself a sliver of a Honeybadger in that I did have a conversation with Ben about joining the company. And then in 2017, I did do a little contracting with you guys, which is ironic in that... So we're probably going to talk about cryptocurrencies and Bitcoin. So the Bitcoin protocol is, essentially, on a four-year timer. And in 2017 was the last time that we were building up to, I guess, an explosive end to that cycle. And I had just been working at Salesforce at Desk.com, And I left because of Bitcoin. And then this year, four years later, I, again, just left Salesforce, but I just left from Heroku. And I didn't leave so much because of Bitcoin, I just got a better opportunity, and I'm a principal engineer at Okta, and I'm in the developer experience working on SDKs, primarily, the Golang SDK.Mike:So I think one of the things that they were happy about was that I had experience carrying the pager, and knowing what that's like, and they wanted to have an experienced engineer that would have empathy for the engineers to main the SDK. So I'm really excited to be here, because I'm not going to be carrying the pager, and it is the fun programming. What I imagine, listening to the founders, about the kind of fun programming that you guys get to do, working with different languages and whatnot. So, obviously right now, I'm starting out with Golang. We don't have a Ruby SDK, because OmniAuth provider is the thing that most people use. But, there's also PHP, and some Java, so I'm just looking forward to being able to do a bunch of different languages.Josh:Yeah. That's awesome. Yeah. We don't know anything about SDK teams, Honeybadger. But yeah, it sounds like we have very similar jobs at the moment. So that's cool. We'll have to trade tips at some point. Yeah.Ben:Yeah, I'm excited that you're there, because I'm definitely going to hit you up on the SAML stuff, because SAML's a pain in the tuchus yeah, I'm sure you'll have some insights from your time there.Mike:Well, that was how I was even open-minded to talking to Okta, was the recruiter had contacted me and I think actually it was the recruiter... I don't know the structure of how this works, but a lot of companies have a prospecting recruiter. And I think that a veteran oriented prospecting recruiter contacted me. And so being a veteran, I'll usually entertain those cold calls. And so then when I was at Desk, I wrote... So Desk was a big Rails monolith. I wrote a microservice to break some of the SSO off of the monolith itself. And in writing the API documentation that was on desk.com, I actually used Okta as one of the examples as a SSO identity provider using SAML. So yeah, I have had a little bit of experience from the outside of Okta with SAML. And so maybe I'll have more experience here to answer your questions.Ben:Yeah. We'll have to have you back and we can just do a whole hour on that. It's a fun world.Josh:After we do an hour on SDKs.Ben:Yeah, and your code that you wrote for us still lives on in Honeybadger.Josh:Yeah. Was it the webpack? That was some of the work, right?Ben:Some of it, yeah.Mike:Yep.Josh:Yeah.Ben:And some GitHub integration work.Josh:And the integrations, yeah.Mike:Yeah, well if I remember correctly with the GitHub integration, I did do some GitHub integration, and it tickled your enthusiasm, Ben, and then I think you went in and like refactored that a little bit.Ben:Well, if you have a monolith like Redo that's been around for as long as ours has, things don't... It's like, what was that Theseus' ship, it's goes around the world but you replace things as it goes, and it's never the same app, right?Mike:Yeah, that's the thing, we had discussed this in the prelude around just software engineering in general and how hard it is to maintain a monolith, especially as a company grows and as developers come rolling into a project, you get all of these... Over time you get engineers with different goals, different techniques, different styles of touching your code base, to the point that it becomes very hard to maintain a project. And I think, I don't know if we're going to talk about Heroku at all, but I think that Heroku suffers from a little bit of that, where there's very few original Heroku that are involved in the runtime at least. And I just came from being on the runtime in the control plane. And, definitely, the code base there is... There's maybe one or two people that are still around that have touched that code base from the beginning.Ben:Yeah, let's dive into that, because that's fascinating to me. I know that there's been chatter on Twitter recently that people feel that Heroku is stagnated. That they haven't really brought a lot of innovative stuff to market recently. I remember, actually a funny story, I'm going to tell it myself. I can't remember what year this was, it were way... I don't know, I don't know, early 2000s. I was sitting as part of a focus group, and I can't reveal a lot of information because secrecy and stuff. But anyway, I was part of this focus group and I was asked as part of this group, what as a developer working on Ruby applications and Rails applications, what I thought about this new thing called Heroku. And had it explained to me, "Oh, you just get push", and "Blah, blah, blah", and I poo-pooed the idea. I was like, "Nah, I'm not interested", because I already know how to deploy stuff. I've got Mongrel, I got a DVS.Josh:Say Mongrel.Ben:I know how to use SEP, why do I need this? Like Math, never going to catch on. And so don't follow me for investing advice.Mike:Yeah, totally.Josh:I got my Linodes.Mike:Yeah. Or even back then, I wrote all of my own chef, so I got my own recipes I can-Ben:Right, exactly.Mike:... bare metal at will.Ben:Exactly. So, what do you think, you've been at Heroku, you've seen this process of people having to maintain this code base over a long period of time. What are some tips for people who might be a little earlier on the process? Looking down the road, what do you suggest people think about for having a more maintainable application?Mike:That's interesting. I really think that there is not one size fits all, and actually some of the things that are specific to Heroku, and actually to desk.com when I was there previously, that some of the issues actually stem from Salesforce culture and the way that Salesforce manages its businesses. And so, I guess the thing that I've always liked about Rails, specifically, is that the conventions that are used in Rails, you can drop an experienced Rails developer pretty much into any Rails app and they're going to know the basic conventions. And that saves you so much time to ramping up and bringing your experience into a project. Whereas when you get into bespoke software, then you run into well what were the architectural design patterns 10 years ago compared to now? How much drift has there been in libraries and the language, depending.Mike:And so that is... I don't... That's a very hard question to nail down in a specific way. I would just say in spit balling this, conventions are very important, I would say. So as long as you have a conventions using a framework, then I think that you'll get to go a long ways. However, if you start to use a framework, then you get the everything is a nail and I'm going to use my hammer framework on that. Which is its own thing that I've seen in Ruby, where if you start a project with Rails, I don't think everybody realizes this, but you are essentially going to be doing a type of software development that is in the mindset of Basecamp, right? And if you have an app that is not quite like Basecamp, and then you start to try to extending Rails to do something different, then you're going to start running into issues. And I think that... It makes me sad when I hear people talk poorly about Rails, because oftentimes people are just pushing it into a direction that it's not built to do. Whether they're, like in the old days, like monkey-patching libraries, or whatnot.Ben:Yeah, I think we saw that with the rise of Elixir and Phoenix, right? José just got frustrated with wanting to do some real time stuff. And that really wasn't the wheelhouse for Rails, right? And so he went and built Elixir and Phoenix, and built on top of that. And that became a better hammer for that particular nail than Rails, right? So now if you come into a new project and you're like, "Well, I'm going to do a lot of highly concurrent stuff", well, okay, maybe Rails isn't the best solution. Maybe you should go look at Elixir and Phoenix instead.Mike:Yeah. Yeah. So, with Heroku, I just want to say that it was so awesome to work at Heroku, and the day that I got a job offer to work there, it was like... I still, if I'm having a bad day, I still think about that, and the... I've never used hard drugs, but I would think that somebody that was cocaine high, that's probably what I was feeling when I got the offer from Heroku. I started using Heroku in 2009, and it has a story within our community, it's highly respected. And so I just want to say that I still think very highly of Heroku, and if I was to be doing just a throwaway project, and I just want to write some code and do git push main, or git push Heroku main, then I would definitely do that.Mike:And we were... And I'm not very experienced with the other kinds of competitors right now. I think, like you pointed him out, is it Vercel and Render?Ben:Render. Mm-hmm (affirmative).Mike:Yeah. So I can't really speak to them. I can really just speak to Heroku and some of the very specific things that go on there. I think one of the issues that Heroku suffers from is not the technology itself, but just the Salesforce environment. Because at Salesforce, everything eventually has to be blue, right? And so, Heroku, I don't think they ever could really figure out the right thing to do with Heroku. As well as, the other thing about enterprise software is that if I'm selling Salesforce service cloud or whatever, I'm selling, essentially, I'm selling seats of software licenses. And there's no big margin in selling Compute, because if I'm buying Compute, I expect to be using that.Mike:And so, as a salesperson, I'm not incented to sell Heroku that much because there's just not margins for me in the incentive structure that they have at sales within Salesforce. So I think that's the biggest thing that Heroku has going against it, is that it's living in a Salesforce environment. And as, I guess, a owner of Salesforce being that I have Salesforce stock, I would hope that they would maximize their profits and actually sell Heroku. Who knows, maybe a bunch of developers get together and actually buy the brand and spin that off. That would be the best thing, because I think that Salesforce would probably realize a lot more value out of Heroku just by doing that, even if there's some sort of profit sharing, and then not have to deal with all the other things.Ben:Yeah, that's really interesting. Yeah. The thing about billing, and then selling per user, versus the compute- That's definitely a different world. It's a totally different mindset. And I think Josh that we have now been given a directive step. We should acquire Heroku as part of Honeybadger.Josh:I was going to say, maybe we can acquire it with all of our Doge profits in five or 10 years from now.Mike:Well, yeah. Somebody spin a Heroku coin, a ERC20 token on Ethereum and get everybody to dump their Ethereum into this token.Josh:Mm-hmm (affirmative).Mike:Get that pot of money together. And then that is the Heroku Foundation. Yeah, exactly.Josh:Okay, yeah.Mike:The Heroku Foundation that buys the Heroku brand. I know that we're laughing about it, but actually this is what is possible today. And, I was telling Ben... Well, let me just say a couple of things about the FounderQuest and how it relates to me, is I've been listening to FounderQuest from the first episode, and I'm an only child, and I like to listen to podcasts. So I'll be on my afternoon walk, and I'll be hearing you guys talk, and I'm having this conversation along with you guys listening to the podcasts.Mike:And so, I think, in January, you guys were talking about, or maybe Ben was talking about, $30,000 Bitcoin, and you guys just had your yucks and laughs about it. And it actually made me think critically about this, because I've been involved with Bitcoin since about 2012, and it's like, "Do I have a tinfoil hat on?" Or what do I think? And so, I'm not joking about this, listening to you guys actually has helped me concretely come up with how I feel about this. And first off, I think, I'm bullish on technology. And this is the first epiphany that I had, is all of us have had a career close to Linux, close to Ruby, building backend services, close to virtualization and orchestration. Fortunately, that's been my interest, and fortunately that's been where our industry has gone. And so, when Bitcoin came out, as technologists, all you ever hear, if you don't know anything about Bitcoin, you just hear currency. And you're thinking internet money, you're not thinking about this as a technologist.Mike:And so that was the thing. I wish that Bitcoin had been talked about as a platform, or a framework.Josh:Mm-hmm (affirmative).Mike:And not even called it coin. Because that confuses the issue-Josh:The whole coin thing, just... Yeah.Mike:Yeah, totally. And mining the metaphors-Josh:That alone.Mike:... just totally throws everything off. Because we are talking, we're laughing about it, but this is really possible today. We could come up with a Foundation to buy Heroku with a cryptocurrency, and it would... Yeah. So that's one thing that Ben helped me realize in my thinking around Bitcoin and cryptocurrencies. And I think I'm just bullish on technology. And so to me, again, across our career, there's been so much change. And why would we look at Bitcoin and cryptocurrencies any differently than any other kind of technology? Even a hundred dollar bill with all the holograms on it, that is a kind of financial technology. And so we're just talking about a digital technology, we're not talking about coins I guess.Josh:That's the appeal, a lot of the Altcoins, right? They give everyone a way to invest in those companies, whereas before you would have to... Whatever, be an accredited investor or something to be able to get involved. Is that part of the appeal? I'm probably showing what I know about crypto, which is very little, but I'm excited to... Yeah, maybe you can...Mike:Yeah. Yeah, so I feel like these projects are... I'm not a VC, and I'm not an insider, but from what I can see from afar, in Silicon Valley there's a close group of people that have access to all of these ideas. And there's Angel clubs, and VC clubs, and whatnot, that are funding these startups. And to me, I feel like these crypto projects are the same kind of thing, except for they're just available to the public. And so, I think if I was speaking to another technologist that was interested in cryptocurrencies, is you probably need to get your hands on some of the technology in order to get experience with it.Mike:And so if that means you figure out how to maybe mine some coin on your laptop, or whatever, or you actually pay for it, you should at least have some in your possession, and at least learn about the custodial part of it. Also, there's different software libraries now to actually do programming against it, and platforms, I believe. So that'd be another way to at least tickle your curiosity, is by actually touching the technology and not thinking about the value. So yeah.Ben:Yeah. That, to me, that's one of the most interesting things about the whole coin thing. My younger son is really interested in the crypto space, in the coin and in the other parts of a distributed ledger, and what does that mean, and how does that work? And before I heard about NFTs, he was talking about NFTs. And so it's really interesting to me to see this coming from him. Just yesterday, we had a conversation about CRDTs, right? Because we're talking about how do you merge transactions that are happening in distributed fashion? Right? I was like, "Oh yeah", and it's so weird to have my teenage sons' world colliding with my world in this way.Josh:Yeah.Ben:But it's a lot of fun. And I've got to say, Mike, I got to give you back some credit, talking about the whole coin thing. As you've heard, we're pretty coin skeptical here at Honeybadger, the Founders, but you made a comment in our pre-show conversation. And maybe you didn't make this explicitly, but maybe it's just a way that I heard it. But I think... Well what I heard was, and maybe you actually said this, was basically think about this like an index fund, right? You put dollar cost to averaging, right? You put some money into coin, you put a little bit, it's not going to be your whole portfolio, right? But you don't treat it like a gamble, and you just treat it like an investment, like you would other things that may appreciate in value. And of course you may not.Ben:And so, as a result, I decided, "Okay, I can do that. I can put a little bit of my portfolio into coins". So just this week, and this is the funny part, just this week-Josh:I'm just finding this out now, by the way.Ben:Yeah, yeah. Josh is like... I told my wife about this last night and she was like, "What's Josh going to say?" "Like, I don't know". So anyway, just this week I put a little bit of money into Bitcoin and Ethereum. And that was... When did Elon do his thing about Bitcoin? Was that Thursday morning?Josh:Oh yeah.Ben:I bought, two hours before Elon did his thing, and Bitcoin lost 15% of its value.Mike:That's awesome.Ben:I'm like, "It's okay. It's okay, I'm just putting-Josh:Yeah, you don't sell, it doesn't matter.Mike:What was your emotion? What was your emotion?Ben:Yeah, totally. Yeah. In fact, my first buy, I used Coinbase. And Coinbase was like, "Oh, do you want to do this periodically?" I'm like, "Yes, I do. Every month". Boom.Mike:Oh.Ben:I went ahead and set that up like so, yeah.Mike:Oh, I did not know you could do that.Ben:I'm in it to win it, man.Mike:You should get a hardware wallet. That's the next thing, is you need to learn how to handle your own custody, so-Josh:Right, yeah. You got to... Yeah.Mike:Not leave it on the exchange. Interesting.Josh:Get those hard drives.Mike:Yeah.Josh:Yeah. Ben's a veteran indexer though. So you can handle some dips. Some volatility.Ben:Yeah. Yeah.Josh:I actually, I did make some money off of Bitcoin back in the day, and probably if I would've just held onto it, I would've made a lot more, of course.Mike:Same.Josh:So I accidentally... Back, I don't know when this was, it was maybe five years ago or something, when Bitcoin was going through one of its first early hype cycles, and I was like, "I'll check it". I was learning about it, of course. And so I went and bought some and I think I ran a blockchain Elixir app that someone made, to see how the transactions work and stuff. Read some books on Bitcoin. But I bought some Bitcoin, I can't remember how much, but just left it. I think this was after Coinbase had launched, I'm pretty sure I bought it through Coinbase. But yeah, I just left it, and then that was when it was in the first huge push of Bitcoin where it went up to 20,000 or something. And I remembered that I had it, and I went and looked and oh yeah, I made five grand or something. I put hardly anything into it initially. So I forget what I actually bought with that money. I just sold it and it's like cool, free money.Mike:So you just sold it this year? Or you sold it...Josh:No, I sold it back-Mike:In 17?Josh:I think I sold it at 20... Yeah, this would have been at 17 that I actually sold it, probably.Mike:Did you report it on your taxes, your capital gains?Josh:I did, yes. Yeah, I did.Ben:That's the benefit of having an accountant, because your accountant reminds you, "You know what? You did have some Bitcoin transactions, you should probably look at those".Josh:Can I say on here that I actually put some of it through a Bitcoin tumbler though, just to see how those work?Mike:Yeah, I mean...Josh:And that was a very small amount of money, but I didn't actually report that on my taxes. Because I think I actually forgot where it was or something.Ben:You'll have to explain what a Bitcoin tumbler is.Josh:So a Bitcoin tumbler... Well, I'll try, and then maybe Mike might explain it better, but a Bitcoin tumbler is basically how you anonymize your Bitcoin transaction. If you have some Bitcoin and you want to buy some drugs on the dark web or something, you go and you send your Bitcoin to this tumbler, and then it distributes it to a bunch of random Bitcoin addresses that it gives you. And then you have those addresses, and they're anonymized, because they've been sent through a bunch of peoples' wallets, or something like that.Mike:Yep. That's basically it.Ben:So it's basically money laundering.Josh:Yeah, it's laundering.Mike:Yeah. But if your privacy... I mean, okay-Josh:Yeah, no, I get it. Yeah. I mean, yeah. Because part of the appeal of Bitcoin is some people are just like, "Oh yeah, good money, credit card transactions are so... The governments are recording them and stuff, the NSA probably has a database of them". So Bitcoin is anonymous, but it's not. It's not anonymous. And yeah. So that's why people do this, right?Mike:Yeah. Well that, to me, that's if you want to... So the value of Bitcoin, if you want to get bullish on the value of Bitcoin, the traditional outlook is yeah, the silk road was going on and there's all this illegal stuff going on. Therefore it must be bad. But actually, to me, that's the thing, you know it's good if there's illicit stuff going on, because what's the number one currency that's used right now for illicit transactions? It's dirty US dollar bills. And if you're a drug dealer in central South America, you are collecting, dollar bills United States. You're paying some sort of transport probably at 10, 15% cost to get those dollars back to wherever you're going to hold them. And so, if you're using Bitcoin, you're probably not going to pay that fee. So, to me, it's like okay, that actually proves, at least in my mind, that there is value. That it's being used, right?Josh:Yeah. And you also, you don't want to see... Some people are fanatics about cash going away, even just because as more people move to digital transactions, whether it's just through, whatever, traditional networks, or through crypto. People are using less and less cash. And I feel like, whatever... Like Richard Stallman, he pays for everything in cash though, because he thinks that cash is going to go away someday. And that's a problem for privacy, because you do want a way to pay for things in private in some cases.Mike:Yep. I agree.Josh:Yeah.Ben:My only real beef with Bitcoin, well, aside from the whole requiring power plants just to do a transaction, is that there is Badger coin. This company that is named Honeybadger, it's all about Bitcoin. And they have these ATM's in Canada, and we constantly get support requests from people.Mike:Oh really?Josh:Is this the reason that we've been so down on cryptocurrencies in the past?Ben:I think so.Josh:Because ever since the beginning, since people started making coins, Badger coin came out and then it's been our primary exposure to be honest.Ben:It has been, yeah.Josh:Throughout the past... I don't know how many years it's been. Has it been six-Ben:Yeah, six-Josh:... to eight years?Ben:Yeah, something like that. It's been nuts.Josh:I'd say.Mike:You should send them an invoice, and they actually-Ben:Yeah, so what happens is they had these kiosks where you can buy Bitcoin, right? You put your real money in, and you get your fake money out, right? And the name on the top of the kiosk is Honeybadger. So, someone puts in some money, real money, and they don't get their fake money, then all of a sudden they're upset, right?Mike:Yeah.Ben:And so they... For whatever reason, it doesn't go through, right, I don't know how this works, I've never bought Bitcoin at a kiosk. But so, they're like, "Okay, Honeybadger". And so they Google Honeybadger, and the first result for Honeybadger is us. And so they're like, "Oh, here's a phone number I can call". And they call us. And they're like, "Where's my Bitcoin?" That's like, "Uh, I really can't help you with that".Josh:They do.Ben:"You stole my Bitcoin". It's like, "No, that's not us".Josh:Something just occurred to me. I wonder how many of them are just confused over the fact that Bitcoin transactions can take a while to arrive now, right? It's not always instantaneous, where it used to be a lot faster, but now I know that it can take a while to clear. So I wonder how many of those people are emailing us in the span... Maybe that's why they eventually always go away and we don't hear from them again. Maybe it's not that they're getting help, but it's just that their Bitcoins are arriving. Yeah. I have a feeling that there's some sort of... I'm guessing these are mostly regular normies using, and interacting with this very highly technical product and experience, and even if you're walking up to a kiosk, but there's still a highly technical aspect of it that, like you said Mike, people are thinking coin, they're thinking... The way this maps to their brain is it's like dollar bills. So they're looking at it like an ATM. Yep.Mike:Yeah. When it comes to cryptocurrency and the technology, I don't want to have to think about custody, or any of that other kinds of stuff. It'll be successful when it just is happening, I'm not thinking about it. They're already... In some... I don't know all of the different mobile devices, but I do carry out an iPhone. And so, the wallet on iPhone is pretty seamless now, right? And so I'm not thinking about how that technology is working. I had to associate an Amex with it originally, right? But once I've done that, then all I do is click my button to pay. And there you go. And so I do think that the cryptocurrency technology has a long way to go towards that, because if normal people, the non nerds, have to think about it, then it's not going to be useful. Because in the end-Josh:Yeah.Mike:... humans use tools, right? And so, whatever the tool is, they're going to use it especially if it's easy and it makes their life easier.Ben:So what I really want to know, Mike, is what are your feelings about Dogecoin? Are you bullish on Doge?Mike:Well, I'll answer that, but I wanted to come back to the bit about the NFT, and just talking about the possibilities with technology. And I think that you guys could profit from this.Ben:I like where it's going.Mike:You'll have to do some more research. But I think what you could do... See, I love the origin story of Honeybadger. And maybe not everybody knows about the Honeybadger meme from what is... When was this, two thousand...Ben:2012? 2011?Mike:Yeah, okay. So not everybody... Yeah, bot everybody knows about the meme. I guess, just go Google-Ben:I can link it in the show notes.Josh:It's long dead. This meme is long dead.Mike:Is it? Well it's still awesome. I still love it.Josh:It is.Mike:So, there's so many facets of this that I love. The first one is that... Can I name names on competitors-Ben:Of course.Mike:... in the origins? Okay. So the first one was is that Airbrake, an exception reporting service, was doing a poor job with their customer service. And you guys were like, "We're working on this project, we need exception reporting. It's not working". It's like, "Well, can we just take their library, and build our own backend?" Right? And to me, that is beautiful. And in thinking about this episode, in Heroku, the same opportunity lies for an aspiring developer out there where you could just take the Heroku CLI and point it at your own false backend until you figure out all of the API calls that happen. And I don't know, you have that backed by Kubernetes, or whatever orchestration framework is...Mike:There is the possibility that you could do the same Honeybadger story with Airbrake SDK, as there is with the Heroku CLI. So that's the first thing I love about the Honeybadger story, and the fact the name goes along with the fact that Airbrake had poor customer support, and you guys just were like, "F it, we're going to build our own exception reporting service". Now, in the modern context with NFTs is... I have old man experience with the NFTs in that GIFs, or GIFs, and JPEGs, this is BS that people are gouging for profit. However, the technology of the NFT... This is the thing that I think is beautiful, is that... And I'm not sure which of the NFTs does this, but there is the possibility that you could be the originator of a digital object, and then you sell that digital object. And then as that digital object is traded, then you, as the, I guess, the original creator, you can get a percentage of the sales for the lifetime of that digital asset.Ben:Yeah.Mike:And, I'm not sure which of the NFTs allows that, but that is one of the things, that's one of the value propositions in NFT. So what I was thinking is if you guys did an NFT on the shaw of the original Honeybadger Ruby SDK check-in, that this could be the thing that you guys have an experiment with, is you have real skin in the game, you're playing with the technology and see if that works. And, let me know if you do that, because I might try to buy it. So, we'll see.Josh:Well, we've already got a buyer, why wouldn't we?Mike:Yeah, so..Ben:Indeed, yeah.Josh:See I was thinking maybe you could own various errors or something in Honeybadger.Mike:Yeah, I mean... Whatever digital signature you want to... Whatever you want to sign, and then assign value to.Josh:Yeah, we could NFT our Exceptional Creatures.Mike:Yeah.Josh:Have you seen that, Mike? Have you seen that project?Mike:Yep, yep.Josh:Okay.Mike:I'm well aware of that. Yep.Ben:Yeah. I'm thinking what about open source maintainers, right? Let's say you have this project and someone really wants a particular feature, right? Or they're really happy about a particular feature that you've already done, right? You can sell them that shaw, that commit, that put it into name, right?Mike:Yeah, totally.Ben:You are the proud owner of this feature. Thank you.Mike:Yeah, totally. Yeah, I was hoping that I would come with some ideas. I hope someday in the future that I run into somebody and it's like, "Oh, we heard that podcasts were where ideas were free ideas that were worth a lot of money were thrown about. And I did this project, and now I'm retired. Thank you, Mike". Honeybadgers.Josh:Wait, so Ben are you saying that, so as a committer, so say I commit something to Rails, submit a PR, so then I own that PR once it's merged and it would be like I could sell that then to someone? Is that along the lines of what you're saying?Ben:No, I'm thinking the owner of the project. So, if you commit something to Rails, and you're really excited about it, and you for some reason want to have a trophy of that commit-Josh:Right.Ben:... on a plaque on the wall, right? Then the Rails core group could sell you that token.Josh:Okay. Gotcha.Ben:That trophy, that certificate, like, "Yep. This is your thing. Commissioned by..." It's like naming a star, right?Josh:Yeah.Ben:You buy the rights to a star, and it's fake stuff, right? We're naming stars. But that's the same idea.Josh:Yeah. So you could use that same idea to incentivize open-source contribution. So if you make the PR to Rails and it gets merged, you get this NFT for the PR merge, which you could then actually profit for if it was... Say it was, I don't know, turbo links or something, whatever. Years later, when it's a huge thing and everyone in Rails is using it, maybe Mike's going to come along and be like, "Hey, I'll buy... I want to own the PR for turbo links".Ben:Right.Josh:Yeah. And of course then, you, as the owner, would also profit from any sale between parties later on too. You'd get that little percentage.Mike:Yeah. Well, so when somebody comes up with committer coin, just remember me, I want to airdrop of some committer coin.Josh:We have a name. We've got a name for it. Commit coin.Ben:I've got a new weekend project ahead of me.Mike:Yeah.Josh:Cool. Well, that helps me understand NFTs.Ben:Yeah, I really like the idea of being able to sell ownership rights to a digital asset. That I think a good idea. I don't know that the current implementation that we see on the news is a great implementation of that idea. Buying the rights for a copy of a JPEG, it feels kind of sketchy to me. But maybe there's some sort of, I don't know, PDF document that has some sort of value for some reason. And you can give that, sell that to someone. And to me, it's not so much about the profit, or the transaction, it's the ownership. You can say I am the owner of this thing. Yeah, there can be copies all over the place, but I'm the person that has the ownership, quote unquote, of this thing.Josh:Yeah, yeah. But then you've got to define value Ben. What is value? Okay, so, what makes a PDF more valuable than a JPEG?Mike:Yeah. Yeah. Bring this back to Dogecoin, and value propositions, and whatnot. What is valuable? When you're talking about the value of a JPEG, this reminded me of a conversation I was having with my son. He's 10 years old and he wanted some money to buy, I don't know what it was, and old man voice came out of me and it's like, "That's BS. I don't think that's valuable". And he looked at me and he was like, "It's valuable to me". And it's like, "Oh, you just put a dagger in my heart. I'm killing your dream". And one person's value may not be another person's value. So, on the Dogecoin, that's interesting. Dogecoin is very interesting to me, because I feel like I'm in a quantum state with a Dogecoin where it is a joke, but at the same time it apparently it has value.Mike:And I don't know where I stand on that threshold. I know how to trade Dogecoin. And I know the behavior of Dogecoin, and the behaviors, from a trading standpoint, has changed substantially in the last six months. Before it was a pump and dump kind of thing. Well, actually, you know what? When Dogecoin was first created, its purpose was highlighted by the community. People in podcast land don't realize this, but I'm wearing a 2017 Dogecoin shirt from when the Dogecoin community sponsored the number 98 NASCAR. And the thing of the community was like, "Oh, we have all this money, and we're just being altruistic and we're giving it away". And so they were exercising their belief with this currency, right?Mike:And from then, till now, there was a bit of a cycle to Dogecoin where you could, if you acquired Dogecoin for say under a hundred Satoshis, this is the Dogecoin BTC pair, that was actually a good buy. Just wait for the next pump when somebody does something, and Dogecoin goes over 200, or 300 Satoshis, and then you dump it. And that's basically what I did on this in the last six months. I had a small bag of Dogecoin waiting for the next pump and dump. And I actually did that, but it kept on getting pumped, and then it would stabilize. And then now we're at the point where apparently Elon Musk and Mark Cuban are saying that there's value to it.Mike:And to me, I actually put a lot of credence to that, because these are two public persons that they cannot... If they're pumping things in the public domain, then they have risk, right? And so you can't be those two people, and be pumping, and not run the risk of the FTC of the United States government coming in and saying, "Hey, why were you doing this?" So there's the, I guess for me, a small bit of a guarantee that maybe there is something to Dogecoin.Josh:Yeah. See, the way I think, when you first started you were saying it is a joke, but you're in this dual state, and my initial or immediate thought was it is a joke, but this is the internet, and the internet loves to make silly things real.Mike:Yeah, yeah.Josh:Especially these days.Ben:Yeah. It's pretty funny for all those people that made a bunch of money on GameStop, right? Yeah.Mike:Yeah. Well that's the thing, is in Dogecoin, Doge is, of itself, from a meme from the same time period as Honeybadger, right? The Iba Shinu doggie, right? So, the other thing I don't understand, or the thing that I understand but I don't know how to quantify it for myself, is that, to me... So there's no pre-mine on Dogecoin. There's no one person that owns a lot of Dogecoin from the beginning. Whereas if we're talking about Ethereum, Vitalik Buterin, the founder, or one of the founders of Ethereum, they pre-mined Ethereum, and there's a ton of Ethereum that's owned by the founders. Whereas you compare that to, say, Litecoin, Charlie Lee cloned Bitcoin and created Litecoin. He sold all of his Litecoin. I believed in him when he said he's sold it all. He's a software engineer, just like us. He was Director of Engineering at Coinbase.Mike:He doesn't seem like he's wearing tinfoil hat out there, doing conspiracies. So when he says that he sold his coin in 2017, all of his Litecoin, I totally believe that. Yet today, he is the chairperson of the Litecoin foundation. And so, to me... I actually do have, I placed some value in the benevolence of Litecoin and Dogecoin, because there's not any one person that actually controls it. I guess Charlie Lee, he probably has a stronger voice than most. But he doesn't control the levers.Josh:Not financially.Mike:Yeah.Josh:Yeah.Mike:Yeah. And so then with Dogecoin... So Dogecoin, it'll be awesome if it gets above a dollar, but the structure of Dogecoin will be such as they cannot maintain that.Josh:Right.Mike:Because it's an inflation-Josh:There's no cap, right?Mike:Right.Josh:Yeah.Mike:It's inflation. And so, I don't know the number, I think it's a million Dogecoin are minted every day. So, 10 years from now, if Dogecoin is worth a dollar still, then that means Bitcoin will be worth a lot more than that. So I guess that'd be awesome if Dogecoin stays a dollar. However, the point I'm trying to make is actually there is value in having an inflationary currency, especially if we're talking about living in the structure of our current financial... The way that our current financial markets work, where there is an inflation.Mike:And so if I want to be transacting with a digital currency, I don't want to have to be, say, like having an Argentina kind of moment where my one Dogecoin is worth $5 American today, and then maybe only $3 American a week from now. So to me, I think there is value in Dogecoin in that it's inflationary, and that it will not be as susceptible to speculation bubbles as other currencies. And so, I don't know if that answers your questions on the value of Dogecoin, but those are a couple of reasons why I think that Dogecoin is valuable. Now, am I going to be holding a big bag of Dogecoin in 2022? Probably not. Just to be honest.Ben:We're all about honesty at Honeybadger. I love the episodes where we have to have a disclaimer, this is not financial advice. Please consult competent professionals before investing, et cetera, et cetera. Mike, it has been a delight to have you with us. We appreciate your counterbalance to our coin pessimism that we have amongst the Honeybadger fan base.Josh:Yeah, I think we needed this.Ben:Yeah.Josh:We really needed this.Ben:We really did.Josh:So thank you.Ben:It's been good.Mike:Yeah. Oh, I got one more idea out there. Hopefully, somebody can run with this, is I've been trying to get motivated to do some experimentation with the Bitcoin lightning network. We didn't really talk about these a layer two solutions for scaling, but I think that there is a lot of potential in coming up with an interesting project that lays within the Litecoin* network, it has its value in and of itself, but there's a secondary value of being a note on the Litecoin* network where if there's transactions going through your node, let's say, I don't know how you'd instrument this, but let's say that Honeybadger actually was... That you guys were taking your payments across your own lightning node, then all of the transactions that are going across the lightning network, you're getting a small fee, right? So I think that there's the possibility of a micropayments kind of play there, like for instance, paying by the exception. I mean, literally-*Editor's note from Mike - "in my excitement talking about the Lighting Network I slipped and said Litecoin a couple of times between Lightning Network. Lightning Network is a layer 2 protocol that is primarily intended for scaling Bitcoin and that was what I meant. However, Lightning can be implemented to run on top of Litecoin and Ethereum."Josh:That has come up that has come up in the past, I think at one point.Mike:You can't do micro payments on a credit card.Josh:Yeah.Mike:Right? But you can do micropayments on lightening network. And I'm not selling you guys on this, but I'm saying that there's going to be some nerd out there that it's like, "Oh my God micropayments are here, I can do micropayments on lighting network". And then they're going to do well on that product, but then they're also going to do well on the commission that they're earning on payments going through their node.Josh:This could be used for usage base software as a service billing model.Ben:Totally. And then you get the skim off the top, just like a good affiliate does.Mike:Yes.Ben:I love it.Mike:Yes.Ben:I love it. All right. All right, Mike, we're going to have to do some scheming together. Well, any final words, any parting words besides go by all the Dogecoin that you can?Mike:Yeah. Don't put all your money into the cryptocurrencies. Yeah.Josh:Seems like good advice.Ben:Be smart

What do Rubyists need to know beyond the language fundamentals? What things about the language and its tooling will best serve developers working on projects in Ruby to help them navigate the code and avoid pitfalls that crop up in their apps. Luke, John, and Chuck walk through the ideas in within Ruby and the libraries and tools that ever Rubyist needs to understand in order to excel in their jobs. Panel Charles Max Wood John Epperson Luke Stutters Sponsors Dev Influencers Accelerator Picks Charles- Dev Influencers | Devchat.tv Charles- The Courier (2020) Charles- No Safe Spaces (2019) John- Trailblazer John- Find yourself a local butcher Luke- Getting free stuff Luke- Deleting your data Luke- Putting resistors in computer fans

What do Rubyists need to know beyond the language fundamentals? What things about the language and its tooling will best serve developers working on projects in Ruby to help them navigate the code and avoid pitfalls that crop up in their apps. Luke, John, and Chuck walk through the ideas in within Ruby and the libraries and tools that ever Rubyist needs to understand in order to excel in their jobs. Panel Charles Max Wood John Epperson Luke Stutters Sponsors Dev Influencers Accelerator Picks Charles- Dev Influencers | Devchat.tv Charles- The Courier (2020) Charles- No Safe Spaces (2019) John- Trailblazer John- Find yourself a local butcher Luke- Getting free stuff Luke- Deleting your data Luke- Putting resistors in computer fans

What do Rubyists need to know beyond the language fundamentals? What things about the language and its tooling will best serve developers working on projects in Ruby to help them navigate the code and avoid pitfalls that crop up in their apps. Luke, John, and Chuck walk through the ideas in within Ruby and the libraries and tools that ever Rubyist needs to understand in order to excel in their jobs. Panel Charles Max Wood John Epperson Luke Stutters Sponsors Dev Influencers Accelerator Picks Charles- Dev Influencers | Devchat.tv Charles- The Courier (2020) Charles- No Safe Spaces (2019) John- Trailblazer John- Find yourself a local butcher Luke- Getting free stuff Luke- Deleting your data Luke- Putting resistors in computer fans

This week, Chris was almost running into an issue with the law, Jason is getting his COVID vaccine, and Andrew is chain smoking 100 cigarettes so he can get the COVID vaccine. Smoke ‘em if you got ‘em boys! There is never a dull moment in the life of our “Gang of Rubyists!” Today, the guys discuss Delegated Types, steps to create an online training course, and what Chris’s RailConf 2021 talk is about.

収録日 2019/05/10 (Fri) Show Notes RubyKaigi 2019 Rubyの国内最大規模の年次カンファレンス 期間: 2019/04/18（木）〜20（土） 場所: 福岡国際会議場（福岡空港から地下鉄ですぐ） 前回は仙台 参加者数: 約1,500名 世界40ヶ国から セッション数: 4トラック 66セッション スポンサーブース: 40以上 公用語は英語 日本語 → 英語 の同時通訳はあり 英語 → 日本語 の通訳はなし 公式ノベルティ: Tシャツ, パーカー, 靴下, ステッカー GOLDスポンサーしました 午睡チェックのサービスパンフレット&ステッカー配布 ブース出したりノベルティ工夫しないとあまりアピールにならない 様々なスポンサー: シャトルバス, ランチ屋台, 朝食, タクシー など スポンサーブーススタンプラリー 博多織のオリジナルキーケース オリジナルピンズ 各社ノベルティ RubyKaigi 2019 前夜祭 - Ippudo Party!! - オフィシャルパーティー: 川端商店街貸切（400m） コード懇親会 セッションピックアップ Cleaning up a huge ruby application Ovto: Frontend web framework for Rubyists All bugfixes are incompatibilities Ruby Committers vs the World The Year of Concurrency Pattern matching - New feature in Ruby 2.7 Optimization Techniques Used by the Benchmark Winners RubyGemsのMFAは必ず有効に セッション動画 スライドまとめ（unofficial） 来年は長野県松本市で開催 We’re hiring!! Rubyエンジニア インフラエンジニア ディレクター QA

Rubyists in Other Languages with James Edward Gray II and Steve Klabnik TableXI is offering training for developers and product teams! For more info, email workshops@tablexi.com. Guests Steve Klabnik (https://twitter.com/steveklabnik): Blog (https://www.steveklabnik.com/) James Edward Gray II (https://twitter.com/JEG2): Blog (http://graysoftinc.com/) Summary Ruby is great. But it's not the best tool for everything. On this episode, I talk to James Edward Gray II and Steve Klabnik. Both James and Steve have made substantial contributions to the Ruby and Rails community, and they now both spend lots of time using other languages. We talk about what makes Rust and Elixir interesting for Ruby developers to learn, what some other interesting languages might be. Notes 01:48 - Moving Towards Other Programming Languages from Ruby: Why? 03:39 - Rust - The Rust Programming Language (https://www.rust-lang.org/en-US/) - The Elm Programming Language (http://elm-lang.org/) - The Rust Programming Language (Book) by Steve Klabnik (https://www.amazon.com/Rust-Programming-Language-Steve-Klabnik/dp/1593278284) 17:54 - Other Cool Programming Languages for Rubyists - Scratch (https://scratch.mit.edu/) - Logo (https://en.wikipedia.org/wiki/Logo_(programming_language)) - GameSalad (https://gamesalad.com/) - GameMaker Studio 2 (https://www.yoyogames.com/gamemaker/features) - Prograph (https://en.wikipedia.org/wiki/Prograph) - Abstract Syntax Tree (https://en.wikipedia.org/wiki/Abstract_syntax_tree) 29:22 - Elixir - The Elixir Programming Language (https://elixir-lang.org/) - Erlang (https://app.workte.am/timeoff/team) - Prolog (https://en.wikipedia.org/wiki/Prolog) - Pattern Matching (https://en.wikipedia.org/wiki/Pattern_matching) Related Episodes Programming Languages and Communication With Kerri Miller (http://www.techdoneright.io/34) React Native with Gant Laborde, Ed LaFoy, and Brent Vatne (http://www.techdoneright.io/32) Ruby Tapas and Avoiding Code with Avdi Grimm (http://www.techdoneright.io/24) The Elm Programming Language With Corey Haines (http://www.techdoneright.io/17) Special Guests: James Edward Gray II and Steve Klabnik.

Panel: Mark Erikson Eric Berry Josh Adams Special Guests: Steve Bussey In this episode of Elixir Mix, the panel talks to Steve Bussey about Elixir Panel. Steve is a software architect at SalesLoft, which is a company that does sales enablement software to help teams grow and become sales organizations. They talk about how his company was introduced to Elixir, why Rubyists are leaving for Elixir, and sharing sessions. They also touch on how developers have reacted to new changes within the company, the biggest hurdles people face when getting into Elixir, and more! In particular, we dive pretty deep on: Steve intro Software architect at SalesLoft Started off with Ruby and now work heavily with Elixir What size is the engineer team at SalesLoft? How did Elixir get introduced to your company? Having a single advocate for a language promoting it in the company The idea of being a “champion” Shaping how other learn and consume What do you think the reason is for Ruby developers leaving for Elixir? Promises that Elixir provides Erlang A different paradigm JavaScript and React Sharing sessions Serving your users properly Their Rails application Microservices How have the developers reacted to these changes coming in? Slow process Professional development initiative Everyone that’s put in the time haven’t’ said anything bad about Elixir What was the biggest hurdle for people getting into Elixir? The importance of asking questions The XY problem And much, much more! Links: SalesLoft Ruby Elixir Erlang JavaScript React Rails Mockery stephenbussey.com Steve’s GitHub @YOOOODAAAA Sponsors: Digital Ocean Picks: Mark Seafile Josh alchemist.el Steve Architecture the Lost Years by Robert Martin

Panel: Mark Erikson Eric Berry Josh Adams Special Guests: Steve Bussey In this episode of Elixir Mix, the panel talks to Steve Bussey about Elixir Panel. Steve is a software architect at SalesLoft, which is a company that does sales enablement software to help teams grow and become sales organizations. They talk about how his company was introduced to Elixir, why Rubyists are leaving for Elixir, and sharing sessions. They also touch on how developers have reacted to new changes within the company, the biggest hurdles people face when getting into Elixir, and more! In particular, we dive pretty deep on: Steve intro Software architect at SalesLoft Started off with Ruby and now work heavily with Elixir What size is the engineer team at SalesLoft? How did Elixir get introduced to your company? Having a single advocate for a language promoting it in the company The idea of being a “champion” Shaping how other learn and consume What do you think the reason is for Ruby developers leaving for Elixir? Promises that Elixir provides Erlang A different paradigm JavaScript and React Sharing sessions Serving your users properly Their Rails application Microservices How have the developers reacted to these changes coming in? Slow process Professional development initiative Everyone that’s put in the time haven’t’ said anything bad about Elixir What was the biggest hurdle for people getting into Elixir? The importance of asking questions The XY problem And much, much more! Links: SalesLoft Ruby Elixir Erlang JavaScript React Rails Mockery stephenbussey.com Steve’s GitHub @YOOOODAAAA Sponsors: Digital Ocean Picks: Mark Seafile Josh alchemist.el Steve Architecture the Lost Years by Robert Martin

Добрый день уважаемые слушатели. Представляем новый выпуск подкаста RWpod. В этом выпуске: Ruby Ruby 2.5.0-rc1 Released, Getting Started with Metrics in Rails, Surprises with Nested Transactions, Rollbacks and ActiveRecord и Rust for Rubyists Ruby Is Hiding Errors From You!, Introducing sequel_tools: Rake integration over Sequel migrations and related tasks и Keisan - is a Ruby library for parsing equations into an abstract syntax tree JavaScript What's New With Server-Side Rendering in React 16, Netflix functions without client-side React, and it's a good thing и Being in control of font-display WebAssembly interpreter on JavaScript, Docusaurus - easy to maintain Open Source documentation websites, Specificity Visualizer - a visual way to analyze the specificity of selectors in CSS и Popmotion - functional JavaScript motion library

Tweet this Episode RR 325 Date Night with Ruby with Ruberto Paulo In this episode, panelists Dave Kimura, Eric Berry, and Charles Max Wood discuss ongoing learning and keeping your passion for programming alive with Ruberto Paulo. [01:16] Ruberto Paulo introduction and discussion on the South African and worldwide Ruby scene Rubyist from Cape Town, South Africa. Works for a fintech company in Cape Town. He's an organizer of RubyFuza and Ruby DCamp in South Africa. The Ruby scene in South Africa is growing as is fintech. His company's platform was build by Platform45 and is now maintained by his employer. Developers are also finding work in the wider world from the Cape Town area. Is Cape Town a big Rails area? or is there a big focus on other frameworks? It's a mix, but mostly Rails. Most of the people who live in Kenya spend 1/3 of their income charging their phones. M-pesa is their alternative to banks because they can't afford to have bank accounts. Every business in Africa has to have some kind of technology tie-in because of this. A lot of the developers in Ruby are Polyglots. They're people who have experimented with several languages in the past. Ruby is probably the highest paid language in South Africa. Dave Thomas spoke at RubyHACK conference that Elixir is the future. He's using Elixir for pretty much everything now. Elixir presents a viable option to move from for Rubyists. Several years ago, Ruby was hot. Now it's mature. Many corporations have invested in Ruby, so they're not going to adopt another stack. Most frameworks can solve most problems, so people only move when you're in the minority case where you need the capabilities of the new language. A lot of people stick around because they love the language and the community as well. What does Ruby give us that we want to take with us into the future? [19:10] Date Night with Ruby Ruberto is speaking at Ruby Dev Summit about Date Night with Ruby. More show notes in progress  

Tweet this Episode RR 325 Date Night with Ruby with Ruberto Paulo In this episode, panelists Dave Kimura, Eric Berry, and Charles Max Wood discuss ongoing learning and keeping your passion for programming alive with Ruberto Paulo. [01:16] Ruberto Paulo introduction and discussion on the South African and worldwide Ruby scene Rubyist from Cape Town, South Africa. Works for a fintech company in Cape Town. He's an organizer of RubyFuza and Ruby DCamp in South Africa. The Ruby scene in South Africa is growing as is fintech. His company's platform was build by Platform45 and is now maintained by his employer. Developers are also finding work in the wider world from the Cape Town area. Is Cape Town a big Rails area? or is there a big focus on other frameworks? It's a mix, but mostly Rails. Most of the people who live in Kenya spend 1/3 of their income charging their phones. M-pesa is their alternative to banks because they can't afford to have bank accounts. Every business in Africa has to have some kind of technology tie-in because of this. A lot of the developers in Ruby are Polyglots. They're people who have experimented with several languages in the past. Ruby is probably the highest paid language in South Africa. Dave Thomas spoke at RubyHACK conference that Elixir is the future. He's using Elixir for pretty much everything now. Elixir presents a viable option to move from for Rubyists. Several years ago, Ruby was hot. Now it's mature. Many corporations have invested in Ruby, so they're not going to adopt another stack. Most frameworks can solve most problems, so people only move when you're in the minority case where you need the capabilities of the new language. A lot of people stick around because they love the language and the community as well. What does Ruby give us that we want to take with us into the future? [19:10] Date Night with Ruby Ruberto is speaking at Ruby Dev Summit about Date Night with Ruby. More show notes in progress  

Tweet this Episode RR 325 Date Night with Ruby with Ruberto Paulo In this episode, panelists Dave Kimura, Eric Berry, and Charles Max Wood discuss ongoing learning and keeping your passion for programming alive with Ruberto Paulo. [01:16] Ruberto Paulo introduction and discussion on the South African and worldwide Ruby scene Rubyist from Cape Town, South Africa. Works for a fintech company in Cape Town. He's an organizer of RubyFuza and Ruby DCamp in South Africa. The Ruby scene in South Africa is growing as is fintech. His company's platform was build by Platform45 and is now maintained by his employer. Developers are also finding work in the wider world from the Cape Town area. Is Cape Town a big Rails area? or is there a big focus on other frameworks? It's a mix, but mostly Rails. Most of the people who live in Kenya spend 1/3 of their income charging their phones. M-pesa is their alternative to banks because they can't afford to have bank accounts. Every business in Africa has to have some kind of technology tie-in because of this. A lot of the developers in Ruby are Polyglots. They're people who have experimented with several languages in the past. Ruby is probably the highest paid language in South Africa. Dave Thomas spoke at RubyHACK conference that Elixir is the future. He's using Elixir for pretty much everything now. Elixir presents a viable option to move from for Rubyists. Several years ago, Ruby was hot. Now it's mature. Many corporations have invested in Ruby, so they're not going to adopt another stack. Most frameworks can solve most problems, so people only move when you're in the minority case where you need the capabilities of the new language. A lot of people stick around because they love the language and the community as well. What does Ruby give us that we want to take with us into the future? [19:10] Date Night with Ruby Ruberto is speaking at Ruby Dev Summit about Date Night with Ruby. More show notes in progress  

Merrin Macleoad from Rails Girls to talk about Kiwi Ruby about the upcoming conference she is organising.We go into what Ruby (est 1993) is and how it fits into the Dev world.Mike and Merrin also geek out on a few languages they learnt back in the day.Kiwi Ruby is about a mixture of local and international speakers, a day of workshops and one single-track day of talks. The will cover topics that interest, excite, and delight Rubyists and the Ruby-curious of all levels.It's being held on Thursday 2 November (workshops) and Friday 3 November (conference) at Te Papa on the Wellington waterfront.------------------------------------------------------We share New Zealand tech, social media, startup people's stories. If you have a story or know someone that does - get in touch!Mike’s (@MiramarMike) background is explaining stuff, connecting people and getting things done. Raj’s (@nzRaj) background is in video, design, media and making things happen.www.accessgranted.nzhttps://twitter.com/AccessGrantedNZhttps://www.facebook.com/AccessGrantedNZ

On today's episode, Brian Hogan, David Kimura, and Charles Max Wood discuss SQL Server for Rubyists with Carlos Chacon. Carlos is an SQL server enthusiast, managing partner of SQL Data Partners, and co-host of The SQL Data Partners Podcast. Tune in to know more what he is currently up to and how his SQL knowledge would help Rubyists!

On today's episode, Brian Hogan, David Kimura, and Charles Max Wood discuss SQL Server for Rubyists with Carlos Chacon. Carlos is an SQL server enthusiast, managing partner of SQL Data Partners, and co-host of The SQL Data Partners Podcast. Tune in to know more what he is currently up to and how his SQL knowledge would help Rubyists!

On today's episode, Brian Hogan, David Kimura, and Charles Max Wood discuss SQL Server for Rubyists with Carlos Chacon. Carlos is an SQL server enthusiast, managing partner of SQL Data Partners, and co-host of The SQL Data Partners Podcast. Tune in to know more what he is currently up to and how his SQL knowledge would help Rubyists!

Sometimes you start a conversation with one intention, and digress into something completely different. This happened to me recently, in a conversation with an old friend and mentor, Johnny Boursiquot. Johnny and I were supposed to do a deep dive into Go Lang and Ruby in this hour long conversation. Instead we spent half an hour talking about Johnny's experience building a technology agency from scratch. Then we got around to talking tech XD. Johnny is well-known as one of the pillars of BostonRB. He also helped to organize the Boston GoLang meetup before moving to Maryland where he founded Baltimore's GoLang Meetup. He was listed on New Relic's list of 18 Go Experts to Follow Online.  In the episode we talk about: Johnny’s lessons learned from founding and building a tech agency, lots of juicy business advice for consulting companies and agencies in the first half of this talk The relative pros and cons of using ruby vs go in different domains How to get started using a new language A quick primer in serverless application architectures How intermediate devs can 10x their workflow And a lot more Enjoy Notes [00:00] What brings Johnny to Maryland after living more than a decade in Boston What brought him to Boston in the first place [02:30] Major lessons learned from time in Boston running a technology company Running a company means that you’re responsible for other people’s income Many unexpected challenges: biz dev, legal, etc [05:15] How did Johnny get started in technology business. Started with entrepreneurship in high school [08:00] Learning how to do business Dealing with clients Managing expectation Touching on the difference between hacking and building a product [11:00] #1 Lesson? The difference between a service business and product business Agencies do not scale the same way a product scales Most agencies do not end up producing a lot of reusable technology or internal products It’s hard to do internal product development because your staff is busy with revenue generating service activities It’s risky to invest in product development [20:00] What would Johnny do differently if he could start over? Start a product company: raise money. [23:00] What about the reverse situation? Making a profitable, successful agency. Protect your margins Be flexible with workflow; Agile doesn’t always work smoothly in an agency environment “They want warez” Your job is to tease out the specifics of what the client actually wants “You’re not in control of your own product roadmap” [27:30] How to mitigate risk of scope creep Establish a relationship; a partnership to guarantee future work Get a Master Services Agreement [32:00] Segue to technical discussion. What is Ruby good for vs Golang? Ruby for developing something fast. “Getting a web app out there as fast as possible” GoLang is better for heavy lifting, whenever performance is a consideration [37:45] What are Johnny’s tips for learning Go (or any language) “Leave baggage at the door...appreciate the differences of Go” There is a “Go Way” of doing things [41:15] What kind of project should I try using GO in Anything with heavy duty network requirements Microservices (“Something you can throw away”) “Gnarly, performance-critical jobs” Concurrency in Go is super-awesome [45:00] AWS Lambda and Serverless 101 Not actually “serverless”. That’s a marketing term. There is always a server somewhere. Monolithic App > Microservices > Lambda functions Everything is a discrete functional unit Very cost-effective because the server only runs when you call the function [51:30] What can an intermediate Rails developer to 10-20x their workflow Look past the magic of the language (Ruby) or framework (Rails) Learn the underlying properties of the WYSIWYG Understand how SQL, HTTP, Databases, and CURL -- fundamentals of the web -- work Learning the underlying complexity enables you to use the higher-level abstractions more rapidly [59:00] Johnny’s relationship with the command line Used to work in Windows, and mostly everything was a GUI Put together command-line tools to build Flash experiences Started using Ubuntu - understood that there are discrete tools to use and stitch together from the command line Now uses a Mac. Everything can be done from the terminal [1:05:45] Running swift on the server Caffeine runs swift on the server to improve iOS network performance [1:07:00] Johnny’s new life hack Modified Pomodoro with a physical twist [1:10:00] Johnny’s child-rearing hacks Every child is different Reward effort over innate qualities Lots of people squander innate talent. Working hard never fails. [1:14:00] Johnny’s new job at an education non-profit Serving under-served school districts Exposing diverse groups to the world of technology Bring education equity to the communities that need it most Mostly doing ops work these days The biggest challenge is always dealing with people Johnny loves pairing with more junior members [1:20:00] Final requests to the audience and where to find Johnny @jboursiquot on Twitter Donate to the ACLU to protect the rights of individuals

Добрый день уважаемые слушатели. Представляем новый выпуск подкаста RWpod. В этом выпуске: Ruby ROM 3.0 Released, Benchmarking a Go AI in Ruby: CRuby vs. Rubinius vs. JRuby vs. Truffle – a year later и What makes Rails a framework worth learning in 2017? How To Add Active Admin to a Rails 5 API Application и Build your first Facebook Messenger bot in Ruby with Sinatra The Difference Between to_s & to_str In Ruby, Elixir for Rubyists и Random Ruby Tips and Tricks JavaScript Announcing Ionic 2.0.0 Final, ES proposal: Shared memory and atomics и Making Responsive HTML Email Coding Easy With MJML Introduction to WebAssembly, Angular in Production и The end of the clearfix hack? Swarm-numberformat - format large numbers in several human-readable ways, Tilt.js - tiny requestAnimationFrame powered 60+fps и QArt.js - generate artistic QR code

Check out JS Remote Conf and All Remote Confs!   02:32 - Brad Urani Introduction Twitter GitHub Blog Procore 04:01 - Immutable/Persistent Data Structures; Advantages Changing the Unchangeable: The Hows and Whys of Immutable Data Structures @ RubyConf 2015 hamster 07:30 - Tools for Debugging 08:23 - Why do Rubyists care about things like Elm? 09:39 - Persistent Data Structure Use Cases; Functional Programming 12:07 - Testability 13:51 - Where does “functional play a role in a typical CRUD app? Active Record, The Single Responsibility Principle (SRP) Callbacks Object-oriented Programming (OOP) “Nouns are objects; verbs are methods” - Corey Haines 22:49 - Coworker Receptiveness of Ruby + JavaScript Style of Programming Codebase Inconsistency? “Merit” 26:41 - Service-oriented Architecture (SOA) vs Monolithic Applications Remote Procedure Calls (RPC) Representational State Transfer (REST) 30:21 - Monoliths as a Necessary Stage in the Development of a Mature Application Elixir The Phoenix Framework ecto 33:23 - The Repository Pattern; Terminology & Naming Patterns of Enterprise Application Architecture by Martin Fowler 37:40 - Structured Query Language (SQL) Avdi Grimm: The Soul of Software @ RubyConf Portugal '15 The Sapir Whorf Hypothesis' Picks Dan Carlin's Hardcore History (Coraline) Stuff You Missed in History Class (Coraline) Buffer (Avdi) New Belgium Brewing Accumulation White IPA (Avdi) Saramonic SmartMixer Professional Recording Stereo Microphone Rig (Chuck) LaunchCode (Brad) Turing's Cathedral: The Origins of the Digital Universe by George Dyson (Coraline) VAT19 (Brad)

Check out JS Remote Conf and All Remote Confs!   02:32 - Brad Urani Introduction Twitter GitHub Blog Procore 04:01 - Immutable/Persistent Data Structures; Advantages Changing the Unchangeable: The Hows and Whys of Immutable Data Structures @ RubyConf 2015 hamster 07:30 - Tools for Debugging 08:23 - Why do Rubyists care about things like Elm? 09:39 - Persistent Data Structure Use Cases; Functional Programming 12:07 - Testability 13:51 - Where does “functional play a role in a typical CRUD app? Active Record, The Single Responsibility Principle (SRP) Callbacks Object-oriented Programming (OOP) “Nouns are objects; verbs are methods” - Corey Haines 22:49 - Coworker Receptiveness of Ruby + JavaScript Style of Programming Codebase Inconsistency? “Merit” 26:41 - Service-oriented Architecture (SOA) vs Monolithic Applications Remote Procedure Calls (RPC) Representational State Transfer (REST) 30:21 - Monoliths as a Necessary Stage in the Development of a Mature Application Elixir The Phoenix Framework ecto 33:23 - The Repository Pattern; Terminology & Naming Patterns of Enterprise Application Architecture by Martin Fowler 37:40 - Structured Query Language (SQL) Avdi Grimm: The Soul of Software @ RubyConf Portugal '15 The Sapir Whorf Hypothesis' Picks Dan Carlin's Hardcore History (Coraline) Stuff You Missed in History Class (Coraline) Buffer (Avdi) New Belgium Brewing Accumulation White IPA (Avdi) Saramonic SmartMixer Professional Recording Stereo Microphone Rig (Chuck) LaunchCode (Brad) Turing's Cathedral: The Origins of the Digital Universe by George Dyson (Coraline) VAT19 (Brad)

Check out JS Remote Conf and All Remote Confs!   02:32 - Brad Urani Introduction Twitter GitHub Blog Procore 04:01 - Immutable/Persistent Data Structures; Advantages Changing the Unchangeable: The Hows and Whys of Immutable Data Structures @ RubyConf 2015 hamster 07:30 - Tools for Debugging 08:23 - Why do Rubyists care about things like Elm? 09:39 - Persistent Data Structure Use Cases; Functional Programming 12:07 - Testability 13:51 - Where does “functional play a role in a typical CRUD app? Active Record, The Single Responsibility Principle (SRP) Callbacks Object-oriented Programming (OOP) “Nouns are objects; verbs are methods” - Corey Haines 22:49 - Coworker Receptiveness of Ruby + JavaScript Style of Programming Codebase Inconsistency? “Merit” 26:41 - Service-oriented Architecture (SOA) vs Monolithic Applications Remote Procedure Calls (RPC) Representational State Transfer (REST) 30:21 - Monoliths as a Necessary Stage in the Development of a Mature Application Elixir The Phoenix Framework ecto 33:23 - The Repository Pattern; Terminology & Naming Patterns of Enterprise Application Architecture by Martin Fowler 37:40 - Structured Query Language (SQL) Avdi Grimm: The Soul of Software @ RubyConf Portugal '15 The Sapir Whorf Hypothesis' Picks Dan Carlin's Hardcore History (Coraline) Stuff You Missed in History Class (Coraline) Buffer (Avdi) New Belgium Brewing Accumulation White IPA (Avdi) Saramonic SmartMixer Professional Recording Stereo Microphone Rig (Chuck) LaunchCode (Brad) Turing's Cathedral: The Origins of the Digital Universe by George Dyson (Coraline) VAT19 (Brad)

Rubyists are famously polyglot. I've heard people joke that there are more JavaScript talks at some Ruby conferences than there are Ruby talks. But there's one area in which most Rubyists don't go: low-level programming. We often say "Ruby is slow, but that doesn't matter. I'll just drop down to C when I need performance." But C is pretty scary, so we never actually do it.   In this talk, Steve will show off Rust, a new programming language from Mozilla. Steve will show you how that saying should change: "drop down to Rust," and why it's better for Rubyists than C.

Rubyists are famously polyglot. I've heard people joke that there are more JavaScript talks at some Ruby conferences than there are Ruby talks. But there's one area in which most Rubyists don't go: low-level programming. We often say "Ruby is slow, but that doesn't matter. I'll just drop down to C when I need performance." But C is pretty scary, so we never actually do it.   In this talk, Steve will show off Rust, a new programming language from Mozilla. Steve will show you how that saying should change: "drop down to Rust," and why it's better for Rubyists than C.

Rubyists are famously polyglot. I've heard people joke that there are more JavaScript talks at some Ruby conferences than there are Ruby talks. But there's one area in which most Rubyists don't go: low-level programming. We often say "Ruby is slow, but that doesn't matter. I'll just drop down to C when I need performance." But C is pretty scary, so we never actually do it.   In this talk, Steve will show off Rust, a new programming language from Mozilla. Steve will show you how that saying should change: "drop down to Rust," and why it's better for Rubyists than C.

Rubyists are famously polyglot. I've heard people joke that there are more JavaScript talks at some Ruby conferences than there are Ruby talks. But there's one area in which most Rubyists don't go: low-level programming. We often say "Ruby is slow, but that doesn't matter. I'll just drop down to C when I need performance." But C is pretty scary, so we never actually do it.   In this talk, Steve will show off Rust, a new programming language from Mozilla. Steve will show you how that saying should change: "drop down to Rust," and why it's better for Rubyists than C.

Rubyists are famously polyglot. I've heard people joke that there are more JavaScript talks at some Ruby conferences than there are Ruby talks. But there's one area in which most Rubyists don't go: low-level programming. We often say "Ruby is slow, but that doesn't matter. I'll just drop down to C when I need performance." But C is pretty scary, so we never actually do it.   In this talk, Steve will show off Rust, a new programming language from Mozilla. Steve will show you how that saying should change: "drop down to Rust," and why it's better for Rubyists than C.

Rob and Jason are joined by Steve Klabnik to discuss the history of the Rust language and some of its key features.   Steve Klabnik is a Ruby and Rails contributor, member of the Rust core team, and a hypermedia enthusiast. He's the author of "Rust for Rubyists," "Rails 4 in Action," and "Designing Hypermedia APIs."   When Steve isn't coding, he enjoys playing the Netrunner card game. News Get rid of those boolean function parameters Concepts TS voted out (in) Steve Klabnik @steveklabnik Steve Klabnik's Home Page Steve Klabnik's GitHub Links The Rust Programming Language  

02:52 - David Herman Introduction Twitter Blog JavaScript Jabber Episode #54: JavaScript Parsing, ASTs, and Language Grammar w/ David Herman and Ariya Hidayat JavaScript Jabber Episode #44: Book Club! Effective JavaScript with David Herman Effective JavaScript by David Herman @effectivejs TC39 Mozilla 03:50 - The Rust Programming Language [GitHub] rust 06:31 - “Systems Programming Without Fear” 07:38 - High vs Low-level Programming Languages Garbage Collection and Deallocation Memory Safety Performance and Control Over Performance 11:44 - Stack vs Heap Memory Etymology of "Foo" RAII (Resource Acquisition Is Initialization) 16:52 - The Core of Rust Ownership Type System 24:23 - Segmentation Fault (Seg Faults) 27:51 - How much should programmers care about programming languages? Andrew Oppenlander: Rust FFI (Embedding Rust in projects for safe, concurrent, and fast code anywhere.) 32:43 - Concurrency and Multithreaded Programming 35:06 - Rust vs Go 37:58 - servo 40:27 - asm.js emscripten 42:19 - Cool Apps Built with Rust Skylight Wit.ai 45:04 - What hardware architectures does the Rust target? 45:46 - Learning Rust Rust for Rubyists by Steve Klabnik Picks Software Engineering Radio (Dave) How Will You Measure Your Life? by Clayton M. Christensen (Dave) The Presidents of the United States of America (Dave) Design Patterns in C (AJ) Microsoft Edge Dev Blog: Bringing Asm.js to Chakra and Microsoft Edge (AJ) The Web Platform Podcast: Episode 43: Modern JavaScript with ES6 & ES7 (AJ) Firefox Fame Phone (AJ) iTunes U CS106A (Programming Methodology) (Aimee) Valerian Root on Etsy (Aimee) The Dear Hunter - Live (Jamison) Designing Data-Intensive Applications by Martin Kleppmann (Jamison) Fogus: Perlis Languages (Jamison) Galactic Civilizations III (Joe) Visual Studio Code (Joe) Tessel 2 (Dave) Event Driven: How to Run Memorable Tech Conferences by Leah Silber (Dave) Plush Hello Kitty Doll (Dave)

02:32 - Julian Cheal Introduction Twitter GitHub Blog 02:49 - Julian’s Background with Robots and Drones Arduino AR.Drone 03:32 - NodeCopter Events 04:31 - Traveling with Robots 05:35 - Julian’s Collection and Projects Julian Cheal: Dancing with Robots Raspberry Pi BeagleBone 07:46 - Giving Demos 09:12 - What Makes Robots? Sinon.JS MQTT Protocol 10:21 - Where is IoT (Internet of Things) Heading? Security 13:11 - Programming Languages NodeBots 14:15 - Tools and Protocols The MIDI Protocol Spark Core voodoospark 17:31 - Programming Challenges Around Hardware Hacking Artoo celluloid 18:49 - Barrier to Entry 20:41 - Getting Kids Started Kids Ruby Arduino Starter Kit 22:09 - Wearables EL Wire (Electroluminescent Wire) 23:18 - LEGO Robotics Mindstorms LabVIEW National Instruments 25:01 - Issues with Hardware Hacking 28:22 - Rubyists and Hardware Julian Cheal: Dancing with Robots JRuby Rubinius 29:45 - Interfacing with Humans iBeacon OpenCV 33:27 - [Kickstarter] CHIP - The World's First Nine Dollar Computer 34:01 - Connectivity  Sphero Carin Meier: The Joy of Flying Robots with Clojure @ OSCON 2013 36:55 - More Interesting Projects Aaron Patterson: Using chicken scheme to read sausagebox values Oscilloscope Picks Jacob Kaplan-Moss Keynote @ Pycon 2015 (Jessica) Kobo Aura H20 (Avdi) Liz Abinante: Unicorns Are People, Too (Re-Thinking Soft and Hard Skills) @ Madison+ Ruby 2014 (Coraline) littleBits (Julian) Jewelbots (Julian) Ruby Rogues Episode #156: Hardware Hacking with Julia Grace (Julian) The End of Mr. Y by Scarlett Thomas (Julian)        

02:52 - David Herman Introduction Twitter Blog JavaScript Jabber Episode #54: JavaScript Parsing, ASTs, and Language Grammar w/ David Herman and Ariya Hidayat JavaScript Jabber Episode #44: Book Club! Effective JavaScript with David Herman Effective JavaScript by David Herman @effectivejs TC39 Mozilla 03:50 - The Rust Programming Language [GitHub] rust 06:31 - “Systems Programming Without Fear” 07:38 - High vs Low-level Programming Languages Garbage Collection and Deallocation Memory Safety Performance and Control Over Performance 11:44 - Stack vs Heap Memory Etymology of "Foo" RAII (Resource Acquisition Is Initialization) 16:52 - The Core of Rust Ownership Type System 24:23 - Segmentation Fault (Seg Faults) 27:51 - How much should programmers care about programming languages? Andrew Oppenlander: Rust FFI (Embedding Rust in projects for safe, concurrent, and fast code anywhere.) 32:43 - Concurrency and Multithreaded Programming 35:06 - Rust vs Go 37:58 - servo 40:27 - asm.js emscripten 42:19 - Cool Apps Built with Rust Skylight Wit.ai 45:04 - What hardware architectures does the Rust target? 45:46 - Learning Rust Rust for Rubyists by Steve Klabnik Picks Software Engineering Radio (Dave) How Will You Measure Your Life? by Clayton M. Christensen (Dave) The Presidents of the United States of America (Dave) Design Patterns in C (AJ) Microsoft Edge Dev Blog: Bringing Asm.js to Chakra and Microsoft Edge (AJ) The Web Platform Podcast: Episode 43: Modern JavaScript with ES6 & ES7 (AJ) Firefox Fame Phone (AJ) iTunes U CS106A (Programming Methodology) (Aimee) Valerian Root on Etsy (Aimee) The Dear Hunter - Live (Jamison) Designing Data-Intensive Applications by Martin Kleppmann (Jamison) Fogus: Perlis Languages (Jamison) Galactic Civilizations III (Joe) Visual Studio Code (Joe) Tessel 2 (Dave) Event Driven: How to Run Memorable Tech Conferences by Leah Silber (Dave) Plush Hello Kitty Doll (Dave)

02:32 - Julian Cheal Introduction Twitter GitHub Blog 02:49 - Julian’s Background with Robots and Drones Arduino AR.Drone 03:32 - NodeCopter Events 04:31 - Traveling with Robots 05:35 - Julian’s Collection and Projects Julian Cheal: Dancing with Robots Raspberry Pi BeagleBone 07:46 - Giving Demos 09:12 - What Makes Robots? Sinon.JS MQTT Protocol 10:21 - Where is IoT (Internet of Things) Heading? Security 13:11 - Programming Languages NodeBots 14:15 - Tools and Protocols The MIDI Protocol Spark Core voodoospark 17:31 - Programming Challenges Around Hardware Hacking Artoo celluloid 18:49 - Barrier to Entry 20:41 - Getting Kids Started Kids Ruby Arduino Starter Kit 22:09 - Wearables EL Wire (Electroluminescent Wire) 23:18 - LEGO Robotics Mindstorms LabVIEW National Instruments 25:01 - Issues with Hardware Hacking 28:22 - Rubyists and Hardware Julian Cheal: Dancing with Robots JRuby Rubinius 29:45 - Interfacing with Humans iBeacon OpenCV 33:27 - [Kickstarter] CHIP - The World's First Nine Dollar Computer 34:01 - Connectivity  Sphero Carin Meier: The Joy of Flying Robots with Clojure @ OSCON 2013 36:55 - More Interesting Projects Aaron Patterson: Using chicken scheme to read sausagebox values Oscilloscope Picks Jacob Kaplan-Moss Keynote @ Pycon 2015 (Jessica) Kobo Aura H20 (Avdi) Liz Abinante: Unicorns Are People, Too (Re-Thinking Soft and Hard Skills) @ Madison+ Ruby 2014 (Coraline) littleBits (Julian) Jewelbots (Julian) Ruby Rogues Episode #156: Hardware Hacking with Julia Grace (Julian) The End of Mr. Y by Scarlett Thomas (Julian)        

02:32 - Julian Cheal Introduction Twitter GitHub Blog 02:49 - Julian’s Background with Robots and Drones Arduino AR.Drone 03:32 - NodeCopter Events 04:31 - Traveling with Robots 05:35 - Julian’s Collection and Projects Julian Cheal: Dancing with Robots Raspberry Pi BeagleBone 07:46 - Giving Demos 09:12 - What Makes Robots? Sinon.JS MQTT Protocol 10:21 - Where is IoT (Internet of Things) Heading? Security 13:11 - Programming Languages NodeBots 14:15 - Tools and Protocols The MIDI Protocol Spark Core voodoospark 17:31 - Programming Challenges Around Hardware Hacking Artoo celluloid 18:49 - Barrier to Entry 20:41 - Getting Kids Started Kids Ruby Arduino Starter Kit 22:09 - Wearables EL Wire (Electroluminescent Wire) 23:18 - LEGO Robotics Mindstorms LabVIEW National Instruments 25:01 - Issues with Hardware Hacking 28:22 - Rubyists and Hardware Julian Cheal: Dancing with Robots JRuby Rubinius 29:45 - Interfacing with Humans iBeacon OpenCV 33:27 - [Kickstarter] CHIP - The World's First Nine Dollar Computer 34:01 - Connectivity  Sphero Carin Meier: The Joy of Flying Robots with Clojure @ OSCON 2013 36:55 - More Interesting Projects Aaron Patterson: Using chicken scheme to read sausagebox values Oscilloscope Picks Jacob Kaplan-Moss Keynote @ Pycon 2015 (Jessica) Kobo Aura H20 (Avdi) Liz Abinante: Unicorns Are People, Too (Re-Thinking Soft and Hard Skills) @ Madison+ Ruby 2014 (Coraline) littleBits (Julian) Jewelbots (Julian) Ruby Rogues Episode #156: Hardware Hacking with Julia Grace (Julian) The End of Mr. Y by Scarlett Thomas (Julian)        

02:52 - David Herman Introduction Twitter Blog JavaScript Jabber Episode #54: JavaScript Parsing, ASTs, and Language Grammar w/ David Herman and Ariya Hidayat JavaScript Jabber Episode #44: Book Club! Effective JavaScript with David Herman Effective JavaScript by David Herman @effectivejs TC39 Mozilla 03:50 - The Rust Programming Language [GitHub] rust 06:31 - “Systems Programming Without Fear” 07:38 - High vs Low-level Programming Languages Garbage Collection and Deallocation Memory Safety Performance and Control Over Performance 11:44 - Stack vs Heap Memory Etymology of "Foo" RAII (Resource Acquisition Is Initialization) 16:52 - The Core of Rust Ownership Type System 24:23 - Segmentation Fault (Seg Faults) 27:51 - How much should programmers care about programming languages? Andrew Oppenlander: Rust FFI (Embedding Rust in projects for safe, concurrent, and fast code anywhere.) 32:43 - Concurrency and Multithreaded Programming 35:06 - Rust vs Go 37:58 - servo 40:27 - asm.js emscripten 42:19 - Cool Apps Built with Rust Skylight Wit.ai 45:04 - What hardware architectures does the Rust target? 45:46 - Learning Rust Rust for Rubyists by Steve Klabnik Picks Software Engineering Radio (Dave) How Will You Measure Your Life? by Clayton M. Christensen (Dave) The Presidents of the United States of America (Dave) Design Patterns in C (AJ) Microsoft Edge Dev Blog: Bringing Asm.js to Chakra and Microsoft Edge (AJ) The Web Platform Podcast: Episode 43: Modern JavaScript with ES6 & ES7 (AJ) Firefox Fame Phone (AJ) iTunes U CS106A (Programming Methodology) (Aimee) Valerian Root on Etsy (Aimee) The Dear Hunter - Live (Jamison) Designing Data-Intensive Applications by Martin Kleppmann (Jamison) Fogus: Perlis Languages (Jamison) Galactic Civilizations III (Joe) Visual Studio Code (Joe) Tessel 2 (Dave) Event Driven: How to Run Memorable Tech Conferences by Leah Silber (Dave) Plush Hello Kitty Doll (Dave)

Chase and Jon discuss Ember's new versioned guides, testing in Ember CLI, and an Ember dependency guide for Rubyists.

This is Episode #1 featuring live interviews from RubyNation 2014,  a regional Ruby Conference in Silver Springs, MD. It showcases the importance of building meaningful digital experiences,  development culture & community, & the value sharing knowledge.

Welcome to the first ever LRUG podcast! At the March meeting Chris Parsons from Eden Development and Software Journeyman Corey Haines gave talks on software craftsmanship, what it means to Rubyists and how to continuously improve in your craft. After their talks (videos available from our meeting hosts Skills Matter), Chris Lowis sat down with Corey and Chris to find out what it means to be a Software Craftsman. Thanks to Skills Matter for providing the space for the talks and the recording of the interview