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

Впервые прочитав эту цитату Кони Бюрера, который работал в Rational Software, я полагал, что корень всех проблем, возникающих при разработке ПО, кроется именно здесь. С тех пор я повзрослел, оброс шлейфом скепсиса и перестал писать код для продакшена. Я больше не несу ответственности за разработку, тестирование или поставку отдельных классов, компонентов и даже сервисов. Я отвечаю за максимально быструю и качественную поставку бизнес-ценности в рамках одного из ключевых бизнесов ЦФТ - сервиса денежных переводов Золотая корона.

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

В предыдущей заметке было подробно рассмотрено одно из решений для обеспечения повсеместной доступности текущего обрабатываемого HTTP-запроса. В отличие от неё, нынешняя заметка посвящена не одному большому пункту, а двум компактным: поддержке AOP-аспектов и работе OpenFeign-клиентов в «гибридных» приложениях.

В предыдущей заметке было показано несколько подходов к управлению зависимостями в «гибридных» приложениях (использующих части сервлетного и реактивного стеков), а также вариант реализации универсального механизма для поддержки MDC-меток в логах. А в этой заметке речь пойдёт о том, как обеспечить доступность текущего обрабатываемого HTTP-запроса из любой точки бизнес-логики.

Когда рассказывают о прелестях реактивного фреймворка Spring WebFlux и его подкапотном Project Reactor, для примера чаще всего показывают новые, создаваемые с нуля приложения. Однако на практике приходится строить из готовых блоков, в том числе из собственных прикладных и инфраструктурных модулей, которые уже написаны в императивном стиле и опираются на сервлетный стек. Как правило, такие модули нельзя/некогда/неохота (нужное подчеркнуть) переписывать, поэтому надо как-то адаптировать их к создаваемому реактивному приложению с минимумом правок (а лучше без них вовсе). О некоторых подходах к такой задаче и пойдёт речь в этой серии заметок.

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

Но что делать, если новобранцев не один и не пять? Что, если в одно прекрасное утро мы проснулись в новой реальности – реальности, где личный состав удвоился одномоментно? Здесь перестают работать дедовские методы «садись рядом – расскажу» и наступает хаос. О том, как этот хаос подчинить, расскажу в статье.

Три года назад в группе компаний ЦФТ задачи бизнеса потребовали увеличения штата разработчиков в два раза. Перед отделом эксплуатации встало две задачи: не допустить линейного роста OPS и уменьшить TTM, не потеряв при этом в недоступности, непрерывности и безопасности.

В результате в компании теперь есть всё — и NoOps, и DevOps. Где-то пришлось пойти на компромиссы и доработать концепт NoOps напильником под себя. Сергей Бердников, руководитель отдела эксплуатации, сегодня расскажет, что получилось, и разберет — почему.

Привет! Меня зовут Михаил и год назад я стал iOS-разработчиком в компании ЦФТ. До этого почти 8 лет я проработал в сфере логистики и таможенного оформления, а айосером меня можно было назвать разве что из-за наличия iPhone.

Я хочу поделиться своим опытом. Зачем? Меня такие истории мотивировали на старте, и, возможно, именно мой опыт не даст кому-то опустить руки. Моя история не из разряда «как стать джуном за два месяца», а о том, как не соскочить в этом марафоне.

Сегодня почти в каждом проекте существует хотя бы базовая инфраструктура, включающая в себя систему хостинга кода проекта (Github, Bitbucket и др.) и систему его сборки (Teamcity, Jenkins и др.). Мы в ЦФТ активно используем Bitbucket server и Teamcity в наших пайплайнах. Подкатом я расскажу, как мы настроили взаимодействие этих сервисов, с какими трудностями столкнулись и как с ними справились.

Всем привет. Выходим на финишную прямую: сегодня финальная статья о том, какие ответы может дать data science о прогнозировании COVID-19.

Первая статья здесь. Вторая здесь.

Сегодня мы общаемся с Александром Желубенковым о его решениях по предсказанию распространения COVID-19.

Всем привет. Мы продолжаем серию статей о том, какие ответы может дать data science о прогнозировании COVID-19. Первая статья здесь. Сегодня поговорим о втором классе моделей по предсказанию динамики распространения COVID-19. Они основаны на предположениях о росте заболеваемости и описывают ситуацию в средне- и долгосрочной перспективе. Беседуем с Николаем Кобало, старшим инженером данных ЦФТ.

Уже очевидно, что в 2021-м COVID-19 все еще будет оставаться, как говорится, на повестке дня. А значит, закономерно возникают вопросы: есть ли у нас инструменты для прогнозирования роста и снижения заболеваемости, можем ли мы предсказать развитие событий через неделю, месяц или даже год? Давайте разбираться.