Когда проект начинается, разработчику хочется только одного — свободы творчества. Писать код быстро и так же быстро получать результат. Но со временем появляются баги, регрессии, архитектура, миграции... И вот тогда свобода оборачивается болью: оказывается, что один и тот же результат в коде можно выразить десятком способов — и все они несовместимы друг с другом.

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

­­­Какие предметы вам нравились в школе? Я очень любила математику.  Меня завораживали цифры, формулы и логические рассуждения. А самое главное, даже если решать задачу несколькими разными способами – единственно верный ответ всегда будет один. И проверив его, можно быть уверенным, что задача решена правильно.

Сейчас, проектируя программные системы, я тоже решаю задачи, но они принципиально отличаются от математических, где всегда есть единственно верное решение. Если в школе небольшого условия задачи было достаточно, при проектировании это не так. Как говорил итальянский программист Альберто Брандолини: «В прод идут не знания экспертов в предметной области, а предположения разработчиков». Поэтому важно не просто полагаться на своё понимание, а проверять предположения на практике.

Для этого необходимо организовать совместное исследование сложной предметной области бизнеса: собрать команду, построить модель процессов и сверить свои гипотезы с реальными знаниями экспертов. По моему опыту, снизить неопределенность в понимании предметной области и проверить предположения на соответствие действительности помогает — Event Storming. Эта техника выявляет и минимизирует влияние ошибочных предположений на качество конечного продукта.

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

Большинство стандартов безопасности описывает лучшие практики настройки управляющих компонентов — control plane. Нечасто встречаются рекомендации по грамотной настройке рабочих единиц — подов. В статье попробуем восполнить этот пробел. Выполним обзор источников, рассмотрим хорошие практики работы с образами. Изучим, как ограничить привилегии контейнера и почему это важно. Поговорим о инструментах автоматической проверки манифестов и разберем примеры GItlab CI пайпланов.

Мы долгие годы писали сервисы исходя из каких-то своих внутренних ощущений правильности их написания. Но синхронизироваться по хорошим практикам в разных командах бывает довольно сложно и часто хорошие практики не выходили за рамки одной команды, а такого хотелось бы избежать. Поэтому мы решили объединить все хорошие по нашему мнению практики в единый справочник. Этот справочник получил название «Архитектурный гайд». Про него и поговорим в данной статье.

Привет, Хабр! Меня зовут Алёна, я senior фронтенд-разработчик отдела разработки ПО для розничного бизнеса в Райффайзенбанке. Недавно передо мной встала задача улучшения пользовательского опыта обработки ошибок запросов к бэкенду. Я решила комплексно исследовать эту тему на примере HTTP-клиента Axios.

Если при отправке запросов с помощью Axios возникает ошибка — клиентское приложение получает аргумент, который может быть экземпляром объекта, производного от системного класса Error, или любым типом. Он может содержать много информации и не всегда понятно, что самое важное для определения типа исключения и способа обработки. Поэтому я выделала 4 категории ошибок запросов, сделанных при помощи Axios, которые нужно по-разному интерпретировать.

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

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

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

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

В этой статье расскажу, как мы объединили несколько разных команд разработки Райффайзен Онлайн общим Observability и с помощью исключительно технических метрик отслеживаем здоровье бизнес-процессов. Как всё это помогает мгновенно находить первопричину сбоя. Как устроен OpenTelemetry и как с его помощью рассчитать доступность приложения в девятках, а также MTTR (Mean Time to Recovery).

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

Привет, Хабр! Я старший системный аналитик Федор Качан. Попробую рассказать, почему эмоциональный интеллект может быть важнее IQ. Зачем соблюдать баланс между IQ и EQ. Что такое эмоциональная шкала и как развить свой эмоциональный интеллект в любом возрасте.

Привет! Меня зовут Максим Черноусов, и я занимаюсь iOS-разработкой в Райфе. Я обожаю использовать и дизайнить классные API. А один из самых часто используемых строительных блоков для хороших API в Swift — это KeyPath'ы. Сегодня о них и поговорим.

Первый открытый митап iOS Community: приглашаем 2 февраля слушать интересные доклады и вовлекаться в дискуссии! Поговорим про Dependency Injection, подход async/await в задачах с многопоточностью и snapshot-тестирование.

Под катом — видео митапа и презентации спикеров :)

В ноябре dgtl-команды Райффайзенбанка рассказали о шести продуктах на открытом демо-дне. Трансляция была в прямом эфире для всех, кому интересно заглянуть под капот банковских сервисов и узнать подробнее о технологиях.

Всем привет! Меня зовут Николай Первухин, я Senior Java Developer в Райффайзенбанке. В последнее время я активно занимаюсь BPM-системами Camunda и Zeebe (основа Camunda-cloud). Если вы, как и я, с ходу не можете ответить на вопрос, кто быстрее — Camunda или Zeebe, насколько, и в каких случаях они могут тормозить, то добро пожаловать под кат.

Всем привет! Меня зовут Аникин Денис, я тимлид в команде Chat в Райффайзенбанке. А также представитель внутреннего Python-сообщества, так называемый «community lead» (об этом как-нибудь в другой раз). В этой статье я хотел поговорить про отношение к Python среди разработчиков и обсудить все основные претензии, которые очень давно следуют за языком по пятам.

Добрый день! Меня зовут Владислав Верминский, я отвечаю за развитие профессии JVM-разработчика в Райффайзенбанке. В этой статье я расскажу про неоднозначность вывода типов в Java. На первый взгляд с ним всё очевидно, но когда сталкиваешься со странным поведением, возникают вопросы — начинает казаться, что какие-то части кода работают неправильно. Однако, после анализа становится понятно, что всё очень непросто, но при этом всё работает по своей спецификации.

Мы снова встретились онлайн на IT-конференции Райффайзенбанка: пять часов нон-стопа хардовых докладов, эксперты из разных технологических компаний, CTF-соревнование для самых скилловых хакеров и ставшие теперь локальными мемы конференции. Обо всем здесь и по порядку.

Если сразу к делу — готовы все записи докладов конференции. И даже бонус: делимся видео воркшопов!

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

Привет, Хабр! Меня зовут Дмитрий Раевский, я дата-сайентист в Райффайзенбанке, занимаюсь цифровизацией кредитов и кредитного контроля. Сегодня я хочу рассказать про оценку коммерческой недвижимости — объектов, которые используются для извлечения прибыли. Поскольку мы на Хабре, то разговор пойдет не об оценке в вакууме, а о привлечении технологий для решения этой задачи. 

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

Привет, меня зовут Улукбек, я фронтенд-разработчик в команде, которая работает над продуктом «Ипотека» в Райффайзенбанке. Под катом я попробую рассказать, как разработчик может не только просто реализовывать задачи, поступающие от бизнеса, но и сам стать генератором идей, помочь компании в повышении эффективности и дать пользователям удобный сервис.

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

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

Всем же интересно про зарплаты? Давайте про зарплаты

Меня зовут Алексей и я работаю в Райффайзенбанке техлидом. Последние 12 лет я нон-стоп нанимаю технических специалистов и меня всегда интересовал зарплатный гэп между айтишниками и не-айтишниками. Судя по дискуссиям в интернете — разница в зарплатах волнует многих. Так получилось, что в качестве хобби я интересуюсь экономикой. Поэтому когда моих знаний стало хватать для понимания причин такого разрыва, то в голове сразу же щелкнули шестеренки, картина мира обрела гармонию и я получил заслуженную порцию дофамина.

Под катом я рассказываю о том, как формируется зарплата (особенно программиста) с точки зрения экономики.