Docker for Mac - Safely reset from factory defaults
Several months ago, I got a notification to upgrade Docker for Mac to version 18, and there was a note in the recent changes that caught my eye.
Several months ago, I got a notification to upgrade Docker for Mac to version 18, and there was a note in the recent changes that caught my eye.
Wouldn't it be great if there were a documentation tool that's directly tied to the source code (so that you can always access information that's relevant to the code you're looking at), that doesn't clutter up the code itself, that's carefully and automatically timestamped (so that you know how current its information is), and that's guaranteed to be updated whenever the code is? Oh, wait. There is.
We recently changed one of our core values to remove an obviously gendered term. This is an exploration of what prompted us to do so.
I’ve had the idea for a new testing tool in the back of my head for years. I’ve been calling it Cukeness (more on that name later). I was actually working on the project when I first asked Andrea to join me on the Corgibytes journey. I did a horrible job of explaining to her why it needed to exist. So she said that I should put it on pause and focus on other things instead.
This wasn't the sexiest project we've ever worked on, but a combination of good tooling, careful preparation, and a fair amount of mind-melting compiler error resolution made this a one of our best remodeling efforts of 2018.
A little while back, I arrived at my desk to a message no one likes to receive: the production instance of a client's primary app was down. What's more, the site had just gone live earlier that week, and thousands of users were trying to login.
If you want to eliminate your technical debt, communication HAS to be a critical component of your efforts. If you're struggling to break up your monolith and move to a microservices model, the first place to look is how your team is communicating. Command and control silos will result in monoliths. Self-organizing and autonomous teams give rise to microservices.
We frequently work on projects where it's best to start out with an older version of ruby. Getting these to install correctly feels like a dark art sometimes. Here's a quick series of steps that we had to follow to get Ruby 1.8.7 using RubyGems 1.8.30 installed via RVM.
From what I see, it's this relentless commitment to maintenance and modernization that enabled American entrepreneurs like Carnegie to outpace their British competitors, and it's a lesson that modern companies would do well to learn, lest their competition overtakes them.
In many ways the Ship of Theseus paradox is quite similar to software development. Is this app the same one it was five years ago? How about two? What about after the massive refactor we *just* finished? If it still serves the same business users in the same capacity, but we rewrote it, does it matter?