Vyvoj J2EE aplikaci

[eMko]

To sice ne, ale i tak je na tom dost dobře (žádná tragédie se nekoná) a IMHO se to zlepšuje.

[Reklama]

[Turban Legend]

než lze vidět na weblozích nadšenců píšících o nejnovějším server-side JavaScript frameworku, mnozí z nich si nikdy nesáhli na aplikaci s delším životním cyklem než 2 roky od zrodu do hrobu.

+1

[Ivan]

Je to úplně jiný svět než lze vidět na weblozích nadšenců píšících o nejnovějším server-side JavaScript frameworku, mnozí z nich si nikdy nesáhli na aplikaci s delším životním cyklem než 2 roky od zrodu do hrobu.

Kdovi jestli tohle neni budoucnost IT. I kdyz se mi to nelibi, tak kolem sebe vidim pristup: "Kasleme na udrzovatelnost aplikace, kasleme na cistotu kodu, kasleme dokonce i na data quality. Hlavne aby to bylo co nejlevnejsi. Byznys nam na tohle stejne nikdy neda penize. Stejne to za 5-7 roku shodime ze skaly a kompletne to cely napiseme znova - a pouzijeme na to uplne jiny framework nez pouzivame ted"

[Lemming]

Wicket je tedy framework na "vyšší úrovni abstrakce" než Spring MVC (což podle mě není dobře, ale názory se různí - JSF je též komponentový fwk).

No, to je v principu pravda, ale není komponenta jako komponenta V JSF jde o HTML (markup) komponenty, ke kterým se dá případně přifařit nějaká ta Java. U Wicketu je naopak základem strom Java komponent, které k sobě mají "nějak" napojený markup. Přičemž platí, že třída může využívat markup svého rodiče - úžasná věc pro využívání polymorfismu.

[Lemming]

wicket mal problem s dedicnostou (vsetko su inline oddedene classy)

Ugh???

a s modelmi kde sa newbiek mohol uvarit na performenci.

To ano... ale jak člověk pochopí, k čemu je LoadableDetachableModel, AbstractReadOnlyModel... A teda co se týče performance, tak zrádnější je spíš nevhodné přetěžování isVisible().

[Reklama]

[perceptron]

Ugh???

ze kod wicketu je hlavne v zaciatkoch anonymna trieda v anonymnej triede co teda nie je az taky zvyk v jave :-) (tym myslim pageable views, abstractreadonlymodel a podobne). wicket mal na to samozrejme dizajmove dovody

ale jak člověk pochopí, k čemu je LoadableDetachableModel, AbstractReadOnlyModel..

jj, urcite je to lepsie ale niekedy davno bola k tomu fakt biedna dokumentacia ktora dokola vysvetlovala jednoduche veci a zlozite mlzila

[perceptron]

Pokud přicházíte z jiného funkcionálního jazyka (např. z F#, OCamlu, Haskellu), tak většina věcí z té knihy Functional Programming in Scala vám bude pravděpodobně známa (možná vyjma poslední kapitoly, kde se buduje zjednodušená verze knihovny scalaz-stream). Proto si nemyslím, že by to bylo akademické.

to je samozrejme pravda

akurat ze ide f# a ocaml a nebodaj milovany haskell ako reklama na krasny ale mimopraxovy jazyk? opat je to o tom ze bud mate nadsencov ktori migruju medzi scalou a inym funkc jazykom a projektuju krasny liberalny projekt a stretavaju sa na konferenciach a potom vesmir enterprajs developerov kde lambda je ten znak z half-life

bolo by dobre keby to bolo naopak

[eMko]

Kdovi jestli tohle neni budoucnost IT. I kdyz se mi to nelibi, tak kolem sebe vidim pristup: "Kasleme na udrzovatelnost aplikace, kasleme na cistotu kodu, kasleme dokonce i na data quality. Hlavne aby to bylo co nejlevnejsi. Byznys nam na tohle stejne nikdy neda penize. Stejne to za 5-7 roku shodime ze skaly a kompletne to cely napiseme znova - a pouzijeme na to uplne jiny framework nez pouzivame ted"

Nejen budoucnost, souhlasím s Tebou že do jisté míry i současnost. Existuje mnoho aplikací, především webových UI, jejichž životnost je právě 2-5 let (a tedy max po 3 až 4 letech musíš uvažovat o přepisu). V takovém případě je na místě použít co nejnovější framework a jazyk, ve kterém se rychle píše a kde programy se dají co nejrychleji dostat na server (a třeba i upravit za běhu přímo na produkčním serveru, pokud si to situace žádá). Takový jazyk zcela jistě bude interpretovaný, dynamicky (a klidně slabě) typovaný. Třeba JavaScript pro klient i server nebo JavaScript na klientovi a server v PHP/Pythonu/Ruby. To, že není pořádná podpora IDE ani pro jazyk ani pro framework nemusí být až tak na škodu nebo že se programátoři seznamují s technologií při psaní produkčního kódu nebo že výkon interpretu jazyka je tragický oproti .Netu/Javě.

Priorita takového segmentu trhu je někde jinde a Java EE pro takový segment není zajímavá technologie.

Co se ale dá udělat, tak že se kolem stabilního systému udělají webové služby (WCF Rest, JAX-RS...) a uživatelské rozhraní se "naplácá" v něčem, co jsem popsal výše. Jedná se o "validní" a ne až tak raritní byznys model.

Věci jako PHP (a tuna frameworků), RoR, Node.js ... by tu nebyly, kdyby je nikdo nepoužíval. Ale přístup typu "napatlat to co nejrychleji a nejlevněji" nelze použít na systémy, které mají mít delší životní cyklus než právě několik málo let. Pak je z toho nepřehledný paskvil a náklady na údržbu jsou naprosto nereálné.

[m]

bolo by dobre keby to bolo naopak

Pročpak ? Proč se funkcionální programování neprosadilo samovolně, i když na to mělo dlouhých asi tak 50 let ? Že by v něm bylo něco shnilého ?

[tdvorak]

Pročpak ? Proč se funkcionální programování neprosadilo samovolně, i když na to mělo dlouhých asi tak 50 let ? Že by v něm bylo něco shnilého ?

Já tedy sleduji značný vzestup popularity funkcionálního programování. A je jedno, jestli jde o JavaScript, Javu, PHP nebo jiný jazyk. Na druhou stranu znám spoustu lidí, kterým FP neříká vůbec nic. Žádný závěr bych z toho ale nevyvozoval (a už vůbec ne o shnilosti FP). Každému vyhovuje něco jiného, pro různé úkoly jsou vhodná různá řešení.

[m]

A je jedno, jestli jde o JavaScript, Javu, PHP nebo jiný jazyk. Na druhou stranu znám spoustu lidí, kterým FP neříká vůbec nic.

Javascript, Java, PHP, C# nemají s funkcionálním programováním společného vůbec nic, jeden z mála funkcionálních je Haskell. Jak je vidět v této oblasti panuje mnoho nejasností.

[peto]

bolo by dobre keby to bolo naopak

Pročpak ? Proč se funkcionální programování neprosadilo samovolně, i když na to mělo dlouhých asi tak 50 let ? Že by v něm bylo něco shnilého ?

Z 50 rokov sa vacsinu casu riesil vykon na jednom jadre pripadne s jednoduchou paralelizaciou, kde sa praca rozhodi na N vyp. jednotiek tak, ze kazda jednotka dostane 1/N vstupov, ktore potom spracuje v serii. To sa dobre riesi imperativne a programator to ma pod kontrolou, dokaze v pripade potreby robit optimalizacie az na uroven instrukcii, comu sa tazko nieco vyrovna.

Naopak, funkcionalny pristup k programovaniu ponuka rychlostne vyhody az ked mame viac procesorov, ktore su pomerne blizko seba. Uz to nie je o tom, ze sa spracuvaju data po castiach a kazda cast bezi v serii. Vdaka funkcionalnemu programovaniu sa da trivialne paralelizovat napriklad spracovanie jednotlivych casti pipeline bez toho, aby sme to museli riesit. Imperativne to ide tiez, ale nepise sa to tak dobre, necita sa to tak dobre a celkovo sa to nespravuje tak dobre.

Preto to tu nie je 50 rokov v takom postaveni, ze by sa to malo sancu presadit. Okrem toho ma cely svet IT zotrvacnost a ta este nejaku dobu podrzi imperativny pristup.

[m]

Naopak, funkcionalny pristup k programovaniu ponuka rychlostne vyhody az ked mame viac procesorov, ktore su pomerne blizko seba.

Od r. 2005 - Pentium D a r. 2006 - Core 2 Duo je multicore všude (na serverech mnohem dříve), tedy uplynulo 10 let a stále kde nic tu nic. Zjevně absence víc procesorů nebyl ten důvod.

[Ondra Satai Nekola]

Naopak, funkcionalny pristup k programovaniu ponuka rychlostne vyhody az ked mame viac procesorov, ktore su pomerne blizko seba.

Od r. 2005 - Pentium D a r. 2006 - Core 2 Duo je multicore všude (na serverech mnohem dříve), tedy uplynulo 10 let a stále kde nic tu nic. Zjevně absence víc procesorů nebyl ten důvod.

Omezenost prumerneho programatora a jeho "konzervatismus"? O managementu nemluve.
Navic poradny tooling vznika spis az ted.

[Ondra Satai Nekola]

Nemluve o tom, ze vyrobit ekosystem je beh na hodne dlouhou trat...