Anton Mashletov

Единственно хороший совет, если вы хотите, чтобы ваша форма была профессионально сделана, и нормально работала, нанять разработчика.

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

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

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

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

Когда работаете в одиночку:
1. Для миграции/синхронизации базы:
1.1. Раз
1.2. Два
1.3. Три

2. Для файлов:
2.1. Раз
2.2. Два (с визуальным сравнением контента перед синхронизацией!)
-----------------------------------
Когда работаете в команде (или без) - подключаемся через систему контроля версий (VCS) из того IDE, с которым привыкли работать:
PhpStorm VCS Help

ну во первых структура папок . типа
/app
/var
/public
/log

а не все в www
пользовательский контент и статика вообще может быть на субдоменах без права исполнения.

нет не подойдет

ИМХО направление развития PHP сейчас идёт с большим уклоном не на новые возможности, а на уменьшение количества способов выстрелить себе в ногу (если посмотреть на список всего того, что выкинули или объявили устаревшем в 7.0 - 7.2). Во всё большем количестве случаев PHP оставляет только один способ сделать что-то и даёт всё меньше возможностей сделать чёрт знает что. Лично для меня вот это значительно приятнее, чем мешочек синтаксического сахарка, который добавили (или не добавили) в очередной версии. Всё же PHP чаще ругают за то, что он слишком уж многое прощает и тащит груз не самых удачных решений из прошлого, а не за недостаток возможностей. И зачастую небезосновательно.

Минусы? Да полно:

1. Махровая бюрократия
- Будьте готовы устраиваться на работу в срок до пары месяцев, проходя всякие медосмотры и бегая подписывая бумажки.
- В случае, если вам что-то нужно по работе - это тоже нужно кучу раз согласовать и подписать
- Куча бесполезной работы в виде оформления "по госту" документов (даже если вы программист, да)
- Любая работа это ТЗ, а ТЗ это согласования. Нудно и долго.
2. Устаревшая материальная база
- Обычно на госпредприятиях не жалуют новшества
3. Отсутствие нормального доступа в интернет
- Его либо вообще нет, либо через отдельный компьютер с ЭЛТ монитором в углу. По записи. Иногда можно сидеть через ЮСБ-модем, пока по шапке не дали - за свой счет, естесственно.
4. Куча бездельников
- Обычно на госпредприятиях собирается куча неудачников, которых в другие места не взяли. Как это может быть минусом? А так - ваша работа может быть завязана на других людей, которые свою часть сделать не торопятся или, в особо запущенных случаях, будут делать халтурно и потом пытаться валить все на вас.
5. Гнетущая атмосфера
Вся эта хрень с интернетом, бездельниками и бюрократией отбивает желание что-то делать и как-то развиваться. Зачем? У вас и так все будет - лет через 20-30. Вряд ли иностранная компания возьмет такого сотрудника.

Вышесказанное мой личный (слава богу, небольшой) опыт. Возможно, где-то ситуация и получше.

Согласен с LeEnot. Всё описано прям в точности, как было у меня. К сожалению, я провёл в этом учреждении очень много времени. К счастью - я всё-таки одумался ) Теперь приходится усиленно навёрстывать упущенное. Очень много времени тратилось на совершенно посторонние для программиста занятия - субботники (прям как в школе), перетаскивание архивов из одного помещения в другое, производственные лекции (темы которых совершенно не имели отношения к IT), возня с документами (приказы, рапорты и прочая ерунда). В итоге за рабочую неделю удавалось заняться программированием максимум 2-3 дня. Кстати о программировании там: всё плохо ) Распишу подробнее:

- интернета действительно не было, только на отдельном компьютере. Это был тихий кошмар, когда необходимо было посмотреть что-то на stackoverflow или скачать какую-нибудь библиотеку. Беганье туда-сюда от рабочего компьютера к компьютеру с интернетом очень быстро утомляло.
- Материальная база действительно устаревшая. Половину комплектующих рабочего компьютера я купил за свои деньги, ибо работать на тормозном железе было крайне некомфортно.
- Низкий уровень программирования в целом. Никто не знал, что такое CVS, никакого ООП, тем более Design Patterns и т.п. не использовалось абсолютно. В принципе каждый программист вёл какие-то свои приложения, в которых разбирался только он. Как следствие - никакого опыта командной работы.

Единственная ложка мёда в бочке дёгтя - дозволялось применять любую технологию, которая бы выполняла поставленную задачу. Благодаря этому я мог писать сначала на Delphi, потом на C# и на PHP. Но любой интересующий язык программирования можно изучить и дома, в свободное от работы время, так что эта ложка мёда не существенна )

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

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

# php/Dockerfile

FROM php:7-fpm:latest

MAINTAINER Vasya Pupkin

# Ставим, например, composer.

RUN php -r "readfile('http://getcomposer.org/installer');" | php -- --install-dir=/usr/bin/ --filename=composer

Затем обновляем docker-compose.yml. Указываем, что будем использовать свой Dockerfile и указываем имя нового образа.

php:
        build:
	    context: ./php
	    dockerfile: Dockerfile
        image: my-php
        volumes:
            - ./www:/www
            - ./php/log.conf:/usr/local/etc/php-fpm.d/zz-log.conf
        networks:
            - code-network

Чтоб теперь можно поиграться с композером, можно сделать следующие вещи:

1. Зайти в контейнер по ssh и запускать композер оттуда

docker-compose exec my-php bash
composer --version

2. Запустить композер с хостовой машины

docker-compose exec my-php composer --version
или

docker-compose run --rm  my-php  composer --version

Чтоб чуть упростить набор команд, можно создать скриптик на bash (установи себе git bash на windows, из него можно будет выполнять его).

#!/usr/bin/env bash

COMPOSE="docker-compose"

if [ $# -gt 0 ]; then
    if [ "$1" == "composer" ]; then
        shift 1
        $COMPOSE run --rm \
            -w /www \
            my-php \
            composer "$@"

    # If "test" is used, run unit tests,
    # pass-thru any extra arguments to php-unit
    elif [ "$1" == "test" ]; then
        shift 1
        $COMPOSE run --rm \
            -w /www \
            my-php \
            ./vendor/bin/phpunit "$@"

    # If "npm" is used, run npm
    # from our node container
    elif [ "$1" == "npm" ]; then
        shift 1
        $COMPOSE run --rm $TTY \
            -w /var/www/html \
            node \
            npm "$@"
    else
        $COMPOSE "$@"
    fi
else
    $COMPOSE ps
fi

Ну и с его помощью можно делать следующее

./dev.sh # docker-compose ps
./dev.sh logs my-php # docker-compose logs my-php
./dev.sh composer --version # выполнение любой composer команды
./dev.sh npm --version # выполнение любой npm команды
./dev.sh test --filter some_test_method # запуск phpunit тестов

P. S. У меня тоже, когда-то, докер сложновато шел. Это нормально.

flexbox-сетка в контейнере с overflow-x/y:hidden и парой строк js для стрелок.

IDEA с плагинами для разных ЯП обновляется реже чем, продукт для каждого отдельного стека

Если вам не важна скорость появления фич, то обратитесь к ним в поддержку со своим вопросом
Jetbrains идут на встречу своим покупателям

Для указанных требований подойдет эксель.

Хотелось бы узнать в чем различие между Virtualbox(VMware) и Docker?

Docker - строгая изоляция ресурсов внутри операционной системы Linux.
Не более того. То есть бинарный файл запускается в той же ОС, но не имеет доступа за пределы выделенной ему клетки. Программа (одна-единственная вообще говоря в Докер предполагается программа) может иметь свои-собственные зависимости, более того, допускается использование совсем другой версии Linux внутри Докер-контейнера.

Но это не виртуализация. Точнее можно назвать это изоляцией от окружения (настроек) операционной системы. Смысл Докера именно в этом - чтобы можно было запусить программу почти где угодно, не настраивая ее под другую ОС (не устанавливая библиотек, не прописывая путей, портов, не создавая настроечных файлов по возможности и пр.).

Это делается на уровне API ОС, следовательно, довольно не накладно по производительности. Правда, при неграмотном использовании (когда в качестве предков в образе используются разные образы) накладно по расходу дискового пространства.

В частности Docker умеет запускать только Linux из под Linux, причем не какие угодно версии годятся, в контейнере Докера может быть только специально подготовленная (облегченная). В других OC - Windows, MacOSX - Докер реализован как полноценная виртуальная машина с Линуксом, следовательно, жрет ресурсов много.

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

Запуск виртуальной машины сопряжен со значительными затратами времени. Лучшие виртуальные машины откусывают не менее 15% производительности....

Запуск программы в Docker - сопоставим с запуском обычного бинарного файла внутри обычного операционного окружения (если уж быть точным - то чуть больше, но незначительно).

При грамотном использовании вы можете запускать на обычном домашнем компьютере хоть сотни Докер-контейнеров.

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

Если я правильно понимаю, я могу и там и там поднять любую ОС, к примеру ту же Ubuntu и LAMP.

Внутри Докера - далеко не любую. Выбор ограничен считаным числом специально подготовленных дистрибутивов Линукса.

Внутри Virtual Box - действительно любую.

Только разница в том что к Docker я буду иметь доступ сразу же из bash, а к VB через её окно или ssh,

То, что вы хотите и через Virtual Box легко реализуется с помощью инструмента Vagrant. Будет иллюзия, что вы в Докере работаете.

плюс если я выйду то в виртуалке все сохранится, а в Docker без коммита все умрет? Или есть другие важные отличия...?

То, что вы имеете ввиду - можно сделать и внутри полной виртуалки - отключить персистентное сохранение на диски.
То, о чем вы пишете - это просто концепция стейтлесс-контейнеров. То есть внутри все настроено раз и навсегда. Все изменения контейнер Докера должен делать только на смапированных внешних девайсах. Это гарантирует постоянство внешней среды для программы внутри Докер-контейнера. Крайне важно для повторяемости в продакшене. Чтобы не пришлось в 3 ночи просыпаться и искать отчего ваш сайт с миллионой посещаемостью перестал работать. Ах это потому что какая то софтина не имеющая отношения к вашей программе обновилась и потянула за собой библиотеку, не соместимую по версией с тем, что вы используйте.

Пишут что Docker активно применяется при программировании и переносе workstations. Тоесть имеется ввиду, я могу работать с кодом прямо в docker image, после коммитить, пушить, а затем все это запускать на сервере без установки зависимостей?

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

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

Vagrant, насколько я понимаю активно применяется при создании images и конфигурировании их же?

При разработке - да.
Так как ты можешь работать в несовместимой с docker средой (например, в Windows) и отладка возможна только через виртуальную машину.

В продакшене - нет. Так как слишком большие накладные расходы на виртуальную машину.

И последнее, могу ли я:
Запустить image в Linux, сделать правки в коде (кстати как это сделать, к примеру в том же *storm, Sublime. ... ) и закоммитить.
После войти в Windows, запустить image и там продолжить разработку?

Думаю да,
но это не то, для чего создавался Докер.

А написание кода внутри виртуальной машины - возможно. Я сам так делаю.

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