Сделал в компании доклад о применении ИИ в архитектуре, давайте и вам расскажу.
Фокус в использовании подхода architecture as code: абсолютно все архитектурные артефакты у нас это тексты. С обычной документацией понятно, это и так некоторый набор текстовых файлов, чаще всего в макрдауне. Для них мы применяем структурный шаблон Arc42 — список из 12 пунктов, по которым нужно распределить информацию о проектируемой системе.
Структурный шаблон, во-первых, хорошо известен нейронкам, и они сразу понимают, о чём речь. Во-вторых, можно кинуться в модель бизнес-требованиям и очень быстро создать некий первоначальный набросок, от которого вы дальше уже пляшете, уточняя по пунктам и исправляя ошибки ИИ. Ну и, в-третьих, готовая структура с ящиками, по которым нужно всё раскладывать, это гораздо лучше, чем свалка ADR'ок, как это нередко бывает в компаниях.
Со схемами и диаграммами ещё интереснее. Берём инструменты со своими DSL-языками, такие, как Structurizr и PlantUML. Вся схема или диаграмма целиком определяется текстовым файлом. Можно применять Git со всеми его преимуществами. А для нейронок это родная среда: вы, как человек, смотрите на схему глазами, но нейронка работает с её DSL-файлом. Навскидку тут прирост эффективности даже больше, чем в программировании, потому что DSL это просто синтаксис, без смыслового наполнения, человеку его можно вообще не знать. Ты пишешь промпты, а смотришь уже на картинку, сгенерированную схему, и следующим промптом указываешь, где какие правки сделать. Нейронке при этом не приходится думать про потоки, асинхронность, типы данных, она просто правит текст как текст, поскольку у DSL нет поведения.
Тут как раз наиболее видна разница между рутинной и интеллектуальной частью работы. Как именно будет выглядеть схема, продумывает архитектор. Если доверить это нейронке, даже мощной, будет полно ошибок, неоптимальностей, неучтённых нюансов среды и так далее. Но вот само по себе написание синтаксиса — имба.
#dev@clockstackwheels
http://docs.celeryproject.org/en/latest/django/first-steps-with-django.html
Previous versions of #Celery required a separate library to work with #Django, but since 3.1 this is no longer the case. Django is supported out of the box now so this document only contains a basic way to integrate Celery and Django. You’ll use the same #API as non-Django users so you’re recommended to read the First Steps with Celery tutorial first and come back to this tutorial. When you have a working example you can continue to the Next Steps guide.
https://realpython.com/blog/python/asynchronous-tasks-with-django-and-celery/
Asynchronous Tasks With #Django and #Celery
“Celery is an asynchronous task queue/job #queue based on distributed message passing. It is focused on real-time operation, but supports scheduling as well.” For this post, we will focus on the scheduling feature to periodically run a job/task.
https://www.fullstackpython.com/celery.html
#Celery is a task #queue implementation for Python web applications used to #asynchronously execute work outside the HTTP request-response cycle.
Asynchronous
#celery
celeryproject.org
Distributed task queue.
#flower
pypi.python.org/pypi/flower
Tool for monitoring and management of Celery tasks.
#django-channels
pypi.python.org/pypi/django-channels
Official Django websockets interface, can also be used as task queue.
#rq
pypi.python.org/pypi/rq
RQ is a simple, lightweight, library for creating background jobs, and processing them.
#django-rq
pypi.python.org/pypi/django-rq
A simple app that provides django integration for RQ (Redis Queue).
#django-background-#tasks
github.com/arteria/django-background-tasks
Database backed asynchronous task queue.