В дебрях водопада
Aug. 29th, 2018 09:27 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
vit_rЖутко мучаются проповедники agile, пытаясь изобретать то прототипы, то спиральную модель...
Это я сходил на очередную тусовку. DevOps Guru Switzerland: Open Source Performance Test Automation mit JMeter, Selenium und Taurus
Сразу ссылки:
Abstraction level above testing tools: Taurus (http://gettaurus.org/)
Run massively scalable, open source-based tests: BlazeMeter (https://www.blazemeter.com/)
Дальше немного заметок на полях. Частично на английском, потому что так записано в блокноте, а переводить влом.
Пропорция на этот раз была полтора к одному. В смысле, на трёх пришедших извне два организатора. Впрочем, всего народу было меньше двадцати человек.
Очень неудобно в этот Клотен ехать. Особенно отсюда, точнее обратно. Ветки электричек сюда и туда расходятся как раз перед аэропортом. Обратно ехал, вообще, на автобусах.
Заодно в аэропорту набрал туристических брошюр. Первого сентября в Цюрихе ночь музеев. И на этих выходных аэропорт празднует семидесятилетие.
Первый раз вижу, чтобы доклад начинался со шпионажа.
По идее должно было выглядеть по типу:
- Как вы это делате?
- Вот так.
- А надо вот этак.
Но было так:
- Как вы это делаете?
- Вот так.
- Спасибо.
Короче, диалога не получилось.
Увидел интересное добавление к agile версии модели водопада. Development и Test связаны циклом коррекции-изменения.
То есть, все прямоугольнички по новой религией стрелочками в одну сторону, а между тестом и разработкой есть обратная связь.
Ещё десять лет - и додумаются до того, что разработка даёт сообщения об ошибках в дизайн. Дизайн - в сбор требований. А requirements engineering не только получает приказ начинать, но и что-то отправляет обратно прямоугольничку инициации. Например, сообщение "Нафиг-нафиг. Мы с такими пожеланиями только денег сожжём немеряно, но ничего путного в результате не выдадем."
Узнал новое волшебное слово: "Shift Left Model".
Если раньше в начале проекта работали аналитики, потом подключались дизайнеры, потом медленно набирали силу разработка и тестирование, то сейчас предлагается это всё загнать влево. Чтоб не только аналитики радовались, но и тестировщики с разработчиками резвились на сырых требованиях.
Если кто-то скажет, что отсутствие мозгов решили компенсировать грубой силой, тот будет абсолютно прав.
Но, увы, это реалии современной индустрии. Фиг сейчас найдёшь requirements engineer, который скажет "Вы на самом деле хотите раскрасить интерфейс в эти цвета?" или "Вы уверены, что не стоит рассматривать случаи, когда пользователь вводит данные с ошибкой?"
Помнится, двадцать лет назад специалист по IT-договорам, услышав ранних предвестников agile, с удивлением замечал, что для этого клиент должен платить не за сделаннную работу, а за то, что работа делается. Точнее, что-то делается, а что - не понятно.
Время показало, что заказчики под такое найдутся. Толпами. И большими деньгами.
Если им такое нравится, пусть платят.
Несколько интересных фактов:
- Тестирование бывает разрушающее, которое ищет ошибки, и верифицирующее, которое говорит, что ошибок нет. В фармафирмах любят второе. По этой причине практически всё делается вручную и производит гору бумаги.
- Licenses create queues and bottlenecks.
С одной стороны, хорошо, когда все-все-все могут тестировать всё что угодно. С другой - дешевле, если разработчики будут не гонять массивные тесты после каждого маленького изменения, а думать перед тем, как что-то в коде менять.
Мечты... Мечты...
- Чтобы изменить набор тестовых данных в банке надо обратиться к ответственным. И они поменяют. Время это займёт от двух недель до двух лет. (Может человек и преукрасил немного, но цифра правдоподобная.)
- Performance tools report mean values but the interesting part is the distribution of test results.
- Manual test scripts trap: It is simple to create a script that records user's actions but this script is costly to change.
Естественно, в этих замечательных тулах нельзя добавить параметры и случайные отклонения. А, когда один и тот же тест размножается под много клиентов, мы меряем не поведение системы под реальной нагрузкой, а совершенно искусственный случай.
Тысяча клиентов, одновременно выбравших один и тот же пункт в меню, - это не наплыв посетителей, а DOS атака.
- Интересно, что второй докладчик пропагандировал диаметрально противоположный подход: Generate test automation scripts from requirements.
What is wrong with this approach? The word "generate". Miracle is moved to the responsibilities of a business analyst.
Ещё я попытался объяснить людям, что тесты не могут быть слишком хорошими.
Development creates value. Testing eats resources. If tests produce too many errors this errors will be ignored. If this is impossible, developers will blame test scenarios as wrong or irrelevant and as result such "productive" tests will be switched off.
If developers try to be honest with tests that stop them, managers will change this unproductive attitude.
И в заключение лучшее за вчера.
Each advocate of each popular belief in IT is excellent in one aspect: the critique of problems of other beliefs.
Это я сходил на очередную тусовку. DevOps Guru Switzerland: Open Source Performance Test Automation mit JMeter, Selenium und Taurus
Сразу ссылки:
Abstraction level above testing tools: Taurus (http://gettaurus.org/)
Run massively scalable, open source-based tests: BlazeMeter (https://www.blazemeter.com/)
Дальше немного заметок на полях. Частично на английском, потому что так записано в блокноте, а переводить влом.
Пропорция на этот раз была полтора к одному. В смысле, на трёх пришедших извне два организатора. Впрочем, всего народу было меньше двадцати человек.
Очень неудобно в этот Клотен ехать. Особенно отсюда, точнее обратно. Ветки электричек сюда и туда расходятся как раз перед аэропортом. Обратно ехал, вообще, на автобусах.
Заодно в аэропорту набрал туристических брошюр. Первого сентября в Цюрихе ночь музеев. И на этих выходных аэропорт празднует семидесятилетие.
Первый раз вижу, чтобы доклад начинался со шпионажа.
По идее должно было выглядеть по типу:
- Как вы это делате?
- Вот так.
- А надо вот этак.
Но было так:
- Как вы это делаете?
- Вот так.
- Спасибо.
Короче, диалога не получилось.
Увидел интересное добавление к agile версии модели водопада. Development и Test связаны циклом коррекции-изменения.
То есть, все прямоугольнички по новой религией стрелочками в одну сторону, а между тестом и разработкой есть обратная связь.
Ещё десять лет - и додумаются до того, что разработка даёт сообщения об ошибках в дизайн. Дизайн - в сбор требований. А requirements engineering не только получает приказ начинать, но и что-то отправляет обратно прямоугольничку инициации. Например, сообщение "Нафиг-нафиг. Мы с такими пожеланиями только денег сожжём немеряно, но ничего путного в результате не выдадем."
Узнал новое волшебное слово: "Shift Left Model".
Если раньше в начале проекта работали аналитики, потом подключались дизайнеры, потом медленно набирали силу разработка и тестирование, то сейчас предлагается это всё загнать влево. Чтоб не только аналитики радовались, но и тестировщики с разработчиками резвились на сырых требованиях.
Если кто-то скажет, что отсутствие мозгов решили компенсировать грубой силой, тот будет абсолютно прав.
Но, увы, это реалии современной индустрии. Фиг сейчас найдёшь requirements engineer, который скажет "Вы на самом деле хотите раскрасить интерфейс в эти цвета?" или "Вы уверены, что не стоит рассматривать случаи, когда пользователь вводит данные с ошибкой?"
Помнится, двадцать лет назад специалист по IT-договорам, услышав ранних предвестников agile, с удивлением замечал, что для этого клиент должен платить не за сделаннную работу, а за то, что работа делается. Точнее, что-то делается, а что - не понятно.
Время показало, что заказчики под такое найдутся. Толпами. И большими деньгами.
Если им такое нравится, пусть платят.
Несколько интересных фактов:
- Тестирование бывает разрушающее, которое ищет ошибки, и верифицирующее, которое говорит, что ошибок нет. В фармафирмах любят второе. По этой причине практически всё делается вручную и производит гору бумаги.
- Licenses create queues and bottlenecks.
С одной стороны, хорошо, когда все-все-все могут тестировать всё что угодно. С другой - дешевле, если разработчики будут не гонять массивные тесты после каждого маленького изменения, а думать перед тем, как что-то в коде менять.
Мечты... Мечты...
- Чтобы изменить набор тестовых данных в банке надо обратиться к ответственным. И они поменяют. Время это займёт от двух недель до двух лет. (Может человек и преукрасил немного, но цифра правдоподобная.)
- Performance tools report mean values but the interesting part is the distribution of test results.
- Manual test scripts trap: It is simple to create a script that records user's actions but this script is costly to change.
Естественно, в этих замечательных тулах нельзя добавить параметры и случайные отклонения. А, когда один и тот же тест размножается под много клиентов, мы меряем не поведение системы под реальной нагрузкой, а совершенно искусственный случай.
Тысяча клиентов, одновременно выбравших один и тот же пункт в меню, - это не наплыв посетителей, а DOS атака.
- Интересно, что второй докладчик пропагандировал диаметрально противоположный подход: Generate test automation scripts from requirements.
What is wrong with this approach? The word "generate". Miracle is moved to the responsibilities of a business analyst.
Ещё я попытался объяснить людям, что тесты не могут быть слишком хорошими.
Development creates value. Testing eats resources. If tests produce too many errors this errors will be ignored. If this is impossible, developers will blame test scenarios as wrong or irrelevant and as result such "productive" tests will be switched off.
If developers try to be honest with tests that stop them, managers will change this unproductive attitude.
И в заключение лучшее за вчера.
Each advocate of each popular belief in IT is excellent in one aspect: the critique of problems of other beliefs.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
(frozen) Не манадки
Date: 2018-08-31 04:24 pm (UTC)Понимаете, нет?
Физические объекты.
С массой, плотностью, текстурой...
Я у вас, кажись спрашивал даже, об этом. КАК манадки сочетаются с физикой... ответа не получил.
Так что -- нет,
только вашем воображаемом
математическом платоновском мире
где пасутся сферические в ваккуме единороги... %)
(frozen) Re: Не манадки
Date: 2018-08-31 04:29 pm (UTC)(frozen) Было бы честнее
Date: 2018-08-31 04:46 pm (UTC)Но подобная честность, при выходе ЗА рамки своей профессиональной компетенции,
не характерна для так называемых профессионалов.
"Профессионал подобен флюсу..." (с)
(frozen) Re: Не манадки
Date: 2018-08-31 05:00 pm (UTC)(frozen) Что поделать
Date: 2018-08-31 05:34 pm (UTC)не выветрились еще у меня школьно-юношеские идеалы. %))
а впрочем интересно,
людей годами, десятилетиями,
учат всяким умным штукам, там:
что говорить надо логично и обосновано,
опиратся на факты, вести себя корректно.
чтобы потом сама жизнь им же
показывала что это все фигня,
что главное не АйКью,
а эмоциональный интеллект -- то есть нахрапистость и упертость, и волевое навязывание своей т.з., своих убеждений, желаний. %)
(frozen) Re: Что поделать
Date: 2018-08-31 06:02 pm (UTC)показывала что это все фигня,
что главное не АйКью,
а эмоциональный интеллект
Ну посмотрел бы я как на эмоциональном интеллекте строят систему управления тормозной колодкой автомобиля...
(frozen) Опыта...
Date: 2018-08-31 06:55 pm (UTC)(frozen) Re: Опыта...
Date: 2018-08-31 07:10 pm (UTC)(frozen) Значит...
Date: 2018-09-03 05:49 am (UTC)мне -- нет.
(frozen) Re: Что поделать
Date: 2018-09-02 04:51 pm (UTC)Люди с хорошо развитым эмоциональным интеллектом обычно в тюрьме сидят. А те, у кого особенно хорошо с навязыванием своих нехитрых желаний, чаще всего попадают под ножи коллег по опасному бизнесу.
(frozen) Re: Не манадки
Date: 2018-09-02 04:46 pm (UTC)Ну монады - это тоже некоторые стандартные модели некоторых объектов. Просто основы теории множеств вам в детсаду рассказали (на яблоках и грушах), а основы теории категорий - нет.
(frozen) Re: Не манадки
Date: 2018-09-03 05:48 am (UTC)ровно так же мы не думаем "все состоит из монадок".
Собственно, сам оппонент -- Ганди это демонстрирует,
в своем посте где ему говоришь "продемонстрируй логику" -- ответ "а зачем?".
Прошу понять правильно -- я совсем НЕ против монадок,
всячески уважаю математику, но...
в рамках вот этой диспозиции -- никак не могу согласится с этим вот "все состоит из монадок".
Все состоит из атомов -- да, это глупо было бы отрицать,
но одновременно НИКТО этим не заморачивается
Все состоит из монадок -- нет, напихивание монадками Вселенной,
это целиком искуственная, идеологическая конструкция...
так же как напихиване истории "классовой борьбой".
И неправильно (в смысле греха против истины),
и очевидна политическая адженда -- возвышение своей любимой дисциплины,
и себя лично через причастность к ней... попытка сегрегации,
на основе "ах, так вы не знаете монадок?!"
(frozen) Re: Не манадки
Date: 2018-09-08 07:40 pm (UTC)Ну это модель, достаточно общая, чтобы её можно было прицепить к очень многим вещам, как теорию множеств - практически ко всему. Вопрос в целесообразности - сделает ли она жизнь проще или нет.
Где-то делает, где-то нет. С моей точки зрения оно заслуживает изучения, но популярных и хороших книжек с задачами я не видел. Ну, там Милевский что-то пытался делать, но это всё равно слишком сложно получается, и без задач. А задачи ведь в математике - самое главное.
(frozen) Re: Не манадки
Date: 2018-09-09 06:29 am (UTC)Во-о-от.
Большинство областей и так довольно сложны, и отяжелены необходимостью "надо понимать всю глубину наших глубин",
чтобы отягощать их еще и необходимостью думать о том "а ккую монадку я тут использую?".
Собственно, это и по самим ФПшникам видно -- как они погрязли в основном в выяснениях "у кого монадки толще" -- более правильные,
вместо того чтобы демонстрировать как с их помощью можно делать что-то полезное.
Я лично не вижу, где в нашем мире нейро-сеток и программирования ГПУ они могут преуспеть.
Разве что, вот ПЛИСы на подходе -- синтез их напрямую из кода.
Но там скорее всего будет ТАКАЯ специфика и своя математика,
что большинство успешно выучившим "в категории эндофункторов" -- ничего светить не будет.
Все равно надо будет переучиватся. %)
\\С моей точки зрения оно заслуживает изучения, но популярных и хороших книжек с задачами я не видел. Ну, там Милевский что-то пытался делать, но это всё равно слишком сложно получается, и без задач. А задачи ведь в математике - самое главное.
Я вроде где-то обмолвился, что не заслуживает...
просто, банально и наивно наверное, пробовал спрашивать -- а выгода где?
Банальная Экономика ведь -- если выгода МЕНЬШЕ, чем затраты на изучение и использование, то...
зачем платить больше? (тм)
Полуается, только затем чтобы у програмера росло ЧСВ,
потому что он уже не тупой кодер... а математик. %)
\\А задачи ведь в математике - самое главное.
А это... видимо Ганди надо спрашивать... что он считае главным.
Я все же, по невежеству своему, думаю доказательства важнее.