Ruslan Brest, rb.labtodo.com
Backend web-developer: CodeIgniter, PHP, MySQL, OpenCart, PrestaShop, MaxSite CMS

Web development

Opencart: вывод производителей в своём порядке вместо алфавитного

Для тех, кто хочет выводить страницу производителей (брендов) в своём порядке, а не в алфавитном, Сегодняшний рецепт. Надо изменить файл catalog/controller/product/manufacturer.php.

Далее...

Opencart: генераторы sitemap.xml (Google Sitemap) и YML (Yandex.Market) для большого количества товаров

Решения, рассчитанные на большое количество товаров:

Сам я ни одно из этих решений не проверял на больших количествах товаров. Воспринимайте как список для справки, изучения и обсуждения.

Главные проблемы стандартного генератора sitemap.xml, в котором по традиции всё делается в лоб и без оптимизаций:

Далее...

SafePatch -- альтернатива vQmod

Идея патчей и vQmod совершенно одинаковая. И в одном, и другом случае файл с изменениями накладывается на некую известную основу. И если эта основа изменилась -- и патч, и vQmod могут "поломаться": не смогут внести изменения, если не найдут точного соответствия, необходимого для внесения правок.

Поэтому те, кто наивно полагает, что vQmod спасёт их от всех бед и является волшебной таблеткой и позволит без проблем обновлять версии и ни о чем не беспокоиться - сильно заблуждаются.

А те, кто знает об этом и вынужден хоть так, хоть иначе контролировать логи ошибок -- знают, что заниматься отладкой vQmod гораздо менее удобно, чем иметь изменения сразу на месте, в коде, и не гадать, откуда именно берется исполняемый код и где его искать в исходниках.

К тому же vQmod - рантайм решение. То есть работает при каждом запросе к серверу. Конечно, многое решается кешированием. Но я из тех разработчиков, которые не совсем понимают, зачем нужно вводить лишнее звено, если то же самое делается без дополнительных костылей (а технологии внесения и убирания этих изменений существуют уже лет 40 и протестированы не одним поколением программистов -- я говорю об утилитах `patch` и `diff`).

Причём убрать изменения так же просто, как и наложить патч.

Применить изменения к коду: git apply fix-some-problem.diff или patch -p1 fix.diff

Убрать изменения: git apply -R fix-some-problem.diff или patch -R fix.diff

И где здесь сложная часть? Это ничуть не сложнее удаления VQmod файла. При использовании vQmod надо управляться с набором XML файлов. При использовании стандартного подхода -- с набором DIFF файлов. Невелика разница. А преимущества серьёзные.

И вот совсем недавно, в поисках PHP-реализации утилиты `patch` или автоматического конвертера DIFF в vQmod XML, я наткнулся на замечательный вариант: утилиту SafePatch.

http://code.google.com/p/safepatch/

UPD: в связи с закрытием Google Code проект переместился на Github: progerxp/safepatch.

Если кратко и своими словами -- это "менеджер пакетов" (расширений). Но в отличие от vQmod (runtime) он эти изменения вносит непосредственно в исходный код (как и `patch`). При этом понимает формат VQmod и может использовать эти файлы тоже.

Так что те, кто интересуется вопросом - встречайте. По-моему, хороший инструмент. Это не совсем то, что я искал, но отличное готовое решение проблемы.

See also:

На чём пользователи читают почту

Всё больше почты читается на мобильных устройствах.

По статистике компании Ecwid, 65% их рассылок читается на айфонах, около 16% - на андроиде. Остальные платформы (десктоп и веб-клиенты) идут дальше с существенным отрывом.

Даже если цифры распределения неточные - тестируйте, как ваши рассылки и письма выглядят на мобильных устройствах.

То, как вы пишете письма, включая квотинг (в первую очередь его бесполезный объём) и стиль изложения -- тоже крайне важно. Тот, кто никогда не пытался пользоваться смартфоном для переписки, обычно допускают следующие ошибки:

Далее...

2012-05: webdev links

Живые блоги с публикациями о CodeIgniter:

Руководство по оформлению HTML/CSS кода от Google. Руководство вообще-то странное: местами непоследовательное и противоречащее самому себе, а местами и вовсе вредное, на мой взгляд. Видимо, сказываются особенности высоконагруженных проектов. В общем, я бы не стал слепо придерживаться всех изложенных там рекомендаций, но просмотреть список и причины появления таких правил -- полезно.

Opencart module extract (Linux shell script)

5 апреля 2012 г. Ruslan Brest Linux » Web development » OpenCart3

Mодули для Opencart обычно используют одно и то же имя для контроллеров, моделей, view и языковых файлов, поэтому этот скрипт может облегчить задачу по поиску и извлечению всех файлов модуля из рабочей копии магазина с сохранением всей структуры каталогов.

Навеяно модулем http://opencartforum.ru/topic/8272-module-extract-извлечение-модулей/, но мне показалось, что линуксоидам будет проще и удобней одной строкой в шелле это делать (локально или на сервере), без установки модуля в Opencart (установить, разрешить, зайти, найти, скопировать...)

Ни я, ни тот модуль не занимаются анализом PHP-кода и действительно полным выковыриванием всех используемых модулем файлов. Так что результат, конечно, не гарантирует полное и точное извлечение. Но будет работать в подавляющем большинстве случаев.

Далее...

OpenCart 1.5.1.x exploited (RFI)

OpenCart 1.5.1.x exploited (RFI) http://code.google.com/p/opencart/issues/detail?id=596

Чтобы избежать неприятностей, надо как минимум менять ключ шифрования в настройках Opencart.

Не помешает также в папку download поместить файл .htaccess со строчкой SetHandler send-as-is.

Почему я уважаю email (и может ещё Jabber), а скайп, аську и прочую чатико-переписку (VK, FB) -- нет

Преимущества email:

  • не отвлекает тогда, когда ему хочется. В работе программиста это очень важный момент. Критически важный;
  • Переписка может без доп. усилий храниться в одном месте, на сервере. И быть доступной с нескольких компьютеров (в т.ч. чужих) и телефонов;
  • возможность сводить переписку в единое место -- это возможность настроить раз единые правила фильтрации и постепенно их дополнять;
  • простота - друг совершенства. Настроить уведомления на SMS при поступлении почты от определенной группы собеседников или при срабатывании какого-либо правила -- никаких проблем. Отфильтровать и настроить такое уведомление в ICQ/Skype... Ну-у-у, попробуйте. И учтите весь зоопарк устройств, которые могут понадобиться;
  • правила обработки email могут храниться и обрабатываться на сервере. Необязательно держать у себя включенное и подключенное к интернет устройство, чтобы оно занималось фильтрацией (а 99.99% времени - простаивало и жрало батарейку без всякой пользы). И не надо головной боли при смене устройства. Получил SMS о чем-то важном в почте - подключился, забрал почту, читаешь.

Аська, скайп, телефон:

  • очень мешают тем, что могут прервать мыслительный процесс в самый неподходящий момент;
  • историю хранить в едином месте нереально. Особенно этим страдает Скайп и телефон;
  • в телефоне логов разговоров вообще не остается. Особенно при деловых разговорах. Или обсуждении деталей задач. Или условий. Человек иногда с удивлением узнает, что именно он говорил или писал, когда видит логи. Даже самый искренний. Потому что совершенно искренне считал, что сказал по-другому. И привычка фиксации часто спасает от скандалов. Речь вообще даже не о злом умысле. Просто об особенностях психологии и памяти человека в стрессовых условиях;
  • Скайп имеет самый идиотскую реализацию просмотра истории и поиска, которую я видел. А внутренности логов лежат не в виде текста, HTML или XML, а в бинарном виде. Но если бы это позволяло ему хотя бы быстро работать... Так нет же. Дождаться загрузки длинного лога - целая вечность проходит;
  • если угораздило обсуждать что-то важное в дороге и забыл или не смог перенести это вовремя на десктоп или в онлайн-хранилище -- найти потом, где это было, когда и на каком девайсе -- целый подвиг. Особенно если дел много. Перенести с телефона важные детали или присланные в процессе разговора длинные ссылки -- сплошная головная боль, потому что мобильные ICQ/Jabber клиенты обычно понятия не имеют об экспорте. Совсем другое дело при использовании email.
  • в аське часты сообщения "привет" и "ты здесь?", после которых нет ничего. Представьте себе, что чувствует занятый человек, просматривая раз в 10-30 минут накопившиеся сообщения, чтобы ответить на самое важное, а остальные минут 20-30 иметь возможность посвятить очередной задаче без отвлечений? Я на такие вопросы и приветы обычно вообще не отвечаю, и вот почему. Если есть что-то важное - человек обычно пишет о проблеме сразу, а я могу быстро отреагировать, когда в свободный промежуток увидел конкретный вопрос среди десятка других бестолковых сообщений-пустышек. Если там только "приветы", то обычно человеку просто одиноко и разговоры в аське превращаются не в решение проблем, а долгое обмусоливание и размышления вслух;
  • обсуждение одного и того же вопроса по email занимает 10-20 минут, в ICQ/скайпе -- минимум час-полтора. Поскольку в разговоре возникают паузы (то у одного, то у другого собеседника) и писать "словесного мусора" приходится гораздо больше, чем обычно пишешь в ответе на email. В общем, чат отвлекает от дел гораздо больше;
  • использование IM и чатов приводит к более частой отсылке отрывочных фраз, не всегда полностью завершённых, которые нетерпеливый собеседник может прервать новыми вопросами и обсуждениями, не дождавшись конца мысли. В итоге идёт винегрет обсуждения, часто нескольких вопросов, и разобраться в этой каше, что к чему относится, впоследствии становится очень трудно. Кто читал логи бурных быстрых обсуждений в попытке выловить из них конкретные задачи, планы и историю обсуждения вопроса или нескольких - поймёт, о чём речь. Кто пытался восстановить ситуацию по вчерашним-позавчерашним срочным разговорам, когда приходится переключаться между несколькими проектами (и все подробности в голове просто не удержишь) -- тоже в курсе проблемы;
  • иллюзия постоянной доступности человека в аське/скайпе/джаббере - лишь иллюзия. Когда именно я увижу сообщение - зависит лишь от наличия свободного времени, а не от сигнала. Чаще я смотреть туда не стану по каждому прерыванию, поскольку не в службе поддержки работаю, а для работы мне надо сосредоточиться и иметь возможность думать о задаче в течение достаточно длинных промежутков времени. Программисты так устроены: мы держим в голове массу деталей и связей, и нам надо построить в голове модель происходящих процессов, чтобы в ней ориентироваться. И если задачи сложные, а не 5-минутные, любое отвлечение способно разрушить весь этот воздушный замок и процесс "втягивания" приходится начинать заново.

Резюме

Почта удобна тем, что я в нее смотрю, когда свободен. И вся переписка хранится в едином месте. Доступная и с телефона, и с любого компьютера. В отличие от асек и скайпов, где концов не соберешь, потому что понять невозможно, где обсуждали тот вопрос, а где этот, а где файлы и пароли присылались, и на каком компьютере или телефоне этот лог разговора остался и где его теперь искать.

В общем, поймите: не человек - придаток машины, реагирующий на звоночки, а машина является инструментом думающего человека. И только человек решает, отвечать ли на звонки (как телефонные, так и их аналоги), когда он занят. А когда свободен - почту проверять раз в пять минут и чаще никто не мешает, уведомления на SMS получать тоже. Поверьте, скорость получения уведомлений там ничуть не хуже, чем у IM-клиентов.

Поэтому я за почту.

Скорость реакции на почту и IM - одинаковая (сюрприз!). Поскольку всё равно определяется скоростью моей реакции на ситуацию, а не скоростью света и чьими-то желаниями.

Hint: как облегчить другим работу с вашими письмами

Несколько мелочей и микро-правил, которые способны сделать другим жизнь проще при работе с вашими письмами.

Необязательно, но весьма желательно:

  • Никакого HTML оформления. Забудьте. Только plain text;
  • приветствия в эл. письмах при регулярной переписке -- штука бесполезная. То же самое обычно можно сказать о цитировании и перечислении даты и времени письма, на которое отвечаем. Через некоторое время люди перестают обращать внимание на эти служебные строки, иногда там просто "слепое пятно" образуется. Если на большом экране эти 1-2 строки мы просто "пропускаем мимо глаз", то на смартфонах это занимает пол-экрана. Лучше, когда сразу идёт текст по делу;
  • то же, но в меньшей степени, относится к подписи. Уместно в первом письме к новому собеседнику включить полную подпись со всеми контактами и телефонами, а в последующих, если переписка уже длится некоторое время, лучше иметь короткий вариант: с 1-2 контактами или единственной ссылкой на сайт (на страницу со всеми контактами). То ли на персональном сайте, то ли где-то в соцсетях (Linkedin, VK, Facebook, Google+), то ли в блоге (Livejournal, Wordpress, Blogspot и т.п.) Иметь сейчас страницу с полным списком контактов совсем несложно, заводить для этого свой сайт-визитку необязательно.

Внутренности писем:

  • разделяйте абзацы пустой строкой (два раза Enter, а не один). Если отвечаете после цитаты - также отделяйте ответ пустой строкой. Не пишите сразу на следующей строке после квотинга. Этим вы спасёте мозг и пальцы тех, кто работает с почтой на мобильных устройствах (смартфонах, в частности);
  • атомарность, одно письмо -- один вопрос. Лучше послать 10 коротких писем, чем одно большое с 10 разными вопросами. Это поможет легче работать с письмами как с задачами, а также спасёт в очередной раз мобильных пользователей (если не понимаете, о чём я - вы ни разу не пытались ответить на длинное письмо, находясь в пути и имея немного свободного времени). Как следствие - это способно значительно ускорить получение ответов: проще сразу ответить на 3-4 более простых вопроса с телефона, а пару более объёмных оставить для десктопа, чем если надо ответить на большое письмо с несколькими темами/проблемами. Редактировать большое письмо пальцами на смартфоне, пытаясь разбить его на более мелкие -- замучаешься;
  • если есть возможность - настройте почтовый клиент так, чтобы текст цитируемого письма располагался после подписи. Но в случае больших писем это будет неудобно. В случае с атомарными короткими сообщениями - очень удобно.

Hint: как облегчить себе работу с почтой

  • Исповедуйте правило пустого инбокса;
  • не пользуйтесь почтовым ящиком как хранилищем. Всё, что касается конкретных проектов - сразу сохраняйте в папке с проектом (если письмо вообще стоит хранить) в виде обычного текста. Имя файла должно включать как минимум дату (в ISO формате: YYYY-MM-DD). Можно ещё время, email или ник отправителя. Совсем необязательно сохранять одно письмо в одном файле: цепочки обсуждений удобно записывать в один большой файл (txt или markdown), а аттачменты складывать рядом (предваряя имя файла датой-временем). Но разрастание файла быстро становится неудобным, так что пробуйте и выбирайте по обстоятельствам золотую середину;

Не складируйте письма: всё, на что можно сразу ответить - отвечайте и удаляйте письмо. Не надо их разбрасывать по папкам, хранить в почтовом клиенте, сортировать с тем, чтобы когда-то почистить, создавать многочисленные правила автоматической сортировки. Всё это - пустая трата времени.

Что даёт сохранение писем в архиве в виде обычных текстовых файлов?

  • По ним легко и просто искать: как по именам файлов, так и по содержимому;
  • Их можно поместить в систему контроля версий для более удобной и надёжной работы с изменениями;
  • Их легко архивировать и переносить с проектом, не дёргаясь и не собирая хвосты из рабочего и личного почтового ящика, аськи, скайпа, IRC, и ещё Вася что-то с клиентом обсуждал отдельно в четверг, и ещё-не-помню-где=кажется-что-то-было... Всё, относящееся к проекту, собрано в одной папке, а не разбросано в нескольких программах. Возможно, у вас есть багтрекер -- это замечательно. Но тоже накладывает определенные ограничения. Если вы постоянно работаете в команде, и всегда в одной - пользуйтесь багтрекером. Потому что в этом случае велик шанс, что у вас есть дизайнеры и директор, далёкие от VCS, плюс ACL и клиенты с возможностью пускать их в PM/CRM/helpdesk инструмент с веб-доступом. Главное, чтобы было одно централизованное место для поиска всей связанной с проектом информации;
  • Из текстового `markdown` формата легко получить всевозможные красиво оформленные форматы: html, PDF, doc/ods/docx;
  • Рекомендую завести одно персональное место в качестве хранилища знаний (внешнего мозга), плюс в каждом проекте складывать в папку doc всю переписку и дела по этому проекту. Это позволит легко дать доступ к материалам проекта другим участникам при росте команды, а вас быстро приучит разделять личное (в т.ч. и личные проекты) и рабочее. Таким образом, у вас будет всего 2 места для поисков: либо в папке проекта, либо в персональном "внешнем мозге". У меня ещё есть отдельное "более медленное" место для материалов из интернета и книг. Там я храню их в запакованном виде и ищу по именам файлов и папок (файловой системе). Поскольку эти материалы более фундаментальные и реже используются для регулярной оперативной работы и редактирования.

См. также

Как облегчить процесс публикации изменений на сервер

[Git, FTP] Для FTP и shared hosting (без SSH доступа и полноценной консоли)

Рекомендую готовый скрипт git-extract:

По команде, в которой указывается диапазон коммитов, создаёт папку .deployment с готовым деревом и изменившимися файлами. И список удаленных файлов, которые придётся удалить вручную (если пользуетесь FTP клиентом) или через SSH на сервере (если есть такая возможность).

У скрипта есть маленькая особенность: запускать его надо в корне репозитория (там, где расположена скрытая папка `.git`). Не в подпапках из любого места репо: там он просто отработает вхолостую.

[Git, SSH] При полноценном хостинге (с SSH доступом)

Судя по всему, у меня сделано один в один как в http://habrahabr.ru/blogs/Git/127213/, поэтому не вижу смысла описывать то же самое. У меня немного отличается структура папок проектов, но это несущественно. Суть проста - на сервере лежит как Git-репозиторий, так и обычная рабочая копия (на которую смотрит веб-сервер). Точнее, на одну из папок репозитория - public_html. Потому что в репозитории хранится ещё документация, служебные скрипты, тестовые и чистые SQL дампы.

И при новых коммитах от разработчиков (git push) репозиторий по хуку делает автоматически две операции - обновление локальной серверной копии (git pull origin dev) и копирование набора файлов из config_sets (здесь у меня хранятся файлы, специфические для разных конфигураций: для одного разработчика, для другого, для dev2-windows, dev2-linux, для production1, production-dev и так далее, если надо ещё больше). Понятна идея? Требуемый набор конфигов просто перезаписывается поверх того, что есть в репозитории (а туда могут попасть и локальные конфиги девелоперов, если они не исключены через .gitignore), и получается чистая и настроенная конфигурация. Быстро, без чек-листов, ручных проверок-исправлений и условий-ветвлений с множеством девелоперских конфигов (зачем они на сервере?).

Естественно, на сервере настроено использование SSH-ключей, чтобы избавиться от необходимоси ввода пароля после git pull.

Есть, конечно, мелкие особенности - за неделю мы уже наступили на пару граблей и может это стоило бы описать.

См. также

[PHP, FTP] Web based FTP Sync Tool written in PHP. Есть возможность запрещать синхронизацию для отдельных файлов/папок.

[Windows, GUI] Сделать архив, содержащий только измененные файлы (сохранив при этом всю структуру папок) может также WinMerge: http://opencartforum.ru/topic/28606-решено-winmerge-как-сделать-изменения-в-движке-и-сохра/#entry223289

Завёл репозиторий для MaxSite CMS на GitHub-е

3 декабря 2011 г. Ruslan Brest Web development » MaxSite CMS7

https://github.com/rb2/MaxSite-CMS

Основная причина - неудобство предлагаемого способа обновления между релизами. Мне не хватает diff-ов и легкого способа их получения для чистых версий, чтобы иметь возможность накатить эти изменения вручную на модифицированный движок. Обновляться заменой файлов мне чрезвычайно неудобно.

Если кто-то хочет присоединиться к переводу на английский или правке украинского - теперь есть куда:

  • Исключительно языковые файлы живут и переводятся в соответствующих ветках репозитория https://github.com/g3d/MaxSite-TC (сейчас там украинский в ветке master и английская заготовка в ветке english).
  • Участвовать в корректировке переводов может любой человек, даже понятия не имеющий и не желающий разбираться с Git-ом: достаточно оставлять комментарии к строкам файлов при их просмотре. Тем, кто дружит с Git-ом, объяснять наверное ничего не надо.
  • Файлы скачивать можно там же: переключиться на соответствующую ветку ("Current branch" справа) и скачать ZIP.

В https://github.com/rb2/MaxSite-CMS живёт полностью CMS. Языки туда по мере готовности будут периодически вливаться.

Если автор MaxSite CMS переберётся на GitHub - это значительно упростит дело: можно будет предлагать/публиковать дополнения гораздо проще. Пока что я предполагаю держать этот репозиторий (по крайней мере основную ветку) только для "чистых" релизов версий CMS. И пускать разработчиков только с условием коммитить любые дополнения и модификации в соседние ветки, но не в master. Master branch сейчас - исключительно для оригиналов и получения списка отличий между ними.