Везде говорят, что найм умер, а мы активно набираем джавистов. Посмотрел вакансии Сбера, их сейчас тоже много. Наблюдаю, что банки активно развивают небанковские продукты, постепенно захватывая новые рынки. Это всё еще раз подтверждает, что банкиры всегда зарабатывают, даже в кризис. Сразу всплывают в голове мемы про доступное жилье доступную ипотеку 😃 . Яндекс тоже не отстает.
Активный найм — много собеседований. Чтобы не нарваться на кандидата, который проходит паровозик (несколько кандидатов идут на одну и ту же вакансию, собирая базу вопросов) или пользуется базой слитых вопросов, выработал для себя ультимативную тактику. Каждый раз задаю на 80% новый набор вопросов, благо ChatGPT не страдает от недостатка фантазии. Конечно, такой подход требует как бОльшую подготовку перед самим собеседованием, так и сильную теоретико-практическую базу. Все это в наличии😎
Для того, чтобы отсеять накрутчиков опыта, выполняем ревью кода и решаем небольшие практические задачки на знание языка. Условие одной из них: нужно написать неблокирующий потокобезопасный стек, не используя коллекций из библиотеки j.u.c. Попробуй свои силы. Вот решение:
На medium есть целая статья, которая предлагает более элегантное решение с хвостовой рекурсией на Kotlin.
Раньше давал алгоритмическую задачу, от которой впоследствии отказался. За отведенные 15 минут нужно было нарисовать лестницу заданной высоты N вида:
Казалось бы, отступил нужное число пробелов и вывел
Сейчас есть множество других методов, чтобы обмануть интервьюера:
* AI-инструменты, которые позволяют отвечать на вопросы в режиме реального времени, но невидимые при демонстрации экрана. Можно приспособить под это отдельный монитор или мобильное устройство/планшет в идеале с AI-коррекцией направления взгляда
* синхронизация речи и движений губ у AI-клона в реальном времени
* парное прохождение собеседований, когда ответы диктуются более подготовленным напарником, или вообще прохождение собеседования другим человеком
В целом не имеет значения, удалось ли обмануть кандидату интервьюера, если в дальнейшем на испытательном сроке он справляется с поставленными задачами. Хуже, когда команда в течение трех месяцев не получает ожидаемой отдачи от новичка, а тянет ношу и за себя и за того парня. Жаль, что испытательный срок перестал быть лишь формальностью.
Активный найм — много собеседований. Чтобы не нарваться на кандидата, который проходит паровозик (несколько кандидатов идут на одну и ту же вакансию, собирая базу вопросов) или пользуется базой слитых вопросов, выработал для себя ультимативную тактику. Каждый раз задаю на 80% новый набор вопросов, благо ChatGPT не страдает от недостатка фантазии. Конечно, такой подход требует как бОльшую подготовку перед самим собеседованием, так и сильную теоретико-практическую базу. Все это в наличии
Для того, чтобы отсеять накрутчиков опыта, выполняем ревью кода и решаем небольшие практические задачки на знание языка. Условие одной из них: нужно написать неблокирующий потокобезопасный стек, не используя коллекций из библиотеки j.u.c. Попробуй свои силы. Вот решение:
public class LockFreeStack<T> {
// по классике хранит непосредственно значение и ссылку на следующую Node
private static class Node<T> { ...
private final java.util.concurrent.atomic.AtomicReference<Node<T>> head = new AtomicReference<>();
public void push(T element) {
Node<T> newNode;
Node<T> currentHead;
do {
currentHead = head.get();
newNode = new Node<>(element, currentHead);
} while (!head.compareAndSet(currentHead, newNode));
}
public T pop() {
Node<T> currentHead;
Node<T> nextNode;
do {
currentHead = head.get();
if (currentHead == null) {
return null;
}
nextNode = currentHead.next;
} while (!head.compareAndSet(currentHead, nextNode));
return currentHead.value;
}
}
На medium есть целая статья, которая предлагает более элегантное решение с хвостовой рекурсией на Kotlin.
Раньше давал алгоритмическую задачу, от которой впоследствии отказался. За отведенные 15 минут нужно было нарисовать лестницу заданной высоты N вида:
|¯
|¯
|¯
Казалось бы, отступил нужное число пробелов и вывел
|¯, но справился за все время с этим единственный синьор. Не знаю почему, но это был реальный гроб.Сейчас есть множество других методов, чтобы обмануть интервьюера:
* AI-инструменты, которые позволяют отвечать на вопросы в режиме реального времени, но невидимые при демонстрации экрана. Можно приспособить под это отдельный монитор или мобильное устройство/планшет в идеале с AI-коррекцией направления взгляда
* синхронизация речи и движений губ у AI-клона в реальном времени
* парное прохождение собеседований, когда ответы диктуются более подготовленным напарником, или вообще прохождение собеседования другим человеком
В целом не имеет значения, удалось ли обмануть кандидату интервьюера, если в дальнейшем на испытательном сроке он справляется с поставленными задачами. Хуже, когда команда в течение трех месяцев не получает ожидаемой отдачи от новичка, а тянет ношу и за себя и за того парня. Жаль, что испытательный срок перестал быть лишь формальностью.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤6⚡2👍1
Насобирал с последнего поста по собеседованиям немного вестей с полей.
Коллега пишет:
Софтина, конечно, не обязательно именно такая была, но идея понятна: ИИшка разбирает аудиопоток и выдает ответы на вопросы интервьюера в режиме реального времени.В мирном русле можно использовать подобные софтины в качестве переводчика для интервью на иностранных языках, конечно, генерируя ответы самостоятельно.
Как это проявлялось:
Буквально вчера столкнулся с подобным на скрининге: на первоначальный вопрос в ответ полная ерунда, затем после незначительного уточнения/повторения развернутый подробный ответ. И так не один раз, а буквально через вопрос. На некоторые — вообще не получил ответ при том, что спрашивал вполне себе базу у разработчика со стажем в 5 лет...так в резюме написано, я бумажке верю 😃
Может я разучился правильно формулировать мысли? Надеюсь, вы меня еще понимаете. Понимаете же🤩 ? Но, кажется, дело все же в другом. ИИ полностью отключает способность думать. Но не у всех: слабый кандидат с ИИ раскрывается в ещё более невыгодном свете, а сильный кандидат, наоборот, поймает синергию. Должно хватать когнитивных возможностей для того, чтобы обрабатывать два параллельных потока, что возможно только при серьезной подготовке.
Вы скажете: "Паранойя!". Возможно, но другой мой коллега пишет:
При этом все же есть хорошие кандидаты, которые не всё знают, но готовы рассуждать и в диалоге приходить к правильному ответу, что более ценно, чем сам правильный ответ.
Лет, наверное, 5 назад мне очень запомнились два менти. Парень и девушка, которые не имели профильного образования и работали в совершенно не связанных с IT сферах. Они только закончили курсы и хотели получить какой-то опыт собеседований. Каждого из них после первого mock-интервью я отправил собирать офферы. Их ответы были точны и по делу. Практически не было вопросов, на которые они не знали ответ, но даже в этом случае они не сдавались. Это были очень приятные собеседования, о которых я до сих пор помню. Ребята нашли работу в течение двух недель. Да, рынок был другой, но у меня не было сомнений, что работодатели будут бороться за таких специалистов.
А что делать интервьюерам?
В рамках подготовки HR-ы могут хотя бы попросить выписку из электронной трудовой. Мы в свою очередь можем, посмотреть активность в Git-репозитории, но тогда никого не наймем...
На самом интервью будем просить включить камеру со второго ракурса и не использовать наушники, как я писал ранее, буду задавать на 80% новый набор вопросов. Вопросы должны быть не в лоб, как, например, "Что такое Index Only Scan?" в контексте анализа плана запроса, а "Чем плох Index Only Scan?". В них по незнанию тяжелее сориентироваться.
Коллеги развивают идею:
Тут главное не переборщить, чтобы не сбить с толку не ИИ-powered кандидата. И, конечно, давать задачки по проектированию, которые очень хорошо показывают ход мыслей кандидата. Без сильной базы даже с ИИ тяжело будет принимать адекватные решения, чтобы добиться поступательного прогресса при возникающих ограничениях.
Такой вот он найм сейчас — крутимся как можем🤩
Коллега пишет:
Есть острое ощущение, что сейчас на скрининге кандидат использовал нейросетку для прохождения собесов: cluely.com
К кому придет на интервью товарищ ... — присмотритесь.
Софтина, конечно, не обязательно именно такая была, но идея понятна: ИИшка разбирает аудиопоток и выдает ответы на вопросы интервьюера в режиме реального времени.
Как это проявлялось:
Структура ответа всегда одинаковая: сначала полная хрень, потом по бумажке. Говорили чуть-чуть про кубер, спросил его про сайдкары. Он резко сменил контекст, начал рассказывать про распределенные транзакции. Стал у него уточнять, выяснилось, что он про saga рассказывает. Видать нейросетка ослышалась.
Буквально вчера столкнулся с подобным на скрининге: на первоначальный вопрос в ответ полная ерунда, затем после незначительного уточнения/повторения развернутый подробный ответ. И так не один раз, а буквально через вопрос. На некоторые — вообще не получил ответ при том, что спрашивал вполне себе базу у разработчика со стажем в 5 лет...
Может я разучился правильно формулировать мысли? Надеюсь, вы меня еще понимаете. Понимаете же
Вы скажете: "Паранойя!". Возможно, но другой мой коллега пишет:
Дочка-студентка рассказывала как ребята сейчас проходят почти любой собес: ставят 2 компа и 2 человека. Второй ищет ответы в нейросетке и показывает первому. Поэтому, если человек сначала говорит фигню, а потом вдруг дает правильный ответ, на мой взгляд, это гарантия подсказок.
При этом все же есть хорошие кандидаты, которые не всё знают, но готовы рассуждать и в диалоге приходить к правильному ответу, что более ценно, чем сам правильный ответ.
Лет, наверное, 5 назад мне очень запомнились два менти. Парень и девушка, которые не имели профильного образования и работали в совершенно не связанных с IT сферах. Они только закончили курсы и хотели получить какой-то опыт собеседований. Каждого из них после первого mock-интервью я отправил собирать офферы. Их ответы были точны и по делу. Практически не было вопросов, на которые они не знали ответ, но даже в этом случае они не сдавались. Это были очень приятные собеседования, о которых я до сих пор помню. Ребята нашли работу в течение двух недель. Да, рынок был другой, но у меня не было сомнений, что работодатели будут бороться за таких специалистов.
А что делать интервьюерам?
В рамках подготовки HR-ы могут хотя бы попросить выписку из электронной трудовой. Мы в свою очередь можем, посмотреть активность в Git-репозитории, но тогда никого не наймем...
Коллеги развивают идею:
Можно задавать вопросы настолько всрато (издалека заходить), что их даже ИИ не разберет.
Тут главное не переборщить, чтобы не сбить с толку не ИИ-powered кандидата. И, конечно, давать задачки по проектированию, которые очень хорошо показывают ход мыслей кандидата. Без сильной базы даже с ИИ тяжело будет принимать адекватные решения, чтобы добиться поступательного прогресса при возникающих ограничениях.
Такой вот он найм сейчас — крутимся как можем
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4❤2🤔1
Все же уже видели ⬆️? В связи с этим:
Идея для стартапа №1
Нужно сделать фейк настолько дип, что задействовано будет все помещение, а видеопотоки будут синхронизироваться на несколько устройств. Причем готовая запись не подойдет — будут просить протереть камеры и покрутиться на стуле💃
Говорят, что современные проблемы требуют современных решений. С собеседованиями же наоборот — вернётся в моду оффлайн формат. Выиграют те компании, у кого офисы и интервьюеры есть в разных локациях. Для малых и даже средних компаний это настоящая головная боль, так как они значительно ограничены географией присутствия. Их продолжат нещадно обманывать... Поэтому у меня на подходе:
Идея для стартапа № 2
В связи с этим все большей популярностью будут пользоваться системы независимой оценки кандидатов.
Linkedin и HH (в рамках Национальной системы подтверждения IT-компетенций🧐 ) уже предлагают подтвердить свои навыки. Правда, в текущем виде ценность для работодателя такой оценки чуть меньше, чем нулевая.
Как это должно выглядеть НА САМОМ ДЕЛЕ? Кандидат приезжает в локацию, где под наблюдением и с использованием средств РЭБ🪖 будет проходить собеседование по заранее выбранным темам. За достоверность результатов компания отвечает в первую очередь своим именем. Это напоминает сдачу сертификационных экзаменов Oracle, которые в России (как, наверное, и везде) можно было сдать только в тестовых центрах Pearson VUE.
———
Видится, что процесс найма и поиска работы станет ещё более длинным. Работягам из глубинки придется ещё чаще перебираться в крупные города, а компании из регионов продолжат довольствоваться малым.
———
Как обычно в этом безумии не проиграют сильные разработчики. Настоящие синьоры нарасхват при любой погоде. Если чувствуешь, что застрял в развитии карьеры, то приходи ко мне на консультацию, чтобы откусить кусочек побольше от лакомого IT-пирога🥰 .
Идея для стартапа №1
Нужно сделать фейк настолько дип, что задействовано будет все помещение, а видеопотоки будут синхронизироваться на несколько устройств. Причем готовая запись не подойдет — будут просить протереть камеры и покрутиться на стуле
Говорят, что современные проблемы требуют современных решений. С собеседованиями же наоборот — вернётся в моду оффлайн формат. Выиграют те компании, у кого офисы и интервьюеры есть в разных локациях. Для малых и даже средних компаний это настоящая головная боль, так как они значительно ограничены географией присутствия. Их продолжат нещадно обманывать... Поэтому у меня на подходе:
Идея для стартапа № 2
В связи с этим все большей популярностью будут пользоваться системы независимой оценки кандидатов.
Linkedin и HH (в рамках Национальной системы подтверждения IT-компетенций
Как это должно выглядеть НА САМОМ ДЕЛЕ? Кандидат приезжает в локацию, где под наблюдением и с использованием средств РЭБ
———
Видится, что процесс найма и поиска работы станет ещё более длинным. Работягам из глубинки придется ещё чаще перебираться в крупные города, а компании из регионов продолжат довольствоваться малым.
———
Как обычно в этом безумии не проиграют сильные разработчики. Настоящие синьоры нарасхват при любой погоде. Если чувствуешь, что застрял в развитии карьеры, то приходи ко мне на консультацию, чтобы откусить кусочек побольше от лакомого IT-пирога
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4👍1🔥1
Как у вас с рекурсивно заданными типами?
Меня в коде они всегда приводят в замешательство🧐 На самом деле, это не что иное, как F-bounded Polymorphism. Попробуем вместе разобраться с этим понятием, и какое отражение оно нашло в Java 👉 тык. В пост телеги контент не влез.
public abstract class Enum<E extends Enum<E>> ...interface Entity<T extends Еntity<T>> ...Меня в коде они всегда приводят в замешательство
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4
Прошёл Легендарную тридцатку!
Последний раз я ходил в трёхнедельный школьно-студенческий поход на Камчатку. Было это более 10 лет назад. В этот раз занетворкался с ребятами из дружественного банка.
Как было круто, можно увидеть на фото. Я же хотел поделиться моим скромным опытом о технической стороне похода.
Оптимизация расходов
Приобрести всю экипировку может стоить достаточно дорого, особенно если вы любите комфорт.
Чтобы не попасть в долговую яму, часть экипировки я взял у друга, а часть — в аренду. Так делали многие ребята.
Палатка
Взял свою старую добрую двухместную Freetime Easy Ride. Она относительно легкая (2.2 кг) и простая в установке, но достаточно серьезно потеет ночью и оборудована одним тамбуром. Сейчас я бы взял что-то более легкое, практичное и технологичное. Можно присмотреться, например, к топовым вариантам от Sea To Summit (одноместная на 1,1 кг, двухместная на 1,4 кг).
Коврик и спальный мешок
Классический коврик не брал. Взял у друга надувной матрас. Было очень удобно, но так как не посмотрел его характеристики, то ночью в сочетании с моим спальником было прохладно. Приходилось утеплять его флисками. мысли на этот счёт:
* спальник я бы брал максимально теплый, но в то же время легкий (до 700-800 гр), например, такой. Если жарко, то его можно просто не застегивать;
* коврик дает защиту от проколов и холода надувному матрасу, но достаточно объемный. Можно рассмотреть утепленные матрасы;
* ребята брали обычные коврики, что не так удобно, но в сочетании с тёплыми спальниками работали хорошо;
* учитывайте одежду, в которой будете спать, чтобы она не крала тепло.
Рюкзак
Желательно подобрать в магазине, предварительно нагрузив. Чем больше регулировок, тем больше шанс что-то поправить непосредственно в походе. Если рюкзак очень большой, не под ваш рост, то никакие регулировки не помогут.
Фонарик
Выбирать нужно такой, где будут хотя бы три режима: автономный для палатки, ближний свет, например, для ужина, чтобы никого не слепить, и дальний для перемещений.
Одежда и обувь (и прочее)
Тут все достаточно просто: нужно проиграть сценарии, в которых будете использовать ту или иную вещь, и берёте в соответствии с ними самый минимум. Всегда ценятся хорошие мембраны и то, что быстро сохнет.
Так как на солнце я быстро сгораю, то мне в этот раз хорошую службу сослужили панама с защитой от солнца 360°, перчатки и брюки-трансформеры с отстёгивающимися штанинами. А вот купленная белая джерси по ощущениям долго сохла, хотя и была очень легкой.
У обоих новых ботинок Millet на третий день в зона сгиба носка отошла прорезиненная защита😐 . Обязательно разносите новые ботинки хотя бы несколько дней до похода.
Итого
Дорогая экипировка делает поход супер комфортным. Бюджетные альтернативы обычно предлагают некоторый компромисс. Независимо от бюджета, придется продумать все до мелочей, чтобы получить от похода удовольствие.
P.S. Если вдруг захотите пройти этот маршрут самостоятельно, то вот гайд от нашего гида. Если возникли вопросы, то заходите в личку или сообщения группы.
Последний раз я ходил в трёхнедельный школьно-студенческий поход на Камчатку. Было это более 10 лет назад. В этот раз занетворкался с ребятами из дружественного банка.
Как было круто, можно увидеть на фото. Я же хотел поделиться моим скромным опытом о технической стороне похода.
Все написанное ниже касается только несложных летних горных походов.
Оптимизация расходов
Приобрести всю экипировку может стоить достаточно дорого, особенно если вы любите комфорт.
Чтобы не попасть в долговую яму, часть экипировки я взял у друга, а часть — в аренду. Так делали многие ребята.
Палатка
Взял свою старую добрую двухместную Freetime Easy Ride. Она относительно легкая (2.2 кг) и простая в установке, но достаточно серьезно потеет ночью и оборудована одним тамбуром. Сейчас я бы взял что-то более легкое, практичное и технологичное. Можно присмотреться, например, к топовым вариантам от Sea To Summit (одноместная на 1,1 кг, двухместная на 1,4 кг).
Коврик и спальный мешок
Классический коврик не брал. Взял у друга надувной матрас. Было очень удобно, но так как не посмотрел его характеристики, то ночью в сочетании с моим спальником было прохладно. Приходилось утеплять его флисками. мысли на этот счёт:
* спальник я бы брал максимально теплый, но в то же время легкий (до 700-800 гр), например, такой. Если жарко, то его можно просто не застегивать;
* коврик дает защиту от проколов и холода надувному матрасу, но достаточно объемный. Можно рассмотреть утепленные матрасы;
* ребята брали обычные коврики, что не так удобно, но в сочетании с тёплыми спальниками работали хорошо;
* учитывайте одежду, в которой будете спать, чтобы она не крала тепло.
Рюкзак
Желательно подобрать в магазине, предварительно нагрузив. Чем больше регулировок, тем больше шанс что-то поправить непосредственно в походе. Если рюкзак очень большой, не под ваш рост, то никакие регулировки не помогут.
Фонарик
Выбирать нужно такой, где будут хотя бы три режима: автономный для палатки, ближний свет, например, для ужина, чтобы никого не слепить, и дальний для перемещений.
Одежда и обувь (и прочее)
Тут все достаточно просто: нужно проиграть сценарии, в которых будете использовать ту или иную вещь, и берёте в соответствии с ними самый минимум. Всегда ценятся хорошие мембраны и то, что быстро сохнет.
Так как на солнце я быстро сгораю, то мне в этот раз хорошую службу сослужили панама с защитой от солнца 360°, перчатки и брюки-трансформеры с отстёгивающимися штанинами. А вот купленная белая джерси по ощущениям долго сохла, хотя и была очень легкой.
У обоих новых ботинок Millet на третий день в зона сгиба носка отошла прорезиненная защита
Итого
Дорогая экипировка делает поход супер комфортным. Бюджетные альтернативы обычно предлагают некоторый компромисс. Независимо от бюджета, придется продумать все до мелочей, чтобы получить от похода удовольствие.
P.S. Если вдруг захотите пройти этот маршрут самостоятельно, то вот гайд от нашего гида. Если возникли вопросы, то заходите в личку или сообщения группы.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4🔥2
Не воруйте у себя семантику!
Я встречаю это сплошь и рядом и сам нередко попадаю в эту ловушку. Покажу, что имею в виду.
Пример 1. Гигантские конструкторы с множеством nullable-аргументов для создания разных по смыслу экземпляров класса
Здесь обычно возникает один неприятный вопрос: "Какие поля обязательны для заполнения в конкретном случае, а какие наоборот — опциональны?". Каждый раз идти в документацию? Нет, спасибо.
Какие есть альтернативы?
1️⃣ подумать над созданием иерархии классов (которая, однако, может быть избыточной)
2️⃣ реализовать ряд фабричных методов например,
3️⃣ выделить несколько компактных конструкторов без "лишних" аргументов (не так очевидны, как фабричные методы, могут потребоваться сопроводительные комментарии)
Пример 2. Использование одних классов для моделей домена и для DTO
Обычно DTO чем-то отличаются от моделей, использующихся на уровне бизнес-логики сервиса. Один из антипаттернов — использовать везде один и тот же класс. Не поленитесь выполнить конвертацию из DTO и обратно. Если этого не делать, то возможны ситуации, когда:
📍nullable-поля будут использоваться как non-nullable
📍некоторые поля будут иметь неточные/неправильные имена и/или типы
📍будете зависеть от новых значений в поле с типом Enum и др.
Пример 3. Дата лучше булевого флага
Так как автоматизация до моего массажиста еще не дошла, то количество оставшихся массажей в абонементе я мониторил с помощью счетчика. Каждый раз, когда посещал массаж — вычитал из счетчика единичку. Всё просто! Конечно же, в какой-то момент я сбился со счёта, так как не помнил, учел ли я очередное посещение. А как надо было? Фиксировать даты посещений.
То же касается фиксации любых событий в целом. Сохраняйте факт свершения события с помощью даты/времени вместо булевого флага. Например, вместо
Пример 4. Обращайтесь с данными бережно!
На проводимых мной интервью в рамках System Design секции многие так и норовят уйти от сырых данных к доменным моделям, которые потребуются для реализации, например, одного из экранов мобильного приложения. Как затем развивать решение? Откуда брать недостающие данные? Память SSD/HDD-накопителей ничего не стоит. Спорно? Точно дешевле, чем упущенные возможности для продукта. Храните все по максимуму, удалить всегда успеете!
===
Какой бы я сделал вывод по работе с данными в системе?
1️⃣ по возможности не теряйте, не упрощайте и не обобщайте данные, которые потом будет не восстановить
2️⃣ опять же по возможности сами дообогащайте их необходимыми метаданными
3️⃣ но на уровне бизнес-логики работайте с максимально простыми и осмысленными моделями
Я встречаю это сплошь и рядом и сам нередко попадаю в эту ловушку. Покажу, что имею в виду.
Пример 1. Гигантские конструкторы с множеством nullable-аргументов для создания разных по смыслу экземпляров класса
Здесь обычно возникает один неприятный вопрос: "Какие поля обязательны для заполнения в конкретном случае, а какие наоборот — опциональны?". Каждый раз идти в документацию? Нет, спасибо.
Какие есть альтернативы?
1️⃣ подумать над созданием иерархии классов (которая, однако, может быть избыточной)
2️⃣ реализовать ряд фабричных методов например,
createBlockedAccount(...), createNewAccount(...)3️⃣ выделить несколько компактных конструкторов без "лишних" аргументов (не так очевидны, как фабричные методы, могут потребоваться сопроводительные комментарии)
Пример 2. Использование одних классов для моделей домена и для DTO
Обычно DTO чем-то отличаются от моделей, использующихся на уровне бизнес-логики сервиса. Один из антипаттернов — использовать везде один и тот же класс. Не поленитесь выполнить конвертацию из DTO и обратно. Если этого не делать, то возможны ситуации, когда:
📍nullable-поля будут использоваться как non-nullable
📍некоторые поля будут иметь неточные/неправильные имена и/или типы
📍будете зависеть от новых значений в поле с типом Enum и др.
Пример 3. Дата лучше булевого флага
Так как автоматизация до моего массажиста еще не дошла, то количество оставшихся массажей в абонементе я мониторил с помощью счетчика. Каждый раз, когда посещал массаж — вычитал из счетчика единичку. Всё просто! Конечно же, в какой-то момент я сбился со счёта, так как не помнил, учел ли я очередное посещение. А как надо было? Фиксировать даты посещений.
То же касается фиксации любых событий в целом. Сохраняйте факт свершения события с помощью даты/времени вместо булевого флага. Например, вместо
true в БД напротив показанного пользователю уведомления о необходимости перехода на новую версию приложения, запишите дату показа уведомления. Согласитесь, это впоследствии дает возможность выполнять гораздо более замысловатые сценарии.Пример 4. Обращайтесь с данными бережно!
На проводимых мной интервью в рамках System Design секции многие так и норовят уйти от сырых данных к доменным моделям, которые потребуются для реализации, например, одного из экранов мобильного приложения. Как затем развивать решение? Откуда брать недостающие данные? Память SSD/HDD-накопителей ничего не стоит. Спорно? Точно дешевле, чем упущенные возможности для продукта. Храните все по максимуму, удалить всегда успеете!
===
Какой бы я сделал вывод по работе с данными в системе?
1️⃣ по возможности не теряйте, не упрощайте и не обобщайте данные, которые потом будет не восстановить
2️⃣ опять же по возможности сами дообогащайте их необходимыми метаданными
3️⃣ но на уровне бизнес-логики работайте с максимально простыми и осмысленными моделями
👍4❤🔥2⚡2🌚2🔥1🤔1
Захотелось поделиться с вами, моими дорогими читателями, некоторыми приемами оптимизации запросов PostgreSQL. Но для того, чтобы оптимизировать запросы, нужны данные, на которых будем делать выборки.
Поэтому подготовил удобный Dockerfile c Postgres и генерацией датасета заданного размера с помощью тулкита TPC–H. Удивительно, но такую задачу как будто никто не решает. Никому не нужно? Или я плохо искал? Буду благодарен, если поделитесь другими подобными проектами, прикреплю их к посту🙏
А что за TPC-H?
Меня интересовал не весь проект TPC-H, а только инструмент генерации данных dbgen. Он генерирует данные для 8 таблиц, связанных между собой. Можно сгенерировать столько данных, сколько укажете в аргументе при сборке образа. Подробнее, как и какие будут генерироваться данные, можно прочитать в четвертой главе спецификации.
Не вдавался в подробности, но в TPC-DS генерируются еще более замысловатые данные для большего числа таблиц. Тут подробнее о других бенчмарках.
И всё же, какие есть альтернативы?
1️⃣ Есть ряд вариантов, предлагающих заранее сгенеренные синтетические данные заданного размера (обычно небольшого). Например, Pagila. Почему-то тоже не нашел свежий образ / Dockerfile.
2️⃣ Использовать реальные датасеты. Один из примеров — история поездок нью-йоркского такси, когда можно поработать с "живыми" данными. Но опять же придется привести данные к такому виду, чтобы их прожевала ваша БД.
Поэтому подготовил удобный Dockerfile c Postgres и генерацией датасета заданного размера с помощью тулкита TPC–H. Удивительно, но такую задачу как будто никто не решает. Никому не нужно? Или я плохо искал? Буду благодарен, если поделитесь другими подобными проектами, прикреплю их к посту
А что за TPC-H?
TPC-H — это бенчмарк (по-простому набор тестов), разработанный организацией Transaction Processing Performance Council (TPC) для оценки производительности СУБД, выполняющих аналитические (OLAP) запросы в стиле Decision Support Systems (DSS), как сами их и называют авторы.
Меня интересовал не весь проект TPC-H, а только инструмент генерации данных dbgen. Он генерирует данные для 8 таблиц, связанных между собой. Можно сгенерировать столько данных, сколько укажете в аргументе при сборке образа. Подробнее, как и какие будут генерироваться данные, можно прочитать в четвертой главе спецификации.
Не вдавался в подробности, но в TPC-DS генерируются еще более замысловатые данные для большего числа таблиц. Тут подробнее о других бенчмарках.
И всё же, какие есть альтернативы?
Please open Telegram to view this post
VIEW IN TELEGRAM
GitHub
GitHub - Sublimee/tpch-postgres-docker: PostgreSQL Docker image with preloaded [TPCH benchmark](http://www.tpc.org/tpch/) dataset…
PostgreSQL Docker image with preloaded [TPCH benchmark](http://www.tpc.org/tpch/) dataset for analytics and performance testing - Sublimee/tpch-postgres-docker
👍2🔥2❤🔥1
Оптимизация PostgreSQL. Часть 1
Данные сгенерировали. Теперь можно и запросы повыполнять. Но прежде...
№0. Определимся с тем, что значит "запрос работает долго"
С какимSQL-запросом к нам могут прийти?
или таким
или
или
В каждом из примеров нельзя однозначно сказать, есть ли в принципе дефект производительности БД.
В любом случае для идентификации проблемы (если она вообще есть) мы должны опираться на метрики, не ограничиваясь метриками самой БД.
Придется учитывать множество факторов, а именно какие, сколько и как меняются во времени:
* объем и свойства хранимых данных;
* пользовательские сценарии и конкретные запросы, которые формируют профиль нагрузки.
Также важно, какое железо и ОС мы используем и как они себя чувствуют, как настроен кластер PostgreSQL и составляющие его инстансы (от размеров буферов до есть ли и какие используются балансировщики, как настроена репликация и т.д.).
№1. Долго на клиенте ≠ долго на сервере
Выполним запрос на клиенте с замером времени:
В postgresql.conf предварительно подключим расширение pg_stat_statements для сбора статистики по запросам:
и посмотрим среднее время выполнения запроса:
Разница с временем выполнения на клиенте (real) в 6+ секунд! Оно и понятно: запрашивается большое количество строк — целых 6000000, которые участвуют в времязатратном I/O.
№2. Однородные запросы — устойчивый кэш
Если выполнить запрос выше несколько раз, то в статистике pg_stat_statements можно увидеть, что 1491 страница из 359840 были прочитаны из кэша:
Чем больше вы запрашиваете одни и те же данные, тем больше страниц попадет в кэш, и тем больше страниц будет из него вычитываться впоследствии. Конечно, с этой точки зрения выгоднее делать запросы меньшего числа строк (страниц).
№3. EXPLAIN ANALYZE BUFFERS
У EXPLAIN есть много опций. Опция BUFFERS позволяет посмотреть на использование буферов по аналогии с pg_stat_statements:
№4. Index Scan vs Index Only Scan
Если с Index Scan в плане запроса знакомы чуть более чем все, то про понятие Index Only Scan исходя из моего опыта собеседований не знает практически никто. В чем между ними разница? Index Only Scan — это когда всё необходимое для выполнения запроса лежит в индексе и мы не пойдем в индексируемую таблицу. Такой индекс для запроса называется покрывающим (covering). Чтобы его сделать таковым часто используют директиву INCLUDE. Она позволяет включить в индекс колонки, которые не будут участвовать в поиске.
Найдем, например, все контакты богатых клиентов:
Исходя из этого легко выводится правило:
№5. SELECT * почти всегда плохо
Запрос, который ещё вчера выполнялся в рамках Index Only Scan, после появления очередной колонки пойдет за данными в таблицу. Даже если таких запросов у вас нет, то не забываем про правило №1: на время выполнения запроса влияет объем данных, который пройдет через I/O-операции. Также стоит рассмотреть возможность фильтрации и группировки на сервере, а не на клиенте.
Скоро вернусь со следующей частью 🫶
Данные сгенерировали. Теперь можно и запросы повыполнять. Но прежде...
№0. Определимся с тем, что значит "запрос работает долго"
С каким
Мы перестали укладываться в метрики скорости загрузки веб-страницы с отчётом.
или таким
Раньше запрос выполнялся 5 секунд, а сейчас — 2 минуты.
или
На конфах рассказывают про 10 миллионов запросов в секунду, а мы держим просто 10.
или
На интеграционном стенде все летало, а на проде все очень медленно.
В каждом из примеров нельзя однозначно сказать, есть ли в принципе дефект производительности БД.
В любом случае для идентификации проблемы (если она вообще есть) мы должны опираться на метрики, не ограничиваясь метриками самой БД.
Придется учитывать множество факторов, а именно какие, сколько и как меняются во времени:
* объем и свойства хранимых данных;
* пользовательские сценарии и конкретные запросы, которые формируют профиль нагрузки.
Также важно, какое железо и ОС мы используем и как они себя чувствуют, как настроен кластер PostgreSQL и составляющие его инстансы (от размеров буферов до есть ли и какие используются балансировщики, как настроена репликация и т.д.).
№1. Долго на клиенте ≠ долго на сервере
Выполним запрос на клиенте с замером времени:
time psql -h localhost -p 5432 -U postgres -d tpch -c "SELECT * FROM customer;" 1>/dev/null
real 0m7.624s
user 0m6.911s
sys 0m0.395s
В postgresql.conf предварительно подключим расширение pg_stat_statements для сбора статистики по запросам:
shared_preload_libraries = 'pg_stat_statements'
и посмотрим среднее время выполнения запроса:
{...,"query":"SELECT * FROM customer",...,"mean_exec_time":1061.95576325,...,"rows":6000000,...}Разница с временем выполнения на клиенте (real) в 6+ секунд! Оно и понятно: запрашивается большое количество строк — целых 6000000, которые участвуют в времязатратном I/O.
№2. Однородные запросы — устойчивый кэш
Если выполнить запрос выше несколько раз, то в статистике pg_stat_statements можно увидеть, что 1491 страница из 359840 были прочитаны из кэша:
...,"shared_blks_hit":1491,"shared_blks_read":358349,...
Чем больше вы запрашиваете одни и те же данные, тем больше страниц попадет в кэш, и тем больше страниц будет из него вычитываться впоследствии. Конечно, с этой точки зрения выгоднее делать запросы меньшего числа строк (страниц).
№3. EXPLAIN ANALYZE BUFFERS
У EXPLAIN есть много опций. Опция BUFFERS позволяет посмотреть на использование буферов по аналогии с pg_stat_statements:
EXPLAIN (ANALYZE,BUFFERS) SELECT c_name, c_phone FROM customer;
QUERY PLAN
----------
...
Buffers: shared hit=584 read=35400
...
№4. Index Scan vs Index Only Scan
Если с Index Scan в плане запроса знакомы чуть более чем все, то про понятие Index Only Scan исходя из моего опыта собеседований не знает практически никто. В чем между ними разница? Index Only Scan — это когда всё необходимое для выполнения запроса лежит в индексе и мы не пойдем в индексируемую таблицу. Такой индекс для запроса называется покрывающим (covering). Чтобы его сделать таковым часто используют директиву INCLUDE. Она позволяет включить в индекс колонки, которые не будут участвовать в поиске.
Найдем, например, все контакты богатых клиентов:
CREATE INDEX customer_acctbal_idx ON customer (c_acctbal) INCLUDE (c_name, c_phone);
EXPLAIN ANALYZE (SELECT c_name, c_phone FROM customer WHERE c_acctbal > 9999);
QUERY PLAN
----------
Index Only Scan using customer_acctbal_idx on customer ...
Исходя из этого легко выводится правило:
№5. SELECT * почти всегда плохо
Запрос, который ещё вчера выполнялся в рамках Index Only Scan, после появления очередной колонки пойдет за данными в таблицу. Даже если таких запросов у вас нет, то не забываем про правило №1: на время выполнения запроса влияет объем данных, который пройдет через I/O-операции. Также стоит рассмотреть возможность фильтрации и группировки на сервере, а не на клиенте.
Скоро вернусь со следующей частью 🫶
🔥4👌1
Оптимизация PostgreSQL. Часть 2
№6. Избегайте колонок с большими данными
PostgreSQL не очень приспособлен к работе с большими строками и массивами байт. Так сложилось исторически. Лучше взять MongoDB. Хорошая оптимизация😃 ?
Механизм, который позволяет PostgreSQL обойти скромное ограничение размера одной страницы (8 кб) называется...
TOAST — это сочетание сжатия данных и использования вспомогательной таблицы, в которую мы будем сгружать поля в колонках, которые весят более 2 килобайт. Из основной таблицы у нас будут указатели на TOAST-таблицу.
Я уж хотел расписать здесь все нюансы работы TOAST, но за меня гораздо лучше это сделают документация и статьи (одна из тех, что понравилась своей лаконичностью). Вам лишь надо помнить про такой механизм и то, что он дается бесплатно (упаковка/распаковка + работа с данными через указатели на отдельную таблицу).
№7. Играемся с числом WPR
Сам придумал эту абревиатуру. Она означает Workers Per Request. Так как все данные у нас побиты на страницы, то логично параллелить работу с ними, что и делает PostgreSQL. Убедимся в этом, изучив план запроса:
Итак:
* Gather указывает на сбор результатов от параллельных воркеров
* вместо Seq Scan видим Parallel Seq Scan
* использовались 2 дополнительных воркера (Workers Planned: 2 и Workers Launched: 2)
* loops=3 вместо loops=1 при Seq Scan означает, что все данные были разбиты на 3 порции, по одной для каждого из воркеров
Если установить
то увидим классическое:
Посмотрим, какие результаты получатся при разном количестве дополнительных воркеров. Занес все получившиеся результаты в таблицу (каждый тест запускал ~10 раз для получения достоверных результатов):
При max_parallel_workers_per_gather >= 7 значения Workers Planned и Workers Launched оставались равными 7 и больше не поднимались. Видно, что рост производительности нелинейный: чем больше воркеров, тем меньше прирост. После превышения определённого числа потоков результат может становится даже хуже. С точки зрения ресурсов параллельный план использует суммарно больше CPU, чем один поток, так как каждый воркер нагружает отдельное ядро. Подробнее, как обычно, читаем в прекрасной доке.
Какие можно сделать выводы?
* выгодно увеличить число воркеров на ненагруженном сервере
* снижение числа воркеров приводит к экономному использованию ресурсов сервера, но запрос будет занимать больше времени при неполной утилизации процессора
Продолжение следует...
№6. Избегайте колонок с большими данными
PostgreSQL не очень приспособлен к работе с большими строками и массивами байт. Так сложилось исторически. Лучше взять MongoDB. Хорошая оптимизация
Механизм, который позволяет PostgreSQL обойти скромное ограничение размера одной страницы (8 кб) называется...
TOAST — это сочетание сжатия данных и использования вспомогательной таблицы, в которую мы будем сгружать поля в колонках, которые весят более 2 килобайт. Из основной таблицы у нас будут указатели на TOAST-таблицу.
Я уж хотел расписать здесь все нюансы работы TOAST, но за меня гораздо лучше это сделают документация и статьи (одна из тех, что понравилась своей лаконичностью). Вам лишь надо помнить про такой механизм и то, что он дается бесплатно (упаковка/распаковка + работа с данными через указатели на отдельную таблицу).
№7. Играемся с числом WPR
Сам придумал эту абревиатуру. Она означает Workers Per Request. Так как все данные у нас побиты на страницы, то логично параллелить работу с ними, что и делает PostgreSQL. Убедимся в этом, изучив план запроса:
EXPLAIN (ANALYZE, BUFFERS) SELECT * FROM lineitem WHERE l_shipdate = '1996-02-12';
Gather (cost=1000.00..1440944.55 rows=23732 width=117) (actual time=18.547..1262.696 rows=24553 loops=1)
Workers Planned: 2
Workers Launched: 2
Buffers: shared hit=420 read=1124724
-> Parallel Seq Scan on lineitem (cost=0.00..1437571.35 rows=9888 width=117) (actual time=45.016..1245.409 rows=8184 loops=3)
Filter: (l_shipdate = '1996-02-12'::date)
Rows Removed by Filter: 19987166
Buffers: shared hit=420 read=1124724
Planning Time: 0.056 ms
Execution Time: 1264.008 ms
Итак:
* Gather указывает на сбор результатов от параллельных воркеров
* вместо Seq Scan видим Parallel Seq Scan
* использовались 2 дополнительных воркера (Workers Planned: 2 и Workers Launched: 2)
* loops=3 вместо loops=1 при Seq Scan означает, что все данные были разбиты на 3 порции, по одной для каждого из воркеров
Если установить
SET max_parallel_workers_per_gather = 0;
то увидим классическое:
Seq Scan on lineitem (cost=0.00..1874969.65 rows=23732 width=117) (actual time=15.584..3395.071 rows=24553 loops=1)
Filter: (l_shipdate = '1996-02-12'::date)
Rows Removed by Filter: 59961499
Buffers: shared hit=676 read=1124468
Planning Time: 0.049 ms
Execution Time: 3396.748 ms
Посмотрим, какие результаты получатся при разном количестве дополнительных воркеров. Занес все получившиеся результаты в таблицу (каждый тест запускал ~10 раз для получения достоверных результатов):
количество доп. воркеров | Execution Time, ms
---------------------------------------------
0 | 3396.748
1 | 1774.959
2 | 1264.008
3 | 942.845
4 | 801.769
5 | 690.721
6 | 628.289
7 | 571.944
8 | 567.589
При max_parallel_workers_per_gather >= 7 значения Workers Planned и Workers Launched оставались равными 7 и больше не поднимались. Видно, что рост производительности нелинейный: чем больше воркеров, тем меньше прирост. После превышения определённого числа потоков результат может становится даже хуже. С точки зрения ресурсов параллельный план использует суммарно больше CPU, чем один поток, так как каждый воркер нагружает отдельное ядро. Подробнее, как обычно, читаем в прекрасной доке.
Какие можно сделать выводы?
* выгодно увеличить число воркеров на ненагруженном сервере
* снижение числа воркеров приводит к экономному использованию ресурсов сервера, но запрос будет занимать больше времени при неполной утилизации процессора
Продолжение следует...
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4❤2
This media is not supported in your browser
VIEW IN TELEGRAM
Продолжаем следить за своим здоровьем!
После постов 1 и 2 прошел уже практически год, а это значит, что скоро пора сдавать мои ежегодные профилактические анализы крови.
В этот раз наваял для себя вот такой списочек. Попытался отказаться от всего узкоспецифичного, оставив основательный мониторинг состояния организма в целом и основных его систем. Также оставил немногочисленные комментарии, чтобы внести некоторую ясность. Точную сумму пока не посчитал, но будет около 40-60 т.р в зависимости от финального списка. Чтобы сэкономить, нужно поискать актуальные промокоды и акции (просим за нас это сделать ChatGPT🪖 ).
Это пока хороший черновик, который требуется еще раз поревьюить с ChatGPT (режим глубокого исследования — моё почтение!) и врачами📝 . Но это уже достаточно хорошая база, от которой можно отталкиваться, чтобы начать погружаться в тему.
Если вы хотите пойти по моим стопам, но не знаете, с чего начать, то могу порекомендовать такой алгоритм действий:
1) скопировать мой список анализов к себе в таблицу
2) с нейронкой в режиме глубокого исследования указываете свою специфику:
• какие цели преследуете (для меня — это профилактика заболеваний и коррекция питания, тренировок)
• какой у вас образ жизни (питание / тренировки / стрессы / курение / алкоголь)
• с чем связана работа (сидячая / стоячая / на ногах, вредное производство и т.п.)
• есть ли конкретные симптомы (например, болят суставы) и хроника (например, утомляемость, проблемы с ЖКТ)
• результаты предыдущих анализов
3) просите на основе оригинального списка скорректировать его под ваш запрос
Всех благ❤️
После постов 1 и 2 прошел уже практически год, а это значит, что скоро пора сдавать мои ежегодные профилактические анализы крови.
В этот раз наваял для себя вот такой списочек. Попытался отказаться от всего узкоспецифичного, оставив основательный мониторинг состояния организма в целом и основных его систем. Также оставил немногочисленные комментарии, чтобы внести некоторую ясность. Точную сумму пока не посчитал, но будет около 40-60 т.р в зависимости от финального списка. Чтобы сэкономить, нужно поискать актуальные промокоды и акции (просим за нас это сделать ChatGPT
Это пока хороший черновик, который требуется еще раз поревьюить с ChatGPT (режим глубокого исследования — моё почтение!) и врачами
Если вы хотите пойти по моим стопам, но не знаете, с чего начать, то могу порекомендовать такой алгоритм действий:
1) скопировать мой список анализов к себе в таблицу
2) с нейронкой в режиме глубокого исследования указываете свою специфику:
• какие цели преследуете (для меня — это профилактика заболеваний и коррекция питания, тренировок)
• какой у вас образ жизни (питание / тренировки / стрессы / курение / алкоголь)
• с чем связана работа (сидячая / стоячая / на ногах, вредное производство и т.п.)
• есть ли конкретные симптомы (например, болят суставы) и хроника (например, утомляемость, проблемы с ЖКТ)
• результаты предыдущих анализов
3) просите на основе оригинального списка скорректировать его под ваш запрос
Всех благ
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5👍2