Jakie jest Twoje wyobrażenie o nadchodzącym "Budowanie aplikacji Java EE 6 z Clojure"?

[Jacek Laskowski]

Cześć,

Mam tyle możliwych ścieżek, którymi mógłbym zaprezentować Clojure w
kontekście budowania aplikacji Java EE 6, że trudno mi wybrać tą
właściwą, która ma największe szansę powodzenia. Jedna, to po prostu
prezentacja budowania aplikacji ze wstawkami w Clojure (prezentacja
Clojure Java interop). Tu może pojawić się pytanie "Po co?" i bez
kontekstu, np. rodzaju budowanych aplikacji korporacyjnych, odpowiedź
może być niemożliwa do określenia i tym samym, osobnik wyjdzie bez
chęci popróbowania się z tematem. Inna sprowadza się do prezentacji
budowania aplikacji korporacyjnych ze stosem Clojure -
Ring/Compojure/Sandbar/Friend/congomondo, itp. z użyciem narzędzi
specyficznych dla Clojure (a niespotykanych w warsztacie programisty
Java EE). Ponownie pojawi się pytanie "Po co?" i ponownie bez braku
przykładów, w których możnaby zaaplikować myślenie funkcyjne
prezentacja Clojure może być karkołomna.

Zależy mi, aby poza przekazaniem mojej wiedzy na temat użyteczności
Clojure, znalazły się osoby, które będą zaintrygowane, aby popróbować
się paradygmatem funkcyjnym do budowania aplikacji (niekoniecznie
Clojure, ale on będzie tłem).

Jakie jest Twoje wyobrażenie mojej prezentacji, jeśli planujesz
spędzić czas mile z właściwą dawką wiedzy o Clojure? Pozwól mi poznać
Twoje oczekiwania, abym mógł dopasować moje wystąpienie do Ciebie.
Jeśli jednej osobie się spodoba, to może i innym.

Jacek

--
Jacek Laskowski
Functional languages (Clojure), Java EE, and IBM WebSphere -
http://blog.japila.pl
"Never discourage anyone who continually makes progress, no matter how
slow." Plato

[Wojciech Erbetowski]

Cześć,

Ja bym najchętniej posłuchał o webowych rzeczach w dwóch kontekstach:

- pierwszy to typowe aplikacje webowe a'la RoR stworzone do szybkiego dewelopmentu/prototypowania aplikacji.

- drugi to taki jak podczas zdaje się Warsjawy 2010 został zaprezentowany, wysoce wydajna aplikacja.

Jeśli jest wsparcie do nie-blokującej architektury też byłoby super (czyli takiej a'la nodeJS).

To teraz spora moda, bo przy chmurowych rozwiązaniach można zrobić dużo więcej mając mniej wątków :-)

Z czego drugi przypadek mnie interesuje zdecydowanie bardziej :-) 

Tamta prezentacja o Clojure zrobiła na mnie niemałe wrażenie (pamiętacie to? 

to chyba była porównywarka cen z jakimiś skrajnie niskimi czasami odpowiedzi).

Pozdrawiam,

Wojtek

--
Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).
Więcej informacji na stronie http://groups.google.com/group/warszawa-jug?hl=pl
Zachęcamy do odwiedzenia naszej strony domowej http://warszawa.jug.pl
Oferty pracy dozwolone zgodnie z zasadami na http://sites.google.com/site/warszawajug/oferty-pracy-na-grupie

[johnny]

To chyba był search engine na warsjawie (chyba 2011)?

http://www.fablo.pl - na ich stronie jest demo, fajna sprawa, bez guzika, prawie bez opóźnienia...

Lubie jee 6. Ciekawe rozwiązania pokazywali na geeconie Arun Gupta i Adam Bien.

Dlatego fajnie by było zobaczyć do jakiego typu problemów lepiej nadaje się closure niż EJB?

cheers

[Jacek Laskowski]

2012/5/21 johnny <johnny....@gmail.com>:

> Lubie jee 6. Ciekawe rozwiązania pokazywali na geeconie Arun Gupta i Adam
> Bien.
> Dlatego fajnie by było zobaczyć do jakiego typu problemów lepiej nadaje się
> closure niż EJB?

I już zauważam rozdźwięk między moim wyobrażeniem Java EE 6 (zestaw
API i wysokopoziomowe narzędzie do budowania aplikacji javowych) od
Clojure (języka programowania z podobnym poziomem abstrakcji, ale dla
innych elementów Javy). Jak napisałem w zaproszeniu (opublikowałem na
swoim blogu - http://jaceklaskowski.pl), Java EE służy jedynie jako
tło do wprowadzenia Clojure od strony jego współpracy z Javą. Należy
się spodziewać niewielkiej liczby elementów samego Java EE, a raczej
prezentacji, że można i czasami może być warto.

Clojure jest reklamowany jako niewielka biblioteka do programowania
współbieżnego, a biorąc pod uwagę, że w Java EE wszystko jest
jednowątkowe, ten temat mamy z głowy, tzn. nie ma się czym zajmować,
bo nie ma okazji.

Spodziewam się jednak miejsc w aplikacjach Java EE, w których użycie
dowolnego innego języka niż Java może być pomocne, bo w końcu Java EE
to jedynie "nakładka na bajtkod javowy", a Clojure jest stosunkowo
zwartym "generatorem bajtkodu".

Sam nie wiem, jak to pójdzie, bo liczę na aktywne uczestnictwo niż
bierne słuchanie. Wciąż zainteresowany?

[johnny]

No właśnie chciałbym zobaczyć kiedy warto? Taki jakiś konkretny przykład? Namacalny?

Podsunąć idee?

Może, współbierzne poszukiwanie 50 stucyfrowych liczb pierwszych algorytmem naiwnym? :P

[Jacek Laskowski]

2012/5/21 johnny <johnny....@gmail.com>:

> No właśnie chciałbym zobaczyć kiedy warto? Taki jakiś konkretny przykład?
> Namacalny?

Konkretny przykład będzie, kiedy to servlet, albo EJB zawoła klaskę
napisaną w Clojure. Co już w środku zależy od publiczności. Wystarczy?

> Podsunąć idee?
> Może, współbierzne poszukiwanie 50 stucyfrowych liczb pierwszych algorytmem
> naiwnym? :P

Rozumiem, że kombinacja :P ma swoje znaczenie w tej propozycji?! :P

Idąc jednak tym tropem, zastanawiam się nad interfejsem dla tej
funkcjonalności - na pewno należałoby stworzyć funkcję, która zwraca
listę z opóźnionym wyliczaniem. Wtedy (take 50...) i po zabawie. Taka
funkcja jest do wywołania z dowolnej klasy javowej, nawet tej, którą
nazwalibyśmy składową Java EE. Przygotuję się z opóźnionych list.
Punkt odnotowany.

Idąc dalej, wymaganie, aby była to liczba stucyfrowa to akurat zadanie
dla funkcji filter. Też ją przedstawię. Punkt odnotowany.

I dalej, pozostaje zaprezentować współbieżność (będzie, odnotowane)
oraz wyliczanie samych liczb dla opóźnionej listy - również odnotowane
(może nawet moglibyśmy się zająć implementacją sita?)

Dzięki za inspirację! Wciąż niewiele w tym samego użycia Clojure w
Java EE, bo sprowadza się do wywołania klasy i jej metody, które
zostały napisane w Clojure i tak chcę poprowadzić spotkanie.

[johnny]

Owszem, ta emotka jest nie bez znaczenia. Zadanie nietrywialne (dla mnie tym bardziej w closure) a prezentacja jutro;)
Cheers