Tag: dynamic_rubyist
Better Know A Ruby Thing: On The Use of Private Methods
Last time around, we got to Better Know access control in Ruby, and I started to write my opinion on the use of private methods in Ruby, but my position/argument/rant had gotten out of hand and so I spun it off into its own post.
This is that post.
It’s long enough as it is, let’s just get to it, we’ll skip the internal ad.
What I think about Private Methods in Ruby In Ruby, a method without side effects should be public.
Better Know A Ruby Thing: Methods and Access Control (part 1)
I’ll be honest, I picked this topic out of the half-dozen or so Better Know A Ruby Things on my to-do list strictly because it’s maybe the only Ruby take that I genuinely argue with people about. To be even more honest, it got away from me a bit as I started writing the argument: which is why I tend to avoid declaring methods private.
I know these newsletters have tended toward long, but 3100+ words was a bit much even for me, so I’ve split it in half.
Conway’s Law
If your organization has coders continually getting in each other’s way, or if you make a change to part of your code base and don’t know who needs to review it, or if you have code that nobody maintains because everybody owns it… you may be violating Conway’s Law.
Hi – I thought I’d do something a little different this time. We’ll be back to more Better Know Ruby things next time, but I’ve been sitting on this essay for a while and wanted it to get out.
Better Know A Ruby Thing #5: Block Arguments
Previously in what what I guess is now “The Argument Trilogy”, we talked about:
Positional Arguments Keyword Arguments And now the trilogy now comes to its inevitable conclusion with “Return of The Jedi” block arguments.
In the interest of keeping this thing within the plausible word count of a newsletter, we’re not going to talk about what blocks are or the way blocks behave here, that’ll be a future Better Know, but we do need to talk about block syntax.
Better Know A Ruby Thing #4: Keyword Arguments
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…)
Better Know A Ruby Thing #3: Positional Arguments
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 &.
How To Manage Duplicate Test Setup, or Can I Interest You In Weird RSpec?
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.
Better Know A Ruby Thing Bonus: Contestants and Nesting
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.
Better Know A Ruby Thing #2: Constants
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…
Better Know A Ruby Thing #1: method_missing
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.