Говорят, что можно бесконечно смотреть на огонь, наблюдать за тем, как работают другие, а также изучать DDD (Domain Driven Design, предметно-ориентированное проектирование). Но если у вас есть только 10 минут — можно прочитать эту статью и пройтись по самым верхушкам, а потом с умным видом кивать головой во время светской беседы.

Покрутили и рассмотрели DDD с разных сторон вместе с Андреем Ратушным — техническим директором компании Югорские Интернет Решения.

В последнее время много копий сломано вокруг технических собеседований. Очевидно, что инвертирование двоичного дерева на доске практически никак не связано с практическими навыками реального программиста. Примитивный Fizzbuzz по-прежнему остаётся самым эффективным тестом. Как следствие, выросло внимание к опенсорсным проектам, но оказалось, что это тоже не очень хороший показатель, потому что у большинства профессионалов нет на них времени.

У нас в компании самое эффективное собеседование по программированию на сегодняшний день — это обычно какое-то домашнее задание на несколько дней, в котором кандидата просят исправить баг или реализовать небольшую функцию. Это не очень хорошо, потому что занимает много времени, и человек может получить внешнюю помощь (или погуглить, если функция достаточно распространённая). С другой стороны, некоторые крупные компании вместо этого удвоили количество собеседований с доской (и алгоритмами), подвергая будущих инженеров многочасовым сессиям онлайн-программирования с различным уровнем инвазивного наблюдения.

Все эти методы интервью не сравнятся с очень простой метрикой: совместная игра в Factorio. Прохождение всего цикла Factorio — практически идеальный показатель, насколько хорошо человек решает общие технические проблемы. Можно даже настроить прохождение игры на основе будущей должности, чтобы лучше понять, как кандидат справится со своей ролью.

Есть один карточный трюк, который запомнился мне навсегда. Вот его краткое описание: доброволец выбирает карту и запечатывает её в конверт. Затем фокусник предлагает добровольцу выбрать чай. У него есть десятки коробок чая, и все они упакованы в пластик. Доброволец выбирает одну из коробок, срывает обёртку и выбирает один из упакованных пакетиков с чаем. Потом он вскрывает упаковку, и… внутри оказывается его карта.

Если вы не хотите знать, в чём хитрость этого трюка, то дальше не читайте.

Секрет трюка прозаичен, но меня он привёл в восторг. К выбору карты добровольца подталкивают. Однако выбор из этих десятков коробок с чаем на самом деле свободный, и выбор чайного пакетика внутри коробки тоже делается свободно. Здесь нет никакой ловкости рук: фокусник не касается коробок или выбранного добровольцем чайного пакетика. Карта на самом деле находится внутри этой упаковки чайного пакетика.

Вся хитрость заключается в подготовке. Перед выполнением фокуса фокусник покупает десятки коробок чая, вскрывает каждую и разворачивает каждую упаковку с чайным пакетиком. Кладёт в каждую упаковку тройку крестей. Снова запечатывает упаковку. Возвращает упаковки обратно в коробку. Снова запечатывает каждую коробку. И повторяет так сотни раз. На это уходят часы, может быть, даже дни.

«Фокусом» это является именно потому, что такая подготовка выглядит настолько скучной, настолько невозможно монотонной, что когда мы видим трюк, то не можем представить, что кто-то проделал бы столь скучную работу, чтобы добиться такого простого эффекта.

Этот день — яркий пример того, как несколько вещей, которые сами по себе не приводят к отказу, могут удачно совпасть. Итак, 23 апреля было совершенно обычным днём, с обычным трафиком и обычной загрузкой ресурсов. Как обычно, с запасом больше трети, чтобы при потере любого из ЦОДов пережить это без проблем. Никто не думал, что к серверному мониторингу нужно прикручивать ещё мониторинг того, что говорит президент на прямой линии, поэтому дальше случилось вот что:



Примерно в 13:30 у нас резко подскочила нагрузка на поиск по авиации и по железнодорожным билетам. Где-то в этот момент РЖД сообщила о перебоях на сайте и в приложении, а мы начали экстренно наливать дополнительные инстансы бекендов во всех ЦОДах.

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

Аристотель придумал, что в риторике есть четыре главных способа убеждения. Пафос — через эмоции и повествование. Логос — через факты и логику. Этос — через авторитет того, что убеждает. Есть еще кайрос, фактор контекста: того, когда вас пытаются убедить и при каких условиях.

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

Что же, ответ у меня есть. Я считаю, что этос — это бич мыслящего человека. Кайрос — кандалы, который выковал информационный век. А понимание того, как работает риторика — базовый инструмент критического мышления. Особенно для IT-специалиста.

Я так много рассказывал об этом на кухнях и в чатах, что решил написать статью. А получился лонгрид с научными исследованиями, разбором влияния алгоритмических новостных лент, и безумным комиксом из мемов, который я делал 4 часа в Фигме. Поехали!

UPD Большое спасибо всем тем людям, что помогли мне исправить ошибки и очепятки! Только на Хабре так стремятся помочь, и это неоценимо.

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

Эти знания особенно важны в том случае, когда приложение, которым занимается разработчик, достигает определённого размера. Если уделять утечкам памяти недостаточно внимания, то всё может закончиться тем, что разработчик, в итоге, попадёт в «команду по устранению утечек памяти» (мне доводилось входить в состав такой команды).



Утечки памяти могут возникать по разным причинам. Однако я полагаю, что при использовании Angular можно столкнуться с паттерном, который соответствует самой распространённой причине возникновения утечек памяти. Существует и способ борьбы с такими утечками памяти. А лучше всего, конечно, не бороться с проблемами, а избегать их.