22 мая 2013 в 20:06

Ruby on Rails. Установка, настройка, начало работы tutorial

Зачем.


В этой маленькой статье, которую с удовольствием прочитал бы сам неделю назад, я попытался собрать все вещи, которые понадобились бы человеку, задумай он «с нуля» написать приложение на RoR. То есть не углубляясь ни в одну из областей, описать необходимый минимум действий, чтобы установить, настроить и написать своё первое приложение.Здесь собрано, как мне кажется, всё, что нужно и я надеюсь этот текст сэкономит кому-нибудь несколько часов поиска в интернете). Сам изучаю RoR вторую неделю, так что не судите строго).

Установка.


Просто и быстро ror ставится через rvm c rvm.io.

>\curl -L https://get.rvm.io | bash -s stable --rails --autolibs=enabled


Запустить rvm:

>source /Путь_к_домашней_директории*/.rvm/scripts/rvm

*$HOME в дальнейшем.
После этого в $HOME/.bash_profile должна появиться строчка:

[[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm" # Load RVM into a shell session *as a function*


и при каждом открытии консоли rvm будет подгружаться, но у меня этого не случилось — пришлось ещё в $HOME/bashrc прописывать:

. ~/.bash_profile


Теперь всё точно должно быть хорошо.
Устанавливаем нужную(скорее всего это будет самая последняя) версию руби (сколько их и в чём отличие можно посмотреть здесь -http://www.ruby-lang.org).
>rvm install 1.9.3

Проверка на успешность создания
>ruby -v

должна вернуть более подробную информацию, вроде
ruby 1.9.2p320 (2012-04-20 revision 35421) [x86_64-linux].

В процессе установки я случайно установил несколько версий, что потом доставило некоторые неприятности). Посмотреть список установленных версий руби можно так:
>rvm list
Если версий несколько, то текущая будет помечена "=>", дефолтная — "*", а текущая и дефолтная — "=*". Поменять на нужную используемую версию можно так:
>rvm use ruby-1.9.2-p320 (любая нужная версия)

Чтобы поменять дефолтную версию руби пишем:
>rvm use ruby-1.9.2-p320 --default



Создание проекта.


Теперь можно перейти непосредственно к созданию проекта. Создаём папку $HOME/ROR/tickets, заходим в неё и делаем следующее.
>sudo gem install bundler
>rails new tickets

При создании проекта будут сгенерированы все необходимые директории(app,config,db,log и т.п.) и конфигурационные файлы в указанной папке. Для работы небольшого тестового проекта нам потребуется, в моём случае, база данных PostgreSQL, пара gem-ов(библиотек) и запущенный rails сервер).
Для запуска сервера нужно, находясь в корне папки с созданным проектом запустить команду:
>rails s -p 3000

где s — команда запуска сервера(server), а -p 3000 -номер порта(port), по которому будет доступен проект. Что бы запустить консоль, нужно набрать:
>rails c

где с- сокращение от console
Список всех команд можно посмотреть, набрав
>rails --h. Теперь по адресу localhost:3000 мы увидем стартовую страницу проекта. Так же можно запускать любое количество серверов других проектов на других, не занятых портах. В ходе работы. у меня в один момент по какой-то неведомой мне причине возникла проблема с запуском сервера — выдавалась ошибка, что сервер уже запущен — для её решения нужно просто удалить файл $HOME/ROR/tickets/config/tmp/pids/server.pid и запустить сервер ещё раз.

База данных.


Чтобы работать с постгресом, добавляем в конец файла Gemfile, который должен находится в корне проекта, строчку
>gem 'pg'
сохраняем файл и делаем
>bundle install

его мы делаем каждый раз, когда вносим изменения в Gemfile, а потом ещё и перезапускаем сервер. Чтобы сюда больше не возвращаться, сразу же добавляем и
>gem 'haml-rails' для быстрой и удобной(после того как привыкнешь)) разметки шаблонов-представлений. Теперь отредактируем атрибуты конекта к постгресу в файле database.yml. Он находится в папке $HOME/ROR/tickets/config/ и должен будет содержать такой блок:
development:
  host: localhost
  adapter: postgresql
  encoding: unicode
  database: tickets
  pool: 5
  username: tickets

с нужными пользователем и именем БД, у меня это tickets и tickets соответственно).

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

Модель.


Создаём модель:
>rails g model user

где g- сокращение от generate
Название модели пишем в единственном числе — таблица в бд будет во множественном. Эта команда создаст файлы модели и миграции в $HOME/ROR/tickets/app/models/user.rb и $HOME/ROR/tickets/app/db/migrate/20130425081208_create_users.rb. все файлы контроллеров и моделей имеют расширение .rb, представлений — .html.haml(в нашем случае использования haml). Посредством миграции мы будем управлять работой с таблицами в БД через консоль, что весьма удобно(опять таки, когда привыкаешь), так же ониобеспечивают простоту переноса приложения, на другой сервер, например. Добавляем нужные поля:

class CreateUsers < ActiveRecord::Migration
  def up
    create_table :users do |t|
      t.string :name, null: false
      t.boolean :role, null: false, default: false
      t.datetime :reg_date
      t.timestamps
    end
  end
  
  def down
     drop_table :users
  end

end


Создаём два метода — up и down, которые используются по умолчанию функциями работы с миграциями — они, соответственно, создают и удаляют нашу таблицу. Названия типы данных будут зависеть от используемой БД. Первичный ключ создаётся по умолчанию и будет называться id, но его можно задать и явно:
create_table :users, :primary_key => :users_id do |t|

А если мы не хотим создавать первмчный ключ вообще, пишем так:
create_table :users, :id => false do |t|

Сохраняем и пишем в консоле:
>rake db:migrate

В результате действия этой команды выполняются все невыполненные методы up из файлов миграций в директории $HOME/ROR/tickets/app/db/migrate/. Все сведения о состоянии таблиц можно посмотреть в файле $HOME/ROR/tickets/app/db/shema.rb.
>rake db:rollback

Запускает метод down последней выполненной миграции, в результате чего таблица удаляется из БД. Чтобы откатить больше миграций, нужно добавить к команде rollback параметр STEP:
>rake db:rollback STEP=3

эта команда откатит три последние миграции. Посмотреть статус всех миграций в консоли:
>rake db:migrate:status

Если нужно запустить какой-то определённый метод из определённой миграции, то добавляем параметр VERSION:
>rake db:migrate:up VERSION=000001

В файле модели ($HOME/ROR/tickets/app/models/user.rb) нам пока нужно сделать только одно — определить поля таблицы, которые будут доступны для изменения из контроллера, в целях безопасности, как я понимаю). Для этого пишем в нём следующее:

class User < ActiveRecord::Base

   attr_accessible :name, :role

end


Кстати, синтаксис haml очень чувствителен к табуляциям — их очень хорошо можно отслеживать в редакторе, которым пользуюсь я — Sublime Text.

Пока приложение не работает, для того, чтобы удостовериться, что все созданные таблицы действительно созданы и функционируют как им и положено, можно воспользоваться раилс консолью:
>user = User.new(name:"Test",role:"true")

эта команда не сделает запись в таблицу, но создаст объект руюи в памяти со всеми установленными атрибутами. А теперь сделаем запись:
>user.save

в случае успеха должна вернуть true. Запись можно создать и одной командой — create:
>User.create(name:"Test",role:"true")

Чтобы проверить есть ли объект в БД, можно использовать find:
>User.find(1)

вернёт объект или ошибку: «ActiveRecord::RecordNotFound: Couldn't find User with id=1», а так же и сам сгенерированный sql-запрос к БД.
Искать можно и по конкретным полям:
>User.find_by_name("Test")

Ещё несколько удобных методов, которые наверняка пригодятся на первых порах:
>User.first и User.last -вернут первую и последнюю запись в таблице соответственно, а User.all вернёт массив всех объектов таблицы.

Контроллер.


Создаём контроллер:
>rails g controller users

В результате этой команды будут созданы файл контроллера: $HOME/ROR/tickets/app/controllers/users_controller.rb и директория для представлений:
$HOME/ROR/tickets/app/views/users/. Каждому методу котроллера будет соответствовать представление с таким же названием, в этой папке. Их можно создавать вручную, а можно и сразу при создании контроллера:
>rails g controller users index,list

В этом случае файлы представлений создадутся автоматически в папке $HOME/ROR/tickets/app/views/users/ и будут называться (если вы не забыли подключить haml) index.html.haml и list.html.haml. Удалить контроллер можно так:
>rails d controller users

где d- сокращение от destroy
Определять метод index, который создаётся по умолчанию, не обязательно. Содержимое нашего контроллера users будет таким:

class UsersController < ApplicationController
  def list
     @users_list=User.all
     
  end

end


В users_list будет массив объектов пользователей, которых мы по идее уже понадобавляли из консоли, а "@" означает, что переменная будет передана в шаблон.

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


Теперь создаёи представление, я просто создал этот файл руками в нужной директории:
$HOME/ROR/tickets/app/views/users/list.html.haml
Документацию по HAML можно почитать здесь (http://haml.info/tutorial.html), а пока набо понадобится минимум знаний о нём, например то, что вместо открывающего и закрывающего тега в нём используется "%tag". То есть после рендеринга шаблона, содержащего %html, мы получим страницу с
<html></html>
. Уровень вложенности задаётся табуляцией, атрибуты тегов пишутся «хешеобразно» в фигурных скобках:
 %td{colspan=>"2"}
превратится в
<td colspan="2"></td>
, а содержимое — через пробел: %td test. Таким образом содержимое нашего представления:

%table{:border=>"1"}
	%tr
		%td Логин
		%td Администратор
	- @users_list.each do |users|
		%tr
			%td= users.name
			%td
				%input{:type=>"checkbox",:name=>"role_#{users.id}",:checked=>users.role}
			
				
%br


Дефис — исполняемый код в шаблоне. Здесь мы проходимся по массиву объектов и выводим в цикле его методы — поля name и role и id.

Все представления «оборачиваются» в главный шаблон, который находится в $HOME/ROR/tickets/app/views/layouts/application.html.haml
Удаляем всё, что в нём есть и делаем его максимально простым:

!!!
%html{:lang => "en"}
	%head
		%title Test
	%body
		=yield


Содержимое всех наших сгенерированных шаблонов подставляется вместо =yield. Главное не ошибится с уровнями вложенности, меня это поначалу очень напрягало).

Маршруты.


И остался только один маленький шаг — редактирование файла-конфига маршрутов(url) — routes.rb. Он находится в $HOME/ROR/tickets/config/. В нём описываются все маршруты нашего проекта. Сейчас там будет только две записи:

Tickets::Application.routes.draw do

  root :to => "users#index" 

  #GET Urls
  get "users/list"

end


Это рутовый путь на «главную» страницу(будет показываться содержимое шаблона /users/index.html.haml, даже несмотря на то, что метод index в контроллере не определён) и путь к странице вывода списка пользователей. В случае, если к методу будет пост запрос, он должен будет прописываться так:
post «users/add».
Теперь всё должно работать)
Сергей @dio_bless
карма
8,0
рейтинг 0,0
Самое читаемое Разработка

Комментарии (89)

  • 0
    Чего очень не хватает подобным туториалам — описывается обычно настройка дев-среды, но очень вскользь рассматриваются вопросы настройки продакшена и деплоя на него, а часто вообще не рассматриваются.
    • 0
      Как правило, такие туториалы предназначаются для самого начального уровня, чтобы можно было быстро вовлечь человека. Рассматривать здесь вопросы настройки продакшена совершенно не к месту. К тому же из начала статьи понятно, что текст от новичка к совсем новичку.
      • 0
        Ну, туториалы для PHP подобного уровня часто содержат всё необходимое, чтобы не просто написать приложение и на локалхосте посмотреть, но и миру его показать. Для RoR же в лучшем случае ограничиваются деплоем на Heroku. Думаю отчасти популярность PHP обусловлена и тем, что прошедший подобный туториал может написать простейшее CRUD-приложение не только в учебных целях, но и выложить его на продакшен и использовать в работе, хобби или бизнесе.

        P.S. «продакшен» здесь просто как «паблик», «не дев», «не локалхост» на какой-нибудь вдске за 100 рублей, а не «хайлоад». Понятно что можно на vds всё из статьи сделать (с изменениями типа sudo rails s -p 80 вместо rails s -p 3000, но о недостатках такого подхода вы, наверное, лучше меня знаете, а они могут иметь последствие обратные «вовлечь».
    • 0
      Так вроде всё легко, если использовать nginx + phusion passanger + capistrano + postgresql + jenkins? Особо и писать нечего…
      • +3
        лол. вы серьезно?
        напишите хотя бы почему вы в эту цепочку добавили Jenkins. И почему именно Postgresql? с мускулем работать не будет?
        деплой это тот ещё гемор. Даже с капистранкой. Но когда есть опыт и написанные рецепты деплоить всяко проще и горадо проще чем на PHP.
        • 0
          Абсолютно серьезно. nginx устанавливается одной командой, для минимальной работоспособности дополнительной настройки не требует, passenger устанавливается 4 командами, для минимальной настройки хоста достаточно 5 строчек в конфиге. Capistrano — установка — добавление одной строки в Gemfile, 10 строчек конфига. Постгрес устанавливается 1 командой, создание юзера и бд — еще 2 команды. jenkins — установка — 1 команда, настройка — строчек 5 конфига и пара кликов мышью, позволяет легко содержать стейджинг и продакшн, деплой благодаря нему перестанет быть чем-то страшным и непонятным.

          Итога за полчаса-час можно с нуля руками развернуть работоспособный сервер, с деплоем по гит-хуку или периодическим деплоем, забыть про ад деплоя и всё такое.

          Почему postgres? Потому что с ним работаю. Может быть и мускуль. В любом случае, стоит попрактиковаться проектах на 2-3, и деплой станет простым и безболезненным.
          • –1
            Хорошо быть гуру в песочнице) Это как если бы Павел Дацюк читал лекцию 10-ти летним мальчикам из «Юниора»:
            -Что вы там с азами и теорией маятесь? Взяли клюшку, коньки — и вперёд, в лучшие игроки НХЛ, это же просто, надо только забивать шайбы в ворота, мимо голкипера!)
            • +1
              Да нет, там на самом деле всё достаточно просто. Ну ладно, первый раз это часа 2-4 может занять, так как непривычно. Но вся фишка в том, что документации по настройке всего этого — море, там всё написано простым понятным языком и нету никакой магии (ну если только чуть-чуть, где-нибудь в районе capistrano или jenkins). Ну и делать это всё легче тогда, когда проект еще маленький и не оброс кучей странного хардкода и костылей :)
              • 0
                2-4 часа для разбирания как выложить в паблик «hello world», написанный по туториалу, непозволительно много. Так вот и складывается «высокий порог вхождения». Туториал, претендующий на «простейшее, но полноценное приложение с нуля», по-моему, просто обязан содержать команды для установки всего этого и конфиги, чтобы развернуть приложение можно было копипастой, так же как и написать его. А то получается как в туториале по какому-нибудь компилируемому языку рассказать как скомпилировать «hello world» в объектный файл, но не рассказать как из него сделать исполняемый.
                • 0
                  Специально для таких людей есть heroku. Там всё бесплатно, деплоится — одной командой, автоматически при пуше в гит. Этим вашим php такое и не снилось.
                  • 0
                    Насчет «не снилось» не перегибайте. У меня в проекте тоже деплоится по пушу в гит, если тесты прошли. С помощью capistrano кстати деплоится :) И без всякой зависимости от конкретного хостера.

                    А не использовать heroku может быть много разных причин. От его забугорности до наличествующей вдски с «привязанным» доменом, настройки которого трогать весьма нежелательно.
                    • 0
                      Ну так в heroku это совсем из коробки, без лишних телодвижений :) Вообще, heroku я привел как пример для выкладывания в паблик «hello world», написанного по туториалу. Тем более, беслптаного аккаунта heroku для этого более чем хватит.
                      • 0
                        Я в курсе что такое heroku. Но тоже в свое время пришлось повозиться. например в туториале используется sqlite, на локалхосте всё работает, а там…
          • +2
            Для человека, который не в теме деплоя, но хочет быстренько свой блог разместить в сеть надо не только знать, какие 10 строк прописать в капистрано, но ещё и для начала знать, что для используется nginx, и phusion passenger, чем они отличаются и нужно ставить их по принципу и или или. Даже для человека, который программирует тыщу лет, но никогда не занимался вебом всерьез, такие вещи легко могут оказаться неизвестны.
            • –1
              Мало того, некоторые вещи могут оказаться неизвестными человеку, занимающемуся вебом всерьез давно, но в другой экосистеме. nginx он-то установит, а вот passenger уже может в тупик поставить.
            • 0
              А зачем этому человеку тогда настраивать продакшен вообще? Для него есть уютные appfog, heroku и иже с ними. Продакшн там автоматом работает по пушу в гит. Подробно описано в рельсотуториале.
      • 0
        passenger установить не так просто, не нарушая общей целостности системы. Для туториала бы лучше подошел unicorn. сapistrano ещё куда не шло, но вот Jenkins в этом списке явно лишний.

        Ну и главное — мало всё это установить, нужно ещё и заставить работать в одной связке. Проще говоря нужны примеры конфигов.
        • 0
          Да ладно, что там нарушать? Удаляешь старый nginx, ставишь по мануалу новый. Я даже не представляю, где там можно ошибиться. И гораздо удобнее, чем unicorn, в плане конфигурирования — для добавления rails-хоста ни надо разбираться со всякими fcgi, держать отдельно god/runit/etc для fastcgi сервера, рестарт — одной командой. Что может быть проще?

          Все примеры конфигов уже 100 раз разобраны в документации для описанных мной выше средств.
          • –1
            Обновлять nginx как? Каждый раз пересобирать? Для многих дистров это не православно. Из популярных наверное только гентушникам привычно.

            Ладно бог с ними с обновлениями, но туториал претендует на «всё в одном месте», а значит и процесс установки должен быть и конкретные конфиги. Пускай без пояснений (кроме типа «замените „example.com“ на свой домен) и ссылок, но и без необходимости идти на сторонние ресурсы и, тем более, что-то гуглить (особенно учитывая, что гуглятся часто холивары, что лучше для тех или иных целей, аргументы сторон в которых новичку непонятны).

            • +1
              Хорошая идея, может быть напишу на досуге статью, как я деплою (включая настройку сервера). Может быть, действительно кому-нибудь пригодится.
        • 0
          Ну вот у меня unicorn, и вот меня несколько раздражает, что для того, чтобы поднять ещё одно приложение приходится совершать очень много телодвижений.
          А именно:
          • Скрипт в /etc/init.d/ (хотя тут достаточно написать один раз и создавать симлинк каждый раз)
          • Конфиг nginx — тут приходится всегда заново писать, по крайней мере я не нашёл информацию о том, как их динамически генерировать
          • Конфиг unicorn — также приходится писать каждый раз
          • Конфиг capistrano — также приходится писать каждый раз

          Возможно что-то ещё не учёл. В итоге куча однотипных файлов, похожих друг на друга.
          • –1
            Править больше, да, но работать проще и безопасней, по-моему.
            • 0
              Тут спорить не буду. Сам же использую.

              P.S. На самом деле добавляя комментарий, я надеялся услышать «ты всё делаешь неправильно, достаточно добавить две строчки в ...».
  • +9
    Чем этот туториал отличается от первых 10 страниц любой книжки по рельсам/ овер9000 других таких туториалов?
    Вот про продакшн действительно не мешало бы, хотя и это гуглится на раз.
    • +1
      И мне не понятно. Уже тема интро для рельс давным давно избита. Плюс ко всему описана настройка рельс для семейства GNU/Linux, а проблемы зачастую возникают у тех, кто на винде. Хотя тут настраивается всё в несколько кликов и туториала, собственно, не требует. Я запутался…
      • 0
        Ну, на винде, к слову гораздо меньше проблем с тем, чтобы поднять рельсы — railsinstaller.org/; на все про все пару кликов.
        Вот когда у Вас возникнуть проблемы на винде, так это когда Вам нужно будет собирать гемы — процесс до того временами тяжкий, что даже сильного мужчину заставит плакать.
        В общем, лучше не использовать винду для разработки на руби и для работы с рельсами.
        • 0
          >> Ну, на винде, к слову гораздо меньше проблем с тем, чтобы поднять рельсы — railsinstaller.org/; на все про все пару кликов.
          К слову, с использованием Rails Installer возникали проблемы, поэтому лучше всё делать другим образом. Ставим Ruby Installer, дальше gem install rails, а дальше вручную бандлим и настраиваем окружение вручную. Меньше хлопот приносит, знаете ли.

          >> Вот когда у Вас возникнуть проблемы на винде, так это когда Вам нужно будет собирать гемы — процесс до того временами тяжкий, что даже сильного мужчину заставит плакать.
          А можете указать конкретный юзкейс? У меня просто с этим проблем не возникало.

          >> В общем, лучше не использовать винду для разработки на руби и для работы с рельсами.
          Без обид, но это конечно уж совсем какой-то не корректный вывод, не подкреплённый ничем. Вообще это тема для отдельного спора. Разумеется, когда мы говорим о рельсах и рубях — имеем ввиду GNU/Linux окружение, что называется, by default. Но есть множество людей, которые пишут и деплоят приложения на винде и у них проблем не возникает абсолютно. И я в их числе.
          • 0
            А можете указать конкретный юзкейс? У меня просто с этим проблем не возникало.
            Да установка любого нативного гема, часто превращается в кошмар, тот же json, например, или therubyracer, который вообще не собрать под виндой. В принципе, сборка чего либо по Windows, мне видится гораздо менее тривиальной задачей, чем сборка под Linux.

            Без обид, но это конечно уж совсем какой-то не корректный вывод, не подкреплённый ничем. Вообще это тема для отдельного спора. Разумеется, когда мы говорим о рельсах и рубях — имеем ввиду GNU/Linux окружение, что называется, by default. Но есть множество людей, которые пишут и деплоят приложения на винде и у них проблем не возникает абсолютно. И я в их числе.
            Успешность использования того или иного инструмента зависит во многом от задач, которые Вы решаете с его помощью. Если мне нужен Sidekiq для своего проекта, я не рискну связываться с Windows. Мой комментарий, что для Ruby\Rails разработки лучше использовать Linux означал, что при прочих равных возникнет гораздо меньше проблем связанных с настройкой рабочего окружения и функционированием отдельных его компонент при использовании Linux, а не Windows. Т.е. все, что я могу сделать в Windows я могу сделать и в Linux и скорее всего это будет даже проще, но не все, что я могу сделать в Linux, я могу сделать в Windows. Default, он, знаете ли, не просто так default.
            • 0
              >> Да установка любого нативного гема, часто превращается в кошмар, тот же json, например, или therubyracer, который вообще не собрать под виндой. В принципе, сборка чего либо по Windows, мне видится гораздо менее тривиальной задачей, чем сборка под Linux.
              Native Development Kit же нужно для этого ставить самому. github.com/oneclick/rubyinstaller/wiki/development-kit

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


            Про PHP говорят то же самое. Однако когда надо сделать что-то посложнее шаблонного проекта на пару сотен человекочасов, начинаются проблемы.
  • 0
    Генератор Rails давно уже генерирует другие миграции с одним change методом. Незачем генерировать отдельно модель и контроллер, есть
    rails g scaffold
  • +1
    Имхо после такого туториала у меня отпало бы желание изучать что такое руби он рейлс. Зачем такой туториал нужен я не понимаю, разве что отпугнуть людей.
    • +1
      Я тоже вторую неделю изучаю RoR. Книга на подобии той которую можно скачать тут rusrails.ru/ на много лучше в своих первых главах чем такой туториал.
      • –1
        Конечно лучше, тоже читаю. Но для написания такой книги нужны недели. И месяцы практики. Я сделал выжимку из проблем, с которыми столкнулся в самом начале. С удовольствием прочитаю Вашу статью на данную тему.
        • +1
          Там 25 страниц первых после прочтения которых стает понятно что рейлс именно то что ты искал если ты очень ленивый:) А здесь просто ужасная тягомотина всякие непонятные команды для начинающего, когда все норм люди привыкли кликать некст некст некст под вендой.
      • 0
        и плюс скринкасты www.youtube.com/feed/UCPIyDzf1vwWc8EQJGUX-vYw
      • 0
        Спасибо за комплимент в адрес rusrails :)

        Не думал, что скачиваемый pdf популярен, немного пристыдился, на сайте гораздо свежее переводы… Нужно бы сверстать pdf поновее :)
        • +1
          Очень полезный ресурс, несомненно! Если это Ваше творение, тогда ОГРОМНОЕ СПАСИБО! Очень помогает! Особенно, когда начинаешь изучать RoR. У меня www.rusrails.ru/ всегда открыт на одной из вкладок.
  • 0
    Вам не кажеться что это уже заезженная тема?

    Ну а это вообще вершина:
    source /Путь_к_домашней_директории*/.rvm/scripts/rvm
    особенно когда потом пишете
    . ~/.bash_profile
    • –2
      Всегда полезно и интересно выслушать мнение умных людей) Спасибо за Ваш пост.
  • +1
    Я понимаю, что пост нацелен на то, чтобы помочь поднять рельсы людям, которые не рискнули немного поднапрячься и погуглить или заглянуть в pick axe. И возможно это дело благое, все-таки все по разному обучаются, и не мне судить. Но упрощая, не создавайте дополнительный хаос высказываниями вроде
    "@" означает, что переменная будет передана в шаблон.
    не стоит забывать, что мы все-таки не на рельсах программируем, а на руби.
    • 0
      Да жесть, полная жесть там в статье.
      Вот это например: «Кстати, синтаксис языка очень чувствителен к табуляциям — их очень хорошо можно отслеживать в редакторе, которым пользуюсь я — sublime_text» — что это вообще такое? Речь о Python'e может быть идет??
      Action'ы в контроллерах сразу преподносятся не в rest'овом стиле, зачем делать index, если можно сделать list. Офигеть. RVM без гемсетов, зачем его ставить тогда. Мое личное мнение такие статьи нужно писать когда уже давно ориентируешься в теме, когда есть опыт и действительно можешь дать совет новчикам. А это полная жесть.
      • 0
        Писать нужно сразу, но только в паблик не выкладывать сразу, а или перечитать месяцев через N, или дать на рецензию кому-то более опытному. Если писать не сразу, то многие вещи будешь считать уже очевидными и забудешь упомянуть, а новички на них споткнуться.
        • 0
          Да, теперь согласен, что надо было подождать и не выкладывать сразу, но мне действительно казалось, что что-то из написанного можетпомочь кому-то прямо сейчас… в том числе и мне — разложить по полочкам пройденное)
      • 0
        Речь идет о HAML
  • –2
    Пфф, зачем создавать отдельно модель, отдельно миграции, отдельно контроллер?

    rails g scaffold users name:string role:boolean
    


    и стандартная CRUD-логика уже создана за нас.
    • –2
      И многое Вы сможете с этой стандартной CRUD-логикой? Все-равно придется практически все переделывать, если это хоть немного серьезный проект, а не учебный пример.
      • 0
        Ну вообще-то да, многое. И переделывать придётся намного меньше, чем писать с нуля.
        • –2
          Уже имею опыт разработки на RoR, и пользовался scaffold только в самом начале… совершенно не впечатлило использование «строительных лесов». Хотя спорить не буду — это очень удобный механизм для построения каркаса приложения.

          Но тем не менее, можно подробнее о «Ну вообще-то да, многое.». Например? Кроме того, что за вас построен каркас приложения с минимальной функциональностью?
          • 0
            Тоже имею опыт, поэтому пользуюсь скаффолдами в каждом новом проекте и имею каркас уже через полчаса-час после начала работы. Когда архитектура базы достаточно громоздкая — создавать отдельно модели и контроллеры со стандартной логикой очень долго и нудно. Я не буду говорить за всех, но мне удобнее добавлять свою логику к уже сгенерированной, чем писать для каждой модели одно и то же.
            • –2
              Просто ради интереса. Достаточно громоздкая архитектура базы — это какая по Вашему мнению? На каждый чих отдельная модель с контроллером? Уж не из тех ли Вы, кто полагает, что «на каждую „сущность“ — отдельный класс»?
              • +2
                Вы так говорите, как будто это что-то плохое «на каждую „сущность“ — отдельный класс». Контроллер на каждый «чих» не обязателен, но вот модель, имхо, да. Исключение разве что, когда возникает необходимость в оптимизации, и тогда проводишь «денормализацию», делая, например, user.profile_address_city_name вместо user.priofle.address.city.name, порождая классы с десятками, а то и сотнями полей, логически друг с другом слабо связанными.
                • –2
                  Хммм… все ясно.
                  Тогда Вам точно без скаффолдов никак.
                  Вопросов более не имею.
                  • +2
                    Надеялся на более конструктивный разговор. По вашему тону похоже, что я заблуждаюсь в чем-то, но вот в чем вы не говорите.
                    • –2
                      Почему-то мне кажется, что Вы — фанатик ООП, так показалось. А я избегаю ООП-фанатизма. Поэтому и свел тему на нет.
                      Вполне возможно, что мне просто показалось.
                      • +2
                        Да нет, не фанатик. Скорее я фанатик мультипарадигменных языков, которые мне позволяют выбирать ту парадигму, которую я считаю более уместной в данном контексте, а не искусственно меня загоняют в рамки какой-то конкретной, будь-то ООП, ФП, ПП или ещё какое *П. Правда, очень часто при решении конкретных задач я выбираю именно ООП парадигму за основу или к ней перехожу в процессе. По крайней мере в части приложения, касающейся бизнес-логики — как-то так получается, что чаще всего приходится моделировать объекты реального (или вымышленного) мира со своими свойствами и поведением в рамках грамматики «субъект как-то действует на объект», а не «два объекта на равных взаимодействуют».
                        • –2
                          Тогда все же, какую архитектуру БД Вы считаете громоздкой? Я так и не получил ответа…
                          • +2
                            Я предпочитаю слова «архитектура модели». Но в целом считаю громоздкой, если в одной сущности (таблице) содержится больше 5-7, край — 10 свойств (столбцов). А это обычно означает, что нужно вводить много небольших классов и описывать связи междуними, даже если это строгие 1:1 связи. Ладно ьописать сами свойства, но вот отдельную синтаксическую обвязку для каждой группы свойств…
                            • –2
                              Нет, все же мои предположения подтверждаются, как ни крути… Вы, конечно же, будете возражать и приведете множество доводов в свою пользу. Я даже спорить не буду. Дело Ваше — плодите классы пачками, пока не столкнетесь с поистине сложным проектом, в котором просто начнете путаться в этом зоопарке объектов и классов, и даже скаффолд будет не в помощь.

                              Довольно показательна на эту тему шуточная статья:
                              inet777.ru/skladyivaem-chisla-v-oop-stile/8660

                              Я не против ООП, не против скаффолда, но все должно быть разумно и в меру.

                              Удачи Вам!
                            • –2
                              … да, еще вдогонку… так, к слову…
                              вместо того, чтобы использовать спокойно 10-20-… свойств в одной модели, что ничем страшным не грозит, Вы предпочтете поделить это все… не понятно для чего и почему, но тем не менее… А вот это бессмысленное деление просто ради отдельных сущностей, классов приводит к увеличению нагрузки как на сервер БД, так и на само приложение. Так, просто к сведению. Или тормоза ради ООП — это оправдано?
                              Советую почитать книги по ООП-проектированию. Кстати, ни в одной из них не читал о том, чтобы класс делили на несколько только потому, что якобы перебор с количеством свойств получился. Все же классы определяются по иным принципам.
                              • +2
                                Я делю не просто количественно, а логически. В книгах по проектированию это называется «декомпозиция» (процесс очень похож на нормализацию РБД). Иногда ну никак не избавиться от пары десятков свойств — в смысле никак их не сгруппировать логически. А что до нагрузки — когда будут тормоза, тогда и буду решать, а так мне проще оперировать кучей небольших классов, как правило разделенных на несколько уровней, чем одним большим суперклассом.
                                • –2
                                  «Но в целом считаю громоздкой, если в одной сущности (таблице) содержится больше 5-7, край — 10 свойств (столбцов). А это обычно означает, что нужно вводить много небольших классов и описывать связи междуними, даже если это строгие 1:1 связи. „

                                  как-то не вяжется с

                                  “Я делю не просто количественно, а логически.»

                                  так все-таки что играет роль — логика или количество столбцов?
                                  Вы уже начинаете противоречить сами себе.

                                  В общем-то я уже закончил диалог. Мне не интересны беседы с ООП-фанатами.
                                  Всего хорошего!

                                  (кстати, о минусах… видимо, у Вас товарищ есть, который Вас поддерживал на рабочей неделе (-2 в каждом моем посте, и соответственно +2 — в каждом Вашем), а сегодня Вы в одиночку трудитесь (-1 — +1) — очевидная тенденция. Не утруждайтесь, меня минуса не пугают.)

                                  • +2
                                    Вот смотрю я на некоторые таблицы, вижу, что они громоздкие, но ничего не могу с этим сделать (кроме как разделить чисто количественно, без всякой логики) — я и не делаю. Но если вижу в таблице, например, user 50 столбцов, которые можно сгруппировать по признакам типа аутентификационные данные, адрес, контактные данные, статистика, рейтинги и т. п., то я их группирую (переношу в отдельные таблицы). Хотя бы чтобы просто в IDE в автодополнении после точки не появлялся список на 50 полей, а только 5-7.

                                    Насчёт минусов — это вы мимо. Не ко мне.
                                    • 0
                                      Какая, однако, оживлённая дискуссия)
                                  • 0
                                    Мы живем в объективном мире. Объект, как философская категория зародился, тысячилетия назад. ООП как парадигма насчитывает 15-20 лет? Разработка любого приложения по сути проекция взаимодействия объектов. В какой парадигме ее реализовать — дело каждого конкретного разработчика.
                                    Удивляюсь почему ООП выделятся Вами в парадигму достойную отчуждения. Тем более, в хабе где среда разработки подразумевает, что вообще все объект. Вас минусуют за свои уставы в отдельно взятом, и видимо чужом для Вас, монастыре.
                                    И уж никто из адекватных специалистов не усомнится, что процедурное программирование, например, это круто! И тем более ругать функциональное программирование за «чтобытонибыло».
                                    • 0
                                      Знаете, я не против ООП, я ООП сам с успехом использую. Не нужно говорить, что я типа в чужом монастыре. Если бы Вы читали внимательно диалоги и старались понять, то пришло бы понимание того, что я против фанатизма в ООП — когда любую мелочь стараются сделать объектом. ООП призвано облегчить разработку, его использование должно быть целесообразным и уместным, но почему-то некоторые считают, что если уж ООП, то «ээээххх! щас прокачу» — кучу объектов наворочу!

                                      Давайте простой пример. Запись о человеке — вот то, что можно смело реализовать в виде объекта с конкретными свойствами: фамилия, имя, отчество, пол, возраст, место рождения, адрес проживания, место работы и т.п.

                                      А вот тот же пример на фанатичном ООП уровне. Имя человека — объект со свойствами: фамилия, имя и отчество. Возраст — объект типа число. Пол — тоже отдельный объект. Адрес проживания, место проживания — два разных объекта класса Адрес, место работы — тоже отдельный объект. Все они, естественно, связаны между собой, потом сверху приправлены интерфейсом и, возможно, не одним, различными proxy, декораторами, фабриками и т.п.

                                      Чувствуете разницу?

                                      Прежде чем возражать, желательно бы все-таки постараться понять, против чего я тут высказываюсь.
                                      • 0
                                        Эмм. Ну я на своем веке встречал не одно приложение, где адрес, вуз и место работы объекты, а не просто строчные поля в базе :)
                                        Если это одна тупая запись с которой не нужно работать, то бог с ней. Везьде есть мера.
                                        В остальный случаях — денормальизация. Т.е. если вы не взаимодействуете со свойством сложнее чем вывод значения на экран, то заводить ради этого десятки свойств — плохой тон, 100500 лет назад для этого придумана сериализация.
                                        А что вы имели в виду, мне так и не ясно. Возможно это не моя проблема.
                                        Начали со скафолдов закончили за упокой.
                                        • 0
                                          > А что вы имели в виду, мне так и не ясно. Возможно это не моя проблема.

                                          Ну если уже и после последнего ответа не поняли, тут уже вообще ничем не могу помочь, извиняйте.

                                          > Начали со скафолдов закончили за упокой.

                                          Отвечал на возникшие вдруг возражения, только лишь.

                                          Еще вопросы будут? Или все-равно вы меня не понимаете, то смысл?
                                          • 0
                                            Если в системе много объектов у которых есть свойство «город проживания», и с городами нужно работать то город резко становится объектом со своими счетчиками и связями со странами и регионами.
                                            Если фейсбук группирует по местам работы пользователей, то место работы резко становится объектом.
                                            А из имени объект класса имя никто делать не будет, такую идиотию никто не прелагал.
                                            • 0
                                              > такую идиотию никто не прелагал.

                                              Хорошо, если Вы это понимаете.

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

                                              «Я предпочитаю слова «архитектура модели». Но в целом считаю громоздкой, если в одной сущности (таблице) содержится больше 5-7, край — 10 свойств (столбцов). А это обычно означает, что нужно вводить много небольших классов и описывать связи междуними, даже если это строгие 1:1 связи. „

                                              “Но если вижу в таблице, например, user 50 столбцов, которые можно сгруппировать по признакам типа аутентификационные данные, адрес, контактные данные, статистика, рейтинги и т. п., то я их группирую (переношу в отдельные таблицы). Хотя бы чтобы просто в IDE в автодополнении после точки не появлялся список на 50 полей, а только 5-7.»

                                              Что это? Это ООП? Когда человек пилит на несколько объектов со связями 1:1 только потому, что его напугало большое количество полей. Это бред!

                                              • 0
                                                Началось все с CRUD. CRUD для рельсовика это как grep для юниксойда. И да, все можно сделать CRUD-ом. Это необходимые и достаточные операции над объектом, как раз чтобы сущности не плодить :)

                                                Потом началось группирование объектов по признакам, «которые можно сгруппировать по признакам» — связь 1 ко многим, или разместить в этом же объекте в своих группах.
                                                Это удобство разработки, а вовсе не бред. Невозможно вычленить глазами все свойства объекта, особенно если их 50. А если дебаг? Сколько строк на экране займет объект с 50-ю свойствами. Да это нужно попилить в 1:1 лишь бы довести проект до рабочего конца. А джоин одного объекта по индексу погоду не сделает :) Да и не бывает такого, обычно столько свойств хранить не нужно. Самое длинние что я видел на своей практике — характеристики автомобиля — но хранить их в одной записи в виде 50-ти полей — полный бред.

                                                Предложите по-настоящему сложный объект у которого 50 полей и с этим ничего нельзя сделать?
                                                • 0
                                                  > Предложите по-настоящему сложный объект у которого 50 полей и с этим ничего нельзя сделать?

                                                  По-настоящему разумное решение — это не делать с объектом ничего, если в этом нет никакой необходимости, когда не появляются удобные связи 1:n, когда нет деления на общее и частное. В том-то и дело, что не нужно пытаться обязательно что-то сделать. Ну 50 полей… и что? Что из этого? ООП ради ООП?

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

                                                  Фрейд: «Есть только намерение — помнить или забыть».

                                                  Так вот у вас намерение во что бы то ни было опровергнуть.
                                                  • 0
                                                    Без ООП можно провести декомпозицию. Не должно быть 50 полей.

                                                    Что плохого намерении, как таковом, что Вы отвели ему столько места в своем рассуждении?
                                        • 0
                                          > Ну я на своем веке встречал не одно приложение, где адрес, вуз и место работы объекты, а не просто строчные поля в базе.

                                          Согласен, имеет смысл сделать объектами, но только в том случае, если будут использованы связи 1:n, т.е. есть всего несколько вузов и определенные предприятия.

                                          Опять же, все дело во внимательном прочтении и Вашем намерении либо понять, либо изначально опровергнуть.
                                          Сделаю акцент: «Адрес проживания, место рождения — два разных объекта класса Адрес», чтобы конкретно Вам было понятнее.
                                          • 0
                                            Сделаю акцент: «Адрес проживания, место рождения — два разных объекта класса Адрес», чтобы конкретно Вам было понятнее.

                                            Вы издеваетесь?
                                            • 0
                                              > Вы издеваетесь?

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

                                              > Вас минусуют за свои уставы в отдельно взятом, и видимо чужом для Вас, монастыре.

                                              У многих срабатывает стадное чувство на заминусованные посты. Один небуч минусанул, другой поддержал. И тут же возникает чувство общности, желание принадлежности к правильному мнению. Отсюда и ответы явной направленности — опровергнуть.

                                              Кстати, минусы в мой адрес — совершенно мимо, никоим образом не расстраивает даже.

                                              Я не буду с вами спорить, мне это неинтересно.

                                              Удачи Вам!
                                            • 0
                                              Кстати, ваше наигранное непонимание не прибавляет Вам и Вашим высказываниям значимости и не характеризует Вас как более грамотного, чем Ваш собеседник. Ошибочный прием в разговоре — изображать искреннее непонимание и недоумение. Конечно, ЧСВ от этого у Вас явно повышается, не более того.
                                              Непонимание — это… ну сами понимаете, надеюсь.
                                              • 0
                                                С одной стороны это адреса разных событий, значит вы издеваетесь, мол я не могу понять, чо это экземпляры одного класса.
                                                С другой стороны адрес проживания длинный с индексом, городом, страной, улицами и домом, который, на почте например, нужен в развернутом виде, а место рождения всеголишь страна и город, причем можно через запятую, т.к. место рождения не несет никакого смысла, даже юридического. Тогда это как понимать?
                                                Я правильно не понимаю?

                                                А на личности переходить ну уж совсем не этично.
                                                • 0
                                                  Это был гипотетический пример с явными преувеличениям, чтобы показать сущность фанатизма в ООП. Нет же, вы давай отстаивать именно эту позицию. Пора бы призадуматься Вам… видимо, не все так хорошо Датском Королевстве.

                                                  И еще раз — покаааа! Удачи Вам! Всего хорошего!
                                                  На сим позвольте откланяться.
                                    • 0
                                      опечатка:
                                      вместо: «Адрес проживания, место проживания — ...»
                                      следует читать: «Адрес проживания, место рождения — ...»

                                      не успел поправить, пока возможность была… на хабре это время ограничено
  • НЛО прилетело и опубликовало эту надпись здесь
  • +6
    Написано небрежно, с туевой хучей опечаток.
    Команды rails в сокращённом виде. Новичкам, для которых вы написали статью, хорошо бы объяснить, что «d» — это «destroy», «g» — «generate» и так далее.
    «sublime_text» это переменная руби что ли? Видно, что вы торопились или скопировали из своего личного блокнотика и добавили текста, раз название редактора написали хер знает как.

    Документацию по HAML можно почитать здесь

    Где здесь? Ссылки нет.

    Ждём от вас статью «учимся программировать микроконтроллеры на ассемблере за 10 минут».

    Для новичков есть замечательнейший учебник: railstutorial.ru. Первые две главы оттуда намного наглядней, легче и интересней объяснят то же самое, что и в этом недопосте.
    • 0
      Согласен. Пост вообще ниачем! Такой пост только отпугнет от Рельсов.
      Сам начать изучать RoR со знакомства с railstutorial.ru — очень неплохо все описано, по шагам. Только новичкам посоветую смело пропускать всю информацию, касающуюся тестирования. Поверьте мне, информация о построении тестов только мешает первоначальному восприятию нового материала, а пропустив ее вы ничего не потеряете. Я понимаю, что автор как бы сразу пытается показать хороший тон программирования, но для такого туториала — это лишнее.

      Вот как я начинал:
      inet777.ru/izuchenie-ruby-i-ruby-on-rails/8470
    • 0
      Переписывал действительно из записей, которые накидывал по ходу… Мне казалось, что написано более-менее гладко, но неудачный опыт написания статьи такого плана тоже опыт. Все неточности и ошибки устраню по мере сил.
      До ассемблера надеюсь не дойдёт в ближайшем будущем)
  • 0
    В этой маленькой статье, которую с удовольствием прочитал бы сам неделю назад...

    Обычно с таких слов начинаются статьи, полные ереси и вредных советов. Вы неделю назад начали изучать рельсы, ну куда вы ломитесь писать статьи для новичков? Разберитесь сначала хоть немного в основах.
    • 0
      Если честно, статья задумывалась не для новичков, которым я сам являюсь, а для тех, кто вообще рельсов ни разу в глаза не видел, с целью облегчить возможно их мучения, но, как я уже понял, задумка не особо удалась) + это помогает устаканить у себя в голове новые знания
  • 0
    так как статья написана совсем начинающим для таких же начинающих, было бы правильным добавить в каких именно проектах стоит использовать RoR и в каких случаях он просто избыточен. Честно говоря ожидал это увидеть в разделе «Зачем» но там ничего про это не сказано. П.С. Тоже начинающий как и вы :)
    • 0
      RoR избыточен для «Hello, World!», для всех остальных веб-приложений — в самый раз!
    • 0
      В разделе «Зачем» я попытался объяснить зачем я всё это написал)
      Я думаю, он избыточен если только для написания сайта-визитки или персонального блога.
      Сам изучаю ввиду того, что в ближайшем будущем буду заниматься поддержкой проекта, написанного именно на RoR.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.