А вас не достают требованиями СИБ о том что нужно "сделать так что бы анализатор не показывал уязвимостей". Причем доводы о том, что эта "уязвимость" в принципе не применима к данному прикладному ПО, просто не принимаются во внимание. "не должен показывать" и все тут.
Так тут проблема не в Спринге, а в вашей СИБ - и вы ее "решили" отказавшись от Спринга, но это ж не решение, правильно? Завтра возможности отказаться от чего-то что бы накормить СИБ не будет, и вы обратно окажетесь в такой же ситуации, только вместо Спринга будет что-то еще.
Психанул и заменил на grizzly. Благо сервис не на Spring Boot и меняется легко.
Заметьте, заменили вы не потому, что Спринг плох или Гризли хорош, а потому что нашелся кто-то, кто заставил вас психануть.
А на Spring Boot 2.x.x строчек 20 сообщений об уязвимостях на самой последней версии.
Это говорит только о том, что уязвимости ищут и находят - и вам о них говорят. А, ка я и сказал, то, что в Гризли ничего не найдено вовсе не говорит, что в нем нет дыр размером с верблюда - может их просто не ищут и не сообщают о них, поди знай...
Да лучше бы сразу было написано без оберток Spring Boot. Заменил некоторые либы и все.
Думаю очевидно, что проблема тут ни разу не в Спринге, а в том, что кто-то не хочет включать мозг, и спускает указивки на "устранение уязвимостей" не приходя в сознание.
Вы же понимаете, что практически все эти правила без всякого труда замечательно разворачиваются в обратную сторону, и превращаются в глупости?
Не опаздывайте на совещания
А зачем вы ставите так много совещаний?
На планерке все должны быть готовы к отчетам по своим направлениям
Ну, вот тут возразить в общем-то сложно, это да.
Приходите с решениями, а не проблемами
Понял, если у меня нет решения, то я должен молчать о проблеме!
Критикуешь - предлагай
То есть если я не хочу становиться ответственным за устранение всех косяков которые я вижу, то мне лучше помолчать? Хорошо, понял, принял!
У любого проекта должен быть один ответственный
Прям у любого? Даже у запуска космического корабля в космос? Вот прям один единственный ответственный? А этот самородок точно сможет один потянуть ответственность за все?
Все задачи должны иметь точный дедлайн
Даже те, которые имеют дело с НИОКР? Даже те, которые завязаны на смежников? Вам же подойдет совершенно точный дедлайн с запасом в год-другой, правда? Он будет совершенно точен, при этом мы учтем возможные риски!
Прекратите вы уже рожать "серебряные пули", их не существует, и то, что будет уместно и умнО в одном случае окажется неизбежной глупостью в другом.
Вы издеваетесь? QA отвечает за качество продукта, а требования к нему, судя по тому что вы тут говорите, такие, что он не то, что за продукт, он за себя ответить не сможет.
Давай так - имея только код ориентироваться будет на круг всяко легче, чем имея код И bpmn, который связан с кодом совершенно не очевидным образом. К тому же у нас микросервисный мир, в котором есть такая штука, как api, которое является единой точкой входа в сервис, имея эту точку разматывать клубок становится сильно легче, а для камунды ничего подобного нет - все в не явном виде на текстовых метках, по которым нет толком ни поиска, ни навигации.
Всего одну? Вы понимаете, что по сути каждый элемент bpmn будет ссылаться на "какой-то код" - каждый кубик, каждая стрелка будет смотреть в java-код. Не имея быстрого и надежного средства навигации туда-сюда поддержка и развитие превратится в адЪ, где львиная доля времени будет уходить на поиски откуда ноги растут.
А теперь задание со звездочкой - быстро и на кончиках пальцев понять в каком месте bpmn используется произвольный кусок кода? И в обратную сторону - какой конкретно код лежит под каждым кубиком диаграммы? Пока двусторонний переход из bpmn в код и обратно нельзя будет сделать по привычному ctrl+клик использование камунды в продакшене будет мучением для развития и поддержки.
Ну, и как волшебным образом "смежная команда" может оценить сотрудников соседей, если они не погружены и не вовлечены в то, кто что делает у этих самых соседей? Отдельные команды - отдельное планирование.
А откуда возьмутся эти "большие числа"? Команда редко больше 12-15 человек, а кто тебя еще знает достаточно хорошо, чтобы определить твою компетентность? В соседних отделах как ни крути, а знать тебя будут довольно однобоко, и что бы такой "360" сделать адекватным и информативным в него придется ввалить столько усилий, что мама не горюй.
А вас не достают требованиями СИБ о том что нужно "сделать так что бы анализатор не показывал уязвимостей". Причем доводы о том, что эта "уязвимость" в принципе не применима к данному прикладному ПО, просто не принимаются во внимание. "не должен показывать" и все тут.Так тут проблема не в Спринге, а в вашей СИБ - и вы ее "решили" отказавшись от Спринга, но это ж не решение, правильно? Завтра возможности отказаться от чего-то что бы накормить СИБ не будет, и вы обратно окажетесь в такой же ситуации, только вместо Спринга будет что-то еще.
Психанул и заменил на grizzly. Благо сервис не на Spring Boot и меняется легко.Заметьте, заменили вы не потому, что Спринг плох или Гризли хорош, а потому что нашелся кто-то, кто заставил вас психануть.
А на Spring Boot 2.x.x строчек 20 сообщений об уязвимостях на самой последней версии.Это говорит только о том, что уязвимости ищут и находят - и вам о них говорят. А, ка я и сказал, то, что в Гризли ничего не найдено вовсе не говорит, что в нем нет дыр размером с верблюда - может их просто не ищут и не сообщают о них, поди знай...
Да лучше бы сразу было написано без оберток Spring Boot. Заменил некоторые либы и все.Думаю очевидно, что проблема тут ни разу не в Спринге, а в том, что кто-то не хочет включать мозг, и спускает указивки на "устранение уязвимостей" не приходя в сознание.
То, что их не находят не значит, что их нет - возможно просто никто особо не ищет.
Вы же понимаете, что практически все эти правила без всякого труда замечательно разворачиваются в обратную сторону, и превращаются в глупости?
Не опаздывайте на совещания
А зачем вы ставите так много совещаний?
На планерке все должны быть готовы к отчетам по своим направлениям
Ну, вот тут возразить в общем-то сложно, это да.
Приходите с решениями, а не проблемами
Понял, если у меня нет решения, то я должен молчать о проблеме!
Критикуешь - предлагай
То есть если я не хочу становиться ответственным за устранение всех косяков которые я вижу, то мне лучше помолчать? Хорошо, понял, принял!
У любого проекта должен быть один ответственный
Прям у любого? Даже у запуска космического корабля в космос? Вот прям один единственный ответственный? А этот самородок точно сможет один потянуть ответственность за все?
Все задачи должны иметь точный дедлайн
Даже те, которые имеют дело с НИОКР? Даже те, которые завязаны на смежников? Вам же подойдет совершенно точный дедлайн с запасом в год-другой, правда? Он будет совершенно точен, при этом мы учтем возможные риски!
Прекратите вы уже рожать "серебряные пули", их не существует, и то, что будет уместно и умнО в одном случае окажется неизбежной глупостью в другом.
А тогда уже не надо.
Вы правда считаете, что именно эти цели изначально стояли? Хех...
Это же очевидно - возникнут сильно иные языки программирования!
Вы издеваетесь? QA отвечает за качество продукта, а требования к нему, судя по тому что вы тут говорите, такие, что он не то, что за продукт, он за себя ответить не сможет.
но игра до сих пор не вышла из фазы раннего доступа.А ведь когда-то долгостроем называли Duke Nukem Forever...
Я уже более трёх лет в геймдевеЯ учусь в магистратуреи тут же
написал десятки тысяч диалоговКонечно, мы верим. Жаль, что не сотни!
Как всегда - спасибо!
Спасибо за дайджесты! Даже не знаю, я б так не смог, когда под каждым буквально ноль комментариев.
И ни слова про зарплату, про ее индексацию и ее повышение. Вы там точно ожидания мониторили, а не фантазии?
Новый правленый bpmn точно так же нужно выводить в прод, его точно так же нужно тестировать. На круг сам по себе его наличие ничего не ускоряет.
Давай так - имея только код ориентироваться будет на круг всяко легче, чем имея код И bpmn, который связан с кодом совершенно не очевидным образом. К тому же у нас микросервисный мир, в котором есть такая штука, как api, которое является единой точкой входа в сервис, имея эту точку разматывать клубок становится сильно легче, а для камунды ничего подобного нет - все в не явном виде на текстовых метках, по которым нет толком ни поиска, ни навигации.
вызывает функцию описанную в JAVAВсего одну? Вы понимаете, что по сути каждый элемент bpmn будет ссылаться на "какой-то код" - каждый кубик, каждая стрелка будет смотреть в java-код. Не имея быстрого и надежного средства навигации туда-сюда поддержка и развитие превратится в адЪ, где львиная доля времени будет уходить на поиски откуда ноги растут.А теперь задание со звездочкой - быстро и на кончиках пальцев понять в каком месте bpmn используется произвольный кусок кода? И в обратную сторону - какой конкретно код лежит под каждым кубиком диаграммы? Пока двусторонний переход из bpmn в код и обратно нельзя будет сделать по привычному ctrl+клик использование камунды в продакшене будет мучением для развития и поддержки.
А там еще и перец может быть, который в БД вообще не храниться...
Ну, и как волшебным образом "смежная команда" может оценить сотрудников соседей, если они не погружены и не вовлечены в то, кто что делает у этих самых соседей? Отдельные команды - отдельное планирование.
А откуда возьмутся эти "большие числа"? Команда редко больше 12-15 человек, а кто тебя еще знает достаточно хорошо, чтобы определить твою компетентность? В соседних отделах как ни крути, а знать тебя будут довольно однобоко, и что бы такой "360" сделать адекватным и информативным в него придется ввалить столько усилий, что мама не горюй.
Всех много, а всего мало - и всего на всех не хватит.