Перейти к публикации
Поиск в
  • Дополнительно...
Искать результаты, содержащие...
Искать результаты в...

Поиск по сайту

Результаты поиска по тегам 'фича'.

  • Поиск по тегам

    Введите теги через запятую.
  • Поиск по автору

Тип публикаций


Категории и разделы

  • Основной
    • Новости и анонсы
    • Предложения и пожелания
    • Акции, подарки, конкурсы и награды
  • Opencart 4.x
    • Opencart 4.x: Общие вопросы
    • Opencart 4.x: Установка и обновление
    • Opencart 4.x: Локализация
    • Opencart 4.x: Настройка и оптимизация
    • Opencart 4.x: Песочница
    • Opencart 4.x: Поиск модулей
    • Opencart 4.x: Отчёты об ошибках
  • Opencart 3.x
    • Opencart 3.x: Общие вопросы
    • Opencart 3.x: Установка и обновление
    • Opencart 3.x: Локализация
    • Opencart 3.x: Настройка и оптимизация
    • Opencart 3.x: Песочница
    • Opencart 3.x: Поиск модулей
    • Opencart 3.x: Отчёты об ошибках
  • Opencart 2.x
    • Opencart 2.x: Общие вопросы
    • Opencart 2.x: Установка и обновление
    • Opencart 2.x: Локализация
    • Opencart 2.x: Настройка и оптимизация
    • Opencart 2.x: Песочница
    • Opencart 2.x: Поиск модулей
    • Opencart 2.x / ocStore 2.x: Отчёты об ошибках
  • Реклама и продвижение
    • SEO-вопросы (оптимизация и продвижение магазина)
    • Контекстная реклама
    • Торговые площадки
    • E-commerce tracking и бизнес аналитика
    • Разное
  • Поддержка и ответы на вопросы
    • Общие вопросы
    • Установка, обновление, настройка
    • Шаблоны, дизайн и оформление магазина
    • Модули и дополнения
    • Помощь программистам и разработчикам
    • Мобильная витрина
    • Вопросы безопасности
    • Перевод
    • Отчёты об ошибках
    • Интернет-магазины и электронная коммерция
    • Песочница
  • Services
    • Создание магазинов под ключ
    • Design, layout and templates
    • Programming, creating modules, changing functionality
    • Setting up and minor work on an existing site
    • Обновление версии движка магазина
    • Наполнение магазина
    • Системное администрирование (настройка хостинга, серверов, ПО)
    • Другие услуги
  • Разное
    • Пользовательские обзоры дополнений
    • Примеры сайтов на OpenCart (ocStore)
    • Курилка
    • Предложения по улучшению

Категории

  • Шаблоны
    • Бесплатные шаблоны
    • Платные шаблоны
  • Фильтры
  • Цены, скидки, акции, подарки
  • Реклама и продвижение
  • Бонусы, купоны, программы лояльности
  • Блоги, новости, статьи
  • Покупки, оформление заказа, корзина
  • Опции
  • Атрибуты
  • Серии, Комплекты
  • Поиск
  • SEO, карта сайта, оптимизация
  • Кэширование, сжатие, ускорение
  • Платежные системы
  • Доставки
  • Редакторы
  • Меню, дизайн, внешний вид
  • Слайдшоу, баннеры, галереи
  • Письма, почта, рассылки, sms
  • Обратная связь, звонки
  • Обмен данными
  • Учет в заказе
  • Сравнения, закладки
  • Социальные сети
  • Парсеры
  • Модули
  • Инструменты, утилиты
  • Лицензии
  • Языковые пакеты
  • Прочее
  • Отчеты
  • Сборки
    • ocStore
  • Услуги
    • Графика и дизайн
    • Маркетинг

Категории

  • Служебные документы
  • Оплата
  • Документация Opencart

Категории

  • Общие вопросы
  • Покупка дополнений
  • Для разработчиков
  • Аккаунт
  • Техническая поддержка
  • Финансовый отдел

Блоги

  • Konorws (Разработка и модификация Opencart)
  • Блог mr.Kent)
  • Прожектор Бритни Спирс
  • Layk
  • Продвижение интернет-магазина, seo оптимизация
  • Записная книжка
  • Блог RGB
  • Модули которые сделают сайт лучше
  • Блог веб-студии NeoSeo
  • Useful IT
  • Записи
  • Найденные решения проблем с Opencart
  • ocdroid blog
  • Заметки на полях...
  • Pimur
  • Серж Ткач
  • О жизни, смерти, о бизнесе и Опенкарте
  • Просто мысли от laim731
  • Маркетинг и продвижение интернет-магазина
  • Мой копирайтинг
  • SEO боксинг специального назначения
  • Get-Web Dev
  • Seok
  • Блоги sitecreator-а
  • Best practice
  • Vlad-Egorov-Blog
  • Блог spectre
  • commanddotcom
  • Внимание мошенники
  • Наблюдения обычного человека
  • Блог Rassol2
  • Блог Exploits
  • блог для натуралов
  • Настюша, тут есть темы
  • Пропитано рекламой
  • Tutorial
  • ОтВинта
  • Tg chnls
  • Блог
  • Блог sv2109
  • КАК ОРГАНИЗОВАТЬ НОВОСТНЫЕ ПОДПИСКИ НА БАЗЕ API OPENCART 3/0/2
  • VDS/VPS, серверы под Linux: установка, настройка, оптимизация
  • IT блог
  • Блог
  • Opencart SEO
  • Путёвые заметки о работе магазина NiceBike на платформе OpenCart
  • Blondi Blog
  • Полезные статьи, новости.
  • Блог владельца магазина
  • разное
  • ПРОДАЖА АКАУНТОВ-binance ВЕРИФИЦИРОВАННЫe ЧИСТЫЕ УСПЕВАЙТЕ КУПИТЬ ПО НИЗКОЙ ЦЕНЕ
  • Диспансеризация
  • wozobat
  • quasarbyte
  • Мой блог
  • Igorych
  • aaaaa
  • 👌🔊Bellsouth CUSTOMER support number 1+(8O8)678=9O64-☎phone number
  • Liudmila marketer
  • Заметки реалиста
  • ocstore на ноліках
  • Про Opencart
  • Блог про рутинні процеси в магазині на ocsote
  • Radaevich
  • Плагіни Opencart
  • Крафтовий OpenCart: Старт пригоди. Ціна створення сайту на Опенкарт

Искать результаты в...

Искать результаты, содержащие...


Дата создания

  • Начать

    Конец


Последнее обновление

  • Начать

    Конец


Фильтр по количеству...

Зарегистрирован

  • Начать

    Конец


Группа


Сайт


Skype


Город:


Интересы

  1. Давно были наброски для этого поста, а тут так кстати подвернулась ситуация, на примере которой можно рассмотреть данный вопрос . Итак, вы нашли баг в дополнении какого-то автора, для начала определимся с тем, в каких случаях он вообще достоин внимания и обсуждения. Шаг 1. Повторение – мать учения Все прекрасно знают, что баги, т.е. программные ошибки, бывают абсолютно у всех разработчиков, которые хоть что-то делают, но не все баги являются действительно багами, поэтому первое, что нужно сделать – убедиться, что это точно баг, а не фича. Для этого, очевидно, нужно подтвердить обнаружение бага путем его локализации и повторения в разных условиях. В идеальном случае эксперимент нужно проводить на чистом движке и в отсутствии влияния каких-либо других дополнений/модификаторов. Если у вас такой возможности нет и баг обнаружен, к примеру, на демо-сайте разработчика, то тут уже ничего не поделать – сразу переходим к следующему шагу. При этом я еще не встречал людей, которые бы покупали дополнение ради подтверждения обнаруженного на демо бага, но этот сценарий вполне имеет право на жизнь. Для этого не обязательно быть добрым волшебником – возможно, у вас просто есть хороший клиент, которого нужно обезопасить от любых проблем и прибыль от работы с которым точно перевешивает расходы на покупку и тестирование дополнения, даже если оно не подойдет. Шаг 2. Насколько все серьезно? Не все баги одинаково полезны опасны, поэтому перед тем, как предпринимать какие-то дальнейшие действия, нужно самостоятельно оценить масштабы и влияние обнаруженного бага. Конечно, когда в результате найденного вами бага удаляются все пользовательские данные (как в этом каноничном примере rm -rf с GitHub), лучше поторопиться и как можно скорее приступать к следующим шагам. Но если вы заметили какую-то мелочь, например, лишний пробел или перенос где-нибудь в верстке – сразу вас огорчу, исправление таких мелочей очень часто откладывается большинством разработчиков на неопределенный срок. Почему так – есть несколько причин: Если мы говорим о дополнениях для OpenCart, то стоимость таких дополнений и средние бюджеты в проектах далеки от высоких, поэтому требовать "Pixel perfect" от какого-нибудь шаблона за 20$ – бесполезно Не все разработчики вообще обновляют дополнения, поэтому и ошибки в них могут существовать годами, а то и весь срок жизни дополнения Те, кто регулярно выпускают обновления, не делают это каждый день из соображений как собственного удобства (разошлите экстренное обновление тысяче пользователей и через день непременно найдете новый баг, поверьте), так и удобства пользователей (все любят регулярные обновления, но никто не любит тратить время на их установку) Обычно в обновление входит исправление сразу множества ошибок, поэтому исправления пары незначительных багов обычно ставится в очередь для подготовки более крупного обновления Тут все зависит от отношения к своей работе самого автора и зачастую вам будет быстрее и проще самостоятельно исправить обнаруженную проблему. Конечно, это не касается случаев, когда работы выполняются по четкому ТЗ, в котором оговорено отсутствие таких багов – в этом случае вы имеете полное право требовать скорейшей реакции, потому что вы за это платите. Шаг 3. Уведомление или неуведомление автора На этом шаге я бы хотел остановиться подробнее. У любого человека, как у простого пользователя, так и у опытного специалиста, в случае нахождения бага в каком-то дополнении всегда есть несколько вариантов действий: Промолчать Уведомить, но не автора Уведомить автора Разберем каждый из вариантов, его плюсы и минусы. Шаг 3.1 Молчание Если баг оказался некритичным и вы сами смогли его исправить, то вполне возможно, что не захотите тратить время на уведомление автора (тем более, если автор не отличается оперативным исправлением багов). Возможна и другая причина – автор составляет вам конкуренцию (или просто неприятен) и вы заинтересованы в том, чтобы он и его клиенты подольше «страдали» от неисправленного бага Промолчали – и ладно, никто вас за это не осудит (разве что сам автор, и то лишь если узнает или вы сами проболтаетесь). Плюсы: ничье самолюбие не пострадало Минусы: баг так и остался незамеченным и неисправленным Шаг 3.2 По секрету всему свету Бывает и так, что обнаруживший баг специально решает скрыть это от автора, но рассказать это другим лицам (конкурентам, читателям, администрации, кому-угодно еще). Мотивация таких персонажей бывает самой разной – от банальной зависти и конкурентной борьбы до простого и старого, как мир, желания исподтишка нагадить ближнему. Справедливости ради стоит заметить, что есть некоторые авторы, которые категорически отрицают любую критику и воспринимают ее в штыки, поэтому бывает и так, что вы многократно следовали шагу 3.3, но это не дало результатов, поскольку к автору просто невозможно достучаться из-за его собственного упрямства и у нашедшего баг остается только два варианта – молчать или подключать третьих лиц. Плюсы: к багу привлечено внимание, вы ощущаете себя Д'Артаньяном Минусы: баг все равно может остаться неисправленным, а отношения с автором с большой долей вероятности будут испорчены Шаг 3.3 Профессиональная этика Я не просто так назвал этот шаг профессиональной этикой, по моему мнению именно этот вариант действий наиболее профессионален, продуктивен и разумен для всех сторон. К сожалению, мне не часто попадается такое поведение со стороны других разработчиков, да и сам я не без греха, поэтому не стоит воспринимать этот пункт как самовосхваление. Итак, если в случае обнаружения и подтверждения бага вы сперва описываете его автору дополнения, то убивается сразу несколько зайцев. Самолюбие автора не страдает так сильно, как если бы вы прилюдно демонстрировали его баг, а времени на исправление бага у автора остается достаточно много, чтобы все обдумать и грамотно пофиксить (в отличии от ситуации, когда вы публично критикуете автора, вынуждая его защищаться, совершать поспешные действия и оправдываться). При этом в случае с адекватной реакцией автора вы получаете благодарность, причем я говорю не о программе Bug Bounty (все таки мы не в фейсбуке работаем), а про нормальное отношение и признательность со стороны автора к человеку, не поленившемуся помочь справиться с проблемой. Плюсы: баг исправлен, автор (как правило) признателен Минусы: автор (иногда) может затаить злобу и не прислушаться к советам, а вы уже не сможете посадить подготовленного автора в лужу Плохой пример Приведу пример из личного опыта, упомянутый в начале этой публикации – некий сеошник, в последнее время активно рекламирующий на форуме свои услуги, обнаружил у меня в шаблоне проблему, связанную с непродуманным выводом артикулов товаров за пределами заголовочных тегов H1. Почти месяц назад он упомянул ее в своей статье, да еще и приписал мне выполнение SEO-аудитов (которых я никогда не делал и не собирался делать), желая на этом фоне выставить меня эдаким сапожником без сапог и думая, что этого никто не заметит. При всем при этом он за все это время даже не подумал обратиться ко мне лично, чтобы сообщить о найденной проблеме или хотя бы уточнить, действительно ли я делаю эти самые аудиты, которые он критикует? Эта информация про артикулы и H1 не являлась новой для меня и я ее видел еще несколько лет назад в отчете довольно известной компании WebPromo, специалисты которой тогда готовили 100-страничный SEO-аудит сайта знакомых и в одном из пунктов прямо советовали «уникализировать заголовок H1 посредством добавления артикула». В то время я не придал должного внимания этой технике (зря, конечно), отложив реализацию на будущее, а потом благополучено забыл об этом, за что мне стыдно Но речь не об этом. Что можно было сделать в такой ситуации? Если бы человек был немного умнее и изначально уведомил меня об этой проблеме, я бы в знак признательности за найденный баг посоветовал обращаться к этому человеку своим многочисленным клиентам, которые у меня стабильно несколько раз в месяц спрашивают контакты толкового сеошника для своих магазинов. Т.е. человек потратил бы 5 минут своего времени на описание бага и получил бы стократ больше – свежий приток новых клиентов, уважительное отношение к себе со стороны автора и хорошую репутацию, которую не купишь рекламными постами. Не спешите писать в комментах «если бы да кабы», сперва прочтите следующий пункт. Хороший пример А вот другой пример из личного опыта с человеком, в особых симпатиях к которому меня точно сейчас не заподозришь Опять же, несколько лет назад, когда мы еще нормально общались и мой оппонент производил в целом адекватное впечатление, у него был в работе проект с моим шаблоном, в котором была обнаружена неприятная проблема – в блоке быстрого поиска я не догадался поставить небольшой таймер для задержки поискового запроса. Поэтому при быстром наборе этого самого запроса каждое нажатие клавиши вызывало отправку запроса на сервер и получение ответа, из-за чего окно поиска мерцало, а сервер вместо того, чтобы с небольшой задержкой сразу искать один товар "кресло" выполнял серию последовательных запросов, пытаясь найти товар "кр", "кре", "крес", "кресл", и т.д. Что сделал мой оппонент в то время? Написал мне в личку «со всем уважением, вы тут не правы)» и объяснил суть проблемы. В итоге уже через день клиент, у которого эта проблема проявлялась, получил инструкцию по ее исправлению, в готовящемся обновлении шаблона тоже появилось это исправление, ну а мой оппонент получил не одну и не две рекомендации его услуг среди моих собственных клиентов. Как мог поступить мой оппонент (и как, вероятно, поступил бы сейчас в такой ситуации)? Разумеется, ни в коем случае не стал бы сообщать об этом баге лично, а предпочел бы выложить на всеобщее обозрение какой-нибудь гневный пост в блоге, сопроводив язвительными комментариями о том, какой шаблон кривой-косой и как он много вреда и бед принес его клиенту. Что полезного в результате получил бы мой оппонент в такой ситуации, кроме минутного удовольствия от того, как жертву макнули в лужу? Ровным счетом ничего. Никто из нас не любит, когда его критикуют, а особенно когда критикуют публично, этому учат и студентов-психологов, и маркетологов, и даже политиков. Если ваша цель не в минутном удовлетворении раздутого ЧСВ, а в том, чтобы кто-либо что-нибудь исправил – будьте умнее, сделайте так, чтобы человек сам добровольно захотел это сделать!
×
×
  • Создать...

Важная информация

На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности.