Claude Code for Beginners Tutorial

[00:00] Master Cloud Code and learn to integrate [00:03] Anthropic's powerful AI directly into [00:06] your development environment. This [00:08] course is designed to take you from [00:10] initial setup to managing complex [00:13] multifile projects with a structured [00:15] professional methodology. You will learn [00:18] how to scaffold applications, enforce [00:21] testing standards, and leverage AI for [00:23] deep architectural reviews and security [00:25] audits. Jeremy Morgan from CodeCloud [00:28] developed this course. [00:30] >> Okay, now here's the prerequisites and [00:32] how to get started with Cloud Code. [00:33] Cloud Code is an npm application at its [00:36] core. So if you're familiar with npm, [00:39] then this part is super easy. If not, [00:41] you'll need to have NodeJS 18 or newer. [00:45] So what I do, I'm on a Mac here, so I'll [00:47] just do brew install Node. [00:50] And it looks like we are at Node 24.4.1 [00:53] 4.1 already installed and up to date. [00:57] Great. So, it requires Node.js 18 or [01:00] newer. So, we're good there. And the way [01:03] to install Node is different on each [01:05] operating system. Generally on Mac, you [01:07] can download it the binary installer or [01:10] you can do brew install node. Um, I use [01:12] Homebrew, so it manages all those [01:14] packages. If you're on Linux, you can do [01:17] uh, you know, pseudo app get install [01:18] node, something like that. Um, in [01:20] Windows you can download the installer, [01:22] but you just want to make sure that you [01:24] have NodeJS 18 or newer. And that's [01:27] really all the requirements for this. I [01:29] mean, aside from a cloud account. [01:32] Okay, so we know that Cloud Code is an [01:35] npm app. And if you're not familiar with [01:36] npm, that's fine. You don't need to know [01:39] a lot about it to use Cloud Code. [01:43] What you'll need to type in to install [01:44] it is npm install-gthropic-icode. [01:52] Now, what is the -ash g? Well, that [01:54] means we're installing it globally. So, [01:56] if you install a nodejs without that - [01:59] g, it will install cloud code into your [02:01] project. So, whatever folder you're in, [02:03] whether it's a git repo or an npm app or [02:06] whatever, it'll install cloud code [02:08] within that application. We want to run [02:11] this on any application anywhere on our [02:15] hard drive basically. So we're going to [02:18] install this globally and that's what [02:19] the slashg is is for global. [02:22] So let's type that in [02:26] and it'll go through and it says added [02:27] 12 packages. So now cloud code is [02:31] installed on our machine. [02:34] Okay. So what do we do now? How do we [02:36] run cloud code? Well, it's pretty easy. [02:38] Let's type in Claude. [02:41] Now it says welcome to Claude Code. And [02:44] here's the first startup screen that you [02:46] will see the very first time you start [02:47] up Claude Code on your machine. And it [02:49] says let's choose the text style looks [02:51] best with your terminal. Dark mode, [02:53] light mode. You can do dark mode, [02:56] colorblind friendly, [02:59] etc. I tend to do just regular old dark [03:02] mode. Anzy colors are kind of nice, too. [03:06] Let's do that. Now check this out. It [03:09] says, "Welcome to Cloud Code." Cloud [03:12] Code can now be used with your cloud [03:13] subscription or build based on API usage [03:16] through your console account. So here [03:20] there's two different ways. So if you [03:22] have a pro account, which is $20 a [03:24] month, or the $100 a month max account, [03:28] this is basically a predictable pricing [03:30] model. So you'll be able to use this [03:32] without being build too much. or you can [03:35] just do an anthropic console account [03:38] with API usage billing if you're only [03:40] going to use this to try it out or [03:42] whatever. Uh this can be a little bit [03:44] cheaper, but I'm already using a Claude [03:46] account with a subscription. Um I'm [03:49] doing a Cloud Pro account, so I'm just [03:51] going to select that. And it says using [03:55] your browser to sign in. Now, here's [03:57] something cool. If it says browser [03:59] didn't open, use this URL to sign in. [04:03] Right? So you can just take this URL, [04:06] drop it in. Now where this is handy, the [04:09] reason I'm bringing this up is because [04:11] if you were running [04:14] WSL in Windows, sometimes it does not [04:17] pop up that browser automatically. [04:20] Um, that's one thing that I've noticed. [04:22] Now on my Mac, it did just pop up a [04:24] browser for me, but uh when you're in [04:28] Windows with WSL, it won't pop up that [04:31] browser. or if you are sshed into a [04:34] server. So you can run cloud code [04:35] anywhere, right? So if you have a [04:38] server, you're sshing into a Linux [04:40] server somewhere out on AWS or whatever, [04:43] uh it's not going to have a browser [04:45] installed on it. So you won't be able to [04:46] do that. But if you take this [04:49] URL here, you can go into your browser [04:52] and give it access. [04:55] So like I said, mine did open up a [04:57] browser for me on this machine. And it [04:59] says cloud code would like to connect to [05:01] your cloud chat account, access your [05:03] anthropic profile information, [05:05] contribute to your cloud subscription [05:06] usage, etc. So I'll go ahead and [05:08] authorize that. Now it says [05:11] authentication code. Paste this into [05:13] cloud code. So I'll click copy code. [05:16] Here we go. It's asking for this code. [05:20] Boom. We'll put this in. [05:24] And it says login successful. Press [05:26] enter to continue. [05:29] Next, you'll see some security notes. [05:32] Now, here it says, "Claude can make [05:34] mistakes. You should always review the [05:36] responses, etc. These are just basic [05:38] standard boilerplate warnings." All [05:41] right, so let's do a real life example [05:43] here. So, I'm going to use one of my [05:44] favorite websites, mockaroo.com. And [05:47] what this does is it generates mock data [05:49] for testing, software development, stuff [05:51] like that. It's a really cool site. It's [05:54] amazing. So, we'll hit generate data. [05:56] And I'm going to download this and we'll [05:59] call it uh members.csv [06:03] and just download it into my awesome [06:05] project. And now back at the cloud code [06:08] prompt, I'm going to say [06:11] create a Python file [06:15] that reads members.csv [06:20] and displays [06:23] first and last names. [06:27] Now, it's going to go through and of [06:29] course, it's going to look and see if it [06:31] can find that file, and it's going to [06:32] create a Python file to read that and [06:35] display first and last names. Here we [06:36] go. Here's our code. Now, when you're [06:39] adjusting the theme or the colors, [06:42] things like that, it's mostly for this [06:44] for the code highlighting. So, I can see [06:46] this and we can see we have read members [06:49] py import CSV. We have a read members [06:52] function here that opens up member CSV [06:55] readonly. It takes first name and last [06:58] name and it looks like it will print [07:02] that out. And of course if it doesn't [07:04] find the file it throws an error. If [07:06] there's any other kind of exception it [07:07] captures it there. This is some good [07:09] code right? This is good code for [07:12] reading a CSV file. Now a lot of times [07:14] they'll use pandas or something like [07:16] that when things are complex but for [07:18] this simple task this is a very good [07:21] code generation. So I'm going to say do [07:23] you want to create read members? Yes. [07:27] There we go. Now what can we do from [07:30] here? Well we can leave [07:32] this prompt open. Right. This thing goes [07:36] we can go back to Visual Studio Code. [07:38] And here's one of the good things. [07:39] Here's my awesome project right here. [07:44] I've got that open. Now I can exit this [07:48] and in Visual Studio Code I can go to [07:50] the terminal here, create a new terminal [07:55] and type in cloud here. And here we go. [07:57] We can see that we have Cloud Code [07:59] running in the terminal. So in here we [08:03] can do terminal setup. We can change [08:05] some settings etc. I'll press enter. And [08:08] there we go. That way you don't have to [08:10] have that window open all the time. So [08:12] you saw that I had a terminal window [08:13] open and I was running Claude code and [08:16] doing things like that. But now I'm [08:18] sitting here in my awesome project and [08:22] looking at this new code that was [08:23] created here by Claude looking at my [08:25] member CSV. So for me it's a little bit [08:28] easier to just run claude code within [08:30] this terminal. And then I can just go [08:32] here and just create a new terminal, you [08:35] know, bash terminal or or whatever else. [08:38] And we can do that. So I can say create [08:42] a virtual environment. [08:45] We'll activate it. And I can say Python [08:49] read members py. [08:52] And there we go. Within seconds, cloud [08:54] code created this file that reads off [08:57] the first and last names from that CSV [08:59] file. So, I just wanted to show how to [09:02] set up the prerequisites, how to install [09:04] cloud code the first time, and this is [09:07] on a Mac for this demonstration. [09:09] However, it can be on Windows or Linux, [09:13] basically the same. So, let's start [09:15] digging into this and doing a little bit [09:17] more advanced stuff. But this is how [09:19] easy and quick it is to get set up with [09:21] Cloud Code and get rolling right off the [09:24] bat. All right, let's take a little [09:26] deeper look at this and setting up your [09:28] first session. Now, here we have some [09:30] tips for getting started. Run slash [09:32] andnit to create a Claude MD file with [09:35] instructions for Claude. And we're going [09:36] to dive into that and see what that [09:38] means. Use cloud to help with file [09:40] analysis, editing, bash commands, and [09:42] git. Be as specific as you would with [09:44] another engineer for best results. Now, [09:46] this is probably the most important tip [09:48] right here. Be as specific as you would [09:51] with another engineer. So pretend like [09:54] Claude code is an assistant because [09:57] that's exactly what it is, but it's it's [10:00] just another developer sitting next to [10:01] you who happens to know a lot that you [10:04] can discuss things with. You can say run [10:06] terminal setup to set up terminal [10:08] integration. So the first thing I want [10:10] to do is do a net. Now here this is [10:14] going to create a new cloud MD file. And [10:16] you can see here it's going to go [10:17] through several steps here. It's going [10:19] to analyze things. [10:21] It's going to find out what kind of [10:22] project it is here. It's looking for [10:24] package JSON, which we don't have. PI [10:27] project toml. See, all we've done is [10:29] created a Python file in a CSV. So, it [10:32] is going to have to kind of figure out [10:34] how this works. Now, let's take a look [10:37] and see what it created for the Claude [10:39] MD. Cloud MD. This file provides [10:42] guidance to claude code when working [10:44] with code in this repository. So this is [10:46] a simple Python project that processes [10:48] member data from a CSV file. Project [10:51] consists of that has everything that we [10:54] have uses Python 312 with a virtual [10:57] environment. Here's how to activate it. [10:59] Here's how to run the main script. [11:01] Here's how to deactivate it etc. Now [11:04] it's shows the code architecture here. [11:06] Single purpose script code contains one [11:09] main Python file that handles CSV [11:11] reading and processing. Talks a little [11:13] bit about the error handling. Right? So [11:15] the script includes basic error [11:16] handling. Uh flexible CSV parsing [11:19] provides both snake case and title case [11:22] column headers for names. Works with a [11:24] large CSV data set. Appears to contain [11:27] thousands of member records [11:30] and has some key implementation details. [11:33] So it says do you want to make this [11:34] edit? I'm going to say yes. So we're [11:37] going to edit that. Now what if I want [11:39] to turn this into a a real application? [11:42] Right now, we can see we've gone back [11:44] here and if we do the front slash, [11:46] there's a whole bunch of different stuff [11:48] here that and we're going to take a look [11:49] at that in this course for sure. But you [11:52] can see here we have a config panel. We [11:55] have a doctor which diagnoses and [11:58] verifies your cloud code installation, [12:01] manage agent configurations, etc. Now, [12:04] one thing I'm going to do, I'm going to [12:05] talk to this like a real engineer, [12:06] right? I'm going to say how [12:10] do I make this a real [12:13] application [12:15] that I can publish to GitHub? [12:18] Now, what's a real application? That's [12:21] really fuzzy, really indeterminate [12:23] definition, [12:24] but I will I'll double down a little bit [12:27] and explain it. other applications and I [12:32] would like to provide [12:35] as much information [12:38] to [12:40] the developer using it as possible. [12:44] Now we've kicked that off. Let's see [12:46] what it says. Basically, I'm just [12:48] saying, you know, how do I make this a [12:50] something that I'm not afraid to put on [12:52] GitHub and be embarrassed about? [12:56] Okay, now we'll open this up just a [12:58] little bit more so we can take a look at [12:59] it here. We'll scroll all the way up. [13:01] We've created Claude. It says, "I'll [13:04] help you transform this into a proper [13:05] Python package that can be published and [13:08] easily integrated into other [13:09] applications. Let me create a [13:10] comprehensive structure with all the [13:12] necessary files." Here's what it wants [13:14] to do. And what it does is cloud code [13:17] will create a set of to-dos and it'll [13:18] walk through these. So create proper [13:21] Python package structure. We're going to [13:24] add a setup py or project toml for [13:27] packaging a comprehensive readme a [13:29] requirements.ext [13:31] example usage and documentation proper [13:34] handling and logging create unit tests [13:37] add GitHub workflows for CI/CD and [13:39] create contributing guidelines and [13:42] update cloud MD with the new structure. [13:44] Do I want to proceed? Yeah. Now granted, [13:47] this isn't a super useful program. It's [13:49] not really worth putting on GitHub uh [13:51] because it has just this ver very narrow [13:53] use but it's a good idea just to kind of [13:56] see how these things can um can kind of [14:00] evolve and stuff like if you're building [14:03] some kind of project you can have cloud [14:04] code say hey I want to make this so that [14:07] other folks can use it and you know how [14:09] do I do that we have an init py and [14:12] we're looking here this is going to be [14:14] an init py that's going to have some [14:16] classes to it showing the errors that it [14:19] uses. And basically, we're doing a lot [14:21] of like documentation and um other [14:24] things that are kind of tightening up [14:25] the we got exceptions py that's [14:27] tightening up the script a little bit [14:29] and it's making it a little bit more [14:31] production ready than it is now. Okay. [14:34] We'll notice here that it is creating a [14:36] reader py and it's a data class with [14:40] some member data here [14:42] and then a member reader that reads that [14:45] data [14:46] and it's putting this into a set of [14:48] classes [14:51] and asking me do you want to do this? [14:52] Yeah, let's do this. So now it's putting [14:56] it into a set of classes. Why does that [14:57] matter? Well, it's good for [15:00] expandability, right? If we want to just [15:02] have this be a simple Python script that [15:04] you run to read the first and last name [15:06] of members, it's great. But if you want [15:09] to make this uh into a real application [15:13] or make it into a module to put into a [15:16] real application, you're going to want [15:17] to do a lot more. Some of the things [15:19] like classes, you want to do that for [15:22] organization purposes, for ease of [15:24] upgrading and testing. [15:27] We can see here it's creating a pi [15:29] project toml [15:31] and this is basically saying here's what [15:34] it requires [15:36] here's the name the version you can put [15:38] my name in there a python package for [15:41] reading and processing member data [15:44] and it just goes through all of this [15:47] information to make this a real Python [15:50] project [15:52] and here's the command line interface [15:53] for the CSV member reader let it go [15:56] through and we can see that things are [15:58] getting definitely more complex. [16:00] However, it's also becoming more like a [16:03] real production application. [16:06] Okay, now we've got a readme file here. [16:10] I could see robust Python package for [16:12] editing, etc. [16:15] And we've got a nice readme file. And we [16:18] have edits to requirement.ext, text, [16:20] which right now doesn't really contain [16:23] anything, but we'll see how it goes [16:25] later on. Here's our development [16:27] dependencies, [16:29] which I'm not sure where I found those [16:31] dependencies cuz I don't think I need [16:32] any of those. But next is going to be [16:35] creating example usage and [16:36] documentation. This is basic usage py or [16:40] basic usage example. Here's CLI [16:43] examples. So in here we'll have a CLI [16:46] usage example where it's going to say [16:48] here's how to use it with a CLI [16:51] CSV member reader members.csv show total [16:54] member count [16:57] verbose output with logging using [16:59] different encoding [17:01] etc. And now it wants to chod this shell [17:04] script so that we can run it. So I'm [17:06] going to say yes. And now it's going to [17:09] create a test package. [17:11] It says, "Do you want to make this edit [17:13] to test reader py?" And this is going to [17:15] be testing our application. [17:18] And here I'm going to say yes and don't [17:21] ask again because we're just going to [17:23] let it go through and build all the [17:25] tests and do all the things for our [17:27] awesome project. And here, do you want [17:29] to make this directory? Yes. Okay. Now [17:34] we can see here the next steps to [17:36] publish. [17:38] We can set up a development environment. [17:41] which we've already done but gives us [17:44] instructions to do that again. Test [17:46] everything works with pi test [17:49] CSV members count create GitHub [17:51] repository [17:53] configure for publishing GitHub urls [17:56] etc. The package can now be easily [17:59] installed by others with pip install CSV [18:01] member reader and used as both a library [18:03] and CLI tool. Well, let's see. Let's [18:05] find out. So, we'll go here to back to [18:08] our bash [18:11] And I'm going to go to CSV member reader [18:14] and take a look at this. We'll go to [18:15] tests [18:19] Python test CLI. And we don't have piest [18:23] installed. [18:26] So we'll do that. And we should actually [18:28] have a requirements text in here [18:30] somewhere. [18:34] And that requirements text does not have [18:39] piest. [18:41] Just as a note, [18:44] we also don't have CSV member reader. [18:48] So we're going to go back here [18:53] cloud MD. [18:56] We have our accident. We're going to do [18:58] Python [19:02] readmeers py. We can see that that [19:04] works. [19:06] And for this [19:09] we can do pi test [19:14] member reader. [19:19] We want that to be HTML. [19:24] So we can see here [19:27] that these commands [19:30] may not be 100% accurate for the pi [19:34] test. [19:41] Try running it within here. And we're [19:44] still getting unrecognized documents. So [19:46] that's something to note that there [19:49] could be some hallucinations in here. [19:56] So we can do pi test [20:02] and one of the things we can do is we'll [20:04] deactivate it and we will [20:08] say let's see [20:12] here and we'll follow the instructions [20:14] exactly to make sure that we are not [20:17] doing something wrong. [20:23] It does need to be pip 3 because I'm on [20:25] a Mac. We're going to type in pre [20:29] commit [20:31] install. [20:34] It failed. It is installed. We're going [20:36] to get repository directory. [20:40] So, some of this stuff here [20:42] I think we could remove out of here [20:48] because as I go through the instructions [20:49] I can see some things that don't exactly [20:52] work. One of them here [20:56] we can say and I don't see any dev [21:00] directory where this is created. See [21:03] where it says pip install- e. This is [21:05] unfamiliar to me. So, I'm not really [21:07] sure why it suggested that and how that [21:09] works, [21:11] but I also don't see that environment [21:15] and where it was created. [21:20] So, it does look like a bit of a [21:21] mystery. So, I would take this out, [21:25] run tests, [21:28] take this out [21:31] until we can find out the stuff that [21:33] works and the stuff that doesn't. [21:39] All right, we have code quality tests [21:46] and we type in black here and it goes [21:49] through all of these and says all done. [21:52] 10 files reformatted. So, that one's [21:54] good. What about flake 8 for flaky [21:57] tests? [22:06] See here [22:09] like Kate says a bunch of these the line [22:11] is too long. [22:19] And finally we're going to do my pie. [22:26] There we go. And we do have an import [22:29] issue. [22:35] So in here if we do my pi [22:46] or my pi dot and it is not seeing our [22:49] net py. So my pi appears to not be [22:52] working. [22:54] So that part isn't working quite as well [22:57] either. So basically the point I'm [22:59] trying to make here is we want to go [23:01] through these [23:02] and really go through your your cloud [23:05] MD, go through your readme [23:08] and make sure that things are accurate [23:11] and they are set up the way they're [23:13] supposed to be set up. Um things like [23:15] that just to kind of double check your [23:17] cloud installation. But I wanted to show [23:19] some of the first session type things [23:22] that you'll do in the first time you [23:23] work with a new product. So, previously [23:25] we did the prerequisites and the [23:27] install. This is how you get set up and [23:30] start your first session and kind of [23:32] build out like we've built out this huge [23:35] project here from a single Python script [23:38] with a CSV. So, this is one of those [23:41] things where you can use Cloud as an [23:43] agent to kind of get you started to get [23:45] all that not so fun stuff out of the [23:48] way. Things like building tests, [23:51] building readme files, and things like [23:53] that. So, thank you for watching and [23:55] let's continue to dive in. [23:58] Now, there's another cool thing you can [24:00] do with COD Code, which is analyzing [24:02] code bases. So, I wanted to find a big [24:05] giant code base that I have in my [24:08] personal collection. One of them is [24:09] Retroacraer which is a combination of a [24:13] JavaScript NodeJS 3JS video game with a [24:18] Go backend when and I have a Go API with [24:22] a SQLite database for the backend for [24:25] this. And so I just want to ask a few [24:28] questions about this repository. So I'll [24:33] type in Claude my terminal. [24:36] It says cloud code may read files in the [24:38] folder, might execute files. Now, this [24:41] is something that is valid to ask for [24:43] this because there's a Go application in [24:45] here. So, this thing might execute Go [24:48] apps, but uh I'm cool with it because [24:51] it's mine. You can see here we can run [24:53] init. You can use cloud to help with [24:54] file analysis, editing, bash commands, [24:56] and git. You can run terminal setup. So, [24:59] we never did do terminal setup in the [25:01] last one. So, let's do that now. [25:04] the terminal setup and you can see here [25:08] we're going to use VS Code terminal [25:10] shift enter keybinding and so now cloud [25:14] code knows that it lives within visual [25:16] studio code and I can change those key [25:20] bindings by editing this file here now [25:22] what can we do here now we have cloud in [25:25] here we can say something like give me a [25:29] high-level overview [25:32] of this codebase like just tell me what [25:35] the heck this is that we're looking at [25:36] here. [25:39] Okay. And now we've got a good highle [25:40] overview. So let's take a look at it. [25:43] Retroacraer highle overview. It's a [25:45] multiplayer racing game with a retro [25:47] aesthetic built with modern mech web [25:49] technologies and a go backend. The front [25:52] end JavaScript based web client using [25:54] 3JS for 3D graphics. The back end is a [25:57] Go server with websocket support for [25:59] real-time multiplayer gameplay. The [26:02] build system is Vite for development and [26:04] bunding. Here it shows our key [26:06] components. Here's our front end entry [26:08] point or main logic etc. And then our [26:12] backend the server entry point server [26:15] and client management core game logic [26:18] physics etc. And it shows here our [26:21] technology stack. And this is all [26:24] completely accurate. This codebase [26:26] appears to be a complete racing game [26:28] implementation with real-time [26:29] multiplayer capabilities, physics [26:31] simulation, and a 3D graphics rendering. [26:34] That's awesome. So, one of the things I [26:36] can do is say explain the main [26:41] architecture of the Go backend app. And [26:47] now this is going to go through and it's [26:49] going to take a look at the Go backend [26:51] and just kind of explain how it works. [26:54] And here we go. Key architectural [26:56] patterns. Event-driven hub model and [26:58] hub.go. It uses Go channels for [27:01] non-blocking communication. 60 Hz game [27:03] tick for real-time updates. Separate [27:06] channels for registration, input, and [27:07] broadcasting. [27:09] Concurrent player management. Mutex [27:11] protected shared state go routines for [27:13] each client's readr operations. Channel [27:16] blaze player life cycle management. We [27:18] have physics integration. We have [27:20] message protocol. The architecture [27:22] supports up to eight concurrent players [27:24] per hub with real-time physics [27:26] simulation running at 60 frames a second [27:28] using websocket connections for low [27:30] latency multiplayer gameplay. So this is [27:33] a really good overall kind of look at [27:36] this. Now one of the things we can do [27:40] here is say [27:42] find the files that handle database [27:46] access. [27:48] And now you can see it's searching [27:50] through the code. [27:52] And let's take a look at what it says. [27:54] It says, "Based on my analysis of the [27:56] Retroacer codebase, there are no [27:57] database access files. It uses in-memory [28:00] storage only." Which is correct because [28:02] the latest iteration of this actually [28:04] doesn't use a back-end database. So it [28:07] says no database dependencies, no [28:10] imports from any Go files, no SQL [28:12] database related code, no persistence [28:15] layer. Everything is stored in memory [28:17] via ghost trucks, which is correct. When [28:19] you start up a multiplayer server and [28:22] shut it back down, everything is lost. [28:25] However, there is retroacraer server [28:27] log. [28:28] So, [28:30] here's another cool thing we can do. [28:32] What are the most recent errors found in [28:37] Retroacraer server log? And we can just [28:40] ask, hey, what kind of errors have we [28:42] had for this thing recently? And we can [28:44] look here and it says key issues found. [28:48] Player client map synchronization [28:49] problem which that is a problem with [28:52] this. Players are being removed from the [28:54] players map immediately after joining [28:56] indicates a race condition between [28:58] client registration and player tracking. [29:00] Client count discrepancy broadcasted [29:03] update players to list to zero clients. [29:05] Show zero clients but players are [29:07] joining successfully. Phantom heartbeat [29:10] messages. Websocket connection errors. [29:13] It's showing us a whole bunch of this [29:14] stuff. And sometimes you can be very [29:16] direct with this and just say fix this. [29:19] And sometimes it works, sometimes it [29:22] doesn't. Or you can just copy this, go [29:26] down here and say, [29:28] suggest some ways to fix. [29:33] And I could just say item number one, [29:35] but we're just kind of reminding Claude [29:38] code which one we're talking about and [29:40] suggest some ways to fix this. [29:42] And it comes back with a recommended [29:45] approach. So it takes a look at all the [29:46] code here and says, "Hey, why don't you [29:49] do all of these things, [29:51] right? So add a registration state flag, [29:56] which is something I actually did before [29:57] that didn't work out great, but I [30:00] haven't tried this with cloud code. Move [30:02] player map date updates inside the hub's [30:05] main event loop, etc." So it says, I'd [30:07] suggest implementing solution number [30:09] four, single source of truth, combined [30:11] with solution number one because it [30:13] eliminates synchronization complexity, [30:15] reduces race conditions, maintains clear [30:17] ownership of player state, etc. So I can [30:21] say implement solution number four and [30:25] solution number one as you suggested. [30:28] And now it's going to start asking me [30:30] one by one as it modifies files, do you [30:34] want me to make this edit to client go? [30:36] Yeah. And you can see here these are the [30:39] changes that it wants to make. And it'll [30:42] go through quite a few of these I [30:44] imagine with this particular fix. And I [30:46] can say yeah and don't ask again this [30:49] section. Now we'll work on the [30:50] hubstruct. [30:54] Okay. Now let's come back to ask me a [30:56] question again. And now it wants to [30:59] build the Go backend and check for [31:01] compilation errors. So I'm going to say [31:03] yes. And it looks like we did have some [31:06] compilation errors which Cloud Code's [31:08] going to catch and attempt to fix. [31:11] Okay, now it's going to try to build it [31:13] again. Great. The compilation is [31:16] successful. Now let me update the client [31:18] registration logic to use atomic [31:20] registration and mark the client as [31:22] complete. [31:23] So, this is how easy it is to use Cloud [31:26] Code with a giant, and I say giant [31:29] because this is a pretty fairly large [31:32] project. And it basically will go in and [31:34] take a look at all of your code files [31:36] and make suggestions and things like [31:38] that. And we have build successful. Do I [31:41] want to proceed? And now it's going to [31:43] mark the final to-do is complete. So, I [31:45] can check this out, see if we have any [31:47] errors or anything, but I just kind of [31:49] wanted to show how to work with existing [31:51] code bases with Cloud Code and how easy [31:54] it is. And um it's very smart. It does a [31:57] great job of looking at your entire [31:59] codebase and figuring out how it works, [32:01] what it needs. And then, of course, in [32:03] this case, I said, "Hey, look at my logs [32:05] and tell me what's wrong." And it went [32:07] through those logs, told me what was [32:09] wrong, and then now it's starting to do [32:12] fixes. So, this is an indispensable tool [32:15] for things like this, and this is pretty [32:17] cool. So, thank you for watching. Let's [32:19] dig in a little deeper. Okay. Now, I'm [32:22] including this demo because I had some [32:24] problems setting up machines on EC2 [32:28] machines to do demos. This is a problem [32:31] that you may run into. So, if you have a [32:33] typical Ubuntu machine, EC2 or other [32:36] platforms, you may run into this [32:38] problem. So we'll type in pseudoapp [32:42] update, [32:44] right? We'll update the machine. Okay. [32:46] And it shows here that we have some [32:47] packages that could probably be [32:49] upgradeable, right? So we'll do pseudo [32:52] apt upgrade [32:56] and upgrade the system. And this is part [32:57] of the install instructions for claude. [33:01] Okay, awesome. So we've got this thing [33:03] upgraded. Right now, if we try to do as [33:07] the cloud instructions say and do [33:09] pseudoapp install [33:11] NodeJS [33:13] npm, right? Because we need that to [33:16] install cloud. It's going to go through [33:18] and say, hey, do you want us to install [33:19] all this stuff? And we say, yeah, sure, [33:21] that'd be great. Okay, now we're [33:23] upgraded. We have npm, all that. And [33:27] we'll copy this directly from the cloud [33:29] code instructions [33:31] where it says npm install-g [33:34] for global anthropic AI cloud code. [33:37] Right? And it specifically says on the [33:40] anthropic site, do not use pseudo npm [33:44] installg because it can lead to [33:46] permission issues. So we're going to [33:48] trust them that we shouldn't do that and [33:51] we're going to run it as they say. And [33:53] this is what we get. [33:55] We get a permission denied [33:58] here. It doesn't allow us to make user [34:00] local lib node modules. Right? This [34:04] operation was rejected by your operating [34:06] system. It's likely you don't have the [34:08] permissions, [34:09] which is fine. So, there's a couple [34:11] different ways we can approach this. We [34:13] can change the permissions for node [34:15] modules [34:17] to allow the iuntu user to own user [34:20] local live node modules. Now, why is [34:23] that a problem? because any other users [34:25] on the system aren't going to be able to [34:28] access it. So, we have a choice here. We [34:31] can either run pseudo npm install-g, [34:36] which by the way, anthropic, like I [34:39] said, tells us specifically not to do [34:42] this. So, we could run that. So, we can [34:45] run it, or we can change it to be user [34:47] local live node modules. Either way, [34:50] it's probably not the best idea. [34:54] So, how do we solve this? Well, the way [34:57] that I solved it was by installing this [35:00] manually. And I'll show you now. One of [35:03] the things that I should point out here [35:05] is when you're creating an instance, [35:06] like here, I'm doing it on light sale, [35:09] right? We want to make sure that we're [35:12] selecting this one. This has 4 gig of [35:15] memory, two CPUs, 80 gig of storage. Why [35:18] is that important? because it says right [35:20] here system requirements. We need [35:23] operating systems of these. We need four [35:26] gigs of RAM in order to run claude code [35:30] effectively. So I just wanted to make [35:33] sure and put that in here that we want [35:35] to select an operating system that meets [35:39] the requirements and four gigs of RAM or [35:43] more. Okay, so we're back at our machine [35:45] here and we've installed npm and NodeJS [35:50] and stuff like that and we couldn't get [35:51] it to work. And here's how we can [35:53] install it manually using the native [35:55] installer. [35:58] So here we're going to do pseudoapp [35:59] install-y [36:01] curl and git. Now git should already be [36:04] installed and it looks like curl already [36:06] is too, but it's something you want to [36:08] do just in case. [36:10] And then we're going to install cloud [36:13] code from the binary. And the way we do [36:16] that is do curl-f [36:18] SSL https/cloud.ai [36:23] install.sh and pipe that into bash. Now [36:26] you can look at install.sh and examine [36:30] it to see if that's something you want [36:32] to run or you can just trust them and [36:35] pipe it into bash like this. [36:39] And here we can see it is going to [36:41] install it manually. And it says claude [36:44] code successfully installed which is [36:46] great. [36:48] So we'll do claude help. [36:51] And it's not found which is fine. We can [36:54] exit out of it and log back in. Okay. [36:58] We'll type in claude help. And now we [37:01] can see that Claude is installed. [37:04] So, by the time you watch this video, [37:07] this might be fixed. But this is just [37:09] something that I noticed when I was [37:10] going on to EC2 servers is I could not [37:13] do a standard npm install-g [37:16] of claude like you would on other [37:19] machines. And I went to another iuntu [37:22] server on another service and kind of [37:24] found the same thing. So, I just wanted [37:27] to show this is what I had to do. I had [37:29] to go look it up and see. And so this is [37:31] how you install it manually with that [37:33] curl command that I gave you and then [37:35] it'll work just fine. And like I said, [37:37] they might get this fixed by the time [37:39] you take this course and I hope so. But [37:42] this is always an option to do. Thank [37:44] you for watching. In this video, we're [37:46] going to start our new project with [37:48] Cloud Code. Now, I want to start [37:49] something from fresh that we can work [37:52] with, we can build tests for [37:54] documentation, etc. And it's actually [37:56] really fast and easy. We really don't [38:00] need to know a ton about code in order [38:03] to create really cool applications. [38:05] However, I am going to use my previous [38:07] knowledge of software development [38:09] because I know exactly what I want this [38:11] project to look like. Now, we're going [38:13] to build a MEAR reader. What's a MEAR? [38:15] Well, it's a format for reporting [38:17] weather information to pilots. So, each [38:20] airport puts out this MEAR weather [38:22] report, and it's mostly used by pilots, [38:25] sometimes used by weather people, folks [38:27] like that. but it just kind of assists [38:30] with weather forecasting and raw mear is [38:33] highly standardized as it says here [38:35] through the international civil aviation [38:37] organization. So that means I should be [38:39] able to build a tool that goes to each [38:42] individual airport whatever airport we [38:45] select and brings up this information in [38:48] a human readable format. Now why is that [38:50] important? Because this is what a mear [38:53] looks like. It's a little cryptic, [38:55] right? We can look at the KJFK and [38:57] figure out maybe that's K JFK as in JFK [39:00] airport. Uh this might be a time maybe [39:04] or a date. We have 16008 KT. [39:10] Who knows what that might be 10 SM etc. [39:14] So this stuff now pilots can look at [39:16] this and tell you exactly what it is. [39:18] They can say, you know, winds 15 mi to [39:21] the south, 80% humidity, and it's a 70° [39:25] day or whatever, but we as regular folks [39:29] don't know how to interpret this. And [39:31] that's exactly what our mear reader is [39:33] going to do. We're going to make it so [39:34] we can type in KJFK or in my case, [39:39] here's the airport that's right down the [39:40] road from me, KHIO, [39:43] and we'll be able to see some weather [39:45] information for that area. and it'll be [39:48] in a nice readable clean format. Now, as [39:51] I said before, I am going to use my [39:54] previous software development knowledge [39:56] to [39:58] dictate what I want. So, if I just go in [40:00] here and type in, you know, build me an [40:02] app that does this, well, it could be an [40:04] Electron app. It could be a QT++ [40:09] app. It could be anything. A web app, [40:12] who knows? And I do want this to be a [40:14] web app. And I want this to be a Flask [40:17] application because I really like Flask [40:19] and I have some other Flask stuff. So [40:22] what we're going to do is we're going to [40:24] fire up Claude. Now I have this folder [40:27] created here. It's already a Git [40:28] repository. And we've seen this a couple [40:30] of times now where Claude may read files [40:32] in the folder, etc. Now here we have [40:36] some tips for getting started, right? We [40:38] already know we can set up terminal [40:40] integration. and we can create a cloud [40:42] MD. But let's just get started with [40:45] this. So what are some of the things [40:46] that we need to know? Well, we need to [40:50] know what the app is, what it's going to [40:53] do, what it will be built with, and what [40:56] we expect to be a criteria of success. [41:00] With just those things, Claude can build [41:03] us an application. So I'm going to say [41:06] create a flask web application. [41:11] This application will be a mear [41:16] reader. Now I'm making an assumption [41:18] here and this is one of the things I've [41:20] talked about in all of the courses that [41:22] I do when I build these courses with LLM [41:24] tools is you have to make assumptions of [41:27] what the LLM knows or explain [41:30] everything. I'm going to assume it knows [41:32] what a mear is and I'm going to give it [41:34] an example so it should be able to [41:36] figure that out. But I'm going to say [41:37] create a flask web application. This [41:39] application will be a mear reader. [41:42] The user [41:44] can type in an airport code and then the [41:48] application will fetch the mear [41:53] reading from that airport [41:57] and decode it. [42:00] I'm going to say MEAR is a standardized [42:05] weather report. So I am going to put in [42:07] some context there and do a little [42:10] explaining just in case. MEAR is a [42:12] standardized weather report. [42:15] It is somewhat [42:18] cryptic. So I would like to [42:22] convert it into plain English. [42:28] that people can understand. [42:31] For instance, [42:34] clear day, [42:37] 70° [42:39] wind. See? So, I'm basically saying this [42:41] is what it looks like for success. And [42:45] I'll double down on that a little bit. [42:47] type in an airport code [42:51] and receive a friendly [42:56] readable weather report from it. Here is [43:01] the service [43:03] I will use. [43:06] When you change the airport code, [43:09] it outputs [43:13] the corresponding [43:15] NEAR. [43:17] And so I'm going to go back to [43:20] up here [43:23] and copy this. [43:26] And now I should be ready to go. And it [43:29] might have some questions for me, but I [43:31] think it will create [43:33] an application pretty close to this just [43:36] based on our very specific prompt. [43:41] And we can see it's setting up the [43:42] to-dos, right? So, as we've talked about [43:44] before, Cloud Code sets up a to-do list [43:46] and it brings out all these to-dos. This [43:49] is a good thing for you to look at and [43:51] say, "Oh, wait. That's not right. That [43:53] doesn't look good." And um at that [43:54] point, you can interrupt cloud code and [43:56] say, "No, I didn't ask for that or I [43:58] didn't want that or whatever." But now [44:00] it's going through the to-dos. Okay. And [44:02] we can see here we have our first edit [44:05] request and it's trying to create a [44:07] flask import here. It says meet me [44:11] decoder. And here's our wind directions, [44:14] right? So north, north, northeast, etc. [44:18] Get wind direction. We got decode [44:20] visibility. So if the visibility is 10 [44:22] sm that means visible for 10 square [44:25] miles or it ends with square miles and [44:28] that must mean there's some visibility [44:30] otherwise visibility not reported. [44:33] And if you can't tell I I can tell what [44:35] some of these codes are. Um I'm a little [44:38] bit familiar with them but here's [44:40] another one. Decode cloud types clear [44:42] skies CLR. A lot of what you see in the [44:45] summertime. SKC is another one. Sky [44:48] clear. Few clouds scattered clouds. [44:50] broken clouds or overcast. And we can [44:53] see here [44:54] decode weather phenomena, rain, snow, [44:57] drizzle, fog, mist, thunderstorm, [44:59] showers. So all of these are assumptions [45:02] that claude code is making based on its [45:04] knowledge of what a mear is because [45:06] these are all mear codes. Uh intensity, [45:10] etc. All of these are valid mear codes. [45:13] So I'm just going to say, okay, this [45:16] looks good. It's calling what I want it [45:19] to call. So I'll say yes. And now I've [45:23] noticed it comes up with a bunch of [45:24] different words down here. [45:25] Cerebrraiding, cerebrraiding, I'm not [45:27] really sure. Now it says I want to make [45:30] a directory named templates. So yeah, [45:32] let's create some templates directory [45:35] here. And here, do you want to make this [45:37] edit to index html? So here's mear [45:40] weather reader. Enter an airport code to [45:42] get a friendly weather report. Yeah, [45:44] sure. I'll say yes. [45:48] And you can tell the to-dos are starting [45:50] to get checked off here. Now we have a [45:53] create results display template. [45:57] And this is going to be the display [46:01] with the raw mear included. So I'm going [46:04] to say, yeah, that sounds good. And it [46:06] wants to create a static directory for [46:08] CSS files. Sure. [46:11] Elucidating, I think it's what it says [46:13] there. [46:15] Okay. And we have a stylesheet. [46:19] I'm just going to say yes. It says test [46:22] the application with various airport [46:23] codes. And then finally [46:25] requirements.ext. [46:27] Yes. Now it's articulating again. And [46:30] right here it's creating a Python [46:32] virtual environment. Installing [46:34] requirements.ext. [46:36] I'll just select yes. [46:38] And it says start flask application and [46:40] background of test. Yes. And we can see [46:44] command timed out. So it tried to start [46:47] it up and it already got an error. So [46:49] now it's going to be flipped to [46:50] jibbiting [46:51] development server. Okay. And it says [46:54] this app will be available at localhost [46:57] 5000. And let's try it out. Okay. And [47:01] I've got my local host up here. And hey, [47:03] that's a kind of a nice looking like [47:05] purple almost a code cloud styled [47:08] background there. And we can see here we [47:10] have our mear weather reader. Enter an [47:12] airport code to get a friendly weather [47:13] report. So, it says here for examples, [47:17] KHO, [47:18] Portland Hills, which is where uh that's [47:21] like I said, the airport that's down the [47:22] road from me. Let's try that one first. [47:26] We'll say Khio. [47:29] And it even says, what is a MEAR? Well, [47:31] it's a standardized weather report used [47:32] in aviation. Now, we can check this here [47:34] and it says clear skies, 81° F, 27° C, [47:40] which is accurate. wind from the north [47:42] at zero knots. So if there is any wind [47:44] that's coming from the north, zero knots [47:46] means pretty much nothing. And it's [47:49] observed at this time, that was when the [47:51] MEAR created wind from the north, 0 [47:54] knots, 10 plus miles of visibility, [47:56] which means it's clear sky conditions, [48:00] clear skies. Temperature again, due [48:03] point, 52° F or 11° C. and even our [48:08] barometric pressure at 30.05 and HG with [48:13] the raw mear. So, it took all of this [48:16] beautiful human readable stuff from this [48:19] mear right here. So, let's check another [48:22] airport. [48:24] Let's see how things are doing in Los [48:25] Angeles right now. Well, down there we [48:28] have a few clouds at 25,000 ft, 75° F. [48:33] So, oddly enough, we are hotter than Los [48:35] Angeles today. [48:37] 24° wind from the west at 11 knots. And [48:42] here we go. We can check another [48:45] airport. We'll say KGFK. [48:48] This is New York, which is also 75° F. [48:52] Some broken clouds at 24,000, wind from [48:55] southeast, [48:58] etc. So, I just wanted to create this as [49:02] our base project that we're going to [49:03] work on as we test out some of Claude [49:05] Code's features. [49:07] and we build agents and things like [49:09] that. We're going to do this all around [49:11] this MAR weather reader. We're going to [49:13] use this to create some documentation. [49:16] We're going to create some tests and [49:17] stuff like that. But this is how easy it [49:20] is to get started. This is a vibe coding [49:23] dream as far as cloud code. If you're [49:25] doing anything in Python or JavaScript, [49:27] it pretty much builds things for you [49:29] very, very fast. All right. Well, I'll [49:32] see you in the next video. We'll keep [49:33] going. [49:35] All right. Now that we know our Python [49:37] application works, this is something [49:39] that I want to release publicly. [49:43] So in order to do that, there's a few [49:46] things that we need to do. We need to [49:48] probably freshen up our Git ignore file [49:51] and we need to create some documentation [49:53] around this, mainly a readme file and [49:57] things like that to kind of prep it for [50:00] being placed in the public. Now, we can [50:02] look at some of these files and say, [50:03] well, they could be probably uh cleaned [50:07] up a little bit. Maybe app py could use [50:09] a little more documentation. So, I'm [50:11] going to include that in there. [50:14] Now, one of the things I can do here is [50:17] say [50:20] I would like to commit [50:24] the initial creation [50:26] of this application. [50:29] help me create a good [50:33] commit message, right? So, you can just [50:36] ask it simple things like that. [50:39] Okay. And it'll even do it for you where [50:42] here it says get add app. py [50:44] requirements.ext [50:45] static templates and all application [50:47] files to staging. Yeah. Now, here we [50:49] have get commit-m add flask mear reader [50:52] web application. And it does all of this [50:54] stuff. Generated with Claude code, [50:56] co-authored by Claude. [50:59] Do I want to proceed? Yeah. Now, if you [51:02] really wanted to, you could probably [51:04] remove that from the code message, the [51:07] commit message that it was created by [51:08] Cloud Code, but I don't really care. It [51:11] says this is now committed and ready. [51:12] You can run it with Python app. py and [51:15] I'll be able to get friendly weather [51:17] reports. So, one thing I'm going to say [51:19] is I want to [51:23] release this publicly, [51:26] please. Now, again, this is putting in. [51:28] So, if you're just vibe coding with no [51:31] background in software development, you [51:33] can build a lot of cool stuff, a ton of [51:35] cool stuff, but sometimes you need to [51:36] know what to ask for. So, previous [51:38] development experience really helps you [51:40] out here. So, since I have previous [51:43] development experience, I know what to [51:45] ask Claude to do. And some of this is [51:52] add comments to app.py [51:56] using [51:58] Python best practices. [52:01] Then create a readme [52:04] for GitHub that explains the application [52:08] and how to install it. And for now, this [52:13] could probably work. We'll add a little [52:15] bit more, but this should go for now. [52:19] And it's going to go through and put [52:20] things here a pi do syntax or some type [52:23] of syntax that's easy to understand. And [52:27] we can see here flask mar reader web [52:30] application web application blah blah [52:32] blah. [52:35] So I'm going to say yeah, let's do that. [52:40] And it's going to put this in. I'm going [52:41] to say yes and don't ask again this [52:44] session. So, I'm just going to let it go [52:45] through and throw all of these [52:49] documentation notes in here. Now, this [52:51] is all stuff that's put in through [52:53] comments. It's generated with claw code, [52:57] but this stuff is basically [53:00] pi dot type comments. [53:04] Okay. And now it's done. Here it says [53:06] test the application after adding [53:09] comments. [53:11] And here it says from app import test [53:14] test mear result decoding test passed [53:18] result summary. [53:20] Yeah, we could add some testing in there [53:23] too. And it says commit the [53:25] documentation code improvements [53:28] in here. Do you want to proceed? Get add [53:30] app. And like I said, you could change [53:32] the commit messages so it doesn't say [53:34] co-authored by claude or whatever. But [53:36] I'm being transparent here and just kind [53:39] of letting everybody know that uh that I [53:41] use cloud code for this stuff. [53:45] It says now it's fully documented and [53:46] ready for GitHub release. Users will be [53:48] able to understand the purpose, install [53:51] easily, use effectively contribute and [53:53] deploy. Your Flask MAR reader is now [53:56] professional grade and ready to help [53:58] aviation enthusiasts and weather lovers [54:00] convert cryptic aviation weather codes [54:02] into crystal clear forecasts. That's [54:04] great. So we can take a look here at get [54:07] log and we can see it's added some [54:10] comprehensive documentation and code [54:12] commits. This is great get status. [54:19] All right, let's do get push which now [54:22] if I go to github.com [54:24] I can see I have my mear reader says hey [54:27] what is mar example mAR code [54:31] features all the different features such [54:33] as global airport support responsive [54:37] design we don't have any screenshots yet [54:41] but I'll put those in there by hand but [54:43] we do have installation [54:47] and I can see here it says your usern [54:49] username. We need to put in this. [54:52] So, by the way, I am going to leave this [54:54] up if you want to check after the course [54:55] is done. It's going to be [54:57] github.com/jeremyorggan/codecloud-mear-re. [55:04] And here's the usage. Here's some [55:06] different airport codes. Now, because I [55:09] used Hillsbor, Hillsboro airport has is [55:12] nowhere near in the same league as LAX [55:14] and JFK and O'Hare and etc. But since I [55:17] used that as an example, I think Claude [55:19] threw it in there. Um, it says how it [55:22] works. We have a mear decoding process. [55:26] Then here we have the project structure, [55:30] development, [55:32] etc. How to put it into a Docker [55:34] container, [55:36] everything you need. So if you want to [55:38] fork the repository, [55:40] you can check it out. Does this open an [55:42] actual license file? [55:45] No, it does not. So, there's a few [55:47] things that I need to check on here, but [55:49] I just wanted to create some initial [55:50] documentation. Now, here's something [55:53] that is sort of interesting, and again, [55:56] it's something you can probably remove [55:58] if you don't want people to know this. [56:01] However, you can see right here, [56:02] contributors, two, Jeremy Morgan and [56:05] Claude. So, Claude is listed as a [56:08] contributor here because I asked it to [56:10] commit things for me. Now, like I said, [56:13] you could probably remove that. you can [56:15] remove it from the commit messages and [56:17] you can commit this stuff all on your [56:18] own without having Claude as a [56:20] contributor. [56:21] Um, but in my case, I don't care. I have [56:24] video evidence that Claude built this, [56:27] right? So, it's not a big deal to leave [56:29] it transparent, but I just wanted you to [56:31] know as a student that this does show up [56:34] here where Claude is a contributor to [56:37] the project. So, for this, this is how [56:39] we can kind of get this ready and get it [56:41] prepped for public consumption. And so [56:45] we're going to dig even deeper into it [56:47] next. And thank you for watching. Okay. [56:49] In this video, we're going to create [56:51] some Python unit tests for this [56:53] application. [56:54] And we're going to do it by using cloud [56:57] code, of course. [57:00] So one of the things you can do is do a [57:01] front slash. [57:04] And you can look here and we could say [57:05] add a new working directory, manage [57:07] agent configurations, [57:09] submit bug, etc. So, this is one of the [57:13] things that, you know, I kind of like to [57:15] just show off once in a while as we go [57:18] through and just remember that we can [57:21] export the current conversation to a [57:23] file or clipboard, which is super [57:24] important if you're wanting to keep [57:26] track of things. But I just wanted to [57:28] make sure that you knew about this slash [57:30] window. [57:32] It works. Now, one of the things I want [57:34] to do with this is say [57:36] I would like to create [57:39] a set of unit tests [57:43] for app.py. [57:47] Help me decide which type [57:50] and help implement them. [57:53] I want to use mock near readings and [57:59] test that they are [58:03] interpreted correctly. [58:07] All right. So now it's going to create a [58:08] set of tests [58:11] and we're going to take a look at some [58:12] of the to-dos and things like that and [58:14] just see how it approaches it. [58:17] First it's going to analyze the mear [58:18] decoder. [58:21] Then it's going to design test structure [58:23] using piest and mockmear data. So I was [58:26] wondering if it was going to use pi test [58:28] or something else but it's using piest. [58:32] We're going to have some integration [58:33] tests, some flask route tests and edge [58:36] case tests. [58:38] All right, let's see what it came up [58:39] with here. [58:42] We can see here we have test mear [58:44] decoder. [58:46] It's going to set up method test wind [58:48] direction, [58:50] test visibility, [58:52] test clouds, [58:54] weather phenomena, [58:56] Celsius to Fahrenheit, [59:01] and looks like we've got a good set of [59:02] tests here. So, I'm just going to select [59:04] yes. Now, one of the things that you'll [59:06] notice here is it will probably run it [59:09] for us because it likes to run things. [59:12] So, now we need to update [59:13] requirements.ext text. And here we're [59:16] adding in pi tests [59:20] and it shows how to run the tests. So [59:22] we'll do that. [59:28] So we're going to open up a new terminal [59:30] here. [59:32] pip install-r [59:34] requirements.ext. [59:37] And I forgot pip 3. Awesome. And here of [59:41] course we have piest [59:43] test app py-v. [59:48] And we can see that we have some failed [59:50] tests here. [59:53] We've got a 404. [59:56] Got a few different things here. So one [59:58] thing we could do here is just say run [60:00] the tests and analyze the output. I'm [60:04] actually glad these failed because [60:08] we want to see if Cloud Code is capable [60:10] of doing this. [60:13] Okay, we do have Python 3. [60:16] And now it's running it and it's getting [60:18] the same error message that I got. So [60:21] now it's got some to-dos here. [60:24] It's going to create a plan. And this [60:28] plan, it looks like [60:33] the only thing we're really updating [60:37] is some weather phenomena stuff. So, I'm [60:39] going to say, yeah, [60:41] let's verify our fixes. [60:45] Perfect. All tests are now passing. [60:48] And now it wants to run tests with [60:50] coverage analysis to see how much of our [60:54] application is being covered by tests. [60:56] So coverage is just how much of the code [60:58] is being tested with our unit tests. And [61:02] this gives a great example of what it [61:04] tests. Wind direction conversion, [61:06] visibility parsing, cloud layer [61:08] decoding, weather phenomena, temperature [61:09] conversion, etc. Real strings. And then [61:13] it goes through our web routes and some [61:16] edge cases. And this looks good. [61:20] Update the readme [61:22] to include testing information. [61:30] Okay. And now it says running tests. It [61:32] includes a comprehensive test suite with [61:34] 99% code coverage. [61:39] There we go. And so I'll say yes. And [61:42] then we are updating the [61:46] uh diagram that's showing the file [61:48] structure. [61:51] All right. Now I can say [61:55] create a commit message. [61:58] Commit this and push it. [62:01] Now this one might not work. I noticed [62:03] the push did not work previously, but [62:07] I think it can create a commit for us. [62:11] And now we're going to get push. [62:17] Awesome. [62:19] Now let's take a look at our repository. [62:22] And we can see the readme has been [62:24] updated. [62:27] We'll look for testing. [62:32] And there we go. Here's all the test [62:34] stuff, how to run tests, [62:38] etc. [62:40] And this is how easy it is to add [62:42] testing to your project. Now, you want [62:44] to go through, [62:46] you know, I'm kind of rushing through [62:48] this a little bit, it feels like, [62:50] because we're in a course environment, [62:53] but you just want to go through and and [62:55] look at these changes that it's made. [62:57] Really examine things and make sure that [63:00] it's doing exactly what you want it to [63:02] do, right? We want it to test all of [63:05] these different things. Look at how it's [63:07] testing it. Make sure that it's not [63:09] creating tests that are designed to [63:11] pass. and you should be good. So, this [63:14] is basically a way to add testing to our [63:17] project. Thank you for watching. [63:22] In this demo, we're going to look at [63:23] autonomous task completion. Now, what [63:26] does that mean? Well, we're going to see [63:27] how Quad Code is far more than just a [63:30] code completion tool like a lot of these [63:32] generative AI tools started out as, you [63:35] know, where they worked in an IDE and [63:37] they completed some code for you. Cloud [63:40] code goes far beyond that and I'll show [63:43] you how. [63:44] What we're going to do here is uh what [63:47] they call vibe coding a lot where they [63:49] just kind of specify an end result that [63:52] you want and you just kind of let the [63:55] tool build out what you want to build. [63:57] Now we're going to see how capable [63:59] Claude Code is. [64:01] So [64:03] we're starting out here with simple [64:05] React app. And this is just an empty [64:07] folder. has nothing in it at all. And [64:10] I'm going to say yes, proceed. [64:14] And now, here we go. Here's our tips to [64:16] get started. And we're at our initial [64:18] screen. Now, here's what I'm going to [64:21] say. We're going to try to do this in [64:23] one shot, just one prompt. Now, it's [64:25] going to take more than one, but with [64:27] one prompt, we're going to see how much [64:29] we can scale out and build something [64:31] with cloud code. So I'm going to say [64:33] create a complete authentication system [64:37] for a React application. That's the [64:41] first thing. Now that's kind of vague, [64:43] but we want to say something like [64:45] include user registration, [64:49] login, [64:50] password reset, [64:53] JWT tokens. [64:56] Let's see. Uh email verification. [65:01] Uh what else do we want to put in there? [65:04] Um a simple front end of course. [65:11] Now basically what we're doing is kind [65:12] of picture this like a funnel. And when [65:15] we start out and we'll talk about this [65:16] even more in the prompt section where we [65:19] talk about prompts, but we want to start [65:21] out with a very wide very open thing [65:24] like create a complete authentication [65:27] system. If we say that, if we just say [65:29] create a complete authentication system, [65:31] that could be anything, right? That [65:33] could be C++, it could be whatever, but [65:38] we're saying create it in React. So now [65:41] we're saying complete an authentication [65:42] system for React. So we've narrowed that [65:44] down. Then we say here's what we'd like [65:47] it to do because a complete [65:48] authentication system is very [65:50] subjective. I mean that could be [65:52] anything really but we're saying include [65:54] registration, login, password reset, JWT [65:57] tokens etc. We're being very specific [66:00] and we can also be specific about the [66:04] technologies used. We already specified [66:06] React. We could say use express [66:10] MongoDB [66:14] and we can say modern security best [66:18] practices. [66:21] Now before we we begin, let's look at [66:24] what this prompt is. And this is where [66:26] it kind of goes beyond vibe coding, [66:27] right? Because if we were just vibe [66:29] coding, we're not really specifying [66:32] much, you know? We just say create an [66:33] authentication system with a web app. [66:36] So, but let's break this down to this [66:39] prompt here that's saying it's [66:41] authentication system for a React [66:43] application. We've said all the things [66:45] it needs. We're saying to use these [66:48] technologies and to top it all off, we [66:51] say use modern security best practices [66:53] because [66:55] by default, we can assume and we've [66:57] talked about assumptions in this course [66:58] and we'll talk about them more. We can [67:01] assume as us that claude knows security [67:04] best practices. [67:06] But on the same token, claude code can [67:09] assume that we don't need them, right? [67:11] It's all assumptions. So you have to [67:12] control assumptions as much as possible [67:14] when you're building these types of [67:16] prompts. Now, let's see how far this can [67:19] get with just a single prompt. And [67:21] here's where Cloud Code goes beyond code [67:24] completion is it can create files. We [67:27] know that. We've already seen that it [67:28] can run commands in bash. We've seen [67:31] that it can run test commands. It can do [67:35] a lot of things. But can it do a npx [67:38] create react app? We don't know yet. I'm [67:41] going to assume again that it can. And [67:45] I'm assuming that in this prompt. I'm [67:46] assuming that it can do all of these [67:48] things. And so let's go ahead and kick [67:51] it off. Now, what we're going to see is [67:54] what we've already seen before where it [67:55] starts to do the thinking. It starts to [67:58] talk things through with you and for [68:00] lack of a better terms, and then it's [68:01] going to come up with a to-do list. And [68:03] here's our to-do list. Now, while this [68:06] is working, let's check out the to-do [68:07] list. If it doesn't run away from us, [68:12] it's going to analyze the project [68:14] structure, existing project structure, [68:16] which is nothing. This is a blank [68:18] folder. And then it says, "Set up [68:20] ExpressJS backend with MongoDB [68:23] connection. Install required security [68:24] dependencies. BCrypt.js JSON." See, [68:27] those are things that may not have been [68:29] installed had we not added that last [68:31] little bit on the end of using security [68:34] best practices. It's going to create a [68:36] user model with MongoDB. It's going to [68:38] implement user registration endpoint [68:39] with email verification, login endpoint [68:42] with JWT token registration, all kinds [68:45] of stuff here. And we can see it's going [68:47] to go down through this list. And now [68:48] it's come to the very first question, [68:50] the bash command. So now it knows that [68:53] it's running in bash on my Mac and it [68:55] says, hey, this is what we need to do. [68:57] Do you want to proceed? I'm going to say [68:59] yeah. And now we can see backend front [69:01] end already being created. [69:03] And here we go. Okay. So I said a few [69:06] minutes ago, is it going to know npx [69:07] react app? And it does. And it goes even [69:10] farther. It does template, typescript, [69:12] etc. And I'm going to say yes. And don't [69:15] ask again here. [69:18] And we'll just keep doing that. And [69:20] we're just going to let this thing fly [69:22] and let it do whatever it thinks it [69:24] needs to do to make this happen. Now, [69:26] we've got another question here. [69:29] And here it's saying, do we want to [69:31] install express and mongoose and brypt [69:34] and all this stuff that needs to be ex [69:36] installed for the backend dependencies? [69:38] Yeah. And I'm going to select here. [69:40] Don't ask again for npm install [69:42] commands. If you think I need it, then [69:44] install it. Okay. Now it says, do you [69:46] want to make this edit to package JSON? [69:49] Now package JSON, if you're not familiar [69:51] with Node, that's what manages all of [69:53] the packages and dependencies in Node. [69:55] Yes, and don't ask again this session. [69:57] That way we can just let it set up the [69:59] package JSON however it thinks it needs [70:01] to be set up. And we'll uh we'll check [70:03] it out once it's done. And if we look [70:05] through here while it's creating, you [70:06] can see it's already creating. We've got [70:09] two separate applications here, backend [70:12] and front end. It's creating all of [70:14] these. And now it says, "Hey, do you [70:17] want us to create the model directory?" [70:19] Yep. And don't ask for make dirt [70:21] commands. Make all the directories you [70:23] need to make. So we're essentially just [70:26] kicking back and letting Claude code do [70:28] whatever it wants to do. Whether or not [70:30] it ends up being what we want in the [70:32] end, we don't know yet, but it is we're [70:35] just letting it go. Here, let me create [70:37] the user model and database schemas. Now [70:40] we'll create the email service. Now, you [70:43] might notice this takes quite a while, [70:44] but when you think about it, it's doing [70:46] a ton of work. So, is it really taking [70:50] that long? If you were doing this by [70:51] hand, it would take days. And now we can [70:54] see we're getting down towards the end [70:55] of our to-do list. So, we can expect [70:58] this to be done any time. Okay. So, now [71:01] we can see here that we have a summary [71:04] of everything that it did. And this is a [71:06] long summary, but hey, it's been running [71:08] for 10 minutes, right? And so, we have [71:10] our backend. And it says complete [71:12] authentication system first off back end [71:15] user model with secure password hashing, [71:17] email verification and account lockout. [71:19] All of this stuff, right? It shows the [71:21] front end and all the stuff it did with [71:23] the front end. And then security best [71:25] practices, which is what we asked for in [71:27] that original prompt. It has password [71:28] complexity requirements, account lockout [71:31] after failed attempts, all the stuff. [71:33] There's key features here, and these [71:35] features are things that we asked for. [71:37] And it went a little bit further as I'm [71:39] looking at it. Like there's password [71:41] reset via email. We asked for that. [71:43] Could we ask for a protected dashboard [71:44] with user management? Not exactly, but [71:47] it created one. Responsive modern UI. I [71:50] didn't mention that, but it created it [71:52] because why wouldn't you want a [71:53] responsive modern UI, right? It makes [71:55] assumptions. [71:57] Complete error handling. That's another [71:59] thing that I didn't say needed to be [72:01] done, but Claude made that assumption [72:04] that you're going to want complete error [72:06] handling. And it decided to throw [72:08] TypeScript in there for type safety, [72:10] which is excellent. You know, that's [72:12] great. So, we have some instructions [72:15] here to get started, start MongoDB, [72:17] configure email, run backend, run front [72:19] end. It gives us all of stuff we need. [72:21] So, it says here the system is [72:24] production ready with proper security [72:26] measures, comprehensive documentation, [72:27] and a clean, maintainable codebase [72:29] structure. Now, a lot of folks say, [72:33] especially security people, do not [72:36] generate production code with AI, right? [72:38] So, we just violated that rule. So, I'm [72:41] going to say it, too. As a disclaimer, [72:44] if you're going to build things for [72:46] production for your organization or even [72:48] your personal projects, if you're going [72:50] to build something that the world's [72:52] going to see, you need to audit it by [72:54] hand and audit it personally. Now, [72:57] Claude code says this is production [72:59] ready. And you know what? It might be [73:01] production ready. Could be perfect, but [73:03] you need to check and you need to verify [73:05] and you need to make sure before you [73:07] release this stuff out to the world for [73:10] people to use. So, with that disclaimer [73:13] out of the way, let's check this out. [73:16] Okay. And I'm taking a look at my [73:17] environment file here. And I can see [73:19] that it's port 5000. Here's my MongoDB [73:22] URI, JWT secrets, etc. All right. So, [73:26] this is all my config information. So, [73:28] let's go ahead and follow these [73:29] instructions. [73:31] Now, what I'm going to do is create [73:32] another terminal here. We're going to [73:34] leave this terminal open for cloud code. [73:37] We're going to do cd backend and npm [73:40] rundev. And it looks like we're having [73:42] some issues with MongoDB. [73:44] These are some warnings, but MongoDB is [73:47] connected. I do have a MongoDB server on [73:49] my Mac here. And we'll go back to our [73:51] claude terminal here. And the next one [73:54] is our front end. [73:57] So I'll create another bash terminal for [74:00] that. [74:05] And it's asking if I want to let it [74:07] access Google Chrome, which is fine. [74:11] And look at this. We have a very nice [74:15] looking application [74:18] that we didn't have to build [74:20] and sign up for an account. [74:24] Now, I don't have my email set up, so I [74:27] don't know if this will actually work, [74:28] but h it says network error. So, there [74:33] is a little bit of a problem because I [74:34] don't have it set up to an email [74:35] account. But it's nice to see that this [74:38] is created. This looks really nice. And [74:41] with a little bit of work, I think I can [74:43] actually have an application which I can [74:45] log into and authenticate with and work [74:49] with MongoDB and Express and all this [74:52] stuff. Now, what I really wanted to show [74:54] here is, [74:57] you know, we've got this backend [74:59] application, we've got a front-end [75:00] application, we have a ton of code here. [75:03] Now, let's say that you are a React [75:05] expert. You are a developer who uses [75:09] React and every day. [75:11] You could run this simple prompt, go get [75:14] a cup of coffee or some orange juice, [75:17] let this thing run, and come back and [75:19] have it build out boilerplate that you [75:21] would build any other time. And you [75:24] could come look through the code and [75:25] say, "Okay, this looks good. This looks [75:26] good. I've done an audit. This is [75:28] great." And something that may have [75:30] taken a couple of days writing [75:31] boilerplate code is instead done in 30 [75:35] minutes. [75:36] So what have we learned here about cloud [75:38] code in this as far as autonomous [75:41] building? Well, independent problem [75:43] solving, right? It made a bunch of [75:45] architecture decisions. Some of it with [75:47] us, some of it asked us, and then some [75:49] of it made assumptions and said, I think [75:51] you want to do it this way. [75:52] Multicomponent orchestration. I mean, [75:55] there's a whole bunch of stuff going on [75:56] in this back end. There's a bunch of [75:58] stuff in the front end. The production [76:00] readiness part where it says, "Hey, this [76:01] is ready for production." Again, you [76:04] know, there's that standard disclaimer [76:05] that you don't want to just generate [76:06] things and dump them into production. [76:08] However, it does include in here testing [76:11] and documentation and security things. [76:14] You know, this can be adapted basically [76:17] for creating apps from the very [76:20] beginning. Like if you've got green [76:21] field apps, this is a great way to [76:23] create like a proof of concept where you [76:26] go to your boss and you tell them, "Hey, [76:28] I've got this idea to do this thing." [76:30] And they're like, "Okay, show me." And [76:31] they'll think about it. You can come [76:33] back here to cloud code and say build [76:35] this thing that's exactly like this. [76:38] Show it to your boss and your boss says [76:39] that's great. Let's do this. She signs [76:42] off on it. Then you just go back and [76:43] either modify what Cloud Code generated [76:45] or you could generate it your way. [76:48] Either way, this is one of the big [76:50] benefits of Cloud Code is it's very [76:52] autonomous. It's very independent and it [76:55] can be super useful for doing things [76:58] like this. So, I just wanted to show um [77:01] kind of the autonomous task completion [77:04] and how it all works and things like [77:06] that. Now, in the next few videos, we're [77:08] going to do even more with this, but [77:10] thank you for watching. [77:12] In this video, we're going to talk about [77:14] Cloud Code's environment and some [77:16] configuration, just kind of settings [77:18] that we can work with. Now, user [77:22] settings is in your settings. I'll show [77:24] you where those are located. And these [77:27] are going to be your personal settings. [77:30] So I'm on a Mac, so it will be included [77:36] settings.json. [77:38] And it'll be the same for Linux. In [77:40] Windows, it should be under [77:44] uh program data cloud code and in that [77:48] folder. So let's just open this up in [77:51] code. Okay, we'll do a Vim. [77:54] And here I don't have much, right? So I [77:57] can add all kinds of stuff in here and [78:01] we'll do that here in a little bit. But [78:03] for the most part right now, it's just [78:05] just some real basic stuff. Just shows [78:07] the schema, what it's supposed to look [78:09] like, etc. [78:12] Now, there's another one here, another [78:14] couple of places. So we'll go out of [78:17] this. So settings.json is basically the [78:20] settings that you use on your machine. [78:24] Now if you want to create something in [78:28] your project folder here you can create [78:32] a cloud folder [78:37] and in here you could create something [78:40] like [78:42] settings.json [78:44] which is what we just had in my user [78:46] folder. Now this is going to be the [78:48] settings for the project. Now, these [78:51] ones are settings that are checked into [78:53] source control and shared with the whole [78:55] team, right? So, I'll show you a good [78:57] example of a settings JSON from Cloud's [79:01] documentation just so you can see what [79:03] it looks like. Here's a typical set JSON [79:06] where we say we allow bash npm run lint. [79:10] We allow npm run test. [79:13] We can read the our Zshrc. [79:17] Um, and then it says deny curl, can't [79:21] read environment files, can't read [79:23] secrets. [79:24] Um, and then we have a couple [79:26] environmental settings here. Now, [79:27] there's a ton of different environmental [79:28] settings that you can choose, but here, [79:31] like we have cloud code, enable [79:32] telemetry, hotel, metrics, exporter, [79:35] etc. So, let's say this is a typical [79:39] cloud code settings file. Now, what if [79:43] you want something that's settings that [79:45] aren't checked in? So, this is a little [79:48] more for personal preferences. Now, [79:50] settings.json that's in your root folder [79:53] um is obviously going to be your [79:55] personal settings for cloud code that [79:57] you want to use everywhere. But you [79:58] might want to use personal settings per [80:01] project. And that's where this comes in. [80:02] So, in here, we would create [80:06] settings.local.json. [80:10] Now, this won't be checked into source [80:12] control and it's useful for things like [80:15] personal preferences, experimenting, [80:18] things like that. Um, and basically [80:22] cloud code will configure git to ignore [80:25] this uh file if it sees that it exists, [80:28] right? So, it will put it in a git [80:30] ignore and you won't see it. Now, for [80:34] enterprise deployments of cloud code, [80:36] they have enterprise manage policy [80:39] settings. And so in there um I'll just [80:43] show you the [80:45] location where that would be located. On [80:48] Mac OS it would be library application [80:51] support cloud code manage settings. [80:53] Linux or WSL will both be etsy [80:57] cloud-code [80:59] manage settings. And then Windows it's [81:01] going to be manage- settings JSON [81:03] located in program data cloud code. So [81:06] that's if you want to set enterprise [81:08] level stuff. [81:10] Now there's a whole bunch of different [81:12] settings that you can put in here, [81:14] right? And let's let's copy our settings [81:16] here. [81:19] And we have things like permissions, [81:21] allow, etc. [81:24] Um there are different settings in here [81:27] like we have environment keys. Now, we [81:29] can just put base level settings in [81:31] here, such as how long do we retain chat [81:35] transcripts, for instance, in days. [81:37] Default's 30 days, but you could put [81:39] cleanup period days [81:42] 20 or even seven. And we can actually [81:46] we'll pull these out here and just make [81:49] our personal file. Now, there are [81:51] certain things that you can put in that [81:52] that's in the documentation. There's [81:54] things like the allow, right? So, we had [81:57] permissions, allow for this. There's all [82:00] kinds of different stuff you can do [82:02] here. You can put in all the different [82:04] tools that you can use, um, things like [82:08] that. Web fetch, you know, curl, all [82:11] these types of things that you could put [82:13] in here if it's part of using that. [82:18] Or if you decide you don't want folks to [82:20] use that, you can go into the deny here. [82:23] You can do a default permissions mode in [82:26] here. [82:29] Can say default mode and we can see here [82:32] accept edits, bypass permissions, [82:34] default and plan. So there's quite a few [82:37] different things that you can do with [82:39] this. Um you can also add additional [82:41] working directories [82:44] to this by saying additional directories [82:50] some other [82:53] project. Right? So you can put that in [82:55] there. Um there's all kinds of cool [82:58] stuff that you can do. If you go to this [83:02] URL and I'll just put it on the screen. [83:05] httpsdocs.anthropic.com/doc [83:07] anthropic.com/en/doccks [83:10] claude-code settings. You can see a [83:13] whole bunch of different settings that [83:16] you can do. Now, let's talk about the [83:18] configuration system [83:22] in a little bit more detail. [83:25] So, there are some other files that you [83:26] can do here. Um, you can do cloud.md, [83:29] which has instructions and context that [83:31] cloud loads at startup. So I can go in [83:34] here, say new file, [83:37] cloud MD. Um, and this thing you could [83:40] actually tell Claude, [83:43] create a claude.md [83:46] file for me. [83:49] That would be typical in a Python [83:52] application. [83:55] It starts to think about it. And it did [83:58] say illegal operation on a directory [84:00] maybe. Uh yeah, I've actually [84:06] some of this out. But here [84:09] it's created a Claude MD for me. So I'll [84:12] say yes, I want to make this edit. Now [84:15] let's check out our CloudMD that it [84:18] created for us. [84:20] We can drop that in the cloud folder [84:24] if we like it. And here it says MIAR [84:28] reader application. This is a Flask web [84:29] application that decodes mear aviation [84:31] weather reports. Um it shows how to set [84:34] up the environment, how to run the [84:36] application, how to test it, and then [84:38] there's some code quality stuff here. So [84:40] basically with this we're giving Claude [84:44] some context and we're telling it so [84:46] anytime you run cloud code it's going to [84:48] go through this file and we're telling [84:49] it look for code quality you can install [84:51] these let's use this for linting right [84:54] flake 8 [84:56] etc. For code formatting, let's use [84:58] black app. py test app etc. And it has [85:02] the dependencies. So it tells cloud [85:04] code. Here are the dependencies that we [85:06] have here. Uh we have requests [85:10] etc. Then the project structure [85:13] basically telling cloud code this is [85:14] what it looks like. So, this is what [85:17] Claude Code calls a memory file, and [85:20] it's basically instructions and context [85:22] that loads at startup, and you can type [85:24] in all kinds of stuff in here. Um, [85:27] there's also the settings files that we [85:30] just looked at. There's slash commands, [85:32] too. And so, you can add different [85:34] configurations with this. So, manage [85:36] this list and manage background shells, [85:39] things like that. Config theme. And this [85:43] configures some preferences here. Use [85:45] to-do list. True. Now, the to-do list, [85:47] we've seen this in action, right? And I [85:50] like the to-do list. Maybe you don't. [85:52] You can actually turn it off here, but [85:54] I've seen the to-do list where it goes [85:56] through and it shows me all the stuff. I [85:57] like it. Checkpointing. We want that to [86:00] be true because you can run into some [86:02] things where Cloud makes some changes [86:03] and they break everything and you're [86:04] like, "Ah, let's roll that back." That's [86:06] where checkpointing comes in. Um, [86:08] verbose output, auto updates, the theme, [86:12] we had a dark mode, auto notifications, [86:15] normal editor mode, model, this is [86:18] pretty important, right? Because you can [86:19] change between different models. We have [86:21] a diff tool, just selecting auto and [86:25] auto install ID extension. So, these are [86:27] all configuration [86:29] things that you can do. Now, here's [86:31] another thing that we want to think [86:34] about for when you're hiding sensitive [86:37] files. So, we're going to go back to our [86:39] permissions a little bit here. And in [86:42] our settings, see how we have allow and [86:44] deny, [86:45] etc. Now, one of the best things you can [86:48] do is this right here. Don't let it read [86:51] a secrets folder, for instance, or a [86:54] build folder, things like that. And [86:56] these are sensitive files. I mean, [86:58] that's why they call them secrets, [86:59] right? So this is something that's very [87:01] important to know is that you can allow [87:04] cloud code to look at your entire [87:06] application but you can say hey nothing [87:08] in this folder or nothing of this file [87:10] name etc things like that. So I just [87:13] kind of wanted to show some of the [87:16] configuration options and how you can do [87:18] it. There's a ton of environment [87:20] variables you can change here. You can [87:22] change you can put in your API key. You [87:25] can put in uh the model you want to use. [87:29] You can do all kinds of stuff. Um you [87:31] can tell it whether you want it to go to [87:33] bash and do bash stuff or not. You can [87:36] do all kinds of stuff. And again, that's [87:38] at that URL [87:40] docsanthropic.com/en/doccks/cod-code/ [87:45] settings. Now, here's another cool thing [87:48] to check out. You can type in claude [87:51] config list. And it looks like we've got [87:54] an error this time. But you'll have to [87:57] trust me when I say that a lot of times [87:59] this works. [88:01] For some reason, it's not working great [88:03] here. But you can do claude [88:05] config list. You can do claude config [88:08] set. So you can say cla [88:11] what did we configure up in here that we [88:14] could look at? [88:16] Config set. And then you can type in [88:19] different keys and different values. [88:22] Like I can say cloud code enable [88:24] telemetry. Put that to zero. And like I [88:28] said, it looks like we're having a [88:29] little bit of an error with this, but [88:32] just know that most of the time you can [88:33] list settings with cloud config list. [88:36] You can see a setting with cloud config [88:38] get and then whatever the setting is. [88:40] We'll try that. We'll see if that part [88:42] works. [88:44] Cloud config get. Nope. None of these [88:48] seem to be working right now. So, and it [88:50] seems to really dislike this setting in [88:54] particular. So, [88:56] here's our different keys. Now, it [88:58] should work where we can say cloud [89:00] config list. There we go. And we can [89:03] list some config things like allowed [89:05] tools has trust dialogue accepted, etc. [89:09] And this is based on this settings local [89:13] JSON [89:15] having basically nothing in it. But you [89:17] can grab your settings. You can config [89:19] settings, things like that. You can set [89:22] a global configuration for something [89:25] like auto updates. You would do claude [89:29] config set-g, [89:31] right? And then the key could be like [89:33] auto updates [89:37] true. [89:39] And so that sets it so cloud auto [89:41] updates. You can do the color theme [89:47] and just set this [89:49] global [89:50] theme dark, which it already was set to [89:55] dark, but let's set it to light. [89:58] And now it looks a little different. [90:01] So, that's the configuration settings. I [90:04] just kind of wanted to show how these [90:06] work and how the memory file works, [90:09] things like that. And you can configure [90:11] Claude Code to do a lot of really cool [90:14] different things. So, thank you for [90:17] watching. In this session, we're going [90:19] to look at managing long sessions [90:20] effectively. So, you'll might have short [90:23] sessions where you just go in and ask a [90:25] question or two and you pop out, but [90:27] you'll also have longer ones. And so, we [90:29] need to take a look at what that looks [90:31] like. And the way that we're going to do [90:33] that is by building a fairly complex [90:36] application with a series of prompts. [90:38] And we're really going to try to push [90:40] that context envelope to its maximum. [90:44] And so what we're going to do is we're [90:46] going to build a web-based Flask [90:49] application that does image [90:51] optimization. So what we want to do is [90:53] reduce the quality of an image, reduce [90:56] the colors, things like that. And a lot [90:58] of this is going to require OpenCV. It's [91:00] going to require some different command [91:03] line things. And it's going to be a [91:06] somewhat long project. So we'll start [91:08] with a prompt. [91:10] Now, we're going to talk in the next [91:12] session about managing effective [91:14] prompts, writing effective prompts, and [91:16] so we'll touch on some of the stuff that [91:18] we do here. But for now, I'm going to [91:21] drop in a prompt to show you exactly [91:23] what I'm talking about when we say [91:26] writing a very specific prompt and it's [91:28] going to kick off this very long context [91:32] type operation. Okay, so here's how [91:34] we're going to put this together. First, [91:36] we're going to start with requirements, [91:38] right? Now, I have a list of [91:39] requirements here that I'll just paste [91:42] in. One of the first things I'm going to [91:44] say is [91:46] build a single [91:50] image optimization web app [91:55] using Flask. [91:57] And then I'm going to hit control enter [91:59] and I'm going to dump in my [92:00] requirements. [92:04] Now, let's take a look at these [92:05] requirements. So, I want a Flask web UI [92:06] with drag and drop upload. I want to [92:09] support JPEG, PNG, WEBP. Uh, we'll [92:12] reject SVG and GIF. We're going to rate [92:15] limit this to 30 requests per minute per [92:18] IP. Uh, because we're going to host this [92:20] publicly, we don't want it to get [92:22] flooded. Allow a maximum of 25 meg [92:26] upload size. Autocle temp files. So, we [92:29] don't want to keep the people's images [92:31] that they're optimizing. We just want to [92:33] optimize them, send them out the door. [92:36] Show before uploaded image and [92:38] placeholder after pane. Use pillow for [92:40] image IO. Keep open CV available for [92:43] future features. And docker guised with [92:46] unicorn for production. [92:50] And we might actually remove that one [92:53] because we're going to do some [92:54] deployment stuff later. [92:57] Now we want to put in the deliverables. [93:00] We want a complete flask app with HTML [93:03] elements, the requirements text, things [93:05] like that. So we will dump that in here [93:10] and we're going to say we want a [93:11] complete Flask app structure with [93:13] routes, config, validators, and cleanup, [93:16] HTML templates, static files, and [93:18] requirements.ext. [93:20] So since we've been so deterministic [93:23] with this, we're basically saying this [93:25] is exactly what we want. This should [93:27] start kicking off and firing off things. [93:29] And we can add more later. [93:34] So, I'm going to press enter and let it [93:36] go. You'll notice the to-do lists that [93:38] are coming up here. And these to-do [93:40] lists are pretty long. Now, we get our [93:43] first question here that says, "Do you [93:45] want to make this edit to app py?" I'm [93:47] going to say yes. And don't ask again [93:49] this session. Just create whatever needs [93:51] to be created. Okay. Okay, now we're [93:54] getting to the bash commands where it [93:55] says, "Hey, do you want us to make [93:57] templates?" Things like that. And I'm [93:59] going to say again, yes, and don't ask [94:02] again for maker commands. Make all the [94:03] directories you need to make. Okay. Now, [94:06] surprisingly, it says, "Hey, this app is [94:08] ready to use at localhost 5000." So, [94:12] let's take a look at what we have here. [94:13] We have app. py. It's loading in flask [94:17] request, render template, jsonify, [94:19] senfa, a whole bunch of stuff here. But [94:22] before we go and audit it, let's just [94:24] run it. Right. It says that it's ready [94:27] to use at localhost 5000. And when I [94:30] bring it up in a browser, it says it's [94:33] access denied. So, it's possible that [94:36] this isn't running yet. So, I can put in [94:40] here. I'll copy and paste this error [94:42] message [94:45] I am getting. And if you hold down shift [94:48] and enter, you can do multiple lines. [94:52] How do I run this? Now, we know how to [94:54] run this, but this is one of the things [94:57] I want to show to kind of add to the [94:59] context of [95:01] our conversation. [95:05] And it says, "Yeah, pip install. Do you [95:08] want to do this?" Sure. We'll do a pip [95:10] install requirements.ext. [95:12] And it doesn't look like it's creating a [95:14] virtual environment, [95:17] which could be a problem. So, we're [95:19] going to go back and say, "Hey, we need [95:20] you to create a virtual environment." [95:23] Now, if we look at this here, and this [95:25] is the first time that we've done this [95:26] in this course, it says, "Now, let's run [95:30] the Flask app. Python 3A app. py. Do you [95:33] want to proceed?" Yes. Yes. And don't [95:35] ask again. But now, we're going to [95:37] select no and tell Claude what to do [95:39] differently. This is, like I said, the [95:42] first time we've done this in this [95:43] course. We're going to say [95:46] I want to create a Python [95:50] virtual environment [95:56] for this application. [95:59] Now what it's going to do is it's going [96:00] to create an environment and install the [96:04] requirements from requirements.ext in [96:06] it. And it says, "Hey, do you want to do [96:09] Python 3-m VNV?" VNV. Yeah, that's [96:12] exactly what I want you to do. It says, [96:14] hey, do we want to activate and then [96:16] install it requirements.ext? Yeah, we [96:19] do. And it says, do you want to run it [96:21] in a virtual environment? And yes, we [96:24] do. And it looks like it's having a [96:26] little problems with the output there. [96:28] And it's kind of fixing itself. It's [96:31] asking us, do you want to run it again? [96:33] Let's try running it. And we've got some [96:35] more issues here. [96:37] So, we're just going to let Cloud Code [96:40] work through those issues. and fix [96:41] everything. Now it says, "Hey, [96:43] everything should work perfectly." And [96:44] look, we have a to-do list with a list [96:46] of features, right? So, activate the [96:48] virtual environment. [96:52] And I'm assuming that that's something [96:54] that we're going to have to do here. So, [96:58] it's not going to do it for us [96:59] automatically. Let's create another bash [97:01] terminal. [97:03] And in that bash terminal, we'll go down [97:05] here and say source bnv bin activate. [97:14] And if you're a Python developer, this [97:16] is all pretty basic stuff, but we're [97:17] just going to copy and paste exactly as [97:20] it says to do. Python app.py. [97:30] Oops. and it's going to be Python 3 on [97:32] this machine. And we have a problem [97:35] here. It says port 5000 is in use by [97:37] another program, but it's not. So, [97:41] what we need to do is find out why. [97:45] So, we'll copy these warnings. [97:48] We'll put it in here. Now, it's going to [97:50] try to change it to a different port. [97:52] Now, see, this is one of the things that [97:53] I wanted to bring up in here and I [97:55] wanted to kind of expose in this video [97:58] is that when your context starts to get [98:01] longer, [98:02] now every tool will say we have the [98:05] longest context and it'll have a huge [98:06] amount, but as your context starts to [98:09] get longer, you will notice a little bit [98:12] of hallucination or weird things like [98:15] this where it's saying, "Hey, if port [98:16] 5000 is blocked, then let's just change [98:19] it to port 50001." Now, we know that [98:22] port 5000 is probably [98:25] being locked by an older version of this [98:28] application. [98:30] Now, it's not coming up, so it's not [98:32] working. But I'm going to say no and [98:34] claude what to do differently. And I'm [98:36] going to say, [98:38] how do I find out what's running [98:42] on port 5000 [98:46] and stop it? And we can even say I am [98:50] using Mac OSX even though it knows this. [98:54] It knows what operating system I'm [98:56] running, but it's it's kind of handy to [98:58] throw it in there sometimes just in case [99:01] Claude doesn't exactly know where it is. [99:04] It's going to say, "Hey, we'll do lsof- [99:07] i." Yeah, that sounds good. I'm familiar [99:10] with that command. Let's see what it [99:11] does. Next thing it says, hey, do you [99:14] want to kill this process? [99:17] Port 5000 used by control center. This [99:19] is likely the AirPlay receiver mentioned [99:22] in the error. Yeah, we'll proceed. I [99:26] don't think I need AirPlay right now. [99:28] And I was assuming it was actually our [99:30] app locking up port 5000, but it doesn't [99:33] look like it. But it's still saying [99:35] let's do it on port 50001. So yeah, [99:38] fine. We'll do it on port thou 50001. [99:41] Okay. And says it's ready to use. So [99:44] let's find out. We're going to take our [99:46] browser here and say port 50001 instead [99:49] of port 5000. And look at this. We've [99:51] got an image optimizer. Awesome. Drop [99:54] your image here or browse files. This is [99:58] great. Let's try it out. Okay. So, one [100:00] of the first things I'm going to do is [100:02] go to my pictures here and drag and drop [100:04] this picture of my family. That's my [100:07] greatgrandfather and my grandfather and [100:10] several great aunts and uncles. [100:13] And it says image optimization feature [100:15] coming soon. [100:17] What does that mean? Well, we'll copy it [100:23] and find out. But other than that, I [100:24] mean, this looks pretty nice, right? Can [100:28] browse files and probably go that. But [100:31] the image optimization feature is not [100:33] ready yet. [100:35] So I can go in here and say [100:40] I am getting the error [100:44] optimization not ready yet. [100:48] And that's all I'm going to say. This is [100:50] Hey, it says it's not ready yet. Okay. [100:52] Now we look at it and it says image [100:53] optimization is now working. New [100:55] features. We've got real image [100:57] optimization using pillow with quality [100:59] compression before after compression [101:01] compression ratio display [101:03] etc etc etc. [101:06] Well, let's see if it's actually [101:08] changed. [101:10] We've got our image optimizer open here [101:14] and we can browse and drop the image. [101:18] So, I'm going to take this picture [101:19] again, the Morgans [101:22] and it says image optimization coming [101:24] soon. So, we'll refresh it just to be [101:27] sure. [101:30] And now we do have some optimization [101:33] options here. Now, this one is 99 by [101:37] 704. It's 1,91 kilobytes. This one, we [101:41] can see we saved 91.9%. [101:44] And now it's 90.84. We can hit optimize [101:47] image, which that button doesn't seem to [101:50] do much, or download optimize, and that [101:52] will download it to our downloads [101:54] folder. So, we're getting somewhere. [101:57] But now, we're going to put in even more [101:59] prompts. We're going to add in some [102:01] features to implement. And I'm going to [102:04] say [102:06] I would like to add the following [102:08] features. [102:12] And let's look at the features here. A [102:14] quality slider for JPEG WEBP. Resize by [102:18] percent, 200%, 1000, whatever. [102:22] Strip metadata toggle. So we can strip [102:25] out metadata that's in there. Strip out [102:27] XF data. Speed versus quality presets. [102:31] Update UI to show live preview of [102:33] parameters. Produce a real after image [102:35] and show it side by side with before. [102:36] Keep no retention. Delete the temp files [102:39] after the response. And then hit enter. [102:44] So in here I'm basically putting in more [102:47] features. And we're just going to keep [102:48] adding more. And we're going to make [102:51] this context as long as we possibly can [102:54] to see if it starts spitting out some [102:56] errors. [102:59] Okay, now we've got a result here [103:03] and it's showing all of the features [103:04] that it added, right? So, advanced [103:06] features now available, new controls, [103:09] speed versus quality presets, smart [103:11] features, backend improvements, how to [103:15] use it, etc. [103:17] So now, of course, we'll bring up our [103:19] image optimizer and we'll refresh it. [103:23] It says, "Drop your image here." We'll [103:25] drop in this picture. And now we see a [103:28] bunch of new options. We've got quality [103:31] all the way down to one, all the way up [103:33] to 95. We've got resize, [103:38] percentage. [103:39] We can say we want speed, we want max [103:42] quality. [103:45] So, for this one, I'm going to say max [103:47] quality. [103:49] We're just going to leave it at 100%. [103:52] We have options to strip the metadata, [103:55] the auto orient, and the quality. Let's [103:58] set our quality to like five and see [104:00] just how bad this image looks. So, we'll [104:03] click on optimize image, and we can see [104:06] that we don't have [104:09] output. [104:12] Now if we look at some of the console [104:14] output we can see some evidence of a [104:16] problem. [104:18] So I can take this and copy console. It [104:20] says failed [104:22] Morgans.phd failed to load the server [104:24] responded with a status of 500 internal [104:27] service error. [104:30] So I'll just dump that in there. [104:35] And our text here says hey internal [104:38] service error. The server responded with [104:41] a status of 500, etc. And we'll see if [104:44] Claude can figure this out. And it has. [104:46] It's showing some stuff here where it's [104:48] trying to uh looks like add a little bit [104:51] more error correcting. Try uploading an [104:53] image now. So, I'm just going to reload. [104:57] We'll see if Claude has fixed the issue. [105:00] So, I'm going to move that quality way [105:02] down. Click optimize image. And there it [105:05] is. [105:06] Now, this is the reason I moved the [105:08] quality down is to test it. If we put [105:11] the quality at one and click optimize [105:14] image, [105:15] you can see it looks pretty terrible. [105:18] If we do quality 95, [105:21] and it looks like we're still having [105:23] some errors here. So, I'll just do this [105:26] one at a time. Now, this one we do [105:28] quality 95. [105:32] while the other one that we show is [105:35] relatively the same quality. [105:39] So, I'm going to copy this [105:43] and let Claude know, hey, we're still [105:45] getting an error. Okay, now it's saying [105:47] that it made a bunch of changes. You can [105:49] upload an image once, optimize multiple [105:52] times with different settings, see [105:54] realtime changes as you adjust sliders [105:56] and presets, and compare different [105:58] optimization results. So the problem was [106:01] I was trying to optimize something after [106:04] I'd already done it, right? So I had [106:06] loaded this up, optimized an image, and [106:08] I tried to optimize it again, and that [106:11] didn't really work. So now Cloud Code [106:14] knows what we're trying to do. So I can [106:17] click optimize image. I can slide it [106:20] back and click optimize image quality [106:23] one. Well, quality one looks terrible. [106:26] This looks like the pictures we used to [106:28] see in the '9s, right? [106:32] But if I go to 95, it's there. And if I [106:35] want to make it bigger, [106:38] I can make it bigger [106:40] or smaller. [106:42] Now we've made it into a little [106:44] thumbnail. Look at that. [106:47] Or we can make it bigger. [106:52] So our application is getting really [106:55] advanced and really good. So let's try [106:58] to add a few more things to it. And [107:00] again we're trying to build up this [107:02] context to see how big we can get it and [107:06] see what kind of things happen when we [107:07] do that. Now the whole reason for doing [107:10] this of course is you know we're [107:12] building up this application. We're kind [107:14] of starting out with a base level. We're [107:16] adding more features etc. But what we [107:19] want to do is put this into a session [107:22] and think about it like a session. So it [107:23] really is a session here that we're [107:27] working with and it's goes all the way [107:29] up to the very beginning where we kind [107:31] of describe the application. Um but what [107:33] we want to do is start taking notes on [107:35] this and keeping track. Now why do we [107:36] want to do this? There's two different [107:38] reasons. For one, cloud code getting a [107:41] large context will cause problems. So, [107:44] one of the impressive things about [107:45] Claude Code is that the context is [107:48] enormous. I mean, relatively speaking, [107:51] compared to other tools, you can carry [107:53] on these conversations for a very long [107:55] time. Um, I've built some random things [107:58] where I've just tried to keep going and [108:00] going and going and going and eventually [108:02] it does start to have some issues and [108:05] hallucinate a little bit, but it takes a [108:07] really long time. [108:09] But when we create the session notes, [108:11] we're creating notes for us so that we [108:13] can say, okay, this is what we did here. [108:16] This is what we did here. But another [108:18] reason to have session notes is claude [108:20] code will look at these session notes. [108:22] So one of the things I'm going to do is [108:24] we're at a good place here in our image [108:26] tools, right? [108:29] So I'm going to say get add. [108:33] We're going to add all of these files. [108:35] And we've created quite a big [108:37] application here. We're going to commit [108:38] it [108:43] initial application. [108:47] Okay. And so we're committing that and [108:50] we're saying at this point this is where [108:51] we're at. Now I want to go over here to [108:53] cloud code and say help me create [108:57] a session notes.md [109:01] for this project. [109:04] And now it's puzzling. And like I said, [109:07] there's always some kind of funny verbs [109:08] that they come up with here. Now, what [109:10] I'm doing is with this prompt is I kept [109:12] it very simple and direct. And I'm [109:14] assuming Claude knows what I'm talking [109:17] about when I say I want to make a [109:18] sessions session notes.md. [109:22] Okay. And there it is. When I click on [109:24] this first, we'll take a look at this. [109:26] And it says, hey, I've created a [109:28] comprehensive session notes MD file. And [109:32] like I said, this is something that's [109:33] for us and it's for other developers [109:36] that are going to jump into your project [109:37] and cloud code itself. Cloud code will [109:40] look at this file and kind of know what [109:42] it did in the past. [109:45] So we can see here what's included. We [109:46] have project overview and feature [109:48] summary technical architecture [109:49] breakdown. This is all of the stuff [109:52] here that we have done. And when we look [109:54] at session notes MD, we can see this is [109:57] all the stuff that we've done in this [109:59] single session. [110:02] So we did some advanced optimization [110:03] controls, user experience, backend, [110:06] front end, file structure, all of the [110:09] stuff was created in this session. It [110:12] says project completed successfully. [110:14] However, if we want to, we can start [110:17] updating this cuz we're going to do some [110:20] additional stuff. So I'm going to say [110:25] up here I'll just put and this isn't [110:28] really uh kind of carved in stone set in [110:32] stone law about a way to do this but we [110:34] can say session one completed [110:38] here [110:39] just to you know say and here it's [110:43] trying to put in a date but here it just [110:46] says session one completed and then all [110:48] of this stuff. Now I can say down here [110:51] session two [110:53] and we could say something like session [110:56] two focus what we want to do with [110:59] session two [111:04] implementing [111:07] advanced features. [111:10] Sorry can't really type today. [111:13] Now, I want to add in some stuff here, [111:15] like I want to add in sharpen controls. [111:20] And we can even describe what we want it [111:22] to do. Sliders for sharpening, blur, [111:24] contrast, brightness. That actually [111:26] sounds great. We want to add in [111:28] something like format conversion. [111:33] And what do we want to do for format [111:35] conversion? Well, the ability to convert [111:37] between formats. Looks like that's a [111:40] pretty good suggestion there. And this [111:42] will be kind of a stage three, right, of [111:44] this just kind of adding some extra [111:46] polish. Now I can keep this in the [111:48] session notes and then go down here and [111:51] I can just copy this in [111:54] and say [111:57] something like I would like to add in [112:01] additional features [112:05] outlined [112:07] in session notes. [112:12] And then I can put it in here too to be [112:14] firm about it and say I want these [112:16] sharpen controls. I want this format [112:18] conversion and then we'll hit enter. So [112:20] this is the first part of managing a [112:21] session is actually using the session [112:23] notes. And now that we have gotten [112:26] pretty far with this thing, we can go [112:29] back and look at some of our session [112:30] information also. All right, looks like [112:33] we're done. Well, at least Cloud Code is [112:35] done with what we've asked it to do. [112:38] Let's take a look at it. Session two [112:41] advanced features complete. I've [112:43] successfully implemented all the [112:45] requested advanced features. New image [112:47] enhancement controls. We have a sharp [112:49] and blur slider, a contrast slider, [112:51] brightness slider, and format [112:53] conversion, enhanced UI layout, three [112:55] column responsive grid for better [112:57] organization. I didn't ask for that. But [112:59] again, cloud code makes a lot of [113:01] assumptions. And sometimes those [113:03] assumptions are things that I should [113:06] have put in. And a year ago with a [113:07] different tool, if I didn't put that in, [113:09] it wouldn't happen, right? So some of [113:11] this is like cloud code can look at it [113:13] and say this is a lot of features for [113:15] this tiny window that we have right now. [113:17] So we're going to redo it. Um and it [113:19] made it mobile responsive [113:22] format flexibility [113:24] etc. I think we should try it out. But [113:27] first I'm going to say [113:31] this is great. [113:33] Please add it. Well actually let's try [113:35] it out before we add it to our session [113:37] notes. [113:39] So, we're going to try this out. Okay. [113:42] So, we're going to reload our image [113:43] optimizer and I'm going to click browse [113:45] files. We're going to take that same [113:47] file [113:48] and we can see we have some additional [113:51] settings and we have balanced speed max [113:54] quality. Same as before. However, I can [113:57] see here we now have a sharpen real [114:00] sharp really blurry. Let's try that out. [114:03] Optimize image. There is a very blurry [114:06] version of it. We'll go over here to [114:08] sharp [114:12] optimize image and we can see that the [114:15] sharp doesn't quite work. Now why is [114:18] that? Well, it might be because [114:22] it was unable to sharpen [114:28] after we blurred it. Ah, we can see a [114:31] problem here. Float object cannot be [114:33] interpreted as an integer. So, I'm going [114:35] to click that again. [114:38] Copy this [114:42] and we can go into cloud and say [114:46] I'm getting an error [114:49] when sharpening [114:52] and dump in the air. And this is pretty [114:55] basic stuff we've all done a million [114:57] times [114:58] at this point. Okay. And it says it [115:00] should work smoothly now. So, we're just [115:02] going to blindly trust that it will open [115:04] up this image again. [115:08] Sharpen optimize. There we go. And this [115:11] is actually a sharper image [115:14] here. So, let's try contrast. [115:18] And we'll just go with extreme contrast. [115:23] Doesn't seem to be doing much. [115:26] We'll go with low contrast. And maybe we [115:29] have to upload the image again. So, [115:33] we'll load this up [115:35] and say I want to do max quality, [115:39] a little bit brighter, [115:42] little more contrast, and a little more [115:44] sharp. [115:46] Optimize image. And then I say, okay, [115:49] that looks good. I can click download [115:51] optimize. [115:55] And there we go. [115:57] We can see our optimized image. [116:01] So this is pretty good for this second [116:03] set of features here. So the only thing [116:06] I will say is [116:09] I noticed [116:12] when I apply one setting [116:16] or I should say when I change [116:19] one setting [116:21] and apply it. [116:24] Then I have to re-upload [116:28] the image to make another setting [116:31] change. Can we make it so that it and [116:33] this is going to be a significant [116:35] refactoring by my guess so that we can [116:40] make several different changes [116:44] that will take place anytime we hit [116:48] optimize. [116:50] So I hope I'm being fairly clear about [116:52] that. [116:54] Okay. And it looks like it's done here. [116:56] Now, upload your image once, optimize [116:58] multiple times, and see real time [117:01] results. So, let's see. We'll reload our [117:05] image optimizer [117:07] with our image, [117:10] and I'm going to say sharpen, optimize [117:13] image. Okay, that is sharper. Then I'm [117:15] going to go to blur, [117:17] optimize image. Still doesn't quite [117:20] work, but we can put that in like a [117:22] to-do or something. and try to get [117:24] Claude Code to do it again. Because it [117:27] looks like now that we've done one [117:31] change, [117:32] we really can't do any other changes to [117:34] it. It's kind of a oneshot deal. Just to [117:38] make sure, I'll do a hard refresh. [117:42] Do it again. But it still looks like [117:43] you've got one shot basically. So, we'll [117:46] reduce the quality. We'll blur it. We'll [117:49] up the contrast. Up the brightness. If [117:51] we do all these at the same time, then [117:54] we get exactly what we look for. But if [117:55] we try to undo [117:59] that, [118:01] we can't. And some of it [118:04] is kind of the nature of images and that [118:07] you can't really take add quality back [118:09] to an image, right? So you can save an [118:11] image high quality, but being the nature [118:14] of the format, you can't just add the [118:16] quality back in. So I think for now we [118:19] could say it's okay that this is a [118:21] oneshot thing and maybe it's something [118:24] that we'll fix later. Now I can say [118:28] this will work. Can you update session [118:32] notes [118:34] with this information? [118:37] Now in here this technically is still [118:39] session one right? So [118:43] if we look here performance metrics etc. [118:47] Now that I look at it, it looks like it [118:49] already did update this for me. So if I [118:52] go up here, it says session two [118:53] completed advanced stamp and there's our [118:56] sharpen blur slider, etc. So it did [118:58] already [119:00] do it for us. Now we'll look here [119:06] and says here's what was added. [119:09] Great. Now here's some takeaways I want [119:12] to give you before we dive in even more [119:15] with this. [119:17] is just some kind of takeaways and pro [119:19] tips. You want to break your work into [119:21] logical chunks, right? So, what we did [119:23] here is we've did this long [119:26] basically very long session in claude [119:29] all in one session. When we talk about [119:31] sessions and claude, it means when you [119:32] type in claude the first time to when [119:34] you exit claude. So, that's one [119:38] continuous session. It was a little [119:39] confusing. We put session two in here. [119:42] Technically, a session is when you start [119:43] up Claude and then when you end it. So, [119:45] you want to break it into logical [119:47] chunks. You did notice that it didn't [119:49] quite fix my bug here, and I don't want [119:51] to dig too deep into this with this [119:54] video because it's a little off topic to [119:56] kind of get in the weeds, but there is a [119:58] possibility that this context has become [120:00] so large and so abstract that it's like [120:03] not really understanding what it needs [120:06] to do and it's not quite or it's just [120:08] hallucinating or something like that. I [120:10] can't really say for sure without [120:11] spending a lot more time on this, but [120:14] trust me when I say if you don't break [120:16] the work down and you make really long [120:18] sessions, you will start to see [120:20] hallucinations and things like that. And [120:23] one good thing that's best practice is [120:25] to use the session notes and summarize [120:28] the progress that you've made after [120:29] you've made it. And then when you start [120:32] new features, you want to come in and [120:33] add those new features and say, "This is [120:35] what I want to do." Now, when you're [120:37] doing major refactors, you want to start [120:40] fresh sessions, right? So, basically, if [120:44] you're doing something as huge and big, [120:46] it's really easy to just exit out of [120:48] cloud code and go back in. And I'll show [120:51] you how you can grab some of that [120:54] session information, hint, session notes [120:57] MD to when you create a new cloud [120:59] session, it doesn't have to start from [121:01] scratch, right? It doesn't have to [121:02] reinvent the wheel. It can just read the [121:04] session notes and keep going. [121:07] So, here's some things that you don't [121:08] want to do. You don't want to try to do [121:10] an entire project in one session. We're [121:13] doing this for demonstration because I [121:15] wanted to show you, you know, a big long [121:16] session, but don't do this. Don't try to [121:18] do the entire project with one session. [121:21] And don't assume that everything you [121:23] know that you've done will be remembered [121:25] by Claude, right? Don't assume assume [121:27] that it's going to remember everything [121:29] from hours ago or way back early in the [121:31] session because that may not be true. [121:34] Now, when you notice degraded [121:36] performance, don't just keep going with [121:39] that session and keep iterating. There's [121:41] a couple of reasons. For one, it can [121:43] burn up a lot of money. If you're paying [121:44] for this with API calls, it can burn up [121:47] a lot of money to kind of go in circles [121:49] on a problem that may be solved if you [121:51] just quit the session and start another [121:53] session. And another thing that you [121:55] don't want to do is you don't want to [121:57] expect Claude to remember this across, [121:59] say, a few days. So, if you have a [122:02] session going and even if the session's [122:05] open on your laptop and you leave it [122:06] somewhere and you come back to that [122:08] session a few days later, don't expect [122:10] Claude to maintain that context. Highly, [122:13] highly likely that it will not. It will [122:16] probably then come back and try to [122:19] attempt to figure it out. Right? So when [122:23] you see performance problems like we [122:25] started to see here that's a good time [122:27] to [122:29] kind of look at things and say is this [122:30] session big is it too big etc do we need [122:35] to trim this down and so cloud code [122:39] works best with its own constraints and [122:41] we'll talk about that a little bit [122:44] but what you can do is you can ask [122:47] claude to there's a few things you can [122:49] do like a canary test And I'm going to [122:52] do this in the same session before we [122:54] close it. I'm going to say, can you [122:57] recall [122:59] what database we're using, [123:02] which we're not using a database, but [123:05] we're going to see if cloud knows that. [123:07] And so it's starting to think now. And [123:09] it says the app was designed as a simple [123:11] stateless image processing tool without [123:13] any database requirements. So that's [123:15] correct. So that's some of the things [123:16] that you can ask. And by asking these [123:19] questions, you can tell how the context [123:21] is doing, right? If it comes back and [123:22] says, "You know what? I have no idea." [123:23] Or if it comes back and says, "Oh, you [123:25] have a Maria DB database, but we deleted [123:27] it earlier." And you know that that's [123:29] not true. Then it could be a chance that [123:32] your sessions are getting a little bit [123:34] long. So, you kind of want to do a [123:36] health check once in a while, right? And [123:39] it's basically this kind of looking at [123:41] it asking it, hey, you know, what did we [123:44] do here or something like that. Now if [123:47] we look at this here is how we can free [123:49] up our context. [123:52] We can clear [123:54] reset you see here which is clear [123:56] conversation history and free up [123:58] context. This is the same as exiting [124:02] claude and restarting it again [124:05] sort of. If you don't trust it then the [124:07] best way of course is to shut off Claude [124:09] and start it back up again. And there's [124:12] another one that's compact clear [124:14] conversation history but keep a summary [124:16] in context. [124:17] So we can just say [124:21] compact [124:23] compacting conversation and we can say [124:26] you know this is pretty good. We've got [124:27] a lot done with this super long set of [124:30] instructions. So [124:32] we can compact it. Now, another thing [124:34] that we can do as soon as it's done [124:37] compacting is we can start up another [124:39] session that has new context, but we can [124:43] give it a little bit of history with [124:45] session notes MD. Okay. And now it says [124:49] here previous conversation compacted [124:52] read and it says here read in session [124:55] notes read app py main.js stylejs etc [124:59] to-do list compacted it see controlr to [125:02] see full summary. So let's do controlr [125:05] showing detailed scrant transcript. [125:08] Let's go back and just kind of look at [125:10] this. Implemented virtual environment [125:11] for clean dependencies. All user [125:14] messages. Here's my message. Build a [125:16] single optimization web app using Flask [125:18] with detailed requirements. [125:20] Serving it up. There was an error. We [125:23] fixed it. Some pending tasks. Current [125:25] work. Optional next step. The user's [125:28] immediate requests have been satisfied. [125:29] No further development work was [125:31] explicitly requested. So this is all [125:34] stuff that we can rely on session notes [125:37] for and we have our session notes here. [125:39] So of course we can just do controlr [125:44] go back to our prompt. [125:47] We can exit out of cloud. Now we're [125:48] completely out of cloud. So what are we [125:51] going to do to do all this context? So [125:52] obviously any question that we ask is [125:54] going to jump back into the files but [125:57] it's not going to have the context. It's [125:59] not going to know everything that we did [126:02] here. It's going to try to guess it. [126:04] It'll try to reverse engineer and look [126:06] at our code and say, "Okay, I see this. [126:07] I see this. I think the point is this, [126:09] etc." But an easy way to do it, of [126:11] course, is to do claude and say, "Read [126:15] in [126:18] session notes MD and [126:22] whatever you want it to do. [126:26] All [126:29] right. And so that will load up this [126:32] history and give Claude a little bit of [126:34] history. Another thing we could do is [126:37] you could copy this whole summary that [126:38] we had [126:41] and put that and add that into an [126:44] additional file and say, "Hey, here's [126:45] another summary. Here's some more stuff [126:46] you might want to look at." But [126:48] basically, the easiest way is say read [126:50] in session notes and create some [126:53] features to X. [126:56] So just for some kind of pro tips again [126:59] break work into logical chunks. Don't do [127:01] these huge long sessions like this. Try [127:04] to summarize your progress before [127:05] starting new features. So try to [127:07] summarize things in session notes or [127:08] some other place before you start new [127:10] features and keep fresh sessions. Start [127:13] fresh sessions for major stuff or just [127:16] to be safe. Just start a session and say [127:18] pull in session notes and let's go for [127:20] it. Don't try to do a project an entire [127:23] project in one session. Don't assume [127:25] that cloud's going to remember this [127:26] stuff just because it's in the same [127:28] session, etc. But take control of it by [127:30] using these session notes. So, I hope [127:33] this is clear. Now, you can see that we [127:35] have this set up. We can do things like [127:37] we can deploy it, stuff like that. I [127:39] think we're going to leave this [127:40] application pretty good for now, but we [127:42] might want to jump in and do some [127:43] features later or something like that. [127:46] And we're going to keep digging into [127:47] Cloud Code and this amazing tool. So, [127:50] thank you for watching. Let's go to the [127:52] next task. Now, in this demo, we're [127:54] going to talk about writing effective [127:56] development prompts. So, writing the [127:58] right kinds of prompts will get you the [128:00] right kind of results. [128:02] Now, we've talked a lot in this course [128:04] about assumptions and how Claude will [128:07] make assumptions based on what you say. [128:09] Some of those assumptions are perfect [128:11] and they're great and some of them maybe [128:13] not so great. And that's not necessarily [128:16] the fault of Cloud itself. For instance, [128:19] we can say make a login screen. [128:23] Now, this is an example of a bad prompt. [128:27] And what do I mean by bad? Well, it's [128:30] just not that great. It's not specific. [128:33] It's not clear. It's very vague. All of [128:37] these things will make for interesting [128:39] results. So, if I say make a login [128:42] screen, now it's made some assumptions [128:45] here. And those assumptions could be [128:47] based on [128:49] my previous experience with cloud maybe [128:52] things I've built in the past or maybe [128:53] it's going to look at GitHub and say [128:55] what is the most common thing. So it [128:58] says here I'll create a login screen for [129:00] your express application. Let me first [129:02] explore the project structure to [129:04] understand the current setup etc. Now [129:07] actually I do want to make a login [129:09] system with express. I'm not sure how it [129:11] knew that, but in this case, we're [129:14] really not going on the right path. [129:17] So, we'll see here listed two paths [129:21] and it says read illegal read operation [129:24] on a directory. Let me check the [129:26] contents. There are no contents. This is [129:28] just an empty folder. So, then it says [129:31] find [129:33] and it wants to look for [129:35] JS, JSON, HTML, CSS, etc. Now, the [129:41] reason it inferred that we would want an [129:43] express application is probably because [129:45] the name of the project or the name of [129:48] the folder that we're in is express [129:50] login demo. And that's probably how [129:53] cloud code guessed that we want to do [129:55] this in express. But if you look at it, [129:57] it says, hey, we want to look at some [129:58] files. Now, I'm going to say no and tell [130:02] cloud what to do differently because [130:05] this is just kind of a silly request. [130:07] Make a login screen. make a login [130:09] system. It's just too vague. So Cloud [130:13] will ask multiple clarifying questions. [130:16] It'll create something generic and that [130:18] might not meet what we want. Right? [130:20] Since we've called this Express login [130:22] demo, it says we'll use Express. But if [130:24] we didn't name this folder that, maybe [130:27] it'd try to create something in React or [130:29] Vue or who knows. So we need to be [130:34] specific. And so one problem here is if [130:36] we let it assume what our intent is, it [130:39] may create something wildly outdated or [130:43] weird or something that we don't want, [130:46] right? It might say, "Oh, maybe this [130:47] person wants a DOSS app and we'll build [130:50] that or maybe it wants a Go app or a [130:52] Python app or whatever." And another [130:55] problem is it probably won't throw in [130:58] error handling, validation, security, [131:00] all that because it's just going to try [131:01] to make a guess [131:03] of what you're trying to create. Now, [131:07] here's another thing that we can do that [131:09] we can make this better. Now, I did back [131:11] out of this and say, "No, Claude, don't [131:14] make something. I'll be more specific." [131:16] So, I'll copy and paste this in here, [131:19] and this will be an example of a better [131:21] prompt. I'm going to say create a post [131:25] slappi/off [131:27] login endpoint using expressjs. Now that [131:31] is what we're named here. So claude [131:34] inferred that. But that's actually what [131:36] I want with the following requirements. [131:38] For our input we need an email and a [131:40] password. Both are required. Must be a [131:43] valid email. Must be a valid password. [131:46] We want to validate that input using [131:48] express validator. Check if the user [131:50] exists in postgree SQL database. Compare [131:53] the password using brypt. Generate a JWT [131:56] token with 24-hour expiration. And then [131:59] the response should be success or [132:00] failure. And we'll define what those [132:03] should look like. And then I say include [132:06] error handling for database failures and [132:08] validation errors. So I'm going to hit [132:11] enter. Now this is what we would call a [132:14] better prompt. Now, I said the last [132:15] prompt was a bad prompt, and I kind of [132:18] explained why. This is an example of a [132:20] much better prompt. We're being very [132:23] specific. We're saying we want to use [132:24] ExpressJS, right? Here are the fields [132:27] that we need. Here's what I want you to [132:29] do with them. Here's the database that I [132:32] want you to use. Here's how I want you [132:33] to compare the password, and I want a [132:36] JWT token, etc. We're getting very [132:39] specific. And the more specific you are [132:42] with your prompts, even the very [132:43] beginning prompts, usually the better [132:46] result you will get. So we will let this [132:49] run. Now if we look at this, it says, I [132:52] see this is a new project with only get [132:54] initialization. I'll create the complete [132:57] Express.js project structure with the [132:59] following login endpoint. And we have a [133:02] to-do list. Now in this course, we've [133:05] seen a bunch of to-do lists, right? So, [133:07] we've seen how they go through and cloud [133:10] code will present this to-do list and it [133:12] will go step by step and do all the [133:14] things here. It says initialize NodeJS [133:18] project with package JSON. [133:21] Do we want to do that? Yeah, let's do [133:23] that. And next, it says do we want to [133:26] install required dependencies which are [133:28] express and validator, brypt, json, etc. [133:32] Yes. And now it says create basic [133:36] express app structure and I'll select [133:38] yes. Now here's something to notice. It [133:41] says hey do we want to write this [133:43] environment file where we have port 3000 [133:47] a JWC secret etc. And yes we do [133:53] and that is something that we will have [133:54] to create. So we'll have to create a [133:57] actual postgres database with a login [134:00] and password etc. [134:03] But it's going to create all of the [134:04] software that's wrapped around that. And [134:06] it says here, do we want to make routes? [134:08] Yeah. As we go through, I can say yes [134:12] for this session only and just let [134:14] Claude go, right? Let it just make all [134:17] the things that it wants to make and [134:18] needs to make and then we can go back [134:20] and test it later. Now, I mentioned that [134:23] we're going to have create a PostgresSQL [134:25] database. And you can see here that it's [134:26] actually making a database schema file [134:29] for us which will make things really [134:31] easy because we can just run that into [134:33] the Postgres database. Now one way that [134:36] I could have been more specific with the [134:38] prompt is to say the database backing [134:40] that I want. I could have said SQLite my [134:43] SQL Microsoft SQL whatever that would [134:47] have been another way to specify things [134:49] more. And so that's one of the things [134:51] you want to think about your prompts. [134:53] You want to look at them and say, "Is [134:55] this specific enough?" Now, here's a pro [134:57] tip that's really awesome is you can [134:59] take the prompt that you want to use. [135:01] You can dump it into an LLM like chat [135:03] GBT, Gemini, Grock, Claude, whatever you [135:08] like and say, "Act [135:11] prompt engineer or act as an LLM [135:16] and tell me how to make this prompt [135:18] better." And it will go through all of [135:20] the basic LLMs that are out there right [135:22] now. will go through and it will ask you [135:24] a few questions and it will tell you [135:27] here's a better prompt to use. So that's [135:29] something that you should always try as [135:32] you're building your prompts to try to [135:33] make them a little bit better. Now here [135:35] it says [135:37] we've got the whole to-do list is [135:39] checked off. So it says the post API off [135:42] login endpoint has been implemented with [135:44] all the requested requirements. [135:46] Email validation using express validator [135:49] password 8 character minimum error [135:52] messages we have postgres [135:55] integration here we have JWT token [135:57] generation we have a specified response [136:00] format we have what to do on failure [136:04] comprehensive error handling so 503 401 [136:08] 400 500 all of these are handled here's [136:10] the files that were created to use this [136:12] endpoint configure your PostgresSQL [136:15] database credentials and run the schema [136:17] SQL to create the required tables. Now, [136:21] what is the difference between the two [136:23] things that we did here? Well, the [136:25] difference is in this case, cloud is [136:27] building exactly what we need, right? We [136:30] asked for a specific thing and it's [136:32] delivered that specific thing. It [136:34] includes all the security features, [136:36] proper error handling, things like that. [136:38] And there really are no clarifying [136:40] questions needed most of the time when [136:43] you get very specific with your prompts. [136:46] and it's pretty awesome. So, this kind [136:48] of goes into a formula that I like to [136:50] use, right? I like to use this formula [136:53] and I call it context action details [136:56] examples. And what I'll do is I'll just [136:58] create a little file here. [137:05] We'll call it examples MD. And this is [137:09] going to be context [137:13] action details [137:16] examples. [137:18] And we didn't do all of these with this [137:20] the initial prompt that we did here, but [137:22] this is something that we can really [137:24] utilize to our advantage. Now, context, [137:27] right? What do we do with context? Well, [137:30] we know that context sets the stage, [137:33] right? It basically says here's the past [137:36] information that you need to care about. [137:40] So we'll say sets the stage. [137:43] Now what's good and what's bad with [137:46] context. [137:48] Now bad is something like add a feature, [137:52] add a new feature, add something. Good [137:55] is I have an ExpressJS API with MongoDB. [137:58] Current routes are slout API. add a [138:02] feature that does blank. [138:05] Now, as far as action goes, [138:10] what does action do? Well, it will be [138:13] specific. [138:14] So, instead of just saying do this thing [138:17] that you should do, with action, it will [138:20] be clearly defined, right? So, a bad [138:23] example would be make it better, right? [138:26] So, the context would be look at my [138:28] software. Action is make it better. good [138:31] would be refactor this function to use [138:33] as sync await instead of callbacks or [138:35] something like that something very [138:37] specific which ties into details. Now [138:41] with details we want to include [138:44] constraints. Now with action we're [138:46] telling it exactly what it should do, [138:49] right? We're saying here's what we'd [138:51] like you to do with details. That's a [138:53] good place to insert constraints. [138:56] So instead of something like a bad [138:58] example would be add validation for [139:00] this, right? Cloud code could probably [139:03] figure it out. So a good example would [139:05] be add validation that ensures email is [139:08] unique in the database and password [139:10] meets OASP standards. So that's an [139:14] example of good details. [139:16] Now with examples, what are we doing [139:18] with examples? [139:21] We are showing desired patterns. [139:26] Now, if you've worked with LLMs a lot, [139:27] which you probably have, you'll notice [139:29] that the patterns are everything. [139:34] So, as you're going through and you're [139:36] saying, "Please make this thing." As [139:38] soon as you say, "Th looks like this." [139:42] Now, the final step is examples, which [139:44] is where you show your desired patterns. [139:46] And that's where you're saying, "Hey, [139:48] this is what this should look like." So, [139:50] a bad one is make it like all the other [139:53] applications out there, O applications [139:55] out there. You could say something like [139:57] make it a typical authentication app. [140:00] Something like that is way too vague and [140:02] it doesn't really give an example of [140:04] what success looks like to the LLM. But [140:06] if you say something like follow this [140:08] pattern from our existing endpoints and [140:11] type in your endpoints, something like [140:13] that or follow this pattern from the [140:15] OOWSP examples. [140:18] And that basically says, "Hey, here's [140:21] how we want it to look." And notice that [140:24] sometimes if you're typing in these [140:26] vague prompts, it will just waste a lot [140:28] of time. Honestly, you will go through [140:31] and say, "Make this thing like this." [140:33] And you'll do these vague prompts and [140:35] things won't really go the way you want. [140:37] And so then you'll have to go back and [140:38] get more specific anyway. So if you just [140:41] remember this context, action details, [140:43] examples, then you know you can say here [140:47] I'm going to put in my context. I'm [140:48] going to tell it what I want it to do. I [140:50] want to tell it what I don't want it to [140:52] do or what world I want it to live in. [140:55] And in examples, this is what I want it [140:57] to look like. And sometimes you can get [140:59] this down to one prompt that will [141:01] generate a ton of code. So, the big [141:05] things here are the three C's of good [141:09] prompts, and I'll put that here. And the [141:12] first C is clear, which means no [141:15] ambiguity. Don't leave things open for [141:18] interpretation unless you want the LLM [141:20] to get creative. Basically, you want to [141:22] say this is what I want. [141:25] The next C that we care about is [141:27] complete, right? All the requirements [141:30] are stated. All of the constraints are [141:33] defined. All of the end results that you [141:36] want are defined. [141:39] And the last one is contextual. [141:42] So what we're saying here with [141:43] contextual is we want to include the [141:45] relevant background. We're basically [141:47] saying here's what we have now. Here's [141:49] how we've built it. Here's how we'd like [141:51] it to look moving forward. Now remember [141:54] there's a time investment rule here. If [141:56] you spend a minute writing a good [141:58] prompt, you can save 10 minutes of [142:00] revision. And that's no exaggeration. If [142:03] you spend time upfront getting the right [142:06] prompts as you're going through, those [142:08] prompts will generate things that are [142:10] more specific, more accurate, better for [142:14] your intended goal. And if you want to [142:17] save time and just put in vague prompts, [142:19] you'll end up spending a lot of time [142:21] refactoring those and saying, "Oh, [142:23] that's not what I meant. I meant this." [142:25] etc. So remember, there's kind of a [142:28] Goldilock zone when it comes to prompts [142:30] here that like we've put in. If you're [142:31] too vague, Claude will guess. It will [142:34] infer things and it will basically make [142:37] assumptions, which we've talked about a [142:39] bunch in this course. If it's too [142:41] verbose, right, the other side of that [142:43] where you have just a ton of words and a [142:45] ton of explanations and tons of details, [142:49] then cloud gets a little bit confused. [142:50] And sometimes it's like, well, I hear [142:52] what you're saying. I see that you have [142:55] 53 things that you want me to do. So, [142:57] I'm going to try to do 45 of them and [143:00] then you never know what you're going to [143:02] get right. So, just right, which is the [143:05] middle is clear, structured with [143:08] examples as we've shown here. So, these [143:11] are some good prompting techniques that [143:13] you should keep in mind and you should [143:15] use while you're using Cloud Code and [143:16] you'll see some amazing results. I've [143:18] worked with a lot with claude code [143:20] lately and I've noticed that when I put [143:22] in the right prompts and I put in the [143:24] right info, I get really good output. [143:27] So, I wanted to include this demo as [143:29] kind of a way that we can look at clear, [143:31] complete, contextual prompts that will [143:35] get you exactly what you're looking for. [143:37] Thank you for watching. Now, in this [143:40] demo, we're going to talk about using [143:41] multiple files in your projects, project [143:44] navigation, and how Cloud Code kind of [143:46] handles that. And it's really cool. I [143:48] mean, you can do things like say, "Show [143:51] me the file structure [143:54] of this application, [143:58] right? It'll start kicking off and we'll [144:02] go through and look at everything." And [144:03] we have some of this stuff. We've got it [144:06] documented in other places, but we can [144:09] always look at this and say, "Oh, that's [144:10] cool." Right? And you can say [144:15] l as our project structure [144:19] and tell me. [144:24] What are the main components? [144:31] How are the routes connected to [144:34] controllers? [144:36] We just come up with some different [144:38] things like this. uh [144:41] what database are we using [144:46] and cloud will go through and answer a [144:48] lot of questions about this. Now, where [144:49] does this come in handy? Obviously, none [144:52] of us really like to jump into giant [144:54] legacy code bases that we don't know [144:58] anything about. And this is where cloud [145:00] can really help because it's not just [145:01] focused on one file, one task, one [145:04] function. It'll look at your entire [145:08] project like this. And so we can see [145:11] main components server.js. [145:13] That's going to be our main application [145:15] entry point. That's the PostgresSQL [145:18] connection pool authentication routes [145:22] schema.SQL. [145:24] And then it says route controller [145:25] architecture. It shows main server [145:28] mounts off routes at API o off router [145:31] handles etc. in a database is Postgre [145:35] with a connection via PG library with [145:37] connection pooling single users table [145:40] email index for performance schema. [145:42] Right? So we can go through and kind of [145:45] look at this and we can even have it [145:46] look at other projects. But one of the [145:49] things we could do here is since we have [145:52] these main components as names, [145:55] we can say something like [146:01] I would like to change the database. And [146:04] we're actually going to do this in a [146:05] future video, but I would like to change [146:07] the database [146:10] to Maria DB. And we have to say at some [146:13] point, otherwise it'll start changing it [146:15] for us. [146:17] what files might be affected. [146:22] Okay, we can see here based on the [146:24] codebase analysis, these files would [146:26] need changes for Maria DB migration. [146:29] Direct changes required and it shows [146:32] schema changes environment variables. [146:35] This application used parameterized [146:36] queries which helps but you'll need to [146:38] update the placeholder syntax and [146:40] connection pool configuration. So this [146:41] is some good stuff to know and this [146:44] basically shows how Claude knows things [146:47] about your project, right? It can [146:50] correctly identify relationships between [146:52] files, what files do and things like [146:55] that. Now one of the things that you can [146:58] do here also is you can make changes to [147:01] specific files by naming them. You can [147:03] say add X to config database.js. You can [147:08] say add something, refactor something in [147:11] this file. So you do have file level [147:13] access, but as we can see, Claude also [147:16] looks at a bunch of different files and [147:19] examines how they're all related. Now, [147:22] where does this kind of thing come in [147:23] handy? Well, when you're doing [147:25] refactoring, you can specify the files [147:27] that you want to refactor to change. Um, [147:30] you can use this and the next step can [147:32] be, okay, change it. And it could just [147:34] be that you're saying, "Hey, analyze [147:36] this codebase and tell me what to [147:38] change." Maybe you know that all these [147:40] things need to be changed, but you want [147:41] to make sure that claude knows before [147:43] they start making changes. Now, you can [147:46] do this here in your queries. So, this [147:50] is file clustering, right? So, based on [147:52] the codebase analysis, etc., direct [147:55] changes required, schema changes, you [147:57] can say make changes to these files. And [148:01] you could actually just copy this right [148:03] here. Replace PG dependency with SQL [148:05] tool or Maria DB. And then you can say [148:08] schema changes change the schema here [148:12] and so on and so forth. So this is just [148:15] a cool pattern and a cool way to do [148:18] this. You know, you can tell it what [148:19] it's about. You could say something like [148:23] file name [148:28] package JSON [148:32] purpose [148:36] maintain [148:38] registry of packages [148:41] used [148:43] change add in [148:46] Maria DB B [148:50] instead of PG or whatever, right? So [148:54] these are things that you can go in and [148:56] you can take this information and make [148:58] it useful. So club is very useful as far [149:01] as knowing the code when you're working [149:04] in a file. You know, if you just crack [149:06] open this code and start looking at it, [149:08] you can ask Claude questions about it [149:10] and say, "Hey, tell me what this does [149:12] and add some comments here." or it'll [149:15] also take a more meta view of the entire [149:17] project as we can see and look at [149:19] multiple files all over the place and [149:21] how they're related and how they're kind [149:23] of put together. So, this is really cool [149:25] stuff and it's a cool feature in Cloud [149:27] that I wanted to show you. Now, here's [149:29] something else that you can do that's [149:32] pretty interesting with Cloud Code is [149:34] you can say do not I guess I don't have [149:38] to yell. I don't have to capitalize it, [149:39] right? But you can say do not modify [149:43] these files [149:46] and you can request changes and of [149:49] course if the changes have to be [149:51] modified in those files then cloud will [149:54] say hey I need to modify that right but [149:57] you can say do not modify these [149:59] following files when you do something. [150:02] This can be handy if you have something [150:05] where you're working on a problem and [150:07] it's just kind of spinning out of [150:09] control and it's updating things that [150:10] you don't want it to update or you can [150:14] say [150:15] that you just want you know this [150:17] particular set of code to not be [150:19] touched. You can say only create and [150:23] modify [150:25] and specify the files. And again, if the [150:27] files do need to be if different files [150:30] do need to be modified, Claude will let [150:33] you know. Now, there's another cool [150:35] thing here. The last thing I'll show you [150:37] is you can just verify. You can say [150:40] something like [150:42] this. [150:44] Verify these files were refactored. [150:50] And you can say give it a list of files [150:52] and say verify these ones because these [150:54] are the ones that I wanted you to touch. [150:56] So you can do a verification. [151:00] Now here's a few dos and don'ts uh when [151:03] it comes to files, right? So don't say [151:08] uh here are all the files in our project [151:10] and a massive paste of every single one. [151:12] Uh Claude knows those are the files in [151:14] your project and it's really kind of a [151:17] waste of cycles. But you can say here [151:20] are the three files related to user [151:21] authentication. Please modify them. You [151:24] don't want to just paste in file names [151:26] with no relationship context and just [151:28] say here's a list of files build an off [151:30] system. Instead you want to say [151:32] something like these files work together [151:34] the list of files and these make up our [151:36] off system. We want to make some [151:39] changes. Um, some of the things that you [151:41] don't want to do also is if you're doing [151:43] mixed project context, you don't want to [151:44] say like use the React components from [151:47] project A and put it in here, right? [151:49] Because we're not running React in here. [151:51] So, you could say something like here's [151:53] the logic from our React project for [151:56] authentication. Adapt this pattern for [151:59] Express, something like that. Those are [152:01] just some kind of dos and don'ts. And [152:03] this is a great feature with Claude, the [152:05] way it's able to work with files. And [152:07] it's something cool that I wanted to [152:08] show you. So, thanks for watching. [152:11] In this demo, I'm going to show you how [152:13] Cloud Code can work with APIs in two [152:15] different ways. First, we'll use Claude [152:17] to help us call an existing API. And in [152:20] this case, we'll look up a city's [152:21] coordinates with the Nomatim service and [152:24] grab the weather from Open Weather. [152:26] Then, we'll flip it around and we'll use [152:27] Claude to build our own API with fast [152:29] API so anyone can type in a city and get [152:32] back weather data. Now, the goal is to [152:34] show that Claude doesn't just write [152:35] code. It helps you connect different [152:37] pieces together quickly and turn them [152:39] into something that you can run. So, [152:42] we're going to start with a basic API [152:44] call. I have some prompts prepared and [152:47] we're going to let Cloud Code just build [152:49] this software based on what we're going [152:52] to tell it. [152:54] So for the first prompt, I'm going to [152:57] say write a Python script that takes a [152:58] city name, uses the nominatum API to get [153:02] its latitude, longitude, then calls the [153:04] open weather API, and the key will be in [153:06] the open weather API key environment [153:08] variable to fetch weather, print the [153:10] city, coordinates, temperature, and [153:12] conditions. [153:15] So now we will let cloud code take off, [153:18] and we'll see what it comes up with. [153:20] Now, I did specify I wasn't super [153:22] specific with this, but I did specify [153:24] just basically the clear goals that we [153:26] want to do, right? We want it to be in [153:28] Python. We want it to take a city name, [153:31] use an API, get the Latin longitude, [153:33] then call the open weather. So, we [153:35] basically have laid out how we want it [153:36] to work, but we haven't gotten super [153:38] detailed with it yet. And we can see [153:40] here it has already created weather. py. [153:44] And I'm going to say yes, go ahead and [153:46] create that. And we'll take a look at [153:48] it. [153:51] Now if we look at weather py [153:55] we can see we have a get coordinates [153:56] function here we have a get weather and [153:59] then our main. So let's look at get [154:02] coordinates in here. We're going to call [154:04] this nominatum openstreetmap.org search. [154:08] We're going to use a JSON format search [154:11] and we're going to search by a city [154:13] name. Then we're going to use that [154:16] response. We're going to get the URL [154:19] parameter headers. We're going to format [154:21] that response and take that Latin [154:23] longitude here and return it. Now, if it [154:26] doesn't work, we're going to say, "Hey, [154:27] city name is not found. Return none." [154:30] Um, if there's any other kind of errors [154:32] with fetching coordinates, it will be [154:34] produced here. So, this is good, clean [154:36] code. I mean, we don't really need this [154:38] try catch type thing going, but it's [154:41] really nice that it has it in there. And [154:43] I say we don't need it as in we don't [154:44] necessarily need it to function, but we [154:47] definitely should have it. And cloud [154:49] code puts it in here for us. If we look [154:52] at get weather, [154:54] we're getting weather data using open [154:55] weather API. We're sending that Latin [154:57] longitude. We're sending our API key [155:00] units metric, etc. Now, I'm not super [155:03] familiar with this API with either of [155:04] these APIs, so I'm not really sure it's [155:06] going to work. However, we're going to [155:09] see how well Cloud Code handles this. [155:12] So, I'm going to save it. And it says [155:17] created weather py script. We need to [155:19] export an open weather API key. And then [155:22] we just put in python weather py New [155:24] York. [155:26] So, let's try it out. I'm going to put [155:28] in my API key in the environment [155:30] variable and give it a shot. [155:33] Okay. So, now I have the API key [155:36] entered. And one of the things I'll do [155:38] is create a Python environment for this. [155:41] and we'll install the things we need. [155:42] Now, if we go back to Cloud Code here, [155:45] it says that you can just export the key [155:48] and then do Python weather py. [155:51] And I can see here [155:54] that it might actually work. [155:58] Weatherpy [156:01] New York. [156:04] But it needs to be Python 3 cuz I'm on a [156:06] Mac. [156:09] And we need to import requests. So we'll [156:11] go ahead and do this. Python.mnb. [156:14] We'll create a virtual environment [156:17] again. Python 3. [156:26] We'll activate that. [156:30] And then we can do Python weather py [156:34] New York. It's going to need at least [156:36] requests, right? So, we'll say pip [156:37] install requests. [156:43] And it looks like it is unauthorized. [156:52] So, I'm going to make sure that I have [156:53] the right API key entered. [156:57] Okay. Well, I have double checked and my [157:00] API key is being populated and it's [157:04] valid on the website. So, [157:08] I'm going to go back to Claude here and [157:11] say [157:15] uh we'll say unauthorized for URL [157:20] and let's see if cloud can help. [157:24] I am getting an error [157:28] and then we will submit the error. [157:38] And now it's grooving. [157:42] It says you want to check if this is [157:46] set. It's going to run a bash command. [157:55] says your API key isn't set, [157:58] which is actually untrue because it is [158:02] set. [158:08] So let's try something else because if [158:12] we go into bash and we echo out open [158:16] weather API key, it's there. So [158:21] clearly that isn't the problem. [158:25] And it says if you have an API key and [158:27] it's still not working, the key might be [158:28] invalid or you might need to wait a few [158:30] minutes. So, we'll wait a few minutes. [158:36] Okay. So, we've waited a while here and [158:39] it's just not working. So, I'm going to [158:42] say [158:44] I've waited [158:46] and it still is not working. [158:50] Can you check the API call? itself [158:55] to make sure it is [159:00] following open weather [159:07] specifications. So this is one thing [159:09] that you can ask claude and sometimes it [159:13] will go out to the internet and it will [159:15] examine documentation and things to kind [159:17] of double check itself and that's what [159:18] it's doing right here. Cloud wants to [159:20] fetch this content. Yes. [159:24] So, it's going to fetch this content and [159:26] kind of look up and see how we're [159:28] supposed to access this API because [159:31] maybe it's changed since the training [159:33] happened. [159:39] And it says here that it wants to do [159:42] some debug output. [159:44] It says I'll check the Open Weather API [159:47] documentation to determine it's correct. [159:49] It looks correct. Let me test it with [159:50] the debug version to see exactly what's [159:52] happening. So yes, we want to put in [159:55] this additional debug information. [160:00] Now try running the script again. [160:06] So we will [160:08] run it again. [160:12] And [160:14] adding the debug information, [160:16] it now appears to be working properly. [160:19] as it should. Uh this is what we were [160:22] trying to get earlier is these [160:24] coordinates here. [160:30] Put in something different. Now we have [160:32] a response. So I am not sure exactly [160:35] what happened there, but it looks like [160:38] it's working now. And I'm going to leave [160:40] this in the video because I've been [160:41] leaving all the mistakes in the video [160:43] with all of these things to show a more [160:46] realistic process of how this really [160:48] works. So, if I clip and edit this part [160:50] out of here, then it makes it look like [160:52] cloud code works perfectly and looks [160:54] like everything went smoothly and great. [160:56] And that's not always the case. So, [160:58] we're going to leave this in here. Now, [161:01] we need to move on to the next step. So, [161:02] if we're able to get this information, [161:04] we're even able to get this weather [161:06] information, but we're going to do [161:10] something a little different. [161:12] Now, one thing we're going to do, so [161:15] this put it into two functions, right? [161:17] And that was one of the things I was [161:18] going to do to improve readability. I [161:20] was going to say, "Hey, please put this [161:22] into get coordinates and get weather as [161:24] two separate ones." But cloud code [161:25] already did that for us. So it has some [161:29] good structured results coming out of [161:30] it. And now what we want to do is expose [161:34] this as an API with fast API. And so [161:38] what that's going to do is we're going [161:39] to turn this into our own API that we [161:43] can share with other people. And one of [161:45] the things we could do is we could [161:47] convert this temperature into Fahrenheit [161:49] because we're in the United States and [161:52] even though I don't necessarily agree [161:54] with it, we use Fahrenheit here. So [161:57] that's something that we can add in [161:58] there as well. So I said turn this into [162:01] a fast APA app with one endpoint, [162:03] weather, city. It should return JSON [162:06] with the city name, coordinates, [162:07] temperature, and conditions. [162:10] I would like to [162:13] display [162:17] Fahrenheit [162:20] for the temperature. [162:22] So, we're being pretty specific here, [162:24] right? We're saying this is what we want [162:26] to do with it. So, we're able to grab [162:28] this API data. Now, we want to convert [162:30] this into something else. We could even [162:31] turn this into an MCP application if we [162:34] wanted to, like we've done in our MCP [162:37] course. But here we go. So now it says [162:39] uh we need to import fast API. [162:44] We need to change [162:46] uh it looks like right now it's just [162:48] importing the fast API. So we'll say yes [162:52] and then we'll see now it's going to [162:54] convert this script to a fast API [162:56] application. So if you haven't used fast [162:59] API as a Python developer, it is [163:01] fantastic. So that's why I chose this. [163:04] And we can see here we don't even have [163:06] to do the conversion. So, when I said I [163:07] wanted to display it in Fahrenheit, I [163:09] was thinking maybe it would do the 9 [163:10] by32 and do the conversion, pop it out. [163:14] But it looks like we can just change our [163:15] API call, which is even simpler and [163:17] easier to do. So, I'm going to say, [163:20] yeah, let's let's make this edit. [163:26] And now we're getting into the the meat [163:28] of the API application here. [163:32] And it says, do you want to make these [163:33] edits? So, it's going to pull some of [163:35] this stuff out of Maine and it's going [163:37] to move it around. We've got an [163:38] asynchronous function here. Get weather [163:40] per city [163:43] and it's yeah, it's kind of shifting [163:44] things around. All of this looks really [163:46] good at a glance. [163:48] And if it doesn't work perfectly the [163:50] first time, we'll debug it and figure [163:51] out why. But I think this is going to [163:54] work. [163:57] It says here, we're going to pull out [163:58] this debug information. Now, this debug [164:01] information when we added it and made it [164:02] work. So, [164:05] we'll go ahead and pull it out of there, [164:06] but that may not be a great idea. [164:12] Okay, it says here [164:15] we can convert it to fast API. So, I [164:17] need to install fast API and unicorn. [164:22] We've already exported the key here. We [164:25] need to do unicorn weather app reload. [164:28] So, we'll just do that. [164:30] Clear this. say pip install fast API. [164:36] Awesome. [164:38] And we're just going to copy this. We're [164:40] going to pretend we've never used [164:42] Unicorn before. [164:44] Copy it to see if Claude gave us the [164:47] right command to run it. [164:50] And here we go. Now we have Unicorn [164:52] running on 127800. [164:55] So we can send this a request with a [165:00] city. Let's see what it returns. [165:03] Okay, now I've got my favorite API [165:05] testing tool, Postman, open here, and [165:07] we're just going to send a get request [165:10] to localhost 8000/weather [165:12] with the city name. [165:15] And you can see here [165:18] it brings back Forest Grove with [165:20] coordinates latitude and longitude. [165:23] Temperature 60.76 [165:26] Fahrenheit. conditions overcast with [165:29] clouds, which if I look outside, I can [165:32] see that's pretty accurate. So, this is [165:36] great. [165:38] So, in this demo, I wanted to show how [165:40] easy it is to work with APIs. Now, you [165:42] can't plug in an API directly into cloud [165:44] code like you can with some other [165:46] generative AI tools. However, you can [165:49] call APIs, [165:50] use that data, make APIs, [165:54] things like that. Very simple. So, Cloud [165:56] Code is very aware of APIs and other [165:59] services and how to create them. In this [166:02] one, we had a little bit of a hiccup [166:03] that may have been from the service that [166:06] we signed up and maybe when I generated [166:08] the API key, something like that, but [166:10] Cloud Code was able to handle it, fix it [166:12] for us, and get it going. So, thank you [166:15] for watching. Now, in this section of [166:17] the course, we're going to look at [166:19] auditing for software quality, and we're [166:22] going to do that with cloud code. Now, [166:23] if you've worked in enterprise software [166:25] development, obviously code reviews, [166:28] code quality reviews, things like that [166:31] are extremely common and they've been [166:34] doing this for decades. Looking for [166:36] things like architecture, [166:38] design patterns, error handling, [166:42] fault tolerance. All of these things are [166:44] things that human beings have checked [166:46] for for years. And sometimes that's [166:48] their full-time job, right? where they [166:50] go through and and look for particular [166:54] bad patterns, bad smells, code [166:56] duplication, things like that. And then [166:59] sometimes we have tools that do it, [167:00] right? Automated tools. Well, Claude [167:03] Code just happens to be the ultimate [167:05] automated tool for doing this as you'll [167:08] see in this section because we're going [167:09] to review our software package and we're [167:13] going to look for very specific items. [167:16] Now, first we're going to do a [167:17] broadbased kind of overall type of [167:20] report and then we're going to drill [167:22] down. We're going to really hone in on [167:24] some very particular things. Now, in [167:27] order to do this, we are going to be [167:29] using some pretty long prompts. Now, [167:32] rather than saying, you know, watch [167:33] along and type in these long gigantic [167:36] prompts, I made them available here at [167:38] github.com/jeremyorggan/claudecode [167:43] reviewing prompts. And you'll find all [167:45] the prompts here for uh both our [167:48] software reviewing and our security [167:50] reviewing. So let's get started with the [167:52] first one. [167:54] Now what I'm going to do is I'm going to [167:56] dump the prompt in here. As you can see, [167:58] it's 41 lines. And then as it's running [168:01] and evaluating our software, we'll kind [168:03] of walk through what we're doing in this [168:05] prompt. So it's kicking off. Now here [168:07] we're saying analyze the project [168:09] architecture and identify is there clear [168:11] separation of concerns. Which [168:13] architectural pattern is used? Are there [168:15] any god objects or modules doing too [168:17] much? Is the dependency flow clean with [168:19] no circular dependencies? Rate the [168:21] modularity with justification. [168:24] And it says create an architecture [168:26] diagram showing layer dependencies, data [168:28] flow, external service integrations, [168:30] potential bottlenecks. Identify adder [168:33] anti-patterns like spaghetti code, copy [168:36] paste programming, god classes, modules, [168:38] tight coupling, and missing [168:39] abstractions. [168:41] And then provide a structured finding [168:43] report, a scale of 1 to 10 on how [168:46] important each finding is, precise code [168:49] level fix or config change, snippets, [168:51] welcome, plus defense in-depth guidance. [168:55] Now for constraints and style, we want [168:57] to be concrete and site exact code [168:59] locations and identifiers. We prefer [169:01] minimal drop-in fix snippets over pros, [169:04] which may not always be possible, right? [169:06] This one is really important that we [169:08] need to do. We need to put in this [169:09] prompt. Do not invent files or functions [169:12] that aren't present. If context is [169:14] missing, Mark is unable to verify and [169:16] say what code would prove it. Write this [169:18] into a markdown file and place it in the [169:20] audits folder. Now, we can see here that [169:22] Claude is analyzing the project [169:24] architecture, identifying design [169:26] patterns, antiatterns, and areas for [169:28] improvement. And it goes through and [169:30] explores all of our code. We've got some [169:33] to-do lists here. [169:35] And we can see here that we already have [169:38] software design architecture analysis. [169:41] And I'm going to select yes because it's [169:43] asking if it wants to write that. And [169:45] then we'll take a look at it. [169:50] Okay. And here we have in the audits [169:51] folder software design and architecture [169:54] analysis report. So let's take a look at [169:56] it. Says here the express login demo [169:59] follows a basic MVC inspired [170:01] architecture but suffers from [170:02] significant design limitations. The [170:05] application demonstrates minimal [170:06] separation of concerns with most [170:08] business logic embedded directly in [170:10] route handlers. It lacks proper [170:12] abstraction layers and has no [170:14] comprehensive error handling strategy. [170:16] Now that's terrible news, right? We [170:18] don't really like that much. But let's [170:21] take a look at it goes even deeper. [170:24] Minimal MVC inspired architecture. Model [170:26] layer, view layer, controller layer. [170:28] That's somewhat MVC. You know, it's [170:30] pretty close. And then here, separation [170:34] of concern score, we got three out of [170:36] 10. Business logic is mixed with route [170:38] handling. Data access logic is embedded [170:41] in controllers. The whole skinny [170:43] controllers thing, something that's [170:45] often hard to stick with. No service [170:47] layer abstraction and basic database [170:50] configuration is separated. So that's [170:52] good. Shows the project structure, [170:56] modularity score, extremely flat [170:58] structure with minimal organization. [171:00] Single route file contains all [171:02] authentication logic and no abstraction [171:04] layers for business logic. Database [171:06] schema is separate but not versioned. So [171:09] that is something that's important. Now [171:11] here we can take this and make a mermaid [171:13] graph out of the data flow. Right? So [171:16] it's provided that for us in case we [171:18] want to crack this open and do something [171:20] with the mermaid document. The key [171:23] issues all business logic is [171:24] concentrated in a single route handler. [171:26] No service layer for authentication [171:28] logic. direct database access from [171:30] routes and no middleware abstraction for [171:32] common operations. Here we have some [171:34] anti-atterns that are identified right [171:36] so we have a god object in module that [171:39] is an 8 out of 10 severity it's an offjs [171:43] and it makes testing difficult violates [171:46] SRP hard to maintain right and SRP is [171:49] single responsibility principle do one [171:51] thing and do it well this is doing [171:54] several things so we're not really sure [171:56] how well it's doing all of those several [171:58] things here's the remediation how we can [172:01] separate it and we can put this off into [172:03] services and have the router just point [172:06] to the services. Number two, primitive [172:09] obsession, it says. And this is an ojs. [172:13] We have select where email equals that's [172:16] a SQL injection [172:19] point which we'll find in our security [172:20] audits. This is a vulnerability for SQL [172:23] injection here. Remediation. Here's how [172:27] to fix it. We have copy paste [172:29] programming, duplicated error response [172:32] pattern, centralized error handling [172:34] middleware. Number four, the concern [172:37] magic numbers and strings, [172:39] right? So here we have a lot of stuff [172:41] that comes from constants is length is a [172:44] magic number, magic status codes, magic [172:47] time string, tight coupling, something [172:50] we always try to avoid. Uh we do have [172:52] tight coupling with direct database pool [172:54] import, hard-coded express validator [172:56] usage and direct brypt JWT dependencies. [172:59] So these are tight coupling which means [173:02] any change to either side of those is [173:04] going to cause problems in the future. [173:08] Shows how we can remediate that. We have [173:10] an architecture diagram here which is [173:12] pretty straightforward and then a list [173:15] of our problems. No abstraction layers, [173:17] no service layer, no data access layer, [173:20] no error handling middleware. [173:22] Now it also goes into potential [173:24] bottlenecks, right? There's a single [173:26] database connection pool. No connection [173:28] limit management, which means we could [173:29] have 100,000 people connect at once. And [173:32] guess what's going to happen with our [173:33] application? It's going to crash. We [173:35] have synchronous password hashing blocks [173:38] the event loop. We have no caching [173:40] layer. So every request hits the [173:42] database. Again, 10,000 people, probably [173:45] less than that, probably a thousand [173:46] people will crash our application right [173:48] now. And there's no rate limiting. So [173:50] we're vulnerable to brute force attacks, [173:52] right? So brute force is basically [173:54] putting in a username and password over [173:56] and over and over and over. We have no [173:58] rate limiting. So they can do that as [173:59] much as they want. Here's some of the [174:01] detailed findings with our high priority [174:04] issues, medium priority issues, and low [174:07] priority issues. Now next, this kind of [174:10] is what takes it out of a standard [174:12] report and it goes into recommended [174:14] improvements. We should have a routes [174:16] layer, controller, services, data access [174:18] layer, and a models layer. Here's the [174:20] proposed directory structure where we [174:22] can put all of these things and then [174:24] kind of shows the dependency flow, [174:26] right? Controller, services, [174:28] repositories, database, models, models, [174:30] models. And that's kind of a neat little [174:33] diagram for dependency. [174:36] Now, it also adds some in-depth security [174:38] recommendations, and we're going to go [174:40] in depth with security soon, but this is [174:42] saying input validation layer, service [174:45] layer security, centralized error [174:47] handling. It gives us a bunch of [174:48] suggestions to make things a little bit [174:50] more secure on that side of things. So [174:52] our final assessment, it's a basic [174:54] functioning application with significant [174:56] architectural debt. What is [174:58] architectural debt? Well, that means [175:00] things that are small problems now, but [175:03] after years of maintenance and updates [175:06] and refactoring. After a while, you're [175:09] going to have what's called [175:10] architectural debt, which means, "I'm [175:13] sorry, I can't change anything because [175:14] it'll take us 3 days to fix everything [175:17] that it breaks." That's architectural [175:20] debt. Technical debt, same thing. [175:24] Essentially technical debt is what [175:26] people talk about the most which is any [175:28] changes costs so much that after a while [175:32] you stop uh making feature changes and [175:35] bug fixes so fast because it'll break [175:38] and this is high right refactoring is [175:41] required for scalability maintainability [175:44] is low it's a monolithic structure [175:47] impedes development testability tight [175:49] coupling makes unit testing difficult [175:51] scalability architecture doesn't report [175:54] feature growth. So, gives us a set of [175:56] immediate actions here, some long-term [175:58] architecture goals, and these are things [176:00] we can put this entire report into cloud [176:02] code and say, "Hey, help me with this. [176:04] Help me make my score better." And then [176:08] it will do that for you. So, this is our [176:11] initial software design analysis. Let's [176:13] dig deeper on some software design [176:15] principles with our prompts and see what [176:18] kind of results we get and some [176:20] suggestions we get to make this a better [176:23] application. So, in this section, we're [176:25] doing reviews of software. And we're [176:27] doing very common software reviews that [176:29] you would often do with your code, [176:32] whether it's legacy code or green field [176:34] code. And these are just some basic [176:35] reviews to make sure that your software [176:37] that you're building is good and [176:39] extensible and secure and all that fun [176:42] stuff. So, next what we're going to do [176:45] is reviewing the codebase for design [176:48] pattern usage. We're going to look and [176:50] see what kind of patterns are found. Is [176:53] it appropriate? Is it being implemented [176:55] correctly? That sort of thing. So, as [176:57] I've done before here, I'm going to [177:00] paste in the prompt, hit enter, and [177:02] while it's working, we'll investigate [177:04] this prompt, and we'll look and see what [177:05] kind of report we're building. So, we [177:09] have here the start of the prompt. [177:10] Review the codebase for design pattern [177:12] usage. Identify and evaluate creational [177:15] patterns, structural patterns, [177:18] behavioral patterns, and domain [177:20] patterns. Now if we look at this like [177:21] creational pattern are we using [177:23] singletons database connections loggers [177:25] etc a factory pattern for object [177:27] creation a builder pattern for complex [177:30] objects and are they implemented [177:32] correctly very important we have the [177:35] same thing for structural patterns where [177:36] we have adapter facade decorator proxy [177:40] we're just basically looking through and [177:41] saying are these patterns being used and [177:43] are they being implemented correctly [177:47] and here we can say for each pattern [177:49] found is it appropriate ate for the use [177:51] case. Is it implemented correctly? Could [177:53] a simpler solution work? Now, this is a [177:56] big one, right? Because sometimes with [177:58] design patterns, it's like, well, we [178:00] could implement this really fancy, nice [178:01] pattern, or we could just do X that's [178:04] much simpler with less code and achieves [178:07] the same thing. Sometimes that's the [178:08] right call to make. And and here we're [178:11] going to provide a structured finding [178:12] report with a scale of 1 to 10. Um, just [178:15] like we did with our previous report. [178:17] And now we can take a look at it. And it [178:19] is still forging. So, it's still [178:20] analyzing all of our software at this [178:22] time. Now, it says, "Do you want to make [178:24] this edit to design pattern analysis [178:26] MD?" Yes, I do. And we're going to take [178:28] a look at that. We're going to see what [178:29] it found. [178:33] We're here in design pattern analysis [178:35] report. [178:37] Let's take a look at it. This report [178:39] analyzes the design patterns implemented [178:41] in the express login demo application, [178:43] evaluating their correctness, [178:44] appropriateness, and identifying areas [178:46] for improvement. Now, it shows the [178:48] project structure. This was kind of what [178:50] our last one did and a lot of these [178:51] reports will show you your project [178:52] structure sometimes in a different [178:54] context but it always shows you how your [178:58] project structure is set up and for [178:59] creational patterns well we found a [179:01] singleton pattern in the PostgresSQL [179:04] connection pool [179:06] correctly implemented appropriate use [179:08] case and proper connect and error event [179:12] listeners so that's good working [179:14] correctly no changes needed factory [179:17] pattern n pattern patterns detected, but [179:20] we could benefit from the JW token [179:22] factory for different token types. User [179:25] object creation could also use a factory [179:27] pattern. [179:28] So recommendation add the JWT token [179:31] factory. [179:33] Builder pattern also not present. [179:35] Express validator chains show builder [179:37] like pattern but from the library. No [179:40] complex object construction requiring a [179:42] builder pattern. Current application [179:44] complexity doesn't warrant builder [179:45] pattern. Now this is important and we [179:47] see it. This comes into another, you [179:49] know, we're going to throw out some [179:51] different terms here and some different [179:53] acronyms and Yagy is one of them. You [179:55] aren't going to need it. We're going to [179:57] see that here with Claude apparently [179:59] because it says, "Hey, we don't have a [180:01] builder pattern here, but we also don't [180:02] need one." So, we're not going to, you [180:04] know, Claude isn't going to suggest [180:05] throwing in a builder pattern just for [180:07] the heck of it. [180:09] Now, if we look at structural patterns, [180:11] the facade pattern, we found that with [180:13] our Express router, and it's well [180:15] implemented. It provides a clean [180:16] interface to authentication operations. [180:18] Simplifies HTTP handling complexity. And [180:21] the O route acts as a facade for [180:23] authentication complexity. [180:25] That's great. It's working well. No [180:27] changes needed. And we can see here we [180:29] have a decorator pattern that's in our [180:30] Express middleware chain. This one is [180:33] also correctly implemented. Has good [180:35] separation of concerns. [180:38] And it says ears a caution. Missing O [180:41] middleware. We don't have any JWT [180:42] verification middleware. So that's a [180:45] good way. It shows here how we can [180:46] remediate that with the JavaScript. [180:50] Now if we look at proxy pattern not [180:52] implemented, but we could because it [180:55] says there's no caching layer for [180:57] database queries, we could add a query [180:59] caching proxy and it shows how to do [181:01] that. [181:02] And that recommendation 6 out of 10. Now [181:05] if we look at behavioral patterns, so we [181:07] have the design patterns, how things are [181:08] set up, how they're architected, but the [181:10] behavioral patterns are also some [181:12] patterns that this tool looks at. And it [181:15] says chain of responsibility. We found [181:17] it with the express metal alert chain [181:18] properly implemented. Good error [181:20] propagation working correctly. [181:23] We're missing a strategy pattern because [181:26] it's single authentication strategy [181:28] only. [181:29] So it says only email password [181:31] authentication no multiple off [181:33] strategies error handling uses [181:35] conditional logic instead of strategy [181:37] pattern. So it does recommend implement [181:39] authentication strategy pattern here and [181:42] shows a way that you can do that [181:44] observer pattern. Here's another one [181:47] that we're looking at here and we found [181:49] that with emitter usage [181:52] and it says it's correctly used. [181:54] Database events are properly handled but [181:56] it's limited scope. only database [181:57] events, no application events, couldn't [182:00] expand user authentication events. So, [182:02] it says to add an application event [182:04] system, which is obviously this is just [182:06] a login app where you log in and log [182:08] out. Uh, so we don't have an application [182:10] event system yet, but we would want one [182:13] if we were to make this a more complex [182:15] application. [182:16] Command pattern not implemented, not [182:19] critical for current scope. So, again, [182:20] you aren't going to need it. Now we can [182:23] take a look at domain patterns in here [182:26] for the repository pattern. We're [182:27] missing this for direct database queries [182:30] in routes. Now this is something that [182:31] was called out in the previous one also. [182:34] We have direct database queries in our [182:36] routes which causes a bunch of problems. [182:38] It's a violation of separation of [182:40] concerns. There's no abstraction there. [182:42] And abstraction is very important with [182:44] software design. You know, you want to [182:45] be able to take the end of your cord and [182:48] plug it into a wall into a 110 interface [182:51] and have your device turn on. You don't [182:54] want to think about is it 110, is it [182:55] singlephase, is amperage, [182:58] etc. That's where abstraction comes in [183:00] and there's no abstraction with this and [183:02] it's hard to test because it's tightly [183:03] coupled to the database. Meaning, if we [183:05] were to switch databases, we got to go [183:07] in and modify routes and do all kinds of [183:09] stuff. So, n out of 10 critical [183:12] refactoring needed. And here's how we [183:14] can refactor it. [183:16] Now here we can look at the service [183:18] layer pattern. This one's missing and [183:19] it's missing business logic and route [183:21] handlers. Critical for maintainability, [183:24] right? Authentication logic again is in [183:26] the route handler. Direct manipulation [183:28] and controllers and that's the database [183:30] thing we just talked about. And logic is [183:32] tied to the HTTP layer. All of this is [183:35] critical for maintainability. So this [183:37] stuff doesn't have uh business logic, [183:41] you know, separated out into its own [183:43] layer. And so this is how it's [183:45] recommending we do that. Now the DTO [183:47] pattern data transfer objects partially [183:50] implemented manual object construction, [183:53] but it's an informal implementation [183:55] because it's manual. There's no [183:56] validation, no type safety. It says [183:59] improve data transfer objects [184:02] and shows us how we can do that. [184:05] And then we see the domain model [184:07] pattern. It says anemic domain, which is [184:09] not a great thing to read, right? No [184:10] business logic in the entities. There's [184:12] no domain entities. There's no business [184:13] logic encapsulation. There's no domain [184:15] validation. We don't really have a [184:17] domain. It's just a login app where you [184:19] log in with your name and password. But [184:21] this has definitely come in here and [184:24] said even with the minimal functionality [184:28] that you have, you should have this [184:29] pattern. [184:32] So here's a summary and recommendation. [184:33] So we have the critical issues. The [184:35] biggest stuff is repository pattern [184:37] missing, service layer missing, high [184:39] priority stuff, authentication strategy, [184:41] authentication middleware, factory [184:43] pattern for tokens, and it goes down to [184:46] medium priority, low priority, and [184:48] recommended refactoring order. So it [184:50] says, hey, here's how you should do it [184:51] in the order you should do it. You [184:52] should extract the repository layer, [184:54] then create a service layer, etc. This [184:57] refactoring would transform the [184:59] application from a simple script-like [185:00] structure to a wellarchchitected [185:02] maintainable system following [185:03] established patterns. And I've said this [185:06] before and I'll say it again. This is [185:08] something you can take this report and [185:10] copy and paste it into cloud code and [185:12] tell cloud code, help me make this [185:14] software more like what you're [185:17] suggesting here and make it pass better [185:19] on this test. And again, all of these [185:22] prompts, you're not going to have to try [185:23] to type them out or copy them or [185:25] transcribe them or something. Uh, [185:26] they're all available here at [185:27] github.com/jeremyorggan/cloudcode [185:30] reviewing prompts. So, let's take a look [185:33] at the next one. This one has been a [185:35] really helpful one for design patterns. [185:38] It's basically saying, what ones are you [185:39] using? What ones should you be using? I [185:41] think this kind of stuff makes your code [185:43] better. It really does. It gives you the [185:45] things to think about and the things to [185:46] look for. And that's exactly what we're [185:48] trying to do in this section of the [185:49] course. All right. So, we've done a [185:51] series of audits here that check our [185:53] software quality. It checks things like [185:56] our architecture, design patterns, [185:59] domain patterns, etc. Now, this is one [186:02] of my favorite checks. And this one is [186:05] basically evaluating your application [186:07] for how it adheres to solid principles, [186:10] right? And so, solid principles, we'll [186:13] explain that if you don't know what that [186:14] is. We'll kind of go through it, but I [186:17] am going to copy in the prompt here, [186:19] which is 47 lines. And then while it's [186:23] processing the prompt and it's looking [186:24] at our application, I'll explain exactly [186:26] what it is. So, we'll hit enter. [186:30] We'll bring this up. And basically here [186:34] we're saying evaluate this application [186:36] and its adherence to solid principles. [186:39] Solid principles are single [186:41] responsibility, open closed principle, [186:44] list substitution, interface segregation [186:47] and dependency inversion. [186:50] So the first thing it checks for is [186:51] single responsibility. [186:54] And the single responsibility principle [186:56] is a class or module should only do one [186:59] thing and do it well. Now the reason for [187:01] this is because that way it only has one [187:04] reason to change, right? So if the [187:07] module only has one single [187:09] responsibility, right, you had only one [187:11] job. Well, if it has that [187:13] responsibility, then it only has one [187:14] reason to change. And this is very [187:17] important for software design at both a [187:20] macro level and a micro level. The [187:23] opencloed principle. Now, this one's [187:24] pretty important as software starts to [187:26] grow and get big. code should be open [187:29] for adding new features but closed to [187:32] modifying existing core logic. Right? So [187:35] in other words, you should be able to [187:37] add new stuff to it, but you shouldn't [187:40] be able to change the core logic because [187:42] when you change the core logic, that's [187:44] when you start to get regression and [187:46] dependency problems and things like [187:48] that. So the core logic of the module [187:50] should always stay the same. Liskov [187:52] substitution. If something works with a [187:55] base class, it should also work with any [187:58] of those subclasses without breaking. [188:00] So, if you're familiar with [188:01] object-oriented programming, you have a [188:03] base class. Um, and it has a set of uh [188:07] properties and methods. And that base [188:10] class, anything that comes off of that [188:13] base class should work with any of the [188:15] subclasses. And that's basically just [188:17] keeping a solid design. Interface [188:21] segregation principle just means don't [188:23] force things to depend on methods that [188:25] they don't use. Right? So if you make [188:28] something depend on something else [188:30] somewhere else that it's not using then [188:34] your interfaces can have problems and a [188:36] lot of this comes in during testing [188:39] and dependency inversion principle [188:42] depend on abstractions right we've [188:44] talked about abstractions in the last [188:46] couple of videos you know and I used a [188:48] electrical outlet as an abstraction you [188:51] want to depend on abstractions which are [188:53] basically general rules but not concrete [188:55] implementations [188:56] So code is more flexible and testable. [188:59] So you're depending on an abstraction [189:01] like a wall plugin. But if it's a [189:04] concrete implementation and it's ultra [189:06] specific, then you're going to run into [189:07] problems. So these are the solid [189:09] principles that we're looking for. And [189:11] now how do we check it? Well, with our [189:13] prompt here, we can say with single [189:15] responsibility, does each module have [189:17] one reason to change? I mean, that one [189:19] really cuts down to kind of the core of [189:21] what SRP is. And then it identifies [189:24] modules that are violating that and it [189:27] gives an example a user controller that [189:29] also handles emails, payments and [189:30] authentication. [189:32] Now with the o openlo principle we say [189:34] can we extend this without modifying it [189:36] right? So can we add features to this [189:38] without changing the core functionality? [189:40] Are there hard-coded switch statements [189:42] that should be polymorphic? Check for if [189:44] else chains that could be strategy [189:46] pattern. Now with Liskov substitution, [189:49] do the derived classes properly extend [189:52] the base classes? Now it sounds simple. [189:54] It sounds like you know your application [189:55] wouldn't work if that were the case. But [189:58] if you've been in software engineering [189:59] long enough, then you know that this is [190:02] a very valid concern. Derived classes [190:05] can extend base classes in funky ways [190:08] and those funky ways cause problems when [190:10] you go to scale. And we're saying are [190:13] there any violations of expected [190:14] behavior here? Now with interface [190:17] segregation, are interfaces too large? [190:19] This is a problem very common problem in [190:22] software engineering that sometimes [190:24] interfaces become enormous. And one way [190:28] that I've described this in the past [190:29] when talking about it is you have a [190:31] remote control and it has 493 buttons [190:34] and you have to press these buttons and [190:36] all these different combinations, but [190:38] really the person holding the remote [190:40] only wants to watch TV. So you can [190:42] easily get out of touch with what an [190:44] interface is supposed to do. and over [190:46] complicate it and you can make it so [190:49] that there comes those weird [190:50] dependencies again on functions you [190:52] don't use. So in here we're saying are [190:54] the interfaces too large which is [190:56] somewhat subjective but cloud code knows [190:59] what to look for and knows how to make [191:01] an estimation and do clients depend on [191:03] methods that they don't use. So that's [191:06] one of the things where you can lock up [191:07] an interface by saying it requires all [191:09] these methods and if it doesn't use them [191:12] then it can cause big dependency [191:14] problems down the line. And for [191:16] dependency inversion are we depending on [191:18] abstractions or concretions? Is there [191:21] proper dependency injection? This this [191:23] gets really important during testing [191:25] especially if we don't have proper [191:26] dependency injection there's going to be [191:29] a lot of stuff that we're not going to [191:31] be able to test. And we want to check [191:33] for new keyword uses versus injections, [191:35] right? So we want to see if there's, you [191:37] know, new stuff going on where we're [191:40] creating things rather than injecting [191:42] the things it depends on. We're hard [191:44] coding it there in the methods. So here [191:47] we're saying rate solid compliance 1 to [191:49] 10 with specific violations and fixes. [191:51] And then we have our standard report [191:53] thing here where it says structured [191:54] finding report, precise code level fix, [191:58] etc. So we've seen that before. Now we [192:00] can see it's gone through all of our [192:01] files and it says, "Do you want to make [192:04] this edit to solid compliance report?" [192:06] Yeah. Yeah, we do. Let's check it out. [192:11] So, we're going to go in here to audits, [192:13] solid compliance report. Let's see what [192:16] Claude found for us. [192:19] Now it says this express authentication [192:22] application demonstrates a basic [192:24] understanding of separation of concerns [192:25] but it has significant violations across [192:28] all solid principles. So this wasn't [192:31] something that I was expecting. However, [192:34] we have to remember where this code is [192:37] coming from and it's coming from samples [192:39] of other people's code. So all these [192:42] public GitHub repositories, public [192:45] software all over the place, blog posts, [192:48] YouTube videos, all of this code is [192:51] ingested by these LLMs and it's averaged [192:54] out and sometimes bad code can make it [192:56] right to the top and say, you know what, [192:57] this is how everybody does this method. [193:00] And everybody could be doing it in a [193:02] terrible way publicly and putting it on [193:04] their GitHub and putting it on their [193:06] blog and everything else. So that's one [193:07] of the things to remember. So you might [193:09] be saying, well, why is Claude code [193:11] putting out code that it doesn't even [193:13] approve of? Well, because these are two [193:15] separate processes. When we ask it to [193:17] generate code, it's generate based on [193:20] what kind of code it's seen and how it's [193:21] seen it used. When we're putting in [193:24] these reports and we're doing these [193:26] audits, it's basically saying, "Oh, now [193:28] I need to look for these things based on [193:30] what I know about these things." So this [193:33] one goes into some pretty detailed stuff [193:36] because as I mentioned we are violating [193:39] all the solid principles. So let's take [193:41] a look. Violations identified high [193:43] severity monolithic o route handler. [193:46] Again we're talking about our o handler [193:48] which seems to be ostensibly terrible at [193:51] this point and it's a single function [193:53] that handles validation, authentication, [193:55] database queries, JWT generation and [193:58] error handling. Now earlier we did an [194:00] audit where it talked about the database [194:03] queries in in the routes and how that [194:07] was a bad thing. This is giving us more [194:09] detail which is exactly why I ran the [194:11] first kind of overall [194:14] look at the software stuff and then now [194:15] we're going down into detail. Now we can [194:17] find out that yeah there were definitely [194:19] database queries and raw SQL in our [194:22] routes but this is digging down even [194:25] deeper and saying there's one function [194:27] that has authentication database queries [194:29] JWT generation and error handling all [194:31] things that should be abstracted. So the [194:34] reasons to change input validation [194:36] changes authentication logic changes [194:39] anything changes this method breaks and [194:42] so that's exactly why this one is a high [194:44] severity and they're wanting to address [194:47] it and it shows some ways to address it. [194:49] Now let's look at a medium severity one [194:51] database module mixing concerns. [194:53] Database connection handles both [194:54] connection management and logging. This [194:57] is not something that was brought up in [194:58] a previous audit. So this is very [195:01] helpful and this is exactly why we're [195:03] kind of drilling down and doing these [195:05] more detailed audits. [195:07] It's basically saying the database [195:09] connection handles connection management [195:11] and logging and there's a lot of mixing [195:14] concerns there and that violates the [195:15] opencloed principle. The issue is adding [195:18] new database error types requires [195:20] modifying existing code. So again, we're [195:22] modifying [195:24] the core functionality of the code [195:26] whenever we try to add anything new. And [195:29] it shows a remediation for that and how [195:32] to fix it. Here's another one. No [195:34] authentication strategy abstraction [195:36] cannot extend to support OOTH, LDAP, or [195:39] any other O methods without [195:40] modification. Now, this is super [195:42] important because if this were a real [195:43] application [195:45] that we're building and deploying into [195:47] the enterprise, then we're going to want [195:49] OOTH. We're going to want LDAP. We're [195:51] going to want things like that. And this [195:54] isn't possible without coming up with [195:56] some kind of strategy pattern. I mean, [195:57] it's possible, but it's not possible in [195:59] a clean way. So, that's one of the [196:03] things that we want to look at here in a [196:06] Liskoff substitution principle. Our [196:08] score of 6 out of 10 limited inheritance [196:10] in the codebase [196:12] but some issues present and then here's [196:16] a bunch of different issues that kind of [196:20] relate to that list of substitution [196:22] principle pool connection interface [196:24] direct instantiation of pool prevents [196:26] substitution with mock or different [196:28] database clients. Now why are we going [196:29] to use a mock? Obviously for testing so [196:32] testing is going to be very difficult [196:34] with the way this is designed right now. [196:36] If we're going to do thorough testing [196:38] with 100% code coverage, this is going [196:40] to be a problem. But the great thing is [196:43] here's our remediation. It shows how we [196:45] can solve that problem. Now, the [196:47] interface segregation principle, it says [196:51] JavaScript's duct typing limits [196:53] traditional interface violations, but [196:55] conceptual issues exist. So, in other [196:57] words, this could work and there's not a [196:59] lot we can do when it comes to [197:01] JavaScript. You know, this isn't [197:03] something like Java or C. So there is [197:05] some definite limits here, but it says, [197:08] you know, route handlers depend on the [197:10] entire express wre objects when they [197:13] only need specific properties. Handlers [197:15] are tied to express specific methods [197:17] that they may not use. So once again, [197:20] we're talking about dependency on [197:21] methods that we don't use and it offers [197:24] some remediation here. Now, dependency [197:27] inversion principle, this is the the [197:30] final one. They talk about major [197:31] violations. It says here 10 out of 10 [197:34] direct database dependency [197:36] again it's very upset about the database [197:40] connections in the authentication routes [197:44] right so putting things into routes this [197:47] is very poor I took a few tutorials and [197:49] put it together type of design here um [197:52] and I'm not trying to insult cloud's [197:54] output because it's based on what it's [197:56] seen but we can see here the issue is [197:58] highle o off module depends on low-level [198:00] database implementation right directly [198:02] in the O module. What's the point of [198:04] abstracting that database implementation [198:06] and taking it out of the O module? The [198:09] biggest most brightest reason for doing [198:11] that is switching database providers. So [198:14] if you have PostgreSQL and you've got a [198:16] bunch of code with it and you want to [198:18] change it to Mariab or you want to [198:21] change it to Firebase or something, [198:23] you're going to have to go in and blow [198:24] that route apart and possibly affect [198:27] your routing. Whereas if you separated [198:30] it out and abstracted it into its own [198:32] class with a set of methods, you could [198:34] take the new database [198:36] right in those implementation methods [198:39] using that same method signature, same [198:42] interface and you can plug it right in [198:45] with a couple of lines of code changed. [198:47] You plug in this new module, it's good [198:49] to go. We can't do that with our [198:51] existing application. That's why it's a [198:53] 10 out of 10 direct database dependency [198:56] problem. And it shows here's how to fix [198:58] it. You know, we can create a repository [199:01] pattern here with PostgresSQL [199:04] that extends user repository. So if you [199:07] wanted to put in something for Mariab, [199:09] you guessed it, Maria user repository [199:12] extends user repository. So on and so [199:15] forth. Here's another high severity 9 [199:16] out of 10 direct environment variable [199:18] dependencies. [199:20] So we're accessing process.anv. [199:23] You can't test with different [199:24] configurations without environment [199:26] manipulation. Now, you want your tests [199:29] to be encapsulated pretty much [199:31] independent of the environment entirely [199:33] if possible. And so, this is a way to [199:37] basically say you need to get away from [199:40] these dependencies on the environment. [199:42] We want to containerize this in a way [199:44] either formally containerize it in [199:46] Docker or containerize it conceptually [199:50] and move away from that. and it shows [199:52] how to do that where you can inject a [199:53] dependency instead. [199:56] And so that's great. We've got a few [199:58] more here. We've got a high severity [200:00] hard-coded crypto dependencies, direct [200:02] brypt and JWT imports. That's also a [200:05] security concern, but in this case, we [200:08] can't mock or substitute crypto [200:10] implementations for testing. So, this [200:13] one is another one that will throw us [200:15] some problems if we try to make tests. [200:17] Now the idea is you want to make tests [200:19] and you want to have good test coverage [200:21] which means you want tests to cover the [200:23] majority of the code you've written. And [200:25] in our case with these problems that we [200:27] found from the software audit we have [200:29] work to do before we can get to that [200:31] point. Specifically critically [200:33] immediately we need to extract the [200:35] authentication service implement the [200:36] repository pattern and create a [200:39] configuration service. [200:41] After that high priority which means we [200:44] better get this done pretty quick. We [200:46] want to implement an error handler [200:47] strategy, right? Replace this switch [200:49] statement with an extensible pattern um [200:51] that we can take these errors and form [200:54] them into objects that we can use and [200:56] put them into other areas. We want to [200:58] extract that JWT service. We don't want [201:00] that hardcoded in there like it is right [201:03] now. Same thing with the validation [201:05] service. We want to separate that logic. [201:07] And then medium priority. This one, you [201:10] know, after we get everything else done, [201:11] we want to create some authentication [201:12] strategies. Support multiple off [201:14] methods. When's the last time in 2025 [201:17] you've come across an application that [201:19] only had a single method for [201:21] authentication? Most of the time there [201:23] are several. [201:25] You want to implement service containers [201:27] for proper dependency injection. That's [201:29] really going to help you with your [201:30] tests. And you want to reduce the [201:31] coupling between layers, which helps [201:33] with tests and expanding your software. [201:36] Here's the recommended architecture [201:38] where it says this is how we should set [201:40] it up file-wise etc. And code quality [201:45] metrics. It talks a little bit about how [201:47] it came to this conclusion. Cyclomatic [201:50] complexity. That's something that [201:52] software engineers talk about all the [201:53] time. What is your cyclomatic [201:55] complexity? Well, in our case, it's [201:57] high. We have a login function that has [201:59] eight plus decision points from a switch [202:02] statement. We know from earlier. So, [202:04] yeah, that's messy. That's not optimal. [202:07] Lines per function excessive. Login [202:10] function is 79 lines long. Now, there's [202:13] a few idioms out there and kind of [202:15] quotes that they say like keep your [202:16] controller skinny and things like that. [202:18] And one of those things is lines per [202:21] function is huge. Keep your function [202:22] small. Do one thing and do it well. When [202:26] it needs to change, it should only be [202:28] that one thing to change. That comes [202:29] into lines per function. Personally, 79 [202:32] lines of function seems very excessive [202:34] to me because it's not doing one thing [202:37] and doing it one well if it takes 79 [202:39] lines to do that thing, right? So, we [202:41] know that it's doing multiple things and [202:42] this report actually shows that, you [202:45] know, earlier it's doing multiple things [202:47] in one function. We don't want that. Uh [202:49] we've got some high coupling direct [202:51] dependencies, the five plus modules and [202:54] it's dependencies to stuff that we're [202:55] not necessarily using. Testability is [202:58] poor. Like I said, if we want to get to [202:59] 100% [203:01] test coverage, this will be very [203:03] difficult and we've got a lot of work to [203:04] do. This report tells us that. So, I'm [203:08] really glad that Claude can go through [203:10] and kind of go through all of these [203:12] different principles. And this is just a [203:14] solid test, right? There's a bunch of [203:16] other tests that we're going to go [203:18] through, but this is just a solid test [203:20] that I think you should run on every [203:21] single application you generate with [203:23] Cloud write yourself. I did some [203:26] personal stuff where I grabbed some of [203:28] my old repositories and started running [203:29] some of these audits and I found, wow, I [203:31] missed a lot of things and there's a lot [203:34] of work to do. So, this is one of those [203:36] things in an enterprise, I guarantee [203:38] you're going to find it. And once again, [203:41] if you're just watching this video and [203:43] you haven't watched our previous videos, [203:45] you don't have to type these giant [203:46] prompts in because they're all available [203:48] here at github.com/jeremyorggan [203:52] reviewing prompts. [203:54] Thank you for watching. Now let's jump [203:56] into the next part which is error [203:58] handling and resilience. A huge part of [204:01] software engineering that cloud code can [204:03] really help you out with. Okay, let's [204:05] talk about a very important audit here. [204:08] Now, we've been doing audits on our [204:09] software quality, and we've gone from [204:12] here's an abstract like tell me [204:14] generally what's wrong based on these [204:16] principles and now we're starting to [204:17] narrow it down to very detailed [204:21] principles because we want to know. And [204:23] when we do this, you know, by taking [204:25] this approach, we're going to see some [204:27] repeated information cuz we're basically [204:29] saying, look at this entire software [204:31] project and tell me what's wrong with [204:32] it. And then we start to narrow down, [204:34] you know, tell me, does it violate these [204:36] principles? Does it violate these design [204:38] patterns etc? And now we're talking [204:40] about one that's very important which is [204:42] error handling and resilience. How [204:45] resilient is our application? Well, [204:47] error handling is a big part of it. [204:49] Error handling can be a big problem [204:51] because it can result in unsaved data. [204:54] It can result in frustrated users and it [204:56] can have security implementations. So, [204:59] this one is pretty big. And this prompt [205:02] is specific towards JavaScript and API [205:06] applications. So, keep that in mind. And [205:09] again, I'm going to paste this in. Hit [205:12] enter. And then we're going to look at [205:13] the prompt while it chews through our [205:14] software and takes a look at it. Now, in [205:17] this prompt, we're saying evaluate this [205:19] entire software package and perform a [205:21] comprehensive error handling review on [205:24] these subjects. Error handling [205:26] consistency. Is there a centralized [205:28] error handler? You know, are we just [205:30] console logging this? Are we logging it [205:31] to a file? Are we just exploding on the [205:34] screen and telling the user, "Sorry, but [205:37] here's a bunch of information. Are [205:39] errors handled uniformly? Do we have [205:42] custom error classes versus generic [205:44] errors?" And then we have error [205:46] categories here. And these are all [205:48] pretty specific to web-based stuff, [205:50] right? 400, 401, 403, [205:53] etc. Are they properly categorized? Now, [205:55] this one's important. Sometimes people [205:56] like to just kind of dump everything [205:59] into that server 500. I've seen that [206:01] before with APIs where they're like, [206:04] "Well, we'll just give them a 400 and [206:06] call it a day." But there are definitely [206:08] other errors that need to be considered, [206:10] specifically rate limit errors. I've [206:12] seen rate limit errors dumped into just [206:15] general server errors. Same with [206:16] authentication and authorization. So, [206:18] this is basically saying, are we [206:19] splitting it into categories and are we [206:21] doing that properly? Async error [206:24] handling. Now, asynchronous functions [206:25] are all over the place, especially in [206:27] web applications. Are we handling [206:29] unhandled promise rejections? That's [206:31] something that if you've developed a web [206:33] app at any point in your life, you've [206:35] probably seen a bunch of those. Async [206:37] middleware wrapper usage, little less [206:40] common. Callback error handling, very [206:42] common. Event emitter error handling, [206:44] very common. We're just trying to see, [206:47] are we doing this properly? Are we doing [206:49] this in a sane and simple way? Error [206:52] recovery. And this kind of goes back to [206:54] the losing data, exposing secrets for [206:58] security issues. You know, how are we [207:01] recovering? Are we doing a graceful [207:03] degradation of our errors, retry [207:06] mechanisms, circuit breakers, fallback [207:08] strategies, or are we just dumping a big [207:10] dump of information on the screen? [207:12] Hopefully not. And error information, we [207:16] have development versus production error [207:17] details. This is very important because [207:19] the needs of each are quite different. [207:22] Stack trace exposure. Are we doing that? [207:24] Do we want to expose a stack trace? [207:26] Perfectly fine in development. No can do [207:28] in production. Error logging [207:31] completeness. User friendly error [207:33] messages. So this kind of goes back to a [207:36] little bit with security and user [207:38] interface. The user friendly error [207:39] messages. Are we just throwing a stack [207:41] trace up there? The user is not going to [207:42] know what to do with that, but an [207:44] attacker will. So this is where the [207:47] error information, who gets what type of [207:49] information is very important. And of [207:51] course, we're providing a report. And if [207:54] we scroll down here, it says, "Do you [207:56] want to make this edit to error handling [207:58] comprehensive review?" Yes. And we do [208:01] want to check out that comprehensive [208:03] review. [208:08] Now, if we look at this executive [208:10] summary, our overall score is 3.5 out of [208:13] 10, which is not great. The express [208:15] login demo exhibits severe error [208:17] handling vulnerabilities that create [208:19] significant security risks and [208:21] operational challenges. So as I said [208:24] earlier, we're risking losing data, [208:26] frustrating the customer and security [208:28] risks. And according to this audit, we [208:31] are not doing well. We're failing on [208:35] error handling consistency. [208:37] We're partially failing in error [208:39] categories. We have basic HTTP codes, [208:41] but we're missing categorization. [208:43] Async error handling, we're failing [208:45] that. There's no unhandled rejection [208:48] protection. Uh error recovery fail. [208:51] There's no retry fallback or circuit [208:52] breaker patterns. These are all [208:54] important things because sometimes a [208:56] glitch is a glitch and it just happens. [208:59] And there are times where there are [209:01] timing issues or there's some service [209:04] that's just doesn't put out the right [209:06] thing at the right time, but if we retry [209:08] it, everything is great. And that's [209:10] where this basically comes in is we need [209:12] a retry, we need a fallback. If [209:14] something fails, we'll try this or the [209:16] circuit breaker pattern to just make [209:19] sure cuz sometimes a small glitch can [209:21] completely take down the user and what [209:24] they're trying to do and they'll get [209:25] frustrated and close out and stop using [209:27] your application. Error information [209:29] partial. there's sensitive data exposure [209:32] and logs which is a security problem and [209:35] we're going to do a lot of security [209:36] editing and auditing in our next module. [209:41] Let's just take a quick look at the [209:43] problems that we're having here. [209:45] Critical no centralized error handler [209:48] errors are just kind of, you know, [209:49] sometimes they're going here, sometimes [209:51] they're going there, and the error [209:54] responses are inconsistent. [209:57] But here we go. Current state and [209:59] remediation. So here's how we can fix [210:01] it. Medium inconsistent error response [210:04] format. This is another one. If you [210:07] don't have a consistent error response [210:08] format, [210:10] you know, there's really it really makes [210:12] logging in presentation quite difficult, [210:15] especially when you get an error that [210:16] you're not anticipating and it just [210:18] dumps a bunch of random stuff on the [210:20] screen. So this is basically saying the [210:23] remediation is a standardized error [210:25] response utility. Here's another one [210:27] here that's kind of medium. Basic HTTP [210:30] status code usage. We talked about this [210:32] a little bit. Current status. Yeah, [210:34] we've got a 400 bad request, which is [210:36] great. 401 unauthorized, which is great. [210:39] So, those two are separated out. The 500 [210:43] internal server error is great for [210:45] generic stuff. And then we have a 503 [210:46] service unavailable, [210:48] which in this case it says used for [210:50] database errors, which that can usually [210:53] be true. Usually, it's database that [210:54] causes that. But we don't have a 403 [210:56] forbidden if you're not supposed to be [210:59] looking at the resource that you're [211:00] trying to access. We don't have a 404 [211:03] not found, which can be pretty [211:05] important. We don't have a 429 too many [211:08] requests. So if somebody sends too many [211:10] requests, it's just going to get a 500 [211:11] error. And we have a 409 conflict where [211:14] we don't have anything there. If we have [211:17] a conflict error, [211:20] here's how we can remediate that. gives [211:22] us a nice full explanation. [211:25] Now, async error handling, like I said, [211:28] with everything web-based these days, [211:30] async is super important. Uh, we have no [211:35] unhandled promise rejection protection, [211:37] which comes up quite frequently. [211:40] We're missing global handlers, handlers [211:42] for unhandled rejections. So, when we [211:45] have a promise rejection, it just dumps [211:48] out into the console and the application [211:50] doesn't work. [211:53] Now we're missing async wrapper [211:55] middleware which that was mentioned in [211:57] an earlier audit here. So we have manual [212:00] try catch blocks and async routes. We're [212:02] basically we don't have any middleware. [212:04] We don't have anything that's really [212:05] handling this async with the respect [212:07] that it deserves. [212:10] Another critical one, no retry [212:12] mechanisms, which we know about that. [212:14] It's not trying to, [212:17] you know, redo if there's a timing [212:19] issue, if there's a race condition, if [212:20] there's something like that. Our [212:22] application just gives up and says, [212:24] couldn't work where it should try to [212:27] retry and make things happen again. [212:30] Another critical one, no circuit breaker [212:32] pattern. So, there's no protection [212:33] against database cascade failures. What [212:36] does that mean? Well, we can have a [212:40] failure happen that can go across and [212:42] rip our database apart. Basically, [212:44] there's no circuit breaker and a circuit [212:46] breaker pattern essentially says, "Oh, [212:48] if these certain things have gone wrong, [212:50] then just cut it all off and stop the [212:52] operation." We don't have that here. So, [212:55] the operation will continue and may [212:57] cause some pretty severe damage. But, we [212:59] have remediation here. [213:02] So, these reports are fantastic. We have [213:05] sensitive information disclosure. This [213:07] one is pretty big for security. It'll [213:10] say full error objects and database [213:12] details log. So if somebody's trying to [213:14] figure out how our database is set up, [213:16] what database we're using, they can just [213:18] check our logs, right? If we've had any [213:20] errors, it gives them everything they [213:22] need to know. We have no structured [213:24] logging, by the way. So our logs are [213:26] going to be a bunch of random stuff [213:27] dumped into a text file and or [213:31] console.log. [213:33] And here it says applicationwide. It [213:36] only uses console log error statements. [213:38] So in this case, we may not even be [213:40] logging this in an actual file that you [213:42] can look at. It's just going in the [213:44] console on all the clients that are [213:45] connecting to it. Not great, not [213:48] optimal. [213:50] Development versus production error [213:52] handling. Again, during development, we [213:55] want to expose everything, right? So if [213:57] there's an error, we want to show the [213:58] stack trace. We want to show the log [214:01] entries. We want to show every bit of [214:03] information so that the developer, he or [214:06] she can look at that and say, "Okay, [214:09] here are the problems. Let's dig into [214:11] it." We don't want that in production. [214:14] In production, we want that to say, [214:15] "Something went bad. Let us try it [214:17] again." Or, "Something went bad. Please [214:20] contact support." We don't want it to [214:22] dump out all this stuff that attackers [214:23] can use. So, that's what that one's all [214:26] about. [214:28] And it gives us a plan. We need to [214:30] implement centralized error handler. We [214:32] need to add unhandled promise rejection [214:35] protection and sanitize error logging as [214:37] soon as possible. Then we can implement [214:40] async wrapper middleware structured [214:42] logging. Create some error response [214:45] standards which there are tons of them [214:47] available on the internet that you can [214:49] look up or cla itself I'm sure can come [214:52] up with a pretty good framework for [214:54] that. We want to implement database [214:56] retry logic. Add a circuit breaker in [214:59] there or many circuit breakers. [215:01] Implement graceful degradation, [215:04] comprehensive error categories and [215:05] environment specific error handlings [215:08] shows us how to do that. What do we get [215:11] from this? If we run this and we fix all [215:14] these things, we get improved system [215:15] reliability, reduce security risk, [215:17] better debugging capabilities, and [215:19] production readiness. [215:21] We're starting to realize after doing [215:23] these software audits that this is not a [215:25] production ready application. When you [215:27] saw the application earlier, it probably [215:28] looked pretty good. Maybe it works [215:30] pretty good, but it's not quite [215:32] production ready. And that's the whole [215:34] point of these audits is we want to make [215:36] sure that this is production ready [215:38] software. Now, we've taken a look at [215:42] error handling and how errors are [215:44] handled, but what about exceptions? [215:46] There's a difference between exceptions [215:47] and errors. And if you're a software [215:49] developer or software engineer, you [215:50] already know that. So let's see how we [215:53] handle exceptions and whether that's [215:56] acceptable and we can do that with [215:59] another cool prompt that we can send [216:00] cloud code. Thank you for watching. I'll [216:03] see you in the next one. Okay, so we've [216:05] talked about errors in a program and we [216:07] all know what errors are and how they're [216:09] defined. Exceptions are a little bit [216:10] different. And exceptions are basically [216:12] when the software is going to try to do [216:14] something and if all the cards aren't [216:17] lined up and all of the things aren't [216:19] exactly how they should be, then it [216:22] catches that and says, "Hey, something's [216:24] wrong. Here's what it is." And it writes [216:27] it out to a log or it writes it out to [216:29] the screen or something like that. And [216:32] not all exceptions are, you know, big [216:35] deals where they stop everything. [216:37] Sometimes they're just kind of small [216:38] things where we retry. And so what we're [216:41] going to do here is we're going to do an [216:43] audit of how our application handles [216:46] exceptions. [216:47] Basically, how does it catch the errors? [216:50] What does it do with them? Is it [216:52] consistent? Things like that. So we're [216:55] going to dump the prompt in here as we [216:57] have before. And while Claude is [217:00] processing and going through our app, [217:02] we'll take a look at this prompt. And it [217:04] says, "Evaluate this entire application. [217:06] Trace error flow through the [217:07] application." And so we have some [217:09] critical paths to analyze. Database [217:12] connection failure, third-party API [217:14] timeout, invalid user input, [217:15] authentication failure, and file system [217:18] errors. Now, this is just kind of a [217:20] generic type of thing for applications [217:23] like this. We're looking through these [217:25] things. They may not all be applicable [217:27] to this particular application, but [217:31] these are the things that we're going to [217:33] look for. We're going to look for what [217:35] happens when one of these things happens [217:37] for each bath. We want to verify where's [217:40] the error caught, how's it transformed, [217:42] you know, what do we do with the error? [217:44] Do we pretty print it somewhere? Do we [217:46] log it? Do we strip out all the PII [217:49] stuff like that? What gets logged? Uh [217:52] what does the user see? So, that's [217:54] usually two different things, right? [217:55] Because we don't want to give away [217:57] things to the user that might expose how [218:00] things work underneath or exposes PII or [218:04] something like that. So sometimes we log [218:07] things that we wouldn't necessarily show [218:09] the user. [218:12] And finally, is the system state [218:14] consistent? This is a big one because [218:16] the system state sometimes you can catch [218:19] exceptions and it can say, "Okay, we're [218:21] shut down now. Please log out and log [218:24] back in later or something like that." [218:25] And then sometimes an exception can just [218:27] take down the whole thing and the whole [218:29] service stops and you're in a bad spot. [218:32] So we're asking all these questions with [218:34] this audit here. And it says create an [218:37] error flow diagram showing error origin [218:39] points, transformation layers, final [218:41] handling points, recovery mechanisms. [218:44] And we want to take a look at some [218:46] anti-atterns, right? Some swallowed [218:49] exceptions, which are empty catch [218:51] blocks. If you've been programming for [218:52] any amount of time, you know exactly [218:54] what an empty catch block is. It's [218:55] basically like, hey, if there's an [218:57] exception, do nothing and just keep [218:58] going, keep moving through. uh not a [219:01] great situation to have that set up. Uh [219:05] generic catch all handlers that hide [219:07] specific errors. So that's always a [219:09] problem if you dump all of your errors [219:10] into the same bucket. Um you don't have [219:13] any kind of differentiation between [219:15] them. Sometimes you can miss things and [219:18] in many languages you need to catch [219:21] specific errors to get specific info [219:24] from the exception. We have errors used [219:26] for flow control. [219:28] Now this one we are I remember looking [219:31] through this code I know that we're [219:32] going to find this and basically what [219:35] errors use for flow control is if this [219:37] is an error 400 do this if it's error [219:39] 404 do this if it's error 200 do this [219:42] the problem with that is you were [219:43] tightly bound to the actual error codes [219:47] and text not really good we have missing [219:50] error boundaries and what that is is [219:52] basically where an error happens [219:54] somewhere down in a child component and [219:58] the error comes back somewhere else [220:00] upwards in the tree and it's not really [220:02] specific. And we have inconsistent error [220:04] formats which is obviously you know some [220:06] errors have this plain text message in [220:09] the code some of them don't etc. We want [220:11] that standardized [220:13] and we want to provide a standardized [220:15] error handling template. Meaning what [220:18] can we build with JavaScript in this [220:21] case that can just catch errors as they [220:23] come out and catch exceptions and handle [220:26] them in a consistent and solid way that [220:29] we can depend on that we can use for [220:31] testing and knowing what to expect. [220:34] And then of course we're doing this [220:36] report that we've done throughout our [220:38] other ones where we say provide a [220:40] structured finding report, code level [220:42] fix, [220:43] etc. So let's scroll down here. [220:46] Yes, we want to build the error flow [220:50] audit document. [220:53] And this one is going to be errorflow [220:55] comprehensive analysis [220:59] MD. Let's scroll up and take a look at [221:01] it. This report provides a complete [221:04] analysis of error handling patterns [221:05] throughout the express login demo [221:07] application. Now, this evaluation traces [221:10] error flows from origin points through [221:12] transformation layers to final handling, [221:14] identifying critical gaps in error [221:16] management and system resilience. Just a [221:20] big paragraph that says we're going to [221:22] check and see how you handle exceptions [221:24] and make sure it's consistent. [221:27] Now the critical finding is this [221:29] application exhibits multiple high [221:31] severity error handling vulnerabilities [221:33] that can lead to service disruption, [221:35] information disclosure and inconsistent [221:37] state. Now these are the three things [221:39] that we talked about right when we're [221:40] talking about displaying errors. You [221:43] know we can have error problems that [221:45] will stop the service. If we're not [221:46] handling an exception properly it can [221:48] break everything, break the service. we [221:50] have information being shown to users or [221:53] in logs that should not be shown and an [221:56] inconsistent system state means you know [221:58] sometimes an exception does nothing and [222:01] sometimes it takes everything down we [222:03] want a little bit more uh security than [222:06] that right so in our entry path analysis [222:10] we've got an HTTP server without timeout [222:13] limits we've got a single post login [222:14] endpoint postgres SQL pool without a [222:17] timeout configuration the timeouts are [222:20] big. We've already seen reports where [222:22] they're talking about timeouts. They're [222:24] super easy to add, but we don't have any [222:26] in our current application. And it says [222:29] dependencies, Express 4212, JWT [222:32] authentication, PostgresSQL Express [222:34] validator. What's missing is thirdparty [222:37] API clients, file system operations, and [222:40] comprehensive middleware stack. And [222:41] that's because this application doesn't [222:43] really do anything right now. It's just [222:45] basically a login app. [222:47] But that's good to know that you know [222:49] it's suggesting that we do these things [222:51] and it's not finding it here. We're [222:53] finding here in database connection [222:55] failure. So whenever the database fails [222:59] we have something here where we have [223:01] pool creation without connection limits. [223:03] So that can make it create a pool that [223:05] can be overwhelmed that can take down [223:06] the whole application. We have a [223:08] database query without timeout [223:09] protection. That can be bad because the [223:12] way this works is you have a database [223:14] query doesn't have a timeout right? So [223:16] it hangs for some reason. Uh the user [223:19] closes their browser, opens it again, [223:21] tries it again, the next one hangs, and [223:23] the next one and so forth. And multiply [223:25] this by a thousand users and all of a [223:28] sudden you've got a problem. You've got [223:30] a service that's ending. So this again [223:33] is a single line of code. It's easy to [223:35] implement. Uh but we need some timeouts [223:38] for sure. The error flow trace postgres [223:41] SQL connection error pull query routes [223:44] off goes into a catch block goes into an [223:47] error code switch. We know what the [223:49] audit's going to find next right [223:51] specific error response generic fallback [223:53] lines. [223:55] So for transformational analysis this [223:58] one says good for specific postgres SQL [224:01] error code handling we get e connection [224:04] refused if the database connection fails [224:06] we get 28p01 [224:09] and that is transformed into a 503 which [224:12] is database authentication failed or [224:15] 3D00 [224:17] which transforms to 503 database does [224:19] not exist. Now, here are some critical [224:22] gaps that's showing. That's no timeout [224:24] handling. So, we talked about that. No [224:27] connection pool exhaustion protection. [224:28] We've talked about that. No retry logic [224:31] for transient failure. So, if something [224:33] just, you know, all the cards didn't [224:35] line up, everything wasn't timed [224:36] properly, something failed, it doesn't [224:38] go back and retry to see if it can try a [224:40] second time. And oftent times, you can [224:44] have a system that does that thousands [224:46] of times a day. you know, things the [224:48] timing just isn't right and something [224:49] doesn't quite work, but you try it the [224:51] second time and it works. Person gets [224:53] what they need and everything's great. [224:55] It says error details are logged but [224:57] potentially sensitive. [224:59] Now, let's look at system state [225:01] consistency. [225:02] It's inconsistent, right? Failed [225:04] authentication temps are not tracked. No [225:06] circuit breaker pattern for database [225:08] failures. And a circuit breaker pattern [225:10] is basically something that breaks [225:12] early, resets things, and it doesn't go [225:14] down a path. You know, once a certain [225:18] execution doesn't work, right? So, a [225:21] certain execution fails, [225:24] then in some cases it will just keep [225:26] going and it'll try the next thing and [225:28] the next thing and the next thing and it [225:29] just piles up errors. If you have a [225:31] circuit breaker pattern, basically [225:32] you're saying, "Hey, if this one part [225:34] fails, then stop everything. Stop the [225:37] process. [225:38] We're done until we figure that out. [225:42] Third party API. We don't have any [225:44] thirdparty API integrations. So, [225:46] skipping over that. Invalid user input [225:49] error path. So, if somebody puts in some [225:51] invalid data um here, it kind of shows [225:55] error origin points, the flow trace, and [225:58] it says there's some good stuff that [226:00] we're doing here. Email format [226:01] validation with his email, password [226:03] length validation, and email [226:05] normalization. These are all things that [226:06] we should be doing that we are doing. [226:08] However, we're not doing input [226:09] sanitization for cross- sight scripting [226:11] prevention. We're not doing any rate [226:13] limiting for validation attempts. [226:16] Detailed validation errors are exposed [226:18] to our client. And we have no input [226:20] length limits. So that's another area [226:22] where potential denial of service, [226:25] right? Somebody's sending in terabytes [226:27] of text. Authentication failure [226:30] handling. We're not doing great in this [226:31] department. User not found in database [226:34] is coming back. invalid passwords coming [226:36] back. JWT signing process. [226:39] Basically here the good stuff that we're [226:42] doing is consistent error message for [226:44] user enumeration prevention. So we're [226:47] not saying bad username if somebody puts [226:50] in the wrong username. We're using the [226:52] proper HTTP status codes and brypt [226:56] compare for password verification. [226:58] However, what we're doing wrong, we're [227:01] not using any JWT secret validation or [227:03] fallback. No algorithm specification in [227:06] JWT signing. No rate limiting for [227:09] authentication attempts. No account [227:10] lockout mechanism and JWT expiration [227:13] depends on an environment variable [227:15] without validation. So [227:18] we are not doing great in that [227:20] department. File system error handling. [227:23] How does this handle errors when dealing [227:26] with file system? Well, we don't [227:27] actually work with the file system. It [227:30] says here no file system operations [227:32] detected. [227:35] error handling anti-atterns. Remember [227:37] that list of anti-atterns? Well, here it [227:40] found some. So, it found the generic [227:42] catch all handler, which means it's [227:44] catching a whole bunch of different [227:47] stuff and just saying internal server [227:48] error. It swallows all unhandled errors [227:50] and it masks critical system issues. We [227:54] have console error logging only logging [227:57] to the console, which if you're logging [227:58] to the console, you're kind of logging [228:00] to nobody, right? because the user may [228:03] not even look at the console and we [228:04] can't read the user's console and we [228:07] can't see this stuff. So the errors just [228:08] kind of go out into a place where [228:10] someone might see them and we definitely [228:12] won't see them. We're missing a global [228:14] error handler. So that's, you know, some [228:16] type of middleware or to something [228:18] globally that can handle all of the [228:21] errors and keep track of them. We don't [228:23] have that. We have a single point of [228:24] failure because the entire application [228:26] crashes on unhandled errors. And we have [228:28] some inconsistent error formats. We have [228:31] invalidation failed with details. We [228:33] have invalid credentials. Database [228:35] connection failed. So, some of these are [228:39] a little bit inconsistent. You know, we [228:40] don't have an error code and then [228:42] details and a name, etc. like we should. [228:45] Here's our error flow diagram where we [228:47] can see we have an HTTP request that [228:49] goes into an express app off route. It [228:52] shows some of the error origin points [228:54] that we can come up with in those first [228:56] two steps. So we can come up with input [228:57] validation authentication database or [228:59] JWT. Then it goes through a [229:02] transformation layer validation details. [229:06] Does some final handling HTTP status [229:09] code error JSON response console log [229:11] which again is not a great place to put [229:15] our stuff. And then for recovery [229:17] mechanisms if any of these errors happen [229:19] we don't have retry logic circuit [229:21] breakers or graceful degradation. [229:24] So, we're just basically exploding on [229:26] the screen and expecting the user to [229:30] figure out why that happened. [229:33] So, we're missing a global error [229:35] handler, database connection without [229:36] timeout. All of these we've looked [229:38] through. These are all put into a nice [229:40] list and prioritized. Here's the [229:42] detailed remediation guide that we asked [229:44] for. And this is saying, you know, [229:46] here's the way you can fix it. It's [229:48] giving us a fix for our global error [229:50] handler. Database connection timeouts. [229:53] Those are super easy to add. Secure JWT [229:56] configuration showing us how we can [229:59] secure that. Here's how we can implement [230:01] a circuit breaker pattern. [230:04] Right? And this one, if circuit breaker [230:06] is open, [230:08] then we've got an issue here, right? So, [230:10] we have rate limiting, which is a great [230:13] thing to put on there. If somebody is [230:15] attacking you, doing an attack, we are [230:17] able to at least rate limit that and [230:19] slow them down a little bit. Structured [230:21] logging implementation. Here's a [230:23] suggestion for that. And this is just a [230:25] logger, you know, creating a logger and [230:29] sending it some data and getting that [230:32] all consistent. Building consistent log [230:34] messages is just really good practice [230:38] for a lot of things. It's not just one [230:40] of those, oh, maybe we should do it [230:41] because it's the best thing to do, but [230:42] we won't. It's definitely one of those [230:44] things you need to really focus on. [230:48] Um here for priority three, we've got [230:50] some input validation enhancements, [230:53] standardized error handling template, [230:55] and a timeline for implementation. [230:57] Right? You should probably get all this [230:59] done in 4 weeks. Here's some testing [231:02] recommendations that it throws in. And [231:03] sometimes I've noticed that cloud code [231:05] will do this. It'll throw in some [231:06] testing stuff. Here we can test database [231:09] connection timeout. We can test [231:11] connection exhaustion, malformed input. [231:15] We can test rate limiting. all of this [231:18] stuff. So basically this analysis here [231:20] says [231:22] hey this is you know exhibiting [231:24] significant error handling [231:25] vulnerabilities that pose immediate [231:27] risks to system reliability and [231:30] security. The recommended remediation [231:32] plan addresses critical gaps in error [231:34] management etc etc. Basically, it says [231:37] we've got a lot of problems with how we [231:39] handle errors and exceptions, but it [231:43] does not criticize without a solution, [231:45] right? And so, it gives us a bunch of [231:46] solutions to things that we can modify [231:49] and update. [231:51] So, next we're going to talk a little [231:52] bit about resilience and fault [231:54] tolerance. So, all of this stuff with [231:56] error handling is great. when we have [231:58] errors, we need to figure out, you know, [232:00] how can we get things cleaned up and [232:03] back on the road as quickly as possible [232:04] with our application and we're going to [232:07] do an audit of that and see how that [232:09] does. Thank you for watching. [232:12] Okay, so we've gone through some initial [232:14] project analysis, we've looked at design [232:16] patterns, we've looked at some solid [232:19] principles for putting things together, [232:21] and then we got into error handling and [232:22] resilience and exception flow analysis. [232:26] Basically, when something goes wrong, [232:27] how are we handling it? Well, there's [232:30] another part of that, and that's [232:31] resilience and fault tolerance. What [232:34] does that mean? Well, it basically means [232:36] how well does this program stand up to a [232:39] heavy load or major problems. So, that [232:43] means things like services locking up, [232:46] things becoming unavailable, [232:49] data being overwritten. These are all [232:50] problems that can happen when there's [232:53] too much of a load and you don't have [232:54] enough resilience to kind of help pick [232:57] up when things break. You know, how hard [232:58] is it trying to recover itself from a [233:01] major error? And that's what this [233:04] section is about. And that's what we are [233:06] going to cover with an audit with cloud [233:09] code. Okay, for this next audit, we're [233:11] going to look a little bit more into [233:13] some abstract things for software [233:16] quality. We're looking at a lot of [233:17] things here and we've looked at errors, [233:20] how we handle them. We've looked at some [233:22] design patterns things and maybe some [233:24] architecture considerations. This is [233:27] going to get a little bit deeper into [233:28] the actual code itself. [233:31] So, I'm going to paste this in and we'll [233:34] talk about the prompt while it's [233:36] running. And as a reminder, you can get [233:38] all of these prompts at [233:40] github.com/jeremyorggan [233:43] reviewing prompts. That way you don't [233:45] have to try to copy and paste these or [233:47] figure it out. Now let's take a look at [233:49] what we are examining with this [233:52] particular audit. We're saying analyze [233:54] code complexity across the codebase. So [233:57] this one might take a while, right? But [233:59] it says look for complex functions and [234:02] methods. Also look at functions and [234:04] methods and calculate or evaluate these [234:07] following things. cyclatic complexity, [234:09] cognitive complexity, lines of code [234:12] metrics, coupling metrics, cohesion [234:15] analysis. [234:16] Now, some of this is it's a little [234:19] subjective, right? It's kind of depends [234:20] on errors and and how you do things. So, [234:23] things like cyclomatic complexity, [234:25] those are pretty deterministic for the [234:28] most part. You can kind of look at it [234:29] and you can put some metrics to it. [234:31] Sometimes you can say, here's how much [234:33] nesting you have. Here's complexity that [234:36] you have with your switch statements [234:38] etc. Cognitive complexity is much more [234:41] subjective than cyclomatic complexity [234:43] because cognitive complexity is for [234:46] human beings like how hard is this code [234:47] to understand. Well, for some people [234:50] they might look at spaghetti code and [234:52] say this is perfect that it completely [234:55] makes sense to me. It's usually the [234:56] author, right? Uh but sometimes things [234:59] you know are a complete mystery by [235:01] people who look at them even if they [235:03] have tons of programming experience and [235:04] cognitive complexity is something you [235:06] want to reduce for the human side of [235:08] things. Cyclomatic complexity is mostly [235:10] around performance and reliability but [235:13] cognitive complexities for the human [235:15] beings. lines of code metrics. This kind [235:17] of goes back to some of the principles [235:19] that we talked about earlier that we [235:20] were auditing for. Functions over 50 [235:23] lines, that usually means that function [235:25] is doing too many things. Files over 300 [235:28] lines, that's mostly a human type of [235:32] thing where we don't want our humans to [235:33] have to look at code files that are [235:36] enormous, that are doing too much. Um, [235:39] classes over 500 lines, same thing. That [235:41] class is probably doing too much at that [235:44] point. And you can identify candidates [235:46] for splitting things up, subclassing it, [235:48] things like that. There's coupling [235:50] metrics, right? So, you know, epherent [235:53] coupling where how many dependencies are [235:56] on this model, efferent coupling, [235:58] dependencies of this model, how many is [236:01] it depending on uh instability index? [236:03] And we want to identify tightly coupled [236:05] modules. Cohesion analysis. This one is [236:09] a little bit more for a human being [236:10] also. So, are related functions grouped? [236:14] you know, are things all kind of grouped [236:15] together and and separated in ways that [236:18] make sense. That's good for humans that [236:19] are crawling through the code and [236:21] looking at it. Single responsibility [236:22] adherence. That one is a little bit [236:25] human being and it's a little bit [236:27] software design. And then module focus [236:30] clarity is kind of this very similar to [236:32] similar responsibility. you know, is a [236:34] module focus is what it's supposed to do [236:38] pretty clear and is it only doing what [236:39] it's supposed to do and nothing more, [236:42] which is generally how we want to do [236:43] this. So, we're going to go down here to [236:46] we'll do code complexity analysis audit [236:50] and let's take a look at it. [236:54] This report analyzes code complexity [236:56] metrics across the express login demo [236:58] codebase. Overall assessment, this [237:01] codebase demonstrates low to moderate [237:03] complexity, which is good with some [237:05] areas requiring attention. So we do have [237:08] some high complexity functions. We've [237:10] got a login route handler with high [237:12] cyclatic complexity. This one says main [237:15] login function has 12 decision points. [237:18] So that's one of those places where we [237:19] can see that we are putting a solid [237:23] number on this. 12 decision points. It [237:26] makes it pretty clear that's for one [237:28] function. That's not great. Multiple [237:30] conditional branches for validation, [237:32] user lookup, password verification, [237:33] complex error handling with a switch [237:35] statement. We pointed that out in an [237:37] earlier [237:39] audit as well. Nested if else structures [237:42] always something that's frustrating to [237:45] work with. Here has a code path [237:47] breakdown. [237:49] Some remediations. Here's a bunch of [237:52] remediations. Low complexity functions. [237:55] We have cyclomatic complexity of 1 to [237:57] three. So well ststructured simple [237:59] functions. These functions demonstrate [238:00] good single responsibility principle. [238:03] Cognitive complexity login handler has a [238:07] high cognitive load. Says here we've got [238:09] conditionals that are three levels deep. [238:11] We've got database queries mixed with [238:13] business logic which that's mixed [238:15] abstraction. That's always a confusing [238:17] thing. Switch statement with multiple [238:19] cases. 80 lines doing multiple [238:21] responsibilities in a function. That's [238:24] not good. So we want to break that into [238:26] smaller focused functions as shown [238:28] above. [238:30] Error handling complexity, we do have a [238:32] little complexity there. The switch [238:33] statement with four cases plus default [238:36] that in itself, some of these are [238:37] subjective, right? As a software [238:39] engineer of many years, a switch [238:41] statement with four cases plus a default [238:43] is not that bad. However, this audit is [238:47] showing issues and that one is an issue [238:49] that could become something much more [238:52] problematic later. Mix database specific [238:55] and generic error handling that I agree [238:57] is a problem. Nested inside try catch [239:00] block. Yes, nesting is always bad. [239:04] Sometimes necessary always bad. [239:07] And our remediation is to use error [239:09] handler function that I gave. Line of [239:11] code analysis. We've already seen this. [239:13] There are some huge offjs at 98 lines. [239:16] That's under 300 line threshold but it's [239:19] approaching moderate complexity. single [239:22] large function that exceeds the 50 line [239:24] threshold. It's 80 lines long. That's [239:26] too long for a function. That's how you [239:28] know that it's doing more than it should [239:30] or you're writing really verbose code. [239:31] Either way, that's not great. [239:35] Coupling metrics. So, we have some [239:38] coupling here that we need to look at. [239:40] Importantness, five out of 10, right? We [239:42] have five external modules. A reasonable [239:44] coupling level for an authentication [239:46] module, which I would agree with. Uh [239:49] there's you don't write your own for a [239:51] lot of this stuff, right? You don't [239:52] reinvent the wheel. You don't build your [239:53] own authentication. [239:55] Uh so you're going to have some coupling [239:58] to libraries [240:01] here. Good separation of concerns. We [240:03] like that. Let's see. For stable [240:05] database module, ideal stability for [240:08] infrastructure component, moderate [240:10] instability route module, acceptable [240:12] instability for business logic layer. uh [240:15] kind of goes into the cohesion analysis [240:18] here. All functions relate to database [240:20] connection management, which is great. [240:22] In authentication route, all code [240:24] relates to user authentication through [240:26] the single function. Yeah, that's [240:28] something that should be broken up and [240:29] cleaned up a little bit. Login handler [240:31] does validation, authentication, token [240:33] generation, and error handling. Yikes. [240:36] That's definitely a violation of the [240:37] single responsibility principle that we [240:40] talked about in a early module where [240:42] it's just do one thing and do it well. [240:45] Clearly, we don't have that happening [240:47] here. [240:49] Here's our refactoring recommendations. [240:51] High priority, that cyclomatic [240:53] complexity, splitting the login handler [240:56] up, reducing cognitive load by breaking [240:57] down nested conditionals, and it did [241:00] suggest some code for that, which is [241:02] great. All the way down to low priority [241:04] stuff like monitor file growth as [241:06] features are added. Uh, consider [241:08] dependency injection for better [241:09] testability, something we already know [241:12] was necessary and needed. And then [241:14] there's an implementation plan here that [241:16] gives us code step by step how we can [241:19] fix this which is great and it ends with [241:22] this summary where files pretty good [241:25] functions need improvement cyclomatic [241:27] complexity cognitive complexity any [241:29] improvement but our coupling is [241:31] acceptable and our code cohesion is [241:33] good. So we're at 6 and a half out of 10 [241:35] which actually isn't bad. You know, [241:37] lower is better, but the code base shows [241:40] architectural decisions with room for [241:42] improvement in function level complexity [241:43] management. I honestly thought this [241:45] would be a 10 out of 10. So, this is [241:47] good. But this code analysis is [241:50] something again we could take this and [241:52] put it back in the cloud and say, "Help [241:54] me fix this to get a better score for [241:56] this." Or we could send it to a human [241:58] being who can do the same thing. But [242:00] this is just one of the cool ways to use [242:03] cloud code for auditing purposes like [242:05] this. and wanted to show you that. Up [242:09] next, we're going to look at code [242:10] duplication, which is another problem [242:12] with code that uh can cause some [242:14] problems. So, I'll see you there. Okay. [242:18] Now, we've gone through a lot of audits [242:19] and a lot of them are kind of [242:21] generalized. We started generalizing. [242:22] Now, we're starting to dig down deeper [242:24] into things and and get really specific [242:27] code problems we're looking for. And [242:29] this one is no exception. We're looking [242:30] for duplicate code here. So, as we've [242:34] done before, I'm going to dump this in. [242:36] This prompt is 47 lines. And then we'll [242:38] take a look at the prompt while Cloud [242:40] Code is auditing our software. Now, this [242:43] one says, "Examine all the code in our [242:45] application. Identify and analyze code [242:47] duplication in our project and look for [242:49] similar looking functions. Check for [242:51] exact duplicates, near duplicates, [242:54] structural duplicates, data duplication, [242:57] and for each duplication found." So, [243:00] these are the four that we're looking [243:01] for. And we're looking for like [243:02] copypasted code. You know, we've all [243:04] been guilty of it before where you'll [243:07] come in and say, "Oh, well, I'll just [243:08] copy this here and I'll I'll abstract [243:10] this to a method later or I'll make a [243:13] general utilities class later. For now, [243:15] we'll just copy it through." And so [243:17] that's what we're looking for. And I [243:18] don't expect to find much here from [243:20] cloud code, but because Cloud Code [243:22] actually generated the software we're [243:24] looking at, I don't expect to find a lot [243:25] of this. But I think in a regular uh [243:29] production application written by humans [243:30] or mostly by humans I think you will [243:32] find a lot of this. So when it finds [243:36] each duplication it says we'll calculate [243:38] the duplication percentage. You know how [243:40] similar is it to these other methods. [243:43] You know sometimes the methods can just [243:44] be a tweak here and there variable [243:46] renamed and it's the same thing that [243:48] sort of thing. suggest an extraction [243:50] method, right? Whether we're going to [243:51] extract it into a function, a class or [243:53] an entire module and provide a dry [243:56] solution, which is don't repeat [243:58] yourself. Estimate the refactoring [244:00] effort. So, we want to say, you know, is [244:02] this going to be a very large [244:04] undertaking? If so, you know, maybe you [244:07] don't want to fix it right now. And then [244:09] we're going to create a utilities module [244:11] for common functions. So we're going to [244:13] take some of these functions if it finds [244:15] them put it into a common utilities [244:17] module for you and then of course build [244:20] this report. So looks like this one is [244:23] already done. Code duplication analysis. [244:25] Now remember LLMs are text processing [244:28] engines. They generate text primarily [244:32] the function of an LLM is to generate [244:34] text that it thinks is statistically [244:37] possible to be true. So on the flip side [244:40] it analyzes text very well. Also, so if [244:44] we look here, we have just a short [244:46] report here [244:48] that says uh you know overall [244:50] duplication store very low. Good. Yeah, [244:53] I didn't expect a lot of this. I expect [244:55] this out of humans more than claude. [244:58] Let's look at the audit code duplication [245:01] analysis [245:03] and let's see what it has to say. Now it [245:06] says this report analyzes code [245:08] duplication patterns in the express [245:09] login demo application. The codebase is [245:12] relatively small, right? There's four [245:14] main application files and generally [245:16] follows good DRI principles, but several [245:18] opportunities for improvement were [245:19] found. Okay, got this. So, it looked at [245:22] serverjs, ojs, database.js. Uh, those [245:26] are the files that we've been examining [245:28] through these audits all over the place. [245:30] We did find some stuff here. So, let's [245:33] look at it. Exact duplicates. No exact [245:36] duplicates were found in the application [245:37] code. This indicates good development [245:39] practices. That's great news. Uh, [245:42] sometimes exact duplicates happen. When [245:45] I was working back in the PHP world, I [245:47] worked at a place where developers were [245:49] only there 2 or 3 months each and found [245:51] it all over the place. So, it's good [245:53] that we don't have exact duplicates. I [245:56] used Grep said and to find this back in [245:59] the day. And trust me when I say this is [246:02] much easier. Near duplicates three out [246:04] of 10. Some minor issues. So, we do have [246:07] some near duplicates. similar error [246:09] response patterns. Well, that's exactly [246:11] what we want. However, we don't want it [246:13] broken into several functions, right? [246:15] So, we do want similar response error [246:18] responses. We covered that in a module [246:20] earlier, but we don't want a bunch of [246:23] functions with those similar responses [246:24] because if one of them changes, then all [246:26] of a sudden we're we're out of whack. [246:28] So, we want to combine those. And the [246:30] remediation for this, of course, is to [246:32] create a utility function called create [246:34] error response. So this part of the [246:37] audit that's coming out is actually tied [246:39] into a former audit that we did that [246:41] said, "Hey, you should take all this and [246:43] put it into a common function." So that [246:46] was when we were talk we're deep diving [246:48] on our error handling. Well, now this [246:50] particular audit is suggesting the same [246:52] thing. So it's pretty safe to say that [246:54] creating this error response function is [246:56] a good idea. Database error handling [246:58] pattern potential for reuse if more [246:59] routes are added. Yeah, this one uses a [247:02] switch case pattern, which a lot of [247:04] these tools that we've been building to [247:06] do the audience audits don't really like [247:09] switch case. You know, they don't like [247:11] switch statements. That's fine. I like [247:12] switch statements. Uh they have their [247:14] place. I'll put it that way. But in [247:17] here, it says there's a potential for [247:19] reuse if more routes are added. Here's a [247:21] way that we can fix it by making a map, [247:25] an error map. That way when you need to [247:27] add more routes, you can add in stuff to [247:30] your error map. That's a good idea. [247:32] Structural duplicates. Well, here [247:35] potential future routes. Again, this [247:37] application uses consistent express [247:38] router patterns, which is good practice. [247:41] As the application grows, consider [247:43] creating a base router class or [247:44] middleware factory. So, routes are just [247:47] like any other objects in [247:48] object-oriented programming. There are [247:50] times where you want to build a good [247:52] solid base class and extend off of it. [247:55] If you have a ton of routes, in our [247:56] case, we've only got a few, so it [247:58] doesn't really matter. And you know we [248:00] can build an application that can have [248:02] you know less than 10 routes for the [248:04] entire thing and we can build one that [248:05] has hundreds. So it's one of the things [248:08] to consider. Database connection pattern [248:10] consistent event handler pattern for [248:12] database connections. If multiple [248:14] database connections are needed extract [248:16] it to a factory function. This one is [248:18] fantastic advice mostly because as it [248:21] says if you want to do concurrent [248:22] database connections which can be tricky [248:24] of course always something to to watch [248:27] out for. You would want to do a factory [248:29] function. This creates a new connection [248:31] does this thing creates another [248:33] connection does another thing. You [248:35] definitely don't want to stack it all [248:36] into that same function. [248:39] Data duplication a little bit of that. [248:41] 25% of constants are environment [248:44] dependent. So this does not like the [248:46] fact that we're using a bunch of [248:47] environment variables for stuff. [248:50] Remediation will do it in a process [248:52] environment variable. And the effort I [248:54] forgot to mention is showing effort on a [248:56] lot of these. And some of these are [248:58] effort one hour. You know, worth an hour [249:02] almost always to fix something that's [249:05] important like this [249:07] recommended utilities module. So here's [249:09] where it's going to create this. Now if [249:12] we look here the magic number strings [249:14] thing this we're going to see this in a [249:16] lot of audits magic values that should [249:18] be constants these things this is a [249:21] 45minute effort so this is definitely [249:24] something that you would want to [249:25] consider taking a look at [249:28] creating a constants file that contains [249:32] all of your constants. So we're looking [249:34] here at the recommended utilities [249:35] module. This is what I said. Hey, [249:36] recommend something that puts all this [249:38] together and utilities so that we can [249:40] just call that method and get the same [249:42] result from the same data we put in. And [249:45] here it is. And looks pretty nice. [249:47] Create error response. We've got a [249:49] database error map which is great. This [249:51] is super extendable or we can add more [249:55] errors in here if we want to get more [249:57] granular. We have a function to handle a [249:59] database error so that we have that [250:01] consistent error handling which is [250:03] something that we touched on in the [250:05] previous audit. Here we have handle [250:08] database error. That's fantastic [250:10] validation result handler. So that will [250:13] go into the validations and this just [250:14] makes everything more consistent. Right? [250:16] We have our constants that it was [250:18] suggesting the config files all of this [250:21] stuff to say implementation priority [250:24] centralize those envir variables [250:27] create error response utilities which [250:29] that's something if we went by the old [250:30] audit we'd already done extract [250:32] constants do some mapping improvements [250:35] the code demonstrates good DY principles [250:37] overall the main improvements would [250:39] centralize configuration management and [250:40] create reusable error handling utilities [250:43] to support future growth it it didn't [250:45] take very long either but this is a very [250:47] useful tool to run because like I said, [250:49] if this were written by humans, you [250:50] would find a lot more duplication. It's [250:52] something we've all done as a junior [250:54] programmer. I definitely copied and [250:56] pasted methods and put things in places [250:58] and said, "Yeah, we'll fix this later. [251:02] It compiles. We're good to go." And so, [251:05] we want to get rid of those remnants of [251:06] bad habits in our software. And so, [251:08] that's what exactly what this audit [251:09] does. Next, we're going to take a look [251:12] at something that is mostly for the [251:15] humans. So in all of these audits that [251:18] we've been doing, most of them have been [251:21] structured around the design of the [251:23] software uh whether we're following good [251:26] principles and most of the stuff with [251:28] the exception of a few like resilience [251:30] and fault tolerance. Most of the stuff [251:31] is for humans really. We do have some of [251:35] the things like exception flow and error [251:37] handling and resilience. Those things [251:39] are for the machine. That's to make the [251:41] machine run good, make the service run [251:42] good. Everything else is pretty much for [251:44] a human and for when other humans come [251:46] in and read your code or work with your [251:48] code or in the age of AI. If an LLM is [251:51] going to read your code, we want it to [251:54] be readable, clean, and good. So the [251:57] next one that we're going to take a look [251:58] at is naming conventions and [252:00] readability. And this one is strictly [252:02] for the humans. Let's see if Claude code [252:05] can do a good job of determining what [252:08] kind of code you want to look at. So [252:10] that's naming conventions of readability [252:12] and we'll do that next. Okay, we're back [252:14] in our IDE and we're going to do another [252:16] audit that will be very helpful for the [252:20] human beings that are reading your code. [252:22] And like I said, maybe the LLMs, too. As [252:25] a reminder, uh if you're skipping around [252:27] through the videos, all of these prompts [252:29] that we're using here are available at [252:31] github.com/jeremyorggan/codcode [252:35] reviewing prompts. These will all be [252:37] available here so you don't have to try [252:38] to copy or paste or try to guess what [252:40] I'm doing. Uh you can take these prompts [252:41] and use them to review your own software [252:44] projects. [252:46] Now let's go ahead and dump in our [252:49] prompt [252:51] for and this one's pretty simple for [252:55] readability and naming. So we're going [252:56] to review naming conventions, naming [252:58] consistency, code readability, and [253:01] function signatures. And each of these [253:03] has a set of principles that we want [253:05] code to follow. Right? So naming [253:09] conventions, we want descriptive versus [253:11] cryptic variables. We want verbased [253:14] functions with clear intent. Nounbased [253:17] classes, single responsibility [253:19] principle. We've been looking at that [253:20] earlier with earlier audits. Constants, [253:23] uppercase consistency, private methods, [253:26] etc. Now underscore convention. It all [253:29] depends on the language. You might have [253:30] to tweak these a little bit. Same thing [253:32] with naming consistency. Camel case, [253:34] snake case, depends on the language [253:36] you're using. And of course, it depends [253:38] on the organization that you work for. [253:40] You can put in your own code rules in [253:42] here. And as we saw earlier, we can put [253:44] the code rules into Claude and make [253:46] Claude follow those same rules. Uh for [253:48] code readability, self-documenting code. [253:51] That one is subjective. Some folks say [253:54] there is no self-documenting code. You [253:56] need to always do code comments. Some [253:58] people say if you write good enough [253:59] code, you don't need comments. So [254:01] remember, a lot of this stuff is [254:02] subjective. Uh need for comments. If [254:05] there's too much of a need, that's a [254:06] code smell that I agree with. Magic [254:08] number strings, complex boolean [254:10] expressions, turnary operator abuse, [254:13] etc. And then function signatures. We [254:15] want the function signatures to be [254:18] pretty consistent like the parameter [254:20] count. More than three is a smell. I [254:22] agree. If you have to put in more than [254:24] three parameters, [254:26] you're probably violating single [254:27] responsibility principle as well. But [254:30] it's very complicated. Boolean [254:31] parameters, something to avoid optional [254:33] parameter handling and return type [254:35] clarity. So we already have a response [254:38] from this. So I'm going to select yes. [254:41] We're going to take a look at naming [254:44] here. Naming reability audit. [254:47] And let's see what it has to say. This [254:50] audit evaluates the codebase for naming [254:52] conventions, code readability, and [254:54] function signature quality. So the first [254:56] one, variable naming. Excellent. We got [254:58] a 9 out of 10. And this is consistent [255:02] use of descriptive camelc case variable [255:04] names. Good semantic clarity throughout [255:06] the codebase. So this is great. And it [255:08] shows an example. Here's an example of [255:10] some good practice. Here's some good [255:11] stuff that we found. All variables [255:13] follow camelc case naming consistently. [255:15] So good job cloud code who actually [255:17] wrote this because this is good stuff. [255:20] Function naming good and this is eight [255:22] out of 10 importance. We have arrow [255:24] functions with clear actionoriented [255:26] intent. We have event handlers that [255:28] follow descriptive patterns. We're doing [255:30] good. There's a minor issue here though. [255:32] Anonymous async function could benefit [255:34] from named function for debugging [255:36] purposes. [255:38] So in offjs we do have an anonymous [255:40] async function that we could probably [255:43] change, right? And that's pretty easy. [255:45] Here we have current async. We just [255:47] instead [255:49] create a actual function login handler. [255:52] Not a big deal. Something worth looking [255:55] at for debugging. And that's mostly [255:56] because if a debugger pops in a certain [255:59] area, it's not going to tell you which [256:01] function it's in unless you do that. So [256:03] that's good. Constance naming. [256:06] Excellent. We did a great job of that. [256:08] Naming consistency. Case convention. [256:11] Excellent. findings, examples. So, we're [256:13] using consistent camel case usage [256:15] everywhere. We're not mixing up snake [256:17] case or uh sentence case or anything [256:20] weird like that. Terminology usage, [256:22] excellent consistent domain terminology, [256:25] clear authentication, authorization [256:26] language, proper HTTP status code usage. [256:30] So, all of this is looking really good [256:32] for cloud code. They've investigated [256:34] themselves and found that they're doing [256:35] great in this category. Self-documenting [256:38] code is good. Variable names clearly [256:40] express intent. The function structure [256:41] is logical and readable and minimal [256:44] comments needed. So that's awesome. [256:47] Magic and numbers and strings. Here we [256:49] go. We brought this up in a previous [256:52] audit. Needs improvement. Issues found. [256:56] HTTP status codes. [256:59] Here's a remediation. You know, just [257:01] putting that into a constance file. [257:05] Not a big effort there. That's pretty [257:07] small effort for the most part. Here's [257:09] some password length requirements is [257:12] another one. [257:14] Default port and how to remediate that. [257:16] Now complex boolean expressions. [257:18] Excellent. This one simple readable [257:21] boolean logic. No turnary operator [257:23] abuse. So when turnary operators were [257:26] introduced to most people, they started [257:28] to use them everywhere, myself included. [257:30] And so turnary operator abuse is [257:32] something that's pretty common. We have [257:34] clear conditional structures here. So [257:36] that's great. We're also doing excellent [257:38] when it comes to function signatures. [257:39] Parameter count, we're not overloading [257:42] parameters with, you know, this huge [257:44] list shows there boolean parameters. [257:47] Excellent. We're not using any of that. [257:49] Return type clarity is good because [257:52] we're using a consistent JSON response [257:53] structure instead of, you know, [257:55] returning a bunch of different data [257:56] types. Clear async await usage, etc. [258:00] There is a minor issue here. We could [258:01] benefit from explicit return type [258:03] annotation on that same async function [258:05] here. little anonymous function that we [258:08] slipped in there. That one could be [258:09] better. And it created a naming [258:12] convention guide here for variables and [258:13] functions, constants, database fields, [258:16] and HTTP responses. This is all stuff [258:18] you could pipe into cloud code and have [258:20] cloud code start doing it for you. So, [258:22] primarily the biggest thing is we want [258:24] to create a constants file, add some [258:26] named functions. This is all uh not very [258:29] new. Uh HTTP status, all of this stuff [258:32] has been coming up in these audits. So [258:34] sometimes as we're doing this audit, [258:36] like I said, you'll see repeated [258:37] information, but that usually generally [258:41] means it's something valid to look at. [258:43] It's valid concern. So here's our [258:46] strengths, areas for improvement. [258:49] And this is a good quick audit that took [258:51] us, you know, 5 minutes and could [258:54] actually help the readability and help [258:58] the programmers who are working. So, you [259:00] know, he or she doesn't go crazy trying [259:03] to figure out what's going on in the [259:05] application. So, it's all human benefit [259:07] for this one. So, thank you for [259:09] watching. We've got one more to look at. [259:12] Test coverage and quality analysis. And [259:14] we're running this knowing that we don't [259:16] have tests, but I just want to want to [259:19] show how it works, what it looks for, [259:21] and things like that. So, we'll see you [259:23] there. Okay. Now, we're at our final [259:26] one, and testing because testing is [259:28] already last. We made this one last and [259:32] we actually don't have any testing going [259:34] on in this application. We haven't built [259:35] it yet. Um, and that will be a part of [259:38] this course, right? So, we're right now [259:41] we are going to do an audit to analyze [259:44] the testing just so we can see what it's [259:46] all about. And as a reminder, [259:48] github.com/jeremyorggan [259:51] claude code reviewing prompts if you [259:53] want copies of all these prompts. Now, [259:56] it's thundering. [259:58] I think it's been a different verb every [260:00] time we've done it through this course, [260:01] which is cool. So, evaluate testing [260:04] implementation for this software [260:06] project. Analyze test coverage, test [260:08] quality, test patterns, missing tests. [260:10] You know, that's where we're really [260:12] going to see it. But if this were a [260:13] larger software development project, [260:16] this is an important audit. This [260:19] arguably one of the most important, if [260:22] not the most important, because look at [260:25] what we're checking for here. We're [260:27] checking for test coverage. Do we have [260:28] unit tests? How much of our code is [260:31] covered by those unit tests? Do we have [260:33] integration tests? Those are always [260:35] tricky. Are they present? Are they [260:37] functional? End to end testing also [260:40] extremely important. Do we have any [260:42] endend tests? Uncovered critical paths. [260:45] So what does that mean? That means a [260:46] path that a user could take through the [260:48] software and get untested code. Guess [260:52] where the problem will probably arise [260:56] in that path? test quality. We want [260:58] things we want it named well. We want [261:00] the arrange act assert pattern. Uh we [261:03] want test independence meaning you know [261:05] this test shouldn't rely on another test [261:06] to get it done. We want mock usage when [261:10] it's appropriate. And we want to test [261:12] data management. Uh test pyramid [261:15] adherence unit integration and to end [261:18] testing anti patterns implementation [261:20] versus behavior [261:22] brittle test identification and test [261:24] speed issues. [261:26] So, and then it's going to look for [261:28] missing tests, [261:30] which of course is what we have now. [261:32] It's already gone through. We're going [261:34] to select yes. We're going to take a [261:36] look at this [261:38] report on our testing [261:41] or lack thereof. [261:44] And this is the first time we've done an [261:46] audit and we got a zero out of 10. So [261:50] each of these audits I asked to rate us [261:54] on a scale of 1 to 10. We are at zero. [261:58] So it says this express login demo [262:01] project currently has zero test [262:02] coverage. The application contains [262:05] critical authentication functionality [262:06] but it lacks any testing infrastructure [262:08] or test cases. So no unit tests for the [262:12] component. Here are all the files with [262:15] zero test coverage. Integration test [262:17] non-existent. [262:19] No database connection validations, no [262:21] end toend flows, no middleware, end [262:23] to-end test coverage non-existent. [262:26] Here's what we're missing. A complete [262:27] login flow, authentication token [262:29] validation, error handling, [262:31] test quality analysis, our test [262:34] infrastructure. What framework are we [262:36] using? We're using none. However, [262:38] package JSON contains a placeholder [262:40] where it says no test specified. [262:44] So, recommendations, remediations, [262:48] just [262:49] can put in there for test patterns. We [262:51] don't have any missing critical tests. [262:53] We're missing all the critical tests. [262:56] The reason I wanted to show this is [262:58] basically to show what it's going to [263:00] suggest, what it's going to do, what [263:02] we're looking for with this prompt. All [263:04] of these things here, you can start to [263:07] see some edge cases that it's suggesting [263:10] that we're missing. These are the things [263:12] that Cloud Code's going to suggest that [263:13] we put in here. Empty request body. How [263:17] do we handle that? SQL injection [263:18] attempts. How do we handle that? We have [263:20] some injectable SQL in this application. [263:22] We have found it. Uh malformed JSON [263:26] payloads, missing required fields, etc. [263:28] How are we checking for those edge [263:30] cases? Security tests, JWT secret [263:32] validation, we've got lots of issues [263:34] with that in the way that it's [263:36] implemented right now. Our token [263:37] expiration testing, tokens do not expire [263:40] in our application currently. Password [263:43] hashing verification, timing attack, [263:45] etc. And the timing attack we'll talk [263:48] about a little bit more in our security [263:52] module. But a timing attack is basically [263:54] when it sends a username and password. [263:56] If it sends a bunch of garbled up weird [263:59] usernames and it comes back in 5 [264:01] milliseconds, but then it sounds sends [264:02] in Jeremy Morgan, which might be a valid [264:04] username, and it comes back in 10 [264:07] milliseconds, then they know that they [264:09] found a valid username. [264:12] No SQL injection testing, SQL injection [264:14] testing, etc. No load testing. [264:18] Test improvement plan. Here we go. Phase [264:20] one. Start just doing just for [264:24] everything. Create a basic test [264:25] structure. Configure just core tests [264:30] that it wants us to do. Advanced testing [264:33] priority immediate action items risk [264:36] assessment etc. So what do we know about [264:39] this? We know that we don't have any [264:40] testing. And we know that's bad. What [264:42] can we do with this? We can follow this [264:44] key plan to get testing set up. In fact, [264:47] we could copy and paste this report into [264:50] Cloud and say, "Build us a test coverage [264:53] suite." That's what's so great about [264:54] Cloud Code. We're going to do something [264:57] similar to that. Um, but I wanted to [264:59] show all of these software audits to [265:01] basically show the things you're looking [265:03] for. And here's how I built them and how [265:05] you can build yours. Let's say you want [265:07] to do one on commenting. Commenting is a [265:09] little subjective. However, there are [265:11] tons of rules out there about code [265:13] comments. Pick all the rules that you [265:16] like. Pick the principles that you want [265:19] to follow. Pick the most important [265:21] things you want to look for and build [265:22] one of these prompts like we've built [265:24] here. You know, this prompt here is [265:27] basically just saying, here's a bunch of [265:29] best practices that I know about [265:31] testing, and you know, go through and [265:34] and look at these. So, here's a [265:36] step-by-step path of how you can start [265:37] your own audit. And I'll use comments as [265:40] an example. [265:41] You will come in and say, "What are the [265:44] core things we want from the comments?" [265:47] Break it down. What are the best [265:49] practices that we want our software to [265:51] follow with the comments? Break it down. [265:54] Take that and send it into Claude or [265:56] Chat GPT or any other LLM and ask, "What [265:59] am I missing?" Sometimes it will come up [266:01] with suggestions for things and you're [266:03] like, "Oh, yeah, that's great. I forgot [266:05] about that. Add that in there. Then take [266:07] it and do exactly like we've done [266:09] throughout this. Say, evaluate my [266:11] software, analyze it, build a report, [266:14] tell me what to fix, tell me how to fix [266:16] it, give me a plan, tell me what's [266:19] important, what's not important, all of [266:21] these things. And it runs in five [266:23] minutes. And you get this great thing [266:25] that it could have taken a whole group [266:26] of people to create for you. So, that's [266:28] the whole reason I'm showing this is to [266:30] not only show you the cool things that [266:32] Cloud Code's capable of, but to show you [266:35] a good structured way of how to do these [266:37] audits and how to save yourself tons of [266:39] time with boring stuff. You can take it, [266:44] put it into Cloud Code, make Claude Code [266:46] be your code review agent, and it will [266:49] go through all of these things and look [266:52] for them, and it looks for whatever you [266:53] tell it to look for, tells you a better [266:55] way to do it, and it's a great way to [266:57] refactor your software and make it [266:59] overall better. Next, we're going to [267:01] take a look at something very important [267:03] in the next module, and that's security, [267:05] keeping your application secure. Cloud [267:07] Code can help with that, too. Um, [267:09] there's a bunch of stuff to look for. [267:11] So, we have talked before about how you [267:13] don't want to vibe code your way into a [267:15] production application and put it out on [267:17] the web. We've already seen here in this [267:19] module how the software isn't that [267:22] great, but maybe it's production ready. [267:24] Maybe it can go out. In the next module, [267:26] we're going to see why you shouldn't [267:28] just take Cloud Code and have it build [267:30] an app and throw it up on AWS and expose [267:33] it to the world because there are [267:34] security concerns. [267:36] Can you take a vibe coded cloud code app [267:39] and put it up there? Absolutely. And [267:40] you're going to find out how in the next [267:42] modules where we look at security. Thank [267:45] you for watching.