Sen microservice, analyse text update.

 Numericious path (preamble, bibliography at all, img ect)

project/text/bibliography.bib

@@ -42,7 +42,8 @@ @book{дейт2008введение
   title={Введение в системы баз данных},
   author={Дейт, К Дж},
   year={2008},
-  publisher={Вильямс},
+  publisher={Вильямс}, 
+  pages={1328},
   language=russian
 }
 @book{zeiss2015node,
@@ -51,3 +52,15 @@ @book{zeiss2015node
   year={2015},
   language=english
 }
+@article{приходченко2018обґрунтування,
+  title={Обґрунтування вибору мікросервісної архітектури в порівнянні з монолитною},
+  author={Приходченко, Сергій Дмитрович and Родна, КС and Поштак, РВ},
+  year={2018},
+  pages={4},
+  publisher={Нац. техн. ун-т “Дніпровська політехніка”}
+}
+@article{кучер2018мікросервісна,
+  title={Мікросервісна архітектура та її особливості},
+  author={Кучер, ВВ},
+  year={2018}
+}

project/text/code/CalendarIframe.html

@@ -0,0 +1,8 @@
+<iframe src="https://calendar.google.com/calendar/b/2/embed?title=ФКНФМ ХДУ&amp;
+	height=600&amp;	wkst=2&amp;	hl=uk&amp; bgcolor=%23FFFFFF&amp;
+	src=fcsfmksu%40gmail.com&amp; color=%2342104A&amp;
+	src=kipiekedu%40gmail.com&amp; color=%231B887A&amp;
+	ctz=Europe%2FKiev" 
+	style="border-width: 0;" frameborder="0" scrolling="no" 
+	width="100%" height="600px">
+</iframe>

project/text/main-sen.tex

@@ -31,7 +31,7 @@
 
 \include{sen/intro} % Введение
 \include{sen/analyze}
-\include{sen/database} 
+\include{sen/database}
 \include{sen/backend} 
 \include{sen/conclusion} % Заключение
 \include{sen/bibliography} % Библиографический список

project/text/preamble.tex

@@ -23,11 +23,25 @@
 % Украинский язык
 \usepackage{polyglossia}
 \setdefaultlanguage{ukrainian}
+\setotherlanguage{russian}
+\setotherlanguage{english}
 
 \usepackage[autostyle]{csquotes} % Стиль кавычек
 \DeclareQuoteAlias{russian}{ukrainian} % csquotes не знает об украинском языке. Примем, что кавычки аналогичные русскому
 
-\usepackage[backend=biber, babel=hyphen, bibstyle=gost-standard, style=numeric-comp]{biblatex} % Библиография
+\usepackage[
+backend=biber, %подключение пакета biber (тоже нужен)
+bibstyle=gost-numeric, %подключение одного из четырех главных стилей biblatex-gost 
+citestyle=numeric-comp, %подключение стиля стиля (а вот!) 
+language=auto, %указание сортировки языков
+babel=other, %указание языков
+sorting=ntvy, %тип сортировки в библиографии
+doi=false, 
+eprint=false, 
+isbn=false, 
+dashed=false, 
+url=false %все false выключают отображение полей, заполненных в библиографической базе, но не актуальных для печатного листа
+]{biblatex} % Библиография
 
 \usepackage{import} % Разбиение текста проекта на файлы
 

project/text/sen/analyse/GoogleCalendar.tex

@@ -3,3 +3,19 @@ \subsubsection{Google Calendar}
 Google Calendar — безкоштовний веб-додаток для тайм-менеджменту розроблений Google. Інтерфейс подібний до аналогічних календарних додатків, таких як Microsoft Outlook. Має різні режими перегляду, зокрема денний, тижневий та місячний. Події зберігаються онлайн, а тому календар можна переглядати з будь-якого пристрою, обладнаного доступом до мережі Інтернет. Додаток може імпортувати та експортувати файли календаря різних форматів, а для існуючих — задавати різні права доступу. 
 
 Слід зазначити, що Google Calendar, як і інші сервіси Google, має відкрите API, що дозволяє взаємодіяти з ним через власні додатки після відповідних налаштувань.
+
+Окремо слід звернути увагу на розвинені технології вбудовування документів Google (зокрема календарів Google Calendar) в власні веб додатки. 
+
+Одним з прикладів такого використання в контексті розвитку інформаційної інфраструктури університету можна навести інтеграцію календаря подій факультету комп'ютерних наук, фізики та математики ХДУ в відповідну сторінку (kspu.edu/About/Faculty/FPhysMathemInformatics.aspx) на офіційному веб-сайті (рис.~\ref{fig:CalendarKspuEdu}).
+
+\addimg{CalendarKspuEdu.png}{0.85}{Календар подій факультету}{fig:CalendarKspuEdu}
+
+В наведеному прикладі події різних календарів, об'єднаних для відображення відображаються різними кольорами, в назву події включено час початку, а при натисканні на неї - відображаються деталі, зокрема опис, місце та посилання на подію в Google Calendar, де, крім іншого, можливо додати її для відслідковування та нагадування у власний календар, за умови, якщо користувач попередньо аворизувався в свій акаунт.
+
+Документи, для яких встановлені публічні права для перегляду, можна включати в вихідний код сайту у вигляді фрейму. Фрейм — окремий HTML-документ, який сам чи разом з іншими документами відображений у вікні веб-переглядача. При цьому, всю відповідальність за відображуване в фреймі несе сервіс-власник, тобто Google Calendar в наведеному прикладі, а в місці відображення знаходиться лише код інтеграції з посиланням та супутніми параметрами.
+
+При генерації коду фрейму для інтеграції у адміністратора є можливість налаштувати колірне оформлення фрейму, його розміри, регіональні стандарти (мову відображення, день початку тиждня, часовий пояс), обсяг за замовчуванням (тиждень, місяць), додати або приховати елементи керування. В процесі редагування налаштувань отримується невеликий за обсягом код (HTML тег iframe, рис.~\ref{fig:CalendarIframe}) для розміщення в коді власної веб-сторінки. 
+
+\addCodeAsImg{\lstinputlisting[numbers=left]{code/CalendarIframe.html}}{Код інтеграції календаря факультету}{fig:CalendarIframe}
+
+Аналогічним чином інтегруються інші сервіси Google, що вже знайшло використання при розміщенні матеріалів на сайті, як то презентації, текстові документи, таблиці, карти, що одночасно підтверджує, по перше, перспективність використання хмарних сервісів для поступового осучаснення інформаційної інфраструктури та, по друге, можливість переходу до використання їх замість звичних офісних пакетів (Microsoft Office, Open Office, Libre Office тощо).

project/text/sen/analyse/History.tex

@@ -1,3 +1,3 @@
-\subsection{Історія виникнення комп’ютерних систем планування}
+\subsection{Історія виникнення систем планування}
 
 Ідея планування робіт існує стільки, скільки існує людська цивілізація, адже ще в неоліті, з переходом до тваринництва і землеробства, постають задачі з контролем циклічних процесів, що і викликало у подальшому створення календаря і писемності для фіксування задач.

project/text/sen/backend/API.tex

@@ -6,7 +6,7 @@ \subsubsection{REST API}
 
 REST — підхід до архітектури мережевих протоколів, які забезпечують доступ до інформаційних ресурсів. Був описаний і популяризований 2000 року Роєм Філдінгом, одним із творців протоколу HTTP. В основі REST закладено принципи функціонування Всесвітньої павутини і, зокрема, можливості HTTP. Філдінг розробив REST паралельно з HTTP 1.1 базуючись на попередньому протоколі HTTP 1.0.
 
-Дані повинні передаватися у вигляді невеликої кількості стандартних форматів (наприклад, HTML, XML, JSON). Будь-який REST протокол (HTTP в тому числі) повинен підтримувати кешування, не повинен залежати від мережевого прошарку, не повинен зберігати інформації про стан між парами «запит-відповідь». Стверджується, що такий підхід забезпечує масштабовність системи і дозволяє їй еволюціонувати з новими вимогами.
+Дані повинні передаватися у вигляді невеликої кількості стандартних форматів (наприклад, HTML, XML, JSON). Будь-який REST протокол (HTTP в тому числі) повинен підтримувати кешування, не повинен залежати від мережевого прошарку, не повинен зберігати інформації про стан між парами «запит-відповідь». Стверджується, що такий підхід забезпечує масштабовність системи і дозволяє їй еволюціонувати з новими вимогами. Ці особливості сприяють використанню REST API при проектуванні мікросервісних додатків \cite[158]{кучер2018мікросервісна}.
 
 REST, як і кожен архітектурний стиль відповідає ряду архітектурних обмежень (англ. architectural constraints). Це гібридний стиль який успадковує обмеження з інших архітектурних стилів.
 

project/text/sen/backend/Microservices.tex

@@ -1,9 +1,15 @@
 \subsection{Мікросервісна архітектура}
 
-Мікросервісна архітектура полягає в створенні для кожного з логічно відокремлених компонентів системи окремого модулю, пов'язаного з рештою.
+Монолітна архітектура передбачає реалізацію всіх сервісів ресурсу як єдиної програмної системи. Тобто всі сервіси реалізовані за допомогою одного набору технологій (і мови програмування) і використовують загальні бібліотеки коду. Всі сервіси працюють з одним сервером баз даних.
 
-Один з принципів проектування мікросервісних додатків додатків визначає, що розмір одного сервісу повинен бути таким, щоб повністю «вміщуватися» в голову програміста.
+Мікросервіси є сучасною концепцією реалізації сервісів для систем, що розвиваються. Мікросервісна архітектура полягає в створенні для кожного з логічно відокремлених компонентів системи окремого модулю, пов'язаного з рештою. Часто сервіси групують, якщо вони реалізують схожий, або тісно пов'язаний функціонал.  
 
-\addCodeAsImg{\input{uml/GoogleServicesAuth}}{Авторизація з сервісами Google}{fig:GoogleServicesAuth}
+Один з принципів проектування мікросервісних додатків додатків визначає, що розмір одного сервісу повинен бути таким, щоб повністю «вміщуватися» в голову програміста \cite{приходченко2018обґрунтування}.
 
 В рамках системи закладено низку модулів, частина з яких використовує у своїй роботі доступ до сервісів Google, зокрема Google Sheets та Google Calendar. При цьому для взаємодії посередництвом Google API потрібно пройти процедуру аутентифікації (рис.~\ref{fig:GoogleServicesAuth}), закладену в методи бібліотек для основних платформ, в тому числі Node.js. Всі пакети мають відкритий вихідний код та поширюються разом з документацією.
+
+\addCodeAsImg{\input{uml/GoogleServicesAuth}}{Авторизація з сервісами Google}{fig:GoogleServicesAuth}
+
+Для компонентів додатку, спроектованого з дотриманням мікросервісної архітектури, справедливі наступні твердження: модулі можна легко замінити, зроблено акцент на незалежність розгортання та оновлення кожного з мікросервісів; модулі організовані навколо функцій, мікросервіс виконує одну елементарну функцію; модулі можуть бути реалізовані з використанням різних мов програмування, виконуватися в різних середовищах, під управлінням різних операційних систем на різних апаратних платформах \cite[159]{кучер2018мікросервісна}.
+
+Загалом, пріоритет віддається на користь найефективнішого для кожної конкретної функції способу розробки і виконання.