ssfak

Related: https://http1mustdie.com/

In Go you can ignore the error value though, and use directly the returned value (`int` in your example). In Rust you cannot do that, you need to unwrap the Result or use the `?`

chartsdb[1][2] can be installed locally (or run through Docker) and import your database schema

[1] https://chartdb.io/ [2]: https://github.com/chartdb/chartdb

Using the pg_duckdb[1] is an option, if you can install extensions on your setup.

[1]. https://github.com/duckdb/pg_duckdb

For Python tasks you can check Prefect, among others..

I was expecting something like sending a payload with GET requests is not prohibited by the standard...

More adequate title would be "C++ problems with C"..

Indeed, "Mostly functional" programming does not work: https://queue.acm.org/detail.cfm?id=2611829

The findings are well known, but I find it a bit ironic that the authors provide supplementary material as an Excel file...

..and closures

I believe in the majority of cases SSE are a better technology than web sockets (e.g. WS do not seem to conform to HTTP/2.0, SSE offer transparent (browser-supported) reconnects, SSE event ids allow for replay, etc). The downside is no support in IE/Edge (you can vote at https://goo.gl/bd8V1K), no binary content (but again usually JSON is enough) and no fully bidirectional communication.

A good talk at the matter can be found at https://youtu.be/NDDp7BiSad4

I am a bit puzzled about the scalability of listen/notify in Postgres and its use in the article. Each "listener" in the code requires a connection in the database so it's not a good design to have one listen "query" for each user. You will probably need a dedicated connection in a thread (or a limited number of connections) for the database listening functionality. You can possibly use some async PG driver but still on the database end I am not sure how efficient and scalable this solution will be.

I can assume that this is a good solution if you don't have (need) a high rate of "notify" statements and a high number of subscribers waiting on "listen". Any comments on these limits of PostgreSQL?

cough sci-hub.cc cough

Doesn't a TLS terminator proxy solve this? E.g. I usually put my application services behind HTTPS-enabled nginx and it works wonderfully.

For windows functions a good tutorial can be found at http://tapoueh.org/blog/2013/08/20-Window-Functions

Postgresql also has good support for SQL-99 : http://www.slideshare.net/MarkusWinand/modern-sql

WITH clauses (CTE) are great, but they are "optimization fences" in Postgresql : http://blog.2ndquadrant.com/postgresql-ctes-are-optimization...

Well, he recommends to stick to a specific schedule (having a walk at 21:30, going to sleep at 22:00, waking up at 06:00, etc) The exact times do not really matter, but sticking to a specific time schedule is problematic IMHO when you have a family because of the non-determinism introduced (especially by the kids).. Unless everyone in your family agrees to follow (and stick to) a similar schedule..

Somewhat similar but more useful for debugging "HTTP caching" by Mark Nottingham: redbot (http://redbot.org/)

> This re-imagines passwords as nouns. As a side effect, you get a complete log of whenever anyone changes their password or requests to reset it. > Want to enforce password reuse policies? Do analysis of password lifetimes? Track down malicious abuse of your password reset system? > Those things are now pretty easy with a schema like this

I am also proponent of the more "resource oriented" view of an application but I fail to see how the CRUD approach you proposed is unique in order to support the above.. Because, all of the things that you mentioned can be also implemented/supported if you transmit the tokens in query strings. I.e. /password/:token and /reset_password/?token=:token are more or less the same thing from the REST point of view although the first is more user friendly, cache friedly, etc. After all URIs are opaque to the client: http://www.w3.org/DesignIssues/Axioms.html#opaque and that's where HATEOAS enters so the client just needs to know a single (bookmark) URI and the hypermedia will guide to the creation of the rest resource identifiers needed by the application (HATEOAS is indeed the "highest level" of REST: http://martinfowler.com/articles/richardsonMaturityModel.htm...).

Unless you mean that by following the 'noun'-oriented view of the password tokens you can easily spot these operations in the apache logs.. to which I agree if you also include the user id in these URIs...

Instead of "long polling" (or a different way to have long polling) is to use the HTML5's server sent events (http://www.w3.org/TR/eventsource/) See here for examples: http://www.html5rocks.com/en/tutorials/eventsource/basics/

I have implemented such a functionality for real time monitoring using gevent and works extremely well. This HTML5 feature is supported in recent versions of Chrome, Opera, and Safari and in the beta versions of Firefox, but not in any version of IE: http://caniuse.com/#feat=eventsource