Первое интервью мы взяли у Олега Никитина, технического директора компании «Страта Технологии». Олег очень подробно ответил на вопросы по системе управления сайтом «Twilight CMS»: в переводе "на Word" - больше 10-ти страниц. Но оно, уверены, того стоит - через ответы Олега система Twilight становится... понятнее. Благодаря чему ее выбор (или отказ от нее - система не претендует на удовлетворение всех возможных потребностей) становится достаточно осознанным. Отдельный интерес может представить заключительная часть интервью - там Олег довольно беспристрастно формулирует свое мнение о сложившейся ситуации на рынке CMS. 

 

 

Чтобы объективно сравнивать себя с конкурентами нужно их детально изучать. Могу предположить, что на дотошное их изучение времени нет ни у одного из разработчиков. Простое перечисление своих сильных сторон, с другой стороны (извините за тавтологию) превращается в глупые рекламные заявления. Например, наша изначально система является ориентированной на непрофессионального пользователя, удобно спроектирована в части управления сайтом и работа в ней для пользователя очень эффективна. Расшифровка этого в «суть» занимает некоторое время.

 

Мы используем традиционный windows-интерфейс, позволяющий эффективно работать в админзоне как мышью так и с клавиатуры. Активно применяются «drag&drop», «горячие клавиши» позволяют работать со структурой сайта, каталогов, форумов максимально интуитивно для пользователя. Все диалоговые окна сохраняют свои состояния. То есть, если редактор вставляет на страницу 30 изображений, то он никогда не задаст вопрос "а на чем я остановился", поскольку при возврате в диалог выбора будет сохранен фокус на последнем использованном файле. Есть масса вещей, которые экономят время, например, обычная для винды операция перетаскивания группы файлов. Только у нашей системы есть возможность вставить контент из ворда с автоматическим переносом всех вставленных в файл изображений на сайт и коррекцией ссылок. Есть и более продвинутые вещи, на которые тратится уйма времени контент-менеджера типовой веб-студии. Типовая ситуация: делается редизайн существующег сайта заказчика. Сайт собран, нужно перенести контент со старого проекта. Если просто «скопипастить» контент со страницы, содержащей ссылки на файлы для скачивания, то наш редактор автоматически скачает все эти файлы на сайт, скорректирует ссылки, почистит «мусорные» тэги. В реальной работе экономия времени очень серьезная. Основная наша цель при разработке “Twilight CMS” - сэкономить на обучение и поддержке пользователей, создав удобный и простой интерфейс. У нас это получилось.

Кроме удобства в работе при позиционировании нашего продукта мы говорим о “Twilight CMS” как о системе для быстрой и дешевой сборки сайтов. Сборка производится без программирования на PHP, Perl или других языках и это позволяет экономить на классе разработчика. У нас реализован полноценный макроязык, позволяющих создавать очень сложные комбинации, вставляя тэги один в другой. К примеру, берется картинка, загруженная на сайт в карточку товара. На неё автоматически накладывается водяной знак, затем она масштабируется до нужных размеров. Причем для масштабирования есть несколько режимов, помимо традиционного "вписывания в прямоугольник с сохранением пропорций" система имеет режим "заполнения прямоугольника с сохранением пропорций". То есть, какие бы соотношения сторон не были заданы, пустого места в прямоугольнике не останется. И все это в одну строку двумя макрокомандами. Учитывая, что можно дописывать свои макросы для конкретных проектов, каждый разработчик имеет возможность расширять функционал, не трогая ядро системы. Например, последнее время очень популярны интерфейсные плагины на JQuery. В «Twilight CMS» есть несколько макросов для вставки популярных плагинов одной строкой. При этом система сама контролирует, чтобы в тексте сложных проектов не оказались дублирующие включения файлов js. Естественно, все кэшируется от и до, соответственно количество товаров, новостей и прочих материалов серьезно на производительность системы не влияют. Был бы канал хороший.

Ну и третье - простота установки и обслуживания. В «Twilight CMS» нет необходимости использовать MySQL или другие СУБД, в нее встроен свой движок. Он прекрасно справляется с высокими нагрузками, а его надежность подтверждена многолетней работой ядра базы под нагрузкой в других продуктах, где наш движок используется именно как отдельная СУБД. Установка системы возможна практически на любом хостинге, поскольку мы намеренно избегаем использовать какие-то сторонние модули. Все что системе нужно для стабильной и быстрой работы на всех виртуальных хостингах уже установлено. Но главное, что разработчик может переносить сайт со своей Windows машины на Unix-хостинг простым копированием файлов по FTP.  Меньше затраты на админов, меньше потери времени, меньше вероятность ошибки. Это все снижает себестоимость продукта, то есть сайта, собранного на нашей платформе.

Да, есть еще практически никак не разрекламированный модуль статистики СтратаСтат. Позволяет смотреть интересные вещи, которые не представлены ни в одной системе анализа посещаемости - ни в наших, ни в западных. В частности, мы строим граф посещений визуально, что в совокупности с картой кликов (heatmap) дают полное представление об удобстве использования сайта и его эффективности как инструмента продаж. Статистика в табличном виде вообще этого представления не дает и оттого толком никем не используется.

 

 

Это не совсем правильная постановка вопроса, на наш взгляд. Никто от базы не отказывался, у нас есть база данных. Просто мы используем свою базу, а не реляционные СУБД типа MySQL, MSSQL или Oracle. Использование своего движка позволяет добиться большей независимости системы от доступных на хостинге опций, например, можно поставить систему даже на аппаратные устройства с linux с малым объемом памяти и простейшим самописным веб-сервером (сетевой маршрутизатор с линуксом внутри, хотя это больше из области фантастики, чем из реальной жизни). Плюс меньшая независимость от политики лицензирования производителей СУБД. Плюс простота создания резервных копий и установки + переноса сайта с места на место. Плюс снижаются требования к разработчику, который не должен владеть навыками сисадмина, чтобы управлять СУБД локально в процессе разработки. Последние два момента очень важны, ведь разработчику обычно приходится держать копию СУБД на своей машине (PC, Windows обычно), и гонять бэкапы MySQL (как наиболее часто используемой базы) на хостинг и обратно, на что тратится время и требуется определенная квалификация.

 

Ну и напоследок, мы не видим необходимости в MySQL на веб-сайтах среднего класса сложности. Сайт вообще по большому счету не содержит данных, которые удобно хранить в реляционных СУБД, поскольку большинство данных либо является блоками HTML/CSS/JS кода (лучше хранить в файлах), либо древовидными структурами (лучше XML для хранения которых пока ничего не придумано).

 

Распространенным базам данных наша разработка не проигрывает, если брать использование системы на проектах, под которые «Twilight CMS» рассчитана. Скорость выборки данных из таблиц зависит от количества данных логарифмически, т.к. используются те же алгоритмы, что и в других СУБД. Мы так же как они используем индексы, для быстрого доступа к данным. В общем, все по-взрослому.

 

 

 

Кэширование многоуровневое, что-то кэшируется в памяти, что-то - на диске.

 

Сначала кэшируются данные на уровне системных процедур. Например, если сделать в коде две одинаковых выборки данных, то вторая попытка возьмется из памяти, а не из базы. Затем на уровне логики работы сервисов. Любой макрос будет кэшировать данные, если это необходимо по логике работы. Например, получение PR страницы, получение курсов валют из ЦБРФ однозначно будут выполнены один раз за день, после чего данные будут браться локально из базы. Затем работает кэшированием на уровне результатов работы сервисов. Структура каталога товаров, обработанная единожды из "сырых" данных, хранящихся в базе, будет сброшена на диск в виде образа памяти. При повторном обращении к каталогу данные не будут браться из базы, а поднимутся в память в готовом виде. Ну и на четвертом уровне кэшируются уже сгенерированный html код страниц. Готовые и полуготовые страницы лежат в кэше и отдаются пользователям в ответ на запросы. Полуготовые - это если в странице есть некоторый небольшой кусок, который меняется от вызова к вызову и потому не может полностью быть закэширован, например, тот же курс валюты или зона с доступом по авторизации.

 

Это упрощенная схема. Каждый макрос использует свои собственные алгоритмы, которые "заточены" под конкретную задачу. В частности, все механизмы обработки картинок сбрасывают готовые изображения в кэш. Но если исходное изображение изменится, кэш автоматически перестроится. Вообще, процедура сброса кэша является очень продвинутой и сложной системой, поскольку сброс происходит всегда только тех страниц, которые были затронуты изменениями в базе. И если вы изменили только одну букву в конкретной новости, то сброшены будут только те страницы, где эта конкретная новость фигурирует.

 

Касательно накладных расходов - их нет, если иметь в виду дополнительные затраты на работу системы кэша. Ну, разумеется, процедуры кэширования пишут данные на диск, но они делают это "по ходу дела", когда данные уже готовы.

 

Вопрос достаточно интересный, поэтому ответ будет развернутый.

 

Я начну с технической стороны вопроса.

 

Поскольку на любой Windows машине всегда есть IE, то в реальности наличие альтернативных браузеров никак не препятствует пользованию системой. Мы еще ни разу в своей практике ни сталкивались с компаниями, которые не пользуются IE "из принципа" и заставляют пользователей работать в Опере или FF под страхом наказания. Хотя такие случаи, вероятно, есть. Равно как есть компании работающие под Linux или MacOS. Но на практике больше всех возмущаются отсутствием возможности работы в альтернативных браузерах начинающие веб-разработчики, которые не хотят запускать IE по "религиозным" соображениям. Но наша система рассчитана не на них. В первую очередь, это инструмент работы типового офисного сотрудника коммерческой компании, для которой сайт не развлечение, а инструмент зарабатывания денег. Любители похоливарить на браузерную тему нас, в принципе, не сильно интересуют. Их обычно отпугивает необходимость платить за CMS деньги. Поэтому мы следуем принципу "кто хочет - ищет возможность, кто не хочет - причину". В нашей компании используются совершенно различные OS, и нам удается эффективно работать со всеми проектами наших клиентов и с собственными сайтами. То же касается всех наших клиентов без исключения.

 

Нужно уточнить, что наша система - это не просто набор скриптов, который принято называть web-based CMS. Это полноценное Windows приложение, которое использует IE в качестве оболочки. Какие возможности Win32 в принципе невозможно реализовать в браузере на чисто HTML/JS/CSS уровне? Ну, конечно работу с реестром, с файловой системой, использование родных для OS интерфейсных элементов, работу с памятью. Плюс к этому есть ряд вещей, которые повторить в браузере можно, но придется потратить очень много сил по причине отсутствия структур и переменных определенных типов, невозможности задействовать другие уже реализованные компоненты OS, DDE обмен данными и т.д. Проще говоря, у разработчика Win32 есть все возможности операционной системы, а у web-разработчика - скудный набор HTML элементов для интерфейсного слоя и весьма ограниченный язык для реализации бизнес-логики.

 

Конечно, можно говорить об экзотических вещах. Например, у нас сейчас разрабатывается система, связывающая данные в админзоне сайта с Python приложениями в сотовом телефоне, и позволяющая привязывать объекты к географическому положению, чтобы затем выводить их на карте через Google Maps или любую другую подобную систему, включая собственный движок. Встраивается в админзону - "на ура", клиент вообще не думает ни о каких внешних компонентах - это просто часть его сайта и все.

 

Но можно спуститься к ежедневным потребностям. Самый простой пример - нужно эффективно организовать работу с несколькими тысячами записей через веб-интерфейс. Что мы получим в большинстве решений? Правильно - постраничную разбивку. Но с ней невозможно эффективно работать! Особенно, если приходится постоянно сортировать записи, делать выборки, входить в режим редактирования и возвращаться к тому месту с чего начали. Это издевательство над пользователем (постраничная разбивка) вообще присутствует только на вебе. И только потому, что нормально работать со списками внутри браузера никто изначально не планировал. Можно, конечно, организовать большой список в виде таблицы, манипулируя строками. Пытаться сортировать, фильтровать, импортировать и экспортировать его либо на серверной стороне, гоняя данные туда-сюда. Это будет долго, поскольку любой запрос к серверу это несколько секунд. А с использованием javaScript - будет безумно медленно уже за счет низкой скорости работы интерпретатора. Что дает ActiveX технология: возможность кэшировать данные на клиенте, фоновое удаление элементов без обновления всей выборки данных, сохранение состояния всех интерфейсных элементов, раскраска строк индивидуально для каждого редактора, импорт-экспорт во все возможные форматы, поддерживаемые на стороне клиента, перетаскивание местами и скрытие лишних столбцов с данными... Это нереально удобно реализовать на javaScript. Разработчики, которые не управляли сайтом изо дня в день, могут протестовать, но для редактора сайта разница в удобстве работы будет очень ощутима. Это как работа с почтой в Outlook и интерфейс mail.ru. Вроде бы все одно и то же, но какая разница в удобстве и эффективности работы!

 

Вот еще пример. Модуль рассылок. Обычно реализуется в виде скрипта, который в простейшем случае в цикле рассылает почту. Цикла, как правило, хватает на 200-800 писем, в зависимости от мощности сервера, после чего на web-based системе происходит таймаут. Более сложные решения требуют разработки серверной очереди, постоянного обновления данных в браузере для контроля "ну все там уже?" и т.д. При этом рассылкой занимается сервер и его еще за рассылки в RBL могут занести. Обработку всевозможных ошибок рассылки придется писать вручную - тоже мало приятного. В "Twilight CMS" реализован ActiveX компонент, который работает локально на машине клиента. Почту он будет рассылать именно с машины клиента, причем у него есть два режима - пытаться разослать письма напрямую (мультипоточно), или использовать учетную запись на выделенном почтовом сервере. Нажал кнопку и ушел пить кофе, а компонент будет просто работать и ничего в браузере при этом "дергаться" не будет, трафик минимален. Надежно, быстро, удобно.

 

Если учесть, что все данные в нашей системе, которыми обмениваются компоненты и сервер сжаты, да еще могут быть и зашифрованы - экономия трафика и времени загрузки данных налицо.

 

Да, некоторые из описанных вещей, возможно, можно было бы в том или ином виде реализовать на javaScript. Но как показывает практика, это работает а) медленно, б) ненадежно и в) не всегда кросс-браузерно. Таскания узлов деревьев (drag&drop) на JavaScript я лично нормально реализованного не видел. Речь, конечно, о больших деревьях, минимум от 500 элементов. Обычно все тормозит, дергается, легко попасть мышью не туда куда нужно, drag постоянно начинает выделение на странице (да, можно блокировать, но не всегда это хорошо). Сложно сделать сложную бизнес логику работы с деревьями, я выше уже писал об ограниченности языка. А у нас можно взять поддерево со 1000 вложенными ветками и элементами и перетащить в соседнюю папку - система даже не икнет. Переформатирование каталога продукции путем замены категорий и перетаскивания элементов решается вообще практически одной мышью. А если прибавить сюда полноценную работу drag&drop не только левой, но и правой кнопкой мыши, то мы получим очень удобный, и, главное, эффективный инструмент для ежедневной работы с сайтом.

 

Google постоянно экспериментирует с разными JavaScript решениями, в итоге их интерфейсы постоянно глючат, в большинстве случаев они несовместимы или не полностью совместимы с разными браузерами. Да чего далеко ходить - можно посмотреть, с какими недочетами работают в разных браузерах чисто HTML/JS интерфейсы системы продажи ссылок SAPE, или системы прогона по каталогам 1PS. Чтобы избавиться от этих проблем придется писать более высокоуровневые библиотеки, инкапсулирующие в себе проблемы несовместимости (например, использовать что-то типа медленного и кривоватого JQuery), либо переносить большую часть примитивных операций на сервер. Что в свою очередь означает лишнюю нагрузку и зависимость от дополнительных установленных на сервере модулей. Тот кто хочет – может всем этим заниматься, но мы выбрали для себя другой путь.

 

Немного рекламы ActiveX технологии от нас звучали бы так:

 

ActiveX компоненты позволяют работать в браузере эффективно. Ты точно знаешь, где нужно ткнуть мышью, через какие доли секунды раскроется контекстное меню. Ты визуально готов работать со знакомыми элементами интерфейса, и ты уверен, что на клик будет немедленная реакция. Ты получаешь в свое распоряжение все прелести обычного приложения, скорость и надежность. Глаза не разбегаются по экрану в поиске "как это сделать", ты просто берешь - и делаешь.

 

ActiveX компонент компактен, крайне быстр, легко интегрируется в другие приложения. В частности, "StrataStat "- модуль статистики - работает как модуль внутри CMS, на Web-based закрытой площадке по показу статистики и еще как standalone windows application. Компоненты обновляются легко и просто, причем всю систему обновлять не нужно - они обновляются независимо друг от друга. Разбиение интерфейсного слоя системы на блоки приводит к гораздо более продуманной архитектуре всего приложения, тщательной проработке интерфейсов взаимодействия компонентов. Зачем изобретать велосипед, делать дублирующую работу для достижения совместимости с кучей браузеров, поддерживать потом всю эту груду кода? Все уже написано до нас, нужно просто грамотно это использовать. Тем более что компоненты прекрасно работают практически на любой Windows (из числа тех которые в ходу) и практически 100% будут работать на любой Windows машине.

 

Теперь пара слов о стороне маркетинговой.

 

Да, к сожалению, на текущий момент реальный конечный пользователь в подавляющем большинстве своем не знает что такое CMS, не понимает что ему и зачем будет нужно в будущем при управлении сайтом, и кроме того совершенно не влияет на процесс выбора системы управления в начале проекта по сборке или созданию сайта. Между ним и производителем CMS стоит веб-разработчик, который оценивает систему под другим углом, зачастую совершенно перпендикулярным точке зрения конечного пользователя (девушки или парня в отделе маркетинга и рекламы). Учитывая достаточно сильные отличия претензий к софту веб-разработчика от запросов простого пользователя, зачастую система, не работающая под FF и другими альтернативными браузерами, даже не рассматривается в качестве потенциальной платформы для сборки сайта. Поэтому с точки зрения маркетинга продукта, конечно нужно чтобы система в них работала.

 

Поэтому планируем внедрить в ближайшее время в систему новый интерфейсный слой, который будет эту проблему решать. При этом мы не собираемся писать килотонны яваскрипта, или терять те удобства, которые в системе присутствуют сейчас. Всегда есть несколько путей для решения задачи. Мы постараемся найти оптимальный.

 

 

 

А зачем? У процесса разработки чистых win32 приложений есть масса недостатков, прежде всего это просто дороже. Вообще, постановка вопроса "а почему выбрана та или иная технология" не совсем корректна, на наш взгляд. Технология не имеет значения, это внутренний выбор компании-разработчика, опирающийся на те ресурсы, что у нее есть. Важно как именно будет выглядеть продукт с точки зрения пользователя, его потребительские свойства.

 

 

 

Технология ActiveX - это самый что ни на есть общепринятый подход для веб-приложений, рекомендованный компанией Microsoft. Когда я получал сертификат MCSD (Microsoft Certified Solution Developer) в наших учебниках по проектированию приложений были явно перечислены все недостатки Win32 приложений и преимущества ActiveX для использования в вебе. В нашей компании вообще широко используются подходы к разработке софта от Microsoft. Это позволяет компании зарабатывать деньги легче.

 

А то, что у нас в стране для веба используется преимущественно другой пакет технологий (PHP + MySQL) - это специфика российского рынка. В мире на самом деле используются много разных технологий и их связок, которые мы иногда по инерции воспринимаем как нечто необычное.

 

 

 

Ну не знаю, все разработки 99-2000 года в студии Лебедева и в Актисе были на технологиях Майкрософт, немного начинали копать Java. Наверное, нужно сказать, что с тех пор Microsoft потерял часть рынка, но никак не "начал продвигать себя". Но принципиальной новизны или преимуществ ни у одной появившейся с тех пор технологии мы не видим, «серебряной пули» нет. Поэтому на первом плане для нас не конкретная технология, а контекст её использования и результат.

 

 

 

В первую очередь, веб-студия может значительно удешевить свой цикл разработки сайтов за счет более доступных (и более дешевых) специалистов. Для работы с нашим движком у разработчика должны присутствовать навыки работы с HTML/CSS и немного понимания основ XML разметки. Нет необходимости знать такие языки как PHP, Perl, SQL, веб-мастер не должен уметь работать как системный администратор с базами данных. Конечно, он должен иметь детальное представление о том, как устроены веб-сайты. Если он сам разрабатывает архитектуру веб-проекта, то соответствующие навыки у него тоже должны иметь место быть. Но важно понять, что разработчик в нашей системе будет не программировать какие-то функции, он будет собирать из готовых блоков удобный в использовании сайт, для чего сугубо технические навыки отходят для него на второй план. Такие разработчики стоят дешевле и их легче найти на рынке.

 

Каждая студия, которая работает на рынке достаточно давно, знает, что некоторая унификация проектов позволяет снизить издержки на разработку сайтов. В случае "Twilight CMS" имея несколько готовых "шаблонных" решений можно создавать подобные сайты очень быстро, причем готовые блоки можно перетаскивать с проекта на проект с минимальными затратами. Стоит добавить, что мы предоставляем нашим партнерам готовые шаблонные решения и пакеты для быстрого развертывания разных возможностей на собираемых сайтах. Наверное, можно сказать, что вместе с CMS нашему партнеру предлагается некая идеология работы с веб-проектом, включая все стадии проекта - от его продажи до тестирования и сдачи клиенту.

 

За счет продуманной архитектуры система управления сайтом "Twilight CMS" позволяет разработчику легко переносить сайт со своей рабочей машины на staging сервер путем простого копирования файлов. Тут легко подключаются системы версионности кода, элементарно автоматизируется архивация проектов. Низкие системные требования и простота установки системы позволяют легко подключать к работе удаленных сотрудников, которым не нужно долго настраивать свое рабочее место и с которыми легко обмениваться данными.

 

В плане расширения функциональности система предоставляет разработчикам несколько возможностей. Это написание собственных модулей, возможность подключать внешние веб-сервисы на любом языке программирования. Разработчику доступны шаблоны отображения данных в админзоне, он может запросто заменить не устраивающие его клиента редакторы на другие, изменить расположение полей "по умолчанию" на экране на своё, либо ввести в систему новые типы данных для конкретного проекта. В принципе, никто не мешает вообще полностью написать свой интерфейс администрирования, заточенный под какую-то задачу, поскольку движок сайта и его административный интерфейс реализованы как независимые части. Это используется, например, в программном приложении Personal Logger, которое сделали наши американские клиенты. По сути, они встроили движок внутрь обычного Win32 приложения для создания механизма приема платежей за дополнительные услуги в своей программе, а систему управления реализовали в виде нескольких ASP скриптов.

 

Наша компания предлагает всем покупателям удобную схему лицензирования. Любая веб-студия или фрилансер имеют возможность сначала создать сайт, убедиться в его полной работоспособности, сдать работу клиенту, получить за работу деньги и лишь затем купить лицензионный ключ. Эта схема является абсолютно безрисковой для любого, кто работает в этом бизнесе. Также и любой клиент может сначала убедиться, что он в состоянии реализовать свои задумки на нашем движке и лишь затем он должен будет заплатить. Это даже не moneyback - это лучше.

 

Ну и, конечно, проработанная документация по системе и оперативная служба поддержки. Без этих составляющих не может быть речи о профессиональном продукте. Любому партнеру мы обеспечиваем максимально удобный и комфортный режим взаимодействия, чтобы каждый мог заниматься своим делом профессионально и эффективно.

 

 

Все будет зависеть от наших клиентов и партнеров. Система по большому счету уже давно не меняется кардинально, т.к. была изначально удачно спроектирована и последние несколько лет только обрастала дополнительными функциями. Вряд ли за ближайший год она сильно изменится, кроме разве что планов по совместимости с разными браузерами, о чем мы говорили ранее. Скорее всего, мы сосредоточимся на продвижении нашего продукта, а не на его разработке. Хотя, кризис на рынке веб-разработок может немного скорректировать планы, так всегда бывает.

 

 

 

История появления названия "Twilight CMS" достаточно простая. Еще в школе, когда мы начинали писать первые программы на gw-basic, мы с другом устраивали разные соревнования. У кого будет круче графика на экране и кто веселее назовет свою "компанию". Я где-то услышал название "Twilight Zone" (известный сериал шестидесятых, "The Twilight Zone" - мне понравилось название). Так, первые программы были помечены «копирайтом» "Twilight Zone Inc.". Позже, когда при разработке CMS возникла необходимость назвать хоть как-то рабочий проект, временно было взято за основу слово "Twilight" (сумрак). Нет ничего более постоянного, чем временное. Так система и называется до сих пор, хотя многие критики считают название не очень удачным из-за сложности написания и произношения. Последнее меня поначалу немного удивляло, поскольку в школе почти всех учат что диграф “gh” не читается, а «i» в открытом слоге дает «ай», в итоге вроде бы несложно прочитать название как «Твайлайт». Но потом привык. И чтобы не напрягать клиентов в последние годы мы чаще употребляем укороченный вариант TWL CMS. Хотя трехбуквенных названий на рынке и без нас хватает J.

 

Кстати, название этого фильма имеет много таких "последователей". Например, известный писатель-фантаст Сергей Лукьяненко в своих "Дозорах" оттуда взял свой "сумрак", по крайней мере он так писал в своем ЖЖ.

 

Пожалуй, одним из самых интересных вызовов в техническом плане было создание собственного движка для хранения данных, который бы удовлетворял жестким требованиям по быстродействию и надежности. Когда мы решили эту задачу, мы увидели новые возможности для бизнеса. Движок "на файлах", то есть система хранения информации без применения стандартных СУБД типа MySQL, оказалась очень кстати во многих внутренних проектах. Например, на этой схеме работает наш антиспам движок "SpamBeat", который получает огромное количество запросов, и стабильность работы мы отлаживали именно под реальной и высокой нагрузкой. Сейчас мы портируем скрипты для работы на сотовых телефонах, благо все разработки у нас получились реально кроссплатформенными.

 

Также любопытным опытом был "возврат к истокам" при реализации механизма отрисовки результатов голосований. Мы не нашли готовых решений, которые позволяли бы красиво рисовать обычную круговую (секторную) диаграмму, и реализовали свой рендерер с нуля. В общем-то, алгоритмы рисования прямых линий, сглаживания степенчатых эффектов по Брезенхэму, заливки замкнутых областей - это заря компьютерной графики. Ничего сверхсложного в этом нет. Зато результат понравился всем клиентам. С тех пор прошло много времени, появились новые технические возможности... Но я уверен, что команда получила совершенно необходимый опыт. Вообще, опытным программистам всегда интересна реализация разного рода непростых алгоритмов, поскольку обычно веб-программирование занятие рутинное и достаточно скучное. Это позволяет держать свои интеллектуальные навыки в тонусе.

 

Еще стоит упомянуть наш граф посещений сайта, который был придуман после длительной борьбы одних наших клиентов с анализом статистики на своем сайте. Кстати, статистика анализировалась с использованием встроенных механизмов Битрикса, уже не помню какой правда версии. Мы задались вопросом - почему западные производители анализаторов логов, таких как WebTrends могут реализовать визуальные инструменты для анализа ситуации на сайте, а для наших разработчиков - это слишком сложная задача и все просто вываливают циферки в табличном виде - типа кому нужно сам разберется. Ну, мы и взялись "сделать удобно". Придумали как отрисовать пути-дорожки, по которым ходят посетители, а затем начали разработку. Сейчас наш отдел аналитики ежедневно отсматривает ситуацию на нескольких десятках собственных проектов, и именно нарисованный на экране граф переходов позволяет быстро и осмысленно делать первые предположения о том, что и почему на сайте происходит. Вкупе с другими визуальными инструментами, такими как модный (и реально полезный) heatmap, показывающий, куда кликают посетители, можно достаточно тонко манипулировать сайтом как инструментом продаж.

 

 

 

Такие тоже есть. Например, до сих пор не решена задача поиска по сайту, в том виде как нам бы хотелось. Вероятно, соперничать с Гугл или Яндекс в вопросах поиска информации достаточно глупо, но свой поиск пишут все производители CMS, поскольку без него как-то неприлично. Но почти у всех качество поиска достаточно низкое, поскольку в 90% случаев базируется на полнотекстовом поиске MySQL, чьи алгоритмы слишком упрощенные. Поэтому мы, рассмотрев последние алгоритмические достижения в этой области, пока реализовали достаточно простой движок, решающий текущие задачи. Но, возможно, через некоторое время вернемся к вопросу о его переработке. Хотя, тут многое зависит от политики поисковых гигантов. Если они дадут возможность легко и просто интегрировать свой поиск в коммерческие проекты без рекламы, например за разумные деньги, то мы не будем тратить время на изобретение велосипеда, а лучше сделаем какую-нибудь новую удобную в работе полезняшку для пользователей.

 

 

Как к бизнес-проекту относимся хорошо. Агрессивное продвижение в последние год-полтора, так раздражавшее "конкурентов" практически сошло на нет. Зато теперь у них есть огромный рынок, и можно спокойно доводить инструмент до ума, зарабатывая при этом деньги. Если говорить до конца откровенно, на текущий момент кроме 1С-Битрикса реально зарабатывающих на CMS игроков на рынке нет, по крайней мере как это видится со стороны. Доля присутствия этой системы настолько велика, что все остальные могут как конкуренты рассматриваться очень условно, как бы это кому не было обидно и кто бы что про себя любимого не говорил. Тем не менее, другие продукты (и наш в том числе) имеют возможность перетянуть на свою платформу часть разработчиков в тех областях, где установка 1С-Битрикса дорога или их система избыточна по задачам проекта. Минусы их общеизвестны, и они фундаментальны. Многофункциональный продукт "для любого проекта" не может быть очень быстрым, малоресурсоемким или простым в настройке и установке. Поэтому более узкоспециализированные CMS смогут найти своего пользователей, если будут целенаправленно работать над улучшением своих потребительских качеств, как бы банально это ни звучало. Сделай грамотный, удобный и хорошо документированный продукт и люди к тебе потянутся.

 

Прежде всего, 1C-Битрикс и "Twilight CMS" не являются одноклассниками. "Twilight CMS" ориентирована на разработку корпоративных сайтов и типовых магазинов и каталогов средней сложности, хотя с её помощью можно создавать и сложные порталы, и другие решения. В частности на движке "Twilight CMS" реализована наша внутренняя система работы с клиентами (CRM, если хотите), система баг-трекинга и некоторые другие вещи, далекие от типовых веб-сайтов. Но мы предпочитаем позиционировать свой продукт более узко, поскольку, как известно, многофункциональные монстры каждую из своих задач обычно выполняют «так себе» и люди это прекрасно знают.

 

Мы можем предложить потребителям удобный и грамотно спроектированный интерфейс, разработчикам - простую модель разработки и хорошую модульность, владельцам сайта - возможность работы на любом дешевом виртуальном хостинге и крайне низкую стоимость владения продуктом. Ну и если в будущем владельцу сайта потребуется доработать свой проект самостоятельно, у него не возникнет большой проблемы найти грамотного разработчика, поскольку к ним предъявляются более низкие требования по квалификации.

 

 

 

Про некоммерческие продукты я говорить не буду, там все немного проще, чем в коммерческом секторе. На мой взгляд, процедура выбора коммерческой CMS несколько надуманна, поскольку на текущий момент на российском рынке среди коробочных коммерческих систем управления сайтом реально можно выбирать среди 6-7 брендов. Остальное - более или менее перспективные прототипы (поделки, если быть безжалостнее), которым еще предстоит доказать и занять. Среди известных систем можно достаточно легко выделить две основные группы: "1С-Битрикс" и "остальные". Если выбор падает на группу "остальные", то выбор прост: пишется описание веб-проекта с перечнем требований по функциональности, рассылается по производителям, которые оценивают а) возможность реализации проекта на их движке, б) стоимость лицензии, необходимой для проекта и в) диапазон стоимостей внедрения и поддержки проекта в будущем. Далее останется только пообщаться с представителями компаний по телефону, чтобы развеять свои сомнения и уточнить риски. Мне кажется, что данная процедура не очень сложна. Если же тот, кто выбирает систему управления не готов вникать в детали, вероятно, ему имеет смысл искать не продукт, а комплекс услуг по производству и поддержке сайта, то есть пойти в веб-студию и довериться профессионалам.