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.