Pull to refresh

Comments 19

Классно, поздравляю с выступлением! :)
Мы тоже участвовали в ClojureCup. У нас была распределённая команда: 1 белорус, 1 бразилец и 2 россиянина. Делали вебприложения для решения японских кроссвордов. В целом понравилось весьма, это был мой первый опыт участия в подобных мероприятиях. Опыта с вебразработкой, а особенно с клиентской частью (и clojurescript'ом) почти ни у кого не было, так что все прокачались немного по ходу конкурса.
В конце концов получилось небольшое приложение с базовой функциональностью. Я доволен результатом. С деплоем решили не заморачиваться и на сервере просто запустили приложение через lein run, чтобы не мучаться с uberjar'ом, загрузкой ресурсов и другими сюрпризами.
Страничка нашего проекта тут. Только следуя духу главного сайта clojurecup, который с файрфоксом не очень дружит, наше приложение тоже багованное в файрфоксе.
Мы оба дня сидели все вместе в одной комнате, и нам это очень сильно помогло. Если бы сидели каждый отдельно, то сделали бы раза в полтора-два меньше, мне кажется.
Привет! Я даже зарешал один средний кроссворд в вашем приложение. Работает здорово.

Мы не парились с автоматизацией вообще ничего — никаких хуков, деплой скриптов или еще чего. nohup lein trampoline run работает прекрасно.
Позволю себе рассказать и о нас.
Мы делали CodeNotes — веб-проект для поиска TODO, FIXME и NOTE внутри репозитория на гитхабе с дополнительным функционалом в виде нотификаций для пользователей и markdown-форматированием для найденных туду.
Плюс у нас можно сгенерить классный бейджик со счетчиком туду, который можно вставить в свой репозиторий на гитхабе.
Варианты использования:
1) Таск-трекер типа Jira для маленьких проектов — можно просто писать в коде TODO и FIXME, а потом в веб-интерфейсе легко это все смотреть.
2) В README.md для своего репозитория можно больше не писать отдельную секцию TODO, а можно вставить наш бейджик.

Но самое крутое это спектр используемых технологий. У нас есть веб-сокеты, вовсю используется angular.js, всякие дополнительные штуки типа миграций (чтобы на сервер все можно было переносить без особого труда), MariaDB для SQL, кэширование в памяти при помощи clojure core.cache. У нас сделан миллиард крутых серверных штук, которые в итоге делают так, что среднее время ответа сервера составляет 18ms при том, что сервера расположены в США. Обязательно напишем об этом пост чуть позже :)

А вот здесь за нас можно проголосовать: clojurecup.com/app.html?app=codenotes
Я использовал Angular.js раньше, и ingspree тоже, но ни мне, ни ему не понравилось. Реакт намного лучше :)

Про серверные штуки будет интересно почитать, обязательно пишите :) А в голосовании мы сейчас идём ноздря к ноздре.
Скажи, bleeding edge! У нас тоже веб-сокеты, тоже SQL (гг, опять в моде?), кеширование в памяти с помощью кложурных атомов и миграции моей личной библиотекой, гг.

Надо сказать, что идея мне ваша нравится, но я пока не нашëл у себя репозиторий с TODO/FIXME, что мешает его потестировать. :\
>кеширование в памяти с помощью кложурных атомов
core.cache, тащемта, круче :) Там из коробки TTL-кеш и LRU. Для github API нужен TTL, для бейджей LRU.
Канеша, но PgSQL круче мариидб и cljs на клиенте круче ангуляра! :) Так шо в сумме у нас 1 очко всë круче. :)))
Кстати, спасибо за core.cache. Знал бы о нем раньше — использовал бы вместо одного из атомов.

Ну и буду писать пост о серверной архитектуре Warmagnet, пока свежо.

Если кратко, у нас прикольно получилось с синхронизацией состояния игры между клиентом и сервером. Есть общий код игровой логики, который принимает «мир» и мутирует его с помощью входящих действий. Любые действия игроков отправляются на сервер, тот их проверяет, изменяет локальное состояние и рассылает эти же действия всем клиентам смотрящим игру. Те уже применяют действие к своим локальным состояниям. Ну и поскольку на сервере хранится мастер копия, то реконнект клиента очень простой — тот просто получает готовое состояние игры сразу, ну а потом инкрементальные апдейты. Вся логика мутаций мира общая на клиенте и на сервере с помощью crossover (https://github.com/emezeske/lein-cljsbuild/blob/master/doc/CROSSOVERS.md)

По сути, получилось что-то типа node.js — возможность написания общего кода между клиентом и сервером, но clojure и в функциональном стиле.
Да, действительно. Если это чуть усугубить, получится полурешётка, CRDT и eventual consistency :)
Eventual им не надо, им strong надо, иначе придется состояния мира мержить. Вообще для таких штук надо что-то универсальное уже запилить, у меня в работе тоже постоянно возникает желание раздать всем нодам общее видение какой-то части мира. Надо учесть что браузер тоже может быть нодой.
Видел ваш project.clj, выносит мозг конечно. У нас попроще:

[org.clojure/clojure «1.5.1»]
[clj-oauth «1.4.0»]
[http-kit «2.1.10»]
[ring/ring-core «1.2.0»]
[compojure «1.1.5»]
[org.clojure/data.json «0.2.2»]
[org.clojure/clojurescript «0.0-1889»]
[prismatic/dommy «0.1.1» :exclusions [crate prismatic/cljs-test]]

и даже вебсокетов нет :(
А как в clojure узнают про выход новых версий? В файле проекта все гвоздями прибито ведь.

В node.js, например npm install, и все наглядно
А что, в ноде версии библиотек не указываются, и оно само может обновиться и всё сломать нафиг?
Можно зафиксировать версии для всего дерева зависимостей при желании
[~/Dropbox/ws/kick] lein ancient
[clj-oauth «1.4.1»] is available but we use «1.4.0»
[http-kit «2.1.11»] is available but we use «2.1.10»
[org.clojure/data.json «0.2.3»] is available but we use «0.2.2»
[org.clojure/clojurescript «0.0-1909»] is available but we use «0.0-1889»
[prismatic/dommy «0.1.2»] is available but we use «0.1.1»
Да в общем-то всё по делу :) Не ожидал, конечно, что так много получится.
Sign up to leave a comment.

Articles