@ -0,0 +1,45 @@ | |||
--- | |||
description: "" | |||
title: How to Setup A Fast, Simple, and Free Blog Like This | |||
draft: true | |||
--- | |||
**TL;DR**: Makefiles are awesome and use Netlify. The code for this entire site is available [here][repo]. I publish | |||
at-will using their CLI via `netlify deploy --prod`. It's simple and awesome. | |||
# Introduction | |||
This website *intentionally* may not look like much. It is simple both in style, | |||
colors, and layout. It is blazing fast. It looks the same on any mobile device. | |||
It uses the simple web technologies you already know. You can use any static site | |||
generator such as [Hugo][hugo] or [Gatsby][gatsby]. *And I don't pay for any of | |||
it to work!* I do pay for the domain [`lyte.dev`](/), though, but you don't need | |||
one. | |||
And it's awesome. | |||
And you can easily build on top of it, extending it to do anything you could | |||
ever possibly want! Need a Content Management System (CMS)? [Done][netlify-cms]. Need to deploy | |||
a complicated Single-Page Application (SPA)? [Easy][netlify-spa]. | |||
I'll show you how I put this together using tools already on your computer and | |||
how you can extend my system to use whatever tools you prefer on top of my basic | |||
ones. | |||
Let's get started! | |||
# How This Site Works | |||
+ Publish the site at will using Netlify (their CLI is great!) | |||
[netlify]: https://docs.netlify.com/cli/get-started/ | |||
[hugo]: | |||
[gatsby]: | |||
[gatsby]: | |||
[repo]: https://git.lyte.dev/lytedev/site.lyte.dev | |||
[netlify-cms]: https://www.netlifycms.org/ | |||
[netlify-spa]: https://www.netlify.com/blog/2020/04/07/creating-better-more-predictable-redirect-rules-for-spas/ |
@ -0,0 +1,47 @@ | |||
--- | |||
description: "" | |||
title: The Only Good Thing About YAML: Anchors, Aliases, and Extend | |||
draft: true | |||
--- | |||
**TL;DR**: You can prefix a YAML value with `&{NAME_HERE}` (like `&key`) to | |||
create an anchor with that name and reference it later with `*{NAME_HERE}` (like | |||
`*key`) to avoid repeating yourself in a document. You can also "merge" object | |||
values using the `<<` key. | |||
# Introduction | |||
Since working at [Postmates][pm] ([we're hiring][pm-referral]!) and getting my | |||
feet wet in the vast world of Kubernetes, I've had to work with a *lot* of | |||
[YAML][yaml]. | |||
One of the most important things for me when dealing with YAML was to keep in | |||
mind is that *YAML is a superset of JSON*. This means all JSON documents are | |||
valid YAML documents. When you look at YAML, it can be easy as a human to fail | |||
to parse what's actually going on. Which is fair, since fully parsing a YAML | |||
document actually requires quite a bit of code, which is a topic unto itself. If | |||
you remember that a YAML document is really (almost always) just a map of keys | |||
and values with various shortcuts that allow you the text representation (YAML) | |||
to look nice, YAML becomes a good deal easier to reason about. | |||
That also means, though, that YAML is wordy. Not as noisy as JSON, since many of | |||
the symbols are now unnecessary, but still wordy. If you have a type of object | |||
with 20 fields, all of which are mostly the same except for a few fields here | |||
and there, you are going to have to repeat yourself a lot. | |||
... At least in JSON. While I dislike YAML, I did learn two really neat features | |||
that helped enormously in cleaning things up and avoiding repetition or needing | |||
to change things in more than one place. I'm surprised, though, that these | |||
features occur so infrequently (maybe parser support is lacking?) out in the | |||
real, wild world as to be nearly undiscoverable: [Anchors and Aliases][aa-spec] | |||
and the [Merge Key][mk-spec]. | |||
# What is it? | |||
Basically, in a YAML document, you may denote a value node for future | |||
referencing later. | |||
[pm-referral]: https://grnh.se/cc2da77e1 | |||
[yaml]: https://yaml.org/ | |||
[aa-spec]: https://yaml.org/spec/1.2/spec.html#id2765878 | |||
[mk-spec]: https://yaml.org/spec/1.2/spec.html#id2765878 |
@ -0,0 +1,16 @@ | |||
--- | |||
description: "" | |||
title: Why You Should Use make and Makefiles | |||
draft: true | |||
--- | |||
**TL;DR**: Makefiles serve as a centralized and self-documenting source of | |||
commonly run commands associated with a project that are version-controlled and | |||
accessible by any team-member. If you've ever come back to a project after | |||
a long time and forgotten what all is necessary in order to spin up | |||
a development environment or which incantation is needed to get this particular | |||
project to compile, you need a Makefile. | |||
# Introduction | |||
@ -1,8 +1,27 @@ | |||
.PHONY: all default build dev publish publish-prod | |||
build: ; @hugo | |||
public: build | |||
dev: ; @hugo serve --buildDrafts | |||
HUGO ?= hugo | |||
DEV_SERVE ?= serve --buildDrafts --buildFuture --buildExpired | |||
NETLIFY_DEPLOY ?= deploy -d public | |||
.PHONY: all | |||
all: build | |||
.PHONY: build | |||
build: ; @${HUGO} | |||
.PHONY: public | |||
public: build | |||
.PHONY: dev | |||
dev: ; @${HUGO} ${DEV_SERVE} | |||
.PHONY: dev-ext | |||
dev-ext: ; @${HUGO} ${DEV_SERVE} --bind 0.0.0.0 | |||
.PHONY: clean | |||
clean: ; @rm -r public | |||
publish: public ; @netlify deploy -d public && echo "You can run \`make publish-prod\` when you're ready." | |||
publish-prod: public ; @netlify deploy -d public --prod | |||
.PHONY: publish | |||
publish: public ; @netlify ${NETLIFY_DEPLOY} && echo "Run \`make publish-prod\` when ready." | |||
.PHONY: publish-prod | |||
publish-prod: public ; @netlify ${NETLIFY_DEPLOY} --prod |