MRI Ruby has gotten a lot faster since I ran my last benchmark, so it’s time for an update.
I recently refinanced my car loan with a local credit union. The refinance process is pretty easy and mostly handled over the phone, until it’s time to sign the paperwork, for which they requested an email address. A few minutes later I get an email from the credit union in which I am notified that I have a secure email waiting at the other side of a link. Upon clicking, you visit a Barracuda Network site, in which I a need an email and password to access. As I have not established a password in the past, I just need to type a new one and confirm it in another box. Easy.
Every once in a while, a process is stuck and doesn’t want to respond. I usually just found the process id by using
psand then ran
kill -9 <pid>. Why? Cargo-culting, mostly.
One of the biggest pains of using jruby is the slow startup time.
Today, I am starting a new feature for this blog. I am calling it The REPL. It’s pretty much a link page of interesting reading I have done around the web in the last week (or, more than likely, since the last issue). Of course, this is not a new idea, but I still think there might be some value to it. I will try to avoid this becoming an echo chamber and instead I will try to focus on material that has got me thinking about software engineering.
Martin Fowler explains the circuit breaker pattern. Coincidentally at work, we have been discussing using something like this for building in fault tolerance in our interactions with other services. Netflix has a library (in java) for this sort of thing and has blogged about it’s use. Embracing that failure will happen and properly preparing for it turns how you design your code on its head.
The fellows at Grouper explain how they are using the interactor gem to extract business logic from controllers and models. Again, this is a pattern that we adopted at work not too long ago. DHH gave it some flak on the hacker news comments, but it has given our team a convention on where and how to code business logic.
A cautionary tale on why it’s important to set clear boundaries between your system and the libraries and frameworks that you use.