Comments for Java crumbs http://blog.krecan.net Short remarks from Java world Wed, 10 Mar 2010 12:21:03 +0100 http://wordpress.org/?v=2.8.6 hourly 1 Comment on Tomu říkám prosakující abstrakce by v6ak http://blog.krecan.net/2008/10/27/tomu-rikam-prosakujici-abstrakce/comment-page-1/#comment-1541 v6ak Wed, 10 Mar 2010 12:21:03 +0000 http://blog.krecan.net/?p=127#comment-1541 Jojo, teď zrovna dělám v LaTeXu a občas na něco trošku narážím... Jojo, teď zrovna dělám v LaTeXu a občas na něco trošku narážím...

]]> Comment on Tomu říkám prosakující abstrakce by Tomáš Záluský http://blog.krecan.net/2008/10/27/tomu-rikam-prosakujici-abstrakce/comment-page-1/#comment-1540 Tomáš Záluský Tue, 09 Mar 2010 23:43:04 +0000 http://blog.krecan.net/?p=127#comment-1540 Koukám rok a půl starý článek (narazil jsem na něj z Dagiho posledního tweetu), ale stále aktuální. Ještě bych jako krásný příklad prosakující abstrakce uvedl LaTeX jako pokus o odstínění TeXu. Koukám rok a půl starý článek (narazil jsem na něj z Dagiho posledního tweetu), ale stále aktuální. Ještě bych jako krásný příklad prosakující abstrakce uvedl LaTeX jako pokus o odstínění TeXu.

]]> Comment on Generovaný kód je zlo. A to i ve webových službách. by ARny http://blog.krecan.net/2010/02/21/generovany-kod-je-zlo-a-to-i-ve-webovych-sluzbach/comment-page-1/#comment-1483 ARny Sat, 27 Feb 2010 20:00:02 +0000 http://blog.krecan.net/?p=511#comment-1483 Suhlasim s v6ak, ze do generovaneho kodu nesmie byt zasahovane rucne. Vidim ze p. Krecan je skor zastanca online generovania kodu na pozadi ala hibernate/JPA atd. My ked sme s JPA robili prisli sme na problemy vyplivajuce objektoveho mapovania relacnych DB. Na niektore situacie reagoval ten vygenerovany kod nie tak ako by sme chceli a preto sme boli donuteni prejst na iBatis a pisat si vsetky mapovania sami. Jeho obrovska vyhoda je ze mate vsetko pod kontrolou a tak sme u neho zostali. Jeho problem vsak je ze ktorukolvek zmenu musite pracne upravovat v XML a entitach mapovania co vyzaduje cas a vznika tam velke mnozstvo chyb. Podla mna je vyhodne zgenerovat tieto casti kodu kedze nieje potrebne aby ich programator pisal rucne. Je to efektivne a prakticky nevznikaju chyby. Samozrejme je potrebne oddelit generovany kod a casti kodu ktore su napisane rucne (napr vlastne selecty). Ja osobne som zastanaca generovania zdrojoveho kodu a odporca roznych online generatorov. Proste som rad ked mam vsetko pod kontrolou ale zakladne veci nemusim pisat. Samozrejme to aku technologiu ci framework pouzijem zavisi na tom co idem robit pripadne co si ziada zakaznik ale inak rad pouzivam princip generuj to jednoduche a casto sa vyskytujuce a ostatne si napisem sam. Suhlasim s v6ak, ze do generovaneho kodu nesmie byt zasahovane rucne.
Vidim ze p. Krecan je skor zastanca online generovania kodu na pozadi ala hibernate/JPA atd. My ked sme s JPA robili prisli sme na problemy vyplivajuce objektoveho mapovania relacnych DB. Na niektore situacie reagoval ten vygenerovany kod nie tak ako by sme chceli a preto sme boli donuteni prejst na iBatis a pisat si vsetky mapovania sami. Jeho obrovska vyhoda je ze mate vsetko pod kontrolou a tak sme u neho zostali. Jeho problem vsak je ze ktorukolvek zmenu musite pracne upravovat v XML a entitach mapovania co vyzaduje cas a vznika tam velke mnozstvo chyb. Podla mna je vyhodne zgenerovat tieto casti kodu kedze nieje potrebne aby ich programator pisal rucne. Je to efektivne a prakticky nevznikaju chyby. Samozrejme je potrebne oddelit generovany kod a casti kodu ktore su napisane rucne (napr vlastne selecty). Ja osobne som zastanaca generovania zdrojoveho kodu a odporca roznych online generatorov. Proste som rad ked mam vsetko pod kontrolou ale zakladne veci nemusim pisat.
Samozrejme to aku technologiu ci framework pouzijem zavisi na tom co idem robit pripadne co si ziada zakaznik ale inak rad pouzivam princip generuj to jednoduche a casto sa vyskytujuce a ostatne si napisem sam.

]]> Comment on Generovaný kód je zlo. A to i ve webových službách. by Milan Fořt http://blog.krecan.net/2010/02/21/generovany-kod-je-zlo-a-to-i-ve-webovych-sluzbach/comment-page-1/#comment-1480 Milan Fořt Sat, 27 Feb 2010 15:38:17 +0000 http://blog.krecan.net/?p=511#comment-1480 Svůj názor ještě doplňuji o jednu situaci. Ať už jako poskytovatel nebo konzument webové služby pracuji s dokumentově orientovaným rozhranním. Použité XSD obsahuje byznysově zajímavé věci a vzniká jako výstup designera v rámci MDA, generuje se z UML. Nicméně používám architekturu, která do zpráv přidává aspekty jako je zabezpečení (autorizace - ACL záznamy u entity ..), audit informace/changelog apd. Tady si už nevystačím s hlavičkou zprávy, potřebuju obohatit zprávy o tyto informace. Technicky na to lze myslet pomocí xsd:anyType a JAX-WS se s tím dokáže nějak vyrovnat. Ale právě tady je zakopaný pes, JAXB objekty mě sice odstiňují, ale jen napůl. Stejně si pak musím XML navíc zpracovat sám. JAXB binding mě nepomáhá, zachraňuji to až Dozerem na úrovni mapování mezi java objekty. Ve chvíli, kdy implementace služby provolává jiné služby a dává jim podobné XML je vám asi jasné, kolik času mi trvá tvorba skutečné byznys logiky a kolik času propálím na uvedených věcech. Svůj názor ještě doplňuji o jednu situaci. Ať už jako poskytovatel nebo konzument webové služby pracuji s dokumentově orientovaným rozhranním. Použité XSD obsahuje byznysově zajímavé věci a vzniká jako výstup designera v rámci MDA, generuje se z UML. Nicméně používám architekturu, která do zpráv přidává aspekty jako je zabezpečení (autorizace - ACL záznamy u entity ..), audit informace/changelog apd. Tady si už nevystačím s hlavičkou zprávy, potřebuju obohatit zprávy o tyto informace. Technicky na to lze myslet pomocí xsd:anyType a JAX-WS se s tím dokáže nějak vyrovnat. Ale právě tady je zakopaný pes, JAXB objekty mě sice odstiňují, ale jen napůl. Stejně si pak musím XML navíc zpracovat sám. JAXB binding mě nepomáhá, zachraňuji to až Dozerem na úrovni mapování mezi java objekty. Ve chvíli, kdy implementace služby provolává jiné služby a dává jim podobné XML je vám asi jasné, kolik času mi trvá tvorba skutečné byznys logiky a kolik času propálím na uvedených věcech.

]]> Comment on Generovaný kód je zlo. A to i ve webových službách. by Milan Fořt http://blog.krecan.net/2010/02/21/generovany-kod-je-zlo-a-to-i-ve-webovych-sluzbach/comment-page-1/#comment-1474 Milan Fořt Thu, 25 Feb 2010 20:37:12 +0000 http://blog.krecan.net/?p=511#comment-1474 Osobně se snažím nemíchat kód endpointů webových služeb s kódem dao komponent. Endpointy jsou vzdáleným rozhranním a tomu odpovídá datový model (často založený na podnikovém canonical data modelu). Snažím se tvořit hrubozrný interface. Byznys logiku do endpointů nedávám, od toho mám komponenty byznys služeb. Tam už se objevuje i jemnozrný interface, se kterým se dobře pracuje z javy. Perzistenci beru jako pomocnou službu, ať už řešenou aplikační databází nebo voláním vzdálených služeb příslušné byznys domény, vlastnící data. U endpointů třeba z Jax-WS je také problém v konfrontaci se Springem, měl jsem problémy třeba s anotacemi kolem aspektů - Spring tvořil proxy a narazil ... Kde s Tebou ale Lukáši plně souhlasím je pocit něčeho chybějícího mezi contract-first a contract-last přístupem u ws stacků jako je třeba Jax-WS. Stává se mi, že někde potřebuju pracovat s XML příchozí zprávy a v případě kompozice služeb kus XML efektivně poslat jiné službě. Převod XML-Object a pak zas Object-XML se mi nelíbí, ještě víc se mi nelíbí způsoby, jak se k XML dostat z Jax-WS. V dokumentově orientovaných zprávách, na službách s hrubozrným rozhranním je tohle běžné. Řešením může by mohlo být použití třeba Service Data Objects. Osobně se snažím nemíchat kód endpointů webových služeb s kódem dao komponent. Endpointy jsou vzdáleným rozhranním a tomu odpovídá datový model (často založený na podnikovém canonical data modelu). Snažím se tvořit hrubozrný interface. Byznys logiku do endpointů nedávám, od toho mám komponenty byznys služeb. Tam už se objevuje i jemnozrný interface, se kterým se dobře pracuje z javy. Perzistenci beru jako pomocnou službu, ať už řešenou aplikační databází nebo voláním vzdálených služeb příslušné byznys domény, vlastnící data. U endpointů třeba z Jax-WS je také problém v konfrontaci se Springem, měl jsem problémy třeba s anotacemi kolem aspektů - Spring tvořil proxy a narazil ... Kde s Tebou ale Lukáši plně souhlasím je pocit něčeho chybějícího mezi contract-first a contract-last přístupem u ws stacků jako je třeba Jax-WS. Stává se mi, že někde potřebuju pracovat s XML příchozí zprávy a v případě kompozice služeb kus XML efektivně poslat jiné službě. Převod XML-Object a pak zas Object-XML se mi nelíbí, ještě víc se mi nelíbí způsoby, jak se k XML dostat z Jax-WS. V dokumentově orientovaných zprávách, na službách s hrubozrným rozhranním je tohle běžné. Řešením může by mohlo být použití třeba Service Data Objects.

]]> Comment on Generovaný kód je zlo. A to i ve webových službách. by Vlastik Eliáš http://blog.krecan.net/2010/02/21/generovany-kod-je-zlo-a-to-i-ve-webovych-sluzbach/comment-page-1/#comment-1465 Vlastik Eliáš Wed, 24 Feb 2010 08:36:19 +0000 http://blog.krecan.net/?p=511#comment-1465 Příme mapování XML JavaBeans DB se společnou sadou JavaBeans jsem dělal již někdy v roce 2004, tehdy s použitím frameworků Castor XML a Hibernate 2.1 (mapování popsáno v XML souborech). Částečně jsem ty JavaBeans a mapovací soubory generoval a pak doupravoval ručně. Použito bylo pro exporty a importy dat (XML soubory velké i několik MB). Stejné JavaBeans pak tvořili model pro web aplikaci, která data zobrazovala (tehdy ještě Struts), a pro částečné exporty dat do dalších různých formátů (XML i nonxml). Fungovalo/funguje to perfektně dodnes (viz http://kramerius.nkp.cz). S dnešními frameworky by to podle mě bylo ještě víc v pohodě, myslím že na to není třeba silný žaludek. Příme mapování XML JavaBeans DB se společnou sadou JavaBeans jsem dělal již někdy v roce 2004, tehdy s použitím frameworků Castor XML a Hibernate 2.1 (mapování popsáno v XML souborech). Částečně jsem ty JavaBeans a mapovací soubory generoval a pak doupravoval ručně. Použito bylo pro exporty a importy dat (XML soubory velké i několik MB).
Stejné JavaBeans pak tvořili model pro web aplikaci, která data zobrazovala (tehdy ještě Struts), a pro částečné exporty dat do dalších různých formátů (XML i nonxml). Fungovalo/funguje to perfektně dodnes (viz http://kramerius.nkp.cz).
S dnešními frameworky by to podle mě bylo ještě víc v pohodě, myslím že na to není třeba silný žaludek.

]]> Comment on Generovaný kód je zlo. A to i ve webových službách. by lzap http://blog.krecan.net/2010/02/21/generovany-kod-je-zlo-a-to-i-ve-webovych-sluzbach/comment-page-1/#comment-1462 lzap Tue, 23 Feb 2010 22:47:48 +0000 http://blog.krecan.net/?p=511#comment-1462 Zas tak bych to nepaušalizoval. Ne vždy je možné si "diktovat" jak bude interface vypadat. Takže se prostě někdy musí generovat... Zas tak bych to nepaušalizoval. Ne vždy je možné si "diktovat" jak bude interface vypadat. Takže se prostě někdy musí generovat...

]]> Comment on Generovaný kód je zlo. A to i ve webových službách. by v6ak http://blog.krecan.net/2010/02/21/generovany-kod-je-zlo-a-to-i-ve-webovych-sluzbach/comment-page-1/#comment-1461 v6ak Tue, 23 Feb 2010 19:26:00 +0000 http://blog.krecan.net/?p=511#comment-1461 Čím je to dáno? Je to opravdu tím, zda je to za běhu? U zmíněných věcí mám namysli generování během kompilace: http://projectlombok.org/ . Mám teda i zkušenosti s Google Protocol Buffers, které sice udělaly svoji práci, ale musel jsem to obalovat vlastní vrstvou, mj. kvůli polymorfismu. Generování je zlo, pokud: * je generovaný kód míchán s ručně udržovaným (typicky v jednom souboru), nebo * je do generovaného kódu ručně zasaženo (nepřál bych si dne, kdy je potřeba jej přegenerovat...) * logika generovaného kódu ne úplně sedí (někdy lze vyřešit další vrstvou) - o tom je v článku a i moje poznámka o protobuf Čím je to dáno? Je to opravdu tím, zda je to za běhu? U zmíněných věcí mám namysli generování během kompilace: http://projectlombok.org/ .

Mám teda i zkušenosti s Google Protocol Buffers, které sice udělaly svoji práci, ale musel jsem to obalovat vlastní vrstvou, mj. kvůli polymorfismu.

Generování je zlo, pokud:
* je generovaný kód míchán s ručně udržovaným (typicky v jednom souboru), nebo
* je do generovaného kódu ručně zasaženo (nepřál bych si dne, kdy je potřeba jej přegenerovat...)
* logika generovaného kódu ne úplně sedí (někdy lze vyřešit další vrstvou) - o tom je v článku a i moje poznámka o protobuf

]]> Comment on Generovaný kód je zlo. A to i ve webových službách. by Lukáš Křečan http://blog.krecan.net/2010/02/21/generovany-kod-je-zlo-a-to-i-ve-webovych-sluzbach/comment-page-1/#comment-1460 Lukáš Křečan Tue, 23 Feb 2010 15:34:14 +0000 http://blog.krecan.net/?p=511#comment-1460 @v6ak: To je zajímavá otázka. Pokud je to generováno za běhu, tak ne. Generování za běhu je věc užitečná, psal jsem je o generování zdrojového kódu. Pokud je generovaný přímo zdrojový kód, tak je to složitější. Já to taky používám, ale jsou s tím problémy. Například na to pak nejsou unit testy. Dále pak, když přidám nějakou položku, hashCode, equals ani toString se mi nezmění. Takže pro mě je to zlo, ale přijatelné :-) @v6ak: To je zajímavá otázka. Pokud je to generováno za běhu, tak ne. Generování za běhu je věc užitečná, psal jsem je o generování zdrojového kódu. Pokud je generovaný přímo zdrojový kód, tak je to složitější. Já to taky používám, ale jsou s tím problémy. Například na to pak nejsou unit testy. Dále pak, když přidám nějakou položku, hashCode, equals ani toString se mi nezmění. Takže pro mě je to zlo, ale přijatelné :-)

]]> Comment on Generovaný kód je zlo. A to i ve webových službách. by v6ak http://blog.krecan.net/2010/02/21/generovany-kod-je-zlo-a-to-i-ve-webovych-sluzbach/comment-page-1/#comment-1458 v6ak Tue, 23 Feb 2010 13:35:49 +0000 http://blog.krecan.net/?p=511#comment-1458 Generování toString(), equals(Object) a hashCode() díky anotacím je taky zlo? Generování toString(), equals(Object) a hashCode() díky anotacím je taky zlo?

]]>