Thoughtbot Icon


A web + mobile + design + development firm with a long history in open source. • 4 Stories
All Sources

Thoughtbot Icon Thoughtbot

Upcase (from Thoughtbot) is now free

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.


German Velasco Thoughtbot

Is Elixir a scripting language?

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 (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.


Thoughtbot Icon Thoughtbot

The mechanics of Maybe

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.

0:00 / 0:00