Dnes mě ale Google Reader překvapil českými reakcemi na Ruby 1.9. Článek na Rootu považuje release za ukvapený. Tak aspoň zní honosný titulek, nikde ale není vysvětleno co je na development relase ukvapeného. Článek dále cituje tento výlev Davida Majdy, který je opět protkán nepochopením.

Nechci zde nikoho odsuzovat ani obhajovat, protože je nutno přiznat, že obě strany mají tak trochu pravdu. Čeští kritikové to nicméně vzali za špatný konec. Z mého pohledu udělal největší chybu Matz, a to tu, že nikde (nebo aspoň nikde viditelně) není oznámeno, že 1.9.0 není nástupce 1.8.x, ale předchůdce na cestě k 2.0. Co to znamená?

Normálně by člověk předpokládal, že když se sníží minor verze produktu (to druhé číslo) tak je zachována zpětná kompatibilita. Tady to z již zmíněných důvodů neplatí.

Matz udělal chybu, protože na letmý pohled vypadá 1.9.0 jako nástupce 1.8.6, ale označení development release by mělo odratit ty co hledají spolehlivý a stabilní produkt.

Krikitové udělali na druhé straně chybu tu, že místo toho aby Ruby povzbudili na cestě k verzi 2.0 děsí se nad nekompatibilitou a chybami ve vývojářské verzi.

Osobně bych rozšiřování syntaxe spíše zavrhoval a soutředil se na zvyšování rychlosti a nativní podporu Unicode. Nakonec je ale tento release dobrá věc, spoustu lidí co ho nepochopí znechutí a otevře místo pro zkoušení alternativních implementací.

CZ podcast #15 je tedy slavnostně venku. Jeho natáčení bylo velice zajímavé a hlavně zábavné. Bylo to poprvé a stálo to zato. Tímto bych chtěl Roumenovi, Dagimu a Filemonovi za pozvání poděkovat. Byl to skvěle strávený večer, snad se i vám bude líbit.

Vám, co RailsEnvy neznáte, přidávám odkazy ještě na poněkud postarší, ale stále skvělé reklamy na Ruby on Rails: první, druhá, třetí, čtvrtá.

O agilní metodiky se zajímám už nějakou tu dobu, ale tato přednáška mě hodně nadchla i pro opomíjené praktiky jako pair-programming a test first, code after. Celkové statistické zhodnocení vlivu Ruby a Agile na průběh projektu sice nelze brát na 100% (je to pořád jenom statistika), ale závěr je nevyvratitelný. Agilní metodiky v kombinaci s dynamickými jazyky jsou dobré nejenom pro vývojáře (práce je zábavnější), ale i pro manažery a byznys jako takový (projekty jsou úspěšnější a výdělečnější).

První jsem si řekl: “Co to sakra znamená? Co si ten člověk sakra myslí?”. Doporučuju přečíst si diskusi, trošku mě uklidnila. Pořád tu jsou ale otevřené problémy. Logo bylo zaplaceno komunitou. Je v pořádku, že jeden člověk na ním má plnou kontrolu? To mi přijde kapku šílené. Nechápu to. A co vy?

Nějak mám pořád problém udělat si na věc jasný názor. Mělo by logo spravovat komunita? Jeden zajímavý nápad: Co takhle, kdyby každé komerční použití loga muselo být komunitě finančně kompenzováno? Rails komunita by získla kousek z toho byznysu, který Rails okolo sebe generují.

(Anglická verze )

Jedno staré anglické rčení říká “The good things in life come for free” a myslím, že to je přesně to co je hlavní osou Richardovi řeči. V průběhu svého projevu vyslovil (jak už je zvykem) nespočet zajímavých myšlenek, faktů a příkladů (nejhorší teroristická organizace je vláda Spojených Států a pod.). Ale nejlepší část přichází na konci, kde popisuje svůj návrh řešení současných problémů s copyrightem. Když to tak člověk poslouchá a představuje si to chce se mu smát, já jsem se teda smál a se mnou spousta posluchačů na tom videu.

Velmi mi to připomělo okamžik, kdy jsem poprvé začal používat Rails. První zkušenost s tímto nádherným nástrojem, který je ještě k tomu zadarmo, byla extatická. A tady právě přichází “One dollar button idea”. Prostě musím souhlasit, že to takhle musí fungovat! Ačkoli nejsem bohatý (ale ani chudý) hrozně moc si užívám některé díla vědy, umění a jiných oborů a často, když mi například zahraje skvělá písnička na mobilu nebo Last.fm playeru, bych hrozně rád autorovi tohoto díla poděkoval a poslal mu něco malého. Můžete argumentovat, že implementovat takovýto univerzální Button je nemožné. Není! Teda dnes možná ano, ale za pár let? Představte si takové zařízení jako MDA (PDA s mobilem v jednom). Různé varianty těchto zařízení získávají na popularitě a doba globální konektivity není zas tak daleko. Pak pokaždé, když mi mé přenosné zařízení pustí pěknou muziku je velmi jednoduché provést mikrotransakci směrem na účet autora (nikoli Labelu, nedejte se zmást).

Nečekám, že Richardovy nápady ožijou v realitu teď hned, ale mediální průmysl pomalu přestává být schopen vydělávat peníze starýmy způsoby a nakonec zkrachuje úplně (doufejme). Pak přijde doba, kdy budou mít myšlenky Free Software Foundation příležitost k realizaci. Na tuto dobu svobodných médií se doopavdy těším a snažím se dělat vše proto, aby se tak stalo co nejdříve. Nekupujte DRM chráněná díla, dobré věci v životě, ty přicházejí zadarmo.

(Anglická verze zde )

Základní chybu v přístupu autora vidím v tom, že si vybral jeden rys jazyka Ruby a snaží se jím charakterizovat celý framework Rais. Tento přístup volí většina odpůrců Rails. Nakonec mě docela rozesmálo, že sám autor píše v PHP a přitom přiznává, že PHP nevěří, ale je to dobrý jazyk. Rozporuplné.

Jak už bylo zmíněno v diskusi na rubyonrails.cz, k problému dynamičnosti Ruby existují dva přístupy. Buď se na to díváte jako na slabinu jazyka nebo naopak jako na výhodu. Každý programátor to vidí jinak. Pokusím se nyní obhájit názor, že se jedná o výhodu.

Ruby má oproti statickým jazykům tu výhodu, že neexistuje rozdíl mezi „compile-time“ (přesněji spíše write-time, protože mluvíme o interpretovaném jazyku) a „run-time“. U statickýh jazyků jsme zvyklí na to, že jakmile je třída jednou nadefinovaná, již ji nejde „zvenku“ měnit. Toto v Ruby neplatí. Metody a třídy lze za běhu upravovat, měnit a přidávat. Dáte-li takovýto nástroj od ruky běžnému PHPkáři nebo jakémukoli programátorovi, který nevidí dva řádky kódu dopředu, stane se přesně ta katastrofa, kterou dxg popisuje. To je jako když dáte člověku pistoli, rozumný člověk ví, že když vystřelí do davu pravděpodobně někoho zabije nebo minimálně zraní, malé dítě neznalé širších souvislostí a následků použití střelné zbraně, to pravděpodobně bude chtít vyzkoušet a stane se něco špatného. Stejně je to i u programátorů. Důvod proč Ruby asi nikdy nepřeválcuje Javu, PHP a .NET je ten, že nutí programátora přemýšlet jinak, v širších souvislostech a to hlavně pokud se jedná o využívání dynamických aspektů jazyka. Tím ovšem nechci říct, že žádný Rails programátor nikdy nešlápne vedle, pokud se ale drží konvencí Rails a hlavně důkladně testuje, je na chybu upozorněn a může si ji uvědomit a hlavně opravit. Ještě se mi nestalo, aby si navzájem nějaké komponenty pod rukama měnili metody v základních třídách, Ruby programátoři holt musí vědět co dělají a jaké mají jejich akce následky. Pokud už něco zásadního změní je slušné to udělat bezkonfliktně a upozornit.

Na závěr bych se ještě pozastavil u kódu, který dxg používá jako příklad. Konkrétně u věty:

„i v PHP lze podobný přístup napodobit … Když si nadefinuji odpovídající třídy, mohu v PHP také psát: …“

Ano! Když si nadefinuješ odpovídající třídy. Ale to já nechci dělat. Já chci efektivně programovat aplikaci a ne definovat pomocné třídy abych mohl efektivně programovat.

Důvod proč mám framework Rails tak rád, je že dynamičnosti Ruby plně, ale přitom ohleduplně, využívá a přidává další koncepty jako je DRY, Convention over Configuration, integrovaná podpora pro TDD a Agilní přístupy všeobecně, REST a další. Samozřejmě, většiny techto rysů se dá dosáhnout v každém prostředí, na Rails mám rád to, že vše přichází “out-of-the-box”, pěkně otestované a zintegrované dohromady. Pokud si dxg myslí, že Rails představují pro progmátora vězení, dobře mu tak, pro mě jsou Rails luxusní hotel, kde se můžu soustředit na svoji práci (vývoj aplikace) a prostředí mi vychází maximálně vstříc.

(Poznámka: Ruby on Rails zbožňuju a psát v Rails je pro mě radost. Normálně pracuji v Javě a dá se to snést. Taky už jsem vyzkoušel pár jazyků, ale do Ruby jsem se skutečně zamiloval)