Для решения таких проблем Spring предлагает профили.
Например вот тут https://docs.spring.io/spring-boot/docs/current/reference/html/howto-database-initialization.html внизу описан процесс интеграции с liquabase. С помощью профилей можно переопределить параметры liquabase и грузить разные ченджлоги для разных режимов работы.
Вот пример(application.yml):
spring:
profiles:
active: development
---
spring:
profiles: production
liquibase:
changeLog: "classpath:/db/changelog/db.changelog-production.yaml"
---
spring:
profiles: development
liquibase:
changeLog: "classpath:/db/changelog/db.changelog-development.yaml"
По поводу локализации, компиляции js/css. В режиме разработки мы просто отключаем кеширование файлов с локализацией(обычно messages/messages.properties) и соответственно каждый раз данные берутся заново. Так же мы не компилируем js/css в режиме разработки. А вот уже в проде мы все компилируем сжимаем оптимизируем. Но эта задача лежит на Maven и Teamcity.
Кстати почему JSP? Есть же Thymeleaf(мы его не любим) и куча других шаблонизаторов, мы используем простеньки Pebble Engine. Но он расширяем и покрывает весь спектр наших задач.
Поясню немного подробнее, конфигурация которую вы предлагаете развернуть как мне кажется немного устарела. Есть Spring Boot с плагином для Maven и Gradle которые позволяет развернуть приложение за 15 минут. И там уже все будет и БД и локализация и JPA и Security.
Очевидно что количество программистов которых раздражает xml > количества программистов которых раздражает Java API. Поэтому без видимых преимуществ xml лучше сменить на Java, благо Spring на текущий момент предлагает красивое Java API. Тут и CDI аннотации и Spring аннотации и красивые билдеры.
Посыл ваш ясен, НО свобода/безопасность это любимая пластинка наверно любого государства(кроме условно нормальных типо Исландии). Тут как бы нет никакого сюрприза для любого вменяемого человека.
А у вас проводятся ревью в компании? Просто я работал года 2-3 в компании с ревью, и насмотрелся всякого. Этот случай не самый худший из моей практики. У нас даже велась статистика чей патч заворачивали больше всего раз(по моему лидер был ~30 раз). У меня рекорд 17 раз.
При этом интересно что люди стоящие выше(тех дир и его окружение) заворачивали гораздо реже патчи, чем теже самые лиды. Вот лиды отрывались по полной.
Поэтому я читая эту заметку понимаю что хотел сказать автор и в принципе с ним согласен.
Гораздо чаще возникают ситуации когда ревьюер исходя из собственного опыта придирается к человеку с другим опытом.
Ну например Java код, метод возвращает пустой список если параметры метода ни прошли какие то проверки(например). Программист напишет:
return Collections.emptyList(); (Collections.emptyList() возвращает неизменяемый список)
а ревьюер исправит:
return new ArrayList<>();
При этом согласно коду программиста список не предполагается изменять в будущем, но ревьюер исходя из своего личного опыта делает вывод что обязательно найдется кто-нибудь кто попытается засунуть в этот список что-нибудь. Казалось бы оба по своему правы, но в целом это скорее всего придирка.
Не поверю что сервера с ботнетом каким нибудь не увезуут на пару дней для изучения. Да тупой поиск в гугл дал выдачу по германии как минимум, автор нормально состаивл коммент, вы просто придираетесь.
Как понять знает только IDE? Для Java разработчика IDE это 30% сэкономленного времени. Вы наверно думаете что разработка это только знание конкретного языка программирования? Это не так, разработка это много много всего еще и знание IDE это не самый последний скил которым должен владеть разраб.
Но на собесах нас упорно заставляют писать код на бумажке, который даже нельзя оттестить, а ведь еще батюшка Фаулер писал что почти нереально сразу написать правильно работающий код.
В 2015 пора уже использовать какие то новые практики собеседований, перестать воспринимать соискателя как мышку над которой можно ставить эксперименты.
Кажой задаче свое средство
— нужно написать решение какой то неизвестной задачи? дайте нормально средство, например IDE где я смогу проверить разные варианты и сделать как надо
— вам нужен ход моих мыслей? мне не нужна бумага, я вам и так скажу
— вы ждете что я и так знаю решение(в случае с алгоритмами)? тогда варианта 2, я его знаю и я его не знаю, поэтому бумажка мне почти никогда не поможет
Я знаю что на собеседование часто есть лист бумаги для собеседуемого, но я не считаю правильным давать писать код на нем. Порисовать квадратики в процессе размышления — да, выделить основные мысли чтобы не мешались в голове — да, нарисовать граф или массив — да, так мы часто делаем на работе. Для остального могли бы и ноутбук с IDE дать.
Из статьи не понял зачем мне нужно писать код на бумажке в 2015. А вообще большинство советов: как вам вести себя на собеседовании у НАС в компании. Имхо.
Да нормальный скала язык, менеджеры свою ошибку прикрывают проблемами языка, вот и все.
Я могу тут на пол статьи расписать проблемы Spring которые ежедневно мешают мне работать. Постоянно приходится либо что то дописывать либо брать стороннюю либу которая поможет работать.
Scala давно принят на вооружение многими компаниями, вон Twitter, Тинькоф все довольны. Конкретно в этом случае именно проблема управления. Кто принимал решения взять Scala, кто являлся техническим лидером в этом вопросе? Если джуниор Петя без грамма знаний и власти, то сори другого исхода быть не могло.
Я в своей компании не использую Scala хотя и пишу дома только на ней. Не делаю этого потому что понимаю что после меня никто там ничего не исправит и не доделает, а значит пишем на Java и не испытываем проблем.
То что вы описали написано у них в доках.
task wrapper(type: Wrapper) {
gradleVersion = '2.4'
}
эта штука позволяет сгенерить враппер, дальше они советуют руками менять версию если надо(в gradle-wrapper.properties файле) либо генерить враппер заново
плюсую за sbt, страшненький но зато мощный какой, казалось бы с первого взгляда такой не понятный, но gradle для меня почему то более непонятен на практике
Например вот тут https://docs.spring.io/spring-boot/docs/current/reference/html/howto-database-initialization.html внизу описан процесс интеграции с liquabase. С помощью профилей можно переопределить параметры liquabase и грузить разные ченджлоги для разных режимов работы.
Вот пример(application.yml):
По поводу локализации, компиляции js/css. В режиме разработки мы просто отключаем кеширование файлов с локализацией(обычно messages/messages.properties) и соответственно каждый раз данные берутся заново. Так же мы не компилируем js/css в режиме разработки. А вот уже в проде мы все компилируем сжимаем оптимизируем. Но эта задача лежит на Maven и Teamcity.
Кстати почему JSP? Есть же Thymeleaf(мы его не любим) и куча других шаблонизаторов, мы используем простеньки Pebble Engine. Но он расширяем и покрывает весь спектр наших задач.
Очевидно что количество программистов которых раздражает xml > количества программистов которых раздражает Java API. Поэтому без видимых преимуществ xml лучше сменить на Java, благо Spring на текущий момент предлагает красивое Java API. Тут и CDI аннотации и Spring аннотации и красивые билдеры.
При этом интересно что люди стоящие выше(тех дир и его окружение) заворачивали гораздо реже патчи, чем теже самые лиды. Вот лиды отрывались по полной.
Поэтому я читая эту заметку понимаю что хотел сказать автор и в принципе с ним согласен.
Ну например Java код, метод возвращает пустой список если параметры метода ни прошли какие то проверки(например). Программист напишет:
return Collections.emptyList(); (Collections.emptyList() возвращает неизменяемый список)
а ревьюер исправит:
return new ArrayList<>();
При этом согласно коду программиста список не предполагается изменять в будущем, но ревьюер исходя из своего личного опыта делает вывод что обязательно найдется кто-нибудь кто попытается засунуть в этот список что-нибудь. Казалось бы оба по своему правы, но в целом это скорее всего придирка.
Но на собесах нас упорно заставляют писать код на бумажке, который даже нельзя оттестить, а ведь еще батюшка Фаулер писал что почти нереально сразу написать правильно работающий код.
В 2015 пора уже использовать какие то новые практики собеседований, перестать воспринимать соискателя как мышку над которой можно ставить эксперименты.
— нужно написать решение какой то неизвестной задачи? дайте нормально средство, например IDE где я смогу проверить разные варианты и сделать как надо
— вам нужен ход моих мыслей? мне не нужна бумага, я вам и так скажу
— вы ждете что я и так знаю решение(в случае с алгоритмами)? тогда варианта 2, я его знаю и я его не знаю, поэтому бумажка мне почти никогда не поможет
Я знаю что на собеседование часто есть лист бумаги для собеседуемого, но я не считаю правильным давать писать код на нем. Порисовать квадратики в процессе размышления — да, выделить основные мысли чтобы не мешались в голове — да, нарисовать граф или массив — да, так мы часто делаем на работе. Для остального могли бы и ноутбук с IDE дать.
Я могу тут на пол статьи расписать проблемы Spring которые ежедневно мешают мне работать. Постоянно приходится либо что то дописывать либо брать стороннюю либу которая поможет работать.
Scala давно принят на вооружение многими компаниями, вон Twitter, Тинькоф все довольны. Конкретно в этом случае именно проблема управления. Кто принимал решения взять Scala, кто являлся техническим лидером в этом вопросе? Если джуниор Петя без грамма знаний и власти, то сори другого исхода быть не могло.
Я в своей компании не использую Scala хотя и пишу дома только на ней. Не делаю этого потому что понимаю что после меня никто там ничего не исправит и не доделает, а значит пишем на Java и не испытываем проблем.
task wrapper(type: Wrapper) {
gradleVersion = '2.4'
}
эта штука позволяет сгенерить враппер, дальше они советуют руками менять версию если надо(в gradle-wrapper.properties файле) либо генерить враппер заново