Димитрий

October CMS. Подходит для любых сайтов любой сложности. И главное - если хотите развиваться и изучать реально хороший, качественный код - это опять же, Октобер. Пример крутого приложения на крутом фреймворке (Ларавел). Его спокойно можно изучать и быть уверенным - не прогадаешь, это просто кладезь мудрости для прогера :)
Если брать поверхностно - есть два основных способа:
1. Плагин Static Pages, плюс Blog как пример реализации разных фишек. Это для "разносторонних" страниц, то есть например, есть страница "Главная" где вообще никакой схемы данных нету, а есть набор виджетов "всего понемногу", есть страница "О нас", где надо текстик wysiwyg и список "Наши партнеры" - объекты вида <баннер + заголовок>, "Контакты" - где опять же текстик, три поля для телефона, адреса и e-mail, и пару координат lat/lng для карты, и т.д. - все это дело в реляционную схему БД заталкивать - мучение. Тогда юзаем static pages, там кстати очень похоже на MODx Revo, если кто знаком: layouts - аналог templates, syntax fields - аналог TV, сами страницы - соответственно ресурсы, partials - аналог чанков, компоненты - аналог сниппетов (не путаем со snippets самих static pages, это немного другие, очень кстати полезные, штуки)
2. Плагин Builder для быстрого создания своих кастомных плагинов с БД, моделями, отношениями, и контроллерами бэкенда чтобы этим делом управлять. Это если есть например API, где 200 стран, 100К городов, а в них 2млн мест. Всё это надо скачать и распарсить в базу, и чтобы на выходе получилось 2080200 страниц с 5 шаблонами - один для страны, один для города и допустим ещё 3 под разные типы мест в городе (отель, кафе, достопримечательность). Легко! Пилишь 3 таблицы в БД, создаёшь модельки со связями и роутинг (url'ы прям в таблицах можно хранить, не забывая про индексы) и БЭМ! 2 ляма страниц не тормозят и удобно управляются из бэкенда, для бэкенда куча виджетов - список, форма, менеджер отношений (управлять связанными объектами, умеет и один-ко-многим и много-ко-многим и т.д.). Виджеты можно и свои создавать - как обычные виджеты, так и поля формы. Накидать CRUD набор страниц для управления сущностью в бэкенде - дело 5 минут. Пример с городами и местами довольно примитивный, т.к. тупо дерево из 3х уровней, но и более сложные вещи так же пилятся и не тормозят, хоть там к каждому из 2млн мест надо прицепить ещё по 10 сущностей с полиморфизмом и прочее, и выводить десяток виджетов на их страницах - тут уж ограничение - только умение проектировать БД.

Да там расписывать можно бесконечно :)

PS: В сети встречаются вопросы и issue на гитхабе, читая которые может сложиться впечатление, что ЦМС сырая. Но! Смотрим на дату этих вопросов - меньше 2х летней давности найти сложно. Сейчас там всё "вылизано", Ларавел подтянут до 5.5 LTS, в общем красота! Да, и самое главное - нет такой задачи, которая потребовала бы куда-то там лезть в ядро и что-то править. О таких вещах можно забыть напрочь. Да там даже мультисайтовость и мультиязычность контента - запилены в виде плагинов! Я в шоке был когда посмотрел, какие вещи там делаются просто как модуль расширения.

OctoberCMS
С одной стороны CMS
С другой laravel.
Тоесть вы не скатитесь к водпресу и подобным. И не будете терять квалификацию в фрэймворках, если вдруг надо будет сделать/прикрутить что-то не стандартное.

Я тоже хочу порекомендовать October CMS. Она на сегодня лучшая, построенная на компонентах Laravel. Но обманываться не стоит, разработка на October не то же самое. Но разрабатывая на October вы получите:

• отличный DX, нужно просто попробовать;
  
• CLI для автоматизации решения задач;
  
• самый популярный PHP-шаблонизатор Twig;
  
• действительно исчерпывающую документацию;
  
• возможность удобного совместеного использования с Laravel (кпример комплексного проекта - 2doc.by - October CMS, api.2doc.by - Lumen, medcrm.by - Laravel);
  
• аскетичность из коробки, следование философии Unix, что позволяет не быть изначально заточенной под конкретный тип проекта и не содержать в себе неиспользуемую проектом функциональность;
  
• отличный скафолдер для разработки кастомной функциональности под нужды проекта;
  
• непрерывно растущую базу плагинов с августа 2015 до мая 2017 росто составил 75% со 130 до 515;
  
• непрерывный рост интереса сообщества к платформе, выраженный в приросте звезд на гитхабе с 3000 в июне 2015 до 6950 в мае 2018;
  

Можно продолжать долго, если будет желание и необходимость. =) Из минусов можно отметить слабый рост количества готовых шаблонов, не такое большое количество дополнений в сравнении с динозаврами рынка CMS. Не минус, но важный момент, что на October вы будете именно программировать, это как порог входа для неквалифицированных разработчиков, так и дополнительные возможности для квалифицированных.

Что касается важной темы E-Commerce, есть несколько готовых дополнений разной степени качества и функциональных возможностей. Я порекомендую Shopaholic, т.к. имею непосредственное отношение к проекту и головой могу отвечать за его качество. Проект пока очень молодой, меньше полугода после релиза и тем не менее, отзывы наилучшие от сообщества (1, 2, 3, 4, 5, 6, 7 и т.д.). Вот неболшая статья в нашем блоге про Shopaholic.

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

Единственной в некоторой степени проблемой выбора не самой известной платформы может стать ее "продажа" клиентам. Но мы успешно с этим справлялись, работая 7 лет с MODX в мире, где правили Wordpress (весь мир) и Bitrix (СНГ). А последние 2,5 года также успешно справляемся с October в мире, где правят Wordpress и Bitrix и это еще теперь пытается делать MODX (СНГ).

Надеюсь, был полезен. =)

Может ваше решение в 2000е еще бы казалось бы нормальным, но сейчас есть и технологии и удобные библиотеки для этого. Попробуйте сделать такое на canvas, например, с помощью paper.js. Если хорошо поискать, наверняка есть хотя бы 50% решение такой задачи.

Посмотрите на SourceTree: разделение на проекты, ветки под фичи и баги да и вообще удобный и приятный в использовании GUI для Git. И почитайте про git flow

Обязательно.
1. Вы тем самым проявляете интерес к проекту, и получаете фидбек спустя время.
2. Вы пингуете клиента, и теперь он помнит о вас еще какое-то время.
3. Да и вообще можете поговорить по душам, а там может еще работенка подвалит от него, т.к. ваша беседа может открыть для него новые потребности в вас.

Правда ли, что новый Mercedes-AMG GT ездит в 8 раз быстрее Камаза?
Конечно правда. По асфальту в легкую.
Ну конечно если асфальт хороший, а не гравийка ухабистая.
К тому же злые языки утверждают что Mercedes-AMG GT вообще не ездит. Реально пробовали - насыпали в салон 20тонн гравия, а он собака ехать не хочет.

Если к серверу есть доступ через SSH (а у большинства хостеров он есть), то не нужны никакие посредники.
Ставите гит и он прекрасно живёт внутри домашней папки даже.
То есть рутовые права не нужны чтобы гит поставить.
Ну а репозиторий гита - это тоже просто папка.
В принципе, наверное можно поискать и возможно есть способы организовать доступ к репозиторию и через фтп.
Кстати, как вариант, вы можете примапить ФТП как сетевой диск к локальной машине.
Тогда на удаленной машине даже гит ставить не надо, все можно делать на локальной машине.
Во всяком случае, в линуксе это делается без проблем.

А самое главное - совсем недавно расписали как работать с flexbox без самих flexbox: Хабр

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

В итоге, ответ на вопрос очень простой - flex нужно использовать там, где он дает конкретные преимущества. Самое очевидное - нужно автораспределение ширины блоков с подстройкой к ширине контента. Или вам нужно менять порядок блоков (свойство order).
Если ничего этого не планируется - flex не нужен! Сейчас уже наплодили сеток и "фреймворков", где flex используется фактически для имитации float-ов! Ну типа же стильно, модно, молодежно. Я ж крутой разработчег, не хухры-мухры.

При верстке каждого блока нужно задавать себе вопрос: "я использую flexbox, чтобы что?" Если на вопрос есть четкий ответ - да, нужно использовать. Если только бла-бла типа "ну это современно, прогрессивно и пр" - использовать старые железобетонные приёмы.

Jade

Купил на skladchik годную книжку - ng-book 2 -- The in-depth, complete, and up-to-date book on Angular 2
+ на торрентах the-complete-guide-to-angular-2 от Udemy

На ютубе есть канал megamind по Angular 2. Уроки 2016 года.