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

public class Example
{
  private int JustInt;

  // Some code here

  public void DoSomething(Example example)
  {
    this.JustInt = example.JustInt; // Вполне валидная строка, некоторых удивляет
  }
}

Это продолжение статьи «Кроссплатформенное использование классов .Net из неуправляемого кода. Или аналог IDispatch на Linux».

Там мы получили возможность использования классов .Net в неуправляемом приложении. Теперь воспользуемся «Создание компонент с использованием технологии Native API».

Итак, начнем.

Будучи программистом 1С, мне часто приходится использовать классы .Net через различные прослойки.

Использование сборок .Net через обертку реализующую IReflect
Для подключения .NET сборок используется «CLR Hosting API»
1C.Net: Предприятие – пример коммерческого успеха .Net-решений в России
Как вызвать метод из C# в 1С?

Но все они используют в той или иной степени COM. С появлением .Net Core стало возможным использование сборок .Net и на любой оси отличной от Windows.

На просторах интернета было найдено решение: Hosting .NET Core Clr in your own process и simpleCoreCLRHost и
initializeCoreCLR createDelegate и
unixinterface

Суть подключения заключается в загрузке библиотеки coreclr.dll, получения нужных интерфейсов и запуск CLR Runtime Host.

Поводом для написания данной статьи послужила эта публикация про "хрущёвки", в которой была поднята интересная для меня тема программной генерации мешей в Unity.

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

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

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

Сейчас проходит соревнование ML Boot Camp, в котором надо спрогнозировать время, за которое будут перемножены 2 матрицы размерами mｘk и kｘn на данной вычислительной системе, если известно, сколько решалась эта задача на других вычислительных системах с другими размерами матриц (точные правила). Давайте попробуем решить эту задачу регресии не с помощью стандартных инструментов и библиотек (R, Python и panda), а используя облачный продукт от Microsoft: Azure ML. Для наших целей подойдет бесплатный доступ, для которого достаточно даже trial Azure аккаунта. Все, кто хочет получить краткое руководство по настройке и использованию Azure ML в общем и ML Studio в частности на примере решения реальной живой задач, приглашаются под кат.

Чарли Чаплин в фильме «Новые времена»

Про Azure Service Fabric уже немало написано статей и даже книг, благо около года продукт находился в состянии preview. Однако 1 апреля 2016 года без всяких шуток Azure Service Fabric наконец достиг состояния General availability, и есть основания полагать, что он задержится здесь всерьез и надолго. А раз так — почему бы не пройтись по нему если не из прикладного, то хотя бы из академического интереса? Тем более что информации по Azure Service Fabric на русском языке явно маловато.

Зачем же вообще потребовался Azure Service Fabric? В мире ПО существует довольно много серверов, привязанных к экосистемам определенного языка или платформы. Исторически так сложилось, что в экосистеме Java таких серверов едва ли не больше всех — Tomcat, JBoss, WebSphere и пр. Увы, платформа .NET таким богатством выбора похвастаться пока не может. На ум приходят разве что IIS, “облачные” сервисы Azure и их “локальный” близнец Windows Azure Pack (не считая хелперов-оберток типа Topshelf). Azure Service Fabric призван расширить этот недлинный список в сторону популярной нынче концепции SOA и остромодной подконцепции микросервисов, упрощая развертывание сервисов и обеспечивая их масштабируемость и отказоустойчивость. И после этого лирического отступления перейдем, наконец, в наступление.

Привет, Хабр!

Часть 1: Введение в ReactiveUI: прокачиваем свойства во ViewModel

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

Xamarin.Forms достаточно интересный и перспективный фреймворк, который сейчас активно развивается и позволяет достаточно быстро получить кроссплатформенное приложение. По умолчанию Xamarin.Forms поддерживает 5 платформ, а именно: Android, iOS, WP, WinRT, UWP.

Несмотря на то, что Microsoft старается активно пересадить своих пользователей на Windows 10, на сегодняшний день Windows 7 все еще очень распространен во многих организациях, и возникает необходимость портирования/разработки приложения под Windows 7.

В своих C# проектах при реализации GUI я часто использую фреймворк ReactiveUI.

ReactiveUI — полноценный MVVM-фреймворк: bindings, routing, message bus, commands и прочие слова, которые есть в описании почти любого MVVM-фреймворка, есть и тут. Применяться он может практически везде, где есть .NET: WPF, Windows Forms, UWP, Windows Phone 8, Windows Store, Xamarin.

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

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

Занимательный C#

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

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

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

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

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

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

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

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

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

В этой статья мне хотелось бы рассказать о том, как была ускорена отрисовка монстров при создании игры 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.

Сервис WHOIS – это один из основных инструментов для людей, которые постоянно работают с доменными именами. Он нужен как любому человеку, желающему подобрать себе красивое доменное имя, так и хостинг-провайдеру, который помимо прочих услуг может предоставлять возможность регистрации домена. И те, и другие ищут автоматизации своей работы.

Итак, давайте разберёмся как это работает.

Как известно, контрол WebBrowser это просто обертка над ActiveX компонентом Internet Explorer. Следовательно он предоставляет доступ к полноценному layout-движку со всеми современными плюшками. А раз так, то попробуем (сам не знаю правда зачем) на его основе сделать пользовательский интерфейс для обычного windows-приложения.

Можно, конечно, было бы запустить в этом же процессе мини веб-сервер (на HttpListener например) и ловить запросы через него, но это слишком просто, скучно и неспортивно. Попробуем обойтись без сетевых компонентов, just for fun.