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

Liip Blog:
New Relic extension for HHVM updated to latest version
January 20, 2015 @ 10:04:14

In his latest post to the Liip blog Christian Stocker points out that the New Relic extension for HHVM has been updated for the latest versions of HHVM to work a bit more seamlessly.

Since HHVM 3.4 it's theoretically possible to have your own external profiler for function level profiling (like xhprof or xdebug) without having to recompile HHVM itself. Unfortunately it wasn't perfect (or I couldn't make it running), but there's a patch in the master branch now (the upcoming 3.6), which seems to solve that problem. So I worked a little bit on my extension in the last few days and I adjusted a lot of things and improved some other stuff.

He talks about the improvements New Relic has made on their functionality and some slowness that still exists in the "hotprofiler". He points out, however, that if you just want overall statistics and not specific, method level ones, you don't really even need to use it. He offers a word of caution when using his extension and when it may fall back to "userland level profiling" instead.

0 comments voice your opinion now!
liip hhvm newrelic extension update version release

Link: http://blog.liip.ch/archive/2015/01/19/new-relic-extension-for-hhvm-updated-to-latest-version.html

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

Matthieu Napoli:
Test against the lowest Composer dependencies on Travis
December 18, 2014 @ 10:53:58

Recently the "prefer-lowest" option of Composer was mentioned in relation to testing for Symfony-based applications. In this new post to his site Matthieu Napoli shows how you can do it on any project that uses the Travis-CI continuous integration service.

Composer just got a new awesome addition thanks to Nicolas Grekas: prefer the lowest versions of your dependencies. [...] This amazing option will install the lowest versions possible for all your dependencies. What for? Tests of course!

He includes all the instructions you'll need to get your Travis build using this command line option, starting with testing it on your own system first. He shows a basic ".travis.yml" file with the configuration you'll need to provide it use the "prefer-lowest" (check out line 17). He does point out that you'll need to run a "composer self-update" first though, as Travis hasn't quite caught up with the latest Composer that includes this option.

0 comments voice your opinion now!
test lowest dependency version composer travisci tutorial

Link: http://mnapoli.fr/test-lowest-dependencies/

Symfony Blog:
Testing minimal versions of Symfony requirements
December 17, 2014 @ 12:02:47

On the Symfony blog today there's a quick tip from Nicolas Grekas about using Composer to install a Symfony2 project and the definition of minimum version requirements.

Setting up Composer package versions for complex projects is not an easy task. For starters, there are a lot of different ways to define package versions. Then, you must check that declared package versions really work when installing or updating the project, specially for the minimal versions configured. In order to improve testing the minimal versions of Symfony Components requirements, Composer now includes two new options: prefer-lowest and prefer-stable. [...] Thanks to these two new options, it's really easy to check whether your project really works for the minimal package versions declared by it.

He includes definitions of what impact each of the options has on the packages Composer installs and the work that's been done recently to define the correct package versions for the 2.3, 2.5 and 2.6 branches of Symfony. He also offers some steps to follow in your own projects to ensure that the "prefer-lowest" packages installed work correctly.

0 comments voice your opinion now!
symfony framework package version preferlowest preferstable

Link: http://symfony.com/blog/testing-minimal-versions-of-symfony-requirements

Lee Blue:
PHP vs Ruby - Application Shelf Life
December 10, 2014 @ 13:19:15

Lee Blue has started up a series of posts talking about his reasoning for moving back to PHP from Rails in his applications. In his first post of the series, he looks at application "shelf life" and the overall lifespan of the project and how that relates to things like maintainability and upgrade handling.

I plan to write a series of posts about how we develop, deploy, and support our affiliate software and digital downloads applications. And why, after 5 years of Ruby on Rails development we switched back to PHP. One of the reasons is what I refer to as the shelf life of a web application. Let's talk about what happens to a web application if you just let it sit.

He talks about the "rotting on the vine" that one of his clients' Rails 1.0 application faced when the later versions of the Ruby on Rails framework. He talks about how these kinds of upgrades cost money (and time) and how, with the right selections for the deployment stack, some of the costs could be alleviated. He gives the example of a PHP-based deployment setup and how much of the related technology has been stable and (mostly) unchanging over the years, just with new features being added. He offers a few suggestions to avoid this "app rot" and things startups/freelancers can do to help prevent it in their clients' applications.

0 comments voice your opinion now!
ruby shelflife application rot version deployment stack opinion rubyonrails

Link: http://leehblue.com/php-vs-ruby-application-shelf-life/

Jordi Boggiano:
My view of PHP version adoption
November 18, 2014 @ 09:28:12

Jordi Boggiano has a new post today sharing some of his own insights about PHP version adoption but, unlike some of the raw numbers shared before, his perspective comes from aggregating data from Packagist.

Pascal's number are interesting but I believe they have a bias towards older PHP versions. I would argue that people configuring their servers properly are also those that tend to keep up to date with newer versions, and part of the best practices is to avoid publishing the software versions you are using (i.e. disable expose_php in php.ini). If I am correct here that means early adopters are mis-represented in those numbers. In any case, I do have another biased dataset to present so here it comes! I looked in the packagist.org logs of the last fifty days for GET /packages.json which represents a composer update done by someone.

He notes that the data is biased towards development machines (not always running the same version as their production counterparts) but that it shouldn't skew the numbers too much. He compares two different datasets, one from November 2013 and the other from November 2014, showing a major change in the overall numbers and moving the largest version used up from 5.3.10 to 5.5.9. He also shares some interesting statistics around the requirements developers are putting on Packagist packages...that have basically remained the same over the past year (sadly).

0 comments voice your opinion now!
jordiboggiano version adoption packagist statistics

Link: http://seld.be/notes/my-view-of-php-version-adoption

Matt Stauffer:
Introducing Laravel Homestead 2.0
November 17, 2014 @ 10:41:45

In his latest post Matt Stauffer has posted a guide to the latest release of the Laravel Homestead project, version 2.0, walking you through the installation, configuration and validation of this virtual machine.

When Laravel Homestead first came out, it was a Github repository that included a base Homestead.yaml by default. There was no prescribed place to install it, no global commands for accessing the box, and any time you actually customized your Homestead.yaml file you instantly dirtied your Homestead Github clone, making upgrading difficult.

You can guess where I'm going with this. All of these things are problems no more. The latest version of the Homestead ecosystem has just been released, and it's moved Homestead into a globally installable Composer package which copies Homestead.yaml (and any other user-editable files) into ~/.homestead on your machine.

He covers the two different ways you'd get this updated version - the fresh install (no previous VM installed) and the upgrade path. For each all of the commands and configuration updates you'll need are included. He also points out some of the new features and handling as he goes along.

0 comments voice your opinion now!
laravel homestead version introduction install configure setup tutorial

Link: http://mattstauffer.co/blog/introducing-laravel-homestead-2.0

SitePoint PHP Blog:
Joomla's Coming of Age
November 13, 2014 @ 12:56:15

In the latest post to the SitePoint PHP blog Adedayo Adeniyi talks about Joomla's "coming of age" and some of the changes that have come/are coming in the latest versions.

Over the years, there has been a healthy rivalry between the main CMSes in use on the planet: WordPress, Drupal, and Joomla!, and all three have hosts of die-hard fans that would pitch for their favorites over the others any day. Don't worry, I'm not about to add to the high pile of subjective CMS comparison posts available on the web. Instead, I will briefly review all the recent changes in Joomla! that have modernized it for the present day developer - from version 3.0 onwards (currently 3.3).

She talks about some of the most recent changes including easier updating, the tool being mobile friendly out of the box and more flexible user access handling. She also mentions the improvements in "developer friendliness" and that it's become a good bit more security-conscious. Other topics mentioned include the JED (Joomla Extension Directory), smart search/tagging and improved database handling.

0 comments voice your opinion now!
joomla improvement version update cms contentmanagement

Link: http://www.sitepoint.com/joomlas-coming-age/

SitePoint PHP Blog:
How to Run Multiple Versions of PHP on One Server
November 07, 2014 @ 10:54:27

The SitePoint PHP blog has a new tutorial by Thien Tran Duy showing you how to run multiple versions of PHP all on the same server. The key is in using a few custom configuration options (you'll be compiling PHP manually for this) to place the different versions in different locations.

In this particular post, we'll demo a solution to install multiple versions of Phalcon and PHP and run them on a single web server. PHP 5.5.x and 5.6.x will be used here, but you can replace them with other versions. Any servers that support PHP-FPM should be enough but we recommend using Nginx. The environment used in this tutorial is Fedora OS - a Linux system, but the instructions are almost identical for any other *nix OS.

The tutorial also includes the installation of a few other PHP extensions including APC caching, memcache and ioncube. He walks you through the installation of Nginx first to get the web server up and running. Then he starts in on the PHP installs and the requirements to ensure you have to be able to compile from the PHP source. He shows how to pull the different versions of PHP down (5.3, 5.4, 5.6 and master) from the GitHub repository and execute the "buildconf" to make the configure script. He includes the example configuration command with options, ensuring it will work with PHP-FPM and the Nginx server. He then reproduces the process, making slight changes, for the other versions of PHP. Finally, he shows the installation of the two different versions of Phalcon and configuring it to all work with the installed web server.

0 comments voice your opinion now!
multiple version one server language tutorial phpfpm nginx

Link: http://www.sitepoint.com/run-multiple-versions-php-one-server/


Community Events





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


framework opinion release interview series community voicesoftheelephpant unittest list composer language configure conference introduction podcast api tool symfony version laravel

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