Но карточка на Wildberries или Ozon выглядит так, будто её фотографировали на кухне при выключенном свете. Конверсия — ноль. Продаж — нет.
Ну ну… впаривайте дальше. Да я скорее куплю то, что сфотано на полу на фоне чего угодно, чем нарисованную картинку которая в 99% случаев вообще мало сопоставима с товаром. Хорошо если есть хоть один отзыв покупателя с фото, где можно понять как товар выглядит на самом деле. А иначе, эта карточка СРАЗУ пролистывается. Неужели кто то еще ведется на нарисованную фигню?
Сейчас меня запинают ногами апологеты Spring Boot. Но не могу удержатся.
Потому что столько времени потратил на копания в потрохах/исходниках Spring при решении неожиданных проблем. И отнюдь не в восторге от всего этого. Так оно еще от версии к версии сильно меняется и перелопачивается.
Часто вспоминается анекдот про самолет в котором пилот лайнера объявляет перед взлетом:
– на первой палубе у нас бассейн, на второй палубе ресторан и зал отдыха, на третье палубе комфортабельные каюты…
– а теперь со всех этой хренью мы попытаемся взлететь
Накладываем поверх jdbc еще парус слоев кода и вот уже доклады и разборы по поводу “магии Spring”. При работе с jdbc в разным БД уже бывают интересные нюансы. А тут еще пара слоев обертки вокруг. Шаг вправо, шаг влево от “типичного применения” и времени тратишь столько, что проще без всех этих оберток делать критические сервисы.
остается одна надежда… услышать лебединое озеро по центральным каналам. остальные альтернативы хуже. Не хочется ни 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. Заменил некоторые либы и все.
ну я все надеюсь на лучшее, что большая часть человечество в целом обладает критическим мышлением. Возможно ошибаюсь… Но надеться же можно.
Ключевое слово “за 5 минут”. Экономия типа…
Ну ну… впаривайте дальше. Да я скорее куплю то, что сфотано на полу на фоне чего угодно, чем нарисованную картинку которая в 99% случаев вообще мало сопоставима с товаром. Хорошо если есть хоть один отзыв покупателя с фото, где можно понять как товар выглядит на самом деле. А иначе, эта карточка СРАЗУ пролистывается. Неужели кто то еще ведется на нарисованную фигню?
угу… прикомандированный… а процент акций во “владении” это так. Все же не в СССР живем. Бабло все движет.
да просто посмотрите кто и зачем является сын первого замдиректора ФСБ…
Сейчас меня запинают ногами апологеты Spring Boot. Но не могу удержатся.
Потому что столько времени потратил на копания в потрохах/исходниках Spring при решении неожиданных проблем. И отнюдь не в восторге от всего этого. Так оно еще от версии к версии сильно меняется и перелопачивается.
Часто вспоминается анекдот про самолет в котором пилот лайнера объявляет перед взлетом:
– на первой палубе у нас бассейн, на второй палубе ресторан и зал отдыха, на третье палубе комфортабельные каюты…
– а теперь со всех этой хренью мы попытаемся взлететь
Накладываем поверх jdbc еще парус слоев кода и вот уже доклады и разборы по поводу “магии Spring”. При работе с jdbc в разным БД уже бывают интересные нюансы. А тут еще пара слоев обертки вокруг. Шаг вправо, шаг влево от “типичного применения” и времени тратишь столько, что проще без всех этих оберток делать критические сервисы.
остается одна надежда… услышать лебединое озеро по центральным каналам. остальные альтернативы хуже. Не хочется ни 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.