Почему я против CMS (Content Management System)
Прально, в принципе. Плюс к тому - чтоб скофигурить даже ту CMS, которая тебе подходит лучше всех, надо прилично попотеть и перечитать кучу документации.
Почему бы не уточнить, что это вообще за CMS? Content Management System, что ли?
ну да
Ты путаешь понятия.
По твоему порочна идея продавать CMS'ки в коробке.
Сайт с динамической структурой данных не может быть написан без CMS, пусть даже эту CMS пишут конкретно под него.
По твоему порочна идея продавать CMS'ки в коробке.
Сайт с динамической структурой данных не может быть написан без CMS, пусть даже эту CMS пишут конкретно под него.
Нет, я именно не путаю понятия.
Против "коробок" я, разумеется, по умолчанию.
Да тут и даже против не надо быть -- самый лучший пример коробки -- народ.ру.
CMS в принципе не нужна. Никогда. Никому. Нигде. Нужен сайт с авторизацией -- это пишется быстро, гораздо быстрее, чем, например, настраивать и подбирать существующую CMS. А если и авторизации не надо -- тут еще проще.
Да, другое дело, что нужны такие вещи как ротация новостей. Но и тут: вот шаблон, вот БД с новостями, вот скрипт, который делает статику раз в 10 минут. Прописали SSI в html-коде, или в скриптовом "ответе" подкачали. Готовые шаблоны с ротацией -- это дешево, быстро и красиво. Зачем, спрашивается, при КАЖДОМ ответе сервера лезть в базу?
Против "коробок" я, разумеется, по умолчанию.
Да тут и даже против не надо быть -- самый лучший пример коробки -- народ.ру.CMS в принципе не нужна. Никогда. Никому. Нигде. Нужен сайт с авторизацией -- это пишется быстро, гораздо быстрее, чем, например, настраивать и подбирать существующую CMS. А если и авторизации не надо -- тут еще проще.
Да, другое дело, что нужны такие вещи как ротация новостей. Но и тут: вот шаблон, вот БД с новостями, вот скрипт, который делает статику раз в 10 минут. Прописали SSI в html-коде, или в скриптовом "ответе" подкачали. Готовые шаблоны с ротацией -- это дешево, быстро и красиво. Зачем, спрашивается, при КАЖДОМ ответе сервера лезть в базу?
Затем, что инфу о 70 страницах лучше хранить в базе, а не в 70ти однотипных файлах.
База данных очень неэффективна для хранения подобной информации. Особенно, если это текст или графика. Однотипные файлы очень хорошо хранятся, легко изменяются и копируются.
Фактически, БД -- это файловая система поверх файловой системы, и для хранения больших блоков крайне неэффетивна. Наша же цель -- сделать так, чтобы сайт грузился быстро у большого числа пользователей, плюс к этому был динамичный и легко настраиваемый. Поэтому решение, делающее много запросов -- говнорешение, ибо оно ТОЧНО упрется в производительность БД уж если ни при 10 пользователях, так при 100.
Место для БД -- это маленькие записи, типа информации о пользователях. Никому же не приходит в голову хранить фотографии в БД или текстовые документы.
В большинстве проектов БД вообще не нужна, максимум одна таблица на весь сайт. Самые сложные сайты типа интернет-магазинов могут хранить такую информацию в базе, но отдавать контент нужно кэшируя все равно, и никакой CMS тут не поможет.
Фактически, БД -- это файловая система поверх файловой системы, и для хранения больших блоков крайне неэффетивна. Наша же цель -- сделать так, чтобы сайт грузился быстро у большого числа пользователей, плюс к этому был динамичный и легко настраиваемый. Поэтому решение, делающее много запросов -- говнорешение, ибо оно ТОЧНО упрется в производительность БД уж если ни при 10 пользователях, так при 100.
Место для БД -- это маленькие записи, типа информации о пользователях. Никому же не приходит в голову хранить фотографии в БД или текстовые документы.
В большинстве проектов БД вообще не нужна, максимум одна таблица на весь сайт. Самые сложные сайты типа интернет-магазинов могут хранить такую информацию в базе, но отдавать контент нужно кэшируя все равно, и никакой CMS тут не поможет.
Т.е. ты не против CMS как таковой, а против использования в ней баз данных, против ее коробочного варианта и т.д. ?
CMS в принципе не нужна. Никогда. Никому. Нигде.А кто будет вносить изменения? Девочка-секретарша. И как он а по твоему должна это делать без CMS?
Кешировать разумеется нужно. Этого никто не отрицает. Вот только ты от критики CMS перешёл к критике баз данных. Ты уж определись.
И, кстати, запросы к базе данных тоже можно кэшировать.
И, кстати, запросы к базе данных тоже можно кэшировать.
А я понял... дохера всякого Г среди CMS потому, то точно никто не в курсе, что она должна делать и как..
Ибо нет общего технического задания...
Это вопервых..
А во вторых - это потому, что СMS по сути своей сейчас это просто замена того же FrontPage но токль на серваке и с настройкой под этот сайт... Созданная как раз для секретарш, которые не рубят в языке разметки, но могут что то набрать в ворде....
Ибо нет общего технического задания...
Это вопервых..
А во вторых - это потому, что СMS по сути своей сейчас это просто замена того же FrontPage но токль на серваке и с настройкой под этот сайт... Созданная как раз для секретарш, которые не рубят в языке разметки, но могут что то набрать в ворде....
Попытаюсь внятно объяснить против чего я выступаю и что предлагаю взамен.
Против того, что морда сайта генерируется "с нуля", начиная от "названия фирмы пишем в title", "читаем меню из одной таблицы БД", "делаем запрос картинок меню из еще одной таблицы" и пр.
Да, секретарша должна быстро вносить новости. Как? Очень просто, заполнила форму, проверила, отправила. Форма в базу (нахуя? можно просто в файлик с именем news.afftar.timestamp а фоновый скрипт через 5 минут обновляет морду сайта и слоты для других страниц. Изменять меню сайта приходится раз в пятилетку, и точно копипаст html-кода займет времени меньше, чем создание мега-гиппер-универсальной системы меню. Главное, все будет работать БЫСТРО. Это все писать и править быстрее, чем мега-системы!
Это не надо делать "универсально" и коробочно, но никто не запрещает делать "заготовки". И лучшее доказательство тому -- огромный вобор CMS, ибо никому не удалось сделать что-то универсальное, но никто не подумал, а возможно ли оно?
Против того, что морда сайта генерируется "с нуля", начиная от "названия фирмы пишем в title", "читаем меню из одной таблицы БД", "делаем запрос картинок меню из еще одной таблицы" и пр.
Да, секретарша должна быстро вносить новости. Как? Очень просто, заполнила форму, проверила, отправила. Форма в базу (нахуя? можно просто в файлик с именем news.afftar.timestamp а фоновый скрипт через 5 минут обновляет морду сайта и слоты для других страниц. Изменять меню сайта приходится раз в пятилетку, и точно копипаст html-кода займет времени меньше, чем создание мега-гиппер-универсальной системы меню. Главное, все будет работать БЫСТРО. Это все писать и править быстрее, чем мега-системы!
Это не надо делать "универсально" и коробочно, но никто не запрещает делать "заготовки". И лучшее доказательство тому -- огромный вобор CMS, ибо никому не удалось сделать что-то универсальное, но никто не подумал, а возможно ли оно?
Писать CMS под себя - как раз абсолютно нормальное явление. Хуже, когда пытаются купить что-нибудь готовое. Тут как раз такой случай, когда нужно изобретать велосипед.
У тебя странное представление о том, что и с какой частотой изменяется на сайте. На сайте-визитке, наверное, всё именно так, как ты описал. На большом сайте — фиг.
Форма в базу (нахуя? можно просто в файлик с именем news.afftar.timestamp а фоновый скрипт через 5 минут обновляет морду сайта и слоты для других страниц.т.е. вместо того, что бы один раз при изменении залить в базу новость а потом брать ее оттуда, ты предлагаешь раз в N минут проверть наличие изменений в файле и при их нахождении - переписывать морду сайта и еще пару страниц с новостями?
т.е. раз в N минут у тебя должен срабатывать парсер (строковые функции работают дольше запроса в базу в данном случае грамотно парсящий от 0 до K новостей из файла в морду, а все остальные страницы с новостями - оккуратно перезаписывающий, и это что бы не сглючила файловая система новостного раздела (проблема с повтором имен и потерей новостей) и что бы небыло глюков с доступом при перезаписи ?
ИМХО - это будет дольше, чем хранить новости в базе и делать из нее архив раз в месяц или в неделю...
Назови мне пример большого сайта.
sotovik.ru
kdo.ru
gazeta.ru
etc...
kdo.ru
gazeta.ru
etc...
Нет, я чуть-чуть неяно объяснил.
Вот новости (неважно, в базе или нет мы из них раз в пять минут делаем что-то типа news.inc. Далее просто линкуем этот файл на фсех страницах. Дешево, быстро и качественно, половину страниц можно сделать статиком. Более того, морду генерируют многие, index.html, и все летает. А есть дибилы, которые запросы виды "SELECT ... ORDER BY ..." вставляют на тех страницах, которые всем одинаковыми выдаются.
Насчет CMS "под себя". Да, ты прав, но писать надо не CMS, а сайт. Так быстрее.
Вот новости (неважно, в базе или нет мы из них раз в пять минут делаем что-то типа news.inc. Далее просто линкуем этот файл на фсех страницах. Дешево, быстро и качественно, половину страниц можно сделать статиком. Более того, морду генерируют многие, index.html, и все летает. А есть дибилы, которые запросы виды "SELECT ... ORDER BY ..." вставляют на тех страницах, которые всем одинаковыми выдаются.
Насчет CMS "под себя". Да, ты прав, но писать надо не CMS, а сайт. Так быстрее.
писать надо не CMS, а сайт. Так быстрее.
-- Печатать умеете?
-- Да.
-- Сколько знаков в минуту?
-- 2000
-- Хм. Очень быстро!
-- Да, только такааая хуйня получается...
т.е. ты предлагаешь вместо реалтайма делать кеширование сайта с частотой в N минут и его отдавать пользователям?
это если отвлечься от новостей и применить твою мысль к каталогу продукции, статьям и другим разделам?
Такой вариант хорош для визитки...
Обоснование:
Для примера возьмем сайт rures.ru.
В свое время я его писал именно по такому принципу, т. е. поcле обновления базы (ручками из excel) сайт переписывался заново. примерно 10000 позиций - 10000 страниц в 250 разделах.. Итого получили 5 минут - генерация сайта заново.
т.е. 5 минут сайт просто валялся.
А вторая часть (тот же сайт, другой раздел, сейчас отключен) - 40000 записей была сделана на основе 3 таблиц со связями один ко многим. проблем с редактирвоанием никаких, заливка базы - 25 секунд.
Скорость отдачи страниц в обоих случаях - одинакова, но гемора в первом - гораздо больше....
Вывод - кеширование в такого рода проектах - нах не нужно...
это если отвлечься от новостей и применить твою мысль к каталогу продукции, статьям и другим разделам?
Такой вариант хорош для визитки...
Обоснование:
Для примера возьмем сайт rures.ru.
В свое время я его писал именно по такому принципу, т. е. поcле обновления базы (ручками из excel) сайт переписывался заново. примерно 10000 позиций - 10000 страниц в 250 разделах.. Итого получили 5 минут - генерация сайта заново.
т.е. 5 минут сайт просто валялся.
А вторая часть (тот же сайт, другой раздел, сейчас отключен) - 40000 записей была сделана на основе 3 таблиц со связями один ко многим. проблем с редактирвоанием никаких, заливка базы - 25 секунд.
Скорость отдачи страниц в обоих случаях - одинакова, но гемора в первом - гораздо больше....
Вывод - кеширование в такого рода проектах - нах не нужно...
Специально сделаю анализ морд перечисленных сайтов. :-)
sotovik.ru:
Шапка: статика в чистом виде, один лишь баннер, и тот или внешний, или слотом можно показывать, на худой конец -- ифрэйм.
Левое меню: чистая статика, меняется дай Бог раз в месяц. Верстальщику -- право записи файла leftmenu.html, все равно универсальности хрен добьешься, а добьешься, так ему тэг понадобится какой-нить, на худой конец картинку "NEW!" повесить...
Серединка: новости вперемешку с рекламой. Вот база с новостями, вот скрипт. Все как я сказал, + шаблоны с местом для вставки рекламных слотов. + пара кроновских скриптов для херни типа "в форуме что творится" (раз в минуту -- более чем достаточно)
Резюме: CMS так все только тормозит, кладет сервер, небось, некисло... это я по тому как он грузится говорю: медленный. Создатель сайта -- некий "Аист" -- на первый взгяд дерьмом не назовешь, вроде как ИХ сайт выглядит получше написанным.
kdo.ru:
то же самое. Добавлю, что 1-2 sql-запроса на страницу там более чем, а это и будет летать всегда.
gazeta.ru:
какой ты там cms нашел? там нормально все вроде бы. Кстати, новости они в файлах они хранят или нет, интересно? Суда по ссылкам -- да (пример -- "постоянный адрес такой-то"). Рекламу используя ssi вставляют. Да и летать это будет всегда...
sotovik.ru:
Шапка: статика в чистом виде, один лишь баннер, и тот или внешний, или слотом можно показывать, на худой конец -- ифрэйм.
Левое меню: чистая статика, меняется дай Бог раз в месяц. Верстальщику -- право записи файла leftmenu.html, все равно универсальности хрен добьешься, а добьешься, так ему тэг понадобится какой-нить, на худой конец картинку "NEW!" повесить...
Серединка: новости вперемешку с рекламой. Вот база с новостями, вот скрипт. Все как я сказал, + шаблоны с местом для вставки рекламных слотов. + пара кроновских скриптов для херни типа "в форуме что творится" (раз в минуту -- более чем достаточно)
Резюме: CMS так все только тормозит, кладет сервер, небось, некисло... это я по тому как он грузится говорю: медленный. Создатель сайта -- некий "Аист" -- на первый взгяд дерьмом не назовешь, вроде как ИХ сайт выглядит получше написанным.
kdo.ru:
то же самое. Добавлю, что 1-2 sql-запроса на страницу там более чем, а это и будет летать всегда.
gazeta.ru:
какой ты там cms нашел? там нормально все вроде бы. Кстати, новости они в файлах они хранят или нет, интересно? Суда по ссылкам -- да (пример -- "постоянный адрес такой-то"). Рекламу используя ssi вставляют. Да и летать это будет всегда...
я не смог зайти на rurse.ru посмотреть. Если увижу -- предложу нормальное решение за 1 минуту.
Кстати, нахуя закрывать сайт на 5 минут? просто переделывай страницы себе и все, на лету, во время работы.
Кстати, нахуя закрывать сайт на 5 минут? просто переделывай страницы себе и все, на лету, во время работы.
gazeta.ru:уж точно не ручками новости дописывают....
какой ты там cms нашел?
www.rures.ru - опечатался...
а он и не закрывается, просто трется весь каталог, а потом заново выстраивается файловая система.. и ее выстройка занимает 5 минут.
а он и не закрывается, просто трется весь каталог, а потом заново выстраивается файловая система.. и ее выстройка занимает 5 минут.
Суда по ссылкам -- даВ век mod_rewrite по ссылкам судить нельзя.
Судя по коду одной новости, она явно обрабатывалась скриптом. Ни один человек в здравом уме не будет вставлять после каждого параграфа картинку.
по поводу газеты: там не cms ы обычном понимании этого слова, Это сайт новостей, и из него нельзя сделать мегапортал, и вообще там узкоспециализировано. И сделан он хорошо, думаю, и добротно. И уж точно он не плодит sql-запросы по поводу и без.
Ты опять скатываешся к базам данных.
на сайт так и не попал. Видать так пиздато написан 
нахуя им mod_rewrite здесь? По-моему они прекрасно хранят архив новостей на диске так, чтобы отдавать максимально быстро. Чем такое решение тебе не нравится? Быстро и дешево.
нахуя им mod_rewrite здесь? По-моему они прекрасно хранят архив новостей на диске так, чтобы отдавать максимально быстро. Чем такое решение тебе не нравится? Быстро и дешево.
> Далее просто линкуем этот файл на фсех страницах. Дешево, быстро и качественно, половину страниц можно сделать статиком.
Это будет работать только для сайтов-визиток.
У всех остальных сайтов почти всегда есть подстройка под пользователя.
Это будет работать только для сайтов-визиток.
У всех остальных сайтов почти всегда есть подстройка под пользователя.
Потому, что БД -- это беда! Ужасно, когда 30 таблиц, сотни запросов и мегапортал самой крупной мегакомпании на 130 месте по их ебаному рейтингу крутости и на 145 в рейтинге дружественного сайта Пупкина с сотрей уникалов в день!
Для начала надо это зло убить, может други подтянутся?
Для начала надо это зло убить, может други подтянутся?
Да никто не мешает подстраиваться под пользователя! Не надо для этого делать kernel.php и utils.php, drivers.php, sql.php и прочую муть на мегабайт объектноориентированной хуйни. Класс конструктора форм так, таблиц, и пр.
Сделать можно просто, лаконично, и используя 1-2 запроса. Максимум.
Сделать можно просто, лаконично, и используя 1-2 запроса. Максимум.
: на сайт так и не попал. Видать так пиздато написанВидать пиздонулся он еще пол-года назад (последний раз там был т.к. бизнес нагнулс, но не в этом дело...
Я к примеру привел, сколько времени нудно для одного и сколько для другого..
Если есть желание - приходи, отрою исходники, и на локале все посмотрим....
Но суть остается - SSI - не панацея... И без баз хрен что сделаешь серьезное...
ЗЫ А то, то ты в файлах предлагаешь хранить - так есть такая фича в php - файловый базы... по скорости - ровно то, что и инклюд из файла (при выборке и обработке т.к. работают по тем же строковым функциям, только встроенным и заточеным под интерфейст работы с базой...
Сделать можно просто, лаконично, и используя 1-2 запроса. Максимум.пример - eurogroupp.ru
там всего то 6 страниц с php и html вперемешку...
Но ты даже не представляешь, как много надо ебаться, что бы сделать шрифт и цвет для заголовка в данном разделе другими... (проще заново переверстать)
Вывод, не только краткость - сестра таланта, еще надо и с головой дружить...
Открою тебе страшную тайну:
писать код, который делает 50 запросов к базе на одну страницу проще и дешевле, чем код, который делает 1-2 запроса.
То же самое и с CMS - да, с CMS страшнее, чем без нее - зато с CMS проект стоит дешевле.
писать код, который делает 50 запросов к базе на одну страницу проще и дешевле, чем код, который делает 1-2 запроса.
То же самое и с CMS - да, с CMS страшнее, чем без нее - зато с CMS проект стоит дешевле.
Ну я не утверждал, что SSI -- это наше все. Я лишь сказал, что МНОГОЕ, ОЧЕНЬ МНОГОЕ можно туда.
Останется действительно мало, и это легко программируется руками. Программируется быстро, без объектных замуток, на простых запросах к SQL-серверу, без мутных inner join и пр.
Останется действительно мало, и это легко программируется руками. Программируется быстро, без объектных замуток, на простых запросах к SQL-серверу, без мутных inner join и пр.
> тормозит всегда и везде. Правильно, если меню сайта грузить из БД, если поле title грузится из файла концига, то никогда это не будет работать
Посчитай - сколько выходит зарплата программиста, который умеет писать страницы с 1-2 запросами к базе, и сколько стоит поставить дополнительный комп с внешней базой.
Посчитай - сколько выходит зарплата программиста, который умеет писать страницы с 1-2 запросами к базе, и сколько стоит поставить дополнительный комп с внешней базой.
ну приведи что ли пример того, как ты это видешь...
и пример кода реализации своих взглядов....
пока я не вижу смысла отказываться от БД в пользу файлов инклюдов и SSI
и пример кода реализации своих взглядов....
пока я не вижу смысла отказываться от БД в пользу файлов инклюдов и SSI
шаблончики должны быть, шаблонцики 
а я разве говорю, что нет ?
Я говорю, что да..
И что менять инфу в шаблонах надо с наименьшими трудо и времязатратами...
В идеале - просто интерфейс к базе....
Я говорю, что да..
И что менять инфу в шаблонах надо с наименьшими трудо и времязатратами...
В идеале - просто интерфейс к базе....
Против того, что морда сайта генерируется "с нуля", начиная от "названия фирмыЭто называется халтурно написаная CMS или коробочный CMS.
пишем в title", "читаем меню из одной таблицы БД", "делаем запрос картинок меню из еще
одной таблицы" и пр.
Да, секретарша должна быстро вносить новости. Как? Очень просто, заполнила форму,Все это херня полная. CMS нужен, например, для нормальной работы веб-мастера, который сайт раскручивает. Прописывать кучу метатэгов, которые должны быть напрямую связаны с контентом страницы - вот тут ты с файловой системой хранения контента загнешся оч. быстро.
проверила, отправила. Форма в базу (нахуя? можно просто в файлик с именем
news.afftar.timestamp а фоновый скрипт через 5 минут обновляет морду сайта и слоты для
других страниц. Изменять меню сайта приходится раз в пятилетку, и точно копипаст html-кода
займет времени меньше, чем создание мега-гиппер-универсальной системы меню. Главное,
все будет работать БЫСТРО. Это все писать и править быстрее, чем мега-системы!
Вообще, бывают такие замуты, как ротация контента в блоке, связи между страницами и инф. на странице, поиск по сайту и т.д. и т.п. В общем, твои наезды на CMS мне непонятны совершенно.
Это не надо делать "универсально" и коробочно, но никто не запрещаетА ты не задумывался о том, что сделать что-то универсальное никто и не пытается? Люди делают CMS по некий круг задач, чтобы упростить разработку и поддержку продукта.
делать "заготовки". И лучшее доказательство тому -- огромный вобор CMS, ибо никому не
удалось сделать что-то универсальное, но никто не подумал, а возможно ли оно?
писать код, который делает 50 запросов к базе на одну страницу проще и дешевле, чем код, который делает 1-2 запроса.Я работал в компании, которая рассуждала именно так. У них было 12 фронтендов на самых современных компах и 24 бэкенда. In the busiest hour на сайт было залогинено 300 клиентов, и трафик был 1 мегабит. Если бы клиентов стало тысяча, то они купили бы еще две стойки и 50 компьютеров. Если бы их было 10 000, то ..... А их не было бы 10 000, потому что на всём земном шаре не наберётся столько клиентов. Слишком специфичный продукт. Поэтому такой подход для них приемлем и они наверное в выигрыше. Процессоры дешевле, чем мозги.
Теперь я в другой тарелке. In the busiest hour у нас 35 000 клиентов и из них 2 - 3 тысячи появляются в секунду и исчезают. Трафик 400 мегабит. 2 (два) фронтенда. Если бы здесь применялся вышеописанный подход, то нам негде было бы ставить стойки с компьютерами.
Кстати, насколько я знаю, хостеры поощряют говнопроекты -- они тогда больше железа продают. А то так бы взяли бы все проекты и на одной такче вместо 20 запустили бы и продали мало
Речь ведь не о том, речь о том, как сделать по-человечески
Речь ведь не о том, речь о том, как сделать по-человечески
Разве хостеры продают железо?
Имелось в виду: больше ставят железа в стойки, и соотв. берут деньги. Фактически продают железо на поюз...
> больше ставят железа в стойки, и соотв. берут деньги. Фактически продают железо на поюз...
когда услуга редкая и дорогая, такое может быть оправдано
но когда распространённая и дешёвая, лучше по максимуму использовать имеющиеся ресурсы
когда услуга редкая и дорогая, такое может быть оправдано
но когда распространённая и дешёвая, лучше по максимуму использовать имеющиеся ресурсы
> Если бы здесь применялся вышеописанный подход, то нам негде было бы ставить стойки с компьютерами.
Еще раз повторю основную мысль - если за счет железа можно решить проблему, то проблему стоит решить с помощью железа.
Если проблема не решается с помощью железа, то тогда стоит думать о низкоуровневой(кусочной) оптимизации.
Да, для разных проектов - понятие "проблему можно решить с помощью железа" очень и очень различное: взависимости от уникальности проекта, взависимости от класса потенциальных клиентов, взависимости от конкурентных решений и т.д.
Причем это именно касается кусочной оптимизации - оптимизации во вред стройности и гибкости общей архитектуры.
Оптимизировать архитектуру нужно и выгодно - т.к. такие оптимизации дают сильный долговременный выигрыш.
Еще раз повторю основную мысль - если за счет железа можно решить проблему, то проблему стоит решить с помощью железа.
Если проблема не решается с помощью железа, то тогда стоит думать о низкоуровневой(кусочной) оптимизации.
Да, для разных проектов - понятие "проблему можно решить с помощью железа" очень и очень различное: взависимости от уникальности проекта, взависимости от класса потенциальных клиентов, взависимости от конкурентных решений и т.д.
Причем это именно касается кусочной оптимизации - оптимизации во вред стройности и гибкости общей архитектуры.
Оптимизировать архитектуру нужно и выгодно - т.к. такие оптимизации дают сильный долговременный выигрыш.
А вдруг проект начнёт расти как на дрожжах, быстрее чем предсказывали аналитики и вдруг упрётся в производительность программно-аппаратного решения. Не в финансовые трудности, не в бюрократию, не в отсутствие спроса, а вот так банально - не сможет качественно обслуживать всех желающих.
Это будет переход этого проекта из общедоступного в элитный и дефицитный не из-за его качеств, а из-за недостатка мощьностей..
Но грамотный маркетинг и из этого сделает минимум - удвоение прибыли...
А т.к. проект коммерческий - то другого и не надо)
Но грамотный маркетинг и из этого сделает минимум - удвоение прибыли...
А т.к. проект коммерческий - то другого и не надо
)Когда я начал читать тред - был согласен с идеей "коробочная CMS - фигня".
Но автор пошёл в направлении "БД - фигня" и вот тут я с ним согласиться никак не могу.
Про удобство БД, коротко и ясно - любая книга по БД, глава про отличия БД от файловой системы. Это раз.
При обработке больших объёмов данных сайта БД работает на порядок быстрее (текстовый поиск, например. Ведь не редкость сейчас?). Это два.
При работе с файлОм есть вероятность очень быстро заипацца, т.к. работа с кодом даже для опытного человека - вещь не особо приятная. Это три.
И среди CMS, если разобраться, есть свои лидеры. Навскидку: PHPNuke, Drupal, Exponent - масса сайтов на них работает, используя стандартные модули. Если не нужно чего-то специфичного - их вполне хватит.
Давайте попробуем взглянуть на проблему под другим углом. Те примеры софтлидеров, которые привёл автор в первом посте, используются на порядок большим числом пользователей. Это говорит о том, что в них и баги отловлены почище, и юзабилити получше. Кроме того, компании, создававшие их, тратят очень серьёзные деньги на поддержку и продвижение этих продуктов. Назовите мне универсальную CMS, на создание которой были потрачены большие деньги одной конкретной, крупной, богатой компанией, да ещё чтобы и стоила не очень дорого? Я таких не знаю. Почему? Нет необходимости, вряд ли это себя окупит. Часто CMS пишется небольшой компанией (ай, ну даже если всем миром, как Drupal) - в общем-то под свои нужды. Серьёзный анализ того, что в ней должно быть и как бы пользователям хотелось, чтобы это было реализовано - не проводится. Я склонен считать это одной из главных проблем "коробочных" CMS.
Теперь другое соображение. "Коробочные" CMS при всём их заявленном удобстве - не являются столь уж интуитивно-понятными. Чем менее очевидна вещь - тем больше придётся читать документации, а если учесть, что таковой часто не имеется или она просто убога - тем [в квадрате] меньшее число народу будет в ней хорошо разбираться. И у тех, чьи потребности в CMS как таковой велики, но нет времени и возможности разбираться, что в ней к чему - мало шансов в нужные сроки сделать с её помощью такой сайт, как требуется. Подчёркиваю - при том, что возможностей CMS может хватать с лихвой.
Дальше даже можно и не углубляться. Уже этих причин хватает, чтобы универсальные CMS не были удобными, а удобные - универсальными.
Но автор пошёл в направлении "БД - фигня" и вот тут я с ним согласиться никак не могу.
Про удобство БД, коротко и ясно - любая книга по БД, глава про отличия БД от файловой системы. Это раз.
При обработке больших объёмов данных сайта БД работает на порядок быстрее (текстовый поиск, например. Ведь не редкость сейчас?). Это два.
При работе с файлОм есть вероятность очень быстро заипацца, т.к. работа с кодом даже для опытного человека - вещь не особо приятная. Это три.
И среди CMS, если разобраться, есть свои лидеры. Навскидку: PHPNuke, Drupal, Exponent - масса сайтов на них работает, используя стандартные модули. Если не нужно чего-то специфичного - их вполне хватит.
Давайте попробуем взглянуть на проблему под другим углом. Те примеры софтлидеров, которые привёл автор в первом посте, используются на порядок большим числом пользователей. Это говорит о том, что в них и баги отловлены почище, и юзабилити получше. Кроме того, компании, создававшие их, тратят очень серьёзные деньги на поддержку и продвижение этих продуктов. Назовите мне универсальную CMS, на создание которой были потрачены большие деньги одной конкретной, крупной, богатой компанией, да ещё чтобы и стоила не очень дорого? Я таких не знаю. Почему? Нет необходимости, вряд ли это себя окупит. Часто CMS пишется небольшой компанией (ай, ну даже если всем миром, как Drupal) - в общем-то под свои нужды. Серьёзный анализ того, что в ней должно быть и как бы пользователям хотелось, чтобы это было реализовано - не проводится. Я склонен считать это одной из главных проблем "коробочных" CMS.
Теперь другое соображение. "Коробочные" CMS при всём их заявленном удобстве - не являются столь уж интуитивно-понятными. Чем менее очевидна вещь - тем больше придётся читать документации, а если учесть, что таковой часто не имеется или она просто убога - тем [в квадрате] меньшее число народу будет в ней хорошо разбираться. И у тех, чьи потребности в CMS как таковой велики, но нет времени и возможности разбираться, что в ней к чему - мало шансов в нужные сроки сделать с её помощью такой сайт, как требуется. Подчёркиваю - при том, что возможностей CMS может хватать с лихвой.
Дальше даже можно и не углубляться. Уже этих причин хватает, чтобы универсальные CMS не были удобными, а удобные - универсальными.
> А вдруг проект начнёт расти как на дрожжах, быстрее чем предсказывали
> аналитики и вдруг упрётся в производительность программно-аппаратного
> решения.
Уволить аналитиков, нанять архитекторов и программеров - пусть всё перепишут правильно.
> аналитики и вдруг упрётся в производительность программно-аппаратного
> решения.
Уволить аналитиков, нанять архитекторов и программеров - пусть всё перепишут правильно.
Нет. Всё происходит не так. Проект набирает популярность и очень быстро переживает пик популярности, потому как упирается в мощности. На смену популярности, в общественном мнении сформировывается стереотип "xxxxx.ru - глючный", и потом стоит больших трудов этот стереотип развеять.
> вот так банально - не сможет качественно обслуживать всех желающих.
Вот здесь все упирается - у нас хорошая или плохая архитектура - можем ли мы легко и быстро внести нужные изменения (нужные оптимизации) или не можем, можем мы раскидать отдельные части по разработчикам - и сказать - "оптимизируй", или не можем.
Вот здесь все упирается - у нас хорошая или плохая архитектура - можем ли мы легко и быстро внести нужные изменения (нужные оптимизации) или не можем, можем мы раскидать отдельные части по разработчикам - и сказать - "оптимизируй", или не можем.
> сформировывается стереотип "xxxxx.ru - глючный", и потом стоит больших трудов этот стереотип развеять
Этот стереотип обычно не мешает завоевывать и удерживать рынок - возьми те же Microsoft, 1C, Rational и т.д.
Этот стереотип обычно не мешает завоевывать и удерживать рынок - возьми те же Microsoft, 1C, Rational и т.д.
> Вот здесь все упирается - у нас хорошая или плохая архитектура
Если шли по пути "быстрее и дешевле", как сказано выше, то архитектура получилась плохая.
Если шли по пути "быстрее и дешевле", как сказано выше, то архитектура получилась плохая.
Вот здесь все упирается - у нас хорошая или плохая архитектура - можем ли мы легко и быстро внести нужные изменения (нужные оптимизации) или не можем, можем мы раскидать отдельные части по разработчикам - и сказать - "оптимизируй", или не можем.Если за основу взята CMS, в которой кода на десятки мегабайт, а документации к позапрошлой версии - сотни страниц (а к последней версии ещё не написали то какой будет ответ?
а вот тут то как раз и прикол... пох сколько кода в CMS...
Основная ее фишка должна быть на в коде, а в виде хранения данных... т.е. в архитектуре....
И если данные хранятся в базе грамотно, то эту многометровую систему можно просто потереть и написать другую...
а если нет - то тогда уже нисем не поможешь...
Основная ее фишка должна быть на в коде, а в виде хранения данных... т.е. в архитектуре....
И если данные хранятся в базе грамотно, то эту многометровую систему можно просто потереть и написать другую...
а если нет - то тогда уже нисем не поможешь...
> документации к позапрошлой версии - сотни страниц (а к последней версии ещё не написали
Важнее - насколько из кода видно общую архитектуру, насколько отдельные части ортогональны к друг другу, насколько код часто "удивляет", насколько имена самоговорящие, насколько часто используются стандартные соглашения, паттерны и т.д.
Документация - это все-таки из разряда - если у вас ничего не получается, то прочтите, наконец, документацию.
Важнее - насколько из кода видно общую архитектуру, насколько отдельные части ортогональны к друг другу, насколько код часто "удивляет", насколько имена самоговорящие, насколько часто используются стандартные соглашения, паттерны и т.д.
Документация - это все-таки из разряда - если у вас ничего не получается, то прочтите, наконец, документацию.
Документация - это все-таки из разряда - если у вас ничего не получается, то прочтите, наконец, документацию.несогласен.
иногда используются функции и настройки, которое интуитивно не понятны... точнее, ты знаешь, что она есть, то делает, а как называется, или где найти - хз...
Вот для таких случаев и нужна документация...
Ну посмотри какую-нибудь популярную CMS и оцени сам.
Я ниасилил ни одну.
Я ниасилил ни одну.
> Если шли по пути "быстрее и дешевле", как сказано выше, то архитектура получилась плохая.
Смотря на чем экономили - на архитектуре, или на оптимизациях.
Если экономили за счет всяких оптимизаций в ущерб архитектуры - то проект спасать тяжело,
если экономили в пользу архитектуры в ущерб оптимизации - то проект спасает довольно легко.
Смотря на чем экономили - на архитектуре, или на оптимизациях.
Если экономили за счет всяких оптимизаций в ущерб архитектуры - то проект спасать тяжело,
если экономили в пользу архитектуры в ущерб оптимизации - то проект спасает довольно легко.
> функции и настройки, которое интуитивно не понятны
да, это не всегда получается, но стремиться к этому можно.
если у вас ничего не получается, то прочтите, наконец, документациют.е. изначально хочется, чтобы настройки и функции были понятны и без документации.
да, это не всегда получается, но стремиться к этому можно.
я сбегу в ужасе от трех вещей в инете, от ЦМС, от баннерокрутилок и топлистов и от раскрутки сайтов. Ибо более тупой работы я не знаю. А вообще, как на лента ру вроде сделано, должна быть прога с базой на одном компе, которая на другом компе из базы генертит статический html, тогда никаких проблем со скорость не будет, вроде как.
может и не будет, а может и будет... от подхода зависит... завалить можно на корню даже вывод одного поля из базы...
А можно в режиме реалтайм делать выборки как в google suggest и никаких тормозов, даже если одновременно несколько тысяч делают то же самое...
А можно в режиме реалтайм делать выборки как в google suggest и никаких тормозов, даже если одновременно несколько тысяч делают то же самое...
// Весь тред пока не прочитал, но решил написать несколько комментариев по поводу первого поста.
> Почему же так получилось, что в этой области нет лидеров?
Лидеры точно есть. Возможно, самому определить и оценить их сложнее, потому что успешность CMS в каждом конкретном случае определяется тем, что дало её внедрение компании. А получить такого рода информацию гораздо сложнее, чем опросить тысячу Вась Пупкиных: "Какой вы графический редактор используете?"
> Зачем, спрашивается, при КАЖДОМ ответе сервера лезть в базу?
Почитай про Bricolage. Это тебе как пример CMS, которая по НЕ использует базу для обслуживания пользователей.
> Большое количество как свободных, так и коммерческих CMS говорит о большой их популярности, большом спросе на такого рода системы, и, что самое главное, о провале всех этих проектов. Что это значит?
На мой взгляд, это значит ровно одно. Веб-программированием занимаются десятки или даже скорее сотни тысяч индусов, китайцев и прочих ребят. И каждый мыслящий человек, на мой взгляд, должен понимать: с миллионами китайцев и индусов по части аккуратности и работоспособности соревноваться безполезно.
Я думаю, что брать нужно чем-то другим - уникальностью, созданием монополии. Короче, моё скромное мнение - в 2005 году всерьёз планировать зарабатывать на жизнь веб-программированием - не разумно. Если, конечно, есть желание к 30 и 40 годам обеспечить себе чуть более высокий уровень жизни, чем в 20.
> Почему же так получилось, что в этой области нет лидеров?
Лидеры точно есть. Возможно, самому определить и оценить их сложнее, потому что успешность CMS в каждом конкретном случае определяется тем, что дало её внедрение компании. А получить такого рода информацию гораздо сложнее, чем опросить тысячу Вась Пупкиных: "Какой вы графический редактор используете?"
> Зачем, спрашивается, при КАЖДОМ ответе сервера лезть в базу?
Почитай про Bricolage. Это тебе как пример CMS, которая по НЕ использует базу для обслуживания пользователей.
> Большое количество как свободных, так и коммерческих CMS говорит о большой их популярности, большом спросе на такого рода системы, и, что самое главное, о провале всех этих проектов. Что это значит?
На мой взгляд, это значит ровно одно. Веб-программированием занимаются десятки или даже скорее сотни тысяч индусов, китайцев и прочих ребят. И каждый мыслящий человек, на мой взгляд, должен понимать: с миллионами китайцев и индусов по части аккуратности и работоспособности соревноваться безполезно.
Я думаю, что брать нужно чем-то другим - уникальностью, созданием монополии. Короче, моё скромное мнение - в 2005 году всерьёз планировать зарабатывать на жизнь веб-программированием - не разумно. Если, конечно, есть желание к 30 и 40 годам обеспечить себе чуть более высокий уровень жизни, чем в 20.
Видел коммерческую CMS. Весь контент, отдаваемый клиентам статичен и лежит в файлах. Вся информация при этоим лежит в базе. При добавлении новой статьи, или исправлении старой, происходит перегенерация статики из базы. Не всей статики, как это делают васи пупкины в своих "супер-CMS", а только затронутых страниц. Ничего не тормозит, естественно.
По слухам, примерно так же устроены CMS на новостных сайтах типа gazeta.ru
По слухам, примерно так же устроены CMS на новостных сайтах типа gazeta.ru
да, все круто... не спорю..
клавное - это правильно эти файлы размещать что бы конфликтов имен и доступа небыло и все будет ок...
правда при таком подходе тратится места больше под хостинг...
клавное - это правильно эти файлы размещать что бы конфликтов имен и доступа небыло и все будет ок...
правда при таком подходе тратится места больше под хостинг...
Оставить комментарий
Werdna
Решил высказаться, поделиться своими соображениями и мыслями.Большое количество как свободных, так и коммерческих CMS говорит о большой их популярности, большом спросе на такого рода системы, и, что самое главное, о провале всех этих проектов. Что это значит?
Посмотрим на рынок ОС: есть Windows, есть Mac, есть Linux и еще несколько свободных и коммерческих. Большинство использует именно эти системы, потому что каждая из них, в принципе, может удовлетворить потребности хотя бы на "троечку". Создавать что-то новое никто не решается, да и решившись, убеждаются, что его детище успеха иметь не будет.
Посмотрим на рынок Графических редакторов. Есть Photoshop, Corel. Есть бесплатные "заменители", есть еще несколько программ. Это говорит о том, что потребности в рисовании, в принципе, этим небольшим набором удовлетворяются.
Посмотрим на рынок http-серверов. Есть Apache, IIS и ряд менее распространенных. Большинство использует именно их. Потому что их хватает, они все умеют, что надо, по ним много документации и пр. Кому что-то не надо, есть еще выбор, но он не так уж огромен, а если нужно что-то специальное -- легче написать самому.
Посмотрим на многообразие скриптовых языков: perl, php, asp .net... десятка самых распространенных покроет 99%. Посмотрим на обилие движков форумов типа нашего ГЗшного -- их не так много, есть пятерка самых-самых, и именно их ставят. Других не надо.
Теперь обратим внимание на количество разрабатываемых CMS: чуть ли не каждая кантора плодит свою, уникальную. И пусть она такая же уёбищная, как и сотня других, но на ней делают и собираются продолжать делать сайты. Почему же так получилось, что в этой области нет лидеров?
На мой взгляд, ответ прост: сама идея CMS порочна. Невозможно создать универсальную систему, да и не нужно. Создание более-менее среднего сайта никогда не обходилось без переписывания движка CMS: то это нельзя сделать, то другое. В итоге, создание сайта ВСЕГДА сопровождается переделкой движка, и, как следствие, работы меньше не становится. Да и по функциональности созданные сайты обычно перенасыщены и перегружены.
Более-менее простые сайты делать легче без CMS, на чистом html или php. Зачем сайт-визитку компании вешать на супер-мега-систему, если можно за час написать несчастную гостевую, а если вы это делаете второй раз, то быстро прикрутить старый код?
Еще стоит обратить внимание на движки "интернет-магазинов": ни один из них никогда работать нормально не работал и не будет, тем не менее, их еще и прикручивают к существующим CMS. Получается эдакий неповоротливый уродец, который перенасыщен ненужной функциональностью и не умеет делать то, что должен -- быстро и надежно работать. Как пример приведу работу знакомого -- simba.ru, сайт создан как модуль Апача, работает быстро под большой нагрузкой, нагрузка сервера -- 2 процента.
Плюс ко всему ни одна CMS никогда не работала хотя бы просто сносно -- тормозит всегда и везде. Правильно, если меню сайта грузить из БД, если поле title грузится из файла концига, то никогда это не будет работать. Знамая админша в хостинге жаловалась: захостились какие-то свежие уроды и положили сервер, причина -- по 50 sql запросов на отдачу ОДНОЙ страницы. Как итог -- дальше морды никто не попал из посетителей. Хотя в тестовом режиме, когда один дурачок тыкал по менюшкам, а другой любовался -- все работало идеально.
Итак, мы приходим к выводу, что место CMS -- на помойке. У кого есть возражения и мысли?