Привет, Хабр! На связи Андрей Чернов, Java‑архитектор в СберТехе. В прошлой своей статье я рассказал про особенности работы с секретами в Java‑сервисах на Spring Boot — где их брать и как применять к вашему сервису, на примере того, как мы делаем это в Platform V Sessions Data.

Работа с секретами в современных реалиях, где ни с чем не интегрированных сервисов почти не осталось, очень важна. Она помогает снизить риски утечек и атак, а значит, сохранить деньги, время и репутацию компании. Секретами могу быть, например, сертификаты и учётные данные (имя пользователя, пароль и т. п.).

Как я уже говорил, файлы с секретами по разным причинам меняются, поэтому сервису нужно вовремя реагировать на это и применять новые секреты. В своём сервисе Platform V Sessions Data мы решили применять обновления секретов прямо «на горячую», не останавливая, не перезапуская сервисы, и даже не снимая с них нагрузку. Мы называем это hot reload.

Сегодня я хочу рассказать о метриках. Но не о тех, которые обычно обсуждают, к примеру, на конференциях, где каждый рассказывает о своём продукте. Я буду говорить о командных метриках и о нашей команде Sber Data Exchange.

Но сначала пару слов всё‑таки о продукте, чтобы задать контекст. Наш продукт специфический: это инструмент для обмена данными со Сбером и компаниями экосистемы. Представьте себе трубы, по которым данные движутся туда‑сюда. Вот этим мы и занимаемся.

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

Залог успеха любого программного решения — хорошее покрытие его функциональными тестами. Каждая полностью покрытая функция — минус одна потенциальная ошибка в работе проекта или даже больше. Однако при написании тестов в проекте, насчитывающем тысячи строк кода и множество пакетов (packages), можно столкнуться с различными трудностями.

Я Роман Соловьев, ведущий ИТ‑инженер в отделе RnD и готовых решений управления развития продукта в СберТехе. Сегодня расскажу, с какими проблемами мы столкнулись при написании тестов к проекту на Go, активно использующему Docker‑контейнеры, и как нам удалось их решить.

Эта статья будет полезна тем, кто пишет модульные тесты на Go, особенно для проектов, использующих Docker‑контейнеры. Я постараюсь просто и понятно объяснить официальный code‑style для модульных тестов, а также подсветить подводные камни, с которыми можно столкнуться при их написании.

В наше время, киберспорт стал самой настоящей мейнстримовой культурой, пленив миллионы людей во всём мире. Но что же это такое и что стоит за его стремительным взлётом? Давайте вместе окунёмся в этот крайне увлекательный мир и выясним, почему киберспорт превратился в такое глобальное явление.

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

В этой статье мы поговорим о разработке простого трёхмерного движка для консоли Dendy (NES/Famicom), который позволит выводить полигональные трёхмерные модели и проводить над ними базовые манипуляции (вращение, перемещение, трансформация, заливка полигонов и т. д.). В первом части мы обсудим реализацию вывода двумерных примитивов и организацию памяти в условиях ограничений NES.

Привет всем! Поговорим об эмоциях и о том, как они влияют на процесс нашего познания. Многие из вас наверняка слышали, что эмоции мешают обучаться, здраво мыслить и принимать правильные решения. Так ли верны подобные предостережения? Давайте обратимся к науке и посмотрим на некоторые её достижения в этой области.

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

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

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

Привет, Хабр! Меня зовут Захар Пикуль, я руковожу в СберТехе отделом сопровождения инфраструктуры тестовых сред. Созданием и внедрением ИТ‑решений в компаниях различного размера и уровня я занимаюсь уже более 15 лет.

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

Эта статья — вводная. В ней мы разберём вызовы, с которыми может столкнуться компания в процессе переезда в облако, и возможные способы их решения.

Всем привет! Меня зовут Вова я разработчик СБОЛа в web-канале.

Наверное, каждый фронтенд‑разработчик, по крайней мере на собеседовании, сталкивался с вопросами: «Какие единицы измерения существуют в CSS?» или «Какие единицы измерения ты использовал для CSS?», и т. п. Скорее всего, большинство интервьюеров удовлетворил бы ответ: «Абсолютные и относительные». И в целом, это, по‑своему, правильно. Но зададим себе вопрос: если разделить множество единиц измерения на два подмножества — абсолютные и относительные, — то будут ли внутри этих подмножеств единицы измерения действительно взаимозаменяемыми? Скорее нет, чем да. Тогда по какому признаку мы могли бы их разделить? По функциональному использованию.

Привет всем! Мы подготовили для вас подборку интересных роботов, которые уже меняют или в обозримом будущем изменят нашу с вами повседневную жизнь. Без длинных предисловий перейдём сразу к делу.

Всем привет! Специально для тех, кто хочет освоить эту профессию, мы подготовили обзор основных инструментов, необходимых для создания DevOps-процессов.

Привет, Хабр! Я Михаил Бибик, работаю в СберТехе QA-automation-инженером, пишу автотесты для СУБД Pangolin — это целевая СУБД в Сбере и не только. В прошлом году наша команда искала и нанимала QA-инженеров с различным опытом, в том числе совсем начинающих. Когда я провёл штук 15-20 собеседований, то понял, что могу обобщить некоторые наблюдения и составить простые советы по поводу составления тест-кейсов для начинающих (скорее, очень начинающих) тестировщиков. В этой статье я покажу, как применить теорию тестирования на техническом собеседовании. Для этого разберу реальную задачу с нашего собеседования. Проходите под кат.

Самое главное стоит понимать, что XSD (XML Schema Definition) – это схема, то есть описание данных взаимодействия. Схемы бывают разные, например, наша XSD, которую обычно используют для описания структур в формате XML, или JSON-schema - для описания структур в формате JSON. Использование схем в контрактах API сейчас уже является стандартом де-факто, так как это удобно.

Основные объекты, из которых состоит XSD-схема:
- Элементы;
- Типы;
- Индикаторы порядка.

При разработке веб-приложений не все задумываются о том, сколько памяти потребляет их код. О производительности наших сайтов мы вспоминаем гораздо чаще. К тому же не каждому разработчику интересно «экономить на спичках». Разве может наш код на языке JavaScript требовать много памяти? «Много» — это вообще сколько? 100 мегабайтов — это много?

Меня зовут Антон Непша. Я работаю в Сбере, разрабатываю сайт СберБанк Онлайн и веду Telegram-канал Антон Непша.js. Недавно я выступил на HolyJS с докладом о том, сколько ресурсов потребляют наши сайты, как эти ресурсы распределяются, где хранятся, и как связать информацию о них из снимка памяти с конкретным местом в своём коде.

Если смотреть видео вам удобнее, то доклад есть на YouTube и ВК Видео. В статье вас ждёт текстовый вариант и ссылки на используемые материалы:

Привет, Хабр! Меня зовут Геннадий Круглов, я работаю в команде «Архитектура Банка» в Департаменте корпоративной архитектуры Сбера. 

Когда мы сравниваем «архитектуры», на самом деле чаще всего мы сравниваем архитектурные стили. Как и в строительстве, где, например, мы можем отнести здания к готике, классицизму, барокко или эклектике, мы относим архитектуры программных систем к N-Tier, SOA или, допустим, к микроядерной архитектуре. Мы позаимствовали из строительства идеи архитектуры и архитектурных стилей, поэтому продолжим использовать аналогии из строительной сферы.

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

Мы — команда, которая обеспечивает D‑People (data‑аналитиков, исследователей данных (data scientist) и data‑инженеров) Сбера удобными и функциональными инструментами для работы с данными. Наш департамент развивает внутреннюю корпоративную аналитическую платформу (КАП). В ней есть множество удобных инструментов, и в статье мы расскажем об одном из них — позволяющем работать с данными на естественном языке.

Мир видеоигр прошёл долгий путь с его современной графикой и постоянно развивающимися игровыми механиками. Однако наблюдается возрождение любви к классическим видеоиграм прошлого. Это возрождение ретро-игр захватило индустрию, подпитываемое ностальгией, доступностью и признанием непреходящих качеств, которые сделали эти игры такими любимыми.  

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

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