Кроме телеги я еще переодически веду твиттер канал, но не совсем понимаю насколько пересекается аудитория. Напишите плс смотрите ли вы его или нет? Потому что в основном это разный контент. Как пример 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

Как на самом деле работает профессиональный рост

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

Если не брать пограничные случаи, для меня это говорит об одной важной вещи. Человек перекладывает (не осознано) ответственность за свой профессиональный рост на работадателя. Он растет только если ему предоставляют такую возможность и не растет если не предоставляют. Правда люди часто не растут даже если такая возможность в компании есть, но это уже другой вопрос.

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

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

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

p.s. Поделитесь своими историями, я знаю что тут много топовых ребят)

Помните я недавно делал подборку вопросов для трудоустройства? Тот тред хорошо зашел, поэтому пробуем еще раз. В этот раз со спецификой под конкретную тему:

1. Предположим что вам надо раздавать большие файлы из приложения (а не напрямую через nginx). Как это организовать так, чтобы файлы не забивали память?
2. Раздаваемые файлы должны иметь ограничения на уровне приложения, например владение определенным пользователем. Как реализовать подобную авторизацию?
3. Как организовать хранение загруженных файлов на диске? Проблема в том что их нельзя просто так складывать в какую-то папку, потому что при большом количестве, чтение таких директорий начнет сильно тормозить.
4. Как бы вы организовали генерацию Thumbnails для загружаемых картинок? Уточнение: читают в 10 раз чаще чем грузят. Размеры картинок регулярно меняют так как меняется дизайн.
5. Как бы вы подходили к вопросу ускорению скорости загрузки и более эффективному использованию каналов, если бы ваши файлы часто скачивали в физически удаленных локациях? Хотя бы общие принципы

Если вы вдруг все пропустили, на днях произошел просто эпический срач на тему того как надо и не надо писать современные фронтенд приложения. Как часто такое бывает, не обшлось без DHH (создатель rails, basecamp и других клевых штук), его продуктов и его подходов. Не могу не процитировать одного из его разработчиков:

I wrote about how this model compares to SPA six years ago and those are still my thoughts today. SPA offers potentially great responsiveness at an excruciatingly high cost. In recent years, I've heard countless first-hand stories of products failing to launch because of some SPA horror story. The real world is all about cost/benefit, and plenty of shops choose – knowing it or not – to ignore cost when picking their stacks. As sad as it is, this gives Rails and Hotwire programmers a tremendous edge.

Software development is full of merchants of complexity. They will tell you about great engineering practices and how to optimize for the local, but they never stop to discuss cost/benefit or how the system as a whole will suffer. The recent debate was a great showcase of such a way of thinking.

I saw the term engineering used a lot in this debate. Here's my hot take: an engineer who overlooks costs is a bad one!

Mind the cost-ignorers.

Подробнее тут: https://world.hey.com/jorge/the-popover-drama-48e317b3

Вышел еще один подкаст с моим участием https://youtu.be/IFPY_VMRCQ4?si=jqL9HEHlcl0lclB5 поболтали с ребятами про обучение и образование

Next.js подход для больших фреймворков

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

Недавно я зарелизил проект по приемке абитуриентов в наш колледж написанный с помощью этого подхода. В качестве бекенд фреймворка там используется Laravel (PHP), а в качестве фронтенда не встроенный шаблонизатор blade, а Inertia.js (https://inertiajs.com/) клей, который прозрачно соединяет бекенд с фронтендовым фреймворком на выбор, в нашем случае React, но мы могли бы легко использовать и Vue.

Бекенд, в такой схеме работает почти на 100% как если бы мы использовали классическую серверную шаблонизацию.

public function create(): Response
{
    $college = new College;

    return $this->render(['college' => $college]);
}

В этом примере экшен отвечает за формирование страницы создания колледжа. Данные для этой страницы передаются по классике. Никакого намека на js тут нет. Рендерингом занимается Inertia.js, которая берет данные для рендеринга и вставляет их сериализованную версию прямо в html в виде переменной с объектами.

Эти данные автоматически прокидываются в клиентские компоненты отвечающие за соответствующие экшены.

type EditPageProps = PageProps<{ college: College }>

export default function Edit({ college }: EditPageProps) {
  const { props: { scope } } = usePage<SharedProps>()

Кроме прочего, Inertia.js дает кучку разных вспомогательных инструментов, например хук useForm который знает как работать с бекендом на Laravel, что дает автоматический захват ошибок и вот это все.

Но даже в таком подходе иногда нужен API, например для автокомплитов. Inertia.js и Laravel этому никак не мешают, всегда можно добавить любое API.

Ребят, есть возможность вложиться в опенсорс без боли. Есть такой проект для склонения имен в русском https://github.com/petrovich/petrovich-php но версия на php устарела. Нам в проекте она нужна, поэтому придется делать форк и добавлять туда composer. Задачка очень простая для современных PHP разработчиков. Если есть желание, бахните плс это дело и отправьте им пулреквест. А мы воспользуемся вашей форкнутой версией, пока они не примут реквест.

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