Two things can be true:
- police should enforce the law to reduce or address crime or infractions
- police should have a standard of enforcement that corresponds with the way the court system should operate, which is that the state carries the burden of proving the crime
The right to demand a blood test or other mechanism of having the state own the burden of proof might be inconvenient but it's integral to a fairly operating system, just like the right to demand a lawyer or representation.
This is such a conflicting comment for me because I agree with so much but also have so many quibbles. That said I think that the other comments cover most things, I'll just comment on b: I don't think this is a problem that a language should solve or needs to solve, since there is a new flavor of the week of network protocols every few years. off the top of my head
- REST (mentioned, but what kind of REST? Rails style REST? Just plain http resource endpoints?
- GraphQL (mentioned)
- gRPC
- SOAP
- JSON-RPC
- Thrift
- CGI (ok not really in the same category as the above)
- Some weird adhoc thing someone created at 3am for "efficiency"
Correct me if I'm wrong but I believe you're interpreting this as if the rails app needs the same amount of is that exists in the described vite solution.
But in reality if you're using hotwire you can get away with almost no JavaScript at all comparatively. That's why stimulus is in vanilla js generally, it's meant for sprinkling behavior onto the dom vs controlling the dom.
So if you don't have a js framework that needs to control the whole Dom and doesn't need a gigantic optimization step or tree shaking or typescript or whatever, you can get away with a whole lot less than it you embraced those frameworks that _do_ want to own the dom wholesale.
You can and should break that up because I'm probably going to want to see screenshots to ensure that the branding changes make sense in context and everything looks consistent.
How would you do this? You'd either
1. Create N pull requests then merge all of them together into a big PR that would get merged into mainline at once
2. Do the same thing but do a bit of octopus merging since git merge can take multiple branches as arguments. Since most source control strategies are locked down, this isn't usually something that I can tell my juniors to do
The point of breaking things down like this is to minimize reviewer context. With bigger PRs there's a human tendency to try and hold the whole thing in your head at once, even if parts of the pull request are independent from others.
> The point of breaking things down like this is to minimize reviewer context.
This principle is much more important than some rule that says "Merges to main should not be more than 150 lines long". Sticklers for hard-and-fast rules usually haven't achieved the experience to know that adhering to fundamental principles will occasionally direct you to break the rules.
> Merges to main should not be more than 150 lines long
This can be done by allowing a flag in the commit message that bypasses the 150 line long (or whatever example) rule in the CI that enforces it. Then the reviewers and submitter can agree whether or not it makes sense to bypass the rule for this specific case.
In many cases like this, it's okay to override a rule if the people in charge of keeping the codebase healthy agree it's a special case.
minimizing reviewer context is one thing a PR can try to do, but it's not like that's any kind of universal most-important metric that every PR needs to optimize for, in fact very often minimizing reviewer context is in direct tension with making changes that are holistic and coherent
One thing that I've wondered is why sorbet didn't choose to use the stabby lambda syntax to denote function signatures?
sig ->(_: MyData) { }
def self.example(my_data)
...
end
Obviously this opens up a potential can of worms of a dynamic static type system, but it looks sufficiently close enough to just ruby. My opinion is that sorbet doesn't lean into the weirdness of ruby enough, so while it has the potential to be an amazingly productive tool, this is the same community that (mostly) embraces multiple ways of doing things for aesthetic purposes. For example you could get the default values of the lambda above to determine the types of the args by calling the lambda with dummy values and capturing via binding.
Personally having written ruby/rails/c#/etc and having been on a dev productivity team myself, I say: lean into the weird shit and make a dsl for this since that's what it wants to be anyways. People will always complain, especially with ruby/rails.
I don’t know if there’s a Ruby reflection API to produce the values of default keyword arguments in a lambda, but correct me if that’s not the case. This syntax is neat enough to be worth spending some time thinking about if you can correct me.
Not everyone has impeccable brushing habits and reducing cavities is a net benefit to public health like sanitation departments. I would be more interested to see a source as to why you think there's no benefit to fluorinated water when there are studies that are a quick search away for fluorinated water.
> reducing cavities is a net benefit to public health like sanitation departments
what is the connection between reducing cavities and sanitation departments? cavities are not communicable.
Also, the paper you linked is my point. there's no actual benefit of ingestion. the effect is purely incidental. it's more effective to apply fluoride to the teeth. nowhere does it actually explain that drinking it is what is beneficial. the difference in the incidence of caries is because by fluoridating the water it obviously will touch teeth, which has well known positive effects.
the main conclusion of the paper is what everyone should hopefully know already - brush your teeth regularly with fluoride toothpaste.
out of curiosity, would you be OK with vitamins being added to the water? most people are deficient in many.
> would you be OK with vitamins being added to the water?
Provided there's reasonable scientific evidence that this is fine and effective and not expensive, I don't see why not. I don't think I've ever seen it proposed.
that is good to know. fundamentally we'll have to agree to disagree. I do not agree with experimentation with the populace's water supply as a matter of principal. fyi there's already plenty of evidence that supplements are useful for those that are sufficient. of course the main counter argument is that if you're eating a balanced diet supplements are unnecessary (which is true). though that's just about as helpful as saying water fluoridation is unnecessary because you can brush your teeth (which is also true).
Whilst I can see your point of view, I think that fluoride in water is an issue that provoked knee-jerk reactions.
Here in the UK, there's areas with and without fluoridisation - the reason being that naturally the water in different areas has different fluoride concentrations with some areas having no need for adding fluoride as it's already there. The benefits were very easy to determine as (presumably) cavities were more common in those areas with low fluoride content, so it's less about experimentation and more about ensuring that more people can gain the same benefit.
There’s a left-right split on the issue in America, which leads to a lot of specious and lazy reasoning, breaking away from typical impulses to have clean unpolluted tap water, etc.
Natural water supply has feces, bacteria, etc too. Civilization has progressed because we have managed to remove them from the water and provide clean water to the masses.
So what you're saying is that, as educated humans with access to decades of scientific research, we can use that research to make decisions about treatment plans for water to keep our population healthy?
Despite consensus this benefits dental health (an important part of heart health) and has no side effects, and the reality that municipalities that already banned fluoride suffered a huge upturn dental issues - particular in children who don't brush as often.
I'm sure the state is ensuring that this little experiment doesn't harm anybody by guaranteeing access to dental care, right? Putting our money where our mouth is and making sure that if they're doing demonstrable harm that anyone affected is compensated?
Oh, no, the poors can just deal with it? Nice.
Makes sense in a bill about "freedom and liberty" that also bans transporting mushrooms that naturally grow in the state and flying drones above farms.
the consensus was that ddt was okay too, and the current consensus is that oil is not a big enough issue to bother with.
the state didn't feed small children radioactive oatmeal for fun oh wait
imo, water is one of those things we should keep simple. today they add fluoride, tomorrow what? maybe "brushing people's teeth for them" in the name of convenience is doing people a disservice. pick up healthy habits or get lost.
signed, fluoride free toothpaste user and boiled tap water drinker.
as for the mushrooms, i agree that it's a stupid law
Not sure why you're being confrontational? I'm not the OP but it's clear there's some misunderstanding
The quote is:
- neat
- plausible
- wrong
"Just get rid of the cancer" is
- neat because it sounds obvious and tidy
- plausible because we can and do cut out cancer
- wrong because it ignores the nuance that cutting into a patient's body can have massive impacts on long term health. It can also be wrong because certain cancers have no tumor sites.
Generally agree with your points about how semver isn't really necessary. I suppose the benefit here would be that dep management tools like dependabot could automatically raise pull requests when a new version is released, which would be pretty cool. If only my peer engineers actually paid attention to dependency updates.
As an aside, instead of an auto incrementing build number I'd suggest the git sha since it's:
1. Already there and points to a specific version of the code in the repo
2. Globally unique
3. Can assist with reproducible builds (i.e. 6afed54 was acting weird, let's build it locally and take a look)
4. Gives you an easy diff target to dump "release notes". Just diff to the previous and dump the merge commit messages.
If you're encountering these problems at scale where scale is up to the reader, I can promise you that you're already writing SQL. You might have already started from the beginning by writing direct SQL, because that's something that rails also allows you to do against a model. Apart from juniors, I don't think I've ever met anyone who actually said that they wanted to avoid writing SQL in all cases. The reality is that it's far more useful and efficient to burn cpu time than dev time, and ORMs general tend towards the latter than the former in the favor of generally being a fair bit more legible (depending on the writer).
The right to demand a blood test or other mechanism of having the state own the burden of proof might be inconvenient but it's integral to a fairly operating system, just like the right to demand a lawyer or representation.