Содержание

13 фактов о Ruby on Rails – Что вам нужно знать?

Многие мои друзья-разработчики лестно отзываются о Rails, но я не мог понять почему. Что такое Rails, и чем он отличается, собственно, от Ruby on Rails? Насколько он сложный в изучении? Это вообще язык программирования? Что мне нужно знать, перед тем как учить Ruby on Rails?

Эти и многие другие вопросы постоянно крутились в моей голове, но, как оказалось, я не один такой. Наши читатели тоже интересовалось этим вопросом, поэтому, чтобы узнать об этом больше, я решил задать одному из своих коллег несколько базовых вопросов o Ruby. Так и родилась эта статья.

Вы готовы? Поехали!

13 фактов о Ruby on Rails – Что вам нужно знать?

1. Что такое Rails?

Rails это фреймворк (каркас) веб-приложений, который создан для написания кода на языке Ruby. Звучит запутанно, правда?

Давайте попробуем еще раз. Существует язык программирования Ruby. Писать на нем одно удовольствие. Кстати, человек, который создал его, говорил, что его главной целью было создание языка, который бы делал жизнь программистов лучше. Разве это не прекрасно?

Позвольте привести пример.

Если я захочу вывести текст на экран на PHP, мне нужно написать

echo “Привет Мир”;

Видите точку с запятой? А этот «echo» – что он вообще значит?

С другой стороны, если мне нужно проделать то же самое на Ruby, мне нужно будет написать следующее:

puts “Hello World”

Никакой точки с запятой, и хотя «puts» может выглядеть немного «по-подростковому», мне эта команда кажется более логичной, чем «echo». Когда вы часами пишете код, такие мелкие детали играют БОЛЬШУЮ роль.

Единственной проблемой Ruby было то, что он не предназначен для создания веб-приложений. То есть, на нем у вас не получится, к примеру, создать сайт. Так было до появления Rails. Я не уверен, был ли Rails первым веб-фреймворком для Ruby, но он ОПРЕДЕЛЕННО стал самым популярным.

Задача Rails заключается в предоставлении платформы и возможностей, которые бы позволили создавать на Ruby приложения, в частности сайт. Пока что это звучит довольно размыто, поэтому попробую объяснить вот так. Если бы я написал

puts “Hello World”

то в HTML-документе, вы бы увидели весь текст целиком. Но я же хочу, чтобы вы видели ТОЛЬКО вот это:

Hello World

Проще говоря, Rails позволяет это сделать. Но это далеко не все.

2. Что такое Ruby on Rails?

Ruby on Rails – это ПОЛНОЕ официальное название фреймворка Rails. Но в разговоре разработчики обычно не говорят первую часть, и просто называют его Rails. Поэтому, если вы хотите быть «в теме» и казаться технически подкованным, вы определенно должны называть его Rails, но при этом ПОМНИТЬ о том, что означает эта первая часть – «Ruby on».

3. Я слышал, что Rails отлично подходит новичкам. Почему?

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

Почему Rails настолько приятен в работе для новичков? Просто он очень стабильный и делает за вас ОГРОМНЫЙ пласт работы.

Для меня работать на Rails сродни вождению на грузовой фуре. Он невероятно мощный, вы только поглядите – вы ведете грузовик!!! Однако, хорошо ли вы знаете, как работает автомобиль, который вы ведете?

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

По этой причине очень важно изучать Ruby on Rails с нуля. И самое главное – вы должны убедиться в том, что вам действительно удобно работать с Ruby. Иначе вы просто на полпути выйдете из этой фуры и скажете себе: «Погодите, неужели я ехал на этой штуковине?».

4. Чем отличается Rails- от Ruby-разработчика?

Формально отличие заключается в том, что чисто «Ruby-разработчик» будет создавать приложения на Ruby, но не на Rails. Хотя такого, как правило, не бывает. Создавать веб-приложения на Ruby, используя другие фреймворки типа Sinatra, конечно, возможно, но я готов поспорить, что в 99% случаев вас вряд ли будут нанимать как программиста, знающего только Ruby. Поэтому нужно в любом случае изучать и Rails.

5. Насколько хорошо я должен знать Ruby? Что мне следует выучить, перед тем как начать обучение?

На этот счет существуют различные мнения, но, придерживаясь примера с большим грузовиком, я считаю, что вы должны чувствовать себя уверенно при работе с Ruby, чтобы углубиться в изучение Rails. Так же как, скажем, лучше сначала научиться ездить на велосипеде, перед тем как пересесть на легковой автомобиль, а потом уже думать о том, чтобы ездить на грузовике.

И вот еще что. Много времени при работе на Rails будет уходить на написание кода на Ruby. По этой причине нужно очень хорошо знать этот язык, особенно его основы: типы данных, методы, объектную ориентацию, отладку и многое другое. И необязательно быть при этом сверхопытным Ruby-программистом – просто вы должны чувствовать себя при работе с ним уверенно, как рыба в воде.

6. Зачем мне изучать Rails? Что делает его особенным?

Он изысканный и просто потрясающий. Что еще вам нужно знать? Когда Rails только появился, он стал реальным открытием и достижением дизайнерского искусства. С наилучшим практиками, которые были учтены при его создании, Rails практически направляет вас на путь к написанию превосходного кода, даже если вы этого не хотите (или не знаете, как это сделать).

Если вы хотите создавать надежные веб-приложения, которые будут расти по мере необходимости, и при этом их будет легко поддерживать в будущем, Rails это отличный вариант. К тому же, он пользуется популярностью среди многих крутых компаний. Последней важной причиной такой высокой популярности Rails среди стартапов является то, что он прекрасно подходит для быстрого макетирования. Всего за несколько часов вы сможете придумать, создать и запустить нужное вам приложение на Rails. Других фреймворков, которые могли бы с этим справиться, на самом деле очень мало.

7. Что можно создавать с помощью Rails?

А что вы хотите создать? Rails подходит для любых веб-приложений. Для наглядности ознакомьтесь с вот этими отличными примерами сайтов, созданных на Rails: Hulu, Airbnb и Basecamp.

8. Могу ли я создавать мобильные приложения на Rails?

И да, и нет. На Rails не получится создавать мобильные приложения, но на Rails вы определенно сможете создать веб-приложение и использовать его в качестве back-end для мобильного приложения.

Также есть инструмент RubyMotion, который позволяет очень просто создавать нативные приложения для iOS и Android на Ruby (но не Rails). То есть, вы не будете КОНКРЕТНО использовать Rails для создания мобильного приложения для App Store, но Rails определенно может стать важной составляющей вашего мобильного проекта. Надеюсь, теперь картина стала более понятной.

9. Ruby on Rails – Какого рода работу я могу получить?

Rails – это один из самых востребованных навыков в настоящее время, поэтому выбор компаний, с которыми можно работать, довольно большой. Особенно Rails любят стартапы, например, такие как Zearn. Это начинающая неприбыльная образовательная ИТ-компания. Также можно выбрать более крупную компанию вроде Bloomberg и принимать участие в разработке сайтов и приложений, которыми пользуются миллионы пользователей. Фриланс тоже неплохой вариант для Rails-разработчиков. Будучи независимым, вы сможете сами выбирать, в каких проектах вы хотите поучаствовать: в небольших и короткосрочных или серьезных и долгосрочных.

10. Я попробовал другой язык программирования, но мне он не понравился. Стоит ли мне пробовать Rails?

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

11. Может мне вместе Rails выучить JavaScript?

Вместо – нет. Дополнительно – НЕСОМНЕННО.

Rails-разработчику придется изучать JavaScript (Тут один из самых лучших курсов по JavaScript). Это не требование для изучения Rails, но это тот навык, который вам будет необходим по мере обучения.

Скажу честно, постепенно погружаясь в сферу технологий, вы начнете понимать, что вам придется обладать достаточно большим количеством навыков (по сути, это значит, что всем нужно стремиться к тому, чтобы быть Full-Stack-разработчиком). К счастью, по мере приобретения опыта вам будет проще изучать как новые языки, так и новые фреймворки.

Что касается того, что выбрать –  JavaScript или Rails, – прямо скажу, что вы в любом случае не ошибетесь. Мне кажется, что Ruby гораздо проще учить, чем JavaScript. К тому же я знаю многих, кому JavaScript давался проще, после того как они сначала изучили Ruby. Но, как я уже сказал выше, вы точно не прогадаете, если изучите и то, и другое.

12. Сколько времени займет обучение?

Сколько времени в день вам придется потратить на обучение? Мне кажется, для хорошего понимания Rails нужно несколько месяцев специального обучения. Но, как и с любым другим навыком, чтобы стать профи в Rails, вам понадобятся десятки тысяч часов, поэтому лучше всего не терять времени и начать прямо сейчас.

На скорость обучения большое влияние будет оказывать ваш уровень знаний в области программирования в целом. Но если вы полный новичок, стоит попробовать начать с Ruby и Rails.

13. Ruby on Rails – С чего начать?

Рекомендую начать с самого лучшего курса по Ruby on Rails на сeгодняший день. Если вы не писали ни строчки кода в своей жизни, первым делом вам стоит пройти курс 

inbenefit.com

Ruby on Rails шаг за шагом. #1 Теория / Habr

Ненадолго отставив серию статей о ЯП Ruby в сторону (1, 2, 3, 4, 5, 6, 7, 8, 9, 10), решил презентовать вам новый цикл о фрэймворке Rails. Набравшись некоторого опыта в «обучении» попробую вывести эту серию на уровень качества и продуманности несколько выше, чем прежде.

Целью первой части уроков по Ruby on Rails будет создание некоторого многопользовательского блога (аля Хабр). Также хочется отметить, что для этой первой части желательно иметь познание о Руби хотя бы на уровне трех-четырех капель. Хочется поскорей приступить к кодингу, но начинать все равно придется с теории.

Что такое Ruby on Rails (далее RoR)? Самый распространненый ответ – это базирующийся на ЯП Ruby (далее Руби) фрэймворк, который реализует шаблон (далее паттерн) MVC. Выделим два главных пункта из ответа:

  • Это фрэймворк на базе Ruby
  • Он реализует паттерн MVC
Разберем каждый отдельно.

RoR – базирующийся на Руби фрэймворк

ЯП Руби – простой и мощный, возможность мета-программинга, блоков, итераторов, а также обработки исключений делает язык замечательной основой для фрэймворка. Собственно так и посчитал Дэвид Хэйнемеер Ханссон, создатель RoR, и в июле 2004 года фрэймворк вышел на свет.
Увидеть, как помогает мета-программирование Руби, можно увидеть в ORM компоненте RoR Active Record. Основываясь на имени класса, RoR считывает схему (schema) и налету создает объекты класса на базе таблицы БД. Можно перейти к следующему аспекту.
RoR реализует MVC

Возожно, вы уже слышали о MVC в отношении других фрэймворков, однако что представляет собой MVC в RoR? MVC – это паттерн архитектуры приложения, четко разделяющий три его компонента:
  • Model (далее
    Модель    ) является «сутью» приложения и отвечает за непосредственные алгоритмы, расчёты и тому подобное внутреннее устройство приложения. Также предоставляет линк к хранилищу данных.
  • View (Представление, дальше Вид) предназначен для вывода данных, предоставленных Моделью. Это единственная часть MVC, которая непосредственно контактирует с пользователем.
  • Controller (Поведение, далее Контроллер) получает данные от пользователя и передаёт их в Модель. Кроме того, он получает сообщения от Модели и передаёт их в Вид.

Вот схема MVC:

Исходя из этого RoR использует три компонента:

  • Active Record
  • Action View
  • Action Controller

Сочетание последних двух известно как Action Pack. Рассмотрим каждый компонент поближе, и узнаем, почему Руби так подходит для реализации фрэймворка.
Active Record

Active Record – это Модель в RoR. Модель хранит данные и предоставляет базу для работы с данными. Кроме этого Active Record также является ORM фрэймворком. ORM значит Object-relational mapping (Объектно-реляционная проекция). Собственно Active Record делает следующие вещи:
  • Проекция таблицы на класс. Каждая таблица проецируется на один или несколько классов по принципу
    convention over configuration     (соглашение выше конфигурации). Одно из таких соглашений – имя таблицы должно быть во множественном числе, а название класса – в единственном. Атрибуты таблицы налету проецируются в атрибуты экземпляра Руби. После того, как все проекции сделаны, каждый объект ORM класса представляет определенную строку таблицы, с которой класс был спроецирован.
  • Соединение с БД. Вы можете подключиться к базе данных, используя API, предоставляемый Active Record, который создает необходимый вам запрос непосредственно в движок БД при помощи адаптеров. У Active Record есть адаптеры для MySQL, Postgres, MS SQLServer, DB2, и SQLite. Необходимо лишь записать параметры доступа к БД в файле database.yml.
  • Операции CRUD. Это операции create (создание), retrieve (получение), update (обновление) и delete (удаление) над таблицей. Так как Active Record – это ORM фрэймворк, вы всегда работаете с объектами. Чтобы создать новую строку таблицы, вы создаете новый объект класса и заполняете его переменные экземпляра значениями. Стоит заметить, что все это Active Record делает за вас.
  • Проверка данных. Проверка данных перед помещением их в таблицу – это первый шаг в безопасности вашего проекта. Active Record предоставляет проверку
    Модели    . Данные могут быть проверены автоматически с помощью множества готовых методов, которые, в случае необходимости, можно переписать под собственные нужды.
Action View

Вид включает в себя логику, необходимую для вывода данных Модели. Роль Вида в RoR играет Action View. Наилее часто используемые функции Action View:
  • Шаблоны (Templates). Шаблоны – это файлы, содержащие заполнители (placeholders), которые буду заменены на контент. Шаблоны могут содержать HTML-код и код Ruby, встраиваемый в HTML с использованием синтакса встроенного (embedded) Ruby (ERb).
  • Помощники (helper, далее хелпер) форм и форматирования. Хелперы форм позволяют создавать такие элементы страниц, как чекбоксы, списки, используя готовые методы. В свою очередь хелперы форматирования позволяют форматировать данные необходимым нам способом, методы существуют для дат, валют и строк.
  • Макет. Макеты (layouts) определяют, как контент будет расположен на странице. Динамически создаваемая страница может содержать вложение из нескольких страниц, даже без использования таблиц и фрэймов, используя API Макета.

Action Controller

В веб-приложении Контроллер регулирует поток логики приложения. Он находится на границе программы, перехватывая все запросы, на основе которых он изменяет какой-то объект Модели и вызывает Вид, чтобы отобразить обновленные данные. В RoR Action Controller является Контроллером, вот его основные функции:
  • Поддержка сессий. Сессия – это период времени, проведенный пользователем на сайте. Его можно отследить с помощью cookie или объекта сессии. Cookie – небольшой файл, он не может содержать объекты, в отличие от объекта сессии.
  • Фильтрация. Бывают ситуации, когда необходимо вызвать определенный код, перед тем как исполнять логику Контроллера или после него, например, аутентификация пользователей, логирование событий, предоставление персонального ответа. Помогают в таких случаях фильтры, предоставляемые Action Controller. Существуют три основных фильтра: before, after и around. О них – позже.
  • Кэширование. Кэширование – это процесс, при котором наиболее запрашиваемый контент сохраняется в кэше, чтобы не было необходимости запрашивать его вновь и вновь.
Три среды

RoR поощряет использование отдельных сред для каждого из этапов цикла жизни приложения: разработка (development), тестирование (testing) и эксплуатация (production), для каждого из которых создается отдельная БД. Рассмотрим каждую среду.
  • development. В среде разработки ставка делается на немедленное отображение нового варианта при изменении кода – достаточно обновить страницу в браузере. Скорость в этой среде не важна. Когда случается ошибка, она выводится на экран.
  • test. При тестировании мы обычно каждый раз наполняем БД каким-нибудь глупым текстом, чтобы убедиться, что нормальное поведение не зависит от содержания БД. Процедуры юнит-тестинга и теста функциональности в RoR автоматизированы и производятся через консоль. Тестовая среда предоставляет отдельное пространство, в которых оперируют эти процедуры.
  • production. В конце концов ваше приложение выходит к финальной черте, пройдя тесты и избавившись от багов. Теперь обновления кода будут происходить редко и можно сконцентрироваться на производительности, включить кэширование. Нет необходимости писать огромные логи ошибок и пугать пользователей сообщениями об этих ошибках в браузере. Для вас – среда production.
Эпилог

Да, да, и тут эпилог — без него никуда 😉 Сегодня мы с вами узнали о том, что такое MVC, как его реализуют Rails, узнали роль компонентов фрэймворка, узнали, как они сообщаются между собой. Взглянули даже на разные среды, которые предоставляют нам Rails. Если все понятненько, то можно начинать обустраивать рабочее место! Комментарии страстно желаемы 😉

PS: Этот номер написан по мотивам книги

Building Dynamic Web 2.0 Websites with Ruby on Rails. Однако с литературой по Rails стоит быть максимально осторожным, поскольку фрэймворк развивается неуловимыми темпами, и почти все книги (даже 2008 г. выпуска, в том числе и эта) основана на старых версиях Rails (1.2.x)

habr.com

Пришло время попрощаться с Rails / Habr

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

Так как я вовлечён во множество Ruby-проектов, люди часто спрашивают меня, почему я не люблю Rails, какие проблемы у меня есть с ним и так далее. Поэтому я решил написать этот длинный пост, чтобы подвести итоги и все объяснить.

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

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


Хорошая часть

Я не буду делать вид, что все в Rails плохо, неправильно, и фреймворк является воплощением зла. Это было бы не справедливо, да и просто глупо. О Rails можно сказать очень много хорошего. И я упомяну пару (очевидных?) вещей для поддержания баланса.

Итак, Rails сделал Ruby популярным. Это факт. Я стал Ruby-разработчиком, что в свою очередь изменило мою карьеру и дало мне много удивительных возможностей, именно благодаря Rails. Многие рубисты тех дней прошли по тому же пути. Мы все здесь благодаря Rails. Во многих случаях, Rails на самом деле оказал огромное влияние на людей, и буквально улучшил им жизнь. Люди получили лучшие рабочие места, лучшие возможности и хорошие деньги. Это было радикальной сменой условий «игры» для многих из нас.

На протяжении многих лет Rails & DHH вдохновили многих людей, в том числе людей из других сообществ, на переосмысление того, что они делают. Например, я уверен, что Rails способствовало улучшению PHP сообщества (вы можете попытаться доказать, что я ошибаюсь, но у меня есть довольно яркие воспоминания как Symfony подчерпнул кучу вдохновения от Rails). То же самое произошло в Java, фреймворк Play является примером.

Есть и другие фантастические аспекты. Rails был всегда нацелен на простоту использования и возможность быстро создавать веб-приложения, что позволило преуспеть таким инициативам, как Rails Girls. Rails доказал людям, что они способны создать что-то самостоятельно, без какого-либо опыта программирования, в относительно короткий промежуток времени. Это удивительно, так как это легко может стать воротами в мир программирования для людей, которые в противном случае даже не рассматривали возможность стать программистом.


Мое путешествие

Позвольте мне рассказать вам немного о моем бэкграунде и как я пришёл к Rails.

Я начал работать с Ruby в конце 2006 года, поскольку моя дипломная работа была о Rails. Я изучал язык в то время, как писал свой диплом. Это было весело, это было интересно, это было что-то новое для меня. Тогда я еще работал в качестве PHP-разработчика. И как типичный PHP-программист в ~2005-6, я делал все эти типичные вещи: писал SQL-запросы в шаблонах представлений, писал в процедурном стиле, а затем разрабатывал свой собственный фреймворк и свой собственный ORM, разочаровывался и выгорал. Несмотря на некоторые знания C, C++, Java и Python, я решил перейти на Ruby, из-за Rails. Я выбрал их для своего диплома и совершенно случайно наткнулся на предложение о работе от местного магазина на Rails. Я ответил и они наняли меня. Это было в марте 2007 года.

Итак, с марта 2007 года я начал работать с Ruby профессионально, и где-то с 2009-го я начал вносить вклад в OpenSource проекты на Ruby. С тех пор я работал в консалтинговой компании в течение 3.5 лет, в основном c большими и сложными проектами. Потом работал фрилансером в течение нескольких лет, работал с кучей клиентов, открыл свою собственную компанию, а затем вернулся на полный рабочий день, а затем снова на фриланс, и теперь я вновь штатный сотрудник. Я создавал Rails-приложения с нуля, и участвовал в разработке относительно больших Rails-приложений.

Позвольте мне рассказать вам одну историю. Однажды я присоединился к существующему проекту. Это было огрооомное приложение, которое управляло веб-сайтом торгового он-лайн сообщества. Сложные модели продаж, сложные промо-акции, затейливые конфигурации товаров, купоны, группы пользователей, сообщения — в нём было всё это. Я присоединился к ним, чтобы помочь добавить несколько новых фич. Одной из моих первых задач было… добавить ссылку на что-то на какой-то странице. Мне потребовалось несколько дней, чтобы добавить эту глупую ссылку. Почему? Приложение было большим шаром сложной логики предметной области, раскатанным по нескольким слоям и с настолько сложными вьюхами, что было не просто даже найти нужный шаблон, в котором добавить ссылку. Так как мне нужны были некоторые данные из заказа для того, чтобы создать эту ссылку, не было очевидно, как я должен получить их. Недостаток внутренних API приложения и опора исключительно на ActiveRecord сделали эту задачу чрезвычайно трудной. Я не шучу.

Мои первые фрустрации с Rails начались довольно рано. Я испытал недовольство от ActiveRecord примерно после 6 месяцев его использования. Также мне никогда не нравилось, как Rails подошел к работе с JavaScript и AJAX. В случае, если вы не помните, или не застали версии до того, как Rails принял UJS подход (который был хитом обсуждений в 2007-2008 годах), Rails использовал inline JavaScript в шаблонах, порожденный связкой противных хелперов. Как и всё с Rails, это было «легко и приятно в начале», а затем превращалось в неподдерживаемое дерьмо. В конце концов, Rails принял UJS в версии 3.0 и, кажется, сообщество согласилось, что это лучший подход. Это было, когда Merb был убит влит в Rails. О, вы не знаете, что такое Merb? Хорошо, давайте поговорим об этом.


Почему я был восхищён Merb & DataMapper

Merb — проект, созданный Ezra Zygmuntowicz. Он начался как хак, чтобы сделать загрузку файлов быстрее и потокобезопасной. И он прошёл интересный путь от этого хака до модульного, потокобезопасного, быстрого full-stack фреймворка для разработки веб-приложений. Я помню, как люди начали говорить о Merb в 2008-м и это было удивительное чувство, что происходит что-то новое, и это будет здорово!

Вы возможно обрадовались, когда в Rails появился режим API, не так ли? Хм, а Merb имел 3 режима: режим полного стека, режим API и микро-режим, в котором он был урезан до минимума, и я до сих пор помню, что это было самой быстрой вещью когда-либо существовавшей в Ruby мире. Это было более 7 лет назад. Вдумайтесь в это.

В то же время еще один проект привлёк внимание сообщества — DataMapper. Он стал частью Merb стека, являясь его выбором для ORM. Я был очень возбуждён тем, как он решал многие проблемы, которые были в ActiveRecord. DataMapper уже в ~2008-9 имел определения атрибутов в моделях, пользовательские типы, ленивые запросы, более мощный DSL запросов и так далее. В 2008 году Yehuda Katz был одним из Core-разработчиков проекта, он активно продвигал его и был большой ажиотаж по этому поводу. DataMapper в конечном счете был лучшим ORM, чем ActiveRecord в 2008-9. Было бы несправедливо не упомянуть о том, что Sequel появился примерно в то же время и до сих пор он используется гораздо меньше, чем ActiveRecord, несмотря на то, что является более хорошим решением.

Я был восхищён Merb и DataMapper так, как они принесли надежду, что мы можем сделать что-то лучше и создать здоровую конкуренцию для Rails. Я был взволнован, потому что оба проекта поощряли модульный подход и потокобезопасность, не говоря уже о таких вещах, как просто более хорошие стандарты написания кода.

Оба проекта были в конечном счете убиты Rails, так как Merb был «влит» в Rails, что вылилось в огромный рефакторинг Rails для версии 3.0. DataMapper потерял внимание сообщества и без особой поддержки проект не смог развиваться, как это могло бы быть, если Merb не был бы «влит» в Rails.

С этим решением экосистема Ruby потеряла кучу важных проектов и только Rails выиграли от этого. Является ли решение убить Merb хорошим или нет, это вопрос личного мнения, мы можем только предполагать, что могло бы произойти, если бы решение не было принято. Тем не менее, есть простая истина о конкуренции — это здорово. Отсутствие конкуренции означает монополию, и есть простая истина о монополии — это не здорово. Конкуренция способствует прогрессу и инновациям, конкуренция создает здоровую экосистему, она позволяет людям сотрудничать больше, чтобы поделиться тем, что распространено, чтобы создавать лучший фундамент. Это не то, что происходит в сообществе Ruby.

После того, как Merb & DataMapper были практически уничтожены (в долгосрочной перспективе), создать нечто новое в экосистеме Ruby оказалось крайне сложно. Поскольку внимание людей сфокусировано на Rails, новые проекты были под его сильным влиянием. Прорваться с новыми идеями было трудно, если не сказать больше… так как каждый раз, когда вы что-то демонстрируете, люди просто хотят, чтобы это было похоже на Rails и хорошо работало с Rails. Делать проекты, которые работают с Rails, — трудно, но я вернусь к этому вопросу позже.

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

Эй, я знаю, как это звучит почти как теории заговора, но не относитесь к этому так. То, что я сказал здесь, — это факты с примесью моих личных чувств. Я начал участвовать в DataMapper в конце 2009 года и, видеть как он рушится было очень грустно.


Сложность!

Сложность является нашим самым большим врагом. Люди стали проявлять меньше энтузиазма к Rails, поскольку быстро оказалось, что имея дело с растущей сложностью, он оставляет нас с большим количеством вопросов без ответа. То, что предлагают DHH & co. никогда не было достаточно, чтобы решить многие проблемы, с которыми тысячи разработчиков начали бороться ещё в 2007-2008 гг. Некоторые люди надеялись, что, возможно, Merb/DataMapper принесут улучшения, но теперь вы знаете, что произошло, так что мы все вернулись обратно к Rails в 2010 году, когда Rails 3.0 был выпущен.

Пару дней назад кто-то запостил на /r/ruby ссылку на статью об организации кода с помощью «Service объектов». Это одна из многих подобных статей. Если вы думаете, что это своего рода тенденция последнего времеми, взгляните на статью James Golick от марта 2010 — «Crazy, Heretical, and Awesome: The Way I Write Rails Apps».

Мы говорим о путях совершенствования архитектуры наших Rails приложений в течение примерно 6 лет. Я пытался внести свой вклад в эту дискуссию насколько я мог — статьями, выступлениями на конференциях и работой над многими проектами с открытыми исходниками, которые стремятся решать различные сложные задачи.

Однако подобные аргументы и идеи всегда высмеиваются членами Rails Core Team, и особенно DHH. Это было отпугивающим и обескураживающим для меня, и это причина почему я никогда не пытался внести свой вклад в Rails. Я чертовски уверен, что мои предложения будут в конечном итоге заминусованы. Monkey-patches? Да ладно, не проблема, мы любим нашу 10.years.ago! Новые абстракции? Кому это нужно, Rails — это просто! TDD? Не проблема, она мертва, не беспокойтесь! ActiveRecord раздутая — ну и что, это же так удобно, давайте добавим больше возможностей!

Экосистема Rails, особенно вокруг своей Core Team, никогда не производила на меня хорошее впечатление, и для меня не проблема признать, что я просто боюсь предлагать любые изменения. Это особенно актуально, так как первое, что я хотел бы предложить «Пожалуйста, удалите ActiveSupport» (ха-ха… представьте себе это!).

Ладно, давайте перейдем к некоторым техническим деталям.


Удобство-ориентированное проектирование Rails

Как я уже говорил, Rails был построен с прицелом на удобство использования. Не путайте это с простотой. Только вчера я наткнулся на этот твит, который говорит об этом всё:

Вот как работает Rails, классический пример:

User.create(params[:user])

Вы видите простую строку кода, и вы можете сразу сказать(если вы знаете, является ли User моделью ActiveRecord), что она делает. Проблема здесь заключается в том, что люди путают простоту с удобством. Эту строку удобно/легко написать в вашем контролере и всё сразу заработает, не так ли?

Однако, эта строка кода не является простой, её легко написать, но код «под капотом» чрезвычайно сложен, так как:


  • params должны пройти через СУБД-специфические приведения типов
  • params должны быть валидированы
  • params могут быть изменены с помощью колбеков, включая потенциальные вызовы внешних систем, вызывающие побочные эффекты
  • невалидное состояние приводит к установке сообщений об ошибках, которые зависят от внешних систем (например I18n)
  • валидные params должны повлиять на состояние объекта, и возможно изменить состояние ассоциированных с ним объектов
  • один объект или весь граф объекта должен быть сохранен в базе данных

Это нехватка разделения ответственности, которая всегда наносит ущерб любому сложному проекту. Это увеличивает связывание(coupling) и затрудняет изменение и расширение кода.

Но в Rails мире это не является проблемой. В Rails мире основные принципы дизайна такие как SRP (и SOLID в целом) высмеивают и представляют как «раздутые, ненужные абстракции, увеличивающие сложность». Когда вы говорите, что предпочитаете моделировать варианты использования приложения, используя свои собственные объекты и делать сложные части явными, лидеры Rails скажут вам YAGNI. Когда вы говорите, что вы предпочитаете использовать композицию, которая делает ваш код более надежным и гибким, лидеры Rails, за исключением tenderlove, скажут вам “use ActiveSupport::Concerns”.

Для Rails-разработчика не проблема, что данные, поступающие из веб-формы направляются в глубины ActiveRecord, где Бог знает, что произойдет.

Действительно сложная часть в этой дискуссии — быть в состоянии объяснить, что это первоочередная проблема. Людей привлекает Rails, потому что он дает вам ложное чувство простоты, в то время как то, что происходит на самом деле, заключается в том, что сложность спрятана за удобными интерфейсами. Эти интерфейсы основаны на многих предположениях о том, как вы собираетесь писать и проектировать ваше приложение. ActiveRecord является лишь одним типичным примером, но Rails полностью построен на этой философии, каждая часть Rails работает аналогично.

Я должен упомянуть, что я знаю об огромных усилиях сделать ActiveRecord лучше, таких как введение Attributes API (сделано с помощью серьезного внутренного рефакторинга, который улучшил кодовую базу). К сожалению, до тех пор пока ActiveRecord поставляется с более чем 200 публичными методами и поощряет использование колбеков и concerns, это всегда будет ORM, которая не в состоянии справиться с растущей сложностью.

Изменится ли эта философия в Rails? Я так не думаю. У нас нет никаких признаков того, что что-то улучшится в этом отношении, так как лидеры Rails просто против этого. Простое доказательство — недавнее спорное дополнение ActiveRecord.suppress, которое было предложено самим DHH. Обратите внимание на то, как он в очередной раз подшучивает над обычными Ruby классами, говоря: «Да, вы можете добиться того же, создав отдельную фабрику CreateCommentWithNotificationsFactory». Ну-ну!


ActiveCoupling

Должен ли Rails являться вашим приложением? Это был важный вопрос, который задают многие после просмотра выступления дядюшки Боба, где он в основном предлагает более сильное разделение между веб-частью и вашим основным приложением. Отбросив технические детали, это хороший совет, но Rails не был разработан с учетом этого факта. Если вы делаете это с Rails, вы теряете всю суть этого фреймворка. По факту, взгляните на то, что сказал DHH об этом:

Его мысли на этот счёт предельно ясны, не так ли? Важной частью является «конечно, является». И знаете, что? Я полностью согласен!

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

Подумайте об этом:


  • ActiveRecord призван стать центральной частью логики вашей предметной области. Вот почему он предоставляет гигантский интерфейс с большим количеством функций. Вы можете иногда извлекать часть логики в отдельные компоненты, когда это имеет смысл. Но Rails философия заключается в том, чтобы поместить всё в ActiveRecord, а не беспокоиться о SRP, не беспокоиться о LoD, не беспокоиться о тесной связи между логикой предметной области и слоем сохранения и так далее. Вот как вы можете эффективно использовать Rails.
  • Весь «слой» представления в Rails связан с ActiveModel, и как следствие он связан и с Active Record ORM (это может быть и Sequel, но это не имеет значения)
  • Контролеры являются неотъемлемой частью Rails-приложения, и сильная связанность имеет место и здесь
  • Хелперы также являются неотъемлемой частью Rails-приложения, сильная связанность ещё раз
  • Все в Rails, и во множестве сторонних gems, созданных для Rails, происходит через наследование (либо mixins, либо на базе классов). Rails и сторонние gems обычно не предоставляют автономных, повторно используемых объектов, они предоставляют абстракции, от которых наследуют ваши объекты — это еще одна форма сильной связанности.

Имея это в виду, было бы сумасшествием считать, что Rails — не ваше приложение. Если вы пытаетесь избежать этого типа связанности, можно себе представить, какие усилии придётся приложить и сколько из встроенной функциональности вы потеряете. И именно поэтому демонстрация альтернативных подходов в Rails создают впечатление раздутых, ненужных абстракций, напоминающих людям об их «страшных» Java днях. Rails не был построен с ориентацией на низкую связность и компонентно-ориентированный дизайн.

Не боритесь с этим. Примите это.


Нежеланная часть

Несмотря на всё вышесказанное, моя самая большая жалоба на Rails — это ActiveSupport. Так как я уже писал об этом, я не чувствую, что мне нужно повторяться. Я также рекомендую почитать комментарии в той статье.

Единственное, что я хотел бы добавить, что именно из-за ActiveSupport я не считаю Rails желанной частью экосистемы Ruby. Эта библиотека является квинтэссенцией всего неправильного в Rails для меня. Отсутствие фактических решений, отсутствие чётких абстракций, просто куча воркэраундов для решения проблемы под рукой, воркэраунды, которые превращены в официальный API, и карго-культ в результате. Чудесно!

Rails является закрытой экосистемой, и это накладывает плохие требования на другие проекты. Если вы хотите заставить что-то работать с Rails, вы должны позаботиться о таких вещах, как работоспособность при подключенном ActiveSupport, или что ничего не сломается от зверской перезагрузки кода в режиме разработки, или что объекты предоставляются глобально, потому что, ну вы знаете, в Rails всё должно быть доступно везде, для вашего удобства.

То, как работает Rails, требует много дополнительных усилий от разработчиков, создающих свои гемы. Прежде всего, следует ожидать, что ваши гемы могут работать с Rails (потому что, очевидно, все будут использовать их с Rails), и это само по себе является непростой задачей. У вас есть библиотека, которая работает с базами данных, и вы хотите заставить её работать с Rails? Ну вот, теперь вы должны заставить её работать, как ActiveRecord, более или менее, поскольку интерфейс интеграции — ActiveModel, изначально основан на ActiveRecord времён Rails 3.0.

Есть множество ограничений, которые делают интеграцию с Rails весьма трудной задачей.

Вы понятия не имеете, со сколькими проблемами вы можете столкнуться при попытке заставить код работать с горячей перезагрузкой кода в режиме разработки. Rails ожидает глобальную, изменяемую среду выполнения. Для того, чтобы сделать всё еще труднее, они ввели Spring. Этот гем открывает целую категорию потенциальных новых багов, с которыми ваши гемы могут столкнуться, когда вы пытаетесь заставить их работать с Rails. Я настолько задолбался с этим, друзья мои, что мне больше нечего сказать. Мало того, что перегрузка кода в Ruby работает ненадежно, так это к тому же добавляет кучу совершенно ненужной сложности для наших гемов и приложений. Это влияет на всех, кто разрабатывает гемы, которые должны работать с Rails. Никто из команды ядра Rails, несмотря на критику на протяжении многих лет, даже не думал, что было бы хорошей идеей, посмотреть, как это можно было бы сделать лучше. Если бы кто-нибудь просто сосредоточился на повышении скорости загрузки приложения, мы могли бы положиться просто на перезапуск процесса. Кроме того, вы должны действительно использовать автоматизированное тестирование, чтобы удостовериться, что изменение, которое вы только что сделали, на самом деле работает, а не жать F5. Просто к вашему сведению.

Я знаю, это звучит, как будто я жалуюсь, хотя по сути так и есть! Я пытался поддерживать Rails и это было слишком разочаровывающим опытом для меня. Я сдался, я не хочу делать это больше.

Посколько моё решение проблем подразумевало выдирание ActiveSupport, удаление ActiveRecord и добавление нормального слоя представления, который был бы отделен от любого ORM, я понял, что неразумно думать, что это когда-нибудь произойдет в Rails.


Уход от Rails

В результате девяти грёбанных лет работы с Rails и активной работы над многими OpenSource проектами на Ruby, я сдался. Я больше не верю, что нечто хорошее может случиться с Rails. Это моя личная точка зрения, но многие люди разделяют те же самые чувства. В то же время, есть много других, которые по-прежнему счастливы с Rails. Рад за них! Честно! Rails вошёл во всеобщее употребление, у него есть своя сфера применения, он по-прежнему помогает людям и это зрелый, хорошо поддерживаемый, стабильный веб-фреймворк. Я не пытаюсь убедить кого-либо, что Rails в конечном счете плохой! Он просто очень плохой для меня.

Впрочем это имело свои последствия. Именно поэтому я оказался вовлечён в такие проекты, как dry-rb, hanami and trailblazer и поэтому я давно работаю над rom-rb. Я хочу помочь построить новую экосистему, которая, мы надеемся, вернёт тот же самый энтузиазм, который мы все чувствовали во времена Merb и DataMapper.

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


Уход от Ruby

Правда в том, что уход от Rails — также начало моего следующего путешествия — ухода от Ruby в качестве основного языка. Я вдохновился функциональным программированием в последние пару лет. Вы можете видеть, что в этом стиле я пишу теперь и на Ruby. Я наблюдаю за ростом Elixir с большим воодушевлением. Я также изучаю Clojure, который в данный момент находится на вершине моего списка «языки для изучения». Чем больше я узнаю, тем больше я люблю его. Моя конечная цель состоит в том, чтобы изучить ещё и Haskell, поскольку я заинтригован его статической типизацией. В настоящее время на работе я программирую на Scala. Я смог очень быстро оценить преимущества статической типизации в нём, несмотря на то, что это была жёсткая перестройка моего рабочего процесса разработки, включая компиляцию и TypeError ошибки. Это освежающий опыт — видеть как мой редактор говорит мне, что я сделал ошибку, прежде чем я добрался до выполнения каких-либо тестов.

Чем больше я погружаюсь в функциональное программирование, тем больше я вижу насколько отстаёт Rails, когда дело доходит до современного дизайна приложений. Monkey-patching, опора на глобальное изменяемое состояние, сложный ORM — эти вещи рассматриваются в качестве основных проблем в функциональных языках.

Я знаю, многие скажут «но Ruby является объектно-ориентированным языком, используй это в свою пользу, вместо того, чтобы пытаться сделать из него то, чем он не может быть». Но это не так. Прежде всего, Ruby является объектно-ориентированным язык с функциональными особенностями (блоки, лямбды и т.д.). Во-вторых, избегание изменяемого состояния является общим, хорошим советом, который вы можете применить в своем Ruby-коде. Устранение глобального состояния и изолирование его, когда вы не можете его избежать, — также очень хороший общий совет.

Как бы там ни было, я покидаю Ruby. Я уже начал этот процесс. Он займёт годы, но это мой путь. Я буду продолжать работать и поддерживать rom-rb, dry-rb, помогать с hanami и trailblazer. Так что не волнуйтесь, эти проекты очень важны для меня, и я счастлив наблюдать рост их сообществ.


Наиболее частая обратная связь

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


Заткнись. Rails великолепен и работает очень хорошо для меня.

Это является наиболее распространенным вариантом обратной связи, которую я получаю. Прежде всего, меня беспокоит, что многие люди так реагируют. Мы обсуждаем инструмент, а не человека, нет необходимости воспринимать это так эмоционально. Не поймите меня неправильно, я понимаю, что это естественно «защищать» что-то, что помогло вам, или то, что вам просто нравится, в то же время здорово иногда выходить за рамки привычного мышления, быть открытым к критике и спокойно анализировать её. Если вы счастливы с Rails, это здорово, на самом деле.


Ты просто жалуешься, ты не помогаешь, ты ничего не сделал, чтобы помочь Rails стать лучше, ты не предложил никаких решений описанных проблем

Этот тип обратной связи раньше меня очень злил и огорчал. В момент написания этой статьи, в соответствии с GitHub, я сделал 2435 коммитов в OSS прошлом году. Это было в моё свободное время. Да, я не способствовал улучшению непосредственно Rails из-за причин, которые я объяснил в этой статье. Там слишком много того, с чем я не согласен, и это было бы пустой тратой времени для обеих сторон. Я вносил свой вклад через статьи в блогах, доклады на конференциях и тысячи строк OpenSource кода, которые вы можете найти на GitHub.


Это OSS, просто форкни Rails

Это абсолютно мимо кассы. Нам необходимо разнообразие в экосистеме с хорошим выбором библиотек, а также несколько фреймворков с их уникальным набором фич, делающим их пригодными для различных вариантов использования. Форк Rails не будет иметь никакого смысла. Никто не будет форкать Rails, чтобы пройти через такие испытания, как удаление ActiveSupport и устранение высокой связности от таких концептов как ActiveRecord и т.д. Проще и быстрее создать что-то новое, что другие люди уже и делают (см. Hanami).

habr.com

Знакомство с Ruby on Rails 3.0 / Habr

Добрый день, друзья. Не так давно мы с друзьями-коллегами решили поизучать Ruby on Rails – что это такое и с чем едят – для использования в будущем при разработке своих проектов.

Так как знаний по данной теме не было вообще, то и двигаться решили постепенно. При начальной установке Ruby с Rails 3.0 мы столкнулись с некоторыми трудностями, о которых в мануалах так сходу никто не упоминал. Поэтому я решил написать это небольшое руководство (которое является обобщением собственного опыта и перевода мануала на guides.rubyonrails.org/getting_started.html) по изначальной установке и настройке Ruby on Rails 3.0 для того, чтобы помочь таким же начинающим как я найти полезную информацию в одном месте и сэкономить свое время.

Манипуляции проводились на системе Windows XP SP2. На Windows 7 все то же самое, а на Висте рельсы у меня не поставились, но об этом позже.

Итак, для начала надо скачать Ruby installer. Инсталляция там нетрудная и все ясно (только сразу обновите переменную PATH, как это предлагается сделать).

Потом запустить командную строку с поддержкой Ruby.

Теперь нам нужно установить рельсы. В командной строке пишем:

gem install rails

На Висте ничегошеньки не получилось – при запуске этой команды появлялось сообщение о том, что не удалось найти папку C:\Users\Владелец. Наверняка, дело тут было в кириллице в названии папки, но особо в детали я вдаваться не стал.

Мы для своих начальных нужд будем использовать базу sqlite3. Чтобы все прошло корректно, нужно будет скачать 2 архива: тут и тут и распаковать их в папку с RoR 3.

Теперь в командной строке набираем:

gem install sqlite3-ruby

После завершении установки библиотек sqlite3 нам надо будет создать свое приложение, в нашем случае блог. В командной строке пишем:

rails new blog

Наш блог создан, теперь надо перейти в папку приложения:

cd blog

Приложения Rails для управления gem-зависимостями по умолчанию используют Bundler. Так как кроме тех gem’ов, что у нас уже есть, других не требуется, можно просто написать:

bundle install

Rails поставляется со встроенной поддержкой SQLite3. Эта база вполне годится для разработки и тестирования, но не для промышленной эксплуатации. По умолчанию при создании нового проекта Rails использует именно базу данных SQLite, однако вы легко можете поменять эти настройки.

Тут я приведу часть дефолтного файла конфигурации (config/database.yml) с информацией по соединению для среды разработки:

  1. development:
  2.  adapter: sqlite3
  3.  database: db/development.sqlite3
  4.  pool: 5
  5.  timeout: 5000

Теперь, после конфигурации базы данных, самое время скомандовать рельсам создать пустую базу. Это можно сделать с помощью команды rake:

rake db:create

После этого в папке db/ будут созданы базы development и test.

Собственно, теперь у нас уже есть функционирующее Rails-приложение. Чтобы в этом убедиться, нужно запустить веб-сервер командой:

rails server

Увидеть свое приложение в действии можно если открыть браузер и набрать в адресной строке localhost:3000

Страница «Welcome Aboard» — это тест для Rails-приложения, позволяющий убедиться, что вы сконфигурировали программное обеспечении верно. Посмотреть информации о среде вашего приложения можно кликнув на ссылку «About your application’s environment».

Чтобы заставить Rails сказать «Привет», нужны, как минимум, котроллер и представление (view). К счатью, для их создания понадобится всего лишь одна команда:

rails generate controller home index

Rails создаст несколько файлов, включая app/views/home/index.html.erb. Это образец, который будет использоваться для отображения результатов метода index в контроллере home. Откройте этот файл в текстовом редакторе и отредактируйте таким образом, чтобы он содержал лишь одну строчку кода:

  1. <h2>Hello, Rails!</h2>

Теперь, после того как мы создали котроллер и представление, нам надо как-то сказать рельсам когда отображать страницу «Hello Rails». В нашем случае, мы хотим, чтобы эта страница отображалась по корневому URL нашего сайта localhost:3000, вместо тестовой страницы «Welcome Aboard». Первым делом надо удалить дефолтную страницу из нашего приложения:

cd public

del index.html

Теперь нам надо сообщить Rails, где находится наша нынешняя домашняя страница. Откройте файл config/routes.rb в текстовом редакторе. Это файл маршрутизации нашего приложения, который содержит точки входа, написанные на специальном языке DSL (domain-specific language). В этом файле содержится множество примеров путей (они закомментированы), и один из них как раз показывает как соединить свою корневую страницу с конкретным контроллером и выполнить действие. Найдите строчку, которая начинается с root :to, раскомментируйте её и поменяйте, чтобы она выглядела примерно вот так:

  1. Blog::Application.routes.draw do
  2.  
  3.  #...
  4.  # You can have the root of your site routed with "root"
  5.  # just remember to delete public/index.html.
  6.  root :to => "home#index"

root :to => «home#index» скажет Rails отображать действие root на действие (метод) index контроллера home.

Теперь если вы зайдете на localhost:3000, то увидите надпись «Hello, Rails!»

В Rails есть понятие строительных лесов (Scaffold) — это быстрый способ создания главных частей приложения. Если вы хотите создать модели, представления и контроллеры, то это именно тот инструмент, который следует использовать.

В нашем случае (приложение-блог) можно начать с создания при помощи Scaffolding ресурса Post, который будет представлять собой пост в блоге. Для этого нужно написать такую команду:

rails generate scaffold Post name:string title:string content:text

Один из файлов, создаваемых командой rails generate scaffold это миграция базы данных (database migration). Миграции – это классы Ruby, которые разработаны для того, чтобы упростить создания и изменение таблиц баз данных. Для запуска миграций Rails использует команды rake, и есть возможность отменить миграцию после того, как она была применена к базе данных. Название файла миграции включает в себя временную метку, для того, чтобы легко было убедиться в том, что миграции запускаются в порядке их создания.

Если вы откроете файл db/migrate/20100917061914_create_posts.rb (помните, что название вашего файла будет слегка отличаться), то увидите там следующее:

  1. class CreatePosts < ActiveRecord::Migration
  2.  def self.up
  3.   create_table :posts do |t|
  4.    t.string :name
  5.    t.string :title
  6.    t.text :content
  7.    t.timestamps
  8.   end
  9.  end
  10.  
  11.  def self.down
  12.   drop_table :posts
  13.  end
  14. end

Эта миграция создает два метода up, вызываемых при запуске миграции в базу данных, и down, который используется в случае, когда нужно откатить изменения, сделанные в базе данных этой миграцией. Команда up создает таблицу posts с двумя строковыми столбцами и одним текстовым столбцом. Также она генерирует два поля для временных меток, которые нужны для отслеживания создания записей и изменения данных.

Теперь можно запустить миграцию командой:

rake db:migrate

Rails выполнит эту миграцию и сообщит о создании таблицы Posts.

Чтобы подключить посты к домашней странице, которую мы создали ранее, можно добавить ссылку на неё. Откройте файл app/views/home/index.html.erb и измените его следующим образом:

  1. <h2>Hello, Rails!</h2>
  2. <%= link_to "My Blog", posts_path %>

Метод link_to — один из встроенных в Rails помощников (helper). Он создает гиперссылку, основанную на тексте, который надо отображать и на том пути, куда надо обращаться – в данном случае путь к постам.

Теперь всё готово для того, чтобы начать работу с постами. Чтобы это сделать, нужно открыть ссылку localhost:3000 и кликнуть на «My Blog» (я себе сделал именной блог — Alex’s блог):

Вы увидите результат воспроизведения Rails представления index ваших постов. На данный момент в базе данных нет ни одной записи, но можно создать новый пост, если кликнуть на «New Post». После этого вы увидите, что можете редактировать посты, просматривать детали, относящиеся к ним, а также удалять их. Собственно, вот и всё для начала, мы встали на рельсы!

В следующей статье-переводе речь пойдет о том, как добавить вторую модель в приложение. Рад был, если помог кому-то сэкономить хотя бы час-другой времени на поиск информации. Всем удачи!

Статья написана моим другом alexlash, кармы которого пока не хватает уже хватает для публикации постов.

habr.com

Ruby on Rails — это… Что такое Ruby on Rails?

Ruby on Rails — фреймворк, написанный на языке программирования Ruby. Ruby on Rails предоставляет архитектурный образец Model-View-Controller (модель-представление-контроллер) для веб-приложений, а также обеспечивает их интеграцию с веб-сервером и сервером базы данных.

Ruby on Rails является открытым программным обеспечением и распространяется под лицензией MIT.

Принципы

Ruby on Rails определяет следующие принципы разработки приложений:

  • Ruby on Rails предоставляет механизмы повторного использования, позволяющие минимизировать дублирование кода в приложениях (принцип Don’t repeat yourself).
  • По умолчанию используются соглашения по конфигурации, типичные для большинства приложений (принцип Convention over configuration). Явная спецификация конфигурации требуется только в нестандартных случаях.

История

Ruby on Rails был создан Давидом Хейнемейером Ханссоном на основе его работы в компании 37signals над средством управления проектами Basecamp[1] и выпущен в июле 2004 года.

25 мая 2010 года выпущена версия 2.3.8.

23 декабря 2008 года команда проекта Merb объединилась с командой Rails с целью создания следующей версии Rails 3, которая объединит в себе лучшие черты обоих фреймворков.[2][3]

29 августа 2010 года вышел Rails 3.0.[4]

31 августа 2011 года вышел Rails 3.1.[5]

20 января 2012 года вышел Rails 3.2.[6]

Архитектура

Схематическое представление архитектуры модель-представление-контроллер

Основными компонентами приложений Ruby on Rails являются модель (model), представление (view) и контроллер (controller).

Модель

Модель предоставляет остальным компонентам приложения объектно-ориентированное отображение данных (таких как каталог продуктов или список заказов). Объекты модели могут осуществлять загрузку и сохранение данных в реляционной базе данных, а также реализуют бизнес-логику.

Для хранения объектов модели в реляционной СУБД по умолчанию в Rails 3 использована библиотека ActiveRecord. Конкурирующий аналог — DataMapper.

Представление

Представление создает пользовательский интерфейс с использованием полученных от контроллера данных. Представление также передает запросы пользователя на манипуляцию данными в контроллер (как правило, представление не изменяет непосредственно модель).

В Ruby on Rails представление описывается при помощи шаблонов ERB. Они представляют собой файлы HTML с дополнительными включениями фрагментов кода Ruby (Embedded Ruby или ERb). Вывод, сгенерированный встроенным кодом Ruby, включается в текст шаблона, после чего получившаяся страница HTML возвращается пользователю. Кроме ERb возможно использовать ещё около 20 шаблонизаторов.

Контроллер

Контроллер в Rails — это набор логики, запускаемой после получения HTTP-запроса сервером. Контроллер отвечает за вызов методов модели и запускает формирование представления.

Контроллером в Ruby on Rails является класс, наследованный от ActionController::Base. Открытые методы контроллера являются так называемыми действиями (actions). Action часто соответствует отдельному представлению. Например, по запросу пользователя admin/list будет вызван метод list класса AdminController и затем использовано представление list.html.erb.

Интеграция

Предпочтительным методом интеграции с веб-серверами является проксирование — использование веб-сервера в качестве прокси-сервера перед сервером приложения. Особняком стоят модули Phusion Passenger для интеграции с серверами Apache и nginx.

Ruby on Rails использует интерфейс RACK, что позволяет использовать менее распространённые механизмы (FCGI, CGI, SCGI). Ruby on Rails может работать с Apache, Lighttpd или любым другим веб-сервером, поддерживающим FastCGI. Для разработки и отладки часто используется веб-сервер WEBrick, встроенный в Ruby, или Mongrel.[7] В качестве сервера базы данных поддерживаются MySQL, Firebird, PostgreSQL, DB2, Oracle и Microsoft SQL Server. Также поддерживается встраиваемая база данных SQLite.

Для Windows существует дистрибутив Instant Rails c настроенной и готовой к работе сразу после установки рабочей средой для разработки Rails-приложений, которая включает в себя сервер Apache и СУБД MySQL. Для платформ Windows, Linux, Mac OS X имеется комплексный установщик BitNami RubyStack[8], включающий в себя все необходимое для разработки в среде Rails, включая Ruby, RubyGems, Ruby on Rails, MySQL, Apache, Mongrel и Subversion.

Помимо этого сайты BitNami.org и JumpBox.com[9] бесплатно предлагают образы VMware с готовой Linux-средой для развертывания RoR-приложений. Эти образы можно подключить к своему серверу виртуальных машин или развернуть в предлагаемой облачной среде.

Для разработки AJAX-приложений в RoR по умолчанию используется javascript-фреймворк jQuery, однако вместо него можно использовать и другие библиотеки. В ранних версиях Ruby on Rails (до 3.1), js-фреймворком по умолчанию был Prototype.

Реализации

JBoss предлагает открытую платформу Torquebox[10] для развертывания Rails-приложений, предлагающую функции планировщика задач, очереди сообщений, SOAP и даже управление SIP-сессиями.

Плагины

  • ActiveScaffold — популярная альтернатива стандартному «scaffold», с использованием AJAX.[11]
  • CommunityEngine — плагин-шаблон для быстрого создания полноценной социальной сети.[12]

Сайты на Rails

Популярные сайты на Rails:

Примечания

Литература

  • Тейт Б., Хиббс К. Ruby on Rails. Быстрая веб-разработка. — СПб.: BHV-Петербург, 2008. — 224 с.
  • Хэнссон Д. Х., Томас Д. Гибкая разработка веб-приложений в среде Rails. — СПб.: Питер, 2008. — 720 с.
  • Фоулер Ч. Rails. Сборник рецептов. — СПб.: Питер, 2007. — 256 с.
  • Фернандес О. Путь Rails. Подробное руководство по созданию приложений в среде Ruby on Rails. — Символ-Плюс, 2008. — 768 с.
  • Руби С., Томас Д., Хэнссон Д. Х. Гибкая разработка веб-приложений в среде Rails. — 4-е изд. — Питер, 2012. — 464 с.

Ссылки

dic.academic.ru

Почему стоит переходить на Ruby и Rails › Блог Интернет Технологий

От автора и предисловие:

Доброго времени суток всем постоянным и не постоянным читателям блога bitby.net. Хочу поздравить вас со сменой дизайна, по мне, так он стал лучше и текст стал более легко воспринимаемым.

Я являюсь новичком в Ruby, тем не менее я имею достаточный опыт программирования на PHP. От того, чтобы я стал php-гуру меня спас один мой друг — опытный программист на php, Python, Ruby, который и посоветовал мне Ruby. Я долго сомневался, а стоит ли браться за изучение чего-то нового, отправлять те знания и опыт, которые у меня уже имеются в топку и заниматься изучением нового языка программирования. Тем не менее аргументы в пользу Ruby и Rails были очень убедительными и вот я стал Рубистом. В помощь себе и другим людям желающим изучить Ruby и Rails я создал блог Разработка на Ruby и Ruby on Rails с нуля, надеюсь он сослужит добрую службу всем новичкам.Кстати, для желающих изучить работу в Rails я начал готовить учебник Ruby on Rails, пока что на основе переводных статей.

В этом посте я хочу познакомить вас с Ruby и Rails и рассказать, почему стоит выбрать именно этот язык программирования и этот веб-фреймворк.

Что такое Ruby и Ruby on Rails

Ruby – сверх динамический, объектно-ориентированный язык программирования, который был создан опираясь на утверждение «Язык программирования должен быть удобен для человека, а не для машины!» Таким образом, Якихиро Мацумото в 1995 году явил миру первую публичную версию Ruby. На данный момент Ruby дорос до версии 1.9.2 и имеет множество отличительных черт и достоинств, которые делают Ruby весьма мощным и удобным языком программирования, позволяющим создавать достойные приложения в разы быстрее, чем при использовании языков программирования более низкого уровня.
Ruby on Rails – великолепный веб-фреймворк написанный Девидом Хэйнемеером-Хенсcоном на Ruby, за что DHH (так прозвали Девида в Ruby-сообществе) получил в OSCON звание «Hacker of the Year». Фреймворк Rails сочетает в себе все передовые технологии, идеи и паттерны проектирования, благодаря чему разработка на нем становится в разы проще и быстрее. В конце 2008 года команда разработчиков другого мощного фреймворка на Ruby – Merb объединилась с командой Rails для совместной работы над проектом Rails 3. На данный момент уже выпущен релиз-кандидат Rails 3. Rails3, по заявлению авторов, должен был вобрать в себя все лучшие стороны Merb, например, модульность, гибкость, расширяемость. Судя по тому, что нам представляется в релиз-кандидатах Rails3, можно сказать, что авторам Rails и Merb удалось сделать Rails3 модульным и более удобным для разработчиков.

Почему стоит переходить на Ruby и Ruby on Rails

1. Агресивность рынка веб-разработки. В последнее время рынок веб-разработки очень сильно вырос, выросла и конкуренция. Rails позволяет разработчику в разы быстрее выполнять заказ, при этом экономятся человеко-часы и значительно снижается себестоимость. Благодаря этому разработчики за то же время могут выполнить большее количество работы (заказов), и снизить цену не в ущерб качеству работы.

2. Весьма большое, развивающееся сообщество. Стоит признать, что сообщество Ruby не такое большое, как у Python и тем более PHP. Однако профессионализм членов сообщества впечатляет. Не стоит бросаться туда, где больше людей, стоит идти туда, где люди лучше. Не стоит идти на поводу известной пословицы: «Миллиарды мух не могут ошибаться, в PHP все-таки что-то есть» (пословицу я немножко перефразировал).

3. Огромное количество готовых библиотек и кода. На данный момент Ruby отлично обеспечен библиотеками для работы со сторонними разработками, такими как базы данных: MySQL, PostgreSQL, MongoDB, SQLite и т.д., различные веб и не-веб сервера, библиотеки для работы с графикой, звуком, видео и т.д. Ruby не просто язык написания скриптов — это полноценный язык программирования. На данный момент сообществом создано более 900000 gem’ов (GEM – так называются расширения Ruby), которые значительно ускоряют и упрощают разработку, ведь возникшую у вас проблему, уже кто-то решил до вас, причем с 99.99% вероятностью, что решение этого человека значительно лучше того, что могли бы предложить вы. Стоит упомянуть о множестве gem’ов и плагинов созданных специально для Rails, это опять-таки позволяет вам экономить время на разработку и собственные нервы на написание велосипедов.

4. Ето же Rails! Ruby on Rails, или просто RoR – это самый популярный Ruby –фреймворк для разработки веб-приложений. Множество программистов завидуют ruby’стам за то, что те имеют такой мощный, и в тоже время, простой инструмент. Не стоит забывать о том, кто является разработчиками Rails!

5. Ruby – это не только Rails! У новичков часто слаживается впечатление о том, что Rails – это единственное преимущество Ruby над PHP, Perl, Python, Java… На самом делеэто не так! Ruby используется в администрировании, в прототипировании, в научных исследованиях, в разработке игр и различных приложений как язык написания скриптов и т.д. Ruby используют такие компании: Microsoft, HP, NASA, Cisco и т.д.

6. Ruby 1.9! Ruby не лишен недостатков и основным недостатком была крайне низкая скорость работы и большой объем потребляемых ресурсов. С каждой новой версией Ruby оптимизировался и боролся со своими недостатками, и в версии 1.9 мы видем много значительных улучшений. Например, Ruby 1.9 обогнал по производительности PHP, Perl, Python3 (из доклада Ехуды Каца), оставив впереди лишь Python 2. Ruby 1.9 более удобен, разумен и быстр.

Так уж сложилось, что большая часть веб-проектов разработывается на PHP, именно по этой причине я хочу раскрыть вам несколько причин того, почему стоит переходить c PHP на Ruby.

Почему PHP sucks, а Ruby — мечь Дао веб-разработки

1. Ruby язык общего назначения, а PHP – нет! Ruby используется во множестве областей разработки и научных исследований, моделировании и т.д., а PHP годится лишь для разработки веб-приложений. PHP написан, если не ошибаюсь, на Си, а Ruby по-большей части на Ruby… PHP работает под различными вебсерверами от сторонних разработчиков типа Apache и nginx, а Ruby имеет несколько веб-серверов написанных на самом Ruby, но отлично работает и на Apache, и на nginx, и на LightHTTPd.

2. Ruby более легкий, чем PHP и имеет более понятный синтаксис, обладает множеством встроенных в сам язык паттернов программирования и различными удобными конструкциями, как, например итераторы, которые не доступны разработчикам на PHP.

3. У Ruby очень быстрые темпы развития, у PHP – нет… Новые версии Ruby имеют заметные преимущества над предыдущими, а в PHP 5.3 был добавлен никому не нужный GOTO=)))

4. Создатели Ruby – опытные программисты со всего мира, а создатели PHP – опытные программисты из Zend. Zend нацелены на получение прибыли с PHP (дорогущая ZendStudio и т.д., странно, как это ZendFramework не стал платным, но думаю, это дело времени), разработчики Ruby – безумные фанатики занятые разработкой оружия порабощения всего мира!=)

5. Ruby on Rails vs ZendFramework. Сами понимаете … CakePHP, Lithium Framework – жалкие попытки создать Rails на PHP. CI, Kohana, Yii – недоZendFramework.

6. Сообщество Ruby – в большинстве своем опытные программисты с желанием и возможностью помочь новичкам. Сообщество PHP – 80% школота, 19% — программисты среднего уровня из мелких и среднего размера студий. Коду на Ruby можно доверять, код на PHP необходимо тщательно проверять.

7. PHP –разработчики аргументируют то, что PHP лучше тем, что на PHP написано множество огромных проектов с чуть-ли не миллиардными аудиториями. На самом деле стоит понимать, что при разработке таких проектов используется целый зоопарк языков программирования. Vkontakte и Facebook можно было бы написать на Ruby в несколько раз быстрее, а узкие места также оптимизировать на Си, Erlang’е и т.д.

Кстати, на Ruby были разработаны: Twitter, Scribd, YellowPages, Groupon, а из русского: серверная часть приложения Вконтакте – ЛицеМер, которое находится на 2м месте по популярности, соцcеть LookAtMe и многое другое. Стоит упомянуть, что ориентировочно, каждый 2й стартап в США создается на Ruby on Rails, здесь Ruby и PHP идут практически вровень.

Недостатки Ruby по сравнению с PHP: малое количество документации на русском языке и маленькое русскоязычное сообщество. Тем не менее, существует русский перевод отличной книги «Programming Ruby», а также перевод книги «The Ruby Way» — “Программирование на языке Ruby” авторства Хэла Фултона. Еще один перевод замечательной книги, но уже совсем для новичков, доступен онлайн: «Learn to Program». Учите английский и читайте мой блог Разработка на Ruby и Ruby on Rails с нуля =) С уважением, Vasilenko Ivan!

bitby.net

Ruby on rails что такое

Сегодня в интернетах я нашел историю о том, как некто Джеймс Фенд учился Ruby on Rails в течение 12 недель. Ниже вы можете прочитать относительно точный перевод этой истории, и, надеюсь, вдохновиться на изучение этого прекрасного фреймворка (и прекрасного языка).

Прежде чем начать, я хотел бы представить Джоша Криуса (http://joshcrews.com) и поблагодарить его за то, что убедил меня начать изучать Ruby on Rails; без него, его помощи и без часов, которые он потратил на то, чтобы быть моим наставником, я не писал бы это сегодня. Спасибо.

23 января я запустил идею своей мечты, Freelancify.com.

Ровно 12 недель назад я был техническим предпринимателем (tech entrepreneur), который тратил тысячи долларов, чтобы создать приличный MVP (минимально жизнеспособный продукт), потому что мне недоставало знаний. Одной из причин (как я тогда думал) было то, что обучение было для меня слишком сложным или заняло бы чрезмерно много времени. Я думал (как и многие другие), что программисты (и некоторые действительно) рождаются с набором волшебных навыков в решении проблем и математике, которые делают их гениями программирования. И именно 12 недель назад я принял лучшее решение за долгое, по-настоящему долгое время. Больше ни одна из моих идей не останется не более чем идеей. Теперь у меня есть возможность запускать рабочие версии, тратя деньги лишь на хостинг и прилагая некоторые усилия. На сегодняшний день этот набор навыков — это примерно как пригнать кучу тракторов во времена калифорнийской золотой лихорадки, пока все остальные используют простые лопаты. Я предлагаю каждому научиться писать код. Здесь я хотел бы добавить уточнение: ранее, назвал пост “Как я изучил Rails за 8 недель”, однако, если быть точным, то учитывая дату запуска, получается 12 недель. Однако за 8 недель я почувствовал, что знаю достаточно, а следующие четыре недели были потрачены в большей степени на то, чтобы заставить полученные знания работать, а не на обучение.

Какие навыки я имел прежде, чем начал изучать Rails?

Я был веб-дизайнером, обладающим познаниями в HTML и CSS, и, в основном, фокусировался на дизайне UI и UX. Самое сложное, что я делал с реальным кодом (не считая HTML) — это возможность настраивать WordPress. Одним словом, я абсолютно не имел представления ни о том, что такое MVC-фреймворк, ни о том, как в целом работают базы данных. Дизайн, макет и HTML для Freelancify были созданы мной за две недели в июне 2011-го.

Почему я принял решение учиться?

Возвращаясь в июнь 2011-го, когда макет был готов, я начал поиски кодера, который сделал бы макет функционирующим. Макет был практически готов: у меня были текстовые поля, выпадающие меню, формы, кнопки, ссылки, ведущие куда необходимо, и так далее. Нашел разработчика, и, если в двух словах, то парень мне не подошел. Я остался с кучей долгов и даже не близким к завершению продуктом. Тогда я связался с Джошем Криусом (с ним я познакомился на встрече, посвященной Ruby on Rails, которую он организовал в Нэшвилле), и встретился с ним, чтобы понять, можно ли сделать хоть что-то из того, что у меня осталось от разработчика. К сожалению, починка и доработка кода заняла бы не меньше времени, чем разработка с нуля грамотным программистом. Я упал духом, понимая, что не смогу позволить себе снова тратить тысячи долларов на разработку с нуля. И тогда Джош сказал… “Почему бы тебе просто не научиться обращаться с Ruby on Rails, этот проект был бы прекрасным способом” и затем “Я могу даже встречаться с тобой дважды в неделю и помогать тебе в обучении”. Я потратил целую ночь на раздумья. Моими вариантами было: найти комфортную работу и оплатить счета ИЛИ рискнуть всем, чтобы научиться Rails и, в конце концов, лакомиться лучшим раменом, который только готовят в Италии. Я решил. Позвонил Джошу на следующее утро. Я поставил все. Я выделил деньги из оставшихся сбережений и разделил их на три месяца (для неженатого парня, живущего в одиночестве и без детей одной тысячи долларов на месяц вполне достаточно). Время приниматься за работу, теперь я ученик на полном рабочем дне. Держу в уме: поиск в Google, Stackoverflow, IRC #RubyOnRails и сообщество Rails будут прикрывать меня, когда я застряну, уверен, что их будет достаточно.

Мои следующие три месяца — Миссия: получить MVP, получить достаточно, чтобы работать, но не “отстойно-достаточно”, чтобы оставить ужасное первое впечатление.

Недели 1 — 3

Это была, пожалуй, сложнейшая кривая обучения, но я НЕ сдавался.

Стены созданы для людей, которые, на самом деле, не хотят их покидать.

Установка рабочего окружения Rails для полного новичка может оказаться невероятно раздражающей. Подсказка #1: заимейте Mac. Подсказка #2: используйте Homebrew, RVM, Git и Heroku (на самом деле это все, что вам нужно, чтобы начать). Я потратил пару дней на установку, затем все удалил и снова установил. Достаточно повторить несколько раз, и вы привыкните к использованию командной строки терминала (консоли) и поймете, почему вещи работают так, как они работают.

Затем, первая вещь, которой я занялся, были уроки TryRuby, Rails for Zombies и Rails Tutorial Майкла Хартла. Не беспокойтесь о том, чтобы на 120% понять материал, этого не случится, пока вы не начнете по-настоящему учиться. Я закончил Rails Tutorial и создал это похожее на Twitter приложение примерно за неделю, не совсем понимая, что я сделал. Позднее, по мере продвижения, я стал понимать, что все начинает обретать смысл.

Недели 3 — 6

С Twitter-приложением, созданным при помощи Rails Tutorial, я обрел некоторую уверенность. Руководство не сделало меня разработчиком, но теперь я знаю общие шаги в создании приложений, с создания самого приложения, и до установки его на Heroku. Все, что было между тем временем оставалось размытым. Как мне теперь ПО-НАСТОЯЩЕМУ начать учиться? Работая над реальным проектом, который что-то для меня значит. Джош и я решили, что мне стоит свободно поработать над Freelancify и посмотреть, что я смогу сделать. Первым, что я сделал, был перенос всего HTML с каркаса и организация его в файлы видов(views) и парциалов(partials). Я создал(scaffolded) шаблонные платформы для Пользователей(Users) и Проектов(Projects).

13 фактов о Ruby on Rails – Что вам нужно знать?

Затем я начал изучать мой первый реальный гем Devise. Затем, возможность иметь отношения, например каждый Пользователь будет иметь портфолио. Но пользователи могут иметь множество портфолио, в то время как каждое портфолио может принадлежать лишь одному Пользователю. Когда вы поймете, как работают отношения между моделями и как вызывать/отображать вещи, которые принадлежат чему-то еще, жизнь станет намного проще. Если в какой-то части вы застряли и не можете сдвинуться с места, пропустите её, велика вероятность того, что пока вы разрабатываете другую возможность, вы так же поймете, как реализовать и то, что вы пропустили.

Недели 6 — 9

Шажок за шажком, я продолжал учиться, копируя и повторяя. Я мог заставлять какие-то вещи работать, а затем — бац — и я втыкался в стену и абсолютно не представлял, что же делать дальше. Заходя на Stackoverflow, IRC-чат #RubyOnRails, RailsCasts или дергая Джоша, в конце концов, я понимал, как действовать. Делайте то же самое снова и снова, и вы научитесь всему довольно быстро. Тратить раздражающие часы, тестируя чей-то ответ со Stackoverflow, чтобы понять, что он не работает — это, на самом деле, полезно. Вы понимаете, чего не следует делать. И когда вы найдете ответ, вы начнете понимать, ПОЧЕМУ последнее не работало. Примерно в это время я начал осознавать, насколько велика картина вещей, и по-настоящему понимать, ПОЧЕМУ все работает именно так, как работает. Я чувствовал себя идиотом, возвращался назад и рефакторил код, который написал ранее, делая его более эффективным. И в какой-то момент я достиг стадии, когда все начало становиться на свои места.

Недели 9 — 12

Я был в режиме невероятной энергичности, дорабатывая Freelancify до стадии запуска. На этой стадии я чувствовал себя так, словно лечу, претворяя функции в жизнь. Последняя неделя была потрачена на отладку различных багов и ляпов. В этот понедельник я запустил сайт. Но я по-прежнему далек от завершения обучения… Вот так. Я опустил (во имя краткости поста) мелкие детали и технические моменты. Тем не менее, не стесняйтесь задавать вопросы в комментариях, я определенно постараюсь ответить. Джеймс Фенд.

P.S. — Несмотря на то, что мне сильно помогла помощь наставника, с которым я мог встречаться, вы определенно можете изучить Rails и без него. Или же попробуйте найти себе такого человека, многие Rails-разработчики любят вносить свой вклад в сообщество. Поищите локальные конференции и встречи.

Этой записи уже более двух лет (опубликована 27 января 2012-го года), но она, тем не менее, не утратила своей актуальности. Джеймс Фенд за это время успел продать Freelancify и вложиться в новый стартап, запись об этом он оставил 27 февраля 2013. Я считаю, что эта статья — прекрасный пример того, как человек может идти к поставленной цели. Достаточно лишь начать. 🙂

steptosleep.ru

No related posts.