Monadt – Algebraic Data Types and Monads in Ruby, Part 2: Monads

In yesterday’s post, I introduced monadt, a gem that adds algebraic data types (ADTs) and monads to Ruby. Today I’m going to dive into how monadt provides monad support, specifically the imperative-looking syntactical sugar you get in languages like Haskell and F#. Read more on Monadt – Algebraic Data Types and Monads in Ruby, Part 2: Monads…

Monadt – Algebraic Data Types and Monads in Ruby, Part 1: ADTs

Functional programming is elegant and expressive. I’ve written before about my love of partial application, and how the funkify gem can be used to bring the power of partial application to your Ruby code. But partial application is just one of the powerful idioms from functional languages that I’d like to borrow in object-oriented languages. I’m also pretty into algebraic data types and monads.

So, continuing my pattern of adding functional concepts to object-oriented languages whether they like it or not, I recently created the monadt gem which adds support for using algebraic data types and monads to Ruby. Read more on Monadt – Algebraic Data Types and Monads in Ruby, Part 1: ADTs…

On the Importance of an Open Mind in Software Development

Software developers can be a contentious lot. Just check out any of the comment threads on Hacker News if you need confirmation. We tend to see ourselves as intelligent and passionate, but far too often, we can come across as arrogant and combative. It seems like no matter what topic you pick–choice of language, testing strategies, micro services, the list goes on–there’s a holy war going on between the adherents of two or more sides. Read more on On the Importance of an Open Mind in Software Development…

Property-Based Testing for Serialized Data Structures

When I first heard about property-based testing, my instincts told me it was too academic to be of practical use. But, as is often the case in the art of software, my gut reaction failed to appreciate the value of something new.

I originally felt the same way about functional programming, so I guess I can’t trust my gut very much when it comes to new concepts. To quote Nick Hornby, “Between you and me, I have come to the conclusion that my guts have s— for brains.” I’ve recently stumbled into some great ways to get real-world value out of property-based testing.
Read more on Property-Based Testing for Serialized Data Structures…

TDD in a REPL

REPLs (Read-Eval-Print-Loops) are often billed as a great place to experiment and learn a language or a framework. They provide a very tight feedback loop. However, it can be difficult or time-consuming to extract the knowledge gained from a REPL and include it in your source code. I’ve hit the up arrow many times in Ruby’s pry, trying to find the specific input I wanted to copy. And don’t get me started on dealing with multi-line input. Thankfully, the developers behind F# came up with a clever way of dealing with this problem. Read more on TDD in a REPL…

Waiter, There’s a WordPress in My Web App!

If you’ve ever been a part of developing custom software, you’ve probably seen some features turn out to be much more complicated than anticipated. Sometimes, it’s due to unforeseen technical constraints. Other times, it’s a case of not fully understanding the nature of the feature—a situation that led me to an unexpected use for WordPress.
Read more on Waiter, There’s a WordPress in My Web App!…

Unorthodox Ember Data Models: A Resource By Any Other Identifier

Ember Data has strong opinions on how it wants you to structure your data and your API, which are essentially collapsed into one by its default paradigm. If you are using ActiveModelSerializer, the path of least resistance is to have your DS.Model classes essentially mirror your ActiveRecord classes, to the point where I feel like an Ember Data app is often doing SQL over AJAX.

Read more on Unorthodox Ember Data Models: A Resource By Any Other Identifier…

Functional C# Application Composition, Part 3: MethodToDelegate

In part 2 of this series I made a case that switching from Stateless Single-Responsibility Objects to delegates and static methods lets us write simple, pure functions and lets us remove a lot of boilerplate.

Nevertheless, there was still one bit of boilerplate I hadn’t yet removed. It dealt with encapsulating dependencies to a method in order to match a delegate signature for use in other parts of the application. Read more on Functional C# Application Composition, Part 3: MethodToDelegate…