newline

In this special episode of the newline podcast, Nate is interviewed by Matt Harrison, founder of Metasnake, and author of his own course Effective Book Authoring. Over the hour, Matt interviews me asking about programming book authoring - how to plan it, how to write it, how market it when you're done.I share my best advice for organizing the process, building your audience, and how to enjoy it along the way. If you're interested in writing a programming book or course, then this episode is for you. Writing a programming course isn't easy. But I've done it enough times now, that hopefully the tips inside will be helpful to you. In this episode we cover:What was your process like to make a course?How does promotion work when creating a programming course?What tools did you use to write your book?What promotions did you do for your book?What advice would you give to yourself before writing your book?How much money have you made?

Today we're talking with Redux js maintainer Mark Erikson. Mark has been maintaining the Redux library for about five years, and has written an amazing amount of documentation and guide material. Redux is used in the majority of React apps, but folks have recently been questioning: is Redux still a tool I should use in 2020? It depends. We tease apart all of the different use-cases for redux: data-fetching, caching state, avoiding prop drilling and compare it the other tools in the ecosystem: apollo, mobx, recoil, hooks, and others. In this wide-ranging conversation we cover the history of Redux, tooling you can use to make your Redux code cleaner, and future plans. Also, Nate struggles to pronounce Redux. We hope you enjoy listening as much as we enjoyed talking with Mark.

Resources:cassie.codestwitter.com/cassiecodesAmelia's TwitterNate's TwitterKurt Vonnegut and Narrative ArcsSara Soueidan's Post on SVG Filters: The Crash CourseWelcome to the newline podcast. Our show is a conversation with experienced software engineers where we discuss new technology, career advice, and help you be amazing at work.I'm Nate Murray and I'm Amelia Wattenberger and today we're talking with creative coder Cassie Evans.In this episode we talk about something often neglected in web design today: how to bring whimsy and joy to your usersIn our chat we talk about how the old web had entry points to programming and where we might find find that today.And open with a story about how she, as a child, sold animated cursors for donuts, which felt like magic - and how even today snippets of code feel like magic spells.We loved our conversation with Cassie, and think you will too, let's dig in!Cassie Evans PodcastAmelia: [00:00:00] Welcome to the newline Podcast. Nate: [00:00:08] Our show is a conversation with experienced software engineers, where we discuss new technology, career advice and help you be amazing at work. I'm Nate. Amelia: [00:00:17] And I'm Amelia Wattenberger. Today, we're talking with creative coder, Cassie Evans. In this episode, we talk about something often neglected in web design today, how to bring whimsy and joy to your users. In our chat, we talk about how the old web had entry points to programming and where we might find that today. Nate: [00:00:35] We open with a story about how Cassie as a child, sold animated cursors for donuts, which felt like magic. And how even today, snippets of code still feel like magic spells. We loved our conversation with Cassie and we think you will too. Let's dig in. Cassie: [00:00:53] We're not Nate: [00:00:54] live and so we just it to be fun. One of things is I really love your talks and you talked about how the web needs more whimsy. I just love that so much. In one of your talks, you mentioned that you sold neopets pages for donuts. Cassie: [00:01:11] Yes. Nate: [00:01:11] Like when you were a child. Can you tell me more about that? For context, I think you and I grew up with some of the similar early web stuff. For example, when I was younger, I once got on the Internet for hours and then my parents were furious, because my dad had gotten an accident at work and his boss was supposed to call. I'd been tying up the Internet, because I was on dial-up for hours. Yeah, I just love the old classic web style, like Myspace and neopets. We can get into that some, but can you tell me about how you sold neopets pages for donuts? Cassie: [00:01:40] Yes, definitely. Yeah, firstly you mentioned dial-up. I missed that so much. It's so close to my heart, because I remember we had one computer at home, that was our home computer and I was only allowed to use it for educational things for a lot of times. I used to wait until my parents were asleep and then I'd creep downstairs with blankets and I'd have to wrap the whole computer up in the blanket, so that it wouldn't make the noises, so that I could dial-up to the Internet. I just sit there clutching it to my chest, trying to dampen down the noises, so they wouldn't wake up. Why Nate: [00:02:15] were modems so loud, right? Cassie: [00:02:17] So loud. Nate: [00:02:18] Yeah. Cassie: [00:02:21] Even that noise now gives me anxiety, because it sounds like being downstairs, terrified that my parents are going to wake up at any moment. I love that. Yeah, the donuts. I didn't have money for the tuck shop when I was younger. I got school dinners. I didn't have packed lunch boxes and they weren't really into giving us sugary snacks. They were quite healthy. I got quite jealous about all of the other kids having donuts from the tuck shops. Around that time, everyone started making Myspace profiles and neopets pet pages. My one was really good and lots of people asked me whether I could make them sparkly cursors and stuff. I started up a little side hustle and swapped sparkly cursors for donuts. It was excellent. Amelia: [00:03:11] What is the deal? Is it one cursor for one donut? Cassie: [00:03:15] Yeah, I think it was something like that; a cursor for a donut. This Nate: [00:03:19] is amazing. I don't actually understand how this would work. How much programming was it? Were you finding GIFs? I'm interested in particularly one, for the entrepreneurship side, two, because it's on-brand that you're adding sparkles. Then three, is the learning programming aspect. I love this idea, for example, that some of the best ways to learn are just when you're self-motivated and you're just trying to do stuff. I learned how to program, because I was tweaking web pages this similar way and I worked my way down. I'm interested. I didn't actually use neopets necessarily, but what were these cursors and how did that work for as much as you remember? Cassie: [00:03:53] As much as I remember. I think it was very much accidental. I don't think that I realized that I was coding at the time. I didn't really have much of an awareness of what coding was. I used to play The Sims me other early games as well and they had cheat codes that you could type in. I saw it as the same thing. It was Internet cheat codes that you went to some websites and they had pictures of different sparkly cursors, or different backgrounds, or different CSS effects and you just copied a cheat code and then you put that cheat code onto your – and I didn't really know that that's what the building blocks of the web were. I didn't understand that at the time. I thought that they were a little magical snippets that you just – I mean, they still are. Nate: [00:04:42] Right, they still are. They still are Cassie: [00:04:43] magical snippets, aren't they? I still feel like that nowadays. Some new CSS comes out and I'm just like, “Wow, another magical snippet. Amelia: [00:04:52] This is amazing.” They keep making them. Cassie: [00:04:54] Yeah. Nate: [00:04:56] I learned some early programming, we would play these old games, they were called MUDs. You'd Telnet in. It's before SSH, you Telnet. It's like SSH, but insecure. You Telnet into these servers and play these text games, where you're go to the sword shop or whatever and you buy a sword. Then I remember that what we would do is we were like, “Oh, we could host our own server.” It's the same thing. We didn't know we were We were just copying and pasting these codes, make our own server and then we're like, “Oh, we can give ourselves our own items.” We're copy this snippet and then you realize now you have these God-like powers of playing this game that you enjoy and then realize like, “Oh, shoot. What else could I do with this power?” That was actually one of my entry points to programming too. I think that's really special. One of the things that you've talked about too is well, I don't know. What are some of these entry points that people have now? What could we do to give this, serendipitous entry point into coding for kids today? Cassie: [00:05:46] It's really difficult, because I've looked around and I haven't found anything that has that same accidentally educational aspect to it. There's some really amazing things that have the same sense of community, because neopets for me and Myspace to a degree had this community aspect, where there were lots of other young kids who were all hacking around and changing things and you learnt things from each other. I think that we definitely got that in platforms like CodePen and Glitch. They're really great, because they lower the barrier to entry. They abstract away all of the fiddly setup and build tools and all of that stuff and they allow people to just jump in and start making things and remix things that other people have made and fork things that other people have made. I think that's really great, but I don't think we already have any of those accidentally educational things around anymore, which is a shame. People have to be a lot more intentional. They have to want to learn and know what they're there for in order to start off. I Amelia: [00:06:58] also think about this with cars. I think it's a little bit related. When I first started dating my husband, he had a – it was 69 Mercury Cougar, a really old car. He could work on it, because there's no computer, you can understand what the parts are pretty easily. You can just look at them and be like, okay, this turns and it turns this other thing. I think the Internet today is so much more complicated. The bar for what's cool on the web is so much higher that when we were kids and we made a sparkly cursor, even our parents would be like, “Oh, wow. How did you do that?” It's hard to make something impressive now and it's just so overwhelming. I think that's also part of why Glitch and CodePen can be so helpful, because they take care of the nitty-gritty for you, so you can focus on being creative. Nate: [00:07:51] I'm optimistic. I think that I've seen some movement there with Minecraft maybe, Roblox is interesting. Yeah, there's some interesting ideas happening there. There's even some interesting, like more deliberate code for kid tools. There's one called Microsoft MakeCode Arcade. It's like Scratch, but it's designed for building games. Even that, board is on educational. I think there's something special, where it's not deliberately educational, but you learn from it that it's important. Cassie: [00:08:19] Scratch is so cool. I really love Scratch. The Harvard computer science course, the first thing that they get you to do is a thing in Scratch. When I started that, I was like, “Oh, I bet this is really – it's really hard. It's that like Harvard computer science course.” Then they were like, “We're going to build a game in scratch.” Wow, it's Nate: [00:08:39] cool. You're like, “I can do this. Yeah.” I hope that there's more tools that come out, particularly on tablets, because one of the things I notice with my kids is that they're using an iPad a lot more frequently than they're using a computer. I think just the ethos and the ecosystem of tablet apps is it's a lot more locked down. You can't necessarily look under the covers, like you would with Vue source on a webpage. I think any tools like that that let you learn are really interesting. There's a scratch junior that my kids use just to build little stories and little animations and I love that, but there's not too many tools yet, but I'm hoping we can create more. I Cassie: [00:09:15] feel there's some stuff in the hardware hacking, crafting worlds. I think that coding and crafting, the intersection of that, there's some quite interesting stuff happening, because I think you can fall into that accidentally as well if you're interested in hacking around with things. You can end up, “Oh, well. I want to make these lights flash and oh, I'm going to have to learn Python in order to do that.” I think that that's still yeah, accidental gateway Amelia: [00:09:51] into things. Yeah, I love that. I think some of the people I used to work with, they would spend time with their kids making a Halloween skull with an Arduino that makes its eyes flashed. It's such good bonding time, and because it's fun for everyone. I enjoy doing that. Cassie: [00:10:05] I was Amelia: [00:10:06] like, “I need a kid, so I mean, Cassie: [00:10:08] I can have an excuse Amelia: [00:10:09] to do Nate: [00:10:10] this.” Right. Yeah, I know. Right. But our kids are doing that now with cosplay stuff, is they first were doing little paper craft creatures. They would print off a template and they cut it out and they'd be like, “Oh, we want to make our own,” so then they're learning how to use blender to do their own 3D modeling. Then use, there's this tool called Pepakura, which you can use to slice 3D models down into a little papercraft, like Minecraft creature or whatever. Then they're learning computer skills for using Figma to edit the templates and they're using Blender to learn 3D modeling. They're not good at that yet, but you can see the progression. They're going to take over the world. Yeah. I recently watched one of your talks on CSS filters and it totally blew my mind. I've been programming for since we talked about since dial-up, and I didn't even know that SVG had filters. I thought that was so fascinating. Can you talk a little bit about your recent work on doing paintings with SVG? Cassie: [00:11:05] Yes. I've really been loving SVG filters recently. I got into a little bit of a slump at the beginning of lockdown, where I wasn't feeling creative at all. The idea of programming, coding sounded not so much fun. I wanted to do something a little bit more relaxing. Yeah, I find SVG and SVG filters really fun to play around with, because it's more declarative. You have some filter primitives and filter primitives they work – well, filters they work a lot like audio programming, where you've got inputs and outputs. You can chain things together. You have different filter primitives inside a filter element and you can feed the output of one into the input of the next one and the output of the first two into the input of another one. That means that there's infinite possibilities. Ultimately, all you're doing is just changing a couple of values and some attributes. It feels like putting Lego blocks together. You don't really have to think through any intricate logic. You can just put some filters together and see what happens. Yeah, I find that really fun, the randomness that you get not being able to predict the outcome. I've played around and I accidentally ended up with something that looked a little bit like a pencil line. Then I just riffed on that and made some things that looked a bit like hand sketched paintings, which was a lot of fun. Nate: [00:12:42] It's gorgeous. It is one of the most beautiful SVGs I've ever seen. We'll put a link in the show notes. It was just delightful and mind-blowing. I think that yeah, your talks on SVG are really a Cassie: [00:12:55] delight. That's so lovely to hear. When you have the chance to play with these things, is Amelia: [00:12:57] that all through just side projects? I know when my – at least my job title was developer, most jobs you don't get to play around or do something super creative. Is this something you get to do in your day-to-day job, or is it mostly just side? Yeah, what is Cassie: [00:13:16] your day job? My day job, I am a front-end developer at a company called Clearleft in Brighton. I'm lucky, because my job we have a mixture of client projects, but we also – well, not so much right now, because of the pandemic, but we also do events. The event sites are a chance to flex your creative muscles a little bit, try out new things. I get to explore things creatively through the event sites and then focus on building accessible, solid front-end websites for Amelia: [00:13:55] my day job. Oh, that's a nice balance of the more focused and the more creative. Are you usually working with designers? Cassie: [00:14:02] We have a lot of really good designers at Clearleft. It's hard, but we try to avoid pigeonholing people into just one role. If people want to explore a little bit more design, but they're a developer, then they try to give people space to do that. I'm currently working on a little side project site at work. I'm getting to do design and stuff on that, which is really nice. Nate: [00:14:28] You mentioned that you used to draw a lot and I feel that , experience in your work. Your chameleon, for example, is just adorable and obviously done by someone who has art skills outside of programming. What does your process look like? Are you sketching out ideas for what you want to see on paper, or do you just go straight to SVG? How does that work? Cassie: [00:14:48] It's very much technology-driven, rather than aesthetics first, actually. I tend to get ideas, because I'll be looking at a particular technology and then I'll think, “Oh, how could I demonstrate that? Or how could I play with that in a way that is aesthetically pleasing, or fun?” The chameleon, I wanted to play around with getting colors from a webcam. I did that and it was just changing Amelia: [00:15:16] a rectangle Cassie: [00:15:17] on the screen to different colors. I was like, “Well, that's fun, but it would be so much more fun if it was a chameleon.” Nate: [00:15:25] I love that in your work. Amelia does this too, I think, in that you build something and then it's like, okay, that's fine, but how do we make that more fun? Then you'll take the time to put in those details and it's really delightful. Cassie: [00:15:38] Yeah, I am such a huge fan of Amelia's work. Your article about the SVG viewBox, I have directed so many people at that. I had a whole lengthy explanation in a workshop that I did about the viewBox and then I was just like, well, actually just look at this wonderful article, because it explains it a million times better than I could. That's so Amelia: [00:15:59] good to hear. I feel like I do these things for myself. I'm like, okay, well I need a little toy example. Then I'm like, well, I might as well make it into a telescope. Might as well just let other people use it, I think the way you described your processes, it's very just like, playing around for your own personal benefit. Then just like, “Well, if I enjoy this, other people may also enjoy this.” You released your new website recently and I feel like it got a lot of attention, especially for the bottom. You have a little SVG of yourself and the eyes follow the cursor around. It's just really delightful to play around with, because there's so many websites out there. It's nice to even stumble across one, where you're like, “Oh, this person didn't just make a nice looking well-designed website, they took the next step to make it delightful and take a chance to connect with the user.” Cassie: [00:16:56] I love that so much. I'm not a huge fan of really whiz-bang websites, so websites that you land on and just everything animates and your cursor gets hijacked and your scroll gets hijacked and all of that thing. I find that really overwhelming. I absolutely love it when I'm navigating around a website that looks on the surface, like it's just your average website and then you hover over something, or you click something and it does something unexpected and joyful. It makes you smile. It makes the website feel a lot more human. Amelia: [00:17:32] I think you have to really understand how the web works to create a website that's both really easy to read and accessible and also has that next level. I feel it's easy to do the scroll-jacking, or just animations everywhere, but to have a little bit of restraint and to make it so that people with slower connections, or using screen readers can even navigate it as well. I think that's really awesome. Cassie: [00:17:58] Yeah. I think I had a head start, because I was using 11T. You get out of the box just a lot of performance benefits there. It's a static site generator. I think the tagline is it's a very simple static site generator. Nate: [00:18:12] On the tooling side, I've noticed that you use GreenSock for a lot of your animations. I've never really used GreenSock, but I've seen that a lot of CodePen people use it. Can you just talk about GreenSock a little bit, like what you about it and explain to me why it's so popular? Cassie: [00:18:29] Yeah. I have to start with the disclaimer that I don't work for GreenSock and GreenSock don't pay me any money. Because whenever I get really excited about GreenSock people are like, “She's got to be selling something.” Yeah, I love GreenSock so much. There are a whole bunch of different animation libraries out there, like JavaScript animation libraries. I think if you're doing things with HTML DOM, or say you're using a JavaScript animation library to trim some 3JS stuff, you're mostly just concerned with changing some numbers and a lot of the animation libraries handle things exactly the same way. The problem with SVG land is different browsers handle SVG transforms differently. You can end up with things moving around in unexpected ways in some older browsers and GreenSock, they have gone above and beyond to iron out all of these browser inconsistencies. You can be very sure that your SVG animations are going to work the way that they should do. They Amelia: [00:19:31] a lot more. They'll make really nice animations between things. They have this new scrolling library, right? Cassie: [00:19:39] Yeah. This is another really cool thing about GreenSock is that they've got the core GreenSock library. Their licensing model gets a bit misunderstood, because they're one of the only JavaScript animation libraries that aren't open source. But their core animation library is free for the majority of use cases. I think if you're selling an end product to multiple users, then you have to pay for it, but for 99% of people, it's free. Then they have these additional plugins. The core library does everything that you would need it to do and then the plugins are extra fun and some of the plugins are free and then some of them are behind a membership fee, but they've got a whole bunch of different SVG-specific plugins. They've got ones that help with SVG stroke animation and they've got ones that do morphing. Yeah, they've just released scroll trigger, which is amazing. I've played around with it a little bit. It uses one event listener behind the scenes, so it's really performance and just really intuitive as well. I think that's, yeah, another thing that I really love about GreenSock is the docs. They're just really good. They've got so many good animated examples in there and the forums are really, really friendly. It's like the opposite of stack overflow, can I say that? People are nice there. You post a question and I think as a newbie, I started off doing banner ads animation. That was my first job. I didn't have anyone to learn from and I had no idea what I was doing and I'd post on the GreenSock forum and someone would just jump in and help me out immediately. Yeah, it's really good. That's a Amelia: [00:21:22] really interesting business model. Cassie: [00:21:23] It's difficult to explain to people, but I understand why they do it, because it means that they don't have to rely on any external sponsors. They can just focus their time purely on updating it, which is why a lot of the other animation libraries don't have the time to put in the effort to make sure that things work with SVG cross browser, whereas GreenSock do. Oh, Amelia: [00:21:45] and it also looks like you can use any of the plugins on CodePen? Cassie: [00:21:50] Yes. It's super cool. That's the coolest thing. I think that's why so many people on CodePen use GreenSock, because everything's available to use on there. Amelia: [00:21:58] Yeah, that's super cool. I haven't had a chance to play with it yet, but it seems like it's – just a really great way to lower the overhead of if you're like, “Oh, I want this button to have a particle system and explode, or I want it to morph into this other thing.” It might just be too much work Cassie: [00:22:13] to do. We all have deadlines at Amelia: [00:22:14] work. If anything, even haves that effort, it might just make it worthwhile. Yeah, definitely. I think there's been quite a few times where people have gone, “Wow, that's Cassie: [00:22:23] a really cool animation that you've done.” Then see that it's five lines of green top coat. That's all Amelia: [00:22:32] it takes Nate: [00:22:33] sometimes, though. Yeah. It's Cassie: [00:22:35] also a lot easier to tweak your animations with green chords, or just an animation library in general. I've struggled with very complex animations with CSS, because you can't chain them together. It's really nice to have a timeline and all that. Amelia: [00:22:54] Yeah, are there any other tools like GreenSock that might be really useful for someone who is new to the more creative coding Cassie: [00:23:02] space? I don't Nate: [00:23:03] know. I'm curious on how to learn how to do SVG animations as well, because I feel the things that actually both of you create just feel like black magic to me. I don't really understand SVG super well, or particularly CSS animations. Golly. I am not good Amelia: [00:23:18] at Cassie: [00:23:19] that. Golly. Amelia: [00:23:21] I thought of one, which is similar. I've always felt like I've seen 3D stuff on the web. I don't know what wizard you have to be to have this 3D scene in a web page, but I will never be there. Then you discover 3JS Cassie: [00:23:38] and it's like – A frame as well. A Amelia: [00:23:41] frame. Cassie: [00:23:41] Yeah, A frame is really cool. It's a web framework for building virtual reality experiences. Oh, my goodness. Yeah. Amazing. Amelia: [00:23:51] I love it. I love how these libraries make even, just you have three lines of code and you're like, “I have no idea how I did this either.” Cassie: [00:23:59] I remember when I made my first Taurus knot in 3JS and I was so excited about it. I think pretty much out of the box, you have to import Amelia: [00:24:10] a plugin, but you can rotate it, you can zoom in and out, you can pan around. It's definitely magic. Cassie: [00:24:16] What's the D3 version of that? Is there a good entry point into D3? I Amelia: [00:24:23] have this spectrum in my head of things that are really complicated, but down to the metal. You can do whatever you want with them. Then the other end is a chart library that'll make a chart for you. You say, do a line chart with this data and it'll make a line chart. D3 is definitely on the former end, where it's like, it gives you tools you need. There's a lot of tools and you have to dig into each one of them. I feel if you want that oh, my God. This is magic feeling with D3, a lot of people, especially at the beginning, they'll just look up, there's so many examples online. They'll copy the code and then they'll paste it and then over two years, they'll understand what each line is doing, which I think everyone who learns D3, this is the way they learn it, just because those end examples are so cool and you're like, “I want this. I'm going to have it.” Then you take it and don't really understand all of it. Then there's also the chart libraries that make it super easy to do a really fancy chart really easily. Nate: [00:25:23] We talked a lot about this when we were working with React and D3. I mean, D3 is like React, in that it's a ton of different little modules that all work together. If you try to use for example, D3 with React, it's obnoxious, because D3 also takes over rewriting the DOM for you. One of the things that I would complain to Amelia when she was teaching me this is that to use D3 with React, you basically use React to form all the SVGs and you almost don't need D3, except for the utility functions. I don't actually know what is a good tool that's magic for D3. There's Amelia: [00:25:55] React chart libraries that you'll get something really amazing and be like, “I did this.” We're all on the shoulders of giants. Cassie: [00:26:04] I remember looking into D3. We got a solar panel installed on the roof of our work and I wanted to hook in. Well, you could hook into the API, which is really cool. I wanted to do that and see what we'd saved. I looked into D3 and it terrified me. Then I ended up making an illustration of our office building in SVG. I've set it up, so that with every certain amount of CO2 we save, it grows another plant out of a rooftop garden. Amelia: [00:26:44] I love how this was easier. Nate: [00:26:46] Yeah. Cassie: [00:26:49] It's like reaching for the tool that you understand. It's really difficult to make yourself learn new things. I was like, this is a great opportunity to learn D3. Then about 24 hours later I was like, “I'm going to make an SVG.” I think about this a Amelia: [00:27:05] lot where the flow state is in between something that's really boring and something that's really challenging. If something's too challenging and overwhelming, your brain will just shut off. You'll be like, “I can't learn this.” Then if it's too boring, your brain also shuts off and it's like, “I can just do this in my sleep.” I think a lot of people when they first look at D3, the needle goes all the way and they'll like, “This is overwhelming. I don't know where to start direction.” Then I think even with SVG, that was probably not in the boring area for you, even though you know SVG it was in the middle flow state of this is a good challenging. Cassie: [00:27:45] Yeah. Nate: [00:27:45] Cassie, in one of your talks you mentioned this idea that limitation breeds creativity. Could you talk a little bit more about that and your thoughts there? Cassie: [00:27:53] I have quite bad anxiety. I'm quite bad with procrastinating as well. I overthink things and I procrastinate. When I was learning how to code, there were lots of times where I'd sit down and stare at an empty VS code screen and just be like, “Right. I need to make something.” Then not knowing what to do. It felt a lot like when I was younger. I really loved drawing. At a certain point, I started doubting myself a little bit and overthinking it. My mom started what we called the scribble game. The scribble game was great. She'd take the paper from me and she'd draw a scribble on it, so that the paper wasn't blank anymore and then she'd hand it back to me and I had to make that scribble into something. It was a challenge, but there was a starting point. I think that that's so important when you're trying to make some things, to have a limitation and a challenge and a starting point. If you've got those three things, I think it's a lot easier. Amelia: [00:29:02] I love that. I Cassie: [00:29:03] love the scribble game. Yeah, it's wonderful. How Amelia: [00:29:07] can we apply this to code? How can we do a code scribble in order to lower that barrier? Cassie: [00:29:14] I guess, that's what you're saying about D3 having examples that you can copy and paste and start with. CodePen as well, like other people's pens that you can fork and Glitch has things that you can remix. I think that's a really great place to get started with something new, is just start with something and then see what you can make it into, or see how you can break it. I think it's a good way to learn things. Amelia: [00:29:40] Yeah, I think that's great. I was also reading an article yesterday. I've been meaning to learn 3D modeling, like you're talking about, Nate, that your kids are doing. It was this article, someone did a 100 days of 3D modeling to learn. They had a few things where it was like, one day they'll do a tutorial and the next day they'll make something with that knowledge. Every other day, they're doing a tutorial and it's an easier day, or every other day they do something easy and then they do something really hard. That's a good idea, because otherwise, you're either burning yourself out, or you're not learning as much as you could. Nate: [00:30:17] I feel like we are so early in programming education in that there's not really – I'm lumping 3D modeling into this too. There's not really a good place that you can go that will give you this off-the-shelf curriculum to learn 3D modeling, as you learn D3. Cassie: [00:30:32] Yeah, it's definitely a tricky thing. I find it really hard, even just trying to figure out what I need to learn to be a good front-end developer nowadays, because I feel there's just so much and I inevitably just go off on rabbit hole tangents all the time into the stuff that I'm really interested in. I'm like, “I should be learning webpack, but I'm going to learn some 3JS instead.” Amelia: [00:30:59] I feel whenever I try to write an article, I turn into a grade school version of myself that would tweak the PowerPoint slide styles, instead of actually writing my presentation, where this is the only reason idea in my blog posts have something fun in them is I don't like writing. Cassie: [00:31:16] I'd rather Amelia: [00:31:17] just do something fun, like scribble on the page with SVG. It's also a strength, I guess. Because most of these things I do, I'll end up using them Cassie: [00:31:26] in work. I work with someone who uses the phrase procrasti-working. That's when you know that you're really bad at procrastinating. You have a couple of things that you want to do. Then if you're not doing one of them, then you're going to be doing the other one to procrastinate them. Right, Nate: [00:31:43] procrastinate doing something else you should be doing, so that at least, you're moving Cassie: [00:31:48] I was to Amelia: [00:31:49] my friend about this. She said, she cleans when she has a deadline. That sounds like such a superpower. At least something's clean. Cassie: [00:31:57] Before I do a talk, my house is the tidiest it's ever been. Everything is alphabetically organized. Everything is polished. Nate: [00:32:06] Can you tell us about how you prep for your talks? What does that workflow look like? I prep with Cassie: [00:32:11] great difficulty, is the honest answer. I'm very lucky, because there's a lot of people at Clearleft who do a lot of public speaking. Jeremy Keith being one of them and he helped me huge amounts with my talk writing. I think that the first ever talk I did, it was just a little talk at a meet-up. I was just doing a show and tell, basically, of some of my CodePens I clutched a glass of wine for the whole thing and just showed people the fun stuff I was working on. Doing a conference talk, it needs to have a little bit more structure than just a list of things. I think that it's very rare that you see a talk that's just a list of things that is engaging. I think Jeremy really helped with that, because he's very good at telling stories and he said to me, what you need is you to make sure that your talk has a narrative structure. You need a flow to it. I wrote down everything that I wanted to talk about on post-it notes. Then Jeremy prompted me with different narrative structures. One being the hero's journey, I think was the one I used, so you've got a hero. The hero learns something along the way and overcomes something. I looked at all of the notes that I had and tried to arrange them into different narrative structures and then, eventually found one that I was happy with. Amelia: [00:33:39] What are the other narrative structures? What do you even google find this story to narrative arts? Nate: [00:33:45] The Wikipedia page on the hero's journey is pretty good. There's another one. There's a graph. I'll link to this in the show notes. There's a blog called Reedzy, and they've actually diagrammed out. There's a talk by Kurt Vonnegut, where he actually goes through all these different narrative arcs. One of them that he talks about is the hero's journey, but they actually plot out Cinderella. Here, I'll send you the link. Cassie: [00:34:10] I love graphs of Cinderella. Excellent. Nate: [00:34:14] Yeah, so Kurt Vonnegut, he wrote Slaughterhouse-Five and he also gave this really fantastic talk. There's a YouTube video of it, where it's Kurt Vonnegut graphs the plot of every story. There's actually a database of these different narrative plot lines. Dativism Cassie: [00:34:28] storytelling. Yeah, this is right up my street. Yeah, I love cart when I get as well. Amelia: [00:34:34] I also found this chart of how happy Harry Potter is throughout all the books. It looks like he just gets progressively less happy. Yeah, Nate: [00:34:42] progressively sadder the whole time, right? Amelia: [00:34:44] Yeah. It's pretty dark by that in there. Cassie: [00:34:47] What are some other narrative arcs? Oh, the rags to riches. That's a narrative arc. Oh, rags to riches has two, so there's the rags to riches rise and riches to rags full Icarus, where you rise and then fall. I feel that'd be such a Amelia: [00:35:03] disappointing book. Cassie: [00:35:04] Yeah. Amelia: [00:35:04] Everything's happy until the end. You definitely wouldn't want to choose that for a conference talk. Right. For a conference, you got to end on the up. Yeah, Cassie: [00:35:08] definitely. Amelia: [00:35:15] Yeah, I love the concept of using storytelling in talks, because I think, especially with technical talks, it can be very like, all right, people want facts. I'm going to tell people how to use this thing. I'm just going to have slide after slide of here's a fact, here's a best practice and then it can be really hard to sit through an hour of that and keep paying attention and just keep learning things. Cassie: [00:35:39] I think it's the human element, isn't it? Again, you need more whimsy and more human elements to things. I think some of the best conference talks that I've seen have been – I learnt this thing by doing it wrong for ages. This is what happened, because I was doing it wrong and I learned this lesson the hard way. I think that that's really good, because it feels – you have empathy with them. It feels more relatable. Amelia: [00:36:06] Brain, it's like, I can avoid this pain myself. Cassie: [00:36:11] Everybody likes to laugh at other people's misfortune as well. You Amelia: [00:36:16] just started a creative coding meetup. Cassie: [00:36:19] Yes. Amelia: [00:36:20] Right before lockdown, right? Cassie: [00:36:23] Yeah. We had about three meet-ups and then lockdown happened. It was really great. There's a conference in Brighton called FFConf and Charlotte Dan did a talk. She's amazing. She does lots of really cool generative art. She makes degenerative jewelry as well, which is very cool. A lot of my Brighton nerd friends, we all went to this conference and we saw her talk and she talks through pen plotting and generative art with CSS and generative art with JavaScript and using hardware and creating physical things, like jewelry and stuff. We were all really inspired. Afterwards, we were like, “Let's have a meet-up,” because it's really hard to find time to do all of that stuff and motivation to do side projects outside of work. We decided to do a meet-up that wasn't the normal talk structure, where you go along and watch people talk and then leave again. It was more of we call it a knitting circle for nerds. Everyone just goes along and we all have our laptops and we just tinker on projects and help each other. Then do a little show-and-tell at the end and eat crisps. Sometimes there's a very, very small dog. A very, very small dog. Very, very, very small chihuahua. Amelia: [00:37:48] [inaudible] . Cassie: [00:37:50] Yeah, now that's all moved online now, because of the plague. It's been really lovely, because we've got this little Slack community that has been there the whole time the lockdown's been happening and quarantine's been happening. It's just been such a great bunch of people. Creativity without the pressure and coding without the link to work and career development and stuff. It's just feels a very free space. Everyone there has been super open about feeling a bit creatively restricted, or battling with balancing out life stuff and coding. Yeah, it's been a really, really lovely group of people. Chris, one of the people from Brighton Generator, he is just a project machine. Even when everyone else hasn't been making stuff, he's just been knocking out projects pretty much every week. It's been wonderful watching what he's been making. That Amelia: [00:38:51] sounds so nice to just have that group, especially in these times. On Twitter, I feel a lot of people are having just such a hard time with a lot of people get inspiration from nature, or talking to people, or going places. It's just so hard when you always stay in the same house, if you see the same things and the same people all the time. Yeah, definitely. I think that that's fine. People shouldn't be outputting stuff all Cassie: [00:39:18] the time. You shouldn't feel like you have to constantly be producing things. Sometimes you have to take time to absorb stuff. If that's reading books, or watching tutorials, or going for walks, or that thing. I think it's all just as important. Amelia: [00:39:34] Totally agree. Cassie: [00:39:35] Ooh, if you're wanting to learn more about SVG filters, Sara Soueidan has an amazing set of articles on Codrops, which I Amelia: [00:39:43] learned everything from. They're really great. Nate: [00:39:45] One of the things I appreciate about you is that you remember people's names. I've noticed that in your talks as well. When you are saying, you're not just like, “Oh, there's a blog post on SVG filters.” You're like, “Sara Soueidan wrote this filter.” You should know her as well as her article. I really appreciate that. I think I would like to see more of that in general. Cassie: [00:40:06] It's so important. One of the things that brings me the most joy, which I've started doing is there are a few times where I had made a CodePen or something, or written a blog post and someone actually just sent me a direct message just saying, “Oh, I just read your article and it was really helpful. Thank you for that.” I do that now. Every time I read something and it's useful, I get hold of the person directly and just say, thank you. It's such a small thing, but yeah, I think it's really nice, especially for people who don't have analytics and tracking on their things, because I don't. I don't really want to know who's on my blog, because I get a bit too overwhelmed with numbers and statistics. But it's really nice to get a message from someone saying that they enjoyed it. Amelia: [00:40:51] I love that. Also, I feel for me, the better something is, probably the less likely I'll reach out to someone to say that I enjoyed it, because I'm like, “Oh, there's so many people who are telling them that it's great.” As a creator, it's so nice to get any message. I think being on the other side has helped that anxiety. Cassie: [00:41:12] Yeah. I think we put people on pedestals and don't reach out for that reason. I think we should stop doing Amelia: [00:41:19] also recently released new newsletter. I think it's monthly. What was your motivation behind starting it? I think it's solely focused on SVG, which is just a great niche. Where do you find inspiration for that newsletter? There is Cassie: [00:41:36] a little patch of time where GreenSock were hosting the CodePen challenges. I mean, it was about a month. Every week, Jack from GreenSock got hold of me with a whole load of CodePens for me to look through and judge. I just loved it. It was so much fun. I spent every Sunday evening just going through all of these different CodePens and writing people messages and telling them what I liked about it. I got so many lovely messages back. It just felt so joyful and so lovely to be able to signal boost some people who are making really cool things and give people some feedback. I basically just loved it, so I thought that I would like to carry on doing that. Then I had also, just before lockdown happened, I did a workshop in Brussels and I met Louie, who's also putting the newsletter together with me and we've been Internet friends for quite a while, but it was we met in person for the first time. We just got along really well. We decided we wanted to do a little side project together. Yeah, he's been writing some SVG tips for a while as well on Twitter and I've been looking at those and thinking, “Oh, it'd be great if we could get these tips out to some more people.” Amelia: [00:42:50] Oh, I've seen those. They're so good. Cassie: [00:42:52] Yeah, I learned things. Amelia: [00:42:54] Yeah, Cassie: [00:42:57] me too for sure. He's a creative coding tour de force, he is. Nate: [00:43:00] Cassie, thank you so much for being with us today. It was really delightful. Cassie: [00:43:04] Oh, it's an absolute pleasure. It was lovely to meet both of you, and especially because I've been such a huge fan of Amelia: [00:43:11] Amelia's work for a while. Nate: [00:43:19] Thank you. Hey, you made it to the end. I hope you enjoyed this conversation. Amelia: [00:43:22] If you have a minute, a review on iTunes would help other people find the podcast. We have a lot of great content coming up. To be notified of new episodes, hit that subscribe Cassie: [00:43:37] button.

Resources:The Coding Career Handbook WebsiteShawn's TwitterAmelia's TwitterNate's TwitterToday we're talking with Shawn Wang, a senior developer advocate at Amazon Web Services. Shawn is a prolific writer- you should totally check out his blog, if you haven't already. and most recently has written a book about the non-coding parts of your coding career.Shawn used to work at a hedge fund until transitioning to tech, and this gives him a unique perspective on how to be effective in your job - and why you should take ownership of your whole career.In this wide-ranging conversation we talk about the differences between a Jr and Sr engineers, how to find strength in your weaknesses, and how to capture your daily ideas and use them to supercharge your career.I think developers at any level will get a tons of value from this conversation, let's dive in.

newline Podcast Sudo StephNate: [00:00:00] Steph, just tell us a little bit about your work and kind of your background with, like AWS and like what you're doing now.Steph: [00:00:06] Yes, so I work as a engineer for a manage services provider called Second Watch. We basically partner with other big companies that use AWS or some other clouds sometimes Azure for managing their cloud infrastructure, which basically just means that.We help big companies who may not, their focus may not be technology, it may not be cloud stuff in general, and we're able to just basically optimize the cost of everything, make sure that things are running reliably and smoothly, and we're able to work with AWS directly to kind of keep people ahead of the curve when.New stuff is coming out and just it changes so much, you know, it's important to be able to adapt. So like personally, my role is I develop automation for our internal operations teams. So we have a bunch of, you know, just really smart people who are always working on customer specific AWS issues. And we see some of the same issues.Pop up over and over. Of course, you know, security , auditing, cost optimization. And so my team makes optimizations that we can distribute to all of these clients who have to maintain their own. You know, they have their own AWS account. It's theirs. And we make it so that we're actually able to distribute these automations same way in all of our customers' accounts.So the idea is that, and it's really wouldn't be doable without serverless because the idea is that everyone has to own their own infrastructure, right? Your AWS account is yours does or your resources, you don't, for security reasons, want to put all of your stuff on somebody else's account. But actually managing them all the same way can be a really difficult, even with scripts, because permissions different places have to be granted through the AWS permissions up with  access, I identity and access management, right? So serverless gave us the real tool that we needed to be able to at scale, say, Hey, we came up with a little script that will run on an hourly basis to check to see how much usage these servers are getting, and if they're not production servers, you know, spin them down if they're not in use to save money.Little things like that when it comes to operations and AWS Lambda is just so good for it because it's all about, you know, like I said, doing things reliably. Doing things in a ways that can be audited and logged and doing things for like a decent price. So like background wise, I used to work at AWS in AWS support actually, and I kind of supported some of their dev ops products like OpsWorks, which is based on chef for configuration management, elastic Beanstalk and AWS CloudFormation, specifically. After working there for a bit, I really got to see, you know, how it's made and what the underlying system is like. And it was just crazy just to see how much work goes into all this, just so you can have a supposedly, easier to use for an end. But serverless just kinda changed all that for the better.Luckily.Amelia: [00:02:57] So it sounds like AWS has a ton of different services. What are the main ones and how many are there?Steph: [00:03:04] So I don't think I can even count anymore because they just, they do release new ones all the time. So hundreds at this point, but really main ones, and maybe not hundreds, maybe a little over a hundred would be a better estimate.I mean,  EC2 which is elastic compute is. The bread and butter. Historically, AWS is just, they're virtualized servers basically. So EC2, the thing that made AWS really special from the beginning and that made cloud start to take over the world was the concept of auto scaling groups, which are basically definitions you attached to EC2 and it basically allows you to say, Hey, if I start getting a lot of traffic on.This one type of server, right? You know, create a second server that looks exactly the same and load balance the traffic through it. So when they say scaling, that's basically what, how you scale, easy to use auto scaling groups and elastic load balancers and kind of distribute the traffic out. The other big thing besides the scalability of  with auto scaling groups is.Redundancy. So there's this idea of regions within AWS, and within each region there's availability zones. So regions are the general, like you can think of it as the place where data center is kind of like located within like a small degree. So it's usually like. Virginia is one, right? That's us East one.It's the oldest one. Another one is in California, but they're all over the world now. So the idea is you pick a region to minimize latency, so you pick the region that's closest to you. And then within the region, there's the idea of availability zones, which are basically just discreet, like physical locations of the servers that you administer them the same way, but they're protected.So like if a tornado runs through and hits one of your data centers. If you happen to have them distributed between two different availability zones, then you'll still be able to, you know, serve traffic. The other one will go down, but then the elastic load balancer will just notice that it's not responding and send the traffic to the other availability zone.So those are the main concepts that make it like EC2 those are what you need to use it effectively.Nate: [00:05:12] So with an easy to instance, that would be like a virtual server. I mean, it's not quite a Docker container, I guess we're getting to nuance there, but it's basically like a server that you would have like command line access to.You could log in and you can do more or less whenever you want on an EC2 instance.Steph: [00:05:29] Right, exactly. And so it used to be AWS used what was called Zen virtualization to do it. And that's just like you can run Zen on your own computer, you can get a computer and set up a virtual machine, almost just like they used to do it .So they are constantly putting out like new ways of virtualizing more efficiently. So they do have new technology now, but it's not something that was really, I mean, it was well known, but they really took it to a new kind of scale, which made it really impressive.Nate: [00:05:56] Okay, so EC2 lets you have full access to the box that's running and you might like load bounce requests against that.How does that contrast with what you do with AWS Lambda and serverless?Steph: [00:06:09] So with , you still have to, you know, either secure shell or, you know, furious and windows. Use RDP or something to actually get in there. You care about what ports are open. You have security groups for that. You care about all the stuff you would care about normally with a server you care about.Is it patched and up today you care about, you know, what's the current memory and CPU usage? All those things don't go away on EC2 just because it's cloud, right? When we start bringing serverless into the mix, suddenly. They do go and away. I mean, and there's still a few limitations. Like for instance, a Lambda has a limit on how much memory it can process with, just because they have to have a way to kind of keep costs down and define the units of them and define where to put them.Right? But at its core, what a Lambda is, it actually runs on a Docker container. You can think of it like a pre-configured Docker container with some pre-installed dependencies. So for Python, it would have. The latest version of Python that it says it has, it would have boto. It would have the stuff that it needs to execute that, and it would also have some basic, it's structured like it was, you know, basic Linux.So there's like a attempt. So slash temp you can write files there, right. But really it's like a Docker container. That runs underneath it on a fleet of . As far as availability zone distribution goes, that's already built into land, but you don't have to think about it with . You do have to think about it.Because if you only run one easy to server and it's in one availability zone, it's not really different from just having a physical server somewhere with a traditional provider.Nate: [00:07:38] So. There are these two terms, there's like serverless and Lambda. Can you talk a little bit about like the difference between those two terms and when to use each appropriately?Steph: [00:07:48] Yeah, so they are in a way sorta interchangeable, right? Because serverless technology just means the general idea of. I have an application, I have it defined it an artifact of we'll say zip from our get repo, right? So that application is my main artifact, and then I pass it to a service somewhere. I don't know.It could be at work. The Google app engine, that's a type of serverless technology and AWS Lambda is just the specific AWS serverless technology. But the reason AWS Lambda is, in my opinion so powerful, is because it integrates really well with the other features of AWS. So permissions management works with AWS Lambda API gateway.there's a lot of really tight integrations you can make with Lambda so that it doesn't, it's not like you have to keep half of your stuff one place and half of your stuff somewhere else. I remember when like Heroku was really big . A lot of people, you know, maybe they were maintaining an AWS account and they were also maintaining a bunch of  stuff and Heroku, and they're just trying to make it work together.And even though Heroku does use, you know, AWS on the backend, or at least it did back then, it can just make things more complicated. But the whole server, this idea of the artifact is you make your code general, it's like a little microservice in a way. So I can take my serverless application and ideally, you know, it's just Python.I use NF, I write it the right way. Getting it to work on a different server. This back end, like for, exit. I think Azure has one, and Google app engine isn't really too much of a change. There's some changes to permissions and the way that you invoke it, but at the core of it, the real resource is just the application itself.It's not, you know, how many, you know, units of compute. Does it have, how many, you know, how much memory, what are the IP address rules and all that. YouNate: [00:09:35] know. So what are some good apps to build on serverless?Steph: [00:09:39] Yes. So you can build almost anything today on serverless, there's actually so much support, especially with AWS Lambda for integrations with all these other kinds of services that the stuff you can't do is getting more limited.But there is a trade off with cost, right? Because. To me the situation where it shines, where I would for no reason ever choose anything but serverless, is if you have something that's kind of bursty. So let's say you're making like a report generation tool that needs to run, but really you only run it three times a week or something like things that.They need to live somewhere. They need to be consistent. They need to be stable, they need to be available, but you don't know how often they're going to call. And even if they can go from that, there is small numbers of times it's being called, because the cool thing about serverless is , you're charged per every 100 milliseconds of time that it's being processed.When it comes to , you're charged and units that are, it used to be by the hour, I think they finally fixed it, and it's down to smaller increments. . But if you can write it. Efficiently. You can save a ton of money just by doing it this way, depending on what the use cases. So some stuff, like if you're using API gateway with Lambda, that actually can.Be a lot more expensive than Lambda will be. But you don't have to worry about, especially if you need redundancy. Cause otherwise you have to run a minimum of two  two servers just to keep them both up for a AZ kind of outages situation. You don't have to worry about that with Lambda. So anything that with lower usage 100%.If it's bursty 100% use Lambda, if it's one of those things where you just don't have many dependencies on it, then Lambda is a really good choice as well. So there's especially infrastructure management, which is, if you look, I think Warner Vogels, he wrote something recently about how serverless driven infrastructure automation is kind of going to be the really key point to making places that are using cloud use cloud more effectively.And so that's one group of people. That's a big group of people. If you're a big company and you already use the AWS and you're not getting everything out of it that you thought you would get. Sometimes there's serverless use cases that already exist out there and like there's a serverless application repo that AWS provides and AWS config integrations, so that if you can trigger a serverless action based off of some other resource actions. So like, let's say that your auto scaling group  scaled up and you wanted to like notify somebody, there's so many things you could do with it. It's super useful for that. But even if you're just, I'm co you're coming at it from like a blank slate and you want to create something .There are a lot of really good use cases for serverless. If you are, like I said, you're not really sure about how it's going to scale. You don't want to deal with redundancy and it fits into like a fairly well-defined, you know, this is pretty much all Python and it works with minimal dependencies. Then it's a really good starting place for that.Nate: [00:12:29] You know, you mentioned earlier that serverless is very good for when you have bursty services in that if you were to do it based on  and then also get that redundancy one. You're going to have to run while you're saying you'll have to run at least two EC2 instances, just 24 hours a day. I'm paying for those.Plus you're also going to pay for API gateway. Do you pay hourly for API gatewaySteph: [00:12:53] API gateway? It, it would work the same either way, but you would pay for, in that case, like a load balancer.Nate: [00:12:59] What is API gateway? Do you use that for serverless?Steph: [00:13:02] All the time. So API gateway?Nate: [00:13:04] Yeah. Tell us the elements of a typical serverless stack.So I understand there's like Lambda, for example, maybe you say like you use CloudFront. In front of your Lambda functions, which may be store images and S3 that like a typical stack? And then can you explain like what each of those services are,Steph: [00:13:22] how you would do that? Yeah, so you're, you're not, you're on the right track here.So, okay. So a good way to think about it is, if you look at AWS has published something which a lot of documentations on it called the serverless application management standard. So S a N. And so basically if you look at that, it actually defines the core units of serverless applications. So which is the function, an API, if you, if you want one.And basically any other permission type resources. So in your case, let's say it was something where I just wanted like a really. Basic tutorial that AWS provides is someone wants to upload an image for their profile and you want to, you know, scale it down to like a smaller image before you store it on your S3.You know, just so they're all the same size and it saves you a ton, all that. So if you're creating something like that, the AWS resources that you would need are basically an API gateway, which is. Acts as basically the definition of your API schema. So like if you've ever used swagger or like a open API, these standards where you basically just define, and JSON, you know it's a rest API, you do get here, post here, this resource name.That's a standard that you might see outside of AWS a lot. And so API Gateway is just basically a way to implement that same standard. They work with AWS. So that's how you can think of API gateway. It also manages stuff like authentication integration. So if you want to enable OAuth or something on something, you could set that up the API gateway level.SoNate: [00:14:55] if you had API gateway set up. Then is that basically a web server hosted by Amazon?Steph: [00:15:03] Yeah, that's basically it.Nate: [00:15:05] And so then your API gateway is just  assigned essentially randomly a DNS name by Amazon. If you wanted to have a custom DNS name to your API gateway. How do you do that?Steph: [00:15:21] Oh, it's just a setting.It's pretty. so what you could do, yeah, so if you already have a domain name, right? Route 53 which is AWS is domain name management service, you can use that to basically point that domain to the API gateway.Nate: [00:15:35] So you'd use route 53 you configure your DNS to have route 53 point a specific DNS name to your API gateway, and your API gateway would be like a web server that also handles like authentication and AWS integration. Okay,Steph: [00:15:51] got it. Yeah, that's a good breakdown of what that works. So that's your first kind of half of how people commonly trigger Lambdas. And that's not the only way to trigger it, but it's a very common way to do it. So what happens is when the API gateway is configured, part of it is you set what happens when the method is invoked.So there's like a REST API as a type of API gateway that. People use a lot. There's a few others, like a web socket, one which is pretty cool for streaming uses, and then they're always adding new options to it. So it's a really neat service. So you would have that kind of input go into your API gate.We would decide where to route it. Right. So in a lot of cases here, you might say that the Lambda function is where it gets routed to. That's considered the integration to it. And so basically API gateway passes it all of this stuff from the requests that you want to pass it. So, you know, I want to give it the content that was uploaded.I want to give it the IP address. It originally came from whatever you want to give it.Nate: [00:16:47] What backend would people use for API gateway other than Lambda? Like would you use an API gateway in front of an EC2 instance?Steph: [00:16:56] You could, but I would use probably a load balancer or application load balancer and that kind of thing.There's a lot of things you can integrate it for. Another cool one is, AWS API calls. It can proxy, so it can just directly take input from an API and send it to a specific API call if you want to do that. That's kind of some advanced usage, but Lambdas are kind of what I see is the go-to right now.Nate: [00:17:20] So the basic stack that we're looking at is you use API gateway to be in front of your Lambda function, and then your Lambda function just basically does the work, which is either like a writing to some sort of storage or calculating some sort of response. You mentioned earlier, you said, you know the Lambda function it can be fronted by an API if you want one. And then you mentioned, you know, there's other ways that you can trigger these Lambda functions. Can you talk a little bit about like what some of those other ways are?Steph: [00:17:48] Yeah, so actually those are really cool. So the cool thing is that you could trigger it based off of basically any type of CloudWatch event is a big one.And so CloudWatch is basically a monitoring slash auditing kind of service that AWS provides. So you can set triggers that go off when alarms are set. So. It could be usage, it could be, Hey, somebody logged in from an IP address that we don't recognize. You could do some really cool stuff with CloudWatch events specifically. And so those are one that I think for like management purposes are really powerful to leverage. But also you can do it off of S3 events, which are really cool. So like you could just have it, so anytime somebody uploads a. Let's say it was a or CI build, right?  You're doing IA builds and you're putting your artifacts into a S three bucket, so you know this is released version 1.1 or whatever, right?You put it into an S3 bucket, right? You can hook it up so that when ever something gets put into that S3 bucket. That another action is that takes place so you can make it so that, you know, whenever we upload a release, then you know, notify these people. So now an email or you can make it so that it, you know, as complicated as you want, you can make it trigger a different kind of part in your build stage.If you have things that are outside of AWS, you can have it trigger from there. There's a lot of really cool, just direct kind of things that you don't need. An API for. An S3 is a good one. The notification service, SNS it's used within AWS a lot that can be used. The queuing service AWS provides called SQS.It works with, and also just scheduled events, which I really like because it replaces the need for a crown server. So if you have things that run, you know, every Tuesday or whatever, right, you can just trigger your Lambda to do that from just one configuration point, you don't have to deal with anything more complicated than that.Nate: [00:19:38] I feel like that gives me a pretty good grounding in the ecosystem, in the setting. Maybe we could talk a little bit more about tools and tooling. Yeah, so I know that in the JavaScript world, on like the node world, they have the serverless framework, which is basically this abstraction over, I think it's over like Lambda and you know, Azure functions and Google up.Google cloud probably too. Do they have like a serverless framework for Python or is there like a framework that you end up using? Or do you just generally just write straight on top of Lambda?Steph: [00:20:06] So that's a great question and I definitely do recommend that even though there is like a front end you could do to just start, you know, typing code in and making the Lambda work right.It's definitely better to have some sort of framework that. Integrates with your actual, like, you know, wherever you use to store your code and test it and that kind of thing. So serverless is a really big one, and that's, it's kind of annoying because serverless, you know, it also refers to the greater ecosystem of code that runs without managing underlying servers.But in this particular case, Serverless is also like a third party company in tooling, and it does work for Python. It works for, a whole budget. That's kind of like the serverless equivalent in my head of like Terraform, something that is kind of meant to be kind of generic, but it offers a lot of kind of value to people just getting started. If you just want to put something in your, read me that says, here's how to, you know, deploy this from Github. You know, serverless is a cool tool for that. I don't personally like building with it myself just because I find that this SAM, which is Serverless Application Model, I think I said management earlier, but it's actually model.I just looked that up. I feel like that has everything I really want for AWS and I get more fine grain control. I don't like having too much obstruction and I also don't like. When you have to install something and something changes between versions and that changes the way your infrastructure gets deployed.That's a pet peeve of mine, and that's why I don't really use Terraform too much for the same reason. When you're operating really in one world, which in my case is AWS, I just don't get the value out of that. Right. But with the serverless application model, and they have a whole Sam CLI, they have a bunch of tools coming out.So many examples on their Github repos as well. I find that it's got really everything. I want to use plus some CloudFormation plugs right into that. So if I need to do anything outside of the normal serverless kind of world, I can do that. So it's better to use serverless than to not use anything at all.  I think it's a good tool and really good way to kind of get used to it and started, but at least my case where it really matters to have super consistent deployments where I'm sharing between people and accounts and all of that. And I find that SAM really gives me the best kind of best of both worlds.Amelia: [00:22:17] So, as far as I understand it, serverless is a fairly new concept.Steph: [00:22:22] You know, it's one of those things it's catching on. Recently, I felt like Google app engine candidate a long time ago, and it was kind of a niche thing for awhile, but it recently it, we're starting to see. Bigger enterprises, people who might not necessarily want bleeding edge stuff start to accept that serverless is going to be the future.And that's why we're seeing all this stuff come up and it's, it's actually really exciting. But the good thing is it's been around long enough that a lot of the actual tooling and the architecture patterns that you will use are mature. They've been used for years. Their sites you've been using for a long time that.You don't know that it's serverless on the back end, but it is because it's one of those things that doesn't really affect you unless you're kind of working on it. Right. But it's new to a lot of people, but I think it's in a good spot where it's more approachable than it used to be.Nate: [00:23:10] When you say that there's like a lot of standard patterns, maybe we could talk about some of those.So when you write a Lambda function and code, either with like Python or Java script or whatever, there are bloods, they say Python because you use Python primarily right? Well, maybe we could talk a little bit about that. Like why do you prefer Python?Steph: [00:23:26] Yeah, so just coming from my background, which is, like I said, I did some support, did some straight dev ops, kind of a more assisted mini before the world kind of became a more interesting place kind of background.Python is just one of those tools that is installed on like every Linux server in the world and works kind of predictably. Enough people know it that it's, it's not too hard to like. Share between people who may not be, you know, super advanced developers, right? Cause a lot of people I work with, maybe they have varying levels of skills and Python's one of those ones you can start to pick up pretty quickly.And it's not too foreign really to people coming from other languages as well. So it's just a practicality thing for a lot of it. But there's also a lot of the tooling that is around. Dev ops type stuff is in Python, like them, Ansible for configuration management, super useful tool. You know, it's all Python.So really there's, there's a lot of good reasons to use Python from, like in my world it's, it's one of the things where you don't have to use one specific language, but Python is just, it has what I need and it gets, I can work with it pretty quickly. The ecosystems develop. There's still a lot of people who use it and it's a good tool for what I have to do.Nate: [00:24:35] Yeah, there's tons, and I was looking at the metrics. I think Python is like, last year was like one of the fastest growing programming languages too. There's a lot of new people coming into Python,Steph: [00:24:44] and a lot of it is data science people too, right? People who may not necessarily have a strong programming background, but there's the tooling they need in a Python already there.There's community, and it sucks that it's not as scary looking as some other languages, frankly. You know.Nate: [00:24:58] And what are some of the other like cloud libraries that Python has? Like I've seen one that's called like BotoSteph: [00:25:03] Boto is the one that Amazon provides as their SDK, basically. And so every Lambda comes bundled with Boto three you know, by default.So yeah, there was an older version of ODA for Python too. But Boto three is the main one everyone uses now. So yeah, Bodo is great. I use it extensively. It's pretty easy to use, a lot of documentation, a lot of examples, a lot of people answering questions about it on StackOverflow, but I'm really, every language does have an SDK for AWS these days, and they all pretty much work the same way because they're all just based off of.The AWS API APIs and all the API APIs are well-defined and pretty stable, so it's not too much of a stretch to use any other language, but Bono's the big one, the requests library in Python is super useful just because it makes it easier to deal with, you know, interacting with API APIs or interacting with requests to APIs.It's just all about, you know, HTP requests and all that. Some of the new Python three. Libraries are really good as well, just because they kind of improve. It used to be like with Python 2, you know, there's URL lib for processing requests and it was just not as easy to use. So people would always bundle a third party tool, like requests, but it's getting better.Also, you know, Python, there's some. Different options for testing Py unit and unit test, and really there's just a bunch of libraries that are well maintained by the community. There's a kazillion on PyPy, but I try to keep outside dependencies from Python to a total minimum because again, I just don't like when things change from underneath me, how things function.So it's one of the things where I can do a lot without. Installing third party libraries, so wherever I can avoid it, I do.Nate: [00:26:47] So let's talk a little bit about these patterns that you have. So Lambda functions generally have a pretty well defined structure, and it's basically through that convention. It makes it somewhat straightforward to write each function. Can you talk a little bit about like, I don't know, the anatomy of a Lambda function?Steph: [00:27:05] Yeah,  so at its basic core, the most important thing that every Lambda function in the world is going to have is something called a handler. And so the handler is basically a function that is accessed to begin the way that it starts.So, any Lambda function when it's invoked. So anytime you are calling it, it's called invoking a Lambda function. It sends it parameters that are event. An event is basically just the data that defines, Hey, this is stuff you need to act on. And it sends it something called context, which a lot of time you never touched the context object.But it's useful too, because AWS provides it with every Lambda and it's basically like, Hey, this is the ID of the currently running Lambda function. You know, this is where you're running. This is the Lambdas name. So like for logging stuff, context can be really useful. Or for stuff where it's like your function code may need to know something about where it is.You can save yourself time from, you don't have to use like an environment. They're able, sometimes if you can look in the context object. So at the core it's cause you have at least a file, you can name it whatever you want. A lot of people call it index and then within that file you define a function called handler.Again, it doesn't have to be called handler, but. That makes it easy to know which one it is, and it takes that event and context. And so really, if that's all you have, you can literally just have your Lambda file be one Python file that says, you can say def handler takes, you know, object and then return something.And then that can be it. As long as you define that index dot handler as your handler resource, which is, that's a lot of words, but basically we need to find your Lambda within AWS.  The required parameters are basically the handler URI, which is the name of the file, and then a.in the name of the handler function.So that's at its most basic. Every Lambda has that, but then you start, you know, scoping it out so you can actually know, organize your code decently. And then it's just a matter of, is there a read me there. Just like any other Python application really, you know, do you have a read me? Do you want to use like a requirements.txt file to like define, you know, these are the exact third party libraries that I'm going to be using.That's really useful. And if you're defining it with SAM, which I really recommend. Then there's a file called template.yaml And that's just contains the actual, like AWS resource definition, as well as any like CloudFormation defined resources that you're using. So you can make a template.yaml as the infrastructure kind of as code, and then everything else, just the code as code.Nate: [00:29:36] Okay. So unpacking that a little bit, you'll invoke this function and they'll basically be two arguments. One is the event that's coming in the event in particular, and then it'll also have the context, which is sort of metadata about the context in which this request is running. So you mentioned some of the things that come in the context, which is like what region you're in or what the name of the function is that you're on.What are some of the parameters in the event object.Steph: [00:30:02] So the interesting thing about the event object. Is, it can be anything. It just has to be basically a Python dictionary or basically, you know, you could think of it like a JSON, right? So it's not predefined and Lambda itself doesn't care what the event is.That's all up to your code to decide what is it, what is a valid event, and how to act on it. So API gateway if you're using that. There's a lot of example events, API gateway will send and so if you like ever try it, look at like the test events for Lambda, you'll see a lot of like templates, which are just JSON files with like expected outputs.But really it can be anything.Nate: [00:30:41] So the way that Lambda's structured is that API gateway will typically pass in an event that's maybe like the request was a POST request, and then it has these like query parameters or headers attached to it. And all of that would be within like the request object. But the event could also be like you mentioned like CloudWatch, like there's like a CloudWatch event that could come in and say, you basically just have to configure your handler to handle any of the events you expect that handler to receive.Steph: [00:31:07] Yeah, exactly.Nate: [00:31:09] So let's talk a little bit more about the development tooling. How in the world do you test these sorts of things? Like with, do you have to deploy every single time or tell us about like the development tooling that you use to test along the way.Steph: [00:31:22] Yeah. So I'm, one of the great things about SAM and there's some other tools for this as well, is that it lets you test your Lambdas locally before you deploy it, if you want.And the way that it does that is, I mentioned earlier that Lambda is really at its core, a container, like a Docker container running on a server somewhere. Is, it just creates a Docker container that behaves exactly like a Lambda would, and it sends your events. So you would just define basically a JSON with the expected data from either API gateway or whatever, right?You make a test one and then it will send it to that. It'll build it on demand for you and you test it all locally with Docker. When you like it, you use the same tool and it'll package it up and deploy it for you. So yeah, it's actually not too bad to test locally at all.Nate: [00:32:05] So you create JSON files of the events that you want it to handle, and then you just like invoke it with those particular events.Steph: [00:32:12] Yeah, so basically like if I created it like a test event, I would save it to my repo is tests slash API gateway event.json Had put in the data I expect, and then I would do like a SAM. So the command is like SAM, a local invoke, and then I would give it to the file path to the JSON, and it would process it.I'd see the exact same output that I would expect to see from Lambda. So it'll say, Hey, this took this many milliseconds to invoke the response code was this, this is what was printed. So it's really useful just for. It's almost a one to one with what you would get from Amazon Lambda output.Amelia: [00:32:50] And then to update your Lambda functions.Do you have to go inside the AWS GUI or can you do that from the command line.Steph: [00:32:57] yeah, no, you can do that from the command line with Sam as well. So there's a Sam package and Sam deploy command. It's useful if you need to use basically any type of CII testing service to like manage your deployments or anything like that.Then you can get a package it and then send it the package to your, Whatever you're using, like Gitlab or something, right. For further validation and then have Gitlab deploy it. Like if you don't want people to have deployed credentials on their local machine, that's the reason it's kind of broken up into two steps there.But basically you just do a command, Sam deploy, and what it does is it goes out to Amazon. It says, Hey, update the Lambda to point to this as the new resource artifact to be invoked. And if you're using and which I think it's enabled by default, not actually the versioning feature, it actually just adds another version of the Lambda so that if you need to roll back, you can just go to the previous one, which is really useful sometimes.Nate: [00:33:54] So let's talk a little bit about deployment. One of the things that I think is stressing when you are deploying Lambda functions is like, I have no idea how much it's going to cost. How is it going to cost to launch something, and how much am I going to pay? And I guess maybe you can kind of calculate if you estimate the number of requests you think you're going to get, but how do you approach that when you're writing a new function?Steph: [00:34:18] Yeah, so the first thing I look at is what's the minimum, basically timeout, what's the minimum memory usage? So number of invocations is a big factor, right? So like if you have free tier, I think it's like a million invocations you get, but that's like assuming like a hundred under a hundred milliseconds each.So when you just deploy it, there's no cost for just deploying it. You don't get charged until it's invoked. If you're storing like an artifact and as three, there's a little cost for you keeping it in as three. But it's usually really, really minimal. So the big thing is really, how many times are you give it?Is it over a million times and or are you not on free tier? The costs, like I said, it gets batchedtogether and it's actually really pretty cheap just in terms of number of invocations cause at the bigger places where you can normally save costs. Is it over-provisioned for how much memory you give it?Right. I think the smallest unit you can give it as 128 that can go up to like two gigabytes maybe more now. So if you have it set where, Oh, I want it to use this much memory and it really never is going to use that much memory and that's kind of like wasteful or if you know, if it uses that much, that's like something's wrongNate: [00:35:25] cause you pay, you configure beforehand, like we're going to use max 128 megabytes of memory and then it's allocated on invocation or something like that.And then if you set it too high, you were going to pay more than you need to. Is that right?Steph: [00:35:40] Yeah. Well and it's more like, I think I'll have to double check cause it actually just show you how much memory you use each time in Lambda is invoked. So you can sort of measure if it's getting near that or if you think you need more than it might give an error.If it doesn't, it isn't able to complete . But in general, like. I haven't had many cases where the memory has been the limiting factor. I will say that, the timeout can sometimes get you, because if a Lambda's processing forever, like let's say API gateway, a lot of times API gateway has its own sort of timeout, which is, I think it's like 30 seconds to respond.And if your Lambda is set to, you know, you give it five minutes to process  it always five minutes processing. If you, let's say that you program something wrong and there's like a loop somewhere and it's going on forever, it'll waste five minutes. Computing API gateway will give up after 30 seconds, but you'll still be charged for the five minutes that Lambda was kind of doing its thing.SoNate: [00:36:29] it's like, I know that AWS is services and Lambda are created by like world-class engineers. It's the highest performing infrastructure probably in the world, but as a user, sometimes it feels like there's giant Rube Goldberg machine, and I have like no idea. All of the different aspects that are involved in, like how do you manage that complexity?Like when you're trying to learn AWS, like let's say someone who's listening to this, they want to try to understand this. How do you. Go about making sense of all of that. Like difficulty.Steph: [00:37:02] You really have to go through a lot of the docs, like videos, people showing you how they did something isn't always the best just because they kind of skirt around all the things that went wrong in the process, right? So it's really important just to understand, just to look at the documentation for what all these features are before you use them. The marketing people make it sound like it's super easy and go, and to a degree, it really is like, it's easier than the alternative, right?It's where you put your complexities the problem Nate: [00:37:29] yeah, and I think that part of the problem that I have with their docs is like they are trying to give you every possible path because they're an infrastructure provider, and so they support like these very complex use cases. And so it's, it's like the world's most detailed choose your own adventure.It's like, Oh, have you decide that you need to take this path? Go to   or this one path B. Path C there's like so many different like paths you can kind of go down. It's just a lot when you're first learning.Steph: [00:37:58] It is, and sometimes like the blog posts have better kind of actual tutorial kind of things for like real use cases.So if you have a use case that is general enough, a lot of times you can just Google for it and there'll be something that one of their solution architects wrote up about had actually do it from like a, you know, user-friendly perspective that anything with the options is that you need to be aware of them too, just because the way that they interact can be really important.If you do ever do something that's not done before and the reason why it's so powerful and what, you know why it takes all these super smart people to set up and all this stuff is actually because are just so many variables that go into it that you can do so much with that. It's so easy to shoot yourself in the foot.It always has been in a way, right? But it's just learning how to not shoot yourself in the foot and use it like with the right agility. And once you get that down, it's really great.Amelia: [00:38:46] So there's over a hundred AWS services. How do you personally find new services that you want to try out or how does anyone discover any of these different services.Steph: [00:38:57] What I do is, you know, I get the emails from AWS whenever they release new ones, and I try to, you know, keep up to date with that. Sometimes I'll read blog posts that I see people writing about how they're using some of them, but honestly, a lot of it's just based off of when I'm doing something, I just keep an eye out.If there's something like, I wished that it did sometimes, like, I used some AWS systems manager a lot, which is basically. You can think of it. It's sort of like a config management an orchestration tool. It lets you, basically, it's a little agent. You can sell on  servers and you can, you know, just automate patching and all this other like little stuff that you would do with like Chef or Puppet or other config management tools.And. It seems like they keep announcing services. What are really just like tie ins to existing ones, right? Which is like, Oh, this one adds, you know, for instance, like the secret management and the parameter store would secrets. A lot of them are really just integrations to other AWS services, so it's not as much.The really core ones that everyone needs to know is, you know, EC2 of course Lambda, so big API gateway and CloudFormation because it's basically. The infrastructure as code format that is super useful just for structuring everything. And I guess S3 is the other one. Yeah. Let's talk aboutNate: [00:40:15] cloud formation for a second.So earlier you said your Lambda function is typically going to have a template.yaml. Is that template.yaml CloudFormation code.Steph: [00:40:26] So at its core, yes. But the way you write it is different. So how it works is that the Sam templating language is defined to simplify. What you would with CloudFormation.So a CloudFormation you have to put a gazillion variables in.And it's like, there's some ways to like make that easier. Like I really like using a Python library called Tropo sphere, where you can actually use Python to generate your own cloud formation templates for you. And it's really nice just cause, you know, I like to know I'll need a loop for something or I'll need to like fetch a value from somewhere else.And it's great to have that kind of flexibility with it . The, the Sam template is specifically a transform, is what they call it, of cloud formation, which means that it executes against the CloudFormation service. So the CloudFormation service receives that kind of turns it into the core that it understands and executes on it.So at the core of it, it is executing on top of CloudFormation. You could create a mostly equivalent kind of CloudFormation template usually, but there's more to it. But there's a lot of just reasons why you would want to use Sam for serverless specifically, just because they add so many niceties and stuff around, you know, permissions management that you don't have to like think of as much and shortcuts and it's just a lot easier to deal with, which is a nice change.But the power of CloudFormation is that if you wanted to do something. That like maybe SAM didn't support the is outside the normal scope. You could just stick a CloudFormation resource definition in it and it would work the same way cause it's running against it. It's one of those services where people, sometimes it gets a bad rap because it's so complicated, but it's also super stable.It behaves in a super predictable way and it's just, I think learning how to use that when I worked at AWS was really valuable.Nate: [00:42:08] What tools do you use to manage the security when you're configuring these things? So earlier you mentioned IAM, which is a, I don't know what it stands for.Steph: [00:42:19] Identity and access management,Nate: [00:42:20] right?Which is like configuration language or configuration that we can configure, which accounts have access to certain resources. let me give you an example. One question I have is how do you make sure each system has the minimum level of permissions and what tools you use? So for example, I wrote this Lambda function a couple of weeks ago.Yeah. I was just following some tutorial and they said like, yeah, make sure that you create this IAM role as like one of the resources for launching this Lambda function, which I think they're like, that's great. But then like. How do I pin down the permissions when I'm granting that function itself permissions to grant new IAM roles. So it was like I basically just had to give it route permission according to my low, my skill level, because otherwise I wasn't able to. Create, I am roles without the authority to create new roles, which just seems like root permissions.Steph: [00:43:13] Yes. So there are some ways that's super risky, honestly, like super risky.Nate: [00:43:17] Yeah. I'm going to need your help,Steph: [00:43:19] but it is a thing that there are case you can, you can limit it down with the right kind of definition. SoIAM. It's really powerful. Right? So the original case behind a MRI was that, so you're a servers so that if you had a, an application server and a database server separately.You could give them separate IAM roles so that they could have different things they could do. Like you never really want your database server to maybe. Interface directly with, you know, an S three resource, but maybe you want your application server to do that or something. So it was nice because it really let you limit down the scope from a servers and you don't, cause you have to leave keys around if you do it .So you don't have to keep keys anywhere on the server if you're using IAM roles to access that stuff. So anytime you're storing like an AWS secret key on a server, or like in a Lambda, you kinda did something wrong. The thing they are just because that's, AWS doesn't really care about those keys. It just looks, is it a key?Do it here. But when you actually use IAM policies, you could say it has to be from this role. It has to be executed from, you know, this service. So it can make sure that it's Lambda or the one doing this, or is it somebody trying to assume Lambda credentials? Right? There's so much you can do to kind of limit it.With I am. So it was really good to like learn about that. And like all of the AWS certifications do focus on IAM specifically. So if anyone thinking about taking like an AWS certification course, a lot of them will introduce you to that and help a lot with understanding like how to use those correctly.But for what you talked about with you, like how do you deal with a function that passes, that creates a role for another function, right? What you would do in that kind of case is there's an idea of IAM paths. So basically you can give them like as namespacing for IAM permissions, right? So you can make a, I am role that can grant functions that can create roles .Only underneath its own namespace. Within its own path.Nate: [00:45:20] When you say namespaces, I mean did inherit permissions. But the parent permission has?Steph: [00:45:28] Depends. So it doesn't inherit itself. But like, let's say that I was making a build server . And my build server, we had to use a couple of different roles for different pieces of it. For different steps. Cause they used different services or something. So we would give it like the top level one of build. And then in my S3 bucket, I might say aloud upload for anyone whose path had built in it. So that's, that's the idea that you can limit on the other side, what is allowed.And so of course, it's one of the things where you want to by default blacklist as much as possible, and then white list what you can. But in reality it can be very hard to go through some of that stuff. So you just have to try to, wherever you can, just minimize the risk potential and understand what's the worst case that could happen if someone came in and was able to use these credentials for something.Amelia: [00:46:16] What are some of the other common things that people do wrong when they're new to AWS or DevOps?Steph: [00:46:22] One thing I see a lot is people treating the environment variables for Lambdas as if they were. Private, like secrets. So they think that if you put like an API key in through the environment variable that that's kind of like secure, but really like I worked in AWS support, anyone would be able to see that if they were helping you out in your account.So it's not really a secure way to do that. You would need to use a surface like secrets manager, or you'd have some kind of way to, you would encrypt it before you put it in and then the Lambda would decrypt it, right? So there's ways to get around that, but like using environment variables as if there were secure or storing.Secure things within your git repositories that get pushed to AWS is like a really big thing that should be avoided. And we said, what else did you ever own?Nate: [00:47:08] I'm pretty sure that I put an API key in mineSteph: [00:47:11] before. So yeah, no, it's one of the things people do, and it's one of those things that. A lot of people, you know, maybe nothing will go wrong and it's fine, but if you can just reduce the scope, then you don't have to worry about it.And it just makes things easier in the future.Amelia: [00:47:27] What are like the new hot things that are up and coming?Steph: [00:47:30] So I'd say that there's more and more kind of uses for Lambda at edge for like IOT integration, which is pretty cool. So basically Lambda editor. Is basically where you can process your lamb dos computers, basically, like, you know, like, just think of it as like raspberry pi.It's like that kind of type thing, right? So you could take asmall computer and you could put it like, you know, maybe where it doesn't have a completely like, consistent internet connection . So maybe if you're doing like a smart vending machine or something. Think of it like that. Then you could actually execute the Lambda logic directly there and deploy it to there and manage it from AWS whenever it does have like a network connection and then you can basically, it just reduces latency.A lot and let your coat and lets you test your code both like locally and then deploy it out. So it was really cool for like IOT stuff. There's been a lot of like tons of stuff happening in machine learning space on AWS too much for me to even keep on top of. But a lot of the stuff around Alexa voices is super cool, like a poly where you can just, if you play with your Alexa type thing before, it's cool, but you could just write a little Lambda program to actually generate, you know, whatever you want it to say in different accents, different voices on demand, and integrate it with your own thing, which is pretty cool. Like, I mean, I haven't had a super great use case for that yet, but it's fun to play with.Amelia: [00:48:48] I feel like a lot of the internet of things are like that.Steph: [00:48:52] Oh, they totally are. That they really are. But yeah, it's just one of the things you had to keep an eye out for. Sometimes the things that, for me, because I'm dealing so much with like enterprisey kind of stuff that excite me are not really exciting to other people cause it's like, yay, patching has a way to like lock it down to a specific version of this at this time.You know, it's like, it's like, it's not really exciting, but like, yeah.Nate: [00:49:14] And I think that's one of the things that's interesting talking to you is like I write web apps, I think of serverless from like a web app perspective, but it's like, Oh, I'm going to write an API that will let her know, fix my images on the way up or something.But a lot of the uses that you alluded to are like using serverless for managing, other parts of your infrastructure, they're like, you're using, you've got a monitor on some EC2 instance that sends out a cloud watch alert that like then responds in some other way, like within your infrastructure.So that's really interesting.Steph: [00:49:47] Yeah, no, that's, it's just been really valuable for us. And like I said, I mentioned the IAM stuff. That's what makes it all possible really.Amelia: [00:49:52] So this is totally unrelated, but I'm always curious how people got into DevOps, because I do a lot of front end development and I feel like.It's pretty easy to get into front end web development because a lot of people need websites. It's fairly easy to create a small website, so that's a really good gateway, but I've never like on the weekend when it to spin up a server or any of this,Steph: [00:50:19] honestly for me, a lot of it was like my first job in college.Like I was basically part-time tech support / sys admin. And I always loved L nuxi because, and the reason I got into Lennox in the first place is I realized that when I was in high school that I could get around a lot of the schools, like, you know, spy software that won't let you do fun stuff on the internet or with the software if you just use a live boot Linux USB.So part of it was just, I was using it. So, you know. Get around stuff, just curiosity about that kind of stuff . But when I got my first job, that's kind of like assist admin type thing. It kind of became a necessity. Because you know when you have limited resources, it was like me and like another part time person and one full time person and hundreds of people who we had to keep their email and everything.Working for them. It kind of becomes a necessity thing cause you realize that all the stuff that you have to do by hand back then, you can't keep track of it all. You can't keep it all secured for a few people. It's extremely hard. And so one way people dealt with that was, you know, offshoring or hiring people, other people to maintain it.But it was kind of cool at the time to realize that the same stuff I was learning in my CS program about programming. There's no reason I couldn't use that for my job, which was support and admin stuff. So, I think I got introduced to like chef, that was the first tool that I really, I was like, wow, this changes everything.You know, because you would write little Ruby files to do configuration management and then your servers would, you know, you run the chef agent to end, you know. You know, they'd all be configured exactly the same way. And it was testable. And there's all this really cool stuff you could do with chef that I, you know, I had been trying to play to do with like, you know, bash script or just normal Python scripts.But then chef kind of gave me that framework for it. And I got a job at AWS where one of the main components was supporting their AWS ops work stool, which was basically managed chef deployments. And so that was cool because then I learned about how does that work at super high scale. What are other things that people use?And right before I actually, you know, got my first job as a full time dev ops person was when they, they were releasing the beta for Lambda. So I was in the little private beta for AWS employees and we were all kind of just like, wow, this changes a lot. They'll make our jobs a lot easier, you know, in a way it will reduce the need for some of it.But we were so overloaded all the time. And I feel like a lot of people from a  perspective know what it feels like to be like. There's so much going on and you can't keep track of it all and you're overloaded all the time and you just want it to be clean and not have to touch it and to do less work at dev ops was kind of like the way forward.So that's really how I got into it.Amelia: [00:52:54] That's awesome. Another thing I keep hearing is that a lot of dev ops tests are slowly being automated. So how does the future of DevOps look if a lot of the things that we're doing by hand now will be automated in the future?Steph: [00:53:09] Well, see, the thing about dev ops is really, it's more of like a goal.It's an ideal. A lot of people, if they're dev ops purists and they'll tell you that it means it's having a culture where. There are not silos between developers and operations, and everyone knows how to deploy and everyone knows how to do everything. But really in reality, not everyone's a generalist.And being a generalist in some ways is kind of its own specialty, which is kind of how I feel about the DevOps role that you see. So I think we'll see that the dev ops role, people might go by different names for the same idea, which is. Basically reliability engineering, like Google has a whole book about site reliability engineering is the same kind of philosophy, right? It's you want to keep things running. You want to know where things are. You want to make things efficient from an infrastructure level. But the way that you do it is you use a lot of the same tools that developers use. So I think that we'll see tiles shift to like serverless architect is a big one that's coming up because that reliability engineering is big.And we may not see people say dev ops is their role as much, but I don't think the need for people who kind of specialize in like infrastructure and deployment and that kind of thing is going to go away. You might have to do more with less, right? Or there might be certain companies that just hire. A bunch of them, like Google and Amazon, right?They're pro still going to be a lot of people, but maybe they're not going to be working at your local place because if they're going to be working for the big people who actually develop the tools that are used for that resource. So I still think it's a great field and it might be getting a little harder to figure out where to enter in this because there's so much competition and attention around the tools and resources that people use, but it's still a really great field overall. And if you just learn, you know, serverless or Kubernetes or something that's big right now, you can start to branch out and it's still a really good place to kind of make a career.Nate: [00:54:59] Yeah. Kubernetes. Oh man, that's a whole nother podcast. We'll have to come back for that.Steph: [00:55:02] Oh, it is. It is.Nate: [00:55:04] So, Steph, tell us more about where we can learn more about you.Steph: [00:55:07] Yeah. So I have a book coming out.Nate: [00:55:10] Yes. Let's talk about the book.Steph: [00:55:12] Yeah. So I'm releasing a book called, Fullstack Serverless. See, I'm terrible.I should know exactly what the title, I don'tNate: [00:55:18] know exactly the title. . Yeah. Full stack. Python with serverless or full-stack serverless with Python,Steph: [00:55:27] full stack Python on Lambda.Nate: [00:55:29] Oh yeah. Lambda. Not serverless.Steph: [00:55:31] Yeah, that's correct. Python on Lambda. Right. And that book really has, it could take you from start to finish, to really understand.I think if you read this kind of book, if I, if I had read this before, like learning it, it wouldn't feel so maybe. Some people confusing or kind of like it's a black box that you don't know what's happening. Cause really at its core lambda that you can understand exactly everything that happens. It has a reason, you know it's running on infrastructure that's not too different from people who run infrastructure on Docker or something.Right. And the code that you write. Can be the same code that you might run on a server or on some other cloud provider. So the real things that I think that the book has that maybe kind of hard to find elsewhere is there's a lot of information about how do you do proper testing and deployment?How do you. Manage your secrets, so you aren't storing those in them in those environment variables. Correct. It has stuff about logging and monitoring, all the different ways that you can trigger Lambda. So API gateway, you know, that's a big one. But then I mentioned S3 and all those other ones. there's going to be examples of pretty much every way you can do that in that book.Stuff about optimizing cost and performance and stuff about using that. SAM, serverless application, a repository, so you can actually publish Lambdas and share them and even sell them if you want to. So it's really a start to finish everything you need to. If you want to have something that you create from scratch.In production. I don't think there's anything left out that you would need to know. I feel pretty confident about that.Nate: [00:57:04] It's great. I think one of the things I love about it is it's almost like the anti version of the docs, like when we talked about earlier that the docs cover every possible use case.This talks about like very specific, but like production use cases in a very approachable, like linear way. You know, even though you can find some tutorials online, maybe. Like you mentioned, they're not always accurate in terms of how you actually do or should do it, and so, yeah, I think your book so far has been really great in covering these production concerns in a linear way.All right. Well, Steph is great to have you.Steph: [00:57:37] Thank you for having me. It was, it was great talking to you both.

Resources:vcstarterkit Twitter / sumukh's TwitterAmelia's TwitterNate's TwitterWelcome to the newline podcast. Our show is a conversation with experienced software engineers where we discuss new technology, career advice, and help you be amazing at work.I'm Nate Murray and I'm Amelia Wattenberger and today we're talking with Sumukh Sridhara who is a product engineer on AngelList's Venture Capital Team and the hilarious personality behind @vcstarterkit.While many engineers work at startups or are interested in starting their own company, Venture Capital can seem like a total mystery.In this episode, we'll learn about:How venture capital firms functionHow VCs make money - and how that affects youRidiculous start-up ideasThe reality of raising moneywhether or not you even should raise money.We really enjoyed our conversation and I'm sure you will too. Let's dive in.

Resources:Eric's book, Security from ZeroEric's company, Brindle ConsultingEric's TwitterAmelia's TwitterNate's TwitterWelcome to the podcast. Our show is a conversation with experienced software engineers where we discuss new technology, career advice, and help you be amazing at work.I'm Nate Murray and I'm Amelia Wattenberger and today we're talking with ex-Google engineer Eric Higgins who is the founder of Brindle Consulting and co-author of the book Security from Zero.https://www.brindleco.com/In this episode we talk about how to think about security as developer and how to take the responsibility we have seriously. We talk about how to take a preventative and proactive approach to your security, and that means we cover:How to deal with extortion threats by having a bug bounty programHow to think about automation tools when it comes to securityWhat resources you should read if you want to get better at securityHow much does a web developer need to know about security, really?Eric has worked in security for a long time and he does a great job at being pragmatic to make sure the security goals are in line with the business goals. Amelia and I really enjoyed our conversation with Eric and I'm sure you will, too. Let's get started. Eric Higgins PodcastNate: [00:00:00] All right. So Eric, welcome to the show. Just kidding. Thanks for having me, Nate. Your company is brittle consulting, so tell us about it.Eric: [00:00:07] Brindle consulting. I basically help my clients who work in the tech sector and have customers, have been customers. They're profitable, but they've.Avoided working on security for a little bit too long, and now they are finally starting to realize that they have some problems that they need to address, and it's becoming overwhelming. So I help them create a very practical security program so they can start to address these things so that they stop from feeling like they're reacting to all this stuff and start taking some proactive approaches.Nate: [00:00:37] What kind of stage company are we talking about here? . On Bug BountiesEric: [00:00:39] the types of stages of clients that I thought I would get are very different than what I've actually had to work with.here's like the common denominator in all these  cases.Usually they'll start to get emails to a gall, have like a security@mycompany.com email address set up where people can report security issues and they. Inevitably, we'll start to receive these emails from security researchers. I'm quoting here, security researchers, and it's usually people who are running these scripts that look for common vulnerabilities against like somebody's website, and.They're basically trying to extort these companies for money to pay out because they don't have a bug bounty program in place. And what that really means is that they don't have a policy in place to say that for these types of vulnerabilities that we're willing to, pay, you'd report to us responsibly.This is how much we pay, right? And this is the rules by which this game is played. So they start to get overwhelmed because they constantly get hit by all these things or all these emails from these researchers, and they start to feel overwhelmed. And it gets to the point where the individuals who are responding to all these emails or all of these security related issues start to realize that like they can't get any of their normal work done because they're just buried in all these security related requests and they realize like it just like, and any other company for any other position, you need somebody to be doing this stuff so that you're not the one doing it. So then they come to me and they say, how do we avoid this problem? Maybe we're not at the stage yet where we can hire somebody to work on security full time for a variety of reasons, but maybe we can do some things to make sure that we don't feel like we're buried in this work and we're not constantly getting distracted from working on our product, but still making sure that we maintain a certain level of security and know how to respond when these things come up.Nate: [00:02:26]Yeah. I want to talk about the bug bounty programs a little bit. So going back, you're saying you used air quotes around security researchers.The implication is they're maybe not really researchers, but maybe they, what's the idea that they have, they're using automated scripts or something to find these vulnerabilities and they're just trying to. Collect bounties? Are they actually trying to say like, we found the security hole and we're going to exploit it.You don't pay us a ransom. What are you implying here?Eric: [00:02:49] So it's a little bit more of the former, I mean, I guess there's a hint of the ladder in there. So here's what I really mean by this. So not to admonish anyone, because I think that there, I mean, I know that there are a lot of real security researchers out there who play by the rules, but there's a certain class of individuals.And there seems to be a network of them that they tend to come from like third world countries or where they have internet access and like they're just looking for some way to make money. Right. So, you know, it's noble cause I suppose, but they specifically seem to target companies that don't have a published.Responsible disclosure policy. So responsible disclosure is really like the umbrella term for what a bug bounty policy is, or a bug bounty program. It's a way to report security issues to accompany in a responsible way, which is the opposite, would be like they just publish about it on like Reddit or hacker news or a blog or something and make it public to the world without telling you first.Right? So the old school mentality. Or approach to this that a lot of companies used to take was if you reported security issues to us, we would assume that you were a hacker and we would start to litigate against you, right? We would take you to court and Sue you cause you're hacking us. So that approach doesn't really work like that stupid and nobody should do it.And I have a firm position on that instead. The way that the landscape has shifted is now there's actually companies. In existence that will help you create and run above bounty program where it's an incentivized responsible disclosure program. That's what the bug bounty is. And you basically say, like for this class of security issues, we'll pay you X amount of dollars.So just to give you some examples. So Google I think has different classes of bounties that they'll pay out. And I think the highest is something like $100,000 and that's if you can find a security, like a major security issue in like the Chrome browser or Android operating system for their phones.Right? So there's a very high level of payout for very like deeply technical and like widely exploitable type of security issue. More commonly for like the class of companies that I work with, they'll have some kind of web application. It will be vulnerable to like SQL injection or something else. It's like relatively common that these, I would say the lower tier of security researchers, they're looking for all these low hanging fruit that they can run some kind of software and scan for these things and find them pretty quickly.Then they contact the companies by email and say, Hey, I thought all these issues, I would love to get paid for my work. So the problem with this is that there's, I guess a few problems with this. The first is like they're not really. Doing a lot of work, right? They're bringing it to your attention, which is great.But as soon as those companies, and this has happened to a number of my clients, as soon as you pay out with one of them, they tell all of their friends and their network that this company pays out. Then like you start to get inundated, you get pile on with all these security reports and they may have run the scan once and like are sharing all these different security issues with their friends so they can all kind of get paid.So it's a little problematic and it's problematic because. The companies haven't said, these are the rules and here's what we're willing to pay. So when it comes time to like reward these researchers who are reporting these issues, they don't have any guidelines to follow to save. This is how much we're going to pay for this type of vulnerability or this type of vulnerabilities out of scope.You can't stalk our employees on Facebook or LinkedIn and try to extort us for higher payment because you disagree with, because there's no written policy to say, these are what the rules are and we use what the payments are. That's kind of where they get stuck, right? Like they. Not having the policy in place is really like the key driver to this and these researchers, the air quote, researchers are starting to target those kinds of companies because they know that they can get payment and kind of extort them for a little bit higher.Nate: [00:06:21] What are the types of classes of like the tiers for the types of bugs that the people typically pay out for? And also who gets to decide? Is it just like the company gets to decide somewhat arbitrary early and they say, like we said, that if you find SQL injection, we'll pay out, you know, $1,000 or there are many cases where it's ambiguous what the actual vulnerability was.Eric: [00:06:40] I would say it used to be more ambiguous than it is now because bug bounty programs are. Much more prolific than they used to be. It's become almost standardized to say, like for this class of vulnerability, this is the payment tier we're going to pay out. So here's the common case. So it is set by the companies.To answer your direct question, the payment tiers are set by the company and usually goes along with what stage they're at and like what their financials look like. So they'll set some kind of a budget for the year to say, this is the max we want to pay for security issues through this bug bounty program for the year.So let's say it's. I don't know, $10,000 or $30,000 whatever it happens to be, it's usually pretty low around that ballpark. So then they can say, well, we're going to expect in the first year to get, based on our priors, however many we've had from these researchers, maybe twice that many, because now we're like publishing that this thing's available.So we'll expect it to see more for a specific. Type of vulnerability, like let's say it's low hanging fruit, you're using an older version of some Java script library. Then maybe has some kind of weird vulnerability in it or the vulnerability one, its dependencies or something like that, but the effects of that aren't very great.Like the impact isn't great to your web application. It just happens to be like, Oh, this isn't a best practice. The threat level is pretty low. So thanks for reporting it. Here's like $100 like so the lower end is usually like maybe a hundred bucks, something like that, maybe $50 it all depends on the company, what they decide to set.So at the higher end of the types of security vulnerabilities that the companies are looking for are things like remote code execution. Like you can. Fill out some form on our web application and somehow run code on our server that we didn't expect you to run. Or you can somehow access everything that's in our database so you're not supposed to be able to access.So the classes for security issues. Are fairly well documented. There's like, you know, five or six general categories they fall into, but it's really the level of impact that that security vulnerability that the reporting has and whether or not it can be reproduced and it's well documents and all of a sudden things kind of play into whether or not it's actually granted as a true vulnerability or a valid report.So the level of impact that the security issue has is being recorded usually ties directly to the level of payment. So, you know, a company that's first starting off, I usually recommend a couple of things. First.  your payment size pretty low, especially for the first year, because you're going to get a ton of low hanging fruit and you're not going to want to pay like $10,000 per whatever, weird JavaScript vulnerability that it's relatively low.So, so Kevin, pretty low for the first couple of years. And then the second piece of advice I usually give that they don't always follow is to use a managed bug bounty program. And what that means is you pay these companies who provide the software. It's almost like. I'll use get hub as an example, like their get hub.In this scenario, they're offering the software that hosts this bug bounty program. So that's where the security reports go to and are listed and are managed by teams of manage bug bounty program is where that company also provides. So their employees to review and triage the tickets and make sure that they're like written in the proper format, they're reproducible and all these things before they actually come to your teams.That really helps to reduce the amount of noise because especially at the very beginning, what you go public with, your bug bounty program. You tend to get a really, really  poor signal to noise ratio and you want to try and improve that level. So I usually set the caps pretty low, make sure it's managed for like the first year because you're going to have to manage all the noise and then as time goes on, you start to increase your budget, you increase the tiers, you can increase the scope, and if you hire people who can manage this thing, then maybe you don't have to pay that company, whatever they charge for somebody to manage it for you.Managed Bug Bounty ProgramsNate: [00:10:19] What are the major players in that space?  who are the companies that, or maybe  the defaults to go to?Eric: [00:10:25] The two main ones right now at the time of recording our hacker one and the other is called bug crowd. For all intents and purposes, they offer nearly the exact same services. Their marketing material in their sales team will tell you that there is slight differences between them and there are, there are some differences.There's differences for the types of integrations their software provides. They'll tell you that there's a different number of. Security researchers in their platform, and in a lot of ways it's very similar to Uber versus Lyft. Hacker one was first in the same way that the Uber was first and Lyft came later.Same is true. Both crowded came later, and also in that same way, I would say that based on my experience, hacker one is a little bit more aggressive with like their sales and marketing techniques. In the same way that Uber is a little bit more aggressive with their sales and marketing techniques. That being said, it work successfully with both these companies.I'm not trying to like bash any of them by making a negative correlation between any of these companies based on, you know, whatever your predilections happened to be about Uber and Lyft. So those are the main players. Now, interestingly. At my previous role at Optimizely, we use a company called Cobolt who also did, or also offered a bug bounty program as software package, like  as a service.And recently when I reached out to them to see if they're still doing this, they have transitioned away from that model and more towards almost like an automated model where it's. They scan your systems from the inside and try and look for these vulnerabilities. At least that's the way that I am remembering my understanding of it.It seemed kind of complicated and expensive when I talked to them. Maybe it's a great product, but it was interesting that they had completely pivoted away from the previous model where they were kind of competing with hacker one and bug crowd to something that's completely new. The Role of Automation in the Future of Cyber SecurityAmelia: [00:12:01] How much of this space do you think is going to be automated in the next few 10 years?Eric: [00:12:06] So my background, I should clarify, is as a software developer, so I tried to think of the question of automation in terms of a software developer, like what's possible to automate. And I'm like, what should be automated? So, so this is actually a really interesting question because I've started to see in the last couple of years a lot more tools that.Offer automation for all these kinds of problems. Like the security space is just like one aspect of this, and I'm sure that like, you know, by next year we're going to have all kinds of crazy blockchain distributed Kubernetes, AI driven security tools that are out there trying to sell us products.Whether or not they work, I think is a different question. And if you think about the last few years, like there was this huge push like, Oh man, machine learning is going to solve all these problems for us and is going to solve all these problems for us. And then a couple of years later people start to realize like, Oh, you machine learning is a cool tool for a specific set of problems, like finding patterns and making sure that you're including things in the same kind of pattern.So more for AI. Like there's certain things that they're really good at, but it is not like general AI. Like it doesn't. Do all of the things that a human being can do very simply. So you have to kind of back away from that. And like we've started to see people sort of backing away from these like very grandiose claims about what those things can do or what they're capable of.So I think to answer your question, I think the same is really true as it currently stands for security software. There's a lot of companies who are offering crazy AI driven, automated tools to do all these things, but whether or not they actually do the things they say, like I think is a different question.And. It's really up to the companies buying whether or not they want to go through a pilot program and see if it works for them. What are they willing to pay for it? I think fundamentally, the question for any kind of software as a service comes down to what am I paying for this and how does that correlate to the number of employees that I would normally have to hire to do that job?Right? Are they automating something that. Is easy to automate that we could do ourselves. Like is it, you know, just trying to match them patterns that we know and like could just add a filter to Splunk or whatever logging software we have, or they're doing something more advanced where we're like, we would have to build out a huge crazy complex platform, two ingress, all this data and then, you know, run a bunch of code against it to find like weird patterns that we would not normally see.How much time does that save us? Not only like at the initial, but also like over the longterm. And I think the same answer is true for a lot of software as a service. Like if you're going to charge a company $30,000 a year for software, but it would cost them an engineer. Per year to do that same job, like an engineer is going to cost them $100,000 or more.So they're saving a ton of money by using the software instead of hiring an engineer to do that job. So maybe that's a roundabout way of answering your question, but like that's the way that I think about these things. I don't have a lot of firsthand experience with a lot of the newer automation tools that are coming out.Maybe they're great. Maybe they're junk. I mean, I haven't seen evidence in either direction yet, but my gut reaction to me, I've just like worked in security too long, so I'm always like a little bit skeptical. I'm usually pretty skeptical about what they're offering, like whether or not it's worth the price that they're asking.How You Detect HacksNate: [00:15:03] You mentioned  using Splunk to  track logs and to find abnormal behavior. One of the things that I've noticed when I've seen blog posts about security incidents, they might say, you know, we had an employee who had their admin panel password hacked and the attacker had access to all these accounts for like three days and you know, we were able to track them down and shut them down. What tools would you use to actually detect that? Because for pretty much every company I've worked for, if a hacker got access to an admin's password, no one would ever know, like ever. Like we would never find out that that had happened.So like what tools and processes and monitoring do you put in place to catch something like that?Eric: [00:15:46] You opened that really interesting can of worms. And here's why. So the question that you asked is how do you detect this? Which. In the question itself, you're already telling me that it's too late because it's already happened.So this is really the type of thing that I focus on with my clients is How do you prevent this from happening? How do you make sure this doesn't happen? Because if you can make sure that it never happens or is nearly impossible to happen, or is such a great burden for an attacker. To go after that approach.They're going to do something else. They're going to do something that's easier instead so then like, maybe you don't need a crazy monitoring solution for this kind of hard problem in place because even if you had it now, you know it's too late. They already have it. Right? So how long would it take them if they had ad admin access to your systems to copy all that data?Right? Even if you can shut them out, maybe it took them 30 seconds and like it took 30 seconds just for you to get that email and read it. And they already have your data, so it's too late. Right. So I would rephrase the thought process too. How do you prevent these things from happening in the first place so that you don't have to worry about like, Oh my God, like what are we going to do if this happens?Cause that's a much harder problem. So I focused on the easy thing. So the easy thing is how do you keep people out of the admin. Handle it, of your systems to have access to everything. And just as a preface, I want to point out that I think a lot of my clients and a lot of people I talked to tend to think that attackers are going to try and go through your web application or your mobile application to try and hack your company.But that's a pretty limited approach. And I think threat actors in the space have already started to realize this. So the targets that they're choosing instead are developer machines or developer systems. So. If you have Jenkins running all your CIC CD systems, your continuous integration, continuous deployment, that system probably has keys for all of your servers as keys for all your source code.It probably has rewrite access to your database. It probably has admin level access to everything so that it isn't blocked. So that's a really ripe target. And usually when people set up. The systems, like they just set it up just to the point where it's working, but not necessarily secure. Right. And it's just like an admin.Yeah. Right. It's very common. And that's the thing. And that's kind of the reason, the realization I had when I started consulting is that everybody has the same problems. Everybody's making the same mistakes. So there's a pattern that's pretty easy to solve for in, it's really just a matter of education.So that's kind of what I focus on. So getting back to the question of how do you prevent this from happening. There's a variety of ways, like the easy one that I usually recommend is for anything that requires admin level access. I review who has access to it with my clients and say, do all of these people actually need admin level access on a day to day basis for their jobs?Often the answer's no. Right? There might be a couple people who day to day need admin level access to do their jobs in whatever that system happens to be. For everyone else, they can get a lower level. Admin privilege or whatever it happens to be, or lower level permission. But I admin like they don't need rewrite access to literally everything.So that's the first thing I focused on is who has access to this and this. So this model is called least privilege. So you're offering the least privilege to most people by default. So that one comes up a lot, right? And then the second thing is for the people who have admin access or any access at all, can you enable some type of multifactor off like two factor auth using, you know, the Google authenticator on your phone or like a YubiKey or some other kind of system to make sure that even if your admin password was published on the internet, nobody could really do anything with it.There's something else preventing them from logging in. Just those two things like limiting who has access to admin levels in systems. Enabling multi-factor off. Get you most of the way there. Like you're almost to the point where like it is a really hard target now to get into those systems. Now I could kind of fearmonger you and say like, well, you know, it's an had been a little system in like the person who's the admin is kind of sloppy and they set up SMS for their two factor auth instead of like a, you know, authentication app and maybe their phone gets spooked and now like it's possible it's a compromise that there's all these weird ways to kind of work around these things, but it's a much higher bar.Than it was before where maybe laptop got stolen, right? Or like somebody just like look over their shoulder and saw them log in, or you know, maybe they like sniff their cookie or something like that, and then now they have access to this system. So it raises the bar for that kind of thing just by putting these preventative measures in place.But to answer your question more directly, which was. How do you know about these things after the fact? Normally, any types of systems that have admin paddles, not always, but they will often offer some kind of like auditing system when it, any kind of administrator logs in, it will keep a separate log for all the actions of that person.So click, who logged in, where do they log in from? Like in the world, what was their IP address? What actions did they perform? So if you are talking about like the AWS. Council or like the Google cloud console, they usually offer this kind of system. I think Splunk does as well. So this gives you a couple of things, like you've prevented the ability or not the ability, but you've raised the bar for getting access to these admin systems, or if you've made it much harder to get in, and you also have some kind of system in place to say like for anybody that's in there.What are they doing? Like do  we have some kind of record for what actions have been performed so that we know that if somehow one of those logins were compromised, we have some record of what actually took place act that happened. So hopefully that helps to answer your question. That gives you a little bit more insight into like the kind of things I'd be looking for.Amelia: [00:21:03] It kinda sounds like there is no incentive for actually monitoring the logs.Like you can only get bad news that you can't act on. So if I were a little bit more nefarious, I might just never look atthem.Eric: [00:21:16] That's a good point to bring up. I would say that it depends on the logs you're talking about. If we're talking about like the audit logs that are considered any action that is contained within Ottawa, we assume that it's somebody internal to our company, like somebody who should have access to this, except for the worst case where maybe somebody.Shouldn't have access, does have access to like they're doing something weird. Right? So the audit logs are, they're definitely going to be reactive in the, in that case. But if you think about logging more generally, like if you think about your server logs for your website, right? That actually can be a good leading indicator that an attack.Might be happening or somebody probing your systems. So you can look for all kinds of interesting things in your logs. You can look at like the login page, like all the login URLs and see like is one IP address trying a bunch of different logins and failing? Are they trying one login? And it's constantly feeling like they're trying to brute for somebody's password.So there's a lot of things you can do and get a signal that like. An attack is happening and understand what they're trying to attack in your systems just by looking at the log in without actually having been compromised. So let's say the, in that more general case, you're getting a leading indicator instead of a trailing indicator.So I think both of the things you said are true, but I think it depends on the system that you're talking about.Nate: [00:22:32] Looking at the logs after an attack is sort of reactive. Taking more proactive steps of making sure that you review who has admin access in your review that everyone has two factor auth.That's more of like a proactive approach. Would that fall under the more general umbrella of threat modeling?  we're looking at this and saying, okay, how could we get attacked? We could be attacked by one of our employees losing their credentials somehow, or leaking their credentials. What are some of the other things we might look at to have a process to prevent things before they happen.Eric: [00:23:02] Oh, this is a great question and I'm glad that you brought up threat modeling. So threat modeling is an exercise, and by far, what are the best values for getting the most information to the least amount of time that I do with my clients. So I want to try to explain threat modeling to help you wrap your head around it and like give you some examples like what it is and what it means.It'll help you to answer this question for yourself and the way that you would sort of like think about. The general problem, which is like we have this system in place. What could possibly go wrong with it? Which is the shortest version of like what threat modeling is. So here's the most simple real world example of threat modeling, let's say, and this is something that people do on a day to day basis.So here's a simple example, like you want to go out to lunch from work. And meet up with a friend for lunch right now. There's a lot of considerations that your mind processes before you actually go out to lunch. Is it raining? Do I need to take an umbrella? Right? The thing that could go wrong is like, am I going to get rained on the preventative measures?Like, do I need a rain jacket? Do I need an umbrella or. Another thing that comes up is like, you know, are there any dietary restrictions I have to keep in mind for myself or the person I'm going out to lunch with. If there are like, how are we going to resolve that? Where are we going to choose to go to lunch?Do I have to be back at exactly one o'clock for a meeting with my boss and I can't be late? Like we can't go somewhere that's too far away. So it's really, this is this process by which you think about problems and think about all the different things that could possibly go wrong and then come up with.Different ways of solving them so that you avoid as many of those problems as possible. Now, some of the risks are. You don't want to get caught in like analysis process where you think like, Oh my God, whatever we're trying to do, there are so many things that could go wrong. Like maybe we should just not do it.My advice is to say like the approaches you take is usually the one that has the most pros and the fewest cons rather than no cons cause you'll just never get anything done. If you try and take that approach for threat modeling as it applies to security and it applies to software. Let's think about.Something that's a little bit more practical than like going out to lunch. So let's say we have. I dunno, a basic software system. There's some kind of web application running in production. It has a database somewhere, and we want to say like, what could possibly go wrong with this? Like how could it be compromised or abused?So the approach for this exercise is you get a bunch of. People who work at your company or work with you on this project in the same room together and you just have that conversation. Like I usually start with a different question though. I say like, what are the biggest risks for our company? What could really just ruin us or like put us in a bad situation?And it might be, we've got a lot of really bad PR at this point. We would really struggle to recover from it because we lose a lot of customer trust. We'd end up on the front page of the New York times with all this negative press, and like it would really hurt our brand and they'd go to our competitors and said, so that might be the worst case scenario.So like, how would an attacker. Compromise you in such a way that would make it a really bad PR campaign. Or it could be like, we have a lot of this really sensitive data in the database, like maybe it's personally identifiable information, PII, like people's credit card numbers, or it's their address along with their names and email addresses.All this stuff. Like we cannot allow this data to get leaked because like our customers, again, like they wouldn't trust us. It'd be a huge problem for our company. Going forward. And that's a hard problem to recover from. Like once I data's out on the internet, you can't unleash information. Like that's a hard one to recover from.So you really have to think about how you can prevent it in the first place. Similar to the problem of admin credentials, like after it's done, it's too late, right? You enough solve these problems before it's too late. So just to give you a third one, like maybe the worst case scenario for our company is.Financial, right? What would happen if these attackers got access to our bank accounts? Or you know, maybe we deal in like Bitcoin. Like what if people like could somehow compromise our system and like steal everybody's money. So that would also be problematic. So there's all these different scenarios you could think about that would be worst case scenarios or maybe like, not necessarily worst case, totally disaster, but like hard recover from problems.And then you think about like what ways would an attacker or a malicious actor. Achieve that goal based on everything that we know about how our systems and our software works today. And sometimes this goes beyond. Again, like as I said before, it isn't just your web application or just how your database works.It could be something much more sinister, like maybe you have. A bunch of laptops and people who work from home work from cafes, like you know, Starbucks and a laptop gets stolen and that laptop belonged to a cofounder and the drive wasn't encrypted. Right? So now an attacker like who stole this laptop?Maybe they didn't know what they stole, but they find out and now they have access to the bank account information and login four, your company's bank. Like it's a bad scenario. So how do you prevent that kind of thing from happening? Or maybe something else, like how would they get admin access to one of our systems?Can we prevent that in some way? So it's this way of sort of thinking about the problem and preventing it in advance. And then once you leave, you should have a list, Oh, here's all the things that an attacker could do. And it normally boils down into like a handful of very common things, like all these different threads of attacks.Have you a few things in common, like, you know. We don't have to factor off the Naval, not on all these systems, really, too many people have access to it or drives aren't encrypted or whatever it happens to be. It's usually a handful of things that are common amongst all those attacks. And those are the things that you focus on fixing first because you, I fixed one thing that solves three possible tax, right?So you're really like getting a great value for the time that you're spending and you're also focusing on the right problems instead of like the things that might happen. Maybe like it's a low. Likelihood and maybe low impact if they do happen. Like that's not really where you want to spend your time.You want to focus on the things that are potentially big problems for your company and take the least amount of effort to achieve. So hopefully that helps to answer the question. I would say that the one other thing about threat modeling is, I can give you a recent example from the news where like this kind of went horribly wrong.So I think this was maybe last year. There is a company called Strava who does like fitness trackers. The way that struggle works is like people attach them like a Fitbit and they run around it. It maps out like everywhere they run. So then like the people who were running King see where they ran, what their route was, and then they can keep track of their miles, which is great.But the other thing that Strava did was it would. Publish on a public map everywhere that you were running, which, you know, privacy concerns start to bubble up with this, but people start having fun with it, right? They start drawing like the Nike swoosh with their running patterns, or they draw, you know, spaceships or Darth Vader or tie fighters and all this stuff.People will start to do this more and more, and like this feature gets really popular. But the other thing that happens is that the U S military has soldiers. Who are using these fitness trackers while they're exercising, but they're doing it secret bases around the world. And now you look at Strava map and you have all these little hotspots that show up in the middle of Africa, or you know, somewhere where there's nothing else.And there's this little tiny hotspot and. The effect is that Strava has just now leaked the specific locations of all these secret us military bases around the world. So huge problem, right? How do they not think about this in advance? This ends up on the front page of the New York times, you know, Strava leaks, location of all these secret us military bases.If your Garmin, a competitors' Strava who offers nearly the identical product and has the same problem, you might think like we really dodged a bullet. Because we're not on the front page of the New York times. But three days later or whatever it happened to be like they also were, because they had the exact same issue.It's kind of interesting to me that like they didn't immediately like, we need to fix this now. I'm like, delete this from the internet so that we're not also caught in the same place, but it just goes to show that. I don't know what the root cause was that they both ended up having the exact same problem where they didn't think about what the consequences were, their actions.A more lighthearted example through our modeling is the Boaty McBoatface example. So there is this like online voting system in the UK where they're going to name some military ship or whatever happened to be, and the top voted ship name by far is. Boaty McBoatface right. And really like that's kind of an abuse of the platform.Those weren't the answers that they were hoping to get, but is the answers that they got, what the mitigations were for preventing that? Like maybe the consequences weren't that great for Boaty McBoatface but the consequences for leaking the secret location view as how us military bases is pretty high by comparison.So you have to think of these abuse patterns in addition to how could we actually be hacked. Like Strava wasn't hacked. They like leaked this information out because like. Like the system was working as designed by, it was a use case they hadn't thought about in advance and it was like it published on by default, I assume.So anyway, like those are just some simple examples of threat modeling and like the ways to think about these things from a larger perspective. And I think the last thing I would say about through modeling is it depends who you invite. To this meeting where you conducted the right modeling exercise.Because if I were to ask a database engineer, what's the worst thing that could happen to your company? A database engineer is going to tell you all about the worst things that can happen to their database. Cause like that's their world. So the best person to ask this question to and is usually somebody in executive leadership because they're going to have the best perspective.I'm like. What the company I'd a broader vision is doing, like what the real business risks are. They don't necessarily have to attend a meeting and hear all the nitty gritty details about how the database works with the web application works or two factor off, but they should provide those initial answers to the question of like, what's the worst case scenario for our company?And then everyone else who's more technical can think about their own systems. Either it. You know, managing all the laptops of the company or the database engineer, managing all the data storage systems or the web application engineer running all the Node.js Or Python code. Whatever happens, all those people should have one representative in the room to think about their own systems and how it can contribute to the threat modeling exercise.Security in Today's WebAmelia: [00:32:48] I feel like your examples have highlighted something about how the web itself has evolved over. I don't know, the past 30 years where it used to be this scrappy connection of people in different parts of the world and we get to do weird things and it's all fun and lighthearted and now it feels like we have to grow up because we can't just have fun anymore.People will use our fun.Yeah.Eric: [00:33:14] That's a really interesting way to phrase that. Arguably, fun has always been profitable to some degree, but I think we're not quite as carefree as we once were. It's certainly true that the old internet, as I remember it, like there were still plenty of problems, like security problems, the ability to really like.Make widespread chaos and the old school internet was much harder. And like there's a lot of ways I could speculate or reasons. I can speculate why that's true or more true now than it used to be. So one is like the way that you phrase it was like it was a bunch of small little interconnected websites, right?Like maybe people were hosting on their servers and like when they turn their computer off at night, that website went down until like the next morning when they turned it backAmelia: [00:33:55] on, the store is closed.Yeah.Eric: [00:33:57] The store is closed. Exactly like. And I've had that experience plenty of times when I've seen that for a website I was looking at at 3:00 AM, but now if you think about it, because of the way the industry has grown in evolves, there's servers run all the time and it's cheap.I mean, it's practically free to run a web service. And most of them, a lot of them are consolidated on three major platforms. . AWS and Google cloud, and they're on all the time. And you know, if there happens to be a fundamental security flaw in Google cloud or AWS or Azure, that affects almost everybody, right?And we've seen this come up a few times, I would say like the last seven years. So, you know, when I worked to optimize the is when we had. A number of industry-wide security vulnerabilities come to light. So Heartbleed was one of them. Shell shock was another, and if you were working at the time in the industry, you probably remember like it was all hands on deck.We had to patch all of our systems in like prevent this because the fundamental problem, these cases was that in some version of bashes insecure Nick, you could compromise it remotely. And then the other one was, there was some kind of. Underlying security vulnerability with open SSL, which is the library used by like every Linux server, which is most of the servers on the planet.And this is a huge problem. So everyone had to go out and like patch all servers the exact same time. So for a couple of weeks during these periods of time, nobody was writing code. Everyone is trying to patch their systems to make sure that they weren't the ones that were hacked. And the other thing that is.Also happened is not just that the targets have sort of like shifted from being, well, I could compromise this computer, but it's like off from midnight until 5:00 AM it's just one computer. Right? But now it can compromise all these computers. Right? So the, the targets are much bigger because connectivity has improved.The sharing of information has improved, which is like by far has. More positive effects than it has negative, like there's GitHub and all these ways to share code. But now like the things that can also be shared are, here's a tool called  that allows you to just click on button in, like run some kind of crazy massive attack.Or here's the source code for the myriad worm, which shut off most of the internet. And when was this like 2015 I can't remember exactly. So they can share the, the nasty code, the dangerous code, as well as like the good code that, you know, people write day to day. And I think for the most part, people just want to do the right thing, but there's always going to be malicious actors out there.And it's certainly true that like now they have easier access to some of these tools and it's problematic. But. The good news is that everyone's getting smarter about security. They understand what the attacks are as technology improves, like the attacks, the types of attacks are going to also like mature and evolve with technology, but people are more wise to it now.As has always been true of history, we learned from the mistakes of our past, or at least we should, and hopefully like the technology we build tomorrow is better than the technology we built yesterday. How much should a responsible Web Developer know about security?Amelia: [00:36:51] I bet your experience of these attacks is a very different experience than the experience I as a software developer has.So when Heartbleed came out, I remember all I knew was it's a big deal. We're freaking out and everybody should be upset,Eric: [00:37:08] andAmelia: [00:37:09] maybe I can spend three hours reading up about it to try to understand. So as a software developer who doesn't work in security. How much should I know about security? What are some basic things that I know and how does that differ from, say someone who isn't a software developer?Do they need to know anything.Eric: [00:37:27] Oh, these are both excellent questions and thanks for sharing your experience about Heartbleed. I just want to clarify the, at that time I had a lot of different roles. What I worked to optimize the and security is just like one small portion of that. All of the things I had to focus my time on.And it was really like a group effort of everyone coming together at the company, all the engineers and it professionals to come together as this sort of like make sure that we did the right thing and patch our systems and like communicated to everyone that.  patch things as quickly as we could and to the best of our knowledge, like nothing was compromised.So I think we did everything we could in that situation. We worked as a team to kind of solve the problem. Just like you said, it was kind of pants on fire, like everybody knew, like, Oh my God, this is everyone. It isn't just like some companies, it's everyone except for the few people out there who run Microsoft based servers out there.I'm sure they're laughing at us, but that's okay. We get to laugh at them the rest of the time, I would say. Yeah. So your question was, what should you think about as a software developer about security. On a maybe a regular basis or how do you learn more is, am I remembering correctly? Yeah.Amelia: [00:38:26] How much do I need to know?Like how much should I feel responsible to understand?Eric: [00:38:31] I would say that my general advice, which is less specific about security, is. Take in as much information as you're comfortable with, like, you know, read some more diverse sources. Like I think it's common for, for engineers, especially those who are like just starting out to really focus on how do I write better code.Like that's the one thing they kind of focus on is like, how do I write the best possible code? Like how can I learn all these interesting coding design patterns and like make my code run faster and like have fewer bugs. And I would say that the more diverse sources you can read, the better you'll be at your job on the whole.So. Here's some examples, like try to understand the perspective of like the product and program managers at your company or like the marketing departments. What is their job look like or the support team, what does their job look like? What kind of questions are they getting from your customers on the support team?How are they helping the customers? Like what does that system look like? How do they do their jobs? Do they have to provide technical support? And some companies I've worked at. We were allowed to sit on sales calls like with potential customers and just sit there and listen to the concerns, sometimes security concerns, but sometimes just like the product concerns about from potential customers.We could also sit in on calls with customer, like existing customers in here about their problems. And it really helps to like understand your perspective or a change of perspective to understand their perspective about like, you know, what are the things that actually concern them cause they're going to be different than what you assume they are.Which I think really helps. As far as security goes. Like the same thing is true if you have the opportunity to participate in your company's security program, if they have one, I would say the right way for a company to run a security program is one that's inclusive instead of exclusive, which is to say that like you have office hours, you invite people to join and participate.Instead of saying like security is our world. And like, we're trying to protect you. Just stay back and let us do our jobs. Right? I vehemently disagree with that approach by disagree with this exclusive approach where like they played the new sheriff in town to like, they're trying to protect everybody and no one else can really play the game because it, it has a number of problems with the main two that come to mind right now are nobody likes to be told what to do.They like to understand what they're being asked to do. They can comprehend like, okay, there is a good reason why I have to do this other work instead of like Joe over and it just like, you have to do this, whatever security thing is now. Like that's annoying. Okay. I guess I'll do it. Cause they wrote a new policy.And the other thing is that. By being inclusive, it helps to spread like education and awareness about security. So for example, if you worked at a company, they had an inclusive, you know, anybody contribute security program, you would probably have the opportunity to go in and maybe participate in the threat modeling exercise and you'd have a better understanding for like, you know, what are the threats our company actually faces?Which might inform you later on if you're creating a new feature or a new product for that company. Oh, I know that. If I, you know, create this web service, these are the kinds of threats that. It might face, cause you've experienced that threat modeling exercise before. So I know that I can't use X, Y, and Z type of database.I don't know. Just some random stupid example. So it's really just about like getting. More information in your mind, in a different perspectives in your mind, in all of this stuff will not necessarily be immediately useful. It'll just be one of those things like that later in your life it'll become apparent like, Oh man, I'm so glad that like I participated in that and I'm so glad I learned that thing.Cause like now it actually makes sense and I finally get it. So I would say like I could point you to several different security related blogs and you know, newsletters and Twitter accounts and all this stuff, but you're just going to get so inundated with all these like. Technical details and it's going to drag you down mentally.Cause a lot of them are just like aggregators for like, here's another company that got breached and here's how they got breached and you're going to think that the world is falling apart. I would say that like that's not going to like bring up your spirits about security and like the state of the world.So instead I would focus on like the things that you can learn in your most local community, your local environment. So if your company doesn't have a security program, there might be a local Oh wasp chapter. So ops is like a open security organization. They're around the world. Most cities have like some kind of local chapter.I know the here in Portland, there's like monthly meetings you can go and attend. They usually have some kind of like guest speaker who will give a talk about some thing related to security. So I think engaging those types of communities can be really beneficial as well. You know, if you want to, the other thing you could do is just like attend a security conference.I wouldn't necessarily, I recommend starting with black hat or Devcon in Las Vegas. Those are very intense and very like, I would say deeply technical and like. Culturally heavy. I would say that there's something a little bit more lightweight though. It'd be beneficial. Like if you went to a JavaScript conference and like somebody was talking about JavaScript security, attend that talk, see what you can learn.I think they would probably help you on a more on a day to day basis and going head first into like the deep rabbit hole of security.Amelia: [00:43:14] Right. Don't start with the black diamond ski slope.Eric: [00:43:18] Right? Exactly. Exactly. That's a great analogy. I don't ski, but I get the reference.Amelia: [00:43:23] I also love your answer because I realize that as a front end developer, I don't have to worry about what other people within my company know.Whereas within security. I feel like you have to worry about your coworkers, whether they open a malicious email or the security could be attacked through people, which I think I would find terrifying.Eric: [00:43:46] It's certainly true. So as far as like the nasty email example that you gave, that's such a great one.And like I've seen this firsthand where emails were sent to a company I worked for, there were spooks, so it looked like a legitimate email from one of my coworkers. It looked like any other. Email that you would get if they were like sharing a Google doc with you, right? It would say like, here's the name of the stock.Whatever happens to be in, there's a link in the email and you click on it, you open it. But the clever thing about it, there's two, like the one is like spoofing their email addresses, which is not technically challenging. It's pretty trivial. There's a few things you can do to mitigate that. The clever bit was.They make it look like a legitimate email. We're like, nobody would really be the wiser on a day to day basis. But you open it, you click on the link and it takes you to a page that looks exactly like the modern Google walkin. So now if you type in your password. They have your password and they know your email address.So it's a pretty clever way to fish people and they can get a whole bunch of logins and passwords relatively easily. And I think the other thing that you do that's kind of clever is they've gotten wise, they're not running from their home. Machines, like all these web servers and stuff they have to run are these scripts that they use to target different companies or servers.They just run them on like compromise AWS accounts. So you can't black list like the IP addresses for AWS because then all of your code shuts off. Right. So it's pretty clever the way that they're kind of using the same systems that we use to the right, normal white hat code. As far as your, the concern about, you know, if you work in security, you have to worry about everyone.I think that's true. Like you're going to be worried a lot like, but that's your job. Your job is to be the one worrying so that other people don't have to. But that's kind of the motivating factor. Like if it's keeping you awake at night, then that should lead you into action and like to do something to make sure that that one thing can't happen.So you can spend your nights being awake, worrying about something else, and maybe you can't control. Right. And then you think, you know, if I can't control this thing, what can I do.How Do We Think About Security and New Hardware?Amelia: [00:45:43] So you mentioned this  example before, which is smartwatches, which haven't been around for that long. How much do you have to keep up to date with new technology? Like we have Google homes and our houses and their smartwatches, and there's something new every year.How much do you worry about new devices that come out or have to keep up to date with new tech?Eric: [00:46:05] Maybe you have a Google home in your house, but I don't have one in mind. Well, I guess there's a lot I could say on this, and I'll try and keep it. More succinct. So at a philosophical level, the same problems always persist in the security threats.Simply follow along and mature and evolve with the technological changes that we have. If you had a computer before and you didn't have an iPhone or you know, a smart home, there is still possibility that like your computer could be compromised remotely and the camera could be taken over. The microphone could be taken over and that could lead to.Some kind of disastrous result for you and I, the day to day, like that's not that big of a deal. Like if our computer gets compromised, like, okay, like what's really the worst case cap? If they see me okay. I don't often sit naked in front of my computer, but even if I did, like nobody really is going to want anything to do with that.Let me give another example though. The risks are much higher in the federal government in the Pentagon. They have a policy where if you go into a conference room, you cannot bring a cell phone. You cannot bring a laptop, you can't bring anything that has the ability to record information and has a battery in it or transmit information.It has a battery. Like that's the policy. What that means is. Is that if you want to give a presentation at the Pentagon, you have to print out all of the slides for your presentation on paper and then give a copy of that to every attendee that's in the meeting, and then at the end of the meeting, those all have to get shredded securely.I know this because I have a friend who works in the Pentagon one day. This person who was like. Very concerned because they had to give a presentation the next day. I think it was like right after, right before the government shutdown, all of the printers at the Pentagon, which is the only place they were allowed to print off these classified documents.All the printers at the Pentagon were out of ink. So how do they give their presentation? Right? So it's weird problems that you take on for the sake of security, where for the sake of national security, you can't take any kind of these types of devices that we take for granted. Like, you know, if you. Told somebody in Silicon Valley that you had to print off a proper presentation.They couldn't bring their laptops and phones into a meeting. You would get fired. They would think you're crazy and like kick you out of the company probably, or just tell you that you're paranoid. So I used to live in DC and I worked in a similar environment that, so for me, like having lived on both coasts and in both of the DC area, then also in Silicon Valley, the differences are so stark.It's really crazy. But it also goes to show like. The vast differences are the vast levels of security that people take on based on the level of risk. So I would say like that's the fundamental thing to keep in mind is what are the risks that you want to avoid if you're going to like enable internet of things devices in your home.I may not have a Google home in my house, but I do have a nest thermostat. And I know that the nest thermostat doesn't have a microphone in it and like, you know, could it be compromised remotely? Probably we're going to do make it too hot or cold in my house. Big deal. Right? But it's a nest thermostat is so much better than like a non nest thermostat.They're like, why would I not have a net service set? There's so great. Just a couple of days ago, the ring doorbell company, like it was published that there was like, these podcasts are so like taking over people's ring doorbells in their house and like harassing people across the country. With the ring doorbells.Right. Which is crazy. So I don't have a ring doorbell because I know that their security is pretty low. And that's really the problem with the internet of things stuff, is that they want to make these things cheap, which means they have to compromise on something. And the one thing they usually compromise is the security of their product.And that's actually how the myriad worm spread is. They didn't pay for a bunch of servers that had really high bandwidth. They compromised a bunch of internet of things devices and use them like a swarm to take down like internet servers around the world, which is crazy. It was just like people's cameras and stuff in their houses.They use it as like a zombie to like send more traffic to things. Those are the kinds of things I think about. Like, you know, you could have those things, no big deal, but just be aware of what the risks are and whether or not you trust the company behind the device that you were just right.Amelia: [00:50:00] It seems like it's so as a trade off between convenience.And money and security.Eric: [00:50:05] I'm glad that you said that. So at my first job back in 2001 I remember stating, and I don't know if I was just trying to be clever, but I said like security is inversely proportional to convenience, and I think that is still true today. But going back to the seatbelt example that I gave you earlier.It is, you could argue inconvenient to get into a car and have to book your seatbelt. It's inconvenient to have a seatbelt on. If you want to like take off your jacket or put a jacket on, you're too high or too cold. It's it convenient to have a seatbelt on if you are in the back seat and you dislike over, but it's a trade off between the level of security that provides.It might be inconvenient. You might be a little cold or a little hot early cancer site across the car or whatever. But it's better than flying out of the windshield if you happen to get an accent. Right. So it's constantly this trade off where like convenience versus security. I think it's still true. I would say that because technology is improving so much, they are lowering how inconvenient it is.So here's some good examples or recent examples. Like I have an Android phone and it has a fingerprint reader on the back and it's great. I can unlock that thing in a split second and it just, boom, there it is. I don't have to type in a password or put in a code. And same thing is true for like the neuro iPhones that are in like the new pixel phones is, they have like face unlock.So you just look at the thing and unlocks where you. If you're a James Bond and you are tied up on a chair somewhere and they want to like unlock your phone, they just pointed your face and now you know, if you're under arrest, like you can't prevent that from happening. But like, you know, most of us aren't James Bond.So I don't think that that isn't necessarily like the primary concern that you want you to have, but is the way that I would usually recommend thinking about these things. The Dangers of Wireless Security and SerendipityAmelia: [00:51:40] Your seatbelt example brings up the point of I think about how dangerous it is to drive versus how dangerous it is to take a flight cross country and driving is way more dangerous, but I still get really scared every time I take a long flight because it feels so much scarier.So I bet in the security world there are things that don't feel like big risks are and things that are big risks, but they feel like not a big deal when you think about them.Eric: [00:52:08] Here are a couple things that come to mind. The first one is wifi. So why fi wireless internet is like something that's so prevalent now.That we assume that when we go to the airport, there's going to be free wifi. We assume that when we go to a restaurant, there's going to be free wifi. We assume that what we go to work, there'll be a wifi. We can catch you. So our phones have service. We assume that there's going to be wifi, like everywhere we go and when there isn't, it seems like a huge problem.Because there's free wifi everywhere. That means there's a network that you're connecting to. Who knows who else is on that network, right? When you go to the airport, who knows who else is on the network at the airport? Who knows if they're monitoring all the traffic that's going through computer, who knows if they compromise the router at the airport.That's a bigger problem than I think people realize like wifi, security. Even though you have like your crazy long password on your router and you keep it up to date all the t

Nate's TwitterAmelia's TwitterStay-at-home sale

What We Talk AboutWhat it's like to work at FacebookWhy is typescript so popular?TypeScript and it's relationship to JavaScriptTypeScript as a productivity toolMistakes beginner TypeScript developers makeWhat's the difference between TypeScript and Flow?