Читать в телеге. Когда-то там были посты не только от меня.
Большие запросы без пагинации и scroll'а в ElasticSearch
Параметр search_after позволяет выполнить последовательность запросов без использования пагинации (у которой есть ограничения на размер page*size, по умолчанию 10 000) и без использования scroll (который практически создает слепок индекса и жрет память). Идея довольно простая: использовать сортировку по какому-то полю, взять первые N результатов, а потом сделать запрос, в которого значение поля сортировки больше, чем у N-ного результата.
Есть пара подводных камней. Во-первых, размер страницы должен быть больше количества элементов с повторяющимся значением (иначе часть “повторок” будет пропущена). Во-вторых, данные будут меняться, поэтому надо учитывать, что данные могут быть обновлены, удалены или изменены, и с умом подбирать поле для сортировки (время создания — неплохой кандидат).
CQRS
CQRS (Command and Query Responsibility Segregation) — это очень простой принцип построения систем, который является продолжением CQS (сommand-query separation). Напомню, что CQS говорит о том, что всякий метод является либо командой, которая меняет данные, но ничего не возвращает, либо запросом, который возвращает данные, но не меняет их. А CQRS дополняет его, говоря о том, для обработки команд и обработки запросов используются разные сущности (например, сервисы).
Подробнее можно посмотреть в презентации, которую я делал для внутреннего доклада, или посмотреть видосик (но им я недоволен, потому что речь моя оставляет желать лучшего).
Иерархия мотивации
Один из самых классных докладов на конференции TeamLead 2020 был про мотивацию.
В нем обозначена проблема, что руководство пытается лечить симптомы (поведение), а не корневую причину. Рассмотрены 6 мотивационных статусов:
- Автоматическая мотивация — делаешь на автомате, мысли о другом.
- Внешняя — ждешь награду, не обязательно материальную.
- Навязанная — избегаешь “наказания” (увольнения, стыда, позора, провала и т.п.).
- Согласованная — видишь связь со своей целью. “Я хочу заниматься этой задачей”.
- Интегрированная — получаешь удовольствие, чувствуешь связь с призванием, “работа мечты”. Ошибки воспринимаются как полезный опыт.
- Поток — наслаждение, “хочу делать только это, на остальное пофиг”. Важен процесс, нет гарантии результата.
В 4-6 цель внутри, задачи выполняются ответственно, мотивация оптимальная. В 1-3 цель вне задач и они выполняются для галочки. Долго в низких уровнях мало кто может находится. Кроме этого, существуют 3 базовых психологических потребности: автономия, принадлежность, компетентность. Если какая-то не закрыта, то с мотивацией будут проблемы.
Чтобы повысить мотивацию, есть 2 основных способа:
- Внезапно, устранить проблемы, если у демотивации есть объективная причина.
- Включить саморегуляцию: осознанность (чтобы сотрудник думал о себе, рефлексировал), цели (для чего он к ней идет), ценности (которые определяют направление его движения и помогают ставить цели, принимать решения).
Задайте себе вопрос — если бы пропали деньги из мира, стали бы вы заниматься тем, чем занимаетесь сейчас?
Макакачность
Короткий цикл обратной связи — это классно. Можно быстро проверять гипотезы, работоспособность алгоритма, можно не компилировать код в голове и не проверять крайние случаи, а просто накинуть тестов.
Можно почти не думать — на глазок сделал, проверил, не получилось — попробовал еще раз. Быстро же. Делаешь так по наитию и через пару итераций — опа, работает, едем дальше. Мозг вообще любит лениться и часто мыслит шаблонно (см. миллионы примеров про биту и мяч, сестер Чичи и т.п.). Самое поганое, что такой ленивый подход действительно часто работает.
Но вот когда с разбегу не получилось, то легко провалиться в яму “ну вот, почти работает, сейчас чуть-чуть поправлю здесь и будет все хорошо”. Еще хуже будет, когда переключаешься на другую активность и не можешь сосредоточиться на проблеме (или не хочешь).
Начал замечать за собой такое поведение: например, когда реализовывал поиск по префиксному дереву с учетом разовой ошибки. Все тесты были уже готовы, просто хотел решить сам, чтобы понять, какие трудности могут возникнуть у моих студентов. Алгоритмы там очень простые, накидал почти не думая решение — тесты не прошли. Поправил немного в месте, где скорее всего ошибка — не прошли другие. Как макака, повторял эти действия. Через пару часов очнулся: вместо кода — лапша с костылями al dente, тесты не проходят. Все стер, включил мозги и написал минут за 10 нормально.
Вот смотрю на себя и на то, что вокруг, и думаю: индустрия хотела 10x-инженеров, а получила 10x-макак.
Большие стрелки и маленькие квадратики
Когда готовил доклад про скучное программирование, то не нашел эту статью, поэтому заменил затравку на цитату Хоара (“Inside every large program is a small program struggling to get out.”).
А ключевая идея статьи заключается в том, что больше всего времени разработчика тратится не на бизнес-логику приложения, а на интеграции и передачу данных между различными слоями и компонентами. И картинки с тонкими стрелочками и крупными блоками искажают картину. С точки зрения трудозатрат они должны выглядеть примерно так:
Хотя с другой стороны, толстые стрелки можно обозвать деталями реализации, ведь многие говорят о том, что данные важнее алгоритмов: Брукс, Пайк, Торвальдс. Возможно, это применимо и к архитектуре приложения.
Автоматическая репликация на все узлы Elasticsearch
Как-то совсем мимо меня прошла полезная настройка, которая была даже в первой версии эластика. index.auto_expand_replicas со значением 1-all
позволит иметь по реплике индекса на всех узлах кластера, что очень удобно для небольших вспомогательных индексов (настройки, пользователи и т.п.).
Самоорганизующаяся команда
Неплохая статья про самоорганизующиеся команды и уровни зрелости команды.
TLDR:
- Директивное управление работает на энергии руководителя, кончится она — кончится команда.
- У команды должна быть четкая и понятная цель, общее видение и ответственность.
- Члены команда должна знать контекст друг друга, работа всех должна быть прозрачна.
- Если переборщить с самостоятельностью, то можно начать выходить за зоны своей ответственности или указывать бизнесу на его недочеты (и это может быть как плюс, так и минус).
- Чем больше нужно согласований для действий, тем меньше инициативы в команде.
И другая статья, в которой изложены похожие мысли, но отмечается, что работать это будет не всегда: не все люди готовы брать инициативу и принимать решения.
Коммит в соавторстве
Иногда на GitHub можно увидеть коммит от нескольких авторов (например). Сделать совместный коммит довольно просто: нужно просто добавить строку в коммит с текстом
Co-authored-by: name <name@example.com>
Разумеется, туда можно вписать что угодно. Отображение соавторства поддерживается GitHub и GitLab, но это не стандартная фича git. При этом есть и другие “прицепы”.
Индексирование нового поля в ElasticSearch
Чтобы добавить новое поле в существующий индекс, новый индекс создавать не нужно, достаточно обновления маппинга. Но старые данные не будут переиндексированы, даже если это поле было в документах раньше. Чтобы индексировать их, можно выполнить update by query с пустым скриптом. В запросе имеет смысл указать новое поле как отсутствующее и, возможно, какое-нибудь старое поле как маркер необходимости обновления документа в индексе (чтобы не индексировать все подряд).
POST your-index/_update_by_query?conflicts=proceed&wait_for_completion=false
{
"query": {
"bool": {
"must_not": [{
"exists": {
"field": "new.field"
}
}],
"must": [{
"exists": {
"field": "exisiting.field.as.flag"
}
}]
}
}
}
Пулл-реквест в Kotlin
Пара недавних постов были подводкой к этому (и еще один грядет). Захотел сделать пулл-реквест в Kotlin, выбрал один из “простых” тикетов. Выкачал репозиторий с GitHub, импортировал в Idea и начались проблемы.
Для регресса нужна установка Java 6. В Readme рекомендуют пакетные менеджеры, аж 3 штуки, но все они устанавливаются только через curl | sh
, что опять меня триггернуло. Заленился искать адекватный вариант, в итоге просто отключил флагом gradle.
Попробовал запустить тесты. Один тест не запустился — оказалось, что надо было сначала сгенерировать все тесты, а потом уже запускать compilerTest
. Кстати, хрен найдешь этот таск в списке грейдловских. Сгенерированные тесты не прошли, работало больше 2 часов, завершения тестов javascript я так и не дождался. В завалившихся, кроме javascript, были еще тесты с Java 9-15, но даже если запуститься с Java 15, ситуация не изменилась. Причем в репозитории лежит .idea
-проект, т.е. подразумевается, что все уже настроено, а по факту — даже просто прогнать тесты уже не так просто, причем проблема не только у меня, а может это и вовсе норма.
Сам проект выглядит не очень ухоженным. Открытых тикетов больше 4 тысяч, веток 3,5 тысячи, TODO в коде 9 тысяч, некоторые пулл-реквесты висят с 2017 года (бывают и просто грустные). В коде встречаются непонятные сокращения, периодически выскакивают java-файлы, форматирование и нейминг неконсистентные, есть даже файлы, названные по идентификатору тикетов в YouTrack. Создается впечатление, что раньше Kotlin был прибит гвоздями к Idea, потому что плагин был в основном коде языка и добавление инспекции могло привести к изменению языка (судя по истории git). Структура проекта вроде понятна, но найти место, где нужно поменять код, не очень тривиально (хотя это скорее я просто затупил). У меня возникло подозрение, что есть код, вообще не покрытый тестами, ну или я их просто не смог найти. У некоторых тестов интересный формат входных данных: котлиновский файл с кучей комментариев для управления проверками (но документации нет).
Выбранный тикет так и не получилось сделать: сначала я долго не понимал, что именно там нужно сделать и где, а потом пришел к выводу, что не факт, что эти изменения вообще нужны. Даже совсем плюнуть хотел на эту затею, но потом вспомнил о баге с манифестом. В нем хотя бы было понятно, что делать и откуда начать. Корневая причина оказалась не там, где я думал, но в итоге со всем разобрался (хотя тесты чужеродно выглядят). Мой пулл-реквест в итоге приняли (achievement unlocked!), но ревьюер проделал больше работы, чем я: я упустил довольно серьезный баг, поэтому не очень собой доволен. А еще TeamCity шлет письма по валящимся билдам, в которые попал мой коммит (хорошо хоть проблемы вызваны не моими изменениями).