diff --git a/build/j-spec.pdf b/build/j-spec.pdf index 4b604c6..e6ca3ba 100644 Binary files a/build/j-spec.pdf and b/build/j-spec.pdf differ diff --git a/build/jtc1-1a.pdf b/build/jtc1-1a.pdf new file mode 100644 index 0000000..16c67af Binary files /dev/null and b/build/jtc1-1a.pdf differ diff --git a/build/jtc1-2a.pdf b/build/jtc1-2a.pdf index 5efe8ba..5612cd6 100644 Binary files a/build/jtc1-2a.pdf and b/build/jtc1-2a.pdf differ diff --git a/j-spec.tex b/j-spec.tex index 44817ce..66141d1 100644 --- a/j-spec.tex +++ b/j-spec.tex @@ -105,7 +105,7 @@ print(how\_old, "лет назад ты стал совершеннолетни \appendix \sloppy %\addcontentsline{toc}{chapter}{Термины, определения и сокращения} -\printnomenclature[20mm] +\printnomenclature[27mm] \chapter*{Приложения} %\addcontentsline{toc}{chapter}{Приложения} diff --git a/jtc1-1a.tex b/jtc1-1a.tex index f607ea5..ad822c5 100644 --- a/jtc1-1a.tex +++ b/jtc1-1a.tex @@ -1,4 +1,4 @@ -\documentclass[main.tex]{subfiles} +\documentclass[j-spec.tex]{subfiles} \begin{document} \section{Платформа: история и окружение} @@ -63,12 +63,12 @@ В последнее время, с развитием контейнеризации приложений, часто устанавливают инструментарий в Docker-контейнер и ведут разработку прямо в контейнере, это позволяет не захламлять компьютер разработчика разными версиями инструментария и быстро разворачивать свои приложения в \nom{CI}{(англ. Continious Integration) практика разработки программного обеспечения, которая заключается в постоянном слиянии рабочих копий в общую основную ветвь разработки и выполнении частых автоматизированных сборок проекта для скорейшего выявления потенциальных дефектов и решения интеграционных проблем.} или на целевом сервере. \begin{frm} - В общем случае, для разработки на любом языке программирования нужны так называемые \nom{SDK}{(от англ. software development kit, комплект для разработки программного обеспечения) — это набор инструментов для разработки программного обеспечения в одном устанавливаемом пакете. Они облегчают создание приложений, имея компилятор, отладчик и иногда программную среду. В основном они зависят от комбинации аппаратной платформы компьютера и операционной системы.} (Software Development Kit, англ. - инструментарий разработчика приложений или инструментарий для разработки приложений). Частный случай такого SDK - инструментарий разработчика на языке Java - Java Development Kit. +\info В общем случае, для разработки на любом языке программирования нужны так называемые \nom{SDK}{(от англ. software development kit, комплект для разработки программного обеспечения) — это набор инструментов для разработки программного обеспечения в одном устанавливаемом пакете. Они облегчают создание приложений, имея компилятор, отладчик и иногда программную среду. В основном они зависят от комбинации аппаратной платформы компьютера и операционной системы.} (Software Development Kit, англ. - инструментарий разработчика приложений или инструментарий для разработки приложений). Частный случай такого SDK - инструментарий разработчика на языке Java - Java Development Kit. \end{frm} На курсе будет использоваться BellSoft Liberica JDK 11, но возможно использовать и других производителей, например, самую распространённую Oracle JDK. Производителя следует выбирать из требований по лицензированию, так, например, Oracle JDK можно использовать бесплатно только в личных целях, за коммерческую разработку с использованием этого инструментария придётся заплатить. \begin{frm} - Для корректной работы самого инструментария и сторонних приложений, использующих инструментарий, проследите, пожалуйста, что установлены следующие переменные среды ОС: +\excl Для корректной работы самого инструментария и сторонних приложений, использующих инструментарий, проследите, пожалуйста, что установлены следующие переменные среды ОС: \begin{itemize} \item в системную \code{PATH} добавить путь до исполняемых файлов JDK, например, для UNIX-подобных систем: \verb|PATH=$PATH:/usr/lib/jvm/jdk1.8.0_221/bin| \item \code{JAVA_HOME} путь до корня JDK, например, для UNIX-подобных систем: \code{JAVA_HOME=/usr/lib/jvm/jdk1.8.0_221/} @@ -306,7 +306,7 @@ Hello, world! \end{lstlisting} \begin{frm} - Скомпилированные классы всегда содержат одинаковые первые четыре байта, которые в шестнадцатиричном представлении формируют надпись «кофе, крошка». +\info Скомпилированные классы всегда содержат одинаковые первые четыре байта, которые в шестнадцатиричном представлении формируют надпись «кофе, крошка». \begin{figure}[H] \centering \includegraphics[width=14cm]{jc-01-cafe-babe.png} @@ -397,17 +397,17 @@ Here is your number: 4. В подразделе \hrf{subsec:cli} мы проговорили о сборке проектов вручную. Компилировать проект таким образом — занятие весьма утомительное, особенно когда исходных файлов становится много, в проект включаются библиотеки и прочее. \begin{frm} - \code{Makefile} — это набор инструкций для программы \code{make} (классическая, это GNU Automake), которая помогает собирать программный проект в одну команду. Если запустить \code{make} то программа попытается найти файл с именем по-умолчанию \code{Makefile} в текущем каталоге и выполнить инструкции из него. +\info \code{Makefile} — это набор инструкций для программы \code{make} (классическая, это GNU Automake), которая помогает собирать программный проект в одну команду. Если запустить \code{make} то программа попытается найти файл с именем по-умолчанию \code{Makefile} в текущем каталоге и выполнить инструкции из него. \end{frm} -Make, не привносит ничего принципиально нового в процесс компиляции, а только лишь автоматизируют его. В простейшем случае, в \code{Makefile} достаточно описать так называемую цель, \code{target}, и что нужно сделать для достижения этой цели. Цель, собираемая по-умолчанию называется \code{all}, так, для простейшей компиляции нам нужно написать: +Make, не привносит ничего принципиально нового в процесс компиляции, а только лишь автоматизируют его. В простейшем случае, в \code{Makefile} достаточно описать так называемую \setword{цель}{word:makefile-target}, \code{target}, и что нужно сделать для достижения этой цели. Цель, собираемая по-умолчанию называется \code{all}, так, для простейшей компиляции нам нужно написать: \begin{lstlisting}[style=ASMStyle] all: javac -sourcepath .src/ -d out src/ru/gb/jcore/sample/Main.java \end{lstlisting} \begin{frm} - Внимание поклонникам войны за пробелы против табов в тексте программы: в Makefile для отступов при описании таргетов нельзя использовать пробелы. Только табы. Иначе make обнаруживает ошибку синтаксиса. +\excl Внимание поклонникам войны за пробелы против табов в тексте программы: в Makefile для отступов при описании таргетов нельзя использовать пробелы. Только табы. Иначе make обнаруживает ошибку синтаксиса. \end{frm} По сути, это всё. Но возможно сделать более гибко настраиваемый файл, чтобы не нужно было запоминать, как называются те или иные папки и файлы. В Makefile можно записывать переменные, например: @@ -423,7 +423,7 @@ javac -sourcepath .${SRCDIR}/ -d ${OUTDIR} Чтобы вызвать утилиту для сборки цели по-умолчанию, достаточно в папке, содержащей \code{Makefile} в терминале написать \code{make}. Чтобы воспользоваться другими написанными таргетами нужно после имени утилиты написать через пробел название таргета \begin{frm} - Docker — программное обеспечение для автоматизации развёртывания и управления приложениями, контейнеризатор приложений. Позволяет «упаковать» приложение со всем его окружением и зависимостями в контейнер, который может быть развёрнут на любой системе, поддерживающей соответствующую технологию. +\info Docker — программное обеспечение для автоматизации развёртывания и управления приложениями, контейнеризатор приложений. Позволяет «упаковать» приложение со всем его окружением и зависимостями в контейнер, который может быть развёрнут на любой системе, поддерживающей соответствующую технологию. \end{frm} Docker также не привносит ничего технологически нового, но даёт возможность не устанавливать JDK и не думать о переключении между версиями, достаточно взять контейнер с нужной версией инструментария и запустить приложение в нём. diff --git a/jtc1-2a.tex b/jtc1-2a.tex index e134f49..aff89ec 100644 --- a/jtc1-2a.tex +++ b/jtc1-2a.tex @@ -21,21 +21,30 @@ \item \nom{Maven}{Apache Maven — фреймворк для автоматизации сборки проектов на основе описания их структуры в файлах на языке POM (англ. Project Object Model), являющемся подмножеством XML. В отличие от Ant, декларативный. Проект Maven издаётся сообществом Apache Software Foundation. Название системы является словом из языка идиш, смысл которого можно примерно выразить как «собиратель знания».}; \item \nom{Gradle}{система автоматической сборки, построенная на принципах Apache Ant и Apache Maven, но предоставляющая специалььный предметно-ориентированный диалект на языках Groovy и Kotlin вместо традиционной XML-образной формы представления конфигурации проекта.}; \item \nom{Bazel}{свободный программный продукт для автоматизации сборки и тестирования приложений. Компания Google использует внутренний инструмент под названием Blaze, и выпустила свободно распространяемый вариант с открытым исходным кодом под названием Bazel (анаграмма Blaze). Bazel впервые выпущен в марте 2015.}; +\item \nom{DSL}{(англ. domain-specific language, DSL — «язык, специфический для предметной области», предметно-ориентированный язык) — компьютерный язык, специализированный для конкретной области применения (в противоположность языку общего назначения, применимому к широкому спектру областей и не учитывающему особенности конкретных сфер знаний). Построение такого языка и/или его структура данных отражают специфику решаемых с его помощью задач.} +\item \nom{XML}{англ. eXtensible Markup Language) — «расширяемый язык разметки». Рекомендован Консорциумом Всемирной паутины (W3C). Спецификация XML описывает документы и частично описывает поведение XML-процессоров (программ, читающих XML-документы и обеспечивающих доступ к их содержимому). XML разрабатывался как язык с простым формальным синтаксисом, удобный для создания и обработки документов как программами, так и человеком, с акцентом на использование в Интернете.} \item \nom{Артефакт}{Артефакт — это любой созданный искусственно элемент программной системы. К элементам программной системы, а, следовательно, и к артефактам, могут относиться исполняемые файлы, исходные тексты, веб страницы, справочные файлы, сопроводительные документы, файлы с данными, модели и многое другое, являющееся физическим носителем информации.}; -\item \nom{Репозиторий}{место, где хранятся и поддерживаются какие-либо данные. Чаще всего данные в репозитории хранятся в виде файлов, доступных для дальнейшего распространения по сети}; -\item \nom{Прокси}{промежуточный комплекс, выполняющий роль посредника между пользователем и целевым сервером, позволяющий клиентам как выполнять косвенные запросы к другим сетевым службам, так и получать ответы. Сначала клиент подключается к прокси и запрашивает какой-либо ресурс (например артефакт), затем прокси либо подключается к указанному серверу и получает ресурс у него, либо возвращает ресурс из собственного кэша.}; +\item \nom{Репозиторий}{(англ. repository — хранилище) — место, где хранятся и поддерживаются какие-либо данные. Чаще всего данные в репозитории хранятся в виде файлов, доступных для дальнейшего распространения по сети}; +\item \nom{Прокси}{(англ. proxy — уполномоченный, заместитель) промежуточный комплекс, выполняющий роль посредника между пользователем и целевым сервером, позволяющий клиентам как выполнять косвенные запросы к другим сетевым службам, так и получать ответы. Сначала клиент подключается к прокси и запрашивает какой-либо ресурс (например артефакт), затем прокси либо подключается к указанному серверу и получает ресурс у него, либо возвращает ресурс из собственного кэша.}; \end{itemize} \subsection{Мотивация и схема (зачем это нужно и как это работает)} -% Комментатор_Ильнар. Вот тут ощущение что мы недостаточно ребятам объяснили что реальный проект - это не только свой код, который мы написали в IDE, но и большое количество всего остального, что мы при этом используем - библиотеки, фреймворки и т.п. Более того, здесь ребята могут ничего не знать про jar файлы, в которые запаковывается проект. Я бы наверное (возможно в 1-й лекции) рассказал про jar, сделал "исполняемый файл" который можно скормить JRE, а потом на этой лекции рассказал что руками собирать все нужные библиотеки, указывать их в класспаф и т.п. - это дико неудобно, эту работу можно всю автоматизировать с помощью сборщиков, а сборщики - это вот то про что мы тут собственно и рассказываешь) +% по комментарию Ильнара. +Реальный проект - это не только непосредственный код, который пишется в IDE\footnote{Чаще всего, называется бизнес-кодом или бизнес-логикой}, но и большое количество всего, что мы при этом используем - библиотеки, фреймворки и т.п. То есть, мы не пишем каждый проект «с чистого листа», использование JRE/JDK нам это явно демонстрирует, поскольку в них есть уже готовые написанные классы, реализующие некоторую функциональность (подробнее на странице \pageref{table:jdk-contents}). + +\begin{frm} +\info Всё, что так или иначе используется в проекте, кроме непосредственного кода, написанного в IDE, называется \textbf{зависимостями проекта}, поскольку код всегда «опирается» на заранее созданный инструментарий. Например, мы просто пишем строку с приветствием миру, не думая, как именно она раскладывается в массив символов. Или мы просто выводим приветствие миру в терминал, а инструментарий берёт на себя открытие вспомогательных потоков и прочие сложности. +\end{frm} + +Из-за этого, \textit{единый исполняемый файл} проекта\footnote{Чаще всего, такой файл нужен для быстрого переноса и запуска проекта на устройстве, на котором не установлен JDK}, включающий в себя все зависимости, может разрастаться до нескольких сотен мегабайт, а о том, чтобы скомпилировать его со всеми зависимостям, и речи быть не может. Сборщики проекта - это сложный инструментарий, который может скрывать обширный объём работы, который при ручном подходе требует значительных затрат и может оказаться весьма утомительным. Они позволяют не привязываться к конкретным IDE и интерфейсу среды разработки. Имеют текстовое управление, что часто ускоряет процесс работы с ними на пред-продакшн серверах, где часто терминальный интерфейс. \begin{frm} - Система сборки это программа, которая собирает другие программы. На вход система сборки получает исходный код, написанный разработчиком, а на выход выдаёт программу, которую уже можно запустить. Отличается от компилятора тем, что вызывает его при своей работе, а компилятор о системе сборки ничего не знает, то есть является инструментом более широкого спектра. +\info Система сборки это программа, которая собирает другие программы. На вход система сборки получает исходный код, написанный разработчиком, а на выход выдаёт программу, которую уже можно запустить. Отличается от компилятора тем, что вызывает его при своей работе, а компилятор о системе сборки ничего не знает, то есть является инструментом более широкого спектра. \end{frm} Сборщик часто решает целый спектр задач, для решения которых компилятор не предусмотрен. Например: @@ -53,43 +62,54 @@ \begin{enumerate} \item Конфигурации - собственная конфигурация, где хранятся «личные» настройки системы. Например, такие как информация о месте установки или окружении, информация о репозиториях и прочее; \item Конфигурация модуля, где описывается место расположения проекта, его зависимости и задачи, которые требуется выполнять для проекта; -% Комментатор_Ильнар. Слово зависимости мы еще не ввели. студенты его могли не слышать. Надо как раз как в прошлом комментарии показать что наш проект может использовать сторонние библиотеки. При этом мы легко можем скачать и положить их рядом на своем компе и прописать в класспаф при javac и даже некоторую автоматизацию сделать. Но, если мы хотим это разместить где-то в другом месте (деплой на сервере), то это становится уже далеко не так удобно. Библиотеки (и все остальное) с которыми связан наш проект (читай от которых он зависит) называются зависимостями. И одна из задач, которую решают сборщики проектов - это как раз таки работа с этими зависимостями. - + % по комментарию Ильнара, слово "зависимости" было раскрыто выше \item Парсеры конфигураций - парсер способный «прочитать» конфигурацию самой системы, для её настройки соответствующим образом; \item Парсер конфигурации модуля, где некоторыми «понятными человеку» терминами описываются задачи для системы сборки; \item Сама система — некоторая утилита + скрипт для её запуска в вашей ОС, которая после чтения всех конфигураций начнет выполнять тот или иной алгоритм, необходимый для реализации запущенной задачи; \item Система плагинов — дополнительные подключаемые надстройки для системы, в которых описаны алгоритмы реализации типовых задач; -\item Локальный репозиторий — репозиторий (некоторое структурированное хранилище некоторых данных), расположенный на локальной машине, для кэширования запрашиваемых файлов на удаленных репозиториях. - -% Комментатор_Ильнар. Я бы тут простыми словами еще раз это сказал. Локальный репозиторий - это то место на вашем компьютере куда будут скачаны зависимости для вашего проекта. Хотя это наверное больше для сценария, но немного упростил бы все равно. +\item Локальный репозиторий — репозиторий (некоторое структурированное хранилище данных), расположенный на локальной машине, для кэширования запрашиваемых файлов на удаленных репозиториях. +% по комментарию Ильнара. добавил слово репозиторий в глоссарий, поскольку само понятие репы можно раскладывать целый урок (локальный, проектный, зеркало, прокси, глобальный, публичный, а чуть подробнее о структуре хранения предполагается рассказать в этом же уроке далее) \end{enumerate} Для языка Java основных систем сборок три: \begin{itemize} -\item Иногда можно встретить Ant в сочетании с инструментом по управлению зависимостями Ivy, в чистом виде Ant почти никогда не применялся; -\item Самый популярный инструмент - это Maven, используется для JavaEE и приложений с использованием Spring Framework; -\item Gradle основной инструмент в мобильной разработке, часто Groovy/Kotlin описания сборки оказываются удобнее XML; -% Комментатор_Ильнар. Тут предполагается что читатель знает причем тут XML, но это может быть не так. Можно добавить XML, который используется в Maven или что-то типа того. Или в блок про Мавен написать что в нем описание сборки в виде XML файла дается. +\item Иногда можно встретить Ant в сочетании с инструментом по управлению зависимостями Ivy, в чистом виде Ant почти никогда не применялся, описывает задачи сборки в виде XML файлов; +\item Самый популярный инструмент - это Maven, используется для JavaEE и приложений с использованием Spring Framework, основана на специальном подмножестве XML, называемом POM\footnote{(англ. Project Object Model) модель объектов проекта}; +\item Gradle основной инструмент в мобильной разработке, часто описания сборки на специальном DSL на основе Groovy/Kotlin, оказываются удобнее XML; +% по комментарию Ильнара, добавил чуть больше про хмл и дсл + глоссарий. \end{itemize} Экзотическая Bazel. Её отличает полная кроссплатформенность и кросстехнологичность, что делает её особенно привлекательной для микросервисных проектах, использующих несколько языков программирования. \subsection{С чего всё начиналось (Ant, Ivy)} -Первый специализированный инструмент автоматизации задач для языка Java. По сути, это аналог \code{Makefile}, то есть набор скриптов (которые в разговорной речи называются тасками\footnote{от англ task - задача, задание}). В отличие от make, утилита Ant имеет только одну зависимость — JRE. Ещё одним важным отличием от мейка является отказ от использования команд операционной системы. Всё что пишется в ант пишется на XML, что обеспечивает переносимость сценариев между платформами. +Первый специализированный инструмент автоматизации задач для языка Java. По сути, это аналог \code{Makefile}, то есть набор скриптов (которые в разговорной речи называются тасками\footnote{от англ task - задача, задание}). В отличие от \code{make}, утилита Ant имеет только одну зависимость — JRE. Ещё одним важным отличием от \code{make} является отказ от использования команд операционной системы. Всё что пишется в Ant пишется на XML, что обеспечивает переносимость сценариев между платформами. -Управление процессом сборки как только что было сказано, происходит посредством XML-сценария, также называемого Build-файлом. В первую очередь этот файл содержит определение проекта, состоящего из отдельных целей (таргетов, с этим понятием мы познакомились когда говорили о мейкфайлах). Цели в терминах ант сравнимы с процедурами в языках программирования и содержат вызовы команд-заданий (тасков). Каждое задание представляет собой неделимую, атомарную команду, выполняющую некоторое элементарное действие. +Управление процессом сборки происходит посредством XML-сценария, также называемого Build-файлом. В первую очередь этот файл содержит определение проекта, состоящего из отдельных целей (жарг. таргетов, стр. \pageref{word:makefile-target})). Цели в терминах Ant сравнимы с процедурами в языках программирования и содержат вызовы команд-заданий (жарг. тасков). Каждое задание представляет собой неделимую, атомарную команду, выполняющую некоторое элементарное действие. -Между целями могут быть определены зависимости — каждая цель выполняется только после того, как выполнены все цели, от которых она зависит (если они уже были выполнены ранее, повторного выполнения не производится). Типичными примерами целей являются clean (удаление промежуточных файлов), compile (компиляция всех классов), deploy (развёртывание приложения на сервере). +Между целями могут быть определены зависимости\footnote{не путать с зависимостями проекта, здесь речь исключительно о задачах и командах Ant} — каждая цель выполняется только после того, как выполнены все цели, от которых она зависит (если они уже были выполнены ранее, повторного выполнения не производится). Типичными примерами целей являются +\begin{itemize} +\item \code{clean} (удаление промежуточных файлов); +\item \code{compile} (компиляция всех классов); +\item \code{deploy} (развёртывание приложения на сервере). +\end{itemize} -Скачивание и установка, ant для Linux-подобных ОС выполняется привычной командой установки в вашем пакетном менеджере, вроде sudo apt install ant, а для Windows можно перейти на сайте ant.apache.org и скачать архив, распаковав его и прописав соответствующий путь в переменные среды. Проверить версию можно командой ant -version +Скачивание и установка, Ant для Linux-подобных ОС выполняется командой установки в пакетном менеджере (для Debian-подобных дистрибутивов \code{sudo apt install ant}), а для Windows необходимо перейти на сайт \href{https://ant.apache.org}{https://ant.apache.org}, скачать архив с приложением, распаковать его и прописать соответствующий путь в переменные среды. Проверить установку и версию можно командой +\begin{lstlisting}[language=Bash,style=CCodeStyle] + ant -version +\end{lstlisting} -% Комментатор_Ильнар. Команды типа sudo apt-install ant и т.п. давайте выделять как-то в тексте. наверное тут можно это красиво сделать +% по комментарию Ильнара просто переместил описание перед примером +Теперь можно написать простой сценарий HelloWorld, для этого необходимо создать файл \code{build.xml} (см листинг \hrf{lst:ant-hello}). В нём мы указываем следующие данные: +\begin{enumerate} +\item версию XML, иначе XML не работает; +\item название проекта в теге \code{project} параметр \code{name}; +\item таргет по умолчанию в теге \code{project} параметр \code{default}; +\item внутри тега \code{project} описания таргетов, в теге \code{target} параметр \code{name} указывает имя цели; +\item внутри тега \code{target} команды, которые необходимо выполнить, например, \code{}. +\end{enumerate} -% Комментатор_Ильнар. теперь к тому что ниже. нужен некоторый переход. Иначе мы с ant -version перешли на некоторую магию. Надо пояснить что мы сейчас будем делать. - -% --- слайд -\begin{lstlisting}[language=XML,style=ASMStyle] +\begin{lstlisting}[language=XML,style=ASMStyle,caption={сценарий Ant echo «Hello, World!»},label={lst:ant-hello}] @@ -97,24 +117,22 @@ \end{lstlisting} -% --- конец слайда -Теперь можно написать простой сценарий HelloWorld: в нём мы указываем версию XML, без этого никакой XML никогда не работает. затем говорим, что наш проект называется "привет мир", а собирать по умолчанию для этого проекта надо таргет hello. далее в проекте идут описания таргетов, в нашем случае таргет будет один, он будет носить имя хелло, а в рамках таргета нужно будет вывести в терминал приветствие миру. -% Комментатор_Ильнар. к тексту выше. надо все же чуть более явно пояснить отдельные детали. Например, когда мы пишем что по умолчанию будет выполняться таргет hello, то можно в скобках сделать пояснение (см. default="hello") и так по всем пунктам. -% --- слайд -\begin{lstlisting}[language=C,style=CCodeStyle] -mkdir hello -cd hello -ant +Затем, нужно создать каталог \code{hello} и сохранить туда только что созданный файл с именем \code{build.xml}, который содержит сценарий. Далее надо перейти в каталог и вызвать \code{ant}. +\begin{frm} +\excl Следует обратить внимание, что команды навигации (а также, копирования, создания, редактирования файлов) в терминале могут (и, скорее всего, будут) отличаться. +\end{frm} +Полный перечень команд, например: + +\begin{lstlisting}[language=Bash,style=CCodeStyle] + mkdir hello + cd hello + cp ../build.xml . + ant \end{lstlisting} -% --- конец слайда -Затем, нужно создать подкаталог hello и сохранить туда файл с именем build.xml, который содержит сценарий. Далее надо перейти в каталог и вызвать ant. Полный перечень команд: - -% Комментатор_Ильнар. ощущение что этот слайд находится чуть выше. После этого слайда также вроде текст сбит, должен находиться до него - -% --- слайд +В результате выполнения получим следующий вывод. \begin{verbatim} Buildfile: /home/hello/build.xml @@ -122,9 +140,8 @@ hello: [echo] Hello, World! BUILD SUCCESSFULL \end{verbatim} -% --- конец слайда -В результате выполнения которых получим следующий вывод. Что именно произошло? система сборки нашла файл сценария с именем по умолчанию, по удачному стечению обстоятельств система ищет файл с именем build.xml и выполнила цель указанную по умолчанию, здесь уже никаких удачных стечений обстоятельств, мы явно указали, что нужно по умолчанию выполнять таргет с именем hello. Чтобы не запутаться в более сложном проекте, мы указали имя проекта, с помощью атрибута name. +Система сборки нашла файл сценария с именем по умолчанию (\code{build.xml}) и выполнила цель указанную по умолчанию (\code{hello}). В стандартной поставке Ant присутствует более 100 заранее созданных заданий, таких как: удаление файлов и директорий (\code{delete}), компиляция java-кода (\code{javac}), вывод сообщений в консоль (\code{echo}) и т.д. Пример реализации удаления временных файлов, используя задание delete % --- слайд \begin{lstlisting}[language=XML,style=ASMStyle] @@ -136,7 +153,6 @@ BUILD SUCCESSFULL \end{lstlisting} % --- конец слайда -В стандартной поставке ant присутствует более 100 заранее созданных заданий, таких как: удаление файлов и директорий (delete), компиляция java-кода (javac), вывод сообщений в консоль (echo) и т.д. Вот пример реализации удаления временных файлов, используя задание delete \subsection{Репозитории, артефакты, конфигурации} \subsection{Классический подход (Maven)} @@ -220,5 +236,8 @@ Apache Ivy обязана быть сконфигурирована, чтобы Однако, у такой системы, как Ant есть и свои минусы: Ant-файлы могут разрастаться до нескольких десятков мегабайт по мере увеличения проекта. На маленьких проектах выглядит всё достаточно неплохо, но на больших они длинные и неструктурированные, а потому сложны для понимания. Что привело к появлению новой системы - Maven. +\newpage +\sloppy +\printnomenclature[27mm] \end{document} \ No newline at end of file diff --git a/settings/main-style-preamble.tex b/settings/main-style-preamble.tex index f99357c..9ae5327 100644 --- a/settings/main-style-preamble.tex +++ b/settings/main-style-preamble.tex @@ -1,5 +1,6 @@ \usepackage{fancyhdr} \usepackage{graphicx} +\usepackage{xcolor,colortbl}% http://ctan.org/pkg/xcolor \usepackage{titlesec} \usepackage{tikz} \usepackage{indentfirst} @@ -8,7 +9,7 @@ \usepackage{enumitem} \usepackage{multicol,multirow} \usepackage{float,adjustbox} -%\usepackage{fontawesome} +\usepackage{fontawesome} \usepackage{longtable} \usepackage{tikz} \usepackage{hyperref} @@ -45,8 +46,18 @@ \newcommand*{\nom}[2]{#1\nomenclature{#1}{#2}} \renewcommand\labelitemi{\textemdash} \newenvironment{frm} - { \begin{center} \begin{tabular}{|p{0.9\textwidth}|} \hline\\ } - { \\\\\hline \end{tabular} \end{center} } + { \begin{center} \renewcommand*{\arraystretch}{2} \begin{tabular}{|p{0.9\textwidth}|} \hline } + { \\\hline \end{tabular} \end{center} } + +\newcommand{\info}{\cellcolor{green!20}{\Huge \faInfoCircle \quad}} +\newcommand{\excl}{\cellcolor{red!20}{\Huge \faExclamationTriangle \quad}} + +\makeatletter +\newcommand{\setword}[2]{% + \phantomsection + #1\def\@currentlabel{\unexpanded{#1}}\label{#2}% +} +\makeatother \fancypagestyle{plain}{ \setlength{\headheight}{33pt}