Recent Posts

dry-rb 1.0: upgrading validations, types and schemas

9 minute read

I’m enthusiastic about dry-rb gems. Actually, I’ve never worked on Ruby projects without a dry-rb gem. However, some people are sceptical, as a lot of core dry-rb gems are still in their 0.x phase, which leads to a lot of breaking changes and hours of refactoring.

I’m happy to see dry-rb mature: dry-monads entered 1.0 phase in Summer 2018, and now two more libraries hit v1.0 milestones: dry-types and dry-struct; and dry-validation is in its 1.0 RC phase.

I haven’t updated my dry-rb gems for a couple of months, so I’ve missed a lot of breaking changes. Finally, I decided to upgrade the gems and write about the process. I’ll take a swing at automating my upgrade process as much as I can.

Partial application in Ruby

7 minute read

Ruby is a multi-paradigm language with a strong bias towards object-oriented programming. You can argue that its design is influenced by Alan Kay and Smalltalk, as opposed to C++/Java-style object-oriented languages. Thankfully, this object-oriented design doesn’t mean we can’t use ideas from functional programming. There’s a small list of functional traits in Ruby:

  • Expression-oriented syntax
  • Geeky names for Enumerable methods: filter, map, reduce, flat_map
  • Idiomatic monads
  • Railway oriented programming
  • lambdas and procs
  • … I can go on and on

There’s also one specific empowering feature: built-in support for partial application. In this article, I want to talk about implementation and use-cases for partial application in Ruby.

Monad laws in Ruby

5 minute read

I’ve been using monads in Ruby since May 2016, but I haven’t really understood the theoretical basis for them. I thought about learning Haskell, but I gave up pretty soon: I didn’t think I would benefit from it. Moreover, we started using ReasonML in Planado, which improved my functional programming skills to the point I didn’t really need a new functional language in my life. Why bother with learning Haskell when you know Ruby and Reason, right?

In early 2018, I became curious about theoretical aspects of functional programming, especially the monad laws. That’s when I realized that I really needed Haskell, mainly because everyone used it in their articles. It was extremely annoying because I couldn’t even read the code. How was I going to apply those things in Ruby if I can’t even understand what they’re saying? So I got a little help.

I grabbed my laptop and a friend who knows Haskell and figured out how to describe the three monad laws using Ruby’s dry-monads gem.

Railway Oriented programming in Ruby: do notation vs dry-transaction

7 minute read

Railway oriented programming is a design pattern which helps us handle errors in our applications. Instead of relying on exceptions, we design our data and functions in a specific way. Since applications are essentially just a combination of steps, we’ll make some design decisions about those steps and their structure:

  • There is a Result type, which can be either a Success or a Failure
  • Success and Failure are practically containers with different data
  • Steps accept Result and return Result
  • Once a step returns Failure, we stop further execution

I want to emphasize that Result is just an alternative name for the Either monad. Railway Oriented Programming comes from functional programming, so it is tightly related to the usual FP concepts like monads, composition, and many others. However, you don’t need to have an extensive knowledge of monads to use ROP in your code. In this article, I’ll show you how to write railway-oriented code in Ruby.