Fork me on GitHub
#clojure-russia
<
2015-09-18
>
asolovyov08:09:33

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

asolovyov08:09:54

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

asolovyov08:09:02

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

ul08:09:47

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

niquola08:09:53

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

niquola08:09:28

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

dottedmag08:09:29

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

asolovyov09:09:42

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

asolovyov09:09:59

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

asolovyov09:09:12

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

asolovyov09:09:24

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

dottedmag09:09:39

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

niquola09:09:06

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

niquola09:09:00

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

asolovyov09:09:16

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

asolovyov09:09:20

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

niquola09:09:46

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

dottedmag09:09:05

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

dottedmag09:09:00

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

dottedmag09:09:14

Ага, [me.raynes/fs]

dottedmag09:09:16

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

dottedmag09:09:29

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

dottedmag09:09:53

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

dottedmag09:09:09

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

dottedmag09:09:16

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

dottedmag09:09:51

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

kharus10:09:18

А что state-то?

kharus10:09:35

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

kharus10:09:18

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

konukhov10:09:59

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

konukhov10:09:22

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

dottedmag10:09:56

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

dottedmag10:09:14

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

dottedmag10:09:32

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

dottedmag10:09:38

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

dottedmag10:09:11

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

dottedmag10:09:22

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

niquola10:09:37

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

dottedmag10:09:47

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

niquola10:09:38

embedded (datomic || datascript)

dottedmag10:09:50

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

dottedmag10:09:08

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

niquola10:09:38

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

dottedmag10:09:06

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

niquola11:09:23

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

dottedmag11:09:43

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

a.espolov11:09:18

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

dottedmag11:09:27

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

a.espolov11:09:46

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

a.espolov11:09:53

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

dottedmag11:09:03

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

dottedmag11:09:25

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

niquola14:09:42

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

yogthos14:09:53

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

niquola14:09:15

your time is?

yogthos14:09:45

-5 utc, in Toronto

yogthos14:09:02

btw russian is fine, just can’t write 😛

niquola14:09:32

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

yogthos14:09:14

let’s move to an hour to 15:00

prepor14:09:00

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

yogthos15:09:52

just some toy projects

niquola15:09:50

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

niquola15:09:43

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

dottedmag15:09:07

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

niquola15:09:03

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

dottedmag15:09:45

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

prepor15:09:46

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

prepor15:09:56

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

niquola15:09:50

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

prepor15:09:12

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

prepor15:09:43

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

prepor15:09:34

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

niquola15:09:12

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

niquola15:09:05

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

prepor15:09:44

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

prepor15:09:15

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

prepor15:09:56

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

niquola16:09:34

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

niquola18:09:49

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

prepor19:09:20

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

prepor19:09:26

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

prepor19:09:23

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

prepor19:09:58

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

prepor19:09:46

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

niquola20:09:47

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

prepor20:09:39

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

prepor20:09:19

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