запускаю правда не релиз, а lein ring server.
собственно вся обвязка очень и очень медленно стартует.
В тоже время sbcl (Common Lisp) по сравнению с кложой(lein) можно сказать "летает".
Да и размер зависимостей в разы меньше.
Вот и думаю, стоит ли скорость лиспа менять на красивые хеш-мапки кложи?
Кложа конечно восхитительно смотрится в кодэ.
Здравствуйте, varenikAA, Вы писали:
AA>запускаю правда не релиз, а lein ring server. AA>собственно вся обвязка очень и очень медленно стартует. AA>В тоже время sbcl (Common Lisp) по сравнению с кложой(lein) можно сказать "летает". AA>Да и размер зависимостей в разы меньше. AA>Вот и думаю, стоит ли скорость лиспа менять на красивые хеш-мапки кложи? AA>Кложа конечно восхитительно смотрится в кодэ.
Она стартует медленно, но потом всё вроде более-менее нормально. Ну да, прожорливая, ну да, генерируемый код оставляет желать лучшего в плане производительности (дизассемблируй, много сюрпризов, особенно с "рекомендуемыми практиками" типа map и т.п.), но это не проблема даже. Серьезная проблема в другом, в типизации.
После того как полгода писал продуктовый код (не интеграционные тесты) на Elixir пришел к выводу, что динамика в проде вообще не опция, если ты планируешь писать больше 50 KLOC. Слишком много неожиданностей и неприятностей. Только статическая типизация, без вариантов. Хочется экзотики в проде — то, наверное, надо брать Haskell или F#. А лучше не брать экзотики вообще.
Да, я полностью поменял свое мнение в этом вопросе, но продолжаю считать что Python для интеграционных тестов, скриптов и POC это самое то что нужно
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, varenikAA, Вы писали:
AA>>запускаю правда не релиз, а lein ring server. AA>>собственно вся обвязка очень и очень медленно стартует. AA>>В тоже время sbcl (Common Lisp) по сравнению с кложой(lein) можно сказать "летает". AA>>Да и размер зависимостей в разы меньше. AA>>Вот и думаю, стоит ли скорость лиспа менять на красивые хеш-мапки кложи? AA>>Кложа конечно восхитительно смотрится в кодэ.
KP>Она стартует медленно, но потом всё вроде более-менее нормально. Ну да, прожорливая, ну да, генерируемый код оставляет желать лучшего в плане производительности (дизассемблируй, много сюрпризов, особенно с "рекомендуемыми практиками" типа map и т.п.), но это не проблема даже. Серьезная проблема в другом, в типизации.
KP>После того как полгода писал продуктовый код (не интеграционные тесты) на Elixir пришел к выводу, что динамика в проде вообще не опция, если ты планируешь писать больше 50 KLOC. Слишком много неожиданностей и неприятностей. Только статическая типизация, без вариантов. Хочется экзотики в проде — то, наверное, надо брать Haskell или F#. А лучше не брать экзотики вообще.
KP>Да, я полностью поменял свое мнение в этом вопросе, но продолжаю считать что Python для интеграционных тестов, скриптов и POC это самое то что нужно
Рич Хикки на это замечает:
И мне нравится задавать этот вопрос: что верно
для каждой ошибки, найденной в продакшене?
(Ответ аудитории: Кто-то её написал.)
Она была кем-то написана. Да.
Что ещё более интересно:
она прошла проверку типов.
Что ещё она сделала?
Она прошла все тесты.
Да. Что теперь вам нужно сделать?
Я считаю, что мы в мире, как я его называю
оградительного программирования.
Грустно говорить это.
Мы такие: Я могу делать изменения,
потому что у меня есть тесты.
Кто так делает?
Кто водит машину,
стукаясь об ограждения, говоря:
«Вау! Я рад, что у меня есть эти ограждения,
иначе я никогда бы не приехал вовремя.»
И установленные ограждения
помогают вам добраться до места?
Вроде, ограждения направляют вас?
Нет. Ограждения повсюду.
Они не направляют вашу машину
в какое-то конкретное направление.
Здравствуйте, varenikAA, Вы писали:
AA>Рич Хикки на это замечает:
убрал много бла-бла-бла.
Да, он в чем-то прав, на том же JS кучу чего написали, при том что это динамический язык. Тем не менее, если хочется упростить жизнь и ускорить развитие продукта, именно развитие, а не изначальное написание, то с динамикой связываться не надо. Статическая типизация — это те же тесты, только принудительного характера, которые ты никак не можешь игнорировать. Так что его аналогия в данном случае кривая.
Здравствуйте, varenikAA, Вы писали:
AA>И установленные ограждения AA>помогают вам добраться до места? AA>Вроде, ограждения направляют вас? AA>Нет. Ограждения повсюду. AA>Они не направляют вашу машину AA>в какое-то конкретное направление.
Ну правильные тесты гарантируют что протестированный воркфлоу остался рабочим так-то. Т.е. можно гарантированно доехать до нужной точки, по аналогии с автомобилем.
Здравствуйте, sambl74, Вы писали:
AA>>Они не направляют вашу машину AA>>в какое-то конкретное направление.
S>Ну правильные тесты гарантируют что протестированный воркфлоу остался рабочим так-то. Т.е. можно гарантированно доехать до нужной точки, по аналогии с автомобилем.
Это какие же интересно тесты правильные?
Гарантию часовой завод дает.
Если есть сложный, запутанный стэйт, то обложить все кейсы тестами не реально.
Все равно вылезит. Рич предлагает другой путь — по возможности упростить задачу, тогда и ошибок удаться избежать.
Здравствуйте, varenikAA, Вы писали:
AA>Это какие же интересно тесты правильные?
Тесты, который гарантируют работоспособность пользовательских сценариев
AA>Гарантию часовой завод дает.
Да?
AA>Если есть сложный, запутанный стэйт, то обложить все кейсы тестами не реально.
Почему? Ленивый штоле?
Вот самый запущенный случай — Безумие и успех кода Oracle Database
AA>Все равно вылезит. Рич предлагает другой путь — по возможности упростить задачу, тогда и ошибок удаться избежать.
Ага-ага. Плохо быть бедным и больным — надо быть богатым и здоровым Ну и так-то упрощёние задачи позволяет и тесты хорошие написать — так что это правильно, но иногда с этим таки вылезают проблемы.
Здравствуйте, sambl74, Вы писали:
S>Здравствуйте, varenikAA, Вы писали:
AA>>Если есть сложный, запутанный стэйт, то обложить все кейсы тестами не реально.
S>Почему? Ленивый штоле?
S>Вот самый запущенный случай — Безумие и успех кода Oracle Database
Ну, интересная статья. Опять же сказки на ночь. Рич Х. тоже не лаптем щи хлебает. До кложи и собственного взгляда на разработку он десятки лет программировал на плюсах.
Он отрицает не столько тестирование, сколько идею тупого кодинга как это было в оракл. Прежде чем кодить требуется осмыслить задачу.
Возможно в оракле тоже думали, но производительность была важнее. Кто знает почему так получилось. Возможно, это было время когда еще не сформировались нужные подходы.
И да, помню был опыт установки оракл стандарт на "почти сервер(виндос)" и почему-то регулярно билась база. Как будто нужны были какие-то особые условия вроде рэйд-массивов с нормальным кэшем.
AA>>Все равно вылезит. Рич предлагает другой путь — по возможности упростить задачу, тогда и ошибок удаться избежать.
S>Ага-ага. Плохо быть бедным и больным — надо быть богатым и здоровым Ну и так-то упрощёние задачи позволяет и тесты хорошие написать — так что это правильно, но иногда с этим таки вылезают проблемы.
В основном согласен, тольео не понял насчет "вылезают".
Лично мое мнение, чем строже ЯП, тем больше времени уйдет на разработку той же фичи. просто проверьте, если есть код на каком нибудь C#,F# и на ванильном js.
В последнем словно крылья вырастают. Любую проблему можно решить кучей способов. По сути js — lisp для браузера ( с сишным синтаксом).
Здравствуйте, kaa.python, Вы писали:
KP>После того как полгода писал продуктовый код (не интеграционные тесты) на Elixir пришел к выводу, что динамика в проде вообще не опция, если ты планируешь писать больше 50 KLOC. Слишком много неожиданностей и неприятностей. Только статическая типизация, без вариантов. Хочется экзотики в проде — то, наверное, надо брать Haskell или F#. А лучше не брать экзотики вообще.
Может это проблема элексира? Он динамичный?
Haskell или F#
— упаси, бог!
Простой пример:
match x with
| A -> f1()
| B -> f2()
...
и
(defgeneric description (object)
(:documentation"Return a description of an object."))
(defmethod description ((object integer))
(format nil"The integer ~D" object))
(defmethod description ((object float))
(format nil"The float ~3,3f" object))
(description 10); => "The integer 10"
(description 3.14); => "The float 3.140"
обобщенные функции в CLOS наголову выше паттерн-матча, который по сути — те же if-ы.
Совершенно не уменьшает связанность и следовательно сложность ПО, даже наоборот, каждый матч это новый клубок.
AA>>Если есть сложный, запутанный стэйт, то обложить все кейсы тестами не реально.
S>Почему? Ленивый штоле?
Потому что кейс на баг может быть из разряда «открыть файл, открыть файл параллельно, закрыть файл из одного потока, записать из второго, открыть из первого, записать из первого, закрыть из второго, закрыть из первого».
Ручками ты такой тест кейс не напишешь. А property-based и fuzzy-тестирование надо а) уметь и б) иметь библиотеки, которые в них умеют.
AA>обобщенные функции в CLOS наголову выше паттерн-матча, который по сути — те же if-ы.
обобщенные функции в CLOS являются убогим, многословным, жестко прибитым гвоздями говном по сравнению с паттерн-матчингом. Можно начать хотя бы с того, что обобщенные функции, как видно из самого названия, доступны только для объявления функций (весьма кривым способом с парой defgeneric/defmatohd, потому что иначе «самый лучший язык на земле» даже не способен понять, что происходит). Паттерн матчинг в функциональных языках доступен как для объявления функций так и внутри функций.
В итоге в CLOS есть defgeneric/defmethod + куча if'ов внутри. В некоторых других языках есть просто единообразный pattern matching.
Здравствуйте, Mamut, Вы писали:
M>Потому что кейс на баг может быть из разряда «открыть файл, открыть файл параллельно, закрыть файл из одного потока, записать из второго, открыть из первого, записать из первого, закрыть из второго, закрыть из первого».
M>Ручками ты такой тест кейс не напишешь. А property-based и fuzzy-тестирование надо а) уметь и б) иметь библиотеки, которые в них умеют.
чёт не вижу тут сложного кейса. в чём тут конкретно проблема?
M>>Потому что кейс на баг может быть из разряда «открыть файл, открыть файл параллельно, закрыть файл из одного потока, записать из второго, открыть из первого, записать из первого, закрыть из второго, закрыть из первого».
M>>Ручками ты такой тест кейс не напишешь. А property-based и fuzzy-тестирование надо а) уметь и б) иметь библиотеки, которые в них умеют.
S>чёт не вижу тут сложного кейса. в чём тут конкретно проблема?
Как ты самостоятельно сможешь найти этот кейс? Именно этот, именно в этом порядке.
Здравствуйте, Mamut, Вы писали:
M>Как ты самостоятельно сможешь найти этот кейс? Именно этот, именно в этом порядке.
Тестеры/пользователи наткнулись, завели багу, её воспроизвели, поправили, написали тест. Всё, кейс рабочий. Навсегда Это же так и работает, не?
Пользователи же не тыкают в программу бездумно — выполняют какие-то рабочие сценарии. Их так-то ограниченное количество.
Проверять все возможные ветвления и сценарии это конечно хорошо, но избыточно. Это как с идеальной коробкой передач — которая экономит бензин на 50%, но при этом будет занимать очень много места. В случае с покрытием всех возможных сценариев код имхо будет очень сильно разбухать.
M>>Как ты самостоятельно сможешь найти этот кейс? Именно этот, именно в этом порядке.
S>Тестеры/пользователи наткнулись, завели багу
Стоп-стоп. Все начиналось с
AA>>Если есть сложный, запутанный стэйт, то обложить все кейсы тестами не реально.
S>Почему? Ленивый штоле?
А тут ВНЕЗАПНО нет, все кейсы тестами не обложил, а ждешь, чтобы на этот кейс наткнулись пользователи/тестеры и завели багу. Ленивый, что ле?
S>, её воспроизвели, поправили, написали тест. Всё, кейс рабочий. Навсегда Это же так и работает, не?
Что случилось с «программист должен написать все тест кейсы иначе он ленивый»?
S>Пользователи же не тыкают в программу бездумно — выполняют какие-то рабочие сценарии. Их так-то ограниченное количество.
S>Проверять все возможные ветвления и сценарии это конечно хорошо, но избыточно.
Ну то есть «Почему? Ленивый штоле?» на проверку оказалось «Если есть сложный, запутанный стэйт, то обложить все кейсы тестами не реально.», и непонятно, почему ты с этим споришь.
А про «тестеры/пользователи наткнутся», воспроизвели, поправили, написали тест, вот тебе реальная жизнь, а не фантазии. Описание решения проблемы, включая воспроизведение, с 36:55 (описание самой проблемы, в кратце, на 27:00). Да и вообще вся презентация про такие проблемы.
Здравствуйте, Mamut, Вы писали:
M>Стоп-стоп. Все начиналось с
M>
AA>>>Если есть сложный, запутанный стэйт, то обложить все кейсы тестами не реально.
S>>Почему? Ленивый штоле?
M>А тут ВНЕЗАПНО нет, все кейсы тестами не обложил, а ждешь, чтобы на этот кейс наткнулись пользователи/тестеры и завели багу. Ленивый, что ле?
Так все кейсы — это все пользовательские сценарии. А не всё многообразие того, что можно сделать в программе.
S>>, её воспроизвели, поправили, написали тест. Всё, кейс рабочий. Навсегда Это же так и работает, не?
M>Что случилось с «программист должен написать все тест кейсы иначе он ленивый»?
Ну в ТЗ есть спецификация, какие сценарии пользователя должны работать — вот это и есть "все кейсы". Для них и пишутся тесты.
Избыточно потому, что программа должна делать хорошо то, что написано в спецификации. Если она что-то делает плохо, когда пользователь отклоняется от описанного сценария — то либо дополняем спецификацию и соответственно дорабатываем продукт и покрываем новый кейс тестами, либо пишем в документацию "Вот так делать нельзя!!!". Ну и можно запретить такое поведение пользователя и написать тест и на это
S>>Это как с идеальной коробкой передач — которая экономит бензин на 50%, но при этом будет занимать очень много места. В случае с покрытием всех возможных сценариев код имхо будет очень сильно разбухать.
M>Ну то есть «Почему? Ленивый штоле?» на проверку оказалось «Если есть сложный, запутанный стэйт, то обложить все кейсы тестами не реально.», и непонятно, почему ты с этим споришь.
В твоём понимании это не "тесты на все кейсы", а некие идеальные тесты, которые покрывают бесконечное количество вариаций входных данных и действий пользователя. И да — время выполнения тоже бесконечно
M>А про «тестеры/пользователи наткнутся», воспроизвели, поправили, написали тест, вот тебе реальная жизнь, а не фантазии. Описание решения проблемы, включая воспроизведение, с 36:55 (описание самой проблемы, в кратце, на 27:00). Да и вообще вся презентация про такие проблемы.
M>https://youtu.be/zi0rHwfiX1Q?t=2215
S>Так все кейсы — это все пользовательские сценарии. А не всё многообразие того, что можно сделать в программе.
Откуда ты знаешь, что именно этот кейс — пользовательский сценарий, а «все многообразие» — нет?
M>>Что случилось с «программист должен написать все тест кейсы иначе он ленивый»? S>Ну в ТЗ есть спецификация, какие сценарии пользователя должны работать — вот это и есть "все кейсы". Для них и пишутся тесты.
А, месье из мира эльфов и фей.
S>Если у тебя в ТЗ написано "всё должно работать", то мне конечно тебя жаль
1. В какой спецификации?
2. Почему ты уверен, что спецификация покроет все варианты поведения программы?
3. Почему ты уверен, что спецификация покроет все варианты использования пользователем?
S>Если она что-то делает плохо, когда пользователь отклоняется от описанного сценария — то либо дополняем спецификацию и соответственно дорабатываем продукт и покрываем новый кейс тестами, либо пишем в документацию "Вот так делать нельзя!!!". Ну и можно запретить такое поведение пользователя и написать тест и на это
А, месье из мира эльфов и фей.
M>>Ну то есть «Почему? Ленивый штоле?» на проверку оказалось «Если есть сложный, запутанный стэйт, то обложить все кейсы тестами не реально.», и непонятно, почему ты с этим споришь. S>В твоём понимании это не "тесты на все кейсы", а некие идеальные тесты, которые покрывают бесконечное количество вариаций входных данных и действий пользователя. И да — время выполнения тоже бесконечно
Ты это говоришь и описываешь какие-то идеальные тесты и кейсы, которые все зарание продумали, тзательно записали в спецификации, а потом каждый из них написан и протестирован программистом.
M>>А про «тестеры/пользователи наткнутся», воспроизвели, поправили, написали тест, вот тебе реальная жизнь, а не фантазии. Описание решения проблемы, включая воспроизведение, с 36:55 (описание самой проблемы, в кратце, на 27:00). Да и вообще вся презентация про такие проблемы.
M>>https://youtu.be/zi0rHwfiX1Q?t=2215
S>Гляну потом. Интересно
Очень рекомендую видео, да. Как раз проказывает разницу между реальным миром и фантазиями на тему «все должно быть описано в ТЗ и протестировано».
Ага
S>>Если у тебя в ТЗ написано "всё должно работать", то мне конечно тебя жаль
M>Оно обычно так и написано. Ну и обязательно посмотри видео, которое я привел, с самого начала. Они там тестируют и ТЗ в том числе, и находят ошибки в самом ТЗ.
Ну и что? Ошибка в ТЗ обычное явление и повод для его доработки.
M>1. В какой спецификации? M>2. Почему ты уверен, что спецификация покроет все варианты поведения программы?
Зачем? У нас описан сценарий, которому следует пользователь. Программа должна всегда корректно его обрабатывать.
M>3. Почему ты уверен, что спецификация покроет все варианты использования пользователем?
Потому что по спецификации пишется документация, по которой пользователь работает. Ну вот да, единственное моё спорное допущение — что это идеальный пользователь, который читает документацию и работает по ней
S>>Если она что-то делает плохо, когда пользователь отклоняется от описанного сценария — то либо дополняем спецификацию и соответственно дорабатываем продукт и покрываем новый кейс тестами, либо пишем в документацию "Вот так делать нельзя!!!". Ну и можно запретить такое поведение пользователя и написать тест и на это
M>А, месье из мира эльфов и фей.
Да, из мира где выпускается MVP и потом по результатам тестирования и фидбеку от пользователей допиливается функционал приложения, которое всегда стабильно работает на заданном наборе сценариев. Да, и программа как сервис, поэтому все пользователи всегда работают с актуальной версией. В прошлом проекте было десктопное приложение, и там кроме тестов было около 5000 описанных тест кейсов пользовательских сценариев.
M>>>Ну то есть «Почему? Ленивый штоле?» на проверку оказалось «Если есть сложный, запутанный стэйт, то обложить все кейсы тестами не реально.», и непонятно, почему ты с этим споришь. S>>В твоём понимании это не "тесты на все кейсы", а некие идеальные тесты, которые покрывают бесконечное количество вариаций входных данных и действий пользователя. И да — время выполнения тоже бесконечно
M>Ты это говоришь и описываешь какие-то идеальные тесты и кейсы, которые все зарание продумали, тзательно записали в спецификации, а потом каждый из них написан и протестирован программистом.
Да, так и работаем. Ощути тленность своего бытия
M>>>А про «тестеры/пользователи наткнутся», воспроизвели, поправили, написали тест, вот тебе реальная жизнь, а не фантазии. Описание решения проблемы, включая воспроизведение, с 36:55 (описание самой проблемы, в кратце, на 27:00). Да и вообще вся презентация про такие проблемы.
M>>>https://youtu.be/zi0rHwfiX1Q?t=2215
S>>Гляну потом. Интересно
M>Очень рекомендую видео, да. Как раз проказывает разницу между реальным миром и фантазиями на тему «все должно быть описано в ТЗ и протестировано».
Какая фантазия — реальный процесс, ты чё В мокапах, которые дают на разработку, уже показано, по какой кнопке чё происходит и всё это уже кучу раз обсуждено.
M>>Оно обычно так и написано. Ну и обязательно посмотри видео, которое я привел, с самого начала. Они там тестируют и ТЗ в том числе, и находят ошибки в самом ТЗ.
S>Ну и что? Ошибка в ТЗ обычное явление и повод для его доработки.
Ну и то, что твое «ленивый што ле» продолжает разбиваться об стену жестокой реальности. Ну и да. Описанный ТЗ — промышленные стандарты на взаимодействие компонентов в машинах.
M>>3. Почему ты уверен, что спецификация покроет все варианты использования пользователем?
S>Потому что по спецификации пишется документация, по которой пользователь работает. Ну вот да, единственное моё спорное допущение — что это идеальный пользователь, который читает документацию и работает по ней
4. Почему ты уверен, что спецификация описывает поведение пользователя, как человека. Например, в видео, которе ты, видать, никогда и не посмотришь, никакого пользователя не было. Была система под нагрузкой, которая раз в один-два месяца падала с невнятной ошибкой.
M>>А, месье из мира эльфов и фей.
S>Да, из мира где выпускается MVP и потом по результатам тестирования и фидбеку от пользователей допиливается функционал приложения, которое всегда стабильно работает на заданном наборе сценариев.
Прекрасноэ, конечно.
Сначала «программисты ленивые, что не пишут тесты на все кейсы», потом «а что сложного в кейсе», потом «не, ну мы нифига не пишем все тесты, мы пишем что смошгли, а потом ждем баг репортов от тестеров и пользователей».
M>>Ты это говоришь и описываешь какие-то идеальные тесты и кейсы, которые все зарание продумали, тзательно записали в спецификации, а потом каждый из них написан и протестирован программистом.
S>Да, так и работаем. Ощути тленность своего бытия
Вы не рабоатете так. Вы работаете реально по принципу «написали те тесты, что смогли придумать, ждем отзыва от тестеров и реальных пользователей. получили отзыв о баге, починили баг, написали тест». Ну то есть ровно так, как работают все.
M>>>>А про «тестеры/пользователи наткнутся», воспроизвели, поправили, написали тест, вот тебе реальная жизнь, а не фантазии. Описание решения проблемы, M>>Очень рекомендую видео, да. Как раз проказывает разницу между реальным миром и фантазиями на тему «все должно быть описано в ТЗ и протестировано».
S>Какая фантазия — реальный процесс, ты чё В мокапах, которые дают на разработку, уже показано, по какой кнопке чё происходит и всё это уже кучу раз обсуждено.
«Мокапы, кнопки». Видео посмотри один раз уже, да.
