Перейти до вмісту
Пошук в
  • Детальніше...
Шукати результати, які ...
Шукати результати в ...

RGB

Користувачі
  
Усі розширення автора
 Профіль  Активність Усі розширення автора

  • Публікації

    6 964

  • З нами

  • Відвідування

 Тип публікації 

Записи блогу, опубліковані користувачем RGB

  1. RGB

    О мешках и Д'Артаньянах

    Автор: RGB,


    Главное
    По понятным причинам на форум сейчас захожу редко. Недавно заметил одну полезную инициативу, которую, естественно, поддержал (что и другим советую). И вот прошло полторы недели, война еще и близко не закончилась, а отдельные Д'Артаньяны уже рвут тельняшки с пафосными речами и обещаниями кровавой мести в чатах и бложиках, доказывая, что они больше всех сделали для победы и больше всех натерпелись, пока другие «мрази» «вальяжно расслаблялись» (цитата).
     
    Наверняка это очень сложно понять, когда ты считаешь других мразями, а себя – Д'Артаньяном, вокруг которого вертится этот мир, но для реальной помощи вовсе не обязательно рвать глотку в интернете (и вообще заходить сюда), доказывая всем свою исключительность и героизм. Не обязательно упрекать всех тех, кто – вполне возможно – уже помог гораздо больше нас с вами вместе взятых, но кому хватило мудрости и скромности не вопить об этом на весь форум, унижая заслуги всех, кто не вопит так же громко.
     
    На улице, соседней с моим домом, недавно был очередной "прилет" сверху. Во время разбора его разрушительных последствий мешки для строймусора и перчатки были очень кстати. В отличии от подсчетов – кто больше мешков перенес и у кого мешки были тяжелее.
    Потому что п****ть – не мешки ворочать, знаете ли.
  2. RGB
    Порой пользователи OpenCart (особенно начинающие) сталкиваются со всякими «мутными» ресурсами, где им предлагают скачать различные модули и шаблоны, либо купить их по привлекательной цене. К сожалению, владельцы таких ресурсов все больше наглеют и пытаются зарабатывать на своих посетителях, пользуясь их неосведомленностью. Для этого они делают свои веб-сайты похожими на легальные площадки, поэтому неопытному человеку очень легко запутаться среди всех этих ресурсов.
     
    Предлагаю решить проблему неосведомленности пользователей о том, можно ли доверять какому-то ресурсу, с помощью создания базы опасных ресурсов, распространяющих вредоносное ПО. Родилась идея сделать простой проверочный сервис Warez.RIP.
     
    https://warez.rip/
     
    Данный веб-сайт предназначен для того, чтобы помочь пользователям OpenCart отличать легальные ресурсы, где выкладываются подлинные модули и шаблоны для OpenCart, от варезников, где распространяется взломанное и вредоносное программное обеспечение под видом легального.
     
    Варез (от wares, мн.ч. software – Программное Обеспечение, ПО) – незаконным путем распространяемое программное обеспечение с нарушением авторских прав, взломанным и модифицированным исходным кодом. Обычно код модифицируется, чтобы можно было его использовать бесплатно, но в виде «бонуса» пользователи взломанных модулей и шаблонов получают разного рода вредоносное ПО – трояны, майнеры, скрытую рекламы и т.д. Ведь взломщики стараются не просто так, а чтобы как-то монетизировать свою деятельность.
     
    Как понять, что перед вами – варезный сайт?
     
    Понять, что вы столкнулись с варезником, не так уж сложно, если знать их характерные черты:
    В разделах с дополнениями вы видите слова «nulled», «cracked», «без ioncube», «складчина» Наличие «подписки», «vip-аккаунта» и прочих механизмов, открывающих доступ ко всем дополнениям сразу От вас требуют совершить какое-то действие, чтобы скачать файл (поставить лайк, подписаться) Скачивание дополнений ограничено для тех, кто недавно зарегистрировался, но ограничения можно снять за отдельную плату Все дополнения загружены несколькими пользователями, имеют одного автора с логином «admin» или не имеют авторов вообще Ссылка на загрузку дополнения лежит под спойлером (хайдом), для раскрытия нужно заплатить администрации На дополнения организовываются «складчины», т.е. групповая покупка одного дополнения После скачивания файла вы обнаруживаете, что он запаролен, а чтобы узнать пароль, нужно платить администрации Отсутствует какая-либо юридическая информация, а из контактов указан только скайп или электронка Сайт копирует дизайн или использует отдельные его элементы с официальных сайтов Ссылки на загрузку дополнений ведут на бесплатные файлообменники, но не на сервер самого ресурса Отсутствует хоть какая-то информация о самом сайте, используются общие фразы типа «Мы команда опытных веб-дизайнеров и веб-разработчиков» без какой-либо конкретики или портфолио У дополнений нет демо-сайтов, потому что у мошенников нет ресурсов/квалификации, чтобы делать отдельные демо на каждое выложенное дополнение  
    Конечно, это не все признаки того, что ресурс однозначно представляет опасность, поэтому если вы не уверены, с каким именно ресурсом имеете дело, воспользуйтесь этим сайтом и просто введите адрес подозрительного ресурса в поле ввода. Если нам что-либо известно об указанном ресурсе, вы сразу получите информацию.
     
    Как взломщики обманывают пользователей?
     
    Рассмотрим на примере работу одной из таких пиратских площадок, которая настолько удачно «прикидывается» легальной, что даже в Яндексе додумались дать на нее ссылку из своего официального руководства по интеграции метрики (со временем после обсуждения на форуме убрали, но пример показателен).
    Берется какой-нибудь популярный модуль с официальной площадки или с нашего OpenCartForum, к примеру – известный модуль упрощенного оформления заказа AJAX Quick Checkout PRO Его взламывают (или находят на какой-то соседней варезной помойке старую версию), переименовывают так, чтобы название отражало суть, но не полностью совпадало с оригиналом - например, AJAX Quick Checkout PRO превратился в Custom Quick Checkout для Opencart. Делаются скриншоты модуля, но так, чтобы по ним не сразу было понятно, что это за модуль в оригинале (пираты, естетственно, не делают никакого демо-сайта для демонстрации работы модуля), например – сравните старую версию вышеупомянутого AJAX Quick Checkout от разработчиков Dreamvention и скриншот супер-пупер модуля «Custоm Quісk Сhесkоut для Ореnсаrt» от пиратов (найдите 10 отличий – оригинал и пиратская копия). В итоге модуль выкладывается пиратами с ценой гораздо скромнее оригинала, чтобы потенциальные любители халявы не сильно пугались – на сейчас оригинал стоит больше 50$, а пиратская подделка с неизвестно каким содержимым – в 7 раз дешевле.  Разумеется, никакой внятной техподдержки пираты оказывать не могут и не будут, поскольку они не являются авторами выкладываемых дополнений и зачастую вообще в них не разбираются, ведь их бизнес - обычная продажа краденого, а не поддержка или разработка чего-то нового или хотя бы своего.  
    Благодарности
     
    Хочется выразить огромную благодарность всем, кто в свое время помогал и продолжает помогать с наполнением базы пиратских ресурсов. 
    Абсолютным лидером в плане активности является @AlexDW, за что ему отдельное спасибо!
    Всем, кого смог вспомнить по перепискам и связанным темам, в частности: @ArtemPitov @Bn174uk @costas @Exploits @halfhope @HyperLabTeam @invays @klaos27 @markimax @matroskin92 @mpn2005 @OCdevWizard @Sha @shoputils @SooR @sv2109 @Tom @whiteblue
    А также тем, кто пожелал сохранить анонимность - спасибо! Заранее прошу прощения у тех, кого забыл отметить, напишите мне и я исправлюсь.
     
     
    UPD: На сегодня (8 июня 2022 года) в базу добавлено 125 ресурсов, спасибо всем неравнодушным, кто помогает с наполнением базы!
    UPD2: Должно быть очевидно, что доступ к профилю @RGB и к его публикациям есть только у меня, поэтому если кто-то где-то представляется мною и предлагает использовать проверочный сервис с адресом, отличающимся от warez.rip (раньше использовался адрес check.mnmkr.com), то это точно не я и доверять этой информации не стоит.
    UPD3: В силу своей многочисленности из списка вредоносных ресурсов были исключены социальные сети, т.к. сообщества в них регулярно появляются, исчезают и меняют свои адреса, поэтому отследить их всех и поддерживать их список в актуальном состоянии не представляется возможным. В подавляющем большинстве случаев сообщества в соцсетях распространяют пиратские дополнения, поэтому к таким ресурсам всегда относитесь с подозрением, если это не официальные сообщества легальных площадок. То же самое касается тематических каналов в мессенджерах, например, групп в Telegram, где «делятся» модулями и шаблонами.
    UPD4: Не надо присылать мне свои магазины для проверки легальности установленных там дополнений, я не могу индивидуально проверять каждый отдельный случай. Требуйте у своих исполнителей данные о том, откуда они взяли установленные у вас дополнениия, берите номера заказов и отправляйтесь к авторам дополнений с вопросами о легальности покупок.
  3. RGB
    У меня давно в голове назревала идея создать некое руководство с лучшими практиками и примерами того, как нужно и как не нужно делать при разработке шаблонов. Никакой саморекламы тут не будет, я адекватно воспринимаю критику и никогда не считал свои шаблоны (особенно первый – кто знает, тот поймет ) эталонными с точки зрения разработчика, так что аргументированная критика только приветствуется.

    Многие разработчики и фрилансеры называют лучшим шаблоном – default и в целом негативно относятся к коллегам-«шаблонописателям», на то есть немало причин, которые мы тут и обсудим. Для удобства восприятия информации дальнейшее изложение будет структурировано по пунктам, от более общих понятий к более частным.
     
    1. Не воруйте чужие решения
     
    Как ни странно, даже среди известных разработчиков шаблонов были случаи воровства чужих решений: от заимствования целых модулей (например, фильтров) до более скрытого использования чужого кода, причем порой без понимания его сути.
     
    Думаю, всем очевидно, что это – плохо, причем плохо не только с моральной или этической точки зрения, но и с точки зрения атмосферы в самом сообществе в целом (а еще про вас напишет Yoda). Одно дело, когда код шифруется от пиратов, но когда разработчику приходится скрывать свой код от коллег, т.к. он понимает, что его могут просто украсть – это никоим образом не способствует ни сплочению сообщества, ни доверию к разработчикам в целом.
     
     
    2. Не шифруйте все подряд
     
    Очевидный совет, который относится и к разработчикам модулей. Да, я знаю, что есть пираты (мне ли не знать этого?), с которыми вы так боретесь, но зачем кубить все? Каким образом стороннему разработчику потом разбираться в вашем коде? Каким образом пользователю внести свои индивидуальные доработки, если у вас закодированы и модель, и контроллер? А может быть в зашифрованном коде скрываются не только авторские решения, но и позаимствованные у коллег?
     
     
    3. Не бойтесь пиратов
     
    По моему опыту те пользователи шаблонов, что стабильно используют взломанные версии с вареза, никогда ничего у вас не купят, это просто не их путь. По этой же причине малоэффективно тратить время и силы на пуленепробиваемую антипиратскую защиту шаблона – если даже у вас получится сделать что-то подобное и шаблон чудом не будет взломан, то этот факт вовсе не заставит сотню пользователей вареза пойти к вам его покупать, им гораздо проще взять любой другой пиратский шаблон, чем тратить деньги на ваш.

    Идея в том, что пользователь вареза изначально не настроен на покупку в принципе. Тот небольшой процент, которым кровь из носу нужен именно ваш шаблон (к примеру, нечистоплотные вебмастера, которым заказчик говорит «хочу») в случае отсутствия этого шаблона на варезе будут изо всех сил отговаривать заказчика от его выбора, поскольку это их хлеб. А абсолютно уникальных шаблонов уже просто не существует, в отличии от некоторых узкоспециализированных модулей.

    Также не стоит забывать о том, что есть определенная категория пользователей, которые любят тестировать дополнения с вареза, а уже потом их покупают, поэтому если у вас не предполагается тестовой версии шаблона – это еще одна причина не бояться пиратов, а воспринимать их как один из своеобразных рекламных каналов.
     
     
    4. Не демпингуйте
     
    Если ваш шаблон плохо покупают – причина вовсе не обязательно связана с его ценой.
    Если ваши конкуренты продают похожие шаблоны за 3000, а вы выложите свой за 1000 – вы не получите в 3 раза больше покупателей, а получите покупателей в 3 раза более жадных и вредных.
     
     
    5. Следите за чистотой кода
     
    Еще один очевидный совет, которым многие пренебрегают – все мы знаем, какое «удовольствие» разбирать чужой код. Порой читабельность кода не особо вырастает даже когда он не зашифрован, причем речь не только о коде как таковом, но и о верстке, скриптах и стилях.
     
    Если в самом опенкарте полностью избежать спагетти-кода (и не создать проблем с совместимостью) не получится при всем желании, то это вовсе не значит, что стоит пускаться во все тяжкие и запихивать $this->config->get в tpl-файлы (знаю-знаю, у меня в 1-м шаблоне именно так все и сделано и мне до сих пор стыдно) или делать множественные sql-запросы в контроллерах. Если вы не знаете, что и как сделать правильно – установите на локалку девственно чистый опенкарт и изучайте его структуру и его файлы, он сам по себе как документация (которой нет).
     
     
    6. Забудьте о «разработке через страдания»
     
    Если вы хотите сделать толковый шаблон, то забудьте о принципе «Разработка через страдания», который звучит так: сначала сделай, чтобы было, затем — чтобы было красиво, затем — чтобы было быстро. Он совершенно неприменим к шаблонам. У вас все должно быть по возможности быстро, красиво и продумано до мелочей с самой первой версии, поскольку иначе ваш продукт просто не заметят и не оценят покупатели, а потом будет уже поздно.

    Даже если у вас горят все сроки по возврату кредита/ипотеки и вся надежда только на скорейший релиз шаблона – не выпускайте сырой «неупакованный» продукт, вы этим сделаете только хуже! Наполнение вашего демо не должно быть основано на стандартных унылых товарах и баннерах OpenCart, презентация шаблона не должна быть написана в последний вечер на коленке в ворде, а в самом шаблоне должны быть продуманы даже такие мелочи, как склонения числительных в таймере акций (никаких «Осталось: 13 дн 11 час 18 мин», вы шаблон делаете для живых людей, у которых в русском языке есть склонения, а не для роботов).

    На форуме представлена масса интересных и полезных дополнений, которые никогда не станут популярными по той простой причине, что их авторы – в первую очередь программисты, они не думают про упаковку своего продукта и считают простыню голого текста в описании дополнения презентацией. Они не думают о том, чтобы тратить время на «вылизывание» своего продукта и продумывание всех мелочей. Выражение «pixel-perfect» воспринимаются ими как что-то ужасно долгое и ненужное, но это совершенно не так, по крайней мере в случае с шаблонами – дьявол часто кроется именно в деталях.

    Если у вас однотипные элементы имеют разную высоту, абзацы выравниваются с произвольными отступами, а иконка в круглой рамке выводится не по центру, а смещена вниз – уделите этому свое время. Разумеется, все должно быть в меру, а лучшее – враг хорошего, поэтому маниакальным перфекционизмом заниматься тоже не стоит, важнейший навык в этом плане – найти золотую середину между скоростью и качеством работы.
     
     
    7. Не превращайте шаблон в сборку
     
    Изначально задачи шаблонов заключались в обеспечении привлекательной «внешности» магазина, а функциональность обеспечивалась модулями. Но со временем началась своеобразная инфляция возможностей шаблонов, каждый новый старался превзойти предшественника по количеству настроек и модулей, входящих в комплект.
     
    Сейчас все знают, что получилось в итоге – монструозные сборки (это уже не шаблоны) со встроенными фильтрами, блогами, упрощенными оформлениями заказов, десятком плагинов фотогалерей и сотней комплектного модульного барахла, большую часть которого пользователь никогда не будет включать. Я прекрасно понимаю шаблонописателей, которые пошли по этому пути, да и сам не без греха, хоть и старался не перегружать шаблон лишней функциональностью. 

    Почему же так произошло? Да потому что сложно «продать» средненький шаблончик, когда через дорогу продается такой же, но с фильтром и тележкой модулей в комплекте.
    Правильный ли это путь? Конечно нет, поскольку понятие шаблона смешивается с понятием сборки, от чего страдают абсолютно все:
     
    Пользователи получают неповоротливые громоздкие решения все-в-одном, чрезмерно сложные в целом и слабые по своим отдельным компонентам, в сравнении со специализированными модулями (смеха ради посмотрите возможности комплектного фильтра, входящего в состав какого-нибудь популярного шаблона, и модуля ocFilter), а постоянное наращивание таких решений у конкурентов вызывает у пользователя ложное предположение, что это нормальная практика – когда в шаблон впихивается модуль фильтра-блога-кешировщика и прочие несвязанные вещи Разработчики модулей теряют потенциальных клиентов, поскольку пользователю шаблона порой легче мучиться со встроенным в шаблон решением, чем искать нормальную отдельную альтернативу, которую к тому же придется адаптировать под шаблон Разработчики шаблонов вместо работы над внешним видом шаблона вынуждены постоянно наращивать его функциональность, стараясь угнаться за конкурентами, что доходит до абсурда и встраивания низкокачественных (а порой и вовсе чужих) решений, лишь бы не отстать в этой гонке  
     
    8. Не будьте эгоистом – ваш шаблон не единственный в мире
     
    Очень часто сталкиваюсь с ситуациями, когда пользователи решают сменить свой супер-шаблон на какой-то новый и их ждут любезно расставленные авторами грабли уже на моменте простого переключения в настройках на default, потому что заботливый разработчик и мысли не допускает, что его прекрасный супер-шаблон кто-либо когда-либо может захотеть сменить.
     
    Самая распространенная ситуация – когда многочисленная орава комплектных модулей супер-шаблона имеет файлы шаблонов исключительно для каталога самого супер-шаблона и не имеют своих адаптированных версий (или хотя бы копий!) для каталога дефолтного шаблона. В итоге при переключении на default все страницы магазина, где использовались модули супер-шаблона, перестают открываться, ведь опенкарт просто физически не может найти файлы шаблонов этих модулей. Несчастному пользователю придется вручную выискивать и отключать все модули супер-шаблона лишь для того, чтобы хотя бы вернутся к исходному состоянию системы со стандартным шаблоном.

    Вторая по распространенности ситуация – когда разработчику лень описать в документации процесс установки по шагам и все сводится к копированию всех файлов на хостинг (а модификаторов в /system) – уже догадались, что происходит при смене шаблона, когда пользователь понятия не имеет, что ему еще нужно по FTP ковыряться в системном каталоге и вручную удалять оттуда все модификаторы старого шаблона? И зачем в опенкарте сделан раздел Модификаторы с возможностью установки/удаления из админки?

    И напоследок уже довольно редкий сценарий – разработчик просто перезаписывает файлы шаблона default (и хорошо если только файлы шаблона, а не контроллеры или библиотеки). Думаю, объяснять последствия таких действий нет смысла, тут проще обрадовать пользователя, все сжечь и ставить движок с нуля.
     
     
    9. Думайте о совместимости с другими дополнениями
     
    Бывает так, что у разработчика очень чешутся руки и он решает отказаться от устаревшего барахла, используемого опенкартом – убирает jquery, вырезает bootstrap или обновляет его с версии 3 на 4.5, убирает font awesome и т.д. Это все прекрасно и похвально, когда вы занимаетесь своим собственным магазином или выполняете работу для одного постоянного клиента и предупреждаете его о возможных рисках. Но если вы хотите сделать продукт, которым будете пользоваться не только вы и ваши друзья, подумайте на мгновение о том, с чем столкнется ваш пользователь при попытке установить какой-нибудь самый безобидный модуль, в котором используется сетка bootstrap (а это по определению абсолютно все модули, где идет вывод товаров), иконки font awesome (аналогично), а операции с DOM осуществляются через jquery.

    Конечно, можно следовать трендам и делать костыли для поддержки других дополнений (к примеру, убрать bootstrap и спустя пару десятков недовольных пользователей сделать опцию в админке «Подключить Bootstrap» – гениально же?), но не проще ли следовать стандартам? Поверьте, рядовому пользователю плевать на то, современный ли вы используете фреймворк и все ли у вас сверстано на флексах или на таблицах, ему важно, чтобы все работало как положено и сайт не разваливался при попытке поставить сторонний модуль. А сделать говно можно как на Bootstrap и jQuery, так и на каком-нибудь Foundation с ваниальным js или нодой. Это все лишь инструменты в руках разработчика, только вот успешность проекта зависит не от инструментов, а от навыков, с которыми эти инструменты используются.
     
     
    10. Учите матчасть
     
    Один из последних пунктов по порядку, но не по важности – уделяйте внимание теории, причем я пишу не только про техническую составляющую, рассмотренную в п.5. Если вы делаете шаблон, то я бы очень советовал почитать Стива Круга, Филипа Котлера и других специалистов. Конечно, вы можете все делать и «по подобию» других шаблонов, ничего не понимая в дизайне, юзабилити и маркетинге, вдохновляясь на themeforest или на всяких дизайнерских CSSWinner и CSSDesignAwards, но есть один нюанс.

    Если проводить аналогии, то похожим образом на китайских ноунейм-фабриках делают дешевые велосипеды с тяжелой стальной рамой, неправильной геометрией, посадкой и «одноразовыми» компонентами. При этом со стороны их изделия действительно выглядят как велосипеды (ну а что там такого, два колеса, рама и руль), но если присмотреться поближе или проехаться на них, имея опыт эксплуатации нормальных моделей – все станет очевидно. Недаром есть термин BSO (Bike-Shaped Object, объект в форме велосипеда), которым и нарекают подобные продукты.
     
    Так и с шаблонами – если вы взялись их делать, стоит ли слепо копировать дизайн Юлмарта/Розетки в десятый раз? Почитайте пару книжек, поймите ошибки существующих решений и сделайте лучше!
     
     
    11. Избегайте обращений к своему серверу
     
    Ваши пользователи не должны быть заложниками работоспособности вашего сервера лицензий. Любая зависимость ваших дополнений от вашего сервера – не просто неудобство и лишние тормоза (даже в относительно свежих шаблонах встречается ситуация с постоянным обращением к стороннему серверу для проверки лицензии), а и потенциально опасная уязвимость.
     
    Конечно, разработчик может возразить, что он – профессионал, доступ к его серверу есть только у него, а сам сервер невероятно надежен и полностью защищен. Пока петух не клюнет, все так говорят, к примеру, один печально известный «эксперт по php и OpenCart» @addist, пока из-за обращений к его серверу у пользователей не начались массовые проблемы с доступностью магазинов, а в его модулях не нашли критическую уязвимость. Или одна печально известная веб-студия N***** у которой модули по окончанию срока действия лицензии в определенных ситуациях просто «вешали» сайты клиентов. Не все разработчики понимают, что это не просто неудачные реализации и недоработки – это огромные убытки для работающего магазина, которые могут не только лишить владельца какой-то прибыли, но и привести даже к закрытию всего бизнеса, поэтому таких практик нужно избегать любой ценой.
     
     
    12. Полная документация сэкономит время как вам, так и пользователям
     
    Думаю, тут и так все понятно из заголовка. Кто-то возразит, что пользователи – лентяи, поэтому документацию не читают, я с этим полностью согласен, но есть очень важный нюанс. Рано или поздно в общении с пользователями вы поймете, что чаще всего задаются одни и те же типовые вопросы, поэтому если вы их опишете в документации, то в будущем не будете тратить время, отвечая в -надцатый раз на вопрос о перекраске кнопок, а сможете дать ссылку на конкретный пункт в вашей документации.
     
    Это же касается любой из функций шаблона, поскольку при наличии даже базовой документации она со временем (при вашем участии, естественно) разрастется до такого состояния, когда будет отвечать на подавляющее большинство вопросов (или хотя бы задавать направление пользователям для самостоятельного поиска ответов). Если вы цените свое время, то сами к этом прийдете, но лучше это сделать раньше, а освободившееся время потратить на что-то более продуктивное.
     
     
    13. Ведите лог разработки и обновлений
     
    Помимо очевидных удобств в плане повышения рабочей дисциплины и понимания изменений кода со временем, этот пункт имеет и другой важный и полезный эффект. Конечно, вы сможете показать своей маме/детям/внукам историю своей работы и эволюцию своего шаблона, но, как ни странно, вам это может пригодится в общении и с менее близкими людьми. Причем речь идет не только о хейтерах, но и об администрации площадки, где вы собираетесь выкладывать шаблон.
     
    Речь пойдет о плагиате и способах обоснованно избежать обвинений в нем. Причем я пишу не о плагиате, например, с многострадальной Розетки, удивительное сходство с которой можно без проблем увидеть даже в самых новых шаблонах. Я имею в виду другой плагиат – когда элементы более нового шаблона напоминают элементы другого, более старого шаблона.
     
    Пример из личного опыта – я уже третий год разрабатываю новый шаблон (назовем его A), в котором, среди прочих нововведений, используются градиентные кнопки, на карточке товара есть плавающий блок покупки, а на демо – фото айфонов. И вот неделю назад один разработчик выпускает свой новый шаблон B, в котором используются – угадали? – градиентные кнопки, на карточке товара есть плавающий блок покупки, а на демо фото айфонов в том числе  Конечно, если через несколько месяцев будет релиз моего шаблона A, то некоторые персонажи могут усмотреть в этом плагиат с шаблона В другого разработчика. Но я веду историю разработки и в ней есть железные доказательства того, что, к примеру, градиенты на кнопках в моем новом шаблоне A были уже весной 2021-го года, когда шаблона В, естественно, еще не существовало и увидеть его будущий дизайн я физически никак не мог.
     
    Так вот, чтобы всего этого избежать и быть готовым в случае чего доказать свою правоту и авторство – у вас должна быть история разработки, в которой не только будет видно эволюцию шаблона, дизайн-макеты и прочее, но в ней также должны быть четкие (и независимые от вас) временные отметки по всем важным этапам разработки. В самом примитивном виде – снимок вашего тестового сервера из WebArchive или даже какие-нибудь скриншоты, пересланные в Telegram – такие данные не подделаешь, потому что там видно оригинальные даты, поэтому чем больше у вас таких данных – тем сильнее ваша позиция.
     
     
  4. RGB

    Мифы о PageSpeed

    Автор: RGB,


    Главное
    Данная запись содержит личный опыт и наблюдения, как собственные, так и клиентские, поэтому не претендую на истину в последней инстанции и с удовольствием ознакомлюсь с аргументированной критикой. Убедительная просьба в комментариях придерживаться уважительного тона общения, дабы сохранить запись в удобочитаемом виде для всех желающих.
     
    Содержание записи для многих будет очевидно и понятно, однако есть немалое количество людей, которые до сих пор верят определенным мифам о PageSpeed, поэтому цель всего этого чтива – развеять мифы, простым и понятным языком объяснить, что же это за звери такие – попугаи PageSpeed, на что они влияют и с чем их едят, а в будущем при очередном повторении все тех же вопросов – отсылать пользователей на эту запись.
     
    Миф №1: Оценка PageSpeed влияет на позиции в поисковиках
     
    Как можно убедиться в документации Google, баллы PageSpeed действительно показывают оценку скорости работы сайта, а скорость работы сайта, как говорится в блоге Google для вебмастеров, действительно является фактором ранжирования поисковой выдачи. Итого мы имеем два утверждения, которые нередко преподносятся следующим образом:
     
    Баллы PageSpeed = оценка скорости работы сайта Скорость работы сайта = фактор ранжирования поисковой выдачи  
    И вот, ознакомившись с этими двумя утверждениями, нередко можно увидеть и третье утверждение, которое эксплуатируется некоторыми разработчиками и фрилансерами, занятыми «накруткой» баллов:
     
          Баллы PageSpeed = фактор ранжирования поисковой выдачи
     
    Это утверждение ошибочно по одной простой причине – «оценка скорости работы сайта» и «скорость работы сайта» – это не тождественные понятия, хоть они и взаимосвязаны, но лежат в совершенно разных плоскостях.
     
    Даже у такой могущественной корпорации, как Google, нет ни физической возможности, ни реальной необходимости регулярно прогонять все сайты из поисковой выдачи через PageSpeed, поэтому в ранжировании принимают участие вовсе не конкретные цифры из PageSpeed, а гораздо более объективные и реалистичные данные, к примеру, из пользовательских метрик, в частности, фактическая клиентская скорость загрузки сайта из Google Analytics.
     
    Почему сам Google не должен и не будет полагаться на цифры из PageSpeed для поискового ранжирования? Есть немало причин:
     
    Этими данными легко манипулировать (их можно накрутить до невероятных значений, подсовывая боту не тот контент, что получат пользователи) На эти данные значительно влияет география серверов (утрированный пример – представьте себе скорость загрузки магазина на серверах, работающих в Минске, для бота, заходящего из США) Оценка и многие рекомендации PageSpeed ориентированы в первую очередь на пользователей интернета в США и Канаде, где технологии значительно отличаются от наших реалий (к примеру, в плане распространения ADSL) Результаты оценки имеют слабую точность и повторяемость, поскольку зависят от доступности сети и ее состояния в момент проверки, из-за чего два оценивания подряд могут иметь разброс в десятки пунктов Данные PageSpeed изначально не предназначены для оценки того, «любит» ли Google ваш сайт, а лишь для того, чтобы обнаружить узкие места в работе сайта  
    Из всего вышеперечисленного легко сделать вывод о том, что оценка PageSpeed не имеет и не может иметь прямого влияния на позиции в поисковой выдаче, однако не спешите закрывать PageSpeed Insights и облегченно вздыхать – хоть у этой оценки и нет прямого влияния, это вовсе не значит, что красные циферки 17/42 можно игнорировать, поскольку стабильно плохие показатели (в красной зоне) сигнализируют о том, что с сайтом есть проблемы.
     
    Особенно если речь идет о крайне долгом отклике сервера и времени загрузки до взаимодействия – такие симптомы будут серьезно влиять и на поведенческие факторы, ведь никто не станет сидеть на вашем сайте минуту в ожидании его полной загрузки.
     
    Поэтому сильно проседающие показатели можно и нужно выводить до более-менее приемлемого уровня, ориентируясь на самостоятельные наблюдения и на те самые вышеупомянутые метрики, среди которых можно выделить процент отказов как один из индикаторов того, «нравится» ли посетителям ваш сайт.
    Если же вы переживаете из-за красной зоны, т.к. надеетесь, что поисковый трафик обеспечит вам основную часть продаж, то можно уже не переживать – с большой долей вероятности вы и так скоро закроетесь, потому что сегодня на одном только поисковом получится выехать лишь в очень узких, региональных и неконкурентных нишах. Это является еще одним аргументом в пользу того, что не стоит гнаться за оценкой 99/100, лучше направить эти ресурсы на более важные вещи – на рекламу или контент.
     
     
    Миф №2: PageSpeed показывает скорость работы шаблонов
     
    Так уж сложилось, что мне знакома ситуация с шаблонами, поскольку нередко ко мне обращаются с подобными вопросами о том, какой шаблон «быстрее», а в качестве аргументов рассматриваются именно цифры PageSpeed из демо-сайтов шаблонов. При этом данный миф активно эксплуатируется некоторыми авторами шаблонов, которые указывают в роли преимуществ шаблона его скорость работы и ссылаются при этом на конкретные цифры PageSpeed. Тут надо напомнить немного теории.

    На формирование итоговой оценки PageSpeed влияет множество факторов, значительная часть которых вообще не связаны с шаблонами, а зависят исключительно от настроек сервера и его времени отклика, наличия кеширования, оптимизации графики сайта и прочих технических особенностей. В частности, среди ключевых метрик рассматриваются три важнейшие:
     
    Отрисовка крупного контента (Largest Contentful Paint, LCP) -  время, за которое браузер отрисовывает самый крупный видимый элемент в области просмотра. Отсчет начинается с того момента, когда пользователь запрашивает URL. Самым крупным элементом контента обычно является изображение или видео, но это также может быть объемный блочный элемент с текстом. Этот показатель важен, так как появление первых элементов на экране говорит посетителю сайта о том, что URL загружается.
    Первая задержка ввода (First Input Delay, FID) - время между первым взаимодействием пользователя со страницей (нажатием на ссылку, кнопку и т. д.) и ответом браузера. Учитывается нажатие на любой интерактивный элемент. Этот показатель позволяет оценивать эффективность страницы, на которой пользователи могут предпринять какие-либо действия, и определяет, с какой скоростью реагируют интерактивные элементы на ней.
    Совокупное смещение макета (Cumulative Layout Shift, CLS) - показатель того, насколько элементы на странице смещаются во время ее загрузки. Значения показателя находятся в диапазоне от 0 (без смещения) до 1 (максимальное смещение). Этот показатель важен, поскольку смещение элементов страницы при загрузке плохо влияет на удобство использования сайта.
     
    Даже если не углубляться в детали каждой из метрик, достаточно рассмотреть первую - LCP (или похожую по сути FCP - First Contentful Paint), на значение которой влияют следующие важнейшие факторы, согласно документации:
     
    Медленное время отклика сервера Ресурсы JavaScript и CSS, блокирующие отображение Время загрузки ресурсов Рендеринг на стороне клиента  
    Как видите, сразу на первом же месте идет то, что обычно никак не контролируется шаблоном и зависит в первую очередь не от него, а от того, быстрый ли у вас сервер. Аналогичная ситуация будет и со временем загрузки ресурсов (хотя «продвинутые» шаблоны могут плодить их количество) и множеством других пунктов, поэтому если вы попросите у авторов шаблонов, хвастающих высокой оценкой PageSpeed, хотя бы 5 примеров реально работающих (не пустых) магазинов на их шаблонах и проверите их через PageSpeed – вы и близко не увидите тех красивых цифр, которые видите при проверке специально подготовленных и вылизанных демо-сайтов шаблонов.
     
    Можно ли в таком случае утверждать, что оценка демо-сайта шаблона не играет никакой роли при выборе шаблона? Лишь отчасти, ведь хотя эта оценка и показывает в первую очередь уровень подготовленности демо-сайта, вместе с тем она позволяет проверить и те факторы, которые все же зависят от шаблонов, например вышеупомянутый FID (Первая задержка ввода), повысить который, согласно документации, предлагается следующим образом:
     
    Уменьшить влияние стороннего кода – чем больше всякого «мусора» в виде скриптов и плагинов тянет шаблон с собой, тем хуже Сократить время выполнения JavaScript – на первый взгляд красивая и плавная JS-анимация с выдвигающимися товарами запросто может стоить нескольких секунд проигрыша Минимизировать работу основного потока – чем больше стилей, скриптов и захламленности, тем больше уйдет времени на анализ, компиляцию и выполнение всего этого добра Минимизировать количество запросов и размеры передаваемых данных  
    Также немаловажно будет обращать внимание на следующие факторы:
     
    Размер структуры DOM – если рассматривать два гипотетических шаблона, у которых выводится одинаковое кол-во товаров в категории, то чем меньшей будет структура DOM, тем легче будет верстка шаблона Размер кода CSS – чем меньше вес и легче правила, тем лучше Размер кода JS – чем меньше вес и сложность в выполнении, тем лучше и быстрее все будет отрабатывать  
    Разумеется, это не все факторы, на которые стоит обращать внимание, но цель рассмотрения данного мифа не в том, чтобы научить выбирать шаблоны, а в том, чтобы показать сомнительную целесообразность оценивания и сравнения шаблонов по оценке PageSpeed.
     
    Важность метрики CLS (Совокупное смещение макета) в плане юзабилити можно хорошо продемонстрировать следующим примером:
    При этом оценивающие инструменты вроде того же PageSpeed и Lighthouse подходят к вопросу измерения этой метрики очень формально, являясь автоматизированными инструментами, не понимающими контекста измерений и не знающими, по каким сценариям используется ваш интерфейс. Например, нередко эта метрика показывает плохие результаты из-за того, что определенные блоки инициализируются с помощью скриптов Javascript и могут быть не видны до момента инициализации. Самый распространенный пример – слайдшоу или карусели, на практике «внезапное» появление таких блоков выглядит следующим образом (обратите внимание на блок карусели дополнительных фото товара справа вверху):
    Можно ли от этого избавиться ради получения более низкого показателя CLS? Конечно, есть разные способы (от довольно простого и «глупого» принудительного указания рассчитанной высоты этого блока, чтобы на его месте до инициализации карусели выводилась пустота, до более серьезных и продуманных способов с выводом статичных миниатюр дополнительных фото, визуально идентичных таковым в инициализированной карусели), однако практической ценности у этого будет очень мало, кроме выигрыша «попугаев» этой метрики, да и то не факт.
     
    Улучшится ли UX (user experience, опыт взаимодействия пользователя) на сайте после этих действий? Нисколько, т.к. все эти скрипты, вызывающие смещения в макете, грузятся сразу со страницей, поэтому пользователь до их загрузки все равно ничего с сайтом не сделает и не сможет сделать, даже если поставить заглушки вместо неинициализированных блоков каруселей – заглушки будут нефункциональными до момента инициализации самих каруселей, а значит ими все равно невозможно будет пользоваться.
     
    Возможна ли ситуация, когда пользователь захочет нажать на какую-то из кнопок или ссылок под неинициализированным блоком карусели и промахнется из-за смещения блоков, последовавшего после инициализации карусели? В теории да, но на практике такая ситуация крайне маловероятна, поскольку чтобы нажать на кнопку покупки товара или на какую-то из информационных ссылок, их нужно как минимум успеть увидеть и прочесть. Конкретно в вышеприведенном примере даже при использовании медленного мобильного 3G-интернета основное фото товара загружается намного дольше, чем инициализируется карусель и подгружаются ее дополнительные фото (потому что при весе основного оптимизированного фото в 15.5 кБ дополнительные даже суммарно весят в 4 раза меньше), а кто будет нажимать кнопки покупки товара, не увидев его фото, не говоря про чтение описания и т.п.?
     
    Как видите, на практике результат оценки шаблона по такой метрике может быть низким даже тогда, когда никакого влияния на юзабилити эти измерения не оказывают, поскольку машинные алгоритмы физически не могут знать всех вышеуказанных нюансов и оценивают такие вещи исключительно с «машинной» точки зрения. Стоит ли из-за этого закрывать глаза на все случаи смещения макета? Конечно нет, по возможности это лучше исправлять, особенно если такие проблемы вызывают больше неудобств, чем в вышеуказанном случае (например, когда весь контент страницы дергается и съезжает вниз из-за загрузки большого фото).
     
     
    Миф №3: PageSpeed это зло
     
    До версии 5.0 инструмент PageSpeed сложно было назвать архиважным или очень информативным, но после того, как PageSpeed начал использовать Lighthouse, его оценка стала намного информативнее и объективнее, достаточно лишь относиться к ней со здоровой критичностью и видеть в ней не цель развития сайта, а ориентир – тот самый «Lighthouse» (в пер. с англ. - маяк), направление которого стоит учитывать, но не стоит принимать как единственно возможное.
     
    Если вы считаете, что все рекомендации PageSpeed выеденного яйца не стоят и никак не повлияют на поисковое ранжирование магазина, каждая страница которого грузится по 30 секунд, то в целом вы правы – ваши посетители убегут прочь с вашего сайта и забудут о нем как о страшном сне безо всякого участия и PageSpeed, и Google  
    Однако если вы думаете, что достижение заветных цифр 99/100 проложит вам дорогу в Топ-3 поисковой выдачи по всем ВЧ-запросам, то вам стоит сразу написать это в письме Деду Морозу, ведь вы, скорее всего, все еще в него верите.
     
     
    Выводы для тех, кто читает только заголовки
     
     
    1. Я не призываю и никогда не призывал "забить" на оценку PageSpeed
     
    2. Оценка PageSpeed (абстрактные баллы 0..100) и метрики, на которых основана оценка PageSpeed (конкретные данные FCP, SI, LCP, TTI, TBT и CLS) – не одно и то же!
     
    3. Оценка PageSpeed не является точным индикатором сама по себе, потому что не несет никакой конкретной информации, в отличии от метрик, на которых основана оценка PageSpeed (вышеупомянутые FCP, SI, LCP, TTI, TBT и CLS)
    Почему так? Распишу подробнее на примере из комментариев: 
     
    4. С умом улучшая метрики, на которых основана оценка PageSpeed, вы, естетственно, улучшаете и саму оценку PageSpeed
    Ключевое слово - "с умом", т.е. понимая за что именно отвечает каждая из метрик и каким образом ее правильно улучшать. Слепое выполнение всех рекомендаций без понимания их сути (например, назначение абсолютно всем изображениям атрибута loading="lazy") принесет больше вреда, чем пользы, хоть и может реально улучшить итоговую оценку!
     
    5. Даже вывод всех метрик, на которых основана оценка PageSpeed, в зеленую зону - не сыграет большой роли в ранжировании вашего сайта и не может гарантировать высокие позиции в поиске
    При этом фактором ранжирования (одним из множества) является вовсе не оценка PageSpeed (абстрактные баллы 0..100), а данные метрик (вышеупомянутые FCP, SI, LCP, TTI, TBT и CLS), на которых эта оценка основана и которые собираются с помощью разных механизмов отслеживания пользовательского взаимодействия.
    Еще раз - поисковые системы не гоняют и физически не могут прогонять все сайты в поисковой выдаче через PageSpeed для их оценивания!
     
    6. Оценка PageSpeed косвенно показывает то, насколько грамотно сделан шаблон, но она не может объективно показывать его «скорость», потому что зависит от массы факторов, никак не связанных с шаблонами (скорость ответа сервера, наличие кеширования и тому подобное).
     
    7. Улучшать удобство и скорость работы можно и нужно независимо от оценки PageSpeed.
     
    UPD (20.12.2021): Запись актуализирована, убраны устаревшие скриншоты, а также добавлены выводы для тех, у кого сложности с чтением и пониманием.
    UPD (25.12.2021): Выводы дополнены информацией из комментариев.
  5. RGB
    Давно были наброски для этого поста, а тут так кстати подвернулась ситуация, на примере которой можно рассмотреть данный вопрос .
    Итак, вы нашли баг в дополнении какого-то автора, для начала определимся с тем, в каких случаях он вообще достоин внимания и обсуждения.
     
    Шаг 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 минут своего времени на описание бага и получил бы стократ больше – свежий приток новых клиентов, уважительное отношение к себе со стороны автора и хорошую репутацию, которую не купишь рекламными постами. Не спешите писать в комментах «если бы да кабы», сперва прочтите следующий пункт.
     
    Хороший пример
    А вот другой пример из личного опыта с человеком, в особых симпатиях к которому меня точно сейчас не заподозришь  Опять же, несколько лет назад, когда мы еще нормально общались и мой оппонент производил в целом адекватное впечатление, у него был в работе проект с моим шаблоном, в котором была обнаружена неприятная проблема – в блоке быстрого поиска я не догадался поставить небольшой таймер для задержки поискового запроса. Поэтому при быстром наборе этого самого запроса каждое нажатие клавиши вызывало отправку запроса на сервер и получение ответа, из-за чего окно поиска мерцало, а сервер вместо того, чтобы с небольшой задержкой сразу искать один товар "кресло" выполнял серию последовательных запросов, пытаясь найти товар "кр", "кре", "крес", "кресл", и т.д.
     
    Что сделал мой оппонент в то время? Написал мне в личку «со всем уважением, вы тут не правы)» и объяснил суть проблемы. В итоге уже через день клиент, у которого эта проблема проявлялась, получил инструкцию по ее исправлению, в готовящемся обновлении шаблона тоже появилось это исправление, ну а мой оппонент получил не одну и не две рекомендации его услуг среди моих собственных клиентов.
     
    Как мог поступить мой оппонент (и как, вероятно, поступил бы сейчас в такой ситуации)?
     
    Разумеется, ни в коем случае не стал бы сообщать об этом баге лично, а предпочел бы выложить на всеобщее обозрение какой-нибудь гневный пост в блоге, сопроводив язвительными комментариями о том, какой шаблон кривой-косой и как он много вреда и бед принес его клиенту. Что полезного в результате получил бы мой оппонент в такой ситуации, кроме минутного удовольствия от того, как жертву макнули в лужу? Ровным счетом ничего.
     
    Никто из нас не любит, когда его критикуют, а особенно когда критикуют публично, этому учат и студентов-психологов, и маркетологов, и даже политиков. Если ваша цель не в минутном удовлетворении раздутого ЧСВ, а в том, чтобы кто-либо что-нибудь исправил – будьте умнее, сделайте так, чтобы человек сам добровольно захотел это сделать!
     
     
  6. RGB
    Предисловие
     
    Не все то золото, что блестит, и не каждый зеленый персонаж с ушами - мудрейший джедай  Вероятно, некоторые заметили, как в последнее время один герой с активной гражданской позицией по очищению сообщества от плохих дополнений (по удивительному стечению обстоятельств нередко создающих конкуренцию его собственным услугам) периодически упоминает меня в контексте "воровства" своего профайлера.
     
    Поскольку мне не охота тратить время на продукты жизнедеятельности моего оппонента и повторять эту историю, отвечая на вопросы в личку, возникла идея изложить в одной записи все факты, чтобы на них всегда можно было сослаться и любой желающий мог сделать собственные выводы. Если у кого-либо есть хоть какая-то информация, опровергающая хоть один из изложенных далее ключевых фактов - жду ее с нетерпением.
     
    Ник нашего героя тактично скроем, поскольку он и так скоро сюда прибежит, поэтому будем его звать просто - оппонентом (конечно я в курсе, как он меня называет, но вы же не станете гавкать на дворовую собаку в ответ на ее лай?). Для нетерпеливых, уже знающих предысторию конфликта - сразу переходите к эпизоду 4.
     
    Эпизод 1 - Скрытая угроза
     
    В октябре 2018 мне понадобился профайлер для своего проекта на OpenCart 2.3, чтобы увидеть проблемные запросы. Поиск по местным дополнениям не дал результатов, кроме бесплатного модуля под 1.5 от @snastik (к которому, как позже окажется, был причастен наш зеленый герой). Я решил адаптировать это решение под 2.3, не став искать на других площадках, потому что задача показалась простой.
     
    В результате адаптации профайлер заработал на 2.3, поэтому было решено сделать полезное дело и поделиться с сообществом этим бесплатным решением (которое явно пригодилось бы не только мне). Давным-давно, руководствуясь той же логикой, я адаптировал модуль импорта @aachernishev (в свою очередь, основанный на другом модуле с доработками других пользователей) с поддержкой фильтров под 1.5. Позже мною было выложено несколько простых бесплатных модулей, которые точно так же совершенствовались другими разработчиками и даже включались в состав их дополнений безо всяких вопросов.
     
    Во всех этих случаях мне и в голову не могло прийти, что такая инициатива может быть воспринята негативно или что ее нужно согласовывать, т.к. все решения были бесплатными и их совершенствование корыстных целей не преследовало, ведь сохранялась и бесплатность, и - в моем случае, - оригинальное авторство.
    Поэтому адаптированный профайлер был опубликован 16 октября 2018 года в бесплатном виде и с четким указанием модуля @snastik, на котором он был основан:
    А через пару дней, когда описание модуля было приведено в порядок и приобрело завершенный вид, к указанию автора была добавлена рекомендация обращаться к нему же за оптимизацией (на что я указывал своему оппоненту в письме еще в ноябре 2018-го):
    Забегая вперед, вся страничка профайлера на момент его удаления выглядела так:
    А это все сообщения из его темы поддержки:
    Если кто-то думает, что скрины, страницу дополнения и тему поддержки со всеми сообщениями я нарисовал в фотошопе - наденьте шапочку из фольги и попросите пруфы у @dinox из бекапов базы форума за любой день с конца октября 2018 по август 2019, пока профайлер был выложен на форуме.
     
    Эпизод 2 - Империя собирается наносить ответный удар
     
    18 октября 2018 года мне написал мой оппонент, с которым мы на то время были в совершенно нормальных отношениях. Он заявил, что я зря выложил профайлер, поскольку такой же (но платный) модуль продавался на соседней площадке. После рассмотрения платного профайлера я увидел, что он только под 2.1 (а мне надо было под 2.3) и написал об этом, однако мое сообщение было проигнорировано. Зато факт выкладывания профайлера, по мнению моего оппонента, создавал помехи его работе.
    На это я спросил (дословно):
    И получил ответ о том, что в таком формате инструмент дает рост низкоквалифицированным специалистам, на что я задал еще один вопрос:
    С чем мой оппонент согласился, четко ответив (вся личная переписка надежно сохранена):
    И переключился на тему о кешировщиках, которые стали мешать его работе. Я никогда не занимался оптимизацией на заказ и отнимать работу у него, естественно, не собирался (да и не мог физически, т.к. это вообще не моя область), а в случае обращений ко мне с такими вопросами вплоть до последнего времени я нередко отправлял клиентов к моему оппоненту и к самому @snastik (что им обоим прекрасно известно, т.к. про оптимизацию сайтов на моем шаблоне они писали у себя и в блоге, и в личной переписке все это и сейчас есть).
     
    В дальнейшем диалоге никаких пожеланий удалить профайлер со стороны моего собеседника не было, поэтому я сделал логичный вывод, что ко мне вопросов нет. Ведь мой оппонент не только согласился с тем, что профайлер не может всерьез угрожать его работе, но и не высказал никаких претензий относительно его авторства, поскольку, повторюсь, в описании профайлера было четко сказано, что я не являюсь его автором, а лишь адаптировал модуль авторства @snastik под 2.3.
     
    Казалось бы, недопонимание устранено, но проходит неделя - и один из пользователей моего шаблона скидывает мне скриншот из личного блога моего оппонента, где то ли в шутку, то ли всерьез предлагается выпустить шаблон на основе моего:
     
    Зная специфическое чувство юмора оппонента, я не особо удивился такой записи. Ведь и ежу понятно, что включать чужое платное решение в свой же платный продукт и продавать его - абсолютно не то же самое, что усовершенствовать бесплатное решение и выложить его, сохранив и авторство, и бесплатность. С плагиатом все это тоже не имеет ничего общего, поскольку чужое решение нигде не было заявлено как мое собственное.
     
    Эпизод 3 - Империя наносит ответный удар
     
    Прошел месяц и я уже успел забыть об этой ситуации, но в конце ноября 2018 года случается очередное странное событие. Поскольку на то время мы с моим оппонентом не имели никаких конфликтов, я был в его группе в телеграме (по его приглашению) и в тот день отвечал там на чей-то комментарий. Но не прошло и минуты после ответа, как он был удален, а я - сперва исключен из той самой группы, а затем и вовсе заблокирован без каких-либо объяснений моим оппонентом.
     
    Естественно, меня это удивило, поэтому я сразу написал своему оппоненту на почту (раз уж все другие каналы связи оказались заблокированы). Мы люди не гордые, поэтому я согласился, что надо было сперва спросить @snastik, а также поинтересовался, чем же вызвана такая неадекватная реакция:
    Как вы догадались, мой оппонент не снизошел до ответов, продолжая тактику полного окукливания
     
    Насколько я помню, вскоре после этого мне скинули такой скриншот из той группы:
     
    Раз уж наш зеленый герой вместо заявленного пути джедая выбрал путь ситха (привет фанатам Звездных Войн), стоит ли его переубеждать, если он игнорирует все попытки разрешить недоразумение, убегает из переписок, трет комменты и не отвечает на вопросы? Поэтому я не особо обращал внимание, когда через какое-то время начались вялые нападки в мой адрес сперва в бложике (ныне удаленном), например, в такой формулировке:
    а затем уже на форуме, как по теме профайлера:
    так и вообще не по теме, как например в недавней записи, где мой оппонент был так оскорблен поднятием стоимости моего шаблона вслед за ростом комиссии, что публично обвинил меня в "жадности" (хотя по факту шаблон благодаря созданному промокоду стал даже *дешевле*, чем был раньше, но зачем нужна математика, когда есть говнистый характер и желание видеть во мне врага народа?):
    Возвращаясь к профайлеру - он в итоге был удален с форума 12 августа 2019 года по моей просьбе, не прожив и года, поскольку оказался не совсем точным в некоторых ситуациях (что заметил товарищ @qwerrqq), ну и, конечно, чтобы поберечь нервы моего оппонента и не отвлекаться на попытки меня задеть.
     
    Эпизод 4 - Атака клоунов
     
    Тем не менее полет фантазии непризнанного зеленого борца за справедливость достиг небывалых высот, как в этой недавней записи:

    Отвечаю по пунктам:
    1. Мой оппонент стремится показать меня неизвестным ему "ноунеймом", появившимся из ниоткуда, представляя меня как "некто RGB", очевидно, желая подчеркнуть этим то, что раз я "некто" - доверять мне не стоит. Это является низкопробной манипуляцией, поскольку мы с моим оппонентом заочно знакомы уже лет 7 и "некто @RGB" незадолго до описываемых событий именовался не иначе, как "очень мною уважаемый господин RGB" и "нормальный мужик":
    мой оппонент предлагал проверить его кешировщик (ставший прототипом TURBO), делал обзор (по своей инициативе, я его никогда ни о каких личных услугах не просил) на мой шаблон:
    давал мне личный аккаунт в своем блоге для публикации истории о ловле известного пирата:
    безвозмездно пиарил мой же скромный проверочный сервис для борьбы с варезом и т.д.
    2. Как вы помните, "некто @RGB" не делал никакого своего профайлера - профайлер был, есть и остается авторства @snastik, что было изначально четко указано в его описании и что никоим образом не смущало моего оппонента, когда он это увидел своими же глазами в далеком 2018-м:
    3. Никаким "ближайшим рассмотрением" для выявления авторства кода мой оппонент не занимался, разве что если считать таковым рассмотрение страницы профайлера при выключенном мониторе, ведь иначе было невозможно не увидеть четко указанный текст:
    4. Никакого кода, "очень похожего на наше со снастиком решение" в профайлере физически не было, т.к. код был не просто "очень похож", а идентичен, что никогда мною не скрывалось и что наверное было бы немного странно скрывать, если я изначально ссылался на их решение?
    5. Единственная часть этой фантастической цитаты, соответствующая истине - об отсутствии спроса и уведомления. Да, я действительно совершил ошибку и не догадался спросить @snastik перед публикацией, но во-первых - я признал это еще в первом письме с вопросами своему оппоненту больше двух лет назад, а во-вторых - причины, по которым я был абсолютно уверен, что делать это необязательно, описаны выше (эпизод 1) и должны быть очевидны любому человеку, который знает меня и то, чем я занимаюсь.
    Если кто-либо предполагает, что я это сделал из желания присвоить себе авторство чужого кода (зачем-то указав его автора) или чтобы подложить свинью своему оппоненту, создав бесплатного конкурента его платному решению - вы можете прямо сейчас снять с себя трусы, надеть их на голову и выйти на улицу. Это будет выглядеть так же по-идиотски, как и данное предположение.
     
    Отдельно хочу прокомментировать еще пару свежих реплик моего оппонента.

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

    Конечно же это не последние нападки в мой адрес, т.к. в комментариях к этой записи или в личном бложике наверняка появятся свежие перлы, веские контраргументы в духе "ты сам дурак и клоун!!", очередные вопросы типа "не стыдно было брать чужой профайлер?" (оппонент ведь не читатель, а писатель), угрозы или факты выкладывания "moneymaker free", упоминания овец, ишаков и прочие типичные паттерны поведения нашего героя Я к этому отношусь совершенно спокойно, поскольку правда и факты на моей стороне, а выводы насчет человеческих качеств моего оппонента любой желающий сделает самостоятельно.
     
    Зачем я все это написал? Это не попытка оправдаться или извиниться - в том, что я захотел помочь другим форумчанам и адаптировал существующее решение, сохранив его авторство и бесплатность, никакой вины не может быть просто по определению. При этом еще тогда, в ноябре 2018-го, я признал ту единственную свою ошибку, когда наивно предположил, что необязательно спрашивать разрешение для, как мне казалось, полезного для всего сообщества дела. А вы как думаете, умеет ли мой оппонент признавать свои ошибки?

Покупцям

Розробникам

Корисна інформація

Останні розширення

×
×
  • Створити...

Important Information

На нашому сайті використовуються файли cookie і відбувається обробка деяких персональних даних користувачів, щоб поліпшити користувальницький інтерфейс. Щоб дізнатися для чого і які персональні дані ми обробляємо перейдіть за посиланням . Якщо Ви натиснете «Я даю згоду», це означає, що Ви розумієте і приймаєте всі умови, зазначені в цьому Повідомленні про конфіденційність.

  Я даю згоду