Это все наивно и хорошо только в теории. Вот описываем мы поля как nonnull, а потом в ход вступает десериализатор, который автоматически парсит пользовательский request и вот вам нулы в nonnull полях. То же самое с ORM и прочими технологиями. Требуется более глубокая поддержка nullability всем стеком.
XML -- это группа стандартов с продуманной семантикой, а JSON в оригинале просто был куском JS кода, внезапно ставший индустриальным стандартом ввиду нативной поддержки на фронте. На данный момент мы наблюдаем неудачные стихийные попытки восполнить отсутствующую семантику при помощи JSON path, JSON schema, поделку openapi, etc. Сравнивать эти два формата по принципу "кто круче" по меньшей мере некорректно.
Вчера поставил на своем Mac-е, все завелось. Хочу выразить огромное спасибо, ибо с mc испытывались постоянные проблемы с клавиатурой, редактором и прочими удобствами.
К подобным абстрактным идеям, о том сколько ангелов уместиться на кончике иглы, следует относиться не более чем как к развлекательной беллетристике.
С одной стороны, идеи кажутся простыми и разумными, с другой -- будучи примененными к реальным вещам, сразу провоцируют стопицот нюансов.
Пример: сильно загруженный девелопер был идентифицирован как узкое место. К нему добавили двух новых человек в надежде ускорить процесс разработки. И получили обратный результат, ибо узкое место в проекте -- это менеджер, не умеющий грамотно планировать и распределять задачи. Но кто когда признается в собственной некомпетентности? Всегда найдется причина вовне!
Везде, где только возможно, стараюсь не использовать фреймворки. И хотя стандартный RT джавы уже содержит немало всего, вместе с тем ч не против библиотек, которые содержат максимально необходимый функционал без прочего мусора. Например, для API неплохо подходит Javalin. Template engines вне фреймворка огромное количество (очень прикольный j2html). Для металлизации JSON есть Gson. Для доступа к базе JDBI.
Насчёт DI: в большинстве небольших проектов он вообще лишний, ибо связать 5 бинов можно и вручную. Просто на каждый бин в ApplicationContext заводим соответствующий порождающий метод и все. Там же где он нужен, я использую Guice.
Вообще да, сегодня вырос целый пласт специалистов, которые без фреймворка не осилят написание даже просто проекта, будь то бэк или фронт. У меня в команде чел две недели ковырялся с простой консольной утилитой, в итоге сказал, что ему нужен Spring, и только после этого смог закрыть таску.
TS неплохо лег для всех. Идея -- просто добавить типов к JS. Kotlin всё-таки сильно завязан на Java и JVM. Лучше было бы сразу взять направление на кросс-платформенность.
Если углубиться в тему и отбросить ваниль, то получится сказ о том как "просрать все полимеры". Неплохая и перспективная технология благодаря бездарной политике была сначала выпилена из винды, затем снесена с десктопа, смыта с клиентского веба, практически были просраны все мобильные платформы (только Гугл на свою задницу взял джаву и сильно пожалел потом). На сервере благодаря энтерпрайзному булшиту, веб разработка практически была утрачена в угоду легковесным решениями типа ruby on rails. Все эти JSR спецификации были дорогим и факультативным процессом, и реально никому особо и не впились. Фактически все это время один Spring тащил на себе всю джаву, новый клал по большей части на весь JEE. Около 7 лет застоя языка вызвали отток девелоперов из экосистемы и создание стопицот альтернативных мертворожденных JVM языков. Сегодня джава зацепилась за клауд, но и здесь не все гладко: внезапно оказалось, что она долго стартует, что сильно мешает технологиям с динамическими инстансами, а также не позволяет быть лекговесным языком для написания утилит и скриптов, как Пайтон или JS. ML и AI опять же...
Вообщем, история джавы -- это нифига не история успеха. Скорей вопреки стараниям менеджеров, над все ещё ее использует.
Как жертва бездумного и немотивированного использования различных методологий, я хочу заявить с целью самоутверждения и демонстрации согласия с автором коммента, что скрамы, эджайлы, фреймворки и прочее г. -- это все по то, как на основе посредственной ресурсной базы получить хоть какой-то рабочий результат.
Вот пусть и пишут, им никто не запрещал. Пусть хоть на голове ходят, если это внезапно станет модно. Лично я сначала делаю анализ, дизайн, набрасываю скелет решения, а уж потом итеративно реализовываю его параллельно с тестами.
Вообще TDD -- это методология о том, как написать калькулятор. В реальной среде там возникает куча проблем, о которых постоянно спорят на форумах, такие как: излишняя фрагментация, множественное покрытие, идеализированное окружение, сконцентрированность на внутреннем дизайне вместо бизнес кейсов, общая сложность написания, etc.
Могу ли я сказать, что следую TDD
С другой стороны, почему вас так задевает, являетесь ли вы труЪ адептом TDD или нет? Хотите поговорить об этом? :)
Помню себя 15-20 лет назад, когда всеми силами пытался разобраться как "правильно" писать и огранизовывать код, всасывая всевозможные паттерны и концепты. На определенном этапе я понял, что объективно никакого "правильного" варианта не существует, а большинство идей и концептов -- это не более чем расхайпленное персональное мнение одного или нескольких уважаемых людей, которые последний раз бизнес код писали N-дцать лет назад. А не говорю, что не стоит знать и понимать эти идеи, я лишь призываю скептически к ним относится, в особенности когда они преподносятся как лекарство от всех болезней и диких зверей.
получать возможность тестировать логику с инфраструктурными компонентами, используя такие инструменты, как Testcontainers.
Именно. Все мокированные юниты -- это мусор, который мешает дальнейшей разработке и рефакторингу, и основной смысл которых -- это поднять метрику покрытия. Сегодня мы в основном пишем микросервисы, в которых API -- это фактическая бизнес-спецификация, которая должна быть покрыта тестами и выдерживать регрессии. И фрагментировать тестовое покрытие на более мелкие внутренние компоненты в большинстве случаев не имеет смысла.
Есть более продуктивное средство, которое привнесет в личное пространство гармонию и расслабленность -- нанять в команду гиперответственного дурачка вроде меня и тупо сливать ему все свои задачи.
Вообще хоть я и не менеджер, а девлид, но практически все описанное мне знакомо. Плюс ещё таски нужно делать и коммитить. А лучший tool для меня -- это тестовый файл с беклогом, отсортированным по приоритету, и таски запланированные на каждый день.
Эджайл -- это по то как застроить дачный участок: тут картошку посажу, там горох, а в углу сортир поставлю. Задачи атомарные, из порядок выполнения не особо важен, есть возможность переделать любую из них в следующих итерациях.
Когда же вы стоите небоскреб по эджайл, на определенном этапе все начинает рушится: из одноэтажного коттеджа путем надстроек и изменений не создать empire state building.
А в чем проблема указать в application-test.yaml jdbc driver к testcontainers и соответствующий url? Тогда вся инициализация делается автоматически и один раз.
Общая проблема с медленным запуском все же остаётся. В моем предыдущем проекте я использовал JPA, H2 и Guice. Запуск тестов осуществлялся меньше секунды.
Ну, эта проблема выходит далеко за рамки юнит тестирования и не решается оными. Тем более вашей непосредственной ответственности по части тестирования здесь нет -- это создатели библиотеки должны были оттестировать поведение. Вы же заложились на корректность реализации и соответствие заявленной спецификации, что вобщем-то нормально. Тестировать подключенный сторонний код в своем проекте -- это ненормально. Так можно опуститься и до тестов своей операционнрй системы.
Я тоже критически отношусь к тестам, особенно к из бездумному использованию. В большинстве случаев мы попадаем в абсурдную ситуацию, когда тестовая кодовая база на порядок больше самого бизнес кода, а сложность создания прекондиций и моков превосходит логику тестируемого кода.
В случае граничных условий типа корня из отрицательного числа, поможет контрактное программирование. Добавляете аннотацию к методу она же является спецификацией параметра. Тест в этом случае становится рудиментарным.
Сомневаюсь. Если это апп на электроне, со своим встроенным браузером, то да. Здесь же все пускается в том же хроме, только без навигации. Установил хабр как приложение, запустил, и не вижу отдельного процесса.
Вроде как уже давно можно было сделать шорткат в системе на сайт, чтобы он открывался в отдельном окне без URL и табов. Не совсем понятно чем установка приложения отличается от шортката.
Не обязательно. Когда фронт модульный и пилится одновременно несколькими командами, возникает проблема с зависимостями, когда разные команды используют либы разных версий, которые по нескольку раз включаются в финальный бандл. Поэтому некоторые переходят на монорепозиторий, где менеджить зависимости легче.
Это все наивно и хорошо только в теории. Вот описываем мы поля как nonnull, а потом в ход вступает десериализатор, который автоматически парсит пользовательский request и вот вам нулы в nonnull полях. То же самое с ORM и прочими технологиями. Требуется более глубокая поддержка nullability всем стеком.
XML -- это группа стандартов с продуманной семантикой, а JSON в оригинале просто был куском JS кода, внезапно ставший индустриальным стандартом ввиду нативной поддержки на фронте. На данный момент мы наблюдаем неудачные стихийные попытки восполнить отсутствующую семантику при помощи JSON path, JSON schema, поделку openapi, etc. Сравнивать эти два формата по принципу "кто круче" по меньшей мере некорректно.
Вчера поставил на своем Mac-е, все завелось. Хочу выразить огромное спасибо, ибо с mc испытывались постоянные проблемы с клавиатурой, редактором и прочими удобствами.
К подобным абстрактным идеям, о том сколько ангелов уместиться на кончике иглы, следует относиться не более чем как к развлекательной беллетристике.
С одной стороны, идеи кажутся простыми и разумными, с другой -- будучи примененными к реальным вещам, сразу провоцируют стопицот нюансов.
Пример: сильно загруженный девелопер был идентифицирован как узкое место. К нему добавили двух новых человек в надежде ускорить процесс разработки. И получили обратный результат, ибо узкое место в проекте -- это менеджер, не умеющий грамотно планировать и распределять задачи. Но кто когда признается в собственной некомпетентности? Всегда найдется причина вовне!
Везде, где только возможно, стараюсь не использовать фреймворки. И хотя стандартный RT джавы уже содержит немало всего, вместе с тем ч не против библиотек, которые содержат максимально необходимый функционал без прочего мусора. Например, для API неплохо подходит Javalin. Template engines вне фреймворка огромное количество (очень прикольный j2html). Для металлизации JSON есть Gson. Для доступа к базе JDBI.
Насчёт DI: в большинстве небольших проектов он вообще лишний, ибо связать 5 бинов можно и вручную. Просто на каждый бин в ApplicationContext заводим соответствующий порождающий метод и все. Там же где он нужен, я использую Guice.
Вообще да, сегодня вырос целый пласт специалистов, которые без фреймворка не осилят написание даже просто проекта, будь то бэк или фронт. У меня в команде чел две недели ковырялся с простой консольной утилитой, в итоге сказал, что ему нужен Spring, и только после этого смог закрыть таску.
TS неплохо лег для всех. Идея -- просто добавить типов к JS. Kotlin всё-таки сильно завязан на Java и JVM. Лучше было бы сразу взять направление на кросс-платформенность.
Если углубиться в тему и отбросить ваниль, то получится сказ о том как "просрать все полимеры". Неплохая и перспективная технология благодаря бездарной политике была сначала выпилена из винды, затем снесена с десктопа, смыта с клиентского веба, практически были просраны все мобильные платформы (только Гугл на свою задницу взял джаву и сильно пожалел потом). На сервере благодаря энтерпрайзному булшиту, веб разработка практически была утрачена в угоду легковесным решениями типа ruby on rails. Все эти JSR спецификации были дорогим и факультативным процессом, и реально никому особо и не впились. Фактически все это время один Spring тащил на себе всю джаву, новый клал по большей части на весь JEE. Около 7 лет застоя языка вызвали отток девелоперов из экосистемы и создание стопицот альтернативных мертворожденных JVM языков. Сегодня джава зацепилась за клауд, но и здесь не все гладко: внезапно оказалось, что она долго стартует, что сильно мешает технологиям с динамическими инстансами, а также не позволяет быть лекговесным языком для написания утилит и скриптов, как Пайтон или JS. ML и AI опять же...
Вообщем, история джавы -- это нифига не история успеха. Скорей вопреки стараниям менеджеров, над все ещё ее использует.
Как жертва бездумного и немотивированного использования различных методологий, я хочу заявить с целью самоутверждения и демонстрации согласия с автором коммента, что скрамы, эджайлы, фреймворки и прочее г. -- это все по то, как на основе посредственной ресурсной базы получить хоть какой-то рабочий результат.
Вот пусть и пишут, им никто не запрещал. Пусть хоть на голове ходят, если это внезапно станет модно. Лично я сначала делаю анализ, дизайн, набрасываю скелет решения, а уж потом итеративно реализовываю его параллельно с тестами.
Вообще TDD -- это методология о том, как написать калькулятор. В реальной среде там возникает куча проблем, о которых постоянно спорят на форумах, такие как: излишняя фрагментация, множественное покрытие, идеализированное окружение, сконцентрированность на внутреннем дизайне вместо бизнес кейсов, общая сложность написания, etc.
С другой стороны, почему вас так задевает, являетесь ли вы труЪ адептом TDD или нет? Хотите поговорить об этом? :)
Помню себя 15-20 лет назад, когда всеми силами пытался разобраться как "правильно" писать и огранизовывать код, всасывая всевозможные паттерны и концепты. На определенном этапе я понял, что объективно никакого "правильного" варианта не существует, а большинство идей и концептов -- это не более чем расхайпленное персональное мнение одного или нескольких уважаемых людей, которые последний раз бизнес код писали N-дцать лет назад. А не говорю, что не стоит знать и понимать эти идеи, я лишь призываю скептически к ним относится, в особенности когда они преподносятся как лекарство от всех болезней и диких зверей.
Именно. Все мокированные юниты -- это мусор, который мешает дальнейшей разработке и рефакторингу, и основной смысл которых -- это поднять метрику покрытия. Сегодня мы в основном пишем микросервисы, в которых API -- это фактическая бизнес-спецификация, которая должна быть покрыта тестами и выдерживать регрессии. И фрагментировать тестовое покрытие на более мелкие внутренние компоненты в большинстве случаев не имеет смысла.
Сегодня как раз внезапно PR вьюха отключилась. Потратил час, прежде чем нашел тред в саппорте. Обновился, перелогинился и все завелось.
Пожелание на будущее: в подобных ситуациях хочется, чтобы IDE предупреждала о необходимости обновляться например попапом, а не просто отваливаться.
P.S. imho зря на Intellij гонят -- отличные IDE и развиваются в правильном направлении.
Не понимаю зачем склейка с or, когда postgres поддерживает туплы:
Есть более продуктивное средство, которое привнесет в личное пространство гармонию и расслабленность -- нанять в команду гиперответственного дурачка вроде меня и тупо сливать ему все свои задачи.
Вообще хоть я и не менеджер, а девлид, но практически все описанное мне знакомо. Плюс ещё таски нужно делать и коммитить. А лучший tool для меня -- это тестовый файл с беклогом, отсортированным по приоритету, и таски запланированные на каждый день.
Эджайл -- это по то как застроить дачный участок: тут картошку посажу, там горох, а в углу сортир поставлю. Задачи атомарные, из порядок выполнения не особо важен, есть возможность переделать любую из них в следующих итерациях.
Когда же вы стоите небоскреб по эджайл, на определенном этапе все начинает рушится: из одноэтажного коттеджа путем надстроек и изменений не создать empire state building.
Испаноязычные страны: как правило 2 имени и 2 фамилии, причем фамилии не семейные и у всех членов разные (дети наследуют от отца и матери).
Причем, для остальных человек может представиться любым из своих имён, которое ему больше по душе.
Так что хорошую универсальную модель, к сожалению, определить невозможно.
А в чем проблема указать в application-test.yaml jdbc driver к testcontainers и соответствующий url? Тогда вся инициализация делается автоматически и один раз.
Общая проблема с медленным запуском все же остаётся. В моем предыдущем проекте я использовал JPA, H2 и Guice. Запуск тестов осуществлялся меньше секунды.
Ну, эта проблема выходит далеко за рамки юнит тестирования и не решается оными. Тем более вашей непосредственной ответственности по части тестирования здесь нет -- это создатели библиотеки должны были оттестировать поведение. Вы же заложились на корректность реализации и соответствие заявленной спецификации, что вобщем-то нормально. Тестировать подключенный сторонний код в своем проекте -- это ненормально. Так можно опуститься и до тестов своей операционнрй системы.
Я тоже критически отношусь к тестам, особенно к из бездумному использованию. В большинстве случаев мы попадаем в абсурдную ситуацию, когда тестовая кодовая база на порядок больше самого бизнес кода, а сложность создания прекондиций и моков превосходит логику тестируемого кода.
В случае граничных условий типа корня из отрицательного числа, поможет контрактное программирование. Добавляете аннотацию к методу она же является спецификацией параметра. Тест в этом случае становится рудиментарным.
Сомневаюсь. Если это апп на электроне, со своим встроенным браузером, то да. Здесь же все пускается в том же хроме, только без навигации. Установил хабр как приложение, запустил, и не вижу отдельного процесса.
Вроде как уже давно можно было сделать шорткат в системе на сайт, чтобы он открывался в отдельном окне без URL и табов. Не совсем понятно чем установка приложения отличается от шортката.
Не обязательно. Когда фронт модульный и пилится одновременно несколькими командами, возникает проблема с зависимостями, когда разные команды используют либы разных версий, которые по нескольку раз включаются в финальный бандл. Поэтому некоторые переходят на монорепозиторий, где менеджить зависимости легче.