❗Вакансии «Библиотеки программиста»

Привет! Мы ищем контент-менеджеров, которые будут вести наши телеграм-каналы о разработке.

👾 Требования:
— знать принципы залетающего контента
— разбираться в темах, связанных с разработкой

Большим плюсом будет навык программирования на каких-либо языках.

✨ Условия:
— удаленка
— частичная занятость
— сдельная оплата в зависимости от количества задач

🔥 Оставляйте отклик, и мы свяжемся с вами: https://forms.gle/o4BZnsQ526JoqsCq9

😡 А вас тоже бесят облачные сервисы?

Согласитесь, статус отношений с облаками — все сложно. Но что, если можно изменить правила игры?

Мы готовим нечто особенное в мире облачных технологий, но сначала хотим услышать правду от тех, кто реально работает с облаками каждый день.

❓Что мы хотим узнать:
— Для чего вы реально используете облако?
— Чего катастрофически не хватает прямо сейчас?
— Что бесит больше всего? (можно материться)
— Как выбираете провайдера — по цене или по любви?
— и тому подобное

По результатам опроса мы подготовим исследование без маркетингового мусора и вы узнаете, как обстоят дела у коллег.

⚡️Время на опрос: меньше, чем на кофе-брейк. Жмите → https://clc.to/nboYDA

Каким образом мы можем улучшить стабильность работы приложения в k8s?

Прежде всего необходимо описать probe для контейнеров в PODе, а также указать ресурсы запросов / лимиты. Затем целесообразно описать антиаффинити для PODов наших приложений, чтобы упростить обработку сбоев на конкретных узлах.

Если в нашем кластере работают как продуктовые, так и тестовые среды, хорошей практикой будет указать node selector и taints/tolerations, чтобы запускать продуктовые приложения на отдельных узлах.

Если нет возможности выделить узлы под продакшн или мы можем выделить особо важные (ядреные) сервисы в рамках продакшн, рекомендуется установить priority classes для них. Также стоит описать бюджет нарушения работы POD для особо важных приложений. В случае использования многопользовательской модели (multitenant) в пространствах имен пользователей следует указывать resourceQuotas и limitRanges.

😱 Завтра цена на курс «AI-агенты для DS» вырастет

Пока вы думаете — другие уже покупают. Что вы теряете, откладывая решение? Как минимум — 10 000 рублей, именно столько вы переплатите завтра. Как максимум — шанс войти в топ-1% дата-сайентистов, которые умеют строить AI-агенты.

🎓 Чему вы научитесь на курсе:
— адаптировать LLM под разные предметные области и данные
— собирать свою RAG-систему: от ретривера и реранкера до генератора и оценки качества
— строить AI-агентов с нуля — на основе сценариев, функций и взаимодействия с внешней средой

Решение за вами.

👉 Купить курс по старой цене

Как разработать самовосстанавливающуюся распределенную службу?

Любая система, которая должна быть способна к самовосстановлению, должна в определенной степени иметь возможность обрабатывать ошибки и разделения (т. е. когда часть системы не может получить доступ к остальной части системы).

Для баз данных обычным способом решения проблемы толерантности к разделам является использование кворума для записи. Это значит, что каждый раз, когда что-то записывается, минимальное количество узлов должно подтвердить запись.

Минимальное количество узлов, необходимое для корректного восстановления после отказа одного узла, составляет три узла. Таким образом, два исправных узла смогут подтвердить состояние системы.

Для облачных приложений эти три узла обычно распределяются по трем зонам доступности.