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

PHP Roundtable:
015 SemVer, Licensing & OS Support Expectations
March 20, 2015 @ 12:56:03

The PHP Roundtable podcast has posted their latest episode, part two in a series looking at semantic versioning, open source support expectations and licensing. This new episode features guests Colin O'Dell and Chris Tankersly.

Part 2 of an on-going series on open source. We discuss a number of open source topics including what the expectations are for support of an open source project. We also discuss how to use SemVer to successfully maintain an open source package and what we can do when SemVer is not an option. And finally we take a look at licensing and discuss why we need to be concerned with it.

You can listen to this latest episode by checking out the video of the live recording, coming in at about 1 hour. If you enjoy the show, be sure to subscribe to their feed to get the latest updates on when new episodes are available.

0 comments voice your opinion now!
phproundtable podcast video semver licensing opensource support expectation

Link: https://www.phproundtable.com/episode/semver-licensing-os-support-expectations-open-source-series-part-2

Rafael Dohms:
Why I support "The League"
March 11, 2015 @ 12:47:27

Rafael Dohms has posted some if his own thoughts to his site about The League of Extraordinary Packages and why he supports their efforts to bring a good solid base of curated packages to the PHP ecosystem.

"The League of Extraordinary Packages" is what I have dubbed a collective of composer packages. Its essentially a group of developers who have gathered under a single flag (or in this case a vendor name) and set standards for the packages that live there.

Why does this even matter? Well for one Packagist is an open repository, this means that it is wide open for anyone to join, from the best packages to the most ridiculous ones. Quality control is not one of its roles and quality checking is on average 2-3 clicks per package away.

He talks about the quality control measures The League has in place to only contain good, well-tested and solid PHP packages. He also lists a few of his main reasons for supporting the effort including the fact that it reduces author fragility and provides an extended reach for those packages to reach a wider audience.

I really enjoy the work being done by The League, or The PHPLeague, or Pleague as I prefer to call it. I think it has provided us with some very good packages and given us all something to strive for. Maybe more collectives is what we need.
0 comments voice your opinion now!
thephpleague support packages extraordinary packagist curated

Link: http://blog.doh.ms/2015/03/10/why-i-support-the-league/

Laravel News:
Homestead Now With Blackfire Support
February 27, 2015 @ 10:05:47

As is mentioned in this new post to the Laravel News site, the Homestead development environment now comes with support for the Blackfire.io profiler.

Blackfire Profiler by SensioLabs automatically gathers data about your code's execution, such as RAM, CPU time, and disk I/O. Homestead makes it a breeze to use this profiler for your own applications. All of the proper packages have already been installed on your Homestead box, you simply need to set a Blackfire ID and token in your Homestead.yaml file

With the configuration set up, the only installation the user needs to make is setting up the companion extension (Chrome) for your browser.

0 comments voice your opinion now!
blackfire support laravel homestead development environment performance

Link: https://laravel-news.com/2015/02/homestead-now-with-blackfire-support/

Anthony Ferrara:
Being A Responsible Developer
December 30, 2014 @ 09:04:17

In his latest post Anthony Ferrara is back with more discussion around the "only supporting the latest versions" debate (here is the previous article). In this new post he talks about being a "responsible developer" and how that relates to keeping your software up to date.

The general consensus [shared during a DevHell and PHPTownHall Mashup ] was that as an ideology, only supporting latest versions is correct. From a practical standpoint though they said that it's unrealistic. That there are tons of legacy systems out there that are running just fine and can't justify the cost of upgrading. So they shouldn't have to upgrade "for ideological reasons". From one point of view, this certainly makes sense. [...] This point of view disturbs me deeply. And it further disturbs me that it came from the same person who preaches for testing.

He makes the connection between being responsible and the software upkeep through testing. He points out that the real effectiveness of automated testing is in preventing regressions - that is, when software is updated, that bugs don't reappear. He then goes on to share his opinion on some of the other arguments presented in the recording like the "if it ain't broke, don't fit it" and security issues topics. He also shares some number of the reality of what can happen if software is not up to date (or even patched) and how this circles back around to his previous points about software versions driving the OS and PHP versions forward.

0 comments voice your opinion now!
responsible developer opinion software version upgrade support

Link: http://blog.ircmaxell.com/2014/12/being-responsible-developer.html

Anthony Ferrara:
On PHP Version Requirements
December 22, 2014 @ 10:13:59

In his latest post Anthony Ferrara talks about PHP version requirements and how it's a bit of "chicken and egg" problem. If hosting providers are slow adopting even PHP 5.4, can we realistically bump up the minimum to PHP 5.4+ and potentially shun users not at that level yet?

Most people agreed with me [saying new software with a PHP requirement <= 5.2 is beyond irresponsible, it's negligent], saying that not targeting 5.4 or higher is bad. But some disagreed. Some disagreed strongly. So, I want to talk about that.

[...] Now, these are pretty interesting arguments. It boils down to making the logical argument that if hosts don't support 5.4+, then moving to require 5.4+ would leave the users who use those hosts abandoned. And some projects don't want to abandon users. It's a warm and logical idea; Open your arms to everyone, and include them all. Don't leave anyone behind. Really, it's a good argument. The problem is, is it based on a flawed premise...?

He suggests that it sounds somewhat like an appeal to emotion and that by enforcing a bump up like this would be "abandoning the users". He gets into some of the statistics he worked up regarding PHP versions, WordPress usage and how, because of these large numbers, hosting companies would make the move if only for business reasons. He talks about the "Go PHP5" initiative and the impact it made on versions supported across the board. He also looks at some of the reasons why keeping up with these versions is good for the hosting companies too: security, education of users and the new features that come with later versions.

So I put this to you, WordPress, CodeIgniter and every other CMS and Framework still supporting PHP 5.2 and 5.3 (and earlier versions): Step up and lead. Step up and be the change you want to see. Don't follow and react, lead and be proactive. After all, if we can move forward together, we can all benefit. But if we walk separate paths, we build walls and we all lose...
0 comments voice your opinion now!
version requirements opinion hosting project support

Link: http://blog.ircmaxell.com/2014/12/on-php-version-requirements.html

Fabian Schmengler:
Why I Am Actively Going to Drop PHP 5.3 Compatibility
December 11, 2014 @ 12:15:30

In a recent post to his site Fabian Schmengler has proposed a PHP 5.3 "Death March" in an effort to try to drop PHP 5.3 compatibility for applications and encourage the growth of PHP 5.4 and beyond.

An alarming large amount of websites still runs on PHP 5.3, which does not get updated anymore since 2014/08/14, after one year of "security only" support. In other words, the next critical security hole will only be fixed for versions above 5.4. By the way, active development of the PHP 5.4 branch was discontinued on 2014/09/14. it's already in the "security only" phase. On 2014/08/28, PHP 5.6 has been released, on 2013/06/20, almost 1.5 years ago, PHP 5.5. So, by now, in the year 2014 everybody should work on PHP 5.5, right? [...] Almost half of the Alexa Top 1M Sites that run on PHP, state the version 5.3, ca. one quarter even 5.2, which is not supported since Jan. 2011. PHP 5.2.17 even is the most used patch version in this statistic.

He goes through some of the thinks might be contributing to this drag in adoption including the slow migration of official Linux distribution packages and the incompatibility of applications and frameworks with newer PHP versions. He makes a few suggestions of what different groups can do to help the cause - developers, project managers and hosting companies. He provides a list of things that are either deprecated in 5.4 or have been completely removed.

0 comments voice your opinion now!
php53 php54 support compatibility drop

Link: http://www.schmengler-se.de/en/2014/11/why-i-am-actively-going-to-drop-php-5-3-compatibility/

Kevin Dunglas:
PHP 7 Introducing a domain name validator and making the URL validator stricter
November 28, 2014 @ 09:45:19

In his latest post Kevin Dunglas has released information about a patch for URL filtering that aims to bring more validation and functionality to the pre-existing filter_var functionality.

Until now, there was no PHP's filter validating that a given a string is a valid domain name (or hostname). Worst, FILTER_VALIDATE_URL was not fully enforcing domain name validity (this is mandatory for schemes such as http and https) and was allowing invalid URLs. FILTER_VALIDATE_URL was also lacking IPv6 host support.

His patch introduces support for domain validation rules more strict to what the RFC defines and includes IPv6 support. There's a few code examples included in the post showing the new support. He points out that there's still some things that aren't supported yet, like internationalized domains, but there's future plans for it.

0 comments voice your opinion now!
php7, filtervar, filter, url, domain, patch, support

Link: http://dunglas.fr/2014/11/php-7-introducing-a-domain-name-validator-and-making-the-url-validator-stricter/

PHP.net:
New Supported Versions Timeline Page
October 29, 2014 @ 11:18:40

The PHP.net website has introduced a new feature to help make it a bit clearer which versions of PHP are supported and which have reached their end-of-life mark. This new Supported versions page off the main site provides listings of currently supported versions and graphical timelines of past (and future) support milestones.

Each release branch of PHP is fully supported for two years from its initial stable release. During this period, bugs and security issues that have been reported are fixed and are released in regular point releases. After this two year period of active support, each branch is then supported for an additional year for critical security issues only. Releases during this period are made on an as-needed basis: there may be multiple point releases, or none, depending on the number of reports.

The page includes information on when the initial release in a series was made (like the 5.4.x or 5.5.x series), when active support did/will end and how long the timeline is for security fixes and support. As of the time of this post, PHP 5.3.x is the only series that has reached end-of-life, but the 5.4.x series is coming close being in security fix only mode now and EOL-ing completely in ten months.

0 comments voice your opinion now!
version support timeline page phpnet release bugfix security

Link: http://php.net/supported-versions.php

HHVM Blog:
HHVM Long Term Support
September 03, 2014 @ 10:50:20

The HHVM (HipHop VM from Facebook) has released an update on their blog today discussing some of the long term support they plan to provide for the project and what kinds of things it will involve.

HHVM is known for its very intense and quick development pace: currently we ship to GitHub the exact same code we use to run the Facebook site within minutes of every commit, and we release a full version every 8 weeks. That is great and at the same time scary if you are trying to build a business or infrastructure around it. The HHVM team at Facebook understands that in order to reach every corner of the PHP landscape our users need to have some sort of commitment, in order to plan their deployments accordingly and to know how upstream will react to security and stability fixes in already released versions, for example.

Starting with HHVM v3.3, they'll be supporting two major versions at all times. They provide a table of versions and dates to give you an idea of when the support coverage period is and when they'll end. There's also some discussions about the packaged released for the various linux distributions and what kinds of updates might be included in the long-term support (LTS) updates.

0 comments voice your opinion now!
hhvm support hiphop virtualmachine schedule longterm version

Link: http://hhvm.com/blog/6083/hhvm-long-term-support

SitePoint PHP Blog:
Legacy Code is a Cancer
August 04, 2014 @ 11:08:45

In the latest post to the SitePoint PHP blog Bruno Skvorc proposes the idea that "legacy code is a cancer" that can influence decisions and technology choices that shy away from the new and possibly more functional alternatives.

This might come out controversial, but I firmly believe there is no room for legacy code in modern systems. Allow me to elaborate before you sharpen your pitchfork and light your torch. What I mean by that is: there should be absolutely zero reason to keep implementing the functions you're adding to the new version retroactively into the old version, just because some people are still using it, even if the people using it are a vast majority.

He talks about the "support everything for as long as we can" ideal and how it can come back to bite you in the end. He suggests that, at some point, the v1 users have to "be discarded" and dropped for the upgraded version of the application. He talks about failure potentially brining around success and compares applications versus libraries and components and the upgrade path for each. He ends the post with a suggested upgrade path to move the system itself away from legacy support and into the new, latest version.

0 comments voice your opinion now!
legacy code cancer maintenance upgrade support users

Link: http://www.sitepoint.com/legacy-code-cancer/


Community Events

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


podcast version laravel5 php7 api opinion community video unittest introduction language laravel framework interview library security voicesoftheelephpant release series example

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