В нашей индустрии принято ругать (или просто не любить) галеры. Особенно — их владельцев: типа вписываются в сложные и дорогие контракты благодаря подвешенному языку, а затем набирают десяток джунов и навариваются, пока клиент не сообразит, во что вляпался. Я и сам раньше был на этой стороне, возможно потому, что моя юность прошла именно на такой галере.
За полгода владения собственным аутсорсом я, конечно же, поменял мнение. Должность рулевого на галере — самая неблагодарная из всех. За последние полгода я, к примеру:
— Два раза избежал «блокировки» юрлица (оказывается, в нашей стране даже удалённая компания даже во время пандемии должна иметь офис).
— Нанял, уволил, затем опять нанял бухгалтерию. Первая не любила свою работу, что обошлось бизнесу в полмиллиона рублей.
— Просрочил исполнение договора на два месяца, из-за чего эти два месяца вся команда была для клиента бесплатной.
— Два раза находился в ситуации, когда не понимал, будут ли у нас деньги, чтобы заплатить зарплату — хранить подушку безопасности для маленького бизнеса очень дорого, в отличие от частника.
— Публично подписался под абсолютный срок, запустил работы, а договор не подписал. Надеюсь, всё будет хорошо.
Ну а самое главное — эти полгода были периодом самой большой неопределённости в моей жизни: даже когда я был CTO в венчурном стартапе или уходил в свободное плавание с Саматом, вся ответственность ограничивалась мной и семьёй. Не так уж и много в 2021 году: даже если ты остался без денег, идёшь писать код в условный Яндекс и жизнь снова налажена.
В бизнесе совсем другая ответственность: как бы ни штормило корабль, два раза в месяц нужно откуда-то доставать зарплату. И пофиг, что контрагент, на которого ты рассчитывал, ушёл в отпуск, или ему «нужно пару недель подумать», чтобы принять работу — команда должна получать деньги.
Полгода прошло, неопределённости стало меньше, и за зарплату я уже не переживаю. Нам с Саматом уже есть чем гордиться — за эти полгода мы перезапустили Сноб (скоро будет пост с подробностями), сделали с нуля пару секретных проектов и прямо сейчас начинаем ещё три. Судя по обратной связи, ребята тоже довольны: у нас есть чему поучиться, мы не работаем по часам, общаемся асинхронно, у нас нет жиры, дейли-митингов и прочей херни.
Если хотите с нами — мы нанимаем бекендеров, фронтендеров, менеджеров и девопса-стажёра.
За полгода владения собственным аутсорсом я, конечно же, поменял мнение. Должность рулевого на галере — самая неблагодарная из всех. За последние полгода я, к примеру:
— Два раза избежал «блокировки» юрлица (оказывается, в нашей стране даже удалённая компания даже во время пандемии должна иметь офис).
— Нанял, уволил, затем опять нанял бухгалтерию. Первая не любила свою работу, что обошлось бизнесу в полмиллиона рублей.
— Просрочил исполнение договора на два месяца, из-за чего эти два месяца вся команда была для клиента бесплатной.
— Два раза находился в ситуации, когда не понимал, будут ли у нас деньги, чтобы заплатить зарплату — хранить подушку безопасности для маленького бизнеса очень дорого, в отличие от частника.
— Публично подписался под абсолютный срок, запустил работы, а договор не подписал. Надеюсь, всё будет хорошо.
Ну а самое главное — эти полгода были периодом самой большой неопределённости в моей жизни: даже когда я был CTO в венчурном стартапе или уходил в свободное плавание с Саматом, вся ответственность ограничивалась мной и семьёй. Не так уж и много в 2021 году: даже если ты остался без денег, идёшь писать код в условный Яндекс и жизнь снова налажена.
В бизнесе совсем другая ответственность: как бы ни штормило корабль, два раза в месяц нужно откуда-то доставать зарплату. И пофиг, что контрагент, на которого ты рассчитывал, ушёл в отпуск, или ему «нужно пару недель подумать», чтобы принять работу — команда должна получать деньги.
Полгода прошло, неопределённости стало меньше, и за зарплату я уже не переживаю. Нам с Саматом уже есть чем гордиться — за эти полгода мы перезапустили Сноб (скоро будет пост с подробностями), сделали с нуля пару секретных проектов и прямо сейчас начинаем ещё три. Судя по обратной связи, ребята тоже довольны: у нас есть чему поучиться, мы не работаем по часам, общаемся асинхронно, у нас нет жиры, дейли-митингов и прочей херни.
Если хотите с нами — мы нанимаем бекендеров, фронтендеров, менеджеров и девопса-стажёра.
Начинайте с данных, а не с кода
Важный урок, который я усвоил на Снобе — если в проекте присутствуют старые данные, особенно с легаси-сервисами, то начинать надо не с попыток запилить как можно больше фич, а с этих самых данных.
Вот представьте ситуацию — вы делаете каталог книг. В базе есть автор, есть книга, отношение многие ко многим — всё как положено. Смотрите в легаси — схема данных вроде соответствует. Создаёте модельки у себя, строите вокруг этого фичи — API для фронтенда, выгрузку в elasticsearch.
Перед запуском проекта финально импортируете данные и замечаете, что у некоторых книг подозрительно много авторов — по базе выходит, что «Анну Каренину» написал не только Лев Толстой, но и Ксения Собчак. Начинаете разбираться и выясняете, что у автора книги в легаси-базе есть бинарный флаг «рецензент», и если человек указан как рецензент, то считается, что он не писал эту книгу, а только рецензировал. Было это 10 лет назад, в те времена рецензии хранились как комментарии к товарам. С тех пор рецензии никто не писал, но старые нужно переносить, а авторов чистить — иначе SEO-шники съедят. И вам обо всём этом не сказал никто, включая тех же SEO-шников, пока вы их сами не спросили.
И вот вы в ночь перед дедлайном делаете новую сущность в системе, добавляете API, переписываете импорт, санитизируете данные. Выясняете, что ваша обёртка над эластиком может отдавать только посты — переписываете и её. И всё это потому что данные принесли вам требование, о котором никто не сказал. А если бы начали с данных — ещё в процессе переноса узнали бы о существовании рецензий, поменяли бы скоуп, и закончили бы вовремя.
Важный урок, который я усвоил на Снобе — если в проекте присутствуют старые данные, особенно с легаси-сервисами, то начинать надо не с попыток запилить как можно больше фич, а с этих самых данных.
Вот представьте ситуацию — вы делаете каталог книг. В базе есть автор, есть книга, отношение многие ко многим — всё как положено. Смотрите в легаси — схема данных вроде соответствует. Создаёте модельки у себя, строите вокруг этого фичи — API для фронтенда, выгрузку в elasticsearch.
Перед запуском проекта финально импортируете данные и замечаете, что у некоторых книг подозрительно много авторов — по базе выходит, что «Анну Каренину» написал не только Лев Толстой, но и Ксения Собчак. Начинаете разбираться и выясняете, что у автора книги в легаси-базе есть бинарный флаг «рецензент», и если человек указан как рецензент, то считается, что он не писал эту книгу, а только рецензировал. Было это 10 лет назад, в те времена рецензии хранились как комментарии к товарам. С тех пор рецензии никто не писал, но старые нужно переносить, а авторов чистить — иначе SEO-шники съедят. И вам обо всём этом не сказал никто, включая тех же SEO-шников, пока вы их сами не спросили.
И вот вы в ночь перед дедлайном делаете новую сущность в системе, добавляете API, переписываете импорт, санитизируете данные. Выясняете, что ваша обёртка над эластиком может отдавать только посты — переписываете и её. И всё это потому что данные принесли вам требование, о котором никто не сказал. А если бы начали с данных — ещё в процессе переноса узнали бы о существовании рецензий, поменяли бы скоуп, и закончили бы вовремя.
Системно радоваться
Любой команде нужно показывать успехи — и отдельных людей, и команды в целом. Без успехов — пусто, скучно и грустно. В конце концов успехи — это обратная связь, без неё люди не работают. Показывать успехи можно на ретро, на встречах 1:1, да и вообще при любом удобном случае.
Здесь сейчас расскажу о механизмах, которые я использую, чтобы делать это автоматически.
— В первую очередь это бейскемп. Он рассылает дайджесты проектов на почту каждый день — в них видно, кто и когда какую задачу закрыл.
— Для команд, которые состоят из одних только программистов, я использую Ежедневный Герой — сервис, который делает дайджест закрытых пулл-реквестов.
— В Школе у нас есть специальный канал, который так и называется «Радость» — в него приходят уведомления о каждом новом участнике курса.
Делайте системы, которые вас радуют, — так вся команда, включая вас, будет чувствовать себя гораздо лучше.
Любой команде нужно показывать успехи — и отдельных людей, и команды в целом. Без успехов — пусто, скучно и грустно. В конце концов успехи — это обратная связь, без неё люди не работают. Показывать успехи можно на ретро, на встречах 1:1, да и вообще при любом удобном случае.
Здесь сейчас расскажу о механизмах, которые я использую, чтобы делать это автоматически.
— В первую очередь это бейскемп. Он рассылает дайджесты проектов на почту каждый день — в них видно, кто и когда какую задачу закрыл.
— Для команд, которые состоят из одних только программистов, я использую Ежедневный Герой — сервис, который делает дайджест закрытых пулл-реквестов.
— В Школе у нас есть специальный канал, который так и называется «Радость» — в него приходят уведомления о каждом новом участнике курса.
Делайте системы, которые вас радуют, — так вся команда, включая вас, будет чувствовать себя гораздо лучше.
Чукча не читатель, чукча — писатель
В последнее время, когда у меня спрашивают, откуда я нахожу время на блог или книгу, я отвечаю этой фразой из старого советского анекдота.
Это действительно так — чтобы много писать, нужно мало читать (вернее, много, но сложного контента — об этом расскажу как-нибудь). Недавно я осознал, что начал действительно много писать примерно через месяц после того, как сел на информационную диету: отписался от всех в фейсбуке, удалил RSS-читалку и заблокировал «Медузу» через /etc/hosts. Мне просто стало скучно — я перестал жечь бесчисленное количество энергии на изучение сетевых срачей или мысли о том, как сорвать побольше лайков в фейсбучке.
До сих пор моё общение с внешним миром крайне ограничено: я не пользуюсь соцсетями, не читаю новостей, не слушаю радио, а в телеграме я читаю каналы всего нескольких людей, которых знаю лично. Свободное время (то, в которое в обществе принято тупить в телефон) я трачу либо на размышления, либо на тексты.
В последнее время, когда у меня спрашивают, откуда я нахожу время на блог или книгу, я отвечаю этой фразой из старого советского анекдота.
Это действительно так — чтобы много писать, нужно мало читать (вернее, много, но сложного контента — об этом расскажу как-нибудь). Недавно я осознал, что начал действительно много писать примерно через месяц после того, как сел на информационную диету: отписался от всех в фейсбуке, удалил RSS-читалку и заблокировал «Медузу» через /etc/hosts. Мне просто стало скучно — я перестал жечь бесчисленное количество энергии на изучение сетевых срачей или мысли о том, как сорвать побольше лайков в фейсбучке.
До сих пор моё общение с внешним миром крайне ограничено: я не пользуюсь соцсетями, не читаю новостей, не слушаю радио, а в телеграме я читаю каналы всего нескольких людей, которых знаю лично. Свободное время (то, в которое в обществе принято тупить в телефон) я трачу либо на размышления, либо на тексты.
Асинхронная архитектура: стартуем в четверг
Когда мы в прошлом году начинали с Антоном курс об асинхронной архитектуре, мы были уверены, что делаем узкоспециализированный хард-скилловый курс.
Когда мы заканчивали контент, я пересмотрел весь курс целиком и понял, что в уроках мы говорим на темы, важные не только архитекторам, но и всем бекендерам: зачем нужна типизация, как должны эволюционировать структуры данных, как вытягивать из бизнеса информацию о происходящем и почему не стоит делать асинхронный сервис для отправки СМС.
Окончательно я убедился, когда во время запуска второго потока мы говорили с учениками прошлых потоков. За прошедшие полгода ребятам удалось улучшить качество проектирования и начать более продуктивно говорить с бизнесом. На мой взгляд, самый ценный для бизнеса навык, который нам удалось привить — это умение думать о системах в терминах отказоустойчивости: чтобы пользователь не терял данные, когда у кого-то из партнёров на 30 минут упало API.
Курс получился широким и софт-скилльным — идеально подходит для Школы Сильных Программистов.
Переработанный второй поток стартует в этот четверг — ещё можно успеть (а если у вас быстрая бюрократия — успеете даже оплатить от компании). Промокод M4C4W даст вам скидку 10%.
Когда мы в прошлом году начинали с Антоном курс об асинхронной архитектуре, мы были уверены, что делаем узкоспециализированный хард-скилловый курс.
Когда мы заканчивали контент, я пересмотрел весь курс целиком и понял, что в уроках мы говорим на темы, важные не только архитекторам, но и всем бекендерам: зачем нужна типизация, как должны эволюционировать структуры данных, как вытягивать из бизнеса информацию о происходящем и почему не стоит делать асинхронный сервис для отправки СМС.
Окончательно я убедился, когда во время запуска второго потока мы говорили с учениками прошлых потоков. За прошедшие полгода ребятам удалось улучшить качество проектирования и начать более продуктивно говорить с бизнесом. На мой взгляд, самый ценный для бизнеса навык, который нам удалось привить — это умение думать о системах в терминах отказоустойчивости: чтобы пользователь не терял данные, когда у кого-то из партнёров на 30 минут упало API.
Курс получился широким и софт-скилльным — идеально подходит для Школы Сильных Программистов.
Переработанный второй поток стартует в этот четверг — ещё можно успеть (а если у вас быстрая бюрократия — успеете даже оплатить от компании). Промокод M4C4W даст вам скидку 10%.
Корпоративный 1password
Всего есть два способа передавать пароли — личные аккаунты на корп. почту (норм) или пошаренные на всех пароли, переданные через личку (дно). Мне почти всегда удавалось избежать шаринга общих паролей, но вот в нашем с Саматом аутсорсе — не смог. Там от шаринга паролей никуда не деться: это и доступы в клиентские системы, где на выбивание пароля для одного программиста нужно потратить два часа менеджера, и личные кабинеты, которые не поддерживают создание нескольких пользователей, и даже хероку, куда мне пришлось давать доступ бухгалтерии, потому что только владелец может скачивать оригиналы счетов.
Огородные решения, вроде собственного экземпляра Bitwarden или вообще какого-нибудь KeePassX мы отмели сразу. Поизучав SaaS-ы, мы остановились на 1password. На мой взгляд, 1password — единственный удобный менеджер личных паролей под мак: моментально синхронизируется, выглядит не стыдно в отличие от LastPass, удобно встраивается в сафари и на самом деле всё заполняет, в отличие от Dashlane, который пасует перед сложными формами, вроде входа в Тинькофф-банк. Это важно, потому что предлагая на работе 1password, мы подталкиваем всех сотрудников перейти на него — не будешь же иметь два менеджера паролей на одном компьютере.
Живём с ним уже несколько месяцев, через полгода расскажу как дела.
Всего есть два способа передавать пароли — личные аккаунты на корп. почту (норм) или пошаренные на всех пароли, переданные через личку (дно). Мне почти всегда удавалось избежать шаринга общих паролей, но вот в нашем с Саматом аутсорсе — не смог. Там от шаринга паролей никуда не деться: это и доступы в клиентские системы, где на выбивание пароля для одного программиста нужно потратить два часа менеджера, и личные кабинеты, которые не поддерживают создание нескольких пользователей, и даже хероку, куда мне пришлось давать доступ бухгалтерии, потому что только владелец может скачивать оригиналы счетов.
Огородные решения, вроде собственного экземпляра Bitwarden или вообще какого-нибудь KeePassX мы отмели сразу. Поизучав SaaS-ы, мы остановились на 1password. На мой взгляд, 1password — единственный удобный менеджер личных паролей под мак: моментально синхронизируется, выглядит не стыдно в отличие от LastPass, удобно встраивается в сафари и на самом деле всё заполняет, в отличие от Dashlane, который пасует перед сложными формами, вроде входа в Тинькофф-банк. Это важно, потому что предлагая на работе 1password, мы подталкиваем всех сотрудников перейти на него — не будешь же иметь два менеджера паролей на одном компьютере.
Живём с ним уже несколько месяцев, через полгода расскажу как дела.
Forwarded from Ilya Birman
Илья Бирман ищет девопса для помощи с его блоговым сервисом на базе Эгеи
Смысл сервиса в том, чтобы подключить свой домен к нашему серверу и пользоваться Эгеей, ничего не устанавливая самому:
http://blogengine.ru/hosted/
«Я ищу нового помощника, который будет отвечать за всю серверно-инфраструктурную часть. Сейчас всё просто работает и ничего срочного делать не надо. Первая конкретная задача будет — настроить новый автоматический и регулярный бекап всего. Сейчас бекап тоже есть, но нужно переделать, объясню.
Чтобы начать, нужно разбираться во всяких таких штуках: CentOS, Nginx, webkaos, Apache, mod_php, PHP-FPM, FastCGI, MariaDB, Let’s Encrypt, certbot — это то, что используется сейчас. Глеб написал подробный документ про то, как у нас всё устроено и настроено, ну и если что ответит на вопросы.
При этом я открыт к предложениям по модернизации всего хозяйства. Фёдор говорит, что надо Докер — ну, я не против, свежие версии Эгеи с ним дружат, и я готов допиливать дальше. Было бы круто сделать, чтобы всем было суперлегко и приятно управлять — добавлять пользователей, обновлять само приложение без простоя, легко откатывать в случае проблем, восстаналиваться из бекапа и так далее.
Пока у нас около сотни пользователей, но хочется сделать какой-то шаг вперёд. Например, настроить приём платежей и автоматическое создание платных акаунтов.»
Если вам могло бы быть интересно, напишите Илье по почте ilyabirman@ilyabirman.ru или в телеграм @ilyabirman и расскажите о том, как вы работаете и что вам нужно, чтобы начать.
Смысл сервиса в том, чтобы подключить свой домен к нашему серверу и пользоваться Эгеей, ничего не устанавливая самому:
http://blogengine.ru/hosted/
«Я ищу нового помощника, который будет отвечать за всю серверно-инфраструктурную часть. Сейчас всё просто работает и ничего срочного делать не надо. Первая конкретная задача будет — настроить новый автоматический и регулярный бекап всего. Сейчас бекап тоже есть, но нужно переделать, объясню.
Чтобы начать, нужно разбираться во всяких таких штуках: CentOS, Nginx, webkaos, Apache, mod_php, PHP-FPM, FastCGI, MariaDB, Let’s Encrypt, certbot — это то, что используется сейчас. Глеб написал подробный документ про то, как у нас всё устроено и настроено, ну и если что ответит на вопросы.
При этом я открыт к предложениям по модернизации всего хозяйства. Фёдор говорит, что надо Докер — ну, я не против, свежие версии Эгеи с ним дружат, и я готов допиливать дальше. Было бы круто сделать, чтобы всем было суперлегко и приятно управлять — добавлять пользователей, обновлять само приложение без простоя, легко откатывать в случае проблем, восстаналиваться из бекапа и так далее.
Пока у нас около сотни пользователей, но хочется сделать какой-то шаг вперёд. Например, настроить приём платежей и автоматическое создание платных акаунтов.»
Если вам могло бы быть интересно, напишите Илье по почте ilyabirman@ilyabirman.ru или в телеграм @ilyabirman и расскажите о том, как вы работаете и что вам нужно, чтобы начать.
#вопрос Вот мы постоянно проверяем программистов на качество. Скажи, а как проверить на профпригодность девопсов?
Когда мы на испытательном сроке проверяем программистов, мы проверяем не хард-скиллы, а умение выполнять обещания — все же знают, что не важно насколько ты крутой питонист, если ты не можешь сдать вовремя задачу.
С девопсами мы будем проверять то же самое — умение выполнять обещания. Сложность в том, что программистов легче проверять, даже не разбираясь в коде: если чувак прошёл код-ревью у других программистов и раскатал задачу в срок, значит он скорее всего сделал работу хорошо. Но у нас нет столько девопсов, чтобы проверять качество работы: вдруг чувак настроит инфраструктуру, в которой деплой будет ломаться по три раза в неделю? Или мониторинг, который не будет срабатывать? Или просто не будет реагировать на свои же собственные инциденты?
Увы, пока мы не умеем массово нанимать девопсов, нам придётся вручную отслеживать производительность нового сотрудника. То есть я сам буду делать код-ревью и следить за тем, чтобы вещи случались. Вырастем — у нас появится такая же методика для девопсов, как и для программистов.
Это был вопрос изнутри F&S, но вообще каждый понедельник я отвечаю на один конкретно поставленный вопрос. Задавайте на fedor@borshev.com
Когда мы на испытательном сроке проверяем программистов, мы проверяем не хард-скиллы, а умение выполнять обещания — все же знают, что не важно насколько ты крутой питонист, если ты не можешь сдать вовремя задачу.
С девопсами мы будем проверять то же самое — умение выполнять обещания. Сложность в том, что программистов легче проверять, даже не разбираясь в коде: если чувак прошёл код-ревью у других программистов и раскатал задачу в срок, значит он скорее всего сделал работу хорошо. Но у нас нет столько девопсов, чтобы проверять качество работы: вдруг чувак настроит инфраструктуру, в которой деплой будет ломаться по три раза в неделю? Или мониторинг, который не будет срабатывать? Или просто не будет реагировать на свои же собственные инциденты?
Увы, пока мы не умеем массово нанимать девопсов, нам придётся вручную отслеживать производительность нового сотрудника. То есть я сам буду делать код-ревью и следить за тем, чтобы вещи случались. Вырастем — у нас появится такая же методика для девопсов, как и для программистов.
Это был вопрос изнутри F&S, но вообще каждый понедельник я отвечаю на один конкретно поставленный вопрос. Задавайте на fedor@borshev.com
ГдеМатериал, в котором я когда-то работал, ищет CTO
Вот что пишет CEO, Алим:
«Если у вас есть опыт в сфере управления разработкой и командами, то приглашаем рассмотреть вакансию ИТ-партнера/СТО/Техлида в команду Гдематериал.
Гдематериал это технологичный DIY-маркетплейс. Мы выходим на новый рынок, интегрируем сайт Изолюкс, который теперь наш, запускаем мобильное приложение, строим свою логистику - предстоит много амбициозных задач. Наше лицо удобная онлайн витрина, а сердце — бекофис, где происходит вся магия распределения заказов по нужным людям, поставщикам и складам.
Вы получите полную свободу действий, возможность формировать команду и свободный удаленный график. Вы точно прокачаете бизнес навыки, потому что команда проекта, включая СЕО понимает про продукт и говорит о проблемах и метриках.
Нам важно, чтобы человек на этой позиции не только писал код и проектировал архитектуру, но и думал о том, какую проблему он решает и какая в этом ценность.
Описание вакансии, стек, задачи, требования и контакты, можно посмотреть тут:
https://gdml.notion.site/48a2338294844c669fb8dee1eb06884a»
Вот что пишет CEO, Алим:
«Если у вас есть опыт в сфере управления разработкой и командами, то приглашаем рассмотреть вакансию ИТ-партнера/СТО/Техлида в команду Гдематериал.
Гдематериал это технологичный DIY-маркетплейс. Мы выходим на новый рынок, интегрируем сайт Изолюкс, который теперь наш, запускаем мобильное приложение, строим свою логистику - предстоит много амбициозных задач. Наше лицо удобная онлайн витрина, а сердце — бекофис, где происходит вся магия распределения заказов по нужным людям, поставщикам и складам.
Вы получите полную свободу действий, возможность формировать команду и свободный удаленный график. Вы точно прокачаете бизнес навыки, потому что команда проекта, включая СЕО понимает про продукт и говорит о проблемах и метриках.
Нам важно, чтобы человек на этой позиции не только писал код и проектировал архитектуру, но и думал о том, какую проблему он решает и какая в этом ценность.
Описание вакансии, стек, задачи, требования и контакты, можно посмотреть тут:
https://gdml.notion.site/48a2338294844c669fb8dee1eb06884a»
Самый быстрый способ передать контекст новичку
База знаний — сложная штука: писать её лень, да и протухает постоянно, особенно на проектах в начальной стадии. Мы в F&S практикуем быстрый (пусть и грязный) способ передавать знания новичкам — записываем все созвоны.
Способ грязный потому, что новичку при входе на проект прилетает гора видео на десяток часов, хотя мы могла бы прилететь аккуратная вики, которую можно прочитать за час. Если посмотреть на это с точки зрения бизнеса, способ не такой уж и грязный — ведь любой джун это инвестиция. Грубо говоря, если у джуна 1 час приносит компании -1500 рублей, то чем меньше я потрачу на него времени ребят, которые приносят по 1500 рублей, тем больше у меня будет свободных денег. На код-ревью и личном общении экономить нельзя, а вот на базе знаний — вполне можно.
К тому же по таким записям гораздо легче познакомиться с представителями бизнеса и коллегами, с которыми в обычной работе общаешься редко: посмотрел кик-офф проекта и уже знаешь, кто как выглядит и кто чего хочет. Так что очень советую: если работаете на быстрорастущих проектах с большой долей неизвестности — записывайте все созвоны.
База знаний — сложная штука: писать её лень, да и протухает постоянно, особенно на проектах в начальной стадии. Мы в F&S практикуем быстрый (пусть и грязный) способ передавать знания новичкам — записываем все созвоны.
Способ грязный потому, что новичку при входе на проект прилетает гора видео на десяток часов, хотя мы могла бы прилететь аккуратная вики, которую можно прочитать за час. Если посмотреть на это с точки зрения бизнеса, способ не такой уж и грязный — ведь любой джун это инвестиция. Грубо говоря, если у джуна 1 час приносит компании -1500 рублей, то чем меньше я потрачу на него времени ребят, которые приносят по 1500 рублей, тем больше у меня будет свободных денег. На код-ревью и личном общении экономить нельзя, а вот на базе знаний — вполне можно.
К тому же по таким записям гораздо легче познакомиться с представителями бизнеса и коллегами, с которыми в обычной работе общаешься редко: посмотрел кик-офф проекта и уже знаешь, кто как выглядит и кто чего хочет. Так что очень советую: если работаете на быстрорастущих проектах с большой долей неизвестности — записывайте все созвоны.
#вопрос отталкивает ли тебя возраст при найме?
Я разделяю возраст по паспорту и возраст внутренний. Возраст по паспорту мне пофиг — мне одинаково комфортно работать с ребятами по 18–19 лет, и с ветеранами 50+ (привет, Олег!).
Но вот на внутренний возраст у меня стоит жёсткий ценз. Я никогда не найму на проект с быстрой разработкой старпёра, который считает что все новые технологии — плохие, или думает, что коллеги должны его слушать просто потому, что у него есть лычка синьёра или опыт работы на пару лет больше. На поддержку какого-нибудь старого проекта — с радостью найму, а на новый-быстрый — нет.
Важно понимать разницу между старпёром с ненавистью ко всему новому и нормальным дедом вроде тех, что описал Никита. Дед тоже не любит новое, но в отличие от старпёра не сидит в своём пузыре с названием «куда катится мир», а осознаёт откуда и куда идут хайп-трейны, и понимает, что неэффективное и некрасивое ПО вроде Kubernetes или Webpack может приносить бизнесу больше денег, чем супер-эффективные baremetal и multi-page applications.
Каждый понедельник я публично отвечаю на один конкретно поставленный вопрос. Задавайте на fedor@borshev.com
Я разделяю возраст по паспорту и возраст внутренний. Возраст по паспорту мне пофиг — мне одинаково комфортно работать с ребятами по 18–19 лет, и с ветеранами 50+ (привет, Олег!).
Но вот на внутренний возраст у меня стоит жёсткий ценз. Я никогда не найму на проект с быстрой разработкой старпёра, который считает что все новые технологии — плохие, или думает, что коллеги должны его слушать просто потому, что у него есть лычка синьёра или опыт работы на пару лет больше. На поддержку какого-нибудь старого проекта — с радостью найму, а на новый-быстрый — нет.
Важно понимать разницу между старпёром с ненавистью ко всему новому и нормальным дедом вроде тех, что описал Никита. Дед тоже не любит новое, но в отличие от старпёра не сидит в своём пузыре с названием «куда катится мир», а осознаёт откуда и куда идут хайп-трейны, и понимает, что неэффективное и некрасивое ПО вроде Kubernetes или Webpack может приносить бизнесу больше денег, чем супер-эффективные baremetal и multi-page applications.
Каждый понедельник я публично отвечаю на один конкретно поставленный вопрос. Задавайте на fedor@borshev.com
GitHub Actions выросли
Я присматривался к GitHub Actions с самого его появления — очень нравилась идея иметь всё в одном интерфейсе. Ну и безопасность, конечно: с Actions не нужно хранить статичные GITHUB_TOKEN-ы, скажем для пуша в Package Registry — все токены генерятся прямо во время запуска и протухают после окончания job-a.
У Actions была одна большая проблема — скорость: пушишь задачу, и ждёшь несколько десятков секунд, пока найдётся свободный воркер в очереди. Воркеры тоже были медленными — та же самая работа выполнялась в моём любимом CircleCI примерно в два раза быстрее, чем в Actions.
Несколько недель назад я настроил CI нашего кода для клиента, у которого вся инфраструктура уже построена на Actions. Всё оказалось очень быстро и удобно: воркеры стартуют моментально, таски выполняются быстро. По фичам всё стало ещё лучше — код на GitHub Actions сравним по размеру с кодом на CircleCI Orbs. А самое классное — теперь buildkit (новый механизм сборки докер-образов) умеет автоматически складывать кеш куда-то внутрь в actions, позволяя не думать о передаче кеша между билдами, которую в CircleCI приходилось делать руками.
Мы с командой потихоньку переползаем на GitHub Actions для новых проектов. Если интересно посмотреть, как Actions выглядит по сравнению с CircleCI — посмотрите этот ПР.
Я присматривался к GitHub Actions с самого его появления — очень нравилась идея иметь всё в одном интерфейсе. Ну и безопасность, конечно: с Actions не нужно хранить статичные GITHUB_TOKEN-ы, скажем для пуша в Package Registry — все токены генерятся прямо во время запуска и протухают после окончания job-a.
У Actions была одна большая проблема — скорость: пушишь задачу, и ждёшь несколько десятков секунд, пока найдётся свободный воркер в очереди. Воркеры тоже были медленными — та же самая работа выполнялась в моём любимом CircleCI примерно в два раза быстрее, чем в Actions.
Несколько недель назад я настроил CI нашего кода для клиента, у которого вся инфраструктура уже построена на Actions. Всё оказалось очень быстро и удобно: воркеры стартуют моментально, таски выполняются быстро. По фичам всё стало ещё лучше — код на GitHub Actions сравним по размеру с кодом на CircleCI Orbs. А самое классное — теперь buildkit (новый механизм сборки докер-образов) умеет автоматически складывать кеш куда-то внутрь в actions, позволяя не думать о передаче кеша между билдами, которую в CircleCI приходилось делать руками.
Мы с командой потихоньку переползаем на GitHub Actions для новых проектов. Если интересно посмотреть, как Actions выглядит по сравнению с CircleCI — посмотрите этот ПР.
Вышла большая статья о том, как мы с командой перезапускали snob.ru. В статье я с подробностями рассказываю, как мы создали себе удобный Developer Experience в десятилетнем легаси на смеси ПХП и Питона без единого юниттеста.
Почитайте, если интересуетесь архитектурой медиа, мониторингом, клаудфлером, или тем как катить новый прод, когда к старому нет даже ssh-доступа.
Почитайте, если интересуетесь архитектурой медиа, мониторингом, клаудфлером, или тем как катить новый прод, когда к старому нет даже ssh-доступа.
Блог Фёдора Борщёва
Задача
За полгода мы перезапустили сайт высоконагруженного медиа с кучей легаси-кода. В этой заметке я расскажу, какие технологические решения мы приняли.
Небольшой гайд обо мне, чтобы вы не эвентсорсили из канала
Меня зовут Федя Борщёв, я руковожу Школой Сильных Программистов, где мы делаем синьёров, тимлидов и архитекторов из ребят мидл-уровня. У меня есть бутиковый аутсорс, где мы юзаем все практики, которые я описываю в канале.
Успеваю писать код на Python и node.js, иногда лайвкодю на ютубе. Чтобы показывать новичкам, что код бывает хорошим — открыл почти 100% кода Школы на гитхабе. Другие опенсорсные проекты можно найти в личном профиле.
Послушать меня голосом можно в свежем интервью. Кстати, я люблю выступать публично — если у вас есть аудитория, которой я буду интересен, обязательно позовите меня.
Здесь я пишу обо всём, что меня заботит. В основном это управление разработкой — как выбирать технологии, чтобы через год было кого на них нанимать; как планировать спринты, чтобы успевать в срок; рассказываю о DevOps не в смысле как поднять k8s, а как сделать, чтобы новичок мог запушить новый сервис в прод через две недели работы. Иногда проскакивают личные история про предпринимательство или психотерапию, но рабочего — больше.
В канале нет новостей, дайджестов, мемов, переводов и ссылочек — я пишу только полезный контент, который со временем не протухает, так что смело читайте в любом направлении. Если 2–3 поста в неделю для вас многовато — подпишитесь на блог, тудя я выношу самые важные посты, так что концентрация полезного ещё выше.
Меня зовут Федя Борщёв, я руковожу Школой Сильных Программистов, где мы делаем синьёров, тимлидов и архитекторов из ребят мидл-уровня. У меня есть бутиковый аутсорс, где мы юзаем все практики, которые я описываю в канале.
Успеваю писать код на Python и node.js, иногда лайвкодю на ютубе. Чтобы показывать новичкам, что код бывает хорошим — открыл почти 100% кода Школы на гитхабе. Другие опенсорсные проекты можно найти в личном профиле.
Послушать меня голосом можно в свежем интервью. Кстати, я люблю выступать публично — если у вас есть аудитория, которой я буду интересен, обязательно позовите меня.
Здесь я пишу обо всём, что меня заботит. В основном это управление разработкой — как выбирать технологии, чтобы через год было кого на них нанимать; как планировать спринты, чтобы успевать в срок; рассказываю о DevOps не в смысле как поднять k8s, а как сделать, чтобы новичок мог запушить новый сервис в прод через две недели работы. Иногда проскакивают личные история про предпринимательство или психотерапию, но рабочего — больше.
В канале нет новостей, дайджестов, мемов, переводов и ссылочек — я пишу только полезный контент, который со временем не протухает, так что смело читайте в любом направлении. Если 2–3 поста в неделю для вас многовато — подпишитесь на блог, тудя я выношу самые важные посты, так что концентрация полезного ещё выше.
FEDOR BORSHEV pinned «Небольшой гайд обо мне, чтобы вы не эвентсорсили из канала Меня зовут Федя Борщёв, я руковожу Школой Сильных Программистов, где мы делаем синьёров, тимлидов и архитекторов из ребят мидл-уровня. У меня есть бутиковый аутсорс, где мы юзаем все практики, которые…»
Сервисы: redirect.pizza
Любая организация, которая существуют больше года, владеет больше, чем одним доменом. Домены регистрируют для проектов, продуктов и брендов, а иногда и просто так, потому что они прикольные. По большей части все эти домены лежат и бездействуют, потому что «выкинуть жалко». Я и сам такой — у нас в школе сейчас больше 5 доменов просто лежат и ничего не делают.
Если на какой-то из таких адресов зайдёт пользователь — его надо не потерять. Да и SEO-шники всегда просят настраивать с таких доменов редиректы на основной, пугая умными словами вроде «зеркало» или «робот-склейщик».
Раньше, чтобы поддерживать редиректы с второстепенных доменов, я городил хитрые конфиги в nginx, поддерживал для них DNS и занимался прочей скучной требухой. Недавно погуглил, и мне стало стыдно, сколько же я времени потратил зря — оказывается много лет уже существуют сервисы вроде redirect.pizza, которые позволяют буквально мышкой управлять пачками таких доменов — настраивать и менять редиректы, прописывать заголовки, даже настраивать перенаправление почты, и всё это за $5 в месяц.
Горячо рекомендую.
Любая организация, которая существуют больше года, владеет больше, чем одним доменом. Домены регистрируют для проектов, продуктов и брендов, а иногда и просто так, потому что они прикольные. По большей части все эти домены лежат и бездействуют, потому что «выкинуть жалко». Я и сам такой — у нас в школе сейчас больше 5 доменов просто лежат и ничего не делают.
Если на какой-то из таких адресов зайдёт пользователь — его надо не потерять. Да и SEO-шники всегда просят настраивать с таких доменов редиректы на основной, пугая умными словами вроде «зеркало» или «робот-склейщик».
Раньше, чтобы поддерживать редиректы с второстепенных доменов, я городил хитрые конфиги в nginx, поддерживал для них DNS и занимался прочей скучной требухой. Недавно погуглил, и мне стало стыдно, сколько же я времени потратил зря — оказывается много лет уже существуют сервисы вроде redirect.pizza, которые позволяют буквально мышкой управлять пачками таких доменов — настраивать и менять редиректы, прописывать заголовки, даже настраивать перенаправление почты, и всё это за $5 в месяц.
Горячо рекомендую.
#вопрос Знакомый предлагает делать интернет-магазин (пишем своё решение, без всяких битриксов и прочего). Уже есть реальная ниша, товар и это хорошо продается через маркетплейсы. На мне вся разработка (бек, фронт, девопс и тд), без финансовых вложений. Какие могут быть условия в таком партнерстве? Пока нет прибыли я работаю на голом энтузиазме (предполагается занятость в свободное время от основной работы)?
Нужно ли планировать какой-то дедлайн по выходу на реальную прибыль и получения своего процента?
Хоть это и не по теме вопроса, но я не могу не напомнить, что скоро 2022 год, и делать «своё решение» для интернет-магазина, который пока не работает — очень странно. Но допустим вы знаете, что делаете, поэтому я отвечу на остальную часть вопроса.
Если речь идёт действительно о партнёрстве, то всё просто — договаривайтесь о долях, регистрируйте совместное предприятие, запускайте бизнес. Для этого вовсе не обязательно вкладываться деньгами: время — это вообще-то гораздо более ценный ресурс, чем деньги. Когда в бизнесе появятся деньги — тогда и будете их делить. Если денег нет — то и делить нечего: и прибыль, и убытки вы несёте пропорционально долям.
Если вам предлагают поработать «за идею» с любыми другими формами партнёрства, к примеру обещают заплатить процент, когда появятся деньги — отказывайтесь: вряд ли вы сможете зафиксировать договорённости о разделении прибыли настолько же внятно, насколько это сделает совместное юрлицо.
Разберитесь, почему вам предлагают такие странные формы партнёрства? Может ваша работа для проекта ценна только на момент запуска? В таком случае имеет смысл прописать чёткие договорённости об оплате ваших услуг — к примеру заплатить вам X денег через X месяцев вне зависимости от результата. Это сделать гораздо проще, чем прописать партнёрское соглашение.
Каждый понедельник я отвечаю на один чётко поставленный вопрос. Задавайте на fedor@borshev.com
Нужно ли планировать какой-то дедлайн по выходу на реальную прибыль и получения своего процента?
Хоть это и не по теме вопроса, но я не могу не напомнить, что скоро 2022 год, и делать «своё решение» для интернет-магазина, который пока не работает — очень странно. Но допустим вы знаете, что делаете, поэтому я отвечу на остальную часть вопроса.
Если речь идёт действительно о партнёрстве, то всё просто — договаривайтесь о долях, регистрируйте совместное предприятие, запускайте бизнес. Для этого вовсе не обязательно вкладываться деньгами: время — это вообще-то гораздо более ценный ресурс, чем деньги. Когда в бизнесе появятся деньги — тогда и будете их делить. Если денег нет — то и делить нечего: и прибыль, и убытки вы несёте пропорционально долям.
Если вам предлагают поработать «за идею» с любыми другими формами партнёрства, к примеру обещают заплатить процент, когда появятся деньги — отказывайтесь: вряд ли вы сможете зафиксировать договорённости о разделении прибыли настолько же внятно, насколько это сделает совместное юрлицо.
Разберитесь, почему вам предлагают такие странные формы партнёрства? Может ваша работа для проекта ценна только на момент запуска? В таком случае имеет смысл прописать чёткие договорённости об оплате ваших услуг — к примеру заплатить вам X денег через X месяцев вне зависимости от результата. Это сделать гораздо проще, чем прописать партнёрское соглашение.
Каждый понедельник я отвечаю на один чётко поставленный вопрос. Задавайте на fedor@borshev.com