82. Spotkanie Warszawa JUG - Koziołek o Vaadin* Bartek Kuczyński
Bartek Zdanowski
W imieniu własnym, Warszawa JUG oraz Prelegenta zapraszam wszystkich
na 82. spotkanie Warszawa JUG,
które odbędzie się 24go maja 2011, w gmachu MIMUW, sala 5440,
ul.Banacha 2, Warszawa
Koziołek o Vaadin*
Abstrakcja:
W trakcie mojej prezentacji postaram się przybliżyć Vaadin[1]. Jest to
framework bazujący na GWT[2], który pozwala na szybkie i proste tworzenie
aplikacji WEB. Ukrywa on mechanizmy GWT takie jak komunikacja klient -
serwer czy przetwarzanie zdarzeń przez co programista może skupić się
na tworzeniu aplikacji, a warstwę transportową pozostawić w gestii
biblioteki. Zaprezentuję możliwości Vaadin w środowisku prostej
aplikacji web oraz jak można spiąć ją z aplikacjami EE za pomocą
różnych technologii. Jako, że java4people jest o "językach
alternatywnych" to będzie też przykład integracji Vaadin + Scala
Plan:
- Historia - po co na Vaadin
- GWT - baza technologiczna
- Vaadin w świecie Java
- Jak to działa - architektura Vaadin
- Komponenty
- Integracja na przykładzie Guice
- "Scalowanie" Vaadin
- Czego nie "się nie da"
- Podsumowanie
O prelegencie:
Nazywam się Bartek Kuczyński aka "Koziołek". Z komputerami mam do
czynienia od 4 roku życia gdy w domu pojawił się ZX Spectrum, a ja
dzielnie zapisałem cały ekran literką A. Później moja droga była
typowa, czyli noce zarwane przy "duuumie" i "maralu kombacie", aż na
początku liceum zacząłem się bawić w programowanie. Najpierw były to
makra VB dla Excela, a później proste programy w VB. Na studiach
zainteresowałem się Javą, ale "przy okazji" poznawałem FORTRANa i C.
Od kilku lat pracuję jako programista Java.
Obecnie zajmuję się systemami rozliczeniowymi w
Krajowej Izbie Rozliczeniowej, gdzie odpowiadam za utrzymanie i rozwój
oprogramowania od strony technicznej.
Prowadzę bloga [3]
Frameworków jest wiele, ale na spotkaniu z Bartkiem możemy się
dowiedzieć czy warto uczyć się właśnie Vaadina (na pewno!) -
zapraszam.
*Tytuł wymyśliłem ja - Bartek Zdanowski, bo Koziołek nie odpisywał na
maila, ale chyba jest dobry ;)
Planowany czas prezentacji to 1,5h, po których planuje się
15-30-minutową dyskusję.
[1] http://vaadin.com/
[2] http://code.google.com/webtoolkit/
[3] http://koziolekweb.pl/
--
Pozdrawiam,
Bartek Zdanowski
Bloguję http://blog.bartekzdanowski.pl i twittuję
http://twitter.com/bartekzdanowski
Confitura 2011 (dawniej Javarsovia) - http://confitura.pl
KO Warsjawa 2011 - http://warsjawa.pl
Bartek Kuczyński
Pozdrawiam
Bartek "Koziołek" Kuczyński
http://koziolekweb.pl
Lepiej pomyśleć dwa razy i zacząć programować
niż dwa razy programować i potem zacząć myśleć
\ /
~00~
\_/
|||
W dniu 18 maja 2011 08:43 użytkownik Bartek Zdanowski
<bartek.z...@gmail.com> napisał:
> --
> Otrzymujesz tę wiadomość, ponieważ subskrybujesz grupę dyskusyjną Google o nazwie "Warszawa Java User Group (Warszawa JUG)".
>
> Aby zamieszczać posty w tej grupie, wyślij e-mail na adres warsza...@googlegroups.com.
> Aby anulować subskrypcję tej grupy, wyślij e-mail na adres warszawa-jug...@googlegroups.com.
> Aby uzyskać więcej informacji, odwiedź tę grupę pod adresem http://groups.google.com/group/warszawa-jug?hl=pl.
>
>
Bartek Zdanowski
piotr bitner
Poszukujemy 1 testera do aplikacji przetwarzajacej pliki z danymi rejetrowanymi przez urządzenia telekomunikacyjne (aplikacja nazywa sie IUM) - na 2 miesiące (czerwiec-lipiec).
Nie potrzeba żadnej bardzo specjalistycznej wiedzy, aplikację tester bedzie traktował jako „black-box” , który dostaje plik z rekordami i dla każdego rekordu ma dać sensowny (zgodny z załozeniami) output.
Oczekujemy jedynie:
- znajomosci Unix i Windows (operacyjnie, po prostu musi być samodzielny)
- podstawy java (bardziej aby rozumieć kod/technologię pod spodem aplikacji IUM, aniżeli samodzielnie programować)
- mile widziane doświadczenie w telekomunikacji (na poziomie rozumienia zjawiska powstawania w urządzeniach telekomunikacyjnych rekordów rejestrujących zdarzenia – takie jak np. połączenie telefoniczne)
- analityczne podejscie (potrzebne będzie w stworzeniu scenariuszy testowych zarówno pozytywnych jak i negatywnych, na podstawie opracowanego przez nas Technical Design, które potem bedzie testował)
- sparwnosć i rzetelnosć dokumentowania testów (dobrze jakby to kiedyś robił, ale damy templejty dokumentów itp)
Zakładamy, że tester szybko nauczy się operowania aplikacją IUM, przygotowania danych (pliki z rekordami testowymi) oraz sprawdzania czy rezultat dla tych danych jest zgodny z oczekiwaniami scenariusza.
No i oczywiscie angielski – niezbędny do czytania dokumentacji IUM-a .
Ewa Bitner
HP Polska