edmorley

I was about to rule out Poetry due to pyup not supporting it, however it turns out Dependabot (which as a bonus looks to be more actively maintained than pyup) supports it:

https://dependabot.com/blog/announcing-poetry-support/

Another option similar to Poi, that I'd recommend adding to any comparison, is https://neutrino.js.org/

For more on the rationale behind this feature, see:

https://www.ietf.org/mail-archive/web/httpbisa/current/msg25...

https://bitsup.blogspot.co.uk/2016/05/cache-control-immutabl...

Rough summary:

> At Facebook, ... we've noticed that despite our nearly infinite expiration dates we see 10-20% of requests (depending on browser) for static resource being conditional revalidation. We believe this happens because UAs perform revalidation of requests if a user refreshes the page.

> A user who refreshes their Facebook page isn't looking for new versions of our _javascript_. Really they want updated content from our site. However UAs refresh all subresoruces of a page when the user refreshes a web page. This is designed to serve cases such as a weather site that says <img src="" ...

> Without an additional header, web sites are unable to control UA's behavior when the user uses the refresh button. UA's are rightfully hesitant in any solution that alters the long standing semantics of the refresh button (for example, not refreshing subresources).

This is certainly an interesting technique, however in this case surely git-reflog would have been easier/resulted in not losing code comments etc?

When connecting between different tube lines, much of the time users remain inside the ticketed area of the station, so only tap their Oyster/contactless card when they pass through the entrance/exit barriers at the very start and end of the journey. (Though there are a few stations where there is not a direct tunnel between lines, and travellers are required to connect via a separate street-level entrance, where they would tap their card mid-journey.)

In cases where there are multiple routes to complete a trip (eg remaining on one line vs making multiple connections for a faster journey) it was therefore previously not possible to determine what percentage of people chose which route.

I'm glad that post explicitly called them out on the deception:

> The representatives of WoSign and StartCom denied and continued to deny both of these allegations until sufficient data was collected to demonstrate that both allegations were correct. The levels of deception demonstrated by representatives of the combined company have led to Mozilla’s decision to distrust future certificates chaining up to the currently-included WoSign and StartCom root certificates.

Contrast this to WoSign's announcement:

> WoSign also made a careful investigation of these issues and issued a report on these issues, some problems have been clarified, and all problems are found in the first time and fixed. WoSign actively cooperate with the investigation and communication to guarantee the issued SSL certificate will not be affected in any way.

(https://www.wosign.com/english/News/announcement_about_Mozil...)

This makes a big difference to small projects using the $7 hobby dynos, where the $20 of the SSL Endpoint add-on made Heroku less attractive than other options.

I'm interested to know how performance compares to the add-on, which uses a dedicated ELB per app (which is why it cost $20). On the one hand I would imagine switching to this new feature removes the need to pre-warm the endpoint (https://devcenter.heroku.com/articles/ssl-endpoint#performan...), but on the other could presumably introduce noisy neighbour issues.

"we will be rolling out exciting new features to it over the coming months" ...native Let's Encrypt support perhaps? :-)

Noscript causes this for some reason