Viktor Vsk

Public - должны использоваться очень аккуратно. Чем меньше - тем лучше. Это внешнее API для других классов, которые будут его использовать. А чем меньше можно узнать, тем быстрее это можно выучить и запомнить, тем меньше ошибок сделать.

Protected - это те методы, которые доступны потомкам (классам, что наследуют), но не доступны внешним классам. Грубо говоря, удобно, когда вы знаете, что от класса А будут наследовать много-много разных классов, и у этих классов будет один (или много, не важно) общий метод. Который, однако, совершенно не нужен внешним классам. Если бы не было протектеда, было бы 2 пути - сделать метод, который должен быть у всех потомков - публичным. Это плохо, потому что это лишняя информация для внешних классов. Или же - дублировать одинаковые методы в каждом классе потомке. Это плохо, потому что не DRY.

Private - это те методы, который доступны только классу. То есть, грубо говоря, пользоваться ими вы можете только в том же файле, где идет определение класса. Например, удобно ими пользоваться для рефакторинга. Представим, что есть публичный метод, который уже много лет используют 100 разных, неизвестных классов. Но в этом методе - 500 строк. Менять метод нельзя, поэтому вы превращаете его в 10 строк-вызовов приватных методов.

Лучше всего это усвоить, создав разные вариации и попробовав повызывать разные методы. 2 важных вещи, которые нужно помнить в Ruby:
1) Разные ключевые слова для методов класса и экземпляра (private, private_class_method)
2) Если тестируете поведение в консоли с использованием #send, то поведение будет не ООП-шное - #send игнорирует видимость методов

С self все проще. По умолчанию, всегда self подставляется. Метод вызывается сначала для текущего объекта - потом смотрится наличие методов в предке и т.д. и т.д. до объекта Object. Зачем иногда явно пишут self ? Потому что в руби можно создавать методы вида def method=() end; и использовать их с пробелом: method = 2. Для этого, что бы дать понять, что используется именно метод, а не определяется локальная переменная, иногда прибегают к полной записи.

P.S. Если что-то действительно не понятно даже здесь - берите любую книгу по ООП или википедию и пробуйте все в консоли на любом языке программирования, пока не уловите суть.

Если это типичный небольшой интернет-магазин, то сначала нужно

Надо нарисовать всю структуру сайта на бумажках

Потом, хорошо бы, все-таки продумать ТЗ, так как очень много всего вы 100% не учли, а дизайнер не должен быть гуру екоммерса, что бы на все это указать. Далее, если то, что вы нарисовали на бумажках, до сих пор похоже на какой-то аналог (что, на самом деле врядли, если вы действительно ответственно подошли к рисованию на бумажках), то дальше

Надо просто сказать: я хочу интернет-магазин похожий на...

После чего пообщаться с дизайнером и

он должен сам что-то состряпать

и так в несколько итераций. К сожалению, число итераций - очень индивидуальный вопрос, зависящий от огромного множества факторов. Некоторые говорят, что нужно в любом случае забраковать 1 (2, 3, 4) первых варианта, "что бы дизайнер постарался". В 90% случаев - это чушь.

" Если работа совершенно не нравиться(халтура, совершенно не то что хотел) до каких пор стоит "насиловать ему мозг"?"

Такого быть не должно. Если так случилось, то вся вина на заказчике, т.к. не смог определить то, что ему нужно (скорее всего, в типичных проектах, из-за того, что искал быстрее и дешевле)
Вообще, этот вопрос решается почасовой оплатой - и насилуйте сколько угодно. Заплатить же оговоренную сумму нужно в любом случае. Вы же не говорите таксисту, что он сильно много кочек собрал по пути, поэтому заплатите 50% ?

Быть заказчиком - это тоже ответственная позиция. Заказчик должен хорошо разбираться не только в предметной области (продавать в магазине), но и понимать, что такое дизайн, что возможно, что нет (если заказывает дизайн, конечно же). Вот поэтому часто этап "заказа" и поручают специалистам (менеджерам, аналитикам ...)

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

Не удалять, а помечать удаленным

Если нет никаких ошибок, значит, все прошло нормально. Отсутствие текста говорит о том, что нечего там мигрировать.
Проверить можно с помощью
rake db:migrate:status
Там все будет UP

Возможно, вы смотрите не в те окружения (dev, prod, test)

Может быть, вы это все делаете на сервере, или хотите увидеть изменения в продакшене, тогда как по-дефолту - окружение dev.

Тогда нужно попробовать
RAILS_ENV=production bundle exec rake db:migrate

Простое архитектурное решение - EAV в том числе и для задачи характеристик (фильтров, свойств) в интернет-магазине. При том, еще и довольно неплохо масштабируется. Так сказать, это облегченный вариант поисковых движков (Sphinx, Elasticsearch, Solr...) для начала. И часто его может хватить с головой.