Стремясь к повышению производительности базы данных, вы можете столкнуться с ситуацией, когда оптимизации и настройки уже недостаточно. Если вы не можете заменить движок БД, а для настройки параметры рабочей нагрузки больше нет возможностей — базу данных придется масштабировать. Делать это руками долго и нецелесообразно, но и у автоматизации процессов масштабирования есть свои подводные камни.

Это перевод статьи Дмитрия Костика и Миколы Моржан из Percona. С их помощью посмотрим, в какой степени можно автоматизировать горизонтальное масштабирование баз данных MongoDB, MySQL и PostgreSQL в Kubernetes и как это сделать?

В каждой профессии есть книги из категории «маст хэв» — те, которые любой уважающий себя специалист должен обязательно прочитать в целях самообразования. Какая полезная книга помогла бы углубить профессиональные знания тестировщика? Представляем обзор изданий, которые наверняка займут достойное место в библиотеке.

Сейчас организации, выполняющие требования регуляторов и законодательства по информационной безопасности, размышляют над вопросом, чем заменить зарубежные операционные системы, действия сертификатов которых было досрочно прекращено, чтобы обеспечить соответствие мерам защиты информации.

В этой статье в блоге ЛАНИТ я пытаюсь частично ответить на данный вопрос для тех, кто готов будет изменить и, возможно, перестроить свою информационную инфраструктуру. Пост поможет ИБ-специалистам определиться с заменой операционных систем и значительно сэкономит их время по поиску нужной информации.

Эта статья является переводом материала «When to Mock».

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

Ни одна из этих практик не является достаточно хорошей. В этой статье Владимир Хориков покажет, какие зависимости следует мокать, а какие использовать как есть в тестах.

По мотивам своих собеседований, а также собеседований коллег и mentee, составил список вопросов от тимлида к компании, что стоит прояснить на собеседовании — что спросить собеседующего.

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

Каковы финансовые показатели компании?

Является ли компания прибыльной или тратит деньги инвесторов? Или даже до инвесторов ещё не дошло, и основатели пока платят из своего кармана? Как выглядит бизнесовый план развития?

Если компания имеет представительство в РФ, официальное ли (по ТК РФ) трудоустройство и полностью ли "белая" зарплата?

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

Расскажите про ваше понимание «хорошего тимлида»

У собеседника должно быть четкое и непротиворечивое понимание, что он вкладывает в понятие «тимлид» и какие критерии используются для оценки работы тимлида.

Возможно, это понимание даже прописано в должностных инструкциях.

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

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

В этом посте я попробовал собрать историю архитектуры Учи.ру. В нем нет фрагментов кода и исчерпывающих технических подробностей. О нашем опыте выделения микросервисов для решения некоторых задач образовательной платформы — в следующих публикациях.

При работе с базами данных (БД) в установщике, про который мы уже писали в прошлой статье Пишем установщик на WixSharp. Плюшки, проблемы, возможности, в первую очередь были реализованы проверка доступности СУБД по логину/паролю, добавление и обновление собственно БД (в нашем приложении их несколько) накатыванием миграций, также добавление пользователей. Все это реализовано для двух СУБД Microsoft SqlServer и PostgreSql.
На первый взгляд этого достаточно, но иногда есть необходимость удалять БД и пользователей, а это влечет за собой создание резервных копий. Сразу выявили две необходимые задачи:

1. Удаление БД и пользователей при откате приложения в случае ошибки  при первичной установке. При установке приложения, если возникает ошибка происходил откат всех настроек, кроме БД. Добавленные БД и пользователи оставались. И если при боевой эксплуатации после серии тестирования эта ситуация непредвиденной ошибки маловероятна, то в процессе разработки и доработки установщика ошибки возникают часто. Их однозначно нужно удалять

2. Создание резервных копий (бэкапов) и удаление БД ипользователей при полном удалении приложения установщиком. Правильно ли оставлять БД после полного удаления приложения? Мы решили, что нет. Но бэкапы, конечно, сохранять нужно.

Из второго пункта возникла новая задача:

3. Создание бэкапов БД при обновлении приложения. Если мы сохраняем бэкапы при удалении, неплохо создавать их перед обновлением, накатыванием миграций и прочими изменениями. Подстраховка еще никому не мешала.