Поработав несколько лет с flask и tornado выбираю теперь только django (+drf) именно для веба. Для микросервисов - grpc. А, и машины с АКПП предпочту;)
Этот ваш "try, запоминающий цепочку вызовов" давно придумали, монады называются.
Вообще вариантов, как сделать
прочитали из базы()
обработали()
записали результат()
придумали примерно два: либо через исключения, либо через монады. Они, конечно, стектрейс сами-по-себе не запоминают, но всегда можно сделать специальный вариант Either, у которого Left будет хранить хоть стектрейс, хоть вообще весь контекст.
Интересно и то, что все эти американско-европейские субурбы начинают разваливаться лет так через 10-15 после постройки. Содержание их в порядке стоит очень дорого.
Сравним с хрущевками/брежневками, простоявшими кое-где вообще без обслуживания все девяностые.
Но да, в отдельном доме сам себе хозяин, никто по потолку не ходит, и клапан в спальне не выводит.
Для одного небольшого проекта использую облачную версию. Разного функционала и удобностей очень не хватает (например, ссылки на создание/открытие merge request в ответе на git push прямо в консоли). Но именно проблем пока не было.
Оно галлюцинировать не начнет? В том смысле что «вот код, вот тесты, все компилируется, тесты проходят, я сделяль», эдакое вольное сочинение на тему входящей задачи.
Как-то на одной из лекций по релятивистской астрофизике преподаватель поздоровался, объявил «тема сегодняшней лекции - что такое свет?», повернулся к доске и следующие полтора часа безостановочно писал интегралы и дифуры. Подскажите: как из этого можно было содержательный комикс сделать?
Как учебное пособие или результат лабы - отлично (только добавьте py.typed!).
Для реальных задач - отказать:( уж очень много недочётов (например: вычитывает все данные в память, полно fullscan-операций, нет покрытия тестами - test_database.py явно не оно:), нет проверки заявленных версий питона через tox)
С 22 года переехал с pycharm на vscode/vscodium. Сколько ни пользуюсь - впечатление, что авторы о пользовательском опыте особо не задумываются:) Всё-таки это не IDE, а редактор с набором рассогласованных плагинов от разных авторов.
Оговорюсь сразу, я тут не священную войну веду, а просто выдаю детали возможного решения на django+celery, что б сравнить и понять когда что будет более уместно:)
Понятно, то есть с celery нужно будет писать и саму management-команду и обвязку для нее с декоратором task. django-chronograph убирает часть с @task.
Там команда одна сразу на всё будет, и она реально две строчки:
И, насколько я понимаю, это всё может быть параметризовано переменными окружения, которые, опять же, можно задавать во время запуска. Собственно в одном из проектов я наблюдаю порядка десятка не-инженеров запускающих пайплайны с разными параметрами в зависимости от собственных нужд.
В итоге, если есть инструмент, который устраивает и к которому все привыкли – естественно стоит его использовать. А вот если новый проект начинать, кмк для описанного случая gitlab pipelines выглядит более предпочтительно из-за большей функциональности и активной поддержки. Конечно же это в отсутствие других условий вроде отсутствия гитлаба в инфраструктуре:)
Оборачиваем в самом общем виде в celery task (doc)
В админке делаем форму с параметрами для конкретной задачи (on get show form, on post submin/bind the task) и страницу статуса (on get show the task progress or result).
Это если с нуля делать. Основные недостатки:
В лоб нельзя автоматом получить форму из management command arg parser и наоборот. Такие решения есть, но опять же придётся подбирать стороннюю библиотеку.
Проверку статуса задач хорошо бы делать не через формы, а вытаскивать через api. Сильно подозреваю, что есть готовые решения - но опять же это будут третьи библиотеки, в celery такого не припомню.
Придётся ещё и js-код писать для этих страниц результата/статуса.
В общем выглядит как написание своей нетривиальной библиотеки для django, которую потом можно и нужно самим же выкладывать в открытый доступ для облегчения поддержки:)
p.s. Можете поделиться деталями - а в каких случаях нужно команды из админки запускать? Потому что в проектах, над которыми я работаю, пока полностью устраивает даже "нетехнических" людей в одном случае запуск как часть gitlab pipelines (заодно и полный аудит и история), а в другом - просто из cli (`docker exec ... python manage.py my_command`, только не локально, а в docker swarm).
И в энтерпрайзе тоже на скорость работы именно языка почти всегда плевать потому, что почти все задачи io bound, и решает скорость разработки и наличие программистов.
Поработав несколько лет с flask и tornado выбираю теперь только django (+drf) именно для веба. Для микросервисов - grpc. А, и машины с АКПП предпочту;)
Этот ваш "try, запоминающий цепочку вызовов" давно придумали, монады называются.
Вообще вариантов, как сделать
придумали примерно два: либо через исключения, либо через монады. Они, конечно, стектрейс сами-по-себе не запоминают, но всегда можно сделать специальный вариант
Either, у которогоLeftбудет хранить хоть стектрейс, хоть вообще весь контекст.Интересно и то, что все эти американско-европейские субурбы начинают разваливаться лет так через 10-15 после постройки. Содержание их в порядке стоит очень дорого.
Сравним с хрущевками/брежневками, простоявшими кое-где вообще без обслуживания все девяностые.
Но да, в отдельном доме сам себе хозяин, никто по потолку не ходит, и клапан в спальне не выводит.
Для одного небольшого проекта использую облачную версию. Разного функционала и удобностей очень не хватает (например, ссылки на создание/открытие merge request в ответе на git push прямо в консоли). Но именно проблем пока не было.
Оно галлюцинировать не начнет? В том смысле что «вот код, вот тесты, все компилируется, тесты проходят, я сделяль», эдакое вольное сочинение на тему входящей задачи.
А в чем проблема с широтностью? У КА Гонец наклонение 82.5 градуса, 12 аппаратов всего. Больше про экваториальные области интересно как-раз.
Как-то на одной из лекций по релятивистской астрофизике преподаватель поздоровался, объявил «тема сегодняшней лекции - что такое свет?», повернулся к доске и следующие полтора часа безостановочно писал интегралы и дифуры. Подскажите: как из этого можно было содержательный комикс сделать?
А, да, пробовали. LISP называется:)
Как учебное пособие или результат лабы - отлично (только добавьте py.typed!).
Для реальных задач - отказать:( уж очень много недочётов (например: вычитывает все данные в память, полно fullscan-операций, нет покрытия тестами - test_database.py явно не оно:), нет проверки заявленных версий питона через tox)
‘du -hs | sort -h’ в помощь.
С 22 года переехал с pycharm на vscode/vscodium. Сколько ни пользуюсь - впечатление, что авторы о пользовательском опыте особо не задумываются:) Всё-таки это не IDE, а редактор с набором рассогласованных плагинов от разных авторов.
С подорожником можно сразу две поездки в автобусе оплачивать. Только там очень интересный интерфейс сделан, спросите у кондуктора:)
А что такого? К МКС раз в пол года Союзы летают, а тогда это единственная возможность для американцев была.
Справедливости ради 100 млрд. р. - это 1/5 от выручки одного Autodesk. Так что 7 млрд - и правда капля в море.
А судьи кто?
И вопрос для команды: как изменение метрик сказалось на премии или зарплате?
Оговорюсь сразу, я тут не священную войну веду, а просто выдаю детали возможного решения на django+celery, что б сравнить и понять когда что будет более уместно:)
Там команда одна сразу на всё будет, и она реально две строчки:
Вот только что для себя открыл, что в гитлабе есть:
а) отложенные задачи: https://docs.gitlab.com/ee/ci/jobs/job_control.html#run-a-job-after-a-delay
б) возможность запускать пайплайны по расписанию https://docs.gitlab.com/ee/ci/pipelines/schedules.html
И, насколько я понимаю, это всё может быть параметризовано переменными окружения, которые, опять же, можно задавать во время запуска. Собственно в одном из проектов я наблюдаю порядка десятка не-инженеров запускающих пайплайны с разными параметрами в зависимости от собственных нужд.
В итоге, если есть инструмент, который устраивает и к которому все привыкли – естественно стоит его использовать. А вот если новый проект начинать, кмк для описанного случая gitlab pipelines выглядит более предпочтительно из-за большей функциональности и активной поддержки. Конечно же это в отсутствие других условий вроде отсутствия гитлаба в инфраструктуре:)
Работать на корпорации бесплатно в свое свободное время? Или вы можете дать много примеров активного опенсорса, где нет явных корпоративных интересов?
Не комментатор выше, но попробую ответить. Если делать с нуля без третьих библиотек, то:
Берём
call_command(doc)Оборачиваем в самом общем виде в celery task (doc)
В админке делаем форму с параметрами для конкретной задачи (on get show form, on post submin/bind the task) и страницу статуса (on get show the task progress or result).
Это если с нуля делать. Основные недостатки:
В лоб нельзя автоматом получить форму из management command arg parser и наоборот. Такие решения есть, но опять же придётся подбирать стороннюю библиотеку.
Проверку статуса задач хорошо бы делать не через формы, а вытаскивать через api. Сильно подозреваю, что есть готовые решения - но опять же это будут третьи библиотеки, в celery такого не припомню.
Придётся ещё и js-код писать для этих страниц результата/статуса.
В общем выглядит как написание своей нетривиальной библиотеки для django, которую потом можно и нужно самим же выкладывать в открытый доступ для облегчения поддержки:)
p.s. Можете поделиться деталями - а в каких случаях нужно команды из админки запускать? Потому что в проектах, над которыми я работаю, пока полностью устраивает даже "нетехнических" людей в одном случае запуск как часть gitlab pipelines (заодно и полный аудит и история), а в другом - просто из cli (`docker exec ... python manage.py my_command`, только не локально, а в docker swarm).
И в энтерпрайзе тоже на скорость работы именно языка почти всегда плевать потому, что почти все задачи io bound, и решает скорость разработки и наличие программистов.