Noel Rappin Writes Here

Last time on Better Know A Ruby Thing, we covered positional arguments, and now we’re going to move on to keyword arguments. I really did think this was going to be shorter than the last one, and then I got to the conversion between keyword and positional arguments, and then… well, it’s not shorter. (I know I said the next newsletter was going to be Conway’s Law, that’s coming, but this one moved along faster…)

Ruby has three ways to pass information from a method call to a method definition: positional arguments, keyword arguments, and block arguments. Each of these ways has: A syntax to declare an argument of that type in a method definition A syntax to declare an argument of that type in a method call A class that can can be used to convert arbitrary objects into and out of method calls A text marker that is associated with that kind of argument, *, **, or &.

I am extremely excited to say that Programming Ruby 3.3, also known as The Pickaxe Book, is now done done, finished, completely available as an ebook, and winding its way to distributors to ship to people as a genuine physical book. The PDF and ePub versions of the book are available at Pragmatic’s website. The print book should be available wherever you get print books, including Amazon and Bookshop. I’ve talked in the past about what’s in the book, what’s new, and whether you should buy it.

You have a series of test cases. They cover the same logic with different inputs. In order to get to that logic, there’s some overhead: objects have to be created first. Then there’s more logic needed to evaluate the result. What’s the best way to manage these tests? You want it to be easy to add new tests. You also want it to be clear what part of the test is different in each round and what part is just the common logistics.

Sorry for skipping a week or two – I was approving copyedits on the book that is now called Programming Ruby 3.3, because we now want to be proactive about the next release. Coincidentally, the copyedit review does relate to this newsletter. I noticed a particular code sample as I was going through the book again, and it highlights a feature of Ruby’s constant lookup that I didn’t discuss last time.

A fun thing about learning Ruby is that sometimes concepts that have the same name as in other languages have different behavior and purpose in Ruby. Today: constants They aren’t actually constant. They aren’t only used for small strings or magic literals. They aren’t even mostly used for that in most Ruby programs. Constants are one of the core pieces of Ruby and they aren’t super-well documented in the official site, so here we go…

Welcome to “Better Know A Ruby Thing”. In each one of these, we’re going to look at some feature of Ruby language, library, ecosystem, or culture and explain what it does, how it works, why it’s there, and any thing else that comes to mind. First up, method_missing. If I may be poetic for a second, method_missing represents both infinite potential, and the possibility of a second chance when you can’t figure out what to do the first time around.

Even by my standards, this one is slow to come out, so I’ll keep the intro brief. As I’ve done for the past few years, I quasi-obsessively rank the books I read, and I write about the top several. It’s 40 again this year, and again, I’m really sorry. As usual, don’t take the rankings seriously, they’re just here for some kind of organization. Book links go to Amazon Kindle pages.

I haven’t sent out a newsletter in 2022 – about 10% of people subscribed to this newsletter have never seen an actual newsletter in their mailbox. That seems like it should end, so… hi! I’m Noel. I write books, mostly about Ruby. I write this newsletter, which is normally about Ruby, Rails, Agile, and other topics, and is occasionally (like today) self-promotional. Under normal circumstances this comes out a few times a month.

Welcome. Because of the exact kind of person I am, it’s always bugged me when people put out year’s best lists in early December – the year isn’t over, what if you read or see something on, like, December 29th that changes your whole list. (I realize this is a very silly thing to be bugged by.) I traditionally get around this by putting out my favorite book lists sometime around the Ides of March.