Of the three people I personally knew who died of colon cancer in their 30s, all were athletes or vegans. I'm not saying that caused it, but I do think it is potentially more complex than just fiber.
Is this a market advantage that is a moat? I don’t see why this wouldn’t be at best a few months lead over the competition. It’s certainly not meaningful to user acquisition.
When I joined the Air Force, they helped us fill out the clearance forms. One question was related to marijuana use in the past. The NCO helping us told us “if you have used it before, be honest. They will know.” But then followed it up with “remember: you used it less than 5 times and you didn’t like it”.
In Navy boot camp the person reviewing my security clearance application (which was filled out weeks before) was very helpful in the way he asked the critical question. “It says here you tried marijuana once. Is that true?”
"Well, some guy I didn't know very well said it was marijuana - but how would I know? All it seemed to do was make my eyes water, and give me a headache..."
A paintball gun might not invoke the federal government to hunt you down; an over-powered laser absolutely will. The FAA has a very low tolerance for that sort of thing. Do not ever, ever, ever use lasers in open air that are capable of damaging the human retina without the appropriate licenses. The last thing cities need right now is another federal agency going on a witchhunt. Firing eye-damaging lasers into the air would just serve them that excuse on a silvered platter.
The CCDs in cameras can be damaged with low-power lasers, or so I thought. No need for anything crazy. And the FAA won't become involved unless you're pointing them skyward. Pointing them across the street, or anywhere not visible from the air isn't going to sic federal agencies on you.
> And the FAA won't become involved unless you're pointing them skyward.
The point here is that 'skyward' is where the laser's beam goes when you're trying to aim it at a camera up on a pole. It's practically impossible to point a non-fixed position laser at something a non-trivial distance higher than you without spilling a large amount of laser beam into whatever happens to be behind your intended target; which is very often the sky.
The problem with this, and why SO’s downfall was completely self-inflicted, is that the correct answer from 2013 is only occasionally still the correct answer in 2018. There are a lot of other issues with SO’s general moderation policy but well and truly it was as idiotic and myopic as it was toxic.
They treated subjective questions about programming methods as if they were universal constants. It was completely antithetical to the actual pursuit of applied knowledge, or collecting and discussing best practices and patterns of software design. And it was painfully obvious for years this was as a huge problem, well before LLMs.
That said, I will say after being traumatized by having my threads repeatedly closed, I got so good at boiling down my problem to minimal reproducible examples that I almost never needed to actually post, because I’d solve it myself along the way.
So I guess it was great for training me to be a good engineer in the abstract sense. but absolutely shit at fostering any community or knowledge base.
> that the correct answer from 2013 is only occasionally still the correct answer in 2018
Exactly! They should have added proper structuring to questions/replies so that it could specifically apply for Language/library version X. Later, such a question could be answered again (either by proving it's still correct for version X+1, or by giving a new answer) - that way people wouldn't have to look at a new reply with 2 votes vs an older, possibly outdated one with 100 and make a decision which to prefer.
I don’t think you’d want to solve for plexiglass since not all zoos have that but you could just cluster sightings and if you have 1000 sightings in a very particular location it wouldn’t be hard to identify.
You can separate concerns without violating locality of behavior, and that’s exactly what tailwind does.
It admittedly does not do a good job at being very DRY but I think that’s poorly applied to HTML/CSS in general, and the most DRY css is often over abstracted to the point of becoming nigh uninterpretable.
When I write CSS, I most often do not want the locality of behavior. I instead want uniformity of behavior, hence "semantic" styles. Even the trivial light / dark mode switching is pain with Tailwind, when classes like "color-gray-200" are routinely applied.
I’d somewhat agree with you there, but I usually use variables for uniformity. I do see arguments against tailwind but find anytime I’ve tried to do anything else it just feels like bikeshedding on internals for the same end result.
Really what I want to see is beautiful TDD for CSS so that uniformity can be enforced, but I’m not sure that exists.
Variables are hugely helpful, I agreee.
IDK about bikeshedding. I'm very used to writing React code that normally declares no styles for components at all, and having CSS that style components using 1-2 classes, specific to these components. Container components control margins, <body> controls general things like fonts.
It seems that what solves the problem is a good component library. "But I need red text here!" For what reason? It's a warning. OK, we've got <Text variant="warning">, it will be styled appropriately, and will look like every other warning in the application.
I tend to think that if you're having issues with repeating yourself with stuff like tailwind you probably need to refactor your JSX/templates to share the repeated code. Keeping stuff like CSS isolated is a deliberate choice that helps massively with stuff like splitting code, and keeping changes side effect free.
