railstutorial.ru/chapters/4_0/beginning
Начинаете с фреймворка (рельсы), а не языка (руби).
Чаще гуглите. Старайтесь читать только англоязычную информацию.
Используйте линукс (или мак).
В отличии от распространенного подхода, сначала делаете,
что б работало:
- с помощью ORM создаете логику - потом разбираетесь, как работает SQL
- с помощью гемов реализуете типичную инфраструктуру (аутентификация, авторизация, комментарии, эмейл-рассылку) - после разбираетесь с тем, как же оно работает
- сначала делаете прототип, который работает (описываете бизнес-логику), потом ищите узкие места, которые нужно оптимизировать (если таковые есть).
Не велосипедьте:
- велосипеды изобретаете только в редких случаях (по остальному гуглите best-practices, на начальном этапе >80% задач, с которым сталкнетесь, уже давно решены множество раз и очень элегантным способом), а если и написали - то делитесь с сообществом, организовав его в гем.
Ресурсы
- Перед тем, как приступить к решению задачи, сначали ищите решение здесь:
https://www.ruby-toolbox.com/
- Пробуйте по-максимуму использовать специализированные ресурсы (
rubular,
heroku), которые облегчат жизнь на каком-то этапе.
- Сразу же привыкайте к таким вещам, как
firebug,
byebug,
pry,
Ap
P.S.
Итак, наверное, многих смутит подход отказаться от велосипедов, пользоваться преимуществами коммьюнити, делают вещи, которые just work и не понимать сути некоторых из них на начальном этапе.
Так вот, хоть это и "обидно" не знать чего-то (хотя, когда знаешь, чего не знаешь - узнать это куда легче :) ), ведь кто-то может спросить тебя "Чувак! Ты сделал ЭТО, взял за ЭТО деньги, и вот скажи, как ты это сделал? Как оно работает? А что будет если Х ? А есть сделать Y? А в ситуации Z?"
И тут понимаешь, что ты всего это не знаешь, не продумывал, но что-то уже есть, работает, деньги заплачены, фидбек получен. И тут наверное, должно стать бы стыдно... Но кроме этого тезиса я не вижу причин отказываться от предложенного подхода.
Давайте предсатвим простейшую ситуацию и попробуем взвесить плюсы и минусы (наверное, этот вопрос будет многим интересен еще долго время)
Вы только решили начать изучать Ruby on Rails. И тут подвернулся знакомый, которому нужен простейший сайт-визитка с простой админкой.
Конечно, вы можете потратить неделю или месяц на то, что б понять, как сделать простейшую аутентификацию с bcrypt, как настроить rvm, unicorn, nginx на vps и наклепать кучу вьюх для редактирования чего-то там
А можете поставить devise, active admin и high voltage, получить деньги и увидеть работающее решение, которое на 100% удовлетворяет требованиям заказчика. Хотя вы нифига и не понимаете, как оно все вместе работает.
Какие плюсы?
- Возможность делать реальную работу и получать реальные деньги почти сразу
- Возможность быстро сделать то, что понравится самому, вместо того, что б перепилить 10 велосипедов, которые уже достали
- Возможность заниматься бизнес-логикой вместо инфраструктуры
- Использование опыта сообщества
- Если вы стараетесь "меньше разбираться сам в готовых решения", вы рискуете не изобрести очередной велосипед, а делать все по best-practice (envrionments, deployment, svc, asset pipeline)
...
Какие минусы?
- Действительно, в тот момент, когда выйдет первый более-менее продакшн, вы не станете Йодой по экранированию кавычек или Мастером iconv.
- У вас, скорей всего, не будет времени на изобретение нового "MVC" фреймворка
- Врядли вы захотите "подарить миру еще одну CMS"
- Вы не прочтете кучу учебников "руби для чайников", потому что к концу первого псевдо-проекта поймете, как мало там пользы для начала
- И, конечно, если вы пришли сюда, "потому что айтишникам много платят", то дальше, как это называют, джуниора, не уйдете.
А разобраться, как оно устроено внутри - можно всегда, пока не подписали никаких обязующих договоров и NDA :) хотя, и после можно.
Точно так же, как плоха преждевременная оптимизация. Точно так же очень часто бывает плохо "преждевременно в чем-то разобраться".
В основном нужно не "круто шарить". Не знать синтаксис каждой команды языка и популярных библиотек напамять. Не помнить досконально, что делает тот или иной кусок кода. А понимать, где какое решение лучше применить и почему. А так же, по какому пути идти в определенной ситуации, что б найти выход. И зубреж фундаментальных основ, к сожалению, не так часто здесь помогает.
Или есть еще минусы? Кстати, заметьте, что никто не говорил, "нужно ли вообще делать Х". Спрашивалось, "что лучше делать вначале?".
