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í.

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.

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.

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.

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í.