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)

The PHP development team announces the immediate availability of PHP 7.3.19. This is a bug fix release.All PHP 7.3 users are encouraged to upgrade to this version.For source downloads of PHP 7.3.19 please visit our downloads page, Windows source and binaries can be found on windows.php.net/download/. The list of changes is recorded in the ChangeLog.

PHP just recently celebrated its 25th anniversary since it was first introduced, which is quite the achievement, considering it still powers a large slice of the Internet today. I don’t write much PHP anymore myself as I’ve more or less moved on to new and different things, but I am incredibly grateful to PHP. It was one of the first “real” programming languages I really invested in to learn programming, and learn I did. I built real things, real websites with it, and also was involved in the community for a while. I saw the rise of Composer and Packagist replace the aging PEAR. I saw the release of PHP 7 and all the work that went into it the years prior leading up to it.

Now as expected whenever talking about PHP on the Internet, people are quick to grab their pitchforks and rehash the same classic criticisms of PHP over and over like a mantra. Is it to feel superior? Do they think they’re doing a public service? I don’t know. What I do know is that they’re right to some extent; PHP isn’t the best-designed language by any means, largely because it changed organically and incrementally over time. It certainly hasn’t stopped PHP from becoming as popular as it has.

There are plenty of good reasons why PHP isn’t the best language for many use-cases, and reasons why other languages are superior. I consider myself very experienced with it, so I speak from experience. Here are some examples just from memory:

• The standard library, while fairly complete, doesn’t really follow modern PHP’s own best practices for API design, as it was largely created before PHP had things like namespaces and classes. This results in an odd disconnect with modern packages, and that weird mix of styles never really goes away.
• The standard library also cares a lot about backwards compatibility, which is a good thing, but its also a double-edged sword. There are a lot of APIs and extensions that are soft-deprecated or generally not used in favor of higher-quality third-party packages.
• The fact that every class file begins with <?php reminds you that PHP was originally just an html preprocessor and always runs inside the context of another file format. It makes sense, but its unusual and weird, especially since embedding PHP into html isn’t even done at all in many frameworks which have dedicated templating languages instead.

There are probably others, but these don’t keep me from remembering PHP with fondness as something that just works out of the box and has a lot of convenient features for web development.

What’s strange to me though is that instead of reasonable complaints like these, people like to present complaints that don’t make sense, aren’t true, or are just plain silly. Let’s take a look at just a couple that I’ve seen.

The syntax is strange and archaic!

This complaint doesn’t really make much sense to me. PHP’s syntax is very heavily inspired by C (which it is written in) and borrows many things from it. In fact, it fits right in with most of the languages in the C family of syntax. Just swap the dot operator for -> (which by the way is also lifted from C, its equivalent to (*struct_ptr).field), prepend all your variables with the $ sigil, and that’s just about it. It’s got your boring traditional class syntax that even JavaScript adopted, closures, and pretty much every modern convenience.

Granted, sigils probably remind you of Perl, but don’t worry, they don’t have crazy effects on data types like in Perl. Just think of it as part of the variable name and you’ll be fine.

There are a few PHP-specific oddities in its syntax, like the @ operator and using \ as a namespace separator, but these seem like really petty nitpicks to me.

It isn’t modular!

This sort of complaint is really nebulous, and could stand to have some clarifying questions asked. Usually people mean one of two things:

1. Everything is in a global namespace with no modular separation.
2. There is no modular way of packaging code.

Now both of these are just blatantly false. The first one is easy: PHP has namespaces, like Java, C#, or what-have-you. And they were added to the language in version 5.3, which was released in 2009! Now to be fair, there still exists a lot of codebases that were initially designed before then (like WordPress) that don’t leverage namespaces everywhere because of this, and this includes the standard library itself. But generally namespaces have been adopted for some time, and any modern PHP codebase uses them well.

The second

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