Plausible is great. It provides highly actionable information front and center. The interfaces are simple. You can have multiple domains on the same account and switch between them easily. 100% recommend trying it out if you're curious.

The main thing plausible gets right is simplicity. To get going you can sign up with nothing but your email. Then to start submitting traffic from your site, there's a tiny 1kb script tag you add to the head of your index and your done. Super easy to setup and it doesn't bog your site down with massive scripts. 🎉 This would be my favorite part, if it wasn't for the fact that you can repeat that process for as many domains as you'd like. All on the same account. One login, one bill and all the domains you take care of all being in one place is fantastic. With the simple process also comes simple data. It shows you important things like bounce rate, session duration, location and page views. What it cant show you are large scale things like ad conversion, repeat users or audience reports. Which in my opinion is fine. Not everything you make needs to have corporate level support features. I don't thing that's Plausible's goal and I appreciate that a lot. However the best way to sum up the information they do give you is... "Are people interested in this site?" In a very general sense. For early idea validation, that is fantastic. I don't need to be able to generate a detailed report of every user that's landed on my page for the last 60 days, to know if people like something. 10/10 would recommend. At the end of the day, use the tool that's best suited for you. If you just need to validate an idea from a landing page, use plausible. If you're building a corporate project with ads and such, probably go with Google. Plausible is growing fast, so we'll see if that holds true in the coming years, but for now that's my take. 👍

---

Find me on [Twitter](https://twitter.com/therealdakotal) | [LinkedIn](https://www.linkedin.com/in/dakota-lewallen/) | [Twitch](https://twitch.tv/therealdakotal)

Sponsor me on [Github](https://github.com/IamFlowZ)


I've detailed my experience trying out a new analytics platform, plausible. Let me know what you think!

My First Week with Plausible

# What is this?

deno-diceware is a Command-Line utility for generating passwords based on the Diceware Standard.
# How does it work?


```
$: diceware --count 5
    output:
    output:
$: xxxxxxxxxxx (password)
```

# Where can I find it?

[deno-diceware](https://github.com/IamFlowZ/deno-diceware)
# Can I contribute?

Absolutely! Open-source is based on collaboration! Fork the repository, work to your hearts content, and submit a pull request once you think it's ready.
# Motivation

DENO! I'm super excited that there's a new server-side JavaScript runtime being released. It's pretty clearly far from production-ready, but that doesn't mean we can't start working with it.
# Closing Thoughts

So far, Deno feels like a major upgrade from Node. Top-level await + typescript out of the box feels almost magical. The other major improvement I've noticed that isn't really being mentioned is the standard library. Node obviously has a set of standard features, but unlike most server-side languages it lacks a dedicated standard library. In Deno, the stdlib is not only well defined, but really robust for where the language is in its lifecycle.

The future of JavaScript looks bright. But let's hear your thoughts? Have you built anything with Deno yet? Are you planning on giving it a go? Or are you sick and tired of seeing JavaScript reinvented every six months? Let everyone know in the comments.

---

Find me on [Twitter](https://twitter.com/therealdakotal) | [LinkedIn](https://linkedin.com/in/dakota-lewallen)

Sponsor me on [Github](https://github.com/iamflowz)


Checkout this simple password generating CLI, built with Deno.

deno-diceware. A Deno Password Generator.

KISS

Before we get too deep into the details, I'd like to detail the driving principle behind being able to deploy a website for this cheap. And that is the KISS Principal. KISS stands for "keep it simple, stupid" or "keep it stupid simple" depending on who you ask. Surprisingly, the saying draws its roots from the U.S. Navy, but is applicable to any complicated task. It's particularly applicable while developing software. The millions of ways to develop and deploy applications can be overwhelming when starting out. There's different frameworks, Server-side rendering vs Client-side rendering, different hosting platforms. The amount of options you have is seemingly endless. At the end of the day, if you take your time to honestly exam what you're goals are for a project, and find the smallest tools you can to complete those goals, it often leads to the best outcome both for the creator and for the consumer.
Project Structure

Our deployment pipeline
To kick things off, let's get the mile-high view of how the project is built. For starters, the core of my application is React. However, you can easily do this with just plain-old HTML, CSS & JS. Next, we'll go over the AWS side of things. If you're unfamiliar, Amazon Web Services is a cloud computing platform built and maintained by Amazon. It has an extremely wide-range of services, however today we're going to focus in on two. S3 or Amazon's Simple Storage Service is a data-storage service. It's a staple of AWS and where we're going to store our static files for others to access. Secondly, Cloudfront is Amazon's Content Delivery Network. The purpose of CDNs' is to maximize availability to consumers, regardless of geographic location. So even though our site will live in a specific region, we can ensure that everyone has a consistent experience while accessing our product. Continuous Integration (and it's sibling Continuous Deployment) is the act of automating the process of delivering the production version of an application. CircleCI is a product that provides integrations for deploying applications to common targets. We'll use it to wire our project to AWS.
Getting Started
Project

Let's jump in.

$: npm i -g create-react-app
$: create-react-app demo

This will create a React boiler plate project that we can use to setup our deployment process. Next let's build the project locally, to ensure we don't fail our longer process later.

$: npm run build

Once this completes successfully, let's add a repository. If you're new to Github, you can sign up here and follow this guide for how to create a repository with them. Once you've create a repository lets setup our local repo to work with the remote one we've created in Github. As well as add our first commit. If you're unfamiliar with Git or the Git CLI, I have a short tutorial series that covers the basics {% link fastflowz/git-essentials-in-five-minutes-or-less-2486 %}

$: git remote add origin https://github.com/YOUR_USERNAME/YOUR_REPO.git
$: git add .
$: git commit -m "Inital Commit"
$: git push -u origin master

AWS
S3

Now we'll need to setup our AWS architecture before we go too much further with the project itself. If you don't already have an AWS account, you can follow their guide here. Once you've done that head into the console and search for "S3".
S3 Search
In the S3 dashboard, you'll be greeted by the sight of your accounts buckets in a table. You'll see a series of buttons to the top-right. Select "Create Bucket" on the far right.
Bucket Creation Form
You'll have a form presented to you for creating an S3 Bucket. Buckets in S3 are similar to top-level directories in a file structure. How they are configured determines how the objects inside of them behave. Simply, they are a location for you to store data and configure how the data is accessed. Here you'll want to enter a name that is easy to relate to your project and uncheck the "Block all public access" button. It warns you that this is dangerous, because when you select this setting, any data you put in the bucket can be accessed by anyone. For our use-case, this is required. We're going to be hosting a website for everyone to have access to. After you've created the bucket, select it from your table and then select the "Properties" tab.
S3 Properties
In here, we need to configure the Bucket to be a web host. Select "Static Website Hosting" from the first row of buttons. In here you'll enter the index and error HTML file names. And that's it for S3!! Halfway through the architecture setup, lets now turn to Cloudfront.
CloudFront

If you go back to the AWS console, and search for "Cloudfront" instead of "S3" you'll be redirected to CloudFront. In the CloudFront dashboard, select "Create Distribution". Where you'll be greeted by two buttons. One underneath a section titled "Web" and another under "RTMP". Selected the button underneath "Web". You'll be greeted by a long form with a lot of complicated-sounding options. Lucky for us, the only thing we have to do is insert the bucket's site URL, into the "Origin Domain Name" field. After that you can leave everything as default and select "Create Distribution" at the very bottom-right of the page. Congrats!! That's all the scary stuff down. Finally let's connect the project we made earlier with the architecture that we finished setting up.
CircleCI

First, you'll need to create a CircleCI account here and link it with your github account. Then, head back into your create-react-app project and add a root level directory named, ".circleci". In it create a file titled "config.yml". Paste below, into the file, replacing BUCKET_NAME with the name of the bucket you created earlier.


version: 2.1
orbs:
  node: circleci/node@1.1.6
  aws-s3: circleci/aws-s3@1.0.11
jobs:
  build-and-test:
    executor:
      name: node/default
    working_directory: ~/repo
    steps:
      - checkout
      - node/with-cache:
          steps:
            - run: npm install
            - run: npm test
            - run: npm run build
      - aws-s3/sync:
          from: build
          to: 's3://YOUR_BUCKET'
          overwrite: true
          arguments: |
                --acl public-read \
                --cache-control "max-age=86400"
workflows:
  build-and-test:
    jobs:
      - build-and-test:
          filters:
            branches:
              only: master

One other thing to note, is the "filters" object at the very bottom. This is saying that, whenever their is a commit to the master branch, I want to build and deploy the website. Once you push this file to the remote, you should no longer commit directly to master, otherwise you'll trigger a deployment with every commit! This would not only lead to extra charges on your AWS account, but would most likely lead to a poor experience for your user. In the CircleCI Dashboard, select the "Projects" tab from the sidebar. You should see a list of all the repositories in your Github account. To the right of each repository, you'll see a "Set Up Project" button. Select the button for the repository that houses the create-react-app project. Inside, you'll be greeted by a text-editor with a sample node configuration. Above that you will see this ribbon. CircleCI Creation Ribbon
Select "Add Manually". At this point, CircleCI should be running and within a few minutes, you should have your first deployment!!
Conclusion

You now have your website hosted on AWS!! How's it feel? I know at first AWS can be super overwhelming, but like most things once you spend time in it, getting things done becomes second nature. If you would like to see how to setup a custom domain, had any issues following this guide, or have questions in general, you can comment below or reach out to me on twitter.

---

Find me on [Twitter](https://twitter.com/therealdakotal) | [LinkedIn](https://www.linkedin.com/in/dakota-lewallen/) | [Twitch](https://twitch.tv/therealdakotal)

Sponsor me on [Github](https://github.com/IamFlowZ)


See how to host a simple website with AWS for extremely cheap.

How I host my personal site for ~$1USD/Month

 Learn how to quickly build GraphQL API's with the power of Neo4J and its' Node libraries.
Free Resolvers?

Yup. You read that right. You can build a GraphQL API without having to write a bunch of CRUD boiler plate. All you need to get started is Node & Neo4J.
Setup

    Node - Server-side JavaScript Runtime
        Download
        Installation
        Note: On Windows you just need to download the installer
    Neo4J - Graph Database
        Download
        Installation

Getting Started

After you've setup the dependencies, we'll start setting up our Node project. Firstly we will need a folder to house our project. After we've made that, navigate into the folder and run,

$: npm init -y

This will create our package.json, marking this as a Node project. Now we're going to add this projects' dependencies,

$: npm install \
> express \
> apollo-server-express \
> neo4j-driver \ 
> neo4j-graphql-js

We need one more dependency to reload the app while we work.

$: npm install -D nodemon

Last thing before we get started, we should define how we're going to start our project, in the package.json file. Find the scripts section and add this line. Thanks to nodemon, our project will reload automatically any time we change any of the project files.

  "start": "nodemon -e js,graphql index.js"

Next we will create a file called schema.graphql. This will house our API definition. We'll start off simple with a "type Person" and a "type Car". People will be friends with other people, as well as driving a number of Cars.

type Person {
  name: ID!
  friends: [Person]
  drives: [Car]
}

type Car {
  name: ID!
  color: String
  drivenBy: [Person]
}

Finally, we'll create our sole application file, index.js. In here we're going to do a number of things,

    Load the application dependencies
    Generate our complete schema
    Connect to the database
    Create our server
    Start accepting connections

// 1. Load our dependencies
const fs = require("fs");
const path = require("path");
const express = require("express");
const { ApolloServer } = require("apollo-server-express");
const { makeAugmentedSchema } = require("neo4j-graphql-js");
const neo4j = require("neo4j-driver");

// 2. Generate our complete schema
const modifiedSchema = makeAugmentedSchema({
  typeDefs: fs
    .readFileSync(path.join(__dirname, "./schema.graphql"))
    .toString(),
});

// 3. Connect to the database
const driver = neo4j.driver(
  "bolt://localhost:7687",
  neo4j.auth.basic("neo4j", "letmein")
);

// 4. Create our server
const server = new ApolloServer({
  schema: modifiedSchema,
  context: { driver },
});

const app = express();
server.applyMiddleware({ app });

// 5. Start accepting connections
app.listen({ port: 4000 }, () => {
  console.log("Listening on port 4000");
});

To verify everything is working,

$: npm start

And visit localhost:4000/graphql in your browser. You should be greeted by the site of GraphQL Playground.
Graphql Playground
Being the observant developer you are, at this point you have probably opened the Schema tab, and noticed that... There's a lot more there than you originally wrote. Which is definitely true, but that is only the beginning of the magical things you can do with Neo4J. If you haven't already, you should scroll to the bottom of the schema. Where you'll be greeted by the root Query and Mutation objects, already filled out for you.
Query and Mutation Objects
At this stage of the application, you can CRUD all of the People or Cars that you want. Downside is that the relationships, just aren't there yet. Now normally, in a relational database, this is where I would show you how to make join tables. But not in Neo4J. =D In Neo4J, relationships are just as important as your core data. So naturally adding relationships to your schema is just as easy as adding data. Lets go back into schema.graphql and adjust a couple lines.

type Person {
  name: ID!
  friends: [Person] @relation(name: "FRIEND_OF", direction: "OUT")
  drives: [Car] @relation(name: "DRIVES", direction: "OUT")
}

type Car {
  name: ID!
  color: String
  drivenBy: [Person] @relation(name: "DRIVEN_BY", direction: "OUT")
}

If you reload GraphQL Playground, and revisit the Mutation object in the schema tab. You'll see an almost overwhelming number of operations you can perform. All in the name of CRUD. However, once you look at them a bit more closely, they aren't nearly as intimidating as they might seem. Now to seed our database, run "People" -> "Cars" -> "Driving" inside GraphQL Playground from the file below...

mutation People {
  Scott:CreatePerson(name:"Scott") {
    name
  }
  Jill:CreatePerson(name:"Jill") {
    name
  }
  Bob:CreatePerson(name:"Bob") {
    name
  }
  First:AddPersonFriends(from:{name:"Scott"}, to:{name:"Jill"}) {
		from {
      name
		}
    to {
      name
    }
  }
  Second:AddPersonFriends(from:{name:"Jill"}, to:{name:"Bob"}) {
    from {
      name
		}
    to {
      name
    }
  }
}

mutation Cars {
  Mustang:CreateCar(name:"Mustang", color:"Black") {
    name
  }
  Volvo:CreateCar(name:"Volvo", color:"Red") {
    name
  }
}

mutation Driving {
  One:AddPersonDrives(from:{name:"Scott"}, to:{name:"Mustang"}) {
    from {
      name
    }
    to {
      name
    }
  }
  Two:AddPersonDrives(from:{name:"Bob"}, to:{name:"Volvo"}) {
    from {
      name
    }
    to {
      name
    }
  }
  Three:AddPersonDrives(from:{name:"Jill"}, to:{name:"Mustang"}) {
    from {
      name
    }
    to {
      name
    }
  }
}

Conclusion

Now I will leave it to you, to play with the queries and discover the power of working with GraphQL and Neo4J. If you would like to see the code for this tutorial, you can view it anytime on Github. If this tutorial absolutely blew your mind, leave a heart and a comment. If you hate it and think it's the worst article ever published, my DM's are open. Either way, thanks for reading!

---

Find me on [Twitter](https://twitter.com/therealdakotal) | [LinkedIn](https://www.linkedin.com/in/dakota-lewallen/) | [Twitch](https://twitch.tv/therealdakotal)

Sponsor me on [Github](https://github.com/IamFlowZ)


Learn how to quickly build GraphQL API's with the power of Neo4J and its' Node libraries.

Generate GraphQL Resolvers From Your Schema

A lot of the work done while writing code, is reading code. So my favorite themes and extensions revolve around enhancing that side of the experience while working in VSCode. Because at the end of the day, readable code, is maintainable code.
Themes

One of my first installs whenever I'm setting up VSCode is Material Icon Theme. Personally I find it odd that by default, files get icons while folders don't. Especially with the drop-down carrot being left-aligned with the file icons. So for me, this makes it easier to pick out folders from icons while quickly glancing at the explorer.
Alt Text
This next one is technically an extension, but it provides another layer of readability that I couldn't do without. That is Bracket Pair Colorizer 2. If you write in any language that is not white-space dependent, you probably will have a lot of brackets denoting code blocks. And a lot of times, if you get the bracketing wrong, it can cause issues. So having an extension that makes it easier to pick out the pairs of brackets can help you debug when you have bracket mismatches.
Alt Text
Finally, my themes list. I'm a big dark-mode user. So I tend to go for dark backgrounds with high contrast text coloring.

    Linux Themes for VSCode

    This theme pack has a couple options. My go-to is "United Ubuntu". This is the theme featured in the cover art.

    Ayu

    Another great theme pack. My favorite out of here would have to be "Mirage"

Extensions

The extensions ecosystem in VSCode is by far one of the best reasons to make the switch if you haven't already. I just want to take a second and thank all of the extension authors out there, for taking the time to make VSCode as great as it is. To keep things simple, I'll list my extensions off, then highlight a couple of my favorites.

    AWS Toolkit
    Carbon-now-sh
    Code Spellchecker
    Cypher Query Language
    Docker
    Git Graph
    Git Lens
    GraphQL
    Prettier
    Project Manager

Code Spellchecker is one of my more recent discoveries, and probably one of my favorites. It works exactly how you would expect it to work. Highlighting spelling errors in your codebase. Having code that is comprehensible by other humans, is an integral part of writing software. Whether some people would like to admit it or not. So having a normal spellchecker alongside your syntax checker can help with that.

Git graph has become a staple of my workflow. If you've ever been a part of a project with lots of people working together . Or on a project with a lot of git-based automation, keeping track of branches and tags is important. This extension provides a great visualization, along with the ability to perform git operations from within the visualization. Checkout their repository for a great demonstration.

If, like most people, you have more than one project that you're working on at any given time. It can be tedious to navigate to and from your various projects. Project Manager makes it really easy to switch between projects with just a couple of clicks. You never have to leave your editor and you don't have to worry about having multiple instances of VSCode open.
Alt Text
Settings

Here's my settings.json
Alt Text
I tend to leave things default as much as possible, mainly for stability. The only real changes I've made are enabling formatting on paste/save and what formatter to use for different languages.
Your Turn

What extensions do you use that have changed how you work for the better? Have you authored an extension? Do you use an editor that beats VSCode?

---

Find me on [Twitter](https://twitter.com/therealdakotal) | [LinkedIn](https://www.linkedin.com/in/dakota-lewallen/) | [Twitch](https://twitch.tv/therealdakotal)

Sponsor me on [Github](https://github.com/IamFlowZ)


A rundown of how I like to configure Visual Studio Code.

My Pragmatic VSCode Setup

Recap

So far in this series we've covered the basics what a git repository is. As well as how to manage git repositories in your local environment. In this entry, we're going to look at how you can take your work, and make it available on the internet.
Vocabulary

    Remote

    A non-local location for a repository. Accessed via URL. Stored as a key-value pair, where a given name is the key and the URL is the value. Note: A local repository may have many remotes.

Commands

user:~/project$ git remote add <name> <URL>

    When ran in an existing local repository, this command adds the URL to the list of remotes. Any branches from the remote repository, will follow a naming pattern of <name>/<branch>.

user:~/project$ git clone <URL>

    Creates a new repository containing the contents of the repository located at <URL>. Automatically adds the remote to the repositories list.

user:~/project$ git fetch
user:~/project$ git fetch <name>

    Retrieves information about remote repositories. The name of a remote can be provided to retrieve its history alone.

user:~/project$ git pull
user:~/project$ git pull <name>
user:~/project$ git pull <name> <branch>

    Retrieves information from remote repositories
    Attempts to merge remote branch into local branch.
    If no remote name is provided, the default is used.
    If no branch name is provided, it will attempt to merge a remote branch with the same name as the locally active branch.
    Similar to git merge from the last entry, you can pass flags to the command to prevent automatically merging.

user:~/project$ git push
user:~/project$ git push <name>
user:~/project$ git push <name> <branch>
user:~/project$ git push <name> :
user:~/project$ git push <name> <branch>:<remote>

    Send local changes to remote repository.

    If no remote is specified, will attempt to update the remote for the current branch. You can use the --all flag to push all branches.

    Send current branch to <name>.
    Push <branch> to <name>.
    Using a colon in place of a branch name, will push all branches that exist in both the local and remote repositories.
    You can push local branches to remote branches with different names, by specifying the two, separated by a colon. Effectively merging your local branch with the remote branch, in the remote repository.

user:~/project$ git remote rename <name> <new>
user:~/project$ git remote remove <name>

    Will change the name that is associated with the remote.
    Will remove the remote from the list repositories list.

More Information

Remotes are arguably the most valuable feature of Git. They enable anyone to work on any number of projects at any given time or location. While the commands above will get you running with remotes. The real magic comes from the remote providers. They've made their hosting free and openly available to anyone with an internet connection. By doing so, they've fundamentally changed people's access to software and the information it provides. If you're not familiar already, I would strongly suggest you spend some time getting familiar with them and the people they work with.

    Github
    Create your first repo
    Connect with other contributors

---

Find me on [Twitter](https://twitter.com/therealdakotal) | [LinkedIn](https://www.linkedin.com/in/dakota-lewallen/) | [Twitch](https://twitch.tv/therealdakotal)

Sponsor me on [Github](https://github.com/IamFlowZ)


Quickly understand the difference between local and remote repositories.

Git Remotes in Five Minutes or Less

This Series

Git bit-by-bit is a tutorial series covering the Source Control Management software Git. In the last post I covered everything you need to start using Git as-soon-as-possible. Today we're going to cover how to manage multiple sets of changes.
Vocabulary

    Repository

    Location where changes are tracked.

    Commit

    A set of changes to be recorded.

    Branch

    A collection of commits.

    Tag

    A string assigned by the user to identify a commit.

    Merge

    Combine the commits of one branch, into another.

    Conflict

    A file with two sets of changes, that are not in agreement.

Commands

For this section, you should have an empty repository with a single commit on the master branch. If you don't, please follow the commands in the last entry

user:~/project/tutorial$ git branch

    Lists all of the local branches that are being tracked.

user:~/project/tutorial$ git checkout -b <branch>

    Create a new branch with the name <branch>.

user:~/project/tutorial$ git checkout <branch>

    Switch to <branch>.

user:~/project/tutorial$ git tag "v0.0.1"

    Assigns a tag of "v0.0.1" to the last commit.

user:~/project/tutorial$ git checkout tags/<tag>

    Switch to the commit that was assigned <tag>

user:~/project/tutorial$ git merge <branch> --no-commit --no-ff

    Git will prepare to join the history of <branch> with the current branch. It will not commit it right away, allowing you to compare the incoming changes.

user:~/project/tutorial$ git merge <branch>

    Git will attempt to join the changes you created in <branch>, with the state of the current branch.
    If successful, it will automatically make a new commit containing <branch>'s changes.
    If Git cannot join the changes together, it will result in a merge conflict. This can fixed, by deciding which sets of changes you would like to have committed. The current branch, or <branch>.

More Information:

This entry covered the basics of maintaining multiple sets of changes within a git repository. How to create new branches, how to switch between branches, how to leave a friendly trial behind and how to combine different sets of changes. My number one tip with this would be, to not fear merge conflicts. It can be startling and/or worrying to have to pick between two sets of changes. But if you merge often, take your time resolving them, and verify that the fixes don't break existing code. You'll master it in no time.

---

Find me on [Twitter](https://twitter.com/therealdakotal) | [LinkedIn](https://www.linkedin.com/in/dakota-lewallen/) | [Twitch](https://twitch.tv/therealdakotal)

Sponsor me on [Github](https://github.com/IamFlowZ)


Git Branches in Five Minutes or Less

What is Git?

Git is Source Control Management Software. It is a project management tool, with the goal of maintaining a digital projects history. It does this by tracking changes of the contents within a folder/directory. It also makes it easy to share projects remotely, across the internet, without having to transfer the entire project.
Vocabulary

    Repository

    Location where changes are tracked.

    Commit

    Set of changes to apply to the projects history.

    Branch

    A collection of commits.

Commands

     user:~/project/tutorial$ git init

    Creates a new Git repository in the current location. The repository will contain one branch, named "master" and no commits.
    See git-init

     user:~/project/tutorial$ git add .

    This tells Git that you would like to track the history for all files and folders within this directory.
    See git-add

     user:~/project/tutorial$ git commit -m "Initial Commit"

    This command will add all the current changes, to the repositories history.
    See git-commit

You now have a repository that contains:

    Any files within this folder.
    A "master" branch.
    A single commit with a message of "Initial Commit".

In order to add more changes, you should repeat the second and third commands any time you make changes to the contents of the folder. Note: Make sure you change the message for your commits, because that will be the quickest way to tell what you changed with the commit.

     user:~/project/tutorial$ git revert <commit>

    Undo the changes recorded within a commit. Does not erase the original commit, merely undoes the changes that were recorded.
    The commit must be done through a reference. You can find the hash(ID) for a commit by running "git log". You cannot specify a message.

More Information

This article is intended to be a quick and dirty introduction of the most basic concepts and commands to get up and running with Git. How to start a repository, how to add history, how to undo history. You can check back on this series for more in-depth guides in the future. As well as follow the links provided below for more information.

    Git Everyday for a more comprehensive guide from the maintainers.
    Git Reference the reference manual for Git.
    Github - Hello World for how to get started sharing your projects with the world.

---

Find me on [Twitter](https://twitter.com/therealdakotal) | [LinkedIn](https://www.linkedin.com/in/dakota-lewallen/) | [Twitch](https://twitch.tv/therealdakotal)

Sponsor me on [Github](https://github.com/IamFlowZ)


Git Essentials in Five Minutes or Less

Use npm ci --production. Thanks for coming to my ted talk. 🎉

Kinda kidding, but not really.

For demonstration purposes, lets define a sample package.json, omitting some of the less important stuff.

{
  "name": "test project",
  "version": 1.0.0,
  "description": "Our sample project",
  "dependencies": {
    "first-dep": "1.0.0"
  }
}

So let's say you've been hard at work on this "test project" all morning working with the "first-dep" library. Unfortunately for you, "first-dep" released a minor version the night before, going up to "1.1.0" and breaking one of the API's you use. You run your test suite locally and everything is as green as grass. You push your code and egads batman a bunch of tests are broken. You run your tests locally over and over again racking your brain for what's happening. So you push another change just to see and watch the integration environment break again. So as is common practice in Node, you delete your local dependencies, reinstall and boom. Tests are broken. Finally. Now you go to source control provider to look for what's changed and you see a single change in your package.json

-    "first-dep": "1.0.0",
+    "first-dep": "1.1.0",

The dreaded stealth patch. After some investigation, you discover that in your testing setup you run npm install. Causing the version to get modified in that environments package.json before it was changed in yours. Now you've come to a cross roads. Typically most updates your dependencies release don't directly affect your project and are fine to push through. But wait!

npm ci stops this discussion dead in its tracks. Using ci over install in your build environments defends against this versioning mismatch.

    (npm) will never write to package.json or any of the package-locks: installs are essentially frozen. source

This brings us to the first usage improvement

    Create highly reproducible builds of your dependencies

As long as you haven't specified dependency changes, there shouldn't be any in your automated environments.

What does this mean?

Typically, when you run the command npm install, you will have your dependencies installed, as well as some of your dependency versions updated if there are updates available. This can lead to some hard to find issues when running in an automated environment, similar to the one above.

    Smaller production bundles

Going back to our example package.json. Lets say we want to add typescript to our workflow. First thing you'll want to do is npm install typescript. Now our package.json looks something like,

"dependencies": {
  "first-dep": "1.0.0",
  "typescript": "^4.4.3"
}

But typescript isn't required to run our application. Typescript is a build tool. So even though we're only using it some of the time, it will be included in our node_modules every time. Irregardless of what command we use to set them up. To address this, we should pass the "-D" flag when installing packages that aren't required to run our application in production. So now our command should look like npm install -D typescript. Looking at our revised package.json, you should see something like,

"dependencies": {
  "first-dep": "1.0.0",
},
"devDependencies": {
  "typescript": "^4.4.3"
}

Awesome! But... typescript still shows up in node_modules when you run npm ci. So it's great that we've started dividing our dependencies up between production and development, but the default behavior of both install commands is to install all dependencies. So we've got one more piece to this puzzle and that is the --production flag. This instructs npm that we want to ignore all of the packages listed in devDependencies.

So in short, if you're running your application in an automated environment (shared development servers, production, testing) make sure you setup your dependencies with the command npm ci --production. And while you're working any time you install a dependency that is not directly required by your app, install it with the "-D" flag.

---

Find me on [Twitter](https://twitter.com/therealdakotal) | [LinkedIn](https://www.linkedin.com/in/dakota-lewallen/) | [Twitch](https://twitch.tv/therealdakotal)

Sponsor me on [Github](https://github.com/IamFlowZ)


Improve your Node.js application with these two simple changes.

Two Ways to Improve Your Node.js Application

A lot of grey area exists between SAM and the CDK. SAM makes it nice to verify things locally before pushing out to AWS, CDK doesn't provide anything other than seeing your initial stack. So the dev process for the cdk looks like, read docs -> write js -> deploy to CloudFormation (typically a few minutes for anything more than a s3 bucket) -> manually verify -> repeat. Not a fast process at all. Honestly if you could just take the support for local debugging from SAM and give it to the CDK it'd be near perfect.

CDK documentation is pretty confusing. Somewhat understandable given how young it is, but still. Also doesn't help that a lot of the guides that exist are also outdated. Some even coming from AWS themselves. There's also a lot modules in the CDK that are deprecated but left in place which just adds to the confusion. Obviously the docs for a deprecated api shouldn't be neccesarily removed, but maybe some information pertaining to the version that they deprecated it and a guide for migrating would be nice.

Almost feels like there should be a major version separating some of the API's. Certain modules in the package almost play with each other. As in, inside AWS the services are configurable, but inside the CDK certain things don't allow them to be put together. Again kinda goes back to the deprecation issue. There's clearly some deep internal changes that have happened in the CDK but haven't propagated out to the entire library yet, but where those lines are between old and new are about as clear as mud.

The most odd part of the CDK is the fact that everything has to be defined in class constructors. One of the limitations of class constructors is that they have to be synchronous. The JS reasoning behind constructors being synchronous is due to return types. When you define a function as async, the return type automatically becomes Promise<t>. Which breaks a whole lot of native functionality if you try to do it with a class constructor. However if you've worked with JS in the last 5 years, you'll know that writing strictly synchronous code is not something you do. Even pre async/await almost all of JS was done in callbacks which also doesn't work in CDK code. The reasoning give behind this is

    One of the tenets of CDK apps is that given the same source they will always produce the same output (same as a compiler). If you need to perform async operations, it means you are going to the network to consult with an external entity, which by definition means you lose determinism.

Which is clearly a pretty well thought out argument. But as a counter let me pose a situation I've recently encountered, and imagine would be fairly common for any fairly sized non-open source project.

~~Lets say you're deploying a project with a dependency that is a private github package, but you're building and deploying in AWS and defining those steps via the CDK. In order to install a private github package, you have to have a Personal Access Token from github in your workspace before you can install your dependencies (the first step in your build pipeline). Now the "proper" way to manage this in AWS is via a service called Secrets Manager. It's basically a key/value store with some security related bells and whistles. So now you'll call into this service via one of the SDK's that AWS provides to supply it to your environment, right? ERRRR, not if you're working with the CDK. Since all calls in the CDK have to be synchronous almost (?) the entirety of the JS SDK is off limits. Since the SDK works off either callbacks or promises and nothing else. Both of which are off limits in CDK code.~~

While finishing writing that ramble, I googled "secrets manager and codebuild" and the top link is AWS CodeBuild Adds Support for AWS Secrets Manager which documents how to integrate Secrets Manager values into your code build environments. So it makes that specific use case moot, but something of that argument still stands in that there is zero interoperability between the CDK and SDK. So with my foot firmly in my mouth I still stand by that as a gripe.

Also if there's interest in seeing a guide for setting up and deploying a serverless TS project, poke me or something.

---

Find me on [Twitter](https://twitter.com/therealdakotal) | [LinkedIn](https://www.linkedin.com/in/dakota-lewallen/) | [Twitch](https://twitch.tv/therealdakotal)

Sponsor me on [Github](https://github.com/IamFlowZ)


Some thoughts on working with the CDK and serverless architecture in AWS

Fantastic video by Alex DeBrie. Starts with very elementary explanation of dynamo as a whole and then drills down to provide some examples about modelling for one to many relationships. Found the middle to later parts super useful personally as one of the things I feel I'm lacking the most when working with dynamo are application patterns for dealing with modelling.

I've also heard this stated before from other sources but my favorite quote from the video would have to be

    "Schema-less does not mean that there is no schema enforcement. But rather that you have to enforce the schema at the application layer".

This concept is easy to miss or omit while building applications that are dynamo backed. The freedom felt by not having your storage system forcing you to define the shape of your data is liberating. But it does not come without a cost. Having seen fully schemaless applications at play. More often than not you end up with a pile of scripts moving abstract bits of data back and forth between an API and dynamo with little to no evidence of what it is that's moving. So tracking head from tail becomes an arduous task.

To that end, you'll say. "Well what do you do then?" And from my reading, it appears we end up back at Object Oriented Programming 🎉. [DynamoDb Toolbox] seems like a moderately popular library for accomplishing this in node. I've also talked with a friend who makes heavy use of it and he had no complaints. A newer player in the space is TypeDORM taking heavy inspiration from TypeORM and using DynamoDb Toolbox under the hood. Personally I've yet to use this tool but it's for sure on my short list to try out.

Whatever your runtime environment may be, more than likely you're going to need to develop your entity definitions in your code base, and then use some combination of either 3rd party libraries or aws libraries to hydrate those definitions for use via API's or other services.

Another core concept that diverges from traditional RDBMS backed systems is the storage/access to constant values. While not a requirement of those systems, it is a common to pattern to put constants within a table. So that those values can be derived via joins at the database layer instead of accessed via application code. In dynamo this is a pretty major anti-pattern as joins don't exist. You probably could hack this into a single table design by having them exists as items with like a PK of the constant group name and an SK of the constant key. But you would have to do essentially an in memory join with multiple queries. Where instead you could get the same result if you just defined a static object that holds those values and referenced them after you perform a query to get the item.

A possible footgun you could accidentally build while working with dynamo is using a common delimiter within your PK's and SK's. Context: while working with dynamo its common to concatenate data points for use within one of your items keys. e.g. a user data type might have a PK of the businessId that they belong to, and then a concatenated string for the SK of something like userId+createdAt. The footgun comes into play involving what you use to separate those values in the SK. Lets say you're using UUID's for the userId. Typically UUID's are delimited by dashes "-". If you also delimit the two values with a dash, you'll probably run into some issues at some point, as your SK will look something like "1234-1234-1234-01-12-2022T000.0". Its less of a problem in this example because you can predetermine how many of the dashes in each value. But in other cases, its possible to delimit with a symbol that could unexpectedly appear in your data, which could cause issues when you try to find a value with too many delimiters in it.

Something important to consider when designing your keys, is relative uniqueness of whatever value you assign as your PK. Since PK's 1:1 translate to partitions, there's a Goldilocks zone of having a lot of unique PK's so that your data is well dispersed, but still having enough things related to that data point so that you can work with related things. AKA you don't want 1 item per partition, but you also don't want to only have 1 partition.


---

Find me on [Twitter](https://twitter.com/therealdakotal) | [LinkedIn](https://www.linkedin.com/in/dakota-lewallen/) | [Twitch](https://twitch.tv/therealdakotal)

Sponsor me on [Github](https://github.com/IamFlowZ)


The stuff I've learned about dynamo recently.

Learning About Dynamo

I've had my PC since ~2015. I initially got it to play and compete in Counter Strike: Global Offensive and somehow it turned into an entirely different career. Of the parts listed, only the storage, the case and the power supply are original. Everything else has been replace/upgraded throughout the last couple of years.

Parts List

    Intel i9 9900 @ 3.1Ghz
    EVGA 1660ti GPU
    MSI Z390-A PRO motherboard
    16gb 3200mhz RAM
    ~5/6 TB of storage
    600w EVGA PSU
    2 120m fans in front 1 120m fan in back
    USB front of case expansion
    Bluetooth dongle
    super old corsair case idk the name of
    no RGB 🎉
    ~2016 LG 144hz 1080p monitor (main)
    2015 Acer 60hz 1080p monitor (left of main, in portrait)
    ? Phillips 60hz 780p TV used as a monitor (right of main, in portrait)

Software

    Dual booting Windows 10 & Ubuntu 21.10
    Windows is entirely default as the only reason its installed is for gaming
    Ubuntu is using Wayland and Gnome 40
    Extensions:
        blur my shell: adds nice looking blurs to various parts of the shell, giving it a mac vibe
        burn my windows: cool window closing effects, personally I use either matrix or TV (mainly TV)
        dash to dock: makes dock behave like a mac
        desktop cube: 1/2 the reason i'm on a non-lts release of ubuntu. gives super cool cube effect for transitioning between desktops
        openWeather: gives me local weather information in the top bar and a quick link to radar


---

Find me on [Twitter](https://twitter.com/therealdakotal) | [LinkedIn](https://www.linkedin.com/in/dakota-lewallen/) | [Twitch](https://twitch.tv/therealdakotal)

Sponsor me on [Github](https://github.com/IamFlowZ)


My PC Build

Very short read, but presents interesting findings and perspective. It's obvious that everyone understands the idea of making a "checklist". You write down all the things you need to do, and complete them sequentially. While this mental model applies well for simple, or one-off sets. It doesn't hold up well to the complexity of modern work. More often, the complex work of today's world is often the result of decades or centuries of study, and keeping all that information available mentally or in real-time is physically impossible for any one person. The device Gawande argues people have devised to solve this is The Checklist. However it goes much further beyond being a list of things to-do. Rather it focuses on reducing the amount of error caused by the limits of brain-power and communication. The checklist aims to focus in on mundane, easy to forget but painful to get wrong tasks within a given set of work. Removing the need to commit to memory minute detail, and instead providing head room for where human calculation is actually needed.

Gawande details two main silos for checklists. The more traditional one being READ-DO, where the each item in a checklist is read and completed sequentially. The second, and arguably more useful one is DO-CONFIRM. Rather than require sequence, DO-CONFIRM lays out sets of steps to be completed, along with a point to confirm that the set is done. For example, lets make very simple checklists for an individual getting ready in the morning and then talk about what the process for going through each list might look like.

READ-DO:

    Get out of bed
    make the bed
    Shower
    Brush teeth
    Adjust hair
    Get dressed
    Make coffee 7...

DO-CONFIRM:

    Get out of bed
    make the bed
    shower
    brush teeh
    adjust hair
    confirm first four
    get dressed
    make coffee 8...

So although the two lists look nearly identical, the process for completing the two varies widely. With READ-DO, if followed as intended, each step would be read allowed, completed and checked. So before getting out of bed, you would announce to the world "Get out of bed", you would get out of bed and check it off your list. Then so on and so forth the end of the list. In the case of DO-CONFIRM, everything prior to a given confirm step can be done asynchronously. So getting out of bed, making it, showering and so on up until the "confirmation" step, would be left up to the person in charge to complete. Ending the series at the confirmation.

Obviously in this example we're only demonstrating the fundamental differences of the two approaches. We're only doing it for a single person completing a single set of linear tasks. This problem clearly doesn't demand the specificity of either approach. Problems that do demand the specificity are typically multi-person, multi-stage tasks where stages within the tasks are dependent on prior ones and outcomes are dependent on specific sub-tasks and stages as a whole.

Last thing I want to write out, because it's absolutely crucial. Is defining high-impact, but low complexity things that need the protection of a checklist. If the things added a checklist aren't thoroughly examined to meet the specification of simple, easy to forget and high impact, then the checklist is moot. Checklists should be short, to the point and easy to complete. But most of all cover your ass.


---

Find me on [Twitter](https://twitter.com/therealdakotal) | [LinkedIn](https://www.linkedin.com/in/dakota-lewallen/) | [Twitch](https://twitch.tv/therealdakotal)

Sponsor me on [Github](https://github.com/IamFlowZ)


My thoughts on The Checklist Manifesto by Atul Gawande

Thoughts On The Checklist Manifesto

### My logging in numbers

Started on October 4 and created 147 entries to date (5/2/22).

Some rough napkin math:

30 weeks since that week

150 weekdays (30wks * 5, ignoring weekends)

147/150 is not too bad 😁

To be honest, I will say there are a non-zero number of days that have multiple entries due to a number of reasons, so take the high "completion rate" with a grain of salt.

8 Code Kata's completed in 4 weeks around December

My longest gap between logs is ~4 days in the 3rd week of March (3/18 (a Friday)- 3/24 (a Thursday)). But again being honest, March from beginning to end is the most spotty.
TL:DR;

I appreciate the practice. As someone who tends to find themselves tied up in quite a few things all at once, it serves almost like a "save game" function for my brain. Allowing me to work in starts and stops while maintaining cohesive lines of thought. It also serves as a place to keep to-do lists for all the things going on, so I can track what I have completed vs what I aimed to have completed.

A core to doing something often is making it low friction. Having it in my personal CMS so that I can access it from any device at any time is a huge contributing factor to me doing it so often. If it required an app that needed installing, syncing, maintenance of updates and/or a subscription I highly doubt I would have stuck with it. Definitely more setup overhead and more cost. But I own the source of truth for all the data I produce and I'm only at the mercy of myself in terms of structuring and maintaining it.

### Origins

Admittedly, I scroll hacker news once or twice a day. Say what you want about the front page "practices" and the people that started it, there is still a lot of good tech content that ends up on there that I enjoy reading, that otherwise would never have made it to my information horizon. So when it comes to niche information sometimes I just co-exist with people I don't necessarily agree with a lot of things about. I digress. Amongst it, I've seen a handful of mentions of the practice of maintaining a logbook from various fields. Not coming from a formal background, it was kind of an "ah-ha" moment having it described to me. I've always taken notes, but never with any formal practices. They were primarily in notebooks and the most formal part of my process was writing the date in the top left corner of the page. So safe to say that other than meetings I never really maintained any useful level of information within them. In short, the purpose of a logbook is to keep a record of experiments performed. This article(?) from Indiana University provides a pretty succinct way of starting a logbook. Similar content definitely guided my hand in terms of starting my own practice.

From reading a few things were clear:

- the data generated needed to be time-series
- the data needed to have titles
- needed to be able to embed different types of data (images, files, etc) within any given entry
- notes for meetings and working should probably be maintained with some level of separation

The first three points were derived from widely reading and shared across disciplines. The last point came from engineering-specific and software-engineering-specific articles. Mostly here where the author actively does this and considering the weight I personally place on meetings it felt non-negotiable.

### Getting Going

Most scientific implementations make a hard requirement of doing it in a physical notebook. While I do have a hoard of filled notebooks in my closet, whenever I take notes for work with a notebook, I find it harder to stick to the habit. It's another physical thing to keep track of it and the only purpose it serves is for those notes. So the mental load it creates versus relieves for me isn't as favorable as I would like. I also asked my fiance for some input on this considering they work in human services where they keep extensive written records and they actually agreed with my points and then added additional drawbacks that she experiences with her workflow that would further hinder what I was setting out to do.

An implementation detail from that article, and most others like it, that I immediately dismissed was the idea of doing it as plain text files maintained on my OS. I'm blessed enough to have multiple physical and virtual machines that I work from, so having my logs centralized on one is a non-starter. There are obviously things I could do to solve this that are more technically involved. For instance, setting up my main as an FTP server and automating copying files back and forth from my other machines. This is okay, but I dual-boot on my main machine and occasionally have to take meetings from my non-work OS (windows). So FTP'ing from one OS to the other in that instance is not simple (and probably not possible without some serious hackery). Solving that issue could be done with applications like Dropbox or Google Drive, but to do them for a long period of time I'm likely going to butt up against the limitations of those services and I lose control over my data. Canceled subscriptions, outages, getting accounts closed, etc all result in me being unable to access my data. So in short, local files aren't going to cut it. Luckily enough for me, these are the kinds of problems I like tackling.

Being an aspiring pragmatist, I started looking around for systems I already interacted with regularly and happened to fall into my CMS. I've run strapi on an EC2 instance since September of 2020 and up until starting this project exclusively used it to maintain the content on this site. Primarily my blogs, reading list and "uses" list. Tinkering with the content builder I pretty quickly sketched up a data model that felt fitting.

- Organization: An enumeration of who I was working for. (myself and my current company)
- Project: Title of the project I was working on
- Meetings: Space for detailing my meetings for the day
- Tasks: Space for detailing the work I was doing I then leveraged the Created At field to track the time-series bit and was off to the races. Doing it this way solved quite a few issues and provided some unique benefits.

Pros:

- I own my data and the only people that can change that are myself, AWS (my cloud host) and bad actors
- My data is accessible as long as I have an internet connection and my cloud infrastructure is running.
- My CMS provides a rich-text editor enabling me to write in Markdown and embed other data types (video, pictures, audio) as I see fit
- I own the data model enabling me to add, link or remove data as I see fit.
- Relative to other implementations, I don't have to maintain any automation beyond backups. I just write to my CMS as I would be anyways.
- No new physical things to remember. I use a PC every day anyways, so the barrier to access is a couple of clicks and keystrokes away.

Cons:

- I don't own the computer housing my data. Bluntly the computers doing that belong to Amazon. Granted they have "no access" to the machines I'm using unless I expressly grant it, they are still a service provider sitting between me and my data.
- I have to pay for the infrastructure I use. You could argue I would be doing this no matter the implementation in some form, but here there is a hard bill that comes at the end of the month that has to be paid one way or the other or the service provider has the right to remove my access to my data.
- Infrastructure maintenance.
    - Probably the most impactful of all the points listed so far.
    - For this, some of it is rolled up in the fact that it's being used for multiple projects so could technically count it as amortized across them, but I'm the only person maintaining all of them so it really doesn't matter. If there's misconfiguration or updates that need to be done it falls to me to do it. Granted I employ KISS as far and wide as I can and this infrastructure is no exception. So this additional workload for me comes down to maybe an hour or two every couple of months. But milage on this point will vary.
        To speculate further, if I had to say one point for why most people don't take this approach this would be it. Unless you're in IT and/or don't mind doing it as a "hobby" this approach flat out won't work. It's akin to being a car guy and not having access to a garage. You can for sure do it, but the cost will be exponentially higher and you'll have noticeably less freedom in terms of implementation details.

### In Practice

With all of that considered, this approach has worked wonders for me. My work is noticeably more cohesive. Most importantly I would say my communication is leaps and bounds more consistent. In terms of communicating work, I know what I accomplished in recent history and I know what I still have left to do to reach targets. I can relay information about my meetings to not only people not in the meeting, but to my future self really well. Of all things when I started this, I expected to make my brain more organized but the arguably largest benefit has been my communication with others. I stare into the abyss a lot less when trying to recall things I've worked on or conversations I've had. At the end of the day, it typically leads to a better result for everyone, not just myself.

### The Data Model

Since starting, the four core points of "Organization, Project, Meetings and Tasks" have remained unchanged. I will say there was a small period where I tried to add in the habit of doing code "Kata's" regularly. A Kata being like a small coding exercise to practice specific problems in coding. Really it means I attempted to do LeetCode problems regularly for a few weeks, but in the end, I found them tedious and not really adding much value. Arguably a few weeks isn't really much in terms of data size and I stopped purely based on a subjective opinion. ANYWAYS. The data within the points also stayed fairly consistent. From day to day I typically create a copy of the previous day's notes to kick things off. Typically I don't have to change the project and I never change the Organization. If I'm working on something for a different "org" I copy whatever the last instance of work for that org was. From there I update the "meetings" section. If I have none scheduled I'll write in none. Then if meetings pop up throughout the day I'll remove the "none" and add in a normal meeting entry. A typical meeting entry simply looks like
```markdown
title @ time
 ## pre
  - notes about things I want ready going into the meeting
## during
  - notes taken during the meeting
## post
  - notes taken while following up on the meeting
```
Impromptu meetings don't have "pre" entries since they're impromptu. "During" usually serves as a scratchpad for key points and things I need to follow up on. "Post" serves as the scratchpad for things I do after the meeting that would be nice to know for the next time I need to update the status about tasks or in follow-up meetings.

Tasks are organized differently. I usually divide this into sections organized by the project. So an entry in this section has a much less rigid structure.
```
# Project
- note
- note
- note
- links to documentation
- links to useful videos

Task:
- item ✅ (done)
- item ❌ (decided not to do or blocked)
- item 🔜 (in progress)

# Project 2
...
```

### The Habit

I wrote my first logbook on October 24th, 2021. As the numbers show at the top I've roughly managed to make a logbook entry every day since starting. There's definitely some dirty data contributing to that high number. But I wouldn't say it's below 80%. Having it live in my browser has made the barrier to getting into it is extremely low. I have to have my browser open to do my job so the only reason to not make a logbook is either forgetfulness or laziness. The other part I would say has reinforced the habit is the frequency with which I refer to the logbooks. By putting information that I need to relay to other people somewhere, it's become habitual to look it at when I know I wrote something about it. Essentially creating a positive feedback loop between me writing down accurate information in my logbook, enabling me to relay good information from people without having to commit it to long-term memory. So it basically replaces the mental load of having to memorize everything that I think might be important to someone else (which could be a literal person or my future self) with the action of writing it down in my logbook. Then if I ever feel flaky on the detail of something or feel like I'm forgetting an entire point. I jump into my logs. It's still a human process and I miss things, but more often than not there's something useful in there.
In Conclusion

If you don't take notes. Start. If you have taken notes and had some of the reservations I've had, try my process and hack away at it until it works for you. In my experience, the most difficult part of accomplishing anything is communication, and taking personal notes will do leaps and bounds to improving the quality of your communication.


---

Find me on [Twitter](https://twitter.com/therealdakotal) | [LinkedIn](https://www.linkedin.com/in/dakota-lewallen/) | [Github](https://github.com/IamFlowZ) | [Substack](https://dakotalewallen.substack.com)


A look back at my usage and usage patterns of my log book process

My Software Logbook Process

Managing stateful versus stateless resources in AWS

often times developers in the process of implementation skip too far ahead on the complexity spectrum. the solution for this is to provide a framework around the idea of solving the most atomic problems first.

this idea is the core of TDD. the first test(s) you write should be assertions of the most atomic piece of the new/modified requirements. these tests would fail due to the application not having the ability to fulffill them.

Solving by order of atomicity

1. tagging
2. use the cdk
3. deletion protection
4. get more performance from lambdas by using more memory not more cpu
5. don't use dynamo for graphql api's
6. do use the service clients 🔜
7. read the service faq's
8. lambda function url's
9. s3 bucket hosting
10. make arch diagrams
11. use xray
12. use `sam local generate-event` for testing lambdas 
13. mock an aws sdk api in jest
14. setup mfa for logins
15. testing cdk code hasResourceProperties 
16. testing cdk code snapshots
17. aws cli setup for multi account and mfa
18. budget alerts ✅
19. almost always enable bucket versioning
20. sns fanout

thirty, 30sec AWS tips

Billing in AWS can feel intimidating. Rightfully so given that it is a pay-as-you-use model. Trading the guarantees of a contract for agility. Because of this, there are plenty of stories of people getting a bill that far exceeds what you were expecting. So here's what you can do to avoid being another one of those stories.

In the AWS console, navigate to the billing dashboard  
![Billing dashboard link](http://cms.dakotalewallen.me:1337/uploads/Screen_Shot_2022_10_09_at_2_03_15_PM_14587c3e3a.png)

Then you will want to go to the _Budgets_ dashboard  
![Budgets dashboard link](http://cms.dakotalewallen.me:1337/uploads/Screen_Shot_2022_10_09_at_2_04_12_PM_ba0df9fa77.png)

From here you'll want to click on _Create Budget_ and fill out the form like so to get started. You'll need an email and an ideal dollar amount you would like to alert against.  
![Create Budget Button](http://cms.dakotalewallen.me:1337/uploads/Screen_Shot_2022_10_09_at_2_06_54_PM_4464bab7b2.png)
![Budget form](http://cms.dakotalewallen.me:1337/uploads/Screen_Shot_2022_10_09_at_2_08_15_PM_84bf737606.png)

After you've created your budget. Click into it and go to the upper right hand corner where you will see an _Alerts_ section. Click on _View all Alerts_. Here's where the magic happens.  
![Alerts area](http://cms.dakotalewallen.me:1337/uploads/Screen_Shot_2022_10_09_at_2_10_19_PM_b3b3b79dd3.png)

By default this will provide you with three alerts.
1.) Actual cost > 85%
2.) Actual cost > 100%
3.) Forecasted cost > 100%

You can think of cost like a bucket associated with your account. As you use services within AWS they will pour cost into the accounts bucket. 
*Actual Cost* means that your bucket has been filled up to a certain point
*Forecasted Cost* means that based on the rate of cost coming in, we expect you to incur X this month.

Both are super important. But for the case of monitoring against spend, you typically will want to alert against *Forecasted* costs not actual. That way you can use it as a predictive measure rather than a reactive one.

So the first three alerts provide you some lead in up to your point. But not much past that. To set that up you will need to click on the _Edit Alerts_ button. Once on that page scroll to the very bottom and you'll see a _Add alert threshold_ button.  
![Add threshold button](http://cms.dakotalewallen.me:1337/uploads/Screen_Shot_2022_10_09_at_2_18_14_PM_ca5a9dca04.png)

You will be greeted with an empty threshold form. You should enter a percentage greater than 100, and set the trigger to _Forecasted_. This way you will be alerted once the account spend is set to exceed a certain amount _past_ what you predicted. Finally you'll supply an email for the alert to.    
![completed threshold form](http://cms.dakotalewallen.me:1337/uploads/Screen_Shot_2022_10_09_at_2_20_26_PM_2bf40d380a.png)

You now have configured billing alerts for your account that will lead up to a set amount. As well as a relative amount past that.

---
Best of luck and hope this helps.

Find me on [Twitter](https://twitter.com/therealdakotal) | [LinkedIn](https://www.linkedin.com/in/dakota-lewallen/) | [Github](https://github.com/IamFlowZ) | [Substack](https://dakotalewallen.substack.com)

Here is a quick rundown on how to use Billing Alerts in AWS to prevent unexpectedly large bills.

How to Not Get Burnt by AWS Bills

My Pre-ReInvent goal for this year is to upgrade from the AWS Certified Cloud Practitioner to the Developer Associate.  I started working towards this way back in the spring but got caught up with work and life and it got left behind.  

However I'm picking this work back up now in hopes that I can get level up my certification prior to attending ReInvent this year in November.  

I started out doing Stephane Maarek's developer associate course. He does a fantastic job of not just covering the services and their configuration options. But also including useful advice and implementation patterns to go with it. It is fantastic and I 100% would recommend going through it regardless of if you want to get certified. Sadly personally I've only managed to get through ~65% of the course due to life 🤷‍ But have learned quite a bit from what I have completed.  
![Course Progress](http://cms.dakotalewallen.me:1337/uploads/Screen_Shot_2022_10_15_at_1_25_04_PM_5511864250.png)

Now that ReInvent is closing in (5ish weeks from writing), I'm pivoting my strategy away from coursework and into practice tests. I'm using @jonbonso's practice tests and they live up to the hype. Feels very much like the previous exam I took.  

Today's results from the 1st practice test aren't the greatest. 64%. 3 questions from passing. So not miles off the mark. I've got 4 more tests to use, but likely at min I'll do two more over the next couple of weeks just to get in the practice.  
![Practice test results](http://cms.dakotalewallen.me:1337/uploads/Screen_Shot_2022_10_15_at_1_22_15_PM_079aed31b1.png)

Next step is to review my wrong answers. Then for the next test (next weekend) the goal is to slow down. There's 130 minutes allotted and I used 50. Admittedly I spent 0 mins reviewing before submitting. So next one will take a second go round to double check and take more time with my answers

---

Best of luck and hope this helps.

Find me on [Twitter](https://twitter.com/therealdakotal) | [LinkedIn](https://www.linkedin.com/in/dakota-lewallen/) | [Github](https://github.com/IamFlowZ) | [Substack](https://dakotalewallen.substack.com)

Prepping for ReInvent: Getting my Dev Associate Cert

# Backend
This half has by far seen the most changes. Not only has it been migrated to an actual RDBMS, but now there's [strapi]() running over the top. Self-hosted on an EC2 instance, out of the box it provides everything you need to build a REST API, manage it and create content for it to serve.  I think every developer should go through the experience of building a REST API from scratch for themselves. But at the end of the day, it's not _really_ the most productive solution, given that my real goal is to share my view of the world. Not build and maintain a REST API.

For storage there's a couple layers. So the immediate data is stored in a Sqlite DB on the EC2. Then thanks to strapi's extensability, I have a cron job that pulls the file and backs it up to S3 once a week. Funny story with this, I started strapi somewhere around august of '21. Which meant at the time strapi was on V3. I also 

It's been a year or two since I discussed my setup. It's really an entirely new system from the ground-up, so I figured it was time for an update 😅

My Site Architecture (updated for 2023)

If you use the [AWS CDK](https://aws.amazon.com/cdk/) to deploy resources, you may also likely use the [Pipelines construct](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.pipelines-readme.html) to deploy. Let's say you do, and you run a `cdk diff` against your app prior to committing. It's awfully disappointing as it will only show you changes to the encasing pipeline. 
  However thanks to this [great answer](https://stackoverflow.com/questions/75099227/using-cdk-diff-to-diff-resources-wrapped-in-a-pipeline/75100254#75100254) from @fedonev on StackOverflow, I learned that there is [special syntax](https://docs.aws.amazon.com/cdk/v2/guide/cli.html#cli-stacks) within the CDK CLI that allows you to wildcard the stack you would like a command to run against. 
  > You may also use wildcards to specify IDs that match a pattern.
    ? matches any single character
    * matches any number of characters (* alone matches all stacks)
    ** matches everything in a hierarchy

So running
  ```
  cdk diff '**'
  ```
  Will diff not only diff the pipeline stack, but all the stack's within your application. 
  
![moreYouKnow.gif](http://cms.dakotalewallen.me:1337/uploads/more_You_Know_70a49aa0e7.gif)

---
Find me on [Mastodon](https://mstdn.social/@therealdakotal) | [LinkedIn](https://www.linkedin.com/in/dakota-lewallen/) | [Github](https://github.com/IamFlowZ) | [Substack](https://dakotalewallen.substack.com)

Thanks to the internet, I learned how to diff all of the resources in a CDK project.

TIL: How to CDK Diff Your Entire App

Been pretty active on SO and AWS RePost lately. One of the biggest trends I've noticed is that accepted answers are almost always snippets. And those snippets almost never cite sources. And the worst don't even explain why they are a solution. There are a few negative consequences to this. 
Firstly, it reveals something of a deep pattern (flaw?) in software development practices. In that nearly everything is treated like a 5th grade HW assignment. An epic is made (The project, paper, etc). That is broken down into problems (tickets). The developer then devises a solution (the answer). Sometimes prior to writing code. More likely while actively working with the code.
The code is then submitted for PR (or to the teacher). The grade is then determined by the WTF's/min (probably the same behavior for both the teacher and the reviewer). Well-maintained or mission-critical software will also have some kind of a testing suite, which shows at least a little bit of an evolution.  
![wtf.png](http://cms.dakotalewallen.me:1337/uploads/wtf_6c18af2bd2.png)  
All of this to say, this causes pretty glaring issues in development culture. Most often when people look for help, from forums or even their peers, they usually are set with what they believe to be the answer to their HW assignment. The only thing standing in their way is a pesky error of some kind. Which in turn, leads to the accepted answer being the one that gets the blocker sorted with the least amount of effort from them.  
![78d079.jpg](http://cms.dakotalewallen.me:1337/uploads/78d079_44e25e94dd.jpg)  
I understand there's often much more going on behind-the-scenes than just needing the answer. Sometimes there are projects, jobs, or even whole businesses that could be on the line due to a blocker in the authorship process.
But at the end of the day, that is the exception not the rule. It's intellectual laziness from both parties. The answer giver should at the very least try to point them to some reliable source of information (MDN, AWS FAQ's, library docs, etc) to backup their claim. And question askers should be thorough in their understanding of the problem AND the proposed solution. As well as hold answerers (if that's a word?) to a higher standard and expect reasoning. Not just the snippet that saves the day.

---

Find me on [Mastodon](https://mstdn.social/@therealdakotal) | [LinkedIn](https://www.linkedin.com/in/dakota-lewallen/) | [Github](https://github.com/IamFlowZ) | [Substack](https://dakotalewallen.substack.com)

A call to action for everyone who uses forums as part of their development process.

How to Improve Our Forums

A few months ago, I deployed my first private hosted zone to Route 53. Unbeknownst to me, I had set up a [split horizon DNS](https://en.wikipedia.org/wiki/Split-horizon_DNS) scenario. My public zone was routing calls to my load balancer correctly. But every time my resources deployed in the VPC called into the same domain, it would result in errors like...
`getaddrinfo ENOTFOUND _domain_...`  
I spun and thrashed and tried everything I could think of. Then after hours of debugging, while doing some "pair debugging" they made the suggestion that we duplicate the A record in the public zone into the private zone. Lo and behold problem is solved. So, if you have resources deployed to a VPC and a private zone attached to said VPC, and a public zone sharing the domain name. When your resources are all in the domain, it will use the private zone _and the private zone only_ for resolution.   
I spent some time learning and digging deeper into Route53 and DNS in general, to better understand the situation and why the solution was what it was. I found [this article](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zone-private-considerations.html#hosted-zone-private-considerations-split-view-dns) in the Route53 docs that explained almost the exact situation I was in. Considering how much I enjoy working with the [CDK](https://aws.amazon.com/cdk/), and how much I struggled with this DNS configuration. I figured what better way to improve my understanding than to build a solution, that hopefully will help others avoid the headache I went through.
### Introducing...
The `aws-cdk-split-horizon-dns` CDK construct!
```
import { SplitHorizonDns, AliasTarget } from 'aws-cdk-split-horizon-dns'

const firstTarget: AliasTarget = {
  target: ['8.8.8.8'],
  private: true,
};

const bucketWebsite = new s3.Bucket(stack, 'BucketWebsite', {
  bucketName: exampleDomain, // www.example.com
  publicReadAccess: true,
  websiteIndexDocument: 'index.html',
});

const constructTarget: AliasTarget = {
  target: new targets.BucketWebsiteTarget(bucketWebsite),
  public: true,
};

new SplitHorizonDns(scope, 'MyDNS', {
  zoneName: 'example.com',
  privateZoneVpcs: [vpc],
  targets: [constructTarget, firstTarget],
})
```
Pass it your domain name, any vpc's you want to be attached to the private zone, and a list of either resources or IPs you would like A records for, and boom. Pack it up and send it. For the resources, you can flag them as public, private, or both. And the rest is taken care of.  
This project is still early stages. So if you try it and have success. Let me know! Or if this manages to bring the whole house down, please also let me know! Future goals will depend pretty highly on what's demanded of the construct. I would imagine there will be some want for being able to specify the record type that gets created. As with this initial release it is limited to A records. Additionally, a point of configuration that will likely be added soon is the ability to set the TTL of the record.  
As of now, support for TypeScript is being tested. Python is included, but untested. If you want your stack included in the project, feel free to open an issue or PR [here in the repository](https://github.com/IamFlowZ/aws-cdk-split-horizon-dns).

--- 

Hope this helps!

Find me on [Mastodon](https://mstdn.social/@therealdakotal) | [LinkedIn](https://www.linkedin.com/in/dakota-lewallen/) | [Github](https://github.com/IamFlowZ) | [Substack](https://dakotalewallen.substack.com)


Split Horizon DNS in AWS Made Easy!

notice they happen most often when you try to pass contstructs up -> over -> down. CDK attempts to calculate a direction of dependency, but oftentimes it will end up with each end point inversely at the other. Where possible you should export a specific property of a construct, this way, it's easy for CDK to calculate a CFN export & CFN import. 


Ended up just posting to mastodon about this. As I couldn't recreate the error at will



Circular dependency issues often happen once you start scaling up with CDK projects. Here are my observations on what causes them, and how best to resolve them.

Working With Circular Dependency Errors In CDK

DNS in AWS Made Even Easier!

CDK Dependency Strategies

Three Tips for Writing CDK Tests

Multi-region Deployments with CDK

Learn how to make your architecture more flexible, by optionally reusing existing resources (Code included 😉).

To Build or to Reuse? A CDK Question

A short guide on how to migrate away from CodeCommit

How to Migrate From CodeCommit