Macroscopicentric

Migrating from Jekyll to Eleventy

Your Name — Sun, 08 Jun 2025 18:36:00 GMT

TL;DR: Just the Migration Steps

add package.json and eleventy.config.cjs (see above)
point layouts to _layouts in eleventy.config.cjs
convert _config.yml to _data/site.json
delete config.rb
add .eleventyignore to ignore this readme
replace my jekyll-feed RSS plugin with eleventy's rss plugin
add _posts.json and a permalink to the about page
delete a bunch of js and sass install eleventy's syntax highlighting plugin and update my code blocks
for eleventy 3: update the page links for the index + pagination
add a GH workflow, .nojekyll file, update repo settings in GH
verify domain through GH user settings

The Longer Version

For context: I started this process in January 2024 and finished in June 2025, hurrah personal projects, so there are references to Eleventy 2.0 below from before I migrated to 3.0.

I don't think there's a super clean config migration path from Jekyll to Eleventy but I might've also been underusing Jekyll's config. Per this blog post I moved my _config.yml (site-wide config) to _data/site.json, and then had to decide what to do about build config, which I didn't really have an equivalent for in Jekyll (I did have a config.rb, but it was minimal and I just deleted it). Eleventy currently (as of January 2024) has three config filename options for build config. I tried using eleventy.config.js and specifying "type": "module" in my package.json settings per the recommendation of a friend, but that caused Eleventy to fatal. It looks like Eleventy is trying to migrate away from CJS but that work isn't yet complete, so I was able to leave the module type but did have to change to a .cjs extension for the config file.

Layouts are called layouts in 11ty's config and Jekyll's default pathing, but 11ty's path for them points to _includes/ by default, which honestly seems kind of weird to me as a design choice. I've configured it in the general config file to just point to _layouts/ as it did in Jekyll.

I also, for some reason I don't remember, had separate _layouts AND _includes directories, and my html page fragments (head, header, footer) were in _includes, which made this especially confounding. It's at this point that I started enthusiastically copying from Alex Pearce's blog code and I realized the syntax within the Liquid templating was different so I copied his and it just worked.

I then got stuck on my included scripts, which are probably absolute garbage and definitely include a fair amount of jquery (a combo of what's included by default by Jekyll and the theme I'd picked) but while commenting them out did finally make the blog serve locally, it also changed the location of my header text as well as the font used for the header and headings. (No posts appear yet.) So at this point I want to make this just work with my existing jquery for the theme and then update this later.

There's also some pathing wonkiness happening. Eleventy is turning my pathing for posts (which was "/blog/{page slug}/") into "/blog/{page slug}/index.html", which I think was my fault for the trailing slash, as Eleventy seems to turn those into directories. Removing the trailing slash makes the files end up in _site in the expected location, although they now have no file extension and I'm not sure if that's what Eleventy expects (even though they're properly formatted HTML). Similarly, my about page was going to "/about/index.html". Deleting that file/directory and adding a permalink to about.md's front matter does fix the pathing, but now Eleventy can't seem to find the top-level (also without a file extension) about page. This is fixed now and then there were also some surprising things about front matter namespacing. I gained a lot by simply copying from Alex Pearwin's code for his Eleventy blog. My original (Jekyll's original?) pathing choices were even wackier, though, as my blog home is my index.html but then every next page of blog posts is at "/blog/page{number}", so I had to make a pretty goofy conditional to ensure the permalinks.

I don't think I fully understand Eleventy's assumed pathing because making an html file called "about" at the top level meant Eleventy couldn't find it. But making the permalink "about.html" but linking to it everywhere else in the templates as "/about" seems to work just fine (the URL is just "/about").

There was also definitely something wonky happening with Sass, which worked out of the box with Jekyll, but in this way where I have no idea what Ruby libraries it was using and I think I deleted all my Ruby config, so I needed to go look those up. I've installed the npm versions of Compass and Normalize but something had troubles finding Compass anyway. This is probably worth just blowing away and redoing from scratch since I have the final CSS I currently care about anyway. Also, I'm terrible at SASS. I was able to just delete Compass altogether and move to a NPM package for vanilla Normalize CSS, but Susy will need to get converted into native CSS as well.

A later update the above: this definitely isn't everything but Compass was Ruby code that is totally unsupported and no longer works with modern Ruby so I've excised that entirely, but my understanding of CSS and SASS isn't good enough to figure out where it was being used and how extensively. So I've just started with deleting the import. This blog post for using Sass with Eleventy was extremely helpful for setting everything up in the interim.

The last major thing was that I think either the entire template engine for Markdown or some of its config is different than what Jekyll used, because posts look mostly fine except for code blocks. The docs were pretty useful on this once I realized it's a plugin, but I got there via yet another blog post, and then I had to go to the Prism docs to figure out file pathing off of one of the CDNs for the theme I wanted.

Interestingly, although I did a lot of work earlier to maintain my pathing from Jekyll, upgrading to Eleventy 3 actually caused build errors because I have so many pages that don't have extensions, which Eleventy really doesn't seem to like but (IIRC, because I don't think I would've changed it) was a default in Jekyll. I've compromised by removing the very silly conditional I mentioned above to try to maintain the pathing on the paginated blog pages after the index, but have exempted all posts via additional config in _posts.json to try to keep the links consistent. I may regret this in the future, we'll see, but I'd really like to not break the historical blog links.

Narrator's voice from 30 minutes into the future: She did regret this. (I solved it by going back to look at Alex Pearce's config for his posts, which has a trailing slash. I removed the exemption and added the trailing slash to my posts permalink config and now everything works great.)

Finally, I had a bunch of issues deploying this via Github actions because I'd been using Jekyll for so long that the entire pipeline was automagical to me. In general the Eleventy deployment docs were extremely helpful and have specific config for your workflow since that's such a common use case. The one thing they didn't mention was that you also needed a .nojekyll file at the top level of your repo if you were coming from Jekyll, but there are a plethora of blog posts mentioning this (ex: Lea Tortay's blog post, which is commonly referenced, so that was easy to fix. I did miss an incredibly important step the first time, which was updating my repo settings to deploy from the gh-pages branch and not main. I also did not use --pathprefix, which is included in a lot of the guides, because I deploy this at the top level of my GH pages. I do recommend adding workflow_dispatch into your GH workflow triggers so you can retry it from the GH actions UI. Ex:

on:
  push:
    branches:
      - main
  workflow_dispatch:

I then had an incredibly confusing DNS issue, where I could see the blog at macroscopicentric.github.io but my own domain (macroscopicentric.net) gave me a Github Pages 404 instead. I'm truly not sure what actually caused this to go away, because I already had CNAME config set up in my GH workflow and that didn't seem to be working (where the same CNAME had worked with Jekyll). But I did two things: I verified the domain through my user settings on Github and added the domain to the repo's GH Pages settings, and then I deleted the domain from the repo's GH Pages settings and re-ran my action, which recreated it. I'm assuming it was the domain verification that solved my problem, but it also feels possible that there was some sort of bizarro caching problem at the DNS level from GH because my blog has been around so long with an unchanged CNAME. If anyone has a better idea of what might've happened here, I'd love to hear it!

Zsh Prompt Editing

Your Name — Tue, 14 Mar 2023 17:53:00 GMT

I finally switched my default shell on my laptop (Mac) from bash to zsh. I'd never bothered tinkering with a more sophisticated shell before this, so it was interesting to figure out what zsh could do. But I was frustrated because I had a nice prompt in bash, and it took me a while to recreate it.

My bash prompt was pretty simple, it included my current directory, then my git branch, then status indicators for different types of dirty state in a git repo (specifically, staged vs. unstaged changes). It also used to have a unicode crown emoji, but after working with bash on a lot of hosts with older versions of bash that didn't do well with unicode, I'd pulled the crown out years ago. (I was hopeful that I could add it back in, at least for my personal computer!)

(Sidenote: I looked into oh-my-zsh and then decided it was too complicated as a framework for my needs, so I'll be ignoring it here.)

Replicating my current directory with color-coding was very easy in zsh. It was actually even easier than in bash, since zsh accepts some strings for colors rather than codepoints. After reading the zsh prompt expansion docs and this 2019 blog post about customizing your zsh prompt, I ended up with:

PROMPT="%B%F{magenta}%1/%f%b 👑 "

Here I initiate bolded and magenta-colored text (%B%F{magenta}), then print one directory out of my working directory, using an absolute path regardless of whether I'm inside my home directory (%1/), then undo the magenta color and bolding (%f%b).

Next I wanted to replicate the git-related part of my bash prompt. Here zsh is, again, more sophisticated than bash, and has a bunch of basic out-of-the-box git functionality. If you just want to display your branch name and/or dirty state, zsh can do it right out of the box. I found git's own documentation of how to display git info in the zsh prompt super helpful, and it also linked directly to another section of the zsh docs on zsh and version control systems. After some trial and error (and more help from other people's blog posts), I had this:

# grab current branch and display in prompt
# source: https://git-scm.com/book/en/v2/Appendix-A%3A-Git-in-Other-Environments-Git-in-Zsh
autoload -Uz vcs_info add-zsh-hook
precmd_vcs_info() { vcs_info }
precmd_functions+=( precmd_vcs_info )
setopt prompt_subst

# These lines are specifically for staged + unstaged changes
# source: https://salferrarello.com/zsh-git-status-prompt/
add-zsh-hook precmd vcs_info
zstyle ':vcs_info:*' check-for-changes true
zstyle ':vcs_info:*' unstagedstr ' *'
zstyle ':vcs_info:*' stagedstr ' +'

zstyle ':vcs_info:git:*' formats '(%b%u%c)'

PROMPT='%B%F{magenta}%1/%f%b ${vcs_info_msg_0_} 👑 '

This did everything described above (show the git branch and all dirty states using different symbols), which was almost what I wanted. But I also really wanted part or all of the git part of my prompt to be color-coded red if there was any type of dirty state. After some spelunking through the git and zsh documentation, I decided that vcs_info was neat but just didn't have enough power to allow me to conditionally format the magic vcs_info_msg_0 variable. So I switched tactics, and went back to an old and reliable standby: the git-prompt.sh script in the git repo itself.

I'd used this script before, to do the same things in bash, but I hadn't yet installed or used it with zsh. So I explicitly included that in my .zshrc:

source ~/.git-prompt.sh

And then I did something I've honestly never done before, and I went and read that script's whole dang docstring to figure out if there was an easy way to do what I wanted. And there was! Here's the final draft of my prompt, which felt very simple in the end:

source ~/.git-prompt.sh

# allow prompt substitution, show dirty state in color (incl. untracked files), define prompt
# source: the git-prompt.sh (above) docstring
setopt prompt_subst
GIT_PS1_SHOWDIRTYSTATE=1
GIT_PS1_SHOWCOLORHINTS=1
GIT_PS1_SHOWUNTRACKEDFILES=1
precmd () { __git_ps1 "%B%F{magenta}%1/%f%b " "👑 " "| %s " }

(Second sidenote: I did switch from assigning to PROMPT to using precmd () here because the git-prompt.sh docstring recommended it as faster, but I'm not convinced it's faster for me. I haven't looked into whether this is user error, or zsh being different, or something else I haven't thought of.)

An Introduction to Command-Line Unix Tools

Your Name — Thu, 01 Sep 2016 22:23:48 GMT

I'm relatively new to Unix tools, and when I began, I was frustrated because I felt like the only way I knew how to find new tools was to ask people with more experience. The goal of this post is to provide some starting places if you'd like to learn more about what you can do on the command line, but it's not intended to be an exhaustive list.

apropos - I'm listing this one first because hopefully it will help you find others! Searches your man pages for the keyword(s) you pass into it. Ex: apropos networking will search for man pages that include the word "networking."
curl - get data over a network, via basically any protocol you can think of. It has a LOT of flags and can do oodles of stuff. I once made a joke about how I'd be back in six hours after hunting through the curl docs to find the flag I needed. The joke was on me; it really did take me that long to read the entire man page. Ex: curl http://www.example.com -v will give you the HTTP response (including headers) for a GET to www.example.com. Alternative (Linux only): wget.
netstat - show network connections. Ex: netstat -tunapl (example is Linux only).
ps - list currently-running processes. Ex: ps aux will list all processes for all users, including the percentages of CPU and memory being used. Alternative: pstree is a Linux-only tool that will show you a graph of all parent/children process relationships.
top - live view of current processes, including things like CPU percentage.
strace (Linux only) - trace system calls. Alternative for Mac OSX: dtrace. I'm not going to explain this one too much because Julia Evans wrote a great zine on it. If you're not sure what system calls are, Julia's zine explains that too!
/proc (Linux only) - a virtual directory that keeps track of information related to currently running processes. Once you have a process's PID, you can go to /proc/<PID> to find a variety of info. Ex: /proc/<PID>/fd is a directory listing all of the file descriptors (files being touched) for the given process, and /proc/<PID>/environ is a file listing a process's environment.

Using Other People's Code

Your Name — Mon, 25 Jan 2016 22:08:00 GMT

Including other people's code in your program means you don't have to write everything from scratch. You don't have to solve every problem on your own, and it's often faster and more efficient to use something off the shelf. There are three ways to include other people's code in what you're doing.

The first is something you already do: using the core of a programming language. If you're using Python, for example, every time you use import, for, or return, you're using code other people have written. These specific examples are called keywords, and you can easily find a list of all Python keywords online. Other examples of things in Python's core include its basic data types, such as strings, lists, and dictionaries, and all the methods you can use on those types.

In addition to a language's core, however, there's also the language's standard library. A standard library is a collection of modules that come prepackaged with your language. When the programming language was installed on your computer, everything in the standard library was installed with it. The standard library comes ready to use. All you have to do is include the module you want to use at the top of your file. In Python, one module in the standard library that often comes in handy is the collections module. Once you import the collections module, you can use any data type from within it, such as its OrderedDict and defaultdict. (I highly recommend Python Module of the Week if you want to know more about what's part of Python's standard library.) So you could do something like:

from collections import defaultdict

example = defaultdict('marshmallow')
print example['a']  # 'marshmallow'

The third way to use people's code is to use external libraries. Perhaps you want to use use an external API, such as Twitter's API. One way you could interact with Twitter's API is by using Python's built-in module urllib2, which is part of the standard library:

	import urllib2

	response = urllib2.urlopen('http://twitter.com')
	print response.info()  # list of headers from 'GET http://twitter.com'
	print response.read()  # body of 'GET http://twitter.com'

You can absolutely use Twitter's API (or any other public API) this way, but it's tedious! It will take a lot of code to authenticate you, then even more to fetch and parse whatever data you want access to, whether it's your own tweets, or tweets including a certain keyword, or someone else's mentions, etc. Wouldn't it be neat if someone else had done all the repetitive, boring work of making authentication work and automatically parsing the response? This is where third-party libraries come in; lots of people have already built external libraries that have abstracted out the repetitive parts of writing code to interact with the Twitter API. To use one, all you have to do is pip install <library name> from your terminal, and then import it into your file. Voila, you can now use someone else's third-party library from your own program!

There are some hazards to using other people's code. Sometimes you might have compatibility issues, or perhaps the library you want to use hasn't been updated in a really long time. Pay attention to the libraries you use. How thorough is the README? Is there additional documentation? Do they look like they're being worked on regularly? Do they have an IRC channel where you can ask questions if you'd like?

Using third-party libraries can mean trading convenience for behind-the-scenes complexity, and it may not always be worth it. If you're doing something simple, it might be better to use something from your language's standard library. But it's always good to know what other options exist.

Educational Resources for Beginners in Python

Your Name — Sun, 24 Jan 2016 11:13:00 GMT

This list is mostly Python-specific since that's how I learned to program, but some of these resources are language-agnostic. Feel free to try some out and then drop them if they don't work for you! The important thing is that you're learning, so find a learning tool that fits your style and needs.

Websites

Treehouse and Lynda are both subscription websites that have tons of educational videos and practice material for you to follow along. I've never used Lynda for this purpose, but Treehouse is beginner-friendly and covers a lot of topics, has forums to ask questions if you get stuck, and has workspaces where you can write and run code on the website instead of needing to store it on your computer. Treehouse also has a blog you can see without having an account and might have some helpful information.

If you need free resources, MOOCs (Massive Open Online Courses) are your friend. Websites like Khan Academy, edX, and Coursera have a bunch of educational videos that are organized into courses. Some courses have a syllabus, homework, and projects. Many have forums where you can ask questions.

Learn Python the Hard Way is a free online resource, although you can pay for a physical book or tutorial videos. Zed Shaw has a very opinionated teaching method, and tends to make you do things before explaining them. This works very well for some people, but not so well for others. (He also has a variety of other Learn Code the Hard Way resources for learning Ruby, SQL, C, and regex.)

If you're comfortable with the basics in Python and can write and use classes and short programs on your own, try going through Python Module of the Week. It's a website based on a set of blog posts where the author went through each module in Python's standard library. Each post has example usages for the module and its methods, and a lot of people find the organization very helpful.

Specific Tutorials/Walkthroughs

A Practical Introduction to Functional Programming by Mary Rose Cook. If you're not sure what functional programming is, check out that post and this Quora answer, and keep in mind that functional programming and object-oriented programming are not a dichotomy. You can use elements of both in the same program! Another of her blog posts, "My speech to new Recursers," includes some great general advice (at the bottom) about what to focus on when learning how to program.

She also has "Git in six hundred words" and an extensive essay called "Git from the Inside Out,". These are most helpful if you're already familiar with the most common git commands, such as git commit, git branch, etc, and want to know what git is doing under the hood when you type them. If you just want to figure out how to use git, you might find Atlassian's git tutorials useful instead.

Relatedly, if you're confused by how git works, that's okay! Entire articles have been written on how unintuitive git's interface is. I highly recommend learning the basics of how to use git from the command line and how it works under the hood at some point. But if not knowing git means you're being blocked on writing new programs, feel free to use the desktop client in the meantime. The GitHub team has worked hard to make the desktop client easy to use, so use it if it helps!

For Javascript, Julie Pagano wrote a really wonderful post titled "Javascript Debugging for Beginners."

If you're ready to build something on your own, building a Twitter bot is usually a good start. There are a lot of resources that can help. Sumana Harihareswara's blog post "Fisher-Price's My First Twitter Bot" is a great tutorial in Python. Disclaimer: Twitter bots are a fun and interesting project, but learn from my mistake: make your bot either opt-in (people follow it/tweet at it/etc) or non-interactive. Nobody likes a bot that spams people.

Finding a Mentor

It's tough to learn how to program without personalized help from a real person. Local meetups are a great way to meet both other beginners and people who can help you. Meetups specifically designed to help beginners are probably your best bet. Pyladies is an awesome group that focuses on supporting female Python programmers, has a bunch of locations, and is incredibly beginner-friendly.

I live in Portland (OR), and there's a group here called Mentorship Saturdays that's open to everyone and aimed at beginners who need coding help or career advice. And although you can use Meetup to find local groups wherever you are, in Portland we also have Calagator, an open source calendar specifically for tech events.

Speaking of open source, if you're interested in contributing to an open source project (it's great experience!) but aren't sure how to start, Open Hatch is a great website that aims to connect beginners in open source to beginner-friendly open source projects. Open Hatch itself is open source and written in Python, so that's one project you could work on!

Finally, the Recurse Center has just announced a new initiative called RC Start, where beginning programmers can sign up for a mentor and receive three 45 min one-on-one sessions (via Skype or in person). Go to the blog post for more info.

Configuration Management for Beginners

Your Name — Sat, 23 Jan 2016 16:17:00 GMT

Using Chef as an Example

Who is this blog post meant for?

This post is aimed at software engineers who have used configuration management software (especially Chef) without necessarily being comfortable with the process or fully understanding what they were doing. I spend a lot of time working with Chef in my day job, and frequently explain what's happening behind the scenes to software engineers in other sections of the engineering org who rarely make Chef changes. This blog post is a distillation of how I normally explain what configuration changes they're making and why.

What is configuration management?

Configuration management is the process of creating and maintaining consistent state across a complex system. If you're curious, there's a more comprehensive definition and a long list of industries that use configuration management on the Wikipedia page.

Why does configuration management software exist?

Say you have 1000 hosts that perform different functions. Some are web servers, some are mail servers, some host your database. You want some software on all of them: perhaps git, or monitoring software. And you want that software to be configured similarly on all of the hosts as well. For example, to ensure that the version of git is the same on every host, or that your LDAP configuration is the same everywhere.

In addition, you want some software on just some of your hosts. Of course you'd want a web server (Apache, Nginx, something else) installed on your web server hosts. You'll need a mail server for the mail server hosts, and a database on your database hosts. And again, you'd want the configuration for all of those pieces of software to also be consistent. Configuration management software allows you to manage all this configuration from one central location, rather than logging onto each individual host to set this up manually yourself. It allows you to start thinking of your hosts as a fleet and manage them as such.

So how does Chef do this?

A Chef repo has four major parts: data bags, recipes, roles, and environments.

Data Bags

Data bags are the simplest part; they're just files you can fill with whatever JSON you want to have access to on a host (typically called a node in Chef parlance). Data bags are organized into separate subdirectories depending on what type of data they contain. These organizational lines are entirely human-defined, so you can create whatever sort of subdirectory organization makes the most sense to you. Because data bags are so freeform, people put all sorts of things in them. Here's a great blog post by DNSimple where they use a data bag to store network config.

Recipes

A recipe is an individual script written in a Ruby DSL (Domain-specific language). A recipe can include a variety of steps, such as installing a software package or installing a file from a template. Steps in a recipe are attempted in order. Because Chef recipes are just Ruby code with some syntactic sugar, you can include logic within your recipe to only perform certain actions if the node has certain attributes, such as if it has a specific version of your operating system. Additionally, you can create your own attributes and attach them to certain nodes to use like tags. You can also consult the information contained in data bags from recipes.

Recipes are collected into cookbooks, which, like the data bags, are purely for human readability. However, cookbooks are generally organized along software lines. So for example, you might have a MySQL cookbook, where all the recipes contained within the cookbook relate to the installation and configuration of MySQL. You can also download community cookbooks, cookbooks created by other people, on the Supermarket. A cookbook should always have a "default" recipe. It may also have other recipes for installing the same piece of software but a different version, or be customized for a specific type of host, etc.

Cookbooks are versioned within Chef. When you make changes to a recipe, you must bump the respective cookbook version and push the new cookbook version to the Chef server.

Roles

A role is a functional collection of recipes that are all needed to build a specific type of host. Roles can contain other roles, so you can choose to create a base role as you would a base image, and add that base role to every new role you create from then on. A role executes all roles and recipes listed within it in order, which can cause ordering problems as your system grows in complexity and more roles and recipes are added.

Environments

An environment file is essentially a long list of key/value pairs where the key is a cookbook name and the value is a version number. After editing a cookbook and bumping the cookbook's version number, you must update the corresponding version number in any relevant environment files. This tells Chef to actually start using the new cookbook version in all roles that include it.

Why would you have different environment files? Environment files allow you to build different ecosystems, because you can have environment files with different cookbooks or even different versions of the same cookbook. For example, you might have different environment files for different deployment environments, such as one for staging and one for production. Or maybe you have one environment file that acts as staging for infrastructure changes themselves, and after making changes to a file in a cookbook you update the cookbook in your infrastructure staging environment file before rolling out the same cookbook version to your production systems.

Okay, but how do my changes actually take effect?

Chef has two functional parts. The Chef server stores all of your node and repo data. When you upload cookbook changes, for example, this is where those changes go. The other major part of Chef is chef-client, the daemon that sits on every node and regularly checks into the Chef server to see if there are any cookbook updates relevant to that node. For any updated cookbooks, chef-client will diff the changes between the old version and the new version, and then try to implement the diff. In other words, with Chef, you can make incremental updates to some or all hosts at the same time.

Some related concepts:

What are some alternatives to Chef?

There are two other common alternatives to Chef: Puppet and Ansible. You can find a full list of configuration management software on Wikipedia.

Infrastructure as Code, or Configuration as Code

Exactly what it sounds like! The saving of your configuration, from the creation of your instances in the first place if you're in the cloud (how much memory do they have? how much disk space?) to the software installed on them (which image are you using for this host? what operating system? what software config?), as code in a repository rather than ephemeral values that you edit by hand. Config as code allows you to use version control software to manage it, giving you all the benefits that come with VCS, such as being able to roll back to older versions of the code and tracking who's made what changes to the code and why. The Wikipedia page on Infrastructure as Code is great if you're looking for more info on this concept.

Mutable vs. Immutable Infrastructure

Mutable infrastructure describes a system where you can modify existing resources, such as Chef and other configuration management tools (see above). In Chef, you can make changes to already-existing hosts by adding new steps to existing recipes, or adding recipes altogether.

In a system with immutable infrastructure, on the other hand, all changes involve destroying and fully recreating resources. Containers like Docker, and container orchestration systems like Kubernetes, are good examples of systems with immutable infrastructure.

Which is better? It depends on what you're looking for. In a pure Chef system, creating new resources is costly because you create them from scratch every time, but every subsequent update is relatively cheap. In a pure immutable infrastructure system, the cost is in the creation of the image itself, so it depends on how frequently you make changes to the image, but creating new resources from that image is usually pretty cheap. A lot of places have arrived at a hybrid approach for this reason, where they have base images that are updated occasionally, and then have software that incrementally adds other software and configuration that's updated more frequently on top of what's being installed in the base image.

Like many things in software engineering, the question of whether to use mutable or immutable infrastructure (or a hybrid) has no one right answer. It all depends on what you currently do, how costly it would be to change, and where you and your organization ultimately want to spend your engineering time and energy.

What is Object-Oriented Programming?

Your Name — Sat, 23 Jan 2016 16:17:00 GMT

Object-oriented programming is the idea that data has its own identity and methods so it can do things for itself, instead of a workflow where functions do things to the data. The main goal here is delegation: you can tell an object what you want it to do, but you don't have to worry about the details of how it will accomplish what you want. This allows you to decouple (remove unnecessary dependencies) your code. Decoupling your code means you can change the implementation of an object's method without needing to change the code calling that method, and vice versa. (If you found this explanation confusing, here's a Quora post that tries to answer the same question.)

In practice, object-oriented programming works by creating classes that have variables and methods, then creating instances of that class that store different information in the variables but have similar ways of interacting with it through the methods. You can have a lot of instances of the same class, so a common metaphor is to explain a class as a rubber stamp, and instances of that class like the images created by the rubber stamp. I like to compare classes to the Platonic ideal.* A class is a Platonic ideal of an object, and instances are actual working examples of the class. Like the Platonic ideal of a thing, a class is something you don't usually interact with directly. Instead, you make and then interact with instances of it. So if we use the example of a horse (a common example when explaining the Platonic ideal), you'd have a class Horse, and then individual horse instances of Horse that contain slightly different data, or ideas of what a horse can be. Perhaps your Horse class contains variables for things like age, gender, color or breed, height, etc. Then you could have different instances of Horse with different configurations, such as "a pinto mare" or "a bay yearling" or "a grey stallion." All these individual horses are still instances of Horse, so they all know how to do things that all horses should be able to do, like run. Putting all this together, we could write an example class and instance like this:

	class Horse(object):

		def __init__(self, age, gender, color):
			self.age = age
			self.gender = gender
			self.color = color

		def run(self, distance):
			print "The %s horse runs %d miles." % (self.color, distance)

	pinto_mare = Horse(6, 'female', 'pinto')
	pinto_mare.run(4) # "The pinto horse runs 4 miles."

In a real program, you'd probably have a lot more than just one Horse instance. All instances of Horse would know how to run, and possibly jump, and eat, and do other things. Then instead of needing to manually move the horse (which involves knowing a) how to move a horse and b) how to move this specific horse), you'd simply type pinto_mare.run(4) or pinto_mare.walk(1) and the horse would move itself.

Not everything needs its own class though! How do you tell when something is large enough to warrant writing a class for it? One good marker is trying to pass around a cluster of data all together and/or doing repetitive things to it. These actions signal that you're thinking of that data as a unified entity, at which point it might be worthwhile creating a separate class for it.

Writing object-oriented code allows you to decouple your code, which makes it more flexible, since you can change something without needing to also change everything that uses it. This makes both testing and editing your code much easier and less error-prone. I mean, who doesn't want to make oodles of different horses?

Then I decided to try an experiment and put all of my hard work to the test. The next morning I got up and walked straight to my computer.. (@Horse_ebooks)

*In a nutshell, Plato was convinced that for every concept in the world, there was an ideal form of it that existed somewhere out in the ether. This perfect, ideal form appears in our minds when we try to categorize something we see in the real world. Ex: you see a horse. Your mind contains the Platonic ideal for Horse, and your mind then matches the real, existing horse to your mental Horse, and that's how you know that what you're seeing is indeed a horse.

Macroscopicentric

Migrating from Jekyll to Eleventy

TL;DR: Just the Migration Steps

The Longer Version

Zsh Prompt Editing

An Introduction to Command-Line Unix Tools

Further Reading

Using Other People's Code

Educational Resources for Beginners in Python

Websites

Specific Tutorials/Walkthroughs

Finding a Mentor

Configuration Management for Beginners

Using Chef as an Example

Who is this blog post meant for?

What is configuration management?

Why does configuration management software exist?

So how does Chef do this?

Data Bags

Recipes

Roles

Environments

Okay, but how do my changes actually take effect?

Some related concepts:

What are some alternatives to Chef?

Infrastructure as Code, or Configuration as Code

Mutable vs. Immutable Infrastructure

What is Object-Oriented Programming?