Tag: PHP

17 Tips for Using Composer Efficiently

Martin Hujer has collected 17 tips for using composer efficiently, and then added a few more after receiving the feedback on the blog post.  I was familiar with most of these, but there are still a few that are new to me.

Tip #7: Run Travis CI builds with different versions of dependencies

I knew about the Travis CI matrix configuration, but used it only for other things.  I’ll be looking into extending it for the composer tests shortly.

Tip #8: Sort packages in require and require-dev by name

This is a great tip!  I read the composer documentation several times, but somehow I missed this option.  It is especially useful for the the way we manage projects at work (waterfall merges from templates and basic projects into more complex ones).

Tip #9: Do not attempt to merge composer.lock when rebasing or merging

Here, I’m not quite sure about the whole bit on git attributes.  Having git try to merge and generate a conflict creates a very visible problem.  Avoiding the merge might hide things a bit until they popup much later in the CI.  I guess I’ll have to play around with this to make up my mind.

Tip #13: Validate the composer.json during the CI build

This is a great tip!  I had plenty of issues with composer validations in the past.  Currently, we have a couple of unit tests that make sure that composer files are valid and up-to-date.  Using a native mechanism for that is a much better option.

Tip #15: Specify the production PHP version in composer.json

This sounds like an amazing feature which I once again missed.  Especially now that we are still migrating some projects from PHP 5.6 to PHP 7.1, and have to sort out dependency conflicts between the two versions.

Tip #20: Use authoritative class map in production

We are already almost doing it, but it’s a good opportunity to verify that we utilize the functionality correctly.

 

Defensive Programming : Object Calisthenics

I came across this nice and somewhat strongly opinionated video on Defensive Programming:

Marco Pivetta makes quite a few good points with I agree (and a few with which I disagree).  One thing that he mentioned though I haven’t heard about – Object Calisthenics.  Which turns out to be yet another set of rules and best practices for the object-oriented design and programming.  Here are the rules to get you started:

  1. Only One Level Of Indentation Per Method
  2. Don’t Use The ELSE Keyword
  3. Wrap All Primitives And Strings
  4. First Class Collections
  5. One Dot Per Line
  6. Don’t Abbreviate
  7. Keep All Entities Small
  8. No Classes With More Than Two Instance Variables
  9. No Getters/Setters/Properties

Read the whole article for explanations and examples.

The 2018 Guide to Building Secure PHP Software

“The 2018 Guide to Building Secure PHP Software” is an excellent guide to writing modern PHP applications with security in mind.  It covers a bunch of the usual topics, but provides fresher solutions than most other similar guides.

rector – reconstruct legacy PHP codebase to modern standards

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

“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.