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

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.

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

Jepsen — это классный проект, направленный на проверку поведения распределенных систем (баз данных, шин данных и т.п.) в нештатных ситуациях вроде потери пакетов или split-brain. Фактически Aphyr ломает системы, создавая внешние условия, в которых нарушается консистентность. К сожалению, готовых анализов не так много. Про какой-нибудь Elasticsearch там всего лишь статья 2015 года про древнюю версию 1.5.0. Однако в блоге достаточно высокий технический уровень и детальность проработки, и из него можно почерпнуть много знаний про внутренние механизмы работы и типовые проблемы распределенных систем.

Кстати, недавно на HN наделала шуму статья про то, что несмотря на попытки Mongo улучшить работу с транзакционностью, консистентностью и всем таким, у нее все еще есть проблемы.

Годами я использовал онлайн сервисы типа epochconverter, чтобы из временной метки 1590735600 получить “Friday, May 29, 2020 10:00:00 AM GMT+03:00”. На днях узнал, что это можно сделать и в консоли:

$ date -d @1590735600
Пт мая 29 10:00:00 MSK 2020
$ date -d '2011-04-10T20:09:31Z' +"%s"
1302466171

Если надо импортировать значение из enum, то Alt+Enter в Intellij по умолчанию вам любезно добавит имя enum спереди, превратив

val color = RED

в

import my.package.Colors
...
val color = Colors.RED

По моему опыту, это чаще всего не нужно: обычно по контексту и значению enum очевидно, какому перечислению оно принадлежит. Чтобы изменить это поведение, есть настройка “insert imports for inner classes”. При ее изменении будет добавляться полный импорт:

import my.package.Colors.RED
...
val color = RED

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