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