На мінулым занятку мы падрыхтавалі ўсе неабходныя інструменты, таму не будзем марудзіць і створым наша першае Rails прыкладанне. Зрабіць гэта вельмі проста з дапамогай каманды rails new:
$ rails new course-app
course-app - гэта назва праекта, можаце абраць яе на ваш густ. З дапамогай каманды rails new ствараецца стандартны каркас Rails прыкладання, выконваецца усталёўка гемаў (bundle install) і адбываецца падрыхтоўка бінарных файлаў да працы з прэлоадэрам Spring. Паглядзіце, колькі дырэкторый і файлаў ствараецца з дапамогай адной толькі каманды:
Вы бачыце агульную структуру Rails прыкладанняў. З архітэктурай Rails мы
пазнаёмімся на наступным занятку.
Мы ўжо маем мінімальна працоўнае прыкладанне. Давайце запусцім яго на нашым лакальным web-серверы:
$ cd course-app
$ rails server
Rails пастаўляецца з вэб-серверам Webrick. Webrick запускае наша прыкладанне на порце нумар 3000 (калі ён не заняты). Паглядзіце вынік: http://localhost:3000/. Гэта дэфолтная старонка Rails. Мы выканалі ўсяго толькі 2 каманды, а ўжо маем мінімальна працоўнае Rails прыкладанне на сваім лакальным серверы! Каб адключыць web-сервер трэба націснуць Ctrl+C у тэрмінале.
Bundler - гэта інструмент для усталёўкі і кіравання гемамі і залежнасцямі. Усталёўка ўсіх гемаў адбываецца з дапамогай простай каманды (вы ужо бачылі яе, калі мы запускалі rails new):
$ bundle install
Паглядзіце файл Gemfile:
Каб выкарыстаць якую-небудзь Ruby бібліятэку, дастаткова дадаць радок з назвай і
(апцыянальна) версіяй гема у гэты файл.
У нашым Gemfile ўжо ёсць цэлы шэраг бібліятэк, у тым ліку Rails. Гэта ўсё
дэфолтныя лібы, якія дадаюцца падчас запуска rails new.
Звярніце увагу, як пазначаюцца версіі у файле. Некаторыя гемы ўвогуле без версіі:
gem 'jquery-rails'
Калі не пазначыць нумар версіі, то Bundler усталюе апошнію стабільную версію. У некаторых версія жорстка зададзена:
gem 'rails', '4.2.0'
Таксама можна убачыць спецыфічны (і інтуітыўна зразумелы) сінтаксіс Bundler:
gem 'bcrypt', '~> 3.1.7'
gem 'uglifier', '>= 1.3.0'
gem 'sass-rails', '~> 5.0'
У першым выпадку магчыма усталёўка версіі НЕ МЕНШАЙ за 3.1.7 і МЕНШАЙ за 3.2.0. У другім выпадку магчыма усталёўка версіі НЕ МЕНШАЙ за 1.3.0. У трэцім выпадку усталюецца версія НЕ МЕНШАЯ за 5.0 і МЕНШАЯ за 6.0. Пазнаёмцеся з пагаджэннямі па кіраванню версіямі ў свеце распрацоўкі Software можна на сайце Semantic Versioning.
Звярніце таксама увагу на наступны код:
group :development, :test do
gem 'spring'
end
Гемы можна групаваць па асяроддзям распрацоўкі. У дадзеным выпадку гэта асяроддзі development і test. Гэта значыць, што Spring не будзе даступны ў production асяроддзі (а ён там і не патрэбны).
Усе гемы па дэфолту усталёўваюцца з сервера RubyGems:
source 'https://rubygems.org'
Давайце ўсталюем наш першы гем. Выдаліце сімвал # з радка
# gem 'therubyracer', platforms: :ruby
Усе, што знаходзіцца за сімвалам # у Ruby - гэта каменты. Код каментаў не выконваецца.
Therubyracer - гэта інтэрпрытатар
JavaScript для Ruby. Ен выкарыстоўваецца, напрыклад, для кампіляцыі асетаў. А
яшчэ, ён неабходны, калі вы не паставілі NodeJs. Давайце ўсталюем гем:
$ bundle
Звярніце увагу, што неабавязкова пазначаць опцыю install, бо яна дэфолтная для каманды bundle
Bundler робіць за вас усю працу па кіраванні залежнасцямі. Ён робіць гэта на аснове вашага Gemfile і дазваляе пазбегнуць так званага Dependency Hell. З дапамогай Bundler у кожнага распрацоўшчыка з каманды будуць аднолькавыя версіі gem-пакетаў. Больш за тое, Bundler дае магчымасці кіраваць залежнасцямі на production-серверы. Кожны раз, калі вы запускаеце bundle, аўтаматычна абнаўляецца файл Gemfile.lock, які і гарантуе аднолькавую усталёўку гем-пакетаў для ўсіх распрацоўшчыкаў каманды.
Для таго, каб зручна было кіраваць кодам нашага прыкладання, адкатваць і адсочваць змяненні і эфектыўна працаваць у камандзе, неабходна змясціць код нашага прыкладання ў сістэму кантроля версій. Мы ўжо усталявалі Git на мінулым занятку, яго і будзем выкарыстоўваць надалей. З дапамогай Git мы зможам апублікаваць наша прыкладанне на Github, а таксама разгарнуць яго на сапраўдным production серверы.
Git - гэта размеркаваная сістэма кантроля версій. Гэта значыць, што ўвесь рэпазіторый з праектам можа захоўвацца адначасова на кампутарах каманды распрацоўшчыкаў і на серверы. І кожны раз, калі распрацоўшчык бярэ свежыя версіі файлаў, ствараецца поўная копія ўсіх дадзеных. Перавага размеркаваных сістэм ў тым, што няма залежнасці ад сервера (як у цэнтралізаваных сістэмах): вы можаце аднавіць праект, нават калі сервер "упаў". Таксама ёсць магчымасць працаваць з некалькімі выдаленымі рэпазіторыямі што дае больш гнуткасці ў арганізацыі працэсаў. Паглядзіце схему размеркаванай сістэмы кантроля версій:
Трэба пазначыць імя і email вашага карыстальніка, каб Git мог вас ідэнтыфікаваць:
$ git config --global user.name "Niels Bohr"
$ git config --global user.email [email protected]
Правяраем наладкі:
$ git config --list
Git па дэфолту сочыць за усімі файламі рэпазіторыя, але гэта не заўсёды неабходна. Напрыклад, навошта змяшчаць пад кантроль Git часовыя файлы і файлы логаў? Гэтыя файлы пастаянна змяняюцца і розныя для усіх распрацоўшчыкаў. Таксама карысна будзе выключыць з пад кантроля файлы з сакрэтнымі канфігурацыямі (напрыклад, для базы дадзеных ці мэйлера). Для таго, каб пазначыць, якія файлы трэба ігнараваць, існуе адмысловы файл .gitignore. Гэты файл ужо створаны у нас (з дапамогай усё той жа каманды rails new). Таксама там ужо дададзеныя стандартныя файлы Rails прыкладання, якія звычайна не трэба адсочваць (log, tmp і гэтак далей). Я рэкамендую дадаць у .gitignore наступны радок, калі вы выкарыстоўваеце RubyMine (гэта дазволіць ігнараваць спецыфічныя файлы вашага IDE):
.idea
Каб ініцыялізаваць Git і атрымаць магчымасць аддаць наш код пад кантроль трэба выканаць каманду:
$ git init
Зараз можна дадаць усе файлы з каталога нашага прыкладання:
$ git add .
Гэта каманда дадае усе файлы і каталогі з бягучай дырэкторыі, а таксама ўсе падкаталогі. З дапамогай каманды git status можна адсочваць бягучы стан нашага Git-рэпазіторыя:
$ git status
Давайце зараз зробім наш першы каміт і захаваем нашы змяненні:
$ git commit -m "Initial commit: create Rails app, install therubyracer"
Initial commit... - гэта паведамленне пра змяненні кода. Старайцеся пісаць гэтае паведамленне як мага больш зразумела і інфарматыўна, каб праcцей потым было знайсці вашыя змяненні.
З дапамогай Git можна даволі проста адмяняць незафіксаваныя змяненні. Выдаліце якую-небудзь дырэкторыю вашага Rails прыкладання, напрыклад /app (не бойцеся).
Паглядзіце, што адбылося:
$ git status
Здавалася б, мы зрабілі вялікую памылку - выдалілі галоўны каталог нашага прыкладання. Але пакуль мы не зафіксавалі змянені, выправіць гэта вельмі проста:
$ git checkout -f
Гэта каманда вяртае наш рэпазіторый да апошняга каміта. І поўнасцю аднаўляе выдалены каталог.
Github - гэта самы вялікі хостынг для Git рэпазіторыяў. Там можна апублікаваць свой праект. Мы гэта зробім, але спачатку трэба дадаць SSH-ключы да свайго акаўнта. Падрабязная інструкцыя тут.
Мы зафіксавалі змяненні з дапамогай git commit. Але змяненні захаваліся лакальна, толькі на вашай машыне. Зараз мы адправім змяненні на Github. Стварыце новы рэпазіторый.
Цяпер усё гатова для адпраўкі на Github:
$ git remote add origin https://github.com/micrum/course-app.git
$ git push -u origin master
Цяпер demo-праект нашага курса даступны на Github. І кожны можа сцягнуць яго сабе у любы момант з дапамогай каманды git clone:
$ git clone https://github.com/micrum/course-app.git
Git дазваляе ствараць галіны (branches). Гэта значыць, ствараць копіі рэпазіторыя і паралельна працаваць у іх. Напрыклад, вы жадаеце імплементаваць нейкую новую фічу на праекце, але не упэўнены, што яна будзе стабільна працаваць. Вы можаце стварыць асобную галіну і працаваць у ёй, без перашкоды іншым распрацоўшчыкам, і мець стабільную версію праекта ў галоўнай галіне (master). І калі праца над фічай скончыцца, вы зможаце зліць вашую галіну у master. Альбо выдаліць сваю галіну, калі эксперымент будзе няўдалым.
Давайце на практыцы пазнаёмімся з галінаваннем. Я ўжо казаў, што Rails пастаўляецца з web-серверам Webrick. Мы зараз зменім яго на больш эфектыўны web-сервер Puma. Пагатоў, што ён спатрэбіцца нам, калі будзем разгортваць нашае прыкладанне ў production. Ствараем і пераходзім на новую галіну (change-web-server - гэта назва, зноў-такі, для галін рэкамендую абіраць інфарматыўныя назвы):
$ git checkout -b change-web-server
Паглядзець бягучую галіну можна з дапамогай каманды:
$ git branch
Puma можна ўсталяваць як гем. Адчыніце Gemfile і дадайце радок:
gem 'puma'
Не забудзьце усталяваць яго:
$ bundle
Запусціце web-сервер, каб пераканацца, што ўсё працуе:
$ rails s
rails s - гэта alias (кароткая мянушка) для каманды rails server.
А зараз давайце зафіксуем змяненні:
$ git commit -a -m "Update web-server"
Паглядзець гісторыю камітаў можна з дапамогай каманды git log:
$ git log
Мы пераканаліся, што ўсё працуе, таму зараз можна аб'яднаць нашыя галіны. Пераходзім на master і зліваем галіны:
$ git checkout master
$ git merge change-web-server
Галіна change-web-server больш не патрэбная, можна яе выдаліць:
$ git branch -d change-web-server
Дарэчы, у беларускай мове сустракаецца адпаведнік слову server - паслужнік.