5 Lessons Factorio Taught Me About Development
I recently saw on thread on Reddit’s /r/webdev subreddit that asked a simple but less-than-benign question: “A lot of web dev tools as of late are like “you don’t need to code anymore!”. Doesn’t this insult you?”. This, naturally, inspired a lot of discussion—most of it was dismissive, but a portion of the responses brought up good points about the difference between learning to code something “by hand” versus having a tool automate the process for you.
Same goes for this recent blog post by Ed Coffey: DevOps: More Than Automation.
Between tools like Puppet/Chef/Ansible, scripts for setting up many different programs, Docker-based installs, and devs who are willing to freely share their configurations on Github for anyone to adapt, it’s becoming easier and easier to set up a VPS without knowing a ton about the underlying architecture.
Is that good or bad? It’s hard to say. This very blog has featured a number of tools that abstract and/or automate. Docker makes installing a number of applications incredibly easy, and so does EasyEngine (for WordPress, at least). There’s one tutorial directly focused on Ansible and basic configuration management (CM), and there’s that one time I failed at setting up a VPN server and had to fall back on an automated script.
At this point, you might be wondering what Factorio is.
This factory/automation simulation game “in which you build and maintain factories” hinges on a simple premise: of course you can build just about anything “by hand” from your inventory, but why do something by hand when you can automate it?
|A very compact factory with automation for a number of different tasks. It begins with iron ore (the blue rocks being fed in from the right hand side) and gets turned into iron plate, and steel, and science packs, and much more.|
When you begin the game, you have to manually mine iron ore and coal, and mix those together in a furnace to make iron plate, which you can then that to create new things. As you scour your inventory/crafting area, you start to see some new things you can make with these plates—namely, conveyor belts and “inserters,” robotic arms that move items to and from said conveyor belts.
You can see where this is going—as soon as you learn how to make something new, you seek out a way to automate it. First comes an automated system for making iron ore, and then, perhaps, an automated system for making more conveyor belts.
The game expands rapidly, and rather infinitely from there, but never drops that core learn-automate cycle.
|A decently-sized smelting area.|
The same cycle begins whenever someone connects to a newly-provisioned VPS for the first time, regardless of their education and skill. The path to getting anything done isn’t exactly clear. One has to wonder about the best way to accomplishing their goal, down to the smallest of decisions, like camelCase versus underscores.
Conveniently enough, I think my advice to a starting Factorio player and someone starting on a brand-new VPS would be pretty much identical.
Try your best, on your own: Unless you’re running some mission critical service, it’s okay to fail—the worst-case scenario is that you have to rebuild your server and start again. Keep important work backed up, and then have at it using only the documentation provided by the developers of the software you’re trying to install.
man has worked for Unix developers for decades at this point, so it can work for you, too.
Embrace tutorials: Tutorials are a time-tested method of learning how to get something done on a VPS, and we can’t recommend them enough—have you tried out any of our own?
This might seem contradictory to the learn-automate cycle, but as long as you approach tutorials with a willingness to learn over simply copy-pasting commands into your shell, tutorials will always be a useful resource. With that said, you should try to use tutorials that are aimed at teaching you rather than just instructing you. We always try to teach rather than instruct, but if we’re not doing our job well enough, let us know.
Avoid scripts if possible: We like to tell our users that scripts like EasyEngine exist, but can’t necessarily recommend them, particularly to newer users. If something goes wrong with your installation, and all you did is type one command into a terminal, you have no shot at troubleshooting it. If you went through the steps yourself, and understand how the components fit together, you at least have a shot.
Don’t trust any one configuration: I remember quite clearly stumbling upon the ansible-role-security repository while researching Ansible playbooks for CentOS security and finding the following message:
First, a major, MAJOR caveat: the security of your servers is YOUR responsibility. If you think simply including this role and adding a firewall makes a server secure, then you’re mistaken.
That couldn’t be more true—it’s bad practice, and quite dangerous, frankly, to blindly use someone else’s automation tools without understanding the underlying processes. It could leave you locked out of your VPS, or create a vulnerability you weren’t aware of. Same goes for any configuration we offer via tutorials.
Learn to automate: We’re finally to the second half of the learn-automate cycle. They is where you can start to figure out how to automate the processes that you’ve already learned. It’s okay if they’re based on the work of others, but you should aim to understand how each of the pieces fit and work together.
Remember that any automation tool—whether it’s Ansible or Gulp or Travis CI—doesn’t have to be perfect right away. You can always tweak things later.
And that’s the core of the learn-automate cycle, whether we’re in Factorio or on the Linux shell. Learn how to make something, do it poorly, and then do it better. That’s the difference between “spaghetti” (on the left), and something with a little bit more cleanliness in mind.
|A classic spaghetti factory.||Ahh, that’s better.|