Ну да, перефразировали и выдали за правильное определение!
Вы на, так называемое "окончание мысли", не пишите автотесты? Не подгоняете code style под общий стандарт? Не следите за ошибками?
Если вы всё это делаете, то вам не стоит бояться pre-commit проверок. Я в статье написал, что мои pre-commit скрипты проверяют только измененные файлы. А внутри pre-push проверяется уже весь проект целиком, чтобы лишний раз не гонять CI.
Согласен! Вы же всегда можете временно отключить pre-commit скрипты и пролить ветку в репозитори, а внутри репозитория вас уже не пропустит CI.
Но я всё же против такого подхода, так как считаю, что commit - это точка наиболее стабильной версии кода. По этой причине я при каждом коммите запускаю проверку тестов.
PSR-12 — официальный стандарт, а PER — это надстройка над PSR-12 для более строгой проверки. Она расширяет PSR-12 дополнительными правилами для более строгого и единообразного стиля кода (например, обязательное использование declare(strict_types=1), строгие пробелы, порядок импортов и т.п.).
Я считаю, что эти 2 подхода актуальны, но всё зависит от области применения:
Для проектов с открытым кодом, фреймворков, библиотек — PSR-12.
Для внутренних корпоративных проектов, где нужна дисциплина и единый стиль — можно добавить PER поверх PSR-12.
P.S. Как я писал ранее, я не рекомендую внедрять максимальную строгость на старые проекты, так как это может сильно нагрузить разработчиков и сократить продуктивность.
Я пробовал, но отказался от такого подхода по причине того, что Laravel имеет много внутренних ошибок и если поставить максимальный level, то PHPStan будет ругаться на ошибки фреймворка.
Я также не использую максимальный level, так как такая строгость может отпугнуть и убить всё желание использовать PHPStan.
Увеличивайте уровень постепенно, но начинайте с 6-7. Меньше уже плохо, так как он начинает закрывать глаза на типизацию.
Спасибо всем, кто дочитал до конца! Я постарался собрать практики, которые реально экономят время и нервы в Laravel-проектах. Если у вас есть свои лайфхаки по автоматизации — буду рад услышать в комментариях, возможно, смогу дополнить статью.
Спасибо всем, кто следит за проектом и делится обратной связью!
В этом обновлении постарался закрыть основные запросы от пользователей — в первую очередь, по интеграции с ВКонтакте и удобному развёртыванию через Docker.
Дальше в планах:
добавить web-интерфейс для просмотра информации о чатах и пользователях;
добавить API для работы с чатами;
расширить метрики и алерты в Grafana.
Если у вас есть идеи или кейсы использования — смело оставляйте в Issues, буду рад поработать над ними.
Спасибо за поддержку и звёзды — это действительно помогает развивать проект 🙌
Разрабатывал под PgSQL, но вчера вечером помог пользователю с настройкой на MySQL. Всё зашло нормально! Если будут ошибки, пожалуйста напишите Issues или сделайте PR. Буду очень благодарен!
Да, я согласен! Изначально, я хотел добиться генерации случайных данных. Сейчас модуль при каждом обращение создаёт разные наборы значений для параметром валидации.
После публикации модуля, я получил обратную связь от пользователей, за что вам огромное спасибо!
Теперь я буду дорабатывать модуль и добавлять возможность смешивать статичные и динамичные данные.
Сейчас я собираю обратную связь от пользователей. На данный момент, бота запустили 400+ пользователей. Когда появятся интересные предложения, я постараюсь их реализовать. Если есть идеи, пишите в личку на хабре!
Ну да, перефразировали и выдали за правильное определение!
Вы на, так называемое "окончание мысли", не пишите автотесты? Не подгоняете code style под общий стандарт? Не следите за ошибками?
Если вы всё это делаете, то вам не стоит бояться pre-commit проверок. Я в статье написал, что мои pre-commit скрипты проверяют только измененные файлы. А внутри pre-push проверяется уже весь проект целиком, чтобы лишний раз не гонять CI.
А как ты относишься к git-хукам, которые автоматически исправляют code style? Или те, что корректируют комментарий к коммиту?
Это достаточно универсальная вещь, которая приносит много пользы!
Согласен! Вы же всегда можете временно отключить pre-commit скрипты и пролить ветку в репозитори, а внутри репозитория вас уже не пропустит CI.
Но я всё же против такого подхода, так как считаю, что commit - это точка наиболее стабильной версии кода. По этой причине я при каждом коммите запускаю проверку тестов.
Я только начинаю изучать Python, поэтому буду рад если вы предложите свои альтернативы.
Про ruff я слышал, обязательно позже добавлю версию скрипта с проверкой ruff-pre-commit!
Спасибо, что подсветили!
PSR-12 — официальный стандарт, а PER — это надстройка над PSR-12 для более строгой проверки. Она расширяет PSR-12 дополнительными правилами для более строгого и единообразного стиля кода (например, обязательное использование declare(strict_types=1), строгие пробелы, порядок импортов и т.п.).
Я считаю, что эти 2 подхода актуальны, но всё зависит от области применения:
Для проектов с открытым кодом, фреймворков, библиотек — PSR-12.
Для внутренних корпоративных проектов, где нужна дисциплина и единый стиль — можно добавить PER поверх PSR-12.
P.S.
Как я писал ранее, я не рекомендую внедрять максимальную строгость на старые проекты, так как это может сильно нагрузить разработчиков и сократить продуктивность.
Проверки и тесты лучше внедрять постепенно!
Я не генерирую статьи с помощью LLM! Я пишу о том, что я лично использую.
Статья написана мной лично, все исходники кода можно найти в моих проектах и в отдельном репозитории на GitHub.
Я пробовал, но отказался от такого подхода по причине того, что Laravel имеет много внутренних ошибок и если поставить максимальный level, то PHPStan будет ругаться на ошибки фреймворка.
Я также не использую максимальный level, так как такая строгость может отпугнуть и убить всё желание использовать PHPStan.
Увеличивайте уровень постепенно, но начинайте с 6-7. Меньше уже плохо, так как он начинает закрывать глаза на типизацию.
Попробуйте level = 9 и скажите своё мнение )))
Спасибо всем, кто дочитал до конца!
Я постарался собрать практики, которые реально экономят время и нервы в Laravel-проектах.
Если у вас есть свои лайфхаки по автоматизации — буду рад услышать в комментариях, возможно, смогу дополнить статью.
Спасибо! Рад что вам понравился данный проект.
Статью писал сам, а нейросеть попросил проверить на грамматические ошибки и «припудрить» немного!
Интересно!
Обязательно ознакомлюсь. Спасибо!
Сейчас планирую двигаться в направление Viber и WhatsApp, так как они более популярны!
Также в ближайшем релизе я опубликую API для подключения внешних источников, например "живого чата" на сайте или для интеграции с CRM системой.
Проект развивается и мне очень важна ваша поддержка!
Спасибо всем, кто следит за проектом и делится обратной связью!
В этом обновлении постарался закрыть основные запросы от пользователей — в первую очередь, по интеграции с ВКонтакте и удобному развёртыванию через Docker.
Дальше в планах:
добавить web-интерфейс для просмотра информации о чатах и пользователях;
добавить API для работы с чатами;
расширить метрики и алерты в Grafana.
Если у вас есть идеи или кейсы использования — смело оставляйте в Issues, буду рад поработать над ними.
Спасибо за поддержку и звёзды — это действительно помогает развивать проект 🙌
Я бы ещё указал бота для тех. поддержки через Telegram
https://github.com/prog-time/tg-support-bot
Разрабатывал под PgSQL, но вчера вечером помог пользователю с настройкой на MySQL. Всё зашло нормально! Если будут ошибки, пожалуйста напишите Issues или сделайте PR.
Буду очень благодарен!
На данный момент я использую версию 12.7.2
Да, я согласен! Изначально, я хотел добиться генерации случайных данных. Сейчас модуль при каждом обращение создаёт разные наборы значений для параметром валидации.
После публикации модуля, я получил обратную связь от пользователей, за что вам огромное спасибо!
Теперь я буду дорабатывать модуль и добавлять возможность смешивать статичные и динамичные данные.
Не знал! Надо попробовать. Спасибо
Идея интересная! Буду двигаться в этом направление
Сейчас я собираю обратную связь от пользователей. На данный момент, бота запустили 400+ пользователей.
Когда появятся интересные предложения, я постараюсь их реализовать.
Если есть идеи, пишите в личку на хабре!