Алиасы нужны для решения конфликта имён и только для этого. Добавление промежуточных имён редко делает код чище. Практики принятые в датасаенсе часто не являются примерам хорошего дизайна.
Мои инструменты это автоматизация. Форматер + линтер + статический анализ задают нижнюю планку качества кода на хорошем уровне. Мой личный шаблон https://github.com/Cjkjvfnby/project_template, давно не обновлялся, но всё еще актуальный.
Я именно про радикальность, что это ошибки джунов. Проверить, что все вызовы не возвращают налл это зона ответственности человека и человек ошибается. Ну и то что сегодня не может быть, завтра станет его возвращать. Да линторами и практиками можно значительно улучшить ситуацию.
микросервисы - это спорное архитектурное решение, гарантирующее в первую очередь job security архитектору (ни чего другого микросервисы не могут предложить, чего другая архитектура не может).
Всё-же что-то могут. Просто таких ситуаций значительно меньше, чем проектов с микросервисами.
Про отсутствие тулинга вокруг люто плюсую. Минимальный уровень инфраструктуры необходимый для них - это высокий уровень для обычных проектов.
Часто планировщик должен быть один на систему. Если запустить все примеры в статье в параллель, то задач будет выполняться много. И это не для всех случаев подходит.
У celery другая концепция, это вообще сервис прикрученный сбоку. у него планировщик в отдельном процессе.
то все виденные мною примеры (втч и на хабре) делают фундаментальную ошибку - они забывают, что celery - это не async приложение. А вызывают его таски во всех примерах из async функции.
Я бы уточнил, что клиент для celerу.
Это общая беда асинхронного стека, в него слишком легко запихнуть синхронные задач.
Есть небольшой нюанс, в примерах сервер запускается как один процесс. То есть у нас будет ровно один инстанс планировщика.
Если взять Django, то его обычно запускают во много процессов и соответственно будет много запусков запланированных задач. Этот момент в статье как-то не раскрыт.
Как вы справидливо заметили celery решает эту проблему через отдельный процесс для пларировщика. Такой подход, действительно, не зависит от фреймворка.
Второй шлагбаум проехать не осилила, и поехала по рельсам. А там застрять не не сложно. Фотки с другой стороны нет, но не похоже, чтобы поезд её протащил.
А можете привести примеры, каких инструментов не хватает в Java?
Инструменты есть, но о них не знают. Одна из причин это скорость работы, например для Scala все жалуются, что очень медленно. В чатике C# разработчиков на вопрос о форматерах отвечали как-то вяло. Я попробовал парочку, они работают более 10 секунд (на маленьком проекте).
Для сравнения примерно такой-же объем кода на Питоне c самым быстрым форматером:
208 files left unchanged ruff format . 0.02s user 0.03s system 146% cpu 0.028 total
Что касается написания методов в разном стиле: с точки зрения производительности и бизнес-логики как будто разницы нет
При едином стиле можно бегло читать код. И тогда при нарушении можно что-то не заметить. Это отнимает время. Не критично, но всётаки. Ну и конечно раздражает.
Сравнивать чистые языки не совсем практично. В экосистеме Питона есть имуляция проверки строгой типизации. Работает вполне неполохо и реально ловит баги.
То есть данный код будет отформатирован любым разработчиком абсолютно одинаково. Иначе он просто не будет работать.
Есть еще варианты как в Питоне записать функцию. И лямбды и однострочники. Но это всё решается линтерами и форматерами. После них вариантов уже не будет.
Java, C# сильно отастают в плане инструментов по работе с кодом. Часто когда спрашиваю про тулзы у разработчиков, они делают удивлённые глаза. Компиляция неполохо защищает от ошибок и мне кажется на этом все останалваются. В Go уже получше, больше вещей встроенно в компилятор. Но всё равно подключаешь стронюю тулзу и видишь страницы проблем.
В голом Питоне ничего нет, но за счёт этого бурно растет сторонний инструментарий. И люди активно им пользуются.
Выкидывать только свои исключения это очень хорошая практика.
Что за
перьёд? Товаришь Chat J'ai peté постарался?Можно просто в отдельную функцию вынести.
Алиасы нужны для решения конфликта имён и только для этого. Добавление промежуточных имён редко делает код чище. Практики принятые в датасаенсе часто не являются примерам хорошего дизайна.
Мои инструменты это автоматизация. Форматер + линтер + статический анализ задают нижнюю планку качества кода на хорошем уровне. Мой личный шаблон https://github.com/Cjkjvfnby/project_template, давно не обновлялся, но всё еще актуальный.
@transactional, а также try with resources позволяет одной строкой сделать два действия, открыть и закрыть.
Разбиение этого кода на две строки даёт возможность совершить ошибку.
Такие ошибки может быть сложно поймать, так как многие вещи всё же закроются самостоятельно при выходе из программы.
Мне такой подход в go не нравится.
В современной разработке эту будет отсеяно на стадии CI и никто кроме автора об этом не узнает.
И не пихать не связанные вещи в один файл.
Я именно про радикальность, что это ошибки джунов. Проверить, что все вызовы не возвращают налл это зона ответственности человека и человек ошибается. Ну и то что сегодня не может быть, завтра станет его возвращать. Да линторами и практиками можно значительно улучшить ситуацию.
Всё-же что-то могут. Просто таких ситуаций значительно меньше, чем проектов с микросервисами.
Про отсутствие тулинга вокруг люто плюсую. Минимальный уровень инфраструктуры необходимый для них - это высокий уровень для обычных проектов.
Вы наверно очень внимательный и дотошный. Или дальше hello word не заходили.
GDPR то здесь при чём?
С тем же микросовтом, заключается контракт, и запросы в нейронки не идут на обучение.
Да и свои модельки тренировать пока не заметили.
Похвалил свой продукт.
А что в европе с нейронками? Какой-то чат жпт другой?
Как же! Разбудишь его, вашего Герцена!
Часто планировщик должен быть один на систему. Если запустить все примеры в статье в параллель, то задач будет выполняться много. И это не для всех случаев подходит.
У celery другая концепция, это вообще сервис прикрученный сбоку. у него планировщик в отдельном процессе.
Я бы уточнил, что клиент для celerу.
Это общая беда асинхронного стека, в него слишком легко запихнуть синхронные задач.
Есть небольшой нюанс, в примерах сервер запускается как один процесс. То есть у нас будет ровно один инстанс планировщика.
Если взять Django, то его обычно запускают во много процессов и соответственно будет много запусков запланированных задач. Этот момент в статье как-то не раскрыт.
Как вы справидливо заметили celery решает эту проблему через отдельный процесс для пларировщика. Такой подход, действительно, не зависит от фреймворка.
Тут есть ошибка выжившего, в большинстве видео которые я видел, машина в итоге стоит боком к поезду и распадается на части.
Второй шлагбаум проехать не осилила, и поехала по рельсам. А там застрять не не сложно. Фотки с другой стороны нет, но не похоже, чтобы поезд её протащил.
Инструменты есть, но о них не знают. Одна из причин это скорость работы, например для Scala все жалуются, что очень медленно. В чатике C# разработчиков на вопрос о форматерах отвечали как-то вяло. Я попробовал парочку, они работают более 10 секунд (на маленьком проекте).
Для сравнения примерно такой-же объем кода на Питоне c самым быстрым форматером:
208 files left unchanged
ruff format . 0.02s user 0.03s system 146% cpu 0.028 total
При едином стиле можно бегло читать код. И тогда при нарушении можно что-то не заметить. Это отнимает время. Не критично, но всётаки. Ну и конечно раздражает.
Сравнивать чистые языки не совсем практично. В экосистеме Питона есть имуляция проверки строгой типизации. Работает вполне неполохо и реально ловит баги.
Есть еще варианты как в Питоне записать функцию. И лямбды и однострочники. Но это всё решается линтерами и форматерами. После них вариантов уже не будет.
Java, C# сильно отастают в плане инструментов по работе с кодом. Часто когда спрашиваю про тулзы у разработчиков, они делают удивлённые глаза. Компиляция неполохо защищает от ошибок и мне кажется на этом все останалваются. В Go уже получше, больше вещей встроенно в компилятор. Но всё равно подключаешь стронюю тулзу и видишь страницы проблем.
В голом Питоне ничего нет, но за счёт этого бурно растет сторонний инструментарий. И люди активно им пользуются.