Extensions – SitePointhttps://www.sitepoint.com
Learn CSS | HTML5 | JavaScript | Wordpress | Tutorials-Web Development | Reference | Books and MoreFri, 16 Feb 2018 19:00:05 +0000en-UShourly1https://wordpress.org/?v=4.8.1Procedurally Generated Game Terrain with React, PHP, and WebSocketshttps://www.sitepoint.com/procedurally-generated-game-terrain-reactjs-php-websockets/
https://www.sitepoint.com/procedurally-generated-game-terrain-reactjs-php-websockets/#commentsThu, 14 Sep 2017 17:00:01 +0000https://www.sitepoint.com/?p=151409Last time, I began telling you the story of how I wanted to make a game. I described how I set up the async PHP server, the Laravel Mix build chain, the React front end, and WebSockets connecting all this together. Now, let me tell you about what happened when I starting building the game mechanics with this mix of React, PHP, and WebSockets…

I noticed how similar this GameSocket was to the previous one I had --- except, instead of broadcasting an echo, I was checking for new-farm and sending a message back only to the client that had asked.

"Perhaps it's a good time to get less generic with the React code. I'm going to rename component.jsx to farm.jsx."

It was far from where I needed to be, but using these changes I could see the class accessors in action, as well as prototype a kind of request/response pattern for future WebSocket interactions. I opened the console, and saw {"farm":{"width":10,"height":10}}.

"Great!"

Then I created a Patch class to represent each tile. I figured this was where a lot of the game's logic would happen. From app/Model/PatchModel.pre:

For each cell, I created a new PatchModel object. These were pretty simple to begin with, but they needed an element of randomness --- a way to grow trees, weeds, flowers … at least to begin with. From app/Model/PatchModel.pre:

I thought I'd begin just by randomly growing a patch. This didn't change the external state of the patch, but it did give me a way to test how they were started by the farm. From app/Model/FarmModel.pre:

There was a lot going on here. For starters, I introduced an async function keyword using a macro. You see, Amp handles the yield keyword by resolving Promises. More to the point: when Amp sees the yield keyword, it assumes what is being yielded is a Coroutine (in most cases).

I could have made the createPatches function a normal function, and just returned a Coroutine from it, but that was such a common piece of code that I might as well have created a special macro for it. At the same time, I could replace code I had made in the previous part. From helpers.pre:

I began the createPatches method as before, creating new PatchModel objects for each x and y in the grid. Then I started another loop, to call the start method on each patch. I would have done these in the same step, but I wanted my start method to be able to inspect the surrounding patches. That meant I would have to create all of them first, before working out which patches were around each other.

I also changed FarmModel to accept an onGrowth closure. The idea was that I could call that closure if a patch grew (even during the bootstrapping phase).

Each time a patch grew, I reset the $changes variable. This ensured the patches would keep growing until an entire pass of the farm yielded no changes. I also invoked the onGrowth closure. I wanted to allow onGrowth to be a normal closure, or even to return a Coroutine. That's why I needed to make createPatches an async function.

Note: Admittedly, allowing onGrowth coroutines complicated things a bit, but I saw it as essential for allowing other async actions when a patch grew. Perhaps later I'd want to send a socket message, and I could only do that if yield worked inside onGrowth. I could only yield onGrowth if createPatches was an async function. And because createPatches was an async function, I would need to yield it inside GameSocket.

"It's easy to get turned off by all the things that need learning when making one's first async PHP application. Don't give up too soon!"

The last bit of code I needed to write to check that this was all working was in GameSocket. From app/Socket/GameSocket.pre:

This was only slightly more complex than the previous code I had. I needed to provide a third parameter to the FarmModel constructor, and yield $farm->createPatches() so that each could have a chance to randomize. After that, I just needed to pass a snapshot of the patches to the socket payload.

Random patches for each farm

"What if I start each patch as dry dirt? Then I could make some patches have weeds, and others have trees …"

I changed the order of logic around a bit, exiting early if the patch had already been started. I also reduced the chance of growth. If neither of these early exits happened, the patch type would be changed to weed.

I could then use this type as part of the socket message payload. From app/Socket/GameSocket.pre:

]]>https://www.sitepoint.com/procedurally-generated-game-terrain-reactjs-php-websockets/feed/1Game Development with React and PHP: How Compatible Are They?https://www.sitepoint.com/game-development-with-reactjs-and-php-how-compatible-are-they/
https://www.sitepoint.com/game-development-with-reactjs-and-php-how-compatible-are-they/#commentsWed, 13 Sep 2017 17:00:53 +0000https://www.sitepoint.com/?p=151400"I'd like to make a multiplayer, economy-based game. Something like Stardew Valley, but with none of the befriending aspects and a player-based economy."

I started thinking about this the moment I decided to try and build a game using PHP and React. The trouble is, I knew nothing about the dynamics of multiplayer games, or how to think about and implement player-based economies.

I wasn't even sure I knew enough about React to justify using it. I mean, the initial interface --- where I focus heavily on the server and economic aspects of the game --- is perfectly suited for React. But what about when I start to make the farming /interaction aspects? I love the idea of building an isometric interface around the economic system.

I once watched a talk by dead_lugosi, where she described building a medieval game in PHP. Margaret inspired me, and that talk was one of the things that led to me writing a book about JS game development. I became determined to write about my experience. Perhaps others could learn from my mistakes in this case, too.

Setting Up the Back End

The first thing I searched for was guidance on building multiplayer economies. I found an excellent Stack Overflow thread in which folks explained various things to think about. I got about halfway through it before realizing I may have been starting from the wrong place.

"First things first: I need a PHP server. I'm going to have a bunch of React clients, so I want something capable of high-concurrency (perhaps even WebSockets). And it needs to be persistent: things must happen even when players aren't around."

I went to work setting up an async PHP server --- to handle high concurrency and support WebSockets. I added my recent work with PHP preprocessors to make things cleaner, and made the first couple of endpoints.

I wanted to use amphp/parallel, to move blocking code out of the async server, but it wouldn't install with a stable tag of amphp/aerys. That's why I went with the dev-amp_v2 branch.

I thought it would be a good idea to include some sort of template engine and service locator. I opted for PHP League versions of each. Finally I added pre/short-closures, both to handle the custom syntax in config.pre and the short closures I planned on using after…

Though simple routes, these helped me to test the code in config.pre. I decided to make these routes files return closures, so I could pass them a typed $router, to which they could add their own routes. Finally, I created two (similar) actions.

]]>https://www.sitepoint.com/game-development-with-reactjs-and-php-how-compatible-are-they/feed/6ReactJS in PHP: Writing Compilers Is Easy and Fun!https://www.sitepoint.com/reactjs-php-writing-compilers-easy-fun/
https://www.sitepoint.com/reactjs-php-writing-compilers-easy-fun/#respondFri, 25 Aug 2017 16:00:07 +0000https://www.sitepoint.com/?p=158825I used to use an extension called XHP. It enables HTML-in-PHP syntax for generating front-end markup. I reached for it recently, and was surprised to find that it was no longer officially supported for modern PHP versions.

So, I decided to implement a user-land version of it, using a basic state-machine compiler. It seemed like it would be a fun project to do with you!

Creating Compilers

Many developers avoid writing their own compilers or interpreters, thinking that the topic is too complex or difficult to explore properly. I used to feel like that too. Compilers can be difficult to make well, and the topic can be incredibly complex and difficult. But, that doesn’t mean you can’t make a compiler.

Making a compiler is like making a sandwich. Anyone can get the ingredients and put it together. You can make a sandwich. You can also go to chef school and learn how to make the best damn sandwich the world has ever seen. You can study the art of sandwich making for years, and people can talk about your sandwiches in other lands. You’re not going to let the breadth and complexity of sandwich-making prevent you from making your first sandwich, are you?

Compilers (and interpreters) begin with humble string manipulation and temporary variables. When they’re sufficiently popular (or sufficiently slow) then the experts can step in; to replace the string manipulation and temporary variables with unicorn tears and cynicism.

At a fundamental level, compilers take a string of code and run it through a couple of steps:

The code is split into tokens – meaningful characters and sub-strings – which the compiler will use to derive meaning. The statement if (isEmergency) alert("there is an emergency") could be considered to contain tokens like if, isEmergency, alert, and "there is an emergency"; and these all mean something to the compiler.

The first step is to split the entire source code up into these meaningful bits, so that the compiler can start to organize them in a logical hierarchy, so it knows what to do with the code.

The tokens are arranged into the logical hierarchy (sometimes called an Abstract Syntax Tree) which represents what needs to be done in the program. The previous statement could be understood as “Work out if the condition (isEmergency) evaluates to true. If it does, run the function (alert) with the parameter ("there is an emergency")”.

Using this hierarchy, the code can be immediately executed (in the case of an interpreter or virtual machine) or translated into other languages (in the case of languages like CoffeeScript and TypeScript, which are both compile-to-Javascript languages).

In our case, we want to maintain most of the PHP syntax, but we also want to add our own little bit of syntax on top. We could create a whole new interpreter…or we could preprocess the new syntax, compiling it to syntactically valid PHP code.

I’ve written about preprocessing PHP before, and it’s my favorite approach to adding new syntax. In this case, we need to write a more complex script; so we’re going to deviate from how we’ve previously added new syntax.

Generating Tokens

Let’s create a function to split code into tokens. It begins like this:

We’re off to a good start. By stepping through the code, we can check to see what each character is (and identify the ones that matter to us). We’re seeing, for instance, that the first element opens when we encounter a < character, at index 5. The first element closes at index 210.

Unfortunately, that first opening is being incorrectly matched to <?php. That’s not an element in our new syntax, so we have to stop the code from picking it out:

As with JSX, it would be good for attributes to allow dynamic values (even if those values are nested JSX elements). There are a few ways we could do this, but the one I prefer is to treat all attributes as text, and tokenize them recursively. To do this, we need to have a kind of state machine which tracks how many levels deep we are in an element and attribute. If we’re inside an element tag, we should trap the top level {…} as a string attribute value, and ignore subsequent braces. Similarly, if we’re inside an attribute, we should ignore nested element opening and closing sequences:

We’ve added new $attributeLevel, $attributeStarted, and $attributeEnded variables; to track how deep we are in the nesting of attributes, and where the top-level starts and ends. Specifically, if we’re at the top level when an attribute’s value starts or ends, we capture the current cursor position. Later, we’ll use this to extract the string attribute value and replace it with a placeholder.

We’re also starting to capture $elementStarted and $elementEnded (with $elementLevel fulfilling a similar role to $attributeLevel) so that we can capture a full element opening or closing tag. In this case, $elementEnded doesn’t refer to the closing tag but rather the closing sequence of characters of the opening tag. Closing tags are treated as entirely separate tokens…

After extracting a small substring after the current cursor position, we can see elements and attributes starting and ending exactly where we expect. The nested control structures and elements are captured as strings, leaving only the top-level elements, non-attribute nested elements, and attribute values.

Let’s package these tokens up, associating attributes with the tags in which they are defined:

There’s a lot going on here, but it’s all just a natural progression from the previous version. We use the captured attribute start and end positions to extract the entire attribute value as one big string. We then replace each captured attribute with a numeric placeholder and reset the code string and cursor positions.

As each element closes, we associate all the attributes since the element was opened, and create a separate array token from the tag (with its placeholders), attributes and starting position. The result may be a little harder to read, but it is spot on in terms of capturing the intent of the code.

]]>https://www.sitepoint.com/reactjs-php-writing-compilers-easy-fun/feed/0There’s a Gender Extension for PHPhttps://www.sitepoint.com/theres-a-gender-extension-for-php/
https://www.sitepoint.com/theres-a-gender-extension-for-php/#commentsMon, 26 Jun 2017 16:00:56 +0000https://www.sitepoint.com/?p=155975Unlike in our "mainstream" paid course about exploring PHP, I like to explore the weird and forgotten areas of the language.

Recently, I ventured into a section of the PHP manual which lists extensions that are used to help with Human Language and Character Encoding. I had never looked at them as a whole - while dealing with gettext, for example, I always kind of landed directly on it and ignored the rest. Well, of those others, there's one that caught my eye - especially in this day and age given the various controversies - the Gender extension.

This extension, in short, tries to guess the gender of first names. As its introduction says:

Gender PHP extension is a port of the gender.c program originally written by Joerg Michael. The main purpose is to find out the gender of firstnames. The current database contains >40000 firstnames from 54 countries.

This is interesting beyond the fact that the author is kinda called George Michael. In fact, there are many aspects of this extension that are quite baffling.

While its last stable release was in 2015, the extension uses namespaces which clearly indicates that it's not some kind of long lost remnant of the past - a relatively recent effort was made to make it conform to modern coding standards. Even the example code uses namespaces:

]]>https://www.sitepoint.com/theres-a-gender-extension-for-php/feed/2Can You Build a CLI Image Drawing Laravel App with These Packages?https://www.sitepoint.com/can-you-build-a-cli-image-drawing-laravel-app-with-these-packages/
https://www.sitepoint.com/can-you-build-a-cli-image-drawing-laravel-app-with-these-packages/#respondMon, 15 May 2017 16:02:56 +0000https://www.sitepoint.com/?p=154348It's time for our monthly hunt for new open source libraries to use and contribute to!

If you're new to Sourcehunt, it's our monthly post for promoting open source projects that seem interesting or promising and could use help in terms of Github stars or pull requests.

It's our way of giving back - promoting projects that we use (or could use) so that they gain enough exposure to attract a wider audience, a powerful community and, possibly, new contributors or sponsors.

This package will let you remove all manual validation from Laravel Controllers, and instead rely on automatic validation that kicks instantly into action as a given controller and method are called - all you need to do is use the package's trait in a controller, and set the service provider. Then, you define rules like so:

The remainder of the process is automatic, and if validation fails, the request is automatically redirected back to the page from where it came, with error messages about validation flashed into session.

The project has no outstanding issues or pull requests, but why not add some? Here's an idea: make it dead easy to customize these error messages, and integrate them with Laravel's translator.

]]>https://www.sitepoint.com/can-you-build-a-cli-image-drawing-laravel-app-with-these-packages/feed/0Getting to Know and Love Xdebughttps://www.sitepoint.com/getting-know-love-xdebug/
https://www.sitepoint.com/getting-know-love-xdebug/#commentsTue, 18 Apr 2017 17:00:40 +0000https://www.sitepoint.com/?p=152621It's been 15 years since Xdebug first came out. We think this is the perfect opportunity to re-introduce it to the world, and explain how and why it does what it does.

Xdebug is a PHP extension (meaning it needs to be compiled and installed into a PHP installation) which provides the developer with some features for debugging. Those include:

stack traces - detailed output of the path the application took to reach a given error, including parameters passed to functions, in order to easily track the error down.

a prettier var_dump output which produces color coded information and structured views, similar to VarDumper, along with a a super-globals dumper

a profiler for finding out where the bottlenecks in your code are, and the ability to visualize those performance graphs in external tools. What this results in is a graph similar to that which Blackfire produces.

a remote debugger which can be used to remotely connect Xdebug with running code and an end-client like an IDE or a browser to step through breakpoints in code and execute line by line of your application.

code coverage which tells you how much of your code was executed during a request. This is almost exclusively meant to help with unit tests and finding our how much of your code is test-covered.

How do I use it?

Xdebug comes with a detailed installation page which handles most if not all use cases, but if you'd like to play with the functionality presented below, we recommend using Homestead Improved which comes with the extension pre-installed and activated.

With modern IDEs and Blackfire, is there even a need for Xdebug?

IDEs do provide good code lookup functionality, so the link format functionality's usefulness can seem questionable. There's also loggers of all kinds now which can handle errors and exceptions. Likewise, function traces and profiling are done really well in Blackfire. However, file link formats are just one part of Xdebug, and using Blackfire has its own hurdles - installing the extension, setting up the keys, and then paying to keep trace history. Loggers also need to be used with a lot of foresight, and aren't very easy to add into an application later on.

There's more to Xdebug than just this, though - it's still required for proper unit testing (testing frameworks depend on it for code coverage reports), it's far from easy to get remote break-point debugging going via other means, and it's a tool so old and stable it's been ironed out to near perfection.

If your current tools can handle everything it offers or you don't need the features it offers then of course, there's no need for Xdebug, but I've yet to start a single project that could be completed just as efficiently without it.

Let's Try It Out

I'll assume you have a working Xdebug installation at this point. If not, please consider using Homestead Improved.

Let's make a new project folder with a simple index.php file, and echo out a non-existent variable like $foo:

<?php
echo $foo;

This is what we get:

Turning Xdebug Off

Screens like these are so ubiquitous these days, and such a common default, that most people don't even realize this is already Xdebug-styled. To prove it, let's see how it looks without Xdebug. To disable Xdebug, we edit the file /etc/php/7.1/fpm/conf.d/20-xdebug.ini in Homestead Improved, and comment out the first line:

]]>https://www.sitepoint.com/getting-know-love-xdebug/feed/3Upgrading from Pthreads v2 to v3: What to Look out Forhttps://www.sitepoint.com/upgrading-pthreads-v2-v3-look/
https://www.sitepoint.com/upgrading-pthreads-v2-v3-look/#respondWed, 29 Mar 2017 16:00:11 +0000https://www.sitepoint.com/?p=151001A fair amount has changed for the pthreads extension with the release of pthreads v3. This article aims to cover the necessary information for those who are looking to upgrade their applications from pthreads v2 to v3.

A big thank you to Joe Watkins for proofreading and helping to improve my article!

Generic Changes

There have been a few general changes made in pthreads v3. The first, and perhaps most prominent, is that pthreads cannot be used in any environment other than the command line interface. It was never meant to be used in a web server environment (i.e. in an FCGI process) due to safety and scaling concerns, so the advice from pthreads v2 has now been enforced.

There have also been some changes to workers. Previously, there was a need to keep track of the work objects given to workers, otherwise if they were destroyed before having been executed by the worker thread, a segmentation fault would occur. This was well-known behavior and was demonstrated succinctly in the Multi-Threading in PHP with pthreads gist with the following snippet:

This is no longer an issue because the workers themselves now track the stacked work objects.

Furthermore, there have been some changes around the meaning of method modifiers in pthreads v3. In pthreads v2, method modifiers had a special meaning in the context of Threaded objects. Specifically, protected methods had implicit synchronized access (enabling for them to be safely executed by multiple contexts), and private methods could only be executed by the context they were tied to. These differing semantics have now been removed due to reliability concerns.

In pthreads v2, calling the ExampleThread::exclusive method from both the main context and the new thread context was safe. The value output at the end of the script would always be int(20000). But in pthreads v3, this value can be anything from 1 to 20000 due to race conditions between the two unsynchronized for loops.

In order to achieve the exact same behavior in pthreads v3, we must explicitly synchronize access using the built-in Threaded::synchronized method. This need only be applied to the body of the ExampleThread::exclusive method:

]]>https://www.sitepoint.com/upgrading-pthreads-v2-v3-look/feed/0Parallel Programming with Pthreads in PHP – the Fundamentalshttps://www.sitepoint.com/parallel-programming-pthreads-php-fundamentals/
https://www.sitepoint.com/parallel-programming-pthreads-php-fundamentals/#commentsWed, 22 Mar 2017 16:00:06 +0000https://www.sitepoint.com/?p=150995PHP developers seem to rarely utilise parallelism. The appeal of the simplicity of synchronous, single-threaded programming certainly is high, but sometimes the usage of a little concurrency can bring some worthwhile performance improvements.

In this article, we will be taking a look at how threading can be achieved in PHP with the pthreads extension. This will require a ZTS (Zend Thread Safety) version of PHP 7.x installed, along with the pthreads v3 installed. (At the time of writing, PHP 7.1 users will need to install from the master branch of the pthreads repo - see this article's section for details on building third-party extensions from source.)

Just as a quick clarification: pthreads v2 targets PHP 5.x and is no longer supported; pthreads v3 targets PHP 7.x and is being actively developed.

A big thank you to Joe Watkins (creator of the pthreads extension) for proofreading and helping to improve my article!

When Not to Use Pthreads

Before we move on, I would first like to clarify when you should not (as well as cannot) use the pthreads extension.

In pthreads v2, the recommendation was that pthreads should not be used in a web server environment (i.e. in an FCGI process). As of pthreads v3, this recommendation has been enforced, so now you simply cannot use it in a web server environment. The two prominent reasons for this are:

It is not safe to use multiple threads in such an environment (causing IO issues, amongst other problems).

It does not scale well. For example, let's say you have a PHP script that creates a new thread to handle some work, and that script is executed upon each request. This means that for each request, your application will create one new thread (this is a 1:1 threading model - one thread to one request). If your application is serving 1,000 requests per second, then it is creating 1,000 threads per second! Having this many threads running on a single machine will quickly inundate it, and the problem will only be exacerbated as the request rate increases.

That's why threading is not a good solution in such an environment. If you're looking for threading as a solution to IO-blocking tasks (such as performing HTTP requests), then let me point you in the direction of asynchronous programming, which can be achieved via frameworks such as Amp. SitePoint has released some excellent articles that cover this topic (such as writing asynchronous libraries and Modding Minecraft in PHP), in case you're interested.

With that out of the way, let's jump straight into things!

Handling One-off Tasks

Sometimes, you will want to handle one-off tasks in a multi-threaded way (such as performing some IO-bound task). In such instances, the Thread class may be used to create a new thread and run some unit of work in that separate thread.

In the above, the run method is our unit of work that will be executed inside of the new thread. When invoking Thread::start, the new thread is spawned and the run method is invoked. We then join the spawned thread back to the main thread (via Thread::join), which will block until the separate thread has finished executing. This ensures that the task has finished executing before we attempt to output the result (stored in $task->response).

Introduction

There's a lot going on under the hood when we execute a piece of PHP code. Broadly speaking, the PHP interpreter goes through four stages when executing code:

Lexing

Parsing

Compilation

Interpretation

This article will skim through these stages and show how we can view the output from each stage to really see what is going on. Note that while some of the extensions used should already be a part of your PHP installation (such as tokenizer and OPcache), others will need to be manually installed and enabled (such as php-ast and VLD).

Stage 1 - Lexing

Lexing (or tokenizing) is the process of turning a string (PHP source code, in this case) into a sequence of tokens. A token is simply a named identifier for the value it has matched. PHP uses re2c to generate its lexer from the zend_language_scanner.l definition file.

We can see the output of the lexing stage via the tokenizer extension:

]]>https://www.sitepoint.com/how-php-executes-from-source-code-to-render/feed/4What Would You Pay to Make 27% of the Web More Secure?https://www.sitepoint.com/what-would-you-pay-to-make-27-of-the-web-more-secure/
https://www.sitepoint.com/what-would-you-pay-to-make-27-of-the-web-more-secure/#commentsFri, 25 Nov 2016 17:00:29 +0000https://www.sitepoint.com/?p=144197It’s Open Source Week at SitePoint! All week we’re publishing articles focused on everything Open Source, Free Software and Community, so keep checking the OSW tag for the latest updates. Scott Arciszewski, known on Twitter as CiPHPerCoder, is to security what Chris Hartjes is to unit testing. He’ll pounce on insecure applications, libraries, and packages, […]