
The IRS uses the [Substantial Presence
Test](https://www.irs.gov/individuals/international-taxpayers/substantial-presence-test) to determine whether
a person is a resident for tax purposes. As of the time this calculator was built, the requirements for the
test are that the person must be physically present in the United States on at least:

1. 31 days during the current year, and
2. 183 days during the 3-year period that includes the current year and the 2 years immediately before that,
   counting:
   - All the days you were present in the current year, and
   - 1/3 of the days you were present in the first year before the current year, and
   - 1/6 of the days you were present in the second year before the current year.

This can be a bit confusing to calculate, so I've created a tool to help. Your changes will be automatically
saved to your browser so you can come back later on the same device and get an updated answer if necessary.

<br />

<SubstantialPresenceTest />

<br />


Substantial Presence Test Calculator


My side project [Mantle](https://mantle-docs.vercel.app) is an infra-as-code tool built with Rust
which is configured with YAML files. The key thing my docs need to communicate past the getting
started phase to my users is the format for these config files.

The [first
iteration](https://github.com/blake-mealey/mantle-docs/blob/80b64fdf06485f1efc78395ba5664a08c60699bd/docs/configuration.md)
of my configuration docs were written by hand in a markdown file in the docs site repo. They weren't
terrible, but I had a few issues with them.

## Choose the format for the job

When I started writing these docs, I organized them by complex types. At the top of the file, I
listed each of the top-level properties in the config file along with their type. If the type was
complex, I created a new heading in the document and linked to it.

This worked, but it's a format that's better suited to documenting the classes in a library than the
properties in a config file.

I once watched someone read the document for the first time, and it was unclear to them how the
information they were seeing related to the config file itself, even with the smattering of example
blocks I included.

## Manual changes are tedious

Because I was writing the document by hand, if I ever wanted to make a style change to the page, I
had to make it manually for every object and property. This was not ideal.

## Separate from code, separate from tooling

Documentation in a standalone markdown file is fine for humans to read, but not so good for
computers. If I ever wanted to surface this documentation in other mediums (e.g. inline in VSCode or
with an interactive CLI), I would need to rethink things.

## Enter, JSON Schemas

JSON Schemas are a format for specifying what makes JSON documents valid. Schemas themselves are
JSON documents which makes them easy to read and write. Since YAML is basically just JSON with
cleaner syntax, you can use a JSON schema to validate YAMl files too!

Now I _could_ have replaced my manually written markdown file with a manually written JSON schema
file, but this would have been very unpleasant. I still want to format my docs with markdown, and
considering JSON has no multiline strings that would have been very painful. It also would have
meant manually documenting all of my type information.

Fortunately, many languages have tooling for generating JSON schemas from their type systems, and
Rust is no exception. I discovered [schemars](https://graham.cool/schemars/) which can be easily
used to generate JSON schemas from my Rust structs and enums just by adding a
`#[derive(JsonSchema)]` attribute to them. And the great thing is, schemars integrates with serde so
that it understands serde attributes and produces a schema which matches serde's validation!

I did experience a couple of challenges using schemars, however. schemars uses Rust's doc comments
to capture the JSON schema `description` property, but it does some mangling to the text first which
means that it breaks markdown formatting. To get around this I am working off of a fork of the
library, but I hope to merge in an option to address this properly in the future.

Another challenge I ran into was wanting to add extension properties to my JSON schema. schemars
does support this through its Visitor API, but there is currently no attribute to add an extension
property to a Rust type directly. My solution was to add a special line at the top of my
descriptions when I wanted to add a custom property and then I parsed these out in a Visitor. I also
hope to add this as an attribute to the core library when I get a chance.

## Generating some docs

Now I just needed to generate some docs. Coming back to the format question from earlier, I decided
to try and emulate some examples of other projects documenting large config files like [GitHub
Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions),
[GitLab CI](https://docs.gitlab.com/ee/ci/yaml/index.html), and
[Rollup.js](https://rollupjs.org/guide/en/#big-list-of-options). Basically, instead of organizing by
classes, these docs are just a nested list of all the properties in the schema. Each property
includes the full path name (e.g. `jobs.<job-id>.name`). This makes it very clear to the reader how
the documentation can be applied to the config file itself!

I took a look at some existing JSON schema docs generators but none of them really looked the way I
wanted them to. Most of them used a similar organization to what I started with, so I decided to
roll my own.

I wrote a TS script to load a JSON schema and flatten the properties into a big list, along with
some additional metadata like the full property name, and whether it is a required property.

Then, I wrote a simple Handlebars template which iterated over the properties and printed their docs
in a consistent format.

## Autocomplete and in-editor docs

To take advantage of my schemas even more, I tried loading it into VSCode. With the YAML extension
installed, it was as easy as adding `"yaml.schemas": { "mantle.yml": "schema.json" }` to add
autocomplete and in-editor docs to my config files.

But, they looked... bad. The formatting was all off.

It turns out VSCode interprets the `description` property of schemas as plaintext, and if you want
it to look correct, you need to use a `markdownDescription` property. I was also using some
non-standard markdown syntax which my docs platform ([Docusaurus](https://docusaurus.io)) supports
(like admonitions and code block titles).

To resolve this, I wrote another TS script to transform a schema into something VSCode can properly
interpret. I used remark to parse the markdown into an AST, then modified the AST.

My biggest challenge here was related to Node.js's ESM support. Recently, the remark ecosystem has
"upgraded" to ESM-only, but currently TS has very bad interop with these modules. In the end, I
decided to just use older versions of these packages which use CommonJS modules.

## Tying it all together

Once I was happy with the schema I was generating from my types, I updated my `deploy` GitHub Action
to generate the schema and upload it with my GitHub release assets. Now whenever I bump my version,
a GitHub Action builds my project, creates a Release, and uploads the binaries and schema.

Then I updated my docs generation script to start by downloading all schemas from past releases. I
use the latest one to generate my docs page, then I run all of them through my transformer to make
them VSCode-ready and save them to my site's static directory. Now when I deploy the site, these
schemas are hosted with it (e.g. my
[v0.11.0](https://mantle-docs.vercel.app/schemas/v0.11.0/schema.json) schema).

My users can now just add `"yaml.schemas": { "mantle.yml": "https://mantle-docs.vercel.app/schemas/v0.11.0/schema.json" }`
to add autocomplete to their editor!

TODO: Conclusion


Documenting a Rust Project with JSON Schemas


If you're using .NET Core 3, you're probably relying on it to serialize and deserialize
your models to and from JSON. One of the great things about that is you can easily
configure the serializer in one place and it will use those options wherever it
serializes or deserializes your models.

For example, you could configure it to automatically deserialize enum values for you:

```cs
// Startup.cs
services.AddControllers().AddJsonOptions(opt =>
{
    opt.JsonSerializerOptions.Converters.Add(new JsonStringEnumConverter());
});
```

Now this is great and all, but what if you need to do some custom serializing outside of
the .NET pipeline? Ideally, we could use the same serializer options to make sure we get
consistent results throughout our project.

First of all, it's worth noting that the way the `System.Text.Json` library is designed,
the serializer (`JsonSerializer`) is a static class that cannot be instanced. Therefore,
we cannot access a serializer instance that is configured with our options. Instead, we
need to have access to the options object itself, and pass it in to the serializer (e.g.
`JsonSerializer.Serialize(myJsonString, myJsonSerializerOptions)`).

Fortunately, there's an easy — though not well documented — way of injecting the
`JsonSerializerOptions`:

```cs
// MyController.cs
private readonly JsonSerializerOptions _jsonSerializerOptions;

public MyController(IOptions<JsonOptions> jsonOptions)
{
    _jsonSerializerOptions = jsonOptions.Value.JsonSerializerOptions;
}

public IActionResult MyAction()
{
    // ...
    JsonSerializer.Serialize(someJson, _jsonSerializerOptions);
    // ...
}
```

This is great although a little unintuitive. We can clean it up a bit by adding a service
provider for `JsonSerializerOptions` directly to our container:

```cs
// Startup.cs
services.AddControllers().AddJsonOptions(opt =>
{
    // configure our JsonSerializerOptions
});

services.AddSingleton(provider =>
    provider.GetService<IOptions<JsonOptions>>().Value.JsonSerializerOptions);
```

Now we can directly inject `JsonSerializerOptions`!

```cs
// MyController.cs
private readonly JsonSerializerOptions _jsonSerializerOptions;

public MyController(JsonSerializerOptions jsonSerializerOptions)
{
    _jsonSerializerOptions = jsonSerializerOptions;
}

public IActionResult MyAction()
{
    // ...
    JsonSerializer.Serialize(someJson, _jsonSerializerOptions);
    // ...
}
```


Injecting JsonSerializerOptions in .NET Core 3


## Background

I recently got the chance to completely reset my Windows 10 machine, and took advantage of the
opportunity to create a dev environment I would love. These were my high-level goals:

- Make WSL my primary dev environment
- Use VSCode as my primary editor
- Have a beautiful terminal

## WSL & VSCode

To achieve this, I started by installing WSL 2. I went with an Ubuntu distro because that's what
I've had the most experience with in the past. You can find instructions on installing WSL and/or
upgrading it to WSL 2 in the [official
docs](https://docs.microsoft.com/en-us/windows/wsl/install-win10).

Next I installed [VSCode](https://code.visualstudio.com/), and the [Remote Development extension
pack](https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.vscode-remote-extensionpack)
which is where things start to get fun. With this extension pack installed, you can edit files in
the WSL filesystem seamlessly with VSCode.

## Windows Terminal

To get my beautiful terminal going, I installed [Windows
Terminal](https://devblogs.microsoft.com/commandline/windows-terminal-1-0/) (WT), which is an
awesome new terminal experience for Windows from Microsoft.

Although I wanted WSL to be my primary dev environment, I still wanted working in Windows to be a
nice experience as well, so I wanted to make sure my PowerShell terminal was great too. To get that
going, I also installed the latest [PowerShell
7](https://devblogs.microsoft.com/powershell/announcing-powershell-7-0/).

Now it was time to setup my WT profiles. By default, WT creates a profile for WSL, PowerShell, cmd,
and Azure Cloud Shell. I'm not interested in using cmd or Azure Cloud Shell, and I'm going to be
using PowerShell 7 instead of PowerShell, so I disabled all but the WSL shell. To do this, simply
add the `"hidden": true` property to the profiles in the WT settings file (click the dropdown in the
header bar and then Settings or <Shortcut>Ctrl+,</Shortcut>).

### PowerShell WT Profile

Now to create my PowerShell 7 profile, I added the following object to the profiles array:

```json
{
  "guid": "{346d54ee-6282-41c7-846a-0a2fa38ff66b}",
  "name": "PowerShell",
  "commandline": "pwsh.exe",
  "icon": "%SystemRoot%\\Installer\\{8B844F39-E6EE-486B-BE85-96A485AE2B96}\\PowerShellExe.ico",
  "startingDirectory": "D:\\code"
}
```

A few things to note:

- To generate a GUID, you can use the [Online GUID
  Generator](https://www.guidgenerator.com/online-guid-generator.aspx) website
- I am using the `pwsh.exe` command instead of `powershell.exe` to use PowerShell 7
- Follow these steps to find the icon path on your system:
  1. Open your Start menu and search for PowerShell 7
  2. Right click on the app and click "Open file location"
  3. In the file explorer that opens, right click the shortcut and click "Properties"
  4. On the "Shortcut" tab, click the "Change Icon..." button and copy the file path
- I like to set the starting directory to be where I keep all my projects, and ideally this is near
  the root of a drive to keep file paths as short as possible

### Ubuntu WT Profile

Since I want to make WSL my primary environment, I moved its profile object to the top of the list
so that it will appear first in the new tab dropdown. Then I replaced the top-level `defaultProfile`
property with the WSL profile's `guid` property to make it the profile that is opened automatically
when WT launches.

Similarly to PowerShell, I wanted the starting directory to be `~/code`. If you try setting that
directly in the WT configuration, you'll find it doesn't work because WT doesn't know how to resolve
it. You can use an absolute path to get there instead, and you need to use a Windows file path that
WT can understand. You can access a WSL distro's file system from Windows using `\\wsl$\<distro>`, so, I added this property to the Ubuntu profile object: `"startingDirectory": "\\\\wsl$\\Ubuntu\\home\\blake\\code"` (where `Ubuntu` should be replaced with the name of your WSL
distro and `blake` with your WSL username).

### WT Theme

Finally, I wanted to get a new theme for my WT. I decided I would like to use the same colour scheme
as I was using for VSCode at the time, which was the [Night
Owl](https://marketplace.visualstudio.com/items?itemName=sdras.night-owl) theme. So (naturally), [I
created](/posts/generate-windows-terminal-scheme) a [VSCode
plugin](https://marketplace.visualstudio.com/items?itemName=blake-mealey.generate-wt-scheme) to
automatically generate a WT theme.

Here's what my terminal looks like with the Night Owl theme:

![Windows Terminal with Night Owl](/images/awesome-windows-environment/terminal.png)

## Shell Profiles

Next up I wanted to get my shell profiles started. We'll iterate on these more later on. Your shell
profile is a script that gets run when the terminal starts which can be used to configure the
current environment. For PowerShell, this will be a PowerShell script and for WSL it will be a bash
script.

### PowerShell Profile

Let's start with PowerShell again. You can run `echo $PROFILE` to see if a profile script already
exists. For me it did, and it was located at
`C:\Users\blake\Documents\PowerShell\Microsoft.PowerShell_profile.ps1`. If it doesn't exist for you,
it's not a big deal. It seems that PowerShell looks in a [variety of
places](https://devblogs.microsoft.com/scripting/understanding-the-six-powershell-profiles/) and you
can just create a script in the appropriate place and it should work. Here's what I added to my
profile script:

```ps1
# C:\Users\blake\Documents\PowerShell\Microsoft.PowerShell_profile.ps1

Set-Alias -Name editor -Value nano
Set-Alias -Name edit -Value editor

function profile_alias { editor $PROFILE }
Set-Alias -Name profile -Value profile_alias

function reload_alias { & $PROFILE }
Set-Alias -Name reload -Value reload_alias
```

Let's break this down a bit. First of all, I am creating a couple aliases (`editor` and `edit`) for
my in-terminal editor. I prefer to use a terminal editor instead of a GUI editor because it reduces
context switching when working in the terminal, and is much faster to load the file to make a quick
edit. That said, if you wanted to use VSCode, you could replace `nano` with `code`.

The reason I create an alias for my editor command is so that I can change the editor at any time
and not have to change my muscle memory to use the new command. It also means I can create more
aliases that open the editor without having to change all of them if I change my editor.

Next, I add the `profile` alias which opens the profile script in my editor (the `editor` alias is
already coming in handy!). This is great because now I don't need to remember where my profile is
ever again, I can just run `profile` and can start editing it right away. I also add a `reload`
alias which simply reloads the shell using the profile script. This lets me use my changes to the
profile script without having to create a new terminal instance.

### Bash Profile

Now let's do the same thing for bash. In bash, the profile is a bash script located at `~/.bashrc`.
By default it contains a lot of stuff already, so I like to add my changes to the bottom of the
script. Here's what I added:

```bash
# ~/.bashrc

export EDITOR="nano"
alias editor="$EDITOR"
alias edit="editor"

export PROFILE="~/.bashrc"
alias profile="editor $PROFILE"
alias reload="source $PROFILE"

alias explorer="explorer.exe"
```

This is very similar to the PowerShell script. First, we create an `EDITOR` environment variable.
Some Linux programs respect the `EDITOR` variable, so it's a good idea to set it if you want more
programs to know which editor you want to use. Then we use `EDITOR` to create our `editor` and
`edit` aliases just like before.

Then, I add the same `profile` and `reload` aliases to edit and reload the profile script.

Finally, I added another alias which maps `explorer` to `explorer.exe` which makes it the same
command for opening the Windows File Explorer in WSL as in PowerShell.

## Terminal Editor

Let's revisit our terminal editor. I started with nano because it's a pretty intuitive and easy to
use editor for terminals. I don't have a lot of terminal editor experience, so I'm not very handy
with Vim, and even nano can be a bit awkward to use.

So, I did a bit of research to see if there were any editors that had more similar keyboard
shortcuts and navigation to a modern GUI text editor, like VSCode. I found
[micro](https://micro-editor.github.io/) which is available cross-platform, which is perfect!

### PowerShell Editor

Let's install it. In PowerShell, it's most easily installed via [scoop](https://scoop.sh/) or
[Chocolatey](https://chocolatey.org/). If you don't have either installed yet I'd highly recommend
you do, as it makes installing programs in Windows a much easier experience. I'm going to use scoop
for the purposes of this guide. With scoop installed, simply run `scoop install micro`. Now you can
run `micro` to edit your files.

Let's update our profile script to use it:

```ps1
# C:\Users\blake\Documents\PowerShell\Microsoft.PowerShell_profile.ps1

Set-Alias -Name editor -Value micro
```

### Ubuntu Editor

To install on Ubuntu, we can run the install script from the micro website:

```bash
curl https://getmic.ro | bash
```

Now we can update our bash profile to use it:

```bash
# ~/.bashrc

export EDITOR="micro"
```

### Micro Theme

One issue you might notice once you start editing in micro is that it's theme clashes with your WT
theme. One option could be to port your WT theme to micro, but this is quite a bit of work. I found
using the built-in `simple` theme uses your terminal theme's background colour and seems to fit
quite well for me.

To do this, you'll have to configure micro for PowerShell and WSL separately. To configure it, open
micro, press <Shortcut>Ctrl+E</Shortcut> to open the command prompt, then enter the command `set colorscheme simple`.

## Terminal Prompt

Finally, to make our terminal really pretty, we need to customize the prompt. There's lots of
options out there for this, but the most popular one seems to be
[ohmyzsh](https://github.com/ohmyzsh/ohmyzsh) for Bash and
[oh-my-posh](https://github.com/JanDeDobbeleer/oh-my-posh) for PowerShell. I'm not a huge fan of
these because in my experience they slow down the terminal to a point which makes me frustrated to
use them, and since they are separate solutions for each environment they must be configured separately.

Enter [Starship](https://starship.rs), a "blazing-fast," cross-platform alternative with a
delightfully simple prompt and some awesome customization (with the promise of even more coming in
future releases). Since WSL and PowerShell both have access to the Windows filesystem, we can even
store the Starship configuration in a central place and have both pull from it.

### PowerShell Starship

To install Starship for PowerShell, we can again use scoop: `scoop install starship`. To load
starship, we again need to edit our profile (now with our snazzy editor and single-command alias):

```ps1
# C:\Users\blake\Documents\PowerShell\Microsoft.PowerShell_profile.ps1

Invoke-Expression (&starship init powershell)
```

Now we can run our `reload` alias and see the beautiful prompt immediately.

### Bash Starship

Installing Starship for Bash is just as easy. First run the bash install script from their website:

```bash
curl -fsSL https://starship.rs/install.sh | bash
```

Then add its init script to our profile:

```bash
# ~/.bashrc

eval "$(starship init bash)"
```

Enter `reload` and we can see it in bash now too.

### Powerline Fonts

One problem you may see at this point is that some icons in the prompt don't render correctly. To
fix this, we need to configure a Powerline font for WT. The default WT font is `Cascadia Mono`.
Cascadia is a font family which comes in the variants:

- Cascadia Mono - Cascadia without programming font ligatures
- Cascadia Code - Cascadia with programming font ligatures
- Cascadia (Mono|Code) PL - One of the above with Powerline symbols

By default, Cascadia Mono and Cascadia Code are installed, but you'll have to download and install
the Powerline variants yourself from their [GitHub
Releases](https://github.com/microsoft/cascadia-code/releases).

You could use any other [Powerline font](https://github.com/powerline/fonts) you like, but I think
Microsoft did a great job with this one.

Once the font is installed, you can open your WT settings file and add the `"fontFace": "Cascadia Code PL"`
property to the `profiles.defaults` object. (I also like the programming font ligatures so I am
using the Code variant. If you don't like the ligatures, use the Mono variant instead).

### Starship Configuration

To configure Starship the same on PowerShell and WSL, we'll start by creating the configuration file
in the Windows filesystem for PowerShell, then create a symlink in the WSL filesystem. You could
also do it the other way around, but I think this is better for a couple reasons:

1. It's easier to create symlinks in Linux than in Windows
2. You could add or remove your WSL distros in the future, so having the configuration in Windows
   means it can be used by multiple WSL distros at once, and it won't be deleted if you remove a WSL
   distro in the future

Starship looks for its configuration file in `~/.config/starship.toml` by default. In PowerShell,
`~` resolves to `C:\Users\<username>`, so we can run the following commands to create our
configuration file:

```ps1
mkdir ~/.config  # It's possible this already exists, especially if you've installed micro
touch ~/.config/starship.toml
```

Now you can add whatever configuration you'd like here. I personally don't like all the extra
newlines they have on by default, and I also don't like a couple of the modules they enable by
default, so this is what my configuration looks like:

```toml
# ~/.config/starship.toml

add_newline = false

[line_break]
disabled = true

[package]
disabled = true

[nodejs]
disabled = true
```

I'd encourage you to try out the default settings first to see how _you_ like them before making
these changes though.

Finally, we need to sync these changes to WSL. In bash, you can run these commands to create the
symlink:

```bash
mkdir ~/.config  # It's possible this already exists, especially if you've installed micro
ln -s /mnt/c/Users/<username>/.config/starship.toml ~/.config/starship.toml
```

Here's what my terminal looks like now with starship running:

![Windows Terminal with Starship Prompt](/images/awesome-windows-environment/starship.png)

## Conclusion

It's getting easier and easier to create a beautiful and functional dev environment in Windows 10
these days. I hope this guide was useful to you and that you learned a few new things along the way
(I know I sure did).

Happy coding!


Creating my awesome Windows 10 dev setup


## Background

[Generate Windows Terminal
Scheme](https://marketplace.visualstudio.com/items?itemName=blake-mealey.generate-wt-scheme) is a
VSCode extension for, well, generating [Windows Terminal colour
schemes](https://docs.microsoft.com/en-us/windows/terminal/customize-settings/color-schemes). What
does it generate them from? The currently active VSCode colour theme!

I built this because I wanted my VSCode and Windows Terminal to match, and I must say I am super
happy with the results!

![Results](/images/generate-windows-terminal-scheme/results.png)

_<center>Using the [Night Owl](https://marketplace.visualstudio.com/items?itemName=sdras.night-owl) theme</center>_

In fact, I was so happy with it, I even used colours from Night Owl for this website, so now my
editor, terminal, and website are all matchy-matchy.

## Usage

To use it, first install it in VSCode. Then, open your command pallette with <Shortcut>Ctrl+Shift+P</Shortcut>,
type 'Generate Windows Terminal Scheme' and hit <Shortcut>Enter</Shortcut>. At this time, there is
no extension API to get the name of the colour theme, so you will be prompted to enter it. When you
enter the name, a new editor will open containing a JSON object.

You can now copy that JSON object, and paste it into your VSCode `schemes` array. To do that, open
VSCode, click on the dropdown in the header bar and click Settings (alternatively, <Shortcut>Ctrl+,</Shortcut>).
Your settings file will open in your default JSON editor. Now find the `schemes` array, and paste
the JSON into it. To use the scheme, add a `"colorScheme": "<your-title>"` property to either the
`profiles.defaults` object, or any of the profile objects in the `profiles.list` array.


Generate Windows Terminal Scheme


## Background

I recently reset my PC, partly because my C drive was constantly full which was a constant headache
that prevented me from updating Windows.

These are some of the measures I took to keep my C drive slim this time around.

## UWP Apps

Windows offers a nice solution for this problem for its UWP apps (apps you install from the
Microsoft Store). Open your Start menu and search for 'Storage settings.' Then under 'More storage
settings,' click on 'Change where new content is saved.' You can now choose which drive various new
content will be saved, including apps, documents, and photos. Changing the file type folders will
move your user profile's Documents, Pictures, etc. folders to the drive you specify. I chose to
change all of them to use my D drive.

This will not affect existing apps, but fortunately there's a pretty easy way to move existing UWP
apps to the same drive. Open your Start menu again and search for 'Apps & features.' Now select the
'Filter by' dropdown and choose your C drive. Now scroll through the list of apps and click on any
UWP apps. You can select the 'Move' option to move them to another drive. Unfortunately, Windows
won't allow you to move some of the core Windows apps this way.

## Chocolatey

Chocolatey is a great way to install programs and has the added benefit of keeping all the programs
it installs in the same place under its own install directory. Therefore, to keep those apps off
your C drive, you need only install Chocolatey off your C drive. To do this, you need to tell
Chocolatey where to install before installling it. Open your Start menu and search for 'Edit the
system environment variables' and click the 'Environment Variables...' button. Now in the System
variables section, add a `ChocolateyInstall` variable and set the value to be the directory you want
Chocolatey to be installed in. For example, I chose to put mine in `D:\programs\Chocolatey`. Now
you can install Chocolatey.

## Scoop

Scoop is another great package manager for Windows, which works in a similar fashion to Chocolatey.
Before installing it, add another system environment variable called `SCOOP` and set its value to be
the directory you want scoop installed in. I chose to put mine in `D:\programs\scoop`. Now you can
install Scoop.


~/posts

Posts

Drafts