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

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/

Intracto Blog:
Paying Technical Debt - How To Rescue Legacy Code through Refactoring
Mar 17, 2016 @ 09:36:16

On the Intracto blog there's a new article posted from Jeroen Moons with some suggestions you can use to pay down technical debt in your legacy code through a bit of effective refactoring.

I have good news for you! Squirrels plant thousands of new trees every year by simply forgetting where they leave their acorns. Also: your project can be saved.

No matter how awful a muddy legacy code mess your boss has bravely volunteered for you to deal with, there is a way out of the mire. There will be twists and turns along the way, and a monster behind every other tree. But, one step at a time, you will get there.

He gives lost of different suggestions for things that can be done to "save your code" and make it not only easier to maintain but more flexible:

  • Persuading the customer
  • Don't replace [a huge mess] with a new one
  • Make problems visible
  • Fight what hurts most
  • Build a library

There's plenty more great suggestions here too with some thoughts and methods to back them up and help you accomplish them in your own code. If you're suffering through a large legacy codebase from day to day, I highly recommend reading through this article.

tagged: technicaldebt legacy legacycode rescue opinion method refactor

Link: http://marketing.intracto.com/paying-technical-debt-how-to-rescue-legacy-code-through-refactoring

Paul Jones:
Why Do PHP Developers Think MVC Is An Application Architecture?
Mar 16, 2016 @ 11:49:51

In a new post to his site Paul Jones wonders out loud about why developers think MVC is an application architecture versus just a user interface pattern.

I’ve pointed out before that Model-View-Controller is a user interface pattern, not an application architecture. But why would PHP developers get the idea that MVC is an application architecture in the first place?

[...] I used to think that MVC was an application architecture. Even after reading Fowler’s POEAA and seeing that MVC was for the user interface, I figured that meant I was doing “user interface applications.” But that was not quite right; it would have been more accurate to say that I had been mixing the concerns of user interface with the underlying core application.

He suggests that the reason MVC is commonly thought of as an architecture is because of the "flow" most PHP developers follow in their learning and development practices. Starting from "page scripts" where things are all mashed together, a developer then learns about the separation of concerns and how MVC helps splitting up the application easier. Paul includes a reminder, though, that the "user interface" isn't really just the frontend parts (HTML, CSS, JS) but the HTTP request/response to and from the application.

tagged: mvc modelviewcontroller application architecture progression developer opinion

Link: http://paul-m-jones.com/archives/6288