Have you ever wondered just how out of date your dependencies are? Does your bundle not, well, bundle? Well do we have the gem for you!
While Double Agents Steve Jackson and Daniel Huss both dated gems (the happily married guys they are), gem_dating is helpful to spot rough patches in a Ruby upgrade by showing how long it’s been since a gem received any attention.
If you’re interested in the gem, head over to the repo to see the details. If you’re curious about how Test Double’s agents find ways to collaborate, serve our clients, and share with the open source community, read on.
How we work
Recently Steve had a brief stint on “The Bench,” which is where our agents land when we’re between deployment to client engagements. We manage the ebbs and flows of project work so our clients don’t have to staff to the peak. For Double Agents, heading to the bench can mean a great opportunity to take time off to recharge between engagements. Though, not always.
We’re always looking for ways of working that naturally encourage collaboration.
Test Double’s greatest asset is our people, so we don’t lay anyone off between engagements, or force them to take holidays. Instead we value the time between engagements as a chance to grow, learn, and share with the communities we are a part of. That could be sharpening individual skills, contributing to something internally, or collaborating with others to problem solve in an area of interest or expertise.
When our agents are at a client, it can be a challenge to find ways to collaborate with others on different engagements. Sharing knowledge among our team is the biggest hidden perk we offer our clients, who have access to the expertise of our whole team via their deployed agents. We always look for ways of working that naturally encourage collaboration.
The best is when bench time helps our agents’ growth, serves our clients, and contributes to the communities we’re in. It doesn’t always work that way, but the way gem_dating came to be is a great example of how all three can come together.
The first thing suggested by other agents was bundle outdated, the bundler command that shows which gems have newer versions available. Unfortunately for this use case, bundle outdated may be misleading if a gem was abandoned years ago, and is technically up to date. If the Gemfile.lock is missing, or has a particularly outdated set of gems that makes bundling very un-fun, that also makes bundle outdated harder to work with. The gemfile may be full of vendored gems, local engines, privately-hosted gems, or other bundle-blockers, which makes it an outright unideal answer.
The Test Double team wasn’t able to come up with an answer for Steve, so he took advantage of his bench time to get the bare bones of gem_dating implemented.
Naturally the easiest part came next: naming the gem!
How to name things?
Getting any solution to a problem off the ground has a lot of obstacles. A common blocker is the desire to polish to perfection. As tinkerers and professionals, we always want to show off our best work. Striving for our work to be polished on first draft is the antithesis to positive momentum.
If it’s hiding in your private repo, it’s more likely to drift to the background, forgotten. That said, putting the unpolished work out there requires trust. To build collaboration it’s critical to cultivate a space where “expertise” is not synonymous with “always perfect.” While Double Agents are, without a doubt, experts at any variety of tools, technologies, and skills, none of us hold any illusion that we’re infallible and have every single answer.
By talking publicly about his original problem, Steve got confirmation that:
- this is an interesting problem
- none of us knew of a solution that fit his needs
- others of us would find this useful for our clients
Sharing the problem on Slack meant a whole bunch of us got to have fun discussing options, honing in on what the problem was, and opened space to say “I wish this was real.” That caught Steve into a positive momentum loop. Armed with confidence that the problem was novel and warranted a unique solution, Steve chose to make the solution accessible in a public repo. Knowing you’ve got others who are keen to try out a tool you’re building is a great way to get momentum going. In turn, Daniel got caught in the momentum loop by trying the tool out and thinking “I wish this had a command line tool so I could just point it at my gemfile.” So he did!
If you’re facing down a Ruby upgrade, gem_dating may help put texture to the lumpy bits of the process. There’s a whole other blog post waiting to be written about the ways dependencies can make upgrades a whole lot more complex. If that complex upgrade is holding you back, Test Double can help.
If you want to talk about gem_dating, upgrades, or other challenges with Legacy Code, feel free to send Daniel an email!
