Ниже объяснил все. Разъяснение юристов СберТех - продукт в котором случился казус тоже ниже назвал. Вот так все у нас в стране обстаит. А единственное что я хотел - это что бы дали время на нормальную декомпиляцию и ПОЛНЫЙ РЕФАКТОРИНГ! То есть переписывание кода на основе сторонего кода. К стати посмотрел OpenIde и их plugin они именно так и поступают. А вот в GigaIDE - опять прямая декомпиляция и .......
Во заминусовали по полной. Но эта правда жизни. Продукт Platform V:Artifactoty - под эгидой СберТех. Приказ сверху - тупая декомпиляция плагин от SonaType Nexus - добиваемся минимальной работоспособности - и продаем направо и лево. Как я начал задавать вопросы - тут же создали условия для моего увольнения. При этом было заявлено - стратегия согласована с юристом и расклад согласования - как я озвучил! Так что удачи минусаторы и великая контора СберТех
Для того что бы подать в суд в РФ, им надо доказать что этот программный продукт им принадлежит. На территории РФ, это делается одним способом, через реестр программного обеспечения. Я не подбиваю нарушать авторские права, я просто говорю как на самом деле обстоит.
Есть. Сам в СберТех в этом участвовал. Нет это не GigaIDE - другой продукт из линейки Platform V. Пока дело касалась расширение, доработки Open Source еще было терпимо. Потом понадобилось "перевести" комерческие плагины с нереальными сроками, началась эта жуть. Не было возможности что с кодом там происходит и как он работает. По этому ушел.
Она ушла. Ее нет в российском реестре программного обеспечения. Нет в реестре - значит нет оснований для преследование на территории РФ. Таким образом ребята из СберТех декомпилируют ПО и даже не думаю проводить какой-то рефакторинг, просто добиваются собираемости и ПРОДАЮТ! Так что сначала уж лучше их
Многое упустили. Живу в часовом поясе +4 к Москве. Несколько лет работал по московскому времени. Могу точно сказать - все это шаманство и бубны в виде лампы по утрам не помогают. Если ты завершаешь работу в 18-00 у тебя остается время для того что бы перед сном отвлечься от работы. Ты сможешь сходить куда-нибудь поужинать или посетить спортзал. Но если завершаешь работать в 22-00 или еще хуже в 23-00 - то выбраться не куда не удается. Так что можно так прожить год или два - но потом наступает просто дикие проблемы.
Один мой бывший начальник, не только не любил тестировать, но и вообще запускать продукт после сборки. Регулярно после него приходилось чинить, то что не собиралось. Зря ему про это говорил! Его повысили и он от меня избавился. А вы тестируйте за собой! (Все это шутка, но сами понимаете на реальных событиях)
Да тоже интересно было бы, но вопрос в том - поддерживает ли их 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) Какие-то не понятные архитектурные решения (но это просто мое личное мнение - пусть дальше сам разбирается) - В общем много моментов. Ну с испытательного срока. Типа он давал такие ценные указания - которая команда не делал - он в этом не виноват. Ну и по этим причинам он прошел испытательный срок. После этого я просто не захотел дальше тянуть проект и ушел. Пусть Сбер сам с ним нянчится.
Ниже объяснил все. Разъяснение юристов СберТех - продукт в котором случился казус тоже ниже назвал. Вот так все у нас в стране обстаит. А единственное что я хотел - это что бы дали время на нормальную декомпиляцию и ПОЛНЫЙ РЕФАКТОРИНГ! То есть переписывание кода на основе сторонего кода. К стати посмотрел OpenIde и их plugin они именно так и поступают. А вот в GigaIDE - опять прямая декомпиляция и .......
Во заминусовали по полной. Но эта правда жизни. Продукт Platform V:Artifactoty - под эгидой СберТех. Приказ сверху - тупая декомпиляция плагин от SonaType Nexus - добиваемся минимальной работоспособности - и продаем направо и лево. Как я начал задавать вопросы - тут же создали условия для моего увольнения. При этом было заявлено - стратегия согласована с юристом и расклад согласования - как я озвучил! Так что удачи минусаторы и великая контора СберТех
Для того что бы подать в суд в РФ, им надо доказать что этот программный продукт им принадлежит. На территории РФ, это делается одним способом, через реестр программного обеспечения. Я не подбиваю нарушать авторские права, я просто говорю как на самом деле обстоит.
Есть. Сам в СберТех в этом участвовал. Нет это не GigaIDE - другой продукт из линейки Platform V. Пока дело касалась расширение, доработки Open Source еще было терпимо. Потом понадобилось "перевести" комерческие плагины с нереальными сроками, началась эта жуть. Не было возможности что с кодом там происходит и как он работает. По этому ушел.
Она ушла. Ее нет в российском реестре программного обеспечения. Нет в реестре - значит нет оснований для преследование на территории РФ. Таким образом ребята из СберТех декомпилируют ПО и даже не думаю проводить какой-то рефакторинг, просто добиваются собираемости и ПРОДАЮТ! Так что сначала уж лучше их
Порой проблема не в том, что появляется технический долг, а в том, что бизнес не понимает что он появляется.
Многое упустили. Живу в часовом поясе +4 к Москве. Несколько лет работал по московскому времени. Могу точно сказать - все это шаманство и бубны в виде лампы по утрам не помогают. Если ты завершаешь работу в 18-00 у тебя остается время для того что бы перед сном отвлечься от работы. Ты сможешь сходить куда-нибудь поужинать или посетить спортзал. Но если завершаешь работать в 22-00 или еще хуже в 23-00 - то выбраться не куда не удается. Так что можно так прожить год или два - но потом наступает просто дикие проблемы.
Один мой бывший начальник, не только не любил тестировать, но и вообще запускать продукт после сборки. Регулярно после него приходилось чинить, то что не собиралось. Зря ему про это говорил! Его повысили и он от меня избавился. А вы тестируйте за собой! (Все это шутка, но сами понимаете на реальных событиях)
Да тоже интересно было бы, но вопрос в том - поддерживает ли их 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) Какие-то не понятные архитектурные решения (но это просто мое личное мнение - пусть дальше сам разбирается) - В общем много моментов. Ну с испытательного срока. Типа он давал такие ценные указания - которая команда не делал - он в этом не виноват. Ну и по этим причинам он прошел испытательный срок. После этого я просто не захотел дальше тянуть проект и ушел. Пусть Сбер сам с ним нянчится.