Комментарии 79
автору спасибо за работу. жду продоления.
Достаточно объективно все написано. Спасибо!
спасибо за отзывы! Рад, что понравилось, завтра, в крайнем случае - в понедельник будет продолжение.
О Друпале в контексте изложеного:
действительно, большую часть популярного функционала можно реализовать используя готовые модули как "кубики". Пичем, необходимого схожего результата можно добиться используя различные наборы кубиков-модулей, что есть достоинством и, в некоторой степени, недостаком. Таких дополнительных (contributed ) модулей у Друпала свыше 500, около трети из них активно дорабатывается и содержат несколько версий (dev и stable для разных версий ядра). У модулей появляется и изменяется API для интеграции с другими модулями. Нетривиальный функционал (например digg-like)на данный момент реализуется связкой из 6-8 сторонних модулей (часть не stable) от разных авторов, один из которых, кстати, "забил".
Веду я к тому, что необходимо уделять не мало времени на отслеживание новых версий модулей, их API, списки багов и реакцию разработчиков на них.
Но все-таки, если вы работаете один или у вас маленькая команда - OS CMS/CMF правильный выбор.
действительно, большую часть популярного функционала можно реализовать используя готовые модули как "кубики". Пичем, необходимого схожего результата можно добиться используя различные наборы кубиков-модулей, что есть достоинством и, в некоторой степени, недостаком. Таких дополнительных (contributed ) модулей у Друпала свыше 500, около трети из них активно дорабатывается и содержат несколько версий (dev и stable для разных версий ядра). У модулей появляется и изменяется API для интеграции с другими модулями. Нетривиальный функционал (например digg-like)на данный момент реализуется связкой из 6-8 сторонних модулей (часть не stable) от разных авторов, один из которых, кстати, "забил".
Веду я к тому, что необходимо уделять не мало времени на отслеживание новых версий модулей, их API, списки багов и реакцию разработчиков на них.
Но все-таки, если вы работаете один или у вас маленькая команда - OS CMS/CMF правильный выбор.
полностью с вами согласен, по сути это материал отдельный по стратегии выбора ЦМС... но в общих черта именно так.
В модулях (и их количестве, которое как известно переходит в качество) сила друпала. Меня больше волнует отказ от использования новых возможностей php5 (OOP)(хотя это будет уже не друпал :) Использование таблицы sequences вместо auto_increment, и html размазанный по всему коду.
>отказ от использования новых возможностей php5 (OOP)
легкость, друпал поднимается на стреднестатистичеком shared -хостинге;
>таблицы sequences вместо auto_increment
на это есть основательные причины;
>html размазанный по всему коду
любой тег/элемент легко можно переоптеделить.
вы поклоннийк MVC? Мне тоже нравятся эти буквы.
легкость, друпал поднимается на стреднестатистичеком shared -хостинге;
>таблицы sequences вместо auto_increment
на это есть основательные причины;
>html размазанный по всему коду
любой тег/элемент легко можно переоптеделить.
вы поклоннийк MVC? Мне тоже нравятся эти буквы.
Спасибо за интересную статью.
Aleks_raiden, возможно, вы сможете посоветовать, как именно менеджеру (не техническому специалисту) выбрать среди множества предлагаемых cms, не прибегая к помощи программиста? Передо мной сейчас стоит именно такая задача.
В списках, представленных на сайтах типа cmslist.ru я теряюсь :) там этих cms'ок десятки
Aleks_raiden, возможно, вы сможете посоветовать, как именно менеджеру (не техническому специалисту) выбрать среди множества предлагаемых cms, не прибегая к помощи программиста? Передо мной сейчас стоит именно такая задача.
В списках, представленных на сайтах типа cmslist.ru я теряюсь :) там этих cms'ок десятки
трезво написано. продолжай :)
еще интересно былобы узнать побольше на тему проблемы курицы и яйца. сайт без пользователей - потенциальным пользователям неинтересен. какими найменее затратными путями можно получить начальных пользователей?
еще интересно былобы узнать побольше на тему проблемы курицы и яйца. сайт без пользователей - потенциальным пользователям неинтересен. какими найменее затратными путями можно получить начальных пользователей?
автор случайно не менеджер проекта однокласники.ру?
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
а кроме как то же писать в комментариях вы не можете ничего больше? аргументы есть?
НЛО прилетело и опубликовало эту надпись здесь
ну так как большинство поступают точно наоборот, то видимо это не такая уж распространённая мысль. а можете ли вы много или мало, этого никто не знает, пока не сделаете и не покажите. пока же можете просто писать комментарии и, как бы это сказать, просто ведёте пустые разговоры. есть что сказать по теме факты или аргументированное мнение - говорите.
расскажите почему?
НЛО прилетело и опубликовало эту надпись здесь
о! тут вы правы, но вот вывод неверный. Ваш бизнес - создавать ПО - тогда да, вы правы, ведь наколировав модуль, допустим, реализующий анализ коментариев по нечёткому словарю на наличие матёрых слов, вы создали продукт и ту самую вашу добавленную стоимость (кстати, а к чему эта стоимость добавленная, на входе, в отличие от материального производства, не было ничего). Но если ваша задача обеспечить _сервис_, то, заметьте, это не то совсем понятие, и ценообразование и бизнес-модель _сервиса_ отличается от такой же модели для бизнеса производственного (что бы он не производил - тапочки или компоненты для ASP.NET).
НЛО прилетело и опубликовало эту надпись здесь
кроме этого, есть кстати, ещё и понятия минимализации издержек производства, в данном случае речь идёт о разумной минимизации издержек на развёртывания базисного функционала, о чем (минимализации) бизнес тоже не меньше печётся. поэтому стоит сначала проанализировать, _что_ приносит доход, что лежит в основе вашей конкретной бизнес-модели, а тогда уже переходить на определение добавленной стоимости и к чему она прилагается.
прочитал с интересом. по ходу прочтения с некоторыми вещами был не согласен, только по окончанию понял что Вы говорили о ЦМС системах. Я не любитель таких вещей, в силу того что у меня уже есть достаточно большой опыт в разработке, наборы модулей и достаточно стабильные (многократно обкатанные) версии своих фрэимворков для PHP.
Я согласен в тем, что найти разработчика со знаниями известной ЦМС системы намного проще чем разработчика который сможет доработать кастомную систему. Но тут есть одно "но". в основном с ЦМС системами работают люди с малым опытом, поэтому найти человека который сможет что-то доработать Вам будет проще, но профессионал сможет работать с чем угодно. :) тут и разница - профессионал сделает лучше и подумает наперед.
ЦМС системы безусловно хороши для небольших проектов, при стандартных модулях и скромных аппетитов заказчика :)
Но как только аппетиты начнут расти, не факт что Ваша система будет по-прежнему удовлетворять Вашим потребностям. Например одно дело использовать Smarty в своем фрэимворке. А совсем другое дело использовать готовый движок. Проблема в том, что вы зависите от выранного Вами движка. и если сегодня вы запустите стартап на версии некоего движка 1.1, а завтра выйдет версия 2.0, несовместимая с предыдущими (что бывает достаточно часто), то Вы останитесь не у дел. и придется любыми силами переходить на 2.0 чтобы иметь возможность найти разработчиков знающих Вашу систему. Еще, довольно важный момент всех этих вещей - в любой момент может появиться security bug report на сайте разработчиков Вашего движка. И какие-нибудь недоброжелатели могут им воспользоваться. Имея кастомную систему (пусть намного более несовершенную), все тараканы останутся внутри, и как следствие Вы сможете быть более спокойны в плане безопасности существования Вашего проекта.
Я хочу еще привести несколько причин, почему разработчики предпочитают изобретать велосипеды, вместо использования готовых ЦМС систем. Я согласен, что зачастую на небольших проекта правильнее использовать готовые решения.
1. ЦМС системы, взять тот же eZ (пусть фанаты этого монстра не обижаются), но он жутко тормознутый
2. Для большого проекта, профессионалу лучше использовать хороший enterprise framework
3. банальное - разработчикам легче отвечать за свой код, чем за то что сделали не они (не хочется исправлять чужие баги, угадывать что думал разработчики движка и почему так, а тем более им не хочется разбираться с большой ЦМС, а это нужно, потому как они должны знать что, где, как и почему. для того чтобы в адекватные сроки быть в состоянии оказать поддержку)
4. ЦМС системы очень удобны снаружи и очень сложные и кривые внутри. Из-за большого количества модулей они намного медленнее переходят на более новые версии языков программирования и баз данных.
5. Часто, возможностей модулей недостаточно и их приходится расширять
6. У разработчиков могут быть свои серьезные, похожие наработки
Ну и в заключение, не все заказчики хотят чтобы их проекты делались на известных ЦМС. не знаю почему :) Но как мне кажется, популярные движки и их модули хотят использовать те кто хочет побыстрее и подешевле.
А в целом, статья мне понравилась, Ваш сайт я еще не смотрел, но обязательно загляну. Было бы интересо продолжить дискуссию, ведь в споре рождается истина
Я согласен в тем, что найти разработчика со знаниями известной ЦМС системы намного проще чем разработчика который сможет доработать кастомную систему. Но тут есть одно "но". в основном с ЦМС системами работают люди с малым опытом, поэтому найти человека который сможет что-то доработать Вам будет проще, но профессионал сможет работать с чем угодно. :) тут и разница - профессионал сделает лучше и подумает наперед.
ЦМС системы безусловно хороши для небольших проектов, при стандартных модулях и скромных аппетитов заказчика :)
Но как только аппетиты начнут расти, не факт что Ваша система будет по-прежнему удовлетворять Вашим потребностям. Например одно дело использовать Smarty в своем фрэимворке. А совсем другое дело использовать готовый движок. Проблема в том, что вы зависите от выранного Вами движка. и если сегодня вы запустите стартап на версии некоего движка 1.1, а завтра выйдет версия 2.0, несовместимая с предыдущими (что бывает достаточно часто), то Вы останитесь не у дел. и придется любыми силами переходить на 2.0 чтобы иметь возможность найти разработчиков знающих Вашу систему. Еще, довольно важный момент всех этих вещей - в любой момент может появиться security bug report на сайте разработчиков Вашего движка. И какие-нибудь недоброжелатели могут им воспользоваться. Имея кастомную систему (пусть намного более несовершенную), все тараканы останутся внутри, и как следствие Вы сможете быть более спокойны в плане безопасности существования Вашего проекта.
Я хочу еще привести несколько причин, почему разработчики предпочитают изобретать велосипеды, вместо использования готовых ЦМС систем. Я согласен, что зачастую на небольших проекта правильнее использовать готовые решения.
1. ЦМС системы, взять тот же eZ (пусть фанаты этого монстра не обижаются), но он жутко тормознутый
2. Для большого проекта, профессионалу лучше использовать хороший enterprise framework
3. банальное - разработчикам легче отвечать за свой код, чем за то что сделали не они (не хочется исправлять чужие баги, угадывать что думал разработчики движка и почему так, а тем более им не хочется разбираться с большой ЦМС, а это нужно, потому как они должны знать что, где, как и почему. для того чтобы в адекватные сроки быть в состоянии оказать поддержку)
4. ЦМС системы очень удобны снаружи и очень сложные и кривые внутри. Из-за большого количества модулей они намного медленнее переходят на более новые версии языков программирования и баз данных.
5. Часто, возможностей модулей недостаточно и их приходится расширять
6. У разработчиков могут быть свои серьезные, похожие наработки
Ну и в заключение, не все заказчики хотят чтобы их проекты делались на известных ЦМС. не знаю почему :) Но как мне кажется, популярные движки и их модули хотят использовать те кто хочет побыстрее и подешевле.
А в целом, статья мне понравилась, Ваш сайт я еще не смотрел, но обязательно загляну. Было бы интересо продолжить дискуссию, ведь в споре рождается истина
В беседе рождается истина :) В споре чаще рождаются обиды :)
Вы написали достаточно неплохой и взвешенный комментарий, озвучив некоторые мои мысли. А я, пожалуй, смогу немного прокомментировать ваши.
Очень верно, но без необходимого акцента, подмечено про bug lists: на самом деле, когда проект висит на популярном движке - нужно постоянно следить за обновлениями версий ПО, на котором работает проект. Неоднократно бывали случаи, когда на "хакерских" сайтах публиковались уязвимости известных решений (например, небезызвестный phpBB) - и посетители кидались проверять эту дырку на известных им сайтах на этом решении. А как вы знаете - попросить у гугла вывести ему список сайтом на таком-то движке не очень сложно.
Отсюда можно сделать вывод - что для поддержания такого проекта этому аспекту нужно уделять большое внимание: если ты up-to-date, то ты на коне. А качественно и ответственно этим может заниматься только подготовленный человек, в лучшем случае - профессионал. И тут же - могут появляться проблемы с обновлением движка, переносом на новый и так далее: из-за того, что "что-то" доработали.
По поводу заказчиков и известных решений: во первых, продавать заказчику решение, построенное на базе open source, достаточно спорно. Ведь, по большему счету, open source предназначен для непосредственно для open source. Тут есть тонкая грань - целиковое решение или какие-то компоненты или библиотеки: последние, само собой, используются повсюду.
Заказчики в большинстве хотят получить решение, созданное специально для них. Отчасти может из-за того, что они понимают, что платят деньги за труд, результатом которого будет решение, созданное специально для них. И разработчики, как было отмечено выше, смогут его итерационно доработать до необходимого уровня (если это, конечно, оговорено в договоре) - со своим кодом это делать гораздо проще.
Вообще это всё палка о двух концах, как и многое в этом мире )
Очень верно, но без необходимого акцента, подмечено про bug lists: на самом деле, когда проект висит на популярном движке - нужно постоянно следить за обновлениями версий ПО, на котором работает проект. Неоднократно бывали случаи, когда на "хакерских" сайтах публиковались уязвимости известных решений (например, небезызвестный phpBB) - и посетители кидались проверять эту дырку на известных им сайтах на этом решении. А как вы знаете - попросить у гугла вывести ему список сайтом на таком-то движке не очень сложно.
Отсюда можно сделать вывод - что для поддержания такого проекта этому аспекту нужно уделять большое внимание: если ты up-to-date, то ты на коне. А качественно и ответственно этим может заниматься только подготовленный человек, в лучшем случае - профессионал. И тут же - могут появляться проблемы с обновлением движка, переносом на новый и так далее: из-за того, что "что-то" доработали.
По поводу заказчиков и известных решений: во первых, продавать заказчику решение, построенное на базе open source, достаточно спорно. Ведь, по большему счету, open source предназначен для непосредственно для open source. Тут есть тонкая грань - целиковое решение или какие-то компоненты или библиотеки: последние, само собой, используются повсюду.
Заказчики в большинстве хотят получить решение, созданное специально для них. Отчасти может из-за того, что они понимают, что платят деньги за труд, результатом которого будет решение, созданное специально для них. И разработчики, как было отмечено выше, смогут его итерационно доработать до необходимого уровня (если это, конечно, оговорено в договоре) - со своим кодом это делать гораздо проще.
Вообще это всё палка о двух концах, как и многое в этом мире )
Похоже на раскрутку очередного стартапа на дырявом движке Pligg с помощью якобы актуально статьи и за счет авторитетности хабра
минусуйте, минусуйте, правда режет глаза? стыдно за хабр
Знаете - статья сделала свое дело, раз заставила вас реагировать. Она же не обязана решать какую-то проблему, она может наталкивать на мысли и на обсуждения :D
ну тут ещё надо заметить, что сам по себе опенсорсный движок - это не банальность :) Банальностью в 90% случаев является то, что на этом движке поднимают. Клонированные бложики о заработке в сети (хозяева которых сами надеются заработать в сети) уже стали притчей во языцех :)
Пример мозиллы на друпале показателен лишь в случае, если веб-сайт используется только для донесения конечного продукта(софта) до пользователя.
А вообще, у меня сложилось мнение, что использование существующих CMS уместно только в случае сайтов, у которых не предполагается особое расширение функционала.
А вообще, у меня сложилось мнение, что использование существующих CMS уместно только в случае сайтов, у которых не предполагается особое расширение функционала.
Существующие движки можно и нужно анализировать на наличие удобных вещей, чтобы улучшить свой, в котором ты точно знаешь как что работает. А использовать можно только для мелких проектов не отличающихся большой оригинальностью от множества других.
Уникальные вещи создаются собственноручно.
Уникальные вещи создаются собственноручно.
Virtual_GOD и Silenius - ответ вам занял бы страницу, наверное :) можно использовать цитаты с ваших комментариев для развёрнутого ответа в продолжении материала?
PIT - вы правы, но если заметили - речь идёт именно об уникальный проектах, когда аналогичного функционала _нет_. во многих других случаях решается задача создать сервис, а программисты решают то что им ближе - пишут код, ЦМС, тогда как задача бизнеса все же получить работающий _сервис_. разницу понимаете?
PIT - вы правы, но если заметили - речь идёт именно об уникальный проектах, когда аналогичного функционала _нет_. во многих других случаях решается задача создать сервис, а программисты решают то что им ближе - пишут код, ЦМС, тогда как задача бизнеса все же получить работающий _сервис_. разницу понимаете?
Что-то я не совсем понял. Это перевод старой англоязычной статьи? Не знаю кто как, а я уже живу в конце 2007 года и достаточно наелся "стартапами", в которых всё начинается с "детального создания описания функциональности проекта" :-)) Ёлки-палки, ну что за ересь? Какой смысл обсуждать разницу между CMS, если сначала нужно сделать бизнес-модель? И второе: если нанимать программистов за 1000 долларов, то они сколько угодно будут кормить вас сказками о разнице между Друпалом и Джумлой, говорить много умных слов на тему open-source community и прочем. А стоит только начать нанимать специалистов и платить им нормальные деньги, разговор наконец-то пойдет о другом: о том, насколько выбранный язык отвечает принятому технологическому стандарту производства, о стоимости моделирования функционала, о стоимости внесения изменений, о планируемом проценте риска при расчёте стоимости кастомизации и т.д.
так мы не о ентерпрайз системах говорим то. твиттер как начинался? и все остальные проекты. давайте не путать области. и даже в тех проектах нужно описывать функционал, разве что вы сразу поставите оракл и там вам будут за 10К специалисты-внедренцы и аналитики за вас придумывать а как же вы будете с ним работать.
Ваши сроки разработки немого не те что у Брукса
http://webkomora.com.ua/ru/articles/web/management/man-month/18.html
2.8 Мое практическое правило: 1/3 времени - на проектирование, 1/6 - на написание программы, 1/4 - на тестирование компонентов и 1/4 - на системное тестирование.
-Заявление мифического человеко-месяца -
Столь размытый период проектирования - разработки у Вас, это практический результат?
Кажется первый пункт я бы снял вообще, так как к подобным разработкам он не имеет никакого отношения.
http://webkomora.com.ua/ru/articles/web/management/man-month/18.html
2.8 Мое практическое правило: 1/3 времени - на проектирование, 1/6 - на написание программы, 1/4 - на тестирование компонентов и 1/4 - на системное тестирование.
-Заявление мифического человеко-месяца -
Столь размытый период проектирования - разработки у Вас, это практический результат?
Кажется первый пункт я бы снял вообще, так как к подобным разработкам он не имеет никакого отношения.
НЛО прилетело и опубликовало эту надпись здесь
Это как панельный и кирпичный дом. Дешевле и быстрее панельный, но предпочитают все кирпичный. (при прочих равных)
НЛО прилетело и опубликовало эту надпись здесь
Стартап на Битриксе! Падсталом! :) Легче из г@#№а конфетку сделать.
Все можно сделать на чем угодно. И на битриксе и на пхп-нюке. Главное с умом подойти к делу...
мне всегда казалось, что "старт-ап" это характеристика состояния проекта, а не его технической сложности.
Те же одноклассники до последнего воемени (да и сейчас во многом) ты было очень убогое технически решение. Чего только стоила ненормализованная база учебных заведений!
Те же одноклассники до последнего воемени (да и сейчас во многом) ты было очень убогое технически решение. Чего только стоила ненормализованная база учебных заведений!
Продолжаю флудить...
Делать стартап на CMS - все равно, что говорить пословицами.
Делать стартап на CMS - все равно, что говорить пословицами.
НЛО прилетело и опубликовало эту надпись здесь
Да что вообще спорить? Возьмите, да и попробуйте создать с нуля свой первый проект. И сразу все точки над i будут расставлены - у кого-то пойдет, а у кого-то нет. Программисты или бизнесмены - каждому свое, каждый делает то, что умеет. Умирают стартапы ИМХО потому что всегда чего-то нехватает. Программеру нехватает навыков бизнесмена (сеошника), бизнесмену надо нанимать программера и т. п. Плюс не все готовы продать квартиру и кинуть все деньги на рекламную кампанию :-)))
А если серьезно, интернет-сайт (любой) - это тот-же киоск в реале. У него есть хозяин и товар (контент). Кто-то сможет вывести его на уровень огромного и дорогого супермаркета, а кто-то так и будет торговать сигаретами. Третий вообще поймет, что это "не его" и продаст его нах. Поэтому если вы хотите создать свой проект, да еще чтобы он был востребован и приносил деньги - не жадничайте временем, составьте "бизнесплан" и подробно все распишите, начиная от того, сколько народу будет задействовано в работе и заканчивая цветом ссылочек в подвале страницы. И подсчитайте все затраты.
А сейчас мы наблюдаем в основном такую картину. Сидит человек в сети и думает, как бы денег поднять? Чаще по призванию это программисты, а не бизнесмены. И начинает этот человек, слепо веря в свои силы (и не безосновательно - он хороший программист) тупо с нуля строить свой сайт, в надежде на то, что завтра "озолотится". Но так не бывает - это в первую очередь бизнес, а уже потом IT.
А если серьезно, интернет-сайт (любой) - это тот-же киоск в реале. У него есть хозяин и товар (контент). Кто-то сможет вывести его на уровень огромного и дорогого супермаркета, а кто-то так и будет торговать сигаретами. Третий вообще поймет, что это "не его" и продаст его нах. Поэтому если вы хотите создать свой проект, да еще чтобы он был востребован и приносил деньги - не жадничайте временем, составьте "бизнесплан" и подробно все распишите, начиная от того, сколько народу будет задействовано в работе и заканчивая цветом ссылочек в подвале страницы. И подсчитайте все затраты.
А сейчас мы наблюдаем в основном такую картину. Сидит человек в сети и думает, как бы денег поднять? Чаще по призванию это программисты, а не бизнесмены. И начинает этот человек, слепо веря в свои силы (и не безосновательно - он хороший программист) тупо с нуля строить свой сайт, в надежде на то, что завтра "озолотится". Но так не бывает - это в первую очередь бизнес, а уже потом IT.
Интересно бы понять, вот просто навскидку, какие CMS можно было бы использовать, чтобы создать...ммм... хотя бы аналог Хабра?
Мне кажется одних Друпалов и Плиггов будет маловато, имхо.
Мне кажется одних Друпалов и Плиггов будет маловато, имхо.
да а чего в хабре есть уникального? ничего ведь. уникальность может быть в алгоритме оценки и реакции на отдельные параметры (карма там и т.д.), так что с определенной доработкой и друпал и плигг вполне заменяют, да и добавили бы ещё возможностей (чего стоит убогий совсем и с глюками в ФФ интерфейс создания новой записи, все же 2007 год, а выглядит совсем уж убого).
А кто-нибудь что-нибудь может сказать о open source движке Elgg?
http://elgg.org/
http://elgg.org/
я имел ввиду, что технически нет уникальных и нереализованных нигде функций и возможностей.
Хорошая статья.
Правда есть еще один важный момент, что стоит высветлить.
Необходимо также оценивать трудоёмкость в соотношении к требованиям расширяемости модуля или продукта.
Часто для простых объектов, что или не будут активно расширяться или будут, но вне пределов функциональности продукта всё-же оптимально писать свою систему.
Правда есть еще один важный момент, что стоит высветлить.
Необходимо также оценивать трудоёмкость в соотношении к требованиям расширяемости модуля или продукта.
Часто для простых объектов, что или не будут активно расширяться или будут, но вне пределов функциональности продукта всё-же оптимально писать свою систему.
А вот есть ли варианты, чтобы купить CMS, но недорого (может кто покупал и пользовал)?
Например, за $100-400. Ну саппорт чтобы был и прочее...
Например, за $100-400. Ну саппорт чтобы был и прочее...
1. важно чтоб вы понимали, что в стоимость CMS не входит разработка, внедрение и сопровождение сайта на ней. Вы покупаете коробку интрументов с некоторой гаратией на них - остальное - ваша забота либо докупать кастомизацию, дизайн/шаблон и т.д.
2. поддержка CMS и подержка запущеного сайта - разные статьи расходов.
Популярные открытые CMS также имеют платную поддержку (местами качественней), например http://drupal.org/paid-services
+ у вас будет возможность выбора из желающих помочь за денежку (поторговаться) в отлчии от.
2. поддержка CMS и подержка запущеного сайта - разные статьи расходов.
Популярные открытые CMS также имеют платную поддержку (местами качественней), например http://drupal.org/paid-services
+ у вас будет возможность выбора из желающих помочь за денежку (поторговаться) в отлчии от.
Еще один момент - популярные open-source системы обновляются десятки раз в год, чего себе не могут позволить многие коммерческие системы. Плагины также обновляются и тоже довольно часто. Как-то скачал, установил плагин к ВордПрессу (голосовалку), а пока пришло время сдавать клиенту работу (2 дня) он уже обновился ;)
ИМХО юзать 3rd party типа wordpress или тем более какой-то IPB для посещаемый проектов для тех, кому не жалко денег на новые сервера. Для дом страниц и небольших форумов (до 500К хитов в сутки) конечно хорошо, но продакшн-системы что расчитаны на высокую нагрузку, имхо, стоит проектировать несколько по-другому, чем wordpress (я знаю про существование плагина кеширования, если об этом зайдет речь).
то есть, не нужно использовать готовые, опен-сорс решения, например мемкешед, РНР, тот же MySQL, SymmetricDS, XSLCache, DBSlayer - да? А если вы посмотрите на сайте http://highscalability.com/welcome-high-… то увидите, что почти все гиганты использую очень много всего открытого и бесплатного. Те, кто делают опен-сорс проекты они же тоже разрабатывают свое и архитектурно готовое к высоким нагрузкам. И если я делаю такую систему, сдаю клиенту и открываю код, то что, такая система сразу стает чем-то хуже?
Я не о том опенсорсе и возможно и не об опенсорсе вообще (IPB - насколько я знаю не имеет бесплатных версий.. хотя могу и ошибаться).
Я о движках сайтов и форумов вроде Вордпресса, IPB, DLE итд.
А php, memcache итд использовать очень даже можно и нужно. Но архитектуру сайта надо строить самому (ну или найти решение именно для очень посещаемых сайтов, где страницы не генерятся на лету в большинстве случаев)
Я о движках сайтов и форумов вроде Вордпресса, IPB, DLE итд.
А php, memcache итд использовать очень даже можно и нужно. Но архитектуру сайта надо строить самому (ну или найти решение именно для очень посещаемых сайтов, где страницы не генерятся на лету в большинстве случаев)
Зачет за линк.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Поговорим о стартапах или так можно ли использовать стандартные движки, темы и дизайн?