Сделал в компании доклад о применении ИИ в архитектуре, давайте и вам расскажу.
Фокус в использовании подхода architecture as code: абсолютно все архитектурные артефакты у нас это тексты. С обычной документацией понятно, это и так некоторый набор текстовых файлов, чаще всего в макрдауне. Для них мы применяем структурный шаблон Arc42 — список из 12 пунктов, по которым нужно распределить информацию о проектируемой системе.
Структурный шаблон, во-первых, хорошо известен нейронкам, и они сразу понимают, о чём речь. Во-вторых, можно кинуться в модель бизнес-требованиям и очень быстро создать некий первоначальный набросок, от которого вы дальше уже пляшете, уточняя по пунктам и исправляя ошибки ИИ. Ну и, в-третьих, готовая структура с ящиками, по которым нужно всё раскладывать, это гораздо лучше, чем свалка ADR'ок, как это нередко бывает в компаниях.
Со схемами и диаграммами ещё интереснее. Берём инструменты со своими DSL-языками, такие, как Structurizr и PlantUML. Вся схема или диаграмма целиком определяется текстовым файлом. Можно применять Git со всеми его преимуществами. А для нейронок это родная среда: вы, как человек, смотрите на схему глазами, но нейронка работает с её DSL-файлом. Навскидку тут прирост эффективности даже больше, чем в программировании, потому что DSL это просто синтаксис, без смыслового наполнения, человеку его можно вообще не знать. Ты пишешь промпты, а смотришь уже на картинку, сгенерированную схему, и следующим промптом указываешь, где какие правки сделать. Нейронке при этом не приходится думать про потоки, асинхронность, типы данных, она просто правит текст как текст, поскольку у DSL нет поведения.
Тут как раз наиболее видна разница между рутинной и интеллектуальной частью работы. Как именно будет выглядеть схема, продумывает архитектор. Если доверить это нейронке, даже мощной, будет полно ошибок, неоптимальностей, неучтённых нюансов среды и так далее. Но вот само по себе написание синтаксиса — имба.
#dev@clockstackwheels
https://docs.djangoproject.com/en/1.11/howto/deployment/wsgi/
How to deploy with #WSGI
Django’s primary deployment platform is WSGI, the Python standard for web servers and applications.
Django’s startproject management command sets up a simple default WSGI configuration for you, which you can tweak as needed for your project, and direct any WSGI-compliant application #server to use.
#django
https://github.com/Miserlou/Zappa#about
Zappa makes it super easy to build and deploy all Python #WSGI applications on #AWS Lambda + #API Gateway. Think of it as "#serverless" #web hosting for your Python apps. That means infinite scaling, zero downtime, zero maintenance - and at a fraction of the cost of your current deployments!
If you've got a Python web app (including Django and Flask apps), it's as easy as:
$ pip install zappa
$ zappa init
$ zappa deploy
and now you're server-less! Wow!
What do you mean "serverless"?
Okay, so there still is a server - but it only has a 40 millisecond life cycle! Serverless in this case means "without any permanent infrastructure."
http://www.jaggedverge.com/2017/11/how-a-web-page-request-makes-it-down-to-the-metal/
How a web page request makes it down to the metal
by : Janis Posted in : Tutorials, work-in-progess Tags : #NGINX, #Python No Comments
The other day I was interested in how many steps occur between sending a #POST or #GET#request from a website to the actual processing that happens on the CPU of the #server. I figured that I knew bits and pieces of the puzzle but I wanted to see the complete path from the highest levels of abstraction all the way to the lowest without missing anything too big in-between. It turns out that in a modern web system there are a lot of steps. I have been really fascinated by this much like the explorer that wants to find a path from one known place to another. If you are interested in better understanding how your computer works you might find walking along this path with your tech stack helpful.
Frontend
prelude: GET request
Browser page #rendering
POST request
sidenote: #CSRF#token
Network stack
sidenote: The Internet
#TCP
sidenote: more comprehensive treatment of network stack
Backend
Handling web request
#WSGI
#Django
Django URL routing
Django views
Python implementations
#CPython
CPython bytecode
CPython bytecode execution details
Machine Code
CPython to machine code
Machine code execution
Hardware implementation details
Microcode
Processor #pipeline
Silicon implementation of addition
Silicon adder unit
AND gate
Transistor