софт, хард & интERнет

По принципу “лучше перебдеть”!

Оказывается, пользователи WordPress с ролью Автор не могут толком пользоваться плагином wp-syntax — содержимое <pre lang=”…”>…</pre> автоматически экранируется. Дело оказалось в том, что Автору не доступна возможность unfiltered_html. Для Редактора и Администратора все в порядке. Есть подозрение, что часть жалоб на домашней странице плагина вызвана именно этим.

А здесь написано, как добавить в редактор WordPress (HTML Source, не WYSIWYG) кнопку для быстрой вставки кода и изменить величину отступа при использовании табуляций: Posting source code in WordPress: escaping and syntax highlighting the inserted code. Заодно сделано и экранирование, которое плагин делает автоматически, если у пользователя правильная роль. Так что я открутил эти изменения обратно, файл получился такой: quicktags.js.

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

C недавних пор при первом заходе на этот сайт стало появляться предупреждение:

Warning: ob_start() [ref.outcontrol]: output handler ‘ob_gzhandler’ cannot be used after ‘URL-Rewriter’ in /www/giftinha/www/htdocs/wp-includes/functions.php on line 408

В этой строке находится вызов ob_start( ‘ob_gzhandler’ );

Гугл решение не подсказал, хотя соощения об аналогичной ошибке есть, причем, для разных CMS. Говорят, дело в конфигурации сервера. Хостер мой запрос отразил — никаких изменений, якобы, не было.

Workaround нашелся: в настройках WordPress можно запретить упаковывать статьи, но это временное решение.

Времени с этим разбираться нет совершенно, может, кто-нибудь подскажет?

Конечно, классы в Ruby открыты для расширения. Но порядок интерпретации влияет на результат. Пример:

class A
end
 
class B < A
end
 
class B
   def m
   end
end

Так работает. Но если поменять местами два последних определения, то возникает сообщение об ошибке: superclass mismatch for class B (TypeError), поскольку указать базовый класс можно только при первоначальном определении класса.

Вообще, возможность добавления методов в существующий класс заставляет переосмыслить роль механизма наследования. На первый взгляд, в Ruby с открытыми определениями классов, динамической типизацией и duck typing наследование не требуется!

Программисты, “думающие” на C++/Java часто используют наследование не по назначению. Обсуждая с коллегой вопрос “зачем нужно наследование?” я наткнулся на быстрый ответ: для переиспользования кода. В этом и есть корень зла — при отсутствии нормальных механизмов повторного использования кода в этом качестве начинают использовать наследование. Но в Ruby-то такие механизмы есть. Так зачем наследование?

Похоже, что в Ruby и подобных языках наследование вернулось к своему первоначальному назначению — выразить намерение программиста, что один тип является подтипом другого. Кстати, если вспомнить принцип подстановки Лисков (Liskov substitution principle), то становится понятно, что подтип (subtype) тесно связан с подстановкой (substitution).

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

Продолжаю погружаться в мир Ruby. Для систематического рассказа пока не время, но путевых заметок уже накопилось, пора записывать для памяти.

Далее »

Новогодние каникулы оказались подходящим случаем для общего знакомства с Ruby. Особой склонности к языкам с динамической типизацией я не испытываю — применимость их в больших проектах весьма сомнительна. В Ruby же привлекли возможности метапрограммирования и их использование для реализации DSL (Domain Specific Languages). Кроме того, хотелось понять, что позволяет преодолеть недостатки динамической типизации при использовании Ruby в достаточно больших проектах.

Далее »

За полгода в фоновом режиме перевел сборку подконтрольных проектов на Ant+Ivy. До этого использовался Maven 1, который функционально устраивал, но требовал создания правильного окружения — Maven правильной версии, правильный набор плагинов правильных версий, иногда правильно пропатченных. В результате доходило до абсурда — один из проектов собирался только на одной машине, попытки воссоздать окружение на другой ни к чему не привели.

Все это подтолкнуло к упрощению процесса сборки — переходу обратно на Apache Ant. При этом требования к окружению свелись к минимуму — должен быть установлен Sun JDK, Ant правильной версии (1.7) и “большие” библиотеки (типа Eclipse).

Конечно, Ant требует описания процесса сборки для каждого проекта, а в Maven для проектов стандартной структуры стандартная сборка уже описана. Ну что ж, пришлось оформить описание сборки виде библиотеки. Теперь на новый простой проект трачу не больше времени, чем при использовании Maven. Библиотека опубликована под именем Buildbase, уже достаточно функциональна и стабильна, но как самостоятельный проект не рекламируется.

Второе преимущество Maven - управление зависимостями: описание зависимостей, скачивание недостающих артефактов из репозитория и т.п. Сначала я нашел простенькую библиотеку и временно перевел все на нее. Затем разобрался с Ivy и понял, что реализация управления зависимостями в этом инструменте сделана гораздо грамотнее, чем в Maven. Написать про Ivy обещал уже давно, мешала одна непонятность - не мог понять, как использовать локальный кэш зависимостей. Месяц назад разобрался и с этим, читайте Getting Started with Ant+Ivy.
Далее »

Могу сформулировать техническое задание на плагин для WordPress для определения популярных записей за последние N дней. До смены дизайна я пользовался XNUKE-Counterpost и понял, что общее количество посещений записи не очень интересно. Более информативно видеть количество посещений за последние N дней. Тогда на топе действительно будут те записи, которые популярны в последнее время. Никому такой плагин не попадался?

Попробую перечислить свои пожелания, вдруг у кого-нибудь руки зачешутся реализовать. Вроде, несложно.

1. Настройка: N - количество дней, за которые накапливается статистика.
2. Плагин должен обеспечивать сбор статистики за последние N дней. Логически это N счетчиков посещения для каждой страницы. Ежедневно самый старый счетчик заменяется на счетчик для текущего дня.
3. Плагин должен предоставлять возможность вывода самых читаемых за последние N дней статей в указанной категории. Если категория не указана, учитываются все статьи.

Интерфейс как у XNUKE-Counterpost - функция на сбор статистики, функция на вывод.

Предыдущая часть закончилась выводом о необходимости использования метрик для оценки качества тестирования и обещанием классифицировать используемые метрики (они же — критерии тестового покрытия). Обещания надо выполнять.
Далее »