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

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

Ребят, мы тут проходим в техорду (проект астаныхаба по обучению) и там для заявки нужно подтверждение выпускников из Казахстана. Если вы такой человек, напишите пожалуйста в комментариях. Я с вами свяжусь.

Open Source и рабочее время

На днях Сергей Андреев (Привет!) написал твит по поводу того что он смотрит на гитхаб https://twitter.com/DragorWW/status/1776456741175066801 и, как в таких случаях водится, получил в тачанку, что нет времени/не интересно/не важно заниматься опенсорсом. Среди разных доводов был один про то, что и так на работе пашем, времени на заниматься опенсорсом после работы нет.

Не могу не пройтись по этому пункту. Если брать типовую прикладную разработку, то мы как разработчики каждый день используем большое количество разных библиотек для своих задач. Некоторые из них большие и страшные, как rails, react или spring boot, другие совсем маленькие, созданные вот такими же простыми разработчиками по всему миру.

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

Звучит логично, но на этом этапе появляются следующие возражения.

Я не встречал багов в библиотеках.

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

У меня нет времени коммитить в опенсорс (после работы), бизнесу нужны решения

Для меня вот эта штука все же культурная. Мы часто пишем свои абстракции в коде (чем не библиотеки?), мы часто копаемся в исходниках чужих либ. Исправление ошибок, которые возникают в коде либ, которые мы используем, это тоже часть рабочего процесса. И здесь фактически речь идет про культуру как компании, так и конкретного человека. В моей практике, в тех компаниях где я работал и которые я создавал, быть частью сообщества открытых проектов это не история на посидеть после работы. Это часть работы. Если есть баг и он в либе, то давайте его поправим если в этом есть смысл (А он часто есть). Если мы видим что у нас абстракция, которая может стать либой, давайте ее вынесем и сделаем либой.

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

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

p.s. Сколько у вас принятых пулреквестов в опенсорс?

Мой подход в работе с зависимостями и их устареванию

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

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

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

Что еще важно, чтобы такой подход работал:

• Использовать дефолты там где это возможно. Любая кастомизация мешает обновлениям. Вплоть до невозможности его выполнить
• Использовать только проверенные библиотеки, которые не умрут потому что их забросит основной мейнтенер
• Менять зависимости если их забрасывают (во фронте этого очень много)

Ошибки, при этом, конечно же случаются, не все протестировано, какие-то особые кейсы и так далее. И команда иногда на меня за это криво смотрит) С другой стороны, я вижу достаточно плюсов в этом подходе чтобы продолжать его придерживаться в тех местах, в которых я пишу код. Плюс конечно же, эти проекты не настолько огромные, где черт ногу сломит, поэтому можно себе позволить.

p.s. Как часто вы обновляете зависимости?

Кроме телеги я еще переодически веду твиттер канал, но не совсем понимаю насколько пересекается аудитория. Напишите плс смотрите ли вы его или нет? Потому что в основном это разный контент. Как пример https://twitter.com/mokevnin/status/1778514285917778078

Разбор “твиттер собеседования”

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

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

> Предположим что вы реализуете редакцию журнала, где редактора могут в админке править статьи. Как предотвратить ситуацию, когда два редактора могут начать одновременно редактировать одну статью и перетирать изменения друг друга?

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

> Каких принципов разработки нужно придерживаться, для обеспечения механизма zero downtime deployment, это подход при котором приложение деплоится без простоя сервиса. Как это достигается?

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

> Что может произойти, если ваша крон задача, которая запускается раз в минуту, стала выполняться больше 1 минуты? Как это можно предотвратить?

Может быть нужно перейти на событийную систему и очереди/джобы, может быть увеличить таймауты, а может поставить лок.

> Если вы пишите тесты, то как вы обходите проблему того, что код который вы тестируете, делает внешние вызовы? Доп условие, говорим о том, что на CI внешние вызовы запрещены (почему так правильно?)

VCR (кассеты) или стабы

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

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

> Как вы узнаете об ошибках, которые происходят на продакшене? От пользователей или это автоматизировано?

Самое простое это коллекторы ошибок типа sentry, остальное по требованиям/вкусу

> Как обеспечивается изоляция тестов друг от друга если они ходят в базу и меняют ее (дефолт в большинстве фреймворков)? Если в вашем фреймворке этого нет, то как вы это делаете или сделали бы?

Кстати удивительно, что никто не назвал самый простой вариант реализованный во всех бек фреймворках по умолчанию, это транзакционные тесты. В начале теста транзакция стартует, в конце откатывается. Так работает в laravel, django, rails, spring boot и других фреймворках без доп настроек.

Какие вопросы стоит задать работадателю если вы разработчик?

Честно говоря, хрен его знает. Жизнь показывает, что даже если люди произносят правильные слова, это ничего не означает. Вы пишите тесты? Да пишем. По факту там может быть все что угодно, вплоть до того, что лучше бы вообще не писали, чем писали то что пишут.

Если исходить из задачи, найти адекватное место с возможностью вырасти профессионально (но не факт что по карьерной лестнице), то я бы выбирал компанию по таким критерию:

• Компания работает на свои деньги. Инвестиции или бесконечный ресурс (банки), очень сильно влияют на восприятие реальности. В таких местах можно заработать, но часто, это овер-все. Нанимаем любое количество тестировщиков, делаем сколь угодно сложный процесс и так далее. Расхолаживает и отрывает от принятия разумных решений.
• Команда ориентируется на деньги, понимает свой вклад, свое влияние и связывает свою работу с тем, что компания зарабатывает и на что тратит. Встречается редко, но с моей колокольни, это значительный фактор. В таких компаниях разработчики воспринимают тот же маркетинг не как назойливых людей, которые мешают работать, а как тех людей, с которыми у нас общие задачи, для того чтобы компания процветала и у всех была возможность развиваться нанимать и так далее.
• Во время разговора (на собесе и внутри) люди много уделяют времени бизнесовой стороне вопроса, решению задач, которые влияют на продуктово-маркетинговые метрики. В противположность есть команды, которые большую часть времени создают абстракции, спорят о паттернах и спрашивают всех про SOLID.
• В компании практикуется фулстек разработка. Многие со мной не согласятся, но мне кажется это показателем того, что в компании нет изоляции и перекладывания ответственности, которая может быть в тех местах где “я это не знаю, это девопсы делают”.
• Разработка использует стандартные инструменты, а не пилит свои фреймворки и инструменты. Да бывает что пилить свое надо, но в типовых проектах, это явно перебор.
• Разработчики пишут тесты сами, при этом в компании нет толп ручных и автоматизированных тестировщиков. Да и в целом отношение к пайплайну без фанатизма, типа мы щас тут сделаем три предпрод стадии, чтобы все было ух наверняка.
• Деплой это рядовая процедура, которую делают абсолютно все, желательно по необходимости. В некоторых компаниях это удел избранных и даже одного конкретного человека.
• В собеседовании не прозвучало слово “микросервисы” :)

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

Как найти работу за рубежом, несмотря на hiring freezes?

#дружеский_пиар

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

Вакансии именно в таких компаниях собирают ребята в канале Dev & ML Connectable Jobs. Как результат – уже десятки читателей получили офферы в Neon, InDrive, 1inch, Wheely и др.

Примеры интересных вакансий:
– Frontend Engineer в Rarible (помогают с релокацией в Лиссабон или remote)
– Python Developer в TradingView (remote)
– Senior Frontend Engineer в Monite (remote)
– Senior Backend Engineer в Termius (remote)
– Head of Analytics в Wallet on Telegram (remote)

Еще больше вакансий в других стеках – в канале @dev_connectablejobs

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

Фулстеки это миф?

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

Расскажу немного про мой опыт и опыт Хекслета. Я довольно долго писал только на беке php + ruby + по мелочи python и nodejs. Это классический веб на классических фреймворках, поэтому там всегда фоном присутствовала верстка. Лет пять начиная со входа в разработку в 2007 году. Где-то к концу этого срока я постепенно начал погружаться в автоматизацию, познакомился с chef, потом ansible, чуть позже подключился docker и в конце концов облака, куб, terraform, мониторинги и другие штуки, благодаря которым я мог поднять инфраструктуру даже относительного нагруженного проекта и поддерживать ее. Параллельно с этим в мой арсенал начали входить и другие языки, например elixir и clojure (и даже haskell), в 2014 году я сделал первую версию codebattle.hexlet.io, в которую уже начали активно играть. В прошлом году в мой арсенал включилась Java. Знаком я с ней был давно, но вот активно получилось пописать только в прошлом году. А в 2013 году, когда в свет вышел React, я взялся за фронтенд и реализовал первую версию нашего редактора, которую кстати недавно переписал на TS и это был мой первый серьезный опыт TS разработки. С тех пор я в целом много писал на фронте, местами даже полностью на него переключаясь.

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

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

Из-за этого, отношение к фулстеку всегда было такое, что это что-то само собой разумеющееся через какое-то время после старта карьеры. То есть на горизонте 5-7 лет продакшен опыта, человек минимум пишет на нескольких языках в беке, пробовал фронт (если он не совсем жестко в бекендовых вещах), возможно мобилку, точно разбирается в инфраструктурных вещах и так далее.

Независимо от того, что говорят в интернетах, я заметил такую штуку. Те кто много лет пишет на одном языке никуда не переключаясь, как правило менее эффективны, чем T-shaped спецы. Есть мнение что это не так из-за глубины, но факт в том, что как правило засада не в глубине понимания каких-то кишков, это редко нужно, а именно в том чтобы getting things done, сложность которых вполне умеренная. И человек обладающий более широквыми навыками, взглядами и пониманием всей системы, показывает себе лучше. Но это мой опыт. Для Хекслета это точно работает.

p.s. А вы фулстек?

Инфраструктура на яндекс облаке

Последние пару дней сетапил инфраструктуру на яндексовом облаке для проекта, который сейчас пилю. Из сервисов туда входят: cdn, dns, registry, storage, compute, база, kubernetes, балансер, сертификаты, отправка почты и кое-что другое. Пары дней хватило, чтобы все вспомнить и засетапить облако через terraform + k8s (helm). В целом, с облаком приятно работать, но малова-то доков + мало ответов в сети на разные тех вопросы, так как популярность облака несравнимо ниже чем зарубежных аналогов.

Структура проекта вполне классическая. Два сервера приложений для отказоустойчивости + где-то там в кишках мастер куба. База со скрытой репликой на случай падения (автоматическая фича), storage для хранения файлов и cdn для отдачи.

Вообще изначально хотел пойти по простому пути и использовать сервис serverless внутри яндекса, но с ним возникла неожиданная проблема. Если во время деплоя приложение не стартовало, то сайт падал, так как единственный механизм деплоя в serverless это останавливаем старое и стартуем новое без всяких healtcheck. Для внешних проектов это нереально, поэтому сервис для меня оказался бесполезен. С кубом, в этом смысле красота, несколько строчек кода и zero downtime deploy обеспечен.

Из ожидаемо хорошего, терраформ с lsp это сказка, все подсказывает, все дополняет. Давно чесались руки попробовать и вот наконец-то выпала возможность.

Из интересного, узнал про проект https://github.com/jkroepke/helm-secrets и заюзал его. Обычно для этого я использовал ansible vault, но тут не понадобился. Этот проект мне открыл глаза еще на вот эту штуку: https://github.com/helmfile/vals оч интересная фигня для извлечения конфигурации и секретов из всех сервисов откуда только возможно.

Инфраструктура под проект

> Интересно, можно ли было для этой задачи просто арендовать виртуальную машину, установить туда nginx, php-fpm, postgres, и скопировать папку с проектом на Laravel. Такое решение не помогло бы?

Такой вопрос возник к предыдущему посту. Правильный вопрос, на который надо отвечать развернуто. Почему бы просто не бахнуть машину с проектом?

Проблемы, которые в этом случае возникнут, можно свести к нескольким пунктам:

1. Надежность (+ скорость восстановления)
2. Безопасность
3. Производительность
4. Масштабируемость

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

Если умрет машина, то мы все потеряем. Если мы сломаем ssh, то все потеряем. Если кто-то внутри тачки случайно сделает неверный шаг, мы все потеряем. Для коммерческих проектов это недопустимо, поэтому нужна альтернатива.

Что нас в первую очередь заботит с точки зрения надежности?

1. Главнейшая вещь это данные в базе. Их потеря часто означает потерю всего проекта, а может даже и бизнеса.
2. Пользовательские (загружаемые) файлы. В нашем случае это документы (паспорта и вот это все)

Начнем с одной машины. Что в первую очередь нужно сделать?

База данных

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

Но бекапы это не единственная вещь, которую нужно сделать. Падение базы данных означает серьезный простой. Для многих бизнесов это означает потерю денег и доверия. Поэтому нужно решение, в котором даже если упадет база данных, то она сможет как-то восстановиться. Подобные механизмы есть в большинстве современных баз данных, они реализуются через разные способы репликации. Делать такое без выделенных людей под инфраструктуру нереально. А вот облака предоставляют такую услугу, как правило, из коробки (multi zone). Это, конечно же, стоит денег, фактически за еще одну машину, но уровень надежности в этом случае вырастает очень и очень значительно. Типичный сервис RDS

Файлы

С хранением файлов ситуация аналогичная. Обеспечить надежное хранение файлов сложно. Можно конечно копировать их по расписанию на другую машину, но мы снова получаем точку отказа, возможные ошибки, необходимость следить за этой системой иногда тестировать на работоспособность и так далее. По этой причине, большинство компаний, даже имеющих ресурсы, делегируют эту задачу облакам. Файлы хранят не сами, а в облачных хранилищах, которые сами обеспечивают дублирования файлов по разным местам причем в нескольких экземплярах. Все это происходит прозрачно от нас даже в случае восстановления. Мы скорее всего даже не узнаем что было падение или выход из строя сервера. Сервис продолжит работать, а файлы отдаваться. Типичный пример сервисов такого уровня это S3

Про производительность, безопасность и масштабируемость поговорим в других постах

Надежность и масштабируемость через сервера приложений

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

Мы точно не боимся потерять код приложения, но сам сервер может умереть. Это, кстати, происходит чаще чем может показаться. Чтобы этого не произошло, мы можем поднять два идентичных сервера с кодом, между которыми делится нагрузка. Таким образом мы решаем сразу две проблеми:

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

Чтобы такая схема заработало, нужно сделать несколько изменений. Для начала нам нужно добавить балансировщик нагрузки. В облаках с этим просто, тыкаем кнопку “создать” в нужном разделе. В настройках к нему привязываются машины, по которым нужно балансировать. Дальше нам надо указать в DNS адрес именно этого балансировщика.

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

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

Опубликовал в твиттере пост, про переписку в комментариях к коду https://twitter.com/mokevnin/status/1790150979465175220 Помимо самой переписки, в ответ полетело "комменты на русском, фу" (смягчил формулировку). А как вы к этому относитесь? В вашем коде пишут комменты на русском?

А вы пользуетесь законами Де Моргана при преобразовании логических выражений? Если да, то откуда узнали про них? Мне интересно, как щас без универа (и наших курсов, хаха), про них узнают?

Записался тут в подкасте про айти комьюнити. Крайне рекомендую к просмотру: https://www.youtube.com/watch?v=JQxbkqqGAOg