C# *

Все мы знаем, что юнит-тесты — это классно, что только коду, который так или иначе покрыт тестами, можно доверять и что если какой-нибудь неопытный senior developer старший программист что-нибудь сломает, тесты это сразу же покажут.

Тем не менее, написание тестов сложно назвать увлекательным процессом. Инициализация тестовых данных, инициализация моков, создание объекта тестирования… Пока доберешься до вызова метода, который ты собственно хотел проверить, тестировать уже и не хочется ничего. Я конечно утрирую, юнит-тест по своей природе не должен брать на себя слишком много и содержать пару сотен десятков строк инициализации (хотя и такое бывает), однако писать один и тот же код быстро надоедает. И вот уже появляются фабрики тестовых объектов, иерархия базовых классов для тестов и прочие ООП примочки, призванные «упростить» создание теста. Приводит это как правило к тому, что шансов быстро понять, что же делает тест, не путешествуя по этим самым объектам, практически не остается.

Собственно, инструмент, о котором я хочу рассказать, как раз и призван упростить, а в некоторых случаях и полностью убрать фазу инициализации или Arrange фазу теста.

Сегодня я хочу рассказать о том, как можно централизованно управлять настройками ReSharper на уровне команды разработчиков. Под настройками я понимаю настройки форматтера, Live Templates и настройки ReSharper. Они могут быть экспортированы и упакованы в так называемые Declarative Extensions.

В сети уже есть довольно немало сравнений Entity Framework и NHibernate, но все они по большей части фокусируются на технической стороне вопроса. В этой статье я бы хотел сравнить эти две технологии с точки зрения Domain Driven Design (DDD). Мы рассмотрим несколько примеров кода и увидим как эти две ORM позволяют нам справляться со сложностями.

Эстафета из 100 языков программирования

Квайн — компьютерная программа, которая выдаёт на выходе точную копию своего исходного текста. Цепной квайн отличается от обычного тем, что на каждой последующей итерации выводится код на другом языке программирования, до тех пор, пока не выведется код оригинального квайна. В середине 2013 года японский программист Юсукэ Эндо (遠藤 侑介) разработал цепной квайн, содержащий 50 языков программирования. В конце 2014 кода он опубликовал новую версию, включающую уже 100 языков!

Исходники и информация о компиляции всех этих квайнов есть на гитхабе: quine-relay. Любопытно, что исходный код в виде картинки был написан не в ручную (что невозможно в принципе), а сгенерирован. Автор отмечает, что в течении года он опубликует книгу про обфусцированное программирование, которая будет включать в себя подробное объяснение о том, как писать квайны, ascii-art квайны, цепные квайны (подобные этой эстафете).

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

На C# я пишу редко, и в основном все наши приложения и сервисы подключаются к источнику данных, используя MSSQL сервер или службы баз данных. И вот настало время написать приложение, используя не сервер, а локальную БД. Немного погуглив, я внезапно выбрал SQLite.

Предисловие

У всех наших заказчиков были требования к коду:

• установленное именование переменных;
• группировка кода (конструкторы, переменные, методы, события...);
• табы и форматирование (каралось смертной казнью);
• за самописные SQL запросы разработчик удалялся из команды.

Исходя из вышеперечисленного, для баз данных конечно же были использованы классы LINQ to SQL, связанные с реляционными объектами.

Несколько дней назад вышла новая бета-версия ASP.NET 5 — beta5. Оказалось, что в новой версии довольно много нововведений и мигрировать с предыдущей бета-версии не так уже просто. Рассмотрим главные новшества и как модернизировать стандартный шаблон ASP.NET 5 проекта с Visual Studio чтобы полностью перейти на новую версию.
+ сорсы
+ тест на базе статьи
+ видео последнего ASP.NET Community Standup

Пока все прогрессивные разработчики предвкушают выход Windows 10 и готовятся разрабатывать приложения под нее, я, после сдачи теста 70-485, хочу поделиться с вами углубленными возможностями разработки приложений под Windows 8 и 8.1. Благо, у разработки по 10 и под 8.1 очень много общего. Эта статья по задумке должна помочь вам сдать экзамен 70-485, но может быть интересна в любом случае, если вы разрабатываете приложения Windows Store. Она содержит в себе некоторые must know сниппеты, описание возможностей и классов WinRT, а также некоторые моменты, по которым могут быть заданы каверзные вопросы.
Под катом обо всем понемногу. Так как все охватить невозможно, получилась своеобразная памятка.

Предыстория

А ведь много, много пишут на Entity Framework. Фактически, это ORM «по умолчанию» для .NET и среды Microsoft Visual Studio…

Так, однажды, не очень давно, попал в мои руки один немаленький проект. Ко времени моего появления, проекту было примерно три года. В техническом отношении он представлял собой душераздирающее зрелище. Грубый замер показал, что веб-приложение легко и совершенно неоправданно умудрялось потреблять около 1ГБ серверной памяти на одновременного пользователя. Пришлось быстро-быстро разбираться, чего же там такого интересного написано. Хороший урок, как делать не надо.

В этом проекте для доступа к данным в реляционной БД применялся Entity Framework. Кроме очевидных архитектурных и программистских глупостей, навроде ToList() по любому поводу, Include чему попало, наложения ограничений на множества объектов не на уровне БД, а на уровне приложения с использованием LINQ To Objects, были и проблемы, связанные только с Entity Framework.

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

Всем привет!
В первой статье мы рассказали о нашей инфраструктуре в целом. Теперь пришло время сосредоточиться на конкретных продуктах. В этой статье речь пойдёт о DSP. Как многие знают, DSP (Demand Side Platform) — автоматизированная система покупки рекламы. Требования к системе жёсткие: она должна держать высокую нагрузку (тысячи запросов в секунду), быстро отвечать (до 50 мс, а то и меньше) и, самое главное, выбирать максимально подходящие объявления. Чаще всего такие проекты разрабатываются под Linux, мы же смогли создать по-настоящему высокопроизводительный сервис под Windows Server. Как этого добиться, и как это удалось нам? Об этом я и расскажу.

Вступление

Добрый день, уважаемые читатели! Не так давно передо мной встала задача реализовать несложный графический редактор под Windows, при этом в перспективе он должен поддерживать как двухмерную, так и трёхмерную графику. Задача непростая, особенно если учесть, что наряду с окном просмотра результата рисования непременно должен быть качественный интерфейс пользователя. После некоторых раздумий были выделены два инструмента: Qt и WPF. Технология Qt может похвастаться хорошим API и неплохой поддержкой OpenGL. Однако она обладает и рядом недостатков, с которыми сложно мириться. Во-первых, большое приложение на Qt Widgets выйдет довольно дорогим в обслуживании, а в Qt Quick тяжело интегрировать графику. Во-вторых, в OpenGL нет развитого интерфейса для двухмерного рисования. Таким образом, я остановился на WPF. Здесь меня всё устраивало: мощные инструменты создания GUI, язык программирования C# и большой опыт работы с этой технологией. К тому же было принято решение использовать Direct3D и Direct2D для рисования. Осталась всего одна проблема — нужно было разместить результаты рендеринга, выполненного на C++, в окне WPF. Эта статья посвящена решению данной проблемы. Итак, вот план руководства:

1. Разработка компонента просмотра рендеринга на C#
2. Создание примера проекта с использованием DirectX на C++
3. Вывод результата рисования в окне WPF

Не будем терять времени и немедленно приступим к работе.

Предысторию создания данного «продукта» можно проследить по постам на Хабре (последний, посвященный выпуску версии 1.0, находится здесь).

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

На сегодняшний день «ЭкаунтоЛогика» (новое обрусевшее название «Учетная Логика») позволяет – по крайней мере, должна позволять согласно спецификации – достаточно многое.



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

Добрый день! Одним прекрасным днем мы обнаружили, что наш MSBuild деплой проект не хочет работать в новой среде: для создания и управления сайтами и пулами он использовал MSBuild.ExtensionPack. Падали ошибки, связанные с недоступностью DCOM. Среду менять было нельзя, поэтому кстати пришлась возможность написания собственных задач для MSBuild: msdn.microsoft.com/en-us/library/t9883dzc.aspx, было принято решения написать свои, которые работали бы через WMI (доступный на среде) Кому интересно, что получилось, прошу под кат.

Привет, Хабр! Тема async/await в .NET Framework и C# 5.0 не нова и объезженна: все давно знают, что это, как оно работает, все знакомы с тем скромным фактом, что это очень текучая абстракция и поведение зависит от SynchronizationContext. Об этом очень много писали на хабре, ещё чаще этот вопрос размусоливался в блогах различных респектабельных персон .NET-сообщества.

Тем не менее, мне очень часто приходится сталкиваться с тем, что не только новички, но и матёрые тимлиды не совсем понимают, как правильно пользоваться этим инструментом в разработке.

Что такое NDepend уже было рассказано на хабре — это статический анализатор кода на .NET'е. Недавно вышла новая — 6-я версия этой замечательной утилиты, о новых возможностях которой рассказывается ниже. Это перевод, оригинальная статья здесь.

Каждый разработчик Windows Store приложений должен знать гайдлайны.
Guideline в переводе с английского — рекомендации, руководящие указания. Для того, чтобы приложение попало в Store не обязательно следовать рекомендациям, но следовать им желательно. Есть несколько особенностей, или иноземно выражаясь фич (англ. feature), которые желательно иметь каждому приложению. Я решил рассмотреть эти особенности, а заодно сделать шаблон C#/XAML приложения Windows Store, с которого можно начинать разработку. Ведь, так или иначе, часто приходится заходить в разработанные ранее приложения или MSDN, чтобы скопировать код сниппета для определенной функции.
Описанные далее возможности не только сделают ваше приложение соответствующим гайдлайнам, но и украсят его дополнительным функционалом, привлекающим внимание пользователей, а также помогут в продвижении.

Здравствуйте! Наш проект уже достиг такой стадии когда встал вопрос об оптимизации производительности. После анализа слабых мест, одно из возможных путей для оптимизации был способ избавления от AutoMapper’а, он хоть и не является самым тормозным местом, но является тем местом, которое мы можем улучшить. AutoMapper используется у нас для маппинга DO объектов в DTO объекты для передачи через WCF сервис. Вручную написанный метод с созданием нового объекта и копированием полей работает быстрее. Писали маппинг вручную — безрадостная рутина, часто были ошибки, забытые поля, забытые новые поля, поэтому решили написать генерацию маппинга через t4 шаблоны.

По сути нам надо было сверить список пропертей и типов, и написать копирование, но не всё так гладко в датском королевстве.

Предлагаю всем размять мозг после выходных и начать рабочую неделю с простых, на первый взгляд, задачек по программированию на C#. Возможно эти задачи заставят вас посмотреть на код своих проектов с новой стороны, так как все они касаются сумрачной области – области безопасности приложений, Application Security. Про AppSec и платформу .NET пишут не много, говорят еще меньше, некоторые вообще считают, что использование любого managed языка, магическим образом делает приложение защищенным. Это положение дел я пытаюсь исправить, рассказывая на конференциях про различные аспекты безопасности .NET платформы. Так на этой недели, в четверг, наше сообщество SPB .NET Community проводит митап в Санкт-Петербурге полностью посвящённый вопросам разработки защищённых ASP .NET приложений. Кому интересны подробности этой встречи, кто хочет узнать побольше о сообществе .NET разработчиков Санкт-Петербурга и попробовать свои силы в решении задач по AppSec .NET, приглашаю под кат!

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

База данных пациентов в клинике уже была, написана она была еще в далеком 1998 году в Microsoft Access того времени (причем даже с красивым пользовательским интерфейсом), но вот работала она только в одном месте — на компьютере заведующего, да еще и поддерживать ее стало совершенно невозможно. Значит, давно назрела необходимость внедрять что-то новое!

Сказано — сделано. Работать надо было быстро (все-таки сдавать курсовую пора) и при этом хотелось сделать работу максимально интересной для себя. Я давно хотел разобраться с ASP.NET MVC, был немного знаком с C# и общими принципами MVC, поэтому скачал последнюю Visual Studio 2015 RC и принялся за работу.

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

Статья 1. Почему я не преподаю SOLID

Если вы разговариваете с кем-то, кому небезразлично качество кода, уже достаточно скоро в разговоре всплывёт SOLID — аббревиатура, помогающая разработчикам запомнить пять важных принципов объектно-ориентированного программирования:

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

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

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