Игорь Воротнёв

В ассоциативном массиве PHP порядок всегда соответствует последовательности добавления в него ключей.

$array = [
  [
    "gq_address" => "188.120.254.140",
    "gq_hostname" => "•   RGPlay | DarkRP [Быстрая загрузка]",
    "gq_maxplayers" => 128,
    "gq_numplayers" => 0,
    "gq_online" => true,
    "gq_port_client" => 27015,
  ], [
    "gq_address" => "62.109.18.242",
    "gq_hostname" => "Default Breach Server",
    "gq_maxplayers" => 128,
    "gq_numplayers" => 0,
    "gq_online" => true,
    "gq_port_client" => 27015,
  ]
];
$array = array_map(function($el) {
  return [
    'gq_hostname' => $el['gq_hostname'],
    'gq_address' => $el['gq_address'],
    'gq_port_client' => $el['gq_port_client'],
    'gq_online' => $el['gq_online'],
    'gq_numplayers' => $el['gq_numplayers'],
    'gq_maxplayers' => $el['gq_maxplayers']
  ];
}, $array);
var_dump($array);

array(2) {
  [0] => array(6) {
    ["gq_hostname"] => string(55) "•   RGPlay | DarkRP [Быстрая загрузка]"
    ["gq_address"] => string(15) "188.120.254.140"
    ["gq_port_client"] => int(27015)
    ["gq_online"] => bool(true)
    ["gq_numplayers"] => int(0)
    ["gq_maxplayers"] => int(128)
  }
  [1] => array(6) {
    ["gq_hostname"] => string(21) "Default Breach Server"
    ["gq_address"] => string(13) "62.109.18.242"
    ["gq_port_client"] => int(27015)
    ["gq_online"] => bool(true)
    ["gq_numplayers"] => int(0)
    ["gq_maxplayers"] => int(128)
  }
}

1) На сколько удобны Homstead + Vagrant, которые они рекомендуют использовать? Посмотрел информацию по его установке, использовании. Разве это удобнее всем привычного openServer?

Насколько удобен конкретно именно этот стек, и насколько он удобен будет лично для Вас - сказать затрудняюсь, но в общей сложности, использование "родной" среды при разработке приложения - практика весьма правильная. Думаю что в данный момент, большинство моих эпитетов на тему "почему оно так и зачем" Вам будут не очень интересны, но, есть простой пример из реальной жизни: в *nix, чаще всего, файловые системы чувствительны к регистру имён файлов, в Windows [NTFS] (и OpenServer в частности) - такой чувствительности нет, что влечёт за собой потенциальные ошибки в самый неподходящий момент (когда Вы будете выгружать сайт на хостинг) и исправить их "по быстрому" удаётся не всегда, по этому, я бы рекомендовал использовать "родной" Linux при разработке. Какой стек взять - сакрального значения не имеет, мы используем: Docker (Hyper-V), VirtualBox + настроенную самостоятельно вирт. машину и различные другие варианты (среди которых, OpenServer проскакивает крайне редко).

2) Прямо из коробки Laravel поддерживает Vuejs, но посмотрев их курсы на Laracasts и ещё пару примеров компонентов для него, мне показалось, что он не совсем подходит для того, чтобы делать на нём те же слайдеры, системы частиц и подобные вещи.

VueJS - это JS фреймворк, волей судьбы "встроенный" в Laravel. Как мы знаем, JS относится к области вёрстки, что в целом с фреймворком серверным связано крайне слабо. Какие элементы в вёрстке использовать лично Вам - дело - лично Ваше. Из собственного опыта могу сказать, что мы в своей работе не гнушаемся ни VueJS, ни jQuery, ни различными готовыми слайдерами и вообщем всем, что может быть уместно в рамках конкретных требований конкретного проекта. По сему - я думаю Вам не стоит забивать себе этим голову. Насколько и чем хорош VueJS - можно узнать из массы уроков по оному.

Вообще не понравилось, что в HTML-разметке вставляются ивент-слушатели, как в стандартном JS прям (@click, onclick). Мне это напомнило встраивание CSS прямо в тэги. Мне нравится в jQuery то, что все ивенты вешаются прямиком в скрипте, не заглядывая в HTML-разметку.

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

Я просмотрел вакансии на разных сайтах, чтобы понимать, какой стэк технологий нужен работодателям, и в требованиях я вообще не нашёл, что им нужен jQuery, только Vuejs. Отсюда и вопрос, то есть мне нужно переписать свои слайдеры, системы частиц под Vuejs? Часто встречал сообщения о том, что переплетать эти две технологии плохая затея. Либо то, либо то. Посмотрел предложенные готовые слайдеры, вообще не впечатляют.

Работодателю нужны сотрудники способные принимать решения и выдавать конечный продукт. Остальное особого значения не имеет. Если Вы сможете выдавать продукт нужного качества в рамках поставленных сроков, а потом поддерживать этот продукт в надлежащем состоянии - поверьте мне, работодателю будет совершенно всё равно, на как и на каком языке Вы это делаете, хоть на С++ бекенд пишите.

3) Хорошим ли является планом, чтобы сделать воображаемый интернет-магазин для обучения и освоения Laravel? Или как лучше изучать эту технологию от легкого к сложному? Всегда была проблема с тем, чтобы структурировано изучать ту или иную область разработки. Чтобы не тупо копировать, а понимать, как всё устроено и как работает.

Что бы понимать что-то структурно - нужно понимать истоки. В области веб-разработки таковыми "истоками" могут являться например, протокол HTTP, фундаментом которого будет протокол TCP/IP, в основе которого лежат другие технологи... чем лучше Вы будете понимать как всё работает изначально, и в результате чего появилась, например, такая парадигма как MVC, как работает composer так далее, далее, далее... когда Вы будете всё это понимать - в голове будет складываться целостная картина происходящего, а не обрывки каких-то знаний. Разработка интернет-магазина в этом процессе, глобально, погоды не сделает, но какой-то опыт безусловно даст, главное, перед тем как будете разрабатывать собственный магазин - найдите какой-то уже готовый и постарайтесь в точности повторить его функционал, начиная от восстановления пароля заканчивая тем, как в корзине пересчитывается цена при изменении количества товара.

Немного банальностей:
1. Бизнес не даст ресурсов на переписывание проекта с 0: время и большие риски
2. Бизнесу как правило все-равно какое говно там крутится, лишь бы деньги приносило.
3. Если более-менее адекватное руководство - нужно донести идею постепенного рефакторинга кода по мере необходимости в процессе фикса багов и разработки новых фич и тем самым аргументировать что на разработку новых фич/фикс багов нужно больше времени.

Как я бы делал:
1. Тесты на существующие функции (если возможно, видел методы в контроллерах с мешаниной вызовов методов моделей, созданием DTO и сохранением их через репозиторий, прямых http-запросов и запросов в бд на 1000+ строк, покрыть такое тестами - невозможно)
2. Составить план рефакторинга, где отметить что и где надо сделать, коротко, в основном для команды разработчиков.
3. Постепенно рефакторить старый код по мере взаимодействия с ним.
4. Новый код - писать сразу правильно, для взаимодействия со старым кодом где нет возможности/времени его переделать - делать какие-то адаптеры, что бы не распространять токсичный код.
5. Как оперативная мера защиты от SQL иньекций можно поставить что-то вроде этого https://github.com/nbs-system/naxsi
6. Мониторинг кода, который не используется - pinba.org , по мере обнаружения такого кода - удалять безвозвратно (в крайнем случае есть VCS, я надеюсь). Начать с более высокоуровнего кода - контроллеры, напримерю. Плюс IDE в этом могут помочь и grep.
7. Как вариант - новые фичи можно пилить в отдельном проекте (v2), крутить оба и постепенно переходить на новый, со временем старый (v1) выкинуть (и начать делать новый - v3 :-) )

Здравствуйте!
Соглашусь с Игорем Воротнёвым насчет всего, что он вам написал.
Честно, говоря не совсем понял, что именно вы хотите.
1) вы хотите вывести название рубрики (категории) в цикле?
2) вы хотите вывести записи из конкретной категории?
3) вы хотите вывести цикл со всеми категориями и записями к ним?

Ответы:
Информация по WP_Query
https://wp-kama.ru/function/wp_query

- Если вы хотите вывести записи из конкретной категории, то вместо post_type используйте tax_query, как и отметил мой коллега. post_type используется для задания типа записи post, page, "custom_post_type".

Пример цикла с использованием tax_query
https://wp-kama.ru/function/wp_query#parametry-tak...

- Если вы хотите вывести все рубрики и записи к ним, то надо исопльзовать 2 вложенных цикла. Первый выводит термины таксономии, а второй выводит записи
Пример реализации:
https://gist.github.com/azerphoenix/a8c82ffdee27e1...
https://stackoverflow.com/questions/1780386/loopin...

К сожалению просто класс похожий на синглтон.
если по хорошему
то сначала нужно сделать интерфейс Storage, который будет регламентировать работу с хранищем
потом надо на основе этого интерфейса сделать класс который будет работать с COOKIE то есть сохранять и доставать любые данные из этого хранилища
потом делать свой класс player в параметрах коснтруктора указать Storage который в последствии заинжектится нужное хранилище (в данном случае по работе с кукисами)
Это

if(is_dir($session))
{
require_once $session."a.php";
....
}

Вообще полный яд, так ни в одной книжке по ООП не найдете. У вас объект должен быть как можно меньше зависим от сторонних классов и модулей (желательно только от абстракций как указано выше с Storage)
ЗЫ ну и вообще лучше делать автолоад и переходить на неймспейсы.

Используйте стандартные функции Wordpress для загрузки файлов. Тогда на каждый файл будет создаваться вложение, которое уже зарегистрировано в системе, тут же можно и пост создать, и вложение ему присвоить.
Работает с массивом $_FILES, подходит в вашем случае.
media_handle_upload
Более кастомизируемая функция, если вдруг нужно больше гибкости.
media_handle_sideload

P.S Вложения в wordpress — это тоже посты, только с post_type=attachment
А их уже можно вывести стандартным WP_Query в любых вариациях и с любыми фильтрами

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

Потом, он начал говорить, что этого недостаточно, нужно знать как это устроено на уровне файлов и чуть ли не исходников субд. Это действительно, я должен знать подобные тонкости?

Нет это заморочки конкретного человека.

Эксплейн надо понимать, что он выводит и как с его помощью найти проблему, оптимизировать запрос. А так нужно знать про индексы, селективность, транзакции, джойны, group by, having, подзапросы.

Я много раз видел что люди спрашивают, зачем знать SQL, если есть ORM. Десять лет назад, люди спрашивали обратное - зачем нужен ORM, если я тоже самое могу написать на SQL. У меня ощущение, что веб-разрабы с опытом работы от пары лет вовсе не знают SQL. Либо они используют только ORM, либо вообще какую-нибудь MongoDB (хотя во многих случаях ее использование не адекватно задаче).

Ну и от команды к команде средний уровень сильно разнится.

Для миддла надо подтянуть только п. 3. У Светы Смирновой есть несколько отличных презентаций по работе с explain, они легко находятся гуглом.

Еще желательно различать транзакции и блокировки, когда что использовать.

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

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