Владимир Чернышев

.htaccess в каталогах (не нужны права рута) и простая возможность запускать разные сайты от разных пользователей. Вроде так.

В общем случае лучше один. Начинать нужно с него. Когда он начнёт тормозить, то только тогда начинать профилировать, смотреть планы запросов и начинать оптимизировать. Преждевременная оптимизация - зло.

Использую докер-контейнеры как легковесные виртуалки, которыми куда проще манипулировать. И куда меньше душит жаба для конфигов типа "на этой виртуалке будет работать только nginx, на этой только php-fpm, на этой только postgre, эта будет шарить статические файлы для nginx и php-fpm, тут будет лежать кэш, тут загруженные пользователями файлы, а тут база данных"

1.1 и частично 1.2: Зачастую тупо не знаешь под какой осью твой софт будет работать, даже если он чисто внутренний для компании. Даже (или особенно?) если сервер в компании единственный, админ может решить его обновить из-за критической уязвимости или для установки какого-то другого софта.

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

2. Редкость, по-моему, сейчас когда один физический сервис выполняет ровно одну функцию. Да и раньше как-то не практиковалось, по-моему. Контейнеризация позволяет чётко выделять сервисы и изолировать их друг от друга куда меньшими ресурсами чем виртуализация, как при разработке и деплое, так и в рантайме.

3. Зависимости разных процессов не будут конфликтовать друг с другом. Какой-нибудь унаследованный софт будет работать под уже неподдерживаемым дистром, и тут же будет работать софт, использующий самые последние версии каких-то библиотек.

Symfony Validator https://github.com/symfony/validator

Пока не смог найти условий, которые бы он не смог проверить :) Но нужно учесть, что это не столько валидатор форм, сколько валидатор объектов.

В общем случае при грамотной реализации снизится, так как клиенты не будут запрашивать сервер "а не изменилось ли что?".

2 и 3 легко решаются с помощью указания докрута nginx/apache через симлинк, с хранением всех или последних развернутых версий в отдельных рядом лежащих каталогах, как указал Евгений Безымянников, но только в случаях или если нет схемы базы, или если она не меняется, или если приложение нормально работает с разными версиями схемы, не вылетая с ошибками типа "нет таблицы/поля" (в разумных пределах).

Иначе по быстрому можно вопрос решить только с остановкой проекта на время миграции, если база не поддерживает неблокирующее изменение схемы или поддерживает, но не для множественных изменений в одной транзакции, а в проекте требуются множественные, типа переноса столбца из одной таблицы в другую. В таких случаях для SQL баз я не нашёл способа реализовать zero-downtime без переработки приложения (триггеры, хранимки, вьюхи и т. п. - тоже часть приложения) такой что, оно либо временно (пока синкаются в фоне старые данные) пишет в две базы, читая из старой, либо определяет какая версия каких таблиц ему доступна.

Проблема в том, что в сколь нибудь нагруженном приложении, постоянно в базу что-то пишущем, нельзя получить мгновенно в новой базе маппинг старой без промежуточных версий приложения, работающих с двумя базами одновременно. То есть по сути zero-downtime деплой новой версии приложения разбивается на деплой двух версий - первая (промежуточная) работает с двумя версиями базы (естественно с проседанием по производительности), во второй работа со старыми отключается, когда данные двух баз полностью будут синхронны..

Облачная платформа понятие растяжимое, как минимум это IaaS, PaaS и Saas.

1. Так же как веб-приложение документооборота на своих серверах. Облако или свои сервера - забота исключительно админов и девопсов в этом случае.

2. сильно зависит от платформы. На одних отличия от своих серверов могут быть минимальны, на других - почти как 3

3. Согласно спецификации софта

На htmlforum.ru обычно неплохо критикуют, правда больше не с точки зрения красоты, а с точки зрения технологичности.

Как вариант shell_exec('curl -u "username" https://api.github.com') или exec('curl -u "username" https://api.github.com')

Сферический веб-проект с докером DockerApp:
DockerApp/ #корень репозитория окружения проекта
image/
web/
DockerFile
start.sh
app/
DockerFile
start.sh
db/
DockerFile
start.sh
config/
docker-compose.yml
web.conf
app.ini
db.ini
app.yml
bin/
up.sh
down.sh
show.sh
log/
app/ #субмодуль или внешний репозиторий, настроенный на корень репозитория основной кодовой базы проекта

Основная разработка идёт в app/, изменения коммитятся в репозиторий основной кодовой базы. Сервера запускаются скриптом bin/start.sh, который совместно с config/docker-compose.yml поднимает все три сервера, пробрасывая 80 порт веб-сервера на указанный в аргументах порт хоста (на 80 с sudo) и добавляя в /etc/hosts хоста имя домена, также указанного в аргументах (то есть bin/start.sh 80 example.com). В качестве конфигов серверов и приложения монтируются или линкуются конфиги из каталога config.

Это если вкратце о работе на дев-машине на сферическом проекте.

Как правило, в проектах средних размеров (во всех смыслах) одновременно использовать (в смысле вести активную разработку) схожие по функциональности и решаемым задачам фреймворки, да ещё в рамках одного стэка (например, Symfony и Zend) смысла нет никакого. Но вот если нужно решать технически разные задачи (например, обеспечивать обычный http и websockets, или ядро на мощном, компилируемом, тяжелом и(или) "асинхронном" языке/стэке, но использование которого для конечных интерфейсов связано с большими оверхидами, а интерфейсы на чём-нибудь простом и легком), или в случае плавного перехода с одного фреймворка на другой, то активная разработка на нескольких вполне имет право на жизнь.

Деньги на карту неофициально получать именно нельзя - запрещено законом, ответственность вплоть до уголовной и для вас, и для должностного лица работодателя/заказчика.

Что для вас, что для работодателя в случае официальных отношений основной интерес один - в случае ИП на УСН по доходам разница (которая уйдёт государству), между тем, что потратит работодатель и тем, что вы получите на руки, минимальна (6%) по сравнению с трудовыми отношениями (до 40+%).

Но имейте ввиду, что если налоговая сочтёт что за договором подряда или подобным на самом деле скрываются трудовые отношения (пускай и удаленные) и суд с ней согласится, то разница в последствиях с неофициальной работой будет минимальна. Ходорковский это знает :) Серая схема.

В общем, если это реально работа (прежде всего основное отличие - зарплата не привязана к результату и платится два раза в месяц), то лучше устраиваться на работу, но будьте готовы к тому, что на руки будете получать процентов на 40% меньше, чем через ИП или официально, если не можете диктовать свои условия.

Может где-то и есть такое описания, но не считаю его правильным.

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

Представление - визуальное отображение данных модели для пользователя и способов управления ею. Может (а часто - должно) знать многое о получении данных из модели, но не должно изменять состояние модели (в смысле предметной области, технически изменения могут быть, например lazy loading)

Контроллер обеспечивает взаимодействие модели и представления, обеспечивает персистентность модели, безопасность, логирование и прочее-прочее-прочее непосредственно к предметной области не относящееся.

Вроде в последнее время в тренд входят постпроцессоры.