Только этих мессенджеров уже развелось что-то много. И каждый год-два на какой-то более популярный переходим по какой-либо причине. Никакой стабильности.
У меня тоже на сайта за последний год сильнейшее падение. Чую, не будет больше сайтов, сделанных одиночками. Только тинькоффы всякие останутся. Ну и выдача готового ответа самими поисковиками, которая до списка результатов.
А по-моему, в 2025 основная проблема продвижения - это всякие чат-боты на нейросетях. Вон, у яндекса первым результатом сразу ответ нейросеть даёт. Конечно, на конечные сайты никто уже и не будет переходить.
Смысл в таких условиях писать что-то себе в блог? Разве что для себя, любимого. Только зря нейросетки бесплатно обучать. Никто твой сайт не найдёт.
Там ещё всякие фичи современных стандартов веба реализуют, чтобы мы потом тормозные сайты клепали с десятками мегабайт ужатых скриптов, стилей, шрифтов, разметок и прочего.
А теперь представьте, например самолет. Самолет как законченное изделие состоит из множества блоков. Современные системы все больше уходят на электронику и оптику. Это легче, более помехозащищено. Проще протянуть несколько проводов и шины управления чем тянуть тросы, гидравлику и кучу проводов. Но вдруг, один из компонентов подобной системы перестанет корректно работать. Не на уровне одного экземпляра, а на уровне првеленческой модели. И вот Вы уже не сможете поднять в воздух самолет. Или, что еще хуже,- посадить его.
Я думал, что это просто эмоционально окрашенное выражение, чтобы показать пережитый ужас. Волосы же после луковицы уже какие есть, такие и есть. Как они могут поменять цвет?
Я вообще считаю, что все эти проценты просто попытка получить какое-то число. Но ведь нужно не число, нужно чтобы тесты реально проверяли то, что нужно проверять. Важно писать тесты, которые проверяют ту часть, которая реально нуждается в проверке. Они должны проверять какую-то фичу, сделанную по задаче, чтобы если разработчик сломал фичу, то у него упал этот тест. Они должны проверять основную логику приложения, чтобы быть уверенным, что приложение ещё работает. Они должны проверять обработку ошибок, чтобы быть уверенным, что ошибки ещё обрабатываются, и их обработка не сломана. И т. д. А просто тест ради покрытия вряд ли принесёт какую-то пользу.
У SpringBoot отдельные аннотации для тестирования отдельных слоёв приложения: сериализации JSON, контроллеров MVC, слоя доступа к данным и т. д. Они используются, чтобы весь контекст спринга не поднимать, если я правильно помню.
Но ведь в этом методе можно целую иерархию классов вложенных описать с кучей методов. И на выходе после компиляции получится не один class-файл, а целая куча.
Только этих мессенджеров уже развелось что-то много. И каждый год-два на какой-то более популярный переходим по какой-либо причине. Никакой стабильности.
Пошёл в Страну Вечной Охоты. Будет гулять там держась за ручку с MSN Messenger.
А может, это не он вернул. Может, это сами пользователи видят ответ нейросети на свой вопрос, а на сам сайт уже и не заходят?
У меня тоже на сайта за последний год сильнейшее падение. Чую, не будет больше сайтов, сделанных одиночками. Только тинькоффы всякие останутся. Ну и выдача готового ответа самими поисковиками, которая до списка результатов.
А по-моему, в 2025 основная проблема продвижения - это всякие чат-боты на нейросетях. Вон, у яндекса первым результатом сразу ответ нейросеть даёт. Конечно, на конечные сайты никто уже и не будет переходить.
Смысл в таких условиях писать что-то себе в блог? Разве что для себя, любимого. Только зря нейросетки бесплатно обучать. Никто твой сайт не найдёт.
Может, там в договоре с Google в примечаниях сказано так делать, чтобы и впредь продолжали финансировать.
Там ещё всякие фичи современных стандартов веба реализуют, чтобы мы потом тормозные сайты клепали с десятками мегабайт ужатых скриптов, стилей, шрифтов, разметок и прочего.
Я ещё помню времена, когда про Internet Explorer так говорили.
Жаль, что они об этом редко знают.
Там это, передозировку можно легко словить. Поаккуратнее как-то что-ли.
Скрытый текст
Это смотря что этими юнит-тестами тестировать. Если логику какого-нибудь метода, который что-то рассчитывает, то самое то.
Я думал, что это просто эмоционально окрашенное выражение, чтобы показать пережитый ужас. Волосы же после луковицы уже какие есть, такие и есть. Как они могут поменять цвет?
Можно под Кратоса потом начать косить.
Я вообще считаю, что все эти проценты просто попытка получить какое-то число. Но ведь нужно не число, нужно чтобы тесты реально проверяли то, что нужно проверять. Важно писать тесты, которые проверяют ту часть, которая реально нуждается в проверке. Они должны проверять какую-то фичу, сделанную по задаче, чтобы если разработчик сломал фичу, то у него упал этот тест. Они должны проверять основную логику приложения, чтобы быть уверенным, что приложение ещё работает. Они должны проверять обработку ошибок, чтобы быть уверенным, что ошибки ещё обрабатываются, и их обработка не сломана. И т. д. А просто тест ради покрытия вряд ли принесёт какую-то пользу.
У SpringBoot отдельные аннотации для тестирования отдельных слоёв приложения: сериализации JSON, контроллеров MVC, слоя доступа к данным и т. д. Они используются, чтобы весь контекст спринга не поднимать, если я правильно помню.
Сильны энтузиасты наши.
АЛЬМСИВИ!
Мне кажется, всякие nocode-подходы с незапамятных времен пытаются внедрить, а не только сейчас.
Но ведь в этом методе можно целую иерархию классов вложенных описать с кучей методов. И на выходе после компиляции получится не один class-файл, а целая куча.