В тему нажимания "точки" на гитхабе. Это похоже на рекламную акцию их нового продукта GitHub Codespaces, и похоже оно будет бесплатно работать только до 10 сентября. Я пока не понял, на кого этот сервис ориентируется и какие у него юзкейсы. Ведь если у тебя слабый компьютер, то ты ведь и этот VS Code в браузере нормально использовать наверняка не сможешь. А если машина позволяет комфортно пользоваться VS Code, то почему бы не кодить локально? Если вы собираетесь купить подписку на этот сервис, то опишите вашу ситуацию в комментариях, просто интересно 🌚

Уточнение.

Когда нажимаешь точку на гитхабе, то открывается github.dev — это VS Code, который работает полностью в браузере, без сервера. Поэтому там есть ограничения, например, нет терминала и не все расширения поддерживаются. Оно будет доступно бесплатно всегда.

GitHub Codespaces — это полноценная VS Code, с бэкендом на серверных мощностях Microsoft. Можно пользоваться из браузера, а можно подключаться из своей локальной VS Code. Все расширения из магазина должны в таком варианте работать. Пока что доступно только для корпоративных клиентов по тарифам GitHub Team или Enterprise. До 10 сентября компании могут пользоваться этим бесплатно. Для простых смертных эта фича пока что находится в бета-тестировании и будет доступна позже.

Все ведь уже читали результаты очередного ежегодного исследования от StackOverflow?

2021 является воистину знаменательным годом. jQuery был бессменным лидером по популярности среди JavaScript библиотек, наверное, последние лет 15.

В целом, в айти всё как обычно.

Интересно, что в этом году по сравнению с прошлым среди разработчиков есть рост уровня различных проблем с кукухой. Например, в 2020 лишь 7.2% опрошенных страдало тревожным расстройством, а в 2021 эта цифра выросла до 9.53%. Другие проблемы, такие как депрессия, биполярное расстройство, синдром дефицита внимания, расстройства аутистического спектра тоже стали более распространёнными. Скорее всего, это вызвано удалённой работой и изолированностью от коллектива, к чему многие оказались абсолютно не готовы. Ну и вообще, год был тяжелый.

Заботьтесь о своей кукухе. Голова — ваш рабочий инструмент!

А ещё в этом году в списке питонячьих веб-фреймворков, наряду с Flask и Django, впервые появился FastAPI. И сразу же попал в рейтинг самых любимых фреймворков на третье место. По уровню восторга он конкурирует с гигантами из других экосистем. Он совсем чуть-чуть отстал от Svelte (JS) и ASP.NET Core.

#fastapi #flask

Недавно появился черновик PEP 665 про стандартный способ хранить и описывать lock-файлы для установки зависимостей. Этот документ, судя по всему, является реакцией на тот зоопарк решений, который сообщество породило в попытках решить эту проблему. Например, сейчас для точного воссоздания окружения используются следующие файлы:

* pip-tools создаёт requirements.txt с хэшами всех зависимостей;
* pipenv создаёт Pipfile.lock;
* poetry создаёт poetry.lock.

А после PEP 655, если он будет принят, возможно, у всех этих инструментов будет общий формат описания зависимостей в папочке pyproject-lock.d, и они будут конкурировать не при помощи своих форматов описания зависимостей, а другими способами — кто лучше и быстрее резолвит граф зависимостей, чем удобнее пользоваться, и т.д. А ещё было бы логично, если бы и сам pip умел устанавливать зависимости из этих lock-файлов, так чтобы не приходилось на проде иметь ничего лишнего.

Если интересуетесь cloud-based IDE, то можно попробовать Gitpod. Они делают примерно то же самое, что и GitHub Codespaces, только начали они раньше. Тоже VS Code в браузере с бэкендом где-то в облаке. Опенсорс, можно сделать self-hosted. Доступно всем желающим, можно пользоваться уже сейчас.

Дают 50 часов в месяц бесплатно, чего должно быть достаточно для каких-нибудь пет-проектов.

Насколько я понял, пока что этим можно пользоваться только через браузер, т.е. нельзя подключиться из локальной VS Code.

P.S. Чувствую, этому сервису придётся очень тяжко, когда GitHub Codespaces выйдут из беты.

https://www.gitpod.io/blog/cloud-based-development-for-everyone

Я начинаю проникаться всё большей симпатией к идее эфемерных облачных окружений для разработки.

Мы уже давно привыкли описывать всю инфраструктуру в виде кода. Это удобно и позволяет быстро разворачивать новые типовые сервера, так что сами по себе отдельные сервера перестали быть ценностью. Если вдруг катастрофа, то всё всегда можно удалить и развернуть заново. Важен не сам сервер, важен рецепт, как этот сервер развернуть. Если призадуматься, то машина разработчика — это тоже своего рода инфраструктура, и её тоже можно (и нужно!) описать в виде кода, и воссоздавать/пересоздавать по запросу.

Это же невероятно круто, когда новый человек в компании может за 10 секунд получить готовое настроенное окружение для разработки. Все зависимости есть, тесты проходят, нужные плагины для IDE установлены и настроены. Берешь и сразу же начинаешь разбираться с кодом, а не тратишь три дня на клонирование огромных репозиториев, установку и компиляцию всех зависимостей. Знакомо ведь это чувство, когда нужно собрать какую-то конкретную лохматую версию какой-то всратой библиотеки из исходников с патчами? И эти скрипты почему-то работают на одной машине, но не работают на другой, и никто на самом деле не понимает почему.

А если вдруг твоё эфемерное окружение для разработки вышло из строя, то без проблем — просто создай новое, и через 10 секунд будешь готов продолжить работу.

Постоянно наступаю на проблему, что при переключении между ветками в Git забываю обновлять зависимости. Переключаешься на новую ветку — тесты не работают, линтеры красные. "Ах, ну да, эта ветка отстаёт от мастера на две недели, здесь с такими версиями библиотек ничего работать не будет". Запускаешь свой pipenv --rm && pipenv sync --dev. Это минуты на три. Выпадаешь из потока и идёшь запаривать очередную кружку кофе. А ведь можно было бы просто закрыть один редактор и открыть другой, где всё уже настроено для той конкретной ветки, которая тебе нужна.

И GitHub Codespaces, и Gitpod в фоне постоянно собирают (prebuild) окружения, чтобы можно было взять, и как можно быстрее начать пользоваться. На самом деле, я пока в восторге именно от эфемерности этих окружений для разработки. То, что они работают в облаке — это не так уж и важно. Просто так проще организовать всю эту систему.

https://github.blog/2021-08-11-githubs-engineering-team-moved-codespaces/

Django Software Foundation и JetBrains проводят опрос про экосистему вокруг этого популярного веб-фреймворка. Практикующих и сочувствующих призываю принять участие.

https://www.djangoproject.com/weblog/2021/aug/04/2021-django-developers-survey/

#jetbrains

Lambda + Python 3.9:

https://aws.amazon.com/blogs/compute/python-3-9-runtime-now-available-in-aws-lambda/

#Lambda

Чистый код на Python.

Эта статья содержит в себе краткий пересказ принципов, которые позволят писать идиоматичный, читаемый и поддерживаемый код. Примерно как конспект всех книг дядюшки Боба, но сразу же применённый к Python.

https://testdriven.io/blog/clean-code-python/

Как работают импорты в Python?

Ух, давненько я не читал такой жести, это прям сплошное мясо. Думаю, эта статья заслуживает однажды быть напечатанной в составе какой-нибудь книги. Очень много подробностей того, как устроена система импортов в Python. Я понимал, что эта система сложнее, чем я себе представляю, но не представлял насколько. Возможно, эти знания помогут мне меньше страдать с хаотичным перекладыванием файлов по папкам так, чтобы оно всё импортировалось в будущем.

Однозначно рекомендую эту серию статей "Python behind the scenes" к внимательному изучению, оно того стоит.

https://tenthousandmeters.com/blog/python-behind-the-scenes-11-how-the-python-import-system-works/

Brett Cannon запилил запускальщик питона py, который всегда запускает последнюю, самую свежую среди установленных версию. Это решает проблему, когда алиасы python/python3 перезатираются при установке очередной версии питона, так что они указывают не на самую новую версию питона, а на недавно установленную. В мире Windows подобная штука существует уже лет 10 и устанавливается по умолчанию, а вот теперь такое же есть и для Unix-систем.

Я никогда не страдал от проблемы перезаписывания алиасов python/python3, потому что пользуюсь менеджером версий asdf и сам контролирую, на какую версию ссылаются эти алиасы. Да, и pyenv тоже умеет точно так же.

Для меня, пожалуй, самым полезным применением этого py будет то, что он умеет находить виртуальные окружения, и использовать их без активации, так что вместо:

source .venv/bin/activate
python -m pip install httpx

можно писать вот так:

py -m pip install httpx

Написано на Rust.

https://snarky.ca/introducing-the-python-launcher-for-unix/

В Python 3.10 добавлены две новые встроенные функции aiter() и anext(), которые наконец добавляют возможность полноценно контролировать асинхронные итераторы и генераторы без вызовов dunder-методов. Синхронный и асинхронный миры становятся чуть более симметричными.

https://twitter.com/1st1/status/1374499776570347521

Первый доклад там по сути является пересказом событий и выступлений с Language Summit 2021. Там вообще было показано и сказано много интересного. Ускорение питона нынче самая популярная тема. Горячий выдался саммит, и сообществу наверняка понадобится какое-то время, чтобы всё это качественно впитать и осознать.

Вспомнил всё ещё разок и заодно законспектировал. Вот вам пересказ пересказа.

🐍 Making CPython faster
* Гвидо собрал команду внутри Майкрософт, и они будут работать над ускорением CPython;
* конечная цель — x5 ускорение в течение 4 лет;
* в 3.10 появятся первые оптимизации из этой серии, а 3.11 уже якобы должен работать примерно в два раза быстрее;
* всё это будет достигнуто без жертв со стороны обратной совместимости и мирного населения.

🐍CPython Improvements at Instagram
* внутри Instagram развился собственный форк CPython под названием Cinder, где они экспериментируют с различными подходами по улучшению производительности;
* в общей сложности, получилось ускорить CPython на 20-30%;
* среди применённых оптимизаций — различные срезания углов в асинхронном коде, оптимизация словарей;
* сделали JIT;
* исходники форка доступны на гитхабе, но поддерживаться оно не будет; вместо этого, они будут пытаться пропихнуть удачные оптимизации в апстрим CPython;
* они там в инстаграме совсем ударились в форки питона, поэтому кроме Cinder у них есть ещё один форк под названием Pyro, где упор сделан на более оптимальную работу сборщика мусора.

🐍HPy — Present and Future
* в разработке находится HPy — новый API/ABI для работы с интерпретатором из нативного кода, например, из библиотек на C;
* обещают, что это сделает PyPy и Python внутри GraalVM быстрее;
* в перспективе это ускорит и CPython, но не сейчас.

🐍 Progress on Running Multiple Python Interpreters in Parallel in the Same Process
* субинтерпретаторы в перспективе решат проблему GIL, т.е. позволят эффективно утилизировать несколько процессорных ядер без создания новых процессов в ОС;
* в синтетических тестах субинтерпретаторы работают чуть медленнее, чем мультипроцессинг, но это пока что лишь прототип, так что ок;
* синхронизацию между субинтерпретаторами планируется сделать через что-то, очень напоминающее каналы в Go.

#конспект