Czechs And Slovaks On Rails

S menším zpozděním přináším reportáž o letošním ročníku konference Ruby en Rails, která se konala před dvěma týdny v Amsterdamu.

Zed Shaw

Prvním přednášejícím byl Zed Shaw, muž slavný díky autorství Mongrelu a hanopisu, kterým opustil Ruby komunitu. Tedy zdá se, že úplně neopustil, že? Prý ale navštěvuje pouze evropské konference, protože na těch jsou zakázány zbraně.

Jeho vystoupení bylo dle očekávání velmi vtipné, každý prý má dnes virtuální stroj a díky tomu si myslí, že všechno zázrakem zrychlí (zjevná narážka na YARV a Rubinius), on ale vyvinul "skutečný stroj" (literal machine) jménem EaRing, která je tedy nejrychlejší, protože kód rovnou pouští na procesoru. Pak chvíli ukazoval něco jako interpret assembleru a utahoval si z benchmarku na Fibonacciho číslech, jejichž výpočet byl pod hranicí meřitelnosti.

Přes lehkovážně laděný průběh prezentace byly hlavní myšlenky velmi zajímavé. Virtuální stroje pro dynamické jazyky podle Zeda nic zásadního neřeší, jsou třeba procesory a operační systémy tyto jazyky podporující. Také ukázal, že paralelizací na 200 procesorech se dá dosáhnout pouze šestinásobného zrychlení (kvůli overheadu, nemožnosti dalšího souběžného zpracovávání atd.). To ale jen s velmi dobrými programátory, s těmi průměrnými na tom budete o něco hůř a s těmi podprůměrnými (se kterými prý Zed snad pracuje výhradně) si podle něj klidně můžete pokusy o paralelizaci pohoršit.

Jak tedy podle Zeda zrychlit vaši aplikaci? Optimalizovat! "Pokud chcete mít program rychlejší, udělejte ho rychlejší." Zde také zdůraznil nebezpečnost metaprogramování, které kód znepřehledňuje a optimalizaci značně zesložiťuje.

Obie Ferndandez

Následoval Obie Fernandez, mimo jiné autor knihy The Rails Way. Jeho přendáška byla zdá se totožná s tou na letošní RailsConf: The Worst Rails Code You've Ever Seen (and how not to write it yourself), v podstatě ukázky všemožných chyb, kterých se nezkušení Rails programátoři dopouštějí a pár obecných tipů, jak to dělat lépe: naučte se dobře Ruby a možnosti RoR (a nevymýšlejte již vytvořené), následujte zažité Rails konvence (např. krátké metod v krátkých controllerech). Také vyhledejte senior programátory (20-30 let zkušeností), kteří vám budou skvělými mentory i bez znalosti Railsů (velmi rychle je začnou chápat), čtěte knihy (Chad Fowler a někdo další prý chystá knihu Rails anti-vzorech).

Pokud máte silnou náturu, podívejte se na slajdy (PDF) z prezentace, uvidíte opravdu zajímavé kousky a kusance kódu. Ačkoliv ty nejlepší byly ukázány mimo slajdy (např. controller s 1300 řádky a metodami "confirm" a "do_confirm")

Norbert Crombach

Norbert je holandská Ruby superstar, osnovu přednášky měl napsanou v textovém souboru (otevřeném ve vi), ze kterého postupně odmazával řádky. Přednáška byla celá programovaní naživo a provedla nás zajímavými vlastnostmi Ruby. Uvedu pár těch, které jsem neznal vůbec nebo poznal teprve nedávno.

To, že jakýkoliv kus kódu je možné uzavřít do begin-rescue-end bloku je jasné, ne moc dlouho ale vím, že hlavička metody slouží jako begin, tj. není třeba psát

def method
begin
..
rescue Exception => e
end

ale stačí

def method
...
rescue Exception => e
end

Zachytávat všechny potomky Exception ale není často vhodné, protože to zachytí například i systémové signály (např. SIGTERM), typicky je vhodnější chytat StandardError a z ní také dědit vlastní výjimky. Pak Norbert ukázal pár způsobů, jak zajistit větší oddělení kódu ve vašich modelech - vytvoří se pomocná třída, jejíž instanci pak v případě potřeby deleguje metody na "nadřazený" model (referenci na jehož instanci si drží). Zde padla důležitá poznámka, než něco slepě volat pomocí send je dobré si nejprve zjistit, jestli daný object volaní podporuje a dovoluje; pomocí respond_to?. Toto volání totiž nevrací true pro privátní metody.

Když jsem tak Norberta pozoroval, znovu jsem si uvědomil, jak je důležité pracovat v krátkých iteracích a přijít tak na problémy co nejdříve. Testy samozřejmě pro tyto jednoduché demonstrace nepsal, ale vždy po pár naimplementovaných řádcích vyzkoušel, že dělají, co čeká. Ne že by napsal dlouhou metodu a pak dlouze zjišťoval, kde všude jsou jaké chyby (což je zdlouhavé především kvůli frustraci, kterou to přínáší).

Možná někdo z vás neví, jak snadno lze získat všemožné šikovné metody modulu Enumerable. Stačí namixovat do vaší třídy, nadefinovat metodu each a je to.

Záver kromě *x == x.to_a patřil informaci o metodě tap z Ruby 1.9, která mi přišla že dělá to samé, co returning z activesupport, tj. umožní instanciovat, pracovat s objektem a nakonec ho i vrátit v jednom bloku:

def user_with_specials
 returning User.new do |user|
    user.set_something_special
    user.set_another_thing
 end
end

Úplně nakonec jsme si zase hráli s metaclassamy, ale to už všichni známe, že?

Ninh Bui & Hongli Lai

Tihle dva asijští Holanďani představili novou verzi jejich Phusion Passenger, dříve známému pod jménem mod_rails, jehož cílem je udělat Rails aplikace stejně snadno nasaditelné a rychle běžící jako ty v PHP. V kombinaci s jejich Ruby Entreprise Edition (obohacení Ruby o copy on write garbage collector) se jim to zdá se podle benchmarků daří (tj. není to rychlé jako PHP, ale je to nejrychlejší mezi ostatními alternativami pro Railsy)

Různé

Mluvilo se i o JRuby, ale to jsem si radši zkoušel hrát s Merbem. Mluvilo se i o testování, rcovu, cruisecontrol.rb, heckelu, flogu, ale to už všichni dospěláci znají. A prý průměrný programátor vytvoří 1000 řádek kódu ročně. Průměrný programátor je koukám samá lenost.

DHH

Nakonec iChat Q&A session s DHH. Celkem zajimavé, protože se dostalo i na netechnická témata. V 37Signals nedávájí zaměstnancům podíly, protože nehodlají nikdy fimu prodat. Vůbec se mu nelíbí ta atmosféra, kdy všichni "vyhrávají" jenom v případě, kdy se firma prodá (to mi něco připomíná). Oni si chtějí užívat každý den a z práce se radovat průběžně. Jestli budou někdy Railsy mainstream? Leda že by se mainstream ohnul k Railsům, naopak to nebude.

Někdo se zeptal, jaký vidí rozdíl mezi životem v Dánsku a USA. Prý ho překvapuje, jak málo jsou Evropani ochotní oproti Američanům riskovat. Přitom všude v Evropě je přebujelý sociální stát a riziko, že budete živořit na ulici bez kůrky chleba, je minimální. Proč je tedy Evropa tak konzervativní? Také by mě zajímalo. DHH vyzval k neutíkání z Evropy a k riskování tam, i když sám není dobrým příkladem. Na podzim se ale prý minimálně na pár měsíců chystá do Švédska.

Jinak doporučuje Macbook Air oproti Pro a do důchodu se nechystá, Obie Fernandez má smůlu.

Asi se mnou budou mnozí souhlasit, že Euruko 2008 nasadilo příštím ročníkům laťku hodně vysoko. Nic není perfektní, ale minulý víkend jsme se v Praze v mnoha ohledech dočkaly lépe zorganizované konference, než je samotná americký RubyConf. Díky patří především karmimu a Jirkovi Kubíčkovi, kteří vzali téměř všechnu práci sami na sebe.

Nebudu se rozepisovat, co se na konferenci dělo. Jednak to již mnozí učinili, také budou k dispozici videa. A nakonec jsme se tam všichni sešli ne?

Jen malou poznámku, která je relevantní k tématu tohoto blogu, totiž Ruby on Rails. Z Matzových úst jsme se doslechli, že zatímco Ruby tu pravděpodobně bude ještě dlouho, Railsy nemusí. Vedle toho bylo možné slyšet mnoho lidí zmiňovat jiné v Ruby napsané webové frameworky, především Merb.

Znamená to, že Railsy se v komunitě Ruby hackerů ze stavu horké novinky dostaly do pozice "dinosaura". Především proto, že je to podle nich již příliš nabobtnalý nástroj (viz heslo Merbu "All you need... none you don't"). Napadlo mě, že pro Ruby on Rails to znamená přesun do "enterprise" sféry. V okamžiku, kdy jsou prvotní uživatelé již znudění a přechazí na nějakou novinku, produkt začíná být použitelný a důvěryhodný i jako součást rozsáhlé infrastruktury, se spoustou pohyblivých částí a častějšími lidskými selháními.

P.S.: Moje tajné přání pro přístí Euruko: více obecnějších "netechnologických" přednášek.

Pokud chcete být u toho a potkat a poslechnout si (nejen) evropské příznivce jazyka Ruby, vězte, že dnes byla otevřena registrace na EURUKO 2008!

Konference se koná v Praze a za symbolických 20 euro získáte nejen možnost vyslechnout si všechny přednášky, ale též nějaké ty dárečky. Já jsem neváhal, už se moc těším.

Tento článek shrnuje Matzovu (tvůrce Ruby) keynote na RubyConf 2007. Dříve jsem psal o prvním a druhém dni.

Matz se na začátku rozpovídal na téma "Zaleží na použitém jazyce?" a začal s tím, že přeci ne. Že všechny (běžné) jazyky jsou Turing-kompletní a tudíž mají stejnou sílu. A že Twitter zvýšil výkonnost desetinásobně bez změny platformy, tudíž na jazyce nezáleží. Nebo ano? Ale jistě, důležitý je podle něj přístup. Ruby má příjemnou syntaxi a je kolem něj velmi entuziastická komunita a to znamená mnoho. Zde byla vhodná chvíle na úklon a poděkovaní všem v sále za jejich nadšení. Související poznámkou bylo, že 42% výdělku ThoughtWorks v USA pochází z Ruby projektů (o tom jsme se zde již zmiňovali) a že to prý jejich šéfovi pěkně zavařil, protože málokdo z jeho firmy chce dělat cokoliv jiného než Ruby. Jak říká Martin Fowler "There is business value in fun". Na konec první části přednášky Matz úkazal jakousi vtipnou tabulku vyjadřující poměr láska/nenávist pro různé jazyky vycházející z prý reálné ankety, ve které byli programátoři dotázáni, jestli daný programovací jazyk milují nebo nenávidí. Ruby vyšlo jako spolehlivý vítěz s poměrem 7,18, následoval Perl s 4,53 a Python s 4,35. Bral jsem to spíš jako žert, Ruby se pořádně rozšiřuje teprve v poslední době, a tak většina jeho programátorů si ho spíše sama vybrala, než že by jim byl "přidělen" zaměstnavatelem. Plus další důvody. A to byl konec sektářského úvodu.

Druhá část se věnovala nové verze Ruby - 1.9. Ta prý vyjde o letošních Vánocích, i když nebude tak stabilní, jak si autoři původně představovali. Bude obsahovat vlastnosti nekompatibilní s verzemi 1.8.x, tři z nich jsou podle Matze zásadní:

1. Odlišná práce s argumenty bloku. Argument bloku již nemůže být globální proměnná ani členská proměnná objektu. Tedy žádné |$global| nebo |object.member|. Proměnné bloku také budou zastiňovat lokalní proměnné vně bloku, tj. x uvnitř bloku je jiné, než x vně:

   irb(main):022:0> x = 10
   => 10
   irb(main):023:0> [1,2,3].each {|i| x = i} 
   => [1, 2, 3]
   irb(main):024:0> x
   => 3
   

   Takhle to fuguje nyní, v 1.9 už x zůstane 10. Tohle mi přijde jako dost marginální změna, protože v podstatě byly odstraněny možnosti, které žádný rozumný programátor nepoužije..
2. Řetězce již neobsahují Enumerable. Řetězce tedy již nepůjde iterovat metodou each. Ta ve stávající verzi iteruje přes jeho řádky, což evidentně nejen mně přišlo trochu neintuitivní. Matz podotkl, že vlastně není jasné, přes co by měla tato metoda iterovat, a proto místo ní přibydou metody lines, chars, bytes, které budou vracet příslušná pole (které se dají bez problému iterovat přes each, tj. "česky".chars.each pojede po jednotlivých znacích).
3. Řetězce vědí o svém kódování a prvky řetězce vrací znaky. Řetězce už znají kódování, defaultně tuším UTF-8, ale při různých operacích to půjde předefinovat. Napříkad při otevírání souboru půjde určit, v jakém kódování očekáváme obsah. Související změnou je, že přístup na jednotlivé znaky řetězce bude vracet daný znak (řetězec o délce jedna) a ne jeho ASCII kód, jak je tomu nyní ("ahoj"[1] nevrátí 104, ale "h").

Další nekompatibility jsou prý již nezásadní, Matz rychle ukázal slajd se spoustou změněných metod. Vypíchnuta byla jen neexistence File.exists? ve prospěch File.exist?, protože den předtím si na to někdo stězoval..

Kromě zpětně nekompatibilních změn přibyde i nová funkcionalita. Anonymní (lambda) funkce lze vytvořit novou syntaxí za pomocí "->". Vtipálek Matz ukázal sérii obrázku, ve které se znak lambdy nakláněl a postupně měnil v tuto dvojici znaků, jakože to je podobné.. Nový zápis dělá "->(a, b) {puts a+b}" ekvivalentní s "lambda {|a,b| puts a+b}". Parametry navíc můžou mít výchozí hodnoty. Lambdy půjdou zavolat i s vynecháním jména metody call: lambda.(1,2) bude stejné jako lambda.call(1, 2).

Přibyly iterátory či enumerátory. Tj. lze si z iterovatelného objektu "vytáhnout" pomocný objekt a iterovat pak přes něj. e = [1, 2, 3].each. Opakovaným voláním e.next pak dostaneme jednotlivé prvky pole. Javisté budou znát. Může se asi někdy hodit. Matz ukázal následujicí kousek kódu: 

e1 = [1, 2, 3].each
e2 = [3, 4, 5, 6].each

loop {
  p e1.next + e2.next
}

Toto není nekonečná smyčka, normálně to vytiskne postupně 4, 6 a 8. Metoda next totiž vyhodí nějakou výjimku (EndOfLoopException či co), která způsobí vyskočení z cyklu. Nějak se mi to moc nelibí, chování není jasné na první pohled. Taky jsem si myslel, že výjimky se použivají na výjimečné stavy, ne na vyskočení z cyklu. Anyway.

Další podivností je možnost mít povinné argumenty za nepovinnými. Doteď pokud nějaké argumenty byly nepovinné (tj. měly výchozí hodnotu), nešlo za ně přidat žádné povinné. Tj. def method(a, b=1, c=2, d) nebylo povoleno. V Ruby 1.9 je. Jestli se ptáte, jak tedy vlastně budou hodnoty ve volání metody do proměnných přiřazovány, nejste samy. Byl kolem toho v sále docela rozruch. Matz uvedl pár příkladů:

def m(a, b=24, c)
m(1,2)
a -> 1
b -> 24
c -> 2

def m(1, b=1, c=2, d)
m(1, 2, 3)
a -> 1
b -> 2
c -> 2
d -> 3

Celkem jsem pochopil, jak si rychle uvědomit, co přijde kam: Nejdřív se přiřadí všechny povinné na začátku, poté všechny povinné na konci a pak se berou zbylé mezi tím a přiřazují se odleva, jak tomu bylo doteď (na které se nedostane, dostanou výchozí hodnotu). Problém je, že i Matzovi kolikrát vteřinu trvalo, než to vymyslel. A to on ten jazyk navrhuje.. Doufám, že nic takového se neobjeví v žádném programu, se kterým přijdu do styku; já sám to nepoužiju určitě. Matz vysvětloval, že je to nutný mezikrok pro pojmenované argumenty (které budou v Ruby 2), což se mi moc nezdá. Že by nešlo tohle zakázat a stejně pojmenované parametry umožnit?

Dalšími změnou je používání nativních vláken (co to znamená poznamenává David Majda v komentáři k minulému článku), odlišné bude také nakládání s členskými proměnnými třídy. Jak odlišné jsme se nedozvěděli, ale našel jsem článek, který mluví nejen o tom, ale zmiňuje a vysvětluje i další připravované změny.

Implementace jazyka se bude jmenovat YARV a nedělal ji Matz (někteří jásají), měla by být znatelně rychlejší a konzumovat o něco méně paměti. Matz vtipkoval, že Rubinius je rychlejší než MRI, JRuby je rychlejší než MRI, IronRuby je rychlejší než MRI a že tedy už byl čas předat implementaci někomu jinému. Někdo se zeptal, jestli množství implementací nemůže Ruby uškodit. Matz říkal, že mnoho jich nebude, protože Ruby je naštěstí těžké naimplementovat. On že to zkusil jednou a již nikdy více.

Závěr patřil filozofování na téma současnost a budoucnost jazyka. V klasickém schématu tragédie - nesmělý začátek -> úspěch -> pýcha -> konflikt/válka -> úpadek - se nacházíme v stadiu úspěch a snad to tak prý nějaký čas zůstane. Prý ať chceme nebo ne (Matz že on ne, ale nedá se nic dělat), Ruby si najde cestu do velkých firem (usuzuje podle "the suits people that are surrounding us"). Na podobné téma jsem shlédnul velmi zajímavou prezentaci Kena Auera z Ruby Hoedown 2007, která srovnává historii Smalltalku s Ruby a vůbec obecně mluví o tom, za jakých podmínek se technologie rozšiřují z pár nadšenců mezi masy. Zajímavé, doporučuji.

Tento článek shrnuje druhý den RubyConf 2007. Dojmy z prvního dne lze nalézt zde.

Den zahájila přednáška o IronRuby, což je implementace Ruby pro .Net. Nejzajímavější na ní pro mě bylo, že na IronRuby pracuje můj kolega z MFF UK Tomáš Matoušek. Jelikož byl i osobně přítomen, tahal jsem z něj později odpoledne různé zajímavosti. Například jak moc v Redmondu prší (v létě prý naštěstí málo) a jak se mu tam líbí. Nejvíc mě ale zajímalo, co je pravdy na tom, že se zaměstnanci Microsoftu nesmějí podívat na open source kód, tedy ani vývojáři IronRuby nemají možnost spatřit zdrojové kódy jazyka, jehož implementaci vytváří. Prý je to pravda a důvodem je obava právníků Microsoftu, že by jejich nahlížením na cizí kód ovlivněná implementace byla důvodem žaloby. A že se to prý děje často (že je Microsoft žalován za podobné věci). Eh?

Druhá přednáška byla o JRuby. Pozor jsem dával asi jako při té první, zajímavé ale bylo, že parser Ruby pro JRuby napsaný umožňuje novým Netbeansům (a potenciálně dalším v Javě napsaným IDE nástrojům) implementovat různé vychytávky (byla předvedeno zvýrazňování lokální proměnné v metodě spolu s případným upozorěním, že není použitá). Nové Netbeans chci určite vyzkoušet (už jsem to tedy zkoušel instalovat, ale nezabralo mi to pět minut, tak jsem to odložil). JRuby má problém s implementací Object space (možností Ruby přistoupit na libovolný objekt v systému) související s garbage collectingem Javy. Umožnit Object space JRuby neúměrně zpomaluje, a tak je to ve výchozím režimu vypnuto. Interpret se musí spustit se speciálním flagem, aby byl umožněn. Byla kolem toho vášnivá debata, že by to mělo být defaultně zapnuto (protože jinak to není kompatibilní s původní implementací) and all that, kterou jsem nepochopil. Pokud někdo tuhle věc používá, bude dostatečně informovaný, že si to musí zapnout. JRuby využívá stejná vlákna jako Java (tj. převážně nativní či co, moc se v tom moc nevyznám). Na JRuby spustíte Rails (kdybyste to chtěli udělat..)

Třetí dopolední přednáška byla o další alternativní implementaci jazyka - Rubinius. To už byla jiná káva, dočkali jsme se skutečně zajímavé prezentace. Evan Phoenix působil zdravě sebevedomě a měl k tomu důvod, Rubinius je opravdu zajímavý projekt. Jeho přednáška začala skromným prohlášením, že důvodem, proč práci na alternativní implementaci začal, je, že chce aby Ruby dosáhlo světové dominance. Milé.. Poté postupně procházel jednotlivé stávající implementace a ukazoval, kolik v nich je řádku Ruby: MRI: 0, JRuby: 0, IronRuby: 0. Autoři JRuby se z davu ozvali, a tak jim poté velkoryse přiznal nějakých tisíc řádků. Nicméně MRI nazval Ruby pro C prográmátory, JRuby Ruby pro Java programátory a - modří už vědí - IronRuby Ruby pro C# programátory. Rubinius pak vykazoval poměr 1:2 mezi Ruby a céčkem a byl proto označen za Ruby pro Ruby programátora. Proč je to důležité? Pokud chce někdo přispět k lepší implementaci jeho oblíbeného jazyka, nejen musel do uvedení Rubinia umět některý z těch ostatních jazyků, ale musel být ochoten v něm i hodně pracovat. Rubinius umožňuje Ruby nadšencům zůstat u Ruby (plán týmu Rubinia je zvyšovat poměr Ruby v projektu). Rubinius je navíc více než otevřený přispěvatelům: komukoliv, jehož patch bude zařazen do projektu, bude úložiště kódu zpřístupněno k zápisu (commit right). V tuto chvíli do projektu přispělo 57 programátorů a podle Evana jsou všichni považováni za rovnocenní, tj. ne žádní "rovnější" (narážka na Rails core tým).

Co se týče stavu projektu, tak prý stále selhává v 500 testech specifikace, ale ještě před pěti týdny to bylo 1100, takže se postupuje rychle. Rychlejší než MRI je v 24 testech z 31. Někdo se Evana zeptal, na co jsem myslel už den předtím - jestli si myslí, že Rubinius jednou nahradí stávající implementaci - on poměrně diplomaticky řekl, že místo na slunci mají oba projekty. A že důležitá je přece hlavně ta světová dominance (doprovázeno upravenými plakáty sovětské propagandy, ehm).

V průběhu přednášky došlo na zajímavou anketu, ze které vzešlo, že skoro všichni v sále (asi 500 posluchačů) jsou placeni za každodenní práci s Ruby. Doplňující otázka upřesnila, že zhruba 80% z nich pracují s Ruby on Rails.

Odpoledne jsem zašel na Phila Hagelberga a jeho "Tightening the Feedback Loop", ve které připomněl, jak je důležité mít při práci rychlý feedback. Nejprve jsme testovali ručně (pomalé, nespolehlivé), pak automaticky a spouštěli jsme testy jednou za čas; poté začali používat autotest, který spustí okamžitě přesně ty testy, které jsou potřeba. Phil tuto myšlenku zobecnil a představil následující postup: 1. Identifikujete metriku, která je pro vás důležitá (přesnost testů, komplexita kódu, výkon programu). 2. Najdete nebo vytvoříte nástroj, který metriku bude měřit. 3. Zařídíte, abyste byli informováni, změní-li se měřená hodnota. Například sledujete každý den o půlnoci pokrytí kódu testy a pokud hodnota klesne pod 100%, budete informování e-mailem. Stejně jako Ryan o den dříve připomněl, že přílišná komplexita kódu je škodlivá (a že je snadné produkovat kód, kterému rozumí stroj, ale obtížné programovat tak, aby tomu snadno rozuměli lidé) a opět doporučil flog na její měření. Absolutní čísla z flogu vystupující je pak třeba porovnávat s výsledky jeho běhu nad částmi programu přínášející zhruba stejnou hodnotu, samotné moc informativní nejsou.

Phil navíc rád vizualizuje feedback autotestu, hecklu, flogu atp. přímo v editoru a jeho projekt augment tomu napomáhá.

Eric Hodel (autor autotestu) hned poté přednášel na obdobné téma: "Maximizing Productivity". V podstatě se to točilo kolem stejných věcí - automatizace, automatizace, automatizace. Zajímavější byl dlouhý seznam open source projektů, na kterých se Eric podílel. Prohlásil, že není žádná programátorská hvězda a že nakonec všechny projekty napsal primárně pro sebe. Eric působil jako člověk, do kterého se můžete bez problému vžít. Pro mě byl vývoj open source vždy něco, co je spíš pro nerdy věčně sedící u počítače nemající nic lepšího na práci (asi neprávem, ale takhle to bylo). Eric ale řekl, že open source projektům věnuje maximálně deset hodin týdně a to jenom, pokud má zrovna něco velmi zajímavého na práci. Jinak to jsou třeba jen tři čtyři týdně. To opravdu není mnoho. Navíc člověk nemusí hned začít vlastní projekty, stačí pomoci s těmi stávajícími, které používá. Inspirativní.

Zajímavé také bylo Ericovo rozložení oken při práci. Ta jsou čtyři: vlevo nahoře editor s metodou, pod ním editor s testem, vlevo nahoře (aby šel prodloužit) pak termínál s autotestem, dole pak volný terminál. Už Ryan den předtím oceňoval "pair programming" (programování ve dvojicích), Eric přidal tzv. ping-pong: první z dvojice napíše test, ke kterému musí ten druhý vytvořit implementaci (nejjednodušší, jaká je možná) takovou, aby test uspěl. Poté napíše další test a přehodí míček zpátky prvnímu.

Francis Hwang se pak snažil ukázat, jak nepřesné definice mnoha věcí v Ruby (duck typing, neexistence specifikace) odpovídají našemu světu, protože mnoho jeho vlastností je na tom podobně: druh, rasa, pravda/lež, atd. Hmmm. Poměrně zajímavá ale byla úvaha, že jazyky, které vám davají méně volnosti (jeho příkladem byla překvapivě Java), jsou perfektní volbou pro firmy, které rády zůstávají v bezpečných vodách (nemají ambice být výjimečné, jen chtějí mít pár spokojených zákazníků). Už i u nás bylo totiž diskutováno, že Ruby je silný nástroj, který vám umožní nejen udělat mnoho výjimečného, ale také hodně věcí pořádně zkazit.

Večer pak byla velmi zajímavá Matzova keynote, o té v příštím článku. Ale co nevidět mizím do hor hledat místního yetiho, takže asi ne úplně brzy.