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

Intracto Blog:
How to save a kitten by writing clean code
Jun 03, 2016 @ 12:52:50

On the Intracto blog there's a new post from Joeri Timmermans talking about writing clean code with some good suggestions you can easily incorporate into your current processes.

So you came here to save a kitten? That's wonderful, but the real reason we're both here is to talk about clean code. In this blog post I'll be sharing some of my personal experiences and tips. But before we dive into the tips and tricks part, let's talk about what we, as developers, do and why we do it.

He touches on several topics including:

  • Best vs Fastest
  • Reading vs Writing
  • File and Folder Organization
  • Naming [conventions and clarity]

He also makes the recommendation to "return often", keep things DRY and makes a few recommendations of PHP-specific tools that can help.

tagged: clean code recommendation process development opinion

Link: http://blog.intracto.com/how-to-save-a-kitten-by-writing-clean-code

Phil Sturgeon:
Why Care About PHP Middleware?
Jun 02, 2016 @ 10:35:39

Phil Sturgeon has a post over on his site sharing some of his thoughts on PHP middleware and why he thinks it's worth paying attention to in your applications.

Recently there has been a lot of buzz about HTTP middleware in PHP. Since PSR-7 was accepted, everyone and their friend Sherly has been knocking out middleware implementations, some of them stunning, some of them half-arsed, and some of them rolled into existing frameworks. HTTP Middleware is a wonderful thing, but the PHP-FIG is working on a specific standard for middleware, which will standardise this mess of implementations, but some folks don't seem to think that would be useful.

Let's look into middleware a little closer, to show you why it's something to smile about.

He starts with a bit of background about the history of middleware in the PHP ecosystem and where they fit in the overall execution path. He lists out some of the middlewares that have already come out based on this surge in the community including CSRF protection, debugging and rate limiting handling. With various frameworks handling the request/response slightly differently, the PHP-FIG worked up a standard to make interoperability easier. He links to some other resources about middleware that have been posted and discussions he's had with other people about their usefulness.

HTTP Middleware is awesome. It lets frameworks do far less, it lets people distribute logic in a way often unseen popularly in PHP, it lets more of your application be reusable, and it lets PHP catch up with other popular languages used to build stuff on the web. PSR-7 was a great step towards this goal, but we need another PSR to get the whole way there.
tagged: middleware opinion psr7 request response phpfig example

Link: https://philsturgeon.uk/2016/05/31/why-care-about-php-middleware/

Anthony Ferrara:
All About Middleware
May 23, 2016 @ 11:06:10

Anthony Ferrara has written up a post for his site sharing more information about middleware and the PSR-7 proposal that's being discussed to help standardize interfaces with this popular form of application processing.

Last week, a proposal to standardize middleware for PSR-7 was introduced to the PHP-FIG. The general concept of middleware is not a new one, and has been in use in the PHP world for many years. Several people have raised significant concerns with the proposal, which have gone completely unheeded by the author. Let me go through the most major of these concerns, as well as show what a better proposal might look like.

He starts off with a brief look at the current proposal - the interface it defines and an example of a real world usage of it to check some attributes on the request/response. He gives a few more examples before getting into what he sees as the fundamental problem with the interface: that it passes in a response instance rather than creating its own ("what does $response mean inside the middleware?"). He's mostly talking about context and not knowing from one middleware to the next what kind of changes may have been made to the response. He also includes some of the arguments on the "for" side of including the parameter and an interesting list of middleware that does this modification prior to the next() call, making it difficult to determine the actual state.

He ends the post with a few other issue he has with the proposal including the use of the __invoke method name, a restriction on typing and the next method being callable. He makes a few suggestions of modifications to the proposal that he thinks could help make it better, correcting these issues.

tagged: middleware psr7 proposal opinion example problem

Link: http://blog.ircmaxell.com/2016/05/all-about-middleware.html

Ben Ramsey:
7 Tips for php[tek]
May 23, 2016 @ 09:42:29

Ben Ramsey has a post to his site sharing a few tips for those attending the php[tek] conference this year (though most of them could apply to just about any technology-related conference out there.

This week, I’m attending php[tek]. This is my seventh php[tek], and the first I’ve attended not as a speaker. It’s one of my favorite conferences, and I didn’t want to miss its first year in a new city: St. Louis. As we gear up for the eleventh php[tek] conference, I thought I’d list my seven tips for getting the most out of your php[tek] experience.

His suggestions cover things to help you get the most enjoyment from the conference, and not just from the sessions:

  • Hang out in the evenings, after the conference sessions.
  • After the conference events, follow folks to the bar.
  • Take advantage of the “hallway track,” and don’t forget the regular sessions.
  • Attend the morning keynote sessions.
  • Join the conference IRC backchannel: #phptek on Freenode.
  • Use the official hashtag: #phptek
  • Take lots of pictures and upload them to Flickr.

Each of the suggestions comes with a bit of description and photos from previous years. If you're attending this year's conference, I'd definitely recommend talking a look over the full post and getting prepared for a great week of learning and community at this year's conference.

tagged: phptek tek16 conference opinion tips enjoyment community

Link: https://benramsey.com/blog/2016/05/phptek-tips/

Evert Pot:
Why PHP-FIG matters
May 18, 2016 @ 12:48:02

There's been quite a bit of drama lately around the PHP-FIG (Framework Interoperability Group) organization in the past few weeks, mostly resulting from an inflammatory situation involving one of the member projects. There's been questions around about the PHP-FIG, its role in the community and how that might change in the future. In this post to his site Evert Pot shares some of his own thoughts about the group and why it still matters.

The PHP-FIG is currently going through some growing pains. I recently resigned as a voting rep, and after some juvenile controversy Lavarel, Doctrine and Propel have as well.

Since its inception 8 years ago, the groups greatest problem has been to properly organize itself. [...] Now as a sort of knee-jerk reaction to these issues, PHP-CDS was setup with a much simpler process. [...] Some good stuff is happening though. A few people are working on a thankless effort to restructure the organization dubbed “FIG 3.0”. (thanks Larry Garfield and Michael Cullum).

He makes some of his own suggestions to the group as to things he think could be "quick wins" and help make the group better overall. He then gets to the "why it matters" section. He uses the PSR-6 caching standard as an example and points out that many other standards were based on successful interfaces on projects - not so much on the caching though. He also talks some about PSR-7 and how request/response handling can "look odd" at first glance. He suggests that while the PSR-7 standard probably evolved from too much discussion, but the PHP-FIG was there to facilitate that discussion. Now they just need to make it easier to get through the process...

tagged: phpfig interoperability important group standards opinion psr7 psr6

Link: https://evertpot.com/why-php-fig-matters/

QaFoo Blog:
When to Abstract?
May 18, 2016 @ 10:12:18

On the QaFoo blog they've posted an article that shares some of their thoughts on "when to abstract" in your code - essentially finding that point where abstracting out functionality makes sense.

One of the most difficult challenges in a developers life is finding the "right" abstraction, or at least the best one given the current circumstances. The core problem is that abstraction is a bet on the future development of the software and we know that future is volatile. The circumstances will change, so will the view on the best abstraction change.

But there is another dimension which influences this decision: What kind of software are you developing?

They start off by defining three different types of projects (internal, library and adaptable) and move into how this type changes when/how you abstract things in your code. They give a brief summary for each type and when it usually makes sense, including steps to take (concrete first, then abstract).

tagged: abstract code library internal adaptable type opinion concrete

Link: https://qafoo.com/blog/084_when_to_abstract.html

Pascal Martin:
INI directives are evil!
Apr 28, 2016 @ 12:58:40

In a new post to his site Pascal Martin shares some thoughts about why INI directives are evil, mostly in how they could be used to enable/disable major pieces of functionality in the PHP language.

A few times, while evolutions were discussed for PHP 7, someone suggested a new feature could be optional, depending on an INI configuration directive — the idea being each user could then enable it or not.

Still, the idea of directives that could change, sometimes deeply, the behavior of a programming language… It scares me!

He goes back in time a bit to talk about a feature like this that was once a part of the language (happily removed now): "magic quotes". He points out that, while the intent was to provide security to submitted data, the results were disastrous if it was moved to another server without the setting enabled. He also points out some of the steps that have to be taken when a new directive controlling a major feature is introduced - even worse if you're creating a product to run on other peoples' servers.

In any case, before suggesting "but they could allow us to enable or not this feature with a simple INI directive" for ideas as critical as a weak or strict typing mechanism, ask yourself: do you really want two languages with very distinct behaviors, and applications and libraries that work only on some combinations of configuration values?
tagged: ini directive feature language evil opinion

Link: https://blog.pascal-martin.fr/post/ini-directives-are-evil.html#fn:why-optionnal-feature

Mathias Verraes:
The Repair/Replace Heuristic for Legacy Software
Apr 28, 2016 @ 11:48:06

Mathias Verraes has shared some thoughts about legacy applications and how development should be handled as new features are added and bugs are fixed. He proposes a "heuristic" to keep in mind as you work in your legacy code: the Repair/Replace Heuristic.

Technical Debt is a great metaphor. It shares many analogous properties with financial debt: loans, accrued interest, token payments, bankruptcy… There is a key difference however. We take financial debt with another party. [...] Technical Debt has no measure like money, and no ruleset like Property law, and, more importantly, with Technical Debt there is no other party. The organisation is both the creditor and debtor. [...] In “Managed Technical Debt”, I propose a cheap, imprecise, but surprisingly effective method for mapping and measuring debt. In short, it involves posting stickies whenever progress is impeded by debt, and keep marking the stickies for every incident.

By following this method, you gather together a better overall picture that makes determining the worst debt in your application easier. He proposes using this to follow the Repair/Replace methods: repairing something if it's well architected or replacing it if it's not.

Even when you’re not trying to decide on Repair/Replace — perhaps the decision was already made by others — the process of mapping its history will teach you more about the system and and its design. And one deep insight you learn from temporal modelling.
tagged: legacy code replace repair heuristic software opinion

Link: http://verraes.net/2016/04/repair-replace-heuristic-for-legacy-software/

Cal Evans:
What do developers look for when they scan a job ad?
Apr 28, 2016 @ 09:20:15

Recently Cal Evans took an informal survey of fellow Twitter users and asked them what they thought was most important to see in a job ad for a developer position. In this new post he shares some of the results and responses to the question (with a surprising range of answers).

In my book “Culture of Respect” I have a section on writing job ads that will attract developers. I am in the process of revising that chapter, so I thought I would ask the people who actually read the job ads what they look for. The results weren’t that surprising to me. Having read a lot of job ads though, I am guessing that the results will be surprising to some managers out there.

He's embedded the tweets themselves in the post (straight from the horse's mouth, so to speak). Responses touch on subjects like:

  • salary requirements
  • clear definition of duties
  • less "buzz words"
  • well-defined list of technologies they'll be working with

The results are interesting and a definite must read for anyone coming up with job postings for open developer roles in your company.

tagged: developer job ad posting requirement opinion twitter poll

Link: https://blog.calevans.com/2016/04/20/what-do-developers-look-for-when-they-scan-a-job-ad/

Christian Mackeprang:
Project delays: why good software estimates are impossible
Apr 15, 2016 @ 12:06:47

Christian Mackeprang has a new post to his site with some of his thoughts on why software estimates are impossible in any realistic project development process.

When you, as a programmer, start a new project, you will often not know full well how to do it, for many reasons. But you are a professional, and you’ve completed similar tasks in the past, so you either try to figure it out, or find someone who can, and ask them how, or just google it.

[...] The problem comes down to the difference between tasks which require a lot of thinking, and routine tasks which you already have some practice with.

He gives an example of solving a Rubik’s cube, how most people take a very long time to figure it out but there are some that can do it in a matter of seconds. He talks about unexpected complexity and how that can blow previous estimates out of the water. He points out that complexity can be cumulative (related to the number of tasks) and the difference between creative and mechanical tasks.

tagged: software estimate project delay impossible opinion

Link: http://chrismm.com/blog/software-estimations-are-impossible/