
## Backstory

In June 2019, the team at Microsoft shared a [roadmap](https://github.com/Microsoft/TypeScript/issues/29288) for TypeScript which included an overhaul to the way they handle linting. One of the major changes to come about was the deprecation of TSLint and the adoption of ESLint as the formal linter of choice.

This article assumes you are starting a brand new project, but if you want to migrate from TSLint over to ESLint, the VSCode team has provided a [wonderful walkthrough](https://code.visualstudio.com/api/advanced-topics/tslint-eslint-migration).

Because of these changes, the ESLint team is no longer maintaining the `typescript-eslint-parser` package and they instead [recommend using](https://eslint.org/blog/2019/01/future-typescript-eslint) `@typescript-eslint/parser`.

## Setup

In order to get started, you'll need to navigate to your projects directory and run the following sequence of commands:

**1)** `yarn init -y`

This will create a brand new `project.json` file using the recommended default configuration.

**2)** `yarn add -D typescript eslint @typescript-eslint/eslint-plugin @typescript-eslint/parser`

This installs the necessary base packages to get typescript and eslint integrated into the project.

**3)** `touch .eslintrc.js`

This creates your eslint configuration file where you can specify rules, options, settings, and much more. You'll want to add any necessary configuration options to the file as a part of this step. Make sure to also install any necessary dependencies, if you're extending a base configuration such as `airbnb`. I've provided a few example configuration files [here](https://github.com/thefrugaldev/dotfiles). These may be helpful if you're using react, react native, or node as your framework of choice, otherwise feel free to start with a blank slate. If you are using a base configuration, you'll want to make sure to install any peer dependencies as well.

**4)** Add a `lint` script to your `package.json` file that was created in step 1.

```json
"scripts": {
  "lint": "eslint --ext .ts ."
}
```

**5)** Finally, run the previous script `yarn lint` to search for any errors or warnings in your `.ts` and `.tsx` files.

Thats it! I hope this quick reference guide served useful to you as you begin to build out your next great project!

> **Quick Note**: if you're extending the `airbnb-typescript` configuration, you may run across the following error:
>
> ```bash
> Error: Error while loading rule '@typescript-eslint/dot-notation': You have used a rule which requires parserServices to be generated.
> ```
>
> If this happens, you'll first need to add a `.tsconfig` file to your project, either manually or with the following command: `npx tsc --init`. Once that's been created, you'll want to update your `.eslintrc.js` file and include `project: './tsconfig.json'` under the `parserOptions` section.


One bit of toil I always struggle with when creating a new project is getting my linter and typescript integration set up correctly. I decided this would be a perfect time to document the quick, and very easy, steps involved to doing just that.

Setting Up Typescript with ESLint in 5 Easy Steps


## Introduction

If you're like me, mobile development can seem intimidating. I was used to this world where JavaScript was the hammer that solved all problems when it came to web development. There are solutions to mobile development in the JavaScript ecosystem (like [React Native](https://reactnative.dev/)) that helped bridge that gap a bit, but I still felt this desire to really understand what was happening behind the curtain. In order to kickstart this journey into mobile development, I began in the most obvious starting place, learning [Swift](https://developer.apple.com/swift/). Swift is the official language created by Apple to develop applications for iOS, macOS, watchOS and tvOS. In this introduction to Swift, I'll explore different concepts and try explaining how they relate to their counterparts (if one exists) in JavaScript. Let's get started!

![JavaScript All The Things](all-the-things.jpeg "all the things meme")

## The Basics

**Var** - similar to the `var` and `let` keyword in JS. Used to initialize scoped variables.

**Let** - analogous to `const` in JS. Once it's declared, it cannot be mutated. Small subtlety here in that it can be initialized without an initial value, and eventually set later, but still may only be set **_once_**.

**Optionals** - If you're familiar with TypeScript, these are very similar to nullable values. You declare an optional by appending a `?` at the end of the data type declaration. It's essentially telling Swift, _"this property may or may not have a value associated with it"_. If it does not, the value is set to `nil` and no compilation errors are thrown. Any data type in Swift can be set as an optional.

- _Side note:_ In order to retrieve a value from an optional, you must **_unwrap_** it in Swift. There are two methods to unwrapping an optional, a _forced_ unwrap where Swift pulls the value out without checking for its existence (the onus is on you to check this). The other, more streamlined, approach is to store it in a temp variable if a value exists, or keep moving along if it doesn't. Both options are shown below:

```swift
// declare your optional
var optionalString: String?

// shorter, more concise approach
if let unwrappedString = optionalString {
    print(unwrappedString)
} else {
    //...no value, do something else
}

// must check for value here or app could crash
if optionalString != nil {
    // we are force unwrapping here by using the bang (!) operator
    var unwrappedString = optionalString!
    print(unwrappedString)
}
```

## Data Types

All of your typical primitive data types (`bool`, `char`, `int`, `float`, etc) are available in Swift, as well as some of your other common types found in JavaScript (`string`, `array`). There are even a few others you might not be familiar with if you're coming from a pure JavaScript background (`dictionary`, `set`, `enum`). If you're used to TypeScript, the syntax for declaring these data types may look familiar:

```swift
var myString: String
var myInt: Int
var myIntArray: [Int] // Array of Int
var students: [Int: String] // Dictionary of Int keys and String values
enum animalEnum {
    case lion
    case tiger
    case bear
}
```

With the string data type also comes string interpolation, which does exist in Swift but the syntax may look a bit different than what you're used to:

```swift
let firstName = "Foo"
let lastName = "Barr"
let age = 30

//string interpolation
print("Hello, my name is \(firstName) \(lastName), and I'm \(age) years old!")
```

## Functions

Functions are structured in a similar way to what you might be used to, with a few minor differences thrown in. Functions are declared with the `func` keyword. Any parameters must identify their data type, and any calling function must explicitly define the arguments it's passing to the function (there are times when this restriction isn't true, but for the sake of this article, I'll stick with the rule of thumb here).

```swift
func printHappyBirthdayMessage(age: Int, name: String) {
    print("Happy birthday, \(name)! I can't believe you're already \(age) years old!)
}

printHappyBirthdayMessage(age: 30, name: "Foo Bar")
```

If you are returning a value, you must specify its data type as well, using the arrow syntax (this may look familiar to arrow functions in JavaScript, except with a single dashed arrow instead of `=>`):

```swift
func calculateSqFeet(length: Int, width: Int) -> Int {
    return length * width
}
```

## Loops

There are three major types of loops in Swift, and are all pretty common in JavaScript: `while`, `repeat-while` (analogous to `do-while` in JavaScript), and `for-in` loops. The main one that you'll find yourself using is the `for-in` and its syntax is pretty much the same as JavaScript.

In Swift, there are some additional utilities you can use with loops as well, including `range` operator to increment by 1:

```swift
for number in 0...10 {
    print(number) // this will print out all numbers 0 to 10, including 10
}

for number in 0..<10 {
    print(number) // this will print out all numbers 0 to 9
}
```

Decrementing is just as easy. There are also going to be times where incrementing one by one is not sufficient. In Swift, using `strides` make both of these situations a breeze:

```swift
for number in stride(from: 0, through: 256, by: 16) {
    print(number) // this will print out all numbers 0 to 256, including 256, and increment by 16 at a time
}

for number in stride(from: 0, to: 256, by: 16) {
    print(number) // this will print out all numbers 0 to and increment by 16 at a time
}

for number in stride(from: 100, through: 0, by: -10) {
    print(number) // this will print out all numbers 100 to 0, including 0, and decrement by 10 at a time
}
```

## Structs and Classes

Structs are very similar to classes in that they group related pieces of information into one body or object. A few differences between the two are that structs cannot implement inheritance and are considered value types, whereas classes are considered reference types in Swift.

Structs also support initializers that get called anytime a new struct is instantiated, but they are **_not required_**. The difference here is that classes do require initializers (think constructors in other languages) if default values are not provided. Classes also allow for `de-initializers` that are used to cleanup after a class reference is removed from memory by the ARC (Automatic Reference Counting), otherwise known as the garbage collector in other languages. Both classes and structs can contain _protocols_ (discussed a bit later in this article) and [_subscripts_](https://docs.swift.org/swift-book/LanguageGuide/Subscripts.html) as well.

```swift
struct Book {
    // static properties
    var title: String
    var author: String
    var genre: String
    var publishYear: Int
    var currentPage: Int
    var totalPages: Int

    //computed property - also available in classes
    var remainingPages: Int {
        // excluding a setter makes it a readonly computed prop
        get {
            return totalPages - currentPage
        }
    }

    // methods
    func overview() -> String {
        return "\(title) is a \(genre) book, written by \(author) in \(publishYear)"
    }
}

var newBook = Book(title: "1984", author: "George Orwell", genre: "Fantasy", publishYear: 1949)

print(newBook.overview()) // "1984 is a Fantasy book, written by George Orwell in 1949"
```

```swift
class Animal {
    var numberOfLegs: Int
    init() {
        self.numberOfLegs = 2
    }

    final func walk() { // using the final keyword ensures this function can't be overwritten
        // ...walk function logic
    }

    deinit {
        // do any cleanup work here
    }
}

class Dog : Animal {
    override init() { // must use the override keyword here
        super.init() // have to call superclass' init method first
        super.numberOfLegs = 4 // to override a property
    }

    func bark () {
        print("woof woof")
    }
}


let myDog = Dog()
print(myDog.numberOfLegs) // prints out 4
```

## Closures

Closures in Swift are blocks of code that you intend to pass to a function or method. You can think of this as an anonymous function you might pass to another function in JavaScript. There are a few ways to write and pass closures and the following three solutions are all valid syntax for declaring closures:

```swift
struct Product {
    var id: Int
    var name: String
    var seller: String
    var price: Float
}

let product1 = Product(id: 1, name: "Book", seller: "Foo Industries", price: 12.00)
let product2 = Product(id: 2, name: "Movie", seller: "Foo Industries", price: 15.00)
let product3 = Product(id: 3, name: "Furniture", seller: "Bar Industries", price: 25.50)

let allProducts = [product1, product2, product3]

func sortByPrice(firstProduct: Product, secondProduct: Product) -> Bool {
    if firstProduct.price <= secondProduct.price {
        return true
    } else {
        return false
    }
}

// Closure examples

// 1) just pass in the defined function above
let priceSortedProducts = allProducts.sorted(by: sortByPrice)

// 2) using the "in" keyword
let nameSortedProducts = allProducts.sorted(by: {
    (firstProduct: Product, secondProduct: Product) -> Bool
    in
    if firstProduct.name <= secondProduct.name {
        return true
    } else {
        return false
    }
})

// 3) using the reserved $index Swift provides
let sellerSortedProducts = allProducts.sorted { $0.seller <= $1.seller }
sellerSortedProducts
```

As you can see in the last example, you can condense your closure down and even remove the `return` statement if it fits on one line of code.

## Extensions

A lot of times, you'll want to extend some behavior that might make it easier to reuse across your application. Swift makes it very easy to extend almost any object, struct, or class by using the `extension` keyword. For example, if I wanted to add some functionality to the native `String` type, I could add the following extension method:

```swift
extension String {
    func makeSpongebobCase() -> String {
        var newString = ""

        for (index, char) in self.enumerated() {
            let newChar = index % 2 == 0 ? char.uppercased() : char.lowercased()

            newString.append(newChar)
        }

        return newString
    }
}

let text = "Swift is a tough language!"

print(text.makeSpongebobCase()) // SwIfT Is a tOuGh lAnGuAgE!
```

![Mocking Spongebob Meme](spongebob.jpeg "mocking spongebob meme")

## Protocols

A _protocol_ in Swift is a way to formalize a class or struct's properties and behavior. The easiest way to visualize a protocol is to think of it as a manuscript or list of requirements necessary to implement some behavior or code (in other languages this could be described as an _interface_).

Implementing a protocol is simple, but there a few things to note. If you need to inherit a super class, it **_must_** be defined first. Then you can begin pulling in any necessary protocols. Unlike classes, you can adopt multiple protocols in Swift by separating each one with a comma:

`class MySubClass: MySuperClass, SomeProtocol, SecondProtocol { }`

Defining a protocol is as simple as listing any required properties and methods needed to implement said protocol:

```swift
protocol DogProtocol {
    // what methods are required?
    func bark()
    func eat()
    func drink()

    // what properties/data types are required?
    var name: String { get set }
    var breed: String { get }
    var age: Int { get set }
}
```

## Some caveats to consider

I hope all of the above helped to give a good introduction into Swift, especially if you're coming from a more web-based language like JavaScript. Outside of the foundational programming concepts, there are a few minor components to be aware of when making your way over to the Swift programming language:

- Parentheses are not required in `if` statements, but are allowed. The opening and closing brackets (`{}`) _are_ required, however.
- Semi-colons are also not required to end a line of code.
- Switch statements do not _flow through_, meaning a `break` keyword is not needed as an exit condition in a case block. Once a matching case has been found, the switch statement exits after the case block executes.
  - Multiple case conditions can be checked at once, using comma delimited values:
  ```swift
  switch (myValue) {
      // checking multiple cases
      case 1, 2, 3:
          print("case met")
      case 4:
          //do something else
  }
  ```
- If a function has the possibility of throwing an error, the `throws` keyword must be explicitly stated in the function definition, for example:
  - `func makeNetworkCall(url: String) throws -> Int`
- When calling a function that may throw an error, a `do-catch` block might be necessary (similar to a `try-catch` block in other languages).
  - For example, calling the function above might look something like:
  ```swift
  do {
      result = try makeNetworkCall("www.example.com")
  } catch {
      // ...handle error here
  }
  ```
  - If you don't care about catching the error, you can shorten the above code even more using an optional:
  ```swift
  if let result = try? makeNetworkCall("www.example.com") {
      print(result)
  }
  ```
- A good alternative to writing a bunch of `if/else` conditions in a function that has a number of optional parameters is using the `guard` clause. Any `guard` must have an `else` block that contains an exit condition if the `guard` evaluates to false:

```swift
    func myOptionalFunction(param1: String?, param2: Int?, param 3: String?) {
        guard let p1 = param1,
            let p2 = param2,
            let p3 = param3 else {
            // ...return/throw/break/continue statement
        }

        // p1, p2, and p3 all accessible here since guard clause was used
    }
```

- One final keyword to take note of is `defer`. If you find yourself needing to close a connection, or dispose of an object in multiple places, this is a crucial keyword to take advantage of. In Swift, `defer` will ensure that a block of code runs before exiting the calling block of code (whether thats through a return statement, throwing an error, etc). Defining a `defer` block is simple:

```swift
func processRequest() {
    openConnection()

    defer {
        // something that needs to happen at the end of this function,
        // regardless of what happens during the call of the function
        closeConnection()
    }
}
```


Native mobile development can seem like a steep learning curve, especially for web developers who are used to one language -- JavaScript. In this post, I'll try and clear up some concepts in Swift that make it easier for JavaScript developers to reference the language that is so crucial to iOS development.

Transitioning from JavaScript to Swift


> _Note: This post is part of the Data Structures and Algorithm series. To see more posts from this series, [click here](/series/data-structures-and-algorithms). The illustrations below are inspired by the Algorithms, Part I course on [Coursera](https://www.coursera.org/learn/algorithms-part1). All code examples from this series can be found [here](https://github.com/thefrugaldev/data-structures-and-algorithms)._

A [**_disjoint-set_**](https://en.wikipedia.org/wiki/Disjoint-set_data_structure) (also referred to as a _union-find_ data structure) is a data structure that tracks a set of elements partitioned into a group of disjoint subsets (also known as [_connected components_](<https://en.wikipedia.org/wiki/Component_(graph_theory)>)). Given this type of data structure, there are multiple algorithms that can be used to solve the two major equations for a disjoint-set, the **_Union_** command and the **_Find_** query, which we'll go into more detail below.

![Connected Components](connected-components-illustration.svg "Connected components illustration")

## **Dynamic Connectivity**

- A dynamic connectivity structure maintains information about the connected components of a graph.
- Given a set of _N_ objects:
  - Connect two objects (the **_Union_** command)
  - Determine if there is a path connecting the two objects (the **_Find_** query)

### Union-Find Illustration

![Union-Find](union-find-illustration.svg "Union find illustration")

## **Quick Find**

- Quick Find is an [_Eager_ algorithm](https://en.wikipedia.org/wiki/Eager_evaluation) also used to solve the _dynamic connectivity_ problem.
- The **_Find_** query for this algorithm is very efficient and is measured in [constant time](https://en.wikipedia.org/wiki/Time_complexity#Constant_time).
  - Given id[] of size _N_, check if _p_ and _q_ are connected.
- The **_Union_** command is measured in quadratic time because the time to resolve is dependent on the size of the array and the number of values that must change as a result.
  - When changing a value of `id[q]`, you must also change all entries whose value is equal (connected) to `id[q]` as well.

### Quick Find Illustration

![Quick-Find Illustration](quick-find-illustration.svg "Quick find illustration")

### Quick Find Implementation

```typescript
import DisjointSet from "./DisjointSet";

class QuickFind implements DisjointSet {
  disjointSet: number[];

  constructor(quantity: number) {
    this.disjointSet = [];

    for (let i = 0; i < quantity; i++) this.disjointSet[i] = i;
  }

  connected = (p: number, q: number): boolean => {
    return this.disjointSet[p] === q;
  };

  union = (p: number, q: number): void => {
    const pid = this.disjointSet[p];
    const qid = this.disjointSet[q];

    this.disjointSet.forEach((value, index) => {
      if (value === pid) {
        this.disjointSet[index] = qid;
      }
    });
  };
}

export default QuickFind;
```

## **Quick Union**

- Quick Union is a [_Lazy_ algorithm](https://en.wikipedia.org/wiki/Lazy_evaluation) that, again, is used to solve the _dynamic connectivity_ problem.
- Data structures implementing this algorithm are represented as [trees](<https://en.wikipedia.org/wiki/Tree_(graph_theory)>) in order to find the connected root of each element.
- The **_Find_** query requires a traversal up the tree:
  - Given id[] of size _N_, check if _p_ and _q_ have the same _root_.
- The **_Union_** command requires the _find_ query in order to determine each element's root before merging.
  - This command is measured in [linear time](https://en.wikipedia.org/wiki/Time_complexity#Linear_time) because in order to merge the _connected components_ containing _p_ and _q_, we must set the id of _p_'s root to the id of _q_'s root.

### Quick Union Illustration

![Quick-Union Illustration](quick-union-illustration.svg "Quick union illustration")

### Quick Union Implementation

```typescript
import DisjointSet from "./DisjointSet";

class QuickUnion implements DisjointSet {
  disjointSet: number[];

  constructor(quantity: number) {
    this.disjointSet = [];

    for (let i = 0; i < quantity; i++) this.disjointSet[i] = i;
  }

  private root(valueToCheck: number): number {
    while (this.disjointSet[valueToCheck] !== valueToCheck) {
      valueToCheck = this.disjointSet[valueToCheck];
    }

    return valueToCheck;
  }

  private isDirectChild(p: number, q: number): boolean {
    return this.disjointSet[p] === q;
  }

  connected(p: number, q: number): boolean {
    if (this.isDirectChild(p, q)) return true;

    return this.root(p) === this.root(q);
  }

  union(p: number, q: number): void {
    const rootP = this.root(p);
    const rootQ = this.root(q);

    this.disjointSet[rootP] = rootQ;
  }
}

export default QuickUnion;
```

## Improvements to Quick Union

## Weighted Quick Union

- We can improve Quick Union by _"weighting"_ our algorithm. What this means is that anytime a **_Union_** operation is performed, we will always link the root of the smaller tree to the root of the larger tree.
  - This helps to keep the overall tree structure relatively flat, compared to a normal quick-union tree (as pictured below), and ensures each node is never too far from the overall root node.
  - The **_Find_** query takes the time proportional to the depth of _p_ and _q_.
    - Because we are always setting the root of the smaller tree to that of the larger tree, the depth of any node is **_at most_** _log N_ (where N is the number of nodes in the overall tree).

![Weighted Quick-Union Tree Comparison](weighted-quick-union-tree-comparison.svg "Weighted quick union tree comparison")

### Weighted Quick Union Illustration

![Weighted Quick-Union Illustration](weighted-quick-union-illustration.svg "Weighted quick union illustration")

### Weighted Quick Union Implementation

For the weighted quick union implementation, you can see below that our **_Find_** query remains the same. For the **_Union_** operation, however, we are incrementing the size of the larger root by the size of the smaller root.

```typescript
import DisjointSet from "./DisjointSet";

class WeightedQuickUnion implements DisjointSet {
  disjointSet: number[];
  size: number[];

  constructor(quantity: number) {
    this.disjointSet = [];
    this.size = [];

    for (let i = 0; i < quantity; i++) {
      this.disjointSet[i] = i;
      this.size[i] = 1;
    }
  }

  private root(valueToCheck: number): number {
    while (this.disjointSet[valueToCheck] !== valueToCheck) {
      valueToCheck = this.disjointSet[valueToCheck];
    }

    return valueToCheck;
  }

  private isDirectChild(p: number, q: number): boolean {
    return this.disjointSet[p] === this.disjointSet[q];
  }

  connected(p: number, q: number): boolean {
    if (this.isDirectChild(p, q)) return true;

    return this.root(p) === this.root(q);
  }

  union(p: number, q: number): void {
    const rootP = this.root(p);
    const rootQ = this.root(q);

    if (rootP === rootQ) return;

    if (this.size[rootP] <= this.size[rootQ]) {
      this.disjointSet[rootP] = rootQ;
      this.size[rootQ] += this.size[rootP];
    } else {
      this.disjointSet[rootQ] = rootP;
      this.size[rootP] += this.size[rootQ];
    }
  }
}

export default WeightedQuickUnion;
```

## Weighted Quick Union with Path Compression

- This algorithm can be improved even further by compressing the path to the overall root.
  - So, after computing the root of _p_, for any node that was passed over (6, 3, 1 in the following illustration), we'll set it to point to the new root as well.
  - This causes our overall tree to flatten even further, decreasing the time complexity to _almost_ linear.

### Weighted Quick Union with Path Compression Illustration

![Weighted Quick-Union with Path Compression Illustration](weighted-quick-union-path-compression-illustration.svg "Weighted quick union with path compression illustration")

### Weighted QU with Path Compression Implementation

For this implementation, we're going to update our `root` method so that for each traversal to an object's root, we'll set the value of every other node in the path to point to its grandparent, thereby halving the length to the object's root.

```typescript
private root(valueToCheck: number): number {
  while (this.disjointSet[valueToCheck] !== valueToCheck) {
    this.disjointSet[valueToCheck] = this.disjointSet[
      this.disjointSet[valueToCheck]
    ];
    valueToCheck = this.disjointSet[valueToCheck];
  }

  return valueToCheck;
}
```


A disjoint-set, or union-find as it's also commonly referred, is a data structure that tracks a set of elements partitioned into a group of discontinuous subsets. In this post, I'll highlight a few algorithms that may come in handy when dealing with these types of data structures.

Disjoint-Set/Union-Find Data Structure

User authentication is a key pillar in most modern applications today. Setting it up, however, can sometimes be a bit tricky. In this post, I'll walk you through how to set up authentication with Google's Firebase using React with Redux.

Integrating Firebase with React-Redux


I recently began playing around with Docker in my spare time. I've heard a lot about the benefits of containerizing applications but, being an avid practitioner of [pain driven development](https://www.weeklydevtips.com/episodes/010), I haven't found the need to implement it in any of my applications thus far. Curiosity got the better of me, however, and I decided to list out a quick reference guide for common commands used within the Docker CLI. A [complete list of these commands](https://docs.docker.com/engine/reference/commandline/cli/) are readily available on Docker's documentation site, but feel free to follow along in your terminal after [downloading Docker Desktop](https://hub.docker.com/?overlay=onboarding).

## Getting Started

The easiest way to get started from the command line, and typically one of the first commands I run when starting out with a new CLI, is the **_help_** command. The `docker help` command will give you a list of commands that are available within the Docker CLI.

## Images

In Docker, an _image_ is a set of instructions or commands used to create a _container_ (more on containers later). Images are immutable in nature, so once an image is built, it must either be re-created or deleted using a new set of instructions. The instructions that Docker images are built from are known as [Dockerfiles](https://docs.docker.com/engine/reference/builder/).

In order to build an image, a [simple command](https://docs.docker.com/engine/reference/commandline/build/) can be run from your terminal:

```bash
docker build -f {DOCKER_FILE_NAME} -t {IMAGE_TAG} .
```

`docker build` is executed with a couple of arguments to build a Docker _image_. The first argument specifies which Dockerfile to reference in order to build the image, and the second argument specifies the tag, or alias, of the image that you are building. So, the above command could look something like this:

```bash
docker build -f node.dockerfile -t thefrugaldev/node .
```

Once you've got a few images created, you can list them out using the [following command](https://docs.docker.com/engine/reference/commandline/images/):

```bash
docker images
```

This will list out all top level images, including their properties such as tags, the date they were created, size, and their image id. The output in your terminal should look something like this, after execution.

![Docker Images Command](docker-images.png "docker images cli command")

If you find that you have too many images or decide you don't need a specific image anymore, you can always remove an image by providing the image id as an argument to the [following command](https://docs.docker.com/engine/reference/commandline/rmi/).

```bash
docker rmi {IMAGE ID}
```

## Containers

Containers are probably what brought you to Docker in the first place. The word gets thrown around a lot when mentioning Docker, but what is a container? From a high level, a container is similar to an image, but its state can change and is built at runtime. Containers, unlike images, have a writable persistence layer, that can be added to or modified. When a container is deleted, so too is this persistence layer. So, in this sense, multiple containers can share a single image, and still have an isolated persistence layer.

To [run a container](https://docs.docker.com/engine/reference/commandline/run), simply specify which image you want to run. The terminal will then return the container id of the newly created container.

```bash
docker run -d thefrugaldev/node
```

There are quite a few [options](https://docs.docker.com/engine/reference/commandline/run/#options) that you can pass to the previous command:

```bash
docker run -d --net {NETWORK} --name {CONTAINER_ALIAS} -p {LOCAL_PORT:HOST_PORT} {IMAGE_TO_RUN}
```

By specifying `-d` you are telling Docker to run in detach, or background, mode. In Docker, you can set up an isolated network with the `--net` argument, and containers within that network can communicate with one another. The `--name` allows you to assign a name to the container, making it easier to maintain after it's up and running. The `-p` flag allows you to bind an external port on your local machine to an internal port on the host machine that is running the container. Finally, you can provide the image you'd like to run. An example of this command might look something like this.

```bash
docker run -d --net isolated_network --name my_funky_new_container -p 8080:5000 thefrugaldev/aspnetcore
```

Sometimes, you may need to [execute an external command](https://docs.docker.com/engine/reference/commandline/exec/) once an application is up and running. For this, Docker allows the `exec` command to be run within the context of a specific container.

```bash
docker exec {CONTAINER_NAME} {CMD}
```

Once you've got a few containers up and running, feel free to run any of the following commands to [visualize](https://docs.docker.com/engine/reference/commandline/ps/) and [remove](https://docs.docker.com/engine/reference/commandline/rm/) any containers running on your machine.

```bash
docker ps # list any running containers
docker ps -a # list all containers (running or otherwise)
docker rm {CONTAINER_ID} # remove a specific container by id
docker rm -f $(docker ps -a -q)
```

That final command is an interesting one. It's forcing docker to remove containers with the `-f` flag. The last part of that command `$()` tells Docker to evaluate an expression inside the parentheses. Here, we're telling Docker to find all containers (running or otherwise) in quiet (`-q`) mode (only display numeric IDs) and return what was found. The entirety of the command essentially tells Docker to remove all containers (running or otherwise).

## Volumes

For larger write operations, containers can have _volumes_ associated with them as well. You can think of volumes like a symlink that points to a virtual directory that is managed by Docker. When you stop, or even remove, a container, the volume remains in-tact unless you explicitly remove it. This allows volumes to be safely shared by multiple containers.

In order to remove a container, along with any associated volumes, you'll want to [use the following command](https://docs.docker.com/engine/reference/commandline/rm/) (which you've seen before) with the specified `-v` option.

```bash
docker rm -v {CONTAINER_ID}
```

If you happen to remove a container and forget to remove its associated volumes (which never happens to me :wink:), there is a [quick and easy command](https://docs.docker.com/engine/reference/commandline/volume_prune/) to remove any unused volumes that may be stuck out in purgatory.

```bash
docker volume prune
```

## Docker Compose

Once you get comfortable with Docker, you may find creating multiple containers from individual images can become tedious and is not very scalable. If that's the case, take a look at [Docker Compose](https://docs.docker.com/compose/). According to their docs, compose is a _"tool for defining and running multi-container Docker applications"_. To take advantage of _docker-compose_, you'll need to create a [yaml](https://yaml.org/) file that informs Docker of instructions necessary to create containers, including the docker file to use, networks to create, ports to use, etc.

I wont go into too much detail around the [docker-compose cli](https://docs.docker.com/compose/reference/overview/), but I've provided a list of common commands that I think will be beneficial on your journey.

```bash
docker-compose build
# build the images specified in the docker-compose.yml file
docker-compose up -d
# builds, (re)creates, starts, and attaches to containers for a service
# the -d flag tells docker-compose to run in detach mode
docker-compose down --rmi all --volumes
# stops and removes containers
# also removes any networks, volumes and images created by the up command
docker-compose logs
# displays log outputs.
# very useful if you run the up command in detach mode
docker-compose ps
# list all currently running containers
docker-compose start
# starts existing containers
docker-compose stop
# stop running containers without removing them
docker-compose rm -v
# removes any stopped containers
# the -v flag also removes any attached volumes
```

## Extensions

I hope the above commands can serve as a reference point for others as I'm sure it will for me when I inevitably forget them. As a side note, I wanted to end this post by suggesting a very helpful extension for Visual Studio Code. If you haven't already, I suggest downloading the [Docker extension](https://marketplace.visualstudio.com/items?itemName=ms-azuretools.vscode-docker) provided by Microsoft. This extension gives you a GUI to really help visualize what containers, volumes, images, and registries are currently enabled on your local machine.


Working with containers has been a hot topic for a few years now. But sometimes it can feel intimidating as you're getting started. This post helps alleviate some of those concerns and hopes to serve as a reference guide to a few of the crucial commands that Docker offers.

Essential Docker Commands


There are quite a few ways to resolve conflicts in git, whether it's through the command-line or a GUI. In this post, I'm going to offer an opinionated solution using the command-line and, more specifically, using a tool called vimdiff (because I'm most familiar with the Vim interface).

## Set up Git config with your tool of choice

The first thing you'll want to do is configure git to use the [mergetool](https://git-scm.com/docs/git-mergetool) you're most comfortable with. There are a number of options to choose from, including emerge, gvimdiff, kdiff3, meld, vimdiff, and tortoisemerge. For a complete list of tools and settings, simply run `git mergetool --tool-help` in your terminal. In this post, I'm going to use vimdiff. Now, I could do this by running `git -t vimdiff`, which would configure it as my tool for this session only. However, I want git to always default to this tool for any future conflicts.

So, the first few commands that we'll run are:

```bash
git config merge.tool vimdiff
git config merge.conflictstyle diff3
git config mergetool.prompt false
```

The first command specifies which tool is used by the git-mergetool. The second command specifies the formatting of conflicts in your terminal. Setting "diff3" in this instance adds the original text to the conflict display, but leaving it as default and omitting the second command is fine as well. Finally, the last command just ensures that the user is prompted before the merge resolution is executed.

## Starting the merge tool

Executing the `git mergetool` command will run the mergetool and you can begin resolving conflicts.

Your terminal should now display an interface similar to the format in the image below.
![Git Conflict GUI](git-conflict-gui.png "git conflict gui in vimdiff")

As you can see, there are four sections in this UI. The **_local_** section is the file from the current local branch. The **_base_** is the common ancestor between the local and remote commits. This is essentially what the file looked like before either commit was changed. The **_remote_** file is the one you are merging into your branch. Lastly, the **_merged_** file at the bottom is the result of the conflict resolution and what will be saved in your repository after you execute the resolution.

You can navigate between the four areas of the terminal using `Ctrl W` to move between windows, or `Ctrl W` + `J` to move directly to the **_merged_** window. For other navigational commands, [visit the vim docs](http://vimdoc.sourceforge.net/htmldoc/windows.html#window-moving).

## Edit the files

Once you've navigated to the window that you want to edit, press the `i` key to insert text in Vim. After you're finished making the changes you'd like, press the `esc` key to exit **_insert mode_** and enter **_command mode_**, and you should see those changes reflected in your **_merged_** section. If not, simply type `:diffupdate` and hit enter and the UI should update to show your merged copy.

If this seems tedious and you would rather take a complete copy of either the **_local_**, **_base_**, or **_remote_** files, you can run the following commands. `:diffg RE` gets the entire changes from the **_remote_** copy, `:diffg BA` from the **_base_** copy, and `:diffg LO` from **_local_**.

## Save your changes

After you're satisfied with the changes you made, and the merged copy reflects what you were after, it's time to save and commit the changes.

Enter **_command mode_** by pressing `esc`, and type `:wqa`. This command will write, save, and quite all files within Vim. You are now ready to commit your changes using the well-known `git commit -m "My Commit Message"` command. Vimdiff will create a few files for you during the resolution, most ending in a `*.orig` suffix, but to get rid of these files simply run `git clean`.

## All finished

That should do it. Assuming you had no other conflicts, you should now be ready to push your changes. If there are more, feel free to use the same process we just went over to resolve any outstanding conflicts. I originally decided to write this article as a reference guide for myself, but I hope I've helped a few other frustrated devs stuck in conflict purgatory along the way :wink:.


Resolving conflicts in git can be intimidating, and even more so if you plan on using a cli tool. In this post, I try and resolve (pun intended) some of those concerns.

Resolving Conflicts in Git


[Redis](https://redis.io/) is an open-source, in-memory data store. Although there are many use cases, including acting as a message broker, Redis is commonly used as a caching mechanism. I've recently been looking into utilizing this caching service at work. With that in mind, I figured I would write up a quick post about some of the more common data types supported in Redis, and when you might expect to use them.

> _Note: All examples below are utilizing the `redis-cli` but feel free to follow along using the [playground](https://try.redis.io/)._

## **Keys**

If you are already somewhat familiar with caching, you'll understand that most values are retrieved using a _key_ to lookup said value. In typical caching systems, this key is represented by a primitive string. In Redis, however, keys are binary safe, which means that you can use something as simple as "thefrugaldev" as your key, or something as complex as the content of a JPEG file. With that being said, it is [recommended on their docs](https://redis.io/topics/data-types-intro#redis-keys) to stick with a schema (ex: "object-type:id") rather than really condensed or complex keys, as this can have an impact on lookup performance. Keys can also be assigned for a [limited (expiry) time](https://redis.io/commands/expire) as seen in the example below.

### **Example**

```bash
> set key some-value
OK

# Expire key after 5 seconds
> expire key 5
(integer) 1

# Get TTL for key
> ttl key
(integer) 5

# Get key after TTL has expired
> get key
(nil)
```

## **Strings**

Strings are the most basic kind of Redis data type and have a max value of 512 MB. Strings, similar to keys in Redis, are binary safe, meaning they can contain any type of data including JPEG images, serialized objects, etc.

### **When to use strings**

Strings are useful when you need to encode a lot of data in a little amount space. This may include caching HTML fragments or pages. Because Redis does not have a dedicated integer type, strings can also be used to represent a base-10, 64-bit signed integer. Built-in Redis commands including [INCR](https://redis.io/commands/incr) (increment) or [DECR](https://redis.io/commands/decr) (decrement) can then be used to adjust these integer values.

### **Example**

```bash
> set thefrugaldev awesome
OK

> get thefrugaldev
"awesome"
```

## **Lists**

If you are familiar with Linked List data types, you are already on your way to understanding Lists in Redis. Lists in Redis are essentially Linked Lists of [string values](#Strings), sorted by insertion order. A List in Redis offers a very generous max length of 2<sup>32</sup> - 1 elements (more than 4 billion elements). Similar to a Linked List, when elements are added to a Redis List they can be inserted at the head (beginning) or tail (end) of the list very quickly since it's an O(N) operation. However, these operations can become super slow if you're accessing anything near the middle of a very large list.

### **When to use lists**

A very common use case for Redis Lists is the social network example. [Twitter uses Redis Lists](https://www.infoq.com/presentations/Real-Time-Delivery-Twitter/) to display the latest tweets in a real-time approach. Redis also recommends using lists for communication between processes, where one (the producer) pushes elements onto the list and then the other (consumer) pulls the items off the list and takes some action.

### **Example**

```bash
# Create a new list
# todolist: "cut the grass"
> lpush todolist "cut the grass"
(integer) 1

# Add a new item to the list
# todolist: "cut the grass", "make the bed"
> rpush todolist "make the bed"
(integer) 2

# Add an item to the beginning of the list
# todolist: "pay the electricity bill!", "cut the grass", "make the bed"
> lpush todolist "pay electricity bill!"
(integer) 3

# Remove an item from the list
# todolist: "pay the electricity bill!", "cut the grass"
> rpop todolist
"make the bed"
```

## **Sets**

Redis Sets are an _unordered_ collection of strings. Because there is no guarantee on the order in which a set is returned to the user, operations are always _O_(1), or constant time, regardless of the number of elements within the set. Sets in Redis will never allow repeated members, so adding the same element multiple times will still result in the set only containing one copy of the element. This means that adding an element does not require an initial check to see if it already exists within the set. Unions, intersections, difference operations are all possible with Redis sets and are executed rather quickly.

### **When to use sets**

Sets are great for identifying relationships between entities. For example, keeping track of the individuals that make up a team. Because set values are always unique, another good example for utilizing sets is keeping track of unique visitors to a website or webpage.

### **Examples**

```bash
# Create a set for an amazing basketball team
> sadd "chicago bulls" "michael jordan" "scottie pippen" "dennis rodman" "luc longley" "ron harper"
(integer) 5

# Get all the members in the set
# note that the returned set is not in the order they were added
> smembers "chicago bulls"
1) "scottie pippen"
2) "michael jordan"
3) "luc longley"
4) "dennis rodman"
5) "ron harper"

# Determine if a given value is a member of a set
> sismember "chicago bulls" "michael jordan"
(integer) 1

> sismember "chicago bulls" "larry bird"
(integer) 0
```

## **Hashes**

Redis Hashes are maps between string fields and string values, and are great for storing more complex data. With that in mind, they are perfect for representing objects and, like [lists](#Lists), hashes can store more than 2<sup>32</sup> - 1 (4 billion) field-value pairs.

### **When to use sets**

If you're familiar with object-oriented programming, which I'm assuming a lot of you are, Hashes are a great way to represent and cache these objects. One great example I've read while
researching is inventory information for an e-commerce site.

### **Examples**

```bash
# Create a Hash and set multiple values at once
> hmset developer:001 "username" "thefrugaldev" "height" "5'10" "favorite beer" "bourbon"
OK

# Get the value associated with a hash field
> hget developer:001 "favorite beer"
"bourbon"

# Get all the fields and values in a hash
> hgetall developer:001
1) "username"
2) "thefrugaldev"
3) "height"
4) "5'10"
5) "favorite beer"
6) "bourbon"
```

### **Sorted Sets**

Sorted sets are similar in nature to [sets](#Sets), where they are non-repeating collections of strings. There is a subtle difference in that every member of a sorted set is associated with a score. **Scores** are a range of integers that can be expressed precisely. Sorted sets use a double 64-bit floating point number to represent the score, and this is what will ultimately be used to sort the given set.

While members of a sorted sets are unique, similar to [sets](#Sets), scores may be repeated. Sorted sets begin sorting the set as items are added, which is an _O_(log(_n_)) operation. This improves performance when retrieving an element from the sorted set, making it an _O_(1), or constant time, operation because it's already sorted.

Assuming an element is added to a sorted set with a unique score, the element will be sorted on that score appropriately. However, if the score provided is similar to another score already in the set, the elements will be sorted lexicographically (alphabetically). One other thing to note, sorted sets are variadic, meaning they have an indefinite arity, or the number of arguments a function accepts.

### **When to use sorted sets**

One of the best examples I've come across in relation to using sorted sets comes from Redis' own [documentation](https://redis.io/documentation). There are many commands to use when keeping track of leaderboards in an online multiplayer game, including [ZADD](https://redis.io/commands/zadd) when a new score is submitted, [ZRANGE](https://redis.io/commands/zrange) to pull the top of the leaderboard, and [ZRANK](https://redis.io/commands/zrank) to find a specific users' ranking, all with impressive speed.

### **Example**

```bash
# Create a sorted set with multiple members
> zadd "college football team rankings" 1 "georgia bulldogs" 3 "alabama crimson tide" 130 "florida gators" 2 "clemson tigers" 9 "notre dame" 6 "oklahoma sooners" 7 "auburn tigers" 5 "ohio state buckeyes" 8 "wisconsin" 4 "lsu tigers"
(integer) 10

# Get the score of individual members
> zscore "college football team rankings" "georgia bulldogs"
1.0
> zscore "college football team rankings" "florida gators"
130.0

# Return a range of members in a sorted set, by index
> zrange "college football team rankings" 0 8
1) "georgia bulldogs"
2) "clemson tigers"
3) "alabama crimson tide"
4) "lsu tigers"
5) "ohio state buckeyes"
6) "oklahoma sooners"
7) "auburn tigers"
8) "wisconsin"
9) "notre dame"
```

These are just some of the common data types I've run across while initially exploring Redis. If you'd like to explore further, a full list of data types with their associated commands can be found [here](https://redis.io/commands). I hope you've had some fun following along and enjoyed learning about some of the more useful data types in Redis; I know I did.


I've been interested in learning more about Redis, and when work presented me the opportunity, I jumped right in. In this post, I'll explore some of the common data types in Redis and when it makes sense to use each. I'll also provide some funny, real-world examples.

Getting Familiar with Redis Data Types


> _**Quick note:** Since writing this article, I've actually gone the route of using strictly Gatsby for my blog, but the content below still applies if you're thinking of using Ghost as your headless CMS._

I've finally done it, I've made the plunge and decided to create my own personal blog. This blog will mostly cover financial and technical topics that I find interesting. These could be topics that are new to me, or ones that I've been researching and using in my own personal life/career.

I figured what better way to kick off my new blog, than writing about how I actually implemented said blog. I was introduced to [Ghost](https://ghost.org/) through a friend and really liked the idea of a headless CMS. I also began looking into [Gatsby](https://www.gatsbyjs.org/) as my front-end component, since it offers the opportunity to really dig into [React](https://reactjs.org/) and [GraphQL](https://graphql.org/) as well.

## The Problem

One of the challenges I came across when implementing both solutions was deployability and the overall development process. I found a lot of articles, that suggested deploying to [Netlify](https://www.netlify.com/), and while this seems to be the easier solution, I really wanted to dive into what was happening under the hood, so I decided to deploy and host my blog on a Linux virtual machine (running Ubuntu 18.04) in Azure. I will take you through my deployment and development process as it stands right now.

## The Solution

The first thing you'll want to do is install both the Gatsby and Ghost CLI tools using NPM.

```bash
npm install -g ghost-cli
npm install -g gatsby-cli
```

Next, you'll want to begin developing and working on your blog locally to make sure everything is up to snuff. To do this, I will create two separate directories, one for Gatsby and the other for my Ghost installation. The Gatsby directory will be versioned in source control, but as we'll soon find out, this isn't the easiest solution in the world for Ghost and one of the major factors in deciding to go the headless route.

[Setting up Ghost locally](https://ghost.org/docs/install/local/) is very easy. In fact, its really just one line of code from your terminal or command prompt: `ghost install local`.
With this command, Ghost will run through various checks to validate system requirements and begin downloading and installing the latest version of Ghost onto your local machine. It will also start up your local instance after completing the installation. Once it's finished, you can confirm it's running by navigating to localhost on whatever port it set for you (default is 2368). It's now time to set up and configure Gatsby to serve your static front-end content.

Make your way to the directory you created for Gatsby and run the following command in your terminal:

```bash
gatsby new blog-frontend https://github.com/TryGhost/gatsby-starter-ghost.git
```

This will pull down a starter template from Github that allows you to get up and running very quickly. Once this completes, `cd` into your new blog directory and run either `yarn` or `npm install` to install any needed dependencies. Once those are installed, running `gatsby develop` will compile your site and give you another port to test on localhost (typically port 8000).

If everything above went smoothly, congratulations, you now have a working blog! But, that's not the end of our journey. We need to create a process that allows us to continually make changes and update our blog in production. We'll do that next.

## Moving to Production

After you've edited your front-end and you're happy with the look and feel, it's time to show the world what you've accomplished! I did quite a bit of research but was unable to find a simple solution for migrating my local Ghost instance to a production server, while keeping all of the content and themes in tact (another reason why I trended toward a headless solution). This was also why I chose not to version Ghost, as you'll need to run a fresh install anytime you stand up a new production or local copy.

So, with that being said, let's install our public blog. There is a pretty detailed outline of installing a production-ready instance of ghost on [their documentation website](https://ghost.org/docs/install/ubuntu/), but one thing to note is that there are some prerequisites. One of those being Ubuntu 16.04 or Ubuntu 18.04. Coming from the Microsoft world, I was limited to developing locally on my Windows machine. This presented problem number 2 for versioning Ghost. When installing on your production machine (Linux), Ghost creates a [symlink](https://en.wikipedia.org/wiki/Symbolic_link) between the current directory and the version directory within the root folder. This was an issue, since [Git will not handle symlinks](https://stackoverflow.com/questions/954560/how-does-git-handle-symbolic-links) well unless [explicitly told to](https://git-scm.com/docs/git-config#Documentation/git-config.txt-coresymlinks).

If you followed the documentation above and have a production instance up and running, its time to pull down your versioned copy of Gatsby and follow the same steps as above (navigate to the Gatsby directory and install any necessary dependencies). Once that's complete, your ready to build your final version and let the world see what you've accomplished! Simply run `gatsby build` and a public directory will be created for you, containing any static assets necessary for your production site.

## Configuring the Server

If you followed [Ghost's documentation](https://ghost.org/docs/install/ubuntu/) for setting up your production instance, it will install and configure Nginx for you and, depending on your choice in setup, will also configure SSL. However, because we're using Gatsby to serve our front-end content, we'll need to adjust our Nginx configuration file a bit more.

Navigate to the `/etc/nginx/sites-enabled` directory and open the `.conf` file that is associated with your site (this will have an `-ssl` suffix if you allowed Ghost to configure ssl for your site above) in whatever text editor you feel comfortable with. Another option is to create a copy of your file, so if there are any issues, you can start over using the configuration file that Ghost created for you.

If you opened the `-ssl` conf file, you should see something similar to this:

```bash
server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    server_name **your-domain-name**;
    root **path-to-your-nginx-root**;

    ssl_certificate **your-ssl-cert**;
    ssl_certificate_key **your-ssl-cert-key**;
    include **ssl-params-configuration**;

    location / {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Host $http_host;
        proxy_pass http://127.0.0.1:2368; #default port that Ghost runs on

    }

    location ~ /.well-known {
        allow all;
    }

    client_max_body_size 50m;
}
```

After making adjustments (or creating a new `.conf` file with the same settings as above), your new configuration file with Gatsby enabled should look like this:

```bash
server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    server_name **your-domain-name**;
    root **path-to-your-gatsby-directory**/public;

    ssl_certificate **your-ssl-cert**;
    ssl_certificate_key **your-ssl-cert-key**;
    include **ssl-params-configuration**;

    location / {
        index index.html;
    }

    location /ghost {
        root **path-to-your-nginx-root**;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Host $http_host;
        proxy_pass http://127.0.0.1:2368; #default port that Ghost runs on
    }

    location ~ /.well-known {
        allow all;
    }

    client_max_body_size 50m;
}
```

There are a few things to note about the updated configuration file. First, you'll notice that the root path is now pointing at the Gatsby directory we created earlier and, more specifically, at the public directory. This is where all of our static content lives. Second, you'll notice the default location is now pointing to our index.html file within our Gatsby directory. The other location that we explicitly define is our `/ghost` route and this is implementing the same configuration logic that was in the initial `.conf` file. This essentially tells Nginx to serve the Ghost back-end anytime the `/ghost` path is requested. This allows any administrative tasks like creating or updating posts to still be accessible.

After you've updated your config file, it's time to restart the server. Run the following command `sudo service nginx restart` and your site should now be up and running, pointing to your new Gatsby front-end.

## Final Thoughts

By now, your site should be up and running, so I'll leave you with a few final thoughts moving forward. First, any updates you make to your back-end, including new or updated posts, will require a new build within the Gatsby directory. Second, any new posts you create [will need to be exported](https://ghost.org/faq/the-importer/) in order to create backups in the event that something happens to your production server. My plan in the future is to create a job that automates this process, but in the meantime I'm manually creating backups anytime a new post is created.

I'm sure the process I've outlined will change overtime as I become more familiar with the intricacies of both frameworks, but for now this is my process for shifting between my development and production environments.

Side note: there may be a few files you want to keep secret, but still need in source control for any future environment migrations. The one that specifically comes to mind for me is the `.ghost.json` file, which stores your production url and api key. In order to prevent any updates you make in production from getting into source control, run the following git command in your terminal on your production server:

```bash
git update-index --skip-worktree .ghost.json
```

This will ignore changes to that file, both local and upstream, until you decide to allow them again with:

```bash
git update-index --no-skip-worktree .ghost.json
```

You can also get a list of any files that are marked skipped with the following command:

```bash
git ls-files -v . | grep ^S
```

That's it. Hope this post helped get you set up and running smoothly. I'll write about any updates regarding automation or enhancements to my process in future posts. Thanks for reading, and happy blogging!


With this being my first post, I thought I'd kick things off with a step-by-step guide into how I got my blog up and running. I'll also dive into the technology powering it behind the scenes.