My last job had a codebase large enough (~50M LOC) that there were always large-scale refactors in flight, which was a new experience for me.

One thing this article doesn’t specifically call out is that any kind of dependency update or replacement, whether an internal or external library, is a large-scale refactor. You benefit enormously if you can do this incrementally as the author describes instead of a flag day or One Giant Merge to update all uses. A counterintuitive result is that replacing one dep with another (foolib -> barlib) is easier than updating one (foolib 1 -> foolib 2)! Most languages do not allow you to depend on multiple versions of a package and have different sections of your codebase call different versions. Sometimes internally-maintained dependencies will rename just to get around this limitation.

There’s a style of managing dependencies that mandates you must wrap usage of libraries or APIs. Rather than calling Foolib::Thing.new, you’ll create your own FooThing (maybe using the decorator or facade patterns) and that class is the only place allowed to import from or call into foolib. With less exposure of foolib, it’s easier to create internal documentation, audit or control usage, or replace foolib with barlib. I don’t find this a cost worth paying in smaller codebases, but easily worth it in large ones.

Part of why it’s worthwhile is that it gives you two new methods for dealing with dependency updates. First (hopefully), you have a single codesite that uses foolib so a single team can make a small change to update foolib. Or second, if there are extensive changes that mandate changes at callsites, you can rename FooThing to FooThing1 (usually an easy, if large diff), introduce FooThing2 with the new API, and then use a process like the one this article describes to make that change incrementally to the entire codebase. Either you update foolib at the start of this process and FooThing1 maps old usage to new, or FooThing2 maps new usage to old and you bump foolib at the end. This process works quite well, whether foolib is an internal or external dependency. Whereas, say, emailing all-dev@example.com a link to the foolib release notes and dictum that on some particular date that all foolib usage must be updated will inevitably produce significant internal discord and never, ever an on-schedule completion. An even worse and more common failure mode for internal libs is to quietly mark foolib deprecated and direct people to rewrite to barlib when they show up with urgent questions about foolib during an outage - but of course good sense and steps 6-8 of the process described in the post would avoid such an outlandish footgunning.

(This post was originally a comment on Lobste.rs but then I realized it’s a nice excuse to break the 5.5 year dry spell here.)

Provision

I went with the lowest tier, currently 1.25 GiB RAM, 15 GiB Disk for $5/month. I’m only running weechat for irc/twitter/fediverse/slack and some miscellaneous small things. For “pre-installed distribution” I chose “None (HVM)”.

Netboot to start install

I ssh’d into the management console, ssh [hostname]@[hostname].console.xen.prgmr.com

• 6 bootloader
• 4 netboot installer, pick nixos
• 0 twice for main menu
• 4 to power off
• 2 to start (see “Booting” below)
• 1 to log in as root with no password (relax, ssh is off)

Partition

Surprisingly, the included 1.25 GB of RAM was not enough to run some nix commands. I had to back up and recreate the box with some swap space. I didn’t think too hard about it, just guessed at 2 GB and it worked OK. [2018-07-09: Vaibhav Sagar suggested this is probably this known bug.]{.marginnote .update}

` gdisk /dev/xvda`{lang=”bash”}

` o to create gpt`{lang=”bash”}

n to create swap partition{lang=”bash”}

Command (? for help): n Partition number (1-128, default 1): 1 First sector (34-31457246, default = 2048) or {+-}size{KMGTP}: Last sector (2048-31457246, default = 31457246) or {+-}size{KMGTP}: +32M Current type is 'Linux filesystem' Hex code or GUID (L to show codes, Enter = 8300): EF02 Changed type of partition to 'BIOS boot partition'{lang=”bash”}

Command (? for help): n Partition number (2-128, default 2): First sector (34-31457246, default = 67584) or {+-}size{KMGTP}: Last sector (67584-31457246, default = 31457246) or {+-}size{KMGTP}: -2G Current type is 'Linux filesystem' Hex code or GUID (L to show codes, Enter = 8300): Changed type of partition to 'Linux filesystem'{lang=”bash”}

Command (? for help): n Partition number (3-128, default 3): First sector (34-31457246, default = 27262976) or {+-}size{KMGTP}: Last sector (27262976-31457246, default = 31457246) or {+-}size{KMGTP}: Current type is 'Linux filesystem' Hex code or GUID (L to show codes, Enter = 8300): 8200 Changed type of partition to 'Linux swap'{lang=”bash”}

w to write and exit{lang=”bash”}

mkswap -L swap /dev/xvda3{lang=”bash”}

swapon /dev/xvda3{lang=”bash”}

mkfs.ext4 -L root /dev/xvda2{lang=”bash”}

` {lang="bash"}mount /dev/xvda2 /mnt `{lang=”bash”}

Configuring nix

I generated the initial config and added a few prgmr-specific tweaks:

` nixos-generate-config –root /mnt`{lang=”bash”}

cd /mnt/etc/nixos{lang=”bash”}

` {lang="bash"}vi configuration.nix `{lang=”bash”}

Here’s my tweaks:

` boot.loader.grub.device = “/dev/xvda”`{lang=”nix”}

` # prgmr console config: boot.loader.grub.extraConfig = “serial –unit=0 –speed=115200 ; terminal_input serial console ; terminal_output serial console”; boot.kernelParams = [“console=ttyS0”];`{lang=”nix”}

environment.systemPackages = with pkgs; [ bitlbee tmux weechat wget vim ];{lang=”nix”}

services.openssh.enable = true;{lang=”nix”}

networking.firewall.allowedTCPPorts = [ 22 ];{lang=”nix”}

sound.enable = false; services.xserver.enable = false; services.openssh.enable = true;{lang=”nix”}

` {lang="nix"} users.extraUsers.pushcx = { name = “pushcx”; isNormalUser = true; extraGroups = [ “wheel” “disk” “systemd-journal” ]; uid = 1000; openssh.authorizedKeys.keys = [ “[ssh public key here]” ]; }; `{lang=”nix”}

Then I ran nixos-install to install the system.

Booting

The NixOS manual says you should be able to run reboot to boot to the new system, but something in xen doesn’t reload the new boot code and I got the netboot again rather than the new system. After talking to prgmr I found it worked if I pulled up the management console and did:

• 6 -> 1 boot from disk
• then 4 to fully poweroff
• then 2 to create/start

After this I had a running system that I could ssh into as a regular user.

Prgmr donates hosting to Lobsters, but because Alan configured the hosting, this was my first time really using the system. It was painless and getting support in #prgmr on Freenode was comfortable for me as a longtime IRC user. I liked them before, and now I’m happy to recommend them for no-nonsense VPS hosting.

Nix/NixOS

I did this setup because I’ve been meaning to learn nix (the package manager) and NixOS (the Linux distribution built on nix) for a while. As I commented on Lobsters, they look like they didn’t start from manual configuration and automate that, they started from thinking hard about what system configuration is and encoded that. (The final impetus was that I ran out of stored credit at Digital Ocean, hit several billing bugs trying to pay them, and couldn’t contact support - six tries in four mediums only got roboresponses.)

The NixOS manual is solid and I had little trouble installing the OS. It did a great job of working through a practical installation while explaining the underlying concepts.

I then turned to the Nix manual to learn more about working with and creating packages and failed, even with help from the nixos IRC channel and issue tracker. I think the fundamental cause is that it wasn’t written for newbies to learn nix from; there’s a man-page like approach where it only makes sense if you already understand it.

Ultimately I was stopped because I needed to create a package for bitlbee-mastodon and weeslack. As is normal for a small distro, it hasn’t packaged these kind of uncommon things (or complex desktop stuff like Chrome[2018-07-16: I’ve learned that Nix does have a package for Chrome, but it doesn’t appear in nix-env searches or the official package list because it’s hidden by an option that is not referenced in system config files, user config files, the NixOS Manual, the Nix Manual, the man page for nix-env, the package search site, or the the documentation of any other tool it hides packages from.]{.marginnote .update}) but I got the impression the selection grows daily. I didn’t want to install them manually (which I doubt would really work on NixOS), I wanted an exercise to learn packaging so I could package my own software and run NixOS on servers (the recent issues/PRs/commits on lobsters-ansible tell the tale of my escalating frustration at its design limitations).

The manual’s instructions to build and package GNU’s “hello world” binary don’t actually work (gory details there). I got the strong impression that no one has ever sat down to watch a newbie work through this doc and see where they get confused; not only do fundamentals go unexplained and the samples not work, there’s no discussion of common errors. Frustratingly, it also conflates building a package with contributing to nixpkgs, the official NixOS package repository.

Either this is a fundamental confusion in nix documentation or there’s some undocumented assumption about what tools go where that I never understood. As an example, I tried to run nix-shell (which I think is the standard tool for debugging builds but it has expert-only docs) and it was described over in the Nixpkgs Manual even though it’s for all packaging issues. To use the shell I have to understand “phases”, but some of the ones listed simply don’t exist in the shell environment. I can’t guess if this a bug, out-dated docs, or incomplete docs. And that’s before I got to confusing “you just have to know it” issues like the src attribute becoming unpackPhase rather than srcPhase, or “learn from bitter experience” issues like nix-shell polluting the working directory and carrying state between build attempts. (This is where I gave up.)

I don’t know how the NixOS Manual turned out so well; the rest of the docs have this fractal issue where, at every level of detail, every part of the system is incompletely or incorrectly described somewhere other than expected. I backed up and reread the homepages and about pages to make sure I didn’t miss a tutorial or other introduction that might have helped make sense of this, but found nothing besides these manuals. If I sound bewildered and frustrated, then I’ve accurately conveyed the experience. I gave up trying to learn nix, even though it still looks like the only packaging/deployment system with the right perspective on the problems.

I’d chalk it up to nix being young, but there’s some oddities that look like legacy issues. For example, commands vary: it’s nix-env -i to install a package, but nix-channel only has long options like --add, and nix-rebuild switch uses the more modern “subcommand” style. With no coherent style, you have to memorize which commands use which syntax - again, one of those things newbies stumble on but experts don’t notice and may not even recognize as a problem.

Finally, there’s two closely-related issues in nix that look like misdesigns, or at least badly-missed opportunities. I don’t have a lot of confidence in these because, as recounted, I was unable to learn to use nix. Mostly these are based on my 20 years of administrating Linux systems, especially the provisioning and devops work I’ve done with Chef, Puppet, Ansible, Capistrano, and scripting that I’ve done in the last 10. Experience has led me to think that the hard parts of deployment and provisioning boil down to a running system being like a running program making heavy use of mutable global variables (eg. the filesystem): the pain comes from unmanaged changes and surprisingly complex moving parts.

The first issue is that Nix templatizes config files. There’s an example in my configuration.nix notes above: rather than editing the grub config file, the system lifts copies from this config file to paste into a template of of grub’s config file that must be hidden away somewhere. So now instead of just knowing grub’s config, you have to know it plus what interface the packager decided to design on top of it by reading the package source (and I had to google to find that). There’s warts like extraConfig that throw up their hands at the inevitable uncaptured complexity and offer a interface to inject arbitrary text into the config. I hope “inject” puts you in a better frame of mind than “interface”: this is stringly-typed text interpolation and a typo in the value means an error from grub rather than nix. This whole thing must be a ton of extra work for packagers, and if there’s a benefit over vi /etc/default/grub it’s not apparent (maybe in provisioning, though I never got to nixops).

This whole system is both complex and incomplete, and it would evaporate if nix configured packages by providing a default config file in a package with a command to pull it into /etc/nix or /etc/nixos for you to edit and nix to copy back into the running system when you upgrade or switch. This would lend itself very well to keeping the system config under version control, which is never suggested in the manual and doesn’t seem to be integrated at any level of the tooling - itself a puzzling omission, given the emphasis on repeatability.

Second, to support this complexity, they developed their own programming language. (My best guess - I don’t actually know which is the chicken and which is the egg.) A nix config file isn’t data, it’s a turning-complete language with conditionals, loops, closures, scoping, etc. Again, this must have been a ton of work to implement and a young, small-team programming language has all the obvious issues like no debugger, confusing un-googleable error messages that don’t list filenames and line numbers, etc.; and then there’s the learning costs to users. Weirdly for a system inspired by functional programming, it’s dynamically typed, so it feels very much like the featureset and limited tooling/community of JavaScript circa 1998. In contrast to JavaScript, the nix programming language is only used by one project, so it’s unlikely to see anything like the improvements in JS in last 20 years. And while JavaScript would be an improvement over inventing a language, using Racket or Haskell to create a DSL would be a big improvement.

These are two apparent missed opportunities, not fatal flaws. Again, I wasn’t able to learn nix to the level that I understand how and why it was designed this way, so I’m not setting forth a strongly-held opinion. They’re really strange, expensive decisions that I don’t see a compelling reason for, and they look like they’d be difficult to change. Probably they have already been beaten to death on a mailing list somewhere, but I’m too frustrated by how much time I’ve wasted to go looking.

I’ve scheduled a calendar reminder for a year from now to see if the manual improves or if Luc Perkins’s book is out.[2018-08-09: I wasted another two days trying Nix from the other direction. Rather than build up from the basics I tried to start from the top down and create a “Hello World” Rails app. It’s hard to tell around the bugs and docs, but I’m pretty sure it’s not possible to run a Rails app on NixOS.

2019-12-01: New attempt. Got an incorrect error message that /sbin/bash didn’t exist. Paved and reinstalled, then tried to build a Rails demo but I got a useless error message when it failed to install 1password (!?). The two errors came while pasting directly from the install docs and I was told “lmk when you figure out which command you were just calling wrong”. The documentation’s first example is still broken and following install steps invariably leads to errors. I’m sick of being told it’s my fault nix doesn’t work and I’m giving up on it. ]{.marginnote}

1. Yes Take-backsies

We’re playing for the fun of learning new games and competing. If you make a mistake and we can unwind it, you can take it back and do what you meant to do or realize you should have done.

We don’t do take-backsies of things we can’t easily and fairly unwind. For example, in Risk, if you roll the dice to attack another player’s army and get wiped out, well, that’s not fair to unwind. Similarly, if you learn hidden information like turning over the next card on the deck, we can’t make everyone forget that (but mayyyybe if it’s someone’s first time playing a game).

Making mistakes is a normal part of learning. By helping keep them cheap and emphasizing that it’s socially rewarded to admit and correct them, everyone learns and plays better, and gets to relax and enjoy themself more. Games are fun because they’re an exercise in trust as much as exercise in formal systems.

We very often have players with uneven experience and take-backsies helps the newbies get into a game and keep the moderately-experienced competitive with the experts. We encourage suggestions and polite criticism of in-progress mistakes, too. When learning a complex game it’s hard to recognize the legal moves available and what their tradeoffs might be. So when someone looks particularly stumped, it’s normal to hear something like “Sooo... it looks like you have five or maybe six things you could do here, depending on what’s in your hand?” to offer help.

Suggestions show up even with competitive, experienced players, in part because some of us are so competitive we wrap around into helping our opponents make the best moves for their strategies so that we’re ourselves pushed into improving our own play. Suggestions aren’t a rule because some people don’t like hearing them and it’s more common in competitive play to want opponents to make mistakes, but I wanted to go into it because it’s foundational to the Yes Take-Backsies rule.

2. Public Stays Public

Information that’s revealed during gameplay stays public information and can be reviewed at any time unless doing so severely inconveniences the flow of gameplay.

What this means in practice is cards get discarded face-up and spread out for anyone to look through, or other things that have been played can be reviewed. The limit is that we might run out of table space or it would be distinctly un-fun to dig through that many cards, but when there’s that much information laying around it’s probably not particularly important what’s been played.

For example, The Great Dalmuti is a light trick-taking card game that’s a longtime favorite. Players play cards to try to empty their hands before everyone else, and between hands they shift to sit in the order they finished in to get benefits for the next hand. The last player is punished with the chore of clearing away the cards from each trick (and they have some other chores) so we task the next-to-last player. Instead of the game rule that all played cards are flipped face-down, our house rule is to arrange the best six ranks (numbered 1-6 of the deck’s 12 ranks) face-up along the side of the table. We don’t do this for ranks 7+ to balance the work vs how little strategy is at work in high cards (>85% of the time the correct play is “dump any of them at first opportunity”). This has been a big success. Beginners graduate from learning the rules to start exercising strategy in 2-3 hands instead of 5-6 hands, experts can experiment more effectively, and everyone’s happier not trying to remember “wait... did I see all of the threes, or just two of them?”

Information that’s derivable from public information is also public. In Acquire every player starts with the same amount of money and buys and sells stock in public transactions... but the rulebook suggests keeping it secret to make the game “even more challenging”. Arithmetic is not a fun game, it is a chore.

These “memory subgames” crop up all over, are stressful and uninteresting, and seem an unfair advantage for those who are better at this or spend a few days learning mnemonic techniques. When public information stays public, players make fewer uninformed and mistaken decisions.

The common downside is that sometimes players bog down the game while sifting through old cards or falling into analysis paralysis. We solve this through good-natured grumbling and some smoothly-worn old jokes that reference getting on with things before the mountains crumble into the seas, etc. In rare cases [(or rare players)]{.small} we’ll set a turn timer on someone’s phone. Or give suggestions! Once you’ve looked at all the things an opponent might do and thought through how you’d respond to them and gotten bored, there’s no harm in talking to the opponent about their options.

To keep things moving along (especially when playing someone with very good recall of previous game state), it’s common to ask something like, “Wait, have you played all your aces?” rather than spend twenty seconds flipping through their discards. An honesty norm has developed: you can answer honestly, you can fib and say “I’m not sure” (if you think it gives you a competitive advantage and they won’t check), in an fiercely competitive game you can say “count for yourself”, but you can’t lie. If you’ve played all your aces but say you haven’t, or vice-versa, or otherwise deliberately give false information, it’s considered very rude, unsportsmanlike conduct and is treated almost as negatively as cheating. It’s OK to want to win and normal not to want to help your opponent, but we’ve established lying about public information as something that gets you a lot of frowning friends. We’re good friends or becoming them, so social disapproval means this basically never happens. (Exception: Diplomacy is a blood sport.)

Public Stays Public is a much younger and more explicit rule than Yes Take-backsies, which grew out of long habit. We had only very small, limited experiments with it until about six months ago (December 2017), when I heard at Recurse Center that someone knew of a gaming club (maybe at MIT?) that had it as a universal house rule. I decided it was worth trying and we’ve enjoyed it in every game since.

More?

Our process of developing house rules is a very much like developing traditions. We’re doing this slowly and sometimes only recognizing in retrospect that we have one because we learn another group doesn’t. I’m finally getting around to writing this up today because it came up in an online chat and my response kept getting longer and longer, so maybe I’ll add more in the future.

I suppose one thing worth noting is that in the last decade as games have generally gotten much better (and we’ve gotten more patient), we’ve become much more reluctant to add house rules to individual games. Usually something that seems weird and wrong is a corner of gameplay worth exploring and deliberating rather than something we feel we comfortable immediately trying to prune. We have almost no per-game house rules, really.

Attending Recurse Center was a very rewarding time for me, personally and professionally. I succeeded at studying some difficult topics, I learned about a number of things I’d never have thought to look for, and even more important I got to spend three months with a group of curious, kind, smart, generous developers. I am both proud and humbled to be a part of the Recurse community.

I was a bit unusual among Recurse attendees in how narrowly I focused on studying Haskell, so most of this list of things I did is other stuff:

• Finished a solver for Shenzen Solitaire, a Haskell program to tell me how bad I should feel about my results at the game (very bad, around 99% of games are winnable). I got practical experience in Haskell modeling data, managing state, testing, property-based testing, debugging, and tooling. I’d been working on this for a few months at Code and Coffee before I started.
• Soldered and assmbled a Planck keyboard, then configured it using the very nice QMK firmware with a Norman layout, then trained that up to an acceptable 75wpm. I’ll write a longer post about keyboards at some point, but for anyone who gets curious to buy a kit and might buy from MassDrop, let me mention that I ended up deleting my account over how badly they mismanaged the process and how dishonestly they communicated about it.
• Became the sysop of Lobsters. This wasn’t because of Recurse, but it was a big life event that happened during my time at RC. I planned the migration, learned ansible to help administrate the new servers, and started writing Rails code again for the first time in a year to maintain and improve the site.
• Met with a twice-weekly Haskell study group to work through Haskell Programming from First Principles. I was mostly ahead of the group from prior study, but still learned from all the discussion and helping others. The group split up around Thanksgiving as folks decided to focus on various personal projects.
• Got an introduction to MetaMath and had a multi-day conversation about isomorphisms between different branches of mathematics and computer science, as well as a number of related topics like the role of git in collaborative projects.
• Attended a reading with Q&A by Ellen Ullman, whose book “Close to the Machine” is a cornerstone in my understanding of the experience of programming and its effects on programmers and the world at large.
• Had an interesting experience in sleep deprivation: I started to do some system administration, but quickly recognized that I was too tired to be logged into anything as root. I changed gears to refactoring Haskell and was able to make real improvements by leaning on the type system. Usually I would’ve been writing the commits that featured in the ‘git blame`s of next week’s debugging, but when I looked back they were all solid. The maxim “if it compiles, if works” seems to be true of Haskell refactoring.
• Learned about symbolic execution and concolic testing, an exciting new field of research in program correctness. It’s very academic now and I want to try my hand at writing a practical tool; if it can scale to real-world code it could be tremendously valuable.
• Gave a 5-minute lightning talk introducing functors. I’ll probably record this and put it up on my talks page before the new year. Came in under my usual ratio of one hour of prep time to one minute of presentation.
• Helped a family member’s small Wordpress hosting company recover from being defaced by an Albanian script kiddie. I miss when helping older relatives with tech meant setting VCR clocks.
• Spent two weeks awakened every morning at exactly 3:05 AM. Maybe a building heater had a new routine for the cold weather or something, but the NYC area is noticeably louder at night than Chicago.
• Attended several tech talks, most organized by RC.
• Visited Chicago for a wedding, which was a great chance to see friends and family after so long away.
• I’ve long dithered over the correct order for projects on my homepage. I cut the gordian knot by randomizing it with the rng seeded by year + week so it doesn’t change every single reload.
• Spent Thanksgiving vounteering to serve meals to the elderly and indigent at a restaurant. After taking orders and running food for a bit, I spent the rest of my day behind the bar serving drinks. This was a very rewarding day and I see more volunteering in my future.
• Restarted my use of spaced repetition study software (Anki + AnkiDroid) to shore up my American sign language and solidify the foundation of my Haskell knowledge as I shift into app dev. If the time I spend learning is an investment, SRS is a maintenance contract: I pay a little on a regular basis to ensure the investment doesn’t get lost.
• Took a sharp detour in my last week of studying. Rather than continue to the end ot the Haskell book, I worked on art project called An Inaccurate Clock. Learned SVG for it, which is a nice tool for interactive graphing and vector drawing that I’m glad to put in my toolbox. (This will probably not be released publicly.)
• Got to try an Oculus Rift VR headset, which I was nervous about as almost all 3D games give me motion sickness. I had a lot of fun with First Contact and Superhot and had only a mild reaction.
• Toured New York City a bit. I have family in the area and have visited a number of times, so I didn’t do much of this. Highlights included walking Rockaway Beach, the High Line, a picnic in Central Park, and many long walks through Manhattan and Brooklyn. Took a side trip down to Philadelphia and Baltimore (east coast cities are so close together!) to visit some old friends.
• Met a lot of very good people, saw their excellent, creative, strange, funny, personal, and impressive projects, and had a hundred great conversations about code, practices, careers, and life in general. (Veni, vidi, colloqui.)

If you’re considering attending Recurse, it is almost certainly worth your time. I’d be happy to answer any questions you have by email, on Twitter, or on Freenode.

If you’re considering hiring through Recurse (they keep the lights on with recruiting fees), it is an excellent source of high-quality developers. I don’t know what stronger signal you could get than someone choosing to spend three months learning and collaborating, really.

• The notes are the “intercept” special information tones indicating a line is disconnected and the robots should mark the number as dead.
• The words should confuse or bore humans enough to hang up.
• The length should prevent me from getting two-second empty voicemails from people hanging up too slowly.

(Unfortunately, my phone company doesn’t let me disable voicemail.)

A potential failure is that I want to continue doing business with a few companies that robocall me with notices (insurance, finance, utilities). If one of their robots flags my phone number as bad it might become a customer support hassle where they think they no longer have a valid phone number for me. I’ll edit in an update if this becomes a problem.

2018-06-15: Since this post I’ve only gotten one voicemail (from a relative who read this post). I now only get one spam call every six weeks or so. I wonder if that’s a spammer who tries random numbers without maintaining a database or new spammers entering the market and trying numbers for the first time, but I can’t see a way to effectively differentiate between the two cases and don’t particularly care.

I’m now the sysop of Lobsters, a social news site focused on technology.

Its creator jcs announced three weeks ago that he was ready pass the torch. I’ve been very active on the site, submitting tons of stories to help get the flywheel turning on a solid community. I want to see this good community continue and grow. With the support of the irc regulars, I stepped up to become the new administrator.

We planned the migration and executed it last weekend. There’s a handful of tidying-up tasks on the to-do list, but everything’s running smoothly on the new server.

The Lobsters codebase has been open source for years and I’m now maintaining it. There have been some great contributions from community members and I’ve tagged some issues to encourage new contributors. The new ansible playbook for configuring the site is also public, so hopefully it’ll now be very easy for more people to set up their own sites using the codebase.

I’ve been getting a lot of questions about managing communities in the last week, but I think I’ve already expressed most of my thoughts about it on Lobsters over the years with comments on what I think Lobsters is for, the environment I want to foster, difficulties with brief text on Twitter, and my approach to effective moderation.

If you’re reading this blog because we’ve met or spoken, please email me for an invitation. Otherwise, check the user list for someone you know or ask in chat (mention what you want to contribute or link a personal site/github so they know you’re not a random spammer). Hope to see you there!

Recurse encourages experienced devs to start or work on open source projects. For a couple years I’ve been taking notes on git’s command-line interface and joking about becoming the first CLI UX specialist, so I think I’m going to start that project as part of my Haskell practice. I don’t plan to re-implement git, I plan to wrap it with more cohesive mental models and useful features for day-to-day development work. If you have thoughts or resources in this area, I’d love to hear about them.

I’ll be attending the Fall 2 session in New York City from September 25 to December 15. If you’re in the NYC area those dates and would like to meet up, reach out, I’d love to meet up. And if you’re in Chicago, well, you won’t see me at Code and Coffee for a few months.

Edit: I returned.

So I hacked up a PHP script to grab those mp3s and serve a valid (if spartan) podcast feed.

You can find the code on GitHub. It’s designed to be dropped into place rather than robustly deployed. Then I download mp3s to that folder and they’re delivered as my own personally-curated podcast feed.

Thanks to Shubham Jain for his PHP-ID3 library so the script can read some metadata into the feed.

Pricing is reasonable, it’s $100 to export desktop games, couple hundred more to export to iOS + Android, HTML 5, even PS4 and Xbox. And this week version 1.4 (with a free trial and discounted upgrade to version 2) is on sale cheap.

The games are coded in “GameMaker Language”, which is approximately PHP 3. Little more OO, little less coercion, but it feels similarly very focused on its niche without much experience behind it. I’ve been mostly coding Haskell the last few weeks, so there’s a bit of whiplash moving between the two.

There’s some great video tutorials on YouTube showing how to make games like NES Zelda, Farming RPG, and Platformer. All three of those channels are worth clicking around on as they have other good playlists or one-off videos.

On that last channel I saw a video on Useful Scripts for GMS2 presenting five code snippets. In GML, a “script” is roughly a singleton static method object used to centralize game state or encapsulate snippets of functionality.

The third script presented at 5:18 in the video was wrap(value, min, max) which wraps values that exceed the min or max back around to the other side. So wrap(5, 0, 9) is 5 because it’s in the bounds, but wrap(11, 5, 9) is 6 because it wraps 2 past 9. There’s a visual in the video at 5:30 that makes it real clear. There’s also a screenshot of the code:

/// @description Wrap(value, min, max) /// @function Wrap /// @param value /// @param min /// @param max // Returns the value wrapped, values over or under will be wrapped around

if (argument0 mod 1 == 0) { while (argument0 > argument2 || argument0 < argument1) { if (argument0 > argument2) argument0 += argument1 - argument2 - 1; else if (argument0 < argument1) argument0 += argument2 - argument1 + 1; } return(argument0); } else { var vOld = argument0 + 1; while (argument0 != vOld) { vOld = argument0; if (argument0 < argument1) argument0 = argument2 - (argument1 - argument0); else if (argument0 > argument2) argument0 = argument1 + (argument0 - argument2); } return(argument0); }

There’s a lot going on there. This is probably hot-path code that runs every frame, but it has branches inside a loop for something that could almost certainly be an arithmetic one-liner. So for practice with GML and the IDE in general, I rewrote it.

I saved the above script as original_wrap and created my own wrap implementation:

/// @description wrap(value, min, max) /// @function wrap /// @param value The value to wrap into the bounds /// @param min Minimum bound, inclusive /// @param max Maximum bound, inclusive // Returns the value wrapped to the range [min, max] (min and max can be swapped). // Calls floor() on reals, but GML’s modulo is doing something weird and original_wrap just hangs indefinitely on some values anyways so oh well.

var value = floor(argument0); var _min = floor(min(argument1, argument2)); var _max = floor(max(argument1, argument2)); var range = _max - _min + 1; // + 1 is because max bound is inclusive

return (((value - _min) % range) + range) % range + _min;

Some oddities, like JavaDoc instead of a function signature, so arguments have automatic names (reminds me of perl 5). In dev I got a compiler error for referencing argument1 before argument0 - I’m not sure what that could be but look forward to reading the manual. I can’t unimport/shadow the global max and min, the convention seems to be to use a leading underscore for colliding names.

To test it, I created another script called test and invoked it from an object’s create event. Which felt a little roundabout for specifying that I wanted it to run at startup, but I’ve barely touched the manual so I’m probably missing something obvious. I know there’s 3rd-party test library but I wanted to hand-roll to see more moving pieces. I generated a golden master test suite to exercise a bunch of test data, though I didn’t go all the way into property-based testing:

// make this easy to spot in the build output show_debug_message(“HELLO &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&”);

for(i = -5; i < 25; i++) { var orig = original_wrap(i, -2, 5); var new = wrap(i, -2, 5) if (orig != new) { show_debug_message(“int failed “ + string(i) + “ orig “ + string(orig) + “ new “ + string(new)); } }

//for(i = -5.0; i < 19.2; i = i + 1.1) { // show_debug_message(i); // var orig = original_wrap(i, -2.1, 5.3); // var new = wrap(i, -2.1, 5.3) // if (orig != new) { // show_debug_message(“real failed “ + string(i) + “ orig “ + string(orig) + “ new “ + string(new)); // } //}

The commented-out testcase is, I think, about the broken behavior with regards to reals. I’m pretty sure the (argument0 mod 1 == 0) exists to type-check if argument0 is an integer or real. I’m not sure because GML has typeof for typechecks (is_real in 1.4, which feels very PHP 3), but this is probably well-copy-pasted newbie code. When I tried to test the behavior, I ran into a bug where original_wrap hung indefinitely on some inputs (the existing test triggers this, if you want to uncomment and run). I didn’t want to keep tinkering, so I dropped in some floor calls and moved on.

Anyways, this was some fun tinkering. I’m looking forward to working through the official tutorial with my nephew and maybe making some small games. (Oh, and I release this into the public domain, feel free to use it with or without credit.)

#!/bin/bash

set -e # exit on error #set -x # debugging

if [ `pidof /usr/bin/redshift` ] ; then exit ; fi

# Chicago LAT=41.94 LONG=-87.65

MAX=5700 DOWNTO=4200 # Tungsten: 2700K # Halogen: 3400K # Fluorescent: 4200K # Daylight: 5500K MODE=vidmode GAMMA=0.8

# figure out how overcast it is, and adjust temperature to match TODAY=`date +%Y-%m-%d` wget -q -O/tmp/clouds.xml “http://graphical.weather.gov/xml/sample_products/browser_interface/ndfdXMLclient.php?product=time-series&sky=sky&lat=$LAT&lon=$LONG&begin=${TODAY}T00:00:00&end=${TODAY}T23:59:59” OVERCAST=`echo -e ‘s/[\^0-9]*([0-9]+)<\/value>/\1/m\nt xxx\nd\n:xxx’ |sed -rf - /tmp/clouds.xml |tail -n 1` TEMP=`echo “$MAX+${OVERCAST}0” |bc`

redshift-gtk -l $LAT:$LONG -t $TEMP:$DOWNTO -g $GAMMA -m $MODE