pátek 26. října 2007

Potřebujeme silné nástroje

Dnes jsem si v jedné nejmenované diskusní skupině přečetl, že vizuální návrháře nepatří do IDE, protože jsou často zneužívány v rukouch méně zkušených vývojářů. Tento názor je odvozen podlé mého soudu z ještě obecnější teze, a to že nástroje, které se snaží zakrývat komplexnost dané technologie jsou špatné, protože vedou k špatnému používání dané technologie. Já osobně tento názor nesdílím a považuji jej za jeden z velkých mýtů přeživších z dob špatných HTML editorů. Na následujících řádcích vám zkusím nastínit proč.

Skrývání komplexnosti vývoje je právě ten důvod proč používáme IDE (vývojová prostředí). Kdyby byla tato komplexnost vývoje malá, používali bychom dodnes textový editor a kompilátor ovládaný z příkazové řádky. Dnešní vývoj je ohraničen mantinely jako znovupoužitelnost, standardizace a dalšími. Ty mají za jediný cíl posunout celý proces vývoje dál, výše rychleji s co nejnižšími náklady.

Z tohoto důvodu jsou dnešní programy protkané různými abstrakcemi a technologiemi, které řádově zvyšují jeho složitost a tím pádem se zvyšuje i komplexnost vývoje. IDE by nám měly umožnit držet tuto komplexnost na přijatelné úrovni vzhledem k naší znalosti kontextu. Zkušený a nezkušený vývojář má na IDE různé nároky a IDE by mělo umožnit stejnou efektivitu oběma. V případě méně zkušeného vývojáře to mohou klidně být různí průvodci (wizzardy) pro vytipované případy užití (nová stránka, přechod mezi stránkami, mapování entity) a nebo vizuální editory. Zkušenému vývojáři budou stačit méně specifické prostředky jako editor kódu.

IDE by se rozhodně nemělo snažit upřednostňovat jeden způsob na úkor druhého, rozhodně ne z důvodu možného zneužití dané technologie. Ta jde totiž zneužít bez ohledu na jestli použijete vizuální návrhář a nebo to napíšete ručně. Dnešní IDE si vzala lekci z vizuálních HTML editorů přelomu tisíciletí a nesnaží se pouze o co největší efektivitu, ale i o to, aby vývojáře částečně vedly k správnému používání dané technologie.

Samozřejmě ne vše je úplně ideální. V oblasti IDE pro platformu Java je znát rozdílná filozofie jednotlivých produktů. NetBeans jsou vhodným nástrojem pro méně zkušené vývojáře, naopak Eclipse a IntelliJ IDEA je vhodnější pro zkušenější uživatele. Kdyby bylo možné tyto tři IDE spojit dohromady, získali bychom velice silný nástroj pro skrývání komplexnosti v závislosti na úrovni znalostí vývojáře.

Reakce

středa 24. října 2007

Do pranice: Spring Web Flow a nebo JBoss Seam

Právě jsem s naším UI architektem rozebíral dilema, jaký framework zvolit pro naš webový front end. Celá diskuse se se točila kolem Spring Web Flow (dále SWF) a Jboss Seam (dále Seam). Oba frameworky nabízejí přibližně stejné možnosti a tak jsme sklouzávali k drobným nuancím, které alespoň pro mě vyznívají ve prospěch SWF.

Pokud jste ani o jednom z frameworků neslyšeli, pak Vás v případě SWF odkážu na článek Vlasty Vávrů Spring web flow - framework pro management toku web aplikace a v případě SEamu k Petrovi Ferschmannovi na jeho přednášku Seam (a JSF).

Pro nás je důležité, že oba web frameworky nabízejí takzvané konverzace neboli definice toku aplikace. Konverzace je několik request/response cyklů, které jsou z pohledu aplikace jedním logickým celkem např. objednávka (vyplnění objednávky, kontrola dat, volba dopravy, způsob platby, preview, odeslání k vyřízení). Oba dva frameworky lze také integrovat se Springem a to je důležité z toho důvodu, že aplikační logika je z valné většiny skládána Springem.

Co mi u obou frameworků naopak chybí, je větší podpora ve vývojových nástrojích. Oba mají podporu pouze pro Eclipse, škoda že na tom nic nezmění, alespoň pro SWF, oznámená Spring Tool Suite.

Seam

Po mém soudu má Seam dvě zásadní vlastnosti, které pokládáte buďto za výhodu, nevýhodu a nebo minimálně za kontroverzi. Seam vede k masivnímu používání anotací a k obcházení controller/view helper komponenty. Abych byl spravedlivý, pak musím dodat, že i Seam nabízí xml konfiguraci. Na kolik je ekvivalentní anotacím nedokážu posoudit. Controller/view helper je obejit tím, že do se modelové třídy přimo nastavují/vyzvedávají z aplikační logiky. S tím už mám trochu větší problém z hlediska architektury neboť se aplikační logika ohýbá pro potřeby web frameworku. Protože je ta samá logika vystavená přes REST, pak toto svázání přináší problémy.

Výhodu Seamu vidím v tom, že se skrze WebBeans stane J2EE standardem. To přinese rozšíření konceptů, které Seam představil a z toho vyplývající plusy. Abych nezapomněl early draft WebBeans specky je k dispozici, případně si můžete přečíst sérii článků Web Beans Sneak Peek, které představil dvorní autor Gavin King.

SWF

SWF nabízí tři velice zajímavé vlastnosti, které použijeme. První je programové rozšiřování konverzací a programové ovládání (integrační testy). Druhou výhodou je fakt, že SWF je mnohem benevolentnější k volbě view technologie (JSF, Spring MVC, Struts). Třetí výhodou je jako u většiny Spring projektů Open Closed princip, to je pro nás důležité z toho důvodu, že máme stávající framework, který musí spolupracovat.

Seam ani jednu z těchto vlastností pořádně nepodporuje. Řekl bych, že je to způsobené jeho zaměřením. Seam už pomalu přechází do roviny aplikačního frameworku, viz například podpora scheduleru. Oproti tomu SWF je úzce zaměřeno na oblast frontendové části aplikace. Pokud se tedy bude rozšiřovat SWF, bude to pravděpodobně směrem k frontendu, oproti tomu Seam poroste směrem opačným.

Po zvážení těchto kladů a záporů jsem se nakonec rozhodl přiklonit k SWF. Pokud máte nějaký argument pro/proti Seam/SWF rád si jejv diskusi přečtu.

pondělí 22. října 2007

Tanečky kolem rychlosti Springu

Lukáš Křečan sice neumí moc psát bulvární titulky, nicméně o to lépe mu jde psaní seriozního obsahu. V článku Je Spring pomalý? odhaluje jádro pudla.

Spring jenom věci spojuje a veškerou práci na někoho deleguje. Napadají mě jenom dvě oblasti, kde by teoreticky mohl Spring někoho zpomalovat. První je start aplikace, kdy startuje aplikační kontext, vytvářejí se proxy a injektují se závislosti. Z mých zkušeností start aplikačního kontextu probíhá velmi rychle i u rozsáhlých projektů (jenom kdyby nezdržoval ten Hibernate). Další oblastí, kde by teoreticky mohl Spring běh aplikace zpomalit je AOP. Ale i to z velké části deleguje na JRE nebo CGLIB. Skoro všechno ostatní neřeší Spring, ale jiné produkty (Hibernate, aplikační server, JDBC, Quartz, …). Takže zopakujme si to znovu. Spring nic nedělá, jenom nám spojuje kousky skládačky dohromady. Pokud je ta skládačka pomalá, nemůže za to lepidlo, můžou za to ty kousky samotné.

Lukáš má samozřejmě pravdu, ale o tom jsem nechtěl psát. Chtěl jsem se s vámi podělit o to, že se najdou extrémisté, kteří jsou schopni měřit rychlost toho lepidla. William Louth napsal článek Benchmark Analysis: Guice vs Spring, ve kterém je srovnání rychlosti IoC kontejneru Spring a Google Guice. O přínosu naměřených dat a potažmo celého benchmarku by se dalo spekulovat. Můj osobní nazor je ten, že celý benchmark nemá žádný význam pro praktické nasazení.