В главу 10, "Ввод/вывод и хранение данных", я добавил материал о методе readpartial, неблокирующем вводе/выводе и классе StringIO. Также рассмотрены форматы CSV, YAML и KirbyBase. В ту часть главы 10, которая посвящена базам данных, включены сведения о СУБД Oracle и SQLite, интерфейсе DBI, а также об объектно-реляционном отображении (Object-Relational Mappers - ORM).
Глава 11, "ООП и динамические механизмы в Ruby", пополнилась информацией о таких недавно добавленных в язык конструкциях, как initialize_copy, const_get, const_missing и define_method. Также я рассматриваю делегирование и перенаправление.
Глава 12, "Графические интерфейсы для Ruby", была переработана целиком (в особенности разделы, посвященные GTK и Fox). Раздел по QtRuby - новый от начала до конца.
В главе 14, "Сценарии и системное администрирование", теперь обсуждаются моментальный инсталлятор для Windows и ряд аналогичных пакетов. Кроме того, улучшен код примеров.
В главе 18, "Сетевое программирование", появились разделы о вложениях в электронные письма и о взаимодействии с IMАР-сервером. Также рассматривается библиотека OpenURI.
В главе 19, "Ruby и Web-приложения", теперь рассматриваются продукты Ruby on Rails, Nitro, Wee, IOWA и другие инструменты для Web. Также уделено внимание инструментам WEBrick и в какой-то мере Mongrel
В главу 20, "Распределенный Ruby", добавлен материал о системе Rinda - реализации пространства кортежей, написанной на Ruby. Тут же приводятся сведения о родственной системе Ring.
Так ли необходимы все эти добавления? Да, уверяю вас.
Напомню, кстати, что "Путь Ruby" - это вторая вышедшая на английском языке книга по языку Ruby; первой была знаменитая "Мотыга", или "Programming Ruby", Дэйва Томаса (Dave Thomas) и Энди Ханта (Andy Hunt). Моя книга была составлена так, чтобы не перекрывать, а дополнять свою предшественницу; это и стало одной из основных причин ее популярности.
Когда я приступал к работе над первым изданием, еще не было международных конференций по Ruby. Не было сайтов Ruby Forge, ruby-doc.org, не было Wiki-страницы rubygarden.org. Вообще в Сети не было почти ничего, кроме официального сайта Ruby. В архиве приложений Ruby насчитывалось всего несколько сотен программ.
В то время лишь немногие периодические издания (как обычные, так и онлайновые) знали о существовании этого языка. Когда где-то публиковалась статья о Ruby, мы все брали ее на заметку; о ней сообщалось в списке рассылки и там же проводилось обсуждение.
Многих привычных сегодня инструментов и библиотек еще не существовало. Все пока было впереди: и система RDoc, и пакет REXML для анализа XML-документов. Математическая библиотека была куда беднее нынешней. Поддержка баз данных была фрагментарной, а драйверы ODBC и вовсе отсутствовали. Tk был чуть ли не единственным графическим интерфейсом. Приложения для Web разрабатывались в виде низкоуровневых CGI-сценариев.
Еще не появился "моментальный" инсталлятор для Windows. Пользователям Windows приходилось выполнять компиляцию исходных текстов в среде Cygwin или с помощью minigw.
Системы RubyGem не было даже в примитивной форме. Процедура поиска и установки приложений проводилась вручную; для решения этой задачи использовались инструменты типа tar и make.
Никто слыхом не слыхал о Ruby on Rails. Никто (насколько мне известно) не употреблял термина "утипизация". Не было ни YAML для Ruby, ни системы Rake.
В то время мы пользовались версией Ruby 1.6.4 и считали ее безмерно крутой. Но Ruby 1.8.5 (с которой я обычно работаю сейчас) еще круче!
Был незначительно изменен синтаксис, но не настолько серьезно, чтобы об этом писать. По большей части речь идет о "граничных случаях", и теперь синтаксис в этих ситуациях выглядит более разумно. Ruby всегда отличали странности в отношении к необязательности скобок; в 98% случаев вы никакой разницы не заметите, а если заметите, то, наверное, согласитесь, что язык стал более последовательным.
Изменилась семантика некоторых системных методов. Но несущественно. Например, раньше метод Dir#chdir не принимал в качестве параметра блок, но несколько лет назад это стало допустимо.
Некоторые системные методы объявлены устаревшими или переименованы. Метод class утратил свой псевдоним type (поскольку в Ruby мы обычно не говорим о типах объектов). Метод intern получил более понятное название to_sym, а метод Array#indices называется Array#values_at. Можно было бы продолжить, но думаю, что суть вы уловили.
Кроме того, было добавлено несколько новых системных методов, например Enumerable#inject, Enumerable#zip и IO#readpartial. Старая библиотека futils теперь называется fileutils, и у нее появилось собственное пространство имен FileUtil, тогда как раньше она добавляла методы в класс File.
Есть и еще много изменений. Но важно понимать, что все они вносились очень осторожно и аккуратно. Язык как был Ruby, так им и остался. Красота Ruby в немалой степени обязана тому факту, что он изменяется медленно и обдуманно, ведомый мудростью Маца и других разработчиков.
Сегодня нет недостатка в книгах по Ruby. Публикуется больше статей, чем мы в состоянии переварить. Множатся руководства и документация в сети Web.
Появились новые инструменты и библиотеки. По разным причинам большая их часть - это каркасы и инструменты для разработки Web-приложений, средства для создания сетевых дневников (блогов), разметки, а также для объектно-реляционного отображения (ORM). Но есть и инструментарий для работы с базами данных, организации графических интерфейсов, математических расчетов, Web-сервисов, обработки изображений, управления версиями и т.д.
Поддержка Ruby в редакторах широко распространена и достигла немалой изощренности. Существуют интегрированные среды разработки (IDE), весьма полезные и зрелые; частично они перекрываются с конструкторами графических интерфейсов.
Нет сомнений и в том, что сообщество пользователей разрослось и изменилось. Сегодня Ruby никак не назовешь нишевым языком: им пользуются в НАСА, Национальной администрации по океану и атмосфере (NOAA), компании Motorola и во многих других крупных организациях. Он применяется для работы с графикой, доступа к базам данных, численного анализа, Web-приложений и в других областях. Короче говоря, Ruby стал весьма популярным языком.
Я работал над новой редакцией этой книги с любовью. Надеюсь, что она окажется вам полезной.
Как организована эта книга
Вряд ли вы станете изучать Ruby по этой книге. В ней не так уж много вводного и учебного материала. Если вы еще ничего не знаете о Ruby, то лучше начать с какой-нибудь другой книги.
Но программисты - народ упорный, и я допускаю, что научиться Ruby только по этой книге возможно. В главе 1, "Обзор Ruby", приводится краткое введение в язык и очень скромное руководство.
Также в главе 1 есть довольно полный перечень "скользких мест" (который трудно поддерживать в актуальном состоянии). Для разных читателей этот перечень полезен в разной мере, поскольку что для одного интуитивно очевидно, для другого выглядит странно.
В основном эта книга призвана отвечать на вопросы типа "Как сделать?". И потому вы, вероятно, многое будете пропускать. Я почту за честь, если кто-то прочтет книгу от корки до корки, но не надеюсь на это. Скорее я ожидаю, что вы будете искать в оглавлении темы, которые вас интересуют в конкретный момент. Впрочем, с момента выхода первого издания мне приходилось беседовать с разными людьми, и оказалось, что многие прочли книгу целиком. Более того, несколько человек писали мне, что выучили по ней Ruby. Что ж, все возможно!..
Некоторые рассматриваемые в книге вопросы могут показаться элементарными. Но ведь у разных людей и опыт разный; то, что очевидно одному, будет откровением для другого. Я старался сделать изложение как можно более полным. С другой стороны, было стремление уложиться в разумный объем (ясно, что эти цели противоречивы).
Можно назвать эту книгу "справочником наоборот". Вы ищете то, что нужно, не по имени класса или метода, а по функции или назначению. Например, в классе String есть несколько методов для манипулирования регистром букв: capitalize, upcase, casecmp, downcase и swapcase. В настоящем справочнике они встречались бы в алфавитном порядке, а в этой книге собраны в одном месте.
Конечно, в борьбе за полноту охвата материала я иногда сворачивал на путь, которому следуют справочные руководства. Во многих случаях я старался компенсировать это, предлагая не совсем обычные примеры или разнообразя их по сравнению со справочниками.
Я старался не перегружать код комментариями. Если не считать первой главы, то думаю, что достиг этой цели. Писатель может стать не в меру болтливым, но программист-то хочет видеть код (а если не хочет, то должен хотеть).
Иногда примеры выглядят искусственными, за что я приношу свои извинения. Проиллюстрировать какой-то прием или принцип в отрыве от реальной задачи бывает сложно. Но чем сложнее задача, чем выше ее уровень, тем большие усилия я прилагал к подысканию реального примера. Так, если речь идет о конкатенации строк, то, наверное, вы увидите безыскусный фрагмент кода с упоминанием пресловутых "foo" и "bar", но когда рассматривается тема разбора XML-документа, будет приведен куда более содержательный и реалистичный пример.
Есть в этой книге два-три каприза, в которых хочу заранее сознаться. Во-первых, я всеми силами старался избегать "уродливых" глобальных переменных типа $_ и ей подобных, пришедших из языка Perl. Они есть в Ruby и прекрасно работают, даже применяются в повседневной работе всеми или большинством программистов. Но почти всегда от их использования можно уйти, что я и позволил себе чуть ли не во всех примерах.
Другой каприз состоит в том, что я избегаю пользоваться обособленными выражениями, если у них нет побочных эффектов. В Ruby выражения - одна из основ языка, и это прекрасно; я старался извлечь из этой особенности максимум пользы. Но во фрагментах кода предпочитаю не употреблять выражения, которые просто возвращают никак не используемое значение. Например, для иллюстрации конкатенации строк достаточно было бы написать "abc" + "def", но я в этом случае пишу что-то вроде str = "abc" + "def". Кому-то это покажется излишеством, но выглядит естественным для программиста на языке С, привыкшего к тому, что бывают функции типа void и не-void (а также программисту на Pascal, мыслящему в терминах процедур и функций).
Третий каприз заключается в моем нежелании употреблять символ решетки для обозначения методов экземпляра. Многие поклонники Ruby считают, что я проявляю излишнюю болтливость, когда пишу "метод экземпляра crypt класса String", а не просто string#crypt, но я полагаю, что так никто не запутается. (На самом деле мне придется постепенно смириться с использованием такой нотации, так как ясно, что она уже никуда не исчезнет.)
Я старался давать ссылки на внешние ресурсы там, где это уместно. Ограничения по времени и объему не позволили мне включить в книгу все, что я хотел бы, но надеюсь, что это хотя бы отчасти компенсируется указаниями на то, где найти недостающую информацию. Из всех источников самым главным, наверное, следует считать архив приложений Ruby (Ruby Application Archive) в сети; вы не раз встретите ссылки на него.
В начале книги принято приводить соглашения об использовании шрифтов, применяемых для выделения кода, и о том, как отличить пример от обычного текста. Но я не стану оскорблять вас недоверием к вашим умственным способностям, - вы ведь и раньше читали техническую литературу.
Хочу подчеркнуть, что примерно 10% текста книги было написано другими людьми. И это не считая технического редактирования и корректуры!.. Вы просто обязаны прочитать благодарности, приведенные в этой (и любой другой) книге. Большинство читателей пропускают их. Прошу, прочтите прямо сейчас. Это будет так же полезно, как питание овощами.
Об исходных текстах, приведенных в книге
Все сколько-нибудь значительные фрагменты кода собраны в архив, который можно загрузить из сети. Этот архив есть на сайте www.awprofessional.com и на моем собственном сайте (www.rubyhacker.com).
Он предлагается в виде tgz-файла и в виде zip-файла. При именовании файлов в нем принято следующее соглашение: код, которому в тексте соответствует пронумерованный листинг, находится в файле с таким же именем (например, listing14-1.rb). Более короткие фрагменты именуются по номеру страницы, возможно, с добавленной буквой (например, p260a.rb и p260b.rb). Совсем короткие фрагменты, которые нельзя исполнить "вне контекста", в архиве обычно отсутствуют.
"Путь Ruby"
Что мы имеем и виду, творя о Пути Ruby? Я полагаю, что тут есть два взаимосвязанных аспекта: философия проектирования Ruby и философия использования этого языка. Естественно, что дизайн и применение связаны друг с другом, будь то программное или аппаратное обеспечение. Иначе зачем бы существовала наука эргономика?.. Если я снабжаю устройство ручкой, то, наверное, предполагаю, что кто-то за эту ручку возьмется.
В языке Ruby имеется невыразимое словами качество, которое делает его тем, что он есть. Мы наблюдаем это качество в дизайне синтаксиса и семантики языка, присутствует оно и в написанных на нем программах. Все же стоит попытаться сформулировать, в чем состоит эта отличительная особенность.
Очевидно, Ruby - не просто инструмент для написания программ, но и сам по себе является программой. Почему работа программ, написанных на Ruby, должна следовать законам, отличным от тех, которым подчинена работа интерпретатора? В конце концов, Ruby - исключительно динамичный и расширяемый язык. Могут найтись причины, по которым эти два уровня где-то расходятся, вероятно, стараясь приспособиться к несовершенству реального мира. Но в общем случае мыслительные процессы могут и должны быть сходными. Интерпретатор Ruby можно было бы написать на самом Ruby, в полном соответствии с принципом Хофштадтера, хотя в настоящее время это еще не сделано.
Мы нечасто задумываемся над этимологией слова "путь", но оно употребляется в двух разных смыслах. Во-первых, это метод или техника, а во-вторых - дорога. Ясно, что оба значения взаимосвязаны, и, говоря "путь Ruby", я имею в виду и то и другое.
Следовательно, мы говорим о мыслительном процессе, но вместе с тем и о дороге, по которой движемся. Даже величайшие гуру программирования не могут сказать о себе, что достигли совершенства: они лишь на пути к нему. Таких путей может быть несколько, но я здесь говорю только об одном.
Привычная мудрость гласит, что форма определяется функцией. Это верно, спору нет. Однако Фрэнк Ллойд Райт (имея в виду свою собственную область интересов) как-то сказал: "Форма определяется функцией, которая была понята неправильно. Форма и функция должны быть едины, сливаться в духовном единении".
Что Райт имел в виду? Я бы сказал, что на этот вопрос вы найдете ответ не в книгах, а в собственном опыте.
Однако я думаю, что Райт выразил эту мысль где-то еще, разбив ее на части, которые проще переварить. Он был великим поборником простоты, который однажды заметил: "Самые полезные инструменты архитектора - это ластик рядом с чертежной доской и гвоздодер на строительной площадке".
Итак, одним из достоинств Ruby является простота. Надо ли цитировать других мыслителей, высказывавшихся на эту тему? Согласно Антуану де Сент-Экзюпери, "совершенство достигнуто не тогда, когда нечего добавить, а тогда, когда нечего убрать".
Но Ruby - сложный язык. Почему же я называю его простым?
Если бы мы лучше понимали мироздание, то, наверное, открыли бы "закон сохранения сложности" - факт, который вмешивается в нашу жизнь подобно энтропии, которую мы не можем преодолеть, а способны лишь рассеивать.
И в этом ключ. Нельзя избежать сложности, но можно укрыться от нее. Мы можем убрать ее из виду! Это тот же старый добрый принцип черного ящика, внутри которого решается сложная задача, хотя на поверхности лишь голая простота.
Если вам еще не наскучили цитаты, то будет уместно привести слова Альберта Эйнштейна: "Все должно быть просто настолько, насколько возможно, но не проще".
Таким образом, на взгляд программиста, Ruby - это воплощенная простота (хотя у человека, отвечающего за сопровождение интерпретатора, взгляд может быть иной). Но вместе с тем имеется пространство для компромиссов. В реальном мире всем нам приходится немного "прогибаться". К примеру, все сущности в программе на Ruby должны были бы быть истинными объектами, однако некоторые, в том числе целые числа, хранятся как непосредственные значения. Это компромисс, знакомый всем студентам отделений информатики уже много десятилетий: элегантность дизайна приносится в жертву практичности реализации. По существу, мы променяли одну простоту на другую.
То, что Ларри Уолл говорил о языке Perl, остается справедливым: "Когда вы хотите что-то выразить на маленьком языке, оно становится большим. А когда вы пытаетесь выразить то же самое на большом языке, оно становится маленьким". Это верно и в отношении английского языка. Если биолог Эрнст Хэккель смог всего тремя словами выразить глубокую мысль "онтогенез повторяет филогенез", то лишь потому, что эти слова с весьма специфическим смыслом были в его распоряжении. Мы соглашаемся на внутреннюю сложность языка, потому что она позволяет избежать сложности в отдельных высказываниях.
Переформулирую этот принцип по-другому: "не пишите 200 строк кода, когда достаточно 10".
Я считаю само собой разумеющимся, что краткость в общем случае хороша. Короткий фрагмент кода занимает меньше места в мозгу программиста, его проще воспринять как единое целое. Благоприятным побочным эффектом следует считать и то, что в короткой программе будет меньше ошибок.