jirablog

Team vyhrává když táhne za jeden provaz

2011-03-30T16:35:00.000+02:00

Po svém posledním příspěvku o scrumu jsem měl v hlavě, že napíšu ještě jeden příspěvek, abych se vyjádřil jasně, proč považuji scrum za to nejlepší v metodikách vývoje. Je to právě jeho orientace na team a ne na jednotlivce. Na samoorganizující team (tj. organizace není určena z venku).

Ale pak jsem si poslech czpodcast č. 39 - Operations a Devops (hostem byl Radim Marek z Gooddata) a ten mé myšlenky posunul trochu jiným směrem. Omlouvám se, že podcasty poslouchám v opačném pořadí než vznikaly a navíc hodně zpětně, že si většina již nepamatuje co se v nich řešilo.

Nejprve se pochválím. Praktikujeme cosi podobného jako Devops a myslím, že se nám to osvědčilo. Vždy, když píšu v aplikaci logovací string, tak přemýšlím k čemu jej použiju a co chci, aby v něm bylo za informace. Kontakt se zákazníkem mi pomáhá přemýšlet o našem produktu v kontextu zákazníka nikoliv v mém.

Co mě ale vybudilo napsat tento článeček. Opět zaznělo něco co mi přijde logické. Tj. splynutí developerů a QA. A kritika byla, proč by měl drahý developer dělat testování, když tester je levnější. Argumentace Radima Marka byla do jisté míry správná, developer, který umí napsat automatický test a zárověn udělat performace testování je jistě lepší než ten co to neumí.

Ale proč nad tím přemýšlet na úrovni jednotlivých vývojářů a ne na urovni teamu (jediný důvod, kterému rozumím je ohodnocení členů teamu - výplata se dává jednotlivcům - ale koneckonců proč ji nedat teamu a nechat na něm její rozdělení mezi jeho členy - třeba by to fungovalo). Vývojář sám nic neudělá, team zvládne víc. Je důležité mít schopný team, který je složen tak, aby zvládl analýzu, návrh, vývoj i testování (v celé jeho šíři). Proč je to lepší? Team je na jedné lodi a táhne za jeden provaz. Nepřehazuje si horkou bramboru.

Pokud jeden člen neví jak dál s úkolem, který řeší, zeptá se kolegy, který to již dělal, nebo je zkušenější. Nikomu to nevadí, protože aktivita je stále vynaložena na úkol, který řeší celý team. Tj. je to aktivita pro dobro všech. Navíc se lidé vzájemně vzdělávají a roste jejich kvalita. Pokud ovšem sleduji, úkoluji jednotlivé vývojáře, dříve nebo později (čas je dán okamžikem, kdy se toto sledování využije k represivním krokům) přestane být pro jednotlivce zajímavé spolupracovat, protože neřeší to co mají, ale dělají něco co nemají (pomáhají kolegovi).

Pro mě je to celkem stejné jako rozdělení firmy na oddělení. Funguje to dokud jsou všichni na jedné lodi. Jakmile jsou oddělení dostatečně velká, že si zavedou samostatná účetnictví a "přefakturovávají" si vzájemnou práci, pak je spolupráce ta tam.

Závěrem. Scrum nabízí pohled na vývoj SW skrze team. Samoorganizující team, který je silně kooperující. To je prostředí, kde vznikají rychle dobré věci. V konkurenčním prostředí se rozvoj zpomaluje, protože se všichni ohlíží na konkurenci. Na vývoj SW už dávno nestačí jeden člověk je jich potřeba víc. Takže chceme, aby spolupracovali a ne si konkurovali.

PS. Teda to je pěkná všehochuť, snad z toho někdo něco pochopí ...

Neoprávněná kritika Scrumu v czpodcastu č.46: Kanban agilní vývoj

2011-03-21T20:41:00.000+01:00

Poslouchám nyní zpětně czpodcast a při poslechu 46. dílu s názven "Kanban agilní vývoj" zazněla, dle mého soudu, neoprávněná kritika na adresu scrumu.

Na úvod je nutné si otevřeně říci, že scrum není pro každého. Splnit podmínky pro vývoj pomocí scrumu není úplně triviální, ale pokud se to povede ovoce přinese. Druhá, velmi důležitá věc, je najít kvalitní zdroj, odkud vědomosti čerpat. Existuje spousta knih o scrumu, které jsou zavádějící a nebo špatné. V ideálním případě je vhodný konzultant, který nám poradí, jak scrum správně implementovat v našem konkrétním prostředí. Já žádného dobrého českého konzultanta neznám (rozuměj nemám jej prověřeného), ale účastnil jsem se školení na ScrumMastera s Borisem Glogerem, který mě jednoznačně přesvědčil, že tím schopným konzultantem. Svému řemeslu i scrumu perfektně rozumí.

A nyní již k obsahu podcastu. Prvním jasným signálem, proč scrum nemůže v GoodData fungovat je oddělení QA od vývoje. Scrum si vynucuje existenci tzv. universálních týmů. Tj. z týmu co sprint vypadne funkční plně otestovaný produkt doplněný o nové položky z backlogu. Pokud máme oddělené QA od vývoje, pak z týmu vypadne cosi, ale není to funkční produkt. Kde je probém? Myslím, že si Jaroslav odpověděl sám. Není známa velocita teamu. Team sice doplní produkt o položky (featury) v obtížnosti např. 100, ale v další iteraci je opravuje a spadne mu velocita na 60. Proto musí být universální teamy, aby to co je jejich výsledkem bylo funkční a plně otestované a vědělo se přesně jakou mají velocitu (ta se po několika prvních iteracích ustálí). Velocita pak pomáhá předpovídat, kolik team udělá položek backlogu za definovaný čas.

Dalším problém, který byl zmíněn je vynucování si, aby univerzální teamy nebyly moc veliké, řádově deset členů (i méně). Pokud máme vývojářů víc, pak je rozdělíme do více teamů a je samozřejmě možné udělat, aby pracovali "skoro" nad jedním backlogem.

V podcastu zaznělo, cosi o zarovnávání položek do sprintu a výběr menších položek z backlogu "mimo" prioritu. První jsem slyšel prvně až v podcastu a druhé je naprosto špatně! Team si na začátku sprintu z backlogu vybírá, striktně podle pořadí v jakém jsou uvedeny, položky, které bude realizovat. Chybou je mít položky tak velké, že např. zvolím první, druhou už zvolit nemohu, protože bych ji nestihl, ale první mě zaměstná pouze na 2/3 sprintu. Nikde ovšem není řečeno, že pokud má team velocitu 30, pak si musí vybrat položky v úhrnné složitosti 30, může si zvolit stejně dobře 27, jako 31.

V neposlední řadě zaznělo, že se jim v GoodData položky špatně odhadují, protože dělají nové věci a u nich člověk nikdy neví. Může to být do jisté míry pravda, ale co je na scrumu kouzelné je to, že u položek v backlogu se neodhaduje jejich pracnost, ale pouze jejich složitost a to ještě poměrově mezi sebou. Používá se k tomu technika planning poker, kdy jednotlivý členové ohodnocují položky složitostí pomocí kartiček s hodnotami 1, 2, 3, 5, 8, 13, 20, 40, 100. Na této technice je úžasné, že porovnat dvě věci mezi sebou a říci, která je složitejší a jak moc nám jde velmi dobře a jsme až překvapivě hodně přesní (na rozdíl v odhadování kolik to zabere času).

Z mého pohledu je závěr spíš, že scrum v GoodData neměli vůbec používat a navíc jej používali špatně a proto jim nefungoval. Tedy jednoznačně není chyba na jeho straně. Osobně se domnívám, že scrum je nejlepší metodika, kterou máme v současnosti k dispozici, ale bohužel, není pro každého.

Inovace bez legrace aneb máme se snažit vymýšlet něco nového a nebo jenom přebírat dané

2011-03-01T14:45:00.003+01:00

Dneska se snad poprvé pustím do polemického příspěvku, který na první pohled je o vývoji softwaru ryze okrajově, ale mám takový pocit, že musím ...

Jaká je motivace pro tento příspěvek. Nejprve jsem si přečetl Lukášův Jak nepsat framework, který ve mě zanechal jistou pachuť, ale nevyprovokoval mě k ničemu, ještě jsem nevěděl ...

Pak se mi dostaly do ruky hodnocení prezentací pořádaných na MFF od studentů, kteří je shlédli. A to mě nakoplo, protože jedno hodnocení mé přednášky bylo:

Co se tématu týče, tak na mě to působilo dojmem, že pan Mareš přistupuje k Softwarovému inženýrství dost osobitým způsobem. Přišlo mi, že přednášejícímu je upřímně jedno, jak to či ono realizují v kvalitních společnostech typu NASA, DoD a podobně. Dokonce mi přišlo, že jeho postoj je, že on sám je opravdu chytrý a že to co vymysleli pánové stavějící rakety dvacet let před ním, nestojí za to řešit. Tedy že to všechno on sám už vymyslel a prověřil praxí.

Bezpochyby toto hodnocení ukazuje, že nejsem výborný prezentátor, spíše podprůměrný, protože pokud má přednáška na někom zanechala tento dojem, pak jsem to nezvládl. Naopak myslím, že podporuji iterativní způsob vývoje SW, který se osvědčil právě v NASA a v DoD (Department of Defence) již před více než 30 lety a favorizují iterativní způsoby vývoje na úkor vodopádu (konkrétně favorizuji Scrum).

Ale o tom také nechci psát. Co mají tedy tyto příspěvky společného? Otázku: Máme vymýšlet (vyvíjet) něco vlastního nebo jenom přebírat již existující?

Já si myslím, že není problém vymýšlet něco nového, zkoušet zda to funguje, to je naprosto v pořádku a znamená to MOŽNÝ pokrok. Takže není chyba, pokud někdo napíše vlastní framework nebo vymyslí vlastní způsob práce, to je naprosto v pořádku. Otázkou je, zda je tak geniální, že vymyslí něco prospěšného i pro ostatní a nebo zda to je nějaký nesmysl, který funguje pouze pro jeho zvrácený případ.

Chybná je jiná věc. Chybné je neumět si přiznat, že jsem udělal chybu a držet se dál toho nesmyslu co jsem vymyslel ... a v ideálním případě komplikovat život mnoha dalším lidem. Není špatně vyvinout vlastní framework, pokud se mi podaří někoho přesvědčit, že to je dobrý krok a dostanu na to peníze (nebo to udělám ve svém volném čase). Špatné je, pokud od začátku tvrdím, že se to povede a bude to úspěch a pokud nakonec, když se to nepovede, tak to nepřiznám.

Težko bychom, pokud by se nenašli dostateční "šílenci", dneska měli Hibernate, Spring, Groovy, Tapestry atd. Ovšem kolik je těch projektů, které se nezrealizují a nebo neprosadí? Podstatně více, to je nutno si přiznat. Ale vždyť sama evoluce se řídí přístupem "pokus vs. omyl", úspěšné přežije na úkor neúspěšného, takže proč ne my.

Takže nebojme se vymýšlet nové věci, ale buďme soudní a silní si přiznat, že se nám to nepovedlo. V ideálním případě je veledůležité zpublikovat svůj neúspěch stejně jako (možná víc než) úspěch, aby se i ostatní mohli poučit z naší chyby ...

Jak na porovnávání Comparable objektů či pomocí Comparatoru

2010-05-19T16:53:00.004+02:00

Nemít přetěžování operátorů skutečně považuji za velký problém Javy. Proč? Např. proto, že porovnávání objektů pomocí instance třídy Comparator či porovnání objektů implementující rozhraní Comparable je boj, který pernamentně prohrávám. Mějme např. dva datumy d1 a d2. Pokud chci zjistit, zda platí d1 <= d2, pak mám následující možnosti:

!d1.after(d2)
d1.compareTo(d2) <= 0

Přiznám se, že z těchto dvou variant mi přijde čitelnější ta první (druhou mi mozek nějak nebere a vždy mě stojí hrozně přemýšlení co to znamená). Ovšem metody before a after má pouze třída java.util.Date nikoliv obecná třída implementující rozhraní Comparable. Pokud budeme objekty porovnávat pomocí instance Comparator pak musíme vystačit s metodou compare.

Z tohoto důvodu jsem si udělal jednoduchý enum:


public enum Relation {
   eq, ne, lt, le, gt, ge;

   public static <C extends Comparable<? super C>> boolean rel(C c1, Relation oper, C c2) {
      switch (oper) {
         case eq:
            return c1.compareTo(c2) == 0;
         case ne:
            return c1.compareTo(c2) != 0;
         case lt:
            return c1.compareTo(c2) < 0;
         case le:
            return c1.compareTo(c2) <= 0;
         case gt:
            return c1.compareTo(c2) > 0;
         case ge:
            return c1.compareTo(c2) >= 0;
      }
      throw new IllegalArgumentException("Unsupported operation " + oper);
   }

   public static <C> boolean rel(Comparator<C> comp, C c1, Relation oper, C c2) {
      switch (oper) {
         case eq:
            return comp.compare(c1, c2) == 0;
         case ne:
            return comp.compare(c1, c2) != 0;
         case lt:
            return comp.compare(c1, c2) < 0;
         case le:
            return comp.compare(c1, c2) <= 0;
         case gt:
            return comp.compare(c1, c2) > 0;
         case ge:
            return comp.compare(c1, c2) >= 0;
      }
      throw new IllegalArgumentException("Unsupported operation " + oper);
   }
}

Díky použití tohoto enumu mohu přepsat výše uvedený příklad porovnávání dvou datumů do podoby:

rel(d1, le, d2)

(pokud použijeme statické importy na metodu rel a instanci enumu le). Protože se mi tento zápis ještě stále nezdál dostatečně výmluvný, použil jsem další vylepšení (stačí jej přidat do výše uvedeného enumu):


   protected static final Map<String, Relation> S2R;

   static {
      Map<String, Relation> tmp = new TreeMap<String, Relation>();
      tmp.put("==", eq);
      tmp.put("!=", ne);
      tmp.put("<=", le);
      tmp.put("<", lt);
      tmp.put(">=", ge);
      tmp.put(">", gt);
      S2R = unmodifiableMap(tmp);
   }

   public static <C extends Comparable<? super C>> boolean rel(C c1, String oper, C c2) {
      return rel(c1, S2R.get(oper), c2);
   }

   public static <C> boolean rel(Comparator<C> comp, C c1, String oper, C c2) {
      return rel(comp, c1, S2R.get(oper), c2);
   }

Nyní dostaneme již poměrně elegantní zápis:

rel(d1, "<=", d2)

Je škoda, že Java nemá přetěžování operátorů, které nás vede k takovýmto vylepšením. Např. Groovy si umí poradit a operace porovnání umí zavolat nad objekty implementující Comparable. Scala je na tom podobně díky možnosti přetížení operátorů.

Lekce ze Scaly: Jak se vyvarovat NullPointerException

2010-01-05T21:31:00.002+01:00

Jak se v jazyce Scala brání NullPointerException? V hojné míře se používá třída Option, která zajistí, že nemusí metoda vracet null, ale vrací existující instanci. Jak to celé funguje si ukážeme v Javě:

public abstract class Option<T> {
  public abstract T get();
  public abstract boolean isNone();
  public abstract boolean isSome();
}

Pokud potřebujeme aby nějaká metoda vracela něco a nebo null, použijeme třídu Option. Díky ní metoda vrátí existující instanci, ze které jednoduše zjistíme, zda návratová hodnota má být null (isNone() vrací true) a nebo je to nějaká smyslu plná hodnota (isSome() vrací true) a pak se k této hodnotě dostaneme pomocí metody get().

Teď už to chce jenom nějaký rozumný příklad. Vezněme si např. Map a její metodu get:


V get(T key);

Ta v případě, že klíč v mapě neexistuje vrací null. Takže typicky píšeme něco jako:


String value = map.get(key);
if (value != null) {
  System.out.println(value);
} else {
  System.out.println("Nic");
}

A jak by tedy měla metoda get objektu Map vypadat kdybychom byli ve Scale:


Option<V> get(T key);

A nyní jak by vypadal náš kód pro čtení z mapy:


Option<String> value = map.get(key);
if (value.isSome()) {
  System.out.println(value.get());
} else {
  System.out.println("Nic");
}

A zbavili jsme se ošklivého porovnání na null, což jsme chtěli. Navíc pokud metoda vrací Option a ne přímo hodnotu je podstatně větší pravděpodobnost, že nezapomeneme otestovat zda Option něco obsahuje. Pokud metoda vrací přímo hodnotu nebo null, pak hrozí, že hodnotu rovnu použijeme a neotestujeme ji na null.

A nyní přistupme k implementaci:


public class None<T> extends Option<T> {

  public T get() {
    throw new UnsupportedOperationException("The None had no value");
  }

  public boolean isNone() {
    return true;
  }

  public boolean isSome() {
    return false;
  }

  public boolean equals(Object obj) {
    return ((obj == this) || (obj instanceof None));
  }

 public int hashCode() {
   return 1;
  }

}

public class Some<T> extends Option<T> {
  protected T value;
 
  public Some(T value) {
    super();
    this.value = value;
  }

  public T get() {
    return value;
  }

  public boolean isNone() {
    return false;
  }

  public boolean isSome() {
    return true;
  }

  public boolean equals(Object obj) {
    if (obj == this) return true;
    if (obj instanceof Some) {
      Some other = (Some) obj;
      return value.equals(other.value);
    }
    return false;
  }

  public int hashCode() {
    return value.hashCode();
  }
 
}

A jak to celé funguje ve Scale? Díky pattern matchingu a type inference ještě elegantněji:


val value = map.get(key) 
value match {
  case None => print "Nic"
  case Some(x) => print x
}

Gradle - druhý krůček

2009-10-01T08:23:00.003+02:00

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

2009-10-01T08:03:00.003+02:00

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í

2009-08-16T15:25:00.004+02:00

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

2009-08-11T09:12:00.003+02:00

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

2009-07-16T20:04:00.004+02:00

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

2009-06-25T16:26:00.003+02:00

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

2009-05-07T07:42:00.003+02:00

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).

Google App Engine & Java + Groovy

2009-04-08T08:07:00.002+02:00

Skvělé partnerství!

Od mé účasti na Google Developer Day 2008 jsem si říkal, že se musím na Python podívat, abych mohl Google App Engine vyzkoušet a ejhle, už nemusím. Google App Engine podporuje Javu a Groovy!

Jak jednoduše v groovy implementovat rozhraní s jednou metodou?

2009-03-03T17:34:00.002+01:00

Vše je až trapně jednoduché (např. FilenameFilter):


{ dir, name -> name.endsWith(".txt") } as FilenameFilter

Miluju jednoduché věci.

Tapestry 5.1 - co se na nás chystá?

2009-02-23T21:34:00.003+01:00

Pro ty co nečtou Howardův blog, přináším odkaz na zajímavý příspěvek týkající se novinek, které nás čekají v oblasti výkonu v chystané verzi 5.1.

Howard chystá zrychlení vykreslování stránek, především díky optimalizaci volání metod jednotlivých stavů komponent. Zrychlení se bude týkat i vytváření instancí komponent. V profileru Howard zjistil, že volání jistých metod se neustále při vytváření komponent opakuje, takže jejich vytváření bude rozděleno na dvě fáze: fáze analýzy a fáze vytváření. To pomůže stránkám s velkým množstvím komponent.

A co zrychlení na klientu. Context assets (soubory uložené v kontextu aplikace) budou moci být poskytovány pomocí URL, které bude obsahovat verzi a tudíž budou moci být agresivně cachovány (dlouhá doba expirace). Dále Tapestry bude podporovat kompresi posílanáho obsahu (snížení objemu přenášených dat), navíc se chystá cachování zakompreseného obsahu na servru, čímž se ulehčí procesoru od opakované komprese.

A to vše téměř bez porušení zpětné kompatibility. SUPER!

iPod Touch - nechám si ho, je super!

2009-02-23T20:52:00.003+01:00

Tak už i já, a to jsem tak dlouho "odolával". Ale vezmu celý příběh hezky popořadě.

Na konci ledna mě zase po letech přepadla myšlenka, že nahradím svům aktuální mobil nějakým tím chytrým modelem. Samozřejmě, že první volba padla na telefon s Androidem. Ale pak jsem zjistil, že jediným dostupným je model G1 od T-Mobilu. Už jsem byl skoro rozhodnut, když mi kolega povídá, že by to nedělal, že to není moc hardwareově povedený mobil a že by volil raději iPhone.

Tak jsem začal své myšlenku ubírat tímto směrem. Ovšem bál jsem se koupit si tak velký telefon, nechtěl bych takovou "plachtu" nosit všude s sebou. Takže jsem zvolil variantu zkouška. Zašel jsem na aukro a vydražil jsem nový iPod Touch.

Je to 14 dní co jsem majitelem a jaký je závěr. Začnu negativní stránkou věci. iTunes fungují pouze pod Mac Os X a Windows. A výhody? Skoro všechny audio podcasty co poslouchám, jsou na iTunes a stahují se mi přímo do iPodu automaticky (pánové z CZpodcastu, je ještě co zlepšovat). Ale co spatřuji jako opravdu skvělou věc je sledování videa. Funguje skvěle, displej je prostě super. Dále jsem se pomocí pluginu do Firefoxu naučil stahovat Flashová videa ze stránek (jako YouTube a InfoQ). Ty jsem pomocí softwaru na konvertování videa pro iPod zkonvertovat do MP4, které je přehratelné na iPodu. A už mám konečně čas se na tato videa podívat (dřív jsem neustále řešil, kdy se na ně kouknu - v práci i doma to byla škoda času), protože cestou v autobuse je to docela příjemná zábava. Druhou skvělou funkčností je prohlížení webu, které přes wifi funguje opravdu super. Především čtení novinek v Google Readeru je promakané na jedničku s hvězdičkou.

Takže můj závěr. Jednoznačně mohu doporučit, jenom velká škoda, že iTunes nejsou i pro Linux. Ale jak dopadne rozřešení mého problému s telefonem? Asi počkám na nějaký Androidí telefon, protože iPhone bych musel jailbrakenout, abych do něj dostal všechen software co bych chtěl, což u Androidu není potřeba. Dále si spíš napíšu aplikaci pro Android než pro iPhone (jako javista).

XSS, XSRF - o bezpečnosti je potřeba neustále mluvit a o webu to platí dvojnásob

2009-02-04T21:40:00.005+01:00

A já jsem si toto téma oživil pomocí prezentace Jeffa Williamse publikovanou na InfoQ: Stopping Attacks in a Web 2.0 World. Velmi povedená prezentace zaměřená na XSS a XSRF (nenechme se zmát názvem prezentace, příklady v ní uvedené se nijak nevážou pouze na Web 2.0 aplikace). Velmi podstatnou součástí prezentace jsou příklady použití těchto útoků. Čeho se dá dosáhnout pomocí XSS je až neuvěřitelné (přiznám se, že mi skoro běhal mráz po zádech).

XSRF je novější než XSS, obrana proti němu je relativně náročná (jedinou možností je posílání serverem generovaného tokenu s každým requestem na aplikaci). Zneužití je komplikovanější, protože se útočník nemůže dostat k response, kterou server poslal.

Co se XSS týče, jedná se o velmi starý druh útoku, který se neustále vyvíjí (přicházejí nové a nové nápady, jak útok zamaskovat, aby nebyl odhalen). Podíváme-li se na ha.ckers.org na příklady XSS útoků, pak u řady z nich nechápu, jak se dají použít. Např. útoky pomocí zakódování textu do Base64 vypadají opravdu nevinně. Nebezpečnost XSS je opravdu velmi vysoká. Obrana je opět relativně prostá, validace jakéhokoliv textu, který do aplikace přichází pomocí whitelistu (tj. pomocí povolených znaků). Nejedná se jenom o data z formulářů, ale i o hidden fieldy, cookies i hlavičky HTTP protokolu.

Kdo se chce dozvědět více, především ohledně popisu útoků, pak nechť použije již zmíněný ha.ckers.org, který je velmi vyčerpávající (z hlediska příkladů utoků). Druhým výborným zdrojem je owasp.org, který je (dle mého soudu) lépe přístupný z hledika podání informací jednoduchou a čitelnou formou. Popisy zde poskytují i návrhy ochrany, případně postupy pro review aplikace z pohledu odolnosti oproti útokům.

Porovnání jQuery a Prototype (odkaz)

2009-01-29T10:02:00.002+01:00

Právě jsem si přečetl velmi zajímavé porovnání dvou populárních JavaScriptových knihoven Prototype a jQuery od Glenna Vanderburga pod názvem Why I still prefer Prototype to jQuery.

Text je psaný velmi seriózně, žádné pocity, subjektivní dojmy, ale holá fakta, proto je, dle mého soudu, hodně cenný a zajímavý.

Co se mě a JavaScriptu týče používám jQuery, ale je pravda, že převážně na manipulaci s DOMem, což je jeho silná stránka oproti Prototype. A navíc jsem měl kliku, že jsem nepotřeboval zatím nic, co se v jQuery jeví jako problematické. Každopádně se budu muset na Prototype podívat blížeji.

Hezké počteníčko

Moduly pro Tapestry 5

2009-01-21T20:51:00.002+01:00

Poslouchat Java Posse se vyplácí. Dozvěděl jsem se o projektu Chenille Kit, který nabízí poměrně velké množství komponent a služeb, které jsou založené na Tapestry IoC, tj. služby jsou použitelné i mimo Tapestry.

K dispozici jsou následující moduly:

Access - pro řízení přístupu ke stránkám aplikace

Google - přístup ke službácm Google (např. geocoding)

Hibernate - zjednodušení práce s Hibernate

Hivemind - zpřístupnění komponent z Hivemindu

Image - jednoduché změny velikosti obrázku

LDAP - služba na provádění dotazů do LDAPu

Lucene - služba na indexování a vyhledávání pomocí Lucene

Mail - služba na posílání mailů založená na Commons Mail

Quartz - služba na plánování založená na Quartzu

Reports - služba pro generování reportů pomocí JasperReports

Scripting - služba na plánování založená na BSF

Tapestry - zajímavé komponenty pro Tapestry

Templating - templatovací služba založena na Velocity a FreeMakeru

Hodně zajímavá snůška. Ukazuje se, že Tapestry má velmi dobře udělaný design a zakomponovat do něj další služby je triviální. A množství služeb se bude jenom rozšiřovat, takže se můžeme těšit na zelené zítřky s Tapestry.

Jak selektivně podle třídy mazat objekty z Hibernate session

2009-01-21T12:32:00.007+01:00

Moje honba za LazyInitializationException byla úspěšná (musím se přiznat, že velkým pomocníkem mi byl Eclipse Memory Analyzer, který mi pomohl zjistit, kdo se na objekt odkazuje). Problém byl v tom, že jsem chtěl vymazat objekty ze Sessiony, ale protože jsem neznal jednotlivé instance, zavolal jsem metodu clear a znova zaasocioval to co jsem si myslel, že je důležité (a na něco jsem samozřejmě zapomněl).

V první fázi opravy chyby jsem tedy zaasocioval i další objekty a vše začalo fungovat. Pak mě ovšem postihla myšlenka, proč se mám já a můj kód, který by ideálně měl být na použitém ORM nezávislý, přizpůsobovat Hibernate. Tak jsem začal pátrat v javadoc, zda neexistuje nějaká možnost, jak zjistit jaké objekty jsou v Sessioně uložené. Pak by je stačilo selektivně odstranit pomocí metody evict.

Odpověď zní: existuje. Session má metodu getStatistics, která vrací SessionStatistics. Ten nám umožní zjistit jaké kolekce a jaké entity (včetně jejich identifikátoru) máme v sessioně uloženy. Takže stačí projít tyto údaje a v klidu vymazat co potřebujeme. Napsal jsem na to takovou drobnou třídu:
import java.util.ArrayList; import java.util.Arrays; import java.util.List; import java.util.SortedSet; import java.util.TreeMap; import java.util.TreeSet; import org.apache.commons.logging.Log; import org.apache.commons.logging.LogFactory; import org.hibernate.HibernateException; import org.hibernate.Session; import org.hibernate.engine.CollectionKey; import org.hibernate.engine.EntityKey; import org.hibernate.stat.SessionStatistics; import cz.svt.util.Tuple; import cz.svt.util.Tuple2; /** * This class is capable to print the summary of Hibernate cache content and also is able to evict objects from cache. */ public class HibernateCachceEvicter { /** The Hibernate session. */ protected Session session; protected static final Log log = LogFactory.getLog(HibernateCachceEvicter.class); /** * Creates the empty evicter. */ public HibernateCachceEvicter() { super(); } /** * Creates the evicter and sets the transaction. * @param session The session */ public HibernateCachceEvicter(Session session) { super(); setSession(session); } /** * Sets the Hibernate session. * @param session The session */ public HibernateCachceEvicter setSession(Session session) { this.session = session; return this; } /** * Prints the content of the Hibernate cache grouped by the collections role and entity name. * @return The cache content, first is entities and second collections */ public Tuple2<TreeMap<String, Counter>, TreeMap<String, Counter>> logCacheContent() { if ((session != null) && (log.isInfoEnabled())) { try { SessionStatistics statistics = session.getStatistics(); TreeMap<String, Counter> entities = new TreeMap<String, Counter>(); for (Object key : statistics.getEntityKeys()) getCounter(entities, ((EntityKey) key).getEntityName()).inc(); TreeMap<String, Counter> collections = new TreeMap<String, Counter>(); for (Object key : statistics.getCollectionKeys()) getCounter(collections, ((CollectionKey) key).getRole()).inc(); log.info("The hibernate cache contains " + statistics.getEntityCount() + " entities."); for (String key : entities.keySet()) log.info(" " + key + "=" + entities.get(key).getValue()); log.info("The hibernate cache contains " + statistics.getCollectionCount() + " collections."); for (String key : collections.keySet()) log.info(" " + key + "=" + collections.get(key).getValue()); return Tuple.newTuple(entities, collections); } catch (HibernateException e) { log.warn("Exception during walking through Hibernate cache to log its content", e); } } return Tuple.newTuple(null, null); } /** * Returns the counter from the map. If there is no such counter yet, creates new one and put it into map. * @param map The map * @param key The key * @return The counter */ protected Counter getCounter(TreeMap<String, Counter> map, String key) { Counter counter = map.get(key); if (counter == null) map.put(key, counter = new Counter()); return counter; } /** * Evicts the object of the specified classes from Hibernate cache. * @param classNames The array of the classNames to evict from cache */ public void evictFromCache(String... classNames) { evictFromCache(new TreeSet<String>(Arrays.asList(classNames))); } /** * Evicts the object of the specified classes from Hibernate cache. * @param classNames The sorted set of the classNames to evict from cache */ public void evictFromCache(SortedSet<String> classNames) { if (session == null) return; log.info("Cache before evicting:"); TreeMap<String, Counter> entities = logCacheContent().getV1(); try { int entitiesToEvictCount = 0; for (String key : entities.keySet()) if (classNames.contains(key)) entitiesToEvictCount += entities.get(key).getValue(); List<Object> entitiesToEvict = new ArrayList<Object>(entitiesToEvictCount); for (Object key : session.getStatistics().getEntityKeys()) { EntityKey eKey = (EntityKey) key; if (classNames.contains(eKey.getEntityName())) entitiesToEvict.add(session.load(eKey.getEntityName(), eKey.getIdentifier())); } for (Object entityToEvict : entitiesToEvict) session.evict(entityToEvict); log.warn("Evicted " + entitiesToEvictCount + "entities."); } catch (HibernateException e) { log.warn("Exception during evicting objects from cache", e); } log.info("Cache after evicting:"); logCacheContent(); } /** * This class is counter. */ protected static class Counter { /** The value of the counter. */ int value; /** * Creates the counter a resets the value. */ public Counter() { super(); value = 0; } /** * Increments the value of the counter. */ public void inc() { value++; } /** * Returns the value. * @return The actual counter value */ public int getValue() { return value; } } }

Zajímavé je metoda evictFromCache, která provádí mazání objektů ze sessiony. Nejprve si pomocí logCacheContent vypíšu obsah cache (seskupený podle tříd) před mazáním. Pak si zjistím kolik instancí budu mazat (podle výstupu z vypsání obsahu sessiony) a vytvořím patřičně veliké pole. Následuje procházení sessiony a pokud narazím na třídu, kterou chci vymazat, podle identifikátoru instance ji natáhnu metodou load a vložím do pole. Teprve poté je mažu (byl jsem línej, zkoušet, zda by se to nějak nepralo, kdybych zároveň procházel obsah sessiony a zároveň z ní mazal). Na závěr si jenom pro porovnání udělám výpis obsahu po mazání.

Protože nechci mít v kódu odkaz na takovou ošklivou Hibernatí záležitost, udělal jsem si jednoduchý aspect, který mi na požadovaná místa dotlačí vymazání instancí patřičných tříd.

Předpokládám, že to již někdo řešil, ale pokud to někomu pomůže, pak jen berte inspiraci.

PS. Třídu Counter jsem v příkladu nechal jenom pro úplnost.

Parametrizované testy v TestNG

2009-01-17T21:35:00.003+01:00

Jak už jsem psal dříve, jako testovací framework používáme TestNG. A protože jsem se konečně dostal ke knize Next Generation Java Testing: TestNG and Advanced Concepts od autora TestNG, Cédrica Beusta, mohu se s vámi podělit o novinky, které jsem načerpal (každopádně ta kniha stojí za přečtení, zabývá se totiž nejen unitovým testováním).

Jak jsem již naznačil v minulém textu, hlavní výhodou, kterou vidím, jsou data providery. Proč se tedy tento článek nejmenuje data providery v TestNG? Protože jsem se dozvěděl i o jiné možnosti parametrizace testů v TestNG. Jedná se o factories (český název továrny mi nepřijde tak jasný), které jsou podobné parametrům v jUnitu 4. Takže jak to funguje (příklad je lepší než 1000 slov, opráším příklad z minulého článku):


public class SquareTest {

  private Calculator calculator = new Calculator();
  private int param;
  private int result;

  @Factory
  public static Object[] create() {
    return new Object[] { new SquareTest(0, 0), 
      new SquareTest(1, 1), new SquareTest(2, 4), new SquareTest(4, 16) };
  }

  public SquareTest(int param, int result) {
    this.param = param;
    this.result = result;
  }

  @Test
  public void square() {
    calculator.square(param);
    assertEquals(result, calculator.getResult());
  }

}

Na první pohled je rozdíl oproti jUnit velmi malý (pomineme-li míň anotací a jejich jiná jména). Nevracíme paramtery, ale již vytvořené instance tříd. Jaká je v tom výhoda? Factory metoda může vracet instance jakýchkoliv tříd, nejenom té ve které je definovaná. Tyto třídy mohou obsahovat nejenom testovací metody (označené anotací @Test) a i factory metody. Je to o hodně flexibilnější.

A proč TestNG podporuje jak factory metody tak data providery, když de facto realizují totéž? Protože pokud parametry využijeme u většiny testovacích metod v třídě, je pohodlnější je předat pomocí konstruktoru z factory metody. Data providery se hodí, pokud potřebujeme více skupin dat pro různé testovací metody. A samozřejmě nic nám nebrání obě věci kombinovat.

Na závěr jsem si nechal dotažení konceptu data provideru k dokonalosti. Co když chceme zavolat testovací metodu hodně krát, opravdu hodně hodně moc krát. Pak asi není ideální vytvořit všechny parametry dopředu, vložit je do dvourozměrného pole a vrátit z data provideru, to zblajzne moc paměti. Jak tedy na to? Data provider bude místo Object[][] vracet Iterator, jehož metoda next() vrátí jednorozměrné pole s hodnotami parametrů.

Pokud jsem vás stále nepřesvědčil, že TestNG stojí za zkoušku, pak to jistě zkusím zase příště.

ORM mých snů - iBatis 3

2009-01-14T21:30:00.004+01:00

Všechny velké zajímavé projekty aplikací, na kterých jsem se podílel jako ORM používali Hibernate. Přiznám se, že jsem byl tímto frameworkem zpočátku nadšen. Pak moje nadšení trochu ochablo, ale verze 3 zase přinesla vylepšení, která jsem kvitoval (především z hlediska mapování).

Postupem času, ale čím dál tím víc cítím, že Hibernate (a v podstatě jakýkoliv JPA framework) není to pravé ořechové. Proč?

Nelíbí se mi, že je velmi těžké se z DataTypu dostat na connection, což je potřeba např. pro uložení XML do DB přes datový typ SQLXML, který je nutno vytvářet pomocí metody createSQLXML objectu Connection. O tom, že tuto instanci musím po provedení dotazu zase uvolnit pomocí její metody free ani nemluvě.

Dále se mi nelíbí, že nemám plně pod kontrolou SQL dotazy (jsou generovány z HQL), tj. případná optimalizace dotazů není úplně triviální. Samozřejmě je možné si vyžádat od Hibernate spojení a provést dotaz ručně, ale metoda connection objektu Session je deprecated, tak nevím jak to bude v Hibernate 4.

Šíleně mě začíná obtěžovat cache natažených objektů, Session. Pokud provádím nějaké batchové operace, které manipulují s velkým množstvím objektů (desetisíce), pak je problém jak to celé výkonově optimalizovat. Je nutné průběžně dělat commit, session vyclearovat a znova zaasociovat všechny objekty, které budu potřebovat. Nejen je to pracné, ale velmi často dohledávám původce nějaké LazyInitializationException.

Ale co jiného, co lepšího. Vždy jsem pokukoval po iBatisu. Zkoušel jsem jej, ale něco mi vždy řeklo, že to nějak s Hibernate zmáknu (přeci jenom ten framework znám a málo co mě při práci s ním překvapí). Ale návrh na verzi 3, který se mi dostal pod ruku mě nadchl. Proč?

Šíleně se mi zalíbila myšlenka definice rozhraní, které se zove Mapper, ale de facto je to DAO. Implementaci vytvoří iBatis sám. Např:

public interface EmployeeMapper {
  Employee getEmployee (int employeeId);
  List listAllEmployees();
}

Navíc se případné anotace, jak mapovat budou umísťovat do tohoto rozhraní a ne do modelu (jsem absolutním nepřítelem anotování modelu anotacemi pro DAO vrstvu).

Dále se mi zalíbila představa generování dynamických SQL dotazů pomocí DSL v Javě. Obávám se, že to není správný přístup. SQL by mělo být mimo aplikaci, takže v XML. Ale myšlenka je to jistě zajímavá.

Teď už nezbývá nic jiného než se těšit jak to celé dopadne.

Optimalizace výkonu databáze DB2 - db2top utility

2009-01-13T21:21:00.003+01:00

Jak optimalizovat výkon databáze? Těžko. Jak optimalizovat výkon databáze DB2? Také těžko. Nebo ne?

Tak těď už to neplatí, alespoň si to myslím. Ještě jsem nově objevenou utilitku db2top nezkoušel v případě nouze, ale podle popisu a prvního vyzkoušení je hodně mocná.

Dříve jsem k monitoringu databáze využíval pár utilit operačního systému (v Linuxu např. ps, iostat) a pak řadu nástrojů databáze (např. monitory, snapshoty). db2top integruje všechny tyto schopnosti do jednoho programu.

Utilitky umí pracovat nejenom v interaktivním režimu, ale i v režimu záznamu a následného vyhodnocení. Dokonce je možné hodnoty exportovat do csv a následně importovat např. do Excelu (já používám OpenOffice) a vytvářet grafy.

Koho jsem nalákal rozhodně doporučuji přečíst si DB2 problem determination using db2top utility.

Java 7 - máme se na co těšit

2009-01-12T20:49:00.005+01:00

Máme zde nový rok 2009 a první téma v novém roce nemůže patřit ničemu jinému než nově přicházející Javě - tj. Javě 7. Dostalo se ke mně pár zajímavých informací, které oblažily mé srdíčko.

Za prvé: Java Modularity mimo jiné nahradí classpath (také proto, že nepodporuje více verzí jedné knihovny). Konečně se zbavíme classpath: skutečnosti, které přinášela jenom starosti a žádné slasti. Každopádně, kdo kdy řešil nějaký problém spojený classpath, především na serveru je to lahůdka, pak jistě zaplesá.

Za druhé: closures se odkládají. Další moudré rozhodnutí (představení closures vyvolalo velké množství debat). Vzniklo více návrhů a není jasné, který je nejlepší. Proto oddálení uvedení této featurky je rozumné, uvidíme zda je budeme v budoucnu potřebovat (v Javě 7 budou změny podporující dynamické jazyky, jejichž existence možná tuto potřebu zašlape do země).

Věřím, že vás tyto informace potěší alespoň tak, jak potěšili mě. A když to tak náhodnou zase nedopadne, pak se nebojme, chleba kvůli tomu dražší nebude. Rozhodně vám přeji vše nej... do nového roku.

Překlad výjímek z databáze při použití Hibernate

2008-12-10T20:11:00.005+01:00

Kdo používá Hibernate, ten možná již tuší, kam budu dnešním příspěvkem mířit. Jde o to, že chyby, které detekuje Hibernate se snaží do výjimky dávat jméno třídy a atributu, který chybu vyvolal. Ovšem pokud vám chybu vyhodí databáze, pak vás Hibernate nechá ve štichu a předhodí vám výjimku datábáze a dělejte si s ní co chcete.

Toto chování se mi nikdy nelíbilo, protože mu moc nerozumím, Hibernate má vše co potřebuje. Zná dialekt, který by umožnil překlad databázově závislých výjimek, do obecné formy obsahující jméno tabulky a názvy sloupců. Následně je možné využít mapování a přeložit název tabulky a názvy sloupců na jméno třídy a atributů. Proč to Hibernate nedělá? Nevím ...

My jsme vždy chtěli mít vlastní DAO výjimky, které by byly nezávislé na použitém ORM. A zároveň jsme chtěli aby obsahovaly jméno třídy a atributů. Nikoliv tabulky a sloupce, protože tyto výjimky jsou většinou zpracovávány vrstvami aplikace, které o databázi nemají mít nejmenší tušení.

Řešení jsme měli, ale nelíbilo se nám, protože jsme de facto museli mapování zapisovat dvakrát (jednou z objektů do relací pro Hibernate a podruhé z relací do objektů). Dodnes nevím proč nejsou programátorsky přístupné mapovací soubory, nebo nevím jak je z Hibernate dostat, což jsme chtěli pro překlad sloupců na atributy použít. Občas jsme diskutovali co s tím, ale ne a ne přijít na ten správný nápad. Až takhle jednou jdeme z oběda a s kolegou Lubošem jsme si dali brain storming a triviální řešení jsme našli (nechápu jak to, že nás nenapadlo dřív).

Je až trapně triviální. Stačí si rozparsovat Hibernate mapovací soubory a vytvořit z nich mapování opačné, než jaké reprezentují. Tato akce představuje nesložitý algoritmus, jedinou složitostí je dědičnost, kde je nutno vytvořit vhodnou reprezentaci, aby se při zpětném překladu zvolilo správné jméno třídy (to nejkonkrétnější), v případě překladu více atributů umístěných různě hluboko v hierarchii tříd.

Druhým krokem je vytažení informace z SQLException, kterou vyhodí databáze. Zde je pár drobných oříšků, např. získání jmen sloupců v případě chyby unikátního klíče (námi použitá DB2 vrátí jméno unikátního klíče, které je nutno pomocí katalogu překlopit na jména sloupců).

Takže cca. po 3 dnech programování (nejprve jsem si dělal prototyp v groovy a pak jsem vytvořil kompletní implementaci v javě) máme řešení, se kterým jsme maximálně spokojeni. Stačí nám zapisovat Hibernate mapování a kód za nás udělá zbytek. My pak už pouze zachytáváme např. DARequiredException, která obsahuje jméno objektu a jeho atributu.

PS. Kód jsem neuváděl, protože není složitý, akorát ho je poměrně dost, takže by se velmi pravděpodobně jednoduchost sdělení hodně zkomplikovala.

Lze testovat aplikaci, která s tím nepočítá

2008-12-01T20:40:00.002+01:00

Motivací pro dnešní psaní je 28 czpodcast. Takže zpět k titulku, jde to, ale težko a to je ten problém. Ať už je to metoda, třída, modul nebo celá aplikace, vše musí být navrženo a naimplementováno s ohledem na testovatelnost.

A teď k jádru pudla. Testovatelnost UI je skoro to nejhorší. Ať je to UI webové, swingové a nebo nějaké jiné. Proč? Protože se mění. Většina změn aplikace se projeví v jeho uživatelském rozhraní. Proto se testy musí neustále měnit a modifikovat. Takže není ani tak problém v tom testy napsat, ale udržovat.

Dá se z této situace nějak vybruslit? Nedá, ale dá se řada věcí eliminovat. Tím co se eliminovat dá, je skutečnost, že se rozložení prvků v uživatelském rozhraní mění. Dojde-li k takové změně, pak špatně napsaný test prvek nenajde a nebo najde špatný prvek. Je nutno prvky UI identifikovat spíš než podle umístění (ať fyzického nebo logického) identifikovat podle nějakého logického jména. Tj. ve swingu musíme komponentám dávat jména a v HTML musíme tagům, které pro nás symbolizují komponenty, dávat speciální hodnoty atributům (id nebo class, ale i jiné), tak abychom je v kódu stránky dokázali jednoduše najít.

Pak i když s komponentami trochu hneme, tak nám to nevadí, protože podle tohoto logického názvu je vždy spolehlivě v okně nebo stránce najdeme.

Takže jako musíme komponentu napsat tak, abychom ji byli schopni otestovat, musíme i UI napsat, tak abychom jej otestovali. Rozhodně si tím ušetříme spoustu času a kolikrát si testování de facto umožníme.

JSF vs. Tapestry - tentokrát AJAX

2008-11-14T10:03:00.002+01:00

Zase trochu přileju olej do ohně, tentokrát se podíváme na jednoduchý AJAX příklad. Opět začneme na blogu Jima Driscolla, který napsal A simple Ajax JSF 2.0 example. Při pohledu na tento příklad se opět nemohu ubránit dojmu, že vývoj stránek je v JSF opravdu děs, no posuďte sami (pro jednoduchost ukazuji pouze to co je zajímavé a ne celou stránku):

<h:body>
    <h:form id="form1" prependId="false">
        <h:outputScript name="ajax.js" library="javax.faces" target="head"/>
        <h:outputText id="out1" value="#{count.count}"/>
        <br/>
        <!-- Increment the counter on the server, and the client -->
        <h:commandButton id="button1" value="Count"
                         onclick="javax.faces.Ajax.ajaxRequest(this, event, {execute: this.id, render: 'out1'}); return false;"/>
        <br/>
        <!-- Resets the counter -->
        <h:commandButton id="reset" value="reset"
                            onclick="javax.faces.Ajax.ajaxRequest(this, event, {execute:'reset', render: 'out1'}); return false;"
                            actionListener="#{count.reset}"/>
    </h:form>
</h:body>

A jak to samé uděláme v Tapestry nám ukáže Howard L. Ship na svém blogu v příspěvku Tapestry 5 Ajax Screencast. Šablona bude:

<body>
    <t:zone t:id="output">${index}</t:zone>
    <p>
        <t:actionlink t:id="increment" zone="output">increment</t:actionlink>
    </p>
    <p>
        <t:actionlink t:id="reset" zone="output">reset</t:actionlink>
    </p>
</body>

A nyní přistupme k Java kódu, ten je v JSF malinko jednodušší, protože definuje pouze beanu s hodnotou počítadla:

@ManagedBean(name = "count")
@SessionScoped
public class Count {
    Integer count = 0;

    public Integer getCount() {
        return count++;
    }

    public void reset(ActionEvent ae) {
        count = 0;
    }
}

A nyní ta "složitější" Java třída, tedy Tapestry verze:

public class Index {
    @Property
    @Persist
    private int index;

    @InjectComponent
    private Zone output;

    Object onActionFromIncrement() {
        index++;
        return output.getBody();
    }

    Object onActionFromReset() {
        index = 0;
        return output.getBody();
    }
}

Navíc zde máme definováno co se má měnit po provedení AJAX requestu, toť celá komplikace navrch.
Pro mě je to stále jasné, JSF je špatná volba proto, že je hrozně komplikované a těžko mě někdo bude přesvědčovat o opaku.
PS. Letěl okolo mě moc hezký článek o porovnání Wicket a JSF s názvem A Wicket user tries JSF. Ukázky, které jsou tam uvedeny na mě budí dojem, že Tapestry je kombinací toho dobrého z obou těchto světů: jednoduchou Java část z JSF a jednoduché šablony z Wicket.

Co to je čitelný kód aneb Literate Programming

2008-11-13T10:35:00.005+01:00

Obdivuji lidi co mají tu vlastnost, že dokáží naprosto přesně vyjádřit to co ostatní jenom tuší (řada ani to ne). Teď jsem zase narazil na jednoho takového člověka, kterým je Donald E. Knuth, jenž mě dostal svým spiskem o Literate Programming. Nosnou myšlenkou, která mne zaujala je:

Nesnažme se svým programem počítači sdělit co má dělat. Snažme se programem vysvětlit druhým programátorům, co chceme aby počítač dělal.

To je přeci ono. Nepíšeme program jenom proto, aby dělal co má dělat, ale také proto, aby ho dokázal někdo udržovat (to je ten člověk, kterému vysvětluje, co chceme aby počítač dělal).
Již dlouho jsem náš vývojový proces přizpůsoboval této myšlence, možná jsem ji měl někde zakopanou v podvědomí, ale nedokázal jsem ji tak krásně vyjádřit.

JSF vs. Tapestry - jak jednoduché je dělání komponent

2008-11-03T08:28:00.004+01:00

Opět jsem narazil na velmi zajímavý blog, který porovnává složitost vytváření komponent v JSF 2.0 a Tapestry 5 ("Simple" JSF 2.0 Component vs. Tapetry).
Samotného mě takové porovnání již dlouho zajímalo, protože jsem se o JSF přestal zajímat někdy okolo verze 1.0, přišlo mi zkrátka moc složité a komplikované. Navíc mělo veliké problémy na úrovni integrace s JSP (to už je snad minulost). Takže pokud se někdo nechce koukat na originál, pak vězte, že napsat komponentu v JSF, která vypíše text na žlutém pozadí je realizováno následující komponentou:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:h="http://java.sun.com/jsf/html"
      xmlns:f="http://java.sun.com/jsf/core"
      xmlns:ui="http://java.sun.com/jsf/facelets"
      xmlns:composite="http://java.sun.com/jsf/composite">
<head>
<title>This will not be present in rendered output</title>
</head>
<body>

<composite:interface name="yellowOut"
                     displayName="Very Basic Output Component"
                     preferred="true"
                     expert="false"
                     shortDescription="A basic example">
    <composite:attribute name="value" required="false"/>
</composite:interface>

<composite:implementation>
    <h:outputText value="#{compositeComponent.attrs.value}" style="background-color: yellow"/>
</composite:implementation>
</body>
</html>

Uf. To je skoro jako těžká dřina. V Tapestry stačí velmi krátká třída:

public class Out {
  @Property
  @Parameter(defaultPrefix = BindingConstants.LITERAL)
  private String value;
}

A ještě kratší šablona:

<span style="background-color: yellow">${value}</span>

Takže já mám zase jasněji v tom, co je lepší používat.

jOpenSpace 2008 - Java vs. dynamické jazyky - více návratových hodnot v Javě (aktualizováno)

2008-10-27T21:18:00.011+01:00

Opravil jsem špatně uvedenou ukázku Tuple3.

V záznamu z jOpenSpace na téma Java vs. dynamické jazyky jsem zaznamenal postesknutí: jediné co mi v Javě chybí je možnost, aby metoda měla více návratových hodnot. Ovšem je nutné si přiznat, že to je možné již nyní. Správný název pro objekt, který je de facto kolekcí s tou vlastností, že každý prvek je jiného typu.

Simulovat tuto funkcionalitu pomocí List<Object>, ale to není cesta správným směrem. Dále jsem našel knihovnu javatuple, ta se mi nelíbila, protože místo universálního slova tuple se třídy jmenují Tuple, Triple, ... Nakonec jsme si implementaci napsali sami, a nelitujeme.

Takže třída Tuple2 vypydá:

public class Tuple2<A, B> implements Serializable {
   protected A v1;
   protected B v2;

   private static final long serialVersionUID = -4987109478796050933L;

   public Tuple2(A v1, B v2) {
      super();
      setV1(v1);
      setV2(v2);
   }

   public A getV1() {
      return v1;
   }

   public void setV1(A v1) {
      this.v1 = v1;
   }

   public B getV2() {
      return v2;
   }

   public void setV2(B v2) {
      this.v2 = v2;
   }

   @Override
   public boolean equals(Object obj) {
      if (this == obj) return true;
      if ((obj == null) || !(obj instanceof Tuple2)) return false;
      Tuple2<?, ?> other = (Tuple2<?, ?>) obj;
      return ObjectUtils.equals(getV1(), other.getV1()) && ObjectUtils.equals(getV2(), other.getV2());
   }

   @Override
   public int hashCode() {
      int hashCode = 0;
      if (getV1() != null) hashCode += getV1().hashCode();
      hashCode *= 31;
      if (getV2() != null) hashCode += getV2().hashCode();
      return hashCode;
   }

}

Dále následuje Tuple3:


public class Tuple3<A, B, C> extends Tuple2<A, B> {
   protected C v3;

   private static final long serialVersionUID = -4987109478796050933L;

   public Tuple3(A v1, B v2, C v3) {
      super(v1, v2);
      setV3(v3);
   }

   public C getV3() {
      return v3;
   }

   public void setV3(C v3) {
      this.v3 = v3;
   }

   @Override
   public boolean equals(Object obj) {
      if (this == obj) return true;
      if ((obj == null) || !(obj instanceof Tuple3)) return false;
      Tuple3<?, ?, ?> other = (Tuple3<?, ?, ?>) obj;
      return super.equals(obj) && ObjectUtils.equals(getV3(), other.getV3());
   }

   @Override
   public int hashCode() {
      return super.hashCode() * 31 + ((getV3() == null) ? 0 : getV3().hashCode());
   }

}

Kód pro Tuple4 je již jednoduše vytvořitelný. Zbývá vytvořit implementace až kam potřebujete (my jsme se zastavili na čísle 7). Na závěr jsem vytvořil factory objekt, aby bylo vytváření pohodlnější:


public class Tuple {

   public static <A, B> Tuple2<A, B> newTuple(A a, B b) {
      return new Tuple2<A, B>(a, b);
   }

   public static <A, B, C> Tuple3<A, B, C> newTuple(A a, B b, C c) {
      return new Tuple3<A, B, C>(a, b, c);
   }

   ...

}

Když na tuto implementaci koukám, není mi jasné proč standardní knihovna neobsahuje něco podobného. I bez podpory přímo v jazyce je to řešení použitelné.

Google Developer Day 2008

2008-10-27T20:20:00.003+01:00

V pátek 24. října jsem se zúčastnil akce pořádané společností Google s názvem Google Developer Day v Hotelu Clarion ve Vysočanech. Protože mi to klasicky trvá déle než něco napíšu, pak vás mohu odkázat na Postřehy Martina Hassmana a Pavla Cvrčka, kteří byli rychlejší. Také jsem k celé akci přistupoval s despektem a vzhledem k naléhavosti úkolů z práce jsem se málem nezúčastnil. Ale nakonec musím říci, že mé pocity jsou podstatně pozitivnější než např. z poslední návštevy Sun Tech Days.

Úvodní key note se nesla v duchu toho, že pokud bude žít web bude žít i Google. A dále uvedla do kontextu všechna témata, kterých se celý den měl týkat, tj. Chrome, AppEngine, GWT, Apps (Search, Maps, Data API, ...), OpenSocial a Android. Pak již paralelně probíhaly jednotlivé přednášky ve 4 sálech, v pátem se konaly workshopy a v šestém byla relax zóna. Můj vkus byl malinko jiný než ostatních, tak alespoň přispěji k zacelení mezer v popisu přednášek.

Jako první jsem zvolil úvod do AppEnginu - Dive into Google App Engine (zvažoval jsem JavaScriptový engine V8, ale nakonec jsem se rozhodl pro AppEngine, který spíš využiju). Přednáška byla nakonec tím nejzajímavějším co jsem viděl. Vždy mě trápilo, když bych chtěl psát nějakou aplikaci pro web, kde ji pustím. AppEngine je odpovědí na tyto starosti. Programuje se v něm velmi jednoduše, Python není složitý jazyk, navíc se chystá další jazyk (pokličku se pozvednout nepodařilo, takže není jasné o jaký jazyk se jedná). Kdo píšete aplikace pro web, hledáte hosting a nechcete psát v PHP, mrkněte na něj.

Následovala přednáška o výkonu aplikací napsaných v GWT potažmo všech webových aplikací - Measure in millseconds: Performance tips for GWT (and AJAX in general). GWT nepoužívám takže jsem si jej trochu přiblížil (v podstatě ještě z doby programování v C++ mám odpor k jakémukoliv generovanému kódu a proto jde i nějak GWT mimo mě). Ovšem mile mě překvapilo, jak je to sofistikovaný systém. Co se dalších tipů týče, nic nového jsem se nedozvěděl, snažit se mít co nejméně CSS a JavaScript souborů, mít je co nejmenší a používat CSS Sprite, to jsou dnes již design pattern webového vývojáře.

Pak jsem si řekl, že to risknu a dozvím se něco o social networks. Zavítal jsem na přednášku Best practice for OpenSocial development. Pro mě nejslabší zážitek. Měl jsem pocit, že jsem buď moc starej a nebo z jiné planety, protože jsem nějak nechápal, kdo používá takové věci, zkrátka nejsem nějak in.

Zasklil jsem i Android (o tom se dá načíst ledacost) a zavítal jsem na jedinou českou přednášku Large-scale computing, Google-style: MapReduce, BigTable, Hadoop, HDFS and others přednášenou Peter Kukolem. Na MapReduce se moc nedostalo. Ale bylo to hodně zajímavé, protože se řešilo co to znamená computing v rozměrech Googlu, co vše se stává problémem při počítání v takovém měřítku.

Na závěr jsem shlédl Integrating 'Google' into your applications: Google Data APIs & AJAX APIs, týkající se popisu rozhraní k aplikacím Googlu. Zde jsem se dozvěděl o různých rozhraních ke Google Search (JavaScriptové či REST) či o Google Data API, které se používá pro přístup (čtení i zápis) k datům v kalendáři či Google Apps.

Zbaběle jsem utekl před večírkem a pelášil domů za rodinkou. Dojmy pozitivní, jsem moc rád že jsem se mohl zúčastnit, příště rád půjdu zas. PS. Moc se mi líbil přístup k lidem s notebookem, všude halda prodlužovaček a přístup na net, prostě super. Já dávám jedničku s hvězdičkou.

jOpenSpace 2008 - Spring - otevřenost novinkám

2008-10-27T09:22:00.001+01:00

Už jsem se bál, že zbytek záznamů z nultého ročníku jOpenSpace neexistují a hned jsem dostal odpověď v podobě dalších pěti záznamů. Šestým v pořadí je záznam od Dagiho Spring adoption in large enterprise project. Spring používáme a převážně jako IoC container, tak mě toto téma zajímalo. Bohužel kvalita zvuku je hodně špatná, takže jsem spíš neslyšel než slyšel.

Přesto jsem zaslechl jednu poznámku, která mě vybudila zamyslet se na téma: Kde se v lidech bere touha poznávat a používat nové vs. držet se v zajetých kolejích? Řadil bych se spíš k těm zvídavým, které nové věci zajímají a přemýšlejí o jejich aplikaci.

Je to dáno tím, že mě programování zajímá? Že to je i můj koníček. Nebo je to tím, že chci něčeho ve své profesi dosáhnout a proto se snažím? Nebo je to prostě tím, že věci většinou dělám pořádně a nesnažím se něco odfláknout, jenom proto abych už to měl za sebou? Asi je nutná kombinace všech zmíněných důvodů, aby programátor měl chuť se sebevzdělávat a tím byl otevřený novým věcem.

Vždyť všechny lidské činnosti podléhají zubu času, stále se hledají lepší a dokonalejší řešení čehokoliv, jenom v oblasti IT je to všechno trochu markantnější a rychlejší. Ovšem pozor, i s prosazováním nových věcí to není tak jednoduché. Je nutné se na ně vždy podívat i skepticky, protože hrozí 2 věci. První je over-engineering projektu, kdy na řešení problému používáme příliš složité technologie. A druhým problémem je vklouznutí do slepé uličky, protože ne vše co se v době svého vzniku jeví jako dobré se dobrým ukáže i po čase používání.

Ve svém důsledku se obávám, že i ty skeptiky, kteří neradi posouvají své znalosti někam dál, potřebujeme. Není přeci nic podnětnějšího než přesvědčování takového člověka, protože je nutné vymýšlet argumenty a při této činnosti se kolikrát ukáže, že jsme měli na očích růžové brýle.

Takže závěrem: doufám, že budeme mít vždy šťastnou ruku ve volbě novinek a že se budu potkávat spíš s těmi nadšenci pro nové věci, které budeme moci probírat a řešit, zda jsou užitečné.

jOpenSpace 2008 - Metodiky vývoje - jak děláme review kódu

2008-10-21T20:08:00.000+02:00

Dneska vám předkládám poslední reakci na první dávku audií z jOpenSpace, po ORM a dokumentaci mě oslovila diskuse na téma metodiky vývoje. Poslední 2 zaznamenaná témata mě k nějakým poznámkám nevyburcovala.

Co se metodiky vývoje v podstatě mě velmi mile překvapilo, že se již naplno prosazují iterativní a agilní způsoby vývoje, které začínají odsouvat nevhodný vodopád. To je velmi potěšující. Je až nepochopitelně překvapující, že se vodopád udržel tak dlouho (mimo jiné podle knihy Craiga Larmana Agile and Iterative Development: A Manager's Guide je zjištění jeho nefunkčnosti hodně staré).

Poslední věc z diskuse je taky všude stejná. Zapojit zákazníka do vývoje je velmi težké, ale pokud se to podaří, je to super věc. My se především staráme o jednu už né-malou aplikaci, kterou poskytujeme jako službu. Je-li zákazník interní (vymyslíme si nějakou funkcionalitu, či vyvíjíme něco dovnitř) pak je to super, je-li zákazník externí, pak je odezva většinou pomalá.

Co ovšem vzbudilo mou chuť napsat tento příspěvek, je poměrně složitý způsob reviewováví kódu, které bylo nastíněno. Protože s naším systémem jsem poměrně hodně spokojen a mám pocit, že je na úrovni, rád se s ním s vámi podělím. Review jsem od začátku zamýšlel tak, aby každý kód, který vytvoříme byl reviewován. Z počátku jsme kontrolovali příchozí změny z CVSka. Pak nás začlo být v teamu víc než 2 a tento postup přestal fungovat.

Zhruba v tu dobu jsme nasadili systém JIRA pro evidenci požadavků. Tím se nám nabídla možnost evidovat jakoukoliv práci na projektu jako požadavek, který definuje, kdo jej bude implementovat a zároveň kdo jej bude reviewovat. Požadavek nemůže být zavřen, pokud nebylo provedeno review. Jednoznačnou výhodou je přehled toho, co se na projektu děje. Dále review provádíme průběžně a nikoliv až na konci iterace (přecijenom dělání review není moc populární a zajímavé), navíc je review skutečně provedeno na každý změněný řádek a to považuji za podstatné (víc očí víc vidí a rozumí-li kódu dva mozky, pak jim pravděpodobně bude rozumět i třetí).

Jako vývojový nástroj používáme Eclipse a proto jsem hledal podporu review kódu integrovatelnou do Eclipse. Jediné co jsem našel byl Jupiter (koukám, že se na něm usilovně pracuje, tak třeba se zlepší). Dlouho jsme jej používali a zjistili jsme, že má řadu nevýhod a proto jsem hledal náhradu. Koukal jsem na Crucible, ale nelíbilo se mi, že by evidence review byla mimo již existující infrastrukturu (podobně jako v případě Jupiteru).

Jako zatím top volba se ukazuje integrovat systém JIRA s naším subversion serverem (pomocí subversion pluginu) tak, aby u každého požadavku zobrazoval change sety, které se jej týkají (k tomu stačí, aby komentář commitu do subversion obsahoval kód požadavku). Následně jsme potřebovali nástroj na zobrazení obsahu subversion a volba padla na Fisheye, protože je sofistikovanější než ViewVC.

A jak samotné review probíhá? Je-li požadavek vyřešen, pak je nutno provést review. Podívám se na požadavek a vidím jaké soubory, byly v souvislosti s jeho řešením commitovány. Přímo ze systému JIRA je možno se prokliknout do Fisheye, kde potřebuji další klik na zobrazení změn souboru s požadavkem souvisejících. Je-li vše v pořádku, pak stačí požadavek označit jako reviewovaný a pak už jej může vedoucí projektu zavřít.

Není-li vše v pořádku, pak přijde na řadu diskuse. Tu nijak nedokomuntujeme a je věcí programátorů, jak ji zrealizují. Pokud se ukáže, že je nutné provést změnu kódu (překvapivě se to děje docela často), pak je v systému JIRA vytvořen další požadavek na změnu (nepřehledný kód, nějaká chyba v kódu, chybějící test atd.). Tento požadavek je normálně řešen a je i reviewován jako každý jiný. Commit do subversion obsahuje kódy obou požadavků, aby byl v systému JIRA spojen s oběma (jak s původním, tak s review).

A jaký má systém výhody a nevýhody? Řadu už jsem jich zmínil, ovšem další výhoda tkví v přesné evidenci toho co se děje, v jakém stavu je který požadavek a co se v souvislosti s jeho plněním měnilo a jak. To je neocenitelné. A nevýhody? Pokud je požadavek hodně rozsáhlý, pak je složitější se v souborech vyznat. Je-li to umocněno více change sety (tj. více commity), je to skutečně náročné.

A uplným závěrem motivační větu: Review kódu skutečně zvyšuje jeho kvalitu a napomáhá dřívějšímu odhalení chyb. Navíc se programátoři učí číst kód druhých, orientovat se v něm, komunikovat o něm a lépe poznávají systém, který programují.

Spring bean z Java enumu

2008-10-14T13:43:00.004+02:00

Dneska jsem potřeboval vytvořit ve Spring IoC Java enum, ale jak na to. Než jsem začal vytvářet nějakou factory, řekl jsem si, že to už musí být vyřešené. Google pomohl a našel jsem blog post Creating a Spring Bean from a Java 5 Enum.

Ve stručnosti se věc dá shrnout do dvou ukázek, první jest pro Spring 1.2.2 a menší:

<bean id="latte" class="cz.xxx.PersonType" factory-method="valueOf">
   <constructor-arg>
      <value>ADULT</value>
   </constructor-arg>
</bean>

Kde ADULT je jméno konkrétního enumu. Domnívám se (nezkoušel jsem), že tuto variantu je nutné použít i ve Springu 1.2.2 a vyšším, pokud se odkazujete na enum v okamžiku, kdy není jasné, že výsledkem má být enum (např. položky listu, mapy).

Používáte-li Spring 1.2.2 a starší, pak na místě kde má být enum stačí použít:

<bean id="person" class="cz.xxx.Person">
   <property name="type" value="STUDENT"/>
</bean>

Jednoduché, ale moc šikovné. Tak to mám rád.

jOpenSpace 2008 - Dokumentace - nezatracujme FOP

2008-10-13T10:15:00.003+02:00

A máme tu pokračování inspirované poslechem audio záznamů z jOpenSpace konference. Již jsem psal o ORM a nyní mé poznámky k tématu Dokumentace. Toto téma mě opravdu hodně zajímalo, protože jsem měl dojem, že na našem projektu dokumentace moc nevzniká a hrozně mě zajímalo, jak to dělají druzí.

V podstatě vývojářskou dokumentaci neděláme žádnou, takže pro nováčka může být dost obtížné se v kódu zorientovat. Proč to tak je? No v podstatě se snažíme psát přehledný a jasný kód, což je pohlídané především systémem review, který používáme (o něm více v příštím příspěvku). Navíc je to vše umocněno skutečností, že mé schopnosti orientovat se v kódu jsou nadstandardní a protože podle sebe soudím tebe, myslím si, že to dovedou všichni. Ve výsledku se ukazuje, že to chvilku trvá, ale ve výsledku je struktura aplikace poměrně dobře pochopitelná. Hlavním problémem stejně zůstává skutečnost co aplikace dělá a proč, a o tom bych dokumentaci psal hodně nerad, protože by to bylo na hrozně dlouho.

Byl jsem potěšen, jak i v tomto ohledu je tvorba naší dokumentace v souladu s okolím. Především pro uživatelskou dokumentaci používáme DocBook, který v poslední době editujeme pomocí XMLMindu. A nyní se začínáme malinko odlišovat. Obecně se hovoří o různých způsobech převodu DocBooku do výstupního formátu. Zde jsme šli standardní cestou a tou je XSLT transformace, kterou získáváme jak manuál v HTML tak v PDF (přes FOP). Protože jsme si vybrali jenom podmnožinu DocBooku, kterou podporujeme, máme vlastní šablony, které nejsou komplikované a vše funguje ke 100% spokojenosti. Konfigurace fontů, která byla zmiňovaná jako komplikovaná, zas tak složitá není (v porovnání např. s iTextem je srovnatelně složitá).

Samozřejmě FOP má své mouchy a nedostatky, ale současné verze se od 0.20.5 liší a dosahují uspokojivých výsledků. Navíc se FOP docela vyvíjí a každá nová verze je lepší než ta předchozí.

Jako podpora nanáviděných formátu od nejmenované firmy, bylo zmíněno, že uživatelé stejně vyžadují Wordový dokument, který umějí zpracovat a proto nejde DocBook použít. To není pravda, protože převod DocBooku do RTF není problém a pak pomocí revizí zanést změny zpět do DocBooku také není složité.

Z diskuse je zřejmé, že s dokumentací se bojuje všude a najít vyvážení mezi dost a né příliš záleží projekt od projektu. Ale obecně platí, čím více dokumentace jsme schopní vygenerovat na základě jednoho zdroje (ať už je jím DocBook, kód, UML model atd.) tím lépe pro všechny zúčastněné. Jakmile začneme přepisovat myšlenky z UML, či z kódu do dokumentace je to cesta do pekel, dřív nebo později se dokumentace rozejde s originálem (a když se nerozejde, bude nás to stát velmi vysoké úsilí).

jOpenSpace 2008 - ORM - Hibernate a klientská aplikace

2008-10-05T20:49:00.006+02:00

Konečně jsem se dostal k tomu, abych si poslechl audia z akce jOpenSpace. Pro zájemce bych odkázal především na blog otce Fura.

Konference musela být jisto jistě velmi zajímavá a prospěšná. Moc mě mrzí, že jsem se nezúčastnil, ale mohu si za to především sám, protože jsem zasklil call-for-papers v konference java.cz. Dám si závazek, že napřezrok se to již nebude opakovat.

První záznam je z diskuse o ORM. Nosným tématem je použití Hibernate v klientských aplikacích. Problematické v tomto případě je, že Hibernate session object není thread-safe a Hibernate si hodně zakládá na lazy nahrávání čehokoliv (tj. k nahraným objektům je připojena session a atributy, asociace se dohrávají až v okamžiku, kdy je potřeba).

Klientské aplikace napsané v AWT, Swingu nebo SWT mají jedno velké specifikum oproti aplikacím webovým. Tím specifikem je jednovláknovost těchto knihoven. Tj. kód, který přistupuje k UI tak musí činit z UI vlákna (ve webové aplikaci má každý request své vlákno - skoro vždy). Z tohoto vlákna tedy není vhodné provádět náročné akce, protože dojde k zamrznutí UI. A jak v tomto prostředí řešit přístup k datům (pomocí Hibernate a jeho nesynchronizovaného objektu session)?

Varianty jsou v podstatě tři:

používat session pouze z UI vlákna
používat session pouze z jiného vlákna
používat session jak z UI tak z jiného vlákna

První varianta je špatně, protože provádět dlouho trvající dotazy z UI vlákna zhorší odezvu UI. Druhá varianta je ideální, ale má jedno úskalí. Jak zařídit nahrání všech vlastností a vazeb objektu, které budou v UI potřeba tak, aby již nebylo nutné dotahovat žádná data (tj. jak obejít Hibernate laziness). Třetí varianta spočívá v nahrání dat v jiném vlákně a následném nahrání lazy atributů a vazeb z UI vlákna (dotahují se, až když k nim UI přistoupí a to tak učiní z UI vlákna).

Ještě je nutno zmínit jak to bude se správou session objektů. V prvním případě nám stačí jedna session, protože ji používáme pouze z jednoho vlákna. Pro druhý případ může session potřebovat víc, ale ve své podstatě to záleží na počtu výkonných vláken pro provádění komunikace s DB přes Hibernate. Ve třetím případě určitě potřebujeme pro každou událost (řekněme, že se jedná o obdobu requestu v klientské aplikaci) vlastní session, protože ji použijeme pro nahrání objektů a případné další lazy nahrávání z UI vlákna. Tyto 3 strategie je možné komplikovat dodáním synchronizace a využitím menšího počtu session objektů.

Mě osobně se nejvíce zamlouvá druhá varianta, protože veškerá režie s nahráním dat je mimo UI vlákno. Ale jak nahrát vše co je potřeba? Velmi jednoduše. Stačí, aby model každého UI prvku implementoval speciální rozhraní, které bude vracet ty atributy a vazby, které bude pro své vykreslení potřebovat. Díky tomuto kroku a stromové struktuře UI elementů stačí získat tento seznam pro model root elementu (ten se rekurzivně poptá u svých potomků). Inicializaci lazy atributů a vazeb je možné provést pouhým přistoupením k nim pomocí get metod (nebo pomocí metody initialize).

Bohužel klientskou aplikaci jsem již hodně dlouho nedělal, takže tento návrh je pouze z mé hlavy a né z praktické zkušenosti.

Jak mě vypekla DB2

2008-09-26T20:17:00.004+02:00

Začnu zeširoka. Možnost ukládat XML do databáze v DB2 se mi moc líbí. XQuery je plně integrováno s SQL, je možno tedy dělat dotazy i na XML data z SQL. Navíc jsou plně podporovány indexy, takže vyhledávání může být i rychlé.

Navíc v aplikaci, kterou vyvíjíme je velký tlak na uložení různorodých dat. Vytvářet velké množství tabulek nechci. Ukládat je rozložením do universální tabulky, kde bude více řádků pro jednu entitu (jeden sloupec nese název atributu a druhý jeho hodnotu), taky nechci. Takže jsem si vysnil ukládat je do XML.

10 dní jsem realizoval framework, který mi toto umožní a bude fungovat ruku v ruce s Hibernate. Vše jsem otestoval, vyzkoušel a funguje to super. No a dnes jsem se pustil do realizace v našem produktu. A ejhle, hned jsem narazil na problémy, které mě zastavily.

Není možné mít sloupec typu XML v tabulce, která používá MDC (MultiDimesional Clustering). Velmi špatná zpráva, protože MDC používáme pro zvýšení výkonu přistupu k datům v našich obřích tabulkách. Asi budu muste udělat druhou tabulku, kde budu ukládat pouze XML ... půjde to, ale výkon nebude nic moc ...

A druhá rána, sloupec typu XML nemůže být ve view, které používá INSTEAD OF triggery. Tak to zase používáme pro zápis dat do logovacích tabulek, abychom dokázali trackovat jak se měnila data. To asi budu muset obejít buď logováním přímo z aplikace (pomocí Hibernate a jeho Interceptoru), což se mi nelíbí. Přišel bych o tuto funkcionalitu při přímém přístupu přes SQL. A nebo budu muset udělat trigger přímo na tabulku, což není jednoduché, protože jsem do view často dotahoval data i z jiných tabulek.

Každopádně ... jsou to problémy řešitelné. Ale opět jsem se přesvědčil, že vývoj aplikací není předvídatelná činnost a nedá se naplánovat. Kolikrát si myslíme, že jsme na konci cesty a musíme se zase pěkný kus vracet.

Termín nám straší za dveřmi ... vysvětlete to obchodníkům ...

Tapestry - jak dělat webové aplikace konfortně

2008-09-22T21:42:00.004+02:00

Už je to zase příšerně dlouho co jsem si našel chvíli a navíc jsem měl chuť něco sepsat a protože se mi nahromadilo pár zajímavých čtení o Tapestry, pak je logické, že můj první příspěvek po takové době patří právě Tapetry. Navíc je to pár hodin, co vyšlo Tapestry 5.0.15, které mělo být prvním release candidatem. Bohužel se tak nestalo, kvůli chybičkám objeveným v pozdní stádiu releasu (blíže).

První článek, který vám chci naservírovat, je zajímavý, protože se mu podařilo velmi přehlednou formou shrnout proč je Tapestry zajímavé. Why you should consider Tapestry 5. Bohužel je už malinko starší. Ze stejného blogu pochází i porovnání s Wicket: A glimpse of Wicket 1.4 and Tapestry 5.

Tapestry se vždy hlásilo k následujícím pravidlům: rychlost a škálovatelnost vytvořených aplikací, pohodlný vývoj aplikace bez potřeby speciální podpory v IDE a vysoká produktivita vývojáře. A o produktivitě je Boost Your Productivity Using Apache Tapestry.

Specialitou Tapestry již od verze 4 je vlastní IoC framework. Ve verzi 4 se jednalo o HiveMind, ve verzi 5 jde prostě o Tapestry IoC. Proč má Tapestry vlastní IoC framework, co umí je možné se dočíst ve dvou článcích napsaných přímou autorem Howardem L. Shipem: Tapestry 5 IoC: Binding and Building Services a Tapestry 5 IoC: Introducing Service Configurations.

V neposlední řadě: pozitivní krok je i vznik AppFuse pro Tapestry 5.

Konečně build systém na úrovni - Gradle

2008-07-21T20:06:00.006+02:00

Již hodně dlouho se na mě ze všech stran valí, že Ant je překonaný a že bychom měli používat Maven. Jistě Maven přináší spoustu zajímavých myšlenek, především zavedl jednoutnou strukturu projektů a správu závislostí. Ovšem přinesl i spoustu problémů, jako pevně daný build cycle či buildování multi-projektu.

Na trhu open source projektů se objevuje nový hráč, který si řadu těchto nešvarů bere za své a snaží se je napravit. A o jakém projektu, že píši? O projektu Gradle. Gradle je teprve ve verzi 0.2, ale vyvíjí se mílovými kroky.

A co je to převratné, co mě zaujalo. Build skripty se píší v jazyce Groovy. Má to řadu výhod, skript je programován, je možné používat (zavolat) jakýkoliv kód (díky Groovy, jakýkoliv Javovský kód). Navíc je možné opakující se části volat jako funkce (které se dají vytvářet přímo v build scriptu). Bezvadná integrace s Antem. Kolik z nás má v Antu poměrně složité skripty na generování kde čeho. Jejich převod pod Maven je hotovým peklem. Dále build multi-projektu v maven jde pouze z kořenového projektu, díky čemuž se buildu celý multi-projekt. V Gradle je možné multi-projekt build spustit z libovolného projektu a tím se buildují jenom ty podprojekty, které jsou potřeba.

Konvence ohledně build cycle jsou v Gradle definovány pomocí pluginů. Tj. pokud použiji plugin java, pak je nadefinován konkrétní build cycle. Tento může být dle potřeby modifikován, buď jiným pluginem (např. plugin groovy) či samotným build skriptem. To znamená konec dvojí pouštění testů, aby mohl vzniknout Cobertura code coverage.

A co zatím chybí. Je toho stále dost, není nativní podpora pro TestNG, Coberturu. Neexistují integrace s IDE.

Zatím jsem lákání Mavenu odolal a doufám, že Gradle dospěje a pomůže mi vyřešit problémy, které s Antem máme. Hrozně nerad bych naše skripty převáděl a ladil v Mavenu.

On se ještě používá jUnit? Vždyť máme TestNG.

2008-06-09T18:13:00.006+02:00

Konečně jsem si poslechl záznam přednášky Jana Novotného Automatické testování v praxi. Jen více takových ...

Ale proč píšu tento příspěvek? Stále mě překvapuje jak velké množství lidí neustále používá jUnit, který mi přijde v porovnání s TestNG jak chudý příbuzný. Proto jsem se rozhodl nastínit 2 hlavní výhody TestNG, alespoň z mého pohledu.

Přecházel jsem na TestNG v době, kdy po jUnit4 nebylo ani vidu ani slechu, takže jsem měl rozhodování o hodně jednodušší. Ale i po uvolnění jUnit4 je TestNG lepší. Ovšem jako jUnit4 vyžaduje Javu 1.5, takže pro vás co běžíte na Javě 1.4 a méně, pak máte smůlu (ovšem testy můžete překládat jinou verzí Javy než produkční kód).

Na úvod porovnání uvedu: jako vývojové nástroje používám Eclipse, builduji Antem nebo Mavenem a necítím se být nijak limitován užíváním TestNG oproti jUnitu.

Nyní k výhodám. Hlavní skutečnost, která mě hnala za změnou jUnitu za něco jiného je skutečnost, kterou se sice podařilo vyřešit, ale neskutečmě se mi nelíbila. Jde o to, že každý test nejenom dostává vlastní novou instanci TestCaseu, ale tato instance je zároveň použita jako objekt nesoucí informaci o výsledku testu (proběhl / neproběhl). Proč mi to vadí? Protože pokud máte hodně testů a u hodně z nich si naplníte instanční proměnné nějakými instancemi, pak vám běh testů sežere hodně paměti (protože se instance TestCaseů neuvolní pro garbage collection), pokud nespadnou na nedostatek paměti. Takže buď musíte ručně nastavovat hodnotu null do všech instančních proměnných (pracné a náročné na nezapomenutí) a nebo mít připraveného předka, který bude mít tearDown s funkcí nastavování hodnoty null instančním proměnným.

Druhou obrovskou výhodou, kterou jsem dokázal ocenit až po chvíli užívání testNG jsou data-providery. jUnit4 nabízí něco podobného v podobě parametrizovaných testů, ovšem to co nabízí TestNG se to podobá hodně vzdáleně. Když se podíváme na příklad z článku o jUnit4 na devx.com:

@RunWith(Parameterized.class)
public class SquareTest {

  private static Calculator calculator = new Calculator();
  private int param;
  private int result;

  @Parameters
  public static Collection data() {
    return Arrays.asList(new Object[][]{ {0, 0}, {1, 1}, {2, 4}, {4, 16} });
  }

  public SquareTest(int param, int result) {
    this.param = param;
    this.result = result;
  }

  @Test
  public void square() {
    calculator.square(param);
    assertEquals(result, calculator.getResult());
  }

}

Z příkladu je zřejmé, že jUnit parametrizuje na úrovní třídy, protože parametry se ze statické metody předávají do konstruktoru třídy. Naproti tomu TestNG:

public class SquareTest {

  private Calculator calculator = new Calculator();

  @DataParameter(name = "square")
  protected Object[][] data() {
    return new Object[][]{ {0, 0}, {1, 1}, {2, 4}, {4, 16} };
  }

  @Test(dataProvider = "square")
  public void square(int param, int result) {
    calculator.square(param);
    assertEquals(calculator.getResult(), result);
  }

}

Data providerů můžu mít v TestNG víc, dokonce může data provider být z jiné třídy, než test, který jej využívá. Jediné, co si mi nelíbilo, je přehození parametrů metod assert, tj. první je actual a druhý expected. Naštěstí existuje třída AssertJUnit, která zachovává zvyklost z jUnitu.

Tyto dvě skutečnosti jsou pro mě tak silnými argumety, že jsem přešel a nelituji. Navíc použití data providerů je tak jednoduché, že dnes je používám možná více než je zdrávo, ale když jsou tak elegantní.

Test prošel. To je špatně!

2008-05-25T21:13:00.005+02:00

Test Driven Development má jednu obrovskou výhodu. Tj. napsat test na neexistující funkcionalitu, pustit jej a ... ano správně ověřit, že test neprošel. Co je to za výhodu?

Přiznám se, že TDD stále není můj šálek kávy. Jestli jsem moc starej a nebo jsem ještě nevyspěl, nevím. Ale stále píšu kód a ten pak testuju a ne obráceně. Stále je moje myšlení tam, že vymýšlím jak věc udělat, když ji tvořím a ne, když vymýšlím test.

No a tady je zakopanej pes, protože pokud chci být korektní, musím manuálně a naprosto proti směru vývoje věcí, nakonec kus kódu pozměnit a zjistit, zda se nestane to co inzeruju v nadpise.

Pokud totiž tento krok neudělám, pak se může stát co se mi už nejednou stalo a to, že testy prošli, ale ne proto, že jsem měl dobře napsanej kód, ale protože test netestoval to co měl.

Stále se přesvědčuji, že Extreme Programming je domyšlené do posledního puntíku a je jenom otázkou času, než to zjistím.

Na unit testy si vždy čas udělám ...

2008-05-15T12:35:00.004+02:00

Přečetl jsem si příspěvek Máte čas na unit testy? od Petra Jůzy a po dlouhé době, mě nějaký text přiměl k reakci (Kde je dagi se svými kontroverzními tematy).

Přiznám se, že s testováním jsem začínal nějakým 8 let zpátky za pomocí jUnit knihovny a měl jsem dobrý pocit. Spíš mě to ale zdržovalo. Postupem času jsem se naučil (alespoň si to myslím) testy psát, začal jsem používat Coberturu a přešel jsem na TestNG.

Nedokážu si představit, že bych neměl unit testy. Proč? Jak píšu kód, píšu testy, kterými ověřím, že to celé funguje ještě předtím, než začnu integrovat komponenty dohromady. Jak to dělají ti, co testy nepíšou netuším. Pokud si vše otestuju, pak v návazných objektech používám mock implementaci téhož (díky EasyMock knihovně) a testuju dál. Nejednou jsem kód měnil, abych ho dokázal otestovat a nejednou jsem se setkal s tím, že se mi taková změna v budoucnu vyplatila.

Psát testy stojí čas, ale i když testy nepíšete, nějak musíte testovat a to také stojí čas. Pokud dojde na nějaké úpravy v budoucnu, pak jsou testy k nezaplacení, protože vzpomenout si, jak jsem to vlastně před půl rokem testoval, to už chce sakra dobrou paměť. Při opravě chyb je to podobné, testy opět pomůžou.

Psát testy až po odladění aplikace je zvěrstvo a plýtvání časem. Má to význam pouze pokud chceme opravit chybu nebo udělat změnu. Pak se může vyplatit napsat na ni testy a teprve poté se pustit do změn.

Nepoužívám TDD a tudíž testy píšu až po napsání výkonného kódu. Nějak na tuto myšlenku nejsem ještě připraven.

A co my testy přinášejí především? Jistotu ...

Jak nás vypek DateFormat.parse

2008-02-18T20:30:00.005+01:00

Tak jsme zase objevili jednu, pro mě překvapivou, skutečnost. Ale vezmu to popořadě. Chceme parsovat datumy s časem reprezentované stringem. Používáme Javu, takže jednoduchý úkol pro DateFormat:


DateFormat format = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
Date datum = format.parse(retez);

Tento postup má pro mě nelogickou nevýhodu. Tj. pokud si například někdo zplete pořadí měsíce a dne v měsící (u tohoto formátu to není moc pravděpodobné, ale jsou jiné, kde to jde velmi jednoduše), stejně nám to datum vytvoří. Např. parserování textu 2008-24-04 1:30:43 neznamá chybu, ale datum 2009-12-04 1:30:43.
Absolutně tuto vlastnost nechápu, ale třeba se někomu hodí. Proč je ovšem implicitní, to nepochopím nikdy. Naštěstí se dá jednoduše vypnout:


DateFormat format = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
format.setLenient(false);
Date datum = format.parse(retez);

Takže tentokrát už dostaneme, pro mě očekávanou, ParseException.
A teď se pomalu blížíme k dnešnímu překvapení. Co se stane, pokud na vstupu bude řetěz 2008-04-24 1:30:43 PM? Možnosti jsou tři: ParseException, datum 2008-04-24 13:30:43 nebo datum 2008-04-24 1:30:43? Osobně jsem předpokládal možnost první, přežil bych možnost druhou, ale pravdou je možnost třetí. DateFormat si i v ne-lenient módu odignoruje část vstupního řetězce. To jsem opravdu nečekal a dost mě to zarazilo. Takže pokud někdo chce skutečně správnou funknci parserování data z řetězce, musí použít:


DateFormat format = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
format.setLenient(false);
ParsePosition p = new ParsePosition(0);
Date datum = format.parse(retez, p);
if (p.getIndex() < retez.length() - 1) {
   throw new ParseException(...);
}

Pozor, v případě použití ParsePosition metoda parse nevyhazuje výjimku, musíte si chybu ošetřit sami.
Tak a máme konečně, dle mého názoru, správné parserování řetězce na text. Kód je o poznání složitější než ten, se kterým jsme začínali. Škoda, zřejmě chceme to, co není normální pro ostatní.

PS. Díky Luboši ...

Nová Java: Jak z toho ven ...

2008-02-01T20:57:00.000+01:00

Už je to nějaký pátek, co jsem se zabýval vlastnostmi, které bych rád viděl v Javě 7. Něco málo se na mém názoru změnilo: jsem ještě radikálnějsí. Proč? Jsem přesvědčen, že není možné rozšířit Javu tak, aby byla zpětně kompatibilní a zároveň nabízela prvjky, které by moderní jazyk měl mít. Sun se snaží udržen nejen zpětně kompatibilní bytecode, ale i zdroják. A to je ten problém.

A jak z toho ven. Současnou Javu bych nechal takovou jakou je. Cestu ven by nám ukázala nová Java, říkejme jí např. JavaNW (New Way). JavaNW by byla překládána do stejného bytecode, ale byla by nekompatibilní na úrovni zdrojového kódu. Co to znamená? Nepřijdeme o nic z existující infrastruktury: JRE, HotSpot, Terracotta, Tomcat, ... všechno funguje. Ale to není ještě konec seznamu, protože všechny knihovny budou také použitelné: standardní knihovny Javy, Hibernate, Tapestry, FOP, ... vše budeme moci používat i nadále. Takže vlastně skoro o nic nepřijdeme, ale co vlastně získáme? To co získáme je absolutně závislé na tom, jaká bude JavaNW?

Bude JavouNW Scala? Poslední dobu jsem vyplnil studiem tohoto opěvovaného jazyka. Musím přiznat, že jeho prvky jsou opravdu úchvatné (snad se o nich někdy rozepíšu podrobněji), ale je to jiný jazyk. Syntaxe je jiná, pravda kompaktnější (není tolik upovídaná a všechny vlastnosti jsou zakomponovány tak, že do sebe krásně zapadají). Je možné použít stávající knihovny, ale Scala má také vlastní, a ty je potřeba poznat. Je mi to moc líto, protože se mi Scala opravdu moc líbí, ale nemyslím, že se Scala stane JavouNW (nikdy jsem nevěštil, tak spoléhám na to, že to neumím ...).

Tak co třeba některý ze skriptovacích jazyků: Groovy, JRuby, Jython, ... Ne nemyslím si, že budoucnost je v netypových jazycích, Scala nabízí spoustu (netroufám si napsat všechny) vlastnosti, pro které se mi tyto jazyky zamlouvají, ale je typová. Nemyslím, že jsme schopni a ochotni se připravit o výhody typového jazyka: odhalení řady chyb již při překladu, lépe fugující Code Assist, refaktoring, ... Takže JavaNW musí být něco jiného.

Takže kde vzít JavuNW? Za rozumné považuji více vyjít z Javy, aby se syntaxe nového jazyka Javě více podobala a přechod nebyl tak bolestný. Zakomponovat do něj všechny "potřebné" prvky pořádně: generiky, closures, paralelní zpracování a další. Pak by přechod mohl být pozvolný, poklidný a měli bychom nový "nabušený" jazyk.

Jak vnést trochu pořádku do CSS

2008-01-21T20:24:00.000+01:00

Jsem puntičkář, mám rád, když věci mají jasný řád. Ale todle nějak nejde dohromady s našimi CSS soubory. Snažil jsem se malinko upravit layout stránky a vztekal jsem se s tím skoro půl dne. A pak mi srazil vaz Explorer a začal iterativní proces sbližování vzhledu Firefox vs. Explorer.

Nakonec jsem se poohlídl na webu po nějakých radách a typech, jak zanést řád do změti selectorů, atributů a jejich hodnot. Našel jsem pár šikovných rad, které jsou zřejmě lidem pracujícím s CSS delší dobu již známy, protože si je velmi pravděpodobně již vymysleli nebo přečetli. Ale pro Javisty, kteří považují CSS spíš za nutné zlo, snad budou tyto rady prospěšné (i když všechny popisované principy jsou nám již dávno známé).

Modulárnost

První věcí je modulárnost a její striktní dodržování. Přivede nás k opakovanému použití celých CSS souborů. Takže náš styl jsme rozdělili do následujících souborů:

Typografie - definuje základní vlastnosti HTML elementů včetně fontů, velikostí atd. Tento soubor je nezávislý na projektu.
Formuláře - asi nejsložitější část stylů, spousta hacků, aby formuláře vypadaly stejně ve většině prohlížečů apod.
Navigace - velmi často se menu aplikace dá použít napříč více projekty, takže proto jej umístěme do zvláštního souboru.
Layout - základní layout stránky je velmi jednoduše oddělitelný od zbytku a navíc je silně projektově závislý.
Barvy - definice barev je samostatná, což umožňuje jednoduché přebarvení stránek, vše máte na jednom místě.

Abychom neměli 5 CSS souborů (v souladu se závěry z Yahoo!) pak je vhodné mít ještě šestý soubor, který složí 5 zmíněných v jeden pomocí @import url("file_name.css");.

Sjednocení marginu a paddingu mezi Explorerem a Firefoxem

Následuje zjednošení počtu hacků, které používají jiné definice pro Explorer a Firefox. Celá věc je velmi jednoduchá a ušetří spoustu kódu:


* {
  padding:0;
  margin:0;
}

h1, h2, h3, h4, h5, h6, p, pre, blockquote, label, ul, ol, dl, fieldset, address {
  margin:1em 5%;
}

li, dd {
  margin-left:5%;
}

fieldset {
  padding: .5em;
}

Speciální CSS soubor pro Explorer

Protože jsme stále potřebovali řadu hacků, speciálně pro Explorer (primární platformou pro vývoj je u nás Firefox), pomocí podmíněného komentáře dotahujeme styl pro Explorer (nakonec jsme použili stejnou hierarchii jako v kapitole o modulárnosi):


<!--[if IE] >
< link rel="stylesheet" href="IE.css" media="screen" />
<![endif]-- >

Závěr

Celé nám to chvíli trvalo, protože ve stylech skutečně panovala anarchie, ale nyní je velmi jednoduché představit nějaké změny, odstartovat nový projekt a podobně. Ukázalo se, že je možné zanést pořádek i tam, kde mi bylo tvrzeno, že to nejde ...

Odkazy

Používám Linux a nelituju ...

2008-01-14T11:13:00.000+01:00

Nějak se rozhořelo téma Linuxu na desktopu (dagi či Aleš Dostál), i když na specifickém desktopu a to jest desktopu vývojáře. Ja používám Linux na svém desktopu už skoro 5 let (od února roku 2003) a jsem s ním nad míru spokojen. Od jakživa používám SUSE, nyní openSUSE (altuálně 10.2) ve spojení s KDE (GNOME bylo zkraje hodně velký žrout paměti a už jsem zvyklý na KDE, takže měnit nebudu). Nově jsem si openSUSE nainstaloval i na své nové VAIO a světe div se, vše funguje (jenom původní token iKey 1000 není pod linuxem podporován, takže potřebuju iKey 3000 - to vše pro přístup do firemní sítě).

A proč nechci už Windows ani vidět? Důvody jsou 3: KWrite, terminal a ssh.

KWrite je ten nej editor na cokoliv, který jsem kdy viděl, přepínání kódování, blokové kopírování, podpora XML. Command line v podobě terminálu je naprosto k nezaplacení, nedokážu si představit, že bych pracoval bez ní (už v ní i kopíruju soubory, rozbaluju archivy apod.) a ve Windows jsem zatím nenašel solidní náhradu (ani jsem moc nehledal ...). A ssh je prostě víc než PuTTY, fungují všechny klávesy jak mají (např. ctrl + end).

Největším problémem je asi přenos dokumentů mezi MS Office a OpenOffice, ale zvykl jsem si. Podpora se za těch pět let hodně zlepšila, opravdu hodně moc ... není to na to, abych něco napsaného v MS Office vytiskl a vypadalo to, jako vytištěné z MS Office, ale čitelné je vše (včetně poznámek, tj. není pravda co psal ronnie).

A proč se mi líbí právě SUSE a né třeba Fedora nebo Ubuntu? Je to kvůli YASTu, protože funguje jak v terminálu tak v Xkách a nastavím s ním většinu věcí, které běžně potřebuju ...

Tj. nebojte se linuxu, je to jiný než myšoidní přístup Windows, asi nevypadá tak líbivě jako Windows, ale funguje spolehlivě a bezproblémově.

Nová Java: Chceme ji? - tvrdá realita

2008-01-08T17:24:00.000+01:00

Dneska jsem si pročítal nějaké články o Closures v Javě a narazil jsem na článek Closures and Preserving the Feel of Java, který nepřináší nic nového, ale v jeho komentářích jsem našel perličku od Kurta Christensena:

I remember a great presentation by Bjarne Stroustrup back around 1997 at the Computer Literacy bookstore. Someone said that Java looked like a much better, cleaner C++, to which Stroustrup replied that we should ask him about it again in 10 years after everyone was finished adding the features they want. Well, it's 10 years later, and new Java code is starting to look an awful lot like C++.

Tak trochu střílím do vlastních řad, protože jsem pro rozšiřování jazyka, ale nechci jej rozšiřovat za každou cenu, pokud se nějaké, byť prospěšné, rozšíření ukáže jako problématické, či zesložiťující syntaxi, pak jej nechme být ...

Nová Java: Chceme ji? - počtvrté

2008-01-06T20:11:00.000+01:00

Myslím, že jsem se dostal do finále, alepoň pro tento okamžik, protože poslední věc, která by jistě zasloužila vylepšení je vytváření naplněných collections. Dneska je nutné vytvořit instanci (Collection nebo Map) a postupně do ní přidávat prvky.

Jistě existují různé "zkratky" přes pole, která můžeme vytvářet pomocí inicialiazátoru. Další pokrok přináší Google Collections Library, ale stále to není ono. A přitom jednoduchou syntaxi již máme vymyšlenou, např. pro Groovy.

Takže proč collection nevytvořit:

Collection<Object> col = [ 1, 2, "33", new Long(10) ];

Je to jistě jednodušší než:

Collection<Object> col = new ArrayList<Object>();
col.add(1);
col.add(2);
col.add("33");
col.add(new Long(10));

Jen pro dolnění, prázdná mapa je: [].
Pokud přejdeme na na mapy, je věc identická. Nejprve klasicky v Javě:

Map<Integer, String> map = new HashMap<Integer, String>();
map.put(1, "1");
map.put(2, "dva");
map.put(3, "3");

A jak by tyto 4 řádky vypadaly, kdyby se vylepšila syntaxe vytváření map:

Map<Integer, String> map = [ 1:"1", 2:"dva", 3:"3" ];

Jenom pro doplnění prázdná mapa se vytvoří [:].

Závěr

Nedokážu odpovědět na otázku, zda takovou Javu chceme? Za sebe mohu říci, že změny, které jsem navrhoval podporuju. Ale nesmí dojít k nejasnostem jako v případě implementace generik. Vše musí zapadnout do již existujícího jazyka a fungovat. Pokud se ukáže nějaký problém, jsem pro, aby se z implementace vycouvalo.
Otázkou samozřejmě je, zda je nutné zachovat zpětnou kompatibilitu. Myslím si, že není problém udělat nekompatibilní JavuX a vní implementovat vše co potřebujeme, ale je to co chceme? Ja myslím, že ne, protože to už by nebyla Java ...

Nová Java: Chceme ji? - potřetí

2008-01-05T22:26:00.000+01:00

Původně jsem si myslel, že na tenký led typu closures se pouštět nebudu, protože to je hodně pálivé téma, ale když už se do toho pustil Dagi, chci přidat svůj pohled.

Předně co si pod pojmem closures představuji já: v podstatě zavolatelný kód, takový pointer na funkci. Nespojoval bych to se správou zdrojů (Automatic Resource Management).

Nejprve jsem si prošel všechny návrhy, které se okolo closures v Javě 7 přetřásají (JSR, BGGA, CICE, FCM, C3S). Musím se přiznat, že přestože jsem relativně dost nakloněn novinkám v Javě, tak BGGA návrh mi přijde hodně špatný. Kód je složitý, closures není možné použít všude, kde to dává smysl, a tzv. closures se nechovají jako kus Java kódu (nejde použít break, continue ani dokonce return). Takže pokud otázka stojí: Chceme BGGA návrh jako closures do Javy? říkám jasně a nahlas Ne.

Je jasné, že přidat do Javy closures tak jak je známe např. z Groovy se asi nepovede. Takže potřebujeme nějakou zjednodušenou variantu. A ty vidím dvě. První, která se mi líbí kvůli velmi jednoduché syntaxi a široké nabídce možností, je FCM (First Class Methods). Jsem přesvědčen, že mi pomůže skutečně zjednodušit všechny typy algoritmů, kde si na closures vzpomenu, když je píšu v Javě.

Kdyby existoval argument proč FCM nepoužít, pak se kloním k CICE, které není tak jednoduché jako FCM a není tak moc komplexní, ale přesto nabízí hodně. Bohužel neodstraňuje nutnost existence rozhraní, které bude "closure" implementovat...

Věřím, že se BGGA v Javě 7 nedočkáme ...

Nová Java: Chceme ji? - podruhé

2007-12-30T21:51:00.000+01:00

Blíží se nám konec roku 2007 tak proč nepokračovat v mých představách změny jazyka, tj. takový malý výhled toho co by se v roce 2008 mohlo změnit.

V předchozím příspěvku jsem se rozjel na téma vylepšení programovaní paralelních programů. Dneska se pustím spíš do oblasti vylepšení psaní kódu, tj. změny, které cítím, že zpřehlední kód.

Vylepšení příkazu `switch`

Jistě všichni víme, že příkaz switch funguje pouze nad typy int a char. Takže žádný long, fload, double, natož např. String (o tomto konkrétním typu hovořili pánové v JavaPosse #151). Kdo se podíval pod pokličku překladu switch příkazu do bytecodu, zjistil, že k tomu slouží dvě instrukce, buď lookupswitch nebo tableswitch. V podstatě jde o to, že tato instrukce na základě hodnoty výrazu ve switch příkazu skočí na správný case. Pokud chceme vytvořit ekvivalent např. pro String, pak použijeme kaskádu if - else if - else if ... .
Proč, ale nepovolit switch i pro jiné výsledné typy výrazu (např. String) a až překladačem vše přeložit stejně jako onu kaskádu ifů?

Odchytávání více typů výjimek najednou při zachování typu výjimky

I v tomto případě jsem se nechal inspirovat povídáním pánů z JavaPosse. No představme si následující metodu:

protected Object invokeMethod(String s) throws IllegalArgumentException, 
 IllegalAccessException, InvocationTargetException, 
 SecurityException, NoSuchMethodException 
{
 Method m = String.class.getMethod("toString", new Class[0] );
 return m.invoke(s, new Object[0]);
}

Nyní chceme tuto metodu zavolat a vyhodit jinou výjimku v případě, že se nepodařilo najít metodu a jinou v případě, že se ji nepodařilo zavolat. Nemáme jinou volbu než:

try {
 invokeMethod("A");
} catch (IllegalArgumentException e) {
 throw new CantInvokeException(e);
} catch (IllegalAccessException e) {
 throw new CantInvokeException(e);
} catch (InvocationTargetException e) {
 throw new CantInvokeException(e);
} catch (SecurityException e) {
 throw new CantFindMethodException(e);
} catch (NoSuchMethodException e) {
 throw new CantFindMethodException(e);
}

A to je vskutnu zvěrstvo. Nebylo by přeci jenom lepší něco následujícího:

try {
 invokeMethod("A");
} catch (IllegalArgumentException, IllegalAccessException, 
 InvocationTargetException: Exception e) {
 throw new CantInvokeException(e);
} catch (SecurityException, NoSuchMethodException: Exception e) {
 throw new CantFindMethodException(e);
}

Máme možnost specifikovat libovolný počet typů vyjímek, které chceme odchytit jediným catch příkazem, za seznam přidáme dvojtečku a specifikujeme typ proměnné (v našem případě je nejbližším společným předkem výjimek typ Exception, který je zároveň typem proměnné e). Kloním se k variantě, že programátor musí specifikovat typ proměnné, nenechával bych to na překladači.
Co znamená dodatek při zachování typu výjimky z názvu kapitoly? Pokud bychom kód z předchozího úryvku změnili na:

try {
 invokeMethod("A");
} catch (IllegalArgumentException, IllegalAccessException, 
 InvocationTargetException: Exception e) {
 //něco
 throw e;
} catch (SecurityException, NoSuchMethodException: Exception e) {
 //něco jiného
 throw e;
}

a uvedli ho v metodě se stejnou klauzulí throws jako má metoda invokeMethod, pak bude vše v pořádku. Překladač se nebude zlobit, že se snažíme vyhodit výjimku typu Exception z metody, která ji nemá uvedenou ve throws, protože proměnná e je typu Exception, ale může nabývat pouze hodnot typů uvedených před dvojtečkou. Samozřejmě musí být final (není tak uvedená, ale je).

Závěr

Obě tyto vychytávky rozhodně nezesložití jazyk, a když tak jenom nepatrně. Ale přinesou bezesporu větší čitelnost řadě algoritmů. To je přínos, který jednoznačně stojí minimálně za zamyšlení.

Nová Java: Chceme ji?

2007-12-21T21:31:00.000+01:00

Zamýšlel jsem se nad myšlenkou, změny jazyka Java tak, aby lépe odrážel dnešní potřeby a obsahoval moderní prvky představené především ve skriptovacích jazycích. V poslední době se objevilo pár příspěvků na toto téma, na jedné straně příznivci změn reprezentovaní například JavaPosse #151 a na straně druhé spíše odpůrci, např. Dagi.

Já se spíš stavím za to, aby se jazyk vyvíjel a měnil. Jsem přesvědčen o tom, že požadavky kladené na dnešní "moderní" programovací jazyky jsou diametrálně odlišné od požadavků kladených před oněmi 12 lety, kdy byla Java představena.

Co považuji za nejdůležitejší změnu? Jednoduše použitelná podpora programování multithreadových aplikací. Jistě od roku 1995 máme synchronized, nyní již máme i java.util.concurrent. Do Javy 7 se blíží implementace fork-join algoritmu (pod vedením JSR 166), ale stále si myslím, že je to málo.

Proč chci víc? Programování multithreadových aplikací je stále složitá věc, rozhodně to není pro široké masy programátorů. A dneska je každý nový počítač více-procesorový a abychom využili jejich schopností, pak potřebujeme multithreadovou aplikaci.

Kde bych hledal inspiraci? Co třeba programovací jazyk X10. Ten je dokonce překládán do Javy. Obsahuje řadu konstruktů, které k programování fork-join konstruktů přímo vybízejí (async, atomic, finish, when, atd.).

Myslím, ře prostorů, ve kterých by se Java mohla zlepšovat je jistě nepřeberné množství, a Java bude muset tuto hozenou rukavici zvednout.

Eclipse, Mylyn, IntelliJ IDEA a Teamcity v CZPodcast #19

2007-12-07T07:39:00.000+01:00

Ještě jsem poslední (#19) CZ Podcast nedoposlouchal celý, ale když se věci začali točit okolo Eclipse Mylynu, tak bych si troufl provést malé doplnění. Mylyn už nějaký pátek (přesně už to bude přes čtvrt roku) používám a už se dlouho chystám, že se s vámi podělím o své, ve skrze pozitivní, zkušenosti, ale nějak nenacházím tolik potřebnou sílu ...

Takže Teamcity, není Mylyn, ale je to skutečně Continuous Integration server. Mylyn má ve skrze 3 oblasti, kam upírá svou pozornost:

práce s bug tracking systémem, plánování požadavků, jejich zobrazování, ukládání kontextu k nim atd.
zaměření prostředí na zobrazování pouze relevantních informací v IDE (týkajících se aktuálně zpracovávaného požadavku) = založeno na kontextu, jenž se dá k požadavku uložit - především se to týká filtrování toho, co není k právě realizovanému požadavku relevantní
vytváření change setů pro commit do subversion (CVS) na základě kontextu

Co je mi známo, pak IDEA má podporu pro podobnou věc, ale není navázána na bug tracking systém (tj. požadavky si vytváříte ručně) a UI projektu se nijak nemění (nezaměřuje). Tj. sleduje, který soubor se modifikuje a pak vytváří change set pro commit zdrojáků. Podporuje přepínání požadavků a vytvoření správných change setů podobně jako Mylyn.

Sice IDEAu nepoužívám, a nikdy neříkej nikdy .. Třeba mě tento příspěvek nakopne, abych sepsal ten MYLYN.

Unit testy - ty přece píše kodér, ne?

2007-11-30T07:34:00.000+01:00

Tentokrát spíš chci prodiskutovat jedno téma, než vám něco sdělit. Právě jsem dočetl článek Akshay Sharmi o návrhu, který myslí na testovatelnost kódu (Design to Unit Test). Jediná věc, která mě na tomto článku přímo praštila do očí, je skutečnost, že je psán tak, jako že unit testy píše někdo jiný, než ten, kdo testovaný kód psal.

Já jsem vždy přemýšlel o unit testech jako o věci, kterou si kodér ověřuje, že jeho kód funguje tak, jak má. Navíc si kodér musí již dopředu rozmyslet, jak svůj kód otestuje, což bezesporu vede k jeho větší kvalitě. V neposlaení řadě unit testy vnímám také jako "dokumentaci" ke kódu, což v případě, že je píše někdo jiný opět selhává.

Je pravdou, že psaní testů je trochu jiná káva, než psaní kódu. Je nutné se to naučit. Ale není to zase tak složité. V případě integračních a akceptačních testů je již zřejmé, že je může (nebo má?) implementovat někdo jiný než kodér.

Obávám se, že tento přístup není pro mě. Navíc bych si troufl s ním nesouhlasit.

XML Signature - použít nebo ne?

2007-11-29T23:00:00.000+01:00

V naší aplikaci přenášíme poměrně velké XML soubory a přenášíme jich více najednou. Proto jsou zazipované v ZIP archivu. Ovšem potřebujeme nějak zabezpečit, aby nebylo možné měnit obsah archivu (tj. nemožnost přidávat či mazat soubory) a dále aby nešlo měnit jednotlivé XML soubory. Navíc tato komunikace neprobíhá mezi naším softwarem, ale mezi naším a cizím. Jak věc vyřešit?

Použít XML Signature (specifikace) nebo ne? Než jsem se pustil do zkoušení hledal jsem na netu a našel jsem pár mailů v konferencích a blogů, že XML Signature implementace nefunguje dobře na "large documents". Už jsem přemýšlel o vlastním řešení, kde bych hashoval XML soubory jako stream bytů, nebo bych vytvořil nějaký vlastní algoritmus pracující přímo nad SAXem, který používáme jak pro čtení tak i pro zápis dokumentů. Ale nakonec jsem si řekl, že to zkusím přímo s XML Signature a šáhl jsem po implementací, která je součástí JDK 6. Pro XML Signature hovoří skutečnosti, že je to standard (nemusím specifikovat jak se podpis vypočítá) a existuje implementace pro skoro všechny rozšířené jazyky.

Napsal jsem tedy velmi jednoduchou třídu XMLSignatureTest (při jejím psaní jsem převážně vycházel z příkladu v XML Digital Signature API Examples):

public class XMLSignatureTest {

   protected static final String KEY_ALIAS = "ALIAS";

   public static void main(String[] args) {
      try {
         long milis = System.currentTimeMillis();
         if ("sign".equals(args[0])) {
            signing(new File(args[1]), new File(args[2]));
         } else {
            System.out.println(verify(new File(args[1])) ? "Verified - ok" : "Changed");
         }
         System.out.println("Done in " + (System.currentTimeMillis() - milis) + " ms.");
      } catch (Throwable t) {
         t.printStackTrace();
      }
   }

   protected static void signing(File xmlFile, File signatureFile) throws Exception {
      //načti vstupní XML dokument
      DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
      dbf.setNamespaceAware(true);
      DocumentBuilder builder = dbf.newDocumentBuilder();
      Document doc = builder.parse(new FileInputStream(xmlFile));

      //otevři keystore a načti z něj privátní klíč k podpisu hashe
      KeyStore keyStore = KeyStore.getInstance("JKS");
      keyStore.load(new FileInputStream("keystore"), "XMLSig".toCharArray());
      PrivateKey key = (PrivateKey) keyStore.getKey(KEY_ALIAS, "MEkeypwd".toCharArray());

      //nadefinuj context podpisu
      DOMSignContext dsc = new DOMSignContext(key, doc.getDocumentElement());
      XMLSignatureFactory fac = XMLSignatureFactory.getInstance("DOM");
      
      //podepiš celý dokument, na canonicalizaci použij metodu INCLUSIV, jako hash použij SHA1 algoritmus
      //podpis bude vložen do podepisovaného dokumentu a výsledný hash bude zakryptovát DSA klíčem 
      Reference ref = fac.newReference("", fac.newDigestMethod(DigestMethod.SHA1, null), 
            Collections.singletonList(fac.newTransform(Transform.ENVELOPED, (XMLStructure) null)), 
            null, null);
      SignedInfo si = fac.newSignedInfo(
            fac.newCanonicalizationMethod(CanonicalizationMethod.INCLUSIVE, (XMLStructure) null), 
            fac.newSignatureMethod(SignatureMethod.DSA_SHA1, null), Collections.singletonList(ref));

      //do podpisu jako informaci o použitém klíči vložíme jeho alias
      //tj. obě strany se musí domluvit na aliasech a předat si veřejné klíče
      KeyInfoFactory kif = fac.getKeyInfoFactory();
      KeyName kn = kif.newKeyName(KEY_ALIAS);
      KeyInfo ki = kif.newKeyInfo(Collections.singletonList(kn));

      //spočítej podpis
      XMLSignature signature = fac.newXMLSignature(si, ki);
      signature.sign(dsc);

      //ulož výsledný dokument do souboru
      OutputStream os = new FileOutputStream(signatureFile);
      TransformerFactory tf = TransformerFactory.newInstance();
      Transformer trans = tf.newTransformer();
      trans.transform(new DOMSource(doc), new StreamResult(os));
      os.flush();
      os.close();
   }

   protected static boolean verify(File xmlFile) throws Exception {
      //načti XML document s vloženým podpisem
      DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
      dbf.setNamespaceAware(true);
      DocumentBuilder builder = dbf.newDocumentBuilder();
      Document doc = builder.parse(new FileInputStream(xmlFile));

      //najdi v dokumentu podpis
      NodeList nl = doc.getElementsByTagNameNS(XMLSignature.XMLNS, "Signature");
      if (nl.getLength() == 0) {
         throw new Exception("Cannot find Signature element");
      }

      //otevři keystore pro načtení veřejného klíče
      KeyStore keyStore = KeyStore.getInstance("JKS");
      keyStore.load(new FileInputStream("keystore"), "XMLSig".toCharArray());

      //vytvoř validační kontext (node s podpisem a KeySelector pro získání 
      //klíče podle identifikace v podpisu - v našem případě je to ALIAS)
      DOMValidateContext valContext = 
         new DOMValidateContext(new KeyNameKeySelector(keyStore), nl.item(0));
      XMLSignatureFactory factory = XMLSignatureFactory.getInstance("DOM");
      XMLSignature signature = factory.unmarshalXMLSignature(valContext);

      //ověř podpis
      return signature.validate(valContext);
   }

   //tato třída slouží k nalezení veřejného klíče použitelného k odkryptování podpisu
   private static class KeyNameKeySelector extends KeySelector {
      protected KeyStore keyStore;

      public KeyNameKeySelector(KeyStore keyStore) {
         super();
         this.keyStore = keyStore;
      }

      //tato metoda je volána knihovnou
      public KeySelectorResult select(KeyInfo keyInfo, KeySelector.Purpose purpose, 
            AlgorithmMethod method, XMLCryptoContext context) throws KeySelectorException {

         if (keyInfo == null) {
            throw new KeySelectorException("Null KeyInfo object!");
         }
         SignatureMethod sm = (SignatureMethod) method;
         List list = keyInfo.getContent();

         for (int i = 0; i < list.size(); i++) {
            XMLStructure xmlStructure = (XMLStructure) list.get(i);
            //my hledáme klíč podle jména (aliasu)
            if (xmlStructure instanceof KeyName) {
               try {
                  //natáhnem veřejný klíč z keystoru
                  Certificate certificate = keyStore.getCertificate(((KeyName) xmlStructure).getName());
                  PublicKey pk = certificate.getPublicKey();
                  //ověříme, že v podpisu je stejný algoritmus jako používá klíč
                  if (algEquals(sm.getAlgorithm(), pk.getAlgorithm())) {
                     return new SimpleKeySelectorResult(pk);
                  }
               } catch (KeyStoreException kse) {
                  throw new KeySelectorException(kse);
               }
            }
         }
         throw new KeySelectorException("No KeyValue element found!");
      }

      //pouze porovnává algoritmy
      static boolean algEquals(String algURI, String algName) {
         if (algName.equalsIgnoreCase("DSA") 
               && algURI.equalsIgnoreCase(SignatureMethod.DSA_SHA1)) {
            return true;
         } else if (algName.equalsIgnoreCase("RSA") 
               && algURI.equalsIgnoreCase(SignatureMethod.RSA_SHA1)) {
            return true;
         } else {
            return false;
         }
      }

      //jenom holder pro klíč
      private static class SimpleKeySelectorResult implements KeySelectorResult {
         private Key pk;

         SimpleKeySelectorResult(Key pk) {
            this.pk = pk;
         }

         public Key getKey() {
            return pk;
         }
      }

   }

}

Úpravy spočívají pouze v použití key-storu pro získání klíču a nepřenášení veřejného klíče v podpisu, ale pouze jeho aliasu.

A nyní k samotným testům. Zajímal jsem se o dva faktory: rychlost a peměťová náročnost.

Takže nejprve jsem test prováděl na XML dokumentu o velikosti 6,5 kB. Výpočet podpisu i ověření proběhlo i s nejmenším možným heapem, tj. 2M (1M nestačilo ani na nastartování JDKčka) a výpočet podpisu a serializace trvala 0,6 s. Co se verifikace podpisu týče, došel jsem k úplně stejnému číslu.

Následně jsem přitvrdil a použil jsem soubor o velikost 4,1 MB. Minimální heap, nad kterým jsem se dobral výsledku a nedostav pouze OOM exception byl 53MB a výpočet podpisu včetně serializace výsledku trval 10s, ověření podpisu trvalo pouze 4,8s a dokonce potřebovalo minimálně pouze 47MB. Při použití heapu o velikosti 400MB jsem se u podpisu dostal na čas 4,8s a u ověření na 2,8s.

Závěr

V podstatě jsem byl velmi mile překvapen, jak vše hladce a na první pokus proběhlo a spíš jsem hledal skulinu, jak XML Signature použít. Z prvu mi vadilo, že je nutné použít DOM, protože používáme SAX (a použít Transaformer se vstupem SAXSource a s výstupem DOMResult se mi nechtělo). Pak jsem si uvědomil, že bych stejně nemohl výpočet podpisu zařadit přímo do zpracování dokumentu, protož zpracování může trvat i dost dlouho (třeba i desítky minut). Souborů se může zpracovávat více najednou. Pokud by každý, nedejbože, byl rovnou podepisován a vytváření podpisu by si slízlo 50MB heapu, pak bych měl na serveru pamět jenom pro podepisování.

Nakonec jsem se rozhodl, že prvním krokem zpracování bude načtení dokumentu pomocí DOM a ověření podpisu. Následně teprve, pokud bude vše v pořádku, budu dokument načítat pomocí SAX (do budoucna stejně přejdeme na StAX) a dokument budu zpracovávat a zároveň budu generovat výstup (také pomocí SAX) a ten budu serializovat do souboru. Na závěr výstupní soubor načtu pomocí DOM a vygeneruju podpis.

V neposlední řadě, tak trochu pod čarou, zmíním canonicalizaci, která funguje opravdu pěkně, přidávání mezer, nových prázdných řádků, přehazování pořadí atributů neovlivní platnost podpisu.

JavaScript a Dependency Injection

2007-11-19T21:04:00.000+01:00

Všichni jste už asi slyšeli o Spring IoC, Picocontaineru, HaveMindu či Tapestry IoC. Ale což takhle IoC pro JavaScript?

Ano je to možné. Jmenuje se Squirel Ioc. Jedná se o velmi jednoduchou knihovna, která má 4kB a používá jQuery.

Použití je velmi jednoduché (jak už se v mých příspěvcích stalo pravidlem). Máme následující třídy, které budeme propojovat:


function MyModel(){
  //obsah třídy MyModel
}

function MyDAO(model){
  var _model=model;

  this.get = function() { 
    return _model;
  }
    
  this.save = function() { 
    //uloz
  }
    
  this.delete = function() {
    //smaz
  }
}

function MyService(){
  var _dao = null;
    
  this.get = function() {
    return _dao.get();
  }
    
  this.getDao = function() {
    return _dao;
  }
    
  this.setDao = function(dao) {
    _dao = dao;
  }
}

function MyApp(){
  var _service=null;                 
  //rikame IoC containeru, ze az vse nastavi, ma zavolat metodu onContextSupport
  ContainerSupport.call(this);        
    
  this.onContextSupport = function(containerContext){  
    var model=_service.get();
    //udelej cokoliv dalsiho s hodnotou ...
  }
    
  this.setService = function(service){
    _service = service;
  }
}

Z pohledu IoC v Javě máme POJO objekty a teď je potřebuje spolu nějak svázat (ve Springu se k tomu např. používá xml soubor nebo anotace). Při použití Squirrel IoC nám poslouží velmi jednoduchý kód:

var definition={
  'model':{type:MyModel},
  'dao':{type:MyDAO,args:[{ref:'model'}]},
  'service':{type:MyService,props:[{name:'dao',ref:'dao'}]},
  'app':{type:MyApp,props:[{name:'containerContext',ref:'containerContext'},{ref:'service'}]}
  };

    
  var container = new IContainer();
  container.load(definition);

V příkladu je vidět constructor injection (na příkladu definice dao objektu) či setter injection (na příkladu objektu service).

Když to funguje v Javě, proč ne v JavaScriptu. Opět se ukazuje jednoduchost, kterou nám JavaScript jako dynamický jazyk nabízí. A příště až budete potřebovat propojit pár objektů mezi sebou, zamyslete se, zda vám Squirrel Ioc neusnadní práci.

Nejde říci co je cennější, zda znalosti nebo zkušenosti

2007-11-10T22:43:00.000+01:00

Jak je naznačeno v příspěvku Znalosti a zkušenosti, zkušenost je víc než znalost.

Podle mě jde hlavně o rozdíl mezi znalostí a zkušeností. Znalosti jsou laciná věc. Stačí zajít do školy, projít si pár článku na internetu a nebo nedej bože přečíst knihu. Pokud máte funkční paměť nejen v počítači ale i v hlavě, tak znalosti nabudete velice snadno.

A hned jsem si vzpomněl na strýčka z Jirotkova Saturnina, který měl malou chemickou továrnu a nebyl vzdělán v oboru, na všechno si přišel sám. Vše co bylo napsáno v moudrých knihách on složitě vymýšlel. Neměl žádné znalosti, ale nespočetně mnoho zkušeností. Bohužel, vždy když vyráběl nové mýdlo, netušil co se mu v kádích uvaří ...

Jsou to zkušenosti co se počítá. Můžu si přečíst kolik knih chci o tom jak se mají správně dělat softwarové projekty. Dokud to ale nezažiji na vlastní kůži, mají tyto znalosti malou váhu (bojím se že nulovou). Zkušenosti mají také jednu obrovskou výhodu. Málo stárnou. Když mám zažito jak psát software, jaká pravidla dodržovat a čeho se vyvarovat, je mi více méně jedno jakou technologii používám. Detaily si dokáži nastudovat.

Není přeci nutné mít zkušenost s popáleninou od rozpálených kamen, když mám znalost, že to je dost hrozné. Zkušenost dává znalostem rozměrem. Dává jim ten osobní kontakt s nimi. Ale zároveň nám umožňuje tento rozměr v budoucnu dát znalostem přímo, bez zkušenosti. Znalost nás směřuje správným směrem a zaměřuje naše zkoumání a vytváření zkušeností k užitečným cílům.

A teď musím navázat na Vlastůvovu reakci Co se počítá, ve které zase uhodil hřebíček na hlavičku (jak on to dělá?). Nejde o to, jak své dovednosti získáme, či zkušeností nebo znalostí, každý jsme jiný (někomu vyhovuje si přečíst referenční příručku, někdo jiný si věc raději osahá), ale jde o to, jak svých schopností využijeme k plnění cílů, které jsou nám předkládány.

Takže čtěme, vzdělávejme se, nebojme se poučit od druhých, zkušenějších, berme jejich rady vážně, protože jenom tak nezopakujeme chyby, kterých se dopustili, a získáme více drahoceného času. A třeba to dotáhneme ještě dál než oni.

A je to tady - XQuery Update v pureXML

2007-11-01T22:48:00.000+01:00

Kdo si počká, ten se dočká. Od včera je možné si stáhnout IBM DB2 UDB 9.5. A proč tolik povyku. Kromě mnoha další vylepšení, je konečně implementován i draft XQuery Update Facility. Asi nebudu sám, kdo cítil velký nedostatek v nemožnosti updatovat část XML dokumentu uloženého pomocí pureXML.

Nebudu dlouho běhat okolo horké kaše a ukážeme si pár příkladů.

Máme tabulku friend, která má sloupec info. V této tabulce máme jeden záznam:

<friend>
  <name>Jiri Mares</name>
  <phone type="work">222 222 222</phone>
  <phone type="home">333 333 333</phone>
</friend>

A nyní si ukážeme prostou změnu mého čísla do práce (využiji skutečnosti, že mám v tabulce jeden řádek a vypustím klauzili where z SQL update příkazu):

update friend
set info = xmlquery( 'copy $new := $INFO
  modify do replace value of $new/friend/phone[@type="work"] with "111 111 111"
  return  $new');

Což přidat telefon na mobil:

update friend
set info = xmlquery('copy $new := $INFO
  modify do insert <phone type="cell">444 444 444</phone>
     as last into $new/friend
  return  $new' );

Nebo můžeme přejmenovat tag name na full-name:

update friend
set info = xmlquery('copy $new := $INFO
  modify do rename $new/friend/name as "full-name"
  return  $new' );

Dále jsem neukázal mazání nodu:

update friend
set info = xmlquery('copy $new := $INFO
  modify do delete $new/friend/phone[@type="cell"]
  return  $new');

Můžeme nahradit více tagů najednou:

update friend
set info = xmlquery(' copy $new := $INFO
  modify (
     do replace value of $new/friend/phone[@type="home"] with "999 999 999",
     do replace value of $new/friend/phone[@type="work"]/@type with "cell")
  return  $new' );

Začíná se mi XQuery líbit čím dál tím víc, je jednoduché, čitelné, skoro bych řekl sexy :-).

Na závěr nutno říci, že XQuery Update nemusíte používat jenom při SQL updatu, ale i v selectu. Takže pokud nechcete vracet uživateli hodnotu telef. čísel na mobil, pak stačí udělat dotaz:

xquery copy $new := db2-fn:sqlquery("select info from friend")
modify  for $j in $new/friend/phone[@type="cell"] return
  do replace value of $j with "XXX XXX XXX"
return $new;

A co mě ještě v pureXML zaujalo

Je toho hodně nového, ale ... zajímavá je rychlost, takže je fajn, když se XML dokument může uložit ve stejné stránce jako ostatní sloupce řádku tabulky, protože celý řádek je k dispozici pomocí jediné I/O operace (i když platí omezení na velikost XML dokumentu max. 32k - nebojte, je-li dokument větší, neznamená to chybu, ale pouze se standardně uloží do XDA).

Zajímavá je intergrace XSLT enginu přímo do DB2 (když už je XML uloženo v podobě stromu, přímo si to o tuto integraci říká). Díky nové funkci parameter padá nemožnost předávat parametry do sqlquery funkce. A další ...

Programujeme nebo lepíme

2007-10-26T22:02:00.000+02:00

Přiložím si také trochu do mlýna k diskusi, zda jsou vizuální nástroje dobré nebo špatné. Diskuse se nejprve rozvinula v konferenci konference@java.cz, na to se GUI nástrojů zastal Dagi v příspěvku Potřebujeme silné nástroje a následně Pavel Kolesnikov přidal Potřebujeme domyšlené nástroje. Já se chci trochu vrátit k jádru pudla, zda GUI nástroje ano nebo ne.

Na úvod se přiznám, že nejsem velký přívrženec GUI klikátek, asi už jsem z moc starý školy a jsem moc zakořeněnej v unix shellu. Ale napadlo mě, že dneska už vlastně tolik neprogramujem, spíš skládáme (lepíme) dohromady existující kousky. Však se potichu šušká, že vše už bylo alespoň jednou napsáno.

Ale jaký je rozdíl v použití haldy frameworků, které vše řeší za mě, či GUI klikátka, které ten kód vygeneruje? Ja si myslím, že v podstatě rozdíl není. Cíl je stejný, ale cesta je různá. Mám aplikaci a nemusím moc programovat.

Takže proč vzbuzují GUI klikátka negativnější pocity (alepoň v některých lidech, např. jako já) než frameworky. Za sebe mohu říci že, když jsem je používal já, tak mi hezky zpívaly když mě lapaly. A když jsem je začal používat a následně jsem je potřeboval, pak mě hodily přes palubu, protože složitější věci nešlo realizovat, jak jsem chtěl. A já nerad ustupuju.

A jaký je tedy závěr? I nadále programujeme, ale stále více se uchylujeme k lepení. A zda lepíme pomocí GUI klikátek nebo ne, to si musí každý rozhodnout sám, ale já jsem se rozhodl: "Raději ne, děkuji".

PS: Nejlepším lepidlem posledních let jsou anotace. Abychom se do toho lepidla, ale nezalepili sami.

Architektura naruby

2007-10-25T08:18:00.000+02:00

Právě jsem si přečetl Dagiho příspěvek Do pranice: Spring Web Flow a nebo JBoss Seam a nemohl jsem se nepřidat se stížností na dnešní frameworky. Už toho mám dost, jak se neustále pod rouškou jednoduššího vývoje a já nevím čeho všeho porušují základní pravidla vrstvení aplikace: nižší vrstva nemá vědět, ža nad ní je nějaká vrstva vyšší a využívat pouze služeb svých a nebo služeb vrstev pod ní.

JBoss Seam je úplně klasickým příkladem této šílenosti, protože vrstvy nižší (v tomto případě např. session beany) jsou oanotovány vším možným co se týká jejich komunikace s JSF (přes Seam) jako vrstvou vyšší. Cestou ven je samozřejmě použití XML konfigurace, ale ta se v souvislosti se Seamem skoro neprezentuje.

Z podobného důvodu používám s Hibernate vždy XML konfiguraci. Prostě nechci aby můj model byl zaneřáděn anotacemi, které ke své funkci vůbec nepotřebuje. Mapování uložení do DB je přeci věc DAO vrstvy a model se o něj rozhodně nemá starat.

Ano, je to složitější, pracnější, ale rozhodně je to flexibilnější. Řada čtenářů my možná namítne, že na to není čas, že je jim tato flexibilita na nic atd. Je to každého věc, ale já mám flexibilitu rád a nevzdám se jí. Navíc mám rád pokud je kód přehledný, hezky strukturovaný a provázaný jenom jedním směrem, shora dolů a ne i naopak.

Jednoduše na CSS Sprite

2007-10-22T11:11:00.000+02:00

O CSS Sprite už jsem psal v příspěvku Zaměřte se na fronted, takže jenom z rychlíku. Jedná se o více obrázků rozložených v jednom velkém, které jsou následně pomocí CSS backgroup zobrazovány. Získává se tím větší výkon stránky, protože pro její zobrazení není nutné natahovat 30 malých obrázků (=30 requestů), ale pouze jeden větší.

A já vám nyní předkládám odkaz na stránku, kde si takový CSS Sprite můžete vytvořit. Zazipujte své malé obrázky, uploadněte je a získáte zpět jeden velký. Proč se s tím pachtit v GIMPu.

Jak na vlastní design File Input položek formulářů

2007-10-19T08:13:00.000+02:00

Každý již jistě někdy psal stránku, která umžňovala upload nějakého souboru. To je problém celkem jednoduše řešitelný, ovšem problém nastává, pokud máte nějaký design tlačítek na stránce a chcete, aby i tlačítko pro výběr souboru mělo jednotný design. A zde se už naráží.

Ovšem i toto je věc řešitelná (ve světě počítačů snad neexistují neřešitelné problémy). Celý postup názorně popisuje Shaun Inman ve svém blogu. V principu jde o kombinaci CSS, DOM a JavaScriptu.

Funguje to tak, že se input obalí wrapper-tagem (např. label), jemuž se nastaví pozadí na námi požadovaný vzhled. Následně se nastaví neprůhlednost (opacity) tagu input na 0, čímž se zneviditelní, ovšem stále je klikatelný. No a zavěrečný krůček nám pomůže udělat JavaScript, kterým zařídíme, že tlačítko pro výběr souboru bude vždy umístěno pod ukazatelem myši, pokud je uvnitř našeho wrapper-tagu.

A teď v jakých prohlížečích to funguje? Překvapivě IE 5.5+, Firefox 1.5+, Safari 2+. Uspokojivě je použitelné v IE 5.01 a Opeře.

Jak ovládat Eclipse pomocí prohlížeče

2007-10-18T20:02:00.000+02:00

O Eclipse RAP se už blogovalo (např. dagi), ale o integraci Eclipse s prohlížečem zatím ne. Celé se to jmenoje Web Broser-Based Integration with Eclipse IDE, a jde o skutečné ovládání Eclipse pomocí prohlíče. Nainstalujete speciální plugin včetně Jetty serveru a to je celé. V nastavení eclipse spustíte server, do prohlížeče (pozor celé to funguje pouze ve Firefoxu) zadáte adresu http://localhost:9008/ a zobrazí se vám váš Eclipse.

A takhle vypadá originál:

Celé to funguje velmi jednoduše, skoro se mi chce napsat trapně jednoduše, UI Eclipsu se překládá do XUL Firefoxu, který jej pak zobrazuje.

Zatím je to jenom preview, ale možnosti jsou opravdu velmi široké, od přístupu ke své Eclipse instalci pomocí prohížeče (či k centrální instalaci s definovanými pluginy a projekty), při podpoře více uživatelů (zatím chybí) dokonce může více uživatelů sdílet jednu instalaci Eclipse až po vývoj webových aplikací pomocí Eclipse RCP.

Vývoj aplikace za běhu

2007-10-12T20:30:00.000+02:00

Dostala se mi pod nos opravdu zajímavá věcička, která si říká JavaRebel. O co se jedná? Jedná se o udělátko, které za běhu aplikace dokáže reloadovat třídy. A pozor, nepoužívá k tomu class loader (tak problém řeší Howard Lewis Ship pro Tapestry 5) ani hot swap (jenž je v javě od verze 1.4).

Ale jak to tedy dělají? Jak sami říkají, pomocí změny bytecodu a trochu kouzel. Každopádně JavaRebel podporuje všechny změny tříd až na změnu v dědičnosti (tj. extends a implements). Dá se použít jak při vývoji webových tak klientských aplikací.

Po Terracotte je to další technologie, která používá manipulace s bytecodem k docílení až zázračných věcí.

Jediné mínus je, že se jedná o komerční produkt, a stojí 100$ na vývojáře. Ovšem to je investice, která se vrátí snad už za týden.

Odkazy

JavaRebel Screencast

Kam se ztrácí zkušení programátoři

2007-10-08T21:59:00.000+02:00

Přečetl jsem si velmi zajímavý článek API: Design Matters od Michi Henninga. Je velmi poučný a vhodně doplňuje prezentaci Jaroslava Tulacha Jak psát API, které přežije nástrahy času (slidy, video). Takže rozhodně si ho přečtěte, protože API navrhuje každý z nás.

Ovšem co mě skutečně praštilo do očí je jedna z posledních kapitol, která se designem API zaobírá spíše okrajově. Hovoří o tom, že zkušení programátoři (a v podstatě i designéři či architekti) přestávají existovat. Jak je to možné?

Upřímně kolik znáte programátorů, kterým je přes 40? Já jsem zatím poznal tři (a zkušenost je jednoznačně pozitivní), takže mladší jednoznačně převládají. Proč? Protože je sociální tlak, aby programátor skončil s programováním včas a přeorientoval se na designéra nebo architekta, v nejhorším případě na project managera, protože přeci nemůže na ty mladé kluky, co se nové technologie učí na škole, stačit.

Ovšem co umí mladý kluk, když opouští univerzitu. Umí minimálně 5 programovacích jazyků (což by jistě s knihou a chvilkou času zvládl i bez učitele), umí řadu děsně zajímavých algoritmů, které většinou nikdy nepoužije a když tak velmi vyjímečně. Ale to co by měl používat denně: objektový design, psaní přehledného kódu, test driven development, code coverage, continuous integration, nedej bože jiné metodiky vývoje než vodopád (nejlépe scrum). To nezná.

A kde je problém designérů a architektů? Jsou drazí a je jich málo. Proto nemohou na projektu zůstávat po celý jeho životní cyklus a tím se odtrhávájí od reality, protože netuší jaké dopady mají jejich rozhodnutí. Chybí jim zpětná vazba.

Takže kdeže jsou ti zkušení? Neexistují ...

Velmi jednoduchá validace HTML formulářů JavaScriptem

2007-10-04T23:09:00.000+02:00

Dneska mi padla do oka velmi jednoduchá knihovnička na validování HTMl formulářů pomocí JavaScriptu - JSValidate. V podstatě bych řekl, že se mi víc líbí nápad, jak jsou položky formuláře označovány na co mají být validovány, než samotná knihovna, protože obsahuje validaci pouze JavaScriptem, tj. na klientu, a to je pro mě málo.
A co je to tedy za nápad? Prostě a jednoduše položky formuláře, tj. input tagy označíte CSS třídou podle toho, jak jej chcete validovat a přidáte následující 3 řádky na začátek stránky:

<script type="text/javascript" language="javascript" src="scriptaculous/lib/prototype.js"></script>
<script type="text/javascript" language="javascript" src="scriptaculous/src/scriptaculous.js"></script>
<script type="text/javascript" language="javascript" src="jsvalidate.js"></script>

A jste hotovy.

Příklady

Jednoduchá položka, jejíž hodnota je povinná:

<input type="text" name="name" class="jsrequired" />

Nebo položka pro číslo:

<input type="text" name="number" class="jsvalidate_number" />

A nebo položka na email, který je nutné zadat:

<input type="text" name="email" class="jsrequired jsvalidate_email" />

Jaké jsou dostupné třídy

jsrequired - musí být vyplněna
jsvalidate_number - číslo
jsvalidate_digits - pouze číslice
jsvalidate_alpha - pouze písmena
jsvalidate_alphanum - písmena, číslice a podtržítko
jsvalidate_email - email
jsvalidate_uscanzip - ZIP code USA nebo Kanady
jsvalidate_usstate - 2 znakový kód státu v USA
jsvalidate_usphone - telefonní číslo v USA
jsvalidate_creditcard - číslo kreditní karty
jsvalidate_ssn - Social Security Number - číslo sociálního pojištění (USA)
select-notfirst - používá se u selectů, kde zajistí, že první položka ze seznamu nemůže být vybrána

Závěr

Myslím, že existuje problém, kde se tato knihovná dá nasadit. Asi to nebude do žádné větší aplikace, kde bude na validační framework kladen podstatně větší nárok, především mám na mysli prováznost s validací na serveru.
Co se mi jeví jako hodně zajímavé je využití CSS tříd pro identifikaci, to je velmi jednoduché a elegantní.

Odkazy

Příklady

Zaměřte se na frontend

2007-09-17T21:57:00.000+02:00

Potřebujete zvýšit výkon vašich stránek z pohledu koncového uživatele? Zaměřte se na frontend, ne na backend. To je obsah prezentace Steva Sounderse z Yahoo. A proč? Při analýze výkonu Yahoo stránek se ukázalo, že pouze 12% z doby potřebné pro zobrazení stránek je čas strávený generováním obsahu na serveru. Zbytek je přenos dat a práce klienta. Tento průzkum byl potvrzen na výkonu 9 z 10 TOP10 amerických webů, kdy více jak 20% zlepšení v rychlosti zobrazení stránek po natažení všeho cachevatelného do cache zaznamenal pouze Google.

A jaké jsou tedy rady:

čím méně HTTP requestů, tím lépe - spojujte jvascriptové a CSS soubory, používejte CSS Sprites
používejte CDN (Content Delivery Network) - distribuujte nejprve statický a pak dynamický obsah
používejte Expires hlavičky - umožní cachování obsahu
gzipujte posílaný obsah - 90% klientů podporuje kompresi obsahu pomocí gzipu, využijte jej
CSS stylesheety dejte na začátek stránky - IE zobrazí stránku, až když má nateženy všechny stylesheety, proto je nutné je začít stahovat co nejdřív
javascript naopak dejte na konec - máte-li javascript inline v dokumentu, pak blokuje renderování něčeho viditelného, je-li jako externí soubor, pak blokuje (především v IE) stahování něčeho vizuálního
nepoužívejte CSS výrazy - něco jako width: expression (document.body.clientWidth < 600 ? "600px" : "auto"); příšerně zpomaluje stránku, protože takový výraz se vyhodnocuje pořád (při pohybu myši, při stisku klávesy, ...)
CSS a javascript mají být v externích souborech - sice přidávají HTTP request, ale mohou být cachovány
minimalizovat počet DNS lookupů
Minify Javascript (případně obfuscate) - zmenší objem javascriptu, ale nemění funkci
vyvarujte se redirectů - zablokují renderování stránky a oddalují jej
odstraňte duplicity - ve scriptech, stylesheetech, ...
snažte se používat ETags
udělejte AJAX cachovatelný - i requesty prováděné pomocí AJAX by měly být cachovány

Musím říci, že tato prezentace byla pro mě překvapující, protože bych čekal, že za zvýšením výkonu stránek bude nějaká magická serverová technologie nebo vychytávka. A ejhle ono ne. Je pravda, že na přizpůsobení stránek rychlejšímu zpracování na klientu se moc velká pozornost nevěnuje, zde je taková malá kapesní kuchařka.

Tento příspěvek je spíše lákáním na shlédnutí ani ne 40 min prezentace, jistě je to zajímavé poslouchání.

PS: v prezentaci se hovoří o plugin do Firefoxu YSLOW, který analyzuje stránky a říka proč jsou pomalé, rozhodně stojí za vyzkoušení, jistě se dozvíte zajímavé věci.

Code review je jistě užitečná věc

2007-09-17T20:23:00.000+02:00

Když jsem si přečetl dagiho příspěvek o code review vyskočil jsem jak čertík z krabičky. Než jsem došel domu, málem jsem na své rozhodnotí reagovat zapomněl, ale už jsem si zase vzpomněl.

Jsem zvyklý code review používat a považuji jej za skvělou věc. Ovšem nejprve co to je code review? Jak jej vnímám já, není to kontrola, že kód splňuje nějaký coding standard, není to náhrada testů, tj. kontrola správnosti (ve smyslu fungování) a ani to není kontrola na neexistenci známých chybových paternů. Jsem tedy plně v souladu s dagim, že code review nemá plnit úkoly, které může plnit automat (počítač) pomocí PMD, Checkstyle, FindBugs apod.

Co tedy má plnit code review? Řekl bych, s trochou nadsázky, že má plnit to co pair-programming, akorát, že prográmátoři se baví už nad hotovým kódem. Tj. ten co dělá code review, sleduje kód, jak je napsán, zda mu rozumí (podstatná věc, protože pak je pravděpodobé, že to pochopí i někdo další), zda je kód rozumně strukturován a pod. Samozřejmě se jeden učí od druhého, protože buď se koukám na kód, který mě něčím inspiruje a nebo se mi v něm něco nelíbí, požaduju změnu a inspiruji autora.

U nás v týmu provádíme code review po jednotlivých požadavcích, které programátoři plní. Každý požadavek má přidělen implementátora a reviewera. Teprve pokud je review hotové, všechny připomínky vyřešeny, pak se požadavek zavírá jako hotový.

Tento postup se nám v praxi ověřil, jako kontrolní mechanismus, jako princip vzdělávání, jako postup pro zlepšování kvality kódu. Takže závěr, code review ano, ale ne na automatizovatelné úkony.

OpenAjax Hub = javascriptový messaging v 5kB

2007-09-15T21:36:00.000+02:00

Dneska si ještě více rozšíříme znalosti na poli AJAX technologií. Z blízka se podíváme na OpenAjax Hub z pod pokličky OpenAjax Alliance. V podstatě jde o messaging pro JavaScript napsaný v JavaScriptě, nebo o jednoduchý, ale mocný, publish/subscribe hub.

Pokud děláte AJAX aplikace, které jsou složené z komponent, jenž si mezi sebou posílají události, pak čtěte dále. Pokud použijeme comet, pak komponentou může být i server (jak na to je popsáno v DWR a Jetty = výkoný AJAX naruby). Obzvláště výhodné je použití OpenAjax Hubu v případech, kdy jedna komponenta generuje události, které přijímá více komponent. Navíc hub sebou nese nezávislost jednotlivých komponent, tj. komponenty komunikují pouze s hubem a ne mezi sebou, tj. čím více komponent, tím větší zjednodušení.

My jsme měli např. problém v naší aplikaci, která sleduje pohyb autobusů (autobus se ohlašuje pomocí GPRS a posílá svou polohu získanou z GPS). Chtěli jsme polohu zobrazit nejenom v mapě, ale také pomocí tabulky, která by zobrazovala další informace (např. zda jede na čas, jak je daleko na své trase).

Jak Hub použít

Pokud se proklikáte na sourceforge stránky projektu a stáhnete si OpenAjax Hub možná budete překvapeni, protože soubor OpenAjax.js, který obsahuje implementaci Hubu má plných 5744 B. Ano není to překlep, méně než 6 kB.

Nejprve začnu serverovou částí, kde použijeme Reverse AJAX. Oproti příspěvku s chatem, kde jsme volali funkci newMsg(msg) budeme volat funkci OpenAjax.hub.publish("bus.location", busLocation) (použijeme k tomu objekt ScriptBuffer jako minule). Jako první parametr do funkce publish předáme jméno události a druhým parametrem je samotná událost (využijeme DWR, které převede java objekt do javasriptového).

Na klientu musíme zapnout reverse Ajax v DWR. Dále se zaregistrujeme k odběru událostí, což provedeme kódem:


var subscription = OpenAjax.hub.subscribe("bus.location", showBusLocationInMap);

Prvním parametrem je jméno události. Pokud se chceme přihlásit k odběru všech událostí týkajících se autobusů, pak použijeme wildcard a zapíšeme jméno události bus.*. To znamená i bus.state nebo bus.message. Pokud se chceme přihlásit i k odběru bus.data.check pak použijeme bus.**.
Druhým parametrem je callbak funkce, kterou si popíšeme dále. Dalšími parametry, které v příkladu nevyužíváme jsou:

scope - objekt, který bude this při volání callbacku (je-li null, pak je použit objekt window)
subscriberData - objekt, který je předán callback funkci jako parametr
filter - funkce, která vrací true/false v případě, že akceptujeme/odmítáme předanou událost

Návratovou hodnotou funkce subscribe je objekt, který se použije jako parametr při volání unsubscribe.

Callback bude mít následující podobu:


function showBusLocationInMap(name, event, subscriberData) {
  //změň polohu autobusu na mapě - data jsou v objektu event
}

Nemůžu se stále ubránit dojmu, že je to geniální. Skvělý nápad, skvělá implementace, velmi jednoduché použití.

Závěr

Dneska jsem vám ukázal co to je OpenAjax Hub. Jak jej použít pro distribuci událostí na principu publish / subscribe. Ve spolupráci s DWR a jeho reverse AJAX implementací jsme navíc velmi jednoduše vytvářeli události na serveru.

To co je ESB pro distribuované systémy, to je OpenAjax Hub pro AJAX aplikace. Pokud tvoříte portálová řešení, mashupy, či složitější aplikace, pak se vám zjednodušení vnitřní komunikace, které vám nabízí OpenAjax Hub bude určitě hodit.

Odkazy

OpenAjax Hub Specifikace

DWR a Jetty = výkoný AJAX naruby

2007-09-14T08:43:00.000+02:00

Nebudu přímo reagovat, ale spíš doplním vlastův blog DWR - AJAX knihovna pro remotování Java objektů o ,z mého hlediska hodně zajímavou ,vlastnost frameworku DWR 2.0, tj. Reverse AJAX.

Reverse AJAX je když dokážeme ze serveru volat clienta, toď velmi jednoduchá definice. A jak této skutečnosti dosáhnout? Existují 3 možné způsoby:

polling - asi nejstarší dostupná varianta, klient se v pravidelných intervalech dotazuje serveru, zda není něco nového - nevýhoda je zřejmá, velmi často dotaz běží na server jenom proto, aby se dozvěděl, že nic nového není
piggyback - dotaz na server se přiloží k nejbližšímu následujícímí regulérnímu požadavku na server - nevýhodou je, že se o změnách ze serveru můžeme dozvědět s poměrně velkým zpožděním
comet - vytvoří se spojení se serverem, toto spojení se neuzavře a server jej využívá k odesílání dat klientovi v okamžiku, kdy má taková data k dispozici - výhodou je, že se klient o změnách dozví okamžitě a toto řešení nevyvolává nežádoucí provoz (blíže např. dagiho příspěvek)

Ovšem přeci jenom jednu nevýhodu tento přístup má. Pokud bychom nevytvářeli aplikace "inteligentně", pak každé spojení klienta se serverem, které se používá k posílání dat ze serveru na klienta, nám použije jedno vlákno na serveru, což bude řešení, které nebude moc škálovatelné.

DWR + Jetty = výkoný reverse AJAX

Nyní se dostaneme k řešení, které framework DWR dovoluje použít, pokud je nasazen v kontejneru Jetty 6.0. Ve verzi 6.0 totiž Jetty obsahuje podporu pro continuations, které umožňují "uspat" obsloužení aktuálního požadavku a vyvolat jej později (za podpory java.nio toto uspání neznamená uspání a blokování obslužného vlákna požadavku).

Nyní se pomalu dostaneme k příkladu chat serveru. V první řadě si představíme třídu, která bude reprezentovat zprávu:

public class ChatMessage {

 protected String nick;
 protected String message;

 public ChatMessage(String nick, String message) {
   super();
   this.nick = nick;
   this.message = message;
 }

 public String getNick() {
   return nick;
 }

 public String getMessage() {
   return message;
 }

}

Nic překvapujícího není k vidění. Následuje rozhraní pro příjemce nových zpráv a třída, která bude singleton a bude implementovat vstupní bránu pro všechny došlé zprávy (doručené např. AJAX requestem a nebo obyčejným odesláním formuláře - implementaci takového jednoduchého servletu nechám na vás). Jdu rovnou na ChatListener a ChatGateway:

public void class ChatListener {

 public void onMessage(ChatMessage msg);

}

public void class ChatGateway {

 private static final ChatGateway instance = new ChatGateway();  //singleton instance

 protected List<ChatListener> lsts;

 private ChatGateway() {
   super();
   lsts = new ArrayList<ChatListener>();
 }

 public void addListener(ChatListener lst) { //přidej posluchače
   ...
 }

 public void newMessage(ChatMessage msg) {
   List<ChatListener>  lsts2 = lsts;
   for (ChatListener lst : lsts2) {
     lst.onMessage(msg); //každému sděl novou zprávu
   }
 }

}

V tomto kódu stále ještě není žádné moudro, které by nějak přibližovalo naše řešení a proto pojďme dále k ChatTracker:

import org.directwebremoting.*;

public class CharTracker implements ChatListener {

 protected static final String URL = "...";  //URL stránky, kde se chat odehrává

 protected ServerContext srvCtx;  //to je celé DWR kouzlo

 public void ChatTracker() {
   super();

   //vytvoříme server context
   WebContext webCtx = WebContextFactory.get();
   srvCtx = ServerContextFactory.get(webCtx.getServletContext());

   //gateway o nás musí vědět
   ChatGateway.getInstance().addListener(this);
 }

 public void onMessage(ChatMessage msg) {
   //vytvoříme script, který bude odeslán všem klientům
   ScriptBuilder sb = new ScriptBuilder();
   sb.appendScript("newMsg(").appendData(msg).appendScript(");");

   //pošli script všem klientům, kteří jsou na stránce s definovaným URL
   for (ScriptSession ss: serCtx.getScriptSessionsByPage(URL)) {
   ss.addScript(sb);
 }

}

}

V tomto útržku kódu je velmi podstatný ServerContext, což je DWR třída, která pro nás bude prostředníkem pro zjišťování, kteří klienti jsou právě na stránce chatu a má se jim poslat informace o nové zprávě. Každý takový klient je reprezentován instancí třídy ScriptSession, která je použita k posílání událostí (v našem příkladu k posílání JavaScriptového kódu).

Podstatnou drobností je metoda appendData třídy ScriptBuilder, která zakóduje Java objekt do JavaScriptové implementace, přesně v duchu DWR (viz. konfigurace dále).

Pro jednoduchost nepoužiji integraci se SpringFrameworkem a použiji přímou konfiguraci DWR pomocí souboru dwr.xml, jenž bude umístěn v adresáři WEB-INF:


<dwr>
 <allow>
   <create creator="new" javascript="chatTracker" scope="application">
     <param name="class" value="ChatTracker"/>
   </create>

   <convert converter="bean" match="ChatMessage"/>
 </allow>
</dwr>

S přihlédnutím k vlastově příspěvku zde není nic neznámého a představíme si definici DWR servletu ve web.xml:


<servlet>
 <servlet-name>dwr-invoker</servlet-name>
 <servlet-class>org.directwebremoting.servlet.DwrServlet</servlet-class>
 <init-param>
   <param-name>activeReverseAjaxEnabled</param-name>
   <param-value>true</param-value>
 </init-param>
 <init-param>
   <param-name>initApplicationScopeCreatorAtStartup</param-name>
   <param-value>true</param-value>
 </init-param>
</servlet>

Servlet DwrServlet je v jiné package, než uváděl vlasta, což je dáno použitím verze 2.0. Parametr activeReverseAjaxEnabled povoluje reverse AJAX a initApplicationScopeCreatorAtStartup zařídí vytvoření instance
třídy ChatTracker při startu aplikace, nikolivěk při jejím prvním použití.

A co na straně klienta. Asi už je vám jasné, že to bude opět velmi jednoduché:


window.onload = function() {
 dwr.engine.setActiveReverseAjax(true);
}

function newMsg(msg) {
 if(msg) {
   //zde přidej kód pro zobrazení zprávy
 }
}

A je to. Je to úžasně jednoduché, to je přesně podle mého gusta. Jediné co mi dělá vrásky na čele, je implementace pouze pro Jetty 6.0, ale už existuje požadavek na vytvoření podpory pro Tomcat 6.0 (DWR-143), tak snad se v budoucnu dočkáme.

Závěr

Ukázal jsem vám, jak pomocí DWR 2.0 a Jetty 6.0 implementovat posílání událostí ze serveru na klienty na příkladu chatu. DWR vám jednoznačně hodně ulehčí v implementování detailů, čímž vám ušetří nejenom čas, ale i nervy. Navíc můžete velmi jednoduše přepínat mezi pollováním, piggybackem a cometem bez zásahu do vašeho kódu, všechny detaily jsou schované uvnitř DWR.

Odkazy

Ajax, Comet and Jetty (Greg Wilkins, Webtide, 2006)

Jetty Continuations

Něco úvodem

2007-09-10T20:01:00.000+02:00

Nejprve vám napíšu něco o sobě. Primárně jsem programátor. Takže se na těchto stránkách budete potkávat s různými věcmi týkajícími se programování, tj. od serveru po klienta, od Javy po SQL, od IDE po profiler atd. A abych nezapomněl, asi se tu budete potkávat i s detaily o projektu cobertura, protože to je už i moje dítě.

A proč mít vlastní blog? Vede mě k tomu pocit, že se chci podělit o svoje zkušenosti, které věřím nejsou malé a budou čím dál větší. Snad budu mít stále i chuť sepisovat své zážitky, aby zde bylo co číst.

jirablog

Team vyhrává když táhne za jeden provaz

Neoprávněná kritika Scrumu v czpodcastu č.46: Kanban agilní vývoj

Inovace bez legrace aneb máme se snažit vymýšlet něco nového a nebo jenom přebírat dané

Jak na porovnávání Comparable objektů či pomocí Comparatoru

Lekce ze Scaly: Jak se vyvarovat NullPointerException

Gradle - druhý krůček

CZJUG - Hans Dockter - Gradle

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

Gradle - první krůčky

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

Byl jsem na Scrum Master Training

Tapestry 5. 1 je mezi námi

Google App Engine & Java + Groovy

Jak jednoduše v groovy implementovat rozhraní s jednou metodou?

Tapestry 5.1 - co se na nás chystá?

iPod Touch - nechám si ho, je super!

XSS, XSRF - o bezpečnosti je potřeba neustále mluvit a o webu to platí dvojnásob

Porovnání jQuery a Prototype (odkaz)

Moduly pro Tapestry 5

Jak selektivně podle třídy mazat objekty z Hibernate session

Parametrizované testy v TestNG

ORM mých snů - iBatis 3

Optimalizace výkonu databáze DB2 - db2top utility

Java 7 - máme se na co těšit

Překlad výjímek z databáze při použití Hibernate

Lze testovat aplikaci, která s tím nepočítá

JSF vs. Tapestry - tentokrát AJAX

Co to je čitelný kód aneb Literate Programming

JSF vs. Tapestry - jak jednoduché je dělání komponent

jOpenSpace 2008 - Java vs. dynamické jazyky - více návratových hodnot v Javě (aktualizováno)

Google Developer Day 2008

jOpenSpace 2008 - Spring - otevřenost novinkám

jOpenSpace 2008 - Metodiky vývoje - jak děláme review kódu

Spring bean z Java enumu

jOpenSpace 2008 - Dokumentace - nezatracujme FOP

jOpenSpace 2008 - ORM - Hibernate a klientská aplikace

Jak mě vypekla DB2

Tapestry - jak dělat webové aplikace konfortně

Konečně build systém na úrovni - Gradle

On se ještě používá jUnit? Vždyť máme TestNG.

Test prošel. To je špatně!

Na unit testy si vždy čas udělám ...

Jak nás vypek DateFormat.parse

Nová Java: Jak z toho ven ...

Jak vnést trochu pořádku do CSS

Modulárnost

Sjednocení marginu a paddingu mezi Explorerem a Firefoxem

Speciální CSS soubor pro Explorer

Závěr

Odkazy

Používám Linux a nelituju ...

Nová Java: Chceme ji? - tvrdá realita

Nová Java: Chceme ji? - počtvrté

Závěr

Nová Java: Chceme ji? - potřetí

Nová Java: Chceme ji? - podruhé

Vylepšení příkazu switch

Odchytávání více typů výjimek najednou při zachování typu výjimky

Závěr

Nová Java: Chceme ji?

Eclipse, Mylyn, IntelliJ IDEA a Teamcity v CZPodcast #19

Unit testy - ty přece píše kodér, ne?

XML Signature - použít nebo ne?

Závěr

JavaScript a Dependency Injection

Nejde říci co je cennější, zda znalosti nebo zkušenosti

A je to tady - XQuery Update v pureXML

A co mě ještě v pureXML zaujalo

Programujeme nebo lepíme

Architektura naruby

Jednoduše na CSS Sprite

Jak na vlastní design File Input položek formulářů

Jak ovládat Eclipse pomocí prohlížeče

Vývoj aplikace za běhu

Odkazy

Kam se ztrácí zkušení programátoři

Velmi jednoduchá validace HTML formulářů JavaScriptem

Příklady

Jaké jsou dostupné třídy

Vylepšení příkazu `switch`