Наш проект уже почти год использует систему управления содержанием
S.Builder 3.7+. Не могу сказать, что S.Builder совсем неизвестная система на российском рынке, но среди разработчиков она менее популярна, чем, скажем «Битрикс», «Joomla», «Drupal» или «Wordpress». В статье я расскажу, чем приглянулась нам эта коммерческая CMS. Но для начала...
Почему мы не стали делать сайт на своем движке
Как и у всех разработчиков, у меня есть «свой» движок, написанный с соавторстве с моим коллегой. Движок достаточно простой, рассчитанный на малые и средние сайты, работать с ним легко, он содержит в себе пару неплохих концепций…, но мы не стали делать на нем наш сайт.
Потому, что как и у каждого «движка», у него есть проблема с восприятием его другими пользователями.
Под «движком» я понимаю систему для публикации динамических страниц без особых заморочек с интерфейсом администрирования. «Заплатки» и «феньки»на который, обычно разрабатываются по ходу очередного проекта. В результате получается очень гибкая, но не очень дружественная система, похожая на framework.
Т.е. делая сайт на своем движке, вам придется обновлять его самому — всегда. Дело не столько в наличии инструментов администрирования как таковых, а в их «дружественности» рядовому пользователю. Ведь с обучением персонала заказчика и написанием толкового руководства пользователя проблемы даже у больших компаний. Что же говорить, если разработчик — и программист, и дизайнер, и юзабилити-эксперт?
Другими словами. Все изменения сторонних специалистов будут идти через вас. Например, вы наняли корректора для правки текстового наполнения сайта. У корректора есть фиксированная цена на определенное количество скорректированного текста. (При этом предполагается, что редактировать текст будет УДОБНО, в противном случае цена может или сильно подняться, или вам придется искать нового корректора.) Разбираться с «сырой» системой, обладающей примитивными возможностями по корректуре текста, никто не станет. Вас попросят прислать тексты в формате Word, и в нем же отдадут. Закончится тем, что вставлять и форматировать текст в сайт будете Вы сами. А теперь добавим сюда сторонних авторов и прочие радости жизни — и вот у нас уже самоорганизовался небольшой персональный рабочий Ад! Ваши фрилансеры делают работу и получают деньги, а вы лишаетесь денег и получаете еще один пункт в список срочных дел.
Сказанное выше — прописные истинны, но их довольно трудно заметить, если ты разрабатываешь сайт, а не используешь его. Если при создании ресурса для разработчиков основными критериями в выборе CMS являются: знакомство с решением, простота изменения шаблонов, возможности конфигурирования готовых модулей, возможность интеграции своих разработок в тело системы (ну или хотя бы организация совместного существования своих разработок и CMS), — то для хозяина и пользователя на первый план выходят совсем другие задачи: возможность работы с CMS простым смертным, наличие технической поддержки (для простых смертных, которым надо немного подкорректировать сайт), возможности и стоимость расширения функциональности.
Поэтому очевидно, что для экономически эффективного сайта понятность системы получается гораздо важнее ее «крутизны».
Хотя современные разработчики все больше ориентируются на сетевые источники информации, мне кажется, у книг посвященных программированию все же есть своя ниша. Статьи представляют решение конкретных задач, описание конкретных моментов. Книги – это более общий взгляд на технологии, обзор лучших практик, полный охват технологического процесса. В общем, книги — это набор статей, посвященных одной большой теме, и дополняющих одна другую. 
