Как найти работу за рубежом, несмотря на 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 разработчиков. Если есть желание, бахните плс это дело и отправьте им пулреквест. А мы воспользуемся вашей форкнутой версией, пока они не примут реквест.

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

Серверная шаблонизация
После того как я написал про inertia.js, несколько людей спросило у меня, в чем же собственно крутость такого подхода? И действительно, получается так, что в современном мире много разработчиков, которые плотно не писали на классическом клиент-серверном MVC (его еще называют MVC model 2, потому что обычный MVC это как раз толстый клиент и событийная архитектура).

Исправляюсь. Опишу тут то, чего мы лишились и чего не хватает при переходе в режим SPA, когда у нас есть отдельно бек с API и приложение на клиенте.

Небольшой ликбез. Классическая серверная шаблонизация хотя технически и является серверным рендерингом SSR, но эти понятия не стоит смешивать, потому что под SSR понимают именно рендеринг JS кода, например компонентов React. А серверная шаблонизация подразумевает использование шаблонизаторов, написанных под тот язык, на котором пишется бекенд. Внутри этих шаблонов используется либо такой же язык, либо очень похожий. Например в этом смысле, PHP сам является шаблонизатором, так как в исходниках позволяет мешать себя с html.

В чем же плюсы?

SEO

Сео стало проблемой для программистов только с появлением SPA :)

Производительность

Максимальная. Это просто html с сервера

Цена (Один программист)

Вам не нужен фронтендер чтобы создавать такие шаблоны. Их делают разработчики бекенда и верстальщики. Для эффективной работы требуется какое-то знание HTML и CSS, но так было всегда для веб-разработчиков на любом языке.

Скорость разработки

Так как человек один, то и скорость разработки значительно выше чем раздельно. Как подпункты тут можно выделить:

• Не нужно создавать api (!!!)
• Стейт только один и он в базе (!!!)
• Интеграция с самим фреймворком, многие вещи делаются автоматически, типа обработка и вывод форм
• Отсутствие дублирования логики так как нет отдельного фронтенда
• А еще посмотрите на haml-like шаблоны, я по ним скучаю

В общем и целом, скорость с которой создавались и создаются (на хекслете так) страницы и формы в такой форме, недосигаема для отдельного фронтенда, особенно если это SPA

Тестирование

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

Тогда почему от них ушли если все так сладко? Многие проекты требуют высокого уровня интерактивности, по сути многие современные сайты, это полноценные приложения (толстые клиенты) в браузере. Серверная шаблонизация тут не поможет, она stateless и это просто html который генерит сервер.

Домашнее задание: пройдите getting started на rails, чтобы заценить как это работает

Боже мой, это случилось. Первый выпуск на моем канале, который монтировали 4 месяца (хаха) https://www.youtube.com/watch?v=wnz5E6Vxfd4 Смотри, залетай, лайкай, шарь!

Когда вы последний раз видели в глаза PHP? Узнаете этот синтаксис? Эх, опять курсы дописывать)

Я перестал использовать Copilot после 2 месяц. И вот почему

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

Сетап

За это время я использовал copilot в основном с двумя языками: php (laravel) и typescript (react). В качестве редактора nvim (сборка LazyVim на скрине). Писал и фронт и бек и тесты.

Что понравилось

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

Почему я остановился

Но чем дальше, тем больше появлялось ситуаций, когда я понимал, что copilot мне скорее помешал чем помог.

Уменьшение продуктивности

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

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

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

Импорты

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

Ошибки

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

Итого

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

p.s. А где вас раздражает Copilot?