Рубрика «C#» - 20

в 9:26, , рубрики: .net, .net 5.0, C#, jit, ryujit, Компиляторы, оптимизации

Некоторое время назад я начал удивительное путешествие в мир JIT-компилятора с целью найти места, куда можно засунуть свои руки и что-нибудь ускорить, т.к. по ходу основной работы накопился небольшой багаж знаний в LLVM и его оптимизаций. В этой статье я хотел бы поделиться списком моих улучшений в JIT (в .NET он называется RyuJIT в честь какого-то дракона или аниме — я не разобрался), большая часть которых уже попала в master и будет доступна в .NET (Core) 5. Мои оптимизации затрагивают разные фазы JIT, которые очень схематично можно показать следующим образом:

Оптимизации в JIT-компляторе для .NET 5 - 1

Как видно из схемы, JIT — это отдельный модуль, связанный с рантаймом узким Jit-Interface, по которому JIT консультируется по некоторым вещам, например, можно ли скастить один класс к другому. Чем позже JIT компилирует метод в слой Tier1, тем больше информации может предоставить рантайм, например, что static readonly поля можно заменить константой, т.к. класс уже статически проинициализирован.
Читать полностью »

в 20:58, , рубрики: C#, ооп, перевод, Программирование, функциональное программирование

Привет! Представляю вашему вниманию перевод оригинальной статьи «Your C# is already functional, but only if you let it» автора Igal Tabachnik.

Несколько дней назад я написал в Твиттере фрагмент кода C#, реализующий FizzBuzz, используя некоторые из новых «фичи» в C# 8.0 . Твит “стал вирусным”, несколько человек восхищались его лаконичностью и функциональностью, в то время как другие спрашивали меня, почему я не написал его на F#?

Прошло уже более 4 лет с тех пор, как я в последний раз писал на C#, и то, что я обычно использую функциональное программирование, явно повлияло на то, как я пишу код сегодня. Фрагмент, который я написал, кажется очень аккуратным и естественным, однако некоторые люди выразили опасения, что он не похож на код на C#.

«Он выглядит слишком функциональным.» – писали мне они.

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

в 17:37, , рубрики: .net, C#, DDD, Microservices, микросервисы, Программирование, Проектирование и рефакторинг, Совершенный код

Организация кода в микросервисах и мой подход применения гексагональной архитектуры и DDD - 1
Привет! В Монолите весь код должен быть в едином стиле, a в разных микросервисах можно использовать разные подходы, языки программирования и фреймворки. Для простых микросервисов с 1 — 2 контроллерами и 1 — 10 действиями особо смысла городить слои абстракций нет. Для сложных микросервисов с различными состояниями и логикой перехода между ними наоборот лучше изначально не лениться. Я хочу рассказать о моем опыте организации кода и использования подходов DDD, Портов и Адаптеров для обоих случаев. Есть кратко суть статьи: Джун — пишет код в контроллере. Мидл — пишет кучу абстракций. Сеньор — знает когда нужно писать код в контроллере, а когда нужны абстракции.Читать полностью »

в 9:22, , рубрики: C#, c++, gdb, linux, python, python3, Разработка под Linux

Краткий гайд по использованию GDB - 1

В этом коротком туториале мы рассмотрим базовые приёмы работы с GDB, а также посмотрим как можно (и нужно) подготавливать файлы к отладке для GDB.
GDB — переносимый отладчик проекта GNU, который работает на многих UNIX-подобных системах и умеет производить отладку многих языков программирования, включая Си, C++, Free Pascal, FreeBASIC, Ada, Фортран, Python3, Swift, NASM и Rust.

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

в 23:47, , рубрики: .net, C#, c#.net, Excel, interop, npoi, office, xls, xlsx, Разработка для Office 365

В этой статье я постараюсь рассказать об одном из возможных путей конвертации документов формата xls в xml.

Непосредственно моя задача выглядела примерно так:

Дано:

  1. 1-2 дня времени на поиск и реализацию решения
  2. Найденное решение должно быть на столько бесплатным, на сколько это возможно
  3. Известна примерная структура, размер и содержание файла, которые должны быть обработаны, что снимает необходимость читать графики, диаграммы и иные медианные из документа.
  4. Использовать Interop, равно как и иные библиотеки, которые требуют установки Office нельзя, так как это создает лишнюю нагрузку на сервер и требует дополнительной установки офисного пакета.Читать полностью »

в 8:46, , рубрики: C#, game development, Gamedev, unity, unity3d, ассеты, Блог компании Pixonic, валидация, геймдев, оптимизация кода, оптимизация рабочего времени, разработка игр, сериализация

Валидация ассетов в Unity3D - 1

Начнём с того, что я обожаю сериализацию в Unity. Она надёжна и очень проста в использовании. Я просто расширяю MonoBehaviour, ScriptableObject и подобные классы и настраиваю сериализуемые поля экземпляров в инспекторе.

Но у неё есть и слабости. Одна из них ― человеческий фактор. Представьте себе огромный проект, который живёт несколько лет и над которым работает около сотни человек. И любой из них может совершить ошибку: оставить пустую ссылку на объект, указать число вне диапазона, ввести строку в неверном формате, заполнить массив слишком маленьким или, наоборот, слишком большим количеством объектов. Уверен, у каждого из вас найдутся такие примеры из своего опыта. Причин и оправданий тоже множество: невнимательность, неожиданные последствия слияния веток, сбои редактора… И никто от этого не застрахован.

Такие ошибки до поры до времени остаются незаметными: компилятору до них нет дела, в отличие от опечаток в коде. Особенно неприятны они тем, что проявляются часто уже во время выполнения кода. Только тогда вы начинаете читать журнал сообщений и идёте проверять данные: тыкать их в редакторе или листать YAML. Но объектов может быть достаточно много, есть риск что-то пропустить или попросту залениться.

Конечно, можно добавить проверок в коде, но от этого он загрязнится. Иногда эти проверки негативно влияют на производительность. А ещё не всегда однозначно понятно, как именно обработать каждую конкретную ошибку.

Универсального или даже штатного метода бороться с подобным в Unity нет. Поэтому мы в Pixonic реализовали свою систему валидации ассетов. И это очень помогает нам жить.

Сейчас я опишу, как там всё устроено.
Читать полностью »

в 16:34, , рубрики: .net, C#, c#.net, docx, openxml, openxml sdk, xlsx, XML, конвертация, текст

Недавно мне пришлось столкнуться с необходимостью достать текст из офисных документов (docx, xlsx, rtf, doc, xls, odt и ods). Задача осложнялась требованием представить текст в формате xml без мусора с максимально удобной для дальнейшего парсинга структурой.

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

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

  1. Для платформы .Net не существует какого-либо готового решения для работы со всеми перечисленными форматами, что заставит нас местами кастылизовывать наш солюшн.
  2. Не пытайтесь в сети найти хороший мануал по работе с Microsoft OpenXML: чтобы разобраться с этой библиотекой придется изрядно покрасноглазить, покурить StackOverflow и поиграться с отладчиком.
  3. Да, мне все таки, удалось приручить дракона.

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

Работа с xlsx и docx

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

в 7:07, , рубрики: C#, Rust, аппликативы, длиннопост, монады, никто не читает теги, Программирование, Совершенный код, функторы, функциональное программирование

Монады как паттерн переиспользования кода - 1

В предыдущей статье мы обсуждали, почему функциональное программирование это совсем не то, что распиарено, и что оно совершенно не противоречит ООП, так, что даже сам Фаулер пишет про хороший ФП дизайн порождающий хороший ООП дизайн программы (и наоборот).

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

Но ведь в интернете буквально сотни статей про ФП и монады, зачем писать еще одну?

Дело в том, что все их (по крайней мере те что я читал) можно поделить условно на две категории: с одной стороны это статьи где вам объяснят что монада это моноид в категории эндофункторов, и что если монада T над неким топосом имеет правый сопряжённый, то категория T-алгебр над этой монадой — топос. На другой стороне располагаются статьи, где вам рассказывают, что монады — это коробки, в которых живут собачки. кошечки, и вот они из одних коробок перепрыгивают в другие, размножаются, исчезают… В итоге за горой аналогий понять что-то содержательное решительно невозможно.

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

Я же хотел бы занять промежуточную позицию, и рассказать про монады без заумных терминов, но и без котиков, используя понятные ООП разработчикам термины: интерфейсы, паттерны, копипаста, инкапсуляция сложности, бойлерплейт, и так далее. В процессе работы над статьёй ни один термин теории категории использован не был.

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

в 14:19, , рубрики: .net, C#, flutter, архитектура системы, мессенджер, Программирование, разработка мобильных приложений, сервер

Одним вечером, после очередного расстраивающего дня, наполненного попытками наладить баланс в своей игре, я решил, что мне срочно требуется отдых. Переключусь на другой проект, быстренько его сделаю, верну на место скатившуюся за время разработки игры самоооценку и с новыми силами возьму игру штурмом! Главное выбрать проект nice and relaxing… Написать свой месседжер? Ха! How hard can it be?

Код можно посмотреть здесь.

Как я свой мессенджер писал - 1 Как я свой мессенджер писал - 2

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

в 7:00, , рубрики: .net, .net interactive, .net notebooks, C#, F#, jupiter, microsoft, Блог компании Microsoft, Программирование

.NET Interactive уже здесь! | .NET Notebooks Preview 2 - 1

В ноябре 2019 мы анонсировали поодержку .NET для Jupyter notebooks с доступностью C# и F#. Сегодня мы рады объявить о выпуске Preview 2 .NET Notebook. В этой статье вы можете найти все основные новые функции этого выпуска. Присоединяйтесь!
Читать полностью »

1...10...192021...3040...137
Рейтинг@Mail.ru
Главная   |  Архив новостей  |   Android  |   Google  |   Apple  |   Microsoft  |   Информационная безопасность  |   Веб – разработка
Публикации RSS  |  Комментарии RSS
https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js