Спасибо всем за отзывы!
Да, такое бывает. Хотя нету прямого конфликта между удобством GUI и качеством CMS с точки зрения технологий.
Я считаю, что отчуждаемость безусловно является одним из критериев, но важность ее сильно преувеличена. Про злобного разработчика, который "привязывает" к себе клиента - скорее миф, подогреваемый "коробочниками". На самом деле, держать недовольного клиента - почти всегда не выгодно, требует много нервов и времени.
Вопрос отчуждаемости лежит не в сфере технологий, а скорее относится к организации бизнеса разработчика системы. Если система неотчуждаемая - это значит всего лишь, что ее изготовитель не занимается продажей CMS :) Значит, разработчик не хочет держать большой отдел тех. поддержки, придумывать "универсальный" функционал, вкладываться в маркетинг продукта и т.д. При этом система может иметь и полную документацию, и открытый код, и даже поддержку от разработчика.
Я работал в 4х компаниях, где внедряли свою разработку. Помню всего один случай, когда клиент ушел и затем перенес сайт на другую систему (причем новый разработчик даже не пытался получить документацию, хотя мы обещали помочь). С другой стороны, у нас есть несколько проектов на поддержке, разработанных не нами. Есть на "самописках", есть и на "коробках". Поддерживать "коробки" ничуть не проще, а иногда и гораздо напряжнее. Играет роль не система, а квалификация предыдущего разработчика. Поверьте, на "Битриксе" можно сделать такое, что ни одна вменяемая студия поддерживать не возьмется :)
И кстати, еще одна проблема "коробок" - программисты очень любят валить на них все грехи. Особенно если на использовании системы настоял заказчик. Ну, типа "это не мы кривые, это система кривая, не мы же ее писали!". Не имея квалификации, с этим очень сложно спорить :)
kod_ssilki_ru, спасибо за ценный комментарий.
Возможно, это важно для клиента. Большинство студий со временем обзаводится своими серверами, поскольку это сильно удобнее и дешевле.
Вполне себе жив и открыт для общения :) И развивается в правильном направлении, как мне показалось.
Это было бы интересно. Но у меня нет опыта интеграции этой системы, хотя и "ковырял" ее довольно глубоко. Если кто-то готов взяться за анализ - будет очень круто.
On Air,
1. На какую аудиторию рассчитываете? Технарскую или "маркетоидную"?
2. http://seopult.ru/content/seminary/umisoft - ссылка на umi-cms.ru битая, кавычка лишняя в конце.
3. Две темы - непорядок, вообще-то за такое штрафуют. Ну да ладно, верю, что это по недомыслию :) Тему в "Семинарах" сейчас убьем.
4. Красный цвет на сером фоне не читается, пожалуйста, не злоупотребляйте.
А так - спасибо, будет интересно посмотреть.
BrokenBrake, спасибо за отзыв!
Секция, где я выступал, называлась "инструментарий веб-студии". Тут более сложная задача - не выбор системы для отдельного проекта, а выбор основного инструмента для большинства проектов, которые выполняет команда. Ясное дело, к такому вопросу следует подходить более ответственно. В частности, полезно изучить технические особенности систем-кандидатов.
Во-первых, что значит "субъективно"? В смысле, "дизайн упаковки понравился"? :) Такое, слава Богу, уже не часто встретишь. Во-вторых, откуда цифра? )
Я соглашусь, что большинство студий при выборе CMS не руководствовались каким-то систематическим подходом, процесс выбора не был формализован. Ну, грубо говоря, генеральный услышал про X.CMS, предложил программистам попробовать, понравилось, вот система и выбрана. Или, например, студия делала сайты на своей системе, потом пришел новый сотрудник, сказал, что на X.CMS быстрее и проще, попробовали, понравилось... ну и т.д. Оданко, это самое "понравилось" в любом случае имеет под собой ряд объективных критериев. Я лишь попытался формализовать часть из них.
У нас после конференции была интересная дискуссия с Shivana на эту тему. С одной стороны, внедрять технически отсталую систему только потому, что она привычнее - наверно, не совсем правильно. Но я категорически убежден, что решение о смене CMS не должно спускаться "сверху". Переучиваться против своей воли программисты не будут :) Но если к команде придет понимание: "надо что-то менять" - обязательно нужно выделить время на изучение конкурирующих систем. Иначе, маринуясь в собственном соку, легко отстать от жизни.
Кстати, это особенно больной вопрос для систем-"самоделок". Я на это обратил особое внимание в докладе. Если студия работает на своей системе, по понятным причинам вопрос об альтернативах - весьма неприятный. Ну как - тут наша Studio.CMS, мы ее вырастили, мы ее любим, мы ее знаем вдоль и поперек... зачем нам ваш бездушный Битрикс? :) Но на самом деле разработка и поддержка своей системы требует много сил, и к этому нужно относиться критически в любой момент времени, сравнивать с "коробками", анализировать недостатки и понимать преимущества. В том числе - и технологические, для чего можно использовать аспекты, перечисленные в моем докладе, в качестве паттерна.
Во-первых, техническими характеристиками процесс выбора не ограничивается, я об этом много раз говорил. Просто технологии сложнее анализировать. Во-вторых, если в компании много времени тратится непосредственно на разработку (что особенно характерно для больших сложных проектов) - это как раз тот момент, который необходимо оптимизировать любыми средствами. Если компания планирует просуществовать хоть сколь либо долго, затраты обязательно окупятся. Например, если потратить на обучение неделю и ускорить реализацию месячного проекта хотя бы на 2 дня (10%) - затраты окупятся через 4 проекта :)
А кстати, почему неинтересных? Лидеры, как никак. Правда любопытно :)
На панели не сайты делают, а... Битрикс - система :)
Переношу в "Работу".
Вот кусок кода, который мы юзаем, не помню уже, откуда взялся:
public static function validateEmail($address, $use_mxrr_test = false, $use_socket_test = false) { /** Проверка валидности е-мейла */ if(!preg_match("/^[a-zA-Z0-9_\.-]+@[a-zA-Z0-9\-\.]+\.[a-zA-Z0-9\-\.]+$/", $address)) { return FALSE; } list($Username, $Domain) = split("@",$address); if($use_mxrr_test) { if (@getmxrr($Domain, $MXHost)) { return TRUE; } else { return false; } } if ($use_socket_test) { if(@fsockopen($Domain, 25, $errno, $errstr, 10)) { return TRUE; } else { return FALSE; } } return TRUE; }
Помимо регулярки умеет проверять хост на существование MX-ов и 25-го порта, но по понятным причинам может тормозить, а в большинстве случаев и регулярки хватает.
Кстати, оформлен дебильно, надо бы переписать :)
Поэтому запросы полезно тестировать в phpMyAdmin или другом подобном интерфейсе, чтоб было ясно, где ошибка - в коде или в запросе. Заодно можно сразу и скорость оценить.
Знакомый - альтруист или раб? :)
Вообще-то прекрасно разрабатывают. Даже на серче есть тысячи их, если поискать как следует :)
Ржачная тема :)
В курилку.
Clike, я думаю проще всего это выяснить, обратившись к ребятам, которые делали сайт.
