Айтишник на все руки
Сетевой стек — одна из самых запутанных вещей в Linux. И не только из-за сложности некоторых концепций и терминов, но и из-за изменения смысла некоторых параметров в разных версиях ядра. В этой статье приведена информация для ядра 2.2 и выше, а также, там где это возможно, указано различие между версиями вплоть до 5.5.
О том как изменять параметры ядра, описываемые здесь, можно прочитать в статье Linux Kernel Tuning for High Performance Networking: Configuring Kernel Settings.
Хотите добиться нестандартного поведения от aspnet core? Мне вот понадобилось добавить прозрачную поддержку Json Rpc. Расскажу о том, как я искал решения для всех хотелок, чтобы вышло красиво и удобно. Может быть, вам пригодятся знания о разных точках расширения фреймворка. Или о тонкостях поддержки Json Rpc, даже на другом стеке/языке.
В результате получилась библиотека, которая позволяет работать с Json Rpc, вообще не задумываясь, что он спрятан под капотом. При этом пользователю не нужно уметь ничего нового, только привычный aspnet mvc.
Сегодня пользователи требуют оперативности, новейших и лучших функций и нулевого времени простоя своих приложений. Компании быстро осваивают возможности облака, чтобы удовлетворить потребности пользователей, повысить масштабируемость и доступность приложений. Однако для того, чтобы полностью использовать облако и оптимизировать экономию средств, приложения должны разрабатываться с учетом облачности. Это означает не только изменение способа создания приложений, но и изменение практики разработки в организации для принятия этого архитектурного стиля, ориентированного на облачные вычисления.
Команда .NET собрала коллекцию бесплатных ресурсов, чтобы помочь вам ускорить процесс разработки облачных приложений. Независимо от того, модернизируете ли вы свое приложение или создаете что-то новое, у нас есть рекомендации, которые помогут вам принять решение. Эти руководства актуальны и включают новейшие и лучшие облачные функции платформы .NET.
- 3 ресурса с гайдами
- сайт с учебными модулями
- 8 книг
- ресурс с примерами архитектуры
Все это под катом!
При использовании архитектуры в стиле вертикальных слайсов рано или поздно встает вопрос «а что делать, если появляется код, который нужно использовать сразу в нескольких хендлерах?»
TLDR: нужно создать промежуточный слой обработчиков и добавить специализированные маркерные интерфейсы, чтобы было ясно, какие обработчики — холистические абстракции, а какие нет.
Ответ на этот вопрос не всегда очевиден. Джимми Боггард, например, предлагает «просто использовать приемы рефакторинга». Я всецело поддерживаю такой подход, однако форма ответа видится мне такой же обескураживающей, как и предложение воспользоваться свободной монадой для внедрения зависимостей в функциональном программировании. Такая рекомендация точна и коротка, но не слишком полезна. Я попробую ответить на этот вопрос более развернуто.
У функционального программирования есть одна большая проблема — о нем очень непросто рассказывать. Попытки донести людям что-то с использованием терминов типа «зигохистоморфный препроморфизм» легко сводят неподготовленного слушателя с ума.
Марк Симан — автор популярной книги Dependency Injection in .NET, автор бесчисленных блог-постов. На DotNext 2017 Moscow Марк рассмотрел применение dependency injection в классическом объектно-ориентированном дизайне и объяснил, почему его необязательно (даже нежелательно) использовать в функциональном программировании. Следом за этим он наглядно показал, как использование приемов функционального программирования устраняет необходимость в использовании моков и стабов в модульном тестировании и позволяет полностью выбросить мусор из прямого перечисления зависимостей.
Под катом — перевод доклада и видео. Далее повествование будет от лица Марка.
Когда речь заходит о многозадачности в .Net, то в подавляющем большинстве случаев предполагается вытесняющая многозадачность на основе потоков операционной системы. Но в этой статье речь пойдёт о реализации кооперативной многозадачности, с помощью которой можно создать видимость одновременной работы нескольких методов, используя всего один единственный поток.
У меня есть несколько микросервисов, которые общаются друг с другом с помощью JSON через REST, и мне кажется, что скоро они достигнут предела производительности VPS, и мне нужно будет его апгрейдить, чтобы не было просадки по производительности.
И я решил оценить, какой выигрыш в производительности я смогу получить от gRPC (если вообще смогу) и, что более важно, сколько усилий мне придется приложить, чтобы полностью перевести все мои микросервисы на gRPC.
Две недели назад весь мир наблюдал за успешной посадкой робота Perseverance на поверхность Марса и разговоров о космосе сразу стало на порядки больше. Инфоповод всколыхнул обсуждения в соцсетях и блогах — все больше людей хотят говорить о покорении космоса, возможностях и опасностях.
Поэтому мы решили разобрать лексику и особенности из видео приземления марсохода. И неожиданно сковырнули несколько интересных нюансов языка. Поехали!
Эта статья является конспектом материала Clarified CQRS.
Прежде чем начать разбираться с CQRS, нужно понять две основные движущие силы, стоящие за ним: сотрудничество и устаревание.
Сотрудничество относится к ситуациям, когда несколько участников используют или изменяют один и тот же набор данных независимо от того, действительно ли они намерены сотрудничать. Зачастую имеются правила, которые указывают какие пользователи могут выполнять модификации. И эти модификации могут быть приемлемыми в одном случае и неприемлемыми в другом. В качестве пользователя может выступать реальный человек или программное обеспечение.
Устаревание касается того факта, что в многопользовательских системах, как только данные были показаны пользователю, те же самые данные могут быть в дальнейшем изменены и стать устаревшими. Почти любая система, использующая кеширование, например, с целью улучшения производительности, работает с устаревшими данными. Это означает, что нельзя полностью доверять принятым решениям наших пользователей, поскольку они могли быть приняты на основе устаревших данных.
Стандартная многоуровневая архитектура не решает ни одну из этих проблем. Хотя размещение всех данных в одной БД может способствовать улучшению совместной работе, устаревание обычно усугубляется в такой архитектуре из-за использования кеширования в качестве средства повышения производительности.
Хочу поделиться своим опытом реализации микросервисной архитектуры поверх actor-model фреймоворков, таких как AKKA и Microsoft Orleans.
Моя гипотеза: если использовать один стек для реализации микросервисов, то можно:
О… Похоже на «серебряную пулю»! Давайте разберемся, так ли это.
Разработчик SimpleInjector очень любит «декораторы», особенно в сочетании с дженериками видаQueryHandler<TIn, TOut>, CommandHanler<TIn, TOut>.Время от времени я встречаю людей, пытающихся выразить API в терминах IQueryable<T>. Почти всегда это плохая идея. В этой статье я объясню почему. Вкратце, IQueryable<T> — это один из лучших примеров заголовочного интерфейса (Header Interface), предлагаемых платформой .NET. Его почти невозможно реализовать полностью.
Эта статья о проблемах реализации API на основе интерфейсаIQueryable<T>. Это не претензия к интерфейсу как таковому. Кроме этого, это не претензия к замечательным методам LINQ, доступным для интерфейсаIEnumerable<T>.
Можно сказать, что IQueryable<T> — это одно сплошное нарушение принципа подстановки Лисков. Я буду использовать закон Постела, чтобы объяснить почему это так.
Принцип устойчивости, также известен как закон Постела в честь Джона Постела: «Будь либерален к тому, что принимаешь, и консервативен к тому, что отсылаешь (Be liberal in what you accept, and conservative in what you send)».
Прежде чем начать я бы хотел отметить, что это всего лишь небольшой туториал по быстрому старту для тех кто, как и я, ни разу не использовал Kafka на практике
Сегодня в этой статье мы обсудим концепцию обработки исключений в приложениях ASP.NET Core. Обработка исключений (exception handling) — одна из наиболее важных импортируемых функций или частей любого типа приложений, которой всегда следует уделять внимание и правильно реализовывать. Исключения — это в основном средства ориентированные на обработку рантайм ошибок, которые возникают во время выполнения приложения. Если этот тип ошибок не обрабатывать должным образом, то приложение будет остановлено в результате их появления.
В ASP.NET Core концепция обработки исключений подверглась некоторым изменениям, и теперь она, если можно так сказать, находится в гораздо лучшей форме для внедрения обработки исключений. Для любых API-проектов реализация обработки исключений для каждого действия будет отнимать довольно много времени и дополнительных усилий. Но мы можем реализовать глобальный обработчик исключений (Global Exception handler), который будет перехватывать все типы необработанных исключений. Преимущество реализации глобального обработчика исключений состоит в том, что нам нужно определить его всего лишь в одном месте. Через этот обработчик будет обрабатываться любое исключение, возникающее в нашем приложении, даже если мы объявляем новые методы или контроллеры. Итак, в этой статье мы обсудим, как реализовать глобальную обработку исключений в ASP.NET Core Web API.
Здравствуй дорогой наш читатель. Это третья статья из серии переезда нашего ПО на кроссплатформенные рельсы. Она затронет визуальную часть продукта, а именно диалоговое окно.
В рамках первой статьи упоминалось, что данное приложение вызывается через пункт ПКМ, в связи с чем были проблемы при развертывании в разных ОС. Самое интересное заключалось не только в том, как реализовать вызов “визуальщины”, но и в том, как нам без сильных потерь реализовать диалоговое окно, которое мы сможем спокойно использовать в Linux, а возможно в дальнейшем и в Windows. Для самых нетерпеливых забегу в перёд и скажу, что в данной задаче нам помог framework Avalonia. Ну а теперь по порядку.
Мы имеем WinForms приложение, работающее, разумеется, только в Windows. Его задача - выводить диалоговое окно с небольшим количеством контролов, фактически главными из которых листбокс и кнопка.
Как раз только выходит .Net Core 3, с предположением о работе в Linux. Собираем, проверяем и ничего не получаем. В действительности в Linux не добавили визуальную часть. Ну что же, ищем другие варианты.
Самым часто встречающимся фреймворком по данному вопросу является Avalonia. Мы решили опробовать её. Взяли простейший пример, собрали в Linux, запустили и да, диалоговое оно отобразилось. Теперь дело за малым - перенести WinForms проект на Avalonia.
В качестве проекта был выбран простой шаблон Avalonia Application, при условии, что логика и DTO уже вынесены в отдельные библиотеки, шаблон MVVM здесь был бы избыточен.
Перенос дизайна основного окна с WinForms на XAML прошёл без проблем, несмотря на то, что разработчик в знакомстве с WPF ранее замечен не был.
Логика осталась практически без изменений (BackgroundWorker, файлы, DTO, ...).
Реализация окон сообщений, на первый взгляд, также проблем не вызвала.
В проекте WinForms в качестве диалогового окна сообщения использовался System.Windows.Forms.MessageBox.
Язык F# уступает в популярности C#. Вместе с тем, во многом благодаря сообществу, фаршик стал реальной альтернативой для прикладных проектов. В статье описаны ингредиенты бэкенда, фронтенда, тестов, сборки и инфраструктуры проекта, полностью написанного на F#. Исходный код прилагается.
Go - это язык с автоматическим управлением памятью: сборщик мусора без участия программиста позаботится о том, чтобы освободить память, занимаемую объектами, более не используемыми программой. Но памятью вся автоматика в целом и ограничивается - об остальных используемых программой ресурсах нам по-прежнему нужно заботиться самостоятельно.
О механизмах освобождения ресурсов и решении связанных с ними проблем - в этой статье.
Любой, кто работал на крупном корпоративном проекте, знает, что утечки памяти подобны крысам в большом отеле. Вы можете не замечать их, когда их мало, но вы всегда должны быть начеку на случай, если они расплодятся, проберутся на кухню и загадят все вокруг.
Умение обнаруживать, исправлять и предупреждать утечки памяти — очень важный навык. Здесь я перечислю 8 лучших практик, используемых мной и моими коллегами старшими .NET разработчиками, которые и вдохновили меня написать эту статью. Эти методы научат вас определять, когда в приложении возникает утечка памяти, находить и исправлять ее. Наконец, я включил в статью стратегии для мониторинга и отчета об утечках памяти в уже развернутых программах.
Веб-токен JSON обычно используется для авторизации в клиент-серверных приложениях. JWT состоит из трех элементов:
Это объект JSON, который представляет собой метаданные токена. Чаще всего состоит из двух полей:
Официальный сайт предлагает два алгоритма хэширования: