Czechs And Slovaks On Rails

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.