All posts across the whole website belong to this category. They might also belong to some other categories as well, but this one holds all of them. Hence the descriptive name – All.
One of the many reasons for abandoning this blog was the lack of the proper mobile app. Earlier versions of the WordPress for mobile were very limited. They were lagging behind the fast-paced development of the web application.
Giving it a try now, I already see that there was a significant progress. The UI is much cleaner and easier. Block editor is supported. And there are probably large improvements in the media handling. Although, that is yet to be tested.
This gives me hope…
Well, that’s been a long time since I posted anything here. And a lot has happened since. I’m going to revive this blog in the next few hours, days, weeks, months. Stay tuned.
PHP, the language that has truly changed the web, is celebrating its 25th birthday. Over time, it gained an army of fans and army of haters, and it’s still difficult to tell which one is larger.
As someone who is using the language since its early days (yes, PHP 3), I’m glad to see that it is still around, it is still going strong, and it is still vital for the larger portions of the web.
Huge thanks go to the core development team, community, and millions of contributors and users. It wouldn’t have been the same without you. Happy birthday, PHP!
And here’s an awesome timeline to help you remember all the years!
It’s not that often that I come across a useful, but undocumented feature in a major software application. It happened recently, so I’ll document it here just for the future self.
For a particular setup, I had to send additional HTTP headers (let’s use X-GEOIP for this example) to the PHP-FPM, which was configured as a FastCGI backend in Nginx web server. This StackOverflow thread suggested several solutions, but this one was the easiest and worked like a charm: use Nginx’s fastcgi_param directive AND prefix your variables with HTTP_. For example:
location ~ \.php$ {
fastcgi_param HTTP_X_GEOIP $geoip;
... other settings
}
With the constant expansion of cloud providers and services, one would think everything is possible and easy these days. Well, at work, we came across an interesting project which shed some light on the lesser discussed areas of cloud providers and services – macOS.
Both Linux and Windows are well suited for the cloud, and are widely covered. macOS though not so much. Why? Well, there are many reasons, but one of them might be that short, but annoying paragraph in the software license agreement (this one is for Catalina, but you can easily check the others here):
J. Other Use Restrictions. The grants set forth in this License do not permit you to, and you agree not to, install, use or run the Apple Software on any non-Apple-branded computer, or to enable others to do so.You agree not to remove, obscure, or alter any proprietary notices (including trademark and copyright notices) that may be affixed to or contained within the Apple Software. Except as otherwise permitted by the terms of this License or otherwise licensed by Apple: (i) only one user may use the Apple Software at a time, and (ii) you may not make the Apple Software available over a network where it could be run or used by multiple computers at the same time. You may not rent, lease, lend, sell, redistribute or sublicense the Apple Software.
Yup. You have to run Apple software on the Apple hardware. This alone is a huge showstopper for the cloud. And only user may use it at a time too.
There are still some cloud providers who offer specifically macOS based products and services (and yes, they run them on the Apple hardware). Here are a few examples, thanks to this thread:
It’s good to have options here, even if the prices are much higher than what you’d expect.