Second version of Circle CI configuration changed dramatically.
It introduced workflows, and they are used in pipes meaning.
Every workflow can include multiple steps.
This note begins a series of notes on application development and deployment processes. To start with, I will show how you can relatively easily implement a code quality and functionality checking process using the Travis CI service.
The practice of continuously checking the build for defects is called Continuous Integration.
The question of writing tests will not be addressed in this article - it is the subject of another article. It is assumed that you have already set up Behat, and the tests can already be run locally using Selenium.
To begin with, let's check if there are any rule violations in the code. This will allow you to familiarize yourself with and start using Travis CI. If you don't have any tests, I strongly recommend at least checking the code style.
The justification for the importance of code consistency and style can be found in many places, for example, Steve McConnell's "Code Complete", part 7, section 31.
When working with old code, it is sometimes very difficult to find the place where execution was interrupted. Constructions like die, exit, etc. are very bad practice, but there is a lot of legacy code (and not only - I'm not saying anything bad about Wordpress, so I'll keep quiet) that abuse them. One of the biggest problems with such constructions is that they are difficult to find and debug. (Use exceptions!)
But when the task is to find the place where code execution is interrupted, you can use the following snippet:
Repeatedly had to work with a list of dates on php (by days, for example) if there is a start and end of the period ($dateStart, $dateEnd). For example, to synchronize working/non-working days for the DatePicker from jQueryUi with the backend. Or if you need to display reports by days.
I suggest several options for solving this problem, both the most obvious way and a more elegant way (as it seemed to me).
About design patterns, all programmers have heard. Although... Based on the number of jokes about php developers and seeing some pieces of code, maybe some of them (php developers) have no idea what it is.
During the work with Symfony framework, I received the following warning:
Warning: date_default_timezone_get(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone. in /var/www/symfony/app/cache/prod/classes.php on line 5009
In fact, there is nothing to worry about or unusual - this was caused by updating PHP to version 5.4, and since the new version was installed next to the old one with new configs, it was necessary to configure the PHP timezone in php.ini again. First, we need to find out which timezone we are in. More precisely, how it should be specified in the PHP config.