Моє незабутнє літо або як ми створювали аналог Spotify за сім тижнів

Привіт! Я Шевчук Кирило, студент другого курсу на факультеті кібернетики в КНУ та .NET developer у Binary Studio. Нещодавно я закінчив Binary Studio Academy на треку .NET і хотів би поділитись, чому навчився, які уроки виніс для себе та який проект вдалось створити під час Академії.

Коротка передісторія

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

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

Perflow  музичний сервіс

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

Загалом наш сервіс можна розділити на декілька мініпроектів.

Perflow — основний продукт для звичайних користувачів, де можна слухати музику. Там можна зареєструватись, створити плей-листи, надсилати їх друзям. Практично все, що є в Spotify в десктопному додатку, було й у нас.

Perflow Studio — це друга частина нашої платформи, яка орієнтована на артистів. Тут можна завантажувати свої альбоми, також є функціонал для модераторів. Модератори можуть фільтрувати артистів, створювати глобальні плейлисти, наприклад «Рок 2021» і додавати туди різні пісні.

Третім підпроектом є мобільний додаток. Він містить більш обмежений функціонал, ніж десктопна версія, але має одну особливість — можливість розпізнавати музику і визначати яка це пісня, тобто аналог Shazam.

Трохи про архітектуру та функціонал

Фронтенд нашого проекту складається з веб додатку на Angular із застосуванням Semantic UI, і мобільного додатку на Flutter. Обидва ці застосунки використовують Firebase Auth, що дозволило нам швидко реалізувати необхідний функціонал автентифікації як у вебі, так і на мобайлі, і додати можливість логіну з акаунтів Google, Apple і Facebook.

На бекенді маємо два RESTful сервіси: Perflow і Perflow Studio, які об’єднані за допомогою Ocelot API Gateway. Обидва сервіси використовують SQL Server як основну базу даних і Azure Blob Storage для зчитування файлів пісень і зображень. Збереженням файлів займається окремий Processor сервіс, який отримує повідомлення через RabbitMQ і обробляє їх перед збереженням.

Архітектура проекту Perflow

Нам вдалося реалізувати величезну кількість різних фіч, і я хотів би розказати трохи про реалізацію деяких з них. Для синхронізації програвача між різними пристроями, а також для одночасного прослуховування музики (аналог Apple SharePlay), ми використовували SignalR, який також дозволив нам реалізувати відправку сповіщень про нові релізи артистів. Як я згадував раніше, обробкою аудіо файлів займається Processor сервіс. З кожного нового треку, використовуючи ffmpeg, він створює 4 файли з різними рівнями якості звуку, а також генерує fingerprint, який потім зберігається у спеціальному сховищі, і використовується для розпізнавання музики нашим аналогом Shazam.

Насправді в нас вийшла досить цікава історія з розробкою Shazam. Загалом на створення проекту в нас було 7 тижнів. План був таким, що 5-6 тижнів ми додаємо функціонал, а в останній тиждень ми лише виправляємо баги. Отож, на сьомому тижні ми вже всі розслабились, а в одного з наших коучів з’явилася ідея додатково розробити фічу для розпізнавання треків. Писали ми її буквально в останні дні. Пам’ятаю, як за дві години до фінального демо ми ще підправляли деталі. Смішно, що протягом семи тижнів ми старались не робити змін на платформі, через які вона могла б лягти, а тут запуск власного Shazam в мобільному додатку міг нам все зіпсувати. В цілому наше демо зайняло близько 30 хвилин, адже в нас був доволі великий функціонал та багато що показати.

Функціонал та стек технологій проекту Perflow

Уроки винесені з Академії

Урок 1. Не лякатись, якщо не знаєш технологію

Раніше я думав, що найважливіше у розробці — круто розбиратись в технології чи фреймворку. І сам факт знання є супер важливим. Звичайно, досвід вирішує дуже багато, але 90% з того, з чим я працював на проекті, було новим. Ми працювали з Entity Framework Core, MSSQL, Azure Blob Storage, Firebase, Dapper, MediatR Ocelot API Gateway, SignalR, RabbitMQ, ffmpeg, Angular, Semantic UI, SASS. Про більшість з них я навіть не чув раніше, тому реально доводилось розбиратись з новою технологією з нуля.

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

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

Урок 2. English matters

Кожного тижня у нас були демо дзвінки з Product owner-ами англійською мовою. Це були працівники Binary Studio, але вони виступали як PO на проекті й нам потрібно було показати результат нашої роботи. Це було досить корисно, але й складно водночас. Інколи українською важко пояснити навіщо зробили ту чи іншу фічу, і як вона допоможе бізнесу. А тут ще й англійською. Спершу було незвично, тому що граматику я ніби й знаю, але з розмовними навичками все складніше. Однак в майбутньому, щоб працювати з іноземними клієнтами потрібно обов’язково прокачувати свою англійську.

Урок 3. Quality vs Quantity

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

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

Урок 4. Найкорисніше — це фідбек

Раніше я проходив декілька курсів, але ніколи не було менторів, які так швидко відкликались й так допомагали. Ще на етапі відбору, коли були лекції і домашні завдання, я постійно отримував розгорнутий відгук по своїй роботі — де зробив щось не так і як це виправити. Пам’ятаю, як в перший тиждень отримав велику кількість правок і весь день розбирався з ними.

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

Урок 5. Розвивайте софт скіли

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

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

Висновки

Це було найпродуктивніше літо за все моє життя. Хоч і були моменти коли я хотів все кинути, не було сил продовжувати, але потім збирався духом і працював далі. Результат був того вартий. Я б радив спробувати свої сили в Академії тим, хто хоче інтенсивного навчання, готовий прийняти цей виклик та хто дійсно хоче розвиватись і отримати ґрунтовні знання за короткий час. Не бійтесь пробувати! Воно справді того варте.

👍ПодобаєтьсяСподобалось8
До обраногоВ обраному4
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

1. Чудово написана стаття
2. Неймовірно крутий досвід
3. Бінарі Студіо красавчики
4. Майбутнє в України стає світлішим від таких проектів

Оце якраз і є продуктовий майндсет та T-shape інженери, які мають вивести нашу інженерію на новий якісний крок. Лю, молодці!

Блін! Круто!!!!! Красавчікі, це крутий та шикарний прогрес за 7 тижнів

Кирило, зв‘яжісь зі мною будь де) мої контакти є в профілі

Так а сколько человек писало 3 недели ?

Незабутнє літо — це оце www.youtube.com/watch?v=eFjjO_lhf9c
А у вас просто Hackathon довжиною в 7 тижнів.

Боже

Ви ж розумієте, що то тільки ваші проблеми, правда?

як же це скупо...

Мені оте все трогання «Entity Framework Core, MSSQL, Azure Blob Storage, Firebase, Dapper, MediatR Ocelot API Gateway, SignalR, RabbitMQ, ffmpeg, Angular, Semantic UI, SASS» завжди нагадує гру в лотерею. Бац-бац-продакшин-інкубатор-бігом-бігом-вестінг-А-вестінг-Б-о-АйПіО!
І ще гаміфікацію забув — гаміфікація то важливо і не скупо.
Я краще буду скупим і робити цікавіші для мене речі.

На жаль, ваше незабутнє літо залишилось у 1969-ому.

На жаль

На щастя, це, хіба що, для вас.

Потрогали много интересного конечно. Бывает вполне обычная ситуация, когда .NET синиор работает 10 лет со связкой WebForms + SQL Server. А тут куча хипстерских баззвордов.

Скорочу до змісту: «на сьомому тижні ми вже всі розслабились». «наше демо зайняло близько 30 хвилин» — оце і все заради чого воно писалося, не більше.

Та нічо, просто набрався купу досвіду за короткий час і прорекламував академію.

Ну опыт-то на самом деле бесценный, и который из курсов или книжек не вынесешь. Особенно вот это:

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

и что если вкрячивать фичу в последний момент — можно поймать неприятности на презентации.

И очень хорошо, что ребята получили этот опыт не на реальном проекте ценой конфликта с заказчиком.
---
Это, если что, без сарказма было.

Ну опыт-то на самом деле бесценный

Опыт был бы бесценный, если бы весь этот энтити фреймворк работал под нагрузкой в миллион человек хотя бы. И что-то мне подсказывает, что инструменты и архитектуру выбирали не студенты. Опыт это когда ты сам выбираешь инструменты, лажаешь 3 раза подряд, разбираешься почему облажался, а потом на 4-й раз делаешь правильно.

Это вы от Trainee хотите? Студенты пощупали технологии, сделали что-то даже, потренили soft-skills на английском. Почему бы и нет

а може зразу системний дизайн дати їм розробити для гугла чи твітера?)
камон, це ж студенти/трейні, як вже писали

а може зразу системний дизайн дати їм розробити для гугла чи твітера?)

тоже справедливо. как и то, что создатели всех этих гуглов и твитеров даже не знали таких страшных слов как

системний дизайн

*Занудным голосом*
И еще один принцип, дорогие студенты:
Не имеет никакого смысла использовать технологии и подходы систем с миллионами конкурентных подключений в продукте, у которого будет от силы пара сотен пользователей.

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

Я восхищен тем, как вы смогли приплести

совєтським «вот раньше було краще»

к принципу KISS. И очень прошу, покажите где же там у меня в сообщении пессимизм?

Кстати, в списке использованных технологий есть и Dapper (на котором фактически держится современная индустрия разработки ПО), который заметно производительнее EF Core.

Dapper (на котором фактически держится современная индустрия разработки ПО),

Это конечно классный инуструмент, который учится за полдня (респект создателям). Но блин ... Чтоб вся индустрия разработки ПО держалась на нем? Серьезно?
У меня вот прямо сейчас в солюшене открыт такой же самописный «даппер» в проекте, которому уже 17 лет и ничего в нем не меняют уже лет 5 как минимум. Единственно чем он хуже чем Dapper так это тем что работает только с MS SQL, но это потому что другие СУБД на проекте не нужны.

Stackoverflow работает (по крайней мере раньше работал) на Dapper. Это сарказм был.

Підписатись на коментарі