There’s a cool mind map covering all the things a rails developer needs to know over here: This is Why Learning Rails is Hard.
Category Archives: Programming
Camel case
Today I read up on Camel case over on Wikipedia.
CSRF, CORS, and HTTP Security headers Demystified
This on Hacker News today: CSRF, CORS, and HTTP Security headers Demystified.
The above article referred to OWASP SameSite doco, and you can read about how to implement that with PHP.
136 facts every web dev should know
I found this fun list of things to know: 136 facts every web dev should know before they burn out and turn to landscape painting or nude modelling.
I particularly liked these points:
124. Web dev frameworks are for organisations, not small software teams or individual developers. The value frameworks provide lies in bridging team boundaries: they create a shared understanding that aids in collaboration across groups, simplify messaging, and establish clear conventions. Frameworks turn teams in large organisations into service interfaces.
125. Individual teams or individual developers don’t have that problem, so they get less value from a web dev framework. The more opinionated the framework is and the more of the web platform it abstracts away, the more its value proposition skews towards solving organisational problems and the less value it provides to individual teams.
HTML boilerplate
See My current HTML boilerplate for some good ideas for a starting place for HTML content. I kept a copy, here.
PHP in 2021
A nice write up on PHP’s recent successes: PHP in 2021.
PHP prepared statements and stored procedures
Here’s some good documentation on PHP prepared statements and stored procedures including how to call stored procedures with output parameters.
Installing zstd lib for PHP
To get the zstd_compress PHP function:
# apt install php7.2-dev # pecl install zstd
Then add “extension=zstd.so” to php.ini.
The Architecture Behind A One-Person Tech Startup
This on HN today: The Architecture Behind A One-Person Tech Startup.
Do you need to call PDOStatement::closeCursor when you’re done with the statement?
The answer is no, so long as you’re not preparing to execute the statement again. I figured this out by looking at the code for PDOStatement::closeCursor and the MySQL implementation. Seems to me that all the freeing necessary is done in the destructor so if you’re not planning to use the statement again it seems to me that you can safely omit the call to PDOStatement::closeCursor(). On the other hand if you are going to reuse the statement calling closeCursor seems like it’s a pretty important thing to do. It would be nice if PDOStatement::fetchAll() called closeCursor() for us, but I don’t think it does.