Что вам мешает сразу написать так и не париться?Лень же...
Они же каждый день в телегу пишут, что у них что-то там не работает локально и как это поправить."Они" много чего пишут, и много чего "не работает" совершенно не по тому что "технологии плохие".
Посоветуйте ИДЕ которая умеет всё это и работать по SFTP.Если ее нет, значит кто-то придумал киллер фичу, которая выкосила такую возможность из ИДЕ, не думали об этом? ИДЕ вегда подстраиваются под рынок, а рынок диктует хотелки, -> отсутствие возможности работать с удаленными проектами следствие тенденций рынка разработки. Хотя никто не мешает вам примонтировать локально удаленный каталог через SSHFS, например, и работать "как по сфтп".
Посоветуйте ИДЕ которая умеет всё это и работать по SFTP.Сторм же...
Код не мойто что кто-то выложил какаху на гитхаб, не делает этот код качественным, или даже рабочим.
Запросы к сервисамЭто к бд, или сервисы - внешние апи? По вопросу вроде про бд говорили...
Запросы к сервисам выполняються за 0.37 секунды,Приемлемо для тяжелого запроса, хотя сложно что-то сказать не зная ни запроса, ни размеров таблиц, ни настроек сервера.
некоторые запросы за 1.3 секунды.Очень долго, опять же - сферический запрос в вакууме...
Суммарно получаеться 8 секундОпределенно фигня, 8 секунд на запросы ото пипец как много, бд - штука специально настроенная на быстрые манипуляции с большими объемами данных, где-то явный пройоп. Ну и в целом - нужен 1, максимум 2 запроса, а не 20. У вас же, насколько я понимаю, в цикле идет сборка в $product набора каких-то элементов, классы которых лежат в массиве, и каждый из них работает со своей таблицей(?), и при этом все таблицы связаны через поле productId. Очень похоже что индекса по этому полю нет, а структура, если это так как я описал - хромает на обе ноги...
Например, у клиента три заказа, два на категорию 2 и один на категорию 4. отвечает он указанным требованиям или нет - совершенно непонятно.
размещали более одного заказа в день, на продукты относящиеся к одной категории.Соответственно отвечает, так как минимальные условия выполнены.
хз, чего кот подумал, что я аналог букинга пишу
Подойдет для простого букинга?
по какой то причине я получаю пустой массив из формыЭто как-то отличается от вопроса в заголовке, не находите?
А есть пример, где можно структуру типовую глянуть?Хз, на самом деле у вас просто бронь комнаты, по этому системы букинга вам скорее всего не подойдут. Там вообще очень много нюансов зависящих от деталей реализации и концепции. Если тема интересна, поищите выступление спикера от букинг.ком лет 5 назад на какой-то конференции, там много чего было, в том числе и по структуре хранения. Тема очень сложная и большая, например для больших объемов выборки часть данных они специально раз в сутки сводили в денормализованные таблицы с быстрым доступом, так как пересчитывать налету не получалось по ресурсам.
Deprecated: Constant FILTER_SANITIZE_STRING is deprecated in /home/user/scripts/code.php on line 3это два. Использовать мануалы двухтысячных годов при разработке как минимум небезопасно, ну или не использовать учебные пособия от "гуру", основанные на этих мануалах.
string(13) "Üßärblöck"
трудно представить кейс, в котором фронт джуниор в большом конкурсе выделится только за счет того, что "хорошо знает свою узкую область"Скорее сложно себе представить что джуниор вообще хорошо знает свою область (на то он и джуниор), и выбирают обычно из топа разбирающихся по принципу "ну вот эти 4 более менее готовы к мелкой работе, тот который вонял нафиг, тот с лысым черепом и свастикой тоже наверно не подойдет, остались только тот что без двух зубов и тот который через слово говорит 'типа'... Кого возьмем?".
джун никогда не найдет работу в условиях, где 200 человек на 1 местоКак раз в конторах где большой конкурс требуют хорошо знать свою узкую область, с пониманием как вообще работает стек в целом (собсно похоже на кейс ТС). В вашем описываемом кейсе в вакууме в вакансии четко будет указано - нужен фуллстек, тогда и требования будут другие и контора скорее всего так себе, бо разделение на узкие специализации для крупных контор норма.
фронтенд джун должен знать, как написать бэкендЕсли бы у бабушки были яйки, она была бы дедушкой (джуном). Как миниимум странно требовать от джуна фронтера серьезных знаний в области бэка. Достаточно знать что бэк что-то там достает из бд, пакует в требуемый формат (например жсон), и отдает на фронт (ну или пишет в бд и отдает отчет - получилось/нет). Если формат кривой - виноват бэкэндер, если код фронта не работает по другой причине - виноват фронтендер. Как именно колдует бэк, фронта волновать особо не должно.
2) Изменения должны быть видны при добавлении элемента, или только при изменении значения?