PHP Community

Community News: phpBB Participates in the Google Summer of Code

PHPDeveloper.org - Thu, 13/03/2014 - 18:54

As is mentioned in this new post to the phpBB forums, the project is participating in the Google Summer of Code project this year. phpBB is one of the longest running, widely used open source PHP forums software.

With two years of participation under our belt, I am glad to announce that phpBB is once again taking part in the Google Summer of Code (GSoC) program this year. Google's Summer of Code program encourages students to get involved in free and open source software (F/OSS) by pairing them up with experienced mentors in popular F/OSS projects.

If you're interested in working on the phpBB project this year, check out their Ideas page for some examples of things they're wanting to work on. You'll need to be familiar with the git version control system to do the work and will need to apply to be considered for this year's event.

Link: https://www.phpbb.com/community/viewtopic.php?f=14&t=2231996

Anthony Ferrara: Why I Don't Recommend Scrypt

PHPDeveloper.org - Thu, 13/03/2014 - 17:11

Anthony Ferrara has a new post today looking at password hashing and a type of hashing that's beginning to get more attention in the PHP community - scrypt. However, he doesn't recommend it for production password storage and shares his reasoning why.

Scrypt was not designed for password storage. It was designed as a key derivation function for generating keys from weak material (namely passwords). The prime type of attack that scrypt is designed to defeat is ASIC based attackers. It is not designed to try to favor CPU over GPU (and thereby defeat GPU based attacks). It is this fact that we can leverage to gain an advantage when used as a password hashing mechanism.

He covers some of the basic design decisions that were made when scrypt was created. He also points out that none of the results of these decisions are strictly fatal, they just make it a bit weaker than something like bcrypt for password storage. He goes through the basic inputs scrypt requires and includes a quick snippet of code (not PHP, but easy to understand) showing its use. He talks about its "chain of 4 operations" and gets into what he sees as limitations: loop unrolling and the tune-able reduced memory usages. He finishes off the post mentioning that scrypt is still secure, but despite this he doesn't recommend it for password storage specifically.

Link: http://blog.ircmaxell.com/2014/03/why-i-dont-recommend-scrypt.html

SensioLabs Insight Blog: Jenkins integration

PHPDeveloper.org - Thu, 13/03/2014 - 16:06

The latest post to the SensioLabs Insight blog today shows you how you can integrate the service with Jenkins as a part of your pre-existing continuous integration workflow.

One of the main features of SensioLabsInsight service is that it integrates smoothly into your existing workflow and technical infrastructure. We know that most companies use Jenkins as their continuous integration server and for that reason, SensioLabsInsight provides out-of-the-box Jenkins integration.

The integration uses the Insight API to perform the checks and return a report of the results. They step you through the process to get the connection set up (using the API client) and send the request for processing. The result is returned in PMD format, something Jenkins can easily parse and integrate into the pass/fail of the job. You can also get the details of the issues including error message, file location and the priority of the issue.

Link: http://blog.insight.sensiolabs.com/2014/02/12/jenkins-integration.html

Community News: Packagist Latest Releases for 03.13.2014

PHPDeveloper.org - Thu, 13/03/2014 - 15:01
Recent releases from the Packagist:

The performance penalty of the early MySQL Fabric support for PHP

Planet-PHP - Thu, 13/03/2014 - 00:42

PECL/mysqlnd_ms 1.6 is currently being modified to support sharding and fully automatic server and client failover when using MySQL Fabric (slides) to manage a farm of MySQL servers. PECL/mysqlnd_ms is a mostly transparent load balancer that works with all PHP MySQL APIs (PDO_MySQL, mysqli, …). The idea is, that if, for example, a MySQL server fails, the plugin talks to MySQL Fabric to learn about alternative servers that Fabric has provisioned automatically. This “talks to” gives implies a performance penalty for applications. One worth looking at, to understand it. One worth looking at, to have a success story once the early implementation is gone and replaced with a proper one ;-) .

Behind the scenes…

How exactly a “Fabric aware” driver or application talks to Fabric is implementation dependent. Figures given for PHP must not be used to extrapolate behaviour of Connector/J or Connector/Python. Only remarks about Fabric itself apply to all.

Let’s assume you want to use MySQL Fabric and PHP for sharding. Fabric takes care of all the server side stuff: splitting, merging, monitoring shards and so forth. The PHP application ensures that queries end up on the appropriate shards by hinting the driver which shard to use. In the PHP case, the “driver” is the PECL/mysqlnd_ms plugin for mysqlnd. The plugin exports a function mysqlnd_ms_select_shard() for hinting it.

$mysqli = new mysqli("myapp", "user", "password", "database");
mysqlnd_ms_select_shard($mysqli, "mydb.mytable", "key");
$mysql->query("INSERT INTO mytable(col1) VALUES ('abc')");

This tiny snippet triggers a huge machinerie: from you application it goes to the plugin. Then, the plugin calls Fabric via XML RPC over HTTP and waits for a reply. Once Fabric has replied, the plugin makes the connection handle point to the shard.

Client   Fabric mysqlnd_ms_select_shard(link, table, key)   PECL/mysqlnd_ms *.c XML RPC over HTTP: sharding.lookup_server(table, key, LOCAL) ->     HTTP worker thread   Executor   <- XML reply HTTP worker thread PECL/mysqlnd_ms: make $link use shard mysqli_query($link, …) The hotspots

Switching a connection from one server to another takes some effort. The current implementation will simply replace an plugin internal list of servers. This is a very fast operation. No new MySQL connection is opened yet. By default, lazy connections are used and the connect to the shard is delayed until the application issues a query. Let’s consider this a cheap step, that can be marked green below.

Client   Fabric mysqlnd_ms_select_shard(link, table, key)   PECL/mysqlnd_ms *.c XML RPC over HTTP: sharding.lookup_server(table, key, LOCAL) ->     HTTP worker thread …

Asking Fabric for a set of one master any number of additional slaves that make a shard is expensive. Upon every call to mysqlnd_ms_select_shard(), PECL/mysqlnd_ms opens a HTTP connection to Fabric to make an XML remote procedure call. Future version of the mysql plugin will do less calls, but that’s no

Truncated by Planet PHP, read more at the original (another 11123 bytes)

Categories: Open Source, PHP Community

/Dev/Hell Podcast: Episode 41: Let Me Wet My Beak

PHPDeveloper.org - Wed, 12/03/2014 - 20:14

The /Dev/Hell podcast, hosted by Chris Hartjes and Ed Finkler, has posted its latest episode - Episode 41: Let Me Wet My Beak. In this new episode they're joined by guest David Rogers.

This week we're joined by David Rogers, aka @al_the_x, to hear how he's teaching PHP in college courses for brand-new programers. We also talk about what possessed Ed to develop his own unit testing framework.

You can check out this episode either through the in-page player or by downloading the mp3 of the show. Also, be sure to subscribe to their feed if you like what you hear.

Link: http://devhell.info/post/2014-03-10/let-me-wet-my-beak/

Lorna Mitchell: Using Composer Without GitIgnoring Vendor/

PHPDeveloper.org - Wed, 12/03/2014 - 19:45

In her latest post Lorna Mitchell looks at a method, when using Composer and git, to fix an issue around subdirectories that are git repositories and git thinking they should be submodules instead.

Recent additions to the joind.in API have introduced some new dependencies so we decided we'd start using Composer to manage these - but we don't want to run composer unsupervised. I'm sure this will bring the rain of "just run composer install, it's probably mostly almost safe" criticism, but actually it's quite tricky to run Composer without excluding vendor/ from source control so I thought I'd share how we did it so that anyone who wants to do so can learn from my experience!

She starts by describing the usual use of Composer - making the "composer.json", running the install and see the "vendor" directory being added. When she tried to check in the dependencies, git gave her an error about wanting them to be submodules. Instead, she figured out a way to add a line to the .gitignore to have it disregard the "vendor/.git" directory, making it work as expected.

Link: http://www.lornajane.net/posts/2014/using-composer-without-gitignoring

Liip Blog: Of HHVM, Hack and the future of PHP

PHPDeveloper.org - Wed, 12/03/2014 - 18:09

Lukas Smith has posted some of his own thoughts on the Liip blog about the future of PHP, HHVM and Hack (related to this previous post from Anthony Ferrara) in the context of the company and the work they're doing.

I want to specifically comment on the part about HHVM and Hack. I have of course published my own opinion on the topic fairly recently on my private blog. Fellow Liiper Chregu has also done a very popular post on this very blog showing some very significant performance improvements that can be achieved with HHVM. [...] While Anthony does not recommend running HHVM in production, we are obviously getting ready to do just that. I totally agree however with the risks he points out.

He talks more about using HHVM in a production environment and some of the possible problems with it in the future (like maybe a change in it being incompatible with PHP someday). He also touches on the Hack language and how it is possible that Facebook's team will go wholly with Hack instead of PHP.

One of the big questions is why does Facebook even care about PHP mode if they are already moving their own code to Hack? To me one big reason for this could be that they actually want to use code produced in the community. [...] So maybe in the end the best way to ensure that PHP mode in HHVM remains a goal for Facebook is to keep churning out high quality PHP code? Link: http://blog.liip.ch/archive/2014/03/11/of-hhvm-hack-and-the-future-of-php.html

Understanding Drupal’s EntityFieldQuery

Planet-PHP - Wed, 12/03/2014 - 18:00

When building complex web apps, you’ll eventually have to interact with a database. To retrieve data in Drupal one can use the database abstraction layer provided, which requires some SQL knowledge to be used properly. From Drupal 7 EntityFieldQuery API is provided, which lets you fetch information about entities from Drupal without actually building SQL queries. In this article, let’s see how we can use the EntityFieldQuery API to fetch data from Drupal and use it in our modules.

Continue reading %Understanding Drupal’s EntityFieldQuery%

Categories: Open Source, PHP Community

The PHP.cc Blog: PHPUnit 4.0: Test Proxies

PHPDeveloper.org - Wed, 12/03/2014 - 17:13

On thePHP.cc blog today there's another post looking at an improvement in the latest release of the popular PHP unit testing tool, PHPUnit 4.0.0. In the post Sebastian Bergmann looks at test proxies.

One of the highlights of PHPUnit 4.0, which was released last week, is improved support for integration testing through so-called test proxies. [...] PHPUnit has had built-in support for stubs and mocks for quite some time. These stubs and mocks can be used in every context where an object of the original class is expected. As it should be, the code of the original class is not executed when a method is called on the stub or mock. [...] PHPUnit 4.0 introduces the concept of test proxies [...] to have an object that provides the same API for expectations as a mock object while at the same time proxying method calls to the original class.

He includes some code examples to help illustrate. He creates a "SimpleWorkflow" class and shows how to test the execution of its "doWork" function to return the correct kind of "Result".

Link: http://thephp.cc/viewpoints/blog/2014/03/phpunit-4-0-test-proxies

Voices of the ElePHPant: Interview #2 with Larry Garfield : Drupal 8 & Object Oriented Programming

PHPDeveloper.org - Wed, 12/03/2014 - 16:07

The Voices of the ElePHPant podcast has posted the second part of their interview with Larry Garfield (part one is here) talking about Drupal 8 and OOP.

Topics mentioned include the D8FTW blog post series, Refactor Chicago and the Chicago Advanced Drupal User Group.

You can listen to this latest episode either through the in-page player or by downloading the mp3 directly. You can also subscribe to their mailing list for this and more great shows.

Link: http://voicesoftheelephpant.com/2014/03/11/interview-2-with-larry-garfield-drupal-8-object-oriented-programming/

Why I Don't Recommend Scrypt

Planet-PHP - Wed, 12/03/2014 - 16:00
As many of you likely know, I have a "thing" for password storage. I don't know what it is about it, but it fascinates me. So I try to keep up as best as I can on the latest trends. In the past few years, we've seen the rise of a new algorithm called scrypt (it's 5 years old actually). It's gaining more and more adoption. But I don't recommend its use in production systems for password storage. Let me explain why:
Read more »
Categories: Open Source, PHP Community

The Security of Future PHP Versions - Lately in PHP podcast episode 45

Planet-PHP - Wed, 12/03/2014 - 13:52
By Manuel Lemos
As the plans for the upcoming PHP 5.6 and PHP 6 versions are being finalized, some of the proposals are about improving the security of these future PHP versions.

That has been one of the main topics discussed by Manuel Lemos and César Rodas on the episode 45 of the Lately in PHP podcast.

They also have talked about several other types of proposals and ideas for PHP 6, as well a tutorial on How to Use a Webcam to take Pictures in PHP Application.

Now listen to the podcast, or watch the hangout video or read the transcript text to learn more about these interesting PHP topics that were discussed.
Categories: Open Source, PHP Community

PHPUnit 4.0: Test Proxies

Planet-PHP - Wed, 12/03/2014 - 09:00
Categories: Open Source, PHP Community

Using Composer Without GitIgnoring Vendor/

Planet-PHP - Wed, 12/03/2014 - 00:25

Recent additions to the joind.in API have introduced some new dependencies so we decided we'd start using Composer to manage these - but we don't want to run composer unsupervised. I'm sure this will bring the rain of "just run composer install, it's probably mostly almost safe" criticism, but actually it's quite tricky to run Composer without excluding vendor/ from source control so I thought I'd share how we did it so that anyone who wants to do so can learn from my experience!

The Prescribed Method

Let's start with the usual method of using composer:

  1. Create composer.json to describe the dependencies
  2. Run composer update to find specific versions of those dependencies and write exact versions to composer.lock. Repeat this step if composer.json changes.
  3. Add the vendor directory to .gitignore, but add the composer.* files.
  4. Run composer install on all platforms (and do this again whenever composer.lock changes.

That's the basic composer pattern, and it works well. Most people should do it this way.

Checking Libraries into Git

There are a few reasons you might want to check your dependencies into source control yet still use composer, such as:

  • Either your users or your tools aren't ready to start using composer yet
  • Your live servers don't have internet access so dependencies need to be packaged with code
  • Running composer on live scares you because it's recently had some bad security press
  • You like composer for managing dependencies, or think it will become production-ready soon, but you're not running it on live yet - because you, your sysadmins or your IT director aren't ready

When I tried to just commit my vendor directory, some git submodule weirdness ensued, and in fact, the documentation does cover this:

Adding dependencies installed via git to a git repo will show them as submodules. This is problematic because they are not real submodules, and you will run into issues.

I did, indeed, run into issues.

The workaround (from the same docs) is to add a .gitignore line that removes all .git directories within your vendor directory. So add this line to the .gitignore file at the same level as composer.json and vendor/:

vendor/.git

Now when you install dependencies into composer (I found I had to git rm my entire vendor directory, commit, and then composer install again to clean up my earlier mistakes) you can safely add the vendor directory to the project and treat it as a library directory you had unzipped downloaded packages to. Apart from it's fabulous autoloader and easy-to-update format, that is :)

Lorna is an independent web development consultant, author and trainer, available for work (interesting projects only). This post was originally published at LornaJane

Categories: Open Source, PHP Community

Using Composer Without GitIgnoring Vendor/

Planet-PHP - Wed, 12/03/2014 - 00:25

Recent additions to the joind.in API have introduced some new dependencies so we decided we'd start using Composer to manage these - but we don't want to run composer unsupervised. I'm sure this will bring the rain of "just run composer install, it's probably mostly almost safe" criticism, but actually it's quite tricky to run Composer without excluding vendor/ from source control so I thought I'd share how we did it so that anyone who wants to do so can learn from my experience!

The Prescribed Method

Let's start with the usual method of using composer:

  1. Create composer.json to describe the dependencies
  2. Run composer update to find specific versions of those dependencies and write exact versions to composer.lock. Repeat this step if composer.json changes.
  3. Add the vendor directory to .gitignore, but add the composer.* files.
  4. Run composer install on all platforms (and do this again whenever composer.lock changes.

That's the basic composer pattern, and it works well. Most people should do it this way.

Checking Libraries into Git

There are a few reasons you might want to check your dependencies into source control yet still use composer, such as:

  • Either your users or your tools aren't ready to start using composer yet
  • Your live servers don't have internet access so dependencies need to be packaged with code
  • Running composer on live scares you because it's recently had some bad security press
  • You like composer for managing dependencies, or think it will become production-ready soon, but you're not running it on live yet - because you, your sysadmins or your IT director aren't ready

When I tried to just commit my vendor directory, some git submodule weirdness ensued, and in fact, the documentation does cover this:

Adding dependencies installed via git to a git repo will show them as submodules. This is problematic because they are not real submodules, and you will run into issues.

I did, indeed, run into issues.

The workaround (from the same docs) is to add a .gitignore line that removes all .git directories within your vendor directory. So add this line to the .gitignore file at the same level as composer.json and vendor/:

vendor/.git

Now when you install dependencies into composer (I found I had to git rm my entire vendor directory, commit, and then composer install again to clean up my earlier mistakes) you can safely add the vendor directory to the project and treat it as a library directory you had unzipped downloaded packages to. Apart from it's fabulous autoloader and easy-to-update format, that is :)

Lorna is an independent web development consultant, author and trainer, available for work (interesting projects only). This post was originally published at LornaJane

Categories: Open Source, PHP Community

How To Convert Include Files To Classes

Planet-PHP - Tue, 11/03/2014 - 21:35

When working with legacy applications, there are two major problems tied for first place in causing frustration, pain, and overtime: globals, and includes. I talk about how to remove globals in “It Was Like That When I Got Here”. But removing includes can be a much bigger challenge in many ways.

My new book, “Modernizing Legacy Applications in PHP”, has an entire chapter on how to convert includes to independently testable classes. The chapter describes how to do this in a way that does not break the existing legacy code.

As a gift to PHP developers suffering under legacy applications, I have made that chapter part of the sample text for the book. You can read it here.

Afterword

Are you overwhelmed by a legacy PHP application? Have you inherited a spaghetti mess of code? Does it use globals everywhere, so that a fix in one place causes a bug somewhere else? Does every feature addition feel like slogging through a swamp of includes?

It doesn’t have to be that way. “Modernizing Legacy Applications in PHP” gives you step-by-step instructions on how to get your legacy code under control by eliminating globals and separating concerns. Each chapter shows you exactly one task and how to accomplish it, along with common questions related to that task.

When you are done, you will come and go through your code like the wind. Your application will have become autoloaded, dependency injected, unit tested, layer separated, and front controlled. And you will have kept it running the whole time.

Buy the book today, or sign up for notifications on the mailing list below!

Sign up for Modernizing Legacy Applications in PHP:

First Name Email
Thank you, your sign-up request was successful! Please check your e-mail inbox.
That email address has been subscribed already, thank you!
Please provide a valid email address.
Oops. Something went wrong. Please try again later.
Categories: Open Source, PHP Community

Of HHVM, Hack and the future of PHP

Planet-PHP - Tue, 11/03/2014 - 20:31

Anthony posted a very interesting opinion piece about the future of PHP. I want to specifically comment on the part about HHVM and Hack. I have of course published my own opinion on the topic fairly recently on my private blog. Fellow Liiper Chregu has also done a very popular post on this very blog showing some very significant performance improvements that can be achieved with HHVM. Infact the project Chregu is working on is looking to be one of the first large production users of HHVM outside of Facebook and he is making good progress on integrating HHVM with New Relic which we use quite a bit for performance analysis in larger projects. Facebook is also presenting their point of view on PHP and Hack and probably the most promiment was this presentation called "Taking PHP Seriously". So with having set the stage let me address some of the points raised by Anthony.

HHVM in production

While Anthony does not recommend running HHVM in production, we are obviously getting ready to do just that. I totally agree however with the risks he points out. We realize that while the current version of HHVM is open source, there is no telling what will be the case with future versions and if they will eventually no longer be compatible with PHP or simply no longer open source. We have an extensive test suite to ensure that we get the expected behavior. Furthermore we have a failover system in place leveraging Varnish to ensure that we can simply go back to plain PHP and we make sure that our application meets the minimal performance requirements of our client with good old PHP. But for now we like the improved latency we are getting thanks to HHVM in a few more complex parts of the application. So far so good.

Hack, trouble in paradise

Now Hack is more than a mixed bag for me. Lots of the things in there are interesting. But it shows how impatient Facebook is with the core of PHP. Maintaining HHVM to have a PHP and a Hack mode is certainly a burden for Facebook's development and if indeed all their code will eventually target Hack, the question becomes if they will one day decide that PHP mode is no longer worth the hassle.

Now since HHVM is open source of course the open source community can then fork and continue the development. The longer HHVM remains committed to PHP compatibility, and infact right now Facebook is doing a lot to continously improve the compatibility, the higher the chances of enough people becoming invested in HHVM and therefore potentially willing to keep HHVM PHP mode going even if Facebook might loose interest.

Making Facebook care

One of the big questions is why does Facebook even care about PHP mode if they are already moving their own code to Hack? To me one big reason for this could be that they actually want to use code produced in the community. I have not really seen any Facebook engineers sending code to PHP libraries but maybe right now they are not being so obvious about this. Despite the fact that last I checked (about a year ago) their Facebook PHP SDK had some hideous code, I am sure that this would be quite exciting and I have no doubts that they have some excellent PHP programmers that could boost adopted libraries quite significantly.

So maybe in the end the best way to ensure that PHP mode in HHVM remains a goal for Facebook is to keep churing out high quality PHP code?

Categories: Open Source, PHP Community
Syndicate content