POPULARITY
5 episodes with evil martians
4 episodes with evil martians
4 episodes with evil martians
3 episodes with evil martians
2 episodes with evil martians
2 episodes with evil martians
2 episodes with evil martians
2 episodes with evil martians
2 episodes with evil martians
We all love Ruby on Rails. You may remember that my first episode on this show was about whether Rails was still relevant. In the last few years, there's been so many exciting things coming to Ruby and Rails. I have felt that excitement in the community. I've felt it at conferences and in my conversations with many of you. Today, Irina Nazarova joins us to talk about how we can better evangelize Rails Show Notes Neighbor gem https://github.com/ankane/neighbor Irina's Keynote https://www.youtube.com/watch?v=-sFYiyFQMU8 Rails stack from Evil Martians: https://evilmartians.com/rails-startup-stack (this includes Turbo Mount and other things Irina mentioned) Irina's Meetups Blog Post https://evilmartians.com/chronicles/lets-have-more-tech-meetups-a-quick-start-guide-to-holding-your-own
In today's episode, Jason, Chris, and Andrew, along with their guest, Irina Nazarova, CEO of Evil Martians, engage in a candid discussion that covers the intricacies of using Rails and integrating it with technologies like React, and the challenges of marketing developer-facing products. The discussion also touches on open-core business models, the relevance of Docker in current tech companies, and the future of software deployment. Also, Irina touches on a new tool from Thoughtbot called Superglue, a new open source product called Skooma, and she invites listeners to come to RailsConf and some Ruby meetups in San Francisco coming soon. Press download to hear more! Panelists:Jason CharnesChris OliverAndrew MasonGuest:Irina NazarovaSponsor:HoneybadgerLinks:Jason Charnes X/TwitterChris Oliver X/TwitterAndrew Mason X/TwitterIrina Nazarova X/TwitterEvil Martians X/TwitterEvil MartiansEvil Martians SkoomaThoughtbot SuperglueThrusterSupabase“Image processing servers benchmark”-imgproxy blogRailsConf -May 7-9, 2024Rails World-Sept 26-27, 2024RubyConf AU-April 11-12 2024Honeybadger Honeybadger is an application health monitoring tool built by developers for developers.Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.
In the latest episode of Maintainable, Robby Russell has a fascinating conversation with Irina Nazarova, the CEO of Evil Martians, a name that resonates with innovation and bold strides in the software development world. They dive deep into what it takes to maintain not just code, but also the delicate balance between rapid development and long-term sustainability in the ever-evolving startup landscape.Irina shares her unique perspective on the common traits of well-maintained software, stressing the importance of adaptability and the role of technical debt at different stages of a company's growth. With a background rich in pushing the boundaries of what's possible in software consultancy, she offers a fresh take on commercializing open-source projects, nurturing innovation within the team, and the significance of building genuine relationships with clients.Listeners will get a glimpse into the challenges and triumphs of running a software consultancy that dares to dream big. From the intricacies of investing in internal projects to the philosophy behind fostering a culture of innovation and respect, this episode is a goldmine of insights for anyone curious about the intersection of consultancy work and product development.Don't miss out on this engaging discussion that reveals the byproducts of passion, dedication, and a relentless pursuit of excellence in the software industry. Check out the episode and let us know your thoughts!Book Recommendations:The Challenger SaleHelpful Links:Evil MartiansIrina on LinkedInIrina on TwitterAnyCableLayered Design for Ruby on Rails Applications by Vladimir DementyevThanks to Our Sponsor!Turn hours of debugging into just minutes! AppSignal is a performance monitoring and error tracking tool designed for Ruby, Elixir, Python, Node.js, Javascript, and soon, other frameworks. It offers six powerful features with one simple interface, providing developers with real-time insights into the performance and health of web applications. Keep your coding cool and error-free, one line at a time! Check them out! Subscribe to Maintainable on:Apple PodcastsOvercastSpotifyOr search "Maintainable" wherever you stream your podcasts.Keep up to date with the Maintainable Podcast by joining the newsletter.
How do you commercialize open-source products? While at NDC Porto, Carl and Richard talked to Victoria Melnikova about her work with Evil Martians, helping startups make open-source products and make a living at the same time. Victoria talks about various revenue strategies, but always with a mind to providing a "forever free" tier to be responsible to the open source community. Charging for pro-features, limiting the number of uses before a paid tier... there are several approaches to revenue that users can work with, as long as you are open and honest about how things work!
How do you commercialize open-source products? While at NDC Porto, Carl and Richard talked to Victoria Melnikova about her work with Evil Martians, helping startups make open-source products and make a living at the same time. Victoria talks about various revenue strategies, but always with a mind to providing a "forever free" tier to be responsible to the open source community. Charging for pro-features, limiting the number of uses before a paid tier... there are several approaches to revenue that users can work with, as long as you are open and honest about how things work!This show is part of the Spreaker Prime Network, if you are interested in advertising on this podcast, contact us at https://www.spreaker.com/show/5634793/advertisement
Vladimir is a backend engineer from Mars, or Evil Martians, a consultancy specialized in product development for startups and developer tools. Vladimir is known for his work on many open-source projects in the Ruby on Rails world, such as AnyCable, Action Policy, TestProf and many more. He recently published the book Layered Design for Ruby on Rails Applications. Show Notes Buy Layered Design(Pakt) - https://www.packtpub.com/product/layered-design-for-ruby-on-rails-applications/9781801813785 Buy Layered Design(Amazon) - https://www.amazon.com/promocode/A1F9CL9CYX3GLM Sponsored By: Honeybadger (https://www.honeybadger.io/) As an Engineering Manager or an engineer, too much of your time gets sucked up with downtime issues, troubleshooting, and error tracking. How can you spend more time shipping code and less time putting out fires? Honeybadger is how. It's a suite of monitoring tools specifically for devs. Get started today in as little as 5 minutes at Honeybadger.io (https://www.honeybadger.io/) with plans starting at free!
In this episode, Jason and Andrew are joined by guest, Vladimir Dementyev of Ruby on Rails and Evil Martians fame. Today, they touch on Vladmir's new book on designing Rails applications, and dive into the importance of sticking to Rails principles, even in the era of microservices. Vladimir shares insights on working as a consultant on legacy Rails projects and the challenges that can arise when codebases deviate from Rails conventions. We'll also explore the evolution of Rails applications, the power of open source contributions, and Vladimir's journey to becoming a recognized figure in the tech community. Also, Vladimir introduces AnyCable, a performance-oriented solution for real-time communication in Rails applications and provides insights into its capabilities and evolution. Hit download now to hear much more! [00:02:29] Vladimir briefly describes his book on designing Rails applications. [00:05:40] Vladimir talks about sticking to Rails principles and not injecting foreign patterns into Rails applications and emphasizes the importance of maintaining a Rails oriented approach even when using microservices. [00:08:33] We hear about Vladimir working as a consultant on legacy Rails projects and the challenges of maintaining codebases that deviate from Rails principles. [00:10:29] Jason asks for more examples of where the Rails framework ends and developers have to steer their own course. Vladimir discusses the structure of the app folder in Rails applications and mentions the trend of putting everything in the model folder, and he talks about how Rails applications changed during the API-only era, leading to a shift away from Rails conventions and MVC patterns. [00:13:41] Andrew expresses how he feels vindicated for sticking to writing Rails apps even when the trend shifted towards API-only development. [00:15:08] Vladimir shares his journey to joining Evil Martians, starting as a solo developer, and his attraction to the simplicity of Rails. He mentions his experiments with different design patterns and how joining Evil Martians provided a collaborative environment for open source work. [00:19:15] Vladimir talks about how Evil Martians encouraged new engineers to propose conference talks, leading him to present on AnyCable, which sparked his open source contributions. [00:20:18] He talks about how it took a couple of years for his efforts, including writing blog posts and working on AnyCable, to gain recognition and production users outside of Evil Martians. Also, he explains how writing became a way for him to cope with stress and how it contributed to the company's visibility and recognition in the tech community. [00:26:20] We hear about Evil Martians' shift in focus from consumer products to developer tools and how they use and contribute to products built by others. Vladimir briefly discusses HTTPie, and how they helped with its development. [00:28:44] Jason brings up AnyCable, and Vladimir tells us what it is, what problem it solves, and the benefits of using it. Also, he explains how AnyCable allows for seamless replacement of Action Cable in existing applications and its Go-based WebSocket server. [00:32:16] Vladimir mentions that AnyCable has evolved over seven years to offer additional features, including support for different transports and service-sent events, making it versatile for various use cases. [00:34:08] Vladimir discusses the versatility of AnyCable, highlighting that it can be deployed anywhere and used with platforms beyond Rails. He mentions that AnyCable is becoming the default choice for handling WebSockets in Rails applications as they continue to expand their reach into other ecosystems.[00:38:09] We hear about some upcoming features for AnyCable, including presence tracking, and plans to make AnyCable compatible with other ecosystems. Vladimir teases a new feature he's working on for Rails and Turbo.[00:43:04] Andrew shares that he used to read Vladimir's code on GitHub to learn new patterns and gain inspiration for his own work. He mentions reading code from different libraries and ecosystems is a powerful way to expand one's toolkit for problem-solving.[00:43:47] Vladimir suggests the idea of a podcast or show where experts review codebases and discuss patterns, techniques, and the rationale behind certain code decisions. He believes it could be a great way to learn and share knowledge. [00:45:36] Jason shares that he appreciates Vladimir's contributions to Ruby on Rails and the high-quality content shared by Evil Martian's on their blog. [00:46:36] Find out where you can find Vladimir online.Panelists:Jason CharnesAndrew MasonGuest:Vladimir DementyevSponsor:HoneybadgerLinks:Jason Charnes TwitterChris Oliver TwitterAndrew Mason TwitterVladimir Dementyev TwitterVladimir Dementyev GitHubStimulusReflex DiscordEvil MartiansLayered Design for Ruby on Rails Applications: Discover practical design patterns for maintainable web applications by Vladimir DementyevAnyCableHTTPieRails World 2023Ruby for All Podcast
In episode 134 of Jamstack Radio, Brian speaks with Victoria Melnikova of Evil Martians. They discuss commercializing open source projects for improved feedback loops and longterm sustainability, as well as the importance of technical marketing.
In episode 134 of Jamstack Radio, Brian speaks with Victoria Melnikova of Evil Martians. They discuss commercializing open source projects for improved feedback loops and longterm sustainability, as well as the importance of technical marketing.
This week we are joined by Andrey Sitnik, the creator of PostCSS, Browserslist, Autoprefixer, and many other tools. We talk about the origins of PostCSS, the future of CSS, and the power of open source and distributed applications. We also go into OKLCH, a new color format that Andrey has been working on tooling for. https://github.com/ai https://sitnik.ru/en/ https://twitter.com/sitnikcode Become a paid subscriber our patreon, spotify, or apple podcasts for the full episode. https://www.patreon.com/devtoolsfm https://podcasters.spotify.com/pod/show/devtoolsfm/subscribe https://podcasts.apple.com/us/podcast/devtools-fm/id1566647758 https://www.youtube.com/@devtoolsfm/membership
Irina Nazarova is CEO of Evil Martians, a product development consultancy that works with startups and established businesses while creating open-source products and services. Victoria talks to Irina about getting a sense of what people are interested in learning about or what kind of problems they have, how consulting and product development complement each other, and of course, the question on everyone's minds: Is Evil Martians really evil?
This week we're joined by Irina Nazarova, CEO of Evil Martians. Evil Martians is a consultancy that has created and amazing open source catalog with projects like PostCSS, AnyCable, and ImgProxy. We talk about her background, stepping into leadership, and commercial open source. https://evilmartians.com https://twitter.com/inazarova https://anycable.io https://imgproxy.net Become a paid subscriber our patreon, spotify, or apple podcasts for the full episode. https://www.patreon.com/devtoolsfm https://podcasters.spotify.com/pod/show/devtoolsfm/subscribe https://podcasts.apple.com/us/podcast/devtools-fm/id1566647758
Listen to Brittany Martin (The Ruby on Rails Podcast), Jason Charnes (Remote Ruby) and Paul Bahr (Peachtree Sound) as they interview guests from the community on a live podcast at Railsconf 2023 in Atlanta, GA. Guest #1: Aaron Patterson, Senior Staff Engineer at Shopify (https://twitter.com/tenderlove) Guest #2: Irina Nazarova, CEO of Evil Martians (https://twitter.com/inazarova) Guest #3: Voted on by the community in an online poll: Justin Searls, Meta Programmer at Test Double (https://twitter.com/searls?lang=en) Guest #4: Voted on by the community live at this session: Britni Alexander, Senior Software Engineer (https://twitter.com/TwitniTheGirl) Our Vanna White of Guest Selection: Danielle Greaves, Lead Web Developer, Pittsburgh Cultural Trust (https://twitter.com/danigirl329) Show Notes: A Ruby Community Podcast Live! | Railsconf 2023 (https://railsconf2023.sessionize.com/session/471526) Peachtree Sound (https://www.peachtreesound.com/meet-paul) Substitute Teacher - Key & Peele - YouTube (https://www.youtube.com/watch?v=Dd7FixvoKBw) Keynote - Aaron Patterson | Railsconf 2023 (https://railsconf2023.sessionize.com/session/471439) Rails as a piece of birthday cake | Railsconf 2023 (https://railsconf2023.sessionize.com/session/452834) Evil Martians (https://evilmartians.com/) N.E.A.T. (Not Everything's About Technology) (https://testdouble.com/neat) Justin's Field Report from RubyKaiji (https://testdouble.com/field) Hire Britni! | LinkedIn (https://www.linkedin.com/in/britnia) Sponsored By: Honeybadger (https://www.honeybadger.io/) You won't know if Honeybadger will really save you time and trouble until you see how it works in your own toolchain. With two lines of code and five minutes, you can see for yourself. Honeybadger automatically hooks into popular web frameworks, job systems, authentication libraries, and front-end JavaScript. Get started today in as little as 5 minutes at Honeybadger.io (https://www.honeybadger.io/) with plans starting at free!
This is a special episode from RailsConf 2023 Atlanta, where we're having a Ruby Community Podcast LIVE! Today, we have on the panel Brittany Martin, Co-host of The Ruby on Rails Podcast, our very own Jason Charnes, and Paul Bahr, Audio Editor from Peachtree Sound, who edits over a dozen tech podcasts. We also have some great guests joining us: Aaron “tenderlove” Patterson, Irina Nazarova, Justin Searls, and Britni Alexander, who was selected by the audience to be our fourth guest. Today, our guests share some stories about who they are and what they do, give shout-outs, and answer questions from our audience. Hit download now to hear more! [00:04:30] We start with Aaron “Tenderlove” Patterson, sharing the origin of his nickname. [00:06:05] Since Aaron has switched companies over the years, he tells how his job has changed a lot, and how he spends one hundred percent doing open source at Shopify. [00:08:05] A question from the audience comes up on what Aaron is looking most forward to working on this year. He mentions some spoilers. [00:10:38] Since Aaron has been working Ruby and Rails for so long, Brittany asks if there's ever been a community that may have tempted him to leave. His answer is no. [00:11:44] Aaron leaves us with a shout-out to Mushroom Hunting since he is a mycologist. [00:12:46] Our next guest is Irina Nazarova, co-founder of Evil Martians, who tells us she had a dream that Brittany would invite her on a podcast. [00:15:44] Irina explains that consulting allows them to understand user needs, which they use to build useful tools.[00:16:44] She explains the open source products they build are a byproduct of consulting work, and they allocate resources to work on them once they show traction.[00:18:44] The focus here is on startups and if she recommends Ruby and Rails to startups. [00:19:51] An audience question comes up for Irina on how does Evil Martians foster the environment for a great company blog? She tells us about her great editors and the blog articles that bring value to the company. [00:21:23] Irina makes a shout-out for people to support Ukraine during the war.[00:23:18] Next, we have joining us Justin Searls, co-founder of Test Double, and Britni Alexander, former employee at Mailchimp. They introduce themselves and tell us a little bit about what they do. [00:27:48] Justin discusses his favorite talk he's given, “How to Scratch an Itch.”[00:29:14] Britni tells us her ideal job and her struggle to balance being kind and direct. [00:30:05] Justin tells us about an upcoming project called, N.E.A.T, which is focused on discussing ways to make software better that are not related to technology. [00:32:15] Britni talks about what her ideal job would be. [00:33:05] We hear about the RubyKaigi conference in Japan and Justin's plans to attend and report on it. [00:35:30] Britni gives a shout-out to her friend Eileen for being her friend, and Justin expresses his gratitude for the opportunities and connections he's gained through the Ruby community. Moderator:Brittany MartinPanelists:Jason CharnesPaul BahrGuests:Aaron PattersonIrina NazarovaJustin SearlsBritni AlexanderSponsor:HoneybadgerLinks:Jason Charnes TwitterBrittany Martin TwitterThe Ruby on Rails Podcast Aaron Patterson TwitterTenderlove Making ShopifyIrina Nazarova TwitterEvil MartiansJustin Searls WebsiteJustin Searls TwitterTest DoubleTest Double N.E.A.T. communityHow to Scratch an Itch-Justin Searls talk at ng-conf (YouTube)Britni Alexander LinkedInRubyKaigi 2023RubyKaigi 2023 Field Report Blue Ridge Ruby 2023
This week, Irina Nazarova and I discuss the way we think about building features. We get into the kinds of questions you should ask at the beginning of a project, using feedback loops to make sure you understand the user's needs, the propensity of users to muddle through using software rather than reading documentation, releasing smaller chunks of work frequently to limit risk, and focusing on helping the user rather than on the tech. We also discuss upcoming conferences and our travel plans.Irina Nazarova on TwitterIrina Nazarova on LinkedInEvil Martians.comDon't Make Me Think by Steve KrugA Different Way to Think About Rails ModelsRazom for UkraineNova UkraineWorld Central Kitchen
Andrey Sitnik from Evil Martians talks with us about why OKCLH is the best way forward for color on the web, how to incorporate it into design systems, getting your designers to use OKCLH, and what kind of fallback support is needed.
This episode, I'm joined by Irina Nazarova, CEO of Evil Martians for a discussion of her time in Portugal, her time with Evil Martians and her previous experience with startups, my hair salon software, and how focusing on the user can influence design decisions.Irina Nazarova on TwitterIrina Nazarova on LinkedInEvil Martians.comNova UkraineRazom for UkraineWorld Central Kitchen
Guest Geoff Harcourt, CTO of CommonLit, joins Joël to talk about a thing that comes up with a lot with clients: the performance of their test suite. It's often a concern because with test suites, until it becomes a problem, people tend to not treat it very well, and people ask for help on making their test suites faster. Geoff shares how he handles a scenario like this at CommonLit. This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. Geoff Harcourt (https://twitter.com/geoffharcourt) Common Lit (https://www.commonlit.org/) Cuprite driver (https://cuprite.rubycdp.com/) Chrome DevTools Protocol (CDP) (https://chromedevtools.github.io/devtools-protocol/) Factory Doctor (https://test-prof.evilmartians.io/#/profilers/factory_doctor) Joël's RailsConf talk (https://www.youtube.com/watch?v=LOlG4kqfwcg) Formal Methods (https://www.hillelwayne.com/post/formally-modeling-migrations/) Rails multi-database support (https://guides.rubyonrails.org/active_record_multiple_databases.html) Knapsack pro (https://knapsackpro.com/) Prior episode with Eebs (https://www.bikeshed.fm/353) Shopify article on skipping specs (https://shopify.engineering/spark-joy-by-running-fewer-tests) Transcript: JOËL: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Joël Quenneville. And today, I'm joined by Geoff Harcourt, who is the CTO of CommonLit. GEOFF: Hi, Joël. JOËL: And together, we're here to share a little bit of what we've learned along the way. Geoff, can you briefly tell us what is CommonLit? What do you do? GEOFF: CommonLit is a 501(c)(3) non-profit that delivers a literacy curriculum in English and Spanish to millions of students around the world. Most of our tools are free. So we take a lot of pride in delivering great tools to teachers and students who need them the most. JOËL: And what does your role as CTO look like there? GEOFF: So we have a small engineering team. There are nine of us, and we run a Rails monolith. I'd say a fair amount of the time; I'm hands down in the code. But I also do the things that an engineering head has to do, so working with vendors, and figuring out infrastructure, and hiring, and things like that. JOËL: So that's quite a variety of things that you have to do. What is new in your world? What's something that you've encountered recently that's been fun or interesting? GEOFF: It's the start of the school year in America, so traffic has gone from a very tiny amount over the summer to almost the highest load that we'll encounter all year. So we're at a new hosting provider this fall. So we're watching our infrastructure and keeping an eye on it. The analogy that we've been using to describe this is like when you set up a bunch of plumbing, it looks like it all works, but until you really pump water through it, you don't see if there are any leaks. So things are in good shape right now, but it's a very exciting time of year for us. JOËL: Have you ever done some actual plumbing yourself? GEOFF: I am very, very bad at home repair. But I have fixed a toilet or two. I've installed a water filter but nothing else. What about you? JOËL: I've done a little bit of it when I was younger with my dad. Like, I actually welded copper pipes and that kind of thing. GEOFF: Oh, that's amazing. That's cool. Nice. JOËL: So I've definitely felt that thing where you turn the water source back on, and it's like, huh, let's see, is this joint going to leak, or are we good? GEOFF: Yeah, they don't have CI for plumbing, right? JOËL: [laughs] You know, test it in production, right? GEOFF: Yeah. [laughs] So we're really watching right now traffic starting to rise as students and teachers are coming back. And we're also figuring out all kinds of things that we want to do to do better monitoring of our application, so some of this is watching metrics to see if things happen. But some of this is also doing some simulated user activity after we do deploys. So we're using some automated browsers with Cypress to log into our application and do some user flows, and then report back on the results. JOËL: So is this kind of like a feature test in CI, except that you're running it in production? GEOFF: Yeah. Smoke test is the word that we've settled on for it, but we run it against our production server every time we deploy. And it's a small suite. It's nowhere as big as our big Capybara suite that we run in CI, but we're trying to get feedback in less than six minutes. That's sort of the goal. In addition to running tests, we also take screenshots with a tool called Percy, and that's a visual regression testing tool. So we get to see the screenshots, and if they differ by more than one pixel, we get a ping that lets us know that maybe our CSS has moved around or something like that. JOËL: Has that caught some visual bugs for you? GEOFF: Definitely. The state of CSS at CommonLit was very messy when I arrived, and it's gotten better, but it still definitely needs some love. There are some false positives, but it's been really, really nice to be able to see visual changes on our production pages and then be able to approve them or know that there's something we have to go back and fix. JOËL: I'm curious, for this smoke test suite, how long does it take to run? GEOFF: We run it in parallel. It runs on Buildkite, which is the same tool that we use to orchestrate our CI, and the longest test takes about five minutes. It signs in as a teacher, creates an account. It creates a class; it invites the student to that class. It then logs out, logs in as that student creates the student account, signs in as the student, joins the class. It then assigns a lesson to the student then the student goes and takes the lesson. And then, when the student submits the lesson, then the test is over. And that confirms all of the most critical flows that we would want someone to drop what they were doing if it's broken, you know, account creation, class creation, lesson creation, and students taking a lesson. JOËL: So you're compressing the first few weeks of school into five minutes. GEOFF: Yes. And I pity the school that has thousands of fake teachers, all named Aaron McCarronson at the school. JOËL: [laughs] GEOFF: But we go through and delete that data every once in a while. But we have a marketer who just started at CommonLit maybe a few weeks ago, and she thought that someone was spamming our signup form because she said, "I see hundreds of teachers named Aaron McCarronson in our user list." JOËL: You had to admit that you were the spammer? GEOFF: Yes, I did. [laughs] We now have some controls to filter those people out of reports. But it's always funny when you look at the list, and you see all these fake people there. JOËL: Do you have any rate limiting on your site? GEOFF: Yeah, we do quite a bit of it, actually. Some of it we do through Cloudflare. We have tools that limit a certain flow, like people trying to credential stuffing our password, our user sign-in forms. But we also do some further stuff to prevent people from hitting key endpoints. We use Rack::Attack, which is a really nice framework. Have you had to do that in client work with clients setting that stuff up? JOËL: I've used Rack:Attack before. GEOFF: Yeah, it's got a reasonably nice interface that you can work with. And I always worry about accidentally setting those things up to be too sensitive, and then you get lots of stuff back. One issue that we sometimes find is that lots of kids at the same school are sharing an IP address. So that's not the thing that we want to use for rate limiting. We want to use some other criteria for rate limiting. JOËL: Right, right. Do you ever find that you rate limit your smoke tests? Or have you had to bypass the rate limiting in the smoke tests? GEOFF: Our smoke tests bypass our rate limiting and our bot detection. So they've got some fingerprints they use to bypass that. JOËL: That must have been an interesting day at the office. GEOFF: Yes. [laughter] With all of these things, I think it's a big challenge to figure out, and it's similar when you're making tests for development, how to make tests that are high signal. So if a test is failing really frequently, even if it's testing something that's worthwhile, if people start ignoring it, then it stops having value as a piece of signal. So we've invested a ton of time in making our test suite as reliable as possible, but you sometimes do have these things that just require a change. I've become a really big fan of...there's a Ruby driver for Capybara called Cuprite, and it doesn't control chrome with Chrome Driver or with Selenium. It controls it with the Chrome DevTools protocol, so it's like a direct connection into the browser. And we find that it's very, very fast and very, very reliable. So we saw that our Capybara specs got significantly more reliable when we started using this as our driver. JOËL: Is this because it's not actually moving the mouse around and clicking but instead issuing commands in the background? GEOFF: Yeah. My understanding of this is a little bit hazy. But I think that Selenium and ChromeDriver are communicating over a network pipe, and sometimes that network pipe is a little bit lossy. And so it results in asynchronous commands where maybe you don't get the feedback back after something happens. And CDP is what Chrome's team and I think what Puppeteer uses to control things directly. So it's great. And you can even do things with it. Like, you can simulate different time zone for a user almost natively. You can speed up or slow down the traveling of time and the direction of time in the browser and all kinds of things like that. You can flip it into mobile mode so that the device reports that it's a touch browser, even though it's not. We have a set of mobile specs where we flip it with CDP into mobile mode, and that's been really good too. Do you find when you're doing client work that you have a demand to build mobile-specific specs for system tests? JOËL: Generally not, no. GEOFF: You've managed to escape it. JOËL: For something that's specific to mobile, maybe one or two tests that have a weird interaction that we know is different on mobile. But in general, we're not doing the whole suite under mobile and the whole suite under desktop. GEOFF: When you hand off a project...it's been a while since you and I have worked together. JOËL: For those who don't know, Geoff used to be with us at thoughtbot. We were colleagues. GEOFF: Yeah, for a while. I remember my very first thoughtbot Summer Summit; you gave a really cool lightning talk about Eleanor of Aquitaine. JOËL: [laughs] GEOFF: That was great. So when you're handing a project off to a client after your ending, do you find that there's a transition period where you're educating them about the norms of the test suite before you leave it in their hands? JOËL: It depends a lot on the client. With many clients, we're working alongside an existing dev team. And so it's not so much one big handoff at the end as it is just building that in the day-to-day, making sure that we are integrating with the team from the outset of the engagement. So one thing that does come up a lot with clients is the performance of their test suite. That's often a concern because the test suite until it becomes a problem, people tend to not treat it very well. And by the time that you're bringing on an external consultant to help, generally, that's one of the areas of the code that's been a little bit neglected. And so people ask for help on making their test suite faster. Is that something that you've had to deal with at CommonLit as well? GEOFF: Yeah, that's a great question. We have struggled a lot with the speed that our test suite...the time it takes for our test suite to run. We've done a few things to improve it. The first is that we have quite a bit of caching that we do in our CI suite around dependencies. So gems get cached separately from NPM packages and browser assets. So all three of those things are independently cached. And then, we run our suites in parallel. Our Jest specs get split up into eight containers. Our Ruby non-system tests...I'd like to say unit tests, but we all know that some of those are actually integration tests. JOËL: [laughs] GEOFF: But those tests run in 15 containers, and they start the moment gems are built. So they don't wait for NPM packages. They don't wait for assets. They immediately start going. And then our system specs as soon as the assets are built kick off and start running. And we actually run that in 40 parallel containers so we can get everything finished. So our CI suite can finish...if there are no dependency bumps and no asset bumps, our specs suite you can finish in just under five minutes. But if you add up all of that time, cumulatively, it's something like 75 minutes is the total execution as it goes. Have you tried FactoryDoctor before for speeding up test suites? JOËL: This is the gem from Evil Martians? GEOFF: Yeah, it's part of TestProf, which is their really, really unbelievable toolkit for improving specs, and they have a whole bunch of things. But one of them will tell you how many invocations of FactoryBot factories each factory got. So you can see a user factory was fired 13,000 times in the test suite. It can even do some tagging where it can go in and add metadata to your specs to show which ones might be candidates for optimization. JOËL: I gave a talk at RailsConf this year titled Your Tests Are Making Too Many Database Calls. GEOFF: Nice. JOËL: And one of the things I talked about was creating a lot more data via factories than you think that you are. And I should give a shout-out to FactoryProf for finding those. GEOFF: Yeah, it's kind of a silent killer with the test suite, and you really don't think that you're doing a whole lot with it, and then you see how many associations. How do you fight that tension between creating enough data that things are realistic versus the streamlining of not creating extraneous things or having maybe mystery guests via associations and things like that? JOËL: I try to have my base factories be as minimal as possible. So if there's a line in there that I can remove, and the factory or the model still saves, then it should be removed. Some associations, you can't do that if there's a foreign key constraint, and so then I'll leave it in. But I am a very hardcore minimalist, at least with the base factory. GEOFF: I think that makes a lot of sense. We use foreign keys all over the place because we're always worried about somehow inserting student data that we can't recover with a bug. So we'd rather blow up than think we recorded it. And as a result, sometimes setting up specs for things like a student answering a multiple choice question on a quiz ends up being this sort of if you give a mouse a cookie thing where it's you need the answer options. You need the question. You need the quiz. You need the activity. You need the roster, the students to be in the roster. There has to be a teacher for the roster. It just balloons out because everything has a foreign key. JOËL: The database requires it, but the test doesn't really care. It's just like, give me a student and make it valid. GEOFF: Yes, yeah. And I find that that challenge is really hard. And sometimes, you don't see how hard it is to enforce things like database integrity until you have a lot of concurrency going on in your application. It was a very rude surprise to me to find out that browser requests if you have multiple servers going on might not necessarily be served in the order that they were made. JOËL: [laughs] So you're talking about a scenario where you're running multiple instances of your app. You make two requests from, say, two browser tabs, and somehow they get served from two different instances? GEOFF: Or not even two browser tabs. Imagine you have a situation where you're auto-saving. JOËL: Oooh, background requests. GEOFF: Yeah. So one of the coolest features we have at CommonLit is that students can annotate and highlight a text. And then, the teachers can see the annotations and highlights they've made, and it's actually part of their assignment often to highlight key evidence in a passage. And those things all fire in the background asynchronously so that it doesn't block the student from doing more stuff. But it also means that potentially if they make two changes to a highlight really quickly that they might arrive out of order. So we've had to do some things to make sure that we're receiving in the right order and that we're not blowing away data that was supposed to be there. Just think about in a Heroku environment, for example, which is where we used to be, you'd have four dynos running. If dyno one takes too long to serve the thing for dyno two, request one may finish after request two. That was a very, very rude surprise to learn that the world was not as clean and neat as I thought. JOËL: I've had to do something similar where I'm making a bunch of background requests to a server. And even with a single dyno, it is possible for your request to come back out of order just because of how TCP works. So if it's waiting for a packet and you have two of these requests that went out not too long before each other, there's no guarantee that all the packets for request one come back before all the packets from request two. GEOFF: Yeah, what are the strategies for on the client side for dealing with that kind of out-of-order response? JOËL: Find some way to effectively version the requests that you make. Timestamp is an easy one. Whenever a request comes in, you take the response from the latest timestamp, and that wins out. GEOFF: Yeah, we've started doing some unique IDs. And part of the unique ID is the browser's timestamp. We figure that no one would try to hack themselves and intentionally screw up their own data by submitting out of order. JOËL: Right, right. GEOFF: It's funny how you have to pick something to trust. [laughs] JOËL: I'd imagine, in this case, if somebody did mess around with it, they would really only just be screwing up their own UI. It's not like that's going to then potentially crash the server because of something, and then you've got a potential vector for a denial of service. GEOFF: Yeah, yeah, that's always what we're worried about, and we have to figure out how to trust these sorts of requests as what's a valid thing and what is, as you're saying, is just the user hurting themselves as opposed to hurting someone else's stuff? MID-ROLL AD: Debugging errors can be a developer's worst nightmare...but it doesn't have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half. So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! Airbrake's debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. In addition to stellar error monitoring, Airbrake's lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today! GEOFF: You were talking about test suites. What are some things that you have found are consistently problems in real-world apps, but they're really, really hard to test in a test suite? JOËL: Difficult to test or difficult to optimize for performance? GEOFF: Maybe difficult to test. JOËL: Third-party integrations. Anything that's over the network that's going to be difficult. Complex interactions that involve some heavy frontend but then also need a lot of backend processing potentially with asynchronous workers or something like that, there are a lot of techniques that we can use to make all those play together, but that means there's a lot of complexity in that test. GEOFF: Yeah, definitely. I've taken a deep interest in what I'm sure there's a better technical term for this, but what I call network hostile environments or bandwidth hostile environments. And we see this a lot with kids. Especially during the pandemic, kids would often be trying to do their assignments from home. And maybe there are five kids in the house, and they're all trying to do their homework at the same time. And they're all sharing a home internet connection. Maybe they're in the basement because they're trying to get some peace and quiet so they can do their assignment or something like that. And maybe they're not strongly connected. And the challenge of dealing with intermittent connectivity is such an interesting problem, very frustrating but very interesting to deal with. JOËL: Have you explored at all the concept of Formal Methods to model or verify situations like that? GEOFF: No, but I'm intrigued. Tell me more. JOËL: I've not tried it myself. But I've read some articles on the topic. Hillel Wayne is a good person to follow for this. GEOFF: Oh yeah. JOËL: But it's really fascinating when you'll see, okay, here are some invariants and things. And then here are some things that you set up some basic properties for a system. And then some of these modeling languages will then poke holes and say, hey, it's possible for this 10-step sequence of events to happen that will then crash your server. Because you didn't think that it's possible for five people to be making concurrent requests, and then one of them fails and retries, whatever the steps are. So it's really good at modeling situations that, as developers, we don't always have great intuition, things like parallelism. GEOFF: Yeah, that sounds so interesting. I'm going to add that to my list of reading for the fall. Once the school year calms down, I feel like I can dig into some technical topics again. I've got this book sitting right next to my desk, Designing Data-Intensive Applications. I saw it referenced somewhere on Twitter, and I did the thing where I got really excited about the book, bought it, and then didn't have time to read it. So it's just sitting there unopened next to my desk, taunting me. JOËL: What's the 30-second spiel for what is a data-intensive app, and why should we design for it differently? GEOFF: You know, that's a great question. I'd probably find out if I'd dug further into the book. JOËL: [laughs] GEOFF: I have found at CommonLit that we...I had a couple of clients at thoughtbot that dealt with data at the scale that we deal with here. And I'm sure there are bigger teams doing, quote, "bigger data" than we're doing. But it really does seem like one of our key challenges is making sure that we just move data around fast enough that nothing becomes a bottleneck. We made a really key optimization in our application last year where we changed the way that we autosave students' answers as they go. And it resulted in a massive increase in throughput for us because we went from trying to store updated versions of the students' final answers to just storing essentially a draft and often storing that draft in local storage in the browser and then updating it on the server when we could. And then, as a result of this, we're making key updates to the table where we store a student's answers much less frequently. And that has a huge impact because, in addition to being one of the biggest tables at CommonLit...it's got almost a billion recorded answers that we've gotten from students over the years. But because we're not writing to it as often, it also means that reads that are made from the table, like when the teacher is getting a report for how the students are doing in a class or when a principal is looking at how a school is doing, now, those queries are seeing less contention from ongoing writes. And so we've seen a nice improvement. JOËL: One strategy I've seen for that sort of problem, especially when you have a very write-heavy table but that also has a different set of users that needs to read from it, is to set up a read replica. So you have your main that is being written to, and then the read replica is used for reports and people who need to look at the data without being in contention with the table being written. GEOFF: Yeah, Rails multi-DB support now that it's native to the framework is excellent. It's so nice to be able to just drop that in and fire it up and have it work. We used to use a solution that Instacart had built. It was great for our needs, but it wasn't native to the framework. So every single time we upgraded Rails, we had to cross our fingers and hope that it didn't, you know, whatever private APIs of ActiveRecord it was using hadn't broken. So now that that stuff, which I think was open sourced from GitHub's multi-database implementation, so now that that's all native in Rails, it's really, really nice to be able to use that. JOËL: So these kinds of database tricks can help make the application much more performant. You'd mentioned earlier that when you were trying to make your test performant that you had introduced parallelism, and I feel like that's maybe a bit of an intimidating thing for a lot of people. How would you go about converting a test suite that's just vanilla RSpec, single-threaded, and then moving it in a direction of being more parallel? GEOFF: There's a really, really nice tool called Knapsack, which has a free version. But the pro version, I feel like if you're spending any money at all on CI, it's immediately worth the cost. I think it's something like $75 a month for each suite that you run on it. And Knapsack does this dynamic allocation of tests across containers. And it interfaces with several of the popular CI providers so that it looks at environment variables and can tell how many containers you're splitting across. It'll do some things, like if some of your containers start early and some of them start late, it will distribute the work so that they all end at the same time, which is really nice. We've preferred CI providers that charge by the minute. So rather than just paying for a service that we might not be using, we've used services like Semaphore, and right now, we're on Buildkite, which charge by the minute, which means that you can decide to do as much parallelism as you want. You're just paying for the compute time as you run things. JOËL: So that would mean that two minutes of sequential build time costs just the same as splitting it up in parallel and doing two simultaneous minutes of build time. GEOFF: Yeah, that is almost true. There's a little bit of setup time when a container spins up. And that's one of the key things that we optimize. I guess if we ran 200 containers if we were like Shopify or something like that, we could technically make our CI suite finish faster, but it might cost us three times as much. Because if it takes a container 30 seconds to spin up and to get ready, that's 30 seconds of dead time when you're not testing, but you're paying for the compute. So that's one of the key optimizations that we make is figuring out how many containers do we need to finish fast when we're not just blowing time on starting and finishing? JOËL: Right, because there is a startup cost for each container. GEOFF: Yeah, and during the work day when our engineers are working along, we spin up 200 EC2 machines or 150 EC2 machines, and they're there in the fleet, and they're ready to go to run CI jobs for us. But if you don't have enough machines, then you have jobs that sit around waiting to start, that sort of thing. So there's definitely a tension between figuring out how much parallelism you're going to do. But I feel like to start; you could always break your test suite into four pieces or two pieces and just see if you get some benefit to running a smaller number of tests in parallel. JOËL: So, manually splitting up the test suite. GEOFF: No, no, using something like Knapsack Pro where you're feeding it the suite, and then it's dividing up the tests for you. I think manually splitting up the suite is probably not a good practice overall because I'm guessing you'll probably spend more engineering time on fiddling with which tests go where such that it wouldn't be cost-effective. JOËL: So I've spent a lot of time recently working to improve a parallel test suite. And one of the big problems that you have is trying to make sure that all of your parallel surfaces are being used efficiently, so you have to split the work evenly. So if you said you have 70 minutes worth of work, if you give 50 minutes to one worker and 20 minutes to the other, that means that your total test suite is still 50 minutes, and that's not good. So ideally, you split it as evenly as possible. So I think there are three evolutionary steps on the path here. So you start off, and you're going to manually split things out. So you're going to say our biggest chunk of tests by time are the feature specs. We'll make them almost like a separate suite. Then we'll make the models and controllers and views their own thing, and that's roughly half and half, and run those. And maybe you're off by a little bit, but it's still better than putting them all in one. It becomes difficult, though, to balance all of these because then one might get significantly longer than the other then, you have to manually rebalance it. It works okay if you're only splitting it among two workers. But if you're having to split it among 4, 8, 16, and more, it's not manageable to do this, at least not by hand. If you want to get fancy, you can try to automate that process and record a timing file of how long every file takes. And then when you kick off the build process, look at that timing file and say, okay, we have 70 minutes, and then we'll just split the file so that we have roughly 70 divided by number of workers' files or minutes of work in each process. And that's what gems like parallel_tests do. And Knapsack's Classic mode works like this as well. That's decently good. But the problem is you're working off of past information. And so if the test has changed or just if it's highly variable, you might not get a balanced set of workers. And as you mentioned, there's a startup cost, and so not all of your workers boot up at the same time. And so you might still have a very uneven amount of work done by each worker by statically determining the work to be done via a timing file. So the third evolution here is a dynamic or a self-balancing approach where you just put all of the tests or the files in a queue and then just have every worker pull one or two tests when it's ready to work. So that way, if something takes a lot longer than expected, well, it's just not pulling more from the queue. And everybody else still pulls, and they end up all balancing each other out. And then ideally, every worker finishes work at exactly the same time. And that's how you know you got the most value you could out of your parallel processes. GEOFF: Yeah, there's something about watching all the jobs finish in almost exactly, you know, within 10 seconds of each other. It just feels very, very satisfying. I think in addition to getting this dynamic splitting where you're getting either per file or per example split across to get things finishing at the same time, we've really valued getting fast feedback. So I mentioned before that our Jest specs start the moment NPM packages get built. So as soon as there's JavaScripts that can be executed in test, those kick-off. As soon as our gems are ready, the RSpec non-system tests go off, and they start running specs immediately. So we get that really, really fast feedback. Unfortunately, the browser tests take the longest because they have to wait for the most setup. They have the most dependencies. And then they also run the slowest because they run in the browser and everything. But I think when things are really well-oiled, you watch all of those containers end at roughly the same time, and it feels very satisfying. JOËL: So, a few weeks ago, on an episode of The Bike Shed, I talked with Eebs Kobeissi about dependency graphs and how I'm super excited about it. And I think I see a dependency graph in what you're describing here in that some things only depend on the gem file, and so they can start working. But other things also depend on the NPM packages. And so your build pipeline is not one linear process or one linear process that forks into other linear processes; it's actually a dependency graph. GEOFF: That is very true. And the CI tool we used to use called Semaphore actually does a nice job of drawing the dependency graph between all of your steps. Buildkite does not have that, but we do have a bunch of steps that have to wait for other steps to finish. And we do it in our wiki. On our repo, we do have a diagram of how all of this works. We found that one of the things that was most wasteful for us in CI was rebuilding gems, reinstalling NPM packages (We use Yarn but same thing.), and then rebuilding browser assets. So at the very start of every CI run, we build hashes of a bunch of files in the repository. And then, we use those hashes to name Docker images that contain the outputs of those files so that we are able to skip huge parts of our CI suite if things have already happened. So I'll give an example if Ruby gems have not changed, which we would know by the Gemfile.lock not having changed, then we know that we can reuse a previously built gems image that has the gems that just gets melted in, same thing with yarn.lock. If yarn.lock hasn't changed, then we don't have to build NPM packages. We know that that already exists somewhere in our Docker registry. In addition to skipping steps by not redoing work, we also have started to experiment...actually, in response to a comment that Chris Toomey made in a prior Bike Shed episode, we've started to experiment with skipping irrelevant steps. So I'll give an example of this if no Ruby files have changed in our repository, we don't run our RSpec unit tests. We just know that those are valid. There's nothing that needs to be rerun. Similarly, if no JavaScript has changed, we don't run our Jest tests because we assume that everything is good. We don't lint our views with erb-lint if our view files haven't changed. We don't lint our factories if the model or the database hasn't changed. So we've got all these things to skip key types of processing. I always try to err on the side of not having a false pass. So I'm sure we could shave this even tighter and do even less work and sometimes finish the build even faster. But I don't want to ever have a thing where the build passes and we get false confidence. JOËL: Right. Right. So you're using a heuristic that eliminates the really obvious tests that don't need to be run but the ones that maybe are a little bit more borderline, you keep them in. Shaving two seconds is not worth missing a failure. GEOFF: Yeah. And I've read things about big enterprises doing very sophisticated versions of this where they're guessing at which CI specs might be most relevant and things like that. We're nowhere near that level of sophistication right now. But I do think that once you get your test suite parallelized and you're not doing wasted work in the form of rebuilding dependencies or rebuilding assets that don't need to be rebuilt, there is some maybe not low, maybe medium hanging fruit that you can use to get some extra oomph out of your test suite. JOËL: I really like that you brought up this idea of infrastructure and skipping. I think in my own way of thinking about improving test suites, there are three broad categories of approaches you can take. One variable you get to work with is that total number of time single-threaded, so you mentioned 70 minutes. You can make that 70 minutes shorter by avoiding database writes where you don't need them, all the common tricks that we would do to actually change the test themselves. Then we can change...as another variable; we get to work with parallelism, we talked about that. And then finally, there's all that other stuff that's not actually executing RSpec like you said, loading the gems, installing NPM packages, Docker images. All of those, if we can skip work running migrations, setting up a database, if there are situations where we can improve the speed there, that also improves the total time. GEOFF: Yeah, there are so many little things that you can pick at to...like, one of the slowest things for us is Elasticsearch. And so we really try to limit the number of specs that use Elasticsearch if we can. You actually have to opt-in to using Elasticsearch on a spec, or else we silently mock and disable all of the things that happen there. When you're looking at that first variable that you were talking about, just sort of the overall time, beyond using FactoryDoctor and FactoryProf, is there anything else that you've used to just identify the most egregious offenders in a test suite and then figure out if they're worth it? JOËL: One thing you can do is hook into Active Support notification to try to find database writes. And so you can find, oh, here's where all of the...this test is making way too many database writes for some reason, or it's making a lot, maybe I should take a look at it; it's a hotspot. GEOFF: Oh, that's really nice. There's one that I've always found is like a big offender, which is people doing negative expectations in system specs. JOËL: Oh, for their Capybara wait time. GEOFF: Yeah. So there's a really cool gem, and the name of it is eluding me right now. But there's a gem that raises a special exception if Capybara waits the full time for something to happen. So it lets you know that those things exist. And so we've done a lot of like hunting for...Knapsack will report the slowest examples in your test suite. So we've done some stuff to look for the slowest files and then look to see if there are examples of these negative expectations that are waiting 10 seconds or waiting 8 seconds before they fail. JOËL: Right. Some files are slow, but they're slow for a reason. Like, a feature spec is going to be much slower than a model test. But the model tests might be very wasteful and because you have so many of them, if you're doing the same pattern in a bunch of them or if it's a factory that's reused across a lot of them, then a small fix there can have some pretty big ripple effects. GEOFF: Yeah, I think that's true. Have you ever done any evaluation of test suite to see what files or examples you could throw away? JOËL: Not holistically. I think it's more on an ad hoc basis. You find a place, and you're like, oh, these tests we probably don't need them. We can throw them out. I have found dead tests, tests that are not executed but still committed to the repo. GEOFF: [laughs] JOËL: It's just like, hey, I'm going to get a lot of red in my diff today. GEOFF: That always feels good to have that diff-y check-in, and it's 250 lines or 1,000 lines of red and 1 line of green. JOËL: So that's been a pretty good overview of a lot of different areas related to performance and infrastructure around tests. Thank you so much, Geoff, for joining us today on The Bike Shed to talk about your experience at CommonLit doing this. Do you have any final words for our listeners? GEOFF: Yeah. CommonLit is hiring a senior full-stack engineer, so if you'd like to work on Rails and TypeScript in a place with a great test suite and a great team. I've been here for five years, and it's a really, really excellent place to work. And also, it's been really a pleasure to catch up with you again, Joël. JOËL: And, Geoff, where can people find you online? GEOFF: I'm Geoff with a G, G-E-O-F-F Harcourt, @geoffharcourt. And that's my name on Twitter, and it's my name on GitHub, so you can find me there. JOËL: And we'll make sure to include a link to your Twitter profile in the show notes. The show notes for this episode can be found at bikeshed.fm. This show is produced and edited by Mandy Moore. If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. If you have any feedback, you can reach us at @_bikeshed or reach me at @joelquen on Twitter or at hosts@bikeshed.fm via email. Thank you so much for listening to The Bike Shed, and we'll see you next week. Byeeeeeee!!!!!! 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.
Ведущие:
Ведущие:
Irina Nazarova is the CEO of Evil Martians, a consulting company known as authors of PostCSS, AnyCable, imgproxy, and many blog posts and tutorials. She and Brittany discuss both her developer and CEO origin stories, sustainable opensource, leading really talented developers and Google Apps Script. Show Notes & Links: Evil Martians (https://evilmartians.com/) whitequark/parser: A Ruby parser. - GitHub (https://github.com/whitequark/parser) All of the Evil Martians's Open Source Libraries (https://github.com/evilmartians) Google Apps Script (https://developers.google.com/apps-script) Irina Nazarova (@inazarova) · Twitter (https://twitter.com/inazarova) Support Ukraine: Nova Ukraine (https://novaukraine.org/) Razom for Ukraine (https://www.razomforukraine.org/) Sponsored By: Scout APM (http://scoutapm.com/rubyonrails) Try their error monitoring and APM free for 14-days, no credit card needed! And as an added bonus for Ruby on Rails listeners: Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at http://scoutapm.com/rubyonrails (http://scoutapm.com/rubyonrails). Mirror Placement (https://www.mirrorplacement.com/) Mirror Placement are the Ruby on Rails & JavaScript recruiters. They are actively engaged with a wide and deep network of Rails, JavaScript, and Full-Stack Open Source engineers and tech leaders we love, with relationships cultivated over 15 years. Contact Brian, co-host of this podcast, here (https://www.mirrorplacement.com/contact).
Money isn't enough to hire the best product teams. If you want to hire great people to build your product, you need to convince them that your vision has potential. To do this, techies and non-techies alike need to come prepared. Learning notes: A product is a solution to a problem someone is experiencing. You use Uber to get from A to B, not because you want to use an app. Great outsourced product teams like the Evil Martians will question your assumptions and want to validate your idea. If a product team doesn't ask you any questions and just wants to take your money, they are probably not very good, and so you should not work with them. To prepare to work with a great product team, research the problem you are solving and your target users. This research will also be useful if you are fundraising or applying for accelerators. User and problem research is also relevant if you want to get a job in a tech business, invest in tech or lead digital transformation. This will help you stand out at interviews and think like a digital leader. Get my How To Hire Your Product Team & Go From Idea To App: The Non-Technical Founder's Guide Join the Tech for Non-Techies membership community. As a community member, you'll get: Monthly coaching with Sophia Matveeva Live masterclasses with global experts Supportive Online Community Library of masterclasses Exclusive Resources & Perks Learn more and sign up at https://www.techfornontechies.co/membership Say hi to Sophia on Twitter. Following us on Facebook and Instagram will make you smarter.
Steph talks about binging a few Things Worth Learning podcast episodes and particularly enjoyed an episode that featured one of thoughtbot's design directors, Sameera Kapila. Sam shared her expertise about management and inclusion, and Steph shares her favorite parts. Chris shares the story of a surprising error and the resulting journey through database transactions and Sidekiq that eventually resolved the issue. He also shares some follow up on the broken build and the merging process changes they introduced (spoiler, the process changes have been rolled back). Leading Inclusively, with Sameera Kapila - Things Worth Learning Podcast (https://www.youtube.com/watch?v=eiV6_3pZFc0) How to Skim a Pull Request (https://thoughtbot.com/blog/a-smelly-list) Isolator (https://github.com/palkan/isolator) aftercommiteverywhere (https://github.com/Envek/after_commit_everywhere) timefora_boolean (https://github.com/calebhearth/time_for_a_boolean) Transcript: STEPH: Oh man, I'm about to stop eating my pop-tart. I'll put it away. It's within distance. I'm going to eat it. CHRIS: Your high-fat content unfrosted pop-tart. STEPH: You know, surprise Sunday twist: it has icing on it. CHRIS: Steph, who even are you? STEPH: [laughs] CHRIS: There are a few canonical anchor facts that one knows about other people, and when one of those... STEPH: I like to keep everyone, including myself, on their toes. CHRIS: Or you've just secretly accepted that the icing adds another textural flavor adventure component. It's just better with icing. STEPH: All right, all right, all right. There's a complicated answer to this. And the complicated [chuckles] answer to this is that the more organic ingredients that I recognize when reading about pop-tarts are by a particular company, and they all have frosting on them. And the more generic pop-tarts that don't have frosting on them, I don't know how to pronounce a lot of those ingredients. So I'm like, no, but okay, I still eat them. But I prefer the ingredients I can pronounce. So I either go with the ingredients I can't pronounce or have a little bit of frosting on my pop-tart. And I'm going with the non-cancer route for today. CHRIS: For today, in this moment, and accepting the frosting. Okay, all right. Well, that is complicated. [laughs] It's tricky out there. Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. STEPH: And I'm Steph Viccari. CHRIS: And together we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world? STEPH: Hey, Chris. So the weather, I'm going to talk about the weather for a little bit. [chuckles] It's been almost non-stop rain for the past several days, which is fine. I'm sure it's great for plant life. But it's really hard on my dog Utah because then we can't go outside for our normal walks and playtime. Although he is my four-legged water baby because he absolutely loves water, and puddles, and playing in the rain. So he's very fine with going outside and playing for a long time. But then I have to essentially give him a full-on bath before I want to bring him back in. So not wanting to have to give him a bath each time, in the spirit of improvising, we started finding more indoor games to play. And I've started teaching him to play hide and seek. And he's not great at it mainly because he will only stay until I'm out of eyesight, and then he will come and find me. And so I have to be really, really fast at finding a hiding spot to like dash around a corner or hide behind the door. But I think he enjoys it because he will find me and then he seems very excited. And we go back, and we play again. And so I just have to work on teaching him to wait a bit longer so I can find better hiding spots. CHRIS: When you said that, at first, I was like, how did you teach him to hide? But I realize he's only playing the seek part of the game, and you're only playing the hide part of the game. STEPH: [laughs] CHRIS: I'm just so used to you exchange roles back and forth. First, you hide, then you seek, and then you switch it up. That would be a lot to get your dog to be like, now I'm going to secretly hide. STEPH: [laughs] I'd be very impressed. Yes, we have very distinct roles in this game. I am the one that always counts and hides. But he's a very good seeker. So that's been fun. We just got to work on getting a little better at it. But on a more tech-related note, one of the design directors at thoughtbot, Sameera Kapila, who also goes by Sam, was a guest on the podcast Things Worth Learning, which is hosted by Matt Stauffer. And Matt is also the host of The Five-Minute Geek Show and The Laravel Podcast. And in the show Things Worth Learning, Matt meets with individuals that are excited to share something that they're deeply passionate about; maybe it's tech, maybe it's not. And I've binged a couple of those episodes. And I really like how you can choose between the podcast format or the YouTube format. So then you can really watch the conversation unfold, which I know you and I a couple of times have thought it would be fun if people could see us because there are so many facial emotions and gestures that go along with conversations. So it was really delightful. And speaking of delightful, Sam shared her expertise about management and inclusion. And I definitely recommend listening to the episode because I can't share everything that Sam shared. But a couple of the topics that Sam mentioned that I really enjoyed and would love to chat about, so the first one is about helping someone, in this case, someone that you manage that comes to you with a concern. So there's often a presumption that just because someone comes to you with a concern or an issue that they've experienced at work, that they're the ones that will also want to work to address that concern, and that's often not true. It can be true; maybe that person wants to be involved. But they're often coming to you in the leadership or management role to say, "Hey, I've had this issue," and they really want help with that instead of walking away with homework for it. Because then that trains people to essentially be in this mindset of well, if I bring up this concern, then I'm going to be the one that has to address it, even if I'm the one that's most negatively impacted by this. And addressing this concern could be actively harmful to me. And she shared a really great real-world example from her own experience where her and another co-worker had noticed a concern about the hiring process. And her and that co-worker got together, and they talked about the concerns. They even rehearsed for the meeting because they were trained by the tech industry to say, "Hey, if you bring up a concern, you're going to be responsible for addressing and then resolving that concern." And so they had that meeting with the person in leadership. And they were pretty nervous about how it was going to go. And that person in leadership said to them, "Thank you both so much for sharing that. That must have been such a burden. And this is my responsibility to fix. And here are what my next steps are." And that was amazing because it allowed Sam and the other person to go back to client work. And they also received follow-up conversations about how that issue was being addressed. So there was even that feedback loop as to how things were going to change. And I have a personal example that...I really resonated with the example that Sam provided because I remember there are different teams that I've been a part of, where often I was one of the few women engineers on the team. And so we often have conversations about how do we get more women engineers into the company? And they're wonderful conversations. But there's a part of me that always felt resentful about, like, why am I here? Why am I the one fixing this? I understand I have some more insight and expertise, and experience in this area. But I was also frustrated by the fact that I was the one that was in that meeting often with other women, and it felt like our responsibility to fix this. And I used to feel bad about feeling resentful towards that. Because I was like, shouldn't I want to help other people? And I do. But Sam's example really helped remind me and clarify that yes, just because there's a concern doesn't necessarily mean you should be the one to address it. And it really takes everybody involved, or it takes leadership to step up and address that concern. CHRIS: Oh, that's really interesting the way Sam is framing that and describing the situation of not having any problem that you bring in be now your work to solve. Like, oh, I found the issue, and now we've got to go do this. But the idea that you can bring something to light and then be able to walk away from it. And the particular thing that you were saying that if your interaction is always that when you reference something when you bring in a concern that then your manager works with you to figure out how you can solve it, then you get this mental block of like, well, do I even want to say anything? Because I don't want to try and deal with big, amorphous unclear issues. So maybe I just won't even say anything. And so this as a way to make sure that there's room for all of the conversation is a really interesting framing that I hadn't really thought about, frankly, but it's very interesting. I haven't seen this interview either. So I'm definitely excited to give this a look because Sam is wonderful. And the topic that you're describing here sounds fantastic as well. STEPH: Yeah. There was an important moment for me where...one of my managers is Matt Sumner, who's been on the show. And when Matt was my manager, at one point, we were having a one on one, and we would often go for walks for our one on one. And I mentioned something about "I have this concern, or I have this problem, but I don't really know how to fix it. So I'm not sure I'm ready to talk about it." And Matt, in his delightful way, was like, "We can still talk about it. You don't have to have an answer or a solution." I'm like, "Yeah, but I feel like I should be able to fix it. Like, if you have a concern, or if you have something that you want to gripe about, then you should come to the table with solutions for it." And Matt was like, "No, you don't need to do that at all. We can totally gripe about stuff or talk about concerns and then either figure out the solutions together or go to other people for ideas." And that was really important to me because, like you'd mentioned, otherwise, it felt like this mental block where then it feels like you can't air out some of the things that you're worried about or have concerns about because then you think you're the only one responsible. And you may not be able to come up with the best solution. You may need other people to then help you strategize and come up with ideas. And I just love, love, love that part of Sam's discussion. And oh, there was one other part about the conversation. Well, there are lots of parts that were amazing. But another one in particular that blew my mind is about Comic Sans, the font, the font that everyone loves to hate. [chuckles] And I learned that it's one of the most legible fonts for kids. And it's one of the more accessible fonts for people with dyslexia. And it's actually recommended...I think there are still more academic studies that need to be done to really classify fonts that are best for people that have dyslexia. But Comic Sans is recommended by The British Dyslexia Association and the Dyslexia Association of Ireland. And there are some other really great posts that talk about the benefits of using a font like Comic Sans because the typeface has long ascenders and descenders and generous letter spacing and asymmetrical lowercase b and d to then help distinguish those letters. And I just thought that was so cool. This font that everybody wants to rip apart because it seems whimsical, unprofessional gets overused. There are lots of reasons, I suppose. [laughs] But there's a really big benefit to it, and it can help others. And I just found that very whimsical in itself. CHRIS: I love the idea that there are multiple levels of knowing about Comic Sans. First, you're just like, I don't even know the name, but it's that comic book-looking font. And then obviously, the next step is to be like Comic Sans? How could you ever use that? It's an atrocity. And then it's like, but actually, Comic Sans has some things going for it. And it is a really interesting consideration and something that you wouldn't necessarily think of. But then once you learn it, you're like, okay. Man, I wonder how many other things in the world have this interesting shape to them? Hmm. STEPH: Do you know the history behind Comic Sans? CHRIS: I do not. STEPH: I read about it fairly recently, but I'm probably going to botch some of the details. But I believe it was designed or created by Vincent Connare. And it was created for Microsoft. And Vincent was working on a project where I think there was a dog that was essentially going to have these bubbles that would then show you different parts of the application and walk you through the different features. And the dog had a very comic book feel to the character. And so then Vincent designed a font to go along with that comic book character, this dog and came up with Comic Sans. I don't think the dog actually launched with that particular font. But since the font was still developed, it was released as part of the available fonts. And there we go, there is the birth of Comic Sans. And then it just received so much love and ire all throughout history. [chuckles] CHRIS: There's something that you said there that I want to loop back on when you were talking about chatting with Matt Sumner and saying, "Here's this thing, but I don't know how to solve it. So I don't even want to bring it up." I really liked the framing that you gave and the fact that Matt was like, "No, no, we can still talk about it. We can at least explore this thing, have a conversation." I think that's really wonderful. There's a very similar thing that I experience a lot when doing code review, particularly when I'm in more of a leadership role within a team, which is I often want to highlight something that feels a little bit off to me in the code, but I may not have a specific solution. Like, I may see a variable name, or I may see a controller action that feels like it's the wrong shape or something. And I'll often name it but explicitly say, "I actually don't have a better idea here. So feel free to continue on with this, but I want to name it. So in case that sparks something in you, if you were also feeling some incongruousness, maybe it's worth you spending another minute to think about it, but I want to make sure my comment isn't blocking or otherwise making you feel uncomfortable." If I just come to you and I'm like, "This feels wrong," and that's all I say, that to me is unacceptable code review. Because now I want all of my code review feedback to be very actionable, it's either here's the thing that I feel strongly I think we should definitely change this. If you disagree, let's have a conversation. But yeah, this one definitely needs to change. Here's the thing that, like, I don't know, maybe we could break this into two lines and split it up. But if you don't like that, that's fine. Do whatever. And so then it's I've given the person my thoughts but given them clarity and a free rein to do whatever they want with that information. And then there are ones where I'm like, I don't even know what I think we should do here, but I think something. But if you don't have any ideas...like, I don't have any ideas specifically. If you don't have any ideas, it's fine. We'll continue on with this and maybe revisit it down the road. But I want to make sure each of those different tiers is actionable for the other person, and I'm not just giving them homework or something to be sad about because that would be bad code review. STEPH: I'm just imagining a PR comment that says, "I don't know what we should do here. But I don't think this is it," [laughs] and that just creating sadness. That's so interesting to me because I have flip-flopped with that opinion in regards to there are times that I very much resonate and do what you just said where I will point out to someone where I'm like, "I'm not sure why, but I just have concerns about this. And I don't know if you also ran into anything that was weird about this and would like to talk about it. I don't have any really great ideas, so I think this is good for now. And we should keep moving forward, so we're not blocked on it," but just wanted to, as you mentioned, highlight it in case it sparks something for the other person or for someone else that's reviewing the code. And then there are other times where I'll look at something, and I'm like, "Yeah, it's not great. There's something that feels brittle or potentially maybe hard to maintain or things like that. But I don't have a better idea." And I don't comment on it because I'm like, I don't want to distract that person or block them. And I do think it's good enough, and I don't have anything to add to the conversation, so I just leave it out. So it's interesting to me where is that line of when I feel like it's important enough to comment to then potentially spark some conversation versus just letting it go so then I don't add any distraction to their work? CHRIS: I think it's when the spidey-sense gets past 47%. It's a very specific number. I do the same thing where there's something, and I'm like, you know what? I can't even clearly express what about this makes me feel something off, and so I won't even comment on it, and I agree. And then there are things that trip past some magical line in the sand. And I'm like, you know what? I think I'm going to say something here, but I don't even have a recommendation. And then there's a whole spectrum of the nature of code review and, again, 47% being the specific number. STEPH: There's actually a thoughtbot blog post that correlates nicely to that concept of spidey sense. It's written by Mike Burns, and it's titled How to Skim a Pull Request. But essentially, grabbing from one of the lines here is where Mike presents an unexplained, incomplete, and arbitrarily grouped list of keywords that will cause us thoughtboters to read your code with more care and suspicion. [laughs] That feels perfectly aligned with that idea of spidey sense, spidey-sense 101. I'll be sure to include a link in the show notes. Or, you know, 40%. CHRIS: I think it was 47%. It's a very precise number. [chuckles] STEPH: Very precise nonsensical number. Got it. [laughs] CHRIS: If I'm making up fake statistics, I'm not going to have them round to an even 10. [laughter] STEPH: Makes it seem more legit somehow. CHRIS: Exactly. STEPH: But that's really the novelties that I wanted to chat about. Mid-roll Ad And now a quick break to hear from today's sponsor, Scout APM. Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more. Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform. See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. STEPH: What's new in your world? CHRIS: I have some follow up on a recent topic that we talked about. So we had a kerfuffle which I described where we had a branch that got merged and the rebase some stuff got out of hand. And so we introduced some process, the protected branch configuration within GitHub that required the branches to be up-to-date before they can be merged and CI to be passing. And everybody was happy. It was like, this is great. Turns out it was never turned on. That's actually the day I was like, man; this is really straightforward. There's been no annoyance here. And then I got to the point where it was like; this seems weird because we just merged a lot of things in rapid succession. I went and checked, and it turns out what I thought was the name of the branch protection rule in GitHub's UI is, in fact, a regular expression pattern. It might not be a full regular expression but like a wildcard pattern for the branch name to match to, and so it's specific. I created this rule, and in small, gray text underneath, it said, "This applies to zero branches." I missed that the first time but then the second time going back, I was like, oh, I actually wanted it to apply to more than zero branches. So I went back in and changed that. It's a great example of very subtle UI that just slipped past me. STEPH: I was going to say in your defense, the very subtle gray font to say, "This applies to zero," feels tricky. CHRIS: That...also, going through the work of creating this thing and if that results in zero branches that would match, maybe that's the thing to emphasize on creation. I would love that. Because in my case, I was trying very specifically to target an existing branch. There is the ability to say, "Oh, any bugfix-* named branch," if you're using branch naming strategies like that, you can use this for that sort of thing. So it may be that currently, there are no branches with that name. But in my case, I was just like, please, main, anytime anything is happening on main, that is what we want to do. I just needed to put the word main there. But anyway, once I actually turned it on, insufferable, absolutely not, cannot survive in this world. We have a relatively small team. There are three of us, and not everyone is even full-time, and my time is pulled in a lot of different directions. So I'm actually not pushing as much code as I might otherwise. Even with that, nope, absolutely not. Our CI is like; I don't know, five-ish minutes per run. Turns out, especially Monday mornings, we have a volley of things that will have been reviewed and trickled in through Friday afternoon. And then there's a bunch of work we want to land Monday morning. And then, just at any point, it turns out, yes, this was untenable. So we have turned it off. I would like to revisit this down the road and introduce the MergeQueue functionality, so the idea of being able to say, "Yeah, you just name when you want something to go in, and then the system will manage the annoying finicky work there." But for now, I had to give up on my dream of everything running on CI, on a feature branch, before it gets merged. STEPH: Ooph, that phrase, "I had to give up on my dream," that breaks my heart for you. [laughs] CHRIS: I may be going a little bit fanciful with my language but, like, a little. STEPH: [laughs] CHRIS: I liked this thing. I want to exist in that world. But it is not feasible given the current state of the world. And that will only get worse over time, is my expectation. So I get to revisit this when I have the time to more thoroughly figure a thing out. But for now, I don't know, merge whatever; it will be fun. STEPH: There's a small part of me that feels a little reassured that it was a terrible time, although I hate that it was a terrible time. But I have felt that pain on so many other projects where I am constantly waiting, and I'm constantly checking to be like, can I merge? Can I merge? Can I merge? And then I can merge, but then someone beats me to it. And I'm like, oh, then I got to restart. And I got to wait, and I'm constantly checking. So that feels like it helps validate my experience. [chuckles] I am excited for that MergeQueue. I would be super excited to try that out and hear about how it goes just because that seems more like the dream where you can just say, hey, I want this PR to go whenever it can go. Just take care of it. I want it to be rebased, whatever the flow is, and have it be merged, so I don't ever have to check on it again. CHRIS: But once we configured this, there was a new thing that appeared in the GitHub UI, which was auto-merge. And so that was a button where I could say like, "Hey, merge this whenever CI passes," which was a nice upgrade, but it didn't have the additional logic of and rebase as necessary. Or the more subtle logic of like, you don't actually want to rebase where you have five different branches that are all trying to merge, and they keep rebasing. You want to have the idea of a queue, and so you get in line. And you rebase when it's your turn, and then you run the CI. And you try and be as smart as possible about that. If anyone at GitHub is listening, I would love if you all threw this into your platform, and then you could ping Slack if anything went wrong. But otherwise, there are, like I said, existing tools. At some point, I will probably, I don't know, over a long weekend or something like that, sit down with a large cup of coffee and explore these. But today is not that day. STEPH: I'm excited to hear about that day. CHRIS: So that is a tale of woe and sadness. But luckily, I get to balance it out with a tale of happiness and good outcomes. So that's good. The happiness and good outcome story does start with trouble, as they always do. So we had a bug that occurred in the application where something was supposed to have happened. And then there was an email that needed to go out to tell the user that this thing had happened. And the bug popped up within AppSignal and said something was nil that shouldn't have been nil. Particularly, we're using a gem called Time For a Boolean, which is by Caleb Hearth. And he's a former thoughtboter and maintains this wonderful gem that instead of having a Boolean for like, is this thing approved, or is it paid? Or is it processed? You use a timestamp. And then this gem gives you nice Boolean-like methods on top of that timestamp. Because it turns out, very often just having the Boolean of like, this was paid, it turns out you really want to know when it was paid. That would be a really useful piece of information. And so, while you're still in Postgres land, it's nice to be able to reach for this and have the affordances of the Boolean-like interface but also have the timestamp where available. So anyway, the email was trying to process but that timestamp...let's pretend that it was paid as the one that matters here so paid at was nil, which was very concerning. Because this was the email that's like, hey, that thing was processed. Or let's say it was processed, actually, because that's closer to what it was. Hey, this thing was processed, and here's an email notification to tell you that. But the process timestamp was nil. I was like, oh no. Oh no. And so when I saw this pop up, I was like, this is very bad. Everything is very bad. Oh goodness. Turns out what had happened was...because I very quickly chased after this, looked in the background job queue, looked in Sidekiq's UI, and the job was gone. So it had been processed. I was like, wait a minute, how? How did this fix itself? Like, that's not the kind of bug that resolves itself, except, in this case, it was. This was an interaction that I'd run into many times before. Sidekiq was immediately processing the job. But the job was being enqueued from within the context of a database transaction. And the database transaction had not been committed yet. But Sidekiq was already off to the races trying to process. So the record that was being worked on, the database record, had local changes within the context of that transaction, but that hadn't been committed. Sidekiq then reads that record from the database, but it's now out of sync because that tiny bit of Sidekiq is apparently very fast off to the races immediately. And so there's just this tiny little bit of time that can occur. And this is also a fun one where this isn't going to happen every time. It's only going to happen sometimes. Like, if the queue had a couple of other things in it, Sidekiq probably would have not gotten to this until the database transaction had fully closed. So the failure mode here is super annoying. But the solution is pretty easy. You just have to make sure that you enqueue outside of the database transaction. But I'm going to be honest, that's difficult to always do right. STEPH: That's a gnarly bug or something to investigate that I don't think I have run into before. Could you talk a little bit more about enqueueing the job outside the database transaction? CHRIS: Sure. And I think I've talked about this on a previous episode a while back because I have run into this one a few times. But I think it is sufficiently rare; like, you need almost a perfect storm because the database transaction is going to close very quickly. Sidekiq needs to be all that much more speedy in picking up the job in order for this to happen. But basically, the idea is within some processing logic that we have in our system; we find a record, we do some work. And then we need to update that record to assign this timestamp or whatever it is. And then we also want to inform the user, so we're going to enqueue a job to send the email notification. But for all of the database work, we are wrapping it in a transaction because we want it to either succeed or fail atomically. So there are three different records that we need to update. We want all of them to be updated or none of them to be updated. So, therefore, we wrap it in a transaction. And the way we had written, this was to also enqueue the job from within the transaction. That wasn't something we were actively intentionally doing because those are different systems. It doesn't really mean anything. But we were still within the block of ApplicationRecord.transaction do. We're now inside of that block. We're doing all of the record updates. And then the last piece of work that we want to think about is enqueueing the job to send the email. The problem is if we're still within that database transaction if it's yet to be committed, then when Sidekiq picks up that job to run it, it will see the prior state of the world. And it's only if the Sidekiq job waits a little bit that then the database transaction will have been committed. The record is now updated and available to be read by Sidekiq in the correct updated state. And so there's this tiny little bit of inconsistency that can happen. It's basically because Sidekiq is going out to Redis, which is a distinct system. It doesn't have any knowledge of the database transaction at play. That's why I sometimes consider using a Postgres-backed background job system because then actually the job can be as part of the database transaction. STEPH: Cool. That's helpful. That makes a lot of sense the way you explained the whole you're actually enqueueing the job from inside that transaction. I'm curious, that prompts another question. In the case where you mentioned you're using a transaction because you want to make sure that if something fails to update so, everything gets updated together, in the event that something does fail to update because you were previously enqueueing that job from the transaction, does that mean that the update could have failed but that email would still have gone out? CHRIS: That does not. And the reason for that is because we're within dry-monad world. And so dry-monad will implicitly capture the ActiveRecord rollback, which I think is an exception that gets raised or somehow...But basically, if that database transaction fails for any reason and ends up getting rolled back, then dry-monads will not continue processing through the rest of the sequential operation. And so, therefore, even if we move the enqueuing of the email outside of the database transaction, the sequential nature of that processing and the dry-monad stuff that we have in play will handle that. And I think that would more generally be true because I think Rails raises an exception on rollback. Not certain there. But I know in our case, we're fine on that. And we have actually explicitly checked7 for that sort of thing. STEPH: So I meant a slightly different question because that makes sense to me everything that you just said where if it's outside of the transaction, then that sequential order won't fire because of that ActiveRecord migration error. But when you have the enqueuing inside of the transaction because then that's going to be inside of the sequential order, maybe before the rollback error gets raised. Does that make sense? CHRIS: Yes. I think what you're asking is basically like, do we make sure to not send the job if the rest of the stuff didn't succeed? STEPH: I'm just wondering from a transaction perspective, actually. If you have a transaction wrapped block and then you have in there, like, update this record, send email, end block, let's say update...well, I guess it's going raise because you've got probably like an update bank. Okay, so then yeah, you won't get to the next line. Got it. Got it. Got it. I just had to walk myself through that because I forgot that you probably...I have to visualize [laughs] as to what that code probably looks like. All right, that answered my question. CHRIS: Okay. So back up to the top level then, this is the problem that we have. And looking through the codebase, we actually have it in a bunch of different places. So the solution in any one of those cases is to just take the line of code where we're saying enqueue UserMailer.deliver_later take that line of code, move it outside of the database transaction, and make sure it only happens if the database transaction succeeds. That's very easy to do in one case. But my concern was this is a very easy failure mode to end up in. And this is a very easy incorrect version of the code to write. As far as I can tell, we never want to write the code where this is happening inside of the transaction because it has this failure mode. But how do we enforce that? That was the thing that came to mind. So I immediately did a quick look of like, is there a RuboCop thing I can do here or something? And I actually found something even more specific, which was so exciting to find. It's a gem called Isolator. And its job is to detect non-atomic interactions within database transactions. And so it's fantastic. I was like, wait, really? Is this going to do the thing? And so I just installed the gem, configured it where I wanted, and then ran the test suite. And it showed me every place throughout the app right now where we were doing this pattern of behavior like enqueueing work from within a database transaction, which was great. STEPH: Ooh, that's really nifty. I kind of want to install that and just run it on my current client's codebase and see what I find. CHRIS: This feels like something like strong migrations where it's like, yeah, this is great. I kind of want to have this as part of my core toolset now. This one feels even perhaps slightly more so because sometimes I look at strong migrations, and I'm like, no, no, no, strong migrations, I get why you would say that, but for reasons, this is actually fine. And they have configurations within it to say, like, no, this is okay. Isolator feels like it's always telling me something I want to know. So this, very quickly, I'm like, I think this might be part of my toolset moving forward on every single app forever. And actually, there's another gem that I used. It's made by the same team. So this is from the folks over at Evil Martians, which is another Rails consultancy out there in the world. And the Isolator gem is one thing that they've produced. And then I think the same author of it who is an Evil Martian's employee created the aftercommiteverywhere gem. So aftercommit is one of Rails' ActiveRecord callbacks. But in this case, it allows you to use it everywhere, as the name implies. And so rather than actually having to take that line of code out of the database transaction block, which is naturally where we would write it because that's how we think about the code and how we want to express it, you can just use this aftercommit method, wrap the call in that, so it's after_commit, and then a block. So either braces or do..end. That enqueueing of the email now just gets wrapped in that. And so what that does is it says, "Defer this until after the transaction commits. If the transaction does not commit, if we roll it back, then don't run it." And what was nice is the actual code change when I finally submitted all of this was add the gem to the gem file. And then everywhere that we're doing the wrong thing, which running the test suite told me, I just went in, and I wrapped that line in after_commit and a block. And it was such a nice, clean...like, I didn't have to move the code around or actually shift the lines, which was my first attempt at this. I was able to just annotate each of those lines and say, "You're special, you're special, you're special," And then I'm done. And again, the first gem told me every case where I needed to do that. It's like, well, this is a wonderful little outcome here. STEPH: That's really nice, yeah, how you can make the changes and then, like you said, re-run the test or re-run that gem, and it lets you know what else still needs to be updated. I'm intrigued where you mentioned you didn't have to move any lines, though. Maybe I just need to look at the gem and see it, but I'm still envisioning that you have your transaction do block. And then you're doing some things; you're updating records, and then you have your end. And then after that, it's when you want to enqueue the email. And with this after_commit, you actually added that method call inside of the transaction but then wrapped the call to Sidekiq to send the email inside of that block. CHRIS: Correct. Yeah. So it's basically like saying, "Here's almost an anonymous function." If you think about a Ruby block in that nomenclature, you're saying, like, here's some work to do when and if the transaction succeeds. And so it meant that I was able to keep the code in the way that we as humans would talk about it but deal with the murky details, and edge cases of database transactions, and Sidekiq, and whatnot. Sort of just handle it by saying like...it almost feels like an annotation or a decoration or something like that. But it was this, in my mind, almost like a perfect melding of I don't want to think about this. Oh, cool. Okay, here's a quick, easy way to deal with it but to not have to fundamentally change how I write the code. STEPH: Interesting. So I like all the things you're saying. I'll be honest, I'm not totally sold, and I'm trying to think of why. I think the benefits...one, as you mentioned, it's something you don't have to think about or at least signals to others that hey, maybe you should think about this to the extent that you use after_commit. And so that way, you don't have these asynchronous events taking place inside the transaction. So I like that visibility and communication to the rest of the team. Putting it inside of the transaction feels interesting. I don't know why; I feel a little weird about this. [laughs] I'm bringing my true self. CHRIS: That's fair. So if we're being honest, I solved this first by finding the Isolator gem. Well, I solved it first by just doing it manually. I went through the app, and I found all the places. And I was like, you know what? I'm worried that the next person authoring code like this, it's so easy to fall into this trap. Like, this is such a subtle little thing that our brains are not thinking about. And so I had first fixed it, and so I had a diff that involved moving lots of lines of code, every instance of this moved from being in the database transaction out of it. And that was fine. I was fine with that as a solution. But it was a little bit noisy because I was moving a bunch of lines. So then I brought in the Isolator gem. I actually reset that, and I went back to before I had made the fix, ran the test just to make sure Isolator was actually finding every instance. They did; that was great. So I was like, all right, cool. This is better because now I have this thing that will tell anyone when this happens. So I'm very happy about that. Because frankly, this is some hard-earned knowledge that I had to read Sidekiq and remember how database transactions work and convince myself of what was going on here and finally come to what I believe the solution is. And now Isolator is just like, cool, that's encapsulated. And it gives a very nice failure message in the test suite. So it's like, excellent. I really like this. But still looking at it, the diff, the amount of code that I had to change, it's like, well, naturally, this is how we want to write this code, but for reasons, we can't. And it's appeasing the computer more than it's appeasing the reader or the author of the code. And so then I happen to be reading through the Isolator gem's README, and they mention the aftercommiteverywhere gem. And I was like, oh, that's interesting. So one more time, I reset. And then I really tried fixing it with after_commit. And the look of the diff there felt nice to me because the lines got a little more on them, but they didn't move. And so it's like, this is how we naturally would have authored it, and now it works correctly. And I liked that. But I understand your hesitation because you're like, but the thing is, it's wrong. And so you've made the wrong not wrong anymore, but you didn't...and so I get your hesitation. I still like the fancy version. STEPH: Yeah, I think you just helped me figure out my grumpiness with it or why I'm not totally sold on it. And it was in regards to adding a dependency to avoid a noisy diff is the oversimplified version that I was processing or the reason that I was a bit grumpy about adding this other gem for that. But then you also just brought a lot of other really good reasons. One thing that you said that I do really like is adding tools that help us author code in a more natural style, the way that we want to highlight this process, and how this application does work, and how this business logic flows. So given in that light, that makes me feel better about it. But yeah, I think that was my initial grumpiness. I was like, it'll be a noisy diff. It's okay. CHRIS: I think I definitely share your hesitation, or you're like, hmm, that's an interesting reason to bring more code into the application. But at the same time, I think the counterpoint that comes to mind for me is we're using Ruby because of its expressiveness; at least, that's why I'm using Ruby. I really want the code that I write to be as close as possible to the thing that I would say to another human about like, oh okay, when a user signs up for the application, we need to create a record in our system, and then we need to send them an email. And then we need to do this other thing. And so, the closer that our code is to those words that I would use to describe to another human, the happier I am. And I will put in some pretty significant effort to hold that line as long as the code can also be correct. And so, the Isolator gem here does a great job of enforcing that correctness. And then after_commit allows me to still maintain that expressiveness and not have to think about the murky details as much or not have to reshape my code to match the murky realities of different persistence engines. But I do agree. I think it's a good thing to look at and ask, like, is it worth it? Are you sure? And in this case, I will say, "Yeah, I think so," but with that amount of certainty in my voice, [chuckles] which is not a ton. STEPH: I think this is going back to my days of working with dependency bot PRs where every time there was an upgrade for a gem, I always ask, what do you do here? [chuckles] Do we need to upgrade you? Can we just remove you from the codebase? So I'm fairly...I don't know, resistant is a strong word. I'm skeptical of when we're adding stuff in, and I just want to question the value that it's adding. But I want to circle back to something that you said, and that is hard-earned knowledge. And that part I understand so much where when you have gone through a fair amount of work to uncover an issue, and then you want to make sure that others don't have to go through that. This is a really nice way to highlight; hey, there's something that's tricky about computers and software here, and we need to watch out for that. And I want to help you lookout for that. Versus this is just inherit information where this needs to happen outside or after that transaction. And so that makes a really nice entry point where someone can look to say, "Why did we add this gem?" And then there's a commit message that goes with it that explains this is why we use this after_commit gem because we're specifically looking to avoid this type of bug. And I love that. CHRIS: Yeah, I think more lines of git commit message than diff on this one. So yeah, I wrote a short novel describing all of the features, describing the different pieces that are coming together. And then it's actually a +28 -6 diff. So it's a very small code change. But yeah, lots of story captured there. STEPH: And if you had just moved the lines, you could still have that commit message. But it's not likely that someone's going to look up that git commit change or that message that went along with it because they're not going to know to blame that one. But if they look at that particular edition of after_commit, they're more likely to find that historical context. So long story short, I think you have walked me through my initial grumpiness and provided some really good ways to avoid that really tricky failure mode for other developers. CHRIS: Well, thank you. I'm getting Steph's seal of approval starting from grumpy places. [laughs] I feel good. All right. STEPH: I'll have some special Stephanie's approval stickers designed and printed for you. CHRIS: I hope you're not joking because I very much want a yellow heart that says, "Steph-approved." STEPH: [laughs] CHRIS: And I can put it on PRs, and I can put it on the wall. [laughs] STEPH: Well, now I have to find a sticker designer and make a...well, it's just a yellow heart. I can probably handle this. I'm going to use Comic Sans. That will be the approved part. [laughs] Yellow hearts and Comic Sans for everybody. CHRIS: Well, with that absolutely fantastic call back to earlier parts of the episode, shall we wrap up? STEPH: Let's wrap up. CHRIS: The show notes for this episode can be found at bikeshed.fm. STEPH: This show is produced and edited by Mandy Moore. CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes, as it really helps other folks find the show. STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. CHRIS: And I'm @christoomey STEPH: Or you can reach us at hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. All: Byeeeeeeee! Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.
In this episode I talk with Vladimir Dementyev, software engineer at Evil Martians, about "frontendless Rails frontend". We talk about what this means and how it relates to ViewComponent, StimulusReflex and Hotwire.Links:Vladimir Dementyev on TwitterEvil MartiansHotwire:Reactive Rails with no JavaScript?Slides for Vlad's RailsConf talkViewComponent extensions
Dave, John, and Luke get together to finish the discussion leading up to the Ruby 3.0 release. They talk about the different features and concerns that come with upgrading and/or using Ruby 3.0 and how it differs from Ruby 2.7. Panel Dave Kimura John Epperson Luke Stutters Sponsors Dev Heroes Accelerator Links Ruby | dockerhub Ruby on Whales: Dockerizing Ruby and Rails development | Evil Martians Background Job Processing Using Ractor (Ruby 3) by André Guimarães Sakata Parallelism in Ruby with Ractors by Lorenzo Barasti How Fast are Ractors? by Noah Gibbs Samuel Williams' Scalable Concurrency for Ruby 3 talk for RubyKaigi 2020 An Array of Possibilities: A Guide to Ruby Pattern Matching Picks Dave- Hotwire Dave- Angle Grinder John- GitHub | minimul/qbo_api John- GitHub | ruckus/quickbooks-ruby Luke- Creel: Godbolt Compiler Explorer Adventures Luke- Creel: Branchless Programming Luke- Intel - From Inventors of the CPU to Laughing Stock [Part 2] Luke- Starving Threads In Ruby by Piotr Jatkowski
Dave, John, and Luke get together to finish the discussion leading up to the Ruby 3.0 release. They talk about the different features and concerns that come with upgrading and/or using Ruby 3.0 and how it differs from Ruby 2.7. Panel Dave Kimura John Epperson Luke Stutters Sponsors Dev Heroes Accelerator Links Ruby | dockerhub Ruby on Whales: Dockerizing Ruby and Rails development | Evil Martians Background Job Processing Using Ractor (Ruby 3) by André Guimarães Sakata Parallelism in Ruby with Ractors by Lorenzo Barasti How Fast are Ractors? by Noah Gibbs Samuel Williams' Scalable Concurrency for Ruby 3 talk for RubyKaigi 2020 An Array of Possibilities: A Guide to Ruby Pattern Matching Picks Dave- Hotwire Dave- Angle Grinder John- GitHub | minimul/qbo_api John- GitHub | ruckus/quickbooks-ruby Luke- Creel: Godbolt Compiler Explorer Adventures Luke- Creel: Branchless Programming Luke- Intel - From Inventors of the CPU to Laughing Stock [Part 2] Luke- Starving Threads In Ruby by Piotr Jatkowski
Dave, John, and Luke get together to finish the discussion leading up to the Ruby 3.0 release. They talk about the different features and concerns that come with upgrading and/or using Ruby 3.0 and how it differs from Ruby 2.7. Panel Dave Kimura John Epperson Luke Stutters Sponsors Dev Heroes Accelerator Links Ruby | dockerhub Ruby on Whales: Dockerizing Ruby and Rails development | Evil Martians Background Job Processing Using Ractor (Ruby 3) by André Guimarães Sakata Parallelism in Ruby with Ractors by Lorenzo Barasti How Fast are Ractors? by Noah Gibbs Samuel Williams' Scalable Concurrency for Ruby 3 talk for RubyKaigi 2020 An Array of Possibilities: A Guide to Ruby Pattern Matching Picks Dave- Hotwire Dave- Angle Grinder John- GitHub | minimul/qbo_api John- GitHub | ruckus/quickbooks-ruby Luke- Creel: Godbolt Compiler Explorer Adventures Luke- Creel: Branchless Programming Luke- Intel - From Inventors of the CPU to Laughing Stock [Part 2] Luke- Starving Threads In Ruby by Piotr Jatkowski
On today’s episode, Andrew tried Linter Action again and he tells us what happened. Then, Andrew tells us he’s been getting into some big testing and talks about Evil Martians blog and checking out TestProf and Terraforming. Chris goes in depth about starting to revive the old Madmin gem that him and Andrew Fomera were working on a while ago. Chris explains the difference between a Railtie and an Engine. Chris launched an early access Advanced Ruby course on GoRails so go check it out! There’s a lot of cool stuff going into Rail 6.1 and so many new gems coming out. Be a part of the Ruby Renaissance and download this episode now to find out more!
(September 4, 2019) Developing for the global web is so much more than just translating content into multiple languages. In this episode of the State of the Web, Rick Viscomi (Developer Programs Engineer at Google) sits down with Andrey Sitnik (Lead Frontend Engineer at Evil Martians) to talk about considerations for globalization and the tools available to web developers. For more info about everything discussed in this video, check out the original video→ https://goo.gle/2Z5dYq6
Brittany guested on the Ruby Blend! The hosts counsel her on opensourcing her googlepay gem. They then dive into how important README's are, useful tools for documentation, a project from Evil Martians, a gem called Combustion, and RSpec API documentation.
Brittany guested on the Ruby Blend! The hosts counsel her on opensourcing her googlepay gem. They then dive into how important README's are, useful tools for documentation, a project from Evil Martians, a gem called Combustion, and RSpec API documentation.
Brittany guested on the Ruby Blend! The hosts counsel her on opensourcing her googlepay gem. They then dive into how important README's are, useful tools for documentation, a project from Evil Martians, a gem called Combustion, and RSpec API documentation.
Sponsors Sentry use the code “devchat” for 2 months free on Sentry small plan CacheFly Host: Charles Max Wood Special Guest: Vladimir Dementyev Episode Summary In this episode of My Ruby Story, Charles hosts Vladimir Dementyev, a backend engineer at Evil Martians and a mathematician who found his happiness in programming Ruby and Erlang. He is also the author of Author of AnyCable, TestProf and ActionPolicy. Listen to Vladimir on the podcast Ruby Rogues on this episode. Vladimir studied mathematics in university and started programming with ActionScript in an internship during his university education. He then went onto developing with Ruby and became heavily involved in open source projects. He is originally from Moscow but is currently based out of Brooklyn, NY working for Evil Martians, a web development consultancy company that supports open source projects. Vladimir will be a speaker at the RailsConf 2019. Links Ruby Rogues: Cables, Concurrency, and Ruby 3×3 with Vladimir Dem Evil Martians Vladimir’s Twitter Vladimir's GitHub Vladimir's LinkedIn Vladimir's Dev.to https://devchat.tv/my-ruby-story/ https://www.facebook.com/DevChattv Picks Vladimir Dementyev: danger.systems Charles Max Wood: MyFitnessPal CardioCoach VO2 Max App
Sponsors Sentry use the code “devchat” for 2 months free on Sentry small plan CacheFly Host: Charles Max Wood Special Guest: Vladimir Dementyev Episode Summary In this episode of My Ruby Story, Charles hosts Vladimir Dementyev, a backend engineer at Evil Martians and a mathematician who found his happiness in programming Ruby and Erlang. He is also the author of Author of AnyCable, TestProf and ActionPolicy. Listen to Vladimir on the podcast Ruby Rogues on this episode. Vladimir studied mathematics in university and started programming with ActionScript in an internship during his university education. He then went onto developing with Ruby and became heavily involved in open source projects. He is originally from Moscow but is currently based out of Brooklyn, NY working for Evil Martians, a web development consultancy company that supports open source projects. Vladimir will be a speaker at the RailsConf 2019. Links Ruby Rogues: Cables, Concurrency, and Ruby 3×3 with Vladimir Dem Evil Martians Vladimir’s Twitter Vladimir's GitHub Vladimir's LinkedIn Vladimir's Dev.to https://devchat.tv/my-ruby-story/ https://www.facebook.com/DevChattv Picks Vladimir Dementyev: danger.systems Charles Max Wood: MyFitnessPal CardioCoach VO2 Max App
Sponsors Sentry use the code “devchat” for 2 months free on Sentry small plan CacheFly Host: Charles Max Wood Special Guest: Vladimir Dementyev Episode Summary In this episode of My Ruby Story, Charles hosts Vladimir Dementyev, a backend engineer at Evil Martians and a mathematician who found his happiness in programming Ruby and Erlang. He is also the author of Author of AnyCable, TestProf and ActionPolicy. Listen to Vladimir on the podcast Ruby Rogues on this episode. Vladimir studied mathematics in university and started programming with ActionScript in an internship during his university education. He then went onto developing with Ruby and became heavily involved in open source projects. He is originally from Moscow but is currently based out of Brooklyn, NY working for Evil Martians, a web development consultancy company that supports open source projects. Vladimir will be a speaker at the RailsConf 2019. Links Ruby Rogues: Cables, Concurrency, and Ruby 3×3 with Vladimir Dem Evil Martians Vladimir’s Twitter Vladimir's GitHub Vladimir's LinkedIn Vladimir's Dev.to https://devchat.tv/my-ruby-story/ https://www.facebook.com/DevChattv Picks Vladimir Dementyev: danger.systems Charles Max Wood: MyFitnessPal CardioCoach VO2 Max App
Специальный выпуск, посвященный нашей поездке на DevFest Siberia 2018! За три насыщенных дня мы успели полностью погрузиться в атмосферу конференции: рассказали о нашем подкасте десяткам гостей, пообщались и пофотографировались с уже постоянными слушателями, разыграли несколько футболок, вдоволь понетворкались, а так же взяли интервью у нескольких спикеров. А кто-то даже успел сходить на доклад! И с удовольствием делимся нашими впечатлениями. Содержание: 00:00:10 - Делимся впечатлениями 00:05:30 - Интервью с Сергеем Рябовым 00:21:35 - Анонс конкурса "Подлодка дарит книгу" 00:23:00 - Интервью с Константином Цховребовым (RedMadRobot) 00:39:25 - Интервью с Евгением Шкодиным (Evil Martians) 00:48:20 - Прощаемся Внимание, конкурс! Гость одного из наших выпусков, а так же коллега по цеху Никита Маклахов недавно выпустил книгу - "Будет сделано! Как жить, чтобы цели достигались" https://www.mann-ivanov-ferber.ru/books/budet-sdelano/?utm_medium=cpa&utm_source=admitad&admitad_publisher_id=550691&utm_campaign=campaign&admitad_uid=33cfcee780728be7c20bfb90bb63d91f Среди наших слушателей мы разыгрываем два экземпляра этой книги. Для участия необходимо 1. Выбрать свой любимый выпуск подкаста Podlodka (весь список можно найти тут: https://soundcloud.com/podlodka/tracks) 2. Поделиться им в одной из соц. сетей (facebook, twitter, vk). 3. К посту обязательно добавить хештег #подлодкадариткнигу. И можно пару добрых слов :) Среди авторов постов уже через неделю (7-го декабря) мы выберем 2-х победителей, которым достанется по книжке! Читайте книги и слушайте подкаст Podlodka
Анна Селезнёва, lead frontend developer в Spiral Scout, в гостях у Андрея Смирнова из Frontend Weekend. Хочешь поддержать Frontend Weekend, переходи на http://frontendweekend.ml ;) - Как стала разработчиком и была ли опция стать кем-то другим с учетом родословной? 00:29 - Сложно ли постоянно переезжать и как работалось в одной компании в разных городах? 03:14 - Почему было некомфортно жить в Москве? (плюс весёлая история от ведущего) 07:11 - Почему переехала в Минск, не уволившись из Creative People, и каково там было жить? 11:54 - Как устроилась на работу в Evil Martians и почему важно уметь говорить “нет”? 15:33 - Почему ушла из Марсиан из-за синдрома самозванца и перешла тимлидом в Spiral Scout? 19:00 - Комфортно ли работать с людьми и справилась ли в итоге с депрессией? 25:28 - Давно ли тянется уже эта депрессия и связана ли она только с разработкой? 28:59 - Как помогают выступления на конференциях и кроется ли причина всего в детстве? 32:23 - Кем бы хотела стать, если бы не стала разработчиком? 36:41 - Как появились никнеймы askd, asktel и так далее? 38:05 - React, Angular, Vue или Ember? 39:52 - Какая справедливая зарплата для frontend-разработчика в Минске? 41:25 - Готовим вместе с frontend-разработчиком 43:13 - Больше общайтесь с разными людьми! 44:35 Ссылки по теме: 1) Та самая статья про эмоциональное выгорание – https://askd.livejournal.com/127949.html 2) Frontend Weekend Patreon – https://patreon.com/frontendweekend
Анна Селезнёва, lead frontend developer в Spiral Scout, в гостях у Андрея Смирнова из Frontend Weekend. Хочешь поддержать Frontend Weekend, переходи на http://frontendweekend.ml ;) - Как стала разработчиком и была ли опция стать кем-то другим с учетом родословной? 00:29 - Сложно ли постоянно переезжать и как работалось в одной компании в разных городах? 03:14 - Почему было некомфортно жить в Москве? (плюс весёлая история от ведущего) 07:11 - Почему переехала в Минск, не уволившись из Creative People, и каково там было жить? 11:54 - Как устроилась на работу в Evil Martians и почему важно уметь говорить “нет”? 15:33 - Почему ушла из Марсиан из-за синдрома самозванца и перешла тимлидом в Spiral Scout? 19:00 - Комфортно ли работать с людьми и справилась ли в итоге с депрессией? 25:28 - Давно ли тянется уже эта депрессия и связана ли она только с разработкой? 28:59 - Как помогают выступления на конференциях и кроется ли причина всего в детстве? 32:23 - Кем бы хотела стать, если бы не стала разработчиком? 36:41 - Как появились никнеймы askd, asktel и так далее? 38:05 - React, Angular, Vue или Ember? 39:52 - Какая справедливая зарплата для frontend-разработчика в Минске? 41:25 - Готовим вместе с frontend-разработчиком 43:13 - Больше общайтесь с разными людьми! 44:35 Ссылки по теме: 1) Та самая статья про эмоциональное выгорание – https://askd.livejournal.com/127949.html 2) Frontend Weekend Patreon – https://patreon.com/frontendweekend
Андрей Ситник, ведущий frontend-разработчик в компании Evil Martians, в гостях у Андрея Смирнова из Frontend Weekend. Хочешь поддержать Frontend Weekend, переходи на http://frontendweekend.ml ;) - Как из Владивостока уехал в Питер и стал frontend-разработчиком в Злых марсианах? 00:29 - Каким образом и зачем переехал в Нью-Йорк? 04:22 - Поменялось ли впечатление о Нью-Йорке после переезда? 06:13 - Можно ли сравнивать Нью-Йорк с Москвой или Санкт-Петербургом? 09:23 - Три самых клёвых места, где был Андрей (с точки зрения frontend-community и туризма) 11:16 - Насколько проблемы с языком мешают при выступлениях и как с этим бороться? 13:40 - Как появилось сообщество «Лингвопанк» и вообще увлечение лингвистикой? 18:21 - Почему хочешь «уйти из CSS-разработки»? 22:06 - Чем конкретно занимаешься в Амплифере и Злых марсианах? 25:03 - Почему autoprefixer пиарится отдельно, а также Logux или PostCSS? 29:18 - Какого было в гостях у кучи frontend-подкастов и почему Фронтенд Юность не контркультура? 32:36 - Зачем появился #sitnikfriday и за что блокируют в Твиттере? 35:21 - Копимизм, лакричная чёрная водка и роспись тела хной 42:23 - Зачем нужно столько разных твиттеров? 45:15 - Почему Мор (Утопия) одна из любимых игр и топ инди-игр от Андрея 47:50 - Кем бы хотел стать, если бы не стал разработчиком? 50:20 - Какая справедливая зарплата для frontend-разработчика в Нью-Йорке? 51:40 - React, Angular, Vue или Ember? 52:15 - Готовим вместе с frontend-разработчиком 52:46 - Переходите на удалённую работу и путешествуйте! 54:17 Ссылки по теме: 1) Личный сайт Андрея – https://sitnik.ru 2) Сообщество «Лингвопанк» – https://vk.com/linguopunk 3) Frontend Weekend Patreon – https://patreon.com/frontendweekend
Андрей Ситник, ведущий frontend-разработчик в компании Evil Martians, в гостях у Андрея Смирнова из Frontend Weekend. Хочешь поддержать Frontend Weekend, переходи на http://frontendweekend.ml ;) - Как из Владивостока уехал в Питер и стал frontend-разработчиком в Злых марсианах? 00:29 - Каким образом и зачем переехал в Нью-Йорк? 04:22 - Поменялось ли впечатление о Нью-Йорке после переезда? 06:13 - Можно ли сравнивать Нью-Йорк с Москвой или Санкт-Петербургом? 09:23 - Три самых клёвых места, где был Андрей (с точки зрения frontend-community и туризма) 11:16 - Насколько проблемы с языком мешают при выступлениях и как с этим бороться? 13:40 - Как появилось сообщество «Лингвопанк» и вообще увлечение лингвистикой? 18:21 - Почему хочешь «уйти из CSS-разработки»? 22:06 - Чем конкретно занимаешься в Амплифере и Злых марсианах? 25:03 - Почему autoprefixer пиарится отдельно, а также Logux или PostCSS? 29:18 - Какого было в гостях у кучи frontend-подкастов и почему Фронтенд Юность не контркультура? 32:36 - Зачем появился #sitnikfriday и за что блокируют в Твиттере? 35:21 - Копимизм, лакричная чёрная водка и роспись тела хной 42:23 - Зачем нужно столько разных твиттеров? 45:15 - Почему Мор (Утопия) одна из любимых игр и топ инди-игр от Андрея 47:50 - Кем бы хотел стать, если бы не стал разработчиком? 50:20 - Какая справедливая зарплата для frontend-разработчика в Нью-Йорке? 51:40 - React, Angular, Vue или Ember? 52:15 - Готовим вместе с frontend-разработчиком 52:46 - Переходите на удалённую работу и путешествуйте! 54:17 Ссылки по теме: 1) Личный сайт Андрея – https://sitnik.ru 2) Сообщество «Лингвопанк» – https://vk.com/linguopunk 3) Frontend Weekend Patreon – https://patreon.com/frontendweekend
В этом году мы записываем серию подкастов со спикерами конференции RailsClub 2016. 22 октября, Москва, подробности и регистрация на сайте конференции. В этот раз мы поговорили с Владимиром Дементьевым про Action Cable, обучение и open source. Ссылки Профиль Владимира на Github первый проект Владимира – Teachbase Универсальный RPC фреймворк Brainwashing – Курс по Ruby on Rails Rubocop Первый open-source коммит в pry-byebug InfluxDB - БД написанная на языке Go Influxer - InfluxDB ActiveRecord-style Telegraf - сборщик логов Thinknetica Расшифровка эпизода, опубликованная на Habrahabr Расскажи немножко о себе? В Ruby сообщество я пришел не так давно. Примерно 4 года назад я в первый раз попробовал рельсы, поигрался. Мне понравилось. но проект, на котором я тогда работал, их не использовал. Поэтому пришлось отложить до очередной реинкарнации проекта Teachbase, нашего стартапа. Teachbase - это SaaS система для организации управления обучением, она позволяет вам сделать собственную Coursera в рамках компании или проекта. Когда я пришел, это был страшный проект на PHP, а я тогда мало что умел. Кодил, что говорили. Потом я познакомился с рельсами и с того момента, как стал техническим директором, начал вынашивать идею написать новую классную версию системы на продвинутой технологии. Такая возможность представилась в 2014 году, и тогда мы полностью перешли на рельсовый стэк в части веб-приложения. С тех пор я начал активно этим заниматься. Как ты смог убедить заказчика перейти на Rails? Все очень просто - я сам себе заказчик. Я один из основателей этого стартапа, двое моих партнеров не имели достаточной технической экспертизы, поэтому доверяли мне. Надеюсь, они не ошиблись и не жалеют об этом :) Выбор технологий был за мной. Вопрос был только в том, чтобы найти время на переход с одной версии на другую. Ну и деньги, естественно. Когда момент настал, мы переписали все на рельсы, и вот эта третья (или четвертая) версия системы работала быстро, четко, все были довольны - как мы, так и клиенты. Она и сейчас работает? Да, она продолжает работать. Мы довели проект до очень хорошего состояния, когда делать новую версию имеет смысл уже не по технологическим причинам, а скорее идеологическим. Не знаю, какие у ребят планы на данный момент. Пока они занимаются поддержкой этой системы, продажей. Все идет неплохо, проект жив, работает. Teachbase довольно большой проект на рельсах. Причем это были рельсы 4.1, на 4.2 мы не стали переходить, хотя планировали. Год с небольшим назад было объявлено о выходе 5 рельс осенью 2015, в этот момент мы решили, что нет смысла переходить на 4.2, когда можно сразу перейти на 5. Все знают, что потом было :). Прошел еще год, пятые рельсы уже вышли, но сейчас переходить на них, наверное, еще опасно. Надо подождать хотя бы 5.0.1, а лучше 5.1, тогда можно будет переходить. Мы понадеялись на релиз-планы команды разработчиков рельс, они не оправдались, поэтому наш проект до сих пор висит на 4.1. И особых проблем с этим нет. То есть, с точки зрения технологий проект закончен, и вы делаете что-то новое когда понимаете, что это нужно бизнесу? Да. Есть планы переделать значительную часть логики, и это, скорее всего, будет новый проект на новых рельсах, а может и не рельсах. В нашем стеке всегда был Erlang, так как мы занимались видеоконференциями, соответственно, нужен был стриминговый сервис, который работал бы с протоколом RTMP. Он нужен, чтобы люди, используя технологию flash (которую все ненавидят), могли общаться в браузере, проводить вебинары на большое количество людей и так далее. Бэкендом для всего этого служил сервис на эрланге, который отпочковался от довольно известного проекта Erlyvideo. Вы взяли форк, который был еще в open source? Да, это был open source, версия примерно 2.18. Происходило это в 2011 году. Сначала мы его просто использовали, потом стали вскрывать баги и править их, адаптировать все под нашу историю. А потом Макс Лапшин закрыл код и начал разрабатывать платный Flussonic. Нам это, в принципе, не мешало. Так у нас появился опыт в Erlang, и мы начали делать некоторые другие второстепенные сервисы для системы на эрланге. Наш стэк обрел второй основной язык Но найти разработчика на эрланге не очень просто. Тот единственный эрлангист, который у нас был, пришел студентом, он знал С и отлично знал математику, у него было олимпиадное прошлое и он хотел работать. Как эрлангиста мы его воспитывали с нуля. Он, кстати, до сих пор работает в проекте. Но больше таких людей не появлялось, поэтому в начале этого года, когда я еще работал в Teachbase, мы начали программу знакомства с Elixir (как для тех, кто программировал на Ruby, так и для тех кто программировал на Erlang). Был отдельный подпроект, в котором было 2 разработчика: рубист и эрлангист. Они должны были осваивать технологию вместе, используя каждый свои сильные стороны. Один лучше знает Ruby и его парадигму, знает Rails, которые похожи с Phoenix в части MVC. А второй человек, который знает Erlang, делал на Elixir какие-то более близкие к этой парадигме вещи. Проект пока не доделан, но он очень интересный. Мы начали переходить на этот стек, скорее из-за его популярности, чтобы было проще в дальнейшем жить и нанимать новых сотрудников. А не хотели все перевести на Phoenix? Полностью отказаться от Ruby, оставить Erlang, поверх него Elixir, а сверху еще Phoenix? Когда стоял вопрос о переходе на Rails, был альтернативный вариант сразу переходить на Erlang. Я готов был это сделать. Наверное, мы бы дольше стартовали, но вероятно это было бы лучше с точки зрения эффективности. Хорошо, что мы этого не сделали: наши нагрузки не требуют каких-то жутких оптимизаций, и рельса вполне справляется, а скорость разработки дает намного большую. Сейчас я не думаю, что Phoenix можно полностью заменить рельсы именно с точки зрения построения бизнес-логики, слоя работы с данными. Все что касается запросов, сокеты (это отдельный разговор мы к нему вернемся) - с этим в Phoenix все неплохо. Но Active Record (или его альтернативы) и экосистема вокруг него пока гораздо удобнее, чем все, что есть в Elixir. Это логично, там другая парадигма, там не так просто сделать удобный для использования инструмент. Поэтому, на мой взгляд, Elixir и прочие, с Phoenix или без, - это скорее технологии для идеологии микросервисов. Нужно использовать их в какой-то тяжелой части, в которую стучится очень много клиентов, с какими-то задачами, запросами. Такие части можно писать Elixir, решать их несколькими разными сервисами. А основная логика должна, мне кажется, оставаться в рельсах, если изначально была написана на них. Но даже если бы я сейчас начинал проект с нуля, я бы все равно не стал делать все на Elixir. Ты говоришь о Teachbase и своей роли CTO в нем, как о прошедшей истории. Сейчас, насколько я знаю, ты работаешь в Evil Martians, работаешь просто разработчиком. Почему ты перешел от управления к разработке? Чаще наоборот, люди хотят пройти путь от разработчика до управленца. Считаешь ли ты это шагом назад, или это какой-то промежуточный этап? Во-первых, долгое время я был в Teachbase единственным разработчиком. Я начал набирать команду только в последнюю пару лет, когда у нас появилась такая возможность. Проблема для меня, как для разработчика, была в том, что я много всего попробовал, много нового узнал, но в основном на собственном опыте. Я никогда не работал в команде под руководством кого-то, кто был опытнее меня и имел какие-то знания, которых у меня не было. Это была одна из причин: мне было скучно, я понимал, что мой самостоятельный рост в Teachbase будет идти тяжело. Особенно, когда проект стабилизировался, не было каких-то супер интересных задач, только текучка типа добавления фич, нет воли творчеству. Я рассматривал марисан, в первую очередь, так как я был знаком с некоторыми ребятами, я был на курсе Brainwashing, с тех пор у меня остались самые приятные впечатления об этой команде. Мне очень хотелось поработать с такими людьми, поделиться опытом, поделиться своими идеями. Когда я работал в Teachbase, мне не с кем было обсудить какие-то технические идеи, не было людей, которые разбирались бы хорошо в технических аспектах. Поэтому я хотел попасть в сильную команду. То, что в Teachbase у меня была “власть”, а теперь я рядовой сотрудник, не страшно. Наверное. Хотя моя жена говорит, что после того, как я перестал руководить, я пытаюсь немножко чаще руководить дома. Компенсирую :) Мне нравится отсутствие вертикали, можно со всеми спокойно общаться, разговаривать, спорить, ругаться иногда. Мне нужно было попасть в среду, скажем так. Мы начали говорить про Rails и долгожданную 5 версию, в которой много всего появилось. Например, Action Cable, про который ты и будешь рассказывать на конференции. Чего еще тебе не хватает в Rails? Я бы поставил вопрос по-другому: что в рельсе лишнее, что мешает. Да, это хороший вопрос В прошлом подкасте мы говорили с Алексеем Тактаровым о том, стоит ли выкинуть фронтовую часть. А что бы ты выкинул? Фронтовая часть и сборка ассетов с помощью Sprockets, на мой взгляд, уже устаревшая схема. Фронт сейчас пишется со своими сборщиками, там своя очень развитая экосистема. Которая работает, по моему опыту, гораздо приятнее, чем Sprockets. Это быстро, удобно, куча дополнительных возможностей, тонкая настройка и так далее.. Тот же автопрефиксер вставить в Sprockets, конечно, можно. Но если вставить еще 20 аналогичных плагинов, то ассеты, скорей всего, будут собираться очень долго. Я использовал рельсу, по большей части, неклассическим образом, с серверным рендерингом, используя javascript шаблоны и подобные вещи для обновления странички. Я использовал Rails практически в API режиме, только JSON. HTML-странички отдавались также рельсами, но была идея избавиться и от этого, грузить статику отдельно, так как динамического рендеринга был минимум, например, : вставка логотипа налету. Все фишки типа шаблонов,Turbolinks, вот это все, должны быть отдельными примочками к рельсам. Если хочешь - добавляй. В свое время Sprockets был настоящим прорывом. Возможно, сейчас эта технология устарела, потому что фронт развивается какими-то сумасшедшими темпами. Потому что на тот момент во фронте был популярен только Grunt, ужасный и монструозный, на мой взгляд. Он долго меня отталкивал от использования всего этого, пока не появились более приятные глазу альтернативы. Если говорить про текущий момент: если бы я сейчас начинал новый проект и брал бы в качестве бэкенда рельсу, я бы, учитывая, что у нас в Rails 5 есть встроенный API режим, сразу бы делал так, чтобы отдельно один проект делали фронты, отдельно бэкенды. Это очень удобно и с точки зрения разработки. Незачем фронту поднимать сервер, копаться там. Пусть он делает фронтовую работу и не знает, что на сервере. Пусть просто работает по спецификации, которую дают бэкенды. Ты поднял интересную тему: если сейчас делать проект на рельсе. А если не на рельсе, то на чем бы ты делал? Все зависит от того, какой проект, конечно. Давай как пример возьмем Teachbase. API, взаимодействие по JSON. Выкидываем Action View, выкидываем что-то еще. Может стоит использовать альтернативы на Ruby, но не Rails? Или вообще другой язык? Хороший вопрос. Если вопрос стоит как “что-нибудь другое на Ruby” - то нет. Во первых, у меня нет особого опыта. Я пробовал микрофреймворки типа Cuba, Sinatra. Такие микро-микросервисы, просто экспериментировал и смотрел, что это и зачем. Большие альтернативы, типа Trailblazer или Hanami, я не пробовал, они меня, в принципе, не заинтересовали. Я пока не понял, зачем они мне. Да, я видел бенчмарки, там все классно, быстро. Но рельсы и руби выбираются не для того, чтобы было быстро, а для того, чтобы было удобно. Поэтому такой аргумент для меня не самый важный. Да, у Hanami есть один очень большой недостаток: его никто не использует. Вот! Сложно тягаться в Rails, на котором пишут все, с них многие начинают свой путь в Ruby. Реальные конкуренты рельсам сейчас не внутри Ruby, а Elixir и Phoenix, которые набирают обороты. На мой взгляд это происходит отчасти потому, что Elixir хорошо пиарят. Его научились продавать командам разработчиков, говорят что Elixir классный, у вас все будет быстро. Даже в России уже есть люди, которые используют гибридный стек - часть рельсы, часть эликсира, все хотят его попробовать. И главное все хотят продать разработку на Elixir заказчику. Как коммерческий проект Elixir - очень классная штука. Он проще Erlang, хотя лично я бы все равно предпочел Erlang. Да, будет немножко больно, местами будет больше кода, хотя и это можно оптимизировать. Если отвечать на вопрос “что, если не Rails”. Я бы выбрал Erlang, но только в том случае, если мне дали бы пару разработчиков и чуть больше времени. В основном, все упирается в наличие разработчиков: их мало. С Elixir тоже проблема: многие, кто начал изучать Elixir и что-то на нем сделали, сразу считают, что они знают Erlang. Это примерно та же история, как когда люди, потыкавшие в рельсы, потом говорят, что они знают Ruby. Скорее всего, рынок пострадает от этого. Найти хорошего разработчика на эрланге будет еще сложнее, потому что будет много левого мусора. Во фронте сейчас похожие проблемы: если люди, которые выучили Angular, но не понимают, что такое JavaScript. Теперь везде есть такая проблема. Мы начали говорить про альтернативы Ruby. У тебя большой опыт работы с Erlang, ты писал на PHP, насколько я знаю, ты еще пишешь на go. На каких еще языках ты что-то пробовал делать и что хотел бы попробовать? Давай говорить хронологически. В школы и университете были Pascal, C, Basic, Assembler. Но в университете я пропускал программирование, оно мне очень не нравилось. Я до сих пор удивляюсь, как я так случайно стал программистом. Начинал я с ActionScript. То есть Flash? Да. Я начинал со второго ActionScript, он был ужасен. А вот в третьем появилось очень много изменений: нормальные классы, прокси объекты, которые все так ждут сейчас в JavaScript (но пока там не очень хорошо с поддержкой). Много всего классного, удобного. Как язык он был прикольным. Со своими минусами в виде не очень простой компиляции, в которой, если у тебя не Flash Builder от Adobe, приходится много колдовать. У меня был очень большой проект в рамках Teachbase, когда мы начали делать свое решение для вебинаров. Оно состоит из двух частей: клиентской и серверной. В серверной был Erlang, а в клиентской - большое ActionScript приложение. Это был мой первый большой проект, я продумывал его с нуля, с серьезной архитектурой, там было много классных идей. Это приложение до сих пор работает. В нем нет багов, я последний раз его правил два года назад! С тех пор оно классно работает. И это очень хорошо, потому что я даже не знаю, как мне его теперь собрать, запустить и так далее, у меня нет никаких систем сборки, и я уже плохо помню, как там все устроено. Подожди, третий ActionScript вышел очень давно, он старый. Около 10 лет. Он вообще развивается? Да, он очень старый, но еще жив, на нем пишут. Особенно много используют в игровой индустрии, сделали очень много оптимизаций с точки зрения графики, рендеринга, использованием GPU и так далее. На нем можно писать классные игры. Кажется, какая-то из популярных онлайн игр, типа танков, была изначально на flash. Сейчас не знаю, может, до сих пор. Был период, когда эти технологии были во всем реалтайме, когда, например, нужно было сделать видеочат, когда не было и намека на другие технологии, flash был везде. Это сейчас он мало у кого стоит. На Flash раньше было реализовано то, что сейчас есть в Web RTC, peer-to-peer. Этот проект в итоге был заброшен. Изначально он назывался Stratus, мы даже делали на нем побочный проект - портал для психологов с возможностью консультации онлайн. Работало через раз. Сейчас те вебинары, которые существуют и работают просто в браузере, заявляют, что используют Web RTC, но в большинстве случаев это не так. Именно для стриминга по прежнему используется flash, rtmp. Там он еще жив. Я очень хорошо знал ActionScript, но сейчас не сказал бы, что я в нем эксперт. И не планирую им заниматься. А теперь вернемся к нашему вопросу: что было после ActionScript? Потом был php. Не помню, какая там была версия, с ним были разные замуты. А как ты познакомился с Rails? Все получилось случайно и просто. Есть такая замечательная площадка Coursera, когда она только появилась, там было где-то пять курсов, один из них был про SaaS разработку и так далее. Этот курс, фактически, был таким введением в Rails, тогда еще 3. Не сказать, чтобы я выучил рельсы по этому курсу. Это был очень простой курс, вывод одной страницы и поиск по элементам из базы. Но там было хорошо рассказано про тестирование, про все его уровни. После этого я написал какой-то микро-микросервис для нашей системы. Очень страшный, некрасивый, он даже был запущен через rails s в development режиме. Но он работал, практически не падал. Сложно сказать, в какой момент я начал изучать и что-то делать, переключаться. Сильным толчком был поход на Brainwashing. Когда я туда шел, я практически ничего не знал именно про Rails: что там, как там. А на курсе получил пинок, скажем так. Сел и начал разрабатывать. Можно сказать что Равиль и Газай оказали на тебя большое влияние? Да, они подкинули вдохновения в этом направлении. Если дальше говорить о языках, потом был Erlang. Сейчас я иногда использую Golang для разных вещей. Язык довольно простой, можно выбирать его, если надо что-то быстро набросать. Он компилируется в исполняемый файл и его можно использовать. Еще я очень много занимался фронтом, сейчас уже меньше. Не тянет во фронт? Перейти темную сторону. Хороший вопрос. Наверное, нет. Я так себе фронетенд, потому что я не очень силен во всем, что касается стилей, верстки и прочего. Особенно с новыми замутами: какие-то CSS модули, CSS 4, все меняется очень быстро, не успеваю за этим следить. Мне никогда это не нравилось, я всегда считал верстку работой для каких-то…как-бы без расизма обойтись…не буду говорить :) Это черновая работа. Практически всегда мы отдавали ее на аутсорс. Нам присылали верстку, мы ее интегрировали. Один раз я предложил не мучиться, и все сделать самостоятельно. Тогда я начал этим заниматься. Спасибо Андрею Ситнику, который рассказал всякие интересные штуки и показал как делать не надо, дал некоторый вектор. И я начал делать много фронта, в итоге у нас в Teachbase основная логика на клиенте - это написанный мною фреймворк. Мы начинали еще до того, как React стал популярен, Angular еще не был особо популярен, но уже существовал. Я решил, что мне быстрее написать самому, я понимал как работает JavaScript, и не хотел тратить время на то, чтобы разбираться как работает Angular. Я ни разу не жалею об этом, потому что Angular работал в первой версии ужасно, на мой взгляд слишком неочевидно. Хотя кому-то это может казаться понятным. Во второй версии может быть что-нибудь поменялось. У меня был свой велосипед, он до сих пор работает, ребята его используют. В свободное от работы врем я пытался написать его новую версию на es6, но свободного времени оказалось не так много. Поэтому на гитхабе висит две недоделанных версии моего фреймворка :) Там прикольные идеи, но учитывая, что я тратил на это один день в месяц, они сильно отстают от тенденций, которые сейчас есть во фронте. Мы начали тему своих велосипедов. Как ты участвуешь в open source? Есть ли проекты, на которые ты хотел бы, чтобы ребята обратили внимание? Классный проект, но его никто не замечает. Свои проекты или чужие - не важно. Снова прорекламирую Brainwashing :) Open source для меня начался там, я сделал свой первый коммит в OS. В рамках курса ребята наткнулись на баг в pry-byebug, который был в экстеншене на C. Я его нашел, пофиксил, отправил и получил свой первый pull request, получил от этого удовольствие и немного подсел :) Начал этим заниматься. Если говорить про чужие проекты: я очень много работал над Rubocop, это проект Божидара Батсова. Мне очень нравится этот проект и в целом идея, что код должен быть стилизован. Я это везде пропагандирую, где есть возможность. Но ты же не используешь дефолтный конфиг rubocop? Конечно, я всегда там что-то правлю, что-то отключаю, что-то включаю. А меняются настройки из проекта в проект? У тебя есть сложившиеся настройки, которые ты всегда используешь или считаешь, что каждый раз нужно договариваться с другими разработчиками в проекте? По-разному. Сейчас я, например, пришел в проект с большой кодовой базой и мы прикрутили обязательную проверку rubocop’ом, но там у нас очень минимальный конфиг, который проверяет на очень плохие вещи, типа забытого дебага в коде или фокусы в спеках и так далее. И еще у нас включено несколько оптимизационных копов. Вещи типа длины строки, количества строк в методе и так далее мы в этом проекте не проверяем. А ты приверженец истории про 80 символов, 120 или просто отключаешь эту проверку? Я поддерживаю эту тему, обычно я ставлю 100. Это число получилось опытным путем: я долгое время работал на 21-дюймовом iMac и разрабатывал со сплитскрином. Я делал так, чтобы в обеих частях экрана входили все строчки. Это как раз примерно 100 символов. Логика выбора длины строки была такая, потому что горизонтальный скролл это очень неудобно. Про длину методов или длину класса… нет. Комментарий в начале строки, enter в конце Пустую строку в конце я всегда ставлю. Делаю это, потому что так удобно перейти в конец файла. Есть некоторый отступ снизу, тебе не надо попадать в границу дисплея. Я где-то читал, какими историческими ограничениями это правило было вызвано, в каких-то старых системах. Точно уже не воспроизведу, что там было. И сейчас гитхаб постоянно это подсвечивает в диффах, ругается когда у тебя нет пустой строки - это не очень приятно. В моем дефолтном конфиге на нулевом проекте многое включено, но эти параметры сложности немного увеличены. Если где-то очень большая сложность, и я не хочу рефакторить какой-то метод осознанно, то я просто отключаю этот коп локально, да и все. Но во всех гемах, которыми я занимаюсь, или в которые я активно контрибьютил, внедрял это дело. Про rubocop понятно. На какие еще проекты стоит обратить внимание? В каких ты принимал участие? Я много работал над проектами из экосистемы InfluxDB. Это база данных для хранения временных рядов. Интересный проект, сейчас он вырос в InfluxData, у них свой стек, это что-то похожее на стек от Elasticsearch, где у тебя есть сборщик логов, визуализатор, сама база, но он заточен не на логи, а на какие-то временные метрики. Я начал его использовать в Teachbase, он тогда был не очень известен, это было примерно полтора года назад. Их история очень похожа на историю с Rails 5: была версия 0.8, они обещали через месяц выпустить следующую, более стабильную и с багфиксами, с кластеризацией и так далее. Я даже с ними списывался, мне отвечали что работа идет, версия скоро будет. Было довольно рискованно использовать не очень production ready историю, пару раз все очень страшно падало. Но в итоге, обещанная версия вышла, как и Rails, только в начале этого года. Мы прожили год на нестабильной версии, пришлось все-таки с ней работать. Один из моих больших open source проектов, как раз известен тем, кто работает с этой базой. Я написал адаптер для работы с этой базой в стиле Active Record. Проект называется Influxer. Он очень похож на ActiveRecord: определяется некоторый класс, говоришь какие у него есть атрибуты (это атрибуты этих меток в базе), и он позволяет делать запросы, такой синтаксический сахар. InfluxDB поддерживает SQL-подобный язык, и вместо того, чтобы писать на нем можно использовать вот такую обертку. Это удобно, там есть некоторые фишечки, связи с моделями и так далее. Он активно использовался в Teachbase, для этого он и делался. Я и сейчас продолжаю его поддерживать, в связи с выходом новых версий базы и изменением API, там все более или менее актуально. Проект кто-то использует, есть несколько десятков звездочек. Помимо Influxer я занимался другими проектами для этой экосистемы. До какого-то момента весь код был открыт, сама база и все второстепенные сервисы, которые там использовались. В этом году они ввели коммерческий вариант. Часть кода, естественно, уже не в open source, особенно то, что касается кластеризации. Все остальное открыто, и разработчики рады, когда туда приходят люди и контрибьютят. Там все написано на go, и мой первый опыт с go получился именно там. Я делал пару патчей в проект, который называется Telegraf : это сборщик логов, что-то типа Logstash или новых beats от Elasticsearch. Проект очень активно развивается, до стабильной версии далеко. Если вы хотите попробовать go и поучаствовать в open source, знайте, что там довольно просто сделать pull request. Расскажи еще про Thinknetica. Ты там играешь роль наставника, что это значит? Какой опыт ты оттуда вынес? Сколько обучил человек? Да, слово наставник мне нравится больше. Раньше мы называли друг друга менторы, но это как-то не по-русски. Я работаю там 1,5 года, но с перерывами. Мы берем группу, занимаемся, потом делаем перерыв и так далее. Я обучил человек 50, может чуть больше. Из них процентов 20 очень классные ребята, которые хорошо трудоустроились после курса. Много кто из выпускников устраивается потом на профильные вакансии, но я не сильно слежу за этим. Когда обучаешь довольно простым вещам (мы не учим чему-то сложному), это расширяет кругозор, не дает глазам замылиться. Ты видишь разный код очень разных людей. Ты видишь разные ошибки, прежде всего. Некоторые ты встречаешь первый раз в жизни, то как люди пишут, странные баги. Очень много интересной информации для мозга. Не даешь себе засохнуть. Нравится ли тебе быть наставником? Когда ученики хорошие - нравится, когда плохие - нет. Я очень нервный человек, мне хочется всех послать. В этом плане я скорее тренер, чем учитель, я довольно жесткий. При этом мне нравится общаться с теми, в ком я вижу интерес. Не обязательно должно получаться, но когда ребята стараются, это очень классно, с ними можно поговорить, мы периодически встречаемся лично. Они задают интересные вопросы, которые меня самого заставляют подумать. В целом, любой вид преподавания, особенно если ты преподаешь что-то связанное с твоей профессиональной деятельностью, - это бОльшая прокачка для того кто преподает, чем для тех, кто учится. Помимо знаний, которые получаешь по Ruby, про то как общаться с людьми, можно оттачивать свое ораторское искусство, общение с публикой по ту сторону кабеля, когда проводишь вебинары. Плюсов в этой деятельности много, минусы тоже есть. Есть рутина, когда ты третий раз ведешь один и тот же курс, тебе не так интересно. Ждешь, когда ученики уже дойдут до интересных тем, чтобы с ними было о чем поговорить, а то все какую-то фигню делают :). Вот и мы дошли до интересной темы :) Лейтмотив нашего интервью - RailsClub, ты там будешь рассказывать про Action Cable. В основном, все ему рады. Есть недостатки, не все еще клево, он подтекает; бывает, что два треда пишут в один канал. Но в целом, все очень довольны. И только от тебя я слышу скепсис. Расскажи о чем будешь докладывать? Не хочется спойлерить, но я чувствую, что у тебя на эту тему есть боль. Поделишься? Давай вернемся в весну 2015. За некоторое время до того, как состоялась конференция, на которой DHH объявил об этой замечательной фиче. Это для тебя действительно замечательная фича или такая “замечательная фича”, в кавычках? У меня к ней двойственное отношение. В чем-то замечательная, в чем-то “замечательная”. В любом случае, это громкая фича. В Teachbase вебсокеты использовались. Естественно, они были поддержаны эрлангом, потому что это был наш стек. У нас были планы по тесной интеграции сервиса, который обрабатывал данные с веб сокетов, с рельсой. Готовые решения, которые были в рельсе, мы не рассматривали, потому что людям, у которых есть вебсокет сервис написанный на эрланге, зачем-то пихать вебсокеты на Ruby было бы странно. Это как дать дворнику игрушечный совок. У нас была собственная идея (она реализована, выложена в open source и работает), как подружить рельсы с сокетами. И вот, в марте или апреле выходит Action Cable. Я посмотрел видео, посмотрел примеры, которые были. Первое впечатление было: “Вау, ничего себе! Это круто, это выглядит очень классно, удобно, красиво - прямо то, что я бы хотел использовать”. Это был дополнительный аргумент, чтобы не мигрировать на 4.2, а ждать Rails 5, чтобы в новой сделать что-то, используя кабель, сделать все классно. Хорошее впечатление от Action Cable относилось в первую очередь к каналам, к тому, что сделано непосредственно в Rails, обертке бизнес-логики. Мне очень понравилось, как все сделано: очень rails way, все как надо. Но была и вторая мысль - а на чем это будет? Это мысль пришла мне в голову, когда репозиторий самого кабеля в исходниках отдельно выложили на гитхаб. Тогда это работало на Celluloid, если я правильно помню. То есть это было реализовано на Ruby, что, конечно, не круто. У меня предвзятое, но распространенное мнение, что писать конкурентные программы на Ruby не нужно. Это не то, для чего этот язык был создан, особенно если говорить о масштабируемости и эффективности с точки зрения потребления ресурсов. Тогда у меня возникла идея подумать над тем, как же нам взять хорошее от Action Cable и хорошее от того, что на тот момент уже было реализовано в сервисе на Erlang. А там было уже много всего: горизонтальная масштабируемость, различные авторизации и так далее. Тогда я еще не знал про Phoenix. Как потом выяснилось, это было очень похоже на то, с чего начинался Phoenix. Но только сделано на живом Erlang. Хотя по факту под капотом все мы используем один и тот же Cowboy как эрланговский веб сервер. За год в кабеле произошло, конечно, очень много изменений. Все они, пожалуй, положительные. Во-первых избавились от Celluloid в пользу nio4r (который тем не менее и к Celluloid имеет отношение).Добавили очень много различных возможностей синхронизации, адаптеры и прочее.Но основные проблемы уходить не спешат. Буквально недавно был нашумевший баг с утекающей памятью, незакрывающимися соединениями. Довольно странно, что он возник уже после релиза 5.0. Еще висит несколько багов, связанных с производительностью. Все это говорит о том, что Action Cable сейчас не подходит для продакшена в какую-то большую систему, не блог с посещаемостью 100 человек, а реально большую систему с нагрузкой в тысячи и сотни тысяч людей. Это не тот инструмент, который может решить задачу. Тогда возникает вопрос, а какие вообще проблемы может решать Action Cable? Все мы знаем, что все нововведения в Rails появляются ради одного всем известного проекта на букву B. Я проверил, там действительно используется Action Cable, насколько это возможно определить, просто посмотрев логи браузера. Там используется там не тот Action Cable, который сейчас предлагается в рельсе, а, видимо, какая-то его предыдущая версия. А может это вообще не Action Cable? Может быть. По крайней мере, протокол веб сокетов подписан как ActionCable, но в какой сервер он стучится - мы не знаем. Протокол очень похож. К сожалению, инсайдерской информации оттуда нет. Но я не удивлюсь, если на самом деле там работает какой-нибудь сервер, который просто работает по тому же протоколу, может быть общается с рельсой, хотя на самом деле для того, что они делают, это и не нужно делают они буквально два сценария: отправить изменения, которые произошли на странице (кто-то написал комментарий, отправил тудушечку и так далее). Это бродкаст, первый сценарий. И сценарий, который, наоборот, от клиента отправляет информацию серверу о том, что человек делает на страничке. Она передается в несколько зашифрованном виде, но там примерно следующее: перешел на страничку или закрыл вкладку, трекинг активности некоторый. То есть, у них это все используется не очень нагружено? Да. И в этом случае Action Cable хватает. С одной стороны. А с другой стороны возникает вопрос: а зачем тут рельса? Я вижу единственный момент, который точно там используется, это аутентификация. Нам нужно как-то подтвердить право человека подключиться к сокету, подписаться на конкретный канал и так далее. Вот тут они наверное взаимодействуют с приложением. Но не факт, может быть и нет. Все остальное имеет малое отношение к бизнес логике. Я делал нечто подобное, у меня как раз веб сокеты использовались для трекинга активности. Все эти данные не писались в основное приложение, они там вообще не нужны, по крайней мере в сыром виде. Они писались в отдельную систему, там уже обрабатывались и потом вытягивались, когда нужно. В данном контексте не очень понятно: нужен там Action Cable или нет? Используется он или нет? Но раз это квакает как Action Cable, давайте допустим, что это он. Больше я не знаю реальных примеров. И я думаю, пока нет известных проектов, которые используют Action Cable. Наверное, многие хотят его использовать, но вопрос в объемах. Он очень хорош в том, в чем хороши все рельсы - быстро собрать MVP, показать кому-то первую версию проекта. Тебе не нужно ничего тащить, все есть в коробке, набросал realtime и работает. Но когда ты начинаешь это дело развивать, и появляются клиенты, нагрузка и так далее - что делать с Action Cable? Можно, в принципе, плодить инстансы, он выносится отдельно, как какой-нибудь фоновый Sidekiq и прочие побочные сервисы, которые есть у нас в приложении. Но насколько это эффективно - не знаю, пока у меня есть на этот счет большие сомнения. На твой доклад я очень хочу сходить. По моим ожиданиям это будет один из самых клевых докладов. Какие у тебя ожидания от RailsClub’а? Я первый раз ходил на конференцию в прошлом году. Чего-то о прямо очень зацепившего не было. Но были хорошие докладчики, например Claudio Baccigalupo, который говорил про Rails 5. Доклад Koichi Sasada про garbage collector, историю с поколениями, был очень сильный и интересный. Я понимал, наверное, процентов 70, но это было очень круто. Но я думаю, что любая конференция ценна не столько докладами, а тем, что происходит в кулуарах. Поэтому такого общения я и жду, учитывая что у нас приезжают “звезды”. Не знаю, насколько они будут готовы выйти в народ пообщаться, но это интересно. То есть ты бы задал пару вопросов Матцу? Честно говоря, у меня к нему нет вопросов :) Я бы послушал, что он будет отвечать на вопросы других, обычно я делаю так, редко сам спрашиваю. На прошлой конференции я общался с тобой, после доклада о микросервисах (Андреем Дерябиным, ведущим подкаста). И немного общался с Клаудио. Еще на прошлом RailsClub я узнал про Crystal, это довольно интересно, я теперь слежу за этим проектом. Подумываю над тем, чтобы как-нибудь где-нибудь его применить, написать на нем какой-нибудь экстеншен для Ruby, благо есть такая возможность. Какое-нибудь узкое место, может быть даже в проекте, над которым я сейчас работаю. Жду, когда выдастся свободный денек, чтобы разобраться и поиграть с этим делом. Про RailsClub этого года пока не опубликована информация о докладах, есть только люди. Посмотрим, что нас ждет. Мы выражаем огромную благодарность Лене Могильниковой за помощь с организацией этого выпуска.
Наш гость - Алексей Найден Профиль на Github Профиль на Facebook Проекты Алексея с Evil Martians: OnlineTours REN TV Wannafun
Victoria Melnikova is the Head of BizDev at Evil Martians. She joins the show to talk about, How to turn an open-source project into a profitable business. She begins the show by talking about Evil Martians and the services that they offer. She dives into commercial open-source. Moreover, she shares her perspective on how to grow an open-source project and how to monetize it.SponsorsChuck's Resume TemplateRaygun - Application Monitoring For Web & Mobile AppsBecome a Top 1% Dev with a Top End Devs MembershipLinksDev Propulsion Labs — Ep. 1: Building communities around dev tools productsHow to turn an open-source project into a profitable businessOKLCH Color Picker & Convertersidekiq/sidekiqOptimize images for web on the flyAnyCableTwitter: @sitnikcodeLCH Color Picker & ConverterSearch Paul Graham essays with Siri — Building an embedding powered product in few lines of codeSocialsLinkedIn: Victoria MelnikovaPicksCharles - Between Two Castles of Mad King Ludwig Charles - Star Trek: PicardCharles - Corey Hart - Sunglasses At Night (Official Music Video)Valentino - A no-go fantasy: writing Go in Ruby with Ruby NextVictoria - RunningVictoria - The Bear (TV Series 2022Advertising Inquiries: https://redcircle.com/brandsPrivacy & Opt-Out: https://redcircle.com/privacy
© 2020-2025 Ivy Podcast Discovery LLC
