Як минув перший «Спагеті»-конкурс? | robot_dreams
Для отслеживания статуса заказа — авторизируйтесь
Введите код, который был выслан на почту Введите код с SMS, который был выслан на номер
 
Код действителен в течение 5 минут Код с sms действителен в течение 5 минут
Вы уверены, что хотите выйти?
Сеанс завершен
На главную
Написати «лайно» й отримати за це $1000: Як минув перший «Спагеті»-конкурс

Написати «лайно» й отримати за це $1000: Як минув перший «Спагеті»-конкурс

Змагання для айтівців на найдивніший код

У жовтні 2024-го robot_dreams (або як скорочено називає команда — r_d) виповнилося 4 роки з моменту запуску першого онлайн-курсу. Наших студентів лектори вчать, як правильно кодити, уникати помилок, знаходити баги, а не фічі, та багато інших корисних навичок. Тож на честь свята нам захотілося трошки розбавити серйозну атмосферу навчання і розважитись.

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

За умовами змагання кожен учасник мав написати один рядок коду будь-якою мовою програмування та довжиною в 1000 символів. Впродовж двох тижнів ми отримали понад 100 заявок, серед яких до голосування дійшло лише 10 найкращих.

Щоб залучити якомога більше професійної спільноти програмістів до участі та привернути увагу до конкурсу, бренд-команда розробила спеціальний мерч — кастомізоване пиво — разом з українською крафтовою броварнею «2085». Замість звичного дизайну банку прикрасили спагеті!

Фіналістів обрало журі конкурсу в складі експертів з провідних українських IT-компаній та лекторів robot_dreams. Вони оцінювали роботи за декількома критеріями: власна цікава ідея, оригінальність виконання, розв’язання поставленого завдання.

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

— розповідає запрошений експерт журі конкурсу Ігор Фесенко.

На фінальному етапі голосування також провели серед підписників robot_dreams у соціальних мережах (їхні голоси не сумували з балами журі).

То хто ж переміг і як відбувався процес відбору — далі розповідає один із членів журі та Senior Instructional Designer r_d Дмитро Пилипенко.

Про етапи відбору

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

🔘 На першому етапі відбору перевіряли виконання умов конкурсу, а саме:
один рядок коду — не два, не три й уже точно не if-else на двох сторінках. Код має бути не більш як 1000 символів.

🔘 Мова програмування — будь-яка: від Python до Brainfuck. Якщо можете написати це на машинному/двійковому коді — вперед!

🔘 Функціональність — ваш код має працювати.⠀

🔘 Чесність — це має бути ваш код, жодних хакерських трюків.

🔘 Все в одному місці — все необхідне потрібно додати до репозиторію, щоб журі не доводилося щось дописувати за вас!

🔘 Документація — розвʼязок має містити на репозиторії якісну документацію в довільному стилі, але щоб з неї була зрозуміла ідея, формулювання завдання, як скомпілювати/інтерпретувати й виконати ваш код. Також треба додати кілька скриншотів або посилання на відео, в якому продемонстровано роботу вашої програми.

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

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

В умовах конкурсу ми відзначали, чи власну ідею запропонував учасник, чи розв’язував одну із запропонованих нами задач, яких було 5 на вибір.

Про етапи та принципи відбору

Після двох попередніх критеріїв відбору ми дивилися саме в код. Оскільки конкурс «Найкращий Лайнокод» — відповідно, і робота, подана до участі, мала асоціюватися саме з цим.
За відкриття коду в журі мало виникати бажання не те що закрити його, а рубанути тумблер зі світлом і хоча б 5 хв полежати в тиші й темноті. Оце основний критерій! (Сміється).

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

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

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

Про курйози

Курйоз — друге ім’я нашого конкурсу. Було багато цікавих підходів і креативних ідей та рішень, за яких ставив собі запитання, чому саме так людина оформила роботу, й інколи від цього з’являлася посмішка. Наприклад, код у кількох роботах оформляли прямо і тільки в README або текстових файлах. Частенько були випадки, що недотестили, але епічно розписали документацію, а код банально видавав у результаті помилку. Також пригадалася робота, де опис проєкту чомусь розмістили у вордівському файлі замість README. Або робота на генерацію рандомного числа, в якій рандомним числом було те, яке ти ввів через стандартний інпут.

Про переможця

Переглянувши понад 100 робіт, ми відібрали 20 півфіналістів. Запрошені експерти залишили з них 10. Шляхом фінального голосування у соцмережах найкращою за всіма критеріями обрали роботу Artem Vidnik під кодовою назвою Selfie (звук оплесків). 

Натрапив випадково на оголошення про конкурс на DOU — і щойно побачив, подумав: хочу цю статуетку! Концепт конкурсу мені теж сподобався, вирішив спробувати. Завдання виконав під час простою на роботі, але коли взявся тестувати, зрозумів, що дебажити цей хаос доведеться довше. У підсумку доробляв уже вдома. Як же я радів, коли все нарешті запрацювало! Тоді серйозно почав сподіватися на перемогу — і виграв! Тепер планую інвестувати виграш у курс із highload-архітектури або мікросервісів, а статуетка стоятиме біля монітора в офісі. Нехай колеги бачать, з ким мають справу!»

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

Ещё статьи
Порівнюємо швидкість, якість і відповідальність за результат