Dmitry MiksIr

Вы определитесь с целью.

Если вы хотите давать разные виды доступа (с разными лимитами) разным пользователям - то да, считать. Не по IP, конечно, а по ключу/логину и т.п. Хранить в базе соответствующие показатели, накапливать запросы и пересчитывать счетчики с какой-то периодичностью. Если нагрузка мала - можно и на каждый запрос считать.

Если цель - защитить скрипт от флуда - это делается на уровне веб-сервера или даже фаирвола. Но в таких случаях не стоят задачи "до 1000 запросов в день", там стоят задачи "N запросов в секунду". Для nginx, например, модуль ngx_http_limit_req_module.

Вот тут все популярные способы https://habrahabr.ru/post/114997/
Наиболее популярный - N-грамм метод. Готовые реализации есть в mysql 5.7 и postgresql. Впрочем, и самому сделать реализацию весьма просто.
Ну и в добавок к этому я бы предложил вбивать не только оригинальное название, но и звучания на русском и английском в отдельных полях хранить и использовать их для поиска тем же три-граммом.

Думаю под знанием linux подразумеваются базовые знания пользователя, такие как:

• отличие наименования файлов (case-sensitive, slash), символьные ссылки, как работают права доступа, как запускаются скрипты.
  
• основы шела, путешествие по файловой системе, основные команды (типа ls, mkdir, mv, rm, grep, tail, head, и т.п., пайпы и редиректы, sleep и bg процессов)
  
• представлять, что такое процесс, базовые вещи по управлению ими (ps хотя бы).
  
• что такое крон, как им управлять.
  

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

Я вот добавлю. Адаптивная верстка вообще как раз и нужна для того, что бы сайт на меньших экранах выглядел не так, как его просто масштабировали, а более адаптивно ;)
Т.е. не так

А вот так

1. git сервер, можно взять saas решения (гитхаб, гитлаб и т.п.) или сделать свой (самое простое - просто ssh доступ к серверу и сделанный там git init --bare)
2. git clone на dev сервере
3. Хук post-receive на git сервере, который сходит по ssh на dev сервер и сделает там git pull. В случае гитхаб и т.п. - смотреть их вебхуки и т.п. - и по их вызову уже делать git pull). Конечно, всякие миграции и прочее придется исполнять руками. Или брать системы деплоя уже и использовать их.

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

Задача дергать все контролы - это не задача программиста. Если тимлид и руководство требует это от программиста - это просто самодурство и некомпетентность. Программисты тестировать свой код не умеют. Это аксиома.

PHP5
Postgresql

> Как разобраться что работает на сервере?
Заглянуть в сервер. Или искать информацию по разработчикам проекта в интернете.
Например, https://moikrug.ru/dmitry