Рубрика «.net» - 114

Мы выпускаем новый продукт — CodeRush for Roslyn https://www.devexpress.com/Products/CodeRush/coderush-for-roslyn.xml (далее CRR).

CodeRush for Roslyn: Part 2 — обзор фич для лучшего кода - 1

В этой статье пойдет речь пойдет о фичах CRR, которые помогают улучшать качество кода:

  • статический анализ(Static Analysis);
  • проверка орфографии(Spell Checker);
  • проверка именования(Naming Conventions);
  • анализ покрытия кода тестами(Test Coverage).

Все примеры в статье сделаны в Visual Studio 2015 на исходниках проекта OpenCover.
Читать полностью »

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

Picture 1

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

Как должна выглядеть .NET-конференция в 2016-м, когда в .NET-мире происходит тектонический сдвиг? Очевидно, что (ASP).NET Core очень сильно скажется на жизни разработчиков, но для большинства из них это произойдёт лишь спустя ощутимое время. О чём в таком случае рассказывать — масштабных новшествах, которые станут актуальны позже, или более привычных темах, которые важны здесь и сейчас?

Петербургский «Летний фестиваль разработчиков», состоящий из трёх конференций подряд, начался с DotNext 2016. Как там была разрешена возникшая дилемма, и как вообще прошёл DotNext? По снимку команды организаторов видно, что при всей хардкорности мероприятие не обошлось без летнего настроения, а все остальные подробности — под катом.

DotNext 2016: Между настоящим и будущим - 1

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

C# — есть ли что-то лишнее? - 1Все будет быстро. Это выступление Анатолия Левенчука, в последнее время не дает мне покоя. Успехи глубинного обучения в последний год говорят о том, что все очень быстро изменится. Слишком долго кричали волки-волки говорили «искусственный интеллект», а его все не было. И вот, когда он, наконец, приходит к нам, многие люди этого просто не осознают, думая, что все закончится очередной победой компьютера в очередной интеллектуальной игре. Очень многие люди, если не все человечество, окажется за бортом прогресса. И этот процесс уже запущен. Думаю, что в этот момент меня не очень будет интересовать вопрос, который вынесен в заголовок статьи. Но, пока этот момент еще не настал, попытаюсь поднять этот потенциально спорный вопрос.

Программируя уже более 25 лет, застал достаточно много различных концепций, что-то смог попробовать, еще больше не успел. Сейчас с интересом наблюдаю за языком Go, который можно отнести к продолжателям “линейки языков Вирта” — Algol-Pascal-Modula-Oberon. Одним из замечательных свойств этой цепочки является то, что каждый последующий язык становится проще предыдущего, но не менее мощным и выразительным.

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

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

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

Мы выпускаем новый продукт — CodeRush for Roslyn, далее CRR. Уже более 10 лет у нас есть другой продукт, который называется просто CodeRush, или CodeRush Classic, сокращенно CRC. Главное отличие  CRR от CRC в том, что Roslyn версия использует парсинг и языковые сервисы  встроенные в Visual Studio. CRR полностью написан с нуля, поэтому он быстрый и легкий, и уже содержит все необходимое для эффективной работы.
В этой статье расскажу о поддержке тестовых фреймворков в CRR. Почти во всех примерах будет использован проект https://github.com/dewe/Money. Этот проект использует NUnit framework, но мы так же поддерживаем xUniut, MSpec, MS Test Framework. Все рассмотренные ниже практики работают одинаково вне зависимости от того, какой тестовый фреймворк вы используете.
Читать полностью »

WG API предоставляет очень подробное описание API, но при этом не предоставляет никаких библиотек для доступа к API. К сожалению API не использует никакие из стандартов, которые могли бы автоматически сгенерировать модели и методы. Кроме того, в JSON ответах не получилось сгенерировать модели из за особенностей структуры ответа. В итоге оказалось, что проще написать модели (и тем более методы) вручную, но это занятие оказалось очень рутинным и скучным. В статье рассмотрим автоматизацию создания модели и методов запроса из описания HTML, а также полученные преимущества и недостатки.
Читать полностью »

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

Самоконфигурирующиеся приложения - 1
Фотку взял с Yaplakal
Читать полностью »

В этой статья мне хотелось бы рассказать о том, как была ускорена отрисовка монстров при создании игры Alien Massacre. Данное решение подойдет для любых проектов, которые испольуют спрайтовую анимацию.

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

  • 1 Необходимо обеспечить отрисовку большого числа анимированных объектов на сцене. Ведь мы хотим, чтобы игрок отстреливался от полчищ монстров.
  • 2 Прогресс анимации должен быть различен для каждого из объектов. Ведь мы не хотим, чтобы мобы ходили строем.

Решение «из коробки»

Безусловно, первое решение было простым: все сделать с помощью уже встроенного в UnityEngine компонента Animator. Посмотрим, что из этого получается.
Читать полностью »

Практически любой .NET разработчик так или иначе использует в своей практике технологию Linq. Linq позволяет писать красивый и лаконичный код для получения объектов из источника данных с возможностью определения критериев получения и/или трансформации запрошенных объектов «на лету». Поддержка Linq присутствует практически во всех популярных ORM-фреймворках, в том числе и в NHibernate. NHibernate предоставляет Linq-провайдер, с помощью которого мы можем написать запрос на этапе разработки (Design-Time), но для того, чтобы составить запрос в runtime, придется повозиться с Reflection. Однако, если возникнет потребность в формировании запроса во внешнем процессе, например, в клиентской части сервиса, то в таком случае Reflection уже не спасет, клиентская часть, как правило, не знает (и не должна ничего знать) про серверный ORM.
Ниже мы разберем как создать API для написания Linq запросов к NHibernate в ситуации, когда запрос пишется в одном процессе, а выполняется в другом. Также, реализуем собственный IQueryProvider, который будет транслировать запросы из приложения-источника в исполняющее приложение.
Читать полностью »

В далеком 2012, когда цена на нефть еще была трехзначной, а трава зеленее, майкрософтом был выпущен .NET 4.5, а с ним и конструкция async/await. Про неё написано уже довольно много статей (Async в C#), а большинство разработчиков C# хорошо её изучили. Но все ли варианты использования были рассмотрены, можно ли выжать из await немного больше?

Самым очевидным вариантом использованием этой конструкции является ожидание завершения некой асинхронной операции. Первое, что приходит на ум — это ожидание ввода-вывода. Например, мы послали запрос клиенту и ожидаем ответа, тогда используя await мы сможем продолжить выполнение кода после получения ответа, а сам код при этом будет выглядеть синхронным. Но что если во время ожидания возникнет необходимость прервать выполнение этой операции? Тогда нам придется использовать CancellationToken, причем если таких операций несколько, то токены необходимо будет линковать или использовать один общий токен. При этом причина отмены будет скрыта от кода, использующего этот CancellationToken. Кроме отмены, код должен поддерживать обработку потери соединения, таймаута, возвращаемых ошибок и т.д.

В классическом варианте это выльется в использование CancellationToken для обработки отмены, try catch для обработки разрыва соединения и код анализа возвращенных данных, для оценки результата запроса. Но можно ли уместить всё это в единой парадигме? В этот статье я предлагаю рассмотреть альтернативный подход, основанный на событийной модели с использованием синтаксического сахара async/await.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js