Смотрим в документацию:

updated
  The number of documents that were successfully updated.

Внимание, вопрос: учитываются все затронутные документы или все измененные? Вроде как все затронутые, да и обновления могут быть без изменений документа (для того, чтобы обновить документ в индексе, например). Но хочется побольше уверенности.

Роемся в исходниках, недолгий поиск по ключевому слову updated приводит сначала к WorkerBulkByScrollTaskState, а потом к AbstractAsyncBulkByScrollAction:

switch (item.getOpType()) {
    case CREATE:
    case INDEX:
        if (item.getResponse().getResult() == DocWriteResponse.Result.CREATED) {
            worker.countCreated();
        } else {
            worker.countUpdated();
        }
        break;
    case UPDATE:
        worker.countUpdated();
        break;
    case DELETE:
        worker.countDeleted();
        break;
}

Тут видно, что в подсчете вообще не учитывается, был ли изменен документ — интересен только тип операции. Соответственно в поле updated ответа будет число всех затронутых документов, даже если они не менялись. Отличаться от total оно будет только тогда, когда создаются или удаляются документы. Т.е. total = updated + deleted + created.

Люблю Open Source продукты за то, что можно при желании разобраться почти в любой проблеме.

Прикольная статья про то, как чувак строил графы по автодоплнению поисковой выдачи гугла ключевое слово vs. Перевод для нихтферштейнов.

Кто-то сделал даже страничку, чтобы поиграться самому. Запрос к гуглу идет напрямую из браузера, так что персонализация поиска скорее всего будет работать (BB is watching you).

Иногда при установке разных сервисов добавляются пользователи в систему. В некоторых случаях — с возможностью логина в систему со стандартным паролем (sic!). Чтобы найти таких редисок, можно выполнить

cat /etc/shadow | grep -v \*\: | grep -v \!\:

И еще потенциально пользователи отсюда могут залогиниться

ls -l /home

Для того, чтобы ограничить доступ, надо в конфиге sshd добавить строчку

AllowUsers user1 user2

Источник

Иногда нужно найти текст, где что-то должно повторяться. Например, найти и заменить повторяющийся паттерн в коде на вызов функции:

someFun(ololo)
anotherFun(ololo)
yetAnotherFun(rrr, ololo)

Если тупо использовать 4 группы, то такой кусочек тоже попадет в результаты:

someFun(alala)
anotherFun(ololo)
yetAnotherFun(qqq, qyqyqy)

А это мы вряд ли хотим. Чтобы указать, что подстроки именно одинаковые, нужно использовать backreference:

someFun\((.*)\)\s*anotherFun\(\1\)\s*yetAnotherFun\([^,]*,\s*\1\)

P.S. Да, я правлю код регулярками и считаю это приемлемым, когда код в таком состоянии, что только так и имеет смысл делать.

Испытываю теплые чувства к утилите nmap. С ее помощью можно быстро проверить, какие популярные порты открыты на ip-адресе:

nmap 1.1.1.1

или виден ли какой-нибудь сервис наружу

nmap 192.168.1.123 -p9050

или посканить локальную (или не очень) сетку на предмет доступных хостов

nmap -sn 192.168.1.0/24

или еще чего-нибудь насканить в сети.

У IntelliJ есть интересная опция для навигации по коду, кроме известных приемов типа Split View, перехода к определению через Ctrl+B или Ctrl+клик.

Можно делать нумерованные закладки в коде. Для создания закладки — Ctrl+Shift+цифра, для перехода Ctrl+цифра. Закладка ставится на строку и может пригодиться, когда надо быть сразу в двух-трех местах.

Сейчас на столе у меня рабочий ноутбук стоит дальше, чем монитор, и текст с него читать было тяжеловато. Впрочем раньше, когда он стоял даже чуть ближе чем мониторы, проблема тоже наблюдалась. Я решал это тупо масштабированием интерфейса телеги на 125% и Ctrl+ в браузере. Но на выходных я решил, что хватит это терпеть.

Казалось бы, измени разрешение экрана ноута — и проблема решена. Однако есть нюанс: ноут поддерживает только одно разрешение экрана.

Сначала я рыл в сторону подкрутки DPI и HiDPI, но там местами через голову прыгать надо, чтобы для разных мониторов настроить по-разному. Кроме того, не все приложения нормально поддерживают высокий DPI. А режим HiDPI на моем скромном железе выглядел очень крупно. Эх, были времена когда 800х600 в XP хватало. А до этого 320x240 в DOS вообще было норм, и 640х480 было “большим”.

В итоге я решил свою проблему скалированием через утилиту xrandr. Сначала стоит ее запустить без параметров, она выплюнет что-то вроде такого:

Screen 0: minimum 320 x 200, current 3840 x 1539, maximum 16384 x 16384
eDP-1 connected primary 1920x1080+1920+459 (normal left inverted right x axis y axis) 309mm x 174mm
   1920x1080     60.05*+
DP-2 disconnected (normal left inverted right x axis y axis)
HDMI-2 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 509mm x 286mm
   1920x1080     60.00*+  50.00    59.94
   1920x1080i    60.00    50.00    59.94
   1600x900      60.00
   ...

Первая строчка — логический экран. Вторая — id монитора ноута, его фактическое разрешение, позиция по x и y, физический размер, и список поддерживаемых разрешений (* — текущее, + — рекомендованное). Дальше — отключенный моник, а потом текущий.

Теперь скалируем:

xrandr --output eDP-1 --scale 0.75x0.75

и получим на ноуте 1440x810. Осталось прописать команду в автозапуск и дело в шляпе.

У liquibase есть неприятный баг: иногда при рестарте приложения оно может просто ничего не делать. Происходит это из-за того, что liquibase при применении своих изменений выставляет лок. И если приложение падает во время этого процесса, то этот лок никто не снимет, и перезапущенное приложение будет ждать его освобождения вечно. Эдакий deadlock с самим собой.

Решается симптом проблемы очень просто — удалением лока:

UPDATE DATABASECHANGELOGLOCK SET LOCKED=FALSE, LOCKGRANTED=null, LOCKEDBY=null where ID=1;

Мораль сей басни очевидна: вечные локи до добра не доводят.

P.S. “Обожаю” мажорные баги, которые могут не править больше 5 лет (а судя по SO, существует этот баг уже лет 7 минимум).

Как переиндексировать документы, например из-за смены типа поля, желательно “на живую”? На мой взгляд, неплохой вариант выглядит примерно так:

1. Создать новый индекс, переиндексировать туда данные по запросу “все, что было проиндексировано раньше текущего времени”.
2. За время переиндексации появятся новые документы — можно повторить эту процедуру, сокращая “лаг” до приемлемого количества. Обычно 2-3 подходов хватает, но это легко автоматизируется.
3. Переключаем альяс со старого индекса на новый.
4. Делаем еще одну итерацию по переиндексации, чтобы переиндексировать оставшиеся документы из старого индекса.
5. Удалить старый индекс.

Такой подход может показаться сложным, но зато в приложении, читающем данные, разница будет практически не видна и эквивалента тому, что немного документов из п.4 были проиндексированы чуть позже. Если данных много, то это обычно не критично.

Но что делать, если в индексе нет даты индексации? И никакого поля, которое можно было бы использовать таким образом? Есть альтернативный подход:

1. Создать новый индекс.
2. Переключить на него альяс для записи — все новые документы попадают теперь туда.
3. Сделать реиндекс. Поскольку в старый индекс уже ничего не пишется, никаких запросов не нужно, все делается за 1 раз.
4. Переключить альяс для чтения на новый индекс.
5. Удалить старый индекс.

Звучит попроще, но для читающего приложения такая ситуация будет выглядеть, как будто индексация прекратилась на существенный период времени, а потом резко продолжилась с мгновенным появлением документов из этого периода. В принципе, тоже жизнеспособный вариант, подходит для кейсов, когда можно обрабатывать данные с большой задержкой (какие-нибудь ежемесячные отчеты или подобная штука).

Внимательный читатель заметит, что рассмотрен только простейший случай, когда есть только производитель и потребитель, и никаких обновлений. Что ж, когда приложение сложно обновляет документы — тут уже думать надо, шансы прикидывать…

Годная статья про всякие штуки в СУБД, о которых обычно не задумаешься, а стоило бы.

Things I Wished More Developers Knew About Databases