WebExpo 2010 – pátek z mého pohledu
Školení, která pořádám 
Po příjezdu na WebExpo mě zarazila nepříjemně dlouhá fronta. Tušil jsem, že je na registraci, ale raději jsem se šel podívat. Chvíli jsem pozoroval dění, pak jsem našel cedulku se svým jménem, a tak jsem si ji vzal. Hostesky mi jen ještě podaly lístky na oběd (které stejně nebyly potřeba) a mohl jsem jít. Omlouvám se všem, které jsem předběhl (zdržení bylo asi tři sekundy), ale kdo nepotřeboval nic speciálního, mohl to udělat stejně. Tričko a knihu jsem si vyzvedl později.
Teď už k samotným přednáškám, které jsem navštívil:
CouchDB – Databáze pro web
Velmi pěkně udělaná přednáška Karla Minaříka popsala základní i trochu pokročilejší vlastnosti CouchDB. Část věcí už jsem znal, navíc se přednášce z mého pohledu dostatečně nepodařilo vyzdvihnout výhody bezschémových databází ve srovnání s relační strukturou a smysluplným využitím indexů. I tak ale šlo o povedenou přednášku. Bohužel jsem odešel před koncem, protože jsem chtěl vidět přednášku celosvětové Internetové celebrity…
Fronteers
Peter-Paul Koch řekl v podstatě pouze to, že se v Holandsku scházejí každý měsíc v padesáti lidech na pivo, před kterým si povídají o CSS, JavaScriptu a dalších věcech front-end developerů. Přesto o tom zvládl povídat 15 minut. Smysl této „přednášky“ jsem nepochopil, obzvlášť když jsou v ČR podobné akce poměrně běžné (např. Poslední soboty).
Software Development = Learning
Přednáška dvou Rumunů neřekla o moc víc, než je uvedeno v titulku. Tvrzení výroku bylo podpořeno spoustou citátů lidí, které neznám. Odešel jsem před koncem.
Kreativec je kdekdo
Stihl jsem kousek přednášky, kde Lukáš Plíhal podle všeho představil práci dvou architektů a jednoho kuchaře. Prezentace byla zajímavá, ale z posledních deseti minut nechci přednášku hodnotit.
Kreativní×Efektivní
Lukáš Veverka a Petr Skala představili část své práce, kterou dělali pro Českou televizi, Novu nebo reklamní agentury. Tito tvůrci videospotů vysvětlili, že není vždycky dobré se nechat svazovat termíny, rozpočtem nebo zadáním klienta. S těmito myšlenkami se částečně ztotožňuji, ale proč byla tato přednáška umístěna na konferenci o webu, moc nevím.
Debugging with Xdebug
Po obědě, na který jsem šel dost včas na to, abych se vyhnul frontě, jsem se těšil na přednášku od Dericka Rethanse. XDebug celkem důvěrně znám, i tak mi ale přednáška přišla zajímavá. Popis ladícího výpisu proměnných a chyb byl v ČR spíš kontraproduktivní, protože spousta lidí je zhýčkaná Laděnkou. Dozvěděl jsem se ale o jednoduché samostatné aplikaci pro ladění gtk-xdebug-client a zaujala mě možnost otevřít soubory z ladícího výpisu jedním kliknutím v prohlížeči. Začátek se protáhl asi o deset minut, protože na projektoru chybělo pár pixelů. Škoda tohoto zdržení, Derick ale dokázal bavit lidi i během této nepříjemné chvilky.
Vývoj v PHP řízený testy
To, že přednáška nebude určena pro mě, jsem začal tušit, už když Filip Šubr řekl, že je z firmy Actum. Když asi popáté zopakoval „Hm, jak to jenom bylo“ nebo podobnou frázi, tak jsem začal tušit, že se v přednášce naprosto ztrácí. Vypadalo to, že tři dny nespal, neměl žádné slajdy a jak na konci prozradil, opravdu nutně si potřeboval zakouřit. Po začátku jsem odešel, ale před koncem jsem se vrátil, kdy jsem si ověřil, že jsem neudělal chybu.
The Touch Events
Druhá přednáška Petera-Paula Kocha byla o poznání zajímavější. Bohužel jsem ji opět nestihl od začátku, ale popis dotykových událostí na mobilních telefonech byl pro mě nepoznanou oblastí. Trošku mě zklamala odpověď na otázku, který další principiálně odlišný způsob vedle myši, klávesnice a dotyku známe. Já jsem navrhoval kompas a gyroskop, někdo další třesení, odpovědí ale byl trackball, u kterého se stěží podařilo vysvětlit rozdíl od myši. PPK ale přislíbil, že se nad přidáním těchto událostí zamyslí.
PHP business objects
Přednáška estonského vývojáře Skype přehledně představila princip Dependency Injection. Bohužel ale zcela zamlčela koncepci Service Locatoru, který používá třeba Nette a který myšlenku posouvá o úroveň dál. Když vytváříme objekt starající se o zpracování produktu, proč bychom měli jakýmkoliv způsobem odpovídající třídě říkat, co chceme používat jako databázi a co jako mailer? Lepší podle mě je, když si to třída vytáhne sama z centrálního úložiště. Flexibilita je stejná, kódu staší napsat méně.
Proč ne ORM
Michal Špaček bez zbytečných emocí vysvětlil, proč ve Skype nepotřebují ORM a místo toho používají uložené procedury v PostgreSQL naprogramované v PL/SQL nebo v PL/Python. Šlo nejspíš o podobnou přednášku, jako na Poslední sobotě, tu jsem ale neviděl. Já uložené procedury příliš v lásce nemám, protože jednak v MySQL nemají takovou tradici jako v jiných databázích a jednak se dost těžko píšou v PHP. Navíc žerou procesorový čas databáze.
Nette Framework 1.0: příští VELKÁ věc
David Grudl představil novinky Nette Frameworku 2. Těší mě změna čísla verze, protože podle mého názoru by si Nette už dávno vyšší číslo verze zasloužilo. David v podstatě zopakoval informace, které už řekl na Poslední sobotě během asi sedmi minut, i tak ale podle mě šlo o velmi povedenou přednášku dobře uzpůsobenou cílovému publiku. Na závěr si nechal jednu „bombu“ spočívající v tom, že zpracování odkazu AJAXem lze povolit prostým uvedením mřížky v routě. Prezentace mi přišla mnohem lepší, než ta loňská.
Digit 53.
Krátce po začátku rozhovoru se podařilo navodit uvolněnou atmosféru a s Davidem bylo příjemné popovídání podobně jako v hospodách. Vtípky přicházely od všech zúčastněných a publikum je opravdu ocenilo.
NotORM ve srovnání s NoSQL a ORM
Přednáška o NotORM od Jakuba Vrány se bohužel neuskutečnila. Nabídl jsem ji pořadatelům v červenci, ale už nebylo místo ani v jedné místnosti, které by připadaly do úvahy. PHP místnost sice byla v podvečer volná, ale přednášet proti Davidovi bych nikomu nepřál. Neskromně si myslím, že by přednáška byla zajímavější než některé z těch, které jsem navštívil (obzvlášť po zkušenostech z Indie), ale takový je holt už život.
Článek průběžně doplňuji. Konference pokračovala v sobotu.
Diskuse
.:
az mam skoro chut se zeptat jestlis videl Radka Hulana :)(:
ServiceLocator jak ho popisujete vy je AFAIK povazovany za anti-pattern, ponevadz zavadi zavislost na nesouvisejici tride.Holmistr:
Jak to tak čtu, tak mi (zatím) nepříjde, že bys považovat webExpo za nějak extra přínosný..:-) Určitě se budu těšit na nějaké závěrečné zhodnocení nebo tak něco..PR:
Ze stejného důvodu jsme v podstatě vyhodili peníze za loňský rok (a letos to vůbec neřešili). Přednášky byly nedotažené a když někdo začne říkat ,,kde jsem to jen zkončil", patří na 1. stupeň VŠ a ne na konferenci za 5k....
optik:
Jak píše "otočený smajlík" service locator je spíš DI anti pattern - "lepší new", klasická konstuktorová DI je pro udržovatelný kód mnohem lepší. Trochu se vám to v Nette komunitě pomotalo :)
Jakub Vrána 
:
Zásadní problém new je ten, že třídě nemůžu třeba při testování podstrčit jiný objekt. S tímhle Service Locator problém nemá.
Klasické DI, alespoň v té formě, jak bylo popisované na přednášce, má podle mě zcela fatální problém v tom, že parametry konstruktoru závislostí je potřeba předávat každé třídě zvlášť. Navíc to je práce, které bych se nejraději zcela vyhnul.
Popiš prosím, čím je Service Locator pro udržovatelný kód mnohem horší.
Jakub Vrána : optik:
vždyť říkám, že service locator je lepší new, dependency ukrývá, z popisu třídy vůbec nepoznám co vlastně používá za dependency = horší pro maintanance, dále přesouvá detekci chyb z compile time do runtimeoptik:
to s tím compile time vs runtime u php neplatí, spíš type hint error vs. exception nebo tak něco, ale obojí runtime Jakub Vrána :
Jaké závislosti třída má, lze z popisu snadno poznat třeba z dokumentačního komentáře @uses.
Já u klasického DI nechápu, proč když se třída rozhodne, že si bude třeba něco logovat nebo něco někam posílat, proč by se o to měli starat všichni ti, kdo ji používají. A stejně tak, proč bych parametry všech služeb měl předávám všem třídám.
Podle mě to jen spousta kódu navíc, u kterého ve srovnání se Service Locatorem nevidím jediný praktický přínos.
Jakub Vrána : David Grudl:
Jen k tomu dodám, že "service locator" v Nette není implementací stejnojmenného návrhového vzoru. Nicméně vím, že se často používá nešťastně, snažím se o nápravu.Pavel Cvrček:
Přednáška "Kreativec je kdekdo" byla pěkná celá, mohu potvrdit. Nemohu to však bohužel říci o každé přednášce, kterou jsem dnes navštívil. Bohužel jsem se setkal i s PR a o organizačních problémech nemluvě :(
Pavel Stehule:
Tady musím komentovat názor, že uložené procedury žerou procesor databáze a proto je špatné je používat. Je pravda, že uložené procedury běží na serveruí, ale většinou v tom samém procesu - takže nedochází ke context switchi, takže samotný běh je relativně laciný, to co ovšem uspoří je meziprocesová (případně TCP/IP) komunikace mezi klientem a serverem, která je řádově náročnější. Tudíž rozumně psané uložené procedury vždy zrychlí aplikaci a sníží zatížení serveru. Je důležité vědět, že komunikace mezi třeba PHP a MySQL není zadarmo - že si své vezme. Navíc díky rychlejšímu zpracování - odpadá čekání na komunikace se zkracují doby držení zámků, tudíž ve výsledku je databáze průchodnější.Petr Tvaroha:
V podstatě o tom mluvil Michal Špaček. Už jsem měl v minulosti to nutkání vložit celou aplikační logiku do db (postgres). Jen si trochu lámu hlavu s tím, jak naložit s předáváním uživatelských chyb z db do php a následným případným překladem do jiného jazyka a zobrazení uživateli, abych nemusel použít pouze konstatní chybové hlášky.Pavel Stehule:
Záleží na databázi - počínaje 8.4 můžete použít relativně komfortní vlastní výjimky - které se neomezují pouze na plochý text - tj. k dispozici je SQLCODE, message, hint, detailhttp://www.depesz.com/index.php/2008/05/14/…-plpgsql-raise/
Michal Špaček:
Každá naše funkce vrací sloupce status a status_text, kde status 200-299 je považován za "Ok" status, 300+ je chybový stav, v podstatě obdoba HTTP status kódů. Volající aplikace se podle toho zachová. status_text je freeform textové pole, které je pro lidi, většinou se jen zaloguje a říká, co přesně se stalo, aby se to dalo poznat na první pohled.Příklad
-- Status Code:
-- 200, Ok - checks passed
-- 201, Preapproved action exists - no check
-- 202, No associated key_campaign - no check
-- 203, Campaign target is not username and also no node id filter defined - no check
-- 400, User already used campaign id
-- 401, User does not have node id - check failed
-- 402, Node id has orders with that campaign id
-- 404, Order id not found
Karel Minařík:
Díky za feedback, Jakube.
Jen mně dost překvapuje tvoje námitka, že mi se "dostatečně nepodařilo vyzdvihnout výhody bezschémových databází". Snažil jsem se právě tomuto tématu věnovat poměrně zásadní část přednášky v úvodu, až mně dodatečně mrzelo, že jsem nestihnul probrat některé unikátní vlastnosti CouchDB (živou demonstraci replikace, HTTP stream změn v databázi, apod.)
Jak konkrétně by sis to představoval, nebo co ti přesně chybělo?
Jakub Vrána :
Řeknu to takhle: ještě jsem nenašel scénář, pro který by se mi vyplatilo bezschémové databáze použít, všechno jsem zatím zvládl celkem pohodlně udělat v relační databázi s dobře navrženou strukturou a indexy. Tvoje přednáška mi v tom nepomohla. Ale není to tvoje kritika, třeba jde o neřešitelný problém – třeba všemu, co dělám, relační databáze vyhovují.
Docela dost času jsi věnoval vyzdvihování vlastností, které považuji za implementační detaily. Použití HTTP jako přenosového protokolu a JSONu jako formátu dat mě prakticky vůbec nezajímá – na straně serveru zavolám funkci a očekávám vrácený objekt nebo pole a co je vespod, mi je jedno. Při volání z JS to může být užitečné, ale na druhou stranu napsání obálky, která HTTP a JSON přeloží na cokoliv jiného, je otázka pár řádek.
Za nejzásadnější vlastnost CouchDB považuji map/reduce. O tom jsi mluvil také moc pěkně, ale mě z toho vyšlo v podstatě to, že si můžu vytvořit vlastní agregační funkci, pro což nemám reálné využití. Ale schopnost snadného rozdělení na více serverů je samozřejmě ten největší přínos.
Jakub Vrána : Karel Minařík:
> "Použití HTTP jako přenosového protokolu a JSONu jako formátu dat mě prakticky vůbec nezajímá (...)"
Pak se mi bohužel nepodařilo -- anebo to nejde :) -- vysvětlit ti, proč je to zásadní vlastnost a nikoliv implementační detail. Je přeci _zásadní_ rozdíl např. mezi cachováním na úrovni HTTP a "cachováním" aplikačních dat přes nějaké MemcacheD vložené do stacku aplikace. Ale naprosto zásadní. Stejně tak je poměrně zásadní rozdíl mezi JSONem, kterým mohu "přirozeně" modelovat heterogenní, proměnlivé dokumenty, a který se 1:1 mapuje na základní syntaktické prvky jazyka a mezi "řádky", které mi vrací dotaz a které si musím na straně aplikace všemožně agregovat. Nemluvě o tom, že mohu mít _pohodlně_ v databázi uložená i binární data. (Což můžu mít v *SQL taky, ale s tou pohodlností to asi bude docela jinak.)
> " (...) všechno jsem zatím zvládl celkem pohodlně udělat v relační databázi (...)"
No jasně, aby ne :) Děláš to počítám hodně dlouho, dobře tomu rozumíš, a jsi autorem a správcem projektu na rozhraní k *SQL databázím. Nejde totiž ani *zdaleka* o tom, čemu co "vyhovuje". Cokoliv se nějak dá udělat v čemkoliv. Jde právě o to, co je pohodlnější, zajímavější, uspokojivější. Nevěřím, že všemožné `ALTER TABLE` jsou i pro tebe pohodlné. Nevěřím, že změna schématu datového modelu je v *SQL "pohodlná". Je to přece naopak: právě to, že _není_ pohodlná je pro mnoho DBAs důvod k obraně *SQL.
Jakub Vrána :
Já beru, že nad HTTP je vybudovaná nějaká infrastruktura, která spoustu věcí usnadňuje (hlavně reverzní proxy). A samozřejmě také chápu rozdíl mezi HTTP keší a vrstvou, kterou si musím sám napsat do aplikace. Ale obdobné řešení existuje i v konvenčním relačním světě – ať už v podobě MySQL Query Cache (která má tu nevýhodu, že běží na stejném serveru jako samotná databáze, na druhou stranu ale tu zásadní výhodu, že se okamžitě dozví o zneplatnění keše) nebo třeba MySQL Proxy.
Co se heterogenních dat týče, tak nějak nemám potřebu s takovými daty pracovat a naopak spíš vidím problémy, které bych musel řešit proto, že u některých záznamů část dat chybí. Hezký příklad jsou podle mě třeba parametry produktů, které jsou u každé kategorie v obchodě jiné a tudíž by k použití bezschémové databáze vyloženě sváděly. Já si to schéma ale raději stejně navrhnu (byť už bude trochu složitější), než abych musel řešit problémy s konzistencí dat – aby se stejný parametr u dvou různých produktů nejmenoval různě a aby podle těchto dat šlo tedy následně třeba vyhledávat.
Ukládání binárních dat rozumné velikosti je alespoň v MySQL zcela bezproblémové. Samozřejmě si musím napsat obálku, která mi data přepošle s odpovídající HTTP hlavičkou, stejnou obálku ale počítám musím mít i na vybalení z JSONu.
Samozřejmě, že změna schématu může být někdy pracná nebo bolestná. Ale beru to jako daň za to, že mám k dispozici perfektní dokumentaci toho, jaká data a v jakých vazbách mám vlastně uložena. To považuji za docela velkou nevýhodu bezschémových databází, které se v čase nějak vyvíjí. Musí být přece mimořádně protivné v kódu počítat s různými rozdíly záznamů podle toho, jak se „schéma“ v čase vyvíjelo. A nepřekvapilo by mě, když by z tohoto důvodu u bezschémových databází bylo pohodlnější nějakou konzistenci dodržovat, což je kvůli absenci odpovídajících nástrojů asi ještě pracnější než u relačních databází.
Abych to nějak shrnul – já vidím výhody bezschémových databází a strašně se těším na to, až najdu případ, na který by se mi je vyplatilo použít. Protože ale vidím i možné problémy a s relačními databázemi mám značné zkušenosti, tak se mi takový případ těžko hledá.
Jakub Vrána : Diskuse je zrušena z důvodu spamu.
© 2005-2024 