Добро пожаловать на седьмой выпуск нашего дайджеста, посвящённого новостям и событиям в мире .NET! В этот раз мы расскажем про .NET 10 preview 2 и 3, новый релиз Mono, множество интересных статей и, конечно же, AI. Команда PVS-Studio рада представить вам подборку самых интересных и полезных материалов. Поехали!
System.Numerics и узнаем, как применить в продакшне кровавого ынтэрпрайза.
Мы закончили обсуждать тело функции, и теперь пришло время вывода данных. Простые сценарии мы сразу отбросим, так как по ним уже хорошо прошлись, когда изучали выражения. Мы начнём с косяков выполнения, под которыми я подразумеваю не баги, а непреодолимые препятствия с различной степенью неожиданности. Это может прозвучать странно, так как аварийный выход не подпадает под определения output, codomain и т. д. Я с этим согласен и пересматривать эти термины не собираюсь. Однако меня интересует не только легитимная часть, но и вообще всё, что выходит из функции. Вплоть до того, что в следующих главах я начну включать в это аморфное понятие сайд-эффекты, фоновые процессы и много чего другого.
Я начал с ошибок, потому что Godot эту тему фактически проигнорировал, и вряд ли за ненадобностью, так как несколько раз мне уже было очень больно. У меня всё ещё не дошли руки покопаться в GDScript, так что я понятия не имею, вызван ли этот пробел ограничениями языка или архитектурным решением, но в любом случае нам его надо закрывать.
C# и ФП пропагандируют разные подходы к ошибкам. F#, будучи на перепутье, испытывает влияние обоих. Можно много говорить про плюсы взаимного обогащения культур, но судя по публичным баталиям, это не совсем наш случай. Вместо синтеза я куда чаще наблюдаю эмоциональные взрывы в среде представителей то одного, то другого лагеря. Я не буду ввязываться в эту борьбу (в этот раз) и сосредоточусь на решении более насущной задачи. Мне нужно доработать интероп так, чтобы он соблюдал привычную систему распределения ответственности. Так что сегодня только рутина, без красивых ходов и эффектных бросков.
Здравствуйте! Меня зовут Дмитрий Гусаков, я менеджер проектов компании DD Planet. В своей статье я расскажу, почему нельзя использовать 1С как полноценный бэкенд в современных B2B-системах, с какими ограничениями могут сталкиваться разработчики, и как выстроить надёжную структуру, используя дополнительный слой бэкенда и брокеры сообщений.
В России существует острый дефицит отечественных продуктов для автоматизации бизнеса. 1С — один из немногих российских игроков на этом рынке. В условиях активного импортозамещения он стал основным кандидатом на замену западных систем, вроде Oracle CRM, ERP SAP и все больше российских компаний переходят на эту платформу. Однако сам по себе этот переход не решает всех проблем.
Уже более пяти лет мы занимаемся разработкой OpenSilver — open-source-фреймворка, который позволяет переносить приложения на базе WPF и Silverlight в современный веб. Проект стабильно развивается, активно используется в корпоративной среде, и недавно мы задумались о том, как расширить возможности наших пользователей и запустить существующие приложения ещё и на iOS и Android.
Поскольку под капотом OpenSilver использует платформу Blazor, логичным шагом стала интеграция с .NET MAUI Blazor Hybrid. В этой статье я расскажу, как прошла интеграция и какие результаты мы получили на практике. Забегая вперёд, скажу, что результатом мы остались очень довольны!
JSON - это популярный текстовый формат, который используется для обмена данными. Он был разработан на основе JavaScript синтаксиса, но является полностью независимым от языка, что позволяет использовать его почти в любом программном окружении.
В контексте игродела JSON нередко используют для внутриигровых сохранений. Фактически мы преобразовываем экземпляры наших классов и структур в удобный формат, а далее помещаем это в файл с расширением .json
Здравствуйте. Меня зовут Валерий и я — кодоголиклюблю писать программы. И иногда в процессе написания программ сами собой возникают интересные истории. Об одной такой история я и хочу рассказать в этой статье.
За десять с лишним лет, прошедших с момента изобретения конструкции async/await, она стала привычной и широко используемой. В наше время мало у кого вызывает затруднение написать самому или же понять смысл написанного кем-то другим выражения типа await stream.ReadAsync(buffer,async, count) — ясно, что это — чтение из потока в некий буфер, и что программа тут отдает управление на то время, пока это чтение выполняется, чтобы по завершении чтения получить управление продолжить свое выполнение дальше.
Но что вы скажете, увидев в коде вот такое выражение: await this в одном из методов класса, совершенно не похожего на Task/ValueTask или ещё что-то, что привычно видеть после await? Не правда ли это вас смутит и уж, тем более, вы вряд ли напишете такое сами? А я однажды такое написал в здравом уме и трезвой памяти. И если вам интересно, зачем это было так написано и что за магия тут творитсякак это работает, и как вообще определить свой класс, чтобы ссылку на него можно было указать после await — читайте статью.
Всем привет. Сегодня хотел затронуть тему, которая в бытности разработчика вызывает и смех, и слезы, — о самых необычных запросах на разработку от коллег, поставляющих задачи. Также заранее прошу не принимать прочитанное близко к сердцу: какие-то из ситуаций могут показаться наивными, но обойти их стороной я не смог в этом посте.
Итак, начну с собственного реноме. Меня зовут Богдан, я работаю в одном достаточно большом отечественном финтеке вот уже 7-й год и добрую половину из них занимаю позицию Java-лида в одной из интеграционных команд. За такое (относительно) длительное время в энтерпрайзе периодически приходят требования на разработку, от которых хочется или плакать, или смеяться, а то и всё вместе. Происходит это по самым разным причинам, которые мы сегодня касаться не будем. Скажу лишь, что никого не осуждаю, не пытаюсь никого принизить и наверняка сам генерировал нечто схожее, о чем пойдет речь ниже. Также стоит учесть, что мой бэкграунд преимущественно бэкендово-интеграционный, соответственно, и кейсы будут из этой области и контекста. Ну а дальше — по кейсам, по тем 7 кейсам, когда прочитав требования, внутри что-то скукоживается от отвращения либо раздается улыбка во всё лицо — у кого как.
Немного глобального контекста: проект, вокруг которого будут описаны курьезные запросы, — интеграционная шина данных, напичканная самой разной интеграционной логикой, Java-приложение, состоящее из невообразимого количества SOAP/REST-методов, шедуллеров и всяческих очередей.
В этом цикле статей рассмотрим как можно легко и быстро делать на C# любые однотипные действия просто навешивая атрибуты на доменные сущности
В мире .NET разработки, работа с базами данных – неотъемлемая часть. Entity Framework Core (EF Core) предоставляет удобный способ взаимодействия с данными, но при работе с SQL Server, особенно в сложных сценариях, LINQ запросы могут уступать в производительности и гибкости T-SQL. Статья рассматривает эту дилемму, предлагая гибридный подход. Мы погрузимся в проблему: как эффективно использовать мощь T-SQL, не отказываясь от преимуществ EF Core? Обсудим интеграцию T-SQL через Raw SQL, Views, UDF и Stored Procedures. Раскроем лучшие практики: разделение ответственности, оптимизацию запросов, безопасность и тестирование. Поймем, как сочетать удобство ORM с производительностью SQL Server, применяя Data-Driven Design и, при необходимости, Domain-Driven Design. Статья – руководство для .NET разработчиков, стремящихся к оптимальному балансу между производительностью, гибкостью и удобством разработки при работе с SQL Server и EF Core.
В этой статье рассмотрим пример реализации .NET сервиса для работы с API Яндекс Метрики, включая авторизацию, получение данных и их синхронизацию с БД.
В прошлых частях мы подключились к Godot, обсудили адаптацию к API и разобрались с устройством тела функции. Дальше в планах было перейти к входным и выходным данным, от них к общей архитектуре и далее снова к особенностям API. Если бы я отстрелялся быстрее, то так бы и было, но я возился слишком долго (об этом чуть ниже), из-за чего до моей телеги успел доползти читатель с типовым набором набивших оскомину вопросов. Допускаю, что я собрал всю коллекцию практикующих читателей, но мне хочется верить, что где-то прячется «молчаливое большинство» с аналогичными проблемами. Поэтому я решил передвинуть некоторые рассуждения из конца цикла в середину.
Это задержит кульминацию, но не критично, так как финальные части цикла я планировал запостить без длительных пауз. Поэтому эта глава пролежит в ожидании до тех пор, пока не будет готов черновик всего цикла. Если этот текст появился на Хабре, то остальные главы уже на подходе.
Привет, Хабр! Это Алексей Деев, backend-разработчик в компании Avanpost. В этой статье я коротко расскажу о мире параллельной обработки данных с помощью акторной модели, приведу примеры кода на разных реализациях акторов под .net.
В этой статье я расскажу о том, как я создал систему безопасности для своего проекта. Здесь я описываю этапы реализации, проблемы которые я решил, и как я устранил обнаруженные уязвимости.
Я думаю, что многим программистам по мере их профессионального роста и наращивания стека технологий сильно не хватает времени. Это касается как технических аспектов (например, проектирование архитектуры или масштабируемость приложений), так и общей организации работы. Даже если не учитывать все эти нюансы, вход в новый проект требует значительных временных затрат на изучение теории и создание портфолио, особенно для стажеров и джуниоров.
По мере вхождения в проект, изучая документацию и инфраструктуру, я начал чаще сталкиваться с вопросами, связанными с ускорением алгоритмов и потреблением памяти, я также интересовался прокачкой хард-скиллов. Если раньше мне было достаточно базовых возможностей LINQ, то с увеличением объёмов данных из внешних источников я задумался о рефакторинге и смене подходов к разработке.
Находясь на позиции junior, я столкнулся с необходимостью оптимизации кода – и после частого откладывания этого вопроса на потом мне всё же пришлось поднять его снова. Сегодня я бы хотел поделиться своим опытом на эту тему.
Микросервисная архитектура стала де-факто стандартом для построения современных масштабируемых приложений. Вместо единого монолитного приложения система разбивается на набор мелких независимых сервисов, каждый из которых отвечает за свою четко обозначенную функцию. Такой подход позволяет упрощать разработку и развертывание отдельных компонентов, повышать отказоустойчивость и масштабируемость системы. Однако переход к микросервисам и их эффективное использование сопряжены с рядом сложных задач. Для их решения в практике выработаны архитектурные паттерны – типовые подходы и шаблоны проектирования.
В данной статье мы разберем несколько ключевых паттернов, связанных с микросервисами. Речь пойдет о паттернах миграции и интеграции (таких как Strangler Fig – «удушающее дерево» и API Gateway), о сетевых и структурных паттернах (Service Mesh, Sidecar), о шаблонах работы с данными (Database per Service, CQRS) и об особом подходе к хранению состояния (Event Sourcing). Для каждого паттерна мы рассмотрим его суть, назначение, примеры использования, а также плюсы и возможные сложности. К некоторым паттернам приведены упрощенные диаграммы и фрагменты кода, чтобы иллюстративно показать, как они работают на практике.
Рассказываю чем заменить Swashbuckle, который убрали из .Net 9, для создания страницы похожей на Swagger UI.
Этой статьёй я хочу внести некоторые правки в алгоритм развёртывания, который я описывал год назад вот здесь. Статья тогда получилась объёмная, и я искал способы её сократить, в результате чего опрометчиво пренебрёг несколькими сценариями, которые пригодились мне в дальнейшей разработке. Они образовали техдолг, который мне необходимо закрыть ввиду грядущего продолжения.
Привет, друзья! На связи снова Кирилл Пронин из PIX Robotics, и у меня для вас новая статья-сенсация!
Мы сейчас открыли новый набор стажеров нашу команду разработки RPA, и коллеги попросили рассказать, как проходила стажировка по C# в прошлом году. А я что – я только за, потому что: а) благодаря прошлой стажировке мы заполучили двух талантливых джунов; б) для меня стажировка стала первым опытом в роли TeamLead’a; в) это было весёлое и необычное путешествие с неожиданными результатами (саму крутую цифру я уже вынес в заголовок, об остальных – ниже).
Для нашей команды это был первый опыт запуска стажировки, так что, как бы ни готовились, мы все равно не учли некоторые нюансы. Назвать их громко ОШИБКАМИ пальцы не поднимаются, а вот неожиданностями и нюансами – вполне. А так как для меня это все стало еще и первым опытом «тимлидства», то поделиться всем этим хочется вдвойне. Так что в этой статье расскажу, как организовать продуктивную стажировку, как отбирать лучших из лучших, какие ошибки нам удалось избежать и, конечно, о ключевых особенностях работы.