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

Web development

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 сейчас - исключительно для оригиналов и получения списка отличий между ними.

Загрузка jQuery по требованию

Оригинал: Load jQuery on demand | Web-developer notepad

Для загрузки jQuery по требованию вы можете пользоваться скриптом loadJquery.js.

Быстрый старт

Загрузите скрипт по этой ссылке, отредактируйте его нижнюю часть после слов PUT YOUR CODE HERE, вот эту:

(function () {
...
    /* <hr /><hr /><hr /><hr /><hr /> PUT YOUR CODE HERE <hr /><hr /><hr /><hr />-- */
    loadJquery({
        url: 'http://code.jquery.com/jquery-latest.min.js',
        timeout: 5000, //ms
        success: function ($) {
            $('h1').css('border', '2px solid red');
        },
        error: function () {
            alert("Can't load jQuery.");
        }
    });
}());

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

  • кроссбраузерность
  • основан на коде jquery 1.7.2
  • отлов исключений при помощи try/catch
  • возможность указания таймаута загрузки
  • загрузка не будет производиться, если jQuery уже загружен.
  • простота использования для конечного пользователя: просто пишите свой код в success/error-колбеки
  • отсутствие конфликтов с другими js-библиотеками типа prototype.js
  • скрипт проходит jslint-валидацию

Теперь больше информации для тех, кто хочет узнать подробности.

Далее...