442 karma · joined May 7, 2016
Satellite data tells you pretty much everything you would need to forecast at a basic level, especially with the derived soundings.
It's a small miracle things like Rust are supported on OpenBSD at all, let alone things outside of -current.
You don't put every little decision in of course, but most projects have at least 1-2 areas where even the people involved with the decision have a hard time recollecting all the context for the decision.
The downside, at least for OP, is that they're usually something you capture at the time the decision is made - not when you're leaving a project.
I'd prefer spending $300 on something like a refurbished Thinkpad for myself, but realize that might not serve my family's desires.
Having that opinion isn't backend bias - it's likely being exposed to a variety of programming languages and having first-hand experience with the pros/cons of static vs dynamic typing.
Anything new could be termed as an example of RDD, but if that were always the case, we never would have had JavaScript in the first place. One (IMO) useful skill is determining when something new actually provides ROI or is actually a manifestation of RDD or similar.
Unless a language has really great first-class pattern matching (JavaScript does not), I don't ever want to work on a serious project in a dynamically-typed language. The guarantees provided with static-typing and the benefits when it comes to bugs, testing, and refactoring are huge.
Sure, devs that partake in RDD might move on, but there is a good use case for TS that has nothing to do with resumes, and everything to do with a preference in how to build software.
I have no idea why the Kotlin std lib has a Result type but limits it to exceptions - such a missed opportunity.
As someone else mentioned, just being aware that you have skills at various points of competency and you want to be better puts you in a subset of developers that many others enjoy working with. I have personally found success with identifying distinct skills by looking at job postings and various taxonomies and then ranking myself on the Dreyfus model of skill acquisition for each, then choosing where I want to improve.
The number one thing I'll always value in a developer is attitude - bringing positive energy to the team and being willing to adapt and learn are incredibly understated and undervalued traits.
The forward flank downdraft or rear inflow jet of a linear convective system/bow echo can see winds of 50mph+ rather commonly. The more interesting part IMO, is the rear flank downdraft, because it is closely related to tornadogenesis and can also have winds up to 100mph. The RFD is co-located with the hail core in a supercell, so some hail will get caught up in this wind that exists even when there isn't a tornado.
Now terminal velocity of your average baseball-sized hail is roughly 100mph, but you can imagine with 100mph horizontal winds that there can be a strong non-vertical component to the hail in certain portions of the storm. I've personally been hit by smaller 1-2" hail that is traveling nearly horizontal, and I've seen evidence of larger hail impacting at the same angle.
It's a safe assumption that the larger the hail is the more damaging it is, but not all hail is created equal! Depending on how accretion happens and the warmth of the atmosphere, you can have very hard 1" hail that damages cars, and very soft 2.5" hail that doesn't damage cars. My personal rule of thumb is that you need to be wary of anything 1.75"/golf ball or larger.
I think the rationale for that is twofold: that as a static typed language that prefers stack allocation, you can get some very good performance without putting much effort into it, and that it's usually clear what the idiomatic way to accomplish something is. On the latter point, I appreciate golang's simplicity when I need to review other people's code or dig into third party libraries.
For the record, I agree with most of what you're saying. I also don't find it elegant, and most developers I know are eager to work in a different language after spending any amount of time in golang. Its benefits come at the expense of expressiveness, and I never thought I'd be doing things like code gen to work around a lack of generics in 2019.
Insurance companies already know where heavy hail falls - there are several companies with products that correlate hail reports with the dual-pol radar Hydrometeor Classification Algorithm product.
Any sort of black box won't be able to assess the hardness of hail, the distribution of hail or how the wind is driving it. I've seen damage from dense, hard 1" hail cores, and I've driven through softball hail thrown out the back of a storm without any damage.
The types of storms that produce hail, usually supercellular, often have damaging straight-line winds. While out storm chasing, I've seen several gas station canopies collapse from strong winds - I'm struggling to think of a canopy solution that wouldn't have the risk of collapse.
The business can't easily and explicitly monetize "fast" to the same degree it can bloated features and ads/tracking.
That sounds close to the argument that we shouldn't do anything about climate change since the Earth naturally warms and cools.
I've traveled the Midwest and great plains extensively every year since 2009, and have watched it slowly destroy small town life. The locals fought back as much as they could, but saving an extra $50 a week ended up being too alluring, and local businesses died. I've talked to quite a few people that lament how it turned out but are completely resigned to how it happened and that it won't change.