Рубрика «Блог компании EastBanc Technologies»

image

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

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

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

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

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

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

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

Привет!

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

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

Обзор самых интересных докладов DotNext 2018: версия EastBanc Technologies - 1
Читать полностью »

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

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

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

Как составить стратегию тестирования: версия настоящих инженеров - 1
Читать полностью »

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

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

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

Как организовать CI-CD на проекте: от постановки задач до настройки конвейера развертывания - 1
Читать полностью »

Привет! В EastBanc Technologies ведётся большое количество проектов, связанных с мобильной разработкой. В связи с чем необходим целый зоопарк устройств для тестирования на всех этапах. И, что характерно, каждый отдельный девайс постоянно оказывается нужен самым разным людям, а найти его даже в одном отделе мобильной разработки из нескольких десятков человек — это целая история. Не говоря уже о том, что есть тестировщики, дизайнеры, PM’ы, в конце концов!

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

image
Читать полностью »

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

В этой статье на Хабр расскажем о нашем опыте тестирования больших экранов инструментами Protractor, Zalenium и Selenium-grid. Как мы поэтапно внедряли эти инструменты автоматического UI-тестирования и через какие сложности нам пришлось пройти.

UI-тестирование: проверка системы на разных разрешениях - 1
Читать полностью »

На все про все достаточно 50 чашек кофе.

Помимо обозначенного выше эмпирического правила мы публикуем краткую заметку о моментах, на которые нужно обратить пристальное внимание, чтобы на бою и в процессах ничего не сломалось. Заметку составили по горячим следам релиза мобильного сервиса, совсем мигрировавшего на .Net Сore (начало было положено тут). Нам удалось выполнить эту операцию незаметно для заказчика, почти не останавливая основной процесс разработки.

Ниже будет готовый план действий, будет очень емкий тест-лист, будет вот эта картинка для настроения:

Найдена формула безболезненного перехода на .Net Core - 1

Читать полностью »

«Наши сайнтисты сгенерировали кучу графиков, а мы совершенно не знаем, куда их девать. Давайте попробуем их хоть как-то пристроить». (с) подслушано

«Плохие графики везде. В моей работе я постоянно встречаю крайне сомнительные визуализации данных. Никто не делает плохие графики намеренно. Но это происходит. Опять и опять. В каждой компании во всех отраслях экономики сотрудниками всех уровней. Это происходит в СМИ. Это происходит там, где вы ожидаете, что люди должны уметь визуализировать данные». (с) автор книги

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

«Storytelling with Data», Cole Nussbaumer Knaflic: неформальный обзор-конспект книги - 1

Название книги «Storytelling with Data» звучало убедительно. Выбрал её для вечернего чтения и не пожалел. В книге нет формул, хитрых и необычных графиков, сложных кейсов. Понятный английский. Качественная печать. Читается как художественная литература. Книга будет полезна всем, кому приходится делать презентации на основе данных. Думаю, что особенную пользу она принесёт тем, кто занимается аналитикой данных.

Этот обзор очень неформальный: вперемешку идут мысли автора книги, мои мысли, ситуации из моей работы, а также шпаргалки по matplotlib по ссылкам. Будет много картинок. Почти все иллюстрации перерисованы из книги на Python.
Читать полностью »

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

Для начала достаточно ответить на два простых вопроса:

  • Зачем это мне?
  • Что я расскажу интересного и полезного хабраобществу?

После чего можно взять план из этой статьи (или придумать свой) и сделать это.

image

Есть творческие этапы и технические. В этой статье поговорим о творческих. Рассмотрим:

  • Зачем писать статьи,
  • Откуда взять тему для статьи,
  • Где найти время, чтобы её написать,
  • Основные этапы работы над текстом,
  • Что делать, если статья «не идёт»,
  • И с чего начать, если ты ни разу не писал на Хабр.

Надеемся, что текст пригодится и другим авторам Хабра, в том числе потенциальным.
Читать полностью »

Всем привет!

Сегодня расскажем об опыте одного из наших DevOps проектов. Мы решили реализовать новое приложение под Linux с использованием .Net Core на микросервисной архитектуре.

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

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

Поэтому использовали такие технологии:

  • .Net Core для реализации микросервисов. В нашем проекте использовалась версия 2.0,
  • Kubernetes для оркестрации микросервисов,
  • Docker для создания образов микросервисов,
  • шина интеграции Rabbit MQ,
  • EK для логирования,
  • TFS для реализации конвейера CI/CD.

В этой статье поделимся подробностями нашего решения.

Создание приложения на .NET Core и Kubernetes: наш опыт - 1

Это расшифровка нашего выступления на .NET-митапе, вот ссылка на видео выступления.
Читать полностью »