не надо смешивать комментарии на нескольких языках вообще не стоит писать комментарии на чём-либо, кроме английского, если только ты не сотрудник Яндекса

зачем пустой print?

файлы .webp стоит убрать в гитигнор, всю директорию целиком и вообще подумать нужно ли это внутри проекта

хорошо попробую.. в спешке. Пет код в общем, но да я приучаю себя к инглишу ... не всегда выходит ;)

что именно ты пытаешься достичь строчкой print(f)?

вообще чтение файлов какое-то дикое напрочь, почитай примеры как читать файлы на питоне внутри директории.

зачем пустой print?

Ванную перевод строки после сообщения

;))

Ванную перевод строки после сообщения

но в этой функции нет других принтов

это типа у него так логи устроены

что именно ты пытаешься достичь строчкой print(f)?

имя файла, точнее его ээм...объект или что там возвращает open. =\.. но имя. просто лог ;)

конкатенация dir + file это плохо, не надо клеить пути методами предназначенными для строк. используй path.join или что получше

open() возвращает итерируемый объект файла, принт не напечатает содержимое его таким образом, и имя файла тоже

не надо смешивать комментарии на нескольких языках вообще не стоит писать комментарии на чём-либо, кроме английского, если только ты не сотрудник Яндекса

Вообще не стоит писать комментарии. Хороший код в них не нуждается.

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

для себя * ... пока что

Вообще не стоит писать комментарии. Хороший код в них не нуждается.

кстати, да. Комментарии на питоне нужны в примерно 1-5% случаев. Например, когда ты пишешь математику или костылишь.

а вот print(*f), кстати, напечатает

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

Чем лучше код написан, тем понятнее что в нем не так

но в будущем учту, что полезно код оформить чтоб от фидбека не краснеть

Я не против комментов на русском и обсуждения PR на русском

Бывает понятнее че English

а вот print(*f), кстати, напечатает

и вот как я например догадаюсь, что мне выведет принт от файлообъекта, открытого c rb-ключом?

Я не против комментов на русском и обсуждения PR на русском

Особенно, если это делать голосом

и вот как я например догадаюсь, что мне выведет принт от файлообъекта, открытого c rb-ключом?

питон же умеет печатать байты через b’text’

но в будущем учту, что полезно код оформить чтоб от фидбека не краснеть

краснеть полезно. И исправлять ошибки тоже. Вот скрывать код из-за стыда это плохой путь.

Особенно, если это делать голосом

Мы обычно дальше второго круга комментов не уходим, идем голосом говорить.

но в будущем учту, что полезно код оформить чтоб от фидбека не краснеть

Код полезно оформлять, чтобы самому легче понимать что ты делаешь

и для логов есть логгинг. не надо использовать принты

Код полезно оформлять, чтобы самому легче понимать что ты делаешь

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

ну такое а потом твои комментарии устаревают

и начинают врать

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

Так не работает :(

в моём случае работало

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

Ещё можно не комменты, а вызовы пустых функций, а ещё есть tdd, тоже из этой серии

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

Литературное программирование?

Кнут за него топит. И ещё один мой коллега за него топит.

И там вроде бы несколько сложнее дело обстоит, насколько я понял.

Ещё можно не комменты, а вызовы пустых функций, а ещё есть tdd, тоже из этой серии

А оно вообще работает?

что работает? пустые вызовы или tdd? Пустыми вызовами я сам регулярно пользуюсь, а tdd тут вроде кто то говорил, что использует, я не использую, хотя идея мне нравится

что работает? пустые вызовы или tdd? Пустыми вызовами я сам регулярно пользуюсь, а tdd тут вроде кто то говорил, что использует, я не использую, хотя идея мне нравится

Я про tdd, да.

ну а почему нет. думаю работает

как раз всякие веб приложения удобно так писать. задал в селениуме что нажать и что должно получиться и вперед с песней

Кто-нибудь использовал ansible модуль для разруливания мавен зависимостей http://docs.ansible.com/ansible/latest/maven_artifact_module.html? Желательно с нескусом 3 в связке.

как раз всякие веб приложения удобно так писать. задал в селениуме что нажать и что должно получиться и вперед с песней

Каждый разговор и инициатива юзать TDD/BDD начинаются с такого выражения. Напоминает кикстартер и геймдев. "А что нам стоит игру построить?"

ну я кстати не апологет tdd, но сама идея имеет право на жизнь. Нет?

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

TDD это прекрасно, когда есть какой-то код вокруг, так что намокал пару классов, ассертов пару написал и вообще душа радуется

DDD форева

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

Упаси господь применять tdd ко всему проекту. Test-driven development (TDD) is a software development process that relies on the repetition of a *very short development cycle*

взял фичу, сделал functional test, написал юниты и дальше делаешь так, чтобы все это заработало. помогает не забывать о мелочах как в процессе разработки так и потом во время костылинга (типа забыл уже для чего я все это писал)

DDD форева

Дринк драйв девелопмент ?

Дринк драйв девелопмент ?

Отличная парадигма, Балмер одобряет :)

TDD это прекрасно, когда есть какой-то код вокруг, так что намокал пару классов, ассертов пару написал и вообще душа радуется

мне кажется tdd будет работать только если у тебя есть спецификация и ты по ней реализуешь что-то.

мне кажется tdd будет работать только если у тебя есть спецификация и ты по ней реализуешь что-то.

В прожект менеджменте когда-то было такое явление, как use-case driven development, или как-то так. Идея состояла в том, PM/BA/PO описывает требования в виде юзкейса, с ожиданиями и исключениями. Как и на все новшества, на это был бум. ПМы имели свои формы, что позволяли описывать юзкейсы, опции, варианты поведения. Это было так сложно и не нужно, что больше мешало, чем помогало. Вот так вот забавно было

Я бы перефразировал, tdd будет работать только если у тебя есть техническая спецификация и ты по ней реализуешь что-то

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

Но не на работе!

Нельзя!

:)

Нельзя!

нельзя использовать tdd или тесты?

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

У тебя не бывало так, что ты написал тесты, начал имплементацию, а уже через час работы оказалось что тесты что ты написал не нужны, а нужно переписывать их, как миниму на процентов 70?

Это из того случая, когда ты пишешь тесты на проект, не ознакомившись с ним. Тогда я тесты не пишу, если новый проет заходит — просто действительно потом затрешь все.

Но если ты уже “не первый день”, то они тебя и ускоряют, рли.

ERROR: S client not available

Часто вижу чуваков, которые какие-то даже алгоритмические действия долго пишут, советуются. А вынеси ты это в тесты, нагрузи, и сразу решишь задачу.

Раньше я скептически к TDD относился и не верил в полезность, но заставил себя их юзать, как и Vim, как и все консольное.

Я не редко замечал при использовании TDD, что вроде как ты написал тесты, но в процессе реализации оказывается что что-то в системе не подходит, нужно что-то новое написать, а оригинальное решение даже упростить, в следствии чего разве что поведенческие тесты оказались бы стабильными

Часто вижу чуваков, которые какие-то даже алгоритмические действия долго пишут, советуются. А вынеси ты это в тесты, нагрузи, и сразу решишь задачу.

А вот тут соглашусь. Когда у тебя есть blackbox, TDD стабильно приносит выгоду, банально на табличных тестах

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

У тебя не бывало так, что ты написал тесты, начал имплементацию, а уже через час работы оказалось что тесты что ты написал не нужны, а нужно переписывать их, как миниму на процентов 70?

а если смотреть на это как на сигнал о том, что требования не были интепретированы верно? мол - вернись к задаче, пересмотри, а то ли ты пишешь, если тесты разошлись с действительностью сразу на 70% ?

а если смотреть на это как на сигнал о том, что требования не были интепретированы верно? мол - вернись к задаче, пересмотри, а то ли ты пишешь, если тесты разошлись с действительностью сразу на 70% ?

Я больше о технической реализации. Например, у тебя была задача добавить сэмплирование в измерение трафика между двумя узлами. Ты подумал что всё просто, начал писать интеграционку, для определённого API. В процессе имплементации выяснилось, что запрос работает недостаточно быстро, так что приходится реализовывать эту логику на стороне вообще другого продукта/класса

Я больше о технической реализации. Например, у тебя была задача добавить сэмплирование в измерение трафика между двумя узлами. Ты подумал что всё просто, начал писать интеграционку, для определённого API. В процессе имплементации выяснилось, что запрос работает недостаточно быстро, так что приходится реализовывать эту логику на стороне вообще другого продукта/класса

м, а я просто больше в контексте юнитов это воспринимаю чем интерационки

м, а я просто больше в контексте юнитов это воспринимаю чем интерационки

А с юнитами то ещё больше простора ? Я в процессе исполнения задачи могу решить что всё-таки какой-то иной подход более выгодный в силу новых найденных фактов при работы с каким-то экстернальным сервисом. В результате возвращаешься к тестам, которые переписываешь. Потому у меня больше прижился такой вариант: если это blackbox, то TDD юнитами идеально подходит, иначе сначала необходимо либо детальное исследование задачи, либо proof-of-concept, который уже обрастает тестами

внезапно, pypy умеет векторизовать python-код

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

внезапно, pypy умеет векторизовать python-код

по умолчанию?

хм, похоже чтобы включить нужно всё-таки флаг передать --jit vec=1

хм, похоже чтобы включить нужно всё-таки флаг передать --jit vec=1

vec_all=1

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

Тесты нужны, TDD и BDD это очень хорошо и важно. Проблема в том, что проект делать надо, не всегда, не на всех стадиях проекта есть возможность в принципе писать тесты. Есть у заказчика деньги на месяц твоей работы, уж лучше пусть оно будет иногда падать, но покажет даст business value, чем не будет проекта вовсе

вечная битва тестов и бизнеса в условиях плохо отлаженных процессов

Тесты чудесно работают для бэкэнда и библиотек, но для UI все грустно. Те TDD по определению не работает для UI так как UI пляшет не от API, а просто писать тесты чтобы зафиксировать функциональность и ловить регрессии тоже дело не благодарное - очередной редизайн и все выкидывать нафиг. Для себя решил, что если тестировать UI то только снэпшотами которые легко перегенерить.

Тесты чудесно работают для бэкэнда и библиотек, но для UI все грустно. Те TDD по определению не работает для UI так как UI пляшет не от API, а просто писать тесты чтобы зафиксировать функциональность и ловить регрессии тоже дело не благодарное - очередной редизайн и все выкидывать нафиг. Для себя решил, что если тестировать UI то только снэпшотами которые легко перегенерить.

как то странно. как редизайн влияет на функциональные тесты, если функциональность при этом сохранилась? ну покрасили кнопку из красного в зеленый цвет, перенесли ее справа на лево. какая тестам разница?

как то странно. как редизайн влияет на функциональные тесты, если функциональность при этом сохранилась? ну покрасили кнопку из красного в зеленый цвет, перенесли ее справа на лево. какая тестам разница?

ну редизайн не всегда это только цвета, могут поменять весь UX, все взаимодействие

вообще от проекта конечно зависит, если это старый и взрослый софт то да, тесты на ui можно и нужно писать, а если продукт все еще материализуется то лучше даже не начинать

как то странно. как редизайн влияет на функциональные тесты, если функциональность при этом сохранилась? ну покрасили кнопку из красного в зеленый цвет, перенесли ее справа на лево. какая тестам разница?

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

если редизайн меняет функциональность, то само собой надо менять тесты. причем, согласно tdd с замены тестов и надо начать )

В проектах сталкивались с кейсами, когда под UI писали тесты, потом менялся дизайн, тесты просто приходилось просто удалять. Разработчик тратил 4 часа на написание тестов, 2 часа на задачу. Итого, 4 часа оказались потрачены "никуда"

что то мне подсказывает, что методика tdd в этом не виновата )

Именно

TDD идеален, BDD очень красив, вот только не всегда возможно построить команду из людей(PO включительно), чтобы value в этом был и это было оправдано

это факт!

В продолжение темы тестирования. Подскажите, плз, можно ли в джанге (либа django-pytest + Mock) выделить под тесты отдельный кэш-сторадж в Redis? На подобие, как делается при тестах для БД — просто создаётся на лету тестовая табличка, куда всё пишется? Поясню, иногда нужно тестить моканые функции, которые работают с кэшем — было бы удобнее иметь изолированное место под эти тесты ?

В продолжение темы тестирования. Подскажите, плз, можно ли в джанге (либа django-pytest + Mock) выделить под тесты отдельный кэш-сторадж в Redis? На подобие, как делается при тестах для БД — просто создаётся на лету тестовая табличка, куда всё пишется? Поясню, иногда нужно тестить моканые функции, которые работают с кэшем — было бы удобнее иметь изолированное место под эти тесты ?

Заоверрайдь в тестах настройки кеша как тебе нужно, вот и все

В продолжение темы тестирования. Подскажите, плз, можно ли в джанге (либа django-pytest + Mock) выделить под тесты отдельный кэш-сторадж в Redis? На подобие, как делается при тестах для БД — просто создаётся на лету тестовая табличка, куда всё пишется? Поясню, иногда нужно тестить моканые функции, которые работают с кэшем — было бы удобнее иметь изолированное место под эти тесты ?

Там же есть бэкенд local mem storage, с ним вроде проблем не было, так что и редиска не нужна даже: CACHES = { 'default': { 'BACKEND': 'django.core.cache.backends.locmem.LocMemCache', 'LOCATION': 'unique-snowflake', } }

Там же есть бэкенд local mem storage, с ним вроде проблем не было, так что и редиска не нужна даже: CACHES = { 'default': { 'BACKEND': 'django.core.cache.backends.locmem.LocMemCache', 'LOCATION': 'unique-snowflake', } }

спасибо за подсказку

Нп, пиши если будут проблемы )