Проблема решилась открытием сайта в режиме ИНКОГНИТО🤯
Или в Safari вместо Chrome...

Какого черта вообще происходит с браузерами на макбуке? У меня на некоторых сайтах поперебойно такие проблемы: то в хроме что-то не работает, а в сафари - работает, то наоборот😢

Я долго сопротивлялся всем AI тенденциям, считая, что они еще не созрели для использования в реальных проектах. Но недавно попробовал Cursor (о котором я уже прожужжал все уши) - и теперь я полностью переобулся!

Опыт от использования Cursor не идет ни в какое сравнение с моими робкими попытками потыкать Copilot / ChatGPT. Эта штука буквально читает твои мысли - и воплощает их в код быстрее, чем ты формулируешь их до конца.

Copilot же постоянно предлагал мне средневзвешенное говнецо с гита, да еще и галлюционировал по полной - закидывал в методы лишние аргументы, обращался к ненужным или несуществующим аттрибутам объекта и тд. Самое обидное - предлагаемый код выглядел целиком и полностью валидным, но нюанс в виде передачи func(obj.field) вместо func(obj) очень легко проглядеть и он постоянно выстреливал уже при запуске. Это ОЧЕНЬ раздражает.

Cursor же великолепно понимает контекст твоего проекта - он придерживается стиля написания, который принят в проекте, не обращается
к несуществующим полям, методам и вообще делает то, что хочешь именно ты и именно сейчас. За две недели использования я словил ровно 0 галлюцинаций и ровно 100% кайфа. К тому же Cursor отлично помнит контекст происходящего процесса. Ты только поправил класс? - давай поправим его использование ниже по файлу. Перешел в другой файл? - вон тот класс вон в том модуле только что правили, давай поправим его использование и тут! У тебя просто не остается выбора, кроме как нажимать TAB - TAB - TAB...

Опыт от использования очень похож на опыт парного программирования: мысль летит, код пишется, и даже не понятно (да и не важно), чьи руки его написали - настолько ты увлечен процессом.

После написания своей субъективной оценки я полез в интернет еще раз и нашел отличный разбор всех возможностей Cursor. Поэтому прилигаю вам полную статью, где я готов подписаться под каждым слово в хвалу TAB. Другие возможности я пока не использую, либо использую по минимуму - но посмотрим, не переобуюсь ли я и тут.

В общем и целом - Cursor я уже оплатил, а всем, кто еще не пробовал - крайне рекомендую потыкать

Разбор негатива я запланировал на завтра.

#AI #cursor

Ура! Моя статья про декораторы уже ушла в народ и уже используется как авторитетный!!! источник при написании других статей про декораторы😅

https://habr.com/ru/articles/817445/

Особенно забавно, что моя авторская терминология соблюдена

Такие декораторы называются декораторами Шредингера

Глядишь, лет через 5 совсем приживется)

#программирование

В продолжение темы Cursor

В сети есть множество негативных отзывов о работе с Cursor - говнокодит, баголепит и тд. Почему опыт людей от использования этого продукта так разнится? Тут ведь дело не в субъективном восприятии - нейронка либо баголепит и галлюционирует, либо нет.

Сейчас можно было бы высокомерно кинуть: "IDE закидывает тебе точно такое же говно, что пишешь ты сам. Нормально пиши - нормальные комплиты будут". Но это не совсем правда.

Сейчас я склонен считать, что рынок AI-инструментов в любом случае изменит нашу индустрию. RAG-нейронки как поисковик по доке и замена Stackoverflow, промпты избавляют от whitelist прокрастинации, а AI-автокомплиты уменьшают порог входа в новый язык + значительно увеличивают скорость разработки.

Однако, использование новых инструментов требует также и новые подходы. Какие-то старые практики подходят для AI-Driven Development, какие-то - совершенно несовместимы. Нейронки в любом случае будут галлюционировать, наш рабочий процесс должен быть построен таким образом, чтобы минизировать саму вероятность этих галлюцинаций с одной стороны и нивелировать их последствия с другой.

В моем случае мне очень помогло, что на проекте, где я обкатывал Cursor, я использовал TDD + CA. В итоге очень ограниченный скоуп воздействия, где нужны комплиты, большое наличие референсных тестов и классов, с которых AI может копировать, а также большой процент тестового покрытия из коробки сыграли свою роль - и у IDE просто не было возможности ошибаться. Как оно будет работать на легаси проектах с большим количеством говнокода - я не знаю.

В любом случае, я верю, что такие инструменты будут в дальнейшем бустить индустрию, а подходы к разработке - адаптироваться соответствующе. Если это значит, что мы сможем писать код с нормальной архитектурой по TDD БЫСТРЕЕ, чем генерируется говнокод - я буду только счастлив.

#AI #cursor

Мелочь, а приятно😊 Совершенно случайно нашел вот такую бумажку на компе, которая прилагалась вот к этому списочку - https://www.benchcouncil.org/evaluation/opencs/annual.html

Пойду прикреплю к портфолио, пока совсем не потерялась😅

Хочу закруглить все свои мысли насчет AI инструментов в разработке небольшими размышлениями и фантазиями на тему Cursor VS Vim. Слава богу, это последний пост на эту тему (пока что), дальше буду выносить всем мозг тестированием🌚

Неожиданно, основным конкурентом Cursor и подобных инструментов для меня выглядят не VSCode / Pycharm, а именно Vim.

Суть в том, что задачи AI-IDE и Vim в своем корне схожи - избавить разработчика от рутины по набору кода, который он уже визуализировал в своей голове.

Фанаты Vim мотивируют его изучение именно этим - нужно отработать слепую печать и навигацию в IDE до рефлекторного уровня владения. В таком случае ты разгружаешь свой мозг от необходимости тратить калории на моторику пальцев и процесс печати, и можешь думать и реализовывать свои мысли с примерно сопоставимой скоростью, что существенно бустит продуктивность за счет 2ух факторов

* на рутину тратится меньше калорий
* на рутину тратится меньше времени

Но думаем мы все-таки быстрее, чем печатаем. Тут уже вступают в игру законы механики и фундаментальные ограничения нашего тела, проводимости нервной системы и используемой аппаратуры.

AI-IDE с другой стороны предлагают решение той же самой проблемы, но
* ниже порог входа - не нужно тратить месяцы и годы на выработку рефлексов
* дешевле - калорий на нажатие TAB тратится все еще меньше, чем на слепую печать
* эффективнее? - реализация твоих мыслей по нажатию одной клавиши быстрее, чем слепая печать

Вопрос только в том, насколько эти самые ассистенты будут соответсвовать той идеальной картинке рабочего процесса, которую рисует моя больная фантазия.
После нескольких недель опыта использования Cursor я сказал бы, что он соответствует на 80% (если не все 100%). Очевидно, инструменты подобного плана в том или ином виде выместят стандартные IDE либо как полноценные аналоги, либо как плагины, либо как built-in функционал.

Скорее всего, в ближайшие десятилетия в эту же нишу зайдут нейроинтерфейсы, которые позволят убрать gap между скоростью мысли и набора текста. Но даже тут AI-ассистенты не потеряют своей ценности - просто они переобуются на конвертации неформальной и не до конца оформленной человеческой мысли в конкретные строчки кода, либо просто возьмут этот нейроинтерфейс как свой инпут.

В любом случае, нас ждет интересное и захватывающее будущее!

Также, хочу поделиться с вами классным выпуском моего любимого подкаста как раз на тему Vim и продуктивности - https://podlodka.io/291

#AI #cursor #продуктивность

Сейчас изучаю тему стандартизации API и пытаюсь дотянуться до разных гайдлайнов по именованию ресурсов в REST, чтобы выделить из них какие-то общие практики. Пока получается откровенно хуево

Сначала нашел неплохой (блог? сайт?), где собрана куча рецептов по REST - https://restfulapi.net/resource-naming/ . Я даже согласился с 80% того, что там написано

А потом наткнулся на рецепты от Google по приготовлению API https://google.aip.dev/122 - и там написано совершенно другое.

Я начинаю понимать, почему у нас такой разброд и шатание в Интернете и люди предпочитают делать 200: {"status": "error"}, чем разбираться в каких-то противоречащих друг другу рекомендациях. Можно, конечно, изобрести велосипед и опубликовать N+1 стандарт на основе изучения N предыдущих, но как будто это не решение. В итоге так и будем пилить апихи кто во что горазд...

А какие гайдлайны по REST знаете / используете вы?

Wow, у нас тут Yet Another Python Web Framework от автора Poetry (еще один Sébastien, ага)

Дока: https://expanse-framework.com/
GitHub: https://github.com/expanse-framework/expanse

Чето-то там про валидацию, поддержку ORM из коробки, миграции и всякое такое. Похоже, люди устали от "свободы" FastAPI - и теперь тренд идет на то, чтобы натянуть побольше "изкоробинга" и батареек на похожий API.

Не уверен, насколько получится у Себастьяна - ведь я не очень люблю Poetry, но будем посмотреть, конечно

Ситуация вышла из под контроля и FastDepends перевалил за 1_000_000 установок в месяц!🥳

Кажется, нужно туда хотя бы закоммитить😅

Yet another Celery killer moment - товарищ устал ждать развития arq и запилил свое видение проекта - https://github.com/python-arq/arq/issues/437#issuecomment-2675789579

Над неймингом я бы еще поработал - https://github.com/tastyware/streaq

Почему мне это интересно? Потому что Pydantic так и не взялись за развитие своего шедулера. Видимо, ниша шедулеров и асинхронных сервисов показалась им бесперспективной в сравнении с другими их проектами. Чтож, сидим дальше в своем болоте

Чтож, пришло время подвести итоги моего 2ухмесячного тура по TDD. Краткие выводы - я не понимаю, как вообще писал код до этого😅

Основной мой тезис, что любая разработка УЖЕ ВЕДЕТСЯ ПО TDD, и мы этого не осознаем. Просто это Manual TDD. Как мы пишем код для решения задачи Х?

1) Изучаем задачу
2) Формируем требования к коду, который будет ее закрывать
3) Пишем код
4) Проверяем, что сформированные в П.2 требования выполняются (мануально)
5) Пишем тесты???

Но, если у нас уже есть список требований, то почему бы просто не зафиксировать их тестом!? Идея на поверхности, но она полностью меняет ощущения от самого процесса.

К тому же, я сам частенько переходил на TDD в сложных случаях.
Как мы фиксим багу? - пишем красный тест, делаем его зеленым, рефакторим
Как мы рефакторим старый код? - аккуратно исправляем его так, чтобы тесты не сломались
Как мы пишем сложную фичу? - пишем N тестов и пытаемся написать код, который закроет их все разом.

Если ты фиксируешь требования к новому коду через тесты, то

1) Ты гораздо лучше формируешь сами требования. Они превращаются из абстрактных хотелок в твоей голове в конкретный API с конкретными инвариантами. В итоге часто случается, что картинка API нового модуля из твоей головы, в процессе написания теста оказывается неверной - и рождается новый дизайн.

2) Тест является для тебя определенной ступенькой на пути к полной реализации (см. One Step Test), ниже которой ты не можешь провалиться. Ты как альпинист, который по мере поднятия на вершину, переносит страховочные крепления все выше и выше. Начиная с самого тривиального теста, ты докидываешь новые и новые проверки инвариантов без страха, что предыдущие отвалятся. Такое тестовое покрытие прямо в процессе дает коллосальное чувство спокойствия, позволяет держать меньше деталей в голове, и сконцентрироваться только на задаче, решаемой в эту секунду.

3) Если альпинист не может поставить страховку выше того места, где он находится, то в случае с тестами мы можем это сделать! (см Fake It). Красный тест - это цель, к которой натянута веревка - нам будет очень тяжело отклониться от нее. Наличие красного теста буквально за руку ведет нас к реализации функционала. Писать код становится в разы проще.

4) Скорость разработки также кардинально увеличивается. Запустить тест - это гораздо быстрее, чем мануально проверить выполнение логики. Если ты не пишешь все идеально с первой попытки, то такие проверки-перепроверки придется совершить N раз. Сложная логика также требует сложных мануальных манипуляций. Напиши тест! - он выполняется за 0.1 секунды.

Экстремальные адепты TDD даже юзают утилиты, которые сразу запускают тесты при изменении в любых файлах - https://pypi.org/project/pytest-watcher/

5) Наличие тестового покрытия на основные инварианты из коробки банально повышает качество итогового программного продукта. За него не нужно биться или "обеспечивать" - оно уже есть.

6 - бонусный пункт от меня) Написание тестов - отличный способ борьбы с прокрастинацией. Вот надо тебе съесть слона - и ты сидишь и думаешь, с какого бока к нему подступиться. Напиши тест, а лучше два (см. Триангуляция) - это уже будет маленький шажок на пути к ожидаемому результату. Или у тебя просто есть 15 минут между созвонами и ты физически не можешь воткнуть туда полноценное решение задачи - напиши тест! Это занимает 2 минуты, требует околонулевых мозговых затрат, зато приближает тебя к итоговой цели.

7 - бонусный пункт от меня) TDD идеально сочетается с AI-DD, т.к. подразумевает итеративные атомарные изменения кода, где у AI остатется мало пространства для галлюцинаций. А наличие тестов позволяет быстро отлавливать такие галлюцинации.

TDD - это не просто инструмент или конкретный подход. Это целая идеология. Ты можешь готовить ее множеством способов. Не нравится писать много юнит-тестов, т.к. фича слишком проста, чтобы тратить на это время? - увеличивай шаги, пиши высокоуровневые красные тесты (см Fake It, Obvious Implementation).

#TDD

Поначалу тяжело перестроиться на "пиши тест сначала", но это действительно того стоит. Каждый раз, когда я ловил затык и просто тупил в монитор - оказывалось, что я снова пытался написать код без теста😅 После написания красного флага все снова приходило в норму.

Тема TDD показалась мне очень близкой и интересной, поэтому я выпущу еще 2 заметки - о цикле TDD и о конкретной моей практике его использования (с прикладными примерами). А пока - рекомендую всем и каждому почитать Кент Бека и понять, почему ему стоит хотя бы попробовать писать тесты вперед кода.

#TDD

Угадайте, кто снова будет спикером на PiterPy?🌚
Жду всех на свой доклад (неожиданно про FastStream)! Будем всем залом копаться в кишочках и проектировать фреймворк заново😅

https://piterpy.com/talks/6ccc5d2b87a9495a94dcf03ce3468f17

Как-то я несколько озадачен текущей ситуацией со спецификациями OpenAPI / AsyncAPI

С одной стороны - все запросы на поддержку MQTT и прочих вариантов транспорта в OpenAPI закрываются со словами "не очень понятно, как это сделать, юзайте AsyncAPI" - https://github.com/OAI/OpenAPI-Specification/issues/553#issuecomment-620477276

С другой стороны - AsyncAPI стемится быть настолько generic, чтобы дать возможность описать все, что угодно - в том числе и HTTP. Однако, настолько широкая специализация делает ее слишком вербозной и недостаточно удобной для написания руками - https://github.com/OAI/OpenAPI-Specification/issues/55#issuecomment-1052572818

Казалось бы - проблемы нет? Пишем AsyncAPI спеку на асинхронные сервисы и OpenAPI - на HTTP. Но все упирается в то, что HTTP сервисы часто имеют поддержку SSE / Websockets, которую сейчас нельзя выразить в рамках OpenAPI (и не предвидится возможным). В итоге, чтобы описать один сервис, нам нужно иметь сразу две спецификации? - звучит сомнительно.

У автора AsyncAPI есть видение - он предлагает ссылаться из AsyncAPI прямо на OpenAPI - https://github.com/OAI/OpenAPI-Specification/issues/55#issuecomment-1057220490

Как будто бы это единственный вариант, но насколько он рабочий?

В моем представлении, если мы хотим максимально полное описание нашего сервиса в спецификации - нужно юзать AsyncAPI . C Code-first инструментами (типа FastStream) тут даже нет проблемы - их вербозность никак не мешает сгенерировать валидную спеку из кода, которая красиво отрисуется в HTML. А что делать Specification-first страдальцам? Писать руками AsyncAPI для HTTP - сомнительное удовольствие...

Я еще поиграюсь с тем, как работают референсы из AsyncAPI на OpenAPI - в этом может быть ответ, но пока будущее спецификаций туманно

Время пришло и проект Propan переходит в публичный архив - https://github.com/Lancetnik/Propan

Хотя работы над ним не велись с момента релиза FastStream, но все равно как-то грустно отправлять свое авторское детище в дальний ящик. Чтож, посмотрим, какие еще интересные проекты нас ждут в будущем - пока я сосредоточусь на развитии FastStream и FastDepends. Авантюра с Propan зашла значительно дальше, чем я ее планировал😅

По многочисленным заявкам немногочисленного Андрея попытаюсь изложить практические аспекты идологии TDD

Коротенько не получилось, поэтому вот ссылка на фул.

Краткие тезисы для ЛЛ:

1) Цикл TDD: красный тест – зеленый тест – рефакторинг, повторяем
2) Держим фокус решаемой задачи. Красный тест должен быть один. Все мысли вне скоупа этого теста – на бумажку, вернемся к ним на следующем витке цикла
3) Движемся вперед – микроскопическими шагами. Пишем тупые реализации, говнокодим по полной – лишь бы тест стал зеленым. Рефачим уже на этапе "рефакторинг", либо даже на следующем витке цикла.
4) Чувствуешь силы – ускоряйся, пиши реализации не так тупо. Знаешь как правильно – пиши правильно сразу. Но чуть какие проблемы – переходим на "пониженную передачу"
5) Тесты проверяют наши ожидания и формируют интерфейсы будущего кода. Проверять детали реализации они НЕ ДОЛЖНЫ!

https://telegra.ph/Ideologiya-TDD-03-07

В следующий раз приведу реальные примеры уже из реального проекта

#TDD

Никита Соболев запустил новый канал, куда мейнтейнеры могут дропать Good First Issues.

Если вы ищете возможность контрибутить в CPython, FastStream, dishka, taskiq и другие OSS проекты – обязательно подпишитесь!

Я совершенно точно буду дропать туда простые/интересные задачки! Уже совсем скоро будет первый дроп😅

https://t.me/opensource_findings_python/6

Хо-хо-хо, нашел для вас (и себя) топ-контент. Это целое мок-интервью на позицию CTO.

Думаю, всем, интересно узнать, что требуют от руководителей такого уровня?) А кому-то может быть даже пригодится🌚

В общем, пошли смотреть

https://youtu.be/UAuHACFTw5E?si=q4ziHLA79NbRV26_

#карьера

Наконец-то дочитал самую базированную в современных ИТ-реалиях книгу – Цель. Еще в 1984 году Голдратт опубликовал свою теорию ограничений в виде художественного романа. Эта методология выросла как теоретическая база над практическим чудом Генри Форда (1920е) и Тайити Оно (1960е). Именно теория ограничений была заложена в основу современных методик аля Scrum, Canban, Agile, Devops и тд.

Забавно, что перед этим я как раз прочитал Проект Феникс, который явяется буквально современным рерайтом "Цели", но с приземлением на ИТ (что дает нам в итоге DevOps практики). Но Феникс оказался слишком практическим для меня, поэтому саму идеологическую суть получилось ухватить только при обращении к оригиналу.

Революционность теорию ограничений заключалась в том, что она сместила акцент при принятии решений с максимизации метрик локальной эффективности рабочих центров на максимизацию "протока" системы в целом.

"Проток" – это количество полезного действия системы в единицу времени (для производства – деньги, для ИТ – фичи). При перекладывании на ИТ это все выливается в идею, что нет смысла мерить кто быстрее запилит функционал – фронт за 2 дня или бек за 4, если фича осядет в тестировании на 3 недели. В итоге все должно выкручиваться в угоду Time To Market.

Процесс разработки – это цепочка взаимосвязанных операций. А прочность цепочки определяется прочностью самого слабого элемента. Так и величина "протока" системы зависит лишь от пропускной способности самого медленного "бутылочного горлышка".

А вот тут самое интересное. Бутылочным горлышком в случае ИТ может быть:
– архитектор-диктатор, без совета с которым не реализуется ни одна система
– тимлид-контролер, без ревью которого катиться нельзя, а снизойдет он до тебя через неделю
– синьорный синьор. Только он знает как работает система и 90% тасок может выполнить только он, а обучать других членов команды у него нет времени
– аналитик. Идея фичи есть, а на ТЗ разработке его еще никто не перевел.
– хер знает что еще

Основная мысль в том, что работа до 90% времени выполнения может дожидаться чего-то еще (ручки на беке еще не подвезли – фронт курит, ждем ревью по 2 недели, когда там devops'ры нам стенд запилят?). Если такое происходит – это является ограничением в рабочем процессе, которое нужно устранять.

В общем, рекомендую всем прочитать и "Цель", и "Проект Феникс". Можно в произвольном порядке, но для понимания, за что мы тут все воюем – точно стоит)

#карьера #продуктивность