1 — А вот это уже вопрос о целевой аудитории рекламы. Если это конечные клиенты — незачем засорять им информационный фон шаблонами и прочим. Более того, наверняка найдутся те, кто сравнив рекламу одной системы («у нас есть возможность управлять контентом») с рекламой другой («у нас есть возможность управлять шаблонами») подумает — нахрен мне шаблонами управлять, мне контентом надо — и сделает свой выбор. Я немного утрирую, но мысль, думаю, понятна. А вот на веб-студии и правда надо по-другому позиционироваться.
2 — Это очень долгий разговор. Здесь очень много зависит от внедрения. Наш продукт, который, как мы считаем, неплохо юзабелен, можно так внедрить, что им вообще нельзя будет пользоваться. Так что здесь мы с Вами к однозначным выводам не придем :)
3 — Проводил. Нагрузочное тестирование проводил РБК-Хост этой весной, но лично у меня к этому исследованию вопросы, т. к. по нашему продукту там получились цифры гораздо хуже, чем они получились у нас. И даже примерно понятно почему. Сравнение юзабилити тоже проводили, правда, в этом сравнении победила CMS, аффилированная с теми, кто исследование и проводил :) Но в целом — объективное сравнение нужно, не спорю.
4 — За среднюю CMS не скажу, а мы всегда (с самого первого выпуска коробки) работали на обычном LAMP-хостинге. За очень редкими исключениями.
5 — Нет, не признаю :) Инструмент этот нужен, вопрос лишь в культуре его использования клиентом.
Отвечу в качестве представителя одного из этих самых разработчиков CMS. Факты Вы изложили правильно, а вот выводы получились, ИМХО, однобокими. По пунктам:
1. Полное управление наполнением сайта. Ну да, это основная функция, но все ли CMS позволяют управлять всем контентом сайта без залезания в код? Далеко нет. Я часто вижу CMS, где клиенту доступно управление только наиболее «динамичными» типами данных — новости, каталог и пр. А остальное — FTP в руки и вперед с песней. И на «коробочные» CMS люди переходят как правило либо с сильно ограниченных по функциональности систем, либо вообще со статики. Так что это вполне себе честное преимущество.
2. Интуитивно понятный интерфейс. Ну да, здесь можно признать лукавство, хотя бы потому что этот фактор наиболее субъективен. Заявлять о таком преимуществе корректно только при использовании вводных слов типа «по мнению таких-то экспертов» или «согласно такому-то исследованию». Но и Вы тоже субъективны: «На самом деле ни одна CMS-система не проста в использовании». Вы не сможете доказать это утверждение, так же, как и я не смогу доказать обратное. Так что соглашусь, но лишь наполовину.
3. Производительность. Насчет того, что такие утверждения корректны лишь в сравнении с другими — согласен на 100%. А вот про то, что нельзя опровергнуть — Вы не правы. Всегда можно провести тест «при прочих равных» — поставить на соседние одинаковые аккаунты одного хостинг-сервера и мерить скорость генерации страниц. Или на одном и том же сервере провести нагрузочное тестирование. И для клиента эти данные вполне применимы, т. к. даже не плохом канале или загруженном хостинге тормозная CMS создаст дополнительную тормознутость. А вот если канал и хостинг свободны — результат будет очень даже ощутим. Одна сотая секунды или пара секунд на генерацию страницы. 10 или 100 посетителей одновременно.
4. Почти любой хостинг. И снова Вы не правы — это как раз наша заслуга, на все 90%. 10% отводим буквально на последние месяцы, когда хостинг-провайдеры активно стали обращаться за сертификацией тарифных планов, тестированием совместимости. А раньше на нас особо не смотрели, и именно нам приходилось заботиться о совместимости со стандартным хостингом, а у кого не получалось — пробивать у хостеров специальные тарифные планы.
5 Висивиг. Отсутствие его — недостаток, а наличие — преимущество. Мы даем клиенту максимум возможностей, а то, как он ими будет пользоваться — вопрос вне компетенции разработчиков CMS. Стандартный пример — зачем продавать ножи, если ими можно зарезать кого-нибудь? Мы же не можем заставлять клиента при покупке пройти курс по юзабилити. Да и вообще, если начальника Зины не устраивают грядки с клубникой — он сможет скорректировать ее художественные изыски, а если устраивает — ну и его дело! Ну да, я тоже часто вижу результаты такого «творческого» использования нашего продукта. Но кто нас с Вами просил насаждать культуру использования сайтов, искусственно ограничивая их функциональность?
А вообще, гораздо интереснее разбирать конкретные маркетинговые хитрости конкретных разработчиков. Бывает иногда очень весело.
Голосование — да, в первой 3-й версии (сборка 300) оно глючило, в одном из следующих патчей исправлено. Форум — нет, просто макет подключается чуть сложнее, чем к обычному разделу, см. ртфм по модулям, 65 страница. Глючит цвет — как глючит? Саппорт по данной формулировке мне ничего путного не сказал.
В прошлом мессаге вы писали «половина модулей не работает, после каждого обновления система «ложится» и приобретает кучу багов» — можно ли поподробнее об этом? Какая именно половина модулей не работает и как они это (не) делают, как после каждого обновления система ложится и какие баги после каких обновлений приобретаются? Описанные вами проблемы — дикий ахтунг, тысячи пользователей о них не подозревают, хотя и обновляются, и модулями пользуются. Надо же народ предупредить.
Спасибо за пожелания. На самом деле, вопрос полностью новой версии (не совместимой со старой) изучался. Мы пришли к выводу, что в нашем конкретном случае это не имеет смысла ни с маркетинговой, ни с технической точки зрения. Даже полный рефакторинг выйдет дешевле и закроет принципиальные проблемы, которые были (и еще остаются). Главный плюс — мы не «подвешиваем» судьбу текущих пользователей.
Ну и плюс к тому — есть и другие факторы, которые рассказывать очень долго. Проблемы, которые вы подняли, будут решаться, просто не такими кардинальными способами.
По закону жанра я должен всячески отрицать претензии, но я не вижу причин спорить с очевидным :) Да, документация разработчика далека от идеала, и поэтому сейчас мы ей и занимаемся.
Обращения мы не игнорируем, а складываем в списки и по мере поступления разбираем. Что-то действительно «минусим», но большинство ставится в план — либо в ближайший патч, либо в следующую версию. Но вы правы насчет фидбэка, не всегда получается информировать об этом того, кто обращается с предложением.
Да я вам не оппонирую :) Хотя бы потому что вы говорите правильные вещи, и в целом я с вами согласен. Просто мы немного о разном говорим. Смотрите. Пример несколько утрированный, но тем не менее.
Сейчас у всей команды разработки NetCat есть свои задачи. Они расписаны на три месяца вперед. Разумеется, эти сроки отодвинутся, если появится срочная задача — например, найден серьезный баг или что-то в этом роде.
Мы ставим на «через три месяца» одной из групп рефакторинг. Но к этому времени появляется новая версия, вишлист наполняется новыми пожеланиями и пр. И мы видим, что объективно надо отодвигать рефакторинг. Что делать?
Отодвигать? Ну так оно всегда будет отодвигаться и никогда не произойдет. Отодвигать новые задачи? А если их решение влияет на бизнес наших клиентов/партнеров, и те банально могут уйти?
Приходится искать компромиссы.
Впрочем, в реальности не все так плохо, как в этом примере. Сейчас как раз такая ситуация, что на «через три месяца» вполне можно поставить такую задачу.
Такие вопросы лучше разбирать на примерах. Если есть пример — давайте попробуем его разобрать. Чаще всего (по статистике обращений в саппорт) к изменениям в ядре прибегают, когда не до конца разбираются в инструментах разработки системы. Это, кстати, одна из причин, почему мы сейчас занимаемся тотальной переработкой документации разработчика.
А что делать с задачами, которые сейчас решает эта группа? Например, одна группа делает SaaS, другая визарды, третья — готовые решения. С кого из них снимать задачи и почему? Можно конечно сказать, что нужно нанять еще программистов и сформировать из них новую группу, но не все так просто. Механическое увеличение штата не ведет автоматически к пропорциональному увеличению скорости разработки. Иногда даже наоборот.
Про инвестора — подпишусь. Но что из этого следует в контексте вопроса?
Форум — не новый модуль. Когда он писался, такой подход представлялся правильным. Почему — рассказывать долго. Сейчас уже понятно, что это была ошибка. До конца года будет выпущен новый модуль, уже в рамках идеологии.
У нас и так две команды, и они примерно этим и занимаются. Команды в свою очередь делятся на мобильные рабочие группы. 4-ю версию нельзя делать с нуля, она должна быть совместима с третьей, иначе придется либо кидать текущих пользователей, либо поддерживать две ветки и все равно кидать пользователей. В «тройке» была переписана наверное половина кода, но совместимость с 2.х осталась. Архитектура продукта на мой взгляд довольно удачная с точки зрения модернизации и масштабирования.
Инвесторам объяснить можно все что угодно, но с позиции денег. Я вот не знаю, как доказать, что вариант «бросить все на два месяца» более выгоден, чем «в течение полугода постепенно провести аудит и рефакторинг, не бросая приоритетных задач». Вы утрируете проблему — если бы у нас все оставалось на уровне PHP3 и не собиралось меняться — да, из этого ничего путного не вырастишь. Я же говорю лишь о том, что рефакторинг нужен, но не кардинальный и не одномоментно.
Отвечаю в качестве официального представителя NetCat.
Собственно, по большинству примеров я толком не понял претензию. Почему нехорошо так приводить к инту? Почему нельзя эвалить? Примеры со слешами выдраны из контекста. Ну и пр.
Можно ли задачи, выполняемые этим кодом, решить красивее? Наверное, да, по крайней мере, часть из них. Нужно проводить рефакторинг кода? Да. А нужно ли бросить все и вылизывать код? Сомневаюсь. Рефакторинг производится постоянно, и с точки зрения оптимизации, и красоты кода, и безопасности. Проблема в том, что производство коробочного ПО подразумевает кучу тонкостей и непопулярных решений. Ресурсы никогда не бывают безграничны, всегда приходится ставить приоритеты. Например, ввод некоторого востребованного инструмента приоритетнее, чем вылизывание кода, написанного некрасиво, но работающего правильно.
Наши разработчики прекрасно знают проблемы кода, и мне в аську скинули ссылку на этот топик со словами «а я тебе говорил». Смысл в том, что именно я ставлю задачи программистам (с точки зрения приоритетности задач). И я не раз ставил в план работ другие работы в ущерб очередному этапу рефакторинга.
NetCat разрабатывается с 99-го года. За эти 9 лет над кодом ядра трудились самые разные разработчики. От некоторых из них оставалось довольно веселое наследие, которое приходилось (или еще придется) исправлять. Далеко не всегда у нас нас был SVN, CVS, правила документирования кода и тестирования.
Я могу привести много примеров, когда приходилось, например, оттаскивать нового разработчика от рефакторинга, потому что другая задача более приоритетна. Мы можем потратить пару месяцев на аудит кода и его частичное переписывание, сюда же полный перевод на PHP5, но в это время все разработка остановится. Посмотрите на ситуацию с точки зрения не стороннего программиста, а нашего партнера, который запостил в вишлист просьбу включить в ядро новый функционал. Будет ли он рад решению отложить его пожелание на пару месяцев, пока мы вылижем код? Поэтому программистам и приходится наступать на горло собственной песне.
В общем, резюме. iBear, спасибо за топик, проблема есть. Рефакторинг проводится и будет проводиться и дальше, но, увы, это не наивысший приоритет.
2 — Это очень долгий разговор. Здесь очень много зависит от внедрения. Наш продукт, который, как мы считаем, неплохо юзабелен, можно так внедрить, что им вообще нельзя будет пользоваться. Так что здесь мы с Вами к однозначным выводам не придем :)
3 — Проводил. Нагрузочное тестирование проводил РБК-Хост этой весной, но лично у меня к этому исследованию вопросы, т. к. по нашему продукту там получились цифры гораздо хуже, чем они получились у нас. И даже примерно понятно почему. Сравнение юзабилити тоже проводили, правда, в этом сравнении победила CMS, аффилированная с теми, кто исследование и проводил :) Но в целом — объективное сравнение нужно, не спорю.
4 — За среднюю CMS не скажу, а мы всегда (с самого первого выпуска коробки) работали на обычном LAMP-хостинге. За очень редкими исключениями.
5 — Нет, не признаю :) Инструмент этот нужен, вопрос лишь в культуре его использования клиентом.
1. Полное управление наполнением сайта. Ну да, это основная функция, но все ли CMS позволяют управлять всем контентом сайта без залезания в код? Далеко нет. Я часто вижу CMS, где клиенту доступно управление только наиболее «динамичными» типами данных — новости, каталог и пр. А остальное — FTP в руки и вперед с песней. И на «коробочные» CMS люди переходят как правило либо с сильно ограниченных по функциональности систем, либо вообще со статики. Так что это вполне себе честное преимущество.
2. Интуитивно понятный интерфейс. Ну да, здесь можно признать лукавство, хотя бы потому что этот фактор наиболее субъективен. Заявлять о таком преимуществе корректно только при использовании вводных слов типа «по мнению таких-то экспертов» или «согласно такому-то исследованию». Но и Вы тоже субъективны: «На самом деле ни одна CMS-система не проста в использовании». Вы не сможете доказать это утверждение, так же, как и я не смогу доказать обратное. Так что соглашусь, но лишь наполовину.
3. Производительность. Насчет того, что такие утверждения корректны лишь в сравнении с другими — согласен на 100%. А вот про то, что нельзя опровергнуть — Вы не правы. Всегда можно провести тест «при прочих равных» — поставить на соседние одинаковые аккаунты одного хостинг-сервера и мерить скорость генерации страниц. Или на одном и том же сервере провести нагрузочное тестирование. И для клиента эти данные вполне применимы, т. к. даже не плохом канале или загруженном хостинге тормозная CMS создаст дополнительную тормознутость. А вот если канал и хостинг свободны — результат будет очень даже ощутим. Одна сотая секунды или пара секунд на генерацию страницы. 10 или 100 посетителей одновременно.
4. Почти любой хостинг. И снова Вы не правы — это как раз наша заслуга, на все 90%. 10% отводим буквально на последние месяцы, когда хостинг-провайдеры активно стали обращаться за сертификацией тарифных планов, тестированием совместимости. А раньше на нас особо не смотрели, и именно нам приходилось заботиться о совместимости со стандартным хостингом, а у кого не получалось — пробивать у хостеров специальные тарифные планы.
5 Висивиг. Отсутствие его — недостаток, а наличие — преимущество. Мы даем клиенту максимум возможностей, а то, как он ими будет пользоваться — вопрос вне компетенции разработчиков CMS. Стандартный пример — зачем продавать ножи, если ими можно зарезать кого-нибудь? Мы же не можем заставлять клиента при покупке пройти курс по юзабилити. Да и вообще, если начальника Зины не устраивают грядки с клубникой — он сможет скорректировать ее художественные изыски, а если устраивает — ну и его дело! Ну да, я тоже часто вижу результаты такого «творческого» использования нашего продукта. Но кто нас с Вами просил насаждать культуру использования сайтов, искусственно ограничивая их функциональность?
А вообще, гораздо интереснее разбирать конкретные маркетинговые хитрости конкретных разработчиков. Бывает иногда очень весело.
В прошлом мессаге вы писали «половина модулей не работает, после каждого обновления система «ложится» и приобретает кучу багов» — можно ли поподробнее об этом? Какая именно половина модулей не работает и как они это (не) делают, как после каждого обновления система ложится и какие баги после каких обновлений приобретаются? Описанные вами проблемы — дикий ахтунг, тысячи пользователей о них не подозревают, хотя и обновляются, и модулями пользуются. Надо же народ предупредить.
Ну и плюс к тому — есть и другие факторы, которые рассказывать очень долго. Проблемы, которые вы подняли, будут решаться, просто не такими кардинальными способами.
С UTF вопрос пока не решен, в сентябре будет принято решение, будет ли официальная поддержка этой ветки. Если да — уже осенью будет официальный релиз.
Обращения мы не игнорируем, а складываем в списки и по мере поступления разбираем. Что-то действительно «минусим», но большинство ставится в план — либо в ближайший патч, либо в следующую версию. Но вы правы насчет фидбэка, не всегда получается информировать об этом того, кто обращается с предложением.
Сейчас у всей команды разработки NetCat есть свои задачи. Они расписаны на три месяца вперед. Разумеется, эти сроки отодвинутся, если появится срочная задача — например, найден серьезный баг или что-то в этом роде.
Мы ставим на «через три месяца» одной из групп рефакторинг. Но к этому времени появляется новая версия, вишлист наполняется новыми пожеланиями и пр. И мы видим, что объективно надо отодвигать рефакторинг. Что делать?
Отодвигать? Ну так оно всегда будет отодвигаться и никогда не произойдет. Отодвигать новые задачи? А если их решение влияет на бизнес наших клиентов/партнеров, и те банально могут уйти?
Приходится искать компромиссы.
Впрочем, в реальности не все так плохо, как в этом примере. Сейчас как раз такая ситуация, что на «через три месяца» вполне можно поставить такую задачу.
Про инвестора — подпишусь. Но что из этого следует в контексте вопроса?
Инвесторам объяснить можно все что угодно, но с позиции денег. Я вот не знаю, как доказать, что вариант «бросить все на два месяца» более выгоден, чем «в течение полугода постепенно провести аудит и рефакторинг, не бросая приоритетных задач». Вы утрируете проблему — если бы у нас все оставалось на уровне PHP3 и не собиралось меняться — да, из этого ничего путного не вырастишь. Я же говорю лишь о том, что рефакторинг нужен, но не кардинальный и не одномоментно.
Собственно, по большинству примеров я толком не понял претензию. Почему нехорошо так приводить к инту? Почему нельзя эвалить? Примеры со слешами выдраны из контекста. Ну и пр.
Можно ли задачи, выполняемые этим кодом, решить красивее? Наверное, да, по крайней мере, часть из них. Нужно проводить рефакторинг кода? Да. А нужно ли бросить все и вылизывать код? Сомневаюсь. Рефакторинг производится постоянно, и с точки зрения оптимизации, и красоты кода, и безопасности. Проблема в том, что производство коробочного ПО подразумевает кучу тонкостей и непопулярных решений. Ресурсы никогда не бывают безграничны, всегда приходится ставить приоритеты. Например, ввод некоторого востребованного инструмента приоритетнее, чем вылизывание кода, написанного некрасиво, но работающего правильно.
Наши разработчики прекрасно знают проблемы кода, и мне в аську скинули ссылку на этот топик со словами «а я тебе говорил». Смысл в том, что именно я ставлю задачи программистам (с точки зрения приоритетности задач). И я не раз ставил в план работ другие работы в ущерб очередному этапу рефакторинга.
NetCat разрабатывается с 99-го года. За эти 9 лет над кодом ядра трудились самые разные разработчики. От некоторых из них оставалось довольно веселое наследие, которое приходилось (или еще придется) исправлять. Далеко не всегда у нас нас был SVN, CVS, правила документирования кода и тестирования.
Я могу привести много примеров, когда приходилось, например, оттаскивать нового разработчика от рефакторинга, потому что другая задача более приоритетна. Мы можем потратить пару месяцев на аудит кода и его частичное переписывание, сюда же полный перевод на PHP5, но в это время все разработка остановится. Посмотрите на ситуацию с точки зрения не стороннего программиста, а нашего партнера, который запостил в вишлист просьбу включить в ядро новый функционал. Будет ли он рад решению отложить его пожелание на пару месяцев, пока мы вылижем код? Поэтому программистам и приходится наступать на горло собственной песне.
В общем, резюме. iBear, спасибо за топик, проблема есть. Рефакторинг проводится и будет проводиться и дальше, но, увы, это не наивысший приоритет.