čtvrtek 12. července 2007

Konvenční lži

Čas od času narazím na rádoby pravidla týkající se vývoje a vývojářů. Tyhle pravidla osobně označuji termínem konvenční lež a v tomto článku se na tři z nich podívám.

Programátor po třicítce je neúspěšný programátor

Nevím kdo to vymyslel každopádně se setkávám s názorem, že pokud dělá člověk vývojáře po třicítce, tak s ním není něco v pořádku. Údajně to naznačuje, že je neúspěšný, protože se nedokázal posunout na vyšší pozici. Dokonce mám kolegu, který s oblibou říká Dal jsem si závazek, že ve třiceti nebudu programátorem. Můj názor je ten, že člověk by měl zastávat takovou pozici, která ho naplňuje a pak je úplně jedno kolik mu je let.

Dokonce bych řekl, že většina programátorů zraje jako dobré víno. To neznamená sice, že platí starší vždy lepší, ale zkušenost dělá hodně. Jedna z námitek na vrub starších programátorů je ta, že nedokáží být dostatečně inovativní. To je další nesmysl, protože místo věku hraje roli charakter vývojáře. Narážky na věk a úspěšnost bych zakončil paralelou ze sportu. Hokejovému brankáři Dominiku Haškovi je 42 let a přesto patří mezi absolutní špičku kanadsko-americké NHL a nikdo se neopovažuje zpochybnit jeho schopnosti.

Architekt by neměl kódovat

Kódovat či nekódovat? Architekt by údajně neměl kódovat a měl by si držet odstup a starat se pouze o architekturu aplikace. Každý architekt, který přestane absolutně kódovat podle mého názoru ztrácí smysl pro reálné použití daných technologií a většina jeho odhadů a rozhodnutí je tímto negativně ovlivněna. Jestli je něco pohroma pro každý projekt, pak je to architekt teoretik.

Pokud mám být jako architekt za systém či jeho část být zodpovědný tak musím nejen znát jeho architekturu, ale musím být schopen obhájit i praktické řešení, za které nesu odpovědnost. Někdo zastává názor, že architekti by měli dělat code review a tím si držet kontakt s realitou. Dle mého názoru se pro code review lépe hodí nástroje pro statickou analýzu kódu.

Architekt by se měl podílet nejen například na návrhu API, ale i na jeho implementaci a na tom, že celé API drží linii, která byla navržena. Architekt, který něco navrhne a tím to pro něj končí a nebo dokonce není schopen prosadit/obhájit to co navrhnul, je špatný architekt.

Nepředvídejme budoucnost, protože nakonec bude úplně jiná

To jsem slyšel ve spojení s návrhem API. Nedávno jsme zde diskutovali objekt, pro který jsme vytvořili rozhraní kopírující jeho public metody. Já tento vzor používám často a rád pro API, která používá klient z jiné vrstvy aplikace. Troufám si tvrdit, že pokud tvoříme API tak vždy předvídáme budoucnost a proto je více než užitečné nezabouchnout si dveře tím, že budu někoho nutit používat konkrétní třídu.

V tomto smyslu je předvídání budoucnosti zbytečné u věcí, které mají jednorázové použití a nebo které lze velice jednoduše refaktorovat. Jenže kolikrát se z jednorázových řešení stanou řešení nejednorázová? Řekl bych,že přirozenou evolucí skoro u většiny. Potom je ve větších projektech tento refaktor holým neštěstím. Ano budoucnost může být jiná, ale většinou není tak diametrálně odlišná, abychom ji nemohli alespoň částečně predikovat a tím si v budoucnu ušetřit plno práce.

středa 11. července 2007

J2EE 6 - krok správným směrem

JSR 316 přesně to je číslo specifikace pro Javu EE 6, která otočí kormidlem dějin dopředu a ani krok zpět. A nebo tak nějak podobně by mohla znít trochu překroucená parafráze jedné hlášky z filmového zpracování románu Miloslava Švandrlíka Černí baroni.

S velkou chutí jsem si přečetl článek Java EE 6 Gets it Right od Roda Johnsona, ve kterém pochvaluje plány této specifikace. Jsem docela rád, že právě Rod Johnson a Interface 21, společnost stojící za Spring frameworkem, budou konečně stát za touto veledůležitou specifikací.

Kromě toho vkládám naděje ještě do Gavina Kinga, který tam bude kibicovat JBoss a připojí reálnou zkušenost s použitím J2EE technologií ve frameworku Seam. Gavin King už se dokonce vytasil s neskromným seznamem přání či změn, které by rád do specifikace protlačil, případně prodiskutoval.

Než se pustím do samotné specky, tak bych rád odcitoval jedno vylepšení EJB, které navrhuje Gavin King a o kterém vždy říkám, že mělo být již součástí EJB 3.0. A také to každému IoC teoretikovi s radostí omlátím o hlavu.

Optional business interface

The fifth item on my wishlist is a pure ease-of-use concern. Currently, EJB mandates that all session beans have some @Local or @Remote interface. This was not an unreasonable requirement when session beans were understood to exist in a business tier, with a well-defined API sitting between the business logic and the client. But now that we're using session beans everywhere - even for presentation logic - it's clear that defining the local interface for every bean is simply a PITA. Unfortunately, we realised this much too late in the process of writing the spec to do anything about it in EJB 3.0 (I've kicked myself many times over this, I should have known better). Especially in an environment like Seam, where the only client of a bean might be a JSF page with EL expressions, the interface looks totally redundant!

The interface should be optional, and when it is missing, the public methods of the bean class should be taken as the business methods of the session bean.

Enterprise verze 6 je zaměřen na tři oblasti.

  • rozšiřitelnost
  • profily
  • deratizace

Rozšiřitelnost

Rozšiřitelnost bere monopol technologiím poskytovaným aplikačním serverem a nahrazuje jej možností integrovat technologie podle potřeb aplikace. Aplikační server nabídne extension pointy, na kterých půjde integrovat technologie použitá aplikací se službami serveru. To znamená, že nebude například problém použít Hibernate či Spring v těsné integraci se službami aplikačního serveru. To co se muselo po různu obcházet, by mělo být transparentní.

Profily

Profily definuji nutnou množinu technologií pro danou oblast, například Web profile může definovvat JPA, Servlety a JSF. To znamená, že aplikační server může být kompatibilní se specifikací na nižším levelu (profilu). Většina aplikací totiž využívá pouze část technologií a tak je zbytečné, aby čekaly na certifikaci celého serveru, která trvá měsíce. Díky profilům se tak specifikace dostane mnohem rychleji do produkce.

Deratizace

Konečně zvítězil zdravý rozum a technologie poplatné době "pravěku" budou odstraněny, tak aby zbytečně nenafukovaly J2EE rodinu. Místo nich zůstanou jejich nástupci. Specifikace již nyní zmiňuje CMT entity beany nahrazený JPA a JAX-RPC nahrazené JAX-WS.

Počítá se s integrací následujících novinek.

Zároveň se bude sahat do stávajících specifikací.

EE 6 opravdu podle prvního nástřelu vypadá tak, že je řízena tím jak vypadá současný model vývoje aplikací a né tím jak si expertní skupina JCP myslí, že by měl vypadat. Rozšiřitelnost a profily nabízejí něco podobného, co představila Java platforma v podobě skriptovacích jazyků. Už není jenom JVM a jeden jazyk, ale JVM, která slouží jako podvozek pro další jazyky. Je na vývojáři, jaký jazyk si vybere a stejné to bude v případě technologií, které se budou moci integrovat s aplikačním serverem.

Vypadá to, že i dodavatelé aplikačních serverů si uvědomili, že je pro ně výhodnější cesta integrace než destrukce a varování před technologiemi nepocházejícími originálně z J2EE specifikace. Vývojář dostane svobodu v tom jakou technologii použije a snadná integrace se službami aplikačního serveru bude stimulovat poptávku po aplikačních serverech. Přesně podle pořekadla Vlk se nažral a koza zůstala celá.

Očekávám, že lidé jako Gavin King a Rod Johnson přinesou další zjednodušení J2EE technologií, tak aby k jejich použití nebylo potřeba nastudovat hory tutoriálů, stohy teorie a ještě tunu návrhových vzorů. Na konci roku 2008 uvidíme co se jim podařilo splnit a kde si ukousnuli příliš velký krajíc.

úterý 10. července 2007

OT: pointa dne

Manažeři a inženýři

Cestuje skupina inženýrů se skupinou manažerů ve vlaku. Každý manažer má zakoupen svůj lístek, inženýři však mají dohromady lístek jen jeden. Najednou jeden z inženýrů zavolá: "Jde průvodčí!" a všichni inženýři se natlačí na WC. Průvodčí zkontroluje lístky všem manžerům a vidí, že dveře na WC jsou zamčené. Zabouchá na ně: "Jízdenku prosím!". Z WC se zpod dveří vysune jeden lístek, průvodčí ho cvakne, prostrčí nazpátek, poděkuje a spokojen odchází.

Na zpáteční cestě mají manažeři jen jeden lístek a, světe div se, inženýři nemají žádný. Náhle jeden z manažerů volá: "Jde průvodčí!" a všichni manažeři se utíkají schovat na WC. Inženýři o něco pomaleji odcházejí na druhé WC. Poslední z inženýrů, než se schová, zabuší na dveře u manažerů a zakřičí: "Jízdenku prosím!"...

Pointa: Manažeři často používají inženýrská řešení, aniž by jim přitom rozuměli...

pondělí 9. července 2007

Eclipse a drobné maličkosti: generování toString

Eclipse delší dobu nabízí možnost vygenerovat metody pro hashCode a equals z instančních proměnných třídy. Pokud jste si možnost generování těchto metod oblíbili, tak vám zřejmě chybí generování třetí metody do party a to toString. Naštěstí existuje plugin JUtils ToString Generator, který tuto funkčnost přidává.

JUtils ToString Generator umí generovat toString pro jednu třídu a také hromadně pro více tříd ze všech instančních proměnných třídy. Šablonu pro generování lze customizovat podle potřeb, např. na skládání výsledného řetězce je možné zvolit StringBuilder, StringBuffer a nebo klasické sčítání.

Konfigurace JUtils ToString Generatoru