Алексей Уколов

1. Сортируете свой массив по городу.
   
2. Заводите новый массив, двумерный, в который будете складывать записи.
   
3. Итерируете по своему отсортированному массиву и смотрите, не поменялся ли город и не стало ли записей три. Если нет, то добавляете запись в последний подмассив двумерного, если да, то добавляете в двумерный новый массив и кладёте запись в него.
   
4. Выводите получившийся двумерный массив куда надо.
   

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

Ну вам же на двух языках пишут: вы не заполнили параметр api_paste_code. У вас почему-то содержимое передаётся в api_paste_data, о котором документация ничего знает.

Что-то у вас намешано.
Юнит-тестам не нужен никакой ключ (подойдёт любая строка). Конечным пользователям не нужно тестировать пакет, разумнее его мокать.

Но если хочется всё-таки проверить, например, корректность инициализации, то решение о том, как создавать инстанс класса библиотеки, за конечным пользователем. То есть, пользователь передаёт в конструктор какую-то строку. Где он эту строку возьмёт - зависит от конкретного приложения. Современный стандарт - заполнять контейнер конфига из ENV, а потом этот контейнер использовать. Следовательно, зашивать строку в phpunit.xml - вполне нормальное решение. Если на конкретном проекте это почему-то не работает, то нужно обсуждать предметно.

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

что я делаю не так?

Используете древнюю библиотеку на современной версии php. Или ищите замену, или ставьте php 5.

# Save the DB to disk.
#
# save [ ...]
#
# Redis will save the DB if the given number of seconds elapsed and it
# surpassed the given number of write operations against the DB.
#
# Snapshotting can be completely disabled with a single empty string argument
# as in following example:
#
# save ""
#
# Unless specified otherwise, by default Redis will save the DB:
# * After 3600 seconds (an hour) if at least 1 change was performed
# * After 300 seconds (5 minutes) if at least 100 changes were performed
# * After 60 seconds if at least 10000 changes were performed
#
# You can set these explicitly by uncommenting the following line.
#
# save 3600 1 300 100 60 10000

https://redis.io/docs/latest/operate/oss_and_stack...

У PHP разные файлы настроек для разных сред. Вы поменяли настройки для CLI (консоли), а нужно для FPM (скорее всего).
Вы вывели вот phpinfo() — там указан файл, из которого берутся эти настройки. Поищите по странице «.ini» и увидите, где менять.

1. Текст прекрасно центрируется по горизонтали. Если вам нужно центрировать его ещё и по вертикали, то есть располагать по центру изображения, то для этого нужно написать хоть какой-то код. У вас указан только text-align, он работает, странно ожидать чего-то большего.

2. Укажите желаемый цвет фона в .items.

«Некоторую информацию» нужно хранить в стейте или менеджерах, «работать с DOM» нужно средствами Реакта, а для истории использовать соответствующие библиотеки. И вот от класса ничего не осталось, можно его удалить.

Положите ассеты на Гитхаб и подключайте оттуда.

Такие файлы кладут вне директории, которую обслуживает веб-сервер. Примерно так:

./db.php
./public/index.php

В db.php вы подключаетесь, реквизиты храните в нём же или в .env-файле рядом (или ещё как-то), а в настройках веб-сервера в качестве корневой директории указана public. Тогда через него невозможно будет обратиться к "секретному" файлу.
(есть ещё всякие уязвимости, которые делают такую защиту всё же не стопроцентной, но они далеко за рамками данного вопроса).

Проблемы, естественно, есть, поскольку есть уязвимости.
Столкнётесь ли лично вы с ними никто не знает.

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

Если в компании нормально кадровый процесс построен и нет требования «познакомиться лично», то не нужно. Документы либо электронно подписываются, либо пересылаются почтой.

Ну, скроете вы его, а дальше HR либо на этапе первичного разговора, либо уже на собеседовании спросит всё равно. Надеяться, что удастся убедить при живом общении можно, но, учитывая огромный пул одинаковых кандидатов, шансы невелики. Поэтому я бы советовал быть максимально прозрачным и написать какой-то сопроводительный текст, объясняющий ситуацию. Тогда на собеседование вас позовут люди, которых ваша учёба не пугает по каким-то причинам — сэкономите время и себе, и другим.
Само по себе отсутствие диплома почти никого не отпугнёт, а вот дополнительная занятость вполне может. Если даже вы успешно такими манёврами куда-то пробьётесь, есть шансы быстро вылететь, когда люди поймут, что получили не то, на что рассчитывали, и придётся уже это объяснять на следующих собеседованиях.

Попробуем отделить коней от людей, насколько это получится.
Говоря просто: API - для отдачи непосредственного среза данных, обычно в виде JSON, WEB - для отдачи целых страниц в виде HTML.

Всегда думал что api.php нужно для запроса от сторонних приложений, сайтов к твоему сайту для получения какой то информации, которую я хочу предоставить, без авторизации.

Ну, неправильно думали, ничего страшного. Точнее, очень узко. Вот есть у вас сайт, а потом вы решили сделать к нему в пару мобильное приложение. Оно стороннее? Ничего сделать с отданным через WEB HTML оно не сможет*, потребуется API.
Наличие или отсутствие авторизации тут совершенно ни при чём.

в тоже время используя api.php любой человек может запросить любой роут и получить кучу информации

Любой человек получит то, что вы ему отдадите. Никакого запрета (или сложностей) на внедрение авторизации в API нет.

Количество Middleware на web.php значительно больше, т.е. любой запрос проходит больше проверок перед тем как выдать результат.

Middleware - это любые обработчики, а не только проверки. Т.е. "больше обработчиков не значит больше проверок". Любые обработчики вы можете навесить и на API**. И их даже не надо писать отдельно, в Laravel уже всё есть.

В итоге вопрос, с точки зрения безопасности, производительности есть преимущества api.php перед web.php

С точки зрения безопасности разницы нет. API может быть несколько производительнее за счёт того, что обрабатывает и отдаёт меньше "лишнего". Но по этим аспектам их вообще не надо сравнивать, это всё равно, что выбирать между экскаватором и самосвалом по степени лёгкости угона того или другого.

* без костылей
** с поправкой на отсутствие сессии обычно

Со степенями в Питоне всё прекрасно. Просто запись -10**2 эквивалента записи 10**2 * -1, а не (-10)**2. Переменная как раз как бы добавляет эти скобки вокруг значения.