Posted by csonrails over 2 years ago
Při hledání memory leaku v mém programu jsem narazil na to, že leakuje dost pravděpodobně stadardní knihovna Ruby. Pro detekci objektů, které zůstavají v paměti, jsem použil memory leak detektor dike.
[Update: Leaky způsobovala chyba v diku! Více na mém blogu zde.]
require 'rubygems'
require 'dike'
Dike.logfactory './log/'
class Leak
def http_call
puts 'making http call'
url = URI.parse('http://www.google.com')
Net::HTTP.start(url.host) do |http|
puts http.get('/').code
end
''
end
end
5.times {
leak = Leak.new
leak.http_call
GC.start
Dike.finger
}
V tomto případě leakuje metoda get, zanechává Net::HTTPFound (HTTPResponse) objekty v paměti. Zaměnění get za request_get leak odstraní.
require 'rubygems'
require 'dike'
Dike.logfactory './log/'
class Leak
def http_call
url = URI.parse('http://www.google.com')
puts 'making the call'
Net::HTTP.start(url.host) {|http|
http.request_get('/') do |response|
response.read_body do |segment|
end
end
}
return ''
end
end
5.times {
leak = Leak.new
leak.http_call
GC.start
Dike.finger
}
V tomto příkladě metoda read_body zanechává v paměti ReadAdapter objekty a kvůli nim tam pak zůstanou i další. Tento problém nastává pouze v případě, že se metodě předá blok. Jinak se ReadAdapter objekt nevytváří a žádný memory leak nenastává.
Nevidím na první, druhý, ani třetí pohled v uvedených příkladech nic podezřelého. Ve zdrojácích knihovny mě také do očí nic nepraštilo. Nic zajímavého jsem ani nevygooglil. Někdo je schopen mi tuhle věc objasnit (co, Davide?:). Další zastávkou bude Ruby mailing list.
Btw,
ruby leak.rb && dike log
Posted by root.cz over 2 years ago
Webový framework Ruby on Rails již tu s námi je nějaký ten pátek. Za dobu své existence si získal velké množství příznivců jak z řad amatérských nadšenců, tak také z firemního prostředí. Nyní vyšla jeho dlouho očekávaná druhá major verze. Co přináší nového a co se změnilo? Jakým způsobem upgradovat?
Posted by csonrails over 2 years ago
Na stránkách Confreaks se již objevila videa z RubyConf 2007, alespoň tedy většina z nich. Doporučuji především přednášku Jima Weiricha o třech zajímavých Ruby-pokročilých technikách, prezentaci Rubinia Evana Phoenixe, povídání o efektivitě a síle správných nástrojů od Phil Hagelberga a Erica Hodela a v neposlední řadě keynote Matze Matsumota.
Pro mě osobně nejlepší přednáška konference - totiž ta od Ryana Davise - pořád ještě chybí, ale snad již brzy..
Posted by csonrails over 2 years ago
Měl jsem problém s tím, že "novější" Railsy interpretují tečku v URL jako oddělovač významné části URL a specifikátor požadovaného formátu odpovědi (tj. ".xml" na konci URL by bylo interpretováno jako požadavek na vrácení dat v XML formátu).
Pokud ale vaše URL obsahují tečky bez ohledu na formát, nebude vám mapování fungovat dobře. Tj. /attachment/:file nezachytí /attachment/file.txt. Řešení je ale snadné a to zeslabit omezeni na proměnnou file, aby akceptoval všechny znaky:
/attachment/:file/, :requirements => { :file => /.*/ }
Tohle jsou víc jak rok staré zprávy a řešení se dají poměrně slušně najít, ale třeba jsem vám právě ušetřil půlhodinku bádání ( se hodí lidem, kteří googlují v češtině).
Posted by root.cz over 2 years ago
Jste už unaveni XML na stojedna způsobů? Nudí vás jeho fádní syntaxe? Irituje vás jeho ukecanost? Omezují vás jeho možnosti? Štve vás neustálé eskapování entit? Nemají jej rádi vaši uživatelé? Co takhle seznámit se s Domain-Specific language?
Posted by csonrails over 2 years ago
Tímto zakončujeme sérii reportáží z letošní RubyConf konající se Charlotte v Severní Karolíně. Přecházejícím článkem byl report o Matzově keynote, v něm najdete i odkazy na předchozí příspěvky.
Zdá se, že videa z přednášek se objeví na příslušné stránce Confreaks, zatím tam je ale jenom Q&A session s Matzem na konci prvního dne. Buďme trpěliví. Co tam ale již je, jsou videa z letošní RejectConf, což jsou pidi-konference v rámci RubyConf nebo RailsConf, které - jak již název napovídá - dávají prostor všem, kteří to nedotáhli na hlavní pódium. Kdokoliv se může během pár hodin přihlásit o slovo a pokud přednáška nebude moc dlouhá, je téměř stoprocentní šance, že dostane prostor k prezentaci čehokoliv s Ruby souvisejícího.
Neviděl jsem úplně všechno, ale zaujal mě hlavně monitorovací nástroj skromně pojmenovaný God. Také MonkeyBars - knihovna umožňující vývoj GUI v Ruby pomocí Swingu - stojí za zmínku. Pak snad jen že PDF-Writer má zas někoho, kdo ho bude udržovat. Pro zasmání ale doporučuji zmínku o rozšíření IRB historie ("If you're like me - and I certainly am").
Teď v cuku letu posledním dnem. Dr. Nic Williams ukázal vtipnou variaci úvodní znělky seriálu A-team (v době psaní tohoto článku je YouTube nefunkční, kam ten svět směřuje??), kde zaměnil původní hrdiny známými příslušníky Ruby scény. Poté výpravěl o různých generátorech všeho a generátorech generátorů všeho. Pokud vás zajímá, zkuste Nicův screencast.
Dave Astels (který čerstvě doplnil řady inženýrů Googlu - evidentně tam také dělají Ruby) a David Chelimsky poté představili TDD, BDD a RSpec. TDD neboli Test Driven Development je podle Astelse zaměření na design (Test Driven Design), dokumentaci a chování, ne koncentrací na testy. Tj. nejde ani tak o to mít napsané testy, ale o fakt, že psaním testů dřív, než samotný výkonný kód, dosahujeme přehlednějšího a čistšího designu.
Také to znamená, že nepíšeme žádný kód zbytečně, ale pouze na základě selhávajícího testu (tj. nesplněného požadavku na chování). Odsud se dostáváme k BDD (Behavior Driven Development), tedy vývoji řízeném popisem chování. Při BDD nejprve napíšete specifikaci velmi malé části systému ve formě programu (testu) a pak dopíšete co nejmenší množství kódu tak, aby specifikaci splňoval (test uspěl). Pak pokračujete implementací dalšího požadavku na chování.
RSpec je implementace BDD a co přináší oproti obyčejnému test-first přístupu je především odlišný slovník. Porovnejte dva stejné "testy" a posuďte sami, který se víc hodí na to být napsaný dřív, než kód, který testuje (specifikuje).
describe "Controller" do
it "should have a session hash accessible" do
@controller.session.should.be.an.instance_of Hash
end
end
class Controller < Test::Unit::TestCase
def test_controller_should_have_a_session_hash_accessible
assert @controller.session.instance_of?(Hash)
end
end
Ke konci přednášky byly předneseny nové vlastnosti RSpec, nějaké user stories, které byly napsány jakoby přirozeným jazykem a nějak se překládaly do těch popisů
chování. Tam mi to přišlo hodně přehnané, zbytečně komplexní a přinášející duplicity. Vrcholem byla úvaha, že takové specifikace budou psát uživatelé (či jejich podpora). To mi přišlo jako naprostá hloupost. Teď když nad tím ale přemýšlím, možná by je mohl psát znalec dané domény (např. fyzik, chemik) pro programátory. Ještě to tedy neztracuji.
Další přednáška byla o Adhearsion, též známým jako "nové Rails", hehe. Adhearsion je v Ruby napsaný framework pro VoIP aplikace. Není to napsané od nuly, jedná se o vrstvu nad starší knihovnou Asterisk, ve které psát přímo nebude podle výjadření autora a předvedených ukázek žádný med. Pokud děláte cokoliv s telefony/telefonií, neváhajte Adhearsion alespoň prozkoumat (a dát nám vědět).
Pokud máte více aplikací vyžadující autentikaci, může se vám hodit představený RubyCAS server. Co je ale
mnohem podstatnější (že?) je informace, že toto dílko je napsáno ve frameworku Camping. A pak že je jen na hraní. Pokud zas potřebujete samostatný server na
full-text prohledávání vaší databáze s API, které umí vracet Ruby, třeba se vám bude hodit Solr.
Den a celou konferenci pro mě zakončila přednáška Bena Scofielda na téma DSL (doménově specifický jazyk). Jedním z jeho sdělení bylo, že v Ruby napsané DSL
vlastně žádné jazyky nejsou, jsou to pouze dialekty Ruby, neboť nemají odlišnou gramatiku, pouze jinou slovní zásobu. Navrhoval nazývat je tedy DSD (dialects).
To bylo poněkud nešťastné, neboť jak poznamenali diskutující, nemusíme být zas takoví puntičkáři; slovo "language" nemusí být chápáno jako tak striktně definující.
O tom se bohužel diskutovalo poměrně dlouho, a tak asi zapadla pro mě důležitější myšlenka prezentace. Totiž že slova, která používáme, ovlivňují, jak o věcech
přemýšlíme. Hodně záleží na tom, jaké si zvolíme jména proměnných, protože a, b, x nás myšlenkově drží v abstraktním programování, kdežto today_flights, return_fligths apod. nám umožňuje přemýšlet v doméně, pro kterou programujeme. A to je přesně to, čeho chceme dosáhnout, protože pak náš design dává daleko větší smysl. Zmíněno bylo
i to, že test máme ze školy zafixované jako něco, co přichází na konec (nejprve studujeme, pak se píše test a toť vše), kdežto specifikace je vždy na začátku. Podnětné. Než bude k dispozici video, můžete zkusit více pochytit ze slajdů.
A to je vše přátelé o RubyConf 2007. Setkání to bylo velmi inspirující. Příští ročník bych doporučil všem, kteří budou mít
možnost za moře vyrazit. Ostatní to budou mít (snad!) velmi blízko na RubyConf Europe 2008.
Posted by root.cz over 2 years ago
V posledním díle miniseriálku o unicode v Ruby vezmeme do rukou křišťálovou kouli a nahlédneme do budoucnosti jazyka - podíváme se na podporu unicode v chystaném Ruby 1.9 a pro zajímavost si také řekneme pár slov o podpoře unicode v alternativních implementacích Ruby.
Posted by Jiří KUBÍČEK over 2 years ago
Pátého pravidelného setkání uživatelů Ruby On Rails v Praze se zůčastnili i hlavní protagonisté konference Ostrava on Rails Jirka Kubica a Robert Cigán ze Skvělý.cz a Jirka Štursa z vědeckotechnologického parku Ostrava.
Kromě běžného veselého tlachání o Ruby on Rails jsme zabrousili i do otázky budování komunitní sítě, která by měla pomoci sdružovat lidi a firmy používající Ruby on Rails a pomáhat plnit jejich potřeby. Idea networkingu byla představena na ostravské konferenci. Výsledky ankety byly nedávno zveřejněny.
Na setkání jsme věc probírali více do hloubky a shodli jsme se, že programátoři – lidé, si na oficiality nepotrpí. Pro běžnou komunikaci stačí osobní regioální neformální setkání doplněná o webové fórum, irc kanál a blogy. Chybí ale podpora pro firmy. Síť by měla pomáhat při prosazování RoR do firem.
První nápady:
- Představení Ruby on Rails méně technickým pohledem
- Sada případových studií popisující reálné úspěšné nasazení RoR
- Seznam vývojářů / vývojářských firem, které je možné s projektem oslovit
- Seznam konzultantů, které je možné při řešení projektu využít
- Seznam hostingů, na kterých je možné projekt provozovat
- Pořádání prezentací, konferencí a workshopů
Pro usnadnění procesu vzniku sítě vybral Jiří Štursa metodiku úspěšně použitou v Lucembursku. Když bude dostatek zájemců, můžeme se sejít a ještě jednou probrat cíle a naše očekávání a zkusit probrat i jednotlivé dílčí části o něco detailněji. Bylo by dobré, kdybychom to stihli ještě do konce roku.
Pokud máte nějaké další nápady, můžete je psát do RoR fóra nebo na fórum konference.
Posted by csonrails over 2 years ago
Pokud to také chcete vědět a nechcete vše dolovat z různých blogů (nebo z poznámek ke commitům, hehe), možná jako já nepohrdnete mini-knihou o Rails 2, dostupnou přes Peepcode.
Posted by root.cz over 2 years ago
Již minule jsme si řekli, že problém s unicode není v Ruby nikterak neřešitelný. Z minula již umíme implementovat podporu unicode ve vlastní režii, dnes si ukážeme jak na to, abychom se pomyslnému objevování kola vyhnuli - povíme si o knihovnách, které tento problém řeší za nás.
Posted by csonrails over 2 years ago
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í:
- 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..
- Ř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).
- Ř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.
Posted by csonrails over 2 years ago
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.
Posted by csonrails over 2 years ago
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.
Posted by csonrails over 2 years ago
Jak pozorní budete, když v knížce o Ruby narazíte na příkaz case? Jestli jako já, tak moc ne. Rozhodnutí, jakou větví se provádění programu vydá se řídí operátorem ===, tak co je nutné vědět více, že?
Následující určitě někomu přijde jako stará známá věc, ale věřím, že ne všem. Až do nedávna jsem si myslel, že následující case:
case wifes
when 0
puts 'single'
when 1
puts 'married'
else
puts 'mormon'
end
se přeloží do následující operace:
if wifes === 0
puts 'single'
elsif wifes === 1
puts 'married'
else
puts 'mormon'
end
Chtěl jsem ale, aby můj test vlezl do všech těchto větví (to je takový dobrý testovací návyk;) a jal jsem se nahradit metodu === na objektu wifes něčím (mockem), co mi vrátí postupně všechny hodnoty. A ono to nefungovalo. Zkoumáním nalezené skutečnosti v irb jsem dospěl k různým zajimavostem, které jsem si předtím dostatečnš neuvědomil:
irb(main):001:0> String === ""
=> true
irb(main):002:0> "" === String
=> false
irb(main):003:0> /h/ === "hey"
=> true
irb(main):004:0> "hey" === /h/
=> false
Aneb potřeboval jsem si znova uvědomit, že === není žádný komutativní operátor, ale metoda a ta může (a je) v různých třídách implementována různě.
A jak to navazuje na case statement? No ten příkaz se ve skutečnosti vykoná takhle:
if 0 === wifes
puts 'single'
elsif 1 === wifes
puts 'married'
else
puts 'mormon'
end
Metoda === se tedy nevolá na objektu stojícím za klíčovým slovem case, ale na objektech za "whens" v jednotlivých větvích. Zajimavé to pak začíná být především v případech, kdy nejsou všechny objekty instance stejné třídy.
Doufám, že to dává smysl. Objasňuje to i tyhle hojně využívané casy:
case extension.downcase
when /jpg$/
puts "picture"
when /mp3$/
puts "song"
end
res = Net::HTTP.new(url.host, url.port).start {|http| http.request(req) }
case res
when Net::HTTPSuccess, Net::HTTPRedirection
# OK
else
res.error!
end
Posted by Jan Štěrba over 2 years ago
Potřebuju grafika. Ale nejenom grafika. Potřebuju člověka s citem pro detail, použitelnost a eleganci. Člověka znalého prostředí webových aplikací. Nejradši někoho jako je Martin Cohen. Mám hromadu nápadů a občas i nějaký ten čas, ale práce s jakýmkoli grafickým editorem je pro mě očistcem. Trvá mi hodiny než vytvořím něco co má člověk s grafickým citem za pět minut. Přitom vím jak je pro uživatele vzhled aplikace důležitý. Potřebuju člověka, který si, tak jako já, rád hraje, má čas a chuť dělat věci jinak, experimentovat a prostě se prací bavit.
Jak jsem už říkal, mám několik nápadů na potenciálně výdělečné a hlavně zájímavé projekty nad Ruby On Rails, ale chtělo by to někoho, kdo dokáže dát věcem tvář. Hledám někoho kdo si rozumí s grafikou a neštítí se HTML/CSS. Hledám někoho kdo se nebojí si hrát a dělat věci pořádně.
Posted by root.cz over 2 years ago
Unicode je jedna z nejdůležitějších dnešních technologií, přesto je jeho podpora v Ruby stejně jako v mnoha dalších programovacích jazycích problematická. Pomoc však existuje, možností pomoci je dokonce více. Jak tedy nepodporu unicode elegantně vyřešit?
Posted by root.cz over 2 years ago
Na nedávné RubyConf 2007 v Berlíně bylo představeno nové IDE zaměřené na vývoj v Ruby a především v Ruby on Rails. Protože IDE pro Ruby a Ruby on Rails v současné době spíše nejsou nežli jsou, vzbudilo 3rdRail patřičný rozruch. Jaké je? Co nového přináší?
Posted by root.cz over 2 years ago
V posledním díle seriálu o utilitkách pro Ruby věnovaném systému Rake se budeme zabývat využití Rake ve webovém frameworku Ruby on Rails. Nakonec si vezmene křišťálovou kouli a podíváme se do budoucnosti, jinými slovy podíváme se na chystané novinky v Rake.
Posted by root.cz over 2 years ago
V dnešním díle seriálu o utilitkách pro Ruby přijdou na přetřes jednotlivé knihovny pro tvorbu specifických tasků, naučíme se balit balíčky pomocí Rake, mazat dočasné soubory, ale také automatizovat testování naší aplikace a generovat dokumentaci.
Posted by root.cz over 2 years ago
V dnešním díle seriálu o utilitkách pro Ruby budeme pokračovat v popisu buildovacího systému Rake a konkrétně se budeme věnovat třídě FileList. Povíme si také další podrobnosti o vyvolávání jednotlivých tasků přímo z těla jiného tasku a řekneme si také, jakých zajímavých úprav doznal modul FileUtils v Rake.
