Для содомодокументации многое даст политика документации принятая в проекте. А слоты стоят часто на первом месте после объявления класса и вместе c корректным названием класса могут заменить docstring, так еще и бенефит по памяти, который никаким педантиком и датаклассами не достичь.
>> что вы такое пишите на 300к строк? Это судя по профилю всё на Django?
Ага. На ней родимой. Начинал с 1.3 версии Django. Сейчас 5.2.a1. В самой моей первой публикации тут в 2019 писал про этот проект. Большая база данных по алкоголю с лютым количеством свистоп€рд€лок для конвертации данных в разные форматы.
Любой ассистент формирует. Некоторые из них пишут именно тесты очень хорошо. Но это всегда по запросу. Самостоятельно - пока ни один. Вот тут немного обсуждалось https://habr.com/ru/articles/876714/
ну если совсем "душнить", то я сравнивал результаты производства (самолет и бытовые приборы) не способы. Так вот. В автоматизированных линиях есть допустимый процент брака в районе 5%. Потому гарантированность одного и того же результата в районе 95%.
Если с AI я достиг того же - одинаковый результат в 95% случаев - то инженерная задача решена. Или нет?
Удивительно, как люди советующие самим летать на AI-разработанных самолетах пользуются бытовыми приборами собранными на полностью автоматизированных производственных линиях, ах, да, это же другое...
А теперь по делу. Разработкой TDD с AI пользуюсь довольно давно. И прийти к этому довольно просто, надеюсь, что даже самые отъявленные скептики, вероятно задумаются.
Грубо про TDD - есть четко представленная идея / тех задание. Пишем тест на тех задание, представив, что реализация уже есть. После написания теста, пишем реализацию проходящую тест.
Удивительно, но есть работающий пример, как создания теста под "тех задание" так и создания собственно самого кода: это код-генератор клиента и сервера почти на на любом языке по описанию из yaml. Сомневаетесь что это работает? - зайдите на editor.swagger.io
Из текста в код... не находите аналогий со статьей?
Далее. проще. Задача написать хорошую yaml-схему. Тоже довольно просто, поскольку есть отличные YAML валидаторы и какая-никакая спека OpenAPI (кстати новая версия вышла, Arrazo называется) для проверки корректности смысла схемы.
А вот тут LLM просто прекрасно справляются. Поскольку это не код и yaml-схема не может работать или не работать. Это текст. Проверить корректность описания endpoint-a довольно просто визуально.
В итоге в моем примере, LLM, плюс линтеры по тех заданию клепают yaml, а после какой-нибудь connexion генерит код. В моей работе я не могу вспомнить примеры с ноября 2023, когда это не cработало. Тогда Мы/Я в команде начали использовать codewhisperer/codeium для этого.
Да, немного не в стиле идеи статьи, поскольку у нас по тех заданию сразу генерится клиент сервер приложение, а не тесты. Сейчас уже 420 api, работают как часы. Продолжим.
Наш следующий шаг в использовании произошел прошлым летом, когда в codewhisperer появились конвейеры проверяющие верность сгенерированного кода прежде, чем выдать ответ на промпт. Да, обычно это здорово тормозит генерацию ответа, но убыстряет путь к рабочему решению.
Так вот. Вернемся к статье.
Машина не должна писать тесты. Тесты - зона ответственности программиста.
Это утверждение я поставил под сомнение: оказывается, машина может писать тесты. Точнее llm пишет задание генератору кода, а с лета 2024 агент научился запускать кодгенератор и предлагать граничные условия для тестов, часто более качественно или подробно, чем это сделал бы я. Например https://github.com/django/django/blob/main/tests/utils_tests/test_numberformat.py - набор случаев созданных человеком ранее не включал большое отрицательное число записанное через e.форму. Уже поправили.
Ну так вот, по поводу писать тесты самому: мой промпт на TDD обсуждался в чате одного из Code-assistant. выглядит примерно так:
Please generate TDD tests for Django project according to this specification:
Дальше текст тех задания на разработку.
Да, предварительный контекст для модели тоже используется, больше похож на codestyleguide проекта и мои личные предпочтения по коду (например, на питоне писать генераторами без использования [] ). И на мой взгляд, наш ассистент справляется очень хорошо: Тесты работают сразу, граничные условия более продуманные, я часто потом уменьшаю их количество, типа - "тут одного хватит"
Так вот. Я к тому, что задача, которую должна выполнить модель - это сформировать по моему нечеткому тз декларативный документ для запуска кодогенерации. А самих код генераторов вагон и тележка. И они выдают результат работающий без сомнений.
Верить или нет коду от LLM, конечно, решать в итоге разработчику. Но вот сократить время разработки LLM точно могут. И кстати, на мой взгляд, с LLM подход TDD, скорее всего, станет не нужен.
Ээ... может это перевод? Поскольку тут описываются только встроенные возможности python. Да и то без особого разбора. Есть компрехеншены, и тут же идет map и filter.
Понимаю, трюк - "вы использовали map, filter и list-comprehention, а теперь вы можете написать все в одном стиле":
numbers = [1, 2, 3, 4, 5]
squared = (x**2 for x in numbers if x % 2 == 0 )
print(*squared) # [4, 16]
А так, просто неорганизованные куски примеров использования python.
А у меня тоже вопрос к @djcrhk3chabrпро запуск через nginx - сколько воркеров использовали. По моему опыту, от хостинга к хостингу могут отличаться настройки при, казалось бы, одинаково выбранной мощности (hetzner vs djangoeurope).
Ну и в принципе, стоило все же сначала дотянуть до 490-500 rps только методами Django и потом кешить (если все сразу обмазать кешем нормально не померяешь улучшения). Как натянуть со стандартных 70-100 до 500 rps я рассказывал в докладах про "Django-FTL"
Да ладно. Между прочтением про махровые реакт хуки и про профилирование - я рад что с такой статьёй возможно полностью переключиться между темами. Ну и про концептуальный признак гендера я не знал, а очень хороший пример поверхносностного подхода даже в уважаемых научных изданиях.
А может все лучше использовать ast.Ast вместо ispect, для получения всего, что необходимо?
Вторая идея - модно же использовать кеширующий декоратор, он сработает на момент первого вызова функции. проверит тип, вызовет нужную функцию и запомнит на следующие вызовы.
Ну почему же не померить.
However, what is most surprising is that namedtuple instances take a bit more memory than instances with slots.
Или тут: https://tommyseattle.com/python-class-dict-named-tuple-performance-and-memory-usage/
Для содомодокументации многое даст политика документации принятая в проекте. А слоты стоят часто на первом месте после объявления класса и вместе c корректным названием класса могут заменить docstring, так еще и бенефит по памяти, который никаким педантиком и датаклассами не достичь.
ээ пропустил похоже. а что, без тестов, сразу в продакшн? Может все же tests папку и какие нить тесты запустить?
И еще не нашел где докер статику собирает. Или вы как-то иначе ее раздаете, типа глобально?
>> что вы такое пишите на 300к строк? Это судя по профилю всё на Django?
Ага. На ней родимой. Начинал с 1.3 версии Django. Сейчас 5.2.a1. В самой моей первой публикации тут в 2019 писал про этот проект. Большая база данных по алкоголю с лютым количеством свистоп€рд€лок для конвертации данных в разные форматы.
Любой ассистент формирует. Некоторые из них пишут именно тесты очень хорошо. Но это всегда по запросу. Самостоятельно - пока ни один. Вот тут немного обсуждалось https://habr.com/ru/articles/876714/
Я согласен с советами на больший контекст. У меня over 300 000 строк, и модель норм отрабатывает и очень вменяемо пишет.
Может дело в том что у него проект с нуля? Но даже с нуля почти любая модель вполне хорошо штампует питон код под задачи.
В общем, похоже что это очень хорошо продуманная статья от DevRel IDE Cursor. Столько народу откликнулось!
Да, его не пригласят:
Ему некогда. Он неизвестен. Для нового проекта брать малоизвестных людей - это риск.
Другой вопрос, его могут порекомендовать.
ну если совсем "душнить", то я сравнивал результаты производства (самолет и бытовые приборы) не способы. Так вот. В автоматизированных линиях есть допустимый процент брака в районе 5%. Потому гарантированность одного и того же результата в районе 95%.
Если с AI я достиг того же - одинаковый результат в 95% случаев - то инженерная задача решена. Или нет?
Удивительно, как люди советующие самим летать на AI-разработанных самолетах пользуются бытовыми приборами собранными на полностью автоматизированных производственных линиях, ах, да, это же другое...
А теперь по делу. Разработкой TDD с AI пользуюсь довольно давно. И прийти к этому довольно просто, надеюсь, что даже самые отъявленные скептики, вероятно задумаются.
Грубо про TDD - есть четко представленная идея / тех задание. Пишем тест на тех задание, представив, что реализация уже есть. После написания теста, пишем реализацию проходящую тест.
Удивительно, но есть работающий пример, как создания теста под "тех задание" так и создания собственно самого кода: это код-генератор клиента и сервера почти на на любом языке по описанию из yaml. Сомневаетесь что это работает? - зайдите на editor.swagger.io
Из текста в код... не находите аналогий со статьей?
Далее. проще. Задача написать хорошую yaml-схему. Тоже довольно просто, поскольку есть отличные YAML валидаторы и какая-никакая спека OpenAPI (кстати новая версия вышла, Arrazo называется) для проверки корректности смысла схемы.
А вот тут LLM просто прекрасно справляются. Поскольку это не код и yaml-схема не может работать или не работать. Это текст. Проверить корректность описания endpoint-a довольно просто визуально.
В итоге в моем примере, LLM, плюс линтеры по тех заданию клепают yaml, а после какой-нибудь connexion генерит код. В моей работе я не могу вспомнить примеры с ноября 2023, когда это не cработало. Тогда Мы/Я в команде начали использовать codewhisperer/codeium для этого.
Да, немного не в стиле идеи статьи, поскольку у нас по тех заданию сразу генерится клиент сервер приложение, а не тесты. Сейчас уже 420 api, работают как часы. Продолжим.
Наш следующий шаг в использовании произошел прошлым летом, когда в codewhisperer появились конвейеры проверяющие верность сгенерированного кода прежде, чем выдать ответ на промпт. Да, обычно это здорово тормозит генерацию ответа, но убыстряет путь к рабочему решению.
Так вот. Вернемся к статье.
Это утверждение я поставил под сомнение: оказывается, машина может писать тесты. Точнее llm пишет задание генератору кода, а с лета 2024 агент научился запускать кодгенератор и предлагать граничные условия для тестов, часто более качественно или подробно, чем это сделал бы я. Например https://github.com/django/django/blob/main/tests/utils_tests/test_numberformat.py - набор случаев созданных человеком ранее не включал большое отрицательное число записанное через e.форму. Уже поправили.
Ну так вот, по поводу писать тесты самому: мой промпт на TDD обсуждался в чате одного из Code-assistant. выглядит примерно так:
Please generate TDD tests for Django project according to this specification:Дальше текст тех задания на разработку.Да, предварительный контекст для модели тоже используется, больше похож на codestyleguide проекта и мои личные предпочтения по коду (например, на питоне писать генераторами без использования [] ). И на мой взгляд, наш ассистент справляется очень хорошо: Тесты работают сразу, граничные условия более продуманные, я часто потом уменьшаю их количество, типа - "тут одного хватит"
Так вот. Я к тому, что задача, которую должна выполнить модель - это сформировать по моему нечеткому тз декларативный документ для запуска кодогенерации. А самих код генераторов вагон и тележка. И они выдают результат работающий без сомнений.
Верить или нет коду от LLM, конечно, решать в итоге разработчику. Но вот сократить время разработки LLM точно могут. И кстати, на мой взгляд, с LLM подход TDD, скорее всего, станет не нужен.
Это стоит рассказать ещё и разработчикам pytest, потому что debugging ≠ testing. Но они упорно используют assert в тестировании.
Ээ... может это перевод? Поскольку тут описываются только встроенные возможности python. Да и то без особого разбора. Есть компрехеншены, и тут же идет map и filter.
Понимаю, трюк - "вы использовали map, filter и list-comprehention, а теперь вы можете написать все в одном стиле":
А так, просто неорганизованные куски примеров использования python.
Mouse Trust 23731. Три года пользуюсь, полет нормальный. Чёт новость странная какая то.
Хм, стартап "фкоропке“ это про ритуальные услуги?
А у меня тоже вопрос к @djcrhk3chabrпро запуск через nginx - сколько воркеров использовали. По моему опыту, от хостинга к хостингу могут отличаться настройки при, казалось бы, одинаково выбранной мощности (hetzner vs djangoeurope).
Ну и в принципе, стоило все же сначала дотянуть до 490-500 rps только методами Django и потом кешить (если все сразу обмазать кешем нормально не померяешь улучшения). Как натянуть со стандартных 70-100 до 500 rps я рассказывал в докладах про "Django-FTL"
Да ладно. Между прочтением про махровые реакт хуки и про профилирование - я рад что с такой статьёй возможно полностью переключиться между темами. Ну и про концептуальный признак гендера я не знал, а очень хороший пример поверхносностного подхода даже в уважаемых научных изданиях.
скорее "бегущий по лезвию", там был настольный компьютер заглядывающий за угол по фотографии.
А может все лучше использовать ast.Ast вместо ispect, для получения всего, что необходимо?
Вторая идея - модно же использовать кеширующий декоратор, он сработает на момент первого вызова функции. проверит тип, вызовет нужную функцию и запомнит на следующие вызовы.
@CitizenOfDreams не такие уж мы и древние. 🧙♂️
на нейронку не похоже: мой gpt выдает мне более связный текст на запрос flask vs django и знает про звезды 🤣
в данном случае, если речь о 2024, то вопрос зачем выбирать fastapi или flask если есть litestar.