Сбербанк

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-тесты. Чтобы узнать, как мы улучшаем стабильность тестовых прогонов, добро пожаловать под кат.

В этом году начал обучение первый поток нашей «Школы 21», созданной Сбербанком по модели известной французской L’Ecole 42. Нет учителей и учебного расписания, есть лишь поток проектов, дедлайны и удобные рабочие места. Обучение в «Школе 21» бесплатное для всех независимо от гражданства. Этот пост посвящен историям студентов первого потока, которые расскажут, как отважились на эту авантюру и что она представляет собой изнутри.

В этом посте я хочу поделиться обзором 15 докладов с конференции Heisenbug, рассказать, что интересного было на стендах у компаний, а также поделиться видеоматериалом из доклада Артема Ерошенко о создании actions плагинов для IntelliJ IDEA, которые помогут быстро изменять код тестового проекта.

Привет, Хабр! Меня зовут Павел Липский. Я инженер, работаю в компании Сбербанк-Технологии. Моя специализация — тестирование отказоустойчивости и производительности бэкендов крупных распределенных систем. Попросту говоря, я ломаю чужие программы. В этом посте я расскажу о fault injection — методе тестирования, который позволяет находить проблемы в системе путем создания искусственных сбоев. Начну с того, как я пришел к этому методу, потом поговорим о самом методе и о том, как мы его используем.

Привет Хабр!


Приглашаем на митап по DevOps. На этот раз мы решили уйти от традиционного формата митапа в лектории и собираемся в баре на Невском. Собственно, это и митапом назвать сложно – скорее, это DevOps-вечеринка, где гости смогут не только послушать спикеров, но и проверить свои знания на квизе, повеселиться в фотозоне и в принципе хорошо провести пятничный вечер в конце 2018 года.
Доклады тоже будут интересными. Под катом о программе и спикерах.