
I have a _need_ for _speed_ when developing. That goes for starting up all of my development applications.

Here's what needs to happen before I start coding:

1. Open my repo in VS Code
2. Load in any environment variables
3. Start the local server
4. Open up chrome
5. Visit localhost:3000

A short list. But it takes a few key strokes and mouse clicks to get there. I think I can do better!

**Linux Alias Commands** are the answer.

I have a few set up for a few different use cases. Here's the one the runs the recipe for the steps above:

```
alias cap="cd /Users/cpadilla/code/my-repo && code . && open http://localhost:3000 && source settings.sh && npm run dev
```

I'm adding this to my .zshrc file at the root of my account.

That turns all five steps into one:

```
$ cap
```

Another use case: I keep a list of todos in markdown on my computer. Files are named by the current date. I could do it by hand every time, but there's a better way:

```
alias dsmd="touch $(date +%F).md && open $(date +%F).md"
alias todo="cd /Users/cpadilla/Documents/Todos && dsmd"
```

There we go! `$(date +%F)` is a command for delivering a specific date format. The `todo` alias navigates to the correct folder and then uses `dsmd` to create and open the file.

Small quality of life changes! They add up when you do the same commands every day. 🙂


Starting a Development Environment from the Command Line


## The Sitch

I'm in a spring cleaning state of mind with my data!

I keep a bunch of text files in a `Journal/` folder on my computer. It's pretty similar to the hierarchy Derek Sivers lists in [this post on writing in plain text](https://sive.rs/plaintext).

And then separately I have this blog where I store articles as markdown files in the codebase itself.

```
personalBlog/
|- _posts/
|- components/
|- util/
etc...
```

It's all on my computer, of course — but it feels strange to _write_ in prose in a text editor like VS Code. It even feels strange to store article drafts in the same place as the code for the site.

They are only a few clicks away, but they feel like far flung and very different spaces. So how do I handle keeping published articles and drafts both near each other and organized, but spacially being sourced somewhere that my blog has access?

## Symbolic Links

Alex Payne mentions in [this article](https://www.al3x.net/blog/2009/01/31/the-case-against-everything-buckets) using Symlinks.

Creating one looks like this:

```
$  ln -s source symlinkDestination
```

A very elegant and easy solution! The idea is that you can have a link to another file or directory within a completely different place. Like a regular URL link, but for local files.

My original idea was to have a symlink in the repo for this codebase and have all my writing stored in the Journal folder, included published pieces. The issue is that symlinks are just that - links. When storing them in git and publishing on Github, the files themselves are not pulled in.

So I swapped the direction. The symlink lives in my `Journal` directory, and the actual files are in the codebase. When I publish this article, I'm moving the file from `Journal/blog/drafts`
into the symlink `Journal/blog/_posts`, which then moves it over to the appropriate folder in the code repo.

It works beautifully on the command line.

A nitty, gritty, small tool - but one that makes me unreasonably happy to use!

## A Side Note on Aliases

Mac's have Aliases, which work in a very similar way. They are restricted to finder, though. I'm working mostly on the command line when I'm writing and working on code, and symbolic links are recognized both by finder and by linux systems.
