Что правильнее: git merge master VS git rebase?

Сергей Кузнецов,

Чтобы управлять историей, а не хранить её в виде археологических слоёв.
Rebase не «уничтожает» историю, а переписывает её так, чтобы она оставалась линейной и читаемой.
Git — не архив, а инструмент. И да, rebase — часть нормального рабочего процесса, если понимать, когда и зачем его применять.

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

Старые коммиты никуда не удаляются. Если что-то пошло не так, ветка возвращается в предыдущее состояние одной командой. Не надо тут вводить в заблуждение )))

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

Как раз наоборот: когда вы работаете с веткой один и ленитесь причесать историю через интерактивный rebase перед отправкой в вышестоящий репозиторий — вот тогда это действительно остаётся на вашей совести. ))

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

Перевод бэкенда с PHP на NodeJs?

itrushkoff,

есть бэкенд на PHP, есть бизнес-требование перейти на JS

Шансы, что это бизнес требование минимальны, т.к. это вопрос чисто технический.
Так что тут серьёзная проблема, либо бизнес лезет туда куда не должен, либо технари не очень понимают, что делают (ну нельзя переписывать работающий проект на то, что никто не знает, просто так).

Как сделать уменьшение склада в СУБД безопасными правильным?

Александр Рублев, простой счетчик, как уже писали: balance = balance - 1.
Но, когда реальный остаток и остаток в БД не сойдутся, нужно будет искать ошибку, а без "лишних" таблиц искать негде, у вас только одно число и все. Если есть логи в приложении, то можно по ним, если в них удобно.

Как анализировать рынок IT, чтобы помочь ребенку с выбором направления?

Сергей Горностаев, с одной стороны как бы да, баланс нужен, но так можно быстро начать выбирать только "практичное". И зачастую только кажется что оно практично. Когда не интересно, очень быстро начнет воротить от выбора, и тогда не сможешь развиваться, а значит не сможешь и зарабатывать. И никакой практичности уже нет.
А когда интересно, то найдешь свой путь и среди не сильно "практичного".
Так мне кажется... Ведь если не интересно, зачем оно вообще тогда нужно.

Как анализировать рынок IT, чтобы помочь ребенку с выбором направления?

Выбирать интересное, нужно в любом возрасте

Как скомбинировать массивы, чтобы получить все варианты сочетаний их элементов?

Ипатьев, Алексей Уколов, закинул вариант, по-моему более читабельный, причем рекурсия там не сильно сложнее выглядит чем перебор массивов, а array_slice гарантирует выход.

Как получить данные в виде текста на русском языке из базы данных Paradox 4.5?

Adamos,

Vitsliputsli, вот когда ТС завалит ту элементарщину, с которой сюда явился - зовите его к себе и снабжайте документацией, погружайте во флоу... и вообще, благотворительность - это похвально, конечно.

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

Как получить данные в виде текста на русском языке из базы данных Paradox 4.5?

Adamos,

а вы мальку сразу дадите рабочую задачу, чтобы сначала нужно было недельку поразбираться в проекте и документации?

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

Подключние к базе данных из класса - насколько правильно?

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

Подключние к базе данных из класса - насколько правильно?

nokimaro,

1. производительности при переиспользовании подготовленного выражения
2. безопасности. в случае с EMULATE_PREPARES=true получаем не настоящее подготовленное выражение, а лишь экранирование, что-то близкое к использованию mysqli_real_escape_string() вокруг параметров
3. более корректной работы с типами данных

А на практике? Тут всегда нужно рассматривать в разрезе СУБД, например с PostgreSQL все хорошо, а вот с MySQL все плохо, поэтому PDO и использует эмуляцию вместо реальных prepared statements для MySQL (с PostgreSQL по-умолчанию идут реальные).
1. Производительность ниже. Варианта повторных запросов с кешированным планом практически не бывает (к тому же оно только на сессию в MySQL). 3 запроса вместо 1го не должны быть быстрее, хотя у PostgreSQL получается одинаково както. В MySQL медленнее, да еще и жрет много памяти сервера.
2. Безопасность - да. Хотя, конечно, эмуляцию отладили хорошо, теоретически гарантии нет, в отличии от реальных.
3. Корректная работа с типами вещь надуманная, на мой взгляд, т.к. типы в приложении и в СУБД все равно разные.

Подключние к базе данных из класса - насколько правильно?

Anywake, если непонятно то, что предлагается, то не стоит этому следовать. Не только потому что это может быть чушь, а скорее потому, что не понимая выгоды можно все равно наворотить не того, что подразумевалось.
Кажется, что лучше так, делайте. Но, хорошо бы помнить, что есть и другие варианты, и когда столкнетесь с теми или иными сложностями, вспомните про них.
Но лучше тогда, когда реально будете понимать зачем это вам. К примеру, если не пишите юнит-тесты, если код сугубо специализирован как внутри проекта (т.е. не сильно важны зависимости глобальные), так и по работе с модулями (т.е. хранилище конретная СУБД и вряд ли там появится иное чтото), то и проблем статического обращения не почувствуете, хоть с service locator, хоть напрямую к синглтонам.
Помоему нельзя хорошо освоить чтолибо просто слепо повторяя какието best practice, нужно понимать зачем оно нужно, и понимать не теоретически, а практически. А иной раз лучше не переуслажнять, а сделать проще, пусть и не универсально.

Про PDO::ATTR_EMULATE_PREPARES мой вопрос не что это, оно то понятно, а почему именно такой вариант выбран. Это сознательный выбор или просто следуя какомуто авторитетному источнику.

Подключние к базе данных из класса - насколько правильно?

nokimaro,
PDO::ATTR_EMULATE_PREPARES => false
Кстати, а почему эмуляцию отключаете? Это сознательный выбор, или просто перекочевало откудато?

Подключние к базе данных из класса - насколько правильно?

Anywake, если не очень понятно, то может оно и не нужно пока, nokimaro правильно заметил, что всегда нужно исходить из задачи и инструментов.
Собственно в вашем примере, DB - это Service Locator специализирующийся только на соединениях с СУБД. Service Locator - не нарушает SRP, он ничего не знает об ответственности сервисов, которыми управляет, его ответственноть только получение и возврат объекта.
На превый взгляд может показаться, что это ненужный посредник, но именно то, что он посредник и помогает. К примеру, если взять юнит-тестирование, то в варианте со статическим вызовом конкретных классов все печально, но если сделать посредника в виде ServiceLocator и в нем прописать возможность переопределения объектов, которые возвращают методы, то можно легко подменить реальные объекты на моки. А вот с универсализацией все плохо, но примерно также как и в случае с прямыми статическими обращениями к конкретным классам.

Подключние к базе данных из класса - насколько правильно?

Если уж идти по этому пути, то лучше сразу завести сервис-локатор, чтото вроде:

class ServiceLocator
{
    public function getDB(): DB
    {
        ...
    }
}

будет один статический класс для обращения и из него можно будет получать что нужно.
В принципе, можно создать объект сервис-локатора и тащить только его по всем классам, а интерфейсами регулировать какая часть нужна в том или ином классе. Опираясь на интерфейсы можно будет делать соответствующие моки для юнит-тестов.

Второй момент, а зачем внутри класса статическое обращение? Тащить через всю вереницу классов зависимость тяжко, но не обязательно в конечном классе делать эту зависимость.
Т.е. выносим вызов сервис-локатора, ну или там синглтона, на уровень выше. А в классе Data чистая dependency injection. В итоге, вроде все тоже самое, но когда нет статических вызовов в конечном классе, то можно на него писать юнит-тесты без проблем.

Подключние к базе данных из класса - насколько правильно?

Anywake, вместо этого

catch(PDOException $sql_connect_e)
{  
    echo ("Ошибка подключения к базе данных. SQL erorr: ". $sql_connect_e->getMessage() ."");
    die();
};

так

catch(PDOException $sql_connect_e)
{  
    echo ("Ошибка подключения к базе данных. SQL erorr: ". $sql_connect_e->getMessage() ."");
    throw $sql_connect_e;
};

Зачем здесь echo не знаю, по мне логичнее было бы в лог кидать.

Подключние к базе данных из класса - насколько правильно?

Anywake,

Есть нюанс в том, что у меня несколько баз в колхозе и пользователю мне нужно показывать кто упал и почему упал.

Сделайте на каждое соединение отдельный класс и будет все понятно, если только у вас не динамическое или большое кол-во соединений.
Если очень хочется чтото вписать в лог ошибки, то пишите, но завершайте catch фразой:
throw $sql_connect_e;
Это выведет реальную ошибку. В варианте который вы привели в вопросе, в catch все данные об ошибке уничтожены, т.е. вы не сможете узнать, что за ошибка произошла.

Как объединить 2 таблицы обращаясь к одному и тому же полю 2 раза?

survivor2005, а что именно не очевидно? Просто интересно, как взгляд со стороны, т.к. по мне наоборот все очевидно.

Как учиться и практиковаться?

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

Как автоматически откатить в CI/CD миграции при помощи Goose, если их было несколько?

Станислав, если в разрезе "неких универсальных сервисов" обновляемых под нагрузкой - не откатывайте миграции, тем более автоматически. Одномоментное обновление и БД, и приложения невозможно. Поэтому любая версия приложения должна работать с ближайшими версиями БД. А значит в случае отката - возвращаете предыдущую версию приложения и не трогаете БД. Да, возможность отката БД должна быть, но в ручном режиме, на всякий случай.
Откат миграции, в отличии от отката приложения, это не возвращение предыдущей версии БД, а новое состояние, новая версия, которая лишь теоретически должна соответствовать предыдуущей версии БД. Откатываем мы тогда, когда чтото пошло не так, чтото чего мы не предусмотрели при разработке и не проверили при тестировании. Т.е. творится невесть что, а мы не разбираясь автоматом вызываем еще дополнительные DDL операции - это плохо.
К тому же, если ваша среда в нормальном состоянии, то вы не словите ошибку при накате миграций, а словите ее тогда, когда приложение начнет активно писать в соответствии с новой версией БД. А в таком состоянии, откат БД как правило будет сопровождаться потерей данных.

Как установить русский язык в php:8.2-fpm-alpine?

Михаил, локаль здесь не при чем, вам нужны компоненты юникода ICU для всех языков, а не урезанные, которые по-умолчанию