Michael Herold

I recently had my first ever hard drive failure and have since been looking into off-site backups. There are many choices to look through for off-site backups: what software should I use? What storage provider? This post describes how I set up Duplicacy and Wasabi as my off-site backups solution. Duplicacy is a backup tool written in Go. It supports many back ends including Wasabi, a fast, S3-compatible cloud storage provider. Wasabi offers great pricing that allows you to easily calculate how much it will cost to back up your data. However, combining the two isn’t very clear due to lacking documentation. You’ll leave this post with an understanding of how to set up an off-site backups repository using these two tools.

Have you ever been tempted to subclass a core class like Hash or String? Or have you read blog posts about why you shouldn’t do that, but been left confused as to the specifics? As a maintainer of Hashie, a gem that commits this exact sin, I’m here to tell you why you want to reach for other tools instead of the subclass.

When you want to start phasing in Vue into a project, it’s tempting to not rely on custom components. Instead, you’ll likely use manually mounted Vue instances through the vm.$mount method. However, it’s not clear how you can pass in props using this strategy. The props documentation bases all of its examples around custom components. Instead of passing in props, you can rely on the created lifecycle hook. But that doesn’t feel as clean or communicative as using props for their intended purpose. How can you pass in a prop when you’re manually mounting a component?

How do you think of your customers? Do you think you’re customer-driven? Or are you product-driven? Venkatesh Rao argues that you’re not customer-driven and has an interesting taxonomy for the ways in which you aren’t customer-driven. I think this hierarchy is really interesting, partly because of varying degrees of hubris in the ladder. It shows that the “expert vs layperson,” which I recoil from, is really only halfway down the ladder toward treating other humans poorly. Let’s look at the viewpoint of the expert vs. layperson in the context of application design.

The Hash default value behavior in Ruby is one that can leave people confused. The hallmark of a good API is that it is obvious what is going to happen in each way you use it. This is one of the few places I can think of where Ruby’s standard library has surprising and confusing behavior. In the case where you use a value object – like a Numeric – as the default value, everything works as you would easily expect.

Software teams often cite code reviews as a primary means for ensuring quality and reducing bugs in their code. However, without high quality reviews, the efficacy of this practice is questionable. In most places that I’ve worked, a change requires only one code review (either through necessity due to team size or through informal norms). When this is the case, the code review becomes a taxing process where, if you’re not on your game, bugs or maintainability issues can start to leak into production. This means that it often falls to the senior engineers to do code reviews. However, relying entirely on the seniors means that they become a bottleneck in the process. When it comes to “dangerous” changes like Rails database migrations, the bottleneck of relying on a small subset of the team can mean that velocity drops. Or, to keep up velocity, you make code reviews less stringent and quality drops.

Sometimes, designers will mock-up an extremely usable page that they’ve thought about and tested. Once they’re done and they bring it to you to implement, you look at it and think, “how on Earth can I do that efficiently?” One such case happened at work recently.

The double-splat operator is one of my favorite additions in Ruby 2.0. For some reason, the two little asterisks together make me happier than an optional Hash parameter in a method. Even so, outside of method definitions, I didn’t realize there was a use for the double-splat operator until I dug into a bug in Hashie. I liked the result enough that I wanted to take a quick minute and share what I found.

Do you ever talk to yourself? How about publicly? We, as a society, often make fun of our friends for talking to themselves. But self-talk can be a powerful technique for self-teaching something. As an exercise, I tried using a tweet storm to share how I was approaching relearning a numerical methods technique. This post is a recounting of why I did it and what I learned. I’ll also share whether I think I will do it again.

One of the duties I have at work is to mentor some of the Rails developers on our team. I enjoy this immensely, yet struggle with at the same time. In a previous life, I wanted to be a professor and help people learn computer science and programming. I became jaded with academia, so left it and have been working in the software industry ever since. However, I still have that urge to teach, which is why I enjoy mentoring so much. My struggles with mentoring come from my long background in software development. I have been programming in some form since I was nine years old and have been paid for programming since I was eighteen. As such, I have somewhere between 13-22 years of experience across myriad different computer-related backgrounds. I spent the majority of my waking hours from the age of fourteen to the present building my skillset. Can I really ask more junior developers to do the same? How on Earth do I reconcile that when suggesting ways to improve to my colleagues?