Podcasts about Context

The Context of White Supremacy hosts the second study session on Ernest Tidyman's 1970 novel, SHAFT. Tidyman is a White man. He forged a distinguished journalism career working for The New York Times and Ohio's The Plain Dealer. In the midst of the so called Civil Rights Movement and the unrest of the 1960's, Tidyman decided to concoct a narrative around a black private detective named John SHAFT. This relatively short book sparked a half century of trashy films and mightily influenced the thoughts, speech, action, emotions, and wardrobe of generations of black people. Most of these victims are clueless that their favorite black action hero is the creation of a White man. During the premier session, Gus and listeners were shocked by Tidyman's vulgarity, homoeroticism and slurs. He routinely employs the word "fag," and has SHAFT pretend to set up a date for homosexual/anti-sexual activity with a "gay" White Man. While speaking with the police, Tidyman places SHAFT in a the "butt-cupping grip" of a steel chair. Similar to Romain Gary's WHITE DOG, the White male author obsessives over the black male physique. Tidyman greatly details the black body of John SHAFT, including scars received while fighting in Vietnam. Tidyman was reportedly unhappy that's SHAFT's veteran status was excised from the movie. When not being ogled by the White Men of New York, SHAFT has sexual intercourse with a White Woman. In between all this, a black male dies, and SHAFT gets a shoe shine from a black "shine boy," whom Tidyman describes as neutered. #IsaacHayes INVEST in The COWS – http://paypal.me/TheCOWS Cash App: https://cash.app/$TheCOWS CALL IN NUMBER: 720.716.7300 CODE: 564943#

About EwereCloud, DevOps Engineer, Blogger and AuthorLinks: Infrastructure Monitoring with Amazon CloudWatch: https://www.amazon.com/Infrastructure-Monitoring-Amazon-CloudWatch-infrastructure-ebook/dp/B08YS2PYKJ LinkedIn: https://www.linkedin.com/in/ewere/ Twitter: https://twitter.com/nimboya Medium: https://medium.com/@nimboya My Cloud Series: https://mycloudseries.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 Honeycomb. When production is running slow, it's hard to know where problems originate: is it your application code, users, or the underlying systems? I've got five bucks on DNS, personally. Why scroll through endless dashboards, while dealing with alert floods, going from tool to tool to tool that you employ, guessing at which puzzle pieces matter? Context switching and tool sprawl are slowly killing both your team and your business. You should care more about one of those than the other, which one is up to you. Drop the separate pillars and enter a world of getting one unified understanding of the one thing driving your business: production. With Honeycomb, you guess less and know more. Try it for free at Honeycomb.io/screaminginthecloud. Observability, it's more than just hipster monitoring.Corey: This episode is sponsored in part by Liquibase. If you're anything like me, you've screwed up the database part of a deployment so severely that you've been banned from touching every anything that remotely sounds like SQL, at at least three different companies. We've mostly got code deployments solved for, but when it comes to databases we basically rely on desperate hope, with a roll back plan of keeping our resumes up to date. It doesn't have to be that way. Meet Liquibase. It is both an open source project and a commercial offering. Liquibase lets you track, modify, and automate database schema changes across almost any database, with guardrails to ensure you'll still have a company left after you deploy the change. No matter where your database lives, Liquibase can help you solve your database deployment issues. Check them out today at liquibase.com. Offer does not apply to Route 53.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. I periodically make observations that monitoring cloud resources has changed somewhat since I first got started in the world of monitoring. My experience goes back to the original Call of Duty. That's right: Nagios.When you set instances up, it would theoretically tell you when they were unreachable or certain thresholds didn't work. It was janky but it kind of worked, and that was sort of the best we have. The world has progressed as cloud has become more complicated, as technologies have become more sophisticated, and here today to talk about this is the first AWS Hero from Africa and author of a brand new book, Ewere Diagboya. Thank you for joining me.Ewere: Thanks for the opportunity.Corey: So, you recently published a book on CloudWatch. To my understanding, it is the first such book that goes in-depth with not just how to wind up using it, but how to contextualize it as well. How did it come to be, I guess is my first question?Ewere: Yes, thanks a lot, Corey. The name of the book is Infrastructure Monitoring with Amazon CloudWatch, and the book came to be from the concept of looking at the ecosystem of AWS cloud computing and we saw that a lot of the things around cloud—I mostly talked about—most of this is [unintelligible 00:01:49] compute part of AWS, which is EC2, the containers, and all that, you find books on all those topics. They are all proliferated all over the internet, you know, and videos and all that.But there is a core behind each of these services that no one actually talks about and amplifies, which is the monitoring part, which helps you to understand what is going on with the system. I mean, knowing what is going on with the system helps you to understand failures, helps you to predict issues, helps you to also envisage when a failure is going to happen so that you can remedy it and also [unintelligible 00:02:19], and in some cases, even give you a historical view of the system to help you understand how a system has behaved over a period of time.Corey: One of the articles that I put out that first really put me on AWS's radar, for better or worse, was something that I was commissioned to write for Linux Journal, back when that was a print publication. And I accidentally wound up getting the cover of it with my article, “CloudWatch is of the devil, but I must use it.” And it was a painful problem that people generally found resonated with them because no one felt they really understood CloudWatch; it was incredibly expensive; it didn't really seem like it was at all intuitive, or that there was any good way to opt out of it, it was just simply there, and if you were going to be monitoring your system in a cloud environment—which of course you should be—it was just sort of the cost of doing business that you then have to pay for a third-party tool to wind up using the CloudWatch metrics that it was gathering, and it was just expensive and unpleasant all around. Now, a lot of the criticisms I put about CloudWatch's limitations in those days, about four years ago, have largely been resolved or at least mitigated in different ways. But is CloudWatch still crappy, I guess, is my question?Ewere: Um, yeah. So, at the moment, I think, like you said, CloudWatch has really evolved over time. I personally also had that issue with CloudWatch when I started using CloudWatch; I had the challenge of usability, I had the challenge of proper integration, and I will talk about my first experience with CloudWatch here. So, when I started my infrastructure work, one of the things I was doing a lot was EC2, basically. I mean, everyone always starts with EC2 at the first time.And then we had a downtime. And then my CTO says, “Okay, [Ewere 00:04:00], check what's going on.” And I'm like, “How do I check?” [laugh]. I mean, I had no idea of what to do.And he says, “Okay, there's a tool called CloudWatch. You should be able to monitor.” And I'm like, “Okay.” I dive into CloudWatch, and boom, I'm confused again. And you look at the console, you see, it shows you certain metrics, and yet [people 00:04:18] don't understand what CPU metric talks about, what does network bandwidth talks about?And here I am trying to dig, and dig, and dig deeper, and I still don't get [laugh] a sense of what is actually going on. But what I needed to find out was, I mean, what was wrong with the memory of the system, so I delved into trying to install the CloudWatch agent, get metrics and all that. But the truth of the matter was that I couldn't really solve my problem very well, but I had [unintelligible 00:04:43] of knowing that I don't have memory out of the box; it's something that has to set up differently. And trust me, after then I didn't touch CloudWatch [laugh] again. Because, like you said, it was a problem, it was a bit difficult to work with.But fast forward a couple of years later, I could actually see someone use CloudWatch for a lot of beautiful stuff, you know? It creates beautiful dashboards, creates some very well-aggregated metrics. And also with the aggregated alarms that CloudWatch comes with, [unintelligible 00:05:12] easy for you to avoid what to call incident fatigue. And then also, the dashboards. I mean, there are so many dashboards that simplified to work with, and it makes it easy and straightforward to configure.So, the bootstrapping and the changes and the improvements on CloudWatch over time has made CloudWatch a go-to tool, and most especially the integration with containers and Kubernetes. I mean, CloudWatch is one of the easiest tools to integrate with EKS, Kubernetes, or other container services that run in AWS; it's just, more or less, one or two lines of setup, and here you go with a lot of beautiful, interesting, and insightful metrics that you will not get out of the box, and if you look at other monitoring tools, it takes a lot of time for you to set up, for you to configure, for you to consistently maintain and to give you those consistent metrics you need to know what's going on with your system from time to time.Corey: The problem I always ran into was that the traditional tools that I was used to using in data centers worked pretty well because you didn't have a whole lot of variability on an hour-to-hour basis. Sure, when you installed new servers or brought up new virtual machines, you had to update the monitoring system. But then you started getting into this world of ephemerality with auto-scaling originally, and later containers, and—God help us all—Lambda now, where it becomes this very strange back-and-forth story of, you need to be able to build something that, I guess, is responsive to that. And there's no good way to get access to some of the things that CloudWatch provides, just because we didn't have access into AWS's systems the way that they do. The inverse, though, is that they don't have access into things running inside of the hypervisor; a classic example has always been memory: memory usage is an example of something that hasn't been able to be displayed traditionally without installing some sort of agent inside of it. Is that still the case? Are there better ways of addressing those things now?Ewere: So, that's still the case, I mean, for EC2 instances. So before, now, we had an agent called a CloudWatch agent. Now, there's a new agent called Unified Cloudwatch Agent which is, I mean, a top-notch from CloudWatch agent. So, at the moment, basically, that's what happens on the EC2 layer. But the good thing is when you're working with containers, or more or less Kubernetes kind of applications or systems, everything comes out of the box.So, with containers, we're talking about a [laugh] lot of moving parts. The container themselves with their own CPU, memory, disk, all the metrics, and then the nodes—or the EC2 instance of the virtual machines running behind them—also having their own unique metrics. So, within the container world, these things are just a click of a button. Everything happens at the same time as a single entity, but within the EC2 instance and ecosystem, you still find this there, although the setup process has been a bit easier and much faster. But in the container world, that problem has totally been eliminated.Corey: When you take a look at someone who's just starting to get a glimmer of awareness around what CloudWatch is and how to contextualize it, what are the most common mistakes people make early on?Ewere: I also talked about this in my book, and one of the mistakes people make in terms of CloudWatch, and monitoring in generalities: “What am I trying to figure out?” [laugh]. If you don't have that answer clearly stated, you're going to run into a lot of problems. You need to answer that question of, “What am I trying to figure out?” I mean, monitoring is so broad, monitoring is so large that if you do not have the answer to that question, you're going to get yourself into a lot of trouble, you're going to get yourself into a lot of confusion, and like I said, if you don't understand what you're trying to figure out in the first place, then you're going to get a lot of data, you're going to get a lot of information, and that can get you confused.And I also talked about what I call alarm fatigues or incident fatigues. This happens when you configure so many alarms, so many metrics, and you're getting a lot of alarms hitting and notification services—whether it's Slack, whether it's an email—and it causes fatigue. What happens here is the person who should know what is going on with the system gets a ton of messages and in that scenario can miss something very important because there's so many messages coming in, so many integrations coming in. So, you should be able to optimize appropriately, to be able to, like you said, conceptualize what you're trying to figure out, what problems are you trying to solve? Most times you really don't figure this out for a start, but there are certain bare minimums you need to know about, and that's part of what I talked about in the book.One of the things that I highlighted in the book when I talked about monitoring of different layers is, when you're talking about monitoring of infrastructure, say compute services, such as virtual machines, or EC2 instances, the certain baseline and metrics you need to take note of that are core to the reliability, the scalability, and the efficiency of your system. And if you focus on these things, you can have a baseline starting point before you start going deeper into things like observability and knowing what's going on entirely with your system. So, baseline understanding of—baseline metrics, and baseline of what you need to check in terms of different kinds of services you're trying to monitor is your starting point. And the mistake people make is that they don't have a baseline. So, we do not have a baseline; they just install a monitoring tool, configure a CloudWatch, and they don't know the problem they're trying to solve [laugh] and that can lead to a lot of confusion.Corey: So, what inspired you from, I guess, kicking the tires on CloudWatch—the way that we all do—and being frustrated and confused by it, all the way to the other side of writing a book on it? What was it that got you to that point? Were you an expert on CloudWatch before you started writing the book, or was it, “Well, by the time this book is done, I will certainly know [laugh] more about the service than I did when I started.”Ewere: Yeah, I think it's a double-edged sword. [laugh]. So, it's a combination of the things you just said. So, first of all, I have experienced with other monitoring tools; I have love for reliability and scalability of a system. I started Kubernetes at some of the early times Kubernetes came out, when it was very difficult to deploy, when it was very difficult to set up.Because I'm looking at how I can make systems a little bit more efficient, a little bit more reliable than having to handle a lot of things like auto-scaling, having to go through the process of understanding how to scale. I mean, that's a school of its own that you need to prepare yourself for. So, first of all, I have a love for making sure systems are reliable and efficient, and second of all, I also want to make sure that I know what is going on with my system per time, as much as possible. The level of visibility of a system gives you the level of control and understanding of what your system is doing per time. So, those two things are very core to me.And then thirdly, I had a plan of a streak of books I want to write based on AWS, and just like monitoring is something that is just new. I mean, if you go to the package website, this is the first book on infrastructure monitoring AWS with CloudWatch; it's not a very common topic to talk about. And I have other topics in my head, and I really want to talk about things like networking, and other topics that you really need to go deep inside to be able to appreciate the value of what you see in there with all those scenarios because in this book, every chapter, I created a scenario of what a real-life monitoring system or what you need to do looks like. So, being that I have those premonitions, I know that whenever it came to, you know, to share with the world what I know in monitoring, what I've learned in monitoring, I took a [unintelligible 00:12:26]. And then secondly, as this opportunity for me to start telling the world about the things I learned, and then I also learned while writing the book because there are certain topics in the book that I'm not so much of an expert in things, like big data and all that.I had to also learn; I had to take some time to do more research, to do more understanding. So, I use CloudWatch, okay? I'm kind of good in CloudWatch, and also, I also had to do more learning to be able to disseminate this information. And also, hopefully, X-Ray some parts of monitoring and different services that people do not really pay so much attention into.Corey: What do you find that is still the most, I guess, confusing to you as you take a look across the ecosystem of the entire CloudWatch space? I mean, every time I play with it, I take a look, and I get lost in, “Oh, they have contributor analyses, and logs, and metrics.” And it's confusing, and every time I wind up, I guess, spiraling out of control. What do you find that, after all of this, is a lot easier for you, and what do you find that's a lot more understandable?Ewere: I'm still going to go back to the containers part. I'm sorry, I'm in love containers. [laugh].Corey: No, no, it's fair. Containers are very popular. Everyone loves them. I'm just basically anti-container based upon no better reason than I'm just stubborn and bloody-minded most of the time.Ewere: [laugh]. So, pretty much like I said, I kind of had experience with other monitoring tools. Trust me, if you want to configure proper container monitoring for other tools, trust me, it's going to take you at least a week or two to get it properly, from the dashboards, to the login configurations, to the piping of the data to the proper storage engine. These are things I talked about in the book because I took monitoring from the ground up. I mean, if you've never done monitoring before, when you take my book, you will understand the basic principles of monitoring.And [funny 00:14:15], you know, monitoring has some big data process, like an ETL process: extraction, transformation, and writing of data into an analytic system. So, first of all, you have to battle that. You have to talk about the availability of your storage engine. What are you using? An Elasticsearch? Are you using an InfluxDB? Where do you want to store your data? And then you have to answer the question of how do I visualize the data? What method do I realize this data? What kind of dashboards do I want to use? What methods of representation do I need to represent this data so that it makes sense to whoever I'm sharing this data with. Because in monitoring, you definitely have to share data with either yourself or with someone else, so the way you present the data needs to make sense. I've seen graphs that do not make sense. So, it requires some level of skill. Like I said, I've [unintelligible 00:15:01] where I spent a week or two having to set up dashboards. And then after setting up the dashboard, someone was like, “I don't understand, and we just need, like, two.” And I'm like, “Really?” [laugh]. You know? Because you spend so much time. And secondly, you discover that repeatability of that process is a problem. Because some of these tools are click and drag; some of them don't have JSON configuration. Some do, some don't. So, you discover that scalability of this kind of system becomes a problem. You can't repeat the dashboards: if you make a change to the system, you need to go back to your dashboard, you need to make some changes, you need to update your login, too, you need to make some changes across the layer. So, all these things is a lot of overhead [laugh] that you can cut off when you use things like Container Insights in CloudWatch—which is a feature of CloudWatch. So, for me, that's a part that you can really, really suck out so much juice from in a very short time, quickly and very efficiently. On the flip side, when you talk about monitoring for big data services, and monitoring for a little bit of serverless, there might be a little steepness in the flow of the learning curve there because if you do not have a good foundation in serverless, when you get into [laugh] Lambda Insights in CloudWatch, trust me, you're going to be put off by that; you're going to get a little bit confused. And then there's also multifunction insights at the moment. So, you need to have some very good, solid foundation in some of those topics before you can get in there and understand some of the data and the metrics that CloudWatch is presenting to you. And then lastly, things like big data, too, there are things that monitoring is still being properly fleshed out. Which I think that in the coming months and years to come, they will become more proper and they will become more presentable than they are at the moment.Corey: This episode is sponsored by our friends at Oracle HeatWave is a new high-performance accelerator for the Oracle MySQL Database Service. Although I insist on calling it “my squirrel.” While MySQL has long been the worlds most popular open source database, shifting from transacting to analytics required way too much overhead and, ya know, work. With HeatWave you can run your OLTP and OLAP, don't ask me to ever say those acronyms again, workloads directly from your MySQL database and eliminate the time consuming data movement and integration work, while also performing 1100X faster than Amazon Aurora, and 2.5X faster than Amazon Redshift, at a third of the cost. My thanks again to Oracle Cloud for sponsoring this ridiculous nonsense.Corey: The problem I've always had with dashboards is it seems like managers always want them—“More dashboards, more dashboards”—then you check the usage statistics of who's actually been viewing the dashboards and the answer is, no one since you demoed it to the execs eight months ago. But they always claim to want more. How do you square that?I guess, slicing between what people asked for and what they actually use.Ewere: [laugh]. So yeah, one of the interesting things about dashboards in terms of most especially infrastructure monitoring, is the dashboards people really want is a revenue dashboards. Trust me, that's what they want to see; they want to see the money going up, up, up, [laugh] you know? So, when it comes to—Corey: Oh, yes. Up and to the right, then everyone's happy. But CloudWatch tends to give you just very, very granular, low-level metrics of thing—it's hard to turn that into something executives care about.Ewere: Yeah, what people really care about. But my own take on that is, the dashboards are actually for you and your team to watch, to know what's going on from time to time. But what is key is setting up events across very specific and sensitive data. For example, when any kind of sensitive data is flowing across your system and you need to check that out, then you tie a metric to that, and in turn alarm to it. That is actually the most important thing for anybody.I mean, for the dashboards, it's just for you and your team, like I said, for your personal consumption. “Oh, I can see all the RDS connections are getting too high, we need to upgrade.” Oh, we can see that all, the memory, there was a memory spike in the last two hours. I know that's for you and your team to consume; not for the executive team. But what is really good is being able to do things like aggregate data that you can share.I think that is what the executive team would love to see. When you go back to the core principles of DevOps in terms of the DevOps Handbook, you see things like a mean time to recover, and change failure rate, and all that. The most interesting thing is that all these metrics can be measured only by monitoring. You cannot change failure rates if you don't have a monitoring system that tells you when there was a failure. You cannot know your release frequency when you don't have a metric that measures number of deployments you have and is audited in a particular metric or a particular aggregator system.So, we discovered that the four major things you measure in DevOps are all tied back to monitoring and metrics, at minimum, to understand your system from time to time. So, what the executive team actually needs is to get a summary of what's going on. And one of the things I usually do for almost any company I work for is to share some kind of uptime system with them. And that's where CloudWatch Synthetics Canary come in. So, Synthetic Canary is a service that helps you calculate that helps you check for uptime of the system.So, it's a very simple service. It does a ping, but it is so efficient, and it is so powerful. How is it powerful? It does a ping to a system and it gets a feedback. Now, if the status code of your service, it's not 200 or not 300, it considers it downtime.Now, when you aggregate this data within a period of time, say a month or two, you can actually use that data to calculate the uptime of your system. And that uptime [unintelligible 00:19:50] is something you can actually share to your customers and say, “Okay, we have an SLA of 99.9%. We have an SLA of 99.8%.” That data should not be doctored data; it should not be a data you just cook out of your head; it should be based on your system that you have used, worked with, monitored over a period of time so that the information you share with your customers are genuine, they are truthful, and they are something that they can also see for themselves.Hence companies are using [unintelligible 00:20:19] like status page to know what's going on from time to time whenever there is an incident and report back to their customers. So, these are things that executives will be more interested in than just dashboards, [laugh] dashboards, and more dashboards. So, it's more or less not about what they really ask for, but what you know and what you believe you are going to draw value from. I mean, an executive in a meeting with a client and says, “Hey, we got a system that has 99.9% uptime.”He opens the dashboard or he opens the uptime system and say, “You see our uptime? For the past three months, this has been our metric.” Boom. [snaps fingers]. That's it. That's value, instantly. I'm not showing [laugh] the clients and point of graphs, you know? “Can you explain the memory metric?” That's not going to pass the message, send the message forward.Corey: Since your book came out, I believe, if not, certainly by the time it was finished being written and it was in review phase, they came out with Managed Prometheus and Managed Grafana. It looks almost like they're almost trying to do a completely separate standalone monitoring stack of AWS tooling. Is that a misunderstanding of what the tools look like, or is there something to that?Ewere: Yeah. So, I mean by the time those announced at re:Invent, I'm like, “Oh, snap.” I almost told my publisher, “You know what? We need to add three more chapters.” [laugh]. But unfortunately, we're still in review, in preview.I mean, as a Hero, I kind of have some privilege to be able to—a request for that, but I'm like, okay, I think it's going to change the narrative of what the book is talking about. I think I'm going to pause on that and make sure this finishes with the [unintelligible 00:21:52], and then maybe a second edition, I can always attach that. But hey, I think there's trying to be a galvanization between Prometheus, Grafana, and what CloudWatch stands for. Because at the moment, I think it's currently on pre-release, it's not fully GA at the moment, so you can actually use it. So, if you go to Container Insights, you can see that you can still get how Prometheus and Grafana is presenting the data.So, it's more or less a different view of what you're trying to see. It's trying to give you another perspective of how your data is presented. So, you're going to have CloudWatch: it's going to have CloudWatch dashboards, it's going to have CloudWatch metrics, but hey, this different tools, Prometheus, Grafana, and all that, they all have their unique ways of presenting the data. And part of the reason I believe AWS has Prometheus and Grafana there is, I mean, Prometheus is a huge cloud-native open-source monitoring, presentation, analytics tool; it packs a lot of heat, and a lot of people are so used to it. Everybody like, “Why can't I have Prometheus in CloudWatch?”I mean—so instead of CloudWatch just being a simple monitoring tool, [unintelligible 00:22:54] CloudWatch has become an ecosystem of monitoring tool. So, we got—we're not going to see cloud [unintelligible 00:23:00], or just [unintelligible 00:23:00] log, analytics, metrics, dashboards, no. We're going to see it as an ecosystem where we can plug in other services, and then integrate and work together to give us better performance options, and also different perspectives to the data that is being collected.Corey: What do you think is next, as you take a look across the ecosystem, as far as how people are thinking about monitoring and observability in a cloud context? What are they missing? Where's the next evolution lead?Ewere: Yeah, I think the biggest problem with monitoring, which is part of the introduction part of the book, where I talked about the basic types of monitoring—which is proactive and reactive monitoring—is how do we make sure we know before things happen? [laugh]. And one of the things that can help with that is machine learning. There is a small ecosystem that is not so popular at the moment, which talks about how we can do a lot of machine learning in DevOps monitoring observability. And that means looking at historic data and being able to predict on the basic level.Looking at history, [then are 00:24:06] being able to predict. At the moment, there are very few tools that have models running at the back of the data being collected for monitoring and metrics, which could actually revolutionize monitoring and observability as we see it right now. I mean, even the topic of observability is still new at the moment. It's still very integrated. Observability just came into Cloud, I think, like, two years ago, so it's still being matured.But one thing that has been missing is seeing the value AI can bring into monitoring. I mean, this much [unintelligible 00:24:40] practically tell us, “Hey, by 9 p.m. I'm going to go down. I think your CPU or memory is going down. I think I'm line 14 of your code [laugh] is a problem causing the bug. Please, you need to fix it by 2 p.m. so that by 6 p.m., things can run perfectly.” That is going to revolutionize monitoring. That's going to revolutionize observability and bring a whole new level to how we understand and monitor the systems.Corey: I hope you're right. If you take a look right now, I guess, the schism between monitoring and observability—which I consider to be hipster monitoring, but they get mad when I say that—is there a difference? Is it just new phrasing to describe the same concepts, or is there something really new here?Ewere: In my book, I said, monitoring is looking at it from the outside in, observability is looking at it from the inside out. So, what monitoring does not see under, basically, observability sees. So, they are children of the same mom. That's how I put it. One actually needs the other and both of them cannot be separated from each other.What we've been working with is just understanding the system from the surface. When there's an issue, we go to the aggregated results that come out of the issue. Very basic example: you're in a Java application, and we all know Java is very memory intensive, on the very basic layer. And there's a memory issue. Most times, infrastructure is the first hit with the resultant of that.But the problem is not the infrastructure, it's maybe the code. Maybe garbage collection was not well managed; maybe they have a lot of variables in the code that is not used, and they're just filling up unnecessary memory locations; maybe there's a loop that's not properly managed and properly optimized; maybe there's a resource on objects that has been initialized that has not been closed, which will cause a heap in the memory. So, those are the things observability can help you track. Those are the things that we can help you see. Because observability runs from within the system and send metrics out, while basic monitoring is about understanding what is going on on the surface of the system: memory, CPU, pushing out logs to know what's going on and all that.So, on the basic level, observability helps gives you, kind of, a deeper insight into what monitoring is actually telling you. It's just like the result of what happened. I mean, we are told that the symptoms of COVID is coughing, sneezing, and all that. That's monitoring. [laugh].But before we know that you actually have COVID, we need to go for a test, and that's observability. Telling us what is causing the sneezing, what is causing the coughing, what is causing the nausea, all the symptoms that come out of what monitoring is saying. Monitoring is saying, “You have a cough, you have a runny nose, you're sneezing.” That is monitoring. Observability says, “There is a COVID virus in the bloodstream. We need to fix it.” So, that's how both of them act.Corey: I think that is probably the most concise and clear definition I've ever gotten on the topic. If people want to learn more about what you're up to, how you view about these things—and of course, if they want to buy your book, we will include a link to that in the [show notes 00:27:40]—where can they find you?Ewere: I'm on LinkedIn; I'm very active on LinkedIn, and I also shared the LinkedIn link. I'm very active on Twitter, too. I tweet once in a while, but definitely, when you send me a message on Twitter, I'm also going to be very active.I also write blogs on Medium, I write a couple of blogs on Medium, and that was part of why AWS recognized me as a Hero because I talk a lot about different services, I help with comparing services for you so you can choose better. I also talk about setting basic concepts, too; if you just want to get your foot wet into some stuff and you need something very summarized, not AWS documentation per se, something that you can just look at and know what you need to do with the service, I talk about them also in my blogs. So yeah, those are the two basic places I'm in: LinkedIn and Twitter.Corey: And we will, of course, put links to that in the [show notes 00:28:27]. Thank you so much for taking the time to speak with me. I appreciate it.Ewere: Thanks a lot.Corey: Ewere Diagboya, head of cloud at My Cloud Series. 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 hated this podcast, please leave a five-star review on your podcast platform of choice along with a comment telling me how many more dashboards you would like me to build that you will never look at.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.

My guest today is Genelle Aldred, newsreader, communication expert, and now author who has worked as a journalist at many of the UK largest broadcasting organisations for over a decade, including BBC, ITV and ITN. In this episode we discuss her debut book Communicate for Change: Creating Justice in a World of Bias unpicking some of its fascinating themes: how to make a positive difference, how to think for yourself, how to have better conversations and how to recognise our own biases and blind spots. This book encouraged me to ask better questions and question my own assumptions, breaking away from singular narratives and monolithic thinking. Hope you enjoy this conversation about how it's OK to agree to disagree in conversation and how it's important to not shy away from other peoples truth in order to see how other people around us think. Here is the episode with Genelle!Grab a copy of her book here: https://uk.bookshop.org/a/153/9780281085576Say hello!- My books: https://uk.bookshop.org/lists/my-books-90e08b32-dafc-4517-843a-a7c0cecde865- Twitter: Twitter.com/emmagannon- Instagram: Instagram.com/emmagannonuk See acast.com/privacy for privacy and opt-out information.

The Context of White Supremacy welcomes June BlueSpruce and Lisa Iverson. Gus was frolicking in Seattle's posh Green Lake area, when he stumbled on a flier for group discussion titled: "Whiteness Is Not An Ancestor: book study and reflection." The two session event would be led by June BlueSpruce, a White Woman. She lives in the Seattle area and penned one of the essays in the book, which features 12 separate reports from White Women. The collection was edited by Lisa Iverson, also a White Woman. We'll discuss their motivations for this project, and the results of their recent zoom project. We'll explore what it means to be White, and Ms. BlueSpruce's connections to the #MedicalApartheid industry and the Oakland Black Panther Party. #WhiteCultureIsWhiteTerrorism http://paypal.me/TheCOWS Cash App: https://cash.app/$TheCOWS CALL IN NUMBER: 720.716.7300 CODE 564943#

As we get ready to launch our Impact Initiative, we want to give you a little context regarding what has led us to this point.

BASELINE 10.13.21CONTEXT #Daily #Moon, #Sun, #SchumannResonance, #Crypto, #USA, #Global, and #Spirit #News under 140 seconds.Brought to you by Phireon.com“The Choice is Yours”T.me/Phireon“Liberty is the New Punk”

About TimTim's tech career spans over 20 years through various sectors. Tim's initial journey into tech started as a US Marine. Later, he left government contracting for the private sector, working both in large corporate environments and in small startups. While working in the private sector, he honed his skills in systems administration and operations for largeUnix-based datastores.Today, Tim leverages his years in operations, DevOps, and Site Reliability Engineering to advise and consult with clients in his current role. Tim is also a father of five children, as well as a competitive Brazilian Jiu-Jitsu practitioner. Currently, he is the reigning American National and 3-time Pan American Brazilian Jiu-Jitsu champion in his division.Links: Twitter: https://twitter.com/elchefe The Duckbill Group: https://duckbillgroup.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 Honeycomb. When production is running slow, it's hard to know where problems originate: is it your application code, users, or the underlying systems? I've got five bucks on DNS, personally. Why scroll through endless dashboards, while dealing with alert floods, going from tool to tool to tool that you employ, guessing at which puzzle pieces matter? Context switching and tool sprawl are slowly killing both your team and your business. You should care more about one of those than the other, which one is up to you. Drop the separate pillars and enter a world of getting one unified understanding of the one thing driving your business: production. With Honeycomb, you guess less and know more. Try it for free at Honeycomb.io/screaminginthecloud. Observability, it's more than just hipster monitoring.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. Periodically, I have a whole bunch of guests come on up, second time. Now, it's easy to take the naive approach of assuming that it's because it's easier for me to find a guest if I know them and don't have to reach out to brand new people all the time. This is absolutely correct; I'm exceedingly lazy. But I don't have too many folks on a third time, but that changes today.My guest is Tim Banks. I've had him on the show twice before, both times it led to really interesting conversations around a wide variety of things. Since those episodes, Tim has taken the job as a principal cloud economist here at The Duckbill Group. Yes, that is probably the strangest interview process you can imagine, but here we are. Tim, thank you so much for joining me both on the show and in the business.Tim: My pleasure, Corey. It was definitely an interesting interview process, you know, but I was glad to be here. So, I'm happy to be here a third time. I don't know if you get a jacket like you do in Saturday Night Live, if you host, like, a fifth time, but we'll see. Maybe it's a vest. A cool vest would be nice.Corey: We can come up with something.[ effectively, it can be like reverse hangman where you wind up getting a vest and every time you come on after that you get a sleeve, then you get a second sleeve, and then you get a collar, and we can do all kinds of neat stuff.Tim: I actually like that idea a lot.Corey: So, I'm super excited to be able to have this conversation with you because I don't normally talk a lot on this show about what cloud economics is because my guest usually is not as deep into the space as I am, and that's fine; people should never be as deep into this space as I am, in the general sense, unless they work here. Awesome. But I do guest on other shows, and people ask me all kinds of questions about AWS billing and cloud economics, and that's fine, it's great, but they don't ask the questions about the space in the same way that I would and the way that I think about it. So, it's hard for me to interview myself. Now, I'm not saying I won't try it someday, but it's challenging. But today, I get to take the easy path out and talk to you about it. So Tim, what the hell is a principal cloud economist?Tim: So, a principal cloud economist, is a cloud computing expert, both in architecture and practice, who looks at cloud cost in the same way that a lot of folks look at cloud security, or cloud resilience, or cloud performance. So, the same engineering concerns you have about making sure that your API stays up all the time, or to make sure that you don't have people that are able to escape containers or to make sure that you can have super, super low response times, is the same engineering fundamentals that I look at when I'm trying to find a way to reduce your AWS bill.Corey: Okay. When we say cloud cost and cloud economics, the natural picture that leads to mind is, “Oh, I get it. You're an Excel jockey.” And sometimes, yeah, we all kind of play those roles, but what you're talking about is something else entirely. You're talking about engineering expertise.And sure enough, if you look at the job postings we have for roles on the team from time to time, we have not yet hired anyone who does not have an engineering and architecture background. That seems odd to folks who do not spend a lot of time thinking about the AWS bill. I'm told those people are what is known as ‘happy.' But here we are. Why do we care about the engineering aspect of any of this?Tim: Well, I think first and foremost because what we're doing in essence, is still engineering. People aren't putting construction paper up on [laugh] AWS; sometimes they do put recipes up on there, but it still involves working on a computer, and writing code, and deploying it somewhere. So, to have that basic understanding of what it is that folks are doing on the platform, you have to have some engineering experience, first and foremost. Secondly, the fact of the matter is that most cost optimization, in my opinion, can be done on the whiteboard, before anything else, and really I think should be done on the whiteboard before anything else. And so the Excel aspect of it is always reactive. “We have now spent this much. How much was it? Where did it go?” And now we have to figure out where it went.I like to figure out and get a ballpark on how much something is going to cost before I write the first line of code. I want to know, hey, we have a tier here, we're using this kind of storage, it's going to take this kind of instance types. Okay, well, I've got an idea of how much it's going to cost. And I was like, “You know, that's going to be expensive. Before we do anything, is there a way that we can reduce costs there?”And so I'm reverse engineering that on already deployed workloads. Or when customers want to say, “Hey, we were thinking about doing this, and this is our proposed architecture,” I'm going to look at it and say, “Well, if you do this and this and this and this, you can save money.”Corey: So, it sounds like you and I have a bit of a philosophical disagreement in some ways. One of my recurring talking points has always been that, “Oh, by and large, application developers don't need to think overly much about cloud cost. What they need to know generally fits on an index card.” It's, okay, big things cost more than small things; if you turn something on, it will never get turned off and will bill you in perpetuity; data transfer has some weird stuff; and if you store data, you pay for data, like, that level of baseline understanding. When I'm trying to build something out my immediate thought is, great, is this thing possible?Because A, I don't always know that it is, and B, I'm super bad at computers so for me, it may absolutely not be, whereas you're talking about baking cost assessments into the architecture as a day one type of approach, even when sketching ideas out on the whiteboard. I'm curious as to how we diverge there. Can you talk more about your philosophy?Tim: Sure. And the reason I do that is because, as most folks that have an engineering background in cloud infrastructure will tell you, you want to build resilience in, on the whiteboard. You certainly want to build performance in, on the whiteboard, right? And security folks will tell you you want to do security on the whiteboard. Because those things are hard to fix after they're deployed.As soon as they're deployed, without that, you now have technical debt. If you don't consider cost optimization and cost efficiency on the whiteboard, and then you try and do it after it's deployed, you not only have technical debt, you may have actual real debt.Corey: One of the comments I tend to give a lot is that architecture and cost are the same thing in the world of cloud. And I think that we might be in violent agreement, as Liz Fong-Jones is fond of framing it, where I am acutely aware of aspects of cost and that does factor into how I build things on the whiteboard—let's also be very clear, most of the things that I build are very small scale; the largest cost by a landslide is the time I spend building it—in practice, that's an awful lot of environments; people are always more expensive than the AWS environment they're working on. But instead, it's about baking in the assumptions and making sure you're not coming up with something that is going to just be wasteful and horrible out of the gate, and I guess part of that also is the fact that I am at a level of billing understanding that I sort of absorbed these concepts intrinsically. Because to me, there is no difference between cost and architecture in an environment like this. You're right, there's always an inherent trade-off between cost and durability. On the one hand, I don't like that. On the other, it feels like it's been true forever and I don't see a way out of it.Tim: It is inescapable. And it's interesting because you talk about the level of an application developer or something like that, like what is your level of concern, but retroactively, we'll go in for cost optimization houses—and I've done this as far back as when I was working at AWS has a TAM—and I'll ask the question to an application developer or database administrator, and I'm like, “Why do you do this? What do you have a string value for something that could be a Boolean?” And you'll ask, “Well, what difference does that make?” Well, it makes a big difference when you're talking about cycles for CPU.You can reduce your CPU consumption on a database instance by changing a string to a Boolean, you need fewer instances, or you need a less powerful instance, or you need less memory. And now you can run a less expensive instance for your database architecture. Well, maybe for one node it's not that biggest difference, but if you're talking about something that's multi-AZ and multi-node, I mean, that can be a significant amount of savings just by making one simple change.Corey: And that might be the difference right there. I didn't realize that, offhand. It makes sense if you think about it, but just realizing that I've made that mistake on one of my DynamoDB tables. It costs something like seven cents a month right now, so it's not something I'm rushing to optimize, but you're right, expand that out by a factor of a million or so, and we're talking serious money, and then that sort of optimization makes an awful lot of sense. I think that my position on it is that when you're building out something small scale as a demo or a proof of concept, spending time on optimizations like this is not the best use of anyone's time or brain sweat, for lack of a better term. How do you wind up deciding when it's time to focus on stuff like that?Tim: Well, first, I will say that—I daresay that somewhere in the 80% of production workloads are just—were the POC, [laugh] right? Because, like, “It worked for this to get funding, let's run it,” right?Corey: Let they who does not have a DynamoDB table in production with the word ‘test' or ‘dev' in it cast the first stone.Tim: It's certainly not me. So, I understand how some of those decisions get made. And that's why I think it's better to think about it early. Because as I mentioned before, when you start something and say, “Hey, this works for now,” and you don't give consideration to that in the future, or consideration for what it's going to be like in the future, and when you start doing it, you'll paint yourself into corners. That's how you get something like static values put in somewhere, or that's how you get something like, well, “We have to run this instance type because we didn't build in the ability to be more microservice-based or stateless or anything like that.”You've seen people that say, “Hey, we could save you a lot of money if you can move this thing off to a different tier.” And it's like, “Well, that would be an extensive rewrite of code; that'd be very expensive.” I daresay that's the main reason why most AS/400s are still being used right now is because it's too expensive to rewrite the code.Corey: Yeah, and there's no AWS/400 that they can migrate to. Yet. Re:Invent is nigh.Tim: So, I think that's why, even at the very beginning, even if you were saying, “Well, this is something we will do later.” Don't make it impossible for you to do later in your code. Don't make it impossible for you to do later in your architecture. Make things as modular as possible, so that way you can say, “Hey”—later on down the road—“Oh, we can switch this instance type.” Or, “Here's a new managed service that we can maybe save money on doing this.”And you allow yourself to switch things out, or turn different knobs, or change the way you do things, and give yourself more options in the future, whether those options are for resilience, or those options or for security, or those options are for performance, or they're for cost optimizations. If you make binding decisions earlier on, you're going to have debt that's going to build up at some point in the future, and then you're going to have to pay the piper. Sometimes that piper is going to be AWS.Corey: One thing that I think gets lost in a lot of conversations about cloud economics—because I know that it happened to me when I first started this place—where I am planning to basically go out and be the world's leading expert in AWS cost analysis and understanding and optimization. Great. Then I went out into the world and started doing some of my first engagements, and they looked a lot less like far-future cost attribution projections and a lot more like, “What's a reserved instance?” And, “We haven't bought any of those in 18 months.” And, “Oh, yeah, we shut down an entire project six months ago. We should probably delete all the resources, huh?”The stuff that I was preparing for at the high end of the maturity curve are great and useful and terrific to have conversations about in some very nuanced depth, but very often there's a walk before you can run style of conversation where, okay, let's do the easy stuff first before we start writing a whole bunch of bespoke internal stuff that maps your business needs to the AWS bill. How do you, I guess, reconcile those things where you're on the one hand, you see the easy stuff and on the other, you see some of the just the absolutely challenging, very hard, five-years-of-engineering-effort-style problems on the other?Tim: Well, it's interesting because I've seen one customer very recently who has brilliant analyses as to their cost; just well-charted, well-tagged, well-documented, well—you know, everything is diagrammed quite nicely and everything like that, and they're very, very aware of their costs, but they leave test instances running all weekend, you know, and their associated volumes and things like that. And that's a very easy thing to fix. That is a very, very low-hanging fruit. And so sometimes, you just have to look at where they're spending their efforts where sometimes they do spend so much time chasing those hard to do things because they are hard to do and they're exciting in an engineering aspect, and then something as simple as, “Hey, how about we delete these old volumes?” It just isn't there.Or, “How about we switch to your S3 bucket storage type?” Those are easy, low-hanging fruits, and you would be surprised how sometimes they just don't get that. But at the same time, sometimes customers have, like, “Hey, we could knock this thing out, we knock this thing out,” because it's Trusted Advisor. Every AI cost optimization recommendation you can get will tell you these five things to do, no matter who you are or where you are, but they don't do the conceptual things like understanding some of the principles behind cost optimization and cost optimization architecture, and proactive cost optimization versus react with cost optimizations. So, you're doing very conceptual education and conversations with folks rather than the, “Do these five things.” And I've not often found a customer that you have to do both on; it's usually one or the other.Corey: It's funny that you made that specific reference to that example. One of my very first projects—not naming names. Generally, when it comes to things like this, you can tell stories or you can name names; I bias for stories—I was talking to a company who was convinced that their developer environments were incredibly overwrought, expensive, et cetera, and burning money. Okay, great. So, I talked about the idea of turning those things off at night or between test runs, deleting volumes to snapshot, and restore them on a schedule when people come in in the morning because all your developers sit in the same building in the same time zones. Great. They were super on board with the idea, and it was going to be a little bit of work, but all right, this was in the days before the EC2 Instance Scheduler, for example.But first, let's go ahead and do some analysis. This is one of those early engagements that really reinforced my idea of, yeah, before we start going too far down the rabbit hole, let's double-check what's going on in the account. Because periodically you encounter things that surprise people. Like, “What's up with those Australia instances?” “Oh, we don't have anything in that region.” “I believe you're being sincere when you say this, however, the API generally doesn't tell lies.”So, that becomes a, oh, security incident time. But looking at this, they were right; they had some fairly sizable developer instances that were running all the time, but doing some analysis, their developer environment was 3% of their bill at the time and they hadn't bought RIs in a year-and-a-half. And looking at what they were doing, there was so much easier stuff that they could do to generate significant savings without running the potential of turning a developer environment off at night in the middle of an incident or something like that. The risk factor and effort were easier just do the easy stuff, then do another pass and look at the deep stuff. And to be clear, they weren't lying to me; they weren't wrong.Back when they started building this stuff out, their developer environments were significantly large and were a significant portion of their spend. And then they hit product-market fit, and suddenly their production environment had to scale significantly in a short period of time. Which, yay, cloud. It's good at that. Then it just became such a small portion that developer environments weren't really a thing. But the narrative internally doesn't get updated very often because once people learn something, they don't go back to relearn whether or not it's still true. It's a constant mistake; I make it myself frequently.Tim: I think it's interesting, there are things that we really need to put into buckets as far as what's an engineering effort and what's an administrative effort. And when I say ‘administrative effort,' I mean if I can save money with a stroke of a pen, well, that's going to be pretty easy, and that's usually going to be RIs; that's going to be EDPs, or PPAs or something like that, that don't require engineering effort. It just requires administrative effort, I think RIs being the simplest ones. Like, “Oh, all I have to do is go in here and click these things four times and I'm going to save money?” “Well, let's do that.”And it's surprising how often people don't do that. But you still have to understand that, and whether it's RIs or whether it's a savings plan, it's still a commitment of some kind, but if you are willing to make that commitment, you can save money with no engineering effort whatsoever. That's almost free money.Corey: So, much of what we do here comes down to psychology, in many ways, more than it does math. And a lot of times you're right, everything you say is right, but in a large-scale environment, go ahead and click that button to buy the savings plan or the reserved instance, and that's a $20 million purchase. And companies will stall for months trying to run a different series of analyses on this and what if this happens, what if that happens, and I get it because, “Yeah, I'm going to click this button that's going to cost more money than I'll make in my lifetime,” that's a scary thing to do; I get it. But you're going to spend the money, one way or the other, with the provider, and if you believe that number is too high, I get it; I am right there with you. Buy half of them right now and then you can talk about the rest until you get to a point of being comfortable with it.Do it incrementally; it's not all or nothing, you have one shot to make the buy. Take pieces out of it that makes sense. You know you're probably not going to turn off your database cluster that handles all of production in the next year, so go ahead and go for it; it saves some money. Do the thing that makes sense. And that doesn't require deep-dive analytics that requires, on some level, someone who's seen a lot of these before who gets what customers are going through. And honestly, it's empathy in many respects, becomes one of those powerful things that we can apply to our customer accounts.Tim: Absolutely. I mean, people don't understand that decision paralysis, about making those commitments costs you money. You can spend months doing analysis, but those months doing analysis, you're going to spend 30, 40, 50, 60, 70% more on your EC2 instances or other compute than you would otherwise, and that can be quite significant. But it's one of those cases where we talk about psychology around perfect being the enemy of good. You don't have to make the perfect purchase of RIs or savings plans and have that so tuned perfectly that you're going to get one hundred percent utilization and zero—like, you don't have to do that.Just do something. Do a little bit. Like you said, buy half; buy anything; just something, and you're going to save money. And then you can run analysis later on, while you're saving money [laugh] and get a little better and tune it up a little more and get more analysis on and maybe fine-tune it, but you don't actually ever need to have it down to the penny. Like, it never has to be that good.Corey: At some point, one of the value propositions we have for our customers has always been that we tell you when to stop focusing on saving money because there's a theoretical cap of a hundred percent of the cloud bill that you can save, but you can make so much more than that by launching the right feature to the right market a little sooner; focus on that. Be responsible stewards of the money that's invested with you, but by and large, as a general piece of guidance, at some point, stop cutting and go back to doing the thing that makes your company work. It's not all about saving money at all costs for almost all of us. It is for us, but we're sort of a special case.Tim: Well, it's a conversation I often have. It's like, all right, are you trying to save money on AWS or are you trying to save money overall? So, if you're going to spend $400,000 worth of engineering effort to save $10,000 on your AWS bill, that doesn't make no sense. So—[laugh]—Corey: Right. There has to be a strategic reason to do things like that—Tim: Exactly.Corey: —and make sure you understand the value of what you're getting for this. One reason that we wind up charging the way that we do—and we've gotten questions on this for a while—has been that we charge a fixed fee for what we do on engagements. And similarly—people have asked this, but haven't tied the two things together—you talk about cost optimization, but never cost-cutting. Why is that? Is that just a negative term?And the answer has been no, they're aligned. What we do focuses on what is best for the customer. Once that fixed fee is decided upon, every single thing that we say is what we would do if we were in the customer's position. There are times we'll look at what they have going on and say, “Ah, you really should spend more money here for resiliency, or durability,” or, “Okay, that is critical data that's not being backed up. You should consider doing that.”It's why we don't take percentages of things because, at that point, we're not just going with the useful stuff, it's, well we're going to basically throw the entire kitchen sink at you. We had an early customer and I was talking to their AWS account manager about what we were going to be doing and their comment was, “Oh, saving money on AWS bills is great, make sure you check the EBS snapshots.” Yeah, I did that. They were spending 150 bucks a month on EBS snapshots, which is basically nothing. It's one of those stories where if, in the course of an hour-long meeting, I can pay for that entire service, by putting a quarter on the table, I'm probably not going to talk about it barring [laugh] some extenuating circumstances.Focus on the big things, not the things that worked in a different environment with a different account and different constraints. It's hard to context switch like that, but it gets a lot easier when it is basically the entirety of what we do all day.Tim: The difference I draw between cost optimization and cost-cutting is that cost optimization is ensuring that you're not spending money unnecessarily, or that you're maximizing your dollar. And so sometimes we get called in there, and we're just validation for the measures they've already done. Like, “Your team is doing this exactly right. You're doing the things you should be doing. We can nitpick if you want to; we're going to save you $7 a year, but who cares about that? But y'all are doing what you should be doing. This is great. Going forward, you want to look for these things and look for these things and look for these things. We're going to give you some more concepts so that you are cost-optimized in the future.” But it doesn't necessarily mean that we have to cut your bill. Because if you're already spending efficiently, you don't need your bill cut; you're already cost-optimized.Corey: Oh, we're not going to nitpick on that, you're mostly optimized there. It's like, “Yeah, that workload's $140 million a year and rising; please, pick nits.” At which point? “Okay, great.” That's the strategic reason to focus on something. But by and large, it comes down to understanding what the goals of clients are. I think that is widely misunderstood about what we do and how we do it.The first question I always ask when someone does outreach of, “Hey, we'd like to talk about coming in here and doing a consulting engagement with us.” “Great.” I always like to ask the quote-unquote, “Foolish question” of, “Why do you care about the AWS bill?” And occasionally I'll get people who look at me like I have two heads of, “Why wouldn't I care about the AWS bill?” Because there are more important things to care about for the business, almost certainly.Tim: One of the things I try and do, especially when we're talking about cost optimization, especially trying to do something for the right now so they can do things going forward, it's like, you know, all right, so if we cut this much from your bill—if you just do nothing else, but do reserved instances or buy a savings plan, right, you're going to save enough money to hire four engineers. Think about what four engineers would do for your overall business? And that's how I want you to frame it; I want you to look at what cost optimization is going to allow you to do in the future without costing you any more money. Or maybe you save a little more money and you can shift it; instead of paying for your AWS bill, maybe you can train your developers, maybe you can get more developers, maybe you can get some ProServ, maybe you can do whatever, buy newer computers for your people so they can do—whatever it is, right? We're not saying that you no longer have to spend this money, but saying, “You can use this money to do something other than give it to Jeff Bezos.”Corey: This episode is sponsored in part by Liquibase. If you're anything like me, you've screwed up the database part of a deployment so severely that you've been banned from touching every anything that remotely sounds like SQL, at at least three different companies. We've mostly got code deployments solved for, but when it comes to databases we basically rely on desperate hope, with a roll back plan of keeping our resumes up to date. It doesn't have to be that way. Meet Liquibase. It is both an open source project and a commercial offering. Liquibase lets you track, modify, and automate database schema changes across almost any database, with guardrails to ensure you'll still have a company left after you deploy the change. No matter where your database lives, Liquibase can help you solve your database deployment issues. Check them out today at liquibase.com. Offer does not apply to Route 53.Corey: There was an article recently, as of the time of this recording, where Pinterest discussed what they had disclosed in one of their regulatory filings which was, over the next eight years, they have committed to pay AWS $3.2 billion. And in this article, they have the head of engineering talking to the reporter about how they're thinking about these things, how they're looking at things that are relevant to their business, and they're talking about having a dedicated team that winds up doing a whole bunch of data analysis and running some analytics on all of these things, from piece to piece to piece. And that's great. And I worry, on some level, that other companies are saying, “Oh, Pinterest is doing that. We should, too.” Yeah, for the course of this commitment, a 1% improvement is $32 million, so yeah, at that scale I'm going to hire a team of data scientists, too, look at these things. Your bill is $50,000 a month. Perhaps that's not worth the effort you're going to put into it, barring other things that contribute to it.Tim: It's interesting because we will get folks that will approach us that have small accounts—very small, small spend—and like, “Hey, can you come in and talk to us about this whatever.” And we can say very honestly, “Look, we could, but the amount of money we're going to charge you is going to—it's not going to be worth your while right now. You could probably get by on the automated recommendations, on the things that already out there on the internet that everybody can do to optimize their bill, and then when you grow to a point where now saving 10% is somebody's salary, that's when it, kind of, becomes more critical.” And it's hard to say what point that is in anyone's business, but I can say sometimes, “Hey, you know what? That's not really what you need to focus on.” If you need to save $100 a month on your AWS bill, and that's critical, you've got other concerns that are not your AWS bill.Corey: So, back when you were interviewing to work here, one of the areas of focus that you kept bringing up was the concept of observability, and my response to this was, “Ah, hell. Another one.” Because let's be clear, Mike Julian—my business partner and our CEO—has written a book called Practical Monitoring, and apparently what we learned from this is as soon as you finish writing a book on the topic, you never want to talk about that topic ever again, which yeah, in hindsight makes sense. Why do you care about observability when you're here to look at cloud costs?Tim: Because cloud costs is another metric, just like you would use for performance, or resilience, or security. You do real-time monitoring to see if somebody has compromised the system, you do real-time monitoring to see if you have bad performance, if response times are too slow. You do real-time monitoring to know if something has gone down and then you need to make adjustments, or that the automated responses you have in response to that downtime are working. But cloud costs, you send somebody a report at the end of the month. Can you imagine, if you will—just for a second—if you got a downtime report at the end of month, and then you can react to something that has gone down?Or if you get a security report at the end of the month, and then you can react to the fact that somebody has your root keys? Or if you get [laugh] a report at the end of month, this said, “Hey, the CPU on this one was pegged. You should probably scale up.” That's outrageous to anybody in this industry right now. But why do we accept that for cloud cost?Corey: It's worse than that. There are a number of startups that talk about, “Oh, real-time cloud cost monitoring. Okay, the only way you're going to achieve such a thing is if you build an API shim that interprets everything that you're telling your cloud control plane to do, taking cost metrics out of it, and then passing it on to the actual cloud control plane.” Otherwise, you're talking about it showing up in the billing record in—ideally, eight hours; in practice, several days, or you're talking about the CloudTrail events, which is not holistic but gives you some rough idea, but it's also in some cases, 5 to 20 minutes delayed. There's no real-time way to do this without significant disruption to what's going on in your environment.So, when I hear about, “Oh, we do real-time bill analysis.” Yeah, it feels—to be very direct—you don't know enough about the problem space you're working within to speak intelligently about it because anyone who's played in this space for a while knows exactly how hard it is to get there. Now, I've talked to companies that have built real-time-ish systems that take that shim approach and acts sort of as a metadata sidecar ersatz billing system that tracks all of this so they can wind up intercepting potentially very expensive configuration mistakes. And that's great. That's also a bit beyond for a lot of folks today, but it's where the industry is going. But there is no way to get there today, short of effectively intercepting all of those calls, in a way that is cohesive and makes sense. How do you square that circle given the complete lack of effective tooling?Tim: Honestly, I'm going to point that right back at the cloud provider because they know how much you're spending, real-time. They know exactly how much you spend in real-time. They've figured it out. They have the buckets, they have APIs for it internally. I'm sure they do; it would make no sense for them not to. Without giving anything anyway, I know that when I was at AWS, I knew how much they were spending, almost real-time.Corey: That's impressive. I wish that existed. My never having worked at AWS perspective on it is that they, of course, have the raw data effective immediately, or damn close to it, but the challenge for the billing system is distilling and summarizing and attributing all of that in a reasonable timeframe; it is an exabyte-scale problem. I've talked to folks there who have indicated it is comfortably north of a petabyte in raw data per day. And that was a couple of years ago, so one can only imagine as the footprint has increased, so has all of this.I mean, the billing system is fundamentally magic from the outside. I'm not saying it's good magic, but it is magic, and it's something that is unappreciated, that every customer uses, and is one of those areas that doesn't get the attention it deserves. Because, let's be clear, here, we talk about observability; the bill is still the only thing that AWS offers that gives you a holistic overview of everything running in your account, in one place.Tim: What I think is interesting is that you talk about this, the scale of the problem and that it makes it difficult to solve. At the same time, I can have a conversation with my partner about kitty litter, and then all of a sudden, I'm going to start getting ads about kitty litter within minutes. So, I feel like it's possible to emit cost as a metric like you would CPU or disk. And if I'm going to look at who's going to do that, I'm going to look right back at AWS. The fun part about that, though, is I know from AWS's business model, that if that's something they were to emit, it would also cost you, like, 25 cents per call, and then you would actually, like, triple your cloud costs just trying to figure out how much it costs you.Corey: Only with 16 other billing dimensions because of course it would. And again, I'm talking about stuff, because of how I operate and how I think about this stuff, that is inherently corner case, or [vertex 00:31:39] case in many cases. But for the vast majority of folks, it's not the, “Oh, you have this really weird data transfer paradigm between these two resources,” which yeah, that's a problem that needs to be addressed in an awful lot of cases because data transfer pricing is bonkers, but instead it's the, “Huh. You just spun up a big cluster that's going to cost $20,000 a month.” You probably don't need to wait a full day to flag that.And you also can't put this on the customer in the sense of, “Oh, just set some budget alarms, that's great. That's the first thing you should do in a new AWS account.” “Well, jackhole, I've done an awful lot of first things I'm supposed to do in an AWS account, in my dedicated test account for these sorts of things. It's been four months, I'm not done yet with all of those first things I'm supposed to do.” It's incredibly secure, increasingly expensive, and so far all it runs is a single EC2 instance that is mostly there just so that everything else doesn't error out trying to divide by zero.Tim: There are some things that are built-in. If I stand up an EC2 instance and it goes down, I'm going to get an alert that this instance terminated for some reason. It's just going to show up informationally.Corey: In the console. You're not going to get called about it or paged about it, unless—Tim: Right.Corey: —you have something else in the business that will, like a boss that screams at you two o'clock in the morning. This is why we have very little that's production-facing here.Tim: But if I know that alert exists somewhere in the console, that's easy for me to write a trap for. That's easy for me to write, say hey, I'm going to respond to that because this call is going to come out somewhere; it's going to get emitted somewhere. I can now, as an engineer, write a very easy trap that says, “Hey, pop this in the Slack. Send an alert. Send a page.”So, if I could emit a cost metric, and I could say, “Wow. Somebody has spun up this thing that's going to cost X amount of money. Someone should get paged about this.” Because if they don't page about this and we wait eight hours, that's my month's salary. And you would do that if your database server went down; you would do that if someone rooted that database server; you would do that if the database server was [bogging 00:33:48] you to scale up another one. So, why can't you do that if that database server was all of sudden costing you way more than you had calculated?Corey: And there's a lot of nuance here because what you're talking about makes perfect sense for smaller-scale accounts, but even some of the very large accounts where we're talking hundreds of millions a year in spend, you can set compromised keys up on GitHub, put them in Payspin, whatever, and then people start spinning up Bitcoin miners everywhere. Great. It takes a long time to materially move the needle on that level of spend; it gets lost in the background noise. I lose my mind when I wind up leaving a managed NAT gateway running and it cost me 70 bucks a month in my $5 a month test account. Yeah, but you realize you could basically buy an island and it gets lost in the AWS bill at some of the high watermarks for some of these larger accounts.“Oh, someone spun up a cluster that's going to cost $400,000 a year?” Yeah, do I need to re-explain to you what a data science team does? They light money on fire in return for questionable returns, as a general rule. You knew that when you hired them; leave them alone. Whereas someone in their developer account does this, yeah, you kind of want to flag that immediately.It always comes down to rules and context. But I'd love to have some templates ready to go of, “I'm a starving student, please alert me anytime it looks like I might possibly exceed the free tier,” or better yet, “Don't let me, and if I do, it's on you and you eat the cost.” Conversely, it's, “Yeah, this is a Netflix sub-account or whatnot. Maybe don't bother me for anything whatsoever because freedom and responsibility is how we roll.” I imagine that's what they do internally on a lot of their cloud costing stuff because freedom and responsibility is ingrained in their culture. It's great. It's the freedom from having to think about cloud bills and the responsibility for paying it, of the cloud bill.Tim: Yeah, we will get internally alerted if things are [laugh] up too long, and then we will actually get paged, and then our manager would get paged, [laugh] and it would go up the line. If you leave something that's running too expensive, too long. So, there is a system there for it.Corey: Oh, yeah. The internal AWS systems for employees are probably my least favorite AWS service, full stop. And I've seen things posted about it; I believe it's called Isengard, for spinning up internal accounts and the rest—there's a separate one, I think, called Conduit, but I digress—that you spin something up, and apparently if it doesn't wind up—I don't need you to comment on this because you worked there and confidentiality is super important, but to my understanding it's, great, it has a whole bunch of formalized stuff like that and it solves for a whole lot of nifty features that bias for the way that AWS focuses on accounts and how they've view security and the rest. And, “Oh, well, we couldn't possibly ship this to customers because it's not how they operate.” And that's great.My problem with this internal provisioning system is it isolates and insulates AWS employees from the real pain of working with multiple accounts as a customer. You don't have to deal with the provisioning process of Control Tower or whatnot; you have your own internal thing. Eat your own dog food, gargle your own champagne, whatever it takes to wind up getting exposure to the pain that hits customers and suddenly you'll see those things improve. I find that the best way to improve a product is to make the people building it live with the painful parts.Tim: I think it's interesting that the stance is, “Well, it's not how the customers operate, and we wouldn't want the customers to have to deal with this.” But at the same time, you have to open up, like, 100 accounts if you need more than a certain number of S3 buckets. So, they are very comfortable with burdening the customer with a lot of constraints, and they say, “Well, constraints drive innovation.” Certainly, this is a constraint that you could at least offer and let the customers innovate around that.Corey: And at least define who the customer is. Because yeah, “I'm a Netflix sub-account is one story,” “I'm a regulated bank,” is another story, and, “I'm a student in my dorm room, trying to learn how this whole cloud thing works,” is another story. From risk tolerance, from a data protection story, from a billing surprise story, from a, “I'm trying to learn what the hell this is, and all these other service offerings you keep talking to me about confuse the hell out of me; please streamline the experience.” There's a whole universe of options and opportunity that isn't being addressed here.Tim: Well, I will say it very simply like this: we're talking about a multi-trillion dollar company versus someone who, if their AWS bill is too high, they don't pay rent; maybe they don't eat; maybe they have other issues, they don't—medical bill doesn't get paid; child care doesn't get paid. And if you're going to tell me that this multi-trillion dollar company can't solve for that so that doesn't happen to that person and tells them, “Well, if you come in afterwards, after your bill gets there, maybe we can do something about it, but in the meantime, suffer through this.” That's not ethical. Full stop.Corey: There are a lot of things that AWS gets right, and I want to be clear that I'm not sitting here trying to cast blame and say that everything they're doing is terrible. I feel like every time I talk about billing in any depth, I have to throw this disclaimer in. Ninety to ninety-five percent of what they do is awesome. It's just the missing piece that is incredibly painful for customers, and that's what I spend most of my time focusing on. It should not be interpreted to think that I hate the company.I just want them to do better than they are, and what they're doing now is pretty decent in most respects. I just want to fix the painful parts. Tim, thank you for joining me for a third time here. I'm certain I'll have you back in the somewhat near future to talk about more aspects of this, but until then, where can people find you slash retain your services?Tim: Well, you can find me on Twitter at @elchefe. If you want to retain my services for which you would be very, very happy to have, you can go to duckbillgroup.com and fill out a little questionnaire, and I will magically appear after an exchange of goods and services.Corey: Make sure to reference Tim by name just so that we can make our sales team facepalm because they know what's coming next. Tim, thank you so much for your time; it's appreciated.Tim: Thank you so much, Corey. I loved it.Corey: Principal cloud economist here at The Duckbill Group, Tim Banks. 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, wait at least eight hours—possibly as many as 48 to 72—and then leave a comment explaining what you didn't like.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.

This week in the podcast, we run through the results of our latest quarterly RBC analyst survey, in which we poll the firm's equity analysts on the outlooks for the industries they cover. The big things you need to know: First, outlooks for performance over the next 6-12 months remain optimistic, driven by constructive views on fundamentals, valuations, and cash deployment. Second, our analysts tilt most positive on Financials, Energy, Information Technology, Utilities, and Health Care, and least positive on REITs and Industrials. Third, policy outlooks generally remain cool, though it's worth noting most see higher corporate taxes as a moderate problem for earnings and performance as opposed to a major one. Fourth, while margin expectations have eased only a handful of our analysts consider supply chains to be a major problem for the industries they cover.

The Context of White Supremacy welcomes Guy Lancaster. Editor of the online Encyclopedia of Arkansas, Lancaster is a White Man and freelance writer for the Arkansas Times magazine. He's also published monographs on the 1919 racial cleansing in Elaine, Arkansas. We'll discuss his 2021 publication, American Atrocity: The Types of Violence in Lynching. Lancaster analyzes White Terrorism in Arkansas specifically and specifies how lynchings and White Mob Violence was the product of the entire White collective. We'll relate Lancaster's work to the current White Terrorism from Jan. 6th, as well as the ongoing savagery targeting school officials and flight attendants. Conspicuously, reports neglect to specify that these domestic terrorists are overwhelmingly individuals classified as White. #WhiteCultureIsWhiteTerrorism INVEST in The COWS – http://paypal.me/TheCOWS Cash App: https://cash.app/$TheCOWS CALL IN NUMBER: 720.716.7300 CODE 564943#

Dustin chats with Prisha about her tabletop game cafe in India. They talk about marketing tabletop games and running educational programming at a tabletop cafe. Dustin shares his expertise in using game-based learning and gamification techniques. Episode Topics (timestamps are for podcast episode | video time stamps are available on YouTube) 00:00 - Board Gaming with Education - Twitch or YouTube or Facebook 1:18 - Introduction to Prisha 3:31 - Context for the Conversation and Understanding the Tabletop Gaming Market 12:08 - Questions for Dustin-- Dustin Tackles Questions about Using Tabletop Games for Educational Programming Games/Books from this Episode [Links include games in our Board Gaming with Education Store or Amazon affiliate links]: Splendor Skull Sherlock Holmes Consulting Detective Periodic Cytosis Rhino Hero Rhino Hero Junior Trap Words Ion Wongamania Rabbit Rally Snake Oil Superfight Set Check out our board game store for a curated collection of board games for learning at home and in the classroom: https://www.boardgamingwitheducation.com   Thank you to Purple Planet Music for the wonderful contribution of their song "Retro Gamer" for our Interview Segment. This song can be found in full on this music archive. Also, thank you to Kevin MacLeod (incompetech.com) for his creative commons 4.0 contribution of "Getting it Done" for our Thumbs Up, Thumbs Down Rapid Fire Round. Always be sure to check out our show notes (website blog post) to read a recap of the episode topics and games mentioned in the episode. https://www.boardgamingwitheducation.com/prisha

--- This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app

Scott Ridout, President of Converge The life Jesus wants us to live is a life of authenticity - trusting God and others with the real me.  However, to experience authenticity, there must be vulnerability. Click on the links below for additional Cascade Church resources. Connect Card: https://cascadechurch.org/connectcard Give Online: https://cascadechurch.org/give Kid's Resources: https://cascadechurch.org/children Context of John Guide: https://bit.ly/3nBBXdf

This week on Good Talk, we discuss the importance of context in the Word of God. What does God actually say in the Bible versus what you want Him to say?

This ghostly re-release (with a new introduction) is here to help us fit next week's brand-new episode 'Haunted House Attractions' into a larger American haunted history. Re-listen or listen for the first time, you might be surprised by what the "other side" has to say. Become a Patron and support our show!

The Milwaukee Brewers head back to Atlanta tied up with the Braves 1-1 in the NLCS. We recap Game 2, talk contextual Brewers road stats vs Braves home stats, give our predictions, key things to watch, touch on the Willy Adames signed jersey giveaway and more. Ladies & Gentlemen, you are listening to the IKE Brewers Podcast Make sure to enter our SIGNED Willy Adames Jersey giveaway! Send @IKE_Brewers a DM for details! Don't forget to check out IKE Badgers Podcast for player interviews, game recaps, trends and all things Wisconsin Badgers. View our new website at IKEPODCASTNETWORK.COM Follow the IKE Brewers Podcast on Spotify. Subscribe today on Apple Podcasts. Follow @IKE_Brewers on twitter @WelcometoIKE

Pastor Jim Alter 2 Peter 3

This week; after a week's hiatus, Shaun wants to jump right back into the thick of it with 5 episodes of an anime with quite a dedicated fanbase: Bungou Stray Dogs. Meanwhile, Remington gives Dylan fuel for nearly 2 minutes of corruptions. If you'd like to give us feedback, ask a question, or correct a mistake, send an email to AnimeOutOfContext@gmail.com or tweet at us @AnimeConPod. Visit our Patreon at patreon.com/AnimeoutofContext if you would like to contribute to the show and get bonus content ranging from clips from our pre-episode banter, to our prototype Episode 0, to even getting shoutouts in the show! Intro and Outro are a trimmed from "Remiga Impulse" by Jens Kiilstofte, licensed by MachinimaSound to Anime Out of Context under CC BY-NC-ND 4.0 which has been modified by the licensor for the licensee to allow reproduction and sharing of the Adapted Material for Commercial purposes Video episodes generated by Headliner.app

The Context of White Supremacy hosts The Context of White Supremacy hosts the weekly Compensatory Call-In. We encourage non-white listeners to dial in with their codified concepts, new terms, observations, research findings, workplace problems or triumphs, and/or suggestions on how best to Replace White Supremacy With Justice ASAP. We'll use these sessions to hone our use of words as tools to reveal truth, neutralize White people. We'll examine news reports from the past seven days and – hopefully – promote a constructive dialog. #ANTIBLACKNESS Similar to reports of Whites terrorizing flight attendants and disrupting air travel, educators across the U.S. beg federal officials for assistance to neutralize ongoing threats and White violent attacks against teachers and faculty in response to school mask mandates. Practically all of the perpetrators reported thus far have been White. Some educators have labeled the barbarian attacks on school grounds "domestic terrorism." Speaking of soulless criminals, over a dozen former NBA players (seemingly exclusively black males) were charged with attempted fraud. The exact same charges were leveled against former NFL players just weeks ago. Once again, the earlier suspects were also exclusively black males. #WhiteSupremacyIsTerrorism INVEST in The COWS – http://paypal.me/TheCOWS Cash App: https://cash.app/$TheCOWS CALL IN NUMBER: 720.716.7300 CODE 564943#

The Context of White Supremacy hosts the weekly forum on Neutralizing Workplace Racism. Chaos in the field of labor will usher us into 2022. In New York, approximately 1,500 health care workers were terminated for failure to comply with vaccine mandates. In Gus' Seattle, approximately 33% of Seattle Police officers have failed to show proof of vaccination. Many reports also suggest that vaccine mandates may correlate with an increase in vaccinations over the past few weeks. Besides brawls over Covid-19 protocols, several C.O.W.S. listeners address the hazards of fields that require driving. We'll address possible counter-racist techniques to minimize problems for commercial motorists and delivery personnel. #VaccineSurcharge INVEST in The COWS – http://paypal.me/TheCOWS Cash App: https://cash.app/$TheCOWS CALL IN NUMBER: 720.716.7300 CODE: 564943#

*TRIGGER WARNING* some of the content in this episode may include triggers for topics including: Adverse Childhood Events also known as ACEs, animal abuse, and interpersonal violence, including child abuse and domestic violence. As a reminder, if you are a veterinary student or veterinarian, the VIN Foundation's confidential peer-to-peer support group vets4vets® is here for you, at no cost, please know, you are not alone. Call (530) 794-8094 or visit the website to schedule a session: https://vinfoundation.org/resources/vets4vets/   Listen in as VIN Foundation Executive Director Jordan benShea has a conversation with Vets4Vets® team member Dr. Susan Cohen about suicide risks in the veterinary profession, how adverse childhood events play a role, and the impact of perfectionism. This episode kicks off the Veterinary Pulse's Inhale, Exhale Series on mental wellness in the veterinary profession. Learn the warning signs of mental distress, what to do if you or someone you know is struggling with thoughts of suicide, and where to go for help.   GUEST BIOS: Dr. Susan P. Cohen Susan has been called a pioneer in the fields of pet loss, human-animal interaction, and the human side of veterinary practice. Since 1982 Dr. Cohen has helped pet lovers make decisions about the illness of their pets. She developed the first-ever Pet Loss Support Group and began an animal assisted activity program that took the then-unusual form of having volunteers work with their own pets. She originated many training programs for workers in the veterinary and social service fields, and she has been a field instructor for several schools of social work. She has written several book chapters and scholarly articles on social work, veterinary practice, and the human-animal bond. Her most recent book chapter, “Loss, Grief, and Bereavement in the Context of Human-Animal Relationships” (Susan Cohen, DSW; and Adam Clark, LSW, AASW) was published in 2019. She is currently working on a chapter on pet loss for Routledge's International Handbook on Human-Animal Interaction. These days she consults with veterinary groups on client and professional communication, compassion fatigue, and how to make practice fun again. She facilitates online support groups for veterinarians, animal welfare workers, managers, and those grieving the loss of a pet. She teaches online workshops and lectures widely to veterinary colleges and conferences, colleges of social work, veterinary technician programs, and human health groups on communication, pet loss and bereavement, human-animal interaction, client relations, compassion fatigue, and career development. She is Vice Chairperson of SWAHAB (Social Workers Advancing the Human-Animal Bond), the first such committee of the National Association of Social Workers. Her work has been featured in The New York Times, The Wall Street Journal, The New Yorker, and Smithsonian Magazine. In addition, she has made numerous television and radio addresses nationwide, including “The Today Show,” "20-20," and "The Oprah Winfrey Show."   LINKS AND INFORMATION: Suicide Prevention Hotline: 800-273-8255 https://suicidepreventionlifeline.org/how-we-can-all-prevent-suicide/ VIN Foundation Vets4Vets® and Support4Support:: https://vinfoundation.org/resources/vets4vets/ Book a session with Vets4Vets®: https://vinfoundation.org/resources/vets4vets-appointments/ Dr. Susan Cohen Veterinary Pulse Episode 104: https://vinfoundation.org/are-you-caring-too-much-red-shoe-syndrome-susan-cohen/ Adverse Childhood Events: https://www.cdc.gov/violenceprevention/aces/index.html Borderline personality disorder: https://www.borderlinepersonalitydisorder.org   You may learn more about the VIN Foundation, on the website, or join the conversation on Facebook, Instagram, or Twitter.   If you like this podcast, we would appreciate it if you follow and share. As always, we welcome feedback. If you have an idea for a podcast episode, we'd love to hear it!

1st Week of October, 2021 ------

The Context of White Supremacy hosts the debut study session on Ernest Tidyman's 1970 novel, SHAFT. Tidyman is a White man. He forged a distinguished journalism career working for The New York Times and Ohio's The Plain Dealer. In the midst of the so called Civil Rights Movement and the unrest of the 1960's, Tidyman decided to concoct a narrative around a black private detective named John SHAFT. This relatively short book sparked a half century of trashy films and mightily influenced the thoughts, speech, action, emotions, and wardrobe of generations of black people. Most of these victims are clueless that there favorite black action hero is the creation of a White man. Gus is excited to closely scrutinize a work that depicts SHAFT as a "bi-sexual" Vietnam veteran out to stick it to "The Man." The film adaptation of Tidyman's work is also a spectacular illustration of Racial Showcasing. The director was Gordan Parks, Richard Roundtree starred in the film, and Isaac Hayes' legendary soundtrack remains beloved and recognized a half century later. Hayes owns an Academy Award for his contributions to SHAFT. This franchise of films, along with the late Melvin Van Peebles, is credited with introducing the era of "Blaxploitation" films - cheaply made movies, bloated with crime and gratuitous sexual content, featuring mostly black characters. The fictional John SHAFT remains beloved by numerous black people well into the 21st century. #BlackMalePenis INVEST in The COWS – http://paypal.me/TheCOWS Cash App: https://cash.app/$TheCOWS CALL IN NUMBER: 720.716.7300 CODE: 564943#

By Jorge de Campos in Lexington, KY - October 6, 2021 - Bible study no 1 of 34 of the book of Revelation. Join us for this very amazing video study of the book of Revelation.

About JasonJason is now the Managing Director at Redpoint Ventures.Links: GitHub: https://github.com/ @jasoncwarner: https://twitter.com/jasoncwarner GitHub: https://github.com/jasoncwarner Jasoncwarner/ama: https://github.com/jasoncwarner/ama 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 Honeycomb. When production is running slow, it's hard to know where problems originate: is it your application code, users, or the underlying systems? I've got five bucks on DNS, personally. Why scroll through endless dashboards, while dealing with alert floods, going from tool to tool to tool that you employ, guessing at which puzzle pieces matter? Context switching and tool sprawl are slowly killing both your team and your business. You should care more about one of those than the other, which one is up to you. Drop the separate pillars and enter a world of getting one unified understanding of the one thing driving your business: production. With Honeycomb, you guess less and know more. Try it for free at Honeycomb.io/screaminginthecloud. Observability, it's more than just hipster monitoring.Corey: This episode is sponsored in part by Liquibase. If you're anything like me, you've screwed up the database part of a deployment so severely that you've been banned from touching every anything that remotely sounds like SQL, at at least three different companies. We've mostly got code deployments solved for, but when it comes to databases we basically rely on desperate hope, with a roll back plan of keeping our resumes up to date. It doesn't have to be that way. Meet Liquibase. It is both an open source project and a commercial offering. Liquibase lets you track, modify, and automate database schema changes across almost any database, with guardrails to ensure you'll still have a company left after you deploy the change. No matter where your database lives, Liquibase can help you solve your database deployment issues. Check them out today at liquibase.com. Offer does not apply to Route 53.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by Jason Warner, the Chief Technology Officer at GifHub, although he pronounces it differently. Jason, welcome to the show.Jason: Thanks, Corey. Good to be here.Corey: So, GitHub—as you insist on pronouncing it—is one of those companies that's been around for a long time. In fact, I went to a training conducted by one of your early folks, Scott Chacon, who taught how Git works over the course of a couple of days, and honestly, I left more confused than I did when I entered. It's like, “Oh, this is super awful. Good thing I'll never need to know this because I'm not really a developer.” And I'm still not really a developer and I still don't really know how Git works, but here we are.And it's now over a decade later; you folks have been acquired by Microsoft, and you are sort of the one-stop-shop, from the de facto perspective of, “I'm going to go share some code with people on the internet. I'll use GitHub to do it.” Because, you know, copying and pasting and emailing Microsoft Word documents around isn't ideal.Jason: That is right. And I think that a bunch of things that you mentioned there, played into, you know, GitHub's early and sustained success. But my God, do you remember the old days when people had to email tar files around or drop them in weird spots?Corey: What the hell do you mean, by, “Old days?” It still blows my mind that the Linux kernel is managed by—they use Git, obviously. Linus Torvalds did write Git once upon a time—and it has the user interface you would expect for that. And the way that they collaborate is not through GitHub or anything like that. No, they use Git to generate patches, which they then email to the mailing list. Which sounds like I'm making it up, like, “Oh, well, yeah, tell another one, but maybe involve a fax machine this time.” But no, that is actually what they do.Jason: It blew my mind when I saw that, too, by the way. And you realize, too, that workflows are workflows, and people will build interesting workflows to solve their use case. Now, obviously, anyone that you would be talking to in 2021, if you walked in and said, “Yeah, install Git. Let's set up an email server and start mailing patches to each other and we're going to do it this way.” They would just kind of politely—or maybe impolitely—show you out of the room, and rightfully [laugh] so. But it works for one of the most important software projects in history: Linux.Corey: Yeah, and it works almost in spite of itself to some extent. You've come a long way as a company because initially, it was, “Oh, there's this amazing, decentralized version control system. How do we make it better? I know, we're going to take off the decentralized part of it and give it a central point that everything can go through.” And collaboratively, it works well, but I think that viewing GitHub as a system that is used to sell free Git repositories to people is rather dramatically missing the point. It feels like it's grown significantly beyond just code repository hosting. Tell me more about that.Jason: Absolutely. I remember talking to a bunch of folks right around when I was joining GitHub, and you know, there was still talk about GitHub as, you know, GitHub for lawyers, or GitHub for doctors, or what could you do in a different way? And you know, social coding as an aspect, and maybe turning into a social network with a resume. And all those things are true to a percentage standpoint. But what GitHub should be in the world is the world's most important software development platform, end-to-end software development platform.We obviously have grown a bunch since me joining in that way which we launched dependency management packages, Actions with built-in CI, we've got some deployment mechanisms, we got advanced security underneath it, we've Codespaces in beta and alpha on top of it now. But if you think about GitHub as, join, share, and see other people's code, that's evolution one. If you see it as world's largest, maybe most developed software development platform, that's evolution two, and in my mind, its natural place where it should be, given what it has done already in the world, is become the world's most important software company. I don't mean the most profitable. I just mean the most important.Corey: I would agree. I had a blog post that went up somewhat recently about the future of cloud being Microsoft's to lose. And it's not because Azure is the best cloud platform out there, with respect, and I don't need you to argue the point. It is very clearly not. It is not like other clouds, but I can see a path to where it could become far better than it is.But if I'm out there and I'm just learning how to write code—because I make terrible life choices—and I go to a boot camp or I follow a tutorial online or I take a course somewhere, I'm going to be writing code probably using VS Code, the open-source editor that you folks launched after the acquisition. And it was pretty clear that Atom wasn't quite where the world was going. Great. Then I'm going to host it on GitHub, which is a natural evolution. Then you take a look at things like GitHub Actions that build in CI/CD pipelines natively.All that's missing is a ‘Deploy to Azure' button that is the next logical step, and you're mostly there for an awful lot of use cases. But you can't add that button until Azure itself gets better. Done right, this has the potential to leave, effectively, every other cloud provider in the dust because no one can touch this.Jason: One hundred percent. I mean, the obvious thing that any other cloud should be looking at with us—or should have been before the acquisition, looking at us was, “Oh, no, they could jump over us. They could stop our funnel.” And I used internal metrics when I was talking to them about partnership that led to the sale, which was I showed them more about their running business than they knew about themselves. I can tell them where they were stacked-ranked against each other, based on the ingress and egress of all the data on GitHub, you know, and various reactions to that in those meetings was pretty astounding.And just with that data alone, it should tell you what GitHub would be capable of and what Azure would be capable of in the combination of those two things. I mean, you did mention the ‘Deploy to Azure' button; this has been a topic, obviously, pre and post-acquisition, which is, “When is that coming?” And it was the one hard rule I set during the acquisition was, there will be no ‘Deploy to Azure' button. Azure has to earn the right to get things deployed to, in my opinion. And I think that goes to what you're saying is, if we put a ‘Deploy to Azure' button on top of this and Azure is not ready for that, or is going to fail, ultimately, that looks bad for all of us. But if it earned the right and it gets better, and it becomes one of those, then, you know, people will choose it, and that is, to me, what we're after.Corey: You have to choose the moment because if you do it too soon, you'll set the entire initiative back five years. Do it too late, and you get leapfrogged. There's a golden window somewhere and finding it is going to be hard. And I think it's pretty clear that the other hyperscalers in this space are learning, or have learned, that the next 10 years of cloud or 15 years of cloud or whatever they want to call it, and the new customers that are going to come are not the same as the customers that have built the first half of the business. And they're trying to wrap their heads around that because a lot of where the growth is going to come from is established blue chips that are used to thinking in very enterprise terms.And people think I'm making fun of them when I say this, but Microsoft has 40 years' experience apologizing to enterprises for computer failures. And that is fundamentally what cloud is. It's about talking computers to business executives because as much as we talk about builders, that is not the person at an established company with an existing IT estate, who gets to determine where $50 million a year in cloud-spend is going to go.Jason: It's [laugh] very, [laugh] very true. I mean, we've entered a different spot with cloud computing in the bell curve of adoption, and if you think that they will choose the best technology every time, well, history of computing is littered with better technologies that have failed because the distribution was better on one side. As you mentioned, Microsoft has 40 years, and I wager that Microsoft has the best sales organizations and the best enterprise accounts and, you know, all that sort of stuff, blah, blah, blah, on that side of the world than anyone in the industry. They can sell to enterprises better than almost anyone in the industry. And the other hyperscalers—there's a reason why [TK 00:08:34] is running Google Cloud right now. And Amazon, classically, has been very, very bad assigned to the enterprises. They just happened to be the first mover.Corey: In the early days, it was easy. You'd have an Amazon salesperson roll up to a company, and the exec would say, “Great, why should we consider running things on AWS?” And the answer was, “Oh, I'm sorry, wrong conversation. Right now you have 80 different accounts scattered throughout your org. I'm just here to help you unify them, get some visibility into it, and possibly give you a discount along the way.” And it was a different conversation. Shadow IT was the sole driver of cloud adoption for a long time. That is no longer true. It has to go in the front door, and that is a fundamental shift in how you go to market.Jason: One hundred percent true, and it's why I think that Microsoft has been so successful with Azure, in the last, let's call it five years in that, is that the early adopters in the second wave are doing that; they're all enterprise IT, enterprise dev shops who are buying from the top down. Now, there is still the bottoms-up adoption that going to be happening, and obviously, bottom-up adoption will happen still going forward, but we've entered the phase where that's not the primary or sole mechanism I should say. The sole mechanism of buying in. We have tops-down selling still—or now.Corey: When Microsoft announced it was acquiring GitHub, there was a universal reaction of, “Oh, shit.” Because it's Microsoft; of course they're going to ruin GitHub. Is there a second option? No, unless they find a way to ruin it twice. And none of it came to pass.It is uniformly excellent, and there's a strong argument that could be made by folks who are unaware of what happened—I'm one of them, so maybe I'm right, maybe I'm wrong—that GitHub had a positive effect on Microsoft more than Microsoft had an effect on GitHub. I don't know if that's true or not, but I could believe it based upon what I've seen.Jason: Obviously, the skepticism was well deserved at the time of acquisition, let's just be honest with it, particularly given what Microsoft's history had been for about 15—well, 20 years before, previous to Satya joining. And I was one of those people in the late '90s who would write ‘M$' in various forums. I was 18 or 19 years old, and just got into—Corey: Oh, hating Microsoft was my entire personality.Jason: [laugh]. And it was, honestly, well-deserved, right? Like, they had anti-competitive practices and they did some nefarious things. And you know, I talked about Bill Gates as an example. Bill Gates is, I mean, I don't actually know how old he is, but I'm going to guess he's late '50s, early '60s, but he's basically in the redemption phase of his life for his early years.And Microsoft is making up for Ballmer years, and later Gates years, and things of that nature. So, it was well-deserved skepticism, and particularly for a mid-career to older-career crowd who have really grown to hate Microsoft over that time. But what I would say is, obviously, it's different under Satya, and Scott, and Amy Hood, and people like that. And all we really telling people is give us a chance on this one. And I mean, all of us. The people who were running GitHub at the time, including myself and, you know, let Scott and Satya prove that they are who they say they are.Corey: It's one of those things where there's nothing you could have said that would have changed the opinion of the world. It was, just wait and see. And I think we have. It's now, I daresay, gotten to a point where Microsoft announces that they're acquiring some other beloved company, then people, I think, would extend a lot more credit than they did back then.Jason: I have to give Microsoft a ton of credit, too, on this one for the way in which they handled acquisitions, like us and others. And the reason why I think it's been so successful is also the reason why I think so many others die post-acquisition, which is that Microsoft has basically—I'll say this, and I know I won't get fired because it feels like it's true. Microsoft is essentially a PE holding company at this point. It is acquired a whole bunch of companies and lets them run independent. You know, we got LinkedIn, you got Minecraft, Xbox is its own division, but it's effectively its own company inside of it.Azure is run that way. GitHub's got a CEO still. I call it the archipelago model. Microsoft's the landmass underneath the water that binds them all, and finance, and HR, and a couple of other things, but for the most part, we manifest our own product roadmap still. We're not told what to go do. And I think that's why it's successful. If we're going to functionally integrate GitHub into Microsoft, it would have died very quickly.Corey: You clearly don't mix the streams. I mean, your gaming division writes a lot of interesting games and a lot of interesting gaming platforms. And, like, one of the most popularly played puzzle games in the world is a Microsoft property, and that is, of course, logging into a Microsoft account correctly. And I keep waiting for that to bleed into GitHub, but it doesn't. GitHub is a terrific SAML provider, it is stupidly easy to log in, it's great.And at some level, I wish that would bleed into other aspects, but you can't have everything. Tell me what it's like to go through an acquisition from a C-level position. Because having been through an acquisition before, the process looks a lot like a surprise all-hands meeting one day after the markets close and, “Listen up, idiots.” And [laugh] there we go. I have to imagine with someone in your position, it's a slightly different experience.Jason: It's definitely very different for all C-levels. And then myself in particular, as the primary driver of the acquisition, obviously, I had very privy inside knowledge. And so, from my position, I knew what was happening the entire time as the primary driver from the inside. But even so, it's still disconcerting to a degree because, in many ways, you don't think you're going to be able to pull it off. Like, you know, I remember the months, and the nights, and the weekends, and the weekend nights, and all the weeks I spent on the road trying to get all the puzzle pieces lined up for the Googles, or the Microsofts, or the eventually AWSs, the VMwares, the IBMs of the world to take seriously, just from a product perspective, which I knew would lead to, obviously, acquisition conversations.And then, once you get the call from the board that says, “It's done. We signed the letter of intent,” you basically are like, “Oh. Oh, crap. Okay, hang on a second. I actually didn't—I don't actually believe in my heart of hearts that I was going to actually be able to pull that off.” And so now, you probably didn't plan out—or at least I didn't. I was like, “Shit if we actually pulled this off what comes next?” And I didn't have that what comes next, which is odd for me. I usually have some sort of a loose plan in place. I just didn't. I wasn't really ready for that.Corey: It's got to be a weird discussion, too, when you start looking at shopping a company around to be sold, especially one at the scale of GitHub because you're at such a high level of visibility in the entire environment, where—it's the idea of would anyone even want to buy us? And then, duh, of course they would. And you look the hyperscalers, for example. You have, well, you could sell it to Amazon and they could pull another Cloud9, where they shove it behind the IAM login process, fail to update the thing meaningfully over a period of years, to a point where even now, a significant portion of the audience listening to this is going to wonder if it's a service I just made up; it sounds like something they might have done, but Cloud9 sounds way too inspired for an AWS service name, so maybe not. And—which it is real. You could go sell to Google, which is going to be awesome until some executive changes roles, and then it's going to be deprecated in short order.Or then there's Microsoft, which is the wild card. It's, well, it's Microsoft. I mean, people aren't really excited about it, but okay. And I don't think that's true anymore at all. And maybe I'm not being fair to all the hyperscalers there. I mean, I'm basically insulting everyone, which is kind of my shtick, but it really does seem that Microsoft was far and away the best acquirer possible because it has been transformative. My question—if you can answer it—is, how the hell did you see that beforehand? It's only obvious—even knowing what I know now—in hindsight.Jason: So, Microsoft was a target for me going into it, and the reason why was I thought that they were in the best overall position. There was enough humility on one side, enough hubris on another, enough market awareness, probably, organizational awareness to, kind of, pull it off. There's too much hubris on one side of the fence with some of the other acquirers, and they would try to hug us too deeply, or integrate us too quickly, or things of that nature. And I think it just takes a deep understanding of who the players are and who the egos involved are. And I think egos has actually played more into acquisitions than people will ever admit.What I saw was, based on the initial partnership conversations, we were developing something that we never launched before GitHub Actions called GitHub Launch. The primary reason we were building that was GitHub launches a five, six-year journey, and it's got many, many different phases, which will keep launching over the next couple of years. The first one we never brought to market was a partnership between all of the clouds. And it served a specific purpose. One, it allowed me to get into the room with the highest level executive at every one of those companies.Two allow me to have a deep economic conversation with them at a partnership level. And three, it allowed me to show those executives that we knew what GitHub's value was in the world, and really flip the tables around and say, “We know what we're worth. We know what our value is in the world. We know where we sit from a product influence perspective. If you want to be part of this, we'll allow it.” Not, “Please come work with us.” It was more of a, “We'll allow you to be part of this conversation.”And I wanted to see how people reacted to that. You know how Amazon reacted that told me a lot about how they view the world, and how Google reacted to that showed me exactly where they viewed it. And I remember walking out of the Google conversation, feeling a very specific way based upon the reaction. And you know, when I talked to Microsoft, got a very different feel and it, kind of, confirmed a couple of things. And then when I had my very first conversation with Nat, who have known for a while before that, I realized, like, yep, okay, this is the one. Drive hard at this.Corey: If you could do it all again, would you change anything meaningful about how you approached it?Jason: You know, I think I got very lucky doing a couple of things. I was very intentional aspects of—you know, I tried to serendipitously show up, where Diane Greene was at one point, or a serendipitously show up where Satya or Scott Guthrie was, and obviously, that was all intentional. But I never sold a company like this before. The partnership and the product that we were building was obviously very intentional. I think if I were to go through the sale, again, I would probably have tried to orchestrate at least one more year independent.And it's not—for no other reason alone than what we were building was very special. And the world sees it now, but I wish that the people who built it inside GitHub got full credit for it. And I think that part of that credit gets diffused to saying, “Microsoft fixed GitHub,” and I want the people inside GitHub to have gotten a lot more of that credit. Microsoft obviously made us much better, but that was not specific to Microsoft because we're run independent; it was bringing Nat in and helping us that got a lot of that stuff done. Nat did a great job at those things. But a lot of that was already in play with some incredible engineers, product people, and in particular our sales team and finance team inside of GitHub already.Corey: When you take a look across the landscape of the fact that GitHub has become for a certain subset of relatively sad types of which I'm definitely one a household name, what do you think the biggest misconception about the company is?Jason: I still think the biggest misconception of us is that we're a code host. Every time I talk to the RedMonk folks, they get what we're building and what we're trying to be in the world, but people still think of us as SourceForge-plus-plus in many ways. And obviously, that may have been our past, but that's definitely not where we are now and, for certain, obviously, not our future. So, I think that's one. I do think that people still, to this day, think of GitLab as one of our main competitors, and I never have ever saw GitLab as a competitor.I think it just has an unfortunate naming convention, as well as, you know, PRs, and MRs, and Git and all that sort of stuff. But we take very different views of the world in how we're approaching things. And then maybe the last thing would be that what we're doing at the scale that we're doing it as is kind of easy. When I think that—you know, when you're serving almost every developer in the world at this point at the scale at which we're doing it, we've got some scale issues that people just probably will never thankfully encounter for themselves.Corey: Well, everyone on Hacker News believes that they will, as soon as they put up their hello world blog, so Kubernetes is the only way to do anything now. So, I'm told.Jason: It's quite interesting because I think that everything breaks at scale, as we all know about from the [hyperclouds 00:20:54]. As we've learned, things are breaking every day. And I think that when you get advice, either operational, technical, or managerial advice from people who are running 10 person, 50 person companies, or X-size sophisticated systems, it doesn't apply. But for whatever reason, I don't know why, but people feel inclined to give that feedback to engineers at GitHub directly, saying, “If you just…” and in many [laugh] ways, you're just like, “Well, I think that we'll have that conversation at some point, you know, but we got a 100-plus-million repos and 65 million developers using us on a daily basis.” It's a very different world.Corey: This episode is sponsored by our friends at Oracle HeatWave is a new high-performance accelerator for the Oracle MySQL Database Service. Although I insist on calling it “my squirrel.” While MySQL has long been the worlds most popular open source database, shifting from transacting to analytics required way too much overhead and, ya know, work. With HeatWave you can run your OLTP and OLAP, don't ask me to ever say those acronyms again, workloads directly from your MySQL database and eliminate the time consuming data movement and integration work, while also performing 1100X faster than Amazon Aurora, and 2.5X faster than Amazon Redshift, at a third of the cost. My thanks again to Oracle Cloud for sponsoring this ridiculous nonsense.Corey: One of the things that I really appreciate personally because, you know, when you see something that company does, it's nice to just thank people from time to time, so I'm inviting the entire company on the podcast one by one, at some point, to wind up thanking them all individually for it, but Codespaces is one of those things that I think is transformative for me. Back in the before times, and ideally the after times, whenever I travel the only computer I brought with me for a few years now has been an iPad or an iPad Pro. And trying to get an editor on that thing that works reasonably well has been like pulling teeth, my default answer has just been to remote into an EC2 instance and use vim like I have for the last 20 years. But Code is really winning me over. Having to play with code-server and other things like that for a while was obnoxious, fraught, and difficult.And finally, we got to a point where Codespaces was launched, and oh, it works on an iPad. This is actually really slick. I like this. And it was the thing that I was looking for but was trying to have to monkey patch together myself from components. And that's transformative.It feels like we're going back in many ways—at least in my model—to the days of thin clients where all the heavy lifting was done centrally on big computers, and the things that sat on people's desks were mostly just, effectively, relatively simple keyboard, mouse, screen. Things go back and forth and I'm sure we'll have super powerful things in our pockets again soon, but I like the interaction model; it solves for an awful lot of problems and that's one of the things that, at least from my perspective, that the world may not have fully wrapped it head around yet.Jason: Great observation. Before the acquisition, we were experimenting with a couple of different editors, that we wanted to do online editors. And same thing; we were experimenting with some Action CI stuff, and it just didn't make sense for us to build it; it would have been too hard, there have been too many moving parts, and then post-acquisition, we really love what the VS Code team was building over there, and you could see it; it was just going to work. And we had this one person, well, not one person. There was a bunch of people inside of GitHub that do this, but this one person at the highest level who's just obsessed with make this work on my iPad.He's the head of product design, his name's Max, he's an ex-Heroku person as well, and he was just obsessed with it. And he said, “If it works on my iPad, it's got a chance to succeed. If it doesn't work on my iPad, I'm never going to use this thing.” And the first time we booted up Codespaces—or he booted it up on the weekend, working on it. Came back and just, “Yep. This is going to be the one. Now, we got to work on those, the sanding the stones and those fine edges and stuff.”But it really does unlock a lot for us because, you know, again, we want to become the software developer platform for everyone in the world, you got to go end-to-end, and you got to have an opinion on certain things, and you got to enable certain functionality. You mentioned Cloud9 before with Amazon. It was one of the most confounding acquisitions I've ever seen. When they bought it I was at Heroku and I thought, I thought at that moment that Amazon was going to own the next 50 years of development because I thought they saw the same thing a lot of us at Heroku saw, and with the Cloud9 acquisition, what they were going to do was just going to stomp on all of us in the space. And then when it didn't happen, we just thought maybe, you know, okay, maybe something else changed. Maybe we were wrong about that assumption, too. But I think that we're on to it still. I think that it just has to do with the way you approach it and, you know, how you design it.Corey: Sorry, you just said something that took me aback for a second. Wait, you mean software can be designed? It's not this emergent property of people building thing on top of thing? There's actually a grand plan behind all these things? I've only half kidding, on some level, where if you take a look at any modern software product that is deployed into the world, it seems impossible for even small aspects of it to have been part of the initial founding design. But as a counterargument, it would almost have to be for a lot of these things. How do you square that circle?Jason: I think you have to, just like anything on spectrums and timelines, you have to flex at various times for various things. So, if you think about it from a very, very simple construct of time, you just have to think of time horizons. So, I have an opinion about what GitHub should look like in 10 years—vaguely—in five years much more firmly, and then very, very concretely, for the next year, as an example. So, a lot of the features you might see might be more emergent, but a lot of long-term work togetherness has to be loosely tied together with some string. Now, that string will be tightened over time, but it loosely has to see its way through.And the way I describe this to folks is that you don't wake up one day and say, “I'm going on vacation,” and literally just throw a finger on the map. You have to have some sort of vague idea, like, “Hey, I want to have a beach vacation,” or, “I want to have an adventure vacation.” And then you can kind of pick a destination and say, “I'm going to Hawaii,” or, “I'm going to San Diego.” And if you're standing on the East Coast knowing you're going to San Diego, you basically know that you have to just start marching west, or driving west, or whatever. And now, you don't have to have the route mapped out just yet, but you know that hey, if I'm going due southeast, I'm off course, so how do I reorient to make sure I'm still going in the right direction?That's basically what I think about as high-level, as scale design. And it's not unfair to say that a lot of the stuff is not designed today. Amazon is very famous for not designing anything; they design a singular service. But there's no cohesiveness to what Amazon—or AWS specifically, I should say, in this case—has put out there. And maybe that's not what their strategy is. I don't know the internal workings of them, but it's very clear.Corey: Well, oh, yeah. When I first started working in the AWS space and looking through the console, it like, “What is this? It feels like every service's interface was designed by a different team, but that would—oh…” and then the light bulb went on. Yeah. You ship your culture.Jason: It's exactly it. It works for them, but I think if you're going to try to do something very, very, very different, you know, it's going to look a certain way. So, intentional design, I think, is part of what makes GitHub and other products like it special. And if you think about it, you have to have an end-to-end view, and then you can build verticals up and down inside of that. But it has to work on the horizontal, still.And then if you hire really smart people to build the verticals, you get those done. So, a good example of this is that I have a very strong opinion about the horizontal workflow nature of GitHub should look like in five years. I have a very loose opinion about what the matrix build system of Actions looks like. Because we have very, very smart people who are working on that specific problem, so long as that maps back and snaps into the horizontal workflows. And that's how it can work together.Corey: So, when you look at someone who is, I don't know, the CTO of a wildly renowned company that is basically still catering primarily to developers slash engineers, but let's be honest, geeks, it's natural to think that, oh, they must be the alpha geek. That doesn't really apply to you from everything I've been able to uncover. Am I just not digging deeply enough, or are you in fact, a terrible nerd?Jason: [laugh]. I am. I'm a terrible nerd. I am a very terrible nerd. I feel very lucky, obviously, to be in the position I'm in right now, in many ways, and people call me up and exactly that.It's like, “Hey, you must be king of the geeks.” And I'm like, “[laugh], ah, funny story here.” But um, you know, I joke that I'm not actually supposed to be in tech in first place, the way I grew up, and where I did, and how, I wasn't supposed to be here. And so, it's serendipitous that I am in tech. And then turns out I had an aptitude for distributed systems, and complex, you know, human systems as well. But when people dig in and they start talking about topics, I'm confounded. I never liked Star Wars, I never like Star Trek. Never got an anime, board games, I don't play video games—Corey: You are going to get letters.Jason: [laugh]. When I was at Canonical, oh, my goodness, the stuff I tried to hide about myself, and, like, learn, like, so who's this Boba Fett dude. And, you know, at some point, obviously, you don't have to pretend anymore, but you know, people still assume a bunch stuff because, quote, “Nerd” quote, “Geek” culture type of stuff. But you know, some interesting facts that people end up being surprised by with me is that, you know, I was very short in high school and I grew in college, so I decided that I wanted to take advantage of my newfound height and athleticism as you grow into your body. So, I started playing basketball, but I obsessed over it.I love getting good at something. So, I'd wake up at four o'clock in the morning, and go shoot baskets, and do drills for hours. Well, I got really good at it one point, and I end up playing in a Pro-Am basketball game with ex-NBA Harlem Globetrotter legends. And that's just not something you hear about in most engineering circles. You might expect that out of a salesperson or a marketing person who played pro ball—or amateur ball somewhere, or college ball or something like that. But not someone who ends up running the most important software company—from a technical perspective—in the world.Corey: It's weird. People counterintuitively think that, on some level, that code is the answer to all things. And that, oh, all this human interaction stuff, all the discussions, all the systems thinking, you have to fit a certain profile to do that, and anyone outside of that is, eh, they're not as valuable. They can get ignored. And we see that manifesting itself in different ways.And even if we take a look at people whose profess otherwise, we take a look at folks who are fresh out of a boot camp and don't understand much about the business world yet; they have transformed their lives—maybe they're fresh out of college, maybe didn't even go to college—and 18 weeks later, they are signing up for six-figure jobs. Meanwhile, you take a look at virtually any other business function, in order to have a relatively comparable degree of earning potential, it takes years of experience and being very focused on a whole bunch of other things. There's a massive distortion around technical roles, and that's a strange and difficult thing to wrap my head around. But as you're talking about it, it goes both ways, too. It's the idea of, “Oh, I'll become technical than branch into other things.” It sounded like you started off instead with a non-technical direction and then sort of adopted that from other sides. Is that right, or am I misremembering exactly how the story unfolds?Jason: No, that's about right. People say, “Hey, when did I start programming?” And it's very in vogue, I think, for a lot of people to say, “I started programming at three years old,” or five years old, or whatever, and got my first computer. I literally didn't get my first computer until I was 18-years-old. And I started programming when I got to a high school co-op with IBM at 17.It was Lotus Notes programming at the time. Had no exposure to it before. What I did, though, in college was IBM told me at the time, they said, “If you get a computer science degree will guarantee you a job.” Which for a kid who grew up the way I grew up, that is manna from heaven type of deal. Like, “You'll guarantee me a job inside where don't have to dig ditches all day or lay asphalt? Oh, my goodness. What's computer science? I'll go figure it out.”And when I got to school, what I realized was I was really far behind. Everyone was that ubergeek type of thing. So, what I did is I tried to hack the system, and what I said was, “What is a topic that nobody else has an advantage on from me?” And so I basically picked the internet because the internet was so new in the mid-'90s that most people were still not fully up to speed on it. And then the underpinnings in the internet, which basically become distributed systems, that's where I started to focus.And because no one had a real advantage, I just, you know, could catch up pretty quickly. But once I got into computers, it turned out that I was probably a very average developer, maybe even below average, but it was the system's thinking that I stood out on. And you know, large-scale distributed systems or architectures were very good for me. And then, you know, that applies not, like, directly, but it applies decently well to human systems. It's just, you know, different types of inputs and outputs. But if you think about organizations at scale, they're barely just really, really, really complex and kind of irrational distributed systems.Corey: Jason, thank you so much for taking the time to speak with me today. If people want to learn more about who you are, what you're up to, how you think about the world, where can they find you?Jason: Twitter's probably the best place at this point. Just @jasoncwarner on Twitter. I'm very unimaginative. My name is my GitHub handle. It's my Twitter username. And that's the best place that I, kind of, interact with folks these days. I do an AMA on GitHub. So, if you ever want to ask me anything, just kind of go to jasoncwarner/ama on GitHub and drop a question in one of the issues and I'll get to answering that. Yeah, those are the best spots.Corey: And we will, of course, include links to those things in the [show notes 00:33:52]. Thank you so much for taking the time to speak with me today. I really appreciate it.Jason: Thanks, Corey. It's been fun.Corey: Jason Warner, Chief Technology Officer at GitHub. 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 in your podcast platform of choice anyway, along with a comment that includes a patch.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.

Thursday, 7 October 2021   Then they returned to Jerusalem from the mount called Olivet, which is near Jerusalem, a Sabbath day's journey. Acts 1:12   The two men who appeared with the apostles just relayed the news of Christ's promised return. With that complete, nothing more is said of them. It simply states, “Then they returned to Jerusalem.”   In Luke 24, it says the following –   “Now it came to pass, while He blessed them, that He was parted from them and carried up into heaven. 52 And they worshiped Him, and returned to Jerusalem with great joy, 53 and were continually in the temple praising and blessing God. Amen.” Luke 24:51-53   The words, “And they worshiped Him,” appear to have occurred after His ascension. It may be that the confirming words of the two men that Jesus Christ is, in fact, the Lord (see previous commentary), resulted in a time of prayer and praise to God. If so, it is after this time of worship that they proceeded to head back to Jerusalem “from the mount called Olivet.”   The word translated as “Olivet” is found only here in the Bible, Elaión. It is derived from elaia, meaning “an olive tree.” It is the area where an orchard of olive trees was located. The mountain ridge is one that is separated from Jerusalem by the Kidron Valley. Of this walk from the Mount of Olives to Jerusalem, Luke specifically says that it is “a Sabbath day's journey.”   There are two possibilities for the inclusion of this statement. The first is that it is a general term used to describe the distance if it were a Sabbath, even if it was not a Sabbath. In other words, even if this was not a Saturday (Sabbath), it is the distance that would be considered allowable to walk on a Sabbath. This maximum distance is two thousand cubits as is seen in Joshua 3:4. It is about three-quarters of a mile. Luke is careful to give specific distances elsewhere, such as in Luke 24:13.   The other possibility is that this was, in fact, a Sabbath. As such, Luke is noting that the distance they walked was not a violation of the Sabbath laws. This would then mean that they had gone to the mount on Friday, and walked back Friday evening, the start of the Sabbath (or even Saturday morning after a night of worship and sleep). This would then be in accord with statements recorded by Luke, such as –   “And the women who had come with Him from Galilee followed after, and they observed the tomb and how His body was laid. 56 Then they returned and prepared spices and fragrant oils. And they rested on the Sabbath according to the commandment.” Luke 23:55, 56   Without being dogmatic, it would appear that Luke is stating this distance because it was a Sabbath. If so, then the traditional dating for the ascension is incorrect. The church places it ten days prior to Pentecost. Acts 1:3 says that Christ was seen “during forty days.” The Greek reads “through forty days.” As such, instead of a Thursday ascension, it very well could be a Friday (or Friday evening) ascension. Thus, Luke is now specifying that with the term “a Sabbath day's journey.”   If so, then the ascension of Christ until Pentecost is eight days. The reason this is possible is typology. Christ would then be seen to have completed all of His work and then entered into His rest on (or just at the coming of) the Sabbath. The importance of this for believers is explained in Hebrews 4 –   Therefore, since a promise remains of entering His rest, let us fear lest any of you seem to have come short of it. 2 For indeed the gospel was preached to us as well as to them; but the word which they heard did not profit them, not being mixed with faith in those who heard it. 3 For we who have believed do enter that rest, as He has said: “So I swore in My wrath, ‘They shall not enter My rest,'” although the works were finished from the foundation of the world. 4 For He has spoken in a certain place of the seventh day in this way: “And God rested on the seventh day from all His works”; 5 and again in this place: “They shall not enter My rest.” 6 Since therefore it remains that some must enter it, and those to whom it was first preached did not enter because of disobedience, 7 again He designates a certain day, saying in David, “Today,” after such a long time, as it has been said: “Today, if you will hear His voice, Do not harden your hearts.” 8 For if Joshua had given them rest, then He would not afterward have spoken of another day. 9 There remains therefore a rest for the people of God. 10 For he who has entered His rest has himself also ceased from his works as God did from His.” Hebrews 4:1-10   Believers enter into Christ's rest through faith in what He has done. As He is the Lord God, the typology would be appropriate.   Life application: The term “a Sabbath day's journey” prescribes nothing. Remember the five principal rules of proper biblical interpretation – Descriptive, Prescriptive, Context, Context, Context. Luke is describing what occurred, and quite possibly on the day it occurred. Luke is neither arguing for either a Sabbath observance nor is he stipulating that one can only walk so far on a Sabbath Day.   Rather, he was (possibly) stating that the recorded event occurred on a Sabbath, and this is his way of noting that fact. Today in Israel people observe the Sabbath. It is a fact that prescribes nothing for those who know they do.   Several times later in Acts, it will be noted that Paul went into the synagogues and preached on the Sabbath. This does not mean that Paul is prescribing Sabbath observance. Instead, it is describing to us what Paul did because the Jews (who had not come to Christ and who were being evangelized by Paul) were, in fact, Sabbath observers.   This is a problem with the Hebrew Roots Movement, Judaizers, etc. They take such descriptive passages in the book of Acts, and they treat them as prescriptive. This leads to a faulty hermeneutic. Such a doctrine places believers back under the Law of Moses. As such, it is heresy.   Christ is the end of the law for righteousness to everyone who believes (see Romans 10:4). Don't be misdirected by such people. Read Acts with the understanding that it is a historical recording of events. Nothing is prescribed by Luke's inclusion of the words of Acts 1:12. Hold fast to Christ alone and you will be in the sweet spot.   Lord God, how good it is to know that Jesus fulfilled the law on our behalf. In knowing this, we have every reason to rejoice in Him and what He has done. We are freed from the impossible yoke placed upon Israel through His full, final, and forever satisfaction of the law. Thank you, O God, for Christ Jesus our Lord. Amen.  

Inspired by the Mummy movies from Universal, Alfredo Salazar pens the Mexican horror film LA MOMIA AZTECA (1957) directed by Rafael Portillo! The film stars Ramón Gay, Rosa Arenas, Crox Alvarado and Jorge Mondragón. Can you take a Mummy movie outside of a pulpy, colonial context? Are there genre ties between horror and classic serials? Just what are Aztec mummies? We answer all these questions and more! Context setting 00:00; Synopsis 20:22; Discussion 32:36; Ranking 51:19.

GUEST: Dr. Angela Rasmussen on the Seattle woman who died after taking the J&J vaccine and more // The Forbes 400 list is out. . . and the richest Americans became 40% richer during the pandemic // SCENARIOS See omnystudio.com/listener for privacy information.

BASELINE 10.6.21CONTEXT#Daily #Moon, #Sun, #SchumannResonance, #Crypto, #USA, #Global, and #Spirit #News under 140 seconds.Brought to you by Phireon.com“The Choice is Yours”T.me/Phireon“Liberty is the New Punk”

About LaurenLauren Hasson is the Founder of DevelopHer, an award-winning career development platform that has empowered thousands of women in tech to get ahead, stand out, and earn more in their careers. She also works full-time on the frontlines of tech herself. By day, she is an accomplished software engineer at a leading Silicon Valley payments company where she is the architect of their voice payment system and messaging capabilities and is chiefly responsible for all of application security.Through DevelopHer, she's partnered with top tech companies like Google, Dell, Intuit, Armor, and more and has worked with top universities including Indiana and Tufts to bridge the gender gap in leadership, opportunity, and pay in tech for good. Additionally, she was invited to the United Nations to collaborate on the global EQUALS initiative to bridge the global gender divide in technology. Sought after across the globe for her insight and passionate voice, Lauren has started a movement that inspires women around the world to seek an understanding of their true value and to learn and continually grow.  Her work has been featured by industry-leading publications like IEEE Women in Engineering Magazine and Thrive Global and her ground-breaking platform has been recognized with fourteen prestigious awards for entrepreneurship, product innovation, diversity and leadership including the Women in IT Awards Silicon Valley Diversity Initiative of the Year Award, three Female Executive of the Year Awards, and recognition as a Finalist for the United Nations WSIS Stakeholder Prize.Links: DevelopHer: https://developher.com The DevelopHer Playbook: https://www.amazon.com/DevelopHer-Playbook-Simple-Advocate-Yourself-ebook/dp/B08SQM4P5J 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 could build you go ahead and build your own coding and mapping notification system, but it takes time, and it sucks! Alternately, consider Courier, who is sponsoring this episode. They make it easy. You can call a single send API for all of your notifications and channels. You can control the complexity around routing, retries, and deliverability and simplify your notification sequences with automation rules. Visit courier.com today and get started for free. If you wind up talking to them, tell them I sent you and watch them wince—because everyone does when you bring up my name. Thats the glorious part of being me. Once again, you could build your own notification system but why on god's flat earth would you do that?Corey: This episode is sponsored in part by Honeycomb. When production is running slow, it's hard to know where problems originate: is it your application code, users, or the underlying systems? I've got five bucks on DNS, personally. Why scroll through endless dashboards, while dealing with alert floods, going from tool to tool to tool that you employ, guessing at which puzzle pieces matter? Context switching and tool sprawl are slowly killing both your team and your business. You should care more about one of those than the other, which one is up to you. Drop the separate pillars and enter a world of getting one unified understanding of the one thing driving your business: production. With Honeycomb, you guess less and know more. Try it for free at Honeycomb.io/screaminginthecloud. Observability, it's more than just hipster monitoring. Corey: You could build you go ahead and build your own coding and mapping notification system, but it takes time, and it sucks! Alternately, consider Courier, who is sponsoring this episode. They make it easy. You can call a single send API for all of your notifications and channels. You can control the complexity around routing, retries, and deliverability and simplify your notification sequences with automation rules. Visit courier.com today and get started for free. If you wind up talking to them, tell them I sent you and watch them wince—because everyone does when you bring up my name. Thats the glorious part of being me. Once again, you could build your own notification system but why on god's flat earth would you do that?Corey: This episode is sponsored in part by our friends at Jellyfish. So, you're sitting in front of your office chair, bleary eyed, parked in front of a powerpoint and—oh my sweet feathery Jesus its the night before the board meeting, because of course it is! As you slot that crappy screenshot of traffic light colored excel tables into your deck, or sift through endless spreadsheets looking for just the right data set, have you ever wondered, why is it that sales and marketing get all this shiny, awesome analytics and inside tools? Whereas, engineering basically gets left with the dregs. Well, the founders of Jellyfish certainly did. That's why they created the Jellyfish Engineering Management Platform, but don't you dare call it JEMP! Designed to make it simple to analyze your engineering organization, Jellyfish ingests signals from your tech stack. Including JIRA, Git, and collaborative tools. Yes, depressing to think of those things as your tech stack but this is 2021. They use that to create a model that accurately reflects just how the breakdown of engineering work aligns with your wider business objectives. In other words, it translates from code into spreadsheet. When you have to explain what you're doing from an engineering perspective to people whose primary IDE is Microsoft Powerpoint, consider Jellyfish. Thats Jellyfish.co and tell them Corey sent you! Watch for the wince, thats my favorite part.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. A somewhat recurring theme of this show has been the business of cloud, and that touches on a lot of different things. One thing I've generally cognizant of not doing is talking to folks who don't look like me and asking them questions like, “Oh, that's great, but let's ignore everything that you're doing, and instead talk about what it's like not to be a cis-gendered white dude in tech,” because that's crappy. Today, we're sort of deviating from that because my guest is Lauren Hasson, the founder of DevelopHer, which is a career development platform that empowers women in tech to get ahead. Lauren, thanks for joining me.Lauren: Thanks so much for having me, Corey.Corey: So, you're the founder of DevelopHer, and that is ‘develop-her' as in ‘she'. I'm not going to be as distinct on that pronunciation, so if you think I'm saying ‘developer' and it doesn't make intellectual sense, listener, that's what's going on. But you're also a speaker, you're an author, and you work on the front lines of tech yourself. That's a lot of stuff. What's your story?Lauren: Yeah, I do. So, I'm not only the founder-developer, but I'm just like many of your listeners: I work on the front lines of tech myself. I work remotely from my home in Dallas for a Silicon Valley payments company, where I'm the architect of our voice payment system, and I up until recently was chiefly responsible for all of application security. Yeah, and I do keep busy.Corey: It certainly seems like it. Let's go back to, I guess, the headline item here. You are the founder of DevelopHer, and one thing that always drives me a little nutty is when people take a glance at what I do and then try and tell the story, and then effectively mess the whole thing up. What is DevelopHer?Lauren: So, DevelopHer is what I wish I had ten years ago—or actually nine years ago. It's an empowerment platform that helps individual women—men, too—get ahead in their careers, earn more, and stand out. And part of my story, you know, I have the degrees from undergrad in electrical engineering and computer science, but I went a completely different direction after graduating. And at the end of the Great Recession, I found myself with no job with no technical skills, and I mean, no job prospects, at all. It was really, really bad, ugly crying on my couch bad, Corey.And I took a number of steps to get ahead and really relearn my tech skills, and I only got one offer to give myself a chance. It was a 90-days to prove myself, to get ahead, and teach myself iOS. And I remember it was one of the most terrifying things I've ever done. And within two years, I not only managed to survive that 90-day period and keep that job, but I had completely managed to thrive. My work had been featured in Apple's iOS7 keynote, I'd won the company-wide award at a national agency four times, I had won the SXSW international Hackathon, twice in a row.And then probably the pinnacle of it all is I was one of 100 tech innovators worldwide invited to attend the [UKG 00:03:41] Innovation Conference. And they flew me there on a private 747 jet, and it was just unreal. And so I founded DevelopHer because I needed this ten years ago, when I was at rock bottom, to figure out how to get ahead: how do I get into my career; how do I stand out? And of course, you know there's more to the story, but I also found out I was underpaid after achieving all of that, that a male peer was paid exactly what I was paid, with no credentials, despite all of the awards that I won. And I went out and learned to negotiate, and tripled my salary in two years, and turned around and said, “I'm going to teach other women—and men, too—how to get real change in their own life.”Corey: I love hearing stories where people discover that they're underpaid. I mean, it's a bittersweet moment because on the one hand it's, “Wait, you mean they've been taking advantage of me?” And you feel bad for people, but at the same time, you're sort of watching the blindfold fall away from their eyes of, “Yeah, but it's been this way, and now you know about it. And now you're in a position to potentially do something about it.” I gave a talk at a tech conference a few years back called “Weasel your Way to the Top: How to Handle a Job Interview” and it was a fun talk.I really enjoyed it, but what I discovered was after I'd given it I got some very direct feedback of, “That's a great talk and you give a lot of really useful advice. What if I don't look like you?” And I realized, “Oh, my God, I built this out of things that worked for me and I unconsciously built all of my own biases and all of my own privilege into that talk.” At which point I immediately stopped giving it until I could relaunch it as a separate talk with a friend of mine, Sonia Gupta, who does not look like me. And between the two of us, it became a much stronger, much better talk.Lauren: It's good that you understand what you were bringing to the table and how you can appeal to an even larger audience. And what I've done is really said, “Here's my experience as a woman in tech, and here's what's worked for me.” And what's been surprising is men have said, “Yeah, that's what I did.” Except for I put a woman in tech spin on it and… I mean, I knew it worked for me; I have more than quintupled my base salary—just my base salary alone—in nine years. And the results that women are getting from my programming—I had one woman who earned $80,000 more in a single negotiation, which tells me, one, she was really underpaid, but she didn't just get one offer at $80,000 more; she got at least two. I mean, that changed her life.And I think the lowest I've heard is, like, $30,000 difference change. I mean, this is, this is life-changing for a lot of women. And the scary thing is that it's not just, say it's $50,000 a year. Well, over ten years, that's half a million dollars. Over 20 years, that's a million, and that's not even interest and inflation and compounding going into that. So, that's a huge difference.Corey: It absolutely is. It's one of those things that continues to set people further and further back. One thing that I think California got very right is they've outlawed recently asking what someone's previous compensation was because, “Oh, we don't want to give someone too big of a raise,” is a way you perpetuate the systemic inequality. And that's something that I wish more employers would do.Lauren: It's huge. I know the women and proponents who had moved that forward; some of them are personal friends of mine, and it's huge. And that's actually something that I trained specifically for is how to handle difficult questions like, “How much are you currently making?” Which you can't legally get asked in California, although it still happens, so how do you handle it if you still get asked and you don't want to rule yourself out? Or even worse—which they still can ask—which is, “How much do you want to make?”And a lot of times, people get asked that before they know anything about the job. And they basically, if you give an answer upfront, you're negotiating against yourself. And so I tackle tough things like that head-on. And I'm very much an engineer at heart, so for me, it's very methodical; I prepare scripts in advance to handle the pushback that I'm going to get, to handle the difficult questions. Without a doubt, I know all of my numbers, and that's where I'm getting real results for women is by taking the methodical approach to it.Corey: So, I spent my 20s in crippling credit card debt, and I was extremely mercenary, as a result. This wasn't because of some grand lost vision or something. Nope. I had terrible financial habits. So, every decision I made in that period of my life was extraordinarily mercenary. I would leave jobs I enjoyed for a job I couldn't stand because it paid $10,000 more.And the thing that I picked up from all of this, especially now having been on the other side of that running a company myself, is I'm not suggesting at any point that people should make career decisions based upon where they can make the most money, but that should factor in. One thing we do here at The Duckbill Group, in every job posting we put up is we post the salary range for the position. And I want to be clear here, it is less than anyone here could make at one of the big tech unicorns or a very hot startup that's growing meteorically, and we're upfront about that. We know that if money is the thing you're after and that is the driving force behind what you're going for, great; I don't fault you for that.This might not be the best role for you and that's perfectly okay. I get it. But you absolutely should know what your market worth is so you can make that decision from a place of being informed, rather than being naive and later discovering that you were taken advantage of.Lauren: So, I want to unpack just a couple things. There's just so many gold nuggets in that. Number one, for any employer listening out there, that is such a great best practice, to post the range. You're going to attract the right candidates when you post the right range. The last thing you want is to get to the end of the process to find out that, hey, you guys were totally off, and all the time invested could have been avoided if you'd had some sort of expectation set, upfront.That said, that's actually where I start with my negotiation training. A lot of people think I start with the money and that it's all about the money. That's not where I start. The very first thing I train women, and the men who've taken it, too, on the course is, figure out what success looks like to you. And not just the number success, but what does your life look like? What does your lifestyle look like? What does it feel like? What kinds of things do you do? What kinds of things do you value?Money is one of those components, but it's not all. And here's the reason I did that: because at a certain point in my life, I only got out at—broke even out of debt, you know, within the last five years. That's how underpaid I was at the time. But then once I started climbing out of debt, I started realizing it's not all about money. And that's actually how I ended up in my dream position.I mean, I'm living out how I define success today. Could I be making a lot more money at a big tech unicorn? Yeah, I could. But I also have this incredible lifestyle; it's sustainable. I get on apps like Blind and other internet forums, and I hear just horror stories of people burning out and the toxic cultures they work with. I don't have that at all. I have something that I could easily do for the next 50 years of my life if I live that long.But it's not by accident that I'm in the role that I'm in right now. I actually took the time to figure out what success looks like to me, and so when this opportunity came along—and I was looking at it alongside other opportunities that honestly paid more, I recognized this opportunity for what it was because I'd put in the work up front to figure out what success looks like to me. And so that's why what you guys are saying, “Hey, it's a lifestyle that you guys are supporting and mission that you're joining that's so important.” And you need to know that and do that work up front.Corey: That's I think what it really comes down to is understanding that in many cases… in fact, I'm going to take that back—in all cases, there's an inherent adversarial nature to the discussions you have about compensation with your employer or your prospective employer. And I say ‘adversarial' not antagonistic because you are misaligned as far as the ultimate purpose of the conversation. I'm not going to paint myself as some saint here and say that, oh, I'm on the side of every person I'm negotiating against, trying to get them to take a salary that's less than they deserve. Because, first, although I view myself that I'm not in that position, you have to take that on faith from me, and I think that is too far of a bridge to cross. So, take even what I'm saying now from the position as someone who has a vested interest in the outcomes of that negotiation.I mean, we're not one of those unicorn startups; we can't outbid Netflix and we wouldn't even try to. We're one of those old-fashioned businesses that has taken no investment and we fund ourselves through the magic of revenue and profitability, which means we don't have a SoftBank-sized [laugh] war chest sitting in the bank that we can use to just hurl ridiculous money at people and see who pans out. Hiring has to be intentional and thoughtful because we're a very small team. And if you're looking for something that doesn't align with that, great; I certainly don't blame you. That isn't this, and that's okay, I'm not trying to hire everyone.And if it's not going to work out, why wouldn't we say that upfront to avoid trying to get to all the way at the end of a very expensive interview process—both in terms of time and investment and emotionally—only to figure out that we're worlds apart on comp, and it's never going to work.Lauren: A hundred percent agree. I mean, I've been through it on both ends, both as someone who is being hired and also as a hiring manager, and I understand it. And you need to find alignment, and that's what negotiation is all about is finding an alignment, finding something where everyone feels like they're winning in the situation. And I'm a big proponent—and this is going to go so counterculture—I think a lot of people overlook a lot of opportunities that are just golden nuggets. I think there's a lot of idol worship of the big tech companies.And don't get me wrong; I'm sure they pay really well, great opportunity for your career, but I think people are overlooking a lot of really great career opportunities to get experience, and responsibility, and have good pay and lifestyle. And I'm a big proponent and looking for those golden nuggets rather than shooting for one of the big tech unicorns.Corey: And other people are going to have a very different perspective on that, and that is absolutely okay. So, tell me a little bit more about what it is that DevelopHer does and how you go about doing it because it's one thing to say, “Oh, we help women figure out that they are being underpaid,” but there's a whole lot of questions that opens up because great. How do you do that?Lauren: I do a number of things. So, it's not all about pay either. Part of it's building your value, building your confidence, standing out, getting ahead. DevelopHer started, actually, as a podcast. Funny story; I wanted to solve the problem of, we need more technical women as visible leaders out there, and I said, “Where are the architects? Where are the CTOs? Where are the CSOs?”And I didn't think anyone would care about me. I mean, I'm not Sheryl Sandberg; I'm not [laugh] the CEO of Facebook. Who's going to listen to me? And then I was actually surprised when people cared about my own story, about coming back from being underpaid and then getting back into tech and figuring out how to stand out in such a short amount of time. And other women were saying, “Well, how did you do it?”And it wasn't just women; it was men, too, saying, “Hey, I also don't know how to effectively advocate for myself.” And then it was companies saying, “Hey, can you come in and help us build our internal bench, recruit more women to come work for us, and build our own women leaders?” And then I've started working with universities to help bridge the gap before it even starts. I partnered with major universities to license my program and train them, not only how do you negotiate for what you're worth, for your first salary, but also how do you come in and immediately make an impact and accelerate your career growth? And then, of course, I work with individual women.I've talked about I have a salary negotiation course that's won a couple awards for the work, the results that it's getting, but then I just recently wrote a book because I wanted to reach women and men at scale and help them really get ahead. And this was literally my playbook. It's called The DevelopHer Playbook. And it's, how did I break into tech? And then once I was in tech, how did I get ahead so quickly? And it's not rocket science. And that's what I'm working on is training other people do it. And look, I'm still learning; I'm still paving my own path forward in tech, myself.Corey: This episode is sponsored in part by our friends at Jellyfish. So, you're sitting in front of your office chair, bleary eyed, parked in front of a powerpoint and—oh my sweet feathery Jesus its the night before the board meeting, because of course it is! As you slot that crappy screenshot of traffic light colored excel tables into your deck, or sift through endless spreadsheets looking for just the right data set, have you ever wondered, why is it that sales and marketing get all this shiny, awesome analytics and inside tools? Whereas, engineering basically gets left with the dregs. Well, the founders of Jellyfish certainly did. That's why they created the Jellyfish Engineering Management Platform, but don't you dare call it JEMP! Designed to make it simple to analyze your engineering organization, Jellyfish ingests signals from your tech stack. Including JIRA, Git, and collaborative tools. Yes, depressing to think of those things as your tech stack but this is 2021. They use that to create a model that accurately reflects just how the breakdown of engineering work aligns with your wider business objectives. In other words, it translates from code into spreadsheet. When you have to explain what you're doing from an engineering perspective to people whose primary IDE is Microsoft Powerpoint, consider Jellyfish. Thats Jellyfish.co and tell them Corey sent you! Watch for the wince, thats my favorite part.Corey: I feel like no one really has a great plan for, “Oh, where are you going next in tech? Do you have this whole thing charted out?” “Of course not. I'm doing this fly by night, seat of my pants, if I'm being perfectly honest with you.” And it's hard to know where to go next.What's interesting to me is that you talk about helping people individually—generally women—through your program, but you also work directly with companies. And when you're talking about things like salary negotiation, I think a natural question that flows from that is, are there aspects of what you wind up talking to individuals about versus what you do when talking to companies that are in opposition to each other?Lauren: Yeah, so that's a great question. So, the answer is there are some progressive companies that have brought me in to do salary negotiation training. Complete candor, most companies aren't interested. It's my Zero-To-Hero DevelopHer Playbook program which is, how do you get ahead? How do you build your value, become an asset at the company?So, it's less focused on pay, but more how do you become more valuable, and get ahead and add more value to the company? And that's where I work with the individuals and the companies on that front.Corey: It does seem like it would be a difficult sell, in most enterprise scenarios, to get a company to pay someone to come in to teach their staff how to more effectively [laugh] negotiate their next raise. I love the vision.Lauren: It has happened. I also thought it was crazy, but it has happened. But no, most of my corporate clients say, “We not only want to encourage more women into tech, but we already have a lot of women who are already in our ranks, and we want to encourage them to really feel like they're empowered and to stand out and reach the next levels.” And that's my sweet spot for corporate.Corey: Somewhat recently, I was asked on a Twitter Spaces—which is like Clubhouse but somehow different and strange—did I think that the privilege that I brought to what I do had enabled me to do these things, being white, being a man, being cis-gendered—speaking English as my primary language was an interesting one that I hadn't heard contextualized like that before—and whether that had advantaged me as I went through these things? And I think it's impossible to say anything other than absolutely because it's easy to, on some level, take a step back and think, “Well, I've built this company, and this media platform, and the rest. And that wasn't given to me; I had to build it.” And that's absolutely true. I did have to build it, and it wasn't given to me.But as I was building it, the winds were at my back not against me. I was not surrounded by people who are telling me I couldn't do it. Every misstep I made wasn't questioned as, well, you sure you should be doing this thing that you're not really doing? It was very much a fail-forward. And if you think that applies to everyone, then you are grievously mistaken.Lauren: I think that's a healthy perspective, which is why I consider you one of developers in my strongest allies, the fact that you're willing to look at yourself and go, “What advantages did I have? And how might I need to adapt my messaging or my advice so that it's applicable to even more people?” But it's also something I've experienced myself. I mean, I set out to help women in tech because I'm in women in tech myself. And I was surprised by a couple of things.Number one, I was surprised that men were [laugh] asking me for advice as well. And individuals and medicine, and finance, and law, in business not even related to tech, but what I'm really proud of that I didn't set out to build because I didn't feel qualified, but I'm really glad that I've been able to serve is that there were three populations that I've been really able to serve, especially at the university level. Number one, international students who, you mentioned yourself, English might not be their first language, but they're not familiar with the US hiring and advancement and pay process, and I help normalize that. And that's something that I myself in the benefit of, having been born here in the US. People who, where English isn't their first language; you think it's hard enough to answer, “Why do you think you should be promoted?”Or, “How much do you think you should make for this role? What do you want?” In your first language? Try answering it in your third, right? And then when I'm really proud of is, especially at the university level, I've been really able to help students where they're first-generation college students, where they don't have a professional mentor within their immediate family.And providing them a roadmap—or actually, the playbook to how to get ahead and then how to advocate for yourself. And these were things that I didn't feel qualified to help, but these are the individuals who've ended up coming and utilizing my program, and finding a lot of benefit from that. And it made me realize that I'm doing something bigger than I even set out to do, and that is very meaningful to me.Corey: You mentioned that you give guidance on salary negotiation and career advancement to not just women, but also men, and not just people who are in tech, but people who are in other business areas as well. How does what you're advising people to do shift—if at all—from folks who are women working in tech?Lauren: So, that's the key is it really doesn't shift. What I'm teaching are fundamentals and, spoiler alert, I teach grounding yourself in data, and knowing your data, and taking the emotion out of the process, whether you're trying to get ahead, to stand out, to earn more. And I teach fundamentals, which is five-point process.Number one, you got to figure out what success looks like to you. I talked a little bit about that earlier, but it's foundational. I mean, I start with that because that alone changed my life. I would still be pursuing success today and not have reached it, but I'm living out how I defined success because I started there.Then you got to really know your worth. Absolutely without a doubt, know how much you're worth. And for me, this was transformational. I mean, eye-opening. Like you said earlier, the blindfold coming off. When I saw for a fact how much employers paid other people with my skill sets, it was a game-changer for me. And so I—without a shadow of a doubt, I use four different strategies, multiple resources in each strategy to know comprehensively how much I'm worth.And then I teach knowing your numbers. It's not an emotional thing; it's very much scientific, so I talked about knowing your key numbers, your target, your ask, and your walk away, and those are all very dependent on your employment and financial situation, so it's different from person to person. And then I talk about—and this is a little different than what other people teach—is I talk about finding leverage, what you uniquely bring to the table, or identifying companies where you uniquely add value, where you can either lock in an offer or negotiate a premium.And then I prepare. I prepare. Just like you prepare for an interview, I prepare for a negotiation, and if I'm asking for the right amount of money, I am going to be prepared for pushback and I want to be able to handle that, and I don't want to just know it on the fly; I want to have scripts and questions prepared to handle that pushback. I want to be prepared to answer some of the most difficult questions that you're going—get asked, like we talked about earlier.And then the final step is I practice over and over and over again, just like a sporting event. I am ready to go into action and get a great thing. So, those are the fundamentals. I've marketed to women in tech because I'm a woman in tech and we don't have enough women in tech, and women are 82 cents on the dollar in tech, but what I found is that doctors were using the same methodology. I wasn't marketing it to them. Lawyers, business people, finance people were using it because I was teaching such fundamentals.Corey: Taking it one step further, if someone is listening to this and starting to get a glimmering of the sense that they're not where they could be career-wise, either in terms of compensation, advancement, et cetera, what advice would you have for them as far as things to focus on first? Not to effectively extract the entire content of your course into podcast form, but where do they start?Lauren: Yeah. So, you start by investing in yourself and investing in the change that you want. And that first investment might be figuring out how much you're worth, you know, doing that research to figure out how much you're worth. And then going out and learning the skills. And look, I have a course, I have a book that you can use to get ahead; if I'm not the right fit, there are a ton of resources out there. The trick is to find the best fit for you.And my only regret as I look back over the last 10, 15 years of my career is that I didn't invest in myself sooner and that I didn't go out and figure out how much I was worth, and that I—when they said, “Well, you're just not there yet,” when I asked for more money, that I believed them. And that was on me that I didn't go out and go, “I wonder how much I'm worth?” And do the research. And then, I regret not hiring a career coach earlier. I wish I'd gotten back into tech sooner.And I wish that I had learned to negotiate and advocate for myself sooner. But my knack, Corey—and I believe things happen to me for a reason—is my special skills is I take things that were meant not necessarily intentionally to harm me, but things that hurt me, I learned from them, I turn it around in the best way possible, and then I teach and I create programs to help uplift other people. And that's my special skill set; that's sort of my mission and purpose in life, and now I'm just trying to really exploit it and make this into a big movement that impacts millions of lives.Corey: So, what's next for you? You've built this platform, you've put yourself out there, you've clearly made a dent in the direction that you're heading in. What's next?Lauren: [laugh]. I am looking to scale. I'm just like any company; I've really focused on delivering value proof of concept. What a lot of people don't realize is not only did I build DevelopHer in quote, “my spare time,” but I did this without any outside investors. I funded it at all myself, built it on my own sweat equity—Corey: [laugh]. That one resonates.Lauren: Yeah. [laugh]. I know you know what that feels like. And so for me, I'm focused on scale: bringing in more corporate partners; bringing in more university clients, to scale and bridge the gap before it even starts; and scaling and reaching more women and men and anyone who wants to figure out how to get ahead, stand out, and earn more. And so the next year, two years are really focused on scale.Corey: If people want to learn more about what you do, how you do it, or potentially look at improving their own situations, where can they find you?Lauren: I am online. Go to developher.com. I have resources for individuals; I have a book, which is a great, cost-effective way to learn a lot.I have an award-winning negotiation course that helps you go out and earn what you're truly worth, and I have a membership to connect with me and other like-minded individuals. If you're a company leader, I work with companies all the time to train their women—and men, too—to get ahead and build their value. And then also, I work with universities as well to help bridge the gender wage gap before it starts, and builds future leaders.Corey: And we will, of course, include links to that in the [show notes 00:27:55]. Thank you so much for taking the time to speak with me today. I really appreciate it.Lauren: Corey, thank you so much for having me, and I really mean it. You know, Corey is a strong ally. We connected, and I am glad to count you as not only my own ally but an ally of DevelopHer.Corey: Well, thank you. That's incredibly touching to hear. I appreciate it.Lauren: I mean it.Corey: Thank you. Sometimes all you can say to a sincere compliment is, “Thank you.” Arguing it is an insult, and I'm not that bold. [laugh].Lauren: That's actually really good advice that I give women is, so many times, we cut down our own compliments. And so that's a great example right there, and it is not just women who sometimes I have a challenge with it; men, too. When someone gives you a compliment, just say, “Thank you.”Corey: Good advice for any age, in any era. Lauren Hasson, founder of DevelopHer, speaker, author, frontline engineer some days. 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 and an insulting comment telling me that my company is never going to succeed if I don't attempt to outbid Netflix.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.

Don't forget to subscribe. --- Send in a voice message: https://anchor.fm/beau-of-the-fifth-column/message Support this podcast: https://anchor.fm/beau-of-the-fifth-column/support

This week's show is with Dr. Paul J. Leslie. Paul is a psychotherapist, author, and educator in Aiken, South Carolina. Paul is a licensed therapist and a National Board Certified Fellow in Hypnotherapy. He has a doctorate in Counseling Psychology and is presently the coordinator of the psychology program at Aiken Technical College. He has authored eight books which focus on the areas of transformative psychotherapy, healing, shamanism, and personal development. Paul is a popular trainer of Solution-Based therapies, Ericksonian Hypnosis, and creative coaching applications. In this show, Paul and Lian explored the parallels between magic and psychotherapy, the power of our context for creating the life we live, how and why we make distinctions and how they can be limiting, and how we can move from a “problem solving existence” to a magical life in which we listen to our own hearts to guide us. I'd love to know what YOU think about this week's show. Let's carry on the conversation…  please leave a comment below. What you'll learn from this episode: What is your Context? This is the filter through which you will see everything and create within. Paul talked about the way we make distinctions - this is natural and unavoidable, the invitation is to notice when our distinction has become a problem or limitation that is creating a life that isn't the one we desire  I love how Paul talked about experience vs information... this is especially relevant for coaches and therapists but is actually so helpful for all of us who wish to create a life of wonder and meaning. Resources and stuff that we spoke about: Dr. Paul J. Leslie's Official Website Dr. Paul J. Leslie's Social Media: Facebook Page YouTube Channel  LinkedIn Dr. Paul J. Leslie's Books Transforming Themes: Creative Perspectives on Therapeutic Interaction The Art of Creating a Magical Session Unlimited Resources: Simple and Easy Ways to Find, Access, and Utilize Client Strengths and Resources to Facilitate Change Potential Not Pathology: Helping Your Clients Transform Using Ericksonian Psychotherapy The Year of Living Magically: Practical Ways to Create a Life of Spirit, Wonder and Connection Low Country Shamanism Shadows in the Session Get Out of Your Seat!: An Average Passenger's Guide To Overcoming Airline Terror Thank you for listening! There's fresh episode each week, if you subscribe then you'll get each new episode delivered to your phone every Tuesday (that way you'll never miss an episode): Subscribe on Apple Podcasts/iTunes Subscribe on Android Thank you! Lian & Jonathan

Even the smallest youth ministries can be healthy and help young people become disciples for life. DCE Leah Abel joins Mark and Julianna in talking about the strengths and how God can work through small youth ministries. Find the LCMS Youth Ministry resource website at youthesource.com. Bio: Leah Abel is a Director of Christian Education who lives in Denver, Colorado.  Leah graduated from Concordia University Nebraska and spent 11 years serving as a DCE in Florida and another six years serving youth and families in Colorado.  She now serves as a Project Manager & Ministry Facilitator who serves events like the LCMS Youth Gathering and the National Lutheran Youth Workers Conference as well as churches and church workers.  Leah loves her husband, Scott, who is an LCMS pastor and their wonderful daughter, Amelia.  Leah also loves great music, cooking, being outdoors, and a great cup of coffee.

Episode length: 35:31 Authors: Teunissen et. al. Publication details: Contextual Competence: How residents develop competent performance in new settings Med Educ 2021 Sep;55(9):1100-1109 View the abstract here Follow our co-hosts on Twitter! Jason R. Frank: @drjfrank  Jonathan Sherbino: @sherbino  Linda Snell: @LindaSMedEd  Want to learn more about KeyLIME? Click here! A transcript of this episode is available upon request.

On Episode 396 of the Colombia Calling podcast, we get to discuss the disease of leishmaniasis in the context of the Colombian armed conflict and post conflict period with post doctoral fellow Lina Beatriz Pinto-Garcia. Pinto Garcia's ethnographic monograph explores how the Colombian armed conflict and a vector-borne disease called cutaneous leishmaniasis are inextricably connected and mutually constitutive. The stigmatization of the illness as “the guerrilla disease” or the "subversive disease," is reinforced by the state's restriction on access to antileishmanial medicines, a measure that is commonly interpreted as a warfare strategy to affect insurgent groups. Situated at the intersection between STS (Science and Technology Studies) and critical medical anthropology, her work draws on multi-sited field research conducted during the peace implementation period after the agreement reached by the Colombian government and FARC, the oldest and largest guerrilla organization in Latin America. It engages not only with the stigmatization of leishmaniasis patients as guerrilla members and the exclusionary access to antileishmanial drugs but also with other closely related aspects that constitute the war-shaped experience of leishmaniasis in Colombia. This work illuminates how leishmaniasis has been socially, discursively, and materially constructed as a disease of the war, and how the armed conflict is entangled with the realm of public health, medicine, and especially pharmaceutical drugs. The problems associated with coca cultivation and leishmaniasis cannot be dissociated from cross-border events such as forced disappearance and the massive migration of Venezuelans who arrive in Colombia looking for survival alternatives, including coca production. Tune in and hear about the Diseased Landscapes project https://www.insis.ox.ac.uk/diseased-l...

In this episode, host Anita Fuentes investigates the implications of the U.S. withdrawal from Afghanistan from different angles with the help of guests Rafia Zakaria and Professor Michael Klare. Rafia Zakaria talks about her new book, Against White Feminism (2021), and how it ties into Western media coverage of Afghan women. Fuentes also speaks to Professor Michael Klare, defense correspondent at The Nation magazine, about his take on the US withdrawal from Afghanistan; a very different one to those being portrayed in mainstream media. The episode ends with a September media roundup, a brief section in which news articles, reports, and other materials focusing on (in)security issues are discussed. Security in Context is a podcast project from the research network of the same name, aimed at promoting new thinking on security from a global perspective. It features discussions about key questions on peace and conflict, the political economy of security and insecurity, militarism, and geopolitics, as they intersect with the processes of climate change, population movement, and the reorganization of global powers. In order to delve into these topics, we interview writers, researchers, activists and professionals from inside and outside the Security in Context network.

Quick Take CrypToadz by GREMPLIN reaches 13Ξ and more than $88 million in total trading volume. Utopia Labs exits stealth mode to build infrastructure tooling for DAO payments and accounting. Bank of America makes remarks on DeFi and NFTs in it's latest Digital Asset Primer. Context releases beta version of Web 3.0 app for following crypto wallets.   Read more: https://ether.fm/034

Hello there! So glad you could make it!Today we are beginning a new series. This will be a longer series on the book of Acts. Josh Harrison is here to kick us off into this series by providing some much-needed context to understanding why and how we got here.Join us next Sunday in person at 10am, or online at 5pm!Links:Instagram - https://www.instagram.com/canopy.church/Website - canopy.church- App -  Apple Store - https://apps.apple.com/us/app/canopy-church/id1528251871Google Play - https://play.google.com/store/apps/details?id=io.pushpay.canopychurch- Come say Hi! -In person: 792 Victoria Costa Mesa, CA 92627 @ 10am- We also have our Families Ministry available for children 4 years - 5th grade! So bring the kiddos!Online: Service will be uploaded Sunday evenings around 5pm, right on YouTube! Or available to listen in podcast form, anywhere you stream your podcasts!

From Kingdom In Context Streamed Live Oct 02, 2021 Weekly Portion: Deuteronomy 31: 1-30 Companion Passages: Joshua 3: 1-17 Jeremiah 34: 1-17 1 Enoch 89: 26-41 ~~~ Kingdom In Context Follow Sean Griffin @Twitter, Instagram, Facebook You can support Sean @PayPal &Patreon Make personal check payable to Sean Griffin @ PO Box 1266, Ft. Collins, CO 80522 ~~~~~~~ Please leave a review wherever you can to help propagate the word. If this blessed you, just please share it. Contact Me My Twitter --- Send in a voice message: https://anchor.fm/begoodbroadcast/message Support this podcast: https://anchor.fm/begoodbroadcast/support

Pastor Michael Lodge Jesus' first miracle laid a foundation for the rest of His ministry.  Jesus was not just the life of the party.  Jesus was demonstrating how He breathes abundant life into every area of our lives through His redemption story!  Click on the links below for additional Cascade Church resources. Connect Card: https://cascadechurch.org/connectcard Give Online: https://cascadechurch.org/give Kid's Resources: https://cascadechurch.org/children Context of John Guide: https://bit.ly/3nBBXdf

The Second Civil War . . . . You or your employees could be Republican, Democrat, Libertarian, Trump-loving or Trump-hating, but the bottom line is that whatever someone's politics are, if we don't handle them extraordinarily well, things are going to get far worse. So what can we do? Let's find out together... Our guest is Peter Montoya. Peter is a thought leader, skilled orator, tech entrepreneur, and successful business strategist. His expertise comes from decades of being deep in the trenches. Peter successfully grew his software company, Marketing.Pro, from a three-person start-up to a multi-million-dollar exit, all without partners or investors. Peter is currently building his latest game-changing tech start-up, Urth.media, which is on track to transform the social media landscape by providing a civil, community-driven platform free of bots, trolls, and misinformation. His newest book, The Second Civil War: A Citizen's Guide to Healing our Fractured Nation, was released on August 3, 2021 and immediately became a bestseller. Website: https://www.petermontoya.com/ & Urth.media. Social Media https://www.facebook.com/ThriveUnion https://twitter.com/petermontoya1 https://www.linkedin.com/in/petermontoya . . Part 2) The Most Agitating Action You Can Take to Bring Yourself Peace  Every Side is Listening to The Wrong People Content, Context and Reputation Social Vs Civil Media Who's Right or What's Right Cooling and Framing Political Conversations in The Workplace is This YOU, or... . . . . When you're curious about how to tap into what drives meaning in your life and create meaningful transformation in the lives you touch. Take a look at DovBaron.com Learn more about your ad choices. Visit megaphone.fm/adchoices

The Context of White Supremacy hosts The Context of White Supremacy hosts the weekly Compensatory Call-In. We encourage non-white listeners to dial in with their codified concepts, new terms, observations, research findings, workplace problems or triumphs, and/or suggestions on how best to Replace White Supremacy With Justice ASAP. We'll use these sessions to hone our use of words as tools to reveal truth, neutralize White people. We'll examine news reports from the past seven days and – hopefully – promote a constructive dialog. #ANTIBLACKNESS The self-proclaimed "pied piper of R&B" R. Kelly was found guilty on charges of racketeering, sexual exploitation of a child and other lurid sex crimes. He scheduled for sentencing in May of this year, and numerous legal experts suspect Kelly, 54, will die in greater confinement. As opposed to connecting this case to Simone Biles's abuse at the hands of Larry Nassar, the defunct Boy Scouts of America, or the countless other examples of children being de-valued and sexually exploited, this case was generally isolated as a "victory" for black "girls and women," and/or an example of the disregard for black females. When not bashing R. Kelly, mainstream news outlets paused briefly to excoriate a small number of black male NBA players who've hesitated to receive vaccinations. A number of black people have been employed to join in ridiculing - sometimes name-calling - black people for their medical choices. #WhiteSupremacyIsTerrorism INVEST in The COWS – http://paypal.me/TheCOWS Cash App: https://cash.app/$TheCOWS CALL IN NUMBER: 720.716.7300 CODE: 564943#

This week; due to Shaun's illness we weren't able to get a proper episode up, but we do have a selection of some of our favorite pre-episode banters that are normally only available to our patrons! Once again, a big thanks go out to David and Jordan of Shonen Flop (@shonenflopcast and www.shonenflop.com) for allowing us to include the tragedy of Big Tony! Meanwhile, did Dylan commit arson? If you'd like to give us feedback, ask a question, or correct a mistake, send an email to AnimeOutOfContext@gmail.com or tweet at us @AnimeConPod. Visit our Patreon at patreon.com/AnimeoutofContext if you would like to contribute to the show and get bonus content ranging from clips from our pre-episode banter, to our prototype Episode 0, to even getting shoutouts in the show! Intro and Outro are a trimmed from "Remiga Impulse" by Jens Kiilstofte, licensed by MachinimaSound to Anime Out of Context under CC BY-NC-ND 4.0 which has been modified by the licensor for the licensee to allow reproduction and sharing of the Adapted Material for Commercial purposes Video episodes generated by Headliner.app

Birthday boy Johnny Cochrane, mic'd up Matt Kandela, and Pete Wood all gather to chat through a tough game away at Brighton. We discuss the timid performances of Sambi and Partey We do a heat check on Aaron Ramsdale We discuss whether the result was good or bad given the context of the season so far We set the tone for post-international break. Arteta goes into round 3 of the season, can he win? Thank you for listening, leave a review if you like what you are hearing!

The Context of White Supremacy hosts the weekly summit on Neutralizing Workplace Racism. October means the start of more stringent vaccine requirements in many areas across the U.S. United Airlines reportedly began firing workers who've not received the jab. Airlines are also managing ongoing "Air Rage," where mostly White passengers threaten fellow passengers or crew while flaunting mask mandates and in-flight regulations. Conduct has been so dangerous some flight crew members have questioned their career choice. In the NBA, similar to United Airlines, the vast majority of employees are fully vaccinated. However, a great deal of attention is focused on the small number of black players who're hesitating on receiving a shot. #VaccineSurcharge INVEST in The COWS – http://paypal.me/TheCOWS Cash App: https://cash.app/$TheCOWS CALL IN NUMBER: 720.716.7300 CODE: 564943#

  Nickolaus Bauer speaks to Pratiba Daya, Programme Co-Ordinator in South Africa Brahma Kumaris about non-violent way to fight our problems   See omnystudio.com/listener for privacy information.

The Context of White Supremacy hosts the 9th and final study session on Woody Allen's 2020 autobiography, Apropos of Nothing. One of the most critically revered movie-makers of all time, Woody Allen is a New York City and entertainment icon. In addition to his flicks, he's an acclaimed comedian, a concert-playing musician, and bestselling author - Apropos of Nothing being his most recent text. Published in 2020, the book recounts his life, entertainment career, and "romance" with Soon-Yi Previn. In addition to being non-white, adopted/abducted from Korea, Previn is thirty-five years younger than Allen. Despite a damning Child Protective Services investigation and years of allegations of child rape and sexual abuse of children, Allen remains beloved my hoards of Whites. We'll examine this work for what it reveals about White culture. During our last reading, Allen explains how he hired a black male, the late Geoffrey Holder. Allen explained that his film required an "exotic" element, and Holder fit the bill. Tellingly, this 1972 film is: Everything You Always Wanted To Know About Sex, But Were Afraid To Ask. When not making films, Allen describes going on a musical tour, where he "steals" from the same black New Orleans jazz legends he previously branded as "primitive" When not making films for Whites, Allen confesses one of his top enjoyments was being home to "fondle" Soon-Yi. He later refers to an article that describes Soon-Yi as a "dominatrix" in their relationship, but there are no quotes or citations confirm. #ChildRape INVEST in The COWS – http://paypal.me/TheCOWS Cash App: https://cash.app/$TheCOWS CALL IN NUMBER: 720.716.7300 CODE: 564943#

Rabbi Matt Rosenberg of https://shalomseattle.com/ (Restoration Synagogue) in Seattle, author of "Jesus Never Said Anything New" visited Life Church and provided rarely-considered context to the Jewishness of Jesus, his actions and his teaching. Pastors Sonny Hennessy and Scott Eastman exchange their thoughts on the message and of what it means for us. -- Watch the full message we're chewing on http://bit.ly/LCGBHomepage (here) http://bit.ly/discussnowpc (Download) the discussion questions for your pocket Support this podcast

Deeper Christian Podcast • Episode 217 Studying the Bible in light of its context is of utmost importance. In this particular episode, we conclude our mini-series looking at seven important types of context you need to keep in mind as you study Scripture. As we examine the last three types of contexts (scriptural, geographical, visual), learn what these contexts are, why they are important, and hear some examples of how studying the Bible in light of history and culture helps you understand the Bible. ----------------- View the shownotes for this episode and get other Christ-centered teaching and resources at: https://deeperchristian.com/217/ (deeperChristian.com/217/) Support this podcast

Performance and context matters a lot. One cannot follow a programming without understanding context and intent.