First принципы - Timely

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

Знаете, что тесты - это не только про отсутствие багов? С точки зрения программирования у юнит-тестов есть намного более важная причина для существования.

Partial индексы

Использование #partial индексов - один из способов оптимизации работы баз данных. Представьте, что у вас есть таблица с заказами с 10млн строк и часто выполняющийся типовой запрос SELECT * FROM orders WHERE state IN ('new', 'processing') ORDER BY order_time, возвращающий не более пары сотен заказов. Индекс по state в данном случае будет достаточно эффективным ввиду хорошей селективности по указанным значениям, но будет весить пару сотен мегабайт. И, кажется, поднимать с диска в память индекс, величиной в пару сотен мегабайт, для выгрузки нескольких килобайт информации - очень непродуктивно. Что можно сделать? Ну, например, CREATE INDEX order_time_processing_idx ON order_time(state) WHERE state in ('new', 'processing'). Индекс теперь будет весить несколько мегабайт и, более того, он будет в отсортированном варианте. БД будет его использовать для нашего запроса. Даже если изменить запрос и не сортировать и не запрашивать поле order_time - все равно этот индекс будет использоваться, т.к. в нем есть информация о расположении нужных строк.

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

Пример был для PostgreSQL, но подобные штуки можно проворачивать и на БД, не поддерживающих partial индексы. Например, с помощью горизонтального деления таблиц по состояниям. Правда это уже ближе к application-level оптимизациям.

Как оптимизировать хранение строковых индексов

Раньше занимался обработкой больших объемов информации из сети на слабом оборудовании. И хочется сказать об оптимизации строковых индексов без привнесения дополнительных технических решений в проект. Чтоб было с цифрами - на серверах по $5-10 крутились реляционные базы с сотнями гигабайт индексированной информации. Лет 6 назад использовались сервера на пару ядер и 256-512 Мб оперативки. С тех пор научился ужимать индексы на порядки.

Индексирования строк создает большие индексы. Если хочется обойтись базовой базой, но нужно сделать индекс по строке, например, чтоб искать дубликаты, то для сокращения размера индекса разумно индексировать только начало строки. PostgreSQL, например, поддерживает такое, правда при таком подходе падает селективность индекса.

Альтернативный путь - индексировать дополнительный столбец char(32) содержащий md5-преобразование строки. Тем не менее, результат md5-преобразования занимает 32 байта на каждую строку, что тоже затратно. md5 - это набор из 32-х 16-ричных цифр, охватывающие пространство в 2^256 или больше чем 10^38. Но для большинства задач хватает намного меньшего диапазона значений. Например, сокращение char(32) до char(16) экономит 50% размера ключа, а значит и индекса. Но в 16 байтах хранится 16 символов или 16 8-ричных цифр, которые кодируют 8 байт информации. А значит это заменяется на bigint без потерь. Чтоб сделать это - сначала получить md5 строки, далее обрезать полученный хеш до 16 символов, затем выполнить преобразование из 16-ричной системы счисления в 10-тичную:

text_index = conv(substring(md5(url), 1, 16), 16, 10);


Значения идентификаторов, полученные так, имеют также равномерное распределением по 8-байтовому пространству. Это обеспечивает достаточную селективность. В жертву конечно будут принесены операции LIKE и другие подобные.

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

AvoidStarImport

AvoidStarImport - это настройка чекстайла на Maven Checkstyle плагине. Плагин проверяет, что в блоке импортов не используется wildcard - символ звездочки для автоматического импорта классов указанного пекейджа.

Обоснование - автоматический импорт классов ведет к высокой связности между пекейджами, а также увеличивает вероятность конфликтов при выходе новых версий библиотек. 

Что меня лично смущает - в IDEA в качестве значений по-умолчанию выставлены 3-5 импортов перед автоматическим схлопываением импортов под звездочку. Но в самых распространенных стайлгайдах включен AvoidStarImport. В итоге многие программисты используют эту дефолтную настройку, другие же - выключают. И, во-первых, это ведет к постоянным изменениям в блоке импортов. Во-вторых, к сложностям при внедрении чекстайла в проект, в третьих к росту размеров пулл реквестов. До сих пор не понимаю почему в IntelliJ решили так сделать.

Завтра провожу вебинар по Java “от Junior до Middle”.
О чем буду рассказывать:
- что необходимо знать об архитектуре, чтобы пройти собеседование на Middle-позицию
- как прокачать софт скилы перед собеседованием
- как знание Docker, Kafka и K8S влияет на твое конкурентное преимущества
- как продать себя на более высокую должность

Участие бесплатное, регистрируйтесь по ссылке: https://cutt.ly/ST3yKQr

Снова об оптимизации баз данных

Один из часто используемых инструментов для мониторинга состояния БД остается slow queries log - это лог куда СУБД складирует запросы, которые медленнее установленной величины n. Туда попадают и неверно написанные запросы, однако это редко приводит к снижениям нагрузки на БД и главная причина в том, что чаще основную нагрузку генерируют не низкочастотные неоптимизированные запросы, а высокочастотные быстрые.  

Предположим, есть два запроса. Первый выполняется 30 секунд, но раз в час. Второй выполняется за 100 мс, но "бомбит" БД 10 раз в секунду. Первый генерирует нагрузку ~1% времени потока, а второй занимает ровно 100%. Оптимизация второго запроса даст в ~100 раз больше профита.

Правда мониторить такие запросы сложнее, но на рынке присутствует много средств мониторинга и профилирования - okmeter, datadog и т.д. Если используете другие - поделитесь в комментариях.

#повседневное

Вчерашний запрос, "заморозивший" миграцию на три часа:

SELECT entity_id, MAX(start_date), MAX(end_date)
FROM (
  SELECT entity_id, MAX(start_date) start_date, NULL AS end_date FROM audit_log
  WHERE attr = 'reviewed' AND newValue = 'true'
  GROUP BY entity_id
   UNION ALL
  SELECT entity_id, NULL AS start_date, MAX(end_date) end_date FROM audit_log
  WHERE attr = 'overriden' AND newValue = 'true'
  GROUP BY entity_id
) a GROUP BY entity_id; 

можно было бы написать сильно оптимальнее вот так:

SELECT entity_id, 
  MAX(if(attr = 'reviewed', NULL, start_date)) AS start_date,
    MAX(if(attr = 'reviewed', end_date, NULL)) end_date 
FROM audit_log
WHERE (attr = 'reviewed' OR attr='overriden') AND newValue = 'true'
GROUP BY entity_id;

При сильно похожих WHERE в таких конструкциях, удобнее схлопнуть UNION и "на лету" подставлять в SELECT нужное значение через if.

В последнее время периодически раздумываю запустить какой-нибудь проект типа “Контрольный собес”. Знаете - как “Контрольная закупка”, только о собеседованиях на разработчиков в IT-компании. 
Так уж сложилось что я подготовил многих людей к собеседованиям, и сам часто проводил собеседования, и проходил их соискатель, в том числе в европейские и азиатские компании. Так вот - определить набор критериев и оценивать компании с точки зрения того, как у них устроен процесс найма IT-шников. 

Как думаете - зашло бы такое?

Я знаю что это не по теме, и я никогда не хотел тут писать на темы, слабо связанные с IT. Но если честно у меня ощущение, что у нас всех, в том числе айтишников, отбирают будущее. Если еще вчера казалось, что, если что, всегда можно улететь, спрятать голову в песок и т.д., то уже сегодня перспектива не улететь стала реальностью. Реальностью стало и то, что будучи программистом, можно будет не найти работу через месяц. Потому что отрезанный от глобального рынка локальный - не вывезет то количество айтишников и программистов которые на него придут, после разрыва отношений с западными заказчиками.

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

https://docs.google.com/forms/d/e/1FAIpQLScEsxsoXl_7R4aD5F8-B7fCCBVwU_BXBaOVJsKszbFyRHRkkw/viewform

Планирую выступать на JPoint в июне. Опять с своей любимой многопоточностью.
Ссылка: https://jpoint.ru/talks/82e4c9067a0fae2844e9d6dbc47023f1/
если вдруг кто будет из подписчиков там - буду рад любому фидбеку ну и вопросам, а если вдруг есть идеи/вопросы заранее - буду рад если зададите, а я смогу доработать доклад чтоб было интереснее и мне и вам.

все еще не чувствую себя на 100% комфортно, когда пишу даже короткие приглашения на английском. Поэтому загоняю их иногда в гугл транслейт и проверяю, что все правильно написано, переводя тексты туда-сюда.

Сегодняшний перевод выглядит так:

Я приглашаю вас на запланированную встречу в Zoom.

Я хочу показать вам способы ускорения длительных процессов на примере того, как работает развертывание наших бамбуковых спецификаций.
Насколько правильно использовать ExecutorServices/ThreadPools и сколько реально потоков нужно в вашем коде.

Хотели бы послушать про бамбуковые спецификации? 😏

Упали тесты после замены

private static final Map<String, Validator> VALIDATORS = new HashMap<>();
static {
VALIDATORS.put("US", new StatesUSCodeValidator());
}

на

private static final Map<String, Validator> VALIDATORS = Map.of(
"US", new StatesUSCodeValidator()
);


угадаете в чем разница?

Ребята, а есть кто-то с очень хорошим английским?

У меня уже полгода в полунаписанном состоянии несколько статей и я все боюсь их опубликовать т.к. боюсь что они выглядят неграмотно с точки зрения языка.

Так вот. Я ищу человека который поможет мне в редактировании статей о программировании и дизайне на английском. Нужно будет отредачить (совместно со мной) и высказать свое мнение/критику. Желательно джуновый или мидловый уровень в айти.
С меня - менторинг / подготовка к IT собесам / алгоритмы / ну или просто деньги ^^ кто заинтересон напишите пожалуйста в пм или комменты ваш уровень инглиша / IT и чего бы хотелось получить взамен.

Опубликовал небольшую заметку о том, как проектировать бд с OLTP-подходом. Наверное следующая будет о том, когда и зачем нужна денормализация.

https://hackernoon.com/principles-of-a-clean-relational-database

Пару недель назад вышел подкаст со мной на Javaswag. Бегом бронировать полтора часа на послушать разговор за Java, Clean code и собеседования 😏

https://soundcloud.com/javaswag/e34

В 34 выпуске подкаста Javaswag поговорили с Андреем Сундуковым о переходе c PHP на Java, чистом коде и о собеседованиях

00:00:09 Инженер дата-центра
00:02:54 Из PHP в Java
00:08:16 Что хорошего в Java с точки зрения PHP
00:11:58 PHP же тоже можно писать читаемый код
00:17:15 Зачем писать чистый код
00:33:39 Clean Code 2.0
00:42:04 Простая 300 строчная функция против чистого кода
00:49:03 Договорились писать "чистый код", что дальше?
00:58:28 Спринг мотивируют писать чистый код
01:04:13 Собеседования, курс From Junior to Middle https://education.dhabits.ru/
01:07:48 Что должно быть в резюме
01:18:29 Что спрашивают Сеньоров?
01:27:04 Систем дизайн интервью
01:32:38 Канал https://t.me/developers_mind

Ссылки от гостя:
Разбор резюме на позицию Java Dev https://www.youtube.com/watch?v=nDRXq21B4PI

Гость - https://t.me/Hcd5opza9bdcjid26fg

Кип сейф! 🖖

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

Да да, на 4ый день я уже принес пользу и выложил свое поделие в продакшн. Первый раз настолько быстрый и эффективный онбординг и отлично работающие CI/CD, простой понятный код (даже на незнакомых технологиях), отсутствие танцев с бубном для запуска сервисов. Немного даже в шоке 🙂

В прошлую субботу выступал в качестве спикера в Белграде на IT-митапе по софт скилам (@belgradeitmeetups). Тема: "behavior собеседования на западном рынке".
Основные тезисы:
1. CV - упор на Achievements вместо Responsibilities
2. English - основная причина провала технарей из СНГ на собеседованиях в иностранные компании
3. Необходимо мыслить с точки зрения вашего value для компании, а не с точки зрения какой вы классный или классная и сколько задачек вы успеваете делать.

По-моему эти три пункта отвечают за 20% усилий и 80% успеха с точки зрения поведенческой оценки кандидата с рынка СНГ для западных компаний. Более того - вчерашнее обсуждение этой темы с моим проджект менеджером из США подтвердило эти тезисы.

В следующих постах раскрою подробнее каждый пункт.