Вход • Регистрация

Ошибки новых версий

  • 22 апреля 2013 г.
  • Для меня диафан является основной системой. 99% сайтов разрабатываем именно на любимой cms. В последнее время так уж получается, что становится все больше и больше функционала в системе (порой спорного) - это хорошо. Но зачастую функционал этот оказывается по факту нерабочим... Ошибки, баги, мелкие правки и тд - все это становится неотъемлимой частью новых версий диафана. Последний пример: функционал редиректов... Сделали, в системе присутствует, уже почти как месяц версия 5.2 - в итоге столкнувшись впервые и опробывав функционал обнаружил ошибку - отправил тут же в ТП ( опять таки в последнее время отправляю частенько). Оказалось что просто не работала даже функция сохранения...
    Вот и встает вопрос: что дальше? меня лично как пользователя системы очень настораживают постоянные ошибки в системе, недочеты и тд. Может быть стоит разработчикам подумать о векторе обновлений? Может не стоит при каждом обновлении внедрять все новый и новый функционал, а сосредоточится на стабильности? У кого какие идеи на этот счет, хотелось бы услышать мнения и пользователей и разработчиков.

    • 22 апреля 2013 г.
    • Усложнение системы - ведет к бо'льшему количеству ошибок.
      А разветвленность функций к тому, что сложнее оттестировать, чтобы отработать все варианты.

      Наверное, пора переходить к выпуску стабильных версий раз в год!

      А за полгода выпускать бета-версию с глобальными новинками. С "беты" и спроса по стабильности меньше!
      За полгода ее оттачивать, добавлять незначительные изменения и выпускать как стабильную версию.
  • 22 апреля 2013 г.
  • А мы только за. Вы думаете, что если к осени вот тут не будет предложений, нам заняться будет нечем? Отнюдь! Мы вылижем то, что есть. Застабилизируем, так сказать.
    А так нам деваться некуда: приходит предложение, за него голосует полста человек, мы его должны по традиции делать. Причем в последнее время предложения все масштабнее, а описание все скуднее. "Хочу ракету" и "как хотите, так и делайте". И что нам остается? Потестировали как смогли и успели - нате бету...
    Нет, мы не оправдываемся, но в новом необкатанном функционале без косяков сложно обойтись...
    Вот самая стабильная версия какая считается? 4.5. С учетом того, что начали мы коробку выпускать с 4.0-4.1. Вылизали таки за пару лет, с помощью пользователей, без них никак.
    Теперь вот 5.х по тому же пути. Задача только процесс обновлений может наладить. На самом деле выпускать весной бету и держать ее в этом статусе до осени? Затем переводить ее в stable, а в это время выпускать очередную бету?
    • 22 апреля 2013 г.
    • Понятно, что без ошибок никуда, однако я в корни несогласен с тем чтобы с помощью пользователей это все происходило. Нет, конечно без пользователей никуда, с помощью пользователей система совершенствуется. Но все-таки я считаю, что процент ошибок найденных пользователями надо сводить к минимуму. Это все-таки коммерческий продукт.
      Что касается хотелок, которые вы "должны" реализовывать: лично я думаю что не стоит в обязательном порядке реализовывать все хотелки лишь потому что проголосовало больше всех человек. Порой проскальзывают действительно "Хочу ракету" и набирают немало голосов. Означает ли что это действительно необходимо? Не думаю. Ну набрало предложение полсотни голосов, означает ли это что надо реализовывать в обязательном порядке? Ведь многие, уверен, жмут плюсы просто ради того, чтобы побольше функционала было, не вчитываясь в суть предложения, не внося свои мысли и идеиб предложения... Возможно стоит учитывать "голосования" как некий вектор или сигнал, затем уже вы как разработчики и профессионалы принимаете окончательное решение о внедрении того или иного функционала в систему.
      Все это я тому чтобы система приходила к пользователю в стабильном виде изначально. Лично я готов пожертвовать новым функционалом системы, ради этого.
      Прошу команду диафана не воспринимать мои сообщения как обвинения и тд. Все это от желания сделать систему лучшей или по крайней мере двигаться именно к этому.
      • 23 апреля 2013 г.
      • Цитата
        я в корни несогласен с тем чтобы с помощью пользователей это все происходило.
        А с чьей же еще помощью это должно происходить??? Ведь пользователи эти задания дают!

        Если бы мы полностью отвечали за внедряемые модули, придумывали их, назначение их задавали - тогда да! Мы создали, мы разработали, мы оттестировали, зная что и как там должно быть. Потом приходят пользователи - начинают использовать. Собственно, если говорить по фактам, то вот
        Цитата
        Последний пример: функционал редиректов...
        не работает, Вы говорите. Я видел этот функционал на стадии альфа тестирования. Я читал предложение в вишлисте про него. Но я не до конца понял, зачем он нужен, что хотел его автор, и как его надо тестировать. Я сам его покрутил, потыкал - ну вроде работает. А дальше пусть его автор предложения тестирует и его единомышленники, которые плюсики поставили. Вернее нет, не совсем так. Гораздо правильнее, когда автор предложения изначально пишет в пожелании полноценное ТЗ, для чего модуль, как он должен работать и что делать. Потому, что если касаться SEO-продвижения, для чего и нужен этот модуль, то не все в тонкостях продвижения разбираются идеально, особенно программисты. Надо разжевывать, иначе будут делать вслепую, тестировать наугад, и тогда будет глючить.

        Вы предложите не делать модуль совсем, чем делать его сырым? Вы же сами дали ответ:
        Цитата
        Лично я готов пожертвовать новым функционалом системы, ради этого.
        Вот и не пользуйтесь добровольно сырыми свежевыпущенными модулями. Есть же ядро функционала, которое работает давно и работает стабильно. Добавление страниц, новостей, товаров и пр. Я много раз говорил, что если есть глюки, то они есть только в необкатанных новейших модулях. Все остальное работает хорошо. Даже можно сказать так: если использовать 5.2 в рамках только того функционала, что был в 4.5 или даже 5.0 и 5.1, то это будет наистабильнейшая цмс
        Я лично считаю, что для пользователя, сделавшего предложение, лучше сделать сырой модуль и затем его оттестить, чем не делать его вообще.
  • 23 апреля 2013 г.
  • Пожалуйста: /wishlist/show963/
    Что это? Весь API Яндексе внедрить? По всей CMS его размазать?
    Хорошо, хоть у нас сообщество разумное, плюсиков не понаставит зазря
    Но тем не менее, глас народа вот он
  • 23 апреля 2013 г.
  • Впрочем, Вы правы!
    Буду вносить предложение о переработке раздела "Пожеланий" в следующем виде:
    при создании предложения требовать заполнять поля "Тип пожелания" (переработка, доработка, разработка с нуля, добавление функционала в текущий модуль), "Назначение модуля", "Задачи модуля", "Функционал модуля", "Тема на форуме с предварительным обсуждением потребностей" и если что-то не заполнено, предложение не создавать и не принимать в рассмотрение.
    • 23 апреля 2013 г.
    • В пожеланиях нужна обратная связь от разработчиков!
      Если непонятно, что и как реализовывать, то надо там же и уточнять.
      Может, конечно, небольшой базарчик получиться, но в споре рождается истина!
      • 24 апреля 2013 г.
      • Вопросы всегда те же самые и в большом количестве: зачем, для чего, как должен работать и т.д.
        Будет не раздел пожеланий, а килотонна контента с обсуждениями.
        Гораздо проще, если создающию сразу будет писать поподробнее.
        • 24 апреля 2013 г.
        • Как компромиссный вариант - обратная связь с автором пожелания...
    • 25 апреля 2013 г.
    • Все верно. Четкое ТЗ с ответственным автором. Без него не принимать, или чтоб модерацию не проходило по неполноте информации.
  • 23 апреля 2013 г.
  • Цитата
    А с чьей же еще помощью это должно происходить??? Ведь пользователи эти задания дают!

    Виталий, я говорю о том, что к пользователю должно приходить хотя бы работоспособный модуль или функционал... Который просто хотя бы работает. Логику поведения, какие то мелкие правки, все это конечно необходимо делать и править с помощью пользователей и конечно же лучше всего тут поможет тестирование что говорится в боевых условиях. Приведу вам опять пример, который если честно сподвиг на эту тему: функционал редиректов - он просто даже не сохранял значения, хорошо из ТП ребята быстро ответили как всегда, поправили. Клиент (который как раз и зацепился за этот функционал) обрадовался, но ненадолго. Оказалось что теперь на каждой странице автоматически вставляется одно и тоже значение редиректа.. На всех страницах, а при попытке отредактировать страницу возникает ошибка о невозможности сохранения по причине дублирования url редиректа.. И вы предлагаете просто не пользоваться сырыми модулями? То есть вы приходите покупать машину - вам рассказывают что в обновленной версии теперь адаптивные фары, круиз-контроль и тд. Но тут же говорят что лучше конечно всеми новыми фишками не пользоваться, а просто ездить (ведь машина то едет).

    Вот с изменением раздела Пожелания полностью согласен с вами, Виталий. Я думаю это упорядочит предложения, и вам как разработчикам будет проще понимать суть имея достаточную информацию (а не как сейчас "внедрить API"). У пользователей появится некая ответственность за внесение предложений.
    • 23 апреля 2013 г.
    • Цитата
      функционал редиректов - он просто даже не сохранял значения
      Это косой. За него оправдания нет. Только сбор концентрации на будущее.

      Есть еще что-то подобное в других модулях, кстати? Чтобы мы тут у себя эту тему на вид поставили.
      • 23 апреля 2013 г.
      • Критических ошибок в других модулях пока не замечал). Надеюсь их не будет.
  • 23 апреля 2013 г.
  • Я бы на месте разработчиков не принимал бы все предложения пользователей. Вот, например, интеграция редхелпер...на кой черт пихать это в цмс? Понятно, что много плюсов набрало, но все же...
    • 23 апреля 2013 г.
    • Согласен, редхелпер (как впрочем и вебэффектор) на мой взгляд лишние в коробке.
      • 23 апреля 2013 г. , редакция: 23 апреля 2013 г.
      • Создаём предложение по выкорчёвыванию RH из пакета?
        Минусы я в соответствующей теме написал.

        А вот про вебэффектор, я пока ничего не скажу. Может быть и полезен - не надо парится очень сильно создавать отчёты для клиента, сам заходит и видит как дела обстоят. Если не сможет понять выданную там информацию может быть обучить можно чтобы понимал.
        Ну это так моё виденье полезности - может я заблуждаюсь.
        • 23 апреля 2013 г.
        • ну вообще вебэффектор... почему не руки, сеопульт и тд? Системы разные есть, почему именно вебэффектор (может отчисляет % диафану))). А если серьезно, считаю встраивание таких сервисов неоднозначных в коробку CMS уж точно не первостепенным делом. Да и сервисы такие по сути к CMS отношения не имееют. Ведь никому же не придет в голову встраивать Метрику или Аналитикс в систему? или Директ и Адсенс?
          • 23 апреля 2013 г.
          • Ну предложение звучало следующим образом... "Интеграция онлайн-консультанта.
            Внедрить консультанта".
            Причем в дальнейшем звучали разные версии консультанта, вплоть до собственной разработки диафана. Внедрен был редхелпер. Думаю в основном из-за очень хорошей партнерской программы. Зарегистрировавшись на редхелпере через диафан, клиент бессознательно передает код партнера. В принципе, страшного ничего, но на мой взгляд, не совсем политкорректно так поступать. К тому же, изначально отсутствовала любая другая возможность добавить свои данные, кроме как зарегистрироваться по партнерскому коду Диафана. Позже подправили. С вебэффектором такая же фигня.
            • 24 апреля 2013 г.
            • По имеющийся у меня информации, Редхелпер был внедрен первым из-за того, что у него вполне приличная функциональность бесплатно. Т.е. им можно пользоваться, консультирую людей. А за абонентскую плату можно получить доп.функции. В отличие от того же раскрученного лайвтекса, где бесплатная версия вообще не подразумевается.
              Почему я говорю "внедрен первым", потому, что мы предполагали внедрить несколько сервисов, вкладками. Пока сделали один.
              Далее два вектора развития событий: либо мы вообще убьем этот модуль, как раздражающий наших пользователей, либо мы добавим еще сервисы.
              Зачем вообще мы его сделали и сделали в коробку? Для конечного пользователя. Опытным разработчикам это все кажется баловством, но у нас очень много пользователей, начинающих, которые делают сайт для себя. Они задают множество примитивных вопросов и им удобно, когда все просто, на виду и легко настраивается, без влезаний в код.
              • 24 апреля 2013 г.
              • Ну вот с RH косячёк вышел. Кастомную кнопку нельзя делать. То что сделано сейчас, выходит боком, если пользоваться больше 20 дней, и продолжать не платить.

                Предложение уже звучало, сделать для тех кому оно надо помойку, где можно найти готовые решения интеграции чего либо эдакого в виде модулей скачать залить и нажать кнопку установить.
          • 24 апреля 2013 г.
          • Дело не первостепенное, но и не особо сложное, сделали между делом. Вебэффектора почему первым? Ну так получилось, с ними первыми договорились. Если бы сделали сеопульт, Вы бы спросили, почему Сеопульт первый? Мы планировали сделать вкладками и другие системы для продвижения, и Руки, и Сеопульт. И кстати говоря, мы также думали о внедрении сервиса по управлению кампаниями в Яндекс.Директ - почему нет? Это удобно: вот мой сайт, зашел в админку и там тебе и продвижение, и реклама, и консультант, и комментарии с заказами.
      • 24 апреля 2013 г.
      • Лишние - не ставьте галки при инсталле Места занимает копейки, а желающие использовать все-таки есть
  • 25 апреля 2013 г. , редакция: 25 апреля 2013 г.
  • Проблема вот в чём: через плагин для изображений добавляю картинки на страницу. Всё бы хорошо, только при перемещении внутри страницы этих картинок появляются дублирующие без тегов. Приходится через html всё время руками править. Картинок добавляем много, поэтому надоело. Версия 5.1
  • 25 апреля 2013 г.
  • Вставлю свои пять копеек. Почему бы все эти не штуки/прикрутки не поставить на отдельные комерческие рельсы в качестве доп функционала, захотел поставил из магазина приложений, захотел коробку — ставь коробку. Да и понятно будет что реально из доп функционала востребовано (даже по тем же параметрам установки модуля), а что реально было только для галочки или по прихоти юзера.
    • 25 апреля 2013 г.
    • На мой взгляд предложение Петра как минимум стоит рассмотреть разработчикам. Ведь получится реальный полигон для обкатки модулей и дополнительного функционала. Можно подумать над внедрением в Магазин дополнений, где могут быть как и коммерческие продукты, так и бесплатные, как от пользователей так и от разработчиков (с особой пометкой). А далее как уже судя по установке/скачиванию модулей можно принимать решение о внедрении в коробку..
      Ну и конечно если пойти таким путем, необходимо подумать над схемой внедрении доп функционала, чтобы это было достаточно легко сделать конечному пользователю(аналог модульности cms, которую чуть выше описывал Denis).
      Цитата
      Для конечного пользователя. Опытным разработчикам это все кажется баловством, но у нас очень много пользователей, начинающих, которые делают сайт для себя. Они задают множество примитивных вопросов и им удобно, когда все просто, на виду и легко настраивается, без влезаний в код.

      Как раз решается проблема: простые пользователи смогут запросто доустанавливать себе необходимые модули + сама система не разрастется до огромных размеров несвязанным с самой cms функционалом.

Новости

  • 24 апреля, среда
  • В новой сборке совершили революцию в структурировании кастомизированной информации в шаблонах, добавили авторегистрацию пользователей, усовершенствовали защиту от спама, актуализировали накопительную скидку, а также улучшили производительность и стабильность работы системы.
  • 12 января
  • После выхода сборки 7.1 мы выпустили уже три патча, в каждом из которых улучшаем административную часть сайта. Сборка DIAFAN.CMS 7.1.3 уже доступна к установке. 
  • 15 декабря 2023 г.
  • Подводим итоги 2023 года. Выпустили новую сборку DIAFAN.CMS 7.1.1, вводим новые тарифы на аренду сайта и коммерческую поддержку и автообновления с января 2024 г., строим планы на будущий год.