Subscribe: Planet PHP
http://www.planet-php.org/rss/
Added By: Feedage Forager Feedage Grade B rated
Language: English
Tags:
basic  closure  code  email  file  function  json  module  node  require  run tests  run  socket  test  tests  upload 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Planet PHP

Planet PHP



People blogging about PHP



 



Sockets with PHP and Node - Sarfraz Ahmed

Fri, 21 Jul 2017 21:19:00 +0000

I was looking to implement real time notifications system via sockets without having to use any third party services such as Pusher, etc. I just wanted to be able to send notifications from PHP side to the client and instantly show them on the web application similar to Facebook notifications. First I came across ratchet library, it worked great but problem emerged when setting it up on secure connection (https) on my host (siteground), tried apache proxy module and everything else told on the internet but to no avail (it seems siteground has problem with ratchet on https) so in the end I had to drop ratchet. Then I thought of using socket.io with Node+PHP and with my research I came across elephant.io library (though it isn't updated recently) and this one worked wonderfully well both on non-secure and secure protocols allowing us to send and receive messages from PHP with node-based server. Here are the steps that I followed to get my notification system working. Install elephant.io For your PHP application, install elephant.io via composer: composer require wisembly/elephant.io Install Node Dependencies Create a directory in your project root and under it create a file named package.json with these contents: { "name": "elephantIO_example_emitter", "version": "3.0.0", "main": "server", "scripts": { "start": "supervisor --debug server" }, "dependencies": { "socket.io": "~1", "winston": "*" } } On newly created directory run command npm install --save. This will install socket.io and logger library. In same newly created directory, create a file server with these contents: var server = require('http').createServer(), io = require('socket.io')(server), logger = require('winston'), port = 1337; // Logger config logger.remove(logger.transports.Console); logger.add(logger.transports.Console, { colorize: true, timestamp: true }); logger.info('SocketIO > listening on port ' + port); io.on('connection', function (socket){ var nb = 0; logger.info('SocketIO > Connected socket ' + socket.id); socket.on('broadcast', function (message) { ++nb; logger.info('ElephantIO broadcast > ' + JSON.stringify(message)); // send to all connected clients io.sockets.emit("broadcast", message); }); socket.on('disconnect', function () { logger.info('SocketIO : Received ' + nb + ' messages'); logger.info('SocketIO > Disconnected socket ' + socket.id); }); }); server.listen(port); Run server file through node by typing node server, you should see message that server has started on specified port. Client Side Put following javascript code in your application's page/footer: Sending Notification from PHP Here is how you can send a message to all connected clients: require __DIR__ . '/vendor/autoload.php'; use ElephantIO\Client; use ElephantIO\Engine\SocketIO\Version1X; $client = new Client(new Version1X('//127.0.0.1:1337')); $client->initialize(); // send message to connected clients $client->emit('broadcast', ['type' => 'notification', 'text' => 'Hello There!']); $client->close(); and that's all there is to it. Installing and Running Node on Production Site I was on CentOSv6 and I installed node by following this guide. Then I created simple php file that will be run by cron so that node server is automatically started/restarted if it is not running: $nodePath = 'your node binary path here'; $filePath = 'your server file path'; shell_exec($nodePath . ' ' . $filePath); and then specify that file in cron to run at your spec[...]



05: Finding untested code - Sammy Kaye Powers

Fri, 21 Jul 2017 19:15:53 +0000

width="560" height="315" src="https://www.youtube.com/embed/uFd2yM8HYdE" frameborder="0" allowfullscreen=""/> Now that we know how to create tests and debug them when they fail, let's make a useful test that actually covers some untested code. Finding untested lines of code The PHP gcov website shows what lines of C code are covered by the test suite. We took a long tangent to talk about the PHP_FUNCTION macro as well as the two ways Zend parse parameters (ZPP) works: with the zend_parse_parameters() function and the multi-line macro. Eventually we found some uncovered lines of code in ext/json/json.c for the json_decode() function that checked that value for the depth param was greater than 0. Creating a new test We made sure that we had the ext/json extension installed. $ sapi/cli/php -m | grep json We tried to create a new test. $ vi ext/json/tests/json_decode_error.phpt But quickly realized that there was already a test there so we created a new file variation. $ vi ext/json/tests/json_decode_error001.phpt Then we created our test. --TEST-- json_decode() - depth error --CREDITS-- Sammy Kaye Powers me at sammyk dot me # TestFest Chicago PHP UG 2017-07-18 --SKIPIF-- --FILE-- --EXPECTF-- Warning: json_decode(): Depth must be greater than zero in %s on line %d NULL We ran our test to see it pass with flying colors. $ make test TESTS=ext/json/tests/json_decode_error001.phpt At this point we could totally send our new test as a PR to the main php-src repo, but we wanted to see that this test actually covered the untested lines. Generating a code coverage report Since the PHP gcov website isn't updated regularly, we took Elizabeth Smith's advice and generated the code coverage reports locally. First we have to install lcov. $ sudo apt-get update $ sudo apt-get install lcov Then we can use the handy config.nice script to run configure again with all the previous flags in addition to any new ones. So we ran it with --enable-gcov since we already ran it with --enable-debug previously. $ ./config.nice --enable-gcov Next we had to delete all the previously compiled files with make clean so that everything could be recompiled with the appropriate flags that gcov needs. $ make clean && make Finally we werTruncated by Planet PHP, read more at the original (another 1941 bytes)[...]



[#3331208]: WordPress.com Skimlinks - Federico Cargnelutti

Fri, 21 Jul 2017 09:14:10 +0000

To reproduce this issue:

1) Open this page in “Incognito” mode
2) Refresh the page multiple times and observe how js converts “foo” to “foo}

import {assert} from 'chai';
import sinon from 'sinon';
import mockRequire from 'mock-require';

describe('My module', () => {

    let module; // module under test
    let configMock;

    beforeEach(() => {
        configMock = {
            init: sinon.stub().returns("foo")
        };

        // mock es6 import (tip: use the same import path)
        mockRequire("../../config", configMock);

        // require es6 module
        module = require("../../../app/services/content");
    });

    afterEach(() => {
        // remove all registered mocks
        mockRequire.stopAll();
    });

    describe('Initialisation', () => {

        it('should have an load function', () => {
            assert.isFunction(module.load);
        });

    });

});

Filed under: Programming (image) (image)



Iterators & Generators - Nomad PHP

Fri, 21 Jul 2017 04:01:47 +0000

October 2017 - EU
Presented By

Eli White
October 19, 2017
20:00 CEST

The post Iterators & Generators appeared first on Nomad PHP.




How to Write JavaScript-Style Test Watchers in PHP - SitePoint PHP

Thu, 20 Jul 2017 16:00:46 +0000

I didn't start out writing tests for my code. Like many before and since, my "testing" was to write code and refresh the page. "Does it look right?", I'd ask myself. If I thought so, I'd move on. In fact, most of the jobs I've had have been with companies who don't much care for other forms of testing. It's taken many years, and wise words from people like Chris Hartjes, for me to see the value in testing. And I'm still learning what good tests look like. I recently started working on a few JavaScript projects which had bundled test watchers. Here's a great premium video tutorial about test driven NodeJS development! In the land of JavaScript, it's not uncommon to preprocess source code. In the land of JavaScript, developers write in syntax not widely supported, and the code is transformed into syntax that is widely supported, usually using a tool called Babel. In order to reduce the burden of invoking the transformation scripts, boilerplate projects have started to include scripts to automatically watch for file changes; and thereafter invoke these scripts. These projects I've worked on have used a similar approach to re-run unit tests. When I change the JavaScript files, these files are transformed and the unit tests are re-run. This way, I can immediately see if I've broken anything. The code for this tutorial can be found on Github. I've tested it with PHP 7.1. Setting Up The Project Since starting to work on these projects, I've started to set a similar thing up for PHPUnit. In fact, the first project I set up the PHPUnit watcher script on was a PHP project that also preprocesses files. It all started after I added preprocessing scripts to my project: composer require pre/short-closures These particular preprocessing scripts allow me to rename PSR-4 autoloaded classes (from path/to/file.php ⇒ path/to/file.pre), to opt-in to the functionality they provide. So I added the following to my composer.json file: "autoload": { "psr-4": { "App\\": "src" } }, "autoload-dev": { "psr-4": { "App\\Tests\\": "tests" } } This is from composer.json I then added a class to generate functions with the details of the current user session: namespace App; use Closure; class Session { private $user; public function __construct(array $user) { $this->user = $user; } public function closureWithUser(Closure $closure) { return () => { $closure($this->user); }; } } This is from src/Session.pre To check if this works, I've set up a small example script: require_once __DIR__ . "/vendor/autoload.php"; $session = new App\Session(["id" => 1]); $closure = ($user) => { print "user: " . $user["id"] . PHP_EOL; }; $closureWithUser = $session->closureWithUser($closure); $closureWithUser(); This is from example.pre ...And because I want to use the short closures in a non-PSR-4 class, I also need to set up a loader: require_once __DIR__ . "/vendor/autoload.php"; Pre\Plugin\process(__DIR__ . "/example.pre"); This is from loader.php This is a lot of code to illustrate a small point. The Session class has a closureWithUser method, which accepts a closure and returns another. When called, this new closure will call the original closure, providing the user session array as an argument. To run all of this, type into terminal: php loader.php As a side-note, the valid PHP syntax that these preprocessors generated is lovely. It looks like this: $closure = function ($user) { print "user: " . $user["id"] . PHP_EOL; }; ...and public function closureWithUser(Closure $closure) { return [$closure Truncated by Planet PHP, read more at the original (another 3644 bytes)[...]



PHP 7.2.0 Beta 1 Released - PHP: Hypertext Preprocessor

Thu, 20 Jul 2017 00:00:00 +0000

The PHP development team announces the immediate availability of PHP 7.2.0 Beta 1. This release is the first beta for 7.2.0. All users of PHP are encouraged to test this version carefully, and report any bugs and incompatibilities in the bug tracking system. THIS IS A DEVELOPMENT PREVIEW - DO NOT USE IT IN PRODUCTION!PHP 7.2.0 Beta 1 builds on previous releases with:The much anticipated Sodium extensionOpcache improvementsCountable support for DOMNodeList and DOMNamedNodeMapImproved handling for invalid UTF8 in json_decode()And many bugfixes... For more information on the new features and other changes, you can read the NEWS file, or the UPGRADING file for a complete list of upgrading notes. These files can also be found in the release archive. For source downloads of PHP 7.2.0 Beta 1 please visit the download page, Windows sources and binaries can be found at windows.php.net/qa/. The second beta will be released on the 3rd of August. You can also read the full list of planned releases on our wiki. Thank you for helping us make PHP better.



Node: How to mock the imports of an ES6 module - Federico Cargnelutti

Tue, 18 Jul 2017 21:58:43 +0000

The package mock-require is useful if you want to mock require statements in Node. It has a simple API that allows you to mock anything, from a single exported function to a standard library. Here’s an example:

app/config

function init() {
    // ...
}

module.exports = init;

app/services/content

import config from '../../config';

function load() {
    // ...
}

module.exports = load;

test/services/content_spec

import {assert} from 'chai';
import sinon from 'sinon';
import mockRequire from 'mock-require';

describe('My module', () => {

    let module; // module under test
    let configMock;

    beforeEach(() => {
        configMock = {
            init: sinon.stub().returns("foo")
        };

        // mock es6 import (tip: use the same import path)
        mockRequire("../../config", configMock);

        // require es6 module
        module = require("../../../app/services/content");
    });

    afterEach(() => {
        // remove all registered mocks
        mockRequire.stopAll();
    });

    describe('Initialisation', () => {

        it('should have an load function', () => {
            assert.isFunction(module.load);
        });

    });

});

Filed under: Node, Programming (image) (image)



Domain Logic and Email Templates - Paul M. Jones

Tue, 18 Jul 2017 12:00:42 +0000

From an email conversation with a reader: Hi Paul, I’ve been following your writing and examples about the ADR pattern for some time now. It’s taken me awhile to wrap my head around it but ADR has really added a lot of structure to my code and I’m thankful for your work! One dilemma that I’ve been struggling with is how to organize emails that are sent out by my service classes. Currently my business logic dictates when to send an email and most of them contain html and text templates. It just feels wrong to include those email templates within the Domain. Do you have any recommendations? Any help you can provide would be greatly appreciated. In a somewhat related question – Recently I’ve been organizing my “views” folders within the folders of their parents (Http, Mail). I think I based it on your ADR example on github. Do you still prefer this method or do you lean towards organizing within a “resources” folder? My intuition is that you are right to keep the email templates out of the domain. In a way, sending an email as part of a web request/response cycle is like sending two responses: the normal HTTP response, and the email response. With that in mind, it might make sense to think of the html + Text email templates as part of a presentation layer. Or, as a combination of infrastructure (the email-sending client) plus presentation (the templates). That would be how to think about the separation of concerns there. Here’s an example of what that separation of concerns might look like in a package directory structure: resources/ templates/ web/ # web page templates email/ message-1/ message-1.html message-1.txt message-2/ message-2.html message-2.txt src/ Domain/ AppService/ FooAppService.php BarAppService.php EmailInterface.php # ... other domain classes Infrastructure/ DataSource/ # ... mappers, tables, etc Emailer.php # implements Domain\EmailInterface Web/ Foo/ FooAction.php FooResponder.php Bar/ BarAction.php BarResponder.php The specifics of directory structure are not important, as long as you see that the Emailer class is separated from the Domain application services (or use cases, or whatever). The Emailer class, for its part, might be a facade [1] that coordinates between a “real” emailer (e.g. Swiftmailer or PhpMailer) and a template class, to put together and then send the email. You could configure the Emailer class with the template location (resources/templates/email/*) and inject it into your application service (which depends on the EmailInterface). Now, sending emails inline as part of the web request might be fine in a lower-traffic situation. But as volume scales up, this kind of separation will make it easy to extract all email-sending to a workers. Then the Emailer can queue emails to the workers instead of sending them inline with the web request; the email-sending can become the job of a queue worker, and the template work will go there instead. As far as where to put templates for views: The extended example ADR code on GitHub is a few years old at this point. I still think it’s a reasonable setup, especially for people transitioning out of pseudo-MVC toward ADR, but it might do well to receive an update (or some examples of variations). I don’t prefer any particular method or structure on where to put templates. Sometimes it makes sense to keep templates near the things using them, sometimes it makes sense to collect them all one place. The needs of the system, and the prior experiences of the developer(s), will be the deciding factor as far as I’m concerned. I had PHP-PDS on the brain when I replied, s[...]



Why Developers Should Not Code - thePHP.cc

Tue, 18 Jul 2017 07:00:00 +0000




04: Debugging failed tests - Sammy Kaye Powers

Mon, 17 Jul 2017 17:26:52 +0000

width="560" height="315" src="https://www.youtube.com/embed/a9DacKvgCHs" frameborder="0" allowfullscreen=""/> So far we've learned how to create .phpt tests and run them with run-test.php. But what do we do when a test fails? Today we dig in and debug failed tests. Make a test fail We started by making our trusty echo_basic.phpt test fail by appending a smile emoticon to the end of the --EXPECT-- section and looked at each of the files that run-tests creates when a test fails. $ make test TESTS=echo_basic.phpt $ ls | grep echo echo_basic.diff echo_basic.exp echo_basic.log echo_basic.out echo_basic.php echo_basic.phpt echo_basic.sh .out The actual output that the PHP code from the --FILE-- section generated .exp The output we expected from the --EXPECT-- section .diff A diff file with the actual output compared to the expected output .log Both actual and expected output in one file .php The --FILE-- section as a PHP file .sh A bash script that runs the PHP file in the same environment that run-tests ran it (more on this later) Create a more complex example In order to see the power of the .sh file that gets generated, we created a more complicated test. $ vi upload_ini_basic.phpt --TEST-- upload_max_filesize basic test --INI-- upload_max_filesize=1337M --FILE-- --EXPECT-- Your max upload is 1337M If we run it through run-tests, it passes. $ make test TESTS=upload_ini_basic.phpt But when we run it as a plain-old PHP file, we see it outputs unexpected output in the --FILE-- section. $ sapi/cli/php upload_ini_basic.phpt --TEST-- upload_max_filesize basic test --INI-- upload_max_filesize=1337M --FILE-- Your max upload is 2M --EXPECT-- Your max upload is 1337M The --FILE-- part outputs "Your max upload is 2M" which is not what we want. So why did it pass in run-tests? Because we added the --INI-- section which run-tests will parse and set any ini settings for us. Seeing what run-tests sees Sometime it's handy to see what run-tests sees right in the console so we checked for output options using --help on run-tests. $ sapi/cli/php run-tests.php --help We saw that we could use the --show-all flag to output what run-tests sees straight to the console. But since we're running the tests through make, we didn't have a way to pass in the flag. So we looked at the Makefile and saw that the TESTS variable was just being appended to the end of the command that executes run-tests, so we just added the flag to the TESTS variable. $ make test TESTS="--show-all upload_ini_basic.phpt" Doing this we can see that run-tests clearly sees the expected, "Your max upload is 1337M" output in the PHP code. Running the test as run-tests ran it We made the test fail by appending another smile face at the end of the --EXPECT-- section and looked at the output files that run-tests generated. $ make test TESTS=upload_ini_basic.phpt $ ls | grep uploadTruncated by Planet PHP, read more at the original (another 4220 bytes)[...]