Программирование[11]

по итогу можем сделать вывод, что джава еще большее говно, чем обычно

oh , sweet summer child 

что это значит? 

это у вас в конторе так подстегивают @Just.Doit? Почему просто не сказать тупой пидарас

какая же европа гнилая конечно 

ural1qqq написал 1 час назад:

oh , sweet summer child 

 

что это значит? 

это у вас в конторе так подстегивают @Just.Doit? Почему просто не сказать тупой пидарас

 

какая же европа гнилая конечно 

А ты переехал в Москву кста?

Нет

я не понял, вот есть команда тестеров на каком-то многосервисном проекте, они пишут автоматические тесты, которые запускаются после каждой важной доработки, ну или по какому-то там расписанию, взяли и запустились. Эти тесты проверяют что-то там на фронте, какие-то кнопочки тыкают, прогоняют сценарий, в котором задействовано пол системы.

Вопрос, как эти тесты могут находиться рядом с кодом? с какого хуя вообще? их написали тестеры, в своей репе, чтоб прогнать свои сценарии, какое отношение они имеют к какому-то сервису, или в целом к разработке? Т.е. вот разработчик покрыл свой тест юнит тестами, написал там какой-нибудь интеграционный тест на пару сценариев, и он лежит рядом с кодом, но это же не одно и то же, что те тесты, которые, скажем, пишет группа тестеров.

просто меня немного смутил момент, что как пример привели дотнет. Что он имеет общего с обычными проектами, в которых, зачастую, приходится лепить всякие нелогичные костыли на пол дороге только от того, что так захотел заказчик?

он описывает сравнение покрытия тестами

это обычные юнит тесты

их похуй кто пишет, это часть проекта и меняются всегда синхронно с проектом

репозитории делят по проектам, а не по командам

если у вас зависимые наглухо друг от друга части находятся в разных репозиториях, то у вас говно из жопы похуже неделимого монолита

ну, знач пропустил про покрытие тестами. Хотя с другой стороны, если это огромный старый монолит, написанный очень давно и который меняют редко, то зачем запускать сценарии слишком часто? т.е. в этом случае тоже может быть смысл держать тесты отдельно, так как они кушают много времени.

На самом деле, мне очень интересно узнать про тесты побольше, я чисто чужое мнение узнать захотел :0

я вам честно скажу что жалею что у меня не монолит архитектура

https://about.fb.com/news/2022/11/mark-zuckerberg-layoff-message-to-employees/

@sonac

ural1qqq написал 8 часов назад:

oh , sweet summer child 

 

что это значит? 

это у вас в конторе так подстегивают @Just.Doit? Почему просто не сказать тупой пидарас

 

какая же европа гнилая конечно 

забей перевод

там есть конкретное значение и именно его я и хочу донести

DANIS[Oo] написал 3 часа назад:

ну, знач пропустил про покрытие тестами.

нихуя ты не пропустил и все правильно говоришь.

я говорил И про юниты И про QA тесты

если говорить только про юниты - в JVM есть 2-3 билдтула (мавен, гредл, sbt), в них есть 3-5 плагинов которые запускают тесты. тесты находятся в разных модулях и каждый модуль надо настраивать чтобы он включался правильным образом и запускал тесты и все такое. одновременно может использоваться 2 плагина тк происходит миграция с условно устаревшего на классный. в итоге у тебя скажем 4 модуля * 2 плагина настроек, в которых можно ошибиться. А еще запуск в CI/CD билд тоже чутка отлчиается от запуска на локальной машине билда (формально разное окружение, которое ясен хрен отличается от линуксового сервера с дженкинсом и мака у разраба), а еще в ИДЕ есть плагины которые по своему запускают тесты (не через билд тул). в итоге у себя локально дев тыкает запуск тестов - у него все тестируется, все классно, но потом часть этих тестов во время билда в ci/cd не запускается (из-за ошибки в конфигурации, или различии в среде или различия в запуске в иде и билд туле) и в итоге со стороны дева все норм - он тесты написал, запустил, у него все протестировано, но затем во время билда они не запускаются и соответсвенно потом протухнут.

вот я и думаю как подобное можно отлавливать

это один кейс

второй кейс это QA тесты. в них глобально тоже не все тесты могут запуститься из-за ошибки в конфигурации или бага способа запуска. и вот думаю есть ли какие-то способы/практики сверять (удостоверятсья) что все задуманные тесты прогнаны. условно сверку количества проводить. или вот можно трейсить от запуска к запуску количество запущенных тестов и алертить резкий дроп

ural1qqq написал 56 минут назад:

я вам честно скажу что жалею что у меня не монолит архитектура

дак это база

монолит лучше распределенного говна

(кроме тех случаев когда распределенное гавно вынужденная мера и без него будет совсем треш)

(еще распределенное говно, называемое микросервисами позволяет фиксить проблемы команды в невозможности обеспечить модульность в одной кодовой базе)

Just.Doit написал 43 минуты назад:

забей перевод

там есть конкретное значение и именно его я и хочу донести

о, сладкий летний ребенок?

ввиду того, что у меня микросервисы, встает определенное ограничение в Camunda. 
Связано оно с тем, что по человечески не возможно уложить целиковый бизнес-процесс в единую схему, если процесс исполняется и обеспечивается функциональностью сразу многих микросервисов. Вызвать из сервиса оркестратора соседний код другого сервиса нельзя. 

Поэтому делаются всякие костыли, ввиде организации очереди, которая в себя принимает сообщения, формируемыми другими микросервисами при исполнении активностей, и читаемая сервисом с движком камунды

Это такая ебанина ебаная, поэтому я даже не знаю как донести и коллегам и заказчикам, что хуево получилось

По сути, движок в такой реализации это не оркестратор, а хуета какая то, которая лишнюю нагрузку не полезную абсолютно в себе несет. 

Теперь я буду пытаться донести коллегам и заказчику, что из залупы с Camunda надо вылазить, практически теряются все бенефиты от нее в такой реализации. 

Но это у нас подход такой получился на освоении, можно будет что то придумать более приближенное к стандарту

так то bpms это просто пушка и годнота 

вот и пошла переобув очька

ural1qqq написал 9 часов назад:

Camunda

Звучит не очень лицеприятно

Vova написал 20 часов назад:

https://about.fb.com/news/2022/11/mark-zuckerberg-layoff-message-to-employees/

 

@sonac

было мемно, мне цук лично сказал, что я заебись, поэтому могу не волноваться

ural1qqq написал 18 часов назад:

так то bpms это просто пушка и годнота 

хуйня ебаная

sonac написал 7 часов назад:

Vova написал 09.11.2022 в 22:55:

https://about.fb.com/news/2022/11/mark-zuckerberg-layoff-message-to-employees/

 

@sonac

было мемно, мне цук лично сказал, что я заебись, поэтому могу не волноваться

 фига ты круто получается, пили стори

а чо у вас там с виртуальной реальностью

уволят ли её?

besteady написал 9 часов назад:

sonac написал 16 часов назад:

Vova написал 09.11.2022 в 22:55:

https://about.fb.com/news/2022/11/mark-zuckerberg-layoff-message-to-employees/

 

@sonac

было мемно, мне цук лично сказал, что я заебись, поэтому могу не волноваться

 фига ты круто получается, пили стори

а чо у вас там с виртуальной реальностью

 

уволят ли её?

https://files.catbox.moe/s6sih8.mp4?

 

наверняка это согласовано с hr меты, чтоб ещё людей завлечь на "работу"

besteady said 9 hours ago:

sonac said 17 hours ago:

Vova said On 11/9/2022 at 10:55 PM:

https://about.fb.com/news/2022/11/mark-zuckerberg-layoff-message-to-employees/

 

@sonac

было мемно, мне цук лично сказал, что я заебись, поэтому могу не волноваться

 фига ты круто получается, пили стори

а чо у вас там с виртуальной реальностью

 

уволят ли её?

https://files.catbox.moe/s6sih8.mp4?

 

Надо было идти в product manager, просто берешь из одной кофейни в другую ходишь, из одного рестика в другой. Нихуя не делаешь) Интересно, кто ее ебет, раз такую бесполезную долбаебку взяли в мета