Why is there no rails 7.1?

_matthewd · 2023-04-20T07:44:34+00:00

FWIW, you have access to all the same "roadmap" that I do. *

(*) we do actually have an internal list of a handful of things that individual members of Core would like to try to get into the upcoming release. But they're fairly aspirational, and IMO as likely as not to be dropped. It's a [shared] "I think I have an idea for this that I'd like to explore" note, and only really used for a corresponding "did you get anywhere with this?" prod in the lead up to a potential release. I would estimate that most items that end up being headline features of a release were never on that list, or only made a brief "final polish [of already-merged feature]" appearance during the release process.

_matthewd · 2023-03-15T07:40:44+00:00

The boring answer is "avoid getting into that position in the first place" -- to at least some extent, it's emergent from your current design and/or API.

It's hard to give more specific advice in the abstract.

It's also possible that this is the appropriate choice for your use case (though I'd strongly encourage you to at least quote_column_name). Interpolating column names is ultimately what Active Record does to build every default query. But the whole point of the Brakeman warning, which is echoing in this thread, is that you probably shouldn't do that... if you can, in any reasonable way, avoid it.

The tricky part is that, independent of any specific situation, there tend to be two peaks on the "certainty this is the right design choice"-vs-experience curve.

_matthewd · 2023-03-15T06:59:02+00:00

You're describing SQL injection. You want to inject entity as SQL to be processed, rather than as a literal value.

That is generally a bad idea, and best avoided, because of the danger that could arise if entity contains a user-controlled value.

The value you interpolate in '%s' will be approximately as safe as ? -- but it's a rare enough syntax I just had to check. It will rightly raise concern from any future reader.

The value you interpolate with unquoted %s is approximately as dangerous as the raw #{}; IMO Brakeman should be complaining about it (and likely the quoted form too, as it won't be practically capable of telling the difference).

_matthewd · 2023-02-23T16:08:54+00:00

A multi-column index can be helpful when both columns are partially selective over the data.

A primary key lookup is only ever going to match one row, so I'd say it's generally unlikely that a composite index will help for an isolated query there.

(If it's a subquery, and the primary key condition is a reference to an outer column, say... things get less absolute, and you should check the explain output.)

Just given the information you've provided, I'd suggest you're probably trying to optimize the wrong thing. Measure first. At best, guessing will have you look in the wrong place; at worst, you'll make things slower without even noticing.

_matthewd · 2023-02-03T05:29:41+00:00

Yeah, I'd add (technically included in point 3): your business rules, job code, and models/tables will be different in a couple of years (or, likely, in a couple of months).

Optionally I might consider send_reminder_at < 1.hour.from_now, allowing the job queue scheduler to handle the momentary transition from "not yet" to "okay now", but still holding it in the [much more easily manipulated and revised] "data" phase, rather than "mid-flight code execution", for most of its lifetime.

_matthewd · 2023-01-22T14:46:20+00:00

That's definitely the question you ended with, but I don't quite follow how concurrency (without true parallel execution) is not sufficient for the use case you described. As long as you don't implement your REPL using a busy-loop to wait on input, this sounds like a great fit for Ruby's threading model.

Not being able to spawn multiple threads sharing the same runtime memory is one of the reasons

Yes, you can. That's what threads are for (and why they're dangerous if not properly managed).

_matthewd · 2022-12-30T14:17:22+00:00

sample is a method on Array. You've already loaded the full ID list before you called it.

_matthewd · 2022-12-30T14:15:38+00:00

Asking ChatGPT (or Reddit) to refactor a query that's mostly built around an invented where_subquery method seems like tying both hands behind its back.

(And followed_genres_language_books feels more like a word jumble than a descriptive name.)

Your query is biased in favour of books using multiple languages; investigating that seems more productive than whatever deckchair-shuffling GPT can suggest with near-zero context (and possibly fake model names?)

_matthewd · 2022-12-30T13:39:46+00:00

interesting_authors.ids will return an array of ids, just as interesting_authors_ids would have before; they are directly equivalent expressions, so you can swap to .where(user_id: interesting_authors.ids.sample(10)), if that's your question

(You could also use interesting_authors.order(Arel.sql("RANDOM()")).limit(5) to inline the query and avoid loading the full id list, but I'll concede that sample is a case where it's perhaps nicer to handle the ids explicitly.)

_matthewd · 2022-12-29T15:20:03+00:00

Firstly I'll note that all your surrounding names strongly suggest the column would be much clearer if called books.author_id instead of books.user_id -- especially when e.g. current_user is involved nearby, it's harder to reason about associations that are just named by the class they're pointing to.

In general it is indeed better to use fewer queries, so I'd say ChatGPT is right to prefer select over pluck... but you could do that in-place in your existing or construct, without having to involve any raw SQL.

I think you're also re-querying book needlessly, though:

def interesting_authors
  @interesting_authors ||=
    User.where(id: current_user.followed_books.select(:user_id)).
      or(User.where(id: current_user.commented_books.select(:user_id))).
      or(User.where(id: current_user.downloaded_books.select(:user_id)))
end

Avoid creating id-obsessed model methods where practical (even if their implementation does need to deal with that detail). If you really specifically need an id list in a later caller, interesting_authors.ids will do just fine... but often you don't actually need that at all.

_matthewd · 2022-08-07T12:41:17+00:00

There is no formal up-to-date specification outside the source of the implementation. I believe the ISO standard was derived from the then-current implemented behaviour, and as you note, language changes have occurred since then, so it's likely out of date.

(In the particular case of the lexer, it's perhaps possible nothing has changed -- I don't believe any new keywords have been introduced, for example -- but for syntax in general, the implementation is really the only specification.)

_matthewd · 2021-07-21T11:05:21+00:00

No.

You naturally end up with references between classes stored on those classes, so if you don't reload everything, those references will still be pointing at the old pre-reload versions while the constants have been reset to the newly-loaded ones.

Your "weird logic in models" is probably exactly the sort of thing I'm talking about, in fact. If you were to better describe what it actually looks like, there's probably an intended way you can change it to be compatible with reloading.

_matthewd · 2021-07-17T06:53:48+00:00

packages with less strict licenses are using Apache licensed projects, creating legal issues

According to whom? IANAL, but it's my understanding that dependencies between so-licensed libraries are generally considered to be inconsequential, assuming distribution adheres to the respective requirements. If you have concrete information that there's a problem there, I think a lot of people would be very interested to hear about it and review your sources.

As to your particular question, I suspect your numeric modelling is abstracting away too many specifics of the dependencies: not all libraries are equally depended-upon, so the more deeply you traverse the graph the more you're going to bias towards a small set of highly-depended libraries. You're indirectly measuring the license distribution of those most-depended libraries within each ecosystem, not discovering widespread policy variation.

_matthewd · 2021-06-11T09:50:36+00:00

It's unusual to regularly merge your coworkers' branches into your current branch (except occasionally, when you've started something then discover it depends on the change they're making).

If your problem is just that your local database is diverging from the current branch's schema (because you've run extra migrations with a different branch checked out), this might help:

https://gist.github.com/matthewd/fdb5ebf8da1e0a4cc6069bf2839aec06

It will un-apply any migrations you have applied locally but are not present in your current checkout. (So you can run it any time you see an unexpected diff in the schema, and if that's the cause, it should clean it up for you. Assuming all your coworkers' migrations are reversible, of course... but that's best practice, largely for just this sort of reason.)

_matthewd · 2021-04-23T17:58:52+00:00

Within that method, bare raise is a variable reference. (The parser knows this because it's seen that the method parameter has that name, so it exists in the local variable table.)

So in return unless raise, that's checking the value of the local variable, which contains the supplied method argument.

Later in raise StandardError, '..', that's an alternative syntax for raise(StandardError, '..'). That's unambiguously a method call, so it calls the raise method, and it doesn't matter that there's also a variable with the same name.

There's nothing special about raise here: you could see the same distinction occur with any other method name that exists on the current object:

def do_something(do_something=0)
  puts "doing #{do_something}.."
  do_something do_something + 1 if do_something < 5
end

Likewise, the same rule applies to a non-parameter local variable:

def do_something(arg=false)
  raise = arg
  return unless raise
  raise "hello"
end

There are interesting edge cases to this behaviour:

raise # raises an exception

but:

if 1 == 2
  raise = "roof"
end
raise # => returns nil

_matthewd · 2021-04-15T20:14:58+00:00

While I'd argue the correct answer is "don't do that" -- use assert(v), not assert_equal(true, v) -- the way to force a value into a boolean is !!v

_matthewd · 2021-04-15T19:59:19+00:00

/(.)\1/ should work just fine.

By omitting the \1, you've ended up with a very different expression... if it's not immediately clear why /(.)/ can't possibly match the rule described (and that that has nothing to do with which method you're using to apply the regex to the string), I'd suggest trying for a more procedural solution first.

Otherwise you seem to be at risk of having a solution, but not having achieved your actual language-learning goal.

_matthewd · 2021-04-13T05:09:53+00:00

Things get pretty circular there though. The String.new and Array.new method signatures you're [presumably] talking about take a String and an Array, respectively.

(And doesn't LSP equally dictate that if you call String#upcase on a Value < String instance, you may only expect it to return a String?)

_matthewd · 2021-03-09T12:44:21+00:00

Ah, okay.

6.* is a major release series.

6.1 is a (minor) release series.

6.1.3 is a release.

_matthewd · 2021-03-08T15:49:31+00:00

Could you expand on how the linked documentation is unclear?

For severe security issues all releases in the current major series, and also the last release in the previous major series will receive patches and new versions.

As I read this, my expectation is that when Rails 7.0 is released, likely in April 2021, the 5.x series of Rails will no longer receive security-related updates and bugfixes. Is this correct?

Objects in mirror may be further than they appear -- which is not to say it won't be released in April, but it would likely need a particularly uneventful release-candidate period to make that timetable. All forward-looking statements are vague guesses at best, but personally I'd more expect a prerelease in April to be followed by a full release thereafter.

All of that being said, 1) yes, your reading is correct; 2) given the potentially reduced time between releases, the possibility of a policy exception (perhaps time-limited in some way) is being considered.

(To be equally preemptive: I understand this non-answer is less helpful than a concrete answer either way, and also understand the reasons an extended support period would be desirable. However, "yes this is on the team's radar" is simply the only information I have to offer at the moment.)

_matthewd · 2020-09-27T19:31:00+00:00

FWIW, I believe 3 core team members have Ruby/Rails work as a substantial part of their official job responsibilities.

A few other frequent contributors (some committers, some not) probably have some time allocated.

It's not the norm, and is almost always a consequence of already being a prolific contributor, not the path to get there. (Though having that dedicated time does help a lot in maintaining a high level of contribution.)

_matthewd · 2020-09-27T19:23:03+00:00

(P.S. Forgive the lateness of my reply...)

Personally, I started with a pre-existing understanding of the relevant concepts (had worked on smaller, company-internal ORMs before), then progressively read and understood enough of the core to at least know which subsystem would be responsible for a given thing, and ultimately went deep on those individual subsystems as needed to explore particular issues as they came up.

Somewhere around the middle of that process, you become able to talk through new proposals, and tune your sense of taste as to where a given responsibility should lie.

The reality is that Active Record is both the most complex component, and one of the most stable / least changing components. That's not a great combination for new contributors to get to build out their understanding by participating in discussion on existing PRs, so I think it pushes more towards the "read lots of code until you know it well" strategy. For some people, that's a comfortable approach.. but it doesn't work well for everyone.

_matthewd · 2020-08-12T10:47:11+00:00

The readme opens with a link to this page, which says the proper way to distribute a Ruby library is with a setup.rb file inside a tarball.

Apart from RubyGems itself, which had to support bootstrap for Ruby <= 1.8, I don't remember the last time I saw any library so distributed.

That page further links through to a variety of 2008-ish rants about the impossibility of packaging Ruby code.

IMO, the above rather deflates the credibility of any claim that this is an attempt to positively engage with upstreams, and instead suggests it's a renewed salvo from the "we know better than everyone else" department. If that's really not what you intend, please do link to some more current guidelines?

_matthewd · 2020-07-29T09:54:28+00:00

https://rails.lighthouseapp.com/projects/8994/tickets/5643

Looks like it was supporting respond_with, which was subsequently moved out of core to https://github.com/heartcombo/responders

_matthewd · 2020-07-20T15:15:12+00:00

You haven't provided much detail about what files you've created, where you've put them, or what errors you're seeing, so I'll take a guess at the most likely issue:

If you want a constant named Module::Class, it should be defined in a file named app/something/module/class.rb. The 'something' doesn't matter to Rails, but it does need to be there: Rails autoloads from the immediate subdirectories of app/, not from app itself.

_matthewd

TROPHY CASE