ThunderCat

принято ли в срезе разработки веб приложений СНГ писать коммиты на русском?

У нас как только не пишут. Бывает, что мешают по несколько языков в одном проекте, в том числе и в компаниях, которые себя позиционируют как очень модные. Все зависит от конкретных людей в конкретном месте.

Но чем более подкованные специалисты в команде, тем больше вероятность, что они между собой договорятся все унифицировать и писать коммиты по конкретной схеме (это больше не про язык в вакууме, а про последовательность в проекте, чтобы было проще ориентироваться). Очень вероятно, что при этом выберут английский, т.к. скорее всего "русские" сообщения коммитов будут состоять из:

1. Англицизмов, которые еще и не имеют однозначной транслитерации в кириллицу, что ломает поиск по коммитам.
   
2. Названий классов, файлов, или еще каких-то сущностей из мира кода, которые и так уже переведены и есть в исходниках проекта на английском.
   
3. Набора базовых глаголов, которые ставят в начале предложений, вроде "добавил", "исправил", "удалил".
   

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

если его присылают на клиент?

Его присылают НЕ на клиент, а на определённый урл, который наверняка указывается в настройках при подключении платёжки.



За 2 минуты нашёл инструкцию на их сайте. Как вы гуглите?

Для того чтобы правильно писать catch, надо писать осмысленный код.

А здесь мы наблюдаем очаровательный пример карго-культа.
Узнав, что "толстый контроллер - это плохо, а сервисы - это хорошо", автор небрежным движением руки замел весь мусор под ковёр перенёс весь код из контроллера в "сервис". Ну а что? Контроллер худой, весь код в сервисе!
Тот факт, что сама кривая структура проекта осталась, по сути, той же самой, нас не смущает.
Как и то, что сервис вдруг начал выполнять функции НТТР контроллера и кидать почему-то НТТР исключения. Что с этими исключениями делать в случае, если тот же сервис будет вызван из консольной команды - загадка.

Но самое забавное, что при всём при этом контроллер всё равно пытается выполнять работу модели. Казалось бы, какое отношение интерфейс для обслуживания НТТР запросов имеет к транзакциям в базе данных? А вот поди ж ты!

Чтобы сделать этот код осмысленным, контроллеру всё-таки придется потрудиться, и выполнить какую-то работу самому, а не перекладывать на "сервис". А так же отдать модели то что ей принадлежит.

В общем транзакцию перекинуть в createDefault. причём не напрямую, а ещё ниже - в слой для работы с БД. Стартовать транзакцию до валидации данных - это как бы *не совсем логично*, мягко говоря. И в итоге, как по волшебству, весь этот говнокод исчезнет как страшный сон.
При этом в параметрах передавать не НТТР реквест чохом, а осмысленный набор параметров, вынутый предварительно из реквеста!
В частности, если модель сама проверяет права доступа, то и передавать ид пользователя из авторизации.

При этом модель не должна кидать НТТР исключения. Она должна кидать исключения бизнес-логики. Которые контроллер уже может ловить и транслировать в хттп. Но тут видимо уже сложнее, поскольку это ж ларавель судя по всему.

В любом случае, уж catch (Exception $e)-у тут точно не место

Но это если рассматривать твой конкретный случай.
В общем же случае правильный код написал Илья.

То есть внутри трая операции с БД и коммит.
в кетче роллбэк и перевыброс исключения. Только ловить надо Throwable

try {
  DB::beginTransaction();
  // запись в БД
  // запись в БД
  // запись в БД
  DB::commit();
} catch (\Throwable $e) {
  DB::rollBack();
  throw $e;
}

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

class Test {
    protected $where;
    protected $params;

    public function getAll()
    {
        $result=$this->db->prepare("SELECT * FROM table WHERE 1=1 ".$this->where);
        $result->execute($this->params);
        return $result->fetchAll(PDO::FETCH_ASSOC);
    }

    public function byDate($start,$end=false)
    {
        if ($end) {
            $this->where .= " AND data BETWEEN :start AND :end";
            $this->params['end'] = $end;
        } else {
            $this->where .= " date >= :start";
        }
        $this->params['start'] = $start;
        return $this;
    }

    public function byCol($col)
    {
        $this->where .= " AND col = :col";
        $this->params['col'] = $col;
        return $this;
    }
}

$sql = new Test;
$data = $sql->byCol($col)->byDate($start)->getAll();

по-хорошему тут еще должны быть отдельные переменные для самого запроса, для order by, limit и так далее
Но начать можно с такого

с помощью этой штуки https://www.electronjs.org/docs/tutorial/quick-start
можно поискать видосы на ютубе по ней

У бесперебойников в общем-то две основные характеристики - максимальная мощность и емкость батареи. Мощность - ее прямо в названии в магазинах пишут. Ее должно хватать для типичного потребления компьютера. Для описанных в вопросе пк скорее всего и 300 Вт будет всегда хватать. Можно брать любой самый дешевый. А батарея - тут зависит от необходимого времени работы автономной. Почти любого ИБП хватит, чтобы нормально выключить компьютер. А если надо прямо проработать какое-то время, то гуглим "nix время автономной работы ИБП при нагрузке" и получаем список из протестированных ибп вместе с ценами.

const container = document.querySelector('селектор контейнера с select\'ами');
const selectSelector = 'селектор select\'ов';
const input = document.querySelector('селектор input\'а');
const updateInput = selects => input.value = Array.from(selects, n => n.value).join(' ');

container.addEventListener('change', function() {
  updateInput(this.querySelectorAll(selectSelector));
});

// или

const selects = container.querySelectorAll(selectSelector);
const onChange = updateInput.bind(null, selects);
selects.forEach(n => n.addEventListener('change', onChange));

1. Нету никакого "UTF8bm4", а есть "utf8mb4"
2. В форме и скриптах ничего для этого менять не нужно так как это просто UTF-8
3. utf8mb4 это про кодировку и хранение строк на уровне БД: и вам соотв-но нужно задать правильный charset при установке соединения и правильный collation для полей таблицы

читаем https://profiphp.ru/useful/utf8mb4.html
вникаем https://ruphp.com/utf8mb4-php-mysql.html

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

Используйте их js sdk.

Не хочется ругаться, но вопрос очень бессвязный и в нем перемешаны реальные проблемы с нелепыми фантазиями.

И проблема тут не в незнании как работать с большими базами данных, а в неумении работать с БД в целом.

Про идею "всем индекс не поставишь" надо сразу забыть. Там где индекс нужен, он должен стоять без вариантов. Другое дело что тупо натыкать индексов по всем полям, по которым идёт поиск - это тоже глупость. Индекс в запросе может использоваться только один, и индексы по второму-третьему полю уже будут бесполезны. Надо анализировать запросы и, возможно, делать составные индексы.

Детсадовский запрос вида like '%...%' - это отдельный ужас. Надо смотреть на полнотекстовый поиск. А лучше вообще его избегать. На крайний случай использовать внешние поисковые сервисы типа эластика. И только не говори что этот лайк у тебя идёт по полю типа джейсон или "через запятую"

Но самый конечно кошмар - это select distinct для фильтров. То есть неумение проектировать бд на самом базовом уровне, непонимание самых начальных принципов реляционных бд, нормализации. Вот с этих принципов и надо начать. В потом уже хвататься за большие объемы. Очевидно, что поля по которым ты собрался делать "distinct" - это должны быть отдельные таблицы, от которых в основной таблице будет просто id. поле размером в 4 байта.

Непонятно, откуда взялись фантазии про гигабайтные индексы, кстати. Большая часть полей в нормальной бд - это не больше десятка байт. То есть индекс - это десятки мегабайт, а не "гигабайты".

В общем, куда лучше бы смотрелись здесь не абстрактные рассуждения про большие объёмы, а конкретный запрос, который "отваливается". С обязательным результатом EXPLAIN

А ответ на абстрактный вопрос "как работать с большими объемами" очень простой: точно так же, как с небольшими. Реляционные бд изначально проектировались под большие размеры. То есть надо просто уметь работать с бд. Читать про реляционную модель, нормализацию, индексы, оптимизацию запросов.

Конкретно для грида надо смотреть в сторону Эластика/Сфинкса. В смысле чтобы не только для полнотекстового поиска, а чтобы все фильтры, которые есть выборке, были забиты в поисковый индекс. И все выборки - через поисковый сервис, а не через прямой запрос к базе