V poslední době jsem zjistil, že některé věci, které já považuji za samozřejmé, pokud se rozhlédnu kolem sebe, tak úplně samozřejmé nejsou. Jednou z nich je debugování Javovského kódu. I v dnešní době, kdy je podpora ze strany technologií na perfektní úrovni je mnoho vývojářů, kteří pro rutinní vývoj (nemluvím o řešení problémů po nasazení aplikace) a odlaďování kódu debuggování nepoužívají a spoléhají se na záznamy z logu. Je pravda, že tento přístup má své výhody – obvykle se tímto způsobem obohatí kód dostatečným množstvím logů, že i v produkci je obvykle dost informací k řešení problémů, pokud nastanou. Zásadní nevýhodou, kterou v tom spatřuji já je naprosto drastické snížení produktivity programování. Problém, který se dá vyřešit během půl minuty vložením breakpointu na správné místo v kódu se může v případě procházení logů protáhnout klidně i na pět minut. Flow programátora je potom – však vy víte kde :).

V poslední době jsem řešil problematiku zabezpečení webových projektů spolu se správou uživatelů a oprávnění. Původně se zdálo, že neexistuje open-source projekt, který by pokrýval naše potřeby. Po čase jsem však narazil na Acegi Security projekt, který je určený přímo pro Spring. Ještě před třemi dny jsem měl úplně jiné představy o tom, co Acegi řeší - myslel jsem, že to je jen sada providerů pro napojení na externí zdroje dat o uživatelích (LDAP, Active Directory a pod.). To jsem se ovšem hluboce mýlil.

Kdo někdy nasazoval Maven2 pro vnitrofiremní použití, možná se setkal s aplikací Maven Proxy od Codehausu. Od vydání verze 0.2 již uběhlo přes rok a Maven Proxy neutrpěla žádnou aktualizaci, zato se však objevila nová konkurence v podobě Artifactory od JFrog. Již základní sada funkcí dostupná v Maven Proxy dostatečně obhájí náklady s jejím zavedením, Artifactory však předbíhá Maven Proxy vlastnostmi, které ocení především větší organizace. Jak sami autoři popisují, začínali sami s Maven-Proxy. Ve chvíli kdy její možnosti přestávaly stačit, začali si je dodělávat a došli do stavu, kdy jich prostě bylo tolik, že nebylo myslitelné "propašovat" je do původní Maven-Proxy.

Na přání svých současných kolegů ve firmě FMC jsem připravil seminář zaobírající se základy analýzy v UML.

1. popisem životního cyklu
2. cíle analýzy a návrhu
3. behaviorální diagramy
4. strukturální diagramy
5. diagramy vztahů
6. odhadování časové náročnosti
7. tipy a triky

Obávám se, že jsem v některých částech nebyl úplně přesný, na mnoha místech jsem mohl řadu věcí popsat podrobněji a někde jsem nebyl schopný nalézt ty správné výrazy a obraty. Celou dobu jsem mluvil nespisovně a častokrát ani nedodržel shodu přísudku s podnětem. Pokud se vám zdají některé mé myšlenky zavádějící nebo obtížně pochopitelné, neváhejte a napište mi reakci - pokusím se nejasnosti vysvětlit zde.

Nedávno konferencí java.cz proběhla zmínka (díky Makubovi) o frameworku Stripes - o kterém jsem do té doby neslyšel. Nyní vychází i článek na OnJava site. Po krátkém prolétnutí článku a dostupné dokumentace se mi zdá, že se jedná o velmi životaschopný projekt, který rozhodně stojí za prozkoumání.

Stripes obdobně jako kdysi Spring, se snaží odstranit takové ty nepříjemné věci současných "velkých a oficiálních" frameworků ala JSF a Struts jako je například mohutná konfigurace v XML souborech, složitý životní cyklus a zdlouhavé učení se frameworku, než je možné ho použít. Stripes mají přímou podporu pro Spring beany, AJAX, jednoduchou validaci, upload souborů a další featury. Celé je to postavené na anotacích, takže framework je optimální používat s Javou 1.5, i když existuje i řešení jak backportovat Stripes aplikaci pro Java 1.4.

Řada z vás možná už na výraz Mock testing narazila, někteří ne. Pro ty z vás, kteří Mock přístup v testování nepoužili je tento článek. Pro ostatní může být zajímavá ukázka této techniky na knihovně EasyMock.

• Co jsou to mock objekty?

Jedná se vlastně o techniku psaní určitého druhu automatických testů. V podstatě se jedná o nahrazení reálného objektu testovací fasádou, která neprovádí žádnou funkcionalitu nahrazovaného objektu - jen se jako tento objekt tváří. Místo původní logiky objektu je vloženo chování, které ve svém testu potřebujete.

Stále mnoho vývojářů používá pro buildování svého projektu ant nebo maven 1, někteří si možná píší dokonce své sh nebo bat skripty. Možná o nové verzi Mavenu vědí a možná mají důvody proč zůstat u svého "osvědčeného" řešení. Sám jsem mezi ně patřil, ale přešel jsem - a teď vidím, že jsem udělal dobře, móóóc dobře :).

Jaké hlavní výhody Maven 2 přináší?

• Best Practises

Maven je především koncentrátem dobrých zkušeností z oblasti správy projektů. To není jen termín - v jeho případě je to pravda. V praxi to znamená, že jej nepoužíváte jen k sestavování instalačních balíčků, ale že pokrývá všechny oblasti, které se správou projektu souvisí a hlavně - navádí vás, jak je už od začátku dělat správně.

Ačkoliv chci tento blog orientovat na Javu a věci s ní spojené, první článek bude z jiného soudku. Naše generace, která začínala na osmibitech a ti šťastnější na prvních PC/AT byla zvyklá brát všechny aplikace bez rozdílu. Jednak se software v Čechách skoro ani nedal nikde koupit a jednak jsme v té době coby studenti neměli tolik peněz, abychom si nákup SW mohli dovolit (kdo dostával měsíčně 200,- Kč kapesné, z kterého si kupoval měsíční jízdenku na vlak, ví o čem mluvím). Z nutnosti se časem stal zvyk a nyní i když už se software dá nakoupit poměrně jednoduše, i když už každý z nás vydělává a i když je všude plno software zdarma, stále třebas používáme aplikace nelegálně jen proto, že jsme na ně zvyklí.