6 мая было объявлено, что следующим после .NET Core 3.0 релизом будет .NET 5. Это будет следующий большой релиз в семействе .NET.
В будущем останется только один .NET, и вы сможете использовать его для разработки под Windows, Linux, macOS, iOS, Android, tvOS, watchOS, WebAssembly и другие платформы.
Мы представим новые .NET API, возможности исполняющей среды и возможности языка как части .NET 5.
Всем привет! Сегодня мы рассмотрим разные фишки и изменения, которые появились в .NET Core платформе и сравним их с Framework. Я разбил статью на модули для более лучшего понимания. Эта статья будет интересна тем кто собирается переходить на .NET Core или уже использует его.
В данный момент у нас есть три платформы: .NET Framework, Mono и .NET Core. Каждая платформа включает в себя следующие технологии:
NET Framework — WPF, WinForms, ASP.NET (DNX реализация), WCF
NET Core — UWP, ASP.NET Core, WA, Xamarin (.NET Standard), Avalonia and other
Mono — Xamarin (PCL, Share project), Unity, ASP.NET, WinForms (cross platform)
NET Core (3.0) — Всё тоже самое, что и у .NET Core выше + WPF и WinForms, ML.NET
Ещё есть .NET Standard. Это набор классов, методов и интерфейсов, которые позволяют писать и использовать общий код под все перечисленные выше платформы. Ещё на ней можно писать консольные приложения. Вкратце это тот же PCL, но работает на всех перечисленных выше платформах.
Мы развивали DevOps как могли. Нас было 8 человек, и Вася был самым крутым по Windows. Внезапно Вася ушел, а у меня появилась задача вывести новый проект, который поставляет Windows-разработка. Когда я высыпал на стол весь стек Windows-разработки, то понял, что ситуация — боль…
Так начинается история Александра Синчинова на DevOpsConf. Когда из компании ушел ведущий специалист по Windows, Александр задался вопросом, что теперь делать. Переходить на Linux, конечно же! Александр расскажет, как ему удалось создать прецедент и перевести часть Windows разработки на Linux на примере реализованного проекта на 100 000 конечных пользователей.
Как легко и непринужденно доставлять проект в RPM, используя TFS, Puppet, Linux .NET core? Как поддерживать версионирование БД проекта, если разработка впервые слышит слова Postgres и Flyway, а дедлайн послезавтра? Как интегрировать с Docker? Как мотивировать .NET-разработчиков отказаться от Windows и смузи в пользу Puppet и Linux? Как решать идеологические конфликты, если обслуживать Windows в продакшн нет ни сил, ни желания, ни ресурсов? Об этом, а также о Web Deploy, тестировании, CI, о практиках использования TFS в существующих проектах, и, конечно, о сломанных костылях и работающих решениях, в расшифровке доклада Александра.
Читать полностью »
В предыдущей статье я рассказал про механизм DiagnosticSource и на простом примере показал, как с его помощью можно перехватывать запросы в базу данных через классы SqlConnection и SqlCommand и измерять время их выполнения.
В настоящее время DiagnosticSource уже используется в AspNetCore, EntityFrameworkCore, HttpClient и SqlClient — каждый из них отправляет собственные события, которые могут быть перехвачены и обработаны.
В этой статье я хочу рассмотреть несколько примеров того, как можно на практике использовать DiagnosticSource в приложениях ASP.NET Core.
Кроме того, в этой статье я решил собрать список событий, которые доступны для обработки и могут быть использованы в ваших приложениях, а также рассказать о некоторых подводных камнях, с которыми вы можете столкнуться, если решите использовать механизм DiagnosticSource в своём проекте.
Краткое знакомство с kubernetes для разработчиков на примере разворачивания простого шаблонного сайта, с постановкой его на мониторинг, выполнением джобов по расписанию и health checks (все исходники прилагаются)
— Установка Kubernetes
— Установка UI
— Запуск своего приложения в кластере
— Добавление кастомных метрик в приложение
— Сбор метрик через Prometheus
— Отображение метрик в Grafana
— Выполнение задач по расписанию
— Отказоустойчивость
— Выводы
— Заметки
— Список литературы
Читать полностью »
Для обеспечения балансировки нагрузки, масштабируемости и повышения отказоустойчивости могут использоваться вспомогательные средства — оркестраторы. Среди них большой популярностью сейчас пользуется сервис Kubernetes. Самый простой способ попробовать его в деле — развернуть его в облаке, чем мы сегодня и займемся.
DiagnosticSource — это простой, но весьма полезный набор API (доступен в NuGet пакете System.Diagnostics.DiagnosticSource), который, с одной стороны, позволяет различным библиотекам отправлять именованные события о своей работе, а с другой — позволяет приложениям подписываться на эти события и обрабатывать их.
Каждое такое событие содержит дополнительную информацию (payload), а поскольку обработка событий происходит в том же процессе, что и отправка, эта информация может содержать практически любые объекты без необходимости сериализации/десереализации.
DiagnosticSource уже используется в AspNetCore, EntityFrameworkCore, HttpClient и SqlClient, что фактически даёт разработчикам возможность перехватывать входящие/исходящие http запросы, запросы к базам данных, получать доступ к таким объектам, как HttpContext, DbConnection, DbCommand, HttpRequestMessage и многим другим и даже изменять эти объекты при необходимости.
Я решил разделить свой рассказ про DiagnosticSource на две статьи. В этой статье мы на простом примере разберем принцип работы механизма, а в следующей я расскажу о существующих в .NET событиях, которые можно обрабатывать с его помощью и покажу несколько примеров его использования в OZON.ru.
Hangfire — это библиотека для .net (core), позволяющая асинхронно выполнять некоторый код по принципу "fire and forget". Примером такого кода может быть отправка E-Mail, обработка видео, синхронизация с другой системой и т.д. Помимо "fire and forget" есть поддержка отложенных задач, а также задач по расписанию в формате Cron.
В настоящее время существует масса подобных библиотек. Несколько преимуществ, говорящих в пользу Hangfire:
Не буду слишком вдаваться в детали, поскольку существует немало хороших статей о Hangfire и способах его применения. В этой статье я разберу, как воспользоваться поддержкой нескольких очередей (или пулов задач), как починить стандартную retry-функциональность и сделать так, чтобы каждая очередь имела индивидуальную конфигурацию.
Если вы Web-разработчик и ведете разработку для браузера, то вы точно знакомы с JS, который может исполняться внутри браузера. Существует мнение, что JS не сильно подходит для сложных вычислений и алгоритмов. И хотя в последние годы JS cделал большой рывок в производительности и широте использования, многие программисты продолжают мечтать запустить системный язык внутри браузера. В ближайшее время игра может поменяться благодаря WebAssembly.
Microsoft не стоит на месте и активно пытается портировать .NET в WebAssembly. Как один из результатов мы получили новый фреймворк для клиенской разработки — Blazor. Пока не совсем очевидно, сможет ли Blazor за счет WebAssembly быть быстрее современных JS — фреймворков типа React, Angular, Vue. Но он точно имеет большое преимущество — разработка на C#, а так же весь мир .NET Core может быть использован внутри приложения.
Про «Додо пиццу» уже известно много. Бизнес компании оплетен сетью технологичных сервисов, о своей истории они написали книгу, стек технологий и архитектура системы расписаны прямо на сайте, в паре кликов от главной страницы. Даже самые неприятные факапы они спокойно и открыто обсуждают на публику.
Все это здорово, и создается романтичный флер — кажется, что в «Додо пицце» по умолчанию круто работать. Но нам было интересно понять, так ли это на самом деле.
Нет ли в открытости перегибов и подводных камней? Как люди относятся к открытым камерам на кухнях? Не являются ли технологии просто маркетинговым украшением? В конце концов, пока IT гиганты вокруг зазывают разрабов пожизненным запасом печенек и личными кофеносцами, «Додо» продвигает периодический труд на кухне — чтобы прочувствовать боль клиентов и обычных сотрудников.
Мы с fillpackart обо всем этом расспросили, и нам ответил Александр Андронов, СТО «Додо пиццы».
Читать полностью »
