Podcasts about GitHub

This week, we talk to Nick Craigwood, the creator and principal developer of rclone, a very popular open-source tool for copying data to and from cloud providers. Rclone is downloaded roughly 250,000 times each month, and has over 30,000 stars on GitHub. There are six core developers, and a great community of users and other developers at rclone.org. We talk a little bit about Nick's development philosophy, which is that he doesn't mind adding features - as long as they don't break backwards compatibility. Then we talk about how rclone works, and what it's like to sync a filesystem to an object store – including support for multi-part uploads and downloads. We also talk about rclone's encryption support, while Nick was “relaxing” on holiday. We then talked about how rclone can be used to minimize the risk of backing up to any one cloud provider, preventing things like what happened during the OVH fire earlier in 2021. We also discuss some strategies, such as backing up directly to two different clouds, versus backing up to one, then syncing to another – and how CloudFlare's R2 might figure into things. Finally, we talk about Nick's plans for rclone's future, such as making their web UI better to increase usability for many more people – while not sacrificing the command line. Join us for a fascinating episode, the first one where we're talking to the creator of the tool in question. Don't forget the drawing for a free e-book version of Modern Data Protection. All you have to do to be eligible is sign up for my newsletter at https://www.backupcentral.com/subscribe-to-our-newsletter/

Are we already living in a metaverse? Follow Us Frank: Twitter, Blog, GitHub James: Twitter, Blog, GitHub Merge Conflict: Twitter, Facebook, Website, Chat on Discord Music : Amethyst Seer - Citrine by Adventureface ⭐⭐ Review Us (https://itunes.apple.com/us/podcast/merge-conflict/id1133064277?mt=2&ls=1) ⭐⭐ Machine transcription available on http://mergeconflict.fm

About ClintonClinton Herget is Principal Solutions Engineer at Snyk, where he focuses on helping our large enterprise and public sector clients on their journey to DevSecOps. A seasoned technologist, Clinton spent his 15+ year career prior to Snyk as a web software engineer, DevOps consultant, cloud solutions architect, and technical director in the systems integrator space, leading client delivery of complex agile technology solutions. Clinton is passionate about empowering software engineers and is a frequent conference speaker, developer advocate, and everything-as-code evangelist.Links:Try Snyk for free today at:https://app.snyk.io/login?utm_campaign=Screaming-in-the-Cloud-podcast&utm_medium=Partner&utm_source=AWS TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: This episode is sponsored in part by my friends at ThinkstCanary. Most companies find out way too late that they've been breached. ThinksCanary changes this and I love how they do it. Deploy canaries and canary tokens in minutes and then forget about them. What's great is the attackers tip their hand by touching them, giving you one alert, when it matters. I use it myself and I only remember this when I get the weekly update with a “we're still here, so you're aware” from them. It's glorious! There is zero admin overhead  to this, there are effectively no false positives unless I do something foolish. Canaries are deployed and loved on all seven continents. You can check out what people are saying at canary.love. And, their Kub config canary token is new and completely free as well. You can do an awful lot without paying them a dime, which is one of the things I love about them. It is useful stuff and not an, “ohh, I wish I had money.” It is speculator! Take a look; that's canary.love because it's genuinely rare to find a security product that people talk about in terms of love. It really is a unique thing to see. Canary.love. Thank you to ThinkstCanary for their support of my ridiculous, ridiculous non-sense.  Corey: Writing ad copy to fit into a 30 second slot is hard, but if anyone can do it the folks at Quali can. Just like their Torque infrastructure automation platform can deliver complex application environments anytime, anywhere, in just seconds instead of hours, days or weeks. Visit Qtorque.io today and learn how you can spin up application environments in about the same amount of time it took you to listen to this ad.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. This promoted episode features Clinton Herget, who's a principal solutions engineer at Snyk. Or ‘Snick.' Or ‘Cynic.' Clinton, thank you for joining me, how the heck do I pronounce your company's name?Clinton: That is always a great place to start, Corey, and we like to say it is ‘sneak' as in sneaking around or a pair of sneakers. Now, our colleagues in the UK do like to say ‘Snick,' but that is because they speak incorrectly. We will accept it; it is still wrong. As long as you're not saying ‘Sink' because it really has nothing to do with plumbing and we prefer to avoid that association.Corey: Generally speaking, I try not to tell other people how to run their business, but I will make an exception here because I can't take it anymore. According to CrunchBase, your company has raised $1.4 billion. Buy a vowel for God's sake. How much could it possibly cost for a single letter that clarifies all of this? My God.Clinton: Yeah, but then we wouldn't spend the first 20 minutes of every sales conversation talking about how to pronounce the company name and we would need to fill that with content. So, I think we're just going to stay the course from here on out.Corey: I like that. So, you're a principal solutions engineer. First, what does that do? And secondly, I've known an awful lot of folks who I would consider problem engineers, but they never self-describe that way. It's always solutions-oriented?Clinton: Well, it's because I worked for Snyk, and we're not a problems company, Corey, we're a solutions company.Corey: I like that.Clinton: It's an interesting role, right, because I work with some of our biggest customers, a lot of our strategic partners here in North America, and I'm kind of the evangelist that comes out and says, “Hey, here's what sucks about being a developer. Here's how we could maybe be better.” And I want to connect with other engineers to say, “Look, I share your pain, there might be an easier way, if you, you know, give me a few minutes here to talk about Snyk.”Corey: So, I've seen Snyk around for a while. I've had a few friends who worked there almost since the beginning and they talk about this thing—this was before, I believe, you had the Dobermann logo back in the early days—and I keep periodically seeing you folks in a variety of different contexts and different places. Often I'll be installing something from Docker Hub, for example, and it will mention that, oh, there's a Snyk scan thing that has happened on the command line, which is interesting because I, to the best of my knowledge, don't pay Docker for things that I do because, “No, I'm going to build it myself out of popsicle sticks,” is sort of my entire engineering ethos. But I keep seeing you in different cases where as best I am aware, I have never paid you folks for services. What is it you do as a company because you're one of those folks that I just keep seeing again and again and again, but I can't actually put my finger on what it is you do.Clinton: Yeah, you know, most people aren't aware that popsicle sticks are actually a CNCF graduated project. So, you know, that's that—Corey: Oh, and they're load-bearing in almost every piece of significant technical debt over the last 50 years.Clinton: Absolutely. Look at your bill of materials; it's there. Well, here's where I can drop in the other fun fact about Snyk's name, it's actually an acronym, right, stands for So, Now You Know. So, now you know that much, at least. Popsicle sticks, key component to any containerized infrastructure. Look, Snyk is a developer security company, right? And people hear that and go, “I'm sorry, what? I'm a developer; I don't give a shit about security.” Or, “I'm a security person”—Corey: Usually they don't say that out loud as often as you would hope, but it's like, “That's not true. I say that I care about security an awful lot.” It's like, “Yeah, you say that. Therein lies the rub.”Clinton: Until you get a couple of drinks in them at the party at re:Invent and then the real stuff comes out, right? No, Snyk is always been historically committed to the open-source community. We want to help open-source developers every bit as much as, you know, we're helping the engineers at our top-tier customers. And that's because fundamentally, open-source is inextricably linked to the way software is developed today, right? There is nobody not using open-source.And so we, sort of, have to be supporting those communities at the same time. And that fundamentally is where the innovation is happening. And you know, my sales guys hate when I say this, right, but you can get an amazing amount of value out of Snyk by using the freemium solution, using the open-source tooling that we've put out in the community, you get full access to our vulnerability database, which is updated every day, and if you're working on public projects, that's going to be free forever, right? We're fundamentally committed to making that work. If you're an enterprise that happens to have money to spend, I guess we'll take that too, right, but my job is really talking to developers and figuring out, you know, how can we reduce the amount of pain in your life through better security tooling?Corey: The challenging part is that your business, although I confess is significantly larger than my business, we're sort of on some level solving the same problem. And that sounds odd to say because I focus on fixing AWS bills and you're focused on improving developer security. But I'm moving up about six levels to the idea that there are only two big problems in the world of technology, in the world of companies for that matter. And the problem that we're solving is the worst one of the two. And that is reducing risk exposure.It is about eliminating downside. It's cost optimization, it's security tooling, it is insurance, et cetera, et cetera, et cetera. And the other problem, the one that I've always found, that is the thing that will get people actually excited rather than something they feel obligated to do is speeding up time to market, improving feature velocity, being able to deliver the right things sooner. That's the problem companies are biasing towards investing in extremely heavily. They'll convene the board to come up with an answer there.That said, you stray closer into that problem space than most security companies that I'm aware of just because you do in fact, speed up the developer process. It let people move faster, but do it safely at least is my general understanding. If I'm completely wrong on this, and, “Nope, we are purely risk mitigation, then this is going to look fairly silly, but it wouldn't be the first time I put my foot in my mouth.”Clinton: Yeah, Corey, it sounds like you really read the first three words of the website, right? “Develop fast. Stay secure.” And I think that fundamentally gets at the traditional alignment, where security equals slow, right, because risk mitigation is all about preventing problematic things from going into production. But only doing that as a stop gate at the end of the process, right, by essentially saying we assume all developers are bad and want to do bad things, and so we're going to put up this big gate and generate an 1100 page PDF, and then throw it back to them and say, “Now, go figure out all of the bad things you did and how to fix them. And by the way, you're already overshooting your delivery target.” Right? So, there's no way to win in that traditional model unless you're empowering developers earlier with the right context they need to actually write more secure code to begin with, rather than remediating after the fact when those fixes are actually most expensive.Corey: It's the idea of the people who want to slow down and protect things and not break are on the operation side of the world, and then you have developers who want to ship things. And you have that natural tension, so we're going to smash them together and call it DevOps, which at least if nothing else, leads to interesting stories on stages. Whether it actually leads to lasting cultural transformation is another thing entirely. And then someone said, “Well, what about security?” And the answer is, “We have a security department?” And the answer is, “Yeah, you know, those grumpy people that say no all the time whenever we ask if we could do anything.” “Oh, that security department. I ignore them and go around them instead.” And it's, “All right, well, we need help on that so we're going to smash them in, too.” Welcome to DevSecOps, which is basically buzzword-driven cultural development. And here we are. But there is something to be said for you can no longer be the Department of No. I would argue that you couldn't do that successfully previously, but at least now we're a little more aware of it.Clinton: I think you could certainly do that when you were deploying software a couple times a year, right? Because you could build in all of the time to very expensively and time consumingly fix things after the fact, right? We're no longer in that world. I think when you're deploying every few seconds or a few minutes, what you need is tooling that, first of all, runs at that speed, that gives developers insights into what risk are they bringing on board with that application once it will be deployed, but then also give them the context they actually need to fix things, right? I mean, regardless of where those vulnerabilities are found, it still ultimately is a line of code that has to be written by a developer and committed and pushed through a pipeline to make it back into production.And that's true, whether we're talking about application security and proprietary code, we're talking about vulnerabilities in open-source, vulnerabilities in the container, infrastructure as code. I mean, it used to be that a network vulnerability was fixed by somebody going into the data center, unplugging a Cat 5 cable and plugging it in somewhere else, right? I mean, that was the definition of network security. It was a hardware problem. Now, networking is software-defined. I mean [laugh]—Corey: Oh, the firewall I trust is basically a wire cutter. Yeah, cut through the entire cable, and that is the only secure firewall. And it's like, oh, no, no, there are side-channel attacks. It's not completely going to solve things for you. Yeah.Clinton: You know, without naming names, there are certainly vendors in the security space that still consider mitigation to be shutting down access to a workload, right. Like, let's remediate by taking this off of the internet and allowing it to no longer be accessible.Corey: I don't think it's come from a security standpoint, but that does feel like it's a disturbing proportion of Google's product strategy.Clinton: [laugh]. Absolutely. But you know, I do think maybe we can take the forward-looking step of saying there are ways to fix issues while keeping applications online at the same time. For example, by arming engineers with the security intelligence they need when they're making decisions about what goes into those applications. Because those wire cutters now, that's a line in a YAML file, right?That's a Kubernetes deployment, that's a CloudFormation template, and that is living in code in the same repo with everything else, with all of the other logic. And so it's fundamentally indistinguishable at the point where all security is really now developer security, except the security tooling available doesn't speak to the developer, it doesn't integrate into their workflow, it doesn't enable them to make remediations, it's still slapping them on the wrist. And this is why I think when you talk about—to invoke one of the most overused buzzwords in the security industry—when you talk about shifting left, that's really only half the story. I mean, if you're taking a traditional solution that's designed to slow things down, and shifting that into the developer workflow, you're just slowing them down earlier, right? You're not enabling them with better decision-making capacity so they can say, “Oh, I now understand the risks that I'm bringing on board by not sanitizing a string before I dump it into a SQL, you know, query. But now I understand that better because Snyk is giving me that information at the right time when I don't have to context switch out of it, which is, as I'm writing that line of code to begin with.”Corey: When I look at your website—and I'm really, really hoping that your marketing folks don't turn me into a liar on this one between the time we have recorded this and the time it sees the light of day in a week or so—it's notable because you are a security vendor, but you almost wouldn't know that from your website. And that is a compliment because at no point, start to finish, on the landing page at snyk.io do I see anything that codes to, “Hackers are coming to kill you. Give us money immediately to protect yourself.”You're not slinging FUD. You're talking entirely about how to improve velocity. The closest it gets to even mentioning security stuff is, “Ship on time with peace of mind.” That is as close as it gets to talking about security stuff. There is no fear based on this, and you don't treat people like children and say, “Security is extremely important.” “Thank you, Professor, I really appreciate that helpful tip.”Clinton: Yeah, you know, again, I think we take the very controversial approach that developers are not bad people who want to make applications less secure, right? And I think again, when you go into that 40-year trajectory of that constant tension between the engineering and the security sides of the house, it really involves certain perceptions about what those other people are like: security are bad and want to shut everything down; developers are, you know, wild cowboys who don't care about standardization and are just introducing a bunch of risk, right? Where Snyk comes in is fundamentally saying, “Hey, we can actually all live together in a world where we recognize there's pain on both sides?” And look, Corey, I'm coming to you after essentially waking up every day for 20 years and writing code of some kind or other, and I can tell you, developers are already scared enough, man. It is a fearful and anxiety ridden experience to know that you're not completely in command of what happens to that application once it leaves your IDE, right?You know at some point you're going to get that PDF dumped on you; you're going to have a build block, you're going to have a bug report come in from a very important customer at three o'clock in the morning and you're going to have to do something about it. I think every software engineer in the world carries that fear around with them. They don't have to be told you have the capacity to do bad stuff here and you should be better at it. What they need is somebody to tell them here's how to do things better, right? Here's not necessarily even why a cross-site scripting attack is dangerous—although we can certainly educate you on that as well—but here's what you need to do to remediate it. Here's how other developers have fixed that in applications that look like yours.And if you get that intelligence at the right point, then it becomes truly—to go back to your original question—it becomes about solutions rather than about problems, right? The last thing we ever want to do is adopt that traditional approach of saying, “You did a bad thing. It's your fault. You have to go figure out what to do. And then by the way, you have to do all the refactoring on top of that because we didn't tell you you did the bad thing until three weeks later when that traditional SaaS tool finally finished running.”Corey: Exactly. It's a question of how much can you reduce that feedback loop? If I get pinged 60 seconds after I commit code that there's a problem with it, great. I still have that in my head. Mostly. I hope. But if it's six months later it's, “Who even wrote this?” And I pull up git blame and, “Ah, crap, it was me. What was I possibly thinking back then?” It's about being able to move rapidly and fix things, I guess, as early in the process as possible, the whole shift-left movement. That's important. That's valuable.Clinton: Yeah, the context switching is so expensive, right, because the minute you switch away from that file, you're reading some documentation. You're out of that world. Most of the developer's time is spent getting into and out of different contexts. Once you're in there, I mean, you could rattle off 40 lines of code in a sitting and actually clear a ticket and you feel really good about yourself, right? The next day, when that comes back from QA saying you did something wrong here, that's the painful part of having to get back in.And by the time you've already done that, you've doubled the amount of time you've spent on that feature. So, it's all about integrating the right intelligence in the right context at the right time, and doing so in such a way that we're not throwing around blame, that we're not saying, “You should have known better.” We're saying, “We want to help you do this better because, you know, ultimately, you're going to write another SQL query. That's okay. We hope that maybe this will inspire you to sanitize those strings properly, and we're going to give you some suggestions on how to do that.”Corey: Yeah. Developer time is way more expensive than the infrastructure. That is, I think, a little understood facet of how this works from an engineering perspective because an awful lot of us came up in this industry considering our time to be free. Because we were doing this as a hobby in some cases, it was. When I was in my dorm room back many years ago, as I was basically in the process of being expelled from boarding school, it was very clearly my time was not worth a whole hell of a lot to anyone at that point.Speaking of expensive things, I want to talk for a minute about your pricing. And what I like about this is, let me be clear here. I am a big fan of taking shortcuts wherever I can, and one of the shortcuts I love doing—and I don't know if I've talked about it on this show before—is when I'm talking to a company and I need to figure out do they know what they're doing or are they clowns, I cheat and I go to the pricing page. And there are two big things that I look for, and you have them both.The first is that over on the far left side of the spectrum, it's do you have a free option? And yes, you do. And, “Click here to get started immediately.” Great because it's three in the morning, I need to get something done, I'm under a deadline, I do not have time for a conversation with sales, and as an engineer, I absolutely don't want to deal with that type of sales process because it feels weird to go and ask my boss to go ahead and sign off on something because I feel like my spending authority is capped at $20. Now that I have a little more context, I understand exactly why [laugh] my spending authority was capped at $20 back when I was an engineer.Clinton: Yeah, exactly right. And so it's not only that commitment to ensuring every software engineer in the world can have access to Snyk immediately by making one click because, you know, ultimately, we're committed to that community, right? There's 3 million developers using Snyk currently. That's about 10% of all engineers in the world. We're very proud of that number.We expect that to continue to grow and I think it shows that there is need out there, right? And if we can enable every engineer who's up at 3 a.m. faced with some security prospect to say, you know, it is as simple as getting a free account and getting a vulnerability report, getting the remediation advice, being able to sleep easier. I think we're successful as a company, regardless of what the bottom line is. But when you look at how to scale that into the enterprise, the way security solutions are priced, I mean, it's like throwing a bunch of wet noodles at the wall and seeing what sticks, right?Corey: Yes. And that's the other piece of your pricing that I like is a lot of people are going to be listening to that, what I'm saying right now about, “Oh, well, we have a free tier. Why do you think we're clowns?” It's, “Ah. Because the other end is just as important if not more so, which is there has to be an enterprise tier, and the price for that has got to be, ‘Click here to have a conversation.'” And the reason behind that is if you work in procurement, which is very often who's going to be reaching out on something like this, you are going to need custom contracts; you are going to want a long-term enterprise deal, and if the top tier is X dollars per thing that's already there, it reeks of unsophisticated vendor to a buyer in that position, and it makes the people a big blue chip companies think, “Oh, they don't know how to deal with someone at our scale.” Pricing his messaging, and I think people lose sight of that. You absolutely say the right things on both ends. I look at this, and there's nothing I would change or improve about your pricing page, which to be honest, is really rare.Clinton: I'm not sure all of our sales leaders would agree with you there, but I will pass that feedback along. Well, and the other thing I would add to that is, what everyone who's in a pricing conversation wants is predictability about what is this going to be in the future, right? And so we base our pricing on how many developers are in your organization, right? That's probably a number you know; that's probably a number that you can predict over time. We're not going to say, “How many CPUs are we using, right? What's the footprint of the cloud resources we're deploying to scan your stuff?” These are all things that you have very little control over and there is alchemy there that introduces a financial risk into that situation. And we're all about risk mitigation at scale, right?Corey: You don't pop up halfway through a cycle of, “Oh, you've gone on a hiring spree. Time to go ahead and pay us a bunch more money you didn't plan for or budget for.” I've had vendors pop up a quarter after I signed a deal—repeatedly—and it drives me up a wall because back in my engineering days, it was, great, now I have to spend time on this that I hadn't planned for; I have to go to my boss and ask for more money, never a great conversation, and as a cherry on top, I get to look like I don't know how to manage vendors for crap. It's just everyone is angry about those conversations. And even the salespeople reaching out had the decency to act a little sheepish about having to have that conversation with me.Clinton: The best ones do, at least. Well, and on top of that, you know, maybe that tool has been capped so that now your bills are breaking because you went one over your cap, right? So, I—Corey: Yeah. I love it. When I fail in production. That's my favorite thing. It's like, “All right, we're going to wind up not scanning for security stuff anymore. And if you go five beyond your cap, we're going to start introducing vulnerabilities.” It's, “That's awesome. Just, great plan.” But I'm kidding. I'm kidding. I want to be very clear, I have never heard a whisper of an actual vendor doing that, on purpose anyway.Clinton: Exactly. Right. And you know, look. We want to make it as easy as possible, and that's why, for example, we're on AWS Marketplace. You can use your existing EDP program to, you know, buy Snyk, just as—Corey: At 50% of your spend on Snyk then winds up counting toward your spend commit, which is always an interesting approach that some people are like, “Ooh. So, we can wind up transferring the money that we're spending on a vendor to count toward our commit?” But in many cases, it's how much are you spending on other third-party vendors in this space because you're getting excited about a few tens of thousands in most cases, and you have a $50 million annual [laugh] commit. What are you doing there, buddy? That's like trying to become a millionaire via credit card points. It doesn't usually pan out that way.Clinton: Fair enough. Yeah. And then look, we're very proud of that partnership with Amazon. And look if hey, if they can lock some of our customers into $15 million a year spend contracts, we'll take a few pennies on that, right?Corey: Oh, yeah, as a vendor, you'd be silly not too. It makes sense. But you're doing significantly more than that. As of this week being re:Invent week, you are—well, tell me about it.Clinton: Yeah, Corey, we are thrilled to announce this week that AWS is now integrating with Snyk's vulnerability database within Amazon Inspector. And this is going to bring the best-of-breed security intelligence with a curated vulnerability database, including all of our proprietary research around things like exploit maturity, reachability, vulnerable conditions, social trends on vulnerabilities, all available within Amazon Inspector to any developer utilizing it. We also have an AWS code pipeline integration that makes it easy for anyone utilizing AWS for your CI/CD to get immediate feedback on vulnerabilities in your applications as they move through that pipeline. And remember, we're never just going to say, “We've identified a vulnerability. Now, you need to figure out what to do with it.” We're always going to integrate the remediation advice because our audience at the end of the day is the developer whose job it is to make the fix and who has such a wide variety of responsibility these days, the best we can do is say to them, not just, “We found something wrong,” but, “Here's the solution that we think you should implement to get that secure code back out into production.”Corey: This episode is sponsored by our friends at CloudAcademy. That's right, they have a different lab challenge up for you called, “Code Red: Repair an AWS Environment with a Linux Bastion Host.” What does it do? Well, its going to assess your ability to troubleshoot AWS networking and security issues in a production like environment. Well, kind of, its not quite like production because some exec is not standing over your shoulder, wetting themselves while screaming. But..ya know, you can pretend in fact I'm reasonably certain you can retain someone specifically for that purpose should you so choose. If you are the first prize winner who completes all four challenges with the fastest time, you'll win a thousand bucks. If you haven't started yet you can still complete all four challenges between now and December 3rd to be eligible for the grand prize. There's only a few days left until the whole thing ends, so I would get on it now. Visit cloudacademy.com/corey. That's cloudacademy.com/C-O-R-E-Y, for god's sake don't drop the “E” that drives me nuts, and thank you again to Cloud Academy for not only promoting my ridiculous non sense but for continuing to help teach people how to work in this ridiculous environment.Corey: First, congratulations. It's neat to have a first-party integration like that with an AWS service, as opposed to, you know, their somewhat storied approach of, “Hey, it's an open-source project. We're just going to implement something that's API compatible ourselves, and irritate people.” Now, to be clear, my problem is not that you should expect to build anything and not face competition. My concern is a little bit more along the lines of, “Huh. Why is that same company always the first in line to compete with something.” Which is neither here nor there.Security is also one of those areas where I think competition is important. You want it continual background level of investment in the space because this stuff is super important. What I like about Snyk and a number of companies in this space is I know exactly where you stand. Let's contrast that for a second with AWS. You're integrating with Inspector, which is a great service, but you're not, I don't believe, integrating with their other security services such as [big breath in] Amazon Detective, the Audit Manager—if you want to consider that one of them—Amazon Macie, AWS Firewall Manager, AWS Shield, the Network Firewall, IoT Device Defender, CloudTrail, Config.Amazon Inspector is in one you're there, but not really Security Hub, or GuardDuty, or IAM itself. And I look at all of these services—I mean, IAM is free, of course, but the rest are very much not—and I do some basic arithmetic and I'm starting to realize that if I can figure all the various AWS security services together and what that's going to cost me, it turns out the answer is more than the data breach. So, on some level, it's one of those—at what point is it so confusing and it starts to look like a cross-sell deal between all of the different services, and turn them all on because you could ever have too much security, we still have to ship things eventually. And their security messaging has been extraordinarily confused for a long time. At some level, the fact that you are now integrating with them on the Inspector side means that for the first time, I think I understand what Inspector does now, which is more than a little messed up. But here we are.Clinton: Indeed. Well, the first thing I would say on that is, you know, stay tuned. As we move into the new year. I think you're going to see a lot more announcements both, you know, on the AWS side, but also kind of industry-wide and terms of integration with Snyk. That Vulnerability Database feed also, as you mentioned earlier, in use in Docker Hub, so anyone with Containers and Docker Hub can get advantage by scanning with our Snyk container tool.We have other integrations with Red Hat, for example. And there are actually many other companies utilizing that DB feed to, again, get access to that best in breed vulnerability data. When you talk about that model of, you know, being outcompeted on the security front, I think that's more difficult to do when you're actually talking about data, right? Like tooling, on some level—and I might get in trouble for saying this—but tooling is commodity, right? Somebody tomorrow is going to come out with a better tool to do a thing a little bit faster in a little bit more intuitive way. What can't be easily replicated is the data and intelligence behind that, right? And so that's why—Corey: Yeah, the secret sauce that makes you folks work is not the fact of, “Ah, we can fire off or catch a web hook, and then run the following command against the codebase.” That is—sure it's handy and it's useful and you're good at that, but that is not the reason that people become your customer.Clinton: Exactly right. Look, there's a lot of tools that can resolve the dependency tree within your open-source application, right? We can do that as well. We leverage a lot of open-source to do that, you know, we're very open with that. As I mentioned earlier, a lot of Snyk tooling is available on GitHub, you can see how it works, that code is public.Really the value we're providing is in that curated security research that our dedicated team is working on day in and day out and verifying public security data that's out in CVEs. Is this actually accurate? Do we agree with the severity rating? Might there be other factors that could modify that severity rating? What happens when you are scanning an application that might have some vulnerable conditions versus others? Don't you want to prioritize those vulnerabilities differently? What happens at runtime, right? If you're deploying an application to an EC2 instance with an OpenSSH ingress into your security group, that's going to make certain vulnerabilities a lot bigger risk than if you've got your IAC configured correctly, right? So, the really the overall mission of Snyk as we move into this broader, kind of, ASPM application, you know, security posture management space, is to say, how many different signals across the SDLC can we combine in intuitive ways for the developer to understand that risk at the right time with the right context and armed with the remediation advice to make a better decision as they're writing their code, you know, rather than after the fact? If I could sum it all up, kind of, that's the vision of where we are both today and ultimately where we're going.Corey: There also needs to be an understanding of who the customer is. If I go through the launch wizard and spin up in a brand new account, my first EC2 instance, and I spin up an instance by going through the wizard, the first thing it does is yell at me. Because, “Ah, that SSH port is open to the world.” Which you need to get into it, once it's there. So, it sets that up for me and yells at me all in the same breath. And it's, this is not a promising start; I kind of need that to get into it.Conversely, if you're not someone learning this stuff for the first time, and you're, oh I don't know, a production engineer at a bank, you care quite a bit differently in that use case about things like OpenSSH groups, it's security posture, et cetera, et cetera. An awful lot of the tooling is, “Ah, you're failing this benchmark, and this benchmark, and this benchmark,” from CIS and the rest of all these rules of, oh, you're not encrypting your data at rest. Well, it's in an AWS data center environment. Yeah, if someone could break in and steal the drives from multiple facilities and somehow recombine them together and get out alive, yeah, that's really not my threat model.But it's easy to turn it on and check a box and make an auditor go away. But that's not where I would spend the bulk of my energies if I'm trying to improve my security posture. And it turns into rote checklists super easily. The thing I've always appreciated about the stuff that you're tooling in the open-source world has highlighted is it's not nonsense. And I really can't understate just how valuable that is.Clinton: Absolutely. And that comes from a combination of signals across that SDLC, from the open-source, from the container, from the proprietary code, from the IAC, but then also what's happening at runtime, right? Like, how are those containers actually deployed onto EKS? What ports are open? What running binaries are on the container that might influence, you know, what packages you choose to upgrade, versus not?All of that matters, and what—you know, the issue I think now is getting that visibility to the developer at the right time so that they can make it actionable. And the thing about infrastructure as code, that I think that's really interesting and not super well understood is a lot of those defaults are really insecure. And developers have no idea, right? Like, they might not be aware that if you don't define that encryption for your S3 bucket, it'll happily deploy unencrypted, right? Yes, that's a compliance problem, but that's also potentially exacerbator have other vulnerabilities that might be in that application.But you only see those when you can combine and have a single pane of glass that gives you the runtime signaling plus everything that's happening in the application, armed with the correct information to actually remediate that at the time, and say, “Don't you think you wanted to add, you know, AES encryption to this bucket? Don't you think you wanted to close down port 22?” And also, combine that with your internal business logic, right? Like maybe for an internal only application that never transits beyond your VPC perimeter, sure, it's fine to have port 22 open, right? There's just going to be people within your zero-trust environment authenticating to it. But for your production web application, that might be a different story.Corey: There are other concerns, too. For example, I'm sitting here complaining about the idea of encrypting at rest in an AWS environment, but if you've signed customer contracts that state that you're doing it, you'd better freaking do it, as opposed to, “Well, I know what the actual security risk is and it's no big deal.” Yeah, don't make that decision. If you are contractually obligated to do a thing. Don't YOLO it; do what you say you're going to do. That's that whole integrity thing.Clinton: Oh, sure. And look in a battle between security and compliance. Compliance always wins, right? But from a developer perspective, I don't know that we on the front lines writing code actually differentiate, right? That certainly is a matter for the people defining the policies and, you know, creating their gating mechanisms in CI to figure out.What I want to know as a developer is, is my build going to succeed, right? Or am I going to get shut down and get the nastygram that says, you know, “We couldn't launch this for x, y, and z reason.” Now, everybody on my team hates me, my lead dev is on me, now there's a bunch of merge conflicts because my branch is behind. I want to get that out into production, but in order to do that, I need information on how are all these signals going to be compiled together in a way that, you know, creates that red light or green light on the risk dashboard later on. But up until I think, you know, relatively recently, I don't have visibility into that except to launch the commit, you know, start the build and see what happens, and then I have that context-switching problem, right, because it's hours or days later, that I finally get that signal back.So yes, I think we have a compliance story to tell from the Snyk perspective as well. A lot of those same issues, you know, we're detecting, especially with regard to infrastructure as code, but it ultimately is up to various parts of the organization to work together and say, “What balance do we want to strike between security and velocity,” right? Understanding that those are not mutually opposed. What we need is tooling and more importantly a culture that takes both into account and allows us to develop securely and fast at the same time.Corey: I want to thank you so much for taking the time to speak with me about all this. If people want to learn more, where can they find you? And for God's sake, please don't say in your booth at re:Invent.Clinton: [laugh]. I will not be at re:Invent this year. I've had a little bit too much of the Vegas Strip here recently.Corey: No, I hear you. Right now, the people going are those whose employers find them expendable, which is why I'm there.Clinton: I wouldn't say that Corey. I think you'll do great, and you know, just make sure to bank all your vacation for a couple weeks after. Look, come to snyk.io start a conversation, but more importantly, just start using it, right?I don't want to give you the sales pitch; I want you to see the value in the tooling, and the easiest way to do that as an engineer is just to start using it. And if there is value there, you want to bring it to your enterprise. I would love to have that conversation and move forward. But engineer to engineer, like, figure out if this is going to work for you: does it make your life easier? Does it reduce the pain and anxiety you feel before making that commit into the production branch? And if so, then yeah, we'd love to talk.Corey: I will, of course, put links to that in the [show notes 00:33:22]. Thank you so much for speaking to me today. I really appreciate it.Clinton: Thank you, Corey. Glad to do it.Corey: Clinton Herget, principal solutions engineer at Snyk. I'm Cloud Economist Corey Quinn and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice along with an angry comment yelling at Snyk about how they're a terrible company because they continually refuse to patronize your side business down at the Vowel Emporium.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

Today we're joined by Jessica Lord, talking about the origins of Electron and her boomerang back to GitHub to lead GitHub Sponsors. We cover the early days of Electron before Electron was Electron, how she advocated to turn it into a product and make it a framework, how it's used today, why she boomeranged back to GitHub to lead Sponsors, what's next in funding open source creators, and we attempt to answer the question “what happens to open source once it's funded?”

Today we're joined by Jessica Lord, talking about the origins of Electron and her boomerang back to GitHub to lead GitHub Sponsors. We cover the early days of Electron before Electron was Electron, how she advocated to turn it into a product and make it a framework, how it's used today, why she boomeranged back to GitHub to lead Sponsors, what's next in funding open source creators, and we attempt to answer the question “what happens to open source once it's funded?”

In this episode of Syntax, Scott and Wes talk about all the things that have improved the lives of web developers over the years. Sentry - Sponsor If you want to know what's happening with your code, track errors and monitor performance with Sentry. Sentry's Application Monitoring platform helps developers see performance issues, fix errors faster, and optimize their code health. Cut your time on error resolution from hours to minutes. It works with any language and integrates with dozens of other services. Syntax listeners new to Sentry can get two months for free by visiting Sentry.io and using the coupon code TASTYTREAT during sign up. Freshbooks - Sponsor Get a 30 day free trial of Freshbooks at freshbooks.com/syntax and put SYNTAX in the "How did you hear about us?" section. Linode - Sponsor Whether you're working on a personal project or managing enterprise infrastructure, you deserve simple, affordable, and accessible cloud computing solutions that allow you to take your project to the next level. Simplify your cloud infrastructure with Linode's Linux virtual machines and develop, deploy, and scale your modern applications faster and easier. Get started on Linode today with a $100 in free credit for listeners of Syntax. You can find all the details at linode.com/syntax. Linode has 11 global data centers and provides 24/7/365 human support with no tiers or hand-offs regardless of your plan size. In addition to shared and dedicated compute instances, you can use your $100 in credit on S3-compatible object storage, Managed Kubernetes, and more. Visit linode.com/syntax and click on the “Create Free Account” button to get started. Show Notes 00:16:18 Topic introduction 01:03:00 Leaf blowing and house updates 02:57:01 We complain a lot 04:13:22 Typescript improvements 06:20:00 Optional chaining 07:01:06 Async, Await and Promises 07:57:05 Array methods and tools for immutability 09:13:16 DOM interactions with getElementBy 10:34:10 Arrow functions 11:13:06 Classes! + All of ES6 was a huge breath of fresh air 12:18:07 Looping 13:22:00 Prettier Code is a huge game changer Prettier ESLint 15:51:00 Sponsor: Freshbooks 17:04:15 CSS updates 17:41:11 CSS Variables 18:41:15 Flexbox and Grid 20:16:10 VH, VW units 20:47:24 Overflow scroll on mobile 21:54:10 Color formats 23:08:06 Sticky headers 23:45:06 HTML 5 Introducing HTML5 By Bruce Lawson and Remy Sharp A Book Apart 27:54:00 Web components 28:29:09 Sponsor: Sentry 30:01:17 Tooling Syntax 12 Why Is Everyone Switching to VS Code? 31:28:13 Speed of latest crop → ESBuild, Vite, Snowpack, parcel Vite Snowpack 33:33:03 Image compression 37:08:21 Hot module reloading 39:11:09 Image resizing, video hosting, accepting credit cards Gatsby Cloudinary Spritecow SmushIt Stripe Braintree Entrepreneur friendly licensing 39:48:18 Entrepreneur friendly licensing 40:43:18 Sponsor: Linode 42:11:10 Developer Tools in the browser Tweet from @Bentlegen Chris Coyier - Let's Suck at Github Together Chrome.io 43:52:17 Insights into errors and troubleshooting 44:49:13 Cross browser and cross device testing 47:12:19 Hosting and SSL Certificates 48:14:08 Scaling up 49:53:13 Scaling with containers 50:14:09 When did we start using Github? 53:52:12 ××× SIIIIICK ××× PIIIICKS ××× Scott 59:42:22 ××× SIIIIICK ××× PIIIICKS ××× Wes ××× SIIIIICK ××× PIIIICKS ××× Scott: Tonal Wes: Reboot your Portfolio / Canadian Couch Potato Shameless Plugs Scott: Astro Course - Sign up for the year and save 50%! Wes: All Courses - Black Friday sale! Tweet us your tasty treats Scott's Instagram LevelUpTutorials Instagram Wes' Instagram Wes' Twitter Wes' Facebook Scott's Twitter Make sure to include @SyntaxFM in your tweets

About BrianBrian is an accomplished dealmaker with experience ranging from developer platforms to mobile services. Before InfluxData, Brian led business development at Twilio. Joining at just thirty-five employees, he built over 150 partnerships globally from the company's infancy through its IPO in 2016. He led the company's international expansion, hiring its first teams in Europe, Asia, and Latin America. Prior to Twilio Brian was VP of Business Development at Clearwire and held management roles at Amp'd Mobile, Kivera, and PlaceWare.Links:InfluxData: https://www.influxdata.com TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: This episode is sponsored in part by my friends at ThinkstCanary. Most companies find out way too late that they've been breached. ThinksCanary changes this and I love how they do it. Deploy canaries and canary tokens in minutes and then forget about them. What's great is the attackers tip their hand by touching them, giving you one alert, when it matters. I use it myself and I only remember this when I get the weekly update with a “we're still here, so you're aware” from them. It's glorious! There is zero admin overhead  to this, there are effectively no false positives unless I do something foolish. Canaries are deployed and loved on all seven continents. You can check out what people are saying at canary.love. And, their Kub config canary token is new and completely free as well. You can do an awful lot without paying them a dime, which is one of the things I love about them. It is useful stuff and not an, “ohh, I wish I had money.” It is speculator! Take a look; that's canary.love because it's genuinely rare to find a security product that people talk about in terms of love. It really is a unique thing to see. Canary.love. Thank you to ThinkstCanary for their support of my ridiculous, ridiculous nonsense.   Corey: Writing ad copy to fit into a 30 second slot is hard, but if anyone can do it the folks at Quali can. Just like their Torque infrastructure automation platform can deliver complex application environments anytime, anywhere, in just seconds instead of hours, days or weeks. Visit Qtorque.io today and learn how you can spin up application environments in about the same amount of time it took you to listen to this ad.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. This promoted guest episode is brought to us by our friends at InfluxData. And my guest is titled as the Chief Marketing Officer at InfluxData, and I don't even care because his bio has something absolutely fascinating that I want to address instead. Brian Mullen is an accomplished dealmaker is how the bio starts. And so many of us spend time negotiating deals, but so few people describe ourselves in that way. First, Brian, thank you for joining us. And secondly, what's up with that?Brian: [laugh]. Well, thanks, Corey, very excited to be here. And yes, dealmaker; I guess that would be apropos. How did I get into marketing? Well, a lot of my career is spent in business development, and so I think that's where the dealmaker part comes from.Several different roles, including my first role at Influx—when I joined Influx—was in business development and partnerships. And so, prior to coming to Influx, I spent many years building out the business development team at Twilio, growing that up, and we did a lot of deals with carriers, with Cloud partners, with all kinds of different partners; you name it, we worked with them. And then moving into Influx, joined in an BD capacity here and had a couple different roles that eventually evolved to Chief Marketing Officer. But  that's where the dealmaker comes from. I like to do deals, it's always nice to have one on the side   in whatever capacity you're working in, it's nice to have a deal or two working on the side. It kind of keeps you fresh.Corey: It's fun because people think, “Oh, a deal. You're thinking of mergers and acquisitions, and how hard could that be? You just show up with a bag of money and give it to people and then you have a deal closed.” And oh, if only it were that simple. Every client engagement we have on the consulting side has been a negotiation back and forth, and the idea is to ideally get everyone to the point where they're happy, but honestly, if everyone's slightly unhappy but can live with the result, we'll take that too.And as people go through their own careers it's, you're always trying to make a deal in some form: when you try to get a project approved, or you're trying to get resources thrown at something—by which I generally mean money, not people, though people, too—it's something that isn't necessarily clearly understood or discussed very often, despite the fact that half of what I do is negotiating with AWS on behalf of clients for better contractual terms. The thing that I think takes people by surprise the most is that dealmaking is almost never about pounding the table, being angry, and walking out, like you read the world's worst guide to buying a car or something. It's about finding the win for everyone. At least that's the way I've always approached it.Brian: That's a good point. And actually that wording that you described of finding a win for everybody, that's how I always thought about it. I think about it as first of all, you're trying to understand what the other party—and it could be an individual, it could be a company, it could be a group of companies, sometimes—you're trying to understand what their goals are, what their agenda is and see how that matches with your own; sometimes they're opposing, sometimes they're overlapping. And then everyone has to have some perceived win  in a deal. And it's not competitively; it's more like you just have to have value, that is kind of what the win is – having value in that deal.And so that's the way I always approached it. And doing deals, whether you're in BD or sales, or if you're working with vendors and you're in a different functional role, sometimes it's not even commercial, it's just about aligning resources, perhaps. Our deal might be that you and I are both going to put a collective effort into building something or taking something to market. In another scenario might be like, I'm going to pay for this service that you're delivering, or vice versa. Or we're going to go and bring two revenue-generating products together and take them to market. Whatever it might be, it doesn't matter so much what the mechanics are of the deal, but it's usually about aligning those agendas and in having someone get utility, get value on the other side.Corey: I think that people lose sight of the fact as well, that when you're talking about a service provider—and let's be clear, InfluxData has launched a cloud platform that we'll talk about in a minute—this is not the one-off transactional relationship; once the deal is signed, you've got to work with these people. When they host parts of your production infrastructure, whether you want to admit it or not they're your partner more so than they are your vendor. It has to be an ongoing relationship that people are, if they at least aren't thrilled with it, can at least be happy enough to live with, otherwise it just winds up with this growing sense of resentment and it just sort of leads nowhere.Brian: Yeah, there really is no deal moment. Yes, people sign agreements with companies, but that's just the very beginning. Your relationship evolves from there. We're delivering a product, we're delivering this platform that handles time-series data to our customers, and we're asking them to trust us with their product that they're taking out to market. They're asking us to handle their data and to deliver service to them that they're turning into their production applications. And so it's a big responsibility. And so we care about the relationship with our customers to continue that.Corey: So, I first really became aware of time-series data a few years back during a re:Invent keynote when they pre-announced Timestream, which took entirely too long to come to market. Okay, great. So, you're talking about time-series data. Can you explain what that means in simple terms? And I learned over the next eight minutes that they were talking about it, that no, no, they couldn't. I wound up more confused by the end of the announcement than I was at the beginning.So, assuming that I have the same respect for databases as you would expect for someone whose favorite data store is Route 53—because you can misuse it as a beautiful database—what is time-series data and why does it matter in 2021?Brian: Sure, it's a good question. And I was there in that audience as well that day. So, we think of time-series data as really any type of data that's stamped in time, in some way. It could be every hour, every minute, every second, every half second, whatever. But more specifically, it's any type of data that is generated by some source—and that could be a sensor sources within systems or an actual application—and these things change over time, and then therefore, stamped in time in some way.They can come at different frequencies, like I said, from nanoseconds to seconds, or minutes and hours, but the most important thing is that they usually trigger a workflow, trigger some sort of action. And so that's really what our platform is about. It allows people to handle this type of data and then work with it from there in their applications, trigger new workflows, et cetera. Because the historical context of what happens is super important.And when we talk about sources, it could be really many things. It could be in physical spaces, and we have a lot of IoT types of customers and use cases. And those are things like devices and sensors on the factory floor, out in the field, it's on a vehicle. It's even in space, believe it or not. There are customers that are using us on satellites.And then it can also be sources from within software, applications, and infrastructure, things like VMs, and containers, and microservices, all emitting time-series data. And it could be applications like crypto, or financial, or stock market, agricultural type of applications that are themselves as applications emitting data. So, you think about all these sources that are out there from the physical world to the virtual world, and they're all generating time-series data, and our platform is really specially designed to handle that kind of data. And we can get into some details of what exactly that means, but that's really why we're here. That's what time-series is all about.Corey: And this is the inherent challenge I think we're seeing across the entire industry slash ecosystem. I mean, this is airing during re:Invent week, but at the time we are recording this, we have not yet seen the Tuesday keynote that Adam Selipsky will take to the stage, and no doubt, render the stat I'm about to throw at you completely obsolete. But depending on how you count them, there's somewhere between 13 and 15 managed database or database-like services today that AWS offers. And they never turn things off and they're always releasing new things, supposedly on behalf of customers; in practice because someone somewhere wants to get promoted by launching a new service; good for them. Godspeed.If we look into the uncertain future, at some point, someone's job is going to be disambiguating between the 40 different managed database services that AWS offers and picking the one that works. What differentiates time-series from—let's just start with an easy one—something like MySQL or Postgres—or ‘Postgres-squeal' is how I insist on pronouncing that one. Let's stay away from things like Neptune because no one knows what a social graph database is and I assure you, you almost certainly don't need one. Where does something like Influx work in a way that, “Huh. Running this on MySQL is really starting to suck.”Brian: When and why is it time to consider a specialized tool. And in fact, that's actually what we see a lot with our customers is coming to us around that time when a time-series is a problem to solve for them is reaching the point where they really need a specialized tool that's kind of built for that. And so one way to look at that is really just to think about time-series in general as a type of data. It's rapidly rising. It's the fastest growing data category out there right now.And the reason for that is it's being driven by two big macro trends. One is the explosion of all these applications and services running in the cloud. They're expanding horizontally, they're running in more regions, they're in many cases running on multiple clouds, and so it's just getting big—the workloads are getting bigger and bigger. And those are emitting time-series data. And then simultaneously, you have this  growth of all these devices and sensors that are coming online out in the real world: batteries, and temperature gauges, and all kinds of stuff, both new and old, that is coming online, and those sources are generating a lot of time-series data.So typically, we're in a moment now, where a lot of developers are faced with this massive growth of time-series data. And if you think about some data set that you have, that you're putting into some kind of traditional database, now add the component of time as a multiplier by all the data you have. Instead of that one data, that one metric, you're now looking at doing that every one second in perpetuity. And so it's just an order of magnitude more data that you're dealing with. And then you also have this notion of—when you have that magnitude of data, you have fidelity, you're taking a lot of it in at the same time, I mean, very quickly, so you have  batch or stream data coming in at super high volume, and you may need that for a few minutes or a few hours or days, but maybe you don't need it for months and years.And so you'd maybe dropped down to kind of a lower fidelity for the longer-term. But you really have this  toggling back and forth of the high fidelity and low fidelity, all coming at you at pretty high volume. And so typically what happens is, is when the workloads get big enough, the legacy tools, they're just not equipped to do it. And a developer—if they have a small set of time-series they're dealing with, what is the first thing they're going to do? They're going to look around and be like, “Hey, what do I have here? Oh, I've got Mongo over here. I've got Splunk, or I've got this old relational database, I can put it in.”And that's typically what they'll do, and that works fine until it doesn't. And then that's when they come around looking for a specialized tool. So, we really sit in Influx and, frankly, other time-series products really do sit at that point where people are considering a specialized tool just because the workload has gotten such that it requires that.Corey: Yeah. Taking a look at most of the offerings in the space; anything that winds up charging anything more than a very tiny fraction of a penny—from what you're describing—is going to quickly become non-economical, where it's, “Oh, we're going to charge you”—like using S3: every, I think, 1000 writes cost a penny—“Oh, we're just going to use S3 for this.” Well, at some of these data volumes, that means that your request charge on S3 is very quickly going to become the largest single line item in your bill, which is nothing short of impressive in a lot of cases, but it also probably means that you've taken a very specific tool—like an iPad—and tried to use it as something else—like a hammer—and no one's particularly happy with that outcome.Brian: Yeah. First of all, having usage-based pricing is really important. We think about it as allowing people to have the full version of the product without a major commitment, and be using it in test scenarios and then later in the very early production scenarios. But as a principle, it's important for people that just signed up two hours ago using your product are basically using the same full product that the biggest customers that you have are using that are paying many, many thousands or tens of thousands per month. And so the way to do that is to offer usage-based pricing and not force people to commit to something before they're ready to do it.And so there's ways to unlock lower pricing, and we, like a lot of companies, offer annual pricing and we have a sales team that worked with folks to basically draw down their unit costs on the use of the platform once they kind of get comfortable with their workload. So, there's definitely avenues to get lower price, and we're believers in that. And we also want to, from a product development perspective, try to make the product more efficient. And so we basically are trying to drive down the costs through efficiencies in the product: make it run faster, make queries take less time, and also ship products on top of it that require developers to write less code themselves, kind of, do more of the work for them.Corey: One of the things I find particularly compelling about what you've done is it is an open-source project. If I want to go ahead and run some time-series experiments myself, I can spin it up anywhere I want and run it however I see fit. Now, at some point, if I'm doing this for anything more than, “Oh, let's see how I can misuse this today,” I probably want to at least consider letting someone who's better at running these things than I am take it over. And as I'm looking through your customer list, the thing that strikes me is how none of these things are quite like the other. We're talking about companies like Hulu is probably not using it the same way as Capital One is, at least I certainly hope not. You have Texas Instruments; you also have Adobe. And it sort of runs an entire gamut of none of these companies quite look alike; I have to imagine their use cases are also somewhat varied, too.Brian: Yeah, that's right. And we really do see as a platform, and with time-series being the common problem that people are looking to solve, we see this pretty broad set of use cases and customer types. And we have some more traditional customers like the Cisco's and the IBM's of the world, and then some  relatively new folks like Tesla and Hulu and others that are a little bit more recent. But they're all trying to solve the same fundamental problem with time-series, which is “How can I handle it in an efficient way and make use of it meaningfully in my applications and services?”And we were talking earlier about having some sources of time-series data being in, kind of a virtual space, like in infrastructure and software, and then some being in physical space, like in devices and sensors out in the real world. So, we have breadth in that way, too. We have folks who are building big software observability infrastructure solutions on us, and we also have people that are pulling data off of the devices on a solar panel that's sitting on a house in the emerging world, right? So, you have basically these two far ends of the spectrum, but all using this specialized tool to handle the time-series data that they're generating.Corey: It seems to me that for most of these use cases and the way you describe it, it's more about the overall shape of the data when we're talking about time-series more so than it is any particular data point in isolation. Is that accurate, or are there cases where that is very much not the case?Brian: I think that's accurate. What people are mostly trying to understand is context for what's happening. And so it's not necessarily—to your point—not searching for one specific data point or moment, but it's really understanding context for some general state that has changed or some trend that has emerged, whatever that might be, and then making sense of that, and then taking action on that. And taking an action could mean a couple of different things, too. It could be in an observability sense, where somebody in  an operator type of mode where they're looking at dashboards and paying attention to  infrastructure that's running and then need to take some sort of action based on that. It also, in many cases, is automated in some way: it's either some series of automated responses to some state that is reached that is visible in the data, or is actually kicking off some new series of tasks or actions inside of an application based on what is occurring and shown by the time-series data.Corey: You know what doesn't add to your AWS bill? Free developer security from Snyk. Snyk is a frictionless security platform that meets developers where they are, finding and fixing vulnerabilities right from the CLI, IDEs, repos, and pipelines. And Snyk integrates seamlessly with AWS offerings like CodePipeline, EKS, ECR, and oh so much more.Secure with Snyk and save some loot. Learn more at snyk.io/scream. That's S-N-Y-K-dot-I-O/screamCorey: So, we've talked about, you have an open-source product, which is the sort of thing that most people listening to this should have a vague idea of, “Oh, that means I can go on GitHub and download it and start using it, if it's not already in my package manager.” Great. You also have the enterprise offering, which is more or less, I presume, a supported distribution of this—for lack of a better term—that you then wind up providing blessed configurations thereof and helping run support for that—for companies that want to run it on-prem. Is that directionally accurate, or am I grossly mischaracterizing [laugh] what your enterprise offering is?Brian: Directionally accurate, of course. You could have a great job in marketing. I really think you could.Corey: Oh, you know, I would argue, on some level, I probably do. The challenge I have is that I keep conflating marketing with spectacle and that leads down to really unfortunate, weird places. But one additional area, which is relatively recent since the last time I spoke with Paul—one of the cofounders of your company—on this show is InfluxDB Cloud, which is one of those, “Oh, let me see if I look—if I'm right.” And sure enough, yeah, you wind up managing the infrastructure for us and it becomes a pay-per consumption model the way that most cloud service providers do, without the really obnoxious hidden 15 levels of billing dimensions.Brian: Yes, we are trying to bring the transparency back. But yes, you're correct. We have open-source and we have—it's very popular—we have over 500,000-plus instances of that deployed globally today in the community. And that's typically very common for developers to get started using the open-source, easily recognizable, it's been out for a long time, and so many people start the journey there.And then we have InfluxDB Enterprise, which it's actually a clustered version of InfluxDB open-source. So, it allows you to basically handle in an environment that you want to manage yourself, you manage a cluster and scale it out and handle ever-increasing workloads and have things like redundancy and replication, et cetera. But that's really specifically for people who want to deploy and operate the software themselves, which is a good set of people; we have a lot of folks who have done that. But one of the areas that's a little bit more recent is InfluxDB Cloud, which is really, for folks who don't want to have anything to do with the management; they really just want to use it as a service, send their data in—Corey: Yeah, give me an API endpoint, and I want you to worry about the care, and the feeding, and the waking up at two in the morning when a disk starts filling up. Yeah, that is the best kind of problem from my perspective: someone else's.Brian: Exactly. That's our job. And increasingly, we've seen folks gravitate to that. We've got a lot of folks have signed up on this product since it launched in 2019, and it's really increasingly where they begin their journey, maybe not even going to the open-source just going directly to this because it's relatively simple to get started.It's priced based on usage. People pay for three vectors: they have the amount of data in; they have number of queries made against the platform; and then storage, how much data you have and for how long. And depending on the use case, some people keep it around for relatively short time, like a few days or a couple of weeks. Other folks have it for many, many months and potentially years in some places. So, you really have that option.But I would say the three products are really about how you want to run it. Do you care about running the, kind of, underlying infrastructure and managing it or do you just want to hit an endpoint, as you said.Corey: You launched this, I want to say in 2019, which feels about directionally right. And I know it was after Timestream was announced, so I just want to say first, how kind and selfless it was of you to validate AWS's market, which is, you know how they always like to clarify and define what they're doing when they decide to enter every single market anywhere to compete with everyone. It turns out, I don't get the sense that they like it quite [laugh] as much being on the other side of that particular divide, but that's the best kind of problem, too: again, someone else's.Brian: Yeah, I think that's really true.Corey: The challenge that I have is that it seems like a weird direction to go in as a company, though it is clearly based upon a number of press releases you have made about the success and market traction that you found, it feels, on some level, like it is falling into an older version of an open-source trap of assuming that, “Well, we wrote the software therefore we are the best people you could pick to run it.” That was what a lot of companies did; it turns out that AWS has this operational excellence, as they call it, and what the rest of us call burning through people and making them wake up in the middle of the night to fix things before it becomes customer-visible. But from the outside, there's no difference. It seems, however, that you have built something that is clearly resonating, and in a big way, in a way that—I've got to be direct with you—the AWS time-series service that they are offering has not been finding success.Brian: Thank you for saying that, and we feel pretty excited about the success we've had even being in the same market as Amazon. And Amazon does a phenomenal job at running products at scale, and the breadth that they have in their product lineup is pretty impressive, especially when they roll out new stuff at AWS re:Invent every year. But we've been able to find some pretty good success with our approach, and it's based on a couple of things. So, one is being the company that actually develops and still deploys the open-source is really important. People gravitate to that.Our roots as a company are open-source, we've been a part of and fostered this community over many, many years, and there's a certain trust in the direction that we're taking the company. And Paul, our founder who you mentioned, he's been front and center with that community, pretty deeply engaged for many, many years. I think that carries a lot of weight. At least that's the way we think about it. But then as far as commercial products go, we really think about it as going to where our customers are, going to where developers are. And that could mean the language that they prefer, the language of preference for them. And that could [crosstalk 00:22:25]—Corey: Oh, and it's very clear; it seems that most database companies that I talk to—again, without naming names—tend to focus on the top-down sale, but I've never worked in an environment where the database that will be used was dictated by anyone other than the application developers who are the closest to the technical requirements for the workload. I've never understood this model of, “Oh, we're going to talk to the C suite because we believe that they're going to pick a database vendor based upon who has box seats this season.” I've never gotten that and that probably means I'm a terrible enterprise marketer, on some level. But unlike almost every other player in the database space, I've never struggled to understand what the hell your messaging has meant, other than the technical bits that I just don't have quite enough neurons to bang together to create sparks to fully understand. It is very clearly targeted at a builder rather than someone who's more or less spending their entire life in meetings. Which, oh, God, that's me.Brian: [laugh]. Yes, it's very much the case. We are focused on the developer. And that developer is a builder of an application or service that is seeing the light of day, it's going out and being used by their own end-users and end-customers.And so we care about going to where those developers are, and that could mean going and making your product easily used in the language and tool that customer cares about. So, if you're a Python developer, it's important for us to have tools and make it easy for Python developers. We have client libraries for Python, for example. It also means going to the cloud where your customers are. And this is something that differentiates us as well, when you start looking at what the other cloud providers are offering, in that data—like it or not—has gravity. And so somebody that has built their whole stack on AWS and sure they care about using a service that is going to receive their data, and that also being in AWS, but—Corey: It has to live where the customers are, especially with data egress charges being what they are, too.Brian: Exactly.Corey: And data gravity is real. The cloud provider people pick is the one where their data lives because of that particular inflection in the market.Brian: Absolutely true. And so that's great if you're only going after people who are on AWS, but what about Google Cloud and what about Microsoft Azure? There are a lot of developers that are building on those platforms as well, and that's one of the reasons we want to go there as well. So, InfluxDB Cloud is a multi-cloud offering, and it's equal experience and capability and pricing on each of the three major clouds. You can buy directly from us; you can put it on any of your cloud bills in one of those marketplaces, and to us that's like a really, really fundamental point is to bring your product and make it as easy to use on those platforms and in those languages, and in those realms and use cases where people are already working.Corey: I'm a big believer in multi-cloud for the use case you just defined. Because I know I'm going to get letters if I don't say this based upon my public multi-cloud is a dumb default worst practice for most folks—because it is, on a workload-by-workload basis—but you're building a service that has to be close to where your customers are and for that specific thing, yeah, it makes an awful lot of sense for you to have a presence across all the different providers. Now, here's the $64,000 question for you: is the experience as an InfluxDB Cloud customer meaningfully different between different providers?Brian: It's not. We actually pride ourselves on it being the same. Using InfluxDB, you sign up for InfluxDB Cloud, you come in, you set up your account, create your organization, and then you choose which underlying cloud provider you want your account to be provisioned in. And so it actually comes as a secondary choice; it's not something that is gated in the beginning, and that allows us to deliver a uniform experience across the board. And you may in a future use case, maybe somebody wants to have part of what they're building data living in AWS and maybe part of it living in Azure, I mean, that could be a scenario as well.However, typically what we've seen—and you've probably seen this as well—is  most developers are—and organizations—are building mostly on one cloud. I don't see a lot of  multi-cloud in that organization. But we ourselves need to be multi-cloud in order to go to where those people are working. And so that's the distinction. It's for us as a company that delivers product to those people, it's important for us to go where they are, whereas they themselves are not necessarily running on all three cloud products; they're probably running on one platform.Corey: Yeah. On a workload-by-workload basis, that's what generally makes sense. Anytime you have someone who has a particular workload that needs to be in multiple providers, okay, great, you're going to put that out there, but their backend systems, their billing, their marketing, all the rest, is not going to go down that path for a variety of excellent reasons, mostly that it is a colossal pain, and a bunch of, more or less, solving the same problems over and over, rather than the whole point of cloud being to make it someone else's. I want to thank you for taking so much time to speak to me about how you're viewing the evolution of the market, how you're seeing your move into cloud, and how you're effectively targeting folks who can actually care about the implementation details of a database rather than, honestly, suits. If people want to learn more, where can they find you?Brian: They can go to our website; it's the easiest place to go. So, influxdata.com. You can read all about InfluxDB, it's a pretty easy sign up to get underway. So, I recommend that people get their hands dirty with the product. That's the easiest way to understand what it's all about.Corey: And if you do end up doing that, please tell them I sent you because the involuntary flinch whenever people mention my name to vendors is one of my favorite parts of being me. Brian, thank you so much for being so generous with your time. I appreciate it.Brian: Thanks so much for having us on. It was great.Corey: Brian Mullen, Chief Marketing Officer—and dealmaker—at InfluxData. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice along with a long, angry comment telling me that you work on the Timestream service team, and your product is the best. It's found huge success, but I've just never met any of your customers and I can't because they all live in Canada.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

The 16:9 PODCAST IS SPONSORED BY SCREENFEED – DIGITAL SIGNAGE CONTENT Going back roughly a decade, there were a couple of digital signage vendors talking up and marketing their capabilities for a technology called SMIL. That's short for Synchronized Multimedia Integration Language, but you probably knew that. OK, probably not. It's a bit like HTML, in that it is a programming language developed and supported by the same global entity that developed and continues to support and evolve HTML. If you don't know what HTML is, then this podcast edition is one you may want to pass on. It gets a little nerdy. SMIL, going back 10 years, was being touted as a next big thing for signage, but that didn't happen. However, there are companies using SMIL for managing digital signage networks - particularly companies who have some technical chops in-house and want something that's flexible and in their control. I stumbled recently on a little company in Hannover, Germany that has been squarely focused on SMIL. I had a good, albeit technical, chat with Niko Sagiadinos, one of the two partners in a firm called SmilControl. He walked me through what SMIL is all about, and the advantages he says the technology brings to digital signage. Subscribe to this podcast: iTunes * Google Play * RSS TRANSCRIPT Niko, thank you for joining me. Can you tell me what your company is all about and when it got started?  Niko Sagiadinos: We started in 2011 with a content management system based on SMIL, and I was a developer years before and one day a friend of mine came up with the idea of 101 Signboard and told me that he desperately needs a content management system. So I had at that moment a content management system and I developed two models for this system, one to administer the playlist and one to administer the player, and so it began. I liked SMIL and the open nature of ideas at that time. I often used open source software and that's a concept I personally liked very much and so I stuck with SMIL and I saw that there were a lot of things possible with SMIL, and I liked it and I stayed with it.  So there will be people listening who will already be going, what is he talking about? What is SMIL? Over here, it's sometimes called “smile.” I know it's an acronym for some sort of a language. Can you explain?  Niko Sagiadinos: Yes. SMIL is an acronym for synchronized multimedia integration language. You can also call it the HTML for digital signage or multimedia presentations and SMIL makes it possible to create a multimedia presentation, interaction with time synchronization. That's where the first word synchronized comes from, and just like you can build websites with HTML, you can build presentations or digital signage presentations with SMIL.  So I know that SMIL has been around for several years. I can remember a competitor of yours, SignageLive, talking about SMIL and working with ideas over in Taiwan, on their devices as well. They made a fair amount of noise about it, and then it just dropped off, and Jason and his team moved on to other stuff seemingly. What's the distinction between SMIL and HTML5?  Niko Sagiadinos: SMIL is focused on presentations and the arrangement of media, while HTML is more focused on the arrangement of information and the implementation for the media, but SMIL can synchronize them. So you can position a media to play first, then second, then the third, then repeat, go to one and then continue. These are things which are not natively possible with HTML. You can do it with HTML, but you need to program with JavaScript, and that's easier to do with SMIL. SMIL also has some orders to control how a presentation runs and the presentation is not the thing for HTML. With websites, you can do interactions with the website but you cannot synchronize media sequentially, parallelly, or what happens when a special time comes, for example, at 5 o'clock, a video has to run an, and then another playlist starts. There are a lot more complicated things focused on presentation which are better solved by SMIL. So why has the digital signage industry migrated more to HTML5 and those kinds of web services and JavaScript as opposed to SMIL?  Niko Sagiadinos: Now I have two theories. The first is it is easier for most to make a web design and it seems to be easier to make its own thing. This is one, it seems to be easier to make a website, but it has some disadvantages because it's a browser, you need a digital signage player. You can integrate a browser in a digital signage player, but you also need commands to administer this player and this is with the browser a little bit more complicated.  The second thing is that every company wants to do his own thing. So you need to buy a software from company X and you need to buy a digital signage player software or hardware from company X, and this is what we call a window lock in. Every company wants to lock in their customers to use their product and so they have established this connection between an authoring system and the player system, and with SMIL, this connection can break up so you can use any player from any company or even my open source player, and you can write your own SMIL authoring software, if you like, and that's something companies don't want. They want to have it all together and sell a solution, and that's the reason, in my opinion, they stuck more on this product.  In the early days, they tried to establish SMIL as low-cost signage also, but it was a mistake from my point of view, because SMIL can do much more than what they were focused on. They focused on the media player only and said, okay, this is only low cost signage, but you can run a SMIL software even under a mobile and computer, and this is a way to do more high cost signage for example, and there's another reason. Companies don't want to cannibalize their own product. For example, if you get a market leader and they have their own system, and now you come to SMIL, and they have a feature that has low cost signage, because if they said, okay, they can do the same things like our enterprise product with SMIL, they'll lose money.  So your company is SMIL Control. What do you offer? I know that recently you introduced a free software player as well that works with SMIL.  Niko Sagiadinos: We started in 2012 officially with only a content management system and most of our customers used players from IAdea but some of our customers wanted to create their own player. They were not satisfied with the player from IAdea for various reasons, because there was no company, they wanted to have more control, maybe they got some cheaper devices from Asian manufacturers and so they started to write their own SMIL software and that caused some problems. When three or four of our resellers started to write software, and put a lot of resources to develop this player, but they didn't focus on marketing and to make sales, and just focused on developing and in 2015-16, I decided, okay, we have now some success with our content management system, I tried to develop a player for those who want to create their own hardware. And the only target for me is to create an open source player, and this player is the Garlic Player, and now after five years, increasing companies are showing interest in this player to brand it under their name or to use it in their player and to make their own hardware around this player. That's the goal. To be clear, this is the software that plays out the media and there's a hardware player, which is not what we're talking about here?  Niko Sagiadinos: At SMIL Control, our focus is only on software. You can take our software and use it as you want and this is the same with the  . The Garlic Player is a piece of software that you can use on a Windows PC, on a Linux PC or an Android device. You can even name it on Android as X Player, and you can sell it at X Player by making a service out of this, and that's the goal. You can use our software, and the only consistent way to publish the software is to open source the player software so everybody can take part of it.  I apologize, I'm not overly technical. I'm probably more technical than a lot of people, but I have my limits, sometimes severe.  You were describing how IAdea, a great little company from Taiwan. I'm good friends with them, they had a SMIL based hardware player, and I think you mentioned that there are some other companies that also have SMIL based hardware players, but you're saying, your garlic player doesn't need to be on one of those devices, it could run on a Windows or Linux box, or even on an Android box and I think I read that it doesn't even need to be rooted, right?  Niko Sagiadinos: You can use this on an Android together with a launcher, and the launcher is another software which works together with the player and the launcher does not need the device to be rooted. I know this is a little tech focused discussion, but yes, at the end of the day, there's only software running on hardware. Even with IAdea and the other players, there's just software which is running on the hardware, and the goal is that if someone wants to offer his own hardware, they can use our software.  So if I'm an end-user or a solutions provider, I'm listening to this and getting the explanations around the advantages of SMIL over HTML5 and so on. I'm wondering if they're listening and thinking, “This sounds interesting, but I don't know anything about that particular programming language and how much of a curve do I have to get up,” or is if I'm an end-user, is it invisible and you don't need to know anything about it?  Niko Sagiadinos: This is a valid point. Our products are not for end users. They are for resellers who have a technical background and know what they have to do. For example, there are a lot of companies in Germany who want to offer digital signage products and have tech support, but they don't have knowledge in digital signage and have possibly two opportunities.  The first opportunity is to build everything from scratch by themselves, or to get someone who sells them a complete package, a full service but if you are between that, you will have your own hardware maybe, and you want to use your own hardware, but you don't have the software for it. You have knowledge of hardware and PC, but you don't have the software and you need software. That's our customer.  The end users will be totally overwhelmed because they will run into problems because of the technical nature because you have to know a lot of things, but a company which has a technical background, like a solutions provider for PCs or someone else that has this technical background, and so they can work together.  And would there be a lot that they need to learn or would it be pretty straightforward if they're already working with web technologies? Niko Sagiadinos: They won't have much to learn because the software is from us, and the only thing they have to learn is how to control the software. Of course we can offer bandwidth with this. We can offer that you can take it and use it or maybe you can do more things. If you need your own CMS, and you want to use only the player, we can help you, and the two documentation for SMIL and everything is open so there is no need for NDAs and things like that and we'll make the things to learn much easier, so you can learn, but you can only start to use it and install it.  So you could be trained on it. It's just like any other piece of software, you just might need some training?  Niko Sagiadinos: Exactly. We are computer nerds and we can show them how to use this software,  how they can use these concepts. So if this is for our solutions providers/resellers, that sort of thing, I gather something about what you're saying is this gives them the ability to control it, maybe put their own front-end skin on it so it looks like their product, and as you say, you're the nerds, you guys are just sitting in the background. Niko Sagiadinos: It can be digital signage companies too, or companies who want to be digital signage companies, but they don't want to reinvent the wheel and they get used in other industries.  We are something intermediate. You can take a full service provider, that's okay. But if you don't want this full service provider and you don't want to develop everything by yourself, you can use our products. So we are in the middle.  Do you get pushback from companies who say, this sounds really interesting, but I don't know much about this language. I know I asked this already, but this makes me a little nervous in that it's unfamiliar to me. Why wouldn't I just go with something with one of the established products out there that's using more familiar technology?  Niko Sagiadinos: Yes, of course, we get this feedback, but for me, it's a matter of time. There are customers for this because we get requests and these requests started coming in even a year before I started marketing. The last few years we got some big customers and we didn't even need to get out. So it was a secret. We had no real website and my partner and I know how to get customers and they have commissions for software, and so we started last year to make websites to do marketing. And in this year, the requests began to increase from other companies, and we have started to work with companies in Eastern Europe, for example, who use the Garlic Player and even join the programming and the coding.  To go back to your question, there are companies that say, okay, that's too complicated for us. We want to use some other things. But our goal is to get these companies who want to do these complicated things, because they see more effort to do this, then using something from someone else, which they can't control. And it sounds like what you're saying as well as it could be complicated to people who aren't around programming, don't do coding or anything like that, they are end-users or whatever it may be. If you are a technical company by nature and have software developers within your staffing, this is not complicated. It's just another way of going at it?  Niko Sagiadinos: Yes. For example, with a room booking software. If you want to have room booking software, you can develop your own room booking software and implement it transparently in our system via a widget which is a bit technical, but you are able to control and make use of what you have written with our infrastructure. So you can use a software like a media player, for example, and say, okay I will run a playlist from 10 to 3 o'clock, and from 3 o'clock, this room booking software will run on this or any other kind of software, and that's possible because we have these open technical features. So is it a bit like the kind of emerging idea of headless CMSs? Niko Sagiadinos: Yes, a little bit. You can compare it to a headless CMS a little bit.  Because you're the control platform and distribution platform, but somebody could write a front end and use their existing room booking tools or whatever and it's going to flow through there? Niko Sagiadinos: Exactly, and another thing to say is that we are at the beginning at the moment. We started to get open, to get published and to imagine the SMIL player, the garlic player which I have written in 2016, the first three years did not even get any interest, because we are a small company in Germany, but we try to make our infrastructure step by step and build a SMIL based ecosystem and this ecosystem will grow.  At first, we had only the content management system. Now we have a player, a launcher, even the proxy, and this ecosystem grows and grows. The next step we have to do is to deliver more information on how to use SMIL?  There is a website from IAdea, but it hasn't been maintained for over six and seven years and so we have to do something to teach people. That's our goal.  Not only we have to teach people how they can use these things for their businesses, and this is a way we have to go. At the moment, we can not give a solution for everything, but we are on a way and time by time we can offer more and more solutions, more and more information, and the product gets “round” so to say in German.  I would imagine it's important to stress that this is not some little side project on GitHub or whatever. SMIL is something that was developed by the world wide web consortium, they are the same people who came up with HTML, right? Niko Sagiadinos: Yes, and it is used in industry. The HD-DVD started with SMIL, the MMS also uses SMIL, a new eBook standard also uses SMIL. That's not something we developed with a few students. This is an industry standard. It's no joke. It's global and I'm wondering why IAdea ten years ago didn't put more power to show the world that it's possible to make amazing playlists, produce amazing products with this language, and accept it as low-cost signage and went with that if you want to do real signage, you have to get other products and that's, for me, a reason why SMIL in the last 10 years did not get accepted. And is this a standard that's standing still or is it evolving just in the same way that HTML is evolving?  Niko Sagiadinos: It's now standing still, it's not evolving at the moment. It's stuck on SMIL 3.0, which is from 2008, but I've contacted the inventors of SMIL in the Netherlands, some professors and I contacted them because we need to evolve. There are some features that are missing in SMIL, and we tried to wake them up.  The standard is okay, but since 2008, nothing has happened like HTML, but on the other side there are many things you can do. HTML evolves because a lot of things have to come in, for example, 50 years ago HTML was not able to play video without plug-ins and things changed a lot. Internet Explorer was a market leader for much too long and had blocked the evolution of HTML for years and now with other browsers, Firefox, Chrome and Safari, there's much more moving in the web browser markets. And we are trying the same thing for SMIL. At the moment, it fulfills our needs more than we expected. My partner at first was skeptical too. But when I developed more and more features into the Garlic Player, he was stunned seeing what is possible and what only expensive digital signage systems are able to do, we can do with SMIL. So there is no reason to call it low cost signage.  Okay. What are the business arguments around working with SMIL versus an HTML5 based platform or some other developed platforms. Are they going to be more reliable? Is it gonna be less expensive? Is it gonna last longer? Niko Sagiadinos: Well, you are asking a developer a business question. (Laughter) You gotta sell it down the stream.  Niko Sagiadinos: Selling is more my partner's job, but I will try. The interesting thing is that HTML is okay for what it has to do. SMIL is another part and the web browser is not a digital signage player so as we say in German, we are comparing an apple with a pear and those are two different things. You can do digital signage with HTML, but you can even ride a bicycle to Tokyo. That's possible too.  I think SMIL is much more of a fit for the digital signage age than HTML. The business side is that with SMIL, you don't have any dependencies and HTML won't fulfill the needs of digital signage.  Your company's based in Hanover, Germany, and it's privately held, I assume? You guys own it. You're not owned by a larger company or a venture capital company? Niko Sagiadinos: We are a bootstrapped company, we started as two people and now we are a kind of German limited, GmbH, because we want to expand next year.  How many people work for SMIL Control? Niko Sagiadinos: At the moment, we are two people. My business partner and I so yes, we are a little company, but we also use external developer, and last time I started to work with Bulgarian developers and Greek developers, and because I'm a digital nomad, I'm commuting between Germany and Greece, because I like the weather in Greece much more and the food. You don't like Hanover or Northern Germany in February? Niko Sagiadinos: No, it's extremely cold and to be honest, November and December are the ugliest months because in Germany, everything is gray here and cold and Greece is so much better.  If somebody wants to find out more about your company, where would they find you online now that you have a website? Niko Sagiadinos: Yes, we have a website, smil-control.com. But the company name is Camel case. All right, that was terrific. Thank you for spending some time with me and explaining what SMIL is all about.  Niko Sagiadinos: Thank you for allowing me. I hope it was understandable. I know I was a little nervous and that's complicated because I'm not a salesman or a businessman. We are technically focused and I'm very stuck on this technical thing and I have grown up in 30 years of technology. So maybe for one or the other, it was a little bit hard. Sorry!  Oh, that's okay. There's lots of technical people who will be intrigued by this and want to know more, so I'm sure it'll work out. Thanks again.  Niko Sagiadinos: Thank you very much, Dave.

Every Monday at 3:30PM UTC/11:30AM EST Horizen gives a LIVE update on Discord including a Q&A session with the community.  Weekly Insider detailed chat channel in Discord: https://horizen.io/invite/discord November 29, 2021, Weekly team updates from the following divisions: * Engineering * Node network * Product/UX * Customer service/Helpdesk * Legal * Business development * Marketing * Team Lead closing thoughts * 5 mins Q&A ZEN 2.0.24 deprecation: December 1 ZEN 3.0.0 (Zendoo) hard fork: December 1 (deprecation +24 blocks) Horizen is an exciting cryptocurrency with a solid technological foundation, unique capabilities, an active and capable team, ongoing funding for improvements, and a large, positive, encouraging community. ZEN is available and trading now on Bittrex, Binance, Coinbase, and more, has wallets available that implement advanced private transaction and messaging capability and has a strong roadmap. The goal of Horizen is to create a usable private cryptocurrency operating on a resilient system for people and businesses worldwide, enabling the daily use of private transactions, messaging, and publishing everywhere, all the time. Store: https://store.horizen.io Merchant Directory: https://horizen.io/merchants Horizen Nodes: https://horizen.io/zennodes Horizen Academy: https://academy.horizen.io/ Reference: Horizen Website – https://www.horizen.io Horizen Blog – https://blog.horizen.io Horizen Discord - https://horizen.io/invite/discord Horizen Github – https://github.com/HorizenOfficial Horizen Forum – https://forum.horizen.io/ Horizen Twitter – https://twitter.com/horizenglobal Horizen Telegram – https://horizen.io/invite/telegram Horizen on Bitcointalk – https://goo.gl/5vicqP Horizen YouTube Channel – https://www.youtube.com/c/Horizen/ Horizen Facebook Page – https://www.facebook.com/horizenglobal/ Horizen on Instagram - https://instagram.com/horizenglobal Horizen Blog on Medium – https://medium.com/@horizen Buy or Sell Horizen Horizen on CoinMarketCap – https://bit.ly/ZENCoinMarketCap Horizen on CoinGecko – https://bit.ly/ZENCoinGecko                                      

Recently, GitHub released Copilot, which is an amazing AI pair programmer powered by OpenAI's Codex model. In this episode, Natalie Pistunovich tells us all about Codex and helps us understand where it fits in our development workflow. We also discuss MLOps and how AI is influencing software engineering more generally.

Recently, GitHub released Copilot, which is an amazing AI pair programmer powered by OpenAI's Codex model. In this episode, Natalie Pistunovich tells us all about Codex and helps us understand where it fits in our development workflow. We also discuss MLOps and how AI is influencing software engineering more generally.

Steph gives an update about RSpec focus and how she often forgets to remove the focus feature from tests. She figured out two solutions: one using Rubocop, and the other from a Twitter user, suggesting using a GitHub gist. She also suggests that if you're one of those people who misses being in an office environment, you check out soundofcolleagues.com for ambient office noise selection. Chris has been struggling to actually do any coding and is adjusting to doing more product management and shares some strategies that have been helping him. They answer a listener question about dealing with large pull requests and how it's hard to recognize a good seam to break them up when you are in the thick of one. This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy. Twitter note re: rspec-retry (https://twitter.com/jasonrudolph/status/1458416077726158852) soundofcolleagues.com (https://soundofcolleagues.com) mailcheck (https://github.com/mailcheck/mailcheck) Inertia.js (https://inertiajs.com/) Svelte (https://svelte.dev/) devise (https://github.com/heartcombo/devise) clearance (https://github.com/thoughtbot/clearance) Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! Transcript: CHRIS: One day, I'll grow up. It's fine. I look forward to that day. But today, I don't think it's that day. Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. STEPH: And I'm Steph Viccari. CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world? STEPH: Hey, Chris. Well, in some fun news, Utah started his professional training as of this morning, which I'm very excited about. Because we've been working with him to work on being good with walking on a leash, FYI, he's not, [laughs] and also being good about not jumping on people. And essentially, being a really good roommate. And he started training today, and we are using an e-collar, which initially I was really hesitant about because I don't want it to hurt him in any way. But now that I have felt the e-collar myself and we've had a first day with it, it's going super well. I'm very excited for where this is headed. CHRIS: That's very exciting. When does he start paying rent? STEPH: Ooh. I'll have to check with him, or I guess I have set those boundaries. That's my job. CHRIS: I just figured that's a core part of being a good roommate. But maybe we've got baby steps or doggy steps to get there. But that's exciting. I'm glad [laughs] that the first day of training is going well. STEPH: Yeah, it's going great. And the place that we're going to the trainer they have horses, and mules, and goats. And so now I have a very cute video of him trying to play with a goat, and the goat was having none of it. But it's still all very cute. In tech-related news, I have an update for when you and I were recently chatting about the RSpec focus and how I mentioned that I often forget to remove the focus feature from tests. And so then that goes up to a PR, and I have to rely on a kind human to let me know, and then I remove it. Or worst-case scenario, it gets merged into the main branch. And for anyone that's not on Twitter, I just wanted to share an update because I also shared something there. But the resolution for what I was looking for there's already a rule that's written into Rubocop, but it's specifically written in the Rubocop RSpec codebase. And with that rule, you can essentially just say, hey, let me know anytime that a test is using the focus metadata, and then make sure to let me know and fail. And then if you don't want to actually include all of Rubocop into your project because Rubocop is pretty opinionated, you can still add Rubocop to your project, but you can specifically add Rubocop RSpec, and then you can say, hey, all other rules disabled by default, but then you can enable that specific rule. So then, that way, you will catch all of your focus tests. There's also another approach that someone on Twitter shared with us recently from Marz Drel. And Marz shared specifically a really nice simple GitHub Gist that documents or exemplifies that you can add an environment variable that checks to say, hey, if we're in CI mode, then add a before hook. And then that before hook will look for any examples that are using that focus metadata, and then it's going to raise. And then if we're not in CI mode, then don't do anything, don't raise, and carry on. And that's just a really nice simple addition if someone didn't want to pull in Rubocop into their project. CHRIS: Both of those definitely sound like great options. I don't think we have Rubocop on the current project that I'm working on. But I think the RSpec focus thing, the metadata one, seems like it'll work great. More generally, I just want to thank folks out there who listen to the show and then write back in like, "Hey, this is probably what you want." There was a similar thread that someone shared around the RSpec::Retry stuff that I was talking about recently and the failure mode there and trying to get that into the Junit Reporter. And so they had some suggestions around that. Jason Rudolph on Twitter reached out, sharing just his initial exploration and thoughts on how it might be possible to extend the XML reports that are generated and capture a flaky test in that way. So that's really interesting. And again, just really love that folks are listening to the things that we say and then even adding on to them and continuing the conversation. So thanks to everybody for sharing those things. STEPH: Yeah, it's incredibly helpful. And then one other fun thing that I'd love to share, and I found this out from someone else at thoughtbot because they had shared it recently. But it's a neat website called soundofcolleagues.com. And I know you've got your laptop in front of you. So if you'll go visit it, it'll be neat to see as we're talking through it. For anyone else that wants to pull it up, too, we'll include a link in the show notes. But it's a neat project that someone started where you can bump up the sounds that you would normally hear in an office. So maybe you want to bump up background noise of people or an open window. There's one specifically for printers and a coffee machine, and keyboards are on there as well. [laughs] I have discovered I am partial open window and partial rain, although rain is just always my go-to. I like the sound of rain for when I'm working. CHRIS: Gentle rain is definitely nice white noise in general. I've seen this for coffee shops, but I haven't seen the particular one. Also, yes, I definitely know how to spell the word colleague on the first of three tries. Definitely didn't have to rely on Google for that one. But yeah, nice site there. I enjoy that. STEPH: I tried the keyboard option that's on there because I was like, oh yeah, I'm totally going to be into this. This is going to be my jam. I don't think it is because I realized that I'm very biased. I like the sound of my own keyboard. So I had to shush the other one and just listen to the rain and the open window. But that's some of the fun things that are going on in my world today. What's new in your world? CHRIS: I'm just now spending a moment with the keyboard sound. It's a very muted keyboard. I want a little more clackety. STEPH: A little more clackety? CHRIS: I was assuming it would be too much clackety, and that would be the problem. But it sounds more mushy. Maybe we can pipe in some of the sound here [laughs] at this point. Or we can link to these sounds, and everyone can dial up the keyboards to 100. But I, too, am partial to the sounds of my own keyboard. But what's new in my world? This past week and I think probably even a little bit more of the prior week, I've been noticing that I've been struggling to actually do any coding, which has been interesting to observe. And again, trying to observe it, not necessarily judge it, although if that's not the thing that we want to be doing, then try and improve that. But mostly trying to observe what's going on, what is taking my time. A lot of it is product management type work. So I am spending a good amount of time trying to gather the different voices and understand what is the work to be done, and then shape that into the backlog and make sure that that's clear and ready for the team to pick up. And then, thankfully, the other two developers that are working on the project are fantastically prolific. So they're often very quickly working through the work that has been set up in front of them. And so I'm trying to then be proactive and respond to the code. But there's almost a cycle to it where I'm just staying out in front of them, but they're catching up with everything that's going on. So it's something that I'm trying again to be intentional about, name, share some of that back up with the group. If there are things that I'm doing that I don't uniquely need to be doing, then let's share as much of that knowledge as possible. But one thing that I will say is the product management, shaping the backlog work is exhausting. I am astonished by just how drained I am at the end of the day. And I'm like, I don't even really feel like I did anything. I didn't write any code, but I am just completely spent. And there really is something to when the work is clear, just doing the work, I can actually find energizing. And it's fun, and I can get in flow state. And sometimes, I'll be drained in a certain way. But the work of taking a bunch of different slack threads, and communications, and meetings, and synthesizing that down, and then determining what the work needs to look like moving forward, and providing enough clarity but then not over constraining and not providing too much clarity. And there are so many micro-decisions that are being made in there. And I'm just spent at the end of the day, and I have so much...I've always had a lot of respect for product managers and folks that are existing in that interstitial space and trying to make sense of the noise, especially of a growing company, but all the more so this week as I've been feeling some of that myself. STEPH: I totally agree. I have felt that having a strong product manager really makes or breaks a project for me where even though having technical leadership is really nice, I'd prefer someone that's really strong at the product knowledge and then helping direct where the product is headed. That is incredibly helpful. Like you mentioned, the work is exhausting. There's someone that joined the thoughtbot team fairly recently, and I was chatting with them about what type of projects they would be interested in working on. And one of their responses was, "I'd love to work on a project with a strong product manager because I have been doing that a fair amount for recent years. And I would love to get back to just focusing on coding." And so I think they enjoyed some of the work, but they just recognize it's exhausting. And I'd really like to just get back to writing code for a while. CHRIS: Yeah, I'm definitely in that space. And I think there's a ton of value to spending a little bit of time, like having any developer at some point in their career spend a little bit of time managing the backlog, and you will learn a bunch from that. But I'm also in the space of I would love to just turn on some music and code for a while. That sounds fun. There's a lot of work to be done right now. I'd love to just be in there doing the work. But sometimes, out of necessity, the defining of the work is the thing that's important. And so, I think I've been correctly assessing the most important thing. And that that has consistently for a while now been the defining and responding to the work that's in process as opposed to doing it myself. But, man, I really hope I get to dive back into the code sometime and use my clackety keyboard to its fullest extent. STEPH: Have you found any particular strategies that really help you with the product management work? CHRIS: I will say that I think this is a competency. This is a skillset and a career path that...again, I've been at plenty of organizations that I don't think respected the role as much as it should be. But it's an incredibly hard role and multidisciplinary communication at the core of it. And so I don't think I'm great at it is the thing that I'll say. So everything that follows is just to be clear; I'm not saying that I'm great at this, but I have been doing some of it. So here are some thoughts that I have. I think a lot of it is in reaction to where I felt like the work was clear. So I have a sense of what it looks like when I can go to the backlog, trust that it is in a roughly solid priority order, pick up a piece of work and immediately go to work on it. And understand what are the end-user implications of this piece of work? Where would I start on it like, how technically? What's a rough approach that I would have? And getting that level of specificity just right. So it's not overconstrained, but it's not under constrained. So having experienced that on the developer side, I try and then use that to shape some of the guidance that I'm putting into, say, the Trello tickets that I'm writing up here. We recently introduced Trello epics, which is I want to say like an add-on. And that allows us just the tiniest bit of product management, like one level up. So instead of just having cards and a list that is like, here's the work to be done, we now have an epics list that is separate to it, and it links between a card and its associated epics. So it's like project and action within that project. And just that little touch of structure there has been really, really useful to help look at like, okay, what are the big pieces that we're trying to move? And then how do they break down into the smaller pieces? So a tiny, tiny bit of fanciness in our product management tool, not Jira-like not going in that direction yet for as long as I cannot. But that little bit of structure. And then thinking about what has been useful to me as I pick up tickets. And then, as always, trying to just always be cognizant of what is the user's experience here? What problem am I trying to solve for them? What is their experience going to be? How will they know how to work with this feature? And just always asking that and then framing the work to be done in the context of that. STEPH: I like how you're adamant about a little bit of fanciness but not all the way to Jira-like. I also like how you highlighted end-users. All of that, I think, is awesome when developers are able to expand their role to experience all the other facets of building software. CHRIS: Yeah, definitely. I think that whole list of all of the different facets of where our work interacts with different groups. The more empathy or, the more experience that you can have there, the better that you'll be able to understand how to communicate there, how to express things in terms, et cetera, et cetera. So a huge fan of all of those ideas. I am ready to just get back in the code for a few minutes, though. But for now, for as long as necessary, I'll do some of this work. But I am trying to find my way to other things. In terms of actual feature work that we're working on, one of the things that we're doing right now is restructuring our onboarding. So when a user comes and signs up to the website and then subsequently has to fill out a handful of other forms, there's actually an external system that we've been working with that houses some of the core data of our application. And they have a hosted application form. So we can send the user over to them, and the user fills out the rest of the application on this other system's site. And then they get redirected back to us. And everything's got nice DNS entries for a particular subdomain and whatnot. So it looks roughly consistent. There's some branding. But it's still someone else's UI, essentially. And we were feeling enough pain from that experience. We were like; you know what? It's time. We're going to bring this back in-house. We're going to do all the forms ourselves. We're going to do a nice progressive little progress bar. You can see all the steps as you're going through onboarding. We're just going to own that more because that's a core part of the experience that we're building here. So biting the bullet, deciding to do that. But there's an interesting edge case that we run into, which is we are using Devise for authentication. Totally makes sense. We're in Rails context; there we go. It's the thing to use. But Devise exists in truly the Rails world. So like HTML ERB templates, the controllers have certain expectations as to what's going on. So thus far, we've just let that exist in that world and everything else we're building in Inertia and Svelte. But we're just now starting to feel enough of the pain, and that Devise exists in this other context. And for a while, we just kept saying, "You know what? It's not worth the effort to port it over. It's fine." Because we're using Tailwind, we have a consistent design language that we can use across them. That said, the components are drifting a little bit. And it's like, oh, this one's got a rounded corner like this, and that one's got this color. And we don't have the disabled style. But it is nice that it's not completely distinct. But we have finally decided it is time. We need to port this thing over because we feel like the onboarding and authentication type flows; they're actually a big part of the user experience or at least the first run user experience when someone's signing up to our site. So we want to own that a little bit more. One of the things that I ran into as I was trying to introduce Mailcheck, which is a library that I've talked about, I think in a previous episode...but basically, you can have it observe a field and if someone types in like, user@gmaip.com, you can like, did you mean gmail.com? And then go from there. And I think there's more subtlety. They can maybe even look up MX records and things like that. But basically validate an email address heuristically and offer the nice, very friendly to a user, "Hey, did you mean this instead?" So not a full validation that says, "No, you cannot put your email address," because maybe you have a weird one that sounds like Gmail but isn't. But that's a little bit trickier to implement both on the Devise side and then in any other place that we have an email input. And so what we want to do is port over to Inertia and Svelte, and then everything's in our nice, happy context with all our components and all the other work that we're doing. And it really does just highlight how much I've come to enjoy working with Inertia and Svelte. They are fantastic technologies. And now I just want absolutely everything to be in them. So we're finally going to bite the bullet, and I think port those over a little bit after we get the current batch of work done. But soon, soon, that's the goal. STEPH: I'm having a bit of déjà vu where I feel like there was a project that you were working on that was using Devise, and then removing Devise and replacing it with something else was a challenge. Does that ring a bell? CHRIS: Yes, that is accurate. So I had a project that I worked on where we had both Devise and Clearance was actually what was going on. There were basically two different applications that existed; one was using Clearance, the later one used Devise. But then we folded those two applications back together. And by virtue of that, I tried to unify the authentication schemes, and it was like, nope, not going to happen. And then we didn't. STEPH: And then we didn't. [laughs] I like that ending. CHRIS: Well, sometimes you don't. [laughs] STEPH: Yeah, I love that ending because it reflects reality. Sometimes that just happens. In fact, I'm going to segue for just a moment because you're reminding me that there's something I don't think I've shared with you yet. On my previous project, there was a particular feature. It was a big feature that someone had picked up and worked on. And at one point, we were essentially playing hot potato with this feature because we hadn't gotten it to the point that it was merged. There was too much that was happening in that pull request, although then we ended up merging it. But then we found lots of bugs. And it was just one of those features that we couldn't really get across the finish line. There was always something else that was wrong with it or needed to be done or needed to be considered. And we'd reach that point where Chad Pytel, who is on the project, was like, "We're either going to finish this, or we're going to throw it away." And I felt a little guilty saying this, and I was like, "I vote we throw it away. I have lots of concerns about this. We are essentially reimplementing another complex workflow. But now, we are implementing it pretty differently in another portion of the application. It's going to be hard to manage. The cost of adding this and maintaining this is a really high concern." And so he talked with the rest of the team and came back, and he's like, "Yep, we're going to throw it away." And so then he issued a PR, and we removed it. And it was one of those moments of like; this isn't great because then we have invested hours into this, and now we are taking it away. But it also felt really good that that's always an option. And that was the better option because it was either we're going to continue sinking more time into this, or we can stop it now. And then we can move on to more important work. CHRIS: Sunk costs and all that. STEPH: Yeah. I feel like it's so rare when that really happens because then we just feel dedicated to like, well, we're going to make this valuable to somebody. We're going to keep this. And in this case, we just threw it away. It's very nice. CHRIS: There's a similar anecdote that I remember. Actually, I think it's happened more than once. But very particularly, we were working on a system. And this was with our friend, Matt Sumner, a friend of the show, as well been on a few times. And Matt was working on the project. And we got to a point where we had two competing implementations of a given workflow, and we were opting to go with the new one. But there were folks that were saying, "Let's keep the code around for the old one." And Matt was like, "Absolutely not. If we do that, we might go...no, this will be bad. Then we have to maintain that code. We need to burn the ships," as he said. And he actually named the pull request burn the ships where he just removed all the code. And I was like, I like your style, man. You made a decision here. We collectively made a decision. And then this is a classic Matt Sumner move. But he did the thing that we said we were going to do. And he just held that line. And I really appreciated it. And it's a voice that I have in the back of my head often now, which is just like, no, burn the ships. If we need it, it'll be in Git history. We can recover it. But it's going to need to be handled in the interim. We don't want to have to support that code right now and for however long until we actually decide to remove it from the codebase. So let's get rid of it. And if we really need it, well, then we'll resurrect it, but for now, burn the ships. And I like that. STEPH: I like that too. I think it's one of those areas where it takes experience to feel that pain too. If you're pretty new to writing code, you're going to think, well, we can keep it around. There's no harm. And so it often has to be that sage, that person who's been around long enough and felt some pain from making that decision in prior centuries or years. And he's like, "No, we're not going to do this." The WE collective of developers who have experienced the pain from this understand that that's not a good choice. And so we're going to burn the ships instead. But it is one of those that if you're newer, you won't think that way. And I think that's totally reasonable that you wouldn't think that immediately. CHRIS: I think that tacit knowledge that oh, I've gone through this before, and I've experienced the pain, and now let me tell you about that. And let me try and share that with you because there's always the cost-benefit trade-off. Because if that code stays in the codebase, then we know it works because we've kept it around for that whole time. And so there's a nicety to that, but there's a cost, that maintenance cost. And being able to express that well and being able to say, "I've been here, and let me tell you a tale," but do it in a way that doesn't sound overly condescending or explainy or things like that. I think that's a very subtle skill and a very important one, and frankly, really hard one to get right. I'm not sure I always hit the mark on that where I'm just like, "No, can't do it. It's bad." I think it's very easy to end up in a space where you're just like, "No, it's bad." And they're like, "But why?" And you're like, "Because it's bad. Trust me." It's like, well, I feel like you do need to be able to explain the stories, the experiences that you've had in the past, the anecdotes that you've heard, the blog posts that you've read that have really informed your thinking. But I think that is a big part of what it means to continue on in this profession and be able to do the work and make those subtle trade-offs, and the it depends because, at the end of the day, it all depends. STEPH: Or you just issue a pull request and title it burn the ships. [laughs] CHRIS: Burn the ships. Indeed, that is, in fact an option. And actually, while we're on the topic of pull requests, this might be a perfect segue into a listener question that we have. Mid-roll Ad And now a quick break to hear from today's sponsor, Scout APM. Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more. Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform. See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. CHRIS: As always, thanks to everyone who sends in listener questions. We so appreciate getting them. They help direct the conversation and give us something to chat about. So this question comes in from Bryan Robles. And Bryan writes in about large pull requests. And Bryan writes in with, "My toxic trait is large pull requests. Any tips on when you get into a place where you're fixing or refactoring something, and it ends up cascading to many more changes than you want it to? I sometimes can go back and break it up. But it's hard to recognize a good seam when you're in the thick of it." So, Steph, what do you think? Large pull requests and finding yourself in them after [laughs] certain amounts of time. STEPH: Yeah, speaking of that knowledge that often comes from experience, this is something that I'm certainly always striving to get better at. I think it does take practice. There are some things that I do that I can share. And I categorize them really into a before, and I guess midway. So there's the before I set sail and set off to deeper waters list that I will think through as I'm starting a new task, and then there's the I'm lost at sea. And then, I need to figure out how I'm going to organize this change. So in the first category, when I'm first starting off a task, I consider what sort of changes need to be made, and are there any obvious roadblocks? So an obvious roadblock may be changing or updating a model that has one relationship, and I need to change it to has many relationships. Or perhaps there's a part of the application that is untested. And before I make any changes, I need to document that existing behavior. And that really falls neatly within Kent Beck's advice where he said, "First make the change easy (warning: this might be hard) and then make the easy change." So I try to think upfront what are some of the small, incremental changes that I can make first that will then make the final change easy? And then I separate that mentally into PRs. Or I may separate it into tickets, whatever is going to help me stay organized and communicate how I'm breaking up that work. And then the other thing that I'll do is I'll consider what's my MVP? So what's my minimum viable pull request? What set of changes include just enough changes to be helpful to users or to other developers? Which, by the way, is also a helpful mindset to have when you're breaking down work into tickets. So, as an example, let's say that I need to fix some bad data that's causing a site to error. So my first step could be to write a task to fix the bad data. And then, step two, prevent bad data from being created. And then probably step three, I need to rerun the task to fix data that was created during step two. But I can think through each of those steps and separate them into different pull requests. And then there may also be the question of well, how small is too small? Like you're saying, what's a minimum viable pull request? How do I know if I am not delivering value? And that one gets a little trickier and vague. But ultimately, I will think, does it pass CI? Is this change deployable? And then I do have to define what value I'm delivering. And I think that's a common area that folks struggle because we'll think of delivering value as delivering a whole new feature or adding complete test coverage for an untested interface. But delivering value doesn't have to represent that end goal. It may be that you added one test for an untested interface. And that's still delivering really great value to your team, same for delivering a feature to a user. You may be able to speak with that wonderful product manager and find what's the smallest bit of value that you can deliver instead of the whole feature set? I think the smallest PR I can think of that I've issued is either fixing a typo or removing a focus metadata from an RSpec test. So that's my starting point. That's the before I set sail. Those are some of the things I think about. I have more for the I'm lost at sea. But what are your thoughts? CHRIS: First, that was a great summary that you gave. So I totally agree with everything that you just said. I think part of the question I would have...So Bryan wrote this in and described this as his toxic trait. So he's identifying this as something that seemingly consistently plagues him. So I would ask, is there a way that you can introduce something? Like, are there natural breaks in your day? And can you ask the question at those breaks? Like, hey, I've been working on a thing for a little while. Is there a version that I could...like, could I close off a body of work at this moment? When you break for lunch, if you go grab coffee in the morning, when you're leaving at the end of the day, use those natural breakpoints. I'm not sure exactly what you mean when you say large pull requests. But if those are spanning multiple days, in my mind, if anything starts to span more than a day, I will start to ask that question to myself. And that's a reflex that I built up over time by feeling the pain of large pull requests and putting it up, and feeling apologetic. And then having my colleagues gently, professionally kindly ask me to break it down into smaller pieces. And me saying, "I really don't want it. All right, fine, fine, fine, I'll do it." And then I do it. And it's one of those things that I never want to do in the first place, but I'm always happy to have done after the fact. But it is work. And so, if I can get better at pulling that thinking and pulling that question earlier in the process, that I think is really useful. Similarly, I will try to, again, as friendly as I can; if I notice someone mentioning the same body of work at stand up for a few days, I might gently ask, "Hey, is there a way that we can find a shippable version of a portion of that of a subset? Can we put it up behind a feature flag and get something out there just to try and keep the PR small, et cetera?" And so gently nudge in that direction. And then I think the other side of that is being very okay with one character PRs. Like, that's it. We changed one character. It turns out we need to pluralize that word, or we need one-line changes are great. That's fine. And more pull requests, in my mind, are better than fewer, larger pull requests. And so really embracing that and having that be part of the core conversation and demonstrating that throughout the team is a way to share this idea. So that's perhaps more in the process or person point of view on this as opposed to the technical, but that's part of the consideration that I would have. I am interested, and I'll bounce back to, Steph, what you were saying of now that you're out at sea, what do you do? STEPH: So I need to react positively to some of the things that you just said because you made me think of two things. One of them is I've never had someone say, "Hey, Steph, that PR is too small. Could you add some more changes to it? Could you do some more work?" I have had people say, "Hey, that PR was hard to review." But even then, sometimes getting that feedback from folks is hard because nobody really wants to say, "I had a hard time reviewing your PR." That's something that, over time, you may become really comfortable saying to someone. But I think initially, people don't want to say, "Hey, that was hard to review," or "There were a lot of changes in that. Would you break it down?" Because that's a lot of complex emotions and discussion to have there. But yeah, I just figured I'd share that I have never had someone complain that a PR is too small, and I've issued a single character change. And then I love, love how much you asked the question of what's the problem we're trying to solve? And so there's this ambiguous idea of a large PR. But what does that mean? What are the pain points? What are we actually looking to change about our behavior? And then how is that going to impact or benefit the team or benefit ourselves? And so, going back to the question of how do we measure this? How do I know I'm starting to break up my changes in a helpful way? We may need to circle back to that because I don't have answers to it. But I just really like asking that question. As for the I'm lost at sea part, or maybe you're not lost at sea, but you've caught too many fish, and the fish warden is going to fuss at you if you bring too many fish back to dock. I don't think this is a real nautical example. But here we are. CHRIS: Was that the fish warden? STEPH: Yeah, the fish warden. You know, the fish warden. [laughs] CHRIS: Sure, I do, yeah. Yeah, I know about that, well-versed in fish law. STEPH: [laughs] Got to know your fish law. If we're going to talk about pull requests, you got to introduce fish law. But I'm actually going to quote Joël Quenneville, a fellow thoughtboter, because they shared a thoughtful thread on Twitter that talks a lot about breaking up your changes and how to break up your pull requests and your commits. And I'll be sure to include a link in the show notes because it's really worth reading as there's a lot of knowledge in that thread. But one of the things that Joël says is get comfortable with Git, and it makes a world of difference. In particular, you want to get really good at git add --patch, git reset, and git rebase interactive. And that is so true for me. Once I have gotten really good at using those commands, then I feel like I can break up anything. Because often when I am helping someone break something up, it's often they want to, but they're like, "I don't know how. And this is going to take so much of my time. It doesn't feel efficient and the right thing to do." And they're probably right. If you don't know how to break it up, then it may take you too long. And maybe it's not worth it at that point. But if you can ask a friend, and they can help walk you through this process, or if you can learn on your own, that's going to be a game-changer because you will start to think about how can I separate these commits? And I can reorder them, and then issue separate PRs, or just keep them in separate commits, whatever process you're looking to improve. In fact, there's a really great course on Upcase called Mastering Git written by someone who is co-host of this podcast. And it has a lot of great videos and tutorials that will help you get really good at these Git commands and then will help you split up your commits. CHRIS: Oh yeah, I did do that. Warning: it's like three and a half hours long. But it is broken up into, I believe, 10 or 11 videos. So you can find just the ones that you want. There's a couple in the middle that I think are particularly useful talking about the object model of Git. Git is weird, unfortunately. And so I spent a bunch of time in that course. Also, thank you for the kind words, Steph. [laughs] But I spent a bunch of time in that course trying to make Git less weird or understandable. If you look under the hood, it starts to make more sense. But if you really want to get comfortable with manipulating Git history, which I think is a really useful skill for this conversation that we're having, that's the only way I found to do it, just memorizing the steps. It's always going to feel a little bit foreign. But once you understand the stuff under the hood, that's a really useful thing for being able to manipulate and tease apart a pull request and break it into different things, and port things from one branch to another, and all those fun activities. Yeah, man, that was a bunch of years ago too. I wonder what I look like in it. Huh. STEPH: I really liked that episode, the one you just mentioned, the Git Object Model. Now that you've mentioned it, I remember watching it, and it's very interesting. So yeah, thank you for making all this helpful content for folks. There's also a blog post that we can include in the show notes as well that is a really nice overview of using git interactive, and rebase, and squash and amend those types of behaviors as well. So will be sure to include both so folks can check those out. And then to round things out, one of the other things that I will do is I will ask a friend. I will ask someone for help. So we've talked about some of these behaviors, or some of these processes that we have are really built up from experience and practice. And you can watch a lot of helpful content, and you can read blog posts. But sometimes, it really just takes time to get good at it. I know, as I'd mentioned earlier, I am always still looking to improve this particular skill because I think it's so valuable. And one of the ways I do that is I will just phone a friend. And I'll say, "Hey, can we chat for a bit? I would like to show you my changes. I want to hear from you if you see something in here that's valuable that you think can be shipped independently, so that way we can get it delivered faster." Or it may be a change that's just like a test improvement or something. And we can go ahead and get that immediately released to the team, and it will benefit them. Or you may want to do this at the start of a ticket. If I am new to a project or when I am new to a project, I will often ask someone to break down a ticket with me if I'm feeling a little bit uncertain. Or just say, "Hey, do you see any clean lines of division here? I feel like there's a lot in this ticket. You're more familiar with the codebase. What would you ship? How would you ship this incrementally?" and have someone else walk through the process with you. CHRIS: Yep, the phone a friend and/or, as always, pairing is a wonderful tool in these sorts of situations. The one other thing that comes to mind for me is part of the question was about sometimes it's difficult to find a clear parting line within a larger body of work, within a larger change. And that can definitely be true. I think there are certain standouts of like is this a refactoring that can be shipped separately? Is this a test change that would be useful on its own? Is there a model change that we could break out and have just that go out? So there's a bunch of mechanical questions that we can ask and say; here's categories of things that might fit that bill. But to flip this to the other side, the question was asked by Bryan very much as an I struggle with this thing. This is my toxic trait is the phrase that he used, which I thought was really interesting. And that can be true. This can be something that if you're consistently and uniquely within the team producing these giant PRs and then folks find that difficult to review, then I think that is absolutely something to work on. But if this is something that is happening between members like, other members of the team are also finding that they keep ending up with PRs that are bigger than they expected and taking longer and harder to review, there is a question of is the codebase actually in a shape that makes it harder to do small changes? There's the phrase shotgun surgery, which refers to a codebase that is so entangled and coupled that any change requires modifying ten files just to make one small alteration. And I think that's a worthwhile question to step back and ask, actually, is it not me? Is it actually the codebase? It could be both certainly. But there is a version of your codebase is coupled in a way that means that any even small, tiny change requires touching so many different places in the code. And if that's true, that's at least worth naming and worth highlighting and maybe talking about in retro and saying, hey, this feels like it's true. So maybe we start to get intentional about refactoring, and breaking out, and starting to add those dividing lines within the code such that hopefully, down the road, small changes can, in fact, be small changes. So that is the one last thing that I would consider here. Also, anecdotally, this is just a thing that came to mind. As I've worked with strongly-typed languages, systems that have a compiler, and have a type system, and the ability for the compiler to keep an eye on the whole codebase, I've noticed that it's very easy to do this sort of thing where I just start with one small data model change, and then the compiler is like, oh, you got to go fix it here, and here, and here, and here. And I found that because the compiler is your friend and will just point you to all the places you need to make the change, it is very easy to just keep going because some of that mechanical work is happening on your behalf. And it's a wonderful facet of typed languages and of having a compiler and being able to have that conversation with the compiler. But I found that for me, it is much easier to end up in this mode where I'm like, oh no, this PR is way too large. When I'm working in a system that has types, that has a compiler, that frankly makes it a little bit easier to chase down all the places you need to make a change. So that's also a consideration. It's not necessarily a good or a bad thing, just something that I've observed that feels like it's adjacent to this conversation. But yeah, I think those are my thoughts. STEPH: Yeah, those are great points. I've certainly worked on projects where that felt very true where it's a small change, but it would cascade throughout the project. And all the changes were necessary. It wasn't something that I could split into smaller PRs. So checking if it is the codebase that's really making it hard to have small PRS is a really great idea. CHRIS: Who'd have thunk such a little question could get us rambling for so long? Oh, wait, I would have thunk that. STEPH: And so far, reflecting on the things that we've talked about so far, I think I've talked a good game of where I'm saying, "Oh, I identify the seams upfront, and then I organize and create different tickets." And that is very much not the case. That's the really ideal outcome. But often, I am in the thick of things where like you just said...and it's this moment of, oh, I've done a lot in this PR. And how can I break this up? And that does take time. And it becomes a conversation of trade-off, which is why those Git skills really come in handy because then it will lower the cost of then splitting things out for others. But for people that are struggling with creating smaller PRs, I do think it's very fair to ask your team for help. I think it's also fair that if you issued a large pull request and folks have already reviewed it, and it's gotten approved, and someone makes a comment like, "Oh, this would be great as two PRs instead of one," to say, "Awesome, thank you for letting me know. I will take that forward with me, but I'm not going to do it for this PR." I wouldn't recommend making that a habit. But just know that that is something that you can say to someone to say, "I think this one is good to go at this point. But I will keep that in mind for future PRs. And I may even reach out to you for help if I feel like I'm having trouble splitting up a PR." And bring that person into your progress and use them as an accountability buddy. They can be someone that helps you down that path towards smaller PRs. CHRIS: Yeah, I definitely agree with that, although it becomes a very subtle line. Saying, "Thank you, but no thank you," in a pull request or to feedback is delicate. It's difficult. That's a whole thing. But I agree there have been times where I have either been the one making that decision or suggesting that or being like, "We probably should have broken this up. But we're far enough along now. Let's get this merged. And then we'll iterate on it after the fact." One last thing, actually. I thought I was done, but I have one more thing, which is I feel like there's a strong parallel between test-driven development and this question in that, often, I hear folks saying, "I don't know how to write tests upfront. I don't know how to do that. I know after the fact I can write tests, and I can add them after." And that can definitely be true. It can become more obvious after you've written the code how you could then write a test that would constrain that behavior that would interact with the system. But I think the useful thing that you can do there is take a moment and pause there and say, "Okay, now that I have written the test, what would it look like if I had written this in the first place?" Or if you really want to go for it, throw away the code, try again. Start with the test first and then rebuild it. That's maybe a little much. But that thing of taking these moments of maybe you don't know upfront how to break the work into smaller pieces, but then you get to the end, and you have that conversation with someone. And they highlight where some parting lines would be, or you figure it out after the fact. Stay there in that moment. Meditate on it a bit and try and internalize that knowledge because that's how moving forward, you might know how to do this in the future. So take those moments, whether it be with TDD or with pull requests, or breaking up a ticket into smaller tickets, anything like that. And spend a moment there and try and internalize that knowledge so that you have it proactively moving forward. STEPH: You know how Slack has status? I really like the idea of there being a status that's meditating on...and you can fill it in. And the example that you just provided, meditating on splitting up a pull request or meditating on how to write a test first, [laughs] I think that would be delightful. CHRIS: I, too, think that would be delightful. But with that long, adventurous answer to what seemed like a simple question, and they always do, but here we are, shall we wrap up? STEPH: Let's wrap up. CHRIS: The show notes for this episode can be found at bikeshed.fm. STEPH: This show is produced and edited by Mandy Moore. CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes, as it really helps other folks find the show. STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. CHRIS: And I'm @christoomey STEPH: Or you can reach us at hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. All: Byeeeeeeeeeee! Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Charles Pincourt is a STEM professor who has recently published a book (edited by James Lindsay) about the ideological capture of academia by Critical Social Justice (aka Wokeness). In this conversation we speak about the ins and outs of this ideology, and how cold war era spy novels gave him clever strategies to counter it. Buy Counter Wokecraft: amzn.to/3r1y0Ak Find Charles on twitter @wokedissident and on GitHub: https://woke-dissident.github.io Support this channel: https://www.paypal.me/benjaminboyce --- Send in a voice message: https://anchor.fm/calmversations/message

In this Hasty Treat, Wes and Scott talk about their experiences using Github Co-pilot. Show Notes 00:58 Wake up early and let's go 02:19 Sponsor: LogRocket 03:21 Sponsor: Freshbooks 03:56 What is Github Co-Pilot? GitHub Co-Pilot 06:01 Scott is a GitHub Star 07:03 Examples of GitHub Co-Pilot usage 09:43 Writing pseudo code Emmet 12:51 Using it for loop callbacks 13:52 What langauges does GitHub Co-Pilot work with? 14:54 It plays nice with HTML files 15:48 Svelte component example 16:31 Benefits for course creators 17:35 Some scary things 21:04 Could GitHub start charging for this? 22:30 Good at writing types 23:59 Gripes 24:54 Converting code to Parcel 2 Parcel Tweet us your tasty treats Scott's Instagram LevelUpTutorials Instagram Wes' Instagram Wes' Twitter Wes' Facebook Scott's Twitter Make sure to include @SyntaxFM in your tweets

Custom schemes, http schemes, protocols, they are a pain to develop for, but are so powerful! After years of using them, we finally figured out how to automate it and we have a lot of ideas! Follow Us Frank: Twitter, Blog, GitHub James: Twitter, Blog, GitHub Merge Conflict: Twitter, Facebook, Website, Chat on Discord Music : Amethyst Seer - Citrine by Adventureface ⭐⭐ Review Us (https://itunes.apple.com/us/podcast/merge-conflict/id1133064277?mt=2&ls=1) ⭐⭐ Machine transcription available on http://mergeconflict.fm

Claroty researcher Vera Mens and JFrog researcher Shachar Menashe join the podcast to discuss a recent research collaboration between the two companies that looked at the security of BusyBox. Busybox is a popular embedded Linux utility suite, and is found everywhere in operational technology, including in devices such as PLCs, HMIs, and RTUs.The researchers published a paper that describes 14 vulnerabilities uncovered in BusyBox—all of which were patched—and the custom fuzzing harnesses used to trigger the bugs. The harnesses were released to open source by Claroty and can be found on GitHub. 

The gang is back together to discuss the latest tech news after our two fantasy football centric episodes. Jeanine is pinch hitting for Ed, as Ed had some bad clams, and we will just leave it with that.    We start off discussing the story that one lucky or unlucky individual can sell their face for the price of two hundred thousand dollars to be the face of PromoBot robots moving forward. If you are interested in selling your face then go here.   Sight Tech global will be December 1 and December 2, you can register for the free virtual online conference here. Friend of the podcast, Larry Goldberg and Brian will be presenting on a panel at the conference.    Jeanine then fills us in about the Carroll Centerer Virtual Technology Fair that took place on November 23rd.   Some Tesla owners got locked out of their cars by the Tesla app, and boy did we laugh our asses off about it. HBOMax and Air Pods, Pod Pros, and Maxes are not playing nicely together, well at least for sighted people! Amazon has released a Mac stand alone app for amazon Prime, and while the design is clunky, the catalyst designed app seems accessible.   We discuss Black Friday, because some of us want things, and some of us may flip flop about what we want.  We then discuss our go to shopping apps and the state of these apps accessibility in November 2022.    It's the story that will not go away, Apple is on track to deliver a fully autonomous self driving car by 2025. Will this happen? What laws and regulations will need to go in to affect for a blind person to take control and get out on the road?  Apple is also bringing Do It Yourself fixes for iPhones and Macs to the masses in 2022.   With security vulnerabilities not going away, we revisit what we are doing to keep our passwords safe and unique.    We then discuss a few new products that are actually not Apple! But of course at the end of the day, it all comes back to Apple, as Windows could potentially becoming to M1 Macs after a contract between Qualcomm and Microsoft expires. We then discuss a brilliant plug in for your Mac, VOcr. You can download it from GitHub. Here is the direct download link.   And it's more of Watcha Streaming, Watcha Reading.    To contact That Real Blind Tech Show, you can email us at ThatRealBlindTechShow@gmail.com, join our Facebook Group That Real Blind Tech Show, join us on the Twitter @BlindTechShow , or leave us an old school phone message at 929-367-1005.

Idan Cohen, Co-founder and CEO of Reflectiz, joined the crew to share how they detect website vulnerabilities and threats. He also discussed the risks of third and fourth-party code. In the news, the guys covered the Windows 10 21H2 release, Apple's move to let you fix your own devices, and Twitter stopping AMP support. Then two groups were pwned last week, with GoDaddy exposing WordPress data and Firefox users sharing login cookies on GitHub. Oops.

Idan Cohen, Co-founder and CEO of Reflectiz, joined the crew to share how they detect website vulnerabilities and threats. He also discussed the risks of third and fourth-party code. In the news, the guys covered the Windows 10 21H2 release, Apple's move to let you fix your own devices, and Twitter stopping AMP support. Then two groups were pwned last week, with GoDaddy exposing WordPress data and Firefox users sharing login cookies on GitHub. Oops.

Eric and Brandon talk about RHEL 8.5 and RHEL 9 Beta and talk about some interesting tools for managing your datacenter and IT assets. Destination Linux Network (https://destinationlinux.network) Sudo Show Website (https://sudo.show) Sponsor: Bitwarden (https://bitwarden.com/dln) Sponsor: Digital Ocean (https://do.co/dln) Sudo Show Swag (https://sudo.show/swag) Contact Us: DLN Discourse (https://sudo.show/discuss) Email Us! (mailto:contact@sudo.show) Sudo Matrix Room (https://sudo.show/matrix) Follow our Hosts: Brandon's Website (https://open-tech.net) Brandon's GitHub (https://github.com/dbrandonjohnson) Brandon's Gitlab (https://gitlab.com/sudoshow) Eric's Website (https://itguyeric.com) Red Hat Streaming (https://www.redhat.com/en/livestreaming) Asset Management https://snipeitapp.com/ CMDB (Content Management Database) https://www.cmdbuild.org OS Ticket (can be morphed into it added it because it is a widely used solution) https://osticket.org IPAM/DCIM (IP Address Management and Datacenter Infrastructure Management) https://github.com/netbox-community/netbox Chapters 00:00 Intro 00:42 Welcome 02:00 Sponsor: Bitwarden 03:02 Sponsor: Digital Ocean 04:10 RHEL 8.5 and 9 Beta 21:18 Snipit Asset Management 33:56 CMDB Build 36:11 OSTicket 37:44 Netbox 46:55 Call to Action 48:20 Wrap Up

In the previous episodes, we looked at the rise of patents and software and their impact on the nascent computer industry. But a copyright is a right. And that right can be given to others in whole or in part. We have all benefited from software where the right to copy was waved and it's shaped the computing industry as much, if not more, than proprietary software. The term Free and Open Source Software (FOSS for short) is a blanket term to describe software that's free and/or whose source code is distributed for varying degrees of tinkeration. It's a movement and a choice. Programmers can commercialize our software. But we can also distribute it free of copy protections. And there are about as many licenses as there are opinions about what is unique, types of software, underlying components, etc. But given that many choose to commercialize their work products, how did a movement arise that specifically didn't? The early computers were custom-built to perform various tasks. Then computers and software were bought as a bundle and organizations could edit the source code. But as operating systems and languages evolved and businesses wanted their own custom logic, a cottage industry for software started to emerge. We see this in every industry - as an innovation becomes more mainstream, the expectations and needs of customers progress at an accelerated rate. That evolution took about 20 years to happen following World War II and by 1969, the software industry had evolved to the point that IBM faced antitrust charges for bundling software with hardware. And after that, the world of software would never be the same. The knock-on effect was that in the 1970s, Bell Labs pushed away from MULTICS and developed Unix, which AT&T then gave away as compiled code to researchers. And so proprietary software was a growing industry, which AT&T began charging for commercial licenses as the bushy hair and sideburns of the 70s were traded for the yuppy culture of the 80s. In the meantime, software had become copyrightable due to the findings of CONTU and the codifying of the Copyright Act of 1976. Bill Gates sent his infamous “Open Letter to Hobbyists” in 1976 as well, defending the right to charge for software in an exploding hobbyist market. And then Apple v Franklin led to the ability to copyright compiled code in 1983. There was a growing divide between those who'd been accustomed to being able to copy software freely and edit source code and those who in an up-market sense just needed supported software that worked - and were willing to pay for it, seeing the benefits that automation was having on the capabilities to scale an organization. And yet there were plenty who considered copyright software immoral. One of the best remembered is Richard Stallman, or RMS for short. Steven Levy described Stallman as “The Last of the True Hackers” in his epic book “Hackers: Heroes of the Computer Revolution.” In the book, he describes the MIT Stallman joined where there weren't passwords and we didn't yet pay for software and then goes through the emergence of the LISP language and the divide that formed between Richard Greenblatt, who wanted to keep The Hacker Ethic alive and those who wanted to commercialize LISP. The Hacker Ethic was born from the young MIT students who freely shared information and ideas with one another and help push forward computing in an era they thought was purer in a way, as though it hadn't yet been commercialized. The schism saw the death of the hacker culture and two projects came out of Stallman's technical work: emacs, which is a text editor that is still included freely in most modern Unix variants and the GNU project. Here's the thing, MIT was sitting on patents for things like core memory and thrived in part due to the commercialization or weaponization of the technology they were producing. The industry was maturing and since the days when kings granted patents, maturing technology would be commercialized using that system. And so Stallman's nostalgia gave us the GNU project, born from an idea that the industry moved faster in the days when information was freely shared and that knowledge was meant to be set free. For example, he wanted the source code for a printer driver so he could fix it and was told it was protected by an NDAQ and so couldn't have it. A couple of years later he announced GNU, a recursive acronym for GNU's Not Unix. The next year he built a compiler called GCC and the next year released the GNU Manifesto, launching the Free Software Foundation, often considered the charter of the free and open source software movement. Over the next few years as he worked on GNU, he found emacs had a license, GCC had a license, and the rising tide of free software was all distributed with unique licenses. And so the GNU General Public License was born in 1989 - allowing organizations and individuals to copy, distribute, and modify software covered under the license but with a small change, that if someone modified the source, they had to release that with any binaries they distributed as well. The University of California, Berkley had benefited from a lot of research grants over the years and many of their works could be put into the public domain. They had brought Unix in from Bell Labs in the 70s and Sun cofounder and Java author Bill Joy worked under professor Fabry, who brought Unix in. After working on a Pascal compiler that Unix coauthor Ken Thompson left for Berkeley, Joy and others started working on what would become BSD, not exactly a clone of Unix but with interchangeable parts. They bolted on the OSI model to get networking and through the 80s as Joy left for Sun and DEC got ahold of that source code there were variants and derivatives like FreeBSD, NetBSD, Darwin, and others. The licensing was pretty permissive and simple to understand: Copyright (c) . All rights reserved. Redistribution and use in source and binary forms are permitted provided that the above copyright notice and this paragraph are duplicated in all such forms and that any documentation, advertising materials, and other materials related to such distribution and use acknowledge that the software was developed by the . The name of the may not be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED ``AS IS AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. By 1990 the Board of Regents at Berkley accepted a four clause BSD license that spawned a class of licenses. While it's matured into other formats like a 0 clause license it's one of my favorites as it is truest to the FOSS cause. And the 90s gave us the Apache License, from the Apache Group, loosely based on the BSD License and then in 2004 leaning away from that with the release of the Apache License 2 that was more compatible with the GPL license. Given the modding nature of Apache they didn't require derivative works to also be open sourced but did require leaving the license in place for unmodified parts of the original work. GNU never really caught on as an OS in the mainstream, although a collection of tools did. The main reason the OS didn't go far is probably because Linus Torvalds started releasing prototypes of his Linux operating system in 1991. Torvalds used The GNU General Public License v2, or GPLv2 to license his kernel, having been inspired by a talk given by Stallman. GPL 2 had been released in 1991 and something else was happening as we turned into the 1990s: the Internet. Suddenly the software projects being worked on weren't just distributed on paper tape or floppy disks; they could be downloaded. The rise of Linux and Apache coincided and so many a web server and site ran that LAMP stack with MySQL and PHP added in there. All open source in varying flavors of what open source was at the time. And collaboration in the industry was at an all-time high. We got the rise of teams of developers who would edit and contribute to projects. One of these was a tool for another aspect of the Internet, email. It was called popclient, Here Eric S Raymond, or ESR for short, picked it up and renamed it to fetchmail, releasing it as an open source project. Raymond presented on his work at the Linux Congress in 1997, expanded that work into an essay and then the essay into “The Cathedral and the Bazaar” where bazaar is meant to be like an open market. That inspired many to open source their own works, including the Netscape team, which resulted in Mozilla and so Firefox - and another book called “Freeing the Source: The Story of Mozilla” from O'Reilly. By then, Tim O'Reilly was a huge proponent of this free or source code available type of software as it was known. And companies like VA Linux were growing fast. And many wanted to congeal around some common themes. So in 1998, Christine Peterson came up with the term “open source” in a meeting with Raymond, Todd Anderson, Larry Augustin, Sam Ockman, and Jon “Maddog” Hall, author of the first book I read on Linux. Free software it may or may not be but open source as a term quickly proliferated throughout the lands. By 1998 there was this funny little company called Tivo that was doing a public beta of a little box with a Linux kernel running on it that bootstrapped a pretty GUI to record TV shows on a hard drive on the box and play them back. You remember when we had to wait for a TV show, right? Or back when some super-fancy VCRs could record a show at a specific time to VHS (but mostly failed for one reason or another)? Well, Tivo meant to fix that. We did an episode on them a couple of years ago but we skipped the term Tivoization and the impact they had on GPL. As the 90s came to a close, VA Linux and Red Hat went through great IPOs, bringing about an era where open source could mean big business. And true to the cause, they shared enough stock with Linus Torvalds to make him a millionaire as well. And IBM pumped a billion dollars into open source, with Sun moving to open source openoffice.org. Now, what really happened there might be that by then Microsoft had become too big for anyone to effectively compete with and so they all tried to pivot around to find a niche, but it still benefited the world and open source in general. By Y2K there was a rapidly growing number of vendors out there putting Linux kernels onto embedded devices. TiVo happened to be one of the most visible. Some in the Linux community felt like they were being taken advantage of because suddenly you had a vendor making changes to the kernel but their changes only worked on their hardware and they blocked users from modifying the software. So The Free Software Foundation updated GPL, bundling in some other minor changes and we got the GNU General Public License (Version 3) in 2006. There was a lot more in GPL 3, given that so many organizations were involved in open source software by then. Here, the full license text and original copyright notice had to be included along with a statement of significant changes and making source code available with binaries. And commercial Unix variants struggled with SGI going bankrupt in 2006 and use of AIX and HP-UX Many of these open source projects flourished because of version control systems and the web. SourceForge was created by VA Software in 1999 and is a free service that can be used to host open source projects. Concurrent Versions System, or CVS had been written by Dick Grune back in 1986 and quickly became a popular way to have multiple developers work on projects, merging diffs of code repositories. That gave way to git in the hearts of many a programmer after Linus Torvalds wrote a new versioning system called git in 2005. GitHub came along in 2008 and was bought by Microsoft in 2018 for 2018. Seeing a need for people to ask questions about coding, Stack Overflow was created by Jeff Atwood and Joel Spolsky in 2008. Now, we could trade projects on one of the versioning tools, get help with projects or find smaller snippets of sample code on Stack Overflow, or even Google random things (and often find answers on Stack Overflow). And so social coding became a large part of many a programmers day. As did dependency management, given how many tools are used to compile a modern web app or app. I often wonder how much of the code in many of our favorite tools is actually original. Another thought is that in an industry dominated by white males, it's no surprise that we often gloss over previous contributions. It was actually Grace Hopper's A-2 compiler that was the first software that was released freely with source for all the world to adapt. Sure, you needed a UNIVAC to run it, and so it might fall into the mainframe era and with the emergence of minicomputers we got Digital Equipment's DECUS for sharing software, leading in part to the PDP-inspired need for source that Stallman was so adamant about. General Motors developed SHARE Operating System for the IBM 701 and made it available through the IBM user group called SHARE. The ARPAnet was free if you could get to it. TeX from Donald Knuth was free. The BASIC distribution from Dartmouth was academic and yet Microsoft sold it for up to $100,000 a license (see Commodore ). So it's no surprise that people avoided paying upstarts like Microsoft for their software or that it took until the late 70s to get copyright legislation and common law. But Hopper's contributions were kinda' like open source v1, the work from RMS to Linux was kinda' like open source v2, and once the term was coined and we got the rise of a name and more social coding platforms from SourceForge to git, we moved into a third version of the FOSS movement. Today, some tools are free, some are open source, some are free as in beer (as you find in many a gist), some are proprietary. All are valid. Today there are also about as many licenses as there are programmers putting software out there. And here's the thing, they're all valid. You see, every creator has the right to restrict the ability to copy their software. After all, it's their intellectual property. Anyone who chooses to charge for their software is well within their rights. Anyone choosing to eschew commercialization also has that right. And every derivative in between. I wouldn't judge anyone based on any model those choose. Just as those who distribute proprietary software shouldn't be judged for retaining their rights to do so. Why not just post things we want to make free? Patents, copyrights, and trademarks are all a part of intellectual property - but as developers of tools we also need to limit our liability as we're probably not out there buying large errors and omissions insurance policies for every script or project we make freely available. Also, we might want to limit the abuse of our marks. For example, Linus Torvalds monitors the use of the Linux mark through the Linux Mark Institute. Apparently some William Dell Croce Jr tried to register the Linux trademark in 1995 and Torvalds had to sue to get it back. He provides use of the mark using a free and perpetual global sublicense. Given that his wife won the Finnish karate championship six times I wouldn't be messing with his trademarks. Thank you to all the creators out there. Thank you for your contributions. And thank you for tuning in to this episode of the History of Computing Podcast. Have a great day.

Matt Holt is the creator of popular open source projects like Caddy Web Server, CertMagic, PapaParse, & others. If you've ever wondered what it would be like to maintain open source projects full-time, Matt is the man to speak with. We learn how he came up with the idea for Caddy, how it works, and the pro's and con's of building a sustainable an open source project. Want to show your support for Caddy? Become a sponsor on GitHub!Connect with Matt:https://twitter.com/mholt6https://github.com/mholtMentioned in today's episode:https://github.com/caddyserver/caddyhttps://caddy.community https://www.amazon.com/PHP-MySQL-Development-Luke-Welling/dp/0672317842https://en.wikipedia.org/wiki/Automated_Certificate_Management_Environment https://github.com/mholt/timelinerWant more from Ardan Labs?You can learn Go, Kubernetes, Docker & more through our video training, live events, or through our blog!

dabappsJamie on GitHub and TwitterUnpolydjango-readersdjango-zen-queriesdjango-rest-framework-serialization-specdjango-db-queuedjango-log-request-idDjango Views - The Right Way by Luke PlantDjango Vanilla Views by Tom ChristieBlack Friday Sale50% off the list price of the books Django for Beginners/APIs/Professionals by William Vincent, co-host of this podcast and current Django Software Foundation Board Member. Offer valid through Friday, November 26th, end of day.

This is the 51st episode of Lightning Junkies! In this episode we have Ben Arc returning, he was previously on episode LNJ031 (https://sicksub.network/LNJ031)! In this episode we are focusing on the world of LNbits, it is a way to add more features and options than would ordinarily be available in your Bitcoin Lightning Stack. We talk about: 0:00 - Intro 1:27 - A Prolific Creator 6:17 - The Start of Ben Arc 12:12 - How to Choose a Project 15:31 - Sci-Fi Weirdos 21:53 - Ben's Opinion on Bolt12 26:03 - AMP Invoices 27:08 - What is LNbits? 37:01 - DJ Livestream tipping 41:23 - LNDHub 47:25 - Extension Lightning Round 52:16 - The Future of LNbits 1:02:53 - How can YOU help the Lightning Network? 1:07:09 - The Idea Tangent 1:21:32 - Excitement for the Future FIND GUEST HERE ------------------------------------------------ Ben's Twitter:https://twitter.com/arcbtc LNbits' Twitter: https://twitter.com/lnbits LNbits' GitHub: https://github.com/arcbtc/lnbits VALUE 4 VALUE ------------------------------------------------

About StephanieStephanie Wong is an award-winning speaker, engineer, pageant queen, and hip hop medalist. She is a leader at Google with a mission to blend storytelling and technology to create remarkable developer content. At Google, she's created over 400 videos, blogs, courses, and podcasts that have helped developers globally. You might recognize her as the host of the GCP Podcast. Stephanie is active in her community, fiercely supporting women in tech and mentoring students.Links: Personal Website: https://stephrwong.com Twitter: https://twitter.com/stephr_wong TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: This episode is sponsored in part by our friends at Vultr. Spelled V-U-L-T-R because they're all about helping save money, including on things like, you know, vowels. So, what they do is they are a cloud provider that provides surprisingly high performance cloud compute at a price that—while sure they claim its better than AWS pricing—and when they say that they mean it is less money. Sure, I don't dispute that but what I find interesting is that it's predictable. They tell you in advance on a monthly basis what it's going to going to cost. They have a bunch of advanced networking features. They have nineteen global locations and scale things elastically. Not to be confused with openly, because apparently elastic and open can mean the same thing sometimes. They have had over a million users. Deployments take less that sixty seconds across twelve pre-selected operating systems. Or, if you're one of those nutters like me, you can bring your own ISO and install basically any operating system you want. Starting with pricing as low as $2.50 a month for Vultr cloud compute they have plans for developers and businesses of all sizes, except maybe Amazon, who stubbornly insists on having something to scale all on their own. Try Vultr today for free by visiting: vultr.com/screaming, and you'll receive a $100 in credit. Thats v-u-l-t-r.com slash screaming.Corey: This episode is sponsored by our friends at Oracle Cloud. Counting the pennies, but still dreaming of deploying apps instead of "Hello, World" demos? Allow me to introduce you to Oracle's Always Free tier. It provides over 20 free services and infrastructure, networking, databases, observability, management, and security. And—let me be clear here—it's actually free. There's no surprise billing until you intentionally and proactively upgrade your account. This means you can provision a virtual machine instance or spin up an autonomous database that manages itself all while gaining the networking load, balancing and storage resources that somehow never quite make it into most free tiers needed to support the application that you want to build. With Always Free, you can do things like run small scale applications or do proof-of-concept testing without spending a dime. You know that I always like to put asterisks next to the word free. This is actually free, no asterisk. Start now. Visit snark.cloud/oci-free that's snark.cloud/oci-free.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. One of the things that makes me a little weird in the universe is that I do an awful lot of… let's just call it technology explanation slash exploration in public, and turning it into a bit of a brand-style engagement play. What makes this a little on the weird side is that I don't work for a big company, which grants me a tremendous latitude. I have a whole lot of freedom that lets me be all kinds of different things, and I can't get fired, which is something I'm really good at.Inversely, my guest today is doing something remarkably similar, except she does work for a big company and could theoretically be fired if they were foolish enough to do so. But I don't believe that they are. Stephanie Wong is the head of developer engagement at Google. Stephanie, thank you for volunteering to suffer my slings and arrows about all of this.Stephanie: [laugh]. Thanks so much for having me today, Corey.Corey: So, at a very high level, you're the head of developer engagement, which is a term that I haven't seen a whole lot of. Where does that start and where does that stop?Stephanie: Yeah, so I will say that it's a self-proclaimed title a bit because of the nuance of what I do. I would say at its heart, I am still a part of developer relations. If you've heard of developer advocacy or developer evangelist, I would say this slight difference in shade of what I do is that I focus on scalable content creation and becoming a central figure for our developer audiences to engage and enlighten them with content that, frankly, is remarkable, and that they'd want to share and learn about our technology.Corey: Your bio is fascinating in that it doesn't start with the professional things that most people do with, “This is my title and this is my company,” is usually the first sentence people put in. Yours is, “Stephanie Wong is an award-winning speaker, engineer, pageant queen, and hip hop medalist.” Which is both surprising and more than a little bit refreshing because when I read a bio like that my immediate instinctive reaction is, “Oh, thank God. It's a real person for a change.” I like the idea of bringing the other aspects of what you are other than, “This is what goes on in an IDE, the end,” to your audience.Stephanie: That is exactly the goal that I had when creating that bio because I truly believe in bringing more interdisciplinary and varied backgrounds to technology. I, myself have gone through a very unconventional path to get to where I am today and I think in large part, my background has had a lot to do with my successes, my failures, and really just who I am in tech as an uninhibited and honest, credible person today.Corey: I think that there's a lack of understanding, broadly, in our industry about just how important credibility and authenticity are and even the source of where they come from. There are a lot of folks who are in the DevRel space—devrelopers, as I insist upon calling them, over their protests—where, on some level, the argument is, what is developer relations? “Oh, you work in marketing, but they're scared to tell you,” has been my gag on that one for a while. But they speak from a position of, “I know what's what because I have been in the trenches, working on these large-scale environments as an engineer for the last”—fill in the blank, however long it may have been—“And therefore because I have done things, I am going to tell you how it is.” You explicitly call out that you don't come from the traditional, purely technical background. Where did you come from? It's unlikely that you've sprung fully-formed from the forehead of some god, but again, I'm not entirely sure how Google finds and creates the folks that it winds up advancing, so maybe you did.Stephanie: Well, to tell you the truth. We've all come from divine creatures. And that's where Google sources all employees. So. You know. But—[laugh].Corey: Oh, absolutely. “We climbed to the top of Olympus and then steal fire from the gods.” “It's like, isn't that the origin story of Prometheus?” “Yeah, possibly.” But what is your background? Where did you come from?Stephanie: So, I have grown up, actually, in Silicon Valley, which is a little bit ironic because I didn't go to school for computer science or really had the interest in becoming an engineer in school. I really had no idea.Corey: Even been more ironic than that because most of Silicon Valley appears to never have grown up at all.Stephanie: [laugh]. So, true. Maybe there's a little bit of that with me, too. Everybody has a bit of Peter Pan syndrome here, right? Yeah, I had no idea what I wanted to do in school and I just knew that I had an interest in communicating with one another, and I ended up majoring in communication studies.I thought I wanted to go into the entertainment industry and go into production, which is very different and ended up doing internships at Warner Brothers Records, a YouTube channel for dance—I'm a dancer—and I ended up finding a minor in digital humanities, which is sort of this interdisciplinary minor that combines technology and the humanities space, including literature, history, et cetera. So, that's where I got my start in technology, getting an introduction to information systems and doing analytics, studying social media for certain events around the world. And it wasn't until after school that I realized that I could work in enterprise technology when I got an offer to be a sales engineer. Now, that being said, I had no idea what sales engineering was. I just knew it had something to do with enterprise technology and communications, and I thought it was a good fit for my background.Corey: The thing that I find so interesting about that is that it breaks the mold of what people expect, when, “If someone's going to talk to me about technology—especially coming from a”—it's weird; it's one of the biggest companies on the planet, and people still on some level equate Google with the startup-y mentality of being built in someone's garage. That's an awfully big garage these days, if that's even slightly close to true, which it isn't. But there's this idea of, “Oh, you have to go to Stanford. You have to get a degree in computer science. And then you have to go and do this, this, this, this, and this.”And it's easy to look dismissively at what you're doing. “Communications? Well, all that would teach you to do is communicate to people clearly and effectively. What possible good is that in tech?” As we look around the landscape and figure out exactly why that is so necessary in tech, and also so lacking?Stephanie: Exactly. I do think it's an underrated skill in tech. Maybe it's not so much anymore, but I definitely think that it has been in the past. And even for developers, engineers, data scientists, other technical practitioner, especially as a person in DevRel, I think it's such a valuable skill to be able to communicate complex topics simply and understandably to a wide variety of audiences.Corey: The big question that I have for you because I've talked to an awful lot of folks who are very concerned about the way that they approach developer relations, where—they'll have ratios, for example—where I know someone and he insists that he give one deeply technical talk for every four talks that are not deeply technical, just because he feels the need to re-establish and shore up his technical bona fides. Now, if there's one thing that people on the internet love, it is correcting people on things that are small trivia aspect, or trying to pull out the card that, “Oh, I've worked on this system for longer than you've worked on this system, therefore, you should defer to me.” Do you find that you face headwinds for not having the quote-unquote, “Traditional” engineering technical background?Stephanie: I will say that I do a bit. And I did, I would say when I first joined DevRel, and I don't know if it was much more so that it was being imposed on me or if it was being self-imposed, something that I felt like I needed to prove to gain credibility, not just in my organization, but in the industry at large. And it wasn't until two or three years into it, that I realized that I had a niche myself. It was to create stories with my content that could communicate these concepts to developers just as effectively. And yes, I can still prove that I can go into an hour-long or a 45-minute-long tech talk or a webinar about a topic, but I can also easily create a five to ten-minute video that communicates concepts and inspires audiences just the same, and more importantly, be able to point to resources, code labs, tutorials, GitHub repos, that can allow the audience to be hands-on themselves, too. So really, I think that it was over time that I gained more experience and realized that my skill sets are valuable in a different way, and it's okay to have a different background as long as you bring something to the table.Corey: And I think that it's indisputable that you do. The concept of yours that I've encountered from time to time has always been insightful, it is always been extremely illuminating, and—you wouldn't think of this as worthy of occasion and comment, but I feel it needs to be said anyway—at no point in any of your content did I feel like I was being approached in a condescending way, where at every point it was always about uplifting people to a level of understanding, rather than doing the, “Well, I'm smarter than you and you couldn't possibly understand the things that I've been to.” It is relatable, it is engaging, and you add a very human face to what is admittedly an area of industry that is lacking in a fair bit of human element.Stephanie: Yeah, and I think that's the thing that many folks DevRel continue to underline is the idea of empathy, empathizing with your audiences, empathizing with the developers, the engineers, the data engineers, whoever it is that you're creating content for, it's being in their shoes. But for me, I may not have been in those shoes for years, like many other folks historically have been in for DevRel, but I want to at least go through the journey of learning a new piece of technology. For example, if I'm learning a new platform on Google Cloud, going through the steps of creating a demo, or walking through a tutorial, and then candidly explaining that experience to my audience, or creating a video about it. I really just reject the idea of having ego in tech and I would love to broaden the opportunity for folks who came from a different background like myself. I really want to just represent the new world of technology where it wasn't full of people who may have had the privilege to start coding at a very early age, in their garages.Corey: Yeah, privilege of, in many respects, also that privilege means, “Yes, I had the privilege of not having to have friends and deal with learning to interact with other human beings, which is what empowered me to build this company and have no social skills whatsoever.” It's not the aspirational narrative that we sometimes are asked to believe. You are similar in some respects to a number of things that I do—by which I mean, you do it professionally and well and I do it as basically performance shitpost art—but you're on Twitter, you make videos, you do podcasts, you write long-form and short-form as well. You are sort of all across the content creation spectrum. Which of those things do you prefer to do? Which ones of those are things you find a little bit more… “Well, I have to do it, but it's not my favorite?” Or do you just tend to view it as content is content; you just look at different media to tell your story?Stephanie: Well, I will say any form of content is queen—I'm not going to say king, but—[laugh] content is king, content is queen, it doesn't matter.Corey: Content is a baroness as it turns out.Stephanie: [laugh]. There we go. I have to say, so given my background, I mentioned I was into production and entertainment before, so I've always had a gravitation towards video content. I love tinkering with cameras. Actually, as I got started out at Google Cloud, I was creating scrappy content using webcams and my own audio equipment, and doing my own research, and finding lounges and game rooms to do that, and we would just upload it to our own YouTube channel, which probably wasn't allowed at the time, but hey, we got by with it.And eventually, I got approached by DevRel to start doing it officially on the channel and I was given budget to do it in-studio. And so that was sort of my stepping stone to doing this full-time eventually, which I never foresaw for myself. And so yeah, I have this huge interest in—I'm really engaged with video content, but once I started expanding and realizing that I could repurpose that content for podcasting, I could repurpose it for blogs, then you start to realize that you can shard content and expand your reach exponentially with this. So, that's when I really started to become more active on social media and leverage it to build not just content for Google Cloud, but build my own brand in tech.Corey: That is the inescapable truth of DevRel done right is that as you continue doing it, in time, in your slice of the industry, it is extremely likely that your personal brand eclipses the brand of the company that you represent. And it's in many ways a test of corporate character—if it makes sense—as do how they react to that. I've worked in roles before I started this place where I was starting to dabble with speaking a lot, and there was always a lot of insecurity that I picked up of, “Well, it feels like you're building your personal brand, not advancing the company here, and we as a company do not see the value in you doing that.” Direct quote from the last boss I had. And, well, that partially explains why I'm here, I suppose.But there's insecurity there. I'd see the exact opposite coming out of Google, especially in recent times. There's something almost seems to be a renaissance in Google Cloud, and I'm not sure where it came from. But if I look at it across the board, and you had taken all the labels off of everything, and you had given me a bunch of characteristics about different companies, I would never have guessed that you were describing Google when you're talking about Google Cloud. And perhaps that's unfair, but perceptions shape reality.Stephanie: Yeah, I find that interesting because I think traditionally in DevRel, we've also hired folks for their domain expertise and their brand, depending on what you're representing, whether it's in the Kubernetes space or Python client library that you're supporting. But it seems like, yes, in my case, I've organically started to build my brand while at Google, and Google has been just so spectacular in supporting that for me. But yeah, it's a fine line that I think many people have to walk. It's like, do you want to continue to build your own brand and have that carry forth no matter what company you stay at, or if you decide to leave? Or can you do it hand-in-hand with the company that you're at? For me, I think I can do it hand-in-hand with Google Cloud.Corey: It's taken me a long time to wrap my head around what appears to be a contradiction when I look at Google Cloud, and I think I've mostly figured it out. In the industry, there is a perception that Google as an entity is condescending and sneering toward every other company out there because, “You're Google, you know how to do all these great, amazing things that are global-spanning, and over here at Twitter for Pets, we suck doing these things.” So, Google is always way smarter and way better at this than we could ever hope to be. But that is completely opposed to my personal experiences talking with Google employees. Across the board, I would say that you all are self-effacing to a fault.And I mean that in the sense of having such a limited ego, in some cases, that it's, “Well, I don't want to go out there and do a whole video on this. It's not about me, it's about the technology,” are things that I've had people who work at Google say to me. And I appreciate the sentiment; it's great, but that also feels like it's an aloofness. It also fails to humanize what it is that you're doing. And you are a, I've got to say, a breath of fresh air when it comes to a lot of that because your stories are not just, “Here's how you do a thing. It's awesome. And this is all the intricacies of the API.”And yeah, you get there, but you also contextualize that in a, “Here's why it matters. Here's the problem that solves. Here is the type of customer's problem that this is great for,” rather than starting with YAML and working your way up. It's going the other way, of, “We want to sell some underpants,” or whatever it is the customer is trying to do today. And that is the way that I think is one of the best ways to drive adoption of what's going on because if you get people interested and excited about something—at least in my experience—they're going to figure out how the API works. Badly in many cases, but works. But if you start on the API stuff, it becomes a solution looking for a problem. I like your approach to this.Stephanie: Thank you. Yeah, I appreciate that. I think also something that I've continued to focus on is to tell stories across products, and it doesn't necessarily mean within just Google Cloud's ecosystem, but across the industry as well. I think we need to, even at Google, tell a better story across our product space and tie in what developers are currently using. And I think the other thing that I'm trying to work on, too, is contextualizing our products and our launches not just across the industry, but within our product strategy. Where does this tie in? Why does it matter? What is our forward-looking strategy from here? When we're talking about our new data cloud products or analytics, [unintelligible 00:17:21], how does this tie into our API strategy?Corey: And that's the biggest challenge, I think, in the AI space. My argument has been for a while—in fact, I wrote a blog post on it earlier this year—that AI and machine learning is a marvelously executed scam because it's being pushed by cloud providers and the things that you definitely need to do a machine learning experiment are a bunch of compute and a whole bunch of data that has to be stored on something, and wouldn't you know it, y'all sell that by the pound. So, it feels, from a cynical perspective, which I excel at espousing, that approach becomes one of you're effectively selling digital pickaxes into a gold rush. Because I see a lot of stories about machine learning how to do very interesting things that are either highly, highly use-case-specific, which great, that would work well, for me too, if I ever wind up with, you know, a petabyte of people's transaction logs from purchasing coffee at my national chain across the country. Okay, that works for one company, but how many companies look like that?And on the other side of it, “It's oh, here's how we can do a whole bunch of things,” and you peel back the covers a bit, and it looks like, “Oh, but you really taught me here is bias laundering?” And, okay. I think that there's a definite lack around AI and machine learning of telling stories about how this actually matters, what sorts of things people can do with it that aren't incredibly—how do I put this?—niche or a problem in search of a solution?Stephanie: Yeah, I find that there are a couple approaches to creating content around AI and other technologies, too, but one of them being inspirational content, right? Do you want to create something that tells the story of how I created a model that can predict what kind of bakery item this is? And we're going to do it by actually showcasing us creating the outcome. So, that's one that's more like, okay. I don't know how relatable or how appropriate it is for an enterprise use case, but it's inspirational for new developers or next gen developers in the AI space, and I think that can really help a company's brand, too.The other being highly niche for the financial services industry, detecting financial fraud, for example, and that's more industry-focused. I found that they both do well, in different contexts. It really depends on the channel that you're going to display it on. Do you want it to be viral? It really depends on what you're measuring your content for. I'm curious from you, Corey, what you've seen across, as a consumer of content?Corey: What's interesting, at least in my world, is that there seems to be, given that what I'm focusing on first and foremost is the AWS ecosystem, it's not that I know it the best—I do—but at this point, it's basically Stockholm Syndrome where it's… with any technology platform when you've worked with it long enough, you effectively have the most valuable of skill sets around it, which is not knowing how it works, but knowing how it doesn't, knowing what the failure mode is going to look like and how you can work around that and detect it is incredibly helpful. Whereas when you're trying something new, you have to wait until it breaks to find the sharp edges on it. So, there's almost a lock-in through, “We failed you enough times,” story past a certain point. But paying attention to that ecosystem, I find it very disjointed. I find that there are still events that happen and I only find out when the event is starting because someone tweets about it, and for someone who follows 40 different official AWS RSS feeds, to be surprised by something like that tells me, okay, there's not a whole lot of cohesive content strategy here, that is at least making it easy for folks to consume the things that they want, especially in my case where even the very niche nature of what I do, my interest is everything.I have a whole bunch of different filters that look for various keywords and the rest, and of course, I have helpful folks who email me things constantly—please keep it up; I'm a big fan—worst case, I'd rather read something twice than nothing. So, it's helpful to see all of that and understand the different marketing channels, different personas, and the way that content approaches, but I still find things that slip through the cracks every time. The thing that I've learned—and it felt really weird when I started doing it—was, I will tell the same stories repeatedly in different forums, or even the same forum. I could basically read you a Twitter thread from a year ago, word-for-word, and it would blow up bigger than it did the first time. Just because no one reads everything.Stephanie: Exactly.Corey: And I've already told my origin story. You're always new to someone. I've given talks internally at Amazon at various times, and I'm sort of loud and obnoxious, but the first question I love to ask is, “Raise your hand if you've never heard of me until today.” And invariably, over three-quarters of the room raises their hand every single time, which okay, great. I think that's awesome, but it teaches me that I cannot ever expect someone to have, quote-unquote, “Done the reading.”Stephanie: I think the same can be said about the content that I create for the company. You can't assume that people, A) have seen my tweets already or, B) understand this product, even if I've talked about it five times in the past. But yes, I agree. I think that you definitely need to have a content strategy and how you format your content to be more problem-solution-oriented.And so the way that I create content is that I let them fall into three general buckets. One being that it could be termed definition: talking about the basics, laying the foundation of a product, defining terms around a topic. Like, what is App Engine, or Kubeflow 101, or talking about Pub/Sub 101.The second being best practices. So, outlining and explaining the best practices around a topic, how do you design your infrastructure for scale and reliability.And the third being diagnosis: investigating; exploring potential issues, as you said; using scripts; Stackdriver logging, et cetera. And so I just kind of start from there as a starting point. And then I generally follow a very, very effective model. I'm sure you're aware of it, but it's called the five point argument model, where you are essentially telling a story to create a compelling narrative for your audience, regardless of the topic or what bucket that topic falls into.So, you're introducing the problem, you're sort of rising into a point where the climax is the solution. And that's all to build trust with your audience. And as it falls back down, you're giving the results in the conclusion, and that's to inspire action from your audience. So, regardless of what you end up talking about this problem-solution model—I've found at least—has been highly effective. And then in terms of sharing it out, over and over again, over the span of two months, that's how you get the views that you want.Corey: This episode is sponsored in part by something new. Cloud Academy is a training platform built on two primary goals. Having the highest quality content in tech and cloud skills, and building a good community the is rich and full of IT and engineering professionals. You wouldn't think those things go together, but sometimes they do. Its both useful for individuals and large enterprises, but here's what makes it new. I don't use that term lightly. Cloud Academy invites you to showcase just how good your AWS skills are. For the next four weeks you'll have a chance to prove yourself. Compete in four unique lab challenges, where they'll be awarding more than $2000 in cash and prizes. I'm not kidding, first place is a thousand bucks. Pre-register for the first challenge now, one that I picked out myself on Amazon SNS image resizing, by visiting cloudacademy.com/corey. C-O-R-E-Y. That's cloudacademy.com/corey. We're gonna have some fun with this one!Corey: See, that's a key difference right there. I don't do anything regular in terms of video as part of my content. And I do it from time to time, but you know, getting gussied up and whatnot is easier than just talking into a microphone. As I record this, it's Friday, I'm wearing a Hawaiian shirt, and I look exactly like the middle-aged dad that I am. And for me at least, a big breakthrough moment was realizing that my audience and I are not always the same.Weird confession for someone in my position: I don't generally listen to podcasts. And the reason behind that is I read very quickly, and even if I speed up a podcast, I'm not going to be able to consume the information nearly as quickly as I could by reading it. That, amongst other reasons, is one of the reasons that every episode of this show has a full transcript attached to it. But I'm not my audience. Other people prefer to learn by listening and there's certainly nothing wrong with that.My other podcast, the AWS Morning Brief, is the spoken word version of the stuff that I put out in my newsletter every week. And that is—it's just a different area for people to consume the content because that's what works for them. I'm not one to judge. The hard part for me was getting over that hump of assuming the audience was like me.Stephanie: Yeah. And I think the other key part of is just mainly consistency. It's putting out the content consistently in different formats because everybody—like you said—has a different learning style. I myself do. I enjoy visual styles.I also enjoy listening to podcasts at 2x speed. [laugh]. So, that's my style. But yeah, consistency is one of the key things in building content, and building an audience, and making sure that you are valuable to your audience. I mean, social media, at the end of the day is about the people that follow you.It's not about yourself. It should never be about yourself. It's about the value that you provide. Especially as somebody who's in DevRel in this position for a larger company, it's really about providing value.Corey: What are the breakthrough moments that I had relatively early in my speaking career—and I think it's clear just from what you've already said that you've had a similar revelation at times—I gave a talk, that was really one of my first talks that went semi-big called, “Terrible Ideas in Git.” It was basically, learn how to use Git via anti-pattern. What it secretly was, was under the hood, I felt it was time I learned Git a bit better than I did, so I pitched it and I got a talk accepted. So well, that's what we call a forcing function. By the time I give that talk, I'd better be [laugh] able to have built a talk that do this intelligently, and we're going to hope for the best.It worked, but the first version of that talk I gave was super deep into the plumbing of Git. And I'm sure that if any of the Git maintainers were in the audience, they would have found it great, but there aren't that many folks out there. I redid the talk and instead approached it from a position of, “You have no idea what Git is. Maybe you've heard of it, but that's as far as it goes.” And then it gets a little deeper there.And I found that making the subject more accessible as opposed to deeper into the weeds of it is almost always the right decision from a content perspective. Because at some level, when you are deep enough into the weeds, the only way you're going to wind up fixing something or having a problem that you run into get resolved, isn't by listening to a podcast or a conference talk; it's by talking to the people who built the thing because at that level, those are the only people who can hang at that level of depth. That stops being fodder for conference talks unless you turn it into an after-action report of here's this really weird thing I learned.Stephanie: Yeah. And you know, to be honest, the one of the most successful pieces of content I've created was about data center security. I visited a data center and I essentially unveiled what our security protocols were. And that wasn't a deeply technical video, but it was fun and engaging and easily understood by the masses. And that's what actually ended up resulting in the highest number of views.On top of that, I'm now creating a video about our subsea fiber optic cables. Finding that having to interview experts from a number of different teams across engineering and our strategic negotiators, it was like a monolith of information that I had to take in. And trying to format that into a five-minute story, I realized that bringing it up a layer of abstraction to help folks understand this at a wider level was actually beneficial. And I think it'll turn into a great piece of content. I'm still working on it now. So, [laugh] we'll see how it turns out.Corey: I'm a big fan of watching people learn and helping them get started. The thing that I think gets lost a lot is it's easy to assume that if I look back in time at myself when I was first starting my professional career two decades ago, that I was exactly like I am now, only slightly more athletic and can walk up a staircase without getting winded. That's never true. It never has been true. I've learned a lot about not just technology but people as I go, and looking at folks are entering the workforce today through the same lens of, “Well, that's not how I would handle that situation.” Yeah, no kidding. I have two decades of battering my head against the sharp edges and leaving dents in things to inform that opinion.No, when I was that age, I would have handled it way worse than whatever it is I'm critiquing at the time. But it's important to me that we wind up building those pathways and building those bridges so that people coming into the space, first, have a clear path to get here, and secondly, have a better time than I ever did. Where does the next generation of talent come from has been a recurring question and a recurring theme on the show.Stephanie: Yeah. And that's exactly why I've been such a fierce supporter of women in tech, and also, again, encouraging a broader community to become a part of technology. Because, as I said, I think we're in the midst of a new era of technology, of people from all these different backgrounds in places that historically have had more remote access to technology, now having the ability to become developers at an early age. So, with my content, that's what I'm hoping to drive to make this information more easily accessible. Even if you don't want to become a Google Cloud engineer, that's totally fine, but if I can help you understand some of the foundational concepts of cloud, then I've done my job well.And then, even with women who are already trying to break into technology or wanting to become a part of it, then I want to be a mentor for them, with my experience not having a technical background and saying yes to opportunities that challenged me and continuing to build my own luck between hard work and new opportunities.Corey: I can't wait to see how this winds up manifesting as we see understandings of what we're offering to customers in different areas in different ways—both in terms of content and terms of technology—how that starts to evolve and shift. I feel like we're at a bit of an inflection point now, where today if I graduate from school and I want to start a business, I have to either find a technical co-founder or I have to go to a boot camp and learn how to code in order to build something. I think that if we can remove that from the equation and move up the stack, sure, you're not going to be able to build the next Google or Pinterest or whatnot from effectively Visual Basic for Interfaces, but you can build an MVP and you can then continue to iterate forward and turn it into something larger down the road. The other part of it, too, is that moving up the stack into more polished solutions rather than here's a bunch of building blocks for platforms, “So, if you want a service to tell you whether there's a picture of a hot dog or not, here's a service that does exactly that.” As opposed to, “Oh, here are the 15 different services, you can bolt together and pay for each one of them and tie it together to something that might possibly work, and if it breaks, you have no idea where to start looking, but here you go.” A packaged solution that solves business problems.Things move up the stack; they do constantly. The fact is that I started my career working in data centers and now I don't go to them at all because—spoiler—Google, and Amazon, and people who are not IBM Cloud can absolutely run those things better than I can. And there's no differentiated value for me in solving those global problems locally. I'd rather let the experts handle stuff like that while I focus on interesting problems that actually affect my business outcome. There's a reason that instead of running all the nonsense for lastweekinaws.com myself because I've worked in large-scale WordPress hosting companies, instead I pay WP Engine to handle it for me, and they, in turn, hosted on top of Google Cloud, but it doesn't matter to me because it's all just a managed service that I pay for. Because me running the website itself adds no value, compared to the shitpost I put on the website, which is where the value derives from. For certain odd values of value.Stephanie: [laugh]. Well, two things there is that I think we actually had a demo created on Google Cloud that did detect hot dogs or not hot dogs using our Vision API, years in the past. So, thanks for reminding me of that one.Corey: Of course.Stephanie: But yeah, I mean, I completely agree with that. I mean, this is constantly a topic in conversation with my team members, and with clients. It's about higher level of abstractions. I just did a video series with our fellow, Eric Brewer, who helped build cloud infrastructure here at Google over the past ten decades. And I asked him what he thought the future of cloud would be in the next ten years, and he mentioned, “It's going to be these higher levels of abstraction, building platforms on top of platforms like Kubernetes, and having more services like Cloud run serverless technologies, et cetera.”But at the same time, I think the value of cloud will continue to be providing optionality for developers to have more opinionated services, services like GKE Autopilot, et cetera, that essentially take away the management of infrastructure or nodes that people don't really want to deal with at the end of the day because it's not going to be a competitive differentiator for developers. They want to focus on building software and focusing on keeping their services up and running. And so yeah, I think the future is going to be that, giving developers flexibility and freedom, and still delivering the best-of-breed technology. If it's covering something like security, that's something that should be baked in as much as possible.Corey: You're absolutely right, first off. I'm also looking beyond it where I want to be able to build a website that is effectively Twitter, only for pets—because that is just a harebrained enough idea to probably raise a $20 million seed round these days—and I just want to be able to have the barks—those are like tweets, only surprisingly less offensive and racist—and have them just be stored somewhere, ideally presumably under the hood somewhere, it's going to be on computers, but whether it's in containers, or whether it's serverless, or however is working is the sort of thing that, “Wow, that seems like an awful lot of nonsense that is not central nor core to my business succeeding or failing.” I would say failing, obviously, except you can lose money at scale with the magic of things like SoftBank. Here we are.And as that continues to grow and scale, sure, at some point I'm going to have bespoke enough needs and a large enough scale where I do have to think about those things, but building the MVP just so I can swindle some VCs is not the sort of thing where I should have to go to that depth. There really should be a golden-path guardrail-style thing that I can effectively drag and drop my way into the next big scam. And that is, I think, the missing piece. And I think that we're not quite ready technologically to get there yet, but I can't shake the feeling and the hope that's where technology is going.Stephanie: Yeah. I think it's where technology is heading, but I think part of the equation is the adoption by our industry, right? Industry adoption of cloud services and whether they're ready to adopt services that are that drag-and-drop, as you say. One thing that I've also been talking a lot about is this idea of service-oriented networking where if you have a service or API-driven environment and you simply want to bring it to cloud—almost a plug-and-play there—you don't really want to deal with a lot of the networking infrastructure, and it'd be great to do something like PrivateLink on AWS, or Private Service Connect on Google Cloud.While those conversations are happening with customers, I'm finding that it's like trying to cross the Grand Canyon. Many enterprise customers are like, “That sounds great, but we have a really complex network topology that we've been sitting on for the past 25 years. Do you really expect that we're going to transition over to something like that?” So, I think it's about providing stepping stones for our customers until they can be ready to adopt a new model.Corey: Yeah. And of course, the part that never gets said out loud but is nonetheless true and at least as big of a deal, “And we have a whole team of people who've built their entire identity around that network because that is what they work on, and they have been ignoring cloud forever, and if we just uplift everything into a cloud where you folks handle that, sure, it's better for the business outcome, but where does that leave them?” So, they've been here for 25 years, and they will spend every scrap of political capital they've managed to accumulate to torpedo a cloud migration. So, any FUD they can find, any horse-trading they can do, anything they can do to obstruct the success of a cloud initiative, they're going to do because people are people, and there is no real plan to mitigate that. There's also the fact that unless there's a clear business value story about a feature velocity increase or opening up new markets, there's also not an incentive to do things to save money. That is never going to be the number one priority in almost any case short of financial disaster at a company because everything they're doing is building out increasing revenue, rather than optimizing what they're already doing.So, there's a whole bunch of political challenges. Honestly, moving the computer stuff from on-premises data centers into a cloud provider is the easiest part of a cloud migration compared to all of the people that are involved.Stephanie: Yeah. Yeah, we talked about serverless and all the nice benefits of it, but unless you are more a digitally-born, next-gen developer, it may be a higher burden for you to undertake that migration. That's why we always [laugh] are talking about encouraging people to start with newer surfaces.Corey: Oh, yeah. And that's the trick, too, is if you're trying to learn a new cloud platform these days—first, if you're trying to pick one, I'd be hard-pressed to suggest anything other than Google Cloud, with the possible exception of DigitalOcean, just because the new user experience is so spectacularly good. That was my first real, I guess, part of paying attention to Google Cloud a few years ago, where I was, “All right, I'm going to kick the tires on this and see how terrible this interface is because it's a Google product.” And it was breathtakingly good, which I did not expect. And getting out of the way to empower someone who's new to the platform to do something relatively quickly and straightforwardly is huge. And sure, there's always room to prove, but that is the right area to focus on. It's clear that the right energy was spent in the right places.Stephanie: Yeah. I will say a story that we don't tell quite as well as we should is the One Google story. And I'm not talking about just between Workspace and Google Cloud, but our identity access management and knowing your Google account, which everybody knows. It's not like Microsoft, where you're forced to make an account, or it's not like AWS where you had a billion accounts and you hate them all.Corey: Oh, my God, I dread logging into the AWS console every time because it is such a pain in the ass. I go to cloud.google.com sometimes to check something, it's like, “Oh, right. I have to dig out my credentials.” And, “Where's my YubiKey?” And get it. Like, “Oh. I'm already log—oh. Oh, right. That's right. Google knows how identity works, and they don't actively hate their customers. Okay.” And it's always a breath of fresh air. Though I will say that by far and away, the worst login experience I've seen yet is, of course, Azure.Stephanie: [laugh]. That's exactly right. It's Google account. It's yours. It's personal. It's like an Apple iCloud account. It's one click, you're in, and you have access to all the applications. You know, so it's the same underlying identity structure with Workspace and Gmail, and it's the same org structure, too, across Workspace and Google Cloud. So, it's not just this disingenuous financial bundle between GCP and Workspace; it's really strategic. And it's kind of like the idea of low code or no code. And it looks like that's what the future of cloud will be. It's not just by VMs from us.Corey: Yeah. And there are customers who want to buy VMs and that's great. Speed up what they're doing; don't get in the way of people giving you their money, but if you're starting something net-new, there's probably better ways to do it. So, I want to thank you for taking as much time as you have to wind up going through how you think about, well, the art of storytelling in the world of engineering. If people want to learn more about who you are, what you're up to, and how you approach things, where can they find you?Stephanie: Yeah, so you can head to stephrwong.com where you can see my work and also get in touch with me if you want to collaborate on any content. I'm always, always, always open to that. And my Twitter is @stephr_wong.Corey: And we will, of course, put links to that in the [show notes 00:40:03]. Thank you so much for taking the time to speak with me.Stephanie: Thanks so much.Corey: Stephanie Wong, head of developer engagement at Google Cloud. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice along with an angry comment telling me that the only way to get into tech these days is, in fact, to graduate with a degree from Stanford, and I can take it from you because you work in their admissions office.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

I just interviewed Maxim, a main contributor to SMS Power and someone who's been contributing to the scene for quite a long time. We discussed - as expected - The Sega Master System, as well as other project he's been a part of and plenty of other nerdiness. This is also available as a video here: https://www.retrorgb.com/interview-with-maxim-from-smspower.html SMS Power: https://www.smspower.org/ SMS Power Discord: https://discord.gg/ZEn8QPy Phantasy Star Re-Translation: https://www.smspower.org/Translations/PhantasyStar-SMS-EN Maxim's Github: https://github.com/maxim-zhao/psrp Sonic 1 Editor: https://github.com/maxim-zhao/STH1EDWV SMS Hi-Fi Audio: https://youtu.be/ZX4A2EYAYfU Game de Check!: https://www.smspower.org/Games/GameDeCheckKoutsuuAnzen-SMS Space Harrier BIOS Music: https://youtu.be/R0rgokqjWK4 If you liked this interview, please don't forget to spread the word and subscribe wherever is the most convenient place for you to get podcasts. Also, please consider supporting the channel here: https://www.retrorgb.com/support.html T-Shirts: https://www.retrorgb.com/store.html All equipment used to shoot this video can be found here: https://www.amazon.com/shop/retrorgb --- Support this podcast: https://anchor.fm/retrorgb/support

Yoav Ganbar joins the Jabber crew to discuss Dev FOMO. He leads the panel through a discussion about adopting technologies and knowing about new niches. The panel discusses how to stay on top of the movements in our ecosystem and when we should prioritize other things. Panel Aimee KnightAJ O'NealCharles Max WoodDan ShappirSteve Edwards Guest Yoav Ganbar Sponsors Shortcut (formerly Clubhouse.io)Top End DevsCoaching | Top End Devs Links GitHub: Yoav Ganbar ( hamatoyogi )LinkedIn: Yoav GanbarTwitter: Yoav Ganbar ( @HamatoYogi ) Picks Aimee- What is SSH Tunneling, SSH Reverse Tunneling and SSH Port Forwarding? | TeleportAimee- Why Does Quantitative Easing Benefit the Rich?AJ- GitHub - ulid/spec: The canonical spec for ulidAJ- Jake Archibald on TwitterAJ- GitHub - Creeds of CraftsmanshipCharles- The Search for Planet XCharles- Author | Top End DevsDan- Core Web Vitals Technology ReportDan- The Kite Runner by Khaled HosseiniSteve- The wholly pun bible | InstagramSteve- The wholly pun bible | InstagramYoav- Zack JacksonYoav- Next.js Conf 2021Yoav- daily.dev Special Guest: Yoav Ganbar.

Yoav Ganbar joins the Jabber crew to discuss Dev FOMO. He leads the panel through a discussion about adopting technologies and knowing about new niches. The panel discusses how to stay on top of the movements in our ecosystem and when we should prioritize other things. Panel Aimee KnightAJ O'NealCharles Max WoodDan ShappirSteve Edwards Guest Yoav Ganbar Sponsors Shortcut (formerly Clubhouse.io)Top End DevsCoaching | Top End Devs Links GitHub: Yoav Ganbar ( hamatoyogi )LinkedIn: Yoav GanbarTwitter: Yoav Ganbar ( @HamatoYogi ) Picks Aimee- What is SSH Tunneling, SSH Reverse Tunneling and SSH Port Forwarding? | TeleportAimee- Why Does Quantitative Easing Benefit the Rich?AJ- GitHub - ulid/spec: The canonical spec for ulidAJ- Jake Archibald on TwitterAJ- GitHub - Creeds of CraftsmanshipCharles- The Search for Planet XCharles- Author | Top End DevsDan- Core Web Vitals Technology ReportDan- The Kite Runner by Khaled HosseiniSteve- The wholly pun bible | InstagramSteve- The wholly pun bible | InstagramYoav- Zack JacksonYoav- Next.js Conf 2021Yoav- daily.dev Special Guest: Yoav Ganbar.

Daffy Durairaj is the co-founder of Mango Markets and is currently working full time as a developer in service of the Mango DAO.00:28 - Origin Story04:44 - Seeing the order book10:20 - The idea behind creating Mango Markets15:38 - Going from creating smart contracts to creating Mango17:32 - How big is the DAO?20:01 - The Launch29:15 - VCs and the launch32:43 - Decentralization and getting stuff done34:55 - Will DAOs ever compete with big tech companies?40:43 - What's next for Mango Markets? Transcript:Anatoly (00:09):Hey folks, this is Anatoly and you're listening to the Solana Podcast, and today I have with me Daffy Durairaj, who is the co-founder of Mango Markets, so awesome to have you.Daffy (00:20):It's great to be here.Anatoly (00:22):So origin story, how'd you get into crypto? What made you build Mango Markets?Daffy (00:30):How did I get into crypto? So, I started off really not wanting to get into crypto. I was really interested in algorithm training. I did that in college and did some competitions that I did well in, and I wanted to trade equities, but it turns out if you have not enough money, if you have a few thousand dollars it's just not allowed. You're not allowed to algorithmically trade. There's a patent day trader rule, and I was infuriated and I was just looking around and I found Poloniex where you can do anything you want. The thing that actually hooked me first to Poloniex was the lending market because immediately as soon as I saw an open lending market, I was like, "Oh wow, I have to buy some bitcoin, and I have to lend it out." And, Poloniex was all bitcoin, and then it gradually got into just the meat of it, which was algorithmic trading and everything about crypto seemed exciting, but I actually didn't want to hold bitcoin. Poloniex was all bitcoin, but again, I think the government sort of pushed me in the right direction.I was like, "Okay, I don't want to hold bitcoin, I'll hedge off my risk on BitMEX, but again, not open to US persons, and so I was kind of reluctantly holding bitcoin and thinking, all right, I have a few thousand dollars if things go bad in this whole bitcoin thing. I'll come out okay. I'll get a job or whatever, but just never got a job, just kept holding bitcoin and continue to trade crypto, and I did that for about five years. Then, I wanted to actually start trading on chain because I thought this was probably for a lot of the reasons that you built Solana, the censorship resistance, and the global liquidity of it, and the openness of it, the fact that you're not excluding people that have a few thousand dollars. I wanted to build on chain and I was just not very bullish on a lot of things, so I kept going back to trading, and then I saw Serum DEX, and I was just hooked. I placed a trade and it felt totally natural and normal. It wasn't like $40 and takes 20 seconds and you don't know if it... And, then MetaMask was jammed and you're like, "Oh, but how do I cancel this?" So, that was a long-winded way of saying I was a trader and then I saw Serum DEX and then I had to start building the tools that would make Serum DEX even more fun.Anatoly (02:59):That's awesome. I got into it by trading. Basically, I set up like an Interactive Brokers IRA account, and that let me kind of bypass the rules.Daffy (03:11):Really?Anatoly (03:13):With a very small amount of money. I think they probably closed these loopholes already. I wrote a bunch of stuff on top of their Java STK and started trading there.Daffy (03:22):I remember I actually got started that way too. I did a bunch of stuff for their Java, and we can tell you we're both programmers. We wanted to build this money machine. It's so fascinating, and it's a machine that-Anatoly (03:40):It prints money.Daffy (03:40):It does things and it prints money. What more could you want? So, I got started with Interactive Brokers, but I guess the whole IRA thing... Because I was a college student, and so even talking to an accountant would take a huge dent out of my net worth.Anatoly (04:01):Totally, it's all really not designed for... The whole financial system in trading in the US is designed to funnel retail towards an app like E-Trade or Robinhood, which takes a cut, and then sells that trade to somebody else, who will take a cut, and then 10 other people until it gets an exchange, and that's how everybody's protecting their neck. They're all taking a little slice, and I think what's cool about crypto is that even centralized exchange like FTX is 1,000 times better and less extractive of the users than anything in traditional finance, simply because they can guarantee settlement. Such a very simple thing.Daffy (04:49):You feel it right from the beginning. You go to Poloniex in 2016, and it's like, oh, you have an email, you have deposited bitcoin, and now you're just lending to people. So, just talk about not being extractive. To see the order book through Interactive Brokers or Ameritrade or whatever costs you a lot of money and it costs them a lot of money to provide it, and I don't think I'd ever seen an order book. This was my passion, this is what I love to do, and I've never actually seen it.There's that story of the blind men who are touching this elephant, and so I had kind of figured out maybe what the order book looks like, but then on Poloniex, you go there and you just see the order book and you see all the lights flashing and you're like, "Oh, this is it. This is where the trades are happening." And, that's free, and of course, a big part of Mango Markets as well is you can see the order book. That's it, that is it, there's nothing more, and it's all on chain and all this stuff. So, in terms of not being extractive, it's a really big piece of what motivates people to come in.Anatoly (06:02):I don't know if you ever tried to get data, real data. I wanted timing information when a bid comes in or when an ask comes in versus when it's filled. How do I get access to it? Because when you get data from any of these places, basically it's like a little better than Yahoo Finance, which is like every five minutes they give you a low and a high.Daffy (06:27):I don't know, did you ever succeed at doing that in Interactive Brokers?Anatoly (06:32):No, I recorded some of it, but it just never had that fidelity and it always felt like a gamble. I'll build some models and sometimes stuff would work locally against my simulations, but then whenever I would actually try to run it, I'd see that fills take a little longer than they should and all this stuff really feels like you're not interacting directly with the trading system, that somebody when they see your order they're like, "Well, maybe I'll put my order ahead of yours or do whatever or slow you down a bit." It just sucks.Daffy (07:16):It feels very opaque, it's like a black box, and of course, this is all for people like me who are kind of looking on the outside looking in. So, if I had gotten a job at Citadel or somewhere, then I could probably see what's actually happening, but the fact that the vast majority of people are going to look at it and not really know it's actually happening, not everyone wants to see an order book. That's an important fact, but there are a large number of people who need it to be a little bit transparent to be involved.Anatoly (07:49):What I hate about it is that there's a lot of people that make a lot of money from you not seeing, that they're in the business of information assymetry and fuck them.Daffy (07:58):So, it's not a family friendly podcast, so it's good. I was going to ask that. So, there's a funny story on RuneScape. I don't know if you've ever played RuneScape.Anatoly (08:17):I played Ultima Online, which is I think similar vibes in the early days.Daffy (08:22):Yeah, so on RuneScape, just like on the point of no one being able to see anything, on RuneScape, also they had an order book because that's the most natural thing to do, and I actually had to figure it out from first principles. I would place a trade and I would see that sometimes it would get executed and sometimes it would not get executed, then I realized, okay, if I place a trade for these water runes or something or oak logs or something, and I put the price really high it gets executed at some price that's not the price that I said, and then I was able to form this concept of that's the asking price. I didn't even have the terminology for this, and then I did the same for set the price to zero for a trade and now I found the bid, and now I can make a lot of money actually underbidding the best asker and overbidding the best bid.Anatoly (09:18):So, you're market making.Daffy (09:20):Yeah, so it's funny, I was reminded because you said there's a lot of people who make a lot of money in you not knowing, and I was just minting money. It took me years to accumulate like 1 million gold pieces in RuneScape and then I was able to just 30X it in a month.Anatoly (09:46):Too bad RuneScape is not a crypto currency. Whoever is running RuneScape, you're missing a huge opportunity right now to just go full crypto.Daffy (10:00):There was some talk about some NFT or something on Twitter. Somebody was trying to encourage Jagex, the company, to get involved in crypto, and of course, I tried to signal boost it, but eventually everyone falls in line.Anatoly (10:17):How did you end up with the idea for Mango Markets?Daffy (10:21):So, I have to give credit to dYdX. It was like 2019 and I hadn't really considered that this was possible. I was heads down writing, trading algorithms and trading crypto just kind of holding all of my wealth in bitcoin and I was borderline bitcoin maxi on that, and just seeing dYdX do it in those early days... Now of course, they're way more successful now. Those early days seemed that you could do leverage trading on chain, and they kind of showed it as a proof of concept, which I just kind of started pacing back and forth like, oh my God, this is changing our worldview completely.Ethereum was slow and whatever, so years went by. Actually, maybe just like a year, and then I saw Serum DEX where I felt finally, okay, all the pieces are in play and also I wanted to market make on Serum DEX, but I really need leverage. I don't really need leverage, it just makes market making dramatically more efficient and safer. Leverage is just this tool that people who are involved in the financial plumbing really need, and it wasn't there. I was like, "Okay, this is the time and I have to learn how to code smart contracts," which sounds like a very scary and daunting task, but it was not that bad.Anatoly (11:54):The scary part was that you guys were building on a platform that was really rough around the edges at the time.Daffy (12:02):Well, no one told me that shit was really rough around the edges at the time. That was actually maybe important. You come in and there was nothing to do, this was August of 2020, things were not locked down necessarily here in the United States, but people kind of scattered. No one was hanging out in the major cities, they had kind of went to go live with their families, as did I. I fled San Francisco and went to the rural part of North Carolina. So, there was nothing going on and you just have all the time in the world and bitcoin is doing well, so that's funding you in a way.Bitcoin is this big, or crypto in general, it's all the people who bought it or own some crypto, as long as it's going up, it's kind of funding whatever zany side projects you have in mind. So, this is just a side project. Wouldn't it be cool if I could access this part of the world or this technology? And so, that's why chewing glass... You probably coined that term, I don't know, that's why chewing glass wasn't so hard because that pressure to... You have all the time in the world basically.Anatoly (13:30):Basically, COVID and lockdowns were so boring that chewing glass to learn how to code smart contracts with Solana was like a reprieve from the boredom.Daffy (13:45):And, I've heard you kind of say, okay, a bear market is when everyone is coding. To give the opposite perspective, I feel like a bull market, unlike much more chill, oh yeah, nothing really matters. Crypto is going up, it doesn't matter what I do. The rent is going to be paid for, everything is going to be fine, might as well engage in high variance new ideas, new projects. In a bear market, I'm very I got to grind, I got to squeeze out a couple of more bips out of this trading algorithm because I got to pay rent. So, that's the bullish case on bull markets.Anatoly (14:30):That you can try something crazy. That is the point where people enter this space is in a bull market. It's that they kind of start coming in droves because they're like, "Everything is crazy and I can also be part of the party." But, it's hard as a founder to stay focused because you are in that high variance, high risk taking kind of mindset.Daffy (14:58):There's a trade off of during a bull market there's a lot of things looking for your attention, and a bear market is very calm, or it can be. If you built up a lot of liabilities during the bull market, now you have to stay afloat during the bear market. Maybe it's calm in the external world, but internally it's not calm. You're like, "I got to do X, Y, and Z today every day." There's that natural pressure.Anatoly (15:32):So, you decided to learn coding on smart contracts on Solana. How did you end up going from there into Mango?Daffy (15:39):Initially, it was called Leverum. Not it, there was just an idea and there was a command line tool where you could... The YouTube video might still be out there, and Max was out there somewhere on the internet and he saw it and he thought it was a great idea. And so, he reached out to me and we did some other things like speculative about a prediction market, and then we were like, "Okay, no one is going to build margin trading." A lot of people are saying it, but it doesn't look like if we just wait it's just going to happen in the next couple of weeks or something. It's probably we just have to build it.Not we just have to, but we totally should. This is clearly a very important piece of the Solana ecosystem. So, we started building it. Mango was just we were thinking alliteration is good. Everybody loves mangoes, it's a fruit that I have never heard of anybody who doesn't like mangoes. It's probably the high sugar content and Mango Margin was the idea, but then we got the domain Mango.Markets. It's kind of evolved now. When you're starting off with something, you have kind of a narrow scope. You're like, "I just want to be able to borrow money." And now, there's this Mango DAO and people are talking about NFTs and drones. I'm talking about drones. I don't know if anybody else is, but it's just gone way higher and now I'm like, "I'm a humble servant of the Mango DAO." And, that's totally a normal thing to say.Anatoly (17:27):How big is the DAO?Daffy (17:28):How big is the DAO? That's a good question.Anatoly (17:30):In humansDaffy (17:31):That's like a philosophical question. In human terms, wow, again, even still a philosophical question. So, I think if you go to MNGO token, if you go to the Solana explorer and just type in mango or MNG or something, you can probably... I don't know if they have a list of unique token addresses, so in some sense that's the DAO, but in terms of the number of people who actively post on the forums and make proposals, that's much smaller. I'm guessing there's thousands of people who have votes, but the number of people who make proposals and add meaningful commentary on the forums is maybe 20 people, and it's expanding pretty quickly.I always see new people coming in. There's also not just people, there's the wealth of the DAO and the cultural reach of the DAO, the spiritual significance of the DAO, all of those seem like size if you ask how big is the DAO. You interviewed Balaji Srinivasan, and there's this idea that he had on Twitter that was like a DAO should buy land in Wyoming and send a drone to circle it and this is kind of like a moon landing sort of kind of thing or some kind of significant breakthrough where the DAO is controlling physical objects in the real world. So, this is very exciting to me, but it has nothing to do with margin trading, it's just something exciting that maybe in a bear market, I don't know, I'll push to get this done.Anatoly (19:23):Do you want the control to happen on chain?Daffy (19:25):Yeah, I think that's necessary. Maybe not the total control, but some kind of signal that distance... So, you can kind of think of Congress authorizes a certain thing and then the executive branch does it. If we could make that link be as automated as possible, I think there's something useful there, at the very least something exciting and interesting, kind of like the moon landing where maybe there wasn't anything useful, but it was inspiring for sure.Anatoly (20:02):So, the DAO, if you guys decided you want to do something with leverage and lending, and how you guys launched was really unique. I don't even know if people did this in Ethereum. To me, this is the first time anyone's kind of done this style of launch. Can you talk about the design and how you guys thought of it and what let you make those choices?Daffy (20:25):So, people early to Solana may be familiar with the Mango market caps and how that went, which somewhat argues the first NFT on Solana, and that was done pretty much sort of like how NFTs are typically done where there's a mad rush to grab the caps as soon as possible and the price is swinging wildly and there's a lot of people. Now, I think we put that together as an April Fool's kind of thing, very quickly, and so it was great for what it did, but the experience from that was, okay, there's going to be a lot of angry people. If you do it in this way where the DAO is raising funds, and this is the inception of the DAO, the DAO is raising funds for insurance fund, you probably don't want it to just be distributed to the people who were the fastest to click.And, that was the idea. We probably don't want that. It doesn't seem useful, it seems like a lot of angry people, and a lot of frustrated people. So okay, so you take out the time component, you take out the luck component, and then you're left with you kind of have this sort of auction that lasts 24 hours, but then what if X somebody comes at the last moment and dumps in a huge amount of money and raises the price for everyone? Everyone gets the same price. So, our design was we'll have a withdrawal period or a grace period at the end, the remaining 24 hours where if you kind of don't like the price, you can bail out. It had some flaws and I think we knew about those flaws from the beginning. We were like, "Okay, we just pushed to this game of chicken to a later point where someone can put in a lot of money to scare other people away and then they pull out at the last second. And that did happen, but it's not clear if that was net positive or net negative.Anatoly (22:28):And kind of in summary, there's this 24 hour period where people deposit funds in for a fixed supply of tokens.Daffy (22:36):Correct.Anatoly (22:37):And, then the period is over, and now everybody knows what the total amount in the pot is for the token and there's kind of this price that's created and then if you don't like the price, you can withdraw the entire bid or as much as you want. You can only reduce your bid.Daffy (22:54):Correct.Anatoly (22:54):But, you don't need to withdraw the entire bid, you can just reduce it.Daffy (22:57):Correct, yep.Anatoly (22:58):So, then that pushes the average price down at the same time, so for every dollar you take out, you kind of get a better price per token.Daffy (23:07):And, you see the price ticking up during the first 24 hours as more and more people are putting money in and then the price ticking down over the next 24 hours.Anatoly (23:19):I'm a huge fan of this setup because it creates a lot of... There was news, you guys made the news because it was almost half of all of USDC that was minted on Solana ended up in that smart contract. It was like 45% of it.Daffy (23:43):I remember actually because we saw the USDC on Solana was 700 million the days before and then it had climbed up to like 1.1 billion or I don't know what the number was at the end, and there was 500 million in the contract at the end of the first 24 hours. That was not the intention.Anatoly (24:05):It's like it was minted.Daffy (24:05):And honestly, I think you could appreciate it better from the outside than from my point of view for sure, and of course, I also could appreciate it better from the time distance, but that was not expected. We kind of knew that there would be a lot of money placed in the beginning and then money would go down. That was in all the documentation that we wrote, and that was expected and we had all these dev calls where everyone was always talking about it, and I was like, "Okay, come on. Literally, there isn't that much USDC in Solana." So, it can't be that bad, but of course, I underrated the possibility that someone could just mint a whole bunch of new USDC and bring it in from somewhere else. It made the news and a couple of other projects did the same thing, and I wonder if maybe it's a one time kind of thing. The game only works once. You can't expect to scare people every time or use the tactic every time.Anatoly (25:10):Maybe, I think a lot to be said, but there was no other way to go. Mango took it all, so there was no private round, they were never listed anywhere. This was really the only way to get it, and the anticipation of a project that was awesome, and from every other perspective is... What I always tell founders is that you should always raise the least amount for the highest price. The VCs kind of have more power than you usually because they have more information, they look at many deals, people come to them, they have the money, but it's sometimes the founders have this asymmetry where they're the only ones without equity. They're the only ones without tokens and that moment is if you can get everybody at the same time to compete for that thing, then you've kind of created the symmetry there and you maximize the capital raise for the DAO, for the project, for the community, and therefore that actually is a good thing. You have more resources to build a vision.Daffy (26:16):Although, I'll clarify, I think the DAO is still handing out a lot of tokens, so there's still a lot of ways to acquire Mango tokens, and that was kind of the inception for the insurance fund. The DAO has been paying people out of the insurance fund, and so it's been useful, but there's still more tokens to be had. There is a slight private rounds and I totally understand why people do them, but like I said earlier, if you are in crypto for a while, and this the cool thing about bull markets, I don't actually need money, I just need to pay rent and bitcoin has gone up 50%, so I'm solid.And, no one was paid anything. There was just Mango tokens that were given to people and they were told the DAO values your contribution or this is the inception of the DAO, and everyone worked to build this thing. People worked without even the Mango tokens and sort of the tokens were given after the fact. I think it's a valuable way to build crypto projects actually.Anatoly (27:30):I want more teams to try to totally from genesis this DAO first approach, but it's really tough because you guys had such a principled view on how things should be done and there's a lot of people out there that are offering money for that one thing. How did you guys have the discipline to just go stick with this?Daffy (27:54):We had a lot of discussions about all these things. We talked to VCs and we still do and we like all VCs actually. So, I think Satoshi, I'm not trying to draw a comparison to us to Satoshi or anything, but there is this beauty in that story and I think there's a lot, maybe even the majority of bitcoin's value at least to me... To me, I just love the narrative. I love the story of Satoshi, the pseudonymous founder who is one of the richest people on the planet right now. Obviously, they're in a no VCs. This person wanted to not make a big fuss. It was kind of like this clockmaker prophetic person who just came and then left, built this thing and then left, and that's such an amazing story.There are these long, long payoffs. Maybe they take a while, but they definitely do pay off that if you're not hurting for rent, again, I was in a position, all the other Mango devs were in this position as well where it was a bull market, we're not getting eviction notices or something, we could kind of float the boat for a while. Just consider the longterm payoffs, consider the five year payoffs. Stories are amazing.Anatoly (29:17):The weirdest thing is that every good VC will tell you that you should maximize for the highest return. Don't worry about the middle exit, or don't compromise. Actually, imagine you're taking over the world, what are the steps to get there? And, the risk don't matter. Actually maximize for the high and this is the irony here is that I think this kind of fair launch, most distribution will probably result in overall longterm, better, and higher returns, but the risks that I always find is that humans are hard to organize and at the same time, cryptography is this new tool for organization.It is what allows us to massively scale agreement and complex problems, really, really complicated problems. We can just click a button and vote and agree on that one and you know. You know that the decision was made, but I'm curious, do you see tension between the decentralization, kind of the disorganization of the DAO and getting shit done? I've got to build stuff.Daffy (30:34):No, 100% actually, on a daily basis actually. There was a podcast with the guy on Twitter that goes by Austerity Sucks and this was back in April. We talked about this and he brought up a similar point and he was, "Yeah, this DAO thing, it's all a fine and dandy idea, but do you think this will work?" And I, to be honest with you, am skeptical, however it is always felt to me sort of a high variance idea, kind of like if you were in the 16th century Netherlands or the 17th century Netherlands and you were like, "Okay, we've got to get spices from India. How do we do it?"And, you come up with a joint stock corporation and then the join stock corporation is everywhere and I don't think anyone has really figured out how to do DAOs well or what's the right mix, how do we communicate, how do we coordinate, all those things. I don't think anyone's quite figured it out yet. No one had figured it out like six months ago. I still don't think we have figured it out, but if it works, the payoff is enormous. There is global coordination, there isn't a jurisdiction. I imagine the DAO is controlling drones one day. It could be wild. So, even taking into account all of my skepticism, I was still like, "Okay, we should do the DAO idea." Anyway, not just me, Max is totally on board with this and Tyler and all the other people who kind of built Mango Markets. But on a day to day basis, as of October 2021, now I'm thinking, okay, maybe what we need to do is have small teams that build things and then pitch it in front of the DAO and get compensation. So, the DAO is kind of the government and it subcontracts out to people. Maybe not like direct democracy rules everything and we'll try that out and if that doesn't work, we'll try something else out, but try new stuff out quickly.Anatoly (32:45):That's awesome. This is actually a really good strategy to incentivize product development. Building an MVP, which means you're the PM, and the implementer, the dev, and you go do all the work and here's your management. It's all done, just give me money.Daffy (33:09):And, there's some maintenance tasks, so it's not purely new products, so I'm thinking Mango V4, but also in the meantime, there are all these nodes that need to be paid for.Anatoly (33:24):I think you guys will need to split. We called it KTLO, keeping the lights on work. You for six months, you're on KTLO duty, and you get paid a salary effectively, and you just got to keep the lights on, but then some other folks are like, "Go build something that you can propose to the DAO and the DAO will fund it."Daffy (33:49):I think that's basically what we have coalesced on is that, well, some people should be doing KTLO and other people should be doing new things, building the new product, and it takes kind of the risk out. The DAO doesn't have to pay for whatever stuff that I produce for Mango V4, but we both have some kind of incentive to be honest about it. If it's clearly a huge improvement or even a very substantial improvement, DAO should pay me something because if the DAO doesn't, then you can expect future builders to not go for it. And, we have these discussions on the forums.People make good arguments like this. I think the average IQ in the Mango Markets forums is very high. I think probably higher than most legislative bodies. I'm just going to go out on a limb and just say that. Not ours of course, ours is obviously very high IQ, smart people in our government, but you know.Anatoly (34:55):Do you believe five years there's going to be a 30,000 person DAO. Imagine a tech company, 30,000 engineers, or 30,000 people, they got product managers, teams, layers of bullshit. Is there going to be a DAO that's competing with a big tech company?Daffy (35:16):It's legitimately really hard to figure out how this might look. The reason why I hesitate so much with the question of a 30,000 person DAO is I'm not sure it'll look exactly like a corporation that we can say, okay, these are these 30,000 people. You might never be able to figure out who is part of the DAO and maybe that's one of the benefits of the DAO. If I asked you, how many people are part of Solana, not Solana Labs, but Solana the community? It's a little bit difficult to even answer, lots of people, various levels of involvement, and financial. Some people have a lot of financial stake until you don't, but some people have a lot of financial stake and no involvement at all. It's wild all over the place. Does Bitcoin look like a country or a corporation? I can even point my finger on what it is.Anatoly (36:20):So, even LINE had a battle that had 8,000 people all coordinating over something and I think they have corporations within that game that are maybe probably span up to 1,000 I'd imagine. So, that's people organizing using tech for a common goal without a job, without a structure that you normally have at a company. Linux was built by people organizing online. I think as soon as you have something to lose and in Linux and even LINE you start building up a virtual token, your reputation is a contributor to this thing and becomes a thing that we don't normally think of as valuable in a monetary way, but it's valuable to that person, but I definitely care about my ability to continue contributing to an open source project. So, where tokens I think can get there is if there is something of value being created by the community, some common goal that everyone is working on and that token is in the middle of it and is uniting and organizing it. I think that could scale as large as a corporation.Daffy (37:45):No, I agree with you. I just think it'll always be a little bit hard to figure out how many or who is involved, just by the nature of it. I just think it'll be always a little bit hard to figure out, but will 30,000 people be building on Mango or some DAO? You already know the numbers better, but we might even be approaching that with Solana. So, I'm not part of Solana Labs or affiliated with Solana in any way, but building on Solana, and also I have a financial incentive too, but also I have a reputation incentive and it feel like I'm part of the Solana corps or whatever it is, but I don't know what it is. It doesn't even exist. It's not even a DAO. There isn't even a DAO there.Anatoly (38:39):Oddly enough, I feel the same way about Eth and bitcoin even is that we're competing with them.Daffy (38:50):But, it all feels like we're actually kind of a part of the same team and-Anatoly (38:54):This is the weird part that I think is going to be really interesting how it plays out because I don't think it's obvious to anybody what is crypto. Is it the token? Is it the coin? Is it the network? Is it the cryptography itself?Daffy (39:10):It's not the cryptography itself, so we can strike that one out.Anatoly (39:14):Are you so sure? I think it's honestly the power that a person has to be able to make these very concrete statements that are unbreakable no matter how... That's the math. The math behind it is what allows them to do them.Daffy (39:36):I don't totally know the cryptography itself. I know basic 101 number theory stuff, but I remember going through my first programming class and coming up feeling just very powerful. I'd write stuff down and then it happens. Kind of like a king, actually, more powerful than a king in a lot of ways because I was writing these training algorithms and it was happening around the world in ways that probably a medieval king couldn't imagine and crypto brings that to finance where things of actual value can be moved.Mango Markets exists and you can go there and place a trade right now, but it was just somebody who wrote it. I was involved based on you can see the GitHub contributions, but it was just people who wrote it and that's probably... We can maybe chalk that up to the cryptography.Anatoly (40:43):So, what's next for you guys?Daffy (40:46):There's drones on the horizon. Yes, sometime in the future, but we have to do a lot of the nitty-gritty, roll up your sleeves kind of work. On Solana so far, there isn't... Maybe a lot of projects are struggling with this, indexing all the data and providing it for people in a usable way because there's just so many transactions. It turns out if transaction fees are really low, people just make a lot of transactions and they don't think about it.And so, gathering it up and displaying it in a useful format to people, that's a very immediate term and then slightly medium term is sort of becoming the place where everyone does leverage trading and does borrow and lending, all the crypto natives. And then of course in the longterm, I would say it's somebody like my mom should be able to store her money in Mango Markets and not think twice about it. It's not a good idea right now I wouldn't say, but that's the goal. That involves a lot more social things than just technological things. That's get it to a level where she can do it safely and feel comfortable and manage her keys, or even if she's not managing her keys, have a solution for how the keys might be managed, that she's not falling for scams, and that's I would say my longterm goal.Anatoly (42:09):That's awesome, man. On that note, man, really awesome to have you on the podcast. Great conversation. I'm always excited about what you guys are doing and how the community is building this ecosystem of its own, so really amazing. It's serendipity that you guys started going on Solana, just really lucky to have folks like you in the ecosystem.Daffy (42:35):Thanks a lot. It means a lot. This was really fun.

Watch the live stream: Watch on YouTube About the show Sponsored by Shortcut - Get started at shortcut.com/pythonbytes Special guest: Chris Patti Brian #1: Using cog to update --help in a Markdown README file Simon Willison I've wanted to have a use case for Ned Batchelder's cog Cog is a utility that looks for specially blocks [[[cog some code ]]] and [[[end]]] These block can be in comments, [HTML_REMOVED] for markdown. When you run cog on a file, it runs the “some code” and puts the output after the middle ]]] and before the [[[end]]]. Simon has come up with an excellent use, running --help and capturing the output for a README.md file for a CLI project. He even wrote a test, pytest of course, to check if the README.md needs updated. Michael #2: An oral history of Bank Python Bank Python implementations are effectively proprietary forks of the entire Python ecosystem which are in use at many (but not all) of the biggest investment banks. The first thing to know about Minerva is that it is built on a global database of Python objects. Barbara is a simple key value store with a hierarchical key space. It's brutally simple: made just from pickle and zip. Applications also commonly store their internal state in Barbara - writing dataclasses straight in and out with only very simple locking and transactions (if any). There is no filesystem available to Minerva scripts and the little bits of data that scripts pick up has to be put into Barbara. Barbara also has some "overlay" features: # connect to multiple rings: keys are 'overlaid' in order of # the provided ring names db = barbara.open("middleoffice;ficc;default") # get /Etc/Something from the 'middleoffice' ring if it exists there, # otherwise try 'ficc' and finally the default ring some_obj = db["/Etc/Something"] Lots of info about modeling with classes (instruments, books, etc) If you understand excel you will be starting to recognize similarities. In Excel, spreadsheets cells are also updated based on their dependencies, also as a directed acyclic graph. Dagger allows people to put their Excel-style modelling calculations into Python, write tests for them, control their versioning without having to mess around with files like CDS-OF-CDS EURO DESK 20180103 Final (final) (2).xlsx. Dagger is a key technology to get financial models out of Excel, into a programming language and under tests and version control. Time to drop a bit of a bombshell: the source code is in Barbara too, not on disk. Remain composed. It's kept in a special Barbara ring called sourcecode. Interesting table structures, like Pandas, but closer to a DB (MnTable) Over time the divergence between Bank Python and Open Source Python grows. Technology churns on both sides, much faster outside than in of course, but they do not get closer. Minerva has its own IDE - no other IDEs work if you keep your source files in a giant global database. What I can't understand is why it contains its own web framework. Investment banks have a one-way approach to open source software: (some of) it can come in, but none of it can go out BTW, I “read” this with naturalreaders app Chris #3: Pyxel Pyxel is a ‘retro gaming console' written in Python! This might seem old and un-shiny, but the restrictions imposed by the environment gift simplicity Vastly decreased learning time and effort compared to something like Unity or even Pygame Straight forward simple commands, just like it was for micro-computers in the 80s cls(), line(), rect(), circ() etc. Pyxel is somewhat more Python and less console than others like PICO-8 or TIC-80 but this is a feature! Use your regular development environment to build. Brian #4: How to Ditch Codecov for Python Projects Hynek Schlawack Codecov is a third party service that checks your coverage output and fails a build if coverage dropped. It's not without issues. Hynek is using coverage.py --fail-under flag in place of this in GitHub actions. It's not as simple as just adding a flag if you are using --parallel to combine coverage for multiple test runs into one report. Hynek is utilizing the coverage output as an artifact for each test, then pulling them all together in a coverage stage combine and check coverage. He provides the snippet of GH Action, and even links to a working workflow file using this process. Nice! Michael #5: tiptop (like glances) via Zach Villers tiptop is a command-line system monitoring tool in the spirit of top. It displays various interesting system stats, graphs it, and works on all operating systems. Really nice visualization for your servers Good candidate for pipx install tiptop Chris #6: pyc64 A Commodore 64 emulator written in pure Python! Not 100% complete - screen drawing is PETSCII character mode only This still allows for a lot of interesting apps & exploration Actual machine emulation using py65 - a pure Python 6502 chip emulator! You can pop to a Python REPL from inside the emulator and examine data structures like memory, registers, etc! An incredible example of what Python is capable of 0.6 Mhz with CPython and over 2Mhz with pypy! Extras Michael: Michael's FlaskCon 2021 HTMX Talk Chris: Amazon OpsTech IT is hiring! (If deemed appropriate :) Joke: I hate how the screens get bright so early this time of year

In this episode, Damir and I take a deep dive on API design.Damir.Svrtan.meDamir Svrtan on TwitterDamir Svrtan on GitHub

Every Monday at 3:30PM UTC/11:30AM EST Horizen gives a LIVE update on Discord including a Q&A session with the community.  Weekly Insider detailed chat channel in Discord: https://horizen.io/invite/discord November 22, 2021, Weekly team updates from the following divisions: * Engineering * Node network * Product/UX * Customer service/Helpdesk * Legal * Business development * Marketing * Team Lead closing thoughts * 5 mins Q&A Horizen bug bounty program on HackerOne will be open to public from November 23rd ZEN 3.0.0 (Zendoo) released on mainnet! ZEN 2.0.24 deprecation: December 1 ZEN 3.0.0 (Zendoo) hard fork: December 1 (deprecation +24 blocks) Horizen is an exciting cryptocurrency with a solid technological foundation, unique capabilities, an active and capable team, ongoing funding for improvements, and a large, positive, encouraging community. ZEN is available and trading now on Bittrex, Binance, Coinbase, and more, has wallets available that implement advanced private transaction and messaging capability and has a strong roadmap. The goal of Horizen is to create a usable private cryptocurrency operating on a resilient system for people and businesses worldwide, enabling the daily use of private transactions, messaging, and publishing everywhere, all the time. Store: https://store.horizen.io Merchant Directory: https://horizen.io/merchants Horizen Nodes: https://horizen.io/zennodes Horizen Academy: https://academy.horizen.io/ Reference: Horizen Website – https://www.horizen.io Horizen Blog – https://blog.horizen.io Horizen Discord - https://horizen.io/invite/discord Horizen Github – https://github.com/HorizenOfficial Horizen Forum – https://forum.horizen.io/ Horizen Twitter – https://twitter.com/horizenglobal Horizen Telegram – https://horizen.io/invite/telegram Horizen on Bitcointalk – https://goo.gl/5vicqP Horizen YouTube Channel – https://www.youtube.com/c/Horizen/ Horizen Facebook Page – https://www.facebook.com/horizenglobal/ Horizen on Instagram - https://instagram.com/horizenglobal Horizen Blog on Medium – https://medium.com/@horizen Buy or Sell Horizen Horizen on CoinMarketCap – https://bit.ly/ZENCoinMarketCap Horizen on CoinGecko – https://bit.ly/ZENCoinGecko                                      

Food is the very nourishment of life. Climate change, population growth and population density has come to challenge the way we feed ourselves. Let's look at some factors that are affecting the way we grow food:World's population is in more urbanized areas - 60% of the population lives in cities. Farms Waste Much of World's Water - On average, farms around the world account for 70% of all water that is consumed annually. Demand for locally grown food in urban areas is rising - For environmental reasons, as well as efficiency and ability to have produce that is often damaged during transport (e.g. berries)One of the emerging solutions is vertical farming and its different techniques. In this episode, we're going to talk about how it can be viable solution for highly urbanized area and in todays shift to sustainable food growth. The very way we make our food is changing.. what will the farms of the future look like? Check this episode out to find out! Materials for Content:Vertical farms are growing more and more vegetables in urban areasVertical Farming TechniquesAerofarms ImpactVertical Farms fill a Tall OrderBowery - Why Vertical FarmingSoundclips:Vertical Farming as a solution for Food of the Future - ViceThe rise of vertical farming - VPRO DOKHow Aerofarms' vertical farms grow produce - CBS MorningsFarms Waste Much of World's WaterEach degree of temperature rise, 10% of existing agricultural land will be lostHow much your food has travelled to get to your plateSupport the show (https://www.thc-pod.com/)

.NET Conf is over and we get hands on with live .NET 6 bits and get excited about all sorts of new features! We cover all sorts of goodies in this lighting topic podcast. Follow Us Frank: Twitter, Blog, GitHub James: Twitter, Blog, GitHub Merge Conflict: Twitter, Facebook, Website, Chat on Discord Music : Amethyst Seer - Citrine by Adventureface ⭐⭐ Review Us (https://itunes.apple.com/us/podcast/merge-conflict/id1133064277?mt=2&ls=1) ⭐⭐ Machine transcription available on http://mergeconflict.fm

Privacidad máxima con DuckDuckGo / Winamp vuelve / MediTek 9000 impacta / Marco legal para emuladores / Shinkansen operado por ordenador / Autofiltrado de cookies en Git / RPi con 48 TB Patrocinador: La gala de premios Huawei Next Image son el mayor concurso de fotografía móvil https://consumer.huawei.com/es/community/next-image/ del mundo. Más de dos millones de personas de todo el mundo han participado, y este año viene con más premios que nunca. — Las inscripciones están abiertas https://consumer.huawei.com/es/community/next-image/ hasta el 30 de noviembre, y puedes participar en múltiples categorías. Si algún lector gana que lo comparta conmigo, ¿eh? Privacidad máxima con DuckDuckGo / Winamp vuelve / MediTek 9000 impacta / Marco legal para emuladores / Shinkansen operado por ordenador / Autofiltrado de cookies en Git / RPi con 48 TB

GitHub link here: https://github.com/tp02ga/FunWithStreams In this episode we'll talk about: What are streams and why you should care about them Comparing a simple Stream example to a Looping example Intermediate vs Terminal operations

Today I want to discuss the Deprecate dynamic properties RFC in PHP 8 and give you my view on breaking changes in software development. Changelog New YT short PHP Union Data types You can watch me struggle to get the new PHP course that I'm building to level 9 of PHPStan I did that live on Tuesday. Over on Twitch I connected Googles YouTube API to https://howtocodewell.fm I've started to use the new GitHub projects beta tool which lets you create a project that can have tasks from multiple repos which is proving very handy. I've started to look into the blockchain and how it works. I can't promise that I will do a course or a tutorial on that but I'm trying to wrap my brain around how it all works I have my new M1 Max MacBook Pro. I haven't had much chance using it as I've been so busy of late. Get in contact and ask me a question My web development courses ➡️ Learn How to build a JavaScript Tip Calculator ➡️ Learn JavaScript arrays ➡️ Learn PHP arrays ➡️ Learn Python ✉️ Get my weekly newsletter ⏰ My current live coding schedule (Times are GMT) Tuesdays 18:00 = Live Podcast YouTube Thursdays 20:00 = Live Podcast YouTube Saturday 14:30 - Live coding on Twitch

In this episode, we talk to Dan Edlebeck, cofounder of Exidio. Building a decentralized VPN solution as part of the Sentinel ecosystem. Exidio is building decentralized and distributed networking solutions and contributing to the Cosmos open-source community by creating a resilient and robust decentralized VPN and allowing you to create your own decentralized and distributed VPN network. The Sentinel Network hosts open-source distributed and decentralized applications that provide users with assurance that their session information is not being logged, their communication is not being stored, and that not even the creator of the application can view any of their data. Sentinel Network is a network layer that enables a true p2p and decentralized applications and resources marketplace. Sentinel enables anyone to create Public and Private networks that provide access to both free and incentivized, and also payment method agnostic (pre-paid/escrow/post-paid) services (dApps) & distributed resources, enabling its clients to become both producers and consumers in the network. Dan's Twitter (https://twitter.com/deeeedle) We spoke to Dan about dVPN, and: What is Exidio and Sentinel? How do decentralized VPNs work? The DVPN token IBC Liquidity in a project PR and marketing in a project Memology and the BlueFrenGang Content: is it good or bad? Web3 and frontend VPN as a neutral technology Can web3 change the world? Who can be the face of a crypto brand? Daily motivational resources The projects and people that have been mentioned in this episode: | Tendermint (https://tendermint.com/) | Cosmos (https://cosmos.network/) | Exidio (https://exidio.co/) | Sentinel (https://www.citizencosmos.space/exidio) | IBC (https://github.com/cosmos/ibc) | Ethereum (https://www.ethereum.org/) | BlueFrenGang (https://twitter.com/hashtag/bluefrengang?src=hashtag_click) | Sentinel's Telegram (https://t.me/sentinel_co) | Atlas Shrugged by Ayn Rand (https://en.wikipedia.org/wiki/Atlas_Shrugged) | Sentinel Ambassador Program (https://medium.com/sentinel/introducing-the-sentinel-ambassador-program-f4b063a59d8e) | If you like what we do at Citizen Cosmos: Stake with Citizen Cosmos validator (https://www.citizencosmos.space/staking) Help support the project via Gitcoin Grants (https://gitcoin.co/grants/1113/citizen-cosmos-podcast) Listen to the YouTube version (https://www.youtube.com/watch?v=5hJ3Ycx8huo) Read our blog (https://citizen-cosmos.github.io/blog/) Check out our GitHub (https://github.com/citizen-cosmos/Citizen-Cosmos) Join our Telegram (https://t.me/citizen_cosmos) Follow us on Twitter (https://twitter.com/cosmos_voice) Sign up to the RSS feed (https://www.citizencosmos.space/rss)

About Micheal BenedictMicheal Benedict leads Engineering Productivity at Pinterest. He and his team focus on developer experience, building tools and platforms for over a thousand engineers to effectively code, build, deploy and operate workloads on the cloud. Mr. Benedict has also built Infrastructure and Cloud Governance programs at Pinterest and previously, at Twitter -- focussed on managing cloud vendor relationships, infrastructure budget management, cloud migration, capacity forecasting and planning and cloud cost attribution (chargeback). Links: Pinterest: https://www.pinterest.com Twitter: https://twitter.com/micheal LinkedIn: https://www.linkedin.com/in/michealb/ TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: You know how git works right?Announcer: Sorta, kinda, not really Please ask someone else!Corey: Thats all of us. Git is how we build things, and Netlify is one of the best way I've found to build those things quickly for the web. Netlify's git based workflows mean you don't have to play slap and tickle with integrating arcane non-sense and web hooks, which are themselves about as well understood as git. Give them a try and see what folks ranging from my fake Twitter for pets startup, to global fortune 2000 companies are raving about. If you end up talking to them, because you don't have to, they get why self service is important—but if you do, be sure to tell them that I sent you and watch all of the blood drain from their faces instantly. You can find them in the AWS marketplace or at www.netlify.com. N-E-T-L-I-F-Y.comCorey: This episode is sponsored in part by our friends at Vultr. Spelled V-U-L-T-R because they're all about helping save money, including on things like, you know, vowels. So, what they do is they are a cloud provider that provides surprisingly high performance cloud compute at a price that—while sure they claim its better than AWS pricing—and when they say that they mean it is less money. Sure, I don't dispute that but what I find interesting is that it's predictable. They tell you in advance on a monthly basis what it's going to going to cost. They have a bunch of advanced networking features. They have nineteen global locations and scale things elastically. Not to be confused with openly, because apparently elastic and open can mean the same thing sometimes. They have had over a million users. Deployments take less that sixty seconds across twelve pre-selected operating systems. Or, if you're one of those nutters like me, you can bring your own ISO and install basically any operating system you want. Starting with pricing as low as $2.50 a month for Vultr cloud compute they have plans for developers and businesses of all sizes, except maybe Amazon, who stubbornly insists on having something to scale all on their own. Try Vultr today for free by visiting: vultr.com/screaming, and you'll receive a $100 in credit. Thats v-u-l-t-r.com slash screaming.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. Sometimes when I have conversations with guests here, we run long. Really long. And then we wind up deciding it was such a good conversation, and there's still so much more to say that we schedule a follow-up, and that's what happened today. Please welcome back Micheal Benedict, who is, as of the last time we spoke and presumably still now, the head of engineering productivity at Pinterest. Micheal, how are you?Micheal: I'm doing great, and thanks for that introduction, Corey. Thankfully, yes, I am still the head of engineering productivity; I'm really glad to speak more about it today.Corey: The last time that we spoke, we went up one side and down the other of large-scale environments running on AWS and billing aspects thereof, et cetera, et cetera. I want to stay away from that this time and instead focus on the rest of engineering productivity, which is always an interesting and possibly loaded term. So, what is productivity engineering? It sounds almost like it's an internal dev tools team, or is it something more?Micheal: Well, thanks for asking because I get this question asked a lot of times. So, for one, our primary job is to enable every developer, at least at our company, to do their best work. And we want to do this by providing them a fast, safe, and a reliable path to take any idea into production without ever worrying about the infrastructure. As you clearly know, learning anything about how AWS works—or any public cloud provider works—is a ton of investment, and we do want our product engineers, our mobile engineers, and all the other folks to be focused on delivering amazing experiences to our Pinners. So, we could be doing some of the hard work in providing those abstractions for them in such way, and taking away the pain of managing infrastructure.Corey: The challenge, of course, that I've seen is that a lot of companies take the approach of, “Ah. We're going to make AWS available to all of our engineers in it's raw, unfiltered form.” And that lasts until the first bill shows up. And then it's, “Okay. We're going to start building some guardrails around that.” Which makes a lot of sense. There then tends to be a move towards internal platforms that effectively wrap cloud services.And for a while now, I've been generally down on the concept and publicly so in the general sense. That said, what I say that applies as a best practice or something that most people should consider does tend to fall apart when we talk about specific use cases. You folks are an extremely large environment; how do you view it? First off, do you do internal platforms like that? And secondly, would you recommend that other companies do the same thing?Micheal: I think that's such a great question because every company evolves with its own pace of development. And I wouldn't say Pinterest by itself had a developer productivity or an engineering productivity organization from the get-go. I think this happens when you start realizing that your core engineers who are working on product are now spending a certain fraction of time—which starts ballooning pretty fast—in managing the underlying systems and the infrastructure. And at that point in time, it's probably a good question to ask, how can I reduce the friction in those people's lives such that they could be focused more on the product. And, kind of, centralize or provide some sort of common abstractions through a central team which can take away all that pain.So, that is generally a good guiding principle to think about when your engineers are spending at least 30% of their time on operating the systems rather than building capabilities, that's probably a good time to revisit and see whether a central team would make sense to take away some of that. And just simple examples, right? This includes upgrading OS on your EC2 machines, or just trying to make sure you're patching all the right versions on your next big Kubernetes cluster you're running for serving x number of users. The moment you start seeing that, you want to start thinking about, if there is a central team who could take away that pain, what are the things they could be investing on to help up-level every other engineer within your organization. And I think that's one of the best ways to be thinking about it.And it was also a guiding principle for us within Pinterest to view what investments we could make in these central teams which can up-level each and every different type of engineer in the company as well. And just an example on that could be your mobile engineer would have very different expectations from your backend engineer who was working on certain aspects of code in your product. And it is truly important to understand where you want to centralize capabilities, which both these types of engineers could use, or you want to divest and have unique capabilities where it's going to make them productive. There's no one-size-fits-all solution for this, but I'm happy to talk about what we have at Pinterest, which has been reasonably working well. But I do think there's a lot more improvements we could be doing.Corey: Yeah, but let's also be clear that, as you've mentioned, you are heavily biased towards EC2 instances for a lot of what you do. If we look at the AWS console and we see hundreds of different services now, and it's easy to sit here and say, “Oh, internal platforms are terrible because all of those services are going to be enhanced in various ways and you're never going to be able to keep up with feature parity.” Yeah, but if you can wrap something like EC2 in an internal platform wrapper, that begins to be a different story because sure, someone's going to go and try something new with a different AWS service, they're going to need direct access. But the EC2 product across the board generally does not evolve in leaps and bounds with transformative changes overnight. Let's also not forget that at a company with the scale that Pinterest operates at, “Hey, AWS just dusted off a new feature and docs are still rolling out, and it's not in CloudFormation yet, but we're going to roll it out to production,” probably seems like the wrong direction to go in, I would assume.Micheal: And yes, I think that brings one of the key guardrails, I think, which these groups provide. So, when we start thinking about what teams, centralized teams like engineering productivity, developer tools, developer platforms actually do is they help with a couple of things. The top three are: they can help pave a path for the most common use cases. Like to your point, provisioning EC2 does take a set of steps, all the time. If you're going to have a thousand people doing that every time they're building a new service or trying to expand capacity playing with their launch templates, those are things you can start streamlining and making it simple by some wrapper because you want to address those 80% use cases which are usually common, and you can have a wrapper or could just automate that. And that's one of the key things: can you provide a paved path for those use cases?The second thing is, can you do that by having the right guardrails in place? How often have you heard the story that, “I just clicked a button and that now spun up, like, a thousand-plus instances.” And now you have to juggle between trying to stop them or do something about it.Corey: Back in 2013, you folks were still focusing on this fair bit. I remember because Jeremy Carroll, who I believe was your first SRE there once upon a time, wound up doing a whole series of talks around how Pinterest approached doing an AMI Factory. And back in those days, the challenges were, “Okay. We have the baseline AMI, and that's great, but we also want to do deployments of things and we don't really want to do a new deploy of an entire fleet of EC2 instances for a single line of config change, so how do we wind up weighing off of when you bake a new AMI versus when you just change something that has—in what is deployed to them?” And it was really a complicated problem back then.I'm not convinced it's not still a complicated problem, but the answers are a lot more cohesive. And making sure that every team—when you're talking about a company as large as Pinterest with that many teams—is doing things in the same way, seems like it's critically important otherwise you wind up with a whole bunch of unique-looking instances that each have to be managed by hand as opposed to something that can be reasoned around collectively.Micheal: Yep. And that last part you mentioned is extremely crucial as well because like I said, our audience or our customers are just not the engineers; we do work with our product managers and business partners as well because at times, we have to tie or change our architecture based on certain cost optimizations which would make sense, like you just articulated. We don't want to have all the instance types. It does not add much value to a developer unless they're explicitly seeking a high-memory instance or a [GP-based instance in a 00:10:25] certain way. So, we can then work with our business partners to make sure that we're committing to only a certain type of instances, and how we can abstract our tools to only give you that. For example, our deployment system, Teletraan which is an open-source system, actually condenses down all these instance types to a couple of categories like high-compute, high-memory—and you've probably seen that in many of the new cloud providers as well—so people don't have to learn or know the underlying instance type.When we moved from c3 to c5, it was just called as a high-compute system, so the next time someone provisioned a new service or deployed it using our system, they would just select high-compute as the de facto instance type and we would just automatically provision a C5 for them. So, that just reduces the extra complexity or the cognitive overhead individuals would have to go through in learning each instance type, what is the base AMI that comes on it, what are the different configurations that need to go in terms of setting up your AZ-scaling properties. We give them a good reasonable set of defaults to get started with, and then they can then work on optimizing or making changes to it.Corey: Ignoring entirely your mispronunciation of AMI, which is, of course, three syllables—and that is a petty hill upon which I will die—it occurs to me the more I work with AWS in various ways, the easier it gets. And I used to think in some respects, it was because the platform was so—it was improving so dramatically around me. But no, in many cases, it's because the first time you write some CloudFormation by hand, it's a nightmare and you keep smacking into weird issues. But the second or third time, it's super easy because you just copy the thing you've already built and change the relevant bits around. And that was the learning curve that I went through playing around with a lot of these things.When you start looking at this from a large-scale environment where it's not just about upskilling the people that you have to understand how these things integrate in AWS land, but also the consistent onboarding of engineers at a fairly progressive clip is, great, you effectively have to start doing trainings on all these things, and there's a lot of knobs and dials that can blow up and hurt people. At some point, building the guardrails or building the environment in which you are getting all the stuff abstracted away from where the application engineers have to think about this at all, it eventually reaches a tipping point where it starts to feel like it's no longer optional if you want to continue growing as a company because you don't have the luxury of spending six months of onboarding before you let someone touch the thing they were hired to build.Micheal: And you will see that many companies very often have very similar programming practices like you just described. Even I learned that the same way: you have a base template, you just copy-paste it and start from there on. And no one goes through the bootstrapping process manually anymore; you want to—I think we call it cargo-culting, but in general, just get something to bootstrap and start from there. But one of the things we learned in sort of the hard way is that can also lead to, kind of, you pushing, you know, not great practices because people don't know what is a blessed version of a good template or what actually would make sense. So, some of those things, we have been working on.And this is where centralized teams like engineering productivity are really helpful is we provide you with the blessed or the canonical way to do certain things. Case in point example is a CI/CD pipeline or delivery of software services. We have invested enough in experimenting on what works with some of the more nuanced use cases at Pinterest, in helping generate, sort of, a canonical version which would cover 80% of the use cases. Someone could just go and try to build a service and they could just use the same canonical pipeline without learning much or making changes to it. This also reduces that cargo-culting nature which I called, rather than copying it from unknown sources and trying to like—again, it may cause havoc to our systems, so we can avoid a lot of that because of these practices.Corey: So, let's step a little bit beyond AWS—I know I hate doing it, too—but I'm going to assume that your remit is broader than, oh, AWS whisperer-slash-Wrangler. So, tell me a little bit more about what it is that your day-to-day looks like if there is anything that could be said not to focus purely around AWS whispering.Micheal: So, one of the challenges—and I want to talk about this a bit more—is our environments have become extremely complex over time. And it's the nature of, like, rising entropy. Like, we've just noticed that there's two things: we have a diverse set of customer base, and these include everyone trying to do different workloads or work service types. What that essentially translates into is that we realized that our solution may not fit all of them. For example, what works for a machine-learning engineer in terms of iterating on building a model and delivering a model is not the same as someone working on a long-running service and trying to deploy that. The same would apply for someone trying to operate a Kafka system.And that has made, I think, definitely our job a bit challenging in trying to assess where do you actually draw the line on the abstraction? What is the right layer of abstraction across your local development experience, across when you move over to staging your code in a PR model and getting feedback and subsequently actually releasing it to production? Because this changes dramatically based on what is the workload type you're working on. And we feel like that has been one of the biggest challenges where I know I spent my day-to-day and my team does too, in trying to help provide some of the right solutions for these individuals. There's—very often we'll also get asked from individuals trying to do a very nuanced thing.Of late, we have been talking about thinking about how you operate functions, like provide Functions as a Service within the company? It just put us in a difficult spot at times because we have to ask the hard question, “Is this required?” I know the industry is doing it; it's definitely there. I personally believe, yes, it could be a future, but is that absolutely important? Is that going to benefit Pinterest in any formal way if we invest on some core abstractions?And those are difficult conversations to have because we have exciting engineers coming in trying to do amazing things; it puts us in a hard spot, as well, as to sometimes saying graciously, no. I know many companies deal with it when they have these centralized teams, but I think it's part of that job. Like when you say it's day-to-day, I would say I'm probably saying no a couple of times in that day.Corey: Let's pretend for the sake of argument that I am, tomorrow morning, starting another company—Twitter for Pets—and over the next ten years, it grows to be larger than Pinterest in terms of infrastructure, probably not revenue because it turns out pets are not the lucrative source of ad revenue that I was hoping it would be but, you know, directionally the same thing. It seems to me that building out this sort of function with this sort of approach to things is dramatically early as far as optimizations go when it's just me puttering around on something. I'm always cognizant of the wrong people taking the wrong message when we're talking about things that happen like this at scale. When does having an engineering productivity group begin to make sense?Micheal: I mentioned this earlier; like, yeah, there is definitely not a right answer, but we can start small. For example, this group actually started more as a delivery team. You know, when we started, we realized that we had different ways of deploying services or software at Pinterest, so we first gathered together to figure out, okay, what are the different ways and can we start simplifying that part? And that's where it started expanding. Okay, we are doing button-based deployments right now we have thousand-plus microservices, and we are seeing more incidents than we wanted to because anything where there's a human involved means there's a potential gap for error. I myself was involved in a SEV 0 incident, and I will be honest; we ended up deploying a Hello World application in one of our production fleet. Not the thing I wanted to be associated with my name, but, you know—Corey: And you were suddenly saying hello to the world, in fact—Micheal: [laugh].Corey: —and oops-a-doozy.Micheal: Yeah. So—and that really prompted us to rethink how we need to enable guardrails to do safe production rollouts. And that's how those conversations start ballooning out.Corey: And the healthy correct way. We've all broken production in various ways, and it's—you correctly are identifying, I believe, the direction you're heading in where this is a process problem and a tooling problem; it is not that you are secretly crap and should never have been allowed near anything in production. I mean, that's my excuse for me, but in your case, this is a common thing where it's, if someone can unintentionally cause issues like that, there needs to be better processes and procedures as the organization matures.Micheal: Yep. And that's kind of like always the route or the starting point for these discussions. And it starts growing from there on because, okay, you've helped improve the deploy process but now we're seeing insane amount of slowness, say on the build processes, or even post-deploy, there's, like, issues on how we monitor and look into data.And that I think forces these conversations, okay, where do we have these bespoke tools available? What are people doing today? And you have to ask those hard questions, like what can we actually remove from here? The goal is not to introduce yet another new system. Many a times, to be honest bash just gets the job done. [laugh].Personally, I'm okay with that as long as it's consistent and people, you know, are able to contribute to it and you have good practices in validating it, if it works, we should go for it rather than introducing yet another YAML [laugh] and some of that other aspects of doing that work. And that's what we encourage as well. That's how I think a lot of this starts connecting together in terms of, okay, now this is becoming a productivity group; they're focused on certain challenges where investing probably one person here may up-level a few other engineers who don't have to do that on a day-to-day basis. And I think that's one of the key items for, especially, folks who are running mid-sized companies to realize and start investing in these type of teams to really up-level, sort of, the rest of the engineering.Corey: You've been doing this for a fair while. If you were to go back and start over again on day one—which is always a terrifying question, on some level—what would you have done differently about building out this function as Pinterest continued to scale out?Micheal: Well, first, I must acknowledge that this was just not me, and there's, like, ton of people involved in helping make this happen.Corey: No, that's fair. We'll blame them for the missteps; that is—Micheal: [laugh].Corey: —just fine with me. I kid. I kid.Micheal: I think, definitely the nuances. If I look back, all the decisions that were made then at that point in time, there was a decision made to move to Phabricator, which was back then a great open-source code management system where with the current information at that point in time. And I'm not—I think it's very hard to always look back and say, “Oh, we could have chosen x at one point in time.” And I think in reality, that's how engineering organizations always evolve, that you have to make do with the information you have right now to make a decision that works for you over a couple of years.And I'll give you a small example of this. There was a time when Pinterest was actually on GitHub Enterprise—this was like circa 2013, I would say—and it really served as well for, like, five-plus years. Only then at certain point, we realized that it's hard to hire PHP engineers to support a tool like that, and we had to rethink what is the ROI and the investments we've made here? Can we ever map up or match back to one of the offerings in the industry today? And that's when you make decisions that, okay, at this point in time, it's clear that business continuity talks, you know, and it's hard to operate a system, which is, at this moment not supported, and then you make a call about making a shift or moving.And I think that's the key item. I don't think there's anything dramatically I would have changed since the start. Perhaps definitely investing a bit more individuals into the group and going from there. But that said, I'm really, sort of, at least proud of the fact that usually these teams are extremely lean and small, and they always have an outsized impact, especially when they're working with other engineers, other [opinionated 00:22:13] engineers for what it's worth.This episode is sponsored by our friends at Oracle Cloud. Counting the pennies, but still dreaming of deploying apps instead of "Hello, World" demos? Allow me to introduce you to Oracle's Always Free tier. It provides over 20 free services and infrastructure, networking databases, observability, management, and security.And - let me be clear here - it's actually free. There's no surprise billing until you intentionally and proactively upgrade your account. This means you can provision a virtual machine instance or spin up an autonomous database that manages itself all while gaining the networking load, balancing and storage resources that somehow never quite make it into most free tiers needed to support the application that you want to build.With Always Free you can do things like run small scale applications, or do proof of concept testing without spending a dime. You know that I always like to put asterisks next to the word free. This is actually free. No asterisk. Start now. Visit https://snark.cloud/oci-free that's https://snark.cloud/oci-free.Corey: Most folks show up intending to do good today, and you make the best decision at the time with the context and constraints that you have, but my question I think is less around, “Well, what were the biggest mistakes you made?” But more to do with the idea of, based upon what you've learned and as you have shown—as you've shined light on these dark areas, as you have been exploring it, has anything jumped out at you that is, “Oh, yeah. Now, that I know—if I had known then what I know now, I would definitely have made this other decision.” Ideally, something that applies a little more globally than specific within Pinterest, just because the whole idea, aspirationally, is that people might learn something from our conversation. At least I will, if nothing else.Micheal: No, I think that's a great question. And I think the three things that jump to me, top of mind. I think technology is means to an end unless it gives you a competitive edge. And it's really hard to figure out at what point in time what technology and why we adopted it, it's going to make the biggest difference. Humans always tend to have a bias towards aligning towards where we want to go. So, that's the first one in my mind.The second one is, and we spoke about this last time, embrace your cloud provider as much as possible. You'd want to avoid taking on operational burden which is not going to add value to the business. If there is something you see your operating which can be offloaded—because your provider can, trust me, do a way better job than you or your team of few can ever do—embrace that as soon as possible. It's better that way because then it frees up your time to focus on the most important thing, which I've realized over time is—I really think teams like ours are actually—we're probably the most value as a glue to all the different experiences a software engineer would go through as part of their SDLC lifecycle.If we can simplify someone's life by giving them a clear view as to where their commit or the work is in this grand scheme of rolling out and giving them the right amount of data to take action when something goes wrong, trust me, they will love you for what you're doing because you're saving them ton of time. Many times, we don't realize that when we publish 11 different ways for you to go and check to just get your basic validation of work done. We tend to so much focus on the technological aspect of what the tool does, rather than the experience of it, and I've realized, if you can bridge the experience, especially for teams like ours, people really don't even need to know whether you're running Kubernetes or any of those solutions behind the scenes. And I think that's one of the biggest takeaways I have.Corey: I want to double down on something you said about the fact that you are not going to be able to run these services as effectively as your provider can. And relatively recently—in fact, since the first time we spoke—AWS has released a investment report in Virginia. And from 2011 through 2020, they have invested in building AWS data centers there, $35 billion. I promise almost no company that employs people listening to this that are not themselves a cloud provider is going to make that kind of investment in running these things themselves.Now, do cloud providers have sharp edges? Yes, absolutely. That is what my entire career is about, unfortunately. But you're not going to do a better job of running things more sustainably, more reliably, et cetera, et cetera. But there are other problems with this—and that's what I want to start exploring here—where in the olden days, when I ran things in data centers and they went down a lot more as a result, sometimes when there were outages, I would have the CEO of the company just standing there nervous worrying over my shoulder as I frantically typed to fix things.Spoiler: my typing accuracy did not improve by having someone looming over me. Now, when there's an outage that your cloud provider takes, in many cases the thing that you are doing to fix it is reloading the status page and waiting for an update because it is completely out of your hands. Is that something that you've had to encounter? Because you can push buttons and turn dials when things are broken and you control it, but in an AWS—or other cloud provider—outage, all you can really do is wait unless you have a DR plan that is large-scale and effective enough that you won't feel foolish or have wasted a huge amount of time and energy migrating off and then—because then it gets repaired in ten minutes. How do you approach that, from your perspective? I guess, the expectation management piece?Micheal: It's definitely I know something which keeps a lot of folks within infrastructure up at night because, like you just said, at times we can feel extremely powerless when we obviously don't have direct control—or visibility at times, as well—on what's happening. One of the things we have realized over time as part of running on our cloud provider for over a decade now, it forces us to rethink a bit on our priority workflows, what we want our Pinners to always have access to, what they need to see, what is not important or critical. Because it puts into perspective, even for the infrastructure teams, is to what is the most important thing we should always have it available and running, what is okay to be in a degraded state, until what time, right? So, it actually forces us to define SLOs and availability criteria within the team where we can broadcast that to the larger audience including the executives. So, none of this comes as a surprise at that point.I mean, it's not the answer, probably, you're looking for because is there's nothing we can do except set expectations clearly on what we can do and how when you think about the business when these things do happen. So, I know people may have I have a different view on this; I'm definitely curious to hear as well, but I know at Pinterest at least we have converged on our priority workflows. When something goes out, how do we jump in to provide a degraded experience? We have very clear run books to do that, and especially when it's a SEV 0, we do have clear processes in place on how often we need to update our entire company on where things are. And especially this is where your partnership with the cloud provider is going to be a big, big boon because you really want to know or have visibility, at the minimum some predictability on when things can get resolved, and how you want to work with them on some creative solutions. This is outside the DR strategy, obviously; you should still be focused on a DR strategy, but these are just simple things we've learned over time on how to just make it predictable for individuals within the company, so not everyone is freaking out.Corey: Yeah, from my perspective, I think the big things that I found that have worked, in my experience—mostly by getting them wrong the first time—is explain that someone else running the infrastructure when they take an outage; there's not much we can do. And no, it's not the sort of thing where picking up the phone and screaming at someone is going to help us, is the sort of thing that is best to communicate to executive stakeholders when things are running well, not in the middle of that incident.Then when things break, it's one of those, “Great, you're an exec. You know what your job is? Literally anything other than standing in the middle of the engineering floor, making everyone freak out even more. We'll have a discussion later about what the contributing factors were when you demand that we fire someone because of an outage. Then we're going to have a long and hard talk about what kind of culture you're trying to build here again?” But there are no perfect answers here.It's easy to sit here in the silver light of day with things working correctly and say, “Oh, yeah. This is how outages should be handled.” But then when it goes down, we're all basically an inch away at best from running around with our hair on fire, screaming, “Fix it, fix it, fix it, fix it, now.” And I am empathetic to that. There's a reason but I fix AWS bills for a living, and one of those big reasons is that it's a strictly business-hours problem and I don't have to run production infrastructure that faces anything that people care about, which is kind of amazing and freeing for someone who spent too many years on call.Micheal: Absolutely. And one of the things is that this is not only with the cloud provider, I think in today's nature of how our businesses are set up, there's probably tons of other APIs you are using or you're working with you may not be aware of. And we ended up finding that the hard way as well. There were a certain set of APIs or services we were using in the critical path which we were not aware of. When these outages happen, that's when you find that out.So, you're not only beholden to your provider at that point in time; you have to have those SLO expectations set with your other SaaS providers as well, other folks you're working with. Because I don't think that's going to change; it's probably only going to get complicated with all the different types of tools you're using. And then that's a trade-off you need to really think about. An example here is just like—you know, like I said, we moved in the past from GitHub to Phabricator—I didn't close the loop on that because we're moving back to GitHub right now [laugh] and that's one of the key projects I'm working with. Yeah, it's circle of life.But the thing is, we did a very strong evaluation here because we felt like, “Okay, there's a probability that GitHub can go down and that means people will be not productive for that couple of hours. What do we do then?” And we had to put a plan together to how we can mitigate that part and really build that confidence with the engineering teams, internally. And it's not the best solution out there; the other solution was just run our own, but how is that going to make any other difference because we do have libraries being pulled out of GitHub and so many other aspects of our systems which are unknowingly dependent on it anyways. So, you have to still mitigate those issues at some point in your entire SDLC process.So, that was just one example I shared, but it's not always on the cloud provider; I think there are just many aspects of—at least today how businesses are run, you're dependent; you have critical dependencies, probably, on some SaaS provider you haven't really vetted or evaluated. You will find out when they go down.Corey: So, I don't think I've told this story before, but before I started this place, I was doing a fair bit of consulting work for other companies. And I was doing a project at Pinterest years ago. And this was one of the best things I've ever experienced at a company site, let alone a client site, where I was there early in the morning, eight o'clock or so, so you know, engineers love to show up at the crack of 11:30. But so I was working a little early; it was great. And suddenly my SSH session that I was using to remote into something or other hung.And it's tap up, tap enter a couple of times, tap it a couple more. It was hung hard. “What's the—” and then someone gently taps me on the shoulder. So, I take the headphones off. It was someone from corporate IT was coming around saying, “Hey, there's a slight problem with our corporate firewall that we're fixing. Here's a MiFi device just for you that you can tether to get back online and get worked on until the firewall gets back.”And it was incredible, just the level of just being on top of things, and the focus on keeping the people who were building things and doing expensive engineering work that was awesome—and also me—productive during that time frame was just something I hadn't really seen before. It really made me think about the value of where do you remove bottlenecks from people getting their jobs done? It was—it remains one of the most impressive things I've seen.Micheal: That is great. And as you were telling me that I did look up our [laugh] internal system to see whether a user called Corey Quinn existed, and I should confirm this with you. I do see entries over here, a couple of commits, but this was 2015. Was that the time you were around, or is this before that even?Corey: That would have been around then, yes. I didn't start this place until late 2016.Micheal: I do see your commits, like, from 2015, and I—Corey: And they're probably terrible, I have no doubt. There's a reason I don't read code for a living anymore.Micheal: Okay, I do see a lot of GIFs—and I hope it's pronounced as GIF—okay, this is cool. We should definitely have a chat about this separately, Corey?Corey: Oh, yeah. “Would you explain this code?” “Absolutely not. I wrote it. Of course, I have no idea what it does. That's the rule. That's the way code always works.”Micheal: Oh, you are an honorary Pinterest engineer at this point, and you have—yes—contributed to our API service and a couple of Puppet profiles I see over here.Corey: Oh, yes—Micheal: [Amazing 00:36:11]. [laugh].Corey: You don't wind up thinking that's a risk factor that should be disclosed. I kid. I kid. It's, I made a joke about this when VMware acquired SaltStack and I did some analytics and found that 60 some odd lines of code I had written, way back when that were still in the current version of what was being shipped. And they thought, “Wait, is this actually a risk?”And no, I am making a joke. The joke is, is my code is bad. Fortunately, there are smart people around me who review these things. This is why code review is so important. But there was a lot to admire when I was there doing various things at Pinterest. It was a fun environment to work in, the level of professionalism was phenomenal, and I was just a big fan of a lot of the automation stuff.Phabricator was great. I love working with it, and, “Great, I'm going to use this to the next place I go.” And I did and then it was—I looked at what it took to get it up and running, and oh, yeah, I can see why GitHub is so popular these days. But it was neat. It was interesting seeing that type of environment up close.Micheal: That is great to hear. You know, this is what I enjoy, like, hearing some of these war stories. I am surprised; you seem to have committed way more than I've ever done in my [laugh] duration here at Pinterest. I do managing for a living, but then again—Corey, the good news is your code is still running on production. And we—Corey: Oh dear.Micheal: —haven't—[laugh]. We haven't removed or made any changes to it, so that's pretty amazing. And thank you for all your contributions.Corey: Oh, please, you don't have to thank me. I was paid, it was fine. That's the value of—Micheal: [laugh].Corey: —[work 00:37:38] for hire. It's kind of amazing. And the best part about consultants is, is when we're done with a project, we get the hell out everyone's happy about it.More happy when it's me that's leaving because of obvious personality-related reasons. But it was just an interesting company from start to finish. I remember one other time, I wound up opening a ticket about having a slight challenge with a flickering on my then Apple-branded display that everyone was using before they discontinued those. And I expected there to be, “Oh, okay. You're a consultant. Great. How did we not put you in the closet with a printer next to that thing, breathing the toner?” Like most consulting clients tend to do, and sure enough, three minutes later, I'm getting that tap on the shoulder again; they have a whole replacement monitor. “Can you go grab a cup of coffee? We'll run the cable for it. It'll just be about five minutes.” I started to feel actively bad about requesting things because I did a lot of consulting work for a lot of different companies, and not to be unkind, but treating consultants and contractors super well is not something that a lot of companies optimize for. I can't necessarily blame them for that. It just really stood out.Micheal: Yep, I do hope we are keeping up with that right now because I know our team definitely has a lot of consultants working with us as well. And it's always amazing to see; we do want to treat them as FTs. It doesn't even matter at that point because we're all individuals and we're trying to work towards common goals. Like you just said, I think I personally have learned a few items as well from some of these folks. Which is again, I think speaks to how we want to work and create a culture of, like, we're all engineers; we want to be solving problems together, and as you were doing it, we want to do it in such a way that it's still fun, and we're not having the restrictions of titles or roles and other pieces. But I think I digressed. It was really fun to see your commits though, I do want to track this at some point before we move completely over to GitHub, at least keep this as a record, for what it's worth.Corey: Yeah basically look at this graffiti in the codebase of, “A shit-poster was here,” and here I am. And that tends to be, on some level, the mark we live on the universe. What's always terrifying is looking at things I did 15 years ago in my first Linux admin job. Can I still ping the thing that I built there? Yes, I can. And how is that even possible? That should not have outlived me; honestly, it should never have seen the light of day in production, but here we are. And you never know how long that temporary kluge you put together is going to last.Micheal: You know, one of the things I was recalling, I was talking to someone in my team about this topic as well. We always talk about 10x engineers. I don't know what your thoughts are on that, but the fact that you just mentioned you built something; it still pings. And there's a bunch of things, in my mind, when you are writing code or you're working on some projects, the fact that it can outlast you and live on, I think that's a big, big contribution. And secondly, if your code can actually help up-level, like, ten other people, I think you've really made the mark of 10x engineer at that point.Corey: Yeah, the idea of the superhuman engineer is always been a strange and dangerous one. If for nothing else, from where I sit, excellence is inherently situational. Like we just talked about someone at Pinterest: is potentially going to be able to have that kind of impact specifically because—to my worldview—that there's enough process and things around there that empower them to succeed. Then if you were to take that engineer and drop them into a five-person startup where none of those things exist, they might very well flounder. It's why I'm always a little suspicious of this is a startup founded by engineers from Google or Facebook, or wherever it is.It's, yeah, and what aspects of that culture do you think are one-to-one matches with the small scrappy startup in the garage? Right, I predicting some challenges here. Excellence is always situational. An amazing employee at one company can get fired at a second one for lack of performance, and that does not mean that there's anything wrong with them and it does not mean that they are a fraud. It means that what they needed to be successful was present in one of those shops, but not the other.Micheal: This is so true. And I really appreciate you bringing this up because whenever we discuss any form of performance management, that is a—in my view personally—I think that's an incorrect term to be using. It is really at that point in time, either you have outlived the environment you are in, or the environment is going in a different direction where I think your current skill set probably could be best used in the environment where it's going to work. And I know it's very fuzzy at that point, but like you said, yes, excellence really means you don't want to tie it to the number of commits you have pushed out, or any specific aspect of your deliverables or how you work.Corey: There are no easy answers to any of these things, and it's always situational. It's why I think people are sometimes surprised when I will make comments about the general case of how things should be, then I talk to a specific environment where they do the exact opposite, and I don't yell at them for it. It's there—in a general sense, I have some guidance, but they are usually reasons things are the way they are, and I'm interested in hearing them out. Everything's situational, the worst consultant in the world is the one that shows up, has no idea what's going on, and then asked, “What moron set this up?” Invariably, two said, quote-unquote, “Moron.” And the engagement doesn't go super well from there. It's, “Okay, why is this the way that it is? What constraints shaped it? What was the context behind the problem you were trying to solve?” And, “Well, why didn't you use this AWS service?” “Because it didn't exist for another three years when we were building that thing,” is a—Micheal: Yes.Corey: —common answer.Micheal: Yes, you should definitely appreciate that of all the decisions that have been made in past. People tend to always forget why they were made. You're absolutely right; what worked back then will probably not work now, or vice versa, and it's always situational. So, I think I can go on about this for hours, but I think you hit that to the point, Corey.Corey: Yeah, I do my best. I want to thank you for taking another block of time out of your day to wind up talking with me about various aspects of what it takes to effectively achieve better levels of engineering productivity at large companies, with many teams, working on shared codebases. If people want to learn more about what you're up to, where can they find you?Micheal: I'm definitely on Twitter. So, please note that I'm spelled M-I-C-H-E-A-L on Twitter. So, you can definitely read on to my tweets there. But otherwise, you can always reach out to me on LinkedIn, too.Corey: Fantastic and we will, of course, include a link to that in the [show notes 00:44:02]. Thanks once again for your time. I appreciate it.Micheal: Thanks a lot, Corey.Corey: Micheal Benedict, head of engineering productivity at Pinterest. I'm Cloud Economist Corey Quinn and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice along with a comment telling me that you work at Pinterest, have looked at the codebase, and would very much like a refund and an apology.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

Learn more about Tuvy:Tuvy's LinkedInTuvy's TwitterEpisode resources:GitHub Support CommunityIf you enjoyed this episode then please either:Subscribe, rate, and review on Apple PodcastsFollow on Spotify

Cloud Security News this week 17 November 2021 According to a research by Trend Micro, Elastic Computing Service (ECS) instances for Alibab Cloud are becoming an increasingly common target for financially motivated hackers with cryptomining goals. This increased targeting may be due to a few unique features of Alibaba Cloud. Alibaba ECS instances come with a preinstalled security agent and provides root access/ privileged control by default. There is a detailed article attached about this here JupiterOne (a Cyber Asset Management Platform ) and Cisco have announced the launch of Secure Cloud Insights, an expanded cloud security and security operations partnership designed to provide businesses with a range of cybersecurity services. This new solution is aimed at helping Cisco customers achieve a higher level of maturity with their digital transformation and security program. CEO of Jupiter One, Erkang Zheng calls it a game changing offering - that would provide increased visibility, efficiency, and speed to security operations, with combined context from situational awareness and structural data. We would be curious to know if you think the same. Those familiar with Palo Alto and their core cloud-security package, Prisma may be intrigued to know that they have launched Prisma 3.0. Truffle Security has released an open source hacking tools called Driftwood designed to discover leaked, paired private and public keys which may be harmful. Driftwood builds upon Truffle Hog and is available on Github. Truffle Security in their blog which is shared here. stated that With this tool they found the private keys for hundreds of Transport Layer Security certificates, and Secure Shell keys that would have allowed an attacker to compromise millions of endpoints/devices. The Federal government is going from a “Cloud First” to a “Cloud Smart” strategy to leverage cloud without compromising security. They quoted that “Cloud Smart is about equipping agencies with the tools and knowledge they need to make these decisions for themselves, rather than a one-size-fits-all approach.The shift will be from “buy before build” to “solve before buy,”. Under security they added that “Successfully managing cloud adoption risks requires collaboration” leaning into that shared responsibility model we hear often about with Cloud Security. The link to the document is here Episode Show Notes on Cloud Security Podcast Website. Podcast Twitter - Cloud Security Podcast (@CloudSecPod) Instagram - Cloud Security News If you want to watch videos of this LIVE STREAMED episode and past episodes, check out: - Cloud Security Podcast: - Cloud Security Academy:

Vlado Cingel recounts his story where he needed common table expressions within SQL for a project he was working on and wrote a patch to AREL and ActiveRecord which he submitted to the Rails Core. Since it hasn't been accepted, he's supporting it as a gem. Vlado explains what Common Table Expressions (CTEs) are, how they work, and where they're used. Panel John EppersonLuke StuttersValentino Stoll Guest Vlado Cingel Sponsors Top End DevsRaygun | Click here to get started on your free 14-day trialCoaching | Top End Devs Links GitHub | vlado/activerecord-cteOrganising complex SQL queries in RailsGitHub: Vlado Cingel ( vlado ) Picks John- Digital Storm: Custom Gaming Computers & Gaming PCsLuke- Pitch PerfectValentino- Ruby TogetherValentino- Ruby CentralValentino- The Ruby VM a speedrun - Penelope PhippenVlado- The Wood Whisperer Guild - Online Woodworking SchoolVlado- Polished Ruby Programming Contact John: Rock Agile ConsultingGitHub: John Epperson ( kirillian )LinkedIn: John Epperson Contact Luke: GitHub: Luke Stutters ( lukestuts ) Contact Valentino: Doximity Technology BlogWork @ DoximityGitHub: Valentino Stoll ( codenamev )Twitter: V ( @thecodenamev ) Special Guest: Vlado Cingel.

In October and November, Microsoft hosted the GitHub Universe and Ignite 2021 conferences, focused on Developers and Cloud Computing. We review the important announcements and analyze the future directions for Azure, GitHub, etc SHOW: 567CLOUD NEWS OF THE WEEK - http://bit.ly/cloudcast-cnotwCHECK OUT OUR NEW PODCAST - "CLOUDCAST BASICS"SHOW SPONSORS:CBT Nuggets: Expert IT Training for individuals and teamsSign up for a CBT Nuggets Free Learner account Megaport - Network as a Service PlatformTry Megaport - Cloud Connectivity SimplifiedBMC Wants to Know if your business is on it's A-GameBMC Autonomous Digital EnterpriseSHOW NOTES:Microsoft Ignite 2021 AnnouncementsMicrosoft Ignite 2021 (Keynote)Everything new from GitHub Universe 2021GitHub Universe 2021 (Keynote)Azure - Bigger Announcements Azure OpenAI Service - access to GPT-3 Azure Cognitive Service for LanguageAzure Cosmos DB Azure Managed Instance of Apache CassandraAzure Synapse Analytics Azure Container Apps (preview) Open Service Mesh for Kubernetes(Java EE) Oracle Weblogic  on Azure Kubernetes Service. (Java EE) Websphere Liberty on Kubernetes/OpenShiftEnhancements to Azure DevOps (see GitHub)GitHub - Bigger AnnouncementsImproved CI/CD workflows with GitHub ActionsImprovements to GitHub CodespacesCustom repository roles (security)Improved “Issues” and “Discussions”FEEDBACK?Email: show at the cloudcast dot netTwitter: @thecloudcastnet

Liyas Thomas is the founder of Hoppscotch, an open source API development ecosystem that's seen exponential growth. Encouraged by his own mentors, Liyas now maintains Hoppscotch full time. Whether he's programming or pursuing his passion for art, he always puts beauty at the core of his work. During this conversation, he shares his path to Hoppscotch, the importance of community, and a preview of his newest endeavor: a book. Liyas on GitHub: https://github.com/liyasthomas Liyas' website: https://liyasthomas.com/ Be sure to check-out The ReadME Project for more episodes, stories and features: https://github.com/readme

GitHub's CEO, Nat Friedman, stepped down recently to focus on his startup roots. Chief product officer, Thomas Dohmke, will be moving to CEO. The Verge reviewed our no-longer-a-joke April Fool's keyboard. How many keyboard layouts are there anyway? Including non-English layouts, there's lots. Do you have a mind's eye? How about an inner monologue? We explore why some people have a voice in their head when they think and some don't. 

Chris finally got his new computer!

Every Monday at 3:30PM UTC/11:30AM EST Horizen gives a LIVE update on Discord including a Q&A session with the community.  Weekly Insider detailed chat channel in Discord: https://horizen.io/invite/discord November 15, 2021, Weekly team updates from the following divisions: * Engineering * Node network * Product/UX * Customer service/Helpdesk * Legal * Business development * Marketing * Team Lead closing thoughts * 5 mins Q&A ZEN 3.0.0 (Zendoo) released on mainnet! ZEN 2.0.24 deprecation: December 1 ZEN 3.0.0 (Zendoo) hard fork: December 1 (deprecation +24 blocks) Horizen is an exciting cryptocurrency with a solid technological foundation, unique capabilities, an active and capable team, ongoing funding for improvements, and a large, positive, encouraging community. ZEN is available and trading now on Bittrex, Binance, Coinbase, and more, has wallets available that implement advanced private transaction and messaging capability and has a strong roadmap. The goal of Horizen is to create a usable private cryptocurrency operating on a resilient system for people and businesses worldwide, enabling the daily use of private transactions, messaging, and publishing everywhere, all the time. Store: https://store.horizen.io Merchant Directory: https://horizen.io/merchants Horizen Nodes: https://horizen.io/zennodes Horizen Academy: https://academy.horizen.io/ Reference: Horizen Website – https://www.horizen.io Horizen Blog – https://blog.horizen.io Horizen Discord - https://horizen.io/invite/discord Horizen Github – https://github.com/HorizenOfficial Horizen Forum – https://forum.horizen.io/ Horizen Twitter – https://twitter.com/horizenglobal Horizen Telegram – https://horizen.io/invite/telegram Horizen on Bitcointalk – https://goo.gl/5vicqP Horizen YouTube Channel – https://www.youtube.com/c/Horizen/ Horizen Facebook Page – https://www.facebook.com/horizenglobal/ Horizen on Instagram - https://instagram.com/horizenglobal Horizen Blog on Medium – https://medium.com/@horizen Buy or Sell Horizen Horizen on CoinMarketCap – https://bit.ly/ZENCoinMarketCap Horizen on CoinGecko – https://bit.ly/ZENCoinGecko                                      

Kareem Zaki is a General Partner @ Thrive Capital, with a portfolio including Stripe, Instacart, Instagram, Nubank, Github, Glossier and many more, they have cemented their position as one of the leading venture firms of the last decade. As for Kareem, he is a co-founder and board member to Cedar, Nava, Scope Security and Cadence and has invested in the likes of Affirm, Lemonade, Ramp and Trade Republic. Prior to entering venture, Kareem spent 3 years in private equity with Blackstone. In Today's Episode with Kareem Zaki You Will Learn: 1.) How Kareem made his way from the world of private equity to backing some of the most innovative next-generation companies with Thrive Capital? 2.) Portfolio Construction: What is the one rule that drives all decision-making at Thrive? How does Kareem think about maintaining focus with such a broad mandate? How do Thrive think about asset allocation internally with such a broad mandate? How does incubating companies also help Kareem be a better investor? 3.) Investing Style: How has Kareem's investing style changed over the last 10 years? What does he focus on now that he did not before and visa versa? How does Kareem assess his own relationship to price? Through what lens does Kareem approach market sizing and timing? Where do many investors make mistakes here? 4.) The Landscape: How does Kareem respond to the activity and cadence of Tiger? In what way does Kareem believe the venture landscape will have changed most significantly in the next 10 years? How do the existing incumbent firms need to change in the wake of this? How do Thrive respond to the pace and cadence of check writing today? Item's Mentioned In Today's Episode with Kareem Zaki Kareem's Favourite Book: How Will You Measure Your Life Kareem's Most Recent Investment: Cadence

We break down the latest in .NET 6, VS 2022, and all of .NET Conf 2021. Follow Us Frank: Twitter, Blog, GitHub James: Twitter, Blog, GitHub Merge Conflict: Twitter, Facebook, Website, Chat on Discord Music : Amethyst Seer - Citrine by Adventureface ⭐⭐ Review Us (https://itunes.apple.com/us/podcast/merge-conflict/id1133064277?mt=2&ls=1) ⭐⭐ Machine transcription available on http://mergeconflict.fm

Brian Lovin is a designer, podcaster, writer, and software tinkerer. He is currently building native mobile apps at GitHub. Before GitHub, he co-founded Spectrum, a platform for large-scale communities to have better public conversations. Spectrum was acquired by GitHub in November, 2018. Before Spectrum he designed payments experiences at Facebook, working across Facebook, Messenger, WhatsApp, and Instagram. He also co-host the Design Details Podcast, a weekly conversation about design process and culture. ARE YOU LOOKING TO GROW AS AN INDIVIDUAL CONTRIBUTOR?Visit Staff.design and learn how navigate the individual contributor design career path  from interviews with successful designersCONNECT WITH BRIAN LOVINFollow Brian Lovin on TwitterRead about Brian Lovin's thoughts LEVEL UP YOUR DESIGN CAREER (FREE EMAIL COURSE)Learn 7 proven strategies in 7 days to grow in your design career -https://levelup.designmba.show/