ioncube decode

PHP 8 is almost here, and with it a host of improvements, new functionality, and overall polish to make the web’s favorite server-side language even better. In this weekly series, leading up to the final release by the end of the year, we’ll cover what you need to know about PHP 8. It’s an exciting release, and we’re not even going to be covering all of it! There’s just that much going on.

The PHP team is pleased to announce the seventh testing release of PHP 8.0.0, Beta 4. This point in the release cycle would normally be RC1, however we’re still finalizing development of the JIT and squaring away named arguments, so we’ve opted for an extra beta release with plans to start the RC cycle in two weeks. At this time, we’re not planning to adjust the GA date, however this may change during the course of the RC cycle. The updated release schedule can, as always, be found on the PHP Wiki. For source downloads of PHP 8.0.0 Beta 4 please visit the download page.Please carefully test this version and report any issues found in the bug reporting system.Please DO NOT use this version in production, it is an early test version. 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. The next release will be the Release Candidate 1, planned for Oct 1 2020.The signatures for the release can be found in the manifest or on the QA site.Thank you for helping us make PHP better.

This episode is sponsored by
RingCentral Developers

The post Interview with Dave Delaney appeared first on Voices of the ElePHPant.

In this article, we give an overview of Swoole, discuss its benefits and drawbacks, and consider how it compares to NodeJS.

Version 8.0.0 Beta 3 is released. It’s now enter the stabilisation phase for the developers, and the test phase for the users.

RPM are available in the remi-php80 repository for Fedora ≥ 31 and Enterprise Linux ≥ 7 (RHEL, CentOS), or in the php:remi-8.0 stream,  and as Software Collection in the remi-safe repository (or remi for Fedora)

The repository provides development versions which are not suitable for production usage.

Also read: PHP 8.0 as Software Collection

Installation : read the Repository configuration and choose installation mode.

Replacement of default PHP by version 8.0 installation, module way (simplest way on Fedora and EL-8):

dnf module disable php
dnf module install php:remi-8.0
dnf update

Replacement of default PHP by version 8.0 installation, repository way (simplest way on EL-7):

yum-config-manager --enable remi-php80
yum update php\*

Parallel installation of version 8.0 as Software Collection (recommended for tests):

yum install php80

To be noticed :

• EL8 rpm are build using RHEL-8.2
• EL7 rpm are build using RHEL-7.8
• lot of extensions are also available, see the PECL extension RPM status page
• follow the comments on this page for update until final version.

Information, read:

• UPGRADING
• UPGRADING.INTERNALS

Base packages (php)

Software Collections (php74)

Two and a half years ago I wrote how to
use RecoilPHP to create a PSR-15 middleware adapter for react/http
using coroutines, monkey patching, and autoloader hijacking. Today there is a followup on that without any coroutines,
monkey patching, and autoloader hijacking. But using ext-parallel instead,
react-parallel/psr-15-adapter was created.

We just released Ketting 6. This is the accumulation of about a year
of learning on how to better integrate REST APIs with frontend frameworks,
in particular React.

It’s packed with new features such as local state management, new caching
strategies, (client-side) middleware support and change events. It’s also
the first release that has some larger BC breaks to make this all work.

Releasing Ketting 6 is a big personal milestone for me, and I’m really excited
to unleash it to the world and see what people do with. A big thank you to
all the people that beta tested this in the last several months!

What’s Ketting?

In short: Ketting is a generic REST client for Javascript. You can use it
for pushing JSON objects via HTTP, but the richer your API is in terms of
best practices and standard formats, the more it can automatically do for
you.

It has support for Hypermedia formats such as HAL, Siren, Collection+JSON,
JSON:API and can even understand and follow links from html.

It’s often said that REST (and Hypermedia APIs) is lacking a good generic
client. GraphQL has a lot of advantages, but a major one is tooling.
Ketting aims to close that gap.

More information can be found on Github.

React support in Ketting 6

Ketting now has a separate react-ketting package that provides React
bindings to Ketting. These bindings should look very familiar if you’ve
used Apollo Client in the past.

Lets dive into an example:

Lets assume you have a REST api that has an ‘article’ endpoint. This returns
something like:

{ "title": "Hello world", "body": "..."
}

This article is retrieved with GET, and updated with PUT, this is how
you would display it:

import { useResource } from 'react-ketting'; export function Article() { const { loading, error, data } = useResource('https://api.example/article/5'); if (loading) { return <div>Loading...</div>;
 } if (error) { return <div class="error">{error.message}</div>;
 } return <article> <h1>{data.title}<

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

This episode is sponsored by
RingCentral Developers

The post Interview with Olatunbosun Egberinde appeared first on Voices of the ElePHPant.

If you want to write applications that are maintainable in the long run, you have to decouple from your framework, ORM, HTTP client, etc. because your application will outlive all of them.

Three simple rules

To accomplish framework decoupling you only have to follow these simple rules:

1. All services should get all their dependencies and configuration values injected as constructor arguments. When a dependency uses IO, you have to introduce an abstraction for it.
2. Other types of objects shouldn’t have service responsibilities.
3. Contextual information should always be passed as method arguments.

Explanations

Rule 1

Following rule 1 ensures that you’ll never fetch a service ad hoc, e.g. by using Container::get(UserRepository::class).
This is needed for framework decoupling because the global static facility that returns the service for you is by definition framework-specific.
The same is true for fetching configuration values (e.g. Config::get('email.default_sender')).

Sometimes a dependency uses IO, that is, it talks to the database, the filesystem, etc.
In that case you should introduce an abstraction for the dependency.
If you depend on a concrete class, that class will work only with the specific library or framework that you’re working with right now, so in order to stay decoupled you should use your own abstraction, combined with an implementation that uses your current library/framework.

Rule 2

Aside from services there will be several other types of objects like entities, value objects, domain events, and data transfer objects, all of which don’t have service responsibilities.
None of them should have service responsibilities, because that means they will either invoke services via some global static facility, or they need special framework/ORM-specific setup meaning they can’t be used in isolation and won’t survive a major framework upgrade or switch.
An example of an object that doesn’t follow rule 2 is an active record model, which may look like an entity, but is able to save itself, which is in fact a service responsibility.

Rule 3

Contextual information is usually derived from the current web request or the user’s session, e.g. the ID of the user who is currently logged in.
Instead of fetching this data whenever you need it (like Auth::getUser()->getId()) you should pass it from method to method as a regular argument.

Combined, rule 1, 2, and 3 ensure that for every method it’s totally clear what it’s doing, what data it needs, and on what service dependencies it relies to do its work.
On top of that, none of the dependencies or method arguments will be framework or library-specific, meaning your application code will be effectively be decoupled from the framework.

Conclusion

If you ask me, these rules are very simple indeed, and they don’t require a lot of extra work compared to tightly coupling everything to your project’s current set of installed packages.
So, why not follow them if you know that your project should still be up-to-date with current standards 3 years from now?

P.S. Following these rules gives you much more than framework decoupling: everything becomes testable in isolation, the tests are fully deterministic and therefore very stable, and they are really fast to run.

Like clockwork, the next release of PHP is slated to come out on November 26th. It’s packed with new features and performance improvements, as well as general overall polish. And as usual, you can try it out early on Platform.sh with a single-line change.
We now have a php:8.0-rc container image available. That is rc meaning our prerelease, not PHP’s RC phase. It is PHP 8.0 beta 3 (just released as of this writing), but we will be updating it periodically as new pre-release versions of PHP 8 are released in the coming weeks.