Konec roku svádí k bilancování. A nad čím jiným se ohlížet na odborném blogu než nad technologiemi. Těmi nadějnými, těmi, bez kterých by se dnešní internet neobešel i těmi, které již zahrabal Děda Mráz na smetišti dějin. Zanořil jsem se do své děravé paměti a hledal jsem technologie, které svého času doporučoval kde kdo (jen zpravidla ne ten, kdo je používal)…

Níže uvedené letopočty, přiřazené k technologiím, jsou mým odhadem nebo prostou statistikou vzniklou při procházení historickými články na českém internetu. Starší technologie lze zpravidla zařadit mezi odepsané. Některé se ovšem vžily a patří mezi „pravdy, nad kterými se nepochybuje“. S novějšími letopočty přibývá technologií, které vypadají nadějně.

Před několika lety jsem spolu s kolegou vyvíjel jeden docela obsáhlý program. Byla to úspěšná aplikace, která se dodnes používá, udržuje a dále rozvíjí. Když se podívám do zdrojových kódů, dodnes v nich najdu kódy napsané v mém vlastním stylu. Možná si říkáte, že bych měl být hrdý a všem tvrdit, jak jsem umění programování zvádl svým jedinečným stylem. Není tomu tak, po přečtení tohoto článku budete vědět proč.

Code Review je revize kódů někým jiným než autorem. Nevím, kde a kdy Code Review vzniklo, Wikipedia mlčí. Předpokládám, že tam, kde jde doslova o život, což napovídá stránka zaznamenáníhodných chyb na wikipedii. Obzvlášť zajímavá je známá chyba v záměně desetinné tečky a čárky v jazyce Forth v kosmické sondě Mariner 1. Dá se říci, že kdyby NASA dělala Code Review, tak by sonda dopadla lépe…

(Fotografie ze startu jmenované sondy byla převzata odsud.)

Ponejprv musím poblahopřát vývojářům z firmy SoftEU k nové verzi aplikace WinStrom. Vytvořit a prodávat komerční krabicovou aplikaci vytvořenou v Javě, navíc v ČR a v oblasti ERP, považuji za úctyhodný výkon. Potěšilo mě, že se někdo snaží prosadit Javu na klientské straně, přeci jen je Java více etablovaná na serverech v korporátní sféře…

I přesto, že autor článku raději moc z pozadí vývoje neprozrazuje, bylo to pro mě zajímavé čtení. Nejzajímavější byly ty části, které přímo či nepřímo popisovaly principy použité při vývoji, například:

• pokus o použití Apache Derby
• snaha o perfektní instalátory
• použití nativního L&F

O nic z uvedeného bych se nikdy nepokoušel, nedávalo by mi to smysl. Nejdřív jsem si říkal, že rozdílnost přístupů spočívá v technologiích – přeci jen vyvíjet zakázkové webové aplikace a krabicové client-server aplikace je rozdíl. Pak mi došlo, že rozdíl může být ještě někde jinde – nazval jsem to slovem paradigma…

Nadešel tedy, po několika technologických článcích, čas na úvahu.

UML je užitečný nástroj pro vývoj SW. Jen je potřeba znát jeho omezení, je potřeba vědět, kdy a k čemu se hodí a jak ho používat. Bohužel většina materiálů o UML se zabývá syntaxí tohoto grafického jazyka, ale málokdy je ukázáno použití na reálné, například webové aplikaci. Sepsal jsem tedy pár praktických poznámek na téma UML.

Míra podrobnosti

Snad největším bariérou při kreslení UML je to, že s vyjímkou školních úloh (a úloh v knihách o UML) je problém složitý a obsáhlý (kdyby takový nebyl, tak nebudeme používat UML, že…). A o to jde: po počátečním nadšení nad „kreslítkem“ zanedlouho zjistíte, že nadpoloviční většina problématiky zůstává stále nepodchycená. S přibližujícím se termínem hotové analýzy pak začnete pronášet něco takového jako „ve Wordu už bych to měl dávno“. Přesně v ten okamžik víte, že jste nezvládli míru detailu.

Problém není v UML. Při psaní textové analýzy každý intuitivně tuší, že text je nepřesný a abstrahující, naopak UML má prostředky, kdy je možné zajít až do implementačních detailů, které jsou zpravidla v zadání nedůležité.

Nové moderní metodiky vývoje se často vymezují vůči vodopádovému vývoji. Člověk snadno nabyde dojmu, že nic horšího než vodopádový model vývoje být snad ani nemůže. Bohužel žádná z nových, ale ani starých metodik není dokonalá, vždy a na vše použitelná. Rád bych ve svém článku ukázal, že vodopádový přístup je přinejmenší dobrou inspirací.

Je zvláštní, že při hledání vhodného obrázku „s vodopádem“ jsem našel obrázků spousty, ale každému něco chybělo. Rozhodl jsem se tedy nakreslit svoji variantu. Právě jí se týkají moje úvahy.

Nedávno mě zaujal článek vydaný na Computerworldu. Je to útržek z první kapitoly knihy Secrets of the Rock Star Programmers.

Ed Burns zpovídá Roda Johnsona a řeč přijde na to, jaké jsou vlastnosti úspěšných vývojářů. Není bez zajimavosti, že se tu baví šéf architekti dvou velmi rozšířených webových frameworků pro Javu: JSF a Spring MVC, podle všech měřítek oba úspěšní programátoři.

Podle Roda Johnsona úspěšným vývojářům nechybí:

Další zastávkou na mé cestě při hledání bug tracking systému bylo Eventum. Jde o open source aplikaci od firmy MySQL. Jde o promyšlený software, který tato firma používá i pro podporu svých zákazníků.

Aplikaci je možné stáhnout z webu MySQL. Na webu je možné najít několik náhledů na stránky, v následujícím textu ukážu několik nejzajímavějších funkcí.

Eventum umožňuje definovat vlastní stavy, a to pro každý projekt zvlášť.

Eventum je velmi dobré ve sledování času, stráveného při řešení problémů.

Odhadovaný čas je možné přiřadit k problému.

Před několika měsíci jsem dostal za úkol najít kvalitní program na sledování chyb a požadavků na aplikaci. Během hledání té správné aplikace jsem vyzkoušel několik open source i komerčních aplikací. Mantis byl jednou z nich. Nechci se zde rozepisovat, co by měl bug tracking system umět, ale rád bych ukázal pár pokročilých funkcí Mantisu…

Před mnoha lety jsme ve firmě na totéž používali MS Excel. Jednoduchá a přímočará tabulka (s krycím názvem ToDo) znázorňující co, kdo a do kdy má udělat. Tenkrát několik málo lidí vyvíjelo a udržovalo jednu jedinou aplikaci v jediné instalaci pro jediného zákazníka. Pragmatické využití Excelu fungovalo dobře do té doby, než bylo potřeba, aby do tabulky zapisoval i zákazník. Bohužel sdílet jeden Excelovou tabulku je možné přes LAN, ale ne přes internet…

Dlouhou dobu jsme používali proprietální systém, ke kterému jsme měli zdrojové kódy. Byla užitečné mít možnost definovat si vlastní systém přístupových práv, vlastní políčka v datech či vlastní workflow. I tato aplikace přestala stačit, tak začalo mé hledání…

Na první pohled vypadá barevnost úkolů v Mantisu zběsile, ale je mimořádně praktická. Barvy označují stav.

Už odteklo hodně vody ve Ponávce, co jsme zavedli kontinuální integraci pomocí Hudsonu a Mavenu. Nastal čas na krátké zhodnocení. Kontinuální integrace je součástí metodik extrémního programování. Ačkoliv neprogramujeme extrémně, má pro nás kontinuální integrace smysl, popišme si krátce jaký.

Jedním z pravidel pro práci s repository je to, že vývojář do verzovacího systému commituje jen takový kód, který je přeložitelný. (Nemusí být ovšem funkční – závisí na konvencích konkrétního projektu). Pravidlo je to pěkné, ale funguje lépe, když existuje nějaký mechanismus, který prověří jeho dodržení. A přesně to Hudson umí – po nepodařeném commitu pošle „hřišníkovi“ nikoliv golema, ale varový email.

Pod lákavým názvem Vývoj softwaru – největší mýty naleznete sepsaných 24 vývojářských paradigmat. Jen je potřeba je převést do negace, což ale napoví až poslední odstavec. A zařazení do kategorie „humor“.

Nicméně nutno poznamenat, že nové metodiky (extrémní, agilní a jiné programování) velmi často některý z aspektů klasického vodopádového vývoje přinejmenším zpochybňují. Proč? Protože klasický vodopád je drahý a vždy se nehodí. Napadají mě dva případy…