Материал: Мизніков Діплом Бакалавр
<p class="registration_page--wrapper--header--heading">
Sign in
</p>
<p class="registration_page--wrapper--header--text">
We make it quick & easy for schools to create high quality, engaging graphics.
</p>
</div>
<div class="registration_page--wrapper--form">
<%= form_for(resource, as: resource_name, url: session_path(resource_name)) do |f| %>
<div class="registration_page--wrapper--form--block_fields">
<%= f.label :email, class: 'registration_page--wrapper--form--block_fields--label' %>
<%= f.email_field :email, autofocus: true, autocomplete: "email", class: 'registration_page--wrapper--form--block_fields--input' %>
</div>
<div class="registration_page--wrapper--form--block_fields">
<%= f.label :password, class: 'registration_page--wrapper--form--block_fields--label' %>
<%= f.password_field :password, autocomplete: "current-password", class: 'registration_page--wrapper--form--block_fields--input' %>
<%= link_to 'Forgot Password?', new_user_password_path, class: 'registration_page--wrapper--form--block_fields--link_password' %>
</div>
<% if devise_mapping.rememberable? -%>
<div class="registration_page--wrapper--form--block_remember">
<%= f.check_box :remember_me %>
<%= f.label :remember_me, class:'registration_page--wrapper--form--block_remember--label' %>
</div>
<% end -%>
<div class="registration_page--wrapper--form--common_block">
<%= f.submit "Sign In", class: 'registration_page--wrapper--form--common_block--button' %>
<%= link_to 'Create Account', new_user_registration_path, class: 'registration_page--wrapper--form--common_block--link' %>
</div>
<% end %>
</div>
</div>
</div>
Лістинг 3.1 містить в собі програмний код для відображення сторінки авторизації. Використавши програмні можливості фреймворку Ruby on Rails, була розроблена форма, яка відправляє HTTP запит на сервер для підтвердження даних користувача. В свою чергу форма авторизації зв’язана з таблицею Users у базі даних.
При відправці форми передаються на сервер дані про email користувача, та закодований пароль, дані приходять на сервер, де відбувається перевіка з полями, що знаходяться у базі даних, якщо користувач ввів всю інформацію правильно, то він потрапляє далі у систему, а якщо ні, то система повідомить про те, що дані не пройшли перевірку.
На рисунку 3.8 представлена головна сторінка.
Рис. 3.8 – Головна сторінка
Потрапивши до системи, користувач має наступні можливості:
перехід до налаштувань профілю;
перехід до сторінки «Your Gallery»;
вибір макету з представлених системою;
здійснення пошуку макету по ключовим словам;
здійсення пошуку макету по тегам;
вибір улюбленого макету;
вихід із системи;
При розробці інфтерфейсу користувача, були використані темні кольори в поєднанні із салатовим, що підвищує конверсію сайту та зацікавленість користувачів у його використанні.
При здійненні пошуку макету користувачем, по ключовим словам відбувається Ajax запит на сервер, за допомогою якого система формує результати пошуку оголошення. Ключові слова та теги зв’язані із сутностями keyword та tag у базі даних.
Макети оголошень, велику кількість яких видно на рисунку 3.8, розташовані відразу на головній сторінці. Таким чином, у користувача є можливість створити оголошення у найкоротший час. Сутність макету у базі даних це – template.
На рисунку 3.9 представлена форма зміни інформації користувача та прив’язки до соціальної мережі Twitter.
Рис. 3.9 – Форма зміни інформації користувача та прив’язки до соціальної мережі Twitter
Прив’язка користвувача до соціальної мережі відповідає наступним колонкам таблиці: twitter_uid, twitter_token. Таким чином система зв’язується з API стороннього веб-ресурсу, а саме соціальної мережі Twitter. Здійснивши цю прив’язку, у користувача відкривається можливість ділитися оголошенням до своєї стрічки новин у Twitter.
Для здійнення прив’язки аккаунту Twitter, використовуються методи входу в аккаунт для сторонніх додатків. В нашому випатку використовується метод, який гарантує безпеку даних користувача під назвою OAuth. Після перевірки даних, система збереже у базу даних інформацію twitter_uid та twitter_token до таблиці Users. Відв’язати акаунт, користувач може не тільки з система, а й із своєї сторінки в Twitter.
На рисунку 3.10 представлений інтерфейс користувача для створення власного оголошення.
Рис. 3.10 – Інтерфейс клієнтської частини для створення оголошення про спортивну подію
Вибравши макет, що підходить для користувача, система перенаправляє до сторінки, де є можливість внести дані про бажану спортивну подію, чи її результат. На даній сторінці користувач може використовувати наступні функції системи:
внесення інформації до оголошення;
перехід до головної сторінки;
змінювати графічний вигляд оголошення;
зберегти попередні налаштування до бази даних;
відновити вигляд макету із попередніх налаштувань;
експортувати оголошення у форматі картинки;
поділитися оголошенням у соцільні мережі Facebook чи Twitter.
Дана сторінка надає доступ користувачеві до основної функції розроблюваної системи, а саме до створення оголошення. При розробці цієї сторінки було прийняте рішення, створювати оголошення на стороні клієнта, за допомогою засобів мови JavaSctipt.
Перейшовши до сторінки Your Gallery, користувач потрапляє до власної галереї медіафайлів.
На рисунку 3.11 представлена сторінка Your Gallery
Рис. 3.11 – Клієнтський інтерфейс сторінки Your Gallery
На даній сторінці, предоставлений доступ до перегляду, редагуванню, додаванню та видаленню необхідних ресурсів, наприклад: картинок, логотипів, фото. Був розроблений інтуїтивно зрозумілий інтерфейс, у вигляді папок, та у зв’язку з цим зв’язана сутність у базі даних називається folder. Користувач має можливість створювати папки, додавати туди власні ресурси та тримати там для швидкого доступу із сторінки створення оголошення. Окрім всього, є зарезервована системою папка, в якій зберігаються всі створені оголошення. Користувач має можливість, перейти до збереженого оголошення, яке зберігається у вигляді картинки, та скачати його.
Зміст папки представлений у вигляді таблиці, а її рядками є записи таблиці з бази даних під назвою pictureBase64.
На рисунку 3.12 представлений зміст зарезервоваї системою папки під назвою Created Pictures.
Рис. 3.12 – Зміст зарезервованої папки Created Pictures
Під таблицею знаходиться кнопка Show More, за допомогою якої, система відправляє Ajax запит на сервер і рендерить ще 6 зображень. Таким чином, було зменшено технічне навантаження на сервер і реалізовано динамічний рендеринг.
На рисунку 3.13 представлена сторінка додавання нових медіафайлів.
Рис. 3.13 – Сторінка додавання нових медіафайлів
На рисунку 3.14 зображено повідомлення системи, про успішне завантаження файлів.
Рис. 3.15 – Повідомлення системи про успішне завантаження файлів
На рисунку 3.16 представлено компонент системи, розроблений для доступу до завантажених медіафайлів.
Рис. 3.17 – Компонент з клієнтськими файлами для сторінки створення оголошь
Обґрунтування прийнятих проектних рішень
Під час розробки системи було прийнято ряд рішень для покращення процесу розробки та оптимізації функцій ситеми.
Для створення функцій роботи із графічною частиною, був проведений порівняльний аналіз між трьома технологіями, а саме: SVG, Canvas та WebGL. При виборі технології, враховувались наступні характеристики:
якість отриманого зображення на виході;
швидкість роботи;
кількість часу, необхідного для реалізації необхідних функцій системи.
Найкращу якість зображення, за рахунок векторної графіки, на виході дає SVG, та проте кількість годин для розробки функцій системи перевищували оцінену кількість годин.
При порівнянні Canvas і WebGL, було прийнято рішеня використовувати Canvas, через те що, API які дає WebGL націлені на створення здебільшого тривимірної графіки.
Лістинг 3.2 – Програмний код для ініціалізації Canvas елементу
loadCanvas() {
const canvas = document.createElement("canvas");
const ctx = canvas.getContext("2d");
ctx.clearRect(0, 0, canvas.width, canvas.height);
canvas.id = `canvasImage_${this.image.id}`;
this._setCanvasWidthAndHeightWithScale(canvas);
ctx.scale(this.scaleBy, this.scaleBy);
ctx.webkitImageSmoothingEnabled = true;
ctx.imageSmoothingEnabled = true;
ctx.imageSmoothingQuality = "high";
this._checkForExistingCanvas();
this.imageWrapper.appendChild(canvas);
canvas.style.opacity = getComputedStyle(this.image).getPropertyValue(
"opacity" );
this._rotate();
}
Canvas має зручні API для збереження контексту графіки та її трансформації до Base64 формату. Таким чиному відкривається можливість експортування оголошення у вигляді картинки.
Макети оголошення, були розроблені за допомогою HTML розмітки та CSS стилів, завдяки тому що розроблювана система має серверний рендеринг, сервер віддає правильні макети за різними посиланнями. Таким чином, з’явилась проблема перетворення HTML та CSS в канвас для подальшої роботи з оголошенням. Проаналізувавши готові рішення, було прийняно підключити готову бібліотеку під назвою html2canvas. Концепція готового рішення наступна, за допомогою засобів програмної мови JavaScript відбувається клонування необхідного вузла з DOM дерева HTML документа, після цього відбувається ініціалізація канвас елементу, який буде відповідати графічному вигляду прийнятого вузла.
На рисунку 3.18 представлений алгоритм перетворення HTML вузла в Canvas елемент.
Рис. 3.18 – Алгоритм перетворення HTML вузла в Canvas елемент
Розглянувши ситуацію, коли кількість користувачів почне зростати, була виявлена проблема, що у майбутньому, якщо всі медіафайли тримати на власному серверві, то пам’ять закінчиться дуже швидко. Адже для створення оголошення високої якості необхідно збільшувати роздільну здатність картинки, це означає що кількість пікселів буде на дюйм буде приблизно 256 – 300. За такої роздільної здатності розмір картинки буде приблизно 3,5 – 4 мб. Якщо взяти невелику аудиторію із 100 людей, які будуть робити по 2 оголошення в день, то для цього необхідно виділяти 800 мб в день. Поки система не підтримується за рахунок коштів користувачів, забезбечення вільним місцем є проблемою. Було прийняте рішення, зберігати всі медіафайли на сторонньому сервісі Amazon Web Services.
Amazon Web Services - комерційна публічна хмара, яка підтримується і розвивається компанією Amazon з 2006 року.
На рис. 3.19 преставлена клієнт серверна архітектура розроблюваної системи з використанням хмарного сервісу Amazon Web Services.
Рис. 3.19 – Клієнт серверна архітектура системи
Таким чином, було вирішено проблему нестачі пам’яті для початкогового етапу веб сайту. Сутність що зберігається у хмарі AWS називається active_storage_blob.