Підготовка робочого середовища для роботи з Ruby on Rails

Сьогоднішня стаття відкриває серію більш практичних дописів, які допоможуть початківцям спробувати втілити якийсь конкретний функціонал. Починаємо, звісно ж, з основ: Як встановити Ruby on Rails. Автор статті: Віталій Накопало

Незалежно від мови програмування чи фреймворку, яким користується розробник, запорукою його ефективності у повсякденній роботі – є зручне, та правильно налаштоване робоче середовище. І Ruby on Rails тут не є винятком.

Перед тим як сказати “rails new my_awesome_app -d postgresql” і почати захоплюючий, складний та цікавий шлях знайомства і роботи з фреймворком потрібно зробити декілька речей.

Отже давайте розберемо що нам для цього потрібно.

Перш за все нам потрібно визначитись з операційною системою у якій ми будемо працювати. Найпоширеніші варіанти – це Linux-дистрибутиви, MacOS та Windows. Моїм вибором є Ubuntu – дистрибутив Linux, який побудований на основі Debian GNU/Linux. В ньому є все, що потрібно для того, щоб почувати себе конфортно підчас роботи. Одним словом – консоль 🙂

Оскільки Ruby on Rails написаний на мові програмування Ruby, то наступним кроком є встановлення Ruby (як би це не було очевидно 🙂
В Ubuntu для цього нам потрібно виконати декілька консольних команд (зрештою весь процес налаштування нашого средовища буде відбуватись у консолі):

sudo apt-get update – синхронізуємо файли-описів пакетів з їх джерелом і отримуємо оновлений список пакетів.

Далі встановлюємо необхідні пакети для роботи ruby:

sudo apt-get install git-core curl zlib1g-dev build-essential libssl-dev libreadline-dev libyaml-dev libsqlite3-dev sqlite3 libxml2-dev libxslt1-dev libcurl4-openssl-dev python-software-properties libffi-dev nodejs

Після цього в нас є декілька варіантів дій. Ми можемо відразу встановити ruby, виконавши команду sudo apt-get install ruby-full, або скористатись якоюсь із систем управління версіями Ruby.

Cистема управління версіями ruby? Невже в нас буде потреба використовувати декілька різних версій ruby? Насправді так – декілька різних проектів можуть бути написані на різних версіях ruby. І, власне, для зручного переходу між версіями використовуються системи управління версіями – зокрема rvm та rbenv.

Встановимо ruby за допомогою rbenv:

cd
git clone https://github.com/rbenv/rbenv.git ~/.rbenv
echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bashrc
echo 'eval "$(rbenv init -)"' >> ~/.bashrc
exec $SHELL

git clone https://github.com/rbenv/ruby-build.git ~/.rbenv/plugins/ruby-build
echo 'export PATH="$HOME/.rbenv/plugins/ruby-build/bin:$PATH"' >> ~/.bashrc
exec $SHELL

rbenv install 2.4.2
rbenv global 2.4.2
ruby -v

Якщо все пройшло успішно, то після виконання останньої команди ми побачимо версію ruby. У моєму випадку таке повідомлення:
ruby 2.4.2p198 (2017-09-14 revision 59899) [x86_64-linux]

Вітаю! Ruby за допомогою rbenv успішно встановлено 🙂
Йдемо далі.

Підчас розробки на ruby не завжди є необхідність писати все самому. За час існування мови, для неї була написана надзвичайно велика кількість корисних пакетів – gem’ів (серед яких rails), які розширюють можливості мови і дозволяють швидко розробляти, використовуючи готові рішення. Для Ruby on Rails також існують такі розширення. Для зручного встановлення gem’ів існує Bundler – менеджер управління gem’ами.

gem install bundler
rbenv rehash

це все що потрібно зробити для його встановлення.

Отже, на даний момент ми встановили дві системи управління:

rbenv – cистема управління версіями ruby
bundler – менеджер управління gem’ами (та їх версіями)

Але це ще не все 🙂
Далі нам потрібно встановити ще одну систему контролю версій – Git.

Git – це система контролю версій, яка дозволяє відстежувати зміни у файлах проекту, при необхідності проводити їх відкат, визначати, хто і коли вносив зміни.

Для того щоб проект хостився на віддаленому репозиторії (що дозволяє нам отримати доступ до нього з будь якого місця де є інтернет), нам потрібно разеєструватись на одному з таких сервісів як GitHub, Bitbucket, GitLab.

До прикладу GitHub. Після реєстрації у консолі пишемо наступні команди:

git config --global color.ui true
git config --global user.name "ім’я користувача"
git config --global user.email "email користувача"
ssh-keygen -t rsa -b 4096 -C "email користувача"

GitHub використовує аутентифікацію за відкритими SSH-ключами. Для того щоб отримати такий ключ, потрібно його згенерувати:

cat ~/.ssh/id_rsa.pub

після чого розмістити у відповідному розділі на GitHub.

Якщо все було зроблено правильно, то після виконання команди:
ssh -T git@github.com

ми отримаємо таке повідомлення:
Hi username! You've successfully authenticated, but GitHub does not provide shell access.

Далі встановимо nodejs – середовище виконання JS – що, зокрема, дозволяє використовувати Coffeescript у Rails:

curl -sL https://deb.nodesource.com/setup_8.x | sudo -E bash -
sudo apt-get install -y nodejs

Нам залишилось встановити рельси та систеу управління базами данних.

Оскільки RoR, як ми вже раніше згадували, є ruby-джемом, тому встановлюємо ruby gem:

gem install rails -v 5.1.4
rbenv rehash

і команда rails -v поверне версію рельсів:

Rails 5.1.4

Встановлюємо СУБД
Завдяки Active Record DB Adapters в rails можна підключати різні бази даних, такі як MySQL, PostgreSQL, SQLite3, Oracle, Microsoft SQL Server.
Розглянемо встановлення PostgreSQL:

sudo sh -c "echo 'deb http://apt.postgresql.org/pub/repos/apt/ xenial-pgdg main' > /etc/apt/sources.list.d/pgdg.list"
wget --quiet -O - http://apt.postgresql.org/pub/repos/apt/ACCC4CF8.asc | sudo apt-key add -
sudo apt-get update
sudo apt-get install postgresql-common
sudo apt-get install postgresql-9.5 libpq-dev

встановлюємо користувача:

sudo -u postgres createuser username -s

і останні штрихи:

створюємо нашу веб-аплікацію:
rails new my_awesome_app -d postgresql

переходимо у директорію проекту:
cd my_awesome_app

створюємо базу даних:
rails db:create

запускаємо сервер:
rails server

наш сайт тут:
http://localhost:3000

Ми описали основні кроки, які потрібно зробити, для того, щоб почати розробляти на rails. Цього, звичайно, не досить. Але такі речі як конфігурування Vagrant та протистояння Atom vs Vim напевне збільшать цю статтю, як мінімум, у двічі 🙂

Як отримати максимальний ефект від код рев’ю?

Після невеликої паузи (минулого тижня в курсантів була внутрішня “сесія”), продовжуємо публікацію статтей курсантів RubyForce. Сьогодні знову стаття від Іллі Кузьми:

На мою думку, code review (CR) – це дуже крута річ, користь від якої отримують всі. Автор коду – свіжий погляд на вирішення проблеми над якою працював. Рев’ювер – розуміння частини проекту, спосіб та підхід до вирішення певного завдання. Загалом, проект стає чистішим та зрозумілішим.

Існує думка, що немає сенсу залучати початківців до CR. Я так не вважаю. Звичайно, добре мати досвідченого розробника, який вкаже на проблеми в коді. Але, навіть, коли новачок рев’ювить чийсь код – це приносить велику користь. Особисто для мене, було дуже складно читати чужий код. CR дозволяє зосередитись на певній частині програми. Розібрати її детально. Зрозуміти підхід іншого розробника. Навчитись. З іншої сторони, коли я сам пишу код і створюю Pull Request, то переглядаю написане перед тим як його побачать інші.

Так, це не легко. Складно вникати в суть написаного кимось коду. CR вимагає багато часу. Інколи хочеться швидше закінчити CR, або відкласти на потім, або просто погодити без перегляду і повернутись до своєї feature. Для того щоб побороти це, потрібно дотримуватись певних принципів.

По-перше, CR – це дуже важлива чатина workflow. Не менш важлива ніж написання коду.

По-друге, гарне CR – це прояв поваги до свого колеги. В такий спосіб ми цінуємо працю іншої людини.

По-третє, всі учасники проекту повинні домовитись як часто вони робитимуть CR. Цей пункт поясню детальніше. Я почув цю ідею у відео MPJ на його YouTube каналі. Така домовленість називається Working Contract. Це неформальна згода усіх членів команди слідувати певному workflow. Автор PR природньо хоче швидкого RAM(review and merge). В той же час інші програмісти не хочуть відволікатись від того над чим працюють вони. Адже CR вимагає занурення в зовсім іншу задачу. Working Contract вирішує цю проблему. Ми домовляємось про CR раз на день. Автор знає, що його PR буде переглянутий колегами до завтрашнього дня і може спокійно переходити до ішого завдання. Рев’ювер може приступити до, власне, CR тоді коли йому буде зручно.

По-четверте, супер важливо коректно писати коментарі. Текст не передає всього змісту повідомлення. Наша мета – кращий код. І CR не місце переходу на особистості.

І останнє, з власного досвіду. Не варто безапеляційно погоджуватись зі всіма зауваженнями більш досвідчених колег. Ви працювали над завданням. Ви глибоко розібрали його. Інколи, яким би досвідченим не був рев’ювер, він просто не встані осягнути всі аспекти рішення. Якщо ви впевнені, що ваш код є кращим, поясніть детальніше чому так. Або якщо не розумієте попросіть пояснити зауваження, щоб в майбутньому писати краще!