Сбербанк

Привет, Хабр!

Приглашаем инженеров и архитекторов на митап, посвященный процессам совместной Open Source разработки. В центре внимания проекты наших друзей, относящиеся к экосистеме Apache Software Foundation.

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

Привет, Хабр! Меня зовут Сергей Лежнин, я старший архитектор в Сбертехе. Одно из направлений моей работы — Единая Фронтальная Система. В этой системе есть сервис управления параметрами конфигураций. Его использует множество пользователей, сервисов и приложений, что требует высокой производительности. В этом посте я расскажу, как этот сервис эволюционировал от первой, самой простой, до своей текущей версии и зачем мы в итоге развернули всю архитектуру на 180 градусов.

14 декабря на митапе в Санкт-Петербурге я (Артем Соковец) совместно с коллегой, Дмитрием Маркеловым, рассказывал о текущей инфраструктуре для автотестов в СберТехе. Пересказ нашего выступления — в этом посте.

В предыдущем посте мы рассказали, как облачные сервисы превратились в негласный стандарт предоставления ИТ-услуг. Нетрудно догадаться, что компании, которые желают по-прежнему зарабатывать на пользовательских приложениях, должны адаптировать и создавать новые продукты с учетом Cloud-Native подхода. Впрочем, для разработчиков это однозначно позитивная новость, поскольку использование облачных технологий открывает для них огромные новые возможности. Главное уметь ими правильно распорядиться.

26-27 января в Москве состоится хакатон для студентов со знаниями Java c призовым фондом 275 000р. Принять участие может джавист любого уровня!

Каждые несколько лет на ИТ-рынке появляется новая технология или парадигма, которая радикально меняет бизнес-модели большинства компаний.

Например, еще 25 лет назад этой парадигмой стал массовый бум ПК, бенефициаром которого стала компания Microsoft. 15 лет назад – массовое распространение широкополосного Интернета, превратившее Google и «Яндекс» в компании с миллиардными оборотами. 10 лет назад – взрыв интереса к мобильной разработке и начало звездной эры Apple. Сейчас, пожалуй, в самом разгаре эра облаков. Под катом рассказываем, как и почему эта эра наступила.

С проблемой flaky-тестов сталкиваются многие проекты, и тема эта уже не раз поднималась на Хабре. Тесты, не определившиеся со своим состоянием, постоянно отнимают не только машинное время, но и время разработчиков и тестировщиков. И если в коммерческой компании можно выделить некий ресурс для решения этой проблемы и назначить ответственных лиц, то в opensource-сообществе все не так просто. Особенно когда речь идет о крупных проектах — например, таких как Apache Ignite, где насчитывается почти 60 тысяч различных тестов.

 

В этом посте мы, собственно, и расскажем, как решали эту проблему в Apache Ignite. Мы — это Дмитрий Павлов, lead software engineer/community manager в GridGain, и Николай Кулагин, IT-инженер Сбербанк-Технологий.

Привет! Меня зовут Андрей Неведомский и я главный инженер в СберТехе. Я работаю в команде, которая занимается разработкой одного из системных сервисов ЕФС (Единой Фронтальной Системы). В своей работе мы активно используем Spring Framework, в частности его DI, и время от времени сталкиваемся с тем, что резолвинг зависимостей в спринге оказывается недостаточно «умным» для нас. Эта статья – результат моих попыток сделать его умнее и в целом разобраться с тем, как он работает. Надеюсь, и вы сможете узнать из неё что-то новое об устройстве спринга.

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

Ситуация такова: предположим, разработчикам удалось убедить себя и бизнес в необходимости покрытия кодовой базы тестами. Со временем в проекте стало более десятка тысяч unit- и более тысячи UI-тестов. Такая большая тестовая база породила несколько проблем, о решении которых мы хотим рассказать.

В первой части статьи мы ознакомимся с трудностями, возникающими при работе с чистыми (не интеграционными) unit-тестами, во второй части будут рассмотрены UI-тесты. Чтобы узнать, как мы улучшаем стабильность тестовых прогонов, добро пожаловать под кат.