Imagine you've developed an order processing service that stores information about the current user and collects items in a shopping cart. Everything works perfectly in a simple web application where each request is handled by a separate PHP process. But one day, the project requirements change.
Project development requires not only programming skills but also the ability to set up an effective working environment. In this article, I'll share my experience in creating a dev environment for PHP projects using Docker. I'll explain how to organize the file structure, configure Dockerfile and docker-compose.yml, and share useful tips on optimization and security. Whether you're working on a pet project or preparing for team development, these practices will help you create a reliable and flexible development environment.
This environment is based on my favorite and most frequently used tools:
When I worked on another project, I met an interesting opinion. They say, all the code in the project should be as open as possible by default. I.e. we should make all new methods and fields public, and we should not put final anywhere, except some special cases when it's really necessary. It was motivated with the difficulties of further codebase support:
If I want to inherit the class, and there is a private method, I have to study the code to understand why it was made
privateand whether I can make itpublic.
This opinion was very unusual for me, and I decided to figure it out if there is really more problems when fields and methods are private by default.
Let's write an extra public method and see how easy is it to support it.
interface FooInterface {
public function foo();
}
class Foo implements FooInterface {
public function foo() {
// do stuff
$this->bar();
// do stuff
}
public function bar() {
// do stuff
}
}
With this article, I open a rubric "Don't do this." It will contain code from real projects, from which I will remove all references to the projects themselves. And, of course, my explanations of why shouldn't you do this, and the way it should be done.
So, the first patient. Inside the trait, the fields of its descendants are used. I mean something like this:
trait Foo
{
public function bar(): string
{
return $this->field . static::CONSTANT . $this->method();
}
}
Note
Or even worse, $this->{$attribute}. But it's out of the question, as the chance of getting an error 500 rises to almost 100%.
Once upon a time, I put together a working environment with PHP, xDebug, Docker and PhpStorm. Since then, I have been dragging it from project to project and felt happy. For those who find it difficult to set up a local environment with Docker and xDebug, I am posting this config with explanations. Here below we will create a Docker image with xDebug installed, configure PhpStorm and explain a working configuration for Docker Compose.
A year ago, when I changed jobs, I didn’t even publish my resume. I acted like this from previous experience: every time opening a resume to the public, I had to communicate a lot with companies with which we obviously could not succeed. So I asked my friends what companies are currently looking for developers, knocked on a couple of doors and found a great place. Later, however, it turned out that we did not quite fit each other with this company, and I quit. I am sure that if I opened my resume, I would again, like a couple of years before, have to dig myself out of the responses of HRs. For me personally, things have changed a lot since then.
What are the worst mistakes in programming? I would single out two types:
While the first ones are immediately clear, what about the second ones? The fact is that the less often we encounter some type of error, the more difficult it is to understand what caused them.
This happened to me at work as well. One morning, the testers noticed that some requests to the backend returned a 502 (Gateway Timeout) error. This bug was a release stopper, so all the senior developers and a devops engineer took it up. At first, it was believed that Nginx returned this error, and the backend had nothing to do with it. After a while, we realized that PHP was to blame. We sinned for everything: turned off the BlackFire, changed OpCache settings, tried different patch versions in PHP, and so on. However, the error itself was not in the infrastructure, but directly in the application code.
The answer is definitely simple: use Docker 😃 Benefits I get from using PHP like this:
git pullNote
This article is about parsing the use of docker in one specific scenario, so if you are already familiar with this technology, you can safely skip it. The rest of you are welcome to the further reading.
When an IT product evolves, there always comes a time when it becomes necessary to bring some new tool into it or replace the old one with something more suitable. While it seems that a lot of articles have been written on the topic of choosing tools, and there is nothing new to say, the question still remains relevant, in some places even sharp.
Here are the most popular approaches:
They are good because you don't have to think when using them. You just take what you want - and that's it 😃 Well, if there is a need or a desire to approach the issue more seriously - welcome under the cut, we'll figure it out.
There are many architectural patterns in the development world. Some of them we use every day, some - less often. Surely each of you has seen the Singleton and the Factory many times. Many of you have written them on your own. But when I first read about the Builder pattern
