Podcasts about Heroku

  • 288PODCASTS
  • 996EPISODES
  • 49mAVG DURATION
  • 5WEEKLY NEW EPISODES
  • Oct 5, 2022LATEST
Heroku

POPULARITY

20152016201720182019202020212022

Categories



Best podcasts about Heroku

Show all podcasts related to heroku

Latest podcast episodes about Heroku

Software Engineering Daily
Open-source Serverless Postgres with Nikita Shamgunov

Software Engineering Daily

Play Episode Listen Later Oct 5, 2022 47:12


PostgreSQL is a free and open-source relational database management system. Postgres-based databases are widespread and are used by a variety of organizations, from Reddit to the International Space Station, and Postgres databases are a common offering from cloud providers such as AWS, Alibaba Cloud, and Heroku. Neon is a serverless open-source alternative to AWS Aurora The post Open-source Serverless Postgres with Nikita Shamgunov appeared first on Software Engineering Daily.

Breaking Changes
The Opsification of the Enterprise with Viktor Farcic, Developer Advocate, Upbound

Breaking Changes

Play Episode Listen Later Sep 25, 2022 42:06


In this episode of Breaking Changes, Viktor Farcic of Upbound joins Kin to talk about the opsification of the enterprise and how we need to provide Heroku-like guardrails for all of the infrastructures that our teams need access to, helping abstract away the increasing complexity of operations and allow developers to focus on what truly matters to the business.

Sustain
Episode 139: Manuel Riel on PikaPods, a container hosting service for open source apps

Sustain

Play Episode Listen Later Sep 23, 2022 29:24


Guest Manuel Riel Panelists Richard Littauer | Justin Dorfman Show Notes Hello and welcome to Sustain! The podcast where we talk about sustaining open source for the long haul. Today, we are super excited to have as our guest, Manuel Riel, joining us from Austria. Manu ran a web development agency and launched multiple open source related products, including an invoice processing tool, and a backup service. He's also the Co-founder of PikaPods, which is a container hosting service for open source apps. Manu is with us to talk about PikaPods. We'll find out what it does, why it's needed, the benefits of having it, the most popular app, and plans he has in the future for PikaPods. Go ahead and download this episode to learn more! [00:01:23] Manu tells us his background, what PikaPods is, and about the apps. [00:03:32] What's the difference between Heroku, Netlify, and PikaPods? [00:04:29] Since you can't run your own stuff and you can't edit the apps, Manu explains how this is an open source marketplace. We hear about PikaPods user base, how long he's been up and running, and how many people are using the platform. [00:06:11] Manu explains the one source of revenue they provide to open source office. [00:09:06] We hear Manu's selling point he pitches to open source maintainers and open source projects. [00:11:45] Why did Manu choose to work with open source projects to host when there are other things available to him? Why PikaPods? [00:13:32] Justin brings up pricing on PikaPods site and comments a trend with the ones that paid the least had the most demands. He wonders how Manu deals with that. [00:15:04] Justin wonders if the services are subsidized by using the BorgBase infrastructure, and Manu explains how they are totally separate, and he tells us about his team. [00:16:31] We hear if there are any collabs with maintainers Manu is working with since there are a lot of projects he hosts. [00:18:02] Find out PikaPods most popular app, if there's a limit, and if bandwidth is an issue. [00:21:17] Manu shares some things he would like to do in the future with PikaPods. [00:23:35] How does Manu position himself in the ecosystem and are there other things that could be used in collaboration with PikaPods that makes it easier for maintainers? [00:25:37] Find out where you can follow Manu and PikaPods online. Quotes [00:10:08] “Hosting is not a good fit for part-time maintainers because it's a big responsibility.” [00:12:20] “The motivating event for me was the Log4j Vulnerability.” Spotlight [00:26:42] Justin's spotlight is pydantic, data validation and settings management using Python type hints. [00:27:10] Richard's spotlight is Amna Shamim. [00:27:36] Manu's spotlight is Uptime Kuma, a fancy self-hosted monitoring tool. Links SustainOSS (https://sustainoss.org/) SustainOSS Twitter (https://twitter.com/SustainOSS?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor) SustainOSS Discourse (https://discourse.sustainoss.org/) podcast@sustainoss.org (mailto:podcast@sustainoss.org) Richard Littauer Twitter (https://twitter.com/richlitt?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor) Justin Dorfman Twitter (https://twitter.com/jdorfman?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor) PikaPods (https://www.pikapods.com/) PikaPods Twitter (https://mobile.twitter.com/pikapods) Apache Log4j Vulnerability (https://status.n-able.com/2021/12/20/apache-log4j-vulnerability-updated-230-p-m-est-december-20-2021/#:~:text=As%20you%20may%20know%2C%20a,potentially%20vulnerable%20to%20this%20exploit.) pydantic (https://github.com/pydantic/pydantic) Amna Shamim (https://github.com/pydantic/pydantic) Uptime Kuma (https://github.com/louislam/uptime-kuma) Credits Produced by Richard Littauer (https://www.burntfen.com/) Edited by Paul M. Bahr at Peachtree Sound (https://www.peachtreesound.com/) Show notes by DeAnn Bahr Peachtree Sound (https://www.peachtreesound.com/) Special Guest: Manuel Riel.

The Bike Shed
355: Test Performance

The Bike Shed

Play Episode Listen Later Sep 20, 2022 42:44


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.

Les Cast Codeurs Podcast
LCC 285 - De mal en pis - partie 2

Les Cast Codeurs Podcast

Play Episode Listen Later Sep 16, 2022 50:38


Dans cette partie 2, nous discutons le changement d'étage gratuit chez Heroku, les vagues de licenciement dans le monde technologique, le carrière de contributeur individuel et le cloud souverain. Et on vous parle de division de nombres entier dans la rubrique débutant. Enregistré le 9 septembre 2022 Téléchargement de l'épisode LesCastCodeurs-Episode–285.mp3 News Infrastructure NVidia interdit de vendre ses processeurs d'intelligence artificiels les plus puissants en Chine https://www.reuters.com/technology/nvidia-says-us-has-imposed-new-license-requirement-future-exports-china–2022–08–31/ Le gouvernement Américain a mis en place la restriction (export control) 10% des ventes en Chine pour NVidia Après 23ans un internaute arrête d'utiliser son propre serveur e-mail et il explique pourquoi cela est devenu impossible https://t.co/TQ61y45MXT?ssr=true Sa raison: l'impossibilité d'avoir un service fiable. Les services de gestion d'e-mails sont désormais dans les mains de quelques gros acteurs (Google, Microsoft,..) qui déploient à coup d'algorithmes des filtres pour mettre en spam les e-mails indésirables Ces derniers sont obscures et peuvent être stupides en blacklistant des blocs entiers d'IPs L'internaute demande aux acteurs de se réveiller avant que les politiciens s'en mêlent (pour le pire …) Cela demande aussi la mise en place de protocoles plus avancés comme DMARC Pour des adresses “casual” comme celles des cast codeurs, c'est maintenant passage à la caisse et 3 à 5 euros par mois et pas adresse email c'est plus que la valeur de ces emails “casual” Cloud Heroku annonce la fin de son étage gratuit https://techcrunch.com/2022/08/25/heroku-announces-plans-to-eliminate-free-plans-blaming-fraud-and-abuse/?guccounter=2&guce_referrer=aHR0cHM6Ly90LmNvLw&guce_referrer_sig=AQAAACIpHvzb3Pb2gtgt8Dm99CWGUhbEkdTgLVDgKwMNNmDI9UITQyNX64GA2LB6rQGNX2EreLoiRvxTqSUls5V_F8x6Cv_xGrfXtaIROP_Jiv45UUO1ODBIno3j7vHC4gokKVLqsZ948CmCfzG2bF03DL-uhbZqYuGXvxTfdsioTbjg heroic éliminé sont plan gratuit dénonçant des abus apres 10 ans pousser vers du paid plan, qui va aussi faire partir des gens et questionner ceux qui avaient un modèle économique base sur ce plan gratuit 28 novembre et aussi efface les comptes inactifs depuis 1 an beaucoup de fraude et d'abus vont garder des plans low cost et des plans étudiants au delà des abuseurs, les plans gratuits étaient utilises pour tester les apps avant leur déploiement Outillage Polices de caractères pour la programmation https://www.programmingfonts.org/#firacode J'aime bien Fira Code moi :slightly_smiling_face: Ce site permet de choisir parmi 111 polices différentes, pour pouvoir les comparer et choisir celle qu'on préfère Mickael Istria pointe sur une video expliquant les nouveautés autour d'Eclipse https://www.youtube.com/watch?v=zDJtVYAJwyY c'est très visuel, â regarder Code snippet Content assis plus rapide Support des concepts récents de Java comme sealed classes dans les quick fix Etc Utiliser git blame malgré les reformattages https://michaelheap.com/git-ignore-rev/ fichier listant les revisions pour ignorer certains sha1 et le changement d'avant est pris Une page concise des quelques façons de sortir d'un problème avec Git (langage coloré) https://ohshitgit.com/ On a toujours quelquye chose a apprendre ; celle qui nettoie la branche principale, je ne connaissais pas. Architecture Les tendances vu pas les éditeurs de InfoQ dans le devops et le cloud https://www.infoq.com/articles/devops-and-cloud-trends–2022/?utm_source=twitter&utm_medium=link&utm_campaign=calendar commenter les 4 vagues et ce qu'il y a dedans Data observability : live qualité de data etc Serverless everything: scale to 0 ; même les bases de données (soit parce que infra partagée soit via un scale down réveille par access à une gateway FinOps: contrôle des cours comme on optimisait pour les œufs eBPF pour injection de code et WASM pour le service mesh ingress (attention WASM dans envoy ne pas pas ton bon vieux Netty) Protection de la supply chain (encore faible en solutions) Low code no code mature pour moins besoin d'ingénieurs ou approche plus légère Developer experience qui influence les decisions Méthodologies Discussion sur la carrière contributeur individuel https://touilleur-express.fr/2022/07/17/devenir-staff-engineer/ exemple de ce que fait doctolib senior c'est le premier niveau d'autonomie et d'aisance ensuite, soit vous voulez coacher vo pairs (manager), soit contributeur individuel ce qui est demandé c'est le leadership (donc l'impact sur la societe et l'organisation) et ca demande une taille de societe minimale technique, communication, marketing d'idée occuper le role avant d'être reconnu (c'est assez classique ; ce qui change c'est le formalisme de la liste des competences attendues entre les boites) et on code moins car coder seul a moins de levier equivalence track technique/leadership et track managériales avec des ponts. Souvent d'arrète avant les VP et autre executive leadership (matrice de Radford) Premotion case avec promotion committee (2 fois pas an) Assez classique de paires un leadership avec un manager pour qu'ils s'épaulent mutuellement staff vs principal peut aussi etre du a l'impact cumulé de la personne et des principals peuvent aider sur une partie plus « bas niveau » / concrete de l'orga ou des projects grace a son experience et ses connexions au dela de son équipe actuelle des exemples de situations de travail du staff engineer https://touilleur-express.fr/2022/07/20/vis-ma-vie-de-staff-principal-engineer/ Loi, société et organisation https://twitter.com/smlpth/status/1551943751714603013?s=21&t=JhmioeiqlY8wFbzjry6b8Q encore un licenciement de masse. 10% chez Shopify. Pas mal d'aides pour faire passer la pilule (congés payés, aide à trouver un nouveau job…) ils ont fait le pari que post covid les gens resteraient à acheter en ligne mais c'est revenu aux volumes d'avant crise et inflation n'aident pas Annonce à l'américaine avec e-mail direct et arrêt du travail le lendemain Paye pendant quelques temps et support Un article sur les licenciements dans la tech des GAFAM et des startups https://www.lefigaro.fr/secteur/high-tech/la-grande-inquietude-des-salaries-de-la-tech-face-a-la-vague-de-licenciements–20220819 recession, résultats décevants, krach boursier (perte 1/4 de leur valeur) recerrement des politiques budgétaires, donc les projets semi viables ne le sont plus 88k licenciement en trois mois vs 5000 en 1 an en 2021: gros mois juin ->août Apple, Microsoft, Amazon, TikTok, Shopify, Snapchat, Netflix (–40% bourse), SoudnCloud (–20% d'effectif) L'argent facile arrête le cycle d'hyper acquisition et de facilite a l'hyper inflation des sociétés tech car impossibilité de lever des fonds startup ont du mal a garder les clients acquis en 1 donc recentrage et chute des activités non rentables fidélisation de l'employé vs aller chercher la meilleur offre comme un mercenaire Le Cloud de Confiance sous le coup du Cloud act américain ? https://www.nextinpact.com/lebrief/69865/les-clouds-confiance-bleu-et-s3ns-seront-bien-soumis-au-cloud-act-americain Alors attention, parce que Next Impact fait un peu dans le sensationnalisme https://twitter.com/pchapuis/status/1565775842675933188?t=y5S63FbOSbtH4FK_1meECQ&s=19 Avec cette interprétation, même Clever Cloud, utilisant du matériel américain, serait soumis au Cloud Act étude demandée par le ministère de la justice des pays bas le cloud act s'applique quand le fournisseur de cloud européen utilise du hardware ou logiciel américain (e.g. cloud de confiance Bleu et S3ns) muraille de chine en refusant tout client américain et en employant zero américain. mais c'est si le logiciel américain a accès aux données (routeur Cisco en decrypté etc), Stockage sans la clef cote client, etc le contrat MS serait « ring fencé » contre le cloud act mais peu d'infos Rubrique débutant Comment faire une division de deux entiers dans un flottant ? https://www.baeldung.com/java-integer-division-float-result Une division d'entier ramène que le quotient Et un entier Retourne un double au un des opérandes est un double, puis float, puis long. Donc il faut d'aster une des opérandes en float et pouf Conférences Nous contacter Pour réagir à cet épisode, venez discuter sur le groupe Google https://groups.google.com/group/lescastcodeurs Contactez-nous via twitter https://twitter.com/lescastcodeurs Faire un crowdcast ou une crowdquestion Soutenez Les Cast Codeurs sur Patreon https://www.patreon.com/LesCastCodeurs Tous les épisodes et toutes les infos sur https://lescastcodeurs.com/

Python Bytes
#301 PyTorch Grows Up and Moves Out

Python Bytes

Play Episode Listen Later Sep 15, 2022 31:10


Watch the live stream: Watch on YouTube About the show Sponsored by Microsoft for Startups Founders Hub. Michael #1: PythonAnywhere: Our Commitment to Providing Free Accounts via Matthew Kramer In light of Heroku's cancelling their free tiers… They believe free tiers are important for beginners Two part solution: Limit outbound internet access for free accounts “Proof of life” to keep running - 3 months for apps, 1 yr for accounts BTW, they were acquired by Anaconda Inc. Brian #2: ruff: An extremely fast Python linter, written in Rust. Announcement article: Python tooling could be much, much faster Charlie Marsh Quite the star history, as it's a new repo as of Aug 30. Now at 1.8k. It is extremely fast. I installed it and tried it on a small project. It ran so fast I thought it didn't do anything. I went and added some errors to convince myself it was running. $ time flake8 src tests ... flake8 src tests 0.29s user 0.02s system 98% cpu 0.311 total $ time ruff src/ tests/ ... ruff src/ tests/ 0.01s user 0.01s system 162% cpu 0.011 total Michael #3: Meta spins off PyTorch Foundation to make AI framework vendor neutral PyTorch, which powers Tesla Autopilot and 150K other projects, will join the Linux Foundation. Its governing board includes representatives from Nvidia, Meta, Google, Microsoft, Amazon, and AMD. The PyTorch Foundation will strive to adhere to four principles, Remaining open Maintaining neutral branding Staying fair Forging a strong technical identity According to Meta, the transition to the PyTorch Foundation will not affect any existing PyTorch code Brian #4: Two string resources Python String Methods to Know Trey Hunner F-Strings Number Formatting Cheat Sheet Brian Allan Extras Brian: In Feb, on episode 271, we talked about Seaborn's new object interface Well, it's out now in seaborn 0.12 Interesting discussion about lazy imports. Other than that, I'm good with your extra.

Swisspreneur Show
EP #262 - Chris Bach: The Fastest Way To Build Sites, Stores & Apps

Swisspreneur Show

Play Episode Listen Later Sep 14, 2022 57:39


Timestamps: 11:20 - Giving up your salary for a startup idea 12:58 - Moving to California 23:25 - Marketing a solution with broad applications 32:19 - Tweaking your pricing 40:03 - Convincing investors to invest About Chris Bach: Chris Bach is the CSO/CCO at Netlify, a platform for building highly-performant and dynamic websites, e-commerce stores and apps. He studied film and media science at the University of Copenhagen but then pivoted to the business world, and created Netlify in 2015 together with co-founders Mathias Biilmann. By uniting an extensive ecosystem of technologies, services and APIs into one workflow, Netlify unlocks new levels of team productivity, while saving time, money and the planet. Their idea was to change the architecture of the web and provide a viable workflow for developers, since nowadays it's known that the biggest overall challenge companies face is reducing time to market, and that the number 1 way of doing so is to invest in developer tools and workflow. They knew that Netlify would have to be venture-backed in order to have the right time-to-market and create the desired impact. Europe was much too risk averse in terms of capital, so they decided to raise funds in the US. To date they've taken on $212M in investment from investors such as A16Z, Kleiner Perkins, Bessemer, EQT, BOND and Menlo Ventures, and angels such as the founders of Github, Heroku, Rackspace Cloud, Slack, Yelp, Figma, and many more. Memorable Quotes: "Venture capital was much too risk-averse in Europe. What we needed was the Silicon Valley approach." "The mission is not money. The mission is building a better web." Don't forget to give us a follow on our Twitter, Instagram, Facebook and Linkedin accounts, so you can always stay up to date with our latest initiatives. That way, there's no excuse for missing out on live shows, weekly give-aways or founders dinners!

Les Cast Codeurs Podcast
LCC 284 - De mal en pis - partie 1

Les Cast Codeurs Podcast

Play Episode Listen Later Sep 12, 2022 50:20


Dans cet épisode, nous discutons bonnes pratiques Java, Groovy, WebAssembly, Micronaut. Nous discutons également le changement de licence de Akka entre autre. La suite de cet épisode parlera de changement d'étage gratuit chez Heroku et des vagues de licenciement dans le monde technologique. Pour rester sous les 1h d'écoute, nous avons découpé les deux derniers épisodes nouvelles en 2 parties chacun. Qu'en pensez vous ? Donnez-nous votre avis sur Twitter ou sur le Google Groups des cast codeurs. Enregistré le 9 septembre 2022 Téléchargement de l'épisode LesCastCodeurs-Episode–284.mp3 News Langages Jonathan Giles, un principal architecte de Java chez Microsoft, a un site qui partage des bonnes pratiques Java http://java.jonathangiles.net/ il couvre des bonnes pratiques Java de manière générale, mais également plus spécifiquement pour les développeurs de librairies Java Des conseils sur la bonne utilisation des dépendances, des BOMs, des versions LTS de Java, des modules Java, de la surface des APIs publiées, de faire attention à null ou au boxing, et de comprendre les interfaces fonctionnelles il y a beaucoup de contenu donc faites par petites doses Certains sujets sont plus controversés comme les modules Java les recommendations sont assez succinctes Je suppose que ce sont les recommendations que les équipes du Azure SDK suivent et qu'il a ouvert. Donc merci à lui Project Leyden https://www.infoq.com/news/2022/06/project-leyden-delays-aot/ Leyden n'a pas progressé en deux ans Accepté que GraalVM a déjà achevé les objectifs initiaux Donc vont explorer un spectre plus faible de contraintes (et probalbment d'optimisations Prochaine LTS en Sept 2023 et Leyden ne sera pas mature, donc Leyden sera utilse ~ Sept 2027 (en terme d'adoption) au plus tôt. SpringBoot pensent que CRaC (snapshot de la memoire sur disque pour demarrage plus rapide) sera très utile module-info dans Spring pourn jlink est dans la roadmap Lead de CRaC a fourni un prototype pour Quarkus: ameliore temps de demarrage pour OpenJDK mais pas la consommation memoire jlink pour Quarkus, dans un context Kube, les gains d'espace disque ne sont pas si interessant vs un layered image Micronaut a des issues ouverst pour CRaC José Paumard couvre Loom et Structured Concurrency dans sa vidéo de la série JEP Café https://inside.java/2022/08/02/jepcafe13/ Et cet article explique les problèmes classiques de concurrence comme les thread leaks et introduit la Structured Concurrency https://howtodoinjava.com/java/multi-threading/structured-concurrency/ Paul King montre l'utilisation de différents frameworks de tests avec Groovy (Spock, JUnit5, Jacoco, Jqwik et Pitest) https://blogs.apache.org/groovy/entry/testing-your-java-with-groovy Paul couvre aussi dans un autre article les comparateurs, et l'utilisation de l'API GINQ https://blogs.apache.org/groovy/entry/comparators-and-sorting-in-groovy La matrice spot est intéressante mais pas avec des noms de variable à, b, c, d :) L.article est super didactique et explique via un example concret quand utiliser quoi Je trouve les property base testing pas si simple à utiliser et avec un coup de réflection >> au truc testé. Mais peut être le cas est super simplistique pour l'usage Paul King continue de publier régulièrement des articles sur Groovy - https://blogs.apache.org/groovy/entry/working-with-sql-databases-with — accéder à des bases SQL avec Groovy et GraalVM - https://blogs.apache.org/groovy/entry/detecting-objects-with-groovy-the — détection d'objet avec le machine learning avec Deep Java Library et Apache MXNet Sortie de Spock 2.2, première version GA avec le support officiel de Groovy 4 https://twitter.com/spockframework/status/1564999285250326529 Bah la seule info intéressante est déjà dans le titre, càd c'est le support officiel de Groovy 4 Google lance un nouveau langage, appelé Carbon, comme un successeur de C++, mais en plus sympa ! https://github.com/carbon-language/carbon-lang interessant, ils veut Ceyloniser ou Scalaizer Rust avec Carbon's Kotlin-like strategy. Not a bad bet Rust n'est pas assez compatible avec C++, c'est problématique, surtout pour des boîtes comme Google avec d'énormes code bases en C++. Donc pour du green-field, Rust c'est bien. Ou c'est bien aussi pour de l'intégration avec du C. Mais pas avec du C++. State of WebAssembly https://blog.scottlogic.com/2022/06/20/state-of-wasm–2022.html On peut peut-être aussi rajouter l'utilisation de WebAssembly chez Figma https://neugierig.org/software/blog/2022/06/wasm-notes.html rust reste le langage de prédilection Python monte JavaScript est maintenant un langage viable Wasmtime est le runtime le plus populaire L'utilisation de WASM pour Serverless et la containérisation et en tant que hôte de plugin a beaucoup émergé Les api non browser sont ce dont a besoin web assembly En fait compilent pas JavaScript mais un moteur JavaScript et faire l'interprétation fonctionnalités très demandées : threads, exceptions, GC, type réflection etc Graal VM 22.2 https://medium.com/graalvm/graalvm–22–2-smaller-jdk-size-improved-memory-usage-better-library-support-and-more-cb34b5b68ec0 GraalVM JDK plus petit Plus petite conso mémoire lors de la création de native images Un travail de Quarkus, Micronaut et Spring Native pour ûblier des métadonnées partagées https://medium.com/graalvm/enhancing–3rd-party-library-support-in-graalvm-native-image-with-shared-metadata–9eeae1651da4 Possibilité de générer des heap dump dans des native images Différentes améliorations du compilateur Support de Apple Silicon Côté autres langages, GraalPython démarre plus vite et avec support étendu de librairie, et GraalJS avec une meilleurs interopérabilité Alex Blewitt un Java Champion est décédé prématurément https://www.infoq.com/news/2022/07/alex-blewitt/ notamment un contributeur à InfoQ Librairies Sortie de Micronaut 3.6 https://micronaut.io/2022/08/04/micronaut-framework–3–6–0-released/ Nouveau module Micronaut Test Resources avec une intégration TestContainers qui permet d'avoir des ressources de test externes, par exemple pour un Redis, un Elasticsearch ou autre Cédric Champeau qui a travaillé sur cette fonctionnalité a écrit un blog post complet sur le sujet https://melix.github.io/blog//2022/08/micronaut-test-resources.html Intégration avec OpenTelemetry (après Open Tracing et autre) Micronaut Data rajoute Hibernate Reactive comme intégration et plein d'autres mises à jour des différents modules existants Utiliser des serialiseurs. / deserialiseurs de messages Kafka dans votre application Quarkus https://quarkus.io/blog/kafka-serde/ explique quand on a besoin d'un serialisateur custom (hors des types fondamentaux) Explique que le support JSON existe par défaut Explique comment utiliser Avro mais avec un schéma registry Et la version full custom Akka change sa licence de ASL vers BSL (Business Source License) https://www.lightbend.com/blog/why-we-are-changing-the-license-for-akka comme MariaDB, Cockroach Labs, Sentry, Materialized BSL is source available et usage dev mais pas prod Après 3 ans, les commits en BSL se convertissent en ASL (donc pas les nouveaux commits) license commerciale disponible pour 2000$ par coeur due au fait qu'avec la maturiote de Akka les contributions ont diminué et le support est revenu a LightBend de plus en plus meme si des societes grosse utilisent Akka dans leur infra critique Gatling impacté Mécontentement de la communauté Akka et Scala, par exemple cet article d'Alexandru Nedelcu https://alexn.org/blog/2022/09/07/akka-is-moving-away-from-open-source Nous contacter Pour réagir à cet épisode, venez discuter sur le groupe Google https://groups.google.com/group/lescastcodeurs Contactez-nous via twitter https://twitter.com/lescastcodeurs Faire un crowdcast ou une crowdquestion Soutenez Les Cast Codeurs sur Patreon https://www.patreon.com/LesCastCodeurs Tous les épisodes et toutes les infos sur https://lescastcodeurs.com/

Remote Ruby
The brand new Hatchbox.io v2

Remote Ruby

Play Episode Listen Later Sep 9, 2022 49:58 Very Popular


[00:02:23] The guys discuss DHH and the release candidate of Turbo v7.2.0.[00:07:13] Andrew asks if we can do Postgres in the browser now, why do we need to build these complex forms and tables? Jason and Chris explain it to him.[00:12:51] The guys chat about customized license plates, car tags, and Jason owing Andrew $163. [00:15:37] The discussion turns to Hatchbox, Chris updated the DNS to point to the new version, Jason tells us about using it with Job Boardly, and they talk about using clusters. [00:19:21] Jason brings up something he did when he started a cluster and asks Chris if he did it right. [00:22:39] We find out Jason switched to a Digital Ocean Managed Database and what happened.[00:25:06] You can set up a Postgres server in Hatchbox and it will provision it for you. Jason wonders when you choose background job, does it provision Redis for you?[00:31:07] We hear about Jason setting up a space for ActiveStorage.[00:36:32] Chris goes back to talking about Hatchbox and switching to Caddy.  [00:40:30] Jason tells us he started using the Hatchbox API to add custom domains and Chris talks about other things he's done with Hatchbox and things he would like to do.[00:43:45] We hear a lesson Jason learned regarding ActiveStorage using Vips for image processing and an error he encountered. He tells us about an article he read to get the error to go away he had to do that for Heroku as well, and Chris shares his thoughts.Panelists:Jason CharnesChris OliverAndrew MasonSponsor:HoneybadgerLinks:Jason Charnes TwitterChris Oliver TwitterAndrew Mason TwitterLearn Postgres at the Playground (crunchy data)Job BoardlyDigital Ocean Managed DatabasesJetsCaddyRuby Radar NewsletterRuby Radar Twitter

Makers.dev
86 First paying customer

Makers.dev

Play Episode Listen Later Sep 8, 2022 67:51


Christian got married! Chris got his first paying customer for AcornChat.  00:00 Intro  01:24 First paying customer  07:32 Heroku is removing the free tier  10:43 Kaggle CTF competition  20:13 Taxes  24:36 Killing grass weeds  30:03 Next marketing thing for acornchat  39:48

Thinking Elixir Podcast
115: ElixirConf 2022 Recap

Thinking Elixir Podcast

Play Episode Listen Later Sep 6, 2022 38:42 Very Popular


ElixirConf US 2022 just finished! We cover the big announcements, talk highlights, and other relevant tech news. We discuss what some of these big announcements and projects represent and what they might mean for the Elixir community going forward. We talk about the Elixir 1.14 release, Livebook advances, Phoenix 1.7, machine learning progress, and the surprise announcement of Phoenix LiveView Native! Show Notes online - http://podcast.thinkingelixir.com/115 (http://podcast.thinkingelixir.com/115) Elixir Community News - https://elixir-lang.org/blog/2022/09/01/elixir-v1-14-0-released/ (https://elixir-lang.org/blog/2022/09/01/elixir-v1-14-0-released/) – Elixir v1.14 officially released - https://github.com/elixir-lang/elixir/blob/v1.14.0/CHANGELOG.md#changelog-for-elixir-v114 (https://github.com/elixir-lang/elixir/blob/v1.14.0/CHANGELOG.md#changelog-for-elixir-v114) – Elixir 1.14 changelog - https://github.com/elixir-lang/elixir/blob/v1.14.0/CHANGELOG.md#changelog-for-elixir-v114 (https://github.com/elixir-lang/elixir/blob/v1.14.0/CHANGELOG.md#changelog-for-elixir-v114) – Nerves v1.9.0 fixed Elixir 1.14 warnings - Phoenix 1.7 upcoming release discussed - Phoenix 1.7 generators will use Tailwind CSS - New phx.gen.auth --live option - https://github.com/liveviewnative/liveview-client-swiftui (https://github.com/liveviewnative/liveview-client-swiftui) – Phoenix LiveView Native was announced - https://github.com/liveviewnative/elixirconf_chat (https://github.com/liveviewnative/elixirconf_chat) – ElixirConf Chat project created using Phoenix LiveView Native - https://getfirefly.org (https://getfirefly.org) – Lumen was renamed to Firefly - https://twitter.com/HoldenOullette/status/1565486046237921280 (https://twitter.com/HoldenOullette/status/1565486046237921280) – Podium released an OWASP security training LiveBook for Elixir developers. - https://github.com/podium/elixir-secure-coding (https://github.com/podium/elixir-secure-coding) – Elixir Secure Coding Training (ESCT) - https://www.ectoinproduction.com (https://www.ectoinproduction.com) – Ecto In Production future home - https://github.com/liveshowy/webauthnlivecomponent (https://github.com/liveshowy/webauthn_live_component) – SmartLogic released a LiveComponent to support WebAuthn authentication for your LiveView app - https://github.com/liveshowy/webauthnlivecomponent_demo (https://github.com/liveshowy/webauthn_live_component_demo) – WebAuthn authentication demo page - https://github.com/kipcole9/tempo (https://github.com/kipcole9/tempo) – Kip Cole released a new kind of DateTime library called Tempo - https://kipcole9.github.io/tempo/2021-01-04-its-about-time/ (https://kipcole9.github.io/tempo/2021-01-04-its-about-time/) – Temp blog post explains more about it. - https://twitter.com/steveschoger/status/1562117153591107586 (https://twitter.com/steveschoger/status/1562117153591107586) – Heroicons v2.0 released. Used in TailwindUI templates. - https://twitter.com/louispilfold/status/1564247740879609860 (https://twitter.com/louispilfold/status/1564247740879609860) – Louie Pilford showed a screenshot of Gleam compiling Elixir's Plug - https://blog.heroku.com/next-chapter (https://blog.heroku.com/next-chapter) – Heroku, a popular PaaS made significant policy changes. Ending free tier and more. - https://spectrum.ieee.org/top-programming-languages-2022 (https://spectrum.ieee.org/top-programming-languages-2022) – IEEE Top Programming Languages 2022 - https://twitter.com/josevalim/status/1565408635961884673 (https://twitter.com/josevalim/status/1565408635961884673) – José Valim shared they are porting non-neural algorithms to Elixir/Nx which runs on both CPU/GPU. Shared impressive performance comparisons. - Chris Grainger gave a keynote about how Elixir is ready for real, production machine learning work. - https://www.lambdadays.org/lambdadays2022 (https://www.lambdadays.org/lambdadays2022) – Lambda Days conference. 5-6 June 2023 in Krakow, Poland Do you have some Elixir news to share? Tell us at @ThinkingElixir (https://twitter.com/ThinkingElixir) or email at show@thinkingelixir.com (mailto:show@thinkingelixir.com) Find us online - Message the show - @ThinkingElixir (https://twitter.com/ThinkingElixir) - Email the show - show@thinkingelixir.com (mailto:show@thinkingelixir.com) - Mark Ericksen - @brainlid (https://twitter.com/brainlid) - David Bernheisel - @bernheisel (https://twitter.com/bernheisel) - Cade Ward - @cadebward (https://twitter.com/cadebward)

Geeksblabla
#124 - Tech News & AMA #19

Geeksblabla

Play Episode Listen Later Sep 6, 2022 126:31


Tech News & AMA #19 with our community members Mehdi,Meriem, Youssouf, Yasser and Abderrahim. During this episode, we discuss Bunjs new javascript runtime, Heroku move to kill the free tier and much more. Guests Abderrahim soubai Mehdi Cheracher Yasser Tahiri Notes 0:00:00 - Introduction and welcoming 0:04:00 - Guest's learning during the last period. 0:19:29 - HeroKu free tier is dead. 0:28:00 - Is Github Copilot worth it? 0:35:30 - BunJs new javascript runtime. 0:46:00 QA ? 1:23:30 - Python updates. 1:31:40 - Favorite programming languages for our guests. 1:53:10 - Geeksblbla Picks. 1:48:30 - Conclusion Links Bun Js Marketing Yourself as a Developer Pydantic Ormdantic ms-kubernetes-tools The Log-Structured Merge-Tree (LSM-Tree) Nleveldb rocksdb pebble Prepared and Presented by Meriem Zaid Youssouf El Azizi

Python Bytes
#300 A Jupyter merge driver for git

Python Bytes

Play Episode Listen Later Sep 6, 2022 55:21


Watch the live stream: Watch on YouTube About the show Sponsored by Microsoft for Startups Founders Hub. Special guest: Seth Larson Brian #1: Test your packages and wheels I've been building some wheels the last couple of weeks with various tools: flit, flit-core, and flit build hatch, hatchling, and hatch build setuptools, build_meta, and python -m build There are a few projects I've used to make sure my projects are in good shape wheel-inspect - you can inspect within Python code through inspect_wheel() function that converts to json. Or use on the command line with wheel2json check-wheel-contents - a linter for wheels tox - easily test the building, installation, and running of a package locally I actually start here, then utilize the other two tools Should have been obvious, but it wasn't to me Projects saved on git (such as gitHub) don't keep wheels in git. (this was obvious) When installing from git using pip install git+https://path/to/git/repo.git Your local pip will run the packaging backend to build the wheel before installing. Yet another way to test packaging. Michael #2: The Jupyter+git problem is now solved Jupyter notebooks don't work with git by default (they inherently have meaningless conflicts). With nbdev2, the Jupyter+git problem has been totally solved. Uses a set of hooks which provide clean git diffs, solve most git conflicts automatically, and ensure that any remaining conflicts can be resolved entirely within the standard Jupyter notebook environment. The techniques used to make the merge driver work are quite fascinating Seth #3: Help us test system trust stores in Python Package aiming to replace certifi called “truststore”, use system trust stores for HTTPS instead of a static list of certificates. Problem truststore is solving usually manifests in corporate networks: “unable to get local issuer certificate”. Experimental support added to pip to prove the implementation Users can try out the functionality and report issues. Brian #4: Making plots in your terminal with plotext Bob Belderbos Tutorial on using plotext - that's one t in the middle With the rise of CLI usage, plots are a nice addition. Bob's plot is great, but check out the options in the plotext docs lots-o-plots streaming data images subplots so fun Michael #5: jinja2-fragments Carson from HTMX (see podcast and course) wrote about template fragments. My jinja_partials project sorta fulfills this, but not really. I had a nice discussion with Sergi Pons Freixes who uses jinja_partials about this. He created Jinja2 fragments Seth #6: SLSA 3 Generic Builder for GitHub Actions GA Supply chain Levels for Software Artifacts, or SLSA (“salsa”) Tools to attest to and verify “provenance” of artifacts, ie “where it came from” Prove cryptographically that artifacts are built from a specific GitHub repository, commit, tag. Another future defense against stolen PyPI credentials/accounts. Generic builder means you can sign anything, like wheels/sdists Extras Brian: Bring your pytest books to PyBay, if you want them signed. I'm only bringing a small amount. I'll be presenting "Sharing is Caring - pytest fixture edition” at 3:05 “Experts Panel on Testing in Python” at 7:00 And be a zombie on my 8 am flight back unless I can change my reservation. That's this weekend, Sat Sept 10, in SF Michael: Heroku announces plans to eliminate free plans Banned paywalls PyPI phisher identified: Actor Phishing PyPI Users Identified and Actors behind PyPI supply chain attack have been active since late 2021 Major Python CVE: CVE-2020-10735: Prevent DoS by large int[HTML_REMOVED]str conversions Seth: Pyxel, retro game engine for Python, v1.8.0 added experimental web support with WASM Joke: Dev just after work

ShopTalk » Podcast Feed
531: Mobile Database, GDPR Fun, and Heroku Shuts Down Free Plan

ShopTalk » Podcast Feed

Play Episode Listen Later Sep 5, 2022 55:15


What database should a mobile app use? Is there any help for GDPR processes? Is there a way to get developers to better match design? How to implement accessibility in a web app environment? Heroku shuts down their free plan, and pricing is hard.

Compilado do Código Fonte TV
Heroku será pago; TypeScript com rebuild mais rápido; Dell e NVIDIA investem em DPUs; LastPass tem código-fonte roubado; VS Code melhora merge; IA para entender e documentar COBOL [Compilado #70]

Compilado do Código Fonte TV

Play Episode Listen Later Sep 3, 2022 38:54


Nesse episódio trouxemos as notícias e novidades do mundo da programação que nos chamaram atenção dos dias 27/08 a 02/09! CallStack: iFood Tech Day - Rust Se você já é um desenvolvedor ou quer saber mais sobre Rust você não pode perder o iFood Tech Day, evento gratuito organizado pelo iFood que nesta primeira edição contará com a comunidade de Rust que está entrando com conteúdo/palestras. No dia 10 de setembro das 09:00 às 19:00 horas, presencial em Osasco/SP e online no YouTube. Inscreva-se e participe. Corra que as vagas presenciais são limitadas: https://codft.me/ifoodtechday0922 NVIDIA GTC A conferência de tecnologia que é referência em inovação e que agora terá também diversas sessões em português. O NVIDIA GTC será online e vai ser transmitido de 19 a 22 de setembro. As inscrições são gratuitas e já estão abertas: https://codft.me/nvidiagtc22 Você ainda pode concorrer a cupons para cursos no NVIDIA DLI! Acompanhe esse episódio do Compilado e descubra como participar. Breakpoint: Nessa semana o tema foi: "Caixinha de som do computador assombrada! (História Real)". Hosts: Somos Gabriel Fróes e Vanessa Weber, um casal de programadores que dá as caras desde 2016 no canal Código Fonte TV no YouTube. Links: Receba as Notícias do Compilado no Email: compilado.codigofonte.com.br Assista o Compilado no YouTube: codft.me/canalcompilado Esse é o momento ideal de pegar um café e se atualizar com notícias sobre programação que nos chamaram a atenção essa semana.

Compilado do Código Fonte TV
Heroku será pago; TypeScript com rebuild mais rápido; Dell e NVIDIA investem em DPUs; LastPass tem código-fonte roubado; VS Code melhora merge; IA para entender e documentar COBOL [Compilado #70]

Compilado do Código Fonte TV

Play Episode Listen Later Sep 3, 2022 38:54


Nesse episódio trouxemos as notícias e novidades do mundo da programação que nos chamaram atenção dos dias 27/08 a 02/09! CallStack: iFood Tech Day - Rust Se você já é um desenvolvedor ou quer saber mais sobre Rust você não pode perder o iFood Tech Day, evento gratuito organizado pelo iFood que nesta primeira edição contará com a comunidade de Rust que está entrando com conteúdo/palestras. No dia 10 de setembro das 09:00 às 19:00 horas, presencial em Osasco/SP e online no YouTube. Inscreva-se e participe. Corra que as vagas presenciais são limitadas: https://codft.me/ifoodtechday0922 NVIDIA GTC A conferência de tecnologia que é referência em inovação e que agora terá também diversas sessões em português. O NVIDIA GTC será online e vai ser transmitido de 19 a 22 de setembro. As inscrições são gratuitas e já estão abertas: https://codft.me/nvidiagtc22 Você ainda pode concorrer a cupons para cursos no NVIDIA DLI! Acompanhe esse episódio do Compilado e descubra como participar. Breakpoint: Nessa semana o tema foi: "Caixinha de som do computador assombrada! (História Real)". Hosts: Somos Gabriel Fróes e Vanessa Weber, um casal de programadores que dá as caras desde 2016 no canal Código Fonte TV no YouTube. Links: Receba as Notícias do Compilado no Email: compilado.codigofonte.com.br Assista o Compilado no YouTube: codft.me/canalcompilado Esse é o momento ideal de pegar um café e se atualizar com notícias sobre programação que nos chamaram a atenção essa semana.

Data Coffee
64 (S2E22). Прослушка, file system SQL, psycopg и другое

Data Coffee

Play Episode Listen Later Sep 3, 2022 56:03


Ведущие подкаста "Data Coffee" обсуждают новости и делятся своими мыслями! Shownotes: 1:40 ДР в подкасте 3:12 Stream deck 7:13 Дум на тракторе 8:22 Подслушивание через оптоволоконный кабель 13:21 SQL для файловой системы 16:29 Новость от слушателя 18:55 Тема от слушателя, галера или in-house 33:09 Дальний космос в колбасе 35:10 TikTok, дипфейки и брюзжание 37:57 20 лет Shazam 40:25 Про яндекс, поиск и обмен сервисами 44:59 Diablo 1 в браузере 46:02 Немного про GeForce Now 48:45 MacPass 50:15 DbGate 51:59 Heroku убирает бесплатные тарифы 52:55 Когда забанили в гугле Обложка - Joaquim de Mello (book author), Public domain, via Wikimedia Commons Сайт: https://datacoffee.link, канал в Telegram: https://t.me/datacoffee, профиль в Twitter: https://twitter.com/_DataCoffee_ Чат подкаста, где можно предложить темы для будущих выпусков, а также обсудить эпизоды: https://t.me/datacoffee_chat

Remote Ruby
Benedikt Deicke on Ember.js, Database Optimizations, and more

Remote Ruby

Play Episode Listen Later Sep 2, 2022 35:59 Very Popular


[00:01:51] Jason and Chris discuss the launching of Hatchbox v2. [00:05:54] Benedikt tells us about himself and what he does.[00:06:55] We learn when Benedikt started using Ember, how long he's been building Userlist, and if he had experience working in Rails API mode with Ember.[00:09:54] Benedikt explains what the process of scaffolding looks like and if ever has to manage and make things happen in sync when he makes a change that affects both sides.[00:11:18] Jason explains what Ember does and we find out if it's in that same vein as React, Vue, and Angular.[00:14:28] We hear what the process is like keeping up to date with things like new Ember releases and new Rails releases.[00:16:40] Benedikt tells us how many developers he has at Userlist, if he's doing more of the Rails side of things, and what it's been like going from a technical Co-founder and the only one developing the application and bringing someone else in to work with it.[00:18:27] Since Benedikt launched Userlist in 2019, he tells us some challenges he faces with building and growing it, as well as any challenges with technical stuff he wanted to build but couldn't to focus on marketing and getting new customers.[00:21:10] Chris asks Benedikt if he picked up an editor that was pre-made, like an Ember plug-in, just to use the first version. He tells us some challenges he ran into as he was building it. [00:24:02] We find out some multiple solutions Benedikt and his team came up with when they tried to update one column in a database that stopped everything. [00:25:30] Jason wonders if Benedikt is doing databases at Heroku or if he's explored another database host.[00:26:46] We hear some other database performance things Benedikt's had to implement solutions for.[00:28:03] Chris wonders how comfortable Benedikt was with SQL before he started, if he had to learn a whole bunch of things on the fly, realizing it may be a challenge, and he explains how he's implementing things with a lot of Arel.[00:30:06] Benedikt talks about what his day looks like for him, how he balances his week to do everything as a Co-Founder, and if he gets to code a decent amount.[00:32:57] Andrew heard Benedikt is really good at Postgres Performance and he wonders if there's any tips he can share for starting out. He tells us about his greatest tool which is pgMustard.[00:35:21] Find out where you can follow Benedikt and Userlist online.Panelists:Jason CharnesChris OliverAndrew MasonGuest:Benedikt DeickeSponsor:HoneybadgerLinks:Jason Charnes TwitterChris Oliver TwitterAndrew Mason TwitterBenedikt Deicke TwitterBenedikt Deicke WebsiteUserlistSlow & Steady PodcastEmber.jsHatchboxpgMustardRuby Radar NewsletterRuby Radar TwitterRuby for All Podcast

Software Defined Talk
Episode 375: For the Birds

Software Defined Talk

Play Episode Listen Later Sep 2, 2022 71:52


This week we discuss VMware Explore, Snap's move to multi-cloud and the Galaxy Brain take on thought leadership. Plus, Matt Ray's latest Raspberry Pi project is for the birds…? Runner-up Titles Where's my admin? All my children qualify as adults Start by eating their food Put two letters in front of it Where's the grocery store I got that everything bagel spice Is it OK to hang-up on your kids? In the heat of the moment, you can't set policy. The runbook's already written. Spagetti Bowl Tanzu the Shih Tzu A FinOps Type of Motion The opposite of the Sales Kickoff, the Savings Kickoff Growth is best done in the shadows. Wrapping bullshit with bullshit Nopehouse, home of the fast follower The fast followers are just in front of the also-rans Thought-leadership suicide mission Rundown VMware Explore (https://www.vmware.com/explore/us.html) How Snap rebuilt the infrastructure that now supports 347M users (https://www.protocol.com/enterprise/snap-microservices-aws-google-cloud) Screaming in the Cloud with Martin Casado (https://www.lastweekinaws.com/podcast/screaming-in-the-cloud/the-new-cloud-war-with-martin-casado/) Give finops a say over cloud architecture decisions (https://www.infoworld.com/article/3671148/give-finops-a-say-over-cloud-architecture-decisions.html) Business Dudes Need to Stop Talking Like This (https://newsletters.theatlantic.com/galaxy-brain/630ec150bcbd490021b17eab/business-dudes-need-to-stop-talking-like-this/) Relevant to your Interests Amazon tries a new way to excite you about cybersecurity (it's called laughter) (https://www.zdnet.com/article/amazon-tries-a-new-way-to-excite-you-about-cybersecurity-its-called-laughter/) The golden noose around Apple's neck (https://spectatorworld.com/topic/the-golden-noose-around-apples-neck/) Campaign pushes Cloudflare to drop trans hate site (https://www.axios.com/newsletters/axios-login-85e45e2f-8629-43d3-be69-45072a3631f5.html?chunk=0&utm_term=emshare#story0) Mudge at Twitter (https://twitter.com/igb/status/1562427951882199044) Bloomberg takes cut and paste seriously (https://twitter.com/MidwestHedgie/status/1562450905907478531) Notice of Recent Security Incident - The LastPass Blog (https://blog.lastpass.com/2022/08/notice-of-recent-security-incident/) World's Most Popular Password Manager Says It Was Hacked (https://www.bloomberg.com/news/articles/2022-08-25/the-world-s-most-popular-password-manager-says-it-was-hacked) LastPass Says No Passwords Stolen in Data Breach (https://www.cnet.com/tech/services-and-software/lastpass-says-no-passwords-stolen-in-data-breach/) AWS and Kubecost collaborate to deliver cost monitoring for EKS customers | Amazon Web Services (https://aws.amazon.com/blogs/containers/aws-and-kubecost-collaborate-to-deliver-cost-monitoring-for-eks-customers/) Pandas Pivot Table Explained (https://pbpython.com/pandas-pivot-table-explained.html) Charted: Big Tech's bigness (https://www.axios.com/newsletters/axios-login-3db6f78d-4da1-494b-a5d4-04c8984ce0e5.html?chunk=1&utm_term=emshare#story1) UK's Micro Focus shares nearly double after Canada's OpenText agrees $6 bln takeover (https://www.reuters.com/markets/deals/canadas-opentext-buy-software-firm-micro-focus-6-bln-deal-2022-08-25/) Teradata takes on Snowflake and Databricks with cloud-native platform (https://venturebeat.com/data-infrastructure/teradata-makes-database-analytics-cloud-native/) The State of the Mainframe Market - Summer 2022 (https://futurumresearch.com/market-insight-reports/the-state-of-the-mainframe-market-summer-2022/) City2Surf face recognition raises concerns (https://ia.acs.org.au/content/ia/article/2022/city2surf-face-recognition-raises-concerns.html) IBM Watson Health layoffs disguised as staff 'redeployment' (https://www.theregister.com/2022/08/29/ibm_allegedly_hid_watson_health/) David Young on LinkedIn: The metaverse economy is set to boom... gambling will be a significant (https://www.linkedin.com/posts/david-young-b5276523_metaverse-5g-localisation-activity-6966387069338218496-4x5F?utm_source=share&utm_medium=member_desktop) OCI History (https://twitter.com/solomonstre/status/1564499775415676928) VMware CEO bats away Broadcom concerns as 'next transition' (https://www.theregister.com/2022/08/30/vmware_broadcom_/) Heroku to delete inactive accounts, shut down free tier (https://www.theregister.com/2022/08/25/heroku_delete_inactive_free_tier/) Cloudflare Is One of the Companies That Quietly Powers the Internet. Researchers Say It's a Haven for Misinformation (https://time.com/6208828/cloudflare-misinformation-internet-research/) Nonsense Sounds right (https://twitter.com/6thgrade4ever/status/1433519577892327424?s=20&t=o8cx7C7pcCkVR4cTcQbv4g) When the development team meet their first Scrum Master (https://twitter.com/onejasonknight/status/1564287640366628866?s=20&t=y3AIxGPb8kge28aICQ6dFQ) Chart of the year nominee (https://twitter.com/jpwarren/status/1564109454009716736/photo/1) Conferences DevOps Talks Sydney (https://devops.talksplus.com/sydney/devops.html), Sydney, September 6-7, 2022 Sydney Cloud FinOps Meetup (https://events.finops.org/events/details/finops-sydney-cloud-finops-presents-sydney-cloud-finops-meetup/), online, Oct 13, 2022 Matt's presenting Kube (https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/)C (https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/)o (https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/)n North America (https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/), Detroit, Oct 24 – 28, 2022 SpringOne Platform (https://springone.io/?utm_source=cote&utm_medium=podcast&utm_content=sdt), SF, December 6–8, 2022 THAT Conference Texas Call For Counselors (https://that.us/call-for-counselors/tx/2023/) Jan 16-19, 2023 Listener Feedback Enlightning (https://tanzu.vmware.com/developer/tv/enlightning/) from Whitney SDT news & hype Join us in Slack (http://www.softwaredefinedtalk.com/slack). Get a SDT Sticker! Send your postal address to stickers@softwaredefinedtalk.com (mailto:stickers@softwaredefinedtalk.com) and we will send you free laptop stickers! Follow us on Twitch (https://www.twitch.tv/sdtpodcast), Twitter (https://twitter.com/softwaredeftalk), Instagram (https://www.instagram.com/softwaredefinedtalk/), LinkedIn (https://www.linkedin.com/company/software-defined-talk/) and YouTube (https://www.youtube.com/channel/UCi3OJPV6h9tp-hbsGBLGsDQ/featured). Use the code SDT to get $20 off Coté's book, (https://leanpub.com/digitalwtf/c/sdt) Digital WTF (https://leanpub.com/digitalwtf/c/sdt), so $5 total. Become a sponsor of Software Defined Talk (https://www.softwaredefinedtalk.com/ads)! Recommendations Brandon: Black Bird (https://www.rottentomatoes.com/tv/black_bird/s01) Matt: BirdNetPi (https://birdnetpi.com/) Festival of Feet Half-Marathon (https://www.westiesjoggers.com/the-georges-river-festival-of-the-feet/) Coté: Spigen ArcDock 120W [GaN III] 4-Port USB C Charging Stantion USB-C PD/USB-A Hub with Spigen USB 4 Cable for Thunderbolt 4 Cable 100W Charging 40Gbps Data Transfer for MacBook Pro Air iPad USB-C Laptop (https://amzn.to/3RqRl7M). C7/C8 coupler cables Photo Credits CoverArt (https://unsplash.com/photos/Ts3yX7wDthw) Banner (https://unsplash.com/photos/hXttDVCwyRA)

Changelog Master Feed
Qalculate is awesome, Restic adds compression, CS teachers coping with Copilot & Heroku's next non-free chapter (The Changelog)

Changelog Master Feed

Play Episode Listen Later Aug 29, 2022 8:50 Transcription Available


Qalculate has a command-line interface, Michael Eischer adds compression to Restic, Emery Berger warns his fellow CS professors about Copilot, and Heroku GM Bob Wise details Heroku's next chapter (which excludes free accounts).

Zemach FM
Episode 93: This Week In Tech (August 29, 2022)

Zemach FM

Play Episode Listen Later Aug 29, 2022 29:25


On the latest tech this week we are taking a look at some of the events that took place in the tech world recently. Starting with what to expect at Apple’s “Far Out” event, T-Mobile and Starlink formed an agreement to let users use Starlink satellites for cellular services in remote areas and much more. Episode timeline 04:22 What to expect from Apple’s September 7 event 09:12 New York State Senate would require new cars have to speed-limiting tech 10:52 Meta’sVP of horizon leaving the company 12:37 A new start-up claims to remove non-American accents on a live call 16:05 Mark Zuckerberg and Sheryl Sandberg will not be deposed regarding the Cambridge Analytica incident 17:40 T-Mobile and Starlink formed an agreement to let users use Starlink satellites for cellular services in remote areas 21:40 Twitter shopping features could lead to ‘individual or societal harm, according to a leaked memo 23:28 The top password manager claims to have been hacked 26:50 Heroku to stop providing free tiers Contact the hosts Henok Tsegaye Twitter Instagram LinkedIn Abdulhadmid Oumer Twitter Instagram linkedIn Follow Zemach FM and give us comment

The Changelog
Qalculate is awesome, Restic adds compression, CS teachers coping with Copilot & Heroku's next non-free chapter

The Changelog

Play Episode Listen Later Aug 29, 2022 8:50 Transcription Available


Qalculate has a command-line interface, Alexander Neumann adds compression to Restic, Emery Berger warns his fellow CS professors about Copilot, and Heroku GM Bob Wise details Heroku's next chapter (which excludes free accounts).

Hacker News TLDR
[#111] Google Timer, gone and back again

Hacker News TLDR

Play Episode Listen Later Aug 27, 2022 38:19


Links covered: Reflections on my time in Y Combinator Removal of Heroku free product plans Google Timer is back Design the next iPhone Shazam turns 20 Fakery: An odd discovery on Spotify Fakery: Fake IMDB credits Fakery: More content by people, for people in Search Fakery: The coming tsunami of fakery

ITmedia NEWS
PaaS「Heroku」が無料プラン廃止、11月から 非アクティブなアカウントとストレージも削除

ITmedia NEWS

Play Episode Listen Later Aug 26, 2022 0:33


PaaS「Heroku」が無料プラン廃止、11月から 非アクティブなアカウントとストレージも削除。 米Salesforceの子会社である米Herokuは8月25日(現地時間)、同社が提供するPaaS「Heroku」の無料プランを廃止すると発表した。同社は「無料プランを利用しようとする詐欺や不正使用などの監視に多くの労力を費やしている」とし、今後はサービスの運営上不可欠なミッションクリティカルな機能の提供にリソースを集中させると説明している。

Screaming in the Cloud
How to Leverage AWS for Web Developers with Adam Elmore

Screaming in the Cloud

Play Episode Listen Later Aug 23, 2022 34:24


About AdamAdam is an independent cloud consultant that helps startups build products on AWS. He's also the host of AWS FM, a podcast with guests from around the AWS community, and an AWS DevTools Hero.Adam is passionate about open source and has made a handful of contributions to the AWS CDK over the years. In 2020 he created Ness, an open source CLI tool for deploying web sites and apps to AWS.Previously, Adam co-founded StatMuse—a Disney backed startup building technology that answers sports questions—and served as CTO for five years. He lives in Nixa, Missouri, with his wife and two children.Links Referenced: 17 Ways to Run Containers On AWS: https://www.lastweekinaws.com/blog/the-17-ways-to-run-containers-on-aws/ Twitter: https://twitter.com/aeduhm Twitch: https://www.twitch.tv/adamelmore TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. Every once in a while, I encounter someone in the wild that… well, I'll just be direct, makes me feel a little bit uneasy, almost like someone's walking over my grave. And I think I've finally figured out elements of what that is. It feels sometimes like I run into people—ideally not while driving—who are trying to occupy sort of the same space in the universe, and I never quite know how to react to that.Today's guest is just one such person. Adam Elmore is an independent AWS consultant, has been all over the Twitters for a while, recently started live streaming basically his every waking moment because he is just that interesting. Adam, thank you for suffering my slings and arrows—Adam: [laugh].Corey: —and agreeing to chat with me today.Adam: I would say first of all, you don't need to be worried about anyone walking over your grave. [laugh]. That was very flattering.Corey: No, honestly, I have big enterprise companies looking to put me in my grave, but that's a separate threat model. We're good on that, for now.Adam: [laugh]. I got to set myself up here to—I'm just going to laugh a lot, and your editor or somebody's going to have to deal with that. And maybe the audience will see—[laugh].Corey: Hey, I prefer that as opposed to talking to people who have absolutely no sense of humor of which they are aware. Awesome, I have a list of companies that they should apply for immediately. So, when I say that we're trying to occupy elements of the same space in the universe, let me talk a little bit about what I mean by that. You are independent as a consultant, which is how I started this whole nonsense, and then I started gathering a company around me almost accidentally. You are an AWS Dev Tools Hero, whereas I am an AWS community villain, which is kind of a polar opposite slash anti-hero approach, and it's self-granted in my case. How did you stumble into the universe of AWS? You just realized one day you were too happy and what can you do to make yourself miserable, and this was the answer, or what?Adam: Yeah, I guess. So. I mean, I've been a software developer for 15 years, like, my whole career, that's kind of what I've done. And at some point, I started a startup called StatMuse. And I was able, as sort of a co-founder there, with venture backing, like, I was able to just kind of play with the cloud.And we deployed everything on AWS, so that was—like, I was there five years; it was sort of five years of running this, I would call it like a Digital Media Studio. Like, we built technology, but we did lots of experiments, so it felt like playing on AWS. Because we built kind of weird one-offs, these digital experiences for various organizations. The Hall of Fame was one of them. We did, like, a, like, a 3-D Talking bust of John Madden, so it was like all kinds of weird technology involved.But that was sort of five years of, I guess, spending venture money [laugh] to play on AWS. And some of that was Google money; I guess I never thought about that, but Google was an investor in StatMuse. [laugh]. Yeah, so we sort of like—I ran that for five years and was able to learn just a lot of AWS stuff that really excited me. I guess, coming from normal web development stuff, it was exciting just how much leverage you have with AWS, so I sort of dove in pretty hard. And then yeah, when I left StatMuse in 2019 I've just been, I guess, going even harder into that direction. I just really enjoy it.Corey: My first real exposure to AWS was at a company where the CTO was a, I guess we'll call him an extraordinarily early cloud evangelist. I was there as a contractor, and he was super excited and would tweet nonsensical things like, “I'm never going to rack a server ever again.” And I was a grumpy sysadmin type; I came from the ops world where anything that is new shouldn't be treated with disdain and suspicion because once you've been a sysadmin for 20 minutes, you've been there long enough to see today's shiny new shit become tomorrow's legacy garbage that you're stuck supporting. So, “Oh, great. What now?”I was very down on Cloud in those days and I encountered it with increasing frequency as I stumbled my way through my career. And at the end of 2016, I wound up deciding to go out independent and fix… well, what problems am I good at fixing that I can articulate in a sentence, and well, I'd gotten surprised by AWS bills from time to time—fortunately with someone else's money; the best kind of mistake to make—and well I know a few things. Let's get really into it. In time, I came to learn that cost and architecture the same thing in cloud, and now I don't know how the hell to describe myself. Other people love to describe me, usually with varying forms of profanity, but here we are. It really turns into the idea of forging something of your own path. And you've absolutely been doing that for at least the last three years as you become someone who's increasingly well known and simultaneously harder to describe.Adam: Yeah, I would say if you figure it out, if you know how to describe me, I would love to know because just coming up with the title—for this episode you needed, like, my title, I don't know what my title is. I'm also—like, we talked about independent, so nobody sort of gives me a title. I would love to just receive one if you think of one, [laugh] if anyone listening thinks of one… it's increasingly hard to, sort of like, even decide what I care most about. I know I need to, like, probably niche down, I feel like you've kind of niched into the billing stuff. I can't just be like, “I'm an AWS guy,” because AWS is so big. But yeah, I have no idea.Corey: Anyone who claims, “Oh, I'm an expert in AWS,” is lying or trying to sell something.Adam: [laugh]. Exactly.Corey: I love that. It's, “Really? I have some questions to establish that for you.” As far as naming what it is, you do, first piece of advice, never ever, ever, ever listen to someone who works at AWS; those people are awful at naming things, as evidenced by basically every service they've ever launched. But you are actually fairly close to being an AWS expert. You did a six-week speed-run through every certification that they offer and that is nothing short of astonishing. How'd it come about?Adam: It's a unique intersection of skills that I think I have. And I'm not very self-aware, I don't know all my strengths and weaknesses and I struggle to sort of nail those down, but I think one of my strengths is just ability to, like, consume information, I guess at a high volume. So, I'm like an auditory learner; I can listen to content really fast and sort of retain enough. And then I think the other skill I have is just I'm good at tests. I've always said that, like, going back to school, like, high school, I always felt like I was really good at multiple-choice tests. I don't know if that's a skill or some kind of innate talent.But I think those two things combined, and then, like, eight years of building on AWS, and that sort of frames how I was able to take all that on. And I don't know that I really set out thinking I will do it in six weeks. I took the first few and then did them pretty fast and thought, “I wonder how quickly I could do all of them.” And I just kind of at that point, it became this sort of goal. I have to take on certain challenges occasionally that just sound fun for no reason other than they sound fun and that was kind of the thing for those six weeks. [laugh].Corey: I have two certifications: Cloud Practitioner and the SysOps Administrator Associate. Those were interesting.Adam: You took the new one, right? The new SysOps with the labs and stuff I'd love to hear about that.Corey: I did, back when it was in beta. That was a really interesting experience and I'll definitely get to that, but I wound up, for example, getting a question wrong in the Cloud Practitioner exam four years ago or so, when it was, “How long does it take to restore an RDS instance from backup?” And I gave the honest answer instead of the by-the-book, correct answer. That's part of the problem is that I've been doing this stuff too long and I know how these things break and what the real world looks like. Certifications are also very much a snapshot at a point in time.Because I write the Last Week in AWS newsletter, I'm generally up-to-the-minute on what has changed, and things that were not possible yesterday, suddenly are possible today, so I need to know when was this certification launched. Oh, it was in early 2021. Yeah, I needed to be a lot more specific; which week? And then people look at me very strangely and here we are.The Systems Administrator Certification was interesting because this is the first one, to my knowledge, where they started doing a live lab as a—Adam: Yeah.Corey: Component of this. And I don't think it's a breach of the NDA to point out that one of the exams was, “Great. Configure CloudWatch out of the box to do this thing that it's supposed to do out of the box.” And I've got to say that making the service do what it's supposed to do with no caveats is probably the sickest shade I've ever seen anyone throw at AWS, like, configuring the service is so bad that it is going to be our test to prove you know what you're doing. That is amazing.Adam: [laugh]. Yeah, I don't have any shade through I'm not as good with the, like, ability to come off, like, witty and kind while still criticizing things. So, I generally just try not to because I'm bad at it. [laugh].Corey: It's why I generally advise people don't try, in seriousness. It's not that people can't be clever; it's that the failure mode of clever is ‘asshole' and I'm not a big fan of making people feel worse based upon the things that I say and do. It's occasionally I wind up getting yelled at by Amazonians saying that the people who built a service didn't feel great about something I said, and my instinctive immediate reaction is, “Oh, shit, that wasn't my intention. How did I screw this up?” Given a bit of time, I realized that well hang on a minute because I'm not—they're not my target audience. I'm trying to explain this to other customers.And, on some level, if you're going to charge tens of millions of dollars a month for a service or more, maybe make a better one, not for nothing. So, I see both sides of it. I'm not intentionally trying to cause pain, but I'm also not out here insulting people individually. Like, sometimes people make bad decisions, sometimes individually, sometimes in a group. And then we have a service name we have to live with, and all right, I guess I'm going to make fun of that forever. It's fun that keeps it engaging for me because otherwise, it's boring.Adam: No, I hear you. No, and somebody's got to do it. I'm glad you do it and do it so well because, I mean, you got to keep them honest. Like, that's the thing. Keep AWS in check.Corey: Something that I went through somewhat recently was a bit of an awakening. I have no problem revisiting old opinions and discovering that huh, I no longer agree with it; it's time to evolve that opinion. The CDK specifically was one of those where I looked at it and thought this thing looks a little hokey. So, I started using it in Python and sure enough, the experience was garbage. So cool, the CDK is a piece of crap. There we go. My job is easy.I was convinced to take a second look at it via TypeScript, a language I do not know and did not have any previous real experience with. So, I spent a few days just powering through it, and now I'm a convert. I think it's amazing. It is my default go-to for building AWS infrastructure. And all it took was a little bit of poking and prodding to get me to change my mind on that. You've taken it to another level and you started actively contributing to the AWS CDK. What was your journey with that, honestly, remarkable piece of software?Adam: Yeah, so I started contributing to CDK when I was actually doing a lot of Python development. So, I worked with a company that was doing—there was a Python shop. So actually, the first thing I contributed was a Python function construct, which is sort of the equivalent of the Node.js function construct, which like, you can just basically point at a TypeScript file and it transpiles it, bundles it, and does all that, right? So, it makes it easy to deploy TypeScript as a Lambda function.Well, I mean, it ends up being a JavaScript Lambda function, but anyway, that was the Python function construct. And then I sort of got really into it. So, I got pretty hooked on using the CDK in every place that I could. I'm a huge fan, and I do primarily write in TypeScript these days. I love being able to write TypeScript front-end and back, so built a lot of, like, Next.JS front-ends, and then I'm building back-ends with CDK TypeScript.Yeah, I've had, like, a lot of conversations about CDK. I think there's definitely a group that's sort of, against the CDK, if you're thinking in terms of, like, beginners. And I do see where, for people who aren't as familiar with AWS, or maybe this is their entry point into cloud development, it does a lot of things that maybe you're not aware of that, you know, you're now kind of responsible for. So, it's deploying—like, it makes it really easy to write, like, three lines of TypeScript that stand up an entire VPC with all this configuration and Managed NAT Gateways and [laugh] everything else. And you may not be aware of all the things you just stood up.So, CloudFormation maybe is a little more—sort of gives you that better visibility into what you're creating. So, I've definitely seen that pushback. But I think for people who really, like, have built a lot of applications on AWS, I think the CDK is just such a time-saver. I mean, I spend so much less time building the same things in the CDK versus CloudFormation. I'm a big fan.Corey: For me, I've learned enough about JavaScript to be dangerous and it seems like TypeScript is more or less trying to automate a bunch of people's jobs away, which is basically, from I can tell, their job is to go on the internet and complain about someone's JavaScript. So great, that that's really all it does is it complains, “Oh, this ambiguous. You should be more specific about it.” And great. Awesome. I still haven't gotten into scenarios where I've been caught out by typing issues, and very often I find that it just feels like sheer bloodymindedness, but I smile, nod, bend the knee and life goes on.Adam: [laugh]. When you've got a project that's, like, I don't know, a few months old—or better, a few years old—and you need to do, like, major refactoring, that's when TypeScript really saves you just a ton of time. Like, when you can make a change in a type or in actual implementation stuff and then see the ripple effects and then sort of go around the codebase and fix those things, it's just a lot easier than doing it in JavaScript and discovering stuff at runtime. So, I'm a big TypeScript fan. I don't know where it's all headed. I know there's people that are not fans of, like, transpiling your Lambda functions, for instance. Like, why not just ship good JavaScript? And I get that case, too. Yeah, but I've definitely—I felt the productivity boost, I guess—if that's the thing—from TypeScript.Corey: For me, I'm still at a point where I'm learning the edges of where things start and where they stop. But one of the big changes I made was that I finally, after 15 years, gave up my beloved Vim as my editor for this and started using VS Code. Because the reasons that I originally went with Vi were understandable when you realize what I was. I'm always going to be remoting into network gear or random—on maintained Unix boxes. Vi is going to be everywhere on everything and that's fine.Yeah, I don't do that anymore, and increasingly, I find that everything I'm writing is local. It is not something that is tied to a remote thing that I need to login and edit by hand. At that point, we are in disaster area. And suddenly it's nice. I mean things like tab completion, where it just winds up completing the rest of the variable name or, once you enable Copilot and absolutely not CodeWhisperer yet, it winds up you tab complete your entire application. Why not? It's just outsourcing it to Stack Overflow without that pesky copy and paste step.Adam: Yeah, I don't know how in the weeds you want to get on your p—I don't know, in terms of technical stuff, but Copilot both blows me away—there are days where it autocompletes something that I just, I can't fathom how—it pulled in not just, like, the patterns that it found, obviously, in training, but, like, the context in the file I'm working and sort of figured out what I was trying to do. Sometimes it blows me away. A lot of times, though, it frustrates me because of TypeScript. Like, I'm used to Typescript and types saving me from typing a lot. Like, I can tab-complete stuff because I have good types defined, right, or it's just inferred from the libraries I'm using.It's tough though when GitHub is fighting with TypeScript and VS Code. But it's funny that you came from Vim and you now live in VS Code. I really am trying to move from VS Code to, like, the Vim world, mostly because of Twitch streamers that blow my mind with what they can do in Vim [laugh] and how fast they can move. I do—every time I move my hand, like, over to the arrow keys, I feel a little sad and I wish I just did Vim.Corey: This episode is sponsored in part by our friends at Lambda Cloud. They offer GPU instances with pricing that's not only scads better than other cloud providers, but is also accessible and transparent. Also, check this out, they get a lot more granular in terms of what's available. AWS offers NVIDIA A100 GPUs on instances that only come in one size and cost $32/hour. Lambda offers instances that offer those GPUs as single card instances for $1.10/hour. That's 73% less per GPU. That doesn't require any long term commitments or predicting what your usage is gonna look like years down the road. So if you need GPUs, check out Lambda. In beta, they're offering 10TB of free storage and, this is key, data ingress and egress are both free. Check them out at lambdalabs.com/cloud. That's l-a-m-b-d-a-l-a-b-s.com/cloud.Corey: There are people who have just made it into an entire lifestyle, on some level. And I'm fair to middling; I've known people who are dark wizards at it. In practice, I found that my productivity was never constrained by how quickly I can type. It's one of those things where it's, I actually want to stop and have my brain catch up sometimes, believe it or not, for those who follow me on Twitter. It's the idea of wanting to make sure that I am able to intelligently and rationally wrap my head around what it is I'm doing.And okay, just type out a whole bunch of boilerplate is, like, the least valuable use of anything and that is where I find things like Copilot working super well, where I, if I'm doing CloudFormation, for example, the fact that it tab-completes all the necessary attributes and can go back and change them or whatnot, that's an enormous time saver. Same story with the CDK, although with some constructs, it doesn't quite understand which ones get certain values to it. And I really liked the idea behind it. I think this is in some ways, the future of IDEs, to a point.Adam: Oh, for sure. I think, like, the case, you call that with CloudFormation, you don't have really typeahead in VS Code, at least I'm not using anything. Maybe there are extensions that give you that in VS Code. But to have Copilot fill in required prompts on a CloudFormation template, that's a lifesaver. Because I just, every time I write CloudFormation, I've just got the docs up and I'm copying stuff I've done before or whatever; like, to save that time it's huge. But CodeWhisperer, not so much? Is it not, I guess, up to snuff? I haven't seen it or played with it at all.Corey: It's still very early days and it hasn't had exposure outside of Amazonian codebases to my understanding, so it's, like, “Learn to code like an Amazonian.” And you can fill in your own joke here on that one. I imagine it's like—isn't that—aren't they primarily a Java shop, for one? And all right. It turns out most of my code doesn't need to operate the way that there's does.Adam: I didn't know that they were training it just internally. Like, I'm assuming Copilot is trained on, like, Stack Overflow or something, right? Or just all of GitHub, I guess.Corey: And GitHub and a bunch of other things, and people are yelling at them for it, and I haven't been tracking that. But honestly, the CodeWhisperer announcement taught me things about Copilot, which is weird, which tells me that none of these companies are great at explaining this. Like I can just write a comment in this of, “Add an S3 bucket,” and then Copilot will tab-complete the entirety of adding an S3 bucket, usually even secure, which is awesome. They also fix the early Copilot teething problems of tab-completing people's AWS API credentials. You know, the—yeah, they've fixed a lot of that, thankfully.Adam: Yeah.Corey: But it's still one of those neat things that you can just basically start—it gets a little bit closer to describe what you want the application to do and then it'll automatically write it for you on the back-end. Sure, sometimes it makes naive decisions that do not bear out, but again, it's still early days. I'm optimistic.Adam: Yeah, that reminds me of, like, the, I mean, the serverless cloud, so serverless framework folks, like, what they're doing where they're sort of inferring your infrastructure based on you just write an app and it sort of creates the infrastructure as code for you, or just sort of infers it all from your code. So, if you start using a bucket, it'll create a bucket for that. That definitely seems to be a movement as well, where just do less as a developer [laugh] seems to be the theme.Corey: Yeah, just move up the stack. We see this time and time again. I mean, look at the—I use this analogy from time to time from the sysadmin world, but in the late-90s, if you wanted to build a web server, you needed a spare week and an intimate knowledge of GCC compiler flags. In time, it became oh, great, now it's rpm install, then yum install, then ensure present with something like Puppet, and then Docker has it, and now it's just a checkbox on the S3 page, and you're running a static site. Things don't get harder with time, and I don't think that as a developer, your time is best spent writing by hand the proper syntax for a for loop or whatnot.It's not the differentiated value. Talk to me instead about what you want that thing to do. That was my big problem with Lambda when it first came out and I spent two weeks writing my first Lambda function—because I'm bad at programming—where I had to learn the exact format of expected for input and output, and now any Lambda function I write takes me a couple of minutes to write because I'm also bad at programming and don't know what tests are.Adam: [laugh]. Tests are overrated, I don't spend a lot of time writing t—I mean, I do a lot of stuff alone and I do a lot of stuff for myself, so in those contexts, I'm not writing tests if I'm being honest. I stream now and everyone on the stream is constantly asking, “Where are the tests?” Like, there are no tests. I'm sorry. [laugh]. Was someone else's stream.Corey: Oh yeah, it used to be though, that you had to be a little sneakier to have other people do work for you. Copilot makes it easier and presumably CodeWhisperer will, too. Used to be that if AWS launched new service and I didn't know how to configure it, all I would do is restrict a role down to only being able to work with that service, attach that to a user and then just drop the credentials on Twitter or GitHub. And I waited 20 minutes and I came back and sure enough, someone configured it and was already up and mining Bitcoin. So, turn that off, take what they built, and off the production with it. Problem solved. Oh, and rotate those credentials, unless you enjoy pain. Problem solved. The end. And I don't know if it's a best practice, but it sure was effective.Adam: Yeah, that would do it. Well, they're just like scanners now, right, like they're just scanning GitHub public repos for any credentials that are leaked like that, and they're available within seconds. You can literally, like, push a public repo with credentials and it is being [laugh] used within minutes. It's nuts.Corey: GitHub has some automatic back channel thing—I believe; I haven't done an experiment lately, but I believe that AWS will intentionally shoot down the credential as soon as it gets reported, which is kind of amazing. I really should do some more experiments with it just to see how disastrous this can get.Adam: Yeah. No, I'd be curious. Please let me know. I guess you'll tweet about it so I'll see it.Corey: Can I borrow your account for a few minutes?Adam: Yeah. [laugh].Corey: Yeah, it's fun. Now, the secret to my 17 Ways to Run Containers On AWS is in almost every case, those containers can be crypto miners, so it's not just about having too many services do the same thing; it's the attack surface continues to grow and expand in the fullness of time. I'm not saying this is right or wrong; it is what it is, but it's also something that I think people have an understated appreciation for.Let's change topic a little bit. Something you've been doing lately and talking about is the idea of building a course on AWS. You're clearly capable of doing the engineering work. That's not in question. You've been a successful consultant for years, which tells me you also know how to deliver software that meets customer requirements, as opposed to, “Well, the spec was shitty, but I wrote it anyway,” because you don't last long as a consultant if you enjoy being able to afford to eat if that's the direction you go in. Now, you're drifting toward becoming a teacher. Tell me about that. First, what makes you think that's something you're good at?Adam: So, I don't know. I don't know that I'm good at it and I guess I'll find out. I've been streaming, like, on Twitch just my work days, and that's been early signs that I think I'm okay at it, at least. I think it's very different, obviously, like, a self-paced course are going to be very different from streaming for hours, so there's a lot more editing and thoughtfulness involved, but I do think, like, I've always wanted to teach. So, even before I got into technology—I was pretty late into technology; it was after high school. Like back in high school, I always thought I wanted to be a professor.I just enjoyed, I guess the idea of presenting ideas in ways that people understood. And I live in an area—so I live in the Ozarks, it's not a very tech literate area. It became, like, this thing where I felt like I could really explain technology to people who are non-technical. And that's not necessarily what my course—what I'm aiming to do. I'm trying to teach web developers how to leverage AWS, and then sort of get out of the maybe front-end only or maybe traditional web frameworks—like, they've only worked with stuff that they deploy to Heroku or whatever—trying to teach that crowd, how to leverage AWS and all these wonderful primitives that we have.So, that's not exactly the same thing, but that's sort of like, I feel like I do have the ability to translate technology to non-technical folks. And then I guess, like, for me, at this stage of my career, you know, I've done a lot of work for a company, for startups, for individual clients, and it feels very, like—I just always feel like I'm going in a hole. Like, I feel like, I'm doing this little thing and I'm serving this one customer, but the idea of being able to, I guess, serve more people and sort of spread my reach, the idea of creating something that I can share with a lot of developers who would maybe benefit from it, it just feels better, I guess. [laugh]. I don't know exactly all the reasons why that feels better, but like, at the end of the day, my consulting kind of feels like this thing I do because I just need money.And now that I need money less and less, I just feel like I'd rather do stuff that I actually am excited about. I'm actually really excited about the outcomes for creating a course where, you know, I think I can maybe—my style of teaching or something could resonate with some group of people. Yeah, so that's it. It's AWS for web devs. The thought is that I'm going to create courses after this. Like, I hope to move into more education, less consulting. That's where I'm at.Corey: I would say you're probably selling yourself fairly short. I've seen a lot of the content you've put out over the years and I learned a lot from it every time. I think that there are some folks who put courses out where, one, they don't have the baseline knowledge around what it is that they're teaching, it just feels like a grift, and another failure mode is that people know how to do the thing, but they have no idea how to teach it to someone who isn't them. And there's nothing inherently wrong with not knowing how to teach; it is its own distinct skill. The problem is when you don't recognize that about yourself and in turn, wind up having some somewhat significant challenges.Adam: Yeah. No, I know that one of the struggles is, I work with pretty obscure technologies on AWS. Not obscure, but like, I have a very specific way I build APIs on AWS and I don't know that's generally, if you're taking a bunch of web developers and trying to move them into AWS is probably not the stack that I use. So, that is part of it, but that's also kind of to my benefit, I guess. It works for me a little bit in that I'm less familiar with maybe the more beginner-friendly way to enter into AWS.It's been years, so I think I can kind of come at it a little fresh and that'll help me produce a course that maybe meets them where they're at better. Yeah, the grifting thing, I'm definitely sensitive to just this idea of putting out a course. It was hard for me to really go out there and say I was making a course, even on Twitter, because I just feel like there's, like, some stereotype—I don't know, there's an association with that, for me at least, for my perception of course creation. But I know that there are people who've done it right and do it for the right reasons. And I think to the extent that I could hit that, you know, both those things, do it right and do it for the right reasons, then it's exciting to me. And if I can't, and it turned out not good at teaching, then I'll move on and do more consulting, I guess, [laugh] or streaming on Twitch.Corey: You are very clearly self-aware enough that if you put something out and it isn't effective, I have zero doubt that you won't just stop selling it, you'll take it down and reach out to people. Because you, more so than most, seem very cognizant of the fact that a poor experience learning something does not in most people's cases, translate to, “Oh, my teacher is shitty.” Instead, it's, “Oh, I'm bad at this and I'm not smart enough to figure it out.” That's still the problem I run into with bad developer experience on a bunch of things that get launched. If I have a bad time, I assume it's, “Oh, I'm stupid. I wish someone had told me.”And first, they did, secondly, it's the sense that no, it's just not being very clearly explained and the folks who wrote the documentation or talking about it are too close to what they've built to understand what it's like to look at this thing from fresh eyes. They're doing a poor job of setting the stage to explain the value it brings and in what scenario, you should be using this.Adam: It's a long process. I want to launch the course in the fall, but in the process of building out the course, I'm really going to be doing workshops and individual—like, I just have a lot of friends that are web developers and I'm going to be kind of getting on with them and teaching them this material and just trying to see what resonates. I'm going to a lot of trouble, I guess, to make sure I'm not just putting out a thing just to say I made a course. Like, I don't actually want to say I made a course, so if I'm going to do it, it's like most things I do I really kind of throw myself into. And I know if I spend enough energy and effort, I think I can make something that at least helps some people. I guess we'll see.Corey: I look forward to it. Any idea as far as rough timeline goes?Adam: Yeah, I hope to launch in the fall. But if it takes longer, I don't know. I've heard people say, to do a course right, you should spend a year on it. And maybe that's what I do.Corey: No, I love that answer. It's great. You're just saying I want to launch in the fall, which is sufficiently vague, and if that winds up not being vague enough, you could always qualify with, “Well, I didn't say what year.”Adam: [laugh].Corey: So, great you know, it's always going to be the fall somewhere.Adam: [laugh]. I just know, like, when someone says you should spend a year I just do things very hard. Like I really, like, throw a lot of time and obsess, like, I'm very obsessive. And when I do something, it's hard for me imagine doing any one thing for a year because I burn myself out. Like, I obsess very hard for usually, like, three months, it's usually, like, a quarter, and then I fall off the face of the earth for three months and I basically mope around the house and I'm just too tired to do anything else. So, I think right now I'm streaming and that's kind of been my obsession. I'm three weeks in so we got a few more months and then we'll see, [laugh] we'll see how I maintain it.Corey: Well, I look forward to seeing how it comes out. You'll have to come back and let us know when it's ready for launch.Adam: Yeah, that sounds great.Corey: I really want to thank you for being so generous with your time and taking me through what you're up to. If people want to learn more, what's the best place for them to find you?Adam: Yeah, I think Twitter. I mean, I mostly hang out on Twitter, and these days Twitch. So, Twitter my handle—I guess you'll put it, like, in the thing description or something. It's like the phonetic—Corey: Oh, we will absolutely toss it into the show notes, where useful content goes to linger.Adam: [laugh]. It's like A-E-D-U-H-M. It's like a—it's the phonetic way of saying Adam, I guess. And then on Twitch, I'm adamelmore. So, those are the two places I spend most my time.Corey: And off to the show notes it goes. Thank you so much for being so generous with your time. I really appreciate it, Adam.Adam: Thank you so much for having me, Corey. I really appreciate it.Corey: Adam Elmore, independent AWS consultant. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice along with an insulting comment that attempts to teach us exactly what we got wrong, but fails utterly because you're terrible at teaching things.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

Datacast
Episode 98: Building Developer Tools, Managing Platform Products, Fostering Diversity, and Enabling Real-Time Data Applications with DeVaris Brown

Datacast

Play Episode Listen Later Aug 17, 2022 97:11


Show Notes(01:43) DeVaris reflected on his upbringing on the south side of Chicago and college experience at UIUC, studying Mathematics and Computer Science in the early 2000s.(06:46) DeVaris shared his journey of learning how to program, make computers, and dive into the Internet.(09:35) DeVaris recalled valuable lessons from interning at Intel and Cisco Systems.(15:49) DeVaris shared his proudest accomplishments during his five years at Microsoft — first as a system engineer and then as an academic developer evangelist.(22:06) DeVaris recalled his experience working in the gaming and music space as the Chief Developer Evangelist at Marmalade and the Chief Product Officer at Klick Push, respectively.(27:49) DeVaris provided his perspective on the startup acquisition process.(29:13) DeVaris unpacked his two years as a platform product manager at Zendesk, where he drove the adoption of the Zendesk Developer Platform for developers to create unique customer experiences.(35:43) DeVaris revealed the challenges of building a technical community, given his experience at Zendesk.(38:25) DeVaris recalled his time working for a year as the Lead Product Manager at VSCO — a startup that builds digital tools for the modern creative.(45:12) DeVaris went over the challenges of building software for brand ambassadors and children's playtime, given his time as the Head of Product Management at Slyce.io and the CTO at Super Heroic.(49:39) DeVaris reflected on his desire to scratch his entrepreneurial itch.(52:00) DeVaris gave advice for early-career technologists on evaluating startup opportunities.(55:51) DeVaris unpacked the product challenges he encountered while building tools for developers as the Director of Product Management at Heroku.(58:57) DeVaris touched on his one year as the first platform engineering PM hire at Twitter.(01:02:18) DeVaris shared the founding story of Meroxa.(01:04:28) DeVaris dissected how Meroxa's platform architecture is designed at a high level — including a change data capture service, schema registry, event streaming service, API proxy, and incident automation framework.(01:06:06) DeVaris explained the technical challenges associated with creating connections between data sources and destinations in real time.(01:08:37) DeVaris zoomed into Conduit — Meroxa's open-source, single-binary data integration tool written in Golang that provides developer-friendly streaming data orchestration.(01:12:32) DeVaris highlighted a few customer use cases of Meroxa.(01:16:16) DeVaris shared valuable hiring lessons to attract the right people who are excited about Meroxa's mission and fit with Meroxa's cultural values.(01:18:37) DeVaris shared challenges to finding the early design partners & lighthouse customers for Meroxa.(01:20:24) DeVaris gave advice to founders seeking the right investors for their startups.(01:22:58) DeVaris gave advice to smart, driven operators looking to explore angel investing.(01:25:17) DeVaris discussed the remaining barriers that prevent minorities from pursuing a technology career.(01:30:42) DeVaris imparted lessons from photography and DJ that benefited his career in product.(01:32:26) Closing segment.DeVaris' Contact InfoLinkedInTwitterWebsiteGitHubMeroxa's ResourcesWebsite | LinkedIn | Twitter | YouTubeCareers | Medium BlogDocumentationConduit (GitHub | Discord | Twitter | Docs)Mentioned ContentArticles“Hello World, Meroxa Style” (April 2021)“Streaming Your Database Changes with Change Data Capture” (Part 1 + Part 2)“Conduit: Streaming Data Integration for Developers” (Jan 2022)“Why Conduit? An Evolutionary Leap Forward for Real-Time Data Integration” (Feb 2022)“Hello Meroxa 2.0” (April 2022)Resources for minoritiesKura Labs (A free training and job placement academy for Infrastructure Computing, DevOps, and SRE for students from underserved communities)Free Code Camp (Learn to code — for free)BooksZero To One (by Peter Thiel)The Hard Thing About Hard Things (by Ben Horowitz)PeopleTristan Handy (Co-Founder and CEO of dbt Labs)Arjun Narayan (Co-Founder and CEO of Materialize)Benn Stancil (Chief Analytics Officer at Mode Analytics)Chad Sanderson (Head of Data Platform at Convoy)NotesMy conversation with DeVaris was recorded back in April 2022. Since then, many things have happened at Meroxa. I'd recommend checking out:The introduction of Meroxa 2.0 and Turbine.This interview on data-driven work culture.New CDC Connectors built into Conduit.Meroxa is a recipient of DoD funding to help the US Space Force monitor aircraft health in real-time.About the showDatacast features long-form, in-depth conversations with practitioners and researchers in the data community to walk through their professional journeys and unpack the lessons learned along the way. I invite guests coming from a wide range of career paths — from scientists and analysts to founders and investors — to analyze the case for using data in the real world and extract their mental models (“the WHY and the HOW”) behind their pursuits. Hopefully, these conversations can serve as valuable tools for early-stage data professionals as they navigate their own careers in the exciting data universe.Datacast is produced and edited by James Le. Get in touch with feedback or guest suggestions by emailing khanhle.1013@gmail.com.Subscribe by searching for Datacast wherever you get podcasts or click one of the links below:Listen on SpotifyListen on Apple PodcastsListen on Google PodcastsIf you're new, see the podcast homepage for the most recent episodes to listen to, or browse the full guest list.

The Bike Shed
350: 21 Bell Salute

The Bike Shed

Play Episode Listen Later Aug 16, 2022 52:09


It's Steph and Chris' last show. Steph found a game, and if you've been following the journey, all of the Test::Unit test files are now live in RSpec. JWTs really grind Chris' gears. They wrap up with things they've learned, takeaways they've had, and their proudest podcasting moments. They also thank all the folks who've helped make The Bike Shed happen. 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. Microservices (https://www.youtube.com/watch?v=y8OnoxKotPQ) Transcript: CHRIS: One more round of golden roads, our golden. So here we go. STEPH: Oh, one more round of golden roads. Okay, maybe that's going to get to me today. [laughs] CHRIS: [singing] Golden roads take me home to the place. STEPH: [singing] I belong. CHRIS: Yeah, there you go. 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, at least one more time. So with that [chuckles] as an intro, Steph, what would you say is new in your world? STEPH: Hey, Chris. Well, today is the big day. It is the day that you and I are recording our final Bike Shed episode, which we have all the feels about, and we will definitely dive into. But to ignore some of that for now, I have another small fun update I can provide about a new game that I found. So one of the things that's new in my world is I started playing a new board game with Tim; it's called Ticket to Ride. Have you heard of that? CHRIS: I have. I don't know if I've played it. I feel like it's a particularly popular one now. But I don't know if I've ever had the pleasure. STEPH: It's a very cute game, so we have the smaller version of it. For anyone that's not familiar, it's essentially a map. And then there's a bunch of spots where you can build trains and connect them, and then you get tickets. So your goal is that you're going to connect one location to another location. And then you get points and yada yada, but it's so much fun and especially the two-player version. It's like this perfect 20, maybe 30-minute game. I'll be honest; I'm not really a board game person. I always enjoy it. Once I get into it, then I'm like, this is great. I don't know why I was resistant to this. But every time someone's like, "Do you want to play a board game?" I'm like, "Not really." [laughs] I first have to get into it. But I have really enjoyed Ticket to Ride. That's been a really fun game to play. And it's been a nice way to, like, even during the day, we'll break for lunch and squeeze in a game. CHRIS: Well, I love good two-player games. They're hard to find. But when you find a good one, and it's got that easy pickup and play...I believe I'm going to now purchase this. And thank you for the tip. STEPH: Yeah, this is definitely one of those where it's easy to pick up, and then you can get the expanded board. So there's a two-player version, but then yeah, you can get one that's a map of the U.S. or a map of Europe. And I think it accommodates up to five players as the maximum, so not a huge group but definitely more than two. On a slightly more technical note, I have something that I'm very excited to share. It is a journey that you have been on with me, that everybody listening has been on this journey with me. And I'm very excited. I see you nodding your head, so I'm guessing that you're going to know where I'm headed with this. But I'm very excited to announce that all of the Test::Unit test files now live in RSpec. So that is a big win. I'm very, very excited for that to be a previous state of life and not an ongoing state of life. Because I have certainly developed too much niche knowledge around migrating these tests, and that became apparent to me when I was pairing with another developer that works with the client because they had offered...they had some time. They're like, "Hey, do you want help migrating a test file?" And I was like, "Sure." I was like, "But this is wonky enough, like, we should pair and work on this together because I just know some ins and outs. And I don't want you to have to learn a lot of the hard lessons that I've learned." And the test that we happened to pick up was very gnarly. It had a lot of mystery guests. And we spent, I think it was a good two hours. And we only migrated one of the tests, so not even a full file but one of the tests. And at the end of it, I was like, I know way too much about some of the oddities and quirkiness of this. And we got through it, but we decided that wasn't a good use of their time for them to go at this alone. So that's why I'm extra excited and relieved because I didn't want this task to carry on to someone else. So, hooray, we did it. CHRIS: Hooray. Just in time. You're Indiana Jones grabbing your hat right as you roll out and off to [laughs] be away from the project for a bit. So you stuck the landing. Well done, Steph. STEPH: Thank you. Thank you. So that's some great news. And then also, everything else in life is pretty much focused around getting ready for maternity leave. That's about to happen soon, and I am so ready. I have thoroughly enjoyed a lot of the things that I'm doing, [laughs] but goodness, being pregnant is hard. And I am very much ready for that leave. So also, a lot of the things that I'm doing right now are very focused on making sure everything's transitioned and communicated and that I just feel really good about that day of departure. That covers all the newness in my world other than the big thing that we're just not talking about yet. How about you? What's new in your world? CHRIS: Well, continuing to skirt the bigger topic that we will certainly get to in the episode, what is new in my world? I'm actually quite excited workwise right now. We have a much larger body of work that finally we got the clarity. All the pieces fell into place, and now we're sort of everybody rowing in the same direction. There's interesting, I think, really impactful code that we're writing for Sagewell right now. So that's really fantastic. We've got the whole team back together on the engineering side. And so we're, I think, in the strongest and most interesting point that I have experienced thus far. So that's all really fantastic. On a slight technical deep dive, you know what really grinds my gears? It's JWTs. JSON Web Tokens and I have never gotten along. It's never been a match made in heaven. And we have a webhook that comes from Plaid. Plaid is a vendor for connecting bank accounts and whatnot. And they have webhooks like many people do. So they can inform us when things change, lovely feature of how we build web apps these days. But often, there's a signature that says, "This is definitively from us, and you can trust us." And usually, it's some calculated signature, HMAC, or something like that. For some reason, Plaid's uses JWTs, and more than that, they use JWKs. So there's JWT which is the signature. That JWT itself is signed with a JWK. You have to fetch the JWK from their server based on the key ID in the header of the JWT. But how do you know if you can trust the JWT before you've gotten the JWK? All of this broke in a recent upgrade. We went from Heroku-20 to Heroku-22 to the new platform with Heroku, which bumped us to OpenSSL 3.0, and it turns out JWT doesn't work with it. And so that's sad. It's a no. It's going to be a no. It turns out the way that OpenSSL 3.0 works is incompatible with some of the code paths in JWT. And so I was like, wait, we just can't do this? And it's low-level cryptographic primitive stuff that I'm not comfortable messing around with. I'm not going to hop in there and roll up my sleeves. And even just getting to the point that I understood what was broken about this took like an hour and a half just to sort of like, wait, which is okay...so the JWT signs and encodes. And this will be a theme that we come back to later, but I think web development should be simpler. I think we should strive for simplicity. And this is a perfect example where I'm guessing Plaid uses JWTs and that approach to communicating security things often, but I've not seen it used much for signing webhooks. And, oof, it led to a complicated day. And it's unfixable now as far as I can tell. There is a commit on the JWT Ruby repo as of five days ago, but it doesn't build in our system. And it's not released. And it's just a mess. So yeah, engineering is complicated. I'm both wildly excited about what we're doing at Sagewell, and then today was this local minimum of like, oh, JWTs again. Again, we find ourselves battling. And you won today, but hopefully not for too long. STEPH: Oof, how did this manifest that you first noticed? So is it because a webhook suddenly stopped working, and that was like the error that rose up, and that's what helped you dive into it? CHRIS: Yeah, we have a little bit of code in the controller for where Plaid events come in. We calculate and verify the signature of the webhook to make sure that it's valid, and we reject it otherwise. And we alert ourselves via Sentry, and then we also have a Datadog scan that can show what's the status code of the response. Because these are incoming HTTP payloads or requests, and so we can see there were 200 up until this magical day when suddenly everything changed. And that was when we switched Heroku stacks. And then we can see it also in Sentry. So we're able to look at it, and we're like, why are none of the Plaid webhooks able to verify the signature anymore? That seems weird. And so then Datadog confirmed that it consistently was broken from this point in time. And then we were able to track that back. It was also pretty easy to guess because the error was "pkeys are immutable in OpenSSL 3.0," and that was the data. And I was like, oh, cool, that sounds fun. Let me go figure out what that means. STEPH: [laughs] Well, it's a nice use of Datadog. I remember in the past you were talking about adding it. And I was excited because I've never been at that point where a team has just introduced it; either a team doesn't have it, and they wish they had more insights, or they have it and don't use it. And nobody ever checks the board. So that's a nice anecdote for Datadog helping you out. Yeah, I'm not envious of your situation, friend. CHRIS: I do love the cup half full take [laughs] that you have on the overall situation, but that's nice how Datadog worked out for you. And you know what? It was. Thank you, Steph, for once again being that voice of positivity. STEPH: I appreciate that you enjoy it because there are times that when someone points it out to me that I do that, I have to be like, "I'm sorry, I'm not trying to be toxic positivity over here. [chuckles] That's just how my brain works." CHRIS: Oh, you are definitively not toxic positivity. That's a different thing. Because you ended with but also, I feel bad for you, and I'm glad that I'm not in your shoes. So you are the right level of positivity. I don't think I could have talked to you for three and a half years as co-host on a podcast if I didn't appreciate the level of positivity or the general approach that you bring to thinking about stuff. STEPH: Okay. Well, to borrow a phrase from Matt Sumner, who has been a guest on the show, cool, cool, cool, cool. I'm glad my positivity has been well calibrated. And I was about to say I'm interested to hear how this turns out for the team. [laughs] But we're in an awkward spot where I mean, you and I, we can still totally chat. But listeners won't get to hear the rest of that particular saga. I mean, you can share. I mean, you do you. I'm setting all sorts of boundaries for you right now. Okay. And now I'm just rambling, and I'm getting weird with it. Because the truth is that, you know, we won't be back. And this is our final episode together. So I think let's just go ahead and rip off the Band-Aid. Let's dive into it. Let's talk about it. Given that it's our last episode that we are recording, we thought of a couple of things that we'd like to talk about. You brought up a great idea that I'm excited to dive into. Do you want to lead us in? CHRIS: Sure. Well, if we go back all the way to Episode 172, that is the first episode that you came on as a guest. I actually continue to really love the title of that episode, which is What I Believe About Software. And it both captured that conversation really well, but also, more generally, it's actually become the tagline of the show when we do our little introduction. What do we believe about building great software? Et cetera. And I think that's been the throughline of the conversations that we've had is what remains true. What are the themes? Not necessarily the specific technologies, although we certainly talk about that. But what do we believe about building great software? And so today, I thought it would be fun for us to talk about what do we still believe about building great software? It's roughly three and a half years or so that we've been doing this. What's still true? STEPH: Oh, well, I have the first unequivocal one, the thing that I still believe about building great software, and that's you should hire thoughtbot. That's definitely the way to go. We'll help you get it done, not that I'm biased in any way. CHRIS: No. I'd say collectively between us; there's zero bias with regard to thoughtbot or any other web development shop out there. But thoughtbot is the best. STEPH: All right, perfect. So we've got the first one, the clutch one of hire thoughtbot. And then I also really like this topic. And I still think back to that first episode that I recorded with you and how much fun that was and how that really got me to start thinking about this. Because it was something that, at the time, I didn't really reflect on a lot in terms of what does it take to build great software? I was often just doing the day-to-day actions but then not really going high-level think about it. So I'm excited this is one of the topics that we're revisiting. So for the next one, this one is, I don't know, maybe it's a little cutesy, but I was trying to think of an alliteration that I enjoyed. And so this one is be an assumption assassin. So what assumptions are you making? And then how can you validate or disprove them? And that is something that I find myself doing constantly. And it always yields better work, better questions, better software, better code, better code reviews. And that's my first one is be an assumption assassin and identify what assumptions you have. And I had a really good example come up today while I was having a conversation with Joël about something that I was looking to merge. But I was a little hesitant about it because there are some oddities that I won't dig in too deeply. But essentially, there's a test that I migrated that highlights an existing concern in the code. And I was like, should I go ahead and merge this test that documents it, or should I wait to fix that concern and address it? And he brought up a good point. And he's like, "Well, we're assuming it's a bug and an issue, but it may not actually be depending on how the software is being used." And so then he was encouraging me to reevaluate that assumption that I had where I'm like, oh, this is definitely a problem to, like, I don't know, is it a problem? Let's ask somebody. CHRIS: First off, I love that as a theme, as one of the things that you still believe about software. Second, I believe you correctly said that you were looking for an alliteration, but my brain heard acronym. STEPH: [laughs] CHRIS: And so then I was like, B-A-A-A. Is it BAAA? What are you going for there? Oh, you just wanted a bunch of As. Okay, I got it now. Secondly or thirdly, I think I'm on my third now. Apparently, within Sagewell team culture, one of the things that I'm most known for is... there are two phrases: one is just to name it, and the other is to be clear. And these are the two things that I do apparently constantly so much that it's become a meme within the team. It's just like, okay, everybody's been talking. But I just want to make sure we're on the same page here. So just to be clear, or just to name it, here's what I'm seeing. But I agree; I think taking those things...what are the implicit bits? What are the assumptions? And making them more explicit. Our job as developers is just to yell at computers all the time and make them try and do human stuff. And there's so much room for lossy conversions at every point in that conversation chain. And so yeah, being very clear, getting rid of assumptions, love it. It's all great stuff. Actually, in a very related note, the first on my list is that code is for humans to read. This is one of the things that I believe most deeply and most impacts the way that I write software. Any given piece of functionality that we want to author in our code feels like 10, 20, 50, frankly, almost infinite different versions of the code that would produce nearly identical functionality. So at the end of the day, the actual symbols and strings of text that we bring together to write the code is all about other humans, other people on your team, you five months from now, you a week from now, frankly, or me. I'm going to say me, me a week from now. I want to do future me and everyone else on the team a solid and spend that extra 10% of okay, I have something that works now, but let me try and push it around and try and massage it into a shape that is a little more representative of how we're actually thinking about the code, how we talk about it as an organization. Is that the word that we use to describe that domain concept? Maybe we could change that just a little bit. Can I push more of this into the private API? What actually needs to be known here? And I think that's where I'm happiest is in those moments because that's where all of the parts of the job come together, the bit where I trick a computer into doing what I want and simultaneously making it so that that code is revisitable, clear, expressive, all of those things. So yeah, code is for humans. And that's true across every language, and framework, and domain that I have worked in. And I've only believed it more and more so over time. So yeah, that's mine. STEPH: Yeah, I love that one. That's one of the things that comes to mind when people talk about disliking code reviews. And I can imagine there are a number of reasons that people may have had a poor experience with a code review process. But at the end of the day, if you're not getting that feedback or validation from fellow humans, then how do you know that you've been successful, that you've written something that other people can follow up on? Which goes back to the assumptions in terms of like, you're assuming that you have written something that your future self or that other people are going to be able to read and maintain down the road. So yeah, I love that one. One of the other things that I still hold really true to building great software is prioritize early and often. So always be checking in to understand with your users, with your tech concerns, with data that you may have, new insights, and then just confirm that yes, you and the team are constantly working on the thing that has been prioritized and that is the most important. And also, be ready to let go. That can be really hard. I have definitely had those moments in my career where I've spent two weeks working really hard on something. And then we've realized that the thing that we were pursuing isn't that valuable, or it's something that users don't need or actually want. And so it was better to let go of it than to pursue it and ship it anyways. So that's one of my other mantras that I have adopted now is prioritize, prioritize, prioritize. CHRIS: Unsurprisingly, I agree wholeheartedly with all of that. We're still searching for that thing, that core thing that we disagree on other than Pop-Tarts and IPAs. But I don't know that today is the episode that we're actually going to find that. But yeah, prioritizing is such a critical activity. And it is this interesting collaboration point. It gets different groups together. It's this trade-off. It's this balance. And it's a way to focus on and make explicit the choices that we're making. And we're always making choices. We're always making trade-offs. And so being more explicit, being more connected and collaborative around those I believe in so, so, so much. So love that that was something on your list. Let's see, next up on my list is reduce complexity, just sort of as an adage, just always be reducing complexity. It is amazing to me in my time, particularly as a consultant, but even now, this is something that I hold very true is just it's so easy to grow a system in anticipation of future complexity or imagine that the performance concerns that we're going to run into will be so large that we must switch from Postgres and a nice, simple atomic database into a sharded, clustered Kafka queue adventure. And there are absolutely cases that make sense for that sort of thing. But at a minimum, I beg of you, anyone starting a new system, don't start with microservices. Don't start with an event queue-based system. These are wildly complex versions of what often can be done with so much simpler of an application. And this scales through to everything. What's the complexity of an API? Do we need caching in that API layer? Or can we just be a little bit inefficient for a little while and avoid the complexity and the overhead of caching? Turns out caching is a tricky thing to get right, just as an aside. And so the idea of like, oh, let's just sprinkle in a little bit of caching. It'll be easy, and then we'll get better performance, like, yeah, but did you get it right? Or did you introduce a subtle bug into your program that's going to be really hard to debug later? Because do you cache in development? Well, maybe, I'm not sure, could be. So over time, this is something that I've sort of always felt, but I've only ratcheted it up. It's only something that I've come to believe in more and to hold more firmly to. I think earlier in my career, it was something that I felt, but I would more easily be swayed by aspirational ideas of the staggering amounts of traffic that we would be getting soon or the nine different ways that the data model will expand. And so, we should code the current version in anticipation of that. And I have become somewhat the old man on his lawn yelling at the clouds like, "Nah, we don't need it yet. We can grow to that." And there's a certain category of things that are useful to try and get out in front of and don't introduce additional complexity, but they're a tiny, tiny list. And so, for most things, my stance is what's the simplest thing that we can get away with right now, that still provides a meaningful experience to our users, that doesn't compromise on security or robustness or correctness but just solves the problem we have right now? And over and over and over again, that has served me incredibly well. So yeah, keep that complexity at bay. STEPH: That is one that I've definitely struggled with. And frankly, it works in my favor, that idea of keeping things simple. Because I'm terrible when it comes to predicting the future or trying to build things in a way that I just don't have enough information to really drive the architecture or the application that I'm building. So anytime I'm trying to then stretch and reach for the future in those ways unless I really have a concrete understanding of I am building for these particular scenarios, it's really hard to do. So I very much like keeping it simple and not optimizing before you need to. And it reminds me of I think it's Mark Twain, who has a quote, "Worrying is like paying a debt that you don't owe." And that's something that comes to mind for me when also writing code and building features and software is that I tend to be someone who will worry about stuff. And I'm like, oh, is this going to be easy to extend? Is it going to be what it needs to be six months from now if we need to add more features to this and build on top of it? And I have to remind myself it's like, well, let's just wait. Let's wait till we get there and we know more. One of my other ideas that couples nicely with the one that you just shared in regards to keeping things simple and then waiting for those needs to arise is that mistakes are going to happen. They are a part of the process. As we are learning and growing and we're stretching our skills and trying things out, things are going to go wrong. We're going to introduce bugs. And to take those opportunities, that's when we start to use that feedback to then improve things like observability, like capturing logs, and how we handle error reporting or having a plan for emergencies. So maybe that's the part of worrying that can pay off is thinking through, all right, if something does break, or if something gets shipped that shouldn't, then what is our plan in how we handle that? How do we roll back? Or how do we get things back to a stable build? CHRIS: It's funny. I was actually visiting with a friend this past weekend, and we were chatting more generally about life things but the idea of worrying and anticipation and trying to prepare for every bad outcome. And there's the adage of an ounce of prevention is worth a pound of cure. But increasingly, both in life, depending on the context, and in code, I've found that I've shifted to the opposite of it's impossible to stop everything. There are going to be bugs that are going to get out there. There are going to be places where we code things incorrectly. And I would rather...I still want to try as hard as I can to get things right, to be clear. I'm not giving up on trying. But I'm all the more focused on how do we know and how do we recover when those things happen? So it's interesting that you just described exactly that, which, again, is a very human life conversation, and yet it applies to the code. STEPH: I love that rephrasing of it. Instead of the mistakes are going to happen, it's, like, how do we know, and how do we recover? I think that's perfect. I've also found that by answering the how do we know and how do we recover, that really helps you build trust with clients as well. Because again, things are going to happen, things are going to break. And the more prepared you are for that and then the better plan that you have, and then they can watch how you execute that plan, and it's going to establish a lot of deep trust with other engineers and also the team that you're working with, that you have been thoughtful and that you have ideas on how are we going to address this? Instead of waiting for that moment to happen. That's going to happen too. You're going to make decisions in the heat of the moment. But I have found that to be a really useful way to establish yourself with a team in terms of I care about this team and these processes and this application. So how do we handle the bad times, not just the good times? I do want to circle back because you alluded to the fact that you and I, we've tried to find things that we disagree on. And so far, Pop-Tarts and beer have been the two things that we disagree on. But I do have a question for you that maybe I will disagree with you on. But I need to know some more about it first. You have alluded to there's the Brussels snack, (Oh, I'm going to get this wrong.) Brussels sprout snack hour or working lunch, something combination of those words. [laughs] And it's the working lunch that has stuck out to me, and I've wanted to ask you about it. So here I am. I'm asking you about it. What's a working lunch? What's the Brussels snack happy hour, snackariffic working lunch look like? CHRIS: This is fantastic. I love that you waited until the last episode that this was rolling around in the back of your head. And you're like, are you making the team work through lunch? And now, on this final episode, we get to address the controversy that has been brewing in the back of your head. Spoiler alert, no, this is just ridiculous nomenclature. These are two meetings that we have that are more like, let's get the dev team together and talk about stuff that's in our platform sort of developer experience. Or stuff in observability often is talked about in this context because it doesn't quite impact users, but it's how we think about the work. And so there are two different meetings that alternate every other week. So every Friday afternoon, we do this, but it's one of two meetings depending on the day. So there's a crispy Brussels snack hour that was the first one that was named, which was named purely for nonsense reasons because we don't have anything else that's named nonsensically in our organization. And so I was like, oh when we name this meeting, we should make it nonsense because we don't have any other...We don't have, you know, an SOA microservices fleet with Barbie doll and Galactus and all of the other wonderful names. Those are references to the greatest video ever about microservices; if you've not seen it, that will be in the show notes. It's required reading. But anyway, we don't have that. And so we thought, let's be funny with the name of this. So the crispy Brussels snack hour is one, and the crispy Brussels we wanted something that was...the first one is a planning meeting. The second is like, let's actually sort of ensemble program. Let's get the four of us together, and we'll work on some of the stuff that we're talking about here but as a group. And so I wanted the idea of we're working, and so I was like, oh, this will be the crispy Brussels work lunch. But it's purely a name. It's the same time slot. It's 3:00 o'clock on a Friday afternoon. [laughs] So it is not at all us working through lunch. I don't think we should work through lunch. I'm concerned that you thought that for a while, and you were just like, I'm a little worried, but I'm not going to bring it up. But I'm glad we got to cover this before we wrapped up this whole Bike Shed co-hosting adventure together. STEPH: I feel relieved and also a little robbed of an opportunity for us to have something that we disagree on because I thought this might be a thing. [laughs] CHRIS: We can continue searching for that thing. But maybe it's okay that we agreed on most stuff for the run [laughs] of this fun, little show that we did together. STEPH: Yeah, that's gone on quite a time. We've got like three years together that we have managed to really only find two, I mean, very important of course, two things. But yeah, it's been pretty limited to those two areas. And each time that you'd mentioned the work lunch, I was like, huh, I need to ask about that because I have feelings about it. But then, you always would dive into very interesting stories of things that came out of it, and I quickly forgot about it. So this feels good. This feels like very good important closure. I'm glad that this finally surfaced. But circling back, since I took us on a detour for a little bit, what are some other things that you still hold deeply about building great software? CHRIS: I've really got one last thing on the list. It's interesting, there's not a ton technically in this list, which I think represents broadly how I feel about software, and I think how you feel about software. It's like, it's actually mostly about how the people interact at the end of the day. And you can program in any language or framework, and you can get the job done. We certainly have our preferences and things that we enjoy. But the last one really rounds us out, which is think about the users. I always want to be anchoring the conversations that we're having, the approach that we're taking to building the software in what do the users think? Who are our users? What do we know about them? What do they care about? How are they using this technology? How is it impacting their lives? We've talked a number of times about potentially actually watching the sales demo as an engineering team, trying to understand what's the messaging that we're putting out into the world for this piece of software that we're building? Or write along with customer support and understand what are the pain points that people are hitting? And really, like, real humans, what are they experiencing? Potentially with a name attached. And that just changes the way that you think about the software. There's also even the lower-level version of it. As we're building classes or modules, what are the public facets of that, and what are the private API? What's the stuff that we're hiding away? And what's the shape that we are exposing to the outside world for varying definitions of outside? And how can we just bring in a little bit of empathy to try and think about, again, in the case of like the API for a class, it's probably you on the other side of it, but it's future you in a slightly different mindset with a little bit less information and context on the current problem that you're working on. And so, how can we make things easier for ourselves in the code, for our users at the end of the day? How can we deliver real value that is not mired in the minutiae of technical complexity and whatnot but really is trying to help people live better lives? That's a little too fancy as I say it out loud. But it is kind of the core of what I believe, so I'm not going to take it back. STEPH: I love how you've expanded users where more traditionally, it's people that are then using the software. But then you've expanded it to include developers because that is something that is often on my mind and something that I just agree with wholeheartedly in terms of when you're writing software; as you mentioned before, software is for people. And so we want to include others. And it does improve people's lives. People show up to work every day, and if you've been thoughtful if your past you has been thoughtful, it's either going to give you your future self a better day, or it's going to give other people a better day. So I think that's a very fair statement, improving lives by being thoughtful in regards to focusing on the users, people consuming software, and working in the codebase. CHRIS: I know we've talked about this before, but I was having a conversation with one of the developers on the team at Sagewell just last week, and they were mentioning how they really loved working on admin features. And I was like, oh, that's interesting. Let's talk more about that. And it was really it's that same thing that I think you and I have discussed of like there's that immediacy. There's that connection. These are actually colleagues, but you can build software to make their day better. You can understand in detail what the pain points are. What's the workflow that as you watch it, you're like, oh, I could put a button up in the corner of the screen that would automate almost all of this and your day would be that much faster? Oh, let me do that. That's exciting. And so I love that as another variation of it, like, yeah, there's for other developers. There's also for the admin team or other users in the organization of the software. There are so many different versions of users, but I think I think we build a better thing if we think about them more. STEPH: I have definitely worked with teams where I can tell that certain people are demoralized, and it comes down to they feel frustrated and often disconnected from the people that they are building for. And so then you really feel isolated. I'm pushing code around, but I don't really see the benefit or the purpose of it. And I think that's very hard for developers who typically want to build something that's going to be useful and not feel like it's just going to be thrown away. So connecting your team to those users, I certainly understand. Getting to build something for your colleagues and then they get to say how much they like it is an incredible, rewarding experience. You also touched on something that I really appreciate, where you highlighted that a lot of the technical decisions that we make are important, but they're not at the center of the things that we believe when it comes to building great software. And that's something that I will often reflect on. Like, as we were thinking through these particular ideas that we still hold true today, how mine are more people and process-focused and rarely deep in the technical weeds. And there are times that I think, well, shouldn't there be something that's more technical, something that's very concrete? Yes, you should build your code this way or build your application or use a specific technology. But after all the projects and teams that I've been a part of, that's just usually not the most important part. And so I appreciate that you highlighted that because sometimes I have to remind myself that, yes, those things can be challenging, but it's often with people and process. That's where the heart of great software lies. CHRIS: That's a fantastic phrase, I think, that really encapsulates all of the conversations that we're having here. 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 you cut your debugging time in half. So why do developers love Airbrake? Well, 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 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 enables 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 and includes 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. So head on over to airbrake.io/try/bikeshed to create your FREE developer account today! CHRIS: Actually shifting gears a little bit, so we've just talked about what we still believe about building great software. I'm intrigued. We've been chatting for a number of years here on this microphone, these microphones. We have separate ones because we're in different states. But I'm interested; what have we changed our minds about? What have you changed your mind about, Steph? I got a couple of ideas, but I'm intrigued to hear yours. STEPH: Nothing. I've never been wrong. I've stuck to everything that I've ever thought. CHRIS: That must be boring. STEPH: [laughs] Yeah, that's totally not true there. There are definitely things that I've changed my mind about. One of the things that I've changed my mind about is that people who know the most will ask the fewest questions. That's something that I used to consider the trademark of someone who is a more experienced senior developer in terms of you really know what you're doing. And so you typically don't ask for help or need help very often. And so, I'm going way back in terms of things that I have changed my mind about. But I have definitely changed my mind where people who know the most are actually the ones that do a really great job of constantly asking questions and asking for feedback. And I think that is still a misconception that people still carry forward. The idea that if you're asking a lot of questions or asking for help that you are not as skilled in your work, and I view it as quite the opposite, that you are very good at what you do and that you know precisely the value of your time. And then also reaching out to others for help, and then also just getting validation on things that you may have concerns around. So that's one I've changed my mind on is that I think the more experienced you are, the more questions you tend to ask. CHRIS: Oh, I love that one. It's a behavior that I know...I think we've talked about this before. But as consultants, we try and model it just the like; it's totally fine to ask questions. And because we often come in with less context, it makes sense for us to be asking questions, but I will definitely intentionally lean into it in those contexts to be like, everybody keeps throwing around this acronym. I don't actually know what that is. Let me raise my hand. And my favorite moment is when people disagree on what the acronym or what the particular word or what the particular project is. Like, I ask the question, and people are like, "Oh, it's this," and someone across the room is like, "Wait, that's what it means? I thought it was this totally other thing." I'm like, cool, glad that we sorted that out. Glad that we got that one up in the air. But I actually remember many, many, many years ago, at this point, there was a video series of...PeepCode was the company, and there was the Play by Play series. And so there were particular prominent developers, particularly in the Ruby community. And they would come and sort of be interviewed and pair program. And it was amazing getting to watch these big names that you had heard of, like Yehuda Katz is the one that stands out in my mind. He was one of the authors of merb, which was a framework that was merged with Rails, I want to say around the 3.0 time. And just an absolute, very big name in this world and someone that I looked up to and respected. And watching this video, they had to Google for particular API signatures and Rails methods. They were like, "Oh, how does that work? Is it link to and then you pass the name?" I forget what it was specifically. But it was just this very human normalizing moment of this person who has demonstrably done incredible work in our community and produced very complex software still needs to Google for the order of arguments to a particular method within Rails. I was like, oh, okay, that's good to know. And with complete humility in the moment, I was just like, yeah, this is normal. Like, it's impossible to hold all of that in your head. And seeing that early on shook me off the idea that that's the thing to do is just memorize everything. It's like no, no, get good at asking the questions. Get good at debugging. Get good, yeah, asking questions. It's a core skill rather than a thing that you grow out of. But I definitely shared early on I was like, not allowed to ask questions, that'll be scary. STEPH: I love that example. Because counterintuitively, to me, it demonstrates confidence when someone can say, "Oh, I don't remember how this works," or "Let me go look it up." And so I just very much appreciate when I see someone demonstrating that level of confidence of let's keep going. Let's keep making progress. I'm going to ask for help because that is totally fine, and we are in a safe space. Or I'm going to create a safe space for us to do that. One of my favorite versions of this where you shared like if you ask about an acronym and then people disagree, one of my favorite versions is to ask about a particular area of the codebase and be like, what would you say this code is doing here? What do you think users do here? Like, what is the purpose? What's the point of this? [chuckles] And then having people be able to say, "Oh, yeah, this definitively does this thing." Or people are like, "You know, I'm not sure. I don't even know if that code is getting run." That's one of my favorite outcomes of asking questions. How about you? What's something you've changed your mind about? CHRIS: I made a list of a couple of things like remote is on there. I didn't know if I'd like remote. I wanted to try it for a while. Tried it, turns out I like it a lot. It's complex. You got to manage it, whatever. But that I think everybody's talked about that a bunch. I think probably the most interesting one is deadlines. Initially, in my career, I didn't really feel anything about them. And then I experienced the badness of deadlines. Deadlines are bad. Deadlines are things that come down from on high and then you fail to hit them, and then you're sad. And maybe along the way, you're very stressed and work long hours to try and get there. But they're perhaps arbitrary. And what do they even mean? And also, we have this fixed scope, and they're just bad. And then there was a period of my time where, like, deadlines are bad. The only thing that we do is we show up, and we make the software as quickly as we can. But in reality, there are times that we need that constraint. And in fact, I have found a ton of value in deadlines when used intentionally. So we can draw a line in the sand, and we can say, at this point in time, we will have a version of the software. We have a marketing campaign that we need to align with this. So we got to have something at that point. And critically, if you're going to have a deadline, you've now fixed a point in time. You need to flex other things. And critically, I think the thing to flex is the scope. So we need to have team management. We have user accounts right now, but now we need to organize them into teams. That is like a category of functionality. It's not a singular feature. And so yeah, we can ship teams in the next quarter. What exactly that means is up in the air. And as long as we're able to have conversations essentially on a day-to-day at least weekly cadence as to what will make it in by that deadline and what won't, and we're able to have sometimes the hardest conversations but the very necessary conversations of the trade-offs that we have to make as we're building that software, then I find deadlines are absolutely fantastic tools for focusing and for actually reducing scope but in a really useful way. And getting something out there in the hands of users so that you start to get real feedback so that you start to learn, is this useful? What are the ways that people are using this? What should we lean into and do more of? What maybe should we roll back, actually? So yeah, deadlines. First, I didn't know them, then I feared them. Now I love them but only under the right circumstances. It's a double-edged sword, definitely. STEPH: I, too, have felt the terribleness of deadlines and railed against them pretty hard because I had gone through a negative experience with them but have also shifted my feelings about them where they can be incredibly useful. So I really liked that's one of the things that you've changed your mind about. It also reminds me of one of the other things...I'm going to circle back for a moment to one of the things that I believe about creating great software is to not wait for perfection, and deadlines are a really good tool that helps you not wait for perfection. Because I have also seen teams really struggle or sometimes fail because they waited until there was something perfect to present, and then you realize that you've built the wrong thing. So I do want to transition and talk a bit about the show because it's our last episode, and we should talk about it, and the fun adventures that we've had and some of the things that we've learned or things that we're feeling in the moment. So given that it's been a wonderful three years for me, it's been four years for you since you've been a host on the show. How are you feeling? CHRIS: I'm feeling a bunch of different things sort of all at once. I am definitely going to miss this immensely. Particularly, I loved when I started, and I got to interview a bunch of thoughtboters and other people from the community. But frankly, three-plus years of getting to chat with you has been just such a delight. There's been an ease to it. We kind of just show up and talk about what we're doing. And yet there are these themes that have run through it. And it has definitely helped me hone and shape my thinking and my ability to communicate about what I'm thinking. I've learned that you have a literal superpower to remember the last thing that you were talking about. Listeners, you may not know this, but we are not quite the put-together folks that we may sound like in these recordings. We have a wonderful editor, Mandy Moore, who makes us sound so much better than we are. But we'll often pause and stop and then discuss what we want to talk about next. And Steph always knows the exact phrase that she or I left off on. And it has been so valuable to the team. But really, it's been just such a pleasure getting to have these conversations. It's also been something that has just gently been in the back of my mind at all times. And so, I'm observing the work in any given week as I'm doing it. It's almost like meditation in a certain way, whereas I'm working on something, like, oh, this is actually really cool. I want to take a note about this and talk about it on The Bike Shed with Steph. And having this outlet, having this platform to be able to have those conversations and knowing that there are people out there is fantastic, although it's very weird because really, every one of these recordings is just you and I on a video call. And so there is an audience, I'm pretty sure. I think people listen to the show; I don't know, occasionally they write in, so it seems like they do. But at the end of the day, this really just feels like a conversation with a friend, and that has been so valuable to have. And yeah, I'm definitely going to miss that. It's been a wonderful run, you know, four years is a long time. It's about as long as I've done most things in my career. And so I'm very happy with what we have done here. And there's a trite saying that isn't...yeah, whatever; I'll just say it, which is, "Don't be sad that it's over. Be glad that it happened." And I guess I'm still going to be sad that it's over. But I am so glad that I got the opportunity to do this, that you joined in this adventure and that we got to chat each week. It's been really delightful. STEPH: I really liked how you refer to this as being a meditative state. And that is something that I have certainly picked up from you and thoroughly enjoyed that I have this space that I get to show up and bring these ideas and topics and then get to talk them out with you. And that has been such a nice way to either end the week or start a week. I mean, it doesn't matter. Anytime that we record, it's this very nice moment of the week where we get to come together and talk through some of the difficulties and share our stories. And that's been one of my favorite moments is because you and I get to show up and share everything that's going on. But then when someone writes into the show or if they send a tweet or something and they share their story or their version of something that happened, or if they said that we made them laugh, that was one of my favorite accomplishments is the idea that something that we have done was silly enough or fun enough that it has brought them joy and made them laugh. So I, too, I'm very, very much going to miss this. It has been a wonderful adventure. And I thank you for encouraging me to come on this adventure because I was quite nervous in the beginning. And this has definitely been an aspect of my life that started out as something that was very challenging and stretching my limits, and now it has become this very fun aspect and something that I get to show up and do and then get to share with everyone. And I do feel very proud of it, very much in part to Thom Obarski, who was our initial producer and helped us have that safe space to chat about things. And now Mandy, who keeps the show running smoothly and helps us sound our best week to week. So it's been a wonderful adventure. This is going to be hard to let go. And I think it's going to hit me most. Like, this was one of those things as we're talking about it, it's, like, I'll see you next week. This will be fine. But I think it's going to hit me when there's something that I want to talk about where I'm like, oh, this would be great to talk about, and I'll add it to The Bike Shed Trello board. And I'll be like, oh yeah, that's not a thing anymore, at least not quite in the same way that it was. CHRIS: So what I'm taking away from this is that you're immediately going to delete my phone number the minute we hang up this call and stop recording. [laughs] STEPH: Oh yeah. I preemptively deleted. So that's already done. Friendship is over at this point. CHRIS: That's smart. Yeah, because you might forget otherwise in the heat of the moment as we're wrapping this whole thing up. STEPH: [laughs] CHRIS: But actually, on that note, in a slightly more serious vein, again, there's this weird aspect where the audience is out there. But we're very sort of disconnected, particularly at the moment in time where we're recording. But it has been so wonderful getting various notes from listeners, listener questions, but also just commentary and the occasional thanks and focusing; oh, you pointed me in the direction, or you helped me think through a complicated piece of work or process a problem that we were having. And so that has been just so, so rewarding. And one of the facets of this that has been so interesting to me is being able to connect to people and basically put out there what we believe about software, and for the folks that resonate with it and be able to have that connection instantly. And meeting people, and they're like, "Oh, I've listened to The Bike Shed. I like all these things." I'm like, oh, cool, we get to skip way further into the conversation because I've already said a bunch, and you say you like that thing. So, cool, we're halfway through our introductory chat. And I know that we agree about a bunch of things, and that's really wonderful. And frankly, I'm going to miss that immensely. So for anyone out there who's found something valuable in this, who's enjoyed listening week to week, or perhaps even back to Upcase for things, I would love to hear from you. I'd love to connect to folks. Send me an email, Twitter. I'm on all the places. I'm Chris Toomey in various spots or ctoomey.com on the internet. Chris Toomey on GitHub. I'm findable, I think. Chris Toomey developer will probably get you there. But I would really love to hear from folks, to connect to folks, you know, someday down the road; I think I'll be hiring again. And that'll be fun. I would love to work with some of the folks that have listened to this show or meet you at a conference, or if I happen to be traveling to a city or you're traveling to Boston. Really for me, so much of what this show is about is connecting with people around how we think about building great software. And so, I would love to continue that forward into the future. So yeah, say hi, if you're interested. STEPH: I agree. That's been one of the most fun aspects of being co-host of the show. And I'll be honest, you are welcome to contact me, but I am going to be off-grid for probably six months. [laughs] So just know that there will be a bit of a delay before you hear back from me. But I would definitely love to hear from you. I also want to say a very heartfelt thanks to a couple of people, just folks that have made this journey incredible and have made it so much fun. One, in particular, is everyone at thoughtbot for their continuous stream of knowledge. I mean, frankly, my software opinions wouldn't be half as interesting if it wasn't for everyone at thoughtbot constantly sharing their knowledge and being a source of inspiration. So I deeply appreciate everyone that has contributed to topics and ideas and just constantly churning out blog posts because those are phenomenal. And I also want to give a shout-out to my husband, Tim, because he has listened to The Bike Shed for many years and even helped out with a number of show notes when that was something that you and I used to do before Mandy made our life so much easier and took that over for us. And has intervened a number of times when Utah mid-recording would decide it's time to play. So I want to give a very special thank you to him because he has been a very big supporter of the show and frankly helped me manage through a lot of the recordings for when I had an 80-pound dog that was demanding my attention. CHRIS: I think continuing on the note of thanks; similarly, I'm so grateful to thoughtbot as an organization for everything that is represented in my career. It's a decade-plus that I have been following and then listening to the podcasts and then joining the organization, and then getting so many wonderful opportunities to learn about this thing called web development. And then, even after I left the organization, I was able to stay on here on The Bike Shed and hang out and still chat with you, Steph, which has been really wonderful. So thank you, thoughtbot, so much. Thank you to Joël Quenneville, who will be the continuing host of the show. This show is not going anywhere. And, Steph, you and I aren't really going anywhere, but we won't be around anymore. But we are leaving it in the very, very capable hands of Joël, and I'm super excited to hear the direction that he takes it and Joel's incredibly thoughtful and nuanced approach to thinking about programming and communicating. So I think that will be really wonderful. And lastly, I definitely want to thank Derek Prior and Sage Griffin, the two original hosts of this show, who really produced something wonderful, and for many years, I think it was about four years that they hosted together. I was an avid listener despite actually working at the company the whole time and really loved the thing that they produced and was so grateful that they entrusted me with continuing it forward. And hopefully myself and then with the help of you along the way, we've...I think we've done an okay job, but now it is time to pass the torch or the green lantern. That's the adage I've been going with. Gotta pass the lantern, pass the mantle on to the next one. So, Joël, it's going to be in your hands now. STEPH: Yeah, I'm so looking forward to future episodes with Joël Quenneville. They are going to be fabulous. So I've been thinking in terms of this being our finale episode and then a fun ending for it, so there's a thing called the 21-gun salute, which is the military honor that's performed by firing cannons or artillery. Not to be confused with the three-volley salute, which I definitely confused earlier that is reserved and used at funerals, which this is not. So using the 21-gun salute, I was like, hmm, it is The Bike Shed, and we have this cute ring ring that goes. So I think for our finale, we should have a 21-bell salute as we exit the shed and right off into the sunset. CHRIS: I love it. I couldn't imagine a more perfect send-off. So with that, what do you think? Should we wrap up? STEPH: Yes, but I have one more silly thing to add. I've thought of a new software idiom that I'm excited about. And so, this may be my final send-off into glory that I'd like to share with you. And I think that we should make like a shard and split. CHRIS: [laughs] I so appreciate that in this moment, this final moment that we have together, you choose to go with a punny joke. It is so on brand for the show. It is absolutely perfect. And I think with that note, 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 on iTunes, as it really helps other folks find the show. STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. CHRIS: And I'm @christoomey. STEPH: Or you can reach us at hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeeeee!!!!!!!! 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.