Ian Henry

Okay. We aren’t actually done with Chapter 5 yet. We got through the bulk of it, but we still have a few short sections to go.

Oh gosh. I’ve been really putting off chapter five because, well, because look at it. It’s massive. It’s intimidating.

But as I recall from the Nix manual, the reference sections do not make the most exciting reading, but they are usually very educational. So I can’t just skip them.

Even if I really want to skip them.

We’ve had two chapters covering two different ways to override packages, but we still haven’t actually been able to override any packages. But this chapter is about overriding, so maybe it will tell us how to use the features from chapters 2 and 3?

This is a very curious presentation order.

This is my first encounter with the term “overlays.” The manual describes it thus:

Overlays are used to add layers in the fixed-point used by Nixpkgs to compose the set of all packages.

Any questions?

This is a very long guide about setting up tmux “from scratch,” which is to say without any of the default keybindings or any default behavior. It’s mostly an excuse to demonstrate a simple ~/.tmux.conf, and to explain how you can set up tmux to do exactly what you want it to, and nothing more.

I like this, because it turns my ~/.tmux.conf into documentation about what my tmux can do, and how it works. If something isn’t in that file, it doesn’t exist. If I forget how to do something, I can just look at that file. I don’t need to remember any tmux defaults; I don’t need anything except my little file.

This is a fancy thing that iTerm can do, somewhat invasively, and Terminal.app can do, somewhat transparently, and if you already know how to do this then just keep doing your thing and don’t worry about it.

This post is going to show you how to do it in tmux, because tmux is great and it’s not coupled to your choice of terminal emulator and it’s a cool superpower to add to your toolkit.

But it’s not trivial to do in tmux. It took me a while to figure it out. Which is why you’re looking at a blog post, and not a code snippet.

Look, you already know that tmux lets you split your terminals or whatever. You know it lets you maintain remote sessions like a supercharged nohup. Neither of these features are very interesting, if you’re using a modern terminal emulator (or a tiling window manager) and doing your development locally.

So you’ve never tried tmux. People raved about it, but you didn’t listen: you’re not in the target audience. tmux is not for you.

I am projecting, obviously: that was my impression of tmux, a few years ago. Before I tried it. Before I learned how wrong I was.

Well, I took a bit of a break from learning Nix, but I’m back to continue my journey through the documentation.

I already read the whole Nix manual, so now it’s time read through the Nixpkgs manual. Wish me luck.

Given the contents of my bar:

$ cat facts/bar
brandy
dry vermouth
lemon
light rum
lime
orange liqueur
reposado tequila
sugar

And my cocktail recipe book:

$ head facts/recipes
martini <- london dry gin
martini <- dry vermouth
daiquiri <- light rum
daiquiri <- lime juice
daiquiri <- simple syrup
margarita <- blanco tequila or reposado tequila
margarita <- lime juice
margarita <- orange liqueur
margarita <- lime wedge
...

What cocktails can I mix?

$ cat results/mixable
daiquiri
margarita
sidecar

Gosh, that’s not very many. What could I add to my bar to expand my options?

$ cat results/shopping-list
london dry gin -> gimlet
london dry gin -> martini
champagne -> airmail
cognac -> between-the-sheets
sherry -> sherry-cobbler
rhum agricole -> ti-punch

We open on a chat conversation that I had with my good friend and former colleague “Doug,” in which we were discussing my experience reading through the Nix manual.

 ian: there were certain things that i wanted to learn how to do
 ian: and i still don't really know how to do them
 ian: like
 ian: it seems like
 ian: you should just have a file
 ian: called "ian.nix"
 ian: where you write down the things you want
 ian: and then there should be a way to say "install exactly this set
      of things"
 ian: but there isn't
 ian: so i still want to figure out how to write that
 ian: anyway

It’s been several days since I reinstalled a bunch of stuff with Nix instead of Homebrew, and so far everything has been fine. I mean, the software I installed, like, works the same. As far as I can tell.

But I realize that I should probably update my packages, and see if there are any juicy new bytes to keep my hard drive entertained.

I really didn’t expect that this would be worthy of a blog post but, well, here we are: my first upgrade. Attempt.

In my last post, I tried to install Mercurial, and it didn’t go well.

Solemn music plays over this black and white flashback:

Okay, break’s over.

I don’t feel like I know enough about Nix to manage my own build dependencies with it, but I do feel like I know enough to use Nix as a simple package manager. I use Homebrew on my laptop, and at this point I definitely know more about Nix than I do about Homebrew.

Why would I switch away from Homebrew? Mostly because I think it will be educational. I don’t really have anything against Homebrew. It works. It has a lot of the packages I want. It does break more often than I’d like – not, like, often, but any time I go more than a year or so without using a particular computer I know that I’m going to return to some bizarre Ruby error that I have to spend half an hour figuring out before I can do anything.

And there’s no way that Nix would ever play me like that.

Now that I’ve reached the end of the manual, I want to reflect a little bit on my journey so far.

What have I learned?

I have learned a lot, really.

But I feel like I haven’t learned enough to like… use Nix.

Let’s talk about nix.conf.

This is another reference section – seems like we’re going through all the options. I’m going to read this list and make notes in anything that sounds interesting.

Oooookay.

I said I was gonna read the manual, right? I’ll do it. I’ll read it. I already read all those functions, didn’t I? It’s time for Part VI: Command Reference.

~/sd is my script directory. It looks like this:

$ tree ~/sd
/Users/ian/sd
├── blog
│   ├── preview
│   └── publish
├── book
│   ├── open
│   ├── pdf
│   ├── progress
│   └── typeset
├── cat
├── dim
│   └── visualize
├── edit
├── git
│   └── ugh
├── help
├── new
├── nix
│   ├── diff
│   ├── info
│   └── sync
├── tmux
│   ├── init
│   └── restore
└── which

sd is a command on my PATH. It dispatches its arguments to my script directory.

$ sd blog publish

Will run the script ~/sd/blog/publish.

This sounds like a dumb way to save myself having to type a few characters. Which it is. But it’s also slightly more than that:

Oh gosh oh gosh. I don’t know if I’m ready.

It’s time for Part V: Advanced Topics.

Ooooookay. This is a really, really long section. This is like… a reference. Dang. Okay.

The section we’ve all been waiting for…

Okay! Chapter 15 is finally going to teach us the language we’ve been using for the past several chapters. I’m excited.

The Nix expression language is a pure, lazy, functional language.

I didn’t know it was a pure language.

We got to Part IV! We have learned everything we need to know about Package Management and now get to learn about Writing Nix Expressions.

I have to point out that this “part” basically starts out with a link to a whole other manual. My goodness. I don’t know if I can type up every thought that goes through my head as I read two manuals. I’ve gotta sleep at some point.

So apparently you can move packages around from one machine to another very easily.

Neat? I guess?

I turn my eyes to Chapter 12, and learn:

A Nix channel is just a URL that points to a place that contains a set of Nix expressions and a manifest.

Neat. What does that mean?

I remember from using Nix long ago that when you “uninstall” a package, you don’t really “uninstall” it – you just remove the symlinks to it in your ~/.nix-profile/bin directory, so it no longer appears on your PATH.

Now I know that it doesn’t “remove symlinks” but rather “builds a new user environment and changes the ~/.nix-profile symlink to point to the new generation’s symlink to that user environment.” But you know, effectively the same thing. So there is a separate operation to actually delete those files, and remove the old generations.

Let’s find out more.

Chapter 10 describes the directory structure of ~/.nix-profile, and explains how rollbacks work.

The chapter starts with a sort of complicated drawing of multi-user directories with like default profiles and custom ones and it’s way too much for me to follow and I don’t really care. I think it’s easier to just look at some examples on my current system, and imagine how I would generalize them to multiple users.

Part III deals with using Nix as a package manager. The quick start guide already gave us a brief introduction to this, but now we get to go into detail.

I start reading through the Nix manual. I won’t quote it in its entirety like I did in the glossary. But I will any time I want to highlight something or I have a question or I don’t understand something.

I decide to start learning Nix by reading through the glossary. I don’t expect to fully understand every definition – I expect it will take first-hand experience to really understand these terms – but I think it will be a useful primer before I read the documentation. At least I will recognize when I encounter a Nix-specific term.

As I said in the introduction to this series, I’m not coming to Nix completely blind. I used Nix for a brief period five years ago, but I basically haven’t touched it since then.

So the first thing I did was try to write down everything I could remember about Nix, as I think that it’s pretty important context that will give me an advantage understanding some concepts. Mostly I did this for myself: it was nice to think back on what I had had trouble with back then, and what I wanted to make sure I understood this time around.

Five years ago, I migrated my VPS from Arch Linux to NixOS.

I had no idea what I was doing. I had never used Nix before. I thought I could figure it out.

Five years later, I’m still running NixOS. And I still have no idea how it works.

This is an adaptation of a talk that I gave a few times to graduates of the Flatiron School as part of Trello’s fellowship program.

This is a softer post than my “usual” fare. This post is not about a particular challenge or task; it’s about programming for the sake of programming. It’s a self-indulgent affair. You have been warned.

Look at this program:

main = do
  contents <- readFile "foo.txt"
  writeFile "foo.txt" ('a':contents)

What does it do?

This post started out as “Applicative Functors for Non-Haskell Developers.”

That was an ambitious title.

Instead, it’s turned out to be something more like “Applicative Functors for Curious Haskell Novices,” or, more accurately, “Applicative Functors for Ian Henry, Two Years Ago.” But that’s not as catchy.

Specifically, this post assumes the following prior Haskell knowledge:

We all know the absolute minimum every software developer must know about Unicode. We aren’t bad citizens of the internet, spreading malice and encoding errors willy-nilly around the world. We’re good people, just trying to get by.

But knowing the minimum is starting to bother us. And the more we think about UTF-8 and text encoding, the more we realize that we don’t “get it” at a messy, squishy level. We’ve read about it, sure, but we’ve never actually wrapped our hands around it and felt the blood pump through its veins.

So that’s what we’re going to do in this post: grab UTF-8 by the bytes and squeeze some real understanding out of it.

Let’s do something extremely simple:

We’ve got a view controller, it has a user, the user’s got a username, and we want to show that in our navbar title. With an @ in front, because that’s what all the cool kids do these days. Simple, right?

- (void)viewDidLoad {
    [super viewDidLoad];
    self.title = [NSString stringWithFormat:@"@%@", self.user.username];
}

Yep! That’s all it takes. As long as the username never changes.