I want to tell you about GRASP principles.
If you are already familiar with OOP, and especially with SOLID, some of the ideas behind GRASP may look familiar. You may even realize that you have been using some of them in your work for years without knowing their specific names.
I ran into this topic while building my own application — the kind that gets installed on a user's site and works in tandem with a remote server. The scheme looked trivial at first glance: on installation, the module sends its domain and email to the server, the server registers a new client, generates a key pair, and returns it. From there, the module talks to the server, signing its requests with its own secret.
Everything looked simple right up until I started asking myself some uncomfortable questions.
Recently, I had to write documentation for a large project with a fairly complex structure.
Documentation itself doesn’t seem like such a difficult task anymore. With the help of AI, you can get a good understanding of even a large project relatively quickly. The important part is to clearly explain what you want to get as a result, plan the documentation structure, and provide the AI with enough context.
But there is another problem.
It’s not always convenient to describe a complex architecture using text alone.
Lately, I've been using OpusPlan quite a lot in Claude Code. In my opinion, it's one of the most convenient features when working with an agent on larger tasks.
The idea is simple: Opus is used for planning, while Sonnet handles the implementation once the plan is ready. And the switch between the two happens automatically.
I think this is a very logical approach.
Lately, I've been studying design patterns and architectural approaches, and I'm gradually starting to notice that many things I've been using in Laravel for years actually have specific names.
One of these patterns is Active Record.
Lately, I've been spending quite a lot of time learning about design patterns and software architecture.
And the deeper I go, the more often I come across two concepts that seem to be behind almost everything: coupling and cohesion.
They may sound abstract at first, but they actually describe two very practical things:
How strongly are different parts of the system dependent on each other, and how well do the responsibilities inside a component belong together?
For the last several years, MySQL has been my primary database.
PostgreSQL came up from time to time, but I never had a real reason to dive deeply into it.
That changed when I started working on a new project — an AI assistant. The project required PostgreSQL, JSONB, Full-Text Search, and, most importantly, pgvector for vector search.
After spending some time working with PostgreSQL more seriously, I realized that it is not just “another SQL database that is more or less like MySQL”.
Recently, I started learning Python a bit. It is a very popular programming language today, ranking among the top three most popular languages both in terms of the number of questions on various websites like Stack Overflow and the number of repositories on GitHub.
SOLID are programming principles that greatly help to write large applications, making them more flexible, extensible, while reducing the number of errors and conflicts, as well as the time and money to support and maintain this application in the future.
I became interested in the topic of telegram bots.
Wrote my first telegram bot using PHP, Laravel and Telegram Bot SDK