09 maj 2006
Rails - wprowadzenie, część 1 - fundamenty
“Jeśli widziałem dalej niż inni, to dlatego, że stałem na ramionach gigantów.”– Isaac Newton
Witam wszystkich serdecznie w pierwszym polskim tutorialu Ruby On Rails. Dziś zaczniemy od spraw najbardziej podstawowych, w rzeczywistości nie dotkniemy nawet na chwilę samego przedmiotu naszych rozważań, lecz zajmiemy się za to czymś o wiele ważniejszym - fundamentalnymi ideami na których jest on zbudowany i bez których nie byłby tak genialny, jak moim zdaniem jest.
A więc, dlaczego kogoś wogóle miałby interesować Rails? Potencjalnych powodów jest wiele…
Oto kilka z nich:
- “Convention over configuration”, czyli “konwencja ponad konfiguracją” - Rails zamiast kazać Ci pisać 1000 linii xml’a, żeby skonfigurować framework zanim wogóle przystąpisz do tworzenia aplikacji, daje Ci domyślną konfigurację, wyekstrahowaną z tego, czego używa się najczęściej, a dostosowuje się ją do swoich potrzeb, nadpisując wartości domyślne. Możesz dzięki temu zacząć pisać aplikację o wiele wcześniej i o wiele łatwiej. Właściwie na konfigurację poświęca się tak mało czasu, że wogóle się jej nie zauważa.
- Separacja i integracja. “Rails” to właściwie tylko nazwa dla całej rodziny komponentów, jakby oddzielnych frameworków, które razem dostarczają programiście wszystko czego potrzebuje, żeby produktywnie tworzyć aplikację sieciowe. To jedna z rzeczy, z którymi olbrzymi problem miała, a częściowo pewnie ma nadal Java - “posklejanie” własnej aplikacji, gdy osobny framework zajmuje się mapowaniem bazy danych na obiekty, osobny MVC, a jeszcze inny logowaniem, może być bardzo, bardzo, bolesne, o czym nie jeden miał się okazję przekonać. W Rails dostajemy od razu pełen pakiet i rzadko kiedy będziemy zmuszeni sięgać do jakichś dodatkowych rozwiązań. Dzięki temu całość jest spójna i mocno “zintegrowana”, w pozytywnym tego słowa znaczeniu. Jednocześnie wszystko jest tak dobrze zmodularyzowane, że z powodzeniem można używać poszczególnych komponentów osobno np. użyć ActiveRecord w normalnej aplikacji desktopowej, która potrzebuje korzystać z bazy danych np. do zachowywania stanu obietków pomiędzy uruchomieniami programu (serializacji).
- Dynamika na wiele sposobów i znaczeń. Po pierwsze - nigdy więcej restartowania serwera. W Rails wszystkie zmiany natychmiast znajdują odzwierciedlenie w już działającej aplikacji, sytuacje w których trzeba ponownie uruchomić serwer zdarzają się sporadycznie. Po drugie - AJAX, po raz pierwszy programista może pisać dynamiczne aplikacje ala Web 2.0 często nawet bez dotykania JavaScriptu, korzystając z dobrodziejstwa generatorów Rails.
- “Zwinność” (agillity). W roku 2001 grono ludzi, którzy jeśli idzie o programowanie są dla mnie zdecydowanie wielkim autorytetami, stworzyło “Aglie Manifesto”. Kent Beck, jeden z twórców eXtreme Programming, Martin Fowler, człowiek który wynalazł “Refactoring”, Ward Cunningham, ojciec-założyciel orginalnej i najlepszej Wiki, Dave Thomas, któremu wciąż jestem winien 30$ za moje “Programming Ruby”… ;) Przesłanie manifestu są proste - my, niżej podpisani zawodowi programiści, chcemy dostarczać produkty o jak najwyższej jakości na czas, a że wymagania klientów ciągle się zmieniają, nasze oprogramowanie musi być zawsze gotowe na zmiany. Służy temu zestaw praktyk, z których jedynie część ma bezpośredni związek z komputerem - regularne wypuszczanie kolejnych wersji programu, dokładnie testowanie modułowe i funkcjonalne wszystkich komponentów itp. itd.. Rails znakomicie wspiera ten model programowania, np. testowanie jest już weń wbudowane.
- Ruby pod podszewką. Ruby jest wspaniałym językiem i Rails używa go wszędzie. Tworząc aplikacje w Rails, będziesz używał go nie tylko do właściwego programowania, ale też do opisu struktury bazy danych i zmian tej struktury, do wszelakich konfiguracji, do tworzenia view, do opisywania relacji pomiędzy modelami itp. itd. Koniec pisania setek linii XMLa, żeby połączyć się z bazą danych.
Nie są to bynajmniej jedynie moje rozpływy, sporo ludzi poznała się na Rails, jak to bywa w Internecie powstało coś na kształt “wirusa” i na dziś dzień anglojęzyczny łeb aż roi się od materiałów na ten temat. Sam autor Railsów doczekał się tytułu “Hackera Roku” od OReilly, a nawet skejtowskiego ficzuringu w BusinessWeek’u.
Ale to wszystko nieważne. Ważne, że obecnie mamy dojrzałe Rails 1.1, z olbrzymią społecznością użytkowników, paroma książkami na ich temat i kilkunastoma w druku, z ludźmi używającymi ich komercyjnie. Polska, jak to niestety nieraz bywa, jest w tym względzie nieco sto lat za murzynami, ale czy to ma powstrzymać nas, młodych, dynamicznych programistów ;) ?
Koniec żartów - mam nadzieje, że ta długa lista pochwał zainteresowała Was, Drodzy Czytelnicy, choć trochę, teraz zaś przyjrzyjmy się absolutniej podstawie Rails - wzorocowi projektowemu Model View Controller, w skrócie MVC.
Celem MVC jest podzielenie aplikacji na trzy komponenty, jak nie trudno się domyślić są to: Model, View i Controller.
Model zajmuje się tylko wyłącznie reprezentacją (model-owaniem) danych, na których nasza aplikacja będzie operować i relacjami pomiędzy tymi danymi. Niektórzy nazywają to “logiką biznesową”. Przykładowym modelem może być “Użytkownik” - klasa go reprezentująca będzie miała np. pola nazwa, imie, nazwisko, haslo, wiek itp., a przy zapisywaniu do bazy danych będzie się upewniała że hasło nie jest puste (walidacja, przynajmniej w Rails, jest cześcia modelu). Przeważnie jeden model odzwierciedla jedną tabele w bazie danych.
Funkcją Widoku jest wizualne przedstawienie danych zawartych w modelu. Przeważnie jest to albo strona w HTML pomieszanym z jakimś językiem do pisania szablonów (w naszym przypadku po prostu z Rubym) albo graficzny interfejs użytkownika (w nie-railsowych zastosowaniach MVC).
Co kontroluje Kontroler? Oczywiście komunikacją pomiędzy Widokiem, a Modelem. Odpowiada on na akcję użytkownika, odpowiednio manipulując Modelem i wybierając odpowiedni Widok w zależności od sytuacji. Kontroler jest niejako “centrum dowodzeniowym”, całej aplikacji.
Wzorzec ten zadebiutował pierwotnie w środowisku Smalltalka i był stosowany głównie do pisania aplikacji GUI. Ponownie użyteczny okazał się gdy świat zaczął fascynować się programowaniem aplikacji Internetowych - i dziś praktycznie zmonopolizował “rynek” tychże. Większość poważnych aplikacji zostało zbudowanych na takim czy innym “frameworku” (albo nawet na dwudziestu frameworkach), ale prawie zawsze framework ten jest oparty na MVC.
Podział Rails na komponenty częściowo odzwierciedla MVC, mamy więc:
Active Record - czyli część odpowiedzialną za Model, zapewniającą komunikację z bazą danych itp.
Action Pack - oferujący Widok i Kontroler
Action Mailer - realizujący obsługę poczty elektronicznej
Action Web Service - pozwalający na tworzenie “Web Services”, czyli wyeksportowanie części funkcjonalności twojej aplikacji innym użytkownikom/programistom/programom/whatever.
Prototype - biblioteka w JavaScript, realizująca te wszystkie Ajaxowe cudeńka.
Do pełni developerskiego szczęścia potrzebujemy poza wyżej wymienionymi jeszcze bazy danych, oraz opcjonalnie serwera www (możemy bowiem użyć wbudowanego WebRICKa). Wspierane bazy to: MySQL, PostgreSQL, SQL Lite, MS SQL Server, DB2, Oracle… Wybór serwera jest prostszy i sprowadza się generalnie do dwójki Apache/LightTTPD. Konfiguracją całego tego stuffu zajemiemy się w odcinku numer 2.
No i pozostaje rzecz ostatnia - religijny wręcz wybór środowiska pracy. Od siebie, jak zwykle polecam Emacsa (do którego świetny tutorial piszę Martinez), z innych sensownych opcji można popatrzeć na JEdit’a, RadRails oparte na Eclipse, lub jeśli ktoś MOXuje TextMate.
Na dziś to tyle, w części #2 przyjrzymy się konfiguracji naszego środowiska pracy i może zaczniemy nawet tworzyć jakąś małą aplikacyjkę…
Dodaj do del.icio.us | Dodaj do wykop.pl
Komentarze ():
Cudi, 24 kwiecień 2006, 9:04 pm
Przede wszystkim gratuluje podjęcia się szczytnej inicjatywy i z niecierpiliwością wyczekuję na kolejne częsci.
Szkoda, że znów musimy gonić resztę świata. Wśród polskich programistów o RoR się mówi, każdy coś o nim wie, pewnie wielu z nich coś tam nawet próbowało wyskrobać. Jedyny kłopot w tym, że z hostingiem u nas cięzko, co też skutecznie zmniejsza popyt na aplikacje pisane w Rails na naszym rynku. Przez to zacofanie firm hostingowych do dziś jestem zmuszony pisać w PHP 4 (to już rok czy dwa po premierze PHP 5?). A że w Railsie zakochałem się od pierwszego wejrzenia, jako framework wybrałem CakePHP, czyli przeniesienie idei przyświecających Railsowi w realia PHP. Nie jest to już to samo, na własnej skórze można się przekonać, dlaczego autor Railsa wybrał Ruby, a nie PHP (choć na początku chciał pisać w PHP). Ale narazie innego wyjścia nie mam, w Railsa mogę się bawić na localhoście…
Oczywiście warto się z Railsem zapoznać, warto o nim pisać. Im głośniej o nim będzie, tym szybciej będziemy mogli wykorzystać zdobyte w domowej piaskownicy umiejętności w aplikacjach z prawdziwego zdarzenia :)
konrad, 24 kwiecień 2006, 10:04 pm
sorry, ale czytal nie bede. znam sie co nieco na programowaniu, ale takie opisy jak powyzej wlasnie mnie odstraszaja. kupa technicznego zargonu, wyjetego z samego srodka jezyka, gdy tymczasem autor probuje zainteresowac tego jezyka poczatkiem. Slowa Model, Kontroler sa w tym momencie dla mnie abstrakcyjne i tylko rozpraszaja. Nie wiem o co chodzi
nomind, 24 kwiecień 2006, 11:04 pm
Niezla ‘zajawka’ kursu - po 12 godzinach pracy przed kompem poprzedzonych 4 godzinami snu przeczytalem Twoj wpis i mam ochote wypic kolejną (czwartą?) kawę i wziąć sie za Ruby !teraz! ;]
sztywny, 25 kwiecień 2006, 6:04 am
Cudi: Brak hostingu faktycznie jest problemem, ale cóż zrobić… Pozostaje co najwyżej serwerować się samemu :S
Konrad: Staram się tłumaczyć wszystko tak jasno jak tylko się da, żadnego żargonu “wyjętego z języka” raczej nie użyłem, co najwyżej trochę takiego specyficznego dla programowania aplikacji sieciowych, ale bez niego nieco trudno wytłumaczyć zalety Rails.
Nomind: Dzięki :)
wporzo, 25 kwiecień 2006, 9:04 am
Jak dla mnie swietny poczatek ! Gratuluje pomyslu i zycze jak najwiecej zapalu. Mi go brakuje, zeby sie z jezykiem zapoznac.. a tu prosze.. komus chce sie nawet opisac framework oparty na nim :) Moze dzieki temu tutorialowi i ja sie wreszcie za siebie wezme :))
Konrad: Jesli rzeczywiscie “znasz sie co nieco na programowaniu”, to ani jedno slowo uzyte w tym artykule nie powinno byc dla Ciebie problemem.
Nill, 25 kwiecień 2006, 3:04 pm
Ruby to genialny jezyk, z Railsem mialem do czynienia niewiele (hm, przerobilem ogolem te video tutoriale ze strony railsa ;p) ale Twoj kurs Sztywny bede sledzil z zaciekawieniem ;) Czekam na nastepne czesci, pozdro
Seban, 25 kwiecień 2006, 7:04 pm
I want more, more, more… ;-) Z zainteresowaniem czekam na kolejną część, ale nie śpiesz się - jakość przedewszystkim.
idoru, 1 maj 2006, 4:05 pm
Nie jest prawdą, że nie trzeba restartować serwera. Wręcz przeciwnie. To dla PHP nic nie trzeba restartować. Poza przypadkiem korzystania z ekstremalnie wolnego webricka (www na 1 procesie), który jest zalecany tylko i wyłącznie do pracy developerskiej, każda zmiana kodu w przypadku użycia FastCGI wymaga restartu całego serwera http://www.
sztywny, 1 maj 2006, 5:05 pm
Mowa była o niczym innym jak tylko o developmencie i WebRicku. Na serwerze produkcyjnym jest mi dokładnie wszystko jedno czy muszę restartować aplikację przy deployu, czy nie.
Nie wiem jak z Apache, ale lighttpd nie trzeba restartować, z tego co mi wiadomo.
idoru, 2 maj 2006, 12:05 am
Skąd masz informację że nie trzeba restartować Lighttpd? Przecież to moduł fastcgi, który jest częścią serwera. Podobnie jak dla Apache’a.
sztywny, 2 maj 2006, 7:05 am
Możesz poczytać tu: http://duncandavidson.com/essay/2005/12/railsonlighty - restartuje się samą aplikację, serwer cały czas chodzi dalej jak chodził.
Cogito, 9 maj 2006, 12:05 pm
Mi też część pierwsza bardzo się podoba. Również jestem
za tym, żebyś napisał w jaki sposób wykorzystywac Test::Unit
w Railsach. Tutorial do Ruby też świetny
p.c
sztywny, 9 maj 2006, 12:05 pm
Trochę ciężko przyrównywać Javę do Rails… ActiveRecord jest swoistym miksem pomiędzy JDBC, a Hibernate - zajmuję się zarówno połączniem z bazą danych, może wykonywać polecenia w SQL, ale też implementuje przechowywanie obiektów bazie. Stanie się to bardziej jasne, mam nadzieje, w dalszych częściach, jak tylko znajdę dość sił żeby je napisać :)
Of kors dziękuje za wszelkie komplementy :>
paweł, 9 maj 2006, 12:05 pm
Dzięki za zgrubne wyjaśnienie. Przyznam że Twój tutorial spowodował że mocno zainteresowałem się Railsami i Rubym. Rychłych kolejnych części życzę :)
wonder, 9 maj 2006, 10:05 pm
Zapowiada się ciekawie. Również czekam na dalsze części :) Jak na chwilę obecną RoR i sam Ruby wyglądają zachęcająco.
RaVbaker, 10 maj 2006, 9:05 pm
Ja zacząłem poznawać Ruby. Jako kolejny język który wydaje się być ciekawy. Ale Twój wpis zachęcił mnie do przyjrzenia się bliżej również RoR, więc z niecierpliwością czekam na kolejną część tutoriala… Gratuluję pomysłu i chęci… Tak trzymaj!
Agnieszka, 12 maj 2006, 12:05 pm
Supcio… czekam z niecierpliwoscia na kolejny odcinek “R jak RoR”
pozdrawiam
torcz, 13 maj 2006, 12:05 pm
Z tego wszystkiego zapomniałem się podpisać i post wyżej poszedł jako anonymous ;-)
Anonim, 13 maj 2006, 12:05 pm
Początek ciekawy :) Ja także zaczynam mocno interesować się Railsami. Póki co pisze trochę w Javie (w tym w Struts). Gorąca prośba do sztywnego, żeby opisał/wyjaśnił w kilku zdaniach właśnie ActiveRecord. Na czym taki “mix” (w porównaniu do JDBC, Hibernate) polega. No i jakiś prościutki unit test w Railsach też by się przydał. Czyta się w opisach Railsów że “testowanie mają praktycznie wbudowane”. Fajnie gdyby autor powstającego tutoriala to rozszerzył :) To oczywiście tylko propozycje i z góry dzięki wielkie jak napisze cokolwiek :):) Powodzenia i czekamy na dalszy ciąg.
paweł, 18 maj 2006, 4:05 pm
Ja tak delikatnie tylko zapytam ;-) Jak tam prace nad kolejną częścią tutoriala do RoR? :)
Adam, 20 maj 2006, 10:05 am
Moim zdaniem minimum następnej części poświęć na opis instalacji Ruby Railsów. Jest to opisane już w wielu miejscach i szkoda na to kolenego wprowadzenia. Tym bardziej że pod różnymi dystrybucjami linuksa robi się to różnie, a pod Windows jest prosty installer. Rubygems to też chyba oczywista sprawa. Lepiej pokazać jak klepnąć prostą aplikację z użyciem “scaffold”, na czym polega “belongs_to”, czy “has_many”. Pokazać na prostym przykładzie co ma takiego rails w porównaniu do PHP, czy Javy w kwestii MVC co powoduje ze taką aplikację tworzy się szybciej. Czekam również na część kolejną i życzę powodzenia!
sztywny, 21 maj 2006, 3:05 pm
Jak pisałem na początku wprowadzenia do Ruby’ego - następny odcinek będzie, jak będzie. Jak widać wena raz jest, raz jej nie ma, po tych już prawie dwóch latach blogowania wygląda na to że tak już jest i nic na to nie poradzę… Tak czy inaczej, dalsze części będą napewno, jak się nie uda teraz, to najpóźniej w czerwcu, jak szkoła już poluzuje trochę.
ludwikc, 28 lipiec 2006, 10:07 pm
“z hostingiem u nas cięzko… ”
a są jakieś wogóle?
sztywny, 29 lipiec 2006, 6:07 am
Ciężko, znaczy - hostuj sobie sam albo szukaj wujka w Ameryce :D Był kiedyś wątek o tym na http://www.rubyonrails.pl i niektóre firmy ponoć ofiarują się zainstalować na życzenie klienta (za odpowiednią opłatą), albo twierdzą że w przypadku większego zainteresowania się tym zajmą.
janekw, 4 sierpień 2006, 12:08 pm
Albo są tu dwa tutoriale z czego jeden (niniejszy) dopiero się zaczął, albo to jeden tutorial z dwoma pierwszymi odcinkami. Czepiam się tylko;>
RaVbaker, 8 grudzień 2006, 8:13 pm
Sztywny, i co z tutorialem do Railsów? Będziesz w ogóle kontyunuował?
sztywny, 8 grudzień 2006, 8:53 pm
Szczerze mówiąc - wątpie, przynajmniej nie teraz… Pisanie tutorialów jest niezbyt przyjemne, a mam sporo pomysłów z większym priorytetem niż akurat ta seria i cały czas kompletny brak czasu (mimo GTDowania na potęge ;)). Niemniej jednak wypadałoby dokończyć, może na emeryturze :D ?