- 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.

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.


$ 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.

W sumie nic dziwnego, języki rozwijają się, dołączone do nich biblioteki rosną w postępie logarytmicznym. Poza tym znajomość języka to raz, a znajomość konkretnego frameworka to dwa. Dając ogłoszenie o programisty JSF jakoby normalny staje się fakt, że potrafi on Javę samą w sobie.

Można by było przypuszczać, że obecny trend zmierza do jeszcze większej specjalizacji. Jednak tak nie jest. Znajomość frameworka czy narzędzia nadal pojawia się w ogłoszeniach. Jednak oprócz nich pojawiają się wymagania dotyczących technologii nie związanych bezpośrednio z językiem, np. AJAX. Przecież możemy wykorzystywać go zarówno w aplikacjach javowych, php-owych, rails-owych czy też innych. Poniżej przedstawiam listę nowych wymagań stwianych w ofertach pracy. Wg mnie technologie te staną się w ciągu kilku najbliższych lat bardzo ważne, więc zapoznanie się znimi już dziś może nam ułatwić poszukiwania pracy.

1. Widgety, Gadgety

Wiele stron i mechanizmów umożliwia wykorzsytywanie tych mini aplikacji. Widgety to jakby aplikacje wewnątrz innych aplikacji, które potrafią żyć własnym cyklem nie ingerując w mechanikę strony. Za to dodają witrynie wiele nowych finkcjonalności, których napisanie zajęłoby nam sporo czasu.

2. Integracja z serwisami społecznościowymi

Serwisy społecznościowe rosną jak grzyby po deszczu. Jedne bardziej popularne drugie mniej. Jedne oferują więcej usług i możliwości inne odwrotnie. W każdym razie już coraz mniej witryn można spotkać, które nie mają chociaż jednej malutkiej integracji z takim portalem społecznościowy. Wiele takich integracji z resztą polega na dodaniu do strony widgetu wspomnianego w punkcie pierwszym. Przeglądając witrynę spójrzmy, czy nie ma tam linka do takich serwisów jak Twitter, Blip, Flakier, Wykop, Dig-it, delicious czy też innych.

3. SEO

SEO jest ważnym elementem pozycjonowania strony więc wiedza na ten temat jest coraz bardziej wymagana.

4. Aplikacje mobilne IPhone & Android

iPhone zrewolucjonizował rynek telefonów, uczynił rewolucję, która podłączyła wielu użytkowników do internetu. Przeglądamy strony jadąc tramwajem, słuchamy radia internetowego, czy też gramy w gry online. Oferty pracy dla programistów iPhone’a czy Androida pojawiają się coraz częściej. Moim zdaniem Android będzie się rozwijał szybciej bo nie jest blokowany jak to ma się z telefonem od Apple.Dostęp do tej technologi jest łatwiejszy, więc rynek będzie szedł w tą stronę.

aha! Poszedłem więc do /usr/local i zrobiłem link symboliczny
sudo ln -s mysql* mysql
Po ponownej próbie uruchomienia bazy danych otrzymałem komunikat:
Starting MySQL database server
Czyli wszystko ok.

Większość projektów nie jest prowadzona samodzielnie, jest w niego zaangażowane kilku (-nastu, -dziesięciu) innych programistów. Każdy z nich może lokalnie prowadzić własną ścieżkę, ale z doświadczenia wiem, że przydaje się jedno wspólne repozytorium. Punkt centralny dla naszej pracy.

Inicjalizacja repozytorium

Przypuśćmy, że posiadamy serwer w domenie projekty.pl i tam chcemy założyć nasze centralne repozytorium. W tym celu logujemy się na naszym serwerze:

 > ssh projekty.pl 
cd /repos
mkdir gittutor.git
cd gittutor.git
git --bare init
exit

To wszystko. Wszystkie powyższe komendy za pewne są jasne, tylko jedna może nasuwać pewne niepewności:

 git --bare init

Co daje nam atrybut –bare? Otóż w naszym zdalnym repozytorium nie potrzebujemy kopii plików projektu tylko samą informację o repozytorium. To właśnie robi atrybut –bare – tworzy strukturę plików repozytorium, do którego możemy się połączyć tylko zdalnie bez plików projketu wewnątrz.

Po wylogowaniu się z naszego serwera wracam do naszego projektu na lokalnym komputerze.

 > cd /projekty/gittutor

który jest już pod kontrolą wersji. Wydajemy komendę:

 > git remote add centrala ssh://projekty.pl/repos/gittutor.git

git remote add

dodaje nowe zdalne repozytorium,

 centrala

nasza nazwa tego zdalnego repozytorium,

 ssh://projekty.pl/repos/gittutor.git

url do tego zdalnego repozytorium.

Sprawdźmy, czy dodano nasze zdalne repozytorium:

 > git remote show centrala
* remote centrala
  URL: ssh://projekty.pl/repos/gittutor.git
  HEAD branch: (unknown)

Wysyłanie plików na zdalny serwer

Do synchronizacji lokalnego repozytorium ze zdalnym wykonujemy za pomocą komend git push oraz git pull. Spóbujmy wysłać pliki do naszego zdalnego repozytorium:

 > git push centrala master

Jako pierwszy argument podajemy nazwę zdalnego repozytorium, jako drugi lokalny branch, który ma być wysłany.

Counting objects: 32, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (22/22), done.
Writing objects: 100% (32/32), 2.72 KiB, done.
Total 32 (delta 4), reused 0 (delta 0)
To ssh://projekty.pl/repos/gittutor.git
 * [new branch]      master -> master

W ten sposób umieściliśmy nasz projekt w zdalnym repozytorium.

Klonowanie repozytorium

Teraz gdy nasze pliki znajdują się w zdalnym repozytorium możemy je w prosty sposób sklonować (np. dla nowego członka zespołu pracującego nad projektem).

 > git clone ssh://projekty.pl/repos/gittutor.git
 
Initialized empty Git repository in /projekty/gittutor2/gittutor/.git/
remote: Counting objects: 32, done.
remote: Compressing objects: 100% (22/22), done.
remote: Total 32 (delta 4), reused 0 (delta 0)
Receiving objects: 100% (32/32), done.
Resolving deltas: 100% (4/4), done.
 
cd gittutor
git remote show
 
origin

“origin” jest domyślną nazwa nadawaną dla zdalnego repozytorium. Zauważmy, że po klonowaniu w naszym projekcie jest ustawione zdalne repozytorium (to z którego klonowaliśmy pliki) – nie musimy tego robić ręcznie.

Praca ze zdalnym repozytorium

Sprawdźmy jeszcze jeden ciekawy scenariusz – jeden z programistów zakłada własny projekt od zera i synchronizuje go z naszym zdalnym repozytorium.

> mkdir gittutor3
cd gittutor3
git init
git remote add origin ssh://projekty.pl/repos/gittutor.git
 
echo "plik2" > nowy_plik.txt
git add nowy_plik.txt
git commit -m "Dodano nowy plik"
[master (root-commit) 577763f] Dodano nowy plik
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 nowy_plik.txt

Co zrobiłem? Utworzyłem nowy katalog, dodałem go do kontroli wersji (’init’) ustawiłem zdalne (dobrze nam znane ) repozytorium. Następnie dodałem plik i skommitowałem go do lokalnego repozytorium.
Teraz musimy wysłać naszego brancha na serwer. Po nazwie lokalnego musimy podać nazwę pod jaką nasz branch będzie widniał w zdalnym repozytorium (po dwukropku)

> git push origin master:fajny_projekt
 
Counting objects: 3, done.
Writing objects: 100% (3/3), 223 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To ssh://projekty.pl/repos/gittutor.git
 * [new branch]      master -> fajny_projekt

Teraz przełączmy się do folderu z którego rozpoczęliśmy pracę

 cd ../gittutor 
> git remote show centrala
 
* remote centrala
  URL: ssh://projekty.pl/repos/gittutor.git
  HEAD branch: master
  Remote branches:
    fajny_projekt new (next fetch will store in remotes/centrala)
    master        tracked
  Local ref configured for 'git push':
    master pushes to master (up to date)

Widać, że zdalny branch jest widoczny – jednak w jaki sposób się na niego ‘przełączyć’? Najpierw musimy zaktualizować nasz mirror zdalnego repozytorium:

 > git fetch centrala
Unpacking objects: 100% (3/3), done.
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
From ssh://projekty.pl/repos/gittutor
 * [new branch]      fajny_projekt -> centrala/fajny_projekt
 
git remote show centrala
 
* remote centrala
  URL: ssh://projekty.pl/repos/gittutor.git
  HEAD branch: master
  Remote branches:
    fajny_projekt tracked
    master        tracked
  Local ref configured for 'git push':
    master pushes to master (up to date)

aktualnie skopiowaliśmy zdalny fajny projekt do lokalnego repozytorium.
Można go zobaczyć na liście branchy

 > git branch -a
* master
  remotes/centrala/fajny_projekt
  remotes/centrala/master

Jeżeli teraz chcemy dokonać zmian na tym zdalnym repozytorium musimy utworzyć lokalnego brancha, który będzie śledził (tracking) ten zdalny.

 > git checkout --track -b fajny_projekt centrala/fajny_projekt
Branch fajny_projekt set up to track remote branch fajny_projekt from centrala.
Switched to a new branch 'fajny_projekt'

Utworzono lokalny branch pod nazwą ‘fajny_projekt’ ze zdalnego ‘centrala/fajny_projekt’ i od razu zaznaczono go jako aktywny sprawdźmy:

 > git branch -a 
* fajny_projekt
  master
  remotes/centrala/fajny_projekt
  remotes/centrala/master
 
> ls
nowy_plik.txt

Mam nadzieję, że wszystko jest zrozumiałe, jest późno – a o tej godzinie to czasami sam nie do końca wiem co piszę . W razie nieścisłości proszę o słówko w komentarzach.