Пісочниця для початківців: як ми тренувалися писати онлайн-платформу для навчання

З кожним роком все більше речей переходять у формат online. Багато з того, що раніше було важко уявити в такому форматі, стало звичним та як результат більш зручними у використанні.

Мене звати Тетяна Гутій, я FullStack .NET розробниця компанії Binary Studio, і мені пощастило бути коучем Binary Studio Winter Academy 2020-2021 та взяти участь у розробці досить непростої, але водночас цікавої ідеї.

У цій статті розповім про створення вебплатформи для онлайн-навчання програмуванню під назвою Codi. На її базі вчителі могли б викладати свої лекції, а студенти — передивлятися їх та виконувати практичні завдання, не відволікаючись на використання сторонніх сервісів.

Наша платформа мала би містити всі необхідні для навчання матеріали в одному місці та дати користувачам можливість отримати повноцінний освітній досвід із живими сесіями кодування та переглядом результату виконання роботи.

Стаття буде корисна тим, хто тільки починає свій шлях в IT і хотів би дізнатися про успіхи та складнощі таких же початківців, як і вони. Хоч це і було до війни, але все ж залишається актуальним, тому що досвід новачків завжди цікавий та дає винести щось нове для кожного з нас.

Одна ідея — безліч варіантів імплементації

Завдання було неординарним та вимагало ретельного обміркування, але ми взялися за нього охоче. Адже дана платформа мала дозволити студентам попрацювати не тільки зі звичайними CRUD операціями, а і з чимось важчим, знаходити для себе нові виклики та працювати з раніше невідомими технологіями та інструментами.

Ідея була продумана до деталей, а саме: спосіб взаємодії вчителя та студента, робота з проєктами та кодом, можливість публікації та поширення своїх напрацювань з іншими.

Прийшла черга до реалізації. Ми перечитали безліч статей та обговорили багато варіантів, як можна реалізувати задум. Серед них було збирання проєкту всередині окремого Docker-контейнера, збір за допомогою командного рядка або ж пошук та використання вже готових рішень.

Нам хотілося врахувати все: витримку завантаженістю, масштабованість і важкість імплементації. Все потрібно було встигнути зробити за час проведення етапу проєктів, а це 6 тижнів. Не менш важливим було врахувати сили студентів. Потрібно було об’єктивно оцінити їх можливості та розставити пріоритети.

Після довгих дискусій та ресьорчу ми вибрали основні напрямки, на які слід було звернути увагу:

• Онлайн-редактор коду, щоб студенти та викладачі могли прямо в системі створювати та правити свої проєкти
• Максимальна незалежність від мови реалізації проєкту
• Можливість збирати та запускати проєкти
• Легкість розширення та масштабування
• Реалізація ролей вчитель/ студент та відповідного функціоналу для кожної з них та їхня взаємодія

Після визначення основних напрямків почався період підготовки: створення початкової архітектури, розробка дизайну та написання специфікації проєкту.

Паралельно ми з нетерпінням чекали зустрічі та знайомства з нашими студентами. (Псс.. ми також хвилюємося перед першою зустріччю, як і вони). І ось, етап проєктів почався. Ми познайомилися і потроху почали налаштовувати процеси в команді: призначили щоденні мітинги, роздали перші таски, почали привчати студентів до роботи в команді.

Складнощі початківців у роботі над проєктом

Як завжди перші складнощі виникли з фронтендом. На .NET напрямку таке зустрічається часто, адже зазвичай студенти, які навчаються на ньому, в більшості працюють з бекендом і завжди зарікаються, що фронтенд не чіпатимуть. Spoiler alert: до кінця проєкту майже всі з ним потоваришували і почали показувати гарні результати. З бекендом справи йшли краще — тут студенти відчували себе впевненіше і сміливо бралися за важкі таски.

Наступна проблема полягала в командній роботі, адже більшість зі студентів до цього ніколи не працювала з кимось в парі, а тим більше з групою людей. Часто виникали конфлікти (на щастя, тільки в коді 😜), труднощі під час роботи з чужим кодом. Проте після першого тижня спільної роботи потрохи процес почав налагоджуватись і студенти почали розуміти, що так працювати навіть веселіше.

Пісочниця та нюанси її реалізації

Робота йшла. Коли базові сторінки (сторінки зі списком проєктів, опублікованих аплікейшинів, профіль користувача і відповідні сторінки для CRUD операцій над ними) були виконані, ми взялися за реалізацію основного функціоналу. Ідея полягала в тому, щоб зробити нашу реалізацію максимально універсальною та легко розширюваною.

Базові сторінки вебплатформи Codi

Працювало це все наступним чином. Користувач міг самостійно створити проєкт або завантажити вже існуючий з GitHub, попередньо прив’язавши свій акаунт. В момент створення ми зберігали всі файли та структуру проєкту в MongoDB. Коли користувач починав збірку проєкту, ми витягували збережену структуру з усім її змістом і відтворювали її на своєму сервері. Потім, в залежності від мови, якою був написаний проєкт, ми створювали Dockerfile на основі вже існуючих темплейтів та розміщували його у відповідному місці. Функція цього файлу полягає в тому, щоб сказати Docker-у, як збирати образ, на основі якого надалі буде створено контейнер. Завершальним кроком було підняття контейнера і вуаля — проєкт зібраний.

Але тут нам спало на думку, що було б добре дати користувачу можливість не просто зібрати проєкт і побачити сповіщення про успішне виконання, а і дати змогу взаємодіяти з ним в реальному часі. Тобто якщо проєкт містить вхідні дані (як часто буває з консольними додатками) або вихідний результат, то ми хотіли дати користувачу їх ввести в потрібний момент часу, або побачити процес виконання програми завдяки поступовому виводу вихідних даних.

Для цього ми додали Notification Service, який використовує SignalR — бібліотеку, що допомагає реалізувати real-time спілкування. Вона працює на основі вебсокетів та надає можливість миттєво відправляти дані до підключених клієнтів у міру доступності сервера, не змушуючи користувача весь час обновляти сторінку, щоб побачити актуальні дані.

Після додавання нового сервісу виникло питання про те, як ефективно опрацьовувати сповіщення та знизити можливість їх втрат до мінімуму, адже приходити можуть десятки, а то і сотні сповіщень за короткий проміжок часу. Рятівниками в цій ситуації стали черги, які взяли на себе цю роботу. Ми додали чотири черги. Дві з них відповідали безпосередньо за процес доставки даних, що потрібні для підняття контейнерів та відсилання повідомлення про успішне виконання задачі. Дві інші працювали з вхідними та вихідними даними, з якими вже напряму взаємодіє користувач. Черги допомогли нам розвантажити сервіси та дозволили їм брати нові завдання в міру їх виконання.

У користувача, завдяки чергам, з’явилася можливість займатися чимось іншим, поки йде процес, і не чекати відповіді сервера з неможливістю взаємодіяти з рештою сторінок.

В результаті в нас вийшла така архітектура:

Архітектура проєкту Codi

Перші результати

Через деякий час ми вже мали першу робочу версію, яка охоплювала можливість редагування коду, його збірку та виведення результату користувачу. В процесі розробки виникали ускладнення, адже Docker і так забирає досить багато пам’яті, а в нашому випадку це була пісочниця в пісочниці. Часто ми мали не один, а декілька контейнерів, піднятих в один і той же час.

Одним словом, кипіла не тільки робота, а і все поряд 😅. Через це в студентів виникали питання, для чого нам взагалі знадобився Docker, але розібравшись в ньому детально, вони зрозуміли всі його основні переваги. Docker допомагає ефективніше використовувати систему і ресурси, швидко розгортати готові програмні продукти, а також масштабувати їх та переносити в інші середовища зі збереженням стабільної роботи. Часто траплялося, що на одному середовищі щось працює, а на іншому ні. В більшості випадків Docker вирішує таку проблему.

Ну, і останнє, але не за важливостю: завдяки Docker-у можна не встановлювати весь потрібний софт чи пакети безпосередньо на машину, а зробити це в контейнері і, за потреби, однією командою позбутися цього всього. Саме ці переваги нам і були потрібні, тому використання Docker-а і виглядало таким доречним.

Вебплатформа Codi

Фінальне демо та неочікувані складнощі

І ось він, момент істини — переддень фінального демо! Ми заливаємо останні зміни, які б мали покращити наш процес збірки, і, хто би міг подумати, — наш сервіс упав! Ми в паніці починаємо розбиратися, шукати проблему, і вже посеред ночі знаходимо рішення, що дало нам змогу успішно презентувати наш продукт.

Проблема полягала, як зазвичай це буває, в комунікації між контейнерами. Виявилося, що сервіс, який був піднятий у контейнері, працював на невірному порті, через що ми і не могли достукатися до нього. Ідентифікувавши цю проблему, ми з легкістю нагуглили вирішення.

Вся ця пригода коштувала нам однієї (а то і не однієї) безсонної ночі та декількох сивих волосин, але вона була того варта! Студенти залишилися задоволеними виконаною роботою. Вони змогли попрацювати з новими, раніше не відомими технологіями, знайти нових друзів та, що не менш важливо, отримати проєкт, який не соромно додати у портфоліо. Як результат, студенти отримали безліч схвальних відгуків.

А від себе я ще б додала, що всім бажаю пережити такий досвід і радо братися за роботу над чимось новим. Адже, тільки виходячи із зони комфорту та стикаючись із чимось раніше незнаним, можна вдосконалюватись і досягати вершин.