Мы уже рассказывали, как помогли одной производственной компании трансформировать процессы корпоративного обучения и развития персонала. Сотрудники заказчика, которые тонули в бумажных документах и Excel-таблицах, получили удобное iPad-приложение и веб-портал. Одна из самых важных функций этого продукта – создание динамических отчетов, по которым руководители судят о работе сотрудников «в поле». Это огромные документы с десятками полей и средними размерами в 3000*1600 пикселей.

В этой статье мы поговорим о том, как развернуть эту красоту на базе Microsoft SQL Server Reporting Services, почему такой бэкенд может плохо дружить с веб-порталом и какие хитрости помогут наладить их отношения. Вся бизнес-часть решения уже описана в предыдущей статье, поэтому здесь мы сосредоточимся на технических вопросах. Начнем!

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

В случае разработки под платформу iOS, да и в целом, экосистему Apple, есть два варианта подключать библиотеки в качестве зависимостей:

1. Собирать их каждый раз при сборке приложения.
2. Собирать их заранее, используя уже собранные зависимости.

При выборе второго подхода становится логичным использовать CI/CD системы для сборки библиотек в готовые к употреблению артефакты.

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

На этом фоне, было сложно не заметить и крайне интересно изучить, одно из нововведений от Apple, представленное на WWDC 2019 в рамках презентации Binary Frameworks in Swift — формат упаковки фреймворков — XCFramework.

XCFramework имеет несколько преимуществ, в сравнении с устоявшимися подходами:

1. Упаковка зависимостей под все целевые платформы и архитектуры в единый bundle из коробки.
2. Подключение bundle в формате XCFramework, как единой зависимости для всех целевых платформ и архитектур.
3. Отсутствие необходимости в сборке fat/universal фреймворка.
4. Нет необходимости избавляться от x86_64 слайсов (slice) перед загрузкой конечных приложений в AppStore.

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

Я тимлид и моя задача — обеспечить продуктивную работу команды. Это непросто, поскольку готового рецепта успеха не существует. Конечно, есть признанные методологии: Agile, Lean, Value Stream Mapping. Они дают общие ориентиры и ценности, что уже неплохо, но это лишь ориентиры. А с конкретными решениями, будь добр, вертись сам. На то ты и тимлид.

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

Наш продукт разрабатывается на платформе .Net Core 2.2 с использованием WCF 4.5 для взаимодействия с SOAP сервисом клиента. В процессе работы сервиса разработчики шины данных заметили высокую нагрузку на сервер. Далее стали появляться проблемы с доступом к сервису. В результате выяснили, что причина кроется в количестве активных соединений.

Существует такая проблема как connection exhaustion. Она может возникать из-за нехватки доступных портов при установлении соединения или ограничения на количество соединений с внешним или внутренним сервисом. Есть два варианта решения:

• Увеличение доступных ресурсов,
• Уменьшение количества соединений.

Первый вариант нам недоступен, так как увеличение ресурсов может производится только на стороне сервис-провайдера. Поэтому решили искать варианты оптимизации количества соединений. В этой статье расскажем о найденном решении.

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

Наш клиент — это федеральная компания-производитель. Её мерчендайзеры отвечают за наличие товаров в магазинах, представленность на полках, POSM материалы (реклама), знания продавца о продукции и др. Супервайзеры занимаются обучением, оценкой и контролем полевых сотрудников. Для этого есть корпоративные стандарты и четко регламентированный процесс.

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



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

У нас есть проект с настроенным CI/CD-процессом. Когда разработчик заканчивает задачу и вливает свои изменения в develop\qa, автоматически запускается билд, который выкладывает новую версию приложения на тестовую среду. В идеальном мире тестировщик автоматически узнаёт о задачах, которые были завершены, и на каком окружении они развёрнуты. В таком случае поток работ становится непрерывным, бесперебойным и требует меньше коммуникаций, отвлекающих от сосредоточенной работы. На практике всё не столь радужно.

И вот однажды утром тимлид спросил меня: «А можешь сделать такую штуку для TFS, чтобы таскам, которые прикреплены к билду, после прохождения этого билда навешивался указанный тэг?»

Я решил реализовать для задачи свой build\release task. Тем более что исходники всех build task’ов лежат на github, и вся информация доступна.

Наш таск помечает цветом задачу, которая завершена, но не протестирована. Благодаря этому, разработчик сразу заметит, если забыл поставить нужный тег, а QA сразу увидит, что нужно проверить. Это визуализирует статус задач и ускоряет работу над проектом.

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

Для особо нетерпеливых: github и готовый extension на marketplace.

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



Мы начали разрабатывать мобильное приложение для агентов, которые занимаются выездным оформлением страховых полисов. Они заполняют в приложении большие формы с данными клиентов: информация об автомобиле, собственниках, водителях и т.п. Хотя каждая форма имеет свои секции, ячейки и структуру, а каждый пункт анкеты требует уникального типа данных (строка, дата, вложенный документ), экранные формы были достаточно похожи. Но главное – это их количество… Никто не захочет заниматься повторением визуализации и обработки однотипных элементов помногу раз.

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

В конце июня в Москве прошла крупная конференция о дизайне Mail.ru Design Conf × Dribbble Meetup 2019. Записи с трансляции уже в сети, поэтому мы выбрали самые интересные доклады, чтобы вам было удобно ориентироваться. Расскажем о них подробнее в статье.

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

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

В этой статье расскажем, как мы настроили выборочное логирование трафика для сервисов SOAP.

Мы в True Engineering настроили процесс непрерывной доставки обновлений на сервера заказчика и хотим поделиться этим опытом.

Для начала мы разработали онлайн систему для заказчика и развернули её в собственном кластере Kubernetes. Теперь наше высоконагруженное решение переехало на платформу заказчика, для чего мы настроили полностью автоматический процесс Continuous Deployment. Благодаря этому, мы ускорили time-to-market – доставку изменений в продуктовую среду.

В этой статье мы расскажем обо всех этапах процесса Continuous Deployment (CD) или доставки обновлений на платформу заказчика:

1. как стартует этот процесс,
2. синхронизация с Git-репозиторием заказчика,
3. сборка бекенда и фронтенда,
4. автоматическое развертывание приложения в тестовой среде,
5. автоматическое развертывание на Prod.

В процессе поделимся деталями настройки.

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

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

Некоторые компании, в том числе наш заказчик, развивают продукт через партнерскую сеть. Например, крупные интернет-магазины интегрированы со службой доставки — вы заказываете товар и вскоре получаете трекинговый номер посылки. Другой пример — вместе с авиабилетом вы покупаете страховку или билет на аэроэкспресс.

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

Дано: экосистема и API-портал с интерфейсом, где пользователи зарегистрированы, получают информацию и т.п. Нам нужно сделать удобный и надежный API Gateway. В процессе нам нужно было обеспечить

• регистрацию,
• контроль подключения к API,
• мониторинг того, как пользователи используют конечную систему,
• учёт бизнес-показателей.

В статье мы расскажем о нашем опыте создания API Gateway, в ходе которого мы решали следующие задачи:

• аутентификация пользователя,
• авторизация пользователя,
• модификация исходного запроса,
• проксирование запроса,
• постобработка ответа.

У нас в True Engineering на одном проекте назрела необходимость в смене версии PostgreSQL с 9.6 на 11.1.

Зачем? База данных на проекте уже объемом 1,5 Tb и растет. Перформанс – одно из основных требований к системе. А сама структура данных эволюционирует: добавляются новые колонки, меняются существующие. Новая версия Postgres научилась эффективно работать с добавлением новых колонок с дефолтным значением, так что не нужно городить кастомных костылей на уровне приложения. Ещё в новой версии добавили несколько новых способов партиционирования таблиц, что тоже крайне полезно в условиях большого объема данных.

Итак, решено, мигрируем. Конечно, можно поднять параллельно со старой новую версию сервера PostgreSQL, остановить приложение, через dump/restore (или pg_upgrade) переместить базу и снова запустить приложение. Нам это решение не подошло из-за большого размера базы, к тому же, приложение работает в боевом режиме, и на даунтайм есть считанные минуты.

Поэтому мы решили попробовать миграцию с помощью логической репликации в PostgreSQL с использованием стороннего плагина под названием pglogical.

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



TL;DR

• Всё получилось (не без костылей, о них и статья).
• Мигрировать можно в рамках PostgreSQL версии от 9.4 до 11.x, с любой версии на любую, вниз или вверх.
• Даунтайм равен времени, которое требуется вашему приложению, чтобы переподключиться к новому серверу БД (в нашем случае это был перезапуск всего приложения, но в дикой природе, очевидно, «возможны варианты»).

От переводчика:
Начало года — отличное время, чтобы вдумчиво оценить прошедший год. Окинуть широким взглядом происходящее и понять, как сделать 2019 год лучше, спокойнее и продуктивнее. В этом деле нам показалась полезной статья How To Slow Down to Go Faster Than Ever in Software Development, которую написал Lemi Orhan Ergin. А ее перевод мы публикуем ниже.

В рамках недавно прошедшей конференции DotNext 2018 состоялся BoF по Domain Driven Design. На нем был затронут вопрос работы с исключениями, который вызвал жаркий спор, но не получил развернутой дискуссии, поскольку не являлся основной темой.

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

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

Есть разные мнения о том, стоит ли создавать собственные типы исключений или использовать стандартные, поставляемые в .NET.

Кто-то делает валидацию на исключениях, а кто-то повсеместно использует монаду Result. Справедливо, что Result позволяет по сигнатуре метода понять, возможно ли не только успешное выполнение. Но не менее справедливо, что в императивных языках (к которым относится C#) повсеместное использование Result приводит к плохо читаемому коду, засыпанному конструкциями языка настолько, что с трудом можно разглядеть исходный сценарий.

В данной статье я расскажу о практиках, принятых в нашей команде (если кратко — мы используем все подходы и ни один из них не является догмой).

Речь пойдет об enterprise-приложении, построенном на базе ASP.NET MVC+WebAPI. Приложение построено по луковой архитектуре, общается с базой данных и брокером сообщений. Используется структурированное логирование в ELK-стек и настроен мониторинг при помощи Grafana.

Привет, хабровчане!

Мы вернулись с конференции для .NET-разработчиков DotNext и честно делимся впечатлениями про самые запомнившиеся доклады. Надеемся, наш отзыв пригодится тем, кто будет смотреть видеозаписи выступлений.

На сайте конференции опубликована часть презентаций, так что мы дополнили некоторые отзывы ссылками на них.

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

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

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

Привет, хабровчане! В этом посте хотим поделиться своими впечатлениями от конференции для Java-разработчиков Joker 2018, что из услышанного нам запомнилось больше всего.

Надеемся, это поможет вам сориентироваться в видеозаписях с конференции, когда они появятся в открытом доступе. А пока мы добавили ссылки на презентации везде, где было возможно.

В чем залог успешной настройки Continuous Delivery на проектах? Слаженная работа команд разработки, тестирования и инженеров по инфраструктуре. Спасибо, кэп, как говорится :) Но как это реализовать на практике? В этой статье поделимся нашими наработками, как это всё организовать и воплотить в жизнь.

Мы обобщили базовые основы в одну шпаргалку для себя и делимся с вами:

• Какие бывают требования и чем они характеризуются,
• Типы задач и порядок их описания в Issue tracker,
• Как оформлять User story и Tech story,
• Как описывать баги,
• Настройка конвейера развертывания.

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

Сегодня мы детально разберем реактивное angular-приложение (репозиторий на github), написанное целиком по стратегии OnPush. Еще приложение использует reactive forms, что вполне типично для enterprise-приложения.

Мы не будем использовать Flux, Redux, NgRx и вместо этого воспользуемся возможностями уже имеющимися в Typescript, Angular и RxJS. Дело в том, что данные инструменты не являются серебряной пулей и могут внести излишнюю сложность даже в простые приложения. Нас об этом честно предупреждают и один из авторов Flux, и автор Redux и автор NgRx.

Но эти инструменты дают нашим приложениям очень приятные характеристики:

• Predictable data flow;
• Поддержка OnPush by design;
• Неизменяемость данных, отсутствие накопленных side effect-ов и прочие приятные мелочи.

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

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