We’ve had some excellent discussions about API design over the years. Add to the list this piece by Joël Quenneville at Thoughtbot where he borrows a mental model from the world of MOBA games:

In gaming, MOBA (multiplayer online battle arena) players have a mental framework for describing just what kind of player is empowered by different characters. This framework describes all characters in terms of two statistics: their skill floor and their skill ceiling.

Stephen Lindberg takes cues from the level design in Super Mario 3D World and applies it to user experience design:

You may not know what a Conkdor is, but the design problem is universal: “how do we reduce cognitive load without sacrificing interest and fun?” To summarize the video, game designers would approach the problem like this:

1. Introduce a new concept in a way that the player is not punished for failing.
2. Build upon that concept in a way that challenges the player.
3. Combine the concept with other familiar concepts to put a new twist on it.
4. Give the player a reward!

A solid breakdown of both the benefits and drawbacks of these two popular approaches to managing CSS. Stick around to the end where a 3rd, merged approach is presented.

Command (line? I’ve never called it that) mode is indeed where much of Vim’s power lies. In this post on Thoughtbot’s blog, German Velasco explains search and replace, command repetition, ranges, and more.

Lots of good advice in this quick post on Thoughtbot’s blog. I especially like this:

It’s easy to list all the things you think need changing in the pull-request but gloss over all the good things present. If you see something good, say something good! It’s refreshing to receive positive feedback. I find that even simple things like these can go a long way:

• “I love this method extraction”
• “These tests look great! 🎉”
• “Nice catch on this poorly named method! Thanks for changing it”

German Velasco:

I find that many people confuse refactoring with any change in code. Sometimes they even use the word to mean huge changes that break the application — “we need a month to refactor this monolith.” I think that in those cases, we are misusing the word refactoring, robbing it of its proper meaning, and ultimately, robbing ourselves of the power to communicate an important concept.

Let’s revisit what refactoring is and what it is not.

Some folks might consider this post semantic pedantry, but I think there’s value in knowing the difference between refactoring and merely changing stuff. Don’t get me wrong, I misuse the term on the regular, but when I’m being more diligent with my word choice I will reach for rejiggering instead.

Chris Thorn writing for Thoughtbot:

Lately, I’ve noticed that opening Markdown files in Vim is slow. I don’t know exactly how slow, but slow enough that I notice a pause after opening the file before I can edit it. I’m not sure why or when it started, but it’s painful enough that I want to track down and alleviate it.

I, too, have felt this pain, which is one of the reasons I no longer use Vim as my full-time coding editor. I still use it enough for its sluggishness to bug me, but not quite enough to go chasing down why it’s sluggish. This article might change my calculus on that decision.

If you’re a tmux user, but you’ve never heard of tmuxinator… it’s time to fix that. Simon van Dyk has a solid intro to it on Thoughtbot’s blog:

tmuxinator is a ruby gem that allows you to easily manage tmux sessions by using yaml files to describe the layout of a tmux session, and open up that session with a single command.

I’ve been using tmuxinator for years and highly recommend it. 👌

But…why?

We’ve loved building Upcase, both as a business and as a way to share what we’ve learned with the community. But while we’d love to keep investing in Upcase and producing tons of new content, we’ve been moving in a different direction—back to our roots, in fact, as we focus on our core consulting business.

So what to do with this learning platform we’ve poured our hearts and souls into? We ultimately decided the best option was to open Upcase up to the world and share all of the content, no subscription needed. As they say, if you truly love something, set it free.

Focus is SOOO crucial and sometimes is overlooked for too long. Been there. Glad to see the wisdom of focus here being shared (freely) from Thoughtbot. We’ve always been huge fans of their leadership in the community.

Finally, an article that breaks Betteridge’s law of headlines!

Elixir is known for being a language made for building distributed applications that scale, are massively concurrent, and have self-healing properties. All of these adjectives paint Elixir in a grandiose light. And for good reasons! But is Elixir also a language that can be used for the more mundane tasks of this world like scripting? I think the answer is a definite yes.

I’ve been writing Elixir for a few years now, but when it comes time to script something I still reach for Ruby. Case in point, our data import routines for changelog.com (which y’all know is an Elixir app) are written in Ruby.

Why do I do this? Familiarity plays a big part. Also I find Ruby to be highly ergonomic for such tasks. Having said that, this article will make me consider trying Elixir for my next script.

Derek Prior on Ruby 2.5’s yield_self method and how it can be compared to Elixir’s (and soon JavaScript’s?) pipe operator.

I write Ruby daily, but I had no idea yield_self was a thing. In this post, Derek takes us through a real-world use case for it. I agree that the final code is more readable than where it started. Good stuff 👌

Joël Quenneville:

Our world is full of uncertainty. This uncertainty bleeds into our programs. A common way of dealing with this is null/nil. Unfortunately, this leads to even more uncertainty because this design means any value in our system could be null unless we’ve explicitly checked it’s presence.

Imagine how many developer-hours are wasted globally each year dealing with null/nil. The number would probably astound us.

The major advantage of guard clauses is to suss out invalid inputs (often nils) at the perimeter of your program/module/function, so the rest of your code doesn’t have to concern itself with these uncertainties. But Maybe there’s another way…

In Elm, all values are guaranteed to be present except for those wrapped in a Maybe. This is a critical distinction. You can now be confident in most of your code and the compiler will force you to make presence-checks in places where values are optional.

Click through to learn the mechanics of it all.