Ostrava on Rails: Tobias Lütke o Shopify
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."