Testing The Core
Growing the PHP Core
Hack Your Home With a Pi
The Workshop: PHP Puzzles: PSR Pickup:
Accept Testing with Making Some Change PSR 12 - Extending Codeception Coding Style Standards
Security Corner: Education Station: Drupal Dab: Operational Security Which License to V9 Intro and Install Choose? DDD Alley: finally{}: When the New Requirement Arrives Tech is Taking Sides
Learn how a Grumpy Programmer approaches improving his own codebase, including all of the tools used and why.
The Complementary PHP Testing Tools Cookbook is Chris Hartjes’ way to try and provide additional tools to PHP programmers who already have experience writing tests but want to improve. He believes that by learning the skills (both technical and core) surrounding testing you will be able to write tests using almost any testing framework and almost any PHP application.
Available in Print+Digital and Digital Editions.
Order Your Copy
phpa.me/grumpy-cookbook
April 2022 Volume 21 - Issue 4
2 Impacting the World Through Tech Eric Van Johnson 3 Growing the PHP Core - One Test at a Time Florian Engelhardt 9 How to Hack your Home with a Raspberry Pi - Part 4 Ken Marks 23 Which License to Choose? Education Station Chris Tankersley 28 Operational Security Security Corner
Eric Mann
30 Accept Testing with Codeception The Workshop Joe Ferguson
35 When the New Requirement Arrives DDD Alley Edward Barnard
39 Drupal 9 - Introduction and Installation Drupal Dab Nicola Pignatelli
45 Making Some Change PHP Puzzles Oscar Merida 49 New and Noteworthy 50 PSR 12 Extended Coding Style Standard PSR Pickup Frank Wallen
52 Tech is Taking Sides finally{} Beth Tucker Long
Copyright © 2022—PHP Architect, LLC All Rights Reserved
Although all possible care has been placed in assuring the accuracy of the contents of this magazine, including all associated source code, listings and figures, the publisher assumes no responsibilities with regards of use of the information contained herein or in all associated material.
php[architect], php[a], the php[architect] logo, PHP Architect, LLC and the PHP Architect, LLC logo are trademarks of PHP Architect, LLC.
Edited with peace and love
php[architect] is published twelve times a year by:
PHP Architect, LLC 9245 Twin Trails Dr #720503 San Diego, CA 92129, USA
Subscriptions Print, digital, and corporate subscriptions are available. Visit https://www.phparch.com/magazine to subscribe or email contact@phparch com for more
Advertising To learn about advertising and receive the full prospectus, contact us at ads@phparch.com today!
Contact Information: General mailbox: contact@phparch.com Editorial: editors@phparch.com
Print ISSN 1709-7169 Digital ISSN 2375-3544
Impacting the World Through Tech
Eric Van Johnson
If you listen to my PHPUgly podcast, you might know that we have a policy of not mixing politics with our tech talk. That is a policy we have been breaking more and more often over the past couple of years.
From the previous presidential term and through the election, a glaring topic that started to surface more and more was that our industry and technology were playing a more significant role in politics, local and worldwide. For better or worse, it has become how people get their news, shape their opinions, and set the stage for how people are perceived. Speaking about technology and how it plays into events like the Russian invasion of Ukraine is unavoidable. Tech companies and services also know they can no longer avoid how their products and offerings might be contributing to atrocities that they do not want to be a part of, and they have begun to take action. In this April edition of finally{}, Beth Tucker Long shares her thoughts in Tech is Taking Sides. We get Part Four of Ken Marks’ Raspberry Pi series, where he discusses web API and plotting data. This series has been such a fantastic read. If you haven’t been keeping up, go back to the beginning of the year and read the previous three parts. Ken has been doing a terrific job explaining the journey of his real-world solution that he created using a Raspberry Pi and PHP. Also, congratulations to our second winner of the Raspberry Pi giveaway, Miguel Gallegos. Florian Engelhardt contributed a column this month on a topic matter I had been wanting for a long time called Growing the PHP Core One Test at a Time. Florian walks you through the PHP core codebase and how the tests work. I couldn’t wait to step through this article. He steps you through cloning the PHP codebase and through the testing workflow. This month, we introduce a new column called Drupal Dab, contributed by Nicola Pignatelli. Drupal 9 Introduction and Instal_lation—thetitleprettymuchcoversthetopic._
He walks us through how to install Drupal and some of the first things to do after you install it. In this month’s Education Station, Chris Tankersley takes us down the path of licenses with some thoughts on choosing one for our project in his article Which License to Choose? He discusses the pros and cons of several open-source licenses and explains the benefits and drawbacks. In Security Corner, Eric Mann discusses Operational Security. He touches on what happens when disaster strikes, learning from mistakes, best practices, and the ongoing quest for security. Next to time, one of the more frustrating areas to code is money, and in this month’s PHP Puzzles Making Some Change, Oscar Merida goes over the challenge of making change. He also shows some solutions to last month’s challenge on the best ways to make change. We’ve all heard the excuses for not having tests, tests are “confusing”, “difficult”, “takes too long to write”, or are just “complicated.” There’s also a saying, “any tests are better than no test.” In this month, The Workshop, Joe Ferguson goes over one of the easiest ways to get some basic tests in your project with his article Accept Testing with Codeception. I have personally been a huge fan of Edward Barnard’s new DDD Alley column. This month he continues the series with When the New Requirements Arrive, where he talks about what you do when new requirements for a codebase are introduced and how to handle them. He touches on the solid principle, bloated classes, test boundaries, and more. Frank Wallen continues his new column, PSR Pickup, where he moves on to PSR 12 Extended Coding Style Standard and discusses what this PSR is and why you might want to use it in your projects.
Write For Us
If you would like to contribute, contact us, and one of our editors will be happy to help you hone your idea and turn it into a beauti- ful article for our magazine. Visit https://phpa.me/write or contact our editorial team at write@phparch.com and get started!
Stay in Touch
Don’t miss out on conference, book, and special announcments. Make sure you’re connected with us.
- Subscribe to our list:
- Facebook:
Download the Code
Archive:
Growing the PHP Core - One Test at a Time
Florian Engelhardt
In September 2000, I started my vocational training at an internet agency with two teams: one doing JavaServer Pages and one doing PHP. I was assigned to the PHP team, and when presented with the language, I immediately knew that no one would ever use it. I was wrong. Today, my entire career is built on PHP. It’s time to give back to the community by writing tests for the PHP core itself!
Prepare Your Machine!
Before you start writing tests for PHP, let’s start with running the tests that already exist. Fetch the PHP source from GitHub and compile it to do so.
$ git clone git@github.com:php/php-src.git
$ cd php-src
$ ./buildconf
$ ./configure --with-zlib
$ make -j `nproc`
I recommend creating a fork upfront because it’s easier to create a pull request when you finish your test. If you do not have a compiler and build tools already installed on your Linux computer, install the
development-tools group on Fedora or the build-essential
on Debian Linux. The ./configure command may exit with
an error condition; this usually occurs when build requirements are not met, so install whatever ./configure is missing
and rerun that step. Keep in mind that you need to install
the development packages — in my case, the configure script
stated it was missing libxml, which was, in fact, installed.
It was really missing the header files in the development
package (usually named with a dev or devel suffix). Note that
the —with-zlib argument to ./configure is mandatory only in
this case, as you will need the zlib extension (which is not
built by default) for the following examples.
After your build is complete, you can find the PHP binary
in ./sapi/cli/php. Go ahead and check what you just created:
$ ./sapi/cli/php –v
PHP 8.2.0-dev (cli) (built: Dec 28 2021 19:43:57) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.2.0-dev, Copyright (c) Zend Technologies
Now that you have a freshly built and running PHP binary, you can finally run the tests included within the GitHub repository. Since PHP 7.4 tests may run in parallel, you can give the number of parallel jobs with the -j argument.
$ make TEST_PHP_ARGS=-j`nproc` test
============================================
TEST RESULT SUMMARY
-------------------------------------------Exts skipped : 46
Exts tested : 26
-------------------------------------------Number of tests : 17124 11774
Tests skipped : 5350 ( 31.2%) -------Tests warned : 1 ( 0.0%) ( 0.0%)
Tests failed : 2 ( 0.0%) ( 0.0%)
Expected fail : 28 ( 0.2%) ( 0.2%)
Tests passed : 11743 ( 68.6%) ( 99.7%)
-------------------------------------------Time taken : 40 seconds
============================================
This output looks good, and it only took 40 seconds to run 11774 tests — quite fast. Only one warning and two failures, hooray! You can also see that 5350 tests have been skipped, and 28 have been expected to fail. You will learn about why this is in the next part.
What Do Tests Look Like?
Now that we know how to execute the tests, let’s look at a
test case. PHP test files have the file ending .phpt and consist
of several sections, three of which are mandatory: the TEST,
the FILE, and the EXPECT or EXPECTF section.
--TEST-strlen() function
--FILE-<?php
var_dump(strlen('Hello World!'));
?>
--EXPECT-int(12)
###### The TEST Section
This section is a short description of what you are testing in a single line. It must be as short as possible, as the section is printed when running the tests. You can put additional details in the DESCRIPTION section.
The DESCRIPTION Section
If your test requires more than a single line to describe it adequately, you can use this section for further explanation. This section is completely ignored by the test binary.
The FILE Section
This section is the actual test case, PHP code enclosed by PHP tags. It is where you do whatever you want to test. As you have to create output to match against your expectation, you usually find var_dump all over the place.
The EXPECT Section Figure 1.
This section must exactly match the output from the executed code in the
FILE section to pass.
###### The EXPECTF Section
EXPECTF can be used as an alterna
tive to the EXPECT section and allows
the usage of substitution tags you may
know from the printf functions family:
--EXPECTF-int(%d)
###### The EXTENSIONS Section
You should list all the PHP extensions that your test case depends on in this optional section. The PHP test runner will try to load those extensions, and if they are not available, skip the test. If you depend on multiple extensions, the list must be separated by a newline character. In our case, we will list the zlib extension.
The SKIPIF Section
This section is optional and is parsed and executed by the PHP test runner. The test case is skipped if the resulting output starts with the word skip. If it starts with xfail the test case is run, but it is expected to fail.
The XFAIL Section
XFAIL is another optional section. If present, the test case is
expected to fail; you don’t need to echo out xfail in the SKIPIF section at all if you have this. It contains a description of why this test case is expected to fail. This feature is mainly used when the test is already finished, but the implementation isn’t yet, or for upstream bugs. It usually contains a link to where a discussion about this topic can be found.
The CLEAN Section
This section exists so you can clean up after yourself. An
example might be the temporary files you created during
the test. Keep in mind this section’s code is executed independently from the FILES section, so you have no access to
variables declared over there. Also, this section is run regardless of the outcome of the test.
You may find more in-depth details on the file format at the PHP Quality Assurance Team Web Page[1].
What Can You Test?
Now that you know what a PHP test looks like, it is time to find something to test. Head over to Azure Pipelines[2], click on the latest scheduled run (look for the calendar icon and the string “Scheduled for”), and then click “Code Coverage” to view the code coverage report.
When I started looking for something to test, I found that the zlib_get_coding_type() function in ext/zlib/zlib.c was not covered at all (this was back in the PHP 7.1 branch and on the now-retired gcov.php.net[3] . See Figure 1. The next step was to check out what this function was supposed to do in the PHP Documentation[4]. In the documentation and the code itself, I saw that this function returns the string gzip or deflate or the Boolean value false. The linked zlib.output_compression directive documentation[5] gave one additional bit of information: the zlib output compression feature reacts on the HTTP Accept-Encoding header sent with the client HTTP request.
The Big Picture
In an HTTP request, a client can indicate via the Accept-En``` coding header that it would understand a compressed response
using the specified compression algorithms. Additionally, if
the PHP directive `zlib.output_compression is enabled, PHP`
magically compresses the output generated by your script
before sending it to the client, saving bandwidth.
_1_ _[Web Page: https://qa.php.net/phpt_details.php](https://qa.php.net/phpt_details.php)_
_2_ _Azure Pipelines:_
_[https://dev.azure.com/phpazuredevops/PHP/_build?definitionId=1](https://dev.azure.com/phpazuredevops/PHP/_build?definitionId=1)_
_3_ _gcov.php.net:_
_[http://gcov.php.net/PHP_7_1/lcov_html/ext/zlib/zlib.c.gcov.php#543](http://gcov.php.net/PHP_7_1/lcov_html/ext/zlib/zlib.c.gcov.php#543)_
_4_ _[PHP Documentation: https://www.php.net/zlib-get-coding-type](https://www.php.net/zlib-get-coding-type)_
_5_ _zlib.output_compression directive documentation:_
_[https://www.php.net/zlib.configuration#ini.zlib.output-compression](https://www.php.net/zlib.configuration#ini.zlib.output-compression)_
Figure 1.
-----
###### Test cases
For the test, this means there are four possible cases to
check for:
- the absence of the Accept-Encoding header
- the Accept-Encoding being gzip
- the Accept-Encoding being deflate
- the Accept-Encoding being anything else
The last case is treated the same as the first case: The function is expected to return the Boolean value false.
###### Time To Write That Test!
Let’s start with the first test for the case where
there is no `Accept-Encoding header set in the file`
test/zlib_get_coding_type.phpt.
Listing 1.
- —TEST- 2. zlib_get_coding_type()
- —EXTENSIONS- 4. zlib
- —FILE- 6. <?php
- ini_set(‘zlib.output_compression’, ‘Off’);
- var_dump(zlib_get_coding_type());
- ini_set(‘zlib.output_compression’, ‘On’);
- var_dump(zlib_get_coding_type());
- ?>
- —EXPECT-13. bool(false)
- bool(false)
You can run this single test via:
$ make test TESTS=test/zlib_get_coding_type.phpt
Sadly, this gives you a failed test. You can easily see why
this is the case by checking the test directory contents where
you find your .phpt test file and other files with various file
endings. One that is particularly interesting, in this case, is
the zlib_get_coding_type.log file:
---- EXPECTED OUTPUT bool(false) bool(false) ---- ACTUAL OUTPUT bool(false) Warning: ini_set(): Cannot change zlib.output_compression
- headers already sent in test/zlib_get_coding_type.php
on line 4
bool(false) ---- FAILED
Don’t let these failed tests get you down if this is your
first time learning about PHP internals. These failed tests
are learning opportunities. For example, in this case you
will learn that you cannot change the output compression
setting after your script creates any form of output. For
output compression to work, there is a handler that is called
when we change the zlib.output_compression directive. This
handler checks to see if any output has already been sent,
and if it has, sends a warning.
Let’s dive deeper. Try searching for “zlib.output_compression” in the ext/zlib/zlib.c source code file. You find it in the
call to the STD_PHP_INI_BOOLEAN macro along with the pointer
to the function `OnUpdate_zlib_output_compression in which`
you can spot the warning you received.
Thinking of the big picture of the feature, this totally makes
sense. When the script creates any form of output, PHP
will create and send the HTTP response headers indicating
whether the response will be compressed and, if so, what
algorithm was used We can not toggle this feature anymore
as there is no way of telling the client that part of the response
is compressed and another part is not.
To work around this warning, you can change the `FILE`
section to only create output after the calls to ini_set:
Rerunning the test case results in your first successful test!
🎉
It’s not time to party yet; there are still other cases to cover.
The next one on the list is the case with the HTTP Accept-En```
coding header set to the string gzip. As a PHP developer,
you know you can access and change the HTTP headers via
the super global $_SERVER. Let’s change the FILE and EXPECT
section accordingly as shown in Listing 2.
Listing 2.
1. --FILE- 2. <?php
3. ini_set('zlib.output_compression', 'Off');
4. $off = zlib_get_coding_type();
5. ini_set('zlib.output_compression', 'On');
6. $on = zlib_get_coding_type();
7. $_SERVER['HTTP_ACCEPT_ENCODING'] = 'gzip';
8. $gzip = zlib_get_coding_type();
9. var_dump($off);
10. var_dump($on);
11. var_dump($gzip);
12. ?>
13. --EXPECT-14. bool(false)
15. bool(false)
16. string(4) "gzip"
Now run the test via:
$ make test TESTS=test/zlib_get_coding_type.phpt
The test failed again. Looking into the zlib_get_coding_type.
log file, you notice that the third call to the zlib_get_coding_
type() function returned false, not the expected string gzip.
It seems like PHP is not reacting to the HTTP header that
you clearly set just one line before. Did we spot a bug in PHP?
The source code tells you: Open the ext/zlib/zlib.c source
code file and search for the variable compression_coding as
this is the variable being evaluated in the function you are
testing. You should find some matches, but there is one at
the beginning of the file in the C function php_zlib_output_
encoding, which looks like the only place where something is
assigned to the variable in question.
Analyzing the source code, not understanding exactly what
is going on, and finally asking for help on the PHP Community
Chat[6] reveals the following: All of your userspace variables
and PHP user-accessible autoglobals ($_GET, $_SERVER, …)
are copy-on-write. Altering those from your script creates a
copy for you to work on in userspace, effectively making the
HTTP request headers immutable to the userspace. The
PHP core continues to use the original, unaltered version.
Now that you know you can not alter or set the HTTP
header from within your script to influence PHP’s behavior,
this might look like a sad end for your tests code coverage.
Wait, there is more! I did not tell you about another
section in the PHPT file format that might come in handy
now: The ENV section. This section is used to give environ-
ment variables to your script that are passed to the PHP
process that runs your test code—meaning you can continue
writing tests and that you have to create a test file per test
case. Let’s create a new test file for the gzip case and name it
zlib_get_coding_type_gzip.phpt.
Listing 4.
1. --TEST- 2. zlib_get_coding_type() is gzip
3. --EXTENSIONS- 4. zlib
5. --ENV- 6. HTTP_ACCEPT_ENCODING=gzip
7. --FILE- 8. <?php
9. ini_set('zlib.output_compression', 'Off');
10. $off = zlib_get_coding_type();
11. ini_set('zlib.output_compression', 'On');
12. $gzip = zlib_get_coding_type();
13. ini_set('zlib.output_compression', 'Off');
14. var_dump($off);
15. var_dump($gzip);
16. ?>
17. --EXPECT-18. bool(false)
19. string(4) "gzip"
Run the test and see it fails once more. You might have expected this by now. 😝 Let’s see what happened by looking into the
zlib_get_coding_type_gzip.log file.
---- EXPECTED OUTPUT
bool(false)
string(4) "gzip"
---- ACTUAL OUTPUT
�1�0 ���B�P�Txꆘ8`5ؑ������s�7a�ze��B+���ϑ�,����^�
---- FAILED
Wow, this looks like some binary garbage, and yeah, this
does not match the expected output.
Look at your test case. You told PHP that you accept gzip
encoding and you turned on output compression. PHP is
basically just doing what we told it to do. The binary garbage
you see here is gzip encoded data. This means you succeeded
in activating gzip output compression, but forgot to turn it off
before dumping out the two variables. Now, all that’s left is to
add another call to deactivate output compression again so
the final test looks similar to Listing 4.
Rerun this test, and it finally passes! 🎊🥳🎉
Now you’re left writing one test case for the Accept-En-
coding header being set to deflate and another test case for the
Accept-Encoding header being set to an invalid string (basi
cally something that is not gzip or deflate). From this point on, finishing the test cases is just diligence, and if you like to cheat, you can find the tests in the ext/zlib/tests/ directory named:
-
zlib_get_coding_type_basic.phpt -
zlib_get_coding_type_br.phpt -
zlib_get_coding_type_deflate.phpt
-
zlib_get_coding_type_gzip.phpt
Listing 3.
1. --TEST- 2. zlib_get_coding_type() is gzip
3. --EXTENSIONS- 4. zlib
5. --ENV- 6. HTTP_ACCEPT_ENCODING=gzip
7. --FILE- 8. <?php
9. ini_set('zlib.output_compression', 'Off');
10. $off = zlib_get_coding_type();
11. ini_set('zlib.output_compression', 'On');
12. $gzip = zlib_get_coding_type();
13. var_dump($on);
14. var_dump($gzip);
15. ?>
16. --EXPECT-17. bool(false)
18. string(4) "gzip"
6 PHP Community Chat: https://phpc.chat
Collect Some Evidence!
Now that you have tests for all four cases, you could hope
you covered that function with tests or (a way better option if
you ask me), you could continue and create a code coverage
report! For the report to work, you need to install the lcov
tool via your Linux package manager (sudo dnf install lcov
for Fedora or sudo apt-get install lcov for Debian). PHP
was built with gcov disabled, so we need to run configure
again, with enabled gcov and recompile.
$ make clean
$ CCACHE_DISABLE=1 ./configure --with-zlib --enable-gcov
$ make -j `nproc`
This code compiles the PHP binary with enabled code coverage generation. Lcov will be used to create an HTML code coverage report afterward. To create your code coverage report, you need to rerun the tests.
$ make test TESTS=test/zlib_get_coding_type.phpt
While running the tests, gcov generates coverage files with a gcda file ending for every source code file. To generate the HTML code coverage report, run the following:
$ make lcov
You may find the resulting HTML code coverage report in
lcov_html/index.html.
It looks like we covered all four cases as shown in Figure 2.
What’s in It for You?
PHP becomes more stable and reliable with every test you write, as functions may not suddenly change behavior between releases. Writing tests for PHP gives you a deeper understanding of how your favorite language works internally. In fact, by reading up to this point, you may have learned that HTTP request headers are immutable to userspace, that there is such a thing as userspace, and that there are handler functions called to check what you are doing when you want to change ini settings at runtime.
Also, knowing the PHPT file format gives you other benefits as well: PHPUnit[7] not only supports the PHPT file format and can execute those tests, part of PHPUnit is tested with PHPT test cases. This skill led me to become a PHPUnit contributor: Writing PHPUnit tests in the PHPT file format.
Shout Out!
I would like to thank everyone involved in the PHP TestFest[8], especially Ben Ramsey[9] and everyone else involved in the organization of the 2017 edition. This was what made me write tests for PHP and made me not only a contributor to PHP but also a PHPUnit contributor. In the long run, this brought me my first ElePHPant 🐘!
Florian is a father of five, developer, architect, tech lead, geek and still sometimes finds time to contribute to open source. He started writing software with PHP in September 2000 and will try to convince you to use vim. @realFlowControl
7 PHPUnit: https://phpunit.de/
8 PHP TestFest: https://phptestfest.org/start/#whos-behind-this
9 Ben Ramsey: https://twitter.com/ramsey
SECRET WEAPON!
Exception, uptime, and cron monitoring, all in one place and easily installed in your web app. Deploy with confidence and be your team’s devops hero.
Are exceptions all that keep you up at night?
Honeybadger gives you full confidence in the health of your production systems.
DevOps monitoring, for developers. gasp!
Deploying web applications at scale is easier than it has ever been, but monitoring them is hard, and it’s easy to lose sight of your users. Honeybadger simplifies your production stack by combining three of the most common types of monitoring into a single, easy to use platform.
Exception Monitoring Uptime Monitoring Check-In Monitoring Delight your users by Know when your external Know when your background proactively monitoring for services go down or have jobs and services go missing and fixing errors. other problems. or silently fail.
Start Your Free Trial Today
How to Hack your Home with a Raspberry Pi - Part 4
Ken Marks
Welcome back to another installment of How to Hack your Home with a Raspberry Pi*. At the end of this article, you will have an accelerometer data plotting application running on your Raspberry Pi. You will need to start from the beginning of the series if you want to build this project yourself.
Introduction
Here’s what we’ve covered so far in parts 1 thru 3:
-
Part 1:
-
My motivation for this project
-
Components needed
-
Installing the OS on the Pi
-
Configuring the Pi
-
-
Part 2:
-
Updating the software packages on your Pi
-
Installing and testing the LAMP Stack
-
-
Part 3:
-
Connecting the accelerometer
-
Creating the database for storing accelerometer data
-
Compiling a C/C++ program that reads accelerometer data and logs it to the database
-
Creating a Unix Service to automatically start and stop logging In this installment we will:
-
-
build a web service that uses the logged accelerometer data
-
and build an application that plots the accelerometer data
Power Up Your Pi and Remotely Log in
Ensuring your accelerometer is properly connected to your Raspberry Pi (see part 3), connect the power supply to your Pi and plug it into A/C mains.
Ssh Into Your Pi
After a few minutes of letting the Pi power-up, bring up a terminal window on your computer. Next, SSH into your Pi with the user pi by typing the following command into the terminal:
ssh pi@raspberrypi.local
Enter your password. You should now be logged in to your Raspberry Pi.
Update the Packages
I’ll first check to see if any software packages need upgrading on the Pi using the apt package manager and run the following two commands in the terminal window:
sudo apt update
sudo apt upgrade
###### Building a Web Service
We ultimately want to build a web application that plots the accelerometer data in real time. So first, let’s create a simple REST service with a single endpoint that provides the following two mechanisms for reading the accelerometer data:
-
Getting the newest accelerometer data and its id
-
Getting all the accelerometer data starting with the next newest row of data after the id sent, all the way up to the newest data along with the newest accelerometer data’s id.
💡 What is REST? REST[1] stands for REpresentational
State Transfer. If this acronym isn’t confusing enough,
we have many alternative names for it such as RESTful service, web API, or web service. At the great risk of giving an oversimplified definition, REST is a means of transferring data (typically defined as a noun in the URI) using HTTP verbs representing the intent of what we are doing with the data. Going forward, I will refer to this as a web service. We use web services to expose an API for accessing a CRUD object (another acronym meaning Create, Read, Update, and Delete, which is a code wrap- per for accessing our database tables).
Since all we need from our web service is to retrieve data,
we will only use the HTTP verb GET. When a client makes
an HTTP GET request to our service, we’ll return a JSON[2]
payload containing the accelerometer data, making it really
flexible for any programming language to interact with this
service. For example, I could create an application entirely in
PHP using Guzzle[3] or in JavaScript using AJAX to interact
with the web service.
Accelerometer Data Web Service Api
Table 1.
HTTP Verb CRUD Action
POST Create record
GET Read record(s)
PUT Update record
DELETE Delete record
We won’t require any authentication to keep it simple, and we won’t worry about versioning our service either. As mentioned, there is just one endpoint, and we will create it at the following location to interact with our web service:
http://raspberrypi.local/accelerometerservice/
The first time we call our service, we want to get the latest accelerometer data, so we will send an HTTP GET request without any parameters as shown in Table 2 row 1. We want the JSON data we get back to contain the latest accelerometer reading, its timestamp, and its ID. See Listing 1. Then we can plot this data point in the plotting application we will create using the timestamp. Remember, our accelerometer logging service is saving data every 100 milliseconds. Therefore, we will use the last``` MeasurementId as an input parameter the next time we request
Table 2.
**HTTP**
**Verb** **Endpoint**
GET http://raspberrypi.local/accelerometerservice/
GET http://raspberrypi.local/accelerometerservice/
_2_ _[JSON: https://www.json.org/json-en.html](https://www.json.org/json-en.html)_
_3_ _[Guzzle: https://docs.guzzlephp.org/en/stable/](https://docs.guzzlephp.org/en/stable/)_
Listing 1.
- “accelerationData”: {
- “accelerationMeasurements”: [
- {
- “axis”: {
- “X”: “0.199219”,
- “Y”: “-0.182617”,
- “Z”: “0.943359”
- },
- “dateTime”: “2022-03-02 15:00:46.631”
- }
- ],
- “lastMeasurementId”: “171695”
- }
|Accelerometer Data Web Service Api|Col2|
|---|---|
|Table 1.||
|HTTP Verb|CRUD Action|
|POST|Create record|
|GET|Read record(s)|
|PUT|Update record|
|DELETE|Delete record|
|||
Listing 2.
- “accelerationData”: {
- “accelerationMeasurements”: [
- {
- “axis”: {
- “X”: “0.203125”,
- “Y”: “-0.177734”,
- “Z”: “0.947266”
- },
- “dateTime”: “2022-03-02 15:00:46.746”
- },
- …
- {
- “axis”: {
- “X”: “0.200195”,
- “Y”: “-0.185547”,
- “Z”: “0.948242”
- },
- “dateTime”: “2022-03-02 15:00:56.625”
- }
- ],
- “lastMeasurementId”: “171795”
- }
data from the web service to get all the data points since the
above request.
For our next call to our service, we will send an _HTTP_
_GET request (Table 2 row 2) with the lastMeasurementId as a_
parameter to get all the data since our last request.
We want the JSON data we get back to contain all the accelerometer data since the last request and the newest reading’s
ID as shown in Listing 2.
If this request is exactly 10 seconds since the last request,
we should have 100 measurements in the JSON payload.
###### Creating the Accelerometer Data Web Service
I have created a PHP web service containing the endpoint
script and a CRUD wrapper class to retrieve the acceleration
data from the database and convert it into a JSON payload to
be sent to the requesting client.
|HTTP Verb|Endpoint|Parameter|
|---|---|---|
|GET|http://raspberrypi.local/accelerometerservice/|[none]|
|GET|http://raspberrypi.local/accelerometerservice/|lastMeasurementId|
9.
10.
Table 2. `11.`
12.
**HTTP** `13.`
**Verb** **Endpoint** **Parameter** `14.`
15.
GET http://raspberrypi.local/accelerometerservice/ [none] `16.`
17.
GET http://raspberrypi.local/accelerometerservice/ lastMeasurementId
18.
19.
-----
_Download the Accelerometer Service Scripts_
In the terminal window, within your `Downloads folder,`
download the `accelerometerservice.zip[4] file to your Pi`
using wget:
cd ~/Downloads/ wget https://www.phparch.com/downloads/accelerometerservice.zip
In the terminal window, unzip the `accelerometerservice.`
zip file and move the accelerometerservice folder to the /var/ www/html/ folder: unzip accelerometerservice.zip sudo mv accelerometerservice/ /var/www/html/
The web service contains the scripts shown in Table 3.
And our web service endpoint is now located at: `http://`
raspberrypi.local/accelerometerservice/
_accelerometerdata.php_
First, let’s take a look at AccelerometerData.php in Listing 3.
This class is for fetching data from a database table into
an object. You can see that the properties in this class match
the fields in the accelerometer_data table in the Accelerom**eterData database. Each object of this class will represent a**
row from a query into the table. I’ve added magic getters and
setters and a __toString() method for completeness, but we’ll
just be using the magic getter.
_accelerometerdatamanager.php_
Listing 4 is our CRUD wrapper the `AcelerometerDataMan-`
ager class. This class has two public methods:
Table 3.
**File Name**
AccelerometerData.php
AccelerometerDataManager.php
index.php
_4 accelerometerservice.zip:_
_[https://www.phparch.com/downloads/accelerometerservice.zip](https://www.phparch.com/downloads/accelerometerservice.zip)_
Listing 3.
- class AccelerometerData
- {
- private $id;
- private $created;
- private $axis_x;
- private $axis_y;
- private $axis_z;
- // Get/Set
- public function __get($ivar)
- {
- return $this->$ivar;
- }
- public function __set($ivar, $value)
- {
- $this->$ivar = $value;
- }
- // Serialize
- public function __toString()
- {
- $format =
- “
Id: %s
Created: ” - . “%s
X: %s
Y: ” - . “%s
Z: %s
”; - return sprintf(
- $format,
- $this->__get(‘id’),
- $this->__get(‘created’),
- $this->__get(‘axis_x’),
- $this->__get(‘axis_y’),
- $this->__get(‘axis_z’)
-
); - }
- }
|Table 3.|Col2|
|---|---|
|File Name|Description|
|AccelerometerData.php|Class wrapper for accelerometer_data table data|
|AccelerometerDataManager.php|CRUD manager wrapper for retrieving data from the aceler- ometer_data table and packaging it up into a JSON payload|
|index.php|Web service entrypoint|
|||
- `readLatest() retrieves the newest accelerometer data,`
including its id
-----
Listing 4.
- require_once(‘AccelerometerData.php’);
- class AccelerometerDataManager
- {
- const HOST = “localhost”;
- const DB = “AccelerometerData”;
- const USER = “accelerometer”;
- const PW = “accelerometer”;
- public function readLatest()
- { … }
- public function readFromIdToLatest($id)
- { … }
- private function
- getJsonEncodedDataFromAccelDataObjects(
- $accelDataObjects
- )
- { … }
- }
- `readFromIdToLatest($id) retrieves all the accelerometer`
data since the id (passed in as a parameter) and the
newest id. If the id is not found in the table (due to it
being deleted because it’s older than 60 seconds), return
all 60 rows of the accelerometer data.
The class also has one private utility method:
- `getJsonEncodedDataFromAccelDataObjects($accelData-`
Objects) that we will use to create a nested associative
array from the accelerometer data and convert it into a
_JSON payload._
Let’s take a look at the getJsonEncodedDataFromAccelDataOb```
jects() (Listing 5) method first.
The parameter,$accelDataObjects, is an array of one or more AccelerometerData objects fetched from the accelerometer_data table. The foreach() loop builds a nested associative array (called
$measurements) containing the accelerometer data from the
array of AccelerometerData objects.
After processing all of the accelerometer data, we will
continue to build the nested associative array by creating
an array called $accelerationData with a key of accelera-
tionData. The key contains another array with two key/value
Listing 5.
1. private function
getJsonEncodedDataFromAccelDataObjects($accelDataObjects)
2. {
3. $measurements = array();
4.
5. foreach ($accelDataObjects as $accel)
6. {
7. $measurements[] =
8. array(
9. 'axis' =>
10. array(
11. 'X' => $accel->axis_x,
12. 'Y' => $accel->axis_y,
13. 'Z' => $accel->axis_z
14. ),
15. 'dateTime' => $accel->created
16. );
17. }
18.
19. $accelerationData =
20. array(
21. 'accelerationData' =>
22. array(
23. 'accelerationMeasurements' => $measurements,
24. 'lastMeasurementId' => $accel->id
25. )
26. );
27.
28. return json_encode($accelerationData, JSON_PRETTY_PRINT);
29. }
pairs: accelerationMeasurements containing the $measure-
ments array as a value, and lastMeasurementId containing the
value of the last ID processed from the AccelerometerData
object array(which will be the newest reading).
Finally, we call json_encode() to convert the completed
associative array $accelerationData into a pretty printed
JSON payload and return it to the calling method.
Let’s take a look at the readLatest() method in Listing
6, which will return the newest accelerometer data reading
along with its primary key ID.
Using PDO, we create a connection to the Accelerome-
terData database and we will handle exceptions. Next, we
will query the newest row of data in the accelerometer_data
table and fetch the results into an array of AccelerometerData
objects — there should only be one object in the array. If
something goes wrong with the query, we will return 0 to the
calling function. We pass this AccelerometerData object array
to the getJsonEncodedDataFromAccelDataObjects() method
and return the JSON payload to the calling function.
Finally, let’s look at the readFromIdToLatest($id) method in
Listing 7 which will return all the accelerometer data readings
since the reading specified by the $id parameter.
This method takes an ID corresponding to a row in the
accelerometer_data table. Using PDO, we create a connec-
tion to the AccelerometerData database, and we will handle
exceptions. Next, we will query all the newest rows of data
in the accelerometer_data table greater than the $id passed
in and fetch the results into an array of AccelerometerData
objects. Notice we are preparing and binding our incoming
$id to :id to prevent SQL injection. If something goes wrong
with the query, we will call the readLatest() method to return
the newest accelerometer data reading. Finally, we pass this
AccelerometerData object array to the getJsonEncodedDataFromAccelDataObjects() method and return the JSON payload to
the calling function.
index.php
index.php (Listing 8) serves as the entry to our web service
endpoint. First we grab the HTTP REQUEST method from
$_SERVER['REQUEST_METHOD']. Next, we instantiate an Acceler
ometerDataManager object. Then we will switch on $httpVerb.
We will only process HTTP GET requests and throw an
Unsupported HTTP request exception for anything else.
Listing 7.
1. public function readFromIdToLatest($id)
2. {
3. $retVal = NULL;
4.
5. $db = new PDO("mysql:host=" . self::HOST . ";dbname="
6. . self::DB, self::USER, self::PW);
7. $db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
8.
9. // Get the 'created' date from the given id
10. $sql = "SELECT id, created, axis_x, axis_y, axis_z "
11. . "FROM accelerometer_data WHERE id > :id "
12. . "ORDER BY id";
13.
14. try
15. {
16. $query = $db->prepare($sql);
17. $query->bindParam(":id", $id, PDO::PARAM_INT);
18. $query->execute();
19.
20. $results = $query->fetchAll(
21. PDO::FETCH_CLASS,
22. "AccelerometerData"
23. );
24.
25. if (is_array($results) && count($results) >= 1)
26. {
27. return
28. $this->getJsonEncodedDataFromAccelDataObjects($results);
29. }
30. else
31. {
32. // Just get the latest reading
33. $retVal = $this->readLatest();
34. }
35. }
36. catch(Exception $ex)
37. {
38. echo "{$ex->getMessage()}<br/>\n";
39. }
40.
41. return $retVal;
42. }
Listing 6.
1. public function readLatest()
2. {
3. $retVal = NULL;
4.
5. $db = new PDO("mysql:host=" . self::HOST . ";dbname="
6. . self::DB, self::USER, self::PW);
7. $db->setAttribute(PDO::ATTR_ERRMODE,
8. PDO::ERRMODE_EXCEPTION);
9.
10. // Get the latest measurement
11. $sql = "SELECT id, created, axis_x, axis_y, axis_z "
12. . "FROM accelerometer_data "
13. . "ORDER BY id DESC LIMIT 1";
14.
15. try
16. {
17. $query = $db->prepare($sql);
18. $query->execute();
19.
20. $results = $query->fetchAll(PDO::FETCH_CLASS,
21. "AccelerometerData");
22.
23. if (is_array($results) && count($results) == 1)
24. {
25. return $this->
26. getJsonEncodedDataFromAccelDataObjects($results);
27. }
28. else
29. {
30. $retVal = 0;
31. $retVal = json_encode($retVal, JSON_PRETTY_PRINT);
32. }
33. }
34. catch(Exception $ex)
35. {
36. echo "{$ex->getMessage()}<br/>\n";
37. }
38.
39. return $retVal;
40. }
Once we’ve determined the request method is an HTTP GET,
we will send an HTTP header
with the content type of
application/json, so the
client’s browser knows to
expect a JSON payload. If
a query parameter named
lastMeasurementId is passed
in we will call the readFromId``` ToLatest() method passing
in the query parameter
contained in `$_GET['last-`
`MeasurementId'].` Otherwise,
we will call the `readLatest()`
method. Both of these
methods will return a _JSON_
payload which is echoed out
to the client.
###### Testing Our Web Service
We have several ways we
can test our web service to see
if we’re getting the expected
_JSON payload:_
Listing 8.
- require_once(“AccelerometerDataManager.php”);
- $httpVerb = $_SERVER[‘REQUEST_METHOD’]; // POST, GET, PUT, DELETE, …
- $accelerometerDataManager = new AccelerometerDataManager();
- switch ($httpVerb)
- {
- case “GET”:
- // Read
- header(“Content-Type: application/json”);
- if (isset($_GET[‘lastMeasurementId’])) // Read (by lastMeasurementId)
-
{ - echo $accelerometerDataManager->readFromIdToLatest($_GET[‘lastMeasurementId’]);
-
} - else
-
{ - echo $accelerometerDataManager->readLatest();
-
} - break;
- default:
- throw new Exception(“Unsupported HTTP request”);
- break;
- }
Figure 1.
Bring up a browser tab on your local computer and navigate to `http://raspberrypi.local/accelerometerservice/.`
You should see a JSON payload that returns the newest accelerometer data and looks something like Figure 1.
Notice the `lastMeasurementId and its value. We will use`
this as a query parameter in our next request to query all the
accelerometer data since this request.
Assuming less than 60 seconds have transpired,
bring up another tab in your browser and navigate to
http://raspberrypi.local/accelerometerservice/?lastMeasurementId=41820. You should see a JSON payload that returns
all the newest accelerometer data since the lastMeasurementId
and looks something like Figures 2 and 3.
Now, I’ll show you how to use curl to test your web service
if you have it installed as a command-line utility. Open up
a terminal window on your local computer and type the
following command:
curl —location —request
GET ‘http://raspberrypi.local/accelerometerservice’
💡 NOTE: When we request all the data
_since this last request, keep in mind that the_
accelerometerdatalogging.service is only storing
_60 seconds worth of data. So if you request all the data_
_since the lastMeasurementId and more than 60 seconds_
_have passed, you will retrieve the latest 60 seconds worth_
_of accelerometer measurement data. This web service_
-----
In Figure 4, you should see the JSON payload returned. If
you like, you can repeat this command with the query parameter added onto the end of the URL to get all the newest
measurement data since the lastMeasurementId.
###### Building a Plotting Application
Now that we know our accelerometer data web service is
working, we will build a client-side web application using
JavaScript that makes an AJAX call to the web service to get
the latest accelerometer entries every second. We will use
_Smoothie Charts[5] (a JavaScript charting library) to plot the_
accelerometer data in real time.
_Download the Accelerometer Plotting Application Scripts_
In the terminal window, within your `Downloads folder,`
download the accelerometer.zip[6] file to your Pi using wget:
cd ~/Downloads/ wget https://www.phparch.com/downloads/accelerometer.zip
In the terminal window, unzip
the accelerometer.zip file and move
the `accelerometer folder to the`
/var/www/html/ folder:
unzip accelerometer.zip sudo mv accelerometer/ /var/www/html/
The plotting application contains the following scripts
shown in Table 4.
Our accelerometer plotting application is now located at:
http://raspberrypi.local/accelerometer/.
I’m not going to go through the `smoothie.js library, but`
if you want to know more, a ten-minute tutorial[7] shows
you how easy it is to use. And a configuration tool called
_Smoothie Charts Builder[8] allows you to set various options_
and generates the HTML and JavaScript you need for these
options.
_5_ _[Smoothie Charts: http://smoothiecharts.org](http://smoothiecharts.org)_
_6_ _accelerometer.zip:_
_[https://www.phparch.com/downloads/accelerometer.zip](https://www.phparch.com/downloads/accelerometer.zip)_
_7_ _[ten-minute tutorial: http://smoothiecharts.org/tutorial.html](http://smoothiecharts.org/tutorial.html)_
_[8 Smoothie Charts Builder: http://smoothiecharts.org/builder/](http://smoothiecharts.org/builder/)_
|File Name|Description|
|---|---|
|smoothie.js|Smoothie Charts library script|
|index.html|Main page that displays the canvas containing the real-time plot of accelerometer data|
|js_get_server_name.php|PHP script for returning the name of the server to an AJAX call for proper URL construc- tion|
|acceleration.js|Contains functions for getting the latest accelerometer data from the web service and plotting it to a canvas using Smoothie Charts|
Table 4. `unzip`
sudo
**File Name** **Description**
smoothie.js Smoothie Charts library script
Main page that displays the
index.html canvas containing the real-time
plot of accelerometer data
PHP script for returning the
name of the server to an AJAX
js_get_server_name.php
call for proper URL construc-
tion
Contains functions for getting
the latest accelerometer data
acceleration.js from the web service and _5_
plotting it to a canvas using _6_
Smoothie Charts
_7_
Figure 2. JSON payload part 1
-----
However, I want to walk through the rest of the scripts with
you so you understand how our plotting application works
and integrates with our web service.
_NOTE: Smoothie Charts has many options not covered in_
_the Smoothie Charts Builder. You will need to peruse the_
_well-documented smoothie.js library to find them._
_index.html_
I will again use the Bootstrap[9] CSS framework for our
_Accelerometer Data page. See Listing Listing 9._
We’re starting out with a typical boilerplate Bootstrap web
page. The things I want you to note are we need a canvas:
Our canvas will be a fixed height of 100 pixels and responsive to the width of the canvas.
Next, we need to include JQuery because we will be making
some AJAX calls to use our web service:
Then we need to include our `smoothie.js library and our`
acceleration.js script containing our functions:
And lastly we need to call our `plotAccelerometerData()`
function:
_js_get_server_name.php_
This script will return the name of the server as JSON to an
AJAX call from the acceleration.js script and will be used to
construct the URL to the web service endpoint:
Listing 9.
-
-
-
-
Accelerometer Data
-
-
-
integrity="sha384-ka7Sk0Gln4gmtz2MlQnikT1wXgYsOg+OMhuP+IlRH9sENBO0LRn5q+8nbTov4+1p" -
crossorigin="anonymous"></script> -
integrity="sha256-/xUj+3OJU5yExlq6GSYGSHk7tPXikynS7ogEvDej/m4=" -
crossorigin="anonymous"></script> - plotAccelerometerData();
…
_9_ _[Bootstrap: http://getbootstrap.com](http://getbootstrap.com)_
-----
Listing 10.
- let Server =
- {
- url: ""
- }
- let AccelerometerData =
- {
- lastId: 0
- }
Listing 11.
function getLatestAccelerometerData( axis_x, axis_y, axis_z) { … } function plotAccelerometerData() { … }
Listing 12.
- function plotAccelerometerData () {
- $.getJSON(‘js_get_server_name.php’,
- function (data) {
- Server.url = ‘http://’
-
+ Server.server_name -
+ '/accelerometerservice/'; - });
- …
- }
property to point to our web service with the endpoint URL:
http://raspberrypi.local/accelerometer/.
Next, we need to specify the plot lines for each axis of
accelerometer data. Smoothie Charts requires us to create a
TimeSeries object for each plotline: function plotAccelerometerData() { … let x = new TimeSeries(); let y = new TimeSeries(); let z = new TimeSeries(); … }
Then we will call `setInterval(), which will call the`
`getLatestAccelerometerData()` function every
one second, passing in the time series objects
for each axis. `getLatestAccelerometerData()`
will retrieve one second’s worth of accelerometer data and
append it to the time series objects. See Listing 13.
In Listing 14 we will instantiate our SmoothieCart object.
We will set our chart to be responsive, so when we resize
the width of our canvas, the chart will adjust accordingly.
We also set the `grid parameters and` `labels. You can exper-`
iment with some of these settings using the Smoothie Charts
One reason for this is similar to the BOM in a file. When a
script is imported using require or include and there happens
to be a space after ?>, it could trigger output in the including
file before it has properly emitted its headers, resulting in
the dreaded Headers already sent error. It might also add
unwanted whitespace during output. In the browser, that is
less likely to create a problem as the space is invisible and
doesn’t impact the index like a non-breaking space ( ). But if
a download file is generated (like a TAB file), then that could
easily introduce unexpected behavior in the consumer of that
file.
Code MUST use an indent of 4 spaces for each indent level, and MUST NOT use tabs for indenting.
This rule is a classic long-running debate among developers. Luckily, an IDE will usually allow you to set the number of spaces representing a tab, so you can just strike the TAB key easily, and the IDE inserts spaces. Mixing spaces with tabs can be handled elegantly by an IDE, leaving the user unaffected as the code looks properly formatted. But version control software, like Git, handles whitespace differently. A
space followed by a TAB in an IDE appears as if it were only a
single TAB, but version control would see the difference and consider it a change. While not impacting the functionality of the code, it can present as cognitive friction when another developer is reviewing the code. Figure 3 shows TAB characters used instead of spaces and a space added before the TAB. There is no visual difference in the IDE and no real issue.
Figure 3.
The screenshot in Figure 4 is taken from a diff on Github. Note Line 10 now shows a space added before the tab and the line is considered changed.
PSR 12 Extended Coding Style Standard
Figure 4.
Again, this isn’t terrible either, but it highlights the potential confusion of mixing spaces and tabs. While you may not see it in the IDE, the diff tool noticed.
Conclusion
I have only highlighted the rules from PSR-12 that I believe can impact the developer’s experience when it comes to tooling and collaboration. There are many more rules in PSR-12[1] that I recommend reviewing. Discuss them with your team to decide which ones to follow, and write up your own style guide for new members. If it’s in the team style guide, it’s established, and development can continue. This up-front work eliminates wasting time and effort debating whether a rule from PSR-12 should be implemented. Admittedly, styling PSRs are not as impactful as other PSRs, but they are significant in terms of collaboration and should be considered just as important.
Frank Wallen is a PHP developer and tabletop gaming geek (really a gamer geek in general). He is also the proud father of two amazing young men and grandfather to two beautiful children who light up his life. He lives in Southern California and hopes to one day have a cat again. @frank_wallen
Related Reading
• PSRs - Improving the Developer Experience by Frank Wallen, March 2022. https://phpa.me/wallen-mar-2022
- Mentoring and Teaching PHP by Ken Marks, July 2021
https://phpa.me/teaching-php-2021
Figure 4.
- Working with PHP Streams by Chris Tankersley, January 2021 http://phpa.me/education-jan-21
1 PSR-12: https://www.php-fig.org/psr/psr-12/
Figure 3.
Tech is Taking Sides
Beth Tucker Long
Throughout history, industries have stayed relatively neutral during wartime. Global companies, especially, may offer marketing-focused messages of hope and concern but keep their heads down and their tones neutral when faced with actually taking a stand against one side of a conflict. Per usual, though, the tech industry is happy to disrupt the status quo—not just taking a clear stand but putting their money and their talent where their mouth is.
Global industries have long been accused of profiting off of war by selling to all sides, especially those in manufacturing and raw materials. Tech companies around the world, though, are taking a defined stand and even putting aside opportunities to profit as they take sides in the current conflict between Ukraine and Russia. SpaceX has donated Starlink Internet communications systems to keep people in Ukraine connected to the internet. AT&T, Verizon, T-Mobile, and Vodafone have all waived fees for services involving Ukraine—some waiving roaming charges for customers in Ukraine, some waiving international call fees for calls to and from Ukraine. Apple has halted all sales through its Russian online store, shut down Apply Pay access in Russia, and has disabled traffic and incident reports within Ukraine in Apple Maps. Google, likewise, has disabled live traffic reports for Ukraine in Google Maps, blocked Russian state-sponsored media channels on YouTube, and paused ad sales in Russia. Microsoft has stopped sales to Russia, and even Netflix has gotten involved, suspending their services in Russia. Even companies that are trying to just carry on with business-as-usual are having trouble staying uninvolved. Despite not taking a public stand in the matter, Coinbase, Patreon, and many other fundraising, financial, and social media platforms have found themselves in the spotlight as their platforms are being used heavily to support various organizations involved in the Russia-Ukraine conflict. It is no longer easy to keep your head down and stay neutral. Outside of work, the tech community is also getting involved. Over 300,000 programmers have volunteered to become an “IT Army” on behalf of Ukraine, taking down key Russian websites and online services through coordinated DDoS attacks, reporting disinformation on social media platforms, and creating digital marketing campaigns to bring awareness to the conflict. Anonymous has claimed credit for hacking Russia’s television networks to broadcast footage from Ukraine and for accessing the corporate systems of Rosatom, Russia’s state corporation for nuclear energy, after they claimed ownership of a Ukrainian nuclear power plant. Regardless of the outcome of this conflict, it is no longer isolated and localized. People around the world are getting
involved. Strangers are fighting together while sitting in their living rooms halfway around the world from each other. One thing is abundantly clear—tech has drastically changed the landscape of war.
Beth Tucker Long is a developer and owner at Treeline Design, a web development company, and runs Exploricon, a gaming convention, along with her husband, Chris. She leads the Madison Web Design & Devel- opment and Full Stack Madison user groups. You can find her on her blog (http://www. alittleofboth.com) or on Twitter @e3BethT
The book also walks you through building a typical Create-Read- Update-Delete (CRUD) application. Along the way, you’ll get solid, practical advice on how to add authentication, handle file uploads, safely store passwords, application security, and more.
Available in Print+Digital and Digital Editions.
Learn how to build dynamic and secure websites.
The book also walks you through building a typical Create-Read- Update-Delete (CRUD) application. Along the way, you’ll get solid, practical advice on how to add authentication, handle file uploads, safely store passwords, application security, and more.
Purchase Your Copy
https://phpa.me/php-development-book
SECRET WEAPON!
Exception, uptime, and cron monitoring, all in one place
and easily installed in your web app. Deploy with confidence and be your team’s devops hero.
Are exceptions all that keep you up at night?
Honeybadger gives you full confidence in the health of your production systems.
DevOps monitoring, for developers. gasp!
Deploying web applications at scale is easier than it has ever been, but monitoring them is hard, and it’s easy to lose sight of your users. Honeybadger simplifies your production stack by combining three of the most common types of monitoring into a single, easy to use platform.
Exception Monitoring Uptime Monitoring Check-In Monitoring Delight your users by Know when your external Know when your background proactively monitoring for services go down or have jobs and services go missing and fixing errors. other problems. or silently fail.