Oℕ
нужно установить вообще любой sbt
Size: a a a
2021 January 19
Oℕ
любым образом
S
нужно установить вообще любой sbt
начиная с
0.13, кажется. Так что не совсем любой. Подозреваю, что в каком-нибудь допотопном дистре таки можно найти достаточно старый sbt.Oℕ
возможно, кажется, когда были такие старые СБТ, СБТ официально ставился шел скриптом, который жарник скачивал
EB
возможно, кажется, когда были такие старые СБТ, СБТ официально ставился шел скриптом, который жарник скачивал
на гитхабе много проектов этот шелл скрипт прям вкомичивают
EB
а оказывается это дремучий подход
S
возможно, кажется, когда были такие старые СБТ, СБТ официально ставился шел скриптом, который жарник скачивал
Может быть, но у меня была версия < 0.13 в виде пакета в системе.
S
а оказывается это дремучий подход
gradle считает, что подход - самое то
Oℕ
я правильно понимаю, что скрипт градла ещё ищет gradle и gradlew локально?
S
Дока рекомендует запускать ./gradlew - не помню что будет, если запускать gradle при наличии враппера, но, кажется, локальный враппер игнорируется.
e
Согласна, по-хорошему подтверждение-отбивка должна быть, добавим в нотификацию.
дизайн хороший - страничка не очень
"перейти к экзаменам"
"перейти к экзаменам"
A
Это если из ЛК заходите и нажимаете на кнопку?
e
только что с телефона попробовал , снова 404
A
доступ к экзаменам по этой кнопке будет открыт завтра, сейчас там ведутся как раз работы по добавлению тестов, поэтому скорее всего из-за этого в том числе вылетает 404
AS
Конкретно, я делаю вот так:
В моих приложениях обычно у меня на входе сообщения из кафки. И я не могу не ждать успешного паблишинга. Потому что мне после паблишинга нужно делать коммит.
???.evalMap(msg.publish).parEvalMap(maxPublishBufferSize)(identity)
msg.publish на самом деле ничего не паблишит. Он только добавляет сообщение в буфер на паблишинг. Это внешний F. Сделующим шагом я дожидаюсь внутреннего F — он отрабатывает, когда данные из буфера успешно отправлены в кафку. Чтобы не ждать каждого сообщения (то есть не делать буфер размером 1) я делаю parEvalMap(maxPublishBufferSize)(identity), где maxPublishBufferSize — достаточно большое число. В кафка клиенте уже и так есть куча настроек этого буффера, поэтому мне нет смысла (обычно) ещё и на приложении делать какое-то ограничение буфера. Поэтому maxPublishBufferSize я выбираю заведомо больше, чем может влезть в буфер. И получается, что когда буффер отправляется в кафку, сразу пачка этих внутренних F внутри parEvalMap резолвится и идёт дальше по стриму.В моих приложениях обычно у меня на входе сообщения из кафки. И я не могу не ждать успешного паблишинга. Потому что мне после паблишинга нужно делать коммит.
Такая логика не ломает ordering между исходящими сообщениями?
Я прям сча этим же занимаюсь
Я прям сча этим же занимаюсь
VG
Ser Sh
Беларусь, Казахстан. Ну и в данный момент я работаю в комании в Латвии, тут тоже очень много русскоговорящих
Отличный повод стать частью России
AV
Такая логика не ломает ordering между исходящими сообщениями?
Я прям сча этим же занимаюсь
Я прям сча этим же занимаюсь
Ломает
SS
Отличный повод стать частью России
Давайте без политики и подобного. Замечательные люди и там и там. Проблемы так же есть с обеих сторон границы.
I
Такая логика не ломает ordering между исходящими сообщениями?
Я прям сча этим же занимаюсь
Я прям сча этим же занимаюсь
Ох. Сколько такого пришлось хлебнуть. И в чистой java, и на скале с akka и с zio. И главное что я запомнил из этого опыта - параллельная обработка сообщений в рамках одной партиции почти всегда зло. Особенно если нельзя терять сообщения.
Надо параллелить - добавь ещё партицию.
Надо параллелить - добавь ещё партицию.