2. října 2011

Agile Prague Conference 2011 - ohlédnutí

Ve čtvrtek a v pátek se v Praze konal první ročník konference o agilním přístupu k vývoji - Agile Prague Conference, které jsem se zúčastnil.

Pokud bych měl krátce zhodnotit akci jako takovou, tak moc nevím, co bych ji vytknul - vše probíhalo podle plánu, catering fungoval jak měl, na žádné nedostatky technického rázu jsem nenarazil. Kvalita přednášek a přednášejících byla nadprůměrná - z mého osobního pohledu se mi více líbil pátek a až na jednu hodně slabou přednášku ve čtvrtek jsem byl celkově spokojený. Nejvíce mě zaujaly čtyři "case-study" přednášky českých firem, které se podělili se zkušenostmi se zavaděním agilních metodik u nich ve firmě. Také asi pro mnoho lidí bylo překvapením, že o jednotlivých metodikách se skoro vůbec nemluvilo, vše bylo spíše o důvodech pro agilní vývoj, o organizaci týmů, o zkušenostech ze zavádění agilních přístupů.

Dále nechci procházet jednotlivé přednášky a hodnotit je, chci zmínit zajímavé postřehy a myšlenky, které jsem si odnesl:

  • agilní přístup k vývoji má velice úzký vztah ke správné organizaci/struktuře společnosti - pokud chce být firma "agilní", tak musí být agilní celá a ne jen vývojové oddělení a i organizace jako taková tomu musí být přizpůsobena - místo klasické hierarchie šéf - product manager - project manager - tým vytvářet Self Organizing Teams, tj. reorganizovat odpovědnosti na celý tým, podpořit kreativitu a přenést zodpovědnost na všechny členy týmu.
  • všechny case-study přednášky se týkaly firem, které mají produkty, takže zákazníkem vývoje jsou interní product manažeři. Hodně by mě zajímal pohled na agilní firmu, které funguje zakázkově pro externí zákazníky (a ještě navíc pro státní sektor)
  • došel jsem k názoru, že pro úspěšné zavedení agilních metodik je nezbytné využití externího konzultanta, který díky tomu, že je externí, má mnohem lepší přesvědčovací pozici než interní vedení. Nejčastějším přístupem lidí při zavádění agilních přístupů je, že říkají, že to nebude fungovat, že my máme něco speciálního, co jinde nemají a proto to zde nemůže fungovat. Toto dost často externí člověk může vyvrátit.
  • dále mi přišlo velice důležité začínat pilotním týmem/projektem, protože ve všech firmách, které své zkušenosti prezentovali, byla skladba lidí před zaváděním přibližně tato - třetina se moc těší, třetině to je jedno a třetina lidí si myslí, že to nemůže fungovat. Pilotní projekt dokáže hodně lidí z poslední skupiny přesvědčit, že to fungovat může.
  • stále více se mi líbí Kanban, jako metodika pro vývoj softwaru - jednoduché, názorné, zábavné a "hravé".
  • pro mě osobně nový zajímavý pojem Lean software development
  • bez osobního potkávání a intenzivní spolupráce to nejde. Pokud chci co nejvíce omezit psaní dokumentace a pokud chci co nejvíce zodpovědnosti přenést na celý tým, pak musím tento tým dát dohromady, na jedno místo. I když preferuji práci na dálku (zejména kvůli mému osobnímu pohodlí), tak sám vím, že je něco úplně jiného mít tým v jedné kanceláři, kde lítají myšlenky vzduchem, kde všichni táhnou za jeden provaz.
  • zpětná vazba od zákazníka musí být co nejkratší - pokud chci něco řídit (viz Teorie řízení z kybernetiky), tak kvalita řízení je přímo úměrná kvalitě zpětné vazby. Na jedné přednášce byla prezentována přímá úměra mezi délkou sprchy a nastavením správné teploty vody. Jak trefné :)
  • Dnes (snad již) nikdo nevěří tomu, že vodopádový model může efektivně fungovat. Mnoho firem postoupilo o krok dále a praktikují iterativní způsob vývoje a včetně zavedené postupné integrace. To je ale pořád jen víceméně technický posun, ale pokud se nezmění organizace práce, struktura firmy a předání odpovědnosti týmům, pak není možné se bavit o agilním způsobu vývoje.
  • Líbila se mi přednáška, kde přednášející trefně říkal, že dlouhá léta se softwarové inženýrství snažilo okoukávat přístup k vývoji a řešení problémů od průmyslu, který tu už přes sto let byl a dobře fungoval. Až nyní v poslední době se ukázalo, že vývoj softwaru potřebuje zcela něco jiného.
A nakonec přidám ještě pár hesel, které mě zaujaly:
  • Vždy bude více požadavků než jaké jsou možnosti realizace - nutná prioritizace požadavků, čím kratší a rychlejší zpětná vazba, tím lepší.
  • Častěji bych se měl ptát, zda dělám správnou věc než zda dělám danou věc správně.
  • Posunu resp. zlepšení není možné dosáhnout beze změn.
  • "When in doubt, leave it out" - pokud si nejsme jisti při výběru a návrhu nějaké nové funkce, tak to raději nechme ať zákazník sám řekne, jak a co chce.
  • Kvalitní zpětná vazba od zákazníka není možná bez kvalitní komunikace s ním.
  • Čím jednoduší je architektura celého systému, tím rychlejší je přidávání nových vlastností do systému. I proto refaktoring je tolik důležitý.
  • Realita se mění, to je realita. Pokud chci vytvářet reálnou aplikaci, pak musím být na každodenní změny připravený.
  • Kód píšeme kvůli tomu, že ho ještě nikdo jiný před námi nenapsal. Pokud již někdo napsal, pak není důvod to psát znovu.

24. září 2011

Zkušenosti ze zavádění testování

Bude to již skoro dva roky, kdy jsem začal zavádět testování ve firmě (viz článek Největší problémy při zavádění testování). Teď jsem se dostal do stavu, že si potřebuji vše zpětně zhodnotit a posunout to ve firmě zase o kousek dále.

Co se povedlo:

  • základní principy a přínosy testování zná v týmu snad každý, každý až na nějaké výjimky již má zkušenosti s napsáním vlastních testů. V tomto ohledu se to rozjíždělo pomaleji než jsem na začátku čekal, trvalo chvíli než se dostavil efekt sněhové koule. Nejdříve jsem psal testy jen já, pak se začali postupně přidávat po jednom další a další až nyní je nás většina. Ovšem samozřejmostí je to pořád jen pro pár lidí. Také pomohlo několik případů, kdy nebylo jiné možnosti než napsaní aut. testů, protože ruční vytváření testovacích dat bylo strašně moc komplikované a zdlouhavé.
  • technické řešení resp. podpora pro psaní testů byla již od samého počátku hotová, v průběhu těch dvou let jsem toho zase tolik nemusel přidávat. Naše řešení je postavené nad vlastním frameworkem pro vytváření testovacích dat (viz článek Vytváření testovacích dat), doplněné o některé zajímavé vychytávky pro snadnější psaní testů - Testování webových služeb nebo Plošné vypnutí povinného @Autowired.
  • téma testování se začíná ve firmě prosazovat, nejen ve vývoji, ale zejména v konzultantské části firmy. V tomto ohledu také nastává posun z manažerského pohledu - ze začátku bylo testování, dle mého názoru, podporováno hlavně kvůli tomu, že o tom hodně lidí mluvilo, a že jsem byl schopen říci jak s testováním začít, jak to celé uchopit. Nyní je to spíše o snaze celé testování více zefektivnit, případně začít více měřit. Je tedy např. snaha o lepší spolupráci mezi konzultanty (zadavateli úkolů) a vývojáři tak, aby již zadání obsahovalo podpůrné informace pro co nejefektivnější psaní unit testů, které by ve výsledku měli ulevit právě konzultantům.
  • testy jsou součástí automatického buildu
Co se nepovedlo:
  • stále jsou zarytí jedinci, kteří testování "odolávají". Neustálá argumentace a úsilí mě celkem vyčerpává, ale je to vlastně má jediná zbraň, takže musím vydržet
  • bylo ode mě na začátku celkem naivní si myslet, že když někdo "prasí" produkční kód, tak testy na tom budou lépe. Spíše naopak. Testy jsou prostě považovány za něco "méně kvalitního", co nepotřebuje komentáře, vše se může psát bez nějaké struktury pod sebe. Tento bod nesouvisí nejen s testy, ale je to spíše úkol pro celý tým - používat a dodržovat konvence pro psaní zdrojového kódu.
  • unit testy fungují víceméně jako nástroj vývojáře, aby si svůj kód alespoň párkrát spustil a ověřil, že to plus mínus funguje. Z mého pohledu je potřeba zlepšit předávané informace od konzultantů, aby již v zadání úkolů byly uvedeny informace na co je vhodné se během testování zaměřit tak, aby to v konečném důsledku pomohlo nejen vývojářům, ale i konzultantům, kteří to vše musí převzít a sami ověřit, že je implementace správná.
  • chybí nám měřitelná zpětná vazba, neumíme říci, že díky pokrytí určité části testy se zlepšila chybovost o tolik a tolik. Neumíme říci, zda vynaložený čas na psaní testů je v konečném důsledku opravdu přínosem nebo není. Já jako vývojář vím o hodně výhodách a bez testů si to už nedovedu představit, ale má podobný názor i vedení? Obávám se, že zatím ne.
  • od začátku jsme chtěli, aby se testy co nejvíce efektivně, tj. psát testy jen k tomu, kde to má přidanou hodnotu. Vymysleli jsme to tak, že každý kdo bude chtít psát nějaké testy, tak přijde za mnou a zkusí mě přesvědčit, že daný test má smysl. Na první pohled dobrý nápad, ale ve výsledku špatné - potřebovali jsme motivovat vývojáře ke psaní testů a ne jim házet klacky pod nohy. Od tohoto jsme postupně opustili, bohužel zase mám někdy pocit, že některé testy mi nepřijdou moc efektivní. Ale asi je lepší mít více testů než méně.
Co dále v nejbližší době?
  • v rámci code review se více zaměřím právě na testy
  • chtěl bych zlepšit dokumentaci testů resp. JavaDoc testů. Jsem toho názoru, že každý by měl umět před implementací metody popsat, co daná metoda bude dělat. Pokud toho není schopen, pak vlastně přesně neví, co daná metoda má dělat. To samé platí o testech - každý si musí před každým testem říci, co chce testovat, jaké budou vstupy a jaké očekávané výstupy. Zde bych to chtěl nějak standardizovat, ale ještě nevím jak - nějaká jednotná JavaDoc šablona nebo nějak úplně jinak? Budu rád za nápady, jak se to řeší jinde.
  • musím zrychlit běh testů na build serveru. Je pravda, že build server je přetížený, ale i tak je hodně, pokud nám celý build včetně všech testů běží skoro hodinu. Zpětná vazba musí být rychlejší. (pozn: máme cca 700 tabulek, k tomu odpovídající Hibernate entity, které se musí vždy všechny inicializovat. Dokončení modularizace aplikace s možností vypnutí/zapnutí modulů bude až tak příští rok). Zde by možná mohl pomoci systém agentů, který znám z TeamCity. Nebo vhodně definovat testovací profily a pouštět to na více strojích vždy pouze s daným profilem.


18. září 2011

Proč nechci použít Hibernate na dalším projektu

Minulý týden se mě kolega zeptal, zda bych použil znovu Hibernate na dalším projektu? Já jsem mu po krátkém zamyšlení řekl, že již ne, že bych Hibernate (a obecně žádné jiné ORM řešení) nepoužil. Následovala diskuze, kde jsem se snažil obhájit mojí odpověď:

  • ORM nástroje se snaží vývojáře odstínit od konkrétního úložiště dat, snaží se vývojáře držet pouze v objektovém světě bez ohledu na to, že nejčastěji ukládáme data do relačních databází. Je naivní si myslet, že napíši kvalitní aplikaci bez znalostí databází a SQL.

  • ORM nástroje (pozn. konkrétně Hibernate, protože s ním několik let pracuji, ale myslím si, že to lze zobecnit pro všechny ORM nástroje) přidávají do projektů další velkou složitost, nároky na znalosti a zkušenosti. Toto má vliv na spoustu dalších věcí - výběr vhodných lidí do týmu, architektura systému, větší pravděpodobnost chyb, plnění termínů atd.

  • znalost SQL mi přijde natolik rozšířená a základní, že v tomto nevidím další znalostí zátěž pro vývojáře

  • používání ORM odstiňuje vývojáře od přímé práce s databází, což často vede k tomu, že vývojáři vůbec vlastně nevědí, jak jsou určité operace náročné, kolik se vlastně výsledně musí zavolat SQL dotazů, aby se jedna Hibernate operace vykonala

  • Hibernate přináší do vývojového týmu prvek náhodnosti, špatné říditelnosti - pokud vím, že mám napsat 3 dotazy přes JDBC, tak je to tak jasná a ohraničená věc, že není co dalšího řešit. Místo toho implementovat DAO pomocí Hibernatu, to moc jasné být nemusí - nikdy člověk neví, na čem se může zaseknout nebo jak se bude Hibernate v určitých kritických stavech chovat.

  • při porovnávání JDBC vs. ORM přístupů je potřeba také zmínit, že databáze často mnohonásobně přežijí aplikace, které je využívají. Technologie pro server a klienta se mění mnohem rychleji než relační databáze a jazyk SQL. Z tohoto pohledu je základem správný návrh databáze bez ohledu na to, jakou architekturu pak aplikace bude mít.

  • kolikrát se na projektu měnila databáze? Možná lepší otázka - stalo se již někomu, že se během projektu měnila databáze? Když pominu vývoj aplikací pro více databází, tak naopak si myslím, že napojení na konkrétní databázi mi nabízí mnohem více než když jsem odstíněný přes ORM.

  • ladění složitějších HQL nebo Criteria dotazů moc nejde a já osobně jsem vždy skončil u SQL. Někdy postupuji i naopak - pomocí SQL si vyzkouším, že daný dotaz je možné vytvořit, a že je správný a pak ho přepisuji pomocí Hibernatu.

Myslím, že nejsem sám, kdo má dnes podobný názor k této problematice jako já, viz např. článek Problems with ORMs jako jeden z nich.

Základní otázkou ale zůstává, co tedy jiného místo toho? Mě zde bohužel chybí osobní zkušenost, ale určitě bych se vydal cestou přes JDBC, tedy jako vhodné řešení mi přijde použití MyBatis nebo Spring JDBC nebo Spring Data nebo to celé nějak zkombinovat dohromady.

20. srpna 2011

Znáte SPL (Software Product Line)?

SPL je zkratka pro Software Product Line. Jedná se o styl vývoje podobný tomu, jak se vyrábí mobily nebo auta. Není to tedy vhodné pro jednorázové projekty, ale spíše pro produkty - firma má představu, jaký produkt nabízet na trhu, navrhne možné varianty a ty se pak snaží nabízet zákazníkům.

Je to opravdu hodně podobné výrobě aut. Výrobci znají segment cílových zákazníků, ví, že to například směřujeme na střední vrstvu, která si ráda připlatí za navigaci, tempomat, xenony, automatickou převodovku atd. Je tedy nutné navrhnout takový výrobní proces resp. architekturu auta, aby toto všechno šlo zákazníkovi dodat, ale klidně s určitými omezeními, např. pokud tempomat, tak ano, ale pouze s aut. převodovkou. I u aut může chtít někdo něco opravdu speciálního, co v nabídce automobilky není - pak osloví třeba nějaký specializovaný servis, který mu upraví motor dle jeho přání. To už ale je něco opravdu specifického a zákazník musí počítat s tím, že si to také pořádně zaplatí.
Automobilka nevidělá tím, že prodá jedno, dvě auta, ale třeba až tisíc, kdy se ty náklady na vývoj a implementaci vrátí.

Zpět k SPL. My nenavrhujeme auto, ale produkt, o kterým si myslíme, že ho máme komu nabídnout a nabídku opakovat. Musíme vědět možné variace a závislosti mezi nimi, tak abychom nenabízeli jeden uzavřený produkt, ale aby si zákazník mohl vybrat - chcete Oracle nebo MS SQL? Chcete zabezpečení přes HTTP, NTLM nebo OpenID? Chcete systém nasadit na vlastní server nebo na náš server nebo do cloudu? Naopak není třeba nutné, aby zákazník měl mít možnost vybrat jaký DMS systém chce - u auta si také nemůžete vybrat z více podvozků.

Asi nejvíce se mi ze SPL líbí přístup k vytváření interních megalomanských frameworků - budu citovat "Rather than put general software components into a library in the hope that opportunities for reuse will arise, software product lines only call for software artifacts to be created when reuse is predicted in one or more products in a well defined product line."

Pokud si o tom chcete přečíst více, pak doporučuji následující zdroje:


9. srpna 2011

Přenositelnost zkušeností

Konečně jsem si opět našel chvilku a píši na můj blog. Poslední měsíce jsem byl extrémně vytížený, protože se mi stalo, že se mi sešlo několik termínů dokončení projektů a já nevěděl co mám dělat dříve. Samozřejmě jsem to takto vůbec neplánoval, bylo to způsobené standardně tím, jak se všechny projekty protahovaly až se to vše potkalo v jeden termín.

Práci na volné noze mám natolik rád, že to považuji za jednu velkou výhodu, nicméně zde se ukazuje jedna malá nevýhoda - nedokážu říci svým stálým a dlouhodobým zákazníkům NE, protože se bojím o ztrátu zákazníka. A proto se mi to pak někdy takto vyboulí. Sám ale cítím, že je to takto špatně, protože pokud je někdy hodně práce a nevíte co dříve, pak zákonitě musí trpět kvalita, i když si to člověk nepřipouští.

Dnes ale chci psát o něčem jiném - v poslední době stále více dostávám prostor v různých firmách radit s optimálním nastavením vývojového procesu. Musím se přiznat, že mě někdy překvapuje, jak některé zavedené firmy, které jsou maximálně profesionální ke svým zákazníkům, se snaží odpovědět na základní otázky týkající se interního procesu vývoje.

Často jsem se v této souvislosti zamýšlel, jak nejlépe v této oblasti předávat moje zkušenosti nabité z působení v řade firem, vždy by se dalo říci s unikátními a vlastními postupy vývoje aplikací. Pokud někomu předáváte ryze technické informace a zkušenosti, tak to každý většinou vezme a ani nepřemýšlí o tom, že by to mohlo být jinak. U předávání ryze praktických zkušeností to takto nefunguje a mám prostě pocit, když to trochu přeženu, že pokud si na to každý nepřijde sám, tak tomu neuvěří. Jen je potřeba správně určit mantinely, aby člověk znovu neobjevoval kolo.

Celkem se mi zdá rozumné, když si firma na tyto konzultace a rady najímá někoho externího, protože jeho slovo má "větší" váhu, není zasažen interními vztahy, historií firmy a má celkový nadhled nad celým procesem.

Snad v každé firmě, ve které jsem byl, tak byl specifický proces vývoje, nějak specificky upravená metodika. Jsou určitě rozdílné nároky na vývoj jednorázových aplikací nebo produktů, ale proč to musí být všude jinak, když existuje opravdu jen několik rozumných metodik, které má cenu zvažovat a nasadit?

Je také zajímavé vidět, kdo v jaké firmě je ten "nejdůležitější" - jednou to jsou obchodníci, podruhé konzultanti a někdy dokonce vývojáři jsou ti, kteří mají největší hlas v tom, jak se co bude dělat. Myslím, že toto je většinou dáno tím, jak firma vznikala - pokud firma začínala s několika programátory, tak i nyní, když má přes sto lidí, má vývoj největší slovo.

13. května 2011

Co vybrat na klienta? Konec prvního kola

Vítězem prvního kola se stal .Net, i když i GWT budeme chtít využít.

Jako první volbu pro přepis našich stávajících aplikací použijeme .Net platformu. To je zatím jedno jasné rozhodnutí, na kterém jsme se domluvili, a které nám dává smysl. Hned příští měsíc si v tom vyzkoušíme napsat jednu zcela novou aplikaci, abychom nabrali zkušenosti a získali cennou zpětnou vazbu.

Mezi hlavní argumenty pro .Net patří tyto:

  • možnost výběru cílové podoby aplikace (za splnění určitých podmínek během vývoje) - standalone aplikace vs. webová aplikace Silverlight
  • naši zákazníci jsou zvyklý na velký uživatelský komfort z našich stávajících aplikací, toto musíme i nadále dodržet
  • chceme řešit vývoj aplikací, ne řešit detaily GUI pro různé prohlížeče
  • většina vývojářů, kteří nyní dělali v Delphi, chtějí spíše .Net než něco jiného. Preferujeme know-how kolem řešené problematiky, než znalost samotné technologie.


Nicméně i GWT (asi) nezůstane stranou. Existuje spoustu oblastí a problémů, které není vhodné řešit jen .Net platformou, Silverlight je pro spoustu webových řešení těžkopádné a nevhodné. Proto mi dává smysl mít na výběr - buď .Net platformu pro naše produkty a nebo "čisté" webové řešení jako např. GWT nebo i třeba i něco jiného (zde ještě nemáme zcela jasno).

Firma má know-how jak ve vývoji tlustých klientů, tak i čistě webových projektů, proto mi přijde vhodné tohoto dále využít a stanovit pro firmu dvě nosné technologie. Navíc je to i slušná konkurenční výhoda, umět použít technologii podle zadání projektu a ne podle interních možností.

18. března 2011

Co vybrat na klienta? Finále Silverlight vs. GWT

Výběr klienta jde do finále, rozhodujeme se nyní mezi Silverlightem a GWT.

Potřeboval jsem tu původní množinu možností z prvního článku nějak zúžit, abych je mohl detailně porovnat a vybrat nejlepší variantu.

Důvody, proč jsem vybral tyto dvě technologie a nevybral jiné:

  • technologie nevybíráme úplně na zelené louce, nezačínáme od začátku - firma již má nějakou historii, má nějaké produkty, má nějaké know-how, má nějaké programátory, kteří mají určité znalosti. Není možné tedy říci, co bylo, to mě nezajímá, teď přichází budoucnost ...

  • současný výběr technologie ovlivní vývoj ve firmě na dalších min. pět let, možná i více. Ze zkušenosti potřebuji mít aspoň nějaké garance, že technologie tuto dobu (a ideálně mnohem déle) bude existovat, bude podporována, musím z ní "cítit", že se s ní do budoucna počítá. Proto jsem vyřadil řešení jako OpenLaszlo nebo třeba vaadin, které se mi zdají výborné, ale nedovolím si na tom postavit strategii firmy na další roky.
    Pozn.: možná by bylo vhodné uvést, že se bavím o firmě s více jak sto zaměstnanci, z toho čistý vývoj (bez konzultantů) čítá cca 30 lidí.

  • firma dosud hlavně vyvíjela tlusté klienty v Delphi, některé menší projekty mají webové uživatelské rozhraní. Servery jsou všechny psané v Javě. Toto má dva významné důsledky: přepsaní tlustých klientů do webových technologií nebude určitě bezbolestné a bude potřeba najít cestu nejmenšího odporu. Lidem se znalostí Delphi je bližší technologie .NET než webové technologie, navíc tu již nějaké znalosti .NETu jsou.

  • jak jsem již uváděl v předchozím článku, tak Java na straně klienta u mě (bohužel) důvěru nemá. Nikdy to nebylo ono, a ani JavaFX ve mě nyní nebudí moc velkou důvěru. Sun tuto technologii hodně tlačil, ale Oracle je nyní pro mě v této oblasti velkou neznámou.

  • výběr technologie souvisí s možnostmi sehnat (kvalitní) lidi s potřebnými znalostmi. Firma by se v tomto ohledu chtěla "otevřít" mladším ročníkům, absolventům. Také bude určitě dříve či později potřeba sehnat lidi pro nárazovou pomoc na projektech, takže je potřeba se dívat na její rozšíření a podporu v našich končinách.

  • základní technologie je jedna věc a nabízená rozšíření třetích stran je druhá věc. Např. samotné GWT dobrý, ale nabídka třetích stran ještě lepší - SmartGWT, ExtGWT atd. To samé Silverlight - telerik, infragistics atd.

  • při vývoji webových aplikací nechci řešit (nebo řešit co nejméně) kompatibilitu mezi prohlížeči. Chci používat nějaký produkt, nějaké komponenty, které to budou řešit za mě. Bohužel ze zkušenosti vím, že toto nikdy nebude 100%, viz moje zkušenosti z JSF a NetAdvantage.

  • na serveru bude Java, to je jistá věc. K Javě má určitě blíže GWT než Silverlight. Dnes máme celkem velkou znalostní propast mezi lidmi, co dělají klienta a co dělají server, protože se používají úplně odlišné technologie. Jen opravdu minimum lidí rozumí obojímu.
    Při volbě GWT budou mít oba světy k sobě blíže, bude možné lépe vytěžovat lidi - v případě potřeby podpořit více klienta nebo server. Teď to moc nejde, protože s Javou mi v Delphi nepomůžou a naopak
    Naopak pokud zvolím Silverlight a ty světy budou více oddělené, pak by mohl být větší tlak na kvalitní API na serveru, byly by jasně dané hranice. Až za pár let se zase třeba bude měnit technologie na klientovi, tak server zůstane beze změn a jen se vymění klient.

  • v dnešní době je určitě nutné přemýšlet o mobilním přístupu k datům. Není to hlavní kritérium, ale ohled na to je potřeba brát.

  • trochu mám obavu z přijetí Microsoftu u státních projektů. Je jasné, že Microsoft je u nás všude ve státní správě, ale přeci jen cítím, že státní projekty by měly být co nejvíce nezávislé a v tomto pohledu "mám lepší pocit" z Google než Microsoftu. Asi je to jen pocit.


Jdeme tedy do finále :). Zase budu moc rád za vaše komentáře a zkušenosti, protože takové věci jsou k nezaplacení.

17. března 2011

Porovnání RIA frameworků

Na předchozí článek Co vybrat na klienta? Html, flash, silverlight nebo JavaFX? reagovalo formou komentářů nebo emailů velké množství lidí a dokonce mi jeden z nich, Honza Kovář, poslal na toto téma svoji diplomovou práci - moc díky!

Uvádím pouze závěrečné srovnání, kde je vše hezky porovnané. Sice je z roku 2009, nicméně většina věcí stále platí a pro celkový přehled to vůbec nevadí.







Ještě přidávám odkaz na originální PDF.

8. března 2011

Co vybrat na klienta? Html, flash, silverlight nebo JavaFX?

Dneska se chci zamyslet nad výběrem vhodné technologie pro prezentační vrstvu pro náš nový projekt. Bude to spíše "manažerský" pohled než programátorský - nejde mi nyní moc o to, jak dobře se to bude programovat, ale spíše o to, jak moc to bude vyhovovat požadavkům projektu a firmy, kde nyní pracuji. Navíc ty technologie ani moc neznám.

Přehled požadavků, které je potřeba splnit:

  • projekt pro rozsáhlou státní organizaci. Cílové stanice nejsou pod kontrolou, nicméně je možné definovat nějaké podmínky pro běh aplikace (např. minimální verze určitých prohlížečů).
  • minimální nároky na administraci
  • potřeba přehrávání videa i audia
  • možnost ukládání dat na klientovi resp. držení nějakého stavu na klientovi. Možná bude potřeba i částečný běh v režimu offline.
  • interakce se souborovým systémem


Dle mého názoru připadají v úvahu tyto technologie: Adobe Flash (Flex), Microsoft Silverlight a nebo JavaFX, možná OpenLaszlo.

Uvedené technologie dále ještě více proberu a budou mě zajímat hlavně odpovědi na tyto otázky:
  • Jak moc daná technologie splňuje základní požadavky projektu?
  • Jak bude těžké ve firmě v dané technologii vyvíjet? Tedy jak moc je těžké někoho sehnat, jak moc je těžké se danou věc naučit, jak moc to zapadá do znalostí, které firma nyní má apod.? Ve firmě je velké know-how s vývojem Java serverových aplikací s tlustými klienty (Delphi, trochu .Net), částečně i s tenkými webovými klienty.
  • Jak vypadá celý "ekosystém" kolem dané technologie? Komunita, dokumentace, informace na internetu atd.
  • Jaké jsou možnosti zobrazení GUI v přenosných zařízeních?


OpenLaszlo jsem objevil teprve nedávno, na to se budu muset ještě více podívat, ale moc této variantě šancí nedávám.

JavaFX:
  • nemůžu si nějak pomoci, ale Java na klientské straně moc mojí důvěru nemá. Kolem JavaFX bylo hodně humbuku 1-2 roky zpátky, teď mám pocit, že se o tom už skoro vůbec nemluví (pohled na Google Trends mi to jen potvrzuje).
  • instalace a správa klientů bude asi v pohodě, pokud je aplikace podepsaná, tak může pracovat i se souborovým systémem. Možná prvotní instalace JRE bude vyžadovat admin přístup.


Adobe Flash:
  • velice rozšířené, multiplatformí, běží snad úplně všude
  • minimální požadavky na administraci resp. zásah adminů - flash plugin se instaluje zcela sám bez problémů
  • není moc velký výběr komerčních komponent pro aplikace (třeba Ribbon)
  • přijde mi dost těžké sehnat kvalitní lidi na Flash, navíc jsou skoro nulové znalosti ve firmě o této technologii
  • z pohledu státní správy mi Flash od Adobe přijde "méně bijící do očí" než Silverlight od Microsoftu.
  • stejně jako Silverlight by měl Flash splňovat všechny vstupní požadavky


Silverlight:
  • mnoho komerčních komponent (Ribbon)
  • prvotřídní podpora multimédií včetně 3D (zrychlené přehrávání videa s korekcí zvuku tak, aby bylo rozumět).
  • píše se v C#, hodně podobné Javě. Navíc směr, kam by firma chtěla do budoucna jít, protože stávající Delphi klienti již mají nejlepší léta za sebou.
  • pro první instalaci jsou potřeba administrátorská oprávnění
  • mám pocit, že Microsoft tuto technologii celkem tlačí a podporuje, i se o ní hodně píše a je prostě vidět. Očekávám, že má nejlepší léta před sebou.
  • pro mě zatím favorit, jen si nejsem jistý, jak moc dobře to bude běhat na Linuxech. Sice existuje projekt Silverlight MoonLight, ale Linuxové distribuce ho moc rádi nemají a pak je v implementaci cca rok pozadu oproti standardní windows verzi.


A co klasické HTML? Pokud bych výběr dělal za pár let, tak věřím, že bych volil HTML5, ale teď to bohužel k tomu není. Možná pokud se ukáže, že není potřeba držet žádný stav na klientovi nebo režim offline, tak se k variantě HTML vrátím. Samozřejmě čím "tenčí" klient, tím lepší.

Jaké máte zkušenosti vy? Jaké jiné výhody či nevýhody vás napadají pro dané technologie, co by jste mi doporučili? Předem moc děkuji.

21. února 2011

Je Java produktivní jazyk?

Všechno to začalo zajímavým článkem "Java Kicks Ruby on Rails in the Butt", kde aspoň pro mě se objevila velice zajímavá myšlenka:

The productivity in Java world is a cultural problem, not a technical one.

Na uvedený článek se objevilo spoustu reakcí v Java světě a mě to přinutilo popřemýšlet a napsat pár myšlenek v tomto článku.

Já osobně moc tyto srovnávací články rád nemám, protože mi přijdou skoro vždy jednoúčelové. Cožpak někdo může říci, že Java je produktivnější než Ruby a naopak? Ve spoustě případů ano, ve spoustě případů zase ne.

Nicméně s uvedenou myšlenkou plně souhlasím. Opravdu to asi máme nějak v sobě, že když už ta aplikace bude Javovská, tak vždy bude mít alespoň tři vrstvy, že to musí být robustní, škálovatelné atd. atd. Doufám, že doba, kdy byly mainstream EJB, je již pryč, ale pořád se mi zdá, že není moc velké povědomí o alternativních řešeních jako jsou Grails, Spring ROO, v článku uvedený OpenJava nebo třeba DB forms. Nebo obecně o dostupných knihovnách - takové Jakarta Commons by snad měl znát úplně každý a pokud si někdo uvedené funkce píše sám, tak to fakt nechápu. V minulosti jsem již psal o rychlém rozcestníku na základní knihovny.

Dnes více než v minulosti je nutné se vyznat - nestačí znát jen Java jazyk jako takový, ale je potřeba znát všechny možné knihovny a frameworky, znát přednosti a nevýhody jednotlivých řešení, umět si vhodně vybírat. To samé se dá říci o programovacích jazycích - Java jako základ ano, ale pro určité úlohy je lepší třeba Groovy, jinde Perl apod.
(Pozn.: když se na tyto všechny jazyky koukám z pohledu projektového vedoucího, tak jsem pořád tak nějak k tomu skeptický - čím více bude jazyků potřeba na vývoj, tím horší (= dražší) bude pak údržba. To nepočítám náklady na osvětu a zaškolení týmu.)

Možná je to tím, že jsem na volné noze, kdy efektivita má pro mě přímou úměru k výši výdělku, že se tak o všechny možné knihovny zajímám. Já již asi rychleji psát kód nebudu, ale tím, že ho budu psát méně a více výslednou aplikaci skládat, tak mohu být efektivnější. Také za těch skoro 10 let co programuji již mám slušnou databázi odkazů a hotových řešení, že někdy více kopíruji, než vymýšlím nové věci.

Každopádně i když budu umět perfektně Javu, znát knihovny a celou platformu, tak jsem podle mě někde ve dvou třetinách kvalitního programátora. Když nebudu počítat vlastnosti jako pečlivost, systematičnost, zodpovědný, cílevědomý, které buď prostě máme nebo nemáme, tak je nutně potřeba znát řešenou problematiku, bez toho nemůže být řeč o programátorovi, ale o kodérovi.

18. února 2011

Proč jsem nepoužil Spring Batch?

Když jsem si srovnal zadání na mém posledním projektu, tak vše na první pohled nasvědčovalo tomu, že bude vhodné použít Spring Batch, další projekt z rodiny Springů. Za to jsem byl moc rád, protože jsem již delší dobu hledal příležitost, abych tento zajímavý projekt vyzkoušel.

Na začátku jsem Spring Batch znal jen z několika článků, a proto, když se mi v zadání projektu objevovala slova jako "dávkové zpracování, škálovatelné, rychlé, vícevláknové, robustní, procesy", tak se mi to automaticky spojilo s tímto Springovským projektem. Nastudoval jsem referenční příručku a přidal do mé aplikace.

Bohužel žádný Spring Batch ve výsledné aplikaci nenajdete. Když se teď na to koukám již z dvouměsíčním odstupem, tak se musím trochu smát, jak jsem opravdu chtěl za každou cenu Spring Batch využít, jak jsem se to snažil napasovat na všechny možné podporované "patterny" z dávkového zpracování dat apod. Nakonec jsem Spring Batch kompletně opustil a vystačil si jen ze základními funkcemi Spring frameworku pro scheduling a práci s táskama - Task Execution and Scheduling.

Výhody použití Spring Batch:

  • Spring Batch pomáhá s řešením dávkového zpracování dat, což má svá určitá specifika ve srovnání s "normálními" aplikacemi. Pokud náš řešený problém dokážeme napasovat na podporované scénáře, tak máme vyhráno a můžeme Spring Batch použít.

  • dávkové zpracování hodně souvisí se správně zvolenou strategií transakcí a zde podle mě nabízí Spring Batch největší přidanou hodnotu, kdy jsme většinou zcela oproštěni od řízení transakcí.

  • dávkové zpracování ve většině případů vyžaduje nějaké vstupní funkce na čtení a pak výsledné zapisovače. Spring Batch obsahuje čtečky pro flat soubory, XML soubory, databáze atd., data je možné zapisovat do databáze přes JDBC, Hibernate nebo JPA. Samozřejmě není problém si cokoliv upravit či dopsat - já sám jsem si napsal čtečku dat z mailové serveru.

  • Spring Batch nabízí funkce na opakování a znovu-spuštění dílčích operací (repeat a retry). To vše díky tomu, že Spring Batch si ukládá všechny informace k tomu, aby mohl jakýkoliv proces, krok procesu znovu spustit nebo ho pustit opakovaně.
    Spring Batch vyžaduje určitý datový model, do kterého si ukládá informace o aktuálním procesu, kroku, zpracovaných datech. Ukládání těchto dat není povinné, ale pak je řada funkcí nedostupná.

  • Spring Batch Admin - pokud necháme Spring Batch ukládat běhová data, pak můžeme využít webovou aplikaci pro zobrazení těchto dat, pro jejich administraci, včetně funkcí na znovu-spuštění procesů či jednotlivých kroků.

  • jak už jsem psal, dávkové zpracování má svoje specifika včetně řady "paternů" pro různé scénáře a pokud naše řešení dokážeme napasovat na tyto paterny, tak budeme mít aspoň nějakou jistotu, že daný problém řešíme dobře.


Já jsem Spring Batch nevyužil z těchto důvodů:
  • zažil jsem to poprvé, ale měl jsem od zákazníka celkem přesné zadání, jak by workflow aplikace mělo vypadat. Neměl jsem tedy úplně možnost si to udělat podle sebe. (ono by to šlo napasovat, vše jde, ale došel jsem k názoru, že to udělám mnohem jednodušeji bez Spring Batch, viz dále)

  • nepotřeboval jsem žádné repeat a retry funkce, žádné držení stavu, žádné informace o počtu procesů, kdy běžely, žádnou webovou vizualizaci dat atd.

  • po nějakém zhodnocení jsem došel k závěru, že jediné co by mi Spring Batch přinesl, tak by bylo transakční řízení, které jsem navíc potřeboval také nepatrně jinak, než bylo standardně nabízenou.


I když Spring Batch ve výsledné aplikaci není, tak i přesto jsem se s ním detailně seznámil, řadu věcí vyzkoušel a pokud budu zase někdy něco řešit dávkově, tak určitě budu přemýšlet o jeho využití.

15. února 2011

Znáte Spring Data (JPA)?

Již jsem o tom psal na Twitteru, ale myslím, že si to zaslouží trochu větší a delší pozornost, tak to píši ještě sem.

Pod hlavičkou firmy SpringSource se v poslední době objevilo spoustu nových projektů a jedním z nich je i projekt Spring Data. Rozsah projektu je celkem velký:

The primary goal of the Spring Data project is to make it easier to build Spring-powered applications that use new data access technologies such as non-relational databases, map-reduce frameworks, and cloud based data services. A secondary goal is to provide additional support for relational database technologies such as Oracle RAC and convenience classes for Java generic based repository classes.


Mě osobně nejvíce zaujal podprojekt Spring Data JPA, o kterém vyšel pěkný úvodní článek na blogu.

Snad každý si vytvořil nějaké svá rozšíření pro práci s Hibernatem nebo JPA, aby nemusel pořád dokola psát jednoduché dotazy na načtení jednoho objektu, všech objektů, jejich uložení atd. Právě toto vše a mnohem více nabízí tento projekt Spring Data JPA, takže budu moci s klidem zahodit své řešení a začít využívat toto od Springu.

9. ledna 2011

Generování PCL do souboru

Tento článek dnes píši z trochu jiných důvodů než jindy - rád bych si shrnul mé dosavadní znalosti v této oblasti a také bych vás rád požádal o radu, protože s touto problematikou nemám moc zkušeností.

PCL je formát používaný při tisku tiskárnami. Většinou se s tímto formátem člověk přímo nepotká, protože když někdo chce něco vytisknout, tak použije nějaký vhodný ovladač ke konkrétní tiskárně, ten PCL vygeneruje a pošle rovnou na tiskárnu k tisku.

Já mám k řešení trochu jiný problém. Moje aplikace tvoří část tiskového řešení, které je postavené na tom, že firma má po celém světě různé sklady a kanceláře, kde má síťové tiskárny. A podle určitých pravidel přijde nějaký dokument, ze kterého je potřeba vygenerovat PCL a poslat dle konfigurace na cílovou tiskárnu. Tiskárny jsou to většinou HP (řekl bych tak z 90%), sem tam se objeví i jiná značka, např. Xerox. Přenos souboru na tiskárnu je přes FTP.

Nemohu tedy využít konkrétní ovladače pro konkrétní tiskárny, musím vygenerovat nějaký obecný PCL soubor a ten tam poslat. Pokud se jedná čistě o textový soubor, tak ten se vytiskne bez potřeby generování PCL, ale ne všechny dokumenty jsou jen čistý text, někde jsou i obrázky.

PCL formát má řadu podformátů - 5e, 5c, 6. Ideální je (asi) verze PCL6, protože již dnes většina tiskáren podporuje tuto verzi a do budoucna bude rozšíření ještě větší. Navíc jednotlivé verze nejsou zpětně kompatibilní (někde se píše, že jsou zpětně kompatibilní a někde, že zase ne, ale spíše věřím tomu, že nejsou).

Další obecné požadavky na aplikaci - cílové OS je Linux (Redhat Enterprise) a velký důraz je kladen na rychlost, robustnost a škálovatelnost aplikace. Výsledný soubor k tisku musí být co nejmenší, řádově desítky kB.

Java Print Service

Java má celkem flexibilní API pro tisk - Java Print Service. Použití je přímočaré (ukázka generování z GIFu do PS) a v dokumentaci mezi podporovanými formáty PCL je, jenže při bližším zkoumání zjistíte, že PCL je podporováno jen na rozhraní a ne implementačně - "The StreamPrintService from JDK 6 does only support PS...".

Nenašel jsem žádnou knihovnu třetí strany, která by toto implementovala.

Apache FOP

Když se člověk poprvé při řešení tohoto problému porozhlédne po internetu, tak jako první většinou najde Apache FOP, který umí převádět data do PCL.

Bohužel podpora PCL v Apache FOP není dokonalá a má spoustu nevýhod:
  • celkem složité na implementaci, navíc těžko říci, zda to bude také rychlé. Je potřeba různě generovat XML, pak je transformovat atd. Určitě nic extra rychlého.
  • umí jen PCL5 a podpora PCL6 asi ani nebude.
  • neumí UTF-8 (Multibyte characters are not supported)
  • přehled dalších omezení

FO procesorů je více (zde je přehled), ale žádný jiný neumí PCL a nebo nejsou vhodné k použití s Javou.

Command-line a tiskové nástroje

Při hledání možného řešení jsem i prohledal všechny možné tiskové a konverzní nástroje, bohužel bez přímé podpory pro PCL.
I kdybych našel vhodný nástroj pro konverzi do PCL, tak zde vidím spoustu dalších nevýhod: nejsou to úplně levná řešení, pomalé a nevýkonné řešení, problém s integrací do naší aplikace, kód a další vývoj produktu nemám pod kontrolou.

Generování přes drivery

Při nějakém dalším zkoumání mě napadlo využít nějaký obecný driver pro tiskárnu, tj. poslat dokument k tisku na vhodný driver, ale místo na tiskárnu, tak výstup uložit do souboru.

Našel jsem "HP Universal Print Driver", ale ten je pouze pro Windows, já potřebuji Linux.

Pro Linux mě zaujal projekt Gutenprint a obecný driver Generic PCL 6/PCL XL Printer.

Podle mých slabých znalostí v této oblasti mám dvě možnosti - použiji program ghostscript a vygeneruji PCL z PS. Ghostscript by měl být součástí distribuce. Druhou variatnou je vyrobit virtuální tiskárnu, která se tváří jako PS tiskárna a interně použije ghostscript jako filtr na výrobu konkrétního tiskového formátu.

Chybí mi v této oblasti znalosti, jak by se to vůbec dalo na Linuxu zrealizovat, nicméně mám pocit, že tato cesta je celkem reálná, a že by mohla fungovat.

Něco jiného než PCL?

Když se podíváte na podporované formáty u lepších (=síťových) tiskáren, tak často jsou ještě vidět dva další formáty - PDF a Postscript.

PDF musím hned vynechat, protože podpora není nic moc - v mém vzorku cca 20 řad tiskáren (nemyslím konkrétní modely, ale celé řady tiskáren, např. HP LaserJet P4015 Printer series) je podpora u cca 50% a to je málo.

Pak se nabízí Postscript, podpora asi u 85% tiskáren. Generování do PS je přímočaré, protože to umí přímo Java Print Service ve standardní Javě. Jedinou nevýhodou, kromě slabší podpory u tiskáren než má PCL, je výsledná velikost souboru a nároky na systémové prostředky při generování. Z mých testů vyplynulo, že pro naše typové dokumenty je velikost PS 3x větší než PCL. Hned je ale potřeba dodat, že výsledné velikosti PS byly okolo 10kB, takže minimální.
"PS used to come at a price - it use to be the case that you had to pay extra money to get PS but now its fairly standard on many printers and indeed some HP printers will even print PDF directly. PS is generally considered more resource hungry - it requires more memory and is slower than PCL5/PCL6.
PS output files are usually larger than those generated for PCL5/PCL6 because it is plain ASCII, you can actually read it ; BUT communication times (between computer and printer) used to be slower."

Generování do PS již naše aplikace umí a zdá se, že vše běhá celkem rychle. Bohužel business požadavek je od začátku PCL.

Další informace:


Budu moc rád, pokud mi někdo poradíte a posunete mě dál. Já osobně nyní nejvíce věřím řešení přes drivery v OS.

1. ledna 2011

Knihovny pro testování: MockFtpServer a GreenMail

Minulý rok jsem toho napsal zatím nejméně a rád bych, aby to ten letošní rok bylo lepší. Proto píšu hned první den - jak se říká, jak na nový rok, tak po celý rok :).

Na posledním projektu jsem měl potřebu si ověřit správnou komunikaci s FTP serverem a posílání/přijímaní mailů, tedy komunikace se SMTP serverem a IMAP resp. POP3 serverem.

Pro komunikaci s FTP serverem jsem použil knihovnu Apache Commons Net. Nejdříve jsem chvíli přemýšlel, zda mi nebude stačit podpora ve standardní Javě (pro moje potřeby naprosto dostačující), ale nakonec jsem si vybral Commons Net. Rád a často používám knihovny s rodiny Commons a i zde jsem rád, že jsem tuto knihovnu vybral.
Pro testování komunikace s FTP serverem jsem našel výbornou knihovnu MockFtpServer. Dokáže opravdu věrohodně simulovat FTP server, zejména možnosti nastavení práv souborového systému jsou super.


Pro odesílání mailů používám podporu ve Springu - JavaMailSenderImpl. Kromě odesílání jsem potřeboval maily i přes IMAP stahovat, vytvářet složky na mail serveru a s maily různě manipulovat. Čekal jsem, že najdu nějakou vhodnou knihovnu, ale nakonec jsem skončil u standardní Javy, která nabízí JavaMail API. Některé věci jsou možná až moc nízkoúrovňové, ale nic lepšího jsem nenašel.

Pro testování mailů jsem využil knihovnu greenmail. Jako jedna z mála knihoven, které jsem našel pro testování, umí kromě ověřování SMTP i IMAP/POP3 protokol.

Pokud někdo potřebuje testovat jen SMTP, tak pro to by asi úplně stačila knihovna SubEtha SMTP.