Илья

Можно теоретически снизить пинг на треть
Известно, что скорость света в оптоволокне 0,69с (с - скорость света)
Кроме того оптоволокно как правило проложено не по кратчайшему расстоянию,
Хотя на участке между Москвой и Питером оптика зарыта вдоль ЖД, которую Николай I рисовал линейкой, так что много тут выиграть не получится

Итак нам нужен радиоканал. Во первых скорость в воздухе близка к с
а во вторых так мы получим минимальное расстояние по кратчайшему пути

Единственный момент - нам нужно учесть кривизну земли.
У Unifi есть такая клевая утилита https://link.ui.com
с помощью нее вычисляем высоту на которой нужно установить радиопередающие устройства:


Оказывается чтобы снизить пинг на треть достаточно построить в Москве и Хельсинки радиовышки высотой в 15500 метров. Впрочем, на первое время, можно обойтись аэростатами.

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

База: ООП, базовые алгоритмы и структуры данных, умение гуглить.
База для работы в команде: коммуникабельность, неконфликность, стрессоустойчивость.
База по беку: php7, mysql, git, http, ssh, linux, phpstorm.
База по фронту: html/css/js/ajax/jquery, работа с панелью разработчика в браузере.
То, что отличает мидла от джуна, опыт: 2-3 года коммерческой разработки - основные проблемы с серверами, БД, сервисами, архитектурой, основные способы их решения, боль, примеры как не нужно делать, умение писать лаконичный, понятный, поддерживаемый код, библиотека готовых удачных решений (можно в голове, главное понимать, почему лучше сделать так, а не иначе), решительность. Умение рассказать об этом опыте, о встреченных проблемах и найденных решениях - без этого оффера, само собой, не будет.
Это то, что требуется почти везде.

Бонусом будет gitlab, postgres, docker, unit-тесты, curl, rest, elastic, regexp, операции над множествами (для фильтрации/поиска/пересечений массивов данных). Всё это можно добрать по необходимости, но работу упростит и время сэкономит.

Конкретный бек и фронт фреймворк не проблема добрать во время работы, под конкретный проект - документация есть.
Но как минимум по одному нужно пощупать на беке и фронте, чтобы понимать общий принцип. Я бы рекомендовал symfony и vue, но это, конечно, не принципиально.

На некоторых позициях фронта нет совсем, или заявляется, что нет фронта. Но как правило он там есть, и база по фронту лишней не будет.
Фронта нет только на узких api-проектах, там только работа с curl и БД. Но если проект предоставляет личный кабинет, настройки - этот личный кабинет и формы настроек придется писать и поддерживать, а это фронт.
В общем php без html почти не бывает, а html без css/js/ajax и подавно.

Верстка скорее не нужна, чем нужна.
На большинстве позиций в IT-компании базы по фронту достаточно, т.к. основную работу по вёрстке будут отдавать конкретно верстальщикам или фронту, от тебя максимум, что потребуется - точечно поправить какие-то мелкие баги верстки(поправить размер/цвет/текст), внедрить ajax, натянуть вёрстку, вывести данные, подключить стили/скрипты. База по фронту позволит серьезно сэкономить время, понимая 80% происходящего на фронте, выполнять работу быстрее за счёт намного более редкого обращения к вёртальщикам/фронтендерам, т.к. правки минутные, а бюрократия может занять дни.
В непрофильных конторах заинтересованы в человеке-оркестре, чтобы за одну зарплату купить целый IT отдел. Но и зарплаты там намного меньше, чем в IT-компаниях, т.к. IT в непрофильных конторах не является основным источником дохода, а скорее идёт как довесок, без которого нельзя, но от которого хотелось бы избавиться. Так что требований будет больше: админ-фуллстек-дизайнер-менеджер за 30к.

update without touching timestamps

Поставьте галочку для preserve log, так не будут очищаться запросы) это для хрома

Никакой. Фронт надо делать на Windows.

если обе работают, очевидно что версия не выше самой нижней (5.4 в вашем случае).

если вусмерть нужно узнать поддерживаемые версии, то https://github.com/PHPCompatibility/PHPCompatibility и аналоги в помощь.

$post = json_decode(file_get_contents('php://input'), true);

Конечно! Будете говнокодером.

Используйте функцию array_map.

Мой пример:

array_map(function (Value $value) {
   return [
      'label' => $value->characteristic->name,
      'value' => $value->value,
   ];
}, $product->values);

Ваш пример:

$answers['answers'] = array_map(function ($item) {
   return [
      'id' => $item['qid'],
      'aid' => $item['aid'],
   ];
}, $query);

Есть разные понятия джиттера, основное это резкое изменение фазы сигнала (например при последовательном воспроизведении двух музыкальных треков). Однако в сетях джиттером обычно называют просто "прыгающий пинг", т.е. разброс во времени прохождения сетевых пакетов. Т.е. если у вас все пакеты идут по 2 миллисекунды, то джиттера нет. Если все пакеты по 200 миллисекунд то джиттера тоже нет. Но если часть пакетов идет по 2 и часть по 200 - то это джиттер. Джиттер есть практически в любых броадкастных сетях, в т.ч. и в Ethernet, при высоких загрузках среды передачи. В WiFi выраженность джиттера будет зависеть от нескольких факторов, основной это загруженность используемого частного канала. В многоквартирном доме или офисном здании с кучей небольших компаний это может быть достаточно серьезной проблемой. Джиттер плох в основном для игр и реалтаймовых протоколов (голоса, видео).

Если вы не наблюдаете рандомных задержек пинга даже при существенной нагрузке на сеть, то проблемы джиттера у вас нет.

Скачайте исходники Битрикса. Там копролиты десятилетней давности присутствуют до сих пор и, к сожалению, никак не закончат свой жизненный цикл.