Karmi is on Rails - Vše

Od Karmi k Restafari

2008-10-31T08:16:00+00:00

Pojďte se rozloučit s blogem Karmi Is On Rails a dozvědět se, co nového se stalo ve světě Ruby/Rails za uplynulý rok!

Dobrá předsevzetí mají nejdelší život. Tak dlouho ležely nadesetinu až načtvrt připravené články v šuplíku, až autora život poučil, že už je nikdy nedopíše.

Když před rokem a půl publikoval první článek o Ruby on Rails na tomto blogu, neexistoval v Čechách (veřejný) spolehlivý Rails hosting. Jediné informace o Ruby a Rails byly bez kontextu, útržkovité nebo zastaralé. Neexistovalo fórum ani IRC kanál na výměnu zkušeností a kontaktů. Neexistovala setkání vývojářů v Ruby. Ani svobodný software v Ruby českého původu. Nikdo nepsal testy, leckdy protože nevěděl, že se nějaké testy pro webové aplikace píšou. Pro lokální vývojářskou komunitu bylo kromě několika výjimek Ruby on Rails nesrozumitelný úkaz, který je jim přece k ničemu, když „mají svoje PHP a tam to jde taky“. Až na to poslední :) se za tu dobu leccos změnilo. Proto je na místě alespoň ta nejmenší rekapitulace.

Rok a půl v Ruby a Rails

Čtyři články na tomto blogu tvoří (bohužel) stále neujucelenější informaci o Ruby on Rails v češtině. Pokud se chce někdo o Rails dozvědět, a začít s nimi, rozhodně má kde (přestože např. routing v Rails je nyní o pár světelných let dále). (Začínat s knihou lákavě nazvanou „Začínáme programovat v Ruby on Rails“ je dle oficiálního stanoviska Československého sdružení uživatelů programovacího jazyka Ruby rozhodně nedoporučeno :) Mission accomplished. Děkuji všem čtenářům, kteří mi napsali do komentářů nebo e-mailem!

Automatizované testování aplikací, jedna z nejdůležitějších součástí Rails a zároveň téma, které Rails pomáhaly svojí atraktivitou mezi webovými vývojáři propagovat, už není tou vysmívanou věcí „na kterou nemáme čas a peníze“. Už i v české Ruby komunitě se vedou spíše debaty kterou testovací strategii a technologii zvolit a nikoliv jestli testovat či netestovat. Přednášky o automatizovaném testování jsou obecně sice stále unheimlich, ale však „oni“ to i do toho Zend Frameworku nakonec dodělají a zase všichni popojedem :)

V Čechách nyní existuje přátelská a dosti rozmanitá komunita vývojářů v Ruby a Rails, která se pravidelně setkává v Praze, a tak kdokoliv z vás by chtěl o Rails zjistit více, může tak učinit i mimo virtuální svět internetu. Máte-li to do Prahy daleko, můžete většinu z nás pravidelně potkat na IRC kanále #rubyonrails (IRCnet).

Po konferenci Ostrava on Rails v roce 2007 proběhla v Praze následující rok mezinárodní konference o Ruby, EURUKO 2008. Ruby se vyučuje na Filosofické fakultě Univerzity Karlovy a na Unicorn College.

Čeští Ruby vývojáři se zapojili i do mezinárodní komunity a v Čechách vzniká dost open-source software. Zajímá-li vás pokrok v Rails za uplynulý rok, podívejte se určitě alespoň na k internacionalizační/lokalizační framework (I18n) — viz průvodce ve formě živé aplikace. Konkrétní způsob, jak integrovat Rails lokalizaci do vaší aplikace si můžete prohlédnout v ukázkové mini-aplikaci.

Rails jsou v obecném povědomí čím dál známější, i když stále jako ten „divný“ framework v tom „divném“ jazyce (který my se učit nebudem', když máme to svoje atd atd ). To ale vůbec nevadí. Síla Rails byla od začátku v něčem úplně jiném, než že jsou „tečka za webovými frameworky“. Nic takového nikdy Rails nebyly ani být nechtěly.

Síla Rails od počátku byla v tom, že nekompromisně implementovaly ty nejlepší z prakticky možných řešení pro webový vývoj. V počátku to bylo použití generátorů kódu a scaffolding, podpora pro automatizované testy, migrace databátového schématu, implementace Model—View–Controller průzračná jako sklo, bez „XML sklapovaček“. Posléze důsledně RESTful architektura. Jedna z posledních věcí je např. Rails podpora pro tzv. „conditional get“ neboli ETag, což je ultimátní řešení pro cachování webových aplikací, o kterém však mimo kruhy Rails vývojářů a často i v nich člověk slyší většinou jen „ETag? Co to je todle?“ Postupně však většina z těchto strategií a technologií prosakuje i do ostatních frameworků v jiných technologiích a webový vývoj se tak postupně skutečně vyvíjí a „vývoj“ nespočívá v tom že se maličko poladí „třída pro připojení k databázi“.

Právě implementace toho nejlepšího z webového vývoje podle hesla „představil jsem si chlápka chytřejšího než jsem já a pak jsem přemýšlel, co by udělal“, je tím, co autora tohoto blogu přimělo opustit teplé místo v internetové agentuře a vydat se opět na volnou nohu jako programátor v Ruby.

Od té doby celkem úspěšně „kudy chodí, tudy o Ruby mluví“ a lidi to zdá se baví. I když za to platí :) Např. autorova přednáška na konferenci WebExpo která proběhla před pár týdny, se setkala s velmi příjemným přijetím, a všem, které zaujala, patří jeho dík.

Prezentaci z ní si můžete prohlédnout níže a ukázkovou aplikaci stáhnout na serveru Github. (Zvažujete-li, co vám může přinést Ruby on Rails ve vaší společnosti nebo ve vašem podnikání, můžete si u autora blogu objednat školení Ruby on Rails -- jak obecný úvod do Rails, tak specializovaná témata nebo pokročilá školení na míru.)

To nejdůležitější: Hosting!

A nakonec to nejdůležitější. Z webové aplikace, která běží na http://localhost:3000 má člověk možná docela radost, ale moc se o ni nepodělí. Díky relativně složité struktuře toho, jak Rails aplikace běží na serveru na světě prakticky neexistuje Rails hosting „na zkoušku“ nebo „zadarmo“. Vynikající prostředí pro vývoj a zkoušení Rails, navíc cele v prostředí webového prohlížeče, poskytuje např. platforma Heroku. Ale nejedná se o plnohodnotný hosting.

V České republice existuje samozřejmě mnoho hostingů „podporujících“ Ruby, jen málokde ale sami provozovatelé těchto hostingů vědí, co si na své weby o „podpoře Ruby“ vlastně píšou. (Nebudeme citovat.) Před několika týdny ale společnost Kraxnet, provozovatel absolutně nejlepšího Rails hostingu v České republice, Railshosting.cz, spustila tzv. mod_rails verzi Rails hostingu, která je zcela zdarma. Úplně. Naprosto. Nyní můžete díky týmu Jiřího Kubíčka hostovat v Rails cokoliv chcete. I ty poslední, ufňukané výmluvy, proč si to nezkusit, zkrátka zmizely. Cítil-li by se snad někdo poškozen tvrzením o „nejlepším Rails hostingu”, nechť směle argumentuje v komentářích! :)

Railshosting zdarma si můžete registrovat na adrese http://free.railshosting.cz.

Tento hosting je na rozdíl od komerčního Rails hostingu, který je provozován na technologii „Mongrel proxyovaný Apachem“ (viz složitý obrázek), provozován na technologii Phusion Passenger, neboli modrails. Phusion Passenger je modul do webového serveru Apache (ano!, jako modphp! OMG PONIES!) a umožňuje současné spuštění desítek Rails aplikací, aniž by si každá z nich ukousla třicet, padesát nebo sto megabajtů paměti. Pro provoz free hostingu je zatím dle sdělení Jiřího Kubíčka vyhrazen jeden stroj IBM Blade Server (2×Xeon 3.0Ghz, 4GB RAM). Více informací, zkušeností z provozu, tipů, apod. se dočtete na blogu společnosti Kraxnet. Zbývá připomenout, že se jedná o plnohodnotný, „normální“ hosting zdarma, který není „na hraní“, jak se člověk může dočíst na internetu. Ne, TLD doménu nebo e-mail „na hraní“ k němu ale (překvapení! překvapení!) nedostanete.

To nejdůležitější je ale stále ještě v něčem jiném.

Za prvé, mod_rails umožňuje provozovat nejen aplikace napsané v Ruby on Rails, ale v libovolném Ruby frameworku: např. Merb nebo Sinatra. Ba co víc! Umožňuje také provoz aplikací napsaných v jazyce Python, jako je např. Django.

Za druhé: tento hosting obsahuje plnou podporu pro ty nejefektivnější techniky deploymentu (instalace a aktualizace) aplikací na server pomocí nástroje Capistrano. Capistrano vám umožňuje jedním příkazem (cap deploy:migrations) provést export nové revize kódu aplikace z verzovacího systému, nahrát ji na server, starou verzi uložit do archivu releases, spustit migrace databázového schématu, restartovat webový server, a provést další řadu maintenance úkolů, které pravděpodobně děláte ručně nebo vůbec. (Umožňuje vám např. také pomocí jednoho příkazu cap deploy:rollback vrátit aplikaci na serveru ke starší verzi, pokud omylem nasadíte verzi s chybou. Jak se vracíte k předchozí verzi vy?)

Pokračujte!

Blog Karmi is on Rails bude v provozu ještě pár týdnů, než stařičká Rails aplikace (stále ještě běžící na přibalené archivní verzi Rails z května 2007) doslouží a bude nahrazena statickým obsahem. Všechny články tedy budou stále k nalezení na svých původních adresách. Konstruktivní i destruktivní komentáře můžete tedy v klidu zanechat níže :)

O autorovy články ale přijít nemusíte. Chcete-li, můžete pokračovat na webu Restafari.org, tentokrát však v lingua franca internetu: angličtině. Není vyloučeno, že na adrese www.restafari.cz někdy v budoucnu najdete články v češtině, pravděpodobné to ale není.

Autor děkuje ještě projednou všem milým komentářům a e-mailům, které po založení blogu obdržel. Pomohly-li vám články najít, získat nebo znovu nakopnout ztracenou energii něco dělat na webu, podělte se o vaši karmu v komentářích!

Linkujte svoje blogy, svoje projekty! Založte si blog a pište o tom, co vás na Ruby/Rails baví a co ne! Navrhněte tričko pro CSRUG. Pošlete odkaz na forum.rubyonrails.cz! Sestavte RSS agregátor z českých Ruby/Rails zdrojů a publikujte ho na webu, třebas jako Sinatra aplikaci! Když už nemůžete publikovat ucelené aplikace, publikujte alespoň fragmenty kódu! Nechte už těch keců a dělejte konečně něco!

One Love!

Ruby on Rails a revoluce ve vývoji pro web. Dokončení

2007-08-19T14:57:00+00:00

V závěrečné části seriálu se dozvíte o nástrojích, které nám Rails poskytují pro pohodlnější psaní aplikací, a ukážeme si na konkrétních příkladech, jak nám mohou usnadnit práci pluginy acts as list a acts as attachment. Můžete si také stáhnout ukázkovou mini-aplikaci, která všechny techniky a postupy našeho seriálu demonstruje.

Poznámka editora: Autor tohoto blogu neočekával komplikace při dokončování závěrečného článku seriálu. Stihnul se mezitím oženit a stihnul pomoci kamarádovi s administračním rozhraním pro web ve Flashi :) Jak jinak než v Rails. Takže se můžete těšit o tutoriál o tom, jak v Rails zprovoznit podporu pro Flash Remoting. Jako aktuální odčinění naleznete u tohoto článku malou ukázkovou aplikaci, která demonstruje všechny ty techniky, triky a strategie popsané v dosavadních čtyřech článcích.

V předchozích částech seriálu jsme se seznámili se základními principy frameworku Ruby on Rails — s návrhovým vzorem ActiveRecord a s konvencemi, které Rails extrahují ze zkušeností s vývojem webových aplikací (a zpětně je na něj aplikují). Tyto části frameworku silně inspirovaly mnoho dalších klonů (identické pojetí modelů a vztahu mezi controllery a views najdete např. v Cake PHP). V tomto článku náš úvodní seriál dokončíme výkladem o tom, co je v Rails z pohledu vývojáře, jeho produktivity a radosti při vývoji, ojedinělé.

Rozšíření a pomocné metody

Jak jsme viděli v předchozím článku o propojení controllerů a views, principy Rails vycházejí z jednoduchých pravidel a konvencí webového vývoje: předej identifikátor nějakého objektu určitému controlleru a prostřednictvím jeho metody s tímto objektem něco udělej. Název šablony odpovídá názvu metody. Název layoutu odpovídá názvu controlleru. A tak dále.

Podobných opakujících se činností najdeme při vývoji nekonečné množství: neustále musíme formátovat datum nebo čas a počítat rozdíly mezi nimi, formátovat velikost souborů a jiná „ošklivá“ čísla, vypisovat varovná hlášení pro položky formulářů, generovat opakující se části kódu se složitější logikou, … Nepřekvapí nás proto, když v Rails najdeme jak velké množství rozšíření pro nejčastější případy takových úkolů, tak transparentní mechanismus pro integrování rozšíření vlastních. Rails obsahují dvě základní rozšíření: rozšíření jazyka Ruby (Core Extensions) a pomocné metody (helpers) obsažené v modulu Action View.

Rozšíření jazyka Ruby doplňují třídy Array, Date, Hash, Numeric a String o „pohodlné“ metody (convenience methods), které zjednodušují často se opakující operace — typicky např. zjištění, zda je číslo sudé či liché, které využijeme třeba pro střídání barvy pozadí řádků tabulky:

1.even?
=> false

Podobně pro definice velikosti souborů můžeme použít metody pracující s „lidštějšími“ tvary než je neustálé násobení a dělení číslem 1024 a jeho násobky:

10.megabytes
=> 10485760

Důležité je, že tato rozšíření jsou přidána přímo do Ruby, metody even? nebo megabytes lze tedy volat pro všechna čísla.

Většina těchto rozšíření posiluje expresivní charakter Ruby — velmi často chceme kupříkladu vypsat položky pole (seznam kategorií nebo tagů) v čitelném, „neprogramátorském“ formátu: „Zařazeno do kategorií Apple, iPhone a Mac OS X“. Pohodlná metoda to_sentence pro objekt Array zařídí právě to:

['Hynek', 'Vilém', 'Jarmila'].to_sentence
=> "Hynek, Vilém a Jarmila"

Standardně Rails pochopitelně vypíšou „Hynek, Vilém and Jarmila“. Můžeme (jako obvykle) doplnit konfiguraci a napsat ['Hynek', 'Vilém', 'Jarmila'].to_sentence(:connector => 'a'), anebo použít lokalizační plugin, obsahující podporu i pro český jazyk.

Nepřekvapí nás, že nejvíce rozšíření nalezneme pro práci s datem a časem. Datová aritmetika („články za poslední měsíc“) a formátování data a času jsou jedny z nejotravnějších činností při programování. Pokud bychom tedy chtěli vypsat seznam úkolů pro tento měsíc, napsali bychom:

@TodoItems = TodoItem.find( :all, 
                            :conditions => "due_date > '#{Time.now.at_beginning_of_month.to_s(:db)}' AND due_date < '#{Time.now.at_end_of_month.to_s(:db)}'", 
                            :order => 'due_date' )

Pohodlná metoda at_end_of_month nám vrací objekt třídy Time, Tue Jul 31 00:00:00 +0200 2007. Ten si jednoduše převedeme pomocí metody to_s na řetězec v SQL formátu (viz parametr :db), který můžeme využít v porovnávání. K zabudovaným formátům :db, :long, atd. můžeme pochopitelně přidat vlastní a využít je pak podle filosofie Don't repeat yourself v dalším kódu. Pro datovou aritmetiku obsahují Rails celou řadu rozšíření.

Pomocné třídy Rails se od rozšíření tříd Ruby liší — jsou automaticky dostupné pouze ve view, nikoli v controllerech a modelech. (Lze je ale direktivou include zpřístupnit i jim.) Slouží opět ke zjednodušení formátování a generování kódu, typicky formulářových prvků, odkazů (nám již dobře známá metoda link_to nebo výstižně pojmenovaná link_to_unless_current) či pro přístup k chybovým hlášením formulářových prků (error_message_on).

Jedna z nejefektivnějších pomocných metod je ta s výstižným, byť krkolomným názvem distance_of_time_in_words_to_now. Do jisté míry zavedla určitý návrhový vzor pro „polidštění“ výpisu data a času. Byl-li např. článek publikován včera, je většinou mnohem čitelnější říci o něm, že byl publikován včera, než že byl publikován 16. 7. 2007 v 18:15.

Zde je zřetelně vidět inspirační zdroj v mentalitě 37Signals: snaha zbavit se žargonu, péče věnovaná jazyku, kterým aplikace s uživateli „mluví“. Rozdíl mezi publikován 16. 7. 2007 v 18:15 a publikován včera se může zdát nepodstatný, nezasluhující si zvláštní pozornosti, můžeme jej odsoudit jen jako „vychytávku“. Z pohledu uživatele však tento rozdíl může být propastný

Jestliže s ním aplikace mluví o „Úkolech na zítra“ a „Změněno včera“, radikálně roste jeho důvěra v to, že má smysl ji používat, že mu rozumí — neboť s ním mluví „jeho“ jazykem a neplete se mu do cesty. Neschopnost takové empatie na straně tvůrců aplikací je jedním z hlavních důvodů, proč aplikace tak často uživatele stresují. (Empatie se dá přitom samozřejmě karikovat a přehánět do podoby přechytralých aplikací, které se stále ptají „Zdá se, že na ploše jsou nepoužívané ikony, chcete je odstranit?“)

Podobné pobídky k „neprogramátorskému“ výpisu dat nalezneme napříč všemi pomocnými metodami, zvláště s ohledem na čísla:

number_with_delimiter(1234567, " ")
=> "1 234 567"

number_with_precision(123.45678, 2)
=> "123.46"

number_to_human_size 10485760
=> "10 MB"
number_to_human_size 1572864
=> "1.5 MB"
number_to_human_size 125952 
=> "123 KB"

number_to_phone(123456789, :delimiter => ' ', :country_code => '420')
=> "+420 12 345 6789"

number_to_currency(12345, :unit => 'Kč ', :separator => ',', :delimiter => ' ')
=> "Kč 12 345,00"

Mnoho dalších tipů pro práci s helpery najdete v loňském Adventním kalendáři pro Rails.

Kromě zabudovaných pomocných metod v Rails nalezneme efektivní a transparentní mechanismus, jak vytvářet helpery vlastní. Najdeme je ve složce app/helpers, a její obsah může vypadat např. takto:

Soubor application_helper.rb obsahuje pomocné metody dostupné všem views (to nás nepřekvapí, protože víme, jaký význam v Rails mají komponenty pojmenované application: layout/application.rhtml, public/javascripts/application.js, atd.) Obsahuje-li naše aplikace controller pojmenovaný Todos (controllers/todos_controller.rb), pro „jeho“ views budou automaticky dostupné pomocné metody ze souboru helpers/todos_helper.rb. Samozřejmě, jako obvykle metody definované v helperech pro konkrétní controllery přetěžují ty definované v application_helper.rb přetěžují. A k čemu můžeme helpery nejlépe využít?

Typicky kupříkladu chceme, aby název stránky (<title>) byl na úvodní stránce webu jiný (Veterinární klinika Jezevčí Skála: Nejlepší péče o vaše miláčky. Očkování, vyšetření, ošetření psů, koček a jiných domácích zvířat) než na stránkách ostatních (Naše vybavení | Veterinární klinika Jezevčí Skála). Skládáme tedy název stránky z různých částí. Mohli bychom v šabloně zkusit něco jako

<title><%= if controller.action_name == 'index' then 'Veteri...' else "@page.title | Veteri..." end -%></title>

ale víme, že takový kód je velmi špatně čitelný a jako takový opět náchylný k chybám. Určitě by bylo efektivnější, kdybychom napsali prostě

<title><%= page_title -%></title>

a metodu page_title definovali právě pomocí helperu. Protože název stránky je (většinou) záležitostí celé aplikace, bude nejlépe, když tuto metodu nadefinujeme v globálním application_helper.rb například nějak takto:

def page_title
   if controller.action_name == 'index'
     "Veterinární klinika ... domácích zvířat"
   else
     "#{@page.title} | Veterinární klinika ..."
   end
 end

Obrovskou zásobů helperů obsahují Rails pro práci s formuláři, kdy usnadňují zejména práci s předvyplňováním hodnot u radio buttonů a u select prvků. To je však rozhodně téma na zvláštní článek, a proto se k nim ještě někdy v budoucnu vrátíme.

Nějaké ty pomocné rutiny, které do HTML vypíšou nějaký ten formulářový prvek má totiž leckterý framework. Rails však mají pro vývojáře přichystány také pomocníky velmi specifické. Na tři z nich se nyní podíváme.

Generátory

Lze říci, že počítačové programy obecně řeší dva typy úloh: buď nějaké výpočetně velmi složité úkoly (a fungují tedy jako „tisíc kalkulaček dohromady“) nebo opakující se a mechanické činnosti — případně, a to nejčastěji, kombinaci obou. Jak jsme viděli, vztahy mezi jednotlivými součástmi aplikace v Rails jsou postaveny na několika málo velmi dobře kodifikovaných principech. Není až takový problém si je zapamatovat — většinou stačí napsat to první, co člověka napadne. Bylo by však dosti neefektivní stále dokola vytvářet nové soubory s modely v příslušných složkách s příslušnými jmény a vepisovat do nich příslušné definice dědění tříd… Z tohoto důvodu obsahují Rails tzv. generátory kódu (generators). Ty nám pomohou při vytváření nových modelů, controllerů a jiných součástí aplikace. Podíváme se podrobněji na to, co nám umožňují.

Chceme-li v Rails vytvořit novou třídu objektů, tedy nový model, např. pro úkolovník, postačí, když vytvoříme ve složce app/model soubor todo_item.rb. Museli bychom ale jednak deklarovat jeho odvození z třídy Active Record, jednak bychom nějak a někde museli deklarovat jeho datovou strukturu („po staru“ řečeno sloupečky v tabulce), která je s ním těsně spjatá. V Rails nám totéž — a ještě více — vykoná jeden příkaz:

script/generate model TodoItem

Jeho zkrácený výstup vidíte níže:

create  app/models/todo_item.rb
create  db/migrate/001_create_todo_items.rb
create  test/unit/todo_item_test.rb
create  test/fixtures/todo_items.yml

Generátor nám nejenom vytvořil soubor s prázdným modelem Active Record, ale vygeneroval i soubory pro testování (které prozatím necháme stranou) a soubor se zajímavým názvem 001_create_todo_items. Ten obsahuje silnou zbraň Rails jménem migrace.

Migrace odstiňují vývojáře od definování datových struktur modelů (sloupečků v tabulce) pomocí SQL příkazů (CREATE TABLE ...) a mají dvě základní výhody: jsou čitelnější než SQL a tudíž méně náchylné k chybám v kódu a jsou přírůstkové a odvolatelné. Obsahují tak historii definic datové struktury aplikace, kterou lze vracet zpět, upravovat, jednoduše přidávat objektům nové atributy („sloupečky“).

Definice datové struktury tudíž může probíhat skutečně agilně, z hlediska znalosti věcí v daném okamžiku a vývojář se nemusí stresovat tím, jestli náhodou nepojmenoval nějaký sloupeček špatně nebo jestli mu (bože!) v tom hezkém obrázku propojených tabulek náhodou některý nechybí a „zákazník to pak bude chtít…“

Typická migrace pro náš model s úkoly může pak vypadat např. takto:

class CreateTodoItems < ActiveRecord::Migration
  def self.up
    create_table :todo_items do |t|
      t.column :title, :string
      t.column :due_date, :date
      t.column :completed, :boolean

      t.column :position, :integer
      t.column :created_at, :datetime
    end
  end

  def self.down
    drop_table :todo_items
  end
end

Vidíme, že se jedná o standardní třídu Ruby, obsahující metody up pro provedení migrace a down pro její „odvolání“. Číslo 001 v názvu souboru slouží pro identifikaci dané migrace. Migraci provedeme příkazem rake db:migrate pro změnu datové struktury aplikace na poslední definici v pořadí, příkazem rake db:migrate VERSION=1 se vrátíme na datovou strukturu odpovídající souboru 001_....

Vidíme také, že definujeme objekt s atributy pro název, datum plánovaného dokončení a informací o tom, zda byl úkol splněn, a to ve velmi srozumitelných datových typech string, date a boolean. (Rails obsahují abstraktní datový typ boolean velmi dobře popsaný v knize Agile Web Development With Ruby On Rails.)

Řekněme, že v náhlém hnutí mysli se nám velmi znelíbí pojmenování pro atribut názvu úkolu, title. Chtěli bychom, aby se jmenoval (logičtěji) name a tento nedostatek nám v pokročilé hodině téměř znemožňuje programovat dále. Je třeba to napravit, a to co nejdříve. A nepřijít přitom o všechna data, která již databáze obsahuje — takže na nějaké to DROP TABLE... můžeme zapomenout. Generátor migrace obsažený v Rails nám pomůže právě v takové situaci. Jediné, co musíme udělat, je vymyslet srozumitelný název pro migraci a vyplnit údaje o tom, jak se má příslušný sloupeček příslušné tabulky přejmenovat:

script/generate migration ChangeAtrTitleOfTodoItemToName
=> create  db/migrate/002_change_atr_title_of_todo_item_to_name.rb

Vygenerovaný soubor pak obsahuje prázdnou třídu migrace, do níž doplníme jen těla metod up a down.

class ChangeAtrTitleOfTodoItemToName < ActiveRecord::Migration
  def self.up
    # rename_column :table_name, :column_name, :new_column_name
    rename_column :todo_items, :title, :name
  end

  def self.down
    rename_column :todo_items, :name, :title
  end
end

Příkazem rake db:migrate a restartem aplikace pak provedeme migraci na tuto definici. Z tohoto důvodu nečekejte u Rails aplikací žádné SQL dumpy apod. Ty případně využijete jen pro přenášení dat — nikoliv datových struktur — mezi databázemi.

Podobně snadno můžeme Rails nechat vytvořit soubory pro určitý controller (např. Article) a jeho metody (např. index, list a show):

script/generate controller Article index list show

create  app/controllers/article_controller.rb
create  test/functional/article_controller_test.rb
create  app/helpers/article_helper.rb
create  app/views/article/index.rhtml
create  app/views/article/list.rhtml
create  app/views/article/show.rhtml

Vidíme, že generátor vytvořil soubory pro samotný controller, jeho helper a test, stejně jako views pro metody, které jsme uvedli při jeho volání. V postupně vznikajících IDE pro Rails nalezneme tyto generátory obalené grafickým rozhraním, jejich funkce je ale totožná a možnosti stejné.

Konzole

Podobná specialita Rails, která se též odehrává v příkazové řádce, je konzole aplikace, která se spouští příkazem script/console. Umožňuje nám pracovat s živou, běžící aplikací v prostředí terminálu. Ve fázi psaní kódu i pro rychlý pohled na data aplikace je její pomoc neocenitelná: umí číst data z modelů, upravovat je a zase zapisovat, má přístup k helper metodám a v omezené míře i ke controllerům. Můžeme si tak vyzkoušet různá formátování výstupu za pomoci helperů, složitější operace s modely „nanečisto“, bez použití prohlížeče, neustálého znovunačítání stránky a vypisování různých „pomocných“ dumpů. Mnoho triviálních operací můžeme navíc provádět pouze přes konzoli a vůbec k nim nevytvářet grafické rozhraní v HTML a odpovídající controllery. Typickou takovou úlohou je např. změna hesla u nějaké velmi jednoduché aplikace bez složité struktury uživatelských práv:

script/console production

u = User.find_by_login('admin')
=> #<User:0x35a0ed0 @attributes={"name"=>"Administrator", ...
u.password = 'simsalabim'
=> "simsalabim"
u.save
=> true

A je to. Podobně neocenitelnou pomoc nám konzole poskytuje pro rychlý administrátorský zásah nebo rychlou kontrolu:

User.find_by_email('persona_non_grata@botmail.com').destroy!
=> true
User.find_all_by_is_logged_in(true).size
=> 21

Z pohledu vývojáře je zkrátka konzole jedna z nejužitečnějších věcí v Rails; nástroj, který šetří obrovské množství času a psaní různých podpůrných pseudo-metod controllerů a pseudo-views pro ladění výstupu aplikace. Všechny příklady Rails kódu v našich článcích jsou prováděny právě v konzoli. Implicitně je konzole spuštěna v development režimu aplikace — pokud bychom ji chtěli spustit nad „ostrými“ daty (což chceme dost často), musíme režim uvést při jejím spuštění: script/console production. Rozsáhlý seznam tipů a triků pro práci v konzoli naleznete na blogu Amy Hoy, Err the Blog a v příslušné epizodě Railscasts. Zde z nich uvedeme pouze dva nejužitečnější.

Při práci v konzoli zároveň často měníte kód modelu. Konzole však o změněném kódu neví. Abyste ji nemuseli stále ukončovat příkazem exit a znovu startovat, postačí znovu načíst aplikaci příkazem reload!. Druhým nedocenitelným tipem je zkratka pro zformátování výstupu do velmi čitelného YAML formátu — postačí příkaz uvést jediným písmenem y:

y TodoItem.find(:all)
--- 
- !ruby/object:TodoItem 
  attributes: 
    name: "Dopsat článek"
    completed: f
    id: "1"
    ...

Ba co víc. Znak podtržítko slouží jako zkratka po vyvolání výstupu předchozího příkazu. Můžeme tedy psát příkazy „jak jsme zvyklí“, a jen výstup, který nás zajímá, rychle převést na YAML, aniž bychom museli daný příkaz psát znova.

TodoItem.find(:all)
=> [#<TodoItem:0x362c91c @attributes={"name"=>"Dopsat článek"...]
y _
--- 
- !ruby/object:TodoItem 
  attributes: 
    name: "Dopsat \xC4\x8Dl\xC3\xA1nek"
        ...

Konzole dokonce obsahuje všechny vlastnosti terminálu, na které jste zvyklí: šipkami nahoru a dolů se pohybujete v historii příkazů, pomocí ctrl+R můžete v historii i vyhledávat, klávesa tab doplňuje příkazy — těm, kteří se terminálu nebojí, tedy poskytuje maximální komfort a efektivitu při budování a ladění aplikace.

Pluginy a komunita

Protože nejste sněhová vločka, je velká pravděpodobnost, že funkcionalitu, kterou potřebujete, potřeboval už dříve někdo před vámi. A ten někdo mohl být dokonce chytřejší než vy. Pro Rails existuje obrovské množství rozšíření formou pluginů, od těch určených pro specifické případy, po pluginy, které řeší obecné problémy téměř každé aplikace. Podívejme se na dva takové případy.

V aplikaci můžeme mít určitý uspořádaný seznam položek: stránek v menu, souborů ke stažení, úkolů v úkolovníku. Položky se mohou vypisovat v určitém pořadí (podle data, názvu, apod.) nebo podle manuálně zadaného pořadového čísla. Je standardním požadavkem ze strany klienta, aby řazení položek bylo možné „manuálně“ ovlivnit i u takových seznamů, které jsou řazeny dle data — např. v případě výpisu tiskových zpráv. Tuto funkčnost je třeba implementovat snad v každé webové aplikaci. Lze říci, že kde je nějaký podobný seznam, dříve či později se objeví požadavek na to, aby bylo možné jeho položky manuálně řadit. Nepřekvapí nás proto, že Rails obsahují standardně plugin s příznačným názvem acts_as_list — TodoItem acts_as_list („Úkol se chová jako seznam“).

Každému modelu můžeme jednoduše nastavit, že se chová jako seznam:

class TodoItem < ActiveRecord::Base
    acts_as_list
end

Jediné, co musíme navíc udělat, je definovat v dané tabulce sloupeček s názvem position. Pro instance třídy TodoItem pak máme automaticky k dispozici metody k pohodlné manipulaci s položkami seznamu: move_higher, move_lower, move_to_top, higher_item a další. V controlleru si pak nadefinujeme jen jednoduché obslužné metody:

def move_higher
  if TodoItem.find(params[:id]).move_higher
    flash[:message] = "Položka byla posunuta výše v seznamu"
  else
    flash[:message] = "Bohužel, položku se nepodařilo posunout&hellip;"
  end
  redirect_to :action => 'list'
end

(Pro kompletní kód si stáhněte ukázkovou aplikaci z tohoto článku.)

Psát podobnou funkcionalitu „vlastnoručně“ by bylo naprostým plýtváním času. Právě v těchto případech Rails oceníte nejvíce: vždy, když si uvědomíte, kolika vlastností dosáhnete prostými deklaracemi typu acts_as_list.

Obsluha uspořádaného seznamu je ale pořád ještě slabý čaj proti práci se soubory nahrávanými do aplikace pomocí formulářů: ošetřením práv, zmenšováním obrázků, hlídáním správných datových typů, … Právě pro práci s uploady obsahují Rails plugin actsas_attachment, resp. jeho novější inkarnaci attachmentfu. Tento plugin si musíme do aplikace nainstalovat:

script/plugin install acts_as_attachment

Pro uploadovaná data si vytvoříme model a deklarujeme jeho chování:

class Photo < ActiveRecord::Base
  acts_as_attachment  :storage => :file_system, 
                      :max_size => 3.megabytes, 
                      :content_type => :image,
                      :resize_to => '800x>',
                      :thumbnails => { :small => '125>', :tiny => '25>' }                      
  validates_as_attachment
end

Vidíme, že definujeme způsob ukládání dat (na disku), maximální velikost (3 MB), povolený typ souborů (pouze obrázky) a necháváme je zmenšit na 800 pixelů na šířku. Zároveň vytváříme dva thumbnaily (small a tiny) o velikostech 125 a 25 pixelů na šířku. Na posledním řádku deklarujeme, že se má před uložením objektu provést validace — zda vůbec něco bylo nahráno, zda není nahrávaný dokument větší, než povolené tři megabyty a zda má správný mime-type.

Jediné, co musíme zajistit ve view, je to, aby se příslušný file input jmenoval korektně, tedy:

file_field :photo, :uploaded_data
=> <input id="photo_uploaded_data" name="photo[uploaded_data]" type="file" />

V controlleru pak jednoduše zavoláme:

@photo = Photo.create(params[:photo])

Což je jen zkratka pro případný zápis Photo.create(:uploaded_data => params['nahrany_soubor']). V případě, že data z formuláře odesíláme „zabalená” v kontejneru photo a nazvaná uploaded_data, vystačíme si s kratším zápisem. V každém případě pozorně sledujte log soubory (log/development.log a log/production.log), jestliže vám něco nefunguje – dozvíte se přesně, s jakými parametry voláte metody a pod jakým názvem vám uploadovaný soubor přichází.

Soubor pak máme uložen jak na disku, tak v databázi a můžeme k němu a k jeho atributům snadno přistupovat:

photo = Photo.find(:first)
=> #<Photo:0x3576c84 @attributes={"content_type"=>"image/jpeg", "size"=>"132716", ...
number_to_human_size photo.size
=> "129.6 KB"
photo.content_type
=> "image/jpeg"
photo.width
=> 500
photo.public_filename
=> "/photos/1/sample-image-01.jpg

Pokud si budete chtít výše uvedený Ruby kód vyzkoušet v Rails konzoli, nezapomeňte nejprve nalinkovat helpery pro čísla: include ActionView::Helpers::NumberHelper. Konzole je sama od sebe připojené nemá.

Na disku ukládá plugin actsasattachment dokumenty do podsložky pojmenované stejně jako tabulka pro daný model, v našem případě tedy photos, a pro každý dokument vytváří dále podsložky pojmenované podle jejich ID:

Ve view, kde chceme daný soubor zobrazit, pak jen jednoduše napíšeme:

<%= image_tag photo.public_filename(:small) # Malý thumbnail %>
<%= image_tag photo.public_filename         # Plná velikost %>

Jak vidíme, práce s uploady je díky pluginu actsas_attachment zcela jednoduchá. Rails však obsahují ve svých útrobách skrytou ještě jednu _vychytávku: třídu TestUploadedFile. Ta je primárně určena především k testování uploadů, jak její název napovídá. Můžeme ji ale skvěle využít k něčemu jinému: k automatizovanému importu dat z disku do naší aplikace.

Představme si, že programujeme fotogalerii, a fotografie máme na disku. Chceme využít plugin acts_as_attachment a mít všechny fotografie přístupné jako objekty v Rails. Jistě nebudeme stovku fotografií uploadovat jednu po druhé pomocí formuláře v HTML stránce. Napíšeme si importní metodu:

# class Photo
def self.import_photo file
    raise "PhotoNotFound (#{file})" unless File.exists? file
    self.create( :uploaded_data => ActionController::TestUploadedFile.new(file, 'image/jpeg') )
    print "."
end

Nyní nám jen stačí projít celý adresář a fotografie naimportovat:

# class Photo
def self.import_directory dir
    t = Time.now
    count ||= 0
    Dir.foreach(dir) do |file|
        # Trivialni kontrola vyhovujicich souboru
        if file.to_s.downcase.include? "jpg"
            Photo.import_file "#{dir}/#{file}"
            count += 1
        end
    end
    puts "\n-- Nahrál jsem #{@count} fotografií z adresáře #{dir} za #{Time.now-t} sekund\n\n"
end

Tyto metody nyní můžeme spustit pomocí Rails konzole, nebo je můžeme pouštět třeba periodicky pomocí cronu a script/runner. Můžeme tak pomocí dvou metod o sedmnácti řádcích naplnit databázi stovkami megabytů dat, která pak máme ve webové aplikaci přístupná jako objekty v databázi. Co to přesně znamená? Stačí jen trochu rozpálit fantazii a představit si, že pomocí callbacku before_save a funkce get_exif_by_entry RMagicku přečteme data třebas o fotoaparátu a můžeme si dělat podobně krásné statistky jako má Flickr… a s takovými hezkými grafy…

Pluginy pro Rails a knihovny (standard libraries) nebo balíčky (rubygems) pro Ruby jsou totiž možná to úplně nejlepší na psaní aplikací v Rails. Máloco vás potěší tak jako to, když zjistíte, že funkčnost, kterou potřebujete, napsal už někdo před vámi, a možná dokonce i líp, než byste to udělali vy. Pluginy a gemy jsou takový svět Rails/Ruby v malém — základní infrastrukturu máte hotovou, nemusíte o ní přemýšlet a nemusíte ji programovat. Můžete se zabývat „detaily“, které celý svět tak obdivuje na Basecampu, Flickru, Joyent Connectoru. Můžete zkrátka řešit věci, které jsou z pohledu uživatelů vaší aplikace daleko důležitější než „prostá funkcionalita“. Tu očekávají automaticky — neohromíte je tím, že jim ukážete pár text fieldů ve formuláři, pomocí nichž mohou zadat novou fakturu do účetní aplikace. Pluginy, gemy a ostatní rozšíření vám šetří čas, který můžete věnovat úplně jiným věcem.

Například podobně standardní potřebou jako manipulace s položkami uspořádaného seznamu nebo upload souborů je i to, aby vám aplikace poslala e-mailem notifikaci, když dojde k nějaké chybě či výjimce. Pro Rails existuje výborný plugin Exception Notifier, který vám zašle vyčerpávající informaci o tom, jaká chyba v aplikaci nastala, při jakém requestu, jaký řádek kódu chybu způsobil. A vy se můžete zabývat sortováním takových mailů, nebo třeba jejich automatickým parsováním do ticket systému...

Co když ale potřebujete něco méně obvyklého? Chtěli byste například exportovat ActiveRecord recordsety do CSV formátu. A ejhle, on existuje pěkně napsaný plugin convertibleto_csv. Potřebujete provést request na nějaké URL na internetu a zpracovat je? Využijete už nám dobře známou knihovnu Net::HTTP_. Chcete použít jako datové úložiště třeba Google Spreadsheet? Stáhněte si knihovnu GData Ruby a polovinu práce máte hotovou.

Samozřejmě, ne všechno v Ruby a pro Ruby je ukázkou elegantního kódu. (I když ty nejhorší výstřelky bývají dost často portem z jiného jazyka.) Díky úspornosti a čitelnosti kódu v Ruby vám ale trvá neporovnatelně méně času přepsat části kódu podle „svého“.

Okolo Ruby a Rails však především existuje na celém světě přátelská, energická komunita programátorů, vývojářů a web designérů, takže pokud vládnete angličtinou, najdete na blozích a diskusních fórech spřízněných s Rails jedny z nejzajímavějších a nejtalentovanějších tvůrců dneška.

Ruby on Rails je jedním z nejpoutavějších duchovních výkonů v oblasti informačních technologií za poslední dekádu: zcela změnil zavedené postupy ve vývoji pro web, a za jeho vlak se dále připojují vagony Standardizace deploymentu, Integrace version-control, Výstup v různých formátech pomocí respond_to, Sdílené aplikační rozhraní aplikací — REST, Škálování aplikací, … Právem za Rails David Heinemeier Hansson obdržel cenu 2005 Open Source Best Hacker.

V současné době je již samotný kód Rails dílem mnoha a mnoha přispěvatelů, nikoliv solitérským geniálním činem. Právě účast na tomto „společném díle“, objevování netušených možností Ruby a Rails, integrování funkcí a vlastností, které byste si v jiných jazycích a frameworcích dvakrát rozmysleli, je to co přináší vývojářům v Rails takovou radost z práce.

Tento „nakažlivý optimismus“ lidí okolo Rails je možná jedním ze zdrojů nedůvěry a obav, které se v souvislosti s Rails stále dokola objevují. Práce má být přece otrava. Pro vývoj v Rails to ale tak úplně neplatí. Existuje-li něco srovnatelného s radostí ze hry (běžně chápané jako protiklad práce, neboť nevytváří žádnou hodnotu), je to psaní webové aplikace v Rails… A začnou-li vás Rails bavit doopravdy, můžete nejen začít opravovat a vylepšovat Rails samotné, ale také si nabrousit ostruhy v utkání nejlepších Rails hackerů.

O Rails už každém případě víte dost na to, abyste se mohli rozhodnout, zda-li vás zajímají a mohou vám přinést nějaký užitek. Tímto článkem jsme skončili náš úvod o nejdůležitějších principech Rails. V dalších článcích se podíváme podrobněji na syntaxi jazyka Ruby, abychom porozuměli všem jejím zákoutím, a budeme se věnovat konkrétním návodům a postupům v Rails. Mezi připravená témata patří práce s formuláři a Ajax v Rails, nasazení aplikací na serveru (deployment), implementace Flash Remoting a další. A samozřejmě též slíbený článek o Rails z pohledu projektových manažerů a vůbec „neprogramátorů“. Máte-li návrh na nějakou problematiku, o níž byste se chtěli dozvědět více, využijte komentáře k článku!

Obrovský dík tentokrát patří Jiřímu Kubíčkovi za chladnokrevnou asistenci při zprovozňování Rails, SQLite a RMagicku na Windows XP, aby si autor sám prošel trnitou cestu, již budou muset projít ti z čtenářů, kteří si budou chtít ukázkovou aplikaci rozběhat v tomto operačním systému.

Výukovou mini-aplikaci doprovázející tento seriál článků si můžete stáhnout, abyste si vše mohli vyzkoušet v pohodlí svého http://127.0.0.1:

rails_demonstration_app.zip

Je vhodná i pro naprosté začátečníky v Rails, obsahuje celou řadu doporučených postupů při vývoji v Rails, a na 120 řádcích kódu pokrývá tato témata:

Použití metod find, update_attributes a toggle ActiveRecordu, definování vlastních metod pro třídu i instanci modelu
Práci s layouty, kombinaci scaffoldu v Rails a vlastních metod controllerů a views
Metody controllerů pro zobrazování i manipulaci s objekty, včetně ošetření chyb, přesměrování
Definování vlastních helperů
Ukázky embedded Ruby (ERB) v šablonách, ukázky volání parciálních šablon
Použití pluginu acts_as_list a využití jeho metod pro manipulaci s objekty v controllerech
Použití pluginu acts_as_attachment pro upload obrázků do aplikace a jejich zmenšování

Aplikace vyžaduje jako databázi SQLite nebo MySQL, pro zmenšování obrázků pak ImageMagick a RMagick. Podrobný návod naleznete přibalený k aplikaci v doc/README_FOR_APP. Pokud se dostanete do nesnází, využijte komentářů k článku, diskusního fóra na Rubyonrails.cz nebo IRC kanálu #rubyonrails na irc.felk.cvut.cz.

Pojďte do kina na Ruby on Rails!

2007-07-26T14:02:00+00:00

Přijďte ve čtvrtek 2. srpna na druhé setkání příznivců Ruby a Ruby on Rails, tentokrát s promítáním v kině Světozor!

Pravidelná setkání příznívců (příp. též odpůrců) Ruby a Ruby on Rails pokračují i v srpnu. Tentokrát se sejdeme za týden, ve čtvrtek 2. 8. ve 20.00 v pražském Kině Světozor a na programu máme:

Promítání videa Rails From Scratch, Part 1, 78minutového screencastu od Geoffreyho Grosenbacha v angličtině o základech Rails, jejich adresářové struktuře, pomocných metodách, controllerech a views, apod. Jestliže vás zaujaly úvodní články o Rails na tomto blogu, nenechte si jej ujít.
Přednáška o testování v Rails od Jana Kubra ukáže praktické postupy při využití integrovaných testovacích nástrojů v Ruby on Rails

Screencast je vhodný pro programátory i „neprogramátory“ — obsahuje sice doopravdové ukázky kódu v Ruby, ale vše vysvětluje a je prost žargonu. Za screencast od vás organizátoři budou žádat malý finanční příspěvek na pronájem sálu, odměnou vám bude dárek v několikanásobně vyšší hodnotě. :)

Kapacita sálu ve Světozoru je omezená, proto se prosím registrujte na fóru RubyOnRails.cz!

Do čtvrtečního setkání se můžete těšit na dokončení našeho úvodního seriálu o Ruby on Rails.

Ruby on Rails a revoluce ve vývoji pro web. Část třetí: Controller a view

2007-07-03T00:18:00+00:00

V předchozích článcích jsme se zabývali filosofickými východisky jazyka Ruby a tím, jak na ně Rails navazují prostřednictvím výkladu o Active Record. Dnes si řekneme, jak Rails řeší prezentační vrstvu aplikace – vztah mezi controllery a views.

V minulých dvou článcích (první část, druhá část) jsme se zabývali základními principy programovacího jazyka Ruby a frameworku Ruby on Rails, s konkrétním výkladem o jeho části Active Record (tedy onomu M v MVC). V dnešním článku bych chtěl pokračovat výkladem o zbývajících dvou součástech MVC: Controlleru a View. V článku následujícím náš úvod o tom, co je na Ruby on Rails pro programátory tak uchvacující, dokončíme.

URL jako rozhraní aplikace

Prozatím jsme si probrali jen jednu část z Model-View-Controller schématu, tedy model implementovaný pomocí návrhového vzoru ActiveRecord. Typická (nejen) webová aplikace potřebuje nejenom přistupovat ke zdrojům dat, ale také sbírat požadavky zvenčí a prezentovat na jejich základě výstup. Základním prvkem tohoto principu je směrování, anglicky routing, které zajištuje, že aplikace „ví“, na jaké prvky má směrovat konkrétní požadavek.

Typickým takovým „požadavkem zvenčí“ je pro webové aplikace URL, ať již je návštěvník zadá přímo, či klepne na odkaz nebo tlačítko ve formuláři. Dlouho se URL ve webových aplikacích bralo jako pouhý transportní mechanismus, u něhož nezáleží na tom, jak vypadá, jak je dlouhý, zda je čitelný. Proto jsme se setkávali (a leckdy i dnes setkáváme) s URL ve tvaru:

http://example.com/exec/default?action=list&template=article_list&currPage=2&order=DESC&showonly=title,perex& …

Takové URL má dvě základní vlastnosti: je maximálně pohodlné pro programátora a maximálně nepohodlné pro uživatele. Avšak dle pregnantního vyjádření Jakoba Nielsena je URL součástí grafického rozhraní aplikace. Lidé si URL posílají e-mailem, diktují do telefonu a dle výzkumné zprávy Microsoftu (PDF, 650KB) věnují až čtvrtinu času stráveného prohlížením výsledků vyhledávání právě „adresám stránek“.

To, že se v současné době setkáváme s „lidštějšími URL“ (pretty URL nebo user-friendly URL), je v určité míře způsobeno masivní evangelizací odborníků na použitelnost, daleko více však důležitostí, kterou na současném webu hraje optimalizace pro vyhledavače. I programátoři si uvědomili (nebo je k tomu někdo donutil), že pokud „nejste na Googlu“, váš web jakoby nebyl, a téměř všechny content management systems se dnes chlubí tím, že generují „SEO-friendly URL“.

Při tvorbě správného URL je třeba dodržet minimálně dva základní principy: odhadnutelnost a reprodukovatelnost. To znamená, že běžný návštěvník ze samotného URL odhadne, co za obsah jej asi na dané adrese čeká („výpis článků nebo detail článku?“) a že URL vrací stále tentýž dokument (např. pokud URL někomu pošlu e-mailem), a obsahuje úplné informace k jeho zobrazení (proměnná lang tedy např. není uložena v cookie nebo session). (Existují samozřejmě výjimky, jako je adresa http://blog.example.com/latest-posts nebo http://blog.example.com/posts-since-your-last-visit. Zvláště v kontextu blogů se podobné problémy řeší tzv. permalinky, odkazy na komentáře ve tvaru http://blog…/#comment-45, apod.)

Řekli jsme, že typickým požadavkem zvenčí u webové aplikace je URL. Takové URL může v (téměř) ideálním tvaru vypadat např. takto:

http://www.example.com/article/show/1

Je zjevné, že toto URL velmi pravděpodobně zobrazí (show) nějaký článek (article) s identifikačním číslem 1 — je tedy velmi dobře odhadnutelné. To, co je zjevné člověku, ale stroje samy od sebe neví. Aby to „věděly“, je třeba jim to „říci“. Jak tedy Rails říkají stroji, co a jak zobrazit?

Direktivy, které routing řídí, jsou v Rails obsaženy v souboru config/routes.rb. Nepřekvapí nás, když tam najdeme tuto direktivu:

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

Rails vycházejí v této základní route z jednoduchého principu: první entita, na kterou v URL narazíme, je zároveň první dělící čárou aplikace v MVC architektuře — který controller převezme požadavek? Druhá entita je další dělící čárou — která metoda (akce) tohoto controlleru převezme požadavek? A konečně, této metodě je třeba předat nějaké parametry (např. ID stránky, způsob řazení výpisu, apod.)

90% všech routes v typické webové aplikaci je tvořeno právě takto: zavolej určitou metodu nějakého controlleru a předej jí nějaký identifikátor nebo jiný parametr. Rails obsahují tuto direktivu již v čisté instalaci a není třeba ji stroji zvlášť sdělovat. V typické aplikaci si s touto direktivou vystačíte a další ani nebudete muset přidávat.

Stačí tedy, když dodržíte tuto strukturu URL, a vaše aplikace bude „sama od sebe vědět“, co si má s požadavkem počít. Tento typický scénář ilustruje následující schéma:

Protože routes je samozřejmě třeba stejně snadno číst jako vypisovat (typicky ve view), Rails obsahují pohodlné a čitelné generátory routes:

<%= link_to "Celý článek", :controller => 'article', :action => 'show', :id => article.id %>
=> <a href="/article/display/1">Celý článek</a>

Routing v Rails je samozřejmě velmi sofistikovaný (a odstiňuje vývojáře od direktiv pro mod_rewrite podobně, jako ActiveRecord od SQL). Nyní zmíníme jen jeden velmi poutavý koncept: koncept pojmenovaných routes, kdy určité pravidlo není „anonymní“, jako v našem příkladě výše, ale má svůj identifikátor, pomocí něhož se pak na pravidlo můžeme odkazovat. Místo uvedeného příkladu stačí použít jiný výraz než connect a nakonfigurovat pravidlo o něco složitěji:

map.show_article 'article/show/:id',
                                    :controller => 'article',
                                    :action     => 'show',
                                    :id         => /\d+/

Překlad: toto pravidlo zachytí URL, které začíná výrazem article/show, který následuje číslo (onen regulární výraz \d+, tedy alespoň jedno číslo). Kromě větší flexibility a případně i přehlednosti routovacích pravidel mají pojmenované routes jednu velkou výhodu: lze je volat ve views, takže místo relativně komplikovaného kódu:

<%= link_to "Celý článek", :controller => 'article', :action => 'show', :id => article.id %>

můžeme napsat velmi čitelně:

<%= link_to "Celý článek", show_article_url(:id => article.id) %>

Koncept pojmenovaných routes krásně ilustruje eleganci Rails. Transparentní routing, který člověka zbaví nutnosti konfigurovat a ladit nevyzpytatelný mod_rewrite je balzám na nervy vývojáře. Ale pojmenované routes, které umožní celý seznam pravidel zpřehlednit a učinit čitelný, a navíc je lze využít v Rails pro ušetření psaní dalšího kódu, to už je téměř živá voda. „Méně kódu!“ (less code!) je základní mantra vývoje v Rails, která úzce souvisí s filosofií „Nepiš to dvakrát!“ („Don't repeat yourself!“ neboli DRY) — tedy že vše by mělo být deklarováno jen jednou a na jednom místě.

Propojení controller ↔ view

Dosud jsme si ukázali, jak Rails řeší práci s daty v databázi a jak prostřednictvím routingu vědí, kterou část kódu mají vykonat při jakém požadavku. Jak ale Rails vědí, který view je třeba kdy zobrazit, a jak si data mezi jednotlivými komponentami předávají? Jak je vlastně uspořádána ta část aplikace, která řeší zobrazení uživateli?

Právě propojení mezi logikou aplikace a výstupem v HTML stránce je jednou z nejbolestivějších oblastí vývoje pro web. Diskuse o „správném“ přístupu k šablonám (tedy prezentační vrstvě aplikace) jsou jedny z nejžhavějších, a v kontextu webového vývoje se stále dokola rozebírá, zda může šablona obsahovat interpretovatelný kód, co tento kód „smí“ a „nesmí“, co je „srozumitelnější“ pro web designéry (takže vznikají „šablonovací systémy vytvořené pomocí šablonovacích systémů“) a podobně. Pro všechny možné jazyky existuje nespočet šablonovacích systémů s různou mírou striktnosti, čistoty a komplexity. Šablony jsou umisťovány ve složkách s různými názvy, různými příponami, a vztah mezi šablonami a controllery je začasté přinejmenším neodhadnutelný.

Jednoduchá definice „šablony“ v kontextu webové aplikace praví, že se jedná o HTML kód s „dírami“, do nichž se leje dynamický obsah, poskytovaný aplikací, tedy ono typické <p>Ahoj, {NAME}</p>, kde {NAME} je nahrazeno za Honzo. Koncept šablony ovšem přestává být takto prostý, jakmile začneme řešit výpisy v cyklu, střídání barev pozadí řádků tabulky, zobrazení obsahu pouze určitému uživateli, a jinou složitější logiku, které se v promyšlenější aplikaci nevyhneme.

Klasický akademický přístup reprezentuje např. StringTemplate Terence Parra, který rozhodně stojí za pozornost, zajímá-li vás problematika šablonovacích systémů hlouběji. (Děkuji Jiřímu Gruntovi za jeho připomenutí.) StringTemplate se (úspěšně) snaží o naprosté oddělení logiky aplikace od view a jedná se o velmi robustní koncept. Mementem pro všechny koncepty šablonovacích systémů je vyjádření Terence Parra: „Vypadá-li vaše šablona jako program, pak to asi bude program — podařilo se vám dokonale zamotat model a view dohromady“. A takové „zamotání“ je pro skutečnou Model-View-Controller architekturu nepřípustné.

Rails tento oříšek řeší velmi pragmaticky a dle dikta Davida Heinemeiera Hanssona, že správné techniky by měl nástroj podporovat, resp. k nim ponoukat, nikoliv je od vývojáře vyžadovat. Rails nepoužívají žádný „šablonovací jazyk“ (template language), HTML šablony Rails (.rhtml soubory ve složce app/views) obsahují „úplně normální“ Ruby kód, tzv. ERB neboli Embedded Ruby. Nevymýšlejí a nepoužívají tedy nějaké „jiné if“ nebo „jiný foreach“ (jak mají autoři šablonovacích systémů velice v oblibě), ale „úplně normální“ Ruby příkazy if … end, each … end, atd.

Na koncepci view v Rails je velmi sympatická maximální jednoduchost a vynalézavé uplatnění pravidla „konvence má přednost před konfigurací“. Mnohé nám díky znalosti routingu bude ihned srozumitelné.

Rails rozlišují obecnou šablonu celé aplikace nebo její části (typicky controlleru): layout, od šablon pro konkrétní výstupy (typicky metody controlleru): template. Layout obsahuje obecnou „skořápku“ aplikace — sekci <head>, záhlaví, zápatí — a template pak „maso“ stránky. Pokud Rails najdou ve složce app/views/layouts/ soubor application.rhtml, použijí jej automaticky jako obecný layout pro všechny controllery — dokud nenaleznou jinou konvenci nebo konfiguraci. Tohoto faktu můžeme skvěle využít, a speciální HTML layout vytvářet jen pro určité controllery.

Vyjdeme z toho, že máme controller nazvaný Article (viz app/controllers/article_controller.rb), s metodami index, list a show:

class ArticleController < ApplicationController

  def index
        # logika metody...
  end

  def list
        # logika metody...
  end

  def show
        # logika metody...
  end

end

Chceme mít pro tento controller zvláštní layout, odlišný od obecného v application.rhtml. Rails pro tento controller automaticky použijí layout ze souboru article.rhtml, pokud takový soubor ve složce app/views/layouts naleznou. To je konvence, kterou je velmi dobré v Rails dodržovat — kromě toho, že si (opět!) ušetříme spoustu psaní, struktura aplikace bude zas o něco srozumitelnější (nejenom vám, ale i někomu jinému, a to dle známého pravidla znamená i „vám po 2 letech“). Controller Page tedy používá layout page.rhtml, controller User layout user.rhtml, a tak dále. Nám pak stačí pouze tyto soubory vytvořit ve složce app/views/layouts, naplnit HTML, a Rails se postarají o ostatní.

Samozřejmě můžeme pro určitý controller použít i zcela jiný layout — jako téměř vše v Rails, je to otázka jednoduché konfigurace:

class ArticleController < ApplicationController
    layout "clanek"
    # zbytek logiky controlleru...
end

Rails pak budou layout pro controller Article hledat v souboru app/views/layouts/clanek.rhtml. Ba co víc! Layout můžeme klidně deklarovat dynamicky, podle stavu aplikace, typu požadavku nebo třeba (nesmyslně) IP adresy, z níž přichází HTTP požadavek (příklad je převzat z knihy Agile Web Development With Rails):

class StoreController < ApplicationController

    layout :determine_layout

    private

    def determine_layout
        if Store.is_closed?
            "store_closed"
        else
            "standard"
        end
    end

end

Podle toho, jakou hodnotu vrátí metoda Store.is_closed? (opět si povšimněte skvělého použití otazníku v Ruby, je zcela jasné, že metoda vrací booleovskou hodnotu) se použije layout store_closed nebo standard.

Náš controller Article, jak vidíme, má tři metody: index, list a show. Poslední dvě budou (nepřekvapivě) vypisovat seznam článků a zobrazovat konkrétní článek. Metoda index je specialita Rails: je volána, pokud voláme v URL samotný controller bez nějaké metody/akce — tedy např. http://example.com/article. (Povšimněte si, jak je elegantně nazvána podle názvu implicitně načítaného souboru na webovém serveru: index.html)

Šablony pro tyto metody jsou pak (nepřekvapivě) uloženy ve složce article ve složce app/views. Každé metodě pak odpovídá .rhtml soubor: index.rhtml, list.rhtml a show.rhtml — název souboru je tedy shodný s názvem metody. Není třeba nějak výslovně zobrazení toho view „volat“ nebo „konfigurovat“, aplikace provede kód metody a zobrazí šablonu.

Pro metody mohou též existovat šablony pro zobrazování jiného typu obsahu, např. XML (.rxml) nebo specificky pro Rails Javascriptu (.rjs), které se využívají zvláště pro práci s Ajaxem — metody controlleru mohou vracet jiný typ obsahu (klidně i obrázkový graf místo HTML tabulky) podle typu požadavku. K tomu se ještě vrátíme v některém z příštích článků o Ajaxu.

Struktura prezentační vrstvy aplikace je pak zobrazena na obrázku níže. (Tuto demonstrační miniaplikaci si můžete stáhnout (ZIP, 80KB), pokud si chcete propojení controlleru, jeho metod a views vyzkoušet sami.)

Vidíme, že díky jednoduché korespondenci: název controlleru = název layoutu a název metody = název šablony nám Rails (jako obvykle) šetří nejenom psaní kódu, ale především vymýšlení a konfigurování těchto vztahů. Právě tyto chytré vlastnosti Rails způsobují, že při psaní kódu máte pocit, že vám „počítač rozumí“, že programování nemusí být útrpná dřina a snaha přimět počítat vykonávat nějaké „příkazy“. Aplikace funguje jakoby „sama od sebe“ — stačí respektovat jednoduchá a velice přirozená pravidla: název metody je stejný jako název šablony, název controlleru je stejný jako název layoutu.

Pro určitou metodu však můžeme velmi triviálně použít zcela jiný layout:

def show
    # logika metody...
    render(:template => 'zobraz')
end

a to buď k dobru nebo ke škodě naší aplikace.

Dosavadní — snad až příliš rozsáhlý — exkurz měl sloužit k ilustraci nejvýraznější vlastnosti Ruby on Rails:

Rails obsahují téměř nejucelenější soubor best practices pro webový vývoj a design.

Jednoduchá, pragmatická a přitom maximálně promyšlená pravidla pro vztahy mezi controllery, jejich metodami a šablonami mají charakter „platinového standardu“. Těžko lze vymyslet něco chytřejšího při zachování stejné míry obecnosti a zároveň jednoduchosti. Téměř ve všech ostatních aspektech (např. hned za okamžik při výkladu o Embedded Ruby v HTML) potkáme v Rails identický přístup: zde je určitá „doporučená technika“, best practice, a je jen na vás, zda-li jejího intelektuálního přínosu využijete či budete vymýšlet „vlastní cesty“. Téměř vše lze v Rails ohnout, znásilnit, udělat „jinak“.

Ke správným technikám vás Rails, podobně jako Ruby, nenutí, jen je doporučují. Klasické vyjádření Yukihira Matsumota zní: „Globální proměnné začínají znakem dolaru. To vypadá dost ošklivě, takže vás to odrazuje od jejich používání“ (Přednáška „The Power of Ruby“). Je to ošklivé, takže by se to tak nemělo dělat… máloco shrnuje filosofii Ruby tak výstižně. Právě z těchto pozic vycházel David Heinemeier Hansson, když Rails navrhoval.

„Pohleďme na vývojáře. Po jeho levici stojí ďábel, po jeho pravici anděl. (…) V určitých situacích a za určitých podmínek je ďábel mocnější než anděl. (…) Ďábel praví například: ó, na tom nezáleží — tohle můžeš vždycky vylepšit později, k tomu se můžeš vždycky vrátit, nezáleží na tom, zda Petr ví, jak tohle funguje, ty víš, jak tenhle algoritmus funguje, a to z tebe dělá cenného zaměstnance. (…) Snažíme se ze všech sil, abychom do Rails vtělili anděla. [Vezměte si například] tyto konvence. Snažíme se, aby pro vás v Rails bylo jednodušší dělat věci správně a čistě než hackovat. Musíte se dost snažit, aby se vám povedlo udělat něco ošklivého. Musíte hrubě porušit nějakou konvenci a přidat nějakou konfiguraci, abyste vytvořili něco nekonzistentního. (…) Všude v Rails se snažíme klást tyto „pozvánky“, jak dělat věci lépe.“
~ David Heinemeier Hansson: Happy Programming and Sustainable Productivity with Ruby on Rails, přednáška na konferenci Future Of Web Applications, únor 2006

O vztahu mezi controllery a views tedy již víme hodně z koncepčního i praktického pohledu. Vynikající instruktáž o views v angličtině naleznete mj. v epizodě „All about layouts“ na Railscasts, kde Ryan Bates pravidelně publikuje screencasty o Rails.

Jak ale Rails předávají data do views? K tomu jsme se ještě nedostali. Je to opět velmi prosté: proměnné, které controller nastaví, jsou přístupné ve view. Představme si typický scénář, kdy chceme mít ve view dostupný objekt, obsahující data o článku s ID 1. (Tomu odpovídá URL ve známém tvaru: http://www.example.com/article/show/1.) Pomocí ActiveRecord data přečteme z databáze a uložíme do proměnné @article. (Zavináč před názvem proměnné znamená, že proměnná bude platit pro celou instanci controlleru a bude dostupná i ve view. Pokud bychom proměnnou nazvali article (bez zavináče), platila by pouze v rozsahu metody show — tedy jako lokální proměnná. O proměnných v Ruby si povíme více v některém z dalších článků.)

V controlleru tedy napíšeme:

# app/views/controllers/article_controller.rb
class ArticleController < ApplicationController

  def show
        @article = Article.find(params[:id])
  end

end

Ve view pak proměnnou @article můžeme jednoduše použít:

# app/views/article/show.rhtml
<h1><%= @article.title %></h1>
<div><%= @article.body %></div>
<hr />
<p>Publikováno dne: <%= @article.published_at %></p>

Výraz <%= otevírá onu zmíněnou „díru“ v HTML, kam prostřednictvím Embedded Ruby vypisujeme dynamický obsah (např. název článku: @article.title). V určité analogii odpovídá výrazu <?= v PHP. Pokud chceme v šabloně použít jinou logiku než prostý výpis proměnné do stránky, např. ověřit nějakou hodnotu pomocí if, použijeme podobný výraz bez rovnítka:

<% if @user.is_admin? %>
    <h2>Statistické informace o aplikaci:</h2>
    <p>Přihlášených uživatelů: <%= @application.logged_users_count %></p>
    ...
<% end %>

Tento přístup samozřejmě v jistém smyslu otevírá Pandořinu skříňku pro HTML prošpikované nekonečnými if … else sekvencemi, pro příliš logiky v šabloně. Rails jsou v tomto smyslu jednak nesmiřitelně pragmatické, jednak správné techniky doporučují, nikoliv vnucují, jak jsme probírali výše. Použití Embedded Ruby dává šablonám velkou moc — je na intuici a uvážení vývojáře, zda bude do šablony vkládat nepřehledné kusy logiky a jiné hacky či nikoliv. Čistě teoreticky lze tedy v HTML šabloně Rails napsat jakýkoliv Ruby kód, includovat knihovny, připojit se k databázi, a podobně.

V kontextu Rails je však takové nebezpečí relativně malé. Díky úspornosti a expresivitě Ruby každý nepřehledný kus kódu trčí ze šablony ven „jako šídlo z pytle“. Správné postupy, kterým se lze učit nejenom z ustrojení Rails samotných, ale i z ukázkových Rails aplikací, vás na dobré cestě vedou.

Podstatnější z praktického pohledu ale je, že Rails obsahují mnoho nástrojů pro to, že k hackování ve špatném slova smyslu nikdy ani nedojdeme. Jedním z těchto nástrojů jsou parciální šablony (partial templates), o nichž si povíme v některém článku, zabývajícím se Ajaxem. Daleko silnějším nástrojem je koncepce helperů, pomocných metod, do nichž se přesunuje logika z view. Rails obsahují mnohé helpery zabudované a disponují velmi transparentním mechanismem, jak si tvořit vlastní. O helperech si povíme hned v příštím článku, společně s výkladem o generátorech a konzoli, neocenitelných pomocnících při každodenním vývoji. Naše úvodní série článků skončí výkladem o pluginech pro Rails, tedy o práci energické komunity vývojářů, která nám může vlastní vývoj usnadnit a naše přemýšlení o webových aplikacích třeba nasměrovat na úplně jinou cestu…

Velké poděkování patří Vítku Burdovi za nepolevující kritický zrak, nezkalený „dobrým srdcem“ =)

Setkání v Praze

2007-06-28T10:31:00+00:00

Přijďte na setkání spřízněných duší okolo Ruby a Ruby on Rails na Letnou!

Jiří Kubíček z Railshosting.cz pořádá příští středu setkání zájemců o Ruby a Ruby on Rails v Praze na Letné. Pokud si plánujete příští týden, tak si středu 4. 7. 19:00 rezervujte. Já i mí kolegové rozhodně jdeme, takže přijďte, ať si můžeme o všem popovídat naživo a potkáte Ruby/Rails spřízněné duše.

Aktuální informace naleznete na forum.rubyonrails.cz. Tamtéž potvrzujte svou účast, ať může Jiří provést rezervaci příhodného lokálu!

Mám připravený další článek (dokončení úvodu), který by měl vyjít někdy v průběhu víkendu. Hned poté se můžete těšit na oznámený článek o Rails z pohledu projektového manažera, který mi přihrál Martin Michálek na blogu Vzhůru dolů.

Jak vidíte na obrázku níže, těch, které Rails zajímají, začíná být relativně dost i v Čechách! Díky všem za odkazy, za povzbudivé komentáře a e-maily!

Ruby on Rails a revoluce ve vývoji pro web. Část druhá: Active Record

2007-06-16T23:00:00+00:00

V prvním článku o Ruby on Rails jsme si osvětlili principy, na nichž je založen jazyk Ruby, základ celého frameworku. V tomto článku se budeme zabývat základními východisky Rails a elementu, který je nejlépe dokládá: abstraktní vrstvě Active Record.

V prvním článku o Ruby on Rails jsme se zabývali základními filosofickými principy, na nichž je založen jazyk Ruby — jazyk, v němž jsou Rails napsány a v němž jsou psány Rails aplikace. Viděli jsme, že jeho úsporná syntaxe je navržena tak, aby se programátorovi nepletla do cesty, a umožnila mu co nejsnazší a nejelegantnější vyjádření „myšlenky“:

5.times { print "Hurá! " }
=> ‚Hurá! Hurá! Hurá! Hurá! Hurá!‘

V tomto článku bych se chtěl věnovat tomu, co dělá Rails tím, čím jsou. Jestliže nevíte o Rails nic nebo téměř nic, než budete číst dál, podívejte se na patnáctiminutové video v angličtině, kde autor naprogramuje kompletní blog: Creating a weblog in 15 minutes.

… hotovo? Tak můžeme jít dál. Video je samozřejmě působivé a jsou v něm jasně vidět inspirační zdroje v Ruby. Asi je vám jasnější, proč Computerworld zařadil Rails mezi pět nejvýznamnějších technologií pro rok 2007. Napsat funkční aplikaci v čistém kódu a s použitím transparentních abstraktních vrstev za čtvrt hodiny je slušný výkon.

Video také naznačuje odpověď na otázku, proč David Heinemeier Hansson (dále jen DHH) Ruby on Rails vytvořil: protože ho bavilo vidět výsledky své práce, ale nebavila ho práce samotná („Happy Programming with Ruby On Rails“). Takže po pěti letech vývoje různých aplikací v PHP vytvořil — víceméně jako „vedlejší produkt“ při práci na projektu Basecamp — framework Rails. (Pro nabízející se srovnání Ruby s PHP a celou diskusi „nechápu, proč jsi Basecamp neudělal v PHP“ čtěte archivní diskusi na toto téma.) Oproti „běžné práci“ webového vývojáře vzniká výsledek v uvedeném videu snad jakoby sám od sebe, aplikace roste jako živý organismus.

Proč je tomu tak? Protože autor nedělá a především nevymýšlí žádné „nutné a nudné“ postupy: konfigurace, mapování URL, nepíše ani SQL dotazy. Všechny tyto základní věci se dějí jakoby „samy od sebe“. Autor se zabývá jen logikou aplikace samotné. Proč je tomu tak? Protože:

„Toto je sněhová vločka. Vaše aplikace není jedna z nich. Většina věcí, které většina lidí dělá, není nijak unikátní. Vaše potřeby nejsou nijak ‚zvláštní‘.“
~ David Heinemeier Hansson, přednáška na konferenci Future Of Web Applications, únor 2006

Konvence má přednost před konfigurací

Nejste unikátní – to je naprosto klíčový princip designu Rails: webové aplikace jsou si v podstatě podobné jako vejce vejci. Načítají data z databáze, transformují je do datových struktur programovacího jazyka (pole, hashe, objekty), provádějí s nimi manipulace (řazení, filtrování, transformace textů), vypisují je do HTML, a prostřednictvím formulářů je zase sbírají, provádějí s nimi manipulace a ukládájí je do relačních databází. Interaktivita aplikace je tvořena odkazy a formulářovými prvky, které načítají různá URL.

Problém je v tom, že začínat psát běžnou webovou aplikaci v PHP od příkazu mysql_connect a zabývat se dotazy do databáze typu SELECT * FROM articles ORDER BY published_at je absurdně vyčerpávající a nevýhodné. Proto vstupuje na scénu záležitost zvaná framework, byť by to byly jen dvě třídy na abstrakci připojení k databázi a na generování formulářů. Enterprise řešení s sebou zase většinou přinášejí takovou zátěž konfigurace, nastavování, provázání technologií nebo závislosti na platformě, že je v běžném provozu používají jen specifické projekty.

Proto se DHH rozhodnul ctít hlavní pravidlo: konvence má přednost před konfigurací. V určité analogii s Paretovým principem tvrdí, že většina frameworků selhává proto, že se snaží řešit všechno, všechny možné případy, abstrahovat až na úplně nejvyšší úroveň, a fetišizuje „teoreticky čistá řešení“. Hlavní pravidlo designu Rails pak konkrétně znamená např. to, že autor konfiguruje v aplikaci pouze to, co se liší od běžného nastavení — vytvoří-li tedy např. model Person, aplikace bude data automaticky hledat v databázové tabulce people (tedy v tabulce, která se jmenuje stejně jako model, avšak v množném čísle). Chce-li, aby aplikace načítala data z tabulky staff, musí tak učinit výslovně.

Ještě uvidíme konkrétně, jak Rails filosofii „nejjednodušší řešení je zpravidla nejsprávnější“ (viz Occamova břitva) uplatňuje prakticky ve všech svých hlavních rysech. Ale už jen díky tomuto svému přístupu: „Flexibilita je přeceňována. Omezení jsou osvobozující“ Rails vnesly do nekonečných technických debat o rychlosti interpreterů, o tom, jestli je XML lék na všechno, správném pojetí objektově orientovaného programování, a podobně, nikoliv pravdu, ale čerstvý vítr. Pojďme se tedy podívat na principy, na nichž jsou Rails postaveny.

Model-View-Controller

Vyjdeme-li z definice v prvním článku o Ruby on Rails, Rails jsou Model-View-Controller framework. Co to přesně znamená?

Model-View-Controller (dále MVC) je ustálený návrhový vzor v softwarovém vývoji, způsob, jak transparentně oddělit různé části aplikace (lhostejno či webové nebo desktopové) podle toho, jakou úlohu v ní hrají. Model se stará o čtení a zapisování dat a o manipulaci s nimi („Vrať mi seznam osob, kde název zaměstnavatele je ‚Škoda Auto‘, seřazený vzestupně podle příjmení“); data předává controlleru. Controller (česky někdy zvaný řadič) se stará o příjem vstupů ze strany uživatele aplikace („Proveď akci definovanou pro kliknutí na odkaz ‚Telefonní seznam‘“) a distribuci výstupů („Načti stránku s identifikátorem ‚telefonni-seznam‘“). View (česky zvaný též pohled, v kontextu webu též šablona) obsahuje grafické rozhraní aplikace samotné, s definovanými ovládacími prvky (tlačítka, roletky, odkazy, …) a „dírami“, do nichž se leje obsah, který do view předává controller.

Jestliže se podíváme na strukturu Rails aplikace, mělo by nám tedy být již pár věcí docela jasných:

app
- controllers
- helpers
- models
- views
…

Ve složce app se nacházejí složky pro controllery, modely, i view. Tyto tři složky jsou srdcem Rails aplikace. Jaké jsou tedy konkrétní součásti Rails z pohledu MVC?

Převedení dat z relační databáze na objekty Ruby (object-relational mapping), které zajišťuje Active Record (M)
Směrování (routing) — mapování URL na vnitřní řídící prvky: controllery a jejich metody (funkce) a předávání dat mezi controllery a views (HTML šablonami) (C a V)
Pomocné metody pro práci s HTML formuláři, Ajaxem, formátování řetězců, data a času a rozšíření Ruby tříd (M a V)

Další klíčové součásti Rails jsou:

Skripty pro generování kódu, tedy např. šablon pro modely nebo controllery, tzv. lešení (scaffolding) aplikace, a dalších (script/generate)
Konzole pro přímou interakci s modely běžící aplikace na příkazové řádce (script/console)
Komunita a sdílení kódu — nejlepší kód je ten, který nemusíte psát. Tedy pokud nejste sněhová vločka. :)

Těchto šest oblastí nám dává dobrou představu o tom, jak jsou Rails uspořádány, a zároveň na nich lze dobře demonstrovat, v čem spočívá jedinečnost a elegance Rails. V tomto článku si projdeme pouze bod první, tedy Active Record — ostatním bodům se bude věnovat článek následující.

Active Record

Active Record je srdcem každé Rails aplikace. Tvoří jádro frameworku, a dokonale demonstruje intelektuální principy, na nichž jsou Rails založené, proto se u něj zdržíme nejprve a nejdéle.

Jak již bylo řečeno, Active Record je návrhový vzor, který mapuje databázové tabulky na třídy a převádí řádky na objekty (tedy instance tříd) a sloupce na jejich atributy: z názvu třídy (Article) odhadne název tabulky (articles). (Pro tento odhad obsahuje jednoduchou implementaci anglického slovníku, která je snadno rozšiřitelná.) Zároveň v implementaci Rails obsahuje výkonné nástroje na práci s daty (čtení, zápis, validace) a pro vztahy mezi tabulkami–objekty (ono Post has_many :comments, známé z podcastu).

To znamená, že odstiňuje vývojáře od „surového SQL“ (SELECT * FROM articles WHERE id = 1), od „vlastnoručního“ převádění výsledků dotazu na nativní datové entity a umožňuje efektivní práci na daleko vyšší úrovni. Zde je velmi dobře zřetelný intelektuální přínos Rails: 90% práce práce webového vývojáře spočívá právě v nekonečném psaní databázových dotazů SELECT ..., SELECT ... LEFT JOIN ..., UPDATE ... WHERE ..., případně v jejich konfiguraci pro nějaké obalující třídy či metody. To je samozřejmě z hlediska efektivity absurdní: pamatujeme si Matzovo diktum „čím více kódu, tím více chyb“. Jestliže se v 80% procentech případů nazývá tabulka v databázi stejně jako model, pouze v množném čísle (což dává logiku, obsahuje totiž více objektů, zatímco model reprezentuje povětšinou jeden objekt), nemá smysl tento fakt dokola a dokola potvrzovat v konfiguraci.

Proto místo dotazu SELECT * FROM articles WHERE id = 1, který nám k vrátí data:

+----+-------------+--------------------+--------+---------------------+
| id | title       | body               | author | created_at          |
+----+-------------+--------------------+--------+---------------------+
|  1 | Lorem Ipsum | Dolor sit amet ... | Cicero | 0000-00-00 00:00:00 | 
+----+-------------+--------------------+--------+---------------------+

v Rails vytvoříme třídu Article (ano, následující kód je úplný, nejsou potřeba inicializační ani žádné jiné metody):

class Article < ActiveRecord::Base
end

a napíšeme Article.find(1). Dostaneme objekt s příslušnými atributy:

--- !ruby/object:Article 
attributes: 
 id: "1"
 title: Lorem Ipsum
 body: Dolor sit amet ...
 author: Cicero
 created_at: 0000-00-00 00:00:00

Pokud bychom mermomocí chtěli, aby model používal tabulku clanky, myimportantprefix_articles, nebo jinou, není nic snazšího:

class Article < ActiveRecord::Base
  set_table_name "clanky"
end

Tím však možnosti, které nám Active Record pro efektivní práci při získávání dat dává, nekončí. Kromě prostého find, které hledá záznam dle sloupce id, můžeme využít jeho varianty:

Article.find(:all, :order => 'created_at DESC') nám vrátí všechny záznamy v tabulce articles seřazené sestupně dle data
Article.find_all_by_author('Cicero', :order => 'title') nám vrátí všechny záznamy konkrétního autora seřazené vzestupně podle názvu (tyto metody se v Rails nazývají dynamické dotazy, dynamic finders)
Article.find_all_by_author_and_title('Cicero', 'Lorem Ipsum') ukazuje, jak můžeme dynamické dotazy kombinovat

Bylo by asi ztrátou času vypisovat zde příslušné SQL dotazy, abychom si ukázali, kolik znaků (a tím i příležitostí k chybám) a energie jsme si ušetřili. Dynamické dotazy navíc krásně ukazují sílu objektově-relačního mapování.

Řekli jsme ale, že Active Record nám dává nástroje nejenom pro získávání dat, ale i pro manipulaci s nimi. Co když tedy chceme změnit některý atribut daného záznamu/objektu?

article = Article.find(1)
article.author = 'Seneca'
article.save

Jednodušší to být nemůže. Změním atribut objektu a ten uložím. Vypisovat zde ukázkové dotazy 'SELECT FROM ... UPDATE ... SET author='.$author.' WHERE id='.$id.', důvěrně známé všem webovým vývojářům, je pravděpodobně opět zbytečné: absolutní rozdíl v úrovni přístupu je zřejmý sám od sebe. Třídy odvozené od Active Record obsahují pochopitelně i metody create a destroy pro vytváření a mazání záznamů. (Active Record v Rails obsahuje také metodu find_by_sql pro specifické případy složitých dotazů, nebo například dotazů, které je třeba silně optimalizovat. Princip „konvence má přednost před konfigurací“ neznamená, že „konfigurace“, tedy odchylka od obvyklého, není možná.)

To ale stále není všechno, co nám Active Record poskytuje. Mapovat data z tabulek na „pole“ koneckonců umí kdekterá vlastnoručně stvořená knihovna pro PHP obalující připojení k databázi. Detailní popis Active Recordu přesahuje tento článek, ale pro naše ilustrační potřeby zmíníme dvě vlastnosti: validaci vstupních dat a vztahy mezi objekty.

Validace vstupních dat je jednou ze základních podmínek bezpečnosti a správné funkce webových aplikací. Přesto je přístup mnoha programátorů k ní více než laxní. Implementace Active Record v Ruby on Rails má funkce pro validaci zabudované. Vezměme si tedy definici třídy Article:

class Article < ActiveRecord::Base
  validates_presence_of :author
end

V prostém jazyce říká, že atribut author nesmí být prázdný (article validates presence of author), tedy jinými slovy: článek musí mít autora — což je logické. Co se tedy stane, když se pokusíme uložit článek, který nemá autora, tedy: jehož atribut author je prázdný řetězec?

article = Article.find(1)
article.author = ''
article.save!
=> ActiveRecord::RecordInvalid: Validation failed: Author can't be blank

Boom! Autor nesmí být prázdný. (Vysvětlení pro nadprůměrně všímavé: zatímco metoda save z prvního příkladu vrací hodnoty true nebo false podle toho, zda se povedlo záznam uložit, bang-metoda save! z druhého příkladu při neúspěchu operace vyvolá definovanou výjimku. K bang-metodám se ještě v rámci výkladu o Ruby vrátíme v některém z příštích článků.) Platí totéž, co pro ukládání záznamu výše: jednodušší to být nemůže. Připočteme-li k tomu to, že Active Record je v Rails implementovaný tak, že formuláře jsou předvyplněny hodnotami objektu, že při neúspěšném uložení Active Record vrací chybu pro každý atribut (a můžeme ji tedy snadno vypsat k příslušnému poli) a že mezi další validační funkce patří např. validates_length_of, validates_uniqueness_of, validates_format_of (využívající regulární výrazy), je opět zjevné, kolik kódu nám Rails šetří, kolik kódu vůbec nemusíme psát.

Poslední vlastností Active Record, kterou se v našem úvodu budeme zabývat, je podpora pro vztahy mezi objekty. Náš příklad s třídou Article totiž neodpovídá vývoji ve skutečném světě. Těžko bychom ve skutečné aplikaci měli autory článků uložené ve sloupečku tabulky articles. Ne, vyčlenili bychom pro ně zvláštní tabulku, pravděpodobně tabulku s názvem authors. Článek může mít více autorů, autor může napsat více článků, jde tedy o vztah n ku m. Rails je, jak dobře víme, framework pro skutečný svět, ne pro zjednodušené tutoriály, a proto nám poskytuje nástroje i pro relativně složité vztahy mezi entitami podobného typu. Stačí nám jen dobře definovat vztahy v deklaraci tříd (tento kód je opět úplný, pro pouhé vzájemné propojení tabulek-objektů více nepotřebujeme):

class Article < ActiveRecord::Base
  has_and_belongs_to_many :authors
end

class Author < ActiveRecord::Base
  has_and_belongs_to_many :articles
end

Nyní tedy vytvoříme nový článek, nového autora, a autora k článku přiřadíme:

article = Article.new
article.title = "Lorem Ipsum"

cicero = Author.new
cicero.name = "Cicero"
cicero.email = "cicero@senatus.gov"
cicero.save!

article.authors << cicero
article.save!

To nebylo těžké. Když se nyní podíváme na objekt article, vidíme, že obsahuje pole s autory:

>> print article.to_yaml
--- &id002 !ruby/object:Article 
attributes: 
  body: 
  title: Lorem Ipsum
  id: 2
  created_at: 2007-06-16 02:23:40.124124 +02:00
authors: 
- &id001 !ruby/object:Author 
  attributes: 
    name: Cicero
    id: 3
    email: cicero@senatus.gov

Zrovna tak z druhé strany, pokud bychom chtěli dostat seznam Ciceronových článků:

>> print cicero.articles.to_yaml
--- 
- !ruby/object:Article 
  attributes: 
    body: 
    title: Lorem Ipsum
    id: "2"
    author_id: "3"
    article_id: "2"
    created_at: 2007-06-16 02:23:40

(Vysvětlení: metoda to_yaml, kterou v uvedených příkladech používáme, je upomínkou další silné zbraně Rails: formátu YAML, tedy „XML pro lidi“: způsobu čitelného zápisu strukturovaných dat. Rails jej využívají jednak pro konfigurace — např. připojení k databázi (/config/database.yml) —, tak pro čitelné výpisy datových struktur — např. pro ladění programu.)

A jak nyní vypadají tabulky (articles, authors, articles_authors) v databázi? Žádné velké překvapení nás nečeká:

<caption>mysql>select * from articles;</caption>

id	title	body	created_at
2	Lorem Ipsum	NULL	0000-00-00 00:00:00

<caption>mysql>select * from authors;</caption>

id	name	email
3	Cicero	cicero@senatus.gov

<caption>mysql>select * from articles_authors;</caption>

article_id	author_id
2	3

V grafickém vyjádření pak vztahy vypadají takto:

andbelongs_to_many" />

Sloupce v tabulkách articles a authors odpovídají atributům našeho objektu, tabulky jsou na sobě nezávislé. Jejich propojení zajišťuje zvláštní tabulka s názvem articles_authors, která obsahuje dva sloupce pro definici vztahu mezi článkem a autorem: article_id a author_id. To, co vypadá tak logicky, samozřejmě a jednoduše, je samozřejmě výsledkem složité odhadovací logiky v Rails, nikoliv projevem nějaké inteligence stroje. Stroj neví a sám od sebe nemůže vědět, že tabulka s definicemi vztahů se jmenuje articles_authors. To, že nemusíme stroji všechny tyto „logické“ a „samozřejmé“ fakty stále dokola a dokola sdělovat, je výsledkem aplikace několika prostých pravidel:

Deklarace has_and_belongs_to_many v modelech zajistí, že Active Record je bude považovat za propojené a přidá přístupové metody k propojeným objektům, např. ono cicero.articles, použité v příkladu. Has_and_belongs... je poměrně složitý název pro vztah n ku m. Je odvozen z direktiv pro vztah 1 ku n: has_many pro rodičovský objekt („Článek má mnoho komentářů“) a belongs_to („Komentář patří ke článku“) pro jeho děti. Ve vztahu n ku m jsou objekty ve složitějším vztahu: „Článek má mnoho autorů. Autor má mnoho článků.“.
Rails se v takovém případě podívají do databáze, zda najdou tabulku, jejíž název je tvořen názvy tabulek pro dané objekty, oddělené podtržítkem, v abecedním pořádku, tedy: articles_authors. Pokud byste chtěli nebo potřebovali, aby tato tabulka měla jiný název, řekněme authors_to_articles, žádný problém, jde o jednoduchou konfiguraci vztahu v modelu: Class Author ... has_and_belongs_to_many :articles, :join_table => "authors_to_articles".
Tabulka definující vztah pak má dva sloupce: article_id a author_id (každému vztahu odpovídá jeden řádek). I tyto parametry je možné konfigurovat — chceme-li, aby se klíč vztahu jmenoval jinak, není problém: Class Author ... has_and_belongs_to_many :articles, :foreign_key => "clanek_id".

Nejsou v tom tedy žádná kouzla. Kouzla způsobuje lidmi vymyšlený a napsaný kód v hlubinách Rails. Je to ale kód, který vy nemusíte vymýšlet a který vy nemusíte psát. Kouzla jsou způsobena důslednou aplikací principu konvence má přednost před konfigurací v implementaci Active Record. Není důvod konfigurovat název tabulky, je-li v drtivé většině případů utvořen jako množné číslo od názvu třídy. Není důvod konfigurovat tabulku vztahů, jmenuje-li se v drtivé většině případů jako název první tabulky podtržítko název druhé tabulky. Všechna data je třeba na vstupu validovat, proto je ošetření vstupních dat zabudováno přímo v Active Recordu.

To ale není všechno. V běžné webové aplikaci potřebujeme běžně ještě další nástroje na práci s daty: sčítání, výpočty průměrných hodnot, hledání pomocí LIKE, … Active Record v Ruby On Rails nám dává nástrojů mnohem více:

# Kolik článků napsal Cicero?
print cicero.articles.count
=> 1

# Vrať mi články od Cicerona, které začínají na ‚Lor‘ 
cicero = Author.find_by_name('Cicero')
print cicero.articles.find(:all, :conditions => "title LIKE 'Lor%'").to_yaml
=> --- !ruby/object:Article 
   attributes: 
     body: 
     title: Lorem Ipsum
     id: "2"
     author_id: "3"
     article_id: "2"
     created_at: 2007-06-16 02:23:40

Jak je snad z předchozího výkladu o Active Record vidět, Ruby on Rails nejsou „nějaký“ webový framework. Jeho intelektuální úroveň je zcela jedinečná: díky kombinaci promyšlené konfigurace a použití akademických vzorů, jako je Active Record, a zároveň nemilosrdně pragmatického přístupu k vývoji dávají vývojáři do ruky silný nástroj, který nemá jen tak nějaké srovnání.

V dalším článku výklad o Active Record doplníme o možnosti, které mu přidávají pluginy acts_as_attachment a acts_as_list, nejprve se však budeme věnovat zbylým slíbeným bodům.

Komplexní výklad Active Record naleznete v knize Agile Web Development with Rails, doposud nejlepší výukové a zároveň referenční knize o Rails, o níž si někdy také něco povíme.

Ruby on Rails a revoluce ve vývoji pro web. Část první: Ruby

2007-06-16T22:00:00+00:00

Framework pro vývoj webových aplikací a stránek Ruby on Rails je v posledních dvou letech jedním z nejžhavějších témat mezi webovými vývojáři. Běží na něm nejslavnější aplikace „Webu 2.0“, usnadňuje tvorbu Ajaxových vychytávek a stal se slavným díky videu, kde autor naprogramuje za patnáct minut kompletní blog včetně administrace. V češtině o něm existuje zatím velmi málo informací obsahujících více než několik tezí a ukázek, a následující tři články by měly tuto díru alespoň částečně zaplnit.

Framework pro vývoj webových aplikací a stránek Ruby on Rails si za poslední dva tři roky získal takovou slávu, že jedni jsou nadšeni zcela nad míru běžně obvyklou a kážou Rails kudy chodí, druzí mluví o „pouhé módě“, „skvělém marketingu 37 Signals“ a „zbytečném hype“.

Z pohledu na významné vývojářské blogy či weby nebo videa, kde v patnácti minutách naprogramujete kompletní blog člověk rozhodně získá dojem, že Rails jsou mýtická „stříbrná kulka“ softwarového vývoje, technologie, jejíž pouhé použití či nasazení několikanásobně zvyšuje produktivitu. A k dovršení všeho na Ruby on Rails běží nejslavnější aplikace a stránky současného webu: Basecamp, Shopify, Cork'd, A List Apart či Twitter.

Není třeba si tedy klást (řečnické) otázky jako „Je Ruby on Rails stříbrná kulka?“ a podobně, ale můžeme rovnou vyložit karty. Řekněme to narovinu:

Jestliže se zabýváte vývojem pro web, Ruby on Rails je to nejzajímavější, co se za poslední dva roky na tomto poli objevilo. Rails je killer app webového vývoje.

Panebože! Slyším ty výkřiky! Ne Ajax? Ne PHP 5? Ne Script.aculo.us? Ne … Zend framework? Ne Adobe Apollo... tedy AIR? Ne. A nejenom proto, že Rails v sobě Ajax i Script.aculo.us zahrnují (a v jistém smyslu, k němuž se vrátíme, teprve akcelerují, neboli „staví na koleje“).

Rails jsou jedinečné (a v tomto smyslu „nejzajímavější“) proto, že kromě mnoha ryze technických konceptů a inovací vnesly do webového vývoje zásadní intelektuální koncepty a nové myšlenky. To je ohled, který v debatách ohledně Ruby on Rails pravidelně zapadá. Debaty ohledně Rails totiž trpí známým syndromem „to není nic nového pod sluncem“. Poučná je v tomto smyslu debata k článku „Proč bylo Ruby on Rails možné napsat pouze a jedině v Ruby?“. V ní se diskutující pravidelně vracejí k objevné myšlence, že „to samé“ je možné udělat v Pythonu nebo v Perlu, že Model-View-Controller není nic nového, že lepší než Rails je framework Django pro Python nebo Catalyst pro Perl. A další variace: to umí .NET/Java/atd. už dávno a líp, a navíc mají IDE, a striktní typování. PHP je rozšířenější, a rychlejší, a levnější na provoz. A s „free-hostingem“. Jenže na webu se nyní o ničem nemluví s takovým nadšením jako o Rails, a jasná volba pro všechny obdivované start-upy není ani .NET, ani Python. Ani PHP.

Tato diskuse totiž posuzuje Rails z omezeně technologického pohledu. A z omezeně technologického pohledu je Ruby on Rails skutečně jen další MVC webový framework. Co však Rails činí zajímavé a jedinečné jsou netechnické (ve striktním slova smyslu), intelektuální a sociální aspekty, kterými se chci zabývat v těchto článcích. Právě ty ve vývojářích vyvolávají pocit „všechno v Rails a už nikdy jinak“ a právě ty vyvolaly mohutnou vlnu nadšení a nové energie pro vývoj na webu. Postoj „všechno už tu bylo, všechno je pořád stejné, je to prostě práce“ jistě v nikom příliš entuziasmu nevzbudí. Nejprve však krátký úvod či opakování.

Co je Ruby a co je Ruby on Rails

Ruby on Rails je vývojový framework postavený na bázi vzoru Model-View-Controller (podobně jako za všechny např. Apache Struts či klon Rails pro PHP CakePHP), který automaticky mapuje URL na vnitřní řídící prvky aplikace, abstrahuje přístup k datům v databázi pomocí Object-relational mapping („řádky“ v databázi se převedou na instance objektů, „sloupce“ na jejich atributy) a obsahuje rozsáhlé pomocné knihovny pro snadné generování HTML, práci s Ajaxem, formátování dat a další. „Naučit se Ruby on Rails“ tedy znamená seznámit se s konvencemi a principy, na nichž je postavené („kde jsou šablony?“, „jak zpracuji data z formuláře?“) a naučit se programovací jazyk, který Rails používají: Ruby. Protože Ruby je základem frameworku Ruby on Rails, a jeho koncepce Rails zásadně ovlivnila, zastavíme se nejprve u něj.

Ruby, tedy programovací jazyk samotný, v němž jsou Rails napsány a v němž píšete Rails aplikace, je relativně nový jazyk, který vytvořil Yukihiro Matsumoto („Matz“), a který vychází ze základního principu: programování je tvořivá činnost, která vám má přinášet radost:

„Věřím, že — alespoň do jisté míry — je smyslem života být šťastný. Na základě tohoto přesvědčení je Ruby navrženo tak, že je nejenom snadné, ale i zábavné v něm programovat. Ruby vám umožňuje soustředit se na kreativní stránku programování, a nepřidělává vám další starosti.“
~ Yukihiro Matsumoto, předmluva k prvnímu vydání knihy Programming Ruby

Podobnou větu v předmluvě k referenční příručce programovacího jazyka by pravděpodobně čekal málokdo. Ostatní principy Ruby jsou však z tohoto základního principu odvozené — přestože se podobné uvažování o softwarovém vývoji může zdát hardcore geekům trochu divné. Výchozí motivací Matsumota bylo vytvořit jazyk, s nímž bude radost pracovat a který dá programátorovi co nejkomfortnější vyjadřovací prostředky. Fakt, že to znamená dokonale objektově orientovaný jazyk, perfektně integrované regulární výrazy, snadno čitelnou, úspornou syntaxi a pohodlné iterátory typu 10.times {puts "ahoj"}, je přitom zcela vedlejší. Matsumoto se totiž přímo odvolává na hypotézu jazykového relativismu, která tvrdí, že vnímání světa a způsob myšlení je radikálním způsobem ovlivněno právě vyjadřovacími prostředky, tedy jazykem, kterým mluvíme. Tato hypotéza tvrdí nejenom to, že v různých jazycích myslíme různým způsobem. Ve své radikální podobě tato hypotéza v teorii Ludwiga Wittgensteina tvrdí, že to, co nemohu v jazyce vyjádřit, nemohu ani myslet (Filosofická zkoumání, §243 a následující).

Matsumoto tuto hypotézu vztahuje i na jazyky zvané programovací: programovací jazyk je totiž specifickým případem umělého jazyka, který má syntaxi, gramatiku i slovní zásobu, stejně jako jazyky přirozené. Vykládá ji tak, že čím pohodlněji se mohu vyjádřit, tím pohodlněji mohu i myslet — a v programování jde pochopitelně především o myšlení, o „výsledek“: o to, co má program dělat („nahradit všechny výrazy XXX v řetězci za YYY“, „vypsat všechny články z databáze publikované tento měsíc“, atd.). Syntaxe, gramatika, slovní zásoba, to jsou vyjadřovací prostředky, které usnadňují či znesnadňují vyjádření samotné — nejsou však vůči vyjadřované „myšlence“ nijak sekundární. Napsat program, který nahradí výraz XXX za YYY lze stejně tak v Javě, PHP, Ruby nebo assembleru, ale pohodlnost, s jakou tuto (triviální) myšlenku v jednotlivých jazycích vyjádříte, bude dost rozdílná. „V assembleru můžete napsat všechno. Nikdo ale už nechce psát v assembleru“ (Yukihiro Matsumoto, The Philosophy of Ruby).

Upozornění! Následující text srovnává syntaxi Ruby a PHP. Účelem srovnání není dokazovat, která syntaxe je „lepší“. Účelem je demonstrovat filosofii, na které je Ruby založena. Možná se vám tato filosofie bude zdát mylná, nepodstatná nebo lhostejná. Možná se vám bude zdát, že to je „stejně jedno“, že je jazyk jako jazyk a navíc je důležitější striktní typování, výkonnostní parametry nebo paletka Změnit všechny výskyty… ve „vašem IDE“. Pak vás následující argumentace asi nepřesvědčí.

Právě určitá expresivita jazyka, tedy snadnost, s jakou vyjadřuje myšlenky (programátora) je základní vlastností a rozlišovacím znakem Ruby. Rozdíl mezi „příkazem“, tak jak si jej v duchu řekneme, a skutečným kódem je v Ruby minimální. Srovnejte následující úryvek kódu v PHP, důvěrně známý všem webovým programátorům:

if ( !empty($this->email) ) echo $this->email;

Stejný úryvek v Ruby, resp. v rozšíření Rails:

print self.email unless self.email.blank?

Srovnání není určeno k posouzení toho, který jazyk je „lepší“, protože to vždy znamená otázku „lepší k čemu?“ nebo „lepší pro koho?“ a ty si zde neklademe, protože si je pokládá každý sám za sebe. Oba zápisy jsou si velmi podobné — na rovině syntaxe však první příklad připomíná spíše rovnici (matematický symbol negace, závorky), zatímco příklad druhý vypadá jako jednoduchá věta v přirozeném jazyce: „Vypiš proměnnou, pokud není prázdná“. Print something to screen, unless that something is blank — dokonce se správným slovosledem. Podmínka unless zde slouží jako modifikátor (modifier) příkazu print. To, který způsob zápisu se vám zdá přehlednější, záleží zčásti na tom, zda myslíte spíše „v rovnici“, nebo „ve větě“, a především na tom, na co jste zvyklí. Díky síle zvyku se často syntaxe Ruby zdá na první pohled „divná“. Ale při řešení abstraktních problémů je přeci jen většina z nás zvyklá přemýšlet „ve větách“, dal by se shrnout přístup Ruby.

„Vypiš proměnnou, pokud není prázdná“ je velmi, velmi triviální myšlenka. Tuto triviální myšlenku můžeme vyjádřit buď složitým, nebo jednoduchým zápisem. Symbol negace, striktní pravidla pro použití závorek — to vše je trivialitě oné myšlenky v zásadě cizí. V tom je tento příklad příznačný: programátoři webových aplikací velmi často na podobnou kontrolu hodnoty proměnné nedbají. Je otázka, zda a nakolik v tom má prsty přílišná striktnost syntaxe PHP. (Je přitom jisté, že chyby v nesprávně uzavřených nebo překřížených závorkách jsou v PHP jedny z nejčastějších.)

Vezměme si však jiný příklad, převzatý z nejoriginálnější učebnice jazyka Ruby, Why's Poignant Guide to Ruby:

5.times { print "Hurá! " }
=> ‚Hurá! Hurá! Hurá! Hurá! Hurá!‘

Five times print "Hurá", neboli „pětkrát napiš ‚Hurá!‘“ je opět věta v přirozeném jazyce, v angličtině, a opět se správným slovosledem. Vidíme, že zahrnuje „matematické znaky“ (složené uvozovky), ty ale slouží víceméně jako interpunkce — například pomlčky nebo čárky --, pro oddělení částí souvětí.

Tato „literární povaha“ je pro Ruby zcela zásadní a velmi ovlivnila právě framework Ruby on Rails. Jak říká vývojář Dan Benjamin: „Ruby vám umožňuje se skvěle vyjádřit, a nemusíte u toho psát tucty řádků komenářů — kód v Ruby je srozumitelný sám od sebe“. I programátor, který Ruby neovládá, velmi dobře porozumí kódu, jako je:

print ["banán", "citron", "ananas"].sort.last.capitalize
=> ‚Citron‘

„Porozumí“ přitom znamená: „odhadne výstup programu“, porozumí tomu, co program udělá (tedy oné „myšlence“), nikoliv nutně syntaxi. Důležité je, že uvedenému kousku kódu porozumí i neprogramátor se základní znalostí angličtiny, na rozdíl od identického kódu např. v PHP:

$a = Array("banán", "citron", "ananas");
sort($a);
print ucwords( end($a) );
=> ‚Citron‘

Z tohoto důvodu je Ruby oblíbeným a často používaným programovacím jazykem pro výuku programování. Jak říká autor knihy Learn to Program, Chris Pine, Ruby je ideálním jazykem pro výuku programování, protože psát v něm programy je za á snadné a za bé je to zábava. (Úplně jinou kapitolou v použití Ruby pro výuku programování je projekt Ruby artisty Why The Lucky Stiffa Hackety Hack, k němuž se zajisté ještě vrátíme.)

Na uvedených úryvcích kódu je ihned vidět jedna důležitá vlastnost Ruby: řetězení (chainability). Metody, které jsou volány na objektu (v tomto případě poli), vrací objekt samotný, takže lze volání metod řetězit a předávat si jej mezi nimi. (Řetězení prostřednictvím Rails ovlivnilo mnoho dalších projektů, typicky např. JavaScript frameworky Prototype.js, JQuery nebo Fry.)

Řetězení se neuplatňuje jen v případě triviálních operací jako je seřazení pole, ale i v daleko sofistikovanějších výstupech (s výjimkou přetypovací metody to_a, neboli to array je uvedený kód na první pohled srozumitelný):

# http://www.ruby-doc.org/stdlib/libdoc/net/http/rdoc/classes/Net/HTTP.html
require 'net/http' 
print Net::HTTP.get('www.google.cz', '/').match("<title>(.*)<\/title>").to_a.last
=> ‚Google‘

Podobně jako podmínkové modifikátory (print variable unless variable.blank?) je řetězení silnou zbraní Ruby, protože umožňuje psát velmi čitelný a úsporný kód: jak říká známý teorém o jazyce Python, „V úspornosti je síla“ (Succinctness is power). Nebo, jak praví známý aforismus, počítačový kód má být v první řadě čitelný pro lidi, a jen mimochodem též pro stroje.

Proč je tomu tak? Jak říká Matz: Úsporný kód znamená méně chyb — čím méně řádků kódu, tím méně chyb. A méně chyb znamená, že se cítíte chytřejší.

To je to, co Matz v uvedené přednášce nazývá „efektivita měřená počtem úderů do klávesnice“ (efficiency in keystrokes) — nikoliv efektivita z hlediska výpočetního výkonu, ale z hlediska produktivity. Úspornost a čitelnost kódu, snadno zapamatovatelná syntaxe bez obtížné „interpunkce“ — to vše slouží k tomu, aby se programátor mohl soustředit na „myšlenku“ a ne na to, jak ji vyjádřit. Lze říci, že všechny ostatní, ryze technické vlastnosti Ruby jsou podřízeny tomuto principu. Kruh se uzavírá:

Programujeme proto, že nás to baví. I když programujeme pro peníze, stejně chceme, aby nás to bavilo.
~ Yukihiro Matsumoto, přednáška na Brigham Young University

Proč tak rozsáhlý úvod do Ruby v článku, který má Ruby on Rails ve svém názvu? Protože základní principy Ruby zde shrnuté ovlivnily návrh celého frameworku Rails (ať již se jedná o princip „konvence má přednost před konfigurací“, o využití známých návrhových vzorů jako je Active Record, a další). Takže až potkáme podobný úryvek kódu:

# http://api.rubyonrails.com/classes/ActiveSupport/CoreExtensions/Numeric/Time.html#M000394
10.minutes.ago 
=> Sat May 26 19:52:58 +0200 2007

nebo:

# http://api.rubyonrails.com/classes/ActionView/Helpers/DateHelper.html#M000575
t = Article.find_by_id(1).published_at
=> Sat May 26 19:02:12 +0200 2007
time_ago_in_words(t) 
=> ‚about one hour‘

budeme přesně vědět, odkud vítr vane. Popularita Ruby skokově vzrostla právě díky Ruby on Rails — jak říká samotný Matz: „Rails jsou pro Ruby killer app“. Rails samotné se pak staly populárními díky tomu, že se přesně trefily do neuspokojivé situace na poli vývoje pro web, kterému vládlo (a vládne) PHP, se svými světlými i temnými stránkami, s nedostatečně ukotvenými pravidly vývoje, kdy každý vývojář objevuje Ameriku. Vzbudily v komunitě vývojářů nadšení, protože usnadnily práci s Ajaxem a vizuálními efekty a umožnily vývojářům soustředit se konečně na to, co chtějí udělat, než na to, jak toho dosáhnout. Co je ale na Rails tak fascinujícího, že o málokteré technologii se mluví s takovým nadšením? Proč prodeje knih o Ruby on Rails rostou na angloamerickém trhu nejrychleji z celé oblasti web designu? Právě tomu se bude věnovat další článek.

Poznámky a odkazy:

Všechny uvedené příklady Ruby si můžete vyzkoušet ve webové verzi konzole: http://tryruby.hobix.com/.
První vydání základní referenční příručky k Ruby, The Pickaxe Book, je přístupné online: http://www.ruby-doc.org/docs/ProgrammingRuby/
Pro neředěný zážitek z Ruby a s Ruby ovšem doporučuji dobrodružný cestopis Why's (Poignant) Guide to Ruby: http://www.poignantguide.net/
Pro další článek nemusíte znát nic více než ono video, které všechno začalo (alespoň v mém případě)

Poděkování patří Vítku Burdovi, Vráťovi Čermákovi, Petru Krontorádovi, Pavlu Šimkovi a Václavu Vančurovi za cenné podněty, připomínky, rady a opravy při přípravě článku.