Быстрый переход на Middle PHP (Laravel)

Добрый день!

В одну из бессонных ночей после дебага драйвера от партнёра заказчика, который падал с сегфолтом и уходил в hardware reset, возникли крамольные мысли, а не оставить ли это всё и перейти писать backend на php.

Если серьёзно, последние 3 года занимаюсь программированием под embedded linux, преимущественно на С (последнее время часть кода переписываем на С++ или пишем на нём с нуля - почти, используем кодогенерацию на jinja2). Проект знаю хорошо, видимо пропал азарт и интерес. Хочется покорять либо новые идейные, либо новые финансовые горизонты.

После поиска вакансий Linux C Developer на hh.ru и Linkedin осознал, что в России от системного/embedded программиста хотят непомерно много, предлагают - непомерно мало. На европейском рынке ситуация получше, но пока есть сомнения, что:
а) уровень английского будет достаточен для ежедневного общения (возможно удастся это проверить, если дойдёт до собеседования в одной из международных компаний)
б) не окажется так, что в целом взял для себя всё что хотел из навыков и знаний сетей (на текущем проекте пишу ПО для сетевого устройства) и системного программирования (раньше увлекался бэкендом, писал на Django, но занесло сперва в нагрузочное тестирование, потом после известных событий - в системное программирование)

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

На Laravel немного писал, общие темы, вроде устройства IoC контейнера, MVC паттерна (и вообще основных паттернов проектирования), баз данных (ACID, CAP теорема, аномалии, уровни изоляции транзакций, способы реализаций индексов: хэш мапа, b-tree, и т.д.) знаю.

Хотел посоветоваться, какие темы надо на практике освоить (что пройти по Laravel, базам данных, что-то ещё?), чтобы можно было "нарисовать" себе опыт 2 года работы бэкендером на php и с большой вероятностью пройти собеседования?

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

Буду рад любым комментариям.

0

Сообщение от newOptimden Вот здесь стало интересно, где race conditions происходят?

Ну например у меня был реальный кейс, когда два обращения к скрипту приходили почти одновременно (с разницей в доли секунды), и логика (большой легаси проект, написанный более 10 лет назад, где ни один живой сотрудник уже и половины не знает как и зачем что-то делалось) была неидеальна. Пример:

На сайте приобретается товар. Приобретение полностью автоматизировано. Покупатель заполняет все формы, подтверждает все условия, и нажимает кнопочку "оформить заказ". Приходит массив данных, например, в класс Shop, метод buy. В этом методе, прежде чем будет совершена транзакция происходит ряд проверок - есть ли товар на складе, достаточно ли у клиента денег на счете, нет ли каких-то иных ограничений (там пара десятков ифочек). И случился такой кейс - два покупателя, не зная друг о друге, нажали "оформить заказ" практически одновременно (запрос пришел с разницей примерно в 0.002 секунды). Первый инстанс приложения проверил, что покупка может быть совершена. Второй инстанс приложения также проверил, что покупка может быть совершена. Потом первый инстанс начал транзакцию. Второй инстанс встал в очередь, дождался пока первый инстанс отработает, и затем тоже отработал. Ошибка устранилась довольно легко - просто перенесли блокировку, чтобы она срабатывала раньше. Но ситуация была довольно неприятная (а до подходящего случая проект проработал более 10 лет и проблем в этом месте не возникало).

Сообщение от newOptimden php вроде стандартными средствами не умеет в многопоточность

Сложность в том, что процесс запускаете не вы. Он сам запускается, и вы это не можете контролировать. Посетитель просто заходит на сайт и дергает ваш скрипт. Может дернуть раз в день. А может сто раз за секунду.

Добавлено через 3 минуты

Сообщение от newOptimden Больше с этим Лафкрафтовым детищем от мира программирования (JS) работать не хочется.

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

0

Сообщение от liris На сайте приобретается товар. Приобретение полностью автоматизировано. Покупатель заполняет все формы, подтверждает все условия, и нажимает кнопочку "оформить заказ". Приходит массив данных, например, в класс Shop, метод buy. В этом методе, прежде чем будет совершена транзакция происходит ряд проверок - есть ли товар на складе, достаточно ли у клиента денег на счете, нет ли каких-то иных ограничений (там пара десятков ифочек). И случился такой кейс - два покупателя, не зная друг о друге, нажали "оформить заказ" практически одновременно (запрос пришел с разницей примерно в 0.002 секунды). Первый инстанс приложения проверил, что покупка может быть совершена. Второй инстанс приложения также проверил, что покупка может быть совершена. Потом первый инстанс начал транзакцию. Второй инстанс встал в очередь, дождался пока первый инстанс отработает, и затем тоже отработал. Ошибка устранилась довольно легко - просто перенесли блокировку, чтобы она срабатывала раньше. Но ситуация была довольно неприятная (а до подходящего случая проект проработал более 10 лет и проблем в этом месте не возникало).

Ну, это не особенность PHP. На C# и других языках всё точно так же будет, если с блокировками и транзакциями не быть осторожными...

0

Сообщение от liris И случился такой кейс - два покупателя, не зная друг о друге, нажали "оформить заказ" практически одновременно (запрос пришел с разницей примерно в 0.002 секунды). Первый инстанс приложения проверил, что покупка может быть совершена. Второй инстанс приложения также проверил, что покупка может быть совершена. Потом первый инстанс начал транзакцию. Второй инстанс встал в очередь, дождался пока первый инстанс отработает, и затем тоже отработал.

Ага, понял, на стороне БД. Как по мне, самый неприятный тип бага - на синхронизации.

0

Сообщение от Usaga Получается, что PHP для фоновых задач подходит чуть менее, чем никак?

Да, лучше не рисковать. Максимум какие-нибудь обработчики по cron-у на несколько минут. Можно использовать и обычный Си. В последнее время - Гоу. Питон лично я ненавижу. Не потому что плохо знаю, а скорее наоборот: плохо знаю, потому что ненавижу

Сообщение от newOptimden php вроде стандартными средствами не умеет в многопоточность, т.е. это не race conditions на критической секции, как понимаю.

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

1

Сообщение от newOptimden Ничто ничего не легче, получается.

В PHP много вакансий по перекладыванию json'ов, где про race condition даже в теории не слышали. Например, полгода работал в одной крупной электронно-торговой площадке, пилил простенькие api, фиксил баги и собственно всё, сложность работы была околонулевая.

Всё зависит от целей. В пыхе полно работы на любой вкус и уровень сложности.

0

Сообщение от Jodah В PHP много вакансий по перекладыванию json'ов, где про race condition даже в теории не слышали. Например, полгода работал в одной крупной электронно-торговой площадке, пилил простенькие api, фиксил баги и собственно всё, сложность работы была околонулевая.

Если не секрет, оплата при этом не околонулевая? Т.е. сопоставима с "в среднем по больнице"?

Сообщение от Jodah Всё зависит от целей. В пыхе полно работы на любой вкус и уровень сложности.

Вот вариативность, наверное, и привлекает. Имхо, в system programming/embedded я вижу переходы на другие места либо с усложнением (копать вглубь), либо с доучиванием чего-то, чего не было на предыдущем месте работы.
А на текущий момент сильного энтузиазма "доучивать" что-то узкоспециализированное нет. Вернее, как, вот взяли бы куда-то на хорошую зп с возможностью доучить что-то на месте, на практических задачах - может и рассмотрел бы такие варианты. Но на уровне middle+ - senior так, мне кажется, не работает. Нужен готовый специалист.
Пытаю сейчас удачу прособеситься в Canonical, попилить ядро Linux (ну или куда возьмут, если возьмут). Так ещё куда ни шло. А самому осваивать - может и интересно, чекпоинт для себя проставить, но кажется неподъёмным. Слишком прагматичный у меня подход к освоению новых знаний.

Добавлено через 4 минуты

Сообщение от Jodah Например, полгода работал в одной крупной электронно-торговой площадке, пилил простенькие api, фиксил баги и собственно всё, сложность работы была околонулевая.

Я неделю на старте карьеры поработал на php в конторе из 4 программистов, включая меня, и начальника. Систему переписывали на Yii2, а написана она была на Drupal. Что-то в духе простых сайтов для всероссийских оффлайн форумов делали (регистрация участников, личные кабинеты и т.д.). Я в шоке был, что оказывается люди хранят php-код прямо в полях БД. Может конечно это и оправданный подход иногда, не берусь резко осуждать, но я был сильно удивлён, когда узнал.
В общем, я от них очень скоро ушёл)

0

Сообщение от newOptimden Если не секрет, оплата при этом не околонулевая?

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

0

Сообщение от Jodah пилил простенькие api, фиксил баги и собственно всё, сложность работы была околонулевая.

Кстати, звучит так, что за счёт достаточного количество непыльных вакансий, php это вполне кандидат на совмещать две фуллтайм работы. Или так только кажется?

Добавлено через 1 минуту

Сообщение от estic Труд "хорошо осязаемый" начальниками и заказчиками

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

0

Сообщение от newOptimden Или так только кажется?

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

А вы где живете?

0

Сообщение от estic А вы где живете?

В Средней Азии, до этого немного в ЮВА жил (Таиланд, Индия, Непал). Ну, как, жил сколько-то в разных локациях, потом переезжал. А вообще из Питера.
Сейчас работодатель отличный, заказчики - шведы/финны, никому не важно, где ты живёшь и работаешь (главное не РФ и не Беларусь, ибо санкции, все дела). Но видимо проектом перегорел, потому вот и мучаю форумчан вопросами)

0

Сообщение от newOptimden оплата при этом не околонулевая?

Скажем так, в вакансии зарплата была указана 200-250К.

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

Сообщение от newOptimden php это вполне кандидат на совмещать две фуллтайм работы

Если специально искать чилловые вакансии - да, вполне.

Сообщение от newOptimden платят больше там, где бизнес делает деньги, и, в силу своего нетехнического бэкграунда считает программистов заклинателями байт)

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

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

0

Сообщение от Jodah В пыхе полно работы на любой вкус и уровень сложности.

Много в каких интервью на Ютубе встречал, что собеседуемые преподносят опыт интеграции со сторонними сервисами и платёжными системами, как признак "мидловости" и чуть ли не самых сложных задач, которые у них были на проекте.
Деталей там особо нет.

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

P.S.
Темы по Laravel посмотрел, через Guzzle сделал сброс пароля в Телеграмм пользователя, с JWT авторизацией поработал и т.д.
В zend engine залез, посмотрел, как там массивы реализованы. Теория легко освежается/набирается.
Понимаю, что нужна легенда для собесов и какие-то практические кейсы, которыми можно занять время собеса.
Всё же middle и выше - это часто разговор про сложные кейсы из практики. По крайней мере, на собесах на нагрузочного тестировщика и C programmer у меня так было.

0

Сообщение от newOptimden какие там главные сложности, на настройке интеграций

У меня не было каких-то сложных задач с интеграциями, может кто из форумчан подскажет.

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

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

Сообщение от newOptimden Какой тип интеграций наиболее часто используется (предполагаю, что с платёжными системами)?

Наверное да, интеграция с готовым сервисом с задокументированным апи (платёжки, маркетплейсы, парсеры прайс-листов, да те же соц сети или телеграм боты), ну и межкомандные интеграции в пределах одной компании.

Сообщение от newOptimden Что вообще самому можно потыкать в этом плане, чтобы можно было рассказать на собесе?

Да наверное любой бесплатный апи. Допустим dadata, или например в ВК запилить управление группой, создание постов и т.д. через api.

0

Сообщение от newOptimden какие там главные сложности, на настройке интеграций

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

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

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

Сообщение от newOptimden Теория легко освежается/набирается.

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

1