ivan-igorevich
/
gb-java-devel
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Ilnar comments in 1-2 abstract

This commit is contained in:
Ivan I. Ovchinnikov 2022-09-01 21:38:05 +03:00
parent bd03b9d5a1
commit fcb7fda755
2 changed files with 308 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
jtc1-2a.tex
View File

@ -27,9 +27,12 @@
\end{itemize}
\subsection{Мотивация и схема (зачем это нужно и как это работает)}
Сборщие проекта - это сложный инструментарий, который может скрывать обширный объем работы, который при ручном подходе требует значительных затрат и может оказаться весьма утомительным.
Позвляют не привязываться к конкретным IDE и интерфейсу среды разработки. Имеют текстовое управление, что часто ускоряет процесс работы с ними на пред-продакшн серверах, где часто терминальный интерфейс.
% Комментатор_Ильнар. Вот тут ощущение что мы недостаточно ребятам объяснили что реальный проект - это не только свой код, который мы написали в IDE, но и большое количество всего остального, что мы при этом используем - библиотеки, фреймворки и т.п. Более того, здесь ребята могут ничего не знать про jar файлы, в которые запаковывается проект. Я бы наверное (возможно в 1-й лекции) рассказал про jar, сделал "исполняемый файл" который можно скормить JRE, а потом на этой лекции рассказал что руками собирать все нужные библиотеки, указывать их в класспаф и т.п. - это дико неудобно, эту работу можно всю автоматизировать с помощью сборщиков, а сборщики - это вот то про что мы тут собственно и рассказываешь)
Сборщики проекта - это сложный инструментарий, который может скрывать обширный объём работы, который при ручном подходе требует значительных затрат и может оказаться весьма утомительным.
Они позволяют не привязываться к конкретным IDE и интерфейсу среды разработки. Имеют текстовое управление, что часто ускоряет процесс работы с ними на пред-продакшн серверах, где часто терминальный интерфейс.
\begin{frm}
Система сборки это программа, которая собирает другие программы. На вход система сборки получает исходный код, написанный разработчиком, а на выход выдаёт программу, которую уже можно запустить. Отличается от компилятора тем, что вызывает его при своей работе, а компилятор о системе сборки ничего не знает, то есть является инструментом более широкого спектра.
@ -50,11 +53,16 @@
\begin{enumerate}
\item Конфигурации - собственная конфигурация, где хранятся «личные» настройки системы. Например, такие как информация о месте установки или окружении, информация о репозиториях и прочее;
\item Конфигурация модуля, где описывается место расположения проекта, его зависимости и задачи, которые требуется выполнять для проекта;
% Комментатор_Ильнар. Слово зависимости мы еще не ввели. студенты его могли не слышать. Надо как раз как в прошлом комментарии показать что наш проект может использовать сторонние библиотеки. При этом мы легко можем скачать и положить их рядом на своем компе и прописать в класспаф при javac и даже некоторую автоматизацию сделать. Но, если мы хотим это разместить где-то в другом месте (деплой на сервере), то это становится уже далеко не так удобно. Библиотеки (и все остальное) с которыми связан наш проект (читай от которых он зависит) называются зависимостями. И одна из задач, которую решают сборщики проектов - это как раз таки работа с этими зависимостями.
\item Парсеры конфигураций - парсер способный «прочитать» конфигурацию самой системы, для её настройки соответствующим образом;
\item Парсер конфигурации модуля, где некоторыми «понятными человеку» терминами описываются задачи для системы сборки;
\item Сама система — некоторая утилита + скрипт для её запуска в вашей ОС, которая после чтения всех конфигураций начнет выполнять тот или иной алгоритм, необходимый для реализации запущенной задачи;
\item Система плагинов — дополнительные подключаемые надстройки для системы, в которых описаны алгоритмы реализации типовых задач;
\item Локальный репозиторий — репозиторий (некоторое структурированное хранилище некоторых данных), расположенный на локальной машине, для кэширования запрашиваемых файлов на удаленных репозиториях.
% Комментатор_Ильнар. Я бы тут простыми словами еще раз это сказал. Локальный репозиторий - это то место на вашем компьютере куда будут скачаны зависимости для вашего проекта. Хотя это наверное больше для сценария, но немного упростил бы все равно.
\end{enumerate}
Для языка Java основных систем сборок три:
@ -62,6 +70,7 @@
\item Иногда можно встретить Ant в сочетании с инструментом по управлению зависимостями Ivy, в чистом виде Ant почти никогда не применялся;
\item Самый популярный инструмент - это Maven, используется для JavaEE и приложений с использованием Spring Framework;
\item Gradle основной инструмент в мобильной разработке, часто Groovy/Kotlin описания сборки оказываются удобнее XML;
% Комментатор_Ильнар. Тут предполагается что читатель знает причем тут XML, но это может быть не так. Можно добавить XML, который используется в Maven или что-то типа того. Или в блок про Мавен написать что в нем описание сборки в виде XML файла дается.
\end{itemize}
Экзотическая Bazel. Её отличает полная кроссплатформенность и кросстехнологичность, что делает её особенно привлекательной для микросервисных проектах, использующих несколько языков программирования.
@ -75,6 +84,10 @@
Скачивание и установка, ant для Linux-подобных ОС выполняется привычной командой установки в вашем пакетном менеджере, вроде sudo apt install ant, а для Windows можно перейти на сайте ant.apache.org и скачать архив, распаковав его и прописав соответствующий путь в переменные среды. Проверить версию можно командой ant -version
% Комментатор_Ильнар. Команды типа sudo apt-install ant и т.п. давайте выделять как-то в тексте. наверное тут можно это красиво сделать
% Комментатор_Ильнар. теперь к тому что ниже. нужен некоторый переход. Иначе мы с ant -version перешли на некоторую магию. Надо пояснить что мы сейчас будем делать.
% --- слайд
\begin{lstlisting}[language=XML,style=ASMStyle]
<?xml version="1.0"?>
@ -86,7 +99,8 @@
\end{lstlisting}
% --- конец слайда
Теперь можно написать простой сценарий HelloWorld: в нём мы указываем версию хмл, без этого никакой хмл никогда не работает. затем говорим, что наш проект называется приветмир, а собирать по умолчанию для этого проекта надо таргет хелло. далее в проекте идут описания таргетов, в нашем случае таргет будет один, он будет носить имя хелло, а в рамках таргета нужно будет вывести в терминал приветствие миру.
Теперь можно написать простой сценарий HelloWorld: в нём мы указываем версию XML, без этого никакой XML никогда не работает. затем говорим, что наш проект называется "привет мир", а собирать по умолчанию для этого проекта надо таргет hello. далее в проекте идут описания таргетов, в нашем случае таргет будет один, он будет носить имя хелло, а в рамках таргета нужно будет вывести в терминал приветствие миру.
% Комментатор_Ильнар. к тексту выше. надо все же чуть более явно пояснить отдельные детали. Например, когда мы пишем что по умолчанию будет выполняться таргет hello, то можно в скобках сделать пояснение (см. default="hello") и так по всем пунктам.
% --- слайд
\begin{lstlisting}[language=C,style=CCodeStyle]
@ -98,6 +112,8 @@ ant
Затем, нужно создать подкаталог hello и сохранить туда файл с именем build.xml, который содержит сценарий. Далее надо перейти в каталог и вызвать ant. Полный перечень команд:
% Комментатор_Ильнар. ощущение что этот слайд находится чуть выше. После этого слайда также вроде текст сбит, должен находиться до него
% --- слайд
\begin{verbatim}
Buildfile: /home/hello/build.xml
@ -108,7 +124,7 @@ BUILD SUCCESSFULL
\end{verbatim}
% --- конец слайда
В результате выполнения которых получим следующий вывод. Что именно произошло? система сборки нашла файл сценария с именем по умолчанию, по удачному стечению обстоятельств система ищет файл с именем build.хмл и выполнила цель указанную по умолчанию, здесь уже никаких удачных стечений обстоятельств, мы явно указали, что нужно по умолчанию выполнять таргет с именем hello. Чтобы не запутаться в более сложном проекте, мы указали имя проекта, с помощью атрибута name.
В результате выполнения которых получим следующий вывод. Что именно произошло? система сборки нашла файл сценария с именем по умолчанию, по удачному стечению обстоятельств система ищет файл с именем build.xml и выполнила цель указанную по умолчанию, здесь уже никаких удачных стечений обстоятельств, мы явно указали, что нужно по умолчанию выполнять таргет с именем hello. Чтобы не запутаться в более сложном проекте, мы указали имя проекта, с помощью атрибута name.
% --- слайд
\begin{lstlisting}[language=XML,style=ASMStyle]

288
scenarios/jtc1-2b.tex Normal file
View File

@ -0,0 +1,288 @@
\documentclass[russian]{beamer}
\usepackage{multicol}
\usepackage[russian]{babel}
\usepackage{fontspec}
\input{../settings/fancy-listings-preamble}
\usepackage{forest}
\makeatletter
\def\beamer@framenotesbegin{% at beginning of slide
\usebeamercolor[fg]{normal text}
\gdef\beamer@noteitems{}%
\gdef\beamer@notes{}%
}
\makeatother
\newcommand{\code}[1]{\small{\texttt{\detokenize{#1}}}\normalsize}
\usetheme{Madrid}
\usecolortheme{seahorse}
\setsansfont{IBM Plex Sans}
\title{Управление проектом: сборщики проектов}
\author{Иван Игоревич Овчинников}
\institute[GB: Java]{GeekBrains. Java Core.}
\date{2022}
\begin{document}
\setbeamertemplate{enumerate items}[circle]
\setbeamertemplate{note page}[plain]
\setbeameroption{show notes}
\frame{\titlepage}
\note{Управление проектом. Как много в этих звуках для джава-разработчика слилось. Здравствуйте.}
\begin{frame}
\frametitle{В предыдущих сериях...}
\end{frame}
\note{
На прошлом уроке мы рассмотрели:
\begin{itemize}
\item краткую историю и причины возникновения языка;
\item что скачать, и как выбирать инструментарий, хотя чаще всего инструментарий выбирает вас, а не вы его;
\item какие шестерёнки крутятся внутри и как примерно всё это работает;
\item структуру простого и обычного проекта;
\item стандартную утилиту для создания документации;
\item сторонние инструменты автоматизации сборки, экзотический мейк и очень современный докер.
\end{itemize}
}
\begin{frame}
\frametitle{На этом уроке}
\end{frame}
\note{
поговорим о том, чем же люди пользуются, если мейк экзотический, а докер был с нами не всегда. для этого будет коротко рассмотрена мотивация создания и использования специализированных сборщиков проектов, какой эволюционный путь прошли специализированные сборщики проектов, какие новые понятия появились в программировании на языке джава при их использовании. Рассмотрим два самых популярных на сегодняшний день сборщика и один экзотический, но достаточно быстро набирающий обороты. Поймём какой путь проделывает чужая библиотека, чтобы попасть в наш проект и научимся публиковать собственный код, делая тем самым вклад в сообщество.
}
\begin{frame}
\frametitle{Мотивация}
\end{frame}
\note{
Итак, зачем собирать проект без IDE, почему нужно использовать специальные инструменты и что такое система сборки?
Научившись выполнять компиляцию и запуск с использованием большого количества ключей, можно приступить к изучению сложного инструментария, который в свою очередь может скрывать очень обширный объем работы, который при ручном подходе требует значительных затрат и может оказаться весьма утомительным. Можно было бы задать вопрос: "Зачем знать команды, если в IDE всё есть?". Здесь есть несколько нюансов:
}
\begin{frame}
\frametitle{Мотивация}
\end{frame}
\note{
Как упоминалось на прошлом уроке, существует огромное количество IDE, которые отличаются расположением управляющих кнопок и в принципе своим внешним видом. Если в проекте несколько участников, они все должны использовать одну и ту же IDE, чтобы не запутаться и иметь возможность синхронизировать настройки при каждом изменении. То есть, можно запускать приложения в IDE, которую нужно будет поставить на все ПК, разложить исходные коды по нужным папкам, установить все требуемые библиотеки и т.д.; Есть очень секретная информация о том, что не все программисты в команде (даже очень маленькой) одинаково сильно любят одинаковые наборы инструментов.
}
\begin{frame}
\frametitle{Мотивация}
\end{frame}
\note{
У сред разработки постоянно меняется интерфейс, часто даже с каждым обновлением. Помимо этого, часто оказывается, что мышкой в кучу разных диалогов долго и неудобно, поскольку основной инструмент программиста это всё-таки клавиатура;
К тому же часто бывает нужно пересобрать приложение после незначительной правки прямо на предпродакшн-сервере, а там вовсе не подключена мышка, поэтому терминальный интерфейс сборщика - это спасение.
}
\newpage
\note{
Уметь собирать код без среды разработки — суровая необходимость. Настолько суровая и важная, что для решения этой задачи существует особый класс программного обеспечения, называемого системами сборки.
}
\begin{frame}
\frametitle{Мотивация}
\end{frame}
\note{
Система сборки это программа, которая собирает другие программы. На вход система сборки получает исходный код, написанный разработчиком, а на выход выдаёт программу, которую уже можно запустить. Отличается она от компилятора тем, что вызывает его при своей работе, а компилятор о системе сборке и её существовании ничего не знает.
Если чуть конкретнее, то сборка, помимо компиляции, содержит в себе ещё целый спектр задач, для решения которых компилятор не предусмотрен. Например, первое, что приходит в голову
}
\newpage
\note{
\begin{itemize}
\item загрузить зависимые библиотеки для вашего проекта из репозитория, возможно даже из интернета;
\item скомпилировать классы модуля или всего проекта как вместе, так и по отдельности;
\item сгенерировать дополнительные файлы: SQL-скрипты, XML-конфиги и т.п.;
\item удалять/создавать директории и копировать в них указанные файлы;
\item упаковка скомпилированных классов проекта в архивы различных форматов: zip, rar, rpm, jar, ear, war и др.;
\item компиляция и запуск модульных тестов (unit-test) вашего проекта с результатами выполнения тестов и расчетом процента покрытия;
\item развёртывание (deploy) файлов проекта на удаленный сервер;
\item генерация документации и отчетов.
\end{itemize}
}
\begin{frame}
\frametitle{Мотивация}
\end{frame}
\note{
В конце концов они могут даже вообще код не компилировать, но делать автоматическую рутинную работу: генерация, архивация, операции с файлами, установка на сервер — что позволяет разработчикам эффективнее тратить своё не самое дешёвое для работодателя время.
}
\begin{frame}
\frametitle{Мотивация}
\end{frame}
\note{
Также, стоит упомянуть, что системы сборок имеют схожую верхнеуровневую архитектуру, которая сводится к следующему:
\begin{enumerate}
\item Конфигурации: собственная и модульная. Там хранятся настройки системы вроде места установки и адресов репозиториев, в модульной же информация о проекте, зависимостях и задачах;
\item Парсеры конфигураций как системный для чтения конфигурации системы и её настройки, так и модульный, преобразующий человекочитаемые задачи в исполняемые;
\item Сама система — некоторая утилита + скрипт для её запуска в вашей ОС, которая после чтения всех конфигураций начнет выполнять тот или иной алгоритм, необходимый для реализации запущенной задачи;
\end{enumerate}
}
\newpage
\note{
\begin{enumerate}
\item Система плагинов — дополнительные подключаемые надстройки для системы, в которых описаны алгоритмы реализации типовых задач;
\item Локальный репозиторий — репозиторий (некоторое структурированное хранилище некоторых данных), расположенный на локальной машине, для кэширования запрашиваемых файлов на удаленных репозиториях.
\end{enumerate}
}
\begin{frame}
\frametitle{Мотивация}
\end{frame}
\note{
Для Java систем сборок, по большому счёту, три:
\begin{itemize}
\item Ant уже можно увидеть только в очень старых проектах, а в чистом видн, наверное, и вовсе не найти. Иногда можно встретить Ant в сочетании с инструментом по управлению зависимостями Ivy;
\item Пожалуй, самый популярный инструмент - это Maven, им собирают не только спринг приложения, но и весь энтерпрайз, поэтому я скорее всего не ошибусь, сказав, что он заниимает процентов 70 рынка джава приложений;
\item Gradle стремительно завоёвывает рынок, плотно закрепившись в мобильной разработке, андроид студия собирает свои проекты гредлом, да и в остальных проектах люди чаще находят груви и котлин более удобными, чем декларативный хмл;
\end{itemize}
}
\begin{frame}
\frametitle{Мотивация}
\end{frame}
\note{
Пожалуй неправильно было бы не упомянуть не совсем стандартную для Java систему сборки Bazel. Её отличает полная кроссплатформенность и кросстехнологичность, что делает её особенно привлекательной для микросервисных проектах, использующих несколько языков программирования. Получается забавно, ант уже почти не используется и сходит на нет, базель возможно наберёт обороты, а инструментов всё равно останется три. О нём мы поговорим в самом конце.
}
\begin{frame}
\frametitle{С чего всё начиналось (Ant, Ivy)}
\end{frame}
\note{
Первым специализированным инструментом автоматизации задач для языка Java появился Ant. По сути, это аналог make-файла, то есть набор скриптов (которые называются тасками, от английского таск - задача, задание). В отличие от make, утилита Ant имеет только одну зависимость — JRE. Ещё одним важным отличием от мейка является отказ от использования команд операционной системы. Всё что пишется в ант пишется на XML, что обеспечивает переносимость сценариев между платформами.
}
\begin{frame}
\frametitle{С чего всё начиналось (Ant, Ivy)}
\end{frame}
\note{
Управление процессом сборки как только что было сказано, происходит посредством XML-сценария, также называемого Build-файлом. В первую очередь этот файл содержит определение проекта, состоящего из отдельных целей (таргетов, с этим понятием мы познакомились когда говорили о мейкфайлах). Цели в терминах ант сравнимы с процедурами в языках программирования и содержат вызовы команд-заданий (тасков). Каждое задание представляет собой неделимую, атомарную команду, выполняющую некоторое элементарное действие.
}
\begin{frame}
\frametitle{С чего всё начиналось (Ant, Ivy)}
\end{frame}
\note{
Между целями могут быть определены зависимости — каждая цель выполняется только после того, как выполнены все цели, от которых она зависит (если они уже были выполнены ранее, повторного выполнения не производится). Типичными примерами целей являются clean (удаление промежуточных файлов), compile (компиляция всех классов), deploy (развёртывание приложения на сервере).
}
\begin{frame}
\frametitle{С чего всё начиналось (Ant, Ivy)}
\end{frame}
\note{
Скачивание и установка, ant для Linux-подобных ОС выполняется привычной командой установки в вашем пакетном менеджере, вроде sudo apt install ant, а для Windows можно перейти на сайте ant.apache.org и скачать архив, распаковав его и прописав соответствующий путь в переменные среды. Проверить версию можно командой ant -version
}
\begin{frame}
\frametitle{С чего всё начиналось (Ant, Ivy)}
<?xml version="1.0"?>
<project name="HelloWorld" default="hello">
<target name="hello">
<echo>Hello, World!</echo>
</target>
</project>
\end{frame}
\note{
Теперь можно написать простой сценарий HelloWorld: в нём мы указываем версию хмл, без этого никакой хмл никогда не работает. затем говорим, что наш проект называется приветмир, а собирать по умолчанию для этого проекта надо таргет хелло. далее в проекте идут описания таргетов, в нашем случае таргет будет один, он будет носить имя хелло, а в рамках таргета нужно будет вывести в терминал приветствие миру.
}
\begin{frame}
\frametitle{С чего всё начиналось (Ant, Ivy)}
mkdir hello
cd hello
ant
\end{frame}
\note{
Затем, нужно создать подкаталог hello и сохранить туда файл с именем build.xml, который содержит сценарий. Далее надо перейти в каталог и вызвать ant. Полный перечень команд:
}
\begin{frame}
\frametitle{С чего всё начиналось (Ant, Ivy)}
Buildfile: /home/hello/build.xml
hello:
[echo] Hello, World!
BUILD SUCCESSFULL
\end{frame}
\note{
В результате выполнения которых получим следующий вывод. Что именно произошло? система сборки нашла файл сценария с именем по умолчанию, по удачному стечению обстоятельств система ищет файл с именем build.хмл и выполнила цель указанную по умолчанию, здесь уже никаких удачных стечений обстоятельств, мы явно указали, что нужно по умолчанию выполнять таргет с именем hello. Чтобы не запутаться в более сложном проекте, мы указали имя проекта, с помощью атрибута name.
}
\begin{frame}
\frametitle{С чего всё начиналось (Ant, Ivy)}
<!-- Очистка -->
<target name="clean" description="Removes all temporary files">
<!-- Удаление файлов -->
<delete dir="\${build.classes}"/>
</target>
\end{frame}
\note{
В стандартной поставке ant присутствует более 100 заранее созданных заданий, таких как: удаление файлов и директорий (delete), компиляция java-кода (javac), вывод сообщений в консоль (echo) и т.д. Вот пример реализации удаления временных файлов, используя задание delete
}
\begin{frame}
\frametitle{С чего всё начиналось (Ant, Ivy)}
\end{frame}
\note{
На данный момент Ant используют в связке с Ivy, которая является гибким, настраиваемым инструментом для управления (записи, отслеживания, разрешения и отчетности) зависимостями Java проекта.
}
%-----------------------------------------
% Некоторые достоинства Ivy:
% гибкость и конфигурируемость – Ivy по существу не зависит от процесса и не привязан к какой-либо методологии или структуре;
% тесная интеграция с Apache Ant – Ivy доступна как автономный инструмент, однако он особенно хорошо работает с Apache Ant, предоставляя ряд мощных задач от разрешения до создания отчетов и публикации зависимостей;
% транзитивность – возможность использовать зависимости других зависимостей.
% Немного о функциях Ivy:
% управление проектными зависимостями;
% отчеты о зависимостях. Ivy производит два основных типа отчетов: отчеты HTML и графические отчеты;
% Ivy наиболее часто используется для разрешения зависимостей и копирует их в директории проекта. После копирования зависимостей, сборка больше не зависит от Apache Ivy;
% расширяемость. Если настроек по умолчанию недостаточно, вы можете расширить конфигурацию для решения вашей проблемы. Например, вы можете подключить свой собственный репозиторий, свой собственный менеджер конфликтов;
% XML-управляемая декларация зависимостей проекта и хранилищ JAR;
% настраиваемые определения состояний проекта, которые позволяют определить несколько наборов зависимостей.
% Apache Ivy обязана быть сконфигурирована, чтобы выполнять поставленные задачи. Конфигурация задается специальным файлом, в котором содержится информация об организации, модуле, ревизии, имени артефакта и его расширении.
% Некоторые модули могут использоваться по разному и эти различные пути использования могут требовать своих, конкретных артефактов для работы программы. Кроме того, модуль может требовать одни зависимости во время компиляции и сборки, и другие во время выполнения.
% Конфигурация модуля определяется в Ivy файле в формате .xml, он будет использоваться, чтобы обнаружить все зависимости для дальнейшей загрузки артефактов. Понятие «загрузка» артефакта имеет различные варианты выполнения, в зависимости от расположения артефакта: артефакт может находиться на веб-сайте или в локальной файловой системе вашего компьютера. В целом, загрузкой считается передача файла из хранилища в кеш Ivy.
% Пример конфигурации зависимостей с библиотекой Lombok:
% \begin{lstlisting}[language=XML,style=ASMStyle]
% <ivy-module version="2.0">
% <info organization="org.apache" module="hello-ivy"/>
% <dependencies>
% <dependency org="org.projectlombok" name="lombok" rev="1.18.24" conf="build->master"/>
% </dependencies>
% </ivy-module>
% \end{lstlisting}
% Его структура довольно проста, первый корневой элемент <ivy-module version="2.0"> указывает на версию Ivy, с которой данный файл совместим. Следующий тег <info organization="org.apache" module="hello-ivy"/> содержит информацию о программном модуле, для которого указаны зависимости, здесь определяются название организации разработчика и название модуля, хотя можно написать в данный тег что угодно. Наконец, сегмент <dependencies> позволяет определить зависимости. В данной примере модулю необходимо одна сторонняя библиотека: lombok.
% Однако, у такой системы, как Ant есть и свои минусы: Ant-файлы могут разрастаться до нескольких десятков мегабайт по мере увеличения проекта. На маленьких проектах выглядит всё достаточно неплохо, но на больших они длинные и неструктурированные, а потому сложны для понимания.
% Что привело к появлению новой системы - Maven.
% \subsection{Репозитории, артефакты, конфигурации}
% \subsection{Классический подход (Maven)}
% \subsection{Всем давно надоел XML (Gradle)}
% \subsection{Собственные прокси, хостинг и закрытая сеть}
% \subsection{Немного экзотики (Bazel)}
\end{document}
% \begin{frame}
% \frametitle{В предыдущих сериях...}
% 000
% \end{frame}
% \note{
% 111
% }
% \newpage
% \note{
% 222
% }