Третий рельс

Не о трамваях и даже не о метро, а о Ruby On Rails и о CodeGear 3rd Rail


Вступление

Ruby On Rails1, по мнению многих аналитиков, - самая перспективная из существующих сейчас web-технологий. Столько восторженных отзывов от самых закоренелых скептиков, которые предрекали скорую кончину Perl'a и гибель Windows как серверной ОС, заставляют обратить внимание на этот продукт даже тех, кто использует PHP или ASP.NET и переходить ни на что другое пока не планирует.

Довольно серьёзный интерес в сообществе web-разработчиков вызвал состоявшийся буквально чуть больше недели назад выпуск компанией CodeGear среды разработки для Ruby On Rails - 3rd Rail. Напомню, что CodeGear - это подразделение легендарной Borland, которое специализируется на средах разработки и других продуктах, с которыми в итоге будет иметь дело непосредственно программист. 3rd Rail - первая полноценная интегрированная среда разработки для Ruby On Rails, и по этому поводу я решил рассказать о нём читателям "Компьютерных вестей". Но для того, чтобы лучше представлять себе, что же это такое, сначала, думаю, стоит рассказать непосредственно о Ruby On Rails.


Ruby On Rails, открой личико!

 

Ruby - это интерпретируемый язык программирования, не менее мощный, чем чуть более известные Python и Perl. Придумал и реализовал его японец Юкихиро Мацумото. Основная идея, который руководствовался автор языка, - это создание мощного объектно-ориентированного, но при этом интерпретируемого языка. В Японии этот язык стал популярен ещё в конце девяностых, но по всему миру распространился уже в двадцать первом столетии. О Ruby можно рассказывать долго, потому что язык действительно интересный, и, наверное, когда-нибудь я расскажу о нём подробнее. Но при чём тут рельсы - вот что сейчас гораздо интереснее и важнее.

Ruby On Rails - это фреймворк (русский аналог этого слова будет звучать, пожалуй, как каркас) для разработки web-приложений на языке Ruby. То есть, это набор библиотек для Ruby, которые позволяют легко и быстро создавать web-приложения, а при этом ещё и манят разработчиков модным словом AJAX. Логотип проекта (кстати, на мой взгляд, весьма привлекательный) вы можете увидеть на иллюстрации. Вы потом узнаете его, если будете работать с IDE 3rd Rail: он там повсюду.

Одна из главных идей Ruby On Rails - использование архитектуры MVC (Model-view-controller, или модель-представление-контроллер), которая призывает разделять данные, интерфейс и бизнес-логику приложения на отдельные части. При таком подходе обычно главную роль играют данные (обычно говорят о модели данных), в то время как представление (т.е. интерфейс) и логика приложения (она же контроллер) уже строятся исходя из имеющейся модели данных.

Идеология Ruby On Rails предусматривает ещё некоторые положения, которые, видимо, также очень сильно приглянулись web-разработчикам. Например, концепция MVC дополняется идеей о том, что ничего, кроме этой архитектуры, разработчику и не нужно, т.е. "приложения не должны определять собственную архитектуру, поскольку они используют готовый каркас модель-представление-контроллер". Язык Ruby - тоже часть идеологии "рельсового" фреймворка, поскольку это один из самых передовых (по мнению разработчиков Ruby On Rails) интерпретируемых языков программирования. Он позволяет создавать довольно простой код в рамках архитектуры MVC, и, что немаловажно для open-source проектов, код на языке Ruby хорошо воспринимается и программистами, привыкшими к другим распространённым языкам. Что ещё более важно, Ruby on Rails предоставляет механизмы повторного использования, позволяющие минимизировать дублирование кода в приложениях - это тоже часть идеологии проекта. Ну и, наконец, по умолчанию для фреймворка используется конфигурация, типичная для большинства приложений, что не может не порадовать тех, кто только начинает вхождение в мир Ruby On Rails.

Но главное преимущество Ruby On Rails - это, как ни крути, всё же ускорение работы. Вот что пишет по этому поводу в своём блоге web-разработчик Александр Лебедев (alexlebedev.com/blog, не путать с Артемием Лебедевым!): "В целом, при работе с Rails возникает ощущение, что попал в светлое завтра веб-разработки. На вещи, которые делаешь в первый раз, времени уходит столько же, сколько на реализацию того же самого в десятый раз на том, с чем я работал раньше. Начиная со второго раза - в два-три раза меньше. Сравниваю, в первую очередь с PHP, ASP и ASP.NET, с которыми я более-менее серьезно работал в прошлом, и с Django, знакомым по паре микроскопических проектов, сделанных для собственного удовольствия". Вообще же стоит почитать некоторые материалы2, написанные профессионалами, об их первом взгляде на Ruby On Rails и о практическом применении теорий и идей, заложенных в этот фреймворк его авторами.

Но всё же главным русскоязычным источником информации по Ruby On Rails является сайт www.rubyonrails.ru. Если вас интересует такая перспективная технология, как Ruby On Rails, то лучше, в первую очередь, обратиться именно к этому ресурсу.

Но всё же дальнейшее знакомство непосредственно с Ruby On Rails лучше оставить на потом - как видите, источников информации огромное количество, да и Ruby не слишком сложный язык для тех, кто освоил PHP, ASP/ASP.NET или даже довольно экзотический для СНГ'шных web-технологий Python. Я бы мог, конечно, рассказать и о Ruby, и о Ruby On Rails подробнее, но не буду. Просто объём газетного номера ограничен, а хотелось бы рассказать и о разработке компании CodeGear - 3rd Rail. Собственно, прямо сейчас, не откладывая в долгий ящик, и начну.


Третий рельс - апгрейд двух уже существующих?

Ruby On Rails, несмотря на всю перспективность технологии, давно не хватало того, чем PHP и ASP.NET уже могли похвастать, а именно - хорошей IDE (Integrated Development Environment - интегрированной среды разработки). Нельзя сказать, что этот компонент процесса разработки был бы так уж жизненно необходим с чисто технической точки зрения, но, на самом-то деле, без хорошей среды разработки продвинуть продукт в массы бывает непросто. Хотя для многих программных продуктов (например, для того же PHP) пристойные IDE появились много после выхода в свет самого интерпретатора. В общем-то, и для Ruby On Rails эта фраза тоже вполне справедлива, но, к счастью, хорошая среда для Ruby, а в особенности для Ruby On Rails, теперь есть. И постаралось, как я уже говорил, подразделение по средам разработки компании Borland - дочерняя компания CodeGear. Найти в Интернете 3rd Rail можно по адресу www.codegear.com/products/3rdrail. Заранее приготовьтесь к тому, что для скачивания понадобится зарегистрироваться. И, кстати, есть trial-версии IDE не только для Windows, как это было с Delphi for PHP, но и для Linux и MacOS X. "Весят" все дистрибутивы среды около трёхсот "метров".

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

Но это просто лирическое отступление. Правда жизни же состоит в том, что основой для очередной среды разработки от CodeGear послужила очень и очень известная open-source IDE Eclipse. Это, с одной стороны, уже заранее означает удобство использования, а, с другой, для разработчиков, с Eclipse незнакомых, может означать и некоторые проблемы, связанные со своеобразием этой среды. Хотя их, думаю, будет не так уж много. Потому что если программист работал в любой современной среде разработки, то он со всем в любой ипостаси Eclipse разберётся.

Возможностей и удобств в 3rd Rail много. Во-первых, конечно же, редактор исходного кода, поддерживающий и автодополнение кода, и подсказки, и подсветку открывающей и закрывающей скобок. Во-вторых, навигация по коду (которого, впрочем, думается, будет меньше, чем при использовании большинства других технологий создания web-приложений). Кроме навигации по коду, естественно, есть и навигация по проекту, в целом, и этот вариант навигации, полагаю, будет уже более востребован - ведь Ruby On Rails ориентирован именно на крупные и трудоёмкие проекты. В-третьих, мощные возможности рефакторинга исходного кода, характерные для всех интегрированных сред производства CodeGear. В-четвёртых, 3rd Rail уже содержит в себе все необходимые для запуска и отладки приложений компоненты, включая интерпретатор Ruby и фреймворк Ruby On Rails, а также дистрибутивы СУБД Interbase и MySQL. Так что можно просто скачать и приступать к разработке какого-нибудь сайта. В-пятых, новинка именно этой среды разработки: CodeGear Commanders. Хоть и звучит это угрожающе, будто бы среда разработки намеревается командовать программистом, но на деле всё не так плохо, и даже, я бы сказал, совсем наоборот. Это просто встроенные в среду инструменты для взаимодействия с приложениями командной строки, которые входят в Ruby On Rails и позволяют продуктивно генерировать код. Это, на мой взгляд, едва ли не главное достоинство среды разработки именно для использования библиотеки Ruby On Rails. Кроме того, есть в 3rd Rail и другие полезные вещи: встроенный браузер на движке Gecko (том, который используется в продуктах Mozilla), встроенный отладчик JavaScript-кода, инспектор DOM, монитор запросов, просмотрщик "логов", проводник по базе данных и ещё масса полезностей, которые все перечислять, пожалуй, и не стоит, потому что лучше один раз увидеть, чем сто раз услышать. Имеется возможность использования среды в командной разработке, поскольку в неё уже встроены специальные средства для работы с CVS и Bugzilla. Но так как среда основана на Eclipse, то можно расширить её функциональность соответствующими плагинами.

К представлению своего мощного и вообще всесторонне замечательного программного продукта во Всемирной паутине CodeGear тоже подошла основательно. На главной странице продукта размещены высказывания авторов языков Ruby и библиотеки Ruby On Rails. Например, Юкихиро Мацумото (напомню, это создатель языка Ruby) говорит о 3rd Rail следующее: "3rdRail has a well designed and very impressive interface which covers programmers at all levels from beginners to experts". То есть, если по-русски, "3rd Rail имеет хорошо спроектированный и очень впечатляющий интерфейс, который подходит программистам всех уровней - от новичков до экспертов". Создатель Ruby On Rails, Дэвид Хэйнемеер Ханссон, высказывается в том же духе: "This opens up a whole new world for things like advanced refactorings and, in general, provides an environment that's familiar to anyone coming from IDE-heavy environments like .NET or J2EE" ("Это открывает совершенно новый мир для таких вещей, как продвинутый рефакторинг, и, в целом, предоставляет среду [разработки], близкую для любого, кто придёт с отягощённых IDE средами, такими как .NET или J2EE").

Думаю, после таких рекомендаций авторитетнейших в мире Ruby людей мало у кого останется сомнение в том, что 3rd Rail - действительно хорошая среда разработки для Ruby (и в особенности для Ruby On Rails). А учитывая особенности этой технологии разработки web-приложений, можно сказать, что попробовать Ruby On Rails и 3rd Rail стоит каждому, кто разрабатывает web-приложения.

Вадим СТАНКЕВИЧ


1 Если перевести словосочетание Ruby On Rails с английского языка дословно, то получится "рубин на рельсах"

2 Некоторые интересные материалы по Ruby On Rails:

Версия для печатиВерсия для печати

Номер: 

39 за 2007 год

Рубрика: 

Software
Заметили ошибку? Выделите ее мышкой и нажмите Ctrl+Enter!
 

Комментарии

Страницы

Аватар пользователя Инкогнито
Интересует вопрос нагрузки на CPU при выполнении скриптов.

Если сравнивать PHP/MySQL, ASP.NET/SQL Server, Ruby/MySQL и cgi-bin - c binary/MySQL. То какой из скриптов будет использовать меньше ресурсов процессора? Какой самый "лёгкий" из них?

Аватар пользователя Инкогнито
binary/MySQL, ясен пень, если ровными руками написаны
Аватар пользователя Инкогнито
Это очень хорошо.

Скажите, почему так много фирм используют эти модные технологии вроде ASP.NET, Ruby и PHP? А о binary - ни слова... как будто бы этот метод уже исчез.

Почему мало говорят о серьёзной потере производительности при использовании Ruby/PHP?

Мне кажется, что намного выгоднее один раз написать хорошие скрипты на C и заказать 1-2 dedicated servers. А не арендовать по 5-10 серверов только из-за того что хочется писать на PHP или Ruby.

Аватар пользователя SF
На PHP, Ruby, ASP.NET писать быстрее, вот в чём вся причина.
Аватар пользователя Инкогнито
На самом ли деле быстрее? Или это просто так кажется, потому что модно? И ещё, быстрее для кого, для новоиспечённых программистов?

По-моему если использовать хорошие вспомогательные функции, грамотно спроектировать код, везде добавлять комментарии, и в случае если объем проекта окажется большой -- нарисовать вспомагательные диаграммы составных функций, то на C/С++ можно понимать и писать код намного быстрее. И разобраться в нем будет легче потом не только самому, но и человеку со стороны.

На C#/PHP/Ruby программистов приучают лениться. В результате код пишется вроде бы быстро, но потом могут всплыть проблемы плохого проектирования. Разобраться в коде будет сложно. Понадобится рефакторинг, в худшем случае - придется переписывать всё заново.

Аватар пользователя SF
>>На C#/PHP/Ruby программистов приучают лениться.

Так уже говорили, когда переходили с C на C++, а с него на Java, а с неё потом ещё на что-нибудь будут переходить.

Да, быстрее для новичков. Потому что им платить можно меньше, чем С++ программерам. Это расточительно для индустрии - писать на С++ cgi-приложения. Время сервера стоит дешевле, чем время разработчика.

Аватар пользователя Dolgov V.V.
ASP.NET при некотором приближении = binary, т.к. при первом обращении к странице движок компилируем код страницы в машинный код.
Аватар пользователя Инкогнито
>Время сервера стоит дешевле, чем время разработчика.

Наверное это самое лучшее объяснение.

Хотя для меня лично С и С++ являются самыми удобными языками. C PHP я хорошо знаком, на ASP.NET тоже пробовал писать. Если бы не проигрыш в серверной производительности, может и пошел бы следом за PHP/Java/Ruby community. Кроме этого, что касается Microsoft -- то после уничтожения Visual Basic Classic, прощанием с СOM/COM+ и заменой на .NET, после слабого развития MFC и одновременно с выходом сырых версий .NET Framework'a, после выхода Vista без обратной совместимости, на которой половина старых программ не идёт, у меня неожиданно возникло сильное желание вернуться к стандартам десятилетней давности и строго их придерживаться. Очень жалею, что догадался до этого слишком поздно. Но лучше поздно чем никогда.

Недавно нашел такую штуку под названием CPP Server Pages

http://www.micronovae.com/CSP.html

Но как потом выяснилось она работает только под WINDOWS. А хотелось бы под Linux или FreeBSD.

Как они пишут на сайте - если сравнивать ASP с С++ , то при выполнении бинарных приложений С++ наблюдается прирост производительности в 80 - 250 раз.

То есть как я понимаю, достаточно арендовать всего 1 сервер вместо несколько десятков с ASP.NET.

Мне скоро надо будет создать большой динамический веб сайт с минимальной нагрузкой на процессор. Поэтому сейчас анализирую как применить C или C++ под Unix-совместимые ОС для правильной разработки серверного ПО, не очень понятно вообще с чего начать. Хотя бы с какого сайта/книги?

Аватар пользователя Инкогнито
Кое что нашёл.

Проблемы c++/cgi это:

- memory leaks (правильно кто-то писал выше, все нужно делать ровными руками и тестировать)

- переполнение буфера (а это могут использовать хакеры, здесь надо думать)

- для каждого HTTP-запроса создается НОВЫЙ процесс, каждый раз файл грузится заново (!), никуда не годится, поэтому оказывается в далеком 1995 году был разработан FastCGI, который решает эту проблему.

Если кому-то интересна эта тема, то есть интересная статья по поводу сравнения технологий: Java servlets, Java server pages, CGI/C++ и FastCGI/C++.

http://www.cse.iitb.ac.in/~varsha/allpapers/mypapers/web_comparison_journal.pdf

Лучший выбор в плане performance и CPU utilization это FastCGI/C++

Аватар пользователя flower
Забыли упомянуть про Perl, который работает быстрее, чем PHP (а тем более, чем Ruby), и может работать в связке с FastCGI.

Это C-подобный язык, ориентированный в том числе и на CGI. Скоро выходит Perl 6.0 , который по функциональности и удобству программирования лучше, чем Perl 5. А учитывая кроссплатформенность Perl'а, это даёт ему много очков в сравненни с ASP.

Страницы