Podcasts about rubyist

In this episode, I'm joined by Victor Shepelev, a member of the Ruby Core team and the author of Ruby's new Data class. We dive into why Ruby needed the Data class, exploring how it fits into the language and enhances Ruby's capabilities. Victor also shares insights on some other exciting Ruby features, including Numbered Block Parameters, the "it" keyword, and the growing role of functional programming in Ruby.Beyond coding, Victor has a unique perspective as he's officially enlisted in the Ukrainian Army. I had the chance to talk with him about what it's like to balance life as a Rubyist and a soldier, and we discuss meaningful ways to support him and Ukraine.Try Mailtrap for freeRuby Data ClassRuby ChangesSupport UkraineUseless syntax sugar”: Numeric block parameters

What does it take to build a modern, distraction-free forum platform that fosters deep community engagement? Join us as we welcome back Jeremy Smith, a seasoned Rails developer and consultant, who shares his journey of creating Liminal, an innovative platform inspired by conversations at RailsConf. Jeremy's insights offer a unique look into his work under Hybrid Studio, his passion for Ruby and Rails projects, and his latest ventures, including organizing Blue Ridge Ruby and co-hosting the Indie Rails podcast. Don't miss out on his practical advice for developers and creators looking to build meaningful online communities.Launching a new product is never easy, and Jeremy opens up about the challenges he faced with Liminal. From focusing on core features to attract users to overcoming common roadblocks like gaining traction and effective marketing, Jeremy shares valuable lessons learned through personal anecdotes. He discusses the importance of communication and storytelling in successful product development, reflecting on why his similar project, Fractional, didn't take off while Joe Mazzolotti's RailsDevs.com flourished. Jeremy's journey into building a fractional services platform highlights the critical role of targeting a niche audience and marketing effectively.Finally, we delve into the future of video content creation with tools like Riverside. Jeremy highlights the efficiency of its AI tools for creating and editing video content, making quick weekly releases a breeze. This episode also explores the joy of building niche events like Blue Ridge and Ruby on Trails, where Jeremy hones his skills in promoting and engaging with the Rubyist community. Tune in for a wealth of practical advice, personal stories, and insightful discussions that will leave you inspired to take your own projects to the next level.Send us some love.HoneybadgerHoneybadger is an application health monitoring tool built by developers for developers.HoneybadgerHoneybadger is an application health monitoring tool built by developers for developers.Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.Support the showReady to start your own podcast?This show is hosted on Buzzsprout and it's awesome, not to mention a Ruby on Rails application. Let Buzzsprout know we sent you and you'll get a $20 Amazon gift card if you sign up for a paid plan, and it helps support our show.

Landon Gray is a Rubyist, speaker, strategic advisor, and AI engineer. In May, he left Test Double to found Identus Consulting, where he helps companies with generative AI and machine learning. We chat about his love for consulting, how he got into AI, and how he's working with clients these days, using a blend of technical and project management skills. Follow LandonTwitterLinkedInRuby AI TwitterIdentus ConsultingCurious CentroidForecasting the future: Intro to Machine Learning for weather prediction in Native RubyRelevant LinksTest DoubleGreat LearningClaudeJeremy HowardTorch.rbTransformers.rbPandasJupyter

Andy Croll is a Rubyist, author, and speaker. He's the CTO of CoverageBook, creator of the First Ruby Friend mentoring program, organizer of Brighton Ruby, and this year is co-chair of RailsConf. In short, he's a bit busy. In our conversation, we dive into his work at CoverageBook, discuss the hiring, onboarding, and mentoring of early career devs, and talk Ruby conferences (and why you should go).Relevant LinksTwitterWebsiteWhy go to a Ruby or Rails conference?One Ruby ThingFirst Ruby FriendBrighton RubyRailsConfCoverageBook

Sara is a team lead at thoughtbot. She talks about her experience as a professor at Kanazawa Technical College, giant LAN parties in Rochester, transitioning from Java to Ruby, shining a light on maintainers, and her closing thoughts on RubyConf. Recorded at RubyConf 2023 in San Diego. -- A few topics covered: Being an Assistant Arofessor in Kanazawa Teaching naming, formatting, and style Differences between students in Japan vs US Technical terms and programming resources in Japanese LAN parties at Rochester Transitioning from Java to Ruby Consulting The forgotten maintainer RubyConf Other links Sara's mastodon thoughtbot This Week in Open Source testdouble Ruby Central Scholars and Guides Program City Museum Japan International College of Technology Kanazawa RubyKaigi Applying mruby to World-first Small SAR Satellite (Japanese lightning talk) (mruby in space) Rochester Rochester Institute of Technology Electronic Gaming Society Tora-con Strong National Museum of Play Transcript You can help correct transcripts on GitHub. [00:00:00] Jeremy: I'm here at RubyConf, San Diego, with Sara Jackson, thank you for joining me today. [00:00:05] Sara: Thank you for having me. Happy to be here. [00:00:07] Jeremy: Sara right now you're working at, ThoughtBot, as a, as a Ruby developer, is that right? [00:00:12] Sara: Yes, that is correct. Teaching in Japan [00:00:14] Jeremy: But I think before we kind of talk about that, I mean, we're at a Ruby conference, but something that I, I saw, on your LinkedIn that I thought was really interesting was that you were teaching, I think, programming in. Kanazawa, for a couple years. [00:00:26] Sara: Yeah, that's right. So for those that don't know, Kanazawa is a city on the west coast of Japan. If you draw kind of a horizontal line across Japan from Tokyo, it's, it's pretty much right there on the west coast. I was an associate professor in the Global Information and Management major, which is basically computer science or software development. (laughs) Yep. [00:00:55] Jeremy: Couldn't tell from the title. [00:00:56] Sara: You couldn't. No.. so there I was teaching classes for a bunch of different languages and concepts from Java to Python to Unix and Bash scripting, just kind of all over. [00:01:16] Jeremy: And did you plan the curriculum yourself, or did they have anything for you? [00:01:21] Sara: It depended on the class that I was teaching. So some of them, I was the head teacher. In that case, I would be planning the class myself, the... lectures the assignments and grading them, et cetera. if I was assisting on a class, then usually it would, I would be doing grading and then helping in the class. Most of the classes were, uh, started with a lecture and then. Followed up with a lab immediately after, in person. [00:01:54] Jeremy: And I think you went to, is it University of Rochester? [00:01:58] Sara: Uh, close. Uh, Rochester Institute of Technology. So, same city. Yeah. [00:02:03] Jeremy: And so, you were studying computer science there, is that right? [00:02:07] Sara: I, I studied computer science there, but I got a minor in Japanese language. and that's how, that's kind of my origin story of then teaching in Kanazawa. Because Rochester is actually the sister city with Kanazawa. And RIT has a study abroad program for Japanese learning students to go study at KIT, Kanazawa Institute of Technology, in Kanazawa, do a six week kind of immersive program. And KIT just so happens to be under the same board as the school that I went to teach at. [00:02:46] Jeremy: it's great that you can make that connection and get that opportunity, yeah. [00:02:49] Sara: Absolutely. Networking! [00:02:52] Jeremy: And so, like, as a student in Rochester, you got to see how, I suppose, computer science education was there. How did that compare when you went over to Kanazawa? [00:03:02] Sara: I had a lot of freedom with my curriculum, so I was able to actually lean on some of the things that I learned, some of the, the way that the courses were structured that I took, I remember as a freshman in 2006, one of the first courses that we took, involved, learning Unix, learning the command line, things like that. I was able to look up some of the assignments and some of the information from that course that I took to inform then my curriculum for my course, [00:03:36] Jeremy: That's awesome. Yeah. and I guess you probably also remember how you felt as a student, so you know like what worked and maybe what didn't. [00:03:43] Sara: Absolutely. And I was able to lean on that experience as well as knowing. What's important and what, as a student, I didn't think was important. Naming, formatting, and style [00:03:56] Jeremy: So what were some examples of things that were important and some that weren't? [00:04:01] Sara: Mm hmm. For Java in particular, you don't need any white space between any of your characters, but formatting and following the general Guidelines of style makes your code so much easier to read. It's one of those things that you kind of have to drill into your head through muscle memory. And I also tried to pass that on to my students, in their assignments that it's. It's not just to make it look pretty. It's not just because I'm a mean teacher. It is truly valuable for future developers that will end up reading your code. [00:04:39] Jeremy: Yeah, I remember when I went through school. The intro professor, they would actually, they would print out our code and they would mark it up with red pen, basically like a writing assignment and it would be like a bad variable name and like, white space shouldn't be here, stuff like that. And, it seems kind of funny now, but, it actually makes it makes a lot of sense. [00:04:59] Sara: I did that. [00:04:59] Jeremy: Oh, nice. [00:05:00] Sara: I did that for my students. They were not happy about it. (laughs) [00:05:04] Jeremy: Yeah, at that time they're like, why are you like being so picky, right? [00:05:08] Sara: Exactly. But I, I think back to my student, my experience as a student. in some of the classes I've taken, not even necessarily computer related, the teachers that were the sticklers, those lessons stuck the most for me. I hated it at the time. I learned a lot. [00:05:26] Jeremy: Yeah, yeah. so I guess that's an example of things that, that, that matter. The, the aesthetics or the visual part for understanding. What are some things that they were teaching that you thought like, Oh, maybe this isn't so important. [00:05:40] Sara: Hmm. Pause for effect. (laughs) So I think that there wasn't necessarily Any particular class or topic that I didn't feel was as valuable, but there was some things that I thought were valuable that weren't emphasized very well. One of the things that I feel very strongly about, and I'm sure those of you out there can agree. in RubyWorld, that naming is important. The naming of your variables is valuable. It's useful to have something that's understood. and there were some other teachers that I worked with that didn't care so much in their assignments. And maybe the labs that they assigned had less than useful names for things. And that was kind of a disappointment for me. [00:06:34] Jeremy: Yeah, because I think it's maybe hard to teach, a student because a lot of times you are writing these short term assignments and you have it pass the test or do the thing and then you never look at it again. [00:06:49] Sara: Exactly. [00:06:50] Jeremy: So you don't, you don't feel that pain. Yeah, [00:06:53] Sara: Mm hmm. But it's like when you're learning a new spoken language, getting the foundations correct is super valuable. [00:07:05] Jeremy: Absolutely. Yeah. And so I guess when you were teaching in Kanazawa, was there anything you did in particular to emphasize, you know, these names really matter because otherwise you or other people are not going to understand what you were trying to do here? [00:07:22] Sara: Mm hmm. When I would walk around class during labs, kind of peek over the shoulders of my students, look at what they're doing, it's... Easy to maybe point out at something and be like, well, what is this? I can't tell what this is doing. Can you tell me what this does? Well, maybe that's a better name because somebody else who was looking at this, they won't know, I don't know, you know, it's in your head, but you will not always be working solo. my school, a big portion of the students went on to get technical jobs from after right after graduating. it was when you graduated from the school that I was teaching at, KTC, it was the equivalent of an associate's degree. Maybe 50 percent went off to a tech job. Maybe 50 percent went on to a four year university. And, and so as students, it hadn't. Connected with them always yet that oh, this isn't just about the assignment. This is also about learning how to interact with my co workers in the future. Differences between students [00:08:38] Jeremy: Yeah, I mean, I think It's hard, but, group projects are kind of always, uh, that's kind of where you get to work with other people and, read other people's code, but there's always that potential imbalance of where one person is like, uh, I know how to do this. I'll just do it. Right? So I'm not really sure how to solve that problem. Yeah. [00:09:00] Sara: Mm hmm. That's something that I think probably happens to some degree everywhere, but man, Japan really has groups, group work down. They, that's a super generalization. For my students though, when you would put them in a group, they were, they were usually really organized about who was going to do what and, kept on each other about doing things maybe there were some students that were a little bit more slackers, but it was certainly not the kind of polarized dichotomy you would usually see in an American classroom. [00:09:39] Jeremy: Yeah. I've been on both sides. I've been the person who did the work and the slacker. [00:09:44] Sara: Same. [00:09:46] Jeremy: And, uh, I feel bad about it now, but, uh, [00:09:50] Sara: We did what we had to do. [00:09:52] Jeremy: We all got the degree, so we're good. that is interesting, though. I mean, was there anything else, like, culturally different, you felt, from, you know, the Japanese university? [00:10:04] Sara: Yes. Absolutely. A lot of things. In American university, it's kind of the first time in a young person's life, usually, where they have the freedom to choose what they learn, choose where they live, what they're interested in. And so there's usually a lot of investment in your study and being there, being present, paying attention to the lecture. This is not to say that Japanese college students were the opposite. But the cultural feeling is college is your last time to have fun before you enter the real world of jobs and working too many hours. And so the emphasis on paying Super attention or, being perfect in your assignments. There was, there was a scale. There were some students that were 100 percent there. And then there were some students that were like, I'm here to get a degree and maybe I'm going to sleep in class a little bit. (laughs) That is another major difference, cultural aspect. In America, if you fall asleep in a meeting, you fall asleep in class, super rude. Don't do it. In Japan, if you take a nap at work, you take a nap in class, not rude. It's actually viewed as a sign of you are working really hard. You're usually working maybe late into the night. You're not getting enough sleep. So the fact that you need to take maybe a nap here or two here or there throughout the day means that you have put dedication in. [00:11:50] Jeremy: Even if the reason you're asleep is because you were playing games late at night. [00:11:54] Sara: Yep. [00:11:55] Jeremy: But they don't know that. [00:11:56] Sara: Yeah. But it's usually the case for my students. [00:11:59] Jeremy: Okay. I'm glad they were having fun at least [00:12:02] Sara: Me too. Why she moved back [00:12:04] Jeremy: That sounds like a really interesting experience. You did it for about two years? Three years. [00:12:12] Sara: So I had a three year contract with an option to extend up to five, although I did have a There were other teachers in my same situation who were actually there for like 10 years, so it was flexible. [00:12:27] Jeremy: Yeah. So I guess when you made the decision to, to leave, what was sort of your, your thinking there? [00:12:35] Sara: My fiance was in America [00:12:37] Jeremy: Good. [00:12:37] Sara: he didn't want to move to Japan [00:12:39] Jeremy: Good, reason. [00:12:39] Sara: Yeah, he was waiting three years patiently for me. [00:12:44] Jeremy: Okay. Okay. my heart goes out there . He waited patiently. [00:12:49] Sara: We saw each other. We, we were very lucky enough to see each other every three or four months in person. Either I would visit America or he would come visit me in Kanazawa. [00:12:59] Jeremy: Yeah, yeah. You, you couldn't convince him to, to fall in love with the country. [00:13:03] Sara: I'm getting there [00:13:04] Jeremy: Oh, you're getting Oh, [00:13:05] Sara: it's, We're making, we're making way. [00:13:07] Jeremy: Good, that's good. So are you taking like, like yearly trips or something, or? [00:13:11] Sara: That was, that was always my intention when I moved back so I moved back in the Spring of 2018 to America and I did visit. In 2019, the following year, so I could attend the graduation ceremony for the last group of students that I taught. [00:13:26] Jeremy: That's so sweet. [00:13:27] Sara: And then I had plans to go in 2020. We know what happened in 2020 [00:13:32] Jeremy: Yeah. [00:13:33] Sara: The country did not open to tourism again until the fall of 2022. But I did just make a trip last month. [00:13:40] Jeremy: Nice [00:13:40] Sara: To see some really good friends for the first time in four years. [00:13:43] Jeremy: Amazing, yeah. Where did you go? [00:13:46] Sara: I did a few days in Tokyo. I did a few days in Niigata cause I was with a friend who studied abroad there. And then a few days in Kanazawa. [00:13:56] Jeremy: That's really cool, yeah. yeah, I had a friend who lived there, but they were teaching English, yeah. And, I always have a really good time when I'm out there, yeah. [00:14:08] Sara: Absolutely. If anyone out there visiting wants to go to Japan, this is your push. Go do it. Reach out to me on LinkedIn. I will help you plan. [00:14:17] Jeremy: Nice, nice. Um, yeah, I, I, I would say the same. Like, definitely, if you're thinking about it, go. And, uh, sounds like Sara will hook you up. [00:14:28] Sara: Yep, I'm your travel guide. Technical terms in Japanese [00:14:31] Jeremy: So you, you studied, uh, you, you said you had a minor in Japanese? Yeah. So, so when you were teaching there, were you teaching classes in English or was it in Japanese? [00:14:42] Sara: It was a mix. Uh, when I was hired, the job description was no Japanese needed. It was a very, like, Global, international style college, so there was a huge emphasis on learning English. They wanted us to teach only in English. My thought was, it's hard enough learning computer science in your native language, let alone a foreign language, so my lectures were in English, but I would assist the labs in japanese [00:15:14] Jeremy: Oh, nice. Okay. And then, so you were basically fluent then at the time. Middle. Okay. Yeah. Yeah. Hey, well, I think if you're able to, to help people, you know, in labs and stuff, and it's a technical topic, right? So that's gotta be kind of a, an interesting challenge [00:15:34] Sara: I did learn a lot of new computer vocabulary. Yes. [00:15:39] Jeremy: So the words are, like, a lot of them are not the same? Or, you know, for, for specifically related to programming, I guess. [00:15:46] Sara: Hmm. Yeah, there are Japanese specific words. There's a lot of loan words that we use. We. Excuse me. There's a lot of loan words that Japanese uses for computer terms, but there's plenty that are just in Japanese. For example, uh, an array is hairetsu. [00:16:08] Jeremy: Okay. [00:16:08] Sara: And like a screen or the display that your monitor is a gamen, but a keyboard would be keyboard... Kībōdo, probably. [00:16:20] Jeremy: Yeah. So just, uh, so that, they use that as a loan word, I guess. But I'm not sure why not the other two. [00:16:27] Sara: Yeah, it's a mystery. [00:16:29] Jeremy: So it's just, it's just a total mix. Yeah. I'm just picturing you thinking like, okay, is it the English word or is it the Japanese word? You know, like each time you're thinking of a technical term. Yeah. [00:16:39] Sara: Mm hmm. I mostly, I, I I went to the internet. I searched for Japanese computer term dictionary website, and kind of just studied the terms. I also paid a lot of attention to the Japanese professors when they were teaching, what words they were using. Tried to integrate. Also, I was able to lean on my study abroad, because it was a technical Japanese, like there were classes that we took that was on technical Japanese. Computer usage, and also eco technology, like green technology. So I had learned a bunch of them previously. [00:17:16] Jeremy: Mm. So was that for like a summer or a year or something [00:17:20] Sara: It was six weeks [00:17:21] Jeremy: Six weeks. [00:17:21] Sara: During the summer, [00:17:22] Jeremy: Got it. So that's okay. So like, yeah, that must have been an experience like going to, I'm assuming that's the first time you had been [00:17:30] Sara: It was actually the second time [00:17:31] Jeremy: The second [00:17:32] Sara: Yeah. That was in 2010 that I studied abroad. [00:17:35] Jeremy: And then the classes, they were in Japanese or? Yeah. Yeah. That's, uh, that's, that's full immersion right there. [00:17:42] Sara: It was, it was very funny in the, in the very first lesson of kind of just the general language course, there was a student that was asking, I, how do I say this? I don't know this. And she was like, Nihongo de. [00:17:55] Jeremy: Oh (laughs) ! [00:17:56] Sara: You must, must ask your question only in [00:17:59] Jeremy: Yeah, Programming resources in Japanesez [00:17:59] Jeremy: yeah. yeah. That's awesome. So, so it's like, I guess the, the professors, they spoke English, but they were really, really pushing you, like, speak Japanese. Yeah, that's awesome. and maybe this is my bias because I'm an English native, but when you look up. Resources, like you look up blog posts and Stack Overflow and all this stuff. It's all in English, right? So I'm wondering for your, your students, when, when they would search, like, I got this error, you know, what do I do about it? Are they looking at the English pages or are they, you know, you know what I mean? [00:18:31] Sara: There are Japanese resources that they would use. They love Guguru (Google) sensei. [00:18:36] Jeremy: Ah okay. Okay. [00:18:38] Sara: Um, but yeah, there are plenty of Japanese language stack overflow equivalents. I'm not sure if they have stack overflow specifically in Japanese. But there are sites like that, that they, that they used. Some of the more invested students would also use English resources, but that was a minority. [00:19:00] Jeremy: Interesting. So there's a, there's a big enough community, I suppose, of people posting and answering questions and stuff where it's, you don't feel like, there aren't people doing the same thing as you out there. [00:19:14] Sara: Absolutely. Yeah. There's, a large world of software development in Japan, that we don't get to hear. There are questions and answers over here because of that language barrier. [00:19:26] Jeremy: Yeah. I would be, like, kind of curious to, to see, the, the languages and the types of problems they have, if they were similar or if it's, like, I don't know, just different. [00:19:38] Sara: Yeah, now I'm interested in that too, and I bet you there is a lot of research that we could do on Ruby, since Ruby is Japanese. [00:19:51] Jeremy: Right. cause something I've, I've often heard is that, when somebody says they're working with Ruby, Here in, um, the United States, a lot of times people assume it's like, Oh, you're doing a Rails app, [00:20:02] Sara: Mm hmm. [00:20:03] Jeremy: Almost, almost everybody who's using Ruby, not everyone, but you know, the majority I think are using it because of Rails. And I've heard that in Japan, there's actually a lot more usage that's, that's not tied to Rails. [00:20:16] Sara: I've also heard that, and I get the sense of that from RubyKaigi as well. Which I have never been lucky enough to attend. But, yeah, the talks that come out of RubyKaigi, very technical, low to the metal of Ruby, because there's that community that's using it for things other than Rails, other than web apps. [00:20:36] Jeremy: Yeah, I think, one of the ones, I don't know if it was a talk or not, but, somebody was saying that there is Ruby in space. [00:20:42] Sara: That's awesome. Ruby's everywhere. LAN parties in college [00:20:44] Jeremy: So yeah, I guess like another thing I saw, during your time at Rochester is you were, involved with like, there's like a gaming club I wonder if you could talk a little bit about your experience with that. [00:20:55] Sara: Absolutely, I can. So, at RIT, I was an executive board member for three or four years at the Electronic Gaming Society. EGS for short, uh, we hosted weekly console game nights in, the student alumni union area, where there's open space, kind of like a cafeteria. We also hosted quarterly land parties, and we would actually get people from out of state sometimes who weren't even students to come. Uh, and we would usually host the bigger ones in the field house, which is also where concerts are held. And we would hold the smaller ones in conference rooms. I think when I started in 2006, the, the, the LANs were pretty small, maybe like 50, 50 people bring your, your, your huge CRT monitor tower in. [00:21:57] Jeremy: Oh yeah, [00:21:57] Sara: In And then by the time I left in 2012. we were over 300 people for a weekend LAN party, um, and we were actually drawing more power than concerts do. [00:22:13] Jeremy: Incredible. what were, what were people playing at the time? Like when they would the LANs like, [00:22:18] Sara: Yep. Fortnite, early League of Legends, Call of Duty. Battlegrounds. And then also just like fun indie games like Armagedtron, which is kind of like a racing game in the style of [00:22:37] Jeremy: okay. Oh, okay, [00:22:39] Sara: Um, any, there are some like fun browser games where you could just mess with each other. Jackbox. Yeah. [00:22:49] Jeremy: Yeah, it's, it's interesting that, you know, you're talking about stuff like Fortnite and, um, what is it? Battlegrounds is [00:22:55] Sara: not Fortnite. Team Fortress. [00:22:58] Jeremy: Oh Team Fortress! [00:22:59] Sara: Sorry. Yeah. Oh, yeah, I got my, my names mixed up. Fortnite, I think, did not exist at the time, but Team Fortress was big. [00:23:11] Jeremy: Yeah. that's really cool that you're able to get such a big group there. is there something about Rochester, I guess, that that was able to bring together this many people for like these big LAN events? Because I'm... I mean, I'm not sure how it is elsewhere, but I feel like that's probably not what was happening elsewhere in the country. [00:23:31] Sara: Yeah, I mean, if you've ever been to, um, DreamHack, that's, that's a huge LAN party and game convention, that's fun. so... EGS started in the early 2000s, even before I joined, and was just a committed group of people. RIT was a very largely technical school. The majority of students were there for math, science, engineering, or they were in the computer college, [00:24:01] Jeremy: Oh, okay. [00:24:01] Sara: GCIS, G C C I S, the Gossano College of Computing and Information Sciences. So there was a lot of us there. [00:24:10] Jeremy: That does make sense. I mean, it's, it's sort of this, this bias that when there's people doing, uh, technical stuff like software, um, you know, and just IT, [00:24:21] Sara: Mm hmm. [00:24:23] Jeremy: there's kind of this assumption that's like, oh, maybe they play games. And it seems like that was accurate [00:24:27] Sara: It was absolutely accurate. And there were plenty of people that came from different majors. but when I started, there were 17, 000 students and so that's a lot of students and obviously not everyone came to our weekly meetings, but we had enough dedicated people that were on the eboard driving, You know, marketing and advertising for, for our events and things like that, that we were able to get, the good community going. I, I wasn't part of it, but the anime club at RIT is also huge. They run a convention every year that is huge, ToraCon, um. And I think it's just kind of the confluence of there being a lot of geeks and nerds on campus and Rochester is a college town. There's maybe like 10 other universities in [00:25:17] Jeremy: Well, sounds like it was a good time. [00:25:19] Sara: Absolutely would recommend. Strong Museum of Play [00:25:22] Jeremy: I've never, I've never been, but the one thing I have heard about Rochester is there's the, the Strong Museum of Play. [00:25:29] Sara: Yeah, that place is so much fun, even as an adult. It's kind of like, um, the, the Children's Museum in Indiana for, for those that might know that. it just has all the historical toys and pop culture and interactive exhibits. It's so fun. [00:25:48] Jeremy: it's not quite the same, but it, when you were mentioning the Children's Museum in, um, I think it's in St. Louis, there's, uh, it's called the City Museum and it's like a, it's like a giant playground, you know, indoors, outdoors, and it's not just for kids, right? And actually some of this stuff seems like kind of sketch in terms of like, you could kind of hurt yourself, you know, climbing [00:26:10] Sara: When was this made? [00:26:12] Jeremy: I'm not sure, but, uh, [00:26:14] Sara: before regulations maybe. ha. [00:26:16] Jeremy: Yeah. It's, uh, but it's really cool. So at the, at the Museum of Play, though, is it, There's like a video game component, right? But then there's also, like, other types of things, [00:26:26] Sara: Yeah, they have, like, a whole section of the museum that's really, really old toys on display, like, 1900s, 1800s. Um, they have a whole Sesame Street section, and other things like that. Yeah. From Java to Ruby [00:26:42] Jeremy: Check it out if you're in Rochester. maybe now we could talk a little bit about, so like now you're working at Thoughtbot as a Ruby developer. but before we started recording, you were telling me that you started, working with Java. And there was like a, a long path I suppose, you know, changing languages. So maybe you can talk a little bit about your experience there. [00:27:06] Sara: Yeah. for other folks who have switched languages, this might be a familiar story for you, where once you get a job in one technology or one stack, one language, you kind of get typecast after a while. Your next job is probably going to be in the same language, same stack. Companies, they hire based on technology and So, it might be hard, even if you've been playing around with Ruby in your free time, to break, make that barrier jump from one language to another, one stack to another. I mean, these technologies, they can take a little while to ramp up on. They can be a little bit different, especially if you're going from a non object oriented language to an object oriented, don't. Lose hope. (laughs) If you have an interest in Ruby and you're not a Rubyist right now, there's a good company for you that will give you a chance. That's the key that I learned, is as a software developer, the skills that you have that are the most important are not the language that you know. It's the type of thinking that you do, the problem solving, communication, documentation, knowledge sharing, Supporting each other, and as Saron the keynote speaker on Wednesday said, the, the word is love. [00:28:35] Jeremy: [00:28:35] Sara: So when I was job hunting, it was really valuable for me to include those important aspects in my skill, in my resume, in my CV, in my interviews, that like, I'm newer to this language because I had learned it at a rudimentary level before. Never worked in it really professionally for a long time. Um, when I was applying, it was like, look, I'm good at ramping up in technologies. I have been doing software for a long time, and I'm very comfortable with the idea of planning, documenting, problem solving. Give me a chance, please. I was lucky enough to find my place at a company that would give me a chance. Test Double hired me in 2019 as a remote. Software Consultant, and it changed my life. [00:29:34] Jeremy: What, what was it about, Ruby that I'm assuming that this is something that you maybe did in your spare time where you were playing with Ruby or? [00:29:43] Sara: I am one of those people that don't really code in their spare time, which I think is valuable for people to say. The image of a software developer being, well, if you're not coding in your spare time, then you're not passionate about it. That's a myth. That's not true. Some of us, we have other hobbies. I have lots of hobbies. Coding is not the one that I carry outside of the workplace, usually, but, I worked at a company called Constant Contact in 2014 and 2015. And while I was there, I was able to learn Ruby on Rails. [00:30:23] Jeremy: Oh, okay. So that was sort of, I guess, your experience there, on the job. I guess you enjoyed something about the language or something about Rails and then that's what made you decide, like, I would really love to, to... do more of this [00:30:38] Sara: Absolutely. It was amazing. It's such a fun language. The first time I heard about it was in college, maybe 2008 or 2009. And I remember learning, this looks like such a fun language. This looks like it would be so interesting to learn. And I didn't think about it again until 2014. And then I was programming in it. Coming from a Java mindset and it blew my mind, the Rails magic also, I was like, what is happening? This is so cool. Because of my typecasting sort of situation of Java, I wasn't able to get back to it until 2019. And I don't want to leave. I'm so happy. I love the language. I love the community. It's fun. [00:31:32] Jeremy: I can totally see that. I mean, when I first tried out Rails, yeah, it, like, you mentioned the magic, and I know some people are like, ah, I don't like the magic, but when, I think, once I saw what you could do, And how, sort of, little you needed to write, and the fact that so many projects kind of look the same. Um, yeah, that really clicked for me, and I really appreciated that. think that and the Rails console. I think the console is amazing. [00:32:05] Sara: Being able to just check real quick. Hmm, I wonder if this will work. Wait, no, I can check right now. I [00:32:12] Jeremy: And I think that's an important point you brought up too, about, like, not... the, the stereotype and I, I kind of, you know, showed it here where I assumed like, Oh, you were doing Java and then you moved to Ruby. It must've been because you were doing Ruby on the side and thought like, Oh, this is cool. I want to do it for my job. but I, I thought that's really cool that you were able to, not only that you, you don't do the programming stuff outside of work, but that you were able to, to find an opportunity where you could try something different, you know, in your job where you're still being paid. And I wonder, was there any, was there any specific intention behind, like, when you took that job, it was so that I can try something different, or did it just kind of happen? I'm curious what your... The appeal of consulting [00:32:58] Sara: I was wanting to try something different. I also really wanted to get into consulting. [00:33:04] Jeremy: Hmm. [00:33:05] Sara: I have ADHD. And working at a product company long term, I think, was never really going to work out for me. another thing you might notice in my LinkedIn is that a lot of my stays at companies have been relatively short. Because, I don't know, I, my brain gets bored. The consultancy environment is... Perfect. You can go to different clients, different engagements, meet new people, learn a different stack, learn how other people are doing things, help them be better, and maybe every two weeks, two months, three months, six months, a year, change and do it all over again. For some people, that sounds awful. For me, it's perfect. [00:33:51] Jeremy: Yeah, I hadn't thought about that with, with consulting. cause I, I suppose, so you said it's, it's usually about half a year between projects or is It [00:34:01] Sara: varies [00:34:01] Jeremy: It varies widely. [00:34:02] Sara: Widely. I think we try to hit the sweet spot of 3-6 months. For an individual working on a project, the actual contract engagement might be longer than that, but, yeah. Maintainers don't get enough credit [00:34:13] Jeremy: Yeah. And, and your point about how some people, they like to jump on different things and some people like to, to stick to the same thing. I mean, that, that makes a lot of, sense in terms of, I think maintaining software and like building new software. It's, they're both development, [00:34:32] Sara: Mm hmm. [00:34:32] Jeremy: they're very different. Right. [00:34:35] Sara: It's so funny that you bring that up because I highly gravitate towards maintaining over making. I love going to different projects, but I have very little interest in Greenfield, very little interest in making something new. I want to get into the weeds, into 10 years that nobody wants to deal with because the weeds are so high and there's dragons in there. I want to cut it away. I want to add documentation. I want to make it better. It's so important for us to maintain our software. It doesn't get nearly enough credit. The people that work on open source, the people that are doing maintenance work on, on apps internally, externally, Upgrades, making sure dependencies are all good and safe and secure. love that stuff. [00:35:29] Jeremy: That's awesome. We, we need more of you. (laughs) [00:35:31] Sara: There's plenty of us out there, but we don't get the credit (laughs) [00:35:34] Jeremy: Yeah, because it's like with maintenance, well, I would say probably both in companies and in open source when everything is working. Then Nobody nobody knows. Nobody says anything. They're just like, Oh, that's great. It's working. And then if it breaks, then everyone's upset. [00:35:51] Sara: Exactly. [00:35:53] Jeremy: And so like, yeah, you're just there to get yelled at when something goes wrong. But when everything's going good, it's like, [00:35:59] Sara: A job well done is, I was never here. [00:36:02] Jeremy: Yeah. Yeah. Yeah. I don't know how. To, you know, to fix that, I mean, when you think about open source maintainers, right, like a big thing is, is, is burnout, right? Where you are keeping the internet and all of our applications running and, you know, what you get for it is people yelling at you and the issues, right? [00:36:23] Sara: Yeah, it's hard. And I think I actually. Submitted a talk to RubyConf this year about this topic. It didn't get picked. That's okay. Um, we all make mistakes. I'm going to try to give it somewhere in the future, but I think one of the important things that we as an industry should strive for is giving glory. Giving support and kudos to maintenance work. I've been trying to do that. slash I have been doing that at ThoughtBot by, at some cadence. I have been putting out a blog post to the ThoughtBot blog called. This week in open source, the time period that is covered might be a week or longer in those posts. I give a summary of all of the commits that have been made to our open source projects. And the people that made those contributions with highlighting to new version releases, including patch level. And I do this. The time I, I, I took up the torch of doing this from a co worker, Mike Burns, who used to do it 10 years ago. I do this so that people can get acknowledgement for the work they do, even if it's fixing a broken link, even if it's updating some words that maybe don't make sense. All of it is valuable. [00:37:54] Jeremy: Definitely. Yeah. I mean, I, I think that, um, yeah, what's visible to people is when there's a new feature or an API change and Yeah, it's just, uh, people don't, I think a lot of people don't realize, like, how much work goes into just keeping everything running. [00:38:14] Sara: Mm hmm. Especially in the world of open source and Ruby on Rails, all the gems, there's so many different things coming out, things that suddenly this is not compatible. Suddenly you need to change something in your code because a dependency, however many steps apart has changed and it's hard work. The people that do those things are amazing. [00:38:41] Jeremy: So if anybody listening does that work, we, we appreciate you. [00:38:45] Sara: We salute you. Thank you. And if you're interested in contributing to ThoughtBot open source, we have lots of repos. There's one out there for you. Thoughts on RubyConf [00:38:54] Jeremy: You've been doing programming for quite a while, and, you're here at, at RubyConf. I wonder what kind of brings you to these, these conferences? Like, what do you get out of them? Um, I guess, how was this one? That sort of thing. [00:39:09] Sara: Well, first, this one was sick. This one was awesome. Uh, Ruby central pulled out all the stops and that DJ on Monday. In the event, in the exhibit hall. Wow. Amazing. So he told me that he was going to put his set up on Spotify, on Weedmaps Spotify, so go check it out. Anyway, I come to these conferences for people. I just love connecting with people. Those listening might notice that I'm an extrovert. I work remotely. A lot of us work remotely these days. this is an opportunity to see some of my coworkers. There's seven of us here. It's an opportunity to see people I only see at conferences, of which there are a lot. It's a chance to connect with people I've only met on Mastodon, or LinkedIn, or Stack Overflow. It's a chance to meet wonderful podcasters who are putting out great content, keeping our community alive. That's, that's the key for me. And the talks are wonderful, but honestly, they're just a side effect for me. They just come as a result of being here. [00:40:16] Jeremy: Yeah, it's kind of a unique opportunity, you know, to have so many of your, your colleagues and to just all be in the same place. And you know that anybody you talk to here, like if you talk about Ruby or software, they're not going to look at you and go like, I don't know what you're talking about. Like everybody here has at least that in common. So it's, yeah, it's a really cool experience to, to be able to chat with anybody. And it's like, You're all on the same page, [00:40:42] Sara: Mm hmm. We're all in this boat together. [00:40:45] Jeremy: Yup, that we got to keep, got to keep afloat according to matz [00:40:49] Sara: Gotta keep it afloat, yeah. [00:40:51] Jeremy: Though I was like, I was pretty impressed by like during his, his keynote and he had asked, you know, how many of you here, it's your first RubyConf and it felt like it was over half the room. [00:41:04] Sara: Yeah, I got the same sense. I was very glad to see that, very impressed. My first RubyConf was and it was the same sort of showing of [00:41:14] Jeremy: Nice, yeah. Yeah, actually, that was my first one, too. [00:41:17] Sara: Nice! [00:41:19] Jeremy: Uh, that was Nashville, Yeah, yeah, yeah. So it's, yeah, it's really interesting to see because, the meme online is probably like, Ah, Ruby is dead, or Rails is dead. But like you come to these conferences and yeah, there's, there's so many new people. There's like new people that are learning it and experiencing it and, you know, enjoying it the same way we are. So I, I really hope that the, the community can really, yeah, keep this going. [00:41:49] Sara: Continue, continue to grow and share. I love that we had first timer buttons, buttons where people could self identify as this is my first RubyConf and, and then that opens a conversation immediately. It's like, how are you liking it? What was your favorite talk? [00:42:08] Jeremy: Yeah, that's awesome. okay, I think that's probably a good place to start wrapping it. But is there anything else you wanted to mention or thought we should have talked about? [00:42:18] Sara: Can I do a plug for thoughtbot? [00:42:20] Jeremy: yeah, go for it. [00:42:21] Sara: Alright. For those of you out there that might not know what ThoughtBot does, we are a full software lifecycle or company lifecycle consultancy, so we do everything from market fit and rapid prototyping to MVPs to helping with developed companies, developed teams, maybe do a little bit of a Boost when you have a deadline or doing some tech debt. Pay down. We also have a DevOps team, so if you have an idea or a company or a team, you want a little bit of support, we have been around for 20 years. We are here for you. Reach out to us at thoughtbot.com. [00:43:02] Jeremy: I guess the thing about Thoughtbot is that, within the Ruby community specifically, they've been so involved with sponsorships and, and podcasts. And so, uh, when you hear about consultancies, a lot of times it's kind of like, well, I don't know, are they like any good? Do they know what they're doing? But I, I feel like, ThoughtBot has had enough, like enough of a public record. I feel It's like, okay, if you, if you hire them, um, you should be in good hands. [00:43:30] Sara: Yeah. If you have any questions about our abilities, read the blog. [00:43:35] Jeremy: It is a good blog. Sometimes when I'm, uh, searching for how to do something in Rails, it'll pop up, [00:43:40] Sara: Mm hmm. Me too. Every question I ask, one of the first results is our own blog. I'm like, oh yeah, that makes sense. [00:43:47] Jeremy: Probably the peak is if you've written the blog. [00:43:50] Sara: That has happened to my coworkers They're like, wait, I wrote a blog about this nine years ago. [00:43:55] Jeremy: Yeah, yeah. So maybe, maybe that'll happen to you soon. I, I know definitely people who do, um, Stack Overflow. And it's like, Oh, I like, this is a good answer. Oh, I wrote this. (laughs) yeah. Well, Sara, thank you so much for, for chatting with me today. [00:44:13] Sara: Absolutely, Jeremy. Thank you so much for having me. I was really glad to chat today.

Kelsey Hightower joins Corey on Screaming in the Cloud to discuss his reflections on how the tech industry is progressing. Kelsey describes what he's been getting out of retirement so far, and reflects on what he learned throughout his high-profile career - including why feature sprawl is such a driving force behind the complexity of the cloud environment and the tactics he used to create demos that are engaging for the audience. Corey and Kelsey also discuss the importance of remaining authentic throughout your career, and what it means to truly have an authentic voice in tech. About KelseyKelsey Hightower is a former Distinguished Engineer at Google Cloud, the co-chair of KubeCon, the world's premier Kubernetes conference, and an open source enthusiast. He's also the co-author of Kubernetes Up & Running: Dive into the Future of Infrastructure. Recently, Kelsey announced his retirement after a 25-year career in tech.Links Referenced:Twitter: https://twitter.com/kelseyhightower TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: Do you wish there were cheat codes for database optimization? Well, there are – no seriously. If you're using Postgres or MySQL on Amazon Aurora or RDS, OtterTune uses AI to automatically optimize your knobs and indexes and queries and other bits and bobs in databases. OtterTune applies optimal settings and recommendations in the background or surfaces them to you and allows you to do it. The best part is that there's no cost to try it. Get a free, thirty-day trial to take it for a test drive. Go to ottertune dot com to learn more. That's O-T-T-E-R-T-U-N-E dot com.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. You know, there's a great story from the Bible or Torah—Old Testament, regardless—that I was always a big fan of where you wind up with the Israelites walking the desert for 40 years in order to figure out what comes next. And Moses led them but could never enter into what came next. Honestly, I feel like my entire life is sort of going to be that direction. Not the biblical aspects, but rather always wondering what's on the other side of a door that I can never cross, and that door is retirement. Today I'm having returning guest Kelsey Hightower, who is no longer at Google. In fact, is no longer working and has joined the ranks of the gloriously retired. Welcome back, and what's it like?Kelsey: I'm happy to be here. I think retirement is just like work in some ways: you have to learn how to do it. A lot of people have no practice in their adult life what to do with all of their time. We have small dabs in it, like, you get the weekend off, depending on what your work, but you never have enough time to kind of unwind and get into something else. So, I'm being honest with myself. It's going to be a learning curve, what to do with that much time.You're probably still going to do work, but it's going to be a different type of work than you're used to. And so, that's where I am. 30 days into this, I'm in that learning mode, I'm on-the-job training.Corey: What's harder than you expected?Kelsey: It's not the hard part because I think mentally I've been preparing for, like, the last ten years, being a minimalist, learning how to kind of live within my means, learn to appreciate things that are just not work-related or status symbols. And so, to me, it felt like a smooth transition because I started to value my time more than anything else, right? Just waking up the next day became valuable to me. Spending time in the moment, right, you go to these conferences, there's, like, 10,000 people, but you learn to value those one-on-one encounters, those one-off, kind of, let's just go grab lunch situations. So, to me, retirement just makes more room for that, right? I no longer have this calendar that is super full, so I think for me, it was a nice transition in terms of getting more of that valuable time back.Corey: It seems to me that you're in a similar position to the one that I find myself in where the job that you were doing and I still am is tied, more or less, to a sense of identity as opposed to a particular task or particular role that you fill. You were Kelsey Hightower. That was a complete sentence. People didn't necessarily need to hear the rest of what you were working on or what you were going to be talking about at a given conference or whatnot. So, it seemed, at least from the outside, that an awful lot of what you did was quite simply who you were. Do you feel that your sense of identity has changed?Kelsey: So, I think when you have that much influence, when you have that much reputation, the words you say travel further, they tend to come with a little bit more respect, and so when you're working with a team on new product, and you say, “Hey, I think we should change some things.” And when they hear those words coming from someone that they trust or has a name that is attached to reputation, you tend to be able to make a lot of impact with very few words. But what you also find is that no matter what you get involved in—configuration management, distributed systems, serverless, working with customers—it all is helped and aided by the reputation that you bring into that line of work. And so yes, who you are matters, but one thing that I think helped me, kind of greatly, people are paying attention maybe to the last eight years of my career: containers, Kubernetes, but my career stretches back to the converting COBOL into Python days; the dawn of DevOps, Puppet, Chef, and Ansible; the Golang appearance and every tool being rewritten from Ruby to Golang; the Docker era.And so, my identity has stayed with me throughout those transitions. And so, it was very easy for me to walk away from that thing because I've done it three or four times before in the past, so I know who I am. I've never had, like, a Twitter bio that said, “Company X. X person from company X.” I've learned long ago to just decouple who I am from my current employer because that is always subject to change.Corey: I was fortunate enough to not find myself in the public eye until I owned my own company. But I definitely remember times in my previous incarnations where I was, “Oh, today I'm working at this company,” and I believed—usually inaccurately—that this was it. This was where I really found my niche. And then surprise I'm not there anymore six months later for, either their decision, my decision, or mutual agreement. And I was always hesitant about hanging a shingle out that was tied too tightly to any one employer.Even now, I was little worried about doing it when I went independent, just because well, what if it doesn't work? Well, what if, on some level? I think that there's an authenticity that you can bring with you—and you certainly have—where, for a long time now, whenever you say something, I take it seriously, and a lot of people do. It's not that you're unassailably correct, but I've never known you to say something you did not authentically believe in. And that is an opinion that is very broadly shared in this industry. So, if nothing else, you definitely were a terrific object lesson in speaking the truth, as you saw it.Kelsey: I think what you describe is one way that, whether you're an engineer doing QA, working in the sales department, when you can be honest with the team you're working with, when you can be honest with the customers you're selling into when you can be honest with the community you're part of, that's where the authenticity gets built, right? Companies, sometimes on the surface, you believe that they just want you to walk the party line, you know, they give you the lines and you just read them verbatim and you're doing your part. To be honest, you can do that with the website. You can do that with a well-placed ad in the search queries.What people are actually looking for are real people with real experiences, sharing not just fact, but I think when you mix kind of fact and opinion, you get this level of authenticity that you can't get just by pure strategic marketing. And so, having that leverage, I remember back in the day, people used to say, “I'm going to do the right thing and if it gets me fired, then that's just the way it's going to be. I don't want to go around doing the wrong thing because I'm scared I'm going to lose my job.” You want to find yourself in that situation where doing the right thing, is also the best thing for the company, and that's very rare, so when I've either had that opportunity or I've tried to create that opportunity and move from there.Corey: It resonates and it shows. I have never had a lot of respect for people who effectively are saying one thing today and another thing the next week based upon which way they think that the winds are blowing. But there's also something to be said for being able and willing to publicly recant things you have said previously as technology evolves, as your perspective evolves and, in light of new information, I'm now going to change my perspective on something. I've done that already with multi-cloud, for example. I thought it was ridiculous when I heard about it. But there are also expressions of it that basically every company is using, including my own. And it's a nuanced area. Where I find it challenging is when you see a lot of these perspectives that people are espousing that just so happen to deeply align with where their paycheck comes from any given week. That doesn't ring quite as true to me.Kelsey: Yeah, most companies actually don't know how to deal with it either. And now there has been times at any number of companies where my authentic opinion that I put out there is against party line. And you get those emails from directors and VPs. Like, “Hey, I thought we all agree to think this way or to at least say this.” And that's where you have to kind of have that moment of clarity and say, “Listen, that is undeniably wrong. It's so wrong in fact that if you say this in public, whether a small setting or large setting, you are going to instantly lose credibility going forward for yourself. Forget the company for a moment. There's going to be a situation where you will no longer be effective in your job because all of your authenticity is now gone. And so, what I'm trying to do and tell you is don't do that. You're better off saying nothing.”But if you go out there, and you're telling what is obviously misinformation or isn't accurate, people are not dumb. They're going to see through it and you will be classified as a person not to listen to. And so, I think a lot of people struggle with that because they believe that enterprise's consensus should also be theirs.Corey: An argument that I made—we'll call it a prediction—four-and-a-half years ago, was that in five years, nobody would really care about Kubernetes. And people misunderstood that initially, and I've clarified since repeatedly that I'm not suggesting it's going away: “Oh, turns out that was just a ridiculous fever dream and we're all going back to running bare metal with our hands again,” but rather that it would slip below the surface-level of awareness. And I don't know that I got the timing quite right on that, I think it's going to depend on the company and the culture that you find yourself in. But increasingly, when there's an application to run, it's easy to ask someone just, “Oh, great. Where's the Kubernetes cluster live so we can throw this on there and just add it to the rest of the pile?”That is sort of what I was seeing. My intention with that was not purely just to be controversial, as much fun as that might be, but also to act as a bit of a warning, where I've known too many people who let their identities become inextricably tangled with the technology. But technologies rise and fall, and at some point—like, you talk about configuration management days; I learned to speak publicly as a traveling trainer for Puppet. I wrote part of SaltStack once upon a time. But it was clear that that was not the direction the industry was going, so it was time to find something else to focus on. And I fear for people who don't keep an awareness or their feet underneath them and pay attention to broader market trends.Kelsey: Yeah, I think whenever I was personally caught up in linking my identity to technology, like, “I'm a Rubyist,” right?“, I'm a Puppeteer,” and you wear those names proudly. But I remember just thinking to myself, like, “You have to take a step back. What's more important, you or the technology?” And at some point, I realized, like, it's me, that is more important, right? Like, my independent thinking on this, my independent experience with this is far more important than the success of this thing.But also, I think there's a component there. Like when you talked about Kubernetes, you know, maybe being less relevant in five years, there's two things there. One is the success of all infrastructure things equals irrelevancy. When flights don't crash, when bridges just work, you do not think about them. You just use them because they're so stable and they become very boring. That is the success criteria.Corey: Utilities. No one's wondering if the faucet's going to work when they turn it on in the morning.Kelsey: Yeah. So, you know, there's a couple of ways to look at your statement. One is, you believe Kubernetes is on the trajectory that it's going to stabilize itself and hit that success criteria, and then it will be irrelevant. Or there's another part of the irrelevancy where something else comes along and replaces that thing, right? I think Cloud Foundry and Mesos are two good examples of Kubernetes coming along and stealing all of the attention from that because those particular products never gained that mass adoption. Maybe they got to the stable part, but they never got to the mass adoption part. So, I think when it comes to infrastructure, it's going to be irrelevant. It's just what side of that [laugh] coin do you land on?Corey: It's similar to folks who used to have to work at a variety of different companies on very specific Linux kernel subsystems because everyone had to care because there were significant performance impacts. Time went on and now there's still a few of those people that very much need to care, but for the rest of us, it is below the level of things that we have to care about. For me, the signs of the unsustainability were, oh, you can run Kubernetes effectively in production? That's a minimum of a quarter-million dollars a year in comp or up in some cases. Not every company is going to be able to field a team of those people and still remain a going concern in business. Nor frankly, should they have to.Kelsey: I'm going to pull on that thread a little bit because it's about—we're hitting that ten-year mark of Kubernetes. So, when Kubernetes comes out, why were people drawn to it, right? Why did it even get the time of day to begin with? And I think Docker kind of opened Pandora's box there. This idea of Chef, Puppet, Ansible, ten thousand package managers, and honestly, that trajectory was going to continue forever and it was helping no one. It was literally people doing duplicate work depending on the operating system you're dealing with and we were wasting time copying bits to servers—literally—in a very glorified way.So, Docker comes along and gives us this nicer, better abstraction, but it has gaps. It has no orchestration. It's literally this thing where now we've unified the packaging situation, we've learned a lot from Red Hat, YUM, Debian, and the various package repo combinations out there and so we made this universal thing. Great. We also learned a little bit about orchestration through brute force, bash scripts, config management, you name it, and so we serialized that all into this thing we call Kubernetes.It's pretty simple on the surface, but it was probably never worthy of such fanfare, right? But I think a lot of people were relieved that now we finally commoditized this expertise that the Googles, the Facebooks of the world had, right, building these systems that can copy bits to other systems very fast. There you go. We've gotten that piece. But I think what the market actually wants is in the mobile space, if you want to ship software to 300 million people that you don't even know, you can do it with the app store.There's this appetite that the boring stuff should be easy. Let's Encrypt has made SSL certificates beyond easy. It's just so easy to do the right thing. And I think for this problem we call deployments—you know, shipping apps around—at some point we have to get to a point where that is just crazy easy. And it still isn't.So, I think some of the frustration people express ten years later, they're realizing that they're trying to recreate a Rube Goldberg machine with Kubernetes is the base element and we still haven't understood that this whole thing needs to simplify, not ten thousand new pieces so you can build your own adventure.Corey: It's the idea almost of what I'm seeing AWS go through, and to some extent, its large competitors. But building anything on top of AWS from scratch these days is still reminiscent of going to Home Depot—or any hardware store—and walking up and down the aisles and getting all the different components to piece together what you want. Sometimes just want to buy something from Target that's already assembled and you have to do all of that work. I'm not saying there isn't value to having a Home Depot down the street, but it's also not the panacea that solves for all use cases. An awful lot of customers just want to get the job done and I feel that if we cling too tightly to how things used to be, we lose it.Kelsey: I'm going to tell you, being in the cloud business for almost eight years, it's the customers that create this. Now, I'm not blaming the customer, but when you start dealing with thousands of customers with tons of money, you end up in a very different situation. You can have one customer willing to pay you a billion dollars a year and they will dictate things that apply to no one else. “We want this particular set of features that only we will use.” And for a billion bucks a year times ten years, it's probably worth from a business standpoint to add that feature.Now, do this times 500 customers, each major provider. What you end up with is a cloud console that is unbearable, right? Because they also want these things to be first-class citizens. There's always smaller companies trying to mimic larger peers in their segment that you just end up in that chaos machine of unbound features forever. I don't know how to stop it. Unless you really come out maybe more Apple style and you tell people, “This is the one and only true way to do things and if you don't like it, you have to go find an alternative.” The cloud business, I think, still deals with the, “If you have a large payment, we will build it.”Corey: I think that that is a perspective that is not appreciated until you've been in the position of watching how large enterprises really interact with each other. Because it's, “Well, what customer the world is asking for yet another way to run containers?” “Uh, this specific one and their constraints are valid.” Every time I think I've seen everything there is to see in the world of cloud, I just have to go talk to one more customer and I'm learning something new. It's inevitable.I just wish that there was a better way to explain some of this to newcomers, when they're looking at, “Oh, I'm going to learn how this cloud thing works. Oh, my stars, look at how many services there are.” And then they wind up getting lost with analysis paralysis, and every time they get started and ask someone for help, they're pushed in a completely different direction and you keep spinning your wheels getting told to start over time and time again when any of these things can be made to work. But getting there is often harder than it really should be.Kelsey: Yeah. I mean, I think a lot of people don't realize how far you can get with, like, three VMs, a load balancer, and Postgres. My guess is you can probably build pretty much any clone of any service we use today with at least 1 million customers. Most people never reached that level—I don't even want to say the word scale—but that blueprint is there and most people will probably be better served by that level of simplicity than trying to mimic the behaviors of large customers—or large companies—with these elaborate use cases. I don't think they understand the context there. A lot of that stuff is baggage. It's not [laugh] even, like, best-of-breed or great design. It's like happenstance from 20 years of trying to buy everything that's been sold to you.Corey: I agree with that idea wholeheartedly. I was surprising someone the other day when I said that if you were to give me a task of getting some random application up and running by tomorrow, I do a traditional three-tier architecture, some virtual machines, a load balancer, and a database service. And is that the way that all the cool kids are doing it today? Well, they're not talking about it, but mostly. But the point is, is that it's what I know, it's where my background is, and the thing you already know when you're trying to solve a new problem is incredibly helpful, rather than trying to learn everything along that new path that you're forging down. Is that architecture the best approach? No, but it's perfectly sufficient for an awful lot of stuff.Kelsey: Yeah. And so, I mean, look, I've benefited my whole career from people fantasizing about [laugh] infrastructure—Corey: [laugh].Kelsey: And the truth is that in 2023, this stuff is so powerful that you can do almost anything you want to do with the simplest architecture that's available to us. The three-tier architecture has actually gotten better over the years. I think people are forgotten: CPUs are faster, RAM is much bigger quantities, the networks are faster, right, these databases can store more data than ever. It's so good to learn the fundamentals, start there, and worst case, you have a sound architecture people can reason about, and then you can go jump into the deep end, once you learn how to swim.Corey: I think that people would be depressed to understand just how much the common case for the value that Kubernetes brings is, “Oh yeah, now we can lose a drive or a server and the application stays up.” It feels like it's a bit overkill for that one somewhat paltry use case, but that problem has been hounding companies for decades.Kelsey: Yeah, I think at some point, the whole ‘SSH is my only interface into these kinds of systems,' that's a little low level, that's a little bare bones, and there will probably be a feature now where we start to have this not Infrastructure as Code, not cloud where we put infrastructure behind APIs and you pay per use, but I think what Kubernetes hints at is a future where you have APIs that do something. Right now the APIs give you pieces so you can assemble things. In the future, the APIs will just do something, “Run this app. I need it to be available and here's my money budget, my security budget, and reliability budget.” And then that thing will say, “Okay, we know how to do that, and here's roughly what is going to cost.”And I think that's what people actually want because that's how requests actually come down from humans, right? We say, “We want this app or this game to be played by millions of people from Australia to New York.” And then for a person with experience, that means something. You kind of know what architecture you need for that, you know what pieces that need to go there. So, we're just moving into a realm where we're going to have APIs that do things all of a sudden.And so, Kubernetes is the warm-up to that era. And that's why I think that transition is a little rough because it leaks the pieces part, so where you can kind of build all the pieces that you want. But we know what's coming. Serverless also hints at this. But that's what people should be looking for: APIs that actually do something.Corey: This episode is sponsored in part by Panoptica.  Panoptica simplifies container deployment, monitoring, and security, protecting the entire application stack from build to runtime. Scalable across clusters and multi-cloud environments, Panoptica secures containers, serverless APIs, and Kubernetes with a unified view, reducing operational complexity and promoting collaboration by integrating with commonly used developer, SRE, and SecOps tools. Panoptica ensures compliance with regulatory mandates and CIS benchmarks for best practice conformity. Privacy teams can monitor API traffic and identify sensitive data, while identifying open-source components vulnerable to attacks that require patching. Proactively addressing security issues with Panoptica allows businesses to focus on mitigating critical risks and protecting their interests. Learn more about Panoptica today at panoptica.app.Corey: You started the show by talking about how your career began with translating COBOL into Python. I firmly believe someone starting their career today listening to this could absolutely find that by the time their career starts drawing to their own close, that Kubernetes is right in there as far as sounding like the deprecated thing that no one really talks about or thinks about anymore. And I hope so. I want the future to be brighter than the past. I want getting a business or getting software together in a way that helps people to not require the amount of, “First, spend six weeks at a boot camp,” or, “Learn how to write just enough code that you can wind up getting funding and then have it torn apart.”What's the drag-and-drop story? What's the describe the application to a robot and it builds it for you? I'm optimistic about the future of infrastructure, just because based upon its power to potentially make reliability and scale available to folks who have no idea of what's involved with that. That's kind of the point. That's the end game of having won this space.Kelsey: Well, you know what? Kubernetes is providing the metadata to make that possible, right? Like in the early days, people were writing one-off scripts or, you know, writing little for loops to get things in the right place. And then we get config management that kind of formalizes that, but it still had no metadata, right? You'd have things like Puppet report information.But in the world of, like, Kubernetes, or any cloud provider, now you get semantic meaning. “This app needs this volume with this much space with this much memory, I need three of these behind this load balancer with these protocols enabled.” There is now so much metadata about applications, their life cycles, and how they work that if you were to design a new system, you can actually use that data to craft a much better API that made a lot of this boilerplate the defaults. Oh, that's a web application. You do not need to specify all of this boilerplate. Now, we can give you much better nouns and verbs to describe what needs to happen.So, I think this is that transition as all the new people coming up, they're going to be dealing with semantic meaning to infrastructure, where we were dealing with, like, tribal knowledge and intuition, right? “Run this script, pipe it to this thing, and then this should happen. And if it doesn't, run the script again with this flag.” Versus, “Oh, here's the semantic meaning to a working system.” That's a game-changer.Corey: One other topic I wanted to ask you about—I've it's been on my list of things to bring up the next time I ran into you and then you went ahead and retired, making it harder to run into you. But a little while back, I was at a tech conference and someone gave a demo, and it didn't go as well as they had hoped. And a few of us were talking about it afterwards. We've all been speakers, we've all lived that life. Zero shade.But someone brought you up in particular—unprompted; your legend does precede you—and the phrase that they used was that Kelsey's demos were always picture-perfect. He was so lucky with how the demos worked out. And I just have to ask—because you don't strike me as someone who is not careful, particularly when all eyes are upon you—and real experts make things look easy, did you have demos periodically go wrong that the audience just didn't see going wrong along the way? Or did you just actually YOLO all of your demos and got super lucky every single time for the last eight years?Kelsey: There was a musician who said, “Hey, your demos are like jazz. You improvise the whole thing.” There's no script, there's no video. The way I look at the demo is, like, you got this instrument, the command prompt, and the web browser. You can do whatever you want with them.Now, I have working code. I wrote the code, I wrote the deployment scenarios, I delete it all and I put it all back. And so, I know how it's supposed to work from the ground up. And so, what that means is if anything goes wrong, I can improvise. I could go into fixing the code. I can go into doing a redeploy.And I'll give you one good example. The first time Kubernetes came out, there was this small meetup in San Francisco with just the core contributors, right? So, there is no community yet, there's no conference yet, just people hacking on Kubernetes. And so, we decided, we're going to have the first Kubernetes meetup. And everyone got, like, six, seven minutes, max. That's it. You got to move.And so, I was like, “Hey, I noticed that in the lineup, there is no ‘What is Kubernetes?' talk. We're just getting into these nuts and bolts and I don't think that's fair to the people that will be watching this for the first time.” And I said, “All right, Kelsey, you should give maybe an intro to what it is.” I was like, “You know what I'll do? I'm going to build a Kubernetes cluster from the ground up, starting with VMs on my laptop.”And I'm in it and I'm feeling confident. So, confidence is the part that makes it look good, right? Where you're confident in the commands you type. One thing I learned to do is just use your history, just hit the up arrow instead of trying to copy all these things out. So, you hit the up arrow, you find the right command and you talk through it and no one looks at what's happening. You're cycling through the history.Or you have multiple tabs where you know the next up arrow is the right history. So, you give yourself shortcuts. And so, I'm halfway through this demo. We got three minutes left, and it doesn't work. Like, VMware is doing something weird on my laptop and there's a guy calling me off stage, like, “Hey, that's it. Cut it now. You're done.”I'm like, “Oh, nope. Thou shalt not go out like this.” It's time to improvise. And so, I said, “Hey, who wants to see me finish this?” And now everyone is locked in. It's dead silent. And I blow the whole thing away. I bring up the VMs, I [pixie 00:28:20] boot, I installed the kubelet, I install Docker. And everyone's clapping. And it's up, it's going, and I say, “Now, if all of this works, we run this command and it should start running the app.” And I do kubectl apply-f and it comes up and the place goes crazy.And I had more to the demo. But you stop. You've gotten the point across, right? This is what Kubernetes is, here's how it works, and look how you do it from scratch. And I remember saying, “And that's the end of my presentation.” You need to know when to stop, you need to know when to pivot, and you need to have confidence that it's supposed to work, and if you've seen it work a couple of times, your confidence is unshaken.And when I walked off that stage, I remember someone from Red Hat was like—Clayton Coleman; that's his name—Clayton Coleman walked up to me and said, “You planned that. You planned it to fail just like that, so you can show people how to go from scratch all the way up. That was brilliant.” And I was like, “Sure. That's exactly what I did.”Corey: “Yeah, I meant to do that.” I like that approach. I found there's always things I have to plan for in demos. For example, I can never count on having solid WiFi from a conference hall. The show has to go on. It's, okay, the WiFi doesn't work. I've at one point had to give a talk where the projector just wasn't working to a bunch of students. So okay, close the laptop. We're turning this into a bunch of question-and-answer sessions, and it was one of the better talks I've ever given.But the alternative is getting stuck in how you think a talk absolutely needs to go. Now, keynotes are a little harder where everything has been scripted and choreographed and at that point, I've had multiple fallbacks for demos that I've had to switch between. And people never noticed I was doing it for that exact reason. But it takes work to look polished.Kelsey: I will tell you that the last Next keynote I gave was completely irresponsible. No dry runs, no rehearsals, no table reads, no speaker notes. And I think there were 30,000 people at that particular Next. And Diane Greene was still CEO, and I remember when marketing was like, “Yo, at least a backup recording.” I was like, “Nah, I don't have anything.”And that demo was extensive. I mean, I was building an app from scratch, starting with Postgres, adding the schema, building an app, deploying the app. And something went wrong halfway. And there's this joke that I came up with just to pass over the time, they gave me a new Chromebook to do the demo. And so, it's not mine, so none of the default settings were there, I was getting pop-ups all over the place.And I came up with this joke on the way to the conference. I was like, “You know what'd be cool? When I show off the serverless stuff, I would just copy the code from Stack Overflow. That'd be like a really cool joke to say this is what senior engineers do.” And I go to Stack Overflow and it's getting all of these pop-ups and my mouse couldn't highlight the text.So, I'm sitting there like a deer in headlights in front of all of these people and I'm looking down, and marketing is, like, “This is what… this is what we're talking about.” And so, I'm like, “Man do I have to end this thing here?” And I remember I kept trying, I kept trying, and came to me. Once the mouse finally got in there and I cleared up all the popups, I just came up with this joke. I said, “Good developers copy.” And I switched over to my terminal and I took the text from Stack Overflow and I said, “Great developers paste,” and the whole room start laughing.And I had them back. And we kept going and continued. And at the end, there was like this Google Assistant, and when it was finished, I said, “Thank you,” to the Google Assistant and it was talking back through the live system. And it said, “I got to admit, that was kind of dope.” So, I go to the back and Diane Greene walks back there—the CEO of Google Cloud—and she pats me on the shoulder. “Kelsey, that was dope.”But it was the thrill because I had as much thrill as the people watching it. So, in real-time, I was going through all these emotions. But I think people forget, the demo is supposed to convey something. The demo is supposed to tell some story. And I've seen people overdo their demos with way too much code, way too many commands, almost if they're trying to show off their expertise versus telling a story. And so, when I think about the demo, it has to complement the entire narrative. And so, sometimes you don't need as many commands, you don't need as much code. You can keep things simple and that gives you a lot more ins and outs in case something does go crazy.Corey: And I think the key takeaway here that so many people lose sight of is you have to know the material well enough that whatever happens, well, things don't always go the way I planned during the day, either, and talking through that is something that I think serves as a good example. It feels like a bit more of a challenge when you're trying to demo something that a company is trying to sell someone, “Oh, yeah, it didn't work. But that's okay.” But I'm still reminded by probably one of the best conference demo fails I've ever seen on video. One day, someone was attempting to do a talk that hit Amazon S3 and it didn't work.And the audience started shouting at him that yeah, S3 is down right now. Because that was the big day that S3 took a nap for four hours. It was one of those foundational things you'd should never stop to consider. Like, well, what if the internet doesn't work tomorrow when I'm doing my demo? That's a tough one to work around. But rough timing.Kelsey: [breathy sound]Corey: He nailed the rest of the talk, though. You keep going. That's the thing that people miss. They get stuck in the demo that isn't working, they expect the audience knows as much as they do about what's supposed to happen next. You're the one up there telling a story. People forget it's storytelling.Kelsey: Now, I will be remiss to say, I know that the demo gods have been on my side for, like, ten, maybe fifteen years solid. So, I retired from doing live demos. This is why I just don't do them anymore. I know I'm overdue as an understatement. But the thing I've learned though, is that what I found more impressive than the live demo is to be able to convey the same narratives through story alone. No slides. No demo. Nothing. But you can still make people feel where you would try to go with that live demo.And it's insanely hard, especially for technologies people have never seen before. But that's that new challenge that I kind of set up for myself. So, if you see me at a keynote and you've noticed why I've been choosing these fireside chats, it's mainly because I'm also trying to increase my ability to share narrative, technical concepts, but now in a new form. So, this new storytelling format through the fireside chat has been my substitute for the live demo, normally because I think sometimes, unless there's something really to show that people haven't seen before, the live demo isn't as powerful to me. Once the thing is kind of known… the live demo is kind of more of the same. So, I think they really work well when people literally have never seen the thing before, but outside of that, I think you can kind of move on to, like, real-life scenarios and narratives that help people understand the fundamentals and the philosophy behind the tech.Corey: An awful lot of tools and tech that we use on a day-to-day basis as well are thankfully optimized for the people using them and the ergonomics of going about your day. That is orthogonal, in my experience, to looking very impressive on stage. It's the rare company that can have a product that not only works well but also presents well. And that is something I don't tend to index on when I'm selecting a tool to do something with. So, it's always a question of how can I make this more visually entertaining? For while I got out of doing demos entirely, just because talking about things that have more staying power than a screenshot that is going to wind up being irrelevant the next week when they decide to redo the console for some service yet again.Kelsey: But you know what? That was my secret to doing software products and projects. When I was at CoreOS, we used to have these meetups we would used to do every two weeks or so. So, when we were building things like etcd, Fleet was a container management platform that came before Kubernetes, we would always run through them as a user, start install them, use them, and ask how does it feel? These command line flags, they don't feel right. This isn't a narrative you can present with the software alone.But once we could, then the meetups were that much more engaging. Like hey, have you ever tried to distribute configuration to, like, a thousand servers? It's insanely hard. Here's how you do with Puppet. But now I'm going to show you how you do with etcd. And then the narrative will kind of take care of itself because the tool was positioned behind what people would actually do with it versus what the tool could do by itself.Corey: I think that's the missing piece that most marketing doesn't seem to quite grasp is, they talk about the tool and how awesome it is, but that's why I love customer demos so much. They're showing us how they use a tool to solve a real-world problem. And honestly, from my snarky side of the world and the attendant perspective there, I can make an awful lot of fun about basically anything a company decides to show me, but put a customer on stage talking about how whatever they've built is solving a real-world problem for them, that's the point where I generally shut up and listen because I'm going to learn something about a real-world story. Because you don't generally get to tell customers to go on stage and just make up a story that makes us sound good, and have it come off with any sense of reality whatsoever. I haven't seen that one happen yet, but I'm sure it's out there somewhere.Kelsey: I don't know how many founders or people building companies listen in to your podcast, but this is right now, I think the number one problem that especially venture-backed startups have. They tend to have great technology—maybe it's based off some open-source project—with tons of users who just know how that tool works, it's just an ingredient into what they're already trying to do. But that isn't going to ever be your entire customer base. Soon, you'll deal with customers who don't understand the thing you have and they need more than technology, right? They need a product.And most of these companies struggle painting that picture. Here's what you can do with it. Or here's what you can't do now, but you will be able to do if you were to use this. And since they are missing that, a lot of these companies, they produce a lot of code, they ship a lot of open-source stuff, they raise a lot of capital, and then it just goes away, it fades out over time because they can bring on no newcomers. The people who need help the most, they don't have a narrative for them, and so therefore, they're just hoping that the people who have all the skills in the world, the early adopters, but unfortunately, those people are tend to be the ones that don't actually pay. They just kind of do it themselves. It's the people who need the most help.Corey: How do we monetize the bleeding edge of adoption? In many cases you don't. They become your community if you don't hug them to death first.Kelsey: Exactly.Corey: Ugh. None of this is easy. I really want to thank you for taking the time to catch up and talk about how you seen the remains of a career well spent, and now you're going off into that glorious sunset. But I have a sneaking suspicion you'll still be around. Where should people go if they want to follow up on what you're up to these days?Kelsey: Right now I still use… I'm going to keep calling it Twitter.Corey: I agree.Kelsey: I kind of use that for my real-time interactions. And I'm still attending conferences, doing fireside chats, and just meeting people on those conference floors. But that's what where I'll be for now. So yeah, I'll still be around, but maybe not as deep. And I'll be spending more time just doing normal life stuff, maybe less building software.Corey: And we will, of course, put a link to that in the show notes. Thank you so much for taking the time to catch up and share your reflections on how the industry is progressing.Kelsey: Awesome. Thanks for having me, Corey.Corey: Kelsey Hightower, now gloriously retired. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice along with an angry comment that you're going to type on stage as part of a conference talk, and then accidentally typo all over yourself while you're doing it.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.

Thanks to Buzzsprout one Rubyist can get a free ticket to Rails World in October this year in Amsterdam, follow the link below for details. Change is good... sometimes. Two days ago Basecamp changed the name of its deployment tool from MRSK to Kamal. Rails 7.1 will have a new `capture_emails` help that's quite a bit more elegant, check it out.Rails World ticket giveawayFrom MRSK to KamalNew capture_emails test helper

Aja Hammerly, Developer Relations Manager at Google Cloud, joins Corey on Screaming in the Cloud to discuss her unexpected career journey at Google and what she's learned about improving the developer experience throughout her career. Aja and Corey discuss the importance of not only creating tools for developers that are intuitive and easy to adopt, but also cater to different learning styles. Aja describes why it's so important to respond with curiosity when a user does something seemingly random within a piece of software, and also reveals why she feels so strongly about the principle of least surprise when it comes to the developer experience. About AjaAja lives in Seattle where's she's a Developer Relations Manager at Google. She's currently excited about developer experience, software supply chain security, and becoming a better manager and mentor. In her free time she enjoys skiing, kayaking, cooking, knitting, and spending long hours in the garden.Links Referenced: Google Cloud: http://cloud.google.com/developers Personal Website: https://www.thagomizer.com TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn and I am joined today by Aja Hammerly, who's a Developer Relations Manager over at a small company called Google Cloud. Aja, thank you for joining me.Aja: Thank you for having me. I've been looking forward to this for quite a while.Corey: You have been at Google for, well, let's call it eons because that's more or less how it feels when you're coming from my position of being great at getting yourself fired from various companies as a core skill. How long have you been there now? And what is your trajectory been like over that time?Aja: So, I've been in there a little over eight years. And the funny part of that is that it was intended to be a two-year gig for me. I moved from consulting developer working on, you know, building out websites for other people to Google's like, “Hey, you want to do this advocacy [unintelligible 00:01:19] relations thing?” And I'm like, “Sure.” And at the time, I'm like, there's no way I'm going to last more than two, three years in this. I hadn't really held the job much longer than that.Turns out, I like it. And then they're like, “Hey, do you want to manage people doing this job?” And I'm like, “That sounds like fun. Let's try that.” And it turns out, I like that just as much if not more. Because I haven't picked a major in tech yet and so managing people doing a bunch of different things is a fantastic way for me to keep my squirrel brain engaged in all the different topics and, you know, always bouncing around. So, it's been great. Cloud's been—well, I started, Cloud was very, very, very small back in 2014 compared to what it is now. Google Cloud is way bigger.Corey: Google Cloud, if you take a look at its entire portfolio, I'm probably one of the only people in the world who looks at it and says, “Yeah, that seems like a reasonably small number of services,” just because I eat, sleep, and breathe in the firehose of AWS announcing every feature as a service. But let's be clear here, Google Cloud is fairly broad in terms of what it does and what it offers. Where do you start and where do you stop? Because increasingly, the idea of, “Oh, I am responsible for talking about everything that Google Cloud does,” is a—it's clearly a fantasy.Aja: Yeah. No, there's too much for any one person to be an expert on. I could give you a list of products, but that's not interesting, quite frankly, because I would prefer that people don't think about it as a set of products. Because—Corey: Why is this such a rare perspective to have? It drives me nuts whenever I go to a cloud conference, and okay, here's the database track, and here's the container track, and here's the storage track. It doesn't matter if I'm building Hello World, let alone anything more complicated. I have to think about all of it.Aja: Yeah. So, I don't know why it's a rare perspective, but at least within my—the folks that I look up to, the folks that I consider mentors internally, we tend to think more about audiences or problems. And the problem that I care the most about—I cared about this well before Google, and Google just pays me to care about it, which is awesome—I care about developers. I one hundred percent want to help people build cool stuff, ideally efficiently, as quickly as possible.I worked at a startup and as part of that experience, I learned that sometimes you just need to get something out quick. I wanted tools that would let me do that. When I worked in consulting, the whole gig was to get something out quick that folks could look at, folks could touch, then we could do feedback, we could iterate, we could come back. And so, I want to make developers successful and I want to get out of their way. And I've always liked tools like that as a developer; I don't want to have to read your 10,000-page manual in order to learn your product.So, when I come to Google Cloud, I'm focused on the products that help developers build stuff quickly. And by developers, I mean, developers. I mean, the people who are hands-on-keyboard with Python, with Go, with Java, building it out features for their employer or, you know—Corey: What about really crappy bash? Does that count?Aja: Sure. If you're going to build some sort of application, a really crappy bash. Awesome.Corey: You'd be surprised. My primary development stack usually is a combination of brute force and enthusiasm.Aja: Yeah. Honestly, there are days that I feel that way, too. And I was working on some demo stuff over the weekend and I'm like, “Well, I could sit down and actually read this code or I could just run it, fix the first bug, and then run it again and fix the next bug. Yeah, let's do it that way.” Brute force is fine.Corey: I think the iterative development.Aja: Yeah, iterative development and/or brute force. Whatever. It works. And, you know, if people want to build cool stuff, cool. Let's help them do that. That's what I get to do every day is figure out how I can make it easier for developers to build cool stuff.Corey: The thing that keeps confusing me, for lack of a better term, is that I see a bunch of companies talking in similar directions of, “Yeah, we want to talk to developers and we want to meet them across the stack about the problems they're having.” “Great, so what's your answer?” And then they immediately devolve it into industry verticals. As if the finance company is going to have problems that the healthcare company could never fathom happening. It's, you get that you to look an awful lot alike, right, and things that work for one of you are going to map them at least 80, if not 90 percent of what the other is doing? But nope, nope, completely separate audiences; completely separate approaches. And I find myself increasingly skeptical about that model.Aja: Yes. I think—I see that too. I have sometimes behave that way. And I think it's because… it's a combination of factors. One is people want to believe that their problems are unique and special. I've worked in edtech, I've worked on real estate stuff, I've worked in… a lot of different fields. As I said, haven't picked a major over my career.I've done a lot of different jobs, worked on a lot of different fields. I have passing knowledge of the electrical industry from an early, early job. And yeah, it's all code. At the end of the day, it's all code. But people like to believe that their problems are unique and special because they want to be unique and special. And cool. People can be unique and special. I am there to support that.I also think that different altitudes see the problems differently. So, if you're someone fairly high up and you're at a healthcare company versus a finance company, you're going to be thinking about things like your different regulatory requirements, your different security requirements. And some of those are going to be imposed by you by law, some of those are going to be imposed by you by your company policies, ethics, I would hope. But if you're the actual developer, I need to store some stuff in a database. Like, down at the lower level where you're actually writing code, getting your hands on keyboard, getting dirty, the problems all start looking roughly the same after a while.And so, you need different people to tell those stories to the different audiences because the higher level folks thinking about regulatory requirements or thinking about efficiencies, they're going to just have a different perspective than the folks I like to go chat with who are the ones banging out features.Corey: I'll take it one step further. Whenever I'm building something and I'm Googling around and talking to people in the community about how to do a certain thing and everyone looks at me like I've lost it, that is a great early warning sign that maybe I'm not doing something the right way. Now, yes, the ultimate product that I'm developing at the end of the day, maybe that's going to be different and differentiated—or at least funnier in my case—but the idea of, well, then I need to write that value back to a database, and people look at me like, “Writing data to a database? Why would you do such a thing?” Like, that's an indication that I might be somewhat misaligned somewhere.The other failure mode, of course, is when you start Googling around—because that's what we do when we're trying to figure out how to do something with a given service—and the only people ever talking about that service are the company who has built that thing. That's also not a great sign. There, at least for my purposes, needs to be a critical mass of community around a particular product where I can at least be somewhat reassured that I'm not going to be out twisting in the wind as the only customer of this thing.Aja: Yeah. No, a hundred percent agree as someone who's, in past lives, evaluated, you know, which APIs, which products, which companies we're going to work with. Having really great developer docs, having really great materials was always important. And I don't tend to read docs, so when I say materials, I like stuff that's interactive because I'm just going to dive in and fix the issues later. That's just how my brain works.But you know, people are different. Everyone has different learning preferences. But if there is a community, that means that you have lots of ways to get help. And you know, super concretely, I'm not a Kubernetes expert, I did some talks on it back in 2015 when it was brand new and shiny, I can use it and understand it, but I'm not an expert. I have other people on my team who have had the time to go deep.When I need help with Kubernetes, even though I work at Google, I've actually gone to my local community. I go to my local DevOps Slack, or I go to my local Kubernetes groups and stuff to get help. And I like that because it gives me all those different perspectives. I also know that if I'm asking you a question that no one understands—and I've had that experience [laugh] numerous times—either I'm doing something wrong, or the actual thing that I found more often is I'm explaining it in words that people don't understand. And that's always a challenge is figuring out the right words to go search for, the right phrasing of something so that everyone else understands the terms you're using. And that's a huge challenge, especially for folks that don't speak English as their primary language or their first language. Because we have lots of different ways to say the same thing, especially when it comes to code.Corey: I've noticed that. There are almost too many ways to do certain things, and they're all terrible and different ways, let's be clear. But that does mean that whenever I'm trying to find something that's 90% done on GitHub or whatnot, I will often find something that fits pretty well, and it's, “Well, I guess I'm learning TypeScript today because that's”—Aja: Yep.Corey: —“What it's written in,” versus building it in the language I have a bit more familiarity with, like, you know, crappy bash.Aja: Yep. Nope, I think that's a problem that anyone who's been developing on a deadline or, you know, spending a lot of time doing proof-of-concept stuff is super familiar with. And I think sometimes folks who haven't worked in those environments, at least not recently, forget that that's our reality. Like, “Cool. Okay, I guess today I'm learning Elastic,” was definitely a day I had when I was consulting. Or, “Cool. Okay. Swift is new”—because that's how long ago that was—“I guess we're all learning swift this afternoon.”Corey: I've been banging on for a fair bit now about the value of developer experience from my point of view. But given that you work with developers all the time, I'm betting a you have a more evolved position on it than I do, which distills down to, the better the developer experience, the happier I am, which is generally not something you can measure super effectively. Where do you stand on the topic?Aja: So, this is one of my passion points. I feel very strongly that tools should fit the workflows that developers have; developers shouldn't alter themselves to work toward their tools. I also think there's kind of a misunderstanding of the nature of developer experience that I've seen, especially from some of… a lot of different companies. Developer experience is not actually tools. Developer experience is the experience you as a developer have while using those tools.So, APIs: I like things that don't have surprises; I like things to get out of my way. I know that we joke about there being 9000 ways to run containers, or you know, five different ways to do this other thing, but you know, if that means it's faster to get something done, and you know, most of those are equally bad or equally good, I'm okay with it because it gets out of my way, and lets me ship the thing I want to ship. I enjoy coding; I think computers are rad, but what I enjoy more is having something finished that I can show to other people, that I can use, that I can make better. So, some of the things I feel super strongly about with developer experience is principle of least surprise. I was a Rubyist for years and years and years.Haven't written a lot of Ruby the last two, three years—management, I'll do that to you—but… I loved that once you understood some of the underlying concepts behind Ruby, stuff generally worked the way you expected. I know a lot of people find the very nature of Ruby surprising, but for those of us who learned it, stuff generally worked the way I expected. So, I like it when APIs do that. I like it when it's super easy to guess. Consistent naming schemes, you know?If you're going to call… you're going to call the way to list a set of services ‘list' in one place, don't call it ‘directory' in another. Keep things consistent. I like it when APIs and the cloud companies all—I've had many thoughts about all of the big cloud companies in this—when their APIs that they provide a fit the language. If you're making me write TypeScript like C because your APIs are really just designed by C programmers and you've loosely skinned them, that's not a great experience, that's not going to make me happy, it's going to slow me down. And quite frankly, my tools should speed me up, not slow me down. And that's kind of the underlying theme behind all of my feelings about developer experience is, I don't want to be angry when I'm writing code unless I'm angry at myself because I can't stop writing bugs.Corey: I don't really want to bias for that one either, personally.Aja: Yeah. And then the other one is, I don't want my tools to be something that I have to learn as a thing. I don't want there to have to be a multi-week experience of learning this particular API. Because that is interesting, potentially, but I'm not being paid to learn an API, I'm being paid to get something done. So, all of the learning of the API needs to be in service of getting something done, so it should go as quickly as possible. Stuff should just work the way I expect it.We're never going to do that. This I acknowledge. No company is ever going to get that right no matter where I work because turns out, everyone's brains are different. We all have different expectations. But we can get closer. We can talk to folks, we can do UX studies. Everyone thinks about UI and UX and design is very much focused on the visual.And one of the things I've learned since I've had the opportunity to hang out with some really amazing UX folks at Google—because big companies have advantages like that, you have lots of people doing UX—is that they can actually help us with our command line interfaces, they can help us with how we name things in an API, they can do studies on that and turn, you know, “It feels good,” into numbers. And that is fascinating to me and I think something that a lot of developers who are building tools for other developers don't realize is actually up there as an option.I spend a lot of time reading UX studies on developer experience. Managers working at big companies, you get to have access to data like that going back years. And I've spent a lot of time reading about this because I want to understand how we turn, “Feels good,” into something that we can develop against, that we can design against, and we can measure.Corey: One of the things that I've always viewed as something of a… a smell or a sign that ‘Here Be Dragons' are when I'm looking for a tool to solve a problem and there's a vendor in the space, great, awesome, terrific. Someone has devoted a lot of energy and effort to it. I want the problem solved; I don't necessarily need to do it for free or cheap. But I'm looking through their website and they talk about how awesome their training programs are and here's how you can sign up for a four-day course, and et cetera, et cetera, et cetera. That feels to me like in most cases, someone has bungled the interface. If I need to spend weeks on end learning how a particular tool works in order to be effective with it, on some level, you reach a point, fairly quickly for anything small, where the cure is worse than the disease.Aja: Yep. This is an interesting thing for me because I, my personal feelings are very similar to yours. I don't want to take a class. Like, if I have to take a class, we have failed. I don't really want to read extensive documentation.I want to get in, get dirty, try it, see, you know, watch the errors, come back and learn from the errors, that kind of thing. If there's code to read and it's a language, I know, I will actually often go read code as opposed to reading docs, which… is weird. The interesting thing to me is that, as I've managed folks, as I've, you know, spent time working with customers, working with folks who I, you know, think would benefit from some of Google Cloud's products, there are some folks who really, really want that formal training, they want that multi-day course before they dig in. And so, while in the past, I definitely would have agreed with you, if it's the only thing, maybe, but if it's one of many different ways to get started, I just keep telling myself, “Hey, that's how someone else needs to learn this.” Isn't my preference, but my preference isn't necessarily better.It's just, this is the brain I got and the tools that came with it. And it doesn't do well for four days in a classroom learning all of the intricacies of this because I need to learn this stuff in context, otherwise, it doesn't stick. Whereas I have people that work for me, I've had people who I've worked with who are like, “No, I actually need to go read the book.” And I'm like, “Let's make sure that there's both a book.”Corey: Everyone learns differently.Aja: Yeah. I just constantly reminding myself, both as a manager and also as someone who works in developer relations, all of the above is the correct option for how are we going to teach this? How are we going to help people? We really need to offer as much as possible all of the above because we need to be able to reach everyone in a way that works for them.Corey: It's the height of hubris to believe that everyone thinks, processes, learns, et cetera, the same way that you do. This is a weird confession for someone who hosts a podcast. I don't learn very well by listening to podcasts. I find that when I'm trying to absorb something if I can read it, it sticks with me in a way that listening to something or even watching a video doesn't.Aja: Yeah, and I'm actually very much the opposite. I take most of my information and learn best through hearing things. So, while I don't particularly like watching video, relatively often, I'll actually have video if I'm just doing like email or something running in the background and I'm listening to the audio as I'm learning the concepts. I adore learning stuff from podcasts, I love audiobooks, but I don't retain stuff as well when I read it. And it's just because, you know, human beings are interesting and weird and not consistent, in all sorts of delightful and confusing ways.Which, you know, as an engineer sometimes drives me nuts because I really wish there was one right way to do stuff that worked for everyone, but there just isn't. There are all sorts of interesting problems. And just like there are multiple valid ways to solve problems, there are multiple valid ways to learn, and we have to support all of them. And we have to support engineers with all of those styles too. People often will say, “Oh, sure. There's lots of learning, different learning styles, but you know, most engineers are like X.” No. There is no ‘most engineers.'Corey: Early on in my career, one of the things I noticed—in myself as well, let's be clear here, I was no saint—that, oh, if people don't learn the way that I learned, then clearly they're deficient in some way. Of course that's not true. Everyone learns differently. And that, among other things, was part of the reason that I stopped being as dismissive as I was about certifications, for example, or signing up for a planned classroom experience. There is tremendous value to folks who learn well from that type of structured learning.I am just barely contained chaos. And for whatever reason, that doesn't resonate with me in the same way. If anything, I'm the one that's broken. The trick is, is making sure that when you're trying to drive adoption, no matter what method people learn best from, you need to be there with something that approximates that. One area that I think resonates with something you said earlier is this idea that the best way for me to learn something, at least is to sit down and build something with it. Bar none, that's what I actually want to experience. And that is only slightly informed by the unfortunate reality that I've been through too many cycles of an exec in a keynote getting on stage and making grandiose promises that the service does not backup.Aja: Yep. And I actually do have a bias here that I will own. I don't believe in anything until I can touch it. And by ‘touch it,' I mean, use it. And that also includes I don't believe in my own learning or the learning of others until I can see it practically applied.And so, even when I have folks on my team who are like, “Hey, I want to go read a book, take a class,” I'm like, “Cool. What else are you going to do with that? How are you going to know that you can actually take what you learned and apply it to a novel situation?” And this has been based on mentors I had early in my career who I'm like, “Hey, I just read this book.” And they're like, “That's awesome. Can you write anything with what you learned?”And I'm like, “Yes. Let me do that and prove it to myself.” So, I do have a bias there. I also have a bias, having worked in the industry for 20-plus years now, that a lot of people say a lot of things that are either theoretically true or true through, you know, a happy path lens. And I started my career as a tester and compu—I always joke computers run in fear of me because if there's a way to cause something to error out in a confusing and unknown way, I will find it. I will find it on accident. And when I can't find it on accident, I will find it on purpose.So, that's the other reason I don't believe stuff until I touch it. It doesn't matter if it's at a keynote, doesn't matter if it's a blog post, I want to know that this works beyond that happy case that you just showed me. And part of this is also that I've built some of those keynote demos and I know that they're explicitly designed so that we can fit in the timeframe allowed to avoid any possible dragons that might be lurking in the background. So, I always go get dirty with things, new products, new features. It's one of the things I actually love about my job is I get to try stuff before anyone else does.And I'm like, “Hey, so, um… I did this thing. You probably didn't expect anyone to do this thing, but I did this thing. Can we talk about whether this thing that I did is actually a valid use case? Because it made sense to me, but you know, I might have been thinking about this backwards, upside down, in purple, so let's back the truck up and have a discussion.”Corey: Yeah, I get to moonlight occasionally as something that looks vaguely like an analyst at a variety of different companies. And as a part of that, I'm often kicking the tires on something that they're going to be releasing soon. And a very common failure mode is that, for obvious reasons, no one has ever really looked at this thing from the perspective of I've never seen this before or heard of this before. Let me approach this as someone who's learning about it for the first time. The documentation is always treated as an afterthought at those stages where it's, “Oh yeah, just spin it up and do it. And you do the thing that we all know about, right?” “Well, okay, assume I don't have that shared understanding. What's the experience?” And, “Oh.” Yeah, if I'm not on the path of a few pre-planned test cases, then everything falls off pretty quickly. I think I share that somewhat special ability to cause chaos and destruction to all about me [laugh] when I start trying to do something in good faith on the computer.Aja: Yeah. No, it's both a blessing and a curse. It's really annoying when like, I managed to brick my work laptop on the morning that I have, you know, a super important talk and I call up, you know, internal tech support at Google and they're like, “You did what, and how?” But it's also great because I know that… I know that I get to—because I started my career in tests working at other companies, I've always done some informal testing no matter where I've worked, everything I find we at least know about, even if we don't have time to fix it. We at least know about it, so if someone else runs into it, we can at least help them untangle whatever crazy stuff they did.And I'm also just not afraid of breaking computers either, which means that I'm very willing to go off happy paths. If I see a tutorial that's close, you know, if all of the steps that work, and I'll guess on the others. And that's a thing that I don't actually see a ton of folks being always willing to do because they're afraid of breaking it. And I'm like, “It's software.”Corey: And a lot of products are designed though, that once you deviate from the happy path, well, now you've broken it and you get to keep all the pieces. There's little attention paid towards, okay, now you've done something else and you're bringing something back into the happy path. It feels like if you haven't been here for every step of the way, well, your problem now. I have work to do. Go away kids, you're bothering me.Aja: Yeah, I've seen that. And I've seen that open-source frameworks, too, when people—when I talk about, you know, deviating from the happy path—and this will date me—using multiple databases with Rails was one of the ones that I ran into numerous times. Just was not designed for that in the beginning. Did not work. There was also some easy security stuff, ages and ages ago, that you often wanted to do, but was not at that point integrated into the framework, so it was clunky.And so, anyone would come to, like, a Ruby meetup or something like, “Hey, I want to use three databases with my Rails application,” we'd be like, “So, you can… but you may not actually want to do it that way. Can we interest you in some microservices so that you can go one-to-one?” And that wasn't always the right choice. I worked on an app for years that had multiple databases in Rails, one was a data warehouse, one was our production database. And it was clunky.And eventually, you know, the Rails community got better. Eventually, people do improve, but people are weird. They do weird things. Like, and I don't think people truly understand that. One of my jobs at various points was I was working in education tech and I was working on an application for kindergarteners.And I don't have kids, but I think kindergarteners are just [unintelligible 00:24:44]. And until you see five-year-olds use software, I don't think people get a true appreciation for how random human beings can actually be when given a textbox or when given a mouse. And, like, we like to think that, you know, engineers and adults are better. We're not. We just, you know, have a different set of five-year-old tools available to us.So, we do have to at least acknowledge that people are going to go do weird stuff. And some of that weird stuff probably makes sense in the context they're living in, and so, the best step is not to say, “Hey, stop doing weird stuff.” The best thing to then say is, “Okay, why did you do it that way?” Because everyone has good reasons for the decisions they make most of the time. And understanding those is important.Corey: Yeah. It's very rare—not entirely unheard of, but at least rare—that when someone shows up and says, “Okay, I'm making a bunch of choices today. What are the worst ones I can possibly make that I'm going to be tripping over for the next five years and leave is my eternal legacy to every engineer who ever works at this company after I do?” But it happens all the time, for better or worse.Aja: Yeah.Corey: Never intentional, but it always hits us.Aja: Yeah. Well, one of the things that I learned in the last-ten ish years, and one of the things that I tried to bring to all of my developer relations, all my developer education work, is, “It made sense at the time.” Now, it may have been that they made a assumption six years ago, that led them down the path of chaos and sadness and now that they're deep into this, they're going to have to back up to that decision six years ago and undo it. But based on the knowledge they had, the assumptions they were making—which may or may not have been true, but you know, were likely made in good faith—they're doing their best. And even when that's not true, I haven't found a situation where, assuming that with regards to technical decisions is harmful.Assume that people are relatively intelligent. They may not have the time to go learn all of your tools, the intricacies and use things exactly the way that you want them to be used because time is a limited resource, but assume that they're relatively intelligent and they're doing their best. And then try to understand why. What assumptions, what skills, what previous knowledge led them down this crazy path? And you know, then you can start having a conversation about okay, well, what should the tools do? How should the tools work together? Just because I wouldn't make that decision doesn't mean that their version of it is necessarily bad. It may not be the most efficient way to get stuff done, but if it works, eh, okay.Corey: So, as we wind up coming towards the end of this episode, one thing that I want to explore a little bit is, you've been with Google Cloud for eight years now. How have you seen the organization evolve during that time? Because from my perspective, back then it was oh, “Google has a cloud? Yeah, I guess they do.” It's a very different story, but all of my perspective is external. How have you seen it?Aja: Oh, that's an interesting question. And I'll caveat that appropriately with I only see the parts I see. One of the hard parts of big companies is, I don't actually dig in on some of the areas particularly deeply. I don't go deep on data analytics, I don't go deep on AI/ML. And I will also [laugh] own the fact that when I started, I'm like, “Oh, Google has a cloud? Huh. Okay, yeah, sure, I'll work on that.”I didn't even know the list of products my first day. I knew about App Engine and I knew that it didn't work with my preferred languages so I had a sad. Some of the things that I've seen. I've seen a real focus on how we can help people with real big problems. I've seen a real focus on listening to customers that I really like.I've learned a lot of techniques that we've been shared out, things like empathy sessions, friction logging. If you're not with the community of developer relations about how we make sure that, as an engineering team, we're thinking about real customer problems. I've seen a lot of maturing thoughts around how we maintain products; how we make sure that we've got updates where we need them, as much as we can; how we talk about our products; how we listen to customers and take, you know, direct feature requests from them.The other big thing is, I've just seen us grow. And that's the big thing is that there's just so many more people than when I started. And I've never worked at a company this big before and just getting my head around the number of people who are actively trying to make cloud better, and spending every day doing their best to improve the products, to add the features that are missing, to make sure that we're keeping stuff up to date where we can, it's kind of mind-boggling. Like, when I go look at the org chart, I'm like, “Wait, there are how many people working on what?” And that in and of itself is a story because that, to me at least shows that we care about getting it right. Google cares about getting it right.I'm not Google, of course, but I feel like from the inside, I can say that Google cares about getting it right as much as we can. And you know, sometimes it's not a hundred percent what people want, which is why we iterate. But we've also had a couple of things that I'm particularly happy with Cloud Run, I think landed pretty well.Corey: I'd say that I would agree with what you're saying. I've had nothing but positive experiences when I've been building admittedly very small-scale shitposting-style stuff on top of Google Cloud. There have been times where the biggest criticism I have is, “It's not the particular flavor of broken that I'm used to coming from AWS-land.” But that's hardly a fair criticism. I think that by and large, it is a superior platform coming from the perspective of developer experience.And people don't like it when I say that and they often like it even less when I say, “And thus, it has better security than something that does not have better user experience because simplicity is everything in that space.” But it's true. It is foundationally and fundamentally true.Aja: I agree with you. Obviously, it's my employer. But I do think you actually were onto something interesting with, “My particular flavor of broken.” I've talked to a lot of folks who are migrating and sometimes they struggle because there are particular magic incantations or other things that they learn to work with a different tool. It's the same thing is when you're learning a new language, a new programming language, or a new framework. You're like, “Wait, I don't have to do this thing. But I'm really good at doing that thing.”And so, I do think there is to some degree, everything—nothing's perfect and it happens to be, you know, it's hard for some folks. And I think some folks resist the better developer experience because it isn't what they're used to. And that's okay, too. Like, if I was a developer, I wouldn't want to have to relearn everything from scratch, so I get that and I think that that is a valid piece of feedback.[unintelligible 00:31:22] it make it familiar to folks working from other clouds, we're working on it. There's stuff coming out of DevRel. There's other things that we do to try to make it easier. But no, I do think, and I'm very grateful I get to work with a lot of teams to do this, we want to make developers like working with Google Cloud. I want to make developers like working with Google Cloud.Like, at the end of the day, if I had to say the most important thing for me is I want to make developers enjoy their time using Google Cloud to get other stuff done. I don't need to live in a world of people who are like, “You know, I really just want to go spend some time on Google Cloud today,” but I want it to be something that they enjoy using or at least gets out of their way, out their way to doing the stuff that they actually want to do: you know, add features, build shitposting websites, whatever it ends up being.Corey: As someone who does an awful lot of that, thanks. It's appreciated. I really want to thank you for spending so much time talking to me. If people want to learn more, where's the best place to find you?Aja: Oh. That's the best place to find me right now is www.thagomizer.com. Thagomizer is the spiky part of the end—at the end—Corey: Of a Stegosaurus.Aja: —of a Stegosaurus.Corey: Yes.Aja: It is. That is my website and it has my most recent social, et cetera on it. That's also where I theoretically blog, although it's been about a year. I've got, as I said, as I mentioned before the show, I've got several blog posts three-quarters of the way done that I'm going to hopefully try to get out over the next couple of weeks… on various topics.Corey: I have a pile of those myself, that for some reason, it never quite ends up happening when you hope it will.Aja: Yeah, exactly.Corey: And we'll, of course, put links to all of that in the [show notes 00:32:47]. Thank you so much for being so generous with explaining your point of view I appreciate it.Aja: Yeah. And thank you for having me. This was lovely.Corey: Likewise. Aja Hammerly, Developer Relations Manager at Google Cloud. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice along with an angry comment telling me exactly which four-week course I need to sign up for to understand that comment.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.

Welcome to Remote Ruby and thanks for joining us!  It's Jason and Andrew today and do they have so much to talk about. RailsConf 2023 is coming up, Andrew booked his flight and lodging early, Jason announces he's doing a podcast with Brittany while they're there, and the guys discuss how their ADHD is so different from each other.  Then they discuss npx, the benefits of using it, and how it can be useful in Ruby.  Jason and Andrew talk about building user interfaces in Ruby, creating games with DragonRuby, learning Rust and Python for hardware projects, and using OpenAI API for Ai projects. We'll also hear about their programming backgrounds, not liking math, regrets about not taking a statistics class seriously, and experiences with other college classes. Press download now to hear more!  [00:04:19] The guys are excited to go to RailsConf but Jason's feeling socially anxious since he had surgery. [00:06:03] Andrew explains what Hashnode is since Jason has no idea what it is.[00:06:28] In the wonderful world of Ruby, Andrew's been scripting lately since he wanted to have fun, and if you don't know what npx is, he explains what it is. Jason and Andrew also discuss using npx with Tailwind and esbuild, [00:11:09] Jason brings up using standards VS Code extension and mentions how surprisingly fast it is.[00:13:35] Jason mentions Nick Schwaderer taking on building a new Shoes project, which was a GUI graphic user interface library for Ruby, built by, why the lucky stiff. It looks like their using WebView, and if anyone can explain it, please Tweet Andrew on Twitter or message him on discord. [00:15:17] The guys talk about building user interfaces in Ruby, creating games with DragonRuby, and a Tweet by Amir Rajan about DragonRuby.[00:20:35] Jason tells us about trying to learn Rust and Python for hardware projects, and Andrew tells us about a widget he built using Rubyist.[00:22:28] There's a discussion on using OpenAI API, Andrew has an interest in creating a profitable business with web3 technology and AI, Jason mentions “Ask Rails,” an Open AI powered chat to help you with all things Ruby on Rails.[00:25:42] The conversation shifts to Jason and Andrew's programming backgrounds and their interest in using Ruby for hardware projects. [00:29:34] Have you heard of PicoRuby? Also, if you know mRuby, please reach out to Jason or Andrew because they need to talk to you.[00:31:50] Andrew was asked to be a Guide at RailsConf, saw the email too late, and he's not doing it because of his commitment issues.[00:34:37] Jason and Andrew discuss their rabbit holes. One is about a speech professor, the other is being back on Khan Academy filling gaps in math knowledge, and regrets about not taking statistics class seriously and other classes.   Panelists:Jason CharnesAndrew MasonSponsor:HoneybadgerLinks:Jason Charnes TwitterChris Oliver TwitterAndrew Mason TwitterRailsConf 2023HashnodeAmir Rajan TwitterDragonRubyAsk Railsnpx-GitHubSearls After Dark #1-ChatJPN (YouTube)ShoesRubyistOpenAI APIPicoRuby-GitHubRuby Radar TwitterRuby for All Podcast

Robby has a chat with Andy Croll (he/him/his), the CTO at CoverageBook, a Rubyist, the Organizer of the Brighton Ruby Conference, an author, speaker, and bootstrapper. The most important thing when it comes to the maintainability of software is “That code is read much more than it's written”, Andy says. He insists that the core focus should always be on readability. Andy will dive into the rationale for why weird things in our code should stay weird until we find a better way to express it and even shared some specific examples within a Ruby on Rails environment. He will share his career journey from the front end into the backend, what prompted him to start the First Ruby Friend project to connect newcomers to a community with people who want to be mentors, examples of how to manage technical debt in a small team and why it's okay to let some stuff "sit in the air", and so much more. Stay tuned. It's going to be an epic one.Book Recommendations:The Overstory by Richard PowersHelpful Links:Andy's websiteOne Ruby ThingBrighton RubyFirst Ruby FriendSubscribe to Maintainable on:Apple PodcastsOvercastSpotifyOr search "Maintainable" wherever you stream your podcasts.Join the discussion in the Maintainable Discord Community

In this tour-de-force, Mike Dalessio – Engineering Director at Shopify – and Evan Phoenix – self-described “long-time Rubyist” – join us for a practical discussion of all things Ruby! Ruby is a beautiful language, and we're really excited to cover the history and present of this language with two experts. 00:01:03 Introductions00:01:49 Mike's Ruby journey00:12:28 Evan's own Ruby experience00:18:20 The pickaxe book00:20:34 Weird programming interests00:25:11 MINASWAN00:30:33 Language conferences00:36:38 Wrong answers on StackOverflow00:41:53 RubyCentral00:44:50 In-depth examination of Ruby00:47:57 How Shopify sticks to vanilla Rails00:50:28 A tale of two developers00:59:59 Bringing Ruby up to Python's level01:04:48 Shopify's largest app monolith01:11:12 Tuning the knobs01:18:01 How not to learn the hard way01:18:57 Opportunities at Shopify01:29:14 Working with the RubyShield program01:32:07 Rails for API servers01:33:21 Mike and Evan's advice for listeners01:36:00 FarewellsResources mentioned in this episode:Links: RubyCentral: Website: https://rubycentral.org/ RubyShield: https://rubycentral.org/ruby-shield Twitter: https://twitter.com/rubycentralorg Shopify: Website: https://www.shopify.com/ Careers: https://www.shopify.com/careers Dev Degree Program: https://devdegree.ca/pages/program HashiCorp Website: https://www.hashicorp.com/ Careers: https://www.hashicorp.com/jobs Mike Dalessio: Website: http://mike.daless.io/ Twitter: https://twitter.com/flavorjones Evan Phoenix: Website: https://github.com/evanphx Twitter: https://twitter.com/evanphx RubyConf 2022 (Nov. 29 – Dec. 1, 2022):Website: https://rubyconf.org/ Other Episodes:Episode 47: RubyShow Link: https://www.programmingthrowdown.com/2015/10/episode-47-ruby.html  References:“The Pickaxe Book” aka Programming Ruby: The Pragmatic Programmer's Guide 2nd Edition:Amazon: https://www.amazon.com/Programming-Ruby-Pragmatic-Programmers-Second/dp/0974514055  If you've enjoyed this episode, you can listen to more on Programming Throwdown's website: https://www.programmingthrowdown.com/ Reach out to us via email: programmingthrowdown@gmail.com You can also follow Programming Throwdown on Facebook | Apple Podcasts | Spotify | Player.FM  Join the discussion on our DiscordHelp support Programming Throwdown through our Patreon ★ Support this podcast on Patreon ★

Chris is helping with efforts to introduce security, practices, and policies at Sagewell. Right now, they are refining the usage of 1Password to standardize passwords and secure information. He also shares (what he believes) is a terrible idea around fixing inconsistencies around symbols and strings. Steph shares an update around factories. Also, at Sagewell, Chris is helping to build mobile apps, one for iOS and one for Android, and is considering pursuing having them be all native. Good idea? Terrible idea? Chris and Steph riff on that a bit. This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy. Services down? New Relic (https://newrelic.com/bikeshed) offers full stack visibility with 16 different monitoring products in a single platform. GitHub - alassek/activerecord-pg_enum (https://github.com/alassek/activerecord-pg_enum): Integrate PostgreSQL's enumerated types with the Rails enum feature Feature #7792: Make symbols and strings the same thing (https://bugs.ruby-lang.org/issues/7792) - Ruby master - Ruby Issue Tracking System RailsConf 2016 - Turbolinks 5: I Can't Believe It's Not Native! by Sam Stephenson (https://www.youtube.com/watch?v=SWEts0rlezA) GitHub - hotwired/turbo-ios (https://github.com/hotwired/turbo-ios): iOS framework for making Turbo native apps Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! Transcript: CHRIS: Weird stuff happens when we sing, Steph. STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari. CHRIS: And I'm Chris Toomey. STEPH: And together, we're here to share a bit of what we've learned along the way. So, hey, Chris, what's new in your world? CHRIS: Hello, Steph. What is new in my world? We are continuing with some of the efforts that we're doing to introduce security, and practices, and policies, and all those fun sorts of things at the organization. One of the things that this is pushing on is we are further refining our usage of 1Password at the company as a way to standardize passwords and secure information and how we store that, how we move it around, as well as integrating SSL, and all those other fun fancier things. But I'm personally historically a LastPass user, and now I'm getting to experience 1Password. So now I'm a child of two worlds, and it's terrible, and I hate it. I hate every moment of this existence. So what I need to do is move over to 1Password, but now I'm in that space where I'm like, I can see the flaws of both systems. This is terrible. I don't like it. 1Password does seem to be great; I will say that. There's one really interesting thing about 1Password. I'm interested...you're a 1Password user, right? STEPH: I'm not; I use LastPass. I'm also a child of two worlds because we use 1Password for thoughtbot stuff, but then I use LastPass for my stuff. CHRIS: Gotcha. Okay, so you survive in the middle space. I'm slowly trying to move everything over because I think 1Password has a little bit more of what I'm going for. And I would like, frankly, to be in one cohesive, consistent space, although having two different accounts seems interesting. I definitely can handle it. But knowing which I'm in and how to save a password to one versus the other, it's a whole thing. The one thing that I find really interesting though is 1Password has a feature where it will do two-factor, two-factor authentication. It will do that for you. Specifically, it's doing, as far as I can tell, the TOTP. I don't know what that acronym stands for, but it's the fancy type of two-factor, so not SMS, not text message-based, and not others like WebAuthn is a thing that I've heard of, which I don't know if that is distinct from YubiKey or hardware keys. So there's a bunch I'm trying to learn about this space a little bit more. I'm very interested in the hardware keys because those seem cool. WebAuthn seems like a new standard. That sounds cool. Don't know anything about it, though. So mostly, I know about SMS, and I do not like that one. I do not want to use text messages because, as far as I understand it, they're not super secure. So that's not the space I want to be in. But the TOTP, the Google Authenticator, or Authy, or that space of password or two-factor code generation tools those seem good. And 1Password has a feature where they're like, hey, yeah, sure, we'll have your password and your two-factor. And so they grab the QR code, which is typically the QR code is a way, as far as I understand it, to share the seed. And then, that seed is used by an algorithm to generate the current code value for a given point in time. So it takes like, given that seed and the current timestamp, we will generate you the relevant code, which can then be verified on the far side. But that seed only exists for one moment in time, et cetera, et cetera. But I've always thought of it as this separate thing. The idea of having that all in one system is interesting and kind of scary to me. But as I think about it, I'm like, if 1Password or LastPass, in either case, gets compromised, we're all done. Like, this is over. We should throw in our cards, give away the internet. This whole experiment has failed is my sense. But it was very interesting because I had not seen this. I've always had these as separate systems. So for me, I have had LastPass, and I have Authy on my phone for the two-factor. But it's frankly very clunky, and I don't like it. And the 1Password thing is fantastic where I say like, yeah, 1Password, fill in my password and username, and then also fill in my two-factor because you have it. This is great. But, and this is where I hesitate, and I don't know, I will say this: I trust that 1Password has thought about this deeply way more than I can and have come to a place of deep confidence that this is a fine and okay thing to do. But I'm still intrigued. What's going on here? STEPH: That was a lot. I have so many thoughts. [laughs] CHRIS: Sorry, that was a lot of words, a lot of ideas, a lot of space there. It's just where I'm at. STEPH: People couldn't hear me, but I was laughing when you were talking about LastPass or if these accounts get hacked in. And I'm imagining someone who uses the combination of their cat's name and their birthday as their password and then like, aha, I win. [laughs] It's like, no, we just all lose. [laughs] But that amused me. Going back, you talked about having it all in one place. And that actually doesn't surprise me that we're different in this area. Because you also like all of your email...you like one source of everything, which makes so much sense, but I'm different. And with these accounts, I like that I have the distinction between all of thoughtbot is in 1Password while all of mine is in LastPass because it's just a very clear delineation between those two accounts. And I'm sure both of these platforms have figured out a really good way to then separate those two. But I just remembered there was someone at thoughtbot that accidentally...because they have everything in 1Password, they accidentally shared their personal vault with a client. And so they were just typing in Slack. They're like, "Oh, shit, oh shit, like, how do I undo this?" And we're all just watching like, "We don't know. But please let us know how it turns out." [laughs] It turned out fine. I think they actually realized they hadn't fully shared it but based on the UI they thought that they had. So it all turned out okay. So that just lives with me. I'm a little scared of that now now that I know that story. So watch out, friends. CHRIS: Oh, wow. Well, now, yeah, I'm also now scared of that. I wasn't, but now I am. STEPH: And I forgot the other thoughts now. Those were my two main thoughts based on the journey that you've shared. CHRIS: Particular to the thing you were sharing there, yes, now I will have nightmares about it. But also, it feels manageable because they're both entirely different accounts, and then also within that, there are different vaults. So as I'm building up the password infrastructure at Sagewell, there's going to be different...like, the dev team will probably have one vault and then a shared vault for the dev team. And then other teams within the organization will have that. And so it feels like there are at least structures within the tool to manage that. But mostly, my consideration is around the two-factor thing. And like, is this reasonable to do? And again, I'm sure 1Password has thought way harder than I have about it. And I trust that they're like, yeah, this seems fine that they're not just like, I don't know, it doesn't seem bad. They're like, no, no, definitively for information-theoretic reasons, this is fine. But it was surprising. STEPH: That was it. The other comment that you made about two-factor auth that resonated with me because there was a point not that long ago where we have one of those, either New Relic or I forget which account it was, but it was with the systems. We really only needed one person to have access, but every now and then, someone else may need to access that account. And so we wanted to be able to store it in 1Password or LastPass somewhere like that. But then the two-factor auth was a problem because then you had to coordinate with that other person to say, "Hey, I just need to check something. Would you let me in?" And because we could then leverage that feature, then we could just store all of it. And then that person could just go to 1Password or LastPass and then have access to all of it, and that was really nice. That was a very nice solution to I want to say it was a small problem but yet also very important for team happiness. So that was really nice. CHRIS: The amount of times that I've been like, "I just tried to sign in to the shared account, and it says that it sent a two-factor request to somebody's phone, but it didn't tell me whose phone. And I'm not sure if we know who that person is or if that person's still around," that version of the story feels true. And so, the idea of being able to centralize two-factor seems great. It almost feels too good to be true, is perhaps where I'm at. I am putting on my tinfoil hat, and I'm saying, yeah, but oh man, security, though. And again, I will 100% defer to 1Password on this. They've thought about it. But it's mostly I want to get to the place where I understand the thought process that they went through to decide that this is perfectly fine because they definitely did that work. I'm certain of that. I just want to read a white paper or something, and I haven't found it yet. [laughs] I'm like, let me get to that deep place of trust because that's what I want to be at with security tooling and those sorts of things. STEPH: Yeah, I haven't looked for something like that, but that sounds...I'm kind of surprised that doesn't exist. CHRIS: Oh, it quite possibly exists. I haven't done much of a search, frankly, at all. Mostly, I'm in the space of like, huh, that's weird and then moving on with my day. Because there's not a lot of free time to go search for the white papers on the internet. But yeah, so moving from 1Password or LastPass or 1Password, or maybe I'll just end up with both for a while. I really hope I don't end up in that space, although you're describing it as a positive, so maybe I will. STEPH: I have found it helpful for me. When you find that white paper, because you are more likely the type of person to read that white paper than I am the type of person to read it, then I would love a summary. That would be much appreciated. CHRIS: I'm so intrigued by the persona that you're describing of me of; like, you're the kind of person who would read a white paper. I'm like, well, I don't know if that feels true or if it's definitely true or definitely not true. But if I do happen to find it, and especially if I happen to read it, [laughs], I will share it with you and perhaps with the listeners as well. Let's see, one other small thing. I have a bad idea. I don't want to share the bad idea with you. I want to more share it with the audience, and then I want the audience to tell me exactly how bad of an idea it is. STEPH: [laughs] CHRIS: Because I'm sure it's a bad idea. I'm just not sure how bad. STEPH: I love that there's not even a scale of goodness here. It's just nope, this is terrible, but I don't know how terrible it is. [laughs] CHRIS: What's fun is in the later parts of this episode, we're going to go into a segment of good idea, bad idea, sorry, good idea, terrible idea because I like that framing. No, this one is firmly bad idea, but how bad is the question. So we're working on the app, and we keep running into inconsistencies around symbols and strings. As any Rubyist who has worked in the language for any amount of time, especially in a Rails app, you have experienced this unpleasantness. There are strings; there are symbols. They're often used somewhat interchangeably, and yet they're different. You'll hit bugs. You'll hit edge cases. You'll hit nils that you didn't expect to be there because you tried to fetch a symbol. It, in fact, was a string, et cetera. So, what if we just applied HashWithIndifferentAccess everywhere, just deep in the internals of the app or in the Ruby runtime? What if we were to just turn this on? My sense is this would be terrible for performance reasons. My understanding is that's why symbols exist is because they are a more performant mechanism. Strings are complicated within the object model of Ruby because they're mutable. These are things that I understand very loosely, as you can tell by the tone of voice that I'm using. But symbols and strings they're separate. They're separate for reasons, performance I believe to be the main reason. But what if we were to just say, well, what if it could be like easy, though? That's what I want. Like, this is the promise of Ruby is that I want to express my code in a way that feels like the words I would use to describe to another human. That's the way I always think of Ruby is it's as close to the words I would use to describe the sort of business logic as possible. And yet these symbols versus strings thing it's just annoying, frankly. And again, I think very good reasons for it, I'm sure. But what if we were to just do the silly thing and turn on HashWithIndifferentAccess for everything? I don't even know that that's fundamentally possible. I don't know that there's the relevant hook or the way to do that. But I would love that because we're using it somewhat regularly throughout our app right now, where we're getting data from one API. And in our test suite, it's one way, and in our code, it's the other way. And granted, that speaks to us being inconsistent in our usage. But overall, I would just love for this to not be a thing. And so, how bad of an idea would it be? How much of a performance hit? That's my guess as to what it would be. Maybe there's actual fundamental correctness that would go wrong here. But my sense is by collapsing the space together; we would actually get more correct. I don't know. Anyway, how bad do you think of an idea this is? STEPH: I was thinking through some of the bugs that you're running into. And I think you provided some nice insight around that around it's the fact that you're fetching data from API. So it's typically you're parsing. That's how you're getting the string and symbol differences is because when you're parsing JSON and then you have a mixed case of maybe you have a symbol, maybe you have a string, or maybe you're parsing it differently. Are there other places in the application where that's a concern? CHRIS: I want to say one other place that we're running into it specifically is we're using a lot of enums, particularly ActiveRecord::PGEnum backed enums. So these are Postgres enums at the database level. And then, within our Rails models, we define them as enums. And the enum is typically defined within the model as a mapping of symbol to string. It could be symbol to symbol. I'm not even sure. I think this might be in terms of our implementation. But you say like, it's an enum. The key is foobar with an underscore, and it's a symbol, and then the value is foobar, but it's a string. And maybe both the key and the value could be symbols; maybe that's a thing, maybe this is our fault. But certain times, when you're interacting with the value, it's a symbol. Certain times I find it to be a string. I feel like that's true. I don't think I'm making that up. [laughs] It's possible I'm making it up. But that's another place where I feel that inconsistency or other values within the system that like as they go through certain type coercion layers, they'll start as a symbol, and then they get saved to the database, and then they get reflected back, and they come back as a string. And it's like, well, that's unfortunate. It was a symbol a minute ago, and now it's a string. And so our tests suddenly break in this way, or our code is inconsistent. And it's enough of a nuisance that I had the bad idea the other day. And so, I wanted to bring the bad idea to this space. STEPH: I think you're right. I think the main reasoning for not having everything just be strings is for looking for that performance benefit. And so then using that HashWithIndifferentAccess then you'd have to loop over everything and then convert it. So I imagine, like you said, there would be a performance hit there. I don't know how bad of an idea it would be. But when you said this, it brought up a memory because I remember someone proposing or the Ruby community talking about the fact, like, what if we didn't have strings? What if everything was just a symbol? Or can we just have one over the other? And there is a ruby-lang issue; it is 7792. And we shall also put it in the show notes and send it to you. [chuckles] And this person is proposing make symbols and strings the same thing. And then some people call out specifically the idea of using HashWithIndifferentAccess and saying, yes, that works wonderfully, but then you are going to have a performance hit for it. So it sounds exactly like everything you're saying. I don't know the outcome. I mean, clearly, the outcome is we're not there. But it seems like a really good place to see the reasoning or different approaches that maybe people have tried in this space. CHRIS: Ooh, I love that. I definitely want to read that and see what sort of deeper thinking folks have done on this. Because again, this feels like another one where definitely folks have thought about this, folks who know more about it and have chosen the current path that we're on for reasons. But I would be really intrigued if I could be like, yeah, I would just like it to be easy to start, and then have the performance optimization be something that I could opt into. Again, that's probably not tractable within the language. Like, oh, we have a hot code path here that we want to actually have immutable symbols only. And that's the sort of thing if we've done this HashWithIndifferentAccess everywhere, you can't back out of it. And so, therefore, you're stuck in a performance low point. That feels like a bad case. And so maybe that's the reason is like, you will shoot yourself in the foot with this definitely. But yeah, I'm intrigued. So I will definitely read what you're sharing here. And we'll include it in the show notes, of course. I'm probably not going to do this, just saying that out loud because it seems like a bad idea. I just want to know how bad of an idea. STEPH: I do love it, for when I'm building a class that's working specifically closely with an API, I do reach for HashWithIndifferentAccess frequently. Because like you said, I just don't want to worry about it. I want to set it up top. It's one of the rare times that I actually will use something in an initializer where I'm like, hey, pass in the data. I'm just going to run it through this method. And then all the data from here on forward you can access it in either way. So the class doesn't have to care; a tester doesn't have to care. So I do feel your pain, or I at least will always reach for it whenever I'm building a class specifically around interactions with JSON. CHRIS: So for a segment that I framed as how terrible of an idea this is, you're like, hmm, I don't know how terrible. That seems to be your take, which is interesting. STEPH: Good point. Let me assess for a moment. I'm going to go just from skimming this issue, although I think partially this issue is talking about the fact that if you merge symbols and strings, it's like, hey, friend, you're going to break a ton of stuff and break a bunch of libraries, and these two things do serve a purpose. So this may not be exactly what you're looking for, but it has some interesting conversation on there. But embedding it deep down in the app so that just happens naturally sounds like it's just a performance concern. So yeah, it comes down to what is the question? How big is the performance? So I feel like I can't say it's a terrible idea until I actually know what the performance hit is. CHRIS: So a plausible question. That's where we're going to put this in the category of. [laughter] STEPH: Plausibly terrible, but still worth researching. CHRIS: Not obviously not terrible. But anyway, these are some of the ideas at the top of my head right now. That's a rough summary of my week. Mid-roll Ad Hey, friends, let's take a quick break to hear from today's sponsor, New Relic. All right, so you've probably experienced this before where you're just starting to fall asleep, and it's a calm, code-free peaceful sleep, and then you're jolted awake by an emergency page. It's your night on call, and something is wrong. But I have some good news because you have New Relic, which means you can quickly run down the incident checklist and find that problem. So let's see, our real user monitoring metrics look good. And that's where New Relic measures the speed and performance of your end-users as they navigate the site. But it looks like there's an error in application performance monitoring. If we click on the error, we can find the deployment marker where it all began, roll back the change, and, ooh, problem is solved. We can go back to bed, back to sleep, and back to happy. That's the power of combining 16 different monitoring products into one platform. You can pinpoint issues down to the line of code so you know exactly why the problem happened and can resolve it quickly. That's why more than 14,000 other companies, including GitHub and Epic Games, use New Relic to improve their software. So you know that next late-night call is just waiting to happen, so get New Relic before it does. And you can get access to the whole New Relic platform and 100 gigabytes of data free forever. No credit card required. Sign up at newrelic.com/bikeshed. That's newrelic N-E-W-R-E-L-I-C .com/bikeshed, newrelic.com/bikeshed. STEPH: I have an update that I can share around factories because the last time we were chatting, I was sharing that strategy that we're pursuing where we're trying to minimize factories and then speed up the CI time by reducing the work that those factories are doing. So Joël Quenneville has done some phenomenal work and this past week, specifically improving factories. And he found one particular factory that he was digging into. So some stats before the change. The factory was taking around two seconds, which I know on paper doesn't sound so bad, but it gets more interesting. So total database time is around 1,000 milliseconds. And 833 total database queries were being made, which includes reads, creates, and updates. So then after, Joël was diving into this looking mainly to reduce the number of database queries because that's such a big number. So after the change, which took a lot of research on Joël's part, the factory is now taking around one second, so half of that time. The total database time is around 666 milliseconds. And the total database queries went from 833 down to 647, so a nice improvement there. But the real wonderful outcome of the story is not just those stats, but okay, so how did we impact CI? So we spent time working on this factory. And we have reduced, and we can see some of that in the stats. But how does that apply to the bigger picture? And so Joël took the time of the last 20 successful builds, and based on those builds, we average 27 minutes and 37 seconds for each build. With the factory change that he made, that same test suite was now averaging 21 minutes and 33 seconds. So shaved off six minutes from the build time, which is about a 22% decrease in the build time which is just fabulous. So that was a really nice win from all the work that had been invested in improving that one factory. CHRIS: That's a heck of a haircut there so glad to see that the efforts are paying off. STEPH: Yeah, it was a really nice win to see that we had researched which factories we should pursue, and then we were methodical about that. And then Joël worked hard to improve this factory and saw such a large payoff. It's one of those areas where the team has already invested a lot of effort and hours into improving the test suite. And it's challenging when you have so many areas that you'd like to improve and 100-plus engineers also contributing to that same codebase. So how do you improve and keep up with it all at once? They had spent about a year, so I think they were recognizing that yes, there are still a lot of areas to improve but also felt like small efforts wouldn't move the needle. So it was a nice data point to remind ourselves that we can still reduce the CI build time in a significant way. We just need to be very strategic about where we invest our time in those improvements. There is also an interesting conversation that Joël and I were having because we have a daily sync with each other each day. We've now been embedded with a team with a client, which is wonderful, but before then, we were also chatting with each other. And we like to chat about code, so we've had lots of fun conversations around code. And one, in particular, this week, came up about how people view code differently. And there's even a tweet that Joël shared that I can link to in the show notes. And there's one view that code is a liability, and if a line can't justify its existence, then it should be deleted. And then there's another view that code is an asset. If a line isn't causing any immediate issues, then why not keep it? And part of the reason that came up was while I was going through and reading pull requests, there was a particular change where someone was memoizing an expensive call, which was great, something that we wanted to do. But then they were also memoizing a very fast operation in two other places where it was just like parsing some params something that, you know, superfast and only getting called in maybe two places. And it was one of those that just caught my attention to be like, hey, I love that you memoized this other call, but this one, I don't think we need the additional overhead or complexity of adding memoization. And I found myself when I was writing that suggestion for the author that I was already looking for more than just to say, like, hey, this is more than we need. Because I've realized that often I take that stance of code is a liability. So if we don't need it, let's just get rid of it. But I've definitely run into other people where they're like, well, it's not hurting anything, so why can't I just leave it? And getting that kind of pushback on suggestions about removing code. So it was a fun opportunity to think through okay, well, why is this memoization not just unnecessary, but how could it actually cause us problems? And what's the cost of keeping it in, not just the cost of removing it but also the cost of keeping it in? And that was fun to talk about. CHRIS: I'm so glad you're bringing this particular conversation up because if we're being honest, I saw Joël tweeted about this. I saw it. I sent an email to myself linking to the tweet with the subject of the email being ahhhh, just A-H-H-H-H, which I believe was me being like, oh my God, we got to talk about this. I apparently didn't want to write all of those words, so I just wrote ahhhh. But as a handful of asides, one, if you're not following Joël Quenneville on Twitter, @joelquen, that is a mistake, because Joël is one of the clearest, most concise, and effective thinkers about code that I've ever seen. The writing that Joël produces is absolutely fantastic. And having worked with Joël for forever, I still will look at his Twitter feed and be like, well, this is fantastic. You're saying amazing things that I have not heard you say. So, again, strongest recommendation I can make; please follow Joël on Twitter and also via the Giant Robots blog and all of those other places. But in particular, I saw this one come through, and I was like, oh, man, we have to talk about this. So I actually have it up in my email app right now behind the scenes. [laughs] I was like, oh, I want to mention this to you, Steph. So I'm very excited that you're bringing it up in this moment. It is such an interesting thing. It's such an interesting case of like; I deeply believe both of these truths, and yet they do seem to be in contradiction. And so what do we do with that? More generally, I feel like that's true of a lot of stuff in life, like, the ability to hold two competing ideas in your head and be able to know where one applies and where one doesn't. That is a critical thing to get to in life and to figure out how to do, and that's some of the hard work of thinking. But in particular, this one, the idea that code is a liability. You have a line of code...I'm going to read it precisely as Joël wrote it, "Code is a liability. If a line can't justify its existence, it should be deleted. Code is an asset. If a line isn't causing any immediate issues, why not keep it?" And I think for me, if I were to try and interpret this, because I do believe both of those sides, I would apply one during code review. When code is coming into the application or when I'm writing code, do I need this? Do we need this? Is this necessary? Because it really should be necessary to come into the app. But then once something has made it in, especially the longer something's been in there, I think code sort of ages and matures. And so, the longer it's been part of the app and not causing an issue, the more I am liable to just leave it at rest. Just say, sure, or not at rest but as part of the runtime production code. But these are two competing ideas, but I think they apply at different times in the conversation. And so I'm definitely on memoization. In particular, memoization is a form of caching. Caching I have run into a handful of caching bugs in my life, let me tell you. I'll probably run into a few more. So if we can avoid caching, let's do that. So that's a particular question around that thing. But again, that idea of like the point in time to have that conversation is during code review or initial authoring or when it's about to come into the app. But if we've had some memoization in the app for forever and you're like, do we need this memoization? I don't know, but don't remove it because maybe it's very important at this point. Maybe it's one of the cornerstones holding up our application. So that's a bunch of thoughts about that. But also super glad that you brought this up because I was very excited about this particular tweet. STEPH: Yeah, there's someone that said something very similar to what you just said around they agree with number one for all new code. And they agree with number two, where code is an asset for refactoring. And I thought, yep, that's a great way to look at it. And I hadn't really thought about that specific perspective. And so it was one of those moments. Because I do like when people will push back on something that I so firmly believe on, not that this person did. I was, frankly, having a conversation with myself based on previous conversations with other pull requests authors that I've had that it's not related to this particular pull request. But in general, when people do push back on something that I do have such a firm belief in...and early eager optimization around memoization is something that I'm just like, I don't want to do it, especially for something that's so cheap and in such a fast execution and something that we're only calling twice. There's no benefit to it at that point. But then when someone says, "Well, but it's not hurting anything," then I appreciate that question because then it's more of not just pushback, but it's sort of well, tell me more. What is the pain that I'm introducing by keeping this in? And then that can be a really nice conversation to have with someone around; like you just said, I've seen caching bugs, and this could be a caching bug, and they are painful to then triage. And so we've introduced this optimization, but it's actually just going to cause us debugging pain later. And we really didn't even get the reward from it in the first place. So I really like those conversations when I feel like there's a little bit of a challenge of where I'm like, oh, I hold this as a deep truth, and somebody doesn't, and I would like to have that conversation with them. There are also some other fun conversations; one was around introducing a query object, which, as you know, we're both really big fans of. And then there was another great question because not everybody who works on this team is really familiar with Ruby and RSpec. They work in Scala, but then sometimes they hop over to the Ruby side. And so then they hop into the Ruby channels, and they're asking questions. And one of them was around the idea of introducing an RSpec Matcher. And they're like, "Am I doing this right? Is this how you would extract something to then improve your test? " And so that was a really fun conversation around like, yes, you did it right. This is exactly how you write a Matcher. But let's talk about use cases because extracting something to an RSpec Matcher to me means it meets the most generalized sense of usefulness that you want the whole team to use this and that you're willing to put in the extra overhead to then introduce this essentially like new RSpec DSL for the rest of the team to use and then maintain that. So it is the most aggressive step that I take when I'm trying to introduce a helpful tool. So then I shared my progression for when I'm extracting something for a test. And first, I will start with just a local method to that test because then it's scoped to just that test. And from there, then I will think about extracting to a shared helper. So maybe it's a module that can get included. But then its scope can still be confined to a couple of tests, but then we've also increased some of its observability. So then other developers will notice it and be able to share with it. And then from there, if I'm like, oh, this is super generic, it is testing time, and it's something that everybody is going to benefit from, then I reach for something like an RSpec Matcher or introducing a custom RSpec Matcher. So lots of fun testing conversations this week. CHRIS: That was a wonderful hierarchy. I like that a lot. I feel like that would make a good blog post. STEPH: There are some things that I realize that I just think of inherently about that I realize that would be fun to share. I'm much better at podcasting than I am at blog posting. [laughs] CHRIS: There's this friend I know, Joël Quenneville, very good at the blogging. He could probably help talk you through writing this up as a quick blog post. But you just described this heuristic hierarchy that you have. And you could probably provide quick examples of each, and I think encapsulate that knowledge. I, too, default to podcasting because it's easy for me to just say stuff here, and then it's there it is. But what you just said also mirrors exactly what I would think of as sort of the hierarchy and the reasons you're like, I'm not sure I'd go all the way to an RSpec Matcher. That hesitation is meaningful and comes from experience that you've had. And again, that seems sort of a trade-off of like, well, why not? Is it hurting anyone? What's the cost here? You know that cost. You have that in your head. And so now if you can capture...I don't want to put work on your plate. But I think that would be a great blog post. I would be happy to read that blog post and share it with other folks. STEPH: Cool, cool. Cool. So I totally hear you. So here's my hierarchy. Typically, I start with a podcast, and then I share it there. And then maybe it'll go to a tweet. And then once I'm like, okay, this is super generic, it can help everybody, then we've reached blog post status. CHRIS: I love how tweet is higher in the hierarchy than a podcast for you. That somehow the throw away let me just have 140 characters or 280, or whatever we're at these days, that somehow that's next in your hierarchy. But I agree; I share that place in the world. STEPH: Yeah, just writing is hard. Here I get to show up, and I say things. And then we have wonderful Mandy, who is then editing all of our words, so there's a safety net here. If it's just me and a keyboard, who knows what's going to happen? CHRIS: Then you'll probably think about the switches that you're using on the keyboard. And do you need a new keyboard? Should it be silent? What do we do? STEPH: I was thinking more how many exclamation marks do you use? That's always a question. CHRIS: Not too many, not too few. It's a difficult question. STEPH: [laughs] Mid-roll Ad Hi, friends, and now a quick break to hear from today's sponsor, Scout APM. Scout APM is an application performance monitoring tool that's designed to help developers find and fix performance issues quickly. With an intuitive user interface, Scout will tie bottlenecks to source code, so you can quickly pinpoint and resolve performance abnormalities like N+1 queries, slow database queries, and memory bloat. Scout also recently implemented external service monitoring, adding even more granularity when it comes to HTTP requests and API calls. So give Scout a try today with a free 14-day trial and experience first-hand why developers worldwide call Scout their best friend. And as an added bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. To learn more, visit scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. STEPH: Pivoting just a bit, [laughs] what else is going on in your world? CHRIS: What else is going on in my world? So we are building out a whole platform over here at Sagewell, and one of the things that we need to build is a mobile app or, frankly, two mobile apps, one for iOS and one for Android. And I'll be honest; I resisted this for a while. I am a big, big believer in the web as a platform like deeply in my heart of hearts. That's the place that I want to spend my time. That's the thing that I believe in. And there are absolutely cases where truly native mobile apps shine, completely outshine what we can do on the web platform sometimes for reasons that are, I think, not great, limitations of the available mobile web platforms, et cetera, reasons that I'll slam my fist on the table or whatever it is. But there are plenty of really great mobile experiences, offline, et cetera, that we just can't...offline is not even a great example. See, I can't even find a great example. There are definitely things, though, where truly native mobile apps are 100% superior. But again, I'm such a big fan of the web platform that that's what I wanted to do. I wanted to hold on to this dream of, like, what if we just make a really great web app and it's just great? And then consistently, our backend is one singular thing. Our frontend is kind of one singular thing. And yeah, we got to deal with responsive design. But that's to me a much more tractable problem than fracturing our entire application architecture across a bunch of different platforms and having all of the logic of our domain splintered and especially depending on how you implement it. That's sort of a big question. I've talked a ton about Inertia.js on this podcast, and that's because I believe it's a really great example as to how to pull some of the logic back to the server-side, which, in my experience, that's where I want the logic to be implemented, our deep domain logic. I just want that to be on my server in a Rails controller, or a Rails model, or a command object, or any of those sorts of things, query objects, all of these wonderful things but server-side that's centralized in one space. Nonetheless, though, we had to build a mobile app. These are the truths of the world. Sometimes it just comes down to the expectation of your user base. And there are certain things that by building a mobile app we will get so, for instance, in our case, having biometric login, so fingerprint, or facial ID, or any of those sorts of things. Those are actually material security differences. They are actually, as far as I can tell, available on the web but not consistently on every browser, et cetera. So that's something that we can get by having our app as a native app. Push notifications is another one that certain platforms, certain web platforms have dragged their feet on, Apple Safari. iOS Safari, specifically, I'm looking at you, but that's an example of something that by going the truly native route, we'll get that. Similarly, access to some of the lower-level things, cameras, et cetera, that is something that we'll get a better experience of. And again, you can hear in my voice I don't want to really seed it to the native platform, but it is true right now, at a minimum. So we had a decision to make as to how we would implement these applications, and we went with an interesting route. So for anyone that's familiar with Turbolinks native, or I believe Turbo iOS is pretty similar. But I'm more familiar with Turbolinks native as there was a talk I Can't Believe It's Not Native I think is the name of the talk that was given a while back talking about the Turbolinks native architecture. So basically, what's happening under the hood is let's still render these things server-side. Let's send down some HTML. In our case, it's a weird sort of hybrid of HTML and not HTML. But broadly, let's say that the server is rendering things. And our native application is going to then be a native shell that wraps around WebViews. But it does so in not just a single WebView sort of way. It's instead trying to find that optimum hybrid spot where let's do native things where they make sense. So, for instance, we have introduced a tab bar at the bottom of our application that is a truly native UI. We similarly have push notifications, biometric login, et cetera. Those are features of the native platform that we're using. But then, for most of the screens, most of the screens that are just some text, maybe a button, maybe a form, et cetera, we are using the server-rendered code that we have. And so server-rendered, in our case, because we're Inertia, it's sort of a misnomer because technically it is being rendered on the client-side in the WebView. But, I don't know; we're now getting too nuanced and in the weeds for it. But what we've opted for is to reuse the same views, controllers, et cetera. All of that is still being reused. Our iOS and our Android codebase at this point are wrappers around those WebView stacks. So it's not just a singular WebView; it's a stack of WebViews. So if you're doing swipe to navigate thing on iOS, that'll work...or Android. I think Android has an actual back button, though, within the applications. But most importantly, we've introduced a tiny little bridge layer. So from our WebViews, we can communicate to the wrapping native context. And similarly, from our native context, we can send messages into our WebView. So we can have a button in our native UI. And when a user clicks that button, it will send a message to the WebView that it's wrapping around and vice versa. We can do push notifications. We can do all that sort of stuff. For any given view, like, say, the login view, we can say, "Hey, don't render the normal server-side thing. Instead, render this truly native, local Swift or Kotlin view that we want to use there." So it's an interesting choice. I think it's something that I've certainly seen applications that are just like, let's take some HTML and wrap it in a WebView, and it'll be fine. And they don't make great apps. But I think this time it might just be a good idea. I actually do think that the approach that we're taking, at a minimum, is buying us a ton of simplicity in terms of having to duplicate what are somewhat nascent domain concepts across multiple platforms. We're not entirely certain as to what our platform and what our business is going to be. So we'd love to non-enshrine that across three different platforms that are hard to update. Like the web, I can kind of change that every day. But iOS and Android because I have to go through review cycles, because I have to get them out to devices, because there are slow update cycles that individuals will use, I'm going to be stuck supporting whatever version of these applications are out there. And so if more of that is the dynamic content that's driven by the server, frankly, I just feel way better about that, at least for now, at least for the point in time that we're at. But I kind of believe that this may be a really useful architecture for us long term. That was a bunch of me rambling about the architecture. Let me pause there, thoughts, questions, comments, concerns? STEPH: First, I really appreciate the thoughtful approach and explanation. Also, you highlighted the reasons that y'all are pursuing having a native app, and all of that makes a lot of sense. Because there is that user expectation of you told me about a service that then there must be an app that I can download because that's what I'm accustomed to using versus having to go to a browser and then having to then remember the URL of the site that I'm supposed to go to. So there's that convenience factor. There's also the idea that some people go to the App Store and search for their solutions instead of going to a browser and searching for a service. So having that presence in the App Store can seem like a really huge win because then even if it maybe slowly pushes them back to use the website or as long as they get a decent experience, they've now at least been exposed to the idea of the service and that it's out there. But then, as you pointed out, building a mobile native application is a lot of work. And then it becomes a question of like, well, are you going to hire people to work specifically on these platforms? And then, is it really worth that investment at this point? Or is it worth the approach that you're taking where you're going the more hybrid approach? I am curious; maybe this is something that you'll know. So as you are investing in this hybrid approach and you are starting to collect more users that are then using the app versus going to the browser, then what does that pivot look like, or how does that further investment look like? If you realize that the UI isn't quite delivering the expectations that you want that if you'd actually built a native iOS or Android application, then what does that investment look like? Can you still reuse some of the work that you've done? Is it totally scrapping that work? I think that would be my biggest question around taking this first approach. Is it an all-in bet that we are now stuck to this? Or is there some salvageable pieces to then move this forward into native apps should we need to do that? CHRIS: That's a heck of a question. Have you made a terrible decision or just like an iffy decision? I think that the framework that we're choosing or, frankly, building right now will actually be amenable to a potential transition entirely into the native world in the future. So again, one of the options that we have here is the ability to say, no; this facet of the application is entirely native. We're going to opt-in. And so it actually happens at the navigation layer. So we can say, if a person transitions to the /user/signin route, instead of just rendering that WebView right in place, push a native Swift or Kotlin. Depending on the context that we're in or the platform that we're in, push the native view onto the stack and use that. And so we're able to, on a screen-by-screen basis, make a decision of no, we'd like to opt into native behavior here. And so, if we did eventually see that the vast majority of the users of the platform are using it via the native app, we should probably continue to invest in that and push in that direction. I think we could do it in sort of a gradual style, and that is critically important to me. I don't want to make a big bet and then be like, oh no, we got to rewrite from the ground up. And there's no way to do that incrementally. It's going to be a whiz-bang Friday launch that everyone's going to hate. That's the thing I want to avoid most in the world. And so I think what we found now is this seems great for right now because it allows us to avoid this complexity explosion of three different platforms and trying to keep them in sync and trying to keep them up to date. But it does, I think, give us an opportunity as we move forward to slowly sort of transition things over. We are, to state it, this isn't just like wrapping a WebView around things. We are building essentially a mini framework on both iOS and Android, or roughly Swift and Kotlin is what the actual languages are, to work with Inertia because inertia is the core technology that we're using. Inertia, thankfully, has a nice little event system in there, so we can say, Inertia on navigate. And when a navigate event happens, we can hook into that and then connect it to whatever Swift or Kotlin runtime that we're building here. And there are a couple of different events that we can opt into. And so that's giving us the hooks that we need in the current architecture. But longer-term, if we needed to, we could just, I think, slowly transition everything over to be truly native mobile, and then that would probably be backed by more traditional API endpoints and that sort of thing. I want to avoid that. That's my dream is to stay in this happy place where we're always going to need some web presence. And I would hate for those to be fractured distinct things. I've worked with enough mobile apps that are wonderful native experiences, and yet I'm like, could you just give me the desktop view? Just scaled to...like, I'll even pinch and zoom because you're hiding data from me, and that makes me very, very sad. Please give me the buttons, and the text, and the content that you would give me on the web. And the fact that you're not is just breaking my heart right now. And, frankly, for our user base, consistency of experience is something that I think is really important. So that's another facet of the conversation that is really interesting to me of like; I don't want it to be different on each platform. Certainly, a three-column layout doesn't work on an iOS app that is zoomed in 150%. But we can turn that into each column is just floated down and then otherwise have all the content in there. And I believe in that as sort of a fundamental truth of let's reshape the content but not fundamentally rethink it. I say that as something that I believed deeply. But as I said it out loud, I was like, yeah, but also, I don't know, make it work on the platform it's on. So I can see both sides. But I have had enough experiences personally where I'm sad about the app that I'm using. STEPH: Yeah, I could also see an argument for both ways where you don't want it to be fundamentally different, but then also, you want it to fit the platform. And then there may be some advantages to the fact that there is a different platform, and you want to utilize that. I also agree with the not hiding of the data. I have felt that pain where I have an app, but I really want to go to my desktop, and I really want to use it there. But then on mobile, it's then hiding, and I realize it's hiding. And that inconsistency really frustrates the heck out of me. So I can understand that as well. Overall, I really like this. You're taking a bet in a direction of we should have a mobile presence, and we should start attracting people through this new marketplace. But we want to reuse a lot of the logic that we already have before we go so far as then we're going to have to start building for each different platform. Because while I don't have a lot of experience in that area, the times that I have been part of teams that are building native apps, it's a big investment. I mean, they hire people very focused on that; designers have to design for browser, for mobile, and then for native, and then everything has to stay in sync across. You have to think about how a feature is going to work across all three of those different views. And so it is certainly not something to go into lightly, which I think is exactly what you're describing is that you're looking for that in-between to how can we start working our way in this direction but yet also do it in a way that we're reusing a lot of the work that we have versus having to invest full sail into then building out these different platforms? So I'm going to go with this is not a terrible idea. [chuckles] I'm excited to see how it feels once I can download this and check it out. I'm excited to then see how that feels from a UX perspective. But overall, everything you're saying really jives with me. It makes a lot of sense. I am curious, what about React Native? Is that something that you considered using? CHRIS: Oh yeah, great question and definitely something that we considered. We're not using React on the backend, so that was actually a consideration when I was thinking about Svelte initially is I assumed we'd be building a React Native app eventually for the native platforms. But I talked myself into Svelte for the web, and that is not the reason that we're not using React Native for the native apps. But it is an interesting sort of constellation of technologies that we have now. We're not using React Native because I'm clinging to this idea of what if we could have a singular experience? So React Native fundamentally you're building a native app that this is this bundle that you download that's got all of the UI and that front-end logic in that bundle that you download. And then when it wakes up, it makes some calls back to some APIs to get some data or to decide if I can do an action or to actually do an action, all those sorts of things. But you're building out a Rest or GraphQL or one of those APIs. And with my explorations of Inertia, I found that what if I didn't need to do that? What if I could do a more traditional Rails CRUD-like experience but CRUD in a good way (I mean it in the very positive sense of the familiar architecture) and still give users a delightful experience but not have to build a distinct API where all of the or majority of the logic was on our client-side? So if I did that, then my web client would need to be that much smarter. And each of the iOS and Android clients would need to be that much smarter because that's fundamentally how these technologies work. UI components they can give a higher fidelity experience, more native-like experience, but they tend to own a lot more of the smarts. And one of my core beliefs is however long I can get away with this, I want to keep as much intelligence on the server as possible and have my view layer be as minimal and as simple as possible. So I think React Native is a really fantastic technology for that sort of work. But my goal was to avoid that sort of work entirely. What if we had a singular way that we had the logic exist on the server-side, and then we rendered pretty minimal view layers? Or, from a user experience, the view should do all this stuff and show all of the things that they want. But I want that view layer to be as naive as possible. And by naive, I mean in the positive sense of like, I want to be able to change this very rapidly. I want to be able to evolve it and iterate it. And so this is more of a buy into I think the thing that Inertia gave me is valuable enough and if I can keep using that and reuse it, especially on these mobile platforms...now if we add a new fundamental part of our Sagewell platform, if we have that, it just exists on each of the iOS, the Android, and the web, and that's fantastic. And we're going to keep a really close eye on what experience that gives to the user. And is it still great? But presuming it is, the complexity savings there are so huge. Our team is a team of web developers that is able to think about things holistically and singularly. We implement it once within our stack, and it just works. And if we can do that, that is worth a ton. We may not be able to do that forever. But for now, especially while we're figuring things out, while we're super early on as a company, I think that savings and complexity is worth a lot. So it'll be interesting to see how it plays out, and will certainly report back. But I'm a big believer in this little adventure we're on. STEPH: Yeah, you said it perfectly there at the end; you're a team of web developers. And so as long as you can stick to that, then that's what's best for y'all and the team and the product. So that's wonderful. I have a short segue because I had a little bit of inspiration when we were talking about terrible ideas. I want to circle back to your other terrible idea because I have a terrible idea for your terrible idea about strings and symbols. Okay, so my terrible idea is you're talking about using HashWithIndifferentAccess for everything. What if you had a class or method that then will first try to access via string and if that fails, access via symbol, and then if that fails, then it fails loudly? So you now have this let's try this, and then let's try the next thing. I have strong feelings about this as I'm saying it. CHRIS: [laughs] STEPH: But we're in the terrible idea segment, so I'm going to embrace it. This is my terrible idea. CHRIS: HashWithIndifferentAccess with runtime exceptions. I think HashWithIndifferentAccess under the hood probably does what you're describing of, like checks one and then checks the other or checks has_key is probably the underlying implementation. I haven't actually looked at it. But some version of that makes sense. Falling back to the key error gets interesting. I did see a different thing recently of a deep fetch, which is something that I want, to stop trying to make fetch happen, except I'm going to try and make fetch happen. We thought about this a bunch where we have these objects that we need to traverse into. So we use dig to get into the third layer of the object, but dig doesn't care. And it's just going to happily nil out whatever. So I'm like, no, dig but then right at the end, fetch, deep fetch. I saw somebody post this recently. So deep fetch is something I want to make happen. HashWithIndifferentAccess, which raises at the end also intriguing. STEPH: So yes, but this will be a little different because this one, you don't have to do the transformation process upfront with HashWithIndifferentAccess where you have to pass the data first, and then it transforms it so then it can do these two different lookups or the fallback. This one, you're skipping the transformation process, and you're using your own custom method that then does that first check for a string or first check for a symbol and then default back to the other one and then fail loudly, yeah, if both of those fail. CHRIS: Interesting, and I have to see what it looks like in practice. But I mean, broadly, I'm into something in this space. Let us find some simplicity. That is what I want. STEPH: Let's find some terribleness and see which one feels not so terrible. [laughs] CHRIS: Some terrible simplicity. Well, I like that idea. We'll see where we get to with it. But I think on that note, and we've said a bunch of stuff today, should we wrap up? STEPH: Let's wrap up. CHRIS: The show notes for this episode can be found at bikeshed.fm. STEPH: This show is produced and edited by Mandy Moore. CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. CHRIS: And I'm @christoomey. STEPH: Or you can reach us at hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeee!!! ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

[00:04:42] We find out if the guys done any stuff with Rails 7 yet and Chris tells us what's been going on with it. [00:09:44] Chris asks the guys if they are using an encryption library, and Jason talks about using Lockbox and Symmetric Encryption. [00:14:08] Chris tells us more about progressive encryption in Rails 7. [00:15:11] The guys chat about Ruby 3.1 and the new project from Shopify getting merged into Ruby called YJIT, which is an open source JIT compiler for CRuby.[00:18:43] The conversation turns to TenderJIT and Jason brings up a Tweet from tenderlove about it. There is a livestream Aaron Patterson did with hexdevs that he did about it this stuff.[00:22:23] Jason talks about using a tenderlove gem called “dnssd.” [00:26:40] Andrew tells us about an app called Rubyist 1.0, where you can write your own Scripts, system commands, and write your own widgets and stuff with Ruby to automatically trigger lights. [00:31:18] Andrew announces they are giving out free RubyConf tickets on Ruby Radar. [00:34:54] Chris shares some nostalgia when he was in high school learning to code and how the calculator keyboard was the worst. [00:37:08] The guys chat about DragonRuby, Amir Rajan who works on DragonRuby, and Matthew McKinney who made a Tetris game with DragonRuby.Panelists:Jason CharnesChris OliverAndrew MasonSponsor:HoneybadgerLinks:Ruby Radar NewsletterRuby Radar TwitterYJIT- Building a new JIT Compiler inside CRuby with Maxime Chevalier-Boisvert (YouTube)hexdevs-TenderJIT: A JIT compiler for Ruby with Aaron Patterson (tenderlove)TenderJIT-GitHubdnssd gem-GitHubRubyist 1.0 AppAmir Rajan Twitter (DragonRuby)Matthew McKinney Twitter (DragonRuby)

Hans Schnedlitz joins the Rogues to discuss how you can use ActionCable to get feedback on ongoing tasks in the commandline by connecting to a websocket. His solution is written entirely in Ruby and provides some interesting options for people building CLI's for their applications. Panel Charles Max Wood Luke Stutters Valentino Stoll Guest Hans Schnedlitz Sponsors Dev Influencers Accelerator Raygun | Click here to get started on your free 14-day trial Links Real-Time Command Line Applications with Action Cable and Thor OptionParser GitHub | ManageIQ/optimist GitHub | rails/thor Rails Application Templates GitHub | rails/rails GitHub | RailsApps/rails-composer TTY GitHub | junegunn/fzf Hans-Jörg Schnedlitz GitHub: Hans-Jörg Schnedlitz ( hschne ) Twitter: Hans Schnedlitz ( @hschnedlitz ) Picks Charles- Kajabi Charles- Devchat.tv/levelup Hans- GitHub | hschne/rails-mini-profiler Hans- Project Hail Mary Luke- CLI OAuth in Ruby Luke- A Rubyist's Walk Along the C-side (Part 6): Classes & Object Oriented Programming Luke- Raspberry Pi Touch Display Valentino- Destroy All Software Valentino- David Dollar | Developer Experience Design Contact Charles: Devchat.tv DevChat.tv | Facebook Twitter: DevChat.tv ( @devchattv ) Contact Luke: GitHub: Luke Stutters ( lukestuts ) Contact Valentino: Doximity Technology Blog Work @ Doximity GitHub: Valentino Stoll ( codenamev ) Twitter: V ( @thecodenamev )

Hans Schnedlitz joins the Rogues to discuss how you can use ActionCable to get feedback on ongoing tasks in the commandline by connecting to a websocket. His solution is written entirely in Ruby and provides some interesting options for people building CLI's for their applications. Panel Charles Max WoodLuke StuttersValentino Stoll Guest Hans Schnedlitz Sponsors Dev Influencers AcceleratorRaygun | Click here to get started on your free 14-day trial Links Real-Time Command Line Applications with Action Cable and ThorOptionParserGitHub | ManageIQ/optimistGitHub | rails/thorRails Application TemplatesGitHub | rails/railsGitHub | RailsApps/rails-composerTTYGitHub | junegunn/fzfHans-Jörg SchnedlitzGitHub: Hans-Jörg Schnedlitz ( hschne )Twitter: Hans Schnedlitz ( @hschnedlitz ) Picks Charles- KajabiCharles- Devchat.tv/levelupHans- GitHub | hschne/rails-mini-profilerHans- Project Hail MaryLuke- CLI OAuth in RubyLuke- A Rubyist's Walk Along the C-side (Part 6): Classes & Object Oriented ProgrammingLuke- Raspberry Pi Touch DisplayValentino- Destroy All SoftwareValentino- David Dollar | Developer Experience Design Contact Charles: Devchat.tvDevChat.tv | FacebookTwitter: DevChat.tv ( @devchattv ) Contact Luke: GitHub: Luke Stutters ( lukestuts ) Contact Valentino: Doximity Technology BlogWork @ DoximityGitHub: Valentino Stoll ( codenamev )Twitter: V ( @thecodenamev ) Special Guest: Hans Schnedlitz.

Hans Schnedlitz joins the Rogues to discuss how you can use ActionCable to get feedback on ongoing tasks in the commandline by connecting to a websocket. His solution is written entirely in Ruby and provides some interesting options for people building CLI's for their applications. Panel Charles Max WoodLuke StuttersValentino Stoll Guest Hans Schnedlitz Sponsors Dev Influencers AcceleratorRaygun | Click here to get started on your free 14-day trial Links Real-Time Command Line Applications with Action Cable and ThorOptionParserGitHub | ManageIQ/optimistGitHub | rails/thorRails Application TemplatesGitHub | rails/railsGitHub | RailsApps/rails-composerTTYGitHub | junegunn/fzfHans-Jörg SchnedlitzGitHub: Hans-Jörg Schnedlitz ( hschne )Twitter: Hans Schnedlitz ( @hschnedlitz ) Picks Charles- KajabiCharles- Devchat.tv/levelupHans- GitHub | hschne/rails-mini-profilerHans- Project Hail MaryLuke- CLI OAuth in RubyLuke- A Rubyist's Walk Along the C-side (Part 6): Classes & Object Oriented ProgrammingLuke- Raspberry Pi Touch DisplayValentino- Destroy All SoftwareValentino- David Dollar | Developer Experience Design Contact Charles: Devchat.tvDevChat.tv | FacebookTwitter: DevChat.tv ( @devchattv ) Contact Luke: GitHub: Luke Stutters ( lukestuts ) Contact Valentino: Doximity Technology BlogWork @ DoximityGitHub: Valentino Stoll ( codenamev )Twitter: V ( @thecodenamev ) Special Guest: Hans Schnedlitz.

Hans Schnedlitz joins the Rogues to discuss how you can use ActionCable to get feedback on ongoing tasks in the commandline by connecting to a websocket. His solution is written entirely in Ruby and provides some interesting options for people building CLI's for their applications. Panel Charles Max Wood Luke Stutters Valentino Stoll Guest Hans Schnedlitz Sponsors Dev Influencers Accelerator Raygun | Click here to get started on your free 14-day trial Links Real-Time Command Line Applications with Action Cable and Thor OptionParser GitHub | ManageIQ/optimist GitHub | rails/thor Rails Application Templates GitHub | rails/rails GitHub | RailsApps/rails-composer TTY GitHub | junegunn/fzf Hans-Jörg Schnedlitz GitHub: Hans-Jörg Schnedlitz ( hschne ) Twitter: Hans Schnedlitz ( @hschnedlitz ) Picks Charles- Kajabi Charles- Devchat.tv/levelup Hans- GitHub | hschne/rails-mini-profiler Hans- Project Hail Mary Luke- CLI OAuth in Ruby Luke- A Rubyist's Walk Along the C-side (Part 6): Classes & Object Oriented Programming Luke- Raspberry Pi Touch Display Valentino- Destroy All Software Valentino- David Dollar | Developer Experience Design Contact Charles: Devchat.tv DevChat.tv | Facebook Twitter: DevChat.tv ( @devchattv ) Contact Luke: GitHub: Luke Stutters ( lukestuts ) Contact Valentino: Doximity Technology Blog Work @ Doximity GitHub: Valentino Stoll ( codenamev ) Twitter: V ( @thecodenamev )

Jeremy Evans, author of the Roda framework, joins the Rogues to talk about how to use Roda to build Ruby web applications. Roda is a super lightweight framework that adds features through plugins to give you the power you need when you need it to build your applications. This allows you to bring in only what you need in order to get fast and easy to maintain code. Panel Charles Max Wood Dave Kimura  Luke Stutters Guest Jeremy Evans Sponsors Dev Influencers Accelerator Raygun | Click here to get started on your free 14-day trial  Links GitHub | jeremyevans/roda Roda: Routing Tree Web Toolkit GitHub | jeremyevans/roda-sequel-stack GitHub | jeremyevans/r10k GitHub | shrinerb/shrine code.jeremyevans.net GitHub : Jeremy Evans ( jeremyevans ) Twitter: Jeremy Evans ( @jeremyevans0 ) Picks Charles- Sea Lion Fins Charles- Atlas Shrugged  Charles- The Ruthless Elimination of Hurry Dave-  DeWalt Heat Gun 20v  Dave- Creality | CR-10 Smart Jeremy- Xanadu Next Luke- A Rubyist's Walk Along the C-side Luke- The Pragmatic Programmer: Your Journey To Mastery, 20th Anniversary Edition Contact Charles: Devchat.tv DevChat.tv | Facebook Twitter: DevChat.tv ( @devchattv ) Contact Dave: Ruby on Rails Screencasts Twitter: Dave Kimura ( @kobaltz ) GitHub: David Kimura ( kobaltz )

Jeremy Evans, author of the Roda framework, joins the Rogues to talk about how to use Roda to build Ruby web applications. Roda is a super lightweight framework that adds features through plugins to give you the power you need when you need it to build your applications. This allows you to bring in only what you need in order to get fast and easy to maintain code. Panel Charles Max Wood Dave Kimura  Luke Stutters Guest Jeremy Evans Sponsors Dev Influencers Accelerator Raygun | Click here to get started on your free 14-day trial  Links GitHub | jeremyevans/roda Roda: Routing Tree Web Toolkit GitHub | jeremyevans/roda-sequel-stack GitHub | jeremyevans/r10k GitHub | shrinerb/shrine code.jeremyevans.net GitHub : Jeremy Evans ( jeremyevans ) Twitter: Jeremy Evans ( @jeremyevans0 ) Picks Charles- Sea Lion Fins Charles- Atlas Shrugged  Charles- The Ruthless Elimination of Hurry Dave-  DeWalt Heat Gun 20v  Dave- Creality | CR-10 Smart Jeremy- Xanadu Next Luke- A Rubyist's Walk Along the C-side Luke- The Pragmatic Programmer: Your Journey To Mastery, 20th Anniversary Edition Contact Charles: Devchat.tv DevChat.tv | Facebook Twitter: DevChat.tv ( @devchattv ) Contact Dave: Ruby on Rails Screencasts Twitter: Dave Kimura ( @kobaltz ) GitHub: David Kimura ( kobaltz )

Jeremy Evans, author of the Roda framework, joins the Rogues to talk about how to use Roda to build Ruby web applications. Roda is a super lightweight framework that adds features through plugins to give you the power you need when you need it to build your applications. This allows you to bring in only what you need in order to get fast and easy to maintain code. Panel Charles Max Wood Dave Kimura  Luke Stutters Guest Jeremy Evans Sponsors Dev Influencers Accelerator Raygun | Click here to get started on your free 14-day trial  Links GitHub | jeremyevans/roda Roda: Routing Tree Web Toolkit GitHub | jeremyevans/roda-sequel-stack GitHub | jeremyevans/r10k GitHub | shrinerb/shrine code.jeremyevans.net GitHub : Jeremy Evans ( jeremyevans ) Twitter: Jeremy Evans ( @jeremyevans0 ) Picks Charles- Sea Lion Fins Charles- Atlas Shrugged  Charles- The Ruthless Elimination of Hurry Dave-  DeWalt Heat Gun 20v  Dave- Creality | CR-10 Smart Jeremy- Xanadu Next Luke- A Rubyist's Walk Along the C-side Luke- The Pragmatic Programmer: Your Journey To Mastery, 20th Anniversary Edition Contact Charles: Devchat.tv DevChat.tv | Facebook Twitter: DevChat.tv ( @devchattv ) Contact Dave: Ruby on Rails Screencasts Twitter: Dave Kimura ( @kobaltz ) GitHub: David Kimura ( kobaltz )

Guest Mae Beale Panelists Eric Berry | Richard Littauer Show Notes TRIGGER WARNING: There is a mention of blood in this episode. Hello and welcome to Sustain! The podcast where we talk about sustaining open source for the long haul. Being surrounded by beautiful mountains is wonderful, but even more wonderful is our guest today, Mae Beale, who is the Engineering Manager for True Link Financial, Vision and Operations Strategist for Title Track Michigan, and the Founder and CEO of Beale Street Software. Today, you will find out about Mae's involvement and the many hats that she wears working for True Link Financial, Title Track Michigan, and Ruby for Good. Also, we learn about some of the projects she's built and others she's involved in, which are Mutual Aid, Voices of Consent, and Terrastories. Mae shares some awesome stories and advice, so go ahead and download this episode now to hear much more! [00:01:20] Mae tells us about True Link Financial and Title Track Michigan. [00:04:47] Eric wonders if acknowledging or giving thanks for the land that I'm on is really common where Mae lives, and she explains the culture behind it. [00:07:21] Mae shares her thoughts with us on the topic of how people talk about laziness a lot in our industry. [00:11:38] We learn about the work that Mae is doing with Ruby for Good. [00:13:41] Mae tells us what kind of projects she has built through Ruby for Good, such as diaper and essential needs for diaper banks and an animal shelter. [00:15:18] Eric asks Mae to talk about if you want to get involved, what type of commitment is required, if it's open for volunteers and to whatever extent they can contribute, the typical contributor that she sees in this program, and if you have to be a Rubyist to do this. [00:17:04] Richard brings up problems with open source such as how to choose the right project, how to fund this work long-term, how to avoid vendor lock-in for the non-profits and now have to use this code that was made for them. Mae shares her thoughts and also mentions a great project called the Terrastories Project. [00:20:32] Mae tells us her views on how to stop young person burnout. [00:22:26] We learn about two more projects Mae is involved in, Voices of consent and Mutual Aid. [00:27:22] Mae talks about how doing a better job of verbalizing could help with interpreting what's happening, and she tells us a great analogy. [00:29:30] Mae tells us about Mutual Aid and how you can get involved. [00:31:38] Find out where you can follow Mae and see her work on the internet. Quotes [00:02:56] “And rights of the water itself. So, there's a lot of different efforts similar to how companies became people. There is precedent for natural spaces to becoming people are entities that have their own rights. So, the protection is on behalf of the lake itself.” [00:06:34] “That's generally my MO is I have a high sensitivity to the way in which the language that we use and the things that we focus our attention on shape who we are and how we are to each other.” [00:07:05] “But, acknowledging what is happening that makes one uncomfortable is something I try to be willing to share and willing to receive.” [00:08:34] “But, calling it lazy it is in my opinion, problematic and communicates things to other people, amongst ourselves and to other people, that don't disclose our awareness of our privilege.” [00:10:00] "But, sometimes, part of language adjustments over time that we're always trying to do is the difference between intent and impact.” [00:15:52] “So, there really is no average contributor we've had in the repos I've been involved in.” [00:21:39] “There's people who like to be in community and so there's a lot we get out of it that isn't just coding.” [00:26:29] “And we operate as if relationships are Boolean states, and if we can shift that to being able to engage and build trust and build understanding then we can get somewhere.” [00:30:12] “Mutual Aid also includes a political arm of taking a political stance in that it's not charity. There's a phrase, “Solidarity - not charity.” Spotlight [00:33:11] Eric's spotlight is Bridgetown. [00:34:14] Richard's spotlight is EMA: The Erasmus Mundus Students and Alumni Association. [00:35:00] Mae's spotlight is Ruby for Good. Links Mae Beale Twitter (https://twitter.com/mae701?lang=en) Mae Beale GitHub (https://github.com/maebeale) True Link Financial (https://www.truelinkfinancial.com/) Ruby for Good (https://rubyforgood.org/) Title Track Michigan (https://titletrackmichigan.org/story/) Title Track Michigan-Understanding Racial Justice course (https://titletrackmichigan.org/understandingracialjustice/) A guide to indigenous land acknowledgement (https://nativegov.org/a-guide-to-indigenous-land-acknowledgment/) Ruby for Good Diaperbase-GitHub (https://github.com/rubyforgood/diaper) Terrastories (https://terrastories.io/) Ruby for Good Terrastories-GitHub (https://github.com/rubyforgood/terrastories) Voices of Consent (https://github.com/rubyforgood/voices-of-consent) Ruby for Good Voices of Consent-GitHub (https://github.com/rubyforgood/voices-of-consent) Ruby for Good-Mutual Aid (https://github.com/rubyforgood/mutual-aid) Bridgetown (https://www.bridgetownrb.com/) EMA: The Erasmus Mundus Students and Alumni Association (https://www.em-a.eu/) Ruby for Good-GitHub (https://github.com/rubyforgood) WeCamp (http://we-camp.us/#home) Credits Produced by Richard Littauer (https://www.burntfen.com/) Edited by Paul M. Bahr at Peachtree Sound (https://www.peachtreesound.com/) Show notes by DeAnn Bahr at Peachtree Sound (https://www.peachtreesound.com/) Special Guest: Mae Beale.

Mason McLead from software.com shows us the editor-integrated suite of tools that help you become a better developer. We find out what music makes you code better (and worse), how data reveals the habits of the world's top coders and why Saturday is code day. Panel Charles Max Wood Dave Kimura Luke Stutters Guest Mason McLead  Sponsors Dev Influencers Accelerator Raygun | Click here to get started on your free 14-day trial Links Software Top 40 Software.com LinkedIn- Mason Mclead Picks Charles- Fanatical Prospecting Charles- Who Not How Charles- Monday.com Charles- Zapier Dave- J-B Weld  Luke- Rubyist Mason- Materialize Mason- Darn Tough Vermont Contact Charles: Devchat.tv DevChat.tv | Facebook Twitter: DevChat.tv ( @devchattv ) Contact Dave: Ruby on Rails Screencasts Twitter: Dave Kimura ( @kobaltz ) GitHub: David Kimura ( kobaltz )

Mason McLead from software.com shows us the editor-integrated suite of tools that help you become a better developer. We find out what music makes you code better (and worse), how data reveals the habits of the world's top coders and why Saturday is code day. Panel Charles Max Wood Dave Kimura Luke Stutters Guest Mason McLead  Sponsors Dev Influencers Accelerator Raygun | Click here to get started on your free 14-day trial Links Software Top 40 Software.com LinkedIn- Mason Mclead Picks Charles- Fanatical Prospecting Charles- Who Not How Charles- Monday.com Charles- Zapier Dave- J-B Weld  Luke- Rubyist Mason- Materialize Mason- Darn Tough Vermont Contact Charles: Devchat.tv DevChat.tv | Facebook Twitter: DevChat.tv ( @devchattv ) Contact Dave: Ruby on Rails Screencasts Twitter: Dave Kimura ( @kobaltz ) GitHub: David Kimura ( kobaltz )

Mason McLead from software.com shows us the editor-integrated suite of tools that help you become a better developer. We find out what music makes you code better (and worse), how data reveals the habits of the world's top coders and why Saturday is code day. Panel Charles Max Wood Dave Kimura Luke Stutters Guest Mason McLead  Sponsors Dev Influencers Accelerator Raygun | Click here to get started on your free 14-day trial Links Software Top 40 Software.com LinkedIn- Mason Mclead Picks Charles- Fanatical Prospecting Charles- Who Not How Charles- Monday.com Charles- Zapier Dave- J-B Weld  Luke- Rubyist Mason- Materialize Mason- Darn Tough Vermont Contact Charles: Devchat.tv DevChat.tv | Facebook Twitter: DevChat.tv ( @devchattv ) Contact Dave: Ruby on Rails Screencasts Twitter: Dave Kimura ( @kobaltz ) GitHub: David Kimura ( kobaltz )

01:22 - Jess’s Superpower: Playing ANY Instrument * Music & Technology * Cultural Expoloration 06:03 - Language Community Ethos (MINASWAN (https://en.wiktionary.org/wiki/MINASWAN)) * Human-Centered Design * The Joy of Programming Meetup (https://www.meetup.com/Joy-of-Programming-DC/) * Sapir-Whorf Hypothesis (https://www.sciencedirect.com/topics/psychology/sapir-whorf-hypothesis) 13:24 - Inclusive Language: Language Matters * Valheim (https://store.steampowered.com/app/892970/Valheim/) 17:19 - Active Listening and Expressing Point-of-View, and Using Loudness * Vocally For * Vocally Against * Quiet For * Quiet Against 21:51 - Shining Light on Marginalized People & Voices * BULQ (https://www.bulq.com/about-us/) * Metacognition: Asking ourselves, “What are we not thinking about?” * Leadership * Changing Mental Patterns; Take a Different Path 31:30 - Benefits of Having Diverse Teams (Resources) & Risks of Homogeneity * Diversity wins: How inclusion matters (https://www.mckinsey.com/featured-insights/diversity-and-inclusion/diversity-wins-how-inclusion-matters) * Why diversity matters (https://www.mckinsey.com/business-functions/organization/our-insights/why-diversity-matters) * The Chevy Nova That Wouldn't Go (https://www.thoughtco.com/chevy-nova-that-wouldnt-go-3078090) * Google Photos labeled black people 'gorillas' (https://www.usatoday.com/story/tech/2015/07/01/google-apologizes-after-photos-identify-black-people-as-gorillas/29567465/) * From transparent staircases to faraway restrooms, why these benign design details can be a nuisance for some women (https://archinect.com/news/article/150073631/from-transparent-staircases-to-faraway-restrooms-why-these-benign-design-details-can-be-a-nuisance-for-some-women) 37:29 - Storytelling * Representation Matters * Normalization Reflections: Jess: We are feeling beings that rationalize. Damien: How technology impacts culture. Casey: Taking loudness for diversity, equity, and inclusion with people who don’t always talk about it. Who is more open to it or not? This episode was brought to you by @therubyrep (https://twitter.com/therubyrep) of DevReps, LLC (http://www.devreps.com/). To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode (https://www.patreon.com/greaterthancode) To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps (https://www.paypal.me/devreps). You will also get an invitation to our Slack community this way as well. **Transcript:: DAMIEN: Welcome to Episode 233 of Greater Than Code. I’m Damien Burke and I’m joined here with Casey Watts. CASEY: Hi, I’m Casey! And I’m here with our guest today, Jess Szmajda. Jess is currently a senior leader at AWS in the EC2 Networking organization. Previously, she was the first female CTO of a major media organization, Axios, and before that, the co-founder and CTO at Optoro, which helps top tier retailers nationwide handle their returned and excess goods. Jess got her start in tech in the 90s writing Perl to configure Solaris machines. Over the years, she’s contributed to Open Source and organized a number of communities. These days, focusing on the DC Tech Slack and the DC-based Joy of Programming Meetup. Outside of the tech world, Jess is a singer-songwriter, an improviser, a gamer, a proud member of the LGBTQ+ community, and a Mom to the most wonderful, Minecraft-obsessed 6-year-old imaginable. Welcome Jess. DAMIEN: Welcome to Greater Than Code, Jess. JESS: Thank you! It's nice to be here. DAMIEN: So I know someone has prepped you with our first question. What is your superpower and how did you acquire it? JESS: My superpower is that I can play any instrument you hand me and I – DAMIEN: Oh. JESS: [laughs] I acquired it by being a giant nerd. [laughs] I went to a special music high school here in the DC area called Suitland High School and I played all kinds of different instruments. I was the principal bassoonist of the DC Youth Orchestra for a while. Music's always been a lifelong love of mine and it's been a mission to find every strange instrument I can find to figure out how it works. So it's challenge [chuckles] to find something that I can't play. [laughs] DAMIEN: Oh, I'm so tempted and of course, the first thing I would have gone with is the double reed bassoon and oboe, but that's too easy. JESS: That’s right. DAMIEN: Banjo, of course, you’ve got steel drum. JESS: Steel drum and plate, yeah. DAMIEN: Cajon. JESS: Cajon. Oh, I have heard of it. DAMIEN: Aha! JESS: I haven't actually touched one. I'll figure it out. [laughs] DAMIEN: It's particularly easy. JESS: Nice. [laughs] CASEY: I don't know very many people who play more than just an instrument, or two. I think it might be like you and I are the two that come to mind for me, honestly. [laughter] I have an instrument in every color, by the way. That's the way I collect them. [laughter] JESS: Nice. CASEY: I’ve got a white accordion. How do you feel like this breadth of instrument ability has affected your life in other ways? JESS: I don't know. That's an interesting question. How has it affected my life in other ways? I mean, there's the obvious tie into music and technology. There's such an incredible confluence of musicians who are engineers and vice versa. I was actually talking to someone at the office earlier about that and she was theorizing it's because all of the patterns and rhythms that we think about and how that ties into a regular patterns and systems that we think about as engineers and I think it's a really interesting way to think about it, for sure. I do think that there's a certain element of cross-culturalism that you get from learning other cultures instruments. Certainly, the berimbau, the Brazilian martial art? [laughs] DAMIEN: Capoeira? JESS: Capoeira, yeah. The capoeira, the berimbau instrument that has the long string and you have the little – I think you learn a lot about what led to developing an instrument so relatively simple, but creating such an incredible art form in the culture where people just wanted to dance and share their heritage with each other and picked up whatever they could find that would make interesting and fun sounds and created an entire culture around that. So for me, it's as much cultural exploration and understanding as it is anything. I think it's wonderful. DAMIEN: Yeah. That's really amazing. I had a tiny insight on this recently. I saw an amazing video about a Jimmy Hendrix song with the basic premise being, what key is this song in? It's a really difficult question because—and I'm going to go a little bit music nerd here—the tonic is e, but the chord progressions and the melodic signature doesn't really fit that. Amazing 20-minute video, but the end conclusion is that using Western art music tonality to describe blues music, American blues music, it's a different tonality. So it doesn't really make sense to say what major key is this in, or what minor key is this in. JESS: Yeah, totally. My partner and I, this morning, we were watching a video about Coltrane's classic—my favorite thing is interpretation in the 60s—and how he's basically playing between these major and minor tonalities constantly. It's not necessarily tonal from the Western sense, but it’s certainly beautiful and I think it's certainly approachable and understandable to any ear regardless of how you decompose it. Anyway, giant music nerd, sorry. [laughs] DAMIEN: Yeah, but it ties so closely to what you were talking about as an instrument being cultural. The guitar, the five-string guitar, is tuned for American music, which is a slightly different tonality from Western European music. So when you think about “Okay, well, that's very slightly different. Now, what is it like in Africa, in Australia, in Asia?” Then it gets all, it's got to be very, very different. JESS: Oh, yeah. I saw this guy in Turkey, he's modified a guitar to add quarter tones to it because a lot of Turkish music uses quarter tones and so, it's just like the fretboard is wild. It has all of these extra frets on it and he plays it. It's absolutely incredible, but it's wild. It's amazing. DAMIEN: So I want to tie this into different cultures, frameworks, and technology. How about that? JESS: Yeah, you bet, let's do it. [laughs] CASEY: Good segue. JESS: So actually, that's something that's been on my mind is this Ruby community diaspora in a way. I know Greater Than Code has a lot of Ruby folks on it and I'm not sure about the latest incarnation, but definitely a lot of Ruby roots. I think that we've seen this incredible mixing of culture in the Ruby community that I haven't seen in other places that drives this – well, I think [inaudible], it's a really fantastic way to sum it up like, math is nice and so we are nice. As much as that might be a justification to be nice, be nice anyway, but it's still this ethos of we are nice to each other, we care, and that is baked into the community and my journeys and other language communities, I think haven't shared that perspective that it is good to be nice in general and some of them even are, I think are focused on it's good to fight. [laughs] So I've been really curious about this movement, Rubius’s movement into other language areas, like Go, Rust, and Alexa, et cetera, et cetera, how much of that carries forward and what really can we do to drive that? DAMIEN: Yeah. So my question is how does a technological community, what is it about the community? What is about the technology? Why is it different? You and I both wrote Pearl in the 90s and so, that is a very different community. I look at Ruby and I write mostly Ruby now and I go, “Why is it different? What's different about it?” JESS: Yeah, no, it's a good question. A lot of the early conversation that I remember in the Ruby community was—and just contextually, I've been using Ruby since 2006, or so, so that era. A lot of the early conversation I remember was about develop the language to optimize for developer happiness. I think that's a really unique take and I haven't heard of that in any other place. So I'm wondering how much that might've been the beginnings of this. I don't know. DAMIEN: Something came up in a Twitter conversation, I saw a while back where they compared Ruby and Pearl, I'm pretty sure it was Pearl and well, one of the defining features of Pearl was that there's more than one way to do it and Ruby has that same ethos. Literally, in the standard lib, there’s a lot of aliases and synonyms. It's like, you can call pop, or drop and I can't keep it straight. [chuckles] But anyway, then I thought to myself, “Well, in Pearl, that's an absolute disaster.” I pull up a profile and I'm like, “I don't know what this is because I don't know what's going on.” Whereas, in Ruby, I've loved it so much and so, what's the difference and the difference pointed out to me was that in Ruby, it was for expressiveness. Things have different names so that they can properly express, or better express the intention and in Pearl, that wasn't the case. JESS: Yeah, no, totally. I think actually looking at Ruby and Python, I think were both heavily influenced by Pearl and I think Python definitely took the path of well, all of this nonsense is just nonsense. Let's just have one way to do it. [laughs] Having worked with some Python developers, I think that perspective on there is one correct path really drives that community in a lot of ways. I think some people find that releasing really simplifying for them because they're like, “I got it. I know the answer.” Like it's a math problem almost. As a Rubyist going into the Python community, I was like, “Oh, I'm so stifled.” [laughs] Where is my expressiveness?! I want to write inject, or oh, I can't even think of the opposite of inject. Collect. [laughs] Those are two different words for me. I want to be able to write both, depending on what I'm doing so. It's also interesting, like I see a lot more DSL development in Ruby than I see in any other language and maybe Alexa also. But I think that also comes from the same perspective of there is not one right way to do it. There's the best way for this problem and there's the best way for this kind of communication you're trying to drive. It's interesting, as I'm talking myself into a corner here a bit, Ruby almost emphasizes the communication of code more than the solving of the problem and I think that might actually help drive this community where we care about the other humans we're working with, because we're always thinking about how we communicate with them in a way. CASEY: I think about the term human-centered design a lot lately and that's becoming more and more popular term, a way to describe this thing. Ruby totally did that. Ruby looked at how can we make this easy for humans to use and work with and I think that's beautiful. I keep thinking about a paper I read a long time ago that a professor made-up programming language and varied features of it like, white space matters, or not, and a whole bunch of those and measured which ones were easier for new people to learn and which ones were harder for new people to learn. As a teacher, I want to use whatever is easy for the students to learn so they can get their feet wet, so they can start learning and building and doing things and get excited about it, not get hung up on the syntax. So human-centered design baked into Ruby is, I think partly why the community is so human-centered. I think you're exactly right. JESS: Yeah. That's really interesting. That's a large part of why the Joy of Programming Meetup, I think has been really fun is we get to learn from how different language communities build things. I think it was founded on that kind of thinking is the Sapir–Whorf hypothesis for better, or worse theorizes language shapes thought and I think that that is to some degree, at least true in how we think about writing code and solving problems. So the kinds of solutions that you see from different language communities, I think very incredibly. I don't know, even just as simple as from like J2EE, which is the ivory tower of purity in XML [laughs] to obviously, I don't want to pick on Rails, but Rails is an open system. [laughs] An interpretive dance, perhaps. I think it's really interesting, the web frameworks even I see in Haskell almost feel like I'm solving a math problem more than I'm creating an API, or delivering content into somebody. So it's hard for me to separate, is this a community of thought of people who are attracted to a certain way of solving problems? Is this driven by the structure and format of the language? I don't know. DAMIEN: I know you mentioned the Sapir–Whorf hypothesis and their research has been shown to be problematic. JESS: Yeah, for sure. DAMIEN: [laughs] But I will say that the hypothesis is that language shapes thought and I would say that the correct state – correct [chuckles] a better description for me is that language is thoughts and so, the language you use is the sort of things you're thinking about. So if you say inject when you mean collect, those are different things, you're going to get different things out of them. This is why we use get annotate instead of get playing. JESS: For sure. Exactly. So at AWS, this is big drive and I'm not speaking for AWS on this, I'm just speaking for me. But I'm noticing this drive for inclusive language and I think it's really beautiful. Connecting that drive, frankly, in the broader tech community to everything that's been going on in this last year in how we interact with each other as humans from different backgrounds, et cetera. It's like, what kinds of dominant culture paradigms have we baked into our code beyond even the very obviously problematic statements, but just the way that we think about, I don't know. Part of me is like, “Well, is object-oriented design driven by certain cultural expectations that we have, or functional?” I don't know. What paradigms would we get if we'd have had a different dominant culture developing technology? I don't know. It's fascinating. DAMIEN: Yeah, and [inaudible] is an excellent example of that. It's a punishment. This is wrong. I did a whole talk several years ago about specifications versus tests. I don't want you to write tests for your code; tests are something you do afterwards to see if something is suitable. Write a specification and then if the code and specifications don't match, well, one of them needs to change. [laughs] JESS: That's right. I love that. That's also kind of like the Pact Contract Testing space. It's like, I like this framework because it allows a consumer of an API to say, “This is what I expect you to do,” and then the API almost has to comply. Whenever I've talked about Pact, I think with a lot of developers, they're like, “Wait, what? That doesn't make any sense at all.” I'm like, “Well, no.” In a way, it's like the API’s prerogative to deliver what the customer expects and to be always right. The customer is right here, in this case and I think it's a really great way to look at this differently. CASEY: That should totally be the tagline for Pact: the consumer is always right. JESS: I love it. [laughs] CASEY: Another way language shapes things, I noticed lately is Valheim is a super popular game where you're a Viking and building houses. There's a command you can type called “imacheater” that lets you spawn in equipment and building materials. On all the forums online, people are harassing each other for doing their own creative mode for spawning stuff in because of that language, I suspect. So in a recent patch, they changed it from imacheater to devtools, or something like that and the forums have rebranded. There's a new moderator is posting things and the culture is completely changing because the devs changed that one word in the changelog and it's just so cool to see language matters. JESS: That's amazing. That's so cool. Actually, I'm totally hooked on Valheim also along with probably everybody else. I have my own little server with some friends. Anyway, we noticed on the Valheim server that there was somebody who sort of redid the loading screen and they really hypersexualized the female character in the painting and actually got a surprising amount of feedback like saying, “Please don't do that. We love Valheim because it's not clearly gendered, or particularly one way, or the other,” and the artist actually took that feedback to heart and put together a much better version of the thing where the woman was very well armored and looked ready for battle and it was really cool. I've been thinking about the whole tech community and there's so many connections to the gamer community as well. Ever since Gamergate, I think we've been putting a really hard light on this whole world. It's just so heartwarming and incredible to know that like this Viking destroying trolls game has people who actually care enough to say, “No, let's pay attention to what that woman's wearing. Make sure she wears something that's actually reasonable.” That's cool. We've come a long way. I mean, not perfect, but it's a long way. CASEY: Yeah, a long way. I always think about progress in terms of people in four groups. There's like people who are vocally for something like they would speak up in this case, people who are vocally against it, and then quiet people who are for, or against it. We can see the vocal people who are supporting this now and I love to think about how many people are moving in that direction who are quiet; we can't see. That's the big cultural shift under the covers. JESS: Yeah. That's a big question. That makes me think about when I was at Optoro, we were trying to understand our employee engagement and so, we used this tool, Culture Amp, which I imagine a lot of people have seen. We did a survey and we got all this data and it's like, “Hey, everybody's really engaged. Maybe there's a couple of minor things we can fix.” But then we were talking to some of our Black employees—those of you who can't see me, I'm white—and there was just a lot of like, “Wow, this doesn't represent us.” Like, “What are you doing? We actually aren't don't feel like this is a really great representation.” We're like, “Well, the data says everything's fine.” So what we actually did, the next survey we ran, we included demographic data in the dataset and then we were able to distribute the data across racial demographics and we saw, oh no, our Black employees are pretty much all pissed off. [laughs] We've done a really bad job of including them for a lot of reasons. For example, we had a warehouse and most of our Black employees worked in the warehouse and it turns out that we had a very corporate-based culture and we didn't pay enough attention and we didn't really engage everybody. The fact that they were basically all in the warehouse is kind of also a problem, too. So there was a lot of really great eye-opening things that we got to see by paying attention to that and looking not just at our Black employees, but all our different demographics. We learned a lot and I think we had a real humbling moment and got to listen, but it's really this quiet – either people who don't use their voice, or can't use their voice, or maybe don't know how to use their voice in a lot of different ways. These people, I think make such an incredible impact on the true feeling of a place, of a community, of a company and really sitting down and listening to those people, I think can be really hard in any position. So I was really happy we were able to do that, but I think you're totally right, Casey, that it's not just moving the vocal people to really change the Overton window, I suppose on what's acceptable in a community. But it's fundamentally, how do you change the people who you aren't hearing from? How do you frankly even know? CASEY: Yeah, it's a big question. There's no easy answer. There's a lot of approaches. I'm glad people are talking about that in the meta sense, that's huge. We want to do this as a community, but there's work to be done and then even once people are comfortable expressing their point of view, there are then further tiers we're going to have to go through like that other people around them understand. They're actively listening and they internalize it. And then beyond that, actually acting on it. I've had experiences at work where I'm usually very confident, I'll say my point of view regardless of the context. I like being outspoken like that and represent quieter people, but often leadership and other people around me don't understand, or even if they do, they don't incorporate that into the plan and then everybody is still very frustrated, maybe even more so in a way, because a light is shining on this problem. And that's the same for marginalized voices. If they can just be heard, that's great, but we have to go farther than that, too. JESS: I couldn't agree more. This is the thing that I struggle with sometimes. I love people. I'm very extroverted. I'm very gregarious, [laughs] as I imagine you can tell, and I like to engage with people and I try to listen, but I find that sometimes I have a big personality and that can be tough, [laughs] I think sometimes. So I super value people you Casey, for example, who I think are much better listeners [laughs] and are willing to represent that. So that's huge. I also, though on the flip side, I know that I can use that loudness to help represent at least one aspect of marginalized people. I'm trans and I'm super loud about that and I'm very happy to make all kinds of noise and say, “Don't forget about trans rights!” [laughs] Frankly, I think it's kind of a wedge into I'm one kind of marginalized community, I represent one kind of marginalized community, but there's a lot more and let's talk about that, too. Not to toot my horn, but like I think those of us who are allowed to have a responsibility to use our loudness in a way that I think supports people and also, to listen when we can. DAMIEN: Can we explore a bit into the into the metal problem of hearing from marginalized voices? I'm an engineer at heart, first and foremost, and so, how do we solve this meta problem? You gave a good example with the survey separated by demographics knowing that racial and gender demographics, or well, finding out that [chuckles] racial and gender demographics were important factors than you think, but how do we solve this on a broader issue? I don't know. JESS: No, that's a great question. I think we have so much calcified thinking that at every organization and every place in the world, there's so much like, “Well, this is the way we've done things,” and frankly, it's not even, “This is the way we've done things.” It's just, “This is the way it works and this is what we do,” and just thinking outside the box, I think it's hard. Finding these areas that we are being blind to in the first place, I think it takes a certain amount of just metacognition and patience and self-reflection, and that's very difficult to do, I think for any human. But driving that shows like this, for example, making sure that people care and think about these kinds of problems and maybe take a second. You as a listener, I'm going to challenge you for a second, take a minute at the end of this podcast and think about what am I not thinking about? I don't know, it's a really freaking hard question, but maybe you might find something. But it's politicians, it's media, it's our leaders in every aspect making sure that we shine a light on something that is different, something that is marginalized, I think is incredibly valuable. That's a first step. But then playing that through everything else we do, that's hard. I think it falls on leaders in every realm that we have like, community leaders, conference organizers, people who lead major open source projects. Making sure that people say, “I believe that Black Lives Matter.” “I believe that we should stand against violence against the Asian community.” Those, I think are powerful statements and saying, “Hey, have we heard from somebody that doesn't look like us lately, who doesn't come from our same socioeconomic educational background?” It's tough. I had food, but I grew up relatively poor, and I think even that is such a huge difference of experience and background to a lot of people that I end up working with and I've been able to talk about like, “How are we setting prices?” Well, who are we actually thinking about? We're not thinking about ourselves here. We're thinking about a different market. Let's make sure we talk to those people. Let's make sure we talk to our customers and make sure that this actually works for them. I was really proud. At Optoro, we built a new brand called BULQ where we took – so 2 seconds on Optoro. We took returns and excess goods from major retailers and helped them get more value out of it and a a lot of the time, we built great classification systems to say, “Oh, well this is a belt and I know how to price belts because I can look on eBay and Amazon and determine, et cetera.” But a lot of the times we couldn't build these kinds of models, like auto parts, for example, were notoriously difficult for us. So we could say, “Oh, this is an auto part. But I don’t know, carburetor, manifold? Who knows?” [laughs] So we were able to classify them as auto parts and then we put them into these cases, maybe like 3-foot square large boxes, and then we were able to sell those in lots to basically individual people who had time to learn what they were and then could resell them. The story that I love to tell here is they're a laid-off auto factory worker, knows a ton about auto parts, and can probably scrounge up enough money to afford this $200 to $300 box, brings it to their house, knows exactly what these parts are and knows exactly what the value is and then can resell them for like 3x to 5x on what this person bought them for. I was so proud to be able to have created this kind of entrepreneurial opportunity for people that we would otherwise often forget about because so much of tech, I think is focused on us. So, it's an interesting thing kind of being at AWS, which is very much a tech for tech company. I love it, don't get me wrong, but sometimes I think these opportunities to listen to the rest of the world, we miss out on. DAMIEN: Yeah. You challenged us to ask ourselves the question, what are we not thinking about and that level of metacognition sounds impossible. It might be impossible. It's close to impossible, if it's not. So I can't help to think the only way to really get that knowledge, that insight is to get people who are different from me, who have different backgrounds, who have different life experiences. You got a great example of someone who knows a lot about car parts, bring them in, they have years of experience in car parts and they can do this stuff that you can't do. But then also, along every axis, if you look around. If you look around the leadership and go, “Oh, there's nobody in leadership here who has this type of experience,” that knowledge, that insight and people like that are not going to be served because it's impossible for them. They don't even know. They can't know. JESS: Could not agree more and it is leadership. Absolutely. You're absolutely right. So many times I've seen, having been a leader, ultimately, you end up in a room with other leaders and you end up making decisions. And if you don't have other voices in there, if you don't have diverse voices, you don't get that benefit. Even if you've gone to the trouble of paying attention to diverse voices beforehand, there's always some data, some argument that comes up and it's like, “Oh, well, maybe, maybe not.” Yeah, I cannot agree enough. This is the other flip side of that is that as a business leader, I have to think about prioritizing the outcomes of the business, it is a fact of my position and I like to think that I work in a lot more data to what that means than other business leaders perhaps. Like, impact on the community. [laughs] Impact on the people. But a lot of times, we'll be having these discussions about who to hire and maybe we'll have done a really great job—and this isn't specific to any particular company that I'm talking about, but I know that this kind of thing happens. Maybe we've done a really great job of getting a diverse pipeline and having talked to a bunch of different kinds of candidates, but when it comes down to it, we're trying to make often the lowest risk decision on who to hire and so often, we are too risk averse to somebody whose background doesn't quite line up to what we're expecting, or to what we think we need. I like to think that I push hiring communities in conversations like that and say like, “Look, let's think beyond what's risky here and factor in more of these aspects to the conversation of getting diverse voices.” But too often, it's very easy, I think for leaders to think, “Well, we’re just going to hire the known quantity,” and I think that is again, on the meta, a major thing that we need to fix. There's so much more to being an effective leader than having the standard pedigree. DAMIEN: Well, there's also, like you mentioned, the risk aversion to not want to hire somebody who's not like all the other people, but then what are the huge risks of having only people who are alike in certain aspects? JESS: Exactly. Couldn't agree more. I think there's tons of examples. If we Google right now, we'd find like companies have made really dumb mistakes because they didn't have somebody in the room who could be like, “That?” The first one that comes to mind is the Chevy Nova, they tried to sell that in Spanish speaking countries, [laughter] “doesn't go,” “not going anywhere.” [laughs] I mean, like that could have been avoided, right? [laughs] CASEY: Nova. JESS: Nova. That might be a trivializing one, but there's been a lot worse and that's a major business risk and I think those arguments carry some weight. I love that so many organizations are prioritizing hiring more diverse leaders, especially, but this is deep pattern that we've gotten into. So that actually comes to mind when you're thinking about how to change your mental patterns. I'm an improviser, I'm all about trying to change my mental patterns all the time so I can try to be creative. Obviously, there's plenty of silly improv games that you get into, but something that's simple, I think that anybody can do is go for a walk and take a different path. Just turn a different way than how you used to. We, humans love to get into patterns, especially engineers, which I find to be highly ironic. Engineers are all about creating change, but don't like change themselves typically. [laughs] But do something a little different, turn left instead of right today, look up instead of down. Those, I think subtle physical changes really do influence our mental states and I think that can actually lead us to thinking in new ways. CASEY: I love it. That's very actionable. I've been doing a lot of walks and hikes and I actually try to go to a different hiking location each time because of that. I think about that idea all the time, take a different path, and it is great. Every time I do it, I feel amazing. I don’t know, more flexible, I think differently. Yeah, try it, listeners. I dare you. JESS: I love it. CASEY: I'm sure there are papers written showing that having diverse teams have very measured effects, a whole bunch of them, more than I know more, than I've read. Well, I guess first of all, I don't know that the data has been collected in a single spot I can point people to and that would be pretty powerful. But then secondly, even if we had that, I'm not sure that's enough to change minds at companies in any widespread way. It might just help some people, who already care, say their message very clearly. Do you know of anything like that Jess, or Damien, either of you? What's the one resource you would send to someone who wants to be equipped with diversity and inclusion data? JESS: Yeah. This study McKinsey did a while ago that, I think gets a lot of traction here where they demonstrated the companies have better total performance with more diverse groups of people and went into some depth with data. I think it's a fantastic study. It's definitely one that I reference often. I've used it to change minds among people who were like, “Wow, what's it really matter?” No, I’ve got data. [laughs] I know. I can see Casey here on video and Casey's mouth just went open [laughs] It's like, “Yes, no, it's, that's real.” No shade on the people I've worked with, I love them, but like, this is such a thing. There are cynics in corporate leadership who want to focus on profit and sometimes, you have to make a cynical argument in business and a cynical argument can come down to data and this data says, “No, look, if we get more people in here who look different from us, we're going to make more money and that's good for you and your bottom line.” So sometimes you have to walk the argument back to that, even if it feels gross and it does, it's like, “No, this actually matters to your bottom line.” DAMIEN: That's a great argument and it's a positive argument. In my view of corporations, I feel like the larger they get, the more you have an agency problem where people aren't looking to take risks to get the positive benefits, they're going to do things to avoid backlash and negative things. So I think larger company, more middle management, more people you’re answerable to, especially on the short-term, the more people are better motivated by fear. So for that, I want to pull out like, what are the risks of homogeneity? You mentioned the Nova. You mentioned like, oh, there was – [laughs] I pull this out far too often. There was an AI image classifier that classified Black people as gorillas. There was a store. Oh goodness, I think it was an Apple store. Beautiful, beautiful architecture, glass everywhere, including the stairs. These are all the harms that come from homogeneity. [laughs] What was the expensive fixing those stairs? It couldn't have been cheap. JESS: Oh my gosh. [chuckles] I don't even wear skirts that often. [laughs] DAMIEN: And I know that's a problem because when I heard that story, I was multiple paragraphs in before I realized the problem. I wear skirts less than you, I'm sure. [laughter] JESS: For sure. Oh, that's amazing. Yeah, I think those stories are really important for us to be able to tell and to share with each other because diversity matters. I think it's easy to say that and especially among people who care, people who prioritize it. We almost take it as like a, “Well, of course,” but I think there is still, getting back to that quiet group of people who don't say what they actually think, there's a lot of people who are on the fence, or maybe frankly disagree. It's like, “Well, you can disagree and I respect your disagreement, but here's the data, here's the results, here's the impact. Let's talk about that. Do you have a better way to handle this? Because I don't.” DAMIEN: So I think the risk is especially acute in tech companies and in tech for tech companies where things are far more homogeneous. Next week on how to pronounce these words. [laughs] So what can we do? Is there anything special that we can do in those sort of environments? JESS: Yeah. Well, besides have the conversation, which I think is something we can all do. Not to fangirl too much about Amazon, but I really do like the company and I'm really enjoying my experience. A lot of it comes down to how we've expressed our leadership principles. We say this is our culture and our values and we actually apply it constantly like, if you ever come to talk to an Amazon person, I'm going to tell you about how I've disagreed and committed and what I'm doing to think big and how I'm customer obsessed. I'm going to talk about those things directly. To this, we say one of our leadership principles is that leaders are right a lot and that feels weird, right? Leaders are right a lot? “Oh, I just happen to know everything.” No, that's not what that means. We actually go into it in more depth and it's like leaders look to disconfirm their beliefs and seek diverse perspectives and we bake that right into one of our core cultural values. I think that that is absolutely critical to our ability to serve the broader tech community effectively. The fact that we hold leaders to being right through having gone through a crucible of finding out how they're wrong, I think is magical and I think that's actually something that a lot more companies could think to do. It's like, you as a tech person and you think, “Oh, I'm going to go sell this great new widget to all of my tech buddies.” Okay. You might be right. But how could you make that bigger? How could you make that better? Like go, try to find out how you're wrong. That should be something we value everywhere. It's like, “No, I'm probably wrong. I want to be right.” So the way to get right is to find out every way I'm wrong and that means talk to everybody you can and find out. CASEY: From our conversation here, I'm picking up a couple of tools we have to help persuade people to get them to be louder, or more proactive at least. Data is one. Telling stories from other companies is another one. And then here, I'm picking up get your own stories that you can really tell from your point of view and that's maybe the strongest of the three, really. The change is you, too. I love that idea. JESS: Yeah. We had a internal conference this week, the networking summit, and there was a great session last night from somebody talking about what customers love and what customers hate about our products. He was just telling story after story about customers saying, “Oh, I'm so frustrated with this.” “I would love to change that.” Those stories, I think have so much more weight in our minds. Humans are evolved to tell the stories to each other. So if we have stories to tell, I think those are so much – they connect at a deeper level almost and they help us think about not just that top of brain logical, almost engineering, binary yes, no, but it's more this deeper heart level. “I understand the story that led to this position. I understand the human that feels this way.” Personally, I think no matter how logical we think we are; [chuckles] we’re still walking bags of meat [laughs] and there's a lot to be said to respect that and to connect with that. So yeah, storytelling is huge. DAMIEN: You brought up, earlier in our conversation, about how things might be different with a different cultural paradigm. This is an enormous example of this. White Western culture overvalues logic and objectivity. It's a by-product of the culture and there's a conflation between objectivity and rationality and rightness. Weirdly enough, in my experience, that makes people less able to be rational and objective. It's quite amazing, ironic, and tragic. But if you follow the science, you follow the logic, you follow the rationality; what you'll discover is that humans are not naturally logical, rational beings. We are not rational beings that feel; we are feeling beings that rationalize. From the beginning from the birth of humans as a species, stories and communication have been how we navigate the world, how we see the world, how our beliefs and behaviors change and you can see that throughout all of history and it's the narratives that change everything. So that's something that is super important to have, to know and especially if you want to be effective. Having grown up in this culture, though, it amuses me to no end how little I use that knowledge. [laughs] I argue with logic and facts and wonder why don't people don't understand when I have all the logic and facts that tell me that that's not going to change what they do. [laughs] JESS: Oh, yeah. Honestly, I think our political climate right now is representative of that because it's like, I don't know, I feel like it's so logical and factual, my political perspectives, and then I'll talk to somebody else and they feel the exact same way. Having been in media, I've seen like a lot of what we end up believing is how we sold it to ourselves and the stories that we've told around it and what we've paid attention to. We've listened to it. It's so easy to develop this cognitive filter on the stories that don't line up to your expectations. I don't know. This is, I think an area that engineers really overlook time and time again, is the power of media and the power of the stories that we tell. Being a trans person, I didn't come out until I was in my late 30s because the stories, I grew up with of trans people were stories of serial killers, rapists, murderers, and people who were at the very edges of society and like, I'm like, “Well, I'm not that. I can't be trans.” [laughs] It wasn't until we had these news stories of love, or hate. Caitlyn Jenner, I think set a new story on the world and a lot of things changed around then where we were able to see ourselves in a light that wasn't just pain and I think that we've seen a lot more trans people come out because they're able to see themselves in these happier stories and better stories. So we need more stories like that. Like Pose, I think is amazing and great stories of standing up in a hard place and owning your power, even under all this adversity, I think it's incredible. Those set of stories, I think are just so incredible for everybody and we just need so much more. I could rant for a while. [laughs] CASEY: Yeah. I'm totally on board with this as a queer man, I wasn't comfortable for a lot of my life being that because of the representation. I'm not into drag, but that's not a requirement. [chuckles] A friend of mine just shared a list of children's books that are incidentally queer and I just think that's so cool. The phrase, even. They're just regular storybooks, not about being queer as a topic, but just people doing normal stuff that happened to have including queer characters. JESS: I love that. CASEY: The world is changing. JESS: Yes, and I think we have a responsibility to be a part of that storytelling. Let's tell stories and it doesn't have to be a big deal that the person you’re talking about is a female engineer. No, she just happens to be an engineer. Let's tell stories where he has a husband. Who cares? He has a husband, it's great. It's not the focus of the story. It's just a part of the whole, the melior that we're in. That's really important. So, I think a lot of normalizing – a lot of acceptance comes through normalization and honestly, it's so complicated because there's this tendency to whitewash when you go into this normalizing place. It's like, “Oh, I don't see skin tone.” No, I think that's not the way to do it. I think it's like there are differences in us, in our backgrounds, in our cultures, in our experiences, and that is incredible and that is wonderful, and it's not the story, but it's a part of the story and that's an important part. DAMIEN: Yeah, as a Black man, I've definitely seen this. I like to say Black Panther was the best thing that happened to African-Americans in the history of cinema. Get Out is another example. It's very much about the Black experience, but it's not the old story of what being Black in America is like and so, it's very different. JESS: Definitely. Yeah. CASEY: We're getting near the end of time we have today, let's shift gears into what we normally do at the end, our reflections. What's something that you're going to take away from this conversation? Jess, or Damien, who wants to go first? JESS: I'll start because I already wrote it down here. Damien, you said, “We are feeling beings that rationalize.” That is going to stick with me. That was profound. I love that and it's so obvious, I think but I'd never thought to think of it that way, or to say it that way. So I’ve got to think about that one for a while, but that's, I think really going to stick with me. Thank you. DAMIEN: Thank you, Jess. That's quite an honor. I can drag out like probably a half dozen off the top of my head, or a dozen probably store of scientific studies that show that. [laughs] I never get enough of them mostly because I've been rationalizing more. Anyway, my reflection is really on how technology impacts culture, both within the technologists and how that relates to storytelling, communication, and language. All those things are creating culture and all those things exist in technology, in between technologists, and that's how we can make our culture. It's something that I want it to be, or more like something I want it to be. So thank you. JESS: That's awesome. CASEY: I think my takeaway is I'm noticing that I said I'm very loud and outspoken about a lot of stuff, and I care a lot about diversity, equity, and inclusion, especially when I’m groups of people talking about it, I talk about that all the time. But can I and how can I take that loudness for diversity, equity, and inclusion with people who don't always talk about it? Who can I approach and how can I tell who is more open to it or not? That's always a big open question for me. I guess, I'll be thinking about that especially this week. JESS: Well, this was a pleasure. Thank you for having me. DAMIEN: This was great, Jess. Thank you so much for joining us. JESS: Yeah, it was delightful. DAMIEN: I suppose this might be a good time to plug our Slack community, which is available to all Patreon for the podcast and also, all of our guests. So Jess, if you want to join us there and we can nerd out some more. I’ll keep throwing you instruments to try and stump you. JESS: Yes! Bring it on! [laughs] Special Guest: Jess Szmajda.

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

Tim Riley is a long-time Rubyist and is a core team member of the Hanami, dry-rb, and rom-rb open source projects. He guested on the show to discuss the eagerly anticipated Hanami 2.0 release, how dry-rb, rom-rb and Hanami partnered and how slices and containers work with one another.

Tim Riley is a long-time Rubyist and is a core team member of the Hanami, dry-rb, and rom-rb open source projects. He guested on the show to discuss the eagerly anticipated Hanami 2.0 release, how dry-rb, rom-rb and Hanami partnered and how slices and containers work with one another.

Tim Riley is a long-time Rubyist and is a core team member of the Hanami, dry-rb, and rom-rb open source projects. He guested on the show to discuss the eagerly anticipated Hanami 2.0 release, how dry-rb, rom-rb and Hanami partnered and how slices and containers work with one another.

Tim Riley is a long-time Rubyist and is a core team member of the Hanami, dry-rb, and rom-rb open source projects. He guested on the show to discuss the eagerly anticipated Hanami 2.0 release, how dry-rb, rom-rb and Hanami partnered and how slices and containers work with one another.

Tim Riley is a long-time Rubyist and is a core team member of the Hanami, dry-rb, and rom-rb open source projects. He guested on the show to discuss the eagerly anticipated Hanami 2.0 release, how dry-rb, rom-rb and Hanami partnered and how slices and containers work with one another.

This week, Brittany is joined by Haroon Ahmed, a programmer from Coventry, UK. He is a Hacker, Rubyist, and open source contributor. They discuss his latest contribution to Rails (--minimal) and how OS can open up career opportunities for developers.

This week, Brittany is joined by Haroon Ahmed, a programmer from Coventry, UK. He is a Hacker, Rubyist, and open source contributor. They discuss his latest contribution to Rails (--minimal) and how OS can open up career opportunities for developers.

Tobi is a developer, leader, benchmarker, Rubyist, Elixir fan, learner, teacher and agile crafter by passion. He loves collaboratively creating just about anything people enjoy - be it the Ruby User Group Berlin, SimpleCov, benchee, or other projects while thinking about new ideas to push boundaries. Currently he's helping companies onboard onto Elixir and creating wonderful web applications in his journey as a freelancer. Show Notes Ruby User Group Berlin (https://www.rug-b.de/) rubycorns (http://rubycorns.club/) SimpleCov (https://github.com/colszowka/simplecov) benchee (https://github.com/bencheeorg/benchee) shopify (https://www.shopify.com/) pivorak (https://pivorak.com/) Aaron Cruz (https://www.parallelpassion.com/13) Shoes 4 (https://github.com/shoes/shoes4) why the lucky stiff (https://en.wikipedia.org/wiki/Why_the_lucky_stiff) wroclove.rb (https://wrocloverb.com/) Arne Brasseur (http://devblog.arnebrasseur.net/) Steve Klabnik (https://steveklabnik.com/) AlphaGo (https://en.wikipedia.org/wiki/AlphaGo) 2 hard problems tweet (https://twitter.com/minsuk_chang/status/1277502761697861632) Theory X and Theory Y (https://en.wikipedia.org/wiki/Theory_X_and_Theory_Y) Piotr Szotkowski (https://www.parallelpassion.com/14) code curious (https://www.codecurious.org/) Ruby Monstas (http://rubymonstas.org/) metasploit (https://www.metasploit.com/) The Agile Samurai (https://www.amazon.com/o/ASIN/1934356581/parpaspod-20) Rework (https://www.amazon.com/o/ASIN/0307463745/parpaspod-20) A Guide to the Good Life (https://www.amazon.com/o/ASIN/0195374614/parpaspod-20) Tao Teh King (https://www.amazon.com/o/ASIN/087573040X/parpaspod-20) The Art Of War (https://www.amazon.com/o/ASIN/1599869772/parpaspod-20) The Manual: A Philosopher's Guide to Life (https://www.amazon.com/o/ASIN/1545461112/parpaspod-20) RSA Animate: Drive (https://www.youtube.com/watch?v=u6XAPnuFjJc) Punished by Rewards (https://www.amazon.com/o/ASIN/0618001816/parpaspod-20) Recommendations Sophie's World (https://www.amazon.com/o/ASIN/0374530718/parpaspod-20) All Quiet on the Western Front: A Novel (https://www.amazon.com/o/ASIN/0449213943/parpaspod-20) Drive: The Surprising Truth About What Motivates Us (https://www.amazon.com/o/ASIN/1594484805/parpaspod-20) Tobias Pfeiffer Twitter (https://twitter.com/PragTob) Personal Page (https://www.pragtob.info/) Parallel Passion Patreon (https://www.patreon.com/parpaspod) Twitter (https://www.twitter.com/parpaspod) Instagram (https://www.instagram.com/parpaspod) Facebook (https://www.facebook.com/parpaspod) Credits Headway (https://unsplash.com/@headwayio) for the header photo Tina Tavčar (https://twitter.com/tinatavcar) for Parallel Passion logo Jan Jenko (https://twitter.com/JanJenko) for intro/outro music

Welcome to Remote Ruby! Today, our special guest is Nick Schwaderer, a Rubyist, who works for a company called, Chef, in the Belfast office in Northern Ireland. On today’s episode, Jason starts us off by talking about the form stuff he’s been working on. Nick talks about “Past Rubies” which will be reappearing soon. The merge of Rails and Merb is mentioned and a fascinating blog post about it. Also, Brighton Ruby’s remote conference is brought up and what they are giving out. We talk about modules, concerns, Gilded Rose Kata, and how the community relations maintenance part is so important to deal with. Also, find out why Andrew calls Chris the “shiz!”

Gina Verrastro is a Rubyist, writer, and proud graduate of LEARN Academy. She is a Tech Support Engineer at SOCi who specializes in taking the most optimistic view of every bug-hunting situation.

Gina Verrastro is a Rubyist, writer, and proud graduate of LEARN Academy. She is a Tech Support Engineer at SOCi who specializes in taking the most optimistic view of every bug-hunting situation.

Gina Verrastro is a Rubyist, writer, and proud graduate of LEARN Academy. She is a Tech Support Engineer at SOCi who specializes in taking the most optimistic view of every bug-hunting situation.

Andy Croll is CTO at CoverageBook & AnswerThePublic, Rubyist, conference organizer of Brighton Ruby, author, speaker, bootstrapper & twin dad. Amidst the COVID-19 pandemic, Andy had to pivot this year's conference into a new experience. He and Brittany discuss the details and the potentially lasting effects on the community.

Andy Croll is CTO at CoverageBook & AnswerThePublic, Rubyist, conference organizer of Brighton Ruby, author, speaker, bootstrapper & twin dad. Amidst the COVID-19 pandemic, Andy had to pivot this year's conference into a new experience. He and Brittany discuss the details and the potentially lasting effects on the community.

Andrew Glass is a Brooklyn based Rubyist operating a small independent devshop called Bang Equals. He has held many ‘enrichment jobs’, including being a ball person at US Open for 5 years, traveling for judging Guinness World Record attempts, and will be a balloon holder in the Macy’s Thanksgiving Day Parade this year. Today the panel is discussing his about his 2018 RailsConf talk, Human Powered Rails: Automated Crowdsourcing In Your Ruby on Rails App. In his talk, he shows the audience how to use Amazon Mechanical Turk. Amazon Mechanical Turk lets you post tasks, set a price point, and then people can go and complete the task. This is often done with tasks that can’t be done with machine learning and to train machine learning algorithms. In his talk he goes into What it is, how it’s used, and how we can use Ruby to automate the process. In his apps, he uses it for lead generation, qualification, enrichment, and some video and photo tagging. More specific uses include recording items from a picture of a shopping list, identifying specific things in a video, categorizing businesses and items, sentiment analysis of text or image. Overall, Mechanical Turk is used for things that machine learning can’t handle yet. The panel discusses some different uses for crowdsourcing and how to submit something to Mechanical Turk. There are multiple ways to ensure accuracy in your surveys, including setting up multiple stages to your task, having more than one person complete your task, and creating a qualified worker pool based on tests to determine their aptitude and skill.  The panel discusses some of the controversy surrounding Mechanical Turk, citing an article in the New York Times (see links). The big issue is wages and worker rights. Wages can be very low, and it is ripe for abuse by companies as they could easily refuse all work and withhold pay. It is also important for the companies to give an accurate time estimate for the task and a reasonable reimbursement. Mechanical Turk attracts a variety of people, from people that do it for fun to people to actually do it for a living, so it is vital that companies use the tool responsibly.  Andrew talks more about how his app works. His apps are built on RTurk, Turkee, and Mechanical Turk, and he talks about how they work. The tricky part is figuring out the logic for what answers they will accept. Andrew talks about how to get started with Mechanical Turk and how to validate the work you get back. To ensure you get accurate information, he suggest that you make it happy for your users, make the UX simple and usable, and use a lot of formatting in your forms so that you get good information in. They preface their results with an accuracy score to help determine what is true. Andrew talks about where he wants to go from he. His Turking days are behind him, but his days of coordinating the efforts of many using software show promise.  Panelists Dave Kimura Charles Max Wood Guest Andrew Glass Sponsors Sentry | Use the code “devchat” for $100 credit Cloud 66 - Pain Free Rails Deployments Try Cloud 66 Rails for FREE & get $100 of free credits with promo code RubyRogues-19 RedisGreen Links Human Powered Rails: Automated Crowdsourcing In Your RoR App by Andrew Glass Amazon Mechanical Turk AWS Transcribe I Found Work on an Amazon Website.  I Made 97 Cents an Hour.  RTurk Turkee AWS SDK Turk Picks Dave Kimura: HatchBox Charles Max Wood: The MaxCoders Guide to Finding Your Dream Developer Job White Christmas Andrew Glass: Foragoodstrftime.com Follow Andrew @andrewglass1 on Twitter and Instagram and andyglass.co

Andrew Glass is a Brooklyn based Rubyist operating a small independent devshop called Bang Equals. He has held many ‘enrichment jobs’, including being a ball person at US Open for 5 years, traveling for judging Guinness World Record attempts, and will be a balloon holder in the Macy’s Thanksgiving Day Parade this year. Today the panel is discussing his about his 2018 RailsConf talk, Human Powered Rails: Automated Crowdsourcing In Your Ruby on Rails App. In his talk, he shows the audience how to use Amazon Mechanical Turk. Amazon Mechanical Turk lets you post tasks, set a price point, and then people can go and complete the task. This is often done with tasks that can’t be done with machine learning and to train machine learning algorithms. In his talk he goes into What it is, how it’s used, and how we can use Ruby to automate the process. In his apps, he uses it for lead generation, qualification, enrichment, and some video and photo tagging. More specific uses include recording items from a picture of a shopping list, identifying specific things in a video, categorizing businesses and items, sentiment analysis of text or image. Overall, Mechanical Turk is used for things that machine learning can’t handle yet. The panel discusses some different uses for crowdsourcing and how to submit something to Mechanical Turk. There are multiple ways to ensure accuracy in your surveys, including setting up multiple stages to your task, having more than one person complete your task, and creating a qualified worker pool based on tests to determine their aptitude and skill.  The panel discusses some of the controversy surrounding Mechanical Turk, citing an article in the New York Times (see links). The big issue is wages and worker rights. Wages can be very low, and it is ripe for abuse by companies as they could easily refuse all work and withhold pay. It is also important for the companies to give an accurate time estimate for the task and a reasonable reimbursement. Mechanical Turk attracts a variety of people, from people that do it for fun to people to actually do it for a living, so it is vital that companies use the tool responsibly.  Andrew talks more about how his app works. His apps are built on RTurk, Turkee, and Mechanical Turk, and he talks about how they work. The tricky part is figuring out the logic for what answers they will accept. Andrew talks about how to get started with Mechanical Turk and how to validate the work you get back. To ensure you get accurate information, he suggest that you make it happy for your users, make the UX simple and usable, and use a lot of formatting in your forms so that you get good information in. They preface their results with an accuracy score to help determine what is true. Andrew talks about where he wants to go from he. His Turking days are behind him, but his days of coordinating the efforts of many using software show promise.  Panelists Dave Kimura Charles Max Wood Guest Andrew Glass Sponsors Sentry | Use the code “devchat” for $100 credit Cloud 66 - Pain Free Rails Deployments Try Cloud 66 Rails for FREE & get $100 of free credits with promo code RubyRogues-19 RedisGreen Links Human Powered Rails: Automated Crowdsourcing In Your RoR App by Andrew Glass Amazon Mechanical Turk AWS Transcribe I Found Work on an Amazon Website.  I Made 97 Cents an Hour.  RTurk Turkee AWS SDK Turk Picks Dave Kimura: HatchBox Charles Max Wood: The MaxCoders Guide to Finding Your Dream Developer Job White Christmas Andrew Glass: Foragoodstrftime.com Follow Andrew @andrewglass1 on Twitter and Instagram and andyglass.co

Andrew Glass is a Brooklyn based Rubyist operating a small independent devshop called Bang Equals. He has held many ‘enrichment jobs’, including being a ball person at US Open for 5 years, traveling for judging Guinness World Record attempts, and will be a balloon holder in the Macy’s Thanksgiving Day Parade this year. Today the panel is discussing his about his 2018 RailsConf talk, Human Powered Rails: Automated Crowdsourcing In Your Ruby on Rails App. In his talk, he shows the audience how to use Amazon Mechanical Turk. Amazon Mechanical Turk lets you post tasks, set a price point, and then people can go and complete the task. This is often done with tasks that can’t be done with machine learning and to train machine learning algorithms. In his talk he goes into What it is, how it’s used, and how we can use Ruby to automate the process. In his apps, he uses it for lead generation, qualification, enrichment, and some video and photo tagging. More specific uses include recording items from a picture of a shopping list, identifying specific things in a video, categorizing businesses and items, sentiment analysis of text or image. Overall, Mechanical Turk is used for things that machine learning can’t handle yet. The panel discusses some different uses for crowdsourcing and how to submit something to Mechanical Turk. There are multiple ways to ensure accuracy in your surveys, including setting up multiple stages to your task, having more than one person complete your task, and creating a qualified worker pool based on tests to determine their aptitude and skill.  The panel discusses some of the controversy surrounding Mechanical Turk, citing an article in the New York Times (see links). The big issue is wages and worker rights. Wages can be very low, and it is ripe for abuse by companies as they could easily refuse all work and withhold pay. It is also important for the companies to give an accurate time estimate for the task and a reasonable reimbursement. Mechanical Turk attracts a variety of people, from people that do it for fun to people to actually do it for a living, so it is vital that companies use the tool responsibly.  Andrew talks more about how his app works. His apps are built on RTurk, Turkee, and Mechanical Turk, and he talks about how they work. The tricky part is figuring out the logic for what answers they will accept. Andrew talks about how to get started with Mechanical Turk and how to validate the work you get back. To ensure you get accurate information, he suggest that you make it happy for your users, make the UX simple and usable, and use a lot of formatting in your forms so that you get good information in. They preface their results with an accuracy score to help determine what is true. Andrew talks about where he wants to go from he. His Turking days are behind him, but his days of coordinating the efforts of many using software show promise.  Panelists Dave Kimura Charles Max Wood Guest Andrew Glass Sponsors Sentry | Use the code “devchat” for $100 credit Cloud 66 - Pain Free Rails Deployments Try Cloud 66 Rails for FREE & get $100 of free credits with promo code RubyRogues-19 RedisGreen Links Human Powered Rails: Automated Crowdsourcing In Your RoR App by Andrew Glass Amazon Mechanical Turk AWS Transcribe I Found Work on an Amazon Website.  I Made 97 Cents an Hour.  RTurk Turkee AWS SDK Turk Picks Dave Kimura: HatchBox Charles Max Wood: The MaxCoders Guide to Finding Your Dream Developer Job White Christmas Andrew Glass: Foragoodstrftime.com Follow Andrew @andrewglass1 on Twitter and Instagram and andyglass.co

Joe Leo is the CEO of Def Method, an agile Ruby software consultancy, and the co-author of The Well-Grounded Rubyist, Third Edition. He and Brittany discussed functional programming in Ruby and their thoughts on the Ruby community after Rubyconf 2019.

Joe Leo is the CEO of Def Method, an agile Ruby software consultancy, and the co-author of The Well-Grounded Rubyist, Third Edition. He and Brittany discussed functional programming in Ruby and their thoughts on the Ruby community after Rubyconf 2019.

On this week's episode, Steph is joined by Brittany Martin, an avid Rubyist and the host of the Ruby on Rails Podcast. They discuss Brittany's passion for roller derby and her upcoming Ruby conference talk: "Hire Me, I'm Excellent at Quitting." They also discuss using AWS Serverless, troubleshooting Postgress connection errors and working with Google Pay and Apple Wallet to introduce digital tickets.@BrittJMartin - Brittany on TwitterRuby on Rails PodcastRubyConf 2019 - Hire Me: I'm Excellent at QuittingBikeshedding with Steph ViccariTN Inspire! "Ramping Up With Roller Derby"RubyConf MY - Rails Against the MachineRuby on Rails on Windows is not just possible, it's fabulous using WSL2 and VS CodeAmazon Aurora ServerlessNate Berkopec - Speed Shop

On today's show, we are joined by a very special guest, Sandi Metz, to talk about functional versus object-oriented paradigms. Sandi is arguably the most famous Rubyist and is the author of several books on the subject.

Sponsors Sentry use code “devchat” for $100 credit Cloud 66 - Pain Free Rails Deployments: Try Cloud 66 Rails for FREE & get $66 free credits with promo code RubyRogues Panel Charles Max Wood Andrew Mason With Special Guests: David A. Black and Joseph Leo III Episode Summary David A. Black has been a Ruby user for 19 years and has been writing books about Ruby for the last 14 years. Joseph spent 12 years in software and started the company Def Method Inc. Together, they co-authored the book The Well-Grounded Rubyist, which will soon have its third edition released. They give some of the history behind The Well-Grounded Rubyist. Joseph talks about his experience being brought into the project. David and Joseph talk about how The Well-Grounded Rubyist is different from other books on Ruby. This book is helpful because a lot of people begin by understanding Ruby more than Rails, and this book talks about ways to think about Ruby and understand how it’s structure. Joseph and David talk about how The Well-Grounded Rubyist 3rd edition differs from the 2nd edition. The book has been updated so that a lot of the code and solutions for the exercises are available online and there is an additional chapter in part 3 about Ruby dynamics and how one would write functional programming with Ruby The panel discusses how important it is to learn Ruby before starting a job in Rails 2. They agree that if you are a Ruby developer, even if you’re working on Rails apps, so you should know your tools. They discuss how far down that road The Well Grounded Rubyist would get readers. They panelists talk about other books that are a natural prequel or sequel to the The Well-Grounded Rubyist. Joseph and David talk about their approach to reading books and how The Well-Grounded Rubyist should be read. Their goal in making the book was not to have people work on an overarching application while reading the book, but rather there are exercises and examples that you are encouraged to work through. There are some lessons in the book that you won’t write often, but you still need to know how to do it. While the book doesn’t have everything about Ruby, but the examples are designed to give you the best returns for you study. David and Joseph conclude by giving their final thoughts on the book. Links The Well-Grounded Rubyist, Third Edition Perl Programming Ruby 1.9 & 2.0: The Pragmatic Programmers' Guide (The Facets of Ruby) 4th Edition Practical Object-Oriented Design: An Agile Primer Using Ruby (2nd Edition) by Sandi Metz String mutability Follow DevChat on Facebook and Twitter Picks Andrew Mason: Default Gems Charles Max Wood: Good to Great: Why Some Companies Make The Leap and Others Don't by Jim Collins David A. Black: Pragmatic Programmer 2nd edition Davidablack.net and @david_a_black on Twitter Joseph Leo III:  Barbarians at the Gate Firehydrant.io @jleo3 and defmethod.com

Sponsors Sentry use code “devchat” for $100 credit Cloud 66 - Pain Free Rails Deployments: Try Cloud 66 Rails for FREE & get $66 free credits with promo code RubyRogues Panel Charles Max Wood Andrew Mason With Special Guests: David A. Black and Joseph Leo III Episode Summary David A. Black has been a Ruby user for 19 years and has been writing books about Ruby for the last 14 years. Joseph spent 12 years in software and started the company Def Method Inc. Together, they co-authored the book The Well-Grounded Rubyist, which will soon have its third edition released. They give some of the history behind The Well-Grounded Rubyist. Joseph talks about his experience being brought into the project. David and Joseph talk about how The Well-Grounded Rubyist is different from other books on Ruby. This book is helpful because a lot of people begin by understanding Ruby more than Rails, and this book talks about ways to think about Ruby and understand how it’s structure. Joseph and David talk about how The Well-Grounded Rubyist 3rd edition differs from the 2nd edition. The book has been updated so that a lot of the code and solutions for the exercises are available online and there is an additional chapter in part 3 about Ruby dynamics and how one would write functional programming with Ruby The panel discusses how important it is to learn Ruby before starting a job in Rails 2. They agree that if you are a Ruby developer, even if you’re working on Rails apps, so you should know your tools. They discuss how far down that road The Well Grounded Rubyist would get readers. They panelists talk about other books that are a natural prequel or sequel to the The Well-Grounded Rubyist. Joseph and David talk about their approach to reading books and how The Well-Grounded Rubyist should be read. Their goal in making the book was not to have people work on an overarching application while reading the book, but rather there are exercises and examples that you are encouraged to work through. There are some lessons in the book that you won’t write often, but you still need to know how to do it. While the book doesn’t have everything about Ruby, but the examples are designed to give you the best returns for you study. David and Joseph conclude by giving their final thoughts on the book. Links The Well-Grounded Rubyist, Third Edition Perl Programming Ruby 1.9 & 2.0: The Pragmatic Programmers' Guide (The Facets of Ruby) 4th Edition Practical Object-Oriented Design: An Agile Primer Using Ruby (2nd Edition) by Sandi Metz String mutability Follow DevChat on Facebook and Twitter Picks Andrew Mason: Default Gems Charles Max Wood: Good to Great: Why Some Companies Make The Leap and Others Don't by Jim Collins David A. Black: Pragmatic Programmer 2nd edition Davidablack.net and @david_a_black on Twitter Joseph Leo III:  Barbarians at the Gate Firehydrant.io @jleo3 and defmethod.com

Sponsors Sentry use code “devchat” for $100 credit Cloud 66 - Pain Free Rails Deployments: Try Cloud 66 Rails for FREE & get $66 free credits with promo code RubyRogues Panel Charles Max Wood Andrew Mason With Special Guests: David A. Black and Joseph Leo III Episode Summary David A. Black has been a Ruby user for 19 years and has been writing books about Ruby for the last 14 years. Joseph spent 12 years in software and started the company Def Method Inc. Together, they co-authored the book The Well-Grounded Rubyist, which will soon have its third edition released. They give some of the history behind The Well-Grounded Rubyist. Joseph talks about his experience being brought into the project. David and Joseph talk about how The Well-Grounded Rubyist is different from other books on Ruby. This book is helpful because a lot of people begin by understanding Ruby more than Rails, and this book talks about ways to think about Ruby and understand how it’s structure. Joseph and David talk about how The Well-Grounded Rubyist 3rd edition differs from the 2nd edition. The book has been updated so that a lot of the code and solutions for the exercises are available online and there is an additional chapter in part 3 about Ruby dynamics and how one would write functional programming with Ruby The panel discusses how important it is to learn Ruby before starting a job in Rails 2. They agree that if you are a Ruby developer, even if you’re working on Rails apps, so you should know your tools. They discuss how far down that road The Well Grounded Rubyist would get readers. They panelists talk about other books that are a natural prequel or sequel to the The Well-Grounded Rubyist. Joseph and David talk about their approach to reading books and how The Well-Grounded Rubyist should be read. Their goal in making the book was not to have people work on an overarching application while reading the book, but rather there are exercises and examples that you are encouraged to work through. There are some lessons in the book that you won’t write often, but you still need to know how to do it. While the book doesn’t have everything about Ruby, but the examples are designed to give you the best returns for you study. David and Joseph conclude by giving their final thoughts on the book. Links The Well-Grounded Rubyist, Third Edition Perl Programming Ruby 1.9 & 2.0: The Pragmatic Programmers' Guide (The Facets of Ruby) 4th Edition Practical Object-Oriented Design: An Agile Primer Using Ruby (2nd Edition) by Sandi Metz String mutability Follow DevChat on Facebook and Twitter Picks Andrew Mason: Default Gems Charles Max Wood: Good to Great: Why Some Companies Make The Leap and Others Don't by Jim Collins David A. Black: Pragmatic Programmer 2nd edition Davidablack.net and @david_a_black on Twitter Joseph Leo III:  Barbarians at the Gate Firehydrant.io @jleo3 and defmethod.com

stdout.fm 33번째 로그에서는 Matz 블로그 부활, 기술서전, 구글 클라우드 장애, WWDC 2019 등에 대해서 이야기를 나눴습니다. 참가자: @seapy, @nacyo_t, @raccoonyy GNU Ethical Repository Criteria - GNU Project - Free Software Foundation ridi/select-frontend: RIDI Select Web Frontend stdout.fm are creating 클라우드, 소프트웨어 개발, 전자 제품에 대해 이야기하는 프로그래머들의 팟캐스트 | Patreon ODK media BambooHR 미림타워: 네이버 지도 마츠모토 유키히로의 프로그래밍 언어 만들기 - Ruby 및 Streem을 통한 언어 제작 과정 살펴보기 | 에이콘출판사 - 마이크로소프트웨어 – MICROSOFTWARE (일본어) WEB+DB PRESS｜gihyo.jp … 정보평론사 (일본어) 닛케이 리눅스 matz/streem: prototype of stream based programming language LangDev (일본어) 루비 매거진(るびま) (일본어) Rubyist를 위한 다른 언어 탐방 のための他言語探訪 【제 1 회】 Python | 루비 매거진 (일보넝) Matz일기(2019-05-31) (일본어) Ruby 1.8.0 リリース! (일본어) 루비로 만드는 루비 - 제로부터 다시 배우는 프로그래밍 언어 입문 - 기술출판사 람다노트 The International Obfuscated C Code Contest (일본어) TRICK 2018 (FINAL) - RubyKaigi 2018 (일본어) ASCII.jp：루비로 배우는 루비 프로그래밍 클라우드 기술 블로그 — 44bits.io (일본어) 기술서전 (일본어) 기술서전 6의 판매 서적 | BOOTH 아마존 엘라스틱 컨테이너 서비스(ECS)와 도커(Docker)로 시작하는 컨테이너 오케스트레이션 | 44bits.io Google Cloud Status Dashboard Chapter 3 - Embracing Risk - Site Reliability Engineering 통신장애 발생시 이용자에 즉시 통보 의무화 :: 공감언론 뉴시스통신사 :: stdout_006.log: KT 서울 서북부 통신 장애, AWS re:Invent 2018 | 개발자 팟캐스트 stdout.fm Ubiquiti Networks - Software Mac Pro - Apple 방구석 리뷰룸 - YouTube 디에디트 – THE EDIT 홈 | Official ESTA Application Website, U.S. Customs and Border Protection Kitze on Twitter: “Jony Ive explaining the new functionality to Tim Cook #WWDC19 https://t.co/hwY2JfzIeG” / Twitter Pro Display XDR - Apple iPadOS Preview - Apple iOS 13 Preview - Apple Xcode - SwiftUI - Apple Developer

Sponsors: Sentry use the code “devchat” for 2 months free on Sentry small plan CacheFly Host: Charles Max Wood Special Guest:  Josh Justice Episode Summary In this episode of My Ruby Story, Charles hosts Josh Justice, software engineer at Big Nerd Ranch, a Mobile app development, training and design firm. Listen to Josh on the podcast Ruby Rogues on this episode. Josh wanted to be a software developer ever since he was very young, his father worked in IT so he had access to computers from very early on. After studying computer science, he started working as a developer in JavaScript, PHP and in Ruby. His specialties include Ruby on Rails, Ember, Vue.js and React Native. Josh really enjoys content creation for other developers and is currently streaming React Native TDD Fridays 2pm EST at Twitch.tv. Josh and his family recently adopted a baby boy in addition to his two daughters. Listen to the podcast to hear more about this miraculous adoption story! Links Ruby Rogues 391: Frontend Testing Like a Rubyist with Josh Justice React Native Testing feat. Josh Justice of Big Nerd Ranch Josh’s Twitter Josh’s GitHub Josh’s LinkedIn Michael Hartl's Ruby on Rails Tutorial Josh's Blog Learn Test-Driven Development Object Oriented and Functional Programming Blog Post https://devchat.tv/ruby-rogues/ https://devchat.tv/my-ruby-story/ https://www.facebook.com/DevChattv Picks Josh Justice: Webpacker Object Thinking Learn Test-Driven Development Ember and Rails Live Stream   Charles Max Wood: The Effective Executive by Peter F. Drucker      

Sponsors: Sentry use the code “devchat” for 2 months free on Sentry small plan CacheFly Host: Charles Max Wood Special Guest:  Josh Justice Episode Summary In this episode of My Ruby Story, Charles hosts Josh Justice, software engineer at Big Nerd Ranch, a Mobile app development, training and design firm. Listen to Josh on the podcast Ruby Rogues on this episode. Josh wanted to be a software developer ever since he was very young, his father worked in IT so he had access to computers from very early on. After studying computer science, he started working as a developer in JavaScript, PHP and in Ruby. His specialties include Ruby on Rails, Ember, Vue.js and React Native. Josh really enjoys content creation for other developers and is currently streaming React Native TDD Fridays 2pm EST at Twitch.tv. Josh and his family recently adopted a baby boy in addition to his two daughters. Listen to the podcast to hear more about this miraculous adoption story! Links Ruby Rogues 391: Frontend Testing Like a Rubyist with Josh Justice React Native Testing feat. Josh Justice of Big Nerd Ranch Josh’s Twitter Josh’s GitHub Josh’s LinkedIn Michael Hartl's Ruby on Rails Tutorial Josh's Blog Learn Test-Driven Development Object Oriented and Functional Programming Blog Post https://devchat.tv/ruby-rogues/ https://devchat.tv/my-ruby-story/ https://www.facebook.com/DevChattv Picks Josh Justice: Webpacker Object Thinking Learn Test-Driven Development Ember and Rails Live Stream   Charles Max Wood: The Effective Executive by Peter F. Drucker      

Sponsors: Sentry use the code “devchat” for 2 months free on Sentry small plan CacheFly Host: Charles Max Wood Special Guest:  Josh Justice Episode Summary In this episode of My Ruby Story, Charles hosts Josh Justice, software engineer at Big Nerd Ranch, a Mobile app development, training and design firm. Listen to Josh on the podcast Ruby Rogues on this episode. Josh wanted to be a software developer ever since he was very young, his father worked in IT so he had access to computers from very early on. After studying computer science, he started working as a developer in JavaScript, PHP and in Ruby. His specialties include Ruby on Rails, Ember, Vue.js and React Native. Josh really enjoys content creation for other developers and is currently streaming React Native TDD Fridays 2pm EST at Twitch.tv. Josh and his family recently adopted a baby boy in addition to his two daughters. Listen to the podcast to hear more about this miraculous adoption story! Links Ruby Rogues 391: Frontend Testing Like a Rubyist with Josh Justice React Native Testing feat. Josh Justice of Big Nerd Ranch Josh’s Twitter Josh’s GitHub Josh’s LinkedIn Michael Hartl's Ruby on Rails Tutorial Josh's Blog Learn Test-Driven Development Object Oriented and Functional Programming Blog Post https://devchat.tv/ruby-rogues/ https://devchat.tv/my-ruby-story/ https://www.facebook.com/DevChattv Picks Josh Justice: Webpacker Object Thinking Learn Test-Driven Development Ember and Rails Live Stream   Charles Max Wood: The Effective Executive by Peter F. Drucker      

Panel: Dave Kimura Charles Max Wood Nate Hopkins Special Guest: Josh Justice In this episode of Ruby Rogues, the panelists talk with Josh Justice who is a developer, writer, and speaker. Josh streams JavaScript and web development on Friday’s at 2:00 PM (ET) here! The panelists and the guest talk about Josh’s background and frontend testing in Ruby. Check it out! Show Topics: 0:00 – Advertisement: Sentry.io 1:04 – Chuck: Hi! Dave, Nate, and myself are on the panel and our special guest is Josh Justice! I am developing a show about developer freedom and it’s called The DevRev. It will be streamed through YouTube, and I will record Friday afternoons. Check out Facebook, too! 2:11 – Josh: Thanks! I am happy to be here! 2:18 – Chuck: Introduce yourself, please! 2:24 – Josh: I have been a developer for about 14 years. I have used PHP and then got into Ruby and then frontend development. 2:46 – Chuck: You work for Big Nerd Ranch in Atlanta? 2:56 – Josh: Yep for the last 3-4 years! 3:15 – Chuck: Can you introduce the topic? 3:25 – The guest talks about Big Nerd Ranch and frontend development. Learn TDD is mentioned, too! Check it out here! 5:06 – Panel: How much bouncing do you do between React and Vue? 5:11 – Guest. 5:47 – Chuck: We need to get you on our podcast shows for React and Vue! It’s an approach that I am familiar with in Ruby – and Selenium what a pain! 6:16 – Guest: I’ve had a good experience with Cypress, actually! 7:47 – Guest: Panelist, can you share your experiences? 7:57 – Panel: Not bad experiences with testing, but now I am trying to minimize my use with JavaScript. 8:30 – Guest: I think there is a big push towards considering more server site rendering. 9:35 – Panel: What’s your recommendation to setup Cypress? 9:40 – Guest: Their docs are really great! They had some conference talks on how to set it up! 10:15 – Guest: Check out my talks about this topic. (Connect Tech 2018). 10:29 – Panel: I think Cypress is a pretty cool solution but one thing that left me confused is that you have to have an environment that is already stood-up and running. Is that accurate or has that changed? 11:00 – Guest: Can you clarify what you mean by a “running environment”? 11:04 – Panelist clarifies. 11:44 – Guest: Luckily for me I have something to say b/c I tried a week ago! 12:01 – Guest mentions Vue CLI 3. 14:38 – Panel: How can you test your code coverage? I want to know how much of my code coverage am I hitting? The applications are up and running, it’s not going through the files (per se), and is there anything that would indicate how good your coverage is with the Cypress test? 15:10 – Guest: Let me as a follow-up question: How do you approach it on the frontend? 15:24 – Panelist answers the guest’s question. 16:06 – The guest mentions Vue CLI 2 & 3. 18:31 – Chuck: Are you using the tool Istanbul? 18:36 – Guest: Yep Istanbul is the one! 18:54 – Chuck: I’ve heard some similar rumors, but can’t say. 19:02 – Panelist talks. 20:13 – Chuck: I have been working on a project and what doesn’t get test-coverage gets a candidate to get pulled-out. 20:40 – Guest: Talking about test-driven development... Guest: Have you read the original book? 21:02 – Guest: The book: “Effective Testing with RSpec 3” is updated information – check it out! The guest mentions his live stream on Friday’s. Check out the links found below! 23:57 – Panel: How is the stability with tests like Cypress with end-to-end tests? If you are testing with a login then the user has to be already created. Or what about a Twitter app – the user has to be created and not followed? How do you handle that? 24:22 – Guest: I think we are spoiled in the Rails world b/c of those... 24:53 – The guest answers the panelist’s question! 26:59 – Fresh Books! 28:07 – Guest: Does that help? 28:10 – Panel. 28:21 – Guest: I have been thinking about this, though, recently. Thinking about the contracts through the business. I have dabbled with native development and I see the cost that runs a native app. 30:21 – Panel: It’s refreshing to hear the new market’s demands. I truly haven’t seen an application that requires that. I have built some extensive applications and also very simple ones, too; the need for productivity. 31:17 – Guest mentions a talk at a conference. See here for that information! 31:43 – Guest: I have a friend who was a new developer and he really knows his stuff. He said that he didn’t know if he could be a full stack developer in the next 5-10 years. Wait a minute?! Guest: The freedom to create something that stands alone. Guest: Tom Dale is mentioned by the Guest. 33:35 – Panel: To choose Rails as a new developer (today) it’s not as easy as it was back in the day. Today you have Active Job, Action Cable and so many other components. It’s more complicated today then it was in the past. It could be overwhelming to a new developer. 35:00 – Chuck: I think a lot of that is the community’s fault and not Rails’ fault. 35:57 – Panel. 36:04 – Panel: The counter-argument could say that’s where server-less come in. 36:27 – Chuck: To some degree you can get away with it. You don’t have to worry about the infrastructure or anything else. 36:44 – Panel: Have you tried messing around with server-less functions with AWS? I have and...it’s not easy. There is not a good flow or good work flow in a server-less environment. 38:01 – Chuck: You can go to this website. It makes the setup easier b/c you are adding your Azure or AWS features. 38:30 – Panel: This topic, though, does tie back to the testing topic we were talking about earlier! 39:14 – Panel: Yeah that is why I haven’t gotten into server-less things. The Rails holistic approach is so appealing. 40:14 – Panel continues: I want to take smaller steps when it comes to technology! I want to move into things that we are laying down the tracks to make it easier travelable. That way we can consider the things we’ve learned in the past and help those in the future. 41:07 – Chuck: What are lacking then? What is the friction that is left? Seems like Cypress helped removed that but maybe not? 42:02 – Panelist mentions Cypress, Jest, Mocha, and others! 43:10 – Panel (continues): I am all about experimenting but I want to know all the reasons. What has changed and what hasn’t’ changed? 43:29 – Panel: There is an article written that talks about this topic. 43:59 – Guest mentions the video “Is TDD Dead?” (See links below.) 44:29 – Guest: I like brining thoughts together and taking his or her input and come up with my own thoughts.  46:32 – Guest (continues): The testing trophy is heavier on the top (picture of a trophy). Guest: I think the thing that draws me to unit testing is that... 47:37 – Guest: I am obsessed with testing. The guest gives a summary here! 48:15 – Chuck: We talked with Quincy Larson last week and it’s a really good take on what we are doing and what we are trying to accomplish with our tests. Check it out – it’s coming out soon! 49:05 – Panel: When you are younger into your career – the way you think about structuring your code – when you are comfortable you really don’t need that guidance. 50:00 – Guest: I would encourage folks who were new to coding to do the following... 51:36 – Guest: Think about WHY you are doing (what you are doing) and being able to articulate well what you are doing and why. 52:03 – Panel: There is no question – every time I test I am surprised how much it shapes my thinking about the code and how many bugs that I catch even in code that I thought was operating well. When you go too far though there is a fallacy there. 52:54 – Panel: Yes, testing is very important. I am a test-after-the-fact programmer. That is my self-key term. Don’t write 500-line methods b/c you won’t be able to test that. Don’t make it too abstract so have a common pattern that you will use. Have a lot of private methods that aren’t exposed to the API. 54:03 – Guest: Yes thinking about how to structure your code can be challenging at first but it gets easier. 55:58 – Chuck: I have had talks with Corey Haines about topics like this! 56:47 – Guest: Yes it can be helpful in consultancy now. 59:23 – Guest: Think about this: choosing what level to test at. 1:00:14 – Panel: It’s hard b/c it changes all the time per function or something else. There are tradeoffs with everything we do. 1:00:41 – Chuck: You are the consultant it depends doesn’t it? 1:00:51 – Picks! 1:00:55 – Advertisement: Get A Coder Job! End – Cache Fly! Links: Get a Coder Job Course Ruby Ruby on Rails Angular Cypress Vue React VUE CLI 3 Jest.io Mocha.js GitHub: Istanbul The RSpec Book RR 068 Episode Ember CLI GitHub: Factory_Bot GitHub: VCR Big Nerd Ranch Big Nerd Ranch: Josh Justice / Team Manager The Bike Shed Keynote: Tom Dale @ EmberFest 2018 JSJ 291 Episode Serverless Article: Test-Induced Design Damage Video: Is TDD Dead? Music: Sub Conscious – Electronic / 2004 Music: Interloper / 2015 Disney Heroes: Battle Mode Google Play: Disney Heroes / Battle Mode Book Authoring Playlist Tom Dale’s Twitter Corey Haines’ Twitter Coding It Wrong Josh’s Twitter Josh’s GitHub Josh’s LinkedIn Josh’s Vimeo Video Sponsors: Sentry CacheFly Fresh Books Picks: Nate Phutureprimitive - Sub Conscious Carbon Based Lifeforms - Interloper Dave Dust collections system in Wood Shop Doctor Who  - Theme Music Charles Authoring music Disney Hero Battles Josh Effecting Testing with RSpec 3 Growing Object-Oriented Software, Guided by Test XUnit Test Patterns Spectacle App Alfred App

Panel: Dave Kimura Charles Max Wood Nate Hopkins Special Guest: Josh Justice In this episode of Ruby Rogues, the panelists talk with Josh Justice who is a developer, writer, and speaker. Josh streams JavaScript and web development on Friday’s at 2:00 PM (ET) here! The panelists and the guest talk about Josh’s background and frontend testing in Ruby. Check it out! Show Topics: 0:00 – Advertisement: Sentry.io 1:04 – Chuck: Hi! Dave, Nate, and myself are on the panel and our special guest is Josh Justice! I am developing a show about developer freedom and it’s called The DevRev. It will be streamed through YouTube, and I will record Friday afternoons. Check out Facebook, too! 2:11 – Josh: Thanks! I am happy to be here! 2:18 – Chuck: Introduce yourself, please! 2:24 – Josh: I have been a developer for about 14 years. I have used PHP and then got into Ruby and then frontend development. 2:46 – Chuck: You work for Big Nerd Ranch in Atlanta? 2:56 – Josh: Yep for the last 3-4 years! 3:15 – Chuck: Can you introduce the topic? 3:25 – The guest talks about Big Nerd Ranch and frontend development. Learn TDD is mentioned, too! Check it out here! 5:06 – Panel: How much bouncing do you do between React and Vue? 5:11 – Guest. 5:47 – Chuck: We need to get you on our podcast shows for React and Vue! It’s an approach that I am familiar with in Ruby – and Selenium what a pain! 6:16 – Guest: I’ve had a good experience with Cypress, actually! 7:47 – Guest: Panelist, can you share your experiences? 7:57 – Panel: Not bad experiences with testing, but now I am trying to minimize my use with JavaScript. 8:30 – Guest: I think there is a big push towards considering more server site rendering. 9:35 – Panel: What’s your recommendation to setup Cypress? 9:40 – Guest: Their docs are really great! They had some conference talks on how to set it up! 10:15 – Guest: Check out my talks about this topic. (Connect Tech 2018). 10:29 – Panel: I think Cypress is a pretty cool solution but one thing that left me confused is that you have to have an environment that is already stood-up and running. Is that accurate or has that changed? 11:00 – Guest: Can you clarify what you mean by a “running environment”? 11:04 – Panelist clarifies. 11:44 – Guest: Luckily for me I have something to say b/c I tried a week ago! 12:01 – Guest mentions Vue CLI 3. 14:38 – Panel: How can you test your code coverage? I want to know how much of my code coverage am I hitting? The applications are up and running, it’s not going through the files (per se), and is there anything that would indicate how good your coverage is with the Cypress test? 15:10 – Guest: Let me as a follow-up question: How do you approach it on the frontend? 15:24 – Panelist answers the guest’s question. 16:06 – The guest mentions Vue CLI 2 & 3. 18:31 – Chuck: Are you using the tool Istanbul? 18:36 – Guest: Yep Istanbul is the one! 18:54 – Chuck: I’ve heard some similar rumors, but can’t say. 19:02 – Panelist talks. 20:13 – Chuck: I have been working on a project and what doesn’t get test-coverage gets a candidate to get pulled-out. 20:40 – Guest: Talking about test-driven development... Guest: Have you read the original book? 21:02 – Guest: The book: “Effective Testing with RSpec 3” is updated information – check it out! The guest mentions his live stream on Friday’s. Check out the links found below! 23:57 – Panel: How is the stability with tests like Cypress with end-to-end tests? If you are testing with a login then the user has to be already created. Or what about a Twitter app – the user has to be created and not followed? How do you handle that? 24:22 – Guest: I think we are spoiled in the Rails world b/c of those... 24:53 – The guest answers the panelist’s question! 26:59 – Fresh Books! 28:07 – Guest: Does that help? 28:10 – Panel. 28:21 – Guest: I have been thinking about this, though, recently. Thinking about the contracts through the business. I have dabbled with native development and I see the cost that runs a native app. 30:21 – Panel: It’s refreshing to hear the new market’s demands. I truly haven’t seen an application that requires that. I have built some extensive applications and also very simple ones, too; the need for productivity. 31:17 – Guest mentions a talk at a conference. See here for that information! 31:43 – Guest: I have a friend who was a new developer and he really knows his stuff. He said that he didn’t know if he could be a full stack developer in the next 5-10 years. Wait a minute?! Guest: The freedom to create something that stands alone. Guest: Tom Dale is mentioned by the Guest. 33:35 – Panel: To choose Rails as a new developer (today) it’s not as easy as it was back in the day. Today you have Active Job, Action Cable and so many other components. It’s more complicated today then it was in the past. It could be overwhelming to a new developer. 35:00 – Chuck: I think a lot of that is the community’s fault and not Rails’ fault. 35:57 – Panel. 36:04 – Panel: The counter-argument could say that’s where server-less come in. 36:27 – Chuck: To some degree you can get away with it. You don’t have to worry about the infrastructure or anything else. 36:44 – Panel: Have you tried messing around with server-less functions with AWS? I have and...it’s not easy. There is not a good flow or good work flow in a server-less environment. 38:01 – Chuck: You can go to this website. It makes the setup easier b/c you are adding your Azure or AWS features. 38:30 – Panel: This topic, though, does tie back to the testing topic we were talking about earlier! 39:14 – Panel: Yeah that is why I haven’t gotten into server-less things. The Rails holistic approach is so appealing. 40:14 – Panel continues: I want to take smaller steps when it comes to technology! I want to move into things that we are laying down the tracks to make it easier travelable. That way we can consider the things we’ve learned in the past and help those in the future. 41:07 – Chuck: What are lacking then? What is the friction that is left? Seems like Cypress helped removed that but maybe not? 42:02 – Panelist mentions Cypress, Jest, Mocha, and others! 43:10 – Panel (continues): I am all about experimenting but I want to know all the reasons. What has changed and what hasn’t’ changed? 43:29 – Panel: There is an article written that talks about this topic. 43:59 – Guest mentions the video “Is TDD Dead?” (See links below.) 44:29 – Guest: I like brining thoughts together and taking his or her input and come up with my own thoughts.  46:32 – Guest (continues): The testing trophy is heavier on the top (picture of a trophy). Guest: I think the thing that draws me to unit testing is that... 47:37 – Guest: I am obsessed with testing. The guest gives a summary here! 48:15 – Chuck: We talked with Quincy Larson last week and it’s a really good take on what we are doing and what we are trying to accomplish with our tests. Check it out – it’s coming out soon! 49:05 – Panel: When you are younger into your career – the way you think about structuring your code – when you are comfortable you really don’t need that guidance. 50:00 – Guest: I would encourage folks who were new to coding to do the following... 51:36 – Guest: Think about WHY you are doing (what you are doing) and being able to articulate well what you are doing and why. 52:03 – Panel: There is no question – every time I test I am surprised how much it shapes my thinking about the code and how many bugs that I catch even in code that I thought was operating well. When you go too far though there is a fallacy there. 52:54 – Panel: Yes, testing is very important. I am a test-after-the-fact programmer. That is my self-key term. Don’t write 500-line methods b/c you won’t be able to test that. Don’t make it too abstract so have a common pattern that you will use. Have a lot of private methods that aren’t exposed to the API. 54:03 – Guest: Yes thinking about how to structure your code can be challenging at first but it gets easier. 55:58 – Chuck: I have had talks with Corey Haines about topics like this! 56:47 – Guest: Yes it can be helpful in consultancy now. 59:23 – Guest: Think about this: choosing what level to test at. 1:00:14 – Panel: It’s hard b/c it changes all the time per function or something else. There are tradeoffs with everything we do. 1:00:41 – Chuck: You are the consultant it depends doesn’t it? 1:00:51 – Picks! 1:00:55 – Advertisement: Get A Coder Job! End – Cache Fly! Links: Get a Coder Job Course Ruby Ruby on Rails Angular Cypress Vue React VUE CLI 3 Jest.io Mocha.js GitHub: Istanbul The RSpec Book RR 068 Episode Ember CLI GitHub: Factory_Bot GitHub: VCR Big Nerd Ranch Big Nerd Ranch: Josh Justice / Team Manager The Bike Shed Keynote: Tom Dale @ EmberFest 2018 JSJ 291 Episode Serverless Article: Test-Induced Design Damage Video: Is TDD Dead? Music: Sub Conscious – Electronic / 2004 Music: Interloper / 2015 Disney Heroes: Battle Mode Google Play: Disney Heroes / Battle Mode Book Authoring Playlist Tom Dale’s Twitter Corey Haines’ Twitter Coding It Wrong Josh’s Twitter Josh’s GitHub Josh’s LinkedIn Josh’s Vimeo Video Sponsors: Sentry CacheFly Fresh Books Picks: Nate Phutureprimitive - Sub Conscious Carbon Based Lifeforms - Interloper Dave Dust collections system in Wood Shop Doctor Who  - Theme Music Charles Authoring music Disney Hero Battles Josh Effecting Testing with RSpec 3 Growing Object-Oriented Software, Guided by Test XUnit Test Patterns Spectacle App Alfred App

Panel: Dave Kimura Charles Max Wood Nate Hopkins Special Guest: Josh Justice In this episode of Ruby Rogues, the panelists talk with Josh Justice who is a developer, writer, and speaker. Josh streams JavaScript and web development on Friday’s at 2:00 PM (ET) here! The panelists and the guest talk about Josh’s background and frontend testing in Ruby. Check it out! Show Topics: 0:00 – Advertisement: Sentry.io 1:04 – Chuck: Hi! Dave, Nate, and myself are on the panel and our special guest is Josh Justice! I am developing a show about developer freedom and it’s called The DevRev. It will be streamed through YouTube, and I will record Friday afternoons. Check out Facebook, too! 2:11 – Josh: Thanks! I am happy to be here! 2:18 – Chuck: Introduce yourself, please! 2:24 – Josh: I have been a developer for about 14 years. I have used PHP and then got into Ruby and then frontend development. 2:46 – Chuck: You work for Big Nerd Ranch in Atlanta? 2:56 – Josh: Yep for the last 3-4 years! 3:15 – Chuck: Can you introduce the topic? 3:25 – The guest talks about Big Nerd Ranch and frontend development. Learn TDD is mentioned, too! Check it out here! 5:06 – Panel: How much bouncing do you do between React and Vue? 5:11 – Guest. 5:47 – Chuck: We need to get you on our podcast shows for React and Vue! It’s an approach that I am familiar with in Ruby – and Selenium what a pain! 6:16 – Guest: I’ve had a good experience with Cypress, actually! 7:47 – Guest: Panelist, can you share your experiences? 7:57 – Panel: Not bad experiences with testing, but now I am trying to minimize my use with JavaScript. 8:30 – Guest: I think there is a big push towards considering more server site rendering. 9:35 – Panel: What’s your recommendation to setup Cypress? 9:40 – Guest: Their docs are really great! They had some conference talks on how to set it up! 10:15 – Guest: Check out my talks about this topic. (Connect Tech 2018). 10:29 – Panel: I think Cypress is a pretty cool solution but one thing that left me confused is that you have to have an environment that is already stood-up and running. Is that accurate or has that changed? 11:00 – Guest: Can you clarify what you mean by a “running environment”? 11:04 – Panelist clarifies. 11:44 – Guest: Luckily for me I have something to say b/c I tried a week ago! 12:01 – Guest mentions Vue CLI 3. 14:38 – Panel: How can you test your code coverage? I want to know how much of my code coverage am I hitting? The applications are up and running, it’s not going through the files (per se), and is there anything that would indicate how good your coverage is with the Cypress test? 15:10 – Guest: Let me as a follow-up question: How do you approach it on the frontend? 15:24 – Panelist answers the guest’s question. 16:06 – The guest mentions Vue CLI 2 & 3. 18:31 – Chuck: Are you using the tool Istanbul? 18:36 – Guest: Yep Istanbul is the one! 18:54 – Chuck: I’ve heard some similar rumors, but can’t say. 19:02 – Panelist talks. 20:13 – Chuck: I have been working on a project and what doesn’t get test-coverage gets a candidate to get pulled-out. 20:40 – Guest: Talking about test-driven development... Guest: Have you read the original book? 21:02 – Guest: The book: “Effective Testing with RSpec 3” is updated information – check it out! The guest mentions his live stream on Friday’s. Check out the links found below! 23:57 – Panel: How is the stability with tests like Cypress with end-to-end tests? If you are testing with a login then the user has to be already created. Or what about a Twitter app – the user has to be created and not followed? How do you handle that? 24:22 – Guest: I think we are spoiled in the Rails world b/c of those... 24:53 – The guest answers the panelist’s question! 26:59 – Fresh Books! 28:07 – Guest: Does that help? 28:10 – Panel. 28:21 – Guest: I have been thinking about this, though, recently. Thinking about the contracts through the business. I have dabbled with native development and I see the cost that runs a native app. 30:21 – Panel: It’s refreshing to hear the new market’s demands. I truly haven’t seen an application that requires that. I have built some extensive applications and also very simple ones, too; the need for productivity. 31:17 – Guest mentions a talk at a conference. See here for that information! 31:43 – Guest: I have a friend who was a new developer and he really knows his stuff. He said that he didn’t know if he could be a full stack developer in the next 5-10 years. Wait a minute?! Guest: The freedom to create something that stands alone. Guest: Tom Dale is mentioned by the Guest. 33:35 – Panel: To choose Rails as a new developer (today) it’s not as easy as it was back in the day. Today you have Active Job, Action Cable and so many other components. It’s more complicated today then it was in the past. It could be overwhelming to a new developer. 35:00 – Chuck: I think a lot of that is the community’s fault and not Rails’ fault. 35:57 – Panel. 36:04 – Panel: The counter-argument could say that’s where server-less come in. 36:27 – Chuck: To some degree you can get away with it. You don’t have to worry about the infrastructure or anything else. 36:44 – Panel: Have you tried messing around with server-less functions with AWS? I have and...it’s not easy. There is not a good flow or good work flow in a server-less environment. 38:01 – Chuck: You can go to this website. It makes the setup easier b/c you are adding your Azure or AWS features. 38:30 – Panel: This topic, though, does tie back to the testing topic we were talking about earlier! 39:14 – Panel: Yeah that is why I haven’t gotten into server-less things. The Rails holistic approach is so appealing. 40:14 – Panel continues: I want to take smaller steps when it comes to technology! I want to move into things that we are laying down the tracks to make it easier travelable. That way we can consider the things we’ve learned in the past and help those in the future. 41:07 – Chuck: What are lacking then? What is the friction that is left? Seems like Cypress helped removed that but maybe not? 42:02 – Panelist mentions Cypress, Jest, Mocha, and others! 43:10 – Panel (continues): I am all about experimenting but I want to know all the reasons. What has changed and what hasn’t’ changed? 43:29 – Panel: There is an article written that talks about this topic. 43:59 – Guest mentions the video “Is TDD Dead?” (See links below.) 44:29 – Guest: I like brining thoughts together and taking his or her input and come up with my own thoughts.  46:32 – Guest (continues): The testing trophy is heavier on the top (picture of a trophy). Guest: I think the thing that draws me to unit testing is that... 47:37 – Guest: I am obsessed with testing. The guest gives a summary here! 48:15 – Chuck: We talked with Quincy Larson last week and it’s a really good take on what we are doing and what we are trying to accomplish with our tests. Check it out – it’s coming out soon! 49:05 – Panel: When you are younger into your career – the way you think about structuring your code – when you are comfortable you really don’t need that guidance. 50:00 – Guest: I would encourage folks who were new to coding to do the following... 51:36 – Guest: Think about WHY you are doing (what you are doing) and being able to articulate well what you are doing and why. 52:03 – Panel: There is no question – every time I test I am surprised how much it shapes my thinking about the code and how many bugs that I catch even in code that I thought was operating well. When you go too far though there is a fallacy there. 52:54 – Panel: Yes, testing is very important. I am a test-after-the-fact programmer. That is my self-key term. Don’t write 500-line methods b/c you won’t be able to test that. Don’t make it too abstract so have a common pattern that you will use. Have a lot of private methods that aren’t exposed to the API. 54:03 – Guest: Yes thinking about how to structure your code can be challenging at first but it gets easier. 55:58 – Chuck: I have had talks with Corey Haines about topics like this! 56:47 – Guest: Yes it can be helpful in consultancy now. 59:23 – Guest: Think about this: choosing what level to test at. 1:00:14 – Panel: It’s hard b/c it changes all the time per function or something else. There are tradeoffs with everything we do. 1:00:41 – Chuck: You are the consultant it depends doesn’t it? 1:00:51 – Picks! 1:00:55 – Advertisement: Get A Coder Job! End – Cache Fly! Links: Get a Coder Job Course Ruby Ruby on Rails Angular Cypress Vue React VUE CLI 3 Jest.io Mocha.js GitHub: Istanbul The RSpec Book RR 068 Episode Ember CLI GitHub: Factory_Bot GitHub: VCR Big Nerd Ranch Big Nerd Ranch: Josh Justice / Team Manager The Bike Shed Keynote: Tom Dale @ EmberFest 2018 JSJ 291 Episode Serverless Article: Test-Induced Design Damage Video: Is TDD Dead? Music: Sub Conscious – Electronic / 2004 Music: Interloper / 2015 Disney Heroes: Battle Mode Google Play: Disney Heroes / Battle Mode Book Authoring Playlist Tom Dale’s Twitter Corey Haines’ Twitter Coding It Wrong Josh’s Twitter Josh’s GitHub Josh’s LinkedIn Josh’s Vimeo Video Sponsors: Sentry CacheFly Fresh Books Picks: Nate Phutureprimitive - Sub Conscious Carbon Based Lifeforms - Interloper Dave Dust collections system in Wood Shop Doctor Who  - Theme Music Charles Authoring music Disney Hero Battles Josh Effecting Testing with RSpec 3 Growing Object-Oriented Software, Guided by Test XUnit Test Patterns Spectacle App Alfred App

Panel: Charles Max Wood David Richards Dave Kimura Eric Berry Special Guests: John Hawthorn In this episode of Ruby Rogues, the panel talks to John Hawthorn about MJIT. John has been a Ruby programmer for about 9 years and is based in Victoria, B.C. They talk about what MJIT is, the effects you can see from using the MJIT compiler, and why the JIT doesn’t always work with other languages. They also touch on how you can use the JIT in your own code, how he makes his performance better, and more! Show Topics: 1:36 – John is a Ruby programmer, and has been one for the past 9 years, and he is based out of Victoria, B.C. 5:00 – He had always been curious how a JIT would work and found that it was always too difficult to work with. Since discovering MJIT, he has been able to work with these compilers because he understands how to work with C code. 7:36 – Ruby has a bytecode and it looks a lot like an assembly language, which is approachable to a Rubyist. 8:24 – The core of MJIT is an ERB template which take this bytecode, loops over it, and emits C code. 9:01 – Effects that you can seem from the JIT in your own code is that it uses a really tight math loop, making your code faster. 11:25 – Other languages aren’t suited for compilers like JIT because they are so flexible to begin with. And in some cases, it doesn’t make sense to JIT compile. 13:05 – The compiled code now is not reusable by other workers and works better with one compilation per process. 15:20 – The temp folder gets cleared immediately after its run, but this compiled code is probably going to stay in memory forever. 17:30 – The MJIT doesn’t work as well with Rails because the code can’t get warmed up enough. Some things aren’t friendly to a JIT. 20:24 – If someone wants to play with the JIT, as long as you have any Ruby version manager, install any of the previewed releases of 2.6 and then run with --jit. 21:44 – Online, you can look into following people who have written various Ruby libraries to look at performance. You can look at people like Sam Saffron and Julia Evans. 23:57 –TruffleRuby is a new front-end on top of a mature virtual machine whereas MJIT is a brand new virtual machine on top of a Ruby front-end. 27:57 – The MJIT had no effect on his work, it was just really fun and interesting to look into. 28:29 – To make his performance better, he allocates fewer objects, does less loops, and writes better queries. 29:02 – You want to run a profiler that will give you a better idea of where to look for performance issues, but you really need a proper benchmark to say what is wrong with your performance. A great benchmark you can use is benchmark-ips. 31:59 – The “gotcha” of doing this kind of work is verifying that you’ve actually improved it. 33:41 – Before we have the JIT in production, we are going to be using these techniques to find out if the JIT is helping us. Links: Get a Coder Job Course Ruby MJIT Playing with ruby's new JIT: MJIT by John Hawthorn Rails Bootsnap Sam Saffron Julia Evans TruffleRuby benchmark-ips @jhawthorn johnhawthorn.com John’s GitHub   Sponsors Sentry Digital Ocean Get a Coder Job Course Picks: Charles Iron Druid Chronicles by Kevin Hearne Zoom Notion Eric Begay Dave Sony WH-1000XM2 Ryobi Bench Sander David Stephen Fry in America Eric Remote for Slides Zoom John Julia Evans Blog Posts Celeste

Panel: Charles Max Wood David Richards Dave Kimura Eric Berry Special Guests: John Hawthorn In this episode of Ruby Rogues, the panel talks to John Hawthorn about MJIT. John has been a Ruby programmer for about 9 years and is based in Victoria, B.C. They talk about what MJIT is, the effects you can see from using the MJIT compiler, and why the JIT doesn’t always work with other languages. They also touch on how you can use the JIT in your own code, how he makes his performance better, and more! Show Topics: 1:36 – John is a Ruby programmer, and has been one for the past 9 years, and he is based out of Victoria, B.C. 5:00 – He had always been curious how a JIT would work and found that it was always too difficult to work with. Since discovering MJIT, he has been able to work with these compilers because he understands how to work with C code. 7:36 – Ruby has a bytecode and it looks a lot like an assembly language, which is approachable to a Rubyist. 8:24 – The core of MJIT is an ERB template which take this bytecode, loops over it, and emits C code. 9:01 – Effects that you can seem from the JIT in your own code is that it uses a really tight math loop, making your code faster. 11:25 – Other languages aren’t suited for compilers like JIT because they are so flexible to begin with. And in some cases, it doesn’t make sense to JIT compile. 13:05 – The compiled code now is not reusable by other workers and works better with one compilation per process. 15:20 – The temp folder gets cleared immediately after its run, but this compiled code is probably going to stay in memory forever. 17:30 – The MJIT doesn’t work as well with Rails because the code can’t get warmed up enough. Some things aren’t friendly to a JIT. 20:24 – If someone wants to play with the JIT, as long as you have any Ruby version manager, install any of the previewed releases of 2.6 and then run with --jit. 21:44 – Online, you can look into following people who have written various Ruby libraries to look at performance. You can look at people like Sam Saffron and Julia Evans. 23:57 –TruffleRuby is a new front-end on top of a mature virtual machine whereas MJIT is a brand new virtual machine on top of a Ruby front-end. 27:57 – The MJIT had no effect on his work, it was just really fun and interesting to look into. 28:29 – To make his performance better, he allocates fewer objects, does less loops, and writes better queries. 29:02 – You want to run a profiler that will give you a better idea of where to look for performance issues, but you really need a proper benchmark to say what is wrong with your performance. A great benchmark you can use is benchmark-ips. 31:59 – The “gotcha” of doing this kind of work is verifying that you’ve actually improved it. 33:41 – Before we have the JIT in production, we are going to be using these techniques to find out if the JIT is helping us. Links: Get a Coder Job Course Ruby MJIT Playing with ruby's new JIT: MJIT by John Hawthorn Rails Bootsnap Sam Saffron Julia Evans TruffleRuby benchmark-ips @jhawthorn johnhawthorn.com John’s GitHub   Sponsors Sentry Digital Ocean Get a Coder Job Course Picks: Charles Iron Druid Chronicles by Kevin Hearne Zoom Notion Eric Begay Dave Sony WH-1000XM2 Ryobi Bench Sander David Stephen Fry in America Eric Remote for Slides Zoom John Julia Evans Blog Posts Celeste

Panel: Charles Max Wood David Richards Dave Kimura Eric Berry Special Guests: John Hawthorn In this episode of Ruby Rogues, the panel talks to John Hawthorn about MJIT. John has been a Ruby programmer for about 9 years and is based in Victoria, B.C. They talk about what MJIT is, the effects you can see from using the MJIT compiler, and why the JIT doesn’t always work with other languages. They also touch on how you can use the JIT in your own code, how he makes his performance better, and more! Show Topics: 1:36 – John is a Ruby programmer, and has been one for the past 9 years, and he is based out of Victoria, B.C. 5:00 – He had always been curious how a JIT would work and found that it was always too difficult to work with. Since discovering MJIT, he has been able to work with these compilers because he understands how to work with C code. 7:36 – Ruby has a bytecode and it looks a lot like an assembly language, which is approachable to a Rubyist. 8:24 – The core of MJIT is an ERB template which take this bytecode, loops over it, and emits C code. 9:01 – Effects that you can seem from the JIT in your own code is that it uses a really tight math loop, making your code faster. 11:25 – Other languages aren’t suited for compilers like JIT because they are so flexible to begin with. And in some cases, it doesn’t make sense to JIT compile. 13:05 – The compiled code now is not reusable by other workers and works better with one compilation per process. 15:20 – The temp folder gets cleared immediately after its run, but this compiled code is probably going to stay in memory forever. 17:30 – The MJIT doesn’t work as well with Rails because the code can’t get warmed up enough. Some things aren’t friendly to a JIT. 20:24 – If someone wants to play with the JIT, as long as you have any Ruby version manager, install any of the previewed releases of 2.6 and then run with --jit. 21:44 – Online, you can look into following people who have written various Ruby libraries to look at performance. You can look at people like Sam Saffron and Julia Evans. 23:57 –TruffleRuby is a new front-end on top of a mature virtual machine whereas MJIT is a brand new virtual machine on top of a Ruby front-end. 27:57 – The MJIT had no effect on his work, it was just really fun and interesting to look into. 28:29 – To make his performance better, he allocates fewer objects, does less loops, and writes better queries. 29:02 – You want to run a profiler that will give you a better idea of where to look for performance issues, but you really need a proper benchmark to say what is wrong with your performance. A great benchmark you can use is benchmark-ips. 31:59 – The “gotcha” of doing this kind of work is verifying that you’ve actually improved it. 33:41 – Before we have the JIT in production, we are going to be using these techniques to find out if the JIT is helping us. Links: Get a Coder Job Course Ruby MJIT Playing with ruby's new JIT: MJIT by John Hawthorn Rails Bootsnap Sam Saffron Julia Evans TruffleRuby benchmark-ips @jhawthorn johnhawthorn.com John’s GitHub   Sponsors Sentry Digital Ocean Get a Coder Job Course Picks: Charles Iron Druid Chronicles by Kevin Hearne Zoom Notion Eric Begay Dave Sony WH-1000XM2 Ryobi Bench Sander David Stephen Fry in America Eric Remote for Slides Zoom John Julia Evans Blog Posts Celeste

いけさんをゲストにお迎えして、両生類のDNA、独立系SIer、Railsチュートリアル、Web系転職、Java女子部、などについて話しました。 【Show Notes】 『深圳IoT界のフロントランナーに学ぶ 「メイカースペースの可能性と、世界最高の分業体制の秘訣」』ログ - #がみぶろ #しがないラジオmeetup 1 - connpass SOAP (プロトコル) - Wikipedia DevOps - Wikipedia カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで | Amazon Ruby on Rails チュートリアル：実例を使って Rails を学ぼう sp.13b【ゲスト: pupupopo88】楽しいよちよちRubyistがコミュニティに貢献する理由 | しがないラジオ sp.27b【ゲスト: atsuco_02】楽しいフリーランスWeb屋の死なない生存戦略 | しがないラジオ Java女子部(@java_women)さん | Twitter Java女子部(Javajo) | Doorkeeper 配信情報はtwitter ID @shiganaiRadio で確認することができます。 フィードバックは(#しがないラジオ)でつぶやいてください！ 感想、話して欲しい話題、改善して欲しいことなどつぶやいてもらえると、今後のポッドキャストをより良いものにしていけるので、ぜひたくさんのフィードバックをお待ちしています。 【パーソナリティ】 gami@jumpei_ikegami zuckey@zuckey_17 【ゲスト】 いけ@otty_375 【機材】 Blue Micro Yeti USB 2.0マイク 15374

Panel: Charles Max Wood Dave Kimura Brian Hogan Eric Berry Special Guest: Daniel Azuma In this episode, the Ruby Rogues speaks with Daniel Azuma, Daniel is has being a “Rubyist", and has been developing for over 20 years, and currently works at Google apart of the Cloud team with programming language support specialist. Daniel leads the Ruby and Elixir team at Google. Daniel is on the show to discuss Ruby debuggers with the Ruby Rogues panel. Topics cover ruby support, cloud debugger, projects, processes for debuggers and much more. This is a great episode to understand more about Ruby debuggers and processes. In particular, we dive pretty deep on: Ruby Support Cloud Debugger First debugger project Talks about debugging Why do you use a debugger in the first place? Figuring out info and where to started  - processes to start Rapid round trips Pry Second debugger, Snapshots of program state Byte Code Is this only available on the Google cloud platform Similar products? Stack driver gems Google cloud debugger gem Standard rails application? Does the debugger take snapshots of the issue? Debugger agents If you could do it about what would you tell yourself? What are the lessons of writing a Ruby Debugger? If someone wants to put a Ruby app on App engine how do they do that? and much much more. Links:  http://daniel-azuma.com/ http://daniel-azuma.com/articles/talks/rubyconf-2017 debugger product App Engine RailsConf 2012 talk RailsConf 2013 talk rgeo Picks: Brian Docker Monodraw Typora Eric The Punisher Dave Kitematic Thomas and Friends Mini app Chuck Business on Purpose  Kent C. Dobbs   Daniel Docker Music Animation Machine  https://www.youtube.com/watch?v=EAWSonBN3Pk

Panel: Charles Max Wood Dave Kimura Brian Hogan Eric Berry Special Guest: Daniel Azuma In this episode, the Ruby Rogues speaks with Daniel Azuma, Daniel is has being a “Rubyist", and has been developing for over 20 years, and currently works at Google apart of the Cloud team with programming language support specialist. Daniel leads the Ruby and Elixir team at Google. Daniel is on the show to discuss Ruby debuggers with the Ruby Rogues panel. Topics cover ruby support, cloud debugger, projects, processes for debuggers and much more. This is a great episode to understand more about Ruby debuggers and processes. In particular, we dive pretty deep on: Ruby Support Cloud Debugger First debugger project Talks about debugging Why do you use a debugger in the first place? Figuring out info and where to started  - processes to start Rapid round trips Pry Second debugger, Snapshots of program state Byte Code Is this only available on the Google cloud platform Similar products? Stack driver gems Google cloud debugger gem Standard rails application? Does the debugger take snapshots of the issue? Debugger agents If you could do it about what would you tell yourself? What are the lessons of writing a Ruby Debugger? If someone wants to put a Ruby app on App engine how do they do that? and much much more. Links:  http://daniel-azuma.com/ http://daniel-azuma.com/articles/talks/rubyconf-2017 debugger product App Engine RailsConf 2012 talk RailsConf 2013 talk rgeo Picks: Brian Docker Monodraw Typora Eric The Punisher Dave Kitematic Thomas and Friends Mini app Chuck Business on Purpose  Kent C. Dobbs   Daniel Docker Music Animation Machine  https://www.youtube.com/watch?v=EAWSonBN3Pk

Panel: Charles Max Wood Dave Kimura Brian Hogan Eric Berry Special Guest: Daniel Azuma In this episode, the Ruby Rogues speaks with Daniel Azuma, Daniel is has being a “Rubyist", and has been developing for over 20 years, and currently works at Google apart of the Cloud team with programming language support specialist. Daniel leads the Ruby and Elixir team at Google. Daniel is on the show to discuss Ruby debuggers with the Ruby Rogues panel. Topics cover ruby support, cloud debugger, projects, processes for debuggers and much more. This is a great episode to understand more about Ruby debuggers and processes. In particular, we dive pretty deep on: Ruby Support Cloud Debugger First debugger project Talks about debugging Why do you use a debugger in the first place? Figuring out info and where to started  - processes to start Rapid round trips Pry Second debugger, Snapshots of program state Byte Code Is this only available on the Google cloud platform Similar products? Stack driver gems Google cloud debugger gem Standard rails application? Does the debugger take snapshots of the issue? Debugger agents If you could do it about what would you tell yourself? What are the lessons of writing a Ruby Debugger? If someone wants to put a Ruby app on App engine how do they do that? and much much more. Links:  http://daniel-azuma.com/ http://daniel-azuma.com/articles/talks/rubyconf-2017 debugger product App Engine RailsConf 2012 talk RailsConf 2013 talk rgeo Picks: Brian Docker Monodraw Typora Eric The Punisher Dave Kitematic Thomas and Friends Mini app Chuck Business on Purpose  Kent C. Dobbs   Daniel Docker Music Animation Machine  https://www.youtube.com/watch?v=EAWSonBN3Pk

"ぷぽさん"ことヴァル研究所の福本さんをゲストにお迎えして、アジャイルとは？、よちよち.rb、RubyKaigi、コミュニティへの貢献、などについて話しました。 【Show Notes】 株式会社ヴァル研究所 Amazon | アジャイルサムライ−達人開発者への道− Agile Samurai Base Camp | Doorkeeper アジャイルソフトウェア開発宣言 LEGO®を使ったスクラム研修（レゴスクラム） | Doorkeeper "総務も！！"アジャイルプラクティス！ | SlideShare 中村 洋（なかむら よう）｜メンバー｜GuildWorks -ギルドワークス- 及部 敬雄 プロフィール - Wantedly 中村＆及部のアジャイル相席居酒屋 (β) | Facebook Scrum Guide Downloads | Scrum Guides よちよち(の心をずっとわすれない).rb | Doorkeeper Ginza.rb | Doorkeeper Asakusa.rb | Doorkeeper I AM "Ruby Ecosystem"! // Speaker Deck RESTful#とは勉強会 - Ruby Children | Doorkeeper RubyKaigi2017がたのしすぎてたまらなかった話 - すむとこ探し 株式会社ヴァル研究所：採用情報インデックス 配信情報はtwitter ID @shiganaiRadio で確認することができます。 フィードバックは(#しがないラジオ)でつぶやいてください！ 感想、話して欲しい話題、改善して欲しいことなどつぶやいてもらえると、今後のポッドキャストをより良いものにしていけるので、ぜひたくさんのフィードバックをお待ちしています。 【パーソナリティ】 gami@jumpei_ikegami zuckey@zuckey_17 【ゲスト】 ぷぽ@pupupopo88 【機材】 Blue Micro Yeti USB 2.0マイク 15374

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  

RR 321: Visual Studio Code Ruby Plugin with Penn Lv This episode of Ruby Rogues features panelists Dave Kimura, Brian Hogan, and Charles Max Wood. Two special guests join the panel today: Eric Barry and Penn Lv. Tune in and learn more about Visual Studio Code’s Ruby Plug-in! [00:01:55] Introduction to Eric Barry Eric turned over Teach Me To Code to Charles, which helped build relationships for Charles that built the Ruby Rogues podcast. Eric is a software engineer who has been working in programming since 1998. He works for Skipio and has been a Ruby on Rails developer for nine years. [00:03:15] Introduction to Penn Lv Penn is a software engineer for Redim. He works on the Ruby extension for Visual Studio Code. This extension deals with enhanced Ruby language support. [4:00] What goes into building a language plug-in/language setup for VS code, what do you have to do in order to make that work in the electron set-up? Usually when you try to build an extension for VS code it is just a NodeJS application. It has nothing to do with electrons; it is just a Node application. Everything is run in a separate process. Just about how to build an extension for VS code. The first category is formatters, or colorization. For both of those you can write plain JavaScript. There are two categories that are difficult: first is de-buggers. The VS code is a set of common UI for de-bugging. Which is language diagnostic. Write an extension and hook up language debug. The second is a language server to write language experience. VS code has a concept called language server protocol. Need to write an extension that follows protocol and tells the VS code about semantic information about your program. [00:06:25] – In order to get some of the nice features for the language you have a Ruby process running somewhere that you talk to in order to do some of the syntax checking? Yes, have to run that in a stand-alone process. It analyzes Ruby, but it can’t run that in Node JS process. [00:06:52] So what’s the goal? What makes the VS code team write a Ruby program? Ruby for VS Code was his ticket to the VS code team. Penn wrote for himself. It is his hobby project. [00:07:32] How many contributors are on the project? Who works with you? It is a community project. There are probably in between 50 to 100 contributors. [00:08:33] What’s your process of knowing what to allow and what not to allow to modify it? How do you know what PRS to accept and how do you stay on top of it? It is challenging to know what to allow. Penn claims to still not be a professional Rubyist. The first step is to run test cases. His way of reviewing code is by downloading the code. He looks into every piece of the code, learns it, and plays around it. If it works, he adds it. [00:10:23] How main PRs do you regularly get and how much time does it take to keep that maintained? Every weekend he goes through everything. He will have maybe five to six VS code extensions and check them thoroughly. [00:13:30] Indentation when blogging in VS code Two months ago he finished a feature dealing with auto indentation. The option for this is called editor.autoindent. Indentation gets adjusted automatically while you type. [00:18:10] Recommendations for plug-ins Charles recommends Emacs key bindings and Penn recommends the VS code extension Vim. [00:21:49] Do you do most of your work in TypeScript? Yes. At the very beginning they were using JavaScript. They were one of the first adopters of TypeScript and are now all TypeScript. [00:22:50] How much of a commitment would it be to add TypeScript to an existing project? The setup of TypeScript is not easy. If you are using a NodeJS application and they have TypeScript or typing support there is no specific thing that needs to be done to make it happen. In VS code there is a feature called automatic type acquisition. If creating a new project that uses an express package, which already has a typing file for it. VS code provides you with auto complete. Also don’t need to worry about typescript file if you are not going to create a library. Can do TypeScript gradually. [00:26:16] What do you see that’s left to do in the Ruby plug-in? A language server is the missing part. [00:27:35] Is that currently being done in other editors? No one does that right now. RubyMine has the best support currently. [00:28:13] Does your work translate to Atom as well? Atom has basic support for Ruby but it is just about colorization, indentation, and formatters. Everyone is waiting for a language server for Ruby. [00:31:38] If you have multiple languages or modes that you have to handle within the same file how do you set up VS code to handle that? Users cannot customize that. A language support extension has to handle that. [00:34:50] What is the font that you use in VS code? Source code pro [00:35:08] If people want to give this a try, what are the best ways to do that? First go to code.visualstudio.com. Then, install VS code. At the welcome page instructions will show you how to use the command palate, give you an interactive playground, and show the best place to get familiar with everything. The welcome page also has links: one is VS tips and tricks, which are shared by the community. There is a Youtube channel, which shows how to make VS Code productive. [00:36:32] If someone is working on an esoteric language and there is no support in there language in VS code yet. Where would you recommend they start? There is a docs session on the website that tells you how to write extensions for VS Code. Penn thinks if you build a debugger it is most difficult. There needs to be an understanding of real debuggers. Look at some of existing debugger, understand how they read source code, get an understanding from there. [00:38:22] Was there an extension that you used as a model while writing the Ruby extension for VS code that you recommend people look at? First looked at Python. Then switched to PHP, which is pretty similar to the Ruby extension. The protocol is very similar. That’s how he learned to make the Ruby extension. [00:40:58] If people want to contribute, is there a GitHub they can go look at? The organization name is Ruby IDE and GitHub name is vscode-ruby. There is a Wiki Page on how to setup and explain concepts behind everything. [00:41:22] How long did it take you to get the plug-in till it was publicly useable? A couple of hours. He was at his girlfriend’s parent’s house bored, got a job with VS code because of it. [00:44:40] What’s your biggest sales pitch for VS code? Compared to some of competitors, VS code is fast. The best part of VS code is that it is open source. Everything is on GitHub, including issues and user feedback. Users know every issue that is being worked out. All information is open to users. Can file an issue and they will respond immediately. [00:47:00] Are there plug-ins for other languages? There is an elm plug-in. Picks Dave: Azure’s cognitive services Brian: OmniFocus Eric: Hugo Netlify Code Sponsor Charles: Building stairs Upwork Penn: The Text Editor Sam by Rob Pike Ruby Weekly

RR 321: Visual Studio Code Ruby Plugin with Penn Lv This episode of Ruby Rogues features panelists Dave Kimura, Brian Hogan, and Charles Max Wood. Two special guests join the panel today: Eric Barry and Penn Lv. Tune in and learn more about Visual Studio Code’s Ruby Plug-in! [00:01:55] Introduction to Eric Barry Eric turned over Teach Me To Code to Charles, which helped build relationships for Charles that built the Ruby Rogues podcast. Eric is a software engineer who has been working in programming since 1998. He works for Skipio and has been a Ruby on Rails developer for nine years. [00:03:15] Introduction to Penn Lv Penn is a software engineer for Redim. He works on the Ruby extension for Visual Studio Code. This extension deals with enhanced Ruby language support. [4:00] What goes into building a language plug-in/language setup for VS code, what do you have to do in order to make that work in the electron set-up? Usually when you try to build an extension for VS code it is just a NodeJS application. It has nothing to do with electrons; it is just a Node application. Everything is run in a separate process. Just about how to build an extension for VS code. The first category is formatters, or colorization. For both of those you can write plain JavaScript. There are two categories that are difficult: first is de-buggers. The VS code is a set of common UI for de-bugging. Which is language diagnostic. Write an extension and hook up language debug. The second is a language server to write language experience. VS code has a concept called language server protocol. Need to write an extension that follows protocol and tells the VS code about semantic information about your program. [00:06:25] – In order to get some of the nice features for the language you have a Ruby process running somewhere that you talk to in order to do some of the syntax checking? Yes, have to run that in a stand-alone process. It analyzes Ruby, but it can’t run that in Node JS process. [00:06:52] So what’s the goal? What makes the VS code team write a Ruby program? Ruby for VS Code was his ticket to the VS code team. Penn wrote for himself. It is his hobby project. [00:07:32] How many contributors are on the project? Who works with you? It is a community project. There are probably in between 50 to 100 contributors. [00:08:33] What’s your process of knowing what to allow and what not to allow to modify it? How do you know what PRS to accept and how do you stay on top of it? It is challenging to know what to allow. Penn claims to still not be a professional Rubyist. The first step is to run test cases. His way of reviewing code is by downloading the code. He looks into every piece of the code, learns it, and plays around it. If it works, he adds it. [00:10:23] How main PRs do you regularly get and how much time does it take to keep that maintained? Every weekend he goes through everything. He will have maybe five to six VS code extensions and check them thoroughly. [00:13:30] Indentation when blogging in VS code Two months ago he finished a feature dealing with auto indentation. The option for this is called editor.autoindent. Indentation gets adjusted automatically while you type. [00:18:10] Recommendations for plug-ins Charles recommends Emacs key bindings and Penn recommends the VS code extension Vim. [00:21:49] Do you do most of your work in TypeScript? Yes. At the very beginning they were using JavaScript. They were one of the first adopters of TypeScript and are now all TypeScript. [00:22:50] How much of a commitment would it be to add TypeScript to an existing project? The setup of TypeScript is not easy. If you are using a NodeJS application and they have TypeScript or typing support there is no specific thing that needs to be done to make it happen. In VS code there is a feature called automatic type acquisition. If creating a new project that uses an express package, which already has a typing file for it. VS code provides you with auto complete. Also don’t need to worry about typescript file if you are not going to create a library. Can do TypeScript gradually. [00:26:16] What do you see that’s left to do in the Ruby plug-in? A language server is the missing part. [00:27:35] Is that currently being done in other editors? No one does that right now. RubyMine has the best support currently. [00:28:13] Does your work translate to Atom as well? Atom has basic support for Ruby but it is just about colorization, indentation, and formatters. Everyone is waiting for a language server for Ruby. [00:31:38] If you have multiple languages or modes that you have to handle within the same file how do you set up VS code to handle that? Users cannot customize that. A language support extension has to handle that. [00:34:50] What is the font that you use in VS code? Source code pro [00:35:08] If people want to give this a try, what are the best ways to do that? First go to code.visualstudio.com. Then, install VS code. At the welcome page instructions will show you how to use the command palate, give you an interactive playground, and show the best place to get familiar with everything. The welcome page also has links: one is VS tips and tricks, which are shared by the community. There is a Youtube channel, which shows how to make VS Code productive. [00:36:32] If someone is working on an esoteric language and there is no support in there language in VS code yet. Where would you recommend they start? There is a docs session on the website that tells you how to write extensions for VS Code. Penn thinks if you build a debugger it is most difficult. There needs to be an understanding of real debuggers. Look at some of existing debugger, understand how they read source code, get an understanding from there. [00:38:22] Was there an extension that you used as a model while writing the Ruby extension for VS code that you recommend people look at? First looked at Python. Then switched to PHP, which is pretty similar to the Ruby extension. The protocol is very similar. That’s how he learned to make the Ruby extension. [00:40:58] If people want to contribute, is there a GitHub they can go look at? The organization name is Ruby IDE and GitHub name is vscode-ruby. There is a Wiki Page on how to setup and explain concepts behind everything. [00:41:22] How long did it take you to get the plug-in till it was publicly useable? A couple of hours. He was at his girlfriend’s parent’s house bored, got a job with VS code because of it. [00:44:40] What’s your biggest sales pitch for VS code? Compared to some of competitors, VS code is fast. The best part of VS code is that it is open source. Everything is on GitHub, including issues and user feedback. Users know every issue that is being worked out. All information is open to users. Can file an issue and they will respond immediately. [00:47:00] Are there plug-ins for other languages? There is an elm plug-in. Picks Dave: Azure’s cognitive services Brian: OmniFocus Eric: Hugo Netlify Code Sponsor Charles: Building stairs Upwork Penn: The Text Editor Sam by Rob Pike Ruby Weekly

RR 321: Visual Studio Code Ruby Plugin with Penn Lv This episode of Ruby Rogues features panelists Dave Kimura, Brian Hogan, and Charles Max Wood. Two special guests join the panel today: Eric Barry and Penn Lv. Tune in and learn more about Visual Studio Code’s Ruby Plug-in! [00:01:55] Introduction to Eric Barry Eric turned over Teach Me To Code to Charles, which helped build relationships for Charles that built the Ruby Rogues podcast. Eric is a software engineer who has been working in programming since 1998. He works for Skipio and has been a Ruby on Rails developer for nine years. [00:03:15] Introduction to Penn Lv Penn is a software engineer for Redim. He works on the Ruby extension for Visual Studio Code. This extension deals with enhanced Ruby language support. [4:00] What goes into building a language plug-in/language setup for VS code, what do you have to do in order to make that work in the electron set-up? Usually when you try to build an extension for VS code it is just a NodeJS application. It has nothing to do with electrons; it is just a Node application. Everything is run in a separate process. Just about how to build an extension for VS code. The first category is formatters, or colorization. For both of those you can write plain JavaScript. There are two categories that are difficult: first is de-buggers. The VS code is a set of common UI for de-bugging. Which is language diagnostic. Write an extension and hook up language debug. The second is a language server to write language experience. VS code has a concept called language server protocol. Need to write an extension that follows protocol and tells the VS code about semantic information about your program. [00:06:25] – In order to get some of the nice features for the language you have a Ruby process running somewhere that you talk to in order to do some of the syntax checking? Yes, have to run that in a stand-alone process. It analyzes Ruby, but it can’t run that in Node JS process. [00:06:52] So what’s the goal? What makes the VS code team write a Ruby program? Ruby for VS Code was his ticket to the VS code team. Penn wrote for himself. It is his hobby project. [00:07:32] How many contributors are on the project? Who works with you? It is a community project. There are probably in between 50 to 100 contributors. [00:08:33] What’s your process of knowing what to allow and what not to allow to modify it? How do you know what PRS to accept and how do you stay on top of it? It is challenging to know what to allow. Penn claims to still not be a professional Rubyist. The first step is to run test cases. His way of reviewing code is by downloading the code. He looks into every piece of the code, learns it, and plays around it. If it works, he adds it. [00:10:23] How main PRs do you regularly get and how much time does it take to keep that maintained? Every weekend he goes through everything. He will have maybe five to six VS code extensions and check them thoroughly. [00:13:30] Indentation when blogging in VS code Two months ago he finished a feature dealing with auto indentation. The option for this is called editor.autoindent. Indentation gets adjusted automatically while you type. [00:18:10] Recommendations for plug-ins Charles recommends Emacs key bindings and Penn recommends the VS code extension Vim. [00:21:49] Do you do most of your work in TypeScript? Yes. At the very beginning they were using JavaScript. They were one of the first adopters of TypeScript and are now all TypeScript. [00:22:50] How much of a commitment would it be to add TypeScript to an existing project? The setup of TypeScript is not easy. If you are using a NodeJS application and they have TypeScript or typing support there is no specific thing that needs to be done to make it happen. In VS code there is a feature called automatic type acquisition. If creating a new project that uses an express package, which already has a typing file for it. VS code provides you with auto complete. Also don’t need to worry about typescript file if you are not going to create a library. Can do TypeScript gradually. [00:26:16] What do you see that’s left to do in the Ruby plug-in? A language server is the missing part. [00:27:35] Is that currently being done in other editors? No one does that right now. RubyMine has the best support currently. [00:28:13] Does your work translate to Atom as well? Atom has basic support for Ruby but it is just about colorization, indentation, and formatters. Everyone is waiting for a language server for Ruby. [00:31:38] If you have multiple languages or modes that you have to handle within the same file how do you set up VS code to handle that? Users cannot customize that. A language support extension has to handle that. [00:34:50] What is the font that you use in VS code? Source code pro [00:35:08] If people want to give this a try, what are the best ways to do that? First go to code.visualstudio.com. Then, install VS code. At the welcome page instructions will show you how to use the command palate, give you an interactive playground, and show the best place to get familiar with everything. The welcome page also has links: one is VS tips and tricks, which are shared by the community. There is a Youtube channel, which shows how to make VS Code productive. [00:36:32] If someone is working on an esoteric language and there is no support in there language in VS code yet. Where would you recommend they start? There is a docs session on the website that tells you how to write extensions for VS Code. Penn thinks if you build a debugger it is most difficult. There needs to be an understanding of real debuggers. Look at some of existing debugger, understand how they read source code, get an understanding from there. [00:38:22] Was there an extension that you used as a model while writing the Ruby extension for VS code that you recommend people look at? First looked at Python. Then switched to PHP, which is pretty similar to the Ruby extension. The protocol is very similar. That’s how he learned to make the Ruby extension. [00:40:58] If people want to contribute, is there a GitHub they can go look at? The organization name is Ruby IDE and GitHub name is vscode-ruby. There is a Wiki Page on how to setup and explain concepts behind everything. [00:41:22] How long did it take you to get the plug-in till it was publicly useable? A couple of hours. He was at his girlfriend’s parent’s house bored, got a job with VS code because of it. [00:44:40] What’s your biggest sales pitch for VS code? Compared to some of competitors, VS code is fast. The best part of VS code is that it is open source. Everything is on GitHub, including issues and user feedback. Users know every issue that is being worked out. All information is open to users. Can file an issue and they will respond immediately. [00:47:00] Are there plug-ins for other languages? There is an elm plug-in. Picks Dave: Azure’s cognitive services Brian: OmniFocus Eric: Hugo Netlify Code Sponsor Charles: Building stairs Upwork Penn: The Text Editor Sam by Rob Pike Ruby Weekly

Добрый день уважаемые слушатели. Представляем новый выпуск подкаста RWpod. В этом выпуске: Ruby Sinatra 2.0.0, Active Admin 1.0, The Lesser-known Features in Rails 5.1 и Building a Rack::Attack Dashboard Improving capistrano deployment performance, Crafting Better Code Reviews и Announcing the RubyLetter Podcast Crystal from a Rubyist's Perspective, Capistrano AWS, Pwrake: Parallel Workflow extension for Rake, runs on multicores, clusters, clouds и RailsConf 2017: Why Software Engineers Disagree About Everything (video) JavaScript Node.js 8.0.0 has been delayed and will ship on or around May 30th, Prepack - a partial evaluator for JavaScript, Autoprefixer 7.0 and Browserslist 2.0 и PostCSS 6.0 ECMAScript modules in browsers, JavaScript: The compilation epoch, UX drives all of this и 45% Faster React Functional Components, Now Getting Started with Headless Chrome, SmartPhoto.js - the most easy to use responsive image viewer especially for mobile devices, Pkg - package your Node.js project into an executable, Typefont - recognises the font of a text in a image и SpectorJS - explore and troubleshoot your WebGL scenes

This week Joel returns to join Kyle with talk of RailsConf 2017, Lin-Manuel Miranda, and what it's like to be a lower-case Rubyist.

This week Joel returns to join Kyle with talk of RailsConf 2017, Lin-Manuel Miranda, and what it's like to be a lower-case Rubyist.

Carol Goulding: @Carols10cents | GitHub | Blog | Integer 32 Show Notes: 00:58 - Going Into Business Using Rust 03:42 - Getting Paid to do Open Source 05:31 - Prototyping Projects in Rust 06:21 - Why Rust? (Benefits) 09:58 - The Language Server 14:52 - Error Messages 19:46 - The Rust Programming Language Book 23:35 - Crates.io 27:41 - The Backend 31:11 - Working with Rust and Ember Together 33:31 - Rust Belt Rust Conference 35:59 - Integer 32 Resources: The Rust Programming Language Book The Frontside Podcast Episode 51: Rust and APIs with Steve Klabnik Rust For Rubyists Working Effectively with Legacy Code by Michael Feathers Clippy Cargo rustlings Python Koans Rust - exercism.io No Starch Tokio Diesel Rocket Nickel Iron Pencil Rust Belt Rust Conference RustFest.EU RustConf Transcript: STEPHANIE: Hello, everybody. Welcome to The Frontside Podcast. This is Stephanie Riera. I am a developer here at The Frontside and with us, we have some very special guests. We have Chris Freeman who is a former Frontsider. He is a developer at a startup here in town in Austin called OJO. I'm going to let Chris introduce Carol Nichols. CHRIS: Hi, everyone. Today we've get Carol Nichols. She is involved in a lot of different things related to the Rust programming language. She is on the Rust community team. She is the co-author of the Rust book. She's the co-founder of a Rust consulting company called Integer 32 and she's the maintainer of Crates.io. How are you doing today, Carol? CAROL: I'm great. Thank you for having me on the show. CHRIS: Thanks for joining us. I have a lot of questions for you. I'm very interested in Rust but I am especially interested in some of the stuff you're doing that's kind of ancillary to it, namely you decided to go into business using a pretty new programming language that in some ways, I think is a little bit niche-related to some other things that people might go into business for say, web development. I was hoping maybe you could talk about what is Integer 32? What led you to starting this business? What kind of consulting work do you find working in something like Rust? CAROL: Integer 32 is my husband and I, Jake Goulding and we decided to form this company because we really wanted to get paid to work on Rust. We think Rust is really interesting and that is moving the industry forward and we see a future in Rust. As far as we can tell, we are the first Rust-focus consultancy in the world, which either makes us trendsetters or really stupid. I'm not sure about that yet but we're figuring it out. We consider ourselves pretty qualified to be running a Rust consultancy. As you mentioned, I'm the co-author on the book. I've been working with Rust for a couple of years now. Jake has the most points on Stack Overflow in the Rust tag. We've got a lot of experience in getting to know Rust. We've been watching the development, helping people learn Rust so we are offering a bunch of different services. One is to build an MVP or a prototype for Rust so that companies can evaluate whether Rust would be a good fit for their problem, without diverting their whole team to be able to learn Rust enough to evaluate it properly. We've done some prototypes. We're also interested in doing training and pairing so we have some training, things in the works. We've also gotten some jobs that are adding to open source libraries in Rust. The ecosystem is still being built up and there's a lot of libraries that do whatever the person who wrote them need them to do but they're not feature complete so if someone else just needs that extra feature on some library, they can pay us to add it if they'd like. One of the things I really want to do with my consultancy is have our proprietary work subsidize our open source work because I really wanted to get paid for open source stuff. We have a different rate that we charge for a proprietary versus open source. We've had a few gigs that are adding stuff to open source libraries and I love those because we're not only benefiting the company who needs something but we're benefiting the entire community. CHRIS: When you say you work on an open source thing, do you mean like a company that happens to be a consumer of an open source library would pay you to add a feature? Or is it the maintainers of the libraries themselves are coming to you and hiring help? CAROL: So far, it has been the former but we have talked to some people about the latter but open source projects typically don't have much funding. I think that's a little rarer but definitely, were open to companies paying us to add what they need to a library. CHRIS: Has there been any friction there like you kind of showing up and say a company is paying us to try and add features to your project? Do the maintainers ever pushback or are they very happy to just have someone helping? CAROL: Yes, so far no. All the maintainers we worked with have been amazing. We're not going to come in and rewrite the whole project. We're going to come in and work with their style and make any modifications they want to be able to incorporate into their library. But as I said, a lot of libraries are gotten to a certain point and I think the maintainers would like their libraries to become more feature complete but everyone only has so much time and you don't necessarily know what's useful to people but this is a very, very strong signal that this library would be useful to someone if only it had this little extra thing. I think most maintainers are open to making their libraries more feature complete to be more useful to more people. CHRIS: Yeah, that is a pretty sweet deal from the standpoint of an open source maintainer. It's nice enough when people show up to help at all. It is especially nice to show up to help and aren't motivated by money. CAROL: Yeah. CHRIS: That's very cool. When it comes to prototyping things with Integer 32, what kind of projects are people coming to you and asking you to prototype in Rust? CAROL: A lot of them are existing projects that they have and written in something else that they want to either perform better and be safer as opposed to rewriting it in C or C++ to get performance out of it. Sometimes, they want something to interface with other Rust things. We're starting to see projects like that but mostly, they have a hunch that Rust will be good for their projects and solve some problem they're having with their current implementation. We scope their projects way down to whatever will let them evaluate, whether Rust is a good fit or not and we go with that. CHRIS: Cool. STEPHANIE: Going from there, the question that I have is why Rust? I don't know a lot about Rust so I'd like to know what would be some of the benefits of using Rust, if you're familiar with programming. If you are in web development like I'm familiar with Ember, why would I like to use Rust or learn Rust? CAROL: I could talk all day about this. I really love working with Rust. I feel like it is adding more tools to help me to write better code and taking care of little details that usually I would have to spend a lot of brainpower thinking about to get right all the time. But now I can actually concentrate on whatever it is I'm trying to get done and let the compiler take care of those details for me. The way it's implemented, it happens really fast. The way I got into Rust was I'm a Rails developer previously to this job and I spend a lot of time optimizing Rails, looking for places where essentially too many Ruby objects and memory leaks and [inaudible] a lot of trying to make Rails go faster. At some point, you can't. There's only so far you can take Ruby and Rails so I look at where I want my career to go next and I love making things go faster but I'm terrified of C. I should be nowhere near production C. You have to spend years learning all the quirks and all the ways that C can go wrong and crash and be insecure. Around this time, I know you had Steve Klabnik on the show, in the previous episode. Steve is from Pittsburgh, where I am and he came home for Christmas one year and came to a Ruby meet up and was talking about this new language called Rust and how awesome it was. Steve gets distracted by new awesome things all the time so I was like, "Yeah, yeah, okay, whatever." The next year, he came home for Christmas again and was still talking about how awesome Rust was. At that point, I was like, "There's got to be something to this." At that point, he was writing his book, 'Rust for Rubyist' which has lead into his work on the Rust programming language book. I was like, "Rust for Rubyist? I can handle this. This is something I can do and capable of," so I started reading his book and submitting corrections and things which is again, how I got involved with the Rust programming language book. If you've ever gotten the error 'undefined method on nil' or 'undefined is not a function' in JavaScripts, like in production at runtime that happens all the time. That's just normal in Ruby and JavaScript land. Rust prevents those problems at compile time so there's no null, there's no nil. It's strongly typed so it checks that you have the thing you think you have before your code even can run. There's no garbage collector so you don't have memory leaks. The system of ownership and borrowing and the borrow checker and lifetimes which is weird. It's tricky to get your head around at first because it's different than any other language. But once you get that that's the part that enables your code to go faster without needing the garbage collector. You actually don't have to think about your memory management as much as you would in C, where you have to say, "Please give me some memory." Okay, I'm done with it now. You are manually managing your memory but you don't have to think about it as much because the compiler is thinking about it for you, if that makes sense. CHRIS: I have a follow up question, kind of related to the fact that Rust is kind of performing at the level of C or C++ but a lot more friendly in the fact that both you and Steve and I think a lot of other people, have come to Rust from scripting languages, from higher level languages. I remember at first that I started paying attention on Rust like right before the 1.0 happened, I thought it sounded interesting and wrote it off because it was just insane and I had only ever done Python and JavaScript and higher level things. In a relatively short time, it has developed a level of ergonomics that I'm envious of, even in the 'more comfortable' languages, things like Cargo, things like the compiler is really great but now the compiler has really friendly and informative error messages so that 'undefined is not a function' never happens but when you try to make it happen, it now shows you like, "No, no, no. On this exact line, in this place, this is where you're doing it wrong." But I recently heard it and I'm curious if you know anything about it that there's also development on a Rust language service, kind of like I guess TypeScript test, where it's a whole set of tools that you can run under the hood that any editor can plug into so that you just get this tool box of things to help you develop in Rust that are all packaged up and handed over and all you have to do is hook into it. Have you try that at all? Are you familiar with that? CAROL: I am not. I've been watching but I haven't worked on it and I haven't tried it out yet. I am excited for the language server because it's going to enable IDEs to do more interesting things. Coming from Ruby where it's so dynamic that you can't do things like ensure that you renamed all of the places and method it's called because you can't know that. I've read books like Michel Feathers' Working Effectively with Legacy Code and a lot of the chapters in that talked about leaning on your IDE, on your refactoring tools to do automated refactoring. RubyMine has a few of those things but not all of them because it's just impossible so I'm really looking forward to having real refactoring tools that can let you do automated refactorings and things like that that are possible in other statically-typed languages but with Rust in an IDE. I haven't used an IDE in years because I haven't found them to be useful but once the language server is up and running, I'm thinking about going back to an IDE so it's definitely exciting. CHRIS: That's some pretty cool right now. There's one called Clippy which I love because of the name like it takes you back to my Microsoft Word days. There's a lot of very good stuff that they have added that I didn't expect from a 'systems language' but it has definitely benefited from a lot of things that people in the scripting world have learned. CAROL: One of the goals of 2017 for the core team is increasing people's productivity in Rust so getting people over the learning curve, providing them with tools like the language server and making it easier for people to build things in Rust without having to manage things around Rust. Just Cargo in itself has made systems programming so much better. I see people who develop in C and C++ who really try to minimize the amount of libraries they bring in because that makes your build system so much more complicated and you have to have libraries in the right place and so much more can go wrong. But with Cargo, it's just Cargo install and you have a Cargo.lock and cargo.toml that manages versions. It just work so it's been interesting watching people figure that out and change their opinions on bringing in dependencies with npm and JavaScript and Bower and Ruby Gems that we're all used to like, "Oh, there's a gem for that. Let's just pull that in and go." Systems people have been really reluctant to do that but Cargo is enabling that to be better and easier which is really exciting to watch. I want anyone listening to this who thinks, "I can't do system programming. It was too hard." No, you totally can. You can do Rust. Rust is going to let you do this and that's why Rust is really exciting because it's enabling a whole new group of people to get into the systems programming space where things need to be optimized and faster and letting people build these sorts of things without having the programs be vulnerable to crashes and security bugs and things like that. It's really, really exciting. CHRIS: Very cool. STEPHANIE: I'm curious in Rust, if there's an error, how would you know that there's an error? Is the whole thing going to stop? Is it going to break? Do you get a useful stack trace? What would I expect to see? CAROL: A lot of the errors in Rust are at compile time. It won't even let you try to run your code if you have certain kinds of problems and they tried to move as much as possible into that compile time space. There are always going to be things that you can't catch a compile time like the user enters a number that's too big for whatever you're trying to do. That's still going to be a runtime error because we can't possibly know what a user is going to put in when you're compiling. They've done a lot of work on the compiler errors as Chris was talking about, to make them friendlier and point here's where your error is, here's why it's happening, here's a hint as to how you might want to fix it. This has been really great. I was volunteering in a local code school with students just starting Ruby and I'm used to Ruby's error messages by now but they were just getting started and getting all sorts of errors and I was like, "Wow, these error messages are not helpful at all," and I forgot how bad that is and how confusing it can be for a beginner to just think you understand, think you have got it working and then you go and run the code and it's just like 'string is not a symbol' or whatever. The worst is when you forget to close the block and just expected to see [inaudible] end of file instead and it's not helpful at all. I was just like apologizing the whole time like, "I'm sorry. This is telling you that you need to write 'end' at the end of the file," but it's not telling you that in any way you could possibly know that. That made me appreciate much more all of the work that's going into Rust error messages that are really trying to help. Some people talk about, especially the borrow checker, fighting the borrow checker like they're not used to having a compiler tell them their code is wrong so often so people talk about fighting the borrow checker a lot but it's not trying to fight with you. It's not trying to make you feel bad about your code. It's trying to help you make your code better and prevent errors that might happen at runtime by catching them earlier. I actually have a little project called Rustlings that is full of little snippets of Rust that intentionally don't compile. You run them and you get an error message right away and your job is to read the error message and learn how to fix it. When I was starting out, I was really frustrated because I was trying to do something and I would get an error message and I would have to stop whatever is doing to deal with the error message. I was like, "If I could just get some practice just dealing with the error messages and learning how to fix them so that when I'm trying to do something else, I already have experience fixing that kind of error," so that's how that project came to be and people found that useful. I haven't had much time to work on it lately but it could definitely use more examples because I think people are used to error messages that are not helping. People used to back traces that are really long and don't say anything useful. Sometimes, you don't stop and read and think but the Rust error messages are really trying to help you and often times, they are telling you exactly what you need to do to change the code to work. I think getting practice seeing the compiler as more of a pair who is trying to help you and not someone who's trying to reject all your code is a different mindset that I don't think people are used to but I think it's really useful. STEPHANIE: That's excellent. I was going to ask you if there are any resources or any repos to check out for someone who is interested in getting into Rust. It's funny, last night I was poking around with Python and there's something similar to Rustlings. It's called Python Koans and it's basically like what you're already familiar if you do web development. You want to get your test to pass so it'll tell you, you need to think about this one or you need to meditate on this and then you try to get it to pass and then it says you have reached enlightenment or you have not yet reached enlightenment and you have to sit there and think about it and then run it again. It's very useful in trying to get started with language in a way that you are already sort of familiar with. CAROL: Yeah, I've definitely gotten inspiration from the Koans project that have existed in other languages. There's also an exercism track for Rust that people found really useful and of course, I'm working with Steve Klabnik on the Rust programming language book. We're rewriting the whole thing so there's an existing version that if you go to the Rust documentation and click on book, you'll get the existing version which is complete but the new version is going to be way better. Especially with the explanations of ownership and borrowing, people have said that the new version is way, way better than the old version. Someone even made the analogy of doing medical research and you see that trial case is doing so much better than the placebo case that is not ethical to continue the trial. It's more ethical to stop the trial and use the new thing because it's helping so many people. Someone was like, "You need to replace the old book with the new book right now because it's so much better," but the new book isn't complete yet. The new book is in a different repo which we can put in the show notes so I'd recommend starting with the new book and then working back and forth with the old book once you run out of content. But we're getting closer all the time so hopefully, that should be done and printed by No Starch sometime in 2017 -- CHRIS: Woah! It's being printed by No Starch? CAROL: Yeah. CHRIS: That's cool. I didn't know that. Congratulations. CAROL: I thought Steve mentioned that in the last one. CHRIS: He may have but he talked about it a long time ago and I thought he always meant the old one. How long have you been rewriting the Rust book for? CAROL: It's been a while. CHRIS: Longer than I knew about then, probably. CAROL: It's kind of like software. It's more work than you think it's going to be and estimating, it's going to be done when it's done. If you kept telling people, "It's going to be out on this time," and like Steve, "There's no way it's not getting done by then," so now he's not allowed to say it when it's going to be out. CHRIS: Nice. CAROL: I'm really grateful to see this opportunity because I don't think I would have written a book on my own and I'm learning a whole lot about the process of writing a book. It turns out there's a lot of editing, a lot of back and forth, a lot of trying to build a narrative through this long stretch of text so that you're building on top of what you've already covered and not introducing things that aren't mentioned. It's a lot of work and I'm learning a lot and I have no idea when it's going to be [inaudible] because I think there's more work that I still don't know about coming, as we get closer to going to print. It's definitely one of those things that you can't make agile because you've got to put it on paper that costs money and it's going to be around a long time at some point. It's definitely a different kind of working that I'm used to with software. CHRIS: Although, I have to say, I clicked around and I think this is the new version: Rustlings.Github.io/Book. Is that the new one? CAROL: Yes, that's the new version. CHRIS: There is a lot here and it's not quite what I would have expected to see here like it's not done yet. I've been clicking links and I have yet to find one that says 'to-do'. CAROL: I think 15 through 20 are like outlines right now. We're maybe three-quarters through with the content but then we have to go through revisions and editing and copyediting. CHRIS: I'm looking at the headings and I was a big fan of the first Rust book but I can already see it calling out things I wish had been hit on more specifically in the original book. There's a lot of good looking stuff here so I'm excited about this. I'm going to go and read this thing. CAROL: I'm excited for people to read it. CHRIS: Earlier, you were talking about one of the things that is really nice about the Rust tooling is that Cargo makes it really easy to bring in dependencies. I happen to know that you are recently, I believe the maintainer of Crates.io which is where all of Cargoes crates, which are the libraries are hosted. Is that correct? CAROL: That is correct. I have commitment Crates.io now which is very exciting. Crates.io is like Ruby Gems or npm. It's the site where people publish their libraries and you can go and search for a library for what you need. As part of the Rust 2017 goals, we want to make it easier for people to find high-quality libraries that do the things they needed to do. I've been doing some work on adding badges and categories. Rust makes major decisions on the language and on things through an RFC process, which I think Ember is doing now too. I forget which way we stole that. Do we steal it from Ember or did you steal from us? I can't remember. CHRIS: If I remember right, I think -- I could be wrong, Twitter -- Ember did it first. Rust borrowed it and then added the 'how do we teach this?' section. I think Ember took that back and added it to their RFCs. CAROL: Okay, I'm super excited about that section. Now, when you propose a change of language, you have to go through this RFC process where you write up what you want to change, why you want to change it, any downsides, any alternative designs. Then the community talks about it and makes comments when you revise it and things like that. Now, there's a new section that just got added. That's 'how do we teach this?' Before something can be stabilized in the language, you have to document it. This is still kind of starting to take effect but I'm super excited about it because people can't use something unless they know how to use it. Right now, Steve's the only person getting paid full time to work on the documentation and I need him to write the book so I'm excited that more people will be thinking about documentation and thinking about how to help people use their new features. Anyway, I have an RFC about how to rank Crates within a category that we're trying to work through. In some automated ways, we can recommend different Crates for different purposes. I'm working through that with the community to try and figure out how to best recommend Crates in different circumstances. Crates.io is written in Rust and it performs really well. It just got added to the Heroku things so you can deploy it too. Looking at the analytics and their response times for is just like the Ruby apps I work on would be thrilled to have these stats. The backend of it is Rust, the frontend is Ember and [inaudible] who was an Ember person is also interested in Rust and he thinks Rust on the backend and Ember on the frontend worked really well together. He's always trying to figure out ways that we can work together. Crates.io is an existing project that I'm still learning Ember. There's lots of words I don't really understand about like components and Bowers. I would love Ember help on Crates.io. I'm starting to pull out issues that would be good at first time issues or more Ember-focus or I have some idea of how to fix that I could help someone fix. I'm starting to tag those things with 'has mentor' in our labels so I love for people to come check out issues on Crates.io who know JavaScript and know Ember and might want to get into Rust because there are definitely some issues that need a little bit of frontend, a little bit of backend so it might be a good way for people to get into Rust. CHRIS: Very cool. I'm personally very interested in that and will likely hit you up. But I'm sure many of our listeners will as well because I think we have a lot of Ember-friendly listeners so look Carol up because it sounds like she could use some help. Actually, I'm curious, the backend, I know that pretty recently, Rust has kind of gone through this period of kind of explosion in terms of Rust as a web language. There have been a number of different things that have come out pretty recently for a web framework in Rust or there's that Tokio thing. I know Diesel is like the ORM for Rust in talking to databases. It looks like it's about to hit 1.0. There's a lot of stuff happening so I'm curious, what are you using to write the backend. I know you're using Rust but are you using one of these frameworks or have you rolled your own? How's that work right now? CAROL: Crates.io is one of the first web apps that has been written in Rust. Actually, if you look at the backend code, you'll see SQL being built by hand. It's going to the Rust postgres library so it has SQL injection protection. All the things are [inaudible] so don't worry about that but they're still like SQL with the Rust code so it's not using an ORM yet. I'm going to have to look up. There is a library that is using that I'm blanking on the name of it for but it's very low level. It just let you send HTTP requests and let you respond to HTTP. We're in kind of a Cambrian explosion period with Rust web frameworks. There's a lot of different ones. One that I'm excited about that I haven't gotten to tryout yet is Rocket. That was just released. The thing I love about Rocket is that everyone's really excited about it because it was announced and they have an awesome website with lots of awesome docs so that should be a lesson to any open source project that's launching is if you want to get excited about it, you've got to launch some docs. That will help so much. There's a lot of different frameworks happening. They're still little trilobites and little animals that can't walk on land on their own quite yet so there's still no Rails. There's the pieces of Rails. There's Diesel which would act like a record. There's Nickel and Pencil and Iron and Rocket. Tokio is the async framework that is getting more and more stable by the day. We got to try it out on a project recently and it's pretty fun. I still am working on wrapping my head around promises and futures and working in that way but I think as that stabilizes and people use that, that is going to cause like another explosion of libraries that enable really fast but safe web backend stuff, which I think is really exciting. If you're looking for the Rails experience of being able to plug things together and nicely, just declare a few things, it works but not quite there yet. But if it excites you to try out new things and figure out the best ways to do the things you want to do in Rust, this is a great time to jump in and help. CHRIS: I will say the Rocket website is beautiful and it even has this templating section, a testing library section. This is very exciting. It really looks like as the closest thing to a Rail-style web framework that I've seen in Rust so far. People should definitely check this stuff out. I'm curious, I know a lot is really interested in Rust and Ember, which doesn't surprise me because lots is really interested in Ember in general, which I think is awesome. But is there anything specific about working with the Rust and Ember together that seems, especially well suited or even like some gotchas that you guys have run into? One of the things I'm thinking of is like Ember is really big into JSON API spec and I don't know if Rust has a JSON API library for serializing things in that format. Is that something you guys have to tackle at all? CAROL: There might be. I'm not sure. Crates.io is using the Rust API adapter for Ember so we might not be keeping up with the latest of Ember. But I know there are people who want them to interface them better with each other. Actually, that's an interesting thing. Both Ember and Rust are on a six-week release trains sort of things so the way Rust people will say -- I don't know if Ember people do -- is stability without stagnation so they're both changing. Rust has backwards-compatibility guarantees so the code you wrote with Rust 1.0 is still going to compile today. You might have some warnings and there's probably new cooler stuff that you could switch to but it's still going to compile. I'm not sure about Ember's upgrade path things. Someone just sent in a pull request that we merged like three days ago to upgrade us from two Ember point versions. There were a couple of things that like [inaudible] and we weren't doing quite right and we had to fix. It's been interesting to kind of fit together, keep both of the sides, update it and upgrade it and continuing on using the best things. But I think they have similar philosophies around making things better all the time. CHRIS: Yeah, the whole stable upgrade path and backwards-compatibility guarantees is definitely mirrored on the Ember side of things. I can see that being a little kind of comforting place to be knowing that both your frontend and your backend are not going to suddenly just break on you one day because some new feature came out that breaks your router or something. That's very cool. One of the thing that I know you're involved in -- you're involved in a lot of things -- when it comes to Rust, it's very cool. But you also run or a co-run a conference, right? Rust Belt Rust? CAROL: Yeah, we had our first year in 2016 in Pittsburgh. I ran Steel City Ruby before then so I love running conferences and I love having them near me one, because it's convenient and I get to trick all of my friends into coming to visit me. But two, because there's a lot of tech stuff happening in the Rust Belt and places that aren't San Francisco or New York. People don't necessarily know about that and people who live here don't necessarily have the opportunities to travel as easy to conferences. I sort of start Rust Belt Rust, one because of the pun opportunity and one of our speakers drew a little bar graph. There were three conferences last year. There was Rust Fest in Europe which has [inaudible] amount of Rust. There's RustConf, the official Rust Conference in Portland that has a lot amount of Rust and then Rust Belt Rust has double the amount of Rust in its name so we're the Rust-serious Rust conference. We're going to do it again, in 2017 we're going to move it to a different Rust Belt city. I'm not going to say which one yet but we're closing in on a date and a venue in the Rust Belt city so watch out for an announcement on that. It was a lot of fun. We had a day of workshops and then a day of single-track talks and a lot of time for conversation. A bunch of the core team members came out and it was fun talking with a friend of mine who was trying out something with Tokio. This was in October so Tokio was still working towards their first big release and he was trying to do something with Tokio. I looked over and I saw Carl Lerche, Alex Crichton and Aaron Turon standing together and talking like 30 feet from us and I was like, "If only the three people working on Tokio were nearby to answer your question --" so he just walked over and talked about Tokio with them. I love getting people together to talk to other people working with things, talk to the people who are working on the things they're using and meeting the people behind the names on the internet so I love running conferences and having events like that. STEPHANIE: Carol, you have a Rust consultancy called Integer 32. How is that going? CAROL: It's going pretty well. We're learning a lot. One of the reasons I wanted to start it is because I felt like I wasn't learning more in my job. In my Rails job, I felt like I had kind of tapped out with that knowledge. In starting a business, I get to learn a lot of stuff like sales and marketing and taxes and invoices. Sometimes, I even get to program a little. We're still learning how to effectively find our target customers. We do have availability, if anyone listening is interested in hiring some Rust experts. Right now, I'm trying to figure out when can we bring more people on the team. I'm trying to decide if we can have an intern for the summer. It should be fun so yeah, it's going pretty well. It's been a slow build but we're lucky enough to have savings and be able to spend some time building our business but it's been really gratifying to feel like I'm in charge of my destiny somewhat, as opposed to the whims of a company. STEPHANIE: And if I were interested in some Rust consulting, what would be the best way to reach you? CAROL: We have a website at Integer32.com and a contact form on there. STEPHANIE: Thank you so much for speaking with us, Carol. It was a pleasure. I feel like I learned a lot about Rust. CAROL: Thank you for having me. STEPHANIE: All right, y'all. That's it from us. Thank you so much for tuning in. Until next time. Bye-bye.

Liz Baillie @_lbaillie | GitHub | Blog | Tilde Inc. Show Notes: 01:32 - Becoming a Developer 07:54 - Website Building 12:03 - Understanding Programming 17:34 - Coming to Peace with Ignorance 22:25 - Systems Programming 26:46 - Making Goals for Yourself 28:57 - Math and Programming 38:08 - Open Source Resources: Wicked Good Ember Liz Baillie: Journey to the Center of Ember Test Helpers Fibonacci Number Freewheel: Volume One by Liz Baillie The Flatiron School Skylight Impostor Syndrome Twilio Letter to a Young Haskell Enthusiast Hello, Con! OSCON Transcript: CHARLES: Hello, everybody and welcome to The Frontside Podcast Episode 57. My name is Charles Lowell. I am a developer here at The Frontside and with me is Stephanie Riera, also a developer at The Frontside. Today, we have with us Liz Baillie, who is a developer at Tilde. I am actually really excited to have Liz on the show. I saw her at Wicked Good Ember back in June of 2016 and her talk was definitely one of the more memorable ones. You come away from a conference kind of only remembering a certain number of talks that stick in your mind and as time passes, the messages may fade but some of the message just stick with you and the one I got from her talk was a feeling of empowerment that, even though I have a lot of experience, I could approach any code base and try and grapple with it and understand it. I came away thinking, "There are a lot of code bases out there that I don't understand but if I apply a certain set of techniques and a certain level of fearlessness, I will actually get there." You know, if I want to go attack something like I don't know like Kafka or something like that, I would feel better about that. That was actually a great feeling coming away from that, a feeling of great power so thank you very much for that, Liz. LIZ: Yeah, no problem. CHARLES: Why don't we start with a conversation of how you came to be a developer? Everybody's got kind of a unique path. What's yours? LIZ: Well, I went to art school and I studied comic books. I actually have a bachelor's degree in comic books. I was a cartoonist for a number of years and at some point, maybe like 10 years ago, I had a friend who was a programmer. He's a web developer. But I didn't even what's a web developer was. But I knew he worked at home and he made his own hours and he made a lot of money. It seemed like an awesome job so I was like, "How did you get into that?" And he's like, "I don't know. I just kind of mess around and figured it out." And I was like, "Uh... I don't know what that means." Like how do you start? I have no idea. I went to the bookstore and I look at the For Dummies books and I got Programming for Dummies or something and it was like Visual Basic, I think. CHARLES: All right. What year was this? LIZ: That's 2004. I guess, it was a little more than 10 years ago. But it didn't say that on the cover. It was like 'Programming' and I was like, "Oh, cool. I'll learn programming." I don't even know what the difference of languages was or anything like that. I did a couple of exercises in that book and I had no concept of how this would become a website ever. I was making 'Hello, World' and little things that spit out Fibonacci numbers or whatever. I kind of gave up on that and I was like, "I don't care. I don't mind being poor." I'm used to it so I kept being a cartoonist, putting out books and stuff. I did a little PHP and HTML type of stuff in making websites for myself in between but I don't really consider that programming. It didn't feel like programming. CHARLES: Did you ever put any of your cartoons on the web? LIZ: Oh, yeah. Google me. They're there. [Laughter] LIZ: I might have some stuff like my web comic, I'm not sure if it's still up. But I had a web comic called Freewheel, which was about this girl who runs away from home and joins a band of magical hobos. CHARLES: That sounds like a career change to programming. It was oddly prophetic. LIZ: Yeah. It's out there. Anyway, I got to a point where, long story short, I was tired of being broken for all the time and I have to figure out some way to make money that I like doing so I thought, "I would go back to school," so I went back to school. I didn't start out with computer science but I took some math and science classes and I got really into math a lot. I really enjoyed math so I started looking into what careers can I do that are math-y. Somebody said, "If you enjoy the problem solving aspects of math, you'll love computer science," so I took a Computer Science 101 class or something like that and I got really, really into it like I just killed it. I just loved it. It was awesome. But I still didn't understand how you made that a website. In the back of my mind, I was like, "We did this thing --" We learned Python in my class so there's some program we had that like move a little turtle around and do pictures or something. I was like, "I don't understand how this makes a website." CHARLES: You got to move that turtle around a lot, especially like account for the kerning in the fonts and stuff. LIZ: Yeah. I have no idea how you make that a job, like the stuff that we were doing like spitting out Fibonacci numbers and making a little adventure game or something but how does that translate into anything else. That was in 2014 and that was around the time that web development bootcamps were starting to be more of a thing. I heard about a school called the Flatiron School in New York which is right at the time and I thought, "This sounds great. In three months, they'll actually teach me how this makes a website and finally know how does this make a website?" I applied in kind of like on a lark. I don't think I'll get in, I didn't know how can I afford it or anything and I applied and I got in. I was really lucky that my stepdad help me pay for it so I don't have to worry about it. I did that in three months and then I got a job. In November 2014, my first web job and now I know how those codes make a website so here I am today. CHARLES: What a journey. LIZ: Now, I live in Portland, Oregon and I make websites. Not really, I work on web apps, I guess is more accurate. CHARLES: So you actually went straight from the Flatiron School to working at Tilde? LIZ: No. I was in New York at the time and my first job was at an ad tech company called SimpleReach and I worked there for a little over a year before I got the job at Tilde, then I move to Portland. A year ago yesterday was my first day at Tilde. CHARLES: Fantastic. Knowing that company and knowing what they do, they must have you doing some really, really fascinating stuff. LIZ: Yeah, I do a lot of typical web stuff. I work on the Ember side of our app, Skylight. I also, more recently have been working on Rails engine that's also a gem that spits out documentation automatically, which is pretty cool. CHARLES: Now, is this documentation for the product or is it just documentation for any real site? LIZ: No, it's for our products specifically but I don't think it would be very difficult to alter for someone's personal needs, other than ours. But it's basically like if someone can write a markdown document, then we'll parse it and spit it out into HTML and all these different places so that it just updates the whole documentation site around our products. CHARLES: Basically, there's an infinite amount of stuff that has to happen to make a website because there are literally so many moving parts. What's been your favorite kind of area, I'll just say the whole website building because that really is like the tip of the iceberg. The actual iceberg goes way, way, way beneath the surface. But what's your favorite location on the iceberg so far? LIZ: I kind of like the middle, I guess. I always feel bad saying it because everybody talks badly about CSS but I just don't like it. I tried it really hard. One of my resolution this year was I'm going to try really hard and I'm going to like it more. But what I like the most is whenever I get to do pure Ruby. I learned Rust in the last year or two and anytime I get to make the stuff behind the visual aspect work or kind of like meta stuff. I'm saying this and it's totally wrong but I did my first meta programming the other day or last month. The metaprogramming that I did ended up getting cut out of [inaudible] but I got to do it before it got deleted. It was pretty cool. CHARLES: That's generally how it works. Metaprogramming is the program we do that we end up hating ourselves later for but it's really fun. LIZ: Yeah, they're like, "This is cool but this is not the most efficient to do this." It's like, "I guess, we don't have to dynamically create methods based on all our filenames. CHARLES: As far as the CSS goes, I actually see CSS like raw kale. It's actually really good for you, if you like to it eat in large quantities and it's like fantastic but it's not always the most pleasant going down. LIZ: It tastes bad. It has a terrible feel. It's like eating rubber. I am really lucky, though that I worked with a couple of people who are incredible at CSS and when I get to pair with them, it's like watching magic happen. CHARLES: Yeah, you realized, for all its quirks and strange ways that you approach it, is an outlier but it is kind of a fully-formed programming model that has a lot of depth and a lot of people have really, really generated some pretty neat abstractions and ways of dealing with CSS. But it is like, "I just want to fix this one thing," and it's basically a sea of things that I have no idea how to navigate. LIZ: It's one of those things. I always think it's funny, anyway that I come from a visual art background but the thing I like about programming is anything visual. CHARLES: That is actually really is fascinating. LIZ: Yeah, when they hired me here they're like, "You're going to be really good at design," and I'm like, "I just want to do programming." CHARLES: Like never the temptation, like this is just because you've actually kind of drank your fill of that in a past life? LIZ: I think I've talked to my coworker, Kristen about this because she actually has a design background and we paired together all the time. She's one of the people that I was talking about who are geniuses at CSS. She's a genius at it. She has a design background. We've talked about this how art and design are kind of different, like the brain stuff that I use to make a comic is really different from designing a book cover or designing an experience. It's all part of the art side of the brain but it's different compartments of the art side of the brain. I don't really have a design background as much as I have like a narrative and a drawing background. STEPHANIE: That and your interest for math that probably has a factor. LIZ: Yeah. STEPHANIE: Going back to your journey, I wanted to ask about it seems like it took you awhile to knock on different doors and finally feel like, "Now, I understand. How do I work with what I have to create a website?" We have similar backgrounds in that. We didn't start off in programming and I also went through a code boot camp. But mine was a little different where when I finish, I didn't really feel I understood what programming really was. I still felt like I understood a primitive level like just building something, just a 'Hello, World' using HTML CSS. When I finished, it took me a year and a half to actually get a full time programming job, like a legit job. Before that, I was scrambling doing three part time jobs and lots of WordPress grunt work. Even though I thought it was actual experience, it was enough experience but I feel like a lot of the programming concepts that I've had to learn and just basic functional programming, I've learned it on the job. I don't yet feel like I am a legit 'real programmer'. We were talking about the Pinocchio thing like, "I'm a real boy." But I want to be a real programmer. [Laughter] STEPHANIE: What I'm curious about is at what point did that happen? When did that click and when did you stop having -- I'm sure at some point you had -- impostor syndrome? When did that just evaporate and you're okay? LIZ: I still have impostor syndrome all the time. It's weird that it's like I have a sense of, "Oh, I can figure anything out." At this point, I know who to ask or where to look and I could figure anything out if I really wanted to. But I also feel like everyone else is better than me. I get impostor syndrome in that sense, not that I'm not a programmer but that everyone else is better than me. When did I start feeling like I was a real programmer? Definitely not at my first job. When I started my first job at SimpleReach in November 2014, I had two months in between bootcamp and the job. In that time, I made some weird little apps but nothing super serious. I made an app that I use the Twilio API to anonymously text Seal lyrics to people. It sends either lyrics from Kiss From A Rose or a fact about Kiss From A Rose. You can choose which one. I made stuff like that. CHARLES: [Singing in the tune of Kiss From A Rose] There's was so much in app can tell you so much it can touch. Okay, I'll stop. I'll stop right there. I promise. LIZ: Yeah, so I did stuff like that and I sort of wrote my own crowdfunding to go to RubyConf because I gotten an opportunity scholarship ticket that year. But I couldn't afford to go otherwise. I did a little crowdfunding thing but I did little things like that. I didn't really feel like I understood everything so I was looking on other people's code and forking stuff to make all that happen. Then I got my job and it was small-ish start up at the time and they didn't have a whole lot of on-boarding at all. It's kind of like I showed up, they gave me a computer and it took me three or four days to get their app running locally. It was just a lot of leaving me to my own devices a lot of the time in the beginning and I was kind of like, "I don't know what I'm doing. What do I do?" It took a while. As the company matured and as I matured as a programmer, they kind of develop a little more infrastructure, I guess for supporting junior engineers. As time went on, I became better and they became better at mentoring me. I don't know when I felt like a real programmer, probably sometime in the middle of that job. I gave my first technical talk, I guess or conference talk at EmberConf in 2015. I gave a lightning talk at the behest of the Leah who is now my boss. It was a five-minute talk on why testing an Ember sucked at that time. It sucked for me to learn and it was really hard. I wanted to learn it but it was really hard. Then after that, people started talking to me. They came up to me after and they are like, "Oh, my God. Blah-blah-blah." I was like, "I don't know half the stuff these people are saying. I don't understand what you're talking about." I'm going to smile and nod. But maybe a little bit after that, I kind of started feeling more that I could solve problems. I think public speaking actually helped me a lot with that like when I realized that I had something to say and that people want to hear it, then I could help other people feel empowered to learn stuff, I think that was part of it as well. CHARLES: Yeah, I really like that. Obviously, I'm going to push back a little bit on Stephanie, just in terms of the day-to-day. You definitely deliver daily as a programmer so you can look at that. You've mentioned this at the very beginning of your answer and it almost really sounds like what you came to be was more of a kind of a peace with the things that you didn't know, rather than feeling confident about the things that you did. You said something and I'm going to paraphrase it but it's like, "I got to the point where I became sure that I would be able to figure it out." Or, "I had strategies for being able to figure it out." Maybe we can unpack that a little bit because I feel that's actually very, very important and that's a skill that's important to have at any level of experience in your career, whether it's one year or whether it's 20. Certainly, that message when I saw you speak that's something that I took away as a very experienced developer. I felt actually empowered by it. What are some of those mechanisms to feel at peace with your own ignorance? LIZ: I think part of the problem for me, I started learning how to program before I went to dev bootcamp or whatever, that I was really good at stuff. I actually think that was a problem because I was used to succeeding immediately or like always doing everything right so it's hard when you start learning something and you don't realize when you first start learning programming and it's not supposed to work immediately, like you're starting with something that's broken and you're making it work. CHARLES: Right. In fact, 99% of the experience is like every time I look at a piece of software, I'm like, "Someone sat with the broken version of this for a year and then it work and that's what I got." They got to live with the working version for two seconds before it came to me and they spent the rest of the time, totally broken. LIZ: Yeah, totally. It's hard when you're used to creating something from scratch like doing comic books and like writing stories and stuff. It's never broken it's just blank and then you add to it so I'm used to that sort of workflow. Then I started in this new field where Rails is new or whatever then it's just errors as far as the eye can see until you fix it, until you configure it, you made it work. It's hard to change your mindset into that. It's easy to feel like a failure when all you see is errors and you don't know that that's normal. I helped a couple of my friends to learn to program and I think the biggest hurdle is just mentally overcoming that it's not you, you're not a failure. It's just that everything's broken until it's done. STEPHANIE: I can definitely relate to that. I was always one of those overachievers, straight A, AP class. I'm not even kidding. In my high school, they called me Hermione, which for those that don't know, that's the girl from Harry Potter. It's like you take it really personally when you feel like you're a failure. You feel like you can't deliver, you don't pull your own weight. For me, it's actually so overbearing that it can even inhibit you from doing things like public speaking or other activities. But one of the reasons why I do like to teach whenever I can is because that's when you realize, "I do know a lot of things," like how to do stuff on Git and just basic things that you don't even think twice about. I volunteered for this these high school girls and no one really gave me any instructions and I just rolled out of bed for this thing and just have them build a basic cute little web page with their picture and this and that. I had to really think hard to how do I put just a regular image tag and I had to peel back all the old layers of stuff that I don't do anymore. You don't think about those kind of things in Ember or JavaScript frameworks. I caught myself in keep on saying dom and this and that and they were like, "What is a dom?" And I'm like, "Urghh." But then I realized, I do have all this context, I guess I don't appreciate it or something. LIZ: I think talking to beginners when you're slightly above beginner-level in helping other fresh beginners is one of the best things for you as a new developer because you realized, you're like, "I actually know stuff." STEPHANIE: Yeah, that's usually the type of advice I like to give to other aspiring junior programmers. I also wanted to ask about it seems like now you're going through something similar because you tweeted or you're asking about systems programming. What's that like? LIZ: I'll start at the beginning. When I started at Tilde about a year ago, I knew that we use Rust, which is a systems programming language, a lower level language than Ruby or JavaScript. We use it for some aspects of our stacks. I thought, "That's really cool. I want to get into that nitty-gritty type of stuff so how do I learned that?” I started learning Rust but I didn't really know how to apply that knowledge. I wrote like a little adventure game in Rust and it was almost exactly the same as when I first started learning about web development, it's similar to how does this become a website, instead of like, "How does this become a computer thing?" I don't even know what systems programming is but I hear Rust is a systems programming language so I want to learn that stuff, like what is that stuff? A couple months ago, I think it was, I tweeted like, "Anybody have any probably three systems programming resources so I could learn more about systems programming?" And I got huge amount of responses. Everybody was super kind and helpful but a third of the responses were like, "Well, what kind of systems programming?" And I was like, "I..." [Laughter] CHARLES: "The kind that happens on a system?" [Laughter] LIZ: I don't know. It was kind of the same thing. I think I used this metaphor earlier but it's similar to when I first started learning programming it was like I was standing at the front of a forest and I knew that the stuff I want is in the forest but I don't even know what a tree is, you know what I mean? Eventually, I learned what a tree was then I learned what a map was and I learned how to get through that forest. But then in the middle of that forest, I was like, "Oh, there's a tunnel," like there's another stuff. "I want to get on to this tunnel," but I don't know anything about living underground, you know what I mean? Like, "What do I need? What even is there?" I have no idea so that's kind of how I feel about systems programming. At the moment, I'm trying to go into this tunnel but can I breathe down there? I don't know. Where does it lead? CHARLES: I feel like at that point when you're about to enter into the tunnel, can you intentionally apply filters for information that at that point is not useful like the difference between a stalactite and stalagmite is not useful when you haven't even gone into the cave yet and you're just like, "How do I actually just get down there with a flashlight?" How do you go about deciding which information is useful and which is not at your particular stage? Because obviously, it's all going to be useful at some point but at what point it becomes useful and what point do you just catalog it and put it for later? I feel like that's very, very hard thing to do. Do you feel like you're able to do that? LIZ: I'm not sure. I think I said this earlier but I feel like I can figure most things out at this point like if I really want to. One of the things I learned just from talking to people on Twitter about systems programming is like, "Oh, some examples of systems programming are operating system," or like a browser engine because I'm still learning Rust and I gotten to write as much lately but I know that there is servo which I believe is a browser rendering engine written in Rust, it's something like that. CHARLES: Supposedly it's going to powering Firefox at some point. LIZ: Yeah, stuff like that, I think is really interesting but now I know a little more about what to look at in terms of as far as I understand, there is probably an infinite amount of different kinds of systems: operating systems is one, maybe a browser engine is another. I can't remember the others but I'm sure people tweeted it out to me. STEPHANIE: I feel like we touched on something which is it can get overwhelming when you're starting off in something new. Trying to understand what you don't know that you don't know. LIZ: Yeah, that's the hardest thing. STEPHANIE: How can you make tangible goal marks for yourself if you don't even know what you don't know? When I first started off, when I would pair with someone that was more advanced, I remember having a realization that every time I would look for an add-on or I'm looking at someone's repo, I would take my time to read everything about it, all of the Ember documentation and I need to know everything. Then later I realized that is totally not the case. Like Charles said, people develop this filter for noise and only focusing on not the entire tool box but that one tool that they need for that one specific thing that they're doing and I realized it only when I was pairing with people and seeing that. They go to this repo, skim it, "No, this is not what we need. Let's go to the next one. Let's try to find a method that what we need," and then they would just search on the page. "Oh, this looks kind of similar. Let's plug this in," and I'm just like, "What? You can do this? You can just copy/paste someone else's stuff?" and it was amazing. But when you're starting out, you don't know all of these things and unfortunately, kind of waste a lot of time thinking that you need to know everything and you don't. CHARLES: Yeah, Cheating is totally a virtue in so many cases. [Laughter] LIZ: Totally, for sure. CHARLES: Just being like, "I don't need to understand this," but I just know that it works. You pushed at what point that happens like further and further back but that boundary of understanding is just simply always going to be there. No matter where you are, that kind of veil of ignorance, you can push it out but it's just can be further away. I am actually curious, you mentioned you got really into math, this is when you went back to school. What drew you to that and how have you applied, if you've applied? Have you found it to be an asset in your development career? LIZ: For sure. When I first went back to school, it was with the idea that this is totally different now, obviously. I thought I might become a veterinarian -- CHARLES: You need a lot of math for that, right? LIZ: Well, it's like a lot in biology and there's a lot of math and science and stuff. I had to take a bunch of science classes and take biology and chemistry so that involved taking some pre-calculus and calculus and more calculus. What I realized, though was that I hated biology and chemistry but I love the math that I was learning. I loved the process of problem solving and just figuring out puzzles. When you get into calculus, how you solve problems, they're similar to how you solve problems in programming where you have sort of a framework like I have this certain language which would be the different theorems or whatever in math and you can just pick and choose which ones will fit your problem and if you're taking a calculus test, you could be sitting next to the same person and you might come to the same answer in different ways so it's similar in programming where you have all of this documentation, you have these languages, you have use other frameworks and you can solve the same problem in a million different ways. But in terms of how people talk about needing math for programming, I don't necessarily think you need math for programming but if you already like math, it's definitely sort of a happy path, I guess because you get the same joy out of programming that you get out at solving calculus problem. But if you don't like calculus, it's okay. I don't think it's necessary. CHARLES: One of my favorite blog posts of all time is this letter to young Haskeller, I don't know if any of you guys have ever read that. It's fantastic and it's an experienced person in the Haskell community talking to someone who's just coming in and it's incredibly empathetic and wonderful. I think it's a message that needs to be heard more generally. I think it's ironic coming out of the Haskell community as it does because they definitely have a reputation for being a little bit salty and a little bit exclusive. But it's actually a very inclusive message. One of the great points they make is they say we've got the whole equation reversed. It shouldn't be, "Math is hard, therefore programming is hard." It should be, "Programming can be really fun, therefore math on which programming is based, can also be really fun." You can go both ways. If you find math fun, you can find programming fun and if you find programming fun first, you can later go and have fun with math. You can pick and choose which parts you want. I think it's a great message that needs to get out there. LIZ: I think it's also really, really important to note for anyone who might be listening that is getting in to programming, that is scared of math or has had a bad experience with math that it is not necessarily to love math. I think that scares a lot of people away and a lot of the stuff that people learn when they're first learning programming are math based. When I was in the Flatiron School, Some of the exercise we did in the beginning with just pure Ruby were Fibonacci sequence. They were sort of math-y and that turns a lot of people off and makes people scared. If someone is hearing this and has experienced that, don't be scared. You don't need to worry about it. But if you love math, then it's great but you don't have to. STEPHANIE: I'm one of those people that always had this mental block of like, "I'm not good at math." I was good at everything in school. I excelled at everything except math. I think a lot of it came from my struggle when I was a kid so you have this self-perpetuating thought that you aren't good at something. Every time you take a final or something, you blank out because you have this mental wall in your mind. What I found weird was I was doing the exact same thing. I was taking calculus for bio-sciences and physics too at the same time. In physics, I loved that class. It was so awesome and I realized that half the stuff I was doing was going backwards in all of my problems and it was fun for me. Eventually, I was taking a final for my calculus class and I didn't remember the equation that we needed for that class so I took out all the variables and I solved it as if it's a physics problem and I got the same answer and I was correct. I realized at that moment, if you just remove the negativity from your mind and you try to apply yourself in the same fashion as you would in something that you enjoy, you'll just forget for the moment that it's math, that it's something that you 'suck at'. You actually could do good in it and not get stuck. I realized I actually do like math when it's veiled as chemistry or physics. LIZ: I think a lot of people have that experience with math. They have a really bad experience when they're young and then they get stuck and they feel like they're just not good at it like somehow, on this subatomic level, you just can't change it or you're not good at it. It's not really true. STEPHANIE: Yeah. CHARLES: I actually love that example because it is, it's all integrated. We are constantly doing things like math without even realizing it. Actually, one of the things I love about the Montessori education is that's the way they actually teach it. They have all of the different great lessons, they want to convey to the children which is things like courtesy and grace, things like taking care of your things, things like music. But for all, I think they've got a bunch of different categories but they make sure that they always intersect with each other and you get that in surprising ways to make sure that if a child likes music, use the music as a way to introduce them to arithmetic. If they like arithmetic, use that as a way to introduce them to music. If they have things doing design, I don't want to say, interior designer or clothing design but practical life stuff and if that's something that a child really is drawn to, then they'll use that as an introduction to music or geography. There's all these parallels that are constantly there and you can ride whichever rail works for you to whatever area that you want to go. There is no set way to approach math. You literally can find a way that works for you. STEPHANIE: The subjects aren't mutually exclusive, "Because you're not good at this, probably you shouldn't become a programmer." CHARLES: It's not expected that every child will grow in one subject at the same rate that they'll grow in every other subject. They just let the children explore the area that they're interested in and let them go crazy. If they're really into art, they just let them explore and learn as much as they can and then slowly entice them and just show them the connections that art has to courtesy and grace to math to music to other things and let them see those connections and then follow them on their own. That's why they call it -- the kind of grown up in there -- the guide. It's really there. The way that they push is by showing them the connections but then using the kind of internal motivations of the children to move. I actually have some pretty strong feels on this. I feel like our education does leave a lot of people behind because there's this expectation that in every single subject, everybody will goose step forward at exactly the same rate and that's just a fable. It's not real. It's not how the human mind works. LIZ: Yeah. CHARLES: But yeah, I actually think, certainly for me and my connection to math has been helped by the fact of programming and now, later on after having done a lot of programming, so much more is interesting to me about math and I can see beauty in it, I think where I didn't see beauty in it before. STEPHANIE: For one of the projects that we've been working on, we have been doing an Ember upgrade. I basically needed to get some changes for one of the dependencies and I have no experience in open source, whatsoever. That happened for the past two weeks. I was making a lot of PRs to two different dependencies and that was my first experience with open source. It was less scary than I had imagined and I actually got a lot of great feedback from it. Now, I realized that it wasn't as hard as I thought it would be and most people are very receptive to your PRs or if you have questions about their open source because they need help, they need people to help them tackle all the issues that they have so I'm curious, do you have any advice for people that are interested in contributing to open source but they may find it daunting and they don't want to look dumb or do things the wrong way? LIZ: One of the things I've been interested in since I started learning programming is open source because I enjoy collaborative atmospheres and just the idea of a big group of people coming together to solve problems. It was something that I wanted to do since the beginning but it's super intimidating because when you think of people who are open source maintainers, at least to me in the beginning, they seemed way above me like Gods so I'm like, "How can I possibly be useful to these Gods?" At my last job, my manager was like, "I got a couple of goals for you and for your career." One of my goals was I want to contribute To Ember CLI Mirage. That was a goal. I just thought, "This is a great add-on. This is a great project and everyone uses it and I love it and I would love to contribute to that." I made it a goal but then in that in the middle of that time period, I got a job here at Tilde and I went to Portland. Shortly after that, I went to the repo and I was like, "I'm going to do this thing," because one of the reasons why I chose it as a project to contribute to is because I heard Sam is a really nice guy. One of the things was that I was really intimidated by the people maintaining projects is like, "Well, he's not intimidating." I feel okay about this so that's a good first step. The second step is let's find a thing to do so I look at all the issues on the repo and I find something super simple which is just adding in-line documentation. That's what I did and I was like, "Can I pick this up?" I was feeling super shy so I didn't even want to put it on the issues so I think I just pinged him on the Ember Slack and just like, "Can I help with this?" He's like, "Yeah, yeah. That's great," so I made a bunch of in-line documentation additions to the project and I made my first PR and it felt like such a way that it's not as scary at all as I thought it would be so I started contributing to other projects, things that just came up. Not so much like in your situation where it was a dependency I was using but more like I saw somebody tweet about it and like, "I just made this project and I think there's a bunch of typos. Can somebody just spell-check this for me?" I'll go in and do a couple of typo fixes. Another situation when I was reading through a repo because I want to learn and there's a project called intermezzOS which is Rust operating system, like a tiny operating system. I was just reading the code and I was like, "There's a couple of typos. I can fix this," and stuff like that and I found, through that experience, that open source maintainers are super happy to have you help in any way that you can, even if it's a little things. In the last couple of months, I started my own project which is like an app -- it's not an add-on or anything. I actually got my first couple of PRs from other people and other people are helping me build it. I don't think I've ever met but every time I get a PR, I feel like I won a prize. Every time someone contributes and I'm like, "Thank you." I cannot give you another -- [Laughter] LIZ: I love that you're helping me. You know, like I only have one hour a day to work on this thing so anything, anyone people can do to help me is so great. Now I have the experience of being on the other side and I can attest to the fact that most open source maintainers are incredibly stoked for any help they can get. Even if you're new, just find someone who's nice and ask them how you can help. STEPHANIE: Yeah, that was a realization that I had because I was communicating directly with this person in the Ember Slack as well. I had submitted a PR and later he was like, "Hey, while you're at it, do you mind adding in this one property that's missing?" And I'm just like, "All right. Sure." Later he offered if I wanted to become a collaborator because I was putting in so many PRs and like you said, he hasn't had the time to cut out a new version or to fix the things that you keep in your head, "Okay, I'm going to go back and fix this," and then someone else is like, "I want to fix this thing," go for it. That's the best. LIZ: Yeah, totally. It's a great way to learn more stuff too. CHARLES: I like the point about choosing a project that you know is not intimidating because unfortunately, there is a lot of negativity that happens out there. LIZ: Totally, I knew that and that was a big blocker for me, for a long time. CHARLES: Yeah but knowing that there are actual, I would like to say, a majority I don't know if that's true but it can feel like it's enclaves, just because negativity has a way of clouding everything and propagating but there are certainly areas where we put that way and it's very healthy, it's very collaborative and welcoming and making a definitive effort to first know that they're out there because if you have a negative experience, you make sure that you don't bounce off of that and then define them. I really like that, how you were deliberate about that. LIZ: Yeah, it seems like the most important thing, if you're a new programmer and they're like, "How do I get involve in open source," and your first advice is like, "Find someone who's really nice." It doesn't sound like the right advice but I think it is the right advice. CHARLES: That's because that's where you'll stick. LIZ: Yeah and you'll want to collaborate with that person and that project because you're not scared of being insulted or something. CHARLES: Well, that was fantastic. We can wrap it up. LIZ: I have two talks this year so far coming up. One is going to be in Toronto at the end of this month at a new conference called 'Hello, Con!' I built a type space adventure game in Rust and I built it side by side with the same game in Ruby so I can learn Rust by doing the same thing on both sides. I'm going to be talking about the similarities and differences and things I came across learning Rust as a Rubyist. I also have a similar talk in May at OSCON in Austin about learning Rust as a Rubyist but at a slightly different, longer talk. I did a version of it at RustConf last year. It's kind of in comic book form so it's all of drawings and it's sort of a story about going to a place called Rustlandia as a Ruby person and how you literally navigate that world, not just everything is sort of a metaphor. I'm getting that talk again in a longer form at OSCON in Austin in May. CHARLES: Well, fantastic. You have to stop by the office and come see us. LIZ: Yeah. CHARLES: But thank you so much -- LIZ: Thank you. CHARLES: -- Liz for taking the time to talk with us. This is a great conversation again. You know, I feel like I'm going to come away feeling that I've got more tools to deal, certainly with my daily struggles -- LIZ: Yeah, get pumped! CHARLES: -- In programming. Yeah. LIZ: Programming! Yeah! [Laughter] LIZ: -- One of the Mortal Kombat music comes in -- Tun-tun-tun-tun-tun-tun-tun-tun-tun... [Laughter] CHARLES: I remember actually seeing Mortal Kombat in a theater and I actually getting up and dancing in the theater and then the rest of the movie just sucked. It was like they spent the whole budget on the first 20 seconds of that movie. Anyhow, all right. That's it from The Frontside. Remember to get in touch with us at Frontside.io, if you're interested in UI that's engineered to make your UX dreams come true.

Steve Klabnik @steveklabnik | Blog | GitHub Show Notes: 02:56 - Getting Into Rust 05:51 - Working on Rust for Mozilla 07:01 - Writing Documentation and Preventing Burnout 13:24 - The Rust Programming Language 18:45 - Rewriting Firefox in Rust 21:20 - High-level Functions 25:23 - Typesystem and Concurrency 36:35 - Rust and Web Developers; Digging Into Rust on a Deeper Level 43:46 - The Rust Ecosystem and Using Rust on a Day-to-Day Basis 48:38 - The Rust Book Resources: Rust For Rubyists Cargo Servo Application Binary Interface (ABI) MetaLanguage (ML) Tokio Systems Programming intermezzOS Steve Klabnik: Exploring Ruby Through Rust What's new with “The Rust Programming Language”? rustbook Transcript: CHARLES: Hello everybody and welcome to The Frontside Podcast episode 51. I'm here, my name is Charles Lowell. I'll be hosting today. With me is Chris Freeman, also of The Frontside and with us is Steve Klabnik. Now, most of you probably heard of Steve before. My first encounter with Steve was actually at the LoneStarRuby Conference back in... Gosh, I don't know. It was many, many years ago and he was giving a talk on Shoes, which I also had never heard of before. It was a wonderful story of a code archaeology project where he was kind of investigating, rehabilitating, and in carrying forward a project that the 'why the lucky stiff' had done. That was a wonderful introduction but it was certainly not the last time that I encountered him in his writings and in talks and stuff, mostly within the Ruby community. But it popped up again and again, talking about Rust APIs and always making a point to take a good knowledge that he'd learned and spread it around. Personally, I've lost track of Steve or hadn't really heard much of what he was doing for a while. But then Chris came into the office and he was always talking about this language called Rust. While I've heard Rust, Chris was just all about it and wanted to have Steve come on the show because it turns out that Steve, you've been really, really, really into Rust these last few years and sounds like concentrating most of your work there. STEVE: That is totally true and accurate. Also to go back a bit, that means that you are in attendance for my very first conference talk ever. CHARLES: Really? STEVE: That was literally the first one. CHARLES: Wow, it was a great start. That was a great story. It was educational and also touching. STEVE: Thank you. It's actually interesting because what happened was is that someone else who works on Shoes have encouraged me to submit to RubyConf and I was like, "Who would want to hear me talk at a conference?" I submitted the talk and RubyConf accepted it and I was really excited. Then a bunch of other conferences noticed and two other conferences had asked me to give a talk before RubyConf happens and LoneStar was one of them and it was the first one chronologically. That moment was also very special to me as well. CHARLES: Fantastic. What year was that? STEVE: I want to say it was like 2012 or 2011. It's really hard for me to pay attention to time and date. My history is so complicated that I often forget. I've literally told people that I'm 10 years old or younger than I am because I would like mess up to date on the things. It just happens. CHARLES: Yeah, but it was a while ago and it's been quite a journey, in between now and then. STEVE: Yeah, definitely and you're also definitely right. It is now literally my day job to work on Rust so it is definitely the focus of most of my efforts. Partly, why I made that happen was because it was the focus of all my hobby efforts before I made my job. It's definitely been a couple of years that I've been a full-time on all the Rust stuff. CHARLES: How was it that you actually got into Rust? How did you hear about it before everybody else and how did it capture your attention? STEVE: I've always liked programming languages and learning different programming languages. Ruby was sort of where I became known professionally. But it wasn't the first language that I knew and I knew it was never going to be the last. As much as I always loved Ruby and I'm like literally have a tattoo on my body so I will be with Ruby forever. I always try to learn new stuff and I find it exciting. I'm from middle of nowhere, Pennsylvania in the suburbs of Pittsburgh on a cattle farm and I was visiting my parents for Christmas one year. There's not really a whole lot to do out of the very small town so I was just reading the internet, as usual and it turns out that that was the day that Rust 0.5 had been released. I saw this release announcement go by and I was like, "I vaguely heard of this programming language once or twice maybe. I don't have anything to do. Let's give it a try." I downloaded and installed it. I looked at their tutorial and the tutorial has a problem that a lot of tutorials had, which is I read it, I said, "This all makes sense," I tried this down to write a program, and I had no idea how to actually write a program in it at all. I'm just completely confused. I couldn't actually apply the sort of syntax stuff that I learned. At the same time, I was going to be working on this hypermedia book -- that was my plans for that trip -- as always, you just rewrite your tooling over and over again. You [inaudible] like, "Just don't write the thing. Write the tools that make the thing," so I wanted to try out a new way to take mark down and generate PDFs in HTML, involving pandoc. I sort of had that all set up and I said, "Well, let me give this a try run. What I'm going to do is I'm going to write down what I learned in Rust as I learned it," and sort of from a Ruby programmers perspective, I'll use that and working with my new tooling to see if it works to actually work on the real book and it will also help me understand Rust better because one of the reasons why I do all this sort of teaching and advocacy is because I think it helps me learn. Just as much as I like helping other people learn stuff, I find that the repetition and being forced to explain something to someone else really make sure that I understand what I'm talking about. That's what the thing called Rust for Rubyist became boring. I'm a sucker for alliteration and that sort of became the first to tutorial for Rust from outside of the Rust projects proper. From there, I went on to submit some pull requests because everything's open source so I wrote some documentation and funny enough, my first ever pull request to Rust was actually rejected based on procedural grounds. At the time, they didn't actually accept pull request to master, they accept this other weird branch and GitHub don't have the ability to re-target the branch of the pull request. I also, always like this story because the thing that I now on the core team of, like my first attempt at getting involved was wrong and was turned down. But I'd fixed that pull request issue and got that in but it is kind of kept working on an open source capacity for a while and then decided to ask Mozilla if I can make it my job. Luckily they said yes. CHARLES: Wow, so what? Your job at Mozilla, like you just kind of showed up and said, "I would like to have a pretty cool, awesome job, working on this brand new language," and they were like, "Sure, come on in?" STEVE: To some degree, yes. That's one way of putting it. There is always the devil in these details. The first thing is that that wouldn't have worked if I had wanted a different kind of job. But when someone comes to you and says, "I would like to write documentation for you all day," you go, "Oh, my gosh. This literally never happens." If I had wanted to like work on the compiler, I'm pretty sure they would have said no. But because they knew documentation was important and they wanted documentation and because I had already been basically doing that job in an open source way, it's like I've had a year-long interview already. Then finally, they actually didn't have headcount at the time so I actually moved on as a contractor initially and had to do some freelance work and then eventually, once we were able to hire a new person kind of got it in. They're like a cool kid story. It's like, "Oh, yeah. I totally asked Mozilla for my perfect dream job and they just gave it to me," but like that's not really the way that it works. CHARLES: Got you. That actually leads me into a question that I have wanted to ask you. You write a very good documentation as your day job and documentation is extremely hard. For me, it is extremely hard to get and stay motivated to document something that I've worked on. I think that is probably a common enough experience for programmers. We don't recognize because we use documentation that it's extremely valuable and yet, it still this thing that is just a constant uphill battle. I'm curious, how do you manage to stay motivated to write documentation for an entire programming language over the span of years? STEVE: As I'm often want to do, this has like three or four different components. I guess, there's a couple of different things involved. The first one is that I actually got accepted to go to English grad school, although I ended up not pursuing that. Like writing, it's something I have just always enjoyed. I got a Bachelor in Computer Science but then I was going to go to grad school for English and due to university shenanigans, it didn't really work out. They told me I was going to get a free ride and then accepted me and then they were like, "Oh, wait sorry. You have to pay for this." And I was like, "Wait, sorry. No, I'm not doing this anymore. That's ridiculous." That's kind of always a predilection for writing and I think that the reason why that is because I grew up basically like on Slashdot and eventually then on Dig and Reddit and all these other things. I've kind of been writing a couple paragraphs a day, basically every day in my life since I was a little kid. I think that's something that's sort of like underappreciated. Documentation is hard but it's like a skill, like any other thing. Programmers will say, "I really want to learn TDD so I'm going to make myself do some TDD, I'm going to practice it, I'm going to focus on it and that's going to be a skill that I'm going to improve," and then they see documentation, and they kind of think it's this thing that you either have the skill or you don't. But writing is just another thing like anything else that you can practice at and get better. I think maybe it's because it's a little bit farther away from the wheel house of what you do day to day, that people aren't as interested in it but it is something you're truly interested in, I think the best way to get better is just to do it and do it a lot. I say this is I'm kind of in the middle of a little bit of writer's block at the moment to be honest. Then finally, I think the other reason that I'm motivated about docs is that I actually believe that documentation is an exercise in empathy. Like good documentation, the ideal as a programmer, the ideal thing that happens in documentation is I have a question about how to use something, I go to the documentation, and it says the exact sentence that answers my exact question. As those varying degrees of vaguely gives you the right idea, versus literally tells you exactly what to do. I think that the way that you can accomplish that excellent documentation is by understanding what your users need and then preemptively figuring it and/or writing that down. I think that that requires being able to put yourself in their shoes to some degree. I'm not going to say that that's a thing that I am perfect at but I think that a valuable skill when trying to improve docs's like figure out what they actually need and then give it to them. It's doesn't always have to be in that order, like sometimes people will fail to find the thing they need, tell you what you need, and then you give it to them. That's a strategy I've used a lot and that's one reason why I hang out in the Rust IRC all the time, helping people is for a very long time, I would like sit in IRC, someone would ask a question, I would answer the question, I'd go look in the docs and see if they could have figured out themselves. If they couldn't, that would be might next doc PR. It's just like even if it's just a couple sentences like add the question from IRC into the documentation and then just do that over and over and over again and then eventually, people start learning from the docs instead of actually ask questions because they already found what they needed. CHARLES: Right. I have a question about that because once you develop those skill, I think you also still run the risk of like burning out. I know that one of the reasons I tend to always fall back to like, "I'm going to spend my time doing coding instead of documentation," Or, "I'm going to spend my time --" Even with TDD is a great example is like with TDD you get to experience those short term wins. I think that kind of prevents you from burning out, where sometimes when I'm writing documentation, it feels like I'm screaming at the void. I might be screaming really loud and really, really well but I feel like a lot of times, I'm not experiencing those wins and I'm wondering if you have any tips for like experiencing those wins. Or getting that feedback to kind of keep you motivated and keep you doing the job. Also, trying to push the level of your own documentation skill and communications skill. STEVE: Yeah, experiencing the wins is definitely a part of it. But one of the other things that is sort of part of it is that like I do the opposite. I do a lot of coding but that's my side projects. When I get fed up with writing documentation, I maintain the [inaudible] implementation that Cargo uses to resolve Rust packages, for example. If I'm feeling a little stuck on docs, I'll go write some software and then come back to the docs so that kind of help with burnout. Another thing is that I think I'm just like perpetually in a state of just barely above burnout anyway so that also sort of factors in I guess. You know, it's like Bruce Banner. The secret is that I'm always angry so -- CHARLES: So you work on open source, is that what you're saying? STEVE: Yeah, exactly. We're working on open source all the time. I've been lucky enough to make open source as my job for, basically almost my entire professional career. Although not totally. You know, at some point, you just kind of get used to it. But in terms of experience and the wins, this is also one of the reasons why I like to teach beginners specifically is that beginners allow you to remember what it's like to be a beginner, which is also part of building the empathy. By interacting with beginners a lot, you also get a lot of those wins because beginners usually ask easy questions so it's easy to figure out the answer that stuff. Then you've got that positive feedback loop kind of going. To me it's maybe not IRC literally for every project but answering questions on Stack Overflow, or whatever message board forum you have, or Twitter, like actually interacting with other people. For me at least, that's how I get that kind of sense of not screaming into the void that you have to like go into the void and find the other people there, I guess, that I'm just like come to you necessarily. CHARLES: Speaking of empathy for beginners, it just occurred to me that we didn't actually talk about what Rust is. We probably should do that. Why don't you tell us a little bit about the Rust, language, as well as, you've mentioned Cargo and [inaudible] ecosystem for us as well? Let's talk about that. STEVE: Yeah, totally. Basically, Rust is a new-ish. I should stop saying new because it's almost not really at this point. A kind of new-ish programming language, heavily sponsored by Mozilla in development. Its idea is to become a new low-level programming language. But I always hesitate when I say this because one of my old pitches for Rust used to be like, "Rust could be used anywhere. You can use C." Then people go, "I would never write, C is so cool. Rust is not for me." I'm like not do that. But the reason that people don't use C is a lot of the problems that we are also trying to fix. I guess the primary differentiator for Rust in terms of like programming languages theory is that it is safe and safety as they got specific meaning. But basically C is a very dangerous sharp tool and you can cut yourself and people who use those tools often do cut themselves, whereas Rust is like it's got a safety guard on it. It's a compiled language so its compiler actively prevents you from making some of the worst mistakes that you can make in a low-level programming language like C. It turns out that when you start building up these sort of safe abstractions on top of these really fundamentally low-level details, you actually end up with a relatively high-level programming language. I talked to a lot of people, for example from JavaScript or Ruby world or Python world who come to Rust that are modulus, some libraries, and other things. This is actually high-level enough that I feel like I could do this instead of review JavaScript all day and I would be just as comfortable. The other day, I did a little bit pair programming and we actually recreated a JavaScript library in Rust that had virtually the same interface because like you can actually build relatively high-level things so pass an enclosure to a function that does some stuff is totally normal and Rust world. That's also very familiar to people that come from the Ruby, JavaScript, Python background. Also then, as part of that is we also culturally like Rust the projects, not Rust the programming language, really, really cares about helping people understand what systems programming and like lower-level programming means. A lot of people will not program and in C or C++ because they have no idea how to get help or to learn because many people in the low-level space have this RTFM attitude or like, "If you don't know what you're doing, then get out of here," whereas in Rust world, if you ask an extremely basic question, we're like, "Welcome. We would love to have you. I would be very happy to like walk you through," like explaining how that works on these kind of low-level details. Part of the culture of Rust is to bring this sort of low-level programming to people that have rejected it before for various reasons. The reason that Mozilla cares and the reason Mozilla sponsored the project is that Firefox is written in C++, so like four million lines of C++ last I checked. Last time we did a security audit of a really pants-on-fire, terrible security bugs in Firefox, I go to this website and now they run arbitrary code on my machine kinds of terrifying bugs. Basically happened because C++ is dangerous and sharp. If you screw up, there's the kind of bad things that can happen. About 50% of those security issues in Firefox would be eliminated at compile time by the Rust compiler. That's a really huge win in general so the idea is that we are slowly rewriting Firefox and Rust over time. That's one angle of why Mozilla cares about Rust. The second part is Servo, which is a rendering engine that's built in Rust from the ground up. If you think about Firefox proper, it's got Gecko as the rendering engine inside that actually determines where things go on the page and stuff. We're also writing a new one of those from scratch called Servo in Rust. That was also to prove that the language was doing the kind of things that we need it to do. But also Servo is an impressive piece of technology in its own right so it might become its own thing and/or bits and pieces of it are already making their way into Firefox. It's kind of also a way to improve our core products. That's why Mozilla cares. CHRIS: I was curious with Servo and Servo is the layout engine. Do you know if there are any plans to write a JavaScript runtime in Rust? STEVE: That question is complicated. Sort of what it boils down to is that a Git is inherently kind of unsafe by Rust definition of unsafety. It's actually controversial like when I talk to people that work on JavaScript engines, they're pretty much 50/50 split between, "Oh, yeah. Totally Let's absolutely rewrite the whole thing in Rust because we rewrite it every two or three years anyway from scratch so why not use Rust next time," to, "Since it's massively unsafe anyway, I don't see what benefit I would actually get so why not just stick with what we know." It's like very extreme ends. It's definitely feasible but I don't know if it's going to happen and/or when exactly. CHARLES: There were two questions that I had kind of to unpack some of the things that you said in there that were just really interesting to me. You said Mozilla plans to incrementally rewrite Firefox in Rust, where it's currently four million lines of C++. Now, how does that actually work where you're talking about swapping out large parts of the runtime with something that's written in a completely separate language? How does that communication happen between those language boundaries? STEVE: There's this concept called an ABI, not API. It may sound very similar -- Application Binary Interface. What this really boils down to is assembly language does not have function calls. That's not a concept, that's in assembly. People have come up with, "If I write a function and I map it to assembly code, what's the convention about how I do things like passing an argument and return values? How those all that stuff actually work?" Because assembly is so low-level, there are multiple different ways that you can make that happen. There's a number of different specifications how to make that work so C, the programming language, has a very straightforward ABI so any programming language that knows how to call C functions, uses these convention at the assembly level to do the function call. What you can do with Rust is you can say, "Please make this Rust function follow the C calling convention," in that way, any sort of thing that knows how to call C functions can call Rust functions directly. By doing that, you can sort of say like take a chunk of code, write it in Rust, expose a C interface, and then anything that knows how to talk to C, which is virtually everything, can talk to Rust equally as well. For example, one of the earliest production uses of Rust was actually inside of a Ruby gem because Ruby can be extended to C and Ruby knows how to have C extensions. It doesn't actually need to know that it's literally written in C. It just needs to know how to generate the assembly to call the correct functions. That's actually like a thing. Basically, the process is like write a component in Rust, expose this language independent wrapper, and then call into it like you would in C code. CHARLES: So it's really, just they're sharing memory and sharing is like right there in the process and there's no overhead for the intercommunication, it sounds like? STEVE: Yeah, exactly. You could also do all the regular things with JSON-RPC over a socket or whatever if you wanted to. The most efficient way is to literally include it as your binary just like anything else. CHARLES: Which kind of leads me into my next question, which is Rubyist and Pythonista people coming from JavaScript, one of the reasons we don't like to write in C is because, as you mentioned, they're so sharp so we have safety so that you don't have to worry about memory allocation for the most part, the garbage collector kind of has your back there. You access things by reference so you never have to worry about accessing memory. That's not there but kind of the conventional wisdom is that that all comes with a pretty big cost. It's like really, really expensive. I know when I was getting into Ruby and I was explaining a lot of the pushback I got from people doing C and even Java, it was like, "It's going to be super slow because all those high-level features that you love so much, you're paying a lot. A lot for them." My understanding is that's not really true with Rust. Is that fair to say? STEVE: Well, Rust does not have a garbage collector so, yes, it does not pay that cost because it doesn't exist. Now, that also raises a bunch of other interesting questions and basically what it boils down to is a compiler and especially one that has a typesystem, basically asks you to declare certain properties of your code like this function takes one argument only and it's always a string. That's sort of what type safety means. It kind of like a fundamental level. One of the ways that Rust uses type safety is to say, "This pointer to this memory always points to valid memory," and you have to be able to demonstrate that to me at compile time. From those couple of sentences, that sounds extremely complicated but it turns out that most programming code is written in a way that actually works this way. For example, like I'd talk to Yehuda Katz a number of times because we're friends, he also works on the Rust project and he's also well-known in JavaScript and to you all, I would assume. It turns out that the style of Rust code I write is actually extremely similar to the style of JavaScript code that I write is just sometimes there are some tweaks. It is true that those features often do take up a lot of memory and/or rely on any sort of expensive, from a low-level perspective, way of doing things. But it turns out that's actually more of a function of the way that the programming language is made in semantics. You could design a programming language that feels very similar but as very different underlying characteristics. For example, Closures in Rust, the compiler is smart enough to know that if you don't actually capture an environment. Say you're going to add one to every number in a list. You want to do like .map, pass in a closure that takes one argument X and adds one to every single X and then collect that up into like the map join kind of thing, to collect into a new array. That closure that you had passed a map, while it's a closure, it's taking that one argument X and doing X + 1, so it's not really capturing an environment at all. There's actually no reason to allocate a bunch of extra memory because it turns out, it's the same thing as a regular function. The compiler is able to optimize that call away completely to the same thing as if it was a normal function and not a closure, and therefore, you're paying no overhead. Even though, like syntactically, it looks kind of like a closure. Then you're kind of think of that applied to almost everything in Rust. For example, Rust has methods but almost all of them are actually statically dispatched at compile time, as supposed to dynamically dispatched, where you need to look through some sort of object hierarchy because we don't really have inheritance. There's no way to say like this might result to a colon, this class or this class is super class, or this class is super class so I have to do this runtime look up to call functions that just doesn't actually really exist. Part of it is through the fact that these coding patterns don't strictly require this stuff. It's just the way those languages are built and part of it is because as we were building a language, we were extremely sensitive to not include features that would require this really heavy overhead. In a language, that's like a low-level of focus on details, it's extremely hard to talk about the details without code. There's a lot of details, it turns out. CHRIS: One thing that I'm very curious about and one of the things that drew me to Rust actually is the fact that its typesystem is, I guess an ML typesystem. It is like much more [inaudible] to something that you would see in a functional programming language like Haskell, than you would like a regular C++ or Java. CHARLES: Now, a Chris-acronym alert. What is an ML-style typesystem? CHRIS: I'm sure Steve can answer this better than I can but it's a typesystem that uses the Hindley-Milner algorithm for type inference. It does a lot of the heavy lifting for you, in terms of correctness. Is that correct? STEVE: Yeah, I would say more accurately, ML is a programming language. It's the name of the language so by saying like an ML-like typesystem, he means like a Java-type typesystem. It's like a similar statement but about a different language. I always forget what ML stands for specifically but like OCaml has got ML at the end so like OCaml is one of the languages that sort of the family of ML. There's like two branches of functional programming, which of course everything is wrong when you try to organize things this way. Like you could also argue Lisp as a third but there's kind of like the Haskell-style and the ML-style are these two big pillars of functional language stuff and Rust tends to be in the ML sort of family. There's lots of common features between families of programming languages and all that kind of stuff. I think the ultimate point that Chris is trying to make is when I say that Rust is a typesystem, I do not mean it's like Java. There is a wide variety of typesystems and they do all sorts of different things and actually Java has been getting increasingly better over the years as well. But it is much more canned to a functional language in the typesystem, which I think is what you were getting at and serves the actual question, right? CHRIS: Yeah. Actually, I just looked it up and ML stands for MetaLanguage. It is actually is going to serve my question really well. ML was originally designed for theorem improving in math, which is part of why it works really well in functional programming languages. But it also makes sense if you use Rust, how the compiler work from the kinds of things that it catches, like a relatively low effort on your part because it is originally designed to completely prove out a theorem so the compiler is doing that to your program. That leads to my question which is I recently heard someone else on the Rust core team talk about one of the things that Rust really seeks to improve upon is concurrency and parallelism, which is historically very hard. To do that, you could use things like mutexes or reference counting, which Rust has. But they also lean extremely heavily on the typesystem itself to sort of guarantee that your concurrent code is actually going to run safely. On one hand, I'm interested in hearing you expound on that but I'm also really curious how the C, C++, Java programmers take to that sort of thing in Rust because as I understand it, that is a pretty novel approach to that kind of problem. I wonder if there's like pushback from the existing low-level systems community on that stuff. STEVE: I'll do the second part first because it's a little simpler. One thing that I will say is we sort of didn't appreciate over time because we were creating Rust for ourselves, roughly the C++ programmers are working on Firefox, which we had to say for ourselves because I was not literally one of those people but you get the idea, is like assuming that C++ people would be the primary audience. But it turns out that a lot of people that programming C or C++ are pretty happy with it and they like doing things that way. They're a lot smaller of a population than the number of programmers who do not program of those languages, which is true for any language, basically. The sum of all other people is bigger than your specific thing. What that means, I think that in retrospect this seems obvious but at the time, it was like hard to figure out or I definitely did not understand this at that time, that most people would come to Rust from not C or C++ than they would from C and C++, just even by virtue of numbers alone. A lot of the people who are not doing it are not doing it for reasons. They've already rejected it for some sort of purpose and the people who are still doing it often are like happy with what's going on. There's definitely a little skeptical at times of the kinds of things that we can accomplish. Also, our success has been pushing C++ specifically to grow a lot of safety things so we hear a lot of people say like, "In five years, C++ is going to have this tooling that's going to make it also pretty safe, even if it's not as safe as Rust. I'll just wait for that instead." Surprise, low-level programmers are extremely conservative bunch in many instances. The first part, which is the bigger and more interesting one, the typesystem is absolutely how concurrency works in Rust. This is extremely powerful for a number of different reasons. The first one, and I think the fundamental reason why it's done this way is that typesystems don't have any runtime overhead. When you're in a performance-heavy language, that's really the key. Originally, a long ago in Rust, we actually had a garbage collector even, like a very long time ago in Rust. The primary goal was always safety and we thought the only way to accomplish that was with lots of runtime checking, heavy runtime, and all these things. Over time, as the typesystem grew, we realized we could use more and more of a typesystem to eliminate more and more of the runtime because types are checked to compile time so they have no overhead cost, which is awesome. Like Rust references, doing this validation that they're always valid is completely a compile time construct that at runtime, they're literally the same thing as C pointers. That's one reason why the typesystem is really heavily useful for concurrency because you want things to be safe. We also don't want to slow them down. The whole point of concurrency in many instances is to get a speed up. If you introduce too many safety checks to make sure that your concurrency stuff works, you lose all the gains that you were trying to get from being concurrent in the first place. Having that like as low-cost as possible is extremely important. The second one is that concurrent problems are extremely difficult to debug because you need to recreate the exact set of circumstances under which the bug happens. If you have a bug because you have two threads that have a particular access pattern on a particular variable and that's where the bug is introduced, good luck coercing your operating system scheduler into scheduling those two threads at exactly the same way as when the bug happens. To some degree of the way that you fix a lot of concurrency bugs is by introducing an extreme amount of logging and then just kind of let it run and praying that you hit into the situation that causes the bug. That really brutal and doesn't really work. By using the typesystem and verifying it upfront, you just know it will work at runtime because you've already proved the concurrency property before your code even runs. It's also just like a better debugging experience, I think in general. The way that we accomplish this task is extremely novel. I guess I should also say extremely novel to working programmers, like almost all Rust is built off of existing research that has been known in academia for a relatively long time. That's actually one of the places where it gets the name from, it's like taking ten-year old ideas that have a little bit of rust on them, that have found usefulness and bringing them to [inaudible] research. Anyway, the way we accomplish this basically is the typesystem in the standard library, the way that you spin up a new thread, it has a particular type signature and the type signature says, "Only allow the types to be sent to this new thread. There are safe to pass between threads," and/or like, "Only allow references between this thread and that thread of types that are safe to use across thread." What that means is that when you try to spin up a thread and you passes a thing that doesn't work, you get a typesystem error. It turns out this is not concurrent safe collection so it does not have the prerequisite types so therefore, you cannot pass on this thread and you're done. That's sort of like at a core level of how these things work. Then for example, mutex is a type that does have that property so by sticking with non-concurrency thing into a mutex, now you can share it safely. That means we've guaranteed that the compile time that you'd safely done this transfer between threads and that kind of thing. It's not just about mutexes but that's sort of the general approach. The last thing I want to say briefly because I just said a whole bunch of things. I'm sure, I've raised a ton of questions here is that the other powerful thing about using the typesystem for concurrency guarantees is that other people can extend it. If you write a library in Rust, your library will be exactly as concurrency safe as the standard library and as the language itself. It's not like we provide the set of concurrent collections and then we vetted our own implementations and then you're kind of your own or building your own stuff. You can use those exact same types to help guarantee properties on your stuff. Also build alternate threading situations, as well that use the same things and the ecosystem all works together so everything is just concurrency safe by default because it's like a property of typesystems that are being built into the runtime or something. CHRIS: I know that recently, there's been a lot of, I guess excitement about this library called Tokio. It's not like there's future that kind of like promises in JavaScript, then there have been abstractions just kind of consistently being built up but it seems like Tokio is the next step and it's building towards a whole stack of higher-level concurrency things. Is what you just said enables that kind of thing to happen? STEVE: Yes. Tokio is using those exact same typesystem features in order to guarantee that when you have a chain of promises, to use the JavaScript terminology instead of future things, that you make sure that they're safe. This is not literally implemented yet but Tokio, for those who are not paid hyper attention to the Rust space because this is a cutting-edge, the library is gearing up for an initial release in the next week or two. Soon after you hear this or maybe right before you hear this, it's just going to be released. It's extremely cutting edge. But in some ways it follows sort of the node model of concurrency. There's event loops, you chained together, we call them futures, you call them promises together, you put that pile a future chain and do an event loop and watch the concurrency kind of go. One example of how Rust can do cool things is you could -- this is not implemented yet but it will be in the future -- run, let's say, five event loops on five different threads. Then you just tell the framework, "Please run this future chain onto one event loop. I don't care which one," and then it will automatically load balance across the five threads and five event loops because you've guaranteed the compile time that everything is safe to pass between threads so we know that that's just trivial to do and therefore it's like not a big deal. We can add those heavy duty features without worrying about introducing very subtle bugs, which is really cool. CHRIS: That kind of leads me to my next question, which is at The Frontside, we are pretty into web development, in case you didn't know. I am someone who follow Rust a lot and I find it very interesting. But for the most part, I don't have a need to do systems programming on a regular basis. I also wouldn't even really know where to start, if I wanted to do systems programming. As I learned Rust, I tend to always gravitate towards wanting to do things that I would probably do in Ruby or Python, like write the back-end for some web app or something. That goes okay but Rust is very much still in the process of building those abstractions to the point that it's relatively digestible. So I have a couple of questions. One is do you see Rust being a thing that would be used by web developers a lot more broadly and two, how would you recommend that people like me who aren't really familiar with systems programming start to really dig into Rust on a deeper level? STEVE: I would like to think that web programmers will use Rust more often and to be honest, originally, I was extremely skeptical of this. But it's been changing rapidly as time has gone on. Part of that is because as we've gained more experience, actually in programming in Rust, the fact is Rust used to be a lot less ergonomic than it is and now it's fairly ergonomic and will only get more so in the future. That's something that web people or at least, I come from Ruby so Rubyist care a lot about ergonomics, maybe more than anything else frankly. I'm not sure it's the first tool that you'll reach for but I do believe that sometimes, it makes a lot of sense. As one example that I will use, there's not a whole lot about this but basically, npm has started using Rust on the server side for powering the registry. They have three services in production now but they were basically like JavaScript as a language we all know what is the best language for doing this. We have a service that needs a little more oomph so maybe let's rewrite that in Rust instead and use it for those kind of things. I think that there's a lot of situations for web developers where they don't realize they have the power to make things faster without just adding on more servers. I think that's kind of like a compelling sort of [inaudible]. Any sort of background job like any sort of job queue thing is like often better written in a faster language but you would not reach for that faster language first because traditionally, those faster languages have been terrible to use. I think we continue to win on the ergonomics and continue to win the libraries that web developers will reach for Rust like more often than not. In terms of the learning rest on a deeper level, I think that one of the initial things and sounds like maybe you personally are a little past that but maybe not the people who listen this podcast is that I do think that sort of building the things that you would normally build in Ruby or JavaScript or Python is the good first step. For example, right now Advent of Code has been like a really fantastic way of having these little programming projects. If you haven't seen AdventOfCode.com, it's like every day in December up until Christmas, there's a new programming project that you can build the thing in. I've been doing those in Rust and that's a lot of fun and it's a good way to practice and gain some basic literacy. But after that moving at a low-level stuff, my personal thing and I know something you've expressed interest in the past is my side project is building an operating system in Rust. More so, than just that the pitch is, "You've written JavaScript before. Let's write an operating system together. Here is this companion book and I'll show you how," and that's called intermezzOS. It's like I'm basically trying to rebuild an operating systems curriculum but in Rust instead from nothing, like we start off with assembly code and move up into Rust code. CHARLES: Now, you can't even use anything like all the things that we've been describing like threads, kernel level callbacks. You get none of that, right? You have to implement it all from scratch. You can't use POSIX or whatever. You know, 90% of your code ends up going through. STEVE: It turns out that and it's sort of like for reasons that hopefully I'll be able to fix in the future, you need about like 200 lines of assembly code before you get into Rust and then you basically don't need to use assembly again, really. It's not that big of a barrier in terms of [inaudible] things and its copy-paste stuff that I explained extremely heavily so it's like totally an accomplished real thing. Then you're in a real programming language and you can do more normal things on top of it. But one thing about that because it is my side project, the kernel is actually farther along than the tutorial is and I actually need to find some time to write more of the freaking tutorial but this is kind of my personal long-term project over the next, let's say, decade and to have a completely free and open source tutorial for you to learn about operating system developments. That's one of the things I've been doing. Another one that I think that is really extremely useful is once you gain some amount of literacy on this, you can actually start to learn more about how your regular programming language works. I've been giving this conference talk recently. It's called 'Exploring Ruby Through Rust', and I'm like, "Once you know this low-level stuff and you gain this literacy, you can look at the source code of your language as interpreter and learn stuff about it and you can contribute to it maybe even." Maybe that's not the most practical thing or whatever but now that I've spent a bunch of time with Rust, I understand Ruby on a far, deeper level than I ever did before because now I'm not afraid to go poke around in the internals and learn how it really works under the hood and I understand what those internals do far better. Maybe five years ago, I could have told you like, "Ruby is garbage collector. It's extremely basic. But I don't really know what that means." And now I can be like, "Ruby has this mark and sweep generational garbage collector. But it's not compacting or concurrent yet but maybe in a year or two. Now, that's not just a bunch of buzzwords because I have this low-level literacy." CHRIS: Yeah, that's definitely something. I forgot about but every time I go learn something in Rust and initially this happens a lot. Every time I do that and I go back to JavaScript or something else, I find that Rust inadvertently taught me something about the language that I actually work on every day. Especially, when it comes to things like references, values, and the difference between them and debugging weird prototype behavior in JavaScript became so much easier after I had spent some time working with Rust and had had to like actually deal with passing around references or dealing with life times or having the compiler yell at me for a lot of things that I thought were totally normal. Then I'm going back to JavaScript, it's like, "Wait a second --" Suddenly a lot of these pieces are starting to fit together and before what was just as weird mystery, now I can totally see what is happening and start to think about how to fix it. Even though I don't even have the same tools that I do with Rust, it still is extremely useful from that perspective. STEVE: That's awesome. I'm glad to hear it. That's how I definitely felt with Ruby for sure. CHARLES: You know, in terms of actually using it for day to day stuff, is there other plans, is the ecosystem already supporting things, say, a web framework? Like a low-level web framework like Sinatra or Express or even higher one like Rails. STEVE: I guess, like you've already qualified it as web stuff. But I would say, in a broader sense, whether or not Rust is ready today for you, it depends entirely on the ecosystem. I feel like 80% is productive in Rust as I did ever in Ruby. But that's only if there's a library that I don't have to rewrite myself because it doesn't exist yet. That number is actually growing rapidly so I just look because it's like the end of the year and our package ecosystem is actually doubles. This is a request from earlier. I didn't expect Cargo so Rust basically has bundler or yarn/npm built into the language itself. We distribute it with Rust and we have all that great package ecosystem shenanigans. Another great example of Rust over a language like C is the tooling. Basically, what happened was Yehuda and I kind of showed up in Rust world and we're like, "Why are you still using make files. We know a better way." And they're like, "Okay." Then he builds the equivalent of bundler for Rust. Then everyone's like, "Oh, yeah. This is way better. We're not using make files anymore." The tooling situation is very familiar to a dynamic programming language person because we literally had the same people write the tools. That also means you can share packages freely and briefly so operating system development thing is totally intense to be able to use your package manager to download packages to help you build an operating system. For example, X86 has custom assembly instructions that you need to use when interacting with the hardware and someone has already built a package on [inaudible] that wraps the inline assembly up in a nice to use Rust functions. I can just include that package and use it when building my operating system, which is totally mind-blowing. The npm is sort of feel into OS development is just real intense and cool. Back to the ecosystem thing, though. For web application specifically, it's good and also bad. There's actually multiple different web frameworks already at different levels of comparison. For example, you have Nickle which is kind of like Sinatra and you have Pencil, which is kind of like Flask and Python, which is also kind of like Sinatra. Then you have Iron, which is kind of like expressed in JavaScript. There's also like I know of at least two. One of is has been worked on but it's not been actually released. But the code is at least open source yet. I know a second that is being developed fully in private that has not had any public release yet. Then when the Tokio stuff comes out, People are going to be building new frameworks on top of the new async shenanigans and/or porting the async stuff into the existing frameworks. We kind of have a lot of options but there's also a lot of churn and activity and stuff going on in that space so that either terrifies you or makes you enthusiastic. They're basically is like that. We definitely don't have a Rails yet. I don't think that's because a Rails will never exist but because it's a much bigger project to build a Rails than to build a Sinatra. CHARLES: Yeah, and you just need those foundational pieces there in place before you really want to attempt that. STEVE: And I think Tokio is the real foundational piece and it's just taken us a long time to put it all together. The initial tests in Tokio, we could do a 'Hello, World' benchmark like the tech and power benchmark. Some of you are already familiar with those things, or not, they're like 'Hello, World' benchmark. We actually got faster than they are fat than all of them. It just edged out the fastest Java, which is currently the reigning benchmark on it. That's like extremely compelling. Even if after all this stuff is built on top of it but it's taken us a while to build those foundations and we're just getting that point like Tokio is going to have a release, hopefully before Christmas. I've been assured by the end of the year and then people are going to build stuff on top of it and it's just going to explode from there. Here's another little interesting pitch. I'll give you for this, is that one of the things I like about Rust on early ecosystem is it means that if you want to be that person who built the library that does X that everyone uses, there's lots of opportunity in Rust world right now. Where there's a lot of foundational libraries that you could be the person who wrote that thing when everyone knows and loves and uses. Like JavaScript is still kind of there. In Ruby, every library basically exists already so there's no more room to build a foundational thing. But if you're someone who likes working on open source and that story is compelling to you like getting involved in a younger ecosystem, it means that you can have a much larger impact. I maintained the [inaudible] library that things used. The only reason that's true is because I was around before we had one and then Yehuda wrote the initial version and now, I'm maintaining it. There's tons of space out there so if writing a web framework is the thing that's interesting to you, Rust is a great place to explore and actually doing that at the moment. CHARLES: Steve, one of the things that I know you do is you actually write the Rust Book. I heard that you're also in the process of rewriting it along with Carol Goulding, I believe. I was wondering if you could tell us a little bit about that. STEVE: As part of this Steve getting the job right in the docs on Rust thing, I kind of working on lots of stuff so up to Rust 1.0, we knew we needed to have some long form explain all the things that Rust so that became what's called the Rust programming language which I named so because the C programming language and the C++ programming language, the names of the foundational books for those languages so I wanted to continue kind of in that tradition. But there is some problems with that which is I'll say that I'm a little harder on my own work than I think other people are so I hear people tell me all the time that they love the Rust Book and that it's like one of the best programming books that have ever written. But I think it's not that great. The reason why is also because I just know that the way in which I wrote it. You have to remember that Rust 1.0 happened in May of 2015. We were working on language for six or eight years before 1.0 happened so there was lots of changes, language is changing on a daily basis. Now, it's super stable like super, super, super stable. But what that also means is in some like deeper philosophical sense, nobody had had experience programming in what really was Rust yet because we were still like finishing building it's so like how do you write a book on a language that like the precursor language is what you're using and you're trying to see like what is it going to actually end up being like at 1.0. Because it's not like we can just say, "It's done. Now, go write a book, Steve and then we'll release it at that time." The circumstances in which I wrote the original book were I had a very intense deadline of this has to be done by the 15th of May. While the language was coming together, it takes a couple months to put together a book so I had to make sure that the stuff I was starting I would need to go back and re-fix. That also means that I was like much more vague in some places where pieces were still falling into place and you're like, "This is definitely going to be the same. But this might change so I'm going to leave that part off," and then I just have to plow through because the deadline. All those things coming together means that I kind of put together this book that while good and I'm proud of the work that I did, I can do much better. At this point in time, we now have a full year and a half after Rust 1.0 has come out. I know the struggles that people have when learning Rust. I know the ways in which they succeed or fail and I've talked to a lot of people so I'm sort of rewriting the book now, bringing that knowledge and understanding in as well as the fact that the language just been around for a minute so it's much easier. As part of that, I brought on Carol. She goes by Carol Nichols or Goulding. She both has her maiden name and her married name. She's been one of my best friends for a very long time so I'm extremely happy that she's my co-author on this book. The two of us together and working on doing the rewrite, I think that it is possibly the best thing I've ever done or worked on as far as books go, like I'm extremely happy with it and you can read it online right now, if you want to and see if I'm right or wrong about that. But I think it's a far better book than the original book was. It's actually going to publish at No Starch as well. We're donating all the proceeds to charities since we're being paid to actually write the book in the first place, like [inaudible]. It's going to be a much, much easier and better way to learn the language, I think as well. CHARLES: If we want to check that out, where can we find the new version? STEVE: I'll give you a link to put in show notes or whatever as well. But it's Rust-Lang.GitHub.io/book. There's also just like a book repo in the Rust Lang organization on GitHub. All things in Rust is being developed fully in the open so you can read the drafts and see what's been done where. We're getting towards the end, slowly but surely so I'm hoping that's going to be done relatively soon. CHRIS: Well, I'm looking forward to it. CHARLES: Fantastic. Sounds like the documentation is there. It's excellent. The community is there. It's excellent and from what I'm hearing like the kind of the tower of the ecosystem is really being built up. It's not as high as a bunch of other places but it's definitely high enough to jump in and get your feet wet. If you're you know coming from almost any walk of programming. STEVE: It's a lot of work but we seem to be doing good. CHARLES: All right. Well, thanks for stopping in and talking about this with us, Steve. STEVE: Thanks so much for having me. It's been a lot of fun. CHARLES: Yeah, and now Chris, we do need to kind of figure out what is going to be our Rust project here at The Frontside. CHRIS: I'm up for that challenge. CHARLES: Yeah, that'll be some Christmas homework. All right-y. Take care everybody and thanks, as always, for listening. We'll see you next week.

00:45 - Introducing the Wood brothers and their work Upgrade Rails Hint.io Ben’s Twitter Joshua’s Twitter 3:05 - Upgrading Rails without breaking it 6:25 - Working with clients with technical debt 12:20 - Frequently seen projects and clients 14:45 - Upgrading clients from older versions of Rails 22:50 - Why do clients push off upgrading? 28:10 - How do you know when it’s time to upgrade? 34:35 - Finding the right clients Website Ruby Weekly 37:50 - Avoiding technical debt Rails Xss gem Bundler 40:30 - Upgrading Rails yourself http://guides.rubyonrails.org/ contact@hint.io Picks: Suture Gem (Ben) Debride Gem (Ben) JRuby Truffle Project by Oracle (Josh) ThinkPads (Josh) Honeybadger IO (Josh) “A Rubyist’s Guide to Big-O Notation” blog post (Josh) Eat That Frog!: 21 Great Ways to Stop Procrastinating and Get More Done in Less Time by Brian Tracey (Brian) Codefights (Brian) Basics of Mechanical Engineering by Paul D. Ronney (Jason) The Demon-haunted World by Carl Sagan (Jason)

00:45 - Introducing the Wood brothers and their work Upgrade Rails Hint.io Ben’s Twitter Joshua’s Twitter 3:05 - Upgrading Rails without breaking it 6:25 - Working with clients with technical debt 12:20 - Frequently seen projects and clients 14:45 - Upgrading clients from older versions of Rails 22:50 - Why do clients push off upgrading? 28:10 - How do you know when it’s time to upgrade? 34:35 - Finding the right clients Website Ruby Weekly 37:50 - Avoiding technical debt Rails Xss gem Bundler 40:30 - Upgrading Rails yourself http://guides.rubyonrails.org/ contact@hint.io Picks: Suture Gem (Ben) Debride Gem (Ben) JRuby Truffle Project by Oracle (Josh) ThinkPads (Josh) Honeybadger IO (Josh) “A Rubyist’s Guide to Big-O Notation” blog post (Josh) Eat That Frog!: 21 Great Ways to Stop Procrastinating and Get More Done in Less Time by Brian Tracey (Brian) Codefights (Brian) Basics of Mechanical Engineering by Paul D. Ronney (Jason) The Demon-haunted World by Carl Sagan (Jason)