Здравствуйте, уважаемые коллеги, партнёры, клиенты, и просто интересующиеся. Меня зовут Григорий Добряков, я технический директор компании Юмисофт. Несмотря на то, что в компании я работаю уже восемь месяцев, это мой первый пост в наш корпоративный блог. Поэтому я тем более рад рассказать вам о наших новых идеях и новых достижениях.
Одна замечательная штука, о которой пойдет речь - это наш новый демо-сайт, который мы назвали UMI.CMS Text Version. Как родилась эта идея? Мы долго развивали наши демо-сайты, исследовали рынок, боролись с конкурентами, продвигали наши готовые решения для корпоративных сайтов и интернет-магазинов. А о простых пользователях, которым просто нужно опубликовать несколько страниц в интернете, мы незаслуженно забыли. Но мы исправились:
UMI.CMS Text Version - это быстрый старт: просто бери и делай. Теперь не нужно брать демо-сайт магазина и выпиливать из него лишние шаблоны. Теперь не нужно брать "пустой" сайт и ломать голову, как же создать свой первый шаблон на "Юми". Теперь всё это есть сразу. Ключ на старт! - и через 5 минут ваш сайт уже работает. Наполняйте его контентом, публикуйте статьи, подкасты, видеоролики. Всё что хотите. Просто поменяйте логотип, а заказать полное дизайнерское оформление можно и немного позже.
В следующих выпусках:
- уникальный кэширующий механизм для UMI.CMS, который многократно снижает нагрузку на сервер (да-да, наконец-то! но пока доступно только нашим бета-тестерам);
- драг-эн-дроп файлов в админку и Edit-in-place: забудьте о занудной кнопке "Загрузить", и просто таскайте файлы мышкой с рабочего стола;
- новый, реально веб-два-нольный инсталлятор и обновлятор системы, не хуже чем у Гугла.
Об этом всём - немного позже. Следите за нашими новостями :-)
Комментирование доступно только авторизованным пользователям.
Пожалуйста, зарегистрируйтесь или войдите на сайт.
А еще я вам примерно такое время назад говорил, что конкуренты умеют вставлять вордовский текст из буфера вместе с картинками. Есть куда стремиться ;)
Багам объявлен смертный бой. Не знаю насколько это видно со стороны, но уже несколько месяцев без автоматизированного functional and regression testing ничего нового в trunk не попадает. Если Вы понимаете о чём я.
Новый ваш флешовый загрузчик - это кошмар. Для начала, а почему, собственно, вы решили, что на компьютере потребителя обязательно должен быть флеш? Какую полезную функцию он там выполняет?
Далее.
1) без флеша что-либо загрузить вообще невозможно;
2) представляем сайт с большим количеством картинок; логично, что я хочу распределить их по подпапкам. Что получается: запускайм ФМ, ждем пока он что-то там инициализирет; видим совершенно бесполезные ярлыки; ищем где-то винзу мелкую кнопочку "папки", переключаемся в режим просмотра дерева папок; продираемся сквозь чащу плюсиков к заветной подпапке. И так на каждой странице. Повеситься можно.
Флешовый файловый менеджер позволяет решить некоторые принципиальные проблемы. Учитывая, что флеш установлен практически на всех компьютерах в интернете, мы решили обратиться именно к этой технологии.
Сказано: Благодаря готовому шаблону интернет-магазин на UMI.CMS готов к работе сразу после установки на сервер и заполнения товарами. Галереи в редакции Shop - нет. О назначении Галереи сказано: Создайте на своем сайте виртуальный фотоальбом или целую фотогалерею, для этого у вас есть удобный инструмент управления фотографиями. Про Каталог сказано: Каталог поддерживает любые типы данных в различных сочетаниях: создавайте неограниченное количество объектов каталога с неограниченными возможностями вложенности.
Из чего покупатель должен сделать вывод что для 1000 товаров ему потребуется модуль Галерея?
Да, в общем-то и про неограниченные возможности вложенности - ложь. Можно насоздавать разделов в Каталоге, затем в модуле Структура вложить их друг в друга (потому что Каталог не позволяет перемещать объекты каталога) и уже затем учитывать получившуюся вложенность в шаблонах и Каталоге. Но это мягко говоря неочевидно и в рамках модуля Каталог неограниченное кол-во объектов создавать нельзя. Можно создать Раздел и в него вложить объект. На этом возможности модуля Каталог заканчиваются и надо идти в Структуру.
http://tiny.dustweb.ru/
А мне кажется вы последний год только о таких пользователях и думаете. Вы не заметили тенденцию в том, что уже несколько постов начинаются с бодрого рассказа о том, как стало круто, просто и быстро... а в комментариях разворачивается дискуссия о том, как управляться с более сложными сайтами. И почему-то все чаще эти дикуссии напоминают футбол, а не конструктивный диалог.
Я не сомневаюсь, что Вы в теме. Если уж мы перешли на личности, возможно я по сравнению с Вами чайник, но поработав в коллективах 10-15 человек, сейчас предапочитаю совмещать роль менеджера и разработчика в собственной очень небольшой студии. А для создания и работы нормального(?!:)) сайта мне нужны только дизайнер, журналист и UMI. Но мы отвлеклись от темы...
Как Вы заметили, я заикнулась о тенденциях и направлении развития UMI (как мне кажется в сторону простейших проектов). Объясню, почему меня это так волнует... Несколько лет назад СЗ отвечала практически на все вопросы сразу, если не могла ответить, то предлагала какие-то обходные пути и вплоть до личной консультации ваших разработчиков.
Сейчас:
1) СЗ даже не затрудняется вникнуть в суть вопроса.. чтобы получить ответ на более-менее сложный вопрос теряются месяцы(!) переписки, повторных объяснений, доказывания что проблема в системе, а не в кастомизации.
2) На удобство работы разработчиков публично забили (см. комментарии в блогах о скинах).
3) В погоне за самый удобный EIP, выпустили абсолютно сырой модуль магазина.
4) Активно пропагандируется XSLT - да, там много чего замечательного, но тоже для простых проектов.
В результате, когда меня коллеги спрашивают о том, стоит ли браться за тот или иной проект на юми, все чаще приходится отвечать, что я бы взялась только с гарантией личной поддержки Котырева. Григорий, Вы лично готовы гарантии технической поддержки сложных проектов дать? Или успокоиться на том, что UMI предназначена для типовых проектов, а для порталов надо искать другое решение?
В любом случае, это не та тема, которую следует обсуждать в комментариях в корпоративном блоге. Приходите к нам на форум. А жалобы на работу СЗ, пожалуйста, направляйте по этой ссылке http://www.umi-cms.ru/company/svyaz_s_zimnim/ с обязательным указанием номера тикета.
Все жалобы рассматриваются руководством в установленном порядке.
И как раз XSLT помогло расширить возможности UMI.CMS. Глядя на то, как некоторые разработчики пишут php код в tpl шаблонах - обидно за такое отношение к конечному клиенту. А потом при обновлении все ломается и клиент начинает ругать UMI.CMS заодно с разработчиком.
2) Вы не совсем логичны: пхп код в шаблонах не должен ломаться при обновлениях, хотя бы потому что шаблоны не обновляются. Т.е. ломается он из-за того, что функции документированные в api работает по-разному при переходе с одной версии на другую. (Что писать код надо не в шаблонах, а в классах это понятно, и где писать уже давно понятно, спасибо документации и Ефиму Жилину :))
3) Плохое отношение к клиенту - это когда берутся, а доделать не могут. А когда сделано и работает - все клиенты довольны. Поэтому я тут и распинаюсь, у меня же все эти вопросы не случайно появились.
На замечание Сергея ниже: Да, хотелось уже поставить точку, вроде и так все понятно. И ЮМИ мы довольны :))) если бы это было не так, нас бы тут просто не было.
2)php кода в шаблонах вообще не должно быть.
И ломается он не из-за обновления как такового, а из-за качества кода.
3)не соглашусь. Клиент в силу отсутсвия необходимых знаний принимает сайт. Но он не знает, что ему написали в шаблонах, в коде, не всегда знает, что нужно просить при сдаче включить отображение всех ошибок в коде. При сдаче работает, а после обновления нет - причина бывает в коде, который написал разработчик сайта.
2) Ломается он, повторяюсь, из-за того что функции API выдают разный результат от версии к версии. Хотя сделаю оговорку, очевидно это было при переходе с 2.6 на 2.7. На 2.8 старые сайты предпочитаю не обновлять - мне не хочется портить зрение в баттерфляе. Поэтому и судить не буду.
3) Клиент и не должен принимать код, он должен получить стабильно работающий, удобный в использовании сайт и ему все равно вообще на чем он сделан. А прежде чем рассуждать о грамотности партнеров, объясните мне каким местом писали модуль "Блоги" например.
2) Ломается как раз потому, что разработчик "поленился" сделать правильно. Обычным макросом.
3) Правильно, клиент не должен принимать код, но и разработчик не должен скрывать свои баги при сдаче сайта. По поводу какой весрии модуля Блоги Вы пишите?
Дорогие программеры!
Несколько замечаний-пожеланий перед выпуском следующих заметок:
- уникальный кэширующий механизм для UMI.CMS - а как вы его включите? В коде файлов (например, в ЮМИ 2.8.х в папке /classes/system/subsystems/models/hierarchy/ и /classes/system/subsystems/models/data/) не содержится строк, задействующих кэширование!!! Даже правильнее сказать, что в коде ошибки и местами кэширование включили, а по большей части забыли. Именно поэтому получаем странные результаты: при выключенном кэшировании на вывод 1 страницы идет 80-100 запросов к БД (в зависимости от типа страницы), а при включенном - 70. Ну и кому это поможет? Кэширование презназначено, что уменьшать запросы к БД до 2-3 максимум! Проверьте, пожалуйста, весь код в папке /classes/system/subsystems/models/data/ и задействуйте кэширование! Сейчас оно не работает! Аналогично со статикой!
- драг-эн-дроп файлов в админку - это круто! только это полмеры, т.к. помимо того, что надо файл загрузить, требется еще поставить на него линк в тексте. Поэтому придумывайте соответствующую кнопку. Т.е. надо: выделил текст, нажал кнопку, выбрал файл, он автоматом загрузился и залинковался в тексте.
- новый обновлятор системы - а чем это поможет? кому? Даже umi-cms.ru это не принесет существенной пользы, т.к. слишком много кастомизации будет затираться.
Отвечаю по-порядку:
1. Не ищите кэширование. Как я указал в тексте, оно доступно пока только определённым бета-тестерам. А в динамическом режиме ни о каких 80-100 запросов на страницу не может быть и речи: 10-15 на страницу - вот наша цель, и мы знаем как её достичь.
2. Такая кнопка будет. Но не забывайте, что кроме ссылки в контенте, есть ещё куча мест куда можно "драг-н-дропнуть" файл: например фотография товара в магазине.
3. Хоть это и выходит за рамки топика, чтобы удовлетворить Ваше любопытство, приоткрою суть дела: разве вы боитесь, когда ваш любимый браузер скачивает обновление для плагинов? Разве обновление антивирусных баз вас напрягает? Разве Windows вынуждает вас бэкапить всю систему перед апдейтом? Нет, нет и нет. Вот и UMI.CMS будет обновляться так же: полностью автоматически, тихо, и ничего не ломая. Больше ничего не скажу - наберитесь терпения :) про обновлятор будет отдельный пост.
- Модуль "Шаблоны данных": редактирование: чтобы сохранить, нужно после добавления новой группы и полей снизу нажимать "Сохранить" где-то сверху (если еще снизу кнопки "Сохранить" добавить, то станет понятнее)
- Модуль "Шаблоны данных": редактирование: пустая группа не удаляется в последнем релизе (спрашивает удалить или нет, а потом все равно не удаляется)
- Ограничьте ширину верстки, даже на обычном широкоформатном ноуте неудобно работать со многими формами админки
- В нескольких местах видел (например, при добавлении нового пользователя): если забыть ввести обязательное поле (имя где-то внизу) и попытаться сохранить, то выведет ошибку и ФОРМА БУДЕТ ПУСТОЙ, нужно как-то бережней относиться к пользовательским данным и сохранять то, что было введено (кроме паролей)
- в визуальной админке не хватает иногда переключения в режим html
Внутренняя админка произвела довольно плохое впечатление...
Хочу:
1. Забить на UI, того, что есть - вполне достаточно, за исключением файлового менеджера, но и к нему привыкаешь ))
2. Реализовать принципы построения системы к 100% хмл. Имеюю ввиду следующе... Любой шаблон данных должен иметь н-количество полей, любое поле тоже может содержать н-количество полей. Группы тогда станут не нужны, т.к. любое поле может являться группой.
3. Возможность фильтров по полям с одним и темже идентификаторм, но разных Обжект тайпов.
4. Доточить SMC, отдельную доку по нему, отдельный апи к нему, не ограничивать SMC админской частью.
А так впринципе, лично мне по большей части всего, что счас есть, вполне достаточно для реализации своих скромных потребностей.
Если вы сравните количество комментариев к разным постам ваших блогов, посвященных всякой ерунде и PR, то увидите, что вашим клиентам нужно пространство для ОТКРЫТОГО ОБСУЖДЕНИЯ продукта.
Формат СЗ устарел, он не помогает РАЗВИВАТЬСЯ.
Поражает упорное нежелание делать форум аналогично http://forum.dle-news.ru/ или другим системам с закрытым\открытым кодом.
Пожалуйста, что надо сделать, чтобы вы воплотили это именно в таком виде форума, а не в том, каком считаете нужным?
Второе – программные модули UMI содержат немалое количество ошибок и недочетов.
Опыт минувших 3 лет показал, что это эта тенденция неизменна и неисправима.
Единственное, что я слышал в ответ на любую критику кода (и вышенаписанные комментарии это подтверждают) – это разведение воды или ответный наезд.
Я вижу схему такой: человек нашел недостаток, описал его на форуме. 10 программеров вне UMI предложили варианты решения, написав конкретный код. Переругавшись друг с другом, они все же нашли несколько удачных вариантов. СЗ выбрала наиболее продуманный вариант и сказала – да, сейчас исправим и внедрим в релиз.
Это мечта?
Про комьюнити, исправляющее баги и про форум DLE я уже отвечал вам в письмах. Мои ответы вряд ли изменятся, если вы будете задавать те же вопросы в комментах блога.
Мы проектируем закрытый раздел сайта для сообщества, но этот проект для нас не такой срочный как работа над CMS или Cloud. Если кто-то готов предоставить нам помощь в создании комьюнити - мы будем рады.
Пока для общения сообщества можем предложить наш форум http://www.umi-cms.ru/support/forum/
Какая помощь сообщества была бы наиболее полезна:
1. У нас есть потребность в евангелистах и модераторах. Отвечать на вопросы и недопонимания новичков на форуме umi-cms.ru и на других форумах и сайтах.
2. Помощь в постановке задач и проектировании официального сообщества. Что нужно людям, кроме форума, какие приоритеты?
3. Наша wiki - http://wiki.umisoft.ru , туда мы (СЗ) вносим различные заготовки, описываем решения типовых и кастомных задач, и т.п.
Вот о каких сообществах про UMI мы знаем на сегодняшний день:
1. Наш форум и wiki
2. http://community.livejournal.com/umi_tips/ (это вы)
3. http://umihelp.ru и http://twitter.com/#!/umihelp (это тоже вы?)
4. http://umi-cms.spb.su
5. http://umisupport.ru
Сейчас таких зачаточных сообществ несколько, а контента и участников в каждом мало. Если бы их объединить, вышло бы что-то толковое.
Если довести до ума один из ниже приведенных неофициальных сайтов сообществ, то мы его анонсировать на нашем сайте и направить туда трафик.
1. пытался участвовать в жизни официального форума UMI, но из-за неудобства использования и отслеживания изменений, моя активность сошла на нет
2. сам этими вопросами задаюсь, пока гениальных прорывов не было
3. wiki стала расти и вам за это большое спасибо, другое дело что бывает сложно найти там решение, которое тебе надо
По поводу сообществ:
2. и 3. пункт это я
4. Прекрасный сайт, мы уже обсуждали сотрудничество, на этапе создания http://community.livejournal.com/umi_tips/, но пока далеко в этом направлении не ушли
5. Жаль, что он не открылся, но так как он нам все равно сейчас не поможет, я сделал http://umihelp.ru/forum. Надеюсь, он сможет помочь людям работающим с UMI
С появлением 2.8 выявились баги, которых не было в прежних версиях (типа круто - ядро переписали, теперь будем разгребать это до выхода версии 4.0), а их решение занимает у СЗ месяцы.
Сомневаюсь, что СЗ будет поддерживать форумы - печальный опыт на действующем сайте это доказал.
Это тупик бизнеса, надо искать другую стратегию развития - осмелюсь заявить.
1. Ошибки в самой системе(избежать их можно либо много тестируя, либо очень скрупулезно проектируя систему перед программированием)
2. Недостаточная освещенность вопросов использования системы (при настройке или при использовании). Тут нужны доступные материалы, поясняющие как можно делать, а как нельзя.
По сути форум и различные сообщества могут решать (и то отчасти)лишь вторую причину. Первую задачу решить сообщество не может, оно может сигнализировать о наличии проблем с проектированием системы (вылившиеся в ошибки ядра и т.п.)
Стратегия развития соответственно лежит в плоскости наличия достаточного количества ресурсов (человеко-часов) для развития конкурентоспособной системы. А вот откуда будут браться человеко часы? Тут либо из сообщества, либо из отдела программистов UMI, либо они будут налаживать взаимоотношения и работать сообща(как третий вариант). Ведь в итоге UMI делается для нас, для пользователей и разработчиков))
1) Растет число продаж и внедрений UMI (и это хорошо)
2) Многие разработчики пробуют делать свои первые сайты на UMI после долгих лет использования других CMS со спагетти-архитектурой (к которым относится 90% всех популярных продуктов, известных с конца прошлого века).
Обучение таких разработчиков требует больше времени и нервов, чем обучение людей без опыта с другими CMS.
3) Баги и недостатки документации, безусловно, вызывают часть запросов в СЗ, но их доля падает.
Создание сообщества, конечно, позволит находить ответы на вопросы и разбираться в системе быстрее и без обращений в СЗ.
Ответственные?
Сроки?
Или это все демагогия, и компания все равно будет идти так, как ей надо, а не пользователям?