“Async PHP Requests & Reactive Responses with PHP-FPM” is talk by Holger Woltersdorf, in which he shares the approaches he tried for implementing asynchronous requests in PHP, and how he arrived at hollodotme/fast-cgi-client, which is a PHP fast CGI client for sending requests (a)synchronously to PHP-FPM.
Month: June 2017
List of cognitive biases
List of cognitive biases is probably the single most useful resource on practical psychology that I’ve seen in my life.
Cognitive biases are tendencies to think in certain ways that can lead to systematic deviations from a standard of rationality or good judgment, and are often studied in psychology and behavioral economics.
Although the reality of these biases is confirmed by replicable research, there are often controversies about how to classify these biases or how to explain them. Some are effects of information-processing rules (i.e., mental shortcuts), called heuristics, that the brain uses to produce decisions or judgments. Such effects are called cognitive biases. Biases have a variety of forms and appear as cognitive (“cold”) bias, such as mental noise, or motivational (“hot”) bias, such as when beliefs are distorted by wishful thinking. Both effects can be present at the same time.
This will take me a very long while to process …
Rate Limiting with NGINX and NGINX Plus
Nginx blog (which, if you work with Nginx in any capacity, you should subscribe to) has an excellent guide to rate limiting. The article explains rate limiting from the basics, through bursts, all the way to more advanced examples, with multiple rate limits for the same location.
LINGsCARS.com – website of the day
LINGsCARS.com deserves some kind of title and reward. I’m giving it a website of the day award, as I’m still stunned for words.
On one hand, it serves as a painful reminder of how the web used to be back in the 90’s. It got everything from psychedelic background and auto-played music to animated GIFs and mouse hover effects.
On the other hand, it does stand out from all pastel colored material designed websites of today. Obviously, a lot of work went into building this thing and … somehow … strangely … it works.
Now, please excuse me while I wipe my bloody tears…
P.S.: Yeah it also took me a while to actually prepare that screenshot. Full-page image was too large. Cropping it down significantly brought it down to just under 5 MBytes, after which TinyPNG compressed it to just 1.4 MBytes.
Git Commit Good Practice
Open Stack wiki has an excellent guide on how to create good commits. In a few places it is too specific to Open Stack development practices, but overall it’s one of the best guides I’ve seen for any project using git.
It is basically split into two sections. One on how to decide which code goes into the git commit, and the other is what to include in the git commit message to make it useful.
The first part is simpler:
The cardinal rule for creating good commits is to ensure there is only one “logical change” per commit. There are many reasons why this is an important rule:
- The smaller the amount of code being changed, the quicker & easier it is to review & identify potential flaws.
- If a change is found to be flawed later, it may be necessary to revert the broken commit. This is much easier to do if there are not other unrelated code changes entangled with the original commit.
- When troubleshooting problems using Git’s bisect capability, small well defined changes will aid in isolating exactly where the code problem was introduced.
- When browsing history using Git annotate/blame, small well defined changes also aid in isolating exactly where & why a piece of code came from.
With these things to avoid:
- Mixing whitespace changes with functional code changes.
- Mixing two unrelated functional changes.
- Sending large new features in a single giant commit.
The second part is slightly more detailed. Here’s the information that should be included in the commit message, generally speaking (abbreviated quote):
As important as the content of the change, is the content of the commit message describing it. When writing a commit message there are some important things to remember
- Do not assume the reviewer understands what the original problem was.
- Do not assume the reviewer has access to external web services/site.
- Do not assume the code is self-evident/self-documenting.
- Describe why a change is being made.
- Read the commit message to see if it hints at improved code structure.
- Ensure sufficient information to decide whether to review.
- The first commit line is the most important.
- Describe any limitations of the current code.
- Do not include patch set-specific comments.
In other words, if you rebase your change please don’t add “Patch set 2: rebased” to your commit message. That isn’t going to be relevant once your change has merged. Please do make a note of that in Gerrit as a comment on your change, however. It helps reviewers know what changed between patch sets. This also applies to comments such as “Added unit tests”, “Fixed localization problems”, or any other such patch set to patch set changes that don’t affect the overall intent of your commit.
Read the whole thing for more details, examples of good and bad practices, and more specific instructions on the spacing, line length, and more.
And if you need more convincing or a different explanation, then Google “git commit best practices” or simply check out some of these resources: