А в чем проблема указать в application-test.yaml jdbc driver к testcontainers и соответствующий url? Тогда вся инициализация делается автоматически и один раз.
Общая проблема с медленным запуском все же остаётся. В моем предыдущем проекте я использовал JPA, H2 и Guice. Запуск тестов осуществлялся меньше секунды.
Ну, эта проблема выходит далеко за рамки юнит тестирования и не решается оными. Тем более вашей непосредственной ответственности по части тестирования здесь нет -- это создатели библиотеки должны были оттестировать поведение. Вы же заложились на корректность реализации и соответствие заявленной спецификации, что вобщем-то нормально. Тестировать подключенный сторонний код в своем проекте -- это ненормально. Так можно опуститься и до тестов своей операционнрй системы.
Я тоже критически отношусь к тестам, особенно к из бездумному использованию. В большинстве случаев мы попадаем в абсурдную ситуацию, когда тестовая кодовая база на порядок больше самого бизнес кода, а сложность создания прекондиций и моков превосходит логику тестируемого кода.
В случае граничных условий типа корня из отрицательного числа, поможет контрактное программирование. Добавляете аннотацию к методу она же является спецификацией параметра. Тест в этом случае становится рудиментарным.
Сомневаюсь. Если это апп на электроне, со своим встроенным браузером, то да. Здесь же все пускается в том же хроме, только без навигации. Установил хабр как приложение, запустил, и не вижу отдельного процесса.
Вроде как уже давно можно было сделать шорткат в системе на сайт, чтобы он открывался в отдельном окне без URL и табов. Не совсем понятно чем установка приложения отличается от шортката.
Не обязательно. Когда фронт модульный и пилится одновременно несколькими командами, возникает проблема с зависимостями, когда разные команды используют либы разных версий, которые по нескольку раз включаются в финальный бандл. Поэтому некоторые переходят на монорепозиторий, где менеджить зависимости легче.
Больше. Все инкрустированные сервисы типа социальных кнопок, рекламы, аналитики тащат с собой свои SDK-бандлы, каждый из которых запросто может превосходить сам код страницы. Благо грузятся они все асинхронно. Автор должен был это учесть.
Каким объективным методом аффтар меряет "Skill" на приведенном графике? К тому же "Сеньорити" подвержено инфляции. Сеньоры сейчас не то же самое, что 10 день назад. Поэтому набирая джунов, вы дай бог возьмете кого-то с недельными курсами.
Не кажется ли вам, что роль различных методик и практик менеджмента сильно преувеличена? Если у вас в команде только ленивые задницы, которые ждут, когда им скажут какие кнопки им давить, то хоть расперпендикуляртесь, вы не заставите их делать что-либо удобоваримое.
В общем случае техдолг -- задачи, которые не приносят непосредственный value бизнесу, но от решения которых зависит скорость выкатывания новых фич. Способом борьбы может быть также мелкий рефакторинг непосредственно при решении основной бизнес задачи. В некоторых случаях техдолг превосходит по объему полную реимплементацию проекта. Однако основной проблемой здесь будет объяснить бизнесу необходимость данного действия. Обычно такое происходит только после полной смены команды.
gRPC - это всё-таки клиент-серверный протокол, нежели полностью распределённый, как например RMI или CORBA. Основное их отличие в том, что endpoint также является объектом, который можно сериализовать и передавать по сети, таким образом осуществляя двустороннюю связь. Одним из кейсов является remote invoke with callback, где помимо структур передается локальный объект, которому удаленный сервис передаст результат. Все же современные протоколы работают лишь в одну сторону.
Дэвид Теннант -- бесспорно лучший доктор! Но эпизоды с Меттью Смитом более захватывающие, к тому же с очаровательной Карен Гиллан. С Питером Капальди через все серии стала протаскиваться "повесточка", которой авторы стали все больше уделять внимание в ущерб сценарию. И с Джоди Фостер авторы сделали "повесточку" главной целью сериала, полностью забив на сценарий.
Я понимаю, если это бизнес -- там как бы изначально цель продать побольше воздуха. Но в IT люди как-то должны критически относиться к навязываемому буллшиту! Я уверен, все эти диаграммы и термины были придуманы людьми, которые не написали ни строчки кода, начиная с университета, и по большей части по причине безделия. Скорей всего человек просто, наконец, разобрался в том, что заимплементили девелоперы, и решил об этом поведать миру, придумывая заумные термины вроде "лямбля" и "каппа" архитектуры, которые можно натянуть на что угодно как сову на глобус.
С другой стороны, польза от "архитектуры" все же есть: все эти диаграммы и модные слова помогают перед клиентом оправдывать ценник проекта. Ибо как в фильме: "гренка не может стоить 8 долларов, а 'крутон' -- может".
Лев Николаевич Толстой был известным полиглотом. Он владел 13 языками. В возрасте 80 лет он стал учить китайский. Но язык ему не дался. "То ли китайский язык слишком сложный, то ли я для него слишком стар" -- разочарованно промолвил Лев Толстой. (где хаскель?)
Может я ошибаюсь ввиду своей ограниченности, но у меня стойкое впечатление, что сначала появляется задача, потом ее решение, и затем реализация. И уже потом умные люди придумывают ей название, классифицируют и пишут о ней в своих блогах, статьях, рассказывают на конференциях, засовывают в учебники, продают ее бизнесу как новую "серебряную пулю", а те в свою очередь добавляют ее в список требований для очередной вакансии...
Это в любом случае означает, что команда считает эти детали значимыми, но не имеет информации, позволяющей оценить степень соответствия каждого из вариантов желаемому продактом.
Как я уже сказал выше, если команда, ждет, что ей объяснят на какие кнопки давить, то это незрелая команда, не способная принимать решения. Значимые детали -- это те, которые определяют архитектуру решения, и которые потом будет сложно поменять. Их и нужно обговаривать в первую очередь с продактом. А куда сдвинуть кнопку или какую надпись поставить на компонент -- это незначительные детали, которые лучше обсуждать уже имея на руках что-то рабочее, и которые прокатывают как есть в 90% случаев.
Технические же детали вообще не нужно обсуждать с продактом, потому как вероятны два варианта:
либо он отложит проблему в долгий ящих и скажет "подумаю потом на досуге"
либо, что еще хуже, примет некомпетентное решение за тебя, которое сулит многими проблемами в дальнейшем
При всем уважении, многие руководители убеждены, что причиной провала проекта является именно неверно выбранная или неправильно используемая методология. И что перейдя на X, их проект попрет как по вазелину. Хотя реальная ситуация может быть как в старом анекдоте: "У моей бабушки был бордель. И вот когда доходы падали, она меняла девочек, а не двигала кровати."
Если почти на все, то у вас явно есть проблемы с делегированием, которые, скорее всего, вытекают из проблем с постановкой задач своей команде.
Там миллион причин: от низкой мотивации в команде до того, что сам менеджер просто ленивая задница.
Задача должна быть четко и конкретно сформулирована.
Насколько конкретно? Если PM должен объяснять девелоперу какие клавиши он должен нажать, то нафиг такой девелопер -- его уже сейчас дешевле заменит ИИ. И при всем желании вы не сможете сформулировать четко и конкретно любую задачу, учтя все стопицот нюансов и кейсов, либо вы уже будете не в силах сфокусироваться ни на чем другом. Вместо этого PM должен донести идею, что он хочет видеть, и дать команде возможность для самостоятельного маневра и выбора решений. И если команда вас постоянно "пингует" спрашивая деталей по любому поводу, это говорит о ее общей незрелости и необходимости внедрения тимлида.
Также стоит отметить, что SMART – это не волшебная таблетка
Очень важная ремарка: мы впарили вам очередной X, но никаких гарантий не даем и никакой ответственности не несем.
Помню дрючил ASM, чтобы инжектнуть в классы код, проверяющий наличие лицензии для нашего продукта. Причем, вместо вызова сторонней функции инлайнился сам код прямо в методы, рандомно выбранные при сборке. Кроме того, пришлось придумать некое подобие полиморфности при генерации, чтобы код не был вычищен простым поиском по шаблону. Интересно, но на мой взгляд слишком трудозатратно: cамым тяжелым была генерация лямбд.
Поэтому лучшим на мой взгляд способом для генерации кода в рантайме будет компиляция из исходного кода с использованием javax.tools.JavaCompiler в связке с каким-нибудь JavaPoet или шаблонизатором. Чаще нужно просто модифицировать уже существующий код, тогда ByteBuddy тут нет равных.
Испаноязычные страны: как правило 2 имени и 2 фамилии, причем фамилии не семейные и у всех членов разные (дети наследуют от отца и матери).
Причем, для остальных человек может представиться любым из своих имён, которое ему больше по душе.
Так что хорошую универсальную модель, к сожалению, определить невозможно.
А в чем проблема указать в application-test.yaml jdbc driver к testcontainers и соответствующий url? Тогда вся инициализация делается автоматически и один раз.
Общая проблема с медленным запуском все же остаётся. В моем предыдущем проекте я использовал JPA, H2 и Guice. Запуск тестов осуществлялся меньше секунды.
Ну, эта проблема выходит далеко за рамки юнит тестирования и не решается оными. Тем более вашей непосредственной ответственности по части тестирования здесь нет -- это создатели библиотеки должны были оттестировать поведение. Вы же заложились на корректность реализации и соответствие заявленной спецификации, что вобщем-то нормально. Тестировать подключенный сторонний код в своем проекте -- это ненормально. Так можно опуститься и до тестов своей операционнрй системы.
Я тоже критически отношусь к тестам, особенно к из бездумному использованию. В большинстве случаев мы попадаем в абсурдную ситуацию, когда тестовая кодовая база на порядок больше самого бизнес кода, а сложность создания прекондиций и моков превосходит логику тестируемого кода.
В случае граничных условий типа корня из отрицательного числа, поможет контрактное программирование. Добавляете аннотацию к методу она же является спецификацией параметра. Тест в этом случае становится рудиментарным.
Сомневаюсь. Если это апп на электроне, со своим встроенным браузером, то да. Здесь же все пускается в том же хроме, только без навигации. Установил хабр как приложение, запустил, и не вижу отдельного процесса.
Вроде как уже давно можно было сделать шорткат в системе на сайт, чтобы он открывался в отдельном окне без URL и табов. Не совсем понятно чем установка приложения отличается от шортката.
Не обязательно. Когда фронт модульный и пилится одновременно несколькими командами, возникает проблема с зависимостями, когда разные команды используют либы разных версий, которые по нескольку раз включаются в финальный бандл. Поэтому некоторые переходят на монорепозиторий, где менеджить зависимости легче.
Больше. Все инкрустированные сервисы типа социальных кнопок, рекламы, аналитики тащат с собой свои SDK-бандлы, каждый из которых запросто может превосходить сам код страницы. Благо грузятся они все асинхронно. Автор должен был это учесть.
Каким объективным методом аффтар меряет "Skill" на приведенном графике? К тому же "Сеньорити" подвержено инфляции. Сеньоры сейчас не то же самое, что 10 день назад. Поэтому набирая джунов, вы дай бог возьмете кого-то с недельными курсами.
Не кажется ли вам, что роль различных методик и практик менеджмента сильно преувеличена? Если у вас в команде только ленивые задницы, которые ждут, когда им скажут какие кнопки им давить, то хоть расперпендикуляртесь, вы не заставите их делать что-либо удобоваримое.
В общем случае техдолг -- задачи, которые не приносят непосредственный value бизнесу, но от решения которых зависит скорость выкатывания новых фич. Способом борьбы может быть также мелкий рефакторинг непосредственно при решении основной бизнес задачи. В некоторых случаях техдолг превосходит по объему полную реимплементацию проекта. Однако основной проблемой здесь будет объяснить бизнесу необходимость данного действия. Обычно такое происходит только после полной смены команды.
gRPC - это всё-таки клиент-серверный протокол, нежели полностью распределённый, как например RMI или CORBA. Основное их отличие в том, что endpoint также является объектом, который можно сериализовать и передавать по сети, таким образом осуществляя двустороннюю связь. Одним из кейсов является remote invoke with callback, где помимо структур передается локальный объект, которому удаленный сервис передаст результат. Все же современные протоколы работают лишь в одну сторону.
Я так понимаю, это перефразированный закон Гудхарта: https://ru.wikipedia.org/wiki/Закон_Гудхарта
Дэвид Теннант -- бесспорно лучший доктор! Но эпизоды с Меттью Смитом более захватывающие, к тому же с очаровательной Карен Гиллан. С Питером Капальди через все серии стала протаскиваться "повесточка", которой авторы стали все больше уделять внимание в ущерб сценарию. И с Джоди Фостер авторы сделали "повесточку" главной целью сериала, полностью забив на сценарий.
Я понимаю, если это бизнес -- там как бы изначально цель продать побольше воздуха. Но в IT люди как-то должны критически относиться к навязываемому буллшиту! Я уверен, все эти диаграммы и термины были придуманы людьми, которые не написали ни строчки кода, начиная с университета, и по большей части по причине безделия. Скорей всего человек просто, наконец, разобрался в том, что заимплементили девелоперы, и решил об этом поведать миру, придумывая заумные термины вроде "лямбля" и "каппа" архитектуры, которые можно натянуть на что угодно как сову на глобус.
С другой стороны, польза от "архитектуры" все же есть: все эти диаграммы и модные слова помогают перед клиентом оправдывать ценник проекта. Ибо как в фильме: "гренка не может стоить 8 долларов, а 'крутон' -- может".
Лев Николаевич Толстой был известным полиглотом. Он владел 13 языками. В возрасте 80 лет он стал учить китайский. Но язык ему не дался. "То ли китайский язык слишком сложный, то ли я для него слишком стар" -- разочарованно промолвил Лев Толстой. (где хаскель?)
P.S. Знать и владеть -- разные вещи.
Может я ошибаюсь ввиду своей ограниченности, но у меня стойкое впечатление, что сначала появляется задача, потом ее решение, и затем реализация. И уже потом умные люди придумывают ей название, классифицируют и пишут о ней в своих блогах, статьях, рассказывают на конференциях, засовывают в учебники, продают ее бизнесу как новую "серебряную пулю", а те в свою очередь добавляют ее в список требований для очередной вакансии...
Как я уже сказал выше, если команда, ждет, что ей объяснят на какие кнопки давить, то это незрелая команда, не способная принимать решения. Значимые детали -- это те, которые определяют архитектуру решения, и которые потом будет сложно поменять. Их и нужно обговаривать в первую очередь с продактом. А куда сдвинуть кнопку или какую надпись поставить на компонент -- это незначительные детали, которые лучше обсуждать уже имея на руках что-то рабочее, и которые прокатывают как есть в 90% случаев.
Технические же детали вообще не нужно обсуждать с продактом, потому как вероятны два варианта:
либо он отложит проблему в долгий ящих и скажет "подумаю потом на досуге"
либо, что еще хуже, примет некомпетентное решение за тебя, которое сулит многими проблемами в дальнейшем
При всем уважении, многие руководители убеждены, что причиной провала проекта является именно неверно выбранная или неправильно используемая методология. И что перейдя на X, их проект попрет как по вазелину. Хотя реальная ситуация может быть как в старом анекдоте: "У моей бабушки был бордель. И вот когда доходы падали, она меняла девочек, а не двигала кровати."
Там миллион причин: от низкой мотивации в команде до того, что сам менеджер просто ленивая задница.
Насколько конкретно? Если PM должен объяснять девелоперу какие клавиши он должен нажать, то нафиг такой девелопер -- его уже сейчас дешевле заменит ИИ. И при всем желании вы не сможете сформулировать четко и конкретно любую задачу, учтя все стопицот нюансов и кейсов, либо вы уже будете не в силах сфокусироваться ни на чем другом. Вместо этого PM должен донести идею, что он хочет видеть, и дать команде возможность для самостоятельного маневра и выбора решений. И если команда вас постоянно "пингует" спрашивая деталей по любому поводу, это говорит о ее общей незрелости и необходимости внедрения тимлида.
Очень важная ремарка: мы впарили вам очередной X, но никаких гарантий не даем и никакой ответственности не несем.
Помню дрючил ASM, чтобы инжектнуть в классы код, проверяющий наличие лицензии для нашего продукта. Причем, вместо вызова сторонней функции инлайнился сам код прямо в методы, рандомно выбранные при сборке. Кроме того, пришлось придумать некое подобие полиморфности при генерации, чтобы код не был вычищен простым поиском по шаблону. Интересно, но на мой взгляд слишком трудозатратно: cамым тяжелым была генерация лямбд.
Поэтому лучшим на мой взгляд способом для генерации кода в рантайме будет компиляция из исходного кода с использованием
javax.tools.JavaCompilerв связке с каким-нибудь JavaPoet или шаблонизатором. Чаще нужно просто модифицировать уже существующий код, тогда ByteBuddy тут нет равных.