In the European Union, things are going quite well. They clearly have the epidemic under control, at least for the moment. They are seeing a little over 4,000 new cases per day which is a rate of < 1/100,000 people.
In the United States, the situation is worrisome. After a long but gradual downtrend, the number of confirmed cases has been rising quickly over the last couple weeks and has begun hitting new highs. We’ve recorded over 250,000 new cases in just this last week. We should be on the lookout for a consequential rise in the number of deaths. (The spike in deaths/day on 6/25 is due to a reporting issue and can be ignored.)
The US situation varies by region.
The northernmost states in New England have only had a relatively minimal number of cases and deaths so far.
New York, the early epicenter of the COVID-19 epidemic in the US, and surrounding areas have successfully gotten their outbreaks under control and the rate of new cases has been kept manageably low. (The spike in deaths on this chart is due to a reporting issue in NJ.)
The mid-Atlantic region has improved in recent weeks, but the decline in new cases has recently leveled off and we should be on a lookout for a rise driven by increases in states to the south and west of this region.
Similar to the mid-Atlantic region, states around the Great Lakes have been improving slowly in recent weeks but new cases have recently begun climbing again.
This region’s rate of new cases per day reached an initial high point in early May, showed only moderate improvement over a month and half or so, and has recently begun increasing again.
This region is sparsely populated so the absolute numbers are small, but the rate of COVID-19 new cases per day per capita is on par with the West coast.
Growth in cases on the west coast has been slow but steadily increasing for some time. Recently new cases per day have been growing at a faster rate. They have nearly doubled over the last three weeks.
After an initial rise, cases in the southwestern states remained relatively steady at about 1000 per day until around the beginning of this month when they began to increase dramatically. They have nearly quadrupled over the last 3 weeks.
Most of the recent rise in cases in the US has been driven by increases in southern states. While the raw numbers in this region are being driven by Texas, cases in both Oklahoma and Arkansas are on a steep rise as well.
While Florida has been hitting new highs approaching 10,000 new cases per day, all states in this region have been seeing increases.
Leave a Comment
This was a frustrating issue I banged my head up against for a while, so I’m explaining it here in the hopes that it helps someone else. This isn’t actually specific to PhpDocumentor at all; that’s just where I saw it come up. Phpdoc was generating some intermediary files just fine but failing to generate its final HTML and it was spewing a bunch of messages that look like these:
PHP Warning: XSLTProcessor::importStylesheet(): error in /usr/share/php/phpDocumentor/src/phpDocumentor/Plugin/Core/Transformer/Writer/Xsl.php on line 62
PHP Warning: XSLTProcessor::importStylesheet(): Local file read for /usr/share/php/phpDocumentor/data/templates/responsive/layout.xsl refused in /usr/share/php/phpDocumentor/src/phpDocumentor/Plugin/Core/Transformer/Writer/Xsl.php on line 62
PHP Warning: XSLTProcessor::importStylesheet(): error in /usr/share/php/phpDocumentor/src/phpDocumentor/Plugin/Core/Transformer/Writer/Xsl.php on line 62
PHP Warning: XSLTProcessor::importStylesheet(): xsltLoadStyleDocument: read rights for /usr/share/php/phpDocumentor/data/templates/responsive/layout.xsl denied in /usr/share/php/phpDocumentor/src/phpDocumentor/Plugin/Core/Transformer/Writer/Xsl.php on line 62
PHP Warning: XSLTProcessor::importStylesheet(): compilation error: file /usr/share/php/phpDocumentor/data/templates/responsive/index.xsl line 3 element include in /usr/share/php/phpDocumentor/src/phpDocumentor/Plugin/Core/Transformer/Writer/Xsl.php on line 62
PHP Warning: XSLTProcessor::importStylesheet(): xsl:include : unable to load /usr/share/php/phpDocumentor/data/templates/responsive/layout.xsl in /usr/share/php/phpDocumentor/src/phpDocumentor/Plugin/Core/Transformer/Writer/Xsl.php on line 62
PHP Warning: XSLTProcessor::transformToUri(): No stylesheet associated to this object in /usr/share/php/phpDocumentor/src/phpDocumentor/Plugin/Core/Transformer/Writer/Xsl.php on line 138
A quick spin on Google helped me find other people with the same or similar problems but didn’t yield a solution. After too much time spent methodically backing out some recent changes on the system, I found that disabling PHP support for librdf (aka the Redland PHP interface) made the problem go away.
With that knowledge, a new Google search turned this up this bug report.
For now, my workaround has been to avoid using Redland PHP together with libxslt but some additional digging suggests that this problem may be resolved by using a libraptor >= version 1.9.
Leave a Comment
You’re probably familiar with the robustness principle which is usually stated as:
Be liberal in what you accept, and conservative in what you send.
When it comes to standards, I’d like to offer a corollary:
Be precise in your description and flexible in your interpretation.
An example of where this corollary could be applied is in some browser developers’ handling of HTTP’s 301 Moved Permanently responses. According to RFC 2616, section 10.3.2 301 Moved Permanently:
The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the Request-URI to one or more of the new references returned by the server, where possible. This response is cacheable unless indicated otherwise.
That’s all well and good but permanence is an elusive thing on the web. Websites and applications tend to change quite a lot, especially during development. And when aren’t they under development? Even if mistakes were never made, the ownership of domains (and therefore URIs) is subject to change.
None of that would pose a problem in this instance if it weren’t for browser developers who cache 301 responses for a resource indefinitely and use one of the returned URIs for all future references to that resource.
But, but, but! . . . That’s what the RFC says they SHOULD do, right? And isn’t a good thing that they want to be called unconditionally compliant?
Yes. But that misses the point. The phrase any future references to this resource can be quite flexibly interpreted. Any future references handled by what exactly? Some browser developers have decided it should mean any future references handled by an installation of their browser. It would be a lot more reasonable, especially from the perspective of web developers, if the browser developers simply interpreted it to mean an instance instead, at least, in the absence of specific caching instructions.
Leave a Comment
Here is an awesome rant on the feeble vision some big players have for the future of interaction design.
The author, Bret Victor, a onetime human interface inventor at Apple, complains that the vision of the future where we are sliding around pictures behind glass isn’t really visionary but just a tiny step from where we are now.
I’m inclined to agree.
Moreover, I think this vision isn’t just limited; it’s limiting too. If we can’t conceive of richer ways to interact with our computers, we’ll be restricting our ability to see what problems we can solve with them.
Leave a Comment