Год работы по объединению людей, создание общины. Сначала — молоковоз. Потом — больше коров. Потом — нашли предпринимателя под сырное производство. Результат: сырзавод с итальянским оборудованием (актив 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 либы сделано)
имеет следующее расположение полей в памяти: .. Итого — структура занимает 40 байт
А вот нифига. В некоторых аппаратных платформах структуры выравниваются ВСЕГДА на 4 байта. Включая bool. Так что попытка записать структуру из C/C++ кода на диск (как область памяти по указателю и sizeof(..)) на одной платформе и прочитать ее в память "как есть" (наивный подход) на другой платформе приведет к проблемам. Плавали... знаем. Ща поменьше стало (sparc RIP), но все равно мир не заканчивается x86.
Так что, упаковка/распаковка данных из локального формата перед запись/чтением куда либо (диск, БД) - это вообще стандарт (должно быть).
Ладно игра... А когда в WAL Postgre все данные выровнены на границу 4-х байт (понятно конечно откуда ноги растут) и даже на первый взгляд можно получить упаковкой экономию размера файлов от 1-15% (зависит от структуры/формата полей таблиц. Меньше прикладные данные - больше экономия на заголовках в процентах) И все ради "а побыстрее обрабатывать" (наверное)? Opensource ПО блин. И сейчас на PG огромные системы пытаются переносить. А по факту разработчиков основных PG можно по пальцем рук пересчитать. И банально некогда им оптимизировать.
Логирование медленных запросов: Нужно настроить в драйвере или на уровне базы, чтобы видеть запросы, выполняющиеся дольше 100 мс.
На уровне БД - понятно. Но это не лучший способ. Сопоставлять сложно события в прикладном ПО с логом БД.
Но, не видел, что бы в драйвере Oracle или PG можно было настроить такое (warn). Можно настроить stmt.setQueryTimeout(..). Что будет порождать типа ORA-01013: user requested cancel of current operation (в PG похожее). Но это отказ, а не warning для лога. Т.е. это предельный таймаут для отмены.
А что бы warn в логе..
либо своя обертка вокруг jdbc (кстати, полезно для логирования вообще), если не используется стандартная обертка типа hibernate
либо выставления "hibernate.session.events.log.LOG_QUERIES_SLOWER_THAN_MS=..." для hibernate
Если знаете (вдруг есть) какие то средства для того что бы на уровне jdbc драйвера выводить WARN на запросы, которые выполнились, но выполнились дольше чем указано - подскажите pls.
Копался и в Oracle jdbc и в PG исходниках jdbc.. Даже намека на такое не видел.
вот же блин.
читаешь (ну в принципе обычные проблемы). Ждешь каких то примеров из жизни.
и тут бац
И осознаешь, что вся статья - это просто тупо реклама.
автор еще и неприкасаемый (карму слить недоступно).
А судя по статьям станочник широкого профиля. на любые темы.
В общем заказуха...
А потому приезжает ОМОН, полицаи (ну так машин 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)
да. Скорее всего ОЗУ. Но это явно нигде не сказано и та же проблема касается сохранения на диске.
А вот нифига. В некоторых аппаратных платформах структуры выравниваются ВСЕГДА на 4 байта. Включая bool. Так что попытка записать структуру из C/C++ кода на диск (как область памяти по указателю и sizeof(..)) на одной платформе и прочитать ее в память "как есть" (наивный подход) на другой платформе приведет к проблемам. Плавали... знаем. Ща поменьше стало (sparc RIP), но все равно мир не заканчивается x86.
Так что, упаковка/распаковка данных из локального формата перед запись/чтением куда либо (диск, БД) - это вообще стандарт (должно быть).
Ладно игра... А когда в WAL Postgre все данные выровнены на границу 4-х байт (понятно конечно откуда ноги растут) и даже на первый взгляд можно получить упаковкой экономию размера файлов от 1-15% (зависит от структуры/формата полей таблиц. Меньше прикладные данные - больше экономия на заголовках в процентах)
И все ради "а побыстрее обрабатывать" (наверное)?
Opensource ПО блин. И сейчас на PG огромные системы пытаются переносить. А по факту разработчиков основных PG можно по пальцем рук пересчитать.
И банально некогда им оптимизировать.
На уровне БД - понятно. Но это не лучший способ. Сопоставлять сложно события в прикладном ПО с логом БД.
Но, не видел, что бы в драйвере Oracle или PG можно было настроить такое (warn). Можно настроить stmt.setQueryTimeout(..). Что будет порождать типа ORA-01013: user requested cancel of current operation (в PG похожее).
Но это отказ, а не warning для лога. Т.е. это предельный таймаут для отмены.
А что бы warn в логе..
либо своя обертка вокруг jdbc (кстати, полезно для логирования вообще), если не используется стандартная обертка типа hibernate
либо выставления "hibernate.session.events.log.LOG_QUERIES_SLOWER_THAN_MS=..." для hibernate
Если знаете (вдруг есть) какие то средства для того что бы на уровне jdbc драйвера выводить WARN на запросы, которые выполнились, но выполнились дольше чем указано - подскажите pls.
Копался и в Oracle jdbc и в PG исходниках jdbc.. Даже намека на такое не видел.
Замечательно работает и гидроксид (ржавчина собранная со металлолома - старых труб).
Проверено на практике в советском детстве.