piątek, 26 marca 2010

4developers

Dziś miałem okazje wziąć udział w konferencji 4developers. Udział w konferencji zawdzięczam mojemu ukochanemu Poznan JUG.

Walka o życie – kuzyni i następcy Javy opanowują świat Michael Hunger prezentacja była tak nudna,że po 10 minutach wyszedłem i przeniosłem się do sali ze ścieżki PHP. Pomimo tego że nigdy nie napisałem linijki w PHP(z czego tak naprawdę jestem dumny) to temat cloud computingu przemawiał do mnie jak najbardziej.

PHP w chmurze Ivo Jansch prezentacja okazała się bardzo ciekawa i nie miała za wiele wspólnego z PHP. Na początku omówione zostały podstawowe pojęcia związane z cloud computing, a w szczególności: IaaS, PaaS, SaaS. Jeśli chodzi o IaaS to jest to podstawowy poziom, który z punktu widzenia klienta opiera się na tym że uzyskujemy dostęp do hardware (sami definiujemy wymagania co do tego hardware )na którym możemy zainstalować system operacyjny, a następnie samą aplikacje. To gdzie fizycznie zostanie uruchomiona aplikacja najczęściej nas nie interesuje...
Instalacja systemu operacyjnego jest zazwyczaj pomijana ze względu na to, że najczęściej wybiera się obraz maszyny wirtualnej z zainstalowanych już systemem operacyjnym. Jako developer dostajemy dostęp do takiego "obrazu" i możemy sobie instalować naszą aplikacje. Ivo szczególnie polecał zaznajomienie się z rackspacecloud, który ma dostarczać bardzo wygodne API, dzięki któremu z poziomu PHP można odpalić nową maszyną wirtualną i zdeployować aplikacje. Kolejny poziom to PaaS, czyli w tym przypadku przechodzimy o poziom wyżej - z poziomu systemu operacyjnego na którym możemy sobie odpalić dowolną aplikacje, otrzymujemy platformę (w pewnym sensie możemy mówić o serwerze-usłudze) na którym odpalamy naszą aplikacje. Najlepszym przykładem jest tutaj Google App Engine który pozwoli nam zdalnie deployować aplikacje napisane w Java i Python. Jak na razie nie ma dostępnej darmowej infrastruktury PaaS dla PHP (istnieje płatne rackspacecloud sites). Ostatni poziom to SaaS czyli gdy tak na prawdę sama aplikacja jest usługą, z której to możemy korzystać. Najlepszym przykładem to Google Apps (docs, spreadsheet) lub też SalesForce CRM. Następnie Ivo omówił typowe problemy (choć lepiej nazwać to specyfiką środowiska) związane z tworzeniem aplikacji uruchamianych w chmurach: bezpieczeństwo, obsługa stanu, regulacje prawne. Na końcu wspomniał jeszcze o private developer clouds(jako VMware vSphere oraz tych udostępnianych przez terremark).
Automatyczne generowanie kodu Marek Berkan prezentacja sponsora, która niestety okazała się bardzo słaba. Mimo, że nie spodziewałem się cudów, to jednak liczyłem na coś więcej ... Przedstawione zostało parę scenariuszy, w których to generowanie kodu ma być bardzo użyteczne: generowanie kodu encji oraz DAO na podstawie schematu bazy danych, generowanie obiektów Javy z XML. Wszystko to było mało odkrywcze: użycie Hibernate, JAXB. Patrząc na Hibernate z punktu widzenia "generacji kodu" to wyniki nie są oszałamiające: głowną bolączką ma być brak automatycznego generowania stałych definiujących nazwy kolumn. W czasie prezentacji pokazał 2 pomysły, które wydają się bardzo sensowne: generowanie stałych dla propertiesów Strutsowych form beanów oraz dla kluczy bundli. Dzięki temu wszelkie zmiany w źródle (definicji form beana czy plikach bundli) są wyłapywane przez kompilator.
TopLink Grid – skalowanie aplikacji korzystających z Java Persistence API Waldekmar Kot - jedna z najlepszych (przynajmniej dla mnie ) prezentacji. Waldek zaczął trochę ospale od przedstawienia standardu JPA i podstawowych pojęć z nim związanych: EntityManager, EntityManagerFactory, PesistenceUnit i czegoś tam jeszcze. Ze względu na to że używam Hibernate nie do końca rozumiem te wszystkie pojęcia...
Następnie omówił standarodowe mechanizmy cachowania: cache transakcyjny(patrząc z perspektywy Hibernate cache związany z Session), oraz ten drugi (nie pamiętam dokładnie jakiego Waldek użył sformułowanie, ale chodziło o cache na poziomie SessionFactory czyli, second-level cache). Ten ostatni jest współdzielony przez cache transakcyjne w ramach pojedynczego JVM, ale może być także współdzielony w ramach wielu JVM. W ten to sposób doszedł do sedna, czyli pojęcia Data Grid: jako osobnej warstwy (najczęściej osadzonej na innym JVM/innej maszynie fizycznej niż nasza aplikacja ) która świadczy usługi przechowywania ale także może przetwarzać obiekty. Zazwyczaj taki Data Grid składa się z większej liczby węzłów, które to tworzą ze sobą sieć Peer-to-Peer i dostarczają nam możliwość bezpiecznego/skalowalnego/wydajnego przechowywania w pamięci dużej ilości danych. Bardzo podobała mi się mechanizm związany z możliwością wykonywania operacji bezpośrednio na Data Grid: zamiast ściągać dane do aplikacji, modyfikować je i odsyłać, można "wysłać" operacje bezpośrednio w Data Grid. Połączenie ze sobą Data Grid (w przypadku Oracle mówimy tu o konkretnym produkcie Oracle Coherence) wraz z implementacją JPA (Oracle Toplink) daję nam Oracle TopLink Grid. Takie połączenie pozwala na zwiększenie wydajności i skalowanie naszej warstwy DAO poprzez sam mechanizm cachowania, ale jednocześnie dostarcza kilku nowych możliwości. Chodzi o to że Oracle Coherence pracujący tuż za plecami naszej warstwy DAO (ale przed bazą danych) może pracować w jednym z 3 trybów:
  • Cache: standardowy second-level cache (cachowanie na podstawie id)
  • Read: w stosunku do trybu powyżej, nasze zapytania SQL są "przechywytywane" przez Data Grid, interpretowane oraz pobierane bezpośrednio z cache. Zapytania mają być rozpraszane na poszczególne instancje składające się na Data Grid (osobiście jestem ciekaw jak wygląda to w przypadku zapytań agregujących które przechodzą wzdłuż przez dane fizycznie przechowywane na innych instancjach Data Grid)
  • Entity: dodatkowo w przypadku modyfikacji najpierw modyfikowane są obiekty w Data Grid a później dane w bazie danych. Jednocześnie jest możliwe takie ustawienie że dane do modyfikacji są buforowane (ze względu na ilość lub czas) i wysyłane w 1 paczce do bazy danych.
Temat na pewno był bardzo ciekawy, ale ze względu na ograniczenia czasowe (dobrze, ze po tej prezentacji był obiad- a tylko szczęśliwcy dostali voucher :( , można było jeszcze trochę Waldka dopytać) nie udało się pokazać więcej.


Zbuduj pierwszą aplikację typu RIA z wykorzystaniem Flex 4 Piotr Walczyszyn
- bardzo fajna prezentacja, której głównym punktem była prezentacja Desktop Keeley :) Prezentacja składała się z 2 części: teoretycznej, w której omówione zostały podstawowe informacje na temat platformy FLEX, oraz praktycznej, w której to Piotr przedstawił w jaki sposób tworzyć w niej aplikacje. W części pierwszej można było usłyszeć o Flex SDK, sposobach komunikacji pomiędzy modułami SWF a częścią serwerową (SOAP, HTTP/HTTPS, AMF/AMFS, RTMP/RTMPS). Nie mogło się obyć bez prezentacji przykładowych aplikacji wykorzystujących FLEX: http://www.windowshop.com/, http://www.taaz.com/makeover.html, oraz "popisowej" http://www.adobe.com/devnet/flex/tourdeflex/. Następnie pojawiło trochę informacji na temat Adobe AIR, czyli runtime umożliwiający uruchamianie aplikacji Flex na desktop. Dzięki temu że można wyjść poza sandbox przeglądarki można skorzystać z dodatkowej funkcjonalności: instalacja i uruchamianie jako natywna aplikacja, dostęp do systemu plików, dostęp do wbudowanej bazy danych SQLite, możliwość uruchamianie aplikacji na wielu platformach: Windows, Mac, Linux a także Nokia S60 i Android...
"Lokalnym" przykładem aplikacji Adobe AIR to e-deklaracje, a inne ciekawe można zobaczyć na stronach Adobe. W 2 części Piotr przedstawił w jaki sposób stworzyć prostą aplikacje we Flex 4: aplikacja stworzona we FLEX łączy się z serwerem - Apache Tomcat, BlazeDS, MySQL. Musze przyznać, że robiło to duże wrażenie, szczególnie jeśli chodzi o skrócenie czas developmentu - choć nie do końca wiem czy to zasługa FLEX4 czy Flex Builer. Szczególnie spodobał mi się w części klienckiej mechanizm automatycznego generowania proxy oraz dto dla wystawionych na serwerze usług. Co ciekawe, zaimplementowany został (bez pokazania szczegółów) mechanizm asynchronicznego powiadamiania klientów. Miał to działać na takiej zasadzie, że usługa dodająca element do bazy wysyłała wiadomość do JMS topic. Na tym topicu "słucha" BlazeDS i powiadamia klientów za pomocą HTTP.
Możliwość asynchronicznego powiadamiania klientów (server push) bez potrzeby korzystania z warswty pośredniej - JMS, ma być zaimplementowana w komercyjnym Flash Media Server lub open-source red5.

Co nowego w Java SE 7? Marcin Kalas hmm nie do końca chyba słuchałem, a przynajmniej nic nie zanotowałem... chyba przychodzą na tą prezentacje miałem złe nastawienie: no bo przecież mój ukochany Websphere 6.1 działa na Java 5... Z tego co pamiętam to zostało wspomniane o paru udogodnieniach:
nowe File I/O, udogodnienia związane z przetwarzaniem równoległym JSR 166, nowy garbage collector, skompresowany wskaźnik 64 bitowy. Myślę że wszystko co było powiedziane można znaleźć tu

Craftsmanship i wzorce projektowe Sławek Sobótka - prezentacja zdecydowanie mniej techniczna od innych, ale całkiem ciekawa. Sławek skupił się na przedstawieniu wzorców projektowych jako ważnego ogniwa dojścia do profesjonalizmu. Wzorce nie tylko wypada znać, rozumieć, ale też wiedzieć kiedy stosować. Ważne jest aby pamiętać, że zastosowanie każdego z wzorców niesie ze sobą określone korzyści ale też i koszty. Mi osobiście spodobało się użycie chain of responsibility do wybierania strategii oraz wzbogacanie strategii poprzez decorator.

Modele komponentowe SCA, OSGi, Distributed OSGi i OSGi Enterprise a Java EE Jacek Laskowski - dziwna prezentacja, chyba nie do końca wiem do czego Jacek dążył ... Rozpoczęło się od próby zdefiniowania podstaw: interfejs, usługa, komponent poprzez bardziej abstrakcyjne byty: "rusztowanie" i "szkielet", ale później poszło już z górki. Jacek przedstawił historie powstawania "architektur komponentowych" na platformie Java. Zaczęło się od JavaBeans, przez EJB, Spring, JEE, OSGi, Spring DM, OSGi Blueprint Container, Distributed OSGi, Enterprise OSGI, SCA. Ja wyłączyłem się przy SCA i tego przejścia nie zaczaiłem...
Prezentacja miała omawiać aspekty programowania deklaratywnego, ale tak na prawdę przemieniła się (przynajmniej ja to tak odebrałem) jako refleksje na temat architektury komponentowej na platformie. Jacek (w mojej ocenie) popełnił 2 błędy/nieścisłości:

  • przyrównanie JavaBean do POJO - JavaBean to jest POJO, ale POJO to niekoniecznie JavaBean.
  • Spring to nie tylko DI, ale też AOP i Abstraction Of Services. Jest to znacząca różnica, szczególnie w momencie gdy historycznie porównujemy Spring do J2EE.