Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

10 Modern Software Over-Engineering Mistakes
Oct 19, 2016 @ 12:45:19

In this recent post to his Medium.com site Subhas Dandapani shares what he sees as the top ten modern software over-engineering mistakes developers make in modern application development.

Few things are guaranteed to increase all the time: Distance between stars, Entropy in the visible universe, and Fucking business requirements. Many articles say Don't over-engineer but don’t say why or how. Here are 10 clear examples.

Important Note: Some points below like “Don’t abuse generics” are being misunderstood as “Don’t use generics at all”, “Don’t create unnecessary wrappers” as “Don’t create wrappers at all”, etc. I’m only discussing over-engineering and not advocating cowboy coding.

Points in his "top ten problems" list include:

  • Engineering is more clever than Business
  • Everything is Generic
  • Shallow Wrappers
  • Overzealous Adopter Syndrome
  • In House “Inventions”

Each item in the list comes with a bit of explanation and an image or two where appropriate. There's definitely some things in here that are a bit debatable, but development has and will always have a file line between over-engineering and "just the right amount" of work. The trick is figuring out where that line is for your development work.

tagged: top10 list modern software overengineering engineering mistake opinion

Link: https://medium.com/@rdsubhas/10-modern-software-engineering-mistakes-bc67fbef4fc8#.byuwr484j

Symfony Finland:
What's in store for PHP performance?
Oct 18, 2016 @ 10:20:51

On the Symfony Finland blog there's a new post looking ahead at what they see in store for PHP's performance in a post-PHP 7.0.x world.

PHP 7.0 made significant improvements in terms of performance and memory use for real applications. Many applications deliver twice the throughput with much less memory just without any changes to the application code.

But with networked API driven architectures individual response times are increasingly critical for end-user experience. Luckily, there are quite a few unbeaten paths for regarding PHP performance.

These other "unbeaten paths" they mention include a trend towards using asynchronous patterns and the use of application servers (long running PHP processes). There's also mentions of JIT (just in time) compilation, defined request and response objects and the improvement of other possible PHP runtimes.

tagged: language future performance improvement opinion

Link: https://www.symfony.fi/entry/whats-in-store-for-php-performance

Exakat Blog:
6 good practices for "use" in PHP
Oct 14, 2016 @ 10:49:51

On the Exakat blog there's a new post sharing six good practices for "use" in PHP. The "use" keyword has a few different places it is used in PHP (like importing namespaced classes and passing in values to closures).

While reviewing code recently, I realized there are no guidelines for use. Every modern code do use ‘use’ (sic), as importing classes from composer or a framework is the norm. There are now quite a few variations in syntax for importing classes or traits. Although the impact on performance is low, as use is solved out, having a clean approach to ‘use’ is important to keep the code clean and readable. Let’s review what are the six good usage of use.

Each of the six tips they share come with a bit of explanation and code to back them up:

  • Do not import unused classes
  • Alway use alias
  • Place all use at first
  • Avoid using the same alias for different classes
  • Group use expression for easy reading
  • Limit the number of use expression

Some of them could be argued as to whether or not they're a "best practice" but it'd definitely interesting to see some tips for the use of this increasingly common little keyword.

tagged: bestpractice use statement keyword top6 import alias opinion

Link: https://www.exakat.io/6-good-practices-for-use/

How is everyone doing development locally today?
Sep 23, 2016 @ 12:08:17

On the /r/php subreddit from Reddit.com there's a post from Spvrtan asking the community what technologies they're using for local development in their day to day development work.

It's honestly been over 5 years since I last touched PHP on the back-end. At that time, other than "doing it live", XAMPP was the top dog for local environments. Is there a new player in the space or should I go with the same? I've been working primarily as a front-end engineer for the past few years during my full-time employment roles and touched the back-end on projects I've worked on but they've all been Java-based.

They also ask what other developers are using for their deployment tools and pipelines. Answers to the post so far include some of the usual tools and methods including:

  • Docker
  • puphpet (for use with Vagrant)
  • Homestead from Laravel

Other comments also mention the manual creation of virtual machines and even support for local installations rather than virtual ones. What's your development environment like? Head over to the topic and share your own setup too.

tagged: reddit rphp local development virtualmachine opinion deployment

Link: https://www.reddit.com/r/PHP/comments/54487o/how_is_everyone_doing_development_locally_today

How Much Coding Should Designers Know?
Sep 23, 2016 @ 09:41:35

The Toptal.com site has an interesting post mostly relevant to those out there that straddle the line between design and development. It wonders how much coding should a designer know to get the job done.

Many designers think each discipline should mind their own business, while others see no problem in professionals wearing multiple hats. Many developers see designers who code as a threat, while others see it as a facilitator. This is a hotly debated subject, and although I think some great designers are also superb at coding, I will always defend that the more you focus on a particular area the best you will be at it. But this shouldn’t be a reason for you to miss out on the benefits of having another skill under your belt.

The article then breaks down the benefits of designers learning to code by levels of knowledge:

  • Step 1: Know the basics of HTML and CSS
  • Step 2: Front-end JavaScript and AJAX could make you a unique asset
  • Step 3: Back-end JavaScript might be overkill
  • Step 4: Database Architecture and Software Engineering Won’t Get Designers Anywhere

For each point there's a brief explanation of the level of knowledge it represents and what he sees as a general designers attitude towards it.

tagged: designer coding opinion development

Link: https://www.toptal.com/designers/digital/designers-coding

SitePoint PHP Blog:
PHP-FIG Alternatives: The Pros and Cons of Various Visions
Sep 22, 2016 @ 11:10:49

On the SitePoint PHP blog paul Jones has written up some of his own perspective on the PHP-FIG and the work that's currently being done by the group on restructuring to make the group more effective, learning from past issues.

In his article The Past, Present and Future of the PHP-FIG, Larry Garfield gives a whirlwind tour of his impressions of the FIG, from its founding to one of its possible futures. I encourage you to read it in its entirety before continuing.

Herein, I will attempt to address some of the errors and omissions in Larry’s article, and offer two other possible futures for the FIG.

He starts by talking about the largest change the group is working on - the PHP-FIG 3.0 proposal. He compares the vision of this effort to some of the founding goals and principles of the group as documented in various emails and posts from current (and past) members of the group. Paul also talks about the FIG 2.0 workflow, what PSRs were before/after it was introduced and some of the overall impact that these and other PSRs from the group have had on the wider community.

He wraps up the post with a look at two alternatives he's proposing for the group's consideration as a way forward and an alternative to the PHP-FIG v3: independent interop groups and disbanding the PHP-FIG all together.

tagged: phpfig alternative vision opinion history group psr community

Link: https://www.sitepoint.com/php-fig-alternatives-the-pros-and-cons-of-various-visions/

Raphael Stolt:
Anatomy of a dope PHP package repository
Sep 22, 2016 @ 09:30:25

In this recent post to his site Raphael Stolt shares an example of what he thinks is a "dope" setup for a Composer package (a well-structured, consistent and fully populated package structure).

While contributing to Construct, maintained by Jonathan Torres, I gathered some insights and learnings on the characteristics of a dope PHP package repository. This post summarises and illustrates these, so that PHP package developers have a complementary guideline to improve existing or imminent package repositories. Jonathan Reinink did a good job in putting the PHP package checklist out there which provides an incomplete, but solid quality checklist for open-source PHP packages.

I'll distill the characteristics of a dope PHP package repository by looking at the repository artifacts Construct can generate for you when starting the development of a new PHP project or micro-package.

Included in his list of things every PHP package should include are things like:

  • the source (naturally), matching tests/specs and documentation
  • consistent naming
  • versioning information (via a CHANGELOG)
  • Travis-CI integration
  • A . gitattributes file for excluding certain files from export

He also makes a few more general suggestions like avoiding the posting of "badges" in the README and some reasons why you should care about the "dopeness" of your repository at all.

tagged: package wellstructured requirements opinion repository

Link: http://raphaelstolt.blogspot.com/2016/09/anatomy-of-dope-php-package-repository.html

Anna Filina:
Re: When it comes to submitting talks, how many is too many?
Sep 14, 2016 @ 11:12:35

For those out there that are speakers (or are wanting to try their hand at speaking) at a technology conference, Anna Filina has shared her own thoughts about how many talks to submit to a single conference...and what might be too many.

I read this interesting post by Cal Evans about submitting conference proposals. He makes some very valid points, but I’d like to add my own experience as an organizer, so that when you submit, you have multiple perspectives.

She responds to Cal's comments about filtering talks based on topics the conference has mentioned, submitting a max of four talks and submitting the best idea first. Anna also shares some of her own recommendations as an organizer from the Confoo conference(s).

I know how hard it is to go through so many talks. At ConFoo, we receive close to 1000 proposals. [...] I don’t mean to tell other conferences what to do. However, speakers should always bear in mind that conferences operate differently. Perhaps organizers can create a comprehensive guideline specific to their event.
tagged: submit talk session conference toomany opinion organizer confoo

Link: http://afilina.com/re-how-many-is-too-many/

Jani Hartikainen:
How many tests is too many?
Sep 13, 2016 @ 09:21:21

While not specific to PHP Jani Hartikainen asks an interesting question in his latest post - how many tests are too many?. He gives an example of the number of tests in a widely used open source project and how, sometimes, more tests doesn't mean better code.

Some time ago I stumbled upon some crazy stuff… Specifically, I found out that SQLite has 787 times more tests than they have actual code! It’s no joke, it’s documented right on their website. While they have about 116 300 lines of source code, they have 91 577 300 lines of test code.

That sounds completely insane. [...] I bet you’ve sometimes wondered what is the right amount of tests to write. In some cases, it’s easy to end up with more tests than code. [...] When thinking of how many tests is enough, we need to think of what the goals are – both for the tests and our actual project.

He focuses in on this last idea, talking more about the SQLite project and its test suite. He then helps answer the main question - how do you know how many tests are enough? Should you "bend over backwards" to make tests for every possible scenario just because you can? He suggests a few things that can help the situation including refactoring where testing is difficult and writing regression tests for bugs fixed.

tagged: testing code opinion toomany unittest sqlite project

Link: http://codeutopia.net/blog/2016/09/10/how-many-tests-is-too-many/

PHP Roundtable:
053: Why I'm Afraid To Admit I Use PHP
Sep 07, 2016 @ 09:56:36

The PHP Roundtable podcast (videocast) has posted their latest episode: Episode #53: Why I'm Afraid to Admin to Using PHP. In this show host Sammy Powers is joined by Evert Pot and Davey Shafik.

So you spend most of your time programming in PHP. You meet another programmer out in the wild. You begin explaining what you do. Do you find yourself using vague terms and actively trying to avoid the word "PHP?" Do you dread the question, "What language do you primarily code in?" Do you anticipate them scoffing at you when you say, "PHP?"

We discuss why PHP has such a bad rep in the eyes of many and why some of us feel the need to start conversations with, "I use PHP but let me explain..."

You can catch this latest episode either using the in-page video or audio player or directly on YouTube. Be sure to check out the extensive show notes for this one too - plenty of good information there. If you enjoy the show, be sure to subscribe to their feed and follow them on Twitter to get the latest updates when new shows are released.

tagged: phproundtable podcast video ep53 afraid opinion usage language evertpot daveyshafik

Link: https://www.phproundtable.com/episode/why-im-afraid-to-admit-im-a-php-programmer