Czechs And Slovaks On Rails

Rozhodl jsem se rozšířit si obzory návštěvou další konference. Tentokrát nebyla o Railsech, ale šla přímo ke zdroji - Ruby. Na RailsConf (ať už americkou nebo evropskou verzi) jsem nejel především kvůli její ceně a masovosti.

Ruby on Rails začínají být notoricky známá a hojně používaná věc (minimálně zde ve Státech), což je samozřejmě dobře, zároveň to ale dělá konference o tomto frameworku trochu přelidněné a působící tak trochu "enterprise" (= nudně).

Ne že bych na RailsConf někdy byl (někdo z čtenářů ano? - rád bych se dozvěděl váš názor), ale takový byl můj pocit a potvrdil mi ho Nathaniel Talbott ve své přednášce "Why Camping Matters". Camping je webový mikroframework, napsaný Why the Lucky Stiffem, pomocí něhož můžete vytvořit webovou aplikaci jedním souborems pár řádky. Ješte jsem nepříšel na to, na co by to bylo dobré.. Ale vzhledem k tomu, že Camping aplikace umí využívat ActiveRecord, mohly by se hodit na superrychlé pre-Rails prototypy. Důležité v Talbottově přednášce ale bylo, že Camping nám připomíná, že zde nejsou a nebudou jen Ruby on Rails a že to nejenom není jediný webový framework, ale že to není ani jediný webový framework napsaný v Ruby. Aneb snažil se sdělit, abychom nepřestávali zkoušet nové věci a inovovat a že diverzita nám jedině pomůže. Je důležité mít Vlad deployer vedle Capistrana, je důležité mít Camping vedle Ruby on Rails.

Ale vraťme se na začátek. Letošní RubyConf odehrávájící se v Charlotte v Severní Karolíně byla zahájena Marcelem Molinou a jeho prezentací nazvanou "What makes code beautiful". Musím se přiznat, že po celém jednom dnu bez internetu jsem musel vyřídit pár věci a moc jsem tedy Marcelův výlet do historie nesledoval; shrnout ji ale snad zvládnu. Jeho oblíbená definice krásy byla, že všechny aspekty něčeho krásného jsou vyvážené, nic nijak nevhodně nevyrůstá nebo nepřečnívá. Totéž aplikoval na kód programu (a na konkrétním příkladě i ukázal) - krásný je, pokud jsou všechny jeho důležité vlastnosti vybalancované - délka, čitelnost, rychlost atp. Zkrátka středně zajímavě podaná jednoduchá myšlenka.

Následovala přednáška Jima Weiricha, mimo jiné tvůrce nástrojů rake a XML Builder nazvaná "Advanced Ruby Class Design". Jim ukázal zajimavé příklady návrhů specifické pro Ruby.

Prvním byla ukázka, jak chceme-li vytvořit rozšíření nějaké standardní třídy (např. pole) se spíše vyplatí dodefinovat metodu to_* (např. to_ary pro pole) a příslušné operace na dané třídě (+, -, *, ..), než využít dědičnosti. Důvod pro to byl myslím podobný problém, o kterém jsem psal minule - (ne)komutativita operací. Další technikou bylo předefinování - nebo lépe schování - (téměř) všech metod nějaké třídy. To používá právě XML Builder, kde volání xml.cokoliv vytvoří XML element . Jim ukázal, jak vyřešit krajní případy související s flexibilitou Ruby. Dále se pokusil nahradit SQL fragmenty vstupující do ActiveRecord objektů čistým Ruby, tj. místo Person.find(:all, :conditions => ["name = ?", name]) psát Person.select {|p| p.name == name} se zachováním efektivity SQL - tedy ještě rozšířenějším překladem Ruby do SQL. Docela mu to šlo, ale narazilo to na nemožnost předefinování operátorů &&, || a !. Celá přednáška včera dávala dobrý smysl, ale určitě si slajdy projdu znovu (až budou k dispozici) a do jednotlivých triků se zahloubám více.

Odpoledne jsem slyšel kromě již zmíněného Nathaniel Talbotta dvojici Japonců povídat o AP4R - messaging middlewaru. Zajímavé jen středně. Eric Ivancich pak představil svoji implementaci Ropes - reprezentaci řetězců binárními stromy. Povídání o datových strukturách nepříliš objevné, v určitých aplikacích to ale může věci velmi urychlit. Zajímavější byla jeho poznámka o tom, co ho k napsání této knihovny vedlo. Na jakési mezinárodní soutěži v programování mnoho příznivců dynamických jazyků v průběhu hledání rešení "uteklo" k Ć++, protože problém vyžadoval mnoho operací nad řetězci a to bylo s použitím tradičních reprezentací velmi pomalé. Což Eric komentoval jako nedostatek důvěry v tyto jazyky. Problém ale nebyl v jazyce, nýbrž ve vybraných datových strukturách; použití něčeho jako Ropes a Ruby by bylo rychlé dostatečně (rychlější než něco středně hloupého v C).

Zlatým hřebem dne pro mě každopádně byl Ryan Davis a jeho přednáška "Hurting Code for Fun and Profit". Ryan stojí za mnou velmi oblíbenými nástroji zentest, heckle a flog (mimo jiných). Ryan skvěle ukázal, že nejhorší věc, která může programátora potkat je apatie. "Svůj kód buď milujete, nebo nenávidíte". Pokud ho nenávidíte, pracujete na jeho zlepšení, zlepšujete testy (jako já připomněl, že stoprocentní pokrytí testy nic neříká o jejich kvalitě), snižujete jeho komplexitu a děláte ho čitelnějším. K tomu patří i nedělání věcí zbytečně, programujete naprosté minimum potřebné k tomu, aby vaše testy uspěly. Zmínil i mou oblíbenou knihu 7 Habits of Highly Effective People a jak změnila jeho přístup k práci. Vysvětlení by bylo na další článek, ale v zásadě to podporuje testování, častou refaktorizaci a automatizaci opakujících se úkolů, aby se člověk mohl soustředit na důležité, ale neurgentní úkoly. Další zajimavostí byla definace "technického dluhu": zvyšováním komplexity kódu si jakoby půjčujete čas - uděláte něco rychleji, ale nakonec to stejně budete muset předělat a ten čas "vrátit". Navíc pokaždé, kdy s takovým kódem pracujete, platíte "úroky" tím, že vám úkony trvají déle, než by trvaly, kdyby byla daná část naimplementována čistě. Doporučoval, abychom hodně programovali, protože pouze praxí dosáhneme mistrovství (věc zde často opakovaná). A na závěr: čtete-li jednu knihu měsíčně, jste na dvanáctinásobku průměru v našem odvětví. Ryan byl velmi inspirující a všechny nadchnul k lepší a svědomitější práci.

Den zakončily "Otázky a odpovědi" s Matzem Matsumoto, tvůrcem Ruby. Z těch zajímavějších odpovědí bych zmínil informaci, že verze 1.9 by měla vyjít o těhle Vánocích. Zajímavé také bylo, že Ruby komunita v Japonsku prý závratně velká není a poměr lidí, kteří se Ruby živí, je menší než v USA. Někdo se Matze zeptal, jestli přijede na evropskou Ruby konferenci a on se tvářil, že toho má strašně moc a že se někdy v budoucnu pokusí. Koho zajímá, jaký Matz používá editor, tak je to .. Emacs. Old-schooler..

Příště další dny.

Vlado se s námi podělil o několik fotek z Ostravy on Rails, organizátor Robert Cigán pak s první várkou videí! Rozhodně doporučuju všem, co neměli tu možnost být tam osobně.

Přednáška Tobi Lütkeho byla pro mnohé tou nejzajímavější na ostravské konferenci. Hlavní důvod byl pravděpodobně ten, že byla nejméně technická a hodně "ze života". Určitě se k ní vrátím na svém blogu (stejně jako to udělali ostatní), zde bych chtěl ale přece jen poukázat na ty techničtější body.

Shopify je podle jeho slov velmi dobře pokryto testy, používají je jako své (levné) oddělení kontroly jakosti. Zdůrazňoval především důležitost unit testů, ostatní prý mají také, ale nějak je příliš nezmiňoval. Tím vlastně prozradil, že jejich aplikace má (tak jak to má být) většinu logiky v modelech a metody v controllerech mají jen pár řádek.

Uplatňují test-first přístup, tedy nejdřív napíší test a až pak samotný výkonný kód (zatím ale nešly tak daleko, aby používaly RSpec). Před opravením chyby vždy nejprve vytvoří selhávající test ověřující daný nedostatek a až pak chybu opraví.

Pro ujištění, že všechen kód je řádně pokryt testy, používají Heckle . Tato utilitka modifikuje váš kód, spustí na něj testy a ujistí se, že selžou. Protože pokud se tak nestane, kód je buď neotestovaný nebo mrtvý. Tedy je to špatně nebo špatně. Za domácí úkol si dávám zjistit, jak se Heckle liší od rcovu, který používým nyní. Někde jsem vygooglil, že je dobré používat oboje. Jeden z rozdílu je, že Heckle dokáže ukázat, jak byl kód modifikován.

Tobiasovo ano na otázku "Does it scale?" (Shopify má kolem 1000 aktivních obchodů, celkem až 25000) bylo především o zmínce o memcached. Memcached je distribuovaná hash tabulka sídlící v paměti vašich serverů, které se můžete zeptat na data, která jste do ní uložili. Já znal jen použití pro data session uživatele (místo souborů na disku nebo ukládání do databáze), Shopify to ale evidentně používá i pro nacachované (fragmenty) stránek. Zmíněna byla i technika s jejich verzováním.

Nebudu předstírat, že to ještě úplně detailně chápu, a tak mě uklidnila zmínka, že ani nemusím začínat, dokud velikost databáze nepřekročí velikost operační paměti.

Dále již jen stručně: na deployment a údržbu samořejmě používají Capistrano, PostgresSQL má evidentně oproti MySQL nějaké problémy s replikacemi a důrazné doporučení nemít jeden bod selhání.

A to byla jen tatechničtější část (tj. cca polovina přednášky). Velmi inspirativní. Btw "If Rails doesn't fit a task then fix Rails. It's easy."

David Majda nám šetří brouzdání a nejen přináší souhrn odkazů na články s dojmy z v sobotu skončené konference Ostrava on Rails, ale také připojuje poznámky své.

Už po úvodním dni první české Rails konference je jasné, že toto setkání bude velmi přínosné. Dopoledne jsme měli jsme možnost slyšet přednášku Jamise Bucka ze 37signals o administračním nástroji Capistrano (zmínky o jeho méně často používaných a pokročilejších schopnostech i novinkách verze 2) a tu Saimona Moora o Globalize, nástroji pro lokalizaci Rails aplikací. Odpoledne jsme se od organizátorů konference dozvěděli, že chtějí vytvořit "Síť Ruby on Rails", aneb organizovat spolupracující komunitu lidí o Railsy se zajímajících. Odpoledne Tobi Lütke z Shopify v pro mě nejlepší přednášce dne prezentoval své "lessons learned" při provozování tohoto populárního e-commerce systému. Navázal Luke Francl povídáním o Railsech použitých při interakci s mobilními telefony a den zakončil Tim Lossen prezentací na téma budování vysoce dostupné soustavy serverů pro Ruby on Rails aplikace.

Každou přednášku následovala nekrátká diskuse přednášejícího s účastníky, kdy se nám dostalo velmi zajimavých doplňujících informací. Samozřejmě nechyběly ani rozhovory v kuloárech, velký to důvod, proč vůbec na takovéhle akce jezdit.

Postupně vydáme krátký výtah všech prezentací včetně fotek. Vzhledem k přítomnosti kamery v sále ale věřím, že všichni, kteří neměli možnost dnes být v Ostravě osobně, budou mít možnost vše vidět alespoň ze záznamu.

Účast na druhém dni mi překazila nutnost návratu do města kanálů, ale věřím, že se tu něco o zítřejším dění také objeví. Také jsem přesvědčen, že tato konference velmi pomůže růstu Ruby on Rails komunity v Česku. Jen tak dál.