Composer: require-dev в определенную папку?

Фигово, менеджер пакетов, а банально скачать папку из репозитория, без танцев с бубном не может

Как осуществить мониторинг php-fpm?

То лог, а мне realtime надо, тем более если висит процесс, который еще не завершен.

Рационально ли использование даты в качестве соли при хешировании данных?

Спасибо.
P.S. Соль естественно состояла бы не только из даты.

Рационально ли использование даты в качестве соли при хешировании данных?

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

Рационально ли использование даты в качестве соли при хешировании данных?

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

Рационально ли использование даты в качестве соли при хешировании данных?

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

На чем создать БД автосервиса?

Тут вопрос на сколько будет гибка и подходить под ваши задачи бесплатная система. При бюджете в 5к она врядли будет достаточно универсальной. Посмотрите microsoft access, у меня друг там спецификацию оборудования вел. Но так как это элемент microsoft office — 5к не отделаетесь (и это не веб интерфейс).

Стратегия git ветвления для модульной основы проекта

Как я понял, личного репозитория через composer получить не удастся, нужно регистрировать пакеты на их сайте. Я правильно понял?

Стратегия git ветвления для модульной основы проекта

Я правильно понимаю что одно из предложенных вами решений позволит разделить написанный мной код на пакеты с зависимостями и свободно их применять и откатывать?

Стратегия git ветвления для модульной основы проекта

Ну собственно вопрос был как создать проект B на основе проекта A (желательно, чтоб изменения в проекте A автоматически или максимально просто переносились в B). На счет авторизации вы правы — это обособленная функциональность, но включать ее в проект, особенно при использовании фреймворка можно и путем редактирования нескольких файлов в разных каталогах (Метод авторизации, миграция для БД, расширение класса пользователя). А веткой это изменение является, потому как не в каждом проекте нужна авторизация.

Стратегия git ветвления для модульной основы проекта

Я так понял вы предлагаете создать клон репозитория и в нем смержить ветки. В принципе подходит. Есть только один минус — при внесении изменений в оригинальном репозитории — не понятно как их добавить в уже смерженные ветки…

Стратегия git ветвления для модульной основы проекта

В данной ситуации использование субмодулей не поможет, так как подключение БД вносит изменения не только в дочерней директории. Кроме того даже если использовать систему подмодулей, то как это облегчит создание проекта на основе дерева…

Стратегия git ветвления для модульной основы проекта

А вы под форкнуть что подразумеваете?

Немного вопросов о условиях?

1) Я это выяснял очень давно, поэтому линк не найду, попробую суть своими словами:
В момент join по cути просходит перемножение строк которое фактически проверяет условие для каждого пересечения т.е.
количествоСтрокПервойТаблицы*количествоСтрокВторойТаблицы, и если в join добавлять условия не имеющие отношения к соединению, то вы их выполняете при каждой проверке, т.е. неоправданно много раз. А вот where это простая фильтрация, которая выполняется для результирующего(или исходного, тут не помню) количества строк, т.е. значительно меньше раз. Таким образом в правильно составленном запросе, все условия фильтрации должны быть в where и having.
2) Я не разбирался на уровне оптимизатора, просто много раз писал запросы, которые выполнялись очень долго и приходилось их оптимизировать, так вот ни разу перестановка условий не повлияла значительно на время выполнения.
3) Аналогично первому.

Немного вопросов о условиях?

1) я же вроде написал выше наверняка… Или вы выбрали один ответ и только его ветку мониторите?

Как заставить WEB сайт работать локально в Chrome?

т.е. вместо окна в браузере, полноценный веб сервер на каждом компе поднимать?

Персональный доступ к файлам на сайте?

А если пользователи будут работать за одним компьютером и в кэше сохранится путь к файлу, да и мало ли ссылку один другому скинет — что воспрепятствует просмотру и скачиванию файла?

Персональный доступ к файлам на сайте?

А ваш метод учитывает возможность обращения по прямой ссылке?

Вопрос: решения для регистрации и аутентификации пользователя

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

Вопрос: решения для регистрации и аутентификации пользователя

Я думал попробовать реализовать решение, описанное: здесь или здесь и прикрутить уже какой-нибудь виджет для авторизации через соц.сети/почтовики

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