Podcasts about invent

Full Description / Show Notes Corey and Linda talk about Tiktok and the online developer community (1:18) Linda talks about what prompted her to want to work at AWS (5:29) Linda discusses navigating the change from just being part of the developer community to being an employee of AWS (10:37) Linda talks about moving AWS more in the direction of short form content, and Corey and Linda talk about the Tiktok algorithm (15:56) Linda talks about the potential struggle of going from short form to long form content (25:21) About LindaLinda Vivah is a Site Reliability Engineer for a major media organization in NYC, a tech content creator, an AWS community builder member, a part-time wedding singer, and the founder of a STEM jewelry shop called Coding Crystals. At the time of this recording she was about to join AWS in her current position as a Developer Advocate.Linda had an untraditional journey into tech. She was a Philosophy major in college and began her career in journalism. In 2015, she quit her tv job to attend The Flatiron School, a full stack web development immersive program in NYC. She worked as a full-stack developer building web applications for 5 years before shifting into SRE to work on the cloud end internally.Throughout the years, she's created tech content on platforms like TikTok & Instagram and believes that sometimes the best way to learn is to teach.Links Referenced:lindavivah.com: https://lindavivah.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: Let's face it, on-call firefighting at 2am is stressful! So there's good news and there's bad news. The bad news is that you probably can't prevent incidents from happening, but the good news is that incident.io makes incidents less stressful and a lot more valuable. incident.io is a Slack-native incident management platform that allows you to automate incident processes, focus on fixing the issues and learn from incident insights to improve site reliability and fix your vulnerabilities. Try incident.io, recover faster and sleep more.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. We talk a lot about how people go about getting into this ridiculous industry of ours, and I've talked a little bit about how I go about finding interesting and varied guests to show up and help me indulge my ongoing love affair on this show with the sound of my own voice. Today, we're going to be able to address both of those because today I'm speaking to Linda Haviv, who, as of this recording, has accepted a job as a Developer Advocate at AWS, but has not started. Linda, welcome to the show.Linda: Thank you so much for having me, Corey. Happy to be here.Corey: So, you and I have been talking for a while and there's been a lot of interesting things I learned along the way. You were one of the first people I encountered when I joined the TikToks, as all the kids do these days, and was trying to figure out is there a community of folks who use AWS. Which really boils down to, “So, where are these people that are sad all the time?” Well, it turns out, they're on TikTok, so there we go. We found my people.And that was great. And we started talking, and it turns out that we were both in the AWS community builder program. And we've developed a bit of a rapport. We talk about different things. And then, I guess, weird stuff started happening, in the context of you were—you're doing very well at building an audience for yourself on TikTok.I tried it, and it was—my sense of humor sometimes works, sometimes doesn't. I've had challenges in finding any reasonable way to monetize it because a 30-second video doesn't really give nuance for a full ad read, for example. And you've been looking at it from the perspective of a content creator looking to build the audience slash platform is step one, and then, eh, step two, you'll sort of figure out aspects of monetization later. Which, honestly, is a way easier way to do it in hindsight, but, yeah, the things that we learn. Now, that you're going to AWS, first, you planning to still be on the TikToks and whatnot?Linda: Absolutely. So, I really look at TikTok as a funnel. I don't think it's the main place, you're going to get that deep-dive content but I think it's a great way, especially for things that excite you or get you into understanding it, especially beginner-type audience, I think there's a lot of untapped market of people looking to into tech, or technologists that aren't in the cloud. I mean, even when I worked—I worked as a web developer and then kind of learned more about the cloud, and I started out as a front-end developer and shifted into, like, SRE and infrastructure, so even for people within tech, you can have a huge tech community which there is on TikTok, with a younger community—but not all of them really understand the cloud necessarily, depending on their job function. So, I think it's a great way to kind of expose people to that.For me, my exposure came from community. I met somebody at a meetup who was working in cloud, and it wasn't even on the job that I really started getting into cloud because many times in corporations, you might be working on a specific team and you're not really encountering other ends, and it seems kind of like a mystery. Although it shouldn't seem like magic, many times when you're doing certain job functions—especially the DevOps—could end up feeling like magic. So, [laugh] for the good and the bad. So sometimes, if you're not working on that end, you really sometimes take it for granted.And so, for me, I actually—meetups were the way I got exposed to that end. And then I brought it back into my work and shifted internally and did certifications and started, even, lunch-and-learns where I work to get more people in their learning journey together within the company, and you know, help us as we're migrating to the cloud, as we're building on the cloud. Which, of course, we have many more roles down the road. I did it for a few years and saw the shift. But I worked at a media company for many years and now shifting to AWS, and so I've seen that happen on different ends.Not—oh, I wasn't the one doing the migration because I was on the other end of that time, but now for the last two years, I was working on [laugh] the infrastructure end, and so it's really fascinating. And many people actually—until now I feel like—that will work on maybe the web and mobile and don't always know as much about the cloud. I think it's a great way to funnel things in a quick manner. I think also society is getting used to short videos, and our attention span is very low, and I think for—Corey: No argument here.Linda: —[crosstalk 00:04:39] spending so mu—yeah, and we're spending so much time on these platforms, we might as well, you know, learn something. And I think it depends what content. Some things work well, some things doesn't. As with anything content creation, you kind of have to do trial and error, but I do find the audience to be a bit different on TikTok versus Twitter versus Instagram versus YouTube. Which is interesting how it's going to play out on YouTube, too, which is a whole ‘nother topic conversation.Corey: Well, it's odd to me watching your path. It's almost the exact opposite of mine where I started off on the back-end, grumpy sysadmin world and, “Oh, why would I ever need to learn JavaScript?” “Well, genius, because as the world progresses, guess what? That's right. The entire world becomes JavaScript. Welcome.”And it took me a long time to come around to that. You started with the front-end world and then basically approached from the exact opposite end. Let's be clear, back in my day, mine was the common path. These days, yours is very much the common path.Linda: Yeah.Corey: I also want to highlight that all of those transitions and careers that you spoke about, you were at the same company for nine years, which in tech is closer to 30. So, I have to ask, what was it that inspired you, after nine years, to decide, “I'm going to go work somewhere else. But not just anywhere; I'm going to AWS.” Because normally people don't almost institutionalized lifers past a certain point.Linda: [laugh].Corey: Like, “Oh, you'll be there till you retire or die.” Whereas seeing significant career change after that long in one place, even if you've moved around internally and experienced a lot of different roles, is not common at all what sparked that?Linda: Yeah. Yeah, no, it's such a good question. I always think about that, too, especially as I was reflecting because I'm, you know, in the midst of this transition, and I've gotten a lot of reflecting over the last two weeks [laugh], or more. But I think the main thing for me is, I always, wherever I was—and this kind of something that—I'm very proactive when it comes to trying to transition. I think, even when I was—right, I held many roles in the same company; I used to work in TV production and actually left for three months to go to a coding boot camp and then came back on the other end, but I understood the product in a different way.So, for that time period, it was really interesting to work on the other end. But, you know, as I kind of—every time I wanted to progress further, I always made a move that was actually new and put me in an uncomfortable place, even within the same company. And I'm at the point now that I'm in my career, I felt like this next step really needs to be, you know, at AWS. It's not, like, the natural progression for me. I worked alongside—on the client end—with AWS and have seen so many projects come through and how much our own workloads have changed.And it's just been an incredible journey, also dealing with accounts team. On that end, I've worked alongside them, so for me, it was kind of a natural progression. I was very passionate about cloud computing at AWS and I kind of wanted to take it to that next place, and I felt like—also, dealing with the community as part of my job is a dream part to me because I was always doing that on the side on social media. So, it wasn't part of my day-to-day job. I was working as an SRE and an infrastructure engineer, so I didn't get to do that as part of my day-to-day.I was making videos at 2 a.m. and, you know, kind of trying to, like, do—you know, interact with the community like that. And I think—I come from a performing background, the people background, I was singing since I was four years old. I always go to—I was a wedding singer, so I go into a room and I love making people happy or giving value. And I think, like, education has a huge part of that. And in a way, like making that content and—Corey: You got to get people's attention—Linda: Yeah.Corey: —you can't teach them a damn thing.Linda: Right. Exactly. So, it's kind of a mix of everything. It's like that performance, the love of learning. You know, between you and I, like, I wanted to be a lawyer before I thought I was going to—before I went to tech.I thought I was going to be a lawyer purely because I loved the concept of going to law school. I never took time to think about the law part, like, being the lawyer part. I always thought, “Oh, school.” I'm a student at heart. I always call myself a professional student. I really think that's part of what you need to be in this world, in this tech industry, and I think for me, that's what keeps my fire going.I love to experiment, to learn, to build. And there's something very fulfilling about building products. If you take a step back, like, you're kind of—you know, for me that part, every time I look back at that, that always is what kind of keeps me going. When I was doing front-end, it felt a lot more like I was doing smaller things than when I was doing infrastructure, so I felt like that was another reason why I shifted. I love doing the front-end, but I felt like I was spending two days on an Internet Explorer bug and it just drove me—[laugh] it just made it feel unfulfilling versus spending two days on, you know, trying to understand why, you know, something doesn't run the infrastructure or, like, there's—you know, it's failing blindly, you know? Stuff like that. Like, I don't know, for me that felt more fulfilling because the problem was more macro. But I think I needed both. I have a love for both, but I definitely prefer being back-end. So. [laugh]. Well, I'm saying that now but—[laugh].Corey: This might be a weakness on my part where I'm basically projecting onto others, and this is—I might be completely wrong on this, but I tend to take a bit of a bifurcated view of community. I mean, community is part of the reason that I know the things I know and how I got to this place that I am, so use that as a cautionary tale if you want. But when I talk to someone like you at this moment, where you're in the community, I'm in the community, and I'm talking to you about a problem I'm having and we're working on ways to potentially solve that or how to think about that. I view us as basically commiserating on these things, whereas as soon as you start on day one—and yes, it's always day one—at AWS and this becomes your day job and you work there, on some level, for me, there's a bit shift that happens and a switch gets flipped in my head where, oh, you actually work at this company. That means you're the problem.And I'm not saying that in a way of being antagonistic. Please, if you're watching or listening to this, do not antagonize the developer advocates. They have a very hard job understanding all this so they can explain that to the rest of us. But how do you wind up planning to navigate, or I guess your views on, I guess, handling the shift between, “One of the customers like the rest of us,” to, as I say, “Part of the problem,” for lack of a better term.Linda: Or, like, work because you kind of get the—you know. I love this question and it's something I've been pondering a lot on because I think the messaging will need to be a little different [coming from me 00:10:44] in the sense of, there needs to be—just in anything, you have to kind of create trust. And to create trust, you have to be vulnerable and authentic. And I think I, for example, utilize a lot of things outside of just the AWS cloud topic to do that now, even, when I—you know, kind of building it without saying where I work or anything like that, going into this role and it being my job, it's going to be different kind of challenge as far as the messaging, but I think it still holds true that part, that just developing trust and authenticity, I might have to do more of that, you know? I might have to really share more of that part, share other things to really—because it's more like people come, it doesn't matter how much somet—how many times you explain it, many times, they will see your title and they will judge you for it, and they don't know what happened before. Every TikTok, for example, you have to act like it's a new person watching. There is no series, you know? Like, yes, there's a series but, like, sometimes you can make that but it's not really the way TikTok functions or a short-form video functions. So, you kind of have to think this is my first time—Corey: It works really terribly when you're trying to break it out that way on TikTok.Linda: [laugh]. Yeah.Corey: Right. Here's part 17 of my 80-TikTok-video saga. And it's, “Could you just turn this into a blog post or put this on YouTube or something? I don't have four hours to spend learning how all this stuff works in your world.”Linda: Yeah. And you know, I think repeating certain things, too, is really important. So, they say you have to repeat something eight times for people to see it or [laugh] something like that. I learned that in media [crosstalk 00:12:13]—Corey: In a row, or—yeah. [laugh].Linda: I mean, the truth is that when you, kind of like, do a TikTok maybe, like, there's something you could also say or clarify because I think there's going to be—and I'm going to have to—there's going to be a lot of trial and error for me; I don't know if I have answers—but my plan is going into it very much testing that kind of introduction, or, like, clarifying what that role is. Because the truth is, the role is advocating on behalf of the community and really helping that community, so making sure that—you don't have to say it as far as a definition maybe, but, like, making sure that comes across when you create a video. And I think that's going to be really important for me, and more important than the prior even creating content going forward. So, I think that's one thing that I definitely feel like is key.As well as creating more raw interaction. So, it depends on the platform, too. Instagram, for example, is much more community—how do I put this? Instagram is much more easy to navigate as far as reaching the same community because you have something, like, called Instagram Stories, right? So, on Instagram Stories, you're bringing those stories, mostly the same people that follow you. You're able to build that trust through those stories.On TikTok, they just released Stories. I haven't really tried them much and I don't play with it a lot, but I think that's something I will utilize because those are the people that are already follow you, meaning they have seen a piece of content. So, I think addressing it differently and knowing who's watching what and trying to kind of put yourself in their shoes when you're trying to, you know, teach something, it's important for you to have that trust with them. And I think—key to everything—being raw and authentic. I think people see through that. I would hope they do.And I think, uh, [laugh] that's what I'm going to be trying to do. I'm just going to be really myself and real, and try to help people and I hope that comes through because that's—I'm passionate about getting more people into the cloud and getting them educated. And I feel like it's something that could also allow you to build anything, just from anywhere on your computer, brings people together, the world is getting smaller, really. And just being able to meet people through that and there's just a way to also change your life. And people really could change their life.I changed my life, I think, going into tech and I'm in the United States and I, you know—I'm in New York, you know, but I feel like so many people in the States and outside of the States, you know, all over the world, you know, have access to this, and it's powerful to be able to build something and contribute and be a part of the future of technology, which AWS is.Corey: I feel like, in three years or whatever it is that you leave AWS in the far future, we're going to basically pull this video up and MST3k came together. It's like, “Remember how naive you were talking about these things?” And I'm mostly kidding, but let's be serious. You are presumably going to be focusing on the idea of short-form content. That is—Linda: Yeah.Corey: What your bread-and-butter of audience-building has been around, and that is something that is new for AWS.Linda: Yeah.Corey: And I'm always curious as to how companies and their cultures continue to evolve. I can only imagine there's a lot of support structure in place for that. I personally remember giving a talk at an AWS event and I had my slides reviewed by their legal team, as they always do, and I had a slide that they were looking at very closely where I was listing out the top five AWS services that are bullshit. And they don't really have a framework for that, so instead, they did their typical thing of, “Okay, we need to make sure that each of those services starts with the appropriate AWS or Amazon naming convention and are they capitalized properly?” Because they have a framework for working on those things.I'm really curious as to how the AWS culture and way of bringing messaging to where people are is going to be forced to evolve now that they, like it or not, are going to be having significantly increased presence on TikTok and other short-form platforms.Linda: I mean, it's really going to be interesting to see how this plays out. There's so much content that's put out, but sometimes it's just not reaching the right audience, so making sure that funnel exists to the right people is important and reaching those audiences. So, I think even YouTube Shorts, for example. Many people in tech use YouTube to search a question.They do not care about the intro, sometimes. It depends what kind of following, it depends if [in gaming 00:16:30], but if you're coming and you're building something, it's like a Stack Overflow sometimes. You want to know the answer to your question. Now, YouTube Shorts is a great solution to that because many times people want the shortest possible answer. Now, of course, if it's a tutorial on how to build something, and it warrants ten minutes, that's great.Even ten minutes is considered, now, Shorts because TikTok now has ten-minute videos, but I think TikTok is now searchable in the way YouTube is, and I think let's say YouTube Shorts is short-form, but very different type of short-form than TikTok is. TikTok, hooks matter. YouTube answers to your questions, especially in chat. I wouldn't say everything in YouTube is like that; depends on the niche. But I think even within short-form, there's going to be a different strategy regarding that.So, kind of like having that mix. I guess, depending on platform and audience, that's there. Again, trial and error, but we'll see how this plays out and how this will evolve. Corey: This episode is sponsored in part by our friends at Vultr. Optimized cloud compute plans have landed at Vultr to deliver lightning-fast processing power, courtesy of third-gen AMD EPYC processors without the IO or hardware limitations of a traditional multi-tenant cloud server. Starting at just 28 bucks a month, users can deploy general-purpose, CPU, memory, or storage optimized cloud instances in more than 20 locations across five continents. Without looking, I know that once again, Antarctica has gotten the short end of the stick. Launch your Vultr optimized compute instance in 60 seconds or less on your choice of included operating systems, or bring your own. It's time to ditch convoluted and unpredictable giant tech company billing practices and say goodbye to noisy neighbors and egregious egress forever. Vultr delivers the power of the cloud with none of the bloat. Screaming in the Cloud listeners can try Vultr for free today with a $150 in credit when they visit getvultr.com/screaming. That's G-E-T-V-U-L-T-R dot com slash screaming. My thanks to them for sponsoring this ridiculous podcast.Corey: I feel like there are two possible outcomes here. One is that AWS—Linda: Yeah.Corey: Nails this pivot into short-form content, and the other is that all your TikTok videos start becoming ten minutes long, which they now support, welcome to my TED Talk. It's awful, and then you wind up basically being video equivalent for all of your content, of recipes when you search them on the internet where first they circle the point to death 18 times with, “Back when I was a small child growing up in the hinterlands, we wound—my grandmother would always make the following stew after she killed the bison with here bare hands. Why did grandma kill a bison? We don't know.” And it just leads down this path so they can get, like, long enough content or they can have longer and longer articles to display more ads.And then finally at the end, it's like ingredient one: butter. Ingredient two, there is no ingredient two. Okay. That explains why it's delicious. Awesome. But I don't like having people prolong it. It's just, give me the answer I'm looking for.Linda: Yeah.Corey: Get to the point. Tell me the story. And—Linda: And this is—Corey: —I'm really hoping that is not the direction your content goes in. Which I don't think it would, but that is the horrifying thing and if for some chance I'm right, I will look like Nostradamus when we do that MST3k episode.Linda: No, no. I mean, I really am—I always personally—even when I was creating content these last few years and testing different things, I'm really a fan of the shortest way possible because I don't have the patience to watch long videos. And maybe it's because I'm a New Yorker that can't sit down from the life of me—apart from when I code of course—but, you know, I don't like wasting time, I'm always on the go, I'm with my coffee, I'm like—that's the kind of style I prefer to bring in videos in the sense of, like, people have no time. [laugh]. You know?The amount of content we're consuming is just, uh, bonkers. So, I don't think our mind is really a built for consuming [laugh] this much content every time you open your phone, or every time you look, you know, online. It's definitely something that is challenging in a whole different way. But I think where my content—if it's ten minutes, it better be because I can't shorten it. That's my thing. So, you can hold me accountable to that because—Corey: Yeah, I want ten minutes of—Linda: I'm not a—Corey: Content, not three minutes of content in a ten-minute bag.Linda: Exactly. Exactly. So, if it's a ten-minute video, it would have been in one hour that I cut down, like, meaning a tutorial, a very much technical types of content. I think things that are that long, especially in tech, would be something like, on that end—unless, of course, you know, I'm not talking about, like, longer videos on YouTube which are panels or that kind of thing. I'm talking more like if I'm doing something on TikTok specifically.TikTok also cares about your watch time, so if people aren't interested in it, it's not going to do well, it doesn't matter how many followers you have. Which is what I do like about the way TikTok functions as opposed to, let's say, Instagram. Instagram is more like it gives it to your following—and this is the current state, I don't know if it always evolves—but the current state is, Instagram Reels kind of functions in a way where it goes first to the people that follow you, but, like, in a way that's more amplified than TikTok. TikTox tests people that follows you, but if it's not a good video, it won't do well. And honestly, they're many good videos videos that don't go viral. I'm not talking about that.Sometimes it's also the topic and the niche and the sound and the title. I mean, there's so many people who take a topic and do it in three different ways and one of them goes viral. I mean, there's so many factors that play into it and it's hard to really, like, always, you know, kind of reverse engineer but I do think that with TikTok, things won't do well, more likely if it's not a good piece of content as opposed to—or, like, too long, right? Not—I shouldn't say not good a good piece of content—it's too long.Corey: The TikTok algorithm is inscrutable to me. TikTok is firmly convinced, based upon what it shows me, that I am apparently a lesbian. Which okay, fine. Awesome. Whatever. I'm also—it keeps showing me ads for ADHD stuff, and it was like, “Wow, like, how did it know that?” Followed by, “Oh, right. I'm on TikTok. Nevermind.”And I will say at one point, it recommended someone to me who, looking at the profile picture, she's my nanny. And it's, I have a strong policy of not, you know, stalking my household employees on social media. We are not Facebook friends, we are not—in a bunch of different areas. Like, how on earth would they have figured this out? I'm filling the corkboard with conspiracy and twine followed by, “Wait a minute. We probably both connect from the same WiFi network, which looks like the same IP address and it probably doesn't require a giant data science team to put two and two together on those things.” So, it was great. I was all set to do the tinfoil hat conspiracy, but no, no, that's just very basic correlation 101.Linda: And also, this is why I don't enable contacts on TikTok. You know, how it says, “Oh, connect your contacts?”Corey: Oh, I never do that. Like, “Can we look at your contacts?”Linda: Never.Corey: “No.” “Can we look at all of your photos?” “Absolutely not.” “Can we track you across apps?” “Why would anyone say yes to this? You're going to do it anyway, but I'll say no.” Yeah.Linda: Got to give the least privilege. [laugh]. Definitely not—Corey: Oh absolutely.Linda: Yeah. I think they also help [crosstalk 00:22:40]—Corey: But when I'm looking at—the monetization problem is always a challenge on things like this, too, because when I'm—my guilty TikTok scrolling pleasures hit, it's basically late at night, I just want to see—I want something to want to wind down and decompress. And I'm not about ready to watch, “Hey, would you like to migrate your enterprise database to this other thing?” It's, I… no. There's a reason that the ads that seem to be everywhere and doing well are aimed at the mass market, they're generally impulse buys, like, “Hey, do you want to set that thing over there on fire, but you're not close enough to get the job done? But this flame thrower today. Done.”And great, like, that is something everyone can enjoy, but these nuanced database products and anything else is B2B SaaS style stuff, it feels like it's a very tough sell and no one has quite cracked that nut, yet.Linda: Yeah, and I think the key there—this is, I'm guessing based on, like, what I want to try out a lot—is the hook and the way you're presenting it has to be very product-focused in the sense that it needs to be very relatable. Even if you don't know anything about tech, you need to be—like, for example, in the architecture page on AWS, there's a video about the Emirates going to Mars mission. Space is a very interesting topic, right? I think, a hook, like, “Do want to see how, like, how this is bu—” like, it's all, like, freely available to see exactly [laugh] how this was built. Like, it might—in the right wording, of course—it might be interesting to someone who's looking for fun-fact-style content.Now, is it really addressing the people that are building everyday? Not really always, depends who's on there and the mass market there. But I feel like going on the product and the things that are mass-market, and then working backwards to the tech part of it, even if they learn something and then want to learn more, that's really where I see TikTok. I don't think every platform would be, maybe, like this, but that's where I see getting people: kind of inviting them in to learn more, but making it cool and fun. It's very important, but it feels cool and fun. [laugh]. So.Because you're right, you're scrolling at 2 a.m. who wants to start seeing that. Like, it's all about how you teach. The content is there, the content has—you know, that's my thing. It's like, the content is there. You don't need to—it's yes, there's the part where things are always evolving and you need to keep track of that; that's whole ‘nother type thing which you do very well, right?And then there's a part where, like, the content that already exists, which part is evergreen? Meaning, which part is, like, something that could be re—also is not timely as far as update, for example, well-architected framework. Yes, it evolves all the time, you always have new pillars, but the guide, the story, that is an evergreen in some sense because that guide doesn't, you know, that whole concept isn't going anywhere. So, you know, why should someone care about that?Corey: Right. How to turn on two-factor authentication for your AWS account.Linda: Right.Corey: That's evergreen. That's the sort of thing that—and this is the problem, I think, AWS has had for a long time where they're talking about new features, new enhancements, new releases. But you look what people are actually doing and so much of it is just the same stuff again and again because yeah, that is how most of the cloud works. It turns out that three-quarters of company's production infrastructures tends to run on EC2 more frequently than it tends to run on IoT Greengrass. Imagine that.So, there's this idea of continuing to focus on these things. Now, one of my predictions is that you're going to have a lot of fun with this and on some level, it's going to really work for you. In others, it's going to be hilariously—well, its shortcomings might be predictable. I can just picture now you're at re:Invent; you have a breakout talk and terrific. And you've successfully gotten your talk down to one minute and then you're sitting there with—Linda: [laugh].Corey: —the remainder of maybe 59. Like, oh, right. Yeah. Turns out not everything is short-form. Are you predicting any—Linda: Yep.Corey: Problems going from short-form to long-form in those instances?Linda: I think it needs to go hand-in-hand, to be honest. I think when you're creating any short-form content, you have—you know, maybe something short is actually sometimes in some ways, right, harder because you really have to make sure, especially in a technical standpoint, leaving things out is sometimes—leaves, like, a blind spot. And so, making sure you're kind of—whatever you're educating, you kind of, to be clear, “Here's where you learn more. Here's how I'm going to answer this next question for you: go here.” Now, in a longer-form content, you would cover all that.So, there's always that longevity. I think even when I write a script, and there's many scripts I'm still [laugh] I've had many ideas until now I've been doing this still at 2 a.m. so of course, there's many that didn't, you know, get released, but those are the things that are more time consuming to create because you're taking something that's an hour-long, and trying to make sure you're pulling out the things that are most—that are hook-style, that invite people in, that are accurate, okay, that really give you—explain to you clearly where are the blind spots that I'm not explaining on this video are. So, “XYZ here is, like, the high level, but by the way, there's, like, this and this.” And in a long-form, you kind of have to know the long-form version of it to make the short-form, in some ways, depending on what—you're doing because you're funneling them to somewhere. That's my thing. Because I don't think there should be [crosstalk 00:27:36]—Corey: This is the curse of Twitter, on some level. It's, “Well, you forgot about this corner case.” “Yeah, I had 280 characters to get into.” Like, the whole point of short-form content—which I do consider Twitter to be—is a glimpse and a hook, and get people interested enough to go somewhere and learn more.For something like AWS, this makes a lot of sense. When you highlight a capability or something interesting, it's something relevant, whereas on the other side of it, where it's this, “Oh, great. Now, here's an 8000-word blog post on how I did this thing.” Yeah, I'm going to get relatively fewer amounts of traffic through that giant thing, but the people who are they're going to be frickin' invested because that's going to be a slog.Linda: Exactly.Corey: “And now my eight-hour video on how exactly I built this thing with TypeScript.” Badly—Linda: Exactly.Corey: —as it turns out because I'm a bad programmer.Linda: [laugh]. No, you're not. I love your shit-posting. It's great.Corey: Challenge accepted.Linda: [laugh]. I love what you just mentioned because I think you're hitting the nail on the head when it comes to the quality content that's niche focus, like, there needs to be a good healthy mix. I think always doing that, like, mass-market type video, it doesn't give you, also, the credibility you need. So, doing those more niche things that might not be relevant to everybody, but here and there, are part of that is really key for your own knowledge and for, like, the com—you know, as far as, like, helping someone specific. Because it's almost like—right, when you're selling a service and you're using social media, right, not everybody's going to buy your service. It doesn't matter what business you're in right? The deep-divers are going to be the people that pay up. It's just a numbers game, right? The more people you, kind of, address from there, you'll find—Corey: It's called a funnel for a reason.Linda: Right. Exactly.Corey: Free content, paid content. Almost anyone will follow me on Twitter; fewer than will sign up for a newsletter; fewer will listen to a podcast; fewer will watch a video, and almost none of them will buy a consulting engagement. But ‘almost' and ‘actually none of them,' it turns out is a very different world.Linda: Exactly. [laugh]. So FYI, I think there's—Corey: And that's fine. That's the way it works.Linda: That's the way it works. And I think there needs to be that niche content that might not be, like, the most viral thing, but viral doesn't mean quality, you know? It doesn't. There's many things that play into what viral is, but it's important to have the quality content for the people that need that content, and finding those people, you know, it's easier when you have that kind of mass engagement. Like, who knows? I'm a student. I told you; I'm a professional student. I'm still [laugh] learning every day.Corey: Working with AWS almost makes it a requirement. I wish you luck—Linda: Yeah.Corey: —in the new gig and I also want to thank you for taking time out of your day to speak with me about how you got to this point. And we're all very eager to see where you go from here.Linda: Thank you so much, Corey, for having me. I'm a huge fan, I love your content, I'm an avid reader of your newsletter and I am looking forward to very much being in touch and on the Twitterverse and beyond. So. [laugh].Corey: If people want to learn more about what you're up to, and other assorted nonsense, where's the best place they can go to find you?Linda: So, the best place they could go is lindavivah.com. I have all my different social handles listed on there as well a little bit about me, and I hope to connect with you. So, definitely go to lindavivah.com.Corey: And that link will, of course, be in the [show notes 00:30:39]. Thank you so much for taking the time to speak with me. I really appreciate it.Linda: Thank you, Corey. Have a wonderful rest of the day.Corey: Linda Haviv, AWS Developer Advocate, very soon now anyway. 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, smash the like and subscribe buttons, and of course, leave an angry comment that you have broken down into 40 serialized TikTok videos.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.

Should we grant patents to Artificial Intelligence algorithms? Should machines have copyright over the art works they generate? What about animals?

Jim Harrison was born in 1937, in Grayling, Michigan. His writing has appeared in The New Yorker, Esquire, Sports Illustrated, Playboy, and The New York Times.Harrison was also the author of over thirty books of fiction, nonfiction, and poetry, including seven volumes of novellas, Legends of the Fall (1979), The Woman Lit by Fireflies (1990), Julip (1994), The Beast God Forgot to Invent (2000), The Summer He Didn't Die (2005), The Farmer's Daughter (2010), and The River Swimmer (2013); eleven novels, Wolf (1971), A Good Day to Die (1973), Farmer (1976), Warlock(1981), Sundog (1984), Dalva (1988), The Road Home (1998), True North (2004), Returning to Earth (2007), The English Major (2008), and The Great Leader (2011); thirteen collections of poetry, including most recently Songs of Unreason (2011), In Search of Small Gods(2009), and Saving Daylight (2006); and three works of nonfiction, the memoir Off to the Side (2001) and the collections Just Before Dark(1991) and The Raw and the Cooked: Adventures of a Roving Gourmand (2001).The winner of a National Endowment for the Arts grant, a Guggenheim Fellowship, and the Spirit of the West Award from the Mountains & Plains Booksellers Association, he was inducted into the American Academy of Arts & Letters (2007) and was named Officier des Arts et Lettres (2012) by the French Ministry of Culture for his “significant contribution to the enrichment of the French cultural inheritance.” He has had his work published in twenty-seven languages.Harrison lived in Montana and Arizona before his death in 2016 at the age of seventy-eight.From https://groveatlantic.com/author/jim-harrison/. For more information about Jim Harrison:Previously on The Quarantine Tapes:James McBride about Harrison, at 24:05: https://quarantine-tapes.simplecast.com/episodes/the-quarantine-tapes-092-james-mcbrideSaving Daylight: https://www.coppercanyonpress.org/books/saving-daylight-by-jim-harrison/“Jim Harrison, The Art of Fiction No. 104”: https://www.theparisreview.org/interviews/2511/the-art-of-fiction-no-104-jim-harrison“Jim Harrison”: https://www.poetryfoundation.org/poets/jim-harrison

Il y a 13.000 espèces de Fougères. Les Filicophytes forment le plus grand embranchement végétal après les Angiospermes (les plantes à fleurs et à graines, 300.000 espèces).   Au Carbonifère (de -360 à -300 millions d'années), les continents étaient regroupés en un seul supercontinent, la Pangée. Il était couvert de forêts tropicales humides, composées surtout de Ptéridophytes (Prêles, Fougères, Lycopodes…). Cette biomasse accumulée a d'ailleurs produit, en se fossilisant, les dépôts de charbon, ce qui a donné son nom au Carbonifère.   Les Fougères furent très novatrices. Elles inventèrent les vaisseaux et les racines pour transporter la sève. Elle ont aussi "inventé" la lignine, une molécule qui assure la rigidité. Ce qui leur a permis de conquérir la hauteur…   Les 3/4 des espèces vivent dans les régions tropicales et humides. Beaucoup sont épiphytes (poussent sur des arbres, sans pour autant être parasites, il s'agit juste de pousser sur un support).   Les Fougères ne possèdent ni fleur ni graine, à l'instar des Champignons, des Mousses ou encore des Algues. On regroupait autrefois ces plantes sous l'appellation de cryptogames, avec un appareil reproducteur caché, à l'inverse des phanérogames qui les exhibent. La génétique a aujourd'hui rendu caduque cette grande division de base des plantes.   La Fougère argentée (Silver Fern) est l'emblème national de la Nouvelle-Zélande. Elle figure sur le drapeau du pays et sur la tenue des All Blacks. Les Maoris en tapissaient leurs chemins : le dessous argenté des frondes reflétait la lune et leur permettait de suivre une direction en forêt la nuit.   En France, la plus connue est la grande Fougère, aussi appelée Fougère-aigle, une plante vivace très commune. En France, on la trouve surtout en forêt. Il s'agit d'une plante envahissante. Il faut donc éviter de la disséminer, elle le fait trop bien toute seule ... La reproduction des Fougères est très particulière : la formation de l'œuf se produit en deux phases séparées par une longue période de repos. La plante adulte produit d'abord des spores (sur le dessous des frondes). Ces spores germent et donnent naissance à un corps formé de lamelles, le prothalle, sur lequel l'œuf se forme. _______  

Sais-tu comment on faisait pour prendre des photos quand les téléphones portables n'existaient pas ? Julien t'emmène au tout début du 19e siècle pour te le raconter et te faire découvrir l'invention de Joseph Nicéphore Niépce… C'est quoi, une chambre noire ?  L'invention de la photographie remonte au tout début du 19e siècle, il y a 200 ans environ. À cette époque, on tente d'améliorer ce qu'on appelle la “chambre noire”. C'est un instrument d'optique qui utilise un principe naturel : la trajectoire de la lumière. Julien t'explique comment cela fonctionne.  La chambre noire, c'est une boîte dans laquelle on a percé un petit trou pour laisser entrer la lumière. Lorsque la lumière du soleil éclaire les objets, elle rebondit dessus. Le petit trou de la chambre noire capture ces rayons lumineux qui proviennent des objets et une image apparaît au fond de la boîte. Elle est plus petite et inversée : le haut en bas, la gauche à droite et inversement.   Ce système était utilisé par les artistes, pour projeter sur une feuille l'image qu'ils souhaitaient peindre : ils n'avaient plus qu'à dessiner par-dessus.  Les recherches de Nicéphore Niépce pour capturer la lumière   Projeter un paysage, une vue, au fond d'une chambre noire, c'est bien. Mais Joseph Nicéphore Niépce, un ingénieur passionné d'optique et de chimie, va essayer de fixer cette image. Il veut “capturer la vue” et réussir à imprimer les rayons lumineux.  Pendant des années, Niépce effectue d'innombrables essais. Il commence par utiliser des sels d'argent, un produit naturel qui a la particularité de noircir à la lumière. Lors d'une expérience, il enduit une feuille de papier avec des sels d'argent et la place au fond de la chambre noire. Il pose ensuite la boîte sur le rebord de sa fenêtre, le petit trou face au paysage, et attend…  Le premier négatif de l'Histoire  Hourra ! En 1816, Niépce parvient, en quelque sorte, à “imprimer” la lumière. Il obtient une reproduction sur papier de la vue depuis la fenêtre de sa chambre : une vue en noir et blanc, presque identique, sauf que le ciel est noir, et le toit d'ardoise est blanc.   Les zones blanches d'un paysage renvoient en effet beaucoup de lumière, et cette lumière fait noircir le sel d'argent. Au contraire, les zones sombres d'un paysage renvoient peu de lumière, donc elles ont peu d'effet sur le sel d'argent, qui reste clair. Niepce a obtenu une image inversée de son paysage !  C'est le premier négatif de l'Histoire.  Comment fixer les images ?  Le véritable souci, c'est qu'en sortant la feuille de la chambre noire, les sels d'argent continuent de réagir à la lumière. Au bout de quelques heures, la feuille est totalement noircie.  Pendant une vingtaine d'années, Niépce teste différents supports pour parvenir à fixer les images définitivement : des plaques de pierre à la place de la feuille, puis des plaques en métal… Il découvre aussi d'autres produits qui réagissent à la lumière.  Niépce arrive enfin à obtenir une vue bien figée, mais pour y parvenir, il faut exposer la plaque à la lumière pendant des heures, parfois toute une journée. C'est bien trop long ! Et puis l'image n'est pas très nette.  Pour réduire le temps de pause, et améliorer la netteté de l'image, Niépce fait appel à un certain Louis Daguerre, un décorateur de théâtre qui travaille sur la chambre noire. Ensemble, ils vont améliorer l'invention de Niépce. Ils parviennent à obtenir des images sans négatif et avec des temps de prise de vue beaucoup plus courts.  Le daguerréotype, premier appareil photographique  Niépce meurt en 1833 et c'est Louis Daguerre qui, en 1839, présente devant l'Académie des Sciences le premier appareil photographique qu'il appelle… le daguerréotype.  Après la mort de Niépce, Daguerre a poursuivi ses recherches et s'est couvert de gloire. Il a fallu des décennies avant que Joseph Nicéphore Niépce soit reconnu comme le véritable inventeur de la photographie. 

Simon Roberts, Managing Engineer of Cabin Awareness at Toyota Connected, joins Lisa Dent on Chicago’s Afternoon News to explain how the Cabin Awareness program works, how it aims to prevent ‘hot car’ deaths, and how they hope the innovative technology can be added to all vehicles in the future. Follow Your Favorite Chicago’s Afternoon News […]

Our guests are the legendary Raqs Media Collective, formed in New Delhi in 1992, by Monica Narula, Jeebesh Bagchi and Shuddhabrata Sengupta. I like to call them intellectuals-at-large, but their production ranges from artistic to curatorial projects, from theoretical to educational works. The collective also co-founded Sarai—the inter-disciplinary and incubatory space at the Centre for the Study of Developing Societies.You'll hear their unique blend of thinking on technologies and media, from surveillance to bureaucratic interfaces as deeply embedded in societal dynamics; and we'll get to explore together how they have been producing knowledge as artists. The tidal changes in image cultures; how digital technologies are intertwined with urban infrastructures; how the poetic is also the political; and ultimately the significance of languages are a few of the things that are lingering in my mind and provoking further thoughts after this conversation.EPISODE NOTES & LINKSBased in New Delhi, Raqs Media Collective comprises three practitioners: Jeebesh Bagchi, Monica Narula, and Shuddhabrata Sengupta. For the past three decades, the Collective has been concerned with urbanism, epistemology, technology, globalization, and the experience of time. Drawing upon critical theory and political philosophy, their work is marked by active inquiry, double-meanings, pluralism, and entanglement. https://www.raqsmediacollective.net/Sarai is among South Asia's most prominent and productive platforms for research and reflection on the transformation of urban space and contemporary realities, especially with regard to cities, data and information, law, and media infrastructures. https://sarai.net/about/Initiated by Ankur: Society for Alternatives in Education, Delhi, and Sarai-CSDS, Delhi in the year 2001 Cybermohalla is a network of dispersed labs for experimentation and exploration among young working-class individuals https://sarai.net/projects/cybermohalla/.The first Cybermohalla took place in LNJP (Lok Nayak Jarai Prakash), an informal settlement in Central Delhi.Parda-darii is a noun in Hindu meaning play of the veil, removing the veil, revealing the truth, and revealment of secrets.Can has written on the design of Cybermohalla Hub, in relation to his ‘Setting a Setting' idea.https://www.academia.edu/5980837/_Setting_and_Remaking_in_Cybermohalla_Hub_eds_Hirsch_N_and_S_Sarda_Berlin_Sternberg_Press_2012Curated by Raqs Media Collective “In the Open or In Stealth” was a group exhibition that has taken place at MACBA in 2018-2019 about the concept of a future in which multiple histories and geographies were placed in dialogue. https://www.macba.cat/en/exhibitions-activities/exhibitions/open-or-stealthThe Walker Art Center is a multidisciplinary contemporary art center in Minneapolis, Minnesota, United States. https://walkerart.org/visitEstablished by Yoshiharu Tsukamoto and Momoyo Kaijima in Tokyo, Atelier Bow-Wow is an architecture firm. http://www.bow-wow.jp/Taken place in Walker Art center in 2003, How Latitudes Become Forms: Art in a Global Age was an exhibition about ways that globalization, or the “new internationalism in art” is affecting visual culture. https://walkerart.org/calendar/2003/how-latitudes-become-forms-art-in-a-global-agHow Latitudes Become Forms has a vintage website that constitutes substantial archival material about the project. http://latitudes.walkerart.org/overview/index.htmlFatwa is a ruling on a point of Islamic law given by a recognized authority.Abhinavagupta (c. 950 – 1016 CE) was a philosopher, mystic, and aesthetician from Kashmir. He was also considered an influential musician, poet, dramatist, exegete, theologian, and logician – a polymathic personality who exercised strong influences on Indian culture. William Shakespeare used more than 20,000 words in his plays and poems, and his works provide the first recorded use of over 1,700 words in the English language. https://www.shakespeare.org.uk/explore-shakespeare/shakespedia/shakespeares-words/Submitted by Rohana Khattak, a sixteen-year-old reader of the New York Times from, Islamabad, Pakistan to the newspaper's Invent a Word Challenge, “Oblivionnaire” refers to a billionaire who chooses to be blind to the disparity and inequality that his or her wealth is creating.“Khullja Sim Sim” translates as “Open Sesame” in English, and “Açıl Susam Açıl” in Turkish. It is a magical phrase in the story of "Ali Baba and the Forty Thieves" and in Antoine Galland's version of One Thousand and One Nights. It opens the mouth of a cave in which forty thieves have hidden a treasure.Nishastagah is a Hindu word referring to a place not (yet, ever) inhabited by memory. In response to the passage of the Citizenship Act on 11 December 2019 and the ensuing police intervention against students at Jamia Millia Islamia who were opposing the Amendment, the Shaheen Bagh protest was a peaceful sit-in protest in Delhi, India, that began on 15 December 2019 and lasted until 24 March 2020.The permanently lost 16mm film, “Half the Night left, and the Universe to Comprehend” is Raqs Media Collective's first work. In the Hindu epic the Mahabharata, Ashwatthama was a Maharathi warrior who became a Chiranjivi (immortal) due to a curse given to him by the god of protection, compassion, tenderness, and love, Krishna.In the essay titled dictionary of war by Raqs Media Collective Ashwatthama is described both as an omnipresent immaterial entity that acts as a propagator of war while tracing his essence within the essence of human subjectivity. http://dictionaryofwar.org/node/894Mahendra Raj (1924 - 2022) was a structural engineer and designer who contributed to the structural design of many buildings in India including the Hall of Nations at the Pragati Maidan in Delhi.Opened in 1972, the Hall of Nations was a building designed by architect Raj Rewal, and structurally engineered by Mahendra Raj. The structure was demolished in April 2017 to make way for a new complex.The essay that Jabeesh mentions while referring to Mahendra Raj is titled Living with the Future in South Asia by Chris Moffat. https://www.publicbooks.org/modernist-architecture-heritage-south-asia-pragati-maidan/This season of Ahali Conversations is supported by the Graham Foundation for Advanced Studies in the Fine Arts. The Graham provides project-based grants to foster the development and exchange of diverse and challenging ideas about architecture and its role in the arts, culture, and society. This episode was also supported by a Moon & Stars Project Grant from the American Turkish Society.This episode was recorded on Zoom on May 17th, 2022. Interview by Can Altay. Produced by Aslı Altay & Sarp Renk Özer. Music by Grup Ses.

durée : 00:52:29 - Côté saveurs avec France Bleu Lorraine - FB Sud Lorraine - Chaque jour les meilleurs chefs de la région sont avec nous pour nous donner idées et conseils culinaires. Elle est tellement meilleure quand elle est faite "nature" ou en tous cas pas industrielle la pâte feuilletée. Grâce à notre charcutier; on va la faire nous même...

O que é felicidade? Podemos nos realizar vivendo a nossa vida aparentemente banal, ou precisamos empreender grandes feitos para sermos grandes pessoas? De que forma podemos contribuir para um "mundo melhor" sem cair em devaneios revolucionários? Neste episódio do Ordem Natural Podcast, quarto do nosso quadro Inventário da Cultura, analisamos o grande clássico do cinema americano A Felicidade Não se Compra. Curtam nossas páginas e nos sigam no: Facebook: www.facebook.com/Ordem.Natural.Podcast Instagram: @ordemnaturalpodcast Telegram: https://t.me/ordem_natural_podcast Twitter: @naturalordem Gettr: https://gettr.com/user/ordem_natural Imagem: One of the Family. Frederick George Cotman (1850–1920). Walker Art Gallery. Trilha sonora: Antonio Vivaldi, “La Notte", Concerto em G menor, RV 439. Felix Mendelssohn, “Variations Sérieuses”, Op. 54, solo para piano. #cinema #felicidade #liberdade #cultura #conservadorismo #filosofia #história #literatura #anticomunismo #olavotemrazao #conservador #conservadora #conservadores #direitaconservadora #familiatradicional #direita #comunismonao #comunismomata #comunismojamais #filme #clássicos #classicos

Hour 3: Evan's ongoing battle with Staten Island. Craig and Big Mack gave Evan grief for saying he went to an "outdoor mall"? And did someone else actually invent WAG Wednesday? 

Show Notes(01:35) Ville recalled his education getting degrees in Computer Science from the University of Helsinki in Finland.(04:35) Ville walked over his time working at a startup called Gurusoft that planned to commercialize self-organizing maps, a peculiar artificial neural network.(07:17) Ville reflected on his four years as a researcher at Nokia — working on big data infrastructure, analytics, and ML open-source projects (such as Disco and Ringo).(11:56) Ville shared the story of co-founding a startup that built a novel scriptable data platform called Bitdeli with his brother and not finding a product-market fit.(13:58) Ville walked through AdRoll's acquisition of Bitdeli in June 2013.(15:49) Ville discussed the engineering challenges associated with his work at AdRoll — AdRoll Prospecting and traildb.io.(19:33) Ville mentioned the product and leadership/management lessons during his time being AdRoll's Head of Data and leading various data/ML efforts.(24:43) Ville rationalized his decision to join the ML Infrastructure team at Netflix in 2017.(27:26) Ville discussed the motivation behind the creation of Netflix's human-centric ML infrastructure, Metaflow, later open-sourced in 2019.(30:21) Ville unpacked the key design principles that summarize the philosophy of Metaflow, which is influenced by the unique culture at Netflix.(35:00) Ville talked about his well-known diagram on the data infrastructure's hierarchy of needs.(37:33) Ville examined the technical details behind Metaflow's integration with AWS to make it easy for users to move back and forth between their local and remote modes of development and execution.(40:58) Ville expressed the challenges of finding Metaflow's early adopters internally at Netflix and externally later on at other companies.(45:13) Ville went over the strategy around prioritizing features for Metaflow's future roadmap.(52:22) Ville shared the story behind the founding of Outerbounds, which he co-founded with Savin Goyal and Oleg Avdeev.(55:03) Ville provided his thoughts behind Metaflow's contributors in a way that can generate valuable product feedback for Outerbounds.(58:30) Ville shared valuable hiring lessons to attract the right people who are excited about Outerbounds' mission.(01:01:28) Ville shared upcoming initiatives that he is most excited about for Outerbounds.(01:04:05) Ville walked through his writing process for an upcoming technical book with Manning called “Effective Data Science Infrastructure,” a hands-on guide to assembling infrastructure for data science and machine learning applications.(01:06:34) Ville unpacked his great O'Reilly article that digs deep into the fundamentals of ML as an engineering discipline.(01:11:03) Closing segment.Ville's Contact InfoLinkedInTwitterGitHubOuterboundsWebsite | Twitter | LinkedIn | GitHub | YouTubeMetaflow GitHub | Metaflow DocsSlack CommunityCareersMetaflow Resources for Data ScienceMetaflow Resources for EngineeringMentioned ContentTalksSF Data Mining Meetup: TrailDB — Processing Trillions of Events at AdRoll (July 2016)QConSF 2018: Human-Centric Machine Learning Infrastructure @Netflix (Feb 2019)AWS re:Invent 2019: More Data Science with Less Engineering — ML Infrastructure at Netflix (Dec 2019)Scale By The Bay 2019: Human-Centric ML Infrastructure at Netflix (Jan 2020)AICamp: Metaflow — The ML Infrastructure at Netflix (Aug 2021)ArticlesOpen-Sourcing Metaflow, a Human-Centric Framework for Data Science (Netflix Tech Blog, Dec 2019)Unbundling Data Science Workflows with Metaflow and AWS Step Functions (Netflix Tech Blog, July 2020)MLOps and DevOps: Why Data Makes It Different (O'Reilly, Oct 2021)PeopleMichael Jordan (Distinguished Professor in EECS and Statistics at UC Berkeley)Matthew Honnibal and Ines Montani (Creators of open-source NLP library spaCy)Hadley Wickham (Chief Scientist at RStudio and Adjunct Professor of Statistics at Rice University)Book“The Mom Test” (by Rob Fitzpatrick)NotesMy conversation with Ville was recorded back in October 2021. Since then, many things have happened at Outerbounds. I'd recommend:Visiting Outerbounds' new website with Metaflow resources for Data Science and EngineeringWatching Ville's recent talk at Data Council Austin about the Modern Stack for ML InfrastructureBuying Ville's newly released book “Effective Data Science Infrastructure”About the showDatacast features long-form, in-depth conversations with practitioners and researchers in the data community to walk through their professional journeys and unpack the lessons learned along the way. I invite guests coming from a wide range of career paths — from scientists and analysts to founders and investors — to analyze the case for using data in the real world and extract their mental models (“the WHY and the HOW”) behind their pursuits. Hopefully, these conversations can serve as valuable tools for early-stage data professionals as they navigate their own careers in the exciting data universe.Datacast is produced and edited by James Le. Get in touch with feedback or guest suggestions by emailing khanhle.1013@gmail.com.Subscribe by searching for Datacast wherever you get podcasts or click one of the links below:Listen on SpotifyListen on Apple PodcastsListen on Google PodcastsIf you're new, see the podcast homepage for the most recent episodes to listen to, or browse the full guest list.

durée : 00:39:10 - Very Good Trip - par : Michka Assayas - Very Good Trip est très heureux de retrouver un vieil ami qu'on avait un peu négligé. On ne savait pas si c'était lui, si c'était nous mais on est particulièrement heureux de le retrouver en pleine forme et, pour ainsi dire, régénéré.

In the final episode of the season, and part II of The Long Goodbye, the team welcome returning guest Holly Norman to discuss and recap our cloud trend predictions over the last few years. Each year at AWS re:Invent in Las Vegas, we record and release a set of trends episodes live from the show floor, so we wanted to take the time to review, dissect, and discuss what we've learned. The team draw on themes across our 2020, 2021, and 2022 trends including adaptable organisations, tech making it into boardroom conversations throughout the pandemic, and what it means to be a cloud native organisation.

Mis au point à la fin du XIXe siècle par un médecin américain, le dilatateur rectal était décrit comme le remède souverain à de nombreux mots. Son utilisation, telle qu'elle était prescrite, fut cependant jugée dangereuse pour la santé par les tribunaux. Pour dilater le rectum Le dilatateur rectal est breveté en 1892 par un certain docteur Young. Ces objets en forme de torpilles, de tailles différentes, sont présentés dans des coffrets. Ils sont d'abord fabriqués en caoutchouc dur puis en bakélite. Le patient était invité à enduire l'objet d'une préparation concoctée par le Dr Young ou, à défaut, de vaseline. Puis il devait ensuite l'insérer tout entier dans le rectum. Au bout d'une minute, environ, les muscles le retenaient sans effort. Il fallait ensuite garder le dilatateur un certain temps, qui dépendait de l'effet attendu. On pouvait ensuite passer à un dilatateur de plus grande taille. Un médicament miracle On ne s'étonnera pas outre mesure que le Dr Young ait préconisé l'usage de ces dilatateurs rectaux pour combattre la constipation et les hémorroïdes. Encore que celle-ci n'ait pas été vraiment démontrée, on pouvait peut-être en attendre, dans ce domaine précis, une certaine efficacité. En revanche, les autres bienfaits de cet appareil, mis en avant par son concepteur, rencontrèrent un large scepticisme. À l'en croire, en effet, le dilatateur rectal aurait été une véritable panacée. Il aurait aussi bien guéri de l'acné et des migraines que de l'anorexie ou de la diarrhée. Mais son inventeur le recommandait aussi aux insomniaques et aux anémiques. Le Dr Young pensait que son appareil était tout aussi efficace dans le traitement de la nervosité et même de l'aliénation mentale. Mais son dispositif finit par attirer l'attention de la justice. Les tribunaux considérèrent en effet que les conseils donnés par la notice accompagnant le produit pouvaient représenter une menace pour la santé du patient qui les suivrait. On lui recommandait en effet d'utiliser ces dilatateurs aussi souvent qu'il le souhaitait. La justice ayant jugé cette recommandation dangereuse pour la santé, elle ordonna de détruire les boîtes contenant les objets. Learn more about your ad choices. Visit megaphone.fm/adchoices

The best way to predict the future is to help invent it. That's exactly what today's guest is doing as the founder and managing director of Lux Capital, where he invests in emerging science and technology ventures at the outermost edges of what is possible. Josh Wolfe (@wolfejosh), renowned Forbes journalist and visionary thinker, joins us on the show to share why we should question everything, how modern stressors differ from those our ancestors faced, the 3 important "M's" in life, and some future advancements to look forward to (like the digitization of human scent). Josh is incredible, and it's safe to say there's something for everyone in this episode. ►► Want more community? Learn more here: http://trwih.com SPECIAL THANKS TO OUR SPONSORS ►► This episode is brought to you by Fundrise. Fundrise is on a mission to use technology to build a better financial system for the individual. With over $2.4B AUM and 250k active investors, it's the largest direct-to-investor real estate investor platform in America. Their platform is so easy to use and they make it so easy to diversify your portfolio. For a limited time if you sign-up, you can get $10 bonus. Just go to www.fundrise.com/room ►► This episode is also brought to you by LMNT (http://DrinkLMNT.com/HAPPENS). LMNT is a delicious electrolyte drink mix with all of the things you need and none of the junk. It contains a science-backed electrolyte ratio: 1000 mg sodium, 200 mg potassium, 60 mg magnesium. LMNT can help prevent and eliminate headaches, muscle cramps, fatigue, sleeplessness, and other common symptoms of electrolyte deficiency. It tastes amazing and is great after a workout or one too many drinks :) Right now LMNT is offering our listeners a free sample pack with any order. That's 8 single serving packets FREE with any LMNT order. Get yours at http://drinklmnt.com/HAPPENS. And it's so good they have a no questions asked refund policy but you won't need it. THIS EPISODE Josh Wolfe: https://twitter.com/wolfejosh Sahil Bloom: https://twitter.com/SahilBloom Greg Isenberg: https://twitter.com/gregisenberg Production & Marketing Team: https://penname.co/ FIND US ON SOCIAL Twitter: https://twitter.com/_trwih Instagram: https://www.instagram.com/_trwih TikTok: https://www.tiktok.com/@_trwih Web: https://trwih.com Spotify: https://open.spotify.com/show/6aB0v6amo3a8hgTCjlTlvh Apple: https://podcasts.apple.com/us/podcast/where-it-happens/id1593424985

Rachel Nie, a senior at Johns Hopkins University joins Lisa Dent on Chicago’s Afternoon News to explain how she and four engineering students invented Tastee Tape, an edible tape that hold wraps and burritos together. Follow Your Favorite Chicago’s Afternoon News Personalities on Twitter:Follow @LisaDentSpeaksFollow @SteveBertrand Follow @kpowell720 Follow @maryvandeveldeFollow @LaurenLapka

We introduce our new travel concept,&“A Tourist In Your Own City”. Plus, how standing on line for ice cream can cure depression. And we preview our potentially upcoming tour of science schools with our lecture, “Invent or Debunk: Which is Better?” And, how a rent by the hour office can be better than the Sistine Chapel. --- Support this podcast: https://anchor.fm/tom-saunders9/support

durée : 00:03:22 - Le Pourquoi du comment : philo - par : Frédéric Worms - Hegel et le "Zeitgeist" ; l'esprit du temps ou l'histoire comme principe explicatif de tout le reste.

Today we chat with Cisco's head of developer content, community, and events, Michael Chenetz. We discuss everything from KubeCon to kindness and Legos! Michael delves into some of the main themes he heard from creators at KubeCon, and we discuss methods for increasing adoption of new concepts in your organization. We have a conversation about attending live conferences, COVID protocol, and COVID shaming, and then we talk about how Legos can be used in talks to demonstrate concepts. We end the conversation with a discussion about combining passions to practice creativity. We discuss our time at KubeCon in Spain (5:51) Themes Michael heard at KubeCon talking with creators (7:46) Increasing adoption of new concepts (9:27) We talk conferences, COVID shaming, and blamelessness (12:21) Legos and reliability  (18:04) Michael talks about ways to exercise creativity (23:20) Links: KubeCon October 2022: https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/ Nintendo Lego Set: https://www.amazon.com/dp/B08HVXMQ87?ref_=cm_sw_r_cp_ud_dp_ED7NVBWPR8ANGT8WNGS5 Cloud Unfiltered podcast episode featuring Julie and Jason:https://podcasts.apple.com/us/podcast/ep125-chaos-engineering-with-julie-gunderson-and-jason/id1215105578?i=1000562393884 Links Referenced: Cisco: https://www.cisco.com/ Cloud Unfiltered Podcast with Julie and Jason: https://podcasts.apple.com/us/podcast/ep125-chaos-engineering-with-julie-gunderson-and-jason/id1215105578?i=1000562393884 Cloud Unfiltered Podcast: https://www.cisco.com/c/en/us/solutions/cloud/podcasts.html Nintendo Lego: https://www.amazon.com/dp/B08HVXMQ87 TranscriptJulie: And for folks that are interested in, too, what day it is—because I think we're all still a little bit confused—it is Monday, May 24th that we are recording this episode.Jason: Uh, Julie's definitely confused on what day it is because it's actually Tuesday, [laugh] May 24th.Michael: Oh, my God. [laugh]. That's great. I love it.Julie: Welcome to Break Things on Purpose, a podcast about reliability, learning from each other, and blamelessness. In this episode, we talk to Michael Chenetz, head of developer content, community, and events at Cisco, about all of the learnings from KubeCon, the importance of being kind to each other, and of course, how Lego translates into technology.Julie: Today, we are joined by Michael Chenetz. Michael, do you want to tell us a little bit about yourself?Michael: Yeah. [laugh]. Well, first of all, thank you for having me on the show. And I'm really good at breaking things, so I guess that's why I'm asked to be here is because I'm superb at it. What I'm not so good at is, like, putting things back together.Like when I was a kid, I remember taking my dad's stereo apart; wasn't too happy about that. Wasn't very good at putting it back together. But you know, so that's just going back a little ways there. But yeah, so I work for the DevRel at Cisco and my whole responsibility is, you know, to get people to know that know a little bit about us in terms of, you know, all the developer-related topics.Julie: Well, and Jason and I had the awesome opportunity to hang out with you at KubeCon, where we got to join your Cloud Unfiltered podcast. So folks, definitely go check out that episode. We have a lot of fun. We'll put a link in the [show notes 00:02:03]. But yeah, let's talk a little bit about KubeCon. So, as of recording this episode, we all just recently traveled back from Spain, for KubeCon EU, which was… amazing. I really enjoyed being there. My first time in Spain. I got back, I can tell you, less than 24 hours ago. Michael, I think—when did you get back?Michael: So, I got back Saturday night, but my bags have not arrived yet. So, they're still traveling and they're enjoying Europe. And they should be back soon, I guess when they're when they feel like they're—you know, they should be back from vacation.Julie: [laugh].Michael: So. [laugh].Julie: Jason, how about you? When did you get home?Jason: I got home on Sunday night. So, I took the train from Valencia to Barcelona on Saturday evening, and then an early morning flight on Sunday and got home late Sunday night.Julie: And for folks that are interested in, too, what day it is—because I think we're all still a little bit confused—it is Monday, May 24th that we are recording this episode.Jason: Uh, Julie's definitely confused on what day it is because it's actually Tuesday, [laugh] May 24th.Michael: Oh, my God. [laugh]. That's great. I love it. By the way, yesterday was my birthday so I'm going to say—Julie: Happy birthday.Michael: —happy birthday to myself.Julie: Oh, my gosh, happy birthday. [laugh].Michael: Thank you [laugh].Julie: So… what is time anyway?Jason: Yeah.Michael: It's all good. It's all relative. Time is relative.Julie: Time is relative. And so, you know, tell us a little bit about—I'd love to know a little bit about why you want folks to know about, like, what is the message you try to get across?Jason: Oh, that's not the question I thought you were going to ask. I thought you were going to ask, “What's on your Amazon wishlist so people can send you birthday presents?”Julie: Yeah, let's back up. Let's do that. So, let's start with your Amazon wishlist. We know that there might be some Legos involved.Michael: Oh, my God, yeah. I mean, you just told me about a cool one, which was Optimus Prime and I just—I'm already on the website, my credit card is out and I'm ready to buy. So, you know, this is the problem with talking to you guys. [laugh]. It's definitely—you know, that's definitely on my list. So, anything that, anything music-related because obviously behind me is a lot of music equipment—I love music stuff—and anything tech. The combination of tech and music, and if you can combine Legos and that, too, man that would just match all the boxes. [laugh].Julie: Just to let you know, there's a Lego Con. Like, I did not know this until last night, actually. But it is a virtual conference.Michael: Really.Julie: Yeah. But one of the things I was looking at actually on Lego, when you look at their website, like, to request one of their speakers, to request one of their engineers as a speaker, they actually don't do that because they get so many requests for their folks to speak at conferences, they actually have a dedicated part of their website that talks about this. So, I thought that was interesting.Michael: Well listen, just because of that, if they want somebody that's in, you know, cloud computing, I'm not going to go talk for Lego. And I know they really want somebody from cloud computing talking to Lego, so, you know… it's, you know, quid pro quo there, so that's just the way it's going to work. [laugh].Julie: I want to be best friends with Lego people.Michael: [laugh]. I know, me too.Julie: I'm just going to make it a goal in life now to have one of their engineers speak at DevOpsDays Boise. It's like a challenge.Michael: It is. I accept it.Julie: [laugh]. With that, though, just on other Lego news, before we start talking about all the other things that folks may also want to hear about, there is another new Lego, which is the Van Gogh Starry Night that has been newly released by the time this episode comes out.Michael: With a free ear, right?Julie: I mean—[laugh].Michael: Is that what happens?Julie: —well played. Well, played. [laugh]. So, now you really got to spend a lot of time at KubeCon, you were just really recording podcast after podcast.Michael: Oh, my God. Yeah. So, I mean, it was great. I love—because I'm a techie, so I love tech and I love to find out origin stories of stuff. So, I love to, like, talk to these people and like, “Why did that come about? How did—” you know, “What happened in your life that made you want to do this? Who hurt you?” [laugh].And so, that's what I constantly try and figure out is, like, [laugh], “What is that?” So, it was really cool because I had, like, Jimmy Zelinskie who came from CoreOS, and he came from—you know, they create, you know, Quay and some of this other kinds of stuff. And you know, just to talk about, like, some of the operators and how they came about, and like… those were the original operators, so that was pretty cool. Varun from Tetrate was supposed to come on, and he created Istio, you know? So, there were so many of these things that I just geek out knowing about, you know?And then the other thing that was really high on our list, and it's really high from where I am, is API quality, API testing, API—so really, that's why I got in touch with you guys because I was like, “Wow, that fits in really good, you know? You guys are doing stuff that's around chaos, and you know, I think that's amazing.” So, all of this stuff is just so interesting to me. But man, it was just a whirlwind of every day just recording, and by the end that was just like, you know, “I'm so sorry, but I just, I can't talk anymore.” You know, and that was it. [laugh].Jason: I love that chatting with the creators. We had Zack Butcher on who is also from Tetrate and one of the early Istio—Michael: Yeah, yeah.Jason: Contributors. And I find it fascinating because I feel like when you chat with these folks, you start to understand the context of why things were built. And it—Michael: Yes.Jason: —it opens your brain up to, like, cool, there's a software—oh, now I know exactly why it's doing things that way, right? Like, it's just so, so eye-opening. I love it.Julie: With that, though, like, did you see any trends or any themes as you were talking to all these folks?Michael: Yeah, so a few real big trends. One is everybody wants to know about eBPF. That was the biggest thing at KubeCon, by far, was that, “We want to learn how to do this low-level kernel stuff that's really fast, that can give us all the information we need, and we don't have to use sidecars and things like that.” I mean it was—you know, that was the most excitement that I saw. OTel was another one for OpenTelemetry, which was a big one.The other thing was simplification. You know, a lot of people were looking to simplify the Kubernetes ecosystem because there's so much out there, and there's so many things that you have to learn about that it was super hard, you know, for somebody to come into it to say, “Where do I even start?” You know? So, that was a big theme was simplification.I'm trying to think. I think another one is APIs, for sure. You know, because there's this whole thing about API sprawl. And people don't know what their APIs are, people just, like—you know, I always say people can see—like, developers are lazy in a good way, and I consider myself one of them. So, what that means is that when we want to develop something, what we're going to do is we're just going to pull down the nearest API that does what we need, that has the best documentation, that has the best blog, that has the best everything.We don't know what their testing strategy is; we don't know what their security strategy is; we don't know if they use other libraries. And you have to figure that stuff out. And that's the thing that—you know, so everything around APIs is super important. And you really have to test that stuff out. Yes, people, you have to test it [laugh] and know more about it. So, those are those were the big themes, I think. [laugh].Julie: You know, I know that Kerim and I gave a talk on observability where we kind of talked more high-level about some of the overarching concepts, but folks were really excited about that. I think is was because we briefly touched on OpenTelemetry, which we should have gone into a little bit more depth, but there's only so much you can fit into a 30-minute talk, so hopefully we'll be able to talk about that more at a KubeCon in the future, we [crosstalk 00:09:54] to the selection committee.Michael: Hashtag topics?Julie: Uh-huh. [laugh]. You know, that said, though, it really did seem like a huge topic that people just wanted to learn more about. I know, too, at the Gremlin booth, a lot of folks were also interested in talking about, like, how do we just get our organization to adopt some of these concepts that we're hearing about here? And I think that was the thing that surprised me the most is I expected people to be coming up to the booth and deep-diving into very, very deep, technical-level questions, and really, a lot of it was how do we get our organization to do this? How can we increase adoption? So, that was a surprise for me.Michael: Yeah, you know what, and I would say two things to that. One is, when you talk about Chaos Engineering, I think people think it's like rocket science and people are really scared and they don't want to claim to be experts in it, so they're like, “Wow, this is, like, next-level stuff, and you know, we're really scared. You guys are the experts. I don't want to even attempt this.” And the other thing is that organizations are scared because they think that it's going to, like, create mass hysteria throughout their organization.And really, none of this is true in either way. In reality, it's a very, very scripted, very exacting stuff that you're testing, and you throw stuff out there and see what kind of response you get. So, you know, it's not this, like, you know—I think people just have—there needs to be more education around a lot of areas in cloud-native. But you know, that's one of the areas. So, I think it's really interesting there.Julie: I think so too. How about for you, Jason? Like, what was your surprise from the conference or something that maybe—Jason: Yeah, I mean, I think my surprise was mostly around just seeing people coming back, right? Because we're now I would say, six months into conferences being back as a thing, right? Like, we had re:Invent last year in Vegas; we had KubeCon last year in LA, and so, like, those are okay events. They weren't, like, back to normal. And this was, I feel like, one of the first conferences, that it really started to feel back to normal.Like, there was much better attendance, there was much more just buzz and hallway tracking and everything else that we're used to. Like, the whole reason that we go to conferences is getting together with people and hanging out and stuff, and this one has so far felt the most back-to-normal out of any event that I've been to over the past six months.Michael: Can I just talk about one thing that I think, you know, people have to get over is, you know, I see a lot online, I think it was—I forget who it was that was talking about it. But this whole idea of Covid shaming. I mean, we're going to this event, and it's like, yeah, everybody wants to get out, everybody wants to learn things, but don't shame people just because they got Covid, everybody's getting Covid, okay? That's just the point of life at this point. So, let's just, you know, let's just be nice to each other, be friendly to each other, you know? I just have to say that because I think it's a shame that people are getting shamed, you know, just for going to an event. [laugh].Julie: See, and I think that—that's an interesting—there's been a lot of conversation around this. And I don't think anybody should be Covid-shamed. Look, I think that we all took a calculated risk in coming—Michael: Absolutely.Julie: To this event. I personally gave out a lot of hugs. I hugged some of the folks that have mentioned that they have come up positive from Covid, so there's a calculated risk in going. I think there has been a little bit of pushback on maybe how some of the communication has come out around it. That said, as an organizer of a small conference with, like, 400 people, I think that these are very complicated matters. And what I really think is important is to listen to feedback from attendees and to take that.And then we're always looking to improve, right?Michael: Absolutely.Julie: If everything that we did was perfect right out of the gate, then we wouldn't have Chaos Engineering because there'd be nothing [crosstalk 00:13:45] be just perfectly reliable. And so, if we take away anything, let's take away—just like what you said, first of all, Covid, you should never shame somebody for having Covid. Like, that's not cool. It's not somebody's fault that they caught an illness.Michael: Yes.Julie: I mean unless they were licking doorknobs. And that's a whole different—Michael: Yes. [laugh]. That's a whole different thing, right there.Julie: Conversation. But when we talk about just like these questions around cultural adoption, we talk about blamelessness; we talk about learning from failure; we talked about finding ways to improve, and I think all of that can come into play. So, it'll be interesting to see how we learn and grow as we move forward. And like, thank you to re:Invent, thank you to KubeCon, thank you to DevOpsDays Boise. But these conferences that have started going back in-person, at great risk to organizers and the committee because people are going to be mad, one way or the other.Michael: Yeah. And you can see that people want to be back because it was huge, you know?Julie: Yeah.Michael: Maybe you guys, I'm going to put in a feature request for Gremlin to chaos engineer crowds. Can we do that so we can figure out, like, what's going to happen when we have these big events? Can we do that?Julie: I mean, that sounds fun. I think what's going to happen is there's going to be hugs, there's going to be people getting sick, but there's going to be people learning and growing.Michael: Yes.Julie: And ultimately, I just think that we have to remember that just, like, our systems aren't perfect, and neither are people. Like, the fact that we expect people to be perfect, and maybe we should just keep some mask mandates for a little bit longer when we're at conferences with 8000 people.Michael: Sure.Julie: I mean, that's—Michael: That makes sense.Jason: Yeah. I mean, it's all about risk management, right? This is, essentially what we do in SRE is there's always a risk of a massive outage, and so it's that balance of, right, do what you can, but ultimately, that's why we have SLOs and things is, you can never be a hundred percent, so like, where do we draw the line of here are the things that we're going to do to help manage this risk, but you can never shoot for a perfectly, entirely safe space, right? Because then we'd all be having conferences in padded rooms, and not touching each other, and things like that. There's a balance there.And I think we're all just trying to find that, so yeah, as you mentioned, that whole, like, DevOps blamelessness thing, you know, treat each other with the notion that we're all trying to get through this together and do what we think is best. Nobody's just like John Allspaw said, you know, “Nobody goes to work thinking that, like, their intent is to crash everything and destroy the company.” No one's going to KubeCon or any of these conferences thinking, “Yeah, I'm going to be a super-spreader.”Julie: [laugh].Michael: Yeah, that would be [crosstalk 00:16:22].Jason: Like, everyone's trying not to do it. They're doing their best. They're not actively, like, aggressively trying to get you sick or intentionally about it. But you know—so just be kind to one another.Michael: Yeah. And that's the key.Julie: It is.Michael: The key. Be kind to one another, you know? I mean, it's a great community. People are really nice, so, you know, let's keep that up. I think that's something special about the, you know, the community around KubeCon, specifically.Julie: As we can refine this and find ways, I would take all of the hugs over virtual conferences—Michael: Yes.Julie: Any day now. Because, as Jason mentioned, is even just with you, Michael, the time we got to spend with you, or the time I kept going up to Jfrog's booth and Baruch and I would have conversations as he made me a delicious coffee, these hallway tracks, these conversations, that's what no one figured out how to recreate during the virtual events—Michael: Absolutely.Julie: —and it's just not possible, right?Michael: Yeah. I mean, I think it would take a little bit of VR and then maybe some, like, suit that you wear in order to feel the hug. And, you know, so it would take a lot more in order to do that. I mean, I guess it's technologically possible. I don't know if the graphics are there yet, so it might be like a pixelated version, like, you know, like, NES-style, or something like that. But it could look pretty cool. [laugh]. So, we'll have to see, you know?Julie: Everybody listening to this episode, I hope you're getting as much of a kick out of it as we are recording it because I mean, there are so many different topics here. One of the things that Michael and I bonded about years ago, for our listeners that are—not years ago; months ago. Again, what is time?Michael: Yeah. What is time? It's all relative.Julie: It is. It was Lego, though, and so we've been talking about that. But Michael, you asked a great question when we were recording with you, which is, like—Michael: Wow.Julie: Can—just one. Only one great question.Michael: [laugh].Julie: [laugh]. Which was, how would you incorporate Lego into a talk? And, like, when we look at our systems breaking and all of that, I've really been thinking about that and how to make our systems more reliable. And here's one of the things I really wanted to clarify that answer. I kind of went… I went talking about my Lego that I build, like, my Optim—not my Optimus Primes, I don't have it, but my Voltron or my Nintendo Lego. And those are all box sets.Michael: Yep.Julie: But one of the things if you're not playing with a box set with instruction, if you're just playing with just the—or excuse me, architecting with just the Lego blocks because it's not playing because we're adults now, I think.Michael: Yes, now it's architecting. Yes.Julie: Yes, now that we're architecting, like, that's one of the things that I was really thinking about this, and I think that it would make something really fun to talk about is how you're building upon each layer and you're testing out these new connection pieces. And then that really goes into, like, when we get into Technics, into dependencies because if you forget that one little one-inch plastic piece that goes from the one to the other, then your whole Lego can fall apart. So anyway, I just thought that was really interesting, and I'd wondered if you or Jason even gave that any more thought, or if it was just fleeting for you.Michael: It was definitely fleeting for me, but I will give it some more thought, you know? But you know, when—as you're saying that though, I'm thinking these Lego pieces really need names because you're like that little two-inch Lego piece that kind of connects this and this, like, we got to give these all names so that people can know, that's x-54 that's—that you're putting between x-53 and x-52. I don't know but you need some kind of name for these parts now.Julie: There are Lego names. You just Google it. There are actual names for all of the parts but—Michael: Wow. [laugh].Julie: Like, Jason, what do you think? I know you've got [unintelligible 00:19:59].Jason: Yeah, I mean, I think it's interesting because I am one of those, like, freeform folks, right? You know, my standard practice when I was growing up with Legos was you build the thing that you bought once and then you immediately, like, tear it apart, and you build whatever the hell you want.Michael: Absolutely.Jason: So, I think that that's kind of an interesting thing as we think about our systems and stuff, right? Like, part of it is, like, yeah, there's best practices and various companies will publish, like, you know, “Here's how to architect such-and-such system.” And it's interesting because that's just not reality, right? You're not going to go and take, like, the Amazon CloudFormation thing, and like, congrats, you're done. You know, you just implement that and your job's done; you just kick back for the rest of the week.It never works that way, right? You're taking these little bits of, like, cool, I might have, like, set that up once just to see what's happening but then you immediately, like, deconstruct it, and you take the knowledge of what you learned in those building blocks, and you, like, go and remix it to build the thing that you actually need to build.Michael: But yeah, I mean, that's exactly—so you know, Legos is what got me interested in that as a kid, but when you look at, you know, cloud services and things like that, there's so many different ways to combine things and so many different ways to, like—you know, you could use Terraform, you could use Crossplane, you could use, you know, any of the services in the cloud, you could use FaaS, you could use serverless, you could use, you know, all these different kinds of solutions and tie them together. So, there's so much choice, and what Lego teaches you is that, embrace the choice. Figure out and embrace the different pieces, embrace all the different things that you have and what the art of possibility is, and then start to build on that. So, I think it's a really good thing. And that's why there's so much correlation between, like, kind of, art and tech and things like that because that's the kind of mentality that you need in order to be really successful in tech.Jason: And I think the other thing that works really well with what you said is, as you're playing with Legos, you start to learn these hacks, right? Like, I don't have, like, a four-by-one brick, but I know that if I have three four-by-one flats, I can stack those three and it's the same height as a brick, right?Michael: Yep.Jason: And you can start combining things. And I love that engineering mentality of, like, I have this problem that I need to solve, I have a limited toolbox for whatever constraints, right, and understanding those constraints, and then cool, how can I remix what I've got in my toolbox to get this thing done?Michael: And that's a thing that I'm always doing. Like, when I used to do a lot of development, you know, it was always like, what is the right code? Or what is the library that's going to solve my problem? Or what is the API that's going to solve my problem, you know?And there's so many different ways to do it. I mean, so many people are afraid of, like, making the wrong choice, when really in programming, there is no wrong choice. It's all about how you want to do it and what makes sense to you, you know? There might be better options in formatting and in the way that you kind of, you know, format that code together and put them in different libraries and things like that, but making choices on, like, APIs and things like that, that's all up to the artist. I would say that's an artist. [laugh]. So, you know, I think it all stems though, when you go back from, you know, just being creative with things… so creativity is king.Jason: So Michael, how do you exercise your creativity, then? How do you keep up that creativity?Michael: Yeah, so there's multiple ways. And that's a great segment because one of the things that I really enjoy—so you know, I like development, but I'm also a people person. And I like product management, but I also like dealing with people. So really, to me, it's about how do I relate products, how do I relate solutions, how do I talk to people about solutions that people can understand? And that's a creative process.Like, what is the right media? What is the right demos? What is the right—you know, what do people need? And what do people need to, kind of, embrace things? And to me, that's a really creative medium to me, and I love it.So, I love that I can use my technical, I love that I can use my artistic, I love that I can use, you know, all these pieces all at once. And sometimes maybe I'll play guitar and just put it in the intro or something, I don't know. So, that kind of combines that together, too. So, we'll figure that piece out later. Maybe nobody wants to hear me play guitar, that's fine, too. [laugh].But I love to be able to use, you know, both sides of my brain to do these creative aspects. So, that's really what does it. And then sometimes I'll program again and I'll find the need, and I'll say, “Hey, look, you know, I realized there's a need for this,” just like a lot of those creators are. But I haven't created anything cool, but you know, maybe someday I will. I feel like it's just been in between all those different intersections that's really cool.Jason: I love the electric guitar stuff that you mentioned. So, for folks who are listening to this show, during our recording of the Cloud Unfiltered you were talking about bringing that art and technical together with electric guitars, and you've been building electric guitar pickups.Michael: Yes. Yeah. So, I mean, I love anything that can combine my music passion with tech, so I have a CNC machine back here that winds pickups and it does it automatically. So, I can say, “Hey, I need a 57 pickup, you know, whatever it is,” and it'll wind it to that exact spec.But that's not the only thing I do. I mean, I used to design control surfaces for artists that were a big band, and I really can't—a lot of them I can't mention because we're under NDA. But I designed a lot of these big, you know, control surfaces for a lot of the big electronic and rock bands that are out there. I taught people how to use Max for Live, which is an artist's, kind of, programming language that's graphical, so [NMax 00:25:33] and MSP and all that kind of stuff. So, I really, really like to combine that.Nowadays, you know, I'm talking about doing some kind of events that may be combined tech, with art. So, maybe doing things like Algorave, and you know, things that are live-coding music and an art. So, being able to combine all these things together, I love that. That's my ultimate passion.Jason: That is super cool.Julie: I think we have learned quite a bit on this episode of Break Things on Purpose, first of all, from the guy who said he hasn't created much—because you did say that, which I'm going to call you out on that because you just gave a long list of things that you created. And I think we need to remember that we're all creators in our own way, so it's very important to remember that. But I think that right now we've created a couple of options for talks in the future, whether or not it's with Lego, or guitar pickups.Michael: Yeah.Julie: Is that—Michael: Hey—Julie: Because I—Michael: Yeah, why not?Julie: —know you do kind of explain that a little bit to me as well when I was there. So, Michael, this has just been amazing having you. We're going to put a lot of links in the notes for everybody today. So, to Michael's podcast, to some Lego, and to anything else Michael wants to share with us as well. Oh, real quick, is there anything you want to leave our listeners with other than that? You know, are you looking to hire Cisco? Is there anything you wanted to share with us?Michael: Yeah, I mean, we're always looking for great people at Cisco, but the biggest thing I'd say is, just realize that we are doing stuff around cloud-native, we're not just network. And I think that's something to note there. But you know, I just love being on the show with you guys. I love doing anything with you guys. You guys are awesome, you know. So.Julie: You're great too, and I think we'll probably do more stuff, all of us together, in the future. And with that, I just want to thank everybody for joining us today.Michael: Thank you. Thanks so much. Thanks for having me.Jason: For links to all the information mentioned, visit our website at gremlin.com/podcast. If you liked this episode, subscribe to the Break Things on Purpose podcast on Spotify, Apple Podcasts, or your favorite podcast platform. Our theme song is called, “Battle of Pogs” by Komiku, and it's available on loyaltyfreakmusic.com.

durée : 00:03:13 - Le Pourquoi du comment : Philo - par : Frédéric Worms - Hegel et le "Zeitgeist" ; l'esprit du temps ou l'histoire comme principe explicatif de tout le reste.

How to start with nothing and invent your type of marketing empire with Marco Torres. Marco Torres is the Founder of MarketingBoost.com, he has helped thousands of business owners worldwide boost sales and scale their businesses by as much as 5-fold through the use of incentive-based marketing. He teaches entrepreneurs how to soar in sales & marketing through the use of “Value-Add-Incentives” instead of discounts. His Facebook Group is home to more than 27,000 active business owners who are raking in sales with his advice and amazingly affordable subscription program.

In this momentous episode 200 of Directly to You, AJ and Parker are joined by to create the BEST Nintendo pitches for prompts like "Nintendo is asked to make a Marvel platformer - what series do they choose, and how would it play?" or "Invent your brand new IP idea for Nintendo", and what's at stake? Steak! Also, is Switch sports a sequel to Wii sports or not?? We talk about all that and much MORE! Timestamps: 0:00 - Housekeeping 2:30 - Nintendo Shark Tank 1:11:55 - Nintendo Switch Sports used to be Hamburgers 1:22:45 - What we're playing 1:35:35 - Q&A Support us on Patreon to help us grow the channel! ➡️ https://www.patreon.com/watchredirect Join our Discord server here ➡️ https://www.discord.gg/invite/2TqtuRU Follow us on Twitter! Re:Direct ➡️ https://www.twitter.com/watchredirect AJ ➡️ https://www.twitter.com/amcraejr Parker ➡️ https://www.twitter.com/parkerdeal --- Send in a voice message: https://anchor.fm/dty/message Support this podcast: https://anchor.fm/dty/support

In this episode, Emily and Dave chat with Talia Nassi, a Senior Developer Advocate for AWS Serverless. Talia covers her cloud career, Q&A, and the oddly effective method of testing in production. One of Talia's passions is EDA, or Event Driven Architecture. In this chat, Talia walks through the different event driven AWS services developers can utilize, when to choose one over the other, and how best to get started. Talia on Twitter: https://twitter.com/talia_nassi Emily on Twitter: twitter.com/editingemily Dave on Twitter: twitter.com/thedavedev Talia at AWS re:Invent 2021 - What's New in Serverless: https://bit.ly/3sXv1cc Talia on the Benefits of Migrating to an Event Driven Architecture: https://go.aws/3LVU0Dr AWS Serverless Land – News for Developers on All the Serverless Things: https://serverlessland.com/ Amazon Event Bridge: https://aws.amazon.com/eventbridge/ AWS Compute Blog: https://aws.amazon.com/blogs/compute/ Serverless Espresso Workshop: https://bit.ly/3PHKfMp Subscribe: Amazon Music: https://music.amazon.com/podcasts/f8bf7630-2521-4b40-be90-c46a9222c159/aws-developers-podcast Apple Podcasts: https://podcasts.apple.com/us/podcast/aws-developers-podcast/id1574162669 Google Podcasts: https://podcasts.google.com/feed/aHR0cHM6Ly9mZWVkcy5zb3VuZGNsb3VkLmNvbS91c2Vycy9zb3VuZGNsb3VkOnVzZXJzOjk5NDM2MzU0OS9zb3VuZHMucnNz Spotify: https://open.spotify.com/show/7rQjgnBvuyr18K03tnEHBI TuneIn: https://tunein.com/podcasts/Technology-Podcasts/AWS-Developers-Podcast-p1461814/ RSS Feed: https://feeds.soundcloud.com/users/soundcloud:users:994363549/sounds.rss

Aïe, le soleil t'éblouit… Heureusement que les lunettes de soleil existent ! Mais qui a eu cette idée ? Julien te raconte…Du verre coloré pour ne pas être ébloui  En 1752, un opticien anglais, James Ayscough, veut aider certains de ses clients à mieux voir. Pour corriger leurs problèmes de vue, il teste des verres colorés sur ses paires de lunettes. Sans succès ! Par contre, il se rend compte que ça empêche d'être ébloui par le soleil…  Le verre teinté permet de filtrer les rayons du soleil. Il existe plusieurs sortes de rayonnements, qui correspondent chacun à une couleur de l'arc-en-ciel… Quand toutes ces couleurs se superposent ça donne une lumière blanche, qui peut être éblouissante. En mettant un verre de couleur devant notre œil, on va filtrer une partie des rayons. Résultat : on est moins ébloui.   Ce principe est d'ailleurs connu depuis bien longtemps. Dans l'Antiquité, l'empereur romain Néron utilisait des émeraudes (une pierre précieuse de couleur verte) pour regarder les combats de gladiateurs. Ainsi, il n'était pas aveuglé par le soleil.  Les UV, dangereux pour notre santé  Attention, un verre coloré protège de l'éblouissement, mais pas forcément des UV.  UV signifie ultraviolets. C'est un certain type de rayons émis par le soleil. Ils produisent une lumière invisible à l'œil nu, mais dangereuse pour notre santé : ce sont ces UV qui provoquent les coups de soleil, des maladies de peau ou des maladies des yeux… qui peuvent finir par rendre aveugle.   En réalité, les lunettes de soleil pour se protéger de ces UV existent depuis des milliers d'années. Ce sont les Inuits qui les ont inventés.  Les “Ilgaak”, des lunettes inventées par les Inuits pour se protéger de la lumière  Les Inuits, c'est un peuple du grand Nord qui vit près du cercle polaire Arctique dans le froid et la neige. Leur paysage, c'est la banquise, la forêt boréale, les steppes enneigées… Bref, du blanc à perte de vue ! Et la couleur blanche renvoie énormément les rayons du soleil, contrairement au noir qui les absorbe.  Dans ces paysages enneigés, nos yeux sont donc beaucoup plus exposés aux rayons du soleil et la lumière peut devenir aveuglante. Les UV sont trop forts et l'on peut perdre la vue. Pour se protéger, les Inuits ont donc eu l'idée de limiter la quantité de lumière qui arrive sur l'œil. Ils ont inventé les “Ilgaak” (le nom des lunettes de soleil chez les Inuits).  Les “Ilgaak” sont fabriquées avec du bois, ou un os de baleine, ou l'ivoire d'une dent de morse. Elles sont sculptées pour suivre les contours du visage : une forme allongée, un petit creux au centre pour le nez et, au niveau des yeux, on creuse deux fentes très très étroites. Les yeux sont ainsi protégés car les rayons ont plus de mal à atteindre la pupille de l'œil.   Grâce aux “Ilgaak”, les Inuits peuvaient continuer à chasser sur la banquise, en plein soleil, sans risquer de perdre la vue.

Who do you see when you look in the mirror? Does the world see that same person? Your peers' perception of you is everything. So, why do some people drag their feet in building their personal brands? In this episode, I sit down with Kyle Lacy, SVP of Marketing at Seismic, to talk about the perks of crafting a positive persona for the masses. A co-author of the book Branding Yourself: How to Use Social Media to Invent or Reinvent Yourself, Kyle lays the groundwork for you to trademark your winning brand. Join us as we discuss: - How personal branding is different from self-promotion [3:18] - Some potential roadblocks, such as compliance and content creation [11:10] - How you can start building your brand and reaping the benefits [17:35] Check out these resources we mentioned during the podcast: - Connect with Kyle on LinkedIn - Email Kyle at kylelacy@gmail.com - Follow Kyle on Twitter You can find this interview and many more by subscribing to Banking on Digital Growth on Apple Podcasts, on Spotify, or here. Listening on a desktop & can't see the links? Just search for Banking on Digital Growth in your favorite podcast player.

In the 1980's, we would do anything to convince our parents to roll through the drive-thru just for the chance to snag the latest toy from our favorite cartoon or movie. Whether you longed for Barbie or Hot Wheels, McRobots or Boo Buckets, cruise on back with us to discover the hotly debated origin of kids meals, unlock the memories of your favorite prizes, and find out how the fast food chains have fared amidst the legal battles, health concerns, and plastic waste.   -- Can I Borrow Your Notes? --  Did McDonald's Invent the Fast Food Kid's Meal? (Culinary Lore) The History of the McDonald's Happy Meal Toys (Wide Open Eats) The Past, Present, and Future of Happy Meal Toys (Eater) McDonald's Happy Meal Toys: A Timeline of the Best Toys Over the Years (Quality Logo Products) The Era of fast-food toys begins to melt away (NNY 360) Taco Bell discontinues kids' meals and toys, says it's the first (LA Times)   -- Teacher's Pets --  Join the Class of 80's High: 80shighpodcast@gmail.com Follow on Instagram: @80shighpodcast and Twitter: @high_80s Theme song by Greg Reed at gregreedmusic.com Cover art by Alex Goddard at alexgoddarddesign.com

durée : 00:52:11 - Le Cours de l'histoire - par : Xavier Mauduit - En Angleterre, la Déclaration des Droits de 1689 renforce les pouvoirs du Parlement et limite le rôle politique du roi. Deux groupes politiques émergent et se structurent peu à peu : les Whigs et les Tories. Comment ce nouveau modèle bipartisan influence-t-il les États-Unis et les pays européens ? - invités : Philippe Chassaigne historien, professeur d'histoire contemporaine à l'Université Bordeaux Montaigne; Rémy Duthille Agrégé d'anglais, maître de conférences en civilisation britannique à l'Université Bordeaux Montaigne

Entre 1949 et 1962, l'Union soviétique conduit une série d'essais nucléaires dans la ville de Semipalatinsk, au Kazakhstan. Son but : construire une arme plus redoutable encore que la bombe atomique américaine qui a détruit Hiroshima en 1945. Dans ce nouvel épisode du podcast "Au cœur de l'Histoire", Clémentine Portier-Kaltenbach dresse le portrait de l'artisan qui a permis à ces expériences de voir le jour : Andreï Sakharov, inventeur de la bombe à hydrogène. Et futur Prix Nobel de la Paix.

Joe Schurman teaches from his deep experience in the software, machine learning, AI, and processes that organizations need today as they transition to data-driven technology companies. He names some of the cloud services and tech tools he uses to lead clients to start with a user case, break it into stories,  build a team led by the solution owner, assign the stories to developers to build, and iterate product demos until the Minimum Loved Project (MLP) is achieved. Joe offers observations on investing the “right” amount of time in projects, and wisdom on developing a learner mindset.   Key Takeaways [2:06] Joe Schurman is a 2nd-degree black belt in Kung Fu. He once judged a competition in Las Vegas. He has four children; two daughters and two sons. [2:57] Joe is an expert on the fringes of what we can do with computing technology. What we can do changes every day. In the past couple of years, from an AI perspective, with data and automation, it's taken leaps and bounds. [4:30] We're still pretty far away from general AI, despite Sophia, an AI robot that was granted Saudi Arabian citizenship in 2017. Today's AI depends on the programming we give a machine and its interpretation and output. Joe's focus is narrow or weak AI. His business colleagues call it magic. Computer vision is an area he loves. [5:45] Joe uses a lab environment across Google Cloud Platform, Microsoft Azure, and Amazon Web Services. The capabilities that have come up in the last year are “just insane” with what you can do with computer vision and building libraries of what the machine can see. [6:06] Joe loved seeing a computer vision capability demonstration at AWS re:Invent of tracking every NFL player on the field and predicting injuries and other types of output and insights in real-time. The machine used narrow AI to access a library seeded with “a ton” of data to interpret the action. [7:15] What you can do with this technology comes down to the data that you feed the engine. Think about the amounts of data that organizations have to sift through to generate reflective or predictive insights. Auto machine learning helps organize the data into useful information such as anomaly detection in software engineering. The data can also come from tools like GitHub and Jira. [8:25] Joe did a fun computer vision project on UAPs for the History Channel, working with some of the nation's top military leaders, building a library of video and audio data to be able to detect unidentified aerial phenomena that were not supposed to be entering our airspace, and curating that library. [10:06] AI started with the idea of speeding up processes, such as getting an app to market faster or gathering insights quicker to make business decisions more timely. [11:28] AI can enhance human performance. Joe starts by finding people who know how to fail fast; to get a Minimum Viable Product (MVP) out the door. Solutions such as quality engineering automation, test automation, and monitoring services for DevOps detect bugs and performance issues quickly and ensure that the quality of the team is sound.[12:47] Joe notes the importance of individuals performing, contributing to, and collaborating as a team. Set your organization and standards governance up first. Look for a platform of technology to leverage that enables you to build and tinker. Finding the latest and greatest tool is no good unless it provides the right level of collaboration with their platform and connection to different processes. [14:53] When introducing ML to an organization, start with discovery, to understand the culture and talent within the organization. How are they communicating today? Joe sees the biggest gap between data scientists and data engineers. Projects tend to fail without collaboration, regardless of the tech. If the data scientists don't understand the domain, then the platform is irrelevant,[17:28] Joe stresses the need for a methodology in place to make any of these aspirations work for your organization. After discovery, there's an align phase. Focus on the outcome and the use case. The solution owner is crucial. The solution owner leads the technology team and brings them together around the client's outcome to develop that use case.[18:12] If you can't take an actual use case and break it down into bite-sized chunks or user stories, then the project will never be on the right track. Start with the use case to mitigate risks. Break the use case into user stories. Match the user stories with the number of engineers that can develop a number of user stories within a given time frame. [18:38] Those user stories given to the engineers are deducted into Story Points, in the Agile Process of engineering software. Price Waterhouse Coopers (PcW) has taken it to the next level, being able to do Engineering as a Service, being able to do it at scale, and being able to pivot quickly.[18:58] Joe explains what can happen if you have a great idea, take three to six months to break down the use case, and fill all the requirements, but hand it off to the Dev team that has no idea what the use case is: you get irrelevant software that doesn't tie back to the outcome! [19:22] Keep the solution team engaged in building the bridge between the subject matter expert stakeholders and the engineers. Every two weeks, demonstrate the iteration or program increment you have built. Does it match the outcome? Does it provide any relevance? Then take the feedback and figure out what happened in that iteration. Fix errors. You will build a product that has value to launch. [20:45] Communicate a lot, so all the people are on the same page! When you have stovepiped organizations where the departments don't talk to one another, you waste time, effort, and money building a product no one will use. One of Joe's colleagues, José Reyes, uses the term Minimum Lovable Project (MLP), where people rally around the outcome, not just the tech. [22:33] What skills and knowledge will the leaders of PwC need to endure for the next five years? Joe says first are character and attitude; people that have a hunger to build something, with a fail-fast mentality, and that are excited to learn constantly, that read every day and learn new technology. [24:27] Then know the tools. Documents exist on the internet for every solution and there is access to services like GitHub to download projects and starter templates without being an expert but just reading the README file and installing the base-level template, learning as you go, and as you tinker. That's way more valuable than coming in as a book-smart expert in a specific product or technology. [24:57] When it comes to tooling, there are products like the Atlassian platform with Confluence and Jira. For an AI stack, Joe typically works with AWS, GPC, and Microsoft, more so on the Amazon side with AWS AI tools, like Rekognition, Glue DataBrew, Redshift ML, Comprehend, and more. Amazon, Microsoft, and Google produce so much documentation and certification to get you up to speed. [26:30] Judgment, wisdom, and character will not be replaced by AI anytime soon. There's still room for philosophy in leadership. There are tools and technologies to speed up the processes, but not the individuals. There are no general AI solutions out yet to replace a pod of application developers, designers, and solution owners to execute a successful MVP or MLP out the door for a client. [27:55] Advice to CEOs: Be patient and understanding. Be willing to fail fast. Support tinkering and R&D, even if the project doesn't work out. Organizations are generally realizing that today they need to be data-driven, technology companies but there is still hesitance over the risk that needs to be taken. [30:03] Why would an insurance company or other traditional company need R&D? Look at Loonshots, by Safi Bahcall for some ideas about R&D. [30:56] Joe shares how he got to this point in his career. He wanted to play baseball but started at Compaq (now HP) when he was 18, writing scripts in Unix and other environments. Just being able to make certain changes to help clients get products faster and seeing the quick response from the outcomes felt like a home run to him! [31:49] Years later, Joe went on his own, with a vision to create telehealth before telemedicine was a thing, using Skype for Business and Microsoft Lync, enabling an API for that. Seeing people connect through a technology he had built, replaced the need to be a baseball star! Joe is grateful for the break he got at a young age and enjoys his work. [33:22] When Joe first started, he was trying to be the smartest person in the room, seeing the instant gratification of making code snippets that tested successfully. Eventually just building the app wasn't enough for him. He got the dopamine hit from seeing users interacting with his code and seeing its value. [34:58] Joe's mentors include many people he worked with. X. D. Wang at Microsoft Research inspired him to tinker, build, and focus on the short-run more than the long-run. Randeep Sing Pal at Microsoft Unified Communications was another great mentor. Also Steve Justice and Chris Mellon, in terms of character and collaboration. Joe shares how they mentored him. [37:23] Jan says something we forget about technology is that there are a lot of failures and attempts before the success hits. We have to be mindful of that as leaders to give people time and space to do really creative, cool things. [38:01] Joe appreciates the opportunity to discuss these things. Joe spent a lot of his career building software solutions that were way ahead of their time. It's frustrating to see telemedicine so successful now, but not when he attempted it. He had to learn to let go. It's not just about releasing bleeding-edge tech; you've got to find some value associated with it to resonate with the end-user. [39:31] Always think about the outcome and understand your audience first. And then be able to supplement the back end of that with bleeding-edge technology, development, tinkering, failing fast, and all the things that go with software engineering. Also, be humble! Get perspective from outside your bubble to build a better solution and be a better person. [40:49] WHenever you're setting out to build anything, start with a press release! Write a story of what it would look like if it were released today. Then just work back from there!   Quotable Quotes “There are so many new and cool technologies and innovations that are coming out at the speed of thought, which are pretty fascinating.” “I've been in real cloud engineering for about a decade, and from an AI perspective, with data and automation, over the past five to 10 years, in terms of running on a cloud environment, and it's just taken leaps and bounds.” “You've got to be able to connect that [data] environment to a use case or an outcome. If you can't do that and you can't enable a data scientist to understand the domain, then the data platform is irrelevant. I see a lot of performance issues occur because of that disconnect.” “If you can't take an actual use case and break it down into bite-sized chunks or user stories, then the project will never be on the right track.” “In this industry, you're constantly learning; constantly reading. I'm reading every day and learning about new technology every day and how to apply it and how to tinker with it. I need people on the team … that have that ability or that hunger to tinker and learn.” “Transitioning from a ‘knower' mindset to a ‘learner' mindset was the biggest shift for me.” “Always think about the outcome and understand your audience first. And then be able to supplement the back end of that with bleeding-edge technology, development, tinkering, failing fast, and all the things that go with software engineering.”   Resources Mentioned Joe Schurman, PwC Joe Schurman on LinkedIn PwC Sophia robot granted citizenship I, Robot film Weak AI Google Cloud Platform Microsoft Azure Amazon Web Services AWS re:Invent GitHub Atlassian Jira Unidentified, The History Channel José Reyes, PwC The Shackleton Journey Atlassian Confluence AWS Rekognition AWS Glue DataBrew AWS Redshift ML AWS Comprehend Steve Justice on LinkedIn Chris Mellon Loonshots: How to Nurture the Crazy Ideas That Win Wars, Cure Diseases, and Transform Industries, by Safi Bahcall  

Le 6 août 1945, les Etats-Unis lâchent la première bombe atomique de l'Histoire sur la ville d'Hiroshima. Une semaine plus tard, Staline donne l'ordre de mettre au point une arme plus redoutable encore que celle de l'ennemi, pour que l'Union Soviétique devienne la première puissance mondiale. Dans ce nouvel épisode du podcast "Au cœur de l'Histoire", Clémentine Portier-Kaltenbach décrit la mission confiée aux chercheurs envoyés au Kazakhstan, dont fait partie un certain Andreï Sakharov… futur Prix Nobel de la Paix.

About JamesJames has been part of AWS for over 15 years. During that time he's led software engineering for Amazon EC2 and more recently leads the AWS Commerce Platform group that runs some of the largest systems in the world, handling volumes of data and request rates that would make your eyes water. And AWS customers trust us to be right all the time so there's no room for error.Links Referenced:Email: jamesg@amazon.comTranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: This episode is sponsored in part by our friends at Vultr. Optimized cloud compute plans have landed at Vultr to deliver lightning-fast processing power, courtesy of third-gen AMD EPYC processors without the IO or hardware limitations of a traditional multi-tenant cloud server. Starting at just 28 bucks a month, users can deploy general-purpose, CPU, memory, or storage optimized cloud instances in more than 20 locations across five continents. Without looking, I know that once again, Antarctica has gotten the short end of the stick. Launch your Vultr optimized compute instance in 60 seconds or less on your choice of included operating systems, or bring your own. It's time to ditch convoluted and unpredictable giant tech company billing practices and say goodbye to noisy neighbors and egregious egress forever. Vultr delivers the power of the cloud with none of the bloat. “Screaming in the Cloud” listeners can try Vultr for free today with a $150 in credit when they visit getvultr.com/screaming. That's G-E-T-V-U-L-T-R dot com slash screaming. My thanks to them for sponsoring this ridiculous podcast.Corey: Finding skilled DevOps engineers is a pain in the neck! And if you need to deploy a secure and compliant application to AWS, forgettaboutit! But that's where DuploCloud can help. Their comprehensive no-code/low-code software platform guarantees a secure and compliant infrastructure in as little as two weeks, while automating the full DevSecOps lifestyle. Get started with DevOps-as-a-Service from DuploCloud so that your cloud configurations are done right the first time. Tell them I sent you and your first two months are free. To learn more visit: snark.cloud/duplo. Thats's snark.cloud/D-U-P-L-O-C-L-O-U-D. Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. And I've been angling to get someone from a particular department at AWS on this show for nearly its entire run. If you were to find yourself in an Amazon building and wander through the various dungeons and boiler rooms and subterranean basements—I presume; I haven't seen nearly as many of you inside of those buildings as people might think—you pass interesting departments labeled things like ‘Spline Reticulation,' or whatnot. And then you come to a very particular group called Commerce Platform.Now, I'm not generally one to tell other people's stories for them. My guest today is James Greenfield, the VP of Commerce Platform at AWS. James, thank you for joining me and suffering the slings and arrows I will no doubt be hurling at you.James: Thanks for having me. I'm looking forward to it.Corey: So, let's start at the very beginning—because I guarantee you, you're going to do a better job of giving the chapter and verse answer than I would from a background mired deeply in snark—what is Commerce Platform? It sounds almost like it's the retail website that sells socks, books, and underpants.James: So, Commerce Platform actually spans a bunch of different things. And so, I'm going to try not to bore you with a laundry list of all of the things that we do—it's a much longer list than most people assume even internal to AWS—at its core, Commerce Platform owns all of the infrastructure and processes and software that takes the fact that you've been running an EC2 instance, or you're storing an object in S3 for some period of time, and turns it into a number at the end of the month. That is what you asked for that service and then proceeds to try to give you as many ways to pay us as easily as possible. There are a few other bits in there that are maybe less obvious. One is we're also responsible for protecting the platform and our customers from fraudulent activity. And then we're also responsible for helping collect all of the data that we need for internal reporting to support some of the back-ends services that a business needs to do things like revenue recognition and general financial reporting.Corey: One of the interesting aspects about the billing system is just how deeply it permeates everything that happens within AWS. I frequently say that when it comes to cloud, cost and architecture are foundationally and fundamentally the same exact thing. If your entire service goes down, a few interesting things happen. One, I don't believe a single customer is going to complain other than maybe a few accountants here and there because the books aren't reconciling, but also you've removed a whole bunch of constraints around why things are the way that they are. Like, what is the most efficient way to run this workload?Well, if all the computers suddenly become free, I don't really care about efficiency, so much is, “Oh, hey. There's a fly, what do I have as a flyswatter? That's right, I'm going to drop a building on it.” And those constraints breed almost everything. I've said, for example, that S3 has infinite storage because it does.They can add drives faster than we're able to fill them—at least historically; they added some more replication services—but they're going to be able to buy hard drives faster than the rest of us are going to be able to stretch our budgets. If that constraint of the budget falls away, all bets are really off, and more or less, we're talking about the destruction of the cloud as a viable business entity. No pressure or anything.James: [laugh].Corey: You're also a recent transplant into AWS billing as a whole, Commerce Platform in general. You spent 15 years at the company, the vast majority of that over an EC2. So, either it was you've been exiled to a basically digital Siberia or it was one of those, “Okay, keeping all the EC2 servers up, this is easy. I don't see what people stress about.” And they say, “Oh, ho ho, try this instead.” How did you find yourself migrating over to the Commerce Platform?James: That's actually one I've had a lot from folks that I've worked with. You're right, I spent the first 15 or so years of my career at AWS in EC2, responsible for various things over there. And when the leadership role in Commerce Platform opened up, the timing was fortuitous, and part of it, I was in the process of relocating my family. We moved to Vancouver in the middle of last year. And we had an opening in the role and started talking about, potentially, me stepping into that role.The reason that I took it—there's a few reasons, but the primary reason is that if I look back over my career, I've kind of naturally gravitated towards owning things where people only really remember that they exist when they're not working. And for some reason, you know, I enjoy the opportunity to try to keep those kinds of services ticking over to the point where people don't notice them. And so, Commerce Platform lands squarely in that space. I've always been attracted to opportunities to have an impact, and it's hard to imagine having much more of an impact than in the Commerce Platform space. It underpins everything, as you said earlier.Every single one of our customers depends on the service, whether they think about it or realize it. Every single service that we offer to customers depends on us. And so, that really is the sort of nexus within AWS. And I'm a platform guy, I've always been a platform guy. I like the force multiplier nature of platforms, and so Commerce Platform, you know, as I kind of thought through all of those elements, really was a great opportunity to step in.And I think there's something to be said for, I've been a customer of Commerce Platform internally for a long time. And so, a chance to cross over and be on the other side of that was something that I didn't want to pass up. And so, you know, I'm digging in, and learning quickly, ramping up. By no means an expert, very dependent on a very smart, talented, committed group of people within the team. That's kind of the long and short of how and why.Corey: Let's say that I am taking on the role of an AWS product team, for the sake of argument. I know, keep the cringe down for a second, as far as oh, God, the wince is just inevitable when the idea of me working there ever comes up to anyone. But I have an idea for a service—obviously, it runs containers, and maybe it does some other things as well—going from idea to six-pager to MVP to barely better than MVP day-one launch, and at some point, various things happen to that service. It gets staff with a team, objectives and a roadmap get built, a P&L and budget, and a pricing model and the rest. One the last thing that happens, apparently, is someone picks the worst name off of a list of candidates, slaps it on the product, and ships it off there.At what point does the billing system and figuring out the pricing dimensions for a given service tend to factor in? Is that a last-minute story? Is that almost from the beginning? Where along that journey does, “Oh, by the way, we're building this thing. Maybe we should figure out, I don't know, how to make money from it.” Factor into the conversation?James: There are two parts to that answer. Pretty early on as we're trying to define what that service is going to look like, we're already typically thinking about what are the dimensions that we might charge along. The actual pricing discussions typically happen fairly late, but identifying those dimensions and, sort of, the right way to present it to customers happens pretty early on. The thing that doesn't happen early enough is actually pulling the Commerce Platform team in. but it is something that we're going to work this year to try to get a little bit more in front of.Corey: Have you found historically that you have a pretty good idea of how a service is going to be priced, everything is mostly thought through, a service goes to either private preview or you're discussing about a launch, and then more or less, I don't know, someone like me crops up with a, “Hey, yeah, let's disregard 90% of what the service does because I see a way to misuse the remaining 10% of it as a database.” And you run some mental math and realize, “Huh. We're suddenly giving, like, eight petabytes of storage per customer away for free. Maybe we should guard against that because otherwise, it's rife with misuse.” It used to be that I could find interesting ways to sneak through the cracks of various services—usually in pursuit of a laugh—those are getting relatively hard to come by and invariably a lot more trouble than they're worth. Is that just better comprehensive diligence internally, is that learning from customers, or am I just bad at this?James: No, I mean, what you're describing is almost a variant of the Defender's Dilemma. They are way more ways to abuse something than you can imagine, and so defending against that is pretty challenging. And it's important because, you know, if you turn the economics of something upside down, then it just becomes harder for us to offer it to customers who want to use it legitimately. I would say 90% of that improvement is us learning. We make plenty of mistakes, but I think, you know, one of the things that I've always been impressed by over my time here is how intentional we are trying to learn from those mistakes.And so, I think that's what you're seeing there. And then we try very hard to listen to customers, talk to folks like you, because one of the best ways to tackle anything it smells of the Defender's Dilemma is to harness that collective creativity of a large number of smart people because you really are trying to cover as much ground as possible.Corey: There was a fun joke going around a while back of what is the most expensive environment you can get running on a free tier account before someone from AWS steps in, and I think I got it to something like half a billion dollars in the first month. Now, I haven't actually tested this for reasons that mostly have to do with being relatively poor compared to, you know, being able to buy Guam. And understanding as well the fraud protections built into something like AWS are largely built around defending against getting service usage for free that in some way, shape or form, benefits the attacker. The easy example of that would be mining cryptocurrency, which is just super-economic as long as you use someone else's AWS account to do it. Whereas a lot of my vectors are, “Yeah, ignore all of that. How do I just make the bill artificially high? What can I do to misuse data transfer? And passing a single gigabyte through, how much can I make that per gigabyte cost be?” And, “Oh, circular replication and the Lambda invokes itself pattern,” and basically every bad architectural decision you can possibly make only this time, it's intentional.And that shines some really interesting light on it. And I have to give credit where due, a lot of that didn't come from just me sitting here being sick and twisted nearly so much as it did having seen examples of that type of misconfiguration—by mistake—in a variety of customer accounts, most confidently my own because it turns out that the way I learn things is by screwing them up first.James: Yeah, you've touched on a couple of different things in there. So, you know, maybe the first one is, I typically try to draw a line between fraud and abuse. And fraud is essentially trying to spend somebody else's money to get something for free. And we spent a lot of time trying to shut that down, and we're getting really good at catching it. And then abuse is either intentional or unintentional. There's intentional abuse: You find a chink in our armor and you try to take advantage of it.But much more commonly is unintentional abuse. It's not really abuse, you know. Abuse has very negative connotations, but it's unintentionally setting something up so that you run up a much larger bill than you intended. And we have a number of different internal efforts, and we're working on a bunch more this year, to try to catch those early on because one of my personal goals is to minimize the frequency with which we surprise customers. And the least favorite kind of surprise for customers is a [laugh] large bill. And so, what you're talking about there is, in a sufficiently complex system, there's always going to be weaknesses and ways to get yourself tied up in knots.We're trying both at the service team level, but also within my teams to try to find ways to make it as hard as possible to accidentally do that to yourself and then catch when you do so that we can stop it. And even more on the intentional abuse side of things, if somebody's found a way to do something that's problematic for our services, then you know, that's pretty much on us. But we will often reach out and engage with whoever's doing and try to understand what they're trying to do and why. Because often, somebody's trying to do something legitimate, they've got a problem to solve, they found a creative way to solve it, and it may put strain on the service because it's just not something we designed for, and so we'll try to work with them to use that to feed into either new services, or find a better place for that workload, or just bolster what they're using. And maybe that's something that eventually becomes a fully-fledged feature that we offer the customers. We're always open to learning from our customers. They have found far more creative ways to get really cool things done with our services than we've ever imagined. And that's true today.Corey: I mean, most of my service criticisms come down to the fact that you have more-or-less built a very late model, high performing iPad, and I'm out there complaining about, “What a shitty hammer this thing is, it barely works at all, and then it breaks in my hand. What gives?” I would also challenge something you said a minute ago that the worst day for some customers is to get a giant surprise bill, but [unintelligible 00:13:53] to that is, yeah, but, on some level, that kind of only money; you do have levers on your side to fix those issues. A worse scenario is you have a customer that exhibits fraud-like behavior, they're suddenly using far more resources than they ever did before, so let's go ahead and turn them off or throttle them significantly, and you call them up to tell them you saved them some money, and, “Our Superbowl ad ran. What exactly do you think you're doing?” Because they don't get a second bite at that kind of Apple.So, there's a parallel on both sides of this. And those are just two examples. The world is full of nuances, and at the scale that you folks operate at. The one-in-a-million events happen multiple times a second, the corner cases become common cases, and I'm surprised—to be direct—how little I see you folks dropping the ball.James: Credit to all of the teams. I think our secret sauce, if anything, really does come down to our people. Like, a huge amount of what you see as hopefully relatively consistent, good execution comes down to people behind the scenes making sure. You know, like, some of it is software that we built and made sure it's robust and tested to scale, but there's always an element of people behind the scenes, when you hit those edge cases or something doesn't quite go the way that you planned, making sure that things run smoothly. And that, if anything, is something that I'm immensely proud of and is kind of amazing to watch from the inside.Corey: And, on some level, it's the small errors that are the bigger concern than the big ones. Back a couple years ago, when they announced GP3 volumes at re:Invent, well, great, well spin up a test volume and kick the tires on it for an hour. And I think it was 80 or 100 gigs or whatnot, and the next day in the bill, it showed up as about $5,000. And it was, “Okay, that's not great. Not great at all.” And it turned out that it was a mispricing error by I think a factor of a million.And okay, at least it stood out. But there are scenarios where we were prepared to pay it because, oops, you got one over on us. Good job. That's never been the mindset I've gotten about AWS's philosophy for pricing. The better example that I love because no one took it seriously, was a few years before that when there was a LightSail bug in the billing system, and it made the papers because people suddenly found that for their LightSail instance, they were getting predicted bills of $4 billion.And the way I see it, you really only had to make that work once and then you've made your numbers for the year, so why not? Someone's going to pay for it, probably. But that was such out-of-the-world numbers that no one saw that and ever thought it was anything other than a bug. It's the small pernicious things that creep in. Because the billing system is vast; I had no idea when I started working with AWS bills just how complicated it really was.James: Yeah, I remember both of those, and there's something in there that you touched on that I think is really important. That's something that I realized pretty early on at Amazon, and it's why customer obsession is our flagship leadership principle. It's not because it's love and butterflies and unicorns; customer obsession is key to us because that's how you build a long-term sustainable business is your customers depend on you. And it drives how we think about everything that we do. And in the billing space, small errors, even if there are small errors in the customer's favor, slowly erode that trust.So, we take any kind of error really seriously and we try to figure out how we can make sure that it doesn't happen again. We don't always get that right. As you said, we've built an enormous, super-complex business to growing really quickly, and really quick growth like that always acts as kind of a multiplier on top of complexity. And on the pricing points, we're managing millions of pricing points at the moment.And our tools that we use internally, there's always room for improvement. It's a huge area of focus for us. We're in the beginning of looking at applying things like formal methods to make sure that we can make very hard guarantees about the correctness of some of those. But at the end of the day, people are plugging numbers in and you need as many belts and braces as possible to make sure that you don't make mistakes there.Corey: One of the things that struck me by surprise when I first started getting deep into this space was the fact that the finalized bill was—what does it mean to have this be ‘finalized?' It can hit the Cost and Usage Report in an S3 bucket and it can change retroactively after the month closed periodically. And that's when I started to have an inkling of a few things: Not just the sheer scale and complexity inherent to something like the billing system that touches everything, but the sheer data retention stories where you clearly have to be able to go back and reconstruct a bill from the raw data years ago. And I know what the output of all of those things are in the form of Cost and Usage Reports and the billing data from our client accounts—which is the single largest expense in all of our AWS accounts; we spent thousands and thousands and thousands of dollars a year just on storing all of that data, let alone the processing piece of it—the sheer scale is staggering. I used to wonder why does it take you a day to record me using something to it's showing up in the bill? And the more I learned the more it became a how can you do that in only a day?James: Yes, the scale is actually mind-boggling. I'm pretty sure that the core of our billing system is—I'm reasonably confident it's the largest or one of the largest data processing systems on the planet. I remember pretty early on when I joined Commerce Platform and was still starting to wrap my head around some of these things, Googling the definition of quadrillion because we measured the number of metering events, which is how we record usage in services, on a daily basis in the quadrillions, which is a billion billions. So, it's just an absolutely staggering number. And so, the scale here is just out of this world.That's saying something because it's not like other services across AWS are small in their own right. But I'm still reasonably sure that being one of a handful of services that is kind of at the nexus of AWS and kind of deals with the aggregate of AWS's scale, this is probably one of the biggest systems on the planet. And that shows up in all sorts of places. You start with that input, just the sheer volume of metering events, but that has to produce as an output pretty fine-grained line item detailed information, which ultimately rolls up into the total that a customer will see in their bill. But we have a number of different systems further down the pipeline that try to do things like analyze your usage, make sensible recommendations, look for opportunities to improve your efficiency, give you the ability to slice and dice your data and allocate it out to different parts of your business in whatever way it makes sense for your business. And so, those systems have to deal with anywhere from millions to billions to recently, we were talking about trillions of data points themselves. And so, I was tangentially aware of some of the scale of this, but being in the thick of it having joined the team really just does underscore just how vast the systems are.Corey: I think it's, on some level, more than a little unfortunate that that story isn't being more widely told, more frequently. Because when Commerce Platform has job postings that are available on the website, you read it and it's very vague. It doesn't tend to give hard numbers about a lot of these things, and people who don't play in these waters can easily be forgiven for thinking the way that you folks do your job is you fire up one of those 24 terabyte of RAM instances that—you know, those monstrous things that you folks offer—and what do you do next? Well, Microsoft Excel. We have a special high memory version that we've done some horse-trading with our friends over at Microsoft for.It's, yeah, you're several steps beyond that, at this point. It's a challenging problem that every one of your customers has to deal with, on some level, as well. But we're only dealing with the output of a lot of the processing that you folks are doing first.James: You're exactly right. And a big focus for some of my teams is figuring out how to help customers deal with that output. Because even if you're talking about couple of orders of magnitude reduction, you're still talking about very large numbers there. So, to help customers make sense of that, we have a range of tools that exist, we're investing in.There's another dimension of complexity in the space that I think is one that's also very easy to miss. And I think of it as arbitrary complexity. And it's arbitrary because some of the rules that we have to box within here are driven by legislative changes. As you operate more and more countries around the world, you want to make sure that we're tax compliant, that we help our customers be tax compliant. Those rules evolve pretty rapidly, and Country A may sit next to Country B, but that doesn't mean that they're talking to one another. They've all got their own ideas. They're trying to accomplish r—00:22:47Corey: A company is picking up and relocating from India to Germany. How do we—James: Exactly.Corey: —change that on the AWS side and the rest? And it's, “Hoo boy, have you considered burning it all down and filing an insurance claim to start over?” And, like, there's a lot of complexity buried underneath that that just doesn't rise to the notice of 99% of your customers.James: And the fact that it doesn't rise to the notice is something that we strive for. Like, these shouldn't be things that customers have to worry about. Because it really is about clearing away the things that, as far as possible, you don't want to have to spend time thinking about so that you can focus on the thing that your business does that differentiates you. It's getting rid of that undifferentiated heavy lifting. And there's a ton of that in this space, and if you're blissfully unaware of it, then hopefully that means that we're doing our job.Corey: What I'm, I think, the most surprised about, and I have been for a long time. And please don't take this as an insult to various other folks—engineers, the rest, not just in other parts of AWS but throughout the other industry—but talking to the people who work within Commerce Platform has always been just a fantastic experience. The caliber of people that you have managed to attract and largely retain—we don't own people, they do matriculate out eventually—but the caliber of people that you've retained on your teams has just been out of this world. And at first, I wondered, why are these awesome people working on something as boring and prosaic as billing? And then I started learning a little bit more as I went, and, “Oh, wow. How did they learn all the stuff that they have to hold in their head in tension at once to be able to build things like this?” It's incredibly inspiring just watching the caliber of the people that you've been able to bring in.James: I've been really, really excited joining this team, as I've gotten other folks on the team because there's some super-smart people here. But what's really jumped out to me is how committed the team is. This is, for the most part, a team that has been in the space for many years. Many of them have—we talk about boomerangs, folks who live AWS, go spend some time somewhere else and come back and there's a surprisingly high proportion of folks in Commerce Platform who have spent time somewhere else and then come back because they enjoy the space, they find that challenging, folks are attracted to the ability to have an impact because it is so foundational. But yeah, there's a super-committed core to this team. And I really enjoy working with teams where you've got that because then you really can take the long view and build something great. And I think we have tons of opportunities to do that here.Corey: It sounds ridiculous, but I've reached out to team members before to explain two-cent variances in my bill, and never once have I been confronted with a, “It's two cents. What do you care?” They understand the requirement that these things be accurate, not just, “Eh, take our word for it.” And also, frankly, they understand that two cents on a $20 bill looks a little different on a $20 million bill. So yeah, let us figure out if this is systemic or something I have managed to break.It turns out the Cost and Usage Report processing systems don't love it when there's a cost allocation tag whose name contains an emoji. Who knew? It's the little things in life that just have this fun way of breaking when you least expect it.James: They're also a surprisingly interesting problem. So like, it turns out something as simple as rounding numbers consistently across a distributed system at this scale, is a non-trivial problem. And if you don't, then you do get small seventh or eighth decimal place differences that add up to something that then shows up as a two-cent difference somewhere. And so, there's some really, really interesting problems in the space. And I think the team often takes these kinds of things as a personal challenge. It should be correct, and it's not, so we should go make sure it is correct. The interesting problems abound here, but at the end of the day, it's the kind of thing that any engineering team wants to go and make sure it's correct because they know that it can be.Corey: This episode is sponsored in parts by our friend EnterpriseDB. EnterpriseDB has been powering enterprise applications with PostgreSQL for 15 years. And now EnterpriseDB has you covered wherever you deploy PostgreSQL on premises, private cloud, and they just announced a fully managed service on AWS and Azure called BigAnimal, all one word. Don't leave managing your database to your cloud vendor because they're too busy launching another half dozen manage databases to focus on any one of them that they didn't build themselves. Instead, work with the experts over at EnterpriseDB. They can save you time and money, they can even help you migrate legacy applications, including Oracle, to the cloud.To learn more, try BigAnimal for free. Go to biganimal.com/snark, and tell them Corey sent you.Corey: On the one hand, I love people who just round and estimate—we all do that, let's be clear; I sit there and I back-of-the-envelope everything first. But then I look at some of your pricing pages and I count the digits after the zeros. Like, you're talking about trillionths of a dollar on some of your pricing points. And you add it up in the course of a given hour and it's like, oh, it's $250 a month, most months. And it's you work backwards to way more decimal places of precision than is required, sometimes.I'm also a personal fan of the bill that counts, for example, number of Route 53 zones. Great. And it counts them to four decimal places of precision. Like, I don't even know what half of it Route 53 zone is at this point, let alone something to, like, ah the 1,000th of the zone is going to cause this. It's all an artifact of what the underlying systems are.Can you by any chance shed a little light on what the evolution of those systems has been over a period of time? I have to imagine that anything you built in the early days, 16 years ago or so from the time of this recording when S3 launched to general availability, you probably didn't have to worry about this scope and scale of what you do, now. In fact, I suspect if you tried to funnel this volume through S3 back then, the whole thing would have collapsed under its own weight. What's evolved over the time that you had the billing system there? Because changes come slowly to your environment. And frankly, I appreciate that as a customer. I don't like surprising people in finance.James: Yeah, you're totally right. So, I joined the EC2 team as an engineer myself, some 16 years ago, and the very first thing that I did was our billing integration. And so, my relationship with the Commerce Platform organization—what was the billing team way back when—it goes back over my entire career at AWS. And at the time, the billing team was similar, you know, [unintelligible 00:28:34] eight people. And that was everything. There was none of the scale and complexity; it was all one system.And much like many of our biggest, oldest services—EC2 is very similar, S3 is as well—there's been significant growth over the last decade-and-a-half. A lot of that growth has been rapid, and rapid growth presents its own challenges. And you live with decisions that you make early on that you didn't realize were significant decisions that have pretty deep implications 15 years later. We're still working through some of those; they present their own challenges. Evolving an existing system to keep up with the growth of business and a customer base that's as varied and complex as ours is always challenging.And also harder but I also think more fun than a clean sheet redo at this point. Like, that's a great thought exercise for, well, if we got to do this again today, what would we do now that we've learned so much over the last 15 years? But there's this—I find it personally fascinating challenge with evolving a live system where it's like, “No, no, like, things exist, so how do we go from there to where we want to be next?”Corey: Turn the billing system off for 18 months, rebuild—James: Yeah. [laugh].Corey: The whole thing from first principles. Light it up. I'm sure you'd have a much better billing system, and also not a company left anymore.James: [laugh]. Exactly, exactly. I've always enjoyed that challenge. You know, even prior to AWS, my previous careers have involved similar kinds of constraints where you've got a live system, or you've got an existing—in the one case, it was an existing SDK that was deployed to tens of thousands of customers around the world, and so backwards compatibility was something that I spent the first five years of my career thinking about it way more detail than I think most people do. And it's a very similar mindset. And I enjoy that challenge. I enjoy that: How do I evolve from here to there without breaking customers along the way?And that's something that we take pretty seriously across AWS. I think SimpleDB is the poster child for we never turn things off. But that applies equally to the services that are maybe less visible to customers, and billing is definitely one of them. Like, we don't get to switch stuff off. We don't get to throw things away and start again. It's this constant state of evolution.Corey: So, let's say that I were to find a way to route data through a series of two Managed NAT Gateways and then egress to internet, and the sheer density of the expense of that traffic tears a hole in the fabric of space-time, it goes back 15 years ago, and you can make a single change to how the billing system was built. What would it be? What pisses you off the most about the current constraints that you have to work within or around?James: I think one of the biggest challenges we've got, actually, is the concept of an account. Because an account means half-a-dozen different things. And way back, when it seemed like a great idea, you just needed an account; an account was your customer, and it was the same thing as the boundary that you put all your resources inside. And of course, it's the same thing that you're going to roll all of your usage up and issue a bill against. And that has been one of the areas that's seen the most evolution and probably still has a pretty long way to go.And what's interesting about that is, that's probably something we could have seen coming because we watched the retail business go through, kind of, the same evolution because they started with, well, a customer is a customer is a customer and had to evolve to support the concept of sellers and partners. And then users are different than customers, and you want to log in and that's a different thing. So, we saw that kind of bifurcation of a single entity into a wide range of different related but separate entities, and I think if we'd looked at that, you know, thought out 15 years, then yeah, we could probably have learned something from that. But at the same time, when AWS first kicked off, we had wild ambitions for it, but there was no guarantee that it was going to be the monster that it is today. So, I'm always a little bit reluctant to—like, it's a great thought exercise, but it's easy to end up second-guessing a pretty successful 15 years, so I'm always a little bit careful to walk that line. But I think account is one of the things that we would probably go back and think about a little bit more.Corey: I want to be very clear with this next question that it is intentionally setting up a question I suspect you get a lot. It does not mirror my own thinking on the matter even slightly, but I get a version of it myself all the time. “AWS bills, that sounds boring as hell. Why would you choose to work on such a thing?” Now, I have a laundry list of answers to that aren't nearly as interesting as I suspect yours are going to be. What makes working on this problem space interesting to you?James: There's a bunch of different things. So, first and foremost, the scale that we're talking about here is absolutely mind-blowing. And for any engineer who wants to get stuck into problems that deal with mind-blowingly large volumes of data, incredibly rich dimensions, problems where, honestly, applying techniques like statistical reasoning or machine learning is really the only way to chip away at it, that exists in spades in the space. It's not always immediately obvious, and I think from the outside, it's easy to assume this is actually pretty simple. So, the scale is a huge part of that.Corey: “Oh, petabytes. How quaint.”James: [laugh]. Exactly. Exactly I mean, it's mind-blowing every time I see some of the numbers in various parts of the Commerce Platform space. I talked about quadrillions earlier. Trillions is a pretty common unit of measure.The complexity that I talked about earlier, that's a result of external environments is another one. So, imposed by external entities, whether it's a government or a tax authority somewhere, or a business requirement from customers, or ourselves. I enjoy those as well. Those are different kinds of challenge. They really keep you on your toes.I enjoy thinking of them as an engineering problem, like, how do I get in front of them? And that's something we spend a lot of time doing in Commerce Platform. And when we get it right, customers are just unaware of it. And then the third one is, I personally am always attracted to the opportunity to have an impact. And this is a space where we get to hopefully positively impact every single customer every day. And that, to me is pretty fulfilling.Those are kind of the three standout reasons why I think this is actually a super-exciting space. And I think it's often an underestimated space. I think once folks join the team and sort of start to dig in, I've never heard anybody after they've joined, telling me that what they're doing is boring. Challenging, yes. Is frustrating, sometimes. Hard, absolutely, but boring never comes up.Corey: There's almost no service, other than IAM, that I can think of that impacts every customer simultaneously. And it's easy for me to sit in the cheap seats and say, “Oh, you should change this,” or, “You should change that.” But every change you have is so massive in scale that it's going to break a whole bunch of companies' automations around the bill processing in different ways. You have an entire category of user persona who is used to clicking a certain button in this certain place in the console to generate the report every month, and if that button moves or changes color, or has a different font, suddenly that renders their documentation invalid, and they're scrambling because it's not their core competency—nor should it be—and every change you make is so constricted, just based upon all the different concerns that you've got to be juggling with. How do you get anything done at all? I find that to be one of the most impressive aspects about your organization, bar none.James: Yeah, I'm not going to lie and say that it isn't a challenge, but a lot of it comes down to the talent that we have on the team. We have a super-motivated, super-smart, super-engaged team, and we spend a lot of time figuring out how to make sure that we can keep moving, keep up with the business, keep up with a world that's getting more complicated [laugh] with every passing day. So, you've kind of hit on one of the core challenges there, which is, how do we keep up with all of those different dimensions that are demanding an increasing amount of engineering and new support and new investment from us, while we keep those customers happy?And I think you touched on something else a little bit indirectly there, which is, a lot of our customers are actually pretty technical across AWS. The customers that Commerce Platform supports, are often the least technical of our customers, and so often need the most help understanding why things are the way they are, where the constraints are.Corey: “A big bill from Amazon. How many books did you people buy last month?”—James: [laugh]. Exactly.Corey: —is still very much level of understanding in some cases. And it's not because they're dumb; far from it. It's just, imagine that some people view there as being more to life than understanding the nuances and intricacies of cloud computing. How dare they?James: Exactly. Who would have thought?Corey: So, as you look now over all of your domain, such as it is, what sucks the most? What are you looking to fix as far as impactful changes that the rest of the world might experience? Because I'm not going to accept one of those questions like, “Oh, yeah, on the back-end, we have this storage subsystem for a tertiary thing that just annoys me because it wakes us up once in a whi”—no, no, I want something customer-facing. What's the painful thing you're looking at fixing next?James: I don't like surprising customers. And free tier is, sort of, one of those buckets of surprises, but there are others. Another one that's pretty squarely in my sights is, whether we like it or not, customer accounts get compromised. Usually, it's a password got reused somewhere or was accidentally committed into a GitHub repository somewhere.And we have pretty established, pretty effective mechanisms for finding all of those, we'll scan for passwords and credentials, and alert customers to those, and help them correct that pretty quickly. We're also actually pretty good at detecting when an account does start to do something that suggests that it's been compromised. Usually, the first thing that a compromised account starts to do is cryptocurrency mining. We're pretty quick to catch those; we catch those within a matter of hours, much faster most days.What we haven't really cracked and where I'm focused at the moment is getting back to the customer in a way that's effective. And by that I mean specifically, we detect an account compromised super-quickly, we reach out automatically. And so, you know, a customer has got some kind of contact from us usually within a couple of hours. It's not having the effect that we need it to. Customers are still being surprised a month later by a large bill. And so, we're digging into how much of that is because they never saw the contact, they didn't know what to do with the contact.Corey: It got buried with all the other, “Hey, we saw you spun up an S3 bucket. Have you heard of what S3 is?” Again, that's all valuable, but you have 300-some-odd services. If you start doing that for every service, you're going to hit mail sending limits for Gmail.James: Exactly. It's not just enough that we detect those and notify customers; we have to reduce the size of the surprise. It's one thing to spend 100 bucks a month on average, and then suddenly find that your spend has jumped $250 because you reused the password somewhere and somebody got ahold of it and it's cryptocurrency-mining your account. It's a whole different ballgame to spend 100 bucks a month and then at the end of the month discover that your bill is suddenly $2,000 or $20,000. And so, that's something that I really wanted to make some progress on this year. Corey: I've really enjoyed our conversation. If people want to learn more about how you view these things, how you're approaching some of these problems, or potentially are just the right kind of warped to consider joining up, where's the best place for them to go?James: They should drop me an email at jamesg@amazon.com. That is the most direct way to get hold of me, and I promise I will get back to you. I try to stay on top of my email as much as possible. But that will come straight to me, and I'm always happy to talk to folks about the space, talk to folks about opportunities in this team, opportunities across AWS, or just hear what's not working, make sure that it's something that we're aware of and looking at.Corey: Throughout Amazon, but particularly within Commerce Platform, I've always appreciated the response of, whenever I report something, no matter how ridiculous it is—and I assure you there's an awful lot of ridiculousness in my bug reports—the response has always been the same: “Tell me more. Help me understand what it is you're trying to achieve—even if it is ridiculous—so we can look at this and see what is actually going on.” Every Amazonian team has been great about that or you're not at Amazon very long, but you folks have taken that to an otherworldly level. I just want to thank you for doing that.James: I appreciate you for calling that out. We try, you know, we really do. We take listening to our customers very seriously because, at the end of the day, that's what makes us better, and that's how we make sure we're in it for the long haul.Corey: Thanks once again for being so generous with your time. I really appreciate it.James: Yeah, thanks for having me on. I've enjoyed it.Corey: James Greenfield, VP of Commerce Platform at AWS. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice along with an angry comment—possibly on YouTube as well—about how you aren't actually giving this five-stars at all; you have taken three trillions of a star off of the rating.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.

Alan interviews Cameron and Nadene McIntyre. The McIntyres loved high-intensity exercise, but not the soreness and strains afterwards. Finding muscle rubs didn't work well and were unpleasant to use - they invented the solution: Punch Gunk. Today, Punch Gunk provides a natural pain reliever for athletes everywhere. Make sure to subscribe to the podcast at Apple Podcasts, or wherever you get your podcasts, so you won't miss a single episode. Website: www.PunchGunk.com  

Tu aimerais savoir tirer à l'arc comme un Indien au triple galop sur son cheval ? Il va falloir beaucoup t'entraîner ! En attendant, Julien te raconte l'histoire d'une invention qui remonte à la préhistoire… Les lances des chasseurs préhistoriques L'arc le plus ancien qu'on ait retrouvé date d'il y a 14 000 ans. Mais cette arme existait probablement avant, car on a retrouvé des petites pointes de flèches en silex taillées aux alentours de 60 000 ans avant J.-C. On appelle cette période l'âge de pierre. À cette époque, les humains sont nomades : ils ne vivent pas toujours au même endroit, ils se déplacent selon leurs besoins. Pour se nourrir, ils cueillent des baies, des fruits et ils chassent en se servant d'une lance sur laquelle ils ont fixé une pointe avec de la résine de pin. Les lances préhistoriques sont pratiques pour repousser un animal, mais pour tuer le gibier, il faut projeter la lance et cela demande beaucoup de force. Et, surtout, il faut être très près de l'animal, et c'est souvent assez dangereux ! L'humain invente alors le propulseur. Le propulseur est un bâton droit, qui se termine par un crochet. On cale la lance sur ce crochet, le propulseur permet de lancer son arme plus loin, plus vite et plus fort. Le chasseur est plus efficace, mais il est encore assez près de l'animal. Un bout de bois, une corde et des flèches… Les chasseurs préhistoriques vont encore trouver une autre technique pour envoyer leur projectile beaucoup plus loin. Ils commencent à fabriquer des lances plus fines, plus petites, plus faciles à lancer.  Pour les propulser plus fort, ils ont l'idée d'utiliser un bout de bois souple, légèrement courbé, et de tendre une corde entre les deux extrémités de ce bout de bois. La flèche, placée sur la corde que l'on tend puis qu'on relâche, part à des dizaines de mètres, à une vitesse incroyable, et se plante fort dans la cible. C'est une arme plus mortelle pour le gibier, et moins dangereuse pour le chasseur ! Petit à petit, l'arc devient l'arme préférée des humains préhistoriques… L'arc, une arme pour les soldats Au fil des siècles, les techniques de fabrication évoluent. On utilise différents types de bois, on teste des arcs plus ou moins grands, de formes un peu différentes. Les pointes de flèches sont fabriquées en métal, ce qui les rend plus résistantes et plus dangereuses. L'arc devient une arme pour les soldats. Il est utilisé par tous les peuples de l'Antiquité, sur tous les continents. Au Moyen Âge, les archers sont essentiels pour défendre les châteaux forts. Mais avec l'invention des canons et des pistolets, les archers finissent par disparaître des champs de bataille.  Au 18e siècle, sur le continent européen, le tir à l'arc devient alors un jeu… ou un sport de précision ! 

This episode of the Getting Smart Podcast is sponsored by What If? Also, if you're interested in submitting your teacher pledge, find out more here and send a recording to Mason@GettingSmart.com. On this episode of the Getting Smart Podcast, Shawnee Caruthers is joined by a few special guests from Project Invent, design thinking and invention programs to empower every student as an innovator. Jordan Mareno is Partnerships and Recruitment Manager at Project Invent, Alexis Lopez is an educator and fellow for Project Invent and lastly, Angel, a student who recently participated in a Project Invent cohort! Links:  Clubhouse network Project Invent Invention Opportunity Angel's LinkedIn Magis Athletics (Angel's T-shirt concept) Teacher Pledge

About TomaszTomasz is a Frontend Engineer at Stedi, Co-Founder/Head of React at Cloudash, egghead.io instructor with over 200 lessons published, a tech speaker, an AWS Community Hero and a lifelong learner.Links Referenced: Cloudash: https://cloudash.dev/ Twitter: https://twitter.com/tlakomy 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 our friends at ChaosSearch. You could run Elasticsearch or Elastic Cloud—or OpenSearch as they're calling it now—or a self-hosted ELK stack. But why? ChaosSearch gives you the same API you've come to know and tolerate, along with unlimited data retention and no data movement. Just throw your data into S3 and proceed from there as you would expect. This is great for IT operations folks, for app performance monitoring, cybersecurity. If you're using Elasticsearch, consider not running Elasticsearch. They're also available now in the AWS marketplace if you'd prefer not to go direct and have half of whatever you pay them count towards your EDB commitment. Discover what companies like Equifax, Armor Security, and Blackboard already have. To learn more, visit chaossearch.io and tell them I sent you just so you can see them facepalm, yet again.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. It's always a pleasure to talk to people who ask the bold questions. One of those great bold questions is, what if CloudWatch's web page didn't suck? It's a good question. It's one I ask myself all the time.And then I stumbled across a product that wound up solving this for me, and I'm a happy customer. To be clear, they're not sponsoring anything that I do, nor should they. It's one of those bootstrapped, exciting software projects called Cloudash. Today, I'm joined by the Head of React at Cloudash, Tomasz Łakomy. Tomasz, thank you for joining me.Tomasz: It's a pleasure to be here.Corey: So, where did this entire idea come from? Because I sit and I get upset every time I have to go into the CloudWatch dashboard because first, something's broken. In an ideal scenario, I don't have to care about monitoring or observability or anything like that. But then it's quickly overshadowed by the fact that this interface is terrible. And the reason I know it's terrible is that every time I'm in there, I feel dumb.My belief is—for the longest time, I thought that was a problem with me. But no, invariably, when you wind up working with something and consistently finding it a bad—you don't know enough to solve for it, it's not you. It is, in fact, the signs of a poorly designed experience, start to finish. “You should be smarter to use this tool,” is very rarely correct. And there are a bunch of observability tools and monitoring tools for serverless things that have made sense over the years and made this easier, but one of the most—and please don't take this the wrong way—stripped down, bare essentials of just the facts, style of presentation is Cloudash. It's why I continue to pay for it every month with a smile on my face. How did you get here from there?Tomasz: Yeah that's a good question. I would say that. Cloudash was born out of desire for simple things to be simple. So, as you mentioned, Cloudash is basically the monitoring and troubleshooting tool for serverless applications, made for serverless developers because I am very much into serverless space, as is Maciej Winnicki, who is the another half of Cloudash team. And, you know, the whole premise of serverless was things are going to be simpler, right?So, you know, you have a bunch of code, you're going to dump it into a Lambda function, and that's it. You don't have to care about servers, you don't have to care about, you know, provisioning stuff, you don't have to care about maintenance, and so on. And that is not exactly true because why PagerDuty still continues to be [unintelligible 00:02:56] business even in serverless spaces. So, you will get paged every now and then. The problem is—what we kind of found is once you have an incident—you know, PagerDuty always tends to call it in the middle of the night; it's never, like, 11 a.m. during the workday; it's always the middle of the night.Corey: And no one's ever happy when it calls them either. It's, “Ah, hell.” Whatever it rings, it's yeah, the original Call of Duty. PagerDuty hooked up to Nagios. I am old enough to remember those days.Tomasz: [unintelligible 00:03:24] then business, like, imagine paying for something that's going to wake you up in the middle of the night. It doesn't make sense. In any case—Corey: “So, why do you pay for that product? Because it's really going to piss me off.” “Okay, well… does that sound like a good business to you? Well, AWS seems to think so. No one's happy working with that stuff.” “Fair. Fair enough.”Tomasz: So, in any case, like we've established an [unintelligible 00:03:43]. So you wake up, you go to AWS console because you saw a notification that this-and-this API has, you know, this threshold was above it, something was above the threshold. And then you go to the CloudWatch console. And then you see, okay, those are the logs, those are the metrics. I'm going to copy this request ID. I'm going to go over here. I'm going to go to X-Ray.And again, it's 3 a.m. so you don't exactly remember what do you investigate; you have, like, ten minutes. And this is a problem. Like, we've kind of identified that it's not simple to do these kinds of things, too—it's not simple to open something and have an understanding, okay, what exactly is happening in my serverless app at this very moment? Like, what's going on?So, we've built that. So, Cloudash is a desktop app; it lives on your machine, which is a single pane of glass. It's a single pane of glass view into your serverless system. So, if you are using CloudFormation in order to provision something, when you open Cloudash, you're going to see, you know, all of the metrics, all the Lambda functions, all of the API Gateways that you have provisioned. As of yesterday, API Gateway is no longer cool because they did launch the direct integration, so you have—you can call Lambda functions with [crosstalk 00:04:57]—Corey: Yeah, it's the one they released, and then rolled back and somehow never said a word—because that's an AWS messaging story, and then some—right around re:Invent last year. And another quarter goes by and out it goes.Tomasz: It's out yesterday.Corey: Yeah, it's terrific. I love that thing. The only downside to it is, ah, you have to use one of their—you have to use their domain; no custom domain support. Really? Well, you can hook up CloudFront to it, but the pricing model that way makes it more expensive than API Gateway.Okay, so I could use Cloudflare in front of it, and then it becomes free, so I bought a domain just for that purpose. That's right, my serverl—my direct Lambda URLs now live behind the glorious domain of cheapass.cloud because of course. They are. It's a day-one product from AWS, so of course, it's not feature-complete.But one of the things I like about the serverless model, and it's also a challenge when it comes to troubleshooting stuff is that it's very much set it and forget it style because serverless in many cases, at least the way that I tend to use it, is back-office stuff, its back-end things, it's processing on things that are not necessarily always direct front and center. So, these things can run on their own for years until finally, you find a strange bug in a new use case, or you want to go and change something. And then it's how the hell did this ever work? And it's still working, kind of, but what fool built this? Of course, it was me; it's always me.But what happened here? You're basically excavating your own legacy code, trying to understand what's going on. And so, you're already upset then. Cloudash makes this easier to find the things, to navigate through a whole bunch of different accounts. And there are a bunch of decisions that you made while building the app that are so clearly correct, that I get actively annoyed when others don't because oh, it looks at your AWS configuration file in your user home directory. Great, awesome. It's a desktop app, but it still consults that file. Yay, integration between ClickOps and the terminal. Wonderful.But ah, use SSO for a lot of stuff, so that's going to fix your little red wagon. I click on that app, and suddenly, bam, a browser opens asking me to log in and authenticate, allow the request. It works, and then suddenly, it goes back to doing exactly what you'd expect it to. It's really nice. The affordances behind this are glorious.Tomasz: Like I said, one of our kind of design goals when building Cloudash was to make simple things simple again. The whole purpose is to make sure that you can get into the root cause of an issue within, like, five minutes, if not less. And this is kind of the app that you're going to tend to open whenever that—as I said, because some of the systems can be around for, like, ages, literally without any incident whatsoever, then the data is going to change because somebody [unintelligible 00:07:30] got that the year is 2020 and off you go, we have an incident.But what's important about Cloudash is that we don't send logs anywhere. And that's kind of important because you don't pay for [PUT 00:07:42] metric API because we are not sending those logs anywhere. If you install Cloudash on your machine, we are not going to get your logs from the last ten years, put them in into a system, charge you for that, just so you are able to, you know, find out what happened in this particular hour, like, two weeks ago. We genuinely don't care about your logs; we have enough of our own logs at work to, you know, to analyze, to investigate, and so on; we are not storing them anywhere.In fact, you know, whatever happens on your machine stays on the machine. And that is partially why this is a desktop app. Because we don't want to handle your credentials. We don't—absolutely, we don't want you to give us any of your credentials or access keys, you know, whatever. We don't want that.So, that is why you install Cloudash, it's going to run on your machine, it's going to use your local credentials. So, it's… effectively, you could say that this is a much more streamlined and much more laser-focused browser or like, an eye into AWS systems, which live on the serverless side of things.Corey: I got to deal with it in a bit of an interesting way, recently. I have a detector in my company's production AWS org, to detect when ClickOps is afoot. Now, I'm a big proponent of ClickOps, but I also want to know what's going on, so I have a whole thing that [runs detects 00:09:04] when people are doing things in the console versus via API. And it alerts on certain subsets of them. I had to build a special case for the user agent string coming out of Cloudash because no, no, this is an app, this is not technically ClickOps—it is also read-only, which is neither here nor there, to my understanding.But it was, “Oh yeah, this is effectively an Electron app.” It just wraps, effectively, a browser and presents that as an application. And cool. From my perspective, that's an implementation detail. It feels like a native app—because it is—and I can suddenly see the things I care about in a way that is much more straightforward without having to have four different browser tabs open where, okay, here's the CloudTrail log for this thing, here's the metrics next to it. Oh, those are two separate windows already, and so on and so forth. It just makes hunting down to the obnoxious problems so much nicer.It's also, you're one of those rare products where if I don't use it for a month, I don't get the bill at the end of the month and think, “Ooh, that's going to—did I waste the money?” It's no, nice. I had a whole month where I didn't have to mess with this. It's great.Tomasz: Exactly. I feel like, you know, it's one of those systems where, as you said, we send you an email at the end of every month that we're going to charge you X dollars for the month—by the way, we have fixed pricing and then you can cancel anytime—and it's like one of those things that, you know, I didn't have to open this up for a month. This is awesome because I didn't have any incidents. But I know whenever again, PagerDuty is going to decide, “Hey, dude, wake up. You know, if slept for three hours. That is definitely long enough,” then you know that; you know, this app is there and you can use that.We very much care about, you know, building this stuff, not only for our customers, but we also use that on a daily basis. In fact, I… every single time that I have to—I want to investigate something in, like, our serverless systems at Stedi because everything that we do at work, at Stedi, since this incident serverless paradigm. So, I tend to open Cloudash, like, 95% of the time whenever I want to investigate something. And whenever I am not able to do something in Cloudash, this goes, like, straight to the top of our, you know, issue lists or backlog or whatever you want to call it. Because we want to make this product, not only awesome, you know, for customers to buy a [unintelligible 00:11:22] or whatever, but we also want to be able to use that on a daily basis.And so far, I think we've kind of succeeded. But then again, we have quite a long way to go because we have more ideas, than we have the time, definitely, so we have to kind of prioritize what exactly we're going to build. So, [unintelligible 00:11:39] integrations with alarms. So, for instance, we want to be able to see the alarms directly in the Cloudash UI. Secondly, integration with logs insights, and many other ideas. I could probably talk for hours about what we want to build.Corey: I also want to point out that this is still your side gig. You are by day a front-end engineer over at Stedi, which has a borderline disturbing number of engineers with side gigs, generally in the serverless space, doing interesting things like this. Dynobase is another example, a DynamoDB desktop client; very similar in some respects. I pay for that too. Honestly, for a company in Stedi's space, which is designed as basically a giant API for deep, large enterprise business stuff, there's an awful lot of stuff for small-scale coming out of that.Like, I wind up throwing a disturbing amount of money in the general direction of Stedi for not being their customer. But there's something about the culture that you folks have built over there that's just phenomenal.Tomasz: Yeah. For the record, you know, having a side gig is another part of interview process at Stedi. You don't have to have [laugh] a side project, but yeah, you're absolutely right, you know, the amount of kind of side projects, and you know, some of those are monetized, as you mentioned, you know, Cloudash and Dynobase and others. Some of those—because for instance, you talked to Aidan, I think a couple of weeks ago about his shenanigans, whenever you know, AWS is going to announce something he gets in and try to [unintelligible 00:13:06] this in the most amusing ways possible. Yeah, I mean, I could probably talk for ages about why Stedi is by far the best company I've ever worked at, but I'm going to say this: that this is the most talented group of people I've ever met, and myself, honestly.And, you know, the fact that I think we are the second largest, kind of, group of AWS experts outside of AWS because the density of AWS Heroes, or ex-AWS employees, or people who have been doing cloud stuff for years, is frankly, massive, I tend to learn something new about cloud every single day. And not only because of the Last Week in AWS but also from our Slack.Corey: This episode is sponsored by our friends at Oracle Cloud. Counting the pennies, but still dreaming of deploying apps instead of “Hello, World” demos? Allow me to introduce you to Oracle's Always Free tier. It provides over 20 free services and infrastructure, networking, databases, observability, management, and security. And—let me be clear here—it's actually free. There's no surprise billing until you intentionally and proactively upgrade your account. This means you can provision a virtual machine instance or spin up an autonomous database that manages itself, all while gaining the networking, load balancing, and storage resources that somehow never quite make it into most free tiers needed to support the application that you want to build. With Always Free, you can do things like run small-scale applications or do proof-of-concept testing without spending a dime. You know that I always like to put asterisks next to the word free? This is actually free, no asterisk. Start now. Visit snark.cloud/oci-free that's snark.cloud/oci-free.Corey: There's something to be said for having colleagues that you learn from. I have never enjoyed environments where I did not actively feel like the dumbest person in the room. That's why I love what I do now. I inherently am. I have to talk about so many different things, that whenever I talk to a subject matter expert, it is a certainty that they know more about the thing than I do, with the admitted and depressing exception of course of the AWS bill because it turns out the reason I had to start becoming the expert in that was because there weren't any. And here we are now.I want to talk as well about some of—your interaction outside of work with AWS. For example, you've been an Egghead instructor for a while with over 200 lessons that you published. You're an AWS Community Hero, which means you have the notable distinction of volunteering for a for-profit company—good work—no, the community is very important. It's helping each other make sense of the nonsense coming out of there. You've been involved within the ecosystem for a very long time. What is it about, I guess—the thing I'm wondering about myself sometimes—what is it about the AWS universe that drew you in, and what keeps you here?Tomasz: So, give you some context, I've started, you know, learning about the cloud and AWS back in early-2019. So, fun fact: Maciej Winnicki—again, the co-founder of Cloudash—was my manager at the time. So, we were—I mean, the company I used to work for at the time, OLX Group, we are in the middle of cloud transformation, so to speak. So, going from, you know, on-premises to AWS. And I was, you know, hired as a senior front-end engineer doing, you know, all kinds of front-end stuff, but I wanted to grow, I wanted to learn more.So, the idea was, okay, maybe you can get AWS Certified because, you know, it's one of those corporate goals that you have to have something to put that checkbox next to it. So, you know, getting certified, there you go, you have a checkbox. And off you go. So, I started, you know, diving in, and I saw this whole ocean of things that, you know, I was not entirely aware of. To be fair, at the time I knew about this S3, I knew that you can put a file in an S3 bucket and then you can access it from the internet. This is, like, the [unintelligible 00:16:02] idea of my AWS experiences.Corey: Ideally, intentionally, but one wonders sometimes.Tomasz: Yeah, exactly. That is why you always put stuff as public, right? Because you didn't have to worry about who [unintelligible 00:16:12] [laugh] public [unintelligible 00:16:15]. No, I'm kidding, of course. But still, I think what's [unintelligible 00:16:20] to AWS is what—because it is this endless ocean of things to learn and things to play with, and, you know, things to teach.I do enjoy teaching. As you said, I have quite a lot of, you know, content, videos, blog posts, conference talks, and a bunch of other stuff, and I do that for two reasons. You know, first of all, I tend to learn the best by teaching, so it helps me very much, kind of like, solidify my own knowledge. Whenever I record—like, I have two courses about CDK, you know, when I was recording those, I definitely—that kind of solidify my, you know, ideas about CDK, I get to play with all those technologies.And secondly, you know, it's helpful for others. And, you know, people have opinions about certificates, and so on and so forth, but I think that for somebody who's trying to get into either the tech industry or, you know, cloud stuff in general, being certified helps massively. And I've heard stories about people who are basically managed to double or triple their salaries by going into tech, you know, with some of those certificates. That is why I strongly believe, by the way, that those certificates should be free. Like, if you can pass the exam, you shouldn't have to worry about this $150 of the fee.Corey: I wrote a blog post a while back, “The Dumbest Dollars a Cloud Provider Can Make,” and it's charging for training and certification because if someone's going to invest that kind of time in learning your platform, you're going to try and make $150 bucks off them? Which in some cases, is going to put people off from even beginning that process. “What cloud provider I'm not going to build a project on?” Obviously, the one I know how to work with and have a familiarity with, in almost every case. And the things you learn in your spare time as an independent learner when you get a job, you tend to think about your work the same way. It matters. It's an early on-ramp that pays off down the road and the term of years.I used to be very anti-cert personally because it felt like I was jumping through hoops, and paying, in some cases, for the privilege. I had a CCNA for a while from Cisco. There were a couple of smaller companies, SaltStack, for example, that I got various certifications from at different times. And that was sort of cheating because I helped write the software, but that's neither here nor there. It's the—and I do have a standing AWS cert that I get a different one every time—mine is about to expire—because it gets me access to lounges at physical events, which is the dumbest of all reasons to get certs, but here you go. I view it as the $150 lounge pass with a really weird entrance questionnaire.But in my case it certs don't add anything to what I do. I am not the common case. I am not early in my career. Because as you progress through your career, things—there needs to be a piece of paper that says you know things, and early on degree or certifications are great at that. In the time it becomes your own list of experience on your resume or CV or LinkedIn or God knows what. Polywork if you're doing it the right way these days.And it shows a history of projects that are similar in scope and scale and impact to the kinds of problems that your prospective employer is going to have to solve themselves. Because the best answer to hear—especially in the ops world—when there's a problem is, “Oh, I've seen this before. Here's how you fix it.” As opposed to, “Well, I don't know. Let me do some research.”There's value to that. And I don't begrudge anyone getting certs… to a point. At least that's where I sit on it. At some point when you have 25 certs, it's when you actually do any work? Because it's taking the tests and learning all of these things, which in many ways does boil down to trivia, it stands in counterbalance to a lot of these things.Tomasz: Yeah. I mean, I definitely, totally agree. I remember, you know, going from zero to—maybe not Hero; I'm not talking about AWS Hero—but going from zero to be certified, there was the Solutions Architect Associate. I think it took me, like, 200 hours. I am not the, you know, the brightest, you know, the sharpest tool in the shed, so it probably took me, kind of, somewhat more.I think it's doable in, like, 100 hours, but I tend to over-prepare for stuff, so I didn't actually take the actual exam until I was able to pass the sample exams with, like, 90% pass, just to be extra sure that I'm actually going to pass it. But still, I think that, you know, at some point, you probably should focus on, you know, getting into the actual stuff because I hold two certificates, you know, one of those is going to expire, and I'm not entirely sure if I want to go through the process again. But still, if AWS were to introduce, like, a serverless specialty exam, I would be more than happy to have that. I genuinely enjoy, kind of, serverless, and you know, the fact that I would be able to solidify my knowledge, I have this kind of established path of the things that I should learn about in order to get this particular certificate, I think this could be interesting. But I am not probably going to chase all the 12 certificates.Maybe if AWS IQ was available in Poland, maybe that would change because I do know that with IQ, those certs do matter. But as of [unintelligible 00:21:26] now, I'm quite happy with my certs that I have right now.Corey: Part of the problem, too, is the more you work with these things, the harder it becomes to pass the exams, which sounds weird and counterintuitive, but let me use myself as an example. When I got the cloud practitioner cert, which I believe has lapsed since then, and I got one of the new associate-level betas—I'll keep moving up the stack until I start failing exams. But I got a question wrong on the cloud practitioner because it was, “How long does it take to restore an RDS database from a snapshot backup?” And I gave the honest answer of what I've seen rather than what it says in the book, and that honest answer can be measured in days or hours. Yeah.And no, that's not the correct answer. Yeah, but it is the real one. Similarly, a lot of the questions get around trivia, syntax of which of these is the correct argument, and which ones did we make up? It's, I can explain in some level of detail, virtually every one of AWS has 300 some-odd services to you. Ask me about any of them, I could tell you what it is, how it works, how it's supposed to work and make a dumb joke about it. Fine, whatever.You'll forgive me if I went down that path, instead of memorizing what is the actual syntax of this YAML construct inside of a CloudFormation template? Yeah, I can get the answer to that question in the real world, with about ten seconds of Googling and we move on. That's the way most of us learn. It's not cramming trivia into our heads. There's something broken about the way that we do certifications, and tech interviews in many cases as well.I look back at some of the questions I used to ask people for