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% успеха с точки зрения поведенческой оценки кандидата с рынка СНГ для западных компаний. Более того - вчерашнее обсуждение этой темы с моим проджект менеджером из США подтвердило эти тезисы.

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

CV - Responsibilities vs Achievements

Какое же основное отличие резюме для западного рынка и резюме с рынка СНГ? Из моего опыта - это упор на достижения вместо описания зоны ответственности. Особенно удручающе выглядят фразы типа “написание кода”, “исправление багов”, “проведение код ревью” - это похоже на “ответсвенный, коммуникабельный стрессоустойчивый, легкообучаемый” что, конечно, является огромным клише. Итак, вместо “разработка функционала” лучше написать “реализовал рекоммендательную систему, которая увеличила прибыль на 40%”. Вместо “оптимизация кода” лучше написать “оптимзировал главную страницу на 200 мс, что улучшило конверсию на 30% и сэкономило на оборудовании 20%”. Вместо “проведение код ревью” лучше написать “внедрил автоматический процесс проверки качества кода который экономит 20 человекочасов разработчиков IT-департамента еженедельно”. Так уж сложилось что на западном рынке не смотрят на, что специалист делал ежедневно, Намного важнее, чего он достиг и как он поможет бизнесу зарабатывать больше денег. В конце концов зарабатывать деньги - и есть цель любого бизнеса.

Бонусом же к такому подходу в составлении CV будет и то, что и на рынке СНГ такое CV не выглядит чужим. Оно выглядит нормально для западных компаний и свежо для компаний рынка СНГ.

English

Много раз собеседовался в иностранные компании и получил несколько инсайдов из западных же компаний по поводу главных причин отказа ребятам из России. Несложно догадаться - это уровень английского. Большинству технически сильных кандидатов отказывают из-за низкого уровня коммуникации - для мидловых, а особенно сеньорных ролей, это критически важный момент. Причем такой фидбек и дают: "кандидат технически крутой, но коммуникация это труба, как потом с ним взаимодействовать?". С кандидатами из других стран это проблема намного менее ярко выражена.

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

Что делать, если хотите работать на западном рынке? Учите английский.

В новой компании в слаке есть канал #insights куда падают feature-реквесты от пользователей и куда кидают результаты опроса-фидбека по поводу причин почему пользователь начал или прекратил пользоваться услугами компании.

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

Value

И наконец, третье отличие рекрутингового процесса на западе и СНГ-рынка - это ориентация на ценности (или value). По сути эта ориентация в процессе интервью позволит не просто пройти интервью, но и получить позитивную, а зачастую и восторженную, обратную связь от менеджеров. В самом примитивном варианте value - количество заработанных для компании денег, т.е. в процессе интервью показывайте сколько денег сэкономлено или заработано в прошлых компаниях и сколько заработаете для этой. Более продвинутый вариант - это почитать на сайте о ценностях компании и излагать опыт и умения с точки зрения ценностей для конкретной компании. Но последним мерилом ценности и полезности все равно являются деньги, поэтому деньги - универсальная метрика, которая помогает компании оценивать профессионалов. Если доказать, что будете приносить компании $30к, то можно легко просить обоснованную зарплату в $10к.