Evgeny Svirsky

Есть 2 сегмента: коммерческий и open source. Из коммерческих самый лучший это PHPStorm, из open source - Aptana вроде ничего, но само собой коммерческий сегмент, на порядок лучше open source-ного. Поэтому только PHPStorm.

Очень мощная и толковая штука. Используем на проекте:
https://bugsnag.com/

Ну не используйте Symfony Forms для вашего случая если так не хотите. Можно и GET, POST параметры получать из суперглобальных массивов и не использовать объект $request которые уже отдаёт satinized данные.
Имхо вопрос в вашем отношении. Сегодня у формы 2 поля, а завтра нужно еще 3, потом еще 2, и всё. Вам придётся рефакторить. Не понимаю, в чём проблема сразу заложить как нужно?
Как по мне, в симфони формы вполне достойны.
И не создавайте форму на лету в контроллере - это плохой тон. Лучше формы держать в отдельном классе а обработку при сабмите отдавать менеджеру. Таким образом контроллер не будет дёргаться при наращивании функционала, и не должен.

Сделайте мониторинг тем же PHP и собирайте статистику каждые 30 секунд к примеру. Потом стройте графики и смотрите параметры которые вас интересуют.

Как по мне лучше делать отдельный docker-compose для каждого проекта.
Сценарий приблизительно такой:
Создаёте конфиги для каждого image-а. Это позволит поднять окружение одной командой.
По поводу деплоя (с этим знаком только в теории) - знаю что у докера есть докер-сервер который готов принимать контейнеры на деплой. Т.е. скармливаете ему конфиг, он вам поднимет окружение обновит код и всё остальное.
Как-то так.

Имхо не должно быть страниц которые грузятся даже 3 секунды. не говоря уже об пяти :)

По коду вроде должно прерваться, а что происходит ? Подвисает скрипт? Может он не дошёл еще до равенства.

Создайте поле у юзера last_login_at и заполняйте его каждый раз при авторизации. Это и будет дата последнего входа.

я бы сделал так:
OAuth авторизацию между андроидом и серваком. Уникальность проверять по ID device-а.
REST api для получения данных.

При такой авторизации - не будет слетать токен при попытке авторизоваться с другого девайса.

Лучше всего это делать не JS-ом а на сервере. Хотя если задача стоит именно так - можно воспользоваться localStorage и отправлять всеравно данные на сервер. Только так вы узнаете сколько раз он был там.
А по поводу количества пользователей на странице - нужен тоже алгоритм на бэкенде. Который будет следить какие страницы юзер запрашивает, как долго он простаивает, чтобы понять что он ушёл с сайта.

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

Проверяйте код ответа. Если 302 - создайте модалку для авторизации. ИМХО это лучше чем редирект юзера. Ну или редиректните его, если вам так угодно.

Нужно определить какой LEFT JOIN ложит ваш запрос. Потом проверить - индексы, если нет, сделать. Если есть, тогда подумать, может стоит добавить избыточность. Еще тут проблема в LIKE. Может есть смысл использовать какой поисковой движок, Elastic, Sphinx.

А к апи нельзя сделать запрос указав 50 записей, 100? Если можно сделать такой Bulk Request - то выход только один - делать пачкой запросы и также пачкой их обрабатывать. Статусы ставить на отправление и что обработан. Запрос может грохнуться в любой момент. Не забудьте при реализации.

Спасибо.

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