
Данный опус представляет собой размышления на тему разработки приложений по принципам `module federation`
с использованием `React` в качестве UI библиотеки.

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

## Особенности федеративных приложений

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

- Ошибки на раннем этапе проектирования могут стоить больше, чем при монолитном подходе. Самые серьёзные ошибки — ошибки при проектировании публичного API модулей и модели их взаимодействия.
  Такие ошибки приведут к каскаду изменений, которые нужно будет внести в каждый из связанных модулей.

<ClickuxaApp />

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

## Воркфлоу и деплой

Есть 2 репозитория: библиотека компонентов и использующее эту библиотеку компонентов приложение.

Библиотека компонентов точно так же, как и приложение должна быть задеплоена на определённый адрес, доступый приложению в рантайме.

Если приложение разрабатывается с использованием нескольких целей деплоя (например, тестовая и боевая),
хорошей идеей будет и библиотеку разрабатывать с такими же целями деплоя.

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

- переменные окружения, в котором происходит сборка приложения
- специализировання рантайм логика (например, в зависимости от текущего URL, на котором приложение запущено)

Для локальной работы над системой нужно подключить библиотеку средствами `module federation`:

- локальный сервер с библиотекой (`webpack-dev-server`, `serve`)
- удалённый сервер с текущей версией библиотеки.

## Обмен информацией между модулями

Обмен информацией это общение. Обмен информацией должен обладать свойствами:

- получатель умеет интерпретировать любую полученную от отправителя информацию.

Должны ли они знать "смысл" информации? или достаточко соотносить переданную информацию и ответную реакцию.

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

* Главное = каждый запрос должен получать ответ \*

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

## API

### onBoot

Позволяет подключиться ко внутренней системе обмена сообщениями модуля. Предоставляет доступ к `request` функции модуля.



Osnova - набор подходов и библиотек для построения приложений.

Основные принципы:

- Разделение приложения на слабосвязанные модули, общающиеся друг с другом через событийную модель.
-

## События

Типы событий:

- `DataEvent` Событие-данные — передаёт информацию о состоянии данных.

```ts
interface DataEvent<T = any> {
  type: string;
  payload: {
    value: T;
  };
}
```



## Введение

<Aside>
  Предполагается, что читатель знаком с основами алгоритмов и структур данных и может прикинуть на глаз сложность
  алгоритма.
</Aside>

Динамическое программирование (<b>ДП</b>) — это подход к решению проблем, заключающийся в применении стратегии:

1. Разбиение проблемы на подпроблемы.
2. Решение подпроблем.
3. Сборка решений подпроблем в решение исходной проблемы.

## Область применения

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

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

## Критерии выбора ДП в качестве метода решения

Чтобы быть эффективно решаемой методом ДП проблема должна обладать свойствами:

- Optimal substructure - отпимальное решение проблемы может быть построено из оптимального решения подпроблем.
- Overlapping subproblems - для решения подпроблем используются результаты уже решённых подпроблем.
- Acyclic dependencies (?) - решения любых двух подпроблем не могут зависеть друг от друга.

Если эти свойства не выполняются, то задача либо решается быстрее/оптимальнее [жадным алгоритмом](https://en.wikipedia.org/wiki/Greedy_algorithm),
либо не решается методом ДП вовсе.

## Причём тут графы

В конечном итоге ДП — это обход некоторого [DAG](https://en.wikipedia.org/wiki/Directed_acyclic_graph)'a:

- в задачах оптимизации нужно обойти граф по минимальной/максимальной цене.
- в комбинаторных задачах — посчитать количество рёбер/вершин.

## Фреймворк

Чтобы применить к проблеме метод ДП, нужно выполнить 5 "простых" шагов:

1. Определить подпроблемы.
2. Предположить часть решения.
3. Соотнести решения подпроблем друг с другом.
4. Построить алгоритм: сверху-вниз (рекурсия) или снизу-вверх (таблица значений).
5. Убедиться, что исходная проблема решена.

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

Остальная часть решения практически идентичная для всех ДП задач.



## Задача

При разработке серьёзной JavaScript-библиотеки присутствует неминуемый этап непосредственной настройки процесса разработки (Developer Experience) и процесса непрерывной интеграциии и поставки (CI/CD). Работа, выполняемая на этом этапе (далее _этап найстройки_), сводится к выбору платформ, инструментов и библиотек, необходимых для разработки и деплоя. На этап настройки _уходят время и силы_, количество которых необходимо сократить.

## Анализ

Задача сокращения количества ресурсов, затрачиваемых на этапе настройки, является решаемой, потому что требования к выстраеваемой на этом этапе системе являются типовыми для широко спектра бизнес-задач. Стандартными требованиями являются:

- поддержка типизации (TypeScript);
- сборка библиотеки для браузеров и для Node.js;
- возможность разбиения библиотеки на отдельные пакеты и управление ими;
- контроль качества: тесты, линтинг, форматирование кода, в том числе локальный при каждом коммите и на стороне CI/CD;
- CI/CD: деплой библиотеки в реестр пакетов с возможностью использовать приватный реестр;

## Решение

С учётом всех перечисленных требований был собран [репозиторий][template-repo], в котором используются:

- GitHub Packages
- GitHub Actions
- yarn + workspaces
- lerna
- tsdx

Репозиторий можно взять за основу для разработки JavaScript-библиотеки, скачав его, например, при помощи [degit]:

```sh
npx degit https://github.com/Noviel/typescript-library-monorepo-template my-lib
```

После этого останется выполнить несколько шагов по настройке GitHub, которые позволят использовать GitHub Packages, а так же заменить данные в шаблоне на свои. Более подробные инструкции по использованию можно найти в репозитории

[template-repo]: https://github.com/Noviel/typescript-library-monorepo-template
[degit]: https://github.com/Rich-Harris/degit




Данная статья описывает способ внедрения WebAssembly, выполняющегося в веб-воркере, в Next.js приложение.

<Aside>
  Предполагается, что читатель знаком с базовыми принципами этих технологий и уже имеет готовый WebAssembly модуль с
  обвязкой, полученный, например, при помощи <a href="https://rustwasm.github.io/docs/wasm-pack/">wasm-pack</a>.
</Aside>

## Настройка Next.js

[worker-loader](https://github.com/webpack-contrib/worker-loader) - позволяет подключать в приложение файл с кодом веб-воркера при помощи стандартного импорта.

Следующие моменты при настройке `worker-loader` являются ключевыми:

- `publicPath` — должен быть **правильным** URL-ом, т.е. вида `https://mysite/_next/`, потому как `import` в веб-воркере трансформируется в `importScript`, требующий корректный URL.
- `chunkFilename` и `filename` должны иметь корректный префикс, чтобы комилируемые файлы сохранялись в `static` директорию Next.js.
- нужно включить в цепочку лоадеров стандартный Next.js лоадер для `JavaScript/TypeScript`.

Пример `next.config.js` с учётом вышеперечисленных моментов:

```ts
// next.config.js

const workerLoader = require('worker-loader');

module.exports = {
  webpack(config = {}, context) {
    const { isServer, defaultLoaders, config: nextConfig } = context;

    const publicPrefix = process.env.NEXT_PUBLIC_URL || nextConfig.assetPrefix;
    const publicPath = (publicPrefix ? `${publicPrefix}/` : '') + '_next/';

    const outputPrefix = (isServer ? '../' : '') + 'static/worker/';

    const workerLoaderOptions = {
      publicPath,
      chunkFilename: outputPrefix + 'chunks/[id].[contenthash].worker.js',
      filename: outputPrefix + '[name].[contenthash].worker.js',
    };

    config.modules.push({
      test: /\.worker\.(js|ts)$/,
      use: [
        {
          loader: 'worker-loader',
          options: workerLoaderOptions,
        },
        (defaultLoader: defaultLoaders.babel),
      ],
    });

    return config;
  },
};
```

В конфигурации используется `NEXT_PUBLIC_URL` переменная окружения, которая должна содержать URL текущего деплоя.

Имена веб-воркер файлов должны оканчиваться на `.worker.ts` или `.worker.js`.

## Внутри веб-воркера

```ts
// heavy-calculation.worker.ts

self.addEventLinstener('message', async ({ data }) => {
  const { payload, command } = data;

  if (command !== 'calculate') {
    return;
  }

  // (1)
  const { calculate } = await import('./wasm/heavy-calculation');

  const result = calculate(payload);

  self.postMessage({
    result,
  });
});
```

<Aside>
  Файл <i>./wasm/heavy-calculation</i> является обвязкой, которая предоставляет описание типов и экспортирует сами
  функции из wasm-файл. По сути при подключении обвязки — подключается wasm-файл.
</Aside>

Веб-воркер подписывается на сообщения, и в случае, если данные сообщения содержат поле `command` со значением `calculate`,
вызывает WebAssembly функцию и отправляет сообщение с результатом вычисления.

Важным моментов является динамический импорт `(1)` wasm-файла. Стандартным решением было бы использовать статический импорт в начале файла, но данный подход приводит к ошибке — Next.js не может включить wasm-файл при серверном рендеринге или при генерации статической страницы. В то время как динамический импорт будет выполнен только в браузере.

## Подключение веб-воркера

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

```ts
// HeavyCalculator.tsx
type Calculate = (n: number) => number;
type WorkerMessageListener = (ev: WorkerEventMap['message']) => void;

function HeavyCalculator() {
  const [result, setResult] = useState<number | null>(null);
  const [inputValue, setInputValue] = useState<stirng>();

  const worker = useRef<Worker | null>(null);
  const calculate = useRef<Calculate | null>(null);
  const listener = useRef<Listener | null>(null);

  useEffect(() => {
    if (calculate.current) {
      return;
    }

    // (1)
    import('./heavy-calculation.worker').then(({ default: HeavyCalculationWorker }) => {
      // (2)
      worker.current = new HeavyCalculationWorker();

      // (3)
      calculate.current = n => {
        worker.postMessage({
          command: 'calculate',
          payload: inputValue,
        });
      };

      // (4)
      listener.current = message => {
        if (mesage.data && typeof mesage.data.result !== 'undefined') {
          setResult(message.data.result);
        }
      };

      worker.current.addEventListener('message', listener);
    });

    () => {
      if (worker.current) {
        worker.current.removeEventListener('message', listener);
      }
    };
  }, []);

  function onCalculateClick() {
    if (calculate.current) {
      calculate.current(parseInt(inputValue, 10));
    }
  }

  return (
    <div>
      <label htmlFor="heavy-calculator-input">Input data for heavy calculation</label>
      <input
        id="heavy-calculator-input"
        value={inputValue}
        onChange={e => {
          setInputValue(e.target.value);
        }}
      ></input>
      <button onClick={onCalculateClick}>calculate</button>
      <div>{result}</div>
    </div>
  );
}
```

`(1)` — динамически импортируем веб-воркер на клиенте (попытка использовать статический импорт в начале файла приведёт к ошибке при серверном рендеринге).

`(2)` — инстанциируем веб-воркер и сохраняем его в ref-переменную, чтобы он был доступен вне колбэка импорта.

`(3)` — создаём функцию `calculate`, которая отправляет сообщение c необходимыми данными веб-воркеру, созданному на этапе `(2)`.

`(4)` — подписываемся на события, приходящие от веб-воркера, у которых есть поле `data.result`.

## Заключение

Данная реализация позволяет подключать на любую Next.js страницу React компонент, взаимодействующий с WebAssembly кодом, выполняющимся в веб-воркере. Как бонус — при создании нескольких экземпляров компонента для каждого из них будет инстанциирован свой веб-воркер, что позволяет, например, запустить несколько параллельных потоков вычислений.



## Задача

### Исходные данные

- Firebase Functions в качестве облачного serverless решения
- GitHub в качестве репозитория кода
- VS Code в качестве IDE

### Необходимо

- Настроить локальное рабочее окружение:
  - Firebase Functions требуют определённую версию Node.js (на момент написания статьи — 10), что является проблемой при локальной разработке нескольких проектов, которые используют более поздние версии Node.js. Необходимо обеспечить требуемой версией Node.js каждый проект без глобального изменения версии (например, через `nvm`).
- Настроить CI/CD процесс

## Настройка локального рабочего окружения

[Visual Studio Code Remote Container](https://code.visualstudio.com/docs/remote/containers) позволяют использовать Docker контейнеры как полнофункциональую среду для разработки. Контейнеры позволяют создавать изолированное окружение для отдельно взятого проекта, что в том числе позволяет использовать для каждого проекта необходимую ему версию Node.js.

1. Создать `.devcontainer/Dockerfile` с указанием версии Node.js

```yml
# .devcontainer/Dockerfile
FROM: node:10
```

3. Создать `.devcontainer/devcontainer.json`

```json
/* .devcontainer/devcontainer.json */
{
  "name": "Node.js 10 Container",
  "dockerFile": "Dockerfile",
  "settings": {
    "terminal.integrated.shell.linux": null
  }
}
```

2. [Предоставить доступ контейнеру к git](https://code.visualstudio.com/docs/remote/containers#_sharing-git-credentials-with-your-container)

3. Открыть папку с проектом в Remote Container: `F1` -> `Remote Container: Open Folder in Container`
4. Выбрать `Clone Volume` для более быстрого доступа к файлам

## Настройка CI/CD процеcса

Для деплоя Firebase Functions используются GitHub Actions.
GitHub Actions нужно предоставить доступ к Firebase Functions:

1. Получить Firebase токен — `firebase login:ci` на машине с браузером
2. Добавить полученный токен в гитхаб — Settings -> Secrets -> New secret
3. Использовать добавленный токен в GitHub Action:

```yml
# .github/workflows/deploy.yml
name: Deploy Firebase

on:
  push:
    branches: [master]

jobs:
  build:
    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [10.x]

    steps:
      - uses: actions/checkout@v2

      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v1

      - run: npm i -g firebase-tools

      - name: Install dependencies
        run: yarn install --production --pure-lockfile --non-interactive

      - name: Deploy
        run: |
          firebase deploy --token {{secrets.$FIREBASE_TOKEN}}

        env:
          CI: true
          FIREBASE_TOKEN: ${{ secrets.FIREBASE_TOKEN }}
```

Созданный workflow обеспечивает запуск `Deploy Firebase` каждый раз при пуше в `master`.

## Заключение

Использование связки `Firebase Functions` + `Visual Studio Code Remote Containers` + `GitHub` позволяет добиться гладкого процесса разработки и деплоя облачных функций.



Технические детали разработки сайта [snov.digital](https://snov.digital)

## Техническая задача

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

Типы контента

- записи блога/статьи с медиа и интерактивными вставками
- новости
- произвольный контент

## Необходимые свойства сайта

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

## Выбор платформы и основных инструментов

Платформа: Веб

- охват аудитории
- необходимые для разработки и поддержки ресурсы
- возможности платформы

Язык: TypeScript

- самодокументирование
- стабильность при росте кодовой базы
- безопасный рефакторинг

Фреймворк: NextJS

- **возможность генерации статического контента**
- возможность использовать полноценный SSR при необходимости
- поддерживаемый, хорошо документированный, популярный фреймворк

Платорма разработки: GitHub

- удобство использование
- GitHub Actions
- наличие интеграций

Инфраструктура: Vercel

- возможность хостить статический контент
- полная поддержка приложений на NextJS
- интеграция с GitHub

Перманентное хранилище: Firebase Firestore

- адекватные бесплатные лимиты использования
- поддержка динамических реактивных данных
- интеграция с Firebase Authentication, Firebase Functions

## Реализация

Сайт представляет собой набор статических страниц с встроенными статическими данными.

### Статические данные

Статические данные — данные, которые являются перманентными в контексте рантайма приложения и являются одинаковыми для всех экземпляров приложения.
Эти данные изменяются только при выпуске новой версии приложения. К такому виду данных относятся:

- набор цветов светлой/тёмной темы
- метаданные приложения (версия, хэш коммита)
- локализованные сообщения
- посты блога
- страница «Об авторе»

#### Хранилище

Статические данные должны постоянно храниться вне запущенного приложения и могут подвергаться изменениям извне приложения. Варианты хранилищ:

1. непосредственный код приложения (inline)
2. локальная файловая системы репозитория приложения
3. сторонний сервис (база данных, например, Firebase Firestore)

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

Код приложения — самый простой вариант, в котором зачастую и зарождается новый тип статических данных. Вариант со сторонним сервисом является самым универсальным, но и самым дорогим.

#### Доступ к хранилищу

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

Но ключевое свойство статических данных (перманентность и идентичность для всех экземпляров приложения) позволяет отвязать количество чтений из хранилища от количества запросов сайта.

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

Таким образом данные будут прочитаны только 1 (**один**) раз во время выпуска новой версии приложения (обновлении контента приложения). Такие свойства хранилища статических данных позволяют использовать внешнюю базу данных с минимальным потреблением её ресурсов, а следовательно финансовыми затратами. Из процесса получения данных при запросе клиентом полностью исчезает взаимодействие с хранилищем: даныне были запрошены и получены заранее и встроены в код приложения.

Для доступа к хранилищу при локальной разработки целесообразно использовать стратегию с кэшированием:

1. Инвалидация кэша при начале разработки
2. Загрузка данных из хранилища
3. Кэширование данных
4. Чтение данных из кэша при последующих запросах, переход к `п. 2`, если запрашиваемых данных нет в кэше.
5. Внедрение данных в приложение функциональностью NextJS (`getInitialProps`, `getStaticProps`)

Процесс получения данных на этапе выпуска новой версии приложения:

1. Чтение данных из Firebase Firestore
2. Кэширование данных
3. Внедрение данных в приложение функциональностью NextJS (`getInitialProps`, `getStaticProps`)

Кэш может храниться локально в файловой системе.

#### Типы статических данных

Статические данные могут быть как **глобальными** для всего приложения, так и уникальными для каждой
страницы (далее — **страничные** данные).

#### Глобальные статические данные

Предоставление доступа к глобальным данным реализуется через расширение стандартных объектов NextJS:
`NextApp` в `pages/_app.tsx` и `NextDocument` в `pages/_document.tsx`.

1. Данные запрашиваются при помощи любого API в `Document.getInitialProps`:

```tsx
Document.getInitialProps = async () => {
  const globalData = await fetchGlobalDataFromAnyAPI();
  return {
    globalData,
  };
};
```

2. Внедряются в HTML в `Document.render`

```tsx
const GLOBAL_DATA_KEY = 'GLOBAL_DATA';

type Props<T> = {
  globalData: T;
};

class Document extends NextDocument<Props> {
  render() {
    const stringifiedGlobalData = JSON.stringify(this.props.globalData);
    return (
      <Html>
        <Head>{'...'}</Head>
        <body>
          <script dangerouslySetInnerHTML={{ __html: `window.${GLOBAL_DATA_KEY}=${stringifiedGlobalData}` }}></script>
          <Main />
          <NextScript />
        </body>
      </Html>
    );
  }
}
```

После этого этапа глобальные данные уже становятся доступны в приложении через `window[GLOBAL_DATA_KEY]`. Но такая форма
доступа имеет проблемы с раскрытием деталей реализации.

3. Создание провайдера и хука доступа к данным:

```tsx
export function createGlobalDataContext<D>(initialData: D) {
  const ctx = createContextReact(initialData);
  const useCtx = () => useContext(ctx);

  return {
    Provider: ctx.Provider,
    useContext: useCtx,
  };
}
```

4. Создание hydrate:

hydrate предназначена для того, чтобы получить актуальные данные для приложения в зависимости от среды
(браузер или node.js): мы гарантируем, что данные находятся в `window[GLOBAL_DATA_KEY]`,если код выполняется в браузере;
если код выполняется в node.js, мы имеем прямой доступ к `globalData` через `props`, пришедшие в `NextApp`.

```tsx
function hydrate<D>(props: { globalData: D }) {
  if (typeof window !== 'undefined') {
    return (window as any)[GLOBAL_DATA_KEY];
  } else {
    return props.globalData;
  }
}
```

5. Объявление типа GlobalData, создание провайдера и хука доступа:

```tsx
export type GlobalData = any;

export const globalDataContext = createGlobalDataContext<GlobalData>({} as GlobalData);
export const GlobalDataProvider = globalDataContext.Provider;
export const useGlobalData = globalDataContext.useContext;
```

6. Использование провайдера и hydrate в `NextApp`:

```tsx
type Props = {
  globalData: GlobalData;
};

export default class App extends NextApp<Props> {
  // globalData будет гарантированно содержать данные после выполнения конструктора
  globalData!: GlobalData;

  constructor(props: Props) {
    super(props);

    this.globalData = hydrate(props);
  }

  render() {
    const { Component, pageProps } = this.props;

    return (
      <GlobalDataProvider value={this.globalData}>
        <Component {...pageProps} />
      </GlobalDataProvider>
    );
  }
}
```

7. Получение доступа к данным на любой странице:

```tsx
export const JustAnotherPage = () => {
  const { someData } = useGlobalData();

  return <div>{someData}</div>;
};
```

В результате любой компонент, используемый в приложении может полуить доступ к глобальным данным.

#### Страничные статические данные

### Pierrot

Pierrot — это CMS-ish библиотека для Next.js, предоставляющая просто интерфейс для доступа к хранилищам данным и для их внедрения в приложение. Код в [Глобальные статические данные](#anchors-in-markdown)

### Интернализация

Локализованные страницы сайта имеют URL формата `snov.digital/[[language]]/[[page]]`.

Сообщения хранится как key-value пары в виде полей объекта [[language]].

Список сообщений хранится в Firebase Firestore и внедряется в приложение при помощи Pierrot.

#### Добавление нового локализованного сообщения

### Визуальные темы

Темизируемые примитивы:

- главная навигационная панель
  - ссылки на разделы сайта
- главная страница
  - заголовок сайта
  - описание сайта
- футер
  - текст футера

При этом каждый из примитивов может быть отображён поразному для разных устройств (разрешения экрана, плотности пикселей и т.д.)

### Панель управления

Подход со статическими данными, хранящимися в Firestore и внедряемыми на этапе сборки, позволяет реализовать панель управления с функциональностью:

- изменение статических данных
- сборка новой версии приложения с изменёнными статическими данными

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



// import bojackShocked from './images/shocked.jpg';
// import bojackWhenSheMarriesDog from './images/when-she-marries-dog.png';

Настроения BoJack Horseman доступны в виде:

Telegram стикеры: [Добавить](https://t.me/addstickers/AwesomeBoJack)

"Настроение — шокированный BoJack" width="50%" height="auto"
"Настроение — когда она выходит замуж за пса" width="50%" height="auto"



# Записки по машинному обучению на основе RL

RL - одно из фундаментальных направлений ML, наряду с Supervised Learning и Unsupervised Learning.

## Области применения RL

<img src="https://i.imgur.com/JHxN8ms.png" width="100%" height="auto" />

### Компьютерные науки

### Инженерия

Optimal control

### Математика

### Экономика

### Психология

### Науки о нервной системе

Reward system

## Характеристика

- Нет надзирателя, только reward сигнал.
- Обратная связь асинхронная, а не мгновенная.
- Время имеет значение (данные приходят/изменяются последовательно)
- Действия агента воздействуют на последующие данные, которые он получает.
- Агент принимает решения, основанные на текущем состоянии системы.

### Примеры

- Управление лопастями вертолёта
- Игра в Backgammon
- Управление инвестициями
- Управление энергостанцией
- Управление гуманоидным роботом
- Прохождение Atari игр

### Реализация

#### Rewards

R(t) - скалярный сигнал ответной связи системы для каждого момента времени t.
Характеризует, как хорошо агент выполняет свою задачу в конкретный момент.
Цель агента — максимизировать sum(R(t)).

Агент последовательно принимает решения (выбирает текущее действие) для максимизации общей суммы наград в будущем.

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

#### Agent and Environment

f(O(t), R(t)) => a(t)

#### History and state

H(t) = A1O1R1, ..., AtOtRt

Окружение предоставляет агенту observations и rewards.

S(t) = f(H(t))

State

Environment state - private environment's representation.
Все данные, используемые средой для выбора следующей пары Observation+Reward.
Обычно не видна агенту.

Agent state - agent's internal representation.
Используемая агентом информация для принятия решения.

Markov State

State является Марковской тогда и только тогда, когда вероятность следующего стейта, в зависимости от текущего
такая же, как вероятность следующего стейта, в зависимости от всех предыдущих.

Environemnt State = Markov
History = Markov

Perfect case

O(t) = Sa(t) = Se(t)

Partial Observable Environments

Sa(t) != Se(t)

### RL Engine

Components:

Policy: agent's behaviour function.

Map from state to action

Value function: how good is each state and/or action.

Prediction of expected future reward.
Depends on the Policy.

Model: agent's representation of environment
Transitions: predicts the next state
Rewards: predicts next reward

## RL Agents categories

### Model free

#### Value Based

Value Function
No Policy (it is implicit)

#### Policy Based

Policy
No value function

#### Actor Critic

Policy
Value function

### Model based

Policy and/or Value Function
Model

## RL Fundamental problems

Learning:

The environment is initially unknown
The agent interacts with the environment => improved policies

Planing:

model of the environment is known
agent performs computations with model => improved policies

## Exploration and exploitation

trial-and-error => better Policy

Exploration = find more about enviroment, get less reward
Exploitation = exploit known information maximizing reward
Need to balance it.

## Prediction and control

Prediction: predict a future with given policy
Control: optimise the future - find the best policy

## Markov Decision Process

MDP описывает среду для RL.
Среда аьсолютно обозрима.

Markov Chain Transition Matrix - матрица вероятности перехода из одного состояния цепи в другое.

Markov Reward - Добавляет в матрицу маркова R - мгновенную награду за нахождение в текущем стейте.

Discount factor [0;1] - применяется для рассчета R в бесконечном будущем, чтобы уменьшать влияние
очень отдалённых в будущее наград.

R(k+1) = DF^k\*R

### Value function

long-term value of a state

v = f(s)

Bellman Equation for MRP

value function = immediate reward R(t+1) + discounted value of successor state DF\*v(S(t+1))

## Ресурсы

https://mitpress.mit.edu/books/machine-learning

https://www.amazon.com/Hands-Machine-Learning-Scikit-Learn-TensorFlow/dp/1491962291


Статьи о разработке и программировании, мысли о жизни, вселенной и всём таком

Блог

Автор сайта, Александр, занимается Web-разработкой. С ним всегда можно {{contact.action}} по вопросам сотрудничества.