Цей контент є частиною серії: Перетинаючи кордони
Слідкуйте за виходом нових статей цієї серії.
Окозамилювання і скептицизм
Дебати про Rails в Java-співтоваристві йдуть інтенсивно, і поки немає ознак їх загасання. Прихильники Rails хваляться неймовірною продуктивністю, за деякими твердженнями, 10 до 1 у порівнянні з Java-розробкою. Як у будь-якого Java-розробника, вашої природною реакцією буде недовіру до будь-яких запевненням про страшну продуктивності, оскільки ви це чули і раніше і були розчаровані. Адвокати Java наполягають на тому, що Ruby on Rails є іграшкою, що не масштабується, виробляє поганий код і не працює за межами простих додатків. Але оскільки вихваляння Rails тривають (часто, з надійних джерел), можливий більш розсудливий підхід до розуміння того, що Rails робить добре, і привнесення цих ідей назад в платформу Java. У даній статті я розгляну основні функціональні можливості (приховану родзинку), які становлять сутність високої продуктивності Rails.
Про цю серії статей
У даній серії статей представлені концепції та технології програмування, які радикально відрізняються від Java-розробки, але безпосередньо підходять для неї. У деяких випадках вам необхідно інтегрувати технологію, щоб скористатися її перевагами. В інших випадках ви можете застосувати концепції безпосередньо. Конкретне інструментальний засіб саме по собі не так важливо, як ідея про те, що інші мови і системи можуть вплинути на розробників, інтегровані системи і навіть на фундаментальні підходи в Java-співтоваристві.
Філософія Rails
- Плавне інтеграція. Rails блискуче використовує найкращі властивості мови програмування Ruby. Він розширює Ruby таким чином, що іноді важко сказати, де закінчується Ruby і починається Rails. Також помітна відмінна інтеграція Active Record (механізм персистенції Rails) і середовища Модель-Представлення-Контролер (model-view-controller - MVC). Наприклад, ви можете написати три рядки коду, створити таблицю і потім відразу ж згенерувати призначений для користувача інтерфейс для цієї моделі.
- Угода по конфігурації. Для збереження бездоганної гнучкості Java-системи підтримують тривимірні, всеосяжні конфігураційні файли. Rails відмовляється від цієї стратегії. Він допускає звичайну структуру каталогів проекту і прості, звичайні угоди по найменуванню для методів, класів, таблиць і стовпців, багато в чому маючи на увазі звичайну конфігурацію в Java-додатках. В результаті Rails-додатки потребують тільки в частині конфігураційного коду, використовуваного в Java, часто зменшуючи його обсяг в 10 і більше разів.
- Низька повторюваність. Не повторювати (Do not Repeat Yourself, або DRY) - ось традиційне гасло в Rails-співтоваристві. Розробники середовища Rails прагнуть абстрагувати повторювані завдання методами, часто виглядають як розширення мови Ruby. Як ви бачили в третій статті даної серії, стратегія метапрограмування в Rails ускладнює роботу кожного рядка коду.
- Негайна зворотна реакція. При роботі в Rails велика частина того, що ви робите, може викликати негайну зворотну реакцію. Ви пишете рядок коду і зберігати, а ваше зміна стає активним при завантаженні наступної Web-сторінки. Міграції можуть стати видимими негайно після оновлення вашої бази даних.
практичний фундамент
Мотиви, що лежать в основі Ruby on Rails, суворо засновані на практичному досвіді. Середа Rails виросла з практичного використання в розробці популярного додатка з управління проектами Basecamp (див. Розділ "Ресурси").
Концентрація на області застосування
Аргумент проти висловлювань про жахливу продуктивності зазвичай грунтується на наступному: якби у мене був хороший молоток, я навряд чи б знайшов інший молоток, який мав би продуктивність в два рази вище; давайте залишимо розмови про підвищення продуктивності в 5-10 разів, оскільки молотки удосконалюються більше тисячі років. Але люди, які порівнюють Ruby on Rails з різними інтегрованими середовищами Java загального призначення, не погодяться з цим. Ви можете підвищити продуктивність рішення деяких проблем в 10 разів, радикально змінюючи природу інструментального кошти. Професіонали зараз використовують пневматичні молотки, які забивають дюжину цвяхів, в той час як звичайний молоток забиває тільки один. Подібно пневматичної молотка, Rails є спеціалізованим інструментом. Це середовище, написана з точним прицілом на одну область застосування: нові Web-додатки, що використовують бази даних.
Я б висловив здогад, що приблизно половина створюваних в даний час Web-додатків використовує бази даних. Тобто, безумовно, Rails - це спеціалізований продукт, але його спеціалізація велика і важлива. Спеціалізація в цій області дає Rails величезні переваги, що пояснюють великий ефект, який він може забезпечити. Концентруючись на проектах в своїй області, Rails-розробники можуть використовувати короткі прийоми, які не можуть забезпечити інші інтегровані системи. Така спеціалізація часто жертвує гнучкістю заради простоти.
Нові функції, які залежать бази даних, пропонують обгортковий (wrapping) підхід замість підходу з відображенням. Як ви бачили в першій статті даної серії, програми Rails припускають наявність угод в моделі даних. Rails-додатків потрібен фрагмент коду моделі, використовуваної в Java-додатках. Якщо ви створюєте вашу схему спеціально для Rails-додатків, така філософія працює добре. Якщо ви хочете пристосувати існуючу схему в Rails, все стає не так гладко.
Web-додатки допускають схожий набір оптимізацій. Знаючи, що додаток засноване на Web-технологіях, ви знаєте загальну структуру програми та головні компоненти, які йому, ймовірно, знадобляться. Наступні функції вдосконалені в Rails, оскільки Rails спеціалізується на Web-додатках:
- Model-view-controller. MVC-середовище Rails, звана Action Pack, налаштована на Web-доступ і реалізує широко відому стратегію, яка називається Model 2 (див. Розділ "Ресурси"). Rails-версія має оптимізовану інтеграцію між контролером і поданням, яка мінімізує конфігурацію і автоматично робить доступним для подання змінні екземпляра контролера.
- Структура каталогів проекту. Всі Rails-додатки мають одну і ту ж структуру проекту, з каталогами для управління кодом програми, конфігурацією бази даних, загальнодоступними статичними файлами і сценаріями для управління Web-серверами і функціональним Web-тестуванням.
- Архітектура. Середа Rails спрощує архітектуру, забезпечуючи готові сценарії, які генерують компоненти програми, які дотримуються загальних архітектурних рішень, таких як сторінкове і пофрагментное кешування, дворівневий дизайн; середовище для тестування, розробки і виробництва.
- Інструментарій. Rails-інструментарій спеціалізований для Web. Системи підтримки ведення журналів, роботи з контрольними точками, профайлера і тестування пристосовані для Web-додатків і дозволені для дворівневої роботи.
Але пневматичні молотки ніколи не замінять звичайний молоток, тому ми вчинили б нерозумно, чекаючи повної заміни. Молоток завжди зможе зробити речі, які пневматичний молоток зробити не в змозі. Rails ніколи не буде інструментом корпоративної інтеграції, об'єктно-реляційного відображення або універсальних Web-служб. Найкраще, що ви можете очікувати від Rails - це те, що він є спеціалізованим інструментом, який відмінно працює в своїй ніші.
досвід розробника
Заглибившись в деталі Rails, ви починаєте розуміти, наскільки радикально іншим може бути досвід Rails-розробника. Швидкий цикл зворотної реакції, інтерактивні консолі на кожному кроці, угоди по конфігурації - все це удосконалює досвід розробника в напрямках, часто недоступних в Java-системах.
Цикл зворотної реакції
Ви можете припустити, що швидкий цикл зворотної реакції, що допомагає при розробці, буде шкідливий для готових додатків. Зрештою, часті перезавантаження класів, які дозволяють швидкий цикл зворотної реакції, повинні сповільнити готове додаток до неприйнятного рівня. Але Rails вирішує цю проблему, надаючи вам різні середовища для розгортання та розробки. Середовище розробки виконує часту перезавантаження класів на шкоду продуктивності додатка, а робоче середовище зменшує перезавантаження до необхідного мінімуму, забезпечуючи швидку роботу кінцевого користувача на шкоду швидкого циклу зворотної реакції для розробника.
інтерактивність
Інтерактивність Ruby теж вносить свій внесок в Rails. Ви, можливо, вважаєте, що налагодження Rails-додатки без повноцінної IDE-середовища є скрутною. Це не так. Rails надає дві функції, що спрощують налагодження. Одна з них - програма роботи з контрольними точками. яка дозволяє вам додавати ключове слово breakpoint в ваш вихідний код.
Якщо ви працюєте в UNIX® або Mac OS X, просто запустіть ваш сервер в окремому процесі.
Введіть або скопіюйте наступний код в файл app / controllers / samples_controller.rb:
Протестуйте код, завантаживши сторінки localhost: 3000 / samples і localhost: 3000 / samples / show.
Коли Rails дійде до контрольної точки, додаток зупиниться. Вікно програми роботи з контрольними точками відкриє інтерпретатор Ruby із середовищем, стан якої відповідає поточному стану контролера. Ви можете потім виконувати команди Ruby для запиту інформації про стан вашої сесії, для виконання методів і запиту значень змінних:
Ця невелика програма не надає вам повноцінний відладчик, але у вас є деякі можливості, відсутні в Java-відладчика, в тому числі, доступ до повноцінного інтерпретатора і здатність виконувати методи вашої програми.
Угода по конфігурації
Угода по конфігурації теж призводить до деяких несподіваних моментів для нових Rails-розробників, оскільки контролер і код моделі досить лаконічні. Ви бачили в першій статті. що, покладаючись на середу Rails, ви можете отримати деяке розширене поведінку для дуже простих класів, налаштовуючи Rails-угоди по найменуванню і дозволяючи Rails здогадуватися про точки з'єднання вашого застосування замість прямого їх конфігурації. Наприклад, об'єкт Person з багатьма атрибутами і ставленням один-ко-многим з department може виглядати наступним чином:
Ніякої конфігурації не потрібно, оскільки Rails зробить припущення про назву таблиць (people), назві ідентифікатора об'єкта і первинного ключа (id), назві пов'язаної таблиці (departments), назві зовнішнього ключа (department_id) і назві зовнішнього класу (department.rb), засноване на угодах по найменуванню. Код залишається легким, виразним і дуже простим за зовнішнім виглядом, незалежно від того, що ви з ним робите, - пишете, читаєте або обслуговуєте. Задуми відразу ж зрозумілі.
Чого можуть навчитися Java-розробники?
Я не пропоную створити кращий Rails на мові Java. Замість цього Java-розробники повинні засвоїти деякі уроки середовища Rails і прагнути створити або покращити Java-середовища для виконання наступних завдань:
- Дозволити гаряче розгортання, при якому скорочується цикл зворотної реакції, або підтримку середовищ, які допускають гаряче розгортання. Цей пріоритет повинен бути набагато вище на стороні Java, ніж він є зараз.
- Використовувати менше XML і більше угод. Угоди не виключають конфігурації, оскільки ви можете використовувати угоди для вказівки значень за замовчуванням та конфігурації для перевизначення угоди. Використовуючи такий підхід, як це робить Rails, ви отримуєте найкраще: лаконічний код з меншою повторюваністю без втрати гнучкості.
- Працювати по включенню більшої кількості мов сценаріїв, в тому числі BeanShell (див. Розділ "Ресурси"), для дослідження Java-класів під час процесу налагодження.
- Використовувати правильні інструменти для виконання роботи. Не обов'язково звертатися до Hibernate тільки для персистенції, або до Struts тільки тому, що вам потрібно Web-додаток.
Включаючи кращі можливості інших мов програмування, ви, можливо, не відтворите Rails, але безумовно поліпшите Java-кваліфікацію.