 Okay, so thank you for the introduction. I have to apologize in advance. Hopefully you can all hear me okay. You won't be able to see my less than beautiful face because webcam issues on Chrome, this is my work computer and we're not authorized to install the Zoom client app on work computers. So forgive me for that. So instead, Mike is gonna co-pilot my presentation for me, he's screen sharing it right now. And then I'll just ask him, I'll say next slide every time I want Mike to go next. And I think we should be able to get through it okay. If you're dying to know what I look like anyway, just you saw the picture ahead of time. So that's a good enough one. I'm the only Gabe Hall me on the internet. So if you wanna reach out to me, you should be able to find me. I also have, I think my contact info at the end. So stay tuned for that. Look, I work for AWS, Amazon Web Services. If you all are new devs, you might not, well, you probably know of it, but you might not have a lot of experience with it. So this talk is just kind of some of my favorite tips that I share with everybody about working with AWS, whether you're brand new or you've been using it for years, everybody I share this deck with learn something new and they thank me for it. So I hope it can make your life better. And like I said, even if you are not into AWS at all, there's some concepts in here that will help you no matter what you do and there's some fun history lessons. So with that, let's take it away and I will try my best to keep it to around 25 minutes. We'll see how well I do there. And then I, if you have any questions, why don't we do questions at the end that way I can gauge the time of the presentation better. Okay, next please. So as builders, what do we want? Well, I would assert that we want powerful and flexible tooling and what we build when we build it, we want to be able to observe the systems that we make and measure them to understand how they're behaving. And of course we do this in this virtuous cycle of building and observing and building and observing as quickly as possible so that we can learn and iterate and make whatever we're building better. And so I'm gonna try and share tips around these three themes with you. Next slide please. So this is a little bit of a quiz. I think everyone, most people on the call are a little bit shy. So I'll just, I'll do rhetorical questions here. I'm wondering if anybody knows what this machine is, if you do without looking at the Wikipedia credit at the bottom, then points for you. Next slide please. For those of you who don't know, it's a teletype model 33 and this is a device that's, this particular model is from 1963. So back in the day, you know, before we would program into, you know, write text and computer screens to program computers, we would type into machines and the first teletypes were actually made to do Morse code long distances or to replace Morse code rather with telegraphic machines. So there'd be two of these machines hooked up together over a network and you type the keys on one and it would print on you in front of you and the same signal would go over the wire and print onto the machine it was connected to. And so it was a great way to exchange messages quickly back and forth. I know, what if you got a typo, right, Jimmy? So that's exactly right. You just have to keep on typing back in the day that was just send only, right? There was no buffer or anything like that or line editing even. But that's how it all started. And so that sort of paved the way for us typing onto a machine that looks like kind of a keyboard in order to do some interactions with people. The next evolution then was to interact with computers. So next slide, please. So next came this, Multix. Does anybody know what Multix is? If you do, again, another point for you. You can, we can keep score and ask for who got a lot of points at the end. I didn't know what it was till I started doing research for this, this is my favorite part about doing talks. Next slide. So this is an operating system. Now, some fun facts here, okay? In 1964, so we're talking only one year after that teletype Model 33 was made, a man named Louis Poussin coined the term shell or computer shell when he was thinking about, it didn't exist yet really, but he was thinking about a interactive command line interface to talk to computers where you would type commands in and get results back. He was thinking about this, but he hadn't even made it yet. Now, a year later, a woman, and I always like to prep or voice for awesome women in computing, this is one of the lesser known women, her name was Glenda Schroeder. So a year after Louis Poussin had the idea for a shell, Glenda Schroeder at MIT writes the first thing that we would consider an interactive shell while she was at MIT in Massachusetts Institute of Technology for an operating system called Multix, which was one of the first multi-user operating systems. Now, she also actually helped build what many people would consider the first version of email, but it wasn't email for machines connected to each other. The idea was you would write email to local inboxes on a shared computer. So I could send messages to you as long as we were working on the same host in a multi-user fashion. But still, a predecessor for the network demo that we know and use today, we can thank Glenda for that as well. Now, that's all well and good. So a year after we were typing into teletypes, someone thought about a CLI to talk to connect these, something like this to a computer. A year later from that, Glenda builds the first interactive shell. And now if we advance forward just a few more years, next slide, we get this. Next slide again. Points, if you knew what this was, this is a data point 3300. So this is also called like a glass TTY or terminal, terminal displays. This is one of the first and most popular computer terminals, what we sometimes people call them a dumb terminal, where you would have a screen instead of a piece of paper in front of you, but it was modeled very much after the teletype machines. So this is 69, it's only a few years after interacting with computers. Before that, now we've got pretty much, if you squint, it's exactly like what we used today, where we type into terminal emulators and our shells to get work done. Next slide. So there's a history about CLIs and how we kind of got to where we were today in three broad jumps. But why do we love the CLIs developers? Well, because it gives us the ability to do things fast. We can compose commands together, right? It's clear to some extent. If you are familiar with the commands, then if you know them, then when you read them, you can kind of understand what it does. It expresses the intent very well, rather than telling me, click here, click there, click this, right? A command will do that for you. And finally, they're repeatable. We can put these CLI commands into scripts and run them. And I think that's why they're, it's still such a beloved tool for us as developers for all of these reasons. So next slide. I'm gonna do a demo for you now of the CLI, the command line interface tool that we have for AWS. And next slide again. And then I think if you just do next one more time, it will play or click the button, that's fine too. Yep, whatever you want. Okay, so this is a quick demo. I'm gonna show off some commands using S3, our simple storage service. So the first thing I'm gonna do is make a bucket. That's like a place where you can put files on Amazon web services. And we can see here now I can write a different command, the S3 API sub command to list the buckets. I'm gonna make a few here just to show off some of the features of the command line. And when you're making S3 buckets, I have to have globally unique names. So I'm just making some really long names here for the purpose of illustrating some points. And so I've made three buckets. And now if I run that list buckets command again, I'm actually seeing all the buckets I've made in the cloud just from running those commands. Now every command in AWS, you can change the output to see it as text instead of JSON. You can also see it as a table if you like with the CLI, which is pretty nice. Now what's pretty cool also is being able to take the same thing and do some filtering too. But first what I'll do is I'll show you my favorite feature of the CLI actually. So I'm just gonna make a little mini file system here with a few folders and files. They're gonna be empty files, but it doesn't matter for the purpose of this demo. We're gonna make some folders, make some files inside those folders. And what we'll do is we're gonna sync our local file system directory up with an S3 bucket. This is super useful if you just wanna like back up a folder really quickly, even recursively. So this is what the structure looks like if the folder structure I've created. So now we can just say I want to pick a bucket. Let's pick this one. I'll copy that. And I'm gonna say sync, synchronize my local file system. So this current folder with the dot with this particular S3 bucket and boom, it will sync it all. Now obviously the files were not, they didn't have anything in them, they were empty, but it still is really damn fast. And if we add some more files and we look at our file system again, and now we run our sync command again, it's only gonna sync up what's new. So it's also smart enough to look at the bucket and figure what was already there and what do I need to do to put things there. You can also go the other way. You can pull from the bucket down. And we can use the LS command now to see that we've actually got content in the bucket. So everything you could do with the AWS web browser, sorry, the AWS management console on your browser if you're familiar with that, you can also do from the command line and that can be really, really comforting. So at the end there, I just cleaned up the bucket. But what you might not know is that if you have files in the bucket, AWS is like, no, I don't want you to delete this. So instead you can say dash, dash, force and it will actually clear out all the files in the bucket for you. So a super handy trick to empty a bucket if you really, really want to from the command line. Okay, next slide. A lot of people don't know about synchronizing. So that's, oh, I don't know why it's playing that again. Can you go next, Mike? Okay, cool. And just one other fancy thing to show. So you can really take the AWS command line and compose the commands. So this is a shell script that will, if you know AWS then you might know that for security purposes you can have these things called roles and roles have policies associated with them and the policies say what a particular principle can or cannot do in an AWS account. But you can't delete a role if there's policies attached to it. So similar to how you can't delete a S3 bucket if there's files in it. So we can use different commands to list all the roles and then for every role, I'm going to get all the policies attached to that role and then for every policy attached to that role I can detach the policy from the role and then I can delete the role. So you can see how you can compose these things together for pretty powerful stuff. Yes, AWS also has a web management console you can log into. You don't have to use the CLI. I just think that people shun the CLI at first but it's actually quite powerful. I don't recommend starting with the CLI but as you start interacting with the web interface more you might want to do some things programmatically or just from the command line sometimes. So it's good to know that you can't and that's why I wanted to show it. Okay, next slide. Another really cool thing is something called the AWS console recorder. Now this is also a video but in the interest of time I'm not going to play this one, we'll skip it but don't go through the next slide just yet Mike. Hold on a second. I'll just tell you guys, what this, if you're interested in this idea this is a browser extension you can install that will watch what you do in the AWS web console while you're clicking around in the web interface. It records it all and then it can output everything you did as the command line interface equivalents. It can output them as Terraform scripts as AWS cloud formation scripts as Python troposphere scripts. So it's an amazing way to say if I want to learn how to build some infrastructure as code if you're into that but you don't, you want to start by figuring out what all the parameters are do it in the console, record interactions and then dump that out with this tool. So if that sounds like something you might be interested in I just wanted to put that in front of you and say go learn more about it, it's really cool. If you use AWS you will love this. If you don't, it's not as interesting to you so I don't want to spend more time on it. Okay, next slide. So again, some other tips for you. There's how you can install the CLI for AWS that's that first link. There's an alternative community based CLI called SAWS or supercharged AWS. It's got some other fancy bells and whistles like some cool cloud resource auto completion and things like that. It might be worth checking out if you're into AWS already and you want more command line tooling in your life. Finally, the console recorder and then another tool by the same creator links are there. So the other one there, former two, it does the opposite. Sorry that you all should have a dot before the dot com. That's the typo, just added that in today. But former two does the opposite of what console recorder does. So former two says, I already have some cloud resources I made in AWS and now I want to know what the scripts are to recreate them. So it can look at your existing infrastructure and make scripts from it. It's super cool. Okay, let's move on. Next slide please. More quiz time now. So this is a really cool picture. And I wonder if anybody can recognize what's going on here. Some guys using a pen pointing at a screen. Next slide. This is a piece of software called Sketchpad which pretty much everybody will agree is the first program to ever use a graphical user interface or GUI. So that's an amazing piece of history right there. And that's in 1962, 63. So just around that time, depending on who you ask or when you're gonna consider the program finished. So that's really neat that you, some people were really at the cutting edge back in even 62 drawing on computer screens to do some simple computer aided design kind of like drafting and architectural work. Next slide please. Okay, I wonder if this is getting, we're getting a little bit more modern here. So I wonder if anybody recognizes this. Next slide. This is a screenshot from Smalltalk 76. So Smalltalk is cool and all of us as devs would probably have a special place in our heart for Smalltalk even if you've never used it. Smalltalk is widely regarded as being one of the first really object oriented languages. And it had its own IDE that you could use to write Smalltalk code in. But what was so cool is that the entire user interface, this whole IDE was also written in Smalltalk. So you could customize your own IDE with your own Smalltalk code for writing Smalltalk programs super ahead of its time. And really not that long ago in 1979. So pretty, pretty cutting edge stuff. Now, it's actually not a big leap from 1979 to what we have next. So next slide. This is, it's not gonna look that much different, right? We got windows and we got text in those windows and we can do things. So it's just like Smalltalk let you get in and debug your programs and look in the insights into them in real time. Next slide. We can do the same thing now with the code we write on our computers. And that's no surprise, right? I think we've all done some debugging before. But what you might not know is that we have tooling in place to make working with things like Lambda functions, which is code that you run in the cloud without having to provision a computer. You can do that on AWS and you can even debug that kind of that stuff locally on your machine as well with some tooling that we have. So next slide. Also in the interest of time, next slide. I'm not going to demo this one for you right now. I'm just gonna tell you if you, or I think here, go to the next slide, Mike. I'll talk about it on this next one. And one more. So thank you. So we have this thing called the AWS toolkit and you can use it in Visual Studio Code if you like VS Code like I do. You can also use it in Python or IntelliJ if you like those IDEs. And it just makes working with AWS really easy, has a lot of cool auto generation for you. You can quickly edit code that you have already uploaded to Lambda functions and things like that. It does local debugging. It's great. Again, this is not an AWS meetup, so I don't want to spend a lot of time on it, but I wanted to put that out to you in case you didn't know, if you like using an IDE, I mean VS Code is where I usually live now for all the code I write. I find the AWS toolkit very useful for all the AWS work that I do. So I want you to just know that it's there. Okay, next slide, please. This one is super, super cool and this is the oldest picture that I have in this deck. Without reading the caption, if anybody knows what this is, then I owe you a beer. Okay, next slide. Why do I owe you a beer? Because this is, believe it or not, a stone tablet or a clay tablet from somewhere between 3,100 and 3,000 BCE. So a hell of a long time ago when we were using a writing style called Cuneiform, one of the earliest forms of writing to keep track of things. And we didn't even write on paper back then. Paper came later, right? Paper or the word paper comes from papyrus because we used to take the papyrus read and actually use it to make markings on clay and that's what's going on here, right? So they would take the tip of the papyrus read, they would mark on the clay and they would let that dry and that was like their first version of record keeping, written record keeping, I should say. And what this is, is actually people keeping track, apparently, I don't read Cuneiform, but apparently this is people keeping track of beer, like who owes who beer, not joking. I think this is amazing. So we've come a long way since then. Next slide. Obviously, we figured out paper and we figured out a particular way of writing things down to keep things better in our life. Next slide. So this is an accounting ledger. So this is from 1828, this particular picture. And there's already a lot going on here. So as people here, even in like the 1800s, we figured out we ought to have some structure to what we're writing down. We shouldn't just write things down willy-nilly. It's nice to have some format, right? We've got columns here. We did the same type of data as in each of those columns, like it's names or it's the money and figuring out who's owing, who what. So this is just the evolution in the Cuneiform tablet with a little bit more organization behind it. And similarly, something that we can do now in the modern era, next slide, is take that one step further and instead of having to manually tally things together, like in a paper log, we can, next slide, we can analyze log files with computers. And this is like, you know, that's not maybe such an a-ha thing, but there's some strategy to it. So we'll come back and I'll show you a quick demo of this, but let's go to the next slide and I wanna talk about a concept first. So the concept is called structured logging. So if you're a new developer, this may be a new idea for you, but if we compare these two examples I have here, right? The first one is only good for humans. We can say, I've got a timestamp, then I've got the log level, and then I've got a message. User Gapol and me completed order one, two, three for total three, one, three, three, seven, right? Awesome, it gets the job done. And that's the kind of logs that we might write when we're just building out our system so that if something goes wrong as a human, we can look at it and figure out what happened. It's super useful for debugging. It's a good habit to get into logging, especially with a logging tool, so you can tune what level of logging gets emitted depending on what you're working on, if it's in production or not, if it's on your local machine, you're gonna have a more verbose style messaging. But there's an alternative, right? Look at that second one, for good for humans and machines. It's exactly the same information. It's just presented in a different way. In this case, I just represented it as JSON. Of course, you don't have to use JSON or JavaScript object notation, but if you put some structure into your log messages, then it makes it very easy for computers to do helpful things with them. And if you use a language like JSON, it's sort of self-documenting. Each record says, here's my label value and here's the value for that label. And so it's a really good saying default anyway. It's a bit verbose, but storage is cheap these days. It doesn't cost a lot of money at all for storing log data. So it's not a bad choice when you're just trying to decide how should I represent my structured information in my logs. And so we can do cool things with this, with this concept of structured logging. And that's what I wanna show off really quickly. So if you can go to the next slide, I'm gonna demo a feature that's relatively new to AWS so you might not be aware of it. It's called CloudWatch Logs Insights. Next step, please, next slide. And this is a video too, Mike. So if you can just play this, cool. So I'm gonna open the Amazon CloudWatch. And CloudWatch is the place in the AWS web console and this is the web interface in case you've never seen it before. Where all of your logs go for the things you do on AWS for services that you choose to log in the cloud and not just stay on your local machine or you know whatever VM you're running. And so here I've got a Lambda function. Again, Lambda is our thing that does code running in the cloud without provisioning your own servers. And I can see here, there's even some structured logging here. Now this isn't JSON, but we've got labels and we've got values that are separated by spaces. And so every Lambda function by default, no matter what else you decide to log, will log things like how long it took to execute, how much memory it consumed, et cetera. And now then you can go to this Insights section of CloudWatch Logs and you pick a log group which is like a folder where all the logs for a particular service go. And then we can run queries. So it may be a little blurry here depending on your internet connection here or how the screen sharing is going for Mike, but this is just a very simple query that's saying, I wanna look at this whole log group. I want to show me the average and maximum duration and minimum duration times for the Lambda function from that structured logging, bin it into 10 second chunks or like bins, like a histogram and then show me the data. And then I can interactively explore that data with the mouse to zoom in on data and see what values are there. So this is like, there's a really popular log analysis service called Splunk that you might have heard of. You might, you could think of this like a very lightweight version of Splunk that has some of the basics about what you need, but built right into AWS. And so it's pretty great for just getting started if you don't need all the heavyweight enterprise features and excellent capabilities that Splunk can also give you. So what we can see here is I've got that one data point at the top and then some other ones. That first one would be like my Lambda cold start where the code needed to get warmed up the first time it was executed. But then if I zoom in on the other data points, I can then go back to my graph and I can see a little bit more detail about that graph because we don't have that one outlier now. So I can see how my response times vary depending on what was happening there. So there's a few sample queries that come built in with CloudWatch logs insights. I'm just showing a few of them here for the purpose of getting you inspired. And you can also write your own. So here's another one that looks at the amount of memory that the Lambda function was using and figuring out how much it used on average, how much maximum it was used. And then we can see from that, maybe I've over provisioned, maybe I've selected too much RAM for that Lambda function to use and I can see that and I can chart it if I wanted to. That's probably enough Mike, you can go to the next slide. We don't need to watch all these any more examples for this. So if that seems cool to you and you wanna know how do I do this? How do I use this list CloudWatch logs insights tool? Which by the way only charges you when you use it. It's like a pay per use, right? So it's a feature that's on, it's ready for you to use and you're only gonna pay for the day that you actually analyze for those ad hoc on-demand queries. You can look at these URLs to learn more or just search for CloudWatch logs insights in your favorite search engine. Okay, next please. This is me wrapping up then. So a summary next. CLI is a great, right? If you're not comfortable with the CLIs yet, if you're not, you know, if you're still getting started in the terminal and I think as junior devs, we've all been there and there's always more to learn, right? Like I've been a professional software engineer for 17 years and I still learn new command line and stuff all the time. So it's a lifetime of learning but it's great to start if you haven't yet and I encourage you to get a little bit more comfortable with the command line because it's not just for the stuff you do on your local machine. You can also use it for a lot of different tooling like working with the AWS cloud, for example. Of course, IDEs are really helpful. So don't shy away from them. I was a long time terminal only VIM user and VIM is still great, it's super fast but over time I found that there are a lot of features that show up in IDEs that I do just really enjoy and I'm willing to sacrifice a little bit of the editing speed that I had with VIM only in a terminal for some of the added graces that I get in an integrated development environment. So don't be a snob if you're only in the terminal and you think you're awesome, give IDEs a try and of course, if you already use IDEs, give the terminal a try for a command line so it goes both ways. And finally, remember that if you write your logs in a way that will be easy for computers to parse, you will thank yourself later because there will come a time where you will want to analyze data from your logs and that idea may not even occur to you if you didn't start with it because it would have made your job really hard. So if from day one you write your logs in a way that's gonna be easy for computers to analyze, you will future you is gonna say, oh my God, I'm so glad I did that because you'll be able to make really cool graphs and help figure out what problems are a lot easier than having to write custom parsers and figure out what log messages you actually were logging and pull actual useful data out of that. That's it, that's all I wanted to leave you with. I hope that was useful, at least a walk down history lane and maybe also you enjoyed some of the AWS tips too. So thank you for your time and attention. You could be doing a lot with your Thursday night. I know that and I wanna really say, it really means a lot to me that you chose to spend these last 25 minutes with me. So thank you if you wanna keep in touch. I'm the only Gabe Hallaby in the world, as far as I know, I'm Gabe Hallaby on LinkedIn and Twitter, that's the best way too. So maybe we have time for like one or two questions. If anyone has a question, I will just look in the chat now or you can come on with your voice if you wanna ask a question. Okay, well, if nobody wants to ask any questions now, you can find me anytime. I'm always happy to chat. In fact, it's also my job to talk about AWS. So thank you for that. But even if it's not about AWS and you just have weird or fun programming questions, Mike can vouch for this. I do love helping people. So don't be a stranger and reach out if you need anything. And thank you, okay. And thanks to Mike for running my slides. You're amazing. No worries.