I've been building software for the majority of my life, and I've tried quite a lot of technologies. Right now I use Ruby for my most day-to-day tasks. Although, I regularly dive into React and Go code if I have to.
My habits, skills, limitations, and style made me somewhat good in solving issues introduced during the rapid growth of a product. I research the issue, systemize the chaos, gather data, look for limitations, build a plan, and then help with execution. You could say I'm often a Solver, as per StaffEng.com definition.
There are some things I've been interested in over the years: functional programming, object-oriented design, domain-driven design, software architecture, C4 model, arc42, type systems.
My software career is a never-ending learning experience. However, I'm never learning alone. There are always other people who share, research, and inspire. Likewise, I enjoy sharing my own observations with other people – through conversations, talks, and blog posts. This website is a good way to access those.
An attempt at providing a comprehensive guide to designing service objects in Ruby. The article showcases multiple typical approaches towards designing those, and suggests different qualities to consider when choosing one or another. Parts 2 and 3 were never published.
A fairly in-depth article focused on one single topic: whether or not it’s reasonable to use monads in Ruby. It gives historical context, takes a look at the arguments pro and against monads, and provides an opinionated, yet qualified conclusion.
A tutorial which helps automate >70% of a complex upgrade for gems within dry-rb ecosystem. 1.0 release for dry-types, dry-schema and dry-validation was particularly complex because there was little room to upgrade gradually. This tutorial provides a strategy to make the upgrade a little bit less risky
A little fun article taking a hint at the ways we can achieve partial application in Ruby. It comes with an idiomatic solution, my own currying solution, and the benchmark to assess Ruby’s built-in currying
A little article taking a look into monad laws through the prism of Ruby and dry-monads. Those laws might be complex from the first glance, but they actually describe some pretty useful behaviors in those objects. The article reads into the definitions, explains those, and illustrates them from a raw programming perspective.
This post showcases one of the then-newest dry-monads’ feature: the Do notation. Akin to Haskell’s Do notation, it allows us to write imperative code instead of chaining binds and ors. The article illustrates the idea of Railway-Oriented programming and the practical application of Do in Ruby.