Разница в том, что именно продается.
Unmanaged — продажа ресурсов, крутись с ними как хочешь. Неплохой выбор, если сам хорошо знаешь что тебе нужно и как это делать.
Managed — продажа знаний и умений. Цена в разы выше. Но с потребителя снимается очень много проблем — как ставить, как настраивать, как обслуживать, как чинить если сломалось. Неплохой размен, если время хочется посвятить чему-то иному (например, собственно развитию сайта или бизнеса)
У нас как раз есть пример с активным меньшинством в работе. Скажем есть некая новая, не совсем общепринятая технология, с рядом вопросов и недостатков, но местами активно продвигаемая. Например в паре стран можно получить скидки за определенные услуги, если эта технология поддерживается. Соответственно, пользователи из этих стран начинают активно голосовать и выводят свое предложение в топ. Тут у нас возникают вопросы, поскольку наша оценка потребности в этой функции сильно отличается от ее рейтинга в голосовании.
Мы не пользуемся какой-то формальной формулой с коэффициентами, но составляющих три
— в каком сегменте пользователей это востребовано
— роль этого сегмента в нашем бизнесе
— влияние предложения на сегмент — удержание/приобретение/монетизация
Есть определенная модель из того, какие есть сегменты, какие и почему у них потребности, как эти сегменты взаимодействуют и соотносятся между собой.
Мы поддерживаем отношения с рядом компетентных клиентов в разных регионах, через эти группы мы можем проверять потребности в функции, в том числе отдельно в разных регионах — США, Европа и Азия в некоторых вопросах существенно отличаются.
Функция рассматривается с точки зрения упоминаемости (uservoice), с точки зрения влияния на бизнес (согласно модели) и вклада в стратегию, и с точки зрения проверки с избранными пользователями. Если есть расхождение между тремя точками зрения, то это повод насторожиться — что-то мы возможно неправильно понимаем. Собственно так мы в свое время и создали модель с разными сегментами — когда обнаружили противоречия в оценке пользы от ряда функций
Интересное решение. А тип issue пользователь выставляет сам?
Для нас голоса это тоже один из параметров. Всегда есть стратегия развития и всегда есть проблема «активного меньшинства», которые могут вывести в топ что-то нужное на самом деле немногим. Поэтому мы отдельно проверяем актуальность предложений через открытые источники и группы экспертов из числа текущих пользователей.
Извините, мы говорим про «высказаться может каждый» (предложения) в отношении одного продукта. Я не рассказываю про то, что «каждому помогут и ответят» — это было бы про службу поддержки. Это было бы совсем другое
Я, к сожалению, не очень компетентен в Desktop, тут надо понимать что Parallels большой, направлений и продуктов много, поэтому за совершенно другую часть бизнеса компетентно ответить не могу. Открыв сайт, сразу вижу следующее про «через определенное время получить ответы невозможно» — видимо речь о политике бесплатной поддержки 30 дней (http://www.parallels.com/ru/support/priority/) с момента покупки/регистрации и политике 2х лет с момента выхода (http://www.parallels.com/ru/support/phone/). Если это не про ваш случай, то если есть номер тикета в службе поддержки, могу частным образом поинтересоваться что с ним.
Да, есть такой момент. Поэтому важно отделять какую проблему люди предлагают решить от того, как они ее предлагают решить.
Почти каждую неделю кто-нибудь приходит просить workaround типа «более быстрой лошади», и после уточнения этот запрос переформулируется или объединяется с другим, где описание сфокусировано на проблеме «хочу ездить быстрее». Необходимость объединять казалось бы разные предложения в одно и была первой причиной перехода на коммерческий тариф — понадобилась функция Merge.
А разве в предыдущих (11, 10, 9) было иначе (не было, проверил — выбор версии php есть в версиях старее)? Могли вы бы подробнее описать изменения?
Для Windows выбор версии PHP был почти всегда (ну то есть давно уже) — так уж удобно устроен IIS в этом отношении. А для Linux появился только сейчас — регистрируете через CLI свой бинарник PHP и потом можно его выбирать для сайтов (для FastCGI/CGI)
Т.е. плеск будет заводить на БД сервере одинаковых пользователей для всех баз в подписке?
Просто у пользователя БД в Plesk появилась опция работать со всеми БД подписки. Права в БД будут настроены соответственно.
ИМХО статья на тему «как из facebook сделать vkontakt». :)
facebook сделан так, как он сделан, потому в нем главное ваши «друзья», а не «вы».
«После входа вижу свой профиль, свои фотки, и прочее» — этакий нарцисс-мод получается.
Системная проблема возникает, когда менеджмент оторван от технологии и эксплуатации слишком сильно. Тогда менеджмент не видит эксплуатационных проблем или не адекватно оценивает их как «быстренько исправьте и побежали дальше». Если одновременно менеджмент должен гнать сроки, то отсупать разработка может только за счет качества — потому что его не видно. :) Тогда возникает кризис — разработка считает, что все плохо из-за менеджмента, а менеджмент думает, что разработка вечно ноет, а надо бежать.
Технический долг совершенно нормален для любого живого проекта. «Девелопмент в рассрочку» — мы это называли так. Ценность получим сейчас, а проблемы отложим на потом.
Как любой долг, оно требует уплаты процентов. И если платить рассрочку не напряжно или проценты окупаются ранее полученной ценностью — то все нормально. А вот когда вся зарплата уходит на гашение кредитов — тут полный швах. А еще хуже — если на уплату одних процентов, даже без основного долга (как в историях про «русский стандарт») — это швах в квадрате. Вопрос гигиены, не более того. :)
Сам долг лучше бы мерить в количестве постоянных (recurrent) проблем, а не субъективном качестве кода. Я несколько раз наблюдал (и организовывал) смену команды разработчиков на проекте — и для всех живых проектов, абсолютно ВСЕГДА новые разработчики характеризовали старый код как «клоаку». Даже если команду сменить повторно — третья команда охарактеризует как «клоаку» творчество второй. :) Был даже пример обратной передачи — угадайте, что говорит первая команда про «что вы тут без нас наворотили?» :)
Кто-то злой поставил минус, а между прочим картина весьма реалистичная. Едва ли не большинство доминирующих продуктов сделаны криво и косо, все ругаются, но терпят. А тщательно продуманные и вылизанные архитектуры умирают из-за
— «пока добежим, все вкусное съездят» — продукт готов, а рынок занят.
— инвестор не вытерпел, деньги кончились. не у каждого есть терпеливый и верный инвестор.
— заплутали в идеалах. сделали все правильно, не учли нюанс, переделали еще раз правильно, еще раз не учли, еще раз переделали. запутались, умерли.
— изменились требования. «пока расчет производился, объект расчета в норке скрылся»
В Plesk в принципе можно ставить «левые» пакеты, если они совместимы с «официальными» по зависимостям, расположению файлов и прочему. К примеру, Atomic'овский репозитарий для CentOS пользуют очень широко. Иногда, конечно, возникают «нюансы» с конфликтами пакетов, но обычно можно разрулить, если понимать немного как вообще RPM работает.
Ну если что-то крутить во внутренней базе, то это достаточно верный путь к проблемам. Тут все под личную отвественность и гарантий никаких.
Лучше крутить через официальные CLI и XML API — они покрывают довольно многое, хотя есть и досадные пробелы. кстати, XML API довольно строго бдит обратную совместимость через версии протоколов. При всех существующих недостатках — простая связка «обработчик события — скрипт — вызов API» у некоторых делает волшебные (с моей точки зрения) вещи с минимальным риском что-то поломать.
Или взять SDK — учитывая, что это почти прямая интеграция в код, возможности довольно интересные открываются. Опять же меньше риска грохнуть что-то по сравнению с лазить в базу.
Насчет неправильной последовательности шагов — Плеск скорее известен негибкостью — с размеченной дороги пользователю свернуть не дадут. Вот админ легко может в неправильном порядке что-то сделать, особенно если что-то самому крутить за пределами ГУЯ.
Если cPanel надо ставить на много серверов, то есть свои трудности: и ставится довольно долго, и нельзя установленные пакеты стандартизировать, на месте компилирует.
В Plesk у резервной копии может быть только одно хранилище (локальное или удаленное). Если залить не удается, то остается в локальном. Инкрементального бекапа в Plesk нет.
В cPanel тоже хранлище только одно — или локальное, или удаленное, но есть инкрементальный бэкап.
Unmanaged — продажа ресурсов, крутись с ними как хочешь. Неплохой выбор, если сам хорошо знаешь что тебе нужно и как это делать.
Managed — продажа знаний и умений. Цена в разы выше. Но с потребителя снимается очень много проблем — как ставить, как настраивать, как обслуживать, как чинить если сломалось. Неплохой размен, если время хочется посвятить чему-то иному (например, собственно развитию сайта или бизнеса)
Мы не пользуемся какой-то формальной формулой с коэффициентами, но составляющих три
— в каком сегменте пользователей это востребовано
— роль этого сегмента в нашем бизнесе
— влияние предложения на сегмент — удержание/приобретение/монетизация
Есть определенная модель из того, какие есть сегменты, какие и почему у них потребности, как эти сегменты взаимодействуют и соотносятся между собой.
Мы поддерживаем отношения с рядом компетентных клиентов в разных регионах, через эти группы мы можем проверять потребности в функции, в том числе отдельно в разных регионах — США, Европа и Азия в некоторых вопросах существенно отличаются.
Функция рассматривается с точки зрения упоминаемости (uservoice), с точки зрения влияния на бизнес (согласно модели) и вклада в стратегию, и с точки зрения проверки с избранными пользователями. Если есть расхождение между тремя точками зрения, то это повод насторожиться — что-то мы возможно неправильно понимаем. Собственно так мы в свое время и создали модель с разными сегментами — когда обнаружили противоречия в оценке пользы от ряда функций
Для нас голоса это тоже один из параметров. Всегда есть стратегия развития и всегда есть проблема «активного меньшинства», которые могут вывести в топ что-то нужное на самом деле немногим. Поэтому мы отдельно проверяем актуальность предложений через открытые источники и группы экспертов из числа текущих пользователей.
Я, к сожалению, не очень компетентен в Desktop, тут надо понимать что Parallels большой, направлений и продуктов много, поэтому за совершенно другую часть бизнеса компетентно ответить не могу. Открыв сайт, сразу вижу следующее про «через определенное время получить ответы невозможно» — видимо речь о политике бесплатной поддержки 30 дней (http://www.parallels.com/ru/support/priority/) с момента покупки/регистрации и политике 2х лет с момента выхода (http://www.parallels.com/ru/support/phone/). Если это не про ваш случай, то если есть номер тикета в службе поддержки, могу частным образом поинтересоваться что с ним.
Почти каждую неделю кто-нибудь приходит просить workaround типа «более быстрой лошади», и после уточнения этот запрос переформулируется или объединяется с другим, где описание сфокусировано на проблеме «хочу ездить быстрее». Необходимость объединять казалось бы разные предложения в одно и была первой причиной перехода на коммерческий тариф — понадобилась функция Merge.
Для Windows выбор версии PHP был почти всегда (ну то есть давно уже) — так уж удобно устроен IIS в этом отношении. А для Linux появился только сейчас — регистрируете через CLI свой бинарник PHP и потом можно его выбирать для сайтов (для FastCGI/CGI)
Просто у пользователя БД в Plesk появилась опция работать со всеми БД подписки. Права в БД будут настроены соответственно.
Ну и выделенные IP как средство дистанцироваться от плохих соседей.
facebook сделан так, как он сделан, потому в нем главное ваши «друзья», а не «вы».
«После входа вижу свой профиль, свои фотки, и прочее» — этакий нарцисс-мод получается.
Системная проблема возникает, когда менеджмент оторван от технологии и эксплуатации слишком сильно. Тогда менеджмент не видит эксплуатационных проблем или не адекватно оценивает их как «быстренько исправьте и побежали дальше». Если одновременно менеджмент должен гнать сроки, то отсупать разработка может только за счет качества — потому что его не видно. :) Тогда возникает кризис — разработка считает, что все плохо из-за менеджмента, а менеджмент думает, что разработка вечно ноет, а надо бежать.
Как любой долг, оно требует уплаты процентов. И если платить рассрочку не напряжно или проценты окупаются ранее полученной ценностью — то все нормально. А вот когда вся зарплата уходит на гашение кредитов — тут полный швах. А еще хуже — если на уплату одних процентов, даже без основного долга (как в историях про «русский стандарт») — это швах в квадрате. Вопрос гигиены, не более того. :)
Сам долг лучше бы мерить в количестве постоянных (recurrent) проблем, а не субъективном качестве кода. Я несколько раз наблюдал (и организовывал) смену команды разработчиков на проекте — и для всех живых проектов, абсолютно ВСЕГДА новые разработчики характеризовали старый код как «клоаку». Даже если команду сменить повторно — третья команда охарактеризует как «клоаку» творчество второй. :) Был даже пример обратной передачи — угадайте, что говорит первая команда про «что вы тут без нас наворотили?» :)
— «пока добежим, все вкусное съездят» — продукт готов, а рынок занят.
— инвестор не вытерпел, деньги кончились. не у каждого есть терпеливый и верный инвестор.
— заплутали в идеалах. сделали все правильно, не учли нюанс, переделали еще раз правильно, еще раз не учли, еще раз переделали. запутались, умерли.
— изменились требования. «пока расчет производился, объект расчета в норке скрылся»
Лучше крутить через официальные CLI и XML API — они покрывают довольно многое, хотя есть и досадные пробелы. кстати, XML API довольно строго бдит обратную совместимость через версии протоколов. При всех существующих недостатках — простая связка «обработчик события — скрипт — вызов API» у некоторых делает волшебные (с моей точки зрения) вещи с минимальным риском что-то поломать.
Или взять SDK — учитывая, что это почти прямая интеграция в код, возможности довольно интересные открываются. Опять же меньше риска грохнуть что-то по сравнению с лазить в базу.
Насчет неправильной последовательности шагов — Плеск скорее известен негибкостью — с размеченной дороги пользователю свернуть не дадут. Вот админ легко может в неправильном порядке что-то сделать, особенно если что-то самому крутить за пределами ГУЯ.
у сpanel действительно лицензирование через ip, но plesk от смены ip страдать вроде бы не должен.
В cPanel тоже хранлище только одно — или локальное, или удаленное, но есть инкрементальный бэкап.