442 karma · joined May 7, 2016
Your business idea is where you'll likely be innovating - trying to use X language/pattern/stack to do something no other developers are talking about us a good sign that you may be going down a rabbit hole.
In all seriousness, my research and speaking with specialists is that bulging or extruding disc do have blood flow and they will eventually reabsorb. Even sequestered discs with no blood flow will reabsorb. The tricky part is dealing with the symptoms while not worsening the issue.
Even after an epidural steroid injection, I've been told it could be months before my very large extrusion is gone. So it is a very slow process. The good news is that some research shows that your body can actually be better at absorbing the larger extrusions.
Especially when you have a news site getting millions of views, you simply can't afford 1 second on page load to download, parse, and eval React and your data model for little gain.
I've seen devs that are so infatuated with React and "isomorphism" that they will use it as a hammer for every screw they come across.
I've found that React generates trustworthy HTML, letting me focus on business logic and the interesting parts of development. I've never come across a scenario where React threatened the coherency of my code (other than the data attributes that are now optional, thankfully).
That being said, we did notice some single digit percentage traffic bumps when we rolled out AMP, and it felt really good telling the hordes of product/business people that I literally couldn't add the dozens of analytics scripts they wanted.
IMO (as an amateur) the bigger impact is for convective meteorologists that are continually watching satellite imagery and the work that places like CIMSS are doing in analyzing satellite imagery and detecting patterns indicative of severe weather. These detection algorithms will have a higher degree of confidence and can be triggered several minutes earlier now - possibly providing earlier warning for tornadoes.
CIMSS proving ground: https://cimss.ssec.wisc.edu/goes_r/proving-ground/SPC/SPC.ht...
If anyone is interested, IEM has a site that is rather easy to use once you find your local station ID and know how to plug it in: http://www.meteor.iastate.edu/~ckarsten/bufkit/image_loader....
Interpolation between sparse grid points can result in missing fine details, like the subtle boundaries that kick off the most violent storms in the central Plains.
Limiting to just GFS and GEM make sense from a proof of concept level, however these are long range models that play in the 10-16 day range. GFS in particular uses a 13km spaced grid that isn't convection allowing, meaning it can't model individual storms well. GFS is typically only output every 6 hours as well so it can easily get out of sync on forecasts for the day of.
It would be great to see these types of visualizations incorporate something fast and higher resolution like the HRRR or even one of the NAM/WRF 4km variants, but that is a lot more data than what is currently being ingested.
The best weather information (for US citizens) hands down is still your local NWS office. I'd recommend everyone bookmarking their site and following them on social media.
I spent years struggling with high dynamic range/contrast acutance with severe weather photography and digital cameras. Blown highlights, color noise in shadows, rough tonality through contrast transitions, etc. Specific films (not slide film like Ektachrome) were my salvation.
Also, noise is not the same as grain. If the difference is unimportant, I'd think the other nuances relevant to this conversation may be as well.
Digital has beaten 135 film, but it still hasn't beaten 120 / medium format in several key areas. I would be surprised if digital beat 4x5 in the next 10 years because there's no substantial market for such a product.
Many respectable sources estimate 35mm to approach 24MP in the best conditions with specific film, 120 to be in the 40-80MP range, and 4x5 to be 100-300MP.
Tim Parkin is one of the better commentators on this subject: http://www.sonyalpharumors.com/sony-36-megapixels-vs-6x7-vel...
To address some of your other points: good LF glass can approach 70/70/50 line pairs per mm which is still really good, diffraction doesn't affect resolution as much as some people think, and f11-f16 is the sweet spot on a lot of modern LF glass - you don't need long exposures with those apertures and Portra 400, for example.
Edit: but you are correct that chromatic aberration, distortion, and other things probably take a backseat to resolution these days, since those things are easier to correct in post.
Most any .NET site doing volume should be using TPL, because the framework is incredibly efficient at managing threads and preventing the pipeline from getting clogged. I've worked on dozens of APIs and sites that need to deal with hundreds and thousands of concurrent requests. Handling those in a synchronous fashion or hand-rolling state management is horrible and I'd never want to go back to it.
The only downside I agree with is the debugging, but that gets better with every C#/.NET/VS release, and you really shouldn't have a ton of complexity buried in your await block. If it hurts, there's a good chance you're violating SOLID.
This likely won't help improve "will it rain this afternoon at the golf course" forecasts, but it will very likely drive "we detected a thermal couplet on this supercell, let's tornado warn it" type decisions several minutes sooner.
Weather is incredibly complex and difficult to model and predict. We have multiple sources of truth to provide the input to our models: radar sites spaced hundreds of miles apart, balloons that are launched twice a day and hundreds of miles apart, METAR stations that record ground observations, satellite, etc. Satellite data is the closest you can get to seeing the entire atmosphere as an interconnected system with no gaps in data, but is limited by being a top-down view (better spectral information will help), somewhat low resolution, and 5-15 minute update intervals (storms can go from nothing to tornadic in 45 minutes).
CIMSS and other groups of researchers are doing great work with our current satellite data like identifying when supercells are likely to produce tornadoes and estimating instability in a column of the atmosphere. Increasing spectral information, resolution, and frequency will enable products to be refined and new products to come out - such as lightning detection, which currently relies on private networks.
Severe weather nowcasting is only one of the areas that will benefit from this, but the one that I'm familiar with as an amateur meteorologist. GOES-R has the potential to cut false alarm rate and increase warning times for severe weather. Weather nerds are rather excited, as this stands to be a powerful new tool.
The devs working on news sites understand the current state of bloated pages is bad and are eager to create fast, sexy pages. Unfortunately there are entities such as BizDev and AdOps that want to add more stuff to the pages to make more money, and it's easier to quantify ROI for a new ad placement compared to shaving 100ms off page load times. So we end up with dozens of scripts and script loaders and all sorts of other things. Editors and product managers want responsive pages with ad placements and enhanced functionality.
Along comes AMP, and all of the above are freaking out at the loss of control while I'm gleefully looking at super fast loading times and pages that still have most of the important functionality and ads.
Yes, the script size is large, but it will be cached amongst all AMP pages and it's refreshing to not have to think about implementing responsive pages, lazy loading, etc. because AMP handles all that.
I would suggest trying it before knocking it at a theoretical level, especially the MVC Core stuff that combines 4.X's MVC and Web API and enhances it.