Vitsliputsli

1) в /proc обычно монтируют виртуальную файловую систему дающую доступ к различной информации и ресурсам, предоставляемым ядром.
2) можно, при наличии прав, смотрите устройства tty, или что-то вроде этого.
3) можете при наличии прав.
4) лимиты операционной системы и файловой системы не контролируют содержимое файлов. Но в зависимости от задачи, можно решить, например, с помощью pipe, или ротацией.

Как уже советовали git-flow (например от Винсента Дрейзена). У разработчиков есть право мержить в dev свои ветки, поэтому request не нужны (они хороши при запросах от удаленных разработчиков), из dev собираете и прогоняете тесты ежедневно (CI), затем из dev собираете релиз и кидаете его в master, это уже делает отдельный человек. На сервере (если речь про прод) git быть не должно, должен быть нормальный CD. И да, никаких доступов к боевым у разработчиков. В остальном верно описали.

Включите вывод ошибок или загляните в логи. У вас в 8 строке вывод, поэтому отправка заголовка и не работает.

Делаете коммит с описание что сделали, что недоделали, начинаете коммит строкой "WIP: " (это стандартное сокращение означает "work in progress", многие системы игнорируют коммиты с таким началом описания).
После того как продолжите работу и сделаете логически завершенный коммит, то сделайте rebase и уберите этот коммит из истории (разумеется, если ветка это позволяет).

""грязное" выковыривание данных", "невнятный клубок данных"

А если бы вы написали что передаете объект в метод, а в этом методе используется только 10% свойств переданного объекта, вам бы написали, что это абсолютно нормально. Хотя по-сути это тоже самое.
Имхо, если здесь проблема и есть, то не в самом способе, а в данных, которые передаете. Если это логически связанные данные, то вполне нормально. Если это разрозненные данные, например конфигурация, то лучше пусть разбором будет заниматься отдельная процедура.
50 элементов это, конечно, мелочи, но если все-равно не хочется постоянно делать новые копии, передавайте по ссылке.

Зачем STRAIGHT_JOIN?
Если в таблице всего 20000 записей, а индекс выбрал 18049, есть ли вообще смысл в таком громоздком составном индексе, если все равно пришлось почти всю таблицу обойти? Вполне может оказаться что без него будет быстрее, или оставить только основной столбец, наиболее различающийся, и столбец для сортировки.

например вместо файла function_items.php будет Class Items и всё что в этом файле будет в одном классе, так?

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

Это вечный наверное вопрос здесь, все устали отвечать одно и то же.

output started at W:\domains\test.ru\login.php:1

Вывод у вас начался в первой строке login.php, а с выводом полетели и заголовки. Раз первая строка, то скорее всего есть пробел перед тегом PHP. Уберите его.

Зачем вам делать подобное? Такое делают, когда есть понимание, что обновление в онлайн режиме не допустимо.
Коммерческие СУБД (Oracle, PostgreSQL) имеют внутренние планировщики для этих целей.

$timeInterval = new DateInterval('P111DT2H3M4S');
var_dump($timeInterval->format('%d day(s), %h hour(s), %i minute(s), %s second(s)'));

SELECT * FROM table WHERE id IN (
select id1 from table2
union all
select id2 from table2
)

Посчитать расстояние между 2 точками - простейшая арифметика (чтобы ускорить выборку можно задействовать индексы, сперва выбирать по квадрату, а затем уточнять расчетом для окружности). А принадлежность к административным единицам определять по ФИАС для России. Какие страны ещё задействованы?

Да, вполне, почему нет. В какой-то степени даже соответствует правилам реляционных СУБД, а их все ни одна СУБД не выполняет. Есть вопросы к резервному копированию и журналированию, т.е. к надежности, но это ограничения больше клиента Excel, а не встроенной СУБД Excel.

Есть замечательная либа ReactPHP, с помощью который ваш сервис может выполнять что-либо по таймеру. И как доказывает Ratchet, проблем с утечкой памяти нет, если сами их не создадите.

В большинстве СУБД есть журнал транзакций. Кроме MS SQL, в PostgreSQL он используется для восстановления состояния с момента бекапа до момента сбоя. В Oracle сможете посмотреть что было, когда было и сможете обращаться к таблицам из прошлого обычным SQL. Но этот механизм имеет ограниченное время просмотра.
Поэтому лучше подобное решать не средствами СУБД.

Потому что путь не верен, у вас даже в задаче они разные.

Сертификаты не нужны. Некоторым все же нужны, чтобы потрясать перед клиентами, но всерьез их никто не воспринимает (разумеется английский другое дело).
Портфолио могут и не спросить, да его может и не быть, если разрабатывал внутренние системы.
Требования у всех разные, кто-то требует умение самостоятельно разрабатывать несложные сервисы с применением фреймворков, а для кого-то достаточно базовых знаний и желания учиться.
Плюсом может быть умение работать в команде, умение писать тесты, знание git, базовые знания Linux. Для отдельных restful api.
Не все спрашивают, но важно понимание протокола http, на уровне типов запросов и их составляющих, web-сокеты пока с джунов вроде не требуют.
В больших городах предложения на любой вкус, но больше в соответствии с современными тенденциями (фреймворки, composer и т.п.). В маленьких много любителей велосипедостроения. В любом случае, есть из чего выбрать.