C# *

Допустим, есть проект WPF/MVVM, в котором необходимо реализовать шаблон State Machine, позволяющий управлять поведением объекта (в данном случае, ViewModel) в зависимости от того состояния, в котором он находится. При этом необходимо получить простую реализацию этого шаблона без использования Windows Workflow Foundation, которая включала бы в себя классы состояний, класс реализующий логику переходов и таблицу переходов. И наряду с вопросами реализации этого шаблона стоит задача реализации инструмента, автоматизирующего процесс построения диаграммы состояний на основе таблицы переходов. При этом граф, построенный с помощью этого инструмента, должен отвечать следующим требованиям:

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

Недавно передо мной встала следующая задача: необходимо сравнить множество пар объектов. Но есть один нюанс: объекты — самые что ни на есть object'ы, а сравнивать нужно по всему набору публичных свойств. Причём совершенно необязательно, что типы сравниваемых объектов реализуют интерфейс IEquatable<T>.

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

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

В приложениях Windows Store жизненный цикл довольно похож на картинку. Он довольно простой и содержит всего 3 состояния: NotRunning – Running – Suspended

Для себя я мысленно отождествляю его с «Не копать – Копать – Перекур». Опытные работяги знают, что с перекура к работе можно уже не вернуться. Опытные разработчики сохраняют состояние приложения при событии Suspending и возвращают его впоследствии в исходное состояние при возобновлении работы приложения.

В приложениях Windows UWP (Windows 10) все точно так же, но появились новые фичи.

Дело было так… мне понадобился односторонний биндер. Только не от контрола к источнику, а наоборот. Я в коде сто тыщ раз меняю значение источника — и не хочу, чтоб голова болела о всяких там textbox'ах. Хочу, чтоб они сами обновлялись…

Вообще-то, у буржуев уже есть встроенный биндер, очень мощный и крутой. Настолько мощный и крутой, что почти без документации. Точнее, ее черезмерно много — и везде невнятно, нечетко. Короче, плюнул я на буржуйские технологии и решил ВОТ ЭТИМИ РУКАМИ запилить свой биндер… Теперь вот показываю новичкам — наверно, кому-то пригодиться для расширения С#-кругозора.

До конференции DotNext 2015 Moscow осталось полтора месяца. Сейчас у нас горячая пора — отбор докладов, конкурсные прослушивания по скайпу и вживую. Скайповский чатик программного комитета постоянно сыплет в меня нотификациями — только успевай отвечать. Работа по входящим заявкам на доклады, если честно, сильно напоминает одно известное шоу — четыре члена программного комитета пытаются по тексту анонса понять, стоящий перед ними спикер или нет, хороший доклад или слабый.



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

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

---

Ниже я немного расскажу о тех докладах и докладчиках, которые уже на сегодня приняты в программу конференции.

Данная информация будет полезна тем, кто только разбирается с C#, на практике пытаясь понять теорию, не читая предварительно книжек до конца. Это скорее всего заметка на полях, а не подробное описание и анализ темы. Итак, кому интересно как ведут себя структуры в памяти при работе с коллекциями в C#, добро пожаловать.

Думаю, многие C# разработчики с нетерпением ждали в C# 6.0 появления первичных конструкторов и record'ов и были огорчены тем, что эта фича была отложена до 7-й версии. Под конец рабочего четверга желание иметь неизменяемые типы во что бы то ни стало пересилило во мне терпение и я решил написать утилиту, генерирующую их. Кому интересно — прошу под кат.

В этой статье я расскажу вам о Xamarin.UITest — фреймворке для приемочного UI тестирования от Xamarin.

Что это такое и как его готовить

Xamarin.UITest сделан на основе Calabash и имеет сходный с ним принцип работы. Однако, тесты на данном фреймворке пишутся на С# и NUnit (в отличие от Calabash, в котором используется Gherkin+Ruby). Фреймворк кроссплатформенный и, следовательно, он позволяет писать тесты как для платформы iOS, так и для Android. Windows Phone не поддерживается, что я лично считаю недостатком данного инструмента. Зато в нем вполне поддерживается тестирование нативных приложений на Java и Objective-C.

При работе с SharePoint часто возникает необходимость сделать свое собственное поле для каких-либо специфических задач. Одна из таких задач — возможность проверки текстовых полей, например на правильность заполнения Email или каких-либо данных об Организации: ИНН, КПП и д.р.

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

Хочу поделиться нашим opensource-решением для генерации docx документов, которое позволяет заполнять документы по шаблону, оформление которого можно менять в Word без переписывания кода.

Для начала — немного вводных.

Что нам было нужно от шаблонизатора

• Шаблон создается в Word и сразу видно, на что будет похож результирующий документ, шаблон без лишнего мусора.
• Результирующий документ после скачивания содержит все необходимые данные, не подтягивая их с внешних источников.
• Возможность заполнять списки, таблицы, и иногда еще и таблицы с вложенными в них списками.
• Шаблон можно доверить секретарю клиента, чтобы он мог сменить логотип, реквизиты компании, или как-либо еще подкорректировать оформление. И все это уже после сдачи проекта, не модифицируя наш код.

Наверняка вы уже знаете об операторе безопасной навигации ("?." операторе) в C# 6. В то время как это довольно хороший синтаксический сахар, я хотел бы отметить варианты злоупотребления этим оператором.

После перехода на Visual Studio 2015 столкнулся с неприятным и довольно критичным отличием в компиляции одного и того же кода старой версией студии и новой.

Суть его состоит в том, что при генерации дерева выражений Visual Studio 2015 немного по другому генерирует результат, а именно вставляет операнд Convert() для явного приведения типов, которые могут в общем-то приводиться неявно.

Cколько времени я использую GitFlow и Semantic Versioning, меня все не покидает чувство, что чего-то в них не хватает. Обе концепции хороши, но так как они предлагают решения для проблем из разных областей, их совместное использование выглядит сложнее, чем должно быть.

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

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

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

Для начала, хотелось бы напомнить, каким образом можно было создавать универсальные приложения в Windows 8.1. Создавалось решение с тремя проектами: для телефона, для Windows 8.1 и проект с общим кодом. А как теперь в Windows 10? Сейчас расскажу.

Здравствуйте! Вас приветствует редакция сайта GeekBrains.ru, сервиса онлайн-обучения программированию. Мы решили завести блог на Хабре! Уверены, что ещё успеем рассказать и обсудить много интересного из мира программирования, ИТ и онлайн-образования. Но начнём очень просто, без особых прелюдий, с обзора бесплатного курса по основам C# и ООП от одного из наших учеников. Слоган курса гласит «Сложная концепция простыми словами». Давайте же посмотрим, насколько это соответствует действительности.

Ссылка на первую статью из этой серии.

Быстрое вступление

Я долго думал какую тему выбрать на этот раз, и решил, что расскажу про некоторые фишки, которые помогут оптимизировать вашу игру. Особенно это будет актуально для новичков, потому что чаще всего первая игра оказывается игрой для смартфонов и планшетов. А на мобилках, сколько бы там ядер не оказывалось — 6 или 8, игры все ещё очень несбалансированные в плане потребления ресурсов. Код и его идея, которые будут приводится в этой статье являются немного более сложными для понимания чем те две строчки кода, которые я приводил в своей предыдущей публикации. Хотя, я не правильно выразился — код легко понять — но порог вхождения в это понимание будет чуть выше чем легко (для новичков конечно), придется посидеть минут 5.

Введение в идею

Как вы создаете объекты в Unity из префабов? Только Instantiate и никак иначе — другой функции там просто не существует.

Для тех кто не помнит или еще не знает, что такое Instantiate (), маленькая справка — *аргументы инстанции*. Вот вы их создаете (объекты), и создаете, иногда удаляете, потом опять создаете, и так в течении всего уровня. Это бьёт по оптимизации и существенно — почему? Потому что так написано на всех форумах Unity, а иногда проглядывается и в документации, а документацию надо слушаться. Как Instantiate бьет по про производительности?

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

Тестирование с помощью SpecFlow прочно вошло в мою жизнь, в список необходимых технологий для «хорошего проекта». Более того, несмотря на ориентированность SpecFlow на behaviour тесты, я пришел к мысли, что и integration и даже unit тесты могут получить преимущества этого подхода. Конечно, в написании таких тестов уже не будут участвовать люди из BA и QA, а только сами разработчики. Разумеется, что для небольших тестов это привносит немалый оверхэд. Но насколько же приятнее читать человеческое описание теста, нежели голый код.