Очень интересный подарок. А вот дизайнеры, ГМы, ведущие квестов - это были какие-то сторонние люди? Интересно как таких находят и во сколько обошлись все затраты на подобный подарок.
Ну а почему нет? Автор выбирал парсер для себя. Почему он не должен руководствоваться привычками? Что плохого в минимизации затрат и усилий? И статья называется не "какой парсер лучше выбрать", чтобы претендовать на объективность.
Если я знаю Java и захочу сделать сайт, то в первую очередь буду искать движки на Java (кстати, я так делал и нашел SparkJava)
Такой подход позволяет первоначально сильно сузить широту выбора. Иначе чем больше выбор - тем дольше выбирать.
Странно предъявлять языку, в основе которого лежит платформонезависимость - неумение работать напрямую с платформой.
При чем специально вводите доп. ограничения. Потому что сами заранее знаете, что просто с задачей "сделать, чтоб работало так же" язык справится, а ваша цель доказать, что язык фуфло, для чего вводите искусственные ограничения.
При чтении статьи, местами возникает ощущение, что вы сами создали себе проблемы, которые потом героически решали (и теперь есть о чем поделиться на Хабре).
Нет, схема то интересная. Но если она у вас решила одну проблему, но добавила две - то возможно такая схема не совсем подходит?
Если вы можете выполнять последовательно первые шаги всех сценариев, а потом делать ожидание и выполнять проверки (на момент проверок созданы куча заказов и прочих данных для всех сценариев разом, т.е. друг другу они не мешают), то почему же вы не могли просто распараллелить все сценарии?
С самого начала посыл стоял в том, что вас не устраивали задержки по 10сек в каждом тесте. При этом пассивное ожидание я уже давно нигде не встречал. Есть же такие библиотеки как awaitility, позволяющие делать "активное" ожидание (проверка производится с заданной периодичностью в течение некоторого времени, после которого наступает timeout). И вместо того, чтобы всегда ждать 10 сек, вы будете проходить проверку как только, так сразу.
Автоматические проверки - хорошо. Но неявные проверки, которые для теста обязательны - не очень хорошо. Есть риск, что такую проверку из общего места уберут (допустим она будет неприменима для большого количества новых тестов), а туда, где она была нужна - не добавят. Потому что забудут, и потому что будет неочевидно, кому она была нужна. То есть на данный момент, добавляя новый тест, вам нужно держать в голове, где какие проверки делаются неявно.
Очень интересный подарок. А вот дизайнеры, ГМы, ведущие квестов - это были какие-то сторонние люди? Интересно как таких находят и во сколько обошлись все затраты на подобный подарок.
Распечатать по длинной стороне и добавить кольцевых стяжек (проще из ленты-троса, но можно распечатать на обычном 3д принтере как в посте)
Подразумевается, что с обновлением базы проблем никогда возникнуть не может?
Ну а почему нет? Автор выбирал парсер для себя. Почему он не должен руководствоваться привычками? Что плохого в минимизации затрат и усилий? И статья называется не "какой парсер лучше выбрать", чтобы претендовать на объективность.
Если я знаю Java и захочу сделать сайт, то в первую очередь буду искать движки на Java (кстати, я так делал и нашел SparkJava)
Такой подход позволяет первоначально сильно сузить широту выбора. Иначе чем больше выбор - тем дольше выбирать.
Как раз искал, как удобно окна расположить на 4к монике. Спасибо за наводку.
Странно предъявлять языку, в основе которого лежит платформонезависимость - неумение работать напрямую с платформой.
При чем специально вводите доп. ограничения. Потому что сами заранее знаете, что просто с задачей "сделать, чтоб работало так же" язык справится, а ваша цель доказать, что язык фуфло, для чего вводите искусственные ограничения.
Вроде как ESB уже устарел и в моде Service Mesh, который выглядит весьма похоже на ту картинку, от которой якобы спасла ESB
Вот кстати статья была давно по сравнению: https://habr.com/ru/company/psb/blog/432428/
Ну почему часто критика останавливается на "не стоит так делать". А как надо то? Какой выбор - лучший?
При чтении статьи, местами возникает ощущение, что вы сами создали себе проблемы, которые потом героически решали (и теперь есть о чем поделиться на Хабре).
Нет, схема то интересная. Но если она у вас решила одну проблему, но добавила две - то возможно такая схема не совсем подходит?
Если вы можете выполнять последовательно первые шаги всех сценариев, а потом делать ожидание и выполнять проверки (на момент проверок созданы куча заказов и прочих данных для всех сценариев разом, т.е. друг другу они не мешают), то почему же вы не могли просто распараллелить все сценарии?
С самого начала посыл стоял в том, что вас не устраивали задержки по 10сек в каждом тесте. При этом пассивное ожидание я уже давно нигде не встречал. Есть же такие библиотеки как awaitility, позволяющие делать "активное" ожидание (проверка производится с заданной периодичностью в течение некоторого времени, после которого наступает timeout). И вместо того, чтобы всегда ждать 10 сек, вы будете проходить проверку как только, так сразу.
Автоматические проверки - хорошо. Но неявные проверки, которые для теста обязательны - не очень хорошо. Есть риск, что такую проверку из общего места уберут (допустим она будет неприменима для большого количества новых тестов), а туда, где она была нужна - не добавят. Потому что забудут, и потому что будет неочевидно, кому она была нужна. То есть на данный момент, добавляя новый тест, вам нужно держать в голове, где какие проверки делаются неявно.