php[architect] magazine has posted an announcement about the release of their December 2018 issue - Better Practice - Improve Your Skills.

Practice and more practice are the keys to adopting modern software engineering practices. It doesn’t matter if you’re using WordPress or Drupal to manage website content, trying to learn unit testing, get hired, or looking for better ways to manage date and time data—there’s always an opportunity to learn how to do it better. This issue rounds up articles on each of these topics to help you deepen your problem-solving skills.

Articles in this issue include:

• "Custom Post Types in WordPress" by Andrea Roenning
• "The Flexibility of Drupal 8" by Michael Miles
• "How to Learn PHP Unit Testing With Katas" by David Hayes
• "It’s About Time" by Colin DeCarlo

All of the usual columns have returned as well with thoughts about creating a culture in your development organization, hashing, interview coding challenges and more. Check out the full list of articles and columns for this month's edition on the php[architect] site and pick up a copy of your own! If you want to "try before you buy" you can read this month's free article and get a feel for the content.

In response to a few other posts about the use of "final" in PHP development, Freek Lijten has posted some of his own thoughts and some of the things he came to realize about its use in his own development.

I read a blog by Brandon Savage a couple of weeks ago and it triggered some thoughts. He refers to a blog by Marco Pivetta which basically states "Final all the things!". Brandon comes back with a more mild opinion where he offers the notion that this approach might be overkill. Since both posts got me thinking I tried to organise my thoughts on this in the following post.

Freek talks about a pretty common trend in the PHP world: the very rare use of "final". He suggests that "extension" of classes is a bad idea (or at least should be used a lot less) and how he has seen it commonly misused. He then shares two reasons why he thinks "final" is a good idea, mostly centering around how easy it is and how the Open/Closed principle applies. In the end, he notes that he'll be trying to use more "final" in the future and see where it takes him and his code.

On Kinsta.com Daniel Pataki has posted a list of seven things not to do in PHP 7 when it's finally released. It's no secret that there's a lot of new functionality coming with this new version but that also potentially means some bad practices coming along with them.

I’ve already shared some of the upcoming features of PHP 7, in this article I thought I’d take a look at some of the bad patterns we should stop using as we switch to the lightning fast PHP 7.

Among the things on his list are suggestions like:

• Do Not Use mysql_ Functions (removed from core)
• Do Not Use PHP Close Tags At The End Of A file
• Do Not Perform Queries In A Loop
• Do Not Trust User Input

Some of the suggestions do have a direct relation to what PHP 7 has to offer but most of them are just good practices to follow during your development work. Quite a few good tips in there, especially if you're relatively new to the language and want to start with PHP 7 and go.

Alejandro Celaya has shared some advanced concepts when using Composer that you may or may not know this popular tool could do.

Composer is The Tool in any modern PHP project. Nowadays I can't imagine to work without it. It is much more powerful than some people think, easily solving the integration of third party components in our projects, but there are some advanced features that are less known. I'm going to try to explain some of the best practices and mechanisms bundled with composer.

His list of more advanced techniques and concepts includes:

• Globally installing composer
• Create the composer.json file (with composer init)
• Production environments (and flags to customize the installation)
• Executing CLI scripts

There's several more items in his list and each includes a description of the feature/practice and commands or code where appropriate.

While not specifically relating to PHP, Erika Heidi's latest post talks about a technique that could help you be more productive in the coding work you do - focusing in on your "time problems" and possibly using the Pomodoro technique to help correct them.

This is a quite famous quotation that is being repeated through the years. "Time is money" is a very contrived way to say that if you lose time, you might be losing money. I personally don’t like this quote; lets refactor it to something that better reflects reality: “Productivity is Money” sounds way more realistic. [...] What we really need is to figure out a way to better use the time we have. How do we maximize our productivity?

She breaks it up into four things that can help identify these "time problems":

• Diagnosing your time problems
• Managing your Focus
• Self-sabotage by the scumbag brain
• The Pomodoro Technique

In this last section she introduces the technique (and tool - the tomato timer) and how it works. She points out the places where the process is flexible and how, especially if you're deep in code, getting to the point of taking a timed break (and sticking with it) can help give perspective.

Anna Filina has a new post to her site today suggesting that developers are like athletes, they need to practice before they can be good at what they do.

Think of a developer as an athlete. He or she is aiming for a medal in a competition. A figure skater can't just perform a triple axel in the Olympics after seeing it done on television. This requires a lot of practice, so that when the time comes, the performance is flawless. Of course, programming doesn't have to be flawless. One must remain pragmatic, yet it still requires practice before a concept can be safely implemented without breaking the project or missing deadlines. Who will pay for that practice?

She relates the development manager to the coach of a sports team, being the one that guides the developers into being all they can be and trying out new ideas in the process. She also recommends making use of idle time between projects to prototype, do R&D and learn in general.

Developers need a sandbox. If you don't give it to them, you can end up with one of the following issues. Your entire project could become a sandbox, making it unstable. [...] If you want your developers to get better, allow time for practice, not just learning. It's necessary, easy to do when planned and provides countless benefits to your company. Let me know how that advice worked out for you.

PHPMaster.com has a new article about a practice that's becoming more popular in recent years to help increase the quality of code that comes out of development - code reviews.

Every developer knows the pain of banal mistakes. A wrong attribute here, a misspelled property there, an accidentally duplicated line of code which you missed because of the coffee-fueled 16 hour hackathon you’ve been on. [...] Code review is simply the act of having someone else look at your code to find the mistakes you missed.

The tutorial talks about the types of code reviews (three of them with varying levels of involvement) as well as some best practices to follow in your reviews like:

• Know your common mistakes and actively fight them.
• Peer code review means being reviewed by someone of equal or greater skill.
• Collect metrics.
• Be mindful of the social aspect – finding bugs is good, not bad!

In this new post to the Developer Drive site today, they share six things that you, as a developer, can do to hold you back in your career (or development growth in general).

The web development industry is one that is always growing because of how we use the web. No longer do we expect the Internet to simply host a digital pamphlet for a business. The expectations nowadays are for a site to be rich with content, provide the means for visitors to interact and be dynamic in every interaction. With the demand at an all time high, freelance web developers may think that there is little they could do to harm their career. Unfortunately, there are many ways that people in this industry sabotage themselves when it comes to their career.

Among the things they recommend avoiding are practices like clinging to older technologies, failing to network with other developers and market themselves and forgetting why you were hired in the first place.

In this new post Ralph Schindler takes a look at the Prototype design pattern and uses it to illustrate some best practices in using constructors in PHP.

If your knowledge of constructors ends with "the place where I put my object initialization code," read on. While this is mostly what a constructor is, the way a developer crafts their class constructor greatly impacts the initial API of a particular class/object; which ultimately affects usability and extensibility. After all, the constructor is the first impression a particular class can make.

He starts at ground level, reintroducing what a constructor is and what it should (and shouldn't) be used for. He talks about constructor overloading, constructor injection, dynamic class extension and using the Prototype pattern to create "an unlimited number of objects of a particular type, with dependencies in tact, each with slight variations." He gives an example with a "DbAdapter" class, showing dynamic class instantiation and how to, using the Prototype method, inject a DbAdapter object and have your class use that instead.

On PHPMaster.com today there's a new tutorial that shares a few regular expression tips about doing some search and replace in your content.

So how can you practice using regex if you are limited to just using them in your code? The answer is to use a utility, of which there are many, that uses regex for performing search and replace. I’m sure everyone is familiar with the standard “find x and replace it with y” type of search and replace. Most IDEs and text editors have built in regex engines to handle search and replace. In this article I’d like to walk through a series of exercises to help you practice using regex.

His examples are based on Netbeans but can be used in just about any IDE that supports regex (or even just your code). He shows how to match word boundaries, do some grouping, work with back references and doing some search/replace based on multiple groupings.