Ciekawy, bo jestem natywnym programistą Java, który kojarzony jest właśnie z enterprise.
Mimo ciekawości powstrzymywałem się od zakupu tej książki, z kilku powodów. Po pierwsze oryginalna wersja została opublikowana w 2008 roku więc jest już dość leciwa biorąc pod uwagę szybkość rozwijania się frameworka Rails. Po drugie lada dzień wspomniany framework zostanie opublikowany w wersji 3.0, który wprowadza wiele rewolucyjnych zmian. Bałem się po prostu, że książka ta stanie się nieaktualna już w momencie zakupu.
Szczęśliwym trafem stałem się posiadaczem kupony, który musiałem zrealizować w jednej z trójmiejskich księgarni danego dnia. Będąc jednak w środku zupełnie nie byłem zachwycony zawartością półki (a raczej półeczki) opatrzonej tabliczką “Informatyka”. Większość tytułów to były podręczniki szkolne, które jak na razie jeszcze mnie nie interesują (zainteresują jak dzieciaki pójdą do szkoły ). Jedyną pozycją nadającą się do kupna był wymieniony wyżej tytuł. Nie mając większego wyboru kupiłem tą książkę.
Obawy co do nieważności książki były tak duże, że o mało co, nie wylądowała na półce bez czytania. No ale skoro książka już jest to chociaż pierwszy rozdział… i tak już do końca.

Moje obawy stały się w pełni niesłuszne. Książka porusza problemy “okołoprogramistyczne” i jeżeli już w niej natkniemy się na fragmenty kodu, to łatwo go zaadaptować do nowej wersji Rails. Co więcej – po przeczytaniu książka awansowała w moim osobistym rankingu z “książki do starych wersji, częściowo nieaktualne” do “książki, które powinny być pod ręką albo w pamięci”.
Lektura tej książki dostarczyła mi bardzo dużo przydatnych informacji. Co w środku:

Pierwszą rzeczą, której nauczyłem się z książki było pisanie nowych funkcjonalności i wprowadzenie ich do projektu w postaci gemów. Nie ukrywam, że jestem początkującym programistą Ruby’ego i ten rozdział przyniósł mi dużo wiedzy na ten temat. Niezamierzenie przez autora przyniósł mi także sporo wiedzy o Ruby reflection.

Kolejnym tematem w książce są bazy danych i ich optymalizacja. Poruszane jest tu na prawdę dużo ciekawych tematów, walidacja na poziomie baz danych, normalizacja, triggery, korzystanie z “widoków bazodanowych” w aplikacji. Opisane jest także dziedziczenie wielotabelarczyne, które dostarczyło całkiem nowe spojrzenie na railsy. Wiele razy spotkałem się z problemem, które zdają się błahe po przeczytaniu tego rozdziału. Myślę, że dla samego opisu dziedziczenia wielotabelarycznego warto zaopatrzyć się w tą pozycję.

Kolejne rozdziały opisują webservices i jak z nich korzystać efektywnie, oraz problemy cache’owania aplikacji.

Myślę, że książka ta powinna znaleźć się na półce każdego programisty Rails. Mimo, że na wiek książki nie wszystkie (jednak..) informacje są aktualne, jest ich na prawdę niewiele. Reszta w całości lub w części może być śmiało zastosowana w naszym projekcie, aby zwiększyć jego bezpieczeństwo lub optymalne działanie.

Podobne wpisy:

• 25.08.2010 -- Vim on Rails
• 25.08.2010 -- Najlepszy edytor do Rails (czyli dlaczego Vim a nie Textmate)
• 07.08.2010 -- Capture model w Pickle

1. Podstawy efektywnego programowania
2. opis pluginu rails.vim
3. Opis pluginu Snipmate
4. Tags, i ich efektywne wykorzystanie
5. kilka słów o wyszukiwaniu
6. jak edytować jeszcze szybciej

Wg mnie screencast powinien być obejrzany zaraz po podstawowej nauce Vima. Filmik jest dobrze nakręcony i dobrze pokazuje jak programować w railsach za pomocą tego edytora.

W związku, że vim jest coraz częściej wykorzystywany do pracy z rails, (sam Yehuda Katz przesiadł się na ten edytor) warto poświęcić te kilka dolarów aby zapoznać się z tym narzędziem.

Good work Ben!
It’s worth to spend few bucks to watch that great screencast. We can learn how to use this efficient editor for more efficient productivity with rails development.

Thanks A lot.

Dziękuję autorowi za udostępnienie screencasta.

Podobne wpisy:

• 25.08.2010 -- Najlepszy edytor do Rails (czyli dlaczego Vim a nie Textmate)
• 03.09.2010 -- Recenzja książki “Enterprise Rails”
• 02.09.2010 -- Vim – trochę więcej o rejestrach

Najpierw przeanalizujmy jakie narzędzia mamy do wyboru:
- Netbeans,
- Rubymine,
- Aptana,
- Textmate,
- Emacs,
- Vim,
- Redcar.

Nie znam innych narzędzi, które są wykorzystywane do tworzenia aplikacji w rails wśród moich znajomych.

Pierwsze trzy to typowe IDE z podpowiadaniem składni, debuggerami i innymi dodatkami. Można powiedzieć, że jest to wyższa klasa niż pozostałe. Nie będę porównywał który z nich jest lepszy. Napiszę tylko, że z pośród tych wszystkich zalet, które ze sobą niosą, mają jedną ale bardzo znaczną wadę. Nie wspierają wersji języka, czy też frameworku, dopóki autor edytora go nie zaimplementuje. Więc czasami musimy walczyć walkę z narzędziem a nie z samym frameworkiem.

Spójrzmy na pozostałem 4 edytory. Zacznijmy od ostatniego: redcar – dość ciekawa propozycja napisana w jruby, czyli międzyplatformowa. Niestety nadal jest w fazie alfa więc na razie nie ma co sobie głowy zawracać tym produktem. Poza tym jako jeden z głównych Feature’s wymieniana jest zgodność z bundlami Textmate’a. Czy to aż taka zaleta?

Pozostają 3. Znam Zarówno Emacsa jak i Vima, jednak ten drugi jest popularniejszy. Mają zbliżone funkcjonalności jednak Vima łatwiej rozszerzać o własne funkcje. Poza tym emacs ma 2,9mln wyników w google a Vim ponad 11mln – więc emacsem nie będziemy się zajmować.

Doszedłem do etapu, który sowicie zaplanowałem, porównanie Vim z Textmate. Sprawdźmy ze strony Textmate Główne cechy tego edytora i porównajmy go do VIma.:

Ability to Search and Replace in a Project

Sic! bzdura aby wypisywać coś takiego jako feature, nawet windowsowy notatnik coś takiego potrafi. Aby nie było – Vim także potrafi. Potrafi szukać w górę, w dół, wyszukuje zgodnie z regexpem.

Auto-Indent for Common Actions Like Pasting Text

Hm, ciekawe, w Vim proszę ustawić :set autoindent i po sprawie mamy to samo.

Auto-Pairing of Brackets and Other Characters

Dla przypomnienia z nauki Vima: % - przenosi na parujący znak. Czyli vim też to ma.

Clipboard History

Ha! Vim nawet ma tzw. nazwane rejestry gdzie możemy decydować do którego rejestru kopiujemy i z którego wklejamy. Historię też ma.

Column Selections and Column Typing

Mamy, mamy. Podstawowy vi tego nie ma, ale Vim wprowadza tryb wizualny, gdzie możemy zaznaczać tekst blokowo i pisać w kilku linijkach to samo.

Completion of Words from Current Document

Vim ma nie tylko autouzupełnianie z obecnego dokumentu, ale i z zewnętrznych, z historii, wklejanie całych linijek z obecnego dokumentu i trochę więcej.

Declarative Language Grammars for Graceful Mixing and Hacking

Vim potrafi sam rozpoznać, który syntax wykorzystywać po rozszerzeniu pliku. Dodatkowo, można w pliku konfiguracyjnym włączać lub wyłączać odpowiednie pluginy przy edycji poszczególnych plików.

Dynamic Outline for Working With Multiple Files

No dobra, Textmate w wbudowany drawer, w którym widać całe drzewko plików projektu. Vim tego nie ma, ale ma plugin NerdTree, który dodaje tą funkcjonalność.

Expand Trigger Words to Code Blocks With Tab-able Placeholders

Vim też tak ma, co prawda wbudowana werjsa :ab jest dośc uboga, ale pluginami takimi jak “sniepty” można już dużo zrobić.

File Tabs when Working With Projects

Vim has tabs. Dodatkowo może obszar zakładki podzielić na kilka części (bufery) i w każdej z nich edytować inny plik. Jeżeli zakładek i buferów zabraknie można otworzyć nowe okno.

Foldable Code Blocks

Vim posiada foldowanie zależne od rodzaju tekstu(np. kod), od wcięć, od markerów, różnic w pliku lub ustawiane ręcznie.

Function Pop-up for Quick Overview and Navigation

No dobra nie znalazłem popapu dla wyjaśnienia funkcji, ale korzystając z systemowej funkcji unixowej funkcji ctags możemy otworzyć wyjaśnienie funkcji w nowym buferze.

Plug-able Through Your Favorite Scripting Language

Vim has looooooots of plugins. Nie potrafię nawet obejżeć i przetestować ich wszystkich. Vim udostępnił wspaniałą architekturę do budowania pluginów i powstaje ich cała masa.

Recordable Macros With No Programming Required

Nie korzystałem z makr w Vimie, ale są.

Regular Expression Search and Replace (grep)

Wspomniano wyżej, jest coś takego w Vimi’e

Run Shell Commands from Within a Document

Może to zabrzmi dziwnie, ale Vim także to potrafi. Potrafi wykonać komendę, przełączyć się na chwilę do shella , może wkleić wynik shellowej komendy do dokumentu, a nawet potrafi zaznaczony fragment tekstu wrzucić jako argument komendy shellowej i wkleić zwrócony wynik.

Support for Darcs, Perforce, SVK, and Subversion

Vim nie ma wbudowanej obsługi SCM, ale można to rozbudować pluginami albo bezpośrednio uruchamianymi komendami shella.

Support for More Than 50 Languages

Vim posiada prawie 3200 pluginów wierzę, że wspiera więcej niż 50 języków.

Switch Between Files in Projects With a Minimum of Key Strokes

Z pluginem rails.vim łatwo się przełączać pomiędzy Modelem, Helperem, Controllerem, Widokiem i plikami testów. bardzo łatwo.

Themable Syntax Highlight Colors

Wow! bomba, w sumie jak by poszukać, to Vim też ma kilka schematów kolorów.

Visual Bookmarks to Jump Between Places in a File

W vimie nazywają się to Tagi.

Works As External Editor for (s)ftp Programs

Też tak potrafię, edycja przez sftp, scp. W którymś z kolejnym artykułów napiszę jak to zrobić.

Works Together With Xcode and Can Build Xcode Projects

Who cares about it! Nie ma to jak dobra reklama XCode. IMO XCode jest wyśmienitym edytorem Objective-C, do innych języków też się nadaje ale słabiej. Wg mnie to żadna zaleta, że potrafi budować projekty XCode przy odrobinie zaparcie idzie coś takiego zrobić applescriptem, pytanie tylko : Po co?

Co więcej?
Textmate pracuje tylko w systemie MacOS, Vim praktycznie na każdej platformie.
Textmate jest płatny i nie jest wspierany od dwóch lat.
Textmate ma bundle, które ułatwiają edytować kod. Vim ma snipety, które robią to samo.
Textmate jest ładny. Vim dla niektórych też.
“Jeżeli mam Textmate’a to znaczy że mam Mac’a i jestem cool”. Też mam Maca, a Textmate’a wywaliłem po dwóch dniach użytkowania.

Reasumując.

Wg mnie Textmate nie ma nic, co może mieć Vim. Za tym drugim stoi także dość spore community. I długie doświadczenie w realizacji projektu. Vim ma jeszcze jedną zaletę, jest wszędzie. Jeżeli jesteśmy nie tylko programistami ale trochę administratorami, to gdziekolwiek sie nie zalogujemy to vim prawdopodobnie tam będzie. Użytkownicy Textmate’a muszą się w takich sytuacjach uczyć drugiego edytora, aby poprawić zdalnie plik. Vim’owcy nie muszą.

Zatem kiedy możemy chcieć programować w Textmate:
- …myślę…
- …myślę…
- gdy… chcemy nakręcić screencasta i chcemy aby wyglądał jak tysiąc innych(musimy wtedy także zmienić tapetę na domyślną)
- gdy wchodzimy do zespołu gdzie inni z tego edytora korzystają.
- gdy mamy ochotę wydać 50Euro za coś co mamy za darmo od 1976 roku.
W innych przypadkach zalecam korzystanie z Vima. A jak skutecznie z niego korzystać przedstawię w jednym z kolejnych artykułów.

PS. Bez urazy ale jakbym miał wydawać tyle kasy to wolałbym dołożyć 42Euro i kupić rubymine’a. Niby prawie dwa razy więcej kasy, ale 5 razy więcej możliwości.

Podobne wpisy:

• 25.08.2010 -- Vim on Rails
• 03.09.2010 -- Recenzja książki “Enterprise Rails”
• 02.09.2010 -- Vim – trochę więcej o rejestrach

Problemem był Pickle. Okazuje się, że capture_model rozpoznaje modele po zdefiniowanych fabrykach lub blueprintach a nie po bazie danych, czy schemie. Po stworzeniu blueprinta dla mojego modelu wszystko zaczęło działać ponownie.

Podobne wpisy:

• 16.07.2010 -- Pickle na Rails3
• 03.09.2010 -- Recenzja książki “Enterprise Rails”
• 25.08.2010 -- Vim on Rails

Po pierwsze zniknęło słowo map, dobrze znane z poprzedniej wersji frameworka. Uprościło to trochę zapis. Np. w poprzedniej wersji taki zapis:

map.resources :posts do
    map.resource :comments
end

można teraz zapisać jako:

resources :posts do
    resources :comments
end

Routing podstawowy i nazwany

map.connect został zastąpiony w rails 3 metodą match. Dodatkowo w routingach nie podaje się już oddzielnie nazwy kontrolera i akcji. Zamiast tego oddziela się je znakiemm #. Dla przykładu routing z poprzedniej wersji frameworka wyglądający w ten sposób:

map.connect 'posts/:id', :controller => "posts", :action => "view"

przyjmie taką postać:

match 'posts/:id', :to => 'posts#view'

Jak widać zapis jest o wiele czytelniejszy. Pojawił się także nowy paramert :to, który został wprowadzony po połączeniu :action i :controller.

Metoda match została także użyta przy nazwanych routingach.
Routingi nazwane są to takie, które tworzą automagicznie helpery do wyświetlania odpowiednich adresów URL. Dla przykładu zapis:

map.logout '/logout', :controller => 'sessions', :action => 'destroy'

będzie wyglądał teraz tak:

match 'logout', :to => 'sessions#destroy', :as => 'logout'

Parametr :as oznacza nazwę, która zostanie użyta podczas tworzenia helperów. W powyższym przypadku: logout_path i logout_url.

Inny przykład użycia :as:

match 'users/show/:id', :as => 'profile'
# zapis w kontrolerze:
profile_path(current_user.id)

Drugim parametrem, którego można użyć wraz z match jest :via. Parametrem tym, określamy, które metody żądania HTTP są dostępne dla danego routingu.

match 'account/setup', :via => [:post, :get]

.
W przypadku, gdy ograniczamy wejście tylko do jednej metody, możemy użyć jej nazwy zamiast match

match 'account/setup', :via => :get
#jest jednoznaczne z:
get 'account/setup'

Rails 3 wprowadził także kilka skrótów, które możemy wykorzystać w jednoznacznych sytuacjach. Dla przykładu, możemy pominąć wspomniany wyżej parametr :to zamieniając oba parametry w mapę.

match 'logout', :to => 'sessions#destroy'
match 'logout' => 'sessions#destroy'

Oba powyższe przypadki są jednoznaczne.
Jeszcze większy skrót jest gdy mapowany url jest analogiczny do nazwy kontrolera i akcji, wtedy wogóle nie musimy określać punktu docelowego.

match 'sessions/destroy', :to => 'sessions#destroy'
match 'sessions/destroy' => 'sessions#destroy'
match 'sessions/destroy'

Wszystkie powyższe zapisy są analogiczne. Kierują wejście na ’sessions/destroy’ do kontrolera SessionsController i akcji destroy.

Route domyślny i segmenty opcjonalne

Ciekawostką wprowadzoną w Rails 3 są opcjonalne segmenty w routingu. Są to takie fragmenty adresu URL, które mogą wystąpić lecz nie muszą. Opcjonalne fragmenty są w zapisie umieszczone w nawiasach.
Najlepszym przykładem ich użycia jest route domyślny, który zmienił postać z:

map.connect ':controller/:action/:id'
map.connect ':controller/:action/:id.:format'

na:

match ':controller(/:action(/:id(.:format)))'

Jak widać powyżej parametry :action, :id i :format są opcjonalne.

Dodatkową przydatną informacją na temat domyślnego routingu jest fakt, że został on domyślnie wyłączony w Rails 3. Jeżeli chcemy użyć tego domyślnego mapowania musimy je odkomentować jednak nie jest to zalecane.

Routing główny

Routing główny jest często określany także pustym. Jest to mapowanie, które jest wyświetlane po wpisaniu w przeglądarce samej nazwy domeny, bez żadnych parametrów.
W rails 2 takie mapowanie jest określane za pomocą metody map.root. W obecnej wersji, pominięto map, więc wystarczy użycie metody root.
Stary zapis:

map.root :controller => "posts", :action => "index"

można w nowej wersji przedstawić w ten sposób:

root :to => 'posts#index'

Ponownie widać uproszczenie zapisu.

Zagnieżdżone zasoby

Niektóre modele w tworzonej aplikacji posiadają referencje do innych, referencje te są zdefiniowane poprzez użycie has_many lub has_one w definicji modelu. Na przykład:

class Post < ActiveRecord::Base
  has_many :comments
end
 
class Comment < ActiveRecord::Base
  belongs_to :post
end

Zagnieżdżony routing pozwala na dostęp do “niższych” zasbów bezpośrednio z URL’a, na przykład: /posts/2/comments/3 dostarczy komentarz o ID=3, który należy do postu o id = 2.
Aby taki routing był możliwy musimy go zdefiniować. Robimy t w ten sposób:

resources :posts do
  resources :comments
end

Po takiej deklaracji zostaną także utworzone odpowiednie helpery, np.:post_comments_path, edit_post_comment_path.

W przypadku jednak gdy helpery te są za długie, lub nie chcemy korzystać z modelu nadrzędnego możemy użyć opcji shallow, która pozwoli nam na bezpośredni dostęp do zagnieżdżonych zasobów.

resources :posts do
  shallow do
    resources :comments
  end
end

Od tej pory możemy używać /comments/2 zamiast /posts/2/comments/2.
Dla przypomnienia w rails 2 z tej opcji korzystało się w ten sposób:

map.resources :posts, :shallow => true do |post|
  post.resources :comments
end

Zasoby

Od czasów wprowadzenia definicji resources do routes, zaleca się z korzystania z tej metody. Tworzy ona helpery oraz zarządza odpowiednimi RESTowymi połączeniami z zasobami.
Aplikacja mapuje odpowiednio wszystkie CRUD’owe metody dla takiego zasobu(index, new, create, delete, update, show, edit).
W rails 3 możemy zrezygnować z niektórych (except), lub wskazać tylko te z których chcemy skorzystać (only):

resources :comments, :except => [:index]
resources :sessions, :only => [:new, :create, :destroy]

Więcej niż REST

Czasem wprowadzamy do naszych kontrolerów inne akcje, do których chcielibyśmy mieć dostęp z zewnątrz. Dodatkowe akcje definiujemy za pomocą metod collections i member zależnie czy chcemy manipulować zbiorem obiektów czy jedną sztuką.
W rails 2 pisaliśmy coś takiego:

map.resources :orders, 
  :collection => {
    :only_new => :get,
    :accepted => :get 
  },
  :member => {
    :change_status => :put
  }

teraz możemy pisać tak:

resources :posts do
  collection do
    get :only_new, :accepted
  end
  member do
    put :change_status
  end
end

lub tak:

resources :posts do
  get :only_new, :on => :collection
  get :accepted, :on => :collection
  put :change_status, :on => :member
end

Zmiana nazwy parametru żądania

W niektórych przypadkach, zwłaszcza w aplikacjach nieanglojęzycznych przydatna jest opcja zmiany nazwy akcji. Np. Chcielibyśmy ze względu na SEO aby w URL było używane “aktualizuj” zamiast “edit”. Możemy tego dokonać za pośrednictwem opcji path_names

resources :users, :path_names => {:edit => 'aktualizuj'}

Przekierowanie żądania

W rails 3 jest możliwe przekierowanie wejścia z jednego żądania na inne

match '/profile', :to => redirect('/users/show')
#albo
match '/profile/:username' => redirect('/users/show/%{username})

Ograniczenia

W routes.rb jest możliwość wprowadzenia ograniczeń co do żądania, np. ID może składać się tylko z pięciu cyfr lub podobne.

resources :users, :constraints => { :id => /\d{5}/ }
#lub w przypadku gdy takie ograniczenia są wspólne dla kilku zasobów:
constraints(:id => /\d{5}/) do
  resources :users
  resources :posts
end

To nie wszystkie nowości, które zostały wprowadzone w Rails 3, pozostały do opisania np. uruchamianie aplikacji bezpośrednio na racku lub inne perełki. Mam nadzieję jednak, że da to ogólny wgląd w nadchodzące zmiany.

Podobne wpisy:

• 16.07.2010 -- Pickle na Rails3
• 03.09.2010 -- Recenzja książki “Enterprise Rails”
• 25.08.2010 -- Vim on Rails

Podczas przygotowywania środowiska jednak napotkałem na jeden problem. Gem, którego chętnie używam do testowania – Pickle – nie za bardzo chciał współpracować z rails 3. Problemem były generatory, których składnia w nowych railsach trochę się zmieniła. Znalazłem jednak rozwiązanie, polecane nawet przez samego autora. Otóż należy użyć forka projektu zrobionego prze codegrama, który rozwiązał ten problem. Jak to zrobić?

1. W pliku Gemfile, wskazać repozytorium git, z którego korzystamy podczas instalacji.

gem 'pickle', :git => "git://github.com/codegram/pickle.git"

2. Zainstalowanie gemów z bundlera.

bundle install

3. Uruchomienie generatów Pickle:

rails g pickle:skeleton --path --email

Atrybuty

--path i --email

są opcjonalne, ale polecam ich użycia.

Podobne wpisy:

• 07.08.2010 -- Capture model w Pickle
• 29.07.2010 -- Routing w Rails 3, nowości
• 05.03.2010 -- Rails Template

- inicjuje repozytorium Git, dodaje niektóre miejsca i pliki do ignore’a po czym zatwierdza resztę.

- instaluje platformę testową RSpec, RSpec-Rails, Cucumber, Factory_Girl i Webrat.

- instaluje authologic i declarative_authorization,

- tworzy model do dodawania artykułów oraz cruda do niego.

- tworzy model użytkownika, ról  i sesji

- tworzy widoki dla artykułów, panel logowania i edycja profilu.

- tworzy dwie początkowe role: user i admin.

- nadaje uprawnienia:

- gość może czytać artykuły, założyć konto i się zalogować,

- użytkownik może się wylogować, dodać artykuł, edytować lub usunąć własny artykuł, edytować swój profil,

- admin może wszystko.

Planuję jeszcze nad kilkoma dodatkami, ale nie wiem jeszcze dokładnie co i jak. Muszę to przemyśleć. Jak na razie szablon tworzy to, co w prawie każdej aplikacji istnieje. Modele można rozbudować wg własnych potrzeb ale mamy już dobry punkt początkowy.

Zapraszam do testowania i wyrażania swoich uwag.

Podobne wpisy:

• 12.12.2009 -- Automatyczny start czyli Rails Templates
• 16.07.2010 -- Pickle na Rails3
• 11.12.2009 -- Objęcie kontrolą wersji Git nowej aplikacji Rails

rails my_app -m ~/szablon_startowy.rb

tak samo jak URI, możemy uzywać URL:

rails my_app -m http://marioosh.5dots.pl/szablon.txt

(powyższy plik nie istnieje więc nie testujcie )
ostatnim sposobem jest inicjacja szablonu przed odpowiednie zadanie rake z ustawienie zmiennej LOCATION:

rake rails:template LOCATION=~/szablon_startowy.rb

Jakie operacje możemy wykonywać w przygotowanym języku DSL? Może zacznemy od przykładu.
Zacznijmy od wykonania kilku operacji opisanych w poprzednim artykule, mówiącym o wprowadzeniu aplikacji rails pod kontrolę Git.
Przygotujmy nasz plik szablonu, ja go utworzłem w katalogu domowym i zapisałem go jako 5dots_template.rb
Kroki które powinniśmy wykonać:
- inicjalizacja Git,
- utworzenie pliku .gitignore w folderach tmp i log
- dodaniu kilku wpisów w głównym .gitignore.
Plik powinien wyglądać tak:

# 5dots_szablon.rb
git :init
git :add => "."
# teraz dodajemy pliki .gitignore do folderów tmp i log.
run "touch tmp/.gitignore log/.gitignore"
#oraz tworzymy plik .gitignore w głównym folderze z zawartością:
file '.gitignore', <<-GITIGNORE_FILE
.DS_Store
log/*.log
tmp/**/*
config/database.yml
db/*.sqlite3
doc/app
doc/api
GITIGNORE_FILE
 
# teraz pozostaje tylko zatwierdzenie zmian do repozytorium:
git :commit => "-a -m 'Initial commit'"

W powyższym przykładnie poznaliśmy kilka komend języka DSL dla szablonów, wyjaśniam po kolei:
- git odpowiada za komendy systemu kontroli wersji git,
- run uruchamia polecenia konsolowe.

run "rm -rf *"

(komenda ta robi porządki w folderze )
- file – odpowiada za tworzenie plików i operacje na nich.

Mając podstawy za sobą możemy przejść do szczegółowego opisania wszystkich poleceń, w końcu te trzy powyższe, może i zrobią dużo, to i tak nie wszystko.

Polecenie rake

Za wykonywanie zadań rake jest odpowiedzialna komenda o tej samej nazwie ,dodatkowo możemy uruchomić skrypt jako superużytkownik, wtedy musimy podać parametr :sudo => true. Dodatkowo możemy podać parametry, których możemy używać podczas ręcznego użycia komendy rake.

rake "gem:install"
# lub jako superuser
rake "gem:install", :sudo => true
# jeszcze jeden przykład:
rake "gem:install", :env => 'production'

Operacje na gemach

Komenda gem odpowiada za dodawanie gemów. Komenda dodaje odpowiedni wpis do pliku config/envoirnment.rb. Parametry, które mają być również dopisane (takie jak :version, :lib, :source) podajemy na końcu.
Komenda nie istaluje gema, do tego celu musimy użyć odpowiedniego zadania rake (zgadnijcie którego )
Kilka przykładów:

gem 'thoughtbot-factory_girl', :lib => 'factory_girl', :source => 'http://gems.github.com'
gem "hpricot", :version => '0.6', :source => "http://code.whytheluckystiff.net"
gem "RedCloth"

Instalowanie wtyczek (inaczej zwanymi pluginami)

Aby zainstalować pluginy używamy z komendy plugin(mam wrażenie, że się domyślaliście – ot taki prosty ten język, wszystko jest domyślnie proste)
Pluginy możemy instalować z svn, z gita lub z gita jako submoduły:

# instalowanie ze starego dobrego subversion:
plugin 'svnowy_plugin', :svn => 'svn://repozytorium/scieżka_do_plugina/trunk'
# albo z nowego, jeszcze lepszego gita:
plugin 'git_plugin', :git => 'git://github.com/scieżka_do_plugina.git'
# lub nawet jako submoduł gitowy (o tym będzie w następnym artykule)
plugin 'git_plugin', :git => 'git://github.com/scieżka_do_plugina.git', :submodule => true

Inicjalizery- czyli automatory, wewnątrz automatora

Jeżeli korzystamy z inicjalizerów, czyli skryptów, które są uruchamiane podczas startu aplikacji używamy komendy initialize. Właśnie ona, tworzy plik w folderze cofnig/initializers

initialize "nowy_object.rb", <<NOWY_OBJECT_CONTENT
class Object
    def nowa_metoda
        puts "Fajna ta nowa metoda, dobrze, że mogę z niej korzystać, zanim railsy się odpalą! ";
    end
end
NOWY_OBJECT_CONTENT

Dokładnie na tej samej zasadzie działają komendy lib i vendor, które tworzą pliki w folderach (odpowiednio) /lib i /vendor.

Pliki

Tworzenie nowych plików tworzymy na podobnej zasadzie jak poprzednia metoda, główną różnicą jest, że plik zostanie utworzony, wg folderu RAILS_ROOT a nie wewnątrz initailizers.

file "app/components/Klasa.rb", <<KLASA
class Klasa
end
KLASA

Komenda powyższa utworzy foldery app/components i umieści w nim plik Klasa.rb.

Zadania Rake

Komenda rakefile tworzy plik w folderze /lib/tasks

rakefile "clear_all.rake" do
    namespace :clear do
        task :all do
            puts "Usuwamy wszystko!!!!! "
        end
    end
end

Teraz to zadanie możemy uruchomić po wydaniu komendy: rake clear:all.

Generatory

Generatory możemy uruchomić komendą generate i podając listę argumentów. Możemy uzywać wszystkie generatory, które są standardowo w railsach, lub które uprzednio zainstalowaliśmy w formie pluginów lub gemów.

generate(:scaffold, "person", "name:string", "email:string", "password:string"
generate("rspec")

Uruchamianie skryptów powłoki

Jak już wspomniałem można tego dokonać za pomocą komendy run

run "rm -rf *"

Dodawanie rutingów

Jeżeli potrzebujemy dodatkowych wpisów w pliku /config/routes.rb wykonujemy je uruchamiając komendę route

route "map.root :controller => :person"

Zmiana folderu

Czasami wygodne jest przejście do innego folderu i w nim wykonanie kilku operacji, możemy to zrobić za pomocą komendy inside. Jako parametr podajemy folder docelowy i potem block.

inside "config" do
    run "cp database.yml database.orig.yml"
# linkowanie ustawień z innego projektu, bo oba mają działać na tej samej bazie
    run "ln -s /projekty/super_rails_app/config/database.yml database.yml"
end

Działanie zależne od odpowiedzi

Podczas wykonywania skryptu, możemy wprowadzić małą intekerakcję, np. zadać pytanie i zależnie od odpowiedzi wykonać dalej skrypt.
Na przykład możemy zapytać o nazwę pliku. W tym celu wykonujemy komendę ask.
W poniższym przykładzie pytamy sie o nazwę pliku dla pliku konfiguracji .yml. Skrypt również sprawdza, czy rozszerzenie zostało podane czy nie. jeżeli nie, to dodaje je do nazwy pliku.

file_name = ask("Podaj nazwę pliku konfiguracyjnego")
file_name << ".yml" unless file_name.index(".yml")
 
file "/config/" << filename, <<FILE_CONTENT
global_settings:
    color: #e343f3
    font-size: 14px
FILE_CONTENT

Istnieją również uproszczone wersje powyższej metody, jedna oczekuje na odpowiedź “yes” druga na “no”

gem "RedCloth" if yes?("Zainstalować gem Red Cloth?")
 
if no?("Zainstalować gem Blue Cloth?") 
    gem ask("Podaj nazwę gemu z edytorem, którym ma być użyty zamiast BlueCloth:")
else
    gem "BlueCloth"
end
# po wpisaniu 'no' zostanie uruchomione zapytanie o nazwe gem'a, w każdej innej sytuacji zostanie dodany BlueCloth

GIT – kochaj albo rzuć

Komenda git wykonduje komendy systemu kontroli wersji Git – jak nie trudno się domyśleć.

git :init
git :add => "."
git :commit => "-a -m 'Initial commit'"
git :submodule => "init"

Rezume

Lista komend do wykorzystania:

 
gem(nazwa, options={})
plugin(nazwa, options={})
initializer(nazwa_pliku, data=nil, &block)
lib(nazwa_pliku, data=nil, &block)
vendor(nazwa_pliku, data=nil, &block)
rakefile(nawa_pliku, data=nil, &block)
generate(co_generować, argumenty)
run(komenda)
rake(komenda, options={})
route(routing_code)
inside(folder)
ask(pytanie)
yes?(pytanie)
no?(pytanie)
git(parametry)

Teraz znająć już wszystkie komendy, możemy tworzyć własne szablone jako startowe ustawienia aplikacji. Jeżeli stworzymy coś nowego i fajnego warto się tym podzielić. Moża dodać je do projektu: Rails Templates, który takie szablony zbiera. Możemy również skorzystać z instniejących tam szablonów.

Podobne wpisy:

• 05.03.2010 -- Rails Template
• 16.07.2010 -- Pickle na Rails3
• 11.12.2009 -- Objęcie kontrolą wersji Git nowej aplikacji Rails


$ rails my_app
$ cd my_app
$ git init
$ git status
...
# Untracked files:
# (use "git add ..." to include in what will be committed)
#
# README
# Rakefile
# app/
# config/
# db/
# doc/
# log/
# public/
# script/
# test/


Wydanie komendy git status pokazało nam całą strukturę aplikacji, która nie jest objęta kontrolą wersji. Zanim dodamy, powinniśmy wyłączyć kilka plików. Po pierwsze w repozytorium nie potrzebujemy plików dzienników („logów”), które znajdują się w folderze log. Aby je wyłączyć musimy stworzyć plik .gitignore i dodać linijkę log/*.log.

$ echo „log/*.log” >>.gitignore

Ponowne sprawdznie statusu pozwoli nam zauważyć zmianę, która zaszła w repozytorium.


$ git status
…
# Untracked files:
# (use "git add ..." to include in what will be committed)
#
# .gitignore
# README
# Rakefile
# app/
# config/
# db/
# doc/
# public/
# script/
# test/
nothing added to commit but untracked files present (use "git add" to track)

Folder log zniknął z listy plików do dodania. Problem polega na tym, że klonująć potem repozytorium, otrzymamy jest bez tego folderu. Gdy uruchomimy aplikację, będą problemy z jej działaniem, ponieważ w tym folderze logi muszą być zapisywane.
Naszym zadaniem zatem jest ustawienie repozytorium tak, aby sam folder znajdował się w nim, a ignorowana powinna być jedynie jego zawartość. Cała powyższa sytuacja dzieję się tak dlatego, że system Git nie śledzi pustych folderów. Wyjściem z tej sytuacji jest trick, polegającym na dodaniu pliku .gitignore w folderze log. Folder nie będzie pusty, a jednocześnie dodany plik, nie będzie miał wpływu na nasz projekt.


$ touch log/.gitignore
$ git status
…
# Untracked files:
# (use "git add ..." to include in what will be committed)
#
# .gitignore
# README
# Rakefile
# app/
# config/
# db/
# doc/
# log/
# public/
# script/
# test/
nothing added to commit but untracked files present (use "git add" to track)

Na powyższym listingu widać, że osiągnęliśmy zamierzony efekt. Podobny problem występuje w folderze tmp, którego zawartość również powinna być ignorowana, nie ignorując samgo folderu. Nauczeni powyższym doświadczeniem dodajemy plik .gitignore w tym katalogu, a w .gitignore znajdującym się w głównym folderze aplikacji dopisujemy tmp/**/*. Co oznacza ignorowanie wszystkich plików nawet w podfolderach.
Warto również zignorować dwa foldery z dokumentacją, które niepotrzebnie zajmują miejsce w repozytorium. Po dopisaniu dwóch linijek w głównym pliku .gitignore, powinien on zawierać taką treść:

log/*.log
tmp/**/*
doc/api
doc/app
Teraz możemy dodać wszystkie pliki i wykonać początkowe zatwierdzenie.

$ git add .
$ git commit -a -m „rozpoczęcie pracy”


W praktyce warto przenieść zewnętrzną bibliotekę rails, wewnątrz aplikacji, co pomoże w późniejszym uruchamianiu projektu na serwerze produkcyjnym. Aby to zrobić musimy wykonać komendę rake rails:freeze:gems co spowoduje przeniesienie całego frameworka, do folderu vendor/rails. Aplikacja przeszukuje ten folder w pierwszej kolejności i dopiero gdy go nie znajdzie, to szuka po zainstalowanych w systemie gemach.
Po wykonaniu powyższej komendy wystarczy zatwierdzić kolejną zmianę.

$ git add vendor
$ git commit -a -m „Dodanie frameworku do fodleru vendors”
Teraz nie pozostaje nic innego niż rozpoczęcie pracy nad projektem.

W sumie nie stoi nic na przeszkodzie, aby powyższy zaimplikować w Rails Template, ale o tym jak to się robi, napiszę już niedługo.

Podobne wpisy:

• 16.07.2010 -- Pickle na Rails3
• 05.03.2010 -- Rails Template
• 12.12.2009 -- Automatyczny start czyli Rails Templates