остается одна надежда… услышать лебединое озеро по центральным каналам. остальные альтернативы хуже. Не хочется ни 37го ни 17го года. А пока все идет к одну из этих вариантов.
В IT — 20 c копейками лет. Потрудился в восьми компаниях, в пяти из них управлял отделами.
Не обязательно относится к автору статьи, но почему то навеяло.
Типаж - кочующий менеджер. Знаю. сталкивался. Зачастую даже дают очень хорошую характеристику лишь бы ушел поскорее (увольнение по своему желанию) куда ни будь в другое место. Сем видел несколько таких примеров (впрочем и с программерами то же).
При этом частое смена работы по причине (по словам) “стало не интересно там. не те масштабы”. Но по факту, обычно пол года дают на вхождение в тему, год на “ну может быть получше будет. отчеты же хорошие”. А потом просто сваливает в другое место.
Основное чем оперирует - трудоднями и красивыми отчетами для начальства.
До сих пор помню как “преподаватель” на курсах PME рассказывал, что настоящему менеджеру проектов все равно чем управлять “хоть созданием космического кОробля, хоть стройкой дома” (сейчас не можно, но как то занесло и получил сертификат)
Год работы по объединению людей, создание общины. Сначала — молоковоз. Потом — больше коров. Потом — нашли предпринимателя под сырное производство. Результат: сырзавод с итальянским оборудованием (актив 20 млн), туры выходного дня из Владивостока, трёхзвенная экономика — фермеры, переработка, туризм. Около 30 человек в каждом звене.
А потому приезжает ОМОН, полицаи (ну так машин 20 на деревню), автозаки и всех животных убивают. Без выдачи справок, учета и анализа на заболевания. И без каких то внятных объяснений от кого либо.
Похоже ssh то же режут. И, похоже, по размеру трафика. У меня видеонаблюдение от raspberry pi с камерой на VPS (Нидерланды) через ssh туннель. Еще год назад работало все идеально. А теперь через 10-20 сек начала передачи видеопотока - начинает канал деградировать (IP пакеты теряются) до практически полной остановки.
Не... конечно могу быть и другие причины. Зла желать вредно, но почему то очень хочется что бы сдохли некоторые люди.
Я об ИИ говорил. И что значит "удивляюсь". Впрочем, тому что люди придумывают в чужих словах того что не было - я давно не удивляюсь.
А код написанный и протестированный только тем кто этот код и писал в продакшен без тестов другими людьми - ну наверное кто то так и работает. До первый проблем в эксплуатации.
Потому, что все это работает при полном погружении в электролит. Т.е. фактически для судов в морской воде. А сухопутном варианте, то как? очаговое попадание влаги. где тут будет ток течь?
Так что все эти
Для этого, аноды укрепляют: внутри колёсных арок, на днище автомобиля — то есть, в местах наиболее подверженных воздействию влаги. Интересный опыт по таким работам описан вот здесь и вот здесь.
Ротор поля наподобие дивергенции градуирует себя вдоль спина и там, внутре, обращает материю вопроса в спиритуальные электрические вихри, из коих и возникает синекдоха отвечания
А я уже и подзабыл эту цитату! Спасибо что напомнили. Надо будет ее заучить и ей объяснять как работают LLM А то когда кто то из народа далекого в теме начинает спрашивать, то на фразы "вектор мерностью N, где N=.." вижу в глаза "где то я термины слышал... но что за занудство".
Да ну.. Когда созданный ИИ код покрывается созданным ИИ тестами на основе этого же исходного кода, это... Это выглядит красиво (100% пройденные "тесты"). Но по факту это дрять, которую в прод не стоит пускать. Ну конечно, если это ПО не для "ой мы сейчас покажем демонстрашку", а для прода где цена сбоя ошибки весьма болезненна.
Но в программировании сертификация обычно быстрее и дешевле.
Смешно.. Тестирование занимает обычно больше времени и ресурсов, чем написание кода (ну как минимум в области финансового ПО).
Думаю очевидно, что проблема тут ни разу не в Спринге, а в том, что кто-то не хочет включать мозг, и спускает указивки на "устранение уязвимостей" не приходя в сознание.
В данном случае, мир под себя не сломаешь. Приходится делать то, за что платят. А как вам требования для ПО которое отправляется на сертификацию: "все комментарии к коде должны быть на русском и термины то же". Приходится.. удерживаясь от русского мата в комментариях и позволяя себе только фигу в кармане, использования православных терминов "поток" (stream) и "поток" (thrеad) в одной фразе в разных смыслах.
А Спринг мне и по другим причинам не очень нравится.
Очень много ресурсов тянет при старте программы, на фактически динамическую компиляцию (замечательно писать в JpaRepository типа findFirstByEntityIdAndAccount, но это все расходы на старте)
Шаг право - влево и мучительный поиск "как сделать" включая копания в исходниках Спринг.
п1. - на самом деле самый проблемный. Не разработчику. А эксплуатации. Когда на HighLoad++ целое тема была посвящена "как мы запускаем массово сразу много сервисов SpringBoot одновременно, оптимизируя запуск".
А вас не достают требованиями СИБ о том что нужно "сделать так что бы анализатор не показывал уязвимостей". Причем доводы о том, что эта "уязвимость" в принципе не применима к данному прикладному ПО, просто не принимаются во внимание. "не должен показывать" и все тут.
Так и довод мой довод, что "gzip" в принципе не может прилететь из этого доверенного источника, не был принят во внимание (если уж источник/канал компрометирован, то от туда прилетит финансовое распоряжение, а не gzip бомба) "не должно быть.." Психанул и заменил на grizzly. Благо сервис не на Spring Boot и меняется легко.
А Spring Boot это вообще.. переписывать на 4.x cо старых 2.x потому что "не должно быть сообщений об уязвимости".. Сервисы которым уже по 10 лет (и работают). А на Spring Boot 2.x.x строчек 20 сообщений об уязвимостях на самой последней версии.
Да лучше бы сразу было написано без оберток Spring Boot. Заменил некоторые либы и все.
Берем из всей многогранность работы с Java threads и набора инcтрументов для синхронизации один очень частный случай и опс... статья готовая. Примитивная до нельзя.
Неа. Фишка не в том, что бы перейти на ГОСТ криптографию. А в том, что бы покупать ПО и железки у "нужных" компаний. Сертификация в ФСБ это только нужным. На bouncycastle вполне формируются/проверяются те же CMS и просто подписи, которые совместимы с JCP. Но... незя.. использовать не сертифицированные крипто либы. Вот и вместо BC с прозрачной (да хоть исходники есть) и привычным API работы с тем же ASN1 - будь добр использовать JCP API. (Хотя там все одно на основе opensorce либы сделано)
остается одна надежда… услышать лебединое озеро по центральным каналам. остальные альтернативы хуже. Не хочется ни 37го ни 17го года. А пока все идет к одну из этих вариантов.
Не обязательно относится к автору статьи, но почему то навеяло.
Типаж - кочующий менеджер. Знаю. сталкивался. Зачастую даже дают очень хорошую характеристику лишь бы ушел поскорее (увольнение по своему желанию) куда ни будь в другое место. Сем видел несколько таких примеров (впрочем и с программерами то же).
При этом частое смена работы по причине (по словам) “стало не интересно там. не те масштабы”. Но по факту, обычно пол года дают на вхождение в тему, год на “ну может быть получше будет. отчеты же хорошие”. А потом просто сваливает в другое место.
Основное чем оперирует - трудоднями и красивыми отчетами для начальства.
До сих пор помню как “преподаватель” на курсах PME рассказывал, что настоящему менеджеру проектов все равно чем управлять “хоть созданием космического кОробля, хоть стройкой дома” (сейчас не можно, но как то занесло и получил сертификат)
Посмотрел ради интереса ваши комментрии.
ну и т.д.
В принципе, с вашей позицией и кругом общения все понятно.
вот же блин.
читаешь (ну в принципе обычные проблемы). Ждешь каких то примеров из жизни.
и тут бац
И осознаешь, что вся статья - это просто тупо реклама.
автор еще и неприкасаемый (карму слить недоступно).
А судя по статьям станочник широкого профиля. на любые темы.
В общем заказуха...
А потому приезжает ОМОН, полицаи (ну так машин 20 на деревню), автозаки и всех животных убивают.
Без выдачи справок, учета и анализа на заболевания. И без каких то внятных объяснений от кого либо.
Похоже ssh то же режут. И, похоже, по размеру трафика.
У меня видеонаблюдение от raspberry pi с камерой на VPS (Нидерланды) через ssh туннель.
Еще год назад работало все идеально. А теперь через 10-20 сек начала передачи видеопотока - начинает канал деградировать (IP пакеты теряются) до практически полной остановки.
Не... конечно могу быть и другие причины.
Зла желать вредно, но почему то очень хочется что бы сдохли некоторые люди.
Я об ИИ говорил. И что значит "удивляюсь".
Впрочем, тому что люди придумывают в чужих словах того что не было - я давно не удивляюсь.
А код написанный и протестированный только тем кто этот код и писал в продакшен без тестов другими людьми - ну наверное кто то так и работает. До первый проблем в эксплуатации.
Потому, что все это работает при полном погружении в электролит. Т.е. фактически для судов в морской воде. А сухопутном варианте, то как?
очаговое попадание влаги. где тут будет ток течь?
Так что все эти
В сущности маркетинговый развод.
А я уже и подзабыл эту цитату! Спасибо что напомнили.
Надо будет ее заучить и ей объяснять как работают LLM
А то когда кто то из народа далекого в теме начинает спрашивать, то на фразы "вектор мерностью N, где N=.." вижу в глаза "где то я термины слышал... но что за занудство".
А тут все просто "ротор поля дивергенции" :))))
Да ну.. Когда созданный ИИ код покрывается созданным ИИ тестами на основе этого же исходного кода, это...
Это выглядит красиво (100% пройденные "тесты").
Но по факту это дрять, которую в прод не стоит пускать.
Ну конечно, если это ПО не для "ой мы сейчас покажем демонстрашку", а для прода где цена сбоя ошибки весьма болезненна.
Смешно..
Тестирование занимает обычно больше времени и ресурсов, чем написание кода (ну как минимум в области финансового ПО).
В данном случае, мир под себя не сломаешь. Приходится делать то, за что платят.
А как вам требования для ПО которое отправляется на сертификацию: "все комментарии к коде должны быть на русском и термины то же". Приходится.. удерживаясь от русского мата в комментариях и позволяя себе только фигу в кармане, использования православных терминов "поток" (stream) и "поток" (thrеad) в одной фразе в разных смыслах.
А Спринг мне и по другим причинам не очень нравится.
Очень много ресурсов тянет при старте программы, на фактически динамическую компиляцию (замечательно писать в JpaRepository типа findFirstByEntityIdAndAccount, но это все расходы на старте)
Шаг право - влево и мучительный поиск "как сделать" включая копания в исходниках Спринг.
п1. - на самом деле самый проблемный. Не разработчику. А эксплуатации. Когда на HighLoad++ целое тема была посвящена "как мы запускаем массово сразу много сервисов SpringBoot одновременно, оптимизируя запуск".
5.0 Jan 20, 2026
"Вам шашечки или ехать"
Честно говоря, не очень понимаю это гонки за версиями и "используем все самое последнее и давайте все перепишем под другой фреймворк".
По производительности или по устойчивости вот ни раза не заметил разницы grizzly с tomcat или jetty.
А так, мне пофиг в каком окружении крутится прикладной код, решающий задачи, которые мне ставит бизнес.
И в принципе использовать javax.ws.rs./jakarta.ws.rs. для задания WEB API или org.springframework.web.bind.annotation.* то же разницы нет особой.
А вас не достают требованиями СИБ о том что нужно "сделать так что бы анализатор не показывал уязвимостей".
Причем доводы о том, что эта "уязвимость" в принципе не применима к данному прикладному ПО, просто не принимаются во внимание.
"не должен показывать" и все тут.
Так и довод мой довод, что "gzip" в принципе не может прилететь из этого доверенного источника, не был принят во внимание (если уж источник/канал компрометирован, то от туда прилетит финансовое распоряжение, а не gzip бомба)
"не должно быть.."
Психанул и заменил на grizzly. Благо сервис не на Spring Boot и меняется легко.
А Spring Boot это вообще.. переписывать на 4.x cо старых 2.x потому что "не должно быть сообщений об уязвимости".. Сервисы которым уже по 10 лет (и работают).
А на Spring Boot 2.x.x строчек 20 сообщений об уязвимостях на самой последней версии.
Да лучше бы сразу было написано без оберток Spring Boot. Заменил некоторые либы и все.
Не люблю Spring Boot. По возможности не использую.
А в тех сервисах, где Spring Boot(с 10 где то), то в них там tomcat.
достали постоянные критические уязвимости в Jetty и переключил сервисы на grizzly
Как то в нем меньше уязвимостей находят.
Берем из всей многогранность работы с Java threads и набора инcтрументов для синхронизации один очень частный случай и опс... статья готовая. Примитивная до нельзя.
Зачем я вообще это читал и открыл..
Неа.
Фишка не в том, что бы перейти на ГОСТ криптографию. А в том, что бы покупать ПО и железки у "нужных" компаний. Сертификация в ФСБ это только нужным.
На bouncycastle вполне формируются/проверяются те же CMS и просто подписи, которые совместимы с JCP. Но... незя.. использовать не сертифицированные крипто либы.
Вот и вместо BC с прозрачной (да хоть исходники есть) и привычным API работы с тем же ASN1 - будь добр использовать JCP API. (Хотя там все одно на основе opensorce либы сделано)
ничем не смущает. так и пользую.
Смутила фраза в тексте статьи
В драйвере.
Подумал, что вдруг чего не знаю (хотя часто копался в исходниках PG jdbc и дебажил Oracle jdbc)
да. Скорее всего ОЗУ. Но это явно нигде не сказано и та же проблема касается сохранения на диске.