Zobrazují se příspěvky se štítkemNástroje. Zobrazit všechny příspěvky
Zobrazují se příspěvky se štítkemNástroje. Zobrazit všechny příspěvky

4. října 2012

Nástroje pro prototypování GUI

Pokud dneska navrhuji novou aplikaci, tak si to bez prototypování uživatelských obrazovek vůbec nedokážu představit. O to více se divím, že byli dříve časy, kdy jsem byl schopný si vystačit pouze s textem. Což samozřejmě nikdy moc dobře nefungovalo.
Je nutné minimalizovat nejasnosti a nedorozumění mezi vývojovým týmem a zákazníkem, předcházet neočekávanému. Je potřeba mít "něco" nad čím se můžu se zákazníkem bavit ještě dříve než vývojový tým začne programovat, "něco" co mi umožní získat co nejdříve zpětnou vazbu na to, jak to celé má vypadat a fungovat.

Z tohoto pohledu se mi jeví jako ideální drátěné modely (wireframes). Používáme k velké spokojenosti Balsamiq Mockup. Je to nástroj postavený nad flashem, nabízí jak webovou, tak desktopovou verzi, dokonce i pěkný plugin do Confluence a JIRY. Mezi všemi verzemi funguje bezproblémový export/import.



Při výběru jsme prošli a vyzkoušeli hodně nástrojů, na některé z nich přikládám odkaz a krátký komentář.

Balsamiq Mockup
  • Nástroj pro rychlý návrh mockup a drátových modelů.
  • Desktop aplikace, web aplikace, plugin do dalších systémů (Google Drive, Confluence, JIRA, XWIKI, …)
  • Desktop aplikace - 79$ na jednoho uživatele, Web aplikace – od 12$/měsíčně 
    Pluginy – ceny se liší v závislosti na použitém systému a způsobu licencování
  • Desktop aplikace – Windows, OS X, Linux, ostatní platformy s podporou Adobe AIR.
    Web aplikace a pluginy – Internetový prohlížeč + Flash 
  • Komplexní nástroj pro designéry.
  • Web aplikace - Internetový prohlížeč
  • Předplatné od 7$/měsíčně
Inpreso Screens
  • Nástroj pro vytváření kvalitních mockup modelů.
  • Desktop aplikace – pro chod aplikace je nutný Adobe AIR
    Web aplikace - Internetový prohlížeč + Flash
  • Omezená verze zdarma, předplatné 29$/rok na jednoho uživatele
  • Nástroj pro vytváření prototypů. Lze jít nad rámec vytváření drátových modelů a prototypů přidáváním událostí.
  • Web aplikace - Internetový prohlížeč
  • Zdarma
 GUI Design Studio
  • Nástroj pro vytváření návrhů pro prostředí Windows. Lze ho použít k rychlému vytvoření prototypů kreslením obrazovek s využitím standardních Windows prvků a jejich propojením, aby bylo možné následně simulovat chování.
  • Desktop aplikace – Windows
  • Od 129$ za jednu licenci
  • Silný nástroj pro vytváření drátových modelů aplikací.
  • Desktop aplikace – Windows, OS X
  • Desktop aplikace - Omezená verze zdarma
    Pro verze 495$ za licenci

  • Webový nástroj pro rychlé vytváření drátových modelů a prototypů GUI pro web, mobilních a podnikových aplikací. Umožňuje pohodlné testování použitelnosti a inteligentní spolupráci.
  • Web aplikace - Internetový prohlížeč
  • Předplatné od 9$/měsíčně
Další nástroje a odkazy bez komentářů:

25. dubna 2012

Crucible - nástroj na code review

Crucible je další z nástrojů od Atlassianu (kromě již známých nástrojů JIRA a Confluence).  Crucible je nástroj na code review. Umožňuje prohlížení zdrojových kódů a vytváření jeho review včetně workflow kolem. Crucible slouží jako komunikační kanál mezi vývojáři nad zdrojovým kódem - vše na jednom místě, vše sledovatelné a dohledatelné.

Přínos efektivního code review je zřejmý, ale často je problém, jak vlastně code review dělat, aby bylo opravdu efektivní. Efektivní code review musí z mého pohledu splňovat tyto podmínky:

  • šíření informací všem členům týmu
  • vše zpětně dohledatelné
  • minimální časová náročnost resp. čím méně času, tím lépe
  • nesmí nabourávat vztahy v týmu (není vždy jednoduché být kritický a nikoho se tím osobně nedotknout)
Když jsme s code review začínali,  tak to vypadalo přibližně tak, že jsme se každý týden na půl hodiny až hodinu potkali osobně, kde jsme procházeli části kódu, upozorňovali na časté nedostatky nebo informovali se o změnách v našich interních API. Toto nejčastěji prováděl team leader. Tento přístup má řadu nevýhod:
  • každý nemůže vždy přijít na osobní setkání, takže se k němu dané informace nedostanou (je pravda, že důležité věci, případně nějaká rozhodnutí jsme zapisovali do interní wiki, ale i tak spoustu informací ze samotného code review nikde zaznamenána nebyla)
  • chybí jedno místo, kde lze informace z code review hledat. Něco se řekne na schůzce, něco se pošle mailem a pak je problém se k některým tématům vracet, dohledávat je
  • samotná kontrola zdrojového kódu probíhá ručně, často náhodným výběrem několika tříd. Chybí nástroj, který vás v tomto podpoří, přidá do toho trochu nějaký systém.
  • vždy bylo nutné mít zdrojový kód v repository, aby si ho někdo další mohl prohlížet
Kvůli těmto nedostatkům jsme začali hledat vhodný nástroj a Crucible nám je pomohlo odstranit.  Crucible nabízí integraci s dalšími svými sourozenci, zejména s JIROU - není tedy problém vytvořit nové review přímo z JIRY k souborům napojených k danému tásků. I na podporu v IDE se nezapomnělo - mohu přímo v IDE vybrat soubory a vytvořit k nim nové review v Crucible (podpora je zatím jen pro IDEU, pro Eclipse zatím chybí). 

Máme teď tedy v týmu nástroj, který umožňuje komukoliv a kdykoliv založit požadavek na review vybrané části kódu a tím získat zpětnou vazbu. Když si člověk uvědomí, že žádné API není hned v první verzi dokonalé, že je potřeba získávat zpětnou vazbu na svoje návrhy a svoji práci, tak máme nástroj, který nám s tím dokáže pomoci.

Standardně součástí Crucible je i FishEye, což je taková hodně komfortní prohlížečka zdrojových kódů v repositářích. Za FishEye je ale nutné platit nemalé peníze navíc, tak zatím používáme samotné Crucible - chybí několik zajímavých pohledů do repositářů, ale z pohledu samotných review se nic nezměnilo.

26. března 2012

Acceptance test driven development

Pro většinu z nás jsou unit testy naprostou samozřejmostí a pokud budu mluvit sám za sebe, tak si to bez unit testů už nedovedu představit. Nejvíce to vidím, když opravuji starý kód, jak jsem nervózní, abych jednou úpravou neudělal další chyby.

Osobně unit testy (nebo i integrační testy, myšleno testy nad databází) píšu po napsaní produkčního kódu. Již během psaní produkčního kódu si dělám poznámky, jaké možné cestičky je potřeba ověřit a podle toho potom píši testy. Testy tedy hlavně beru jako mého pomocníka (=pomocníka programátora), abych byl schopen dodat práci co v nejlepší kvalitě a byl co nejlépe připravený na budoucí úpravy a opravy. Z pohledu samotného vývoje je asi tento pohled v pořádku, ale pokud se na proces vývoje ve firmě podívám z pohledu celé firmy, tak už tam vidím nějaké mezery.

Proces vývoje většinou začíná u konzultantů, kteří tvoří zadání, kteří definují akceptační kritéria, kteří nesou zodpovědnost za to, že zákazníkovi se dodá to, co opravdu chtěl a navíc v požadované kvalitě. Od začátku jsou tedy zřejmé požadavky, které je nutné splnit a tyto požadavky by se měly co nejvíce přenést do samotného vývoje. Je tedy žádoucí, aby programátoři se během vývoje a testování zaměřili právě na tyto důležité požadavky. Často programátor testuje věci dle svého uvážení, kde on sám vidí možné slabiny, ale to je často v rozporu s tím, co musí testovat konzultant/tester.

Právě při těchto úvahách jsem hledal možné řešení, jak co nejvíce propojit obě části vývoje, jak najít společnou řeč. Nejblíže mojí představě je Acceptance test driven development a konkrétně projekt Thucydides, který celému přístupu dává jasné obrysy.

Advanced practices of test-driven development can lead to Acceptance Test-driven development (ATDD) where the criteria specified by the customer are automated into acceptance tests, which then drive the traditional unit test-driven development (UTDD) process. This process ensures the customer has an automated mechanism to decide whether the software meets their requirements. With ATDD, the development team now has a specific target to satisfy, the acceptance tests, which keeps them continuously focused on what the customer really wants from that user story.
Místo vysvětlování ATDD a Thucydides se doporučuji podívat na prezentaci pod článkem, kde je vše pěkně ukázané. Pro další informace pak ještě doporučuji článek z JavaWorldu - Acceptance test driven development for web applications.
Ještě bych zmínil knihovnu jBehave, která je představitelem přístupu zvaném Behaviour-Driven Development (BDD), který je velice podobný ATDD.

Rádi bychom šli v celém návrhu ještě dále a využili JIRU jako nástroj pro psaní a evidenci kritérií resp. stories. JIRA je pro většinu týmu centrálním bodem, kde se evidují požadavky na vývoj a je to i nástroj, který umí používat konzultanti. Tak proč neupravit JIRU i pro zadávání akceptačních kritérií v určitém formátu, ze kterých by se následně generovala kostra/šablona pro psaní testů v Groovy nebo jUnit? 

Nápadů a myšlenek je hodně, uvidíme v jaké podobě (a zda vůbec) se nám to podaří realizovat v praxi. Pokud máte někdo s uvedenými přístupy nějaké zkušenosti, budu rád když je uvedete v komentářích k článku.

23. ledna 2012

Vybrat JasperReports nebo BIRT reports?

Potřebuji se rozhodnout, jaké řešení na reporty vybrat a pořád nevím. Nějaké porovnání těchto nástrojů jsem již uváděl na mém blogu, ale již je to skoro tři roky zpátky a od té doby se mnoho věcí určitě změnilo.

Pořád si myslím, že volba je mezi JasperReports a BIRT reports. Našel jsem další možnosti jako Pentaho Reporting, Crystal Reports nebo NextReports, ale žádné z těchto řešení mě moc nezaujalo.

Já osobně žádné pokročilé funkce od nástroje neočekávám, spíše ty základní:

  • reporty budou primárně zobrazeny na webové stránce
  • export do PDF, XLS je nutností
  • absolutní většina reportů bude statických, tedy uživatel klikne na odkaz a zobrazí se mu určitý report. Žádná velká interakce uživatele při zobrazování reportu nebude.
Můj favorit je JasperReports, ale asi jen díky nějakým subjektivním důvodům:
  • JaspeReports je tu už dlouho a již od nějaké 1.x verze Springu je součástí standardní podpory. Takže Spring nabízí podporu na podobné úrovni jako jiné prezentační frameworky jako Freemarker, Velocity atd.
  • velká komunita a rozsáhlá dokumentace (z uvedených nástrojů nejlepší)
  • myšlenka kolem JasperReports Serveru mi přijde zajímavá a bez většího úsilí nabízí velkou přidanou hodnotu
Moc pěkné srovnání je v článku BIRT, Jasper, Pentaho - Comparison Matrix nebo v článcích JasperReports, případně BIRT Vs Jasper Report A Comparitive Study.

Jaké máte prosím zkušenosti vy?

16. května 2010

Generování class diagramů - Maven plugin

Na konci minulého roku jsem psal o programovém generování class diagramů.

Dnes bych na tento článek navázal implementací Maven pluginu. Ve firmě jsme kompletně přešli na Maven, takže jsem byl nucen vhodně přepsat původní ANT skript.

Implementace byla jednoduchá, napsal jsem totiž Maven plugin pomocí ANTu (pozor, nemyslím využití Maven Ant pluginu).

Dále přikládám zdrojové kódy, které asi nepotřebují další komentáře:

pom.xml:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>cz.marbes.plugins</groupId>
<artifactId>daisy-maven-plugins</artifactId>
<version>3.12.0.11-SNAPSHOT</version>
</parent>
<groupId>cz.marbes.plugins</groupId>
<artifactId>generator-diagram-plugin</artifactId>
<packaging>maven-plugin</packaging>
<version>3.12.0.11-SNAPSHOT</version>
<name>generator-diagram-plugin Maven Mojo</name>
<description>Plugin na generovani class diagramu</description>


<build>
<plugins>
<plugin>
<artifactId>maven-plugin-plugin</artifactId>
<version>2.3</version>

<dependencies>
<dependency>
<groupId>org.apache.maven</groupId>
<artifactId>maven-plugin-tools-ant</artifactId>
<version>2.0.1</version>
</dependency>
</dependencies>

<configuration>
<goalPrefix>diagram</goalPrefix>
</configuration>
</plugin>
</plugins>
</build>


<dependencies>
<dependency>
<groupId>org.apache.maven</groupId>
<artifactId>maven-script-ant</artifactId>
<version>2.0.1</version>
</dependency>
<dependency>
<groupId>org.umlgraph</groupId>
<artifactId>doclet</artifactId>
<version>5.1</version>
</dependency>
<!-- Knihovna UmlGraph vyzaduje, aby byl vedle ni umisten tools.jar -->
<dependency>
<groupId>com.sun</groupId>
<artifactId>tools</artifactId>
<version>1.5.0</version>
<scope>system</scope>
<systemPath>${java.home}/../lib/tools.jar</systemPath>
<!--<systemPath>${user.home}/.m2/repository/org/umlgraph/doclet/5.1/tools.jar</systemPath>-->
</dependency>
</dependencies>

</project>


diagram.build.xml:

<?xml version="1.0" encoding="UTF-8"?>
<project name="generator-diagram-plugin">
<target name="generate">
<!-- vytvoreni vystupniho adresare -->
<mkdir dir="${outputDir}"/>
<delete dir="${outputDir}"/>
<mkdir dir="${outputDir}"/>

<!-- generovani class diagramu -->
<java classname="cz.marbes.plugins.maven.generator.diagram.ClassDiagramGenerator">
<arg value="${package}"/>
<arg value="${outputDir}"/>
<arg value="${srcDir}"/>
<arg value="${dotFile}"/>
</java>
</target>
</project>


diagram.mojos.xml:

<?xml version="1.0" encoding="UTF-8"?>
<pluginMetadata>
<mojos>
<mojo>
<goal>generate</goal>

<!-- this element refers to the Ant target we'll invoke -->
<call>generate</call>

<requiresProject>true</requiresProject>

<description>
Plugin na generovani class diagramu.

Plugin vyzaduje (bohuzel) dve nutna zla:
- musi byt lokalne nainstalovay Graphiz (http://www.graphviz.org). Cesta k '
dot' souboru se zadava pres property 'dotFile'
- knihovna tools.jar musi byt vedle knihovny UmlGraph v Maven repository
</description>
<parameters>
<parameter>
<name>outputDir</name>
<property>outputDir</property>
<required>true</required>
<readonly>true</readonly>
<expression>${outputDir}</expression>
<defaultValue>${project.build.directory}/diagram_output</defaultValue>
<type>java.lang.String</type>
<description>Cesta k vystupnimu adresari, do ktereho se bude generovat diagram.</description>
</parameter>
<parameter>
<name>srcDir</name>
<property>srcDir</property>
<required>true</required>
<readonly>true</readonly>
<expression>${srcDir}</expression>
<defaultValue>${project.build.sourceDirectory}</defaultValue>
<type>java.lang.String</type>
<description>Absolutni cesta k adresari projektu se zdrojovymi soubory, kde je zadany package,
napr. '
/Volumes/Obelix/projects/daisy/apl/aa/trunk/aa-core/src/main/java'.
</description>
</parameter>
<parameter>
<name>package</name>
<property>package</property>
<required>true</required>
<expression>${package}</expression>
<type>java.lang.String</type>
<description>Package, pro ktery se ma generovat class diagram,
napr. '
cz.marbes.daisy.modules.aa.wscommon.komu.v1_1_2'.
</description>
</parameter>
<parameter>
<name>dotFile</name>
<property>dotFile</property>
<required>true</required>
<expression>${dotFile}</expression>
<type>java.lang.String</type>
<description>Cesta ke graphviz DOT souboru (napr. '
/usr/local/bin/dot')</description>
</parameter>
</parameters>
</mojo>
</mojos>
</pluginMetadata>


Nakonec ještě přikládám použití pluginu:

<profile>
<id>generate-diagram</id>
<!--
Profil vyzaduje dve nutna zla:
- musi byt lokalne nainstalovay Graphiz. Cesta k 'dot' souboru se zadava pres property 'dotFile'
- knihovna tools.jar musi byt vedle knihovny UmlGraph v Maven repozitory

Priklad:
mvn process-classes -Pgenerate-diagram -DdotFile=/usr/local/bin/dot -Dpackage=cz.marbes.daisy.modules.aa.modules.pvs.ws.v2_0_0
-->
<build>
<plugins>
<plugin>
<groupId>cz.marbes.plugins</groupId>
<artifactId>generator-diagram-plugin</artifactId>
<executions>
<execution>
<id>compile</id>
<phase>process-classes</phase>
<goals>
<goal>generate</goal>
</goals>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>com.sun</groupId>
<artifactId>tools</artifactId>
<version>1.5.0</version>
<scope>system</scope>
<systemPath>${user.home}/.m2/repository/org/umlgraph/doclet/5.1/tools.jar</systemPath>
</dependency>
</dependencies>
</plugin>
</plugins>
</build>
</profile>


Stejně jako původní řešení, tak i Maven plugin má své omezení, ale pro interní použití se to dá překonat. Důležité je, že dokážeme generovat pěkné class diagramy k našemu kódu. Class diagramy dáváme zejména do dokumentace k našim webovým službám, protože to zvyšuje jejich čitelnost a použitelnost.

1. ledna 2010

Jaký server nejčastěji používáte?

V poslední anketní otázce jsem se ptal, jaký aplikační server nejčastěji používáte. Celkem vás hlasovalo 124 s následujícími výsledky:

  1. Apache Tomcat (59%)
  2. GlassFish (11%)
  3. JBoss (9%)
  4. WebLogic (7%)
  5. Jetty (4%)
  6. IBM Websphere (3%)
  7. Jiný (2%)
  8. SpringSource dm Server (1%)

Já osobně se snažím všude používat Apache Tomcat, protože mi svoji jednoduchostí a funkcionalitou naprosto stačí a vyhovuje. Když jsem používal jiný server, tak to bylo většinou na přání zákazníka. Také mám zkušenosti s IBM Websphere serverem, protože jsme jeden projekt stavěli pomocí Websphere Integration Developeru.

20. prosince 2009

Generování class diagramů

Class diagramy dnes umí vygenerovat mnoho nástrojů, ale přesto jsme raději nakonec použili vlastní řešení pro generování class diagramů. Mnohdy nám přišla nedostatečná kvalita vygenerovaných diagramů, jindy zase bylo málo možností konfigurace generování a nakonec se ukázalo, že bychom rádi celý proces generování class diagramů zautomatizovali, což u většiny nástrojů nebylo možné.

Takto vygenerované class diagramy používáme jednak pro vlastní potřebu, abychom se v určitém kódu sami lépe vyznali a pak je také daváme jako součást naší dokumentace, zejména pro rozhraní webových služeb.

Pro naše potřeby jsme použili knihovnu UmlGraph. Tato knihovna se stará o zjišťování vazeb mezi třídami a funguje na principu JavaDoc docletu. Buď je možné zvolit zcela automatický řežim, kdy knihovna se sama snaží podle konfigurace zjistit vazby mezi třídami a nebo je možné každou třídu doplnit v JavaDocu třídy speciálními tagy, např. pro vyjádření dědičnosti. Automatický řežim celkem funguje, ale není to 100% - pokud bych rád zobrazoval např. kardinalitu vazeb, pak musím použít tagy. My standardně používáme automatický řežim a jen jednou se nám stalo, že určité vazby se nezobrazily, tak jak jsme chtěli - potom jsme použili tagy a bylo vše ok.

UmlGraph pouze generuje DOT soubor, který je nutný následně zpracovat pomocí nástroje Graphviz, který teprve vykreslí výsledný obrázek. Bohužel Graphviz je nutné lokálně instalovat, což je snad jediná nevýhoda celého řešení. Je možné zase spoustu věcí nastavit dle vlastních potřeb, včetně výstupního formátu obrázku.



Přikládám ukázku kódu:

package cz.marbes.daisy.modules.generator.diagramgenerator;

import org.apache.commons.lang.StringUtils;

import java.io.BufferedReader;
import java.io.File;
import java.io.InputStreamReader;
import java.io.PrintWriter;

/**
* Generator class diagramu.
*
* <p>Generator je spousten pres {@link #main(String[]) main} metodu a generuje
* class diagram pro zadany balik (package) trid.
*
* @author <a href="mailto:petr.juza@marbes.cz">Petr Juza</a>
* @see <a href="http://www.graphviz.org">graphviz</a>
* @see <a href="http://www.umlgraph.org/">UML graph</a>
*/
public class ClassDiagramGenerator {

private final static String DOT_FILENAME = "graph.dot";
private static final String UMLGRAPH_MAIN_CLASS = "org.umlgraph.doclet.UmlGraph";

/**
* Vystupni format obrazku [png|gif]
*/
private static final String OUTPUT_IMAGE_FORMAT = "gif";


private ClassDiagramGenerator() {
}


/**
* Main metodu, vstupni bod pro generovani class diagramu.
*
* @param args Vstupni parametry generovani:
* <ol>
* <li>Package, pro ktery se ma generovat class diagram
* (napr. {@code cz.marbes.daisy.modules.aa.wscommon.komu.v1_1_2})
* <li>Vystupni adresar pro DOT soubor a vysledny obrazek
* <li>Absolutni cesta k adresari projektu se zdrojovymi soubory, kde je zadany package
* (napr. {@code /Volumes/Obelix/projects/daisy/apl/aa/trunk/aa-core/src/main/java})
* <li>Cesta ke graphviz DOT souboru (napr. {@code /usr/local/bin/dot})
* <li>Seznam nazvu trid (staci pouze nazev, nemusi byt vcetne baliku), ktere budou vynechany
* pri vykreslovani class diagramu. Jedn. tridy budou oddeleny carkou.
* </ol>
* @throws IllegalArgumentException pokud "nesedi" vstupni parametry
* @throws ClassNotFoundException pokud neni dostupna UmlGraph knihovna
*/
public static void main(String[] args) throws Exception {
// args = new String[]{
// "cz.marbes.daisy.modules.aa.wscommon.smlouvy.v1_1_3",
// "/Volumes/Obelix/projects/daisy/diagram_output",
// "/Volumes/Obelix/projects/daisy/apl/aa/trunk/aa-core/src/main/java",
// "/usr/local/bin/dot",
// "TypPripadService,SqlBuilderQuery,AaSqlBuilderHook"
// };

//kontrola existence UmlGraphu v classpath
try {
Class.forName(UMLGRAPH_MAIN_CLASS);
}
catch (ClassNotFoundException ex) {
throw new ClassNotFoundException("UmlGraph neni dustupny - " +
"pridejte knihovnu UmlGraph do classpath", ex);
}


//validace a zpracovani vstupnich hodnot
if (args == null
|| args.length < 4
|| args.length > 5) {
throw new IllegalArgumentException("Generator ocekava 4 povinne a 1 nepovinny vstupni parametr ...");
}

String packagePath = args[0];
String outputFolder = args[1];
String srcFolder = args[2];
File graphvizDotFile = new File(args[3]);

String excludeClasses = null;
if (args.length == 5) {
excludeClasses = args[4];
}

//kontrola existence graphviz DOT souboru
if (!graphvizDotFile.exists()
|| !graphvizDotFile.canExecute()) {
throw new IllegalArgumentException("Graphviz DOT soubor neexistuje ["
+ graphvizDotFile.getAbsolutePath() + "].");
}

System.out.println("--------------------------------------------------------------");
System.out.println("Generovani class diagramu pro - " + packagePath);
System.out.println("--------------------------------------------------------------");

//generovani
ClassDiagramGenerator generator = new ClassDiagramGenerator();
File diagramDotFile = generator.generateDotFile(packagePath, outputFolder, srcFolder, excludeClasses);

if (diagramDotFile != null) {
generator.generateImage(graphvizDotFile, diagramDotFile);
}

System.out.println("Konec generovani ...");
}


/**
* Generuje DOT soubor.
*
* <p>DOT soubor (format pro <a href="http://www.graphviz.org">graphviz</a>)
* je generovan knihovnou <a href="http://www.umlgraph.org/">UML graph</a>.
*
* @param packagePath Package, pro ktery se ma generovat class diagram
* (napr. {@code cz.marbes.daisy.modules.aa.wscommon.komu.v1_1_2}).
* @param outputFolder Vystupni adresar pro DOT soubor
* @param srcFolder Absolutni cesta k adresari se zdrojovymi soubory, kde je zadany package
* @param excludeClasses Seznam nazvu trid, ktere budou vynechany pri vykreslovani class diagramu.
* Jedn. tridy budou oddeleny carkou.
* @return generovany DOT soubor
*/
private File generateDotFile(String packagePath,
String outputFolder,
String srcFolder,
String excludeClasses) {
File fileDot = new File(outputFolder + File.separator + DOT_FILENAME);

if (StringUtils.isNotEmpty(excludeClasses)) {
//vymazou se mezery a nahradi se carky lomitky (, -> |)
excludeClasses = StringUtils.deleteWhitespace(excludeClasses);
excludeClasses = StringUtils.replaceChars(excludeClasses, ',', '|');
}

excludeClasses = StringUtils.trimToNull(excludeClasses);

//viz http://www.umlgraph.org/doc/cd-opt.html,
// http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/javadoc.html#javadocoptions
String[] args = new String[]{
"-all", //=-attributes -operations -visibility -types -enumerations -enumconstants
"-hide",
"^(java|com\\.sun|org.apache)" + (excludeClasses != null ? "|" + excludeClasses : ""),
"-inferrel",
"-inferdep",
"-inferdepinpackage",
"-collpackages",
"java.util.*",
"-verbose",
"-output",
fileDot.getAbsolutePath(), //napr.: "/Volumes/Obelix/D/graph.dot",
"-sourcepath",
srcFolder,
packagePath
};


//vytvoreni writeru kvuli logovani
PrintWriter errWriter = new PrintWriter(System.err);
PrintWriter warnWriter = new PrintWriter(System.out);
PrintWriter noticeWriter = new PrintWriter(System.out);

System.out.println("Generovani DOT souboru: ");
System.out.println(" Source folder - " + srcFolder);
System.out.println(" Package path - " + packagePath);
System.out.println(" Dot file - " + fileDot.getAbsolutePath());
System.out.println(" Exclude classes - " + excludeClasses);

//vygenerovani DOT souboru
com.sun.tools.javadoc.Main.execute("UmlGraph",
errWriter, warnWriter, noticeWriter, UMLGRAPH_MAIN_CLASS, args);

return fileDot;
}


/**
* Generuje vysledny obrazek class diagramu.
*
* @param graphvizDotFile Graphviz DOT soubor
* @param diagramDotFile DOT soubor ke zpracovani
* @throws Exception v pripade problemu pri generovani obrazku
*/
private void generateImage(File graphvizDotFile, File diagramDotFile) throws Exception {
try {
String[] args = new String[]{
graphvizDotFile.getAbsolutePath(),
"-T" + OUTPUT_IMAGE_FORMAT,
"-O",
diagramDotFile.getAbsolutePath()
};

System.out.println("Generovani obrazku: ");
System.out.println(" Graphviz DOT soubor - " + graphvizDotFile.getAbsolutePath());
System.out.println(" DOT soubor ke zpracovani - " + diagramDotFile.getAbsolutePath());

Process p = Runtime.getRuntime().exec(args);

BufferedReader reader = new BufferedReader(new InputStreamReader(p.getErrorStream()));
String line;
while ((line = reader.readLine()) != null) {
System.err.println(line);
}

int result = p.waitFor();
if (result != 0) {
System.err.println("Errors occured during running Graphviz - return code is " + result);
}
}
catch (Exception ex) {
System.err.println("Errors occured during running Graphviz - " + ex.getLocalizedMessage());
throw ex;
}
}
}


A ještě obecný ANT task pro spouštění generování diagramů:
    <target name="gen_diagram" description="Generovani class diagramu pro zadany package." depends="clean">
<input message="Zadejte package, pro ktery chcete generovat class diagram (napr. cz.marbes.daisy.modules.aa.wscommon.pvs.v1_1_1)?"
addproperty="packagePath" />

<input message="Zadejte cestu ke zdrojovym souborum relativni k projektu, kde je zadany package (napr. /apl/aa/trunk/aa-core/src/main/java)?"
addproperty="srcPath" />

<input message="(nepovinne) Zadejte seznam nazvu trid oddelenych carkou (nemusi byt vcetne baliku), ktere budou vynechany z class diagramu."
addproperty="excludeClasses" />

<java classname="cz.marbes.daisy.modules.generator.diagramgenerator.ClassDiagramGenerator"
classpathref="project.class.path" fork="true">
<arg value="${packagePath}"/>
<arg value="${diagram.output.folder}"/>
<arg value="${basedir}/${srcPath}"/>
<arg value="${graphviz.dot.path}"/>
<arg value="${excludeClasses}"/>
</java>
</target>

5. srpna 2009

Jaký build server používáte? - výsledky

V poslední anketě mě zajímalo, jaký build server nejčastěji používáte. Celkem vás hlasovalo 51 s následujícími výsledky:

  1. Hudson (52%)
  2. TeamCity (23%)
  3. CruiseControl a Apache Continuum (6%)
  4. Něco jiného (9%)
  5. Luntbuild (7%)
  6. Bamboo (3%)

Výsledky jsou dle mého očekávání, možná jen jsem nečekal, že tolik lidí bude používat TeamCity, protože se jedná o placené řešení.

Já sám jsem dlouho používal Hudson ke vší spokojenosti do doby, než jsem měl možnost se setkat s TeamCity. Možnosti tohoto řešení jsou opravdu veliké (přehled vlastností zde) a když k tomu připočtu pěkné uživatelské rozhraní a možnost propojení s IDE nástroji, tak pro mě je to nyní nástroj číslo jedna - i za cenu toho, že to není zadarmo.

Kromě uvedených nástrojů mám uložen ještě odkaz na tyto nástroje: Apache Gump a Gradle. Také se dá využít řešení od Microsoftu - Team Foundation Server (samotného by mě nenapadlo spojovat toto řešení s Javou, ale zrovna nedávno mi kamarád popisoval, jak celá firma funguje nad Microsoftem, tak TFS byla prý logická volba).

Nakonec přikládám odkaz na článek s radami k výběru open-source řešení.

24. června 2009

Spring ROO

Poprvé jsem o projektu Roo slyšel na konferenci SpringOne v červnu v roce 2007. Tehdy vlastně jen oznamovali začátek projektu a musím říct, že mě to nijak příliš nezaujalo. Dokonce jsem si na tento projekt vzpomněl minulý rok na podzim a myslel jsem si, že ten projekt již dávno skončil.

A neskončil. Po dvou letech se objevila první verze, oznámení proběhlo na SpringOne v letošním roce.

Obecně mám k různým generátorům negativní přístup, proto mi trvalo chvíli, než jsem si našel čas a podíval se na to, co vlastně Roo nabízí. A byl jsem pozitivně překvapen:

  • Roo shell se zdá být mocný nástroj.

  • Sami autoři také asi nemají nejlepší zkušenosti se "standardními" generátory kódu a již z deklarace hlavních myšlenek projektu je cítit jiný přístup. Tedy snaha o to, aby Roo byl pomocníkem a ne omezovačem. Roo je možné použít pro rychlé nastartování projektu, dokonce je možné zapojit Roo do již existujícího projektu. Nebo naopak kdykoliv Roo opustit. To je díky tomu, že Roo vlastně negeneruje přímo Java zdrojový kód, ale využívá AOP pro generování do zkompilovaného class souboru.

  • Vygenerovaný kód je postavený na jiných Springových projektech (Spring framework, Spring security), a proto mi nedělá žádný problém se orientovat v těchto souborech a případně je upravovat, doplňovat. Jediné co je navíc, jsou specifické @Roo anotace pro generování výsledného kódu resp. zkompilovaného kódu. Zde se intenzivně používá AspectJ inter-type declarations.

  • Líbí se mi, jak lidé ve Springu se stále drží svých ideologických představ o správném vývoji aplikací, což je vidět i zde. Kromě produkčního kódu se generují unit testy, dokonce s napojením na Selenium.

  • Samotný projekt Roo je napsán hodně flexibilně - kromě základních služeb Roo obsahuje rozšíření (tzn. add-ons), které právě dodávají Roo všechny ty možnosti generování. Takže teď je např. rozšíření pro Maven nebo Hibernate, ale do budoucna může být pro ANT nebo TopLink. Navíc je tu možnost vývoje vlastních rozšíření.


Někde jsem četl názor o tom, proč má Spring dva nástroje na generování kódu - nyní nově Roo a dříve získané Grails. Oba nástroje znám jen velmi povrchně, takže je nemohu moc porovnat. Snad jen, že Grails vyžadují Groovy oproti Roo. Určitě jsou nástroje z výsledného přínosu hodně podobné, ale Roo míří svými možnostmi o dost dále. Kromě toho byl projekt Roo spuštěn dávno před tím, než bylo jasné, že SpringSource získá G2One a tedy Grails. Navíc se domnívám, že hlavním důvodem akvizice nebyly Grails, ale jazyk Groovy. Co bude dále nevím, ale vypadá to, že oba dva projekty pojedou stále dále bez nějakého omezení.

Projekt je nyní ve verzi 1.0.0.M2 a v brzké době bude uvolnění verze 1.0. Hlavním představitelem projektu je Ben Alex, který je mimo jiné hlavním autorem Spring security. Tedy aspoň pro mě záruka kvality.


Odkazy pro více informací:

13. dubna 2009

Srovnání systémů na správu chyb

Kamarád se na mě obrátil s dotazem, zda bych mu mohl doporučit nějaký systém na správu chyb. Vzpomněl jsem si, že jsem si kdysi (asi před rokem) dělal takový malý osobní průzkum a dokonce jsem k tomu našel i nějaké poznámky, které bych teď rád zveřejnil (doufám, že všechny uvedené informace jsou stále platné).

Bugzilla

URL: http://www.bugzilla.org

Výhody:
  • hodně používaný systém, prověřený open-source komunitou – existuje dostatek informací na fórech, v dokumentaci
  • existence spousty rozšíření – integrace s dalšími nástroji jako je SVN, různí klienti mimo základní webový klient. Více informací je zde.
  • existuje (aspoň částečný) český překlad
  • bugZilla je po instalaci připravena k použití, co se týče dat pro zadávání bugů. Obecně lze říci, že bugZilla je řešení v kostce, které pokrývá základní požadavky na bug tracking systém. Pokud chceme určité věci jinak (např. jiné schvalovací workflow, tak už je to problém)
Nevýhody:
  • ne moc „sexy“ vzhled. Toto hlavně platilo pro verze 2.x, nyní od verze 3.x je to lepší a mělo by to být dokonce skinovatelné.
  • komplikované nastavování uživatelských práv – kdo co může vidět, editovat apod. Zkušenost z verze 2.x, ve verzi 3.x opět vylepšeno.
  • struktura bugu je dána, není možné příliš konfigurovat
  • nástroj určen převážně pro interní použití, není vhodné to vystrkovat směrem k uživateli
Poznámky:
BugZilla nabízí demo k vyzkoušení.

Scarab

URL: http://scarab.tigris.org/

Výhody:
  • Scarab není jen systém na evidenci chyb, ale obecně artifaktů – to můžou být požadavky, chyby, nové věci k realizaci.
  • Scarab je hodně konfigurovatelný. Základní instalace obsahuje definici základních typů, které je možné změnit, přidat, upravit.
Nevýhody:
  • Produkt není úplně bez chyb, je ve verzi 0.21. Když se ale ví jak ho používat, tak žádné problémy nejsou.

Trac

URL: http://trac.edgewall.org/

Výhody:
  • Výborná integrace se Subversion.
  • Jednoduché a dostačující řešení pro menší projekty a týmy, nesnaží si hrát na velký systém. Z pohledu uživatele je to tedy srozumitelný, nezatěžuje ho složitost toho co nepotřebuje (např. bugZilla).
  • Postaveno nad Wiki
Nevýhody:
  • Také asi nelze čekat aplikaci bez chyb (aspoň dle čísla verze).
Poznámky:
I zde je demo k vyzkoušení.

JIRA

URL: http://www.atlassian.com/software/jira/

Výhody:
  • Z pohledu použitelnosti, možnostech nastavení se jedná jednoznačně o nejlepší řešení
  • Nejedná se pouze o bug tracking systém, ale lze to využít např. i pro projektové řízení
Nevýhody:
  • Jedná se o placený software, základní verze začíná na ceně $1200.
  • Je primárně určen na větší projekty (nejen svojí robustností, ale i schopností se integrovat s dalšími systémy) – většinu z toho vůbec nevyužijeme.

Závěr

Osobní zkušenost mám se systémy bugZilla, JIRA a částečně Scarab. Pokud bych nemusel hledět na peníze, tak bych si určitě zvolil JIRA – nabízí toho určitě nejvíce ze všech, uživatelsky přívětivé prostředí, velká síla je ve velkém množství reportů.

Nejvíce znám a používal jsem systém bugZilla. Nemůžu říci, že bych s ním byl nespokojený, to co jsem od něj požadoval, tedy správu chyb, tak to plnil bez chyb. Dost často jsem slyšel narážky na její vzhled, zejména v době, když jsme potřebovali zapojit do našeho systému i externí zákazníky. Třetí verzi bugZilly jsem jen viděl nebo o ní četl a myslím, že se tam ty základní problémy (vzhled, nastavení práv) zlepšily.

Hodně příjemně na mě zapůsobil Trac – jednoduchý nástroj postavený na Wiki, který nabízí přesně to, co se od něj očekává. Pokud bych měl tu možnost, tak bych rád Trac použil na nějakém projektu, zatím je to takový můj černý kůň.

Pokud bych nechtěl nic pokazit a musel bych vsadit na jistotu (a neměl bych peníze), tak bych volil bugZillu.

Ještě bych nakonec odkázal na porovnání uvedených nástrojů v článku na JavaWorld.

21. března 2009

JavaRebel - vývoj bez restartu serveru

O nástroji JavaRebel se již psalo před nějakým časem na Jirablogu. Přesto bych rád o tomto super nástroji napsal znovu a podělil se s vámi o mé zkušenosti.

Pokud tento nástroj ještě neznáte, tak se jedná o JVM plugin, který umožňuje za běhu aplikace upravovat Java kód tak, že se změny hned promítnou do běžící aplikace. To zní hodně podobně jako standardní JVM HotSwap, ale JavaRebel toho umí mnohem více, např. přidání nové proměnné do třídy, metody, změna anotace apod. Více o možnostech zde.

Vždy jsem si při vývoji vystačil s lightweight servery (Tomcat, Jetty) a tam nebyl problém server často restartovat z důvodu promítnutí změn v Java kódu. Nyní dělám na projektu, kde máme OC4J server a plně jsem pochopil, proč ty servery jsou tak heavyweight. Člověk si musí při psání kódu dávat opravdu pozor, protože náběh serveru je v řádu desítek sekund až minuty. A pro tyto případy se hodí JavaRebel.

Moje zkušenost je nyní celkem pozitivní. Používám poslední verzi 2.0-RC2 spolu s OC4J verze 10.1.3.4, k tomu IntelliJ IDEA verze 7.0.4. Intalace je velice jednoduchá - JavaRebel knihovnu se nahraje do classpath aplikace nebo serveru, upraví se spouštěcí soubor serveru a pro IDEU se ještě doinstaluje plugin, aby hezky fungovalo debuggování. Vše je popsáno zde.

S JavaRebel pracuji již přibližně měsíc a chvíli trvalo, než jsem si to vyladil. Měl jsem problémy s během aplikace, někdy mi dokonce spadnul z ničeho nic celý server. To se hodně zlepšilo s uvedením nové verze 2.0-RC2 (před tím jsem používal 2.0-M2). Také jsem musel vyloučit generované Java třídy z JSP stránek (přidal jsem při spouštění tento parametr -Drebel.packages_exclude=_oracle._jsp._tag). Teď mám pocit, že to opravdu funguje, jak bych si představoval.

Součástí JavaRebelu je i plugin pro Spring (pozn. pluginy jsou součástí JavaRebelu od verze 2.0-RC1, před tím bylo nutné si stáhnout pluginy odděleně). Ten by měl umět promítnout změny v konfiguraci Spring kontejneru v průběhu běžící aplikace. Tento plugin jsem krátce používal, ale měl jsem podezření, že mi kvůli tomu padá server, tak jsem ho zatím vypnul. Ale určitě se k němu ještě vrátím, až budu mít více času.

Díky udělátku JavaRebel se i s OC4J dá vyvíjet efektivně. Nástroj není sice zadarmo, ale cena 59 dolarů mi přijde velice příjemná, zejména když vezmu o kolik se mi zvýšila produktivita práce. JavaRebel je možné vyzkoušet po dobu 30 dní.

21. února 2009

IDEA vs. Eclipse - je někdo vůbec lepší?

Tento článek bude dalším příspěvkem do nekonečné diskuze, které to IDE je vlastně nejlepší. Nedělám si nároky, že by se mi to podařilo nějak vyřešit, ale cítím potřebu o tom napsat, hlavně abych si to sám srovnal.

Hlavním důvodem k napsání tohoto článku byla skutečnost, že jsem nyní po přibližně 4 letech přešel z Eclipse na IntelliJ IDEA. S Ideou jsem před tím již dělal, bylo to moje vůbec první IDE v Javě, tehdy ve verzi 4 (možná 3, teď již přesně nevím). Pamatuji si, že jsem tehdy za žádnou cenu nechtěl přejít na Eclipse, byl jsem s Ideou maximálně spokojený. Teď jsem změnu z Eclipse na Ideu celkem uvítal, byl jsem zvědavý si vyzkoušet zase něco jiného.

Zde jsou mé osobní pocity a postřehy z obou IDE.

Eclipse 3.3 (resp. MyEclipse 6.5)

  • + automatická kompilace kódu při uložení včetně stálého přehledu chyb a varování v celém projektu mi přišlo něco tak samozřejmého, že jsem byl překvapen, že to tak Idea třeba nemá. Auto-kompilaci při uložení jsem si nastavil, s těmi chybami nevím - ukazují se mi jen v rámci daného souboru a nebo při překladu celého projektu, pokud chci znát všechny problémy.
  • + pluginy, pluginy a pluginy - není žádné IDE, které by mělo takovou komunitu a takové množství pluginů. Ve srovnání s Ideou to může být ale i trochu nevýhoda - spoustu věcí si člověk musí doinstalovat sám, nejsou automaticky součástí. Toto už dneska asi moc problém není - já využívám MyEclipse (obsahuje cca 200 předinstalovaných pluginů) a nebo samotný Eclipse vychází v různých edicích, např. edice pro webový vývoj apod.
  • + Eclipse platforma se často používá jako základ pro vývoj dalších IDE, jako např. Websphere nástroje. Pak člověk ocení, že se nemusí učit od základu nové IDE, ale že to základní už vlastně zná.
  • - nejednotný přístup v různých typech souborů. Když chci vybrat slovo, tak bych očekával, že se to stejně bude chovat v Java, HTML, JSP, TXT souborech. Bohužel ne - někde se vyznačí celý výraz, někde jen slovo. Není to prostě jednotné jako třeba v Idee. Asi je to tím, že různé formáty souborů jsou podporovány různými pluginy, mezi kterými není úplná jednotnost.
  • - slabší podpora webových stránek. Dost často jsem psal JSP nebo JSF stránky a nebylo to úplně špatné, ale při přechodu na Ideu jsem zjistil, že to slabší bylo.


IntelliJ IDEA 7

    + klávesové zkratky - pokud někdo v oblibě klávesové zkratky, tak Idea je jasná volba. Myslím, že to mají "vychytaný" :).
  • + podpora Springu - SpringSource snad oficiálně vytváří plugin jen pro Eclipse, ale i přes to je v Idee podpora o dost dále (propojení beanů s Java kódem je prostě super).
  • + all-in-one - nainstaluji a můžu fungovat na 100%. Někdo namítá, že Idea už toho obsahuje až moc - je pravda, že většinu nevyužívám a již dříve ve verzi 4 jsem měl pocit, že to IDE nic více umět ani nemůže.
  • + podpora Java kódování - již ve 4. verzi Idei jsem byl nadšený z možností refactoringu, nápovědy a podobných věcí, které člověk využije, když programuje čistou Javu. Od té doby Eclipse hodně zamakal a dohnal náskok Idei, ale prostě pořád mi přijde, že Idea je v tomto směru nejdále - takové možnosti refactoringu, takové možnosti analýzy kódu, takové možnosti debuggingu prostě v Eclipse nejsou. Jeden příklad za všechny: provedu analýzu kódu na duplicity. Hned s ukázkou duplicitních částí mám možnost refactorovat - extrahovat duplicitu do jedné metody.
  • + kombinace s TeamCity a verzovacím systémem nemá chybu. Moc jsem si oblíbil tzv. Remote run - místo samotného "comitu" se nejdříve provede spuštění na TeamCity a pokud vše projde (kompilace, testy), tak pak se teprve provede commit.
  • - cena. Co k tomu napsat více? Eclipse nestojí nic, MyEclipse začíná na 32 dolarech za rok a Idea začíná na 225 eurech.


Závěr

Po přečtení možná budete mít pocit, že jsem velký fanda Idee. Tak to úplně není, dnes už tak netrvám na tom, že musím dělat v tom daném IDE a v ničem jiném. Nadšení z Idei je také určitě dané změnou - dělal jsem dlouho s Eclipsem a teď jsem nadšený z každé nové "fíčurky", kterou objevím.

Sám jsem přemýšlel, zda mohu napsat, že nějaké IDE je lepší než jiné - napsat to nemohu, protože každé má svoje a záleží na každém, co přesně preferuje. Já sám za sebe mám radši Ideu, ale koupil jsem si MyEclipse ...

23. prosince 2008

BIRT reports vs. Jasper Reports

Je to dost častý problém - aplikace sbírá data a tyto data je potřeba nějak prezentovat formou reportů. Standardní výstupní formáty jsou HTML (na prohlížení) a PDF (na tisk).

Asi nejznámější řešení na vytváření reportů je Jasper Reports (pěkný článek o Jasper Reports vyšel na Java.cz).

My jsme pro náš projekt zvolili jiné řešení - Eclipse BIRT reports.

Rád bych nyní uvedl takové malé srovnání Jasper Reports a BIRT reports (s laskavým souhlasem mého kolegy Ondřeje Světlíka, který měl reporty na starosti).

Společné vlastnosti

  • umí lokalizaci textů
  • umí přistupovat k datům přímo přes JDBC, ale i jinými způsoby
  • umí grafy
  • umí všechny možné výstupní formáty - pdf, html, doc/rtf, xls a další

Jasper Reports

  • + výrazně menší runtime - cca 5M
  • + editor podporuje přímo práci se Spring beany
  • - nutnost kompilovat .jrxml na .jasper
  • - horší editor
  • - neumí tabulky, skládají se pouze buňky, takže něco jako změna šířky celého sloupce najednou (hlavička, obsah, patička) je nemyslitelné

BIRT reports

  • + lepší editor
  • + editor součástí Eclipse i standalone
  • + umí tabulky
  • + stylování pomocí CSS
  • + umožňuje skriptování v JavaScriptu
  • - obrovský runtime - cca 42M
  • - pokud má být datovým zdrojem Spring bean, musí se použít skriptovaný datový zdroj
  • - větší nároky na PermGen space, je nutné spouštět tomcat s -XX:MaxPermSize=256m (odzkoušená hodnota, zřejmě bude fungovat i menší, ale default 64m nestačí)


Já bych ještě doplnil mé osobní pocity. Velikost BIRT enginu (engine musí být součástí aplikace, generuje samotné reporty) je opravdu značná, v konečném důsledku asi 50MB. To už je celkem nárůst velikosti aplikace, i když se jedná o server.

Moc se mi líbil editor a obecně možnosti BIRTu samotného. Spoustě lidí může vadit přítomnost Javascriptu, ale já s ním problém nemám.

Trochu jsme měli problém s češtinou v PDF reportech, ale to jsme vyřešili nastavením kódování cp1250 v souboru fontsConfig_pdf.xml.

Propojení BIRT enginu a samotné aplikace je realizováno přes servlet - servlet zjistí potřebné informace o reportu (většinou z URL adresy) a předá je BIRT enginu. Ten pak už jen vygeneruje výstup, který se odešle klientovi.

Všechny definice reportů jsou v XML, takže z pohledu verzování nebyl žádný problém.

Jediný problém, který jsme zatím nevyřešili, je horizontální stránkování při výstupu do PDF. Toto BIRT ještě neumí.

S Jasper Reports jsem nikdy moc nedělal, ale asi už ani dělat nebudu. BIRT mě celkem zaujal...

Další odkazy

13. června 2008

Nástroje SoapUI a JMeter

Uvedené nástroje používám již několik let a myslel jsem si, že jsou natolik známé a rozšířené mezi programátory, že ani nemá cenu se psát, jestli je někdo zná. Překvapivě jsem se mýlil.

JMeter je nástroj pro měření výkonnosti a pro vytváření umělé zátěže na webových projektech. Je to spíše nástroj "pro začátek" - tím myslím to, že kdo opravdu řeší problematiku výkonnosti, robustnosti a škálovatelnosti aplikací, tak asi bude používat jiné, komerční nástroje. Já si většinou pouze chci ověřit, že mnou napsaná aplikace běhá dle očekávání, že tam není vyloženě nějaký problém třeba v konkurenčním přístupu více uživatelů apod. V tomto ohledu naprosto dostačující nástroj.

Bez nástroje SoapUI si vývoj webových služeb vůbec nedovedu představit. Vždy když se vytvoří nová webová služba nebo se nějaká již existující integruje, tak je potřeba si ověřit komunikaci pomocí nějakého klienta. SoupUI není pouze klientem webové služby, ale celkem sofistikovaný nástroj pro jejich vytváření a testování.

Oba dva nástroje jsou samozřejmě open-source, tedy zdarma.

9. června 2008

Znáte Daisy?

Mě tento CMS nástroj doporučil kolega, já ho úspěšně použil pro jednoho zákazníka a tak pozitivní zkušenost šířím dál.

Je to již nějaký čas, co jsem Daisy používal, ale zrovna minulý týden se na mě kamarád obrátil pro radu, tak jsem si na Daisy znovu vzpomněl.

Na Daisy jsem oceňoval hlavně tyto věci:

  • aplikace je napsaná v Javě, takže pro mě není problém aplikaci kustomizovat

  • přišla mi velice intuitivní, takže jsem se s tím velice rychle naučil

  • udělal jsem tam vše, co jsem potřeboval - zákazníkovi jsme pomocí Daisy vytvářeli skladiště dokumentace k projektům. Bylo tedy potřeba vytvořit nějakou základní strukturu úložiště pro uložení dat včetně nastavení přístupových práv. Vložené dokumenty (zejména MS Word) se automaticky indexují a lze přes ně fulltextově vyhledávat. Daisy je natolik uživatelsky přívětivé, že zákazník po zaškolení používá aplikaci sám.

Ve svých poznámkách jsem našel jedinou nevýhodu, se kterou jsem se potkal - měl jsem občas problém s češtinou při fulltextovém vyhledávání (používal jsem verzi 2.1). Neměl jsem čas a ani prostor to moc řešit, takže ani nevím, jak to dopadlo.

14. prosince 2007

Hudson - děkuji, rád

V poslední době se mi zdá, že se více než kdy před tím řeší, který že build server je ten nejlepší. Možná je to jen můj subjektivní pohled nebo možná je to také tím, že čím dál tím více lidí má povědomí o "postupné integraci" (continuous integration) a znají nesporné výhody tohoto přístupu.

Hned na začátku říkám, že mám rád Hudson. Už to bude přibližně rok, kdy jsem vybíral buildovací server do naší firmy a při svém výběru jsem víceméně vycházel z nástrojů uvedených v tomto článku. Hned od začátku to byla "láska na první pohled":

  • velice jednoduchá instalace. Slovíčko instalace je přehnané, protože stačí pouze nahrát soubor hudson.war na aplikační server a už vše funguje. S tím je samozřejmě spojen i bezproblémový upgrade, což se zde celkem využije, protože skoro každý den vzniká nová verze.

  • velice jednoduchá konfigurace všeho potřebného. Konfigurace je intuitivní a přímo obsahuje nápovědu, takže není potřeba žádná dokumentace.

  • Hudson nabízí přesně to, co potřebujeme a nic navíc. Používáme Subversion, nemáme (zatím) žádné složité vazby mezi projekty, v každém buildu chceme mít přístup k JavaDoc dokumentaci, výsledkům testů a k informacím z konzole. Pro sledování výsledků buildů nám stačí RSS nebo Email. Pro ty, kdo používají něco jiného než Subversion nebo mají větší nároky na integraci nástrojů třetích stran, tak budou mít s Hudsonem asi problém.

  • S tou integrací nástrojů třetích stran už to také není tak špatné jako třeba před rokem. Úspěšně jsme teď zaintegrovali nástroje FindBugs a Cobertura. Ostatní nástroje pro detekci chyb či něčeho jiného (Checkstyle, PDM, JDepend) sice používáme, ale zatím bohužel bez přímé integrace s Hudsonem. Detailní výsledky máme možnost vidět pouze z výpisu konzole.




Teď si připadám jak na střední na konci referátu o knížce: Hudson se mi velice libíl a všem bych ho jen doporučil :).

Přehled dalších buildovacích serverů:

13. prosince 2007

Apache Forrest - děkuji, nechci

V poslední době jsem musel malinko oželet programování vlastních aplikací, protože jsem více řešil nasazení a konfiguraci produktů třetích stran. Jedním z nich byl produkt se jménem Apache Forrest.

K čemu je Apache Forrest dobrý? Je dobrý k tomu, když si potřebuji vytvořit webovou prezentaci (a nechci ji vytvářet sám přímo pomocí HTML), když chci mít na webu automaticky řadu zajímavých funkcí jako fulltextové vyhledávání, tisk, export do PDF a hlavně, když mám již spoustu dokumentů (různé obrázky, HTML, PDF atd.), které bych rád znovu využil. Pokud chci vytvářet obsah webu sám, pak mám možnost použít celkem intuitivní pseudo-HTML jazyk. Úvodem je ještě vhodné uvést, že například většina projektů Apache má web vytvořený právě pomocí tohoto nástroje.

Podle toho, co jsem doposud napsal by se mohlo zdát, že je to super mocný nástroj. Bohužel jsem si to na začátku taky myslel, ale teď už moc ne. Ale postupně...

Formáty dokumentů

Apache Forrest umí pracovat na vstupu s různými formáty dokumentů a to díky rozšířením Apache Forrest (tzn. pluginy). Základní konfigurace umožňuje na vstupu použít následující formáty dokumentů (kromě dokumentů zapsaných přímo ve formátu Apache Forrest XML):
  • XML

  • HTML

  • MS Excel (tabulka z MS Excel musí být uložena jako Tabulka XML)

  • OpenOffice (Impress, Writer) verze 1 (přípona .sxw)

U těchto vstupních formátů se dokumenty přímo upraví do jednotného vzhledu a struktury webu. Samozřejmě je možné formou odkazu přímo na dokument připojit dokument v libovolném formátu – ten pak sice nebude zpracován a převeden do HTML, ale bude možné jej stáhnout.
Bohužel není možné přímo integrovat nejrozšířenější dokumenty MS Word. Jde to ale obejít přes OpenOffice – dokument z MS Word načtu v OpenOffice a uložím ve formátu OpenOffice (sxw).

Apache Forrest jsem intenzivně používal přes dva týdny a na základě této zkušenosti mohu uvést následující výhody a nevýhody:

Výhody

  • Vzhled webu lze kompletně upravit pomocí CSS (viz projekty Apache).

  • Velké množství vlastností výsledného webu je možné upravit pouze pomocí konfigurace

  • Žádný srovnatelný nástroj (se stejným zaměřením) se mi nepodařilo najít.

Nevýhody

  • Apache Forrest si moc nerozumí s češtinou - měl jsem problémy s českou diakritikou při exportu do PDF nebo při importu dokumentů z OpenOffice.

  • Nepodařilo se mi vůbec rozchodit fulltextové vyhledávání s Lucene. Varianta s Google fungovala dobře.

  • Apache Forrest je v současné verzi 0.8 a moc to nenasvědčuje tomu, že by se v brzké době objevila nějaká stabilní verze 1.0. Když jsme tento nástroj vybírali do jedné nabídky na konci roku 2006, tak byla verze 0.7.

  • Z uživatelského hlediska se nejedná o zrovna přívětivý nástroj. Vše je ovládané pouze z příkazové řádky.


Po všech uvedených nevýhodách jsme byli nuceni přejít na jiné řešení se jménem Daisy. Sice je to řešení z kategorie CMS a tedy směřované trochu jiným směrem než Apache Forrest, nicméně základ je opět postavený nad nástrojem Apache Cocoon a tedy z hlediska možností práce s dokumenty velice podobné. Všechny nevýhody Apache Forrest jsou v Daisy vyřešeny a řada výhod zůstala.