After this, I decided to investigate the pros and cons for the different options to store dates in a database. There are multiple articles about this topic. I want to highlight this article where it is explained with details, examples and benchmarks using MySQL. Next is a too short summary about the article:

• Using DATETIME allows to make SQL queries using functions related to dates(i.e: WEEKDAY in MySQL) in the SQL server. It allows to use dates from year 1000 to 9999. Queries over DATETIME are faster than queries over TIMESTAMP. The format used to print the DATETIME is user friendly and legible.
• Using TIMESTAMP also allows to make SQL queries using functions related to dates. It allows dates until 2038 only. TIMESTAMP is lighter and it saves 1 byte of storage compared with DATETIME. The format used to print the TIMESTAMP is user friendly and legible.
• Using UNSIGNED INT allows dates until 2106. It is not possible to use CURRENT_TIMESTAMP with this data type. SQL queries over INT are much faster than DATETIME and TIMESTAMP. To use date functions, the integer should be converted to a date(using function FROM_UNIXTIME in MySQL). In this case the SQL queries are slower than DATETIME.

One of the disadvantages with TIMESTAMP is the limit of 2038. Personally, I think that the SQL servers will change this in order to preserve compatibility with existing software using this datatype. It is not the same with INT because it is a datatype not intended to be used for dates. However there are integer types using more bytes of storage like BIGINT in MySQL.

After my experience using timestamps in a REST API, definitely I will use DATETIME in next projects unless performance and storage are critical. When you are debugging, readability matters. When you see a bunch of numbers that not make sense, then you need to expend time converting those numbers to readable dates. Also working in the frontend, sometimes I needed to understand why I was getting those dates and then again it was stressful to see unintelligible numbers in the API response.

In my opinion, using UNSIGNED INT has sense if the performance of the app is critical AND you have one or multiple queries that doesn’t require to use date functions and they are in processes that run frequently in the app.

The post Datetime or Timestamp: readability matters appeared first on Carlos Guzman.

There are multiple options that you could use for running phpunit tests automatically. In example, phpunit-watcher is a PHP script that you can install in your project easily through composer. In my case, I created watch-and-do, a bash script and it is now hosted in Github. Honestly I think I didn’t google it well and I didn’t find phpunit-watcher before. But let’s say that I wanted to learn and create a bash script.

A testing environment with WordPress configured and running is required in order to run tests for the WordPress plugin. In the official documentation of WordPress, you can find how to create the testing environment for your WordPress plugin.

The bash script is based on inotifywait to watch and detect changes in the code. This tool can use some filters to notify when a file is created, modified, deleted or moved only:

# listen for changes
inotifywait -m -r -q -e modify -e create -e delete -e move --format "%w%f %e" $WATCHDIR

When a change is detected, then the script waits for a couple of seconds before launching the tests. Sometimes I am editing multiple files and then I save all of them. With a delay in the script, the test are launched after the last saving instead launching the tests after saving each file:

# increase the stock
echo $(( $(cat $STOCK_FILE) + 1 )) > $STOCK_FILE

# sleep for a moment while more changes are detected
sleep $CHANGES_DETECTION_SLEEP

# decrease stock
echo $(( $(cat $STOCK_FILE) - 1 )) > $STOCK_FILE

# if stock is empty (this discard multiple execution)
if [ $(cat $STOCK_FILE) -eq 0 ]
then
    # run tests
    run_tests $@
fi

It is important to run the tests in a new process and store its PID because it is used to stop the process if required. Before launching the tests, it is possible that the tests are under execution due to a previous modification of a file. In order to not get conflicts and to not get a mess in the console, it is a good idea to stop the current execution of the tests. We stop the tests using the PID of the process and the kill command with signal SIGTERM. The tests are not stopped immediately, so it is important to wait until they have been stopped:

while [ $LASTPID ] && [ $LASTPID -gt 0 ] && (ps -p $LASTPID > /dev/null)
do
    # kill previous testing
    if [ $KILLING -eq 0 ]
    then
        KILLING=1    
        kill -SIGTERM $LASTPID
    fi

    # wait until previous tests are finished
    echo "Wait while current tests are stopped..."
    sleep $TESTS_KILLING_SLEEP
done

Finally, when previous tests have been stopped, the new tests are lunched and the PID of its process is stored. The command to run the tests is passed as an argument to the script. In this way the script is not attached to how phpunit is configured in the system:

# execute tests
echo "Running command: $@"
$@ &

# store the pid of the thread running the tests
echo $! > $PID_FILE

Using the script requires as arguments the folder to watch and the command to run the tests:

$ ./watch-and-do my-base-folder phpunit -v

As mentioned before, this script is just an alternative to other tools to watch for changes in your code and run the tests automatically. This bash script is open source and you can find it in Github as watch-and-do.

The post Running PHPUnit tests automatically appeared first on Carlos Guzman.

My first attempt to see the error logs was to login in a bash session it the Docker container. Then I searched for the error log file but the errors are sent to the I/O stream STDERR by default.

Instead to create a custom image to change this configuration, I tried with the Docker cli tool to access to the logs of the container. Using docker logs ID_CONTAINER, I was able to see the logs of the web server. It was progress but it wasn’t what I want. I got all logs entries of the web server including access and warning entries. It would be difficult to spot the error entries easily in a website loading multiple resources and doing multiple Ajax requests.

The solution

If we discard the output sent to the standard stream, then the access entries are gone. So using docker logs -f ID_CONTAINER >/dev/null, we get only the entries sent to the error stream. Most of the entries here are the useful entries for debugging, they are the warning and error messages. The option -f in docker logs command is to follow and refresh automatically the logs in the console.

Extra tip

If you want to see the error messages only without changing the error reporting directive, you can use the grep tool to filter the other entries. Using docker logs -f ID_CONTAINER 2>&1 >/dev/null | grep -i error, the entries are filtered to display only the lines with the error word in them. This command replaces the output of the standard stream with the output of the error stream. Then grep filters the content. The option -i in the grep command is to be case insensitive in the search.

Maybe it isn’t the most elegant but at least it is an effective way to see the error logs in WordPress with Docker.

The post How to see the error logs in WordPress with Docker in Linux appeared first on Carlos Guzman.