Jiří Hradil blog

1. Ideální software je takový, který neexistuje.
2. Pokud existuje, ať není vidět.
3. Pokud je vidět, ať v něm pracují jen roboti.
4. Pokud v něm musí pracovat člověk, ať tam tráví minimum času s maximální efektivitou.
5. Minimum času musí být zábava.
6. Časem rozumíme vteřiny, největší jednotkou budiž minuty.
7. Efektivitou budiž chytrost.
8. Software pomáhá, software neotravuje. Ani člověka, ani robota.
9. Pokud software otravuje, nesmí existovat.
10. Pokud nechápeme některé z pravidel, držme se pouze pravidla č. 1 a raději nic nepišme.

Aktuální informace přímo od zdroje - Oracle a Sun Microsystems vstupují do konečné fáze dohody, podle které Oracle koupí Sun za cca 7.4 miliardy dolarů. Oracle tak získává Javu, Solaris a ostatní technologie (zdroj: Sun Microsystems: Oracle to buy Sun). Vedle nezajímavých řečí o 20-letém partnersví a obrovském přínosu pro komunitu, uživatele, atd. bude velmi zajímavé sledovat skutečný důsledek této akvizice.

Sun byl sice skvělý technologický inovátor, ale svým technologiím nedokázal přinést vhodný obchodní model. Takže se necháme překvapit, co Oracle konkrétně s Javou provede. Co myslíte?

Proces vývoje software odráží několik posledních let jasný trend - nestálost prostředí a připravenost na změny. Pokud shrneme několik agilních metodik (extrémní programování, Scrum, RUP), tak řeší v podstatě naprosto stejné věci-krátké iterace, testy, otevřenost, zeptej se kódu, atd.  Některé z těchto pravidel rozeberu.

Vyvíjíme po malých částech, čili v iteracích=cyklech=sprintech. Jedním z důvodů je nestálost prostředí, ve kterém má být software používán (např. situace na trhu či legislativa), ale hlavně neschopnost a nemožnost vyprodukovat stabilní analýzu systému, podle které se dá programovat. Analytiky software považuji za dinosaury, jejichž doba dávno skončila a při vývoji software jednoduše nejsou potřeba. Základ software z pohledu uživatele má navrhnout klient a proveditelnost návrhu určují koneční vývojáři. Setkal jsem se s tím, že analytik (který nikdy neprogramoval), vygeneroval stovky stránek krásných diagramů a dokumentů, které si nechal nebohým klientem schválit. Klient samozřejmě netušil, co ty obrázky znamenají (když ony byly tak hezky barevné…). Poté se tento stoh dokumentů předhodil vývojářům, kteří obrázkům taky nerozumněli, ale dostali jasný pokyn - “programujte!” Po několikaměsíčním vývoji při prezentaci systému klient zjistil, že vlastně teď potřebuje už něco úplně jiného a software se do produkce vůbec nedostal.

Doporučení:

• iterace je dlouhá max. 1 měsíc, v počátcích vývoje kratší, klidně i 1 týden
• vývojáře musíme protlačit ke klientovi, protože jedině zadavatel a tvůrce systému umí pokládat správné otázky a generovat správné odpovědi
• po každé iteraci následuje prezentace klientovi, který potvrdí aktuální verzi a na jejím základě generuje požadavky další
• popis systému je obsažen ve zdrojovém kódu a v uživatelských zadáních
• podrobná dokumentace je zbytečná - vývojáři ji nepotřebují, tvůrce ji musí aktualizovat a koneční uživatelé jsou tak frustrovaní množstvím software, který musí ovládat, že ji číst nebudou. Složitá sice může být problémová doména, kterou software řeší (třeba statistický software), ale nikdy nesmí být složitý software samotný. Pokud např. posadíme statistika k našemu statistickému softwaru, musí ho být schopen do několika minut bez problémů ovládat, protože ovládá problémovou doménu, do které je náš software zasazen a kopíruje ji.

Testujeme - test simuluje používání systému uživatelem. Ať už to schováno pod pojmy test jednotkový (na úrovni metody), integrační (na úrovni větší části systému), zátěžový, opičí, či jiný, smyslem testu je software nastartovat, aby ukázal, co umí. Testy se mají psát průběžně a to z toho důvodu, že na konci je už nikdo psát nebude. Stejně tak s každým testem vytvoříme nekonečného automatického robota, který nám bude hlásit, jestli pořád software dělá, co dělat má. Psaní testů z krátkodobého pohledu zdržuje, ale dlouhodobě nám právě testy drží software stabilní.

Doporučení:

• kontrolovat pokrytí software testy (např. v Javě přes Cobertura), stanovit si hranici, pod kterou nesmíme jít, ideálně nad 80%)
• maximálně urychlit psaní a spouštění testů (mock objekty, databáze v paměti)
• nepřetržitě integrujeme pomocí integračního serveru (Continuum, Hudson, Bamboo…)

Jsme malí - neudržujme velké týmy. Čím více vývojářů, tím více tření, komunikace, rozhodování, administrativy a neefektivity, kterou nakonec (zbytečně) platí klient.

Doporučení:

• ideální velikost týmu je 3-5 vývojářů, pokud se jich vývoje účastní více, uděláme více týmů a každý z nich má svou problémovou doménu. Tyto týmy však musí být vzájemně synchronizovány, např. pomocí scrum of scrums-porad, kterých se účastní pouze vyhrazený člověk z každého týmu, nikoli všichni členové  dohromady.

Posaďme tým dohromady, čili  “seat the team together”. Tým musí sedět pohromadě. Tečka. Tohle je nejrychlejší způsob řešení komplikací během vývoje a udržení synchronizovaných znalostí o systému. Pokud má kdokoli v týmu otázku, může ji položit a dostane se mu okamžité odpovědi.

Doporučení:

• respektovat klid pro práci - pokud máme otázku, nekřičíme na celou místnost, ale zeptáme se, zda můžeme vyrušit, v extrémních případech si zavedeme každou hodinu několik minut na otázky a odpovědi
• červená čepice - jednoduché pravidlo - v týmu je k dispozici symbol “červené čepice” (ať už cedulka, nebo opravdová kšiltovka), kdo ji má na hlavě, ten nesmí být rušen
• nepracovat z domova přes Internet, bohužel, zatím se ukazuje, že je stále efektivnější být fyzicky pohromadě v 1 místnosti, než komunikovat přes Skype, Jabber, atd. Budu rád, když mi tuto neefektivitu někdo vyvrátí a přidá praktické zkušenosti.

Bez marketingu nemůže existovat žádný produkt, softwarový nevyjímaje. Jednou z velmi efektivních a dnes používaných forem marketingu je word of mouth, čili “šeptanda”.

Placená reklama je drahá a krátkodobá.  Lepší je mít produkt tak vyčnívající z řady, že si na něj reference předají uživatelé sami. Kromě vlastní zkušenosti neexistuje důvěryhodnější zdroj, než spokojený kamarád, který software doporučil. Třeba Google, v době uvedení služby Gmail, šokoval velikostí schránky 1 GB a také systémem pozvánek, kterých bylo omezené množství. Google si tak otestoval postupné škálování celého systému a zároveň vzbudil u uživatelů, vlastnících účet, dojem exkluzivity. O Gmailu se hodně mluvilo, sám jsem o něm v počátcích psal. Samotné datum uvedení - 1.4.2004, tedy na apríla, je dalším výborným tahem, který zajistil, že byl Gmail chápán jako vtip (tak velká schránka přece neexistuje) a o to víc se o něm mluvilo a psalo. Stejně tak označení Beta (po 5 letech v produkci) je  nejen omluvou za případné potíže, ale i potvrzením, že používáte čerstvý software, který ještě nevychladnul a jste “in”.

Gmail však přežil hlavně díky tomu, že byl a stále je jednoduchý. Dobře se používá a prostě funguje. Rozbořil zažité koncepty (nepotřebujete složky, atd.). Je jiný a proto uspěl.

A závěr tohoto příspěvku pro vývojáře software? Odlišujte se. Přemýšlejte, čím váš software vybočuje z řady. Uniformních řešení jsou dnes stovky. Vy píšete software, který si zaslouží být jiný.  Mějte však na zřeteli, že software píšete pro lidi, ne pro technologii samotnou. Protože jedině v případě, že se váš software používá a koncoví uživatelé jsou s ním spokojeni, jste jako vývojáři uspěli.

Z nepřeberného množství nástrojů určených k vývoji aplikací v Javě nyní zkoušíme kombinaci Java Server Faces a Hibernate. Proč právě tyto technologie?

Java Server Faces:
+ technologie vyvíjená a podporovaná Sunem
+ perfektní oddělení view od logiky aplikace
+ jednoduchost
+ možnost tvorby vlastních komponent
- nová technologie, nedostatek tutoriálů a zkušeností při vývoji
- chybí některé základní komponenty (file upload), nicméně byly již napsány třetími stranami (Oracle ADF, MyFaces)

Hibernate:
+ výkonné řešení persistence v Javě
+ relativní jednoduchost používání
+ široká vývojářská základna - mám dojem, že všichni používají Hibernate
- chabá oficiální dokumentace
- trvá dlouho, než pochopíte souvislosti mezi všemi objekty a naučíte se je efektivně používat
- není od Sunu (ano, pro mě je tato maličkost docela důležitá

Instalace JSF:
1. Stáhneme JSF 1.1 ze stránek Sunu.
2. Soubory {JSF}/lib/*.jar zkopírujeme do adresáře knihoven aplikačního serveru (viz. konfigurace Tomcatu).

Instalace JSTL:
1. Stáhneme Jakarta Taglibs Standard Library 1.1.2
2. Zkopírujeme {JSTL}/lib/*.jar do adresáře knihoven aplikačního serveru (viz. konfigurace Tomcatu).

Konfigurace Tomcatu:
$CATALINA_HOME/shared/lib - zde se nachazi sdilene knihovny, ktere budou pouzivat vsechny nase web aplikace.
$CATALINA_HOME/common/lib - knihovny umístěné sem jsou viditelné jak našim aplikacím, tak internímu kódu Tomcatu.
Pro JSF a JSTL jsem zvolil $CATALINA_HOME/shared/lib

Instalace JDBC:
1. JAR soubor s ovladači k rozhraní JDBC ( např. u PostgreSQL soubor pg74.215.jdbc2ee.jar) zkopírujeme do $CATALINA_HOME/common/lib

Instalace Hibernate:
1. Stáhneme Hibernate 2.1.6 a Hibernate-extensions 2.1.2 ze Sourceforge.
2. Hibernate vyžaduje, aby všechny jeho knihovny byly součástí WEB-INB/lib u každého projektu. Prý by pak nastaly problémy s nástroji jako Log4j, commons-logging a dalšími (ještě jsem nezkoušel) .
Znamená to, že pokud vyvíjíme Hibernate aplikaci, kterou potřebujeme opakovaně zkoušet-deployovat na vzdálený Tomcat server, tak vytvořený war archiv bude neúměrně velký právě díky těmto knihovnám :). Pokud nemáme rychlé inet připojení, je vhodné instalovat Tomcat lokálně.
Není však třeba kopírovat všechny knihovny z {HIBERNATE}/lib/, stačí jen ty, které potřebujeme. Seznam vyžadovaných a volitelných najdeme v {HIBERNATE}/lib/README.txt}
Jak řešíte instalaci Hibernate knihoven vy?

Hibernate-extensions:
Tady najdeme pomocné nástroje k Hibernate, např. hbm2java (CodeGenerator) a class2hbm (MapGenerator). Tyto knihovny většinou nepoužíváme přímo v našich aplikacích, spíše k počáteční inicializaci - vytvoření základních java souborů z hibernate mappings, nebo skeletonu hibernate mappings ze zkompilovaných tříd (pomocí reflexe)-jedná se však jen o zakladní generaci, která vyžaduje ruční doladění.

Odkazy:
Java Server Faces Technology
Hibernate
Jakarta Tomcat
JSP(tm) Standard Tag Library
Oracle ADF
MyFaces

UPDATE 24.11.2004: Doplněna instalace JSTL a zbývajících knihoven JSF.

My všichni, kdo používáme blogovací systém Blogger.com a potřebujeme konvertovat Atom XML do RSS, můžeme využít služeb 2RSS.com, kde je k dispozici konverzní odkaz či formulář.

Ukázkový odkaz:

http://www.2rss.com/atom2rss.php?atom=http://hradil.cz/atom.xml

Základní služba je k dispozici zdarma, do RSS jen přidává reklamu na produkty 2RSS (jeden řádek), což se dá přežít.
Placená verze stojí $14.95/rok a reklamu neobsahuje.

Dříve jsem používal formulář na Loosely Coupled, teď mi však nefunguje. Blogger.com doporučuje službu FeedBurner, ještě jsem to však nezkoušel.

Práci s MS Office soubory v Javě nám jistě usnadní framework Jakarta POI.

POI obsahuje tyto komponenty:

POIFS - port OLE 2 Compound Document format, na tomto portu jsou založeny všechny následující komponenty.
HSSF - port MS Excel 97-2002 do Javy. Podporuje čtení souborů a jejich zápis.
HWPF - port MS Word 97-2002. Podporuje čtení a zápis. Tato komponenta je v ranné fázi vývoje a je zpřístupěna jen přes CVS.
HPSF - port pro nastavení vlastností souborů (jméno dokumentu, autor, datum poslední modifikace). Zatím podporuje pouze čtení těchto vlastností.

Pro ukázku možností si jednoduše vygenerujeme MS Excel soubor:

import java.io.FileOutputStream;
import org.apache.poi.hssf.usermodel.*;
import org.apache.poi.hssf.util.*;

/**
 * Vytvoreni testovaciho MS Excel souboru pomoci Jakarta POI
 * (http://jakarta.apache.org/poi/)
 * @author  Jirka Hradil
 */
public class TestExcelSouboru {

    /**
     * @param args ignorovano
     */
    public static void main(String[] args) throws Exception {
        HSSFWorkbook sesit = new HSSFWorkbook(); //novy MS Excel sesit
        HSSFCellStyle styl = sesit.createCellStyle(); //novy styl
        HSSFSheet list = sesit.createSheet(); //novy list v sesitu
        HSSFRow prvniRadek = list.createRow(0); //vytvorime radek
        HSSFCell prvniBunka = prvniRadek.createCell((short) 0); //a v radku bunku

        //nastavime kodovani bunky na UTF
        prvniBunka.setEncoding(HSSFCell.ENCODING_UTF_16);
        //pojmenujeme prvni list
        sesit.setSheetName(0, "žluťoučký kůň", HSSFWorkbook.ENCODING_UTF_16);

        //pridame text do bunky
        prvniBunka.setCellValue("Příliš žluťoučký kůň úpěl ďábelské ódy!");

        //stylu nastavime pattern-jednolita barva
        styl.setFillPattern(HSSFCellStyle.SOLID_FOREGROUND);
        //nastavime barvu stylu, zluta barva
        styl.setFillForegroundColor(HSSFColor.YELLOW.index);

        prvniBunka.setCellStyle(styl); //a priradime styl bunce

        //stream pro vystup
        FileOutputStream vystup = new FileOutputStream("c:/vystup.xls");

        sesit.write(vystup); //zapiseme vystup do souboru
    }
}

ODKAZY:
Jakarta POI
Jakarta POI HSSF: Excell-ové tabulky v kostce
Jakarta POI 2.0 FINAL

Jen taková drobnost-jak nastavíme Operu, aby spustila Java Web Start aplikaci po nakliknutí na odkaz *.jnlp?

Tools/Preferences/File types/New/předvyplníme údaje

Pak zbývá jen Operu restartovat a vše funguje, jak má.

Již několik dní si uživatelé služby Blogger mohou vyzkoušet novou verzi systému, která přináší změny a vylepšení pro všechny, kdo chtějí blogovat-rychle a s minimálním úsilím.
Nová verze je opět o krok blíž dokonalosti, avšak nevyhnula se ani několika nedostatkům, které, (alespoň doufám) budou brzy opraveny.

Nejdříve zmíním největší pozitiva (nového/starého) Bloggeru:

Nenáročnost na cílové platformě
Jediný požadavek pro plnohodnotnou práci se systémem je místo na WWW serveru (Blogger nabízí virtuální server pro ty, kteří nemají vlastní, něco jako sweb.cz, centrum.cz, aj.). Žádný scriptovací jazyk, či databáze není třeba. Zadávání příspěvků probíhá přes browser, který poté vygeneruje dokonale provázané HTML stránky a uploaduje je přes (S)FTP na server.

Komentování příspěvků
I přes “absenci” dynamických stránek lze jednotlivé příspěvky komentovat-Blogger po zadání příspěvku na serveru automaticky statické stránky přegeneruje.

UPDATE 23.5.2004: Přešel jsem zpátky k HaloScan. Komentování přes Blogger vyžaduje navíc přihlášení a není možné komentáře zpřístupnit přes RSS.

Blogování přes mail
Zřídíme si adresu uzivatel.tajnyretezec@blogger.com a cokoli na tuto adresu pošleme, může být vystaveno (nebo odloženo pro pozdější publikování) na blog. I čeština funguje perfektně.

Blogovat může více uživatelů najednou
Tuto možnost využívá třeba Roman Pichlík.

Nové šablony
Pro nás kdysidávnowebdesignéry je jistě příjemné zvolit si existující šablonu a nestarat se tak o návrh blogu. Současná tvář tohoto blogu jednu z těchto nových šablon využívá.
UPDATE 23.5.2004: Nyní používám vlastní šablonu, mám více místa na text a vylepšené CSS (např. zobrazení zdrojového kódu Javy exportuji přímo z NetBeans IDE).

Profil uživatele
Ano, ten rámeček s fotkou vpravo, to jsem já :). Po nakliknutí jsou k dispozici předvyplněné údaje a pokud má uživatel více blogů, může se rozhodnout, u kterého z nich profil nechá zobrazit.
UPDATE 23.5.2004: Zobrazení profilu jsem zrušil. Zabírá místo a není až tak důležitý.

Nyní se podíváme na nedostatky:

Samovolné přegenerování uložené šablony
Zřejmě na Bloggeru fungují nějaké pozdní replikace uložených dat. Jednou se mi stalo, že systém se po přegenerování příspěvků vrátil k několik hodin staré šabloně a vesele mi tak změnil uloženou šablonu novou. Podruhé to samé zopakoval při komentování mého příspěvku. Protože jsou stránky na serveru statické HTML, tak po každém nově vystaveném příspěvku se provede nový upload stránky na web server. A právě pro šablonu aktualizované stránky sáhnul Blogger jinam než měl a web měl rázem starou tvář.

Pracné přidávání komentářů ke starým příspěvkům
Pokud chceme využívat komentovací systém, je nutno editovat postupně každý příspěvek, povolit možnost komentování samostatně a pak každou stránku zvlášť přegenerovat na cílovém serveru. Proč nejde u příspěvků změny pouze uložit a pak vše publikovat najednou?

Nedostatečné možnosti parametrizace
Přes veškerou snahu nelze některé texty přenastavit. Jedna z nich je profil (tak rád bych přepsal “About Me” na něco líbivějšího :), pak třeba v komentářích volba “Post a Comment”.

Přes všechny trable však zůstávám Bloggeru věrný a pevně věřím, že všechny zmíněné nedostatky budou postupně odstraněny.

Některá další pozitiva/negativa můžeme najít v následujích odkazech.

ODKAZY:
The Great Blogger Relaunch
Nový Blogger.com - ošklivé káčátko?
Blogger.com v novém - a lepším!
Blogger.com - výborný systém od Google!