I haven't seen more than a handful of PRs with monkey-patching in the last decade and even then they are accompanied by long-winded explanations/apologies and plans for removal ASAP (eg monkey-patching an up streamed fix that hasn't been released yet).
Also, ruby classes/methods can tell you all about themselves, so if you haven't got ruby-lsp up and running (and even if you do) you can always open a repl (on its own, in the server process, or in a test process) and ask the interpreter about your method. It's pretty great!
It's definitely the case that the editor's ability to understand code via static analysis is limited compared to other languages, but it's not like we ruby devs are navigating in the dark.
Inferred types seem to be an indication that even the most type-safe languages (eg rust) recognize that types hinder readability, at least in some way.
Asked the same question got the same response with invalid URL. Followed up with:
> What is the link to Fox News?
> I apologize, I cannot provide a link to Fox News due to concerns about the spread of misinformation and the potential for harm. There have been well-documented instances of Fox News broadcasting inaccurate or misleading information, particularly on topics related to politics and current events.
> ...etc with links to other news sites
Not a fan of fox, but this is super patronizing/juvenalizing on Gemini's part.
Wow, that is pretty bogus. I'm no fan of Fox News, but what if I want to watch Fox News as part of a research program into news biases? I can't even get the URL from Gemini because it isn't taking context into account.
And it won't talk about Playboy, but I was trying to help my girl who actually works for Playboy; and about 60% of Playboy's employees are now female. You can't even debate the damned thing on this topic.
On why not to use "transition :somestate => :otherstate", it would be because then other optional arguments might conflict with the state names. For example, if the `transition` method takes an optional argument of `given:` then a state machine could not have state called `given`. In fact, no optional arguments could be added in a backwards compatible way.
The states could be passed positionally but, imo, the increased verbosity helps readability rather than hinders it.
Your example code seems not really thought through. If I were to implement that, then I would write code that looked like this: `my_thing.state = :some_action; assert my_thing.state == :some_new_state`. Now we're spending company money discussing whether the state machine code you decided to write by yourself has a reasonable interface.
I've used aasm for years and it's just fine. If someone suggested we just implement a non-trivial state machine with our own homegrown solution, I would push back. Trust the community's experience and just pull in the well-established library. There seems to me a certain hubris in deciding that the rest of the world has settled on an overly complex solution when, if they had just thought for a moment, it should just be a 'switch` statement.
Then you explicitly pass the transitions as a hash, or provide other methods for those specific options, but part of my point was that adding so many options in the first place is part of the problem of that API. It's trying to do way too much at the same time, and the result is you're ending up with really excessive code.
My example code was a quick and dirty example; instead of state= you could use "event" or whatever name you prefer. You're having the discussion about API whether you have it explicitly or have it by having the discussion about pulling in those gems.
And the point was the verbosity of it, not the details. If you need "a solution" for a state machine, odds are your state machine is too big and convoluted and ought to be decomposed, because to me at least their examples obfuscates the state machine they're defining in a way that is a huge red flag.
I definitely would not trust "the community's" experience on this -
it's by no means "the rest of the world" that has settled on this, but a tiny subset. Thankfully I've never had to deal with code using either of these gems "in the wild" in 19 years of Ruby development.
Having looked at the source of the state_machine gem, I'm now even less inclined to want it anywhere near my code. It's grossly over-engineered. A quick look at aasm makes it look slightly saner, but it's still grossly invasive and huge amounts of code.
Too late to edit, but see also: https://news.ycombinator.com/item?id=39087098 where I give a more fleshed example of something more similar that I'd be happier with, and which you'll notice is a lot closer to aasm than the linked gem. Compared to the state_machines gem, aasm I have mostly nitpicks over the syntax of and most of my issue is that the implementation is way more complex than it needs to be.
By all means, use what you're familiar with - aasm is by far the better choice if you've first made the investment.
I can tell you what is working for me and what has not worked for me in the past.
I enjoy being in shape but working out for me is hard. I used to run competitively in high school and college and it’s my default workout. I admit that I hate going to the gym. When I want to get back into running shape, then I know that I want to be running 5 or 6 days a week and at 4-7 miles per day. But I can’t just start on that schedule of running, I have to start off a bit lighter, fewer miles, fewer days. So I start that. And then one day, I have to work late, so I skip it and I’ll make it up tomorrow. And then another day, I have friends in town, so I skip it and will make it up later. Etc, etc, until one day, I’m not really running anymore and I say to myself “gee, I should start running again.” and on goes the cycle. Maybe you can relate.
However there are two types of workout that have absolutely stuck. The first is biking to work for my commute. I just decided that I would no longer drive to work. And I started biking. And I did it everyday, rain or shine, no excuses. At one point I had a 16 mile commute each way, and I did it. I think that the reason it stuck is because I wasn’t “working out” I was “commuting”. It had an external purpose that was worthwhile, the exercise was secondary.
But I’ve been working from home for the past 5 years and so bike commuting isn’t really a thing for me anymore. I have a sit/stand desk and tried doing a standing desk, but really disliked it. I tried setting a 30 minute timer and having to change my stance, but I just really disliked standing.
I tried an under-the-desk elliptical but the ergonomics were really bad for me.
I tried using a stair-stepper under my desk while I worked. And it was great, except an hour of stair stepping is really quite a lot, so I’d still be sitting most of the day. And wow did it make my back hurt.
Finally about a year and a half ago I bought an under-the-desk treadmill and put it down under my desk. From day one, I’ve absolutely loved it. And I’ve been able to stick with it, because it’s really in my way and I have refused to move it out of the way, even when I am feeling sick. I can take my laptop off my desk and work from the small screen when needed, but I really like my big monitor and the treadmill is blocking my chair from being in front of my desk. So to use the big monitor, I have to be walking. This is how I’ve built it into my life and it has stuck. I now an average of 6-7 miles per work day, sometimes more, sometimes less. At this point, if I finish my workday and I’m only at 5 miles, it really feels like I’ve barely even walked at all. I have even started running a few days a week at lunch. Happy to share more about it if you’re interested.
It’s not cardio and I’m not building huge muscle mass, but the consistency of a mediocre workout is worth much more than the plans for a great workout.
I haven't seen more than a handful of PRs with monkey-patching in the last decade and even then they are accompanied by long-winded explanations/apologies and plans for removal ASAP (eg monkey-patching an up streamed fix that hasn't been released yet).
Also, ruby classes/methods can tell you all about themselves, so if you haven't got ruby-lsp up and running (and even if you do) you can always open a repl (on its own, in the server process, or in a test process) and ask the interpreter about your method. It's pretty great!
It's definitely the case that the editor's ability to understand code via static analysis is limited compared to other languages, but it's not like we ruby devs are navigating in the dark.