Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

Search the Community

Showing results for tags 'как быть'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Genaral
    • Новини та оголошення
    • Пропозиції та побажання
    • Акції, подарунки, конкурси та винагороди
  • Opencart 4.x
    • Opencart 4.x: General questions
    • Opencart 4.x: Installing and updating
    • Opencart 4.x: Localization
    • Opencart 4.x: Setting and optimization
    • Opencart 4.x: Sandbox
    • Opencart 4.x: Extension search
    • Opencart 4.x: Bug Reporting
  • Opencart 3.x
    • Opencart 3.x: General questions
    • Opencart 3.x: Installing and updating
    • Opencart 3.x: Localization
    • Opencart 3.x: Setting and optimization
    • Opencart 3.x: Sandbox
    • Opencart 3.x: Extension search
    • Opencart 3.x: Bug Reporting
  • Opencart 2.x
    • Opencart 2.x: General questions
    • Opencart 2.x: Installing and updating
    • Opencart 2.x: Localization
    • Opencart 2.x: Setting and optimization
    • Opencart 2.x: Sandbox
    • Opencart 2.x: Extension search
    • Opencart 2.x / ocStore 2.x: Bug Reporting
  • Реклама и продвижение
    • SEO-питання (оптимізація та просування магазину)
    • Контекстная реклама
    • Торговые площадки
    • E-commerce tracking и бизнес аналитика
    • Разное
  • Підтримка та відповіді на запитання.
    • Загальні питання
    • Встановлення, оновлення, налаштування
    • Шаблони, дизайн та оформлення магазину
    • Модули и дополнения
    • Допомога програмістам та розробникам
    • Мобильная витрина
    • Вопросы безопасности
    • Переклад
    • Отчёты об ошибках
    • Интернет-магазины и электронная коммерция
    • Песочница
  • Услуги
    • Creation of stores
    • Дизайн, верстка и шаблоны
    • Программирование, создание модулей, изменение функциональности
    • Настройка и мелкая работа по уже существующему сайту
    • Shop engine version update
    • Store filling
    • System administration (configuring hosting, servers, software)
    • Другие услуги
  • Разное
    • Пользовательские обзоры дополнений
    • Примеры сайтов на OpenCart (ocStore)
    • Курилка
    • Предложения по улучшению

Categories

  • Templates
    • Free templates
    • Платные шаблоны
  • Filters
  • Promotions & Pricing
  • Реклама и продвижение
  • Coupons & reward points, affiliate programs
  • Blogs, News & Articles
  • Reviews
  • Shopping Cart & Order
  • Product Options
  • Product Attributes
  • Product Combinations
  • Search
  • SEO & Optimization
  • Caching & Server Performance
  • Платіжні системи
  • Доставки
  • Editors
  • Design & Navigation
  • Banners, Slideshows & Galleries
  • Email Marketing & SMS Integration
  • Customer Support & Chat
  • Обмен данными
  • Учет в заказе
  • Compare & Wishlist
  • Социальные сети
  • Parsers
  • Модули
  • Tools & Developer Tools
  • Licenses
  • Language packages
  • Other
  • Отчеты
  • Сборки
    • ocStore
  • Services
    • Графика и дизайн
    • Маркетинг

Categories

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

Categories

  • Gereneral questions
  • Purchasing extensions
  • For developer
  • Account
  • Technical support
  • Financial department

Blogs

  • 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: Старт пригоди. Ціна створення сайту на Опенкарт
  • Щось про щось
  • Від власника до розробника

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Сайт


Skype


City:


Interests

Found 1 result

  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 минут своего времени на описание бага и получил бы стократ больше – свежий приток новых клиентов, уважительное отношение к себе со стороны автора и хорошую репутацию, которую не купишь рекламными постами. Не спешите писать в комментах «если бы да кабы», сперва прочтите следующий пункт. Хороший пример А вот другой пример из личного опыта с человеком, в особых симпатиях к которому меня точно сейчас не заподозришь Опять же, несколько лет назад, когда мы еще нормально общались и мой оппонент производил в целом адекватное впечатление, у него был в работе проект с моим шаблоном, в котором была обнаружена неприятная проблема – в блоке быстрого поиска я не догадался поставить небольшой таймер для задержки поискового запроса. Поэтому при быстром наборе этого самого запроса каждое нажатие клавиши вызывало отправку запроса на сервер и получение ответа, из-за чего окно поиска мерцало, а сервер вместо того, чтобы с небольшой задержкой сразу искать один товар "кресло" выполнял серию последовательных запросов, пытаясь найти товар "кр", "кре", "крес", "кресл", и т.д. Что сделал мой оппонент в то время? Написал мне в личку «со всем уважением, вы тут не правы)» и объяснил суть проблемы. В итоге уже через день клиент, у которого эта проблема проявлялась, получил инструкцию по ее исправлению, в готовящемся обновлении шаблона тоже появилось это исправление, ну а мой оппонент получил не одну и не две рекомендации его услуг среди моих собственных клиентов. Как мог поступить мой оппонент (и как, вероятно, поступил бы сейчас в такой ситуации)? Разумеется, ни в коем случае не стал бы сообщать об этом баге лично, а предпочел бы выложить на всеобщее обозрение какой-нибудь гневный пост в блоге, сопроводив язвительными комментариями о том, какой шаблон кривой-косой и как он много вреда и бед принес его клиенту. Что полезного в результате получил бы мой оппонент в такой ситуации, кроме минутного удовольствия от того, как жертву макнули в лужу? Ровным счетом ничего. Никто из нас не любит, когда его критикуют, а особенно когда критикуют публично, этому учат и студентов-психологов, и маркетологов, и даже политиков. Если ваша цель не в минутном удовлетворении раздутого ЧСВ, а в том, чтобы кто-либо что-нибудь исправил – будьте умнее, сделайте так, чтобы человек сам добровольно захотел это сделать!
×
×
  • Create New...

Important Information

On our site, cookies are used and personal data is processed to improve the user interface. To find out what and what personal data we are processing, please go to the link. If you click "I agree," it means that you understand and accept all the conditions specified in this Privacy Notice.