Discover more from The Art && Science of Ruby
Life is filled with great joy
A poignant tale
Many years ago there was a rubyist called "_why the Lucky Stiff". No one knew who they were but they produced a load of ruby code that was simple, innovative and a joy to work with.
I remember when I first stumbled across Markaby - one of _why's projects. I can remember looking at it and thinking how great it was. Instead of writing loads of HTML and embedding ugly ERB
%> tags in it, instead of using HAML (which I find utterly baffling), if you want to output HTML, you just write ruby.
div.panel do p "Chunky bacon" end
<div class="panel"> <p>Chunky bacon</p> </div>
Camping was _why's equivalent of Ruby on Rails. A way of building web-applications with a ruby backend. But while Rails is big and does everything, Camping is tiny and does very little.
The Poignant Guide to Ruby
_why is best known for The Poignant Guide to Ruby. I remember reading this and thinking "these are my people, this is where I want to be".
The Poignant Guide explains the ruby language, from simple variables and blocks all the way through to meta-programming. Re-reading it this morning reminded me of things I had long forgotten. And the way it's written (and illustrated) reminded me of why I love ruby.
Angry Person Linus (of Linux fame) once described rubyists as "the weird people". When I heard this it made me proud, and I'm sure the Poignant Guide is a big part of why the rest of the world thinks we're so odd.
As an aside, I saw an interview with Angry Person Linus where he was explaining the meaning of the word
git. Apparently, it's another of those english words that has great meaning to the English (and fellow Picts, Celts and other Britons) but means nothing to Americans. Linus said "I am very egotistical; I have two major software projects and they're both named after me". He could be a rubyist.
Software Engineering and Computer Science
I never studied software engineering or computer science. I taught myself, by reading stuff, playing with stuff and then getting chucked in at the deep end in jobs where I had no clue what I was doing.
I still don't really know what
When I discovered Ruby on Rails I loved it. I loved that you could write expressive code that actually did lots of work without the code getting in your way. No matter what you think about DHH nowadays, he has a real talent for building APIs that read beautifully and are often a joy to use.
But ever since Rails came to prominence, there have been people who want to "engineer" it. There's lots and lots of bad code and even worse design decisions in Rails. Rails version 3 was a huge reset, where lots of the internals were rewritten, using principles from "Merb", a Rails competitor that was engineered properly and was significantly more efficient and well-structured. I remember trying Merb and thinking it was dry, dusty and boring. I was glad that Rails 3 retained a sense of joy.
But Rails' design decisions do have a cost.
Because ActiveRecord is a business logic layer, a set of validation tools and a persistence engine, it makes automated testing a nightmare, outside of the simplest cases.
I've spent hours in a rails
console, ploughing through the source code and trying to figure out how some of Rails' internals work.
And, as Collabor8Online gains new features, these issues are really starting to bite.
So there is a place for engineering, there's a place for "single-responsibility principles" and "immutable state" and all that other gubbins.
But you can do all that stuff without making people want to bang their heads on desks or ask their dog to sniff the two terminals on a 9v battery.
You can keep your sense of joy.
How to write code
Take small steps forward with immediate feedback
This means testing. Preferably test-first. Whether they are unit-tests, integration-tests, banana-tests or cat-dog-aadvark-tests (the terminology varies depending on who you talk to), make sure you write tests.
By doing so you are setting boundaries and expectations on what your code is supposed to do. You then do the minimum amount of work to make the test pass - so your code stays small but you know it's doing its job.
But even better, you've just written some documentation so that others can see how to use it.
Code is easy to write but hard to read
You may think the code you've just spent hours sweating over was hard work. But it's nothing like coming back to it two years later and trying to decipher what it does. Or poring over someone else's garbled nonsense so you can fix an urgent bug before your customers burn your house down.
So ensure you make it readable.
Ruby is beautifully expressive. Use that power to write code that looks like a small poem, not a set of mathematical equations.
(I often say ruby is like writing in english, python is like writing in maths)
Code spends longer in production than in development
That ten minute hack gets the task off your plate and keeps your manager happy. But that hack will get deployed to live and will live there for years. People will depend on it. It will still be there when civilisation has fallen and the sky is burning.
And some kid, who is way more talented that you will ever be, will be trying to fix it, thinking "what the buggery fuck was this fool thinking?"
There's a human being on the other side of that interface
All of these previous points boil down to this one container, umbrella, mega-point.
That code you're writing will be used by human beings.
It doesn't matter if it's a class, a gem, an API or a user-interface. There's a real, squishy, malleable and oozing person on the other side of your monitor. They have feelings, they have other, more important, things to do and you have the power to give them a brief second of joy when they use your work.
Ruby is amazing
Use that power for good.
Delight your users.
Get paid for doing a great job.
Make the person you've never met, who uses your work in circumstances you've never envisioned, goes "wow, that's really fucking nice", then forgets about it and moves on with their day.