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

В предыдущей статье мы разбирали протокол Modbus, являющийся стандартом де-факто в промышленности для M2M-взаимодействия. Разработанный в далеком 1979 году, он имеет ряд существенных недостатков, которые решает MQTT.

Протокол MQTT достаточно молод (стандартизирован только в 2016 году), но уже успел получить широкое распространение в промышленности и IoT. Он был специально разработан максимально компактным, для нестабильных интернет-каналов и маломощных устройств, и позволяет гарантированно доставлять сообщения в случае потери пакетов и обрывов связи.

Главные особенности протокола MQTT:

• Компактный и легковесный — минимальные накладные расходы на пересылку данных, для экономии трафика.
• Устойчивость к потерям — гарантированная доставка в условиях нестабильных сетевых подключений.
• Асинхронный — позволяет обслуживать большое количество устройств, и не зависит от сетевых задержек.
• Поддержка QoS — возможность управлять приоритетом сообщений и гарантировать доставку сообщения адресату.
• Динамическая конфигурация — не требует предварительно согласования полей и форматов данных, может конфигурироваться «на лету».
• Работает за NAT — клиенты могут находиться за NAT, только сервер (брокер) должен иметь реальный IP. Позволяет обойтись без VPN и пробрасывания портов.
• Удобная адресация — поля данных имеют текстовые названия, понятные для человека. Не нужно запоминать цифровые адреса и битовые смещения.

В .NET Core 3.0 мы представляем набор инструментов, которые используют новые возможности среды выполнения .NET, которые упрощают диагностику и решение проблем с производительностью.

Эти возможности помогут вам ответить на некоторые распространенные вопросы диагностики, которые могут у вас возникнуть:

1. Является ли мое приложение работоспособным?
2. Почему мое приложение имеет аномальное поведение?
3. Почему мое приложение крашится?

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

Разработчики соединяют людей.
Разработчики помогают людям.
Разработчики дают людям возможности.

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

6 мая было объявлено, что следующим после .NET Core 3.0 релизом будет .NET 5. Это будет следующий большой релиз в семействе .NET.

В будущем останется только один .NET, и вы сможете использовать его для разработки под Windows, Linux, macOS, iOS, Android, tvOS, watchOS, WebAssembly и другие платформы.

Мы представим новые .NET API, возможности исполняющей среды и возможности языка как части .NET 5.

Люди учатся архитектуре по старым книжкам, которые писались для Java. Книжки хорошие, но дают решение задач того времени инструментами того времени. Время поменялось, C# уже больше похож на лайтовую Scala, чем Java, а новых хороших книжек мало.

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

Эта статья является расшифровкой моего доклада с конференции DotNext 2018 Moscow. Кроме текста, под катом есть видеозапись и ссылка на слайды.

При запуске кластера Kubernetes для конкретного приложения следует понимать, какие требования представляет к этому ресурсу само приложение, бизнес и разработчики. При наличии этой информации можно приступать к принятию архитектурного решения и, в частности, к выбору конкретного Ingress-контроллера, коих на сегодняшний день уже большое количество. Чтобы составить базовое представление об имеющихся вариантах без необходимости изучать множество статей/документации и т.п., мы и подготовили этот обзор, включив в него основные (production ready) Ingress-контроллеры.

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

Всем привет! На связи команда по улучшению продуктивности в .NET (aka. Roslyn). Мы много внимания уделяем улучшению вашего опыта .NET-кодинга. Ведь иногда небольшие дополнения и исправления действительно могут улучшить рабочий процесс. Возможно вы уже видели некоторые улучшения в превью-версиях VS2019. Но мы все равно хотим рассказать о некоторых из них, которые должны помочь вам работать продуктивнее.

Осторожно, много гифок.

Существует несколько вариантов бесплатного лицензирования статического анализатора кода PVS-Studio, предназначенного для поиска ошибок и потенциальных уязвимостей. Бесплатной лицензией могут воспользоваться открытые проекты, маленькие закрытые проекты, публичные специалисты по безопасности и обладатели статуса Microsoft MVP. В статье кратко рассматривается каждый из этих вариантов.

PVS-Studio — это инструмент для выявления ошибок и потенциальных уязвимостей в исходном коде программ, написанных на языках С, C++, C# и Java. Работает в среде Windows, Linux и macOS.

Наш коллега, Скотт Хансельман, продолжает изучать тестирование и покрытие кода в .NET Core. Он уже успел рассказать о некоторых инструментах для улучшения качества тестирования, и сегодня рассказывает еще об одном: AltCover. Заглядывайте под кат!

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

Меня зовут Денис Исаев, и я руковожу одной из бэкенд групп в Яндекс.Такси. Сегодня я поделюсь с читателями Хабра описанием проблем, которые могут возникнуть, если не учитывать идемпотентность распределенных систем в своем проекте. Для этого я выбрал формат вымышленных историй о стажёре Васе, который только-только учится работать с API. Так будет нагляднее и полезнее. Поехали.

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

К сожалению, некоторые невысокие программисты всерьёз полагают, что Dockerfile с какой-нибудь вообще любой командой внутри — это уже сам по себе микросервис и его можно деплоить хоть сейчас. Докеры крутятся, лавешка мутится. Такой подход оборачивается проблемами начиная с падения производительности, невозможностью отладки и отказами обслуживания и заканчивая кошмарным сном под названием Data Inconsistency.

Если вы ощущаете, что пришло время запустить ещё одну аппку в Kubernetes/ECS/whatever, то мне есть чем вам возразить.

English version is also available.

Встречали ли вы в C# конструкцию типа using (var scope = new TransactionScope(TransactionScopeOption.Required))? Это значит, что код, выполняющийся в блоке using, заключается в транзакцию и после выхода из этого блока изменения будут зафиксированы или отменены. Звучит понятно, пока не начинаешь копать глубже. И чем глубже копаешь, тем «страньше и страньше» становится. Во всяком случае, у меня при более близком знакомстве с классом TransactionScope и вообще транзакциями .NET возникла целая уйма вопросов.

Что за класс TransactionScope? Как только мы используем конструкцию using (var scope = new TransactionScope()), все в нашей программе сразу становится транзакционным? Что такое «управляющий ресурсами» (Resource Manager) и «управляющий транзакциями» (Transaction Manager)? Можно ли написать свой управляющий ресурсами и как он «подключается» к созданному экземпляру TransactionScope? Что такое распределенная транзакция и правда ли, что распределенная транзакция в SQL Server или Oracle Database — это то же самое, что и распределенная транзакция .NET?

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

В последнее время веб-разработка разделилась. Теперь мы все не full-stack программисты — мы фронтендеры и бэкендеры. А самое сложное в этом, как и везде, это проблема взаимодействия и интеграции.

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

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

Приложения ASP.NET Core по-настоящему кросс-платформенны и могут запускаться в «никсах», а соответственно, и в Docker. Посмотрим, как их можно упаковать, чтобы развертывать на Linux и использовать в связке с Nginx. Подробности под катом!

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

Краткое знакомство с kubernetes для разработчиков на примере разворачивания простого шаблонного сайта, с постановкой его на мониторинг, выполнением джобов по расписанию и health checks (все исходники прилагаются)

— Установка Kubernetes
— Установка UI
— Запуск своего приложения в кластере
— Добавление кастомных метрик в приложение
— Сбор метрик через Prometheus
— Отображение метрик в Grafana
— Выполнение задач по расписанию
— Отказоустойчивость
— Выводы
— Заметки
— Список литературы

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

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

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

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

Эта статья основана на наших материалах по консистентности и ACID-гарантиям в распределенных системах.

Всем привет!

Наша компания делает сервис для хранения и обработки данных с промышленных устройств (насосы, буры и прочая промышленная техника). Мы храним данные наших клиентов и предоставляем функционал для их анализа: построение отчетов, графиков и еще много чего.

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

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

Но именно отсутствие информации на данную тему породило желание рассказать сообществу о размышлениях, принятых решениях и выводах на тему разработки SDK. В статье рассматривается решение для .NET, но речь идет о концепции, так что будет интересно многим. Подробности под катом!

С приходом .Net Core у нас появилась прекрасная возможность не только запускать наш код на разных ОС, но и тестировать его на разных ОС. А что может быть лучше Docker при работе с разными ОС?