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

Hack Blog:
Async - Cooperative Multitasking for Hack
December 08, 2014 @ 11:56:54

On the Hack blog there's a new post talking about async, a feature in Hack that allows for code to "cooperatively multitask". This gives the language a way to keep moving on in the execution without having to wait for things like database queries or remote file fetches to finish.

This is somewhat similar to threading, in that multiple code paths are executed in parallel, however it avoids the lock contention issues common to multithreaded code by only actually executing one section at any given moment. "What's the use of that?", I hear you ask. You're still bound to one CPU, so it should take the same amount of time to execute your code, right? Well, that's technically true, but script code execution isn't the only thing causing latency in your application. The biggest piece of it probably comes from waiting for backend databases to respond to queries.

She gives the example of pulling in a remote file (HTTPS, where there's a bit more latency) and how to use async, await, WaitHandle, and Awaitable to work around the timing issue. She shows how to make a method asynchronous and how to join the results of the operation back up with the rest of the script. This includes the use of various "handles" including RescheduleWaitHandle, SleepWaitHandle and the AwaitAllWaitHandle. She shows the integration of a custom cURL handler that makes use of this processing, marked async, to multithread the requests to the remote server(s).

0 comments voice your opinion now!
hack async asynchronous multitasking curl example remote fetch language

Link: http://hhvm.com/blog/7091/async-cooperative-multitasking-for-hack

Loosely Coupled Podcast:
Episode 14 The Not-So-Secret Life of Remote Developers
December 01, 2014 @ 09:14:55

The Loosely Coupled Podcast, hosted by PHP community members Jeff Carouth and Matt Frost, has posted their latest episode: Episode 14: The Not-So-Secret Life of Remote Developers.

In this episode, Jeff and Matt talk about some things they have learned about being remote developers. While both are currently employed as remote developers they have also worked in on-site jobs. This episode is a collection of things that might be different, things to expect, things that might be hard, and, of course, whether you need to wear pants.

You can listen to this latest episode either through the in-page player or by downloading the mp3 directly. If you enjoy the topics and the show be sure you subscribe to their feed to get the latest as they're released.

0 comments voice your opinion now!
looselycoupled podcast ep14 notsosecret life remote developer podcast

Link: http://looselycoupled.info/blog/2014/11/30/episode-14-the-not-so-secret-life-of-remote-developers/

SitePoint PHP Blog:
Debugging with Xdebug and Sublime Text 3
February 28, 2014 @ 11:10:53

The latest post from the SitePoint PHP blog, a new tutorial by Peter Nijssen, shows you how to get started with Xdebug and Sublime Text 3 to debug your PHP applications.

Debugging - we all do it a lot. Writing code perfectly the first time around is hard and only a few (if any) succeed at it. More than a year ago, Shameer wrote an article on SitePoint about how you can debug your application using Xdebug and Netbeans. In this article, we are going to have a look at how we can debug using Xdebug in combination with Sublime Text.

He assumes you already have Xdebug installed (and links to the instructions for those that don't) and helps you configure it to find your listening editor. Back in Sublime, he shows you how to use the package manager to install the Xdebug client and configure the current project to use it. He shows how to set up breakpoints and view the stack/watch data when the point is hit.

0 comments voice your opinion now!
debug xdebug sublimetext remote tutorial package client

Link: http://www.sitepoint.com/debugging-xdebug-sublime-text-3/

Dutch Web Alliance:
The definitive remote debug and unittest with PHPStorm guide part 7
January 29, 2014 @ 10:54:25

The Dutch Web Alliance has posted the seventh part of their series looking at getting remote debugging and unit testing working with PHPStorm, a popular PHP IDE. You can start at the beginning or just find the links to any other articles in the series you might have missed in the first post.

So, your unit-tests should be small, not doing much, taking one unit at a time to test. Overall, not much is around to actually debug. But on occasion, having the ability to actually stepping through the unit-tests can save you a headache or two! Debugging your PHPUnit scripts isn't really that hard. In fact, most of what we need to do, we already covered in the previous postings! Consider this: PHPUnit is nothing more than a PHP framework running from the command line interface. And since we already know how to debug applications from the CLI, it must be easy!

This is the last post in the series and is pretty short. It basically talks about setting breakpoints in testing and letting PHPStorm catch the issues. If you'd rather run them from the command line, check out part six for more details.

0 comments voice your opinion now!
debugging unittest remote phpstorm tutorial series part6

Link: https://dutchweballiance.nl/techblog/the-definitive-remote-debug-and-unittest-with-phpstorm-guide-part-7/

Dutch Web Alliance:
The definitive remote debug and unittest with PHPStorm guide part 5
December 24, 2013 @ 13:09:05

The Dutch Web Alliance has posted the fifth part (of seven) of their series looking at configuring the PHPStorm IDE to remotely debug and run your unit tests. In this article they focus in on getting coverage information from the tests and generating the reports.

They walk you through all of the terminology and configuration you'll need to get things working. They include an example of a Closer coverage configuration file (XML) to push the results out where PHPStorm can grab them. They show show the result (screenshot) of the coverage results being shown inside the IDE.

This is part five of the series, so if you'd like to get caught up check out the full table of contents for links to all of the posts so far.

0 comments voice your opinion now!
remote debug unittest code coverage clover report series tutorial

Link: http://dutchweballiance.nl/techblog/the-definitive-remote-debug-and-unittest-with-phpstorm-guide-part-5-2/

Dutch Web Alliance:
The definitive remote debug and unittest with PHPStorm guide part 4
December 20, 2013 @ 09:52:28

The Dutch Web Alliance has posted the fourth part of their series looking at remote debugging with PHPStorm. If you want to start from the beginning, you can find the first part of the series here (along with a table of contents for the other parts).

Unit testing should play a pretty big part in your daily PHP work. With the help of PHPUnit, writing and executing those tests is fairly simple. But in a remote environment we run into some issues which we try to solve in this blogpost. I'm not going to tell you the basics of unit-testing, as we assume you already are familiar with this. If not, There are lots of blog posts on this subject.

With some tests already in place, they show you how to get PHPStorm all set up and working. First they talk some about how the IDE makes its connection to the remote server via a "proxy" script. There's a few problems with this method, so they show a different approach using the "PHP on Server" configuration setting. They walk you through the setup of this feature (with screenshots) and how to "trick" it using a dummy phpunit.xml file.

0 comments voice your opinion now!
unittest phpstorm series remote debug guide part4

Link: http://dutchweballiance.nl/techblog/the-definitive-remote-debug-and-unittest-with-phpstorm-guide-part-4/

Dutch Web Alliance:
The definitive remote debug and unittest with PHPStorm guide part 3
December 11, 2013 @ 09:19:23

The Dutch Web Alliance has posted the latest part in their "remote debugging with PHPStorm" series (parts one & two are linked here) with part three. This time they focus on setting up Xdebug and configuring the connection in the IDE.

Let's start with probably the most important part of all: debugging your web applications. In this day and age, people still use var_dump() and die() to debug their application. A shame really, knowing that step-debugging through your code is made really easy with PHPStorm. Using var_dump() is very slow, error prone and you only get a small fraction of the context you need in order to debug correctly. And how many times did such a var_dump() hit your production environment?? Truth be told, implementing XDebug does need a little bit of work, but fortunately PHPStorm has made things super easy for us.

They don't go through the whole installation part of Xdebug - there's other guides for that - but do help you configure it correctly to work with a remote debugger in PHPStorm. They show you how to set various breakpoints and a "trick" to working with path mappings.

0 comments voice your opinion now!
phpstorm remote debugging unittest tutorial series part3

Link: http://dutchweballiance.nl/techblog/the-definitive-remote-debug-and-unittest-with-phpstorm-guide-part-3/

Dutch Web Alliance:
The definitive remote debug and unittest with PHPStorm guide
December 06, 2013 @ 11:48:38

On the Dutch Web Alliance site today they've kicked off a new series of posts looking to help you get the most out of the PHPStorm IDE for remote PHP debugging and unit testing your application.

PHPStorm is probably the best IDE when it comes to PHP development. [...] This multi-part guide will try and set up your systems in such a way that EVERYTHING you need to do when it comes to development gets explained so you can set your system up correctly, once and for all. Meet the "definitive remote debugging and unittest with PHPStorm guide". Even though PHPStorm always had many different ways of editing, syncing and deploying your scripts, it was not until PHPStorm 7 that we finally have an IDE that can work fully on a virtualized remote system. In the next couple of blog posts I will try and give you a tour on how to set up your systems so they actually work.

So far they've posted the first two parts of the series:

Keep tuned in to this post (or their feed) for updates to the series and new articles as they're posted.

0 comments voice your opinion now!
remote debugging unittest phpunit phpstorm guide series

Link: http://dutchweballiance.nl/techblog/the-definitive-remote-debug-and-unittest-with-phpstorm-guide/

Gonzalo Ayuso:
Playing with event dispatcher and Silex. Sending logs to a remote server.
October 22, 2013 @ 09:44:57

Gonzalo Ayuso as a new post today showing the results of some of his testing with the event dispatcher and Silex to send logs to a remote server.

Today I continue playing with event dispatcher and Silex. Now I want to send a detailed log of our Kernel events to a remote server. We can do it something similar with Monolog, but I want to implement one working example hacking a little bit the event dispatcher. Basically we're going to create one Logger class (implementing PSR-3 of course).

He includes the sample code defining a "Logger" class that takes whatever message sent to it and pushes it into a given socket resource. He also creates a provider for the logger to implement it in the example and registers it with the event dispatcher. He hooks it into the request, get controller, terminate and exception events. On the other side he uses React to make a basic server to listen on port 4000 for the incoming log data.

0 comments voice your opinion now!
silex event dispatcher remote server log logger psr3

Link: http://gonzalo123.com/2013/10/21/playing-with-event-dispatcher-and-silex-sending-logs-to-a-remote-server/

Reddit.com:
Composer still susceptible to remote code execution via MITM
October 03, 2013 @ 11:26:15

In this recent post to Reddit.com, a point is brought up about the popular PHP package manager, Composer about it being susceptible to a common attack called the "Man in the Middle". This issue on the project's Github repository talks more about it:

Composer runs code from HTTP sources without validating the source of the download or the code downloaded. As such, trivial man-in-the-middle attacks through any number of vectors (dns, networking, local server exploit, etc) will result in execution of code of an attackers choosing at the userlevel of the user running composer. (Typically a developer account)

Replace getcomposer.org for a given network perspective by replacing it with a malicious http instance (eg by changing the DNS locally, at the lan, at an isp or hosting provider dns resolver, or globally or equally easily by replacing a route to the legitimate server (eg arpspoof)) . The http server instance is configured to serve a malicious /composer.phar and a /version url that produces random data. When users run self-update, the malicious code will be downloaded and run as the user that is executing the self-update command.

As of yet some patches and ideas have been proposed to correct this issue, but it hasn't been resolved and is currently listed as a "blocker" on the project. One suggestion, signing packages, seems to be the front-runner in the current discussion, something that package managers for other languages have already implemented (like npm for Node.js and pip for Python).

0 comments voice your opinion now!
composer package manager remote code execution attack maninthemiddle mitm

Link: http://www.reddit.com/r/PHP/comments/1nkmw8/composer_still_susceptible_to_remote_code/


Community Events





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


interview podcast introduction security framework laravel release version community voicesoftheelephpant series composer artisanfiles conference library list tool opinion language symfony

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