Дмитрий Евграфович

1. Что значит крупный?
2. Каков должен быть функционал?
3. Сколько вы готовы потратить на доработку и обслуживание?
Короче, берите любую.

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

Если в штат то на хедхантинговых сайтах
Если в штат удаленщика или просто временного удаленщика то на фриланс сайтах вроде fl.ru
Если у вас нет хорошего рубиста то смысл задавать вопросы, которые вы не понимаете? Найдите рядом рубиста пусть проводит собеседования, что спросить он и так знает.
Много, рубисты нынче одни из самых дорогих. Нет зависимости , так как большая часть рубистов сидит в больших городах, так как в городах меньше миллиона для них нет работы. А с текущим кризисом рубисты активно рванули за рубеж.
Это вопрос надо задавать сугубо вам.
Нанять их два, чтобы не остаться у разбитого корыта, когда один их них уйдет.

У самого такой "незаменимый" начальник, только пока не уволился, но всё собирается))) Я за ним уже 2 года "шпионю" и всякими хитростями из него информацию вытягиваю. Почему вы так не делали?

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

Ой ностальгия, это как я помощником отдела автоматизации в одну контору, со сомнительной репутацией устроился. В итоге когда компания набрала 100500 заказов, со сказочными обещаниями, а руководитель мой придумал "четкую схему", которая как по его мнению, должна была стать самой конкретно способной в регионе - в итоге понял, что с этим не справиться и вообще, пролетел по крупному - тихо свалил, заявляя "все заработает, с этим даже ребенок справиться". В итоге он когда ушел, меня поставили на его место, я начал разбираться в этом всем дерьме, куда меня не посвящали и осознал, что пытаться продавать кассы на Линуксовом ПО (уже забыл название), которое было только в бето-версии, не поддерживающее в данный момент и половины обещанного клиентам функционала, а самое главное, пускать фискальные и не фискальные чеки с одной ККМ из не совместимой товароучетки, без тестового стенда и запасом времени хотя бы в пол года - Очень глупая затея. В итоге я кое как сделал кривенький обработчик, который обменивался справочником кассы с товароучетной конфигой 1С, а босс начал шантажировать "Пока не сделаешь все, что обещал твой начальник - зарплату не выдадим" - уволился к чертям.

Я бы слал нафиг с такими предложениями. Если не гарантируют место - требуйте повышенную оплату за этот период.

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

Беритесь за то, чтобы определить круг обязанностей, а то навешают на вас лишнего. Кому это надо ? :)

Все будет зависить от ответов стороннего АPI.
1. Если АPI будет в состоянии обработать асинхронные запросы быстро (100ms), не ставя их в очередь - то node.js или просто страничка с асинхронными вызовами будут обрабатывать быстрее;
2. Если же API для обработки запроса нужно будет делать серьезные действия (например 500 ms), то экономия будет ничтожна.

P.S. Синхронные вызовы обрабатываются сервером с более высоким приоритетом и априори получают результат раньше асинхронных. И возможно виигрыш с асинхронными не покроет разницы. Так что если увас уже написан скрип то переписывать его нет смысла.

не составит труда, если изначально все было спроектировано правильно.

И тут приходим к тому что нужно учить не фреймворк, он тут много погоды не делает (хотя в Symfony чуть сложнее накосячить, хотя всегда можно сделать ужасно). Так же есть определенные нюансы. Скажем если вы захотите проникнуться настоящим феншуем, DDD всякими и т.д. придется отказаться от MySQL в пользу PostgreSQL (если конечно вы не работаете с ораклами какими, в mysql все плохо с автоинкрементами, что накладывает определенные ограничения при работе с Doctrine и заставляет писать кучу лишнего бойлерплейта что бы все было красиво, хотя этот бойлерплейт можно реюзать).

По сути единственная разница между приложениями на Laravel и Symfony - ORM идущая из коробки (как бы все можно подменить под себя). Все остальное - минимальные различия. А с нормальным ORM (а в PHP мире она пока одна - Doctrine) уже можно делать дела красиво и эффективно с точки зрения трудозатрат. Но даже с ActiveRecord можно жить и не тужить.

Словом, я не знаю что вы хотите получить от Symfony, по сути переход с одного фреймворка на другой вам мало чего даст.

Прочитал много мнений о том что Laravel намного быстрее работает чем Symfony.

Вот этот параметр просто не учитывайте. Как минимум Laravel основан на компонентах Symfony и единственное узкое место, которое явно работает медленнее это Doctrine ORM, но та гибкость которую она дает слихвой оправдывает прожерливость. Да и смысл вообще по этому поводу загоняться этом есть только на больших нагрузках, а так вы с большей вероятностью убьете производительность не расставив где надо индексы в базе.

подскажите правильный путь

А правильного нет. Каждый сам свой путь выбирает. Хотите развиваться? Читайте книги. Кента Бэка почитайте, Эрика Эванса и других персонажей... Расширяйте кругозор, а далее что понравится. А да, не ограничивайтесь книгами только для программистов. Почитайте чего по процессам разработки (чего-нибудь про скрамы, канбаны, лины, континиус импрувмент).

Для Laravel 5 нет смысла использовать отдельный класс для валидации (как это было в L4).

В L5 существую ValidatesRequests трейт, который можно использовать в контроллерах, и тогда появляется метод validate.

А еще лучше, использовать кастомный FormRequest класс для валидации данных.

Т.е создаем класс Http\Requests\UpdateUserProfile и наследуем его от Request.

В UpdateUserProfile прописываем 2 метода:

// Проверяем может ли пользователь делать это действие
public function authorize();
// Возвращаем массив с правилами
public function rules();

Затем в котроллере используем этот класс, допустим в методе update:

public function update(UpdateUserProfile $request);

Валидация будет происходить автоматически, без лишних телодвижений, и если она прошла, то в $request 99.999% валидные данные.

Учимся очень внимательно читать документацию.

учи php

У cms есть API, которое позволяет реализовать любой необходимый функционал. Знать cms!=знать названия готовых модулей. Все задачи готовыми компонентами не заткнешь и это нормально.
Вывод: пишешь в резюме "интеграция cms" - будь добр соответствовать.

www.confer.work/demo#
https://github.com/cmgmyr/laravel-messenger

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