When I first fell in love with programming, I didn't know what to do with it, so I started trying to solve these problems. All I knew was a little C++, so I used that until a friend introduced me to Python. I also had no sense of runtime complexity, so it was surprising when my code would seemingly just hang instead of producing an answer.

My limited skills allowed me to solve some problems, and the fake internet points felt rewarding. The site also let me know that I had much left to learn since the list of problems was long and mostly unapproachable.

More recently, I returned to the site and was able to solve another ~20 problems in JavaScript without too much effort. Years ago, those problems probably felt out of reach. Of course I know I've gotten more capable since those early days, but it was nice to really feel it.

Solving 50 problems advanced me to Level 2! As of this moment, I've solved 52 problems which puts me in the 95th percentile of all registered users who've solved at least one problem. If you're logged in, you can view those stats here.

Some people use these kinds of problems to explore a new language, but my recent solutions were written in JavaScript, a language I know well. Even then, BigInts aren't very familiar to me, but I needed them occasionally in this context. But for most problems up to this point, basic floating-point numbers and data structures like objects, arrays, and sets are enough to get the job done.

These solutions should only take a moment to run through some combination of mathematical insight and using the right data structures, but I wrote one solution that took ~10 minutes to run. When that problem was written in 2007, the brute force solution would've been further out of reach, but now I can just grind out an answer in JS on a laptop.

Each problem has a difficulty rating. I'm not sure how they're calculated, but most of the problems I've solved have the lowest difficulty rating of 5%. The hardest one of I've solved is titled Su Doku and has a difficulty of 25%. I wrote a sudoku solver a while back, so all that was left for my solution was some basic glue code.

If you also like solving little puzzles, give Project Euler a try. Rosalind is another list of problems focused on bioinformatics, and Advent of Code is a nice, seasonal one. They're all pretty fun and might expose you to some new ideas.

Back in 2015, I discovered React and was looking for a project to stretch my understanding. Around that time, I downloaded a few IRC clients and didn't like any of them. This seemed like an opportunity to explore some new technologies while creating something I'd like to use.

The first commit shows its humble beginnings. It only handles a single IRC connection. The styles are in a single CSS file. It uses node-webkit instead of electron and flux instead of redux. It looks like, even with babel, I was calling React.createClass instead of defining JS classes. It was a different world back then.

Here's the earliest pic I could find.

I don't work on Lax with any consistency. Occasionally, I get inspired to add features or update the tech under the hood. For example, I started toying with Elm in 2017. I had written a lot of code using Redux, but using Elm's type system allowed me to really understand Redux. Later that year, I overhauled the entire project introducing Redux, testing reducers with Jest, and using Flow's type system. That pull request laid the foundation to handle multiple connections, which were introduced a few months later.

That work is all generally still in place today. Here's a screenshot at that time.

Around that time, more people started to pay attention to the project. These technologies are all buzzwords, so the traffic came naturally from Google searches. I started receiving issues and pull requests from other people, and one guy added dark mode. These moments felt motivating.

But overall, the repo serves more as a learning environment than anything, and the app itself suffers as a result. Longstanding issues, like recovering from network disconnection, stay open. The build system could use another overhaul – some shortcomings seen in that first commit are still in the app today. While much could be improved, I usually find myself chatting on Slack and Discord instead.

The future of Lax is uncertain! I'm intrigued by Tauri, but this issue lays out a plan that involves more stable technologies. Open issues include some bugs and many new features. If you're interested in any of this or have thoughts to share, write a new issue, and I'll be sure to respond. And please, give the repo a star – it would sure be embarrassing if it fell below 100!

Recent research from OpenAI has created a system called GPT-3 that has "learned to learn" tasks related to human language. While it was trained on a ton of data, it wasn't trained for a focused task. Instead, you provide a short description in English of what you would like it to do, or maybe just a few examples, and it immediately performs well on a range of tasks like simplifying legal documents and writing short stories.

Let's show it some rap lyrics and see if it's able to explain them in more detail.

Genius

Genius provides song lyrics, and users provide annotations to those lyrics in a Wikipedia-like fashion. The site was originally focused on rap lyrics, so we'll stick to those.

To start, I took a Drake song and grabbed a couple lines that already had good annotations. GPT-3 is given a short description of what's expected and a single example, with both the song lyric and the human-written annotation from Genius. It's then given another lyric, and hopefully it writes a description of that lyric.

The following is a conversation with an AI assistant, Genius. The assistant is insightful, clever, and a hip-hop head.

Drake: Tell Uncle Luke I'm out in Miami, too
Genius: Southern rap pioneer, former 2 Live Crew impresario and former Miami mayoral candidate Luther “Luke” Campbell recently put a few hip-hop personalities on blast for living in Miami while not giving back to the community. If they don’t change their ways by January 2012, Luke threatens to have their “Miami cards” revoked. Luke lost the election. The open letter mentions “Lil Wayne, DJ Khaled, Puff Daddy, and all their boys” – Drake apparently feels like he was worthy of inclusion by name as well.

Drake: Wrist bling, got a condo up in Biscayne
Genius:

GPT-3 is given the above text, and in a matter of seconds, it writes the following:

Drizzy has been co-owner of WAM, a Miami/Boca Raton development, since 2007. The downtown Brickell building is only 20 stories tall, with condos in the $700,000 to $1.2 million range. In January 2011, Drake purchased another condo in Miami’s Biscayne Boulevard. A “condo” is a type of building in which ownership shares in the structure provide access to an exclusive environment; as opposed to an apartment or single-family residence.

Incredible! It referred to Drake by a nickname, gave us some financial figures, and even defined "condo." You can compare it to the best annotation on Genius for that line.

Now, these lyrics are both by Drake, in the same song, and only a few lines apart. I really didn't know where Biscayne was located, but it likely benefits from the original line talking about Miami. We could give it more difficult examples to work with, but even these initial results should make you pause for a moment.

If you saw these sentences out of context, you would assume they were written by a human. Moreover you would have no reason to doubt what they said, but searching around the internet, I can't find anything tied to Drake called "WAM." While the sentences are well-formed and in a natural order, it lied to us right out of the gate!

To show it more variety, let's give it a classic example by one artist and see how it handles another artist. The text provided to GPT-3 is bold, including a two sentence description, a human-annotated lyric, and a second lyric on its own. GPT-3's output immediately follows.

The following is a conversation with an AI assistant, Genius. The assistant is insightful, clever, and a hip-hop head.

Lil Wayne: Bitch, real Gs move in silence like lasagna
Genius: When you pronounce “lasagna,” the G is silent (although it wouldn’t have the “yuh” sound at the end if the G wasn’t there). Real gangsters (Gs) move in silence too, i.e. they keep their hustles on the low.

Kanye: Mayonnaise colored Benz, I push Miracle Whips
Genius: “Miracle Whip” is a brand of mayonnaise. A Maybach is a Mercedes Benz. When mayonnaise comes out the top of the bottle it looks kind of white, like Miracle Whip. But I don’t think that’s what Kanye is talking about here. Instead, he’s referring to a custom paint job called “liquid white” (a.k.a. “mayonnaise white”).

This isn't quite what a human would write. I tried this one a few times, and it consistently seems focused on a Maybach for some reason. It doesn't seem to understand that "whip" refers to a nice car either. GPT-3 recognizes the basics of these lyrics, while the wordplay that ties the two lines together slips right past it.

Again, the bold text above is all it has to work with. It doesn't know I'm writing a blog post and has completely forgotten about the earlier Drake lyrics. I think it's interesting to compare the example its given and note how it mimicked the generous use of quotes and parentheses. In many ways, it does a great job of learning by example, but in other ways it misses the forest for the trees.

Let's try some more wordplay. In 2011, long before Childish Gambino was making soul/funk/psychedelia, he put out an album called Camp that's littered with puns. Here are some lines from Bonfire.

The following is a conversation with an AI assistant, Genius. The assistant is insightful, clever, and a hip-hop head.

Childish Gambino: Okay, it's Childish Gambino, homegirl drop it like the NASDAQ
AI: As of the song’s release, the NASDAQ (the electronic market, mainly for tech stocks) was dropping. Childish Gambino’s girl drops her ass low much like the NASDAQ drops (or has dropped). Of course, now that the tech sector is so frothy, this line has little resonance (too late, CG!).

Childish Gambino: In Adidas, with some short shorts, B-O-O all over me
AI: Childish has long lauded his affinity for Rod Lavers and often wears shorts of vintage nature whose hemline is way above the knees. B-O-O stands for Band of Outsiders, a male clothing line that makes ties. Boo is also a pet name for a woman, so the line is a double entendre.

Childish Gambino: My dick is like an accent mark, it's all about the over E's
AI: An accent mark, called a tilde, has the shape of an "n" with a bar over it. The line, then, is about Childish Gambino's dick, which means it’s a double entendre. The "n" stands for his penis and the bar represents the female pubic region. E’s stands for ecstasy. The line is a nod to rap group Bone Thugs-N-Harmony. They began rapping about their “Accent Marks” and celebrating excess in the 1995 song "East 1999 Eternal". This is also a reference to "The Whiteness Project," a series of videos produced by Complex Magazine on white privilege.

I'll give it some creativity points for this one. While it definitely missed the mark, it "wants" to find the double entendre. "[T]he bar represents the female pubic region" is accurate, but it doesn't grasp the "ovaries" homophone.

I also did some experiments with rhyming, to see if I could give it a leading line and it would complete the bar. The results weren't very exciting so I left them out of this post. Any wordplay involving how the word sounds, rather than the text itself, seems out of GPT-3's reach.

Finally, let's look at some well known Kanye lines. This time, it has a few examples to work with no but no leading description of what's expected.

Kanye: The plan was to drink until the pain over. But what's worse, the pain or the hangover?
Genius: Ye tries to block out the problems with drinking, but realizes delaying them will only make it worse. This is one of the most oft-asked questions of an addict when they reach the point of rock bottom. What causes them more physical and mental anguish? Continuing their addiction and dealing with the consequences, or dealing with the actual issues at hand without the use of a masking agent? This could be a double entendre in the line “The plan was to drink until the pain over”. This could be interpreted as pain being short for champagne, meaning he would drink until the champagne was gone.

Kanye: What you think I rap for, to push a fuckin' Rav 4?
Genius: He raps to ball hard, not to drive some shitty Toyota SUV. This line was inspired by a guy who was working on Kanye’s album in Hawaii who also drove Kanye around Hawaii in a Rav 4.

Kanye: Couldn't afford a car, so she named her daughter Alexis
Genius: She named her daughter “Alexis” so that she could still claim to own “a Lexus,” showing her materialistic desires outwinning her maternal love. In the seventh song of the album, “Jesus Walks” Kanye also talks about people stealing a Lexus. Saying she couldn’t ‘afford’ a car could be a reference to ‘a Ford,’ which is another popular car brand.

Kanye: "Oh my god, is that a black card?" I turned around and replied, "Why yes But I prefer the term African American Express"
Genius: Kanye compares himself to a Black Card, a type of American Express credit card given exclusively to people in the entertainment industry, but he calls it the "African American Express" instead to say that although he's rich, he still considers himself black and knows the history of blacks in this country.

It does okay on this one. These lines are all Kanye but from various songs and albums. Rap verses often focus on some theme(s), so with more of the song's surrounding lines, it could infer more from the given context.

Looking Forward

OpenAI is a company based in San Francisco, California, whose mission is to create Artificial General Intelligence (AGI) in a safe manner that benefits everyone. You've likely heard of AI, since even rapper Common is preaching about how AI empowers us, but the term AGI refers to something on par with human intelligence, as opposed to current AI software that only does one thing really well.

For example, the best chess, Go, and StarCraft players have all been beaten by AI. Rather than studying the masters and learning from their games, the AI is trained on many of years of gameplay in a short amount of time, allowing it to discover ever more powerful strategies on its own. Since the "training data" is generated on the fly while playing, there's essentially unlimited data to work with, and AI will continue to dominate more and more arenas where that holds true.

OpenAI's results on GPT-3 are astounding, not only because it can learn from a few examples but because it shows no signs of slowing down. It's estimated around $5 million was spent on just computing power to train this thing. While such an expense is outside of my budget, a tech giant like Google spends over $2 billion on research and development every month. They have likely already created more impressive technology behind closed doors.

Conclusion

GPT-3 generally writes sentences that make sense, although it doesn't always understand the true intent of the lyrics. It seems to be excellent at pulling in "facts" about the world that might be relevant, but it appears to struggle with wordplay.

Again the technological advance here is that the model was built for general language purposes and only applied to rap lyrics after the fact. OpenAI is sharing this with people to discover the full variety of tasks it can accomplish. On some writing tasks, it performs better than others. Some of its output is pretty indistinguishable from something written by a human, which is concerning when the Web is already overrun with clickbait and fake news. For a look at some poetry and a more in-depth analysis, check out Gwern's post on the topic.

I hope you found this enjoyable! Send me an email if you have any thoughts or would like me to try some other examples. I would love to automate the process and let people freely explore lyrics, but the Genius API doesn't appear to supply lyrics or annotations. Maybe someone at Genius will see this and can give me greater access!

The fact that a book is freely available might not be immediately apparent. In his post on software safety, Hillel Wayne mentions a book and says, "In the lower-left sidebar there’s an option to download the book for free. Most people miss that." Even seeing this message, it took a minute to find the download link – it's now behind the Open Access tab.

Some books are available as a single PDF which I prefer over the others that are often a collection of PDFs or HTML files. It takes a couple clicks to see if the book is a big PDF, and then the back button would take me all the way back to the first page.

Publishing these books for free is a tremendously generous act, but I was slightly frustrated by the website. I gathered all the direct links on a single page for quick browsing. Check out all the open access books from MIT Press.

Each of these orbs is a package that someone took the time write and publish. Zooming out such that all packages are within view reveals a unique shape for each package manager, reflecting the shape of the community.

Take a look at Bower, which aims to be "a package manager for the web." Having such a broad, inclusive goal, you'll see all kinds of variety in the packages, and you'll quickly find distinct communities around jQuery and AngularJS. You might also find smaller communities like Polymer and PureScript, disconnected from the broader community and hurtling off into space.

Elm is a small community with its own package manager. It aims to be "a delightful language for reliable webapps." That reliability comes from static types, which are also used by the language's tooling to enforce a great deal of homogeneity, in addition to their Design Guidelines which are "meant to promote consistency and quality across all Elm packages." We should expect something far more uniform than Bower.

In this post, I'll walk through the key steps in adding Elm's packages to Code Galaxies which include scraping the necessary package data, building the dependency graph, and positioning these packages in 3D space.

tl;dr: Explore all of Elm's packages.

Crawling Packages

Elm has an official package manager that is primarily used with commands like elm install and elm publish. Elm Packages also provides access to these packages and their documentation.

All packages are published with a JSON file describing the package and listing its dependencies. Prior to v0.19, this file was named elm-package.json, but now, every package is published with an elm.json. Here's an example of an elm.json file.

{
    "type": "package",
    "name": "brandly/elm-dot-lang",
    "summary": "Parse DOT Language files",
    "license": "BSD-3-Clause",
    "version": "1.1.3",
    "exposed-modules": [
        "DotLang"
    ],
    "elm-version": "0.19.0 <= v < 0.20.0",
    "dependencies": {
        "elm/core": "1.0.0 <= v < 2.0.0",
        "elm/parser": "1.0.0 <= v < 2.0.0",
        "hecrj/html-parser": "2.3.0 <= v < 3.0.0"
    },
    "test-dependencies": {
        "elm-explorations/test": "1.2.1 <= v < 2.0.0"
    }
}

Each dependency is listed with a range of supported versions ^[1]. Each package range can be resolved to a specific package version, and those packages have their own dependencies, forming a sprawling graph. Acquiring the elm.json or elm-package.json file from each and every package would provide full knowledge of this dependency graph.

The Elm Package website is open-source, and its server provides an API that responds with JSON. The /all-packages endpoint delivers details about the package registry including package names and published versions. In addition, adding ?elm-package-version=0.18 to the request retrieves packages for older versions of Elm. Finding unique package names in both lists results in a combined total of 2,123 packages.

The API responses are structured differently, but they both provide package names and a list of available version numbers for each package. To boost the size of the graph, every major version release of each package will be included in the final graph, and every node will be connected to a compatible version of each of its dependencies.

GitHub's API is used to download an elm.json file for a given package name and version. This works because every Elm package is first tagged and pushed to GitHub before getting added to the package manager.

const getFileAtVersion = async (repo, filename, version) => {
  const url = `https://api.github.com/repos/${repo}/contents/${filename}?ref=${version}&access_token=${token}`
  const res = await axios.get(url)
  return Buffer.from(res.data.content, 'base64').toString('utf-8')
}

const repo = 'brandly/elm-dot-lang'
const version = '1.1.3'
const elmJson = await getFileAtVersion(repo, 'elm.json', version)

// If it were an older package...
const elmPackageJson = await getFileAtVersion(repo, 'elm-package.json', version)

Every package, its major versions, and each of their package definitions are now within reach. The rest of the logic is the orchestration of these requests to download the files into ./packages, resulting in an organized tree.

$ tree packages 
packages
├── 0ui
│   └── elm-task-parallel@1.0.1.json
├── 1602
│   ├── elm-feather@1.0.2.json
│   ├── elm-feather@2.3.5.json
...
└── zwilias
    ├── elm-avl-dict-exploration@1.2.2.json
    ├── elm-bytes-parser@1.0.0.json
    ...
    ├── json-decode-exploration@6.0.0.json
    └── json-encode-exploration@1.0.0.json

814 directories, 3875 files

Due to how these files are laid out, those numbers at the bottom indicate that 814 unique accounts have published 3,875 major package releases.

Connecting the Dots

Code Galaxies is built on top of ngraph, a suite of graph-related tools. These tools help build a pipeline of sorts, taking the downloaded packages and transforming them into the format the app expects.

With the downloaded JSON files, each file represents a node in the graph and contains a list of dependencies, linking the node to some number of other nodes. This information needs to be plugged into ngraph. I'll highlight the interesting bits.

First, the list of files is piped into a script.

$ find ./packages -name '*.json' | node build-graph.js

find spits out a list of filenames, each on their own line. This list is consumed by the script, and the lines are chopped up into an array of file paths.

const fs = require('fs')

const filePaths = fs
  .readFileSync(0)
  .toString()
  .trim()
  .split('\n')

These files are read into memory and looped over, building up the graph data structure.

const createGraph = require('ngraph.graph')
const graph = createGraph()

// For each package
const node = `${package.name}@${package.version}`
graph.addNode(node)

// For each dependency in a package
graph.addLink(node, dependency)

At this point, graph holds the connections between all available Elm packages!

Moving In

In the app, each node sits somewhere in space. These locations are calculated by simulating a physical system, with a force pushing nodes away from one another, like reverse gravity, while the links in the graph tie dependent nodes together. The outcome is that packages with common dependencies end up near one another.

The app isn't a live simulation however. The positions are calculated upfront, and these fixed values are used in the app. Calculating these positions is once again made simple with ngraph.

const layout = require('ngraph.offline.layout')(graph)
layout.run()

const save = require('ngraph.tobinary')
save(graph, {
  outDir: './data'
})

This writes a variety of files to ./data describing every detail about the graph, but the app only cares about a few of them: labels.json, links.json, and positions.json. Feeding these files into Code Galaxies reveals the relationship between every published Elm package. (On mobile, hold two fingers to zoom out.)

What a view! Every Elm package depends on elm/core (formerly elm-lang/core) which forms the backbone of this structure. The core has been updated as the language has evolved creating a series of clustered packages like moments on a timeline. Some rare packages are tied to multiple versions of this core chaining the clusters together. Each cluster is bigger than the last as the Elm community continues to grow!

Within a cluster, the core is the dominant node alongside other sizable nodes like elm/html, elm/json, and elm/browser. These general packages dwarf the size of most other packages. Due to Elm's focus on building web apps, this is no surprise.

Elm strives for consistency in everything from API design to documentation formatting, encouraging package authors to publish general, stable solutions for well-defined problems. As a result, packages don't often "compete" with one another, and the community doesn't fracture easily. This, combined with the common core package, results in the latest cluster forming a fairly uniform ball.

Conclusion

The Elm Package API provides a complete list of packages, and the mapping between an Elm package and a GitHub repo supplies the necessary JSON package definitions. The data is large enough to show something interesting, but still small enough that it can be explored with some for loops. ngraph handles all the graph-related details.

The resulting visualization looks great and is fun to explore! The structure reflects the history of major Elm updates and the growing community around it. The other package managers likely tell their own stories as this is a great way to explore graphs that should be applied to other datasets.

Take a look for yourself, and let me know if you find anything interesting!

Special thanks to Andrei Kashcha for creating ngraph and Code Galaxies.

View the full source code and the resulting visualization featured in this post.

Notes

When a new programmer is getting started, they don't have the bearings they need to know where to search for answers. When someone shows them a solution, it's hard for them to hold on to the answer, since they haven't built a framework in their mind for thinking about programming.

Programming knowledge seems to fall into a few categories. I think recognizing these categories early on helps a young programmer organize the things they're learning.

Learn Syntax

This is probably how someone who doesn't write code views programming. You learn what these symbols mean. You type them in bright colors on your computer. You're a programmer.

Learning systems, like Codecademy, seem to handle this step of the learning process well. They demystify some syntax and show you relatively simple examples, but they don't quite give you enough to allow you to go independently start writing software. I've seen several people go through long stretches of learning like this, but they still feel lost.

However, these systems are still very valuable. The more comfortable one can become at looking at a block of code and understanding what the syntax means, the closer they are to writing software. For this reason, I think beginners should start with just one language and learn as much about that language as possible, instead of gaining cursory knowledge of a list of languages.

For an experienced software developer, the raw syntax, in a language they're fluent in, is something that's rarely even thought about. The same way one's able to read a book and see the fantasy world the author's describing, a well-written program should, when read by a fluent developer, create rich imagery in the reader's mind. What they're imagining is nothing like syntax, but it's an abstract view of how data is flowing through the program, which brings me to the next topic of learning.

Learn How Data Flows

All software programs take some input data, manipulate it, and output some result. Input data may come from a file, a web server, or direct user input. Similarly, the output may be written to a file, sent to a server, or simply displayed in front of the user.

For a simple software program, these three steps will be small and simple, e.g. read data from a file, combine some values, and output the combined values to the user. As a software developer learns more, they'll be able to handle data from multiple locations, perform complex manipulations, and output multiple results to multiple locations.

The main role of a software developer is to leverage the syntax of their language of choice to manage the vast complexity of the software they write. This is the hardest part of programming and something that programmers continue to learn, no matter how many years they've spent programming.

Certain languages and tools are more fit for certain kinds of manipulations. For a beginner, they need to first learn one language well, so they can discover what it's good for, before branching out and discovering new tools.

Nowadays, programmers don't fly solo. No matter what language they're using, they're standing on the shoulders of the giants before them who built these languages and designed these toolsets.

Learn the Context

The software one writes executes against some compiler or interpreter. Usually, this execution context provides information about the computer the code is running on, access to the filesystem, access to the internet via HTTP, etc.

Depending on the language and the environment that language is executing within, these contexts can vary greatly. Initially, programmers will discover this context one Google search at a time, but eventually, they'll start to be able to visualize the context itself. A more experienced programmer will actually browse the documentation for their context of choice and further discover more details about their tools.

Although I've only used "context" to mean the literal execution environment, I think it also includes third-party libraries from sites like GitHub, which provide readily available, open source code anyone can use. Knowledge of these free libraries can greatly increase the efficiency and capability of a software developer.

Learning programming is hard. Building a foundation of knowledge takes time. Grouping one's learning into syntax, data flow, and context can help them build a sturdy foundation and grow their skills more quickly.

However, git isn't known for its beautiful interface. Certain commands are oddly named, have a long list of options, and are capable of doing multiple, seemingly unrelated actions.

There is hope. Git can learn new commands, allowing you to define a more convenient interface that fits nicely into your workflow. Lengthy commands that are difficult to remember can be given simple names, and common commands that are used frequently can be aliased with shortcuts. After hours at a keyboard, those keystrokes will really add up, man.

I know how exciting this sounds, so let's get to it.

show me the money

Remember how I mentioned commands aren't always easy to remember? Let's look at how to define your first alias.

$ git config --global alias.st 'status -sb'

Neat. Take a moment for that to sink in, and try running git st on one of your repos. If we had left out the --global flag, this command would only work in your local repo, but it seems more likely that you would want this shortcut for all your projects.

Now, when we type git st, git will do the exact same action as if we had done git status -sb. This command is one of my favorites, since it can be typed more quickly than git status and the output is a bit nicer.

.gitconfig

Despite popular belief, computers are not magical devices. When we teach git a new trick, it needs to hold onto that information somewhere. In fact, it does so in a small file. Let's go track it down.

$ cd ~
$ ls -a

At this point, I'm sure you're looking at a number of files, but the one we care about is called .gitconfig. If you open that file in your favorite text editor, you should at least see a couple lines that look like this.

[alias]
  st = status -sb

We could have manually edited this file, and git would have been perfectly happy. In fact, let's try that out.

Right below the st definition, scribble down a line like this and save the file. Make sure to use a single tab character for the indentation.

[alias]
  st = status -sb
  co = checkout

Now, when you run something like git co master, git will peek at this file, find out you really meant git checkout master, and take care of business.

more examples

[alias]
  cob = checkout -b
  cm = commit -m
  di = diff
  purr = pull --rebase
  who = shortlog -n -s --no-merges
  lg = log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit

The first few just save keystrokes, but those last two are a bit fancier. I learned about git lg over here, and it's much nicer than a standard git log. I didn't even know about git shortlog until I discovered the git who alias, thanks to thoughtbot.

Personally, I find these aliases useful, but don't be afraid to write your own. Take the things I've taught you and build a deep relationship with git that stands the test of time.

I decided to the bite the bullet and just deploy something. I wanted to get up and running quickly but leave room for plenty of control and customization later. Let's take a quick look at where I landed.

Ghost

Ghost is "just a blogging platform." It seems like a more contemporary WordPress, and it runs on Node.js which is good for me, since I'm more familiar with JavaScript than most things. I'm also writing this post in Markdown, which I enjoy.

Ghost has a few paid options where they'll host an instance for you, but I ended up deploying it to DigitalOcean. They make it stupid simple to get started, but I can still ssh in and do whatever I please.

After searching for "ghost themes," I found an abundance of options. Some are free. Some are not. It was quite easy to install themes, so I tried a few out before sticking with a free one called Crisp, by Kathy Qian. It seemed like a simple jumping-off point that I could tweak to my liking.

It turns out it's far more difficult to write a quality blog post than it is to start a blog, so we'll see what happens next.