Один мой бывший начальник, не только не любил тестировать, но и вообще запускать продукт после сборки. Регулярно после него приходилось чинить, то что не собиралось. Зря ему про это говорил! Его повысили и он от меня избавился. А вы тестируйте за собой! (Все это шутка, но сами понимаете на реальных событиях)
Да тоже интересно было бы, но вопрос в том - поддерживает ли их jetty или tomcat, иными словами сервер приложений, который выполняет spring приложение. В том или ином случае пропускная способность зависит от этого. Второй момент количество потоков в Linux определяется количеством файлов в системе которые можно открыть. В docker описан ulimits порядка 1 миллиона открытых потоков. Замечу не виртуальных - а тех которые поддерживает ОС. То есть имея цифры 1500 оптимально и 3000 максимально возникает вопрос почему при способности системы запустить в 300 раз больше своих нитей мы на создании виртуальных потов имеем выигрыш. В том что потоки в состоянии спячки не обслуживаются системой? Еще раз говорю, я не пытаюсь что-то оспорить. Я просто один раз столкнулся с такой проблемой наращивание производительности, которую решали за счет переписывание всего на Go и теперь пытаюсь разобраться - а стоит ли в данном случае переписывать на Go или на Ktor ? Или все же как-то заставить работать старое нормально?
GC настраиваится, но при данной методике его не настроить. А методика эффективного настраивание GC следующая - замер пика потребление ОЗУ под нагрузкой и порог срабатывания на 10-15% от этого пика (порог можно увеличить для некоторых систем на 20-30%) - результат GC срабатывает часто и мелко. Получается мелкозубная пила - нет длительных потерь производительности + плюс при обработке GC приходится меньший данных обрабатывать (порой меньше в несколько раз).
То есть на всеобщее обозрение были вынесены не достоверные факты. После чего, кто-то на их сошлется. Второй момент, как я понял часть которая касается Nexus была взята с внешних источников. Тут у меня сразу возникает куча вопросов о идентичности настроек и версии исходного продукта, которое к стати тоже почему-то поддерживает Jdk17. То есть этот GC можно было запустить на исходном пакете и померить. В третьих - да просто можно было взять обычный POD с фиксированными настройками в K8S запустить сначала в одинаковых условиях Nexus, потом то что было скомпилировано с открытых исходников Nexus и померить все. И сказать у нас компиляция лучше! Или что еще? То есть воинственно радует в этой статье, что специалист по качеству в Сбер спокойно говорит "Так сойдет" - вот это школа! Что только великий Сбер с людьми не делает! (извиняюсь - но моя карма уже не излечима)
Это очень философский вопрос. Банк платит налоги, которые идут в том числе на финансирование полетов на Марс. Или позволяет аккумулировать деньги для реализаций различных проектов - в том числе строительство жилья. Это сейчас какие-то не разумные проценты, но когда-то много народу в ипотеку (кредит) купили себе жилье, замечу себе! Хотя, жить с родителями или снимать квартиру, для того что бы писать программы запуска кораблей на Марс - то же хорошая дело. Но проблема не в этом. Проблема в том - что бизнес заставляет писать быстро и не качественно.
А какая разница между задач по запуску ракет на Марс и выдачи кредитов? Более того ракету запустили и можно про ту программу забыть, а кредиты по той программе будут выдаваться лет 10, если не более. Вот и приходишь - а там сидит сварливая женщина, у которой, 20 лет назад программисты на гору по 2 задачи в день делали. Что там в этих задачах была, ей просто не ведомо, так как не ее это код писать. А сейчас не те программисты пошли, она их как рентгеном видит, все хотят на теплое место и деньги получать. Но она на страже - всех саботажников определит. В общем в лучшим случае народ пробел ставит и commit делает, с переводом в статус "решено", а могут с помощью ИИ кучу кода, который не чего не делает поставить или вообще не обратить внимание, что соседний функционал сломается заплатку на скорую поставить, и так вместо полдня, целый день на дебаг потратил. Какое приведение в порядок. Есть мысли после испытательного срока, но его проходят единицы.
Честно говоря как можно сравнивать 2 продукта в различных конфигурациях? Надеюсь остальное не так же сравнивали, там просто методика получения данных не указана.
Это статья типичный "лубок". В своем опыте я видел много legacy, но такого legacy который выдают на гора в ГринАтоме больше не где не встречу. Одна из основных систем, разработка длится где-то 2010-2014 года. За это время прошло порядка 7 тендеров на доработки. Причем каждый тендер оформлялся в уникальном неймспейсе (ДА Карл - наследование в более 10 слоев - причем базовый пакет может быть перенаследован в различных пакетах. Пришла контора Рога и Копыта из Гондураса и сделали package gn.roga.kopyta отнаследовала и переопределила те классы которые нужно и таких контор минимум 7). JSF фрейворк писали заново по тендору. Документации на его не оставили. И при этом не реальные сроки выполнения задач на старте. Я сначала смотрел у удивлялся - а почему народ вешает заплатки и не смотрит влияет она на что-то или нет, или вообще пишет какой-то код который не куда не ведет? А просто код есть - задача выполнена, скорость высокая - от начальства не прилетит. И это норма. Это похоже такой стиль работы. А что проект основной во всех 500 предприятиях РосАтома и пользуется активно. Не работает - так большая группа поддержки все исправляет в ручную.
А было время когда мечтали или космонавтом или полярником. В 90-х тоже карьеру начинать не очень было. Комп стоил чуть дороже квартиры и за надлежавшее использование могли просто "спросить".
Пытался указать про то что они взяли клоуна. Но клоун похоже таким хорошим и родным оказался. Я просто взвесил все проблемы с нервотрепкой который этот клоун мне доставит и ушел. Там еще к тому же кусок функционала надо было рефакторить большой. Мне просто после криков от клоуна что он прав не хотелось. Он к стати психологически просто хорошо подготовлен был. В общем учите менторы таких вот крутых специалистов.
1) Нет высшего образования 2) Git flow вообще не знает. Начал какой-то бред нести про универсальную версию продукта - ну и там major.minor.patch - вообще не понимал что и как (ментор поди не рассказал) 3) Unit тесты вообще писать не мог. 4) Какие-то не понятные архитектурные решения (но это просто мое личное мнение - пусть дальше сам разбирается) - В общем много моментов. Ну с испытательного срока. Типа он давал такие ценные указания - которая команда не делал - он в этом не виноват. Ну и по этим причинам он прошел испытательный срок. После этого я просто не захотел дальше тянуть проект и ушел. Пусть Сбер сам с ним нянчится.
В СберТех меня вышиб такой вот накрутчик. Просто работать с "специалистом" который просто что умеет, как много и красиво говорить, но не чего при этом не делал плохо, а вот работать под его начальством вообще не возможно. При этом учитывая что начальник управления оказался инженер-механик ставший DevOps, для которого те речи показались внушали доверия. В общем в БигТех давно формируется фейковый мир фейковых специалистов.
Сигнатура сигнала плывет - то есть: При отражение фаза меняется и ловишь изменение фазы. Но если не знаешь исходную фазу - то как определить на сколько фазу отразилась. Если ребята эту проблему решили каким-то образом - то хорошо. Еще какие секреты рассказать?
Если они смогли решить проблему плавающего сигнала у излучателя - то им уважение. Мое личное мнение такое - если в 2014 в Микране продолжили хотя бы в фоновом режиме работу над антидронным комплексом - то в 2022 году можно было микрановский конвейер в 3 смены в легкую пустить, а не собирать антидронные комплексы на коленках.
В Подмосковье и Нижнем Новгороде можно обычные цифровые радары поставить с классическими излучателями - которые выдают сигнал стабильного вида и у которого меньше будет сложности с БПФ. Там преобразование адово будет - источник сигнала на плавающем расстоянии, плюс сигнал с неоднородной структурой. Разрешение радара будет низкое с высокими шумами. Учитывая что дрон имеет площадь с слабым отражением - то идея использование стороннего излучателя становится не понятной. Удешевление в одном, за счет понижения качества и удорожание другого. Я не отрицаю идею - но вот назначение?
Речь шла не о РЛС - над ней Микран работал и работает, хотя и активная. А антидроным комплексом подавления. Тогда из-за перспективности положили под сукно, а в 22-ом году начали на коленках в срочном порядке делать. Про пассивную РЛС вернее всего такая же история. С другой стороны не понятно надежность такой системы. Сторонний не контролируемый источник - это меньшая точность, при малых объектах - это критично. Плюс в зоне боевых действий глушат все. А в не боевых - можно своим источником пользоваться.
Помнится в "Микран" в 2014-2016 году были антидронные разработки, Но их под сукно положили - денег не было на них. Да и кто знал, что дроны так интенсивно начнут использовать.
Один мой бывший начальник, не только не любил тестировать, но и вообще запускать продукт после сборки. Регулярно после него приходилось чинить, то что не собиралось. Зря ему про это говорил! Его повысили и он от меня избавился. А вы тестируйте за собой! (Все это шутка, но сами понимаете на реальных событиях)
Да тоже интересно было бы, но вопрос в том - поддерживает ли их jetty или tomcat, иными словами сервер приложений, который выполняет spring приложение. В том или ином случае пропускная способность зависит от этого. Второй момент количество потоков в Linux определяется количеством файлов в системе которые можно открыть. В docker описан ulimits порядка 1 миллиона открытых потоков. Замечу не виртуальных - а тех которые поддерживает ОС. То есть имея цифры 1500 оптимально и 3000 максимально возникает вопрос почему при способности системы запустить в 300 раз больше своих нитей мы на создании виртуальных потов имеем выигрыш. В том что потоки в состоянии спячки не обслуживаются системой? Еще раз говорю, я не пытаюсь что-то оспорить. Я просто один раз столкнулся с такой проблемой наращивание производительности, которую решали за счет переписывание всего на Go и теперь пытаюсь разобраться - а стоит ли в данном случае переписывать на Go или на Ktor ? Или все же как-то заставить работать старое нормально?
GC настраиваится, но при данной методике его не настроить. А методика эффективного настраивание GC следующая - замер пика потребление ОЗУ под нагрузкой и порог срабатывания на 10-15% от этого пика (порог можно увеличить для некоторых систем на 20-30%) - результат GC срабатывает часто и мелко. Получается мелкозубная пила - нет длительных потерь производительности + плюс при обработке GC приходится меньший данных обрабатывать (порой меньше в несколько раз).
То есть на всеобщее обозрение были вынесены не достоверные факты. После чего, кто-то на их сошлется. Второй момент, как я понял часть которая касается Nexus была взята с внешних источников. Тут у меня сразу возникает куча вопросов о идентичности настроек и версии исходного продукта, которое к стати тоже почему-то поддерживает Jdk17. То есть этот GC можно было запустить на исходном пакете и померить. В третьих - да просто можно было взять обычный POD с фиксированными настройками в K8S запустить сначала в одинаковых условиях Nexus, потом то что было скомпилировано с открытых исходников Nexus и померить все. И сказать у нас компиляция лучше! Или что еще? То есть воинственно радует в этой статье, что специалист по качеству в Сбер спокойно говорит "Так сойдет" - вот это школа! Что только великий Сбер с людьми не делает! (извиняюсь - но моя карма уже не излечима)
Это очень философский вопрос. Банк платит налоги, которые идут в том числе на финансирование полетов на Марс. Или позволяет аккумулировать деньги для реализаций различных проектов - в том числе строительство жилья. Это сейчас какие-то не разумные проценты, но когда-то много народу в ипотеку (кредит) купили себе жилье, замечу себе! Хотя, жить с родителями или снимать квартиру, для того что бы писать программы запуска кораблей на Марс - то же хорошая дело. Но проблема не в этом. Проблема в том - что бизнес заставляет писать быстро и не качественно.
А какая разница между задач по запуску ракет на Марс и выдачи кредитов? Более того ракету запустили и можно про ту программу забыть, а кредиты по той программе будут выдаваться лет 10, если не более. Вот и приходишь - а там сидит сварливая женщина, у которой, 20 лет назад программисты на гору по 2 задачи в день делали. Что там в этих задачах была, ей просто не ведомо, так как не ее это код писать. А сейчас не те программисты пошли, она их как рентгеном видит, все хотят на теплое место и деньги получать. Но она на страже - всех саботажников определит. В общем в лучшим случае народ пробел ставит и commit делает, с переводом в статус "решено", а могут с помощью ИИ кучу кода, который не чего не делает поставить или вообще не обратить внимание, что соседний функционал сломается заплатку на скорую поставить, и так вместо полдня, целый день на дебаг потратил. Какое приведение в порядок. Есть мысли после испытательного срока, но его проходят единицы.
Честно говоря как можно сравнивать 2 продукта в различных конфигурациях? Надеюсь остальное не так же сравнивали, там просто методика получения данных не указана.
Это статья типичный "лубок". В своем опыте я видел много legacy, но такого legacy который выдают на гора в ГринАтоме больше не где не встречу. Одна из основных систем, разработка длится где-то 2010-2014 года. За это время прошло порядка 7 тендеров на доработки. Причем каждый тендер оформлялся в уникальном неймспейсе (ДА Карл - наследование в более 10 слоев - причем базовый пакет может быть перенаследован в различных пакетах. Пришла контора Рога и Копыта из Гондураса и сделали package gn.roga.kopyta отнаследовала и переопределила те классы которые нужно и таких контор минимум 7). JSF фрейворк писали заново по тендору. Документации на его не оставили. И при этом не реальные сроки выполнения задач на старте. Я сначала смотрел у удивлялся - а почему народ вешает заплатки и не смотрит влияет она на что-то или нет, или вообще пишет какой-то код который не куда не ведет? А просто код есть - задача выполнена, скорость высокая - от начальства не прилетит. И это норма. Это похоже такой стиль работы. А что проект основной во всех 500 предприятиях РосАтома и пользуется активно. Не работает - так большая группа поддержки все исправляет в ручную.
Похоже Google делает все, что бы на Руси не перевелись настоящие программисты.
А было время когда мечтали или космонавтом или полярником. В 90-х тоже карьеру начинать не очень было. Комп стоил чуть дороже квартиры и за надлежавшее использование могли просто "спросить".
Пытался указать про то что они взяли клоуна. Но клоун похоже таким хорошим и родным оказался. Я просто взвесил все проблемы с нервотрепкой который этот клоун мне доставит и ушел. Там еще к тому же кусок функционала надо было рефакторить большой. Мне просто после криков от клоуна что он прав не хотелось. Он к стати психологически просто хорошо подготовлен был. В общем учите менторы таких вот крутых специалистов.
1) Нет высшего образования 2) Git flow вообще не знает. Начал какой-то бред нести про универсальную версию продукта - ну и там major.minor.patch - вообще не понимал что и как (ментор поди не рассказал) 3) Unit тесты вообще писать не мог. 4) Какие-то не понятные архитектурные решения (но это просто мое личное мнение - пусть дальше сам разбирается) - В общем много моментов. Ну с испытательного срока. Типа он давал такие ценные указания - которая команда не делал - он в этом не виноват. Ну и по этим причинам он прошел испытательный срок. После этого я просто не захотел дальше тянуть проект и ушел. Пусть Сбер сам с ним нянчится.
В СберТех меня вышиб такой вот накрутчик. Просто работать с "специалистом" который просто что умеет, как много и красиво говорить, но не чего при этом не делал плохо, а вот работать под его начальством вообще не возможно. При этом учитывая что начальник управления оказался инженер-механик ставший DevOps, для которого те речи показались внушали доверия. В общем в БигТех давно формируется фейковый мир фейковых специалистов.
Сигнатура сигнала плывет - то есть: При отражение фаза меняется и ловишь изменение фазы. Но если не знаешь исходную фазу - то как определить на сколько фазу отразилась. Если ребята эту проблему решили каким-то образом - то хорошо. Еще какие секреты рассказать?
Если они смогли решить проблему плавающего сигнала у излучателя - то им уважение. Мое личное мнение такое - если в 2014 в Микране продолжили хотя бы в фоновом режиме работу над антидронным комплексом - то в 2022 году можно было микрановский конвейер в 3 смены в легкую пустить, а не собирать антидронные комплексы на коленках.
В Подмосковье и Нижнем Новгороде можно обычные цифровые радары поставить с классическими излучателями - которые выдают сигнал стабильного вида и у которого меньше будет сложности с БПФ. Там преобразование адово будет - источник сигнала на плавающем расстоянии, плюс сигнал с неоднородной структурой. Разрешение радара будет низкое с высокими шумами. Учитывая что дрон имеет площадь с слабым отражением - то идея использование стороннего излучателя становится не понятной. Удешевление в одном, за счет понижения качества и удорожание другого. Я не отрицаю идею - но вот назначение?
Речь шла не о РЛС - над ней Микран работал и работает, хотя и активная. А антидроным комплексом подавления. Тогда из-за перспективности положили под сукно, а в 22-ом году начали на коленках в срочном порядке делать. Про пассивную РЛС вернее всего такая же история. С другой стороны не понятно надежность такой системы. Сторонний не контролируемый источник - это меньшая точность, при малых объектах - это критично. Плюс в зоне боевых действий глушат все. А в не боевых - можно своим источником пользоваться.
До 2014 года ниокрили эту тему, потом решили что не перспективна и тему закрыли. Сейчас не знаю. Уже давно не работаю.
Помнится в "Микран" в 2014-2016 году были антидронные разработки, Но их под сукно положили - денег не было на них. Да и кто знал, что дроны так интенсивно начнут использовать.