.net core на linux, devops на коне

Критика

Реализация платформы .NET Framework вызывала и вызывает множество нареканий.

  • С технической точки зрения платформа также подвергалась критике из-за отсутствия поддержки вызовов Streaming SIMD Extensions (SSE) в управляемом коде. В Mono решили эту проблему, добавив поддержку SIMD Extensions версии 2.2 в пространство имён . В состав .NET Framework 4.6 входит новый JIT-компилятор RyuJIT, поддерживающий SIMD через пространство имён .
  • Новые версии платформы (3.5 и далее) вызвали новую волну недовольства тем, что они не предустанавливаются в версии Windows, предшествовавшие выходу Windows 7, что вынуждает пользователей тратить значительное время на их установку.

2017

Поддержка .NET Core 2.0 продуктами Red Hat

Компания Red Hat 25 августа 2017 года объявила о планах обеспечить поддержку .NET Core 2.0 в рамках своего семейства Open Source технологий. .NET Core 2.0 позволяет создавать приложения .NET для различных платформ и развертывать их как на Red Hat Enterprise Linux, Red Hat OpenShift Container Platform, так и на других платформах.

.NET Core 2.0

.NET Core 2.0 теперь входит в состав Red Hat Developer Program, поддерживает .NET Standard 2.0, что обеспечивает оптимизированную совместимость с платформами и переносимость при использовании любых сред исполнения и рабочих нагрузок .NET. Она также помогает оптимизировать упаковку приложений за счет более удобного доступа к стеку для разработки веб-приложений ASP.NET Core 2.0 и ORM-прослойке Entity Framework Core 2.0. Кроме того, при использовании с Red Hat Enterprise Linux или Red Hat OpenShift Container Platform .NET Core 2.0 позволяет создавать современные контейнеризированные приложения на языках программирования C#, F# и Visual Basic.

Поддержка в продуктах Red Hat

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

  • Red Hat Enterprise Linux
  • Red Hat Enterprise Linux Atomic Host
  • Red Hat OpenShift Container Platform
  • Red Hat OpenShift Online
  • Red Hat OpenShift Dedicated
  • Red Hat OpenStack Platform

Доступность

В ближайшее время .NET Core 2.0 станет доступна для соответствующих продуктов Red Hat в виде пакетов в репозитории (rpm) или в качестве контейнерных образов.

За счет поддержки .NET на платформе Red Hat Enterprise Linux мы можем предложить рынку полностью открытую платформу разработки, обеспеченную поддержкой корпоративного уровня и гарантирующую надежную промышленную эксплуатацию рабочих нагрузок .NET на системах, отличных от Windows, — заявил Гарри Моуэр (Harry Mower), директор направления Developer Programs, Red Hat.

Релиз .NET Core 2.0

14 августа 2017 года корпорация Microsoft анонсировала релиз .NET Core 2.0 — модульной платформы .NET с открытым исходным кодом. Данная версия обеспечивает значительное повышение производительности Runtime и Framework. Кроме этого реализована поддержка .NET Standard 2.0, которая более чем удваивает количество API, доступных для разработчиков. .NET Core 2.0 уже доступен в Azure Web Apps.


Список основных изменений:

  • Runtime:
    • Значительные улучшения производительности Runtime и Framework;
    • Внедрён .NET Standard 2.0;
    • Обеспечена поддержка еще 6 платформ, включая Debian Stretch, macOS High Sierra и др.;
    • RyuJIT — это x86 JIT в .NET Core 2.0;
    • Обеспечена предварительная поддержка Linux ARM32.
  • SDK:

    • dotnet restore теперь является неявной командой;
    • Проекты NET Core и .NET Standard могут ссылаться на пакеты и проекты .NET Framework NuGet;
    • .NET Core SDK может быть собран из репозитория открытого исходного кода.
  • Visual Studio:

    • Live Unit Testing поддерживает .NET Core;
    • Реализованы улучшения навигации по коду;
    • C# Azure Functions поддерживаются «из коробки»;
    • Обеспечена поддержка CI/CD в контейнерах.

Разработчики могут установить .NET Core 2.0 вместе с .NET Core 1.0 и 1.1. Существующие .NET-приложения, при необходимости, могут продолжать использовать Runtime 1.0 и 1.1.

Исходные тексты компонентов .NET Core распространяются под лицензиями MIT и Apache 2, ASP.NET Core поставляется под лицензией Apache 2. Кроме Windows, заявлена поддержка Red Hat Enterprise Linux 7, CentOS 7, Debian 8/9, Fedora 25/26, SUSE Linux Enterprise Server 12 SP2+, openSUSE 42.2+, Oracle Linux 7, Ubuntu 14.04/16.04/17.04, Linux Mint 17/18, macOS 10.12/10.13.

Презентация версии .NET Core 2.0, 14 августа 2017 года.

Что не нравится

Нет унификации

«There’s only one way to do smth» — вообще нет:

  • Method call syntax — пиши вызов функции как хочешь
  • camelCase и underscore_notation
  • this и tHiS (спойлер: это одно и то же)

Стабильность

Великолепно! Теперь вместо того, чтобы писать новый код, я должен чинить старый. Не от этого ли я бежал, когда выбирал nim?

Object variants

Вы можете избежать наследования, используя т.н. object variants:

В зависимости от значения , вам будут доступны либо x, y, z поля, либо r, phi и k.

Do notation

  • do with parentheses is an anonymous proc
  • do without parentheses is just a block of code Одно выражение означает разные вещи ¯_(ツ)_/¯

Когда что использовать

Итак, у нас есть функции, процедуры, дженерики, мультиметоды, шаблоны и макросы. Когда лучше использовать шаблон, а когда процедуру? Шаблон или дженерик? Функция или процедура? Так, а макросы? Я думаю, вы поняли.

Custom pragma

В питоне есть декораторы, которые можно применять хоть к классам, хоть к функциям. В nim для этого есть прагмы. И вот что:

  • Вы можете написать свою прагму, которая будет декорировать процедуру:

Nimble

Что мертво — умереть не может. В nimble куча проектов, которые уже давно не обновлялись (а в nim это смерти подобно) — и их не убирают. Никто за этим не следит. Понятно, обратная совместимость, «нельзя просто взять и удалить пакет из репы», но всё же… Ладно, спасибо, что хоть не как npm.

Дырявые абстракции

Итак

Я тупой программист. Я не хочу знать, как работает GC, что там и как линкуется, куда кэшируется и как убирается мусор. Это как с машиной — я в принципе знаю, как она устроена, немного про сход-развал, немного про коробку передач, масло там надо заливать и прочее, но вообще я просто хочу сесть и ехать (причём быстро) на вечеринку. Машина — не цель, а средство достижения цели. Если она сломается — я не хочу лезть в капот, а просто отвезу её на сервис (в смысле, открою issue на гитхабе), и было бы здорово, если бы чинили её быстро.

Nim должен был стать такой машиной. Отчасти он и стал, но в то же время, когда я мчусь на этой машине по хайвею, у меня отваливается колесо, а заднее зеркало показывает вперёд. За мной бегут инженеры и на ходу что-то приделывают («теперь с этим новым спойлером ваша машина ещё быстрее»), но от этого у меня отваливается багажник. И знаете что? Мне всё равно чертовски нравится эта машина, ведь это лучшая из всех машин, что я видел.

IoC, DI, DIP

Если театр начинается с вешалки, то ASP.NET Core начинается с Dependency Injection. Для того, чтобы разобраться с DI нужно понять, что такое IoC.


Говоря о IoC очень часто вспоминают голливудский принцип «Don’t call us, we’ll call you». Что означает «Не нужно звонить нам мы позвоним вам сами».

Различные источники приводят различные паттерны, к которым может быть применен IoC. И скорее всего они все правы и просто дополняют друг друга. Вот некоторые их этих паттернов: factory, service locator, template method, observer, strategy.

Давайте разберем IoC на примере простого консольного приложения.

Допустим у нас есть два простых класса, реализующих интерфейс с одним методом:

Они оба зависят от абстракции (в данном случае в виде абстракции выступает интерфейс).

И, допустим, у нас есть объект более высокого уровня, использующий эти классы:

В зависимости от параметра конструктора переменная _instance инициализируется определенным классом. Ну и далее при вызове Write будет совершен вывод на консоль или в Debug. Все вроде бы неплохо и даже, казалось бы, соответствует первой части принципа Dependency Inversion

В качестве абстракции в нашем случае выступает ILayer.

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

Инициализируя Logging с помощью 1 мы получаем в классе Logging экземпляр класса, выводящего данные на консоль. Если мы инициализируем Logging любым другим числом, то log.Write будет выводить данные в Debug. Все, казалось бы, работает, но работает плохо. Наш объект более высокого уровня Main зависит от деталей кода объекта более низкого уровня – класса Logging. Если мы в этом классе что-то изменим, то нам необходимо будет изменять и код класса Main. Чтобы это не происходило мы сделаем инверсию контроля – Inversion of Control. Сделаем так чтобы класс Main контролировал то, что происходит в классе Logging. Класс Logging будет получать в виде параметра конструктора экземпляр класса, реализующего интерфейс интерфейс ILayer

И теперь нас класс Main будет выглядеть таким образом:

Фактически мы декорируем наш объект Logging с помощью необходимого для нас объекта.

Теперь наше приложение соответствует и второй части принципа Dependency Inversion:


Есть такой термин tight coupling – тесная связь. Чем слабее связи между компонентами в приложении, тем лучше. Хотелось бы заметить, что данный пример простого приложения немного не дотягивает до идеала. Почему? Да потому что в классе самого высокого уровня в Main у нас дважды используется создание экземпляров класса с помощью new. А есть такая мнемоническая фраза «New is a clue» — что означает чем меньше вы используется new, тем меньше тесных связей компонентов в приложении и тем лучше. В идеале мы не должны были использовать new DebugLayer, а должны были получить DebugLayer каким-нибудь другим способом. Каким? Например, из IoC контейнера или с помощью рефлексии из параметра передаваемого Main.

Теперь мы разобрались с тем, что такое Inversion of Control (IoC) и что такое принцип Dependency Inversion (DIP). Осталось разобраться с тем, что такое Dependency Injection (DI). IoC представляет собой парадигму дизайна. Dependency Injection это паттерн. Это то, что у нас теперь происходит в конструкторе класса Logging. Мы получаем экземпляр определенной зависимости (dependency). Класс Logging зависит от экземпляра класса, реализующего ILayer. И это экземпляр внедряется (injected) через конструктор.

Как я подружил Unity3D и F#

Из песочницы

В последнее время я стал все больше и больше интересоваться функциональным программированием, и при выборе языка предо мною пал выбор среди двух очень понравившихся мне языков — Haskell и F#. В F# меня соблазнило то, что его можно компилировать в MSIL сборки, что обеспечивает возможность использования библиотек классов F# в других языках Microsoft .Net, а также то, что он и сам может их использовать. Ко всему прочему, я ещё и начинающий разработчик Unity3D, и мне в голову пришла мысль: если компилируется в MSIL, то может можно использовать F# скрипты в Unity? Гугление дало ответ: по-человечески нельзя. Можно создать библиотеку классов, поставить в проекте ссылки на библиотеку UnityEngine.dll, компилировать и импортировать как ассет, после чего добавлять компоненты Mono-behaviour напрямую из библиотеки, но это не слишком удобно, согласитесь. Однако, пройдя гугл, Reflection и справку по Unity, мне все таки удалось приблизить(но не повторить в точности) работу с F# скриптами внутри редактора к тому виду, в котором производится работа со скриптами на встроенных языках. Подробности — под хабракатом.

Версии

Основная статья: Список версий .NET Framework

Microsoft начала разрабатывать .NET Framework в конце 1990-х под именем «Next Generation Windows Services» (NGWS). В 2000 году была выпущена первая бета-версия .NET 1.0.

Версия CLR Номер версии Дата выхода Visual Studio По умолчанию в Windows Заменяет
1.0 1.0.3705.0 1 мая 2002 года Visual Studio .NET н/д н/д
1.1 1.1.4322.573 1 апреля 2003 года Visual Studio .NET 2003 Windows Server 2003 1.0
2.0 2.0.50727.42 11 июля 2005 года Visual Studio 2005 Windows Vista, Windows 7, Windows Server 2008 R2 н/д
2.0 3.0.4506.30 6 ноября 2006 года Visual Studio 2005 + расширения Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2 2.0
2.0 3.5.21022.8 9 ноября 2007 года Visual Studio 2008 Windows 7, Windows Server 2008 R2 2.0, 3.0
4 4.0.30319.1 12 апреля 2010 года Visual Studio 2010 Windows 8, Windows Server 2012 н/д
4 4.5.50709.17929 15 августа 2012 года Visual Studio 2012 Windows 8, Windows Server 2012 4.0
4 4.5.50938.18408 17 октября 2013 года Visual Studio 2013 Windows 8.1, Windows Server 2012 R2 4.0, 4.5
4 4.5.51209.34209 5 мая 2014 года н/д н/д 4.0-4.5.1
4 4.6.1038.0 20 июля 2015 года Visual Studio 2015 Windows 10 4.0-4.5.2
4 4.6.23123.0 17 ноября 2015 года Visual Studio 2015 Update 1 Windows 10 v1511 4.0-4.6
4 4.6.23907.0 20 июля 2016 года Windows 10 v1607 4.0-4.6.1
4.7 4 4.7.02046 5 апреля 2017 года Visual Studio 2017 Windows 10 v1703 4.0-4.6.2
4.7.1 4 4.7.02556 17 октября 2017 года Visual Studio 2017 v15.5 Windows 10 v1709, Windows Server 2016 (version 1709) 4.0-4.7
4.7.2 4 4.7.03056 30 апреля 2018 года Visual Studio 2017 v15.8 Windows 10 v1803 4.0-4.7.1
4.8 4 4.8.3761.0 18 апреля 2019 года Windows 10 v1903 4.0-4.7.2

А теперь серьёзно

То, что я скажу дальше, — это моё личное мнение, с которым вы (или редакция Skillbox) можете не согласиться.

В работе над разными проектами мне часто приходится сталкиваться как с C# (ASP.NET), так и с PHP. Это бывают как новые проекты, так и поддержка существующих. И, как мне кажется, ASP.NET в разы эффективнее, если сайт рассчитан на долгосрочную перспективу.

Даже если код писал не самый лучший разработчик, в нём можно гораздо быстрее разобраться, потому что в C# есть типизация, лаконичный синтаксис и хорошая реализация ООП. PHP в этом плане значительно проигрывает.

Твоё лицо, когда написал самую крупную социальную сеть на PHP

Поэтому я бы посоветовал PHP для тех проектов, которые нужно быстро написать, сдать и забыть. Максимум — раз в месяц вносить какие-то правки.

Что учить новичку

Новичкам в программировании стоит выбрать в качестве первой технологии PHP — она проще в освоении, на ней можно практически сразу что-то создать. Поэтому можно сразу увидеть результат своих действий, а это один из главных признаков прогресса.

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

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


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

Неизменяемая очередь на F#

Введение

Прочитав недавно статью про список на Haskell, решил тоже немного рассказать о реализации базовых структур на ФЯП (F#). Статья не несёт практической ценности, поскольку готовых реализаций полно в интернете. Цель статьи — рассказать о том, как можно реализовать неизменяемую очередь на F# и как она работает. Для начала немного терминологии.F# — это язык программирования из семейства .NET, который, помимо объектно-ориентированного и императивного подходов, реализует функциональный подход в программировании. Неизменяемые объекты – это такие объекты, которые будучи созданными один раз, в дальнейшем не могут быть изменены. Например, в C# есть такой тип данных, как string, экземпляры которого являются неизменяемыми. Добавляя символ в строку, вы получаете новую строку и имеете неизменной старую. Подробнее тут.

Features

Code analysis

Rider boasts 2,200+ live code inspections, with automated quick-fixes to resolve detected issues individually or in bulk. Solution-wide error analysis will monitor code issues and let you know if anything goes wrong, even in files that are not currently open.

Code editing

Rider’s rich editor features different kinds of code completion and code templates, auto-inserting matching braces and import directives, quick info tooltips and gutter icons for inheritance navigation, context actions, and much more.

Refactorings

Most of ReSharper’s 60+ refactorings are already available in Rider, and its 450+ context actions are all there. Rename, extract methods, interfaces and classes, move and copy types, use alternative syntax, and a lot more!

Unit test runner

Rider helps you run and debug unit tests based on NUnit, xUnit.net, or MSTest. You can explore tests, group them in different ways, break them down into individual sessions, see test output and navigate to source code from stack traces.

Debugger and more tools

Rider includes a debugger that works with .NET Framework, Mono and .NET Core applications, letting you step, watch, evaluate, and run to cursor. Other tools include a stack trace explorer, NuGet browser, and VCS and database support.

Databases and SQL

Work with SQL and databases without leaving Rider. Connect to databases, edit schemas and table data, run queries, and even analyze schemas with UML diagrams.

Navigation and search

Jump to any file, type, or member in your code base instantly, as well as quickly find settings and actions. Find usages of any symbol, or navigate from a symbol to the base and derived symbols, extension methods, or implementations.

Front-end technologies

Rider comes with JavaScript, TypeScript, HTML, CSS and Sass support built in. Take advantage of the refactorings, debugging, and unit testing capabilities included from WebStorm.

Extensibility

True to its roots, Rider supports a wide array of plugins developed for ReSharper and IntelliJ Platform. In addition to the bundled plugins (such as those for VCS, F#, and Unity support), plugins that support Markdown, files, and Python scripts are available.

Определение языка программирования

Язы́к программи́рованияформальная знаковая системалексических, синтаксических и семантическихвнешний виддействияВикипедии

  • Формальный язык — это множество конечных слов (строк, цепочек) над конечным алфавитом.
  • Знаковая система — это система однообразно интерпретируемых и трактуемых сообщений/сигналов, которыми можно обмениваться в процессе общения. Иногда знаковые системы помогают структурировать процесс общения с целью придания ему некой адекватности в плане реакций его участников на те или иные «знаки». В качестве примера знаковой системы обычно приводят язык (как в письменной форме так и, в случае естественных языков, в форме речи).
  • Компью́терная програ́мма — последовательность инструкций, предназначенных для исполнения устройством управления вычислительной машины.
  • Ле́ксика — совокупность слов того или иного языка, части языка или слов, которые знает тот или иной человек или группа людей.
  • Синтаксис — сторона языка программирования, которая описывает структуру программ как наборов символов (обычно говорят — безотносительно к содержанию). Синтаксису языка противопоставляется его семантика. Синтаксис языка описывает «чистый» язык, в то же время семантика приписывает значения (действия) различным синтаксическим конструкциям.
  • Сема́нтика в программировании — дисциплина, изучающая формализации значений конструкций языков программирования посредством построения их формальных математических моделей. В качестве инструментов построения таких моделей могут использоваться различные средства, например, математическая логика, λ-исчисление, теория множеств, теория категорий, теория моделей, универсальная алгебра. Формализация семантики языка программирования может использоваться как для описания языка, определения свойств языка, так и для целей формальной верификации программ на этом языке программирования.
  • Язы́к — знаковая система, соотносящая понятийное содержание и типовое звучание (написание).

Язык программирования

Примечания

Источники-списки

  1. Brian Ritchie.  (англ.). Bitbucket (25 August 2013). Дата обращения 15 октября 2014.
  2. Alexander Köplinger, Matthias Mailänder.  (англ.). mono-project.com (5 October 2014). Дата обращения 30 октября 2014.

Прочие источники

  1. Bjarke Viksoe.  (англ.). viksoe.dk (25 August 2001). — (Указана совместимость с .NET Framework 1.0 SP1). Дата обращения 8 декабря 2014.
  2. Bjarke Viksoe.  (англ.). viksoe.dk (2002). — (Архив содержит проект для Visual Studio .NET (2002)). Дата обращения 8 декабря 2014.
  3. Martin C. Carlisle, Ricky Sward, Jeff Humphries.  (англ.). SIGAda (5 December 2002). — (Указана совместимость с .NET Framework 1.0.3705). Дата обращения 12 ноября 2014.
  4. Martin C. Carlisle.  (англ.). SIGAda (8 December 2003). — (Указана совместимость с .NET Framework 1.1.4322). Дата обращения 12 ноября 2014.
  5. Martin C. Carlisle, Ricky Sward, Jeff Humphries.  (англ.). asharp.martincarlisle.com (6 June 2006). — (Указана совместимость с .NET Framework 2.0.50727). Дата обращения 12 ноября 2014.
  6. Martin C. Carlisle.  (англ.). asharp.martincarlisle.com (9 May 2006). Дата обращения 12 ноября 2014.
  7.  (англ.) (недоступная ссылка). ethoberon.ethz.ch (8 June 2000). Дата обращения 13 ноября 2014.
  8.  (англ.) (недоступная ссылка). oberon.ethz.ch (8 June 2000). Дата обращения 13 ноября 2014.
  9.  (англ.). ethoberon.ethz.ch (12 February 2002). — (Указана совместимость с .NET Framework 1.0.3705). Дата обращения 13 ноября 2014.
  10.  (англ.). Microsoft Research (June 2002). — (Указана совместимость с версией .NET Framework 1.0.3705). Дата обращения 21 декабря 2014.
  11.  (англ.). Microsoft Research (June 2002). — (Указано требование Microsoft .NET Framework Service Pack 1). Дата обращения 21 декабря 2014.
  12.  (англ.). Microsoft Research (June 2002). — (Указана совместимость с Visual Studio .NET). Дата обращения 21 декабря 2014.
  13.  (англ.). Microsoft Research (2003). — (Указана совместимость с версией .NET Framework 1.1). Дата обращения 21 декабря 2014.
  14.  (англ.). Microsoft Research. — (Указано, что Spec Explorer содержит AsmL-компилятор для платформы .NET). Дата обращения 11 декабря 2014.

С этим читают