Prezentacje odbyła się przy współpracy SpringSource i Warszawa JUG. Oficjalnie odbywały się zapisy przez Internet na prezentacje, była lista uczestników i lista rezerwowa, do tych pierwszych przychodził mail z biletem, który trzeba było wydrukować, aby wejść do środka.
Wszystko okazało się niezłą ściemą, ale i tak ludków przybyło całkiem sporo.
Prezentacja odbywała się w tej samej sali jak podczas WarsJava, ale publika tym razem o wiele bardziej dopisała, i dla kilku osób zabrakło krzeseł.
Zgodnie z zapowiedziami Arjen Poutsma miał w godzinach 17-20 zaprezentować nam głównie co nowego jest przygotowywane w Spring 3.0. Po przeczytaniu abstractu prezentacji zapowiadało się naprawdę ciekawie:
- New features in Spring 3.0
- Performance tuning Spring 3.0
- An overview of Spring Projects
- Enterprise capabilities for Spring
Pojawił się z około 15 minutowy opóźnieniem, po rozłożeniu maca i posileniu się pizzą mogliśmy zaczynać.
Już na początku, okazało się, że Arjen Poutsma ma przygotowane 2 prezentację i zacznie od tej bardziej ogólnej: p.t „7 reasons to use Spring”. Zaczęło się od nieśmiertelnej maksymy autorstwa Alana Kaya „Simple things should be simple, complex things should be possible” i później kolejno zostały omawiane poszczególne powody, dla których warto wybrać Springa:
- DI - Nastąpiła krótka opowieść o POJO, jako o obiektach javowych niezależnych od środowiska, - czyli takich które nie posiadają żadnych „environment specific imports”i zależności od żadnych lookup methods. Dalej krótka opowieść czemu POJO są takie fajne i czemu EJB w wersji 2 nie było fajne. Potem był mały przykładzik, w którym to można było zobaczy w akcji mechanizm DI operujący na POJO, gdy konfiguracja została opisana raz to w XML, raz za pomocą annotacji. Mnie bardziej zaciekawił slajd p.t „ Why not use Java EE DI ?”, w którym to zostało podkreślone, że w JAVA EE „wstrzykiwanie zależności” polega na „wstrzykiwaniu” obiektów z JNDI, czyli takie „wstrzykiwanie” nie będzie działać w środowisku JUNIT.
- JdbcTemplate –zaczęło się od krótkiego przypomnienia, że do pewnych zadań (batch operations, stored procedures, sophisticated/analytic queries) lepiej jest cały czas korzystać z czystego JDBC niż całej maści różnych ORM. Następnie typowy przykład ile się trzeba namęczyć, jeśli chodzi o ilośćniezbędnych linii kodu oraz o odpowiednie zamykanie zasobów, aby korzystać z JDBC API. Używanie JdbcTemplate w takich sytuacjach nie tylko pozwoli nam drastycznie zmniejszyć ilość kodu, która musielibyśmy napisać, ale też zajmie się zamykaniem zasobów: PreparedStatement, ResultSet, Connection. Ze względu na to, że każda operacja wyciągnięcia danych za pomocą SQL sprowadza się jedynie do podania zapytania, jego parametrów oraz ewentualnego „obrobienia” ResultSeta reszta to „boiler plate code”, którym lepiej się nie zajmować i zostawić go JdbcTemplate.
- Exception hierarchy – równie powiązane z dostępem do BD, stworzona w Springu hierarchia wyjątków, która umożliwia w spójny sposób radzenie sobie z wszelkiego rodzajami błędami związanymi z dostępem do bazy danych. Kod błędu ze sterownika JDBC jest mapowany w zależności od używanej bazy danych na wyjątek określonego typu, który możemy złapać i obsłużyć jeśli będziemy mieć taką potrzebę, np. złapać DeadlockLoserDataAccessException aby ponowić operację.
- AOP – nadmienione zostały podstawowe pojęcia: pointcut, jointpoint, aspect, cross cutting concern, wraz z typowymi przykładami wykorzystania AOP: transakcji, logowanie, bezpieczeństwo, cachowanie. AOP przede wszystkim ma służyć aby poradzić sobie z 2 problemami:
- Code tangling – gdy klasa/metoda nie zajmuję się wyłącznie logiką dla której została stworzona, ale dodatkowo zawierają kod związany z innymi funkcjonalnościami: sprawdzanie warunków bezpieczeństwa, obsługa logowania/transakcji.
- Code scattering – w przypadku gdy kod (dotyczy to choćby pojedynczego wywołania) związany z daną sprawą(aspektem) jest rozsiany pomiędzy wiele klas, które w swoich założeniach powinny zajmować się jedynie swoją funkcjonalnością.
- Transactional - czyli możliwość deklaratywnego definiowania transakcji.
- Scripting Languages - możliwość definiowanie beanów w językach skryptowych uruchamianych na JVM: Groovy, BeanShell, JRuby. Ma to umożliwiać tworzenie rozwiązań w stylu "mix 'n match", w których to backend systemu będzie napisany w Javie a fronetend w języku skryptowym, a wszystko będzie spięte przez Springa.
- OSGI - jako technologia, która pozwala poradzic sobie z 2 problemami w świecie Javy: "JAR hell" oraz "module encapsulation". Dodatkowo wymienione zostały 2 produkty SpringSource, związane z OSGI: Spring Dynamic Modules oraz Spring DM Server. Arjen pokazał w jaki łatwy sposób w Springu opakować istniejącego beana aby stał się usługą OSGI, bez potrzeby uzależniania naszego kodu od inwazyjnego API OSGI
Nie mogło się obejść od krótkiego omówienia czym jest REST i co w nim chodzi. Były to bardziej pobieżne informację do tych, które umieściłem tutaj. Dodatkowo Arjen uczulił szczególnie na nadmierne/niewłaściwe wykorzystywanie parametrów zapytań, które w swoim założeniu powinny być "parametrami wejściowymi algorytmów", np. http://www.google.pl/search?q=java
Często zostają jednak użyte do innych celów (przemycanie faktycznej metody do wykonania), poza tym mogą być ignorowane przez proxy. 2 sprawą, która powinna wzbudzić naszą czujność są czasowniki w URL, ponieważ URL dotyczy zasobu/bytu który jest "rzeczą" a nie czynnością.
Pozostała cześć prezentacji okazała się kopią tego co znajduję się na blogu Arjena.
Podsumowując, prezentacja była całkiem niezła,(zresztą jak wszystkie te przeprowadzane przez konsultantów SpringSource), ale skierowana dla osób, które nie znają Springa lub znają go bardzo pobieżnie. Było zbyt mało informacji na temat Spring 3.0 (który tak na marginesie oprócz REST, nowego EL oraz odcięcia się od Javy 1.4 nie wnosi zbyt wiele nowego), a zgodnie z abstractem prezentacji to właśnie miało być tematem przewodnim . Dodatkowo w wielu miejscach argumenty przedstawiane przez Arjena, które miały świadczyć o wyższości Springa nad innymi technologiami były trochę "out-of-date".
Brak komentarzy:
Prześlij komentarz