Jeff Geerling shares the best way to get the full PHP version string. I’d think that “php –version” externally or “echo PHP_VERSION” internally would do the job. However, that’s not exactly right, as there are a number of inconsistencies on different platforms. The best option seems to be the combination of the PHP_MAJOR_VERSION, PHP_MINOR_VERSION, and PHP_RELEASE_VERSION constants.
$ php -r 'echo join(".",[PHP_MAJOR_VERSION,PHP_MINOR_VERSION,PHP_RELEASE_VERSION]);'
7.2.12
The evolution goes on. Now that we’ve kind of sorted out most of our infrastructure, development tools, flows and processes, I guess, it’s time to look deeper into the things we’ve had for a while and reiterate over them.
Recently, I’m seeing a lot of blog posts on articles on how to write good commit messages. Sure, we’ve had these for a while. But lately things get a little bit more serious.
Here’s one (in Russian) that I’ve read recently. Here’s another one (in English) that shares some of the concepts and suggestions.
What are they saying? Well, “write better commit messages”, obviously. But there are a couple of specific bits which I found interesting. They are:
For the skeptics among you, I slightly share your feeling. It does seem like a bit too much overhead. But as someone who works with an ever-growing team on a large number of projects, I think there is a place for it. It’ll take a while to integrate, update the process, and enforce the discipline, but I think it’s well worth it. At the very least, it deserves a try.
There’s a lot of confusion between git merge and git rebase even among seasoned users of git. “An Introduction to Git Merge and Git Rebase: What They Do and When to Use Them” is a great article explaining the pros and cons of each, and when and why using each of this is better.
While I understand it a lot better now, I still much prefer the merge approach. It’s simpler and less dangerous, and maintains the full history. This might get noisy at times, but works as a last resort when trying to understand what was going through the developer’s head when he was working on a piece of code.
Now that PHP 7+ sorted out a whole bunch of problems with type-hinting of parameters, return values, variables and properties, we turn our attention to somewhat deeper issues.
Array is a native citizen in PHP. Arrays are very convenient and are widely used. However, if you stop and think about the times where you had to figure out somebody else’s code, I’m pretty sure complex arrays will come to mind at some point.
I’ve recently came across two completely independent blog posts which talk exactly about this particular area of problems:
Both are explaining the issues very well and make valid points. As far as solutions and better ways go, apart from the approaches mentioned in these blog posts, I also remembered a recent blog post from which I linked to the data transfer object library, that solves exactly that.
I’ve been working with REST/RESTful APIs for a while now. They are usually a lot better than the SOAP or XML-RPC stuff we had before. But they are also not perfect. Error handling and reporting is a common area between many implementations that needs more attention and consistency. Turns out, there is, I’ve just somehow never heard of it – RFC7807 defines “Problem Details for HTTP APIs”.
I’ll need to look more into this and see if and how it is better than a variety of things I’m using now. Gladly, there is even a PHP library to help with that – Crell/ApiProblem:
This library provides a simple and straightforward implementation of the IETF Problem Details for HTTP APIs, RFC 7807.
RFC 7807 is a simple specification for formatting error responses from RESTful APIs on the web. This library provides a simple and convenient way to interact with that specification. It supports generating and parsing RFC 7807 messages, in both JSON and XML variants.