Asciinema fills a unique niche in the toolkit for terminal recording and sharing. It bridges the gap between plain text output and video, offering the best of both worlds: the clarity and timing of a recording with the selectability and accessibility of text. Whether you’re creating tutorials, documenting bugs, or sharing command-line workflows, asciinema deserves a spot in your toolkit.
Working within a software development team has tremendous benefits, but it also comes with its share of complications. One of those complications is inertia โ the more people who get used to a process or a certain set of tools, the more difficult it can be to introduce changes. Maybe this manifests in a positive way, where repetition and familiarity …
Let’s get this out of the way: I love tmux. Gaining the ability to multi-task within the terminal was a monumental productivity boost for me, and if you’ve used it in the past, you probably have similar stories about how it leveled up your workflow. It’s fast, it’s well-supported, and it has a plethora of features you can invoke with just a few keystrokes.
…and personally, I can only remember about a dozen of them.
The command line is a powerful tool in software development. Regardless of whether you are comfortable working within a shell or if you prefer a GUI, there are likely scenarios that still require you to open a terminal and type out some commands.
This should not surprise us โ many tools solely support Command-Line Interface (CLI) interaction โ but over time, the efforts required to keep track of each new commandโs syntax can add up. If youโre anything like me, you might memorize only the commands that you use most frequently, resigning yourself to searching through documentation for the rest whenever you need them….
In past blogs, I have discussed development containers (dev containers) in detail, from explaining their general mechanics to showing how they can bolster a team’s build automation. As a brief recap for the uninitiated: dev containers are a way of encapsulating a developerโs setup into a container, typically a Docker container. As a practical example, rather than forcing a new teammate to manually install and configure all the necessary tooling before contributing to a project, they can leverage a teamโs devcontainer.json definition file to quickly spin up a fully configured development environment.
Microsoft has championed this workflow over the past few years, offering tight integration with tools like VS Code and Codespaces to make containerized development as seamless as possible. At the time of writing, the developer experience has reached a point where I honestly prefer to operate within a dev container for certain types of projects. When I open a teamโs codebase within VS Code and it informs me that they have provided a dev container to use, I have higher confidence that Iโll be using the same versions of their tools and seeing the behaviors that they expect.
Iโve even come to trust these setups more than an equivalent set of Dockerfiles or docker-compose scripts, just because the simplicity of the ecosystem makes it more likely that everything is well-maintained and configured correctly. Itโs easy to see how these standardization and automation benefits can be a huge boost to teamsโฆonce theyโve adopted the right tools to integrate with them.
But what if you donโt want to use VS Code?