Podcasts about pull requests

In this episode of Elixir Wizards, hosts Charles Suggs and Emma Whamond sit down with Marek Šuppa, creator of the Missing GitHub Status page, a project that reconstructs GitHub's historical uptime data and reveals discrepancies between official status reporting and the platform's actual reliability. Marek tells us about his dev journey from open source contributor at DuckDuckGo to machine learning engineer at Cisco-acquired Slido. Then, we discuss GitHub's evolution from a hosted Git service into a critical developer tool. We cover reliability, transparency, AI-driven platform growth, developer workflows, and the challenges of balancing convenience with resilience. Along the way, we cover alternative platforms, self-hosted solutions, and whether recent outages are changing how developers think about ownership, dependency, and the future of software collaboration. Topics Discussed in this Episode: Why did Mr. Shu create the Missing GitHub Status Page? GitHub's reported uptime versus developer experiences How open source contributions shaped Marek's career The evolution of GitHub from tool to critical infrastructure Centralization risks in modern software development Git's distributed roots and today's platform-centric workflows Developer reactions to GitHub outages Transparency and accountability in status reporting AI's impact on developer platforms and infrastructure demands Microsoft's stewardship of GitHub Forgejo, Codeberg, and alternative Git hosting platforms Self-hosted Git solutions and tradeoffs Network effects and platform lock-in The social side of software collaboration Building resilience into developer workflows What GitHub outages teach us about infrastructure dependency Links Mentioned: The Missing GitHub Status Page https://mrshu.github.io/github-statuses/ Slido https://www.slido.com/ https://duckduckgo.com/ The official GitHub Status Page https://www.githubstatus.com/ Statuspage.iohttps://www.atlassian.com/software/statuspage Zig Leaves GitHub https://ziglang.org/news/migrating-from-github-to-codeberg/ Ghostty Leaves GitHub https://mitchellh.com/writing/ghostty-leaving-github GitLab https://about.gitlab.com/ Codeberg https://codeberg.org/ https://git.kernel.org/ Forgejo Lightweight Self-Hosting https://forgejo.org/ Former GitHub CEO Thomas Dohmke launches Entire https://entire.io/news/former-github-ceo-thomas-dohmke-raises-60-million-seed-round Update on Spain and LALIGA blocks of the internet https://vercel.com/blog/update-on-spain-and-laliga-blocks-of-the-internet

I'm excited to work with Microsoft once again as the presenting sponsors of the AI Engineer World's Fair! We'll streaming live from MS Build today for a special crossover pod with our friends at No Priors and the one and only Satya Nadella. However we did not hold back with this interview - we asked all the burning questions about uptime and Copilot that we know you have in your minds. Lets go!For almost two decades, GitHub has been the home of software, where both open source and closed flow, through commits, pull requests, reviews, actions, etc.This ecosystem flourished as open-source maintainers and contributors would continue shipping code for the benefit of the community. However as coding agents began to ship mass quantities of code - growing 1400% in 2026, it marked a new era that was both extremely exciting and challenging for GitHub.While these agents help more people ship more projects, they also significantly increase the floor of how much code is shipped, how often it is shipped, how many people commit code, and basically orders of magnitude multiples in every dimension of GitHub infrastructure:Now GitHub inevitably experiences more pressure on their infrastructure which was originally designed around human developers moving at human speed. This has resulted in a very publicly notable uptime story:So it begs the question of whether current systems around code can absorb what AI produces. Can CI/CD keep up when every idea becomes a build? Can open source maintainers survive floods of AI-generated slop contributions? Can GitHub preserve the human social contract of software while becoming the operating layer for agents?Which brings us to the perfect person to answer these questions: GitHub COO Kyle Daigle. In this episode, he joins swyx to unpack what happens when AI doesn't just autocomplete code, but starts changing how companies operate, how open source works, how pull requests get reviewed, and how GitHub itself has to scale. We go deep on GitHub's internal AI workflows: micro-skills, WorkIQ, MCP, Slack, Teams, email, Copilot workflows, the new Copilot desktop app, CLI, cloud agents, and how Kyle uses agents to look backwards across company context before deciding what to do next. Kyle also reflects on GitHub's history building webhooks, APIs, Actions, npm, Dependabot, and Semmle, why the AI era is breaking GitHub in new ways, how Actions became a general-purpose compute layer, and what Copilot becomes after code completion.Full Video PodWe discuss:* Kyle's expanded role across GitHub* How AI got Kyle coding again after years in leadership* Why GitHub rolls out AI through existing workflows instead of forcing new tools* WorkIQ, MCP, Slack, Teams, email, and GitHub as company context* Why massive “mega-skills” are giving way to small, atomic micro-skills* How AI changes summarization, communications, marketing, and analyst work* Why former developers in leadership may have a unique advantage in the AI era* Kyle's “15 agents on Saturday” workflow* How Kyle built an AI-generated executive presentation for CRO/CFO teams* Why AI changes the chief of staff role without removing the human work* GitHub Actions, webhooks, arbitrary code execution, and secure agent compute* The npm acquisition, supply-chain security, 2FA, and token invalidation* Slop forks, vendoring, and whether AI agents change dependency management* What pull requests become when most PRs come from agents* Prompt requests, vouching, AI review, and trust in open source* What counts as a “developer” when AI lowers the barrier to building* GitHub Spark, low-code, and why GitHub refuses to hide the code* 14x commit growth, Actions load, databases, monorepos, and availability* Copilot's evolution from completion to CLI, desktop app, cloud agents, and SDK* Context, memory, rules, and making GitHub “act like Kyle wants it to act”* Ambient AI, OpenClaw, enterprise security, and the new operating system for agents* What swyx should ask Satya Nadella about Microsoft's AI futureKyle Daigle* LinkedIn: https://www.linkedin.com/in/kyledaigle* X: https://x.com/kdaigleTimestamps00:00:00 Introduction00:03:36 Why AI Got Kyle Coding Again00:07:04 Running GitHub with AI: WorkIQ, MCP, Slack, Teams, and Skills00:15:39 The Golden Age for Former Developers in Leadership00:17:31 15 Agents on Saturday and AI-Generated Executive Work00:20:20 How AI Changes the Chief of Staff Role00:21:45 GitHub's History: Actions, npm, Webhooks, and Open Source00:28:45 Slop Forks, Vendoring, and AI Dependency Management00:33:57 Pull Requests, Prompt Requests, and Trust in Agent-Generated Code00:41:21 GitHub Stars, 200M+ Developers, and the New AI Builder Wave00:45:15 GitHub Spark, Low-Code, and Why GitHub Still Shows the Code00:47:38 GitHub's Hardest Era: 14x Growth, Reliability, and Scale00:59:21 Actions as the Compute Layer for CI/CD and Automation01:02:04 The State and Future of GitHub Copilot01:08:24 Ambient AI, Background Agents, and the Future of the SDLC01:13:09 OpenClaw, Enterprise Security, and the New OS for Agents01:18:03 Build Announcements, WorkIQ, FoundryIQ, and Microsoft Context01:21:41 What Should swyx Ask Satya?TranscriptIntroduction: Kyle Daigle's Expanded Role at GitHub and MicrosoftSwyx [00:00:00]: We're here with Kyle Daigle, COO of GitHub. Welcome.Kyle [00:00:07]: Hey, thanks for having me.Swyx [00:00:08]: You're not just CEO of GitHub. People know you as that. You have a new role.Kyle [00:00:11]: So I have an expanded role now. I've been working at GitHub for thirteen years and doing all things developer. Joined as a developer myself. And now, I'm also responsible as the CMO of Developer for Microsoft. And so all the kind of learnings and passion for developers and how we work with them and how we communicate and how we bring our products to market, we're also bringing that expertise to the broader Microsoft ecosystem and helping every developer that uses a Microsoft product or would like to have a sort of similar experience that they've had with GitHub over the years. So it's a different role in some ways, but it's also just building on the experience that I've had at GitHub of just sort of tell the truth, be authentic, show people how to use it and then let the products speak for themselves. Now just doing that with, all of Microsoft.Swyx [00:01:09]: We'll be releasing this in conjunction with Build. You got lots of stuff planned, and we can sort of touch on that whenever it's appropriate. I think one of the interesting things is I rarely meet a COO who's also a CMO. I think you're a very outward facing and you're very confident publicly. That's rare. Do you actually view yourself as COO? What's What is your thing?From GitHub Developer to COO/CMO: Building the Platform and Operating GitHubKyle [00:01:33]: I think for me, it's been funny. The titles have always been, a— have always felt a little strange to me. I joined GitHub as a developer? I wrote so much of theSwyx [00:01:46]: Let's bring that up. You wrote the back ends?Kyle [00:01:48]: I was going through, I was going through, some old photos, when folks were talking about how things were being built or how there was a build GitHub. I built, webhooks and worked with teams building the API, built the platform layer. Anything that integrated with GitHub, up until really twenty eighteen, I built or ran the engineering teams. And that's kind of where my the beginning of my passion always was helping people build things, deliver them to, their customers. And so being a developer, building for developers was always super unique. In a— I think as my role expanded, it became my ability to talk to not just developers, but also enterprise customers or business leaders and have this translation layer. And then through all those years, GitHub has always operated pretty uniquely. Post-pandemic, working remotely was not as novel as it was when GitHub started in two thousand and eight. But all that expertise of running remote teams, doing it well, became this sort of bigger role, ultimately turning into the COO role of how do we operate GitHub in the way that GitHub's always operated after the Microsoft acquisition. And kind of so on from there. So like for me, I think the— I've, I still code. I love coding but the problem has always been, people. It's a much harder problem to both support our own employees, a harder problem to communicate to developers and enterprise buyers what we're building why it matters, ‘cause those are two very different messages. And so getting to work in the mix of COO, CMO, also just being a dev, I think is what's kept me at GitHub for so long.AI Workflows for Leadership: Commits, Retrospectives, and ContextSwyx [00:03:40]: Apparently, you have— your commits have gone up. What's this? What's going on?Kyle [00:03:45]: Rui's called me out pretty aggressively. So I think— as you can imagine, right, you can see my normal era of being a dev In the twenty thirteen, twenty fourteen era, and then moving into management, and then ultimately the COO role. I think what you see there is me, really getting back to coding thanks to AI. I— similar to, attaching problems between how to market and how to operate a business and how to code, I find, building agents and workflows that are connecting very disparate problems to be what's driving this. So that's, some of it's writing software. A lot of it is, connecting a ton of a different data sources to, help me out. But that is completely me really diving in on the AI side in trying out our tools, trying out everyone's tools, But building for me, building for the non-technical leader, though I'm technical and how we're, able to use these tools more than just the simple, call and response that I think a lot of the non-technical, your employers, you have to get— you have to use AI, and so everyone uses, ChatGPT or Copilot or Claude or whatever. To really get into, how is this going to help me out, it— I find that it's not the I need to write a blog post, I need to those simple examples. Helping people find the workflows of, “Okay, I need you to go through all the PRs today. I need you to go through everything that we've posted online. I need you to go through what we did the last three months. Go through all of my Obsidian notes for any mentions of this then go through my transcripts at work.” We use, Teams, so, using WorkIQ, go call that MCP server, grab all the transcripts, go through all the Slack, and then build me out the plan of, what this week's messaging actually was. That's something that was, impossible because for me, I find AI in a what most of this launch here is actually, less building forward. It's actually, a recursive loop backwards. I'm always looking at what had happened first. Go back through the week and tell me what we did, what worked, what didn't work? And then tell me in the next three or four days-What would you tweak based on this sort of like looking backwards and then looking ahead a little bit? I find that to be so much more valuable, especially for like non-technical, because that retrospection is actually LLMs are very good at that. Like finding all the patterns, pulling them out, and then applying that retrospection to just a couple of days or just like a short period of time. Is all a bunch of apps that I've built and launched a bunch of, internal tools. I use the new, GitHub Copilot app, the desktop app with workflows. Every time I crack open my laptop, it's running workflows for me. It's just a ton of different stuff and of course, it all ends up on, it all ends up on GitHub.Swyx [00:06:47]: Of course. That's where, that's where, stuff is hosted. Man, there's so much to ask you. I was going to leave the how do you run a company with AI thing at the end. I have to ask one— double click one thing. You said, you are looking back at the week. You're, you're understanding what happens. When you say we That's three thousand people. How?Rolling Out AI Internally: Skills, CLIs, and Company ContextKyle [00:07:09]: I think when we started rolling out AI internally beyond engineering, right? One of the things that I was really, passionate about is like we have to do this in a way where no one has to change how they work. I don't want to have to teach you a tool. I don't want to have to teach you something new. And so for us, we tried out a few tools. Most of them don't work because I got to get you on board? I got to teach you how to use it. What we've actually ended up doing is we've built like a set of skills internally. We have we each have our set of skills, and we've just been distributing even to the non-technical folks, the CLI. And then effectively, we're just giving it access to like read about everything that we're writing. So that's for us, that's usually GitHub, Teams, Email, and Slack. So Teams for, video chat, generally speaking.Swyx [00:08:03]: Teams and Slack?Kyle [00:08:04]: so we use Teams for video communication, but we don't use it for chat. W-we— GitHub for a long history, right? We're alwaysSwyx [00:08:13]: Also SlackKyle [00:08:14]: Talking about ChatOps and like everything is built into Slack. Like every command, every flow.Swyx [00:08:18]: So even though you have been acquired for I don't know, eight years nowKyle [00:08:22]: we stillSwyx [00:08:23]: You still use Slack?Kyle [00:08:23]: it's a purpose-built tool for us, and I think the reality is that moving off of it would be so bluntly expensive? Simply because all the tooling is, baked in with that paradigm. And they both have their pros and cons but they don't work the same way at all. We still use a bunch of different tools Because it's the purpose-built tools that We need. And thenSwyx [00:08:47]: Well, the same doesn't go for the rest of Microsoft, presumably.Kyle [00:08:50]: like the like various teams like operateSwyx [00:08:53]: They make their own decisionsKyle [00:08:54]: Various ways. I think it just matters what you're trying to what you're trying to do. But we do we do work across kind of every tool that we use, and then by giving everyone access to all of that context and the new WorkIQ MCP server, which is quite cool if you do live in the M365 like world. I can ask it all these backwards-facing questions, and it's incredibly important for our teams that are working remotely. There's a lot of stuff you miss when you're not in an office, and we are spread out all over the world. So most of that is looking back. And then we post, we post either auto-automatically into GitHub issues or discussions, these sorts of like findings or like our industry reports. Like what's happening this morning, today, yesterday. A little automation gets run. We'll use the app. We might use GitHub Actions like with, our agentic workflows just to go do that run, and then we push it into GitHub, and w-we keep having a conversation. So usually for us, it's about that sort of like looking back, looking forward on the non-technical side. And then of course for a lot of those folks, it's also building an app, pushing it to GitHub pages or pushing it somewhere to host it et cetera. But it's just like enabling everyone with that power of it's going to take me a week to figure this out. Instead, we're going “Okay I built a skill. Let's put it into a repo. We'll all share that skill together, and then we'll use the CLI or now the app-” “just to run it.”Micro Skills vs. Mega Skills: How GitHub Uses AI at WorkSwyx [00:10:26]: All right. I think, I think we're going straight into like the team management and productivity thing. I think a lot of people are getting various levels of LLM psychosis. How do you manage the bloat of skills? Like everyone Has their thing, and they're Like trying to promote it to the rest of their peers in their org, right? And obviously, whoever becomes a skill influencer internally becomes like an AI leader, right? Of sorts. I assume you have those.Kyle [00:10:50]: like I think we haveSwyx [00:10:52]: And I assume it's a mess a Yeah.Kyle [00:10:54]: there's like I— like I think the reality is there's two pieces. Like first is I think that we're ending the era of these like massive, beautiful, perfect skills that are just like not any of those things. ‘cause for a while, right every tweet every day is like go download the skills, the perfectly managed thing to do this entire workflow. And I think that like what we've found and what— I was just with my team, this week, and we were talking about the skill side, and we're really talking about these like incredibly micro skills that are just doing one thing for us very well Versus a skill that's going to do I said, that full report. That doesn't really exist on our side anymore. It's usually how do— like a single skill that's going to identify the most important marketing information given any MCP server. Like this is the most important thing. Less about stitch a bunch of tools together and have it produce this mega output because then weeks go by, months go by, things change, and you want to tweakSwyx [00:11:58]: It's brittleKyle [00:11:58]: Your mega skill and you're screwed? You can't do that. And so now we're really just talking about the Legos we're using and just letting the instruction book be something we're all putting together. Whereas I think a lot of AI skills for a while have been that mega instruction book style.Swyx [00:12:15]: I've, thought a lot about Postel's law. I don't know if that's a term that is, means things to folks. It's the idea that you should be liberal in what you accept and strict in what you output, right? And I think that's like a good framing principle for skills. This is my skills, obviously on GitHub. I feel like everyone should have like how like some repos In GitHub are special repos? I feel like we should sort of reify the slash skills and everyone like give it some kind of special presentation. Anyway, so, yeah, this is one of those like download Download anything, transcribe anything, and then you can string together the atomic skills that do one thing well Into like some kind of orchestration skill that calls other skills. I assume, does that match?Kyle [00:12:56]: I like I think so. I think that theSwyx [00:13:00]: Summarize anything.Kyle [00:13:01]: Like I think the- For me, summarizing something for I do communications and PR and analyst relations and marketing and customer activities, and so my summarize everything is very different for each one of those like Contexts. What ‘Cause if I'm summarizing something for an analyst, that's a very different thing than, probably how I'm going to summarize something for like a customer meeting or an engagement. So that's I think like the difference when we're talking about the like the tools I might use on Saturday or the skills I might use on a Saturday when it's just for Kyle. Yeah, those are kind of like they have an atomic actual tool underneath or maybe skill, and then Kyle cares about X. But I think when we're talking about work and enabling the the marketers, communicators there, it's the atomic, this is what good summarization is, and then this is what I care about as for marketing for communications For whatever. And that I think is like the interesting matrix problem when we go from like a developer set of concerns to all kinds of different professions, is that what that word means to me is different than it means to you is different than it means to the analyst or the salesperson, and that's where I think the matrix mess is that we're starting to like still starting to find. It's about these mega skills but they're all just slight permutations, but those permutations are really important. It's the difference between someone reading this and going “Did AI make this?” what Or “This makes total sense, and I would expect this when I'm giving a briefing to Gartner,” or like whatever else.Swyx [00:14:37]: I think the beauty of it maybe is that you don't have to be that careful about what goes in there. It doesn't have to exactly fit as long as it like roughly is contained in there. I used to complain about plugin hell, basically. Like when you have a framework and then you have a hundred things that you need to integrate, everyone does like the GitHub used to be bloated full of these things. And now we don't need them anymore ‘cause now you just use skills.Former Developers in Leadership: AI as a Creation MultiplierKyle [00:15:00]: And like I think the most magical thing is the just that like I can just also crack it open. Like Like yes, I could go like change the how the plugin is coded, or like I could go do that now with AI, but I think there's just something more magical about getting a response back and being “That's not right,” and then you just crack the skill open, you just type English words and it's different. That building block is just, I think very unique. Once I get everyone to kind of understand how to best how to best make those changes to get the most power out of them.Swyx [00:15:36]: Is there a— you have a your peer group that Of people like you. Is there a common framing for Something I'm feeling is, which is true, is that is this a golden age for former developers who are now in leadership? Because you can wield the tools, you would know the right words, you're maybe not too close to the details. Doesn't matter. But like you're more effective than someone who doesn't come from that background.Kyle [00:15:59]: I think that like the secret has always been your ability to identify patterns and solve problems, and I think that for folks that like myself that don't code day to day anymore, that has made me successful as a developer, made me successful as a COO and now CMO. And so now that I have access to get and write code, I'm now applying that sort of like pattern finding and problem solving, and I know enough still about how to then go and say, “Oh, I want to make an app, but I don't want to break into jail or create something that's not going to be able to work or to be deployed scale or whatever.” that ability to apply all that additional business knowledge and still code I think is what makes that so interesting to me. Slightly different than I think some of the other like technical leaders that became business leaders and now are going back to their apps and updating them. Good for them? But I think the more, much more interesting thing is, well, now I have this whole new set of expertise over ten plus years. Why not take that and use that as a developer with these AI tools? So I definitely think that makes me more powerful, but I think that's true for like every dev as well. Most of the dev friends I still have also have some other underlying skill and passion. There's really talented, very kind of linear computer science software devs, absolutely. I just find that the folks that came from a different career, went to school for something else, went off and did this random thing, and then became a software dev, or were a dev, did a random thing, came back. Learning that extra set of information, learning those extra skills, and now having the power of an AI where I can crank up fifteen agents on Saturday while my kids are doing lacrosse, That's like really powerful. And I think it gets me back to that feeling of like creation, and it's very hard to replicate that in most other senses? That first time you build an app and you click it and you show someone that's magical. And so being able to do that not just in code, but across all kinds of different assets that's, that's huge. We were doing we're doing our every year we do our revenue planning. We talk about okay, what is it going to look like for next year? And of course as you imagine, there's, slideshows everywhere talking about what are we going to talk about, what's the narrative, et cetera. And so as you said I'm “Okay, well, I could probably just like build something to build this and then that way I don't have to go build the whole spreadsheet or I have to pass it to my team.” So we went through this process, and I got all the information and used the skills I mentioned. I built like a little app just to make it so I could look at some of the information in a SQLite database, more easily. And I ultimately built this entire presentation without touching any of it and I was “Okay, I'm just going to present this to our CRO, the CFO, their teams,” without mentioning I'd built it with AI. I like built a skill to make it look very much not AI driven. Just not pretty.AI-Generated Presentations, Human Taste, and the Changing Chief of Staff RoleSwyx [00:19:03]: Like a design. Yeah.Kyle [00:19:03]: Not pretty. But just like very clearly not AI. Kind of like don't do anything interesting.Swyx [00:19:08]: That's, yeah, that is valuable.Kyle [00:19:08]: Just go Exactly. We did the whole thing through. It used my notes from Obsidian, it used all the context I mentioned before, the plans, and Never came up once that it was AI generated.Swyx [00:19:20]: It didn't matter.Kyle [00:19:20]: Never once. D It didn't matter. And so now I takeSwyx [00:19:23]: This is a toolKyle [00:19:23]: I can take that tool and go, “Look, I don't want you to go build slideshows.” They're just helping us share information with each other. If this thing can do it With a little bit of crafting from you and then we can look at it together, awesome. There's no value in all that extra work. I think that the ability to, make it look humanly bad and and build a little app to, manipulate the data I think is part of, that upside for devs that are now in leadership roles. Because, the thing that I feel like I said before, this that's all a people, that's all a people problem. I know if you've used a coworker or not to build a slide deck, unless you spent a bunch of time to not do it.Swyx [00:20:07]: I know, but like it was so, I think there's a certain charm to just being blatantly AI. ‘Cause I think that you're well, you're just honest about There may be mistakes here that I cannot vouch for. So how much value is there? But anyway I think, actually the real question I want to ask is, there's a— You were a chief of staff To Thomas. And in the pre-AI world, the that job would've been a chief of staff job of like Can you prep me these slides and all that? And now you do it yourself.Kyle [00:20:35]: I still, I still have a chief of staff. Because, the difference is it's sort of the discussion every time we have some sort of technology evolution is it's not that the jobs the roles don't all go away, they just change? And so yeah, I don't have someone spending all their time building out slides for me and presentations ‘cause I don't need that anymore. But now I need that person that is able to go and find all the different connections between humans in those discussions to help me find out, okay, I should be meeting with this group and this team, and they have an opportunity, and I'm going to be in San Francisco today, I'm going to be in Seattle tomorrow. Those sorts of human connection aspects are still incredibly valuable and has always been a big part of that chief of staff role. But now just like chiefs of staff are not opening up, letters to process, they're doing emails. What It's the same thing. And now they're, they're not building out as many of these presentations because they have the the ability to have a AI take it on for, and share that with me and great. Let's keep moving ‘cause it's allowing us to go faster and make better decisions more quickly.Swyx [00:21:45]: Awesome. Well, so we can dive into more sort of, Productivity insights as you go. I did want to do a little bit of a brief history of colleague and hub. Because, we started here. And then you also involved the NPM acquisition. I did, I do want to touch upon that. And then more recently, I just want to bring up to present day where we're having uptime issues Which transparently we've already Addressed publicly, but we'll, we'll discuss in the pod. Did I miss anything? Like what, any other major highlights? Obviously, it's, it's a lot of years to cover.A Brief History of GitHub: Webhooks, Actions, Acquisitions, and Platform EvolutionKyle [00:22:15]: No the I think one of one highlight was right before the acquisition closed in twenty eighteen, I got to launch the first version of ActionsSwyx [00:22:27]: OhKyle [00:22:27]: At GitHub Universe. So it was OSwyx [00:22:29]: They're that young?Kyle [00:22:30]: It was October of twenty eighteen, I think. Yeah. Yeah.Swyx [00:22:33]: Gee, Jesus.Kyle [00:22:34]: I got to I was the engineering leader on that project and got to launch that. And then, yeah, we did acquisitions of NPM you said, Semmle, Dependabot Pul Panda a whole bunch of things. That was a bigSwyx [00:22:47]: Pul Panda.Kyle [00:22:48]: Abi is doing well.Swyx [00:22:51]: DX. Holy crap.Kyle [00:22:52]: Did well on DX. I and like that was a that was the big shift, after the acquisition. I had to join the sort of business side.Swyx [00:23:00]: So I need to hit you on some of these things ‘cause you were there. Right? And how often do I get to talk to someone who was there? But yeah, Actions. Is that the number one source of security issues on GitHub?Kyle [00:23:11]: Oh, sh I think that the number one source of, security issues is probably like all, the literal code in everyone's like underlying repositories. I would say back further than that is, if you remember I had to show in this graph was this is, I'm, didn't say this before, this is ultimately webhooks.Swyx [00:23:30]: You yeah.Kyle [00:23:31]: Like circa whatever it was.Swyx [00:23:32]: It says Hookshot in there.Kyle [00:23:32]: I forget. Yeah. Yeah, Hookshot's in there. And so like back then, it says GitHub Services. Do you see, it says Hookshot FE for front end, and then it says GitHub Services. GitHub Services back in the old days, right? You we had a repository that was Ruby code, and you could write any Ruby code in there, and then we would execute that On your behalf As a service, and then that way if an if you were trying to integrate with something, it didn't we would run it for you.Swyx [00:23:57]: And of course no containers ‘causeKyle [00:23:58]: No, ‘cause it wasSwyx [00:23:59]: Well, no containersKyle [00:24:00]: Twenty fourteen. And so there was some isolation obviously, but it was mostly the separations on the server level. That's like an example as long as the very old version of Pages, which ran on its own containerization infrastructure, not on Actions.Swyx [00:24:15]: Which like all-time great product.Kyle [00:24:16]: Pages powers the internet at this point to some degree. Those were places where like clearly there were no like issues like to my knowledge. But it was those things where I'm looking at and going “Okay, well we can't be running arbitrary Ruby code,” like on everyone's behalf. Then containerizing all of that up intoUh into actions now where yeah the containerization, is r-really good. The pinning most folks aren't pinning it the like to a particularSwyx [00:24:48]: ImagesKyle [00:24:48]: Sha, et cetera like their workflows, and so that's a big that's a big place Of pain for folks if they're just doing similar to any dependency management, just V1 or newest or latest, I think. But, that journey from that day to “Okay, we're just going to run all this arbitrary code, and, it'll basically be okay,” to now, no, we have, really good containerization. We have a new, underlying, ag-agent, containerization, service. It's like we're using it under the hood. It's through Azure. They recently announced it. The Azure, Dev Compute, but it's, very fast, very fast compute to be able to, spin up your own cloud agents, or whatnot. We're using it under the hood for some parts of the new,Swyx [00:25:36]: Microsoft Dev Box?Kyle [00:25:37]: No. Dev Compute, yeah.Swyx [00:25:41]: Hmm. Not finding it just yet.Kyle [00:25:44]: Oh, it's, it's in there somewhere.Swyx [00:25:46]: All right. Well, we'll cut that out.Kyle [00:25:47]: Sorry. But with, Dev Compute, you can, run, really fast, spin up really, small VMs really quickly, so you're doing a tool callSwyx [00:25:58]: Same conceptKyle [00:25:58]: Just do it containerize exact-exactly. So we're using that so definitely moving that direction to protect us from every every piece of code that we're ultimately running.Swyx [00:26:07]: look, that grows into the full SDLC? Code hosting was just the start and and then it's grown beyond that. Let's talk about NPM may-maybe ‘cause I think that's also, a very major point in the industry. I do think, it was looking for a home. It was, kind of struggling as a business, right? I don't know, I don't know how you would characterize that whole acquisition and how itNPM, Package Security, and Keeping the Internet RunningKyle [00:26:33]: like when we were talking to the team, I think the big thing for the both of us was to find a way to keep NPM, which was basically powering the internet then and way more so now to some degree running. Keep it going keep continuing to scale. It was having scaling problems, if I recall, back at that time. They were doing some rewrites. ItSwyx [00:27:00]: that's cute compared to now.Kyle [00:27:01]: Well, that's the thing is like when I'm talking to folks now, there's there's so many more underlying uses of NPM than there were back when we had them join in with GitHub. But that was ultimately the goal. It was really okay, we used to have pages. We have, the world's code. Let's make sure that we can keep NPM running well for the world. And we put a bunch of time and investment into fixing some of the underlying backend, changes, some of which we talked about some of the manifest work, et cetera. And then now, really trying to bring the the security posture of NPM up to speed. But, it is a unique challenge in that every move that we make to make it more secure will break a lot of people. And security is paramount. And also, we take it very seriously. We're, the any time that we have a problem with GitHub or we make a change that makes us more secure but hurts, there's, a snow day for developers or a really bad fire that they have to go put out. And so we've, have changed the 2FA policies. We've changed the way the tokens work. When we find tokens that have been exposed or potentially, exposed, we invalidate them, andSwyx [00:28:22]: I love that feature in GitHub. Yeah, it's greatKyle [00:28:23]: That creates issues, but, the but that's the thing is we're trying to push the community, forward without necessarily, doing something that is going to break the contract that's been for 15 years or close to it or some amount of years on NPM.Slop Forks, Vendoring, and the Future of Open Source Supply ChainsSwyx [00:28:43]: I think the— So now we're talking about, open source and publishing. And I think there's something here with what people are calling slop forks, which, I think Malta from Vercel is doing. And, part of me thinks, well, the way to get past any vulnerabilities, we just, let's just get rid of the concept of NPM. And we only publish source code. And anytime you want to import it you have your coding agent look at it and then adapt whatever subset you're going to use into your vendor it. But, the AI vendor it. Is that realistic? I don't know. Is it— Will that solve all our security issues? I don't know.Kyle [00:29:24]: I don't think it'll solve I so Mitchell was just talking Mitchell Hashimoto Was just talking about this today, and I think that I-in some ways, it's all all things, old or new again? Yeah, absolutely vendoring everything. Like I do I do remember twenty thirteen, twenty fourteen.Swyx [00:29:42]: This is Yeah. Let's, we must return toKyle [00:29:43]: That's what is We were vendoring everything. We were having actual discussions around, or at least I remember we were “Should we take this full thing?” “Why is this so big? We only need this one file.” And so I do think there's something true there where having either taking only what you need or the dependencies just getting incredibly small over time, I think will help to some degree, but it's not going to solve the fundamental problem, I don't think, because the vulnerabilities in an agent looking at them, there's time and time again, there's a million different ways in which we can convince an agent that this thing is, secure or not and pull it in. Or we can do static code analysis or runtime testing to say whether the code works or not. That is, I think, the step that needs to continue to be, invested in. The question is just on, how much scope. Should it be this enormous project that I'm pulling down, or should it be this piece? Either most companies are running some amount of security checking on the on the packages that they're bringing in or vendoring. That I think won't change. That's like what advanced security does to some degree, Socket does some degree. Like everyone is doing a piece of that. How we each do that like especially when we're talking to enterprise customers, is just like very different. No there's no one wants one single way to do it. And I think that's always been GitHub's, unique position in the world. I talk a lot to maintainers, I talk a lot to folks about this. It's we're— we rarely start like a process and a practice and like push it onto the community. We usually wait for the sort of like RFC process socially or literally, everyone agreeing, and then we'll cement something in. Because otherwise we'reMaintainers, RFCs, Vouching, and the Social Layer of TrustSwyx [00:31:35]: That fits your role in the ecosystem, yeahKyle [00:31:36]: We're GitHub. Yeah, we don't want to shape the whole thing. We want it to be figured out. But like how do you balance that like sort of Role in the industry to keep everything as secure as is possible and make sure that you're you're not going to be compromised as a human, ‘cause that's usually how it all happens. And Not not create a process or lock us into a flow that you're not going to or like Mitchell's not going to or other open source projects aren't going to like. That's always been a tricky balance for us, and I think that's something that we haven't talked about enough is we're not going to be able to fix everything for everyone in a way that everyone is going to like. So tell, help us, tell us what is working. When Mitchell was talking about, the Upvote, the upSwyx [00:32:22]: I was going to bring up his thing. Yeah.Kyle [00:32:23]: I forget what it Yeah. When he's talking to us, I was chatting with him and talking to him about this and I put it on Twitter and we talked to, also over DM, was “We're going to keep working.” but I think the important thing is I do actually want to hear what isn't working for you. And as, be as specific and clear for your project as is possible. And to every piece of credit over the many years that we've known each other through the industry, he's always done that and I appreciate that ‘cause there are places that we need to fix up, and we hear from him, and we'll fix up just like we do all other kinds of maintainers. But that that process between making those types of improvements and being more secure and like creating, I forget what he calls it's not the proof process, not the claims process. Do what I'm talking about? He has that he his projects have a way for you to kind of like,Swyx [00:33:13]: VouchKyle [00:33:13]: Vouch. Thank you. Yeah. He has like the vouch system for saying, “Hey, you should accept my PRs.” That's beenSwyx [00:33:20]: I just built this into GitHub. I don't know.Kyle [00:33:22]: Well, see, but that's the thing is that you say that and like he and his community really likes this and then I'll go talk to other maintainers and other maintainers, globally, and they're “No, this doesn't work for me.” And that is the tension, but also the kind of beauty of GitHub, depending on which way you look at it is we want to help maintainers, so we create all these tools to let you have more control over how much you take in from AI and PRs. But you can also use this. What You can go use this project, and if it takes off and becomes the kind of mostly standard, then yeah, we probably wouldn't enforce it but we would add it in because that's the flow that we tend to do?Swyx [00:34:02]: I hear a lot of people don't know the history of the pull request. And like like that's how, that's something that GitHub standardized basically.Kyle [00:34:08]: Yeah. It was a very messy process Like beforehand, and now the we have the benefit of it being the process? And now we have to go and Figure out the next best process or what adaptations change, or what does a pull request look like when eighty percent of your PRs are just coming from your agents and not From other devs?Swyx [00:34:31]: Do you like the prompt request idea from Peter?Kyle [00:34:34]: like I think that for each like each idea I think has its merits. I'm not, I'm not avoiding saying anything good or bad, but I feel like I've seen a version of we have that we have entire Thomas' store. Take all the assets of what you've built and put that in. I think that's got great ideas. There's all these various permutations of the PR flow, but I think the reason why there's not a single answer is ultimately we're trying to codify trust. We're trying to say “Okay, if Sean reviews this I'm going to trust it because you're Sean or you're the senior dev or you're the whatever.” And right now, when we are working in a flow where an agent writes code and another agent reviews code and then Kyle goes and looks at it the trust is kind of diffuse. And most of the tools that we're talking about are talking more about verification flows. We have more assets to look at, so I can probably say whether this is a good PR or not. But that still doesn't solve, I think, the human problem of I'm looking at a PR and I want to know if I can trust it. And we're still, we still tend to use human signals for that? Mitchell approving it or Kyle approving it or whatever. And so I think that's, I think that's why most of these options haven't really solved it is because, it's a social problem ultimately. It's a it's a human problem to review it and agree. Or you fully trust the tool and you're imbuing that tool with full trust Which I think in some cases that absolutely exists.AI-Generated PRs, Trust, and the Waymo AnalogySwyx [00:36:08]: And so like in the same way that there will be a tipping point in society when we don't allow humans to drive anymore Because machines are measurably better than Than humans. I'm looking for that tipping point, right? Like Mythos is ridiculously expensive. Someday we'll have Mythos on a desktop. I don't know. Will, does that change the equation?Kyle [00:36:30]: I think it's more I took a Waymo here, and I was on my phone and not looking around at all. There are other, self-driving, vehicles that I would not trust while, staring at the road. And I think that trust is something that isSwyx [00:36:48]: Is this a Zoox thing? What is itKyle [00:36:50]: I think that is both. I think that is both. LikeSwyx [00:36:53]: There's Zoox in this robo taxi. That's it. It'sKyle [00:36:56]: Well, depending on what level Of self-driving. But, my point is sort of that I think part of that is I strongly believe that's, a mixture of verifiable proof. Like how many accidents, how much data, and so on, and the human aspect of how I feel when I'm in this car, what it tells me, et cetera. And so that's why I think some of the like Some of these some of our AI tools tend to, imbue me with more of that feeling of trust, even if the data says this is 100% accurate. I feel like it takes more time for us to go, “Should I trust this or not?” And that's in the soft sense of, startups with high agency, weekend projects, and open source. And then there's enterprises and regulated industries and everything else, and that is an even harder problem to go solve because even when it is fully verified, not only do you have to have trust from the humans on the team, you probably have to have trust from multinational,Swyx [00:37:55]: Oh my GodKyle [00:37:55]: Multi governments around the world and regulating agencies. And so that's where I feel like until we tip over to your point on the sort of like human EQ side of it. I feel okay this feels okay I've been proven enough. Then the ball will start to roll a lot faster, where we'll end up getting to the “Okay, we can trust this,” and feel good about it in the Most difficult of cases.Reputation, Sponsors, Stars, and Bot Activity on GitHubSwyx [00:38:18]: If human trust is the thing that matters, I feel like GitHub as the developer social network could maybe do more there. Like vouchers are one system But, we have star counts, and then we have Contributor rights, and that's it. And I feel like there should be more in that space. I don't know if there's any other design decisions there.Kyle [00:38:37]: I think that one of the places that we don't really expose right now in this sort of way is, some degree of like hard trust and support, which would like for me is like sponsors is a good example of that.Swyx [00:38:49]: Ah.Kyle [00:38:49]: It like costs you something. To prove that I believe in your project and I trust you To some degree or I want to support you at the very least.Swyx [00:38:56]: Solve payments for open source. Why not?Kyle [00:38:58]: I think that I think that like as we keep moving forward, right, there's more and more projects where I'm, adding more and more dollars into sponsors personally because I want to like support them, but I also like know of I've probably never met them in person, but, I know of enough of their work that I want to support them. I think the thing that I don't love about stars or commit counts or anything else is ultimately, even with all of the various, abuse and de-spamming and deduplication work that we do or anti-abuse work that we do, these are all, not active social signals. They're passive ones that are ultimately gamifiable. And you may trust me, but another open source maintainer may not. And on what heuristic should you be, trusting me? That I think, is kind of where some of our thinking is right now. What signal from me is most important to you? You— If you can define that potentially, honestly in an agentic workflow that's what we see some of these open source projects do, where you have GitHub actions, and then you have like an agentic workflow that's calling AI, and you're setting these rules. Like if Kyle has submitted and gotten accepted PRs across any given project and has a social handle tied to his account in GitHub, and that social account's older than a certain amount. Really complex measures that matter to you ‘cause most open source projects have that heuristic built into their heads, if not written down in the contributing guidelines. You could take that and then go apply that and then just say, “Oh, we're not going to accept this PR.” Building something that is, I think, malleable to everyone's needs, is a little bit better, rather than going “Hmm, this account's too young.” Because what happens? The attackers just go and go and create a multitude of accounts, and they wait Until it ages up. Needs to have a certain amount of stars. That's how star inflation happens. Need to have a certain amount of reposSwyx [00:40:46]: Oh my God. YeahKyle [00:40:47]: With PRs. They all just create repos and submit PRs to each other, and then they come in and do something nefarious. And so, it's hard. It's hard to find the measure. So I think we're, we're looking more at how can we provide you tools so you can kind of choose what's best for you. And of course, we'll give you some standards. But the trust vector, gets down to I don't know, some version of like human digital ID like everyone's been talking about. Like how do I prove that it's meSwyx [00:41:13]: Give me your eyeballsKyle [00:41:14]: On the internet. Give me your eyeballs. Exactly.Swyx [00:41:18]: The I got to keep moving on Topics, but obviously I can go all day on this stuff because, I've been involved in GitHub and open source My entire professional career. Stars. Very superficial. Everyone knows it. But I think time to one hundred thousand stars is the fastest I've ever seen. Like people just reached that in I don't know, months. And then like at the same time I don't trust it right? Like how many of these are real or bot or like whatever. I don't know how to ask this but like what can we do about it? LikeKyle [00:41:49]: JustSwyx [00:41:49]: Is stars broken? Is stars fine?Kyle [00:41:51]: I think that there's kind of two, there's like two pieces. Obviously we're constantly like trying to find ways in which like your users are producing spam, which would, I would include like be like only doing star gamification. When we find them, we pluck ‘em out and we,Swyx [00:42:08]: But it's like a Whac-A-MoleKyle [00:42:10]: It's a hundred percent like a Whac-A-MoleSwyx [00:42:11]: There's no wayKyle [00:42:11]: Now, powered by AI to be helpful. But I think more so what I'm seeing is, a lot of the like fastest time to X tends to be because we're now inviting so many more people into like software development on GitHub That like the zeitgeist is just swarming? And it'sSwyx [00:42:32]: It's not just developers anymoreKyle [00:42:33]: And it's not you and I. Like like however you want to say like what a developer is it's not just folks who have been coding for a very long time. It's folks that have maybe started coding or only joined in since the AI era. And nowSwyx [00:42:44]: what's the latest Octoverse number? I know eighty million was my lastRem- member that a number of developers on GitHubKyle [00:42:50]: Oh, we're over 200 million now.Swyx [00:42:53]: Okay. Well, so you see?Kyle [00:42:55]: Like over 200 million developers now.Swyx [00:42:56]: But it's not developers, right? It's, it's people with a GitHub account.What Counts as a Developer in the AI Era?Kyle [00:43:00]: So, so this is, this is the biggest debate that I would say, everyone loves to have at GitHub at this point. From my perspective, right, I think that there's, there's clearly a difference between, professional enterprise developer and then developers. But I think that I think that the idea that we should be I don't know, splitting hairs or segmenting developers in the early era of software development is, not worth our not worth the time. SoSwyx [00:43:29]: When you get into gatekeepingKyle [00:43:31]: 100%Swyx [00:43:31]: What is a developer?Kyle [00:43:31]: 100%. ‘Cause I wasn't a developer when I started writing code? I was going toSwyx [00:43:36]: Oh, no. I made— I cloned a thing, seven years before I learned to code. And then I and then I wrote about my learning to code journey, and people Just called me a fraud ‘cause I had a GitHub account. And I'm “Well, no, I just use GitHub, but I don't know-” “I didn't know what I was doing.”Kyle [00:43:49]: I I remember that. I remember those sets of posts, and like that's, that's b******t. So I fight very clearly on the line of, if you create code, if you have an idea and you create it into some way of, I'm, I'm going to run it and use the app right now, you may still use AI in that moment, but that's okay. At some point you're going to do the next thing. You're going to create a big— You're going to have to learn about this database. You're going to fix a bug, whatever. We're all on some same journey, and those people are also hearing about the great new agent skill package or a new CLI tool or a new whatever. And those projects are going up because you want to be a part of this moment, just like I wanted to be a part of the Ruby community when Ruby was popping off when I started becoming a developer, and now I can just click the star button. And so I think that yes, there's clearly some amount of like spamming and game gamification that we're working against, but I really think we're just seeing this whole new cohort of folks that are moving from technology to technology because they're not working on a 20-year-old software application. They're working on a side app that they built on the weekend for their friends or for their new idea or whatever. And that's how you see these enormous charts going up and to the right with With stars.Swyx [00:44:59]: I think something that's remarkable is the persistence or, that GitHub extends to those folks. Usually when I see platforms go into a new audience, they usually have to, have like a second platform with a different name that wraps the main platform. But somehow GitHub has been able to sort of persist and extend, and it's friendly and whatever? So it's, it's nice.Spark, Low-Code, and Always Showing the CodeKyle [00:45:19]: I that's partially why I think as we've tried to move into I don't know, more like low-code-y things. We so we started working on Spark as like a way to, build an app and run it. I think that the reality is that we anytime we try to, kind of put even a veneer on top of it without when we put a veneer on top of something, we still always show you the code. That's kind of like a tenant. We're never going to, hide the code from you ever, because whatSwyx [00:45:52]: Why would you?Kyle [00:45:52]: That's, yeah, that's the whole point? However, I think that what we learned with things like Spark is that really the value of Spark for most devs is, easy runtime. And you may have a runtime or a host that you're going to use for that or you just build something and run it but, the package of making that even more simple isn't really needed for folks that are trying to build software and not just trying to build, an app, which is, slightly different, a slightly different goal. So I want to get you in, I want to get you comfortable. I think the best thing for me as, someone that did not traditionally come into software dev way back, I want anyone to be able to breach that chasm and not be in the I don't know, I feel like we're, we're still in an era of, STEM. I've got a 12-year-old and an eight-year-old, and it's “We got to get ‘em into STEM,”? Over and over. And I like I do, I do the things that good parents do. I was “Oh, you want to do coding?” “Yes, I want to do coding.” Do coding classes. But now they're just not afraid of doing software. And that's, I think, the thing that's honestly kept me at GitHub for so long. Anyone should be able to go and build a thing, just like I can go change a light switch in my house. I'm not going to go into the breaker box ‘cause I'll probably kill myself? But, I can go change that light switch. Everyone should be able to go and say, “This fricking app doesn't do what I want. I want it to work like this.” And that I think, is what's kind of kept us all connected with GitHub through the years and some and during the easiest of times or in the hard times because of that opportunity of, we're the home for all developers, and we want everyone to be able to have that feeling that we've had of, had an idea, I created it and holy s**t here it is.Swyx [00:47:37]: Here it is. All right, I'm going to try to do more spicy questions.GitHub's Hardest Scaling Moment: Growth, Agents, and UptimeKyle [00:47:42]: Great.Swyx [00:47:42]: Is it an easy time now or a hard time?Kyle [00:47:45]: Oh at GitHub? It's a hard time. Like, it's a hard time and also, I was just with my team and I said, “This is also, the best and most exciting time that I think I can remember at GitHub.” BecauseSwyx [00:47:57]: Best of times, worst of times. It's never oneKyle [00:47:59]: ‘cause we've we were talking about Octoverse reports and, usually we do an Octoverse report once a year, and we look at the numbers, and we say, “Oh my goodness.” I was at Universe in October saying, “This was the fastest year of growth that we've ever had,” right? And now we're doing more in a month than we did in a year last year.Swyx [00:48:20]: You're talking about PRs.Kyle [00:48:21]: Commits.Swyx [00:48:21]: Commits, yeah.Kyle [00:48:22]: PRs. Kind of like you name it by roughly every measure that we're looking at, there's some amount of sort of growth that is much bigger, and that is breaking our system in new ways, not old ways. Like webhooks were always notoriously, unreliable over the years?Swyx [00:48:38]: Whose fault is that?Kyle [00:48:39]: not anymore mine, but for a period of time, I'm sure you could pull up a tweet that was “It was me. I'm sorry.” but, now, that got rewritten at a scale level that is still working and is not having problems today. Now what we're finding isn't just the isn't the-The simple stuff that folks are on the sometimes on Twitter or on the internet are “Hey, why is this like this?” Sure. There's absolutely silly problems that we shouldn't exist. But now we're talking about, unique, novel permission problems that happen only at a scale across all different objects or whatever, that now we have to go rewrite this underlying system. And so it's, there are problems that yeah, caught us off guard, which I think I said. Like the growth is astronomical, but also we're making such material progress in that I'm excited once we're once we've kind of like reimagined the underlying foundation layer, or pieces of it at least, what's going to be possible when it's not just all of us and all the new people that are being developers and all of their agents and all the tools like working together. Because that'll still happen in that in that GitHub tool, that GitHub community. But it's a it's a hard day anytime we can't give you what you're looking for. We have the same problem internally. We operate through github. Com. Of course, we have backups when things go down and whatnot for our own operations but we feel it too. If it's not working it's not working for us, and that's kind of like the promise of dogfooding for GitHub. It's always been true. We're using the same tool you're using. We're not using a super secret version. We and so we also need it to be great for us for our customers of course for open source. And now an exponential growth of agents, Doing it too.Swyx [00:50:32]: I wanted to load for audio listeners who maybe haven't seen your tweets, whatever. So one billion commits in twenty-five. Now it's two hundred and seventy-five million per week on pace for fourteen billion this year, if growth remains linear. Is that still the pace? I don't know. It's been aKyle [00:50:48]: it's, it's speedingSwyx [00:50:50]: Roughly.Kyle [00:50:50]: It's still speeding up.Swyx [00:50:51]: It's, it's April, so yeah.Kyle [00:50:51]: Exactly. This was in April.Swyx [00:50:53]: All right. So basically you have fourteen x growth, right? Year on year on year. And I think that's a scaling issue. I think, I'm going to like try to really steel man this thing. People have experienced fourteen x growth. They haven't had your downtime. And that's like— C-can we go dig into that? Why? Like what's the— what broke? What are we doing to fix it? Like just anything for the community to reassure them.Why GitHub Reliability Is Breaking in New WaysKyle [00:51:18]: so there's a Like I was saying, there's a couple different places that we've seen the growth issues. Some of the growth issues, which is why we're t— I was talking about pushing hard on more CPUs is in actions in particular. More tools, more agents, more PRs mean more builds, more builds mean more CPUs. And so we are expanding through not just our data center, but obviously we were talking about moving to Azure and moving to, adding an additional cloud compute because we simply need more CPUs. Not as much GPUs. We definitely need GPUs too, but now CPUs are becoming a factor.Swyx [00:51:53]: It's very CPU heavy.Kyle [00:51:54]: Underneath the hood when it comes to some of the underlying services, we've been breaking up over the years our database infrastructure, so that way we have, more cognitive separation between our the various services. The place that we continue to have pain is in, permissioning. And so right now m-many of our permissioning layers sit into a database that we like internally call MySQL One, and old Hubbers will know what I'm talking about. And so we've been pulling things out of MySQL One for many years, because like and we use we use Vitess and we use other technologies to shard and we do it as one bigSwyx [00:52:31]: Famous thing, PlanetScale was born from this andKyle [00:52:32]: A hundred percent. Sam Old Hubber and friend. And so finding these opportunities to like break this out and then do that globally. The other thing that I think is interesting and both a unique opportunity and tricky is we also run everything I just talked about in a black box container with GitHub Enterprise Server for people that work on-prem. So we take everything I just said, and we also do it on-prem, and we also do all of that and we do it in a data residence setup for customers that need to have their data in a single location. Each of these has the unique characteristic around how we're sort of storing that data in MySQL or in a permissioning setup. That's where some of these outages have oc-occurred, where you're seeing it more like across the board rather than just like the one pieceSwyx [00:53:17]: Filling the databaseKyle [00:53:17]: Isn't quite working. Exactly. And so part of it is that. I think there's been some other places where agents are much more or more projects appear to be moving towards monorepo versus we were going the other direction for many years in the industry. Repos were smaller, but there were more of them, and now we're seeing the opposite. Repos are bigger, and there's, not fewer of them per se ‘cause there's new growth, but, we're just seeing many more big repos. Big repos, big monorepos have always had, a unique performance problem. Because each one, is slightly different if, particularly if the underlying blobs are incredibly big Inside the repos. And so we've done a ton of work that you pro— like most people haven't probably experienced, unless you're in this case of the monorepo. But that Git, infrastructure layer improvement does help the overall, system because, many of the improvements that make monorepos work better make all repo infrastructure work better. And so, I could kind of keep going down the line where it's another thing where we're moving out of, We're changing how we do j I'll just say job queuing for lack of a better, explanation changing the underlying technologies there.Swyx [00:54:32]: I spent two years being a job queuing guy, so.Kyle [00:54:34]: And so it's kind of a little bit of a little bit of piece by piece, and it's mostly because as we were— as it was built, we built everything in a way that assumed, I guess in some ways that the size of the pipe of work was going to remain the same. There's just going to be more people coming through each of those pipes. But instead now in places whereA git push was, generally a certain size for example, is now, no longer true.Swyx [00:55:03]: Oh, yeah.Kyle [00:55:03]: OrSwyx [00:55:05]: I push a thousandKyle [00:55:06]: On the average. 100%Swyx [00:55:06]: A thousand line commits like dailyKyle [00:55:07]: Same thing with PRs. Like PRs same thing. And like we've talked about optimizing that and making changes where, and there were technology choices that did not work there? And it got slow, and it didn't It was not fast. It did not do what the users wanted. And so we've been reeling that all out and going “Okay, that's just not right. Let's stop putting good money after bad and do it the do it the right way or the right way now.” So there's It's a it's a lot of things, not quite when I've experienced scale at GitHub historically, it's almost always two options that we've used. We go vertical scaling, particularly with databases, right? And we go horizontal scaling. Oh, we just have more people using this service. Great. We're going to add more servers, and we rack them in our data center, or we use it in a cloud. And now we're sort of in a like diagonal, where like vertical doesn't really work anymore. Horizontal isn't work either because we're all We all have some CPU or GPU constraints in the world now, and now we have to go in and like crack open services that have been running for 10 or 15 years and go, “Okay, the rules of this service have legitimately changed, and now we have to rewrite them.” None of this is an excuse. This is like we're We have to do the work. We have to make it better.Swyx [00:56:22]: actually as an infra guy, I'm “This is like one of the most fascinating scaling challenges I've ever seen.”Kyle [00:56:26]: That's that's, that's the thing that's the thing that it's hard for Like when we weren't talking about it publicly, and I was like I came out, and I was “Hey, I just want to explain what's going on.” Part of it comes from a very old GitHub ethos, which is it's our it's our uptime. It's down. W What I know you're a developer, so you're, you're inclined to want to understand more what's going on. But at the same time us going “Hey, this service didn't, perform the way we expected, and now we have to go change it,” we weren't We're not trying to hide anything from you i

SummaryIn this episode I'm joined by Chad Holdorf, longtime product and technology leader whose career spans John Deere, Salesforce, Pendo, and now Demandbase, where he leads AI initiatives across the company.We explore how AI is fundamentally reshaping the way modern product teams test, ship, and learn, from debugging customer issues directly against live codebases to product managers and support teams submitting pull requests themselves. Chad shares how tools like Cursor and Claude are collapsing traditional handoffs between product, engineering, and support, creating a much faster feedback loop between customer problems, experimentation, and shipped solutions.We also get into the messy reality behind enterprise AI adoption, including data quality, hallucinations, trust, evals, and why testing AI products inside real customer environments is much harder than most demos make it look. Chad gives us a peek into how his own workflow has changed, how his teams are learning by building in real time, and why this moment reminds him of the early days of Lean Startup, where he and I first met.If you've been wondering what AI-native product development actually looks and feels like inside a real company, this episode is for you.TakeawaysAI is collapsing traditional handoffs between product, engineering, and support teams. Chad described customer support teams going directly into code repositories with AI tools to investigate issues, understand root causes, and eventually submit merge requests themselves.Most enterprise AI demos fall apart when connected to messy real-world customer data. Chad emphasized that “just putting Claude on top of the data” failed quickly without extensive labeling, validation, testing, and human feedback loops. Customers could detect hallucinations within a few prompts.AI systems expose hidden data inconsistencies inside organizations. One example showed AI selecting a custom CRM field that technically produced better targeting results than the field support teams were trained to use, creating confusion about which “truth” was actually correct.Trust has become the critical success factor for enterprise AI adoption. Chad explained that once customers encounter inaccurate outputs, confidence in the system drops immediately, which forces teams to spend enormous time improving prompts, SQL queries, evals, and validation workflows before broader rollout.Product managers are increasingly becoming hands-on builders again. Instead of relying entirely on engineering handoffs, Chad now spends large portions of his week inside Cursor and AI coding agents investigating bugs, generating tickets, reviewing repos, and shaping product direction directly through code conversations.AI-native workflows dramatically compress feedback loops. Problems that previously took days of back-and-forth between support, product, and engineering can now move from customer issue to deployed fix in under an hour through AI-assisted workflows and automated merge requests.The biggest organizational bottleneck is shifting away from engineering speed toward enablement and adaptation. Chad compared this moment to early Agile adoption, where downstream teams like sales, support, and training struggled to keep pace with accelerated shipping cycles. AI is now amplifying that challenge even further.Continuous learning and experimentation matter more than formal process mastery right now. Chad repeatedly compared the current AI moment to the early Agile movement: the people progressing fastest are the ones willing to try tools, build things, stay curious, and learn in public rather than waiting for established best practices or certifications.Guest LinksLinkedIn: https://www.linkedin.com/in/chadholdorf/Demandbase: https://www.demandbase.com/ If your leadership team is about to make a big strategic bet, the real risk usually isn't the idea, it's the assumptions behind it that haven't been surfaced yet. A Decision Sprint is a focused 6–12 week engagement where we extract, map, and test those risks so leaders can make a clear Commit, Correct, or Cut decision before major capital moves. Learn more or apply at precoil.com.

Wie hat dir die Folge gefallen?Gut

Episode 319 covers a range of industry developments, primarily focusing on the recent Vercel security incident and the evolving landscape of AI-driven compliance. The hosts detail how a Vercel employee's use of a consumer-level Context AI plan led to a workspace compromise via a leaked OAuth token, eventually allowing attackers to access sensitive environment variables. This leads to a critical discussion about the SOC 2 provider Delve, with the hosts addressing allegations regarding "fake" compliance automation and the general limitations of auditing frameworks that do not inherently equate to true security. This episode also explores the future of the Pull Request (PR) flow, debating whether traditional human-led code reviews are "dead" due to the massive volume of code generated by AI agents. While they acknowledge that startups are moving toward autonomous commits, Seth argues that the PR concept is evolving into a system of agentic attestation and guardrails rather than disappearing entirely. The episode concludes with community survey results on this shift and a reminder about the hosts' upcoming training sessions in Singapore.

Monorepo, Polyrepo, Frontend hier, Backend dort, Mobile-App nochmal woanders. Klingt nach sauberer Trennung, führt in der Praxis aber oft zu genau dem, was wir als Entwickler:innen am wenigsten brauchen: Reibung. Abhängige Pull Requests, aufeinander wartende Releases, doppelte Tooling-Arbeit und jede Menge Koordination zwischen Teams. Die spannende Frage ist also nicht nur, ob Monorepos ein Comeback feiern, sondern ob sie heute, mit besserem Tooling und AI im Rücken, endlich ihr Versprechen einlösen.In dieser Episode sprechen wir mit Max Kless, Senior Software Engineer bei Nx, über den aktuellen Stand von Monorepos. Wir klären, was ein Monorepo eigentlich ist, warum Monorepo nicht gleich Monorepo ist und wieso ein pragmatischer, hybrider Ansatz für viele Teams sinnvoller ist als ein einziges gigantisches Repository. Außerdem schauen wir auf CI, Caching, Project Graphs, Code Ownership, Plattform-Teams und die kulturelle Seite hinter dem Thema. Denn Monorepos sind nicht nur Architektur und Tooling, sondern auch Zusammenarbeit, Standards und ein bisschen Inner Source im Alltag.Besonders spannend wird es bei AI, LLMs und Coding Agents. Wenn mehr Kontext zu besserer Unterstützung führt, werden Monorepos plötzlich wieder hochrelevant. Wir diskutieren, warum ein gemeinsamer Code-Kontext für AI-Systeme ein echter Hebel sein kann, wo die Grenzen liegen und worauf du bei einer Einführung achten solltest. Wenn du wissen willst, ob Monorepos 2026 mehr sind als alter Google-Glanz, dann bist du hier genau richtig.Bonus: Selbst Jenkins bekommt einen kleinen Ehrenmoment.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

Are advertisements not-so-secretly infiltrating your code reviews? This week on the Friday Deploy, Andrew and Ben break down the controversy over GitHub Copilot injecting promotional tips into pull requests and unpack the massive Anthropic code leak that exposed Claude Code's hidden features. The hosts also explore Shopify's strategy for cutting AI inference costs by 75x using smaller, self-hosted models. Finally, they discuss the game-changing Pretext rendering library, the cyclical hype of "dead" tech trends, and how agent-wielding "vibe maintainers" are rewriting the rules of open-source software.Read the guide: The APEX FrameworkFollow the show:Subscribe to our Substack Follow us on LinkedInSubscribe to our YouTube ChannelLeave us a ReviewFollow the hosts:Follow AndrewFollow BenFollow DanFollow today's stories:GitHub backs down, kills Copilot pull-request ads after backlashSoftware's Next Epoch: Our Investment in R.I.P. grepAnthropic accidentally leaked Claude Code's entire source. Here's what 512,000 lines revealShopify Cuts Inference Cost by 75x Using Qwen 3 for Merchant Data ExtractionPretext Does What CSS Can't — Measuring Text Before the DOM Even ExistsVibe MaintainerOFFERSStart Free Trial: Get started with LinearB's AI productivity platform for free.Book a Demo: Learn how you can ship faster, improve DevEx, and lead with confidence in the AI era.LEARN ABOUT LINEARBAI Code Reviews: Automate reviews to catch bugs, security risks, and performance issues before they hit production.AI & Productivity Insights: Go beyond DORA with AI-powered recommendations and dashboards to measure and improve performance.AI-Powered Workflow Automations: Use AI-generated PR descriptions, smart routing, and other automations to reduce developer toil.MCP Server: Interact with your engineering data using natural language to build custom reports and get answers on the fly.

Dominik Rose spricht in dieser Podcastfolge mit Tim über AI in der Produktentwicklung und darüber, wie sich der Alltag von Produktteams verändert, wenn moderne AI Werkzeuge auf die Realität eines großen Corporate Umfelds treffen. Dominik ist Senior Vice President Product bei LeanIX, einem Unternehmen aus Bonn, das inzwischen Teil von SAP ist und Software für Enterprise Architecture Management entwickelt. Gemeinsam schauen sie auf konkrete KI-Erfahrungen aus der Praxis und darauf, wie AI die Produktentwicklung in großen Organisationen tatsächlich beeinflusst. AI in der Produktentwicklung wirkt in vielen Diskussionen wie ein Thema aus der Startup Welt. Doch auch im Corporate Umfeld verändert sich gerade sehr viel. Bei SAP LeanIX zeigt sich das in der täglichen Arbeit von Produktmanagement, UX und Engineering. Neue Werkzeuge und Modelle verändern, wie Software entsteht und wie Teams zusammenarbeiten. Entwickler nutzen zunehmend AI Unterstützung beim Schreiben, Prüfen und Verbessern von Code. Ein großer Teil der Pull Requests wird bereits durch AI Systeme begleitet. Das führt dazu, dass Delivery deutlich schneller wird und sich die Erwartungen an Teams verändern. Diese Entwicklung hat spürbare Auswirkungen auf die Rollen in der Produktentwicklung. Wenn Software schneller entsteht, verschiebt sich der Fokus stärker auf Problemverständnis, Kundennähe und Produktentscheidungen. Gerade im Corporate Kontext bleibt Continuous Discovery deshalb ein zentraler Bestandteil guter Produktarbeit. Produktmanager und Designer arbeiten weiterhin eng mit Kunden zusammen, sammeln Feedback und bringen diese Erkenntnisse direkt in die Weiterentwicklung des Produkts ein. AI in der Produktentwicklung beschleunigt vieles, ersetzt aber nicht das Verständnis für Kundenprobleme. Gleichzeitig verändert AI auch die Art, wie Produktteams Ideen ausprobieren. Prototypen entstehen heute deutlich schneller. Teams können Konzepte direkt visualisieren und gemeinsam mit Kunden weiterentwickeln. Das führt zu einer engeren Verbindung zwischen Discovery und Delivery. Feedback fließt schneller zurück ins Team und Entscheidungen lassen sich auf einer deutlich besseren Grundlage treffen. Auch auf Produktebene stellt AI Unternehmen vor neue Fragen. Kunden erwarten zunehmend intelligente Funktionen und neue Interaktionsmöglichkeiten. Gleichzeitig darf der eigentliche Kern eines Produkts nicht verloren gehen. Für Unternehmen wie LeanIX bedeutet das, AI gezielt dort einzusetzen, wo sie echten Mehrwert für Nutzer schafft, statt lediglich neue Funktionen zu ergänzen, weil die Technologie verfügbar ist. Besonders deutlich wird der Wandel beim Blick auf den Markt. AI in der Produktentwicklung verändert nicht nur interne Arbeitsweisen, sondern auch Wettbewerbslandschaften. Neue Anbieter tauchen auf, Kategorien verschieben sich und bisherige Marktlogiken werden aufgebrochen. Produktteams müssen deshalb genauer beobachten, wie sich Kundenbedürfnisse entwickeln und welche Probleme in Zukunft wirklich relevant bleiben. Gerade im Corporate Umfeld entsteht dabei eine besondere Spannung. Einerseits verlangen Governance, Sicherheit und Prozesse nach Stabilität. Andererseits entwickeln sich AI Technologien in rasantem Tempo weiter. Organisationen müssen lernen, beides miteinander zu verbinden. Teams brauchen Raum zum Experimentieren und gleichzeitig klare Rahmenbedingungen, die den Einsatz neuer Technologien verantwortungsvoll ermöglichen. Am Ende bleibt eine Erkenntnis besonders wichtig: AI in der Produktentwicklung macht viele Dinge schneller und leichter zugänglich. Auch in einem Corporate-Umfeld. Der eigentliche Kern erfolgreicher Produktarbeit bleibt jedoch unverändert. Produktmenschen müssen ihre Kunden verstehen, Märkte beobachten und Entscheidungen treffen, die langfristig Wirkung entfalten. Wer sich aktiv mit den neuen Möglichkeiten beschäftigt und gleichzeitig nah an den echten Problemen der Nutzer bleibt, hat in dieser Phase eine große Chance, bessere Produkte zu bauen.

Pourquoi openclaw votre futur meilleur ami est aussi votre double numérique Openclaw va au-delà du simple chatbot Face à l'avalanche de promesses non tenues dans le domaine de l'intelligence artificielle, on peut rester sur sa faim concernant les applications concrète. Openclaw surgit comme une rupture brutale. Crée par Peter Steinberger en open source. Ce créateur est très prolifique sur github et là il a trouvé la killer app pour l'intelligence artificielle. Nous assistons peut-être à la mort du chatbot passif au profit de l’agent autonome, un outil doté de “mains” pour agir et d’une mémoire pour apprendre. En seulement 19 jours, ce projet open source a accumulé plus de 94 600 étoiles sur GitHub, une explosion qui témoigne du succès rencontré. Pour faire simple vous pouvez donner à Openclaw le contrôle total de votre vie vie votre PC et vos comptes. Openclaw En résumé avec Openclaw vous donnez les clé du camion à un robot intelligent qui va assumer vos taches à votre place. A peine sorti, déjà un procès pour Openclaw En une semaine le service a changé deux fois de nom. Au départ le nom était Clowdbot. Mais Claude IA a trouvé que c’était trop proche de son nom et a engagé un procès. Le service a changé pour Moltbot cette semaine, et au moment ou cet article est rédigé le nom vient de changer pour Openbot. L’autonomie réelle : Quand l’IA arrête de suggérer pour commencer à agir La véritable force de Openclaw réside dans sa boucle agentique, un concept qui lui permet d’improviser des plans complexes pour atteindre un objectif précis. Pour lui donner les consignes vous passez par une messagerie type telegam ou whatsapp. Ensuite, en utilisant seul les ressources du PC, il va réaliser la tache. Si il a besoin d’un mot de passe vous lui donnez ou il va le chercher dans votre coffre fort de mot de passe. Imaginez les possibilités. Contrairement aux assistants classiques, il peut créer de lui-même un tableau Excel ou prendre l’initiative de contacter un restaurant par téléphone via une synthèse vocale, ou télécharger des documents pour vous. Si une interface numérique lui résiste, l’agent explore des voies alternatives, comme l’utilisation de logiciels pour accéder au résultat. Cette capacité à naviguer entre les outils pour résoudre un problème imprévu marque une étape majeure vers une IA qui n’est plus un outil, mais un partenaire. “Il ne s’agit pas de routines préprogrammées. Ce sont des comportements dynamiques nés d’une boucle agentique qui prend un objectif et improvise un plan, saisissant tous les outils nécessaires à son exécution.” — Jason Meller, 1Password. A chaque tache réussie, il apprend pour toujours comment la réaliser et sera plus efficace la fois suivante. Pour fonctionner pas besoin d’un centre de data entier, un mini PC suffit ou un Raspberry pi. vous pouvez l’installer vous même. Vous le connectez sur une IA comme Antropic ou Chat GPT, et c’est parti. Le “Personal OS” : Reprendre le contrôle face aux géants du SaaS Openclaw incarne une vision où l’utilisateur redevient le maître de son infrastructure en transformant un simple mini PC en un système d’exploitation personnel dopé à l’IA. Cette approche “local-first” permet en partie de s’affranchir des grandes entreprises technologiques tout en garantissant un contrôle total sur les flux de données. En hébergeant l’agent sur sa propre machine, l’utilisateur dispose d’une puissance de calcul et d’une confidentialité que les solutions SaaS centralisées ne peuvent égaler. Attention tout de même. accédant ensuite aux outils GAFAM et devant utiliser les service d’une IA du marché, au final Openclaw vous met bien en contact avec eux. Cette transition vers une autonomie locale est perçue par la communauté comme une libération philosophique et technique majeure. Pour beaucoup de pionniers, faire tourner cet agent sur son propre matériel procure une sensation oubliée de maîtrise totale sur la “pile” technologique. C’est le passage symbolique de Windows à Linux d’il y a vingt ans, où l’utilisateur reprend enfin la souveraineté de son espace numérique personnel. Cela explique un partie du succès fulgurant du service. Le pacte faustien : La puissance brute au prix d’une sécurité fragile L’efficacité redoutable de Openclaw repose sur une architecture qui ignore délibérément certaines barrières de sécurité conventionnelles pour favoriser une action sans entrave. Les clés API et les journaux de session sont stockés en texte clair. Cette vulnérabilité n’est pas théorique : plus de 1 600 instances ont déjà été détectées sur Shodan via le port 18789, exposées sans défense sur le web. Beaucoup d’utilisateurs ont installé Openclaw sur leur propre PC sans le sécuriser d’avantage. Un attaquant ne se contente pas de voler des clés techniques ; il s’empare de la matière première nécessaire pour usurper totalement votre identité numérique. Grâce à la mémoire à long terme de Openclaw, un intrus peut analyser vos relations, vos projets en cours et votre style rédactionnel unique. Pour mitiger ces risques , le projet propose désormais un cloisonnement via Docker Sandboxing afin d’isoler l’exécution des commandes. Il est conseillé de l’installer sur un serveur dédié et sécuriser, voire chez un cloud provider. “Il n’existe pas de configuration ‘parfaitement sécurisée’.” — Peter Steinberger, créateur de Openclaw. L’identité de l’agent : Recruter une IA comme un nouvel employé Pour sécuriser le service, il devient crucial de traiter l’agent IA comme une entité propre plutôt que comme une simple application installée. Au lieu de lui accorder des accès globaux permanents, la stratégie consiste à lui donner une identité distincte, avec son propre compte email et ses propres accès réservés. Cette approche permet de médiatiser l’accès en temps réel, garantissant que chaque action de l’IA est validée dynamiquement en fonction du contexte immédiat. Surtout vous ne créez pas votre double numérique et ses failles de sécurité. Il a ses comptes vous avez les vôtres et vous pouvez lui octroyer des droits utilisateur mais pas administrateur. L’intégration de fonctionnalités comme Voice Wake et le Talk Mode, propulsées par ElevenLabs, rend cette métaphore de l’employé singulièrement tangible. L’IA n’est plus un texte froid sur un écran, mais une présence vocale capable d’interagir par la parole avec son environnement. Cette incarnation renforce la nécessité d’une identité propre pour l’agent, lui permettant de gérer ses outils quotidiens comme une recrue humaine au sein d’une équipe.Car vous lui parlez mais il vous répond en permanence. Applications concrètes de Openclaw Openclaw est capable d’automatiser une vaste gamme de tâches en prenant le contrôle d’un ordinateur et en interagissant avec divers services via un cycle agentique. Par exemple, il peut gérer votre vie quotidienne en nettoyant votre boîte de réception, en envoyant des e-mails, en organisant votre calendrier ou en effectuant votre enregistrement pour un vol via des applications de messagerie comme WhatsApp ou Telegram. Dites juste “aujourd’hui réponds à tous mes mails et télécharge toutes les pièces jointes” Il est également en mesure de gérer des démarches administratives complexes, telles que la soumission de demandes de remboursements de soins de santé ou la recherche de rendez-vous chez le médecin. pour cela il faudra lui donner votre compte et mot de passe Doctolib. Il va se faire passer pour vous. Dans un contexte professionnel, Openclaw peut se connecter de manière autonome à un outil de gestion pour télécharger une facture, puis naviguer vers une plateforme comptable pour y déposer le document. Pour les développeurs, il peut réaliser des tâches techniques avancées comme la création d’un tableau kanban fonctionnel en une heure ou la surveillance d’erreurs logicielles via des webhooks Sentry afin de résoudre des bugs et d’ouvrir des Pull Requests sur GitHub. Certains utilisateurs l’utilisent même pour créer des flux de travail réutilisables en analysant des vidéos YouTube pour en extraire des compétences spécifiques. C’est incroyable. Enfin, Openclaw peut interagir directement avec votre matériel informatique en éteignant votre PC à distance ou en pilotant des objets connectés. Il peut même improviser des solutions surprenantes, comme appeler directement un restaurant avec une voix synthétique pour obtenir une réservation lorsque les systèmes en ligne sont indisponibles. Conclusion : Vers une collaboration inévitable ou une obsolescence programmée ? Openclaw n’est pas seulement un utilitaire technique, c’est le portail vers un futur où la frontière entre le logiciel et votre personnalité devient étroite. Si ses capacités de mémorisation infinie et de correction autonome impressionnent, elles nous placent devant un dilemme éthique et sécuritaire fondamental. L’adoption de tels agents semble inévitable pour rester compétitif dans un monde numérique dont la cadence s’accélère. Reste à savoir si vous êtes réellement prêt à confier les clés de votre vie numérique à un assistant autonome, sachant qu’il peut aussi bien vous libérer que vous exposer. Par régis BAUDOUINThe post Openclaw votre futur meilleur ami first appeared on XY Magazine.

The inside story of how Claude Code with the proper scope provided a massive boost to drafting hundreds of pull requests, and debunking the myth on settling for compromises when prioritizing accessibility principles as demonstrated by a prominent leader in the visualization space. Plus we address candid feedback on last week's discussion on the tinyshinyserver package. Episode Links This week's curator: Jon Calder - @jonmcalder@fosstodon.org (Mastodon) & @jonmcalder (X/Twitter)Semi-automating 200 Pull Requests with Claude CodeHow to create a more accessible line chartEntire issue available at rweekly.org/2026-W04Supplement Resources Risk Conference hosted by the R Consortium (February 18-19, 2026) https://rconsortium.github.io/Risk_website/Supporting the show Use the contact page at https://serve.podhome.fm/custompage/r-weekly-highlights/contact to send us your feedbackR-Weekly Highlights on the Podcastindex.org - You can send a boost into the show directly in the Podcast Index. First, top-up with Alby, and then head over to the R-Weekly Highlights podcast entry on the index.A new way to think about value: https://value4value.infoGet in touch with us on social mediaEric Nantz: @rpodcast@podcastindex.social (Mastodon), @rpodcast.bsky.social (BlueSky) and @theRcast (X/Twitter)Mike Thomas: @mike_thomas@fosstodon.org (Mastodon), @mike-thomas.bsky.social (BlueSky), and @mike_ketchbrook (X/Twitter) Music credits powered by OCRemixDivinity - The Legend of Zelda: A Link to the Past - Nostalvania - https://ocremix.org/remix/OCR03442

Greg Foster, Co-founder and CTO of Graphite (recently acquired by Cursor), joins the podcast to discuss the massive shift occurring in software engineering: the move from maximizing "Inner Loop" speed (writing code) to solving "Outer Loop" bottlenecks (reviewing, testing, merging). With AI generating code faster than humans can review it, the traditional Pull Request model is under pressure. Greg explains how "Stacked PRs" and agentic review workflows are essential for high-performing teams, and why he believes the role of the software engineer is evolving into an "architect of agents." We also cover the strategic rationale behind the Graphite/Cursor merger, the controversial "PRs per engineer" metric, and why he predicts that by 2029, manual code writing will be near zero—but demand for engineers will be higher than ever.

 This week on the PHP Podcast, Eric and John talk about Welcome to 2026, Denmark stops postal services, New Laravel employee, PHPTek Early Bird ending soon, the pains of making a living off open source, PHP is Back according to Nuno, and more… Links from the show: Danish postal service to stop delivering letters after 400 years | Denmark | The Guardian MergePHP: Mastering Agentic PHP Development with MCP, Thu, Jan 8, 2026, 5:00 PM | Meetup https://x.com/wendell_adriel/status/2008168133362618776 PHP TEK 2026 Adam’s Morning Walk | We had six months left AI Code Reviews | CodeRabbit | Try for Free feat: add llms.txt endpoint for LLM-optimized documentation by quantizor · Pull Request #2388 · tailwindlabs/tailwindcss.com · GitHub Why PHP in 2026? https://laravelfortherestofus.com/ The PHP Podcast streams the recording of this podcast live, typically every Thursday at 3 PM PT. Come join us and subscribe to our YouTube channel. X: https://x.com/phparch Mastodon: https://phparch.social/@phparch Bluesky: https://bsky.app/profile/phparch.com Discord: https://discord.phparch.com Subscribe to our magazine: https://www.phparch.com/subscribe/ Host: Eric Van Johnson X: @shocm Mastodon: @eric@phparch.social Bluesky: @ericvanjohnson.bsky.social John Congdon X: @johncongdon Mastodon: @john@phparch.social Bluesky: @johncongdon.bsky.social Streams: Youtube Channel Twitch Partner This podcast is made a little better thanks to our partners Displace Infrastructure Management, Simplified Automate Kubernetes deployments across any cloud provider or bare metal with a single command. Deploy, manage, and scale your infrastructure with ease. https://displace.tech/ PHPScore Put Your Technical Debt on Autopay with PHPScore CodeRabbit Cut code review time & bugs in half instantly with CodeRabbit. Honeybadger.io Honeybadger helps you deploy with confidence and be your team's DevOps hero by combining error, uptime, and performance monitoring in one simple platform. Check it out at honeybadger.io Music Provided by Epidemic Sound https://www.epidemicsound.com/ The post The PHP Podcast 2026.01.08 appeared first on PHP Architect.

Wusstet ihr, dass neue PHP-Versionen nicht einfach wie ein automatischer Cronjob vom Himmel fallen, sondern von einem Team aus Menschen gebaut, koordiniert und durch Community-Diskussionen gestaltet werden? In diesem Deep Dive holen wir euch genau in diesen Maschinenraum: Wir sprechen über den Release von PHP 8.5 – aber weniger über einzelne Features als darüber, wie sie überhaupt in die Sprache hineinkommen und am Ende sicher bei euch auf dem Server landen.Unser Gast ist niemand Geringeres als Volker Dusch, einer der beiden Release Manager von PHP 8.5. Volker erzählt, wie man überhaupt in diese Rolle rutscht, warum dafür keine „Bewerbung beim PHP Elefanten“ nötig ist, welche Rolle Mailinglisten heute noch spielen und wieso ein Release Manager gleichzeitig Organisator, Gatekeeper, Kommunikator und manchmal auch Feuerwehr ist. Dabei geht es um Alphas, Betas, Release Candidates, Feature Freezes – und darum, wie man zwischen Stabilität, Bugfixes und neuen Ideen balanciert, ohne das halbe Internet kaputt zu machen.Wir schauen außerdem darauf, wie Features ihren Weg in die Sprache finden: von „unspektakulären“ Pull Requests bis hin zu großen RFCs, hitzigen Diskussions-Threads und demokratischen Abstimmungen, bei denen die Core-Contributors entscheiden, was PHP in Zukunft kann – und was bewusst draußen bleibt. Die PHP Foundation spielt dabei eine spannende, aber weniger allmächtige Rolle, als viele vermuten, und sorgt vor allem dafür, dass einige Menschen bezahlt Zeit haben, an der Sprache weiterzuschrauben, ohne dass Abkürzungen beim Qualitätsanspruch gemacht werden.Natürlich reden wir auch über Community: darüber, warum die PHP-Welt deutlich jünger und diverser ist, als ihr Ruf vermuten lässt, was Konferenzen, User Groups und Remote-Tools miteinander zu tun haben und weshalb ausgerechnet eine „alten“ Sprache wie PHP so viele Leute anzieht, die Bock auf Sprachdesign, Performance und Internals haben.Und weil es sonst nicht die programmier.bar wäre, streifen wir am Ende auch noch die Klassiker-Fragen rund um Generics, Async, Hacklang und die große „Kehren Firmen wie Meta irgendwann zurück zu Vanilla-PHP?“–Spekulation.Schreibt uns! Schickt uns eure Themenwünsche und euer Feedback: podcast@programmier.barFolgt uns! Bleibt auf dem Laufenden über zukünftige Folgen und virtuelle Meetups und beteiligt euch an Community-Diskussionen. BlueskyInstagramLinkedInMeetupYouTubeMusik: Hanimo

Dans cet épisode, Arnaud et Guillaume discutent des dernières évolutions dans le monde de la programmation, notamment les nouveautés de Java 25, JUnit 6, et Jackson 3. Ils abordent également les récents développements en IA, les problèmes rencontrés dans le cloud, et l'état actuel de React et du web. Dans cette conversation, les intervenants abordent divers sujets liés à la technologie, notamment les spécifications de Wasteme, l'utilisation des UUID dans les bases de données, l'approche RAG en intelligence artificielle, les outils MCP, et la création d'images avec Nano Banana. Ils discutent également des complexités du format YAML, des récents dramas dans la communauté Ruby, de l'importance d'une bonne documentation, des politiques de retour au bureau, et des avancées de Cloud Code. Enfin, ils évoquent l'initiative de cafés IA pour démystifier l'intelligence artificielle. Enregistré le 24 octobre 2025 Téléchargement de l'épisode LesCastCodeurs-Episode-331.mp3 ou en vidéo sur YouTube. News Langages GraalVM se détache du release train de Java https://blogs.oracle.com/java/post/detaching-graalvm-from-the-java-ecosystem-train Un article de Loic Mathieu sur Java 25 et ses nouvelles fonctionalités https://www.loicmathieu.fr/wordpress/informatique/java-25-whats-new/ Sortie de Groovy 5.0 ! https://groovy-lang.org/releasenotes/groovy-5.0.html Groovy 5: Évolution des versions précédentes, nouvelles fonctionnalités et simplification du code. Compatibilité JDK étendue: Full support JDK 11-25, fonctionnalités JDK 17-25 disponibles sur les JDK plus anciens. Extension majeure des méthodes: Plus de 350 méthodes améliorées, opérations sur tableaux jusqu'à 10x plus rapides, itérateurs paresseux. Améliorations des transformations AST: Nouveau @OperatorRename, génération automatique de @NamedParam pour @MapConstructor et copyWith. REPL (groovysh) modernisé: Basé sur JLine 3, support multi-plateforme, coloration syntaxique, historique et complétion. Meilleure interopérabilité Java: Pattern Matching pour instanceof, support JEP-512 (fichiers source compacts et méthodes main d'instance). Standards web modernes: Support Jakarta EE (par défaut) et Javax EE (héritage) pour la création de contenu web. Vérification de type améliorée: Contrôle des chaînes de format plus robuste que Java. Additions au langage: Génération d'itérateurs infinis, variables d'index dans les boucles, opérateur d'implication logique ==>. Améliorations diverses: Import automatique de java.time.**, var avec multi-assignation, groupes de capture nommés pour regex (=~), méthodes utilitaires de graphiques à barres ASCII. Changements impactants: Plusieurs modifications peuvent nécessiter une adaptation du code existant (visibilité, gestion des imports, comportement de certaines méthodes). **Exigences JDK*: Construction avec JDK17+, exécution avec JDK11+. Librairies Intégration de LangChain4j dans ADK pour Java, permettant aux développeurs d'utiliser n'importe quel LLM avec leurs agents ADK https://developers.googleblog.com/en/adk-for-java-opening-up-to-third-party-language-models-via-langchain4j-integration/ ADK pour Java 0.2.0 : Nouvelle version du kit de développement d'agents de Google. Intégration LangChain4j : Ouvre ADK à des modèles de langage tiers. Plus de choix de LLM : En plus de Gemini et Claude, accès aux modèles d'OpenAI, Anthropic, Mistral, etc. Modèles locaux supportés : Utilisation possible de modèles via Ollama ou Docker Model Runner. Améliorations des outils : Création d'outils à partir d'instances d'objets, meilleur support asynchrone et contrôle des boucles d'exécution. Logique et mémoire avancées : Ajout de callbacks en chaîne et de nouvelles options pour la gestion de la mémoire et le RAG (Retrieval-Augmented Generation). Build simplifié : Introduction d'un POM parent et du Maven Wrapper pour un processus de construction cohérent. JUnit 6 est sorti https://docs.junit.org/6.0.0/release-notes/ :sparkles: Java 17 and Kotlin 2.2 baseline :sunrise_over_mountains: JSpecify nullability annotations :airplane_departure: Integrated JFR support :suspension_railway: Kotlin suspend function support :octagonal_sign: Support for cancelling test execution :broom: Removal of deprecated APIs JGraphlet, une librairie Java sans dépendances pour créer des graphes de tâches à exécuter https://shaaf.dev/post/2025-08-25-think-in-graphs-not-just-chains-jgraphlet-for-taskpipelines/ JGraphlet: Bibliothèque Java légère (zéro-dépendance) pour construire des pipelines de tâches. Principes clés: Simplicité, basée sur un modèle d'exécution de graphe. Tâches: Chaque tâche a une entrée/sortie, peut être asynchrone (Task) ou synchrone (SyncTask). Pipeline: Un TaskPipeline construit et exécute le graphe, gère les I/O. Modèle Graph-First: Le flux de travail est un Graphe Orienté Acyclique (DAG). Définition des tâches comme des nœuds, des connexions comme des arêtes. Support naturel des motifs fan-out et fan-in. API simple: addTask("id", task), connect("fromId", "toId"). Fan-in: Une tâche recevant plusieurs entrées reçoit une Map (clés = IDs des tâches parentes). Exécution: pipeline.run(input) retourne un CompletableFuture (peut être bloquant via .join() ou asynchrone). Cycle de vie: TaskPipeline est AutoCloseable, garantissant la libération des ressources (try-with-resources). Contexte: PipelineContext pour partager des données/métadonnées thread-safe entre les tâches au sein d'une exécution. Mise en cache: Option de mise en cache pour les tâches afin d'éviter les re-calculs. Au tour de Microsoft de lancer son (Microsoft) Agent Framework, qui semble être une fusion / réécriture de AutoGen et de Semnatic Kernel https://x.com/pyautogen/status/1974148055701028930 Plus de détails dans le blog post : https://devblogs.microsoft.com/foundry/introducing-microsoft-agent-framework-the-open-source-engine-for-agentic-ai-apps/ SDK & runtime open-source pour systèmes multi-agents sophistiqués. Unifie Semantic Kernel et AutoGen. Piliers : Standards ouverts (MCP, A2A, OpenAPI) et interopérabilité. Passerelle recherche-production (patterns AutoGen pour l'entreprise). Extensible, modulaire, open-source, connecteurs intégrés. Prêt pour la production (observabilité, sécurité, durabilité, "human in the loop"). Relation SK/AutoGen : S'appuie sur eux, ne les remplace pas, simplifie la migration. Intégrations futures : Alignement avec Microsoft 365 Agents SDK et Azure AI Foundry Agent Service. Sortie de Jackson 3.0 (bientôt les Jackson Five !!!) https://cowtowncoder.medium.com/jackson-3-0-0-ga-released-1f669cda529a Jackson 3.0.0 a été publié le 3 octobre 2025. Objectif : base propre pour le développement à long terme, suppression de la dette technique, architecture simplifiée, amélioration de l'ergonomie. Principaux changements : Baseline Java 17 requise (vs Java 8 pour 2.x). Group ID Maven et package Java renommés en tools.jackson pour la coexistence avec Jackson 2.x. (Exception: jackson-annotations ne change pas). Suppression de toutes les fonctionnalités @Deprecated de Jackson 2.x et renommage de plusieurs entités/méthodes clés. Modification des paramètres de configuration par défaut (ex: FAIL_ON_UNKNOWN_PROPERTIES désactivé). ObjectMapper et TokenStreamFactory sont désormais immutables, la configuration se fait via des builders. Passage à des exceptions de base non vérifiées (JacksonException) pour plus de commodité. Intégration des "modules Java 8" (pour les noms de paramètres, Optional, java.time) directement dans l'ObjectMapper par défaut. Amélioration du modèle d'arbre JsonNode (plus de configurabilité, meilleure gestion des erreurs). Testcontainers Java 2.0 est sorti https://github.com/testcontainers/testcontainers-java/releases/tag/2.0.0 Removed JUnit 4 support -> ups Grails 7.0 est sortie, avec son arrivée à la fondation Apache https://grails.apache.org/blog/2025-10-18-introducing-grails-7.html Sortie d'Apache Grails 7.0.0 annoncée le 18 octobre 2025. Grails est devenu un projet de premier niveau (TLP) de l'Apache Software Foundation (ASF), graduant d'incubation. Mise à jour des dépendances vers Groovy 4.0.28, Spring Boot 3.5.6, Jakarta EE. Tout pour bien démarrer et développer des agents IA avec ADK pour Java https://glaforge.dev/talks/2025/10/22/building-ai-agents-with-adk-for-java/ Guillaume a partagé plein de resources sur le développement d'agents IA avec ADK pour Java Un article avec tous les pointeurs Un slide deck et l'enregistrement vidéo de la présentation faite lors de Devoxx Belgique Un codelab avec des instructions pour démarrer et créer ses premiers agents Plein d'autres samples pour s'inspirer et voir les possibilités offertes par le framework Et aussi un template de projet sur GitHub, avec un build Maven et un premier agent d'exemple Cloud Internet cassé, du moins la partie hébergée par AWS #hugops https://www.theregister.com/2025/10/20/aws_outage_amazon_brain_drain_corey_quinn/ Panne majeure d'AWS (région US-EAST-1) : problème DNS affectant DynamoDB, service fondamental, causant des défaillances en cascade de nombreux services internet. Réponse lente : 75 minutes pour identifier la cause profonde; la page de statut affichait initialement "tout va bien". Cause sous-jacente principale : "fuite des cerveaux" (départ d'ingénieurs AWS seniors). Perte de connaissances institutionnelles : des décennies d'expertise critique sur les systèmes AWS et les modes de défaillance historiques parties avec ces départs. Prédictions confirmées : un ancien d'AWS avait anticipé une augmentation des pannes majeures en 2024. Preuves de la perte de talents : Plus de 27 000 licenciements chez Amazon (2022-2025). Taux élevé de "départs regrettés" (69-81%). Mécontentement lié à la politique de "Return to Office" et au manque de reconnaissance de l'expertise. Conséquences : les nouvelles équipes, plus réduites, manquent de l'expérience nécessaire pour prévenir les pannes ou réduire les temps de récupération. Perspective : Le marché pourrait pardonner cette fois, mais le problème persistera, rendant les futurs incidents plus probables. Web React a gagné "par défaut" https://www.lorenstew.art/blog/react-won-by-default/ React domine par défaut, non par mérite technique, étouffant ainsi l'innovation front-end. Choix par réflexe ("tout le monde connaît React"), freinant l'évaluation d'alternatives potentiellement supérieures. Fondations techniques de React (V-DOM, complexité des Hooks, Server Components) vues comme des contraintes actuelles. Des frameworks innovants (Svelte pour la compilation, Solid pour la réactivité fine, Qwik pour la "resumability") offrent des modèles plus performants mais sont sous-adoptés. La monoculture de React génère une dette technique (runtime, réconciliation) et centre les compétences sur le framework plutôt que sur les fondamentaux web. L'API React est complexe, augmentant la charge cognitive et les risques de bugs, contrairement aux alternatives plus simples. L'effet de réseau crée une "prison": offres d'emploi spécifiques, inertie institutionnelle, leaders choisissant l'option "sûre". Nécessité de choisir les frameworks selon les contraintes du projet et le mérite technique, non par inertie. Les arguments courants (maturité de l'écosystème, recrutement, bibliothèques, stabilité) sont remis en question; une dépendance excessive peut devenir un fardeau. La monoculture ralentit l'évolution du web et détourne les talents, nuisant à la diversité essentielle pour un écosystème sain et innovant. Promouvoir la diversité des frameworks pour un écosystème plus résilient et innovant. WebAssembly 3 est sortie https://webassembly.org/news/2025-09-17-wasm-3.0/ Data et Intelligence Artificielle UUIDv4 ou UUIDv7 pour vos clés primaires ? Ça dépend… surtout pour les bases de données super distribuées ! https://medium.com/google-cloud/understanding-uuidv7-and-its-impact-on-cloud-spanner-b8d1a776b9f7 UUIDv4 : identifiants entièrement aléatoires. Cause des problèmes de performance dans les bases de données relationnelles (ex: PostgreSQL, MySQL, SQL Server) utilisant des index B-Tree. Inserts aléatoires réduisent l'efficacité du cache, entraînent des divisions de pages et la fragmentation. UUIDv7 : nouveau standard conçu pour résoudre ces problèmes. Intègre un horodatage (48 bits) en préfixe de l'identifiant, le rendant ordonné temporellement et "k-sortable". Améliore la performance dans les bases B-Tree en favorisant les inserts séquentiels, la localité du cache et réduisant la fragmentation. Problème de UUIDv7 pour certaines bases de données distribuées et scalables horizontalement comme Spanner : La nature séquentielle d'UUIDv7 (via l'horodatage) crée des "hotspots d'écriture" (points chauds) dans Spanner. Spanner distribue les données en "splits" (partitions) basées sur les plages de clés. Les clés séquentielles concentrent les écritures sur un seul "split". Ceci empêche Spanner de distribuer la charge et de scaler les écritures, créant un goulot d'étranglement ("anti-pattern"). Quand ce n'est PAS un problème pour Spanner : Si le taux d'écriture total est inférieur à environ 3 500 écritures/seconde pour un seul "split". Le hotspot est "bénin" à cette échelle et n'entraîne pas de dégradation de performance. Solutions pour Spanner : Principe clé : S'assurer que la première partie de la clé primaire est NON séquentielle pour distribuer les écritures. UUIDv7 peut être utilisé, mais pas comme préfixe. Nouvelle conception ("greenfield") : ▪︎ Utiliser une clé primaire non-séquentielle (ex: UUIDv4 simple). Pour les requêtes basées sur le temps, créer un index secondaire sur la colonne d'horodatage, mais le SHARDER (ex: shardId) pour éviter les hotspots sur l'index lui-même. Migration (garder UUIDv7) : ▪︎ Ajouter un préfixe de sharding : Introduire une colonne `shard` calculée (ex: `MOD(ABS(FARM_FINGERPRINT(order_id_v7)), N)`) et l'utiliser comme PREMIER élément d'une clé primaire composite (`PRIMARY KEY (shard, order_id_v7)`). Réordonner les colonnes (si clé primaire composite existante) : Si la clé primaire est déjà composite (ex: (order_id_v7, tenant_id)), réordonner en (tenant_id, order_id_v7). Cela aide si tenant_id a une cardinalité élevée et distribue bien. (Un tenant_id très actif pourrait toujours nécessiter un préfixe de sharding supplémentaire). RAG en prod, comment améliorer la pertinence des résultats https://blog.abdellatif.io/production-rag-processing-5m-documents Démarrage rapide avec Langchain + Llamaindex: prototype fonctionnel, mais résultats de production jugés "subpar" par les utilisateurs. Ce qui a amélioré la performance (par ROI): Génération de requêtes: LLM crée des requêtes sémantiques et mots-clés multiples basées sur le fil de discussion pour une meilleure couverture. Reranking: La technique la plus efficace, modifie grandement le classement des fragments (chunks). Stratégie de découpage (Chunking): Nécessite beaucoup d'efforts, compréhension des données, création de fragments logiques sans coupures. Métadonnées à l'LLM: L'injection de métadonnées (titre, auteur) améliore le contexte et les réponses. Routage de requêtes: Détecte et traite les questions non-RAG (ex: résumer, qui a écrit) via API/LLM distinct. Outillage Créer un serveur MCP (mode HTTP Streamable) avec Micronaut et quelques éléments de comparaison avec Quarkus https://glaforge.dev/posts/2025/09/16/creating-a-streamable-http-mcp-server-with-micronaut/ Micronaut propose désormais un support officiel pour le protocole MCP. Exemple : un serveur MCP pour les phases lunaires (similaire à une version Quarkus pour la comparaison). Définition des outils MCP via les annotations @Tool et @ToolArg. Point fort : Micronaut gère automatiquement la validation des entrées (ex: @NotBlank, @Pattern), éliminant la gestion manuelle des erreurs. Génération automatique de schémas JSON détaillés pour les structures d'entrée/sortie grâce à @JsonSchema. Nécessite une configuration pour exposer les schémas JSON générés comme ressources statiques. Dépendances clés : micronaut-mcp-server-java-sdk et les modules json-schema. Testé avec l'inspecteur MCP et intégration avec l'outil Gemini CLI. Micronaut offre une gestion élégante des entrées/sorties structurées grâce à son support JSON Schema riche. Un agent IA créatif : comment utiliser le modèle Nano Banana pour générer et éditer des images (en Java, avec ADK) https://glaforge.dev/posts/2025/09/22/creative-ai-agents-with-adk-and-nano-banana/ Modèles de langage (LLM) deviennent multimodaux : traitent diverses entrées (texte, images, vidéo, audio). Nano Banana (gemini-2.5-flash-image-preview) : modèle Gemini, génère et édite des images, pas seulement du texte. ADK (Agent Development Kit pour Java) : pour configurer des agents IA créatifs utilisant ce type de modèle. Application : Base pour des workflows créatifs complexes (ex: agent de marketing, enchaînement d'agents pour génération d'assets). Un vieil article (6 mois) qui illustre les problèmes du format de fichier YAML https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-from-hell YAML est extrêmement complexe malgré son objectif de convivialité humaine. Spécification volumineuse et versionnée (YAML 1.1, 1.2 diffèrent significativement). Comportements imprévisibles et "pièges" (footguns) courants : Nombres sexagésimaux (ex: 22:22 parsé comme 1342 en YAML 1.1). Tags (!.git) pouvant mener à des erreurs ou à l'exécution de code arbitraire. "Problème de la Norvège" : no interprété comme false en YAML 1.1. Clés non-chaînes de caractères (on peut devenir une clé booléenne True). Nombres accidentels si non-guillemets (ex: 10.23 comme flottant). La coloration syntaxique n'est pas fiable pour détecter ces subtilités. Le templating de documents YAML est une mauvaise idée, source d'erreurs et complexe à gérer. Alternatives suggérées : TOML : Similaire à YAML mais plus sûr (chaînes toujours entre guillemets), permet les commentaires. JSON avec commentaires (utilisé par VS Code), mais moins répandu. Utiliser un sous-ensemble simple de YAML (difficile à faire respecter). Générer du JSON à partir de langages de programmation plus puissants : ▪︎ Nix : Excellent pour l'abstraction et la réutilisation de configuration. Python : Facilite la création de JSON avec commentaires et logique. Gros binz dans la communauté Ruby, avec l'influence de grosses boîtes, et des pratiques un peu douteuses https://joel.drapper.me/p/rubygems-takeover/ Méthodologies Les qualités d'une bonne documentation https://leerob.com/docs Rapidité Chargement très rapide des pages (préférer statique). Optimisation des images, polices et scripts. Recherche ultra-rapide (chargement et affichage des résultats). Lisibilité Concise, éviter le jargon technique. Optimisée pour le survol (gras, italique, listes, titres, images). Expérience utilisateur simple au départ, complexité progressive. Multiples exemples de code (copier/coller). Utilité Documenter les solutions de contournement (workarounds). Faciliter le feedback des lecteurs. Vérification automatisée des liens morts. Matériel d'apprentissage avec un curriculum structuré. Guides de migration pour les changements majeurs. Compatible IA Trafic majoritairement via les crawlers IA. Préférer cURL aux "clics", les prompts aux tutoriels. Barre latérale "Demander à l'IA" référençant la documentation. Prêt pour les agents Faciliter le copier/coller de contenu en Markdown pour les chatbots. Possibilité de visualiser les pages en Markdown (ex: via l'URL). Fichier llms.txt comme répertoire de fichiers Markdown. Finition soignée Zones de clic généreuses (boutons, barres latérales). Barres latérales conservant leur position de défilement et état déplié. Bons états actifs/survol. Images OG dynamiques. Titres/sections lienables avec ancres stables. Références et liens croisés entre guides, API, exemples. Balises méta/canoniques pour un affichage propre dans les moteurs de recherche. Localisée Pas de /en par défaut dans l'URL. Routage côté serveur pour la langue. Localisation des chaînes statiques et du contenu. Responsive Excellents menus mobiles / support Safari iOS. Info-bulles sur desktop, popovers sur mobile. Accessible Lien "ignorer la navigation" vers le contenu principal. Toutes les images avec des balises alt. Respect des paramètres système de mouvement réduit. Universelle Livrer la documentation "en tant que code" (JSDoc, package). Livrer via des plateformes comme Context7, ou dans node_modules. Fichiers de règles (ex: AGENTS.md) avec le produit. Évaluations et modèles spécifiques recommandés pour le produit. Loi, société et organisation Microsoft va imposer une politique de Return To Office https://www.businessinsider.com/microsoft-execs-explain-rto-mandate-in-internal-meeting-2025-9 Microsoft impose 3 jours de présence au bureau par semaine à partir de février 2026, débutant par la région de Seattle Le CEO Satya Nadella explique que le télétravail a affaibli les liens sociaux nécessaires à l'innovation Les dirigeants citent des données internes montrant que les employés présents au bureau "prospèrent" davantage L'équipe IA de Microsoft doit être présente 4 jours par semaine, règles plus strictes pour cette division stratégique Les employés peuvent demander des exceptions jusqu'au 19 septembre 2025 pour trajets complexes ou absence d'équipe locale Amy Coleman (RH) affirme que la collaboration en personne améliore l'énergie et les résultats, surtout à l'ère de l'IA La politique s'appliquera progressivement aux 228 000 employés dans le monde après les États-Unis Les réactions sont mitigées, certains employés critiquent la perte d'autonomie et les bureaux inadéquats Microsoft rattrape ses concurrents tech qui ont déjà imposé des retours au bureau plus stricts Cette décision intervient après 15 000 licenciements en 2025, créant des tensions avec les employés Comment Claude Code est né ? (l'histoire de sa création) https://newsletter.pragmaticengineer.com/p/how-claude-code-is-built Claude Code : outil de développement "AI-first" créé par Boris Cherny, Sid Bidasaria et Cat Wu. Performance impressionnante : 500M$ de revenus annuels, utilisation multipliée par 10 en 3 mois. Adoption interne massive : Plus de 80% des ingénieurs d'Anthropic l'utilisent quotidiennement, y compris les data scientists. Augmentation de productivité : 67% d'augmentation des Pull Requests (PR) par ingénieur malgré le doublement de l'équipe. Origine : Commande CLI simple évoluant vers un outil accédant au système de fichiers, exploitant le "product overhang" du modèle Claude. Raison du lancement public : Apprendre sur la sécurité et les capacités des modèles d'IA. Pile technologique "on distribution" : TypeScript, React (avec Ink), Yoga, Bun. Choisie car le modèle Claude est déjà très performant avec ces technologies. "Claude Code écrit 90% de son propre code" : Le modèle prend en charge la majeure partie du développement. Architecture légère : Simple "shell" autour du modèle Claude, minimisant la logique métier et le code (suppression constante de code superflu). Exécution locale : Privilégiée pour sa simplicité, sans virtualisation. Sécurité : Système de permissions granulaire demandant confirmation avant chaque action potentiellement dangereuse (ex: suppression de fichiers). Développement rapide : Jusqu'à 100 releases internes/jour, 1 release externe/jour. 5 Pull Requests/ingénieur/jour. Prototypage ultra-rapide (ex: 20+ prototypes d'une fonctionnalité en quelques heures) grâce aux agents IA. Innovation UI/UX : Redéfinit l'expérience du terminal grâce à l'interaction LLM, avec des fonctionnalités comme les sous-agents, les styles de sortie configurables, et un mode "Learning". Le 1er Café IA publique a Paris https://www.linkedin.com/pulse/my-first-caf%25C3%25A9-ia-paris-room-full-curiosity-an[…]o-goncalves-r9ble/?trackingId=%2FPHKdAimR4ah6Ep0Qbg94w%3D%3D Conférences La liste des conférences provenant de Developers Conferences Agenda/List par Aurélie Vache et contributeurs : 30-31 octobre 2025 : Agile Tour Bordeaux 2025 - Bordeaux (France) 30-31 octobre 2025 : Agile Tour Nantais 2025 - Nantes (France) 30 octobre 2025-2 novembre 2025 : PyConFR 2025 - Lyon (France) 4-7 novembre 2025 : NewCrafts 2025 - Paris (France) 5-6 novembre 2025 : Tech Show Paris - Paris (France) 5-6 novembre 2025 : Red Hat Summit: Connect Paris 2025 - Paris (France) 6 novembre 2025 : dotAI 2025 - Paris (France) 6 novembre 2025 : Agile Tour Aix-Marseille 2025 - Gardanne (France) 7 novembre 2025 : BDX I/O - Bordeaux (France) 12-14 novembre 2025 : Devoxx Morocco - Marrakech (Morocco) 13 novembre 2025 : DevFest Toulouse - Toulouse (France) 15-16 novembre 2025 : Capitole du Libre - Toulouse (France) 19 novembre 2025 : SREday Paris 2025 Q4 - Paris (France) 19-21 novembre 2025 : Agile Grenoble - Grenoble (France) 20 novembre 2025 : OVHcloud Summit - Paris (France) 21 novembre 2025 : DevFest Paris 2025 - Paris (France) 24 novembre 2025 : Forward Data & AI Conference - Paris (France) 27 novembre 2025 : DevFest Strasbourg 2025 - Strasbourg (France) 28 novembre 2025 : DevFest Lyon - Lyon (France) 1-2 décembre 2025 : Tech Rocks Summit 2025 - Paris (France) 4-5 décembre 2025 : Agile Tour Rennes - Rennes (France) 5 décembre 2025 : DevFest Dijon 2025 - Dijon (France) 9-11 décembre 2025 : APIdays Paris - Paris (France) 9-11 décembre 2025 : Green IO Paris - Paris (France) 10-11 décembre 2025 : Devops REX - Paris (France) 10-11 décembre 2025 : Open Source Experience - Paris (France) 11 décembre 2025 : Normandie.ai 2025 - Rouen (France) 14-17 janvier 2026 : SnowCamp 2026 - Grenoble (France) 29-31 janvier 2026 : Epitech Summit 2026 - Paris - Paris (France) 2-5 février 2026 : Epitech Summit 2026 - Moulins - Moulins (France) 2-6 février 2026 : Web Days Convention - Aix-en-Provence (France) 3 février 2026 : Cloud Native Days France 2026 - Paris (France) 3-4 février 2026 : Epitech Summit 2026 - Lille - Lille (France) 3-4 février 2026 : Epitech Summit 2026 - Mulhouse - Mulhouse (France) 3-4 février 2026 : Epitech Summit 2026 - Nancy - Nancy (France) 3-4 février 2026 : Epitech Summit 2026 - Nantes - Nantes (France) 3-4 février 2026 : Epitech Summit 2026 - Marseille - Marseille (France) 3-4 février 2026 : Epitech Summit 2026 - Rennes - Rennes (France) 3-4 février 2026 : Epitech Summit 2026 - Montpellier - Montpellier (France) 3-4 février 2026 : Epitech Summit 2026 - Strasbourg - Strasbourg (France) 3-4 février 2026 : Epitech Summit 2026 - Toulouse - Toulouse (France) 4-5 février 2026 : Epitech Summit 2026 - Bordeaux - Bordeaux (France) 4-5 février 2026 : Epitech Summit 2026 - Lyon - Lyon (France) 4-6 février 2026 : Epitech Summit 2026 - Nice - Nice (France) 12-13 février 2026 : Touraine Tech #26 - Tours (France) 26-27 mars 2026 : SymfonyLive Paris 2026 - Paris (France) 31 mars 2026 : ParisTestConf - Paris (France) 16-17 avril 2026 : MiXiT 2026 - Lyon (France) 22-24 avril 2026 : Devoxx France 2026 - Paris (France) 23-25 avril 2026 : Devoxx Greece - Athens (Greece) 6-7 mai 2026 : Devoxx UK 2026 - London (UK) 22 mai 2026 : AFUP Day 2026 Lille - Lille (France) 22 mai 2026 : AFUP Day 2026 Paris - Paris (France) 22 mai 2026 : AFUP Day 2026 Bordeaux - Bordeaux (France) 22 mai 2026 : AFUP Day 2026 Lyon - Lyon (France) 17 juin 2026 : Devoxx Poland - Krakow (Poland) 4 septembre 2026 : JUG Summer Camp 2026 - La Rochelle (France) 17-18 septembre 2026 : API Platform Conference 2026 - Lille (France) 5-9 octobre 2026 : Devoxx Belgium - Antwerp (Belgium) Nous contacter Pour réagir à cet épisode, venez discuter sur le groupe Google https://groups.google.com/group/lescastcodeurs Contactez-nous via X/twitter https://twitter.com/lescastcodeurs ou Bluesky https://bsky.app/profile/lescastcodeurs.com 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/

Blockiert dein Code Review gerade mal wieder den Release oder ist es der unsichtbare Klebstoff, der Wissen im Team verteilt? In dieser Episode gehen wir der Frage auf den Grund, warum Reviews weit mehr sind als ein einfaches “looks good to me” und was sie mit sozialer Interaktion, Teamdynamik und Wissensverteilung zu tun haben. Wir sprechen mit Prof. Michael Dorner, Professor für Software Engineering an der TH Nürnberg, der seit Jahren zur Rolle von Code Reviews in der Softwareentwicklung forscht: mit Code Review Daten von Microsoft, Spotify oder trivago. Überall zeigt sich: Pull Requests sind mehr als technische Checks, sie sind Kommunikationsnetzwerke. Gemeinsam beleuchten wir, warum Tooling oft zweitrangig ist, wie sich Review-Praktiken historisch entwickelt haben und was das alles mit Ownership, Architektur und sogar Steuern zu tun hat. Ein Blick auf Code Reviews, der dir definitiv eine neue Perspektive eröffnet.Bonus: Wir erklären, warum alle Informatiker Doktoren auch Philosophen sind ;)Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

Fedora 43 arrives with polish, new spins, and a smarter installer; and one decision the rest of the Linux world should pay attention to.Sponsored By:Managed Nebula: Meet Managed Nebula from Defined Networking. A decentralized VPN built on the open-source Nebula platform that we love. 1Password Extended Access Management: 1Password Extended Access Management is a device trust solution for companies with Okta, and they ensure that if a device isn't trusted and secure, it can't log into your cloud apps. CrowdHealth: This open enrollment, take your power back. Join CrowdHealth to get started today for $99 for your first three months using code UNPLUGGED.Unraid: A powerful, easy operating system for servers and storage. Maximize your hardware with unmatched flexibility. Support LINUX UnpluggedLinks:

The Model Context Protocol (MCP) is evolving beyond local developer experiments and into the secure, remote infrastructure that will power the next generation of the internet. Brendan Irvine-Broque, Director of Product at Cloudflare, joins us to share a roadmap for this future. He explains how Cloudflare's "customer zero" philosophy of dogfooding their own tools provides a unique perspective on what it takes to scale MCP for production.Brendan makes the case for observability as the ideal starting point for enterprises and lays out the vision for MCP's ultimate destination: a universal protocol for agent-to-agent communication. The conversation explores how remote servers can create a decentralized layer for security and user memory, and what the exciting development of MCP UI means for the future of chat-based applications. This is an essential look at the next wave of agentic systems and the infrastructure required to build it.Check out:Watch Closing the AI gap: Surpassing executive expectations for AI productivityFollow the hosts:Follow BenFollow AndrewFollow today's guest(s):Learn more about Cloudflare's work with AI: agents.cloudflare.comRead the latest from Cloudflare: The Cloudflare BlogCloudflare's Unique Primitives Mentioned: Durable ObjectsThe MCP UI Project: MCP UI on GitHub (Project by Ido Salomon)Observability Tools Mentioned: Datadog | HoneycombAI Tools Mentioned: Block/Square's "Goose" | CursorConnect with Brendan Irvine-Broque: X @irvinebroque | LinkedInReferenced in today's show:AI Has Won: Google's DORA Study Shows Universal Dev AdoptionThe Theatre of Pull Requests and Code ReviewAI isn't replacing radiologistsIs it time to look for a new job? And how do I start?Support the show: Subscribe to our Substack Leave us a review Subscribe on YouTube Follow us on Twitter or LinkedIn Offers: Learn about Continuous Merge with gitStream Get your DORA Metrics free forever

Thank you to the folks at Sustain (https://sustainoss.org/) for providing the hosting account for CHAOSSCast! CHAOSScast – Episode 119 In this episode of CHAOSScast, we have a special episode from our friends at Sustain. Host Richard Littauer from Sustain is joined by guests Ben Nickolls and Andrew Nesbitt to discuss the ecosyste.ms project. They explore how ecosyste.ms collects and analyzes metadata from various open-source projects to create a comprehensive database that can help improve funding allocation. The discussion covers the importance of funding the most critical open-source projects, the existing gaps in funding, and the partnership between ecosyste.ms and Open Source Collective to create funding algorithms that support entire ecosystems. They also talk about the challenges of maintaining data, reaching out to project maintainers, and the broader implications for the open-source community. Hit the download button now! [00:03:16] Andrew and Ben explain ecosyste.ms, what it does, and how it compares to Libraries.io. [00:06:17] Ecosyste.ms tracks metadata, not the packages themselves, and enriches data via dependency graphs, committers, issues, SBOMs, and more. [00:08:12] Andrew talks about finding 1,890 Git hosts and how many critical projects live outside GitHub. [00:09:55] There's a conversation on metadata uses and SBOM parsing. [00:14:07] Richard inquires about the ecosystem.ms funds on their website which Andrew explains it's a collaboration between Open Collective and ecosyste.ms. that algorithmically distributes funds to the most used, not most popular packages. [00:17:03] Ben shares how this is different from previous projects and brings up a past project, “Back Your Stack” and explains how ecosyste.ms is doing two things differently. [00:20:17] Ben explains how it supports payouts to other platforms and encourages maintainers to adopt funding YAML files for automation. Andrew touches on efficient outreach, payout management, and API usage (GraphQL). [00:26:54] Ben elaborates on how companies can fund ecosyste.ms (like Django) instead of curating their own lists and being inspired by Sentry's work with the Open Source Pledge. [00:30:50] Andrew speaks about scaling and developer engagement and emphasizes their focus is on high-impact sustainability. [00:34:06] Richard asks, “Why does it matter?” Ben explains that most current funding goes to popular, not most used projects and ecosyste.ms aims to fix the gap with data backed funding, and he suggests use of open standards like 360Giving and Open Contracting Data. [00:37:04] Andrew shares his thoughts on funding the right projects by improving 1% of OSS, you uplift the quality of millions of dependent projects with healthier infrastructure, faster security updates, and more resilient software. [00:39:53] Find out where you can follow ecosyste.ms and the blog on the web. Quotes: [00:12:36] “I call them interesting forks. If a fork is referenced by a package, it'll get indexed.” [00:23:25] We've built a service that now moves like $25 million a year between OSS maintainers on OSC.” [00:34:41] “We don't have enough information to make collective decisions about which projects, communities, maintainers, should receive more funding.” [00:35:41] “The NSF POSE Program has distributed hundreds of millions of dollars of funding to open source communities alone.” [00:37:05] “If you have ten, twenty thousand really critical open source projects, that actually isn't unachievable to make those projects sustainable.” Spotlight: [00:40:53] Ben's spotlight is Jellyfin. [00:41:38]** **Andrew's spotlight is zizmor. [00:43:39] Richard's spotlight is The LaTeX Project. Panelist: Richard Littauer Guests: Ben Nickolls Andrew Nesbitt Links: CHAOSS (https://chaoss.community/) CHAOSS Project Twitter (https://twitter.com/chaossproj?lang=en) CHAOSScast Podcast (https://podcast.chaoss.community/) podcast@chaoss.community (mailto:podcast@chaoss.community) Alice Sowerby LinkedIn (https://www.linkedin.com/in/alice-sowerby-ba692a13/?originalSubdomain=uk) SustainOSS (https://sustainoss.org/) podcast@sustainoss.org (mailto:podcast@sustainoss.org) richard@sustainoss.org (mailto:richard@sustainoss.org) SustainOSS Discourse (https://discourse.sustainoss.org/) SustainOSS Mastodon (https://mastodon.social/tags/sustainoss) SustainOSS Bluesky (https://bsky.app/profile/sustainoss.bsky.social) SustainOSS LinkedIn (https://www.linkedin.com/company/sustainoss/) Open Collective-SustainOSS (Contribute) (https://opencollective.com/sustainoss) Richard Littauer Socials (https://www.burntfen.com/2023-05-30/socials) Ben Nickolls LinkedIn (https://www.linkedin.com/in/benjamuk/) Andrew Nesbitt Website (https://nesbitt.io/) Andrew Nesbitt Mastodon (https://mastodon.social/@andrewnez) Octobox (https://github.com/octobox) ecosyste.ms (https://ecosyste.ms/) ecosyste.ms Blog (https://blog.ecosyste.ms/) Open Source Collective (https://oscollective.org/) Open Source Collective Updates (https://opencollective.com/opensource/updates) Open Source Collective Contributions (https://opencollective.com/opensource) Open Source Collective Contributors (https://opencollective.com/open-source) Open Collective (https://opencollective.com/) 24 Pull Requests (https://24pullrequests.com/) Libraries.io (https://libraries.io/) The penumbra of open source (EPJ Data Science) (https://epjdatascience.springeropen.com/articles/10.1140/epjds/s13688-022-00345-7) FOSDEM '25- Open source funding: you're doing it wrong (Andrew and Ben) (https://fosdem.org/2025/schedule/event/fosdem-2025-5576-open-source-funding-you-re-doing-it-wrong/) Vue.js (https://vuejs.org/) thanks.dev (https://thanks.dev/home) StackAid (https://www.stackaid.us/) Back Your Stack (https://backyourstack.com/) NSF POSE (https://www.nsf.gov/funding/initiatives/pathways-enable-open-source-ecosystems) Django (https://www.djangoproject.com/) GitHub Sponsors (https://github.com/sponsors) Sustain Podcast-Episode 80: Emma Irwin and the Foss Fund Program (https://podcast.sustainoss.org/80) Sustain Podcast- 3 Episodes featuring Chad Whitacre (https://podcast.sustainoss.org/guests/chad-whitacre) Sustain Podcast- Episode 218: Karthik Ram & James Howison on Research Software Visibility Infrastructure Priorities (https://podcast.sustainoss.org/218) Sustain Podcast-Episode 247: Chad Whitacre on the Open Source Pledge (https://podcast.sustainoss.org/247) Invest in Open Infrastructure (https://investinopen.org/) 360Giving (https://www.360giving.org/) Open Contracting Data Standard (https://standard.open-contracting.org/latest/en/) Jellyfin (https://opencollective.com/jellyfin) zizmor (https://github.com/zizmorcore/zizmor) The LaTeX Project (https://www.latex-project.org/) Special Guests: Andrew Nesbitt, Benjamin Nickolls, and Richard Littauer.

In dieser Episode sprechen wir mit Christian Weichel, Gründer und CTO von Ona, über die Revolution in der Softwareentwicklung durch KI-Agenten. Ona löst das klassische "Works on my Machine"-Problem durch vollautomatisierte, Cloud-basierte Entwicklungsumgebungen und ermöglicht KI-Agenten stundenlang autonom wertvolle Arbeit zu verrichten. Christian teilt seine Vision einer Zukunft, in der über 70% des Codes von KI-Agenten geschrieben wird – bereits Realität bei Ona. Kernthemen der Episode: - Das "Works on my Machine"-Problem und wie Cloud-Entwicklungsumgebungen es lösen - Von Container-basierten Ansätzen zu echten System-Workloads für die Entwicklung - KI-Agenten in der Softwareentwicklung: Von Tab-Completion zu stundenlanger autonomer Arbeit - Das "Time between Disengagements"-Konzept aus dem autonomen Fahren angewendet auf Coding - Der fundamentale Wandel von "Deep Work" zu "Agent Management" in der Softwareentwicklung Highlights: - Reale Zahlen bei Ona: KI-Agenten sind bei 60% der Pull-Request beteiligt und schreiben 72% des Codes - Mobile-first AI: Entwicklung per Smartphone - Ideen werden direkt an Agenten delegiert und umgesetzt - Autonome Arbeit: Agenten arbeiten stundenlang selbstständig, Entwickler werden zu Managern Über den Gast: Christian Weichel ist Mitgründer und CTO von Ona, einer Cloud Plattform für standardisierte Entwicklungsumgebungen und KI-Agenten basierter Softwareentwicklung. Als Softwareentwickler mit jahrzenter langer Erfahrung und einer Promotion in Human-Computer Interaction bringt er tiefe technische Expertise mit visionärem Denken zur Zukunft der Softwareentwicklung zusammen. Links: Ona Platform: ona.com Christian Weichel: LinkedIn Profil AWS Cloud Horizonte Podcast Website Promo Code: "CloudHorizonte" für 50% Rabatt im ersten Monat bei Ona Host: Modood Alvi, Senior Solutions Architect bei AWS AWS Cloud Horizonte ist der offizielle deutschsprachige AWS Podcast.

Struggling with technical debt and code quality? Learn how a technical coach can help your team level up.In this episode, Emily Bache, a Samman technical coach, shares her proven method for building better engineering teams through structured learning and collaborative coding. We explore ensemble programming, learning hours, and why AI makes fundamental engineering practices more important than ever.Key topics discussed:The role of a Technical Coach and the Samman Method explainedHow AI amplifies good engineering practices instead of replacing themHow to use ensemble programming to achieve single-piece flowRunning effective ensemble sessions and avoiding common failure modesWhy learning is part of the work, not only a side activityWhy pull requests should not be the primary tool for mentoring junior developersThe dangerous trend of “vibe coding” with AI toolsTimestamps:(00:00) Trailer & Intro(02:22) Career Turning Points(03:23) Being Part of Modern Engineering YouTube Channel(04:27) The Role of a Technical Coach(05:42) The Impact of AI on Technical Coaching(08:20) Sofware Engineering is a Learning Process(09:55) Optimizing Learning With Samman Method(11:40) The Samman Method: Ensemble (Mob Programming)(14:59) The Main Benefit of Ensemble: Single Piece Flow(17:26) How to Do Ensemble and Avoid Common Failure Modes(20:27) The Types of Coding to Ensemble On(22:12) The Importance of Trust, Communication, and Kindness(23:52) Common Things Development Teams Are Struggling With(25:37) Prompt Engineering(27:16) The Samman Method: Learning Hours(29:08) Learning is Part of the Work(31:32) The Practice of Learning as a Team(34:39) The Constraint When Learning from Pull Requests(36:30) Putting Aside Time for Learning Hours(39:14) Becoming a Technical Coach(41:23) How to Measure the Effectiveness of Technical Coaching(43:52) Danger of AI Assisted Coding(46:59) The (Still) Important Skills in the AI Era(49:56) Why We Should Not Refactor Through AI(52:41) The Samman Method & Technical Coaching Resources(53:29) 3 Tech Lead Wisdom(54:56) Finding Mentors for Career Progression_____Emily Bache's BioEmily Bache is an independent consultant, YouTuber and Technical Coach. She works with developers, training and coaching effective agile practices like Refactoring and Test-Driven Development.Emily has worked with software development for 25 years, written two books and teaches courses on platforms including Pluralsight and O'Reilly. A frequent conference speaker, Emily has been invited to keynote at prestigious developer events including EuroPython, Craft and ACCU. Emily founded the Samman Technical Coaching Society in order to promote technical excellence and support coaches everywhere.Follow Emily:LinkedIn – linkedin.com/in/emilybacheX – x.com/emilybacheMastodon – sw-development-is.social/web/@emilybacheGitHub – github.com/emilybacheWebsite – emilybache.comSamman Coaching – sammancoaching.orgYouTube – youtube.com/@EmilyBache-tech-coachModern Software Engineering – youtube.com/@ModernSoftwareEngineeringYTLike this episode?Show notes & transcript: techleadjournal.dev/episodes/230.Follow @techleadjournal on LinkedIn, Twitter, and Instagram.Buy me a coffee or become a patron.

This interview was recorded for GOTO Unscripted.https://gotopia.techRead the full transcription of this interview hereAdrienne Braganza Tacke - Senior Developer Advocate at Viam Robotics & Author of "Looks Good To Me: Constructive Code Reviews"Saša Jurić - Author of "Elixir in Action" & The Ultimate Beacon in the Elixir SpaceRESOURCESAdriennehttps://bsky.app/profile/abt.bsky.socialhttps://x.com/AdrienneTackehttps://github.com/AdrienneTackehttps://www.linkedin.com/in/adriennetackehttps://www.instagram.com/adriennetackehttps://www.adrienne.iohttps://blog.adrienne.ioSašahttps://bsky.app/profile/sasajuric.bsky.socialhttps://twitter.com/sasajurichttps://github.com/sasa1977https://linkedin.com/in/sa%C5%A1a-juri%C4%87-21b23186https://www.theerlangelist.comDESCRIPTIONAdrienne Braganza, author of "Looks Good to Me: Constructive Code Reviews", and Saša Jurić, author of “Elixir in Action”, explore best practices for effective code reviews. They discuss how smaller, well-organized pull requests lead to better feedback, the importance of comment classification, and when to take discussions offline. Both emphasize that code reviews aren't just about catching bugs—they're crucial for knowledge transfer and creating cohesive codebases.While AI tools can help with routine aspects, human judgment remains essential, especially as AI-generated code becomes more common. The speakers agree that when done well, code reviews Digital Disruption with Geoff Nielson Discover how technology is reshaping our lives and livelihoods.Listen on: Apple Podcasts Spotify Inspiring Tech Leaders - The Technology PodcastInterviews with Tech Leaders and insights on the latest emerging technology trends.Listen on: Apple Podcasts SpotifyBlueskyTwitterInstagramLinkedInFacebookCHANNEL MEMBERSHIP BONUSJoin this channel to get early access to videos & other perks:https://www.youtube.com/channel/UCs_tLP3AiwYKwdUHpltJPuA/joinLooking for a unique learning experience?Attend the next GOTO conference near you! Get your ticket: gotopia.techSUBSCRIBE TO OUR YOUTUBE CHANNEL - new videos posted daily!

Work progresses on code name "Bento Fit" as Steve does some performance refactoring using Aider and Claude 4 Sonnet while Kotaro polishes up the iOS 26 UI changes. We also have a discussion on the trade-offs of using "AI" tools in programming and the importance of intellectual labor and little bit about what it means to be a "professional."## Show Notes- BentoFit: The Story So far- Steve: Improved loading time by “pair programming” with Aider and Claude Sonnet 4- Kotaro: iOS 26 UI updates- Next: - Kotaro: Dashboard interactions, customization - Steve: Independent loading of views, more HealthKit types - Aaron: Workout trends- Are LLMs Making us Dumber? - MIT Media Lab paper: https://www.media.mit.edu/publications/your-brain-on-chatgpt/ - Cal Newport discussing the results of MIT Media Lab paper: https://youtu.be/LB73n33cHOY- Wrap-Up- One more thing: Azam Sharp Foundation Models Framework Course - https://azamsharp.teachable.com/p/getting-started-with-the-foundation-models-framework - Coupon code: PHILLY - Discount: 40% - Expires: July 31st, 2025## Chapters00:00 Introductions01:47 Bento Fit: The Story So Far04:05 "Pair Programming" With Aider and Claude Sonnet 424:55 iOS 26 UI Updates31:55 Bento Fit: Next Sprint37:45 The Trade-Offs of "AI" in Programming43:34 The Importance of Intellectual Labor54:43 Apple's "AI" Bet01:05:25 Wrap-Up01:05:51 One More Thing...01:07:31 TagIntro music: "When I Hit the Floor", © 2021 Lorne Behrman. Used with permission of the artist.

本期节目应嘉宾的要求，我们只发布了文字稿。带来的不便还请各位听众谅解。 嘉宾 tanloong 链接 gh-133390: Support SQL keyword completion for sqlite3 CLI by tanloong · Pull Request #133393 · python/cpython SQLite Keywords QuantWiki - 中文量化百科 《阳光马达棒球场！》 文字稿 laike9m: 哈喽大家好，欢迎来到最新一期的《捕蛇者说》。我们今天请到了谭龙，然后让他来聊一聊给 CPython 做贡献的经历。谭龙其实最近给 CPython 提了一个 PR，然后也是他第一次给 CPython 做贡献。然后呢，这个贡献是给 SQLite 的那个命令行加了一些命令补全，就是可以补全 SQLite 的关键字。我们今天另外一位主播是 Manjusaka。 Manjusaka: 请叫我 Nadeshiko Manju，对吧？OK，大家好，好久不见，我又回来了。然后今天很高兴又来和 laike9m 进行搭档，来。 laike9m: 好，然后这是我们今天的嘉宾谭龙，你要不先简单介绍一下自己吧。 tanloong: Hello，大家好，我叫谭龙，我是山东的。然后 18 年的时候是来青岛上大学，然后大学本科毕业之后就在这找工作了。我本科不是计算机的，毕业之后找工作也找了一些计算机相关的工作，也有一些其他方面的工作，中间也换了好几次工作。最近是刚刚入职一家新的公司，然后是做数据分析方面的工作。谢谢。 laike9m: 所以你说你本科不是学计算机，方便透露一下吗？你本科学的是什么？ tanloong: 我本科是英语的。 laike9m: 哦，这个跨度很大。 tanloong: 对，确实。其实我本科最开始填志愿的时候，我录取的专业也不是英语，是一个调剂的专业，叫生态学。然后我是大一下学期的时候想转专业，然后正好我们学校有转专业的政策，我就从高中学的那几门课里，我觉得英语我学得还可以，然后当时也比较喜欢，所以我就决定转英语了。直到后来快毕业的时候才有点接触到这个计算机方面的这个东西。 laike9m: 然后就发现自己还是更喜欢计算机一些。那所以你之后是进行一些自学吗？然后就去找工作还是？ tanloong: 对，基本上是自学。最开始接触计算机是大一的寒假，我们辅导员让学生回家的时候在假期要学点东西，然后开学让交学习笔记。我当时从一个中国大学 MOOC 上注册了一个账号，然后它弹出来的，第一个给我推荐的课程就是 Python。那我就学这个吧。所以当时我就学，就学了这个。当时学得很不明白，然后就把 PPT 跟着敲了一遍，但是也云里雾里的。直到后来后面的几个寒暑假才看了一些成体系的 Python 的入门的书，然后算是入门 Python 了。 laike9m: 所以换句话说就是你其实一开始学，你并不知道 Python 是干嘛的，就是并没有特别地抱着某种目的，比如说我就想找一个程序员的工作这样子。 tanloong: 没有，开始的原因只是巧合，但后面坚持下来，应该也算是因为比较喜欢吧。我觉得比较有意思。 laike9m: 那还是挺有意思的，对，感觉是命运的安排。 Manjusaka: 咱行看起来都是转行的。诶，那 laike9m 你是转行吗？ laike9m: 我本科也不是学计算机的，然后我知道你本科也不是，所以。 Manjusaka: 对，那看起来大家这三个人跟少女乐队一样，这三个人里面抽不出一张计算机本科学位。 laike9m: 对，但我觉得还是你的英语这个跨度最大。 Manjusaka: 啊，对，然后，哇，卧槽。啊，现在要是学日语的，我突然就想问一下为什么要学日语。 laike9m: 学日语的转计算机还真没见过，但是很多程序员都会日语。 Manjusaka: 有，可能在大连那边还真有。 laike9m: 啊，对，大连日本人比较多。 Manjusaka: 对，对，对，日语外包会多一些。 laike9m: 嗯，好，对，说回正题，就是你相当于一开始接触的编程语言就是 Python, 然后后来相当于你在工作中可以理解也是主要用 Python, 对吗？ tanloong: 对的，我有两份工作是跟计算机相关，然后都是写 Python 的。第一个工作是之前的一份是写图形界面的，用的是 PySide, 然后就写一个称重系统。他们是一个建桥公司，就是他们需要统计他们的货车送多少货进他们工厂，然后运多少货出来，写一个这个图形界面，然后放在那个他们的磅站去，然后货车过磅的时候来统计数据。另一个工作是现在的工作是在一个私募公司做数据分析。我之前没接触过股票证券这方面的东西，现在还在学习。 laike9m: 你是开发算法吗，还是给他们开发一些内部工具或者界面之类的？ tanloong: 内部工具，我们组三个人有写算法的，但是我是属于比较初级的那种，只能写一些帮他们节省时间的工具。 laike9m: OK，对，因为我感觉那种像交易的算法可能更需要用 C++ 一些，对吧？还是说其实也有用 Python，比较好奇。 tanloong: 我们公司开发部应该是写 C++ 的，然后应该也有写 Python, 但是数据分析我们那个组主要是做一些因子的构建，就分析哪些因子它对你的这个股票的收益率贡献比较大，就这种的，我们就主要是写 Python，不写 C++。 laike9m: 明白，好的。所以就是到了今天我们要聊这个话题，然后你给 CPython 做了一个贡献。那我相信就是百分之可能 99.99% 的用过 Python 的人都没有给 Python 做过贡献，那么你一开始是怎么有这个想法的？然后就是后来你是怎么去一步一步实施这个的？ tanloong: 我最开始有这个想法是应该从天哥，就是 B 站的那个，对，他当时成为 Python Core Dev 之后，在直播的时候就有人在直播间问一个给 Python 做贡献的问题，做贡献难不难呢？这些之类的。但是天哥说，如果你想给 Python 做贡献，你是会发现有很多事可以做的，做贡献并不难。然后后来就是之前我在写称重系统的时候，需要用到 SQLite 去查用户存的那个本地的数据库。然后当时我就发现 Python 的 SQLite 的命令行界面有点不好使，就是如果它能有那个补全就好了，所以当时是有那个想法。然后实施是在后来我前段时间没有工作，然后就每天比较闲，然后我想找点事做，然后我想起来之前我想给那个 SQLite 的加补全的这个想法，我就试试吧。然后我就去 GitHub 上找，我就试了一下。然后试的时候我发现，我本来觉得这个应该是挺难的，因为我完全不知道它这个补全要怎么实现。但是我去看了一下 PDB，就是天哥维护的那个 PDB 里面的代码，它里面实现补全是那样写的，然后我就照着 PDB 的补全，然后给 SQLite 加了一个补全，然后就交了 PR。 laike9m: 所以其实也是从你的实际工作需求出发，然后加上高天的激励。对，你知道高天也来过我们这边好几次吧？ tanloong: 对，两次。 laike9m: 老听众，看来是。对，然后我觉得这个还挺有意思，就是也是算是榜样的力量吧。就是我不知道还有没有其他人是这样，就是因为听到就是有个人跟他说，哎，其实做贡献没有那么难，然后去做了，但这样挺好的。我算吧。你也算吗？ Manjusaka: 对，我算。当时我是先认识张翔老师，然后后面然后跟他聊了一些，就包括我可能当时，那位你可能还认识，那个 Ezio Melotti。谁？18 年北京的那位嘉宾，Ezio。 laike9m: 你说 PyCon。 Manjusaka: 对，就是当时我们不是邀请到另外一位来北京。 laike9m: 哦。PyCon China Beijing 2018。2018 吗？2018 我去了吗？我有点不记得了。没事你继续说吧。 Manjusaka: 你在北京，你当时还没 transfer 去美国，然后你从上海来北京。 laike9m: OK。 Manjusaka: 然后我当时聊了一下，就后面开始，正好 18 年，后面我就说我正好在休息，后面就开始陆陆续续提一些贡献，对。 laike9m: 嗯，对对，其实我觉得翔哥一定程度上也是当时给了我一些激励或者指导嘛，对。 Manjusaka: 对，张翔老师还是非常 nice 的。 laike9m: 对，就给听众们如果有不知道，就是张翔是中国的第一个 CPython core developer, 第一个核心开发者，对，然后高天是第二个。 Manjusaka: 对，然后张翔老师应该是在 16 年晋升的。嗯，反正是老前辈了，老前辈了。 laike9m: 但其实他当时就是更多是因为工作中会需要改一些 CPython 代码，他当时在华为嘛，对吧？ Manjusaka: 然后。哦，不不不，他晋升成为 CPython Core 的时候，我记得没错，是在新浪，然后他就开始编的。 laike9m: 哦，新浪，OK。 Manjusaka: 对，然后他去华为其实做的也不是跟 CPython 本身相关的，他是去做的 OpenStack 相关的东西。对，然后他对就是说是整个生态工具链会比较熟，所以说他可能跟高天老师就是说是有一点不一样，是张翔老师对于各种非常疑难问题的 debug 非常擅长，这也是我记得介绍人给他在他的 promote 介绍里面说的，对。 laike9m: 嗯，我记得他当时那个演讲。 Manjusaka: 对对对，然后我的很多 debug 技巧也来自于张翔老师，对。 laike9m: Anyway，我觉得后人都是在前人的一些基础上去做工作的。 Manjusaka: 是的，没错。 laike9m: 好，那说回谭龙的这个 PR，我其实也简单看了一下，其实我原来也不知道补全要怎么加，但发现其实还真的挺简单的。你可以跟听众们大概说一下这个流程吗？比如说我要给一个像 Python 的 SQLite 命令行加补全，它大概要做些什么工作？ tanloong: 它是写一个 context manager，然后在你进那个 readline 的时候，你把 readline 的那个 completor 给替换成你自己的函数，然后在退出的时候再把它替换回你替换之前的那个函数，就你替换之前的那种 readline 的默认的 completor。然后你自己写的那个函数是还有一个 state, 就是 readline 调你的函数拿补全的时候，它会先给你发一个 state 等于 0, 这个时候你判断了 state 等于 0 的时候，你去生成一个完整的，就根据用户当前输入的那个 text, 生成一个完整的 completion candidate 的列表。然后 readline 会继续给你发 state 等于 1, 2, 3，这个时候你把你之前生成的 candidates 按照它发的 state 做个 index, 返回你的 candidates 对应的要补全的词。然后这中间就是 state=0 的时候，你的 candidates 最好需要缓存一下，不要在每次 readline 给你发 state=1, 2, 3 的时候你再重新生成，那样会比较耗时间，注意一下性能的问题。然后基本就是这样。 laike9m: OK，我说一下我看到的那个 PR 里面，我觉得比较关键的地方就是它其实就是一个首字母的匹配，就相当于首先你有一个关键词的列表，对吧？你要构建一个说哪些单词是 SQLite 关键词，比如说 SELECT 啊 JOIN 这种。然后我发现你是当用户每输入一个字符，然后你就会去跟这些关键词的前缀做一个匹配，对吧？然后发现如果有能 match 上的，你就把它作为一个 candidate 返回，作为补全的一个。 tanloong: 就其实那个关键字最开始的，你要拿到那个 SQLite 的完整的关键字的列表，当时对我来说还是挺难的。我最开始是从 SQLite 的文档里直接复制它的完整的所有的 147 个关键字，然后硬编码到 Python 里。但是有 core dev 说这样写不太好，而且其中有一个关键字并不是在所有的 SQLite 编译出来的时候都会支持的，是一个 V 开头的关键字。希望就是这个 SQLite 这个关键字能够动态生成。然后我当时查了一下，就是如果你想动态生成需要在 C level 去写，但是我这个 C 学的不太好，虽然之前学过一个学期的公开课，但是我完全不知道就是用我查到的 SQLite 文档里说生成关键字列表的那两个函数，去生产，我不知道要怎么写，然后我也不知道怎么把它放进 Python, 所以我当时说这个对我有点难。后来有一天晚上我看到那个消息里，那位 core dev 又说了一遍，就是非常希望这个关键字列表它是能从 C 里拿到的，而不是从 Python 里拿。我当时其实有点理解错了，我以为他的意思是让我把那个硬编码的关键字列表从 Python 给移到 C 里，然后我当时就把它移到 C 里了。虽然我对那个 Python 的 C 要怎么写，然后怎么把它暴露出来，暴露给 Python 的代码去能够访问，我用了一下 AI，当时是用的豆包，问怎么在 Python 的那个 C 里面存一个列表，然后能让它暴露出来，给 Python 的代码调用。然后当时豆包写上，然后我试了一下豆包给的结果，然后是可以的，然后我就直接硬编码到 C 里，然后问那个 core dev 行不行。但是 core dev 后来回复说他的意思是不是在 C 里硬编码，而是在 C 里要动态生成。当时我就，我感觉我理解错了。然后后来是另一位 core dev 帮忙给写的，然后他写了之后给发了一个 PR 到我的那个 fork 里，然后我合并进去，然后我的 fork 再合并到 CPython 的 main。 laike9m: 我还在想，就是因为我也看到你的那个 keywords 那部分是从 C 的 module 里 import 的。这个他当时说为什么要动态生成，其实我还是不太理解。可能就是 OK，我明白，但就是你编译的时候，你会根据你的 CPython 版本有不同的关键词，这样你就不用在那个 Python 里面写，比如说 if 是什么版本，然后你的关键字要加或者减一些东西是吧？ tanloong: 对的，SQLite 它应该是在编译的时候有一个选项，如果你开了某个选项，那么它的关键词会有变化。 laike9m: 明白明白。 tanloong: 哦。 laike9m: 这个确实还挺 tricky 的，对，感觉是这个 PR 里面最困难的部分。 tanloong: 确实。 Manjusaka: 嗯。 laike9m: 那所以就是总体这个流程下来你有什么感受吗？因为我知道你的那个 PR 还被因为把 test break 了还被 revert 了一次，对吧？ tanloong: 对，它是有一个测试在运行那个 run_pty 的时候，它是用那个 run_pty 生成一个 sudo terminal, 就在一个伪终端里去模拟用户的输入，然后查看它给的 candidates 是不是符合预期。但是在那个伪终端里，它给的 candidates 是带颜色的。就是你的 candidates，它的两边会有那个控制符。 laike9m: 它那个颜色码嘛，然后就不对了。 tanloong: 对，然后测试就 fail 了。当时是在那个 buildbot 上跑构建，就是构建失败，我找了一下，但是我想就是在那个 buildbot 上最好能有一个 interactive 的，就我能像在终端里我手动敲命令一样，我可以人为的去测试，然后看一下它中间到底是什么样子，再修改那个测试。但是 buildbot 我找不到我要怎么就进那个交互式的模式，也可能根本就没有。然后这个问题我解决不了。然后当时是有个 core dev 说他去找那个 buildbot 的 owner，然后问他要 SSH 的权限，然后他去调试。 laike9m: 等一下，我有一个疑问，就是为什么你这个 PR 感觉大家都很 helpful? 因为你知道一般的 CPython PR 就是你提了之后，可能很长时间都没有人理。这点你是怎么看的？就是感觉大家都会去帮你去 debug 或者帮你写些代码，这个是自然的吗？还是说他们本来就对这个很有兴趣还是怎么样？ Manjusaka: 嗯，从我的角度出发的话，我不太确定，高天老师那边可能有其他的 input, 但是就我观察来看，这个取决于 core dev 风格。不过他们整体来说，对新人是比较友好的。而且去 buildbot 里面调试这种东西的话，我觉得这个东西其实也还好，你去翻看 CPython 的 PR 其实这种事情也有不少，所以说我觉得这个相对来说还好。但是对于一些争议或者说是还在试图达成共识的过程中，那确实是比较头疼的。但是如果说是已经达成共识要去实施的一个 PR, 那我觉得相对来说会好一些。 laike9m: 明白，所以就是这种没有什么争议性的，只是实现或者一些 debug 问题就会推进的比较快，然后大家也会帮忙。 Manjusaka: 对，而且这种东西我理解主要是你添加新的 feature，而不是更改 API 的话，那这种东西就会好很多。就像我上周的时候，我当时想改 sys._enable_profile() 那个 API, 就是新增加的那个远程 debug 的接口，我想新增加在它的 audit event 里面增加一些元数据。这就牵扯到了 API 的更改以及更内部的一些细节上的更改。然后我就和三个 core dev，然后 Victor, Paul，还有哪一位，然后就 battle 了两天，然后最后 I gave up。 laike9m: 好吧，他们可能有一些 concern。 Manjusaka: 对，就这种你增加一些新的 API 之类的，就是会有一些比较 concern, 但是如果说你是实现一个全新的 feature, 大家觉得你这个 feature 不是为了实现而去实现，那这种情况下相对来说还是会比较顺利的。 laike9m: 嗯，嗯，理解。还有一点就是我知道那个 CPython 的不同模块，它其实是不同的人来维护的嘛。 Manjusaka: 啊，是的，没错。 laike9m: 就可能恰好就是 SQLite 这个维护者，他就是比较积极，比较热心，就是反应比较快，所以。 Manjusaka: 啊，是的，没错。它是比较活跃的，就是 SQLite 这种东西。我就又说到一个伤心事。在改一个东西，然后被 Mark 直接给拒了，然后我现在都还推不动，虽然大家都说有需求，但是 Mark 就觉得说这个东西没需求，然后但是就给拒了，对。 laike9m: 我知道 Mark Shannon 这个人比较固执，对，也是跟人的性格有很大关系。 Manjusaka: 对，是的，没错，跟这个看具体的开发者的问题，对。 laike9m: 对，就是其实你会发现像 Python，如果你不了解，可能会觉得 Python 是一个有一个很庞大团队去维护的这么一个精密复杂的系统，但你真正去看它里面到底是怎么实现的，或者说去提 PR 才会发现可能每一个文件它就是那么一两个人懂，然后你就是要找那一两个 stakeholder, 如果你想做一些更改的话，然后你只要能比如说说服他们，然后你就可以做你想做的。对，它相当的扁平吧。 Manjusaka: 对，我觉得主要还是怎么说服。 laike9m: OK，所以说回谭龙你这个 PR 的话，然后就你把那个 core developer 帮你把测试修好了，对吧？然后你就重新提交，这样子。 tanloong: 对的。就我感觉给 CPython 这个维护者，在这些维护者之间就是它是有一个小圈子的，然后你作为一个新人去给他们交 PR 也是一个交际的过程。就是你要积极主动一点，然后就一般新人你第一次交 PR 的时候，比较容易会被带着审视的态度去看你的工作。然后你交 PR 的时候，你最好是把你之前想到的一些可能会拒绝你 PR 的理由给解释清楚，然后你为什么这样做，然后让他们就是在他们提出问题之前就看到你的解释，这样会就是更容易沟通，然后更容易让你的 PR 更顺利一点。 Manjusaka: 嗯，对。 laike9m: 我看到你其实你之前提了一个 issue 对吧，就是你说你希望能够在 SQLite 的命令行里支持这些补全。所以你提那个 issue 的时候当时就想说自己去实现这个吗？还是说你本来期待说其他人可以去做这个？ tanloong: 是的，我是准备自己实现的。因为 Python 的 dev guide 里面写，如果你想交一个 PR，你应该先写一个 issue, 除非你交的 PR 是 typo fix。所以我就是先写的那个 issue，然后就紧接着交了 PR。当然那个 issue 题目写得有点大了，我那个 PR 只做了关键字的补全，但是 issue 是所有的补全。比如说你以后也许还会需要补全你的那个 SQLite 里面的表名，还有列名，还有函数名，这些目前还不支持。 Manjusaka: 明白。 laike9m: 所以你未来打算就是继续在这方面做一些事情吗？还是说就先到此为止？ tanloong: 也许会吧。但是这个刚才说的表名、列名、函数名，我目前还没有想到就是要怎么才能实现它。我看到就是 Python 的 PyPI 上有一个第三方的 SQLite 的命令行是支持表名、列名、函数名的，而且它是 context-sensitive，就是它会检测你当前是不是需要输入一个表名或者列名，比如说你是在 SELECT 后面，那它就会给你补全列名。就像这种就是非常智能的补全，我还没有想到就是怎么在 CPython 里支持，也许没有那个能力去支持它，总之就是还不确定。 laike9m: 明白。对，那个可能要就是回溯一下，不光得去做一个前缀匹配，对，会更复杂一点感觉。但我觉得是一个好的开始吧，就是你有一个这种框架，就会有更多人去加更多的 feature 进去。也许未来就会有。 tanloong: 是的，确实。就那个关键字的 PR 合进去之后，过了几天，有另一位 contributor 交了一个 dot commands completion 的 PR, 现在给加了那个 dot commands 的补全。目前 Python 的 SQLite 的命令行就有三个 dot commands，就是 .help, .version, .exit。.exit 还是 .quit 就来着，总之是推出的那个 .command。然后那个 PR 现在正是就是刚刚建不久，然后还没有 core dev 留言，但是它实现的有一点简单，就是有一些问题，但是应该后面会就是慢慢给修上，然后给合进去。 laike9m: 其实你可以去那个 review，因为你比较熟，你是最熟的其实。 tanloong: 是，我还真给看了一下，然后写了两个评论。但是写的第一个评论就是那位交 PR 的人，他觉得没有必要，就是他持反对意见。然后第二个评论，那位交 PR 的人还没有回复，然后其他人也没有回复。 laike9m: 嗯，我觉得挺好，就是因为我知道就是如果你比如说在一些 issue 里面回复的比较多，然后就会被那个提拔成 triager 的权限，对吧？然后其实这个是 core dev 之前的一步。 tanloong: 对，确实。然后我看就是交那个 dot command completion PR 的那个人，他的评论比较多，一般 CPython 有什么新的 issue，他都会先跑到底下去评论，然后有时候评论这个 issue 和之前的某个 issue 有联系。就像这种之类的，或者有人交 PR，然后他会去给 review。但是我还没有太多追踪 CPython 的那些 issue 和 PR，然后没有评论多少，就主要是我自己参与的那些 issue 跟 PR。 laike9m: 对，我觉得每个人有不同的风格吧，也不用一定去迫使自己要怎么样之类的。像高天那种，就是从 PDB 模块开始，然后把 PDB 弄得特别熟，然后通过成为 PDB 的维护者，然后来成为 core dev，这个路径也挺好的。我觉得可能更实际一点吧，因为我觉得你要去就是对于一些每一个 change 做一些评论，这个还挺难的。 tanloong: 确实从一个单独的模块开始做，你确实你的那个在 CPython 社区里面的成长会更容易一点。因为你是这个模块的专家，然后别人有什么问题就只能来找你。但是我也觉得这个也挺难的。天哥是从一个完全的 CPython 的陌生人，然后进入到 CPython 一点点做贡献，最后成为 core dev。就像你从一个外人进一家公司，然后慢慢走到管理层，都是非常难的步骤，你要获得信任，然后你做的每一个工作你都要给解释清楚，然后让别人就是认为你是可以承担更重要的角色。我觉得这也是非常难的一个过程。 laike9m: 嗯，是的是的。对，其实说回来就是那个，像给 CPython 做贡献不光是一个技术面上的事情，它还有很多这种交流，对吧？然后尤其是当你和这些外国人交流，你不是用你的母语，然后他们的一些交流的习惯可能也不太一样，所以这个方面也会有一些壁垒吧？就是谭龙，因为你是英文专业，所以这方面你觉得说你的本科教育有帮到你吗？ tanloong: 我觉得是有的。如果我没有选英语专业，我应该还停留在高中的那个状态，就是虽然当时英文成绩还可以，但是如果让我看一个全英文的网站，我是心里发怵的，我是心里有那个牴触的心理。但是大学接触英语比较多，然后主要是你抵触心理没有了，然后你愿意去哪怕接受自己写出来的英语没有那么完美，哪怕也不像母语，也不够 native-like, 你也可以接受自己写出来的这些句子，然后去交流。因为你只要能把意思给表达清楚，让对方看懂就可以。其实你放下这个心理负担，你会发现写英语还是没有那么难的。 laike9m: 是的，是的，同意，对。 Manjusaka: 我现在是有一个做简单的 workflow, 然后我会交给 AI 来帮我润色，然后扩展一下我单纯的观点。对，我觉得这是 AI 的一个很好的使用场景。 laike9m: 你用的是哪个工具呢？还是就是手动复制？ Manjusaka: 我是直接在 Claude AI 上面给他固定了一组 prompt。 laike9m: 明白，明白。 Manjusaka: 我觉得这就是这一块东西很好用的方式，特别是在我跟他们长篇大论地 battle 的时候，还是挺好用的。 laike9m: 帮我写一个回复去反驳这个人。 Manjusaka: 对，我一般是 prompt 就是说是我引用的那一段，然后我首先给他一个正面的肯定，然后其次列出我对他的观点，一 ABC，然后对，然后就这样。 laike9m: 你写 prompt 的时候是拿中文写吗？ Manjusaka: 我拿中文写。 laike9m: 嗯，OK，这样表意更准确一些。 Manjusaka: 对对对，你可以看我群里发的那个 issue，然后那个就是很多大段的，就是我是用 AI 生成出来的。 laike9m: 我想到之前在推特上看到一个段子，就是说在 AI coding 的时代，以前不都是什么 “Talk is cheap, show me the code” 吗？现在是 “Code is cheap, show me the talk”。 Manjusaka: 确实。Code is cheap, show me the talk. laike9m: 一个哥们他在他的 GitHub repo 里面就是把所有的他的那个跟 AI 的聊天记录全都传上去了。这个就是挺好玩的。 Manjusaka: 挺好玩的，挺好玩的。 laike9m: 对，像谭龙，我觉得你之前本来要在 C 模块里面写死 keyword 的时候，你也是用 AI 生成的，虽然后来发现那个路径是不对的，但是至少这方面 AI 的助力还是挺大的。 tanloong: 确实，如果我当时在紧接着问 AI 怎么不要硬编码，然后整个动态生成的话，也许我当时就能直接把动态生成的代码给交进去了，而不是让另一位 core dev 帮忙给写。嗯。 Manjusaka: 是的。 laike9m: 所以就是你对于这个给 CPython 第一次做贡献的这个流程，你有什么其他的一些感受吗？就是我们刚才还没有聊到的，你想分享的。 tanloong: 我没有了。 laike9m: 哦，行，那也没关系，好。我们也是觉得给 CPython 做贡献的人越多越好，然后可能也是能够给听众们一个激励吧。然后感觉这期其实录的挺快的，然后不知道有没有什么你想推荐的东西，就是如果你听我们之前节目的话，你应该知道有这个环节，对吧？ tanloong: 我推荐一个网站是跟量化金融有关的，算是一个给入门的学习者的一个索引吧。那个网站叫 QuantWiki。是量化金融中文百科，然后里面有一些就是量化金融相关的入门的概念，还有一些前沿的证券公司发的研究报告，还收录了其他的类似的 Python Data Training 这方面的 GitHub 的 repo 的链接。如果是这方面像我这样的刚入门的学习者的话，可以就是了解一下。 laike9m: 我看了一下，这个写的还挺好的，就是他把各种概念和一些工具都列出来了，对。嗯，我们之前也请过大伟来聊，就是他开发了一些交易相关的工具，所以其实这方面 Python 应用也是挺多的，对。 Manjusaka: 哎，反正我觉得给 Python 做贡献，就觉得还是希望像谭龙这样的人越来越多。是的，是的。对，而且现在他们就感觉是整体都非常缺人的感觉。 laike9m: 哪个看上去像不缺人？ Manjusaka: 嗯，这倒也是，确实。反正就之前我给 Brandon 和 Ken Jin 然后请教问题的时候他们都表示很新奇，我操居然还有 Freshman 对我们现在做的这块感兴趣。对，居然还有新人对我们感兴趣？Freshman，哦 Freshman。啊对，反正我觉得从他们视野来看，就整体的很多的地方都会很缺人。 laike9m: 嗯，是的是的，尤其是像你做的那些 debugging 啊，然后 tracing 的一些东西，我觉得懂的人真的很少。 Manjusaka: 我觉得就没人管的状态。而且就我现在对他们的 tracing 的部分有很大的怨言，就主要是 Mark 上面说... 哎，我后面会试着再推一推，但是就哎，随缘吧。 laike9m: 嗯，行。好的。Manjusaka 你有没有什么想推荐的东西。 Manjusaka: 我推荐一部番吧，《阳光马达棒球场！》，非常很不错的一部番，我推荐大家去看看。然后可能国内有很多朋友对于传统的国外的可能说足球或者其他也好，这种体育文化他并不清楚，这种体育文化到底应该是怎么样的，它是怎么样遍布在人的日常生活中的，然后有些人不清楚，那么我建议大家可以去看一下，然后挺治愈的一部番。 laike9m: 嗯，好的好的。啊，我先不推荐了吧，以后再说吧。对，我最近在看一些书，但是还没有看完，所以，对。好，其实我们这期是比较短的一期，然后但是也希望听众们可以从中学到一些东西，然后如果要记住一点的话，就是可能给 CPython 做贡献也没有那么难。对，好，我们这期就到此结束，然后各位听众我们就下期再见，大家拜拜。 众人: 拜拜。

Guests Ben Nickolls | Andrew Nesbitt Panelist Richard Littauer Show Notes In this episode of Sustain, host Richard is joined by guests Ben Nickolls and Andrew Nesbitt to discuss the ecosyste.ms project. They explore how ecosyste.ms collects and analyzes metadata from various open-source projects to create a comprehensive database that can help improve funding allocation. The discussion covers the importance of funding the most critical open-source projects, the existing gaps in funding, and the partnership between ecosyste.ms and Open Source Collective to create funding algorithms that support entire ecosystems. They also talk about the challenges of maintaining data, reaching out to project maintainers, and the broader implications for the open-source community. Hit the download button now! [00:01:58] Andrew and Ben explain ecosyste.ms, what it does, and how it compares to Libraries.io. [00:04:59] Ecosyste.ms tracks metadata, not the packages themselves, and enriches data via dependency graphs, committers, issues, SBOMs, and more. [00:06:54] Andrew talks about finding 1,890 Git hosts and how many critical projects live outside GitHub. [00:08:37] There's a conversation on metadata uses and SBOM parsing. [00:12:49] Richard inquires about the ecosystem.ms funds on their website which Andrew explains it's a collaboration between Open Collective and ecosyste.ms. that algorithmically distributes funds to the most used, not most popular packages. [00:15:45] Ben shares how this is different from previous projects and brings up a past project, “Back Your Stack” and explains how ecosyste.ms is doing two things differently. [00:18:59] Ben explains how it supports payouts to other platforms and encourages maintainers to adopt funding YAML files for automation. Andrew touches on efficient outreach, payout management, and API usage (GraphQL). [00:25:36] Ben elaborates on how companies can fund ecosyste.ms (like Django) instead of curating their own lists and being inspired by Sentry's work with the Open Source Pledge. [00:29:32] Andrew speaks about scaling and developer engagement and emphasizes their focus is on high-impact sustainability. [00:32:48] Richard asks, “Why does it matter?” Ben explains that most current funding goes to popular, not most used projects and ecosyste.ms aims to fix the gap with data backed funding, and he suggests use of open standards like 360Giving and Open Contracting Data. [00:35:46] Andrew shares his thoughts on funding the right projects by improving 1% of OSS, you uplift the quality of millions of dependent projects with healthier infrastructure, faster security updates, and more resilient software. [00:38:35] Find out where you can follow ecosyste.ms and the blog on the web. Quotes [00:11:18] “I call them interesting forks. If a fork is referenced by a package, it'll get indexed.” [00:22:07] We've built a service that now moves like $25 million a year between OSS maintainers on OSC.” [00:33:23] “We don't have enough information to make collective decisions about which projects, communities, maintainers, should receive more funding.” [00:34:23] “The NSF POSE Program has distributed hundreds of millions of dollars of funding to open source communities alone.” [00:35:47] “If you have ten, twenty thousand really critical open source projects, that actually isn't unachievable to make those projects sustainable.” Spotlight [00:39:35] Ben's spotlight is Jellyfin. [00:40:20] Andrew's spotlight is zizmor. [00:42:21] Richard's spotlight is The LaTeX Project. Links SustainOSS (https://sustainoss.org/) podcast@sustainoss.org (mailto:podcast@sustainoss.org) richard@sustainoss.org (mailto:richard@sustainoss.org) SustainOSS Discourse (https://discourse.sustainoss.org/) SustainOSS Mastodon (https://mastodon.social/tags/sustainoss) SustainOSS Bluesky (https://bsky.app/profile/sustainoss.bsky.social) SustainOSS LinkedIn (https://www.linkedin.com/company/sustainoss/) Open Collective-SustainOSS (Contribute) (https://opencollective.com/sustainoss) Richard Littauer Socials (https://www.burntfen.com/2023-05-30/socials) Ben Nickolls LinkedIn (https://www.linkedin.com/in/benjamuk/) Andrew Nesbitt Website (https://nesbitt.io/) Andrew Nesbitt Mastodon (https://mastodon.social/@andrewnez) Octobox (https://github.com/octobox) ecosyste.ms (https://ecosyste.ms/) ecosyste.ms Blog (https://blog.ecosyste.ms/) Open Source Collective (https://oscollective.org/) Open Source Collective Updates (https://opencollective.com/opensource/updates) Open Source Collective Contributions (https://opencollective.com/opensource) Open Source Collective Contributors (https://opencollective.com/open-source) Open Collective (https://opencollective.com/) 24 Pull Requests (https://24pullrequests.com/) Libraries.io (https://libraries.io/) The penumbra of open source (EPJ Data Science) (https://epjdatascience.springeropen.com/articles/10.1140/epjds/s13688-022-00345-7) FOSDEM '25- Open source funding: you're doing it wrong (Andrew and Ben) (https://fosdem.org/2025/schedule/event/fosdem-2025-5576-open-source-funding-you-re-doing-it-wrong/) Vue.js (https://vuejs.org/) thanks.dev (https://thanks.dev/home) StackAid (https://www.stackaid.us/) Back Your Stack (https://backyourstack.com/) NSF POSE (https://www.nsf.gov/funding/initiatives/pathways-enable-open-source-ecosystems) Django (https://www.djangoproject.com/) GitHub Sponsors (https://github.com/sponsors) Sustain Podcast-Episode 80: Emma Irwin and the Foss Fund Program (https://podcast.sustainoss.org/80) Sustain Podcast- 3 Episodes featuring Chad Whitacre (https://podcast.sustainoss.org/guests/chad-whitacre) Sustain Podcast- Episode 218: Karthik Ram & James Howison on Research Software Visibility Infrastructure Priorities (https://podcast.sustainoss.org/218) Sustain Podcast-Episode 247: Chad Whitacre on the Open Source Pledge (https://podcast.sustainoss.org/247) Invest in Open Infrastructure (https://investinopen.org/) 360Giving (https://www.360giving.org/) Open Contracting Data Standard (https://standard.open-contracting.org/latest/en/) Jellyfin (https://opencollective.com/jellyfin) zizmor (https://github.com/zizmorcore/zizmor) The LaTeX Project (https://www.latex-project.org/) 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 Guests: Andrew Nesbitt and Benjamin Nickolls.

JavaScript is missing a built-in way to make variables reactive—but Signals might change that. Scott and Wes break down what Signals are, how they compare to React state, and how different frameworks like Preact, Solid, Vue, and Qwik are already using them. Show Notes 00:00 Welcome to Syntax! 01:49 Brought to you by Sentry.io. 02:28 Why JavaScript needs reactive variables. 03:16 What exactly are signals? Signals Proposal. 04:02 Understanding computed state. 04:59 How signals differ from React state. 06:12 How different frameworks handle reactivity. 07:09 DOM Parts. Pull Request. 07:26 HTML Template Instantiation. Template Instantiation. 09:10 Comparing signals across frameworks: Preact, Solid.js, Vue, and more. PreactJS Signals. Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott: X Instagram Tiktok LinkedIn Threads Randy: X Instagram YouTube Threads

Xuan-Son Nguyen opened a low-level code PR written 99% by DeepSeek-R1, Adam Wathan announces the release of Tailwind CSS 4.0, Matheus Lima opens up the Computer Science history books to create list of influential papers, Namanyay Goel thinks AI is creating a generation of illiterate programmers & Russell Baylis shares what he's learned about optimizing WFH lighting to reduce eye strain.

Xuan-Son Nguyen opened a low-level code PR written 99% by DeepSeek-R1, Adam Wathan announces the release of Tailwind CSS 4.0, Matheus Lima opens up the Computer Science history books to create list of influential papers, Namanyay Goel thinks AI is creating a generation of illiterate programmers & Russell Baylis shares what he's learned about optimizing WFH lighting to reduce eye strain.

Xuan-Son Nguyen opened a low-level code PR written 99% by DeepSeek-R1, Adam Wathan announces the release of Tailwind CSS 4.0, Matheus Lima opens up the Computer Science history books to create list of influential papers, Namanyay Goel thinks AI is creating a generation of illiterate programmers & Russell Baylis shares what he's learned about optimizing WFH lighting to reduce eye strain.

In this episode, we dive deep into the dynamics of working solo versus being part of a development team. From the ideal team composition at large companies to the challenges of maintaining open source projects, our hosts share their experiences and insights. Learn about the crucial roles of designers and product managers, the importance of documentation, and why even senior developers still Google Git commands. Whether you're a solo developer looking to collaborate or a team player wanting to improve your workflow, this episode has something for everyone. Chapter Marks00:00 - Introduction01:16 - The Perfect Team Composition02:44 - Different Approaches to Team Building04:37 - Working Without Designers: The FedEx Experience08:10 - Documentation and Project Requirements12:30 - The Role of Documentation in Team Success14:47 - Documentation's Impact on Career Growth15:14 - Onboarding and Documentation Connection16:51 - Open Source Project Management19:45 - Automation in Open Source22:34 - Deals for Devs: Managing Contributors25:29 - Branch Management and PR Workflows29:59 - Solo Development Practices31:21 - Git Commands and Team Workflows35:14 - Open Source Knowledge Barriers38:02 - The Importance of Admitting What You Don't Know39:15 - Episode Wrap-up LinksNick Taylor's Blog Post about GitHub Code Owners - https://dev.to/opensauced/supercharge-your-repository-with-code-owners-4clgB Dougie's GitHub Action for the "Take" command - https://github.com/bdougie/take-action/blob/main/action.ymlChantastic's Git Course on Epic Web - https://www.epicweb.dev/tutorials/git-fundamentalsGitHub Documentation on Squash Merging vs Rebase Merging - https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/about-pull-request-mergesMerge vs Rebase vs Squash - https://gist.github.com/mitchellh/319019b1b8aac9110fcfb1862e0c97fbGitHub Issue Forms Documentation - https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/syntax-for-issue-formsGitHub Pull Request Templates Guide - https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/creating-a-pull-request-template-for-your-repositoryGitHub Code Owners Documentation - https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-ownersVirtual Coffee's Hacktoberfest Resources - https://hacktoberfest.virtualcoffee.io/OpenSauce - https://opensauced.pizza/The "Working Genius" Assessment - https://www.workinggenius.com/Gun.io Work Personality Quiz - https://gun.io/workstyle/Deals for Devs Project - https://www.dealsfordevs.com/GitHub Actions Documentation on Release Management - https://docs.github.com/en/actions/sharing-automations/creating-actions/releasing-and-maintaining-actionsConventional Commits Documentation - https://www.conventionalcommits.org/en/v1.0.0/

Die Transparenz von Open Source schreibt Geschichten, die erzählt werden wollen50% des Begriffes “Open Source” besteht aus dem Wort “Open”. Ok. Für diese Erkenntnis muss man nun nicht studiert haben. Open bzw. Offen bzw. Transparenz bezieht sich dabei nicht nur auf den Source Code selbst, sondern i.d.R. auf alles, was das entsprechende Projekt betrifft. Dazu zählen u.a. für jedermann einsehbare Bug-Reports und Pull Requests. Wenn man dies nun mit weltweiter Kollaboration verschiedener Menschen und Kulturen mixt, ist eins vorprogrammiert: Kreativität, WTF-Momente, persönliche Schicksale und Geschichten, die erzählt werden wollen. Diese Episode erzählt einige dieser Open Source Geschichten. Wir sprechen darüber, wie man Douglas Crockford dazu bringt, über JavaScript Code zu streiten, wann für einen Pull Request eine eigene Torte gebacken wird und warum dies dann zu einem Merge führt, sowie wann und warum Unit Tests fehlschlagen, wenn diese in Australien ausgeführt werden. Es geht aber auch um traurige Seiten und persönliche Schicksale. Zum Beispiel eine Gefängnisverurteilung eines Maintainers von einem Projekt, welches 26 Millionen Downloads pro Woche hat, eine Krebserkrankungen mit verbundener Anteilnahme der Community und wie der Maintainer die Zukunft des Projektes sichert für die Zeit, wenn er nicht mehr da ist oder auch wie die Maidan-Revolution und der Ukraine-Krieg Open Source beeinflussen.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

Do you try to understand the pull request you review?

If my manager gives me a lot of pull request comments does that reflect poorly on me?

Podcasting 2.0 June 7th 2024 Episode 182: "Drop the Dongle" Adam & Dave are joined by OG Podcast developer Andrew Grumet ShowNotes We are LIT Andrew Grumet - OG Podcaster Dev and wherever.audio Bitcoin will be a marketing benefit GetAlby Issues Breez Brings Bitcoin’s Lightning Network To Every Crypto Wallet - Bitcoin Magazine - Bitcoin News, Articles and Expert Insights Greenlight and Breez SDK CLI does Bolt12 Cake wallet Zeus Mobile for keysend receive Pod-mobile | Audiosigma add keysend implementation for LND backend by bernii · Pull Request #1129 · lnbits/lnbits ------------------------------------- MKUltra chat Transcript Search What is Value4Value? - Read all about it at Value4Value.info V4V Stats Last Modified 06/07/2024 15:01:33 by Freedom Controller

Podcasting 2.0 May 31st 2024 Episode 181: "Bucket of Chicks" Adam & Dave talk wallets, music, local programming and chicks man! ShowNotes We are LIT Nashville wrap up and tease Ainsley Track Pocketcasts - heard V4V rumblings - 2 years ago we pitched it to Matt Local Podcasts Project - Playlist - like OPML subscription lists - need to know if playlists work this way Sam and Castopod working on Activity streams into ActivityPub YAY! 8 New Findings About The Podcast Audience From Cumulus Media’s 2024 Audioscape | Westwood One 3. The median age of the podcast audience has held at 34 despite massive audience growth The podcast audience is thirteen years younger than the median age of AM/FM radio listeners and 22 years younger than linear television where audiences have a median age of 56. TV is what’s playing in God’s waiting room. Link This is the "secret" formula: "That was the thing that Adam and I agreed on. Adam being the user, and I being the developer. Of course it was his trying to be a developer, and me trying to be a user that was the spark that created the boom. We both made it safe for amateurs to do what we do. That's why podcasting, unlike the music industry, never went to war with its users." Scripting News: Tech is about people Costello's Bands and Bitcoin Bands at Bitcoin '24 Nashville | Geyser Need a helipad page Music License Wallets Get Alby LNBits Business Opportunity Growth in General Apollo II update and possible pool MikeHero DSP | Audiosigma add keysend implementation for LND backend by bernii · Pull Request #1129 · lnbits/lnbits ------------------------------------- MKUltra chat Transcript Search What is Value4Value? - Read all about it at Value4Value.info V4V Stats Last Modified 05/31/2024 14:59:52 by Freedom Controller

Join Scott as he starts working on ESP BLE pairing and bonding (aka initiating encrypted connections), demonstrates building CircuitPython with asyncio python scripts and answers questions. https://github.com/tannewt/circuitpython/tree/embedded-build https://github.com/tannewt/embedded Thanks to dcd for timecodes: 0:00 Getting Started 1:56 Hello - welcome to Deep Dive w/Scott 3:00 Adafruit Feather nRF25840 bluefruit feather example 3:09 We will talk about Bluetooth Low Energy today 4:47 Join #live-broadcast-chat on Discord at http://adafrui.it/discord 5:15 BLE vs Bluetooth "Classic" (older devices) 6:06 ESP32-S2-DevKitC-1 V1.o S2 SOLO N4R2 (bad example, no BLE support :-) ) 6:16 ESPS3 BLE + WiFi 7:43 LED Glasses nRF52840 8:42 Creating Servers and Dynamic Services - from two weeks ago 10:00 Pull Request to add ability to create services (e.g. HID services ) 10:45 Pairing & Bonding / services / characteristics (create a keyboard) 12:20 esp-matter protocol - hamslabs 13:35 PR: Add ESP BLE GATT server support #9222 13:46 also issue Add ESP BLE GATT server support #5926 14:41 Code review process inner workings 15:29 ESP32-H4 and ESP32-P4 annonuncement on espressif.com (not available yet) - but see ESP-IDF SDK 16:14 also added C2 support to circuitpython ( but it ran out of memory ) maybe only one of WiFi or BLE at a time 17:08 and C6 - no RMT neopixel support, but it does have BLE 19:45 using TinyUSB on devices with SPI but no USB 21:03 BLE_EXT_ADV ( extended advertising feature of BLE 5) 24:39 yesterdays ESP32 issue - better debugging by enabling better debug logging 25:40 pondering interrupt handlers and weak functions 26:27 Review files changed in PR9222 26:35 Trade-off OTA for BLE on new 4MB boards 28:00 adding -u to LDFLAGS to deal with weak symbols 29:18 Pairing and Bonding not supported yet 29:50 then maybe look at building CP with new build systems 31:29 Pairing and Bonding ... 33:35 ESP IDF stores bonding information in NVS partion 34:03 look on github circuitpython/tests/circuitpyton-manual for example code (but no BLE code) 34:14 adafruit/Adafruit_CircuitPython_BLE/examples/ble_hid_central.py ( all commented out) 36:13 adafruit/Adafruit_CircuitPython_BLE/examples/ble_current_time_service.py 36:37 iPhone pairing can deliver time 37:08 github espressif/esp-idf/examples/bluetooth/nimble blecent and bleprph 38:38 bleprph/tutorial bleprph_walkthrough.md 41:35 watch running CP and BLE and updating time 43:38 view example for bleprph/main/main.c code 44:14 CP repo ports/espressif/common-hal/_bleio/PacketBuffer.c 44:26 and ports/espressif/common-hal/_bleio/Connection. ( TODO:Implement this ) 46:58 using copilot to make printf debugging faster! 50:54 also Adapter.c 53:39 refer to online CP docs for _bleio 56:20 git switch ble_bonding 58:03 clangd feature for genertated tags in editor ( mentioned a few weeks ago )o 59:54 S3 WROOM-2 N32R8V 1:01:02 set up window for serial output capture and CP serial REPL 1:06:21 update code.py - start test / paired - decode connections 1:09:20 CP doesn't have audio over BLE 1:17:36 use chatgpt to convert C #defines to switch statement function 1:25:54 save the work in process and switch to embedded-build git repo 1:27;20 fetch and pip install the build tool 1:31:28 review the build code in build_circuitpython.py 1:34:44 build tool uses python asyncio to get parallelism 1:35:38 return to the perfetto.dev chart of the threads to see basic trace information 1:43:02 when you call an async function, it doen't even begin to execute it - it just wraps it so you can run it later1:44:20 discussion of zig build system 1:45:30 rerun the build - this time with some more parallel tasks 2:01:43 TODO: add memoization to the build system in the future 2:04:01 push the code tannewt embedded build and wrap up 2:11:10 have a great weekend Visit the Adafruit shop online - http://www.adafruit.com ----------------------------------------- LIVE CHAT IS HERE! http://adafru.it/discord Subscribe to Adafruit on YouTube: http://adafru.it/subscribe New tutorials on the Adafruit Learning System: http://learn.adafruit.com/ -----------------------------------------

Apple @ Work is exclusively brought to you by Mosyle, the only Apple Unified Platform. Mosyle is the only solution that integrates in a single professional-grade platform all the solutions necessary to seamlessly and automatically deploy, manage & protect Apple devices at work. Over 45,000 organizations trust Mosyle to make millions of Apple devices work-ready with no effort and at an affordable cost. Request your EXTENDED TRIAL today and understand why Mosyle is everything you need to work with Apple. In this episode of Apple @ Work, I talk with Mike McNeil from Fleet about their new maintenance windows feature. Connect with Bradley Twitter LinkedIn Listen and subscribe Apple Podcasts Overcast Spotify Pocket Casts Castro RSS Listen to Past Episodes

How do senior devs feel when a junior deny their pull request?

On today's show, we cover a variety of topics. Ben talks about overcompensation at work; and, how we often swing way too hard in one direction as the first signs of a challenge. Carol talks about how her current task got away from her; and, how she suddenly founder herself creating a Pull Request with 84 files in it. Tim talks about the generation smoking ban going into effect in England. And Adam talks about the challenges of mentoring junior developers; and, how hard it is to have enough "right sized" tasks ready for them to work on.Follow the show and be sure to join the discussion on Discord! Our website is workingcode.dev and we're @WorkingCodePod on Twitter and Instagram. New episodes drop weekly on Wednesday.And, if you're feeling the love, support us on Patreon.With audio editing and engineering by ZCross Media.Full show notes and transcript here.

What tone to use in pull requests when making suggestions?

Присоединяйтесь к брейншторму "как улучшить тесты", добавляйте свой Pull Request в https://github.com/dotnetmore/shit-testsТесты должны быть понятные, говорили они. Тесты должны быть короткие, учили они. Но что делать, если только arrange занимает 20 строк? А если act - больше чем просто вызов метода? А если логика кода достаточно сложная, так что в однострочный assert не влезает?Спасибо всем кто нас слушает. Ждем Ваши комментарии.Бесплатный открытый курс "Rust для DotNet разработчиков": https://www.youtube.com/playlist?list=PLbxr_aGL4q3S2iE00WFPNTzKAARURZW1ZShownotes: 00:00:00 Вступление00:02:30 DRY в тестах00:13:15 Как рефакторить и код, и тесты одновременно00:20:30 А что если делать маленькие классы и маленькие тесты?Ссылки:- https://github.com/dotnetmore/shit-tests : Тесты, которые мы разбирали в выпуске- https://fluentassertions.com/introduction : Fluent Assertions- https://nsubstitute.github.io/ : NSubstitute - https://www.testrail.com/blog/5-bdd-tools-c-codebases/ : Обзор BDD фреймворков - https://github.com/VerifyTests/Verify/ : Verify для сложного assert- https://github.com/VerifyTests/Verify.Serilog : Verify для логов 0_oВидео: https://youtube.com/live/dPH6W7yMJPw Слушайте все выпуски: https://dotnetmore.mave.digitalYouTube: https://www.youtube.com/playlist?list=PLbxr_aGL4q3R6kfpa7Q8biS11T56cNMf5Обсуждайте:- Telegram: https://t.me/dotnetmore_chatСледите за новостями:– Twitter: https://twitter.com/dotnetmore– Telegram channel: https://t.me/dotnetmoreCopyright: https://creativecommons.org/licenses/by-sa/4.0/

Links from the show:PHP[TEK] 2024 - Home Page So You Think You Know Git - FOSDEM 2024 - YouTubeWhite House wants Moon to have its own time zoneThe XZ Backdoor: Everything You Need to Know | WIREDThe Mystery of ‘Jia Tan,' the XZ Backdoor Mastermind | WIREDThe level of sophistication of the XZ attack is - Infosec ExchangeThis episode of PHPUgly was sponsored by:Honeybadger.ioBuilt for Developers. Monitoring doesn't have to be so complicated. That's why we built the monitoring tool we always wanted: a tool that's there when you need it, and gets out of your. Everything you need to keep production happy so that you can keep shipping. Deploy with confidence and be your team's DevOps hero.https://www.honeybadger.io/php[architect]php[architect] magazine is the only technical journal dedicated exclusively to the world of PHP. We are committed to spreading knowledge of best practices in PHP. With that purpose, the brand has expanded into producing a full line of books, hosting online and in-person web training, as well as organizing multiple conferences per year.https://www.phparch.com PHPUgly streams the recording of this podcast live. Typically every Thursday. Come and join us, and subscribe to our Youtube Channel, Twitch, or Twitter. Also, be sure to check out our Patreon Page.Twitter Account https://twitter.com/phpuglyMastodon Account https://phparch.social/@phpuglyHost:Eric Van Johnson | Mastodon: @eric@phpartch.socialJohn Congdon | Mastodon: @john@phpartch.socialStreams:Youtube ChannelTwitchPowered by RestreamPatreon PagePHPUgly Anthem by Harry Mack / Harry Mack Youtube ChannelThanks to all of our Patreon Sponsors:***** PATREON SUPPORTS SPONSOR LEVEL **Honeybadger (https://honeybader.io)** Patreon Supports **ButteryCrumpetFrank WDavid QBoštjan OMarcusShelby CS FRodrigo CBillyDarryl HKnut BDmitri GElgimboMikePageDevKenrick BKalen JR. C. S.Peter AHoneybadgerHolly SClayton SRonny NBen RAlex BKevin YWayneJeroen FahinkleChris CSteve MRobert SThorstenEmily JAndrew WulrikJohn CJames HEric MEd GRirielilHermitChampJeffrey DChris BTore BBek JDonald GPaul KDustin UMel SSeba RJoe F

How do you keep your pull request small?

Podcasting 2.0 March 15th 2024 Episode 171: "Misaligned Expectations" Adam & Dave are joined by Nathan Gathright of the brand new Episodes.Fm ShowNotes We are LIT TLV records people! Nathan Gathright PI storing user activity stream data Metadata drama Proposal: implement custom TLV records for spontaneous payments by rdmitr · Pull Request #273 · lightningdevkit/ldk-node · GitHub Fedifying the Index ------------------------------------- MKUltra chat Transcript Search What is Value4Value? - Read all about it at Value4Value.info V4V Stats Last Modified 03/15/2024 14:09:49 by Freedom Controller

Join Dan Vega and DaShaun Carter for the latest updates from the Spring Ecosystem. In this episode, we're uncovering fresh repositories and invaluable resources that have just landed for the Spring Office Hours community. We will also address one of the most popular questions: how do you kickstart your journey in contributing to Open Source Software? Join our live stream to get your questions answered, or watch the replay on your preferred podcast platform.Show NotesState of Spring SurveyCloud Foundry Weekly - Season 1 Episode 1RedMonk Top 20 Languages over time: January 2024Netflix Blog: Bending pause times to your will with Generational ZGCBuilding Intelligent Applications with Spring AI GitHub Repositories Learning Spring ResourcesSpring Office Hours Discussions

On today's episode, Elixir Wizards Owen Bickford and Dan Ivovich compare notes on building web applications with Elixir and the Phoenix Framework versus Ruby on Rails. They discuss the history of both frameworks, key differences in architecture and approach, and deciding which programming language to use when starting a project. Both Phoenix and Rails are robust frameworks that enable developers to build high-quality web apps—Phoenix leverages functional programming in Elixir and Erlang's networking for real-time communication. Rails follows object-oriented principles and has a vast ecosystem of plug-ins. For data-heavy CRUD apps, Phoenix's immutable data pipelines provide some advantages. Developers can build great web apps with either Phoenix or Rails. Phoenix may have a slight edge for new projects based on its functional approach, built-in real-time features like LiveView, and ability to scale efficiently. But, choosing the right tech stack depends heavily on the app's specific requirements and the team's existing skills. Topics discussed in this episode: History and evolution of Phoenix Framework and Ruby on Rails Default project structure and code organization preferences in each framework Comparing object-oriented vs functional programming paradigms CRUD app development and interaction with databases Live reloading capabilities in Phoenix LiveView vs Rails Turbolinks Leveraging WebSockets for real-time UI updates Testing frameworks like RSpec, Cucumber, Wallaby, and Capybara Dependency management and size of standard libraries Scalability and distribution across nodes Readability and approachability of object-oriented code Immutability and data pipelines in functional programming Types, specs, and static analysis with Dialyzer Monkey patching in Ruby vs extensible core language in Elixir Factors to consider when choosing between frameworks Experience training new developers on Phoenix and Rails Community influences on coding styles Real-world project examples and refactoring approaches Deployment and dev ops differences Popularity and adoption curves of both frameworks Ongoing research into improving Phoenix and Rails Links Mentioned in this Episode: SmartLogic.io (https://smartlogic.io/) Dan's LinkedIn (https://www.linkedin.com/in/divovich/) Owen's LinkedIn (https://www.linkedin.com/in/owen-bickford-8b6b1523a/) Ruby https://www.ruby-lang.org/en/ Rails https://rubyonrails.org/ Sams Teach Yourself Ruby in 21 Days (https://www.overdrive.com/media/56304/sams-teach-yourself-ruby-in-21-days) Learn Ruby in 7 Days (https://www.thriftbooks.com/w/learn-ruby-in-7-days---color-print---ruby-tutorial-for-guaranteed-quick-learning-ruby-guide-with-many-practical-examples-this-ruby-programming-book--to-build-real-life-software-projects/18539364/#edition=19727339&idiq=25678249) Build Your Own Ruby on Rails Web Applications (https://www.thriftbooks.com/w/build-your-own-ruby-on-rails-web-applications_patrick-lenz/725256/item/2315989/?utm_source=google&utm_medium=cpc&utm_campaign=low_vol_backlist_standard_shopping_customer_acquisition&utm_adgroup=&utm_term=&utm_content=593118743925&gad_source=1&gclid=CjwKCAiA1MCrBhAoEiwAC2d64aQyFawuU3znN0VFgGyjR0I-0vrXlseIvht0QPOqx4DjKjdpgjCMZhoC6PcQAvD_BwE#idiq=2315989&edition=3380836) Django https://github.com/django Sidekiq https://github.com/sidekiq Kafka https://kafka.apache.org/ Phoenix Framework https://www.phoenixframework.org/ Phoenix LiveView https://hexdocs.pm/phoenixliveview/Phoenix.LiveView.html#content Flask https://flask.palletsprojects.com/en/3.0.x/ WebSockets API https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API WebSocket connection for Phoenix https://github.com/phoenixframework/websock Morph Dom https://github.com/patrick-steele-idem/morphdom Turbolinks https://github.com/turbolinks Ecto https://github.com/elixir-ecto Capybara Testing Framework https://teamcapybara.github.io/capybara/ Wallaby Testing Framework https://wallabyjs.com/ Cucumber Testing Framework https://cucumber.io/ RSpec https://rspec.info/

On today's episode of Ruby for All, Andrew and Julie kick things off with a nostalgic discussion about the beloved game, “Plants vs. Zombies.” Julie explains the game's concept, setting the stage for a lively conversation that brings us into their gaming experiences and preferences, including cooperative versus competitive gaming. The conversation then transitions to topics relevant to the workplace, including teamwork and communication in a new project that Andrew introduces. They touch on the organizational structure at Podia, the project process, and roles within project teams. Code reviews within project teams are also explored, with insights into how they handle code reviews, expertise in specific code bases, and knowledge sharing strategies to mitigate the “bus factor.” Go ahead and download this episode now! [00:00:11] Andrew and Julie discuss the game “Plants vs. Zombies.” Julie explains the game's concept and Andrew talks about Call of Duty Zombies. [00:01:56] Julie tells us she like cooperative games vs. competitive gaming.  Andrew explains different gaming genres, including strategy, shooting, and RPG. [00:03:20] They discuss playing Guitar Hero, Rock Band, and Mario Kart.  [00:04:54] Andrew introduces a new project and emphasizes the importance of teamwork and communication. [00:06:18] Andrew explains the organizational structure at Podia, the project process, and roles within project teams.[00:09:22] Julie asks how many engineers there are at Podia and she inquiries about code reviews within project teams. [00:10:50] Andrew mentions expertise in specific code bases at Podia and how they track it, also, he discusses knowledge sharing to mitigate the “bus factor” within the team.[00:12:36] Julie wonders if a team of two typically consists of a backend and a frontend person. Andrew explains that at Podia, they have full-stack engineers, but some specialize more in frontend or backend work based on their skills and preferences. [00:13:18] A question comes up if Andrew does a lot of pairing, and he explains that pairing frequency varies among team members and shares his preference for daily pairing. [00:15:55] Andrew shares his assumption that when someone sends a pull request, their code is expected to work, emphasizing that code review serves other purposes. [00:16:27] Andrew discusses the purpose of code reviews and how they should focus on more than just syntax. He clarifies that code review helps ensure the right approach and maintains codebase integrity.[00:17:40] Julie mentions her habit of asking if a particular approach is correct during code reviews and discusses the importance of conventions and patterns. She also talks about her experience with cross-team pairing and how it helps identify edge cases and align with other teams' practices. [00:18:56] Andrew discusses the challenges of code review when teams are large and points out the potential for one person to become the primary reviewer.[00:20:43] Andrew suggests that small, specific pull requests with areas of interest can ease code review and mentions that Podia's teams are smaller, and codebases are more unified. [00:22:23] Julie shares that her organization had 70 engineers and how cross-team pairing benefits knowledge sharing. She reflects on the learning experience when joining a new team and processes can vary, suggesting that individuals can introduce their preferred practices.[00:24:15] Julie asks how Andrew discovers bugs in his code, and he explains Podia's error monitoring and support team processes for bug triage. Panelists:Andrew MasonJulie J.Sponsors:HoneybadgerLinks:Andrew Mason TwitterAndrew Mason WebsiteJulie J. TwitterJulie J. WebsitePlants vs. Zombies (00:11) - Discussion of "Plants vs. Zombies" and gaming preferences (01:56) - Exploring different gaming genres and cooperative gaming (03:20) - Playing games like Guitar Hero, Rock Band, and Mario Kart (04:54) - Introduction to a new project and teamwork importance (06:18) - Organizational structure and project processes at Podia (09:22) - Number of engineers at Podia and code review practices

Reimagine version control systems with Scott Chacon, Co-founder of GitHub and GitButler. Because, even Scott, a Git Veteran, will admit it: ``` Git is a pain sometimes.

New Laravel features are making deployment easier than ever! In our second episode of season six, we explore various topics, screencasting.com by Aaron Francis, the Livewire stack within Breeze, new features in Laravel Prompts, Laravel Pail, a range of hosting choices, and an exciting addition – the new Envoyer tab now accessible within Forge. Additionally, Taylor addresses one of the most frequently asked questions and guides us through the steps involved in reviewing and merging pull requests. Screencasting - https://screencasting.com/ Taylor Otwell's Twitter - https://twitter.com/taylorotwell Laravel Twitter - https://twitter.com/laravelphp Laravel Website - https://laravel.com/ Laravel Folio - https://laravel.com/docs/10.x/folio Livewire Volt - https://livewire.laravel.com/docs/volt Tighten.co - https://tighten.com/ Laravel Pail - https://github.com/laravel/pail       Docker - https://www.docker.com/company/ Jetstream - https://jetstream.laravel.com/ Breeze - https://laravel.com/docs/10.x/starter-kits#laravel-breeze Blade - https://laravel.com/docs/10.x/blade Prompts - https://laravel.com/docs/10.x/prompts Forge - https://forge.laravel.com/ Envoyer - https://envoyer.io/ Vapor - https://vapor.laravel.com/ Ruby on Rails - https://rubyonrails.org/ Digital Ocean - https://www.digitalocean.com/ Fly.IO - https://fly.io/ -----Editing and transcription sponsored by Tighten.

Subscribe to The Realignment on Supercast to support the show and access all of our bonus content: https://realignment.supercast.com/.The Pull Request: https://www.callin.com/show/the-pull-request-ucnDJmEKAaBalaji Srinivasan's Network State Realignment Episode: https://podcasts.apple.com/us/podcast/264-balaji-srinivasan-how-and-why-to-start-new-countries/id1474687988?i=1000569114998The Network State: https://thenetworkstate.com/Antonio's Previous Realignment Appearance: https://podcasts.apple.com/fr/podcast/140-antonio-garc%C3%ADa-mart%C3%ADnez-americas-thirty-years-war/id1474687988?i=1000528206653&l=enREALIGNMENT NEWSLETTER: https://therealignment.substack.com/BOOKSHOP: https://bookshop.org/shop/therealignmentEmail us at: realignmentpod@gmail.comDuring our Labor Day Weekend hiatus, Marshall joined previous Realignment guest Antonio García Martinez's Callin podcast The Pull Request. They discussed "What's broken, why, and how to fix it (or do we just move to Balaji's network state?)"