@nicola: я вот кстати на эти все либы смотрю и думаю, что nesting всë-таки тяжело иногда читать

с одной стороны DRY, с другой - читать проще плоский список урлов

а-ля джанга там, или веркцойг

ну в том же биди, кстати, никто не мешает делать плоский список

@asolovyov: Зато нестинг можно легко разбить на части - сделать что-то вроде модулей со своим роутингом и потом композировать

можно написать сплющиватель роутов на чтение - что бы он дерево в виде списка представил

@asolovyov: А отладочной вьюшки со всеми URL'ами недостаточно?

@nicola: не, ну я больше про мой экспириенс как разработчика, а не про представление в памяти - это как раз меня мало беспокоит

@dottedmag: ну а смысл? Если их удобно редактировать, то и вьюха не нужна

@nicola: а include сделать тоже не проблема

но это я так, ни к каким действиям не призываю

@asolovyov: Редактировать и глазами просматривать - это разные деятельности, всё-таки.

c route-map ты не include делаешь а вкладываешь один роутинг в другой - наследуя по пути мета-данные

что-то вроде mount в файловой системе

@dottedmag: хочу, чтоб редактировать было удобно

@nicola: да, я понимаю

Я обчно складываю роуты рядом с каждым модулем - и там они не глубокие получаются

Господа, а есть какой кложурный враппер для java.io.File?

Не хочется делать пачку (defn is-dir [x] (.isDirectory x)) (defn is-file [x] (.isFile x)) ...

Ага, [me.raynes/fs]

А вот ещё. Мне нужно отпроцессить 100500 файлов. Из них 2-3 тысячи нужно прочитать, а остальные только stat-ать. Какие прочитать - определяется в процессе работы: есть пачка правил "если файл такой, то скипнуть, если такой, то туда, если такой, то сюда, а если вот такой, то надо бы почитать содержимое".

Как это организовать? Заранее читать - мееедленно.

Читать во время обработки правил, которым нужно содержимое - тоже медленно, их может быть десяток на такие файлы.

Делать Var, в которой держать содержимое текущего файла, если оно прочитано? Криво как-то.

Так что вопрос - как организовать local shared mutable state, либо как организовать ленивость.

Ммм, завернуть чтение в delay, а читать с помощью @?

А что state-то?

В смысле непонятно, какой стейт нужно хранить.

То есть описание процесса понятно, но судя по описанию никакого стейта и нет

я думаю, что в стейте нужно хранить отработанные файлы (??). я бы взял список всех файлов (типа того http://stackoverflow.com/questions/2056221/recursively-list-files-in-java) и в core.async pipeline зафигачил.

это если на одной тачке делать.

Стейт - это содержимое файлов.

Вот есть у меня 100500 файлов, я читаю их метаданные с диска.

Для небольшого подмножества нужно прочитать ещё и содержимое, и несколько раз его обработать.

Но это подмножество я заранее не знаю.

Решил это, положив Delay в данные.

Этот Delay при обращении читает файл.

Сложи в базу свой state ;)

Это CLI-утилита, зачем ей база?

embedded (datomic || datascript)

Т.е. "загони мутабельность в базу". Нафига?

Ничем не лучше Var

Потом сможешь инкрементально перепроцешивать, делать выборки ;)

Я и сам могу безо всякого датомика написать (set! mystate (assoc mystate key val))

Некоторые базу даже в браузере поднимают а у тебя 100k файлов - сам бог велел

это каждый раз разные 100k файлов.

@dottedmag: обязательно в браузере это делать?

@a.espolov: Эээ. Кто сказал про браузер?

"Некоторые базу даже в браузере поднимают а у тебя 100k файлов "

оказалось это как пример

сорян

Господа, я уже решил задачу :)

Достаточно оказалось вспомнить, как это делается в Haskell.

Заманиваю @yogthos к нам в hangout в понедельник - http://webmeetups.net/meetups/78

@nicola: about 14:00 mine time, so might be at work then

your time is?

-5 utc, in Toronto

btw russian is fine, just can’t write 😛

Тебе нормально в 14:00 или лучше подвигать?

let’s move to an hour to 15:00

ok

perfect

@yogthos: вижу репку про pulsar. используете как-то его?

just some toy projects

Пишем сейчас прототип платформы для медицинских устройств: придумалась полностью message-driven архитектура: между всеми участниками есть одна большая очередь (ориентировочно kafka), все HTTP запросы, сокеты устройств, web-socket, email, sms и т.п. превращаются в сообщения в очереди - ответы и нотификации это тоже специальные очереди, преобразующиеся в соответсвующие протоколы. А дальше полная свобода - например цикл request-response моделируется двумя очередями - входной и выходной и обработчики, которых может быть сколько угодно, занимаются перекладыванием данных из одной очереди в другую. На фронте есть входящий и исходящий поток - причем обработчик входящих сообщений полностью отвязан от запросов - те потенциально умный сервер может прислать ответ и без запроса - или вообще управлять состоянием фронтового клиента.

вопросов много - но прототип выглядит интересно

http://wamp.ws/

Похоже на "The Technology Altar" отсюда: http://www.infoq.com/articles/SOA-anti-patterns

всем уже нужен real-time - это как раз о нем

Что, настоящий hard realtime?

ну вот kafka например совсем не реалтайм )

там pull-интерфейс исключительно

@prepor - те все клиенты пулят? или long-pollят?

пулят, пуш-интерфейса в кафке нет

чего-то похожего на лонг-поллинг тоже. и вряд ли появится, ибо кафка все же немного не для этого

ну т.е. у кафки нет задачи минимизировать лэтенси в масштабах миллисекунд

а какой лэтенси и нагрузка достижимы с kafkoй на poll? x*10 ms ? я пока только с записью поигрался - там реально быстро.

он же кластеризуется

смотря какой ты клиент используешь. стандартный хай левел консьюмер — полное говно ). но в целом код выглядит примерно так: 1. достать 100кб сообщений. 2. если есть сообщения обработать, если нет то подождать 100мс. 3. повторить 1. т.е. если есть поток сообщений постоянный оверхеда по летенси особо не добавится.

ну и у меня есть православный кафка-клиент с собственной кластеризацией, правильным апи на кор асинке и правильной работой с оффсетами. конечно, с полным отсутствием документации )

https://github.com/prepor/clj-kafka/blob/master/src/ru/prepor/clj_kafka/elastic.clj

точнее комментарии есть какие-то НА РУССКОМ, шеймон ми

ага спасибо, буду ковырять

Смотрю в кафке есть long-poll

@nicola: покажи ) вот настройки реквеста https://github.com/kafka-dev/kafka/blob/master/core/src/main/scala/kafka/api/FetchRequest.scala

в нем ничего кроме “максимум 100кб” нет, как я и говорил

http://www.4byte.cn/question/401501/kafka-long-polling.html

что за китайские сайты ты читаешь? )

в общем вот тут пишут что таки оно умеет как лонг поллинг работать https://cwiki.apache.org/confluence/display/KAFKA/A+Guide+To+The+Kafka+Protocol#AGuideToTheKafkaProtocol-FetchRequest, но в интерфейсе клиента я этого не вижу, надо смотреть реализацию

а, да

окай

лонг полится через конфиг!

я кстати фиг знает как такой интерфейс на латенси отразится. но вроде все, что латенси ориентировано все таки не полинг использует, а пушает в сокет пока получается (а то и вовсе через удп работает). aeron например https://github.com/real-logic/Aeron

Основная фишка kafka - работа batchами - поэтому возможно под нагрузкой с латенси все будет ок - надо проверять

основная фишка кафка это таки производительность, фейловер и стронг ордеринг

ну т.е. в лоу латанси системах я не слышал что бы ее кто-то использовал, но можно погуглить