SitePoint PHPExploring the Webiny Framework: The StdLib Component (6.3.2015, 17:00 UTC)

There’s an adage about a developer’s career cycle:

  1. Doesn’t use frameworks
  2. Discovers frameworks
  3. Writes his own framework
  4. Doesn’t use frameworks

Point 4, of course, referring to the newfound ability to use Composer to build your own framework from various battle tested third party components.

We all know there’s no shortage of frameworks in the PHP ecosystem, so it surprised me quite a bit to see another pop up rather recently.

The framework is called Webiny, and, while packed to the brim with wheel reinventions they deem necessary, there are some genuinely interesting components in there that warrant taking a look. In this introductory tutorial, we won’t be focusing on the framework as a whole, but on the most basic of its components - the StdLib.

Continue reading %Exploring the Webiny Framework: The StdLib Component%

Link
Stefan KoopmanschapOn code reviews (6.3.2015, 11:50 UTC)

Recently we’ve had some discussion on the PHPNL Slack community about code reviews. It’s an interesting topic that I’ve been meaning to blog about for quite a while already (and I’ve written about it for Wisdom of the elePHPant), so this was a good reason to sit down and actually put down my thoughts on code reviewing.

So what is it?

Code reviewing is exactly what it sounds like: It is reviewing code written by another developer. There are different ways of doing this, but in the end it all comes down to having at least one other set of eyes checking any code written before it is released.

There’s many reasons for doing code reviews. It can be to prevent security issues, to ensure correct performance of your application, to prevent bugs but eventually it all comes down to the more generic term of ensuring the quality of your application.

How do you do code reviewing?

There’s many tools that will help you with code reviewing, and I can’t give you The Perfect Tool For The Job. What currently works well for many people is using the approach with Git where you send a pull request. Most Git-tools (such as Github and Stash) have excellent interfaces for going through the diff between a feature/bugfix branch and the main branch. They allow you to add comments with every line of code, so that the author of the code knows exactly what you’re commenting on and is able to fix the right code easily. Similar tools also exist for many of the other version control systems out there.

While tools can make your job easier, it is not necessary to use them. You can go through a diff when using your version control system from the commandline, or you can even go through the code together with the author of the code while sitting next to eachother (or while using screensharing with Skype/Hangout).

Preparing the review

As a developer I always make every change (feature, bugfix, improvement) in a seperate Git branch. The branch is pushed to my fork of the main repository, so once I’m done with my change I push the branch to my fork. I then create a pull request against the main repository. The PR description should contain useful information: A link to the (Jira) issue this is a PR for and possibly some generic information on what you’ve done in this specific PR and what choices or assumptions were made.

When the PR is created, I immediately review it myself. Reading a diff on Github or Stash is completely different from working in your IDE, is my experience. I look at my code in a different way and often I spot small bugs, forgotten changes or useless changes in this mode that I don’t when actually working on the code. I often also spot forgotten docblocks and such pretty quickly when reviewing my own code.

Doing the review

When I sit down to do a code review of code written by someone else I open up the pull request I’m about to review. I click the link to the Jira issue to check what the code is supposed to do and then start looking at the code. I focus on many things: Does this logic indeed implement the feature requested, but also: Does it follow the standards. I am known for nitpicking over docblocks, typehints and such.

Depending on the testing strategy in your organization, this is also the time to check if all code has accompanying (unit) tests, and whether they are actually good tests. Testing is a subject on its own of course, but it should be part of your review to check if the tests are there and good.

For everything I find, I place a comment. Even when there’s several places in a file or PR that have the same “issue”, I place a comment in each place. I’ve gotten some feedback that some people don’t like this and prefer “check this PR for x, there’s several places where this occurs”. This is a personal preference, but I prefer getting the comment in every place where it’s wrong, because when running through the feedback for a pull request it’s easier to know exactly what you should update where.

When commenting, pay attention to the way you write your comment. Code reviews are a check of the code, not the developer. Comments for that reason are not an attack on the person, but should be directed at the code. Explain why something is, according to you, not the right implementation, why you’re commenting, why you think it should change. Always keep in mind that there is a human being on the other side of the pull request that needs to handle the comments.

When code and/or documentation isn’t clear: Ask questions! You can ask the developer directly but you can also add a comment

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

Link
SitePoint PHPPopular Photos, Filters and User Profiles with the 500px API (4.3.2015, 17:00 UTC)

500px is a photo community for discovering, sharing, buying and selling inspiring photography. In this article we are going to explore their API and build a small showcase app. Let’s get started.

Logo

What We’re Building

In this article, we are going to build a small Laravel app with three main features. You can check the final result on Github.

  • The index page will contain the latest popular photos on the 500px website.
  • A filter will let the user choose from popular, upcoming, etc. and also sort the result according to votes, rating, etc.
  • A photographer’s profile page with the list of available photos will be available.

Setting up

Before using their API, we need to get some access credentials. After signing in to the website you can go to the application settings and register for a new test application. The consumer key and the consumer secret will be used for accessing the API.

We are going to use Guzzle to make HTTP requests, and Guzzle Oauth subscriber for using OAuth. If you are not familiar with these two, you can check out this Guzzle introduction and read about using Guzzle OAuth.

Let’s first add the Guzzle packages to our composer.json and autoload our src folder where we put our authentication class. Run composer update to update our app.

// composer.json
...
"require": {
      ...
      "guzzle/guzzle": "3.9.*",
      "guzzlehttp/oauth-subscriber": "0.2.*"
},
"autoload": {
    "classmap": [
        ...
            "app/src"
    ]
}
...

Inside our src/PxOAuth.php file we are going to provide our consumer_key and consumer_secret to build our OAuth object.

Continue reading %Popular Photos, Filters and User Profiles with the 500px API%

Link
Anna FilinaHow skiing made me a better developer (4.3.2015, 02:26 UTC)

I’m currently sitting at T-Bar & Grill in Panorama, British-Columbia, Canada. I had a great week of skiing and another week to come. While ripping the slopes at ear-popping speeds, my mind was surprisingly free to roam and explore ideas that lead me to this article. I’m going to tell you how skiing made me a better developer. You’d be amazed how much in common these two activities have. I picked up skiing 5 years ago. Since then, I made significant progress in programming and project management as well.

Decision-making

When you’re going at great speeds on ever-changing terrain, you must develop the ability to make quick decisions. You feel a patch of ice under your feet and your skis start to wobble, you see an exposed rock or tree stump ahead, an inexperienced skier is turning unpredictably below. You must decide your course of action in a second or risk injury. With enough practice, you can make a rational decision under extreme time pressure. I have noticed this translated into my programming and project-management abilities.

Looking far ahead

I take a lesson at least once a year to reinforce my technique. Usually twice. The first thing that my instructor told me was: “Look far ahead. You don’t need to contemplate the tips of your skis. You need to know what’s coming up and how to tackle it.” That’s what I do in programming. I don’t look at my current code or what’s trendy today. I look far ahead. As far as my foresight and experience will allow it. This is especially useful in project management and I became significantly better at it.

Overcoming obstacles

One false turn and you end up in the worst slope of your life. Just like today: I ended up in a steep one, with huge bumps with ice in between, rocks everywhere, branches sticking out and narrow passages. There was no way out of it, unless I wanted to venture into a dense conifer forest. You learn to not cry about your bad decisions, because you couldn’t have known it. You can’t undo the decision either. You follow through and overcome the obstacles. You can curse later at the bottom of the chairlift. When you’re in a bad situation, keeping yourself together and staying rational is key to avoid hurting yourself and getting off the mountain. Look at the obstacles ahead and plan your path. This brings me to my next point.

Planning

If you value your life, plan your path. Don’t charge and see what happens. I’ve heard enough people dying in avalanches because they ignored the warning signs and didn’t probe before going. Although planning is not a guarantee, skipping this step can be fatal to a project. Too many people jump into code without having any sort of planning: not a single diagram and not a single piece of documentation. I used to be much more hasty and arrogant, but now I never code without thorough planning.

Security

Being appropriately equipped and watching for warning signs is crucial to success. If you’re not dressed warmly enough, if you don’t wear a helmet, if you go out of bounds without avalanche gear, if you ignore the red & yellow signs, you’re taking risks. In programming, it taught me to take more measures to ensure that nothing goes wrong. It taught me to watch for the signs and calculate risks more carefully. This is especially important in project rescue, when you’re trying to mitigate risks and ship projects on time, despite being behind schedule and having plenty of other constraints.

Confidence

In skiing, if you don’t have confidence, you’ll stay a beginner all your life. You’ll be afraid to go fast, because you might fall and hurt yourself. To counter that, you must gear up properly, watch the experts, push your limits and practice a lot. In programming, confidence is what gives you momentum. I no longer second-guess every decision. I know I might make a few bad ones, but that doesn’t matter, because I know that I have the skill to pull myself together and get back on track. I also know that my ability to recognize a cliff from above will protect me, so I don’t worry all the time.

Rhythm & Endurance

I see some younger skiers give it all in their first run. They don’t save energy for later. They ride the mountain like it’s their last day on Earth. Also, many people ignore rhythm. That’s the thing that makes you turn as if to a beat. If you do it right, you’re effortlessly dancing on the slope. You can go on like that for a whole day and not be sore tomorrow. If you don’t have rhythm, you’ll be tired in an hour and will be more prone to falling, which will cause injury and put you out of commission for half a week or sometimes months. In programming, I used to push myself too hard. Now, I know better and pace myself. I became more productive and I almost never get tired from programming anymore.

Conclusion

You can find inspiration everywhere. Having many diverse hobbies will help you grow as a person and as a professional, so I suggest that you pick up as many as you can.

Link
Evert PotPSR-7 is imminent, and here's my issues with it. (4.3.2015, 02:22 UTC)

PSR-7 is pretty close to completion. PSR-7 is a new 'PHP standard recommendation', put out by the PHP-FIG group, of which I'm a member of.

It describes how to create PHP representations of a HTTP Request and a HTTP response. I think the potential impact of PSR-7 can be quite large. If large PHP framework authors are on board (and at least some of them are), it means that these interfaces might in the future be used indirectly or directly by an extremely large portion of the PHP community.

PSR-7 gets a lot of things right, and is very close to nailing the abstract data model behind HTTP, better than many other implementations in many programming languages.

But it's not perfect. I've been pretty vocal about a few issues I have with the approach. Most of this has fallen on deaf ears. I accept that I might be a minority in feeling these are problems, but I feel compelled to share my issues here anyway. Perhaps as a last attempt to sollicit change, or maybe just to get it off my chest.

If anything, it will allow me to say 'I told you so' when people start to using it and run into the edge cases that it doesn't cover well.

PSR-7 doesn't just represent a HTTP request and HTTP response in PHP, it tells you how to build your HTTP application.

Immutability

More recently in the process the decision has been made to make the objects immutable. This means that after the objects have been created, they are set in stone and cannot be changed.

In practice, this means instead of this:

<?php

$response->setHeader('X-Powered-By', 'Captain Planet');

?>

We need to do:

<?php

$response = $response->withHeader('X-Powered-By', 'Captain Planet');

?>

The difference is small in this isolated example, but the impact is massive.

One obvious issue is that for every change that you want to make to request or response objects, an entirely new instance needs to be created.

This bit of code creates a total of 4 copies of the request.

<?php

$request = $request
    ->withMethod('POST')
    ->withUrl(new Url('http://example.org/')
    ->withHeader('Content-Type', 'text/plain');

?>

The real impact in 'time spent' was proven to be quite low, so this part of the argument doesn't really bother me. Cloning objects is apparently pretty cheap in PHP.

What bothers me a bit more is that this is a pretty major departure of how we are used to using these objects. Most PHP frameworks will have some type of representation of the request and response object, and many APIs that use those objects. By forcing immutability, most of this APIs will have to change.

This decision has been made for sake of robustness. This apparently would "remove a whole class of bugs". Well, I believe the confusion that comes with an unusual API will definitely open the doors to a whole new class of bugs as well ;).

Silex

To give you an example of an API that is forced to change, here's an example from Silex. Silex has a set of events that allows a user to alter request and response objects:

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

Link
Brandon SavageIntroducing a new error handler for PHP projects (3.3.2015, 19:56 UTC)

Dealing with errors is one of the most frustrating and challenging parts of developing an application. Nobody likes to think about their application in a failure state, and there’s nothing more deflating than writing a bunch of great code, and getting a message that you forgot a semicolon on line 4. After trying a few […]

The post Introducing a new error handler for PHP projects appeared first on BrandonSavage.net.

Link
Pádraic BradySecurely Distributing PHARs: Pitfalls and Solutions (3.3.2015, 16:45 UTC)
Maximum Security (comics)

The PHAR ecosystem has become a separate distribution mechanism for PHP code, distinct from what we usually consider PHP packages via PEAR and Composer. However, they still suffer from all of the same problems, namely the persisting whiff of security weaknesses in how their distribution is designed.

What exactly can go wrong when distributing any sort of PHAR?

  • Downloading PHARs from a HTTP URL not protected by TLS.
  • Downloading PHARs from a HTTPS URL with TLS verification disabled.
  • Downloading PHARs which are unsigned by the authors.
  • Downloading any PHAR “installer” unnecessarily.

All of the above introduce an element of risk that the code you receive is not actually the code the author intended to distribute, i.e. it may decide to go do some crazy things that spell bad news when executed. A hacker could mount a Man-In-The-Middle attack on your connection to the PHAR server, or compromise the PHAR server and replace the file, or employ some DNS spoofing trickery to redirect download requests to their server.

I’ve started to distribute a CLI app phar of my own recently for Humbug, so I had to go and solve these problems and make installing, and updating, that phar both simple and secure. Here’s the outline of the solution I’ve arrived at which is quite self-evident.

  • Distribute the PHAR over HTTPS
  • Enforce TLS Verification
  • Sign your PHAR with a private key
  • Avoid PHAR Installer scripts
  • Manage Self Updates Securely
  • Do all of this consistently

Some details and a discussion on each point…

Distribute the PHAR over HTTPS

If you really don’t already have a TLS enabled download location, you can avail yourself of Github.io which supports HTTPS URLs. I’m using this for Humbug‘s development builds. You can also use Github Releases for your project and attach the phars there for new versions. If you do need to host the PHAR on your own server, get a TLS certificate for your domain.

Enforce TLS verification

PHP supports TLS verification out of the box, for the most part. It was disabled by default until PHP 5.6. Enforce it! If a user cannot make a simple request to a simple HTTPS URL, then their server is quite obviously misconfigured. That is not your problem, so don’t make it your problem. You use HTTPS, you enforce TLS, and other programmers should be more than capable of fixing their own stuff. Insecure broken systems are not the lowest common denominate you should be targeting.

Enabling TLS verification for PHP’s stream functions, e.g. file_get_contents(), is basically a disaster waiting to happen because its configuration can be fairly long winded to get just right. As something of a shim, I’ve created the humbug_file_contents package which has a ready to roll TLS-loving function that can replace file_get_contents() transparently, but only when it detects a PHP version less than 5.6.

PHP 5.6 introduced significant TLS improvements which were enabled by default. In certain areas, it actually exceeds what might be expected from other options, and it’s certainly better than any combination of pre-5.6 options can currently achieve

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

Link
Brandon SavageThe conference talk creation process (3.3.2015, 13:04 UTC)

There’s been a lot made in the last 24 hours about the process of submitting and accepting conference talks, including whether or not such talks should be written beforehand. There are many valid points of view on the issue, and here are a few of my thoughts. When it comes to creating conference talks, I […]

The post The conference talk creation process appeared first on BrandonSavage.net.

Link
Derick RethansXdebug 2.3: Enhanced xdebug_debug_zval() (3.3.2015, 09:44 UTC)

Xdebug 2.3: Enhanced xdebug_debug_zval()

This is the second article in a series about new features in Xdebug 2.3, which was first released on February 22nd.

xdebug_debug_zval() has been around for quite some time, to provide correct information about how PHP internally stores a variable. Unlike PHP's built in debug_zval_dump() function, it does not modify the variable information that it tries to show. This is because instead of passing in a variable, you pass in its name. Passing a variable into a function, can modify the various parameters that are associated with this variable, such as the is_ref and refcount fields.

xdebug_debug_zval() does not suffer from these inadvertent modifications, as you pass in the variable's name, and the function looks up the information about a variable in the symbol tables itself.

The difference becomes clear with the following two examples. With debug_zval_dump():

<?php
$a = array(1, 2, 3);
$b =& $a;
$c =& $a[2];

debug_zval_dump($a);
?>

Which outputs (after a little formatting):

array(3) refcount(1){
        [0]=> long(1) refcount(2)
        [1]=> long(2) refcount(2)
        [2]=> &long(3) refcount(3)
}

And with xdebug_debug_zval():

<?php
$a = array(1, 2, 3);
$b =& $a;
$c =& $a[2];

xdebug_debug_zval('a');
?>

Which outputs (after a little formatting):

a: (refcount=2, is_ref=1)=array (
        0 => (refcount=1, is_ref=0)=1,
        1 => (refcount=1, is_ref=0)=2,
        2 => (refcount=2, is_ref=1)=3
)

In the debug_zval_dump() example, the refcounts for the array elements are all one too high, and the refcount for the array itself is one too low. The array is also not marked as reference.

However, before Xdebug 2.3, the xdebug_debug_zval() function would only accept a variable name, but not any array subscripts or property deferences. Meaning that you couldn't really dump a sub array. Xdebug 2.3 adds support for dereferencing properties and array elements by reusing the variable name parser of the remote debugging. Hence, you can now do the following:

<?php
$a = array(1, 2, 3);
$b =& $a;
$c =& $a[2];

xdebug_debug_zval('a[2]');
?>

Which outputs:

a[2]: (refcount=2, is_ref=1)=3

Or:

<?php
$a = new StdClass;
$a->prop = [3.14, 2.72];

xdebug_debug_zval('a->prop');
xdebug_debug_zval('a->prop[1]');
?>

Which outputs:

a->prop: (refcount=1, is_ref=0)=array (
        0 => (refcount=1, is_ref=0)=3.14,
        1 => (refcount=1, is_ref=0)=2.72
)
a->prop[1]: (refcount=1, is_ref=0)=2.72


Other parts in this series:

Link
Cal EvansInterview with Morgan Tocker (3.3.2015, 06:00 UTC)

Twitter:
Morgan Tocker @morgo

Show Notes

The post Interview with Morgan Tocker appeared first on Voices of the ElePHPant.

Link
LinksRSS 0.92   RDF 1.
Atom Feed   100% Popoon
PHP5 powered   PEAR
ButtonsPlanet PHP   Planet PHP
Planet PHP