• без физической системы защиты, такой как высокие стены и злые овчарки,
• без веры в правила и стандарты XX века, такие как Tier 1-4,
• без невообразимой плотности пользователей на один хост.

Блокчейн — это и база хранения информации, и гарант её неизменности. Одним из вариантов применения блокчейна стала запись и хранение в нем важной информации в виде параметров «имя-значение» (NVS). Реализованное в блокчейне Emercoin, это решение позволяет локально сохранять данные публичных SSH-ключей, SSL-сертификатов и DNS-записей, не доверяя конкретному центру. Блокчейн Emercoin позволяет базирующимся на нём проектам быть и децентрализованными, и защищеннёми одновременно. Такова сила криптографии.

Децентрализованному дата-центру — распределённое финансирование

Как принять участие в pre-ICO на Emercoin

• Логики – это программисты с классическим флёром. Чтобы познакомиться с новой технологией они идут и читают документацию. Четкость кода – повышенная, ни шага влево, ни шага вправо. От забора и до обеда. Непритязательность к удобству работы с кодом пугает – кажется, что они могут работать и с минифицированным кодом, пользуясь одной только функцией поиска.
• Визуалы – это люди, подходящие к коду более творчески, абстрактно. Чтобы изучить технологию они идут в youtube и смотрят видео про дельфинов уроки. В коде им важно разделение на осязаемые блоки, отсутствие простыней на 1000+ строк, возможность реализовать по-новому. Выполняя новую задачу они будут пристреливаться и искать свой вариант решения вместо поисков уже имеющегося на просторах интернета.

Aphs

• Возвращаясь к тому или иному flow вы включаете нужный соответствующий контекст (граф) и все предстает перед вашими глазами без необходимости болезненно реконструировать всю картину этого flow в памяти. Снижается риск сломать что-то в другом месте пока вы разбираетесь в этом.
• Как инструмент документации, не требующий подчас нудной писанины от изнуренного переключениями между файлами разработчика. Новый сотрудник, открыв тот или иной контекст, сразу увидит, что делается в начале execution flow и как это влияет на то, что происходит в конце.
• Начало работы над заданием с организации нового flow для нее – это легкий психологический шаг первый шаг и база для быстрой работы. Как зарядка по утрам.

• Получить фидбек, понять насколько актуально, что понятно и что не понятно
• Реализовать работу с множеством контекстов / flow (сейчас только один)
• Сделать более юзерфрендли (множество мелочей вроде изменения имен идентификаторов блоков из клиента, а не в коде или исключения повторения идентификаторов и т.д.)

• Логики – это программисты с классическим флёром. Чтобы познакомиться с новой технологией они идут и читают документацию. Четкость кода – повышенная, ни шага влево, ни шага вправо. От забора и до обеда. Непритязательность к удобству работы с кодом пугает – кажется, что они могут работать и с минифицированным кодом, пользуясь одной только функцией поиска.
• Визуалы – это люди, подходящие к коду более творчески, абстрактно. Чтобы изучить технологию они идут в youtube и смотрят видео про дельфинов уроки. В коде им важно разделение на осязаемые блоки, отсутствие простыней на 1000+ строк, возможность реализовать по-новому. Выполняя новую задачу они будут пристреливаться и искать свой вариант решения вместо поисков уже имеющегося на просторах интернета.

Aphs

• Возвращаясь к тому или иному flow вы включаете нужный соответствующий контекст (граф) и все предстает перед вашими глазами без необходимости болезненно реконструировать всю картину этого flow в памяти. Снижается риск сломать что-то в другом месте пока вы разбираетесь в этом.
• Как инструмент документации, не требующий подчас нудной писанины от изнуренного переключениями между файлами разработчика. Новый сотрудник, открыв тот или иной контекст, сразу увидит, что делается в начале execution flow и как это влияет на то, что происходит в конце.
• Начало работы над заданием с организации нового flow для нее – это легкий психологический шаг первый шаг и база для быстрой работы. Как зарядка по утрам.

• Получить фидбек, понять насколько актуально, что понятно и что не понятно
• Реализовать работу с множеством контекстов / flow (сейчас только один)
• Сделать более юзерфрендли (множество мелочей вроде изменения имен идентификаторов блоков из клиента, а не в коде или исключения повторения идентификаторов и т.д.)

• Рекомендательные системы: от матричных разложений к глубинному обучению в поточном режиме (Михаил Камалов, Epam Systems)
  
• Глубокое обучение, вероятностное программирование и метавычисления: точка пересечения (Алексей Потапов, ИТМО)
  
• Автоматический поиск контактной информации в интернете (Александр Сибиряков, Scrapinghub)
  
• Прикладное машинное обучение в электронной коммерции: сценарии и архитектуры пилотов и боевых проектов (Александр Сербул, 1С-Битрикс)
  
• Deep Learning: Распознавание сцен и достопримечательностей на изображениях (Андрей Бояров, Mail.ru)
  

Замеченные вещи

• Наша сборочная система, построенная на принципе Unity-билдов, не была виновником происходящего. Всё дело было в одном конкретном cpp-файле.
• Такое поведение показывал толко компилятор MSVC (clang работал в 10 раз быстрее), но нам тогда был нужен именно MSVC
• Проблема касалась только Release-сборок (а вернее тех сборок, где был включен инлайнинг)
• Проблема касалась не только относительно старого компилятора VS2010. Компиляция с помощью VS2015 работала даже ещё медленнее
• Общим моментом для всех файлов, компиляция которых занимала более 30 секунд, было использование нашей «математической SIMD-библиотеки», которая давала возможность писать код в стиле HLSL. Реализация была основана на весьма заковыристых макросах и шаблонах
• Тот самый файл, компиляция которого занимала 7 минут, включал в себя очень большую и сложную SIMD-функцию, которая к тому же за счет использования шаблонов требовала создание нескольких типизированных реализаций на этапе компиляции (так мы избавлялись от накладных расходов на рантайме, так что этот подход имел смысл)

Ускорение компиляции

Мораль

• Иметь хотя бы какую-нибудь систему профилирования сборки проекта, это лучше, чем не иметь вообще никакой. Если бы у нас подобной системы не было — мы бы так и теряли по 5 минут на каждой сборке проекта (не только на билд-сервере, но и на машинах разработчиков).
• Когда ваша шаблонная функция компилируется, то создаётся N её типизированных представлений. И каждое представление — это отдельный код, который сначала автоматически генерируется, а потом компилируется. При этом для разных версий такого кода, в зависимости от используемых типов, компилятор может ещё и применять различные оптимизации. Разделение большой шаблонной функции на более мелкие (и, возможно, не шаблонные) может реально ускорить компиляцию.
• Сложные шаблонные функции могут компилироваться долго из-за слишком долгой работы оптимизатора. Например, компилятор MSVC тратит основное время именно на это.
• Ускорение сборки — хорошая штука. Ну, помните, тот комикс — "-Эй, вы куда? — Код компилируется!". Чем меньше такого случается в жизни, тем лучше.

Что делает автоматика в HR?

Зима Сингулярность близко!

Почему Voximplant, а не Asterisk?

Вера, вперед! Чемпионские результаты робота

Тотальная цифровизация и омниканальность

1. мгновенная и адекватная обратная связь
2. качественный клиентский сервис онлайн
3. бесшовное взаимодействие (омниканальность)
4. понятный и удобный интерфейс, возможность заказать и оплатить товар или услугу в пару кликов.

Чат-боты и омниканальность

Где и в чем бизнесу пригодятся боты?

• Бизнес не понимает, как внедрять ботов. У него нет сформированной стратегии работы в цифровых каналах или дорожной карты цифровой трансформации.
• Разработка ботов оторвана от бизнес-процессов, а многие IT-вендоры стремятся поднять хайп, чтобы увеличить поток обращений.
• В массовом секторе боты пока еще не умеют качественно распознавать голос и переводить его в текст. На рынке есть очень продвинутые решения, но стоимость их пока еще очень высока.
• На рынке практически нет решений, которые можно легко интегрировать со сторонними платформами. Поэтому сложно внедрять чат-ботов в бизнес-процессы. Одним из пионеров таких решений является компания LiveTex, недавно выпустившая на рынок коммуникационное API, с помощью которого можно не только встроить бота в платформу для омниканального обслуживания, но и собирать статистику по всем обращениям из всех текстовых каналов и подсчитывать эффект от их внедрения.

Что же в сухом остатке?

Чего ожидать к концу года

Интеллектуальные методы защиты

О Comodo Group

• Этапы проведения кибератак
• Что нужно, чтобы стать инженером по ИТ-безопасности
• Как безопасно обмениваться паролями в вашей сети

1. Коллапс

1. Это всего лишь итоги первого квартала 2017 года, в конце года наверняка будет откат. Но с приходом Страшнова Почта каждый год только прибавляла (с 92-го, через 81-е к 59-му). Проблема только в том, что на англоязычных ресурсах EMS никакого рейтинга найти не удалось. Может, плохо искали. Может, рейтинг не так популярен в остальном мире. Остаётся принять на веру данные ПР о крутизне этого рейтинга.
2. Экспорт — за счёт увеличения количества экспортных отправлений EMS на 25%. А это один из основных показателей рейтинга.
3. Собственно скорость доставки. К которой можно добавить скорость ответов на претензии и скорость передачи данных о статусах почтовых отправлений в систему отслеживания.

2. Субсидии

3. Почта.Маркет

4. Direct mail, CRM и остальное

5. Почта Банк и блокчейн

6. Премия и самолёты

7. Перед зависшим IPO

1. Непринятие законов о связи и акционировании
2. Отсутствие политического спонсорства
3. Не поговорил с Путиным на эти темы.

Эта статья является переводом справочного руководства по переносу приложений из ASP.NET в ASP.NET Core 2.0. Ссылка на оригинал
В силу некоторых причин, у нас возникла необходимость перейти с ASP.NET в ASP.NET Core 1.1., о том, как это у нас получилось, читайте тут.

Содержание

1. Требования
2. Выбор Фреймворка
3. Различия в структуре проекта
4. Замена Global.asax
5. Хранение конфигураций
6. Встроенный механизм Dependency Injection
7. Работа со статическими файлами

Требования

• .NET Core 2.0.0 SDK или более поздняя версия.

Выбор фреймворка

Для работы с ASP.NET Core 2.0 проектом, разработчику предстоит сделать выбор – использовать .NET Core, .NET Framework или использовать сразу оба варианта. В качестве дополнительной информации можно использовать руководство Choosing between .NET Core and .NET Framework for server apps (вкратце можно сказать что .NET core является кроссплатформенной библиотекой, в отличие от .NET Framework) для того чтобы понять, какой Фреймворк для вас окажется наиболее предпочтительным.
После выбора нужного Фреймворка в проекте необходимо указать ссылки на пакеты NuGet.
Использование .NET Core позволяет устранить многочисленные явные ссылки на пакеты, благодаря объединенному пакету (мета пакету) ASP.NET Core 2.0. Так выглядит установка мета пакета Microsoft.AspNetCore.All в проект:

Различия в структуре проекта

Структура файла проекта .csproj была упрощена в ASP.NET Core. Вот некоторые значительные изменения:
• Явное указание файлов является необязательным для добавления их в проект. Таким образом, уменьшается риск конфликтов в процессе слияния XML, если над проектом работает большая команда
• Больше нет GUID ссылок на другие проекты, что улучшает читаемость
• Файл можно редактировать без его выгрузки из Visual Studio:

Замена Global.asax

Точкой входа для ASP.NET приложений является Global.asax файл. Такие задачи, как конфигурация маршрута и регистрация фильтров и областей, обрабатываются в файле Global.asax

public class MvcApplication : System.Web.HttpApplication
{
    protected void Application_Start()
    {
        AreaRegistration.RegisterAllAreas();
        FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
        RouteConfig.RegisterRoutes(RouteTable.Routes);
        BundleConfig.RegisterBundles(BundleTable.Bundles);
    }
}

Этот подход тесно связывает приложение и сервер, на котором развернуто приложение. Для уменьшения связности был представлен OWIN как средство, обеспечивающее более правильный путь совместного использования нескольких фреймворков вместе.
OWIN позволяет добавить в конвейер запроса только необходимые модули. Среда выполнения использует Startup для конфигурации сервисов и конвейера запросов.
Startupрегистрирует набор промежуточных сервисов (middleware) вместе с приложением. Для каждого запроса приложение вызывает поочередно каждый из набора промежуточных сервисов, имеющих указатель на первый элемент связанного списка обработчиков.
Каждый компонент промежуточного сервиса может добавить один или несколько обработчиков в конвейер обработки запросов. Это происходит с помощью возврата ссылки на обработчик, который находится в начале списка.
И обработчик, закончив свою работу, вызывает следующий обработчик из очереди.
В ASP.NET Core, точкой входа в приложении является класс Startup, с помощью которого мы нивелируем зависимость от Global.asax.
Если изначально был выбран .NET Framework то при помощи OWIN мы можем сконфигурировать конвейер запросов как в следующем примере:

using Owin;
using System.Web.Http;

namespace WebApi
{
    // Заметка: По умолчанию все запросы проходят через этот конвейер OWIN. В качестве альтернативы вы можете отключить это, добавив appSetting owin: AutomaticAppStartup со значением «false».
    // При отключении вы все равно можете использовать приложения OWIN для прослушивания определенных маршрутов, добавив маршруты в файл global.asax с помощью MapOwinPath или расширений MapOwinRoute на RouteTable.Routes

    public class Startup
    {
        // Вызывается один раз при запуске для настройки вашего приложения.
        public void Configuration(IAppBuilder builder)
        {
            HttpConfiguration config = new HttpConfiguration();
//Здесь настраиваем маршруты по умолчанию, 
            config.Routes.MapHttpRoute("Default", "{controller}/{customerID}", new { controller = "Customer", customerID = RouteParameter.Optional });
//Указываем на то что в качестве файла конфигурации мы будем использовать xml вместо json 

            config.Formatters.XmlFormatter.UseXmlSerializer = true;
            config.Formatters.Remove(config.Formatters.JsonFormatter);
            // config.Formatters.JsonFormatter.UseDataContractJsonSerializer = true;

            builder.UseWebApi(config);
        }
    }
}

Также при необходимости здесь мы можем добавить другие промежуточные сервисы в этот конвейер (загрузка сервисов, настройки конфигурации, статические файлы и т.д.).
Что касается версии фреймворка .NET Core, то здесь используется подобный подход, но не без использования OWIN для определения точки входа. В качестве альтернативы используется метод Main в Program.cs (по аналогии с консольными приложениям), где и происходит загрузка Startup:

using Microsoft.AspNetCore;
using Microsoft.AspNetCore.Hosting;

namespace WebApplication2
{
    public class Program
    {
        public static void Main(string[] args)
        {
            BuildWebHost(args).Run();
        }

        public static IWebHost BuildWebHost(string[] args) =>
            WebHost.CreateDefaultBuilder(args)
                .UseStartup()
                .Build();
    }
}

Startup должен включать метод Configure. В Configure определяется, какие сервисы будут использоваться в конвейере запроса. В следующем примере (взятом из стандартного шаблона web-сайта), несколько методов расширения используются для настройки конвейера с поддержкой:
• BrowserLink
• Error pages
• Static files
• ASP.NET Core MVC
• Identity

public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
{
    loggerFactory.AddConsole(Configuration.GetSection("Logging"));
    loggerFactory.AddDebug();

    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
        app.UseDatabaseErrorPage();
        app.UseBrowserLink();
    }
    else
    {
        app.UseExceptionHandler("/Home/Error");
    }

    app.UseStaticFiles();

    app.UseIdentity();

    app.UseMvc(routes =>
    {
        routes.MapRoute(
            name: "default",
            template: "{controller=Home}/{action=Index}/{id?}");
    });
}

В итоге мы имеем разделение среды выполнения и приложения, что дает нам возможность осуществить переход на другую платформу в будущем.
Заметка: Для более глубокого понимания ASP.NET Core Startup и Middleware, можно изучить Startup in ASP.NET Core

Хранение конфигураций

ASP.NET поддерживает сохранение настроек. Например, это настройки, которые используются средой выполнения, где было развернуто приложение. Сам подход заключался в том, что для хранение пользовательских key-value пар использовалась секция в файле Web.config:

Приложение получало доступ к этим настройкам с помощью коллекции ConfigurationManager.AppSettings из пространства имен System.Configuration :

string userName = System.Web.Configuration.ConfigurationManager.AppSettings["UserName"];
string password = System.Web.Configuration.ConfigurationManager.AppSettings["Password"];

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

{
  "Logging": {
    "IncludeScopes": false,
    "LogLevel": {
      "Default": "Debug",
      "System": "Information",
      "Microsoft": "Information"
    }
  },
  // Здесь можно указать настраиваемые параметры конфигурации. Поскольку это JSON, все представлено в виде пар символов: значение  
 // Как назвать раздел, определяет сам разработчик
  "AppConfiguration": {
    "UserName": "UserName",
    "Password": "Password"
  }
}

Загрузка этого файла в экземпляр IConfiguration для приложения происходит в Startup.cs:

public Startup(IConfiguration configuration)
{
    Configuration = configuration;
}

public IConfiguration Configuration { get; }

А вот так приложение использует Configuration для получения этих настроек:

string userName = Configuration.GetSection("AppConfiguration")["UserName"];
string password = Configuration.GetSection("AppConfiguration")["Password"];

Есть другие способы, основанные на данном подходе, которые позволяют сделать процесс более надежным, например Dependency Injection (DI).
Подход DI обеспечивает доступ к строго типизированному набору объектов конфигурации.

// Предположим, AppConfiguration - это класс, который представляет строго типизированную версию раздела AppConfiguration
services.Configure(Configuration.GetSection("AppConfiguration"));

Заметка: Для более глубокого понимания конфигураций ASP.NET Core, можно ознакомится с Configuration in ASP.NET Core.

Встроенный механизм Dependency Injection

Важной целью при создании больших масштабируемых приложений является ослабление связи между компонентами и сервисами. Dependency Injection – распространенная техника для решения данной проблемы и ее реализация является встроенным в ASP.NET Core компонентом.
В приложениях ASP.NET разработчики использовали сторонние библиотеки для внедрения Injection Dependency. Примером такой библиотеки является Unity .
Пример настройки Dependency Injection с Unity — это реализация UnityContainer, обернутая в IDependencyResolver:

using Microsoft.Practices.Unity;
using System;
using System.Collections.Generic;
using System.Web.Http.Dependencies;

public class UnityResolver : IDependencyResolver
{
    protected IUnityContainer container;

    public UnityResolver(IUnityContainer container)
    {
        if (container == null)
        {
            throw new ArgumentNullException("container");
        }
        this.container = container;
    }

    public object GetService(Type serviceType)
    {
        try
        {
            return container.Resolve(serviceType);
        }
        catch (ResolutionFailedException)
        {
            return null;
        }
    }

    public IEnumerable GetServices(Type serviceType)
    {
        try
        {
            return container.ResolveAll(serviceType);
        }
        catch (ResolutionFailedException)
        {
            return new List();
        }
    }

    public IDependencyScope BeginScope()
    {
        var child = container.CreateChildContainer();
        return new UnityResolver(child);
    }

    public void Dispose()
    {
        Dispose(true);
    }

    protected virtual void Dispose(bool disposing)
    {
        container.Dispose();
    }
}

Создаем экземпляр своего UnityContainer, регистрируем свою службу и устанавливаем разрешение зависимости для HttpConfiguration в новый экземпляр UnityResolver для нашего контейнера:

public static void Register(HttpConfiguration config)
{
    var container = new UnityContainer();
    container.RegisterType(new HierarchicalLifetimeManager());
    config.DependencyResolver = new UnityResolver(container);

    // Опустим остальную часть реализации
}

Далее производим инъекцию IProductRepository там, где это необходимо:

public class ProductsController : ApiController
{
    private IProductRepository _repository;

    public ProductsController(IProductRepository repository)  
    {
        _repository = repository;
    }

}

Поскольку Dependency Injection является частью ядра ASP.NET Core, мы можем добавить свой сервис в метод ConfigureServices внутри Startup.cs:

public void ConfigureServices(IServiceCollection services)
{
    //Добавляем сервис приложения
    services.AddTransient();
}

И далее инъекцию репозитория можно осуществить в любом месте, как и в случае с Unity.
Заметка: Подробности можно посмотреть в Dependency Injection in ASP.NET Core

Работа с статическими файлами

Важной частью веб-разработки является возможность обслуживания статики. Самые распространенные примеры статики — это HTML, CSS, JavaScript и картинки.
Эти файлы нужно сохранять в общей папке приложения (или например в CDN) чтобы в дальнейшем они были доступны по ссылке. В ASP.NET Core был изменен подход для работы с статикой.
В ASP.NET статика хранится в разных каталогах.
А в ASP.NET Core статические файлы по умолчанию хранятся в «web root» (/ wwwroot). И доступ к этим файлам осуществляется с помощью метода расширения UseStaticFiles из Startup.Configure:

public void Configure(IApplicationBuilder app)
{
    app.UseStaticFiles();
}

К примеру, изображения находящееся в папке wwwroot/images будет доступно из браузера по адресу http:///images/.
Заметка: Если был выбран .NET Framework, то дополнительно нужно будет установить NuGet пакет Microsoft.AspNetCore.StaticFiles.
Заметка: Для более подробной ссылки на обслуживание статических файлов в ядре ASP.NET см. Introduction to working with static files in ASP.NET Core.

Эта статья является переводом справочного руководства по переносу приложений из ASP.NET в ASP.NET Core 2.0. Ссылка на оригинал
В силу некоторых причин, у нас возникла необходимость перейти с ASP.NET в ASP.NET Core 1.1., о том, как это у нас получилось, читайте тут.

Содержание

1. Требования
2. Выбор Фреймворка
3. Различия в структуре проекта
4. Замена Global.asax
5. Хранение конфигураций
6. Встроенный механизм Dependency Injection
7. Работа со статическими файлами

Требования

• .NET Core 2.0.0 SDK или более поздняя версия.

Выбор фреймворка

Для работы с ASP.NET Core 2.0 проектом, разработчику предстоит сделать выбор – использовать .NET Core, .NET Framework или использовать сразу оба варианта. В качестве дополнительной информации можно использовать руководство Choosing between .NET Core and .NET Framework for server apps (вкратце можно сказать что .NET core является кроссплатформенной библиотекой, в отличие от .NET Framework) для того чтобы понять, какой Фреймворк для вас окажется наиболее предпочтительным.
После выбора нужного Фреймворка в проекте необходимо указать ссылки на пакеты NuGet.
Использование .NET Core позволяет устранить многочисленные явные ссылки на пакеты, благодаря объединенному пакету (мета пакету) ASP.NET Core 2.0. Так выглядит установка мета пакета Microsoft.AspNetCore.All в проект:

Различия в структуре проекта

Структура файла проекта .csproj была упрощена в ASP.NET Core. Вот некоторые значительные изменения:
• Явное указание файлов является необязательным для добавления их в проект. Таким образом, уменьшается риск конфликтов в процессе слияния XML, если над проектом работает большая команда
• Больше нет GUID ссылок на другие проекты, что улучшает читаемость
• Файл можно редактировать без его выгрузки из Visual Studio:

Замена Global.asax

Точкой входа для ASP.NET приложений является Global.asax файл. Такие задачи, как конфигурация маршрута и регистрация фильтров и областей, обрабатываются в файле Global.asax

public class MvcApplication : System.Web.HttpApplication
{
    protected void Application_Start()
    {
        AreaRegistration.RegisterAllAreas();
        FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
        RouteConfig.RegisterRoutes(RouteTable.Routes);
        BundleConfig.RegisterBundles(BundleTable.Bundles);
    }
}

Этот подход тесно связывает приложение и сервер, на котором развернуто приложение. Для уменьшения связности был представлен OWIN как средство, обеспечивающее более правильный путь совместного использования нескольких фреймворков вместе.
OWIN позволяет добавить в конвейер запроса только необходимые модули. Среда выполнения использует Startup для конфигурации сервисов и конвейера запросов.
Startupрегистрирует набор промежуточных сервисов (middleware) вместе с приложением. Для каждого запроса приложение вызывает поочередно каждый из набора промежуточных сервисов, имеющих указатель на первый элемент связанного списка обработчиков.
Каждый компонент промежуточного сервиса может добавить один или несколько обработчиков в конвейер обработки запросов. Это происходит с помощью возврата ссылки на обработчик, который находится в начале списка.
И обработчик, закончив свою работу, вызывает следующий обработчик из очереди.
В ASP.NET Core, точкой входа в приложении является класс Startup, с помощью которого мы нивелируем зависимость от Global.asax.
Если изначально был выбран .NET Framework то при помощи OWIN мы можем сконфигурировать конвейер запросов как в следующем примере:

using Owin;
using System.Web.Http;

namespace WebApi
{
    // Заметка: По умолчанию все запросы проходят через этот конвейер OWIN. В качестве альтернативы вы можете отключить это, добавив appSetting owin: AutomaticAppStartup со значением «false».
    // При отключении вы все равно можете использовать приложения OWIN для прослушивания определенных маршрутов, добавив маршруты в файл global.asax с помощью MapOwinPath или расширений MapOwinRoute на RouteTable.Routes

    public class Startup
    {
        // Вызывается один раз при запуске для настройки вашего приложения.
        public void Configuration(IAppBuilder builder)
        {
            HttpConfiguration config = new HttpConfiguration();
//Здесь настраиваем маршруты по умолчанию, 
            config.Routes.MapHttpRoute("Default", "{controller}/{customerID}", new { controller = "Customer", customerID = RouteParameter.Optional });
//Указываем на то что в качестве файла конфигурации мы будем использовать xml вместо json 

            config.Formatters.XmlFormatter.UseXmlSerializer = true;
            config.Formatters.Remove(config.Formatters.JsonFormatter);
            // config.Formatters.JsonFormatter.UseDataContractJsonSerializer = true;

            builder.UseWebApi(config);
        }
    }
}

Также при необходимости здесь мы можем добавить другие промежуточные сервисы в этот конвейер (загрузка сервисов, настройки конфигурации, статические файлы и т.д.).
Что касается версии фреймворка .NET Core, то здесь используется подобный подход, но не без использования OWIN для определения точки входа. В качестве альтернативы используется метод Main в Program.cs (по аналогии с консольными приложениям), где и происходит загрузка Startup:

using Microsoft.AspNetCore;
using Microsoft.AspNetCore.Hosting;

namespace WebApplication2
{
    public class Program
    {
        public static void Main(string[] args)
        {
            BuildWebHost(args).Run();
        }

        public static IWebHost BuildWebHost(string[] args) =>
            WebHost.CreateDefaultBuilder(args)
                .UseStartup()
                .Build();
    }
}

Startup должен включать метод Configure. В Configure определяется, какие сервисы будут использоваться в конвейере запроса. В следующем примере (взятом из стандартного шаблона web-сайта), несколько методов расширения используются для настройки конвейера с поддержкой:
• BrowserLink
• Error pages
• Static files
• ASP.NET Core MVC
• Identity

public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
{
    loggerFactory.AddConsole(Configuration.GetSection("Logging"));
    loggerFactory.AddDebug();

    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
        app.UseDatabaseErrorPage();
        app.UseBrowserLink();
    }
    else
    {
        app.UseExceptionHandler("/Home/Error");
    }

    app.UseStaticFiles();

    app.UseIdentity();

    app.UseMvc(routes =>
    {
        routes.MapRoute(
            name: "default",
            template: "{controller=Home}/{action=Index}/{id?}");
    });
}

В итоге мы имеем разделение среды выполнения и приложения, что дает нам возможность осуществить переход на другую платформу в будущем.
Заметка: Для более глубокого понимания ASP.NET Core Startup и Middleware, можно изучить Startup in ASP.NET Core

Хранение конфигураций

ASP.NET поддерживает сохранение настроек. Например, это настройки, которые используются средой выполнения, где было развернуто приложение. Сам подход заключался в том, что для хранение пользовательских key-value пар использовалась секция в файле Web.config:

Приложение получало доступ к этим настройкам с помощью коллекции ConfigurationManager.AppSettings из пространства имен System.Configuration :

string userName = System.Web.Configuration.ConfigurationManager.AppSettings["UserName"];
string password = System.Web.Configuration.ConfigurationManager.AppSettings["Password"];

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

{
  "Logging": {
    "IncludeScopes": false,
    "LogLevel": {
      "Default": "Debug",
      "System": "Information",
      "Microsoft": "Information"
    }
  },
  // Здесь можно указать настраиваемые параметры конфигурации. Поскольку это JSON, все представлено в виде пар символов: значение  
 // Как назвать раздел, определяет сам разработчик
  "AppConfiguration": {
    "UserName": "UserName",
    "Password": "Password"
  }
}

Загрузка этого файла в экземпляр IConfiguration для приложения происходит в Startup.cs:

public Startup(IConfiguration configuration)
{
    Configuration = configuration;
}

public IConfiguration Configuration { get; }

А вот так приложение использует Configuration для получения этих настроек:

string userName = Configuration.GetSection("AppConfiguration")["UserName"];
string password = Configuration.GetSection("AppConfiguration")["Password"];

Есть другие способы, основанные на данном подходе, которые позволяют сделать процесс более надежным, например Dependency Injection (DI).
Подход DI обеспечивает доступ к строго типизированному набору объектов конфигурации.

// Предположим, AppConfiguration - это класс, который представляет строго типизированную версию раздела AppConfiguration
services.Configure(Configuration.GetSection("AppConfiguration"));

Заметка: Для более глубокого понимания конфигураций ASP.NET Core, можно ознакомится с Configuration in ASP.NET Core.

Встроенный механизм Dependency Injection

Важной целью при создании больших масштабируемых приложений является ослабление связи между компонентами и сервисами. Dependency Injection – распространенная техника для решения данной проблемы и ее реализация является встроенным в ASP.NET Core компонентом.
В приложениях ASP.NET разработчики использовали сторонние библиотеки для внедрения Injection Dependency. Примером такой библиотеки является Unity .
Пример настройки Dependency Injection с Unity — это реализация UnityContainer, обернутая в IDependencyResolver:

using Microsoft.Practices.Unity;
using System;
using System.Collections.Generic;
using System.Web.Http.Dependencies;

public class UnityResolver : IDependencyResolver
{
    protected IUnityContainer container;

    public UnityResolver(IUnityContainer container)
    {
        if (container == null)
        {
            throw new ArgumentNullException("container");
        }
        this.container = container;
    }

    public object GetService(Type serviceType)
    {
        try
        {
            return container.Resolve(serviceType);
        }
        catch (ResolutionFailedException)
        {
            return null;
        }
    }

    public IEnumerable GetServices(Type serviceType)
    {
        try
        {
            return container.ResolveAll(serviceType);
        }
        catch (ResolutionFailedException)
        {
            return new List();
        }
    }

    public IDependencyScope BeginScope()
    {
        var child = container.CreateChildContainer();
        return new UnityResolver(child);
    }

    public void Dispose()
    {
        Dispose(true);
    }

    protected virtual void Dispose(bool disposing)
    {
        container.Dispose();
    }
}

Создаем экземпляр своего UnityContainer, регистрируем свою службу и устанавливаем разрешение зависимости для HttpConfiguration в новый экземпляр UnityResolver для нашего контейнера:

public static void Register(HttpConfiguration config)
{
    var container = new UnityContainer();
    container.RegisterType(new HierarchicalLifetimeManager());
    config.DependencyResolver = new UnityResolver(container);

    // Опустим остальную часть реализации
}

Далее производим инъекцию IProductRepository там, где это необходимо:

public class ProductsController : ApiController
{
    private IProductRepository _repository;

    public ProductsController(IProductRepository repository)  
    {
        _repository = repository;
    }

}

Поскольку Dependency Injection является частью ядра ASP.NET Core, мы можем добавить свой сервис в метод ConfigureServices внутри Startup.cs:

public void ConfigureServices(IServiceCollection services)
{
    //Добавляем сервис приложения
    services.AddTransient();
}

И далее инъекцию репозитория можно осуществить в любом месте, как и в случае с Unity.
Заметка: Подробности можно посмотреть в Dependency Injection in ASP.NET Core

Работа с статическими файлами

Важной частью веб-разработки является возможность обслуживания статики. Самые распространенные примеры статики — это HTML, CSS, JavaScript и картинки.
Эти файлы нужно сохранять в общей папке приложения (или например в CDN) чтобы в дальнейшем они были доступны по ссылке. В ASP.NET Core был изменен подход для работы с статикой.
В ASP.NET статика хранится в разных каталогах.
А в ASP.NET Core статические файлы по умолчанию хранятся в «web root» (/ wwwroot). И доступ к этим файлам осуществляется с помощью метода расширения UseStaticFiles из Startup.Configure:

public void Configure(IApplicationBuilder app)
{
    app.UseStaticFiles();
}

К примеру, изображения находящееся в папке wwwroot/images будет доступно из браузера по адресу http:///images/.
Заметка: Если был выбран .NET Framework, то дополнительно нужно будет установить NuGet пакет Microsoft.AspNetCore.StaticFiles.
Заметка: Для более подробной ссылки на обслуживание статических файлов в ядре ASP.NET см. Introduction to working with static files in ASP.NET Core.

• Каждый браузер, поддерживающий script type="module", также поддерживает async/await
• Каждый браузер, поддерживающий script type="module", также поддерживает классы.
• Каждый браузер, поддерживающий script type="module", также поддерживает стрелочные функции.
• Каждый браузер, поддерживающий script type="module", также поддерживает fetch, Promises, Map, Set, и многое другое!

Реализация

module.exports = {
  entry: {
    'main-legacy': './path/to/main.js',
  },
  output: {
    filename: '[name].js',
    path: path.resolve(__dirname, 'public'),
  },
  module: {
    rules: [{
      test: /\.js$/,
      use: {
        loader: 'babel-loader',
        options: {
          presets: [
            ['env', {
              modules: false,
              useBuiltIns: true,
              targets: {
                browsers: [
                  '> 1%',
                  'last 2 versions',
                  'Firefox ESR',
                ],
              },
            }],
          ],
        },
      },
    }],
  },
};

module.exports = {
  entry: {
    'main': './path/to/main.js',
  },
  output: {
    filename: '[name].js',
    path: path.resolve(__dirname, 'public'),
  },
  module: {
    rules: [{
      test: /\.js$/,
      use: {
        loader: 'babel-loader',
        options: {
          presets: [
            ['env', {
              modules: false,
              useBuiltIns: true,
              targets: {
                browsers: [
                  'Chrome >= 60',
                  'Safari >= 10.1',
                  'iOS >= 10.3',
                  'Firefox >= 54',
                  'Edge >= 15',
                ],
              },
            }],
          ],
        },
      },
    }],
  },
};

• main.js (ES2015+ синтаксис)
• main-legacy.js (ES5 синтаксис)

Важные моменты

1. Модули загружаются как script defer. Это означает, что они не выполняются до тех пор, пока документ не будет распарсен. Если какую-то часть вашего кода нужно запустить раньше, лучше разбить этот код и загрузить его отдельно.
2. Модули всегда запускают код в строгом режиме (strict mode), поэтому, если по какой-либо причине часть вашего кода должна быть запущена за пределами строгого режима, ее придется загружать отдельно.
3. Модули обрабатывают объявления верхнего уровня переменных (var) и функций (function) отлично от обычных сценариев. Например, к var foo = 'bar' и function foo() {…} в скрипте можно получить доступ через window.foo, но в модуле это не будет работать. Убедитесь, что в своем коде вы не зависите от такого поведения.

Рабочий пример

• Разделение кода (Code splitting)
• Динамический импорт (Dynamic imports, условная загрузка дополнительного кода во время выполнения программы)
• Asset fingerprinting (для эффективного длительного кэширования)

Игра стоит свеч?

Пришло время собирать наши модули как ES2015

rules: [
  {
    test: /\.js$/,
    exclude: /node_modules/, // удалите эту строку
    use: {
      loader: 'babel-loader',
      options: {
        presets: ['env']
      }
    }
  }
]

Заключение

• Каждый браузер, поддерживающий script type="module", также поддерживает async/await
• Каждый браузер, поддерживающий script type="module", также поддерживает классы.
• Каждый браузер, поддерживающий script type="module", также поддерживает стрелочные функции.
• Каждый браузер, поддерживающий script type="module", также поддерживает fetch, Promises, Map, Set, и многое другое!

Реализация

module.exports = {
  entry: {
    'main-legacy': './path/to/main.js',
  },
  output: {
    filename: '[name].js',
    path: path.resolve(__dirname, 'public'),
  },
  module: {
    rules: [{
      test: /\.js$/,
      use: {
        loader: 'babel-loader',
        options: {
          presets: [
            ['env', {
              modules: false,
              useBuiltIns: true,
              targets: {
                browsers: [
                  '> 1%',
                  'last 2 versions',
                  'Firefox ESR',
                ],
              },
            }],
          ],
        },
      },
    }],
  },
};

module.exports = {
  entry: {
    'main': './path/to/main.js',
  },
  output: {
    filename: '[name].js',
    path: path.resolve(__dirname, 'public'),
  },
  module: {
    rules: [{
      test: /\.js$/,
      use: {
        loader: 'babel-loader',
        options: {
          presets: [
            ['env', {
              modules: false,
              useBuiltIns: true,
              targets: {
                browsers: [
                  'Chrome >= 60',
                  'Safari >= 10.1',
                  'iOS >= 10.3',
                  'Firefox >= 54',
                  'Edge >= 15',
                ],
              },
            }],
          ],
        },
      },
    }],
  },
};

• main.js (ES2015+ синтаксис)
• main-legacy.js (ES5 синтаксис)

Важные моменты

1. Модули загружаются как script defer. Это означает, что они не выполняются до тех пор, пока документ не будет распарсен. Если какую-то часть вашего кода нужно запустить раньше, лучше разбить этот код и загрузить его отдельно.
2. Модули всегда запускают код в строгом режиме (strict mode), поэтому, если по какой-либо причине часть вашего кода должна быть запущена за пределами строгого режима, ее придется загружать отдельно.
3. Модули обрабатывают объявления верхнего уровня переменных (var) и функций (function) отлично от обычных сценариев. Например, к var foo = 'bar' и function foo() {…} в скрипте можно получить доступ через window.foo, но в модуле это не будет работать. Убедитесь, что в своем коде вы не зависите от такого поведения.

Рабочий пример

• Разделение кода (Code splitting)
• Динамический импорт (Dynamic imports, условная загрузка дополнительного кода во время выполнения программы)
• Asset fingerprinting (для эффективного длительного кэширования)

Игра стоит свеч?

Пришло время собирать наши модули как ES2015

rules: [
  {
    test: /\.js$/,
    exclude: /node_modules/, // удалите эту строку
    use: {
      loader: 'babel-loader',
      options: {
        presets: ['env']
      }
    }
  }
]

Заключение

lua_package_path "/home/username/lib/lua/lib/?.lua;;";

server {
    # магия, которая держит вебсокет открытым столько, сколько нам надо внутри nginx
    location ~ ^/ws/?(.*)$ {
         default_type 'plain/text';
         # всё что надо здесь для веб сокета - это включить луа, который будет его хендлить
         content_by_lua_file /home/username/www/wsexample.local/ws.lua;
   }

   # а это магия, которая отдаёт ответы от php
   # я шлю только POST запросы, чтобы нормально передать json payload
   location ~ ^/lua_fastcgi_connection(/?.*)$ {
       internal; # видно только подзапросам внутри nginx
        fastcgi_pass_request_body       on;
        fastcgi_pass_request_headers    off;

        # never never use it for lua handler
        #include snippets/fastcgi-php.conf;

        fastcgi_param  QUERY_STRING       $query_string;
        fastcgi_param  REQUEST_METHOD     "POST"; # $request_method;
        fastcgi_param  CONTENT_TYPE       "application/x-www-form-urlencoded"; #вместо $content_type;
        fastcgi_param  CONTENT_LENGTH     $content_length;

        fastcgi_param  DOCUMENT_URI       "$1"; # вместо $document_uri
        fastcgi_param  DOCUMENT_ROOT      $document_root;
        fastcgi_param  SERVER_PROTOCOL    $server_protocol;
        fastcgi_param  REQUEST_SCHEME     $scheme;
        fastcgi_param  HTTPS              $https if_not_empty;

        fastcgi_param  GATEWAY_INTERFACE  CGI/1.1;
        fastcgi_param  SERVER_SOFTWARE    nginx/$nginx_version;

        fastcgi_param  REMOTE_ADDR        $remote_addr;
        fastcgi_param  REMOTE_PORT        $remote_port;
        fastcgi_param  SERVER_ADDR        $server_addr;
        fastcgi_param  SERVER_PORT        $server_port;
        fastcgi_param  SERVER_NAME        $server_name;

        fastcgi_param SCRIPT_FILENAME "$document_root/mywebsockethandler.php";
        fastcgi_param SCRIPT_NAME "/mywebsockethandler.php";
        fastcgi_param REQUEST_URI "$1"; # здесь вообще может быть что угодно. А можно передать параметр из lua чтобы сделать какой-нибудь роутинг внутри php обработчика.
        fastcgi_pass unix:/var/run/php/php7.1-fpm.sock;
        fastcgi_keep_conn               on;
       
}

    local server = require "resty.websocket.server"

    local wb, err = server:new{
        -- timeout = 5000,  -- in milliseconds -- не надо нам таймаут
        max_payload_len = 65535,
    }

    if not wb then
        ngx.log(ngx.ERR, "failed to new websocket: ", err)
        return ngx.exit(444)
    end

    while true do
        local data, typ, err = wb:recv_frame()

        if wb.fatal then return
        elseif not data then
            ngx.log(ngx.DEBUG, "Sending Websocket ping")
            wb:send_ping()
        elseif typ == "close" then
            -- send a close frame back:
            local bytes, err = wb:send_close(1000, "enough, enough!")
            if not bytes then
                ngx.log(ngx.ERR, "failed to send the close frame: ", err)
                return
            end
            local code = err
            ngx.log(ngx.INFO, "closing with status code ", code, " and message ", data)
            break;
        elseif typ == "ping" then
            -- send a pong frame back:

            local bytes, err = wb:send_pong(data)
            if not bytes then
                ngx.log(ngx.ERR, "failed to send frame: ", err)
                return
            end
        elseif typ == "pong" then
            -- just discard the incoming pong frame

        elseif data then

            -- здесь в пути передаётся реальный uri, а json payload уходит в body
            local res = ngx.location.capture("/lua-fastcgi-forward"..ngx.var.request_uri,{method=ngx.HTTP_POST,body=data})

            if wb == nil then
                ngx.log(ngx.ERR, "WebSocket instaince is NIL");
                return ngx.exit(444)
            end

            wb:send_text(res.body)

        else
            ngx.log(ngx.INFO, "received a frame of type ", typ, " and payload ", data)
        end
end

	





Try WebSocket

Message: 


	Close Websocket

lua_package_path "/home/username/lib/lua/lib/?.lua;;";

server {
    # магия, которая держит вебсокет открытым столько, сколько нам надо внутри nginx
    location ~ ^/ws/?(.*)$ {
         default_type 'plain/text';
         # всё что надо здесь для веб сокета - это включить луа, который будет его хендлить
         content_by_lua_file /home/username/www/wsexample.local/ws.lua;
   }

   # а это магия, которая отдаёт ответы от php
   # я шлю только POST запросы, чтобы нормально передать json payload
   location ~ ^/lua_fastcgi_connection(/?.*)$ {
       internal; # видно только подзапросам внутри nginx
        fastcgi_pass_request_body       on;
        fastcgi_pass_request_headers    off;

        # never never use it for lua handler
        #include snippets/fastcgi-php.conf;

        fastcgi_param  QUERY_STRING       $query_string;
        fastcgi_param  REQUEST_METHOD     "POST"; # $request_method;
        fastcgi_param  CONTENT_TYPE       "application/x-www-form-urlencoded"; #вместо $content_type;
        fastcgi_param  CONTENT_LENGTH     $content_length;

        fastcgi_param  DOCUMENT_URI       "$1"; # вместо $document_uri
        fastcgi_param  DOCUMENT_ROOT      $document_root;
        fastcgi_param  SERVER_PROTOCOL    $server_protocol;
        fastcgi_param  REQUEST_SCHEME     $scheme;
        fastcgi_param  HTTPS              $https if_not_empty;

        fastcgi_param  GATEWAY_INTERFACE  CGI/1.1;
        fastcgi_param  SERVER_SOFTWARE    nginx/$nginx_version;

        fastcgi_param  REMOTE_ADDR        $remote_addr;
        fastcgi_param  REMOTE_PORT        $remote_port;
        fastcgi_param  SERVER_ADDR        $server_addr;
        fastcgi_param  SERVER_PORT        $server_port;
        fastcgi_param  SERVER_NAME        $server_name;

        fastcgi_param SCRIPT_FILENAME "$document_root/mywebsockethandler.php";
        fastcgi_param SCRIPT_NAME "/mywebsockethandler.php";
        fastcgi_param REQUEST_URI "$1"; # здесь вообще может быть что угодно. А можно передать параметр из lua чтобы сделать какой-нибудь роутинг внутри php обработчика.
        fastcgi_pass unix:/var/run/php/php7.1-fpm.sock;
        fastcgi_keep_conn               on;
       
}

    local server = require "resty.websocket.server"

    local wb, err = server:new{
        -- timeout = 5000,  -- in milliseconds -- не надо нам таймаут
        max_payload_len = 65535,
    }

    if not wb then
        ngx.log(ngx.ERR, "failed to new websocket: ", err)
        return ngx.exit(444)
    end

    while true do
        local data, typ, err = wb:recv_frame()

        if wb.fatal then return
        elseif not data then
            ngx.log(ngx.DEBUG, "Sending Websocket ping")
            wb:send_ping()
        elseif typ == "close" then
            -- send a close frame back:
            local bytes, err = wb:send_close(1000, "enough, enough!")
            if not bytes then
                ngx.log(ngx.ERR, "failed to send the close frame: ", err)
                return
            end
            local code = err
            ngx.log(ngx.INFO, "closing with status code ", code, " and message ", data)
            break;
        elseif typ == "ping" then
            -- send a pong frame back:

            local bytes, err = wb:send_pong(data)
            if not bytes then
                ngx.log(ngx.ERR, "failed to send frame: ", err)
                return
            end
        elseif typ == "pong" then
            -- just discard the incoming pong frame

        elseif data then

            -- здесь в пути передаётся реальный uri, а json payload уходит в body
            local res = ngx.location.capture("/lua-fastcgi-forward"..ngx.var.request_uri,{method=ngx.HTTP_POST,body=data})

            if wb == nil then
                ngx.log(ngx.ERR, "WebSocket instaince is NIL");
                return ngx.exit(444)
            end

            wb:send_text(res.body)

        else
            ngx.log(ngx.INFO, "received a frame of type ", typ, " and payload ", data)
        end
end

	





Try WebSocket

Message: 


	Close Websocket

• Первый суперкомпьютер DGX-1 на базе Tesla V100 применят в медицине
• IBM открыла доступ к новому 16-кубитному квантовому процессору

• Решение распространенных проблем в облаке IaaS на базе гипервизора VMware
• Оптимизация производительности в vSphere: решение основных проблем с CPU
• Как справиться с пиковыми нагрузками при помощи IaaS

• Первый суперкомпьютер DGX-1 на базе Tesla V100 применят в медицине
• IBM открыла доступ к новому 16-кубитному квантовому процессору

• Решение распространенных проблем в облаке IaaS на базе гипервизора VMware
• Оптимизация производительности в vSphere: решение основных проблем с CPU
• Как справиться с пиковыми нагрузками при помощи IaaS

Стоит ли думать о порте своего приложения уже сейчас?

Причины пока не портировать

Interop

@ExportObjCClass
class KotlinViewController : UIViewController {

    constructor(aDecoder: NSCoder) : super(aDecoder)
    override fun initWithCoder(aDecoder: NSCoder) = initBy(KotlinViewController(aDecoder))

    @ObjCOutlet
    lateinit var label: UILabel

    @ObjCOutlet
    lateinit var textField: UITextField

    @ObjCOutlet
    lateinit var button: UIButton

    @ObjCAction
    fun buttonPressed() {
        label.text = "Konan says: 'Hello, ${textField.text}!'"
    }
}

Если нужно вызвать Kotlin из Objective-C/Swift

Overhead

Обратная совместимость

inline

Заключение