Сейчас на столе у меня рабочий ноутбук стоит дальше, чем монитор, и текст с него читать было тяжеловато. Впрочем раньше, когда он стоял даже чуть ближе чем мониторы, проблема тоже наблюдалась. Я решал это тупо масштабированием интерфейса телеги на 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

Не все понимают, что означает этот флаг в эластике: довольно много тикетов в гите эластика на то, что получен false на успешно выполненную операцию.

Если вкратце — "acknowledged": true означает, что операция применилась ко всем нодам, то есть кластер в синхронизированном состоянии после выполнении операции.

Если false — значит не все шарды успели выполнить операцию в пределах отведенного таймаута. Но это не означает, что операция не была выполнена совсем или что выполнена частично: просто не все ноды успели отрапортовать, смогли ли ее выполнить или нет.

Think of “acknowledged” = true as an equivalent to “not_timed_out” = true.

При обновлении системы может случиться такое, что systemd не видит новых изменений (новые динамические библиотеки, например). Семь бед — один ресет, рестартнуть systemd можно через systemctl daemon-reexec.

Но самое важное — это конечно догадаться, в чем дело.

В продолжение темы поведения СУБД в нестандартных ситуациях — исследовательский проект по тестированию уровней изоляции в базах данных. На практике применить эти знания тяжеловато, но если это станет нужно, то хотя бы будет откуда начать.

Статья-справочник по способам организации веток в коде.

Читать целиком за раз ее вряд ли стоит, для просвещения я рекомендую ознакомится с разделом Looking at some branching policies и заключением, а потом уже углубиться, если в чем-то не разобрались.

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

Подробнейшая статья про технологии вызова нативных библиотек в Java: JNI, JNR и про то, что нас ждет в будущем — Project Panama: https://habr.com/ru/company/leader-id/blog/505072/

Я надеюсь, что доказывать пользу атомарных коммитов не нужно. Можно почитать немного про это, а заодно про сообщение коммита в wiki OpenStack.

Но не всегда получается построить план своей работы над задачей так, чтобы учесть все возможные изменения. Особенно если вы вдруг из тех, кто считает, что зачем тратить целых 30 минут на раздумья, когда можно всего лишь за 5 часов все потом отрефакторить :)

Если у вас есть большая пачка изменений с рефакторингами и изменениями в бизнес-логике вперемешку, то разбить ее на атомарные коммиты поможет частичный коммит. Ну и stash/shelve, но про них как-нибудь в другой раз.

В mercurial для этого есть просто великолепный интерактивный режим (hg commit -i), который раньше был расширением Crecord. В Intellij поддержки частичного коммита нет, но есть тикет. Шансы на то, что его исправят близки к нулю — “кто же использует mercurial в 2020?”, считает большая часть индустрии.

В git для этого есть механизм patch (git add -p <filename>), который работает, мягко говоря, отвратительно. Там даже нельзя выбрать отдельную строчку. Stage this hunk [y,n,q,a,d,/,j,J,g,s,e,?]? звучит особенно по гитовски — миллион опций, запомнить которые невозможно. В Intellij уже два года как есть поддержка частичного коммита, который является надстройкой над этим механизмом, и закоммитить отдельные строчки через нее тоже пока нельзя.

Но не стоит унывать, потому что для git тоже есть расширение Crecord. sudo apt-get install git-crecord, и после этого доступна команда git crecord, которая окунет вас в такой же отличный интерактивный режим, как и в mercurial.