Виктор Кожухарь

В Go очень распространен подход с кодогенерацией. Он прост, не добавляет ненужную сложность, работает идеально.

План действий:

1. Создадим отдельный репозиторий с Go-модулем, который содержит:

• Базовый конфиг golangci-lint
  
• Маленькую консольную утилиту-генератор, которая пишет этот конфиг в ⁠.golangci.yml нашего проекта

  

2. Запустим этот модуль в каждом проекте через ⁠go run /cmd/genlint@version

3. Закрепим версию через теги: git tag v1.0.0

Таким образом нам в директории проекта понадобится только лишь запустить команду, которая нам сгенерирует конфиг-файл для линтера:

go run gitlab.com/your-company/go-lint-standards/cmd/genlint@v1.0.0 -out .golangci.yml

Таким образом мы даже можем в разных проектах поддерживать разные версии линтера, если нам это понадобится.

И ничего нам не помешает эту команду использовать прямо в Gitlab CI. Например, вот так:

stages:
    - lint

lint:
    stage: lint
    image: golangci/golangci-lint:v1.59.1
    script:
        - go run gitlab.com/your-org/go-lint-standards/cmd/genlint@v1.0.0 -out .golangci.yml
        - golangci-lint run -v --timeout 5m
    rules:
        - if: $CI_MERGE_REQUEST_IID

А для локальной разработки для простоты можно эту команду прописать в Makefile

Моё персональное мнение: скорость первоначальной загрузки страницы в виде, удобном для восприятия основной идеи сайта - это самое главное, что нужно в сегодняшнем мире.
Просто сами вспомните, когда вы долго ищете что-то очень нужное, кликая на ссылки в поисковике, как часто вы закрываете страницы, которые грузятся дольше нескольких секунд? Я очень часто так делаю, обычные люди тоже очень часто так делают.
Посыпав это всё приправой мобильного интернета, который иногда работает через раз в связи с определёнными событиями, скорость первой загрузки становится очень важной.

Некоторые даже идут в экстрим: дело в том, что первые 14 килобайт HTTP запроса загружаются и могут отображаться браузером практически мгновенно, остальные данные загружаются гораздо дольше. И вот некоторые пытаются в эти 14 килобайт запихнуть такие данные, которые позволят отобразить самые важные элементы страницы.

Поэтому, отложенная загрузка - это очень верное решение. Главное, постараться сделать её как можно более незаметной и плавной, нельзя делать "прыгающую" вёрстку. Ещё вам лайфхак, который я выстрадал сам: если подзагрузка данных не долгая, то лучше не отображать прогрессбары, спиннеры и т.д. Чисто психологически эти элементы вызывают ощущение тормознутости. И если запрос точно такое же время будет длиться без отображения спиннера, то он будет ощущаться быстрее. Это конечно, тонкий момент, и настравать нужно в каждом случае отдельно.

Насчёт типа рендеринга и "правильности" тут всё очень хорошо описал уважаемый VoidVolker . В каждом случае вы сами должны решить, как будет удобнее для пользователя. Лично я последнее время всё чаще использую гибридный рендеринг при помощи библиотеки HTMX

Тут нам надо просто подойти логически к вопросу. Понимаем, что RoadRunner держит приложение Symfony в памяти. Значит, в памяти будет находиться и сервис-контейнер со всеми инициализированными сервисами. Поэтому дефолтное подключение для Doctrine не подойдёт, потому что соединение упадёт, и оно будет выдавать ошибку.

Т.е. нам надо написать свою обёртку вокруг доктриновского класса, предоставляющего соединение с базой данных. И в этой обёртке мы и сделаем логику псевдо-пула соединений. А именно, перед каждым запросом будем пинговать соединение, и если оно мертво, то пробовать реконнектиться и продолжать запросы далее в случае успешного реконнекта. Это самое простое, но не самое эффективное решение.

1. Надеюсь, у вас уже установлен бандл для работы с Roadrunner

composer require spiral/roadrunner-bundle

2. Создаём вот эту вот обёртку над соединением

<?php
// src/DBAL/ConnectionWrapper.php

namespace App\DBAL;

use Doctrine\DBAL\Connection;
use Doctrine\DBAL\Driver;
use Doctrine\DBAL\Configuration;
use Doctrine\Common\EventManager;

class ConnectionWrapper extends Connection
{
    /**
     * @var int
     */
    private $reconnectAttempts = 3;

    public function __construct(array $params, Driver $driver, ?Configuration $config = null, ?EventManager $eventManager = null)
    {
        parent::__construct($params, $driver, $config, $eventManager);
    }

    public function prepare($sql)
    {
        $this->ping();
        return parent::prepare($sql);
    }

    public function executeQuery(string $sql, array $params = [], $types = [], ?QueryCacheProfile $qcp = null)
    {
        $this->ping();
        return parent::executeQuery($sql, $params, $types, $qcp);
    }

    public function executeUpdate(string $sql, array $params = [], array $types = [])
    {
        $this->ping();
        return parent::executeUpdate($sql, $params, $types);
    }

    public function ping(): bool
    {
        if ($this->isConnected() && $this->getWrappedConnection()->ping()) {
            return true;
        }

        $this->close();

        for ($i = 0; $i < $this->reconnectAttempts; $i++) {
            try {
                $this->connect();
                if ($this->getWrappedConnection()->ping()) {
                    return true;
                }
            } catch (\Exception $e) {
                // ещё разок
            }
        }

        throw new \RuntimeException("Unable to reconnect to the database.");
    }
}

3. Конфигурируем Доктрину, чтобы использовала нашу обёртку.

# config/packages/doctrine.yaml
doctrine:
    dbal:
        # обычные настройки
        url: '%env(resolve:DATABASE_URL)%'
        driver: 'pdo_mysql'
        server_version: '8.0'
        charset: utf8mb4
        default_table_options:
            charset: utf8mb4
            collate: utf8mb4_unicode_ci

        # наша обёртка
        wrapper_class: App\DBAL\ConnectionWrapper

4. Что ещё

• Обязательно очищайте EntityManager вручную после каждого запроса по API, или каждого большого действия, или что там у вас ещё. Иначе доктриновская Identity Map распухнет, и память будет течь как мороженное в пустыне.
  
• Не забывайте аккуратно обращаться с транзакциями и всегда их коммитить или откатывать.
  
• Продумайте, как лучше всего рестартовать сервис, если реконнект всё-таки не сработает.
  

5. Лучше, конечно, сделать всё через воркеры RoadRunner.

Это сложнее, но более правильно, если так можно выразиться. Тут уже сами разберитесь в документации к этим вот пакетам, там нужно повозиться.

composer require spiral/roadrunner-symfony
composer require spiral/roadrunner-doctrine

Но идея та же, нужно написать обёртку для Доктрины, плюс использовать воркер RoadRunner. Там будет уже более адекватный connection pool и т.д.

Откройте settings.json и попробуйте установить

{
  ...
  "explorer.autoReveal": false
  ...
}

Это не на все 100% то, что вы описываете, но, возможно, это вам поможет.

Для тех, кто не знает, как открыть settings.json:

- Нажмите `Cmd + Shift + P` (на macOS) или `Ctrl + Shift + P` (на Windows/Linux), чтобы открыть палитру команд.
- Если редактор на английском: Начните вводить `Preferences: Open User Settings (JSON)` и выберите этот пункт.
- Если редактор на русском: Начните вводить Параметры: Открыть пользовательские настройки (JSON) и выберите этот пункт.

Откроется файл, меняете значения, обязательно сохраняете его.

Проблема не в редакторе и не в коде, а в том, как вы код запускали. Команда

go run main.go

компилирует только один файл, отсюда и сыпались ошибки о неопределенных функциях.

Нужно было запускать

go run *.go

, чтобы собрать все файлы

Или по классике, как делает Goland:

go build -o app && ./app

Охх... Никогда не думал, что столкнусь с race condition в PHP )))
В других языках такое решают общим хранилищем данных для всех параллельных потоков и использованием мьютекса.

Мы же можем воспользоваться инструментами Redis, которые сделали специально для решения таких вещей. У Redis есть специальные флаги, позволяющие использовать атомарные операции. Команда SET с параметрами NX и EX.

• SET key value NX — установить ключ, только если он Not eXists (не существует).

  
• SET key value EX seconds — установить ключ с временем жизни (eXpire) в секундах.
  

Комбинация этих двух флагов позволяет создать атомарную операцию "захватить блокировку на N секунд".

handler.php

<?php

$redis = new Redis();
$redis->connect('127.0.0.1', 6379);

// 1. Создаем уникальный ключ для этого конкретного запроса
$lockKey = 'request_lock:' . md5(json_encode($_REQUEST));

// 2. Пытаемся захватить ключ на 10 секунд
// Эта команда атомарная: только один процесс из двух победит.
$isLockAcquired = $redis->set($lockKey, '1', ['nx', 'ex' => 10]);

if ($isLockAcquired) {
    // КЛЮЧ НАШ! Делаем свою работу
    try {
        // ... обращаемся к стороннему сервису, запускаем worker.php или ваще что угодно ...
        
        // отвечаем клиенту об успехе операции
        http_response_code(200);
        echo json_encode(['status' => 'success']);

    } catch(\Throwable $e) {
        // Освобождаем ключ для будущих запросов в случае ошибки, чтобы не ждать 10с для переотправки.
        $redis->del($lockKey);
        // отвечаем клиенту, что произошла ошибка
        http_response_code(500);
        echo json_encode(['status' => 'error']);
    }

} else {
    // КЛЮЧ УЖЕ КЕМ-ТО ЗАНЯТ. Ничего не делаем.
    // Просто отвечаем клиенту, что все ок или что запрос дублируется.
    http_response_code(429); // Too Many Requests
    echo json_encode(['status' => 'error', 'message' => 'Request already in progress']);
    exit;
}

Оборачиваем всё в транзакцию, да и всё. И тогда создадутся либо обе записи, либо ни одной. Так мы не расплодим сироток в случае ошибочных данных.

Модели:

<?php

namespace App\Models;

use Illuminate\Database\Eloquent\Factories\HasFactory;
use Illuminate\Foundation\Auth\User as Authenticatable;
use Illuminate\Notifications\Notifiable;

class User extends Authenticatable
{
    use HasFactory, Notifiable;

    /**
     * @var array<int, string>
     */
    protected $fillable = [
        'name',
        'email',
        'password',
    ];

    /**
     * Получить данные пользователя, связанные с этим пользователем.
     */
    public function userData()
    {
        return $this->hasOne(UserData::class);
    }
}

<?php

namespace App\Models;

use Illuminate\Database\Eloquent\Factories\HasFactory;
use Illuminate\Database\Eloquent\Model;

class UserData extends Model
{
    use HasFactory;

    /**
     * @var array<int, string>
     */
    protected $fillable = [
        'phone_number',
    ];

    /**
     * Получить пользователя, которому принадлежат эти данные.
     */
    public function user()
    {
        return $this->belongsTo(User::class);
    }
}

Создание записей

use App\Models\User;
use App\Models\UserData;
use Illuminate\Support\Facades\DB;
use Illuminate\Support\Facades\Hash;

DB::transaction(function () {
    // 1. Создаем пользователя (User)
    $user = User::create([
        'name' => 'Вася Пупкин',
        'email' => 'uasya@fsb.ru',
        'password' => Hash::make('12345'),
    ]);

    // 2. Создаем данные пользователя (UserData) и связываем их с пользователем
    $user->userData()->create([
        'phone_number' => '112',
    ]);
});

P.S. ИМХО: ненавижу Eloquent и весь паттерн Active Record. Как по мне, вместо него лучше уж просто чистым SQL пользоваться. А вот если нужна мощная ORM, то уж лучше воспользоваться Doctrine. Там вообще такой проблемы нет, и всё делается автоматически.

Go - язык, который сознательно создавался, как очень простой язык. В Go всегда всё копируется. Если это базовый тип, то копируется базовый тип, если это структура, то копируется структура, если это массив, то копируется весь массив, если это указатель, то копируется указатель. Если это дескриптор слайса, то копируется этот дескриптор (не сами данные). И нет этих внезапных указателей, которые могут испортить жизнь джаваскриптизёру или пыхарю.

Поэтому, в Go не надо зазубривать, какие операции что возвращают, а мы просто глядим в нашей мега-IDE, что конкретно нам возвращает time.Now()
А возсращает она нам очень простую структурку time.Time

type Time struct {
    wall uint64
    ext  int64
    loc  *Location
}

И что мы видим? Что из ссылок в этой структуре только loc, который занимается исключительно часовыми поясами, а само время хранится в обычных целочисленных переменных без всяких ссылок. А т.к., как мы говорили ранее, в Go всегда всё копируется, то внезапному указателю (ссылке) просто неоткуда взяться.

Если вы запамятовали, и сомневаетесь, что происходит при присваивании, например, слайса, мапы или интерфейса, то лучшим способом это определить будет не зазубривать, а изучить, как устроены слайс, мапа или интерфейс изнутри, и тогда вы сами всё поймёте. И сделать это будет несложно, потому что язык Go написан на языке Go и использует свои же примитивы для своих же структур данных.

Из всего вышеописанного мы делаем вывод, что не все книжки одинаково полезны даже для подтирания, не то что для изучения.

Я рекомендую вам самый лучший инструмент для первоначального вкатывания в Go - это официальный курс "A Tour of Go", где вы в интерактивном режиме изучите базовые основы языка за пару дней. А дальше уже можно смотреть на книги, и уже самому находить в них такие вот несуразности. Не стесняйтесь преходить прямо в IDE на типы или определения функций, чтобы самому смотреть, что же там возвращается. Так как, на наше счастье, Go - это строго-типизированный язык, то никаких сюрпризов и подвохов там не будет.

P.S. Нашёл отличную статью со списком материалов в дополнение: https://habr.com/ru/companies/selectel/articles/929858/

К сожалению, без хака тут не обойтись. Но если получен результат, то кому какое дело? Берем волшебную палочку и достаём кролика из шапки. Сплошная иллюзия и никакого мошенничества.

Опишу, как это сделать на Маке и Линуксе. Про Винду даже не спрашивайте, уже лет 7 как не помню.

Для работы с двумя аккаунтами GitLab с одной машины требуется настроить Git для использования разных SSH-ключей. Каждому аккаунту будет соответствовать свой ключ.

1: Создание отдельных SSH-ключей

Для каждого аккаунта GitLab необходим уникальный SSH-ключ. Если стандартный ключ (`~/.ssh/id_rsa`) уже существует, его можно оставить для первого аккаунта. Для второго аккаунта создаётся новый.

В терминале выполняется команда для генерации нового ключа. В ней `"email_второго_аккаунта@example.com"` заменяется на почту, привязанную ко второму аккаунту GitLab. При запросе имени файла нужно указать уникальное имя, чтобы не перезаписать существующие ключи.

# Имя id_gitlab_work можно заменить на любое другое
ssh-keygen -t ed25519 -C "email_второго_аккаунта@example.com" -f ~/.ssh/id_gitlab_work

В результате у нас будет две пары ключей:

• `~/.ssh/id_rsa` и `id_rsa.pub` (для первого аккаунта)
  
• `~/.ssh/id_gitlab_work` и `id_gitlab_work.pub` (для второго)
  

2: Добавление SSH-ключей в аккаунты GitLab

Далее публичные части ключей (`.pub`) добавляются в соответствующие аккаунты GitLab.

Для первого аккаунта это будет ~/.ssh/id_rsa.pub
Для второго аккаунта ~/.ssh/id_gitlab_work.pub

Кликаем на аватарку в gitlab, выбираем "Edit Profile" и в секции "SSH Keys" обоих аккаунтов добавляем соответствующие им публичные ключи

3: Настройка SSH-клиента

Чтобы система знала, какой ключ для какого репозитория использовать, настраивается файл конфигурации SSH. В нём создаются псевдонимы для `gitlab.com`.

1. Нужно открыть или создать файл `~/.ssh/config`.

Если его нет, создаём:
touch ~/.ssh/config

2. Открываем файл, добавляем конфигурацию, которая создаёт два «хоста», `gitlab.com-personal` и `gitlab.com-work`, которые оба ссылаются на `gitlab.com`, но используют разные файлы ключей.

# Первый аккаунт (например, личный)
Host gitlab.com-personal
  HostName gitlab.com
  User git
  IdentityFile ~/.ssh/id_rsa
  IdentitiesOnly yes

# Второй аккаунт (например, рабочий)
Host gitlab.com-work
  HostName gitlab.com
  User git
  IdentityFile ~/.ssh/id_gitlab_work
  IdentitiesOnly yes

4: Настройка локальных репозиториев

Теперь необходимо обновить URL-адреса удалённых репозиториев в локальных проектах, чтобы они использовали созданные псевдонимы.

1. В директории проекта для первого аккаунта выполняется команда для изменения URL.
Проверить текущий адрес: git remote -v
Заменить `gitlab.com` на псевдоним gitlab.com-personal:

git remote set-url origin git@gitlab.com-personal:username/repo.git

2. В директории проекта для второго аккаунта выполняется аналогичная команда, но с другим псевдонимом:

git remote set-url origin git@gitlab.com-work:otheruser/other-repo.git

При клонировании новых репозиториев следует сразу использовать адрес с нужным псевдонимом:

# Клонирование с первого аккаунта
git clone git@gitlab.com-personal:username/repo.git

# Клонирование со второго аккаунта
git clone git@gitlab.com-work:otheruser/other-repo.git

5: (Рекомендуется) Настройка автора коммитов

Чтобы коммиты в каждом репозитории подписывались правильными данными, а не глобальными настройками вашего git, следует задать имя и почту автора локально для каждого проекта.

В репозитории для первого аккаунта:

git config user.name "Имя для первого аккаунта"
git config user.email "email_первого_аккаунта@example.com"

В репозитории для второго аккаунта:

git config user.name "Имя для второго аккаунта"
git config user.email "email_второго_аккаунта@example.com"

После завершения настройки, при выполнении `git push` из разных директорий, Git будет автоматически использовать соответствующий ключ и данные автора.

А вы верстайте обе версии.
1. Верстаете английскую версию (потому что английский знают почти все, а русский знают не только лишь все)
2. Английскую версию вёрстки загружаете в любой ИИ, и он вам за секунду делает отличный перевод, который вам останется только немножечко подчистить. По моим наблюдениям ИИ щелкает фронтенд как семечки.

Всегда исходите от бизнеса. В зависимости от того, когда магазин нужен вашему бизнесу, у вас есть 2 варианта:

1. Если вы полгода согласовывали проект, потом полгода разрабатывали дизайн, логотип и радиусы скругления полей ввода, то нанимайте специалистов, и они напишут вам персонально для вас магазин, который будет решать именно ваши конкретные задачи. Это будет долго, но получите вы именно то, что хотели. Этот же вариант подойдёт, если магазин не будет являться основным либо значительным источником дохода вашего бизнеса, а будет скорей маркетинговым инструментом, продвижением бренда. Тут качество, производительность и стиль решают.

2. Если же вы уже упускаете значительную прибыль, магазин будет крупной долей бизнеса и он должен был быть ещё вчера, то берите что угодно, ваша задача продавать товары, а не выбирать самое лучшее и вылизывать его. Поэтому, берите то, что можно быстро запустить, у чего есть миллионы разработчиков и очень широкое распространение. И тут оптимальным будет Wordpress + WooCommerce. Если же именно интеграция с учётной программой является камнем преткновения, то выберите что-то, что имеет самую адекватную интеграцию с вашей программой. Наклепайте тему, за которую не будет очень сильно стыдно, и продавайте, продавайте, продавайте... А когда заработаете денег, уже можно подумать о том, чтобы вернуться к п.1.

В первую очередь надо смотреть на то, когда заканчивается поддержка у той или иной технологии. И у PHP 7.4 она закончилась ещё в 2022 году.

Это означает, что дыры в безопасности уже никто чинить не будет. А там их немало. И сайт будет всё проще и проще взломать с каждым новым днём.

Возможно, ваш хостер имеет возможность внедрять патчи расширенной поддержки от Zend, которые так же закончатся уже в 2026 году.

Поэтому, обновить стоит. Но перед этим надо убедиться в работоспособности сайта с этой версией.

1. Полный бэкап файлов и базы. Это даже не обсуждается. Если у хостера бэкап не купили, купите.

2. Обновите всё, что сможете до последних версий. Разработчики часто добавляют совместимость для новых версий PHP в эти последние версии. Это касается и ядра WordPress, и плагинов, и темы, если она была куплена, а не писалась с нуля. Если тему писали с нуля, то можно связаться с разработчиком, чтобы он дал вам точный ответ, будет ли тема работать, или сделал бы поддержку 8.3

3. После обновления плагинов и тем проверьте в их документации совместимость этих обновленных версий с PHP 8.3.

4. Используйте плагин проверки совместимости, чтобы узнать, будет ли ваш сайт работать на 8-х версиях PHP. Он старый, но именно с этой задачей поможет справиться. https://wordpress.org/plugins/php-compatibility-ch...

5. Самым идеальным вариантом проверки всего этого дела было бы купить у хостера на месяц такой же хостинг и там опробовать сайт на новой версии. Это закроет все галочки в вашем списке сомнений. Если нет возможности этого сделать, то хотя бы на локальной машине запустите сайт на новом PHP. Можно ещё и дебаг-режим включить, чтобы иметь полный расклад в логах.

6. Если всё это сделали, можно пробовать менять версию PHP на основном хостинге. Делать это лучше когда посетителей меньше всего, но поддержка хостера ещё не спит. Если не сработает, то верните всё из бэкапа.

7. Далее вам нужно наблюдать за работоспособностью и стараться периодически обновлять ядро и плагины, чтобы следующий апгрейд прошел более гладко. Если вы всё-таки решили купить второй хостинг на 5 шаге, то вы можете его даже и оставить как раз для целей проверки обновлений и каких-то новых фич. Не забудьте его тогда закрыть от роботов на всякий случай, чтобы предотвратить индексирование поисковиками.