Gradle - druhý krůček

V prvním popisku použití gradlu jsem si ukázali jak na jednoduchý projekt, dneska se podíváme, jak jsme zbuildovali projekt do waru.

Vyjdeme z předcházejícího příkladu. Co musíme změnit, abychom měli jako výsledek projektu war, ve správném layoutu a ne jar? Je toho pekelně málo.

usePlugin "java"
usePlugin "maven"
usePlugin 'eclipse'
usePlugin 'war'

sourceCompatibility = 1.6
group = "cz.svt"
version = "${version}"

manifest.mainAttributes "Implementation-Title": name, ...

configurations {
   deployerJars  
}

dependencies {
   compile fileTree(dir: "lib", includes: [ "util.jar", "JMSMailer.jar"])

   compile "org.apache.activemq:activemq-core:5.2.0"
   ...
   
   providedCompile  "javax.servlet:servlet-api:2.4"
   
   runtime "datedFileAppender:datedFileAppender:1.0.2"
   
   deployerJars "org.apache.maven.wagon:wagon-http:1.0-beta-2"
}

repositories {
   ...
}

uploadArchives {
   ...
}

Tam kde jsou uvedeny 3 tečky jsem build zkrátil, buď protože obsah je totožný s buildem z minula a nebo výpis nepřináší nic zajímavého. Takže co se fakticky změnilo? Jeden řádek. Přidali jsme na úvod:

usePlugin 'war'

To je celé. Navíc jsme do struktury adresářů přidali adresáře src/main/webapp/META-INF a src/main/webapp/WEB-INF. Mě to přijde úžasně jednoduché a musím říct, že se mi gradle líbí víc a víc.

CZJUG - Hans Dockter - Gradle

Po velmi dlouhém čase jsem se dostal na CZJUG. Nelituju, spíš lituju, že mi to termínově nevychází se tam dostávat častěji. Přednáška o gradle byla hodně zajímavá. Druhou přednášku o MPS jsem nepochopil, jestli to bylo tím pivem nevím. Samozřejmě jsem rád, že jsem mohl potkat staré známé z java komunity.

Hans pojmul přednášku tak jak jsem to nečekal a bylo to hodně zajímavé. V podstatě na úvod nám ukázal jak je gradle inteligentní. Na příkladu přidání source directory do projektu nám ukázal jak na 4 řádcích je možné vyjádřit vše. Závislosti (interní, externí), vytvoření tasků na přeložení, závislostí mezi tasky. Pak přislo na pořad dne základní motivace a tím pádem trochu srovnání s ANTem a mavenem.

Dále se mluvilo o výhodách v podobě vyhodnocování tásků, které se spustí, o multiprojektech atd. Dále jsme se dozvěděli i něco o budoucnosti (především se na nás chystá spolehlivý build bez clean, tj. že gradle bude shopen zaručeně identifikovat co se změnilo a co je díky tomu nutno zbuildovat).

Nosná myšlenka, pro mě, je, že gradle se snaží být takovým vylepšeným mavenem, tj. používá intenzivně standardní layout projektu, standardní lifecycle buildu, ale navíc nabízí neuvěřitelnou flexibilitu, vše je možno změnit.

Pro mě je to cesta správným směrem, byť to vyžaduje kontrolu nad tím, jak je gradle používán, aby se nám build nevymkl z ruky. Navíc je gradle stále mladý a hodně se mění, takže použití v dnešní době není úplně bezproblémové. Ale je to systém hodně perspektivní.

Pokud někoho obsah přednášky zaujal, pak se vše nahrávalo, takže se můžete kouknout na video (odkaz na něj jistě bude na stránkách CZJUGu).

iBATIS 3 - nový bojovník přichází

Jsem dlouholetý uživatel Hibernate, které používáme na velkém projektu a musím se přiznat, že dnes nám spíš přináší komplikace (především u 50GB databáze už hodně záleží jaká SQL se volají a to nám Hibernate neumožňuje ovlivnit). iBATIS to umí i ve verzi 2. Co se mi líbilo na návrhu připravované verze 3 jsem již psal. Ale my tu již máme první betu trojky. (Než se pustím do svých postřehů, rád bych zmínil seriál otce Fura, který je vyčerpávajícím popisem novinek v porovnání s dřívější verzí iBATISu.)

Krom věcí zmíněných již v předcházejícím článku existují další, které mě hodně potěšili:

• vytváření TypeHandlerů je o poznání jednodušší než podobných UserTypů v Hibernate
• objekty natažené z DB nejsou vytvářené pomocí bezparametrického konstruktoru, ale pomocí ObjectFactory, takže máte způsob vytvoření objektu plně v ruce (objekty půjde vytvářet pomocí DI frameworku - Spring, Guice) - to je obrovská bolest Hibernate, která se řešila pomocí AOP
• vytváření dynamických SQL

Jsem moc rád že komunita za iBATISem stojící sebrala odvahu a vrhla se do designu nového frameworku, i když je to za cenu menší zpětné kompatibility. Moc se jim nový iBATIS povedl a řada věcí řeší bolesti, na které musí každý kdo používá Hibernate narazit.

Spolu s iBATISem byl uvolněn i další produkt a to iBATIS Schema Migration System, který umožnuje automatizovat migraci DB schéma z jedné verze tam i zpět (pokud si SQL skript na zpětnou migraci napíšete). Inspirace jistě pochází z Ruby on Rails Migrations. Bohužel Migrations jak je představil team iBATISu mají jeden zásadní problém: migrační scripty se píší přímo v SQL. Takže jen velmi těžko budeme vytvářet skript, který bude fungovat s různými databázemi nebo s různými konfiguracemi téže databáze.

Gradle - první krůčky

O novém build nástroji gradle jsem již psal. Je to už rok a co se za tu dobu stalo? Gradle nám vyrostl z verze 0.2 na verzi 0.7, která je už velmi rozumně použitelná. A proto jsme se rozhodli gradle použít pro náš první projekt.

Jedná se o velmi jednoduchý projekt (matcher pro easymock). Tento projekt obsahuje 3 třídy, které je potřeba zkompilovat. Neobsahuje testy. Výsledný jar je nutno deploynout do firemní artifactory.

A jak takovéto jednuché věci dosáhnout:

usePlugin "java"
usePlugin "maven"

sourceCompatibility = 1.6
group = "cz.svt"
version = "${version}"

manifest.mainAttributes "Implementation-Title": name, "Implementation-Version": version, "Implementation-Vendor": "ČSAD SVT Praha s.r.o." 

configurations {
   deployerJars
}

dependencies {
   compile "commons-beanutils:commons-beanutils:1.7.0" 
   compile "org.easymock:easymock:2.2"
   compile "org.easymock:easymockclassextension:2.2.1"
   
   deployerJars "org.apache.maven.wagon:wagon-http:1.0-beta-2"
}

repositories {
   mavenRepo urls: "${artifactoryURL}/repo1"
}

uploadArchives {
   repositories.mavenDeployer {
      name = 'httpDeployer'
      configuration = configurations.deployerJars
      repository(url: "${artifactoryURL}/libs-releases-local") {
         authentication userName: "${artifactoryUid}", password: "${artifactoryPwd}"
      }
      snapshotRepository(url: "${artifactoryURL}/libs-snapshots-local") {
         authentication userName: "${artifactoryUid}", password: "${artifactoryPwd}"
      }
   }
}

Maven uživatel může jenom závidět, jak je tento script kompaktní a krátký. Nyní si postupně projdeme co musíme ve scriptu udělat, aby vše fungovalo.

Nejprve definujeme, které pluginy budeme používat. java plugin potřebujeme pro překlad Javy a maven pro deployment do artifactory (jedná se o maven repository).

Další 3 řádky definují, že používáme Javu 1.6, skupina deployovaného artefaktu je "cz.svt" a na verzi se odvoláváme jako na property (o těch si povíme dále). Následuje řádek s definicí manifestu (hojně používáme property dříve nastavené).

Další 3 řádky definují novou konfiguraci deployerJars, kterou použijeme v tasku na deployment jaru do naší sdílené firemní artifactory.

A začínáme tím zajímavým, závislostmi. Stačí nám na ně 7 řádků. Závislosti se definují podobně jako v mavenu, ale skupiona, název, verze se oddělují dvojtečkou. Jinak gradle umí díky ivy pracovat nejen s ivy, ale i maven repository. Poslední závislost říká, že deployování bude potřebovat wagon-http.

Následně defunujeme repository pro resolvování závislostí (opět pomocí property). Poslední je task uploadArchives, který je nejsložitější z celého scriptu. Složitost ovšem spočívá v definování rozdílné repository pro snapshoty a pro finální verze (v podstatě dvakrát to samé). Protože deployment do artifactory nemůže provést každý, je nutné specifikovat už. jméno a heslo (není přímo ve scriptu, ale je to properta).

Jak gradle resolvuje property? Gradle hledá v aktuálním adresáři soubor gradle.properties a dále se kouká do adresáře $HOME/.gradle/ po stejnojmenném souboru. V těchto souborech můžeme definovat property, jenž můžeme využít v buildu. Takže v projektu uvádíme verzi a v domovském adresáři definujeme adresu repository a už. jméno a heslo.

A jaké budou další krůčky? Nejprve přidáme testy, pak generování standardních reportů (javadocs, findbugs, cobertura) a nakonec groovy, aspectj atd...

Super myšlenka učení programovat na škole - programovat open source projekt

Když jsme byli na jOpenSpace 2009 tak jsme v hloučku zainteresovaných vedli diskusi na téma: "Co by měla vysoká škola dělat, aby naučila své studenty programovat?". V této diskusi byl hodně aktivní Petr Adámek, který jako učitel na Masarykově univerzitě, měl k tématu hodně co říci.

Já jsem šel do diskuse s nosnou myšlenkou, že škola musí více do svého programu zatáhnout komerční sféru (u nás ve firmě pracuje řada studujících), aby se studenti dostali do kontaktu s realitou. Pracovali na skutečných projektech, se skutečným zadáním, spolupracovali s již protřelými programátory atd.

Petr se mnou de facto souhlasil, ale tvrdil, že to je nemožné zrealizovat, že zájem firem není.

Dneska jsem poslouchal Java Posse #263 - Interview with Cay Horstmann (profesor na universitě), kde zazněla ona geniální myšlenka. Jak pracovat na reálném projektu, když firmy nemají zájem. No přeci pracovat na open source projektu. Cay Horstmann řekl, že mají na universitě předmět, jehož náplní je pracovat na již existujícím open source projektu (existujícím - dle výběru studenta). Student se naučí psát kvalitní kód, spolupracovat s kolegy, číst cizí kód, inteligentně se ptát atd.

Řekl bych, že tato myšlenka rozsekla onen pomyslný gordický uzel, který vznikl v diskusi mezi mnou a Petrem.

Byl jsem na Scrum Master Training

A stal jsem se certifikovaným Scrum Masterem.

O tom, ale nechci psát, chci psát o tom jak moc bylo toto školení prospěšné a co vše mi přineslo. Školení vedl Boris Gloger, který se ukázal jako perfektní přednášející. Přednášenou oblast dokonale zná, nejenom z již uskutečněných školení, ale i z praxe. Navíc jeho skušenosti se zaváděním Scrumu byly hodně veliké, takže na jakoukoliv otázku byl velmi promptně připraven odpovědět a vždy si věděl rady. Opravdu perfektní školitel.

Školení bylo dvoudenní a konalo se na jihu Čech. Provedlo nás postupně všemi částmi Scrumu, které se Scrum Mastera týkají, o všem jsme si příjemně popovídali a řadu věcí jsme si díky šikovně vybraným cvičením i vyzkoušeli.

Co si ze školení odnáším? Především jde o to, že Scrum Master ze mě zatím nebude, protože vývoj softwaru mám moc rád a hodně těžko bych se bez něj obcházel. A Boris striktně nedoporučuje, aby Scrum Master byl zároveň vývojářem, protože Scrum Master má za úkol podporovat a chránit team před okolními vlivy a to by zároveň jako vývojář nemohl dělat na 100%.

Dále jsem si odnesl velmi důležitou část Scrumu a to: čím více jsou lidé z teamu zatáhnuti do možnosti určovat si práci, rozhodovat o ní jak ji udělají a kolik ji udělají (kolik stihnou udělat za následující sprint), pak se o to více snaží, aby to co slíbili také zvládli. Pokud to rozhodne někdo za ně, pak nebojují za svou čest, ale za čest někoho jiného a to se bojuje podstatně laxněji.

To jsou hlavní poznání, které mi školení přineslo. Pak jsem si ještě odnesl pár drobností: neohodnocovat požadavky (Story) pomocí člověkodnů, ale pomocí bodů (díky tomu, že se určí kolik bodů je schopen team zvládnout za jeden sprint, ví se kolik udělá požadavků), skvělá je metodika ohodnocování složitosti požadavků (opět to dělá team pomocí Planning Pokeru), team v jeden okamžik vždy pracuje na jednom požadavku (aby byl software co nejméně rozvrtaný a aby si vzájemně pomohl, protože chce mít požadavek co nejdříve hotový) atd.

Vřele všem podobné školení doporučuji, i když nehodláte být Scrum Master, ani nehodláte vyvíjet software podle Scrumu. Proč? Protože chytrých nápadů je ve Scrumu spousta a spousta se jich dá použít.

Tapestry 5. 1 je mezi námi

A je to ... verze 5.1.0.5 prošla hlasováním a stala se finální verzí Tapestry 5.1. Co je nového? Především na straně výkonu aplikace bylo podniknuto hodně kroků: zrychleni vykreslení složitých stránek, sloučení více statických JavaScriptových knihoven do jedné, gzipová komprese statického i dynamického obsahu atd. (blíže viz. release notes).