C# *

Это продолжение статьи Кроссплатформенное использование классов .Net в 1С через Native ВК. Или замена COM на Linux II

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

Стр=ъ(Клиент.GetStringAsync(uriSources)).Result;

И напомню про синонимы из предыдущей статьи/ Так добавив синоним

Врап.ДобавитьСиноним(HTTPClient.ПолучитьСсылку(),"ПолучитьСтроку","GetStringAsync");
Врап.ДобавитьСиноним(Task.ПолучитьСсылку(),"Результат","Result");

Я могу использовать все на русском

Стр=ъ(Клиент.ПолучитьСтроку(адрес)).Результат;

Но можно использовать асинхронные методы так.

        Клиент = ъ(Врап.Новый(HttpClient.ПолучитьСсылку(),handler.ПолучитьСсылку()));
	
	лист=ъНовый("System.Collections.Generic.List`1[System.Threading.Tasks.Task]");
	Для каждого стр из ПолучитьСписокURL() Цикл
		Задача=ъ(Клиент.GetStringAsync(стр));
		лист.Add(задача.ПолучитьСсылку()); 
	КонецЦикла;
	
	Task=ъТип("System.Threading.Tasks.Task");
	
	Пока лист.Count>0 Цикл
		массив=ъ(лист.ToArray());	
		индекс = Task.WaitAny(массив.ПолучитьСсылку());
		Сообщить(индекс);
		результат = ъ(лист.get_Item(индекс)).Result;
		Сообщить(СтрДлина(результат));
		лист.RemoveAt(индекс);
	КонецЦикла;

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

Это продолжение статей:

» Разработка → Кроссплатформенное использование классов .Net из неуправляемого кода. Или аналог IDispatch на Linux
» Разработка → Кроссплатформенное использование классов .Net в 1С через Native ВК. Или замена COM на Linux

С того времени добавил поддержку методов с параметрами по умолчанию, вызов методов расширений, вывод типов для дженерик методов, поддержка объектов реализующих IDynamicMetaObjectProvider (ExpandoObject,DynamicObject), добавление синонимов к членам типа и асинхронное программирование на 1С!

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

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

Продолжаем разговор про Azure Service Fabric. В предыдущей статье я упомянул о планах написать сначала про stateful сервисы, а затем уже перейти к модели акторов в ASF. Концепция изменилась — подумалось мне, что неплохо бы для примеров использовать если уж не production-решение, то что-то близкое, чтобы была теоретическая польза и практический смысл. Можно объединить все компоненты ASF в одном флаконе — чтобы и корованы набигали, и лунапарк, и Винни-Пух и все-все-все. Вот с такими мыслями я и пошел на кладбище домашних проектов в поисках кандидата на оживление.

Иногда при разработке программного обеспечения требуется встроить дополнительную функциональность в уже существующие приложения без модификации исходного текста приложений. Более того, зачастую сами приложения существуют только в скомпилированном бинарном виде без наличия исходного текста. Широко известным способом решения указанной задачи является т.н. “сплайсинг” – метод перехвата функций путем изменения кода целевой функции. Обычно при сплайсинге первые байты целевой функции перемещаются по другим адресам, а на их исходное место записывается команда безусловного перехода (jmp) на замещающую функцию. Поскольку сплайсинг требует низкоуровневых операций с памятью, то он осуществляется с использованием языка ассемблера и С/C++, что также накладывает определенные ограничения на реализацию замещающих функций – они обычно также реализованы на С/C++ (реже на ассемблере).

Метод сплайсинга для перехвата API-функций в Windows широко описан в Интернете и в различных литературных источниках. Простота указанного перехвата определяется следующими факторами:

1. целевая функция является статической – она сразу присутствует в памяти загруженного модуля;
   
2. адрес целевой функции легко определить (через таблицу экспорта модуля или функцию GetProcAddress).
   

Реализация замещающих функций на C/C++ при перехвате API-функций является оптимальным вариантом, поскольку Windows API реализовано, как известно, на языке C, и замещающие функции могут оперировать теми же понятиями, что и заменяемые.

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

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

Иногда возникает необходимость иметь несколько вариантов реализации определенного интерфейса и, в зависимости от определенных условий, внедрять тот или иной сервис. В этой статье мы рассмотрим варианты такого внедрения в ASP.NET Core приложении, используя встроенный Dependency Injector (DI).

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

Начну эту статью с того, что я работаю QA Automationg и того, что я люблю автоматизировать все рутинные действия. Так вот в последнее время для меня таковым стало написание, редактирование и проверка локаторов к элементам на странице.

Обычно это процесс выглядит так: я пишу xpath выражение в chrome или firepath, потом копирую его и добавляю атрибут к элементу в C# коде. Но локаторы часто нужно исправлять или просто проверить, на какой элемент он указывает. И даже такое просто изменение предиката как [@id='myId'] на [contains(@id = 'Id')] заканчивается падением теста во время выполнения потому, что я написал '=' вместо ',' и поленился проверить изменения. В общем, слишком много действий с копированием, вставкой, переключений между окнами и тому подобного для такой простой задачи. Решил я написать плагин для ReSharper, который бы по Alt+Enter подсвечивал мой элемент в браузере.

Иногда полезно оглянуться и посмотреть, как мог помочь анализатор в старых проектах, и каких ошибок можно своевременно избежать, если использовать анализатор регулярно. В этот раз выбор пал на проект NASA World Wind, который до 2007 года разрабатывался на языке C#.

NASA World Wind — это интерактивный глобус, позволяющий увидеть любое место на Земле. Для работы проект использует базу публичных снимков со спутника Landsat и проект моделирования рельефа Shuttle Radar Topography Mission. Первые версии проекта создавались на языке С#. Позже проект продолжил своё развитие на языке Java. Последняя выпущенная на C# версия — 1.4. Хотя C# версия уже много лет как заброшена, это не помешает нам проверить проект и оценить качество кода, разработчиком которого является NASA Ames Research Center.

Зачем мы проверили старый проект? Нам давно предлагали проверить что-то из проектов NASA и вот мы случайно набрели на этот проект. Да, эта проверка не принесёт никакой пользы проекту. Но такой цели в этот раз мы и не ставили. Мы просто хотели в очередной раз продемонстрировать пользу, которую может приносить статический анализатор кода PVS-Studio при разработке, в том числе и компании NASA.

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

Привет, Хабр! В связи со своей реальной задачей проанализировать возможности Qt и .NET для реализации так называемых «Назад» (Undo) и «Вперёд» (Redo), цель которых отменить действие и отменить отмену соответственно, я решил все свои мысли, идеи и задумки развернуть в этой статье, даже если они будут частично или совсем неверными (поэтому по возможности и интересу пишите в комментарии свои замечания). Хоть и на просторах Интернета спокойно можно найти хорошие (и не очень) библиотеки и примеры реализаций, более общего представления на эти вещи я нашёл не так скоро, да и то, только в ответе на StackOverflow, а этого было мне не достаточно. Во всём найденном есть моменты, которые меня порадовали, есть и которые огорчили. Пожалуй, стоит отменить все печали и радости… чтобы к ним снова вернуться… «Назад… в будущее»!


Интересно? Добро пожаловать!

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

Во время работы над нашим десктопным приложением столкнулся с такой задачей: имеется элемент-график с некоторыми настройками для отображения (реализован в виде ControlTemplate подключаемого через привязку в ContentControl), к имеющимся настройкам нужно было добавить группу дополнительных. Чтобы не засорять уже имеющийся интерфейс, я решил поместить список этих настроек в элемент Expander, который, при необходимости, можно было бы развернуть, а в остальное время график занимал бы максимально возможное полезное пространство.

Один из способов размещения элементов — под катом.

Несколько месяцев назад, когда ASP.NET Core был еще в RC1, я делал первые неловкие попытки перевести свой тестовый проект с MVC 5 на ASP.NET Core. На тот момент в проекте уже использовалась IOC библиотека Simple Injector, и по этой причине я хотел продолжать использовать эту библиотеку, благо была поддержка с rc1. Я следил за выходом новых версий этой библиотеки и относительно недавно наткнулся на довольно интересную, на мой взгляд, статью, размещенную в тематическом блоге Simple Injector. Хоть статья и опирается на соответствующую библиотеку, но основная ее ценность в поднятии более общей проблемы — новой DI абстракции в ASP.NET Core.

Статья из блога IOC библиотеки Simple Injector
Автор Steve
Буду рад, если укажете на ошибки и неточности перевода.

Последние несколько лет Microsoft занималась разработкой новой версии платформы. NET: .NET Core. .NET Core — это полный редизайн существующей платформы .NET, нацеленный на настоящую кроссплатформенность и совместимость с облачными технологиями. Мы внимательно следили за развитием .NET Core и выпускали совместимые с платформой версии Simple Injector, начиная с RC1. С выпуском Simple Injector v3.2 мы официально поддерживаем .NET Core.

Как вы могли заметить, Microsoft добавила свою собственную DI библиотеку в качестве одного из основных компонентов фреймворка. Кто-то может воскликнуть «наконец-то!». Отсутствие такого компонента породило множество опенсорсных DI библиотек для .NET. И Simple Injector, очевидно, один из них.

9 декабря состоится уже шестая конференция .NET-разработчиков DotNext – называться она будет DotNext 2016 Moscow и пройдет, как вы наверняка догадались, в Москве (гостиница «Славянская»). Кстати, DotNext – единственная в России .NET-конференция, которая собирает под 600 Senior/Middle .NET-разработчиков.



Что нового будет в этот раз? Прошу под кат.

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

Введение

FlashDevelop — популярная среда разработки Flash-приложений, поддерживающая Action Script версии 2 и 3, Haxe, JavaScript, HTML, PHP, C#, и обладающая функционалом, присущим современным редакторам кода, например, автодополнение кода, встроенная поддержка svn, git, mercurial, шаблоны, сторонние плагины, темы подсветки синтаксиса и многое другое. Примечательно, что FlashDevelop использовали Fireaxis Games при разработке XCOM: Enemy Unknown.

Пишу веб-проекты в visual studio, и с каждой новой версией студии она как будто затачивается для работы с Windows Azure. Мне нравится Азура, хотя я пользуюсь только небольшим набором возможностей. Основное для меня — это Облачная служба. Облачная служба отлично подходит для разворачивания распределенного сервера.

Scene View в Unity3D является одним из самых необходимых элементов интерфейса. Каждый, кто хоть раз запускал Unity3D пользовался Scene View для визуальной расстановки объектов на сцене, а также для их настройки. Расширение функционала Scene View может понадобиться для создания собственного редактора уровней, редактирования mesh’а, создания собственных gizmos и много другого. Стоит заметить, что при использовании Terrain в вашем проекте, его редактирование (рисование текстур, изменение высот, а также посадка деревьев и растительности) осуществляется при помощи Scene View.

Для того, чтобы иметь возможность писать скрипты работающие в Scene view в первую очередь класс с которым вы работаете должен быть унаследован от Editor или EditorWindow, что подразумевает подключение namespace UnityEditor. Это дает доступ к нескольким «магическим» методам Unity3D, таким как OnGUI() и OnSceneGUI(). Метод OnSceneGUI дает возможность Editor'у управлять событиями Scene View.

Статьи о проверке проектов с открытым исходным кодом — вещь полезная. Кто-то, в том числе и разработчики, узнает об ошибках, содержащихся в проекте, кто-то узнает о методологии статического анализа и начнет применять её для повышения качества своего кода. Для нас же это прекрасный способ популяризации анализатора PVS-Studio, а заодно возможность его дополнительного тестирования. На этот раз я проверил платформу Accord.Net и нашёл в коде много интересных фрагментов.

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

Мы уже обсудили возможности ReactiveUI, связанные с работой со свойствами, выстраиванием зависимостей между ними, а также с работой с коллекциями. Это одни из основных примитивов, на базе которых строится разработка с применением ReactiveUI. Еще одним таким примитивом являются команды, которые мы и рассмотрим в этой части. Команды инкапсулируют действия, которые производятся в ответ на некоторое событие: обычно это запрос пользователя или какие-то отслеживаемые изменения. Мы узнаем, что можно сделать с помощью команд в ReactiveUI, обсудим особенности их работы и выясним, чем команды в ReactiveUI отличаются от команд, с которыми мы знакомы по WPF и его родственникам.
Но прежде чем перейти к командам, рассмотрим более широкие темы, касающиеся реактивного программирования в целом: связь между Task<T> и IObservable<T>, и что такое горячие и холодные последовательности.