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

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

Читать целиком за раз ее вряд ли стоит, для просвещения я рекомендую ознакомится с разделом 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 со схожими по смыслу и/или написанию значениями.

Старая, но не сильно устаревшая статья про то, как настраивать эластик. Часть книги про работу с эластиком, где есть описание принципов его работы, всякие советы по настройке, набор полезных рецептов и т.п.

Есть несколько способов для этого:

1. Парольный доступ. Пожалуйста, не пользуйтесь им. Вроде как это звучит очень просто, но сервак становится уязвимым к перебору паролей, пароли надо где-то хранить, общие учетки растекаются по куче людей и вообще неизвестно куда, записываются на бумажки и т.п. Вдобавок с парольным доступом есть ограничения на многие действия — тяжело что-то автоматизировать, когда надо пароль пробрасывать. Есть sshpass, но его стоит использовать только в очень крайних случаях.

2. Ключевой доступ. По умолчанию используйте его. Он надежнее, позволяет более гранулировано управлять доступом и использовать ssh практически бесшовно. Есть и проблемы: например, не очень просто удалить ключ уволившегося сотрудника из всех мест или ограничить права уже внутри хоста. Но это решается, например, через системы конфигурации типа Puppet или Ansible.

3. Доступ через SSO. С этим вариантом я столкнулся на новой работе. Суть заключается в том, что никто не дает доступа к серверам напрямую — только через промежуточный агент, который управляет доступом. Банальный вариант — вы запрашиваете доступ к определенному серверу, а после одобрения подключаетесь к серверу-агенту, вводите свои LDAP-данные и работаете дальше. Пример из интернета. Этот подход хорош для большой организации — контролируемый менеджмент ключей, возможность аудита, ведения журналов доступа и т.п. Но для рядового сотрудника это не очень удобно — возникают многие проблемы парольного доступа. Например, уже не скачаешь нормально файл по scp через промежуточный узел или не пробросишь чужие порты.

Надеюсь, что ни для кого не секрет, что для текста лучше использовать длинное тире ‘—’, а не знак минуса ‘-’. Но проблема в том, как его вводить.

Конечно, есть автозамены, когда вам пробел-минус-пробел меняют на пробел-тире-пробел. Иногда это работает неплохо, но, во-первых, это есть не везде, а во-вторых — когда эта автозамена сработает неправильно, то сильно бесит. Горячие клавиши на символы тоже есть не везде.

Один из вариантов решения этой проблемы — Compose-клавиша, которая говорит о том, что несколько следующих символов надо преобразовать в один. В Linux назначить эту клавишу можно в настройках клавиатуры (я навесил на правый Win). Теперь я могу вводить тире как Win + - + - + -, а Æ из имени сына Илона Маска как Win + A + E. И работает это в любом приложении. Стандартные комбинации можно посмотреть, например, здесь.

В винде для этого надо нажать Alt и ввести на numpad код символа в ASCII или в Unicode. Помните лайфхаки из 2000-х, как в аське сердечки слать, еще до того как появились эмодзи? Вот это оно и есть. Но как запомнить код для тире — я не представляю. А в маках это тоже вроде как можно сделать, но инструкции удручают своей длиной. См. например, эту.

Сама по себе фича мне очень нравится. Все тире в последних моих текстах я набирал только так:)

Как мне подсказал @n_kudryavtsev, в Windows 10 уже примерно года два есть “панель эмодзи”, которую можно вызвать, находясь в любом текстовом поле, комбинацией Win + .. Там в одном из разделов есть и длинное тире.