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.