Прогрессирует ≠ будет прогрессировать всегда с такой же скоростью.
Техпроцесс тоже прогрессировал стабильно до 7нм, а потом что-то пошло не так...
Тут как с Законом Мура, предел развития нейронок не за горами.
Недавние бешенные закупки памяти - это последний отчаянный рывок в попытке выйти на новый уровень, а потом пузырь всхлопнется и на рынке нейронок останется примерно то же, что у нас уже есть сейчас.
Единственный способ понять уровень уровень интелекта человека с помощью показателей IQ - поинтересоваться, верит ли он в эту шызотерику или нет.
Если верит или даже хвастается какими-то трехзначными баллами - значит человек с большой долей вероятности не очень умный, а возможно даже откровенно тупой.
Если относится скептически и не воспринимкет всерьез - значит человек с большой долей вероятности обладает критическим мышлением.
Интелект - это настолько сложная и комплексная вещь, что для него даже устоявшегося общепризнанного научного определения нет, а какие то "умники" пытаются его линейкой мерить...
Микросервисы - это не только про порядок в архитектуре (хотя и про это тоже), но и про надежность, гибкость и масштабируемость проекта.
Вот некоторые кейсы пользы микросервисов, выходящие за пределы просто архитектуры:
1) Допустим, мне нужно реализовать надежный, отказоустойчивый функционал для обработки данных, поступающих от партнеров. Я могу сделать отдельный сервис "приемник" который будет максимально легковесным и надежным, он будет ТОЛЬКО принимать данные и складывать их в очередь, благодаря чему партнеры смогут максимально быстро передавать нам данные почти мгновенно получая 200е коды и при этом у нас будут минимальные риски что в этом микросервисе что-то пойдет не так. А все риски и основную нагрузку будет брать на себя другой сервис, который будет эти данные обрабатывать в фоне. При этом, эта обработка никак не будет тормозить первый сервис, которым пользуются партнеры.
2) Допустим, среди доступного функционала у нас есть один наиболее ресурсозатратный флоу, дающий большую нагрузку на железо.
- В монолите, этот флоу всегда будет тормозить весь сервер, включая сервисы взаимодействующие с пользовательскими запросами. Даже если увеличить количество ресурсов, нагрузка от этого флоу всегда будет влиять на общее быстродействие системы.
- В микросервисной архитектуре, этот тяжелый флоу можно не только запускать на отдельных мощностях, но и масштабировать точечно только его. Просто статические буфера и прочий кэш заменяешь на межсервисную память типа redis и плодишь хоть 20 инстансов этого сервиса на отдельно выделенных ресурсах. При этом, сервисы для пользовательских запросов будут продолжать работать на отдельных мощностях и сайты/приложения для юзеров вообще никак не тормозятся в таком случае.
И это не какие то теоретические фантазии из области высоких материй, а реальные кейсы из личной практики, которые решают реальные проблемы на реальных проектах. При чем, это только первое что в голову пришло, продолжать можно долго при желании.
Статью можно брать в рамку и приводить как аргумент в пользу того, что питухон вызывает рак мозга, когда кто-то в интернете пытается защищать этот недоязык.
Фашизм - это деструктивный культ, основанный на диктатуре и тоталитаризме.
Смысл в том, что все это DEI движение тоже является деструктивным культом с делением людей на своих/несвоих, преследованием "неверных", культивацией ненависти к инакомыслию и прочими "прелестями" подобных сект. Хотя DEI по факту и не является буквально фашизмом, сравнение с фашизмом или религиозным фанатизмом тут вполне уместно.
Только смысл от нее есть только в очень редких специфических случаях, потому что повсеместное использование динамической типизации - прямой путь к бардаку и говнокоду.
Прогрессирует ≠ будет прогрессировать всегда с такой же скоростью.
Техпроцесс тоже прогрессировал стабильно до 7нм, а потом что-то пошло не так...
Тут как с Законом Мура, предел развития нейронок не за горами.
Недавние бешенные закупки памяти - это последний отчаянный рывок в попытке выйти на новый уровень, а потом пузырь всхлопнется и на рынке нейронок останется примерно то же, что у нас уже есть сейчас.
Если это не риторический вопрос, то Dispose вызовется в конце текущего скоупа фигурных скобок.
Так же можно написать await using чтоб вызвался DisposeAsync, если у объекта есть IAsyncDisposable
Гдето я это уже слышал)
Единственное что было реально полезно из всей университетской программы.
Какой же кринж...
Единственный способ понять уровень уровень интелекта человека с помощью показателей IQ - поинтересоваться, верит ли он в эту шызотерику или нет.
Если верит или даже хвастается какими-то трехзначными баллами - значит человек с большой долей вероятности не очень умный, а возможно даже откровенно тупой.
Если относится скептически и не воспринимкет всерьез - значит человек с большой долей вероятности обладает критическим мышлением.
Интелект - это настолько сложная и комплексная вещь, что для него даже устоявшегося общепризнанного научного определения нет, а какие то "умники" пытаются его линейкой мерить...
С одним согласен на 100% - если вайбкодинг взлетит, эту нишу тут же займут профессионалы, не оставив вкатунам никаких шансов.
Как бы хорошо модель не генерировала код, а присматривать за ним и вносить небольшие правки руками всегда будет необходимо.
Не уверен насчет индийских выпускников вузов, но редакторов на хабре ИИ заменил и вытеснил - это точно) XD
Совсем недавно знакомому согласился сделать небольшой asp net core mvc проект для курсовой и первым делом решил попробовать этот ваш вайбкод.
Широкими мазками он конечно накинул набросок, но чем дальше шел прогрес - тем хуже был результат и тем больше было нерабочего кода.
Итог: уже на второй день продолжил писать как обычно, по человечески.
Да они скорее всего тупо для красивого скриншота все пооткрывали сразу.
Наверняка можно будет эти окна настраивать.
Микросервисы - это не только про порядок в архитектуре (хотя и про это тоже), но и про надежность, гибкость и масштабируемость проекта.
Вот некоторые кейсы пользы микросервисов, выходящие за пределы просто архитектуры:
1) Допустим, мне нужно реализовать надежный, отказоустойчивый функционал для обработки данных, поступающих от партнеров. Я могу сделать отдельный сервис "приемник" который будет максимально легковесным и надежным, он будет ТОЛЬКО принимать данные и складывать их в очередь, благодаря чему партнеры смогут максимально быстро передавать нам данные почти мгновенно получая 200е коды и при этом у нас будут минимальные риски что в этом микросервисе что-то пойдет не так. А все риски и основную нагрузку будет брать на себя другой сервис, который будет эти данные обрабатывать в фоне. При этом, эта обработка никак не будет тормозить первый сервис, которым пользуются партнеры.
2) Допустим, среди доступного функционала у нас есть один наиболее ресурсозатратный флоу, дающий большую нагрузку на железо.
- В монолите, этот флоу всегда будет тормозить весь сервер, включая сервисы взаимодействующие с пользовательскими запросами. Даже если увеличить количество ресурсов, нагрузка от этого флоу всегда будет влиять на общее быстродействие системы.
- В микросервисной архитектуре, этот тяжелый флоу можно не только запускать на отдельных мощностях, но и масштабировать точечно только его. Просто статические буфера и прочий кэш заменяешь на межсервисную память типа redis и плодишь хоть 20 инстансов этого сервиса на отдельно выделенных ресурсах. При этом, сервисы для пользовательских запросов будут продолжать работать на отдельных мощностях и сайты/приложения для юзеров вообще никак не тормозятся в таком случае.
И это не какие то теоретические фантазии из области высоких материй, а реальные кейсы из личной практики, которые решают реальные проблемы на реальных проектах.
При чем, это только первое что в голову пришло, продолжать можно долго при желании.
Шедевр!
Статью можно брать в рамку и приводить как аргумент в пользу того, что питухон вызывает рак мозга, когда кто-то в интернете пытается защищать этот недоязык.
Спасибо, очень полезно(нет). Теперь ждём урок как включить комп для начинающих с домашним заданием.
Главное ссылку на телеграм оставить не забудьте.
Не вопрос, ждите ai резюме)
Миф 6 - «Архитектор должен писать код»Все что нужно знать о статье.
С таким же успехом, можно сказать что композитор не должен играть на инструменте, фитнес-тренер не должен иметь хорошую форму и т.д.
А что тогда архитектор должен? Широкими мазками обозначить: "эта штука делает то-то, а эта то-то и между ними ходят такие-то данные" ?
Это работа бизнес-аналитика, а не архитектора ПО.
Коротко о том, почему реально топовые программисты крайне редко меняют работу и никогда не контактируют с hr/рекрутерами
Фашизм - это деструктивный культ, основанный на диктатуре и тоталитаризме.
Смысл в том, что все это DEI движение тоже является деструктивным культом с делением людей на своих/несвоих, преследованием "неверных", культивацией ненависти к инакомыслию и прочими "прелестями" подобных сект. Хотя DEI по факту и не является буквально фашизмом, сравнение с фашизмом или религиозным фанатизмом тут вполне уместно.
Сегодня ведь сентябрь, а не 1 апреля?
Вы ведь не хотите сказать что это все серьезно?
Глупость. Игры, которые действительно пробивают потолок, можно пересчитать по пальцам.
В c# тоже есть динамическая типизация.
Только смысл от нее есть только в очень редких специфических случаях, потому что повсеместное использование динамической типизации - прямой путь к бардаку и говнокоду.
Ждём вопросы на stackoverflow:
"Посоветуйте расклад для оценки покрытия автотестов?"
"Что означает 9 кубков и Горящая башня в контексте проверки контракта API на возможность расширения в будущем?"
"Что можно оставить бесам в откуп на перекрестке, чтобы успешно закрывать задачи без дедлайнов?"