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?
Over the years, we’ve seen many approaches to HTTP API design. While REST APIs are still very popular throughout the industry, they offer no inherent guarantees that the client’s assumptions about the response structures will be valid.
GraphQL fills this gap to an extent by allowing client-side code greater control over the resulting structures but at the cost of added complexity. RPC (remote procedure call) frameworks attempt a different solution by sharing generated type definitions between the client and server implementations. What if there was a way to achieve the type safety of RPC by simply inferring the type definitions from the server’s code?
Enter tRPC. Since JavaScript (and specifically TypeScript) can already span across client and server implementations, tRPC allows a client to directly consume structures defined by the server’s exposed procedures. Essentially, you import your dependencies from the server to access these procedures, their return types are inferred and checked at build time, and your client code can confidently consume the returned data.
In this post, we’ll look at how it achieves these goals and what limitations it places on your project stack.
I imagine that most engineers have endured at least one painful onboarding experience. Every person I’ve asked has given me a unique example, from relying on piles of outdated notes to being stuck in some sort of task-less limbo and forgotten by the rest of the team. What should be your first impression of a new team can turn into a nightmare if that process isn’t handled properly.
In this post, I will describe some common themes from these bad experiences, as well as how a team can identify them proactively and work towards a better experience for their next new engineer.
