.NET дайджест #5: .NET Core, ASP.NET 5 Release Date, MassTransit 3

В выпуске: новый сайт .NET Core, даты релиза ASP.NET 5, почему стоит использовать NPM вместо Bower, 12 инструментов для создания анимации на HTML5, расширение для компиляции LESS, Scss и CoffeScript в Visual Studio 2015 и MSBuild, бесплатная пробная версия Xamarin University.

.NET Core

Новый сайт, посвященный .NET Core.

Видео о том, как проводится ревью прогресса разработки .NET Core.

ASP.NET 5

ASP.NET Community Standup — June 30, 2015, о датах релиза ASP.NET 5 и многими интересными ссылками.

Owin и Katana простыми словами для тех, кто, как и я, немного упустил этот вопрос. Собственно, с чего начинался ASP.NET 5.

Tools

Довольно спорная статья о том, почему стоит использовать NPM вместо Bower.

F# and MBraceЛеной Денисенко.

Jimmy Bogard об AutoMapper и OpenSource на .NET Fringe.

Улучшенная поддержка JavaScript и фреймворков в Visual Studio 2015

Visual Studio 2015 RC и много материала о нововведениях и изменениях. Впрочем, через пару дней будет релиз.

Аналитика приложения на ASP.NET 5 c Application Insights.

12 инструментов для создания анимации на HTML 5.

Расширение для компиляции LESS, Scss и CoffeScript в Visual Studio 2015 и MSBuild.

MassTransit v3 Update, с поддержкой TPL, async/await, котороый можно потихоньку использовать в продакшене.

JavaScript/UI

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

www.tryangular2.com — лента новостей сообщества Angular2.

Material Design Lite — библиотека компонент и шаблонов.

Поддержка responsive изображений в Microsoft Edge.

Курсы

Несколько недель назад на corsera стартовал курс Algorithms: Design and Analysis, Part 1 , к которому еще можно присоединиться.

Developing Universal Windows Apps with HTML and JavaScript Jump Start.

У Xamarin University появилась бесплатная пробная версия.

Разное

Вариант реализации ForEachAsync. Кстати, если кто-то встречал интересные реализации параллельного асинхронного producer/consumer, — поделитесь. Про TPL Dataflow немного в курсе.

Throttling Concurrency in the CLR 4.0 ThreadPool.

Свежий выпуск MSDN Magazine.

Юмор



P.S. Мы к себе в команду ищем опытного и талантливого .NET разработчика. В идеале хотим найти человека в Киеве, который бы работал со мной в коворкинге «Часопис». Но мы понимаем, что The best are everywhere, поэтому рассматриваем кандидатуры и из других городов Украины для отдаленной работы. Вопросы можно задавать мне тут или в личку, или по контактам, указанным в описаниях. С удовольствием отвечу на интересующие вопросы.


← Предыдущий выпуск: .NET Дайджест #4
Следующий выпуск: .NET Дайджест #6

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn



14 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.
Вариант реализации ForEachAsync. Кстати, если кто-то встречал интересные реализации параллельного асинхронного producer/consumer, — поделитесь. Про TPL Dataflow немного в курсе.

імхо, це доволі неякісний велосипед (foreach async),
краще вже заюзати щось типу plinq (www.albahari.com/threading/part5.aspx)

PLINQ хорош для CPU-intensive операций. Тут задумка как раз в том, чтобы использовать неблокирующие операции ввода/вывода. А PLINQ внутри реализован очень похожим образом с использованием класса Partitioner. Конкретно имею в виду Parallel.ForEach.

А в своем проекте я все-таки решил возвращать Task и собирать исключения в AggregateException.

PLINQ хорош для CPU-intensive операций. Тут задумка как раз в том, чтобы использовать неблокирующие операции ввода/вывода.

по лінку я побачив партишнінг + таск.ран, де тут неблокуючі io? той самий execution всього на пулі, чи я щось пропустив? плюс реалізація чуть пахне. цілі я так і не зрозумів, це типу poor man’s plinq

ага, селектор вертає таск, пропустив. але тоді це все одно ужоснах, просто waste потоків з пулу, і ексепшени...

ужоснах...і ексепшени
Вы точно читали статью и статьи по ссылкам в ней? Из пула максимум будет использоваться число потоков равное degree of parallelism. А по факту меньше, если I/O операции длиннее, чем выполняемые на CPU.

спочатку проскролав, тепер уважно перечитав. затупив з початковими коментами.

по статті:
якщо degree of parallelism великий (20-50+), то ціна за такий фінт дуже висока, краще просто вручну контролювати кількість задач (виставити ліміт і просто запускати наступну з черги якщо якась закінчилась), знаю, що partitioner може розумно перерозподіляти задачі, але чомусь здається, що на практиці ефективніше може бути просто ручне обмеження, яке ще й зекономить n потоків з пулу на час проведення.

ця реалізація може бути корисна для відносно малих значень degree of parallelism, далі оверхед сильно росте

Вообще рекомедуют использовать количество потоков равное количеству ядер чтобы минимизировать переключения контекста в ядрах CPU. Если все выполнение происходит на CPU то тогда DoP нужно ставить равным количесву ядер. Если есть I/O операции, то есть несколько ваританов. Если I/O операции длинные а CPU операции довольно короткие — можно ставить DoP разы выше количества ядер. Если наоборот I/O операции короткие, а CPU операции длинные — DoP должент быть близок к количеству ядер.

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

я мав на увазі асинхронні іо, тут кількість ядер не суттєва, запускати так, щоб в будь-який момент виконувались n операцій (n — throttling значення), це ж і була задача зі статті. ну от, це можна зробити вручну на івент хендлах

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

await body(partition.Current);
Вот в этом месте тело цикла может использовать неблокирующие оперции.
execution всього на пулі
Да, а I/O операции не будут блокировать потоки из пула, как в случае с PLINQ.
цілі я так і не зрозумів
Цель — неблокирующий цикл, который в PLINQ не реализован.

Да, довольно удобный. Там был ДОУ-ревизор около года назад: dou.ua/...les/dou-revisor-chasopys.

http://jobs.dou.ua/companies/sproom/offices/
пусто

Підписатись на коментарі