Kickass: Charts.css. Also of interest: Which color scale to use when visualizing data.
Category Archives: Web
PHP finally blocks not run on exit
I confirmed with the following code that if you call ‘exit’ withing a ‘try’ block the ‘finally’ block does *not* execute. That’s probably what you would expect. But now we know.
register_shutdown_function( 'handle_shutdown' );
try {
exit;
}
catch ( Exception $ex ) {
echo "caught...\n";
}
finally {
echo "finally...\n";
}
function handle_shutdown() {
echo "shutdown...\n";
}
Enabling XDebug for PHP under Apache2
Putting these settings in /etc/php/7.2/apache/php.ini did the job:
[XDebug]
xdebug.profiler_enable = 1
xdebug.profiler_output_dir = /tmp/xdebug
xdebug.profiler_output_name = cachegrind.out.%p.%u.%H.%R.xt
The cachegrind files are now written to /tmp/xdebug.
CSS property usage
This popped up on lobsters today: Chrome Platform Status: CSS usage. It’s a report on the prevalence of CSS properties as found in the wild. It’s interesting. I was surprised by some things. e.g. ‘display’ and ‘position’ are more prevalent than ‘padding’ and ‘margin’.
security.txt
This security.txt looks like a good idea.
“REST” interfaces
I just wanted to get something that I’ve thought for many years on record, because I don’t think I’ve ever had the chance to discuss it much before, but I believe JSON web services (“REST APIs”) and web applications should deal only in two HTTP verbs, being: GET and POST. You use GET for queries and you use POST for submissions. All POST operations go through business logic for particular services and CRUDing URLs is a supremely bad idea, in my opinion. Just wanted to get that on record. Thanks. p.s for web applications you should 3xx on success, not 2xx on success; what you do for JSON web services is up to you, but for those 2xx is probably fine.
Introducing State Partitioning
This looks like a good idea: Introducing State Partitioning.
Practical Color Theory for People Who Code
Had a quick read of Practical Color Theory for People Who Code.
Best practices for REST API design
Over on the StackOverflow blog: Best practices for REST API design. Some of it is good but I disagree with a bunch of things. I made some notes:
* Use singular https://www.example.com/comment/list Not: https://www.example.com/comments * Use multidimensional selectors, not path/hierarchical selectors: https://www.example.com/comment/list?artist=nirvana&album=nevermind Not: https://www.example.com/album/nirvana/nevermind/comments * Use noun/verb format: https://www.example.com/comment/list https://www.example.com/comment/register https://www.example.com/comment/edit/54688 https://www.example.com/comment/view/54688 https://www.example.com/comment/reply/54688 * The [ noun, verb ] pairs map to Facilities for implementation: [ comment, list ] => CommentLister [ comment, edit ] => CommentEditor [ comment, view ] => CommentViewer Facilities have submit/render functionality and round-trip view state. * HTTP success 30x's not 2xx's. * Include a 'submission ID' on <form> elements for idempotent operations * GET and POST only, don't CRUD URLs, rather invoke business processes
The Complete CSS Grid Tutorial
The Complete CSS Grid Tutorial. Say no more.