News Feed
Sections




News Archive
feed this:

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

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

Link: http://blog.ircmaxell.com/2014/10/educate-dont-mediate.html

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

Link: https://philsturgeon.uk/blog/2014/10/php-wars-attack-of-the-clones

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

Link: http://blog.ircmaxell.com/2014/10/a-followup-to-open-letter-to-php-fig.html

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

Link: http://php-and-symfony.matthiasnoback.nl/2014/10/unnecessary-contrapositions-in-the-new-symfony-best-practices/

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

Link: http://blog.calevans.com/2014/10/14/what-developers-want-recruiters-to-know/

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

Link: http://www.sitepoint.com/good-developer/

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

Link: http://www.reddit.com/r/PHP/comments/2il722/would_you_take_a_job_where_you_had_to_use_a/

Cal Evans:
"Delivery Initiated" A word on having empathy for the users of your software
October 08, 2014 @ 09:24:37

In his latest post Cal Evans reminds us, as software developers, that our jobs aren't always about making the things we create about the best code or most tech. It's also about having empathy for users of the software you're building.

I learned something very important in all of [the troubles I had with traveling to Amsterdam], I learned that we as software developers and designers need to have a great deal of empathy for the people using what we build. It is not enough to put yourself in your user's shoes, you have to put yourself in their mindset. You have to design every user interaction with an understanding of not only who is using your software, but why they are using it.

He focuses the rest of the post on his experience post-delay, trying to get an update on where in the world his luggage might be via a URL given to him by the lost luggage group. He comments on the terseness of the message he was given on the page ("Delivery Initiated") but points out that it's not overly user-friendly and really doesn't give much information. He suggests that the developers of the tool didn't actually think about end users, just that they should share a status and that's all.

It is not enough to create personas and figure out who is using your software. You need to understand why they are using it, and what their mindset will be when they are using it. You need to have empathy for your users.
0 comments voice your opinion now!
user empathy system opinion travel luggage delivery

Link: http://blog.calevans.com/2014/10/07/delivery-initated-a-word-on-having-empathy-for-the-users-of-your-software/

Frank Karlitschek:
A possible future for PHP
October 03, 2014 @ 11:57:06

In a recent post from Frank Karlitschek he speculates about the future of PHP and what when into their (ownCloud) decision to go with it as a primary language. The post also proposes several changes he'd also like to see in the language to help improve it in the future.

PHP is not the most hip programming language in the world. Actually the opposite. It has a relatively bad reputation. I personally was never a big fan of choosing the technologies based on what is cool or "modern" or in vogue. I think there are different technology for different jobs and they should be evaluated objectively and choose without to much emotion involved. So I don't understand the religious discussions why tool x is always better than technology. I think it is all about the right technology for the job after a fair assessment of course. So I'm still very happy with this decision to use PHP. So far we have not seen any bigger architectural technical problems [for ownCloud] that we can't solve with PHP.

Among his suggestions for change are things like enhanced security features (and better teaching around best practices on the topic), a simplified compile and runtime configuration, function/class naming inconsistencies and the introduction of static typing. It's his opinion that this list can help PHP "move to the next level". There's plenty of comments on the post, both supporting and refuting the opinions Frank has included in his list...be sure to give them a read.

0 comments voice your opinion now!
future language opinion features update owncloud

Link: http://karlitschek.de/2014/10/a-possible-future-for-php

Mathias Noback:
Semantic versioning for bundles
September 30, 2014 @ 11:26:40

In a recent post to his site Mathias Noback looks at the use of semantic versioning, introducing some of its basic concepts and how it can relate to the work done in Symfony bundles.

Semantic versioning is an agreement between the user of a package and its maintainer. The maintainer should be able to fix bugs, add new features or completely change the API of the software they provide. At the same time, the user of the package should not be forced to make changes to their own project whenever a package maintainer decides to release a new version.

He breaks down what the version numbering represents (major, minor and patch versions) and how they work with Symfony's "semver" to handle issues that come with backwards compatibility concerns. He then looks at a few things to consider when versioning your bundles and how it relates to the underlying libraries it might use:

  • Bundles expose an API themselves
  • The API of a bundle leads a life on its own
  • A library may contain bugs that are totally unrelated to the bundle
  • A library may contain features that are not implemented by the bundle

Ultimately, he suggests that bundle versioning should have nothing to do with the underlying libraries/packages. It's his opinion that they should only be reversioned when there is a change in the actual bundle.

0 comments voice your opinion now!
semantic versioning symfony bundle package library opinion

Link: http://php-and-symfony.matthiasnoback.nl/2014/09/semantic-versioning-for-bundles/


Community Events





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


zendserver symfony framework podcast api list laravel install release library deployment community series update package tips interview language introduction opinion

All content copyright, 2014 PHPDeveloper.org :: info@phpdeveloper.org - Powered by the Solar PHP Framework