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

tools

Инструменты совместной работы: что использовать для обсуждений и сбора информации

У меня очередной виток переосмыслений.

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

В скайпе обсуждения быстро теряются (и тегами или закладками интересующие места не пометишь), а при бурном обсуждении темы перемешиваются и обсуждать сложно. У вас же тоже наверняка бывало: пока один пишет ответ, другой собеседник успевает затронуть пару связанных вопросов. И тут надо или начинать цитировать, или говорить обо всём подряд. Разделить разговоры некак. И потом при желании сохранить историю разговора приходится выкусывать и облагораживать куски разговоров. Иначе получается фигня, которую и потом никто перечитывать и пользоваться этим логом не будет. Сохраняй, не сохраняй - результат один. Может разве что археологам когда-нибудь будет интересно.

По email мы как-то тоже не очень сейчас треды обсуждений ведём. Там в основном саппорт. А все обсуждения в скайп сами собой мигрировали. Хотя как раз email - один из самых достойных инструментов. Но с накоплением этой информации проблема - этим кто-то должен заниматься, перенося полезную часть переписки в вики, тудушки, багтрекер или куда там ещё.

Issues в битбакете или гитхабе и другие багтрекеры - тоже что-то не то для обсуждений и собирательства идей. В общем-то всё вроде доступно - и обсуждать, и собирать, и решать, и переносить, и назначать. И теги там есть - задачи фильтрации и категоризации с навигацией вполне решаются. Где теги, где категории, где milestones или ещё что подобное. Багтрекеры наряду с email для меня - очень ценные инструменты.

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

Надо что? Далее...

Знакомим `phpcs` (PHP CodeSniffer) и Sublime Text со стандартом оформления кода FuelPHP

UPD: При ближайшем рассмотрении оказалось, что отличий от PSR2 больше, чем табы вместо пробелов. Чтобы сделать автоматическую проверку, надо ещё многое переделать, а где-то и дописать. Так что я поспешил: с опубликованным вариантом проверять синтаксис PHP CodeSniffer'ом на соответствие правилам пока что неудобно.


Самый простой способ - поставить в редакторе/IDE правила автоформатирования PSR-2 и заменить использование пробелов в отступах на табуляцию (этим стандарты оформления кода, принятые в FuelPHP, отличаются от PSR-2). Заодно можно включить отображение пробелов и табуляций.

Это позволит писать новый код по правилам, но огрехи в старом могут оказаться незамеченными.

Для автоматизации проверки кода существуют разные инструменты: примеры (и важность с удобством применения этого непосредственно в редакторах/IDE) есть в статье http://philsturgeon.co.uk/blog/2013/08/php-static-analysis-in-sublime-text.

Обычно они дают возможность запустить проверку, либо настроить её и показ ошибки при сохранениях файла. Последнее очень удобно, т.к. помогает исправлять обнаруженные ошибки по ходу дела и без дополнительных усилий. Ниже - рецепт по автоматизации для ST3 (а может и ST2, если плагин совместим).

Знакомим phpcs и ST3 со стандатами оформления кода FuelPHP

  • sudo apt-get install php-codesniffer
    • phpcs -i - показать список установленных стандартов. Нужен psr2 (PSR-2)
    • Если его нет - обновляем полностью CodeSniffer (просто скопировать оттуда папку с PSR2/1 стандартом недостаточно)

    • Это, конечно, грубовато - обновлять напрямую, в обход apt-get , но он считает, что установлена самая свежая версия и более правильного способа я сейчас не знаю.

      cd ~/Downloads
      wget https://github.com/squizlabs/PHP_CodeSniffer/archive/master.zip
      unzip PHP_CodeSniffer-master.zip
      cd PHP_CodeSniffer-master
      sudo cp -r --parents -t /usr/share/php/PHP/ CodeSniffer CodeSniffer.php scripts
      cd scripts
      sudo mv /usr/bin/phpcs /usr/bin/phpcs.ORIGINAL
      sudo cp -t /usr/bin/ phpcs
    • в PSR-2 используются пробелы вместо табуляций и phpcs на них ругается. Сделаем свой стандарт "FuelPHP", основанный на PSR2. Рядом с папкой PSR2 создаём FuelPHP, в которой достаточно одного файла FuelPHP/ruleset.xml :

    • <?xml version="1.0"?>
      <ruleset name="FuelPHP">
       <description>The FuelPHP coding standard.</description>
       <!-- Include the whole PSR-2 standard -->
       <rule ref="PSR2">
       <!-- Redefine 2.4 Indenting -->
       <!-- Code MUST use an indent of tabs, and MUST NOT use 4 spaces for indenting. -->
       <exclude name="Generic.WhiteSpace.DisallowTabIndent"/>
       </rule>
       <rule ref="Generic.WhiteSpace.DisallowSpaceIndent"/>
      </ruleset>

      Проверяем: phpcs -i

      The installed coding standards are Zend, FuelPHP, PHPCS, PSR2, PSR1, Squiz,
      MySource and PEAR
  • install ST3 plugin "Sublime Phpcs" http://www.soulbroken.co.uk/code/sublimephpcs/
  • check config, see HOWTO: http://philsturgeon.co.uk/blog/2013/08/php-static-analysis-in-sublime-text
    • только мы вместо "psr2" теперь напишем свой "FuelPHP" в юзеркониге:

    • Содержимое /home/rb/.config/sublime-text-3/Packages/User/phpcs.sublime-settings :

      {
          "show_debug": true,
          "phpcs_executable_path": "/usr/bin/phpcs",
          "phpcs_additional_args": {
              "--standard": "FuelPHP",
              "-n": ""
          },
      }

Автоматическая проверка в ST3 тепрь работает.

Также можно использовать отдельно: phpcs --standard=fuelphp home.php .

PhantomJS - утилита для тестирования дизайна на разных экранах

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

Базируется на движке WebKit. Технически - это обычный броузер, но без интерфейса пользователя. Результаты рендеринга страницы и Javascript можно записать в виде картинки.

Testing your responsive design with PhantomJS.

Там описана установка из репозиториев для Ubuntu и MacOSX и пример использования -- результаты в виде скриншотов тоже можно разглядеть. Я с инструментом не работал, так что вряд ли смогу что-то добавить к тому, что написано в указанной статье.

Бекап Opencart сайта - checklist

23 апреля 2013 г. Ruslan Brest E-commerce » Howto » OpenCartОбсудить

Сайт обычно располагается в папке `public_html`.

  1. Папки `admin`, `catalog`, `download`, `system`, а также файлы `.htaccess`, `config.php`, `humans.txt`, `robots.txt`, `yandex_*.txt` -- это всё движок магазина. Те, кто использует VQmod, должны добавить к списку ещё папку `vqmod`.
    • файлы с точкой впереди - системные/скрытые. Поэтому их может быть не видно и надо включить в настройках FTP-клиента опцию их показа. `.htaccess` очень важен для работы сайта. Если у него есть расширение (.TXT или любое другое) - значит он сервером не используется (отключен). В этом случае не будут работать SEO URL;
    • в указанных папках есть 2 "лишние", их нежелательно включать в бекап: `system/cache`, `system/logs`. Это кешированные файлы и лог ошибок. Они нужны для работы и диагностики, но хранить их - смысла мало. Особенно если они большого объёма;
    • если вы пользуетесь VQmod-ом: папку `vqmod/logs` желательно исключить из бекапа. Папку 'vqmod/vqcache' можно бекапить, а можно и нет. Самое ценное здесь - содержимое `vqmod/xml`. Остальное несложно восстановить.
  2. Вторая важная часть сайта - картинки/фото.
  3. Они находятся в папке `image` (`public_html/image`). Оригиналы картинок - в папке `image/data`. Это самое ценное. Остальное несложно восстановить.

    • Что здесь бекапить: всю папку `image` за исключением `image/cache`
    • `image/cache` очень объемная. Эти файлы генерируются сайтом на лету при просмотре сайта. Ссылки на них могут использоваться в `sitemap.xml`.

  4. Третья критически важная часть сайта - база данных магазина. Её через FTP не скопируешь. Её надо бекапить либо Adminer-ом, либо phpMyAdmin (обычно есть в панели управления хостинга).

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:

Сравнение языковых файлов Opencart

23 февраля 2013 г. Ruslan Brest Howto » Linux » OpenCartОбсудить

При поиске различий в языковых файлах Opencart огромную неприятность доставляет то, что утилиты наподобие DIFF оказываются почти бесполезны. Они сравнивают файлы построчно, а поскольку приходится сравнивать английский файл с русским, то 99% строк разные из-за перевода. И найти в этих условиях новые и удаленные переменные в файлах локализации оказывается очень сложно и муторно. Графические аналоги подобных программ тоже не очень-то помогают, даже если способны подсвечивать разницу внутри одной строки: в глазах рябит, строки длинные, и после проверки пары каталогов эта рутинная и фактически ручная визуальная проверка просто выматывает.

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

В файлах локализации неизменной для русской и английской версии остается левая часть строк до знака '='. Их и будем сравнивать. На помощь утилите diff приходит утилита cut:

#!/bin/bash
diff -b <(cut -d'=' -f1 -s $1) <(cut -d'=' -f1 -s $2)

Указав этой утилитке имена двух файлов, получим краткий список отсутствующих и появившихся языковых переменных. Это то, чего мне долго не хватало!

Спасительная команда cut -d'=' -f1 -s setting.php выводит только первую часть строки (-f1), разделенной знаком '='. А diff сравнивает две этих "первых колонки" из обеих файлов, оставляя нам только разницу.

Opencart module extract (Linux shell script)

5 апреля 2012 г. Ruslan Brest Linux » OpenCart » Web development3

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

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

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

Далее...

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

[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

Первичные настройки Git

12 сентября 2011 г. Ruslan Brest Git, SVN » Howto » Linux » Web developmentОбсудить

Представляемся надолго, чтобы коммиты не были ничейными:

git config --global user.name "Your Name Comes Here"
git config --global user.email you@yourdomain.example.com

Облегчаем визуальное восприятие изменений:

git config --global color.diff auto
git config --global color.status auto
git config --global color.branch auto
git config --global color.ui auto

Не забываем про заплетающиеся пальцы (вы способны быстро набрать "status" без опечаток?! Раз 50 в день?!?! Ого!):

git config --global alias.st status
git config --global alias.ci commit
git config --global alias.co checkout
git config --global alias.logd 'log --oneline --graph --decorate'
git config --global alias.logdm 'log --oneline --graph --decorate --no-merges'
git config --global alias.logn 'log --pretty=format:"%cd %C(auto)%h (%an) %s%+b%d" --date=short'
git config --global alias.logst 'log --stat=140,100'
git config --global alias.logf 'log --stat=140,100'
git config --global alias.bav 'branch -av'
git config --global alias.rv 'remote -v'
git config --global alias.diffw 'diff --word-diff'

Проделав это один раз, можно добавить в свой бекап файл ~/.gitconfig, в котором настройки и хранятся. Или скопируйте его в Дропбокс, а в домашнем каталоге оставьте симлинк на этот файл.

И не забывайте про существование возможности авторизоваться на гит-сервере с репозиториями с помощью своего публичного SSH ключа: пара генерируется один раз, публичный ключ раздаёте тем, кто должен вас узнавать и пускать без стука, и забываете про ввод паролей.

Если нужен gitk, то перед вторым запуском (первый под Линуксом нужен, чтобы слегка удивиться, проморгаться и взбодриться) исправьте в ~/.gitk интерфейсные шрифты:

set mainfont {{andale mono} 9}
set textfont {{andale mono} 9}
set uifont {clean 10 bold}
set tabstop 4

Хотя это в принципе и через GUI сделать можно.

Eclipse PDT и Ubuntu

24 августа 2011 г. Ruslan Brest Linux » Web developmentОбсудить

Eclipse - монстрообразинко. Шевелится неторопливо, интерфейс разлапистый и на любителя. Сперва поставил полный (sudo apt-get install eclipse), а из него - последний доступный PDT (3.x.x) через Help - Install new software. Получил постоянные ошибки при попытках открыть PHP файлы, доустановил какой-то WST (на него были намёки в сообщениях об ошибках). Никаких изменений в лучшую сторону.

Вчера не выдержал, удалил всё и попробовал ограничиться малым: оставил только минимум эклипса (sudo apt-get remove eclipse && sudo apt-get autoremove && sudo apt-get install eclipse-platform), а PDT взял с Galileo репозитория (там только 2.x.x какая-то версия доступна, слово Galileo присутствовало на заставке Эклипса при запуске, хотя второй репозиторий не сам же собой появился). Наконец-то после всех его рестартов увидел Эклипс в работоспособном состоянии. Хотя на некоторых PHP файлах его всё равно плющит (например, он не может открыть index.php из приложения Yii фреймворка).

Поживёт пока. Знакомство с Yii Framework пока только добавляет плюсов к впечатлениям о CodeIgniter. С Eclipse пользоваться и изучать Yii и всю его перенавороченную иерархию странностей будет полегче, надеюсь.