4,752 karma · joined March 3, 2014
I don’t mean this to say “you have asked a bad question”, but rather to say, “you have asked so large a question that a man once went insane in trying to answer it.”
The other issue is crop pollination, which AFAIK has heavy reliance on commercial bees.
Philosophically: You can being building criteria for consciousness; the things you look at in yourself that tell you are, and then begin looking for that (or symptoms of that) in other people.
Anecdotally: you can totes spot "unconscious" people. You can even watch people gain consciousness, if you watch 'em in the right circumstances. You can even watch yourself regain consciousness (for me it's usually a sensation of "what was I even doing for the past day/week/month).
All of this gets at least as weird and fuzzy as trying to define "consciousness" in the first place.
Plus, Ruby has lots of easy ways for you to check typing, if you want to.
IMO - there’s a lot of things that queues are an excellent answer to. Potentially including performance.
But - queues (generally and among other things) solve the problem of “this will take some time AND the user doesn’t need an immediate response.”
If that’s not your problem, then using queues might not be the solution. If it’s something that’s taking too long and the user DOES need a response, then (as you say) optimizing is what you should try, not queues. Or some product redesign so the user either doesn’t need an immediate response. Or finding a way to split up the part producing an immediate response and the part that takes awhile.
For example: validating uploaded bulk data is in the right “shape”, and then enqueuing the full validation and insertion.
Also really really avoid jobs that enqueue jobs. Sometimes they’re necessary (spacing out some operation on chunks of a group; or a job that ONLY spawns other jobs) but mostly they’re a route to spaghetti.
Gonna name names? :)
If it doesn't find any class defining that function, it calls `method_missing` (and again, goes up the list). The Ruby base object class defines `method_missing`, so if no-other classes in the ineritance list do, you get that one (which then throws the usual error).
IMO, there is zero bloat or complexity added by this; it's super simple language bootstrapping (allowing more of Ruby to be written in Ruby, vs the c interpreter).
What do you see as the bloat and complexity added by this?
To disagree - Design patterns are a communication language. You use them to talk about code; if you use them as strict recipes they become dogma, with all the problems that entails.
Beyond that - most of the canonical design patterns are coping mechanisms for the limitations of pre-modern Java / strict OOP. You just plain don’t need them in a language like Ruby - IMO, mostly because of ‘yeild’.
The “imprecise use” is a consequence of either trying to use an unnecessary design pattern, or trying too dogmatically to adhere to one.
(I'm personally so-so on VCs; I think the core idea is pretty good but I'm not super sold on some of the implementation details - too OOP, not enough `yield`)
There's a lot of people in LA with the skills and equipment to rapidly organize like this; got to see it in person during the Occupy protests, when a tiny village popped up around City Hall - complete with power and internet infrastructure; medical, porta-potties, meals, workshops and seminars... it was pretty impressive!
It's also worth noting the insanity that is July 4th in Los Angeles, so there being a lot of fireworks is uhhh... really, really not weird for LA? We usually get increasing amounts (in size and frequency) of illegal firework "shows" all throughout June.
Lastly - there's also a big difference between "out of our [LADP's] control" and "out of control" - that's (AFAIK) actually the norm for effective protests. A large protest that's under the LAPD's control is generally a "demonstration" instead (see the women's marches).
So - maybe not doomed to an 80 year cycle, as life expectancy changes, and/or as cultural memory changes due to more/better records.
But in broad strokes... yes.
...you're gonna get bad code again, or, as you say, worse. The impact of the organizational culture dwarfs everything else.
(Like - what would it look like to clean up test results for an LLM?)
Might poke around...
What makes something a good potential tool, if the shell command can (technically) can do anything - like running tests?
(or it is just the things requiring user permission vs not?)
Related: if you want the tapiest tape to ever tape, "bi-filament tape". It's sticky as hell, cannot be torn, and you can get it in 12in (or wider!) rolls.
Also always go for a walk, touch grass, hug a tree. Pleasant physical experiences are truly effective at getting you into the “here and now”.
(Also, huh - I wonder if that’s actually directly doable; “assembled by AI out of programmed outputs”?)
def no_items?
!items.present?
end
def items
# something lone
end
memoize :items, ttl: 60, max_size: 10`
just makes sure the expensive operation results in a truthy value, then add some sugar for the falsey value, done.It's this:
1. You: I am having problem X 2. Them: You are having problem X. 3. Them: Here are possible solutions.
There are lots of variations on this. There are also multiple reasons to do it: validation and calibration being (AFAIK) the main ones. One way to look at it is that validation says I'm not going to fight you about your subjective experience.
Contrast:
1. You: I am having problem X 2. Them: Here are possible solutions.
This can come across as "your problem will be fixed but you do not matter".
Contrast:
1. You: I am having problem X 2. Them: You are not having problem X.
Now it's an argument.
If you go from 100mil in assets to 10m, you’re fine. If you go from 100k to 10k, you’re not.
https://www.ruby-lang.org/en/news/2020/12/25/ruby-3-0-0-rele...