Добрый день! Не так давно прошла серия семинаров CLRium по новейшим технологиям и редко-раскрываемым темам CLRium #2. Мы собрали у себя в залах около 740 человек, что для нас является — фантастическим результатом. Сегодня хотелось представить вам свежие видеозаписи семинара и ссылки на репозитории спикеров:

День 1:

Ссылки с привязкой ко времени:

• Андрей Акиньшин — с самого начала
• Станислав Сидристый — .NET objects in Shared Memory

Общее представление о том, что такое WPF Layout System, можно получить из msdn (1, 2). Там написано, что элементы управления образуют Visual-дерево, что каждый из элементов управления имеет свой определенный прямоугольник, в рамках которого он отрисовывается, что определение этих прямоугольников возлагается на Layout System и выполняется в 2 этапа (measure и arrange) и что WPF — это retained mode graphic system, в отличие от обычных Immediate и в чем преимущества такого подхода.

Однако при чтении msdn возникает ряд вопросов, на которые в документации ответов нет, и можно только догадываться о том, что происходит. Например — что произойдет, если какой-либо дочерний контрол в measure-стадии запросит для себя размер, превышающий переданный ему availableSize? Или — как при необходимости реализовать методы MeasureOverride и ArrangeOverride правильно, чтобы написанный код не противоречил принятым соглашениям о том, как должны выполняться этапы Measure и Arrange ? Влияет ли результат, полученный на этапе Measure, на этап Arrange и отрисовку, или же на отрисовку влияет только вызов Arrange, а Measure — чисто информационный этап?

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

Информация о том, что Windows 10 собирает данные о пользователях, не нова. Еще в 2014 году компания Microsoft опубликовала заявление о конфиденциальности, из которого следует, что на ее серверы может передаваться информация об использованных программах, устройстве и сетях, в которых они работают. Эти данные могут объединяться с идентификатором пользователя (учетная запись Microsoft), также собирается информация об адресе электронной почты, предпочтениях, интересах местоположении, и многом другом.

Чешское издание Aeronet.cz опубликовало расследование неназванного ИТ-специалиста, который решил отследить активность Windows 10 по сбору данных. В ходе исследования использовались следующие инструменты: программа Destroy Windows 10 Spying, блокирующая передачу данных на серверы Microsoft, PRTG Network Monitor, Windows Resource Monitor и Wireshark. По мнению исследователя, Windows 10 — больше похожа на терминал по сбору данных, чем на операционную систему.

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

В связи с этим стал актуальным вопрос о выборе удобного инструмента для создания и подготовки таких постов. SeptiM предложил скрипт, преобразующий маркдаун-разметку + латех в html-код. Я решил развить идею и упростить инструмент, и сделал для этих же целей онлайн-редактор с поддержкой латеха и маркдауна:

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

И помогают мне в этом 3 команды:
netsh wlan set hostednetwork mode=allow
netsh wlan set hostednetwork mode=allow ssid=FastWifi key=12345678 keyUsage=persistent
netsh wlan start hostednetwork

Под катом я детально расскажу как и что нужно делать и покажу на примере настройки Windows 7.

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

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

Я бы хотел обсудить подводные камни, которые наиболее часто встречаются при работе с фичей async/await в C#, а также написать про то, как их можно обойти.

Требования

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

• самозацикленные графы объектов (деревья с back-references)
• массивы структур (value types)
• классы/структуры с readonly полями
• инстансы существующих .Net коллекций (Dictionary, List), которые внутренне используют custom-сериализацию
• большое кол-во инстансов типов, специализированных для конкретной задачи

Речь пойдёт о трёх аспектах, которые очень важны в распределённых кластерных системах:

• скорость сериализации/десериализации
• объём объектов в сериализированном виде
• возможность использовать существующие объекты без надобности “украшения” этих объектов и их полей вспомогательными атрибутами для сериализации

Структура публикации

• Получение кватерниона из вектора и величины угла разворота
• Обратный кватернион
• Умножение кватернионов
• Поворот вектора
• Рысканье, тангаж, крен
• Серия поворотов

Получение кватерниона из вектора и величины угла разворота

Ещё раз – что такое кватернион? Для разработчика – это прежде всего инструмент, описывающий действие – поворот вокруг оси на заданный угол:

(w, vx, vy, vz),

где v – ось, выраженная вектором;
w – компонента, описывающая поворот (косинус половины угла).

Пожалуй, любой разработчик WPF знает о механизме Attached Property, но многие даже не слышали о Behavior. Хотя эти механизмы и имеют схожие функциональные возможности, они, все же, имеют совершенно разную смысловую нагрузку, и очень важно правильно различать их и использовать.

Давайте вспомним, что из себя представляют эти механизмы:

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

Нам понадобятся некоторые знания из прошлых статей, в частности, понимание принципа прямых инжекций.

Недавно мы уже узнали о принципе прямых инжекции и эффективном связывании вью-моделей с представлениями, а также о том, каким образом создавать расширения привязки. Продолжим исследование библиотеки Aero Framework и рассмотрим ещё один архитектурный вопрос.

Навигация между представлениями (экранами) в xaml-ориентированных приложениях довольно важная и интересная задача. Особенно это касается её реализации в рамках паттерна MVVM. В идеале вью-модели не должны содержать никаких прямых ссылок на представления, чтобы быть кросс-платформенными и сохранялась возможность повторного их использования в нескольких проектах. Сегодня мы узнаем, как этого достичь.

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

На практике часто встречается следующая задача: связать вью-модель, которая хранится в unity-контейнере, с одним или несколькими её представлениями (экранами). Обычно такое связывание происходит в бехаинд-коде, в результате чего у представления устанавливается нужное значение в свойство DataContext.

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

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

Краеугольным камнем разработки приложений для Windows (WPF, SilverLight, WP, WinRT) является паттерн MVVM. Который основан на концепции связывания данных модели представления и пользовательского интерфейса, что позволяет, используя декларативное описание UI посредством XAML избавится от codebehind (так я и не придумал/нашел русского перевода) и перенести всю логику работы с пользовательским интерфейсом в модель представления.

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

Написать данную статью меня побудила статья «Автоматическое выделение ссылок в универсальных приложениях Windows». В статье найдено решение конкретной проблемы и предложено работающее решение. Однако для его использования необходимо в codebehind для каждого текстового блока вызывать код. Более того если данные предполагают изменение в процессе работы необходимо следить за их изменением. В процессе своей работы такие решения встречаю довольно часто, они отличаются реализацией, но их все отличает одно неизменное свойство, сложность поддержки и сопровождения кода.

Продолжая тему JIT-компиляции .NET'a, сегодня мы рассмотрим диспетчеризацию методов у интерфейсов, generics (как классов, так и отдельных методов вместе с реальными сигнатурами); производить отладку релизных сборок с оптимизациями; разберемся с истинным предназначением типа System.__Canon (это не то, что Вы подумали).

Тема рантайма платформы .NET освещена весьма подробно. Однако работа самого JIT, результирующий код и взаимодействие со средой исполнения – не очень.

Ну что ж, исправим это!

Узнаем причины отсутствия наследования у структур, природу unbound delegates.

А еще… вызов любых методов у любых объектов без reflection.

Чтобы научиться дизайну, мы записались на курс Design 101 от trydesignlab.com. Первые уроки были посвящены визуальной иерархии. Мы перевели одну из лучших статей на эту тему от 99designs.com.



Перевод от сайта для начинающих предпринимателей «Я люблю ИП»

---

Official translation (with a bit of polishing) is available here.

---

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

Модель освещения Фонга — классический пример локального выбора:



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

Добрый день, уважаемые разработчики (просто не знал, с чего начать пост). Предлагаю перед тем как начнется трудовая неделя немного подразмять мозги (совсем немного) и построить свой Small Objects Heap для .Net. Вернее даже не Small Objects Heap, а Custom Objects Heap.

Как все мы знаем, в .Net существует две группы куч: для больших и малых объектов. Как выяснить, во сколько нам обойдется объект можно при помощи кода из этой статьи (он нам пригодится): Ручное клонирование потока, а получить указатель на объект и по указателю получить сам объект можно научиться, прочтя эту статью: Получение указателя на объект .Net. Также нам понадобится статья корейского (южно-) программиста по перенаправлению указателя на скомпилированную часть метода на другой метод: 실행 시에 메서드 가로채기 — CLR Injection: Runtime Method Replacer 개선

Так что давайте поэкспериментируем и напишем библиотеку, которая позволит:

• Аллоцировать участок памяти
• Разметить его как набор объектов определенного .Net типа
• Выделять объекты с этой памяти
• Возвращать их обратно

Ссылка на проект на GitHub: DotNetEx

Ссылка на проект в GitHub: DotNetEx

На множественных ресурсах время от времени задается вопрос. Можно ли сделать отгружаемые сборки с текущего домена? Так, чтобы попользовался и «давай, до свидания!»? Везде и всегда ответ, который давался – это «нет». Ведь единственное, что можно выгрузить – это домен. Соответственно, если хочется наладить отгрузку, сборку надо помещать в домен, и налаживать между доменами взаимодействие через сериализуемые типы. А это — очень медленное взаимодействие. А мы скажем так. Можно. С ньюансами. Загружать мы будем также в отдельный домен. Но отменим сериализацию при вызове методов между доменами.

Вопросы, которые мы будем решать:

• Создание домена с возможностью отдачи объекта из домена в родительский
• Выгрузка сборки