It’s a cliche that the answer to any given programming question is “it depends” and hard rules that you should 100% follow should always be questioned as there is usually an exception somewhere. This means when I do have a rule I feel I should follow 100% of the time it’s worth special notice. In the spirit of RFC 2119. All functions or methods you write MUST return an identical type regardless of their success or failure.

One of my open questions from Implementing MD2 in Rust was how the PI_SUBST s-box in appendiex 3 was generated. Some follow-up searching led me to a crypto stack exchange post with a response from someone who emailed Ron Rivest to get the answer. Additionally ryanc was super helpful in providing a python implementation of that explanation. Now I generally don’t use python but I do know ruby so to try and understand what is going on I ported it to force myself to type everything out.

When I’m trying to learn about some software, I personally find it most effective to try and implement it myself. I find that by getting actual code working, it helps me understand what is going on on a deeper more meaningful level. Lately I have been wanting to understand more about how cryptographic hash functions work. Additionally, older things tend to be simpler and easier to understand before trying to build up to newer, more complex concepts.

I recently had a discussion about using static methods in ruby as convenience methods to implement the builder pattern.

I have a strong personal preference for favoring dependency injection with defaults via the #initialize method when working with collaborator objects. This frequently gives me class definitions that look like this.