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”
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.
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. 👌
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
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 👌
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.