Stepan Yudin

Телнет проходит? В обе стороны? Если нет (особенно, если от сервера до клиента) - это и есть причина, копайте фаерволлы и т. п.

Вам подойдет Lenovo IdeaPad 520-15IKB (80YL00LXRA) ибо легкий и все потянет, там аж 16 гб оперативки и видюха на 4 гига + 1ТБ HDD + SSD 256 гб + 15" IPS. Правда там DOS и два ядра, но вам подойдет.

1) Можно ли взять достойный лаптоп в этот бюджет? И какой?

Можно. Какой не подскажу т.к не знаю, но на М.видео за 30 есть вполне годный.

Если да - насколько он сольет десктопу аналогичной цены?

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

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

Вполне. Есть такие и с i7, чего думаю вам хватит.

И если брать десктоп - то какой i5/i7 выбрать? Их что-то немеряно развелось на рынке

Конечно лучше i7, но если там будет 8 гигов оперативки, то i7 вам не поможет, уж лучше купить с i5, но 16 гигов.

Лучше vuejs.org еще ничего не придумали.

Я бы советовал строить CRM на базе существующих решений. Например, в мире PHP есть OroCRM, открытый исходный код, вменяемая архитектура, строится на базе symfony, тем самым упрощается поиск разработчиков.

Делаем мы тут одну облачную CRM для турфирм...
Первая версия вышла где-то в $60K, но покупать не хотели.
На тот момент, когда клиенты уже готовы были платить деньги за использование, в систему было вложено около $100K.
Сейчас уже сотни клиентов, системе несколько лет, а она все еще разрабатывается и развивается. И конца этому нет, потому что появились сильные конкуренты.

Интерпретатор php не смог сынтерпретировать ваш файл.

Т.е. сложно понимаю, что "засунуть" в один объект, что в другой, что должно быть статическим методом, что приватным и тд.

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

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

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

И главное, у каждого объекта есть своя область ответственности. UNIX way. Каждый объект делает что-то одно и делает это хорошо. Бывает так что ну... нужно сделать так что бы один объект делал две вещи. НЕ вопрос, мы можем его попросить сделать что-то сложное, а он будет как хороший менеджер тупо делегировать работу другим объектом. То есть он и сложную штуку сделает, и сам не будет знать как она делается.

А все безхозные функции, которые не пренадлежат никаким объектам (например функции порождающие объекты) можно вынести в статические методы. Главное что бы статичесих переменных у нас небыло (ибо это те же глобальные переменные). И поменьше публичного ибо черт его знает что эти разработчики будут использовать. Причем "те разработчики" это вы завтра.

Вообщем писав всё время на процедурке, сложно перейти на ооп.

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

Вы можете начать погружаться в ООП с того, что разобраться "почему глобальные переменные это плохо", почему "состояние порождает сложность" и что такое эта "сложность" (многие почему-то думают что сложность выражается в написании кода а не в его чтении или поддержке), почему "изоляция" (и как следствие инкапсуляция) - это хорошо. Как это все соотносится с декомпозицией. Что такое "ответственность", что такое зависимости, связанности

Подскажите, какой проект начать писать (гостевая, блог), или может начать изучать фреймворк.

Фреймворки универсальны, а значит чистого ООП там быть не может. Во всяком случае нет ни одного фреймворка на котором стоит учиться ООП.

Есть хорошие упражнения на развитие понимания объектно-ориентированного проектирования. Например вот: https://habrahabr.ru/post/206802/

Сразу хочу отметить что это крайности. Упражнения же. Они должны ограничивать вас что бы заставлять думать и задавать правильные вопросы.

Или может подскажите книгу/сайт где пошагово в ооп написан какой-то проект, чтобы быстрее пришло понимание.

Так вы научитесь делать один конкретный проект а на втором вы уже проиграете. Так дела не делаются. Надо разобраться с причинами появления идеи ООП. Ну то есть что было до. Можно еще с функциональным программированием попробовать разобраться. В PHP оно слабо применимо, но основные идеи очень тесно переплетаются с ООП и познав немного функциональщины ваше ООП будет лучше. Да и если про ООП вы можете найти много булшита, про функциональщину врут мало.

1. Норм.
2. Норм.
3. Плохо, транспорт не должен создавать колёса.

Вопрос - как логичней это делать? Учитывая то, что в сущности Wheel по-умолчанию нужно установить нек-рые параметры, к-рые зависят от параметров родителя, т.е. сущности Transport.

Сперва создаёте колесо (через new или через фабрику, как удобнее) и настраиваете параметры, не зависящие от транспорта:
$wheel = new Wheel();

Затем добавляете колесо к транспорту:
$transport->addWheel($wheel);

Параметры Wheel, которые зависят от Transport, определяются в методе Transport::addWheel() или Wheel::setTransport():

public function addWheel(Wheel $wheel)
{
    $wheel->setTransport($this);
    $this->getWheelsCollection()->add($wheel);
}

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

1) Symfony - не MVC фреймворк, это request/response фреймворк. Более правильная терминология для HTTP фреймворка.

2) Контроллеры - это не один класс, это в данном случае весь слой от точки входа, фронт контроллера, до непосредственно экшена контроллера. View в этом случае - это HTTP, пассивная вьюшка и только. Сама по себе она ничего не умеет, это тупо представление данных собранное контроллером.

У этого подхода есть название - Model-View-Adapter или Mediating-controller MVC, но все это лишь бесполезные детали.

3) ParamConverter-ы здорово уменьшают дублирование кода в контроллерах, однако работа с сущностями в контроллерах дело довольно опасное. Это своего рода компромис между "правильной архитектурой" и "стоимостью разработки.