Что может быть общего у разработчика из крупной московской ИТ-компании и пенсионерки из Вологодской области? Ну, например, они оба регулярно пользуются SSO — технологией единого входа. Разработчик входит под одной учеткой во все корпоративные рабочие системы, а пенсионерка авторизуется через «Госуслуги» — чтобы записаться к врачу, проверить пенсию или оплатить коммунальные услуги. Об этом и поговорим, в смысле, об SSO, а не о «Госуслугах».

Привет, Хабр! Я Денис Радостев, старший  backend-разработчик в IBS. В этой статье расскажу о Blitz Identity Provider, российской платформе управления цифровой идентичностью, которая обеспечивает единый вход — SSO, многофакторную аутентификацию и централизованное управление пользователями, и как ее можно интегрировать с приложениями Java по протоколу OAuth 2.0. Покажу ключевые настройки Blitz IDP и моменты, которые важно учитывать на стороне Java-приложения.

А вместо заключения расскажу про наш собственный кейс, связанный с синхронизацией пользователей между Blitz IDP и нашей старой БД для самописной авторизации.

Юнит-тесты в PostgreSQL, как и в других базах данных, не являются обязательными для CI/CD, но они крайне важны и фактически становятся стандартом. С помощью этих юнит-тестов мы уже нашли и исправили много ошибок в функциях на уровне БД, а также сократили загрузку ручных тестировщиков.

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

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

Когда в третий раз за год реализуешь интеграцию ERP с внешней системой и ловишь себя на мысли «мы это уже делали», возникает закономерный вопрос: почему каждый проект на платформе 1С до сих пор начинается почти с нуля? В какой момент все согласились, что интеграции, миграция, нормативно-справочная информация и контроль доступа — это обязательно кастом? Мы решили, что изобретать велосипед каждый раз крайне неэффективно, и попробовали изменить сам подход.

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

Не представляет сложности разработать интеграционный поток и «соединить два API». Настоящая работа начинается там, где в единую экосистему нужно связать десятки разнородных сервисов, каждый со своей логикой, форматом данных и графиком обновлений. В корпоративных средах любая нестабильность интеграции бьет по ключевым процессам, а последствия могут измеряться не только потерянными часами, но и потерянными клиентами. Чтобы enterprise-ландшафт работал как часы, нужны особые подходы к проектированию, устойчивые архитектурные решения и способы сохранять контроль над всей интеграцией на любом ее этапе.

Привет, Хабр! Меня зовут Андрей Чиграй, я архитектор ПО с 10-летним опытом проектирования и разработки корпоративных информационных систем. За это время повидал немало — как лучшие практики в индустрии, так и простые ошибки, грозящие превратиться в полный провал проекта. В этой статье разберу методологию проектирования интеграционных решений от обследования до внедрения, а также поделюсь шаблонами артефактов, которые можно использовать в работе. Надеюсь, информация будет полезна как практикующим системным аналитикам и разработчикам интеграций, так и руководителям интеграционных проектов. Погнали!

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

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

Как правило, разработчики, да и тестировщики не всегда могут заранее предусмотреть, какие именно некорректные входные данные придут в их веб-приложение. Привычные методы тестирования — ручные, интеграционные и даже unit-тесты — хорошо справляются с ожидаемыми сценариями. А вот для проверки непредсказуемых нужны другие подходы.

Привет, Хабр! Меня зовут Алексей Ломай, я младший системный инженер отдела DevOps в IBS. В этой статье расскажу о фаззинге как о мощном инструменте тестирования безопасности веб-приложений. Поговорим об истории и развитии подхода, о доступных инструментах и двух вариантах реализации в CI/CD.

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

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

Первый формат своей диаграммы Генри Л. Гант разработал аж в 1910 году — на бумаге. Сейчас ленточные диаграммы строят в специальных приложениях, сервисах для управления проектами, типа Trello или Jira, конечно же, в Excel, и в том числе в нашем любимом 1C. Об этом и поговорим.

Привет, Хабр! Меня зовут Мирослава Косенко. Я  разработчик 1C в IBS. В этой статье расскажу, как диаграмма Ганта помогает визуально планировать, контролировать и анализировать процессы, будь то производство, проектные задачи или цепочки этапов в учетных подсистемах. Разберемся, что из себя представляет диаграмма и какие проблемы она помогает решать. Посмотрим на реальные примеры использования и обсудим нетиповые кейсы, а также шаг за шагом разберем, как создать и настроить диаграмму Ганта в 1С. Особое внимание уделим нюансам разработки: какие элементы доступны, как они взаимодействуют, какие подводные камни возникают и как их обходить.

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

Почти каждый разработчик рано или поздно задается вопросом: «Я уже Middle или все еще уверенный Junior?» Опыт растет, задач становится больше, стек шире — но вместе с этим появляется и иллюзия, что раз ты пишешь на Java каждый день, значит, язык знаешь. На практике же границы между грейдами проходят не по количеству лет в профессии и не по числу реализованных фич. Они проходят по глубине понимания: платформы, архитектуры, производительности, работы с данными и собственных ограничений.

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

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

Другой значимый фактор — бурное развитие нейросетей. Они уже научились писать типовой код, генерировать тесты, разбирать алгоритмические задачи с LeetCode — по сути, делать то, что раньше поручали джунам, чтобы те набрались опыта. Войти в ИТ все еще возможно, но без продуманной стратегии сделать это стало значительно сложнее.

Привет, Хабр! Меня зовут Борис Жиромский. Я Python-разработчик, AI-инженер и эксперт Учебного центра IBS. В этой статье обсудим, как джуну стартовать в ИТ, когда нейросети кодируют быстрее, да и в целом существенно поменяли рынок. Расскажу про реалии трудоустройства: какие есть ограничения и как их можно обходить, в том числе с помощью самих больших языковых моделей.

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

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

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

Привет, Хабр! Меня зовут Дмитрий Овчаренко, я технический директор департамента разработки IBS для финансового сектора. За последние десять с лишним лет я успел поработать архитектором, тимлидом и техдиром, внедрять SOA, потом микросервисы, потом облака — и наступить на приличное количество грабель. В этой статье честно расскажу несколько таких историй, в которых либо ошибался сам, либо не дожал архитектурно, либо слишком доверился контексту. Без пожаров дата-центров и апокалипсисов, но с теми самыми локальными провалами, которые в реальных системах случаются чаще всего. Надеюсь, эти кейсы окажутся полезными для всех, кто проектирует, особенно в эпоху вайб-кодинга, и потом живет с результатами своих решений.

Каждый год журнал Массачусетского технологического института MIT Technology Review публикует список из десяти технологий, которые, по мнению редакции, определят ближайшее будущее. Это не рейтинг «самых модных» идей и не попытка оседлать хайп, а результат многомесячных обсуждений внутри редакции. Журналисты предлагают варианты, спорят о влиянии, масштабе и последствиях и в итоге оставляют только те технологии, которые действительно могут заметно изменить жизнь и работу людей.

В этом году рейтинг выходит уже в 25-й раз, и сами авторы честно признают: предсказывать будущее сложно и не все прогнозы сбываются. Тем интереснее перечитывать старые списки и смотреть, какие технологии действительно «выстрелили», а какие так и остались экспериментами. Мы уже публиковали подборки MIT Technology Review за 2024 год и за 2025 год, а теперь делимся переводом новой.

Когда система «падает», а времени на вдумчивый разбор логов нет, на помощь может прийти не еще один разработчик, а LLM. Нейросеть показала достойный результат в качестве ассистента при диагностике ошибок 1С.

Привет, Хабр! Меня зовут Евгений Филиппов, я эксперт департамента корпоративных решений IBS. Поговорим о том, как можно использовать ИИ для разбора логов 1С при возникновении некоторых характерных ошибок параллельной работы. 

Одним из самых важных инструментов, который помогает организовать процесс разработки программного обеспечения, является «Спецификация на разработку», или  СНР. Этот документ служит своего рода дорожной картой для всей команды, от аналитиков до разработчиков, и позволяет четко определить требования к продукту. Но что делать, когда на проекте работают десятки аналитиков и каждый пишет спецификацию «в свободной форме»? Ответ прост: использовать шаблоны.

Привет, Хабр! Меня зовут Анатолий Троян, я ведущий разработчик и технический архитектор IBS. В этой статье я хочу поделиться личным опытом применения шаблонов СНР на реальном проекте по разработке 1С-системы: как мы писали спецификации, какие у нас при этом возникали проблемы, почему вообще решили все стандартизировать и как отрабатывали изменения в документе.

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

Привет, Хабр! Меня зовут Елена Маламут, я руководитель проектов в IBS с 2015 года, и за это время мне не раз приходилось принимать проекты на разных стадиях реализации — в том числе и те, что уже столкнулись с трудностями.

Почему руководитель разработки ПО заходит в видеоконференцию и полтора часа наблюдает, как разработчик пишет код? Короткий ответ:  он использует подход гемба — один из лучших способов найти слабые места в процессах.

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

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

Привет, Хабр! Это — Ольга Чужинова и Марина Арпухович, UI/UX-дизайнеры в IBS. Возможно, это профессиональная деформация, но нам кажется, что дизайнерские подходы работают везде: от разработки приложений до проектирования больничных пространств. Ориентироваться на пользователя, работать в команде, тестировать идеи, мыслить системно и действовать последовательно — за этими простыми словами стоит глубокая методология, которая может изменить не только дизайн-процессы, но и саму культуру внутри компании.

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

Привет, Хабр! Меня зовут Михаил Олейник, я разработчик IBS. В этой статье — практический разбор, как устроены фича-флаги, где их хранить, как получать их состояние на фронтенде и что учитывать в реальных проектах. Если вы искали краткий и понятный гайд по теме, это он.