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:
- those that cause a business to lose a lot of money
- and those that are the least common.
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:
- No need to bother with setting up a local environment, switching PHP versions, installing additional libraries and resolving conflicts
- One text file with command line aliases is enough for any version of PHP to work on any computer. And from here
- Ease of transferring data between machines
- You can safely demolish the system on your main computer, restoring work with PHP will be as simple as
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:
- Find something hype on the left road
- Take something proven and reliable on the right road
- Go straight ahead and use your favorite tool
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
There is such a topic among us, IT people, which is usually avoided. The fact is that we are not able to work productively all day long. On the one hand, this is no secret to anyone. On the other hand, it is not customary to discuss it, and for some reason we think that no one but ourselves is in the know. In an ideal world, a programmer with good experience, thirty or forty years old, is quite capable of working a couple of hours a day with great efficiency, devoting the rest of the time to all sorts of routines: code reviews, communication with colleagues, task analysis, and so on. In the real world, procrastination lurks around every corner. No wonder one of the most popular memes in IT right now are memes about burnout.
The question of the area of responsibility of a particular class in a program architecture is no less important than architecture strategic planning. Today I will tell you how to make this job easier for yourself. We will solve a fairly large number of issues, leaving only two types of classes out of an infinite variety: DTO and Service. These types cover 90-99% of everything needed in any project. So, let's look at what they are, and why it's so good to leave only them.
We all use OpenSource products. Some of them we like.
And for those we like, we often want to help to become even better. One way to help is financially. But we ourselves are developers, and sometimes we imagine ourselves among the authors of a wonderful tool that we use with pleasure. At least that's how it used to be for me. And then the dream became a reality. If this is also a dream for you, you're welcome to the further reading: there is my story and the answer, how you can join to develop your favorite OpenSource tool too.