Test Driven Development – Outside-in, Daniel Kolman

Jak jsem psal v minulém příspěvku, za necelý týden 14. prosince v Ostravě v pobočce Vendavo CZ pořádáme Code Retreat a přihlásit se můžete zde: http://srazy.info/coderetreat/4107

Doporučuju shlédnout video Java User Group v Ostravě z roku 2012 od Dana Kolmana na téma Test Driven Development – Outside-in, ve kterém též mluví o Code Retreatu:

//player.vimeo.com/video/51208668

Test Driven Development – Outside-in, Daniel Kolman – Java User Group – Ostrava on Vimeo.

Tak na viděnou v Ostravě!!!

Reklamy

Code Retreat ve Vendavo CZ v Ostravě

Protože ve Vendavo CZ máme programování rádi a rádi se v něm také dále zdokonalujeme, rozhodli jsme se připojit se k celosvětové akci Global Day of Coderetreat a uspořádat 14. prosince Code Retreat v prostorách Vendavo CZ (Novinářská 7, 70900).

Akce je pro programátorskou veřejnost, přihlásit se můžete zde: http://srazy.info/coderetreat/4107 

Občerstvení i prostory sponzoruje Vendavo CZ.

Více o Code Retreatu si můžete přečíst např. na českém webu CodeRetreat.cz, cituji:

Coderetreat je jednodenní intenzivní cvičení zaměřené na základy vývoje softwaru. Díky tomu, že vývojáři nejsou pod tlakem rychlého doručování výsledků, poskytuje Coderetreat možnost cíleně se soustředit na zlepšování svých dovedností. Procvičováním základních principů modulárního a objektově-orientovaného návrhu mohou účastníci zlepšit své schopnosti psát kód, který minimalizuje náročnost implementace dalších změn.

Během několika iterací během dne pracují dvoučlenné týmy na problému Game of Life.

Doporučuji si také přečíst blog post Dana Kolmana z naší hradecké Vendavo CZ pobočky Jak se připravit na Code Retreat. Dan celou akci také povede.

Další dobrý zroje je introduction video přímo od zdroje tedy Corey Hainese:

//player.vimeo.com/video/18955165
Cleveland Code Retreat Introduction from Corey Haines on Vimeo.

Takže na viděnou v Ostravě!

O Oraclu, Ruby on Rails a NetBeans

V posledních dnech čtu hodně tweetů (např. zde) smutných z toho, že Oracle ukončil podporu Ruby on Rails v NetBeans. Neviděl bych to tak černě.
 
Vidím v tom následující pozitiva:

  • Oracle se chová racionálně – tedy obchodně. Na rozdíl od Sunu, který, leccos vymyslel a vyvinul, ale nikdy z toho nevytřískal kapitál, který mohl. Aspoň mě to tak přišlo. Po akvizici Sun Microsystems má nadbytek IDE, Java aplikačních serverů má taky dost. Nikde nevidím, proč by zrovna RoR by mu mělo hrát do karet a měl ho podporovat. Oracle je java-shop, ne ruby-shop. A nemusí podporovat každý dynamický jazyk na trhu. Může nadále podporovat a preferovat některý jiný jazyk na JVM: JavaScript, JPython, Groovy…cokoliv.
  • Jsem rád za JetBrains. JetBrains je firma, která je mi sympatická a obdivuju je, jak dokáží ustát situaci, kdy kvalitní IDE se rozdávají zdarma. Po letech kdy NetBeans a Eclipse dotáhli starou dobrou Intellij Idea, musí JetBrains makat a inovovat na 200%, aby se dále držel na trhu. Tudíž mě ihned napadlo, že to co udělal Oracle je dobrá věc a zbyde víc koláče na JetBrains. To se potvrdilo – viz RubyMine welcomes all NetBeans users. Reduced price for everyone!
  • NetBeans je přece open source projekt, tak proč vzdychat. RoR komunita je velká, RoR podpora v NetBeans je, takže proč jí dále nerozvíjet s pomocí komunity (až na to, že RoR lidi se budou muset „snížit“ k použití toho špatně čítelného prastarého jazyka Java…)
  • Oracle není hloupý a RoR komunita taky ne. Hype NoSQL  databází přichází často od agilníků z RoR komunity. A pokud váš business jso SQL databáze, nejste zrovna nadšen 😉

Tak pěknou sobotu…

How to monitor connection pool in SAP NetWeaver Java AS

Another interesting day today. And another experience with SAP NetWeaver Java application server. Our application (Vendavo of course) suffered with intermittent database connection problems in one of the customer environments. Like in many other cases, also in this case Vendavo is deployed to SAP NetWeaver Java stack.

In the application log files we found next exception stack trace from SAP NetWeaver:

Caused by: com.sap.engine.services.dbpool.exceptions.BaseSQLException: ResourceException in method ConnectionFactoryImpl.getConnection(): com.sap.engine.services.connector.exceptions.BaseResourceException: Cannot get connection for 60 seconds. Possible reasons: 1) Connections are cached within SystemThread(can be any server service or any code invoked within SystemThread in the SAP J2EE Engine), 2) The pool size of adapter „productionPool“ is not enough according to the current load of the system or 3) The specified time to wait for connection is not enough according to the pool size and current load of the system. In case 1) the solution is to check for cached connections using the Connector Service list-conns command, in case 2) to increase the size of the pool and in case 3) to increase the time to wait for connection property. In case of application thread, there is an automatic mechanism which detects unclosed connections and unfinished transactions. at com.sap.engine.services.dbpool.cci.ConnectionFactoryImpl.getConnection(ConnectionFactoryImpl.java:59) at com.vendavo.core.omi.JDBCHelper.getConnection(JDBCHelper.java:267) … 36 more

More details about this exception can be found at help.sap.com.
After we verified that Oracle parameters PROCESSES and SESSIONS are set to sufficient values we came to conclusion that problem is in NetWeaver database connection pool, where the limits are hit. And that the most probable cause of the problem is connection leak. Somewhere database connections are not properly closed.
I found that SAP NetWeaver Java App server contains very nice connection pool monitor in its Visual Administrator. Real-time chart displays number of used / free connections in the pool.
We found that after a particular business action is invoked, limit of connections in the pool is hit almost immediately. Next figure shows that pool does not have any more free connections. All 100 connections are used.

We were able to find the code where the connection was not closed properly pretty quickly and the fix was easy. Next picture shows the same bussiness operation after we applied the fix:

I really appreciate the idea having the real-time connection pool monitor in Visual Administrator.
Btw. if you ever wondered where the connection pool is configured (maximum connections, initial connections etc.), it’s in the Additional tab of the given data source in the Visual Administrator:
Visual Administrator / Server / Services / JDBC Connector / Resources / Data Source

Local SMTP server for testing of email notifications

Testing of the email notifications – i.e. tests that business application is sending appropriate emails to right people is pretty boring but important part of the development of business applications. Developers are tend to underestimate this part of functionality.
Btw. although this piece of work is usually very simple, there’s very often a funny story linked to it. I can tell you several funny stories how hundreds of real users accross the globe were spammed from development environment with purchase orders, invitation to auctions or requirements for approval. This happened at least once in every company I worked for 😉
The best idea is to setup local SMTP server and use it instead of corporate one. And of course be careful to not allow the test emails to be sent to real users.

Recently my colleague @nemecpav showed me this ultra-simple application called Antix SMTP Server for Developers. This application is so simple, that I was even not able to find a way to configure for example a port where SMTP is listening. But at the end, why do would I need to change it?

And this application does the job perfectly. Zero configuration, just run it. And its free.

It’s running in a try, listening on SMTP port and behaves like a folder where all outgoing emails are placed. It’s a folder, so you can switch views in an explorer-like manner.

You can open the outgoing emails in the email client to verify the content, headers etc.

And finally – you do not need to worry that your test email will reach the real users 🙂

Web Services Standards Poster

Pokud vás zajímají webové služby (web services), SOA a podobná témata, rozhodně doporučuji pěkný poster s přehledem existujících Web Service standardů (stav 2007):

WS-Standards Poster 2007-02.pdf

který vytvořila a dala k dispozici německá firma innoQ.

Pro zajímavost. Před pár měsíci jsem procházel nové WS standardy a projekty a pro přehledné vyjádření vzájemných souvislostí jsem použil kontextové mapy vytvořené pomocí CMapTools (více zde).

Contextual map Web Services - Metro and Tango
Příklad: kontextová mapa pro projekty Metro a Tango

Eclipse – nefunkční "hot code replace"

Alternativní nadpis tohoto příspěvku by mohl znít „Jak použít Eclipse (java) compiler“ mimo IDE. Tímto jsem asi dost napověděl, o čem budou následující řádky pojednávat.

Remote Debugging

Vzdálené debugování (remote debugging) je užitečný nástroj pro ladění „vzdálených“ aplikací – „vzdálených“ v tom smyslu, že se pomocí svého debuggeru připojujete do jiné běžící Java Virtual Machine nejspíše s úmyslem ladění dané aplikace 😉 Nebudu nosit dříví do lesa: Více si o tomto tématu přečtete například v článku Debugging v praxi – opravdu samozřejmost?! od otce Fura či Eclipse a drobné maličkosti – vzdálené debugování od Dagiho.

Hot Swap

S remote debuggingem souvisí další funkcionalita, která z mé vlastní zkušenosti dokáže ušetřit obrovské množství času. Tato funkcionalita se jmenuje hot swap. Hot swap umožňuje „vpašovat“ do běžící aplikace novou verzi přeloženého kódu a nahradit jí tak kód původní.

Pro lepší představu, proč považuji hot swap za maximálně efektivní pomůcku, uvedu jeden příklad z mé praxe. Pracoval jsem na Ariba projektu, kde restart modulu Ariba aplikace (to jest jedné instance Weblogicu) na které jsem pracoval, trval na laptopu přibližně 9-10 minut (díky tomu, že se inicializovaly různé adaptéry, Tibco repositories, kontrolovala se XML metadata,…).

Součástí typického úkolu na tomto projektu byl vývoj nějakého vysoce sofistikovaného 😉 java kódu, který používá pokud možno public API aplikace a na konci dosáhne kýženého výsledku, za aplausu business consultantů 🙂 V uvedené konfiguraci, kdy jedním restartem ztratíte tolik času, si musíte dávat sakra dobrý pozor na jakékoliv triviální chyby (na netriviální chyby si často pozor dát ani nemůžete, například z toho důvodu, že API není zrovna dobře zdokumentované a až stacktrace při testování vás upozorní na možný problém) 😉

Zde se pomalu dostávám k jádru věci. Hot swap vám v těchto případech velice dobře poslouží: triviální problém – zapomněli jste test na null? Chcete přidat debugovací řádku…? S hrůzou zjistíte že nerovnost v podmínce je přesně obráceně? Bez remote debuggingu (aneb tak jak jsem to viděl kupodivu u velkého množství kolegů konzultantů) musíte shodit server, opravit, překompilovat, zrestartovat a dvacet minut je pryč. Následnovně zjistíte, že o pár řádků dále je problém podobný a tak pořád dokola.

Ti rozumnější (případně ti pracující v módu fixed fee a ne time&material 😀 ) využijí hot swap: kód v IDE jednoduše opravíte, upravíte, přeložíte, a pokud jste debuggerem připojeni do JVM v které běží aplikace, hot swap nahraje novou verzi byte-kódu do JVM a nahradí jí kód původní. V těchto jednoduchých případech vám hot swap nezanedbatelně šetří čas. (Samozřejmě zde existuje mnoho omezení, která když porušíte, debugger zobrazí varování, že daná změna není podporována (změny v hierarchii tříd ale i například přidání public metody atd.) a restartu se stejně nevyhnete).

Hot Swap v Eclipse

Zatímco v Intellij Idee hot swap fungoval bez problémů a intuitivně, po přechodu na Eclipse mi hot code replace (jak se tato feature v eclipsu nazývá) v mnoha případech nefungoval. Po rekompilaci třídy se mi místo očekávaného nahrání nového byte-kódu na server zobrazovalo často následující varování:

Hot code replace failed

Trochu jsem pátral co je příčinou a dopátral jsem se. Na obranu debuggingu v Eclipsu můžu uvést, že je v tom (částečně nevinně).

Scheme change not implemented

Zásadní problém je ten, že Eclipse pro kompilaci nepoužívá sunovský javac, nýbrž svůj kompilátor (součást JDT Core component). Vyprodukovaný byte kód se liší (nezkoumal jsem do detailů jak…) od byte kódu class přeložených javac kompilátorem. Tyto rozdíly jsou pro debugger ale podstatné tak, že neumožní záměnu byte kódu za běhu. Podobný problém viz např. na news.eclipse.tools.jdt: Scheme change not implemented.

(Nutno podotknout, že důvod proč se mi na serveru objevuje kód kompilovaný jiným kompilátorem (javac než z IDE (eclipse compiler), je fakt, že instalace a deployment této aplikaci je poměrně komplikovaný proces a je pro něj přepdřipravena sada nástrojů (Ant skriptů), které je nutné ve správném pořadí použít v závislosti na prováděné změně).

Řešení

Řešení problému spočívá v použití stejného kompilátoru v obou případech.

První možnost je donutit Eclipse kompilovat pomocí javac. To jde podle mě jednoduše pouze pomocí nového ANT builderu a custom Ant scriptu. Což není zrovna elegantní.

Druhá varianta je donutit existující produkt, který obsahuje vlastní „Ant“ build systém, kompilovat pomocí Eclipse kompilátoru.

To jde celkem jednoduše:

  1. stáhnout ecj.jar (JDT Core Batch Compiler)z eclipse.org
  2. donutit Ant použít tento compiler: tzn. nastavit hodnotu Ant property build.compiler na org.eclipse.jdt.core.JDTCompilerAdapter
  3. a nakonec samozřejmě přidat ecj.jar do classpath (tip pro lenochy: nahrát tento jar do adresáře ant/lib)

Tímto donutíme Ant kompilovat pomocí Eclipse kompilátoru a hot swap neboli hot code replace funguje tak jak má. Malá poznámka na konec. Rozhodně bych nedoporučoval měnit použitý compiler na produkčním server, o čem tu pojednávám, je prostředí vývojáře! Více kompilování v Eclipse o možnostech použití vně Eclipse IDE se lze dočíst v online nápovědě: JDT Plug-in Developer Guide > Compiling Java code.

TunnelliJ a Idea plugin API

Nedávno jsem navštívil zajímavou přednášku pořádanou českou Java User Group s názvem Jak psát API, které přežije nástrahy času prezentovanou architektem Netbeans Jardou Tulachem. V rámci přednášky proběhla diskuse o (ne)kompatibilitě IDE pluginů s postupem času (jakožto současný uživatel Eclipsu vím moc dobře, o čem je řeč).

Napadlo mě tedy, že se mrknu jaká je situace v Idee, zda ještě pořád funguje plugin Tunnellij (TCP tunnel integrovaný do IDE), který jsem napsal před pár lety pro verzi Idea 3.5 (jakožto pomůcku pro sniffování SOAP zpráv). Mrknul jsem na stránky Jetbrains a zjistil jsem, že udělali v této oblasti velký kus práce. Nové a pěkně udělané stránky plugin repository, relativně velké množství pluginů (vzhledem k tomu že Idea je komerční IDE).

Takže jsem vzal poslední build Idea verze 7 a zkusil jsem, zda můj Tunnellij (popis) plugin bude i nadále fungovat. Funguje bez problému, takže plugin API v Idee se zda být celkem stabilní, minimálně pro featury které jsem použil. Lehce se změnil a rozšířil plugin XML descriptor, takže jsem doplnil chybějící údaje (vsuvka – na zmiňované přednášce se mi líbilo, že Jarda zdůraznil, že návrh API není jenom o Java kódu a public interfacech, ale týká se mnohem více věcí, od proměnných prostředí OS přes různé deskriptory, konfigurace atd…) a znova rebuildoval celou package a nahrál do plugin centra. Paradoxem je, že tento build Idea pluginu jsem již dělal z Eclipsu 😉

A co mě nakonec příjemně překvapilo je počet downloadů – přes 5700 downloadů je pěkné číslo 😉

JBuilder 2007 aneb veletoc Borlandu

Vrátím se ještě k nedávné podcast debatě na téma java vývojových prostředí. Zmiňovali jsme zde JBuilder – javovské IDE od firmy Borland – a pokus o jeho“zmrtvýchvstání“ v podobě nové verze postavené na platformě Eclipse. Zdá se, že nový JBuilder se již klube na svět. Jako již tradičně u Borlandu jsou o něco dříve připravene webové stránky a tiskové zprávy před samotným produktem. Ačkoliv na titulní stránce je JBuilder 2007 masivně inzerován, sami si ho zatím vyzkoušet nemůžete (v sekci Downloads ho totiž zatím nenajdete).

Proč bychom si ho ale měli chtít vyzkoušet? Sám nevím. JBuilder nebyl špatné IDE, ale v časech kolem verzí 6, 7, 8 (ano Borland chrlil major verze každý půlrok) podle mě zaspal dobu. Co nám může nabídnout za nemalé peníze dnes? Nejdříve se podívejme, co jsou to ty nemalé peníze. Licenční model zůstáva zachován, verze Enterprise, Professional a nejchudší Developer stojí 1.999 resp. 799 resp. 399 dolarů (cena za nové licence, ceny za upgrade jsou o něco nižší). Poplatky za podporu nejsou v této sumě zahrnuty a nemalé peníze se platí se zvlášť. Čtyřista babek za Developer verzi, určenou pro individuální a open-source uživatele mi přijde jako silná káva a nerozumím nikomu, kdo by do toho tyto peníze investoval. Podíváteli se na seznam funkcí, je tato verze silně okleštěná (či vykleštěná ;-)) a argument, že můžete IDE rozšířit o pluginy produkované eclipse komunitou zde jaksi nemá smysl.

Dalším důvodem proč podlě mě NEinvestovat do JBuilderu je evidentní nejistota co se týče směřování tohoto produktu a potažmo celé firmy. Investovali byste (sta)tisíce dolarů do software firmy, která v únoru tohoto roku oznamovala, že se zbaví své divize zabývající se vývojovými nástroji (JBuilder, Delphi, C++Builder, C#Builder,…) protože to, co je podle nich „hot“, je trh application life management (ALM) softwaru. Tento týden (o devět měsíců později) naopak Borland oznámil, že nejlepší bude divizi nástrojů si ponechat, ale vyčlenit jí jako samostatnou odnož se jménem CodeGear. Pěkný veletoč 😉 Tyto zvraty jsou pro Borland celkem typické, vzpomeňme několikaletou neúspěšnou přeměnu v Inprise a pozdější návrat k původnímu firemnímu jménu Borland.

Nyní se podívejme na technickou stránku věci. Co nového JBuilder 2007 přinese. Čerpám pouze z dostupné dokumentace, což je především web a pdfka: Data Sheet a Feature Matrix.

Již úvodní věta je celkem odvážná 🙂

The latest JBuilder is the first application server independent enterprise class IDE built on open source Eclipse.

Pokračujme dále:

It provides all the economic benefits of an open source platform, with the reliability of a trusted, turnkey solution provider.

S výše zmiňovanou cenovou politikou mi přijde poukazovat na ekonomické benefity open source platformy také celkem zcestné 😉

Krásné fráze.

Z inzerovaných featur:

  • postavený na platformě Eclipse 3.2
  • podpora JEE5,
  • podpora JSE5
  • oboustranné modelování v UML 2.0
  • Visual Web Services Designer
  • vizualizace usnadňující EJB development (Visual EJB Workbench)
  • integrovaný OptimizeIt 2007 (což může být celkem zajímavý argument)
  • ProjectAssist a
  • další čím dál víc enterprise-abstraktně-marketingové funkce.

Jak už jsem řekl jsem k osudu JBuilderu dost skeptický. Ani ne kvůli Eclipse a Netbeans, které jsou zdarma. Ani ne kvůli IntellJ Idee, která je o dost levnější a v některých věcech stále nepřekonaná, ale podle mě míří na trochu jiný segment trhu. Skutečná konkurence pro JBuilder jsou produkty jako IBM RAD nebo Oracle JDeveloper. Jenže ti to mají snazší. IBM i Oracle mají sílu s dalšími produkty a službami protlačit svá IDE k zákazníkovi. Borland tuto sílu už dávno nemá!