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

Привет, Хабр! Меня зовут Алексей Тарасов, я ведущий аналитик IBS. При написании статьи я ориентировался именно на аналитиков, потому что чаще всего допиливание, валидация и публикация API для конечного потребителя — это наша ответственность. Ниже постарался осветить вариант решения задачи унификации и автоматизации процесса разработки API в крупном банке.

Начиная с 2001 года журнал Массачусетского технологического института MIT Technology Review ежегодно публикует свой список из 10 многообещающих технологий, которые, по мнению редакции, способны определить облик мира на десятилетия вперед. Журналисты рассматривают достижения во всех областях: от нейросетей и компьютерных вычислений до робототехники и реактивного топлива. Мы уже публиковали такой топ-10 на 2024 год, а теперь решили перевести и новый.

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

Также заметим, что MIT Technology Review не всегда был прав (в свое время редакция предвещала грандиозный успех почившему роботу Baxter’у), но журнал нередко раньше других определяет важные области прогресса (технология обработки естественного языка попала в самый первый топ-10 еще 24 года назад). В общем, за предсказаниями MIT интересно следить, так что ловите прогнозы на 2025 год.

Хранение данных и управление глобальным состоянием в React-приложениях всегда было важной темой среди разработчиков. К 2025 году выбор подходящей библиотеки для решения этих задач стал еще более разнообразным — от проверенного Redux до современных, легковесных решений, таких как Zustand и SWR. Каждое из этих решений имеет свои особенности, плюсы и подводные камни, что делает выбор оптимального инструмента порой непростым. В этой статье я рассмотрю 5 самых популярных библиотек на сегодняшний день, проанализирую их основные преимущества, применение на реальных проектах и актуальность в контексте последних трендов разработки.

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

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

Хочу поделиться решением проблемы «duplicate key value violates unique constraint "pg_class_relname_nsp_index"» в PostgreSQL, с которой я столкнулся при добавлении новых секций в секционированные таблицы, с использованием распараллеливания.

Асинхронное программирование — это тема, которая часто вызывает трудности у новичков JS. Неопытные разработчики сталкиваются со множеством вопросов, связанных с обработкой параллельных операций, управлением потоками данных и «адом коллбэков». Тем не менее, понимание и освоение асинхронности является важным шагом на пути к эффективной разработке современных веб-приложений. В этой статье разберем основные инструменты, такие как промисы и async/await, и покажем, как они могут облегчить обработку данных в фоновом режиме и повысить читаемость кода.

Привет, Хабр! Меня зовут Олег Волков, я ведущий frontend-разработчик IBS. В этой статье я хочу поделиться выжимкой из книги Кайла Симпсона «Вы не знаете JS. Асинхронная обработка & оптимизация». Лично мне она открыла глаза. Уверен, что другие JS-специалисты найдут ее не менее полезной!

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

Привет, Хабр! Меня зовут Радик Нургалиев, я руководитель команды .NET-разработчиков IBS. В этой статье расскажу про свой карьерный рост от начинающего программиста до руководителя в компаниях разного масштаба. Понятно, что у каждой ИТ-компании свои представления о прекрасном и свои схемы карьерных треков сотрудников, а значит, не может быть некой единой для всех разработчиков инструкции «Как стать тимлидом за Х лет». Я поделюсь личным опытом. Надеюсь, кому-нибудь он поможет повторить мою траекторию: начинающий программист → разработчик со стажем 1–3 года → опытный разработчик → куратор команды → тимлид.

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

На майской конференции React Conf 2024 команда React не только презентовала версию библиотеки React 19, но и рекомендовала использовать для старта новых JavaScript-проектов один из четырех фреймворков: Next.js, Remix, RedwoodJs или Expo. Позже аналогичная рекомендация появилась в официальной документации по React. Из этих фреймворков Next.js может похвастаться самым большим комьюнити, документацией и удобством. Если вы до сих пор его не освоили, то мы идем к вам!

Привет, Хабр! В этой статье расскажем, что такое Next.js, и покажем вам на примере небольшого pet-проекта его базовые возможности.

На августовском Хабрасеминаре коммерческий директор Хабра Любовь Соболева сказала, что айтишников в стране всего два миллиона человек. Эта статья для тех, кто охотится за лучшими из этих двух миллионов, — для нанимающих менеджеров, рекрутеров и HR, руководителей проектов. 

Привет, Хабр. Меня зовут Константин Синанов, я директор отделения ручного тестирования в IBS. В этой статье мы вместе с нашим рекрутинг-партнером Таисией Бикулич расскажем о том, как выстраивать процесс поиска, отбора и найма кандидатов, чтобы тратить меньше времени и получать меньше отказов.

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

Привет, Хабр! Меня зовут Любовь Кулева, я руководитель отдела разработки и методологии Учебного центра IBS. Каждый год в нашем центре сотни сотрудников проходят сертификацию навыков. Собрав статистику по итогам 2023 года, мы выяснили, что сертификацию успешно сдает лишь каждый третий системный аналитик. Да-да, вы не ослышались: это значит, что две трети специалистов в первый раз заваливают экзамен. Очевидно, что многие просто не замечают пробелов в собственных знаниях или не знают, какие именно компетенции следует подтянуть в первую очередь. Эта статья — дорожная карта для любого системного аналитика, желающего расти в профессии.

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

Привет, Хабр! Меня зовут Анастасия Цацкина, я старший разработчик Отдела разработки баз данных IBS. В продолжение нашей серии статей о переезде с иностранных решений на отечественные, сегодня я хочу поделиться проектным опытом проведения полноценного аудита базы данных аналитической отчетности перед сменой ERP-системы. Расскажу, какая задача стояла, как выглядела архитектура баз данных заказчика, из каких этапов состоял аудит и что в результате всего этого получилось.

Один из разделов большого курса про архитектуру ПО, который я веду, посвящен так называемой методологии 12 факторов. Она была придумана разработчиками американской компании Heroku и, если верить Википедии, впервые описана примерно в 2011 году. На Западе методология быстро завоевала поддержку ИТ-сообщества и стала отраслевым стандартом при разработке веб-приложений по модели SaaS (Software as a Service — программное обеспечение как услуга). В русскоязычной среде об этих фундаментальных принципах говорят редко, так что я решил исправить эту вселенскую несправедливость.

Привет, Хабр! Меня зовут Андрей Бирюков, я преподаватель-практик Учебного центра IBS и архитектор по разработке программного обеспечения. За 15 с лишним лет в ИТ я спроектировал и внедрил десятки инфраструктурных решений на базе ОС Linux, Windows, работал с системами виртуализации и контейнеризации, а также занимался комплексными проектами по защите корпоративных и промышленных сетей. В этой статье я расскажу о методологии, которая помогает разрабатывать более качественные, устойчивые и эффективные веб-приложения.

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

Но при проектировании систем, основанных на облачных сервисах, важно правильно выбрать архитектуру решения. Конечно, никто не мешает самостоятельно придумывать свою архитектуру, но, скорее всего, то, что вы «изобретете», уже кто-то придумал до вас. Так наиболее успешные реализации приложений получили распространение в качестве шаблонов проектирования.

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

В продолжение серии статей об устройстве системы управления базами данных PostgreSQL (раз, два) смотрим, как ускорить выполнение запросов к базе данных с помощью индексов.

Привет, Хабр! Меня зовут Артур Титаев, я аналитик департамента проектирования и разработки IBS. Недавно наша команда занималась масштабным импортозамещением компонентов системы поддержки принятия решений для крупного российского заказчика. После переезда с Oracle и MySQL на PostgreSQL мы определили, что время выполнения SQL-запросов для показателей хозяйственно-экономической деятельности клиента в PostgreSQL заметно больше, чем время выполнения тех же запросов для тех же показателей в Oracle. Для «тяжелых» показателей разница во времени выполнения запроса могла достигать 20–30 минут. И это несмотря на то, что база данных Oracle не была проиндексированной!

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

Как Java-методист с 15-летним опытом я решил проверить, как нейросеть ChatGPT-4 придумывает use cases, создает доменную модель и пишет программный код. Давайте посмотрим, способна ли эта большая языковая модель в ее текущей итерации заменить разработчика или, по крайней мере, упростить процесс разработки.

Привет, Хабр! Меня зовут Игорь Судакевич, я преподаватель-практик Учебного центра IBS по программированию на языке Java. В начале 2024 года мой коллега из IBS уже делился собственным опытом создания базовой программы с помощью ChatGPT. В том эксперименте использовалась бесплатная модель 3.5, и мы получили множество комментариев из серии «А вы бы тоже самое провернули на последней версии модели — она всё делает в разы лучше!» Мол, и разработчики скоро будут никому не нужны.

Всем привет! Меня зовут Никита Королев, я тимлид Flutter‑команды в компании IBS. Уже год я работаю на проекте компании Атом — разработчика российского электромобиля. На данный момент наша команда занимается разработкой приложений для направления Такси.

Мы с командой выработали свой подход к построению архитектуры Flutter‑приложений и хотим поделиться им со всеми, кому будет интересна эта тема.

Смотрим, как вездесущий PostgreSQL справляется с нестандартными для реляционной системы управления базами данных (СУБД) ролями: хранением и поиском временных рядов, пар «ключ — значение», эмбеддингов для больших языковых моделей и многомерных кубов. Отвечаем на вопрос: действительно ли так нужно строить сложные архитектуры со множеством разнородных систем хранения данных — MongoDB, Redis, InfluxDB, Pinecone, ClickHouse, Apache Cassandra — или можно обойтись одним PostgreSQL?

Привет, Хабр! Меня зовут Александр Брейман, я доцент департамента программной инженерии факультета компьютерных наук НИУ ВШЭ и по совместительству эксперт Учебного центра IBS по управлению данными и архитектуре ПО. В прошлой статье я рассказывал о миграции с Oracle на PostgreSQL, а сегодня разберу, как последний работает с нетипичными видами данных.

Эксперты IBS, старший разработчик Арсен Омаров и руководитель региональной группы Галина Носкова, взвешивают за и против механизма расширений 1С и объясняют, в каких случаях их можно и нужно использовать.

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

Привет, Хабр! Меня зовут Александр Брейман, я доцент департамента программной инженерии факультета компьютерных наук НИУ ВШЭ и по совместительству эксперт Учебного центра IBS. В этой статье расскажу, чем PL/SQL похож и чем отличается от PL/pgSQL, на что обратить внимание при переходе и какие инструменты могут вам с этим помочь.

Писатель Дмитрий Глуховский как-то предложил водителю автобуса из Саратова свой вариант карьерного плана в ИТ. Моя карьера сложилась почти по этому плану. Только я учил Java.

Hola, Хабр. Меня зовут Джулио, я ведущий бэкенд-разработчик в IBS. Я родился и вырос в Перу, но уже несколько лет живу и работаю в России.

Я приехал сюда студентом 23 года назад, изучал радиофизику в питерском университете, несколько лет работал техническим переводчиком и менеджером проектов по информационной безопасности, а потом решил «зайти в айти». Работал в ИТ-компаниях в России, Перу и Польше. Меньше чем за 10 лет прошёл путь от джуна до сеньора.

Эта статья о том, как я «зашёл в айти», когда ещё не существовало Скиллбокса и Яндекс Практикума. Расскажу, как учился программированию десять лет назад, чем отличаются собеседования в ИТ-компаниях Перу и России и кому не стоит становиться разработчиком.