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

Reddit.com:
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

Toptal.com:
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

Jon LeMaitre:
A Response To PHP- The Wrong Way
Aug 22, 2016 @ 12:21:36

Jon LeMaitre has a new post to his Medium blog sharing his own response to the "PHP The Wrong Way" (phpthewrongway.com) and some of the points it makes.

For anyone who isn’t aware, there is a site call http://phptherightway.com, which is a summary of good (dare I say, best?) practices for writing PHP in 2016. In addition, there now exists http://phpthewrongway.com, whose aim is to provide a kind of counterbalance to http://phptherightway.com and what is presently mainstream PHP culture. This article is a rebuttal to the arguments found in http://phpthewrongway.com.

He starts by pointing out the three main positive points "The Wrong Way" makes:

  • keeping things simple
  • don't apply tools dogmatically
  • write secure software by default

However, as he points out, most of this advice is wrapped in "gross mischaracterizations of the PHP community, the nature of frameworks, standards, and PHP itself." Jon's post gets into a lot more detail on the various sections of "The Wrong Way", breaking them down into a series of quotes and matching responses. There's definitely some good points made here in Jon's post - I'd highly suggest balancing out the thoughts from "The Wrong Way" with it.

tagged: phpthewrongway response opinion phptherightway

Link: https://medium.com/@jon.lemaitre/a-response-to-php-the-wrong-way-fe7bb253e295#.5w6810pwg

Jason McCreary:
Practicing YAGNI
Aug 10, 2016 @ 10:18:33

Jason McCreary has written up a post covering a popular topic from the eXtreme programming world, a talk he presented on the subject and a bit of his own personal experiences with it: YAGNI or "You Aren’t Gonna Need It".

Last week I spoke at Laracon US 2016 about Practicing YAGNI. First, let me say it was an honor to present for such a large audience at such a premiere conference. I received a lot of feedback and interest in my talk. To that point, many people have asked me to share my slides. As the slides were mostly placeholders for discussion, I felt a blog post would better summarize the talk.

[...] YAGNI is a principle of eXtreme Programming - something I practice daily at work. YAGNI is an acronym for You Aren’t Gonna Need It. It states a programmer should not add functionality until deemed necessary. In theory, this seems straightforward, but few programmers practice it.

He talks about practicing YAGNI and why it's hard for the average developer. He starts with the overall problem it solves and the more relatable KISS (Keep it simple, stupid) and MVP (minimum viable product) realms of thought. He then gets into some of the ways that you can practice YAGNI in your own development, mostly dealing with the timing of feature development rather than complexity. He also includes some times when it doesn't make sense to practice YAGNI and, finally, what practicing it means to him personally.

tagged: yagni yaaintgonnaneedit development principle extreme programming opinion

Link: http://jason.pureconcepts.net/2016/08/practicing-yagni/

O'Reilly Software Engineering Blog:
The traits of a proficient programmer
Aug 09, 2016 @ 10:52:26

On the O'Reilly Software Engineering blog there's a post from Gregory Brown sharing what he thinks is the definition of a "proficient programmer" and how it differs from competence.

Do you know what the difference between competence and proficiency is? That sounds like a trick question, because the words seem to mean the same thing. But the subtle distinction between them is critically important.

Competence means having enough experience and knowledge to get stuff done; proficiency involves knowing why you are doing something in a certain way, and how it fits into the big picture. In other words, a proficient practitioner is always a competent practitioner, but the opposite may not be true.

He goes on to talk about the Dreyfus Model of Skill Acquisition and how it relates to the biggest bottleneck he sees for developers: "crossing the divide from competence to proficiency." He defines what it means to be a "competent" programmer first and then one of the things junior developers struggle with - thinking knowledge is enough to make you more competent. He gives a more concrete example of this with the use of the Memento pattern, when to use and - for the competent side - when it breaks down.

He ends the post with some suggestions that can help you if you're wanting to make the jump from "proficient" to "competent" (even if you've been programming for a long time, some good tips here).

tagged: traits proficient programmer opinion oreilly

Link: https://www.oreilly.com/ideas/the-traits-of-a-proficient-programmer