Browse Source

Add some drafts

Daniel Flanagan 1 year ago
Signed by: lytedev GPG Key ID: 5B2020A0F9921EF4
  1. 45
  2. 47
  3. 16
  4. 31
  5. 1


@ -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 [``](/), though, but you don't need
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
Let's get started!
# How This Site Works
+ Publish the site at will using Netlify (their CLI is great!)


@ -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
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.


@ -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
.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


@ -9,6 +9,7 @@
<link rel="stylesheet" href="/styles.css" />
<script defer src="/global.js"></script>
<script defer src="//"></script>
<script defer src="//" type="module" integrity="sha384-by67kQnR+pyfy8yWP4kPO12fHKRLHZPfEsiSXR8u2IKcTdxD805MGUXBzVPnkLHw"></script>
{{ block "head-end" . }}{{ end }}