Хэл Фултон - Программирование на языке Ruby

shall not perish from the earth.

EOS

pdf.text(speech, justification => :full, :font_size => 14,

:left => 50, :right => 50)

pdf.move_pointer(36)

pdf.text("U.S. President Abraham Lincoln, 19 November 1863",

:justification => :right, :right => 100)

pdf.text("Gettysburg, Pennsylvania", :justification => :right,

:right => 100)

pdf.rounded_rectangle(pdf.left_margin + 25, y0, pdf.margin_width - 50,

y0 - pdf.y + 18, 10).stroke

end

pdf.save_as("4page.pdf")

Рис. 15.4. Пример документа, состоящего из четырех страниц в разных квадрантах

Итак, в четырех квадрантах расположены следующие страницы:

• левый верхний: demo.rb;

• правый верхний: фотография Грампианских холмов, Шотландия;

• левый нижний: individual-i.rb;

• правый нижний: Геттисбергское обращение.

Для краткости будем называть эти квадранты UL, UR, LL и LR. В тексте программы используются соответствующие символы ( :ulи т.д.).

Первый квадрант (UL) заполнен вертикальными линиями, толщина которых постепенно уменьшается, начиная с 40 единиц, с одновременным осветлением. Затем рисуются круги увеличивающегося радиуса, при этом толщина линий уменьшается, а цвет становится светлее. И наконец, выводятся два набора текстов: один — сверху вниз с постепенным уменьшением размера шрифта, а другой — с поворотом вокруг центральной оси как раз там, где кончаются вертикальные линии.

Страница во втором квадранте (UR) содержит картинку и ее описание. Особый интерес представляет строка с датой. Мы вставляем в поток байт с кодом 0x01; при отображении вместо него будет поставлен символ ромба в соответствии с таблицей замены, заданной при выборе шрифта.

В третьем квадранте (UR) с помощью программы Individual-I мы снова демонстрируем технику переноса осей и масштабирования. Самое интересное здесь — инверсия осей. Если по оси выбирается отрицательный масштаб, то команды вывода текста и рисования меняют направление. Следовательно, при рисовании буквы I достаточно задать лишь правила формирования половины рисунка, а потом инвертировать ось X, вызвав метод pdf.scale_axis(-1, 1), и повторить ту же последовательность операций.

Последний квадрант (LR) заполняется сравнительно легко. Мы форматируем и заключаем в прямоугольник со скругленными углами текст речи, которую президент Линкольн произнес в Геттисберге.

Сохранение PDF-документа — воплощенная простота. Если нужно записать его на диск, мы вызываем метод save_asобъекта PDF:

pdf.save_as("4page.pdf")

Нетрудно также отправить PDF-документ браузеру из CGI-программы:

require 'cgi'

cgi = CGI.new

out = pdf.render

puts <<-EOS

Content-Type: application/pdf

Content-Disposition: inline; filename="4page.pdf"

Size: #{out.size}

EOS

Конечно, в этом разделе мы сумели затронуть лишь малую толику библиотеки PDF::Writer.Дополнительную информацию ищите в онлайновой документации. Если вы знакомы с форматом PDF, имейте в виду, что библиотека еще развивается и пока не поддерживает спецификацию в полном объеме.

В этой главе мы показали, как с помощью библиотеки REXML можно разбирать XML-документы, представленные в виде дерева DOM или потока. Познакомились мы и с интерфейсом REXML к языку XPath.

Был продемонстрирован разбор информации из новостных каналов, представленных в формате на базе XML. Библиотека rssумеет работать только с форматом RSS, а библиотека feedtoolsпонимает форматы RSS и Atom (и умеет преобразовывать из одного в другой).

Мы также видели, как можно читать и манипулировать графическими изображениями разного формата с помощью библиотеки RMagick. Рассмотрели мы и API рисования, позволяющий включать в изображение произвольный текст и геометрические фигуры. Наконец, мы показали, как с помощью библиотеки PDF::Writerможно создавать из программы сложные PDF-документы высокого качества.

Следующая глава посвящена совсем другой теме. Речь пойдет об эффективном тестировании и отладке написанных на Ruby программ.

Тестирование — вещь важная. Все компетентные программисты об этом знают, хотя не всегда этот вопрос стоит для них на первом месте.

Конечно, исчерпывающее тестирование, как правило, невозможно. Программа сколько-нибудь заметного размера на протяжении своего жизненного цикла обязательно преподнесет сюрпризы. Максимум, что мы можем сделать, — тестировать тщательно и избирательно, стараясь проверить как можно больше.

Исторически сложилось так, что программисты не всегда тестируют как положено. Объясняют это обычно тем, что тесты трудно готовить и прогонять, что вся процедура требует ручного вмешательства или отнимает слишком много времени.

В 1990 году в сообществе программистов стала распространяться «культура тестирования». Идеи экстремального программирования и управляемой тестами разработки начали овладевать умами разработчиков по всему миру.

Являетесь ли вы твердокаменным приверженцем идеологии «тестируй с самого начала», не так существенно. Важно, что любой человек может воспользоваться инструментами, которые позволяют автоматизировать тестирование, упростив написание и прогон тестов.

Такие инструменты, как Test::Unitи ZenTest, написать на Ruby было проще в силу динамичности и гибкости языка. Не менее легко и (посмею ли сказать?) приятно ими пользоваться. Внес изменение в программу, а потом смотришь, как все тесты успешно доходят до конца, — положительно в этом что-то есть!

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

«Стандартный» способ автономного тестирования компонентов в Ruby — библиотека Test::UnitНатаниэля Тэлбота (Nathaniel Talbott). Она была включена в дистрибутив Ruby еще в 2001 году.

В этой библиотеке для анализа тестового кода применяется отражение. Когда вы создаете подкласс класса Test::Unit::TestCase, все методы, имена которых начинаются с test, считаются тестовыми.

require 'test/unit'

class TC_MyTest < Test::Unit::TestCase

def test_001

# ...

end

def test_002

# ...

end

# ...

end

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

Нежелательно и, пожалуй, даже неправильно составлять тесты так, чтобы их поведение зависело от порядка запуска. Однако Test::Unitпрогоняет их в алфавитном (лексикографическом) порядке, поэтому, нумеруя свои методы, я вижу, как они выполняются в определенной последовательности.