chore: update rust aws blog

README.md

@@ -21,14 +21,14 @@ this repository and install dependencies:
 
 ## Getting Started
 
-```bash
+```shell
 pnpm install # or npm/yarn/bun install
 ```
 
 To start the dev server:
 First, run the development server:
 
-```bash
+```shell
 pnpm run dev # or npm/yarn/bun run dev
 ```
 

content/2019/net-core-dapper-and-crud-buzzword-bingo-part-2.md

@@ -30,7 +30,7 @@ Creating these clear boundaries of separation helps to create a modular applicat
 
 With that out of way, let's finally dig into the data access code we'll be writing. From the start, we said we'd be working with Dapper for our database interaction, so let's go ahead and create a new project (a `classlib` in our case). Again, I'll be using the command line, but feel free to spin up the new project in your IDE of choice:
 
-```bash
+```shell
 ~/Dappery/src$ dotnet new classlib -n Dappery.Data
 ~/Dappery/src$ dotnet sln ../Dappery.sln add Dappery.Data/Dappery.Data.csproj
 ```
@@ -47,7 +47,7 @@ With our persistence library wired up, let's go ahead and update our `.csproj` f
 
 Targeting `netstandard2.1` allows us to utilize C# 8 features, and we'll also turn on [nullable reference types](https://docs.microsoft.com/en-us/dotnet/csharp/nullable-references) to allow the compiler to help us catch possible null references. From our dependency graph above, we'll need to create a reference between our data layer and our core layer. For reasons we'll see later, we'll actually need to add just a bit of skeleton code in the core application layer for our data layer to utilize, so let's go ahead and add it now.
 
-```bash
+```shell
 ~/Dappery/src$ dotnet new classlib -n Dappery.Core
 ~/Dappery/src$ dotnet sln ../Dappery.sln add Dappery.Core/Dappery.Core.csproj
 ```

content/2019/net-core-dapper-and-crud-buzzword-bingo.md

@@ -26,21 +26,21 @@ We'll be building a simple CRUD API for our fictional brewery management softwar
 
 In this post, we'll get started with our domain layer. I should mention that we'll also be using .NET Core 3.0 with its new bells and whistles. Let's fire up a terminal (apologies, I'll be working exclusively on a Mac), and get started. If you're using Visual Studio, go ahead and initialize a new solution. In the terminal, let's start a new solution:
 
-```bash
+```shell
 ~$ mkdir Dappery && cd Dappery
 ~/Dappery$ dotnet new sln
 ```
 
 Caveat: it's totally okay to fire up your favorite IDE (I'll be using Rider) and doing all this setup through the GUI. This is just my preference for project setup. Next, let's go ahead and add some `src` and `tests` directories, and spin up our domain layer project within the `src` directory:
 
-```bash
+```shell
 ~/Dappery$ mkdir src && mkdir tests
 ~/Dappery$ cd src && dotnet new classlib -n Dappery.Domain
 ```
 
 Things to note are the fact that this is a `classlib`, which means this is a `netstandard2.0` library that we can reuse in any .NET project that leverages the standard. Now that we've got our project skeleton, let's go ahead and link it to our solution:
 
-```bash
+```shell
 ~/Dappery/src$ dotnet sln ../Dappery.sln add Dappery.Domain/Dappery.Domain.csproj
 Project `src/Dappery.Domain/Dappery.Domain.csproj` added to the solution.
 ```

content/2021/build-a-tailwind-modal-with-angular-and-ngrx.md

@@ -44,21 +44,21 @@ With our sermon out of the way, let's get into some code. At any point, you can
 
 While I'm using an Angular workspace in the example project, this all applies to existing single project workspaces as well. Let's spin up a new application using your terminal of choice:
 
-```bash
+```shell
 ng new ngrx-tailwind-modal
 ```
 
 > I'm using Angular version 11.2.5, which fortunately for us, the Angular team has included PostCSS into the build processor allowing us to natively install Tailwind without explicitly installing it's dependencies
 
 With our project in place, let's go ahead and install Tailwind (assuming you're using Angular v11.2 or greater):
 
-```bash
+```shell
 npm install --save-dev tailwindcss
 ```
 
 and if you're using yarn:
 
-```bash
+```shell
 yarn add tailwindcss
 ```
 
@@ -76,19 +76,19 @@ If you're using another CSS library, checkout the [docs](https://tailwindcss.com
 
 With Tailwind in place, let's go ahead and add NgRx to our dependencies:
 
-```bash
+```shell
 npm install @ngrx/store --save
 ```
 
 and for yarn
 
-```bash
+```shell
 yarn add @ngrx/store
 ```
 
 Optionally, you can install NgRx dev tools as well to assist with debugging, but for our simple use case, it's not necessary. With our required dependencies in place, let's go ahead and generate a new modal component. Go ahead and `cd` into your project directory and run the Angular schematic to spin up a new component:
 
-```bash
+```shell
 ng g c modal --skip-tests
 ```
 

content/2021/hitchhikers-guide-to-angular-nx-development.md

@@ -69,7 +69,7 @@ we should make it a point to keep our applications as simple as possible, offloa
 libraries and modules each with a designated purpose. What does this mean in practice? Let's look at an example architecture
 we'll emulate while developing our applications within an Nx monorepo:
 
-```bash
+```shell
 \apps
   \todos
 \libs
@@ -88,7 +88,7 @@ in some form.
 
 From an Angular code perspective, this means our todos application will look, at its core, like this:
 
-```bash
+```shell
 \todos
   \src
     \app
@@ -105,7 +105,7 @@ With our precursor to monorepos with Nx out of the way, let's jump into some cod
 
 to kick things off, let's create our Nx workspace, preset to Angular:
 
-```bash
+```shell
 npx create-nx-workspace@latest exploring-nx --preset=angular
 ```
 
@@ -126,7 +126,7 @@ of the box... pretty cool, huh?
 
 Our current workspace structure should look something like the following:
 
-```bash
+```shell
 \apps
   \todos
   \todos-e2e
@@ -166,7 +166,7 @@ domains we'll be working with.
 
 To kick things off, let's generate a couple of libraries to see what this looks like in action:
 
-```bash
+```shell
 # To generate our shared todos state management library
 nx g @nrwl/angular:library todos --directory shared/features
 
@@ -296,7 +296,7 @@ export class SharedUiPagesModule {}
 We see that our `pages` library takes on two additional dependencies in `SharedFeaturesTodosModule`, our state management library for todos, and
 `SharedUiComponentsModule`. Now for my favorite about Nx, and a little surprise for whiteboard meeting guys like myself, go ahead and run the following:
 
-```bash
+```shell
 nx dep-graph
 ```
 
@@ -340,7 +340,7 @@ We'll save a more in-depth post on NgRx for a rainy day.
 
 With our state in place, we're ready to wire everything up to our todos application and finally spit some todo items out on the screen. In the name of keeping everything simple, we'll put our component logic in a single `todos` component that we'll house within our shared `pages` library to open ourselves up for reusability later on. Using Nx, let's generate a component:
 
-```bash
+```shell
 nx g @nrwl/angular:component todos --project shared-ui-pages
 ```
 
@@ -409,7 +409,7 @@ Our `todos` page component takes on the responsibility of loading in todos once
 
 We'll add a few more components to keep things bite size and avoid component bloat:
 
-```bash
+```shell
 # Generates a wrapper component that will consume todos into a table
 nx g @nrwl/angular:component todos-list --project shared-ui-pages
 
@@ -531,7 +531,7 @@ One thing to note with our component structure here is that we're using a `@Host
 
 Now that we've cranked out all the necessary code to run our application, let's go ahead and spin it up so we can see what loading todos in action looks like. From your favorite command line, go ahead and run the following to boot up the Angular server for our todos app:
 
-```bash
+```shell
 nx serve todos
 ```
 

content/2021/implementing-tailwind-dark-mode-in-angular.md

@@ -17,7 +17,7 @@ If you're unfamiliar with Tailwind, I've [recently written](/<https://joeymckenz
 
 1. Add Tailwind as a dev package dependency with:
 
-```bash
+```shell
 npm install --save-dev tailwindcss
 ```
 
@@ -63,7 +63,7 @@ With our Tailwind setup ceremony out of the way, let's start dark mode-ifying ou
 
 To help us facilitate toggling dark mode in our application, let's add an injectable singleton service that will be responsible for enabling/disabling dark mode styles in our markup. Let's run the service schematic to generate said service:
 
-```bash
+```shell
 ng g service services/dark-mode
 ```
 
@@ -197,7 +197,7 @@ ngOnDestroy(): void {
 
 With the heavy lifting of applying/removing dark mode in our application out of the way, let's go ahead and create a simple component with just a single Tailwind-styled button. Let's run the following schematic:
 
-```bash
+```shell
 ng g component components/theme-toggle
 ```
 

content/2022/constructing-objects-with-intent.md

@@ -397,7 +397,7 @@ fn main() {
 
 Running our code gives us an output along the lines of"
 
-```bash
+```shell
 Pizza { crust: Regular, toppings: [Cheese, Pepperoni, Pepperoni], sauce: Red }
 Pizza { crust: DeepDish, toppings: [Cheese, Sausage, Mushrooms], sauce: Red }
 Pizza { crust: Thin, toppings: [BellPeppers, Onions, Custom("Anchovies")], sauce: White }... ugh, anchovies...

content/2022/jamstack-angular-apps-with-scully-and-netlify.md

@@ -57,13 +57,13 @@ With Scully generating an entirely static version of our application, it becomes
 This all sounds great, but let's jump into some code to see how we can make our Angular JAMstack dream a reality.
 Let's kick things off by creating a new Angular application with routing:
 
-```bash
+```shell
 ng new scully-netlify-angular-example --routing
 ```
 
 Scully utilizes the Angular router to crawl all of our application routes, allowing it to create individual servable HTML files by reading our router configuration. With our code scaffolding in place, let's add some simple components and a few pages:
 
-```bash
+```shell
 cd scully-netlify-angular-example
 ng g c components/home --skip-tests
 ng g c components/ping --skip-tests
@@ -104,20 +104,20 @@ export class AppRoutingModule {}
 With routes in place, let's implement a few services that will help facilitate talking to our Netlify functions
 (more on those in a bit). Let's implement two services: one for the `PingComponent` that will consume a `PingService` to _ping_ the server, and one for `DataComponent` to offload the responsibility of sending and receiving data from the server.
 
-```bash
+```shell
 ng g s services/ping --skip-tests
 ng g s services/data --skip-tests
 ```
 
 Since we'll be utilizing a bit with `Observable`s, let's implement a service to clean up our streams once a component is destroyed:
 
-```bash
+```shell
 ng g s services/unsubscribe --skip-tess
 ```
 
 While we're at it, let's make a quick service to help us with our SEO to set page titles, update `<meta>`s, etc.
 
-```bash
+```shell
 ng g s services/document --skip-tests
 ```
 
@@ -451,7 +451,7 @@ Our serverless functions will _serve_, more or less, as an API-lite for our stat
 
 To get started writing functions, let's go ahead and install the Netlify Functions package and the Netlify CLI to help us write and serve our functions:
 
-```bash
+```shell
 npm install @netlify/functions
 npm install --save-dev netlify-cli # -g if you'd like to install globally
 ```
@@ -470,7 +470,7 @@ Using the CLI, let's add an npm script in our `package.json` we can run to start
 
 If we run:
 
-```bash
+```shell
 npm run functions:serve
 ```
 
@@ -605,13 +605,13 @@ As you might have guessed, the names and pathing of our function `.ts` files _do
 
 Now that we have our first function in place, let's go ahead and start our function server:
 
-```bash
+```shell
 npm run functions:serve
 ```
 
 and in the terminal, we should see a message like the following:
 
-```bash
+```shell
 > [email protected] netlify:serve
 > netlify functions:serve
 
@@ -702,7 +702,7 @@ We've got ourselves a working solution! So far we've spun up our Angular applica
 To get started, the Scully team has made it dead simple to add static site generation to our
 Angular apps with a simple schematic. With the terminal open, let's run said schematic:
 
-```bash
+```shell
 ng add @scullyio/init
 ```
 
@@ -741,7 +741,7 @@ Tailwind projects targeting version 3 and up. With our scripts in place, let's g
 generate
 a static version of our Angular app:
 
-```bash
+```shell
 npm run scully
 ```
 
@@ -750,7 +750,7 @@ Once the Scully build completes, take a look at your `/dist` output folder. We s
 The Scully dev server will _serve_ these static HTML files with all of our Angular code functionality
 fully intact. Pretty neat, huh? Let's run the dev server:
 
-```bash
+```shell
 npm run scully:serve
 ```
 

content/2022/react-data-fetching-with-rxjs.md

@@ -112,15 +112,15 @@ intricacies of the library as we'll mainly be focusing on fetching data within t
 Okay, enough talk. Let's code! For our demo, we'll tap into the amazing [GitHub API](https://docs.github.com/en/rest)
 to explore repositories. I've spun up a simple next.js app:
 
-```bash
+```shell
 npx create-next-app@latest --ts react-rxjs-data-fetching-demo
 ```
 
 I'm using next.js in this case as we want to showcase data fetching in both the CSR and SSR contexts. Everything
 we'll do within the scope of this blog post is similarly applicable to your average react project. With our project
 scaffolded, let's add a few dependencies:
 
-```bash
+```shell
 npm install swr rxjs
 ```
 

content/2022/rethinking-exceptions-in-dotnet.md

@@ -69,7 +69,7 @@ func SomeFallibleFunction(name string) (string, error) {
 
 with output along the lines of:
 
-```bash
+```shell
 Hello, Joey!
 ```
 
@@ -97,7 +97,7 @@ fn some_fallible_function(name: &str) -> Result<&str, &str> {
 
 and running a simple `cargo run` in the command line of your choice produces the following:
 
-```bash
+```shell
 Nice to meet you, Joey!
 ```
 
@@ -204,7 +204,7 @@ async Task<Result<int, string>> DoSomeFallibleProcessingThatFails()
 
 Running our code, we see the following printed out in the console:
 
-```bash
+```shell
 Result of successfulProcessing
 Successful? - True
 Errors? - False