Про db-queue докладов нет, но в readme есть ссылки на примеры использования. Тема с очередями на БД не новая, мы её используем еще года с 2012 или даже раньше. Если про Java то есть такие реализации https://www.jobrunr.io/en/, https://github.com/kagkarlsson/db-scheduler. На самом деле их гораздо больше, потому что все сложности с конкурентным доступом берёт на себя БД за счёт skip locked директивы.
Мы тоже хотели навести порядок в коммитах, но потом поняли что мы не смотрим историю. Зачастую, когда смотришь историю, интересен ответ не "что было сделано?", а "почему так было сделано?". На второй вопрос можно получить ответ из постановки задачи и из инструмента для код ревью. Для того чтобы найти и то и другое нам достаточно номера тикета в коммите.
О каких проблемах идет речь? Если ссылку на immutable объект расшарить между двумя потоками, то потоки, одновременно работающие с ним, не смогут его «испортить», так как объект неизменяемый. В этом суть данного подхода. Конечно он не полностью решает все проблемы и не всегда подходит.
Поэтому приложение должно уметь отлавливать такие случаи и повторять попытку изменений с самого начала. Практически нигде в примерах это даже не упоминается
В комментах упоминается
Если да, то нас опередили, но мы оптимистичны и повторяем транзакцию еще раз.
В данном случае изменения повторяются автоматически системой. Поэтому операции внутри транзакции должны быть идемпотентны. Я специально убрал часть конфигурации отвечающую за количество повторений транзакции, чтобы не загромождать код.
private final TransactionFactory txFactory = new TransactionFactoryBuilder().setMaxRetries(1_000_000) .build();
И да, я не рассматривал случай, когда максимальное количество повторений превышено. Спасибо за замечание.
в варианте неблокирующего оптимистичного алгоритма есть существенный недостаток: при высокой конкуренции вероятность получить false на compare-and-swap становится достаточно высока, особенно с большими значениями BigInteger
Да, вы правы. Я сделал перформанс тесты (спасибо огромное TheShade) и до определенного момента неблокирующий алгоритм выигрывает в 2 раза у блокирующих. Затем деградириует и в конце концов становится медленнее. Здесь он просто приведен для демонстрации подхода.
Кроме того, пожалуй, метод val() излишний в api, потому что класс в таком виде становится не Thread safe
Спасибо, отлично все заработало. Правда вместо настройки правил в плагине foxyproxy, я использовал privoxy, как описано здесь help.ubuntu.com/community/I2P
Нас на Северном Флоте, да и в учебке в Анапе учили по другому. И я считаю, что более правильно.
Есть определенный гласные которые звучат коротко — это Е и И. А есть те, у которых длинный звук — это А и О. Если вы посмотрите скажем на Х, то там должны быть все короткие звуки, а вас двое длинных (хОлОстяки). У нас Х звучала как «химичите». То же самое с буквой С (сАмОлет), у нас «сисисип». То есть у вас А и О применяются и для длинных и для коротких звуков, что на мой взгляд не способствует более быстрому обучению, хотя это может и не влиять на скорость и качество приема.
cat_via_pygmentize() {
if [ ! -x $(which pygmentize) ]; then
echo package \'pygmentize\' is not installed!
exit -1
fi
if [ $# -eq 0 ]; then
pygmentize -g $@
fi
for FNAME in $@
do
filename=$(basename "$FNAME")
lexer=`pygmentize -N \"$filename\"`
if [ "Z$lexer" != "Ztext" ]; then
pygmentize -l $lexer "$FNAME"
else
pygmentize -g "$FNAME"
fi
done
}
alias o='cat_via_pygmentize'
Из собственного опыта скажу что git blame <имя_файла> на виндовой машине будет говорит, что изменения not commited. Поскольку в репозитории юниксовые, а на винде виндовые и он думает что файл изменился. И поэтому надо прописывать git blame HEAD <имя_файла>. Также при мерджах возникает конфликт, но после вызова mergetool сразу говорит, что разрешён. Почему так еще не разобрался…
На нестандартном порту висит gitolite. После того как все конфиги протестированы этот instance выключается. А gitolite переносится на стандартный порт, как и описано в конце статьи
На другом пользователе нельзя поднимать, поскольку много систем зависит от origin url.
Всё дело в файле authorized_keys. Gitosis'у и gitolite'у нужно эксклюзивное владение этим файлом. А для одного instance'a ssh задаётся только один такой файл. Поэтому чтобы не было конфликтов надо поднять второй instance, который будет использовать другой файл authorized_keys
Подтверждаю) кому нужны очереди на Java для любой из популярных РСУБД добро пожаловать https://github.com/yoomoney/db-queue
Про db-queue докладов нет, но в readme есть ссылки на примеры использования.
Тема с очередями на БД не новая, мы её используем еще года с 2012 или даже раньше.
Если про Java то есть такие реализации https://www.jobrunr.io/en/, https://github.com/kagkarlsson/db-scheduler. На самом деле их гораздо больше, потому что все сложности с конкурентным доступом берёт на себя БД за счёт skip locked директивы.
Есть ещё DSL на Kotlin для написания дашбордов https://github.com/yoomoney/grafana-dashboard-dsl
И Gradle плагин который работает с ним в связке https://github.com/yoomoney/grafana-dashboard-plugin
Когда написал код и прошёл ревью, то иногда получается код отличный от изначального. Тем не менее написал его ты.
github.com/yandex-money-tech/grafana-dashboard-dsl
github.com/yandex-money-tech/grafana-dashboard-plugin
Очевидно что нет)
Мы тоже хотели навести порядок в коммитах, но потом поняли что мы не смотрим историю. Зачастую, когда смотришь историю, интересен ответ не "что было сделано?", а "почему так было сделано?". На второй вопрос можно получить ответ из постановки задачи и из инструмента для код ревью. Для того чтобы найти и то и другое нам достаточно номера тикета в коммите.
Ну так можно поставить autocrlf=true и пушиться будут lf переносы.
Но ведь можно использовать crlf. Почему ты сделал выбор в пользу lf?
В Linux все просто. Там юниксовые переводы строк везде и ставишь в git autocrlf = input. А вот в wsl хз…
Коллеги, объясните пожалуйста, как правильно работать с переносами строк с wsl? Скажем у меня есть git, а редактирую я в через консольный vim и idea.
В комментах упоминается
В данном случае изменения повторяются автоматически системой. Поэтому операции внутри транзакции должны быть идемпотентны. Я специально убрал часть конфигурации отвечающую за количество повторений транзакции, чтобы не загромождать код.
И да, я не рассматривал случай, когда максимальное количество повторений превышено. Спасибо за замечание.
Да, вы правы. Я сделал перформанс тесты (спасибо огромное TheShade) и до определенного момента неблокирующий алгоритм выигрывает в 2 раза у блокирующих. Затем деградириует и в конце концов становится медленнее. Здесь он просто приведен для демонстрации подхода.
В какой реализации? BigInteger же immutable.
Есть определенный гласные которые звучат коротко — это Е и И. А есть те, у которых длинный звук — это А и О. Если вы посмотрите скажем на Х, то там должны быть все короткие звуки, а вас двое длинных (хОлОстяки). У нас Х звучала как «химичите». То же самое с буквой С (сАмОлет), у нас «сисисип». То есть у вас А и О применяются и для длинных и для коротких звуков, что на мой взгляд не способствует более быстрому обучению, хотя это может и не влиять на скорость и качество приема.
Подсвечивает абсолютно любой вывод
Из собственного опыта скажу что git blame <имя_файла> на виндовой машине будет говорит, что изменения not commited. Поскольку в репозитории юниксовые, а на винде виндовые и он думает что файл изменился. И поэтому надо прописывать git blame HEAD <имя_файла>. Также при мерджах возникает конфликт, но после вызова mergetool сразу говорит, что разрешён. Почему так еще не разобрался…
На другом пользователе нельзя поднимать, поскольку много систем зависит от origin url.