Соединение частей 3D моделей

Соединение частей 3D моделей

декабря 09, 2018   3D печать,

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

Читать

Мой способ организации портов ввода вывода на c++. Часть 2

Мой способ организации портов ввода вывода на c++. Часть 2

декабря 05, 2018   AVR, C++,

Предыдущая часть: Мой способ организации портов ввода вывода на c++. Часть 1

На данный момент функционал работы с портами довольно примитивен: есть возможность обработки либо целого порта, либо отдельного его бита. Хотелось бы иметь возможность объединить несколько бит разных портов и работать с ними как с единым целым. Например, объявив виртуальный порт как

using MySet = PortSet<PortA7, PortB1, PortA5, PortA4>;

выполнять все те операции, которые были описаны в предыдущей части: set, clear, write и т.п.

Читать

Мой способ организации портов ввода вывода на c++. Часть 1

Мой способ организации портов ввода вывода на c++. Часть 1

июня 30, 2018   AVR, C++,

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

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

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

Читать

Запуск CodeContracts на Visual Studio Team Services

Запуск CodeContracts на Visual Studio Team Services

апреля 21, 2016   C#, Code Contracts,

Этот пост появился не из ниоткуда. Однажды, я, активно использующий CodeContracts, все таки перевез свой блог (тот самый, который вы читаете) на Continuous Integration сервер. Мой выбор пал на Visual Studio Team Services. Ничего не предвещало беды до тех пор, пока безупречно выполняющиеся на моей локальной машине тесты проекта не стали падать с ужасающими ошибками при попытке их запуска на VSTS.

В результате небольшого проведенного расследования, удалось выяснить причину ошибок - предусловия библиотеки CodeContracts, а именно предусловия с заданным типом исключением Contract.Requires<TException>. Дело в том, что при использовании предусловий с заданным типом исключения, сборка не просто может, а должна быть переписана с помощью утилиты ccrewrite.

Разбираемся в причинах

Прежде всего найдем агента, выполняющего сборку на сервере <Ваш VSTS аккаунт>.visualstudio.com/_admin/_AgentPool: в списке его системных переменных нет упоминания CodeContracts

Как следствие, получаемая сборка при построении не подвергается переписыванию утилитой CodeContracts ccrewrite, поставляемой при установке CodeContracts. Значит, нужно установить CodeContracts на CI сервер, выполняющий сборку. Однако, как установить CodeContracts на неподконтрольную разработчику машину?

Создание локальной копии CodeContracts

Предоставим необходимые утилиты для работы CodeContracts рядом с исходными кодами через систему контроля версий По соглашению, все дополнительные утилиты будем располагать в директории Tools корня репозитория: Скопируйте содержимое установленных CodeContracts на вашей машине (по умолчанию C:\Program Files (x86)\Microsoft\Contracts) в директорию проекта Tools/CodeContracts.

Для работы CodeContracts на VSTS не обязательно копировать все содержимое установленных CodeContracts. Достаточно лишь утилит в каталоге Bin, файлов MsBuild для используемой версии и каталога Languages, однако, я предпочитаю иметь полноценную копию CodeContracts в репозитории с лицензией, примерами и документацией.

Пришла пора сделать коммит, включающий локальную копию CodeContracts, на удаленный сервер:

git add Tools/CodeContracts
git commit -m "CodeContracts"
git push

Прежде чем переходить к дальнейшим действиям, проверьте, что все содержимое CodeContracts было скопировано на сервер. Я практически уверен, что в удаленном репозитории отсутствуют файлы директории Tools/CodeContracts/Bin.

Если это так, добавьте в конец файла .gitignore строку !Tools/CodeContracts/Bin. Добавьте в индекс файлы этой директории и повторите коммит, на этот раз содержимое каталога должно успешно скопироваться на удаленный репозиторий.

Дело в том, что файл .gitignore, создаваемый Visual Studio по умолчанию, содержит исключение для каталога Bin, обычно содержащем результаты билдов, которым не место в системе контроля версий. Но в данном случае в этом каталоге содержатся необходимые для сборки утилиты, поэтому строкой !Tools/CodeContracts/Bin задается исключение из общего правила.

В результате удается в каком-то смысле установить CodeContracts на VSTS в виде локальной утилиты.

Дополнительная настройка

Если вы попробуете собрать сборку, результат будет, внезапно, абсолютно тем же самым - ошибка построения, Действительно, если бы CodeContracts были установлены "официально", инсталлятор CodeContracts добавил бы дополнительный шаг сборки, заключающийся в итоговом переписывании сборки утилитой ccrewrite, в процесс построения приложения. Поэтому придется добавлять шаг переписывания сборки через ccrewrite вручную.

Все действия, которые выполняет CodeContracts при сборке проектов описаны в файле Tools/CodeContracts/MsBuild/<Номер версии>/Microsoft.CodeContracts.targets Достаточно импортировать этот файл в файл файлы ваших проектов и CodeContracts наконец-то будут работать на VSTS. Файл проекта .csproj по сути - обычный xml файл, поэтому его легко можно изменить в вашем любимом текстовом редакторе. Добавьте перед закрывающим </Project> тегом строку следующего содержания:

<Import Project="$(SolutionDir)\Tools\CodeContracts\MSBuild\v$(MSBuildToolsVersion)\Microsoft.CodeContracts.targets" />

Наконец, нужно не забыть указать путь к локальной версии CodeContracts, поместив перед строками импорта установку переменных окружения:

<PropertyGroup>
  <CodeContractsInstallDir>$(SolutionDir)\Tools\CodeContracts\</CodeContractsInstallDir>
  <DontImportCodeContracts>True</DontImportCodeContracts>
</PropertyGroup>

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

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

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

Подводя итоги

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

1. Скопировать на удаленный репозиторий все необходимые для работы файлы (для данного случая - каталог с установленными CodeContracts);
2. Настроить файлы проектов: установка переменных окружения, добавление шагов сборки и т.п. (для CodeContracts - установка переменных окружения CodeContractsInstallDir и DontImportCodeContracts).

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

Читать

"Мутация" посетителя и dynamic

"Мутация" посетителя и dynamic

марта 15, 2016   Шаблон проектирования, C#,

Мы не можем игнорировать особенности окружающей нас инфрастуктуры, оказывающей влияние на, казалось бы, незыблемые паттерны проектирования, описанные более 20 лет назад и несомненно ставшими классическими. Возможности, предоставляемые платформой .NET, могут видоизменять и упрощать реализацию паттернов проектирования. Вспомните, как паттерн наблюдатель среди .NET программистов стал неразрывно связан с понятием событий, но в этом посте я хочу рассказать о другом паттерне, чрезвычайно полезном для решения некоторых задач (к примеру, обход синтаксического дерева) - посетителе, открывающемся с другой стороны благодаря новой в .NET 4 DLR и ключевому слову dynamic.

Классический посетитель

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

// Интерфейс посетителя
interface IFigureVisitor
{
 void Visit(Pawn pawn);

 void Visit(Knight knight);

 void Visit(Bishop bishop);
 ...
}

// Базовый класс для всех фигур. 
// Имеет метод Accept, необходимый для реализации посетителя
abstract class Figure 
{
 public abstract void Accept(IFigureVisitor visitor);
 ...
}

class Pawn : Figure
{
 public override void Accept(IFigureVisitor visitor) => visitor.Visit(this);
}

class Knight : Figure
{
 public override void Accept(IFigureVisitor visitor) => visitor.Visit(this);
}

class Bishop : Figure
{
 public override void Accept(IFigureVisitor visitor) => visitor.Visit(this);
}

// Использование:
// Во первых, реализация интерфейса посетителя,
сlass FigureVisitor : IFigureVisitor
{
 public void Visit(Pawn pawn) { ... }
 
 public void Visit(Knight knight) { ... }
 
 public void Visit(Bishop bishop) { ... }
}

// Во вторых, собственно, его использование
class ClassicVisitor
{
 public void Visit(IEnumerable<Figure> figures)
 {
  var visitor = new FigureVisitor();
  
  foreach (var figure in figures)
   figure.Accept(visitor);
 }
}

Ничего страшного, если вы не знакомы с новым C# 6.0 синтаксисом описания метода через лямбду void Accept(IFigureVisitor visitor) => visitor.Visit(this); - при первом знакомстве можно считать их просто удобным сокращением однострочных методов void Accept(IFigureVisitor visitor) { visitor.Visit(this); }

Dynamic посетитель

А сейчас предлагаю посмотреть на иной подход с использованием ключевого слова dynamic: cуть подхода заключается в том, что решение о вызове необходимого метода посетителя производится не самим объектом в виртуальном методе Accept, а внешним кодом, который приминает решение о выборе нужного метода посетителя в зависимости от типа объекта. Как следствие, отпадает необходимость наличия в иерархии типов метода Accept, что позволяет использовать такую версию посетителя в иерархиях классов (к примеру, XElement), не предоставляющих метод Accept.

// Базовый класс для всех фигур
// Теперь от иерархии не требуется наличие метода Accept
abstract class Figure { ... }

class Pawn : Figure { ... }

class Knight : Figure { ... }

class Bishop : Figure { ... }

// Реализации методов посетителя, которые ранее были в FigureVisitor
class DynamicVisitor
{
 public void Visit(IEnumerable<Figure> figures)
 {
  foreach (dynamic figure in figures)
   Visit(figure);
 }
 
 private void Visit(Pawn pawn) { ... }
 
 private void Visit(Knight knight) { ... }
 
 private void Visit(Bishop bishop) { ... }
}

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

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

Сравнение подходов

Следует иметь в виду, что, как обычно, и бывает в мире программирования, у обоих подходов есть как положительные, так и отрицательные стороны. К примеру, насколько разрушительным станет введение нового типа в иерархию типов? Классический посетитель во время компиляции потребует добавить в интерфейс посетителя новый метод, соответствующий новому добавленному типу. Отлично! Как мне кажется, найти ошибку на этапе компиляции - лучший из возможных исходов. Динамический посетитель в принципе не сможет отловить добавление нового типа во время компиляции из-за позднего связывания вызова методов посетителя. К тому же, во время исполнения, если DLR не сможет найти метод с нужной сигнатурой, она будет вынуждена бросить почти ничего не значащий RuntimeBinderException. Совсем нехорошо, но что поделать? К счастью, можно создать метод, который гарантированно вызовется при отсутвии метода с более подходящей сигнатурой:

class DynamicVisitor
{
 public void Visit(IEnumerable<Figure> figures) 
 { 
  foreach (dynamic figure in figures)
   Visit(figure);
 }
 
 private void Visit(Pawn pawn) { ... }
 
 private void Visit(Knight knight) { ... }
 
 private void Visit(Bishop bishop) { ... }
 
 private void Visit(Figure figure) 
 { 
  /* 
   * Действия по умолчанию, объекты новых типов иерархию попадут сюда, 
   * вместо выброса неприятного исключения 
   */
 }
}

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

class DynamicVisitor 
{
 public void Visit(IEnumerable<Figure> blackFigures, IEnumerable<Figure> whiteFigures) 
 { 
  foreach (dynamic blackFigure in blackFigures)
   foreach (dynamic whiteFigure in whiteFigures)
    Visit(blackFigure, whiteFigure);
 }
 
 private void Visit(Pawn pawn, Knight knight) { ... }
 
 private void Visit(Pawn pawn, Pawn pawn) { ... }
 
 private void Visit(Knight knight, Pawn pawn) { ... }
}

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

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

Хотя производительность и не является темой статьи, настоятельно рекомендую не говорить о проблемах производительности или утечках памяти без результатов профилирования.

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

Читать