В самом начале моей карьеры мы собеседовали тимлида Г. На собеседовании Г. был хорош, уверен в себе и показал отличные технические знания, и мы его взяли. Но буквально через пару недель человек начал вести себя не очень корректно с моей точки зрения. Я решил посоветоваться со своим непосредственным руководителем:

— Как-то мне не очень комфортно и приятно будет работать с человеком, который такое вот делает. Наверное, надо нам с ним расстаться.

На что мой руководитель резонно мне ответил:

— ${zloy_stas}, таких, как этот Г., в твоей работе будет много; если ты будешь увольнять каждого, кто тебе не понравился лично, ты быстро перестанешь быть руководителем. Твоя задача — не детей с ними крестить, а извлекать из них пользу и уметь с ними работать. Пусть этот Г. будет для тебя таким менеджерским челленджем.

Это был очень хороший урок, и действительно, умение работать с не очень приятными людьми — важный и нужный навык для любого руководителя. И я встретился по жизни еще не с одним «трудным» подчиненным. 

Поговорим сегодня о поведении, а точнее о тех психологических проблемах, с которыми мне приходилось сталкиваться на практике. Это будет разговор про ситуации и проблемы, которые не всегда фатальны; про людей, которые ещё могут быть полезны. При этом мы все знаем, что делать с совсем неподходящими людьми ;)

Удивительно, но некоторые разработчики до сих пор считают, что коммуникации в работе не нужны или даже вредны. «Наша задача кодить, а не болтать». Конечно это эффективнее некуда, сидеть три часа и пытаться самостоятельно разобраться, как работает соседний сервис, вместо того чтобы просто спросить у коллеги и получить ответ за 15 минут. Или додумывать за ПО спорные моменты в задаче, а потом выкинуть 90 % работы и переделать заново после первого демо. Или не услышать или не понять критику на обсуждении технического решения, а потом переделывать, костылить, велосипедить и получать критические ошибки и блокеры в середине спринта. Или начать сразу разрешать инцидент, не рассказав про него владельцу продукта и бизнесу, и получить тонны негативной обратной связи от клиентов и бизнеса. Или внезапно узнать, что можно было бы обойтись меньшей кровью, ничего не разрабатывая, а решив проблему административными методами.

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

В экосистеме Node.js существует довольно много библиотек и фреймворков, которые пользуются определенной популярностью в сообществе. Но ни один из инструментов не решил главную проблему, с которой сталкиваются разработчики, когда пытаются писать бэкенд на Node.js. Это проблема выбора архитектуры.

Хочу обратить ваше внимание на относительно молодой фреймворк Nest.js. Из коробки он предлагает заранее предопределенную архитектуру, которая заточена под максимально удобную поддержку и масштабируемость вашего приложения. Заложенные архитектурные подходы проверены временем и давно используются в других, более зрелых платформах: Java(Spring), Python(Django), PHP(Laravel) и прочих.

Авторы Nest.js не скрывают, что их вдохновил один из популярных фреймворков для клиентских приложений — Angular.js, а его авторы ориентировались на походы, используемые в Java и C#. Если вы знакомы с Angular.js, то увидите в Nest.js много схожих идей.

Самый плохой разработчик — тот, который всё делает по ТЗ. А самый лучший код — не написанный.

«Моя задача — писать код, я разработчик!» — да, это очень удобная позиция. Но людям, которые не только программируют, но ещё и общаются с коллегами, организуют собственную работу и понимают предметную область, платят больше. Потому что они приносят бизнесу больше пользы. Разработчики, которых надо микроменеджерить, чтобы они делали свою работу, никому не нужны.

Основная обязанность разработчика — это решить проблему. Не написать код, не отдать задачу на тестирование, а решить проблему. Писать код по спецификациям может любой дурак (на самом деле тоже нет). А вот решать проблемы — нет. Для этого надо думать и брать на себя ответственность.

Это история не про любовь, мир, жвачку и миссию компании, а про простую способность сделать свою работу так, чтобы она была сделана хорошо. И да, для этого разработчик должен не только уметь программировать, но и уметь общаться с другими людьми, уметь доносить свои мысли, уточнять и понимать, что вообще происходит. То есть уметь договариваться. Да, разработчик должен уметь организовывать свою работу: раскладывать проблему на задачи. Ещё он должен интересоваться продуктом (проектом). Не потому что разработчик так его любит, и не потому, что этого требует Agile, а потому, что живой интерес к продукту и понимание его ценности увеличивает качество решений и стоимость разработчика на рынке. Знание предметной области и её ограничений — первейшее требование для того, чтобы принять правильное техническое и архитектурное решение. И очевидно, что чем меньше руководитель тратит сил на управление сотрудником и чем больше получает результат, — то есть чем выше автономность сотрудника, его самостоятельность и беспроблемность, — тем он ценнее при прочих равных.

Тот, кто научится правильно измерять продуктивность разработчиков, точно станет миллионером. Особенно на текущем рынке труда, где кандидаты просто называют случайные пятизначные числа желаемой зарплаты. Есть несколько вендорских платных решений, но они не получили распространения. Никто не ставит такую систему по умолчанию, как, например, CI/CD. Давайте посмотрим на возможные подходы к измерению продуктивности и поговорим об этом в комментариях.

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

У Филиппа Кросби заслуженная репутация лидера в вопросах качества в обрабатывающей промышленности, он написал множество книг о качестве в период с 1968 по 1999 год. Среди его известных и цитируемых работ — «Качество бесплатно», «Ноль дефектов с помощью предотвращения» и «4 абсолютных принципа качества». Хотя Кросби говорил об этих темах в контексте компаний с производственными линиями, его уроки часто без изменений можно перенести на разработку ПО.

После участия в Твиттере во многих обсуждениях работ Кросби и прочтения некоторых его книг, я написал эту статью, чтобы передать на более глубоком уровне мои мысли о «4 абсолютных принципах качества» Кросби из его книги «Качество бесплатно». По моему мнению, эти четыре принципа поддерживают дискуссии о концепции отсутствия дефектов и качестве без затрат.

Примечание: у Кросби много хороших работ! Эта заметка не критикует его творчество. Она подчёркивает, как я использовал идеи Кросби и применил их в контексте моей работы с программным обеспечением. Вы можете согласиться со мной, а можете не согласиться. И это нормально. Я лишь делюсь своими знаниями и взглядом на мир качества в моём представлении.

Четыре абсолютных принципа качества

1. Качество определяется как соответствие требованиям.

2. Способ обеспечения качества — предотвращение, а не оценка.

3. Стандартом работы должно быть Отсутствие Дефектов.

4. Мера качества — цена несоответствия, а не индексы.

Всем привет!

В этой статье я хотел бы рассказать о некоторых мерах, которые мы применяем (ну, или почти применяем) в ДомКлик для обеспечения надежности работы наших сервисов. Честно говоря, возможно, какие-то из этих процедур избыточны, но ежегодный аудит и постоянные проверки заставляют нас дуть на воду и готовиться к худшему.

Также я постараюсь подробно отразить свою субъективную оценку по каждому из перечисленных мероприятий, на предмет сложности реализации и эффективности.

В 2021 году рынок IT — и, в частности, рынок инженеров, которые позиционируют себя как DevOps, — остается перегретым, и пока нет тенденции к его охлаждению. Спрос на специалистов высокого уровня превышает предложение. Компании, конкурируя за перспективных работников, готовы предлагать хорошие условия. Проблема заключается в том, что в погоне за высокими зарплатами пострадало качество набора. Сегодня хотелось бы поговорить о том, какие кандидаты будут привлекать работодателя выдать заветный оффер.

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

def foo():
try:
return 1
finally:
return 2

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

Привет. Сегодня я расскажу о работе с геоданными в PostgreSQL и немного о том, как это сделать в своем Java/Kotlin-приложении.

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

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

Добро пожаловать под кат, далее будет интересно.

Представим, что в системе есть баг, но абсолютно непонятно, как его воспроизвести, а на поиск причин тратится куча времени, и ты чувствуешь себя детективом. Наверное, вам это знакомо?

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

• что такое PageSpeed;
• как измеряется и оценивается производительность;
• лирическое отступление: critical render path;
• способы оптимизации PageSpeed;
• для чего это нужно?

Для асинхронного Python существует мало полноценных ORM, и им далеко до таких монстров-комбайнов, как DjangoOrm и SQLAlchemy.ORM. Бедность ORM-инструментария для асинхронного программирования заставила многих программистов отказаться от зачастую непонятной им работы с ORM и перейти к более прозрачному взаимодействию с БД. Решение в лоб — написание raw SQL, но в этом случае запросы не будут защищены от инъекций, а запросы, составляемые по бизнес логике с опциональными параметрами, превратятся в конкатенацию строк. Важно найти баланс между прозрачностью выполнения кода, скоростью его написания и читаемостью.

Ниже я предлагаю реализацию такого баланса c использованием SQLAlchemy Core.

Всем привет! В бытность мою, когда я самостоятельно изучал Python, я находил достаточно теоретического материала о языке и его возможностях. Однако даже после прочтения нескольких статей на разных сайтах и книг многое не укладывались у меня в голове (да, вот такой вот я тугой). Непонятные концепции приходилось зубрить «на веру» без глубокого понимания, потому что практические примеры в статьях были для меня сложны. Время шло, я становился опытнее, понимание приходило на практических задачах, и в какой-то момент я стал учить Python'у своих друзей. В рамках наставничества я обнаружил, что, кажется, наметил путь, по которому можно объяснять сложные концепции простыми словами.

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

Сегодня хочется ещё раз поговорить о генераторах. Итак, в бой!

Липкие сессии (Sticky-session) — это особый вид балансировки нагрузки, при которой трафик поступает на один определенный сервер группы. Как правило, перед группой серверов находится балансировщик нагрузки (Nginx, HAProxy), который и устанавливает правила распределения трафика на доступные сервера.

В первой части цикла мы уже разобрали как создавать липкие сессии с помощью Nginx. Во второй части разберем создание подобной балансировки средствами Kubernetes.

Так как статьи в основном направлены на начинающих - придется коснуться основ kubernetes. Да-да, я знаю в интернете полно материала для изучения куба. Но здесь будет минимум душной теории и максимум практики. Лучше один раз развернуть тестовое приложение в кластере и понять основные принципы, чем читать тонну скучных мануалов.

Доброго времени суток, уважаемые читатели!

Меня зовут Евгений Когтев, я ведущий разработчик в команде Web Core в ДомКлик. Мы уже рассказывали подробнее о команде и стоящих перед ней задачах, если не читали, то рекомендую. А сегодня я расскажу, зачем нужен онбординг и как его реализовать в UI-kit.

Меня зовут Алексей Казаков, я техлид команды «Клиентские коммуникации» в ДомКлик. В большинстве приложений, с которыми мне приходилось иметь дело, при взаимодействии с БД не ограничиваются лишь драйвером, который позволяет выполнять сырые запросы. Для удобства и избавления от SQL-запросов внутри, например, Python-кода дополнительно используют библиотеки (Object Relational Mapper, ORM).

Это первая статья в серии, посвященной различным ORM. Начнём мы с DjangoORM.

В статье о возможности загружать Linux с VHD был предложен способ загружать Linux на машине с Windows без необходимости разбивать диск на разделы. Но было одно существенное ограничение: рассматривался только вариант загрузки BIOS, т.е. legacy-загрузки. Сейчас появляется всё больше устройств без поддержки режима legacy (например, многие ноутбуки, выпущенные в 2020 году). Поэтому в этой статье будет рассмотрена загрузка Linux с VHD на компьютерах с UEFI.