Podcasts about rubymine

OpenAI has pulled a fast one, and everyone is eating it up.

Brian Douglas is the CEO of OpenSauced which helps enterprises discover the best engineers in Open Source. Victoria and Will talk to Brian about meeting as many developers as possible, setting goals, and keeping himself accountable, and what makes a successful open source project. OpenSauced (https://opensauced.pizza/) Follow OpenSauced on Twitter (https://twitter.com/saucedopen), GitHub (https://github.com/open-sauced), Instagram (https://www.instagram.com/opensauced/), YouTube (https://www.youtube.com/opensauced), Discord (https://discord.com/invite/U2peSNf23P), and Dev.to (https://dev.to/opensauced). Follow Brian Douglas on LinkedIn (https://www.linkedin.com/in/brianldouglas/), Twitter (https://twitter.com/bdougieYO), or visit his website (https://b.dougie.dev/). Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! Transcript: VICTORIA: Hey there. It's your host Victoria. And I'm here today with Dawn Delatte and Jordyn Bonds from our Ignite team. We are thrilled to announce the summer 2023 session of our new incubator program. If you have a business idea that involves a web or mobile app, we encourage you to apply for our 8-week program. We'll help you validate the market opportunity, experiment with messaging and product ideas, and move forward with confidence towards an MVP. Learn more and apply at tbot.io/incubator. Dawn and Jordyn, thank you for joining and sharing the news with me today. JORDYN: Thanks for having us. DAWN: Yeah, glad to be here. VICTORIA: So, tell me a little bit more about the incubator program. This will be your second session, right? JORDYN: Indeed. We are just now wrapping up the first session. We had a really great 8 weeks, and we're excited to do it again. VICTORIA: Wonderful. And I think we're going to have the person from your program on a Giant Robots episode soon. JORDYN: Wonderful. VICTORIA: Maybe you can give us a little preview. What were some of your main takeaways from this first round? JORDYN: You know, as ever with early-stage work, it's about identifying your best early adopter market and user persona, and then learning as much as you possibly can about them to inform a roadmap to a product. VICTORIA: What made you decide to start this incubator program this year with thoughtbot? DAWN: We had been doing work with early-stage products and founders, as well as some innovation leads or research and development leads in existing organizations. We had been applying a lot of these processes, like the customer discovery process, Product Design Sprint process to validate new product ideas. And we've been doing that for a really long time. And we've also been noodling on this idea of exploring how we might offer value even sooner to clients that are maybe pre-software product idea. Like many of the initiatives at thoughtbot, it was a little bit experimental for us. We decided to sort of dig into better understanding that market, and seeing how the expertise that we had could be applied in the earlier stage. It's also been a great opportunity for our team to learn and grow. We had Jordyn join our team as Director of Product Strategy. Their experience with having worked at startups and being an early-stage startup founder has been so wonderful for our team to engage with and learn from. And we've been able to offer that value to clients as well. VICTORIA: I love that. So it's for people who have identified a problem, and they think they can come up with a software solution. But they're not quite at the point of being ready to actually build something yet. Is that right? DAWN: Yeah. We've always championed the idea of doing your due diligence around validating the right thing to build. And so that's been a part of the process at thoughtbot for a really long time. But it's always been sort of in the context of building your MVP. So this is going slightly earlier with that idea and saying, what's the next right step for this business? It's really about understanding if there is a market and product opportunity, and then moving into exploring what that opportunity looks like. And then validating that and doing that through user research, and talking to customers, and applying early product and business strategy thinking to the process. VICTORIA: Great. So that probably sets you up for really building the right thing, keeping your overall investment costs lower because you're not wasting time building the wrong thing. And setting you up for that due diligence when you go to investors to say, here's how well I vetted out my idea. Here's the rigor that I applied to building the MVP. JORDYN: Exactly. It's not just about convincing external stakeholders, so that's a key part. You know, maybe it's investors, maybe it's new team members you're looking to hire after the program. It could be anyone. But it's also about convincing yourself. Really, walking down the path of pursuing a startup is not a small undertaking. And we just want to make sure folks are starting with their best foot forward. You know, like Dawn said, let's build the right thing. Let's figure out what that thing is, and then we can think about how to build it right. That's a little quote from a book I really enjoy, by the way. I cannot take credit for that. [laughs] There's this really great book about early-stage validation called The Right It by Alberto Savoia. He was an engineer at Google, started a couple of startups himself, failed in some ways, failed to validate a market opportunity before marching off into building something. And the pain of that caused him to write this book about how to quickly and cheaply validate some market opportunity, market assumptions you might have when you're first starting out. The way he frames that is let's figure out if it's the right it before we build it right. And I just love that book, and I love that framing. You know, if you don't have a market for what you're building, or if they don't understand that they have the pain point you're solving for, it doesn't matter what you build. You got to do that first. And that's really what the focus of this incubator program is. It's that phase of work. Is there a there there? Is there something worth the hard, arduous path of building some software? Is there something there worth walking that path for before you start walking it? VICTORIA: Right. I love that. Well, thank you both so much for coming on and sharing a little bit more about the program. I'm super excited to see what comes out of the first round, and then who gets selected for the second round. So I'm happy to help promote. Any other final takeaways for our listeners today? DAWN: If this sounds intriguing to you, maybe you're at the stage where you're thinking about this process, I definitely encourage people to follow along. We're trying to share as much as we can about this process and this journey for us and our founders. So you can follow along on our blog, on LinkedIn. We're doing a LinkedIn live weekly with the founder in the program. We'll continue to do that with the next founders. And we're really trying to build a community and extend the community, you know, that thoughtbot has built with early-stage founders, so please join us. We'd love to have you. VICTORIA: Wonderful. That's amazing. Thank you both so much. INTRO MUSIC: VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. WILL: And I'm your host, Will WILL. And with us today is Brian Douglas, CEO of OpenSauced, helping enterprises discover best engineers in open source. Brian, thank you for joining us today. BRIAN: My pleasure. Thanks for inviting me on the podcast. VICTORIA: Just tell us a little bit more about OpenSauced. BRIAN: Yeah, it's opensauced.pizza is the URL. So I always point that out because it's easy to found. WILL: I love it. BRIAN: And OpenSauced is a platform for engineers to find their next contributions and enterprises to discover the best engineers doing open-source, so... VICTORIA: Right. So maybe tell me what led you to start this company? BRIAN: Yeah, that's a great question. Actually, if you don't mind, I'll start further back. I graduated college in 2008 during the financial crisis with a finance degree. And what I learned pretty quickly is, like, if you don't know anybody in finance, it's a little hard to get a job in a bad market. So I took a sales role instead, mainly because I just wanted to learn. I was very much introverted. I wanted to learn how to talk to people, and have conversation, and communicate. So I did that four years and then got my MBA. And then started learning how to code while building an app, which is...I mentioned before we hit record I learned about this podcast around that time, which is, like, very serendipitous to be on this podcast years later. But, fast forward, OpenSauced, like, because of the whole networking aspect of how I got my job in sales and how I was able to do sales when I learned how to engineer, I knew the connection to open source, or how I learned how to code was, like, a wealth of information. So I made it my career goal to meet as many developers as possible. And then, I was working at this company called Netlify. I was employee number three there. And my role was to basically be a front-end engineer, but where I was actually getting more adoption to the product by doing open source. Like, every time I'd do an open-source contribution, I'd add a Netlify deploy preview manually in my PR. And that would give the maintainer enough juice to review the PR sooner. And I was doing a lot of open-source contribution at the time. So I wanted to build a tool to maintain, like, all the PRs I had opened in-flight that I needed to respond back to or...because back in, like, 2016, notifications on GitHub they weren't the greatest. WILL: [laughs] BRIAN: So I built a tool just to keep up to date on what I had opened and how I can communicate back with the maintainer. And saw a need...actually, I didn't see the need. I used this thing myself, and then in 2020, I started live streaming myself, building more features on top of this, like, CRM tool, and had a few people ask, "Hey, can you add a login to this? I'd love to use this, too, with my own database and stuff like that." So I did that. I added login. And I say database, like, we actually originally started with no database. We used GitHub Issues as a tracking mechanism for tracking repos and conversations. We've since moved away from that because, now, obviously, GitHub's got way more advanced in how notifications work. But the sort of ethos of the project still lives today, and what we have in the open-source platform. So that's, like, the long tale of how we got to where we are today. And then, I spoke at GitHub Universe on OpenSauced back in 2017. And from that talk, I had GitHub employees reach out to me and ask me to work at GitHub. So I accepted, and I worked at GitHub for almost five years, sort of putting OpenSauced to the side up until last year, decided to go ahead and pursue it again. And at that point, decided to make it a company. VICTORIA: What a cool story. There are so many things in there that I want to follow up on. I'm sure, Will, you also are like -- [laughs] WILL: [laughs] Yes. VICTORIA: I have so many questions. [laughs] WILL: Wow, that's amazing just hearing the story from you [laughs] got a four-year degree in finance, 2008 happened, no job, very hard to get a job because of who you know. And then you go and changed directions to start learning to code. And I love how it's kind of guided your path to where you are here right now. Like, who knows? But would you have been the CEO of OpenSauced if 2008 would have never happened? So it's amazing to see it. So, I guess, because I love the idea of OpenSauced...because I am that developer that wants to get into open source, but it is hard. It is hard to find the issues that you can work on. It's hard to get into the community to do that. So, if you can just explain to me a little bit more as from there, and we can do it from the enterprise portion later. But, as far as a user: a developer, what does it look like for me to use OpenSauced as a developer? BRIAN: Yeah, yeah. And that's a great question, too, as well. It's funny how serendipitous the story is today, but when I was living it, it was like, oh, man, I'm never going to get a job. [laughter] Or I'm never going to learn how to code. And I think anybody listening who might be where I was ten years ago, I just want to preface, like, your story is like a guided path through experiences. And every experience is like an opportunity for that sort of one piece of, like, the sort of stepping stone to move on to, like, CEO of whatever your next startup is or senior engineer, or staff engineer, whatever it is. But, to answer your question, Will, we built a Discord, and the Discord itself is how we sort of discovered this sort of onboard ramp into open source. So today, if you sign up to OpenSauced, again, opensauced.pizza, you connect to your GitHub account, and you get on-boarded into a flow to ask a couple questions. So, like, what languages are you interested in? And then, what time zone are you in? And the reason for those two things is, one because we're going to do recommendations for projects pretty soon. Everything is open source, so you can literally see the issues that are open about recommendations; happy to take contributions and feedback on it. And then time zone is because communication is pretty key. So, like, if someone is not awake when I see their PR, I have an expectation of, like, cool, I'll write a response, and I'll wait for them to wake up and respond back to that. So the goal there is there's a lot of projects on GitHub, like, 372 million repos is the number off the top of my head. They literally announce this stuff, and they share the data. But of those repos, only 225,000 have more than five contributors. Understanding what you're looking to accomplish first out of doing open source to either share knowledge, or gain knowledge, to get exposure, to get a job, or just to enhance your current job by go try something that's not in the roadmap of what you're working on. Eventually, we'll start asking those questions around, like, what type of contributor that you want to be, so we can start recommending those types of projects. But I mentioned that 225,000 repo number because there are a lot of projects that don't have five contributors that could use their second contributor, or third, fourth. And my recommendation is always find up-and-coming, like, growth-stage projects. A lot of people want to contribute to React. You had mentioned you did React, Will. That's a really big lift to go contribute upstream to a project maintained and supported by millions of enterprises around the world. But there are tons of projects that go trending every week that have no documentation, that have no README, that have no structure and are just getting off the ground. Like, those are the best projects that we try to showcase. So, like, that's hot.opensauced.pizza is our sort of up-and-coming project list. And the way that works is like projects that are trending based on our open-source community; we surface those there. There's a lot of work we have to do on that project. That was, like, a Hack Week project we did a couple of years ago as a community. But the basis of that is they're looking to build our recommendation engine off that. So, step one is find a project that is welcoming, that needs some work done, and then find the path in. So the path usually is going to be your CONTRIBUTING.md, which is like established projects will have this. But if you don't find a CONTRIBUTING.md, but you find a project you want to use, chances are you could build that CONTRIBUTING.md and ask the question, so, like, hey, how would I contribute? Like, how can I be supportive? Actually, I did this talk a couple of years ago at Juneteenth Conf. It was a remote conference on Juneteenth, which a bunch of Black Engineers we all gave our technical expertise sponsored by Microsoft. And I was talking about the idea of open-source hospitality. The best thing you could do is be that sort of hospitable person, either you're a maintainer or a first-time contributor. Like, be that person to set it up for the next person behind you. And the idea of hospitality, you go to a hotel. Like, you know where the towels are. Like, you know where the soaps are. Like, you know exactly where everything is all the time. And, in open source, like, if we could set up our projects in a very similar fashion, like, not franchise them in a way like the Hilton or Marriott, but set the expectation that there is a way to source information and to interact and operate, so... VICTORIA: Yeah, I mean, I love, [laughs] like, hot.opensauced.pizza. That's hilarious. And I love how you have used humor to...even though it's a very serious product, we're making it more friendly and more hospitable like you're saying. And I like how you said, you know, the journey is cool looking back on it, but it was really hard to go through it. And now you're this wonderful speaker and a CEO. But you said that you weren't actually good at talking to people at first. And you specifically sought to get better at that skill. So I wonder if you would share more about that, how that's impacted your career, and why that's important as a developer to have those communication skills. BRIAN: Yeah, it's like...I have a twin brother since birth, basically. And my twin brother is very extroverted. Like, he actually used to wait tables in college. It was like he was the person that would make you feel very special as a server. Like, he's the type of person that kind of lights up the room when you walk in. His name is Brock. My entire life growing up, I was always Brock's brother. And it's like, oh, you're Brock's brother. And it's like, yeah, I'm Brock's brother. And I'm more of a person, like, if you meet me in person, like, I'm very much reserved. I'm sort of reading the room, waiting for my point to jump in. And I made it a point for me to, like, have enough comfort to speak on a podcast or speak at a conference because I knew that skill set would be valuable. Because I definitely had, in my sales career, definitely got overlooked for a lot of opportunity because folks thought, oh, I don't think Brian could do it. So coming into tech and seeing that when every time I went to a meet up...because meetups also are places where I cut my teeth and got to learn about the industry and the community. They always needed someone to speak. So I was, like, oh, there's an opportunity. I can leverage this opportunity of them always looking for speakers and me always wanting to share knowledge and learn something new to do talks. So my first-ever conference talk was in San Francisco. And I had learned React Native, but prior to React Native, I had learned Objective-C. And then, in between Objective-C and React Native, I learned Swift because React Native and Swift came out the same year. Well, React Native went public, open source, the same year as Swift. So it was like a really interesting year back in; I think it was 2017 where...actually, it might have been 2016. But, anyway, everything came out at the same time. And I was learning iOS development. So I made it a point for me to give a talk. But my pet peeve for giving talks is, a lot of times, people just go directly into the code, and there's, like, no connection to a story, or why do I care about this? So I always bring storytelling into my conversations and talks. So, like, that talk about Swift, and Objective-C, and React Native, I made the comparison of, like...it was the same year that Kanye West took the mic from Taylor Swift at the VMAs or whatever the award show was. And the correlation was React Native took the mic away from Swift because it built similar interactions for JavaScript developers to understand and build iOS applications that was not like Ionic or RubyMine or...I forgot the Ruby one. But, anyway, what I'm getting at is, I just wanted to bring story to this because usually what happens is like, you see cool things, but you never remember what the name is. You try to find that REPL again, or you try to figure out who that speaker is. And it's usually hard to find it after the fact. So, like, my goal was always to make it memorable, which is why I go by Bdougie because Bdougie is easier to Google than Brian Douglas. Shout out to Brian Douglas, who's based in Ireland who does system engineering, and has a great YouTube channel. Like, I want to be memorable. And I want to make it easy for folks to find me after. So, while at GitHub, when I was developing all this sort of like Kanye West-type speaking and stuff like that, well, literally, I would use Kanye West years ago as the example to understand storytelling. I no longer use Kanye West. I'm now a Beyoncé advocate. [laughter] So I use Beyoncé instead. But I guess what I'm getting at is, like, I just had a goal. And I knew if I could teach myself to code...and it was about 17 weeks it took me from zero to ship a Ruby on Rails app. And I felt confident enough to talk about it. I knew basically anything I could just accomplish just by putting some effort and consistency behind it. So that's the...sorry, that was a little more long-winded than expected. But I just keep accountable and set goals for myself and try to achieve enough to feel proud about at the end of the year. WILL: Yeah. It's so funny because I recently had a similar situation. At thoughtbot, we try to engage with the community, and one of the ways was writing a blog post. I've never been a writer. It just hasn't been my thing. But I was telling my boss, I was like, I'm going to do that to get outside my comfort zone and to really stretch myself. And at the same time, I was like, why a blog post? Like, I don't know, it doesn't really make sense why a blog post. Well, when I started writing the blog post, I was like, oh, you have to really know, one, what you're talking about in order to write about it. And so I had to really do some research, really had to study it. And I finished it last week. And then, now, looking back over the last couple of months it took me to write that blog post, I'm like, wow, I feel stretched. But I feel really good, and I feel really good about the topic that I did. So that's interesting that you went through that process to stretch yourself and to grow and even learning to code and get to that point. So talking about...you were at Netlify, and then you worked at GitHub. And then you're at your current one OpenSauced. How have Netlify and GitHub, the work that you did there, how has it prepared you for your position right now? BRIAN: You know, actually, that's a great question. I don't know how much thought I put into that. Like, Netlify prepared me because it gave me an opportunity. So I was employee number three, but I had a sales background. And so I got to be an engineer, but they kept always trying to ask me like, you know, business questions and strategy. And, like, I pitched them a 30-60-90 in my interview of, like, what's the growth strategy of Netlify, like day zero when I start? And I go into way more detail in other content. But that prepared me because I got to see how startups work, being so early. I got to see that startup go from seed-funded, just closed their seed round to get their series B is when I left. At GitHub, I got to see what it looked like at a bigger company, which, like, it doesn't matter how big or small you are, like, there's always chaos. Like, GitHub was, like, so much chaos, and there was a lot of good that was happening but a lot of uncertainty at the time I joined in 2018. And then, nine months later, Microsoft acquired GitHub. So then I got to learn stability and what it looks like to...for personal reasons, I always had a budget but never had extra money, even years into my engineering career. And that taught me what it looks like when success meets career. With that being said, like, the problem that I'm solving, I got to learn firsthand while being at Netlify and getting adoption and traction through open source. And then going to GitHub and seeing every single other company that looked at GitHub as a solution to their open-source collaborations and interactions. And then also seeing that there was a hole in just understanding, like, how do you survive? How do you sustain yourself as your career but also your open-source project? Like, a lot of folks want to know, like, what success looks like for open source. Like, how do you get on the trending algorithm? Like, how do you get noticed? It's more than just pushing to GitHub and hoping for the best. There are, like, other things that happen for projects to be successful. And for us to choose the next in the future technologies, it really comes down to community, marketing, and then resources. And those three things end up making projects successful. With OpenSauced, we're working to help inflate some storytelling and add some of those resources to open-source projects. VICTORIA: Great. So you were able to really get, like, the full vision of what it could be if you had a product that became successful and stable, and you knew you wanted to build it on open source. So I love that you really just...you had this problem, and that's what you built the product around. And that ended up becoming the business. What was surprising for you in those early discovery phases with OpenSauced when you were first thinking of building it? BRIAN: I guess what's really surprising is we're not, like, crazy traction today. But we've done a pretty good job of getting, like, 2,000 developers to sign up to it since December. And then the conversations with enterprises so far just by the sheer...like, basically, what was surprising is if you use proper sales technique and you're early stage as a startup, so, like, not necessarily hire salespeople, but as a founder or as a stakeholder, just go talk to your future customers and your users. Everyone says it, but that's actually super valuable. And I think in the same vein of open source, folks they see projects die on the vine, but then you see projects succeed. And I think it also comes down to how often the maintainer of the project is talking to the contributors and the users and also that distinction as well. There are folks who want to contribute code to the codebase, but then there are folks who want to use the codebase. And, like, how do you interact between the two? And how do you cross the chasm for those folks as well? And, a lot of times, it's just fascinating just, like, just by trying, and just by showing up, that's half. It's all cliché stuff, like, I could say, but it's all true. Like, showing up is, like, it's, like, step one. Just show up, do the thing, do the work. And then talk to people is, like, step two. And it's hard to say, like, okay, yeah, because we are not a multibillion-dollar company, like, we're just getting started. So I can't say, like, yeah, we're super successful. But we've survived the year. And we've survived the year based on those two steps, the showing up and then talking to people. Because a lot of times, we could get lost in the sauce, per se, of just shipping code and never talking to anybody and never coming up for air. And I think what I learned, going back to what I learned from GitHub and Netlify, is talking to people and getting that feedback loop going is the best thing you could do for any product. Any early project, any feature you're working on, talk to people about it and see if it's actually valuable for somebody that after you ship it, something will happen. WILL: You're talking about communication is a big thing for a successful project. Have you noticed any other trends that make a successful open-source project? BRIAN: Yeah, that's...Any other trends? Yeah. I mean, AI, [laughs] just kidding. WILL: [laughs] BRIAN: No, I mean, but it also it is true, like, having a trend not sort of following the herd, but catching the herd earlier is extremely valuable. Like, at Netlify, we caught the trend of React. So, basically, Netlify built essentially GitHub Pages but a product and a company. And that was, like, the original project of Netlify. It's expanded so much further from that. But at that time, when I joined, I joined three months before Create React App was developed. So, like, it was a CLI tool to build React apps easy. And, prior to that, React was, like, super complicated to get up and running. Like, you had to know Webpack. You had to know, Babel. You had to make all that glue happen together. And then there wasn't an easy process to go host it somewhere. So the prevalence of build tools like Grunt, and Gulp, and Browserify, they all made it easier to build a static output from React. And that trend is what took Netlify to where it is today. It's like, people needed a place to deploy these static applications. GitHub Pages was like the solution for a lot of folks. Because Heroku, like, why pay $7 for something you could host on S3 for free? But the challenge was S3 it requires way more thought in how you host and take it down and deploy, and then it becomes like a Kubernetes nightmare. So the trend there was, like, people just wanted to have a better developer experience. When it comes to, like, open source, the developer experience in JavaScript has improved so much more. But folks are now looking at the next thing like a Zig, or a Rust, or all these other new languages and server renderings and stuff like that. So I guess when I take a step back, when I look at how I chose things I wanted to work on, and communities I wanted to hang out in...before committing to React...I'm based out here in Oakland, so San Francisco, basically. By seeing the sheer number of RSVPs to the React meetup, it made me confident that React would be something I should pay attention to. When you look at the RSVPs of now all these AI meetups that are happening in San Francisco, like, every single weekend is a hackathon. Highly confident that if you're engineering today, you probably want to know what embeddings are and know how OpenAI works. Not that you necessarily have to build AI stuff, but it is going to be the thing that people are going to be using. So just like we had to learn build tools, and servers, and CDNs prior, now it's all trivial stuff that you can sort of use Cloudflare for free. Like, AI is going to be very similar, and it's probably going to happen much quicker. But, in the time being, the trend right now is, like, you should probably understand whatever the players are in that space so that way you're able to talk confidently about it. WILL: That's really good advice, yep. VICTORIA: Absolutely. And, you know, in my role as Managing Director of Mission Control, or, like, DevOps, SRE platform, I spend a lot of time looking at trends, more on the engineering side. So I think my question is, [laughs] as someone who hires people to work on open-source projects, and who actively maintains and contributes to open-source projects, what should I be thinking about how to use OpenSauced as in my role? BRIAN: For hiring and sourcing skilled folks, we're actually working on a tool right now to make it more discoverable. So, today, when you onboard as an individual developer, you can check a box in your settings to say, like, if you want to collaborate with other folks, you have to opt into it. So if you want to be discovered on OpenSauced, it's in the settings. We'll probably expose that and share more about that in the future, like, in the next month or so. But for, in particular, our user flow today for folks looking to find other people to contribute alongside their project is, you add your project to what we call an Insight Page. You click on the tab on the top and create a page with your project. And then, you can see contributions in your project in the last 30 days. And then you can also add other projects like your project, so you can see who else is contributing. So, that way, you can start discovering folks who are making contributions consistently and start to get some stories of, like, if they're interested in collaborating, they'll check that box; if they're not, the box won't be checked. But at least you know the sort of scope of the ecosystem. As an individual developer, we have the onboarding flow, but then we also have highlights. So, eventually, we'll do recommendations to get you to make contributions. But, for now, if you're already making contributions, you can highlight the contributions you've made so that way, you're more discoverable on the platform. And the highlights are very much like a LinkedIn post or a tweet. You just drop in a PR, and then we'll either generate that description for you, or you write a description: I did a thing. This is what it was. This was the experience. And then, now you're attached to the project through not just a code contribution but also a discovery mechanism, which is a highlight. And then, eventually, we'll start doing blog posts, and guides, and stuff like that, as they're written. Like, if you want to attribute your career, and your journey to your participation to, like, documentation updates and stuff like that, those will also be highlights coming soon. WILL: I love, love, love that. MID-ROLL AD: Now that you have funding, it's time to design, build and ship the most impactful MVP that wows customers now and can scale in the future. thoughtbot Lift Off brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success. As your trusted, experienced technical partner, we'll help launch your new product and guide you into a future-forward business that takes advantage of today's new technologies and agile best practices. Make the right decisions for tomorrow, today. Get in touch at: thoughtbot.com/liftoff WILL: I hear you saying that you have some things that's coming soon. In a high, high level, what are some of the things that you have coming? And what does success look like, six months, a year? What does that look like? Because it sounds like you have some really good ideas that you're working on. BRIAN: Yeah, yeah. So, like, six months to the end of the year, what we want to do is actually start getting more deeper insights to what's happening in open source. What we're doing right now is building the individual developer profile and experience so that way, they're able to be discovered, find projects to work on. And then what's next is there are tons of enterprises and companies that are maintaining open-source projects, SDKs. And what we're seeing right now is we're seeing massive layoffs happening currently in the industry. So like, as of today, I think Facebook laid off 4,000 people, ESPN laid off, like, 7,000 Disney employees as well. And some of those employees are around the Disney+ place. It's a lot of technical engineering stuff. So I guess what I'm getting at is there...we want to be able to see the trends of places that activity is happening and start recommending people to that. But also, we want to give an opportunity for folks who...companies...sorry, I'm avoiding trying to name specific companies because nothing is in contract yet. But certain companies, like, you, don't think of as an open-source powerhouse. So, like, a company we're now talking to right now is walgreens.com. And Walgreens they have tech. They've got open source that they participated. But they're not thought of as a place like, oh, I want to go work at Walgreens and go work on some cloud infrastructure stuff. So, how does Walgreens get exposure? And, like, hey, we're involved in the kubectl, and the Kubernetes platform and stuff like that, like, be aware that there's opportunity here. So we're going to start driving that connection to folks. So, as you develop your career doing open source, you can also be noticed, and folks can reach out to you. And also, I want to stand on the notion of open source is not for everybody. But I also want to point out, like, my entire career in open source has not been nights and weekends. It's always been finding a company that supports my interest to do open-source at work. Part of my story is, like, I was getting an MBA. My first kid, who's nine years old now he, was born 11 weeks early. And he's the reason why I built an app because I wanted to build an app to solve a pain point that I had, and ended up building that in 17 weeks. And that turned into opportunity. So I guess what I'm getting at is, like, folks being laid off right now, you might have some extra free time. You might be submitting like 100 applications a day. Consider taking that down to 50 applications a day, and then try to contribute to a couple of open-source projects a month. So that way, there's some more story to be shared as you're in the job market. VICTORIA: I love that you created that app when you had your son and you had that need. And for developers wanting to get noticed and wanting to get their next leg up or maybe even negotiate for higher salaries, what's the traditional way people do that now to kind of highlight themselves? BRIAN: The traditional way what people are doing is they're tweeting. They're speaking at conferences. They're sharing their stories. It's like zero to I'm an influencer in the open-source space. There's no real clear guide and steps to get to that point, which is why we have highlights today. Like, we want to make it low effort for folks to write 200 characters about something they contributed to. We're actually working on something to generate pull request descriptions because I think that's another missed opportunity. Like, when you open a PR in an open-source project, and it says no description added, like, that's a missed opportunity. Like, there's an opportunity for you to share what you've learned, what Stack Overflow questions you looked at, like, how you got to the problem, and why this is the right solution. All should be in the pull request description. And then that pull request should be in your cover letter for your resume so that people can go back and say, "Oh, wow, you did some real work." I can go see the history of your contributions because perhaps the job you got let go from you only worked in private repos. You couldn't really showcase your skills. That now gives you a competitive edge. And I guess when I look into this, like, going back to my original onboard ramp into engineering, I graduated with a finance degree with no network. I had one internship at an insurance company, but that wasn't enough. Like, everyone who I interned with, like, the guy who got a job at the internship, like, his dad was a client, was a big client at that firm. And another guy he worked at a golf course, and he'd be the caddy for all these big finance folks where I went to school. So, once I learned that there's an opportunity to get a job by just knowing people, that changed my entire path. Like, when I got to sales, like, oh, or when I got to engineering, I just knew go and meet people. Go have conversations. Go to meetups. What I'm trying to do with OpenSauced is make that step closer for folks, so they could look up and be like, you know, I've made all these contributions, or I don't know where to start. Let me just look at people who I know and follow in the industry and see where they're contributing, and make that connection. So, like, we've kind of closed that gap without the need of, again, you don't need 100,000 Twitter followers to get noticed. Just make some contributions or show up and ask questions. And, hopefully, that's the first step to establishing your career. VICTORIA: Well, that sounds great for both people who are looking to get hired, but also, as someone who hires people, [laughter] I know that there's a lot of amazing developers who are never going to do a conference talk, or they're not going to post on Twitter. So I love that that's available, and that's something you're working on. BRIAN: Yeah, it's just coming out of my own pain of, like, I was saying, like, looking at the story now, it sounds great. [laughs] But part of that story was like, hey, I was getting severely underpaid as an engineer in San Francisco, living in a one-bedroom apartment with two kids. Like, all that part of the story is like nothing I dwell on. But it's like, all that opportunity and knowledge-sharing that I ended up benefiting from, it's like what I constantly try to give. I pay it forward with folks. And I'm more than happy to talk with folks on Twitter and in OpenSauced Discord and other places because I think there's a lot of opportunity in open source. And if anybody's willing to listen, I'm willing to show them the path. WILL: I'm so glad you brought that up because this is one of my favorite questions I ask on the podcast: So, knowing where you're at right now and your story, you've gone the ups, the downs, all of it. If you can go back in time and know what you know now, what advice would you give yourself at the beginning? BRIAN: Honestly, I would say write it down. Like, one thing that I did is I did a blog post, and that's part of the reason why I was able to find my first job in engineering is I started a blog, which was really for myself to learn what I did yesterday. I tell everyone who I mentor it takes two hours every time you want to sit and learn something new because one hour is to remember what you did yesterday, and then one hour is to do something new. And so, I usually write it down and then make it a blog post just to solve that problem. I wish I did more with that, like, you know, wrote a book, or created a YouTube channel, or something because all that knowledge and that sort of sharing is actually what got me to level up faster. I was asked by one of my close friends, like, "Hey, how do you do it? How do you accomplish everything you've done in the last, like, 9-10 years?" And I didn't know what the answer was then. But the answer today for my friend, and I'll share this with them, is it's because I wrote it down. I was able to go back and see what I did. And then, at the end of six months, I was able to go back six months and see what I did. It's like the idea of relativity with, like, Einstein. Relativity is the idea of motion and the perception. Like, if you're in a train, it feels like you're just going slow. But you might be going 100 miles per hour, but you don't feel that. And when you're going on your journey, you could be going 100 miles per hour, but you're thinking, oh, man, I failed yesterday. I could have solved a problem. But yeah, you solved six problems while trying to solve for one. It's that situation. So advice for myself, in the beginning, write it down and then share it way more than I did when I started. Because a lot of the stuff I'm like, even in this conversation, I'm thinking, oh yeah, this, this, and this. And I never shared that before, and I wish I did. So yeah. WILL: I love that. Because yeah, I feel like that's development, like, you have some weeks that you're shipping out multiple features. And then other weeks, you're like, I barely got one out, or I barely fixed this one bug that I've been trying to...struggling with the last couple of weeks. So yeah, I like that advice. Write it down. And remember where you've been, remember. I just love the example you used, too, because it does seem like I haven't made any movement. But when you look back, you're like, no, you actually made a lot of movement. And you were very successful with what you did. So that's great advice. VICTORIA: I sometimes write things, and then I go back maybe six months later and read them. And I'm like, who wrote this? [laughter] I don't remember learning this stuff. Oh yeah, I guess I did, right, yeah. [laughs] No, that's so cool. What questions do you have for us, Brian? BRIAN: I'm curious in, like, how do thoughtbot folks stay up to date? Like, what does your involvement in open source look like today? VICTORIA: Yeah, so we are known for being active maintainers of a lot of very popular Ruby on Rails gems. So we're a consulting agency. So we're able to structure our time with our clients so that we can build in what we call investment days, which is typically Fridays, so that people can contribute to open-source projects. They can write blog posts. They can do trainings. And so that gives us the structure to be able to actually allow our employees to contribute to open source, and it's a huge part of our business as well. So if you have a Ruby on Rails project, you're probably using one of our gems. [laughs] And so, when there's other crises or other things happening in an organization, and they want to bring in an expert, they know that that's who thoughtbot is. Of course, we've expanded, and we do React, and now we're doing platform engineering. And we have some open-source TerraForm modules that we use to migrate people onto AWS and operate at that enterprise level with a mix of managed products from AWS as well. And that continues to be, like, how we talk to people [laughs] and get that buzzword out there is, like, okay, there's this cool open-source project. Like, one I'm excited about now is OpenTelemetry. And so we're digging into that and figuring out how we can contribute. And can we make a big impact here? And that just opens the door to conversations in a way that is less salesy, right? [laughs] And people know us as the contributors and maintainers, and that creates a level of trust that goes a long way. And also, it really speaks to how we operate as a company as well, where the code is open and when we give it back to the customers, it's not. Some organizations will build stuff and then never give it to you. [laughs] BRIAN: Yeah. So it sounds like folks at thoughtbot could probably benefit from things like OpenSauced for discoverability. And I get a lot of conversation around in OpenSauced as like, how do I get connected to maintainer of X or maintainer of Y? And the first step is like, how do I even know who the maintainer is? Because when you go to GitHub, you could sort this by last commit date, which not a lot of people know. You can sort the contributors by most frequently and stuff like that. But it's challenging to find out who to reach out to when it comes to packages, especially when people move on. Like, someone created a thing. They have tons of commits. And then they look like they're the number one committer for the past ten years, but they left five years ago. Those are things that we're trying to make more discoverable to solve that problem. But then, going into that thoughtbot thing, is like being able to reach out to thoughtbot and be like, oh, who can I reach out to about this gem? And, say, I have an idea, or we have an issue; how can we get unblocked because we're using this in our product? And I imagine with consulting, there's an opportunity to say, hey thoughtbot...which, honestly, at Netlify, we used thoughtbot to solve some harder problems for us. We were just like, yeah, we don't have the bandwidth to go down this path. Let's go to consulting to unblock us in this arena. VICTORIA: Right. And that was really important to me in making the decision to join thoughtbot last year is that it was built around open source. And that ethos really spoke to me as, like, this is a place where I want to work. [laughs] And you can think of, like, if you're looking for vendors, like, oh, I want to work with people who have that same ethos. So yeah, OpenSauced seems like a really cool product. I'd be curious about how we can leverage it more at thoughtbot. BRIAN: We just shipped a feature called Teams, which it's self-explanatory. But, basically, when you build an insight page, you're able to build a team to help the discover process of what's happening in contributions. You get details and reporting on OpenSauced. The goal is basically to unblock teams who are involved in open source together and make it more discoverable for folks who want to find maintainers and collaborate with them. VICTORIA: Will, I know we're running close on time. But I had one more question about what you said around making open source more hospitable. And, you know, you mentioned going to Juneteenth Conf. And I'm curious if you have a perspective on if open source is equitably accessible to everyone or if there are things we can be doing as a community to be more inclusive. BRIAN: Yeah, it's a great question. So the first answer is quick, it's no. The reason why it's no is because we have to admit [laughs] where there are inequitable situations. And as much as we want to set this up of, like, I want to say that there's opportunity for everyone to contribute based on no matter where their background, but just by your time zone, makes it inequitable of, like, whether you can contribute to open source. Because if you look at the data and zoom out, most open source happens in the West Coast U.S., so from San Francisco to Seattle. Like, majority of contributions are there. There are reasons for that. Like, California has a very, very expressive clause of like where you can contribute. And, technically, your employer can block you on doing open-source contributions. Unless you sign...like, at Apple, you sign away your rights to be able to do that in your employee offer letter. Sorry, [laughs] not to be a dig against Apple. Apple buy lots of open source. But what I'm getting at is that the opportunity is there, but it's the awareness thing. I'm part of an organization called DevColor. It's an organization of Black engineers in tech. We have squads and monthly meetings where we just talk about our career, and growth, and stuff like that. And I attribute a lot of that interactions to my success is, like, talking to other folks who are years ahead of me and have a lot more experience. But I say this because the majority of the folks that I interact with at DevColor they don't do open source because they all...to be a Black engineer at a level of like senior engineer at Netlify, or a staff engineer, or a manager...sorry, I meant, like, Netflix but Netlify too. You basically had a career path of, like, you probably went to school at a decent engineering school, or you figured out how to get a job at Facebook or Google. And, like, that's pretty much it. And, like, this is a blanket statement. I totally understand there are outliers. But the majority of the folks I interact with at DevColor they have a job. They have a great job. And they're doing the thing, and they're being very successful. But there's less community interaction. And that's what DevColor exists for is to encourage that community interaction and participation. So, at the end of the day, like, there's opportunity to make it more equitable. So things like, every time there's a release cut for a major open-source project, why not go to Black Girls CODE and have them build something with it? And, again, very specific, like, React 19 that's currently being tested, why not go to all these other underrepresented organizations and partner with them to show them how to use this project? Because the assumption is everyone in open source, you got to be senior enough to participate, or if it's too hot, get out of the kitchen. But if we set up a place for people to interact and level up, in three or four years from now, you'll see the open-source ecosystem of that project be completely different as far as diversity. But it takes that investment to have that onboard ramp to even have that connection or conversation about testing early releases with underrepresented groups in engineering. That's where we have to start, and that's what we're trying to do at OpenSauced. We want to make that connection. I have a whole plan for it. I'll share in a blog post. I also mentioned that a lot of these thoughts are on our blog as well. I've been writing blog posts around these conversations. So opensauced.pizza/blog if you're interested. VICTORIA: Very cool. Thank you for that. WILL: I'm just processing on the whole conversation. It has just been great. VICTORIA: Yes. Thank you so much for sharing with us. And I wonder, do you have any final takeaways for our listeners today, Brian? BRIAN: Yeah, final takeaways. Like, if anything at all resonated in this conversation, please reach out, bdougie on GitHub. I'm pretty active with my notifications. So if you @ mention me in a random project, I'll probably jump back in and respond to you. But also Twitter @bdougieYO. And then, I mentioned our blog. We also have a newsletter. So, if you're interested in any of this OpenSauced journey, please join us there, and keep in touch. VICTORIA: Wonderful. Thank you so much for joining us today and sharing your story. You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg. WILL: And you could find me @will23larry This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thank you. ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. Special Guest: Brian Douglas.

On this episode of Ruby for All, Andrew attended RailsConf 2023 and talks about his experience at it, how he focused on socializing with friends and co-workers, and attended fewer talks than before. There were some great talks he heard and keynotes he really enjoyed, especially Aaron Patterson, who proposed the idea of Rails shipping its own LSP for Ruby and Rails. Also, a highlight was that this conference had a greater focus on early career developers, offering headshots and resume reviews, which was super cool.   Next year's conference will be in Detroit, and RubyConf 2023 is coming up in November in San Diego, so Julie and Andrew are both excited to attend this one and Andrew will have stickers in case you missed out. Hit download to hear more cool stuff!  [00:02:16] Andrew kicks things off telling us about RailsConf and seeing his crew.[00:04:25] Andrew mentions he attended fewer talks than before and focuses on the social aspect of meeting his friends and expresses his interest in learning more about asset management in Rails. [00:05:58] Julie asks Andrew about Sprockets, and he explains. [00:07:54] He talks about the sponsor exhibit hall at RailsConf, and talking to people from Crunchy Data, a Postgres service, and the RubyMine people from Jet Brains, which he wants to start using again. He mentions the RubyMine IDE and its features. [00:11:48] Andrew highlights Eileen Uchitelle and Aaron Patterson's keynotes, with Aaron Patterson proposing the idea of Rails shipping its own Language Server Protocol (LSP) for Ruby and Rails.[00:13:38] Andrew also enjoyed attending talks by his co-worker Vincent and Drew Bragg, which was a ton of fun.[00:15:16] Did Andrew go to any cool events? He hung out with some people for dinner, but was having major social anxiety, which caused him to stick by his friend Jason.[00:19:12] This year's RailsConf had more focus on early career developers, and he spent more time with them.  Also, Andrew met a lot of people who listen to the podcast. [00:23:26] Julie liked that the conference was focused on early career devs and wishes there was a regional conference that was geared solely to early career devs. [00:24:11] Next year RailsConf is in Detroit, and Andrew and Julie are looking forward to going to RubyConf 2023 in San Diego which will be Nov 13-15.[00:24:54] Yes, Andrew did pass out stickers at the conference, and many people asked for more. He also thanks all the sponsors that made it a success. Panelists:Andrew MasonJulie J.Sponsors:HoneybadgerGoRailsLinks:Andrew Mason TwitterAndrew Mason WebsiteJulie J. TwitterJulie J. WebsiteSprockets RailsShopify-Ruby LSP RailsCrunchy DataJet Brains-RubyMineRuby Conferences 

In 2022, Rails Hiring is Still Hot was our most listened to episode! By popular demand, Brian is back to give us the state of the Ruby on Rails hiring market for 2023. Brittany and Brian discuss his clients, advice for those who have a job and advice for those who are seeking a role in this weird market. Show Notes & Links: Episode 419: Rails Hiring is Still Hot (Brittany + Brian) (https://www.therubyonrailspodcast.com/419) Mirror Placement (https://www.mirrorplacement.com/) Sponsored By: Honeybadger (https://www.honeybadger.io/) Status Pages now come with incident management! Build confidence with a public status page that shows your live service status, incident history, and more—and bring your own domain! Transparency inspires trust—when your next outage happens, communication is key. Go to Honeybadger.io (https://www.honeybadger.io/) to learn more. JetBrains RubyMine (https://www.jetbrains.com/ruby/) RubyMine is an intelligent cross-platform IDE that provides all essential tools for Ruby and Ruby on Rails developers out of the box. It offers smart code completion and analysis, easy code navigation, safe automated refactorings, an interactive debugger, Git workflow support, database integration, and many other tools. All tools are integrated together in a highly customizable, productive, user-friendly environment. To get a special 20% discount for the listeners of The Ruby on Rails Podcast just enter the discount code railspodcast during purchase (https://www.jetbrains.com/ruby/). You can apply this discount to JetBrains All products pack and use IDEs of your choice.

Ruby For All – Episode 32On this episode of Ruby for All, it's raining a lot by Julie, chilly outside by Andrew, and  Andrew's birthday is this week! Happy Birthday, Andrew!  Since it's a new month, Andrew and Julie decided to talk about debugging. So today, they'll be discussing various debugging tools for troubleshooting Rails applications such as binding.irb, binding.pry, puts debugging, the new debug gem, web console, RubyMine, and VS Code debugger. Also, they talk about when to bring in help when a problem has taken too long, and they share advice on the importance of not assuming the cause of the problem, isolating the issue, and taking breaks. Debugging can be difficult and hard to figure out what happened, but always remember, practice makes perfect! We hope you enjoyed this episode!  Hit the download button now! [00:01:23] Andrew is ready to go and asks Julie what she does when she gets that red Rails error screen, and he tells us he reads in chunks.[00:02:11] What debugging tools does Julie use? She explains using binding.irb or binding.pry. Andrew tells us he uses pry a lot, and some others are puts debugging, a new debug gem that's in Ruby 3, and Web Console.[00:06:15] We hear about the debugger, RubyMine and the new debug gem that Andrew likes. He tells us he's huge binding.pry user since it comes naturally to him, and there's a video by Justin Searls you should check out. [00:07:37] Has Julie ever run into a bug that fixes itself when you restart the server? What did Julie do? Andrew brings up the spring gem that he's used, but it didn't work the way he wanted it to.   [00:09:12] Julie shares an instance where she worked for hours on a bug, finally give up, walked away, went to bed, came back, and it was fixed.  [00:12:32] Andrew has one more thing to tell us relating to doing puts debugging, and he tells us what he likes to do using ActiveSupport Deprecation.[00:14:11] Using Sandbox mode is brought up which is a great way if you're debugging in production, and Andrew tells us one of the hardest parts of debugging is recreating a certain thing and brings up a problem a customer who had with a bug and asked Julie where she would start. Andrew shares a third party service nightmare story with a debugging adventure. [00:17:48] Julie brings up a great question and wonders at what point do you bring another team member on to help you debug. [00:21:20] Julie and Andrew discuss using different browsers to figure out things.[00:24:28] As a junior, Julie doesn't look at the network tab and the log and wonders if Andrew looks at them. He explains he uses the debugging tools in the browser and the network tab all the time. Panelists:Andrew MasonJulie J.Sponsors:GoRailsHoneybadgerLinks:Andrew Mason TwitterAndrew Mason WebsiteJulie J. TwitterJulie J. Websiteputs_debuggerer 0.13.1debug.rbWeb ConsoleRubyMineSetup ruby/debug with VSCode by Stan LoDebugging Ruby on Rails with Visual Studio Code by Justin SearlsSpring 1.7.2ActiveSupport DeprecationRuby for All Podcast-Episode 4: Getting Unblocked

After taking a moment to talk about Chris Seaton's impact on the community, Nick tells Brittany about his adventures in TruffleRuby and Hatchbox. They also discuss how Shopify removed all recurring meetings with more than two people in perpetuity to encourage more focus time. Show Notes & Links: Chris Seaton (https://chrisseaton.com/) oracle/truffleruby - GitHub (https://github.com/oracle/truffleruby) postmodern/chruby: Changes the current Ruby - GitHub (https://github.com/postmodern/chruby) Hatchbox.io (https://hatchbox.io/) Roda: Routing Tree Web Toolkit - Jeremy Evans (https://roda.jeremyevans.net/) Shopify tells employees to just say no to meetings (https://www.seattletimes.com/business/shopify-tells-employees-to-just-say-no-to-meetings/) Workplace from Meta (https://www.workplace.com/) Sponsored By: Honeybadger (https://www.honeybadger.io/) Status Pages now come with incident management! Build confidence with a public status page that shows your live service status, incident history, and more—and bring your own domain! Transparency inspires trust—when your next outage happens, communication is key. Go to Honeybadger.io (https://www.honeybadger.io/) to learn more. JetBrains RubyMine (https://www.jetbrains.com/ruby/) RubyMine is an intelligent cross-platform IDE that provides all essential tools for Ruby and Ruby on Rails developers out of the box. It offers smart code completion and analysis, easy code navigation, safe automated refactorings, an interactive debugger, Git workflow support, database integration, and many other tools. All tools are integrated together in a highly customizable, productive, user-friendly environment. To get a special 20% discount for the listeners of The Ruby on Rails Podcast just enter the discount code railspodcast during purchase (https://www.jetbrains.com/ruby/). You can apply this discount to JetBrains All products pack and use IDEs of your choice.

After reflecting on their 2022 resolutions, Brittany and Jemma talk about their resolutions for 2023. Afterwards, Brittany congratulates Jemma on shipping Object Shapes in Ruby 3.2, asks what is in store for her next and why everyone should upgrade to Ruby 3.2. They wrap up the episode talking about team changes at TextUs. Show Notes & Links: Episode 399: New Year's Resolutions & Mediocrity with Brittany and Jemma (https://www.therubyonrailspodcast.com/399) Ruby 3.2.0 Released (https://www.ruby-lang.org/en/news/2022/12/25/ruby-3-2-0-released/) Shopify/yjit: Optimizing JIT compiler built inside CRuby - GitHub (https://github.com/Shopify/yjit) Sponsored By: Honeybadger (https://www.honeybadger.io/) Status Pages now come with incident management! Build confidence with a public status page that shows your live service status, incident history, and more—and bring your own domain! Transparency inspires trust—when your next outage happens, communication is key. Go to Honeybadger.io (https://www.honeybadger.io/) to learn more. JetBrains RubyMine (https://www.jetbrains.com/ruby/) RubyMine is an intelligent cross-platform IDE that provides all essential tools for Ruby and Ruby on Rails developers out of the box. It offers smart code completion and analysis, easy code navigation, safe automated refactorings, an interactive debugger, Git workflow support, database integration, and many other tools. All tools are integrated together in a highly customizable, productive, user-friendly environment. To get a special 20% discount for the listeners of The Ruby on Rails Podcast just enter the discount code railspodcast during purchase (https://www.jetbrains.com/ruby/). You can apply this discount to JetBrains All products pack and use IDEs of your choice.

In this episode of Ventures, I (https://www.reddit.com/user/wclittle) discuss both a Reddit conversation I posted recently about Low-Code/No-Code vs. ChatGPT-assisted code-from-scratch, and an overview of the curriculum we're planning to walk through in our Product and Code cohort (learn more and apply here: https://forms.gle/dtVA1bQ9xATRrPW29). I talk about Rails vs. Bubble, learning with LLMs, and a wide range of web developer topics - from installing necessary software on your computer to caching strategies - that anyone needs to know in order to become a proficient engineer for the modern web. Visit https://satchel.works/@wclittle/ventures-episode-130 for more information. You can watch this episode via video here.   0:06 - Tee-up for the conversation, teaching product and code (Learn more and apply here → https://forms.gle/dtVA1bQ9xATRrPW29) 0:20 - Low-code/no-code vs. build from scratch w/ ChatGPT – https://www.reddit.com/r/rails/comments/zv2xdx/reflections_since_my_rails_journey_began_in_2005/ // Episode w/ Josh from Bubble → https://satchel.works/@wclittle/ventures-episode-63 2:50 -  Product and Code cohort → https://www.reddit.com/r/rails/comments/zyjiq0/what_is_the_best_way_to_teach_ruby_on_rails/ // Apply: https://forms.gle/dtVA1bQ9xATRrPW29 4:36 - Curriculum overview walk-throughKnow your computer/OS well enough to install and run Ruby/Rails/Postgres/Redis/etc... locally (e.g. w/ Homebrew for MacOS)Shell / command lineIDE (VSC, Rubymine, etc..)Git / Github (PR & code review etiquette and such)Linting / PrettierCI / CDBasic DevOps w/ a cloud provider (like AWS + Relay or Heroku)Monitoring (Sentry/Scout/etc..)RubyCore HTML / CSS / JavaScript things of courseCore Rails things (routing, controllers, models, views, etc...)Testing w/ RspecStimulusViewComponentTurboA go-to CSS framework (I'm suggesting new devs quickly learn enough CSS to jump into Tailwind vs. Bootstrap these days, but ideally both and knowledge of BEM/SMACSS/OSS/ACSS)DockerCachingHow to best look up things w/ Google and ChatGPT (and others?) when you are stuck

Brittany is joined by the co-organizers of Rubyconf Mini: co-host, Jemma, and Emily Samp. The trio discussed how inclusivity was laced into the event, their futures as conference planners and the adoration of Jemma's Nana. In the back half of the episode, they discuss their expectations and reaction to the announcement of The Rails Foundation. Show Notes & Links: Episode 434 All Things RubyConf Mini (Brittany + Jemma) (https://www.therubyonrailspodcast.com/434) The Rails Foundation](https://rubyonrails.org/foundation) The Ruby on Rails Podcast Listener Feedback Form (https://docs.google.com/forms/d/e/1FAIpQLSdira0SzpFYUWkfZJzk5yloi6sKUGxcTPLE3V70RDjQOfwppw/viewform) Sponsored By: Honeybadger (https://www.honeybadger.io/) Honeybadger monitors your cron jobs and services to make sure they don't silently disappear. When Honeybadger is quiet, life is good. Check monitoring off your todo list. Try Honeybadger free for 15 days. JetBrains RubyMine (https://www.jetbrains.com/ruby/) RubyMine is an intelligent cross-platform IDE that provides all essential tools for Ruby and Ruby on Rails developers out of the box. It offers smart code completion and analysis, easy code navigation, safe automated refactorings, an interactive debugger, Git workflow support, database integration, and many other tools. All tools are integrated together in a highly customizable, productive, user-friendly environment. To get a special 20% discount for the listeners of The Ruby on Rails Podcast just enter the discount code railspodcast during purchase (https://www.jetbrains.com/ruby/). You can apply this discount to JetBrains All products pack and use IDEs of your choice.

It's back and now a tradition! It's the Holiday Gift Guide episode where Brittany and Nick share their picks for gifts that might appeal to a developer in your life. Brittany's Picks Philips Hue: Smart lighting (https://www.philips-hue.com/en-us) Gold Neutral Recorder Button (https://www.amazon.com/Neutral-Recorder-Recordable-Education-Batteries/dp/B07MQXQWBB) Cirkul Water Bottle | Brittany's Referral Link to Save $ (https://drinkcirkul.com/share/Brittany-V6240301580378) Felix Gray Blue Light Glasses (https://felixgray.com/collections/blue-light-glasses) Wizard Zines by Julia Evans (https://wizardzines.com/) Nick's Picks Rebuilding Rails by Noah Gibbs (https://rebuilding-rails.com/) AWS IoT Button (https://aws.amazon.com/iotbutton/) Roam Research – A note taking tool for networked thought (https://roamresearch.com/) Steam Deck (https://store.steampowered.com/steamdeck) Lava Lamp (https://www.lavalamp.com/) Sponsored By: Honeybadger (https://www.honeybadger.io/) Honeybadger monitors your cron jobs and services to make sure they don't silently disappear. When Honeybadger is quiet, life is good. Check monitoring off your todo list. Try Honeybadger free for 15 days. JetBrains RubyMine (https://www.jetbrains.com/ruby/) RubyMine is an intelligent cross-platform IDE that provides all essential tools for Ruby and Ruby on Rails developers out of the box. It offers smart code completion and analysis, easy code navigation, safe automated refactorings, an interactive debugger, Git workflow support, database integration, and many other tools. All tools are integrated together in a highly customizable, productive, user-friendly environment. To get a special 20% discount for the listeners of The Ruby on Rails Podcast just enter the discount code railspodcast during purchase (https://www.jetbrains.com/ruby/). You can apply this discount to JetBrains All products pack and use IDEs of your choice.

Roman Turner is a classically trained French chef turned developer. He's now a Software Developer at America's Test Kitchen. He and Brittany discuss personal branding, attracting and keeping members in the Ruby/Rails community and advice for junior developers seeking their first role. Show Notes & Links: America's Test Kitchen (https://www.americastestkitchen.com/) Jeweler's Apprentice (http://jewelers-apprentice.com/) Roman (@scoop_law) / Twitter (https://twitter.com/scoop_law) Sponsored By: Honeybadger (https://www.honeybadger.io/) Honeybadger monitors your cron jobs and services to make sure they don't silently disappear. When Honeybadger is quiet, life is good. Check monitoring off your todo list. Try Honeybadger free for 15 days. JetBrains RubyMine (https://www.jetbrains.com/ruby/) RubyMine is an intelligent cross-platform IDE that provides all essential tools for Ruby and Ruby on Rails developers out of the box. It offers smart code completion and analysis, easy code navigation, safe automated refactorings, an interactive debugger, Git workflow support, database integration, and many other tools. All tools are integrated together in a highly customizable, productive, user-friendly environment. To get a special 20% discount for the listeners of The Ruby on Rails Podcast just enter the discount code railspodcast during purchase (https://www.jetbrains.com/ruby/). You can apply this discount to JetBrains All products pack and use IDEs of your choice.

Steph is joined by a very special guest and fellow thoughtboter, Rob Whittaker. ngrok (https://ngrok.com/) Time Off Book (https://www.timeoffbook.com/) Rob's Codespace Setup (https://github.com/purinkle/codespace) Rob Whittaker on Twitter (https://twitter.com/purinkle) Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! Transcript: 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. And today, I'm joined by a very special guest and fellow thoughtboter, Rob Whittaker. Rob has been in the software business for the past 15 years and spent the last five and a half years at thoughtbot. Rob is the Director of Software Development for our Europe, Middle East, and Africa team and, in his spare time, likes to hunt down delicious beers and coffee. Rob, welcome to The Bike Shed. It's so lovely to have you on the show today. ROB: Thank you for having me. It's a pleasure to be here. Yeah, thank you for that lovely introduction and my far too complicated job title. It sounds more serious than it actually is. STEPH: Well, you do have a fancy job title, yeah, Director of Software Development. [laughs] ROB: Yeah, it's the added on bit where it's Europe, Middle East, and Africa where I feel like there's about 20 of us maximum. But that sounds more grandiose than it actually is. STEPH: Yeah, that's something that Chris and I haven't dug into too much on previous episodes are all the different teams that we have at thoughtbot. So the shorter way of saying that is Launchpad II, but not everybody knows that. But I'm going to circle back to that because I would love to talk a bit more about that specific team and the dynamic. But before we do that, I'm realizing I'm not familiar with your origin story as to how you came to thoughtbot and then how you became this very fancy grand title of Director of Software Development for Europe, Middle East, and Africa team. ROB: Yeah, there's a bit of history about thoughtbot London as well that kind of ties into this. So before thoughtbot Launchpad II, it was thoughtbot London before we went remote. And initially, we had the plan of setting up a new studio in London to help expand thoughtbot outside of the Americas, but that plan fell through. But he knew some people from another agency called New Bamboo, and so we merged with or acquired that agency, and that agency then became the thoughtbot London team. I'm actually the first hire or...not the first hire, that's not true, the first development hire for the thoughtbot London team that would then become launchpad II. I was at the Bath Ruby Conference six years ago, I guess. And there was just an advert up on the hiring board that Nick Charlton, who's a Senior Developer and Development Team Lead at Launchpad II now, had put up. And I saw it, and I was talking to somebody who was my mentor at the time that I'd worked with at a previous job at onthebeach.co.uk, a guy called Matt Valentine-House who now works at Shopify who, actually, fun fact, his face appears at the top of Ruby Weekly this week. If you open up this week's Ruby Weekly, you can see Matt Valentine-House, who said to me, "Yeah, apply for it, why not? You see what happens." And I was like, "Okay," and just kind of took the leap. So I thought, thoughtbot, why would thoughtbot want me? Which is something I think a lot of people think when they want to join thoughtbot. They think, well, I can't do that. But I would implore people to apply. And so, from there, I never really wanted to move to London. I'd always lived in the North West of the UK. I made that leap to London because I wanted to work at thoughtbot. And then, gradually, over time, the London team expanded, and we needed to split out the management roles, and the development director role came up. And I've always enjoyed the coaching side of software development. It seems that you gain more experience as you help people with less experience, and I've always enjoyed coaching. And that was a big part of the role for me. So I was fortunate enough to be allowed to do it. And then, from there, things have grown. Yeah, so it's been a really interesting journey as a development director. The London studio went through a pretty tough time at one point where not long after I became development director that two-thirds of the team, in the space of two weeks, decided to hand their notice in and unbeknownst to each other. And so, all of a sudden, we didn't have a very big team. We didn't have very many prospects, and so it was a tough time. And so it's really nice to look back on the last three years and go, okay, we came through that. We're now one of the stronger teams at thoughtbot. And somebody actually asked me in an interview the other day, somebody we actually hired, not just based on this question, but he said, "What is your proudest moment of working at thoughtbot?" And I was like, that's one of the best questions I've heard from a candidate. And I said, "Hmm, that's interesting." It's not anything development-related, but it's that I can now look back on this team and say this is the team that I have grown in my image and all these people apart from Nick, who was the person who put the advert of it at Bath Ruby. I've hired all these people, and so the buck stops with me really because if anybody isn't able to perform, then it's kind of my fault because these are the people that I want to grow into being the team and see be a successful product design team or product development team, which brings us to modern-day I guess. So yeah, that was a long origin story. That's pretty much my whole thoughtbot biography. And I apologize. STEPH: That was perfect. I thoroughly enjoyed hearing it. And yeah, that's an awesome question. What's your proudest moment, like, part of a team? That can yield so many insights. I love that question. And I love your answer as well in terms of this is the team. We've pulled through a hard time. And then we've built everybody to the point that they are now, which kind of leads in perfectly to my next question. So being the software development director, could you walk us through a little bit of like, that's one of those titles I feel like a lot of companies have, but they can be very different from company to company. Would you mind walking us through a bit of the day-to-day in the life of being a development director? ROB: Yeah, sure. It's one of those things where I think this is something that I'm not sure if it's unique to thoughtbot, but you end up taking on a lot of hats at thoughtbot. So I know you're a team lead. So you have to balance your responsibilities as an individual contributor, which is a term I don't like, but I haven't got a better way to say it yet, and your development team lead roles. And I have similar sort of responsibilities where I have to do my individual contributor work. I have to do my director work. I'm also on our DEI Council. So I have to add that work in too, and make sure it's balanced out. So the start of my day is very much about prioritizing things. I know you and Chris, a few episodes ago, had quite lengthy discussions about productivity systems and what tools Chris wants to use. And I'm a big fan of Things, and I've been using it for maybe ten years, if not more, that I've now got my system down that I'm able to prioritize things in the way that I can pick up the right task at the right time. So a big part of my day-to-day is figuring out what is the most important thing to work on? So I have my client work, and then it's about supporting the team from that point. And the big part of my idea of what a manager is is that my job isn't to tell you what to do; my job is to find out what you want to do and direct you in a place where you can find the answer. Or I can give you some guidance about where to find the answer. And I feel like I'm doing a bad job as a manager where if I have to act as a middle person. Because if somebody comes to me and says, "Oh, I want to do this thing," And I say, "Well, I'll talk to that person for you," and then come back, I have failed. And my job is to say, "Oh, you should talk to that person about this." And to some extent, it's about being lazy. I don't want to be doing too much stuff because I have other things to do. But I want to make sure that those people have the right frameworks and guidelines in place so that I can point them in the right direction. STEPH: I think the fancy term for that is just delegating. [laughs] ROB: Yes, thank you. [laughs] STEPH: But I like lazy. [laughter] I like that one as well. I love that framing of a manager where you're not telling someone to do, but as your job, you are helping that person figure out what they want to do and then supporting them. I've been chatting with Chris recently and some others because I've been reading the book Resilient Management by Laura Hogan. And it's really helped me cement the difference between mentorship, coaching, and sponsorship. And I realized that I'm already falling a lot into the coaching and sponsorship because mentorship can be wonderful, but it is more directive of like, this is what I've done. And this is what has worked for me, and you should do this too. Versus the coaching and sponsorship, I think aligns far more perfectly with what you described as management, where it is my job to figure out what brings you joy, what brings you energy, and then how to help you progress to your next goals and your next steps in your career. ROB: Yeah, I think Laura Hogan is a great resource like her blog posts and books. I haven't read Resilient Management. But I know that the team leads on my team had been on her training courses, and they say how great it is. And there's also a blog post of hers that's about managing in tough times. It has a much better title than that. But it's about how do we be good managers in such uncertain times when there are a lot of things going on around the world right now that we all have to deal with? And helping people deal with those situations. Because at the end of the day, work isn't the most important thing; the most important thing is living. And it's something I say to my team, especially when people feel like...it's something that I say to my team when they're not feeling well. The most important thing is that you get better. And thoughtbot is still going to be here. The most important thing is how you live your life and how you look after yourself, and everything else is secondary. STEPH: Absolutely. Well, and everybody needs something different from work too. Some people may be in a state where they really need more stability and predictability from their work. And some people may be in a space where everything else outside of work is very stable and calm, and then they want work to bring the challenge and the volatility and the variety to life. So I remind myself very often that not everybody wants the same thing from work and to figure out what it is that someone wants from work. And then your seasons change. You may be in a season of where you want stability, or then you may be in a season of like, I'm ready to grow and push and take some risks. So helping someone identify which season of work they're in. ROB: Yeah, I 100% agree. What people can't see is me nodding vigorously on the other side of this call. It's very much about understanding because everybody is different. And that's what we want from a good team; it's understanding everybody's different approach to things. And so sometimes people want the distraction of work because they don't want the time off to think about other things. They want to be able to sit and concentrate on something. And it's understanding different people. STEPH: Yeah, that's a great point. I'm curious; you mentioned that as part of being development director, you are also, in addition to managing the team and being part of DEI then, there's also your day-to-day client work. I think you've started a new client recently. Could you tell me more about that? ROB: Yeah, I'd recently been working for a client for two and a half years, which is a very long time to be working with one client at thoughtbot. And it came to the time where I was ready for a new challenge, and it was stable enough for me to move on. So I've been working for a company in the UK. They allow customers to buy and sell cars, not between customers, the customers like companies like Auto Trader but customers to dealers and back and forth. And primarily, they worked with buying cars. And they've launched a product in the UK where people can sell their cars as well because they found that 70% of people who are buying cars also want to sell their cars. And from there, they're now looking to expand into Germany and Spain, so we are helping them to do that. And it's an interesting project, not necessarily from a technical point of view, but I might come back to that but definitely from a cultural point of view. The product at the moment allows you to put in a license plate or a registration plate for a car. And there's then a service in the UK that will allow you to pull up the maker model and the service history of that car. But you can't do that in Germany because it's against the privacy laws to find something from registration plates. And so it's interesting these different cultural aspects that you have to take into account when expanding into other countries that you aren't from and that you have less knowledge about. Because I'm also aware that credit cards aren't a big thing in Germany either. So you have to think about how they pay for things in different countries. And the previous company I was working for they're based in the Middle East. And so we had to take into account how we would do right to left design in a mobile app, which is really interesting from a western point of view that you get so used to swiping through an experience from left to right. But then it's not just the screen that's right to left. The journey moves from right to left. So you have to get used to the transitions of the screen going the other way and not thinking of that as going backwards. It's one of the best things about working in this region is that we get to deal with so many different cultures and how they expect to use applications. It's really satisfying. STEPH: That's fascinating. Yeah, I haven't gotten to work on a project like that that has those types of considerations. I think the most relatable experience I have is more working in healthcare because that's one of those areas that I'm certainly not proficient. I've become more proficient because of the type of projects that I've worked on. But I'm curious, for expanding into other regions and cultures, do those teams typically have an expert on their team that then helps guide the development process? Or, as you mentioned, the process of buying a car could be very different in some of the legal aspects that you're up against. Is there someone that you can turn to that's then helping mentor or be aware of that process? ROB: Yes, the current client they have a team based in Germany, people who are from Germany that are advising us on different cultural aspects or legislative things. They are doing a lot of data analysis for us because we need a new service that we can use for looking up car details. Because there is a service that you give different information to to get information about the car back from. So yeah, we do have that team there. But that's not always the case because every client is different. The company that we're working for in the Middle East didn't have a team. They had two developers who were helping us. But we have to figure things out just from their cultural background to ask them questions about things and allow them to advise us, but nobody who was really a specialist. But that's an interesting thing as well, not just the cultural aspects of the customers but the cultural aspects of the company that you work for. We definitely found that the company in the Middle East was more hierarchical. And so that's another challenge that you have to work with because we tend to work in quite a flat way where we tend to default as on thoughtbot projects, of not having a point person on a project. Everybody is there to answer the questions. But some teams or clients want that point person. And so, we adapt and change to allow for that to happen and work in that way. But it is interesting to work in different companies as well as working as an agency. STEPH: Yeah, you bring up a really good point of something that I don't reflect on very often, but it's something that I really appreciate about our thoughtbot culture is that we do try to strive for a very flat hierarchy. But also in working with clients, we purposely will avoid like, if there are two or more thoughtboters on a project, we don't want one person that is then the primary contact between the client and the thoughtbot team. The goal is that everybody shows up. Everybody is part of the process; everybody is part of meetings. And we do have an advisor for projects, but otherwise, we work very hard to make sure that there's not just one person that's then responsible for communication. We want everybody to have opportunities to be part of meetings, to lead meetings, to take on initiatives versus having that one person. That is something that I really appreciate that we do. ROB: Yeah. And it's more noticeable when you go to places where that isn't the norm, and you appreciate it more. And I think a big part of that is how much we are trusted. And we trust people to trust us, I guess. STEPH: Yeah. And I think it fits in nicely with circling back to the management conversation is that when people have access to those opportunities, that makes my job so much easier as a team lead where then there are more opportunities to sponsor someone or to coach someone as to how they can then be the person that then takes on a project or if they want to lead a particular meeting, or if they want to help a team introduce retrospectives into their process. So it gives more opportunities for me to then coach someone into expanding their skill set in those ways. ROB: Yeah, that's interesting to think about, allowing yourself to coach other people in that role. Because as we gain more experience and become senior developers, we naturally fall into that role of taking the lead on projects, even when we're not asked to. But then, when you gain other responsibilities in the management track, so you as a team lead and me as a team lead and a development director, it could be better for you to not take that role and allow somebody else to come into that role so you can coach them. That's been playing on my mind the last couple of days. Josh Clayton, who's the Managing Director for one of our teams in the Americas, raised it on our pull request in our handbook where we were talking about team leads having a dedicated day to concentrate on team lead things. It's one of those things where somebody says something, and it's like, oh yeah, that really clicks. Maybe that's why we have been having certain struggles on projects where we need to rearrange things and learn from that and so we can be better on projects in the future. So that's something that really resonated with me, and it's flying around in the back of my mind at the moment. STEPH: Yeah, that really resonates with me because while the predominant part of being a team lead at thoughtbot is having one-on-ones with folks, I find that when I have more time, a lot of the work also falls outside of that one-on-one where it's following up on conversations around hey, this person mentioned they're really interested in growing their skill. How can I help them? How can I help find opportunities? Or I know that they're currently stretching their skill set right now. If I have some extra time, then I can check in with them. I can pair with them. I can see how things are going. So I find that while the one-on-ones are the staple thing that happens every two weeks, there's a lot of other behind-the-scenes work that's going on as well to make sure that that person is growing and feeling really fulfilled by their work. ROB: I know we've spoken a lot about the product side and the client side of working on the new project that I'm working on. There are some interesting technical sides to it as well. The client has found that they have had some issues with Haskell and running on M1 Macs. And so, they've decided to take the leap and use GitHub Codespaces as their primary development environment, which has been interesting. I had heard about it but only in the background. I hadn't read anything about it or hadn't had any direct conversations. I just heard that there was a thing. So it's been quite interesting to play with that. It's interesting the way the client is using it as well because they're using a Dockerized environment effectively inside Docker by using Codespaces. So you start the Codespace, which very basically is a Docker instance somewhere on GitHub's infrastructure. It's built very much for Visual Studio Code, and so you can just directly attach your Visual Studio Code session to the Codespace and go from there, but I'm a Vim user. I've started to feel like a bit of an old guard or a curmudgeon recently where I've been like; maybe I need to use Visual Studio Code. Maybe I should just unlearn my Vim key bindings and learn the Visual Studio ones. And people say, "Oh, you could just use The Vim key bindings in VS Code." I'm like, that's cheating. I spent the time to learn the key bindings for Vim. I will take the time to learn the key bindings for Visual Studio Code and use it for the way it's intended. So it's been interesting to understand how Codespaces works, not necessarily in the way, it's intended. So you can still SSH into a Codespace session, but then you lose all the lovely setup stuff that you might have on your local machine. So I did spend half a day porting my dotfiles which are based off thoughtbot's dotfiles, into something that Codespaces can use and made it publicly available. So if you go to github.com/purinkle/codespace, you can see what I use to set up my Codespace environment. And once that's set up, it becomes a bit easier because then you have all the things that you're used to running locally. It is very much early days for how the client is using it. And so they're really open to saying like, okay, let's find out what's not working, and let's work and figure out how to get it up and running properly. So one of the things we do find is that Codespaces do timeout after a while. And then you might lose, like, even if I've created a tmux session, that tmux session disappears. And so I have to go in and create it again. I'm not sure what the timeouts are. I haven't had time to look into what those timeouts are yet. But that's definitely the main pain point at the moment of it being used as a development environment. It's been interesting. It's been kicking around in the back of my head like the difference between developing locally and deploying locally. And it's something that I wanted to talk to people at thoughtbot and outside of thoughtbot as well to understand that more. Because I don't think you need everything running to develop locally, but you might need it to deploy locally. It's interesting to me to understand how different companies work on their products from that point of view. STEPH: Yeah, I'm selfishly excited that you are using Codespaces for a client project because I have kept an eye on it, and I'm very intrigued by it. But I also haven't used it for a project. And it sounds really neat. I'm curious, have you found that it has helped them with onboarding or if you need to switch from working on one application to another? Have you found that it has helped them with some of those? I'm guessing that's the problem that they're optimizing to solve is how do we help people run everything quickly without having to set it up locally? ROB: It's an interesting question because I don't have the comparison of trying to set up the environment as it was before. It was smoother. The main thing with access tokens because once you can set up your SSH keys and your GitHub tokens, it's just a case of running a script and letting it run. So yes, from that point of view, I can imagine if I tried to set up their previous environment, that it'd be a lot more challenging because they were using Vagrant and running things that way, which I know from experience would not be fun. And I know that my Mac fans would just be spinning all the time. It would be like an aeroplane was trying to take off. So I'm thankful for that, that I don't have that experience anymore that my machine is going to slow down all the time. We've had on a previous client who had a Dockerized environment, but you have to have it all running on your machine. There are pros and cons to everything with these things. And it's like you said, what is the problem they're trying to solve with introducing this setup? STEPH: Yeah, I can't decide if this is a good thing or a bad thing. But I'm also intrigued by the idea that if a team is using Codespaces, then that means everybody else is using VS Code. And you can still customize it so you can still have your own preferences. But that does set a standard, so everybody is using the same editor. There's a lot of cross-collaboration in terms of if you do run into an issue, then you can help each other out. Versus when I join other teams, everybody's using their preferred editor, and then there you may have a day where someone's like, "Oh, I'm really stuck because my particular editor is suddenly having a problem and can't connect." And then you have less people that are able to help them if they're not using that same editor. And I can't decide if I like that or if I hate it [laughs] in terms of taking away people's ability to pick and choose their editor. But then the gains of everybody is using the same thing which is nice and would be really great for pairing too. ROB: Yeah, that's an interesting point. I was talking to...I have a management coach. He's a PHP developer, and I'm a Rails developer. And we were talking about the homogenization of things nowadays. And is that good, or is that bad to use with stuff like RuboCop that lints everything, so it's exactly the same? Does that stifle creativity? But then, at the same time, the thing I like about Codespaces is I think we're biased coming at it from the point of view of Rails developers. And if you look at how you can use Codespaces in the browser directly from GitHub, that's quite interesting because now you're lowering the barrier to entry to get started and saying you don't need to have an editor. You don't have to set up everything. You can just do it from your browser. A few years ago, I used to volunteer or coach at an organization called codebar. They help people who are less represented in the tech community get represented in the tech community. And we would see a lot of people coming for sessions using...I forgot what it's called. What was it called? Cloud 66 or something. There was some remote development environment that people would come and say, "Oh, I've been using this," because they didn't know how to set up the necessary infrastructure to just get a Rails server going or things like that or didn't know how to set up Sublime or Atom or editor of choice. And it's really interesting if you remove your bias of 15 years of professional software development and go okay, if I were starting today, what would the environment look like, and how would I get started? I'm lucky enough that I've grown up with the web and seen how web development has changed and been able to gain more knowledge as it's appeared. I don't envy anybody who has to come into the industry now and suddenly have to drink from this firehose of all these different frameworks, all these different technologies. Yeah, I started off by just right-clicking and viewing source on HTML files back in 1998 or something ridiculous like that. And CSS didn't even exist or wasn't used. And so it's a much different world than 24 years ago. STEPH: That is something that Chris and I have mentioned on previous episodes where people are coming into software development, and as much as we love Vim and it sounds like you love Vim, our advice is don't start with Vim. Don't start there. You've got so much to learn. Start with something like VS Code that's going to help you out. And you make such a great point in regards to this lowering the barrier to entry. Because I have been part of a number of classes where you have people coming in with Macs or with a Windows machine, and then you're trying to get everybody set up. You want them to use the same browser for testing. And we spend like a whole class just getting everybody on the same page and making sure their machines are working or then troubleshooting if something's not. But if they can just go to GitHub and then they can run things seamlessly there, that's a total game-changer in terms of how I would teach a class, and it would just be far easier. So I hadn't even considered the benefits that would have for teachers or just for onboarding teams as well. But yeah, specifically for leading a class, I think that is a huge benefit. GitHub did some pretty cool stuff around when they were launching that as well because I went back and watched some of their GitHub Universe sessions that they had where they were talking about Codespaces. And one of the things that they did that I really appreciated was how they went about launching Codespaces. So initially, it was how fast can this be? Or what's our proof of concept? And I think when they were building this, they found it took about 45 minutes if they wanted to spin up an application and then provide you a development environment. And they're like, okay, cool, like, we can do this, but it's 45 minutes, and that's not going to work. And so then their next iteration, they got it down to 25 minutes, and then they got it down to 5 minutes. And now they've got it to the point that it's instantaneous because they're building stuff in the background overnight. And so then that way, when you click on it, it's just all ready for you. But I loved that cycle, that process that they went through of can we even do this? And then let's see, slowly, incrementally, how fast can we get it? And then, to get feedback, instead of transitioning their own internal teams to it right away, they created this more public club. I think they called it The Computer Club, something like that. And they're like, hey, if you want to be part of Codespaces or try out this new feature that we have, delete all the source and the things that you need locally, and then just commit to using Codespaces. And then, if you are stuck or if you have trouble, then your job is to let us know so then we can iterate, and we can fix it. I really liked that approach that they took to launching this product and then getting feedback from everyone and then improving upon it. ROB: Yeah, that sounds like an Agile developer's dream where you just put something out there that's the bare bones, and you're given license to learn from that experience and how people are actually using that tool. That's something we've actually tried to do on the client project at the moment is adding all the...now that there's a different flow in Germany, there are different questions we need to ask. And so that could be quite a complex thing to put into place. So what we said is what we're going to do is just put in the different screens, and all you have is one option to click. So you click that option, you go to the next one, go to the next one, go to the next one. Then we have something that the customer can click on and play with and understand, and then we can iterate on top of that. But it also allows us to identify areas of risk because you can go; oh, where does this information come from? But now we need to get this from a third-party service. So that's the riskiest thing we've got to work on here, where this other thing is just a hard-coded list of three-door or five-door cars. And so that's an easier problem to solve. So allowing yourself to put something that could be quite complex like GitHub Codespaces and go okay, we're going to put something out there. It takes 45 minutes to run-up. But we're telling you it takes 45 minutes to run it. We're not happy with it, but we want to learn how you're using it so that we can then improve it but improve it in the right direction. Because it might be that we get it to 20 minutes to start up, but you need it in half a second. That's a ridiculous example. Or it might be that you need to be able to use RubyMine with it instead of VS Code, and that's where the market isn't. That's the thing that you can't learn in isolation that you have to put something out there for people to use and play with. STEPH: There's one other cool feature I want to highlight that I realized that they offer as well. So in the past, I've used a tool called ngrok, which then you can make your localhost public so other people can access. You can literally demo what you're working on locally, and someone else can access it. And I think that it's very cool. It's come in handy a number of times. And my understanding is that Codespaces has that feature where they can make your localhost accessible. So your work in progress you can then share with someone, and I love that. ROB: Oh, that's really interesting. I didn't know you could do that. I know you could forward ports from your local machine to that. But I didn't know you could share it externally. That'd be really cool. I can see how that can be really helpful in demos and pairing. And it makes sense because it's not running on your computer. It's running on some remote architecture somewhere. That's interesting. STEPH: Well, that's the dream I've been sold from what I've been reading about GitHub Codespaces. So if I'm telling lies, you let me know [laughs] as you're working further in it than I am. But yeah, that was one of the features that I read, and I was like, yeah, that's great because I love ngrok for that purpose. And it would be really cool if that's already built into Codespaces as well. ROB: ngrok is really interesting with things like trying to get third-party services to work. So from, the previous client, they wanted an Alexa Skill. And so, if you're trying to work with an Alexa Skill, you have to sign in from Amazon's architecture onto your local machine. You have to use ngrok as the tool there. So I wonder if that could potentially solve a problem where if there are three developers trying to develop on this if you could point to one Codespace that you're all working on rather than... Because the problem we had was if me or Fritz or Rakesh was working on this, we'd have to go and then change the settings on the Amazon Alexa Skill to point to a different machine. Whereas I wonder if Codespasces allows you to have this entry point, you could point to like thoughtbot.codespace.github.com or something like that that would then allow you to share that instance. That's something interesting that I think about now. I wonder if you could share Codespace instances amongst each other. I don't know. STEPH: Yeah, I'm intrigued too. That sounds like it'd be really helpful. So circling back just a bit to where we were talking about wearing different hats in terms of working on client work, and then also working on the team, and then also potentially some sales work as well, I'm curious, how do you balance that transition? How do you balance solving hard problems in a codebase and then also transition to solving hard problems in the management space? How do you make all of that fit cohesively in your day or your week? ROB: The main thing that somebody said to me recently is that you can only do so much in a day, and it's about the order that you approach those things. And just be content with the fact that you're not going to get everything done. But you have to make sure that you work on things in the right order and just take your time and then work through them. I read a really good book recently that was recommended to me by my coach called Time Off. And it's all about finding your rest ethic, which sounds a bit abstract and a bit weird. But all it is it's about understanding that you can't be working 100% all the time. It's not possible. As developers, sometimes we can forget that we're creative people, and creativity comes from a part of your brain that works subconsciously. So it's important for you to take breaks throughout the day and kind of go okay; I use the Pomodoro Technique. So I have an app that runs, and every 25 minutes, I just take a little break. I don't use it in the way that it's supposed to be used. I just use it to give me a trigger to have a break every 25 minutes. And so in that time, I'll just step away from my computer. I'll walk to the kitchen, grab a glass of water. I usually have a magazine or a book next to my table. So I have a magazine here at the moment. I'll just read a page of that just to kind of rest my eyes, so they focus at a different level but also just to get my brain thinking about something else. And it seems counterproductive that like, oh, you're stepping out of what you were doing. But then I find like, oh, I suddenly have a little refresher to like, oh, I need to get back into what I was doing. I know where I've got to go. That thing that I was thinking about now makes a little bit more sense. And even if it's a bigger break, give yourself the license to go for a walk and just kind of clear your head. And a big thing about going for a walk is not to concentrate on completing the task of walking but to concentrate on the walk itself and taking the things that are happening around you. And let your mind just kind of...you'll sometimes notice that oh, I can hear a bird. But that bird's been chirping for five minutes, and you didn't notice because your mind's kind of going. And if you concentrate on, I just want to complete this walk, that's what I'm out here to do, then you lose that ability to let your mind reset. That's a big thing that I'm working on personally to concentrate on the doing rather than the getting done. And it ties into the craft of being a software developer because if you concentrate on the actual writing of the code and the best practices that we all believe in, you end up with something better that you don't then have to revisit at a later time. Where if you just try and get something done, you're just going to end up having to come back to it or have to revisit in some other way. I've actually got a blog post coming out soon about notifications on phones. I'm a big believer that your phone belongs to you and that if your work wants you to have work notifications on your phone, then they could buy you a phone just for that purpose. The only thing where I kind of draw the line is I have notifications for meetings on my phone because I can't think of another way to get those things to ping up at me. And I understand that there are jobs where you do need to have those sorts of notifications, especially things like where you're on call; it's a big thing. But when it comes to things where a manager wants to get a hold of you straight away, from a trust point of view, that's where I think things fall down. And you're questioning, like, okay, why does this person need to get hold of me at 7:00, 8:00, 9:00, 10:00 o'clock at night? And should I be available? We build by the day at thoughtbot. And so when I find, not when I find but when I talk to people, and they say, "Oh, I was still working at 7:30, 8:00 o'clock," I will say, "Why? You're devaluing your own time at that point because we're not billing any extra for that time. So you're making your craft and your skill...you're cheapening it. And I want them to relish the skills and competencies that they have. That's a big thing for me. We're very lucky at thoughtbot that we can draw a boundary at the end of the day and go, okay, that's it. There's no expectation for me. It is much more difficult at product companies. But yeah, I think it's something that as an industry, and it's a bigger thing as a society, especially with younger people coming into the industry who have never worked in an office and may never work in an office, that idea of where is the cutoff? For so much of the pandemic, the people I would get concerned about the most are the people whose beds I could see behind them because I'm thinking to myself, you spend at least 16 hours a day in that same room. And that's going to become the norm for people. And if people don't have those rest periods and those breaks and aren't given the opportunities to do that by their managers, then it's not going to end well. And happy people and fulfilled people do the best jobs from a business point of view. But that's never the way I approach it, but that's what I say to people. STEPH: I think that's one of the biggest mistakes that I made early on in my career, and even now, I still have to coach myself through it. It's like you said, we are creative people and people in software and in general and not just developers, but it's a creative craft. And I wouldn't step away to take breaks. I just thought if I pushed hard enough, I would figure it out, and then I could get done with my work because I was so focused on getting it done versus the doing, as you'd highlighted earlier. I haven't really thought about it in that particular light of focusing on this is the thing that I'm working on. And yes, I do want to get it done, but let's also focus on the doing portion of it. And so I wouldn't step away for walks. I wouldn't step away for breaks. And that is something that I have learned the hard way that when I actually gave myself that time to breathe, if I gave myself a moment to relax, then I would come back refreshed and then ready to tackle whatever challenge was in front of me. And same for keeping a magazine that's near my desk; I have found that if I keep a book or something that I enjoy...because, at some point, my brain is going to look for some rest, like, it happens. That's when we flip open Twitter or Instagram or emails or something because our brain is looking for something easy and maybe a little bit of like brain candy, something to give us a little hit. And I have found that if I keep something else more intentional by my desk, something that I want to read or that I'm enjoying, then I find that when I am seeking for something that's short that I can look at, that I feel more relaxed and fulfilled from that versus then if I go to Twitter, and then I see a bunch of stuff, I don't like, and then I go back to work. [laughs] And it has the opposite effect of what I actually wanted to do with my downtime. I love the sound of this book. We'll be sure to include a link in the show notes because it sounds like a really good book to read. And I've also worked on improving the setup with my phone and notifications, where I have compartmentalized all the work-related apps into one folder, and then I keep it on the third screen of my phone. So if I want to see something that's work-related, it's very intentional of like, I have to scroll past all of the stuff that matters to me outside of work and then get to that work section and then click in that folder to then see like, okay, this is where I have Slack, and Gmail, and Basecamp, and all the other things that I might need for work. And I have found that has really helped me because I do still have the notifications on my phone, but at least putting it on its own screen further away from the home screen has been really helpful. ROB: Do you find that you still get distracted by that, though, when you're in the flow of doing something else? STEPH: I don't with my phone. I am a person who ignores my phone really well. I don't know if that's a good thing or a bad thing, [laughs] but it is a truth of who I am where I'm pretty good at ignoring my phone. ROB: That's a good skill to have. If there's any phone in the room and a notification goes off, my head swivels, and I pivot, and I'm like, oh, yeah, some dopamine hit over there that I can get from looking at somebody else's notification. STEPH: I have noticed that in the other people that I'm around. Yeah, it's that sound that just triggers people like, oh, I got to look. And even if you know it's not your phone like you heard someone else's phone ding, it still makes you check your phone even though probably there's a part of your brain that recognizes like, that wasn't mine, but I'm still going to check anyways. And I have worked hard to fight that where even if I hear my phone go off, I'm like, okay, cool, I'll get to it. I'll check it when I need to. And I'm that person that whenever apps always ask me, "Can we send you notifications?" I'm like, no, you may not send me notifications. [laughs] Something else you said that I haven't thought about until just now is the idea that there are some people who have never worked in an office or may never work in an office because we are leaning into more remote jobs. And that is fascinating to me to think about that someone won't have had that experience. But you make such a good point that we need to start thinking about these boundaries now and how we manage our remote work and our home life because this is, going forward, going to be the new norm for a number of people. So how do we go ahead and start putting good practices in place for those future workers? ROB: One of the things, as we've hired people from a remote point of view who've only worked with thoughtbot remotely, is the idea of visibility. And I don't mean the visibility of I want to see when somebody's working but maybe the invisibility of people. Because you can't see when people are taking breaks, you assume that everybody is working all the time, and so then you don't take those breaks. And so this is something we saw with people who we hired in the first six months of being remote. And they were burning out because they didn't realize that other people were taking breaks. Because they didn't know about the cultural norms of how we worked at thoughtbot. But people who had worked in the studio would know that people would get up and have breaks. People would get up and go get a coffee from a coffee shop and then have a walk around. They didn't know that that was the culture because they bring the culture from other places with them. But then it's much harder to get people to understand your way of working and how we think that we should approach things when you are sat in isolation in a room with a screen. And that's something that we've had to say to people to break that down. And even things that we took for granted when we worked in a studio where somebody would get up and ask somebody if they could pair with them even if they weren't on the same project. Somebody might have more Elm knowledge or React Native knowledge, or Elixir knowledge. And you'd get up and say, "Hey, can I borrow some of your time just to go over this thing, to pair?" And everybody would say, "Yeah, yeah, I can find some time. If not now, we can do it later." And recently, we've had people saying, "Oh, is it okay if we pair across projects? Is it okay if we pair with other people?" It's like, "Yeah, pair." One of the big things we say is that we have this vast amount of knowledge across thoughtbot, across the world that we can tap into and that you can use. And that's just one example of how do you get those core things that you take for granted and help people understand them? Because you don't know what people don't know. And it's all about that implied knowledge. So that's something that we learned. And we try and say to people and instill in them about yeah, take breaks. You can pair with people. There are people who bring in culture from other places with them. But then, to go back to where you started, how do you start with people who have no culture with them or have the culture of coming from maybe from school, or university, or from a different industry? How do you help those people add to your culture but also learn from your culture at the same time? Big people problems. STEPH: Have you found any helpful strategies to normalize that take a break culture? ROB: One thing we tried, but it doesn't last very long because people are lazy, is putting it in Slack saying, "I'm going for a break." And you can do that, but it's so artificial. After a week or two weeks, people just stopped doing it. It was through conversation. We have a regular retrospective as the Launchpad II team where we talk about what is working, what isn't working. And we have such a trusting environment where people will say things along the lines of this isn't working for me, or I feel like I'm burning out. Then we will talk to each other about it and figure out where it comes from. And it's a good point to raise that I don't think we have explicitly addressed it. But it is something that we will address. I'm not going to say could address; we will address it. I will talk to our latest hire, Dorian, who I have a one-on-one with next week, and to kind of talk to him about it. And we should maybe try and codify that in our handbook somewhere so everybody can learn from it, at least start a strategy and a conversation. Because I don't think it is something that we do talk about. It's the problem of being siloed and being remote and time zones as well. A lot of stuff that Launchpad I knows Launchpad II doesn't necessarily know because we only have three, maybe, hours if people are based on the East Coast where we overlap. I have meetings with Geronda, who's our DEI Program Manager, and she lives in Seattle. And so sometimes I'll talk to her at 5:00 o'clock, and it's 7:00 o'clock in the morning for her. And you have different energy levels. But yeah, so we spend time to try and figure out how we work together. STEPH: Yeah, I like that idea of highlighting that we take breaks somewhere that's part of your expectations as part of your role. Like, this is an expectation of your role; you're going to take breaks. You're going to step away for lunch. You're going to stick to a certain set of hours in terms of having like an eight-hour workday with a healthy lunch break in there. I think that's a really good idea. On the Boost team, I have found that people have adopted the habit of not always but typically sharing of, like, "Hey, I'm stepping away for a coffee break," or "I'm having lunch. Maybe like a late lunch, but I'm taking it," Or "I am stepping away for a walk." You often see later in the afternoon where there are a number of people that are then saying, "Hey, I'm going for a walk." And I feel that definitely helps me when I see it every day to reinforce like, yes; I should do this too because I already admitted I'm bad at this. So it helps reinforce it for me when I see other people saying that as well. But then I can see that that takes time to build that into a team's culture or to find easy ways to share that. So just putting it upfront in like a role expectation also feels like a really good place to then highlight and then to reinforce it as then people are setting that example. ROB: One thing that Nick Charlton tried to introduce was a Strava group. There's a thoughtbot Strava group. So you can see if people are members of it that they've been walking and things like that. It was quite an interesting way to automate it. I think it fell off a cliff. But it was something that we did try to how can we make the visibility of this a little bit easier? But yeah, the best thing I've seen is, like you say, having that notification in Slack or somewhere where you can see that other people are stepping away from their keyboards. STEPH: Well, as you mentioned, solving people problems is totally easy, you know. It's a totally trivial task although I'm sure we could spend too many hours talking about it. All right, so I do have one more very important question for you, Rob. And this goes back to a debate that Chris and I are having, and I'd love to get you to weigh in on it. So there are Pop-Tarts, these things called Pop-Tarts in the world. And I don't know if you're a fan, but if you were given the option to eat a Pop-Tart with frosting or a Pop-Tart without frosting, which one do you think you would choose? ROB: That's an interesting question. Is there a specific flavor? Because I think that the Strawberry Pop-Tart I would have with frosting but maybe the chocolate one I have without. I know there are all sorts of exotic flavors of Pop-Tarts. But I think I would edge towards with frosting as a default. That's my undiplomatic answer. STEPH: I like that nuanced answer. I also like how you refer to the flavors as exotic. I think that was very kind of you [laughs] other like melon crushed or wild flavors that they have. Awesome. All right. Well, I think that's a perfect note for us to wrap up. Rob, thank you so much for coming on the show and for bringing up all of these wonderful ideas and topics and sharing your experience with Codespaces. For folks that are interested in following your work or interested in getting in touch with you, where's the best place for them to do that? ROB: Yeah, thank you so much for having me. It's been fantastic to have a chat. If people do want to find me, the best place would be on Twitter. So my handle on Twitter is @purinkle which I understand is hard for people to maybe understand via a podcast, but we'll put a link in the show notes so people couldn't find me more easily. And that's probably also a good time to say that I am actually trying to find a development team lead to join our Launchpad II team. So we are looking for somebody who lives in Europe, Middle East, or Africa to join our team as a developer and manager of two to three people. There's more information on the thoughtbot website, and I do tweet about it very, very often. So feel free to reach out to me if that's of any interest to you. STEPH: Awesome. We'll be sure to include a link to that in the show notes as well. On that note, shall we wrap up? ROB: Yeah, 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: Byeeeeee!!!!!! 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:01:52] Ben introduces himself and tells us about a configuration he did with Docker. [00:09:24] Find out what GitHub Codespaces is all about. [00:18:20] Ben explains the demo he did on how to create a new repository. [00:22:56] Andrew tells Ben he feels like he might know how to set up a home network somehow, and what does Ben have to say about this?[00:26:01] Ben asks the guys if they're using VSCode.[00:28:06] We learn how Ben and Andrew feel about the state of VSCode Ruby Extension.[00:31:03] Andrew talks about the RubyMine debug functionality and working with the new debug gem.[00:34:27] Ben wonders if Chris has tried the Vim extension in VSCode, Ben tells us about something that was added, and Andrew tells us he just started doing an online course learning Vim and VSCode.[00:39:08] Andrew asks Ben if there are any big cons with this remote kind of development environment that he's got running, and a conversation about VSCode app on the iPad. [00:42:09] Find out where you can follow Ben and his adventures online.Panelists:Jason CharnesChris OliverAndrew MasonGuest:Benjamin WoodSponsor:HoneybadgerLinks:Ruby Radar NewsletterRuby Radar TwitterAndrew Mason WebsiteBenjamin Wood TwitterBenjamin Wood-GitHubHintGitHub CodespacesInoreaderProject Template- Benjamin Wood (GitHub)Dotfiles-Benjamin Wood (GitHub)JetBrains Remote DevelopmentSolargraph

Joining Brittany to celebrate episode 400(!), Collin Jilbert is a Ruby on Rails Developer at GoRails. They discuss why he committed to Rails so early in his career, his various ambitious projects (Ruby Radar, fleur de ruby), his love of the community and what his new role will entail. Show Notes & Links: fleur de ruby (@fleurderuby) (https://twitter.com/fleur_de_ruby) Ruby Radar (https://rubyradar.dev/?via=twitter-profile-webview) GoRails (https://gorails.com/) Jumpstart Pro (https://jumpstartrails.com/) pay-rails/pay: Payments for Ruby on Rails apps - GitHub (https://github.com/pay-rails/pay) Collin (@collin_jilbert) (https://twitter.com/collin_jilbert) Sponsored By: Hook Relay (https://www.hookrelay.dev/) Hook Relay is a service that makes sending and receiving webhooks reliable, secure, and transparent—automatically. Sign up now, and you can start receiving webhooks from integrations like GitHub, etc., even before you have an app to receive them. JetBrains RubyMine (https://jb.gg/rubyonrailspodcast) RubyMine is an intelligent cross-platform IDE for Ruby and Rails developers. Head over to jb.gg/RubyOnRailsPodcast (https://jb.gg/rubyonrailspodcast) for a 20% discount on a JetBrains IDE of your choosing and a chance to win a one-year personal subscription. This offer will be valid for one month following the release of this episode.

Links: Github main site: https://github.com/ The Open Guide to Amazon Web Services:https://github.com/QuinnyPig/og-aws Slackhatesthe.cloud: slackhatesthe.cloud Global Diversity CFP Day: https://www.globaldiversitycfpday.com/ Twitter: https://twitter.com/deniseyu21 Personal site: deniseyu.io TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Cloud Economist 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: This episode is sponsored in part by Thinkst. This is going to take a minute to explain, so bear with me. I linked against an early version of their tool, canarytokens.org in the very early days of my newsletter, and what it does is relatively simple and straightforward. It winds up embedding credentials, files, that sort of thing in various parts of your environment, wherever you want to; it gives you fake AWS API credentials, for example. And the only thing that these things do is alert you whenever someone attempts to use those things. It’s an awesome approach. I’ve used something similar for years. Check them out. But wait, there’s more. They also have an enterprise option that you should be very much aware of canary.tools. You can take a look at this, but what it does is it provides an enterprise approach to drive these things throughout your entire environment. You can get a physical device that hangs out on your network and impersonates whatever you want to. When it gets Nmap scanned, or someone attempts to log into it, or access files on it, you get instant alerts. It’s awesome. If you don’t do something like this, you’re likely to find out that you’ve gotten breached, the hard way. Take a look at this. It’s one of those few things that I look at and say, “Wow, that is an amazing idea. I love it.” That’s canarytokens.org and canary.tools. The first one is free. The second one is enterprise-y. Take a look. I’m a big fan of this. More from them in the coming weeks.Corey: This episode is sponsored in part by VM Ware. Because lets face it, the past year hasn’t been kind to our AWS bills or, honestly, any cloud bills. The pandemic had a bunch of impacts. It forced us to move workloads to the cloud sooner than we would otherwise. We saw strange patterns such as user traffic drops off but infrastructure spend doesn't. What do you do about it? Well, the CloudLive 2021 Virtual Conference is your chance to connect with people wrestling with the same type of thing. Be they practitioners, vendors in the space, leaders of thought—ahem, ahem. And get some behind the scenes look into the various ways different companies are handling this. Hosted by Cloudhealth by VM Ware on May 20th the CloudLive 2021 Conference will be 100% virtual and 100% free to attend. So you really have no excuses for missing out on this opportunity to deal with people who care about cloud bills. Vist cloudlive.com/corey to learn more and save your virtual seat today. Thats cloud l-i-v-e.com/corey c-o-r-e-y. Drop the “e,” we’re all in trouble. My thanks for VM Ware for sponsoring this ridiculous episode.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by Denise Yu, who's a senior software engineer at a company that mispronounces itself as GitHub, but it's actually pronounced Jif-ub. Denise, welcome to the show.Denise: Thanks so much for having me, Corey. I am excited to scream in some clouds with you.Corey: Yes, and I do want to point out that Jif-ub is not accepted by the Jif-ub marketing team, and they're upset. But that's the nice thing about this being my show; they don't get to dictate the nonsense that I say. But this is not you endorsing my correct pronunciation, as an employee, in any way. Because that's not your role. You're a senior software engineer. What do you do?Denise: So, I work on a bunch of different things. I actually originally joined GitHub back in March at the beginning of this global pandemic that we're still living through, somehow, in the year 2021. But I joined a year ago to work on a team called ‘Community and Safety.’ That team has been rolled into other teams by this point, partly because the original team did too good of a job at creating abuse prevention tools for the platform. But these days, I still work on community-facing tools, which is very exciting. I'm actually in a department called Communities. And our whole charter is to build tools that make life better for open-source maintainers. So that's a mission that I'm actually really excited about. I think [laugh] of all the products that I've worked on, this is one of the few that I can say I actually really want to make life better for the end-users. [laugh].Corey: Oh, absolutely. For better or worse, GitHub—or Jif-up—has taken a central role in the open-source community. And on some level, I find it—how do I frame this—kind of weird in that we've taken this protocol that is widely decentralized, and that's its entire point. Well, what do we do about this? Oh, immediately, we're going to re-centralize it. That's the right answer. And it just never ceases to amuse me that that's what we have taken from it as a society. But it works. I can't argue otherwise. And I maintain—and this is a bet that I am definitely going to the wall with—that in five years or so we are going to look back at Microsoft acquiring GitHub as a transitional moment.Denise: Yeah, I think so. I think even though the Git technology is built for resilience and distributed work, I think what GitHub as a platform has shown that the process of building software is more than just pushing lines of code. The code is the artifact of collaboration, but we still need a place to do that collaboration, which is why—I’ve been using GitHub for five or six years now, and I only realized a few years ago that things like pull requests and issues don't exist outside of GitHub. That's an abstraction that's so, so deeply baked into my idea of what it means to work collaboratively. That didn't exist until GitHub invented it, which is pretty wild.Corey: Yeah, it's bizarre in a number of different levels. But so much of what we think is part of Git is not. It is the GitHub abstraction, but it's also something that is widely copied by all of GitHub’s competitors, in many respects. So, the line has gotten very, very blurry. And how people come to Git is also fascinating. I used to go to a Git training, I think in 2009, conducted by a GitHub employee—I may be misremembering the year by a few years in either direction—and it was a multi-day process, and it was complex, and I left it feeling in many ways that I had more questions than I answered. Now, I point people to a GitHub page that talks about how to use Git, and they're mostly there. So, it isn't that Git necessarily has improved as a product, it's that GitHub has made it far more accessible. And let's face it, after a few million times practicing, you get very good at explaining complicated things in simple ways.Denise: Oh, yeah. For sure. It's not a huge surprise that internally, we use GitHub for everything. So, if you want to, I don't know, collaborate on writing a—even a new blog post, new marketing copy, or new documentation, all of that happens through GitHub. And I think that people with different levels of proficiency with command line—actually these days, you don't even need command line. You do everything through the UI, which I think is pretty neat.Corey: Oh, it's phenomenal. And I do want to call out that I am the maintainer of an open-source project on GitHub. We know it's good because it has [28.3000 00:06:18] stars; at the time of this recording, almost 3000 forks. And what it is, is the “Open Guide to AWS” it's a big markdown document that more or less explains what all of the AWS services do. There are over 200 contributors, we have an online Slack community at slackhatesthe.cloud because they don't like open-source community stuff very well, and we make fun of them for it. But my point being is that even without knowing how to write a single line of code, this is more or less just a big readme that explains different aspects of what AWS is because it's incredibly hard to adjust to that. And that is every bit as much an open-source project as anything that's included in NPM, or any command line tool that you'll use in any aspect of your job.Denise: Yeah, exactly. And I think the nice thing about editing a document like an AWS Guide, or anything else, really. A couple years ago, I would have said, “Okay, that sounds like it should be a wiki page.” Wiki pages support revisions, collaboration—or maybe a Google Doc or something. But the nice thing about putting it somewhere like GitHub, is like, well, you're already—probably all your other tools already integrate into GitHub. Like, you maybe get Slack notifications, when you have a PR requires review, or whatever it is. It's just so much easier to have everything in one place. And you also get the cool green squares for contributing. [laugh].Corey: Oh, of course, the most important thing is fill that thing up. It’s—talking about gamification causing weird behavior patterns. Yeah, we have a GitHub workflow on this, that fires off on every pull request that looks at the entire site, and validates the thousand and some odd links are still resolving and valid because when you link to this many different sites across the internet, link rot’s a real thing, and it's depressing and sad to be able to look at this and, “Oh, that didn't work.” Now, we do have to fix some of this because it winds up, in some cases, flagging people's submitted pull requests as not being valid, but it has nothing to do with what they're submitting because I'm bad at this. But the fact that that's built in and is available for use is incredible. Every time I look at GitHub’s site, it's gotten better than the last time I looked at it.Denise: Oh, that's so nice.Corey: Well, can't shake the feeling that at some point, there's going to be at the proper moment, a deploy to Azure button that as soon as someone clicks, whatever they've written is suddenly running in some environment in Azure. Now, if it comes too soon, it's going to be terribly implemented, and no one's going to trust it; if it comes too late, then people will already have solved this problem in different ways, so timing is going to be critical. But that is going to be—well-executed at least—a potential sea change in how people approach Cloud and what the default environment to run something on it.Denise: Wait, have you looked at Codespaces? Or seen the demo around that?Corey: I was hoping you would bring those up. Back in the before times, I would travel kind of a lot. And the only computer I brought with me was my iPad.Denise: Mm-hm. Yeah, a lot of people do this.Corey: Oh, yeah. Trying to get a environment on an iPad, it turns out, it's not terrific. The solution that I fell back to was, well, I've been using VI for 20 years, so I'll just SSH into an instance and call it good. But there were interesting projects of varying degrees of success that would run VS Code in a instance somewhere and then just present its interface as a web page. GitHub has actually integrated this as a core offering: all right, you click a button, it spins it up, and it's there. Denise: Yep.Corey: And oh, my God, is that better.Denise: Yeah. I think it's still in limited beta. So, I think you still have to request access to it—I don't know if this will still be the case in March, but yeah, I've tried it out a couple of times, and it works really, really well. My only gripe is that I don't like to use VS Code, so I'm going to have to learn VS Code in order to use it.Corey: I've got to say that is my single biggest barrier to adoption. I already know how to use VI, but a lot of the VS Code stuff, of you having a full featured IDE that does all of these things, is extraordinarily heavy of a lift for me. It more or less is breaking 20 years of muscle memory.Denise: Yeah. Tons of my co-workers love VS Code and use it every day. I only know how to use RubyMine for, [laugh] like, large monolithic Ruby development. And if I'm not doing work on the monolith, I don't want to use an IDE otherwise; I want to just use VI. I'm working in a small enough codebase where I know the name of every file, then I don't want to use the IDE for it. The VS Code to me sits in this middle ground that I know I need to learn how to exist in that middle ground, but it requires me going off to the internet and hunting down every single plugin that I need to put onto VS Code to make it feel like RubyMine again. And that's the thing that I don't want to do.Corey: Well, I'll take it a step further, and most of the tutorials I see about how to get up with VS Code as an IDE are JavaScript based—or YavaScript. [unintelligible 00:11:01] pronunciation once again—and my lingua franca is crappy Python. So, whenever I look for, oh, I want a VS Code tutorial for Python, the first eight pages of it are here the different ways you can do virtual environments and dependency management because that is Python. It focuses on that, and it winds up getting hung up on those implementation details before ever getting to, “Here's a reasonable Python project that someone who's not very good at Python can understand, and here's how VS Code can add value to it.” I mean, those posts exist, but they're hard to find. And it honestly makes me feel like an imposter for not knowing JavaScript.Denise: Yeah, the feature that I use the most in a full IDE like RubyMine is command-click to go to definition. And with Ruby, you get the correct definition about 70 percent of the time, but it's still better than nothing. Because if I'm not doing that, I'm doing a full text search for the method definition, and that's like—my brain can only work with one of those two things. With VS Code, after 15 minutes of trying to find the right plug-in that does click to go to definition and failing, I was just like, this is just not worth it. Nobody should have to live through this much pain. [laugh]. I don't want to do this anymore. [laugh].Corey: Exactly. It becomes this situation where at least when you're starting to learn something, it's breaking everything you're used to, and it feels like instead of helping you, you're fighting with it.Denise: Yeah, this reminds me of how people talk about switching their keyboard layout to Dvorak, or whatever—Corey: Oh, my God. I want to do that on one hand because I'm deep into the mechanical keyboard space. But on the other is, I don't really have six months to teach myself to type all over again.Denise: Yeah, that's the thing. It's like, maybe it'll speed up my typing by, like, two percent. But I already type really fast. I think I would have extremely diminishing returns on that. But also, I don't want my brain to just not work for weeks or months. Corey: Oh, it is worse than that because as soon as you leave that and go on to someone else's computer—which admittedly is not nearly as frequent as it used to be when I was in help desk and desktop support—“Oh, can you type in your password on this thing?” “Absolutely not. Thank you for asking.” It's effectively having to go back and restart it over. I understand that it's more efficient, but you need a societal shift to it, not individuals doing it piecemeal.Denise: Yeah, that's true.Corey: So you're relatively recent, as far as hires over a Jif-ub. You joined mid-pandemic, or early pandemic, depending on how you want to slice that, and you've never been to their headquarters. What is that like?Denise: Everyone keeps telling me how awesome HQ is like, and I’m like, “Cool.” I actually have a brick wall in my office that looks like some of the spaces in HQ, I guess, so people get super confused when I tell them that I'm in Toronto. Corey: Oh, yeah, I've been to HQ a bunch of times for various things. It's great. You’ve really—Denise: Yeah.Corey: —got to see it. I'm not helping, am I?Denise: [laugh]. You're really not helping. I really want to go to HQ. I was meant to go to HQ in March. So, my start date was March 13th, or 14th—I can't remember—in 2020. And I was part of the first onboarding class to not get to go out to HQ because that was when the travel restrictions around COVID were finally being implemented. So I'm very sad about that.Corey: I will say that GitHub has the advantage of a lot of other companies in that—to my understanding—they had a remarkably resilient remote culture before this all hit. Is that correct, or am I misremembering my history?Denise: No, you're right. I think the figure was 75 percent of employees don't live within commuting distance to HQ when I first joined.Corey: Well, not with that attitude.Denise: [laugh]. Yeah, that's true. We just got to try harder. But I think that number is a lot higher now because we have been hiring internationally. And we've grown a lot in the last year or so that I've been here. Yeah, so I think we were better equipped than a lot of other companies to go full remote because it basically just was telling that 25 percent of employees, “Don't come into HQ anymore.” And giving people a little bit more office budget, I guess, to get set up fully for full time remote work. There are a lot of challenges though, especially when you join as a remote employee and you've never worked in a fully remote environment before. It took me a really, really long time to get used to the fact that Slack was my portal to everything. Corey: Oh, yeah. Here at the Duckbill Group, we were full remote from the beginning, just because I decided to merge my consultancy with my business partner’s ten days before he moved from across the street to Portland, Oregon. So, we at that point decided, all right, we're full remote. And we've never had a critical mass of staff in one city to the point where they're became a de facto headquarters because as soon as that happens, it changes your culture. Trying to retrofit something like full remote to a company that historically has always been face-to-face, it shatters a lot of the dynamics. So, on some level it was easy for us. On the other, it feels like we're at a bit of a disadvantage in some respects, once things return to normal. But that's a future problem, unfortunately.Denise: Yeah, I think the biggest thing is learning to work asynchronously, which GitHub was already pretty good at. So I'm pretty used to opening a PR on Wednesday evening, for example, and not really expecting to get feedback on and until the next day, Thursday, or even Friday, especially if I needed a feedback from a different team. Actually, that's something that I've learned since joining GitHub; that wasn't something I was used to before because I've only ever worked in co-located environments before. Someone didn't review my PR in time, I would take a Nerf gun and go over to them [laugh] and gently ask them to [laugh] review my PR. But it's been very interesting. So, I also used to work at Pivotal, which I'm sure you've heard rumors about our kind of cultish pairing [laugh] culture. So, my default state of working was to constantly be talking to another human about what I was doing all the time. And so, suddenly joining a fully remote company in a time when we have to work a little bit more asynchronously than before because people's lives are just completely upended by this pandemic, that was a big adjustment.Corey: So, in the before time, something else that you were effectively renowned for was not only giving conference talks yourself, but helping other people give conference talks, too. Let's talk a little bit about that because speaking at conferences was always one of my passion projects because I love the sound of my own voice, simply love it. And helping other people do that, too, was also something I was very interested in doing, but it was always hard for me to get traction around getting people to let me help them for reasons that are probably blindingly obvious to everyone except me. So, tell me about that. What's the story?Denise: Yeah, so I have always been pretty comfortable speaking in public. I think it's something that I almost took for granted. And the reason for that is because I spent upwards of 10 years of my teenage and adult years doing competitive debate. It was traveling to debate tournaments pretty much every single weekend in college and spent a lot of time doing both structured and off-the-cuff speaking in front of large groups of people. And when I got into tech, it took me a long time to realize that not everyone is like me. I kind of had this special strand, I guess of imposter syndrome, where I think that if I know how to do a thing, then everybody else knows how to do that thing also. Which is aggressively not a correct assumption to make, ever. Corey: Oh, same here across the board. It's one of those I thought for a while I fit in tech because the stereotypes seem to fit me super well. It's like, yeah, “We're bad with people.” “Absolutely.” “We prefer dealing with computers to humans.” “Absolutely.” “I hate my boss.” “Absolutely.” “I'm good at programming…” “Oh… okay, never mind.” But yeah, there's a lot that I think people miss about what it takes to give a good talk. It's not technical mastery. It is an ability to tell a story.Denise: Exactly. I think you hit the nail on the head there. And so after I realized that, okay, I am, at least at the median. I actually think I'm quite good at public speaking and telling stories about technical subject matter, and breaking things down in a way that someone without as much technical context as me can understand it. The thing that got me into doing more and more public speaking, specifically at tech conferences was, after I gave my first talk, people just kept coming up to me, basically, and being like, “Hey, I saw you talk to this conference. Do you want to come talk at this other conference that I'm running?” or whatever. I think like, once you've got a couple of larger stage conference talks under your belt, you almost don't really have to look for speaking opportunities anymore.Corey: No, they fall into your lap. And then you have different problems such as, oh, I've been invited to speak at this conference. Let me do some checking to figure out are they a trash fire, or are they a reasonable place?Denise: Yeah. Am I going to be the only not white guy speaking at this conference?Corey: Am I going to be on a manel? I won't do it. Is there not a code of conduct that has actual teeth and doesn't read as a joke? I won't do it. And that stuff is way more important to me than the technical content of the talk.Denise: For sure. For sure.Corey: But tying it back to even the stuff that GitHub does, one of the talks that was transformative for how I approach this was a Git talk, “Terrible Ideas in Git.” And I like to teach people things by counterexample, and the first iteration of that talk would have been great if the Git maintainers themselves had been the target audience for this, but two people would have loved that and the rest of the audience would have been looking at this with what the hell are you talking about? So, I had to refactor it, and it made it a far stronger talk all the way to the point where there's jokes for everyone in there. But my favorite time giving the talk, I said that, “I now need to be able to explain Git in such a way that my mother would understand it. And that is a problematic way of framing on ageism and sexism basis in most cases, but not this time because she's sitting in the front row. Hi, mom.” That was one of my favorite speaker moments that was just, it's hard to get that one pulled off, mostly because getting my mother to fly to various parts of the world and watch me speak is a bit of a heavier lift than one expected. But here we are.Denise: Yeah, I use a similar litmus test for my stepdad. My stepdad is not a technologist. He is a biologist by training, actually. But he asks me a lot of questions about what I do. And back when I worked at Pivotal, I had to explain cloud virtualization to him every time I went home. [laugh]. I don't know if it's gotten easier. With GitHub, I feel like GitHub is a little bit easier to explain to the average person than Cloud Foundry. But my bar kind of is, every time I put together a talk, do I think that my stepfather could understand the content.Corey: This episode is sponsored in part by our friends at New Relic. If you’re like most environments, you probably have an incredibly complicated architecture, which means that monitoring it is going to take a dozen different tools. And then we get into the advanced stuff. We all have been there and know that pain, or will learn it shortly, and New Relic wants to change that. They’ve designed everything you need in one platform with pricing that’s simple and straightforward, and that means no more counting hosts. You also can get one user and a hundred gigabytes a month, totally free. To learn more, visit newrelic.com. Observability made simple.Corey: Increasingly, I found the best way to explain GitHub to folks who aren't familiar with it and are non-technical but work in the business space has been, “You know how Microsoft Word has track changes? Yeah, imagine that only without the copy-of-copy-of-file-final-use-this-one-date.bak.PDF.doc? Yeah, imagine that. Instead, this makes this streamlined and easy for multiple people to work on at the same time,” at which point they stare at you hungrily and say, “Oh, my God, how can I use this for my work?” And I feel like there's a breakout moment waiting for GitHub if they ever decide to focus on that part of the market because my God, is there an appetite for it?Denise: Yeah, I think like that kind of revision driven editing, I think that's applicable to so many different domains. I've heard people experimenting with the idea for—I think, Figma does something similar for designs for visuals, but I've also heard the idea floated of this being done for, like, sound mixing, sound engineering, which I think would be super, super cool. I don't know how you could visualize that, but someone who has more knowledge of that space, I'm sure could come up with a way.Corey: Oh, yeah, the challenge I find with stuff like that, for podcasts, for example, is GitHub gets very, very angry because Git gets very, very angry when you start doing things like checking in large uncompressed media files, and then making small changes to them, but you can't diff that so every revision for video work is, “Oh, here's another 150 gig file to put up,” and that becomes a problem.Denise: Yeah.Corey: Yeah, there's a lot that's neat out there. I also want to credit GitHub with fixing the state of working with Git because let's face it, Git makes everyone feel stupid at some point. The question is, is just how far along are you before that hits? And invariably, the approach was always, when you get into that territory, you wind up asking the question on some forum somewhere, and then you wind up getting a few minutes later, this giant essay where it starts out, “Well, Git is not really a version tracker, it's instead of distributed graph that”—and then you just skip down eight paragraph to the bottom where they give you the one-liner that fixes the problem. GitHub has fixed the result of queries for, “How do I X in Git?” And just gives you the answer outright. It's transformative, and it's one of the things that everyone takes for granted because no one really stops to think this documentation is awesome, and accessible, and answers my problem, but the result of it is, is that you just don't see people complaining about how hard Git is anymore.Denise: Yeah, yeah. Oh, my God, Git is so hard. I think the first-time I correctly did an interactive rebase—like, I typed all the arguments correctly. I think I just got up and did a lap around the office. [laugh]. There's just all this random stuff that you have to remember when you're using—especially some people use the desktop GUIs or whatever. I always just use command line. But it took forever and I still make a ton of mistakes with it.Corey: Oh, we all do. That's the beautiful part of it. The nice thing is, “Oh, well the nice thing about Git is that nothing ever really gets truly lost.” And you say, “Well, how do you figure?” “Oh, I copy the entire directory to a backup before I do anything.” Which is on the one hand, awful version control and, two, has saved my bacon multiple times. So, if it's stupid and it works, it's not really stupid, now is it?Denise: It's not stupid if it works. [laugh].Corey: So, a passion project of yours that I want to talk about has been teaching people to submit to conferences, to give talks at conferences, to convince them that yes, you can do this and you're good at it, you have a story that people want to tell, the things you find easy are not easy for everyone. ‘Give that story voice’ has been a recurring theme that you do. How has that manifested during this year of isolation?Denise: Ohh. This year’s definitely been tough. So, usually when I do that pitch, I run workshops specifically around a certain CFP. Like I help out conference organizers in the Toronto area. Like, I did a workshop for devopsdays last year, and another one for GoCon, also meant to be last year. And usually it's like, okay, here's how you write a strong proposal—and I'll have the committee in the room—and be like, here's what the committee is looking for; ask these people questions about what they would choose to program. And this is how you get your talk submitted. This is how you get accepted; you need to understand who your audience is. It's a product question. It's exactly the same mindset that you need to get into when you're playing product manager, or if you're actually a product manager. You need to understand who your target customer or audience is, what they're looking for, and how do you give that to them on a plate. This year, it's slowed down a lot, obviously because there have been fewer conferences, so I've just had fewer opportunities to do this kind of pitch without—it feels weird telling people to write talks without there being a place to submit a talk to. But I think—I found that there still is room for content creation, even if that isn't a conference talk. So, within the company, within my networks, I do try to encourage people to write blog posts. Err on the side of writing what you've learned; if you spent a couple days doing a technical investigation and you found it interesting, write it down so other people can learn about it. On the conference talk front, I think the unique benefit of doing conference talks and getting up on stage is you do build a personal brand. After a little while that kind of transcends the company that you're at, granted that you're not talking about your company's products in every single talk. Corey: Absolutely. And a lot of companies get profoundly insecure about that. And I'm sorry; they're wrong. That is not a bad thing. Anyone who gives a talk for your company will eventually become better known than your brand for some aspects and in some areas—harder at places like GitHub than it is Twitter for Pets, but that's okay—and you have to be okay with that and have a plan for how you're going to transition them out when they outgrow the role and move somewhere else. But that's okay. And companies that are insecure about that drive me up a wall.Denise: Yeah, there have been a few times when I went to very cloud specific conferences and talked about things that my company is working for, but other times, I've gone to just very general conferences where it was just like, let's talk about Agile, or let's talk about software, like super, super generally. And the ones who have gone to the really general conferences and talk about things that matter to me—like cross-functional collaboration, or test driven development, or whatever it is—those are the ones that I've actually managed to get people to apply to my company without even saying that we're hiring. It's a little mind blowing.Corey: It is. People want to work with interesting people, and when you find someone who's able to tell a story that touches you on some level, which is the point of telling stories, then at some point, the idea of I'd like to work with that person on ongoing basis becomes actively compelling. People ask so well, it's not like you could hire a whole lot of people who do what you do, so hiring and recruiting is going to be a problem. It's like, well, it is but it's because it's finding the right people with the right alignment, but we have an awful lot of candidates to choose from for basically any role, just because for better or worse, I make a splash.Denise: Yeah, exactly.Corey: So, as people are looking to get into the space and they're new to speaking, how do you get them to a point where there's at least a certain level of confidence? I would say, “How do you get them to not be terrified?” But I’ve been speaking almost full time for years, and I'm still scared to death every time I give a talk when I start out.Denise: Me too. I'm still terrified. I almost switch into a different persona when I go on stage, and I don't remember anything that happens. I don't know what—maybe there's psychology [laugh] around this, but I literally blank out the 40 minutes that I'm on stage. So, the most common objection that I hear about why someone doesn't want to give a talk is they'll say, “But everybody already knows about this. The thing that I want to talk about has already been talked about. There's already too much content out there. I wouldn't add anything new.” And for a long time, my response to that was just, I don't care. I still want to hear what you have to say, you're going to offer a fresh perspective, you're going to offer a new experience, you're going to explain something in a way that clicks for someone. Your explanation might be the one that works for them that they haven't been able to figure out by listening to anybody else. So, I historically said those things, and I still one hundred percent those things, and I still say those things to people but I actually came across something interesting on Twitter today. Someone was actually talking about fanfiction. I don't know if you’ve written or read fanfiction in the past. When I was a kid I used to—Corey: I can neither confirm nor deny…Denise: [laugh]. There’s varying levels of fanfiction out there. But fanfiction communities are actually incredibly collaborative places. I remember being, I don't know, like a 10 or 11-year-old and writing a lot of anime fanfiction, basically just writing myself into the Pokemon universe and things like that. And we would post these on forums. It'd be forums of strangers working together, and we’d post drafts. And then we would give each other feedback on those drafts. And in the end, there'd be 60 different pieces of fanfiction, roughly about the same universe, every story is a little bit different, and nobody was ever self-conscious that this had already been done. Because the whole point of fanfiction is that there's a lot of it, the value of the community is in the fact that the content is abundant. Not that every single piece of content is unique. So, I think a similar thing is true for content that's technical storytelling. Just because someone else has said this thing before, it doesn't matter. The fact that there's more content out there about this thing is good for the community, building a community around this thing. So, I don't know, that was something that just resonated with me a lot, and I just really liked that framing.Corey: We have this weird perspective that the things that we know are easy, the things we don't know are hard, so once you've learned how to do something, everyone else knows it. I mean, one of my most popular Twitter threads that exploded that I didn't see coming was just me talking about random things that live in my shell config file, and what they do. It's, “Well, this is stuff everyone knows, and everyone has something like this, right?” And it got into a dissection of what these things do, and how it works, and of course, it's snarky because that's my excuse for a personality, but it also shined a light on something that I forgot, once again: not everyone knows this. A lot of the viral tweets you see going around are people noticing something that we've all seen and been ignoring because that's just the way it is, and someone makes an observation about it and, oh, yeah, that's right. That is something that everyone can relate to.Denise: Yeah. Corey: People want stories.Denise: Yeah, exactly. I think about every six months, I try to retweet—every review cycle around mid-year, end-of-year. It’s like, “Hey, just a reminder, if someone on your team has done something for you write this down. Catalog what they did, write it down, send it to them, send it to their manager, put it into their file so they can use it at review time.” And every time I talk about this, I always get a ton of engagement. And I have to remind myself that this is not obvious. Even if someone was told to do this at some point in the past, reminding people to be deliberate and be active about giving each other peer feedback, writing stuff down. You just can't remind people to do that enough, I think.Corey: Yeah, it's one of those things where, “Well, I've already given that talk, so I have to give a different one.” No, you don't, I promise you, you have not given your talk to everyone in the industry, and the reason I know that is because by that point, you would see the view count on YouTube or whatnot—or the video winds up—and be flabbergasted because the industry is bigger than anyone thinks. I feel like I tell the same joke from time to time, but they always get laughs from the audience because it's new to them. My business partner and my romantic partner find it incredibly challenging, both—those are two people, incidentally—they find it incredibly irritating because, “Yes, yes, we've heard that one.” And every once a while they sit up, “Oh, Corey got a new joke.” But the rest of the world doesn't respond that way.Denise: Yeah, exactly. So, I don't know if we've talked about this already, but that closes the loop on the whole imposter syndrome piece where—just because I think one strain of imposter syndrome is telling yourself, just because I know this thing, means everybody else must also know it. I must be the last person in the world to learn this piece of information.Corey: There is no piece of technology, or anything even tangentially related to technology, that you couldn't do a tweet thread on and people would learn things about it. How an if-then-else loop works, for example. That is—sorry—ahh—do you see what I'm talking about? That's exactly what I mean. See, I meant to say ‘Conditional,’ and instead I said ‘Loop’ and we all trip over these things; they're all challenging, and the fact that we can still learn new things about that of, how does a flow control conditional actually work? What does that mean? Sure, anyone who spends their days writing code all the time is going to have some topical understanding of it, but not everyone's going to, first, be that person, or secondly, understand why that's valuable and relevant. You could do an entire conference talk on nothing more than that concept alone and it would be a dynamite talk.Denise: Yeah, exactly. I did go through a wave of imposter syndrome around last year, or maybe—uh, I don't even know what year is it. [laugh]. A little while back, I was feeling uncertain about this talk about distributed systems that I've done a few times. And then I got a random message on Twitter from a student who told me that she had just gotten her first engineering role out of university—ever, ever—and she said, I watched your talk on distributed systems; you gave me the vocabulary to talk about this stuff in an intelligent way, and I've landed my first role as an entry level—I forget exactly what kind of engineer but—I mean software engineering—but I forget if it was like infrastructure, or app dev, I don't know. But it was like, that kind of feedback, just—that's really cool to hear.Corey: I'm going to take it a step further and request anyone listening to this who’s seen the talk that has potentially changed the way they view things or helped them advance in their career, track down whoever gave that talk and send them a message. One of the hardest parts about being a speaker is that you very rarely get feedback. I mean, even on this podcast, I almost never get direct feedback online. People talk to me about it in person, when they run into me at a conference, in the before times. But it's not a thing where people wind up drafting an email, “Dear sir, I found your podcast to be compelling, and also you are a jackass.” I would love letters like that.Denise: Well, I don't love letters like that, so please don't write me letters like that. [laugh].Corey: Well, in my case, they're well-deserved. In your case, it would just be offensive.Denise: [laugh]. But yeah, reach out to those strangers whose content you've learned from, I think it can actually make someone's day.Corey: Absolutely. So, on the other side of that, if someone's listening to this, and they want to start giving a talk, but they don't know where to start, how to build a CFP, where to begin, where should they start? What is the next step for those people?Denise: So there's an initiative that I, in the before times, mentored and helped organize local chapters for. It's called Global Diversity CFP—it's either Global CFP Diversity or Global Diversity CFP, I always forget—day. And even if you're not a person who has a marginalized identity, they've done a really, really great job of consolidating a bunch of resources to get first-time speakers off the ground.Corey: And we will put a link to that in the [show notes 00:36:34], of course.Denise: Cool. So, I recommend reading through what they have. So it's actually an event that take place on a full day; it's a little bit different this year, I think they might be running it remotely this year. But all of their content is geared for first-time speakers, and they have a lot of material that's pepping people up to take the first step. But I would say that beyond that, the best way to get started, honestly, is to just pick a topic that you care about, and just try to write a talk. And if you don't have a place to deliver that talk—if there's no meetup, or conference or anything coming up, you should just record yourself giving the talk to your computer, actually. This is the thing that my debate coach used to have us do in college: the best way to improve as a speaker is to record yourself speaking and watch it. It's going to be terrible the first few times because you're going to be like, “Oh, God. I look so awkward.”Corey: Power through it. I still can't watch myself speak.Denise: [laugh]. Like, what are my hands doing? But you can only catch those things and improve at them once you're aware that you're doing them. So, that is the fastest way to improve your presence and your speaking ability.Corey: Yeah. I want to thank you for taking the time to speak with me and go through all these various topics today. If people want to learn more about you, where can they find you?Denise: So, you can find me on the internet on the cursed blue website at @deniseyu21 is my handle on Twitter. My personal website is deniseyu.io because—I used to have .com but some kids stole it and squatted on it after I forgot to renew it. So I'm not deniseyu.com anymore.Corey: Yeah, the joy of changing usernames on different platforms and the rest. I hear you.Denise: Yeah. Yeah, probably those two places. If you want to talk about anything that I talked about on the podcast, feel free to DM me on Twitter. Please don't send me mean feedback that starts with “Dear sir,” in my Twitter DMs, but other than that, I—Corey: Generally never a good plan for anyone.Denise: [laugh]. No. Corey: Thanks so much for taking the time to speak with me. I really appreciate it.Denise: Yeah. Thanks so much, Corey for having me on. It was a lot of fun. I feel like we covered a lot of ground. Probably too much. [laugh].Corey: It really was. And we did. Denise Yu, senior software engineer at Jif-ub. 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 a comment containing a correctly formatted Git rebase command.Announcer: This has been this week’s episode of Screaming in the Cloud. You can also find more Corey atscreaminginthecloud.com, or wherever fine snark is sold.This has been a HumblePod production. Stay humble.

Jason is back and fills us in on how his move went to his new home. Then, the guys dive into talking about the cool new features Laravel 8 is going to have. We will also learn a little more about the new version of Spark. Other topics discussed are Paddle, Rightward assignments in Ruby, View Components for the Primer Design System, RubyMine and Prettier. Find out why Andrew said, “TypeScript is winning!” Download this episode now to find out more!

Natalie Kudanova is a product marketing manager for JetBrains RubyMine, an IDE for Ruby and Rails developers. She helps the RubyMine team understand the needs of their users. In this short episode, she and Brittany discuss the best way to reach Ruby developers and IDE innovations.

Natalie Kudanova is a product marketing manager for JetBrains RubyMine, an IDE for Ruby and Rails developers. She helps the RubyMine team understand the needs of their users. In this short episode, she and Brittany discuss the best way to reach Ruby developers and IDE innovations.

스탠다드아웃 70번째 로그에서는 ODK 주니어 개발자 오엔 님을 모시고 주니어 개발자에 대한 이야기를 나눴습니다. 게스트: 오엔 참가자: @nacyo_t, @raccoonyy, @seapy 정기 후원 - stdout.fm are creating 프로그래머들의 팟캐스트 | Patreon 주제별 바로 듣기 00:00:00 70번째 에피소드 시작 00:07:10 단신: MS Teams SSL 인증서 만료로 장애, 유튜브 매출 공개, 44BITS 홈브류 글 00:20:20 주니어 개발자 오엔 님 단신 Microsoft Teams goes down after Microsoft forgot to renew a certificate - The Verge Slack CEO Stewart Butterfield: Microsoft Teams has ‘weak engagement’ AWS Certificate Manager - Amazon Web Services(AWS) 스탠다드아웃_068.log: 루비 2.7 릴리스, IRB 개선, 루비의 미래, RubyMine 등 w/ 펭귄 | 개발자 팟캐스트 stdout.fm stdout_001.log: 루비 25주년, Github 장애 | 개발자 팟캐스트 stdout.fm 아마존의 효자 AWS…”총 매출 11%, 영업이익 73% 기여” | 연합뉴스 유튜브 광고 매출액 첫 공개…지난해 18조원(종합) | 연합뉴스 홈브류(Homebrew)란? | 44BITS 기술 블로그 주니어 개발자 오엔 님 패스트캠퍼스 - 커리어 성장을 위한 최고의 실무교육 아카데미 멋쟁이사자처럼 :: LIKELION Eunhyang Kim, Developer at Odk media | SlideShare 2019 Summer Coding - 여름방학 스타트업 인턴 프로그램 | 프로그래머스 Arduino - Home ODK media Careers - BambooHR

스탠다드아웃 68번째 로그에서는 펭귄 님을 모시고 루비 2.7 릴리스, IRB 개선, 루비의 미래, RubyMine 등에 대해 이야기를 나눴습니다. 단신 스탠다드아웃_067.log: RDS 인증서 업데이트, 파이썬 2.…

스탠다드아웃 68번째 로그에서는 펭귄 님을 모시고 루비 2.7 릴리스, IRB 개선, 루비의 미래, RubyMine 등에 대해 이야기를 나눴습니다. 게스트: @say8425(펭귄 님) 참가자: @nacyo_t, @raccoonyy, @seapy 정기 후원 - stdout.fm are creating 프로그래머들의 팟캐스트 | Patreon 주제별 바로 듣기 00:00:00 68번째 에피소드 시작 00:01:35 단신: RDS 인증서 업데이트, EKS 요금 인하 등 00:13:08 게스트 펭귄 님 소개, 루비 카이기 00:26:02 IRB 개선 00:41:35 루비 2.7 그 외 변경 사항들 00:54:33 루비의 미래: 루비 3.0 01:02:28 루비 IDE RubyMine 단신 스탠다드아웃_067.log: RDS 인증서 업데이트, 파이썬 2.7 지원 종료, 스톡옵션 등 | 개발자 팟캐스트 stdout.fm 아마존 EKS(Amazon EKS) 50% 요금 인하 발표 - 시간당 0.10 USD | 44BITS 기술 블로그 G Suite Updates Blog: Manage Windows 10 devices through the G Suite Admin console Facebook: The Inside Story: Steven Levy: 9780735213159: Amazon.com: Books INSIGHTBOOK on Twitter: “Hackers의 지은이 스티븐 레비(Steven Levy)가 페이스북을 다룬 책 집필… 루비 카이기 RubyKaigi 2020 RubyKaigi 2020 - RubyKaigi | Doorkeeper RubyConf 2019 AWS re:Invent 마쓰모토시 - 위키백과, 우리 모두의 백과사전 북알프스 등산 | 마츠모토에 가보자 루비 2.7 릴리스 stdout_001.log: 루비 25주년, Github 장애 | 개발자 팟캐스트 stdout.fm 루비 2.7.0 릴리스 (일본어) 루비 2.7 여기에 주목! 패턴 매치, 컴팩션GC 등 릴리스 매니저에게 들어보았습니다 - 엔지니어허브 Announcing Office Scripts (Preview) - Microsoft Tech Community - 1093559 IRB 개선 The GNU Readline Library 루비(Ruby) 콘솔(IRB, PRY)에서 한글 입력하기 | 오늘부터 seapy는 Read–eval–print loop - Wikipedia pry/pry: A runtime developer console and IRB alternative with powerful introspection capabilities. Jupyter and the future of IPython — IPython ruby/reline: The compatible library with the API of Ruby’s stdlib ‘readline’ What’s new in Interactive Ruby Shell (IRB) with Ruby 2.7 – Saeloun Blog pasting in multiline irb is slow · Issue #43 · ruby/irb (일본어) RubyPrize 2019｜최종 선정작 발표 How to update an anomaly detection monitor to account for local time zone 그 외 루비 2.7 관련 변경 사항 이야기 프로그래밍 언어 루비(Ruby) 2.7 릴리스 및 주요 변경 사항: 패턴 매칭 문법, REPL 개선, 위치 인자와 키워드 인자 분리, 번호 파라미터 등 | 44BITS 기술 블로그 Separation of positional and keyword arguments in Ruby 3.0 Feature #16123: Allow calling a private method with self. - Ruby master - Ruby Issue Tracking System Feature #4475: default variable name for parameter - Ruby master - Ruby Issue Tracking System Feature #14240: warn four special variables: $; $, $/ $ - Ruby master - Ruby Issue Tracking System Feature #14912: Introduce pattern matching syntax - Ruby master - Ruby Issue Tracking System Patterns — The Swift Programming Language (Swift 5.1) AWS 람다(AWS Lambda) 커스텀 런타임 만들기(feat. 루비 2.6.0) | 44BITS 기술 블로그 Feature #14799: Startless range - Ruby master - Ruby Issue Tracking System Ruby의 미래: 2020년 3.0 릴리스 예정 RubyConf 2019 - Opening Keynote - Ruby Progress Report by Yukihiro Matzumoto (Matz) - YouTube LaTeX - Wikipedia React v15.0 – React Blog A Type-level Ruby Interpreter for Testing and Understanding - RubyKaigi 2019 Sorbet · A static type checker for Ruby RubyMine after_commit (ActiveRecord::Transactions::ClassMethods) - APIdock RubyMine: JetBrains가 만든 Ruby on Rails IDE JetBrains: 전문가와 팀을 위한 개발자 툴 Chetan Puttagunta on Twitter: “JetBrains, a Prague based developer tools company…. JetBrains - Wikipedia TextMate: Text editor for macOS Ruby on Rails Screencasts - RailsCasts For Students: Free Professional Developer Tools by JetBrains

Mike rekindles his youthful love affair with Emacs and we debate what makes a "10x engineer". Plus the latest Play store revolt and some of your feedback.

Panel: Dave Kimura Charles (Chuck) Max Wood Nate Hopkins Special Guest: Dan Mayer In this episode of Ruby Rogues, the panel talks with Bozhidar Batsov who is the VP of Engineering at Toptal, and an Emacs fanatic. The panel and the guest talk about RubCop, Emacs, and Komodo, among other topics! Check out today’s episode for more details. Show Topics: 0:00 – Sentry.IO – Advertisement! 1:07 – Chuck lists the panelists and the special guest. 1:37 – Chuck: Why are you famous? 1:41 – Guest gives his background. 2:13 – Guest: I am passionate about Emacs. 2:55 – Chuck. 2:58 – Panel: I have on a few projects. Do you know RUFO? It’s a bit more opinionated than RuboCop. 3:25 – Guest: I am familiar with RUFO and their approach is similar to JavaScript called Pretty or something like that. 4:45 – Guest: 4:49 – Panel: Can you tell us what RuboCop is and why is it important? 5:00 – Guest: There are a few main things that RuboCop is: 1.) Placement for Ruby minor... 2.) Lint tool 3.) Automatic checker for all the best practices outlined in the community 4.) Formatter for Ruby code – you can feed it ugly code and it will spin out beautiful code 7:30 – Panel: What are the origins of the project? Where you interested in the performance and security aspects of it? 7:49 – Guest. The guest talks about RuboCop in detail. 10:59 – Panel: It’s important to remember that these are just guidelines and they are NOT set in stone. Using single or double quotes. As long as the project is consistent and using decent practices then I am okay with the code. I will disable the...in RuboCop. Today with high-resolution monitors it’s one of those things that are an annoyance to me. It’s just my opinion, though. 12:07 – Guest: Why disable it and not...? 13:36 – Panel: You could use VS code instead of Emacs! I am just kidding. 13:51 – Guest: I hope you are kidding! 13:56 – Chuck: I cannot live without this code... 14:06 – Guest. 14:26 – Panel: I was an early adapter from the beginning and it was hella slow. I tried it from sublime text and I got annoyed so I eventually switched to VS code. Once I got over the brand name, I really like it as my main editor. 15:20 – Panel: Maybe it’s more approachable and it’s easier to dip your toes in. 15:35 – Guest. 16:29 – Panel: I haven’t heard of KOMODO in long time. I remember that was one of the first IDs that I had checked out. I tried that then went to Ruby Mine and then tried Sublime text and then VS. 16:57 – Guest: Komodo was a famous editor. 17:17 – Panel: I am curious on RuboCop that the adaption is driven by teaching idiomatic Ruby to people new to the language? 17:40 – Guest: I don’t think it’s much about the stylistic stuff at this point. I also noticed that the main driver of the group was... Guest goes into great detail about this topic.  22:44 – Guest (continues): RuboCop offers a bunch of different structure. 24:27 – Guest (continues): We are wondering how to approach the issue of performance. The performance aspect tended to be trickier than what we had expected. The majority of developers when given the choice to either secure or make something convenient - they will choose the latter option. 25:47 – Panel: That’s why they get hit with a high AWS bill. 26:00 – Guest. 26:30 – Panel: The things you have learned with RuboCop, is it changing the direction with MRI or the design of the language at all? 26:40 – Guest: I would hope so, but I don’t have hard evidence to prove this. If you give people too many options then it could be a waste of time. I don’t care about the nuances. 30:06 – Ad: RubyMine! 30-day trial! 30:38 – Panel: Would you recommend the Rails style guide if you are building a Rails style project? Should we use that as a baseline and then customize it for your team? 30:55 – Guest: The style guide should be good. For a while I was the only editor. Not a lot of the options that are there aren’t my personal opinion, but it’s the general prescription. If you have strong preferences and you have your team agree on those then it’s okay to be modifying it. At the end of the day it’s better to have consistency within a project. You are doing great! 32:57 – Chuck asks a question. 33:44 – Chuck: Could I modify a rule? 33:53 – Guest: There are varying degrees to the rule. 35:56 – Panel: One of your conference talks you talked about the future of Rails and the future of other Ruby frameworks? 36:18 – Guest: I am worried about the future of Ruby b/c I see people talking about the maturity of the system but there isn’t a clear vision to where we are going. There are some cornerstones for Ruby 3 that he is repeating. 41:05 – Guest (continues): I think we need to commit to the module and the API. 45:42 – Chuck: All of those things make sense to me. Is there any desire for people to fork Ruby or pulling / putting some of this in? 46:00 – Guest. 48:18 – Panel: Transition that to Rails and the future of Rails? 48:27 – Panel: There are big companies that are making changes. 48:51 – Guest. 53:33 – Panel: I think that is a common pattern that most companies move towards. 54:12 – Chuck: We did an episode on ElixirMix with Chris McCord. Check that out! 54:35 – Chuck: Picks! 54:40 – Advertisement – Fresh Books! End – Cache Fly! Links: Get a Coder Job Course Ruby Rust Ruby Motion Ruby on Rails Angular Komodo Emacs RuboCop RuboCop – GitHub Stimulus reflex Messages: Share Screens Smittybilt Visual Studio Code: Introducing Visual Studio Live Share VRBO Bozhidar’s GitHub Bozhidar’s Twitter Bozhidar’s Patreon Bozhidar’s Open Collective Past EMx Episode 020 with Chris McCord! Sponsors: Sentry RubyMine Cache Fly Fresh Books Picks: Dave Tire Plugs VS Live Share Nate Share Screen using Messages on Mac Charles VRBO Find opportunities for R&R Rocket League Bozhidar Documentation for Markdown users Bear App

Panel: Dave Kimura Charles (Chuck) Max Wood Nate Hopkins Special Guest: Dan Mayer In this episode of Ruby Rogues, the panel talks with Bozhidar Batsov who is the VP of Engineering at Toptal, and an Emacs fanatic. The panel and the guest talk about RubCop, Emacs, and Komodo, among other topics! Check out today’s episode for more details. Show Topics: 0:00 – Sentry.IO – Advertisement! 1:07 – Chuck lists the panelists and the special guest. 1:37 – Chuck: Why are you famous? 1:41 – Guest gives his background. 2:13 – Guest: I am passionate about Emacs. 2:55 – Chuck. 2:58 – Panel: I have on a few projects. Do you know RUFO? It’s a bit more opinionated than RuboCop. 3:25 – Guest: I am familiar with RUFO and their approach is similar to JavaScript called Pretty or something like that. 4:45 – Guest: 4:49 – Panel: Can you tell us what RuboCop is and why is it important? 5:00 – Guest: There are a few main things that RuboCop is: 1.) Placement for Ruby minor... 2.) Lint tool 3.) Automatic checker for all the best practices outlined in the community 4.) Formatter for Ruby code – you can feed it ugly code and it will spin out beautiful code 7:30 – Panel: What are the origins of the project? Where you interested in the performance and security aspects of it? 7:49 – Guest. The guest talks about RuboCop in detail. 10:59 – Panel: It’s important to remember that these are just guidelines and they are NOT set in stone. Using single or double quotes. As long as the project is consistent and using decent practices then I am okay with the code. I will disable the...in RuboCop. Today with high-resolution monitors it’s one of those things that are an annoyance to me. It’s just my opinion, though. 12:07 – Guest: Why disable it and not...? 13:36 – Panel: You could use VS code instead of Emacs! I am just kidding. 13:51 – Guest: I hope you are kidding! 13:56 – Chuck: I cannot live without this code... 14:06 – Guest. 14:26 – Panel: I was an early adapter from the beginning and it was hella slow. I tried it from sublime text and I got annoyed so I eventually switched to VS code. Once I got over the brand name, I really like it as my main editor. 15:20 – Panel: Maybe it’s more approachable and it’s easier to dip your toes in. 15:35 – Guest. 16:29 – Panel: I haven’t heard of KOMODO in long time. I remember that was one of the first IDs that I had checked out. I tried that then went to Ruby Mine and then tried Sublime text and then VS. 16:57 – Guest: Komodo was a famous editor. 17:17 – Panel: I am curious on RuboCop that the adaption is driven by teaching idiomatic Ruby to people new to the language? 17:40 – Guest: I don’t think it’s much about the stylistic stuff at this point. I also noticed that the main driver of the group was... Guest goes into great detail about this topic.  22:44 – Guest (continues): RuboCop offers a bunch of different structure. 24:27 – Guest (continues): We are wondering how to approach the issue of performance. The performance aspect tended to be trickier than what we had expected. The majority of developers when given the choice to either secure or make something convenient - they will choose the latter option. 25:47 – Panel: That’s why they get hit with a high AWS bill. 26:00 – Guest. 26:30 – Panel: The things you have learned with RuboCop, is it changing the direction with MRI or the design of the language at all? 26:40 – Guest: I would hope so, but I don’t have hard evidence to prove this. If you give people too many options then it could be a waste of time. I don’t care about the nuances. 30:06 – Ad: RubyMine! 30-day trial! 30:38 – Panel: Would you recommend the Rails style guide if you are building a Rails style project? Should we use that as a baseline and then customize it for your team? 30:55 – Guest: The style guide should be good. For a while I was the only editor. Not a lot of the options that are there aren’t my personal opinion, but it’s the general prescription. If you have strong preferences and you have your team agree on those then it’s okay to be modifying it. At the end of the day it’s better to have consistency within a project. You are doing great! 32:57 – Chuck asks a question. 33:44 – Chuck: Could I modify a rule? 33:53 – Guest: There are varying degrees to the rule. 35:56 – Panel: One of your conference talks you talked about the future of Rails and the future of other Ruby frameworks? 36:18 – Guest: I am worried about the future of Ruby b/c I see people talking about the maturity of the system but there isn’t a clear vision to where we are going. There are some cornerstones for Ruby 3 that he is repeating. 41:05 – Guest (continues): I think we need to commit to the module and the API. 45:42 – Chuck: All of those things make sense to me. Is there any desire for people to fork Ruby or pulling / putting some of this in? 46:00 – Guest. 48:18 – Panel: Transition that to Rails and the future of Rails? 48:27 – Panel: There are big companies that are making changes. 48:51 – Guest. 53:33 – Panel: I think that is a common pattern that most companies move towards. 54:12 – Chuck: We did an episode on ElixirMix with Chris McCord. Check that out! 54:35 – Chuck: Picks! 54:40 – Advertisement – Fresh Books! End – Cache Fly! Links: Get a Coder Job Course Ruby Rust Ruby Motion Ruby on Rails Angular Komodo Emacs RuboCop RuboCop – GitHub Stimulus reflex Messages: Share Screens Smittybilt Visual Studio Code: Introducing Visual Studio Live Share VRBO Bozhidar’s GitHub Bozhidar’s Twitter Bozhidar’s Patreon Bozhidar’s Open Collective Past EMx Episode 020 with Chris McCord! Sponsors: Sentry RubyMine Cache Fly Fresh Books Picks: Dave Tire Plugs VS Live Share Nate Share Screen using Messages on Mac Charles VRBO Find opportunities for R&R Rocket League Bozhidar Documentation for Markdown users Bear App

Panel: Dave Kimura Charles (Chuck) Max Wood Nate Hopkins Special Guest: Dan Mayer In this episode of Ruby Rogues, the panel talks with Bozhidar Batsov who is the VP of Engineering at Toptal, and an Emacs fanatic. The panel and the guest talk about RubCop, Emacs, and Komodo, among other topics! Check out today’s episode for more details. Show Topics: 0:00 – Sentry.IO – Advertisement! 1:07 – Chuck lists the panelists and the special guest. 1:37 – Chuck: Why are you famous? 1:41 – Guest gives his background. 2:13 – Guest: I am passionate about Emacs. 2:55 – Chuck. 2:58 – Panel: I have on a few projects. Do you know RUFO? It’s a bit more opinionated than RuboCop. 3:25 – Guest: I am familiar with RUFO and their approach is similar to JavaScript called Pretty or something like that. 4:45 – Guest: 4:49 – Panel: Can you tell us what RuboCop is and why is it important? 5:00 – Guest: There are a few main things that RuboCop is: 1.) Placement for Ruby minor... 2.) Lint tool 3.) Automatic checker for all the best practices outlined in the community 4.) Formatter for Ruby code – you can feed it ugly code and it will spin out beautiful code 7:30 – Panel: What are the origins of the project? Where you interested in the performance and security aspects of it? 7:49 – Guest. The guest talks about RuboCop in detail. 10:59 – Panel: It’s important to remember that these are just guidelines and they are NOT set in stone. Using single or double quotes. As long as the project is consistent and using decent practices then I am okay with the code. I will disable the...in RuboCop. Today with high-resolution monitors it’s one of those things that are an annoyance to me. It’s just my opinion, though. 12:07 – Guest: Why disable it and not...? 13:36 – Panel: You could use VS code instead of Emacs! I am just kidding. 13:51 – Guest: I hope you are kidding! 13:56 – Chuck: I cannot live without this code... 14:06 – Guest. 14:26 – Panel: I was an early adapter from the beginning and it was hella slow. I tried it from sublime text and I got annoyed so I eventually switched to VS code. Once I got over the brand name, I really like it as my main editor. 15:20 – Panel: Maybe it’s more approachable and it’s easier to dip your toes in. 15:35 – Guest. 16:29 – Panel: I haven’t heard of KOMODO in long time. I remember that was one of the first IDs that I had checked out. I tried that then went to Ruby Mine and then tried Sublime text and then VS. 16:57 – Guest: Komodo was a famous editor. 17:17 – Panel: I am curious on RuboCop that the adaption is driven by teaching idiomatic Ruby to people new to the language? 17:40 – Guest: I don’t think it’s much about the stylistic stuff at this point. I also noticed that the main driver of the group was... Guest goes into great detail about this topic.  22:44 – Guest (continues): RuboCop offers a bunch of different structure. 24:27 – Guest (continues): We are wondering how to approach the issue of performance. The performance aspect tended to be trickier than what we had expected. The majority of developers when given the choice to either secure or make something convenient - they will choose the latter option. 25:47 – Panel: That’s why they get hit with a high AWS bill. 26:00 – Guest. 26:30 – Panel: The things you have learned with RuboCop, is it changing the direction with MRI or the design of the language at all? 26:40 – Guest: I would hope so, but I don’t have hard evidence to prove this. If you give people too many options then it could be a waste of time. I don’t care about the nuances. 30:06 – Ad: RubyMine! 30-day trial! 30:38 – Panel: Would you recommend the Rails style guide if you are building a Rails style project? Should we use that as a baseline and then customize it for your team? 30:55 – Guest: The style guide should be good. For a while I was the only editor. Not a lot of the options that are there aren’t my personal opinion, but it’s the general prescription. If you have strong preferences and you have your team agree on those then it’s okay to be modifying it. At the end of the day it’s better to have consistency within a project. You are doing great! 32:57 – Chuck asks a question. 33:44 – Chuck: Could I modify a rule? 33:53 – Guest: There are varying degrees to the rule. 35:56 – Panel: One of your conference talks you talked about the future of Rails and the future of other Ruby frameworks? 36:18 – Guest: I am worried about the future of Ruby b/c I see people talking about the maturity of the system but there isn’t a clear vision to where we are going. There are some cornerstones for Ruby 3 that he is repeating. 41:05 – Guest (continues): I think we need to commit to the module and the API. 45:42 – Chuck: All of those things make sense to me. Is there any desire for people to fork Ruby or pulling / putting some of this in? 46:00 – Guest. 48:18 – Panel: Transition that to Rails and the future of Rails? 48:27 – Panel: There are big companies that are making changes. 48:51 – Guest. 53:33 – Panel: I think that is a common pattern that most companies move towards. 54:12 – Chuck: We did an episode on ElixirMix with Chris McCord. Check that out! 54:35 – Chuck: Picks! 54:40 – Advertisement – Fresh Books! End – Cache Fly! Links: Get a Coder Job Course Ruby Rust Ruby Motion Ruby on Rails Angular Komodo Emacs RuboCop RuboCop – GitHub Stimulus reflex Messages: Share Screens Smittybilt Visual Studio Code: Introducing Visual Studio Live Share VRBO Bozhidar’s GitHub Bozhidar’s Twitter Bozhidar’s Patreon Bozhidar’s Open Collective Past EMx Episode 020 with Chris McCord! Sponsors: Sentry RubyMine Cache Fly Fresh Books Picks: Dave Tire Plugs VS Live Share Nate Share Screen using Messages on Mac Charles VRBO Find opportunities for R&R Rocket League Bozhidar Documentation for Markdown users Bear App

Panel: Dave Kimura Charles Max Wood David Richards Special Guest: Dan Mayer In this episode of Ruby Rogues, the panel talks with Dan Mayer who believes that small distributed software teams can make a large impact. Dan loves Ruby, distributed systems, OSS, and making development easier. The panel and Dan talk about performance and benchmarking. Check out today’s episode to learn more! Show Topics: 0:00 – Sentry.IO – Advertisement! 1:07 – Chuck: Our panel is Dave, David, myself, and our guest is Dan Mayer. Say “Hi”! 1:24 – Chuck: Give a brief introduction, please. 1:32 – Dan gives his background and what he currently is working on. 1:53 – Chuck: We wanted to talk to you about benchmarking and performance. Tell us how you got into this? 2:28 – Dan: It has been an interesting timeline for me. About seven years I worked for a large site that had a legacy Rails app. It got a lot of dusty corners over the years and we removed dead code, and removed bugs and confusion for the consumer. We were finding ways to tweak it and not impacting your users. I was using Trace Point but the overhead was quite significant. I moved away from that project but found that I found a need for it, again, a few years later. I actually tried to modify...and basically Eric said “prove that it is slow.” It really wasn’t the type of bottleneck that I was seeing. Since then I am rewriting it. I removed one bottleneck and now... 5:00 – Chuck: ...if that number gets smaller then Ruby is doing well. Is it really that simple? How do you benchmark? 5:15 – Dan answers the question. 6:40 – Panel: How do you benchmark things front to back? 6:49 – Dan: I look at benchmarking in different layers. You can see the overall impact in the broad range. If you want to see specific things then that’s a little trickier. For Ruby 3x3 he has been working on a Rails Benchmark, and that’s Noah. He has a sample Rails app and... 8:09 – Chuck: He is using discourse, and we talked to him on a past episode. 8:20 – Dan: My original plan was to insert my gem within that project. However, I ran into a few issues and Noah and I are working on that because of the issues. 8:57 – Panel: How does the coverband gem – how does it provide security so you don’t leak out information to in-users? 9:12 – Dan answers the question. 9:54 – Panel: Then you can build whatever views you want to trace back that sort of information? 10:02 – Dan answers the question. 10:30 – Chuck: Is it running benchmarks against every method you have in your app or what? 10:40 – Dan answers question. 11:27 – Panel: I like when I can remove all of the code I feel safe. 1:37 – Dan: The gem was driven by the fact that I love to delete code. These old files have been sitting around – they aren’t valid – let’s get rid of them. 12:04 – Chuck: This is off topic from benchmarking, but... 12:43 – Dan: ...to get that feature at run time it can hurt your performance.  15:20 – Panel: Is there added memory usage? 15:27 – Dan: I rewrote the library around coverage and I put it out. It worked well for my company and myself. But people were saying that they got a huge performance hit. I went from needing to sample to capture...the new bottleneck was collecting the data all of the code usage of your gems and...it went from just recording your custom code to all Ruby code. Where it was slowing down was reporting that. I didn’t have any benchmarks to capture that. What I was failing to do was... I can talk about what I did do to help people if you want? 17:41 – Chuck: Looking at how much storage is my app using or how much...How can you even begin to isolate it? 18:11 – Dan: On all the different types of benchmarking – I know there is a benchmarking memory increase. I haven’t benchmarked that, yet. To get at these different levels, how do we ensure that’s fast? It was a new challenge to me. 19:45 – Panel: It sounds like this has become a practice over the years. Is that how you handle it or how do you like to use it? 20:07 – Dan: When I started using this benchmarking is because I wanted to solve something. There were several regressions. We’d go back and address it. What I tried doing is put all the benchmarks into the gem. I think back by the Ruby 3x3 goals... 21:49 – Panel: What comes to mind is appreciating well-crafted software that really does well – maybe measure what customer output is? 22:43 – Dan: What people care about is their application. You can look to see... 23:33 – Panel: Automating takes that pressure right off of me and I can do 23:47 – Chuck: Recording all the things you want to do. We are talking about this right now you can record some of it in these tests or... 24:06 – Dan: I have fixed these performance things in the past. I have more confidence that these things get fixed before they get released. Having that methodology helps a lot. 24:43 – Advertisement – RubyMine 25:10 – Panel: I think it’s good to see WHERE your application is getting used the most. To see where you have the MOST code usage. 26:20 – Dan: That’s a good story on back on regressions on benchmarking or performances. 27:46 – Dan: One thing that I think is interesting – I believe the Rails performance testing has gone blank essentially. There are good articles but in the Rails 5 the guides no longer have any information. There is so much talk about performance and benchmarking but things have gotten lost, too. 28:28 – Panel: It’s interesting how we get into x, y, and z. We tend to figure it out and some guys focus on the next thing and the next. 29:24 – Dan: The fads of the things that go in-and-out. It’s definitely coming back: the performance in the Ruby world. My theory is that the tools have gotten that much better and people are doing less. They have offloaded a lot of things for people. It shows, though, it doesn’t do everything. 30:19 – Panel: I think that’s valuable, too. The WHOLE package – this is how we deliver, and these are the tools and the toolkits. I miss Ruby every time that I have to step away b/c I have to use something else. 31:17 – Dan: It sounds COOL to use Elixir and whatnot, but I just can’t get into it as much as when I use Ruby. When I try to branch out to use another language it isn’t the same. 31:47 – Panel: When the pressure is high I use Ruby so that’s where my heart is. 31:58 – Dan: It falls a little short, sometimes, it’s an easy thing that people say: it’s so slow. It’s one of those that we’d like to have a better answer. Is it something that people have thought of as a continual thing or...? 32:47 – Chuck: It’s generally to resolve an issue here or there. 32:57 – Panel. 33:07 – Chuck: When I do use the benchmarks I have added in my test suite a trip wire that validates that it’s under a certain point. 33:37 – Panel: If I did that my tests would never pass. 33:45 – Chuck. 33:49 – Dan: How can you do that reliably where you get the value but you don’t have a bunch of false failures? A person has to do it to see if it is faster/slower. 34:26 – Panel: For my applications – usually they are slow not b/c of Ruby but b/c of a poor architectural decision we have made. Every situation you can go and weight it to see what is best. Ultimately they are the ones that are brining in money into your business. 35:27 – Chuck: When I add things into my test suites is b/c there was some major performance hiccup where it ruins the user’s flow. 35:55 – Dan: The way you benchmark it... Benchmarking a gem or a library it’s how can it impact other people’s apps. And the Ruby 3x3 is proving that it’s faster – what does that mean – and I think Noah has done some great work on. 36:30 – Dan: The last thing I want to mention is Julia’s work on that is what got me back into coverband. I was thinking I would use a different version of coverband that would use RBSPY. 37:37 – Chuck: Yeah, that was a great episode. 37:44 – Dan: I want to play with it some more. I guess I would have to know more in Rust, though. 37:57 – Chuck: Anything that you are working on within this space? 38:04 – Dan: There have been 4-5 current people in coverband and we have added a bunch of new benchmarks and they are 60% faster. I am trying to work on getting a simpler version out there. Hopefully it will be live soon after getting rid of the bugs. 39:05 – Chuck: How can people find you? 39:10 – Dan: My blog, Twitter, and GitHub! 39:22 – Chuck: M-A-Y-E-R. 39:36 – Picks! 39:40 – Advertisement – Fresh Books! End – Cache Fly! Links: Get a Coder Job Course Ruby Rust Ruby Motion Ruby on Rails Angular Benchmark-IPS Rbspy Ruby Benchmarking Benchmarking Bugs Coverband TracePoint RR 362 Episode Rails Guides Atomic Habits EasyRes Skinny Pop Blog through AppSignal Book: Extreme Ownership Noah Gibbs’ Twitter Dan Mayer’s Blog Dan Mayer’s Twitter Dan Mayer’s GitHub Dan Mayer’s Medium Sponsors: Sentry RubyMine Cache Fly Fresh Books Picks: David Atomic Habits by James Clear Dave EasyRes Skinny Pop Charles Extreme Ownership Jocko Willink podcast 2 Keto Dudes Ketogenic Forums Dan Artemis https://blog.appsignal.com/2018/09/28/active-record-vs-ecto.html https://github.com/evanphx/benchmark-ips https://github.com/rbspy/rbspy

Panel: Dave Kimura Charles Max Wood David Richards Special Guest: Dan Mayer In this episode of Ruby Rogues, the panel talks with Dan Mayer who believes that small distributed software teams can make a large impact. Dan loves Ruby, distributed systems, OSS, and making development easier. The panel and Dan talk about performance and benchmarking. Check out today’s episode to learn more! Show Topics: 0:00 – Sentry.IO – Advertisement! 1:07 – Chuck: Our panel is Dave, David, myself, and our guest is Dan Mayer. Say “Hi”! 1:24 – Chuck: Give a brief introduction, please. 1:32 – Dan gives his background and what he currently is working on. 1:53 – Chuck: We wanted to talk to you about benchmarking and performance. Tell us how you got into this? 2:28 – Dan: It has been an interesting timeline for me. About seven years I worked for a large site that had a legacy Rails app. It got a lot of dusty corners over the years and we removed dead code, and removed bugs and confusion for the consumer. We were finding ways to tweak it and not impacting your users. I was using Trace Point but the overhead was quite significant. I moved away from that project but found that I found a need for it, again, a few years later. I actually tried to modify...and basically Eric said “prove that it is slow.” It really wasn’t the type of bottleneck that I was seeing. Since then I am rewriting it. I removed one bottleneck and now... 5:00 – Chuck: ...if that number gets smaller then Ruby is doing well. Is it really that simple? How do you benchmark? 5:15 – Dan answers the question. 6:40 – Panel: How do you benchmark things front to back? 6:49 – Dan: I look at benchmarking in different layers. You can see the overall impact in the broad range. If you want to see specific things then that’s a little trickier. For Ruby 3x3 he has been working on a Rails Benchmark, and that’s Noah. He has a sample Rails app and... 8:09 – Chuck: He is using discourse, and we talked to him on a past episode. 8:20 – Dan: My original plan was to insert my gem within that project. However, I ran into a few issues and Noah and I are working on that because of the issues. 8:57 – Panel: How does the coverband gem – how does it provide security so you don’t leak out information to in-users? 9:12 – Dan answers the question. 9:54 – Panel: Then you can build whatever views you want to trace back that sort of information? 10:02 – Dan answers the question. 10:30 – Chuck: Is it running benchmarks against every method you have in your app or what? 10:40 – Dan answers question. 11:27 – Panel: I like when I can remove all of the code I feel safe. 1:37 – Dan: The gem was driven by the fact that I love to delete code. These old files have been sitting around – they aren’t valid – let’s get rid of them. 12:04 – Chuck: This is off topic from benchmarking, but... 12:43 – Dan: ...to get that feature at run time it can hurt your performance.  15:20 – Panel: Is there added memory usage? 15:27 – Dan: I rewrote the library around coverage and I put it out. It worked well for my company and myself. But people were saying that they got a huge performance hit. I went from needing to sample to capture...the new bottleneck was collecting the data all of the code usage of your gems and...it went from just recording your custom code to all Ruby code. Where it was slowing down was reporting that. I didn’t have any benchmarks to capture that. What I was failing to do was... I can talk about what I did do to help people if you want? 17:41 – Chuck: Looking at how much storage is my app using or how much...How can you even begin to isolate it? 18:11 – Dan: On all the different types of benchmarking – I know there is a benchmarking memory increase. I haven’t benchmarked that, yet. To get at these different levels, how do we ensure that’s fast? It was a new challenge to me. 19:45 – Panel: It sounds like this has become a practice over the years. Is that how you handle it or how do you like to use it? 20:07 – Dan: When I started using this benchmarking is because I wanted to solve something. There were several regressions. We’d go back and address it. What I tried doing is put all the benchmarks into the gem. I think back by the Ruby 3x3 goals... 21:49 – Panel: What comes to mind is appreciating well-crafted software that really does well – maybe measure what customer output is? 22:43 – Dan: What people care about is their application. You can look to see... 23:33 – Panel: Automating takes that pressure right off of me and I can do 23:47 – Chuck: Recording all the things you want to do. We are talking about this right now you can record some of it in these tests or... 24:06 – Dan: I have fixed these performance things in the past. I have more confidence that these things get fixed before they get released. Having that methodology helps a lot. 24:43 – Advertisement – RubyMine 25:10 – Panel: I think it’s good to see WHERE your application is getting used the most. To see where you have the MOST code usage. 26:20 – Dan: That’s a good story on back on regressions on benchmarking or performances. 27:46 – Dan: One thing that I think is interesting – I believe the Rails performance testing has gone blank essentially. There are good articles but in the Rails 5 the guides no longer have any information. There is so much talk about performance and benchmarking but things have gotten lost, too. 28:28 – Panel: It’s interesting how we get into x, y, and z. We tend to figure it out and some guys focus on the next thing and the next. 29:24 – Dan: The fads of the things that go in-and-out. It’s definitely coming back: the performance in the Ruby world. My theory is that the tools have gotten that much better and people are doing less. They have offloaded a lot of things for people. It shows, though, it doesn’t do everything. 30:19 – Panel: I think that’s valuable, too. The WHOLE package – this is how we deliver, and these are the tools and the toolkits. I miss Ruby every time that I have to step away b/c I have to use something else. 31:17 – Dan: It sounds COOL to use Elixir and whatnot, but I just can’t get into it as much as when I use Ruby. When I try to branch out to use another language it isn’t the same. 31:47 – Panel: When the pressure is high I use Ruby so that’s where my heart is. 31:58 – Dan: It falls a little short, sometimes, it’s an easy thing that people say: it’s so slow. It’s one of those that we’d like to have a better answer. Is it something that people have thought of as a continual thing or...? 32:47 – Chuck: It’s generally to resolve an issue here or there. 32:57 – Panel. 33:07 – Chuck: When I do use the benchmarks I have added in my test suite a trip wire that validates that it’s under a certain point. 33:37 – Panel: If I did that my tests would never pass. 33:45 – Chuck. 33:49 – Dan: How can you do that reliably where you get the value but you don’t have a bunch of false failures? A person has to do it to see if it is faster/slower. 34:26 – Panel: For my applications – usually they are slow not b/c of Ruby but b/c of a poor architectural decision we have made. Every situation you can go and weight it to see what is best. Ultimately they are the ones that are brining in money into your business. 35:27 – Chuck: When I add things into my test suites is b/c there was some major performance hiccup where it ruins the user’s flow. 35:55 – Dan: The way you benchmark it... Benchmarking a gem or a library it’s how can it impact other people’s apps. And the Ruby 3x3 is proving that it’s faster – what does that mean – and I think Noah has done some great work on. 36:30 – Dan: The last thing I want to mention is Julia’s work on that is what got me back into coverband. I was thinking I would use a different version of coverband that would use RBSPY. 37:37 – Chuck: Yeah, that was a great episode. 37:44 – Dan: I want to play with it some more. I guess I would have to know more in Rust, though. 37:57 – Chuck: Anything that you are working on within this space? 38:04 – Dan: There have been 4-5 current people in coverband and we have added a bunch of new benchmarks and they are 60% faster. I am trying to work on getting a simpler version out there. Hopefully it will be live soon after getting rid of the bugs. 39:05 – Chuck: How can people find you? 39:10 – Dan: My blog, Twitter, and GitHub! 39:22 – Chuck: M-A-Y-E-R. 39:36 – Picks! 39:40 – Advertisement – Fresh Books! End – Cache Fly! Links: Get a Coder Job Course Ruby Rust Ruby Motion Ruby on Rails Angular Benchmark-IPS Rbspy Ruby Benchmarking Benchmarking Bugs Coverband TracePoint RR 362 Episode Rails Guides Atomic Habits EasyRes Skinny Pop Blog through AppSignal Book: Extreme Ownership Noah Gibbs’ Twitter Dan Mayer’s Blog Dan Mayer’s Twitter Dan Mayer’s GitHub Dan Mayer’s Medium Sponsors: Sentry RubyMine Cache Fly Fresh Books Picks: David Atomic Habits by James Clear Dave EasyRes Skinny Pop Charles Extreme Ownership Jocko Willink podcast 2 Keto Dudes Ketogenic Forums Dan Artemis https://blog.appsignal.com/2018/09/28/active-record-vs-ecto.html https://github.com/evanphx/benchmark-ips https://github.com/rbspy/rbspy

Panel: Dave Kimura Charles Max Wood David Richards Special Guest: Dan Mayer In this episode of Ruby Rogues, the panel talks with Dan Mayer who believes that small distributed software teams can make a large impact. Dan loves Ruby, distributed systems, OSS, and making development easier. The panel and Dan talk about performance and benchmarking. Check out today’s episode to learn more! Show Topics: 0:00 – Sentry.IO – Advertisement! 1:07 – Chuck: Our panel is Dave, David, myself, and our guest is Dan Mayer. Say “Hi”! 1:24 – Chuck: Give a brief introduction, please. 1:32 – Dan gives his background and what he currently is working on. 1:53 – Chuck: We wanted to talk to you about benchmarking and performance. Tell us how you got into this? 2:28 – Dan: It has been an interesting timeline for me. About seven years I worked for a large site that had a legacy Rails app. It got a lot of dusty corners over the years and we removed dead code, and removed bugs and confusion for the consumer. We were finding ways to tweak it and not impacting your users. I was using Trace Point but the overhead was quite significant. I moved away from that project but found that I found a need for it, again, a few years later. I actually tried to modify...and basically Eric said “prove that it is slow.” It really wasn’t the type of bottleneck that I was seeing. Since then I am rewriting it. I removed one bottleneck and now... 5:00 – Chuck: ...if that number gets smaller then Ruby is doing well. Is it really that simple? How do you benchmark? 5:15 – Dan answers the question. 6:40 – Panel: How do you benchmark things front to back? 6:49 – Dan: I look at benchmarking in different layers. You can see the overall impact in the broad range. If you want to see specific things then that’s a little trickier. For Ruby 3x3 he has been working on a Rails Benchmark, and that’s Noah. He has a sample Rails app and... 8:09 – Chuck: He is using discourse, and we talked to him on a past episode. 8:20 – Dan: My original plan was to insert my gem within that project. However, I ran into a few issues and Noah and I are working on that because of the issues. 8:57 – Panel: How does the coverband gem – how does it provide security so you don’t leak out information to in-users? 9:12 – Dan answers the question. 9:54 – Panel: Then you can build whatever views you want to trace back that sort of information? 10:02 – Dan answers the question. 10:30 – Chuck: Is it running benchmarks against every method you have in your app or what? 10:40 – Dan answers question. 11:27 – Panel: I like when I can remove all of the code I feel safe. 1:37 – Dan: The gem was driven by the fact that I love to delete code. These old files have been sitting around – they aren’t valid – let’s get rid of them. 12:04 – Chuck: This is off topic from benchmarking, but... 12:43 – Dan: ...to get that feature at run time it can hurt your performance.  15:20 – Panel: Is there added memory usage? 15:27 – Dan: I rewrote the library around coverage and I put it out. It worked well for my company and myself. But people were saying that they got a huge performance hit. I went from needing to sample to capture...the new bottleneck was collecting the data all of the code usage of your gems and...it went from just recording your custom code to all Ruby code. Where it was slowing down was reporting that. I didn’t have any benchmarks to capture that. What I was failing to do was... I can talk about what I did do to help people if you want? 17:41 – Chuck: Looking at how much storage is my app using or how much...How can you even begin to isolate it? 18:11 – Dan: On all the different types of benchmarking – I know there is a benchmarking memory increase. I haven’t benchmarked that, yet. To get at these different levels, how do we ensure that’s fast? It was a new challenge to me. 19:45 – Panel: It sounds like this has become a practice over the years. Is that how you handle it or how do you like to use it? 20:07 – Dan: When I started using this benchmarking is because I wanted to solve something. There were several regressions. We’d go back and address it. What I tried doing is put all the benchmarks into the gem. I think back by the Ruby 3x3 goals... 21:49 – Panel: What comes to mind is appreciating well-crafted software that really does well – maybe measure what customer output is? 22:43 – Dan: What people care about is their application. You can look to see... 23:33 – Panel: Automating takes that pressure right off of me and I can do 23:47 – Chuck: Recording all the things you want to do. We are talking about this right now you can record some of it in these tests or... 24:06 – Dan: I have fixed these performance things in the past. I have more confidence that these things get fixed before they get released. Having that methodology helps a lot. 24:43 – Advertisement – RubyMine 25:10 – Panel: I think it’s good to see WHERE your application is getting used the most. To see where you have the MOST code usage. 26:20 – Dan: That’s a good story on back on regressions on benchmarking or performances. 27:46 – Dan: One thing that I think is interesting – I believe the Rails performance testing has gone blank essentially. There are good articles but in the Rails 5 the guides no longer have any information. There is so much talk about performance and benchmarking but things have gotten lost, too. 28:28 – Panel: It’s interesting how we get into x, y, and z. We tend to figure it out and some guys focus on the next thing and the next. 29:24 – Dan: The fads of the things that go in-and-out. It’s definitely coming back: the performance in the Ruby world. My theory is that the tools have gotten that much better and people are doing less. They have offloaded a lot of things for people. It shows, though, it doesn’t do everything. 30:19 – Panel: I think that’s valuable, too. The WHOLE package – this is how we deliver, and these are the tools and the toolkits. I miss Ruby every time that I have to step away b/c I have to use something else. 31:17 – Dan: It sounds COOL to use Elixir and whatnot, but I just can’t get into it as much as when I use Ruby. When I try to branch out to use another language it isn’t the same. 31:47 – Panel: When the pressure is high I use Ruby so that’s where my heart is. 31:58 – Dan: It falls a little short, sometimes, it’s an easy thing that people say: it’s so slow. It’s one of those that we’d like to have a better answer. Is it something that people have thought of as a continual thing or...? 32:47 – Chuck: It’s generally to resolve an issue here or there. 32:57 – Panel. 33:07 – Chuck: When I do use the benchmarks I have added in my test suite a trip wire that validates that it’s under a certain point. 33:37 – Panel: If I did that my tests would never pass. 33:45 – Chuck. 33:49 – Dan: How can you do that reliably where you get the value but you don’t have a bunch of false failures? A person has to do it to see if it is faster/slower. 34:26 – Panel: For my applications – usually they are slow not b/c of Ruby but b/c of a poor architectural decision we have made. Every situation you can go and weight it to see what is best. Ultimately they are the ones that are brining in money into your business. 35:27 – Chuck: When I add things into my test suites is b/c there was some major performance hiccup where it ruins the user’s flow. 35:55 – Dan: The way you benchmark it... Benchmarking a gem or a library it’s how can it impact other people’s apps. And the Ruby 3x3 is proving that it’s faster – what does that mean – and I think Noah has done some great work on. 36:30 – Dan: The last thing I want to mention is Julia’s work on that is what got me back into coverband. I was thinking I would use a different version of coverband that would use RBSPY. 37:37 – Chuck: Yeah, that was a great episode. 37:44 – Dan: I want to play with it some more. I guess I would have to know more in Rust, though. 37:57 – Chuck: Anything that you are working on within this space? 38:04 – Dan: There have been 4-5 current people in coverband and we have added a bunch of new benchmarks and they are 60% faster. I am trying to work on getting a simpler version out there. Hopefully it will be live soon after getting rid of the bugs. 39:05 – Chuck: How can people find you? 39:10 – Dan: My blog, Twitter, and GitHub! 39:22 – Chuck: M-A-Y-E-R. 39:36 – Picks! 39:40 – Advertisement – Fresh Books! End – Cache Fly! Links: Get a Coder Job Course Ruby Rust Ruby Motion Ruby on Rails Angular Benchmark-IPS Rbspy Ruby Benchmarking Benchmarking Bugs Coverband TracePoint RR 362 Episode Rails Guides Atomic Habits EasyRes Skinny Pop Blog through AppSignal Book: Extreme Ownership Noah Gibbs’ Twitter Dan Mayer’s Blog Dan Mayer’s Twitter Dan Mayer’s GitHub Dan Mayer’s Medium Sponsors: Sentry RubyMine Cache Fly Fresh Books Picks: David Atomic Habits by James Clear Dave EasyRes Skinny Pop Charles Extreme Ownership Jocko Willink podcast 2 Keto Dudes Ketogenic Forums Dan Artemis https://blog.appsignal.com/2018/09/28/active-record-vs-ecto.html https://github.com/evanphx/benchmark-ips https://github.com/rbspy/rbspy

Если уж говорить об IDE, то только с человеком, который сам приложил руку к всемирно известным продуктам. IntelliJ IDEA, PyCharm, WebStorm, RubyMine - это далеко не все продукты, в разработке которых участвовал Дмитрий Жемеров, ветеран JetBrains. Дмитрий заглянул к нам в гости, и вместе мы прошлись по основным этапам развития такого важного для разработчика инструмента, заглянули «под капот» IDE и обсудили её устройство на различных уровнях: от базовых функций вроде текстового редактора, до взаимодействия IDE с плагинами. Бонусом — рассказ про то, как устроена работа над продуктами JetBrains из первых уст. P.S. Конечно, не обошлось без сравнений различных продуктов. Но упоминаний XCode в выпуске крайне мало, ведь мы не iOSный подкаст! Поддержи лучший подкаст про мобильную разработку: www.patreon.com/podlodka Также ждем вас, ваши лайки, репосты и комменты в мессенджерах и соцсетях! Telegram-чат: https://t.me/podlodka   Telegram-канал: https://t.me/podlodkanews Страница в Facebook: www.facebook.com/podlodkacast/ Twitter-аккаунт: https://twitter.com/PodlodkaPodcast   Содержание: - 00:00:40 - Знакомство с гостем - 00:02:20 - Историческая справка: с чего все началось - 00:05:00 - 2000-e: crossing refactoring rubicon. - 00:05:50 - История появления JetBrains - 00:08:00 - Развитие Eclipse и Netbeans - 00:08:50 - Web based IDE - 00:13:00 - IDE в наши дни; LSP - 00:15:00 - Производительность IDE - 00:19:50 - Обзор основных инструментов - 00:27:40 - Устройство IDE: базовые функции - 00:31:00 - Устройство IDE: дополнительные функции - 00:32:00 - Про визуальные редакторы - 00:36:00 - Плагины для IDEA - 00:47:00 - Про Android Studio - 00:50:15 - Как написать свою IDE? - 00:56:00 - Дмитрий о JetBrains - 01:07:45 - Как попасть в JetBrains - 01:10:10 - Подведение черты - 01:11:50 - Вопрос Стасу Полезные ссылки: - Концепт Xcode под iPad https://twitter.com/LouisDhauwe/status/1008071487721439233 - Language Server Protocol https://en.m.wikipedia.org/wiki/Language_Server_Protocol - Документация API для плагинов IDEA http://www.jetbrains.org/intellij/sdk/docs/welcome.html

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

On today's episode of My JS Story, Charles Max Wood welcomes Dennis Ushakov. Dennis is a team lead of WebStorm and RubyMine at JetBrains. Tune in to My JS Story Dennis Ushakov to learn more about his programming experience in Java and JavaScript.

On today's episode of My JS Story, Charles Max Wood welcomes Dennis Ushakov. Dennis is a team lead of WebStorm and RubyMine at JetBrains. Tune in to My JS Story Dennis Ushakov to learn more about his programming experience in Java and JavaScript.

On today's episode of My JS Story, Charles Max Wood welcomes Dennis Ushakov. Dennis is a team lead of WebStorm and RubyMine at JetBrains. Tune in to My JS Story Dennis Ushakov to learn more about his programming experience in Java and JavaScript.

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.

If you have questions of your own, you can tweet us at @immutablefm, email us at questions@immutable.fm, or join our Slack team! Sponsor: Hired Topic 1: Preferred static code analysis tools - JavaScript and Ruby. I find myself back in JS this month and my toolset could be outdated. Using eslint and js-beautify to do static checking and format cleanup. (Ruby I’ve moved to RubyMine, but I like the command line so could come back…) JSHint SwiftLint JP Simard Realm RuboCop Sublime Text 3 Topic 2: Using Tachyons in production for SaaS? Good idea or should we try to keep it for smaller projects and prototyping? Adam Morse Tachyons (scroll down for gallery) Spector BassCSS Brent Jackson Topic 3: Any ideas of frameworks with a lot of components written in React already? I mean like react-bootstrap. What else is there? Rebass Topic 4: What’s your best idea that you haven’t acted on yet (that you can share - or you can talk about it in vague terms) - and what’s preventing you from doing it? Brian Lovin Topic 5: What's your current recording setup? Immutable 12: Wal-Mart Brand Audio Shure Beta 87A Supercardioid Marco Arment OWC ThunderBay 4 Focusrite Clarett 8Pre Caleb Davenport Heil PR40 Apogee One Audio-Technica ATH-M40 Master & Dynamic MH40 B&O H3 Beyerdynamic DT770 Pro Tara Mann Beyerdynamic DT880 Beyerdynamic DT990

本期由 Daniel 和 Terry 共同主持，再一次邀请了原 JavaEye（ITEye的前身）的创始人 Robbin 范凯来 Teahour 做客，本期话题是上一期 Robbin 的访谈的延续，主要包括 Robbin 对行业趋势的观察，分析，包括如何准备创业，如何把握行业趋势，作为技术创业者如何成长，如何培养决策能力，以及他是如何作为技术 VP 加入丁香园的故事。 我们的反馈邮箱是: hi@teahour.fm 欢迎你的来信, 我们将抽取有价值的来信和反馈在节目中播出。 如果你想赞助本节目, 也请写邮件到此邮箱, 非常感谢您的支持. 丁香园 冯大辉 丁香园创始人李天天 Robbin 加入丁香园 池建强 MacTalk 胡适当年为什么选择去台湾？ 戴志康 王志东 张小龙 肉饼铺子 IntelJ IDE RubyMine WebStom CLion CSDN 密码门事件 携程信用卡泄漏 163邮箱被破解 给Java说句公道话－王垠 张三丰教张无忌武功时为什么叫他忘了？ 产品汪和程序猿的相处之道 Swift.gg MindNnode 技术创业空间 Special Guest: 范凯.

Новости Рельсы — решето Как делать PDF в рельсе Как открывать рельсовые сессии в других местах Нестандартный актив рекород Жозе Валим написал еще одну книгу про 4-ые рельсы Как работает поколенческий GC Ruby 1.9.3-p484 и Ruby 2.0.0-p353 Руби-лэнг на русском RubyMine 6 Визуализация работы GC в Руби и Питоне ПНУ от Кирилла Книга о том, как делать приложения для команднной строки Маленькие бэктрейсы Раби андэр и микроскопе доступна на бумаге Обсуждение Новые ведущие Андрей Дерябин Кирилл Шатров

本期由Terry Tai和Dingding共同主持，邀请了 neo 的美女软件工程师鲁葳，和她一起聊聊软件咨询公司是如何工作的。让大家了解更多的优秀软件咨询公司的细节和内幕。 关于鲁葳： Twitter Blog 访谈笔记 neo Pivotal Labs thoughtbot PivotalTracker University of Waterloo rocketfuel Jim Weirich Pair programming TDD Continuous integration Sublime Text RubyMine Vim Emacs tmux Travis CI Jenkins CI Yehuda Katz Eric Ries Lean UX Rails Girls Remote Pair Programing Blog Customer.io Effective JavaScript Special Guest: 鲁葳.

У нас в гостях Максим Семенкин (CodeInside) и Анна Буленкова (JetBrains). Поговорим о прошедшей конференции ULCAMP. Каков ее формат, что интересного рассказывали спикеры и почему стоит посетить это мероприятие. Аня расскажет, чем занимается в JetBrains, как поставлен процесс разработки в компании. Поговорим про IDE RubyMine: что у проекта под капотом, архитектура, чего ждать в новых версиях. Ответим на вопросы слушателей. В выпуске: ULCAMP 2013. Впечатления о конференции. RubyMine. Современный инструмент для веб-разработчика. - коротко о продукте - чем непосредственно Аня занимается - внутренняя кухня проекта - архитектура - направление развития, что нового нас ждет в будущих версиях Наши гости: Анна Буленкова Максим Семенкин Ссылки: Описание IntelliJ IDEA Community Edition Oбщие сведения по плагинам IntelliJ IDEA Гайдлайны для разработчиков плагинов Создание плагина для IDEA с нуля (видео) Podsafe: J.1.0 - Frozen Paradise

Новости Rear admin Сканер уязвимсотей для RoR Прямой аплоад файла на nginx Ставим рельсы на убунту с нуля RubyMine со скидкой Gem отучался shound_not Обновление сайта _why-я Объяснение на пальцах фичи Ruby 2.0 Enumeration#lazy Пиши на Ruby правильно Passenger 4.0 RC6 Ruboto 0.11.0 Кеширование методов в Ruby и патч от Джеймса Голика Обсуждение Интервью с Андреем Руденко Твиттер Андрея Github нашего гостя Compojure Книга Land of Lisp Common Lisp в Wikipedia Официальный сайт языка Clojure Ring Редактор Emacs Редактор Light Table Текущая работа Андрея Clojure Core Статья с разной статистикой про Clojure Книга SICP Выступление Ричи Хики на QCon Выступление Ричи Хики

Новости Поломали rubgems О подписи rubygems Вышел Chef 11.0.0, список нововведений на сайте opscode Вышел Chef 11.2.0 Topaz — Ruby, написанный на Python Вышел Ruby 1.9.3-p385 Вышел Ruby 2.0.0-rc2 Гем gesteau Вышел RubyMine 5 Проект Divergence, для переключения между бранчами на stage-сервере Серия статей о внутренностях руби от Пэта Шонесси — один, два и три В gist теперь есть имя Strano — деплоилка мечты (почти что) Поддержка версий Rails Четвертый пассажир — вышел Phusion Passenger 4.0beta2 Уязвимости в Rack, в частности атака по времени Обсуждение Безопасность 2 Новые версии Rails с исправленными уязвимостями Уязвимость в JSON Уязвимость в serialize Уязвимость в attr_protected Комментарии Егора Хомякова Объяснение некоторых уязвимостей от Аарона Петерсона Новый шеф Chef эпизод 11. Новая надежда Митап по поводу Chef

Новости Занимательное функциональное программирование в Ruby Active Record loves blocks Gitlab 2.7 Ошибка безопасности в рельсах, новые версии 3.0.16, 3.1.7, 3.2.7 Active Record Deep Dive An Introduction to Celluloid, Part I An Introduction to Celluloid, Part II RubyMine 4.5 Rubinius debugging session Pat Shaughnessy написал кусок из своей книги «Ruby Under a Microscope» Objects, Classes and Modules Fun with ruby hashes Обсуждение 15 сентября пройдет новый Railsclub, на который приедут 5 иностранных гостей. Steve Klabnik DayZ Xavier Noria Wynn Netherland Dirkjan Bussink Sau Sheong Chang Redis Sentinel ActiveMQ RabbitMQ skytools PgQ Tom Lane Дмитрий Завалишин PhantomOS и в Wikipedia Griffin подставка Техника Александра Gist с Эдуардом

Matt Kent joins me again to talk about: REACT and its open sourcing The cost of late changing requirements IDEs (we use RubyMine now) Web Frameworks and where we go from here Also: if you like Liam Neeson see Unknown for his standard fare.  Don't see Gnomeo and Juliet on principle. Subscribe via iTunes or RSS

Ještě v roce 2008 jsme stačili nahrát další podcast, který jsme pojali v duchu novinek, jenž nás v prosinci zaplavily především na poli vývojových prostředí. Naším hostem byl Václav Pech z firmy JetBrains a tak se naše řeč točila kolem IntelliJIDEA 8 a RubyMine. Roumen si polívčičku přihřál na Soláči a rozpovídal se trochu o NetBeans 6.5 a VirtualBoxu. Jak je dobrým zvykem našeho podcastu, tak vždy když je naším hostem Václav, tak ve vzduchu visí licence k IntelliJ IDEA a nejinak je tomu v případě tohoto podcastu. Pozorně poslouchejte a na vaše odpovědi se těšíme na naší mailové adrese czpodcast zavináč gmail.com..