PHP 7.1 was an incremental feature release, offering new language constructs, significant performance improvements, and lower resource utilization, making it a natural choice for fast-paced business-critical applications.

In this article, we look at PHP 7.1 features, performance comparisons, end of life, and why the PHP 7.1 release marked such a big change for PHP.

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

The PHP team is pleased to announce the first testing release of PHP 8.0.0, Alpha 1. This starts the PHP 8.0 release cycle, the rough outline of which is specified in the PHP Wiki. For source downloads of PHP 8.0.0 Alpha 1 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 Alpha 2, planned for 9 Jul 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
Using the WordPress REST API

The post Interview with Stephen S. Musoke appeared first on Voices of the ElePHPant.

Recently I received a question; if I could explain these four lines:

/** * @test */
public function it_works_with_a_standard_use_case_for_command_objects(): void

The author of the email had some great points.

1. For each, my test I should write +3 new line of code instead write, public function testItWorksWithAStandardUseCaseForCommandObjects(): void
2. PSR-12 say that “Method names MUST be declared in camelCase”. [The source of this is actually PSR-1].
3. In PHPUnit documentation author say “The tests are public methods that are named test*” and left example below

4. PHPStorm IDE from the last version gives for you ability to generate a TestCode and they do not use an underscore too:

   

5. I opened a popular frameworks (Symfony, Laravel, YII2, CodeIgniter4) test folders in Github and then I opened a popular PHP library and also do not find underscore usage in test and @test annotation.

This made me realize that, yes, what I’m doing here is a convention, and maybe it’s not the most popular one.
Well, I’ve seen tests that use an even less conventional approach to method naming by using some kind of character that isn’t a space but still looks like one:

/** * @test */
public function it works with a standard use case for command objects(): void

This is too much for me, but who knows, in a couple of years maybe…

I’ll first respond to the objections now:

1. I don’t think it’s bad to write 3 new lines for every test method.
   It’s not like it’s actual code that gets duplicated, it’s just an annotation.
   The code never has to be modified, so it will never suffer from Shotgun Surgery (unless you switch test frameworks maybe).
   Anyway, I have a live template configured in PHP so I only have to type it and it will complete this with /** @test */ public function etc. We’ll talk about it later.

2. Philosophically speaking, I don’t think a test method is a regular object method.
   Yes, of course, it is technically a method. PHPUnit instantiates your TestCase and will call its methods.
   But that is just the way PHPUnit does it.
   You might as well write something like this:

   it('works with a standard use case for command objects');
   

   In fact, there are test frameworks that let you write tests like this.

   You will never find any normal code (a.k.a. production code) call these test methods.
   I do think that would look rather weird.

   Instead of regular methods, I think we should consider test methods to be documentation or more specific: specification.
   This makes other aspects than code style conventions more important: it needs to be readable and precise.
   And in my experience testItWorksWithAStandardUseCaseForCommandObjects is really hard to read.
   Then again, maybe I just have to practice.

   But what if your code style fixer automatically turns “snake_case” method names into camelCase ones?
   Just configure the tool to ignore your tests.

3. The way things are done in framework documentation can, but doesn’t have to be considered the standard.
   The writer of the documentation has different goals than you have.
   Maybe they want to show the easiest way to get started with their framework.
   Maybe they just show the way that most users do it.
   Maybe nobody knows what most users do, and they just pick a way.
   What I do know is that the PHPUnit documentation also mentions this other way: “Alternatively, you can use the @test annotation in a method’s docblock to mark it as a test method.”
4. Although I love PhpStorm, I’m totally not inclined to do as they do.
   As an example, they have invented the convention that we have to annotate all the exceptions that a method throws.
   They also have an inspection that warns you about calling a method that could throw an exception.
   I bet that a lot of developers have since been wrapping things in try/catch blocks and coming up with inventive ways of dealing with exceptions.
   Not because we have to, but because the IDE developers thought it would be a good idea.
   End of rant.
   Conclusion: don’t let the IDE determine how you write your code (unless you have thought about it and agree with it of course).
   When it comes to generating a test class and “generating test methods”: totally ignore what PhpStorm h

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

PHP 7 was a landmark release for PHP. See release and EOL dates, performance comparisons, and new features for PHP 7 in this blog

There is no MEDIAN() function in Google BigQuery, but we can still calculate the MEDIAN
with the
PERCENTILE_CONT(x, 0.5) or
PERCENTILE_DISC(x, 0.5)
functions. The difference between those two functions is the linear interpolation that is applied
when using PERCENTILE_CONT(x, 0.5) – so that’s probably what you want when dealing with numeric
values. Take the numbers 1,2,3,4 for example:

• PERCENTILE_CONT(x, 0.5) yields 2.5 (as the 50% percentile is exactly between 2 and 3)
• PERCENTILE_DISC(x, 0.5) yields 2 (as the 50% percentile is >= 2)

Example

SELECT PERCENTILE_CONT(x, 0.5) OVER() AS median_cont, PERCENTILE_DISC(x, 0.5) OVER() AS median_disc
FROM UNNEST([1,2,3,4]) as x
LIMIT 1

Result

Caution: As of today (2020-06-20), BigQuery only supports PERCENTILE_CONT and PERCENTILE_DISC for window functions
(hence the OVER() clause and the LIMIT 1 in the example above):

PERCENTILE_CONT is under development, and we will publish the documentation once it is GA. We will support it as analytic function first, and we plan to support it as aggregate function (allowing GROUP BY) later.

Source: SO: percentile functions with GROUPBY in BigQuery

The more common use case is probably to calculate the median as a result of a GROUP BY statement.
I.e. I would like to write something like this to get the median of quantity per product_id.

SELECT product_id, PERCENTILE_CONT(quantity, 0.5) AS median
GROUP BY product_id

Right now, that is only possible for the average via
AVG()
but not for the median. But we can still work around that limitation by using the
PERCENTILE_CONT function on a window partitioned by product_id, then group by the product_id
(to get only one row per product_id)
and resolve a single median value via ANY_VALUE().

Working Example

<script src=”https://gist.github.com/paslandau/14940ec0fd34dc30b36377886c308ab3.js”><script src=”https://gist.github.com/paslandau/14940ec0fd34dc30b36377886c308ab3.js”>

Run on BigQuery

Open in BigQuery UI

Links

• Answer to “How to calculate median of a numeric sequence in Google BigQuery efficiently?” on Stackoverflow

Notes

There is also the APPROX_QUANTILES()
function (mentioned here) that can by applied to a GROUP BY. I didn’t have a practical use case for approximate functions
yet, though. Thus, I don’t know the implications of “not using an exact calculation” and rather mention
this for the sake of completeness. Example:

SELECT product_id, APPROX_QUANTILES(quantity, 100)[OFFSET(50)] as approx_median
GROUP BY product_id

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

While Advanced Web Application Architecture is still a work in progress, I decided to release another project in the meantime: a book for beginning PHP developers called PHP for the Web.

Of course, there are PHP books for beginners, but most of them aren’t very concise.
They cover many related topics like relational databases, CLI applications, and sending emails.
I wanted to write a book that only shows what makes PHP so special when it comes to web development.

Writing this book took me back to the beginning of my own programming career in 2002.
Many things have changed since then, but surprisingly many things are still the same too!

The biggest change when it comes to dealing with the web in PHP: we now have frameworks.
This is obviously a good thing, since it has made our applications much more secure.
For instance, in 2002 I wasn’t aware of the need for output escaping, or to escape parameters in my SQL queries, and I didn’t know that I should protect TinyMCE’s upload script against anonymous file uploads…

On the other hand frameworks hide so many of the lower-level details that I dare to say that many PHP developers today don’t know how it all works under the hood.
What are cookies and how do they work?
What’s the difference between PHP errors and exceptions?
What is $_FILES and how can I use it?

This new book, PHP for the Web explains it all in over 200 pages.

If you’re thinking about learning PHP to build web applications, use the following link to get the book for just $9: https://leanpub.com/learning-php-for-the-web-without-a-framework/c/RELEASE_DAY
And if you know someone who thinks about learning PHP, forward this link to them as well!

Here’s the table of contents to give you an idea of what’s in there.
If you want to read a sample, go to the landing page and click on Read Free Sample.

1. Serving resources
   • Serving an index.html file with the built-in web server
   • The project root should not be the document root
   • Communication between the browser and the server
2. Serving PHP scripts
   • The response: status, headers and body
   • Linking to other pages
   • Passing values between requests
   • user input can’t be trusted
3. Forms
   • Submitting form data as query parameters
   • Always use output escaping
   • Adding a select element to the form
   • Submitting data via the request body
4. Cookies
   • Setting a cookie
   • Using a cookie
   • Redirecting after processing a POST request
5. Sessions
   • Session files and serialized data
   • Flash messages
   • Using flash messages everywhere
6. Authentication
   • Setting up a login form
   • Logging out
7. Project structure
   • Header and footer snippets
   • Bootstrapping
   • Routing
8. CRUD part 1: Create
   • Saving JSON-encoded data in a file
   • Adding a tour
   • Form validation
   • Listing tours
9. CRUD part 2: The rest
   • Introducing some reusable elements
   • Editing tour data
   • Deleting tours
10. File uploads
    • Uploading a file
    • Showing the uploaded picture
    • Form validation for file uploads
11. Error handling
    • Producing an error
    • Using different configuration settings in production
    • PHP errors
12. Automated testing
    • Using Composer to install testing tools
    • Creating our first browser test
    • Starting with a clean slate
13. Conclusion

Now go get your copy!

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