Party hard по-программистски, или как мы писали ClojureCup 2014

    В минувшие выходные Clojure-сообщество испытывало… Ой, так начинался прошлогодний пост с отчётом о прошедшем ClojureCup 2013.

    ClojureCup — это 48-часовой онлайн-хакатон, обязательным условием которого является написание приложений на языках Clojure/ClojureScript. В этом году в хакатоне участвовало около 50 команд (в каждой по 1-4 человека), которые сделали множество классных приложений.

    Приложения оценивают как жюри (известные в Clojure-сообществе люди), так и обычные пользователи: зайти с помощью twitter-а и проголосовать за понравившиеся вам приложения можно на странице приложений.

    А попробовать, что у нас получилось, можно вот тут.



    Осторожно: под катом много картинок.


    Идея


    Идея поучаствовать в ClojureCup появилась у меня достаточно давно, но лень сделала свое дело, и спохватился я о сборе команды лишь за три дня до начала хакатона (как оказалось, за два дня до хакатона нужно было сформировать команды). Однако этот мир оказался не без программистов, желающих потерять свои выходные, для того чтобы написать что-нибудь на странном языке со скобочками. Тут нужно дополнительно упомянуть, что никто из нас сколько-нибудь серьёзно на Сlojure не писал, а двое и вовсе не писали. И да, все четверо были программистами.

    Изначально в качестве проекта было желание делать странную-штуку-для-статических-сайтов (одна из команд сделала что-то немного похожее в итоге), но возникли большие вопросы в нужности результата.

    В итоге мы сформировали критерии выбора идеи: что-нибудь понятное сразу и для простого юзера.
    От таких критериев мы быстро пришли к идее сделать какую-нибудь игрушку. И тут вспомнилась прекрасная Puzzle Bobble:


    Это пазл с очень озорным режимом P2P: чем больший кусок шариков ты собьёшь группой, тем больше этих самых шариков придёт ко врагу. Так мы сосредоточились на поиске игры, к которой можно было бы прикрутить механику “сделать противнику неприятно”.

    Думали и о тетрисе, и о 2048, но потом вспомнили Rocket Mania!


    Так, ночью, за два дня до начала, родилась идея приложения: двое игроков будут играть в упрощённый вариант Rocket Mania!, но количество ракет будет ограничено и они будут улетать к врагу, а чтобы игра точно когда-нибудь закончилась, у них будет топливо, которое при каждом перелёте уменьшается, а в конце ракета будет улетать в вечность космос.
    На тот момент игра должна была быть с классной графикой и возможностью играть по сети, но когда ночью в пятницу мы начали прорабатывать идею, внеслось два изменения: решили выкинуть игру по сети и поддержать только режим hotseat (помните, был такой в героях, когда два игрока за одним компьютером), а также использовать flat design, потому что так проще, а среди нас одни программисты =)
    Это были очень правильные решения: нужно выбирать целями то, чего реально можно достичь. Упрощать-упрощать-упрощать.
    image

    Как и опыта в Clojure, опыта в функциональном стиле программирования у нас не было. Но тут мы решили брать функциональную парадигму по полной: каждое наблюдение мира — неизменяемо, функции чистые, и т.д. и т.п. В итоге в нашей архитектуре был один “атом мира”, состояние которого однозначно задавало то, что на экране, и изменением которого мир менялся. Также мы решили использовать react.js (это было очень правильное решение) и обертку над ним quiescent (а это неправильное, но терпимое). Сейчас мне кажется, что нужно было глядеть на phaser, но тогда такой мысли не возникло. Кстати, на phaser-е другая команда сделала весёлую игру с котами!

    Тем временем время подошло к 4 утра, начался ClojureCup, а мы пошли спать. Один из членов команды (живущий в другом часовом поясе) в это время поднял сервер и запустил туда заглушку с ракетой Элона Маска:
    image

    Реализация


    Приложение очень хорошо разделилось на части: кто-то пилил чисто игровую логику, кто-то отображение игрового поля, кто-то занимался обработкой клавиатуры. Почему-то активного использования терминального REPL-а у нас не случилось, а вот figwheel — решение для автоматической перекомпиляции ClojureScript кода с hot reload-ом кода в браузере — был очень кстати и очень-очень упрощал нам жизнь. Тут надо заметить еще один интересный момент: состояние мира хранилось в неперезагружаемом атоме, поэтому даже после перекомпиляции приложение оставалось в том же состоянии, что и было до. Из минусов можно отметить то, что у нас время от времени слетала инкрементальная компиляция, приходилось делать полный ребилд.

    Вначале мы хранили сгенеренный код в репозитории, поэтому у нас получились волшебные числа в десятки тысяч изменённых строк кода, при итоговом размере порядка 1К строк кода.

    Из неприятных запар у нас случилось две:
    • первая была связана с тем, что quiescent очень странно решал, какие части страницы нужно обновлять, а какие нет; в тот момент я научился вставлять отладочный вывод в сгенеренный JS-код и даже понимать что там нагенерено,
    • вторая была по всей видимости багой ClojureScript компилятора: правильный код компилировался, но потом не работал.


    Во время реализации игровой логики перед нами встала задача масштабного глубокого изменения immutable состояния мира. В итоге было придумано решение, как потом оказалось, с точностью до сигнатуры совпадающее с решением из стандартной библиотеки =) Мораль: изучайте хоть немного инструменты, которые будете использовать. И перед тем, как делать что-то своё, посмотрите: не сделал ли это кто-нибудь другой?

    А ещё мы не знали, как сделать изменяемое состояние в Clojure (функциональщики поневоле), это родило такой монолог:
    жутко бесит меня кложур, чтоб я ещё раз на нём кодил; зачем нужен этот язык, если его невозможно читать, а чтобы что-то нормальное писать, нужно всё равно выходить из концепций языка.

    В итоге изменяемым состоянием мы пользоваться так и не научились, но заиспользовали loop.

    В конце первого дня у нас уже была что-то показывающая версия приложения, а за 3 часа до конца хакатона — уже более-менее полноценная работающая версия игры. В последние 3 часа мы добавили в игру звуки (тут от функциональной парадигмы пришлось отказаться и появились методы вида play!) и очень сильно отполировали UI.

    За часа 2 до конца у нас упал сервер, и оказалось, что игра раздавалась встроенным python-сервером из коробки. Быстро подняли nginx и были рады.
    За полчаса до конца я открыл приложение в Сафари, и оказалось, что оно там вообще неработоспособно (поворот блоков не работал).
    За 15 минут до конца у нас никак не хотел работать звук для победы (видимо, снова была проблема с компилятором ClojureScript-а), это всё заметно добавило адреналина.

    Так что даже имея за 3 часа более-менее работающую версию, последние минуты мы провели в запаре.

    А вот и этот самый момент, когда мы затегали релизную версию и получили три зелёных галочки, означающие, что всё необходимое мы сделали =)
    image

    Вместо заключения


    image
    У нас получилась, хотелось бы верить, весёлая игра на двоих. А даже если и не получилась — мы получили огромное количество веселья и не меньшее количество опыта. Вот тут можно смотреть исходники проекта, а тут при желании проголосовать.

    Список проектов, упорядоченных по текущему положению в публичном голосовании, можно посмотреть здесь и здесь. Советую посмотреть на эти списки: среди проектов есть очень и очень приличные, весёлые и полезные.

    За этот год уже можно почитать отчёты Александра Соловьёва (вы его можете знать по этому замечательному выступлению про FRP и Clojure), команды проекта Funstructor, а также Milestones.

    Отдельно хочется сказать спасибо Александру Соловьёву ingspree и Никите Прокопову tonsky за поддержание интереса к Clojure на высоком уровне, а также Дмитрию Грошеву si14, Николаю Рыжикову и Михаилу Лапшину за проведенный workshop по clojure в компании JetBrains.

    Также огромное спасибо Юле Беляевой juliette, Серёже Серебрякову megaserg и Андрею Сиунову fandes за прекрасную компанию на этом хакатоне. Хакатонить в прекрасной компании — прекрасно!

    Similar posts

    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 11

      +2
      Пожалуйста :)

      Надо сказать, у вас круто получилось, даже не верится что столько можно сделать без опыта в Кложе.
        0
        > Надо сказать, у вас круто получилось, даже не верится что столько можно сделать без опыта в Кложе.

        То же самое хотел сказать. :) Очень круто вышло.
        0
        жутко бесит меня кложур, чтоб я ещё раз на нём кодил; зачем нужен этот язык, если его невозможно читать, а чтобы что-то нормальное писать, нужно всё равно выходить из концепций языка.
        В итоге это мнение поменялось, или действительно всё так и есть — сложно читать и приходится входить из концепций языка в реальном мире?
          0
          В реальном мире цель работы программы — это менять свое состояние и состояние вокруг, т.е. сайд-эффекты. Кложа прагматичный язык, и не пытается этот факт скрыть или как-то пристыдить, в ней все нормально и с императивными конструкциями, и с мутабельным состоянием. Т.е. всё что есть в обычных языках тут тоже есть. Но, у них даже более удобные и безопасные конструкции для работы с ним предусмотрены помимо обычных get/set! (напр., atom-ы). Концепция языка предполагает, впрочем, что работа с мутабельным состоянием делается редко и явно. Это особо не усложняет программирование, но программа получается проще в понимании и надежней.
            0
            > Это особо не усложняет программирование, но программа получается проще в понимании и надежней.

            С другой стороны, привычки приходится ломать прилично.
              +1
              Да, но in a good way. Потом обратно уже не хочется.
              0
              У нас была проблема незнания идиом того как работать с мутабельным стейтом в кложе. А об использовании атомов что-то мы не подумали =)

              Но вот представление всего состояния программы в одном немутабельном состоянии общую логику сильно упростило на мой взгляд.
            0
            > обертку над ним quiescent (а это неправильное, но терпимое)

            Забыл спросить, а чего неправильное-то? А то мы тоже его взяли и я в принципе доволен.
              0
              Там ссылка на коммит есть =)

              Ну и как оказалось (написали в комментах к коммиту) это была проблема вида RTFM: все аргументы кроме первого не учитываются quiescent-ом для re-render-а, они там называются static arguments. Как мне кажется странное решение, и не то чтобы это было нужно.

              Еще из немного неприятного: по +- понятным причинам слетала поддержка резолва аргументов в IDE. Можно было наверное вручную раскрывать макросы, но не сделали.

              А вообще как чисто решение для state->view над реактом — quiescent приятен.
                0
                А, статики да, спорная идея. Мне еще не хватает children'ов в нормальном синтаксисе, хоть бери и форкай, а то чувак подзабил как-то.
                  0
                  Я вообще не понял зачем они нужны, ведь если они не меняются, то и rerender-а не будет? Зато передавать нескольких аргументов мапой/вектором приходится. Странно.

                  И чилды нужны, так что реально форкать надо =)

            Only users with full accounts can post comments. Log in, please.