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

DI как основа для построения фреймворка, применительно к вебу, довольно молодой подход. Что бы тут было понятней о чем идет речь, начну c привычных для react-разработчиков вещей.

От контекстов к DI

Уверен, что многие использовали контексты при работе с react. Если не напрямую, то наверняка через connect в redux или inject в mobx-react. Суть в том, что в одном компоненте (MessageList) мы объявляем нечто в контексте, а в другом (Button) — говорим, что хотим получить это нечто из контекста.

const PropTypes = require('prop-types');

const Button = ({children}, context) =>
  
    {children}
  ;

Button.contextTypes = {color: PropTypes.string};

class MessageList extends React.Component {
  getChildContext() {
    return {color: "purple"};
  }

  render() {
    return Ok;
  }
}

Т.е. один раз в родительском компоненте задается context.color, а далее он автоматически пробрасывается любым нижележащим компонентам, в которых через contextTypes объявлена зависимость от color. Таким образом Button можно кастомизировать без прокидывания свойств по иерархии. Причем на любом уровне иерархии можно через getChildContext() ... переопределить color для всех дочерних компонент.

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

Однако, для реакта, в виду недостаточной продуманности, этот подход пока развит слабо. Напрямую его использовать разработчики не рекомендуют:

It is an experimental API and it is likely to break in future releases of React

написано в документации. Оно experimental в текущем виде уже достаточно давно и ощущение, что разработка зашла в тупик. Контексты в компонентах сцеплены с инфраструктурой (getChildContext), псевдотипизацией через PropTypes и больше похожи на service locator, который некоторые считают антипаттерном. Роль контекстов, на мой взгляд, недооценена и в реакте второстепенная: локализация и темизация, а также биндинги к библиотекам вроде redux и mobx.

В других фреймворках подобные инструменты развиты лучше. Например, в vue: provide/inject, а в angular, его angular di это уже полноценный навороченный DI с поддержкой типов typescript. По-сути, начиная с Angular второй версии, разработчики попытались переосмыслить опыт бэкенда (где DI уже давно существует) применительно к фронтенду. А что если попытаться развить аналогичную идею для реакта и его клонов, какие проблемы бы решились?

Прибивать или нет, вот в чем вопрос

В полноценном реакт/redux-приложении не всё делают через redux-экшены. Состояние какой-нибудь малозначительной галочки удобнее реализовать через setState. Получается — через redux громоздко, а через setState не универсально, но проще, т.к. он всегда под рукой. Статья You Might Not Need Redux известного автора, как бы говорит "если вам не нужно масштабирование — не используйте redux", подтверждая эту двойственность. Проблема в том, что это сейчас не нужно, а завтра может быть понадобится прикрутить логирование состояния галочки.

В другой статье того же автора, Presentational and Container Components, говорится примерно, что "Все компоненты равны (Presentational), но некоторые равнее (Container)" и при этом высечены в граните (прибиты к redux, mobx, relay, setState). Кастомизация Container компонента усложняется — не предполагается его переиспользовать, он уже прибит к реализации состояния и контексту.

Что бы как-то упростить создание Container-компонент, придумали HOC, но по-сути мало что поменялось. Просто чистый компонент стали комбинировать через connect/inject с чем-то вроде redux, mobx, relay. А полученный монолитный Container использовать в коде.

Иными словами, говорим Presentational и Container, а подразумеваем — переиспользуемый и непереиспользуемый. Первый удобно кастомизировать т.к. все точки расширения в свойствах, а второй — рефакторить, т.к свойств меньше, за счет его прибитости к стейту и некоторой логике. Это — некий компромисс по решению двух противоположных проблем, плата за который — разделение компонент на два типа и жертвование принципом открытости/закрытости.

Например, как в статье Заменяй и властвуй — подход SOLID, где предлагается делать большинство компонент максимально простыми, ухудшая их целостность. Но, сложные компоненты из простых все-равно надо будет где-то собирать и при этом остается вопрос как их кастомизировать. Т.е. проблема переносится на другой уровень.

> this.setState({ dialogOpen: false })} />
    
        
            
                > this.setState({ dialogOpen: false })} />
                Dialog header
            
            Some content
            
                > this.setState({ dialogOpen: false })} key="cancel">
                    {resources.Navigator_ButtonClose}
                
                
                    {resources.Navigator_ButtonSelect}
                
            
        
    

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

Прототип

Развивая идею внедрения зависимостей, можно решить некоторые из этих проблем. Разберем решение на основе вот такого примера:

// @flow

// @jsx lom_h

// setup...

class HelloService {
    @mem name = ''
}

function HelloView(props: {greet: string}, service: HelloService) {
    return 

        {props.greet}, {service.name}
        
> { service.name = e.target.value }} />
    
}
// HelloView.deps = [HelloService]

ReactDOM.render(, document.getElementById('mount'))

fiddle

Здесь есть одна универсальная форма компонента в виде функции, независимо от того, работает он с состоянием или нет. Контексты используют типы. Из них автоматически генерируются описания зависимостей с помощью babel-plugin-transform-metadata. Аналогично typescript, который это делает, правда, только для классов. Хотя можно описывать аргументы и вручную: HelloView.deps = [HelloService]

Lifecycle

А как же быть с жизненным циклом компонента? А так ли нужна низкоуровневая работа с ним в коде? Посредством HOC как раз пытаются убрать эти lifecycle methods из основного кода, например, как в relay/graphql.

Идея в том, что актуализация данных — это не ответственность компонента. Если у вас загрузка данных происходит по факту доступа к этим данным (например, используется lazyObservable из mobx-utils), то componentDidMount в этом случае не нужен. Если надо прикрутить jquery-плагин, то есть свойство refs в элементе и т.д.

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

Поди туда — не знаю куда, принеси то — не знаю что

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

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

Например, без DI можно проектировать, подразумевая кастомизацию через наследование. Т.е. дробить содержимое на мелкие методы, теряя при этом в наглядности и иерархии. О минусах этого подхода пишет автор в статье Идеальный UI фреймворк:

class MyPanel extends React.Component {
    header() { return 
{this.props.head}
 }
    bodier() { return 
{this.props.body}
 }
    childs() { return [ this.header() , this.bodier() ] }
    render() { return 
{this.childs()}
}

class MyPanelExt extends MyPanel {
    footer() { return 
{this.props.foot}
 }
    childs() { return [ this.header() , this.bodier() , this.footer() ] }
}

Надо сказать, что этот автор (@vintage), придумал формат tree, который позволяет описать вышеприведенный пример с сохранением иерархии. Несмотря на то, что многие критикуют этот формат, у него есть преимущество как раз в виде переопределяемости даже самых мелких деталей без специального разбиения на части и рефакторинга. Иными словами, это бесплатная (почти, кроме постижения новой необычной концепции) буковка O в SOLID.

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

В js/ts, в runtime, без усложнений или внедрения строковых ключей, ухудшающих безопасность кода, нельзя ссылаться на интерфейс. Поэтому следующий пример не заработает в flow или typescript (но аналогичный заработает в C# или Dart):

interface ISome {}

class MySome implements ISome {}

const map = new Map()
map.set(ISome, MySome)

Однако, можно ссылаться на абстрактный класс или функцию.

class AbstractSome {}

class MySome extends AbstractSome {}

const map = new Map()
map.set(AbstractSome, MySome)

Т.к. создание объектов и компонент происходит внутри DI-контейнера, а там внутри может быть подобный map, то любую реализацию можно переопределить. А т.к. компоненты, кроме самых примитивных — функции, то их можно подменять на функции с таким же интерфейсом, но с другой реализацией.

Например, TodoResetButtonView является частью TodoView. Требуется переопределить TodoResetButtonView на кастомную реализацию.

function TodoResetButtonView({onClick}) {
  return reset
}

function TodoView({todo, desc, reset}) {
    return 

        > todo.finished = !todo.finished}
        />{todo.title} #{todo.id} ({desc.title})
        reset
    
}

Предположим у нас нет возможности править TodoView (он в другой библиотеке и мы не хотим его трогать, нарушая open/close принцип и заново тестировать 11 других проектов, которые его использовали со старой кнопкой).

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

function ClonedTodoResetButtonView({onClick}) {
  return cloned reset
}

const ClonedTodoView = cloneComponent(TodoView, [
    [TodoResetButtonView, ClonedTodoResetButtonView]
], 'ClonedTodoView')

const ClonedTodoListView = cloneComponent(TodoListView, [
    [TodoView, ClonedTodoView]
], 'ClonedTodoListView')

ReactDOM.render(, document.getElementById('mount'));

fiddle

Переопределять иногда надо не только компоненты, но и их зависимости:

class AbstractHelloService {
    name: string
}

function HelloView(props: {greet: string}, service: AbstractHelloService) {
    return 

        {props.greet}, {service.name}
        
> { service.name = e.target.value }} />
    
}

class AppHelloService {
    @mem name = 'Jonny'
}

function AppView() {
  return 
}
AppView.aliases = [
    [AbstractHelloService, AppHelloService]
]

fiddle

HelloView получит экземпляр класса AppHelloService. Т.к. AppView.aliases для всех дочерних компонент переопределяет AbstractHelloService.

Есть конечно и минус подхода "все кастомизируется" через наследование. Т.к. фреймворк предоставляет больше точек расширения, то, больше ответственности по кастомизации перекладывается на того, кто использует компонент, а не проектирует его. Переопределяя части компонента "таблица", без осознания смысла, можно ненароком превратить его в "список", а это плохой признак, т.к. является искажением исходного смысла (нарушается LSP принцип).

Разделение состояния

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

class HelloService {
    @mem name = 'John'
}

function HelloView(props: {greet: string}, service: HelloService) {
    return 

        {props.greet}, {service.name}
        
> { service.name = e.target.value }} />
    
}

class AppHelloService {
    @mem name = 'Jonny'
}

function AppView(_, service: HelloService) {
    return 

        
        
    
}

fiddle

В такой конфигурации, оба HelloView разделяют общий экземпляр HelloService. Однако, без HelloService в AppView, на каждый дочерний компонент будет свой экземпляр.

function AppView() {
    return 

        
        
    
}

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

Стили

Я не утверждаю, что подход css-in-js единственно правильный для использования в веб. Но и тут можно применить идею внедрения зависимостей. Проблема аналогична вышеописанной с redux/mobx и контекстами. Например, как и во многих подобных библиотеках, стили jss прибиваются к компоненту через обертку injectSheet и компонент связывается с конкретной реализацией стилей, с react-jss:

import React from 'react'
import injectSheet from 'react-jss'

const styles = {
  button: {
    background: props => props.color
  },
  label: {
    fontWeight: 'bold'
  }
}

const Button = ({classes, children}) => (
  
    
      {children}
    
  
)

export default injectSheet(styles)(Button)

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

// ... setup
import {action, props, mem} from 'lom_atom'
import type {NamesOf} from 'lom_atom'

class Store {
  @mem red = 140
}

function HelloTheme(store: Store) {
  return {
    wrapper: {
      background: `rgb(${store.red}, 0, 0)`
    }
  }
}
HelloTheme.theme = true

function HelloView(
  _,
  {store, theme}: {
    store: Store,
    theme: NameOf
  }
) {
  return 

    color via css {store.red}: > { store.red = Number(target.value) }}
    />
  
}

fiddle

Такой подход для стилей обладает всеми преимуществами DI, таким образом обеспечивается темизация и реактивность. В отличие от переменных в css, здесь работают типы в flow/ts. Из минусов — накладные расходы на генерацию и обновление css.

Итог

В попытке адаптировать идею внедрения зависимостей для компонентов, получилась библиотека reactive-di. Простые примеры в статье постронены на ее основе, но есть и более сложные, с загрузкой, обработкой статусов загрузки, ошибок и т.д. Есть todomvc бенчмарк для react, preact, inferno. В котором можно оценить оверхед от использования reactive-di. Правда, на 100 todos, погрешность измерений у меня была больше, чем этот оверхед.

Получился упрощенный Angular. Однако есть ряд особенностей, reactive-di

1. Умеет интегрироваться с реактом и его клонами, оставаясь совместимым с legacy-компонентами на чистом реакте
2. Позволяет писать на одних чистых компонентах, не оборачивая их в mobx/observe или подобное
3. Хорошо работает с типами в flowtype не только для классов, но и для компонент-функций
4. Ненавязчив: не требуется кучи декораторов в коде, компоненты абстрагируются от react, его можно поменять на свою реализацию, не затрагивая основной код
5. Настраивается просто, не нужно региситрации зависимостей, provide/inject-подобных конструкций
6. Позволяет доопределять содержимое компонента без его модификации, c сохранением иерархии его внутренностей
7. Позволяет ненавязчиво, через интерфейсы, интегрировать css-in-js решения в компоненты

Почему до сих пор идею контекстов не развивали в этом ключе? Скорее всего непопулярность DI на фронтенде объясняется не повсеместным господством flow/ts и отсутствием стандартной поддержки интерфейсов на уровне метаданных. Попытками скопировать сложные реализации с других backend-ориентированных языков (как InversifyJS клон Ninject из C#) без глубокого переосмысления. А также пока недостаточным акцентом: например, некоторое подобие DI есть в react и vue, но там эти реализации являются неотделимой частью фреймворка и роль их второстепенная.

Хороший DI — это еще половина решения. В примерах выше часто мелькал декоратор @mem, который необходим для управления состоянием, построенном на идее ОРП. С помощью mem можно писать код в псевдосинхронном стиле, с простой, по-сравнению с mobx, обработкой ошибок и статусов загрузки. Про него я расскажу в следующей статье.

Model-View-Intent (MVI)

• intent(): Функция, которая принимает входные данные от пользователя (например, события пользовательского интерфейса, такие как события click) и переводит в то, что будет передано как параметр функции model(). Это может быть простая строка для установки значения модели или более сложная структура данных, например, объект.
• model(): Функция, которая использует выходные данные из функции intent() в качестве входных данных для работы с моделью. Результат работы этой функции – новая модель (с измененным состоянием). При этом нужно, чтобы данные были неизменяемыми. В первой части я приводил пример с приложением-счетчиком: мы не меняем уже существующий экземпляр модели, а создаем новую модель согласно изменениям, описанным в интенте. Функция model() – лишь часть кода, ответственная за создание нового объекта модели. По сути, функция model() осуществляет вызов бизнес-логики приложения (будь-то Interactor, UseCase, Repository) и в результате возвращает новый объект модели.
• view(): Функция, которая получает на входе модель от model() и просто отображает ее. Обычно функция view() выглядит как view.render(model).

Соединяем точки с помощью RxJava

public interface SearchViewState {

   final class SearchNotStartedYet implements SearchViewState {}
   final class Loading implements SearchViewState {}

   final class EmptyResult implements SearchViewState {
       private final String searchQueryText;

       public EmptyResult(String searchQueryText) {
           this.searchQueryText = searchQueryText;
       }

       public String getSearchQueryText() {
           return searchQueryText;
       }
   }

   final class SearchResult implements SearchViewState {
       private final String searchQueryText;
       private final List result;

       public SearchResult(String searchQueryText, List result) {
           this.searchQueryText = searchQueryText;
           this.result = result;
       }

       public String getSearchQueryText() {
           return searchQueryText;
       }

       public List getResult() {
           return result;
       }
   }

   final class Error implements SearchViewState {
       private final String searchQueryText;
       private final Throwable error;

       public Error(String searchQueryText, Throwable error) {
           this.searchQueryText = searchQueryText;
           this.error = error;
       }

       public String getSearchQueryText() {
           return searchQueryText;
       }

       public Throwable getError() {
           return error;
       }
   }

public class SearchInteractor {
   final SearchEngine searchEngine; 

   public Observable search(String searchString) {
       if (searchString.isEmpty()) {
           return Observable.just(new SearchViewState.SearchNotStartedYet());
       }

       return searchEngine.searchFor(searchString)
              .map(products -> {
                  if (products.isEmpty()) {
                      return new SearchViewState.EmptyResult(searchString);
                  } else {
                      return new SearchViewState.SearchResult(searchString, products);
                  }
              })
              .startWith(new SearchViewState.Loading())
              .onErrorReturn(error -> new SearchViewState.Error(searchString, error));
   }
}

public interface SearchView {
   Observable searchIntent();
   void render(SearchViewState viewState);
}

public class SearchFragment extends Fragment implements SearchView {

   @BindView(R.id.searchView) android.widget.SearchView searchView;
   @BindView(R.id.container) ViewGroup container;
   @BindView(R.id.loadingView) View loadingView;
   @BindView(R.id.errorView) TextView errorView;
   @BindView(R.id.recyclerView) RecyclerView recyclerView;
   @BindView(R.id.emptyView) View emptyView;
   private SearchAdapter adapter;

   @Override 
    public Observable searchIntent() {
       return RxSearchView.queryTextChanges(searchView)
               .filter(queryString -> queryString.length() > 3 || queryString.length() == 0)
               .debounce(500, TimeUnit.MILLISECONDS);
   }

   @Override
    public void render(SearchViewState viewState) {
       if (viewState instanceof SearchViewState.SearchNotStartedYet) {
           renderSearchNotStarted();
       } else if (viewState instanceof SearchViewState.Loading) {
           renderLoading();
       } else if (viewState instanceof SearchViewState.SearchResult) {
           renderResult(((SearchViewState.SearchResult) viewState).getResult());
       } else if (viewState instanceof SearchViewState.EmptyResult) {
           renderEmptyResult();
       } else if (viewState instanceof SearchViewState.Error) {
           renderError();
       } else {
           throw new IllegalArgumentException("Don't know how to render viewState " + viewState);
       }
   }

   private void renderResult(List result) {
       TransitionManager.beginDelayedTransition(container);
       recyclerView.setVisibility(View.VISIBLE);
       loadingView.setVisibility(View.GONE);
       emptyView.setVisibility(View.GONE);
       errorView.setVisibility(View.GONE);
       adapter.setProducts(result);
       adapter.notifyDataSetChanged();
   }

   private void renderSearchNotStarted() {
       recyclerView.setVisibility(View.GONE);
       loadingView.setVisibility(View.GONE);
       errorView.setVisibility(View.GONE);
       emptyView.setVisibility(View.GONE);
   }

   private void renderLoading() {
       recyclerView.setVisibility(View.GONE);
       loadingView.setVisibility(View.VISIBLE);
       errorView.setVisibility(View.GONE);
       emptyView.setVisibility(View.GONE);
   }

   private void renderError() {
       recyclerView.setVisibility(View.GONE);
       loadingView.setVisibility(View.GONE);
       errorView.setVisibility(View.VISIBLE);
       emptyView.setVisibility(View.GONE);
   }

   private void renderEmptyResult() {
       recyclerView.setVisibility(View.GONE);
       loadingView.setVisibility(View.GONE);
       errorView.setVisibility(View.GONE);
       emptyView.setVisibility(View.VISIBLE);
   }
}

public class SearchPresenter extends MviBasePresenter {
   private final SearchInteractor searchInteractor;

   @Override protected void bindIntents() {
       Observable search =
               intent(SearchView::searchIntent)
                       .switchMap(searchInteractor::search) // на видео я использовал flatMap(), но здесь имеет смысл использовать switchMap()
                       .observeOn(AndroidSchedulers.mainThread());

       subscribeViewState(search, SearchView::render);
   }
}

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

Шаг 1. Обучение

Шаг 2. Идем практиковаться!

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

Шаг 3. Практика и специализация

Вот еще 4 совета, чтобы хорошо себя зарекомендовать в компании

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

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

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

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

Творчество роботов

Восприятие произведений

Творчество — это эмоциональное воздействие

Нейросети — в помощь художнику. И музыканту

Искусство видеть

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

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

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

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

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

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

• Форм-фактор: Cтоечный (3U)
• Процессор: 2 x Intel Xeon E5-2600 v3 (6 или 8 ядерная конфигурация)
• Память: 256Gb (DDR4), может быть расширена до 1Tb (16 слотов)
• Flash-память: 512Mb
• Диски:
  • 16 x 3.5" SAS, SATA или 2.5" SAS/SATA SSD
  • 4 x 2.5" SAS/SATA SSD
  • 2 x mSATA
• Максимальная емкость хранилища: 160TB
• Максимальная емкость решения (при помощи полок расширения): 1440TB
• Сетевые интерфейсы:
  • 4 x SFP+ 10GbE ports
  • 2 x RJ-45 1GbE ports
• Слоты/порты расширения:
  • 4 x PCle: 3 слота PCIe Gen3 x8, 1 слот PCIe Gen3 x16
  • 4 x USB 3.0
  • 1 x VGA
• Питание: 2 x 650 Вт
• Энергопотребление:
  • В спящем режиме: 255 Вт
  • В работе: 363 Вт

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

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

О 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.

• Каждый браузер, поддерживающий 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']
      }
    }
  }
]

Заключение

• расскажем об анонсах в ключевых направлениях: бизнес-ориентированный ЦОД и построение катастрофоустойчивых ИТ-систем
• проанализируем современные тенденции в сфере корпоративной мобильности
• поделимся практическим опытом оптимизации и развития ИТ-инфраструктуры на базе продуктов Fujitsu

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

Trace Mode и с чем его едят

• нижний уровень, опрос устройств. Осуществляется «Источниками/Приемниками» — некие структурные шаблоны, которые определяют различные протоколы, технологии и интерфейсы (Modbus RTU/TCP-IP, SNMP, DDE, OPC etc.), содержат настройки связи. В общем, являются софтварным отражением периферии.
• верхний уровень, тэги. В Trace Mode они называются «Каналами». Эти шаблоны уже определяют тип параметра, получаемого от «Источников» (дискретный/аналоговый), задают для него масштабирование, аварийные/предаварийные пределы (для аналоговых сигналов), назначают привязку к словарям аварийных сообщений, наконец, «каналы» же устанавливают будет ли данный параметр архивироваться или нет. Соответственно, к различным графическим элементам на мнемосхемах эти «каналы» можно привязать для оперативного мониторинга.

На заметку.
Все продукты в семействе Trace Mode защищены HASP-ключами. Для работы в IDE требуется свой ключ, лимитирующий в проекте количество источников данных (e.g. лицензия на 128, 256, 512… N устройств). Для работы МРВ требуется свой ключ. Он лимитирует максимальное количество «каналов» в скомпилированном проекте; в подмножество каналов, помимо самих каналов, входят и вызовы программ, шаблонов экранов. Также ключ определяет доступность некоторых технологий, у нас, в частности, возможность запуска OPC-сервера Trace Mode. Для клиент-консолей, которые используются в АРМах, ключ лимитирует число экранов (в проекте дюжина  мнемосхем, а ключ на десять? Два экрана перестанут вызываться). «Тонкие» клиенты? Ну вы поняли, ограничения на кол-во одновременных подключений, шаблонов документов...

Крутые метрики и все-все-все

# Config file for collectd(1).
#
# Some plugins need additional configuration and are disabled by default.
# Please read collectd.conf(5) for details.
#
# You should also read /usr/share/doc/collectd-core/README.Debian.plugins
# before enabling any more plugins.

Hostname "graphite"
FQDNLookup true
#BaseDir "/var/lib/collectd"
#PluginDir "/usr/lib/collectd"
TypesDB "/usr/share/collectd/types.db" "/etc/collectd/my_types.db"
Interval 10
#Interval 60
#Timeout 2
#ReadThreads 5

LoadPlugin logfile
LoadPlugin cpu
LoadPlugin disk
LoadPlugin memory
LoadPlugin modbus  //тот самый плагин
LoadPlugin snmp
LoadPlugin write_graphite

#LoadPlugin email
#LoadPlugin sensors
#LoadPlugin serial


    LogLevel "info"
    File STDOUT
    Timestamp true
    PrintSeverity true




#DC2 VRU Data -------------------------------------------------

 
   RegisterBase 380
   RegisterType int16
   Type word
   Instance "VRU-QF1-Status"
 

 
   RegisterBase 381
   RegisterType int16
   Type word
   Instance "VRU-QF2-Status"
 
…
 
   RegisterBase 300
   RegisterType int16
   Type voltage
   Instance "VRU1-U-AN"
 

 
   RegisterBase 301
   RegisterType int16
   Type voltage
   Instance "VRU1-U-BN"
 

 
   RegisterBase 302
   RegisterType int16
   Type voltage
   Instance "VRU1-U-CN"
 

 
   Address "XXX.XXX.XXX.XXX"
   Port    "502"
   Interval 5
   
   
    Instance "Vars"
    Collect  "VRU-QF1-Status"
    Collect  "VRU-QF2-Status"
...
    Collect  "VRU1-U-AN"
    Collect  "VRU1-U-BN"
    Collect  "VRU1-U-CN"
...
   
 


# DC2_Module1_UPS1 -------------------------------------------------
 
  Type "percent"
  Table false
  Instance "Load_A"
  Values ".1.3.6.1.2.1.33.1.4.4.1.5.1"
 

 
  Type "percent"
  Table false
  Instance "Load_B"
  Values ".1.3.6.1.2.1.33.1.4.4.1.5.2"
 

 
  Type "percent"
  Table false
  Instance "Load_C"
  Values ".1.3.6.1.2.1.33.1.4.4.1.5.3"
 
...
 
   Address "XXX.XXX.XXX.XXX"
   Version 1
   Community "public"
   Collect "UPS1_load_A"
   Collect "UPS1_load_B"
   Collect "UPS1_load_C"
...
   Interval 5
 


	
		Host "localhost"
#		Port "2003"
		Prefix "collectd."
		Protocol "tcp"
#		Postfix "collectd"
#		StoreRates false
#		AlwaysAppendDS false
#		EscapeCharacter "_"
	


Include "/etc/collectd/collectd.conf.d/*.conf"

Подводя итоги

1. Бесплатно (финдир вытирает скупую мужскую слезу счастья).
2. Open Source. Можно теоретически добавить недостающую фичу, написав ее самому.
3. Доступность. По сути, это страничка в браузере для конечного пользователя, а, следовательно, есть у каждого в гаджете в кармане. В Trace Mode поддержки для гаджетов толком нет.
4. Простота и удобство расширения. Достаточно при первоначальной настройке collectd + graphite «скормить» им все необходимые данные — и последующие получившиеся метрики можно редактировать и преобразовывать на лету прямо в grafana. Скажем «Нет!» компиляциям МРВ и клиент-консолей в Trace Mode!
5. Очень неплохие возможности по отображению и анализу графиков «из коробки». Trace Mode в этом плане крайне, хм, консервативен.
6. Есть оповещения и уведомления об аварийных ситуациях во всех новомодных чатиках, по почте etc. Trace Mode же может рассылать E-mail`ы и за отдельную денежку — SMS (если у вас есть необходимое железо).

1. Полновесную SCADA подобной связкой не заменить. Никакого управления тех.процессом. Если, конечно, управление Вам необходимо.
2. Open Source. Ваш покорный слуга не имеет надлежащей квалификации для дописания хотелок, а посему смиренно ждет и/или просит более умных товарищей в git-сообществе.
3. Набор панелей невелик (хоть и расширяется за счет плагинов).
4. Движок алертинга пока очень прост, хитрых условий в нем не настроишь. Разработчики обещают расширить функционал.

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

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

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

Заключение

• Онлайн доверие и репутацию систем;
• Крипто-токены/ криптовалюты, и, в целом, цифровые активы;
• Смарт-контракты;
• Согласованные алгоритмы;
• Алгоритмы анти-спама и алгоритмы, устойчивые к атакам Сибиллы;
• Активизированные рынки для вычислительных ресурсов;
• Децентрализованные системы социального обеспечения /соц. помощи/ основного дохода; Децентрализованное управление (как для коммерческих, так и для некоммерческих организаций).

Привет, Друзья!

Я написал библиотеку поисков путей на произвольных графах, и хотел бы поделиться ей с вами: http://github.com/anvaka/ngraph.path

Пример использования на огромном графе:

Поиграться с демо можно здесь: https://anvaka.github.io/ngraph.path.demo/

В библиотеке используется мало-известный вариант A* поиска, который называется NBA*. Это двунаправленный поиск, с расслабленными требованиями к функции-эвристике, и очень агрессивным критерием завершения. Не смотря на свою малоизвестность у алгоритма отличная скорость сходимости к оптимальному решению.

Описание разных вариантов A* уже не раз встречалось на хабре. Мне очень понравилось вот это, потому повторяться в этой статье я не буду. Под катом расскажу подробнее почему библиотека работает быстро и о том, как было сделано демо.

Почему библиотека работает быстро?

"Как-то не верится что так быстро. Ты точно ниче не считаешь предварительно?"
Реакция друга, который первый раз увидел библиотеку.

Сразу должен признаться, я не верю что моя реализация — самая быстрая из возможных. Она работает достаточно быстро учитывая окружение в котором находится (браузер, javascript). Ее скорость сильно будет зависеть от размера графа. И, конечно же, то, что сейчас есть в репозитории можно ускорить и улучшить.

Статистика

Для замера производительности я взял граф дорог из Нью-Йорка ( ~730 000 ребер, 260 000 узлов). Таблица ниже показывает статистику времени, необходимого для решения одной задачи поиска пути из 250 случайно выбранных:

Каждый алгоритм решал одну и ту же задачу. A* ленивый самый быстрый, но его решение не всегда оптимально. По-сути, это двунаправленный A* который сразу же выходит как только оба поиска встретились. NBA* двунаправленный, сходится к оптимальному решению. В 99% ему понадобилось меньше чем 172 миллисекунды, чтобы найти кратчайший путь (p99).

Оптимизации

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

Во-первых, я изменил структуру данных в приоритетной очереди таким образом, что обновление приоритета любого элемента очереди занимает O(lg n) времени. Это достигается тем, что каждый элемент отслеживает свою позицию в куче во время перестройки очереди.

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

Ну и наконец, алгоритм поиска NBA* имеет очень красивый и жесткий критерий посещения узлов.

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

Как работает демо?

Создание библиотеки это, конечно, очень интересно. Но мне кажется демо-проект заслуживает отдельного описания. Я усвоил несколько уроков, и хотел бы поделиться с вами, в надежде, что это окажется полезным.

Прежде чем начнем. Кто-то меня спросил: "Но ведь это же граф? Как можно карту представить в виде графа?". Легче всего представить каждый перекресток узлом графа. У каждого перекрестка есть позиция (x, y). Каждый прямой участок дороги сделаем ребром графа. Изгибы дороги можно моделировать как частный случай перекрестков.

Готовим данные

Конечно, я слышал об https://www.openstreetmap.org, но их внешний вид меня не сильно привлекал. Когда же я обнаружил API и инструменты типа http://overpass-turbo.eu/ — это как новый мир открылся перед глазами :). Данные они отдают под лицензией ODbL, которая требует чтобы их упомянули (чем больше людей знают о сервисе — тем лучше становится сервис).

API позволяет делать очень сложные запросы, и дает потрясающие объемы информации.

Например, такой запрос даст все велодороги в Москве:

[out:json];
// Сохранить область в переменную `a`
(area["name"="Москва"])->.a;
// Скачать все дороги внутри a у которых аттрибут `highway == cycleway`
way["highway"="cycleway"](area.a);

// и объединить дороги с узлами графа (узлы содержат геопозицию)
node(w);

// Наконец, вернуть результаты
out meta;

API очень хорошо описано здесь: http://wiki.openstreetmap.org/wiki/Overpass_API

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

Сохраняем граф

Данные OSM отдает в виде XML или JSON. К сожалению оба форматы слишком объемные — карта Москвы со всеми дорогами занимает около 47MB. Моя же задача была сделать загрузку сайта как можно быстрее (даже на мобильном соединении).

Можно было бы попробовать сжать gzip'ом — карта Москвы из 47МБ превращается в 7.1МБ. Но при таком подходе у меня не было бы контроля над скоростью распаковки данных — их бы пришлось парсить javascript'ом на клиенте, что тоже повлияло бы на скорость инициализации.

Я решил написать свой формат для графа. Граф разбивается на два бинарных файла. Один с координатами всех вершин, а второй с описанием всех ребер.

Файл с координатами — это просто последовательность из x, y пар (int32, 4 байта на координату). Смещение по которому находится пара координат я рассматриваю как иденификатор вершины (nodeId).

Ребра графа превращаются в обычную последовательность пар fromNodeId, toNodeId.

Последовательность на картинке означает, что первый узел ссылается на второй, а второй ссылается на третий, и так далее.

Общий размер для графа с V узлами и E ребрами можно подсчитать как:

 storage_size = V * 4 * 2 +  # 4 байта на пару координат на узел
                E * 4 * 2 =  # 4 байта на пару идентификаторов вершин
                (V + E) * 8  # суммарно, в байтах

Это не самый эффективный способ сжатия, но его очень легко реализовать и можно очень быстро восстановить начальный граф на клиенте. Типизированные массивы в javascript'e работают быстрее, чем парсинг JSON'a.

Сначала я хотел добавить также вес ребер, но остановил себя, ибо загрузка на слабом мобильном соединении даже для маленьких графах станет еще медленнее.

В первую очередь мобильные телефоны

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

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

Я тестировал демо в первую очередь на платформах iPhone и Андроид. Для тестов на Андроиде я нашел самый дешевый телефон и использовал его. Это очень сильно помогло с отладкой производительности и удобства использования на маленьком экране.

Асинхронность

Самая медленная часть в демо была начальная загрузка сайта. Код, который инициализировал граф выглядел как-то так:

for (let i = 0; i < points.length; i += 2) {
    let nodeId = Math.floor(i / 2);

    let x = points[i + 0];
    let y = points[i + 1];

    // graph это https://github.com/anvaka/ngraph.graph
    graph.addNode(nodeId, { x, y })
}

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

Выход? Я знаю, некоторые используют Web Workers. Это прекрасное решение, учитывая что все сейчас многоядерное. Но в моем случае, использование web workers значительно бы продлило время, необходимое для создания демо. Нужно было бы продумать как передавать данные между потоками, как синхронизировать, как сохранить жизнь батарее, как быть когда web workers не доступны и т.д.

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

С таким решением у браузера появляется возможность постоянно информировать пользователя о том, что происходит внутри:

 Отрисовка

Теперь, когда у нас загружен граф, нужно показать его на экране. Конечно, использовать SVG для отрисовки миллиона элементов не годится — скорость начнет проседать после первого десятка тысяч. Можно было бы нарезать граф на тайлы, и использовать Leaflet или OpenSeadragon чтоб нарисовать большую картинку.

Мне же хотелось иметь больше контроля на кодом (и подучить WebGL), поэтому я написал свой WebGL отрисовщик с нуля. Там я использую подход "scene graph". В таком подходе мы строим сцену из иерархии элементов, которые можно нарисовать. Во время отрисовки кадра, мы проходим по графу, и даем возможность каждому узлу накопить трансформации или вывести себя на экран. Если вы знакомы с three.js или даже обычным DOM'ом — подход будет не в новинку.

Отрисовщик доступен здесь, но я намеренно не документировал его сильно. Это проект для моего собственного обучения, и я не хочу создавать впечатление, что им можно пользоваться :)

Батарейка

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

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

Я до сих пор не нашел способ как думать быстрее, потому я выбрал второй вариант. Решение оказалось по-наивному простым:

Не рисуй сцену на каждом кадре. Рисуй только когда попросили, или когда знаешь, что она поменялась.

Может, это покажется слишком очевидным сейчас, но это было вовсе не так сначала. Ведь в основном все примеры использования WebGL описывают простой цикл:

function frame() {
    requestAnimationFrame(frame); // Планируем следующий кадр

    renderScene(); // рисуем текущий кадр.
    // Ничего плохого в этом нет, но батарею мы можем так быстро посадить
}

С "консервативным" подходом, мне нужно было вынести requestAnimationFrame() наружу из функции frame():

let frameToken = 0;

function renderFrame() {
    if (!frameToken) frameToken = requestAnimationFrame(frame);
}

function frame() {
    frameToken = 0;
    renderScene();
}

Такой подход позволяет кому угодно затребовать нарисовать следующий кадр. Например, когда пользователь перетащил карту и изменил матрицу преобразования, мы вызываем renderFrame().

Переменная frameToken помогает избежать повторного вызова requestAnimationFrame между кадрами.

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

Текст и линии

WebGL не самый простой в мире API. Особенно сложно в нем работать с текстом и толстыми линиями (у которых ширина больше одного пикселя).

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

С другой стороны, из текста мне нужно было нарисовать только пару меток A и B. А из толстых линий — только путь который соединяет две вершины. Задача вполне по силам для DOM'a.

Как вы помните, наш отрисовщик использует граф сцены. Почему бы не добавить в сцену еще один элемент, задачей которого будет применять текущую трансформацию к… SVG элементу? Этот SVG элемент сделаем прозрачным, и положим его сверху на canvas. Чтобы убрать все события от мышки — ставим ему pointer-events: none;.

Получилось очень быстро и сердито.

Перемещаемся по карте

Мне хотелось сделать так, чтобы навигация была похожа на типичное поведение карты (как в Google Maps, например).

У меня уже была написана библиотека навигации для SVG: anvaka/panzoom. Она поддерживала touch и кинетическое затухание (когда карта продолжает двигаться по инерции). Для того чтобы поддерживать WebGL мне пришлось чуть-чуть подправить библиотеку.

panzoom слушает события от пользователя (mousedown, touchstart, и т.п.), применяет плавные трансформации к матрице преобразования, и потом, вместо того чтобы напрямую работать с SVG, она отдает матрицу "контроллеру". Задача контроллера — применить трансформацию. Контролер может быть для SVG, для DOM или даже мой собственный контроллер, который применяет трансформацию к WebGL сцене.

Как понять что кликнуто?

Мы обсудили как загрузить граф, как его нарисовать, и как двигаться по нему. Но как же понять что было нажато, когда пользователь касается графа? Откуда прокладывать путь и куда?

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

Я использовал квад дерево чтобы проиндексировать точки. После того как дерево создано — скорость поиска ближайшего соседа становится логарифмической.

Кстати, если термин "квад дерево" звучит устрашающе — не стоит огорчаться! На самом деле квад-деревья, очень-очень похожи на обычные двоичные деревья. Их легко усвоить, легко реализовать и легко применять.

В частности, я использовал собственную реализацию, библиотека yaqt, потому что она неприхотлива по памяти для моего формата данных. Существуют лучшие альтернативы, с хорошей документацией и сообществом (например, d3-quadtree).

Ищем путь

Теперь все части на своих местах. У нас есть граф, мы знаем как его нарисовать, знаем что было на нем нажато. Осталось только найти кратчайший путь:

// pathfinder  это объект https://github.com/anvaka/ngraph.path
let path = pathFinder.find(fromId, toId);

Теперь у нас есть и массив вершин, которые лежат на найденном пути.

Заключение

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

Искренне желаю вам добра!
Андрей.