10 интересных вещей о платформе DotNet Core


Оглавление (нажмите, чтобы открыть):

.NET Core: возможности и перспективы

Я начал следить за платформой .NET Core ещё с момента анонса. В своё время я успел ознакомится с версиями RC1, RC2 и сейчас активно изучаю возможности RTM версии. На сегодняшний момент .NET Core представляет собой легковесное модульное кросс-платформенное решение, позволяющее, помимо прочего, пользоваться всеми преимуществами классического .NET. В этой статье я предлагаю взглянуть на возможности обновлённой платформы и её перспективы.

Предыстория

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

Скорее всего, если вы слышали про .NET Core, то слышали про него то, что это новый .NET, который работает под Linux и Mac OS X. Именно возможность запуска платформы на ОС, отличных от Windows, и вызвала в свое время множество споров и обсуждений. Хотя, на самом деле, задолго до появления .NET Core уже существовали кроссплатформенные реализация .NET Framework. Два самых известных проекта — небезызвестный проект Mono, который не раз был отмечен даже самой Microsoft, и DotGNU, в свое время поддерживаемый Free Software Foundation. На сегодняшний день проект DotGNU уже закрылся, а вот Mono, наоборот, в последние два года получил активное развитие. Mono представляет собой open source реализацию .NET, поддерживающую операционные системы Linux и Mac OS X. Развивается Mono независимым сообществом разработчиков, которые занимаются реинжинирингом компонентов .NET и создают их кроссплатформенную реализацию. Ввиду этого Mono всегда была «догоняющей» платформой, в которой возможности оригинального .NET появлялись спустя довольно длительное время.

Главное отличие .NET Core от Mono состоит в том, что Mono — это именно перенос «большого» .NET, на платформу *nix. В то время, как .NET Core — это спроектированная практически с нуля платформа, изначально рассчитанная на работу с различными ОС. При этом большая часть кода которой писалась с тем, чтобы платформенно-специфичных зависимостей было как можно меньше. На приведенном ниже графике — соотношение общего кода платформы и кода специфичного для каждого отдельно взятого семейства ОС:

Что нового

По своей сути .NET Core — это практически полная перезагрузка стека .NET Framework. Из новой платформы по разным причинам был исключён ряд технологий. Следует понимать, что платформа .NET Core рассчитана в первую очередь на разработку для серверных и облачных решений. Для десктопных приложений лучше подходят классический .NET для Windows (с поддержкой WPF и Windows Forms) и Mono для Linux и Mac OS X (с поддержкой Windows Forms). Мобильные проекты можно создавать, используя Xamarin. На схеме показано, как технологии распределены внутри различных реализаций .NET:

Таким образом, в .NET Core были исключены:
— ASP.NET WebForms;
— WCF;
— WPF;
— Windows Forms.

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

На изображении ниже показано, как соотносятся между собой классический .NET и .NET Core.

Open Source. В отличии от классического .NET Framework, код которого по большей части является закрытым, код .NET Core полностью открыт и распространяется под лицензиями MIT и Apache2.

Стоит отметить, что после открытия кода .NET Core команда, занимающаяся разработкой проекта Mono, объявила о намерении объединения кодовой базы тех компонентов Mono, которые реализованы в .NET Core.

Работа в облаке. Как и проект, написанный на классическом .NET, проект на базе .NET Core достаточно легко перенести в облако. Microsoft Azure уже поддерживает размещение .NET Core проектов как в службах Application Services, так и на виртуальных машинах.

Библиотеки для работы с сервисами Microsoft Azure также уже начинают портироваться на .NET Core. Например, Windows Azure Storage уже доступна для работы. Соответственно Azure Storage Services могут использоваться в core-проектах.

Также, для проектов .NET Core появляется возможность размещения на площадках тех облачных провайдеров, которые не обеспечили поддержку Windows окружения, но при этом обладают другими привлекательными возможностями. Например, виртуальные серверы Digital Ocean за счет использования SSD дисков очень быстрые, но на данный момент позволяют разворачивать только ОС семейства Linux. Развернуть проект на .NET Core на подобно сервере не составит труда.

Инструменты для работы с .NET Core

Несмотря на то, что платформа только недавно получила статус RTM (release to market), уже имеется ряд удобных и мощных средств для разработки. Давайте рассмотрим подробнее, какие инструменты доступны уже сейчас для .NET Core разработчиков.

Project Rider — IDE от компании JetBrains, той самой компании, которая создала ReSharper, наверное, самый популярный плагин для Visual Studio. В основе Rider лежат IntelliJ IDEA (являющаяся основной для целого семейства IDE) и наработки, используемые в ReSharper. На данный момент Rider поддерживает разработку как под Mono, так и под .NET Core. Следует помнить, что на данный момент Rider находится в стадии EAP (Early Access Preview) и по сути не предназначен для использования в production, однако уже дает возможность оценить имеющийся потенциал. Rider доступен как под Windows, так и под Linux и Mac OS X.

Visual Studio Code — редактор (хотя уже практически IDE), разработанный компанией Microsoft на базе ядра Electron (того самого, на котором основан Atom). Благодаря большому количеству плагинов VS Code поддерживает разработку не только под Mono и .NET Core, но также и под другие языки, включая Go, C/C++, JavaScript, Typescript, etc. Visual Studio Code работает как под Windows, Linux и Mac OS X.

Visual Studio Community Edition — одна из редакций той самой Visual Studio, которая де факто уже стала эталоном IDE. При этом Community Edition распространяется бесплатно и может быть использована в разработке коммерческого ПО. Естественно, как флагманский продукт компании, именно эта IDE даёт наибольшее количество возможностей для как c .NET/.NET Core, так и с Mono. Единственное ограничение этой IDE — на данный момент существует исключительно версия под Windows. Что впрочем не мешает разрабатывать и отлаживать проекты, которые будут работать под Linux и Mac OS X.

ReSharper — наверное, самый популярный плагин для Visual Studio, который добавляет возможности анализа и рефакторинга кода. Буквально несколько дней назад вышла версия 2020.2, в которой реализована полная поддержка проектов на базе .NET Core.

Существующие решения

Уже сейчас есть несколько интересных проектов для построения веб-сайтов на базе .NET Core:

Platformus CMS. Как пишет о сам автор Дмитрий Сикорский: «Platformus CMS — молодая система управления содержимым веб-сайтов альфа на момент написания статьи), построена на базе не менее молодых ASP.NET Core и ExtCore Framework. Написана CMS на C#. Благодаря возможностям ASP.NET Core, она одинаково хорошо может работать на Windows, Linux и Mac. Сама исполняемая среда, необходимая для работы любого приложения на .NET Core, может быть как установлена отдельно, так и интегрирована непосредственно в само приложение». Подробнее о CMS можно прочитать здесь.

Orchard. Orchard — система управления контентом с открытым исходным кодом от компании Microsoft. Первая версия CMS была анонсирован в марте 2010 года и основывалась на ASP.NET MVC. Вторая версия активно разрабатывается уже на основе ASP.NET Core. Подробности на сайте проекта.

Платформа корпоративного уровня для всех

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

Оставляя в наличии все плюсы классической версии, новая версия позволяет значительно снизить инфраструктурные затраты. Хостинг проекта на .NET Core обходится гораздо дешевле хостинга проекта на «большом» .NET. Так в Microsoft Azure самая дешёвая виртуальная машина с возможностью хостинга ASP.NET веб-приложения будет стоит от $13 в месяц. Размещение в службе Azure App Services в тарифе Shared будет стоить от $9 в месяц. При этом размещение проекта на виртуальном сервере у Digital Ocean обойдётся всего в $5 в месяц. При этом количество ресурсов выделяемых на приложение будет гораздо больше, чем у Shared-сервиса, а если сравнивать с виртуальной машиной от Azure, то конфигурация Digital Ocean будет выгодно отличаться наличием SSD диска.

Конечно, для крупных корпоративных проектов подобные суммы не имеют никакого значения. Более того, корпоративная среда достаточно консервативна. Поэтому, на мой взгляд, .NET Core начнёт широко использоваться в enterprise проектах не ранее чем через как это было с ASP.NET MVC. В текущем же своём виде новая платформа будет играть в том же сегменте, где сейчас находятся такие технологии, как Node.js и Ruby — это небольшие проекты с ограниченным бюджетом и невысокой архитектурной сложностью. Крупные решения как и прежде будут реализовываться на «большом». NET. Таким образом, целевой аудиторией .NET являются стартапы и рынок малого и среднего бизнеса.

Выводы

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


Dmitriy Azarov

Начало

Начать стоит с того, как я пришел в .net. Это произошло сразу после погружения в ООП в виде Visual Basic. После знакомства с VB стало понятно, что такое программирование на ООП и что это очень мощная штука. Стал вопрос куда развиваться дальше. Уже существовал .NET Framework и VB.NET, было очевидно, что это не та платформа, за которой будущее. Это было примерно в 2006. Предстояло первый раз выбрать платформу, в которую погружаться. То, что выбор пал на C# — стечение обстоятельств, пусть и счастливое.

Первое время я испытывал эйфорию создавая объекты, классы. Еще ничего не знал о настоящем ООП. Позже пришли абстрактные классы и интерфейсы. К паттернам я испытывал отдельную любовь, красота с которой решаются проблемы проектирования завораживала. И да, много времени уходило на проектирование любого сложного участва программы. Зачастую паттерны были использованы ради паттернов. Делал маленькие проекты, рос, делал средние и ближе к 13 году уже большие сайты с отдельным бекендом, службами, базами. Почувствовал мощь платформы.

Средние века

В далеком 2002, когда был представлен C# и .NET это было революцией, революцией как платформа. Хотя это было не ново, уже существовала Java, но C# был призван решить всю боль Java (не вышло). Вместо VB появился VB.NET, который не получал обновлений и развития, а лишь убил VB. Зачем? Одним из минусов, который Microsoft решила исправить недавно было то, что C# / VB.NET работали только на Windows. В то время распространение интернета и технологий было не таким обширным. Количество людей, работающих на других платформах было низкое и это работало. В 2010+ годах стало видно серьезное развание в ubuntu и mac платформах, и это оказалось тоже удобно. Люди пробовали новое и им нравилось. Порог входа в linux снизился.

В те годы не было мысли, что есть альтернатива .net. Появились такие плюшки как LINQ, WPF, async/await, WCF. Так много сахара всегда приятно. Ни одна другая платформа не могла предложить что-то похожее. LINQ to SQL сильно упростило погружение в мир баз данных. Но, я бы сказал что это минус, когда начинающие разработчики не разобравшись как оно работает начинают использовать технологию, и я в том числе. Я уже получил сертификат в Microsoft по C# и довольно подробно знал как все внутри устроено. То что я увидел меня обеспокоило. Я сделал статью о коллекциях в C#.

.NET вчера

Знакомство с альтернативными платформами началось с погружения в мир Xamarin. Впервые попробовав разработку на Mac понял, что есть что-то кроме Windows разработки. Именно тогда родилась мысль, что альтернативы .net существуют. Однако не было причин менять его. Все больше погружаясь в мобильную разработку я в одно и то же время разрабатывал API на .net и автоматизировал рутину на ruby. Мне очень понравилась простота, с которой можно выполнить скрипты на руби. Они выполняются практически всегда одинакого на разных версиях, платформах. Были мысли реализовать аналоги на .net, но, количество кода, которое нужно написать и скорость работы не устраивали совсем. Я с этим мирился. Но это только начало боли. Компиляция в несколько десятков секунд ��.

Также очень крутой технологией был ASP.NET. Правда классический ASP.NET мне не нравился совсем. К счастью я не успел в нем погрязнуть и разочароваться. ASP.NET MVC был принят как новый стандарт. Версии стряпались каждый код, и практически каждый год изобретались заново. 3-я версия MVC мне кажется хорошей версией, и ее нужно было развивать (а не переделывать). Все это работало тоже только на Windows. В целом ничего критичного. Но цена серверов была и есть выше, весь софт лицензируемый и тоже стоит денег. В качестве надежности всегда можно привести примеры самого сайта Microsoft и Stackoverflow. Большие сайты, выдерживают огромную нагрузку. Технология Microsoft работает.

Что еще было в 2010-2020 годах

Если кто помнит, был еще такой зверь как Windows Mobile 2003. На .net я успешно делал программки. Одну из них опубликовал на форуме 4pda. Называлась она Расписание студента. Появились первые пользователи, отзывы и пожелания. Вот парочка скриншотов.

Microsoft представляет Mango (Windows Phone 7.5). Она не совместима с предыдущими мобильными операционными системами. Это отдельная операционка для телефонов, и там есть что-то вроде .NET, но свой, урезанный. Не было возможности приобрести телефон и попытать счастье в разработке для этой операционки. Потом вышла 7.8.

Я познакомился с Windows Phone уже версии 8.0. Появился магазин приложений. Он был пустой, был шанс быстро выбраться в топ. Было сделано 2 приложения. Это курс валют и простая казуальная игра Точки. Курс валют брал валюты с ЦБ РФ, установок было порядка 10к. Оба приложения выбрались в топ. Но, точки получили почти 150к установок за неделю. Я никак не монетизировал приложения, было интересно попробовать платформу и магазин приложений. В то время у меня уже был опыт разработки для мобильных устройств на iOS и опыт работы с iTunesConnect (сейчас который AppStoreConnect). Не без костылей, но приложения завелись. На Windows Phone модерация была примерно неделю, что было очень странно для компании, у которой нет ничего для удержания разработчиков. Даже у Apple модерация была в среднем 3-5 дней. Это потом Microsoft сделали модерацию приложений за сутки, но возможно было уже поздно.

Что сделали Microsoft с Windows Phone и где он сейчас? Обидно.

После выхода Windows 8 и Windows 8.1 и сравнивая Windows Phone 8 и Windows Phone 8.1 оказалось, что это совершенно разные платформы. Как раз появилась возможность сделать “одно” приложение для обоих магазинов. Кстати, сами магазины приложения были совершенно разными и было видно, что их делали разыне команды, разные требования, интерфейс и вообще все. Я попробовал сделать приложение для обоих магазинов. Это было Судоку. Опубликова билды на 4pda, на хабре, и описал по горящим следам впечатления:

Сильно раздражало, что Microsoft пропагандирует, что это одна платформа и что в Windows 10 будет одна кодовая база. А на самом деле нет. Я сделал очень простое приложение судоку, а на деле получил информацию, что это абсолютно разные платформы. Да, классы называются похоже. Но локалазация в Windows Phone делается одним способом, в Windows Store другим, нельзя переиспользовать строки (локализацию пришлось копипастить). Layout делается для каждой платформы свой. Да, Xaml это отлично, но плохо, что верстка разная. Внутри было 2 проекта для Windows Store и Windows Phone.

Забегая вперед, Microsoft обещали сделать все хорошо в Windows 10. Придумали UWP (Universal Windows Platform). Завелось? Технологии порождаются с бешенной скоростью, а вот качество этих технологий распыляется. Вот список технологий, ключевых слов, за которыми Microsoft пророчили будущее:

  • UWP
  • ASP.NET 5 (ASP.NET Core)
  • Core CLR
  • .NET Standard
  • WinRT (превратилась в Windows 10)
  • Windows Phone (Windows Mobile)

У каждой технологии отличная идея. Но, только зарелизив .net core 1.0 его сразу же задеприкейтили и прекратили поддержку. Я поверив в светлое будущее переделал свой сайт на .net core. С чем я столкнулся? С тем, что экосистема Windows сама по себе не преспособлена для этой технологии. Чтобы запустить его на сервере Windows все равно используются костыли, Kestrel, еще куча библиотек. Отличная технология, которая собирает и деплоит проект через WebDeploy не работает. А есть вообще нормальный способ собрать и задеплоить проект .net core?

А помните как раскатывался .net core первый раз? Придумали package.json. Все выучили, смирились, удобный формат. В следующем обновлении Visual Studio уже этого файла нет, и все по новым рельсам. Об HTTP2 .net core 1.0 не слышал, и не услышал ��.

.NET core сегодня

Если посмотреть что произошло с .net и .net core за последние 3-5 лет. Если кратко описать — ничего. Была стабильная технология .net framework. Со своими плюсами и минусами, но жила и работала. Мне кажется больше использовалась в корпоративном секторе. После цели все в облако и популяризации Azure да и в целом популяризации linux стало понятно, что .net в таком виде долго не проживет. Microsoft принял стратегически верный шаг в открытости платформы, идеологии, но сделали по своему. На 3 года прекратив активное развитие платформы на переписывание всего и вся.

Куда делся Silverlight? Отличная технология, я на ней пилил админку красивую с анимациями. WPF очень мощная технология для реализации пользовательских интерфейсов. Это как html только для нативных приложений. .NET Core его разумеется не поддерживает. Как быть с этой технологией? Писать на старом C#, старой Visual Studio, под старым фреймворком. Когда Microsoft надоест поддерживать это, а вдруг завтра? Это важно, потому что .net core не имеет графического интерфейса.

Мастер Йода рекомендует:  Keywords - ключевой фактор успеха

Есть такие порталы как channel9 и user voice. Используются ли они для принятия решений? Не думаю. Сама IDE без сторонних решений не юзабельна. На одной из конференций Microsoft сказали, что гордятся тем, что для их продукта создаются сторонние решения, что разработчикам нравится делать продукты для Visual Studio. Это потому, что без них это жутко тормозной редактор кода. А новый, сверхскоростной редактор кода на javascript VS Code? Серьезно?

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

На macOS есть Visual Studio. Но она не имеет ничего общего с VS на Windows. Это все тот же MonoDevelop -> Xamarin Studio -> VS в новой обертке. Она очень медленно поддерживает обновления .net core.

Я всегда был сторонником идеи, что и на Windows можно сделать все то же самое что и на linux. Профилирование приложений, статистика, память и прочее. Но, то, что на ubuntu делается просто (Elastic Kibana Logstash или Prometheus), на Windows боль. У Microsoft на все потребности пытается сделать что-то свое, а не использовать уже готовое, годами отработанное решение.

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

Куда идти с .net core?

К этому решению я шел примерно полтора года. Каждый раз у меня возникало ощущение, что я все что угодно могу сделать на net. Тем более на .net core. Разве может быть что-то другое, на чем я с легкостью могу реализовать сложное решение быстро и надежно?


В моих рабочих задачах обработки данных было много Python. Распробовав этот язык я попробовал реализовать несколько Api проектов и сайтов на Python. И это работает. Кроме того, деплой обновлений происходит крайне быстро, стабильно и предсказуемо. Для этого есть простейший маленький rsync. Кроме того, основной рабочий инструмент это Macbook, а на нем разработка даже в Rider это боль. Долго и невкусно. Определенно есть задачи, которые .NET (не .net core) решает лучше и быстрее, но не у меня ��. PyCharm сейчас является основной средой разработки. Консоль обрела новую жизнь.

Я получаю огромное удовольствие от разработки, деплоя, поддержки всего на Python. Очень трудно все с нуля делать на Python, было много вопросов по самым простым процедурам. Например запись в файл и прочее. Но лаконичность, количество кода, стабильность. И самое главное — сообщество и экосистема!

.Net 5 объединит ветви .Net Framework и .Net Core

.Net 5 будет поддерживать Windows, Linux, MacOS, iOS, Android, tvOS, watchOS, WebAssembly и прочие операционные среды

Запланированный на ноябрь 2020 года выпуск .Net 5 ознаменует собой начало эры новой, объединенной платформы.

Следующая версия платформы Microsoft для разработчиков – .Net 5 останется единственной из существующих сегодня ветвей. Отдельных выпусков .Net Framework и .Net Core больше не будет.

Выпуск .Net 5, по планам корпорации, состоится в ноябре 2020 года. Новая версия платформы придет на смену программному обеспечению с открытым кодом .Net Core 3.0, которое в настоящее время представлено в бета-версии и должно появиться в сентябре 2020 года. Как и .Net Core, .Net 5 будет поддерживать Windows, Linux, MacOS, iOS, Android, tvOS, watchOS, WebAssembly и прочие операционные среды.

С самого начала .Net Core оставалась многоплатформенной версией .Net, тогда как оригинальная .Net Framework работала только в среде Windows. Теперь, после объявления о том, что в .Net Core 3.0 отличия от .Net Framework 4.8 будут ликвидированы, .Net 5 вполне можно считать следующим шагом в развитии .Net Core. Файлы программного кода и проектов будут выглядеть одинаково и получат средства поддержки одной и той же среды исполнения, API и языковых возможностей.

Разрабатывая .Net 5, в Microsoft преследовали следующие цели:

  • проектирование единой среды исполнения и платформы .Net, которая должна вобрать в себя весь накопленный разработчиками опыт и особенности сред исполнения;
  • расширение возможностей .Net за счет использования всего лучшего, что было создано в .Net Core, .Net Framework, Xamarin и Mono;
  • формирование единой базы программного кода, которую разработчики будут расширять общими усилиями.

В Microsoft заявили, что .Net 5 будет оставаться кроссплатформенной средой с открытым кодом, тесно интегрированной с IDE и редактором кода Visual Studio. На всех платформах, поддерживаемых .Net 5, будет обеспечена интероперабельность с Java. Кроме того, для многих операционных систем декларирована интероперабельность с Objective-C и Swift.

Выпускать новую версию .Net планируется в ноябре каждого очередного года. Версию 4 в нумерации решено пропустить, чтобы избежать путаницы с .Net Framework 4.x. Все приложения .Net 5 будут использовать CoreFX – нынешнюю базовую библиотеку классов для .Net Core.

В Microsoft намерены распространять документацию .Net 5 в сообществе разработчиков, рассчитывая на тесную обратную связь. Корпорация обещает, что .Net станет проще при расширении ее функциональных возможностей. Одни и те же API и языковые средства .Net будут рассчитаны на множество типов приложений, операционных систем и процессорных архитектур. В Microsoft обещают также упростить внесение изменений в процессе сборки.

Поделитесь материалом с коллегами и друзьями

Двадцать один пример IoT-платформ 58

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

Как вы знаете, у меня есть небольшой частный телеграм-канал «ЗаТелеком», куда я выплескиваю новости, старости или просто заметки. Ну, и один пост почему-то вызвал «особый интерес» в виде массы репостов и упоминаний. Он был про «самые модные в этом сезоне IoT-платформы». Короткий простой пост с девятью ссылками на эти самые платформы.

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

Что есть IoT-платформа?

Начнем с простого: что есть IoT-платформа, и как отличить оригинал от подделки?

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

Но вот есть гораздо более умные парни (разумеется, не наши), которые все понятно объяснили. Вот здесь оригинал, а ниже — краткий переклад на русский.

IoT-платформы — это такая штука, которая объединяет собственно «вещи» и «интернет». По сути — это ключевой инструмент разработки IoT-приложений и сервисов, объединяющий физические объекты и Сеть.

При этом многие вендоры, которые пытаются «держать нос по ветру», предлагают «IoT-платформы», которые в корне различаются между собой. И в ряде случаев, не являются «платформой» в широком смысле слова, но совершенно очевидно имеют основания себя таковой считать — есть «вещь», есть некий ресурс в интернете, который принимает/передает данные от/к «вещи». И что-то там делает (пытается делать) с этими данными. Следовательно, претендовать на высокое звание дом образцового быта платформы вполне себе может. Притом, что четкого и конкретного определения IoT-платформы попросту не существует.

По мнению авторов «IoT Analytics», полноценной IoT-платформой следует считать такую платформу, которая позволяет разрабатывать соответствующие приложения/решения (IoT Application Enablement Platform).

А вот четыре типа платформ, которые называют «IoT-платформами», однако они не вполне подходят под классификацию IoT Analytics:

  • Connectivity / M2M platforms. Платформы в своей работе фокусируются на связи умных объектов через телекоммуникационные сети, но редко на обработке сигналов от датчиков (пример такой платформы: Sierra Wireless с продуктом AirVantage).
  • IaaS backends. Инфраструктура-как-сервис-серверы, предоставляющие хостинг-пространство и вычислительные мощности для приложений и сервисов, ранее оптимизировались для десктопов и мобильных приложений, но сейчас в фокус попал и IoT (пример — IBM Bluemix, но не IBM IoT Foundation).
  • Hardware-specific software platforms. Некоторые компании, продающие умные гаджеты, создают собственный программный бэкенд и рассуждают о нем, как об IoT-платформе. Но так как эта платформа носит закрытый для всех остальных характер, правомерность такого наименования сомнительна (например — Google Nest).
  • Consumer/Enterprise software extensions. Существующие пакеты корпоративного программного обеспечения и операционные системы типа MS Windows 10 становятся все более открытыми для интеграции IoT-устройств. В настоящее время эта область еще недостаточно развита, чтобы называться IoT-платформой, но будущее у нее очень перспективное.

В общем все запутано и ясности в терминологии нет. Что еще и усугубляется «модностью» темы и желанием разработчиков IoT-платформ комбинировать фантазии маркетологов, как, например, это делает IBM (IoT Foundation application enablement platform + Bluemix IaaS backend).

И вот парни из IoT Analytics сделали интеллектуальное усилие, и выделили восемь компонентов полноценной IoT-платформы:


  1. Связь и нормализация (Connectivity & normalization): сведение различных протоколов и форматов данных в один «программный» интерфейс, гарантируя точную передачу данных и взаимодействие со всеми устройствами.
  2. Управление устройствами (Device management): обеспечение правильной работы подключенных «интернет-вещей», их конфигурирование, бесперебойную работу, «накатку» патчей и обновлений. Причем, не только ПО собственно «вещей», но и приложений, работающих на устройстве или пограничных шлюзах.
  3. База данных (Database): тут все достаточно понятно и прозрачно — масштабируемое хранилище данных от «вещей». Требования к этим данным, попытка навести порядок в обработке и перенос данных из, например, разных «платформ» или вовсе к информационным системам «третьих лиц».
  4. Обработка и управление действиями (Processing & action management): данные, полученные от «вещей» в конечном итоге влияют на события в реальности. По этому «платформа» должна уметь строить процессы, «триггеры событий» и прочее «умные действия» на основе конкретных данных датчиков.
  5. Аналитика (Analytics): данные от «вещей» являются ценными сами по себе. Поэтому существование комплекса средств их анализа является всенепременным требованием к «платформе». Если сюда включить еще и средства кластеризации данных и глубокого машинного обучения вплоть до прогнозирующей аналитики,то ценность «платформы» очевидно растет.
  6. Визуализация (Visualization): всю вышеперечисленную аналитику и вообще было бы неплохо показать таким образом, чтобы людям было понятно, приятно и красиво. Строить графики, модели, просто визуализировать то, что происходит с «вещами». Ну, и просто удобный интерфейс.
  7. Дополнительные инструменты (Additional tools): набор инструментов, который позволяет разработчикам IoT создавать прототипы, тестировать и пробовать различные системы. Приложения, виджеты, машапы — вот это все. Желательно, чтобы не очень углубляться в код и хардкор-программирование.
  8. Внешние интерфейсы (External interfaces): интеграция с помощью платформы — одна из главных возможностей. Мир интернет-разработки сегодня не терпит замкнутых решений. Всегда может потребоваться передача и обмен со сторонними системами. Поэтому настоящая IoT-платформа обязана иметь интерфейсы прикладного программирования (API), комплекты разработки программного обеспечения (SDK) и шлюзы.

Вот картинка для общего понимания (я не стал ее переводить):

На рынке уже имеются сотни платформ. IoT Analytics насчитали их более 450 и число продолжает расти. При этом различные платформы появляются из-за различных стратегий входа различных компаний, видения развития, подходов и начальных условий. Клиентские сегменты, кстати:

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

Попробуем разобрать эти стратегии:

  • Стратегия «органического роста» снизу-вверх (Organic bottom-up approach): то есть, платформа начинает расти от «вещей» — сначала появляются некие устройства (обычно универсальные датчики), а потом начинается расширение и улучшение функционала, выстраиваются связи, подключаются другие «железки». Так, например, начиналась платформа Ayla Networks, которая возникла с контроллеров STM32F3.
  • Стратегия «сверху вниз» (Organic top-down approach): обратная ситуация, когда сначала появлялась аналитическая составляющая, а потом к ней пытались приспособить как можно больше разных «вещей». Пример — упомянутая IBM IoT Foundation.
  • Стратегия «партнерства» (Partnership approach): создание альянсов для развития продукта. Кто-то «приносит» «вещи», кто-то «админку». Пример: альянс GE Predix (это тот самый «Дженерал Электрик», у которого активов по Миру на триллион) и PTC Thingworx. Последняя компания в России больше известна пакетом компьютерной алгебры Mathcad.
  • «Слияния и поглощения» (M&A approach): любимый капиталистический прием по целевой скупке интересных решений крупным игроком. Например, Amazon в 2015 году купил 2lemetry, и теперь это все называется AWS IoT. Вариант стратегии — объединение бизнесов, как, например, Nokia и Alcatel-Lucent.
  • Ну, и есть еще «Инвестиционный подход» (Investment approach): тактические инвестиции по всей экосистеме IoT. Так любит поступать, например, Cisco.

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

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

Для того чтобы эти модели «полетели» практически все готово — есть аппаратное обеспечение, имеется развитая инфраструктура передачи данных, есть очень хорошее программное обеспечение. Осталось чуть-чуть, и…

Но двинемся дальше.

Двадцать одна открытая платформа «Интернета вещей»

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

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

  1. AllSeen Alliance (AllJoyn) — Фреймворк взаимодействия «вещей» AllJoyn, созданная AllSeen Alliance (ASA), который является проектом Linux Foundation. Есть мнение, что это одна из самых популярных IoT-платформ с открытым исходным кодом.
  2. Bug Labs — пример стратегии разработки «снизу вверх». Парни из «Лаборатории ошибок» (красиво, кстати), начали разработку и железок для IoT под заказ, но потом обросли кучей веб-приложений и стали платформой, которая зарабатывает на разработке «нестандартных решений». Например, таких. Bug Labs в настоящее время имеет платформу для обмена сообщениями и оповещений «dweet» и «Freeboard — дашборд для создания панелей вывода и визуализации IoT».
  1. DeviceHive — платформа управления всевозможными устройствами на базе DataArt — форк AllJoyn (первый пункт). Предназначен для быстрого развертывания на популярных облачных сервисах: Azure, AWS, Apache Mesos и OpenStack. DeviceHive фокусируется на анализе больших данных с использованием таких инструментов, как ElasticSearch, Apache Spark, Cassandra и Kafka. Работает на любом устройстве, на котором запущено Ubuntu Snappy Core. Собственно ПО построено по модульному принципу с идеологией «промежуточного шлюза». Ну, то есть собственно «вещь» подключается к бордеру в виде, например, Raspberry PI (вот список поддерживаемого железа, где работает Snappy Core), а затем уже «цепляется» к облаку, где развернут DeviceHive.
  2. DSA — Архитектура распределенных служб (Distributed Services Architecture). Достаточно сложная для понимания штука, которая предполагает создание полносвязных сетей «вещей». Имеет три элемента: DSBroker, DSLink и nodeAPI. Попробуйте сами разобраться.
  3. Eclipse IoT (Kura) — IoT-решение от Eclipse Foundation. Основа заключается в наличии API-контейнера Kura API. Написан на Java / OSGi и платформе агрегации для приложений M2M, работающих на служебных шлюзах. Kura использует Eurotech Everywhere Cloud IoT, легко интегрируется с Apache Camel. Подпроекты Eclipse IoT включают в себя инфраструктуру протоколов обмена сообщениями Paho, и полный стек MQTT Mosquitto для «легких серверов» со средой Eclipse SmartHome. Существует также Java-реализация протокола CoAP под названием Californium и еще что-то. Много всего.
  4. Kaa — проект поддерживается компанией CyberVision, и представляет собой масштабируемую инфраструктуру IoT, предназначенную для достаточно больших сетей. Платформа имеет серверную функцию REST-сообщений для служб, аналитику и управление данными. На базе Apache Zookeeper можно создавать кластерные системы, масштабируемые «до куда угодно». SDK Kaa поддерживают разработку на Java, C ++ и C. Имеются библиотеки организации связи «клиент-сервер», аутентификацию, шифрование, хранение и сортировку данных.
  5. Macchina .io — универсальная среда для разработки приложений IoT-шлюзов, работающих на железках под Linux. Macchina.io уже включает поддержку огромного количества датчиков и технологий подключения, включая Tinkerforge bricklets, кучу датчиков на XBee/ZB, GPS/GNSS приемники и еще кучу всего.
  6. GE Predix — выше эта платформа уже упоминалась. Это по сути PaaS (платформа как услуга) для промышленного IoT и базируется на Cloud Foundry. Платформа умеет «управлять активами, обеспечивать безопасность устройств и готовить аналитику в режиме реального времени. Ну, и все остальное, что должны уметь платформы, конечно это сбор данных, их хранение и обеспечение доступности. «Дженерал Электрик» разработали GE Predix, прежде всего, для собственных нужд. Соответственно имеет некоторую отраслевую специфику — электроэнергетика. Predix считается одной из самых успешных IoT-платформ и утверждается, что генерит разработчику порядка 6 млрд. долларов.
  7. Home Assistant — платформа для массового использования для целей домашней автоматизации. Написана на Python.
  8. Mainspring — платформа запилена на Java компанией M2MLabs. Довольно старенькая и страшненькая (как, впрочем, и все написанное на Java — шутка). Использует для коммуникаций «вещей» REST и предлагает инструменты настройки оборудования и моделирования.
  9. Node-RED — этот инструмент визуальной разработки на Node.js. Имеется браузерный редактор «потоков», с помощью которого можно проектировать целые сети IoT с узлами и хабами. После узлы могут быть быстро развернуты как «среды выполнения» на куче серверов и/или в облаках. Обмен данными основан на JSON, что логично. Поддерживаются «вещи» на платах с Linux, а облачная поддержка — Docker, IBM Bluemix, AWS и Azure.
  10. Open Connectivity Foundation (IoTivity). Совместная разработка Intel и Samsung, которые инвестировали в Open Interconnect Consortium (OIC) и UPnP Forum. Очень хотят стать ведущей группой стандартов на базе открытого кода для IoT. IoTivity поддерживает протоколы обмена данными на RESTful, JSON и CoAP.
  11. OpenHAB — среда разработки для «умного дома» с открытым исходным кодом. Может (по задумке) работать на любом устройстве, способном запускать JVM. Модульная архитектура на уровне абстракции разделяет все используемые технологии и компоненты IoT на «элементы», которые поддерживает всевозможные правила, скрипты и процессы.
  12. OpenIoT — Java-based платформа для создания IoT-приложений. Облачная, разумеется. Платформа включает промежуточное ПО датчиков и сенсорной сети, а также онтологии, семантические модели и аннотации для представления объектов IoT. Судя по гитхабу — давненько не обновлялось.
  13. OpenRemote — система, которую изначально разрабатывали для автоматизации зданий. OpenRemote отличается широкой поддержкой редких сетевых спецификаций и протоколов, например 1-Wire, EnOcean, xPL, Insteon и X10. Все остальное стандартно — правила, сценарии и события. Разумеется облачные инструменты проектирования для пользовательского интерфейса, установка и настройка, а также удаленные обновления и диагностика.
  14. OpenThread — спин-офф от известной компании Nest (купленной Google за 3,2 млрд. долларов) с открытым исходным кодом. Заточен под устройства на 6LoWPAN, но есть поддержка и других протоколов. Работает на железных платформах от ARM, Atmel, Microchip, Dialog, Qualcomm и TI. OpenThread реализует сетевые роли модели «Thread»: End Device, Router, Leader, and Border Router.
  15. Physical Web / Eddystone — опен-сорс разработка Google. Это они пытались создать что-то очень похожее на iBeacon от Apple. Маячки на Bluetooth 4.0 с поддержкой «экономии энергии» (BLE) должны передавать URL-адреса на ваш смартфон. Идея состоит в том, что обладатели смартфонов могут взаимодействовать с любыми девайсами с поддержкой BLE, таким как парковочные счетчики, вывески или розничные продукты.
  16. PlatformIO — система разработана на Python и включает в себя IDE, генератор проектов и веб-менеджер библиотек. Изначально разрабатывалась для доступа к данным с конечных точек на Arduino и ARM Mbed. Сейчас имеются готовые прошивки-настройки для более чем 200 плат и интегрируется с Eclipse, Qt Creator и другими IDE.
  17. The Thing System — программное обеспечение на Node.js, предназначенное для смартфонов. Утверждается, что имеется поддержка «реальной автоматизации», а не просто уведомления — таких проектов, надо сказать, очень много. Есть что-то похожее на «самообучение» и искусственный интеллект, что позволяет организовать взаимодействие множества сценариев M2M взаимодействия. Отсутствие облачного компонента обеспечивает большую безопасность, конфиденциальность и контроль. Ну…
  18. ThingSpeak — проект с пятилетней историей. Фокусируется на регистрации датчиков, отслеживании местоположения, триггерах и предупреждениях и анализе всех этих данных. Пользователи ThingSpeak могут использовать версию MATLAB для анализа и визуализации данных, не покупая лицензию от Mathworks.
  19. Zetta — сервер-ориентированная IoT-платформа на Node.js и REST/WebSockets. Использует философию разработки, основанную «на потоках реактивного программирования» (не знаю что это). Рекламируется как API-first система с интерфейсами Siren hypermedia. Любое устройство представляется, как набор API REST, и связывается с облачными сервисами, где имеются инструменты визуализации и поддержки машинной аналитики Splunk. Платформа поддерживает любые Linux-платки и Arduino. Использует Heroku для создания геораспределенных сетей, что тоже звучит очень круто.
Мастер Йода рекомендует:  Как использовать HTTP-заголовок referer

А что в России?

Насколько мне известно, работы по созданию IoT-платформ в РФ идут днем и ночью. Тысячи энтузиастов перерабатывают гигабайты открытого исходного кода для создания систем или «умного дома», или для «сбора данных со счетчиков».

На большее фантазии не хватает.

Впрочем, если вы знаете российские хорошие годные проекты — напишите мне. Я сделаю обзор.

Пока же покажу одну систему, которую вполне можно назвать IoT-платформой — это iRidium Mobile (нет, не спутниковая система связи) из Нижнего Тагила. Земляки.

Это как раз платформа для управления «умным домом». По сути, это некий «облачный хаб», который умеет преобразовывать массу IoT-протоколов и сводить их к «порталу управления». Если еще понятнее — инсталляторы «умных домов», а также «умных зданий» и прочих систем интернет-автоматизации экономят массу времени, денег и усилий на разработке пользовательских интерфейсов и интеграции кучи всяких протоколов и данных. Можно подобрать соответствующие датчики и/или исполнительные устройства, подключить их «по инструкции», а все остальное отдать iRidium.

Где уже готовы интерфейсы — нужно только перетащить мышкой в нужное место и поставить «логотип заказчика». Ну, и чуток автоматизации там тоже есть — это же платформа.

Более подробно на сайте. Я же покажу несколько фоточек, которые с сайта и утянул:

Microsoft представила .NET Core 2.1

Microsoft объявила о выходе .NET Core 2.1. Новая версия программной платформы будет поддерживать Alpine Linux версии 3.7 и выше, а также чипы ARM32. Кроме того, разработчики обещают более эффективное использование инструментов и памяти. Платформа хорошо совместима с версией 2.0, и Microsoft рекомендует сразу мигрировать на 2.1. В ближайшее время ожидается несколько крупных обновлений. В частности, компания намеревается добавить поддержку Ubuntu 18.04.

Основные особенности .NET Core 2.1

К сентябрю 2020 года разработчики планируют выпустить версию платформы с долговременной поддержкой (LTS). Что касается проектов, разработка которых приостановлена, Microsoft рекомендует подождать релиза LTS-версии. Поддержка будет осуществляться в течение трёх лет.

Компания уделила особое внимание уменьшению времени сборки проекта. Особенно это заметно при работе над большими приложениями. По сравнению с версией 2.0 эффективность нового выпуска на порядок повысилась.


Платформа реализует новый способ установки и расширения пакетов инструментов через систему управления NuGet. Благодаря этому инструменты сразу готовы к работе на любой поддерживаемой архитектуре и операционной системе. Эта разработка действует подобно менеджеру пакетов npm.

Благодаря новым типам стало возможно уменьшить нагрузку на память. Например, тип Span позволяет передать часть массива, не делая его копии. Кроме того, в .NET Core 2.1 реализовано использование алгоритма сжатия brotli, поддерживаемого большинством браузеров, серверов и CDN.

Многоуровневая компиляция

Разработчики добавили в .NET Core 2.1 тестовую версию функции Tiered compilation. Обычно качество кода зависит от времени, потраченного на оптимизацию. Зачастую возникают ситуации, когда определённый участок программы выполняется всего один или несколько раз, и время, потраченное на оптимизацию, превосходит время на выполнение. При многоуровневой компиляции код обрабатывается с минимальными затратами времени. После этого компилятор отслеживает наиболее употребляемые методы и оптимизирует именно их.

16 ноября в 10:00, Воронеж, беcплатно

Поддержка .NET Core 2.1 уже включена в Visual Studio 15.7, Visual Studio for Mac и Visual Studio Code. Скачать платформу можно для Windows, macOS и Linux в двух версиях: .NET Core 2.1 SDK и .NET Core 2.1 Runtime. Одновременно выпущены ASP.NET Core 2.1 и Entity Framework Core 2.1.

Как и ранее, программная платформа будет поддерживать Raspberry Pi версии 2 и выше.

.NET Core — .NET становится кросс-платформенной

Продукты и технологии:

.NET Core, средства командной строки .NET Core, Microsoft .NET Framework, ASP.NET Core

В статье рассматриваются:

  • .NET Core — новая кросс-платформенная реализация .NET с целями, отличными от таковых в .NET Framework;
  • создание приложений ASP.NET Core, консольных программ, библиотек/инфраструктур и приложений Universal Windows Platform на .NET Core;
  • .NET CLI — набор средств командной строки, применимых для создания кросс-платформенных ресурсов .NET Core.

В Microsoft мы создаем новую реализацию .NET, названную .NET Core, которая позволит вам писать кросс-платформенный код для обработки рабочих нагрузок в облаках. Многих восхищает эта разработка с открытым исходным кодом, но что она означает на самом деле? Эта статья должна прояснить, что такое .NET Core сегодня, каковы ее цели и как она связана с Microsoft .NET Framework; кроме того, вы узнаете об основах работы со средствами командной строки, помогающих приступить к использованию .NET Core.

Что такое .NET Core?

Чтобы разобраться в том, что такое .NET Core, полезно понимать саму .NET. Говоря «.NET», многие подразумевают .NET Framework, но это не совсем так. .NET — стандарт ECMA, имеющий разные реализации: .NET Framework, Mono, Unity и теперь .NET Core. То есть немалая часть функциональности является общей для .NET Framework и .NET Core. Но .NET Core — новая реализация, построенная на несколько иных принципах.

Прежде всего .NET Core является кросс-платформенной. Она работает в Windows, OS X и нескольких дистрибутивах Linux. Кроме того, она поддерживает разные архитектуры процессоров. Мы занимаемся сейчас добавлением более широкой поддержки разных дистрибутивов Linux и архитектур процессоров, ставя конечной целью способность .NET Core работать на максимально возможном спектре устройств и операционных систем.

В то же время .NET Core имеет фундаментально модульную архитектуру. Исполняющая среда, библиотеки и компилятор — все это отдельные сущности, которые взаимодействуют через четко спроектированные интерфейсы. Это позволяет «заменять» компоненты под конкретные требования. Сами библиотеки тоже являются модульными и распространяются через NuGet, позволяя вам использовать лишь то, что реально необходимо; благодаря этому вы можете тонко настраивать объемы занимаемых .NET Core ресурсов в любой конкретной системе.

Кроме того, код, написанный под .NET Core, является портируемым; его можно подстраивать для выполнения на разнообразных поддерживаемых платформах. В зависимости от настроек в ваших проектах код, использующий .NET Core, может работать на платформах .NET Framework, Mono и Xamarin, в Windows 8 и Windows Phone, а также на Universal Windows Platform (UWP). Чтобы узнать больше, загляните в .NET Platform Standard (bit.ly/1Of6W1r).

Наконец, .NET Core будет производительной и создающей издержки только за реально используемые абстракции. Одна из целей .NET Core — сделать издержки каждой абстракции понятными разработчикам за счет реализации модели «плата только за то, что используется» (pay-for-play model), которая делает очевидными издержки от применения абстракций более высокого уровня для решения какой-либо задачи. Абстракции не даются даром, и эту истину никогда не следует скрывать от разработчиков. Помимо этого, .NET Core будет работать максимально производительно со стандартной библиотекой, которая минимизирует операции выделения памяти и общий объем памяти, занимаемой вашей системой.

Сценарии .NET Core

Сегодня существует четыре сценария, в которых вы можете писать код под .NET Core: кросс-платформенные веб-приложения ASP.NET, кросс-платформенные консольные приложения, кросс-платформенные библиотеки и инфраструктуры, а также UWP-приложения.

ASP.NET Core 1.0, спроектированная с расчетом на максимальное быстродействие, — это кросс-платформенный веб-стек для .NET Core. Если вы когда-нибудь хотели сделать нечто вроде развертывания своего веб-приложения ASP.NET в контейнере в Linux, то теперь это возможно. Чтобы узнать больше о широкой функциональности ASP.NET Core, изучите документацию по ссылке bit.ly/1TqPcIo.

Различия между кросс-платформенными библиотеками и инфраструктурами заключаются в степени масштабирования.

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

Различия между кросс-платформенными библиотеками и инфраструктурами заключаются в степени масштабирования. Библиотеки являются одним из самых естественных кандидатов, на основе которых следует программировать в .NET Core. Но при гораздо больших масштабах инфраструктуры для распределенных вычислений тоже представляют собой хороших кандидатов.

Наконец, UWP-приложения, которые ориентированы на семейство устройств с Windows 10, выполняются в .NET Core. Вы можете создать полнофункциональное UWP-приложение, которое включает библиотеки .NET Core, помогающие в разработке приложений Windows 10 с богатой функциональностью.

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

Если у вас есть ресурсы .NET Framework, которые попадают в один из этих четырех сценариев, или если вы хотите перейти на новую технологию, зайдите на bit.ly/1Q1Q18q, где вы сможете узнать, как приступить к написанию кода под .NET Core.

Как .NET Core соотносится с .NET Framework

Большинство из вас освоило и полюбило .NET в виде .NET Framework. Как же .NET Core соотносится с .NET Framework? Первое, что нужно иметь в виду, — вы используете для написания кода все те же языки: C#, F#, Visual Basic. Ваш опыт в написании кода должен показаться очень похожим. Однако .NET Core — это новый стек, а не подмножество .NET Framework. Лучше всего рассматривать .NET Core и .NET Framework как два стека, которые во многом совпадают и развиваются параллельно.

.NET Framework есть и будет стеком, используемым для написания настольных приложений под операционные системы от Windows 7 до Windows 10. По сути, код .NET Framework и .NET Core может гармонично сосуществовать в одном решении. Например, рассмотрим сценарий, где .NET Framework GUI (вроде Windows Forms) использует сервисы, написанные с применением .NET Core.


Рассматривать сходства и различия .NET Core и .NET Framework полезно с двух точек зрения: перекрытия API и возможностей исполняющей среды. На рис. 1 показано перекрытие API между двумя платформами.

Рис. 1. .NET Framework и .NET Core используют общее подмножество API

.NET Framework APIs .NET Framework API
Shared APIs Общие API
.NET Core APIs .NET Core API

Существуют .NET API, реализованные как в .NET Core, так и в .NET Framework (хотя иногда с разными нижележащими реализациями). В то же время .NET Core и .NET Framework имеют не совпадающие API и возможности. Скажем, в .NET Framework есть несколько инфраструктур GUI и API, специфичных для Windows, которые отсутствуют в .NET Core. Аналогично .NET Core имеется кросс-платформенные средства и API, отсутствующие в .NET Framework.

Кроме того, .NET Framework — это компонент Windows, обслуживаемый через Windows Updates. .NET Core использует совершенно другую модель того, где он размещается и как обслуживается. .NET Core состоит из NuGet-пакетов с исполняющей средой, устанавливаемой App-Local. А значит, приложения могут «носить с собой» .NET Core, что позволяет им сосуществовать бок о бок с другими экземплярами .NET Core на машине или устройстве. Поэтому обслуживание выполняется индивидуально для каждого приложения и через диспетчер пакетов, а не глобально через обновления ОС.

Возникает практический вопрос: если вы пишете что-то в одном стеке, будет ли это работать в другом? Как и в большинстве ответов в жизни, это зависит от ряда факторов. Если используемые вами API реализованы на обеих платформах, ваш код должен выполняться и в .NET Core, и .NET Framework, требуя сравнительно небольших усилий с вашей стороны. Однако, если у вас есть зависимости от исполняющей среды или если вы используете API, недоступные в одном из стеков (например, библиотеку для работы с XAML UI), ваш код не будет работать в обоих стеках. .NET Portability Analyzer, доступный как утилита командной строки (bit.ly/1Sd8oIK) или как расширение Visual Studio (bit.ly/1LqX0aF), — инструмент, который проанализирует ваши файлы .dll и сгенерирует отчет о том, является ли ваш код портируемым с .NET Framework в .NET Core. В будущем мы выпустим больше инструментов, помогающих в портировании.

Командная строка: ваша точка входа для .NET Core

.NET Core поставляется с новым и переработанным базисным инструментарием, применяемым для разработки приложений. Этот инструментарий называется .NET Core CLI (сокращение от .NET Core Command-Line Interface). Как и другие части .NET Core, он тоже имеет открытый исходный код (GitHub.com/dotnet/cli) и активное сообщество, которое участвовало в его создании.

Для введения нового инструментария было несколько причин. Прежде всего нам требовалась поддержка базовых сценариев разработки на всех платформах, поддерживаемых .NET Core. Учитывая разнообразие платформ, хорошая среда командной строки — отличный фундамент, на который можно опереться; в конце концов, командная строка имеется на каждой из платформ по умолчанию.

В качестве логического расширения мы хотели обеспечить одинаковую UX (пользовательскую среду) на всех поддерживаемых платформах. Вы сможете переходить между Linux, Windows и OS X, не осваивая заново инструментарий, синтаксис или семантику. Они одинаковы на всех платформах. Также одинаковы шаблоны использования и даже их синтаксис.

Эта идея единого базисного инструментария (набора инструментов), применяемого на всех платформах, также распространяется на инструментарий более высокого уровня, а именно на Visual Studio Code и Visual Studio. Эти более высокоуровневые инструменты будут размещаться поверх .NET CLI. То есть, когда вы создаете приложение .NET Core в Visual Studio, для компиляции будут вызываться средства .NET CLI.

Знакомство с .NET Core Command-Line Interface

Самый простой способ приступить к работе с .NET Core CLI — следовать руководству Getting Started (aka.ms/dotnetcoregs). Самая суть в том, что вы скачиваете установщик для своей платформы (или регистрируете новый канал apt-get в случае Ubuntu), устанавливаете инструменты и вы готовы к работе. Установщики позаботятся о записи папки установки в вашу системную переменную окружения PATH во всех поддерживаемых операционных системах, а также о настройке любых других переменных окружения, необходимых CLI.

После этого вы можете начать работу запуском драйвера dotnet и передачей какой-либо команды (которую мы также называем операцией [verb]). Драйвер отвечает за выполнение команды и передачу ей любых аргументов. На момент написания этой статьи пакет CLI поставляется с поддержкой команды, перечисленных в табл. 1. Конечно, к тому моменту, когда вы будете читать эту статью, мы, по-видимому, добавим больше команд, что позволит повысить продуктивность вашего труда.

Табл. 1. Некоторые распространенные команды .NET CLI, которые можно использовать уже сегодня

Команда Описание
dotnet new Инициализирует допустимый проект либо для библиотеки классов, либо для консольного приложения, используя C# в качестве языка
dotnet restore Восстанавливает зависимости, определенные в файле project.json для данного проекта. Зависимостями обычно являются NuGet-пакеты, используемые в вашем приложении
dotnet build Компилирует ваш код! Эта команда создаст двоичный файл на Intermediate Language (IL) для проекта. Если проект — консольное приложение, сгенерированным выводом будет исполняемый файл, который вы сможете тут же запустить. По умолчанию команда build генерирует сборки и исполняемые файлы (если применимо) в подкаталоге bin того каталога, из которого она была вызвана
dotnet test Хороший инструментарий не должен поставляться без поддержки выполнения тестов. Эта команда позволяет выполнять наборы тестов, используя средство запуска (runner), которое можно указать в файле project.json. В настоящее время поддерживаются средства запуска тестов xUnit и NUnit
dotnet publish Публикует приложение для выполнения на целевой машине
dotnet pack Команда pack упаковывает проект как NuGet-пакет. На выходе дает набор файлов nupkg, которые можно потом закачивать в свои каналы или использовать в операции restore, применяя переопределение локальной папки (local folder override)
dotnet run Команда run компилирует и выполняет ваше приложение. Ее можно рассматривать как аналог Ctrl+F5 — только без Visual Studio

Помимо любых команд, поставляемых в пакете, вы можете добавлять дополнительные команды как инструменты в project.json, а затем восстанавливать их. Они упаковываются в NuGet-пакет, который предоставляет удобную и простую в использовании модель расширения.

Заключение

Мы надеемся, что вы получили некоторое представление о .NET Core и заинтересованы в написании .NET-кода, который можно выполнять на разных платформах. Как новый стек она предоставляет некоторые потрясающие возможности, недоступные в .NET Framework. Кроме того, в .NET CLI введены отличные средства командной строки, образующие фундамент для средств разработки и интегрируемые в другие инструменты, такие как Visual Studio и Visual Studio Code.

Наконец, мы знаем, что у вас накоплено много кода, написанного для .NET Framework, и мы хотели бы, чтобы этот ресурс продолжал расти по мере развития .NET Framework. Мы представляем себе мир, где .NET Framework и .NET Core применяются совместно в системах, использующих сильные стороны обоих стеков.

Если вы хотите узнать больше и, возможно, поучаствовать в разработке, то вот несколько мест, с которых стоит начать:

  • .NET Core Runtime (GitHub.com/dotnet/coreclr);
  • .NET-библиотеки (GitHub.com/dotnet/corefx);
  • интерфейс и инструментарий командной строки (GitHub.com/dotnet/cli);
  • компилятор Roslyn (C# и Visual Basic) и языковой инструментарий для Visual Studio (GitHub.com/dotnet/roslyn);
  • наша документация на .NET Core (GitHub.com/dotnet/core-docs).

У нас намного больше .NET-проектов с открытым исходным кодом, над которыми сейчас ведется активная работа. Если вы заинтересованы увидеть какие-то из них, обратите внимание на .NET Foundation, независимую организацию, которая поддерживает открытую разработку для .NET. Microsoft внесла свой вклад в несколько проектов .NET Foundation; также следует отметить вклад других компаний, таких как Xamarin, Umbraco, Salesforce, и сообщества .NET. Узнать больше о них и внести свой вклад можно на DotNetFoundation.org/projects.

Филипп Картер (Phillip Carter) — менеджер программ в группе .NET в Microsoft. Увлекается теорией языков программирования, в том числе системных; его часто можно застать поздним вечером в спорах с друзьями о моделях параллельной обработки. Надеется, что однажды поведение всех систем в период выполнения можно будет выражать системой типов, что позволит человеческой расе подняться на новый уровень мышления. С ним можно связаться по адресу phcart@microsoft.com.

Златко Кнежевич (Zlatko Knezevic) — менеджер программ (PM) в группе .NET в Microsoft. Присоединился к Microsoft в 2005 году, поначалу работал в CEE как разработчик-идеолог, а затем стал PM в группе SQL Server. В 2015 году перешел в группу .NET в качестве PM и с тех пор работает над кросс-платформенной .NET Core. С ним можно связаться по адресу Zlatko.Knezevic@microsoft.com.

Выражаем благодарность за рецензирование статьи эксперту Microsoft Иммоу Лэндверту (Immo Landwerth) и группам .NET Core и Framework Program Management.

The code download links seem to be broken http://download.microsoft.com/download/8/8/C/88C0F22E-2EFD-4E87-A607-BBF2FE322A75/Code_SmithCore0516.zip

Phillip Carter and Zlatko Knezevic give a clarifying explanation about what .NET Core is and how it’s positioned relative to the Microsoft .NET Framework, plus they provide an overview of the command-line experience that Microsoft is currently shippi.

.NET Core и C# — технологии, за которыми будущее

Я работал с .NET Core около года и сейчас могу сказать, что был очень впечатлен. Поскольку наша компания создает приложения для разработчиков, которые базируются на .NET Core, я ощущаю нас причастными к тому, что сейчас происходит. Каждый день мы общаемся с клиентами, которые уже используют .NET Core в своих разработках. .NET Core быстро завоевывает популярность, и я уже предсказываю огромную потребность в разработчиках на C# и .NET Core в 2020 году.


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

Мастер Йода рекомендует:  Гиперссылки в HTML

6 вещей, которые стоит знать о C# и .NET Core

Узнайте, почему .NET Core возводит C# в топ списка наиболее популярных языков программирования.

1) Простота в изучении

Если вы уже работали с С, Java или даже JavaScript, синтаксис C# покажется Вам довольно знакомым. Сам синтаксис достаточно прост в понимании и чтении. Исходя из индекса TIOBE, приведенного выше, уже сейчас большинство разработчиков могут легко перейти с Java или C.

В сети существует много онлайн-ресурсов для изучения C#. Большинство из них – бесплатные, другие же можно использовать за умеренную плату.

  • Pluralsight – Отличный обучающий контент за доступную цену
  • Microsoft Virtual Academy – Бесплатные видео и оценивание
  • Microsoft Getting Started with C# — Бесплатные интерактивные туториалы

2) Современные возможности языка

.NET существует на протяжении длительного времени и за последние 15 лет достаточно сильно преобразился и улучшился. На протяжении лет я отмечал такие прекрасные нововведения как MVC, обобщения, LINQ, async/await операторы и многое другое. Как человеку, который лично посвятил себя изучению языка, я рад наблюдать, как он модернизируется. Многое претерпело изменения с появлением .NET Core. Взять тому примером стек технологий ASP.NET. Все эти 15 лет язык C# был с нами, и он продолжает совершенствоваться.

Вот некоторые наиболее примечательные особенности:

  • Строгая типизация
  • Качественные библиотеки классов
  • Асинхронное программирование – шаблон async/await
  • Сборка мусора, автоматическое управление памятью
  • LINQ – интегрированный язык запросов
  • Обобщения – примером List , Dictionary
  • Управление пакетами
  • Общие бинарные файлы для разных платформ и фреймворков
  • Простота в использовании фреймворков для создания MVC веб-приложений и REST API.

3) Универсальность: веб, мобильные, серверные, настольные приложения

Одним из наиболее значимых плюсов C# в частности и .NET в целом, я считаю, является его многогранность. Я могу писать программы для ПК, вести веб-разработку, создавать фоновые сервисы или даже мобильные приложения (спасибо Xamarin!). Кроме того, все, что мне нужно знать, дабы скомпоновать все UI-коды вместе (чего я все же стараюсь избегать), это, кроме C#, всего лишь немного JavaScript’а (+ TypeScript). Шаблоны ASP.NET Core в свою очередь при создании клиентских библиотек даже используют макеты Бутстрапа и npm.

Универсальность языка — довольно весомый плюс, так как ваш вклад в его изучение может найти применение в широком спектре возможностей. Ваши навыки очень мультиплатформенные. Если пожелаете, Вы можете легко «перескочить» с разработки веб-приложений на мобильные. Пожалуй, это уникальное отличие от других языков, заточенных только под серверную часть.

Не стоит забывать о первоклассной поддержке Microsoft Azure. Нужно задеплоить проект на облако? Нет ничего проще: сия операция осуществляется всего лишь в пару кликов. Поддержка Docker-контейнеров также присутствует, что значительно упрощает деплой приложений на AWS или другие хостинги на Ваше усмотрение.

4) Качественные инструменты разработчика

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

Плюс, за вами всегда остается возможность писать коды для .NET Core в любом текстовом редакторе в виде обычных текстовых файлов. Вы также можете использовать Visual Studio Code на любой ОС в качестве отличного редактора кода. Даже те из нас, кто никогда не желает расставаться с этим Vim или Emacs, могут вести разработку на C#. Можно также установить плагины для Visual Studio и добавлять свои «горячие клавиши».

Вся экосистема .NET изобилует прекрасными инструментами. К примеру, вряд ли я смогу представить жизнь без Resharper`а или JetBrains. Существуют десятки классных инструментов, включая смеси открытого кода и коммерческих продуктов.

5) Обобщение навыков

.NET обладает очень хорошим набором базовых библиотек. В отличие от Node.js, такие простые строковые функции, как LeftPad(), уже встроены. Подобное разнообразие стандартных библиотек значительно уменьшает потребность в сторонних пакетах. Также благодаря вмешательству Microsoft, мы можем использовать такие технологии, как JSON.NET и прочее.

Microsoft обеспечивает качественный набор шаблонов и их реализаций на .NET. К примеру, сервис для работы с данными (Entity Framework) и MVC уже встроены. Большинство разработчиков именно ими и пользуется. Подобный подход значительно упрощает взаимодействие между командами и ускоряет понимание, как проект работает. Благодаря этому, Ваши знания и навыки становятся более универсальными.

6) Код .NET Core в свободном доступе

Одним из наиболее значимых событий, которое когда-либо происходило на .NET, является публикация исходного кода. Теперь каждый на GitHub’е может просматривать, вносить правки и дополнять его. Пожалуй, большинство людей даже никогда не думали о том, что подобное может когда-либо произойти.

Как разработчику, время от времени Вам необходимо «заглядывать за ширму», дабы понимать, как на самом деле работает код. К примеру, раньше я мог только гадать, закрывает ли вызов метода Dispose() на базе данных соединение или нет. Если же Вы можете заглянуть в исходный код, большинство схожих вопросов отпадает.

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

Заключение

На протяжении лет я читал о программистах-полиглотах и о новых классных языках. В разное время люди писали на Ruby, Python, Scala, Go, Node.js, Swift и прочем. Приятно видеть, что Microsoft, сообщество сделали с .NET Core и как он вознесся в ранг первоклассной платформы. Я даже портировал .NET приложения на Maрc!

Проблемой многих существующих языков программирования является то, что они узкоспециализированы. Ruby и PHP прекрасно подходят для веб-приложений. Swift или Objective C лучшего всего использовать для IOS или MacOS. Если нужно написать серверное приложение, можно использовать Python, Java и так далее. Пожалуй, кроме C#, только JavaScript и Java могут считаться языками широкого профиля.

Мне бы было трудно применить навыки для решения различных задач, если бы я был вынужден работать со многими языками программирования. Это ограничивает возможности. Мне нравится универсальность C#, нравится то, что его можно использовать для разных типов приложений. Теперь, поскольку .NET Core так же подходит и для MacOS и Linux, больше нет никаких лимитов на его применение.


Надёжен ли сейчас ASP NET Core в плане стабильной работоспособности?

Я отвечу немного нестандартно. Давайте попробуем разобраться вместе.

Вот есть компания X. Компания X выпускает платформу, которую используют сотни тысяч разработчиков по всему миру, учат ее, вкладывают знания, ресурсы.

И вот компания X берет и через 2 года меняет API, меняет платформу так, что теряется обратная совместимость, уничтожает часть компонентов, меняет среду исполнения, что приложения, написанные для N-1 теперь не работают в N.

И самое интересное, что это случается раз. Компании разработчики это простили, схавали и перепилили свое ПО. Затем еще через 2 года. Затем еще через 2 года. Затем еще через 2 года. И т.п.

Вопрос — будете ли вы, зная все это, вкладывать свои силы, знания, умения, время вкладывать в продукты компании X?

Вопрос риторический. Каждый отвечает на него по-своему.

Microsoft .NET Framework: зачем он нужен и как установить на Windows

Если вы часто устанавливаете программы, то наверняка сталкивались с ошибками Microsoft .NET Framework . Две самых распространённых — он либо не установлен, либо установлена не та версия.

Почему так происходит? Что это такое и зачем нужен NET Framework ?

Что такое .NET Framework?

Наверное, вы знаете, что основное занятие программистов — написание кода. При этом они используют различные языки программирования, позволяющие сказать компьютеру, что он должен делать:

Но есть одна проблема — языки программирования довольно примитивны. С их помощью можно легко выполнять простые действия вроде сложения и умножения. А всё остальное требует долгой и усердной работы. Хотите вывести текст или изображения на экран? Тогда придётся написать много кода, используя самые простые элементы языка.

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

К примеру, .NET Framework берёт на себя все операции по отрисовке окон на экране. Программисту остаётся только вставить текст, продумать меню программы, задать поведение кнопок, когда на них нажимает пользователь и т.д.

Но .NET Framework — намного больше, чем просто набор дополнительного кода. Он включает в себя инструменты, призванные сократить время разработки и дополнительные API , которые программисты могут использовать для простого взаимодействия с такими сервисами как Windows Store . Вместо того чтобы вручную писать весь необходимый код для поддержки универсальной платформы Windows , можно воспользоваться .NET Framework :

Есть только один недостаток разработки приложений с использованием .NET Framework — их невозможно запустить, если .NET не установлен в вашей системе.

.NET Framework состоит из двух частей. Первая часть включает в себя набор заранее написанного кода ( официально именуемого SDK , Dev Packs или «Пакеты разработчика» ). Вторая часть включает в себя программу, которая может интерпретировать код .NET Framework в команды для операционной системы. Эта часть, которую называют « средой выполнения », позволяет запускать программы, написанные с использованием .NET Framework .

В этом отношении .NET Framework напоминает Java — для использования написанных на нём приложений необходимо скачать среду выполнения Java Runtime Environment .

Говоря кратко, зачем нужен Microsoft NET Framework : если вы простой пользователь, который не собирается заниматься программированием, вам потребуется только среда выполнения .NET Framework .

Как установить .NET Framework

На большинстве компьютеров на Windows уже установлен .NET Framework , но его версия может быть устаревшей. Например, с Windows 8 и 8.1 поставляется версия 4.5.1 , а с Windows 10 — версия 4.6 , 4.6.1 или 4.6.2 .

На момент написания статьи самая свежая версия — .NET Framework 4.7 . Именно её мы и будем устанавливать:

.NET Framework можно установить и через Центр обновления Windows . Но многие отключают обновление Windows , поэтому данный метод будет предпочтительнее.

Перед установкой — .NET Framework 4.7 можно установить на Windows 10 , Windows 8.1 и Windows 7 SP1 как на 32-битные, так и на 64-битные системы. Чтобы установка прошла без ошибок, Microsoft рекомендует иметь на жестком диске минимум 2.5 ГБ свободного пространства.

Microsoft предлагает два вида установщиков: веб-установщик и автономный установщик. Веб-установщик весит меньше 2 МБ, и скачивает все необходимые компоненты во время инсталляции. Поэтому вам потребуется стабильное соединение с интернетом.

Автономный установщик весит около 60 МБ, и не требует доступа к интернету во время инсталляции.

Оба установщика содержат одинаковые версии NET Framework , но мы предпочитаем использовать автономный установщик. Он надёжнее, и всегда будет под рукой, если потребуется переустановить .NET Framework . После скачивания процесс установки не должен вызвать затруднений — просто следуйте инструкциям, появляющимся на экране. И тогда вы быстрее поймете, зачем нужен NET Framework 4 .

.NET Framework 4.7 Веб-установщик

.NET Framework 4.7 Автономный установщик

Обратите внимание, что версия 4.7 — это выполняемое обновление версий 4 , 4.5 , 4.5.1 , 4.5.2 , 4.6 , 4.6.1 и 4.6.2 . Поэтому не удаляйте предыдущие версии после установки. .NET Framework 3.5 SP1 и более старые версии устанавливаются отдельно.


По умолчанию .NET Framework инсталлирует английскую версию независимо от того, какой вы используете установщик. Для локализации нужно скачать соответствующий языковой пакет. На данный момент языковые пакеты для версии 4.7 доступны только в виде автономных установщиков.

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

Языковой пакет .NET Framework 4.7

Ещё кое-что о .NET Framework

Еще одна причина, зачем нужен NET Framework . Несколько лет назад Microsoft открыла исходный код .NET Framework , позволив всем желающим вносить свой вклад в разработку платформы. В результате Microsoft стала самой активной организацией на GitHub .

Что это значит для вас? В сущности, то, что приложения, написанные на .NET Framework в будущем станут только популярнее и качественнее. Поэтому, почему бы не установить .NET Framework прямо сейчас?

Данная публикация представляет собой перевод статьи « Microsoft .NET Framework: Why You Need It and How to Install It on Windows » , подготовленной дружной командой проекта Интернет-технологии.ру

Archives: Posts

#24 выпуск подкаста DotNet&More: Drinkcast с британцами и не только (осторожно English)

Юбилейная встреча SpbDotNet №50 была крайне необычной: спонсором был Газпром, спикеры из Британии, а доклады были на английском. Не менее экспериментальным получился и Drinkcast. В этом выпуске: Machine Learning на .Net, .Net vs Java, работа в UK и не только. Внимание, выпуск на английском.
PS: если у Вас возникнет желание помочь сообществу сурдопереводом данного выпуска, пишите в vk, twitter, telegram.

Спасибо всем кто нас слушает. Не стесняйтесь оставлять обратную связь и предлагать свои темы.

  • [0:01:03] .Net, not Java
  • [0:03:45] Machine Learning
  • [0:09:50] Future of .Net
  • [0:13:16] Job Market in UK
  • [0:16:20] Requirements to English level
  • [0:31:33] .Net vs Java
  • [0:34:36] Clouds

#23 выпуск подкаста DotNet&More: Архитектура, вопросы на собеседование и не только

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

Спасибо всем кто нас слушает. Не стесняйтесь оставлять обратную связь и предлагать свои темы.

Ссылка для скачивания:

  • [0:00:37] .Next Libraries
  • [0:06:31] Чем занимаются архитекторы
  • [0:28:09] Как стать архитектором
  • [0:43:53] Разбор результатов конкурса
  • [0:45:39] Default Interface Members
  • [1:00:04] Задачи на собеседование и велосипеды
  • [1:15:30] Новости одной строкой

#22 выпуск подкаста DotNet&More: Бесплатный билет на DotNext, F# vs C# и не только

Ровно месяц остался до крупнейшей .Net конференции DotNext и мы рады объявить конкурс, победителю которого достанется бесплатный билет. Для того чтобы поучаствовать, Вам достаточно поделиться своими любимыми вопросами, задачками, тестовыми заданиями на собеседование. Создавайте pull requests в наш репозиторий: https://github.com/dotnetmore/job-interview-competition.Дедлайн 16 октября.

В новом выпуске мы пригласили участников программного комитета Романа Неволина и Максима Аршинова дабы не только обсудить конференцию, но и похоливарить на тему C#8 как функциональный язык программирования, нужен ли F#, казалось бы, при чем тут Kotlin и не только.

Спасибо всем кто нас слушает. Не стесняйтесь оставлять обратную связь и предлагать свои темы.

  • [0:00:45] Условия конкурса
  • [0:02:24] Конференция DotNext
  • [0:05:48] C#8
  • [0:08:09] C# vs Java
  • [0:11:42] Почему нет Unity докладов на DotNext
  • [0:21:03] C#8 и функциональное программирование
  • [0:45:12] Нужен ли F#?
  • [0:53:07] Функциональное программирование как мейнстрим
  • [0:59:49] Kotlin
  • [1:12:42] Анемичная vs Богатая модель
  • [1:21:31] Code Review
  • [1:31:24] Новости одной строкой

#21 выпуск подкаста DotNet&More: Blazor, NetCore 3.0 Preview, C#8 и не только

Поздравляем всех .Net разработчиков с профессиональным праздником!
В том время как .Net Core 3.0 подходит к финишной прямой мы решили поделиться нашим опытом использования preview версии. Кроме того, мы пригласили гостя, который готов рассказать все что думает про Blazor и WebAssembly.
Более того, у нас появилась новая рубрика “Новости одной строкой”! В ней мы перечисляем топики, которые не вошли в основной стрим, но достойны упоминания.

Спасибо всем кто нас слушает. Не стесняйтесь оставлять обратную связь и предлагать свои темы.

  • [0:03:52] DotNet Core 3.0 на проде
  • [0:08:18] Жизнь на preview версиях
  • [0:13:46] AspNet Core 3.0 и его фитчи
  • [0:18:54] Blazor
  • [0:23:52] Shared business logic и Xamarin
  • [0:46:11] Очередной оффтопик про Go
  • [0:52:37] C#8 на проде
  • [1:13;46] Новости одной строкой

Ссылки (off topic):

#20 выпуск подкаста DotNet&More: Game Dev на завтрак и не только


Многие из нас пришли в программирование с желанием разрабатывать игры, но увлекательный мир кровавого энтерпрайза настолько захлестнул, что эта мечта так и остается мечтой. И у нас так и остается виcеть вопрос: как же живет этот прекрасный или ужасный GameDev мир.

В юбилейном выпуске DotNet&More мы пригласили гостя, Solution Architect Game Dev направления, Алексея Стрельцова.
Что из себя представляет разработка на Unity с технической и организационной точки зрения? Есть ли деньги в GameDev? Стоит ли вообще менять уютное формочкописание и уходить в разработку игр?

Спасибо всем кто нас слушает. Не стесняйтесь оставлять обратную связь и предлагать свои темы.

  • [0:01:45] Отличие Game Dev разработки от классического энтерпрайза
  • [0:20:52] Производительность
  • [0:51:17] GC в Unity и Allocation Free Code
  • [1:04:47] Мифы о GameDev: зарплаты, кранчи и проч.
  • [1:14:40] Переход в GameDev

#19 Кишочки за завтраком и не только

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

Спасибо всем кто нас слушает. Не стесняйтесь оставлять обратную связь и предлагать свои темы.

  • [0:03:20] Зачем .Net разработчику знать внутренности платформы?
  • [0:05:31] “Pro .NET Memory Management” Konrad Kokosa
  • [0:22:38] Оптимизация производительности
  • [0:33:26] Многопоточность
  • [0:52:17] Тестирование многопоточнных приложений
  • [0:55:23] Многопоточность и собеседования

#18 ASP.NET Core Developer Roadmap и не только

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

Спасибо всем кто нас слушает. Не стесняйтесь оставлять обратную связь и предлагать свои темы.

  • [0:00:58] ASP.NET Core Developer Roadmap
  • [0:47:13] Чему я научился на своём горьком опыте (за 30 лет в разработке ПО)

#17 WCF наносит ответный удар и не только

Лето, пора отпусков и каникул. Но наш подкаст не знает слова отдых. Есть ли будущее у WCF и WWF? Чего ждать от собеседований? Как собрать fat binary за 2 шага? Обо всем этом и не только в нашем новом выпуске.

Спасибо всем кто нас слушает. Не стесняйтесь оставлять обратную связь и предлагать свои темы.

  • [0:00:55] You can now download the new Open Source Windows Terminal
  • [0:10:01] WF and WCF Given to the Community
  • [0:31:12] Introducing Microsoft.FeatureManagement
  • [0:38:31] Расцвет и упадок Visual Basic
  • [0:59:26] .NET Interview Questions
  • [1:06:19] C# Interview Questions
  • [1:18:49] Announcing .NET Core 3.0 Preview 6
  • [1:30:54] Tips on Container Tools for Visual Studio

#16 Windows Terminal, TryNet и не только

Традиционно, после яркого мая наступает июньское затишье. А это значит, что стоит откопать и обсудить темы, затерявшиеся за громом майских конференций. Стоит ли ждать Windows Terminal? Что такое TryNet? 20 библиотек, которые должен знать любой разработчик. Об этом и не только в новом выпуске нашего подкаста.

Спасибо всем кто нас слушает. Не стесняйтесь оставлять обратную связь и предлагать свои темы.

  • [0:00:22] Windows Terminal
  • [0:15:09] Try.Net
  • [0:20:17] Internet Explorer в Chromium
  • [0:25:26] Net Core Service Workers
  • [0:32:01] Best 20 dot Net Core Libraries Every Developer should know
  • [1:22:39] Оптимизация сборки мусора в высоконагруженном .NET сервисе

#15 Build2020 и не только

Во второй части длинного обсуждения конференций мы решили затронуть недавний Build2020 и сравнить его с .Next. Стоит ли ходить на рекламные конференции? Есть ли будущее у machine learning в .Net? Любить или ненавидеть функциональное программирование? Об этом и не только в нашем выпуске под номером 15.

Спасибо всем кто нас слушает. Не стесняйтесь оставлять обратную связь и предлагать свои темы.

  • [01:25] Build 2020
  • [24:21] ML.NET
  • [56:30] Функциональное программирование

#24 выпуск подкаста DotNet&More: Drinkcast с британцами и не только (осторожно English)

Юбилейная встреча SpbDotNet №50 была крайне необычной: спонсором был Газпром, спикеры из Британии, а доклады были на английском. Не менее экспериментальным получился и Drinkcast. В этом выпуске: Machine Learning на .Net, .Net vs Java, работа в UK и не только. Внимание, выпуск на английском. PS: если у Вас возникнет желание помочь сообществу сурдопереводом данного выпуска, …

Добавить комментарий