News Feed

News Archive
feed this:

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

Mattias Geniar:
The PHP circle from Apache to Nginx and back
November 20, 2014 @ 10:26:28

In this new post to his site Mattias Geniar goes in circles...from Apache to Nginx and back in terms of how it relates to PHP.

As with many technologies, the PHP community too evolves. And over the last 6 or 7 years, a rather remarkable circle has been made by a lot of systems administrators and PHP developers in that regard.

He talks about the "early days" and the rise of Apache as the "A" in the LAMP stack. Then Nginx was created/released and PHP developers saw it as a viable option. He talks about how PHP worked with this server and the solutions that were found to "hack" them together. There were issues around the relationship, though, and - in the author's perspective - the circle has come back around to Apache, just with a bit more smarts about how it's configured.

0 comments voice your opinion now!
circle apache webserver nginx opinion configuration phpfpm


Matthias Noback:
Packages the case for clones
November 17, 2014 @ 11:55:21

In a new post to his site Mattias Noback makes a case for clones (in response to this post from Phil Sturgeon). In it he defends the creation of "clones" of tools, either slightly different version of pre-existing PHP packages or the functionality from a package in another language.

There is this ongoing discussion in the PHP community (and I guess in every software-related community) about reinventing wheels. A refreshing angle in this debate came from an article by Phil Sturgeon pointing to the high number of "duplicate" packages available on Packagist. I agree with Phil. [...] It doesn't make sense to do the same thing over and over again. At least I personally don't try to make this mistake. If I want to write code that "already exists", at least I don't publish it on Packagist. However, recently I got myself into the business of "recreating stuff" myself.

He talks some about one of his own projects (SumpleBus) and how, despite it possibly being a clone of other packages, it has slightly different goals than other tools, making it a different tool, not just a straight up clone. He also covers some of the package design principles he suggests in his book and how they can help to make an isolated package better. He also points out how recent PHP-FIG efforts to define common interfaces and structures can help reduce this kind of package duplication as well by reducing the possible implementations of any given process.

0 comments voice your opinion now!
package reinvent wheel opinion duplication design principles phpfig clone


Anthony Ferrara:
Foundations Of OO Design
October 30, 2014 @ 09:36:24

In his newest post Anthony Ferrara looks at some of the things he calls the foundations of object-oriented design, as set of three things (and principles) to keep in mind when working on OOP applications.

It's quite easy to mix up terminology and talk about making "easy" systems and "simple" ones. But in reality, they are completely different measures, and how we design and architect systems will depend strongly on our goals. By differentiating Simple from Easy, Complex from Hard, we can start to talk about the tradeoffs that designs can give us. And we can then start making better designs.

He starts with the "simple vs easy" concept and how sometimes making the two meet can be difficult. He includes an example of interdependent interfaces and how they add complexity (and, in turn, make them less easy to use). He also talks about accidental versus essential complexity and how, sometimes, "accidental" isn't always a bad thing. Finally, he wraps it up with a few principles to remember in your development including recommendations to reduce (accidental) complexity and keeping the target developers in mind, making it easiest for them to use.

0 comments voice your opinion now!
foundation oop objectoriented design complex simple developer opinion


Anthony Ferrara:
Educate, Don't Mediate
October 21, 2014 @ 11:53:55

In his latest post Anthony Ferarra makes a suggestion about teaching developers how to solve problems via a "quick fix" versus educating them about the real problem: educate, don't mediate.

Recently, there has been a spout of attention about how to deal with eval(base64_decode("blah")); style attacks. A number of posts about "The Dreaded eval(base64_decode()) - And how to protect your site and visitors" have appeared lately. They have been suggesting how to mitigate the attacks. This is downright bad. The problem is that these posts have been suggesting things like "Disable eval()" and "Disable base64_decode()" as possible solutions. And while technically that would work, it completely misses the point, and does nothing to protect users

He suggests that developers shouldn't just look for a "quick fix" solution posted in a tutorial somewhere and go on their merry way. One danger in this is that those instructions could only be patching part of the problem, not all of it. In this case, the disable eval/base64 handling is only a code-level fix. If this exploit exists in your application, the attacker was able to get to the local file system - a much bigger problem.

0 comments voice your opinion now!
educate mediate opinion bugfix quickfix eval base64 encode decode


Phil Sturgeon:
PHP Wars Attack of the Clones
October 21, 2014 @ 10:18:02

In one of his recent posts Phil Sturgeon talks about what he calls the "Attack of the Clones" on Packagist. In this case, he's referring to the number of packages that all pretty much do the same thing, just in slightly different ways.

n the last article I said I wanted to write about when its a good idea to release a component. A lot of this comes down to: is there one out there that does what I want, and if so, can I use it. This blog post is going to touch on a lot of points already made well by Anthony Ferrera. His article Reinvent The Wheel! says many of the same things, so if you only have time to read one article right now, go and read that. I've been talking with various people on Twitter about how I see a lot of people building what I consider to be clones. [...] It should go without saying that I'm not trying to quash innovation; I just don't think building identical shit over and over again is innovation. I see people wasting their time, and I know that time could go to better use.

He talks about how he's not opposed to innovation and development for the sake of learning, but that often the packages released are lower-powered versions of already established, well-tested packages. These kinds of packages can clutter the results when the packages are searched and prevent developers from finding the best fit for what they need. He mentions frameworks, but doesn't dwell on them as they're a bit more "self-contained" than just packages. He also touches on the curation of packages (guiding people to the right ones) as a possible solution and looks at how some of the other communities out there handle this same problem.

0 comments voice your opinion now!
clones package opinion curation learning innovation community


Anthony Ferrara:
A Followup To An Open Letter To PHP-FIG
October 17, 2014 @ 11:51:35

Based on some of the responses to his previous open letter to the PHP-FIG (Framework Interoperability Group), Anthony Ferrara has posted a follow-up explaining some of his points made and the caching proposal in a bit more detail.

A few days ago, I wrote An Open Letter to PHP-FIG. Largely the feedback on it was positive, but not all. So I feel like I do have a few more things to say. What follows is a collection of followups to specific points of contention raised about my post. I'm going to ignore the politics and any non-technical discussion here.

He points out that while the previous post wasn't completely about the cache proposal (it was used as a "literary device") there was some confusion on it. He walks through the "unnecessary complexity" he sees with it, citing code examples, and makes points about performance, memory usage handling stampede protection and the creation of standard ways to avoid it. He ends the post with a look at group invalidation handling and two ways it could be accomplished, either via namespacing or through tagging the items and using that as a reference point for the invalidation.

0 comments voice your opinion now!
open letter phpfig cache proposal detail opinion problem


Matthias Noback:
Unnecessary contrapositions in the new "Symfony Best Practices"
October 15, 2014 @ 12:29:31

Matthias Noback has a new post today with some of his thoughts about the recently released Symfony Best Practices book and some "unnecessary contrapositions" and things he sees that could help improve the perception of the book and the advice it provides.

Of course I'm going to write something about the new Symfony Best Practices book that was written by Fabien Potencier, Ryan Weaver and Javier Eguiluz. It got a lot of negative responses, at least in my Twitter feed, and I think it's a good idea to read Richard Miller's post for some suggestions on how to deal with an "early preview release" like this and how we can be a bit more positive about it.

He emphasizes the "staying positive" aspect of his message and points out that while some of the suggestions are good, they may not be the "best" in all circumstances. His main point, though, is that he thinks the way the book was introduced (the wording of the post) was unfortunate and cast a more negative light on the work done previously around Symfony best practices and advice. He recommends changing things around a bit in both the messaging and the book itself to take the focus away from the "you're doing it wrong" and encourage people to do it the way they recommend, casting a more positive spin on it all.

0 comments voice your opinion now!
symfony bestpractices guide reaction opinion positive


Cal Evans:
What Developers Want Recruiters to Know
October 15, 2014 @ 11:56:25

Cal Evans asked a question on Twitter the other day of his followers for advice, from developers, to share with recruiters and how they can do their job better when it comes to recruiting talent.

I post this not to belittle or ridicule recruiters. I think that good recruiters are a valuable part of the tech ecosystem. I post this to hopefully help more recruiter become good recruiters.

He's listed all of the responses he's gotten in the post (via Storify) as individual tweets. There's a few recurring themes happening and lots of good advice including:

  • "treat developers as human beings"
  • "We're smart people, we can see an email isn't personal. Treat us like the individuals we are."
  • "Read the profile before sending out CV, I am not a Ruby developer."
  • "Googlebing someone before emailing them. Know who they are."
  • "don't try to sound like you know what you're talking about if you don't. You just lose respect."
  • "build a relationship with me, not a one night stand"
  • " Have the decency to at least get back to devs if the end client hasn't chosen them"

If you are or know of a recruiter, please share this post with them. The unfortunate fact is that there's a lot of recruiters out there that don't realize that this is how to talk to developers (and sadly, some don't event care).

0 comments voice your opinion now!
recruiter developer advice twitter feedback opinion


SitePoint Web Blog:
How to be a Good Developer
October 13, 2014 @ 11:54:17

On the SitePoint Web Blog there's a recent post by George Fekete with a few suggestions about how to be a good developer, regardless of the language or technology you're using.

As a PHP developer, or any kind of developer as a matter of fact, you need to constantly improve yourself in this ever-changing industry; you need to learn and use new knowledge every day. What successful developers have in common, is that they care about programming a lot, they are professionals treating good programming practices as a form of art. In this article, you'll learn about how to be a better developer by following the "etiquette" of programming and you'll learn how to use this information to perhaps teach others to better themselves.

He starts with some tips about "being professional" overall that include things like being responsible and having a strong work ethic. Then he moves into writing good code. This isn't about actual code examples, more about good practices and tools. He also shares some tips about how to keep things (and yourself) on track and tips on how to "be a master" when it comes to social interactions and the work you're doing.

0 comments voice your opinion now!
good developer opinion professional code focus communication

Would you take a job where you had to use a custom MVC framework?
October 08, 2014 @ 12:57:00

There's an interesting discussion happening in the /r/php subreddit on that asks about taking a job if a custom framework was involved.

i recently got a new job and whilst I'm working my notice period I've been tasked to find my replacement. One of the big questions my boss has is whether a developer would mind taking over a MVC framework I built specifically for the company. (I would explain why we didn't use Laravel / Symfony / Zend etc. but that's a whole post in itself). The framework is conventional and should feel familiar to someone with Laravel experience... But at the end of the day it's totally proprietary. It's built to PHP-FIG standards and would come with full documentation. So, would you have any issues taking the job, or would you be put off?

There's opinions shared that lean both ways, but there seems to be a large majority that strays more heavily into the "no" column. They suggest that, with all of the great and well-developed PHP frameworks already out there, a custom one would probably cause more problems that it solves. While there's plenty of technically oriented comments, there's also a few that are more "high level" looking at the reasoning for taking the job (hint: it's not just about technology) and what the needs/requirements of the business are.

0 comments voice your opinion now!
opinion custom mvc framework work


Community Events

Don't see your event here?
Let us know!

symfony language update framework application release introduction tool voicesoftheelephpant community series composer laravel security library interview version opinion podcast package

All content copyright, 2014 :: - Powered by the Solar PHP Framework