Więcej na rubyonrails.pl: Start | Pobierz | Wdrożenie | Kod (en) | Screencasty | Dokumentacja | Ekosystem | Forum | IRC

Narzędzia linii poleceń oraz zadania Rake

Ruby on Rails dostarcza wszystkich niezbędnych narzędzi linii poleceń, które umożliwiają:

Ten tutorial zakłada, że przyswoiłeś już sobie podstawy Railsów zapoznając się z przewodnikiem Zaczynamy z Ruby on Rails.

1 Podstawy linii poleceń

Znajomość kilku podstawowych komend to absolutna konieczność. Będziesz z nich często korzystać w codziennej pracy. Te najważniejsze to odpowiednio:

  • rails console
  • rails server
  • rake
  • rails generate
  • rails dbconsole
  • rails new app_name

Stworzymy teraz prostą aplikację, abyś mógł się z nimi zaznajomić w praktyce.

1.1 rails new

Pierwszym krokiem będzie stworzenie nowej aplikacji poprzez polecenie rails, po uprzednim zainstalowaniu Railsów.

Oczywiście, zdajesz sobie sprawę, że aby to zrobić musisz mieć już zainstalowane Railsy, prawda? Najlepiej zrobić to za pomocą gema, poleceniem gem install rails.

$ rails new commandsapp create create README create .gitignore create Rakefile create config.ru create Gemfile create app ... create log/production.log create log/development.log create log/test.log

Wywołanie tej jednej maleńkiej komendy wygenerowało dla ciebie całkiem spore ilości kodu. Masz już gotową strukturę katalogów oraz kod potrzebny do działania naszej prostej aplikacji.

Efekt działania tej komendy może ci się teraz wydać nieco przytłaczający. Spokojnie, kiedy omówimy polecenie generate wszystko stanie się jasne.

1.2 server

Pora sprawdzić jak to działa! Komenda server uruchomi serwer WWW o nazwie WEBrick, który standardowo dołączony jest do Rubiego. Będziemy z niego korzystać za każdym razem, gdy będziemy chcieli zobaczyć w przeglądarce efekty naszej pracy.

Możesz też zastosować alternatywne serwery. Ich omówieniem zajmiemy się w innej części przewodnika.

Wywołanie komendy server natychmiast uruchomi serwer, który obsłuży naszą wspaniałą nową aplikacje:

$ cd commandsapp $ ./script/server => Booting WEBrick... => Rails 2.2.0 application started on http://0.0.0.0:3000 => Ctrl-C to shutdown server; call with --help for options [2008-11-04 10:11:38] INFO WEBrick 1.3.1 [2008-11-04 10:11:38] INFO ruby 1.8.5 (2006-12-04) [i486-linux] [2008-11-04 10:11:38] INFO WEBrick::HTTPServer#start: pid=18994 port=3000

I proszę, przy pomocy zaledwie trzech komend postawiliśmy serwer Railsowy na porcie 3000. A teraz nie zwlekaj! Nie zwlekaj, czym prędzej otwórz przeglądarkę i uruchom http://localhost:3000.

I jak? Nienajgorzej, co? Wszystko działa. nasza aplikacja nie jest może na razie zbyt funkcjonalna, ale zaraz się tym zajmiemy.

1.3 generate

Komenda generate używa szablonów (templates) do tworzenia wielu różnych rzeczy. Możesz sprawdzić co jest dostępne wywołując komendę generate bez dodatkowych opcji. Spróbujmy:

$ ./script/generate Usage: ./script/generate generator [options] [args] ... ... Installed Generators Built-in: controller, integration_test, mailer, migration, model, observer, performance_test, plugin, resource, scaffold, session_migration ... ...

Możesz zainstalować dodatkowe generatory poprzez odpowiednie gemy, wtyczki (plugins) lub tworząc je samemu.

Stosując generatory zaoszczędzisz mnóstwo czasu, który spędziłbyś na pisanie niezbędnych, ale wtórnych fragmentów kodów (tzw. boilerplate code).

Stwórzmy teraz własny kontroler stosując generator kontrolerów. Ale jakiej komendy powinniśmy użyć. Zapytajmy generatora:

Wszystkie polecenia konsoli Railsów mają dołączoną pomoc. Podobnie jak przy większości poleceń systemów uniksowch i uniksopodobnych, możesz spróbować ją wywołać dodając opcję --help lub -h na końcu komendy, np.: ./script/server --help.

$ ./script/generate controller Usage: ./script/generate controller ControllerName [options] ... ... Example: ./script/generate controller CreditCard open debit credit close Credit card controller with URLs like /credit_card/debit. Controller: app/controllers/credit_card_controller.rb Views: app/views/credit_card/debit.html.erb [...] Helper: app/helpers/credit_card_helper.rb Test: test/functional/credit_card_controller_test.rb Modules Example: ./script/generate controller 'admin/credit_card' suspend late_fee Credit card admin controller with URLs /admin/credit_card/suspend. Controller: app/controllers/admin/credit_card_controller.rb Views: app/views/admin/credit_card/debit.html.erb [...] Helper: app/helpers/admin/credit_card_helper.rb Test: test/functional/admin/credit_card_controller_test.rb

Jak widzimy, generator kontrolerów żąda dodatkowych parametrów w postaci generate controller NazwaKontrolera akcja1 akcja2. Stworzymy więc kontroler powitania o nazwie Greetings i akcji hello, który grzecznie się z nami przywita.

$ ./script/generate controller Greetings hello exists app/controllers/ exists app/helpers/ create app/views/greetings exists test/functional/ create app/controllers/greetings_controller.rb create test/functional/greetings_controller_test.rb create app/helpers/greetings_helper.rb create app/views/greetings/hello.html.erb

Spójrzmy co się stało. Co zostało wygenerowane? Generator upewnił się, że pewne katalogi już istnieją w naszej aplikacji, a następnie stworzył plik kontrolera, plik testowy, helper dla widoku oraz plik widoku.

Zajrzyjmy do kodu kontrolera i nieco go zmodyfikujmy (app/controllers/greetings_controller.rb):

class GreetingsController < ApplicationController def hello @message = "Hello, how are you today? I am exuberant!" end end

A teraz otwórzmy widok, który wyświetli nasze urocze powitanie (app/views/greetings/hello.html.erb):

<h1>A Greeting for You!</h1> <p><%= @message %></p>

Gotowe. Sprawdź teraz jak to wygląda w przeglądarce. Pamiętaj o uruchomieniu serwera. Możesz to zrobić za pomocą ./script/server wywołanego z głównego katalogu twojej aplikacji.

$ ./script/server => Booting WEBrick...

Upewnij się, że w katalogu app/views/(controller) nie znajdują się żadne kopie zapasowe plików z tyldą, w przeciwnym wypadku WEBrick nie wyświetli poprawnych rezultatów. To zdaje się bug Railsów w wersji 2.3.0.

Adres to http://localhost:3000/greetings/hello.

Adres URL standardowej aplikacji Railsowej, opiera się na schemacie http://(host)/(kontroler)/(akcja), a adres http://(host)/(kontroler) wywołuje akcję index kontrolera.

“Ale co z danymi?”, mógłbyś zapytać. Otóż Railsy oferują także generator modeli danych. Jak myślisz ja go wywołać?

$ ./script/generate model Usage: ./script/generate model ModelName [field:type, field:type] ... Examples: ./script/generate model account creates an Account model, test, fixture, and migration: Model: app/models/account.rb Test: test/unit/account_test.rb Fixtures: test/fixtures/accounts.yml Migration: db/migrate/XXX_add_accounts.rb ./script/generate model post title:string body:text published:boolean creates a Post model with a string title, text body, and published flag.

Ale zamiast generować model bezpośrednio (czym zajmiemy się później) postawimy teraz rusztowanie (scaffold). Rusztowanie to w Rails model, migracja bazy danych dla tego modelu, kontroler do jego obsługi, widoki do wyświetlania i manipulowania danymi, i zestaw testowy dla każdego z powyższych.

Stworzymy teraz prosty zasób, który nazwiemy “HighScore”. Będzie on zawierał nasze najwyższe wyniki osiągnięte w grach, w jakie ostatnio graliśmy.

$ ./script/generate scaffold HighScore game:string score:integer exists app/models/ exists app/controllers/ exists app/helpers/ create app/views/high_scores create app/views/layouts/ exists test/functional/ create test/unit/ create public/stylesheets/ create app/views/high_scores/index.html.erb create app/views/high_scores/show.html.erb create app/views/high_scores/new.html.erb create app/views/high_scores/edit.html.erb create app/views/layouts/high_scores.html.erb create public/stylesheets/scaffold.css create app/controllers/high_scores_controller.rb create test/functional/high_scores_controller_test.rb create app/helpers/high_scores_helper.rb route map.resources :high_scores dependency model exists app/models/ exists test/unit/ create test/fixtures/ create app/models/high_score.rb create test/unit/high_score_test.rb create test/fixtures/high_scores.yml exists db/migrate create db/migrate/20081217071914_create_high_scores.rb

Po kolei. Generator sprawdza czy istnieją katalogi dla modeli, kontrolerów, helperów, layoutów, testów funkcjonalnych i jednostkowych, arkuszy stylów (stylesheet). Następnie tworzy widoki, kontrolery, modele i migracje baz danych dla zasobu HighScore (tworzy tabelę high_scores i pola). W końcu zajmuje się drogą routingu zasobu i nowymi testami dla wszystkich elementów.

Migracja wymaga wykonania pewnego kodu (zawartego w pliku 20081217071914_create_high_scores.rb) w celu modyfikacji bazy danych. Ale właściwie jakiej bazy? Bazy danych sqlite3, którą Railsy za chwilę dla ciebie utworzą, gdy wywołamy polecenie rake db:migrate. Szczegółowym omówieniem tej komendy zajmiemy się nieco później.

Hej, skoro już mowa o sqlite3, pora zainstalować jego gem poleceniem gem install sqlite3-ruby.

$ rake db:migrate (in /home/commandsapp) CreateHighScores: migrating create_table(:high_scores) -> 0.0070s CreateHighScores: migrated (0.0077s)

Pomówmy teraz o testach jednostkowych. Testy jednostkowe to kod odpowiedzialny za testowanie i przedstawianie uwag na temat testowanego kodu. W procesie testowym, brany jest niewielki fragment kodu, powiedzmy metoda modelu, a następnie sprawdzane są dane wejściowe i wyjściowe tej metody. Zapamiętaj testy jednostkowe to twoi kumple. Im wcześniej zdasz sobie sprawę, że mogą znacząco ułatwić ci życie tym lepiej. Serio! Zaraz jakiś przeprowadzimy.

Spójrzmy na interfejs jaki przygotowały dla nas Railsy. ./script/server; http://localhost:3000/high_scores

Możemy teraz dodać jakiś rekordowy wynik (55,160 dla Space Invaders!)

1.4 console

Komenda console pozwala ci komunikować się ze swoją aplikacją za pomocą linii poleceń. script/console korzysta z IRB, więc jeśli korzystałeś już z tej powłoki praca z konsolą będzie dla ciebie intuicyjna. Konsola przydaje się głównie do szybkiego sprawdzania świeżych pomysłów, bez interferowania w kod strony.

1.5 dbconsole

dbconsole sprawdza, której bazy danych używasz i natychmiastowo uruchamia dla ciebie interfejs linii poleceń jakiego z nią używasz (dodatkowo sprawdza i podpowiada ci parametry). Działa poprawnie z MySQl, PostgreSQL, SQLite i SQLite3.

1.6 plugin

Komenda plugin ułatwia zarządzanie wtyczkami, można by ją określić mianem miniaturowego RubyGems. Jak zainstalować wtyczkę? Możesz wywołać podkomendę discover, która przejrzy repozytoria w poszukiwaniu wtyczek lub wywołać source, aby dodać konkretne repozytorium wtyczek lub bezpośrednio określić ścieżkę do wtyczki.

Powiedzmy, że chcesz stworzyć witrynę dla klienta, który potrzebuje niewielkiego systemu księgowości. Wszystko co wiąże się z obrotem pieniędzmi powinno być odnotowane i niemożliwe do usunięcia. Czy nie byłoby to wspaniałe, gdybyśmy mogli odejść od domyślnego zachowania modelu, tak by nie można było usunąć jego rekordu, a zamiast tego aktualizowane było jakieś pole?

Istnieje taka możliwość! Wtyczka, o której mowa to “acts_as_paranoid”. Pozwala ona modelowi na dodanie kolumny “deleted_at”, którego pole modyfikowane będzie przy wywołaniu polecenia destroy. Później, przy wywołaniu find, wtyczka dołączy sprawdzenie bazy w celu odfiltrowania “usuniętych” rzeczy.

$ ./script/plugin install http://svn.techno-weenie.net/projects/plugins/acts_as_paranoid + ./CHANGELOG + ./MIT-LICENSE ... ...

1.7 runner

runner wykonuje kod Rubiego w kontekście Railsów, bez interakcji. Na przykład:

$ ./script/runner "Model.long_running_method"

1.8 destroy

Możesz myśleć o poleceniu destroy jako przeciwieństwie generate. Sprawdzi ono jakie były efekty wywołania generate i odwróci wprowadzone zmiany. Uwierz mi, że przy pisaniu tego tutoriala, komenda ta przydawała się wielokrotnie.

$ ./script/generate model Oops exists app/models/ exists test/unit/ exists test/fixtures/ create app/models/oops.rb create test/unit/oops_test.rb create test/fixtures/oops.yml exists db/migrate create db/migrate/20081221040817_create_oops.rb $ ./script/destroy model Oops notempty db/migrate notempty db rm db/migrate/20081221040817_create_oops.rb rm test/fixtures/oops.yml rm test/unit/oops_test.rb rm app/models/oops.rb notempty test/fixtures notempty test notempty test/unit notempty test notempty app/models notempty app

1.9 about

Wyświetla: numer wersji Rubiego, RubyGems, Railsów i ich komponentów, katalog główny twojej aplikacji, nazwę bieżącego środowiska Railsowego, rodzaj bazy danych twojej aplikacji oraz wersję jej schematu. Ta komenda bardzo się przydaje, gdy chcesz kogoś prosić o pomoc, sprawdzić czy łatka zabezpieczeń nie zaszkodzi lub gdy potrzebujesz statystyk dla istniejącej instalacji Railsów.

$ ./script/about About your application's environment Ruby version 1.8.6 (i486-linux) RubyGems version 1.3.1 Rails version 2.2.0 Active Record version 2.2.0 Action Pack version 2.2.0 Active Resource version 2.2.0 Action Mailer version 2.2.0 Active Support version 2.2.0 Edge Rails revision unknown Application root /home/commandsapp Environment development Database adapter sqlite3 Database schema version 20081217073400

2 Zaawansowane narzędzia linii poleceń

Bardziej zaawansowane sposoby korzystania z linii poleceń polegają na dopasowywaniu narzędzi do swoich potrzeb, poprzez ciągłe eksperymenty i odkrywanie przydatnych, a niejednokrotnie zaskakujących opcji. W tej sekcji postaramy się omówić kilka użytecznych trików.

2.1 Railsy, a bazy danych i systemy zarządzania kodem źródłowym (SCM)

Tworząc nową aplikację Railsową, mamy od razu możliwość zadeklarowania rodzaju bazy danych i systemu zarządzanie kodem źródłowym (source code management system) jakich będziemy używać w naszej aplikacji. Dzięki temu z pewnością zaoszczędzimy trochę czasu.

Zobaczmy jaki będzie efekt zastosowania opcji --git i --database=postgresql:

$ mkdir gitapp $ cd gitapp $ git init Initialized empty Git repository in .git/ $ rails new . --git --database=postgresql exists create app/controllers create app/helpers ... ... create tmp/cache create tmp/pids create Rakefile add 'Rakefile' create README add 'README' create app/controllers/application_controller_.rb add 'app/controllers/application_controller_.rb' create app/helpers/application_helper.rb ... create log/test.log add 'log/test.log'

Musieliśmy dodać katalog gitapp oraz zainicjalizować puste repozytorium git, zanim Railsy dodałyby pliki stworzone dla naszego repozytorium. Zobaczmy w jaki sposób została zmodyfikowana konfiguracja bazy:

$ cat config/database.yml # PostgreSQL. Versions 7.4 and 8.x are supported. # # Install the ruby-postgres driver: # gem install ruby-postgres # On Mac OS X: # gem install ruby-postgres -- --include=/usr/local/pgsql # On Windows: # gem install ruby-postgres # Choose the win32 build. # Install PostgreSQL and put its /bin directory on your path. development: adapter: postgresql encoding: unicode database: gitapp_development pool: 5 username: gitapp password: ... ...

Dzięki tym opcjom także plik database.yml został wzbogacony o kilka linijek kodu, oczywiście zgodnie z naszym wyborem – w tym przypadku bazą PostgreSQL. Jedyną niedogodnością związaną z opcją SCM jest konieczność stworzenia odpowiedniego katalogu przed inicjalizacją SCM. Później można już skorzystać z komendy rails, aby wygenerować podstawy dla aplikacji

2.2 server i różne serwery WWW

Dostępnych jest wiele różnych serwerów WWW Rubiego, większość z nich powinna współpracować z Railsami. Railsy w wersji 2.3. posługują się już interfejsem webowym Rack do obsługi stron internetowych. Oznacza to, że dla naszej aplikacji możemy wybrać dowolny Serwer WWW obsługujący zapytania Rack w tym min. WEBrick, Mongrel, Thin, Phusion Passenger i inne.

Aby dowiedzieć więcej na temat Rack, zajrzyj do przewodnika Rails on Rack.

Aby użyć innego serwera zainstaluj po prostu jego gem, a następnie użyj jego nazwy jako pierwszego parametru skryptu script/server:

$ sudo gem install mongrel Building native extensions. This could take a while... Building native extensions. This could take a while... Successfully installed gem_plugin-0.2.3 Successfully installed fastthread-1.0.1 Successfully installed cgi_multipart_eof_fix-2.5.0 Successfully installed mongrel-1.1.5 ... ... Installing RDoc documentation for mongrel-1.1.5... $ script/server mongrel => Booting Mongrel (use 'script/server webrick' to force WEBrick) => Rails 2.2.0 application starting on http://0.0.0.0:3000 ...

2.3 Generatory w Railsach

Na stronie Understanding Generators znajdziesz bardzo szegółowy opis działania generatorów. Znaczna jego część znalazła się w tym przewodniku.

Generatory to kod służący generowaniu kodu. Najlepiej zobaczmy to w praktyce. Nasz generator wygeneruje plik tekstowy.

Oto katalogi, w których generator railsów będzie domyślnie poszukiwał dostępnych generatorów, przy założeniu, że Rails.root to główny katalog twojej aplikacji (np. /home/foobar/commandsapp):

  • Rails.root/lib/generators
  • Rails.root/vendor/generators
  • Wewnątrz jakiejkolwiek wtyczki z katalogiem jak “generators”, czy “rails_generators”
  • ~/.rails/generators
  • Wewnątrz jakiegokolwiek Gema, który został zainstalowany pod nazwą kończącą się ciągiem “_generator”
  • Wewnątrz jakiegokolwiek Gema, który został zainstalowany ze ścieżką “rails_generators” i “_generator.rb” w nazwie pliku
  • Wreszcie pośród wbudowanych generatorów (kontrolerów, modeli, itp.)

Posłużymy się teraz czwartą możliwością (w katalogu domowym). Jej efektów najłatwiej się pozbyć.

$ mkdir -p ~/.rails/generators/tutorial_test/templates $ touch ~/.rails/generators/tutorial_test/templates/tutorial.erb $ touch ~/.rails/generators/tutorial_test/tutorial_test_generator.rb

Umieszczamy następujący kod w pliku tutorial_test_generator.rb:

class TutorialTestGenerator < Rails::Generator::Base def initialize(*runtime_args) super(*runtime_args) @tut_args = runtime_args end def manifest record do |m| m.directory "public" m.template "tutorial.erb", File.join("public", "tutorial.txt"), :assigns => { :args => @tut_args } end end end

Bierzemy dowolne dostarczone argumenty, zapisujemy je w zmiennej instancyjnej i bez żadnej modyfikacji kopiujemy, implementujemy metodę manifest, która wywołuje record, który:

  • Sprawdza czy katalog public istnieje.
  • Korzysta z szablonu ERb o nazwie “tutorial.erb”.
  • Zapisujemy w “Rails.root/public/tutorial.txt”.
  • Przekazuje argumnty zapisane za pomocą parametru :assign.

Teraz przygotujemy szablon:

$ cat ~/.rails/generators/tutorial_test/templates/tutorial.erb Jestem szablonem! Przypisano mi pewne argumenty: <%= require 'pp'; PP.pp(args, "") %>

Upewnimy się jeszcze że nasz generator znalazł się na liście dostępnych generatorów:

$ ./script/generate ... ... Installed Generators User: tutorial_test

Znakomicie. Teraz wygenerujemy jakiś tekst!

$ ./script/generate tutorial_test arg1 arg2 arg3 exists public create public/tutorial.txt

Rezultat:

$ cat public/tutorial.txt Jestem szablonem! Przypisano mi pewne argumenty: [["arg1", "arg2", "arg3"], {:collision=>:ask, :quiet=>false, :generator=>"tutorial_test", :command=>:create}]

Tada!

2.4 Rake to Make Rubiego

Rake jest samodzielnym narzędziem, będącym odpowiednikiem uniksowego ‘make’, który za pomocą ‘Rakefile’ i plików .rake tworzy listę zadań. Rake służy do zadań ogólno administracyjnych, szczególnie tych bardzo złożonych, które się ze sobą wzajemnie łączą.

Aby uzyskać listę dostępnych zadań, które na ogół zależne będą od katalogu, w którym się znajdujesz, posłuż się poleceniem rake --tasks. Każde z zadań ma opis, w którym znajdziesz wszystko co istotne.

rake --tasks (in /home/developer/commandsapp) rake db:abort_if_pending_migrations # Raises an error if there are pending migrations rake db:charset # Retrieves the charset for the current environment's database rake db:collation # Retrieves the collation for the current environment's database rake db:create # Create the database defined in config/database.yml for the current RAILS_ENV ... ... rake tmp:pids:clear # Clears all files in tmp/pids rake tmp:sessions:clear # Clears all files in tmp/sessions rake tmp:sockets:clear # Clears all files in tmp/sockets

Przyjrzyjmy się kilku z tych około 80 zadań.

2.4.1 db: Bazy danych

Najbardziej podstawowe zadania Rake db: to migrate i create. Warto wypróbować wszystkie zadania migracji (up, down, redo, reset). Zadaniem przydatnym przy rozwiązywaniu problemów jest rake db:version, który wyświetla bieżącą wersję bazy danych.

2.4.2 doc: Dokumentacja

Jeśli chcesz się pozbyć lub przebudować, któreś z elementów dokumentacji Railsów, możesz posłużyć się zadaniami doc. “Odchudzenie” dokumentacji okażę się przydatne np. przy tworzeniu aplikacji na platformy osadzone (embedded platforms).

2.4.3 gems: Ruby gems

Możesz określić, z których gemów będzie korzystać twoja aplikacja, a rake gems:install zainstaluje je dla ciebie. Zaglądnij do pliku environment.rb, aby dowiedzieć się jak to zrobić przy pomocy dyrektywy config.gem.

gems:unpack rozpakuje gem, czyli skopiuje kod Gema do katalogu vendor/gems. W ten sposób zwiększysz objętość aplikacji, ale i znacząco uprościsz jej instalacje na nowych hostach, eliminując konieczność uruchamiania rake gems:install, czy wyszukiwania i instalacji gemów potrzebnych dla działania twojej aplikacji.

2.4.4 notes: Wyliczenie linii kodu z dołączoną notatką

Te zadania przeszukają twój kod w poszukiwaniu linii rozpoczynających się od notatki “FIXME”, “OPTIMIZE”, “TODO”, czy dowolnej przyjętej (jak XXX) i wylistuje je dla ciebie.

2.4.5 rails: Zadania frameworka Rails

Oprócz wspomnianego już zadania umożliwiającego rozpakowanie dodatkowych gemów, Rake daje ci także możliwość rozpakowania gemów samego frameworka. Znajdą się one w vendor/rails. Wywołując rake rails:freeze:gems rozpakujesz wersję, której aktualnie używasz, natomiast rake rails:freeze:edge rozpakuje najnowszą wersję Railsów (wersja edge).

Kiedy zamrozisz (freeze) gemy, Railsy będą używały w pierwszej kolejności kodu z katalogu vendor/rails zamiast gemów systemu. Możesz “odmrozić” Railsy poleceniem rake rails:unfreeze.

Po aktualizacji Railsów dobrze jest uruchomić rails:update, który zaktualizuje katalogi konfiguracji oraz skryptów. Zaktualizuje także dedykowane Railsowe javascript (takie jak np. Scriptaculous).

2.4.6 test: Testy Railsowe

Solidny opis testów jednostkowych znajdziesz w podręczniku Testowanie aplikacji railsowej

Railsy dostarczają zestawu testów zwanego Test::Unit. To właśnie dużej ilości testów Railsy zawdzięczają swoją stabilność.

Zadania test: pomagają w przeprowadzaniu różnego rodzaju testów, które, mamy nadzieję, napiszesz.

2.4.7 time: Strefy czasowe

Możesz wylistować wszystkie strefy czasowe znane Railom, za pomocą polecenia rake time:zones:all. Jest to zadanie bardzo przydatne w codziennej pracy.

2.4.8 tmp: Pliki tymczasowe

Katalog tymczasowy, podobnie jak w systemach uniksowych jest miejscem, gdzie przechowywane są pliki tymczasowe, jak np. pliki sesji, czy przechowywane w pamięci cache akcje. Zadania tmp: pomogą ci pozbyć się zbędnych plików tymczasowych lub pomogą je stworzyć.

2.4.9 Pozostałe zadania
rake stats wyświetla statystyki dotyczące kodu, takie jak KLOC (ilość linii kodu liczona w tysiącach) oraz stosunek “code to test ratio”. rake secret wygeneruje pseudo losowy klucz, którego możesz użyć w mechanizmie sesji. rake routes wylistuje zdefiniowane drogi routingu. Jest zadanie bardzo przydatne przy analizowaniu problemów routingu. Poza tym przedstawia solidną listę adresów URL twojej aplikacji.

3 Changelog

Lighthouse ticket