I work in technology sector. And I do round a clock, not only from 9 to 5. It is my bread and butter, it is my hobby, it is the fascination of my life. And with the current rate of change particular in information technology (IT), there is always something new to learn, to try, to talk about. I often post news, thoughts, and reviews. And when I do, this is the category I use.
I came across this interesting dive into monitoring, troubleshooting, and replaying JavaScript errors from the userland – “A user encounters a JavaScript error. You’ll never guess what happens next!!“.
This is not something immediately applicable for my projects at work, but gives me a lot to think about.
rector looks like an excellent tool for those days when you need to rewrite large chunks of legacy code for the modern coding standards and best practices. Of course, there are IDEs that can help a lot with refactoring, but they are usually complex and slow. Regular expressions have always been a poor man’s choice for replacing old code with new code. But life can be easier and better. rector helps you find and replace things like namespaces, class names, method names and property names; change type hints and values of parameters; replace magic methods with their real implementations, and much more.
I’m sure I’ll be trying it out Real Soon Now ™, with the upcoming release of CakePHP 3.6.
“PHP-FPM tuning: Using ‘pm static’ for Max Performance” looks at different process management settings in PHP-FPM: static, dynamic, and ondemand, and the way they affect performance. The default – ondemand – might work well for you if you have a large server with plenty of resources and not so many actual visitors. Running on a smaller instance, or expecting high spikes of traffic might require you to look into your PHP-FPM configuration and adjust it. The article is just what the doctor ordered.
Personally, I prefer having a dedicated instance for the web server, but that instance being as small as possible. With that, figuring out the correct settings for static process management is easier. It also minimizes all those nasty cases of running out of memory, swapping, and having an excessive CPU utilization.  Which is especially useful when running on Amazon AWS instances.
These are some sad, sad news, folks – Linux Journal is closing down:
EOF
It looks like we’re at the end, folks. If all goes according to a plan we’d rather not have, the November issue of Linux Journal was our last.
The simple fact is that we’ve run out of money, and options along with it. We never had a wealthy corporate parent or deep pockets of our own, and that made us an anomaly among publishers, from start to finish. While we got to be good at flying close to the ground for a long time, we lost what little elevation we had in November, when the scale finally tipped irrevocably to the negative.
I’ve been a subscriber of the Linux Journal for many years (just not the most recent ones), and I’ve learned a lot from it. It’s very sad to see it go, even though it’s been years since I read it last.
After I upgraded my laptop to Fedora 27, I started experiencing some weird issues with most of the projects I am developing locally. Trying to save anything into the database that involves dates, started throwing the following errors:
Error:Â SQLSTATE[22007]: Invalid datetime format: 1292 Incorrect datetime value: '2017-11-30T13:30:48+02:00' for column 'timestamp' at row 1
A quick look around showed that Fedora 27 ships MariaDB v10.2, while the previous distribution version shipped MariaDB v10.1. Digging through the changes between the two versions didn’t help much, even though there is slight mention of the related change.
SQL_MODE has been changed; in particular, NOT NULL fields with no default will no longer fall back to a dummy value for inserts which do not specify a value for that field.
StackOverflow is much more helpful, as always. These two threads – one and two – in particular, explained the changes and suggested the fix. I had to either fix the projects I was working on, or modify my local configuration to use the old SQL mode. This thread provided some more details, so the final solution was adding the following to the /etc/my.cnf and restarting the MariaDB service:
[mysqld] sql-mode="NO_ZERO_IN_DATE,NO_ZERO_DATE"
And now we are back to normal.