Size: a a a

2020 April 24
FEDOR BORSHEV
Как публичная активность влияет на работу CTO?

Вышел новый совет, где я рассказываю, нужно программистам и CTO выходить в свет или нет. Спойлер — если не знаете зачем, то и не нужно.
источник
2020 April 25
FEDOR BORSHEV
Начинаем стрим через 15 минут

Поговорим об облачной разработке — расскажу про состояние Visual Studio Code Online и покажу, как я поднимаю удалённые машины через ansible.

https://www.youtube.com/watch?v=Y0JraNE8ZRI
источник
2020 April 27
FEDOR BORSHEV
Почему я открыто делюсь исходным кодом (и +2 открытых проекта на Django)

Разработчики, которые приходят на мои проекты, часто удивляются, почему я с такой лёгкостью открываю свои наработки — добавляю в репозитории в гитхабе, даю доступ на сервера и передаю документацию. Ведь обычно все прячут исходный код за семью печатями — не делятся доступами, присылают странные zip-архивы без папки .git и т.д. Я где-то даже видел команду, которая обфусцировала код, прежде чем выложить на гитхаб.

Я так делаю потому, что у меня есть большая цель (только не смейтесь) — я хочу, чтобы как можно больше программистов радовались своей работе. Если программисты не просто делают свою работу, а радуются — они работают гораздо быстрее. Если бы все программисты в мире работали быстрее — многое поменялось бы для человечества в целом: быстрее бы появлялись и умирали новые стартапы, проверялось бы больше гипотез, а значит росло бы количество цифровых продуктов. Представляете, сколько та же яндекс-лавка сэкономила москвичам времени на походах в магазин? А если бы нас посадили на карантин в 2015 году, когда её не было? А ведь уже тогда были доступны все технологии, на которых она работает. Уверен, даже идеи были. Надо было только напрогать.

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

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

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

На прошлой неделе я открыл два важных проекта на Django:
education-backend: это активный коммерческий проект — бекенд, которым я пользуюсь чтобы брать деньги вебинары.
f213/django — мой стартер проектов на django с батарейками: pytest, 12-факторностью, кучей линтеров и ещё много чем.

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

Я надеюсь, что мои исходники послужат кому-то примером того, что можно писать коммерческий код для удовольствия.

Если вам нравится, что я делаю, меня легко отблагодарить — посоветуйте канал друзьям, поставьте звёзду на гитхабе или поддержите мою деятельность на патреоне.
источник
2020 April 29
FEDOR BORSHEV
Выбросьте свой гитлаб

Осторожно — дальше ничем не обоснованное личное мнение

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

Наверное такие команды выбрали гитлаб потому, что сделали табличку, в которой сравнили его с гитхабом по количеству фич, и увидели, что у гитлаба их больше и они бесплатнее. К сожалению, такие таблички не показывают, что большинство фич гитлаба недоделаны и не дотягивают до конкурентов:
— CI поощряет писать шелл-скрипты, как в двухтысячных. Хотите собирать в докере — пилите свой образ с бойлерплейтом вроде apt-get --no-install-recommends install git
— Бесплатный облачный CI не работает — ваш проект просто висит в очереди и не билдится.
— Реестр контейнеров глючит, разрывает соединение и вообще не работает.

UI гитлаба не годится никуда: примеру на странице пулл-реквеста кнопка «закрыть и забить» в два раза больше, чем кнопка «смёрджить», а список коммитов запрятан в отдельную вкладку.

Любой новый хипстерский робо-ai-валидатор пулл-реквестов скорее всего не поддерживает гитлаб — если хотите автоматизации, пишите шелл-скрипты. Никакого probot с десятками полезных расширений, никакого CircleCI и других интеграций — всё что есть, это гора встроенных неработающих фич.

Если вы цените время своих коллег — мигрируйте на гитхаб прямо сейчас, это бесплатно.
источник
2020 April 30
FEDOR BORSHEV
#вакансия #работамечты

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

На беке у нас REST и Django, на фронте пока нет ничего. По технологиям хотим vue.js, больше никаких ограничений нет.

Работа удалённая, команда отличная, заказчик американский, оплата в долларах.

Присылайте пару строк о себе и ссылку на гитхаб на fedor@borshev.com
источник
2020 May 01
FEDOR BORSHEV
PostgreSQL anonymizer

Нашёл классный экстеншн для постгреса — PostgreSQL anonymizer — он простым декларативным синтаксисом вырезает из базы всё, что связано с персольной информацией пользователей.

Им можно вырезать имена из ночных дампов или прямо из базы.

Если вы всё ещё не на auth0 и сами вынуждены работать с персональными данными — мастхев.

P.S. Осталось два дня до повышения цены на мой вебинар об автоматизации разработки. Приходите — поговорим ещё о десятке таких нужных инструментов и о том, как их внедрять
источник
2020 May 02
FEDOR BORSHEV
Вебинар об автоматизации разработки переносится на 30 мая

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

Новая дата — 30 мая, суббота, 14:00.

Если вдруг вам неудобна эта дата или вы разочаровались в самой идее вебинара — просто напишите в саппорт на сайте, мы без вопросов вернём вам деньги.

А чтобы не было так грустно, я проведу ещё один бесплатный devops-стрим на следующей неделе, и продлю льготный период для покупки билетов ещё на неделю — если всё ещё хотите послушать интересный рассказ о том, как сделать, чтобы за вас работали роботы — сейчас самое время купить.
источник
2020 May 04
FEDOR BORSHEV
#вопрос Где проходит граница между зонами ответственности тимлида и менеджера проекта? Вроде и тот, и тот должны отвечать за сроки и качество выполненной работы. И тот, и тот должны общаться с командой, понимать состояние ребят, помогать им расти. Можешь рассказать о своём опыте?

В таких вопросах придерживаюсь agile: считаю, что  важнее не выстраивать чёткую оргуструктуру, а делать так, чтобы каждый человек был на своём месте.

Есть менеджеры, которым интересно говорить с программистами и разбираться, как всё устроено. Такому менеджеру я бы доверил больше полномочий с территории тимлида, к примеру звал бы на технические обсуждения. Есть тимлиды, которым интересно менеджить — таких я бы звал на встречи с бизнесом и доверял бы какие-то проекты, если они им интересны, конечно.

Я думаю вам стоит просто поговорить с конкретным менеджером и конкретным тимлдиом по отдельности, выяснить, что они хотят от работы, и дальше распределить обязанности так, чтобы всем было интересно.
источник
2020 May 06
FEDOR BORSHEV
Учим докер

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

9 мая в 14:00, приходите на стрим
источник
2020 May 08
FEDOR BORSHEV
Уровень ЗП зависит от ответственности

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

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

Человек, который может организовать работу целой команды, получает больше, чем человек, которого надо менеджить. Программист, который принимает красивые архитектурные решения, стоит больше, чем программист, который за месяц превратит проект в лазанью: качество кода — это такая же ответственность.
источник
2020 May 09
FEDOR BORSHEV
Начинаем через 15 минут

Как и обещал, в прямом эфире будем докеризировать Django-приложение, разбирая каждый шаг — https://youtu.be/t8gZD0lwu2k
источник
2020 May 11
FEDOR BORSHEV
Продолжаю рассказывать об аккуратном коде в «советах» — в прошлый четверг вышел совет о заменяемости. Кто знает — это L из SOLID, кто не знает — читайте и разбирайте примеры.
источник
2020 May 13
FEDOR BORSHEV
Чек-лист: на что смотреть, когда затягиваешь новую библиотеку

Зависимости — кошмар любого большого проекта: они приводят к уязвимостям, конфликтуют друг с другом, протухают и блокируют обновление фреймворка. Так получается потому, что добавить в проект зависимость не стоит ничего, а вот поддерживать её (или просто выпилить) — огромный труд.

Кроме очевидного способа минимизировать проблемы от зависимостей (поменьше их притаскивать, кек), есть ещё простая гигиена, которая помогает упростить жизнь. Прежде чем набрать npm install или что там у вас, найдите репозиторий зависимости в Гитхабе и проверьте его:
— Не смотрите на количество лайков.
— Есть ли тесты? Понятно ли написаны?
— Посмотрите 5 минут на код. Удаётся ли понять, как он работает?
— Были ли значимые (не «version bump») коммиты в последние полгода?
— Подходит ли лицензия вашему проекту?
— Не смотрите на количество лайков.
— Растёт или падает количество скачиваний (можно найти в npm/pypi).
— Сколько висит неотвеченных пулл-реквестов?
— Какие issues обсуждают?
— Понятно ли написано ридми, много ли документации?

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

Есть что добавить в чек-лист? Напишите на fedor@borshev.com
источник
2020 May 15
FEDOR BORSHEV
Органы чувств

Вот упал у вас прод, вы заходите по ssh и видите, что Load Average больше, чем количество ядер, в 10 раз. Люди не могут воспользоваться сервисом, партнёры задают вопросы, а всё, что вы знаете, — это то, что нагрузка выше в 10 раз, чем номинальная. Вы начинаете искать по логам (медленно, сервер-то перегружен), запускать `ps` и `strace` и совершать другие шаманские действия. Чувствуете, что двигаетесь по тёмному лесу с закрытыми глазами, как бегуны из старого клипа Pendulum.

Думаю, в такой ситуации был каждый опытный бэкендер. Я — точно несколько раз.

Выход простой — сделайте себе нормальные органы чувств. Заведите мониторинг с дашбордами, которые покажут топ самых нагруженных эндпоинтов API (отдельно по запросам, отдельно — по затраченному машинному времени), состояние серверов и 4 золотых сигнала (время ответа, количество запросов, рейт ошибок и запас нагрузки). Через пару аварий дополните собственные сигналы: скажем, мы в iGooods, пока не разобрались с падающей сетевой картой на сервере с БД, вывели нагрузку на неё на все борды.

Подойдёт что угодно — datadog, newrelic, можете даже Графану с Прометеусом поставить: главное, чтобы у вас были глаза и уши.

P. S. Мы подробно поворим об органах чувств devops на вебинаре об автоматизации 30 мая. Завтра цена участия будет выше, если ещё не купили билет — поторопитесь.
источник
2020 May 18
FEDOR BORSHEV
Каждый понедельник я отвечаю на один конкретно поставленный вопрос с насущной проблемой.

Вот, что интересного было в последнее время:
— Стоит ли уходить из агентства в продуктовую разработку?
Что делать, если разработчик начал фейлить из-за карантина
— Как найти удалённую работу на полставки
ООП или ФП?
— Как оценить успешность или неуспешность фичи после релиза
— Почему ты работаешь стоя?

Чтобы получить публичный ответ на свой насущный вопрос, нужно написать мне на fedor@borshev.com, конфиденциальность гарантирую.
источник
2020 May 20
FEDOR BORSHEV
Говори только с тем, кто принимает решения

Простое правило, которое знают все продажники, но напрочь игнорируют программисты, — говори только с тем человеком, который принимает финальные решения.

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

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

Если руководитель вашей команды допустил такую ситуацию один или два раза — ничего, бывает. Если допускает системно — гоните его в шею и говорите напрямую с теми, кто принимает решения — они, скорее всего, будут только рады.
источник
2020 May 22
FEDOR BORSHEV
Письмо с зарплатой

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

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

Ловите шаблон:

- Ты выходишь к нам на испытательный срок с зарплатой ХХ рублей.
- Испытательный срок продлится до 2 месяцев.
- По окончании испытательного срока твоя зарплата составит YY рублей.
- Критерии окончания испытательного срока — такие-то. Или: критерии окончания испытательного срока мы с тобой обсудим ХХ июня.
- Деньги переводим тебе на ИП / ГПХ / в пенсионный фонд / что там у вас.
- 25 числа каждого полного месяца получаешь аванс, 8 — расчёт за прошлый месяц.
источник
2020 May 25
FEDOR BORSHEV
#вопрос как прокачивать скиллы, будучи интровертом?

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

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

Ответственность нужно забирать целиком — не договариваться с менеджером типа «давай я сам попробую», а взять проект без менеджера и возглавить его самому: общаться с заказчиком, помогать команде строить планы, разруливать конфликты, не терять самообладание, когда всё идёт не так.

Если получится перед этим встать и громко объявить всей компании, что за такой-то проект теперь отвечаете вы — будет вообще круто.

Я пока не до конца понимаю те механизмы, которые стоят за этой магией, но подозреваю, что именно они описаны в «Шкуре на кону» Талеба — нужные скиллы просто сами появляются.
источник
2020 May 27
FEDOR BORSHEV
100500 плохих сигналов

Почти все больные системы мониторинга, которые я видел, объединяет одна черта — они шлют бесполезные алёрты.

Какая разница, что места на сервере осталось 20 гигов или что выросло количество соединений в состоянии TIME_WAIT? Человек, которого PagerDuty отрывает от пикника с друзьями, хочет знать ответ на простой вопрос — надо ли прямо сейчас всё бросать и чинить проблему? Метрики с железок на такой вопрос никогда не ответят.

Чтобы ответить, нужно смотреть на бизнесовые метрики. Они у каждого свои, но в роли базовых стоит использовать 4 золотых сигнала, о которых я недавно писал: время ответа, запас по CPU, количество запросов и количество ошибок. Если все 4 параметра в норме, то в бизнесе, скорее всего, всё ок. И наоборот, если какой-то параметр выбивается — нужно лечить.

P.S. Мой вебинар об автоматизации уже в эту субботу! Там будет целая секция про мониторинг и devops, приходите.
источник
2020 May 28
FEDOR BORSHEV
Что делать, если меня отстраняют от дел?

В бюрошных советах вышел мой ответ на очень интересный вопрос — что делать техдиру, если пришёл новый генеральный и потихоньку выкидывает его из команды?

Почитайте тут — https://bureau.ru/soviet/20200521/.

Полезно получилось ответить?
источник