Для меня ваш cucumber — это огромная пушка, цель которой предоставить аналитикам самим писать тесты.
Это дополнительный уровень инфраструктуры в вашем коде. Имхо, проще добавить groovy/scala в проект в тесты и наслаждаться: etorreborre.github.io/specs2
Это Вам кажется, что сложнее, потому что Вы не пробовали. Попробуете писать на обычных тест-фреймворках — у вас код будет лаконичнее и тестов, и самого тестируемого кода.
Сейчас очень распространены легковесные фреймворки типа Play (со своим шаблонизатором, который компилится в исходный код) и SPA решения…
JSP, конечно, — боль. Но почему сразу сервлеты? У вас же код нечитаемым месивом будет.
И, да, а почему JSP тормозной? Он же в сервлет компилируется.
Совет не писать собственный пул потоков в бд доставило…
Почему вы рассматриваете очереди, deadlocks в этом ключе?
Давно придумали functional, reactive programming, чтобы увести в 0 взаимодействие между потоками. А если взаимодействие есть, то его осуществлять на неблокируемых операциях like CAS.
Кто-нибудь использует J2EE для хай-лоад проектов? Какая нагрузка, стабильность?
Я честно о таком впервые слышу. Обычные отзывы о J2EE контейнерах перемешаны с кровью, потом и слезами даже на простых проектах. Не слышал об исключениях.
Это и правда кошмарно читается — надо всматриваться где начало и конец блоков/вызовов, слишком много вложенных отступов/блоков.
Пример чуть побольше — и разработчики с ума сойдут.
Посмотрите в сторону functional programming (например rxjs), чтобы избавиться от бойлерплейта 'if (!err && response.statusCode == 200) {'
Я бы предпочел видеть API в таком виде:
По мне очевидно, что первая строчка устанавливает какую-то переменную в недрах фреймворка, а вторая ну просто должна тоже что-то установить — в противном случае как фреймворк поймет, что надо проверять аутентификацию?
Регулярку писать — тоже плохой тон — оно нечитаемо в сложных случаях.
Try {
params("id").toInt
} match {
case Success(id) => DB.getUserById(id)
case Failure(ex) => pass()
}
Кошмарный бойлерплейт. В Play достаточно объявить аргумент метода — и он будет считаться параметром запроса. А проверки на валидность реализованы на уровне фреймворка.
Ребята, а приведите пожалуйста примеры модульных систем (где в каждом модуле свои сущности), где есть требование выгружать динамически модули/загружать новые? И откуда растут такие требования?
Это дополнительный уровень инфраструктуры в вашем коде. Имхо, проще добавить groovy/scala в проект в тесты и наслаждаться: etorreborre.github.io/specs2
Более того, cucumber тесты тупо дольше писать — надо писать именно те фразы, которые были определены для конкретного действия: github.com/cucumber/cucumber-jvm/blob/master/examples/java-calculator/src/test/java/cucumber/examples/java/calculator/RpnCalculatorStepdefs.java — ну почему я должен написать 'I add 1 and 2' и реализацию метода вместо простого calc.push(1).add(2) (предположение как выглядел бы вменяемый интерфейс к калькулятору)? Вместо одной строчки!
Это Вам кажется, что сложнее, потому что Вы не пробовали. Попробуете писать на обычных тест-фреймворках — у вас код будет лаконичнее и тестов, и самого тестируемого кода.
А почему, кстати, фреймворк не в open-source?
Сейчас очень распространены легковесные фреймворки типа Play (со своим шаблонизатором, который компилится в исходный код) и SPA решения…
JSP, конечно, — боль. Но почему сразу сервлеты? У вас же код нечитаемым месивом будет.
И, да, а почему JSP тормозной? Он же в сервлет компилируется.
Совет не писать собственный пул потоков в бд доставило…
Почему вы рассматриваете очереди, deadlocks в этом ключе?
Давно придумали functional, reactive programming, чтобы увести в 0 взаимодействие между потоками. А если взаимодействие есть, то его осуществлять на неблокируемых операциях like CAS.
Я честно о таком впервые слышу. Обычные отзывы о J2EE контейнерах перемешаны с кровью, потом и слезами даже на простых проектах. Не слышал об исключениях.
Akka и rx frameworks выглядят гораздо приятнее и надежнее.
Решил проблему использованием iReSign — вот он работает :)
Пример чуть побольше — и разработчики с ума сойдут.
Я бы предпочел видеть API в таком виде:
Как будете эти микросервисы масштабировать?
А бенчмарки-то где?
По мне очевидно, что первая строчка устанавливает какую-то переменную в недрах фреймворка, а вторая ну просто должна тоже что-то установить — в противном случае как фреймворк поймет, что надо проверять аутентификацию?
Регулярку писать — тоже плохой тон — оно нечитаемо в сложных случаях.
Кошмарный бойлерплейт. В Play достаточно объявить аргумент метода — и он будет считаться параметром запроса. А проверки на валидность реализованы на уровне фреймворка.
Mutability в контроллере тоже доставило. :(