Это не микросервисы, это распределенный монолит. Если shortener нужны данные по статистике для работы, то они и должны хранится/обрабатываться в нем же. Но вообще вся затея с топом кеша не имеет смысла и скорее всего вредит. Например, был супер популярный ресурс, который за 2 дня насобирал миллионы просмотров, но потом стал не актуален. Зачем нам хранить ссылку на этот ресурс постоянно?
Хотелось бы какие-то цифры увидеть, а не просто "весьма прилично". Это крайне субъективная оценка и в исследованиях как раз показательно, что субъективное сокращение времени выполнения задач при использовании LLM легко превращается в объективное увеличение.
Хайп LLM проходит и лично у меня до сих пор вопрос в их возможности быть полезными на реальных проектах с большой кодовой базой. Тут на хабре была статья про исследования, что они могут даже замедлять работу инженеров.
Вы вначале статьи пишете про автоскейлер, а потом в ручном режиме конфигурируете порты. Я мог упустить какой-то момент в статье, но как это автоматизируется по итогу?
Этот вопрос максимум джуниор знает, потому что он это изучал на прошлой неделе. Синьор это изучал 5 лет назад и в реальной жизни не использует. Максимум он специально для собеседования повторил.
Я бы насторожился, если бы сеньор забыл что такое "передача по значению" и как устроены слайсы. Достаточно знать устройство языка на котором пишешь, чтобы отвечать на такие вопросы, не обязательно все запоминать
Есть аналитические языки, в которых важен порядок слов (английский, например), а есть синтетические (русский язык). И переключение между ними - это не просто вспомнить нужное слово, но и составить порядок слов. Это чем-то схоже с программированием, где тоже есть жесткие правила о том в каком порядке должны идти ключевые слова. Разница лишь в том что мы выражаем.
Рядовой программист уже давно не использует "машинный" язык. Все скрыто за очень толстым слоем абстракции и размышления идут на уровне "мне надо отправить запрос, отфильтровать по такому-то полю, сохранить его в БД" и выражается это на языке очень похожим на английский.
В том то и дело, что они используют два естественных языка, но подвержены такой же проблеме, но вы почему-то не рассматриваете вариант, что причины и у тех и других - общие, а выделяете программистов в отдельную категорию и пытаетесь как-то объяснить это поведение, основываясь на известных вам фактах о программистах. Факты, кстати, тоже сами по себе спорные.
Я перешел на новую работу с оплатой х2 и в момент оффера стал х2 профессионалом. Потом меня сократили через один год и я больше не профессионал. Логика - мое почтение.
> Профессиона́л — человек, сделавший определённое занятие (дело) своей профессией; человек, ставший в какой-либо области деятельности высококлассным специалистом; хорошо подготовленный для работы в определённой сфере специалист, имеющий навыки, квалификацию, а при необходимости и допуск к выполнению обязанностей по своей специальности.
Здесь ничего нет про оплату труда
> Профессионалы обычно зарабатывают деньги используя свои навыки и умения, их деятельность является их профессией
Упоминается, что они "обычно" зарабатывают деньги используя навыки и умения, это не значит что "исключительно". Даже не говорится, что они обязаны зарабатывать.
Профессионализм - это про навыки и квалификацию, деньги только очень косвенно позволяют судить о ней. Подмена одно на другое у Назарова это просто попытка преодолеть синдром самозванца (а в случае его учеников - это не синдром), сказав что "Смотрите у меня зарплата больше чем у других, значит я профессионал". На самом деле нет, не значит.
Назаров интересный персонаж, смотрел пару его "выступлений". После тейка, что единственное мерило профессионализма - это зарплата, больше его видео не открывал. Хотя дебаты с Подольским были забавными, да
Как бы мы не меняли все вокруг кодовой базы, куча людей которые пушат в одну ветку (мастер) мешают друг другу. И не дай бог кто-то где-то накосячил (а когда у тебя такое количество инженеров это неизбежно и происходит регулярно), то все сидят и ждут стабилизации ветки, чтобы начать доносить фичи до пользователя и по итогу бизнес страдает, т.к. TTM растет. Если нет таких проблем - микросервисы ничего не дадут и добавят боли, но есть примеры их удачного применения там где они реально нужны, поэтому противоставлять одно другому не имеет смысла.
Тут скорее под "распределенным монолитом" имеется в виду микросервисная архитектура, которая на первый взгляд только такой выглядит, но из-за связности между сервисами по сути является монолитом. У меня в практике был пример, когда мне надо было написать сервис на буквально 5-6 эндпоинтов, но просто чтобы этот сервис запустить мне надо было в docker compose завернуть еще сервиса 3-4, просто чтобы они накатили нужные миграции. Это был ад. А еще был момент, когда над монолитом работали 800+ разработчиков и деплой был раз в 45 минут, что привело к тому что от момента аппрува на ревью до попадания кода в мастер проходило несколько дней при активном мониторинге со стороны разработчика. Это тоже было то еще мероприятие.
Сами бы стали таким пользоваться?))
А в чем нужна гибкость в вопросе хранения ссылок в кеше?
LFU на уровне valkey не приведут к тому же самому?
Это не микросервисы, это распределенный монолит. Если shortener нужны данные по статистике для работы, то они и должны хранится/обрабатываться в нем же.
Но вообще вся затея с топом кеша не имеет смысла и скорее всего вредит. Например, был супер популярный ресурс, который за 2 дня насобирал миллионы просмотров, но потом стал не актуален. Зачем нам хранить ссылку на этот ресурс постоянно?
Я верно понял что оценка эффективности LLM проводилась самой LLM?
Хотелось бы какие-то цифры увидеть, а не просто "весьма прилично". Это крайне субъективная оценка и в исследованиях как раз показательно, что субъективное сокращение времени выполнения задач при использовании LLM легко превращается в объективное увеличение.
Хайп LLM проходит и лично у меня до сих пор вопрос в их возможности быть полезными на реальных проектах с большой кодовой базой. Тут на хабре была статья про исследования, что они могут даже замедлять работу инженеров.
Одновременных threads
А как вы узнаете что в него кто-то еще пишет?
И еще ничего не сказано о
errgroupВы вначале статьи пишете про автоскейлер, а потом в ручном режиме конфигурируете порты. Я мог упустить какой-то момент в статье, но как это автоматизируется по итогу?
Я бы насторожился, если бы сеньор забыл что такое "передача по значению" и как устроены слайсы. Достаточно знать устройство языка на котором пишешь, чтобы отвечать на такие вопросы, не обязательно все запоминать
Я не до конца согласен с этим утверждением.
Есть аналитические языки, в которых важен порядок слов (английский, например), а есть синтетические (русский язык). И переключение между ними - это не просто вспомнить нужное слово, но и составить порядок слов. Это чем-то схоже с программированием, где тоже есть жесткие правила о том в каком порядке должны идти ключевые слова. Разница лишь в том что мы выражаем.
Рядовой программист уже давно не использует "машинный" язык. Все скрыто за очень толстым слоем абстракции и размышления идут на уровне "мне надо отправить запрос, отфильтровать по такому-то полю, сохранить его в БД" и выражается это на языке очень похожим на английский.
В том то и дело, что они используют два естественных языка, но подвержены такой же проблеме, но вы почему-то не рассматриваете вариант, что причины и у тех и других - общие, а выделяете программистов в отдельную категорию и пытаетесь как-то объяснить это поведение, основываясь на известных вам фактах о программистах. Факты, кстати, тоже сами по себе спорные.
А в чем уникальное отличие программистов от билингвов в этом случае?
Я перешел на новую работу с оплатой х2 и в момент оффера стал х2 профессионалом. Потом меня сократили через один год и я больше не профессионал.
Логика - мое почтение.
Шикарно, я как раз ее и использовал
> Профессиона́л — человек, сделавший определённое занятие (дело) своей профессией; человек, ставший в какой-либо области деятельности высококлассным специалистом; хорошо подготовленный для работы в определённой сфере специалист, имеющий навыки, квалификацию, а при необходимости и допуск к выполнению обязанностей по своей специальности.
Здесь ничего нет про оплату труда
> Профессионалы обычно зарабатывают деньги используя свои навыки и умения, их деятельность является их профессией
Упоминается, что они "обычно" зарабатывают деньги используя навыки и умения, это не значит что "исключительно". Даже не говорится, что они обязаны зарабатывать.
Профессионализм - это про навыки и квалификацию, деньги только очень косвенно позволяют судить о ней. Подмена одно на другое у Назарова это просто попытка преодолеть синдром самозванца (а в случае его учеников - это не синдром), сказав что "Смотрите у меня зарплата больше чем у других, значит я профессионал". На самом деле нет, не значит.
Можно тогда ссылку на определение?
Я верно понимаю, что специалист который занимается своей профессиональной деятельностью на безвозмездных началах перестает быть профессионалом?
Назаров интересный персонаж, смотрел пару его "выступлений". После тейка, что единственное мерило профессионализма - это зарплата, больше его видео не открывал. Хотя дебаты с Подольским были забавными, да
Как бы мы не меняли все вокруг кодовой базы, куча людей которые пушат в одну ветку (мастер) мешают друг другу. И не дай бог кто-то где-то накосячил (а когда у тебя такое количество инженеров это неизбежно и происходит регулярно), то все сидят и ждут стабилизации ветки, чтобы начать доносить фичи до пользователя и по итогу бизнес страдает, т.к. TTM растет.
Если нет таких проблем - микросервисы ничего не дадут и добавят боли, но есть примеры их удачного применения там где они реально нужны, поэтому противоставлять одно другому не имеет смысла.
Тут скорее под "распределенным монолитом" имеется в виду микросервисная архитектура, которая на первый взгляд только такой выглядит, но из-за связности между сервисами по сути является монолитом.
У меня в практике был пример, когда мне надо было написать сервис на буквально 5-6 эндпоинтов, но просто чтобы этот сервис запустить мне надо было в docker compose завернуть еще сервиса 3-4, просто чтобы они накатили нужные миграции. Это был ад.
А еще был момент, когда над монолитом работали 800+ разработчиков и деплой был раз в 45 минут, что привело к тому что от момента аппрува на ревью до попадания кода в мастер проходило несколько дней при активном мониторинге со стороны разработчика. Это тоже было то еще мероприятие.