Rozpocząłem lekturę pierwszej książki o najnowszych specyfikacjach spod parasola Java EE 6 - Pro JPA 2: Mastering the Java Persistence API z Apress. Po kilku dniach znalazłem się przy rozdziale 6tym i muszę przyznać, że minęło niewiele ponad 150 stron (z prawie 400), a ja jestem padnięty nawałem informacji. Książka pretenduje do miana książki roku w moim osobistym rankingu książek informatycznych ze względu na formę przekazywania wiedzy w sposób dokładny i przystępny. Mnogość przykładów i wyjaśnień nie pozostawia złudzeń, że to prawdziwa składnica wiedzy mimo, że do końca jeszcze daleko - ja już mam wrażenie, jakbym znał specyfikację JPA2 od podszewki. Oczywiście nie znam, ale moja wiedza teoretyczna wzrosła znacząco. Bardzo podobają mi się dywagacje nt. różnych wzorców projektowych i ich znaczenia w ewolucji JPA2, albo odwrotnie, ich uproszczeniom ze względu na zmiany w JPA2. W przypadku poprzednich książek, jakie ostatnio przeczytałem, normą było przejście przez 1 rozdział w ciągu 1 dnia. Z "Pro JPA 2: Mastering the Java Persistence API" sytuacja zmieniła się diametralnie - nie rozdział/dzień, ale rozdział/3 dni zdaje się być bardziej odzwierciedlający rzeczywistość. Nie sądzę, aby wynikało to z braku cierpliwości, czy coś w ten deseń, ale po prostu z natłoku informacji, jakie przewijają się przez każdą przeczytaną stronę. Jeśli do tej pory, zaznaczałem kilka fragmentów tekstu do późniejszej analizy, to teraz są to całe sekcje (!) Jestem przerażony skomplikowaniem JPA, skoro potrzebna była taka książka, aby wyjaśnić zasady rządzące specyfikacją. Nie jest to wcale wina JPA, ale samego problemu obiektowej reprezentacji danych relacyjnych, którego rozwiązania szukano przez tyle lat i wciąż nie ma tego jedynego.
Pod wpływem uroków JPA2 z "Pro JPA 2: Mastering the Java Persistence API" postanowiłem zestawić środowisko do nauki specyfikacji i tak powstał artykuł Java Persistence (JPA) 2.0 praktycznie - zestawienie środowiska z EclipseLink i Apache Maven 2. Początkowo spisywałem kroki, aby przymierzyć się do screencastu, ale skoro już pojawił się artykuł, pomyślałem, że z nim zawojuję świat :) W artykule wykorzystałem EclipseLink (referencyjna implementacja JPA2), Apache Maven 2 oraz NetBeans IDE i Mercuriala. Pomyślałem o wystawieniu projektu w sieci w jakieś przystępnej formie i padło na Google Code z włączonym Mercurialem. W ten sposób można popróbować się z rozproszonym repozytorium hg i JPA2 jednocześnie. To lubię. Uwagi mile widziane.
p.s. Dostałem informację od Suna, od Oliwi, w związku z tematem Pakiety certyfikacyjne od Suna za 600 PLN do końca stycznia. Dzisiaj, 28.01.2010, jest ostatnim dniem ważności oferty. Śpieszcie się!
No to zastanawiające, jeśli chodzi o publikacje Apress przebrnąłem przez kilka i nie byłem zachwycony (zawsze brakowało mi pewnych informacji), zdecydowanie bardziej za to cenię serie 'in Action' czy w ogóle Manning-a, ale autor autorowi nie równy, ... zajrzę na pewno warto
OdpowiedzUsuńPierwszą książką z Apress, która zrobiła na mnie niesamowite wrażenie była Book review: The Definitive Guide to Grails, Second Edition. Ta o JPA2 jest w tym samym stylu, ale cięższa teoretycznie. Więcej w niej dywagacji i ich rozwiazań, więc nie ma czasu na leniuchowanie - ciągle na najwyższych obrotach mentalnie.
OdpowiedzUsuńMożesz wskazać te książki z Apress, na które trzeba uważać (w złym tego słowa znaczeniu)? Szkoda, abym wziął je na warsztat i popłynął :)
A może powiedział byś coś na temat - dlaczego Mercurial?
OdpowiedzUsuńMercurial z powodów poznawczych. CVS to relikt przeszłości ze swoimi wadami z jedyną zaletą jest, że istnieje i ma wsparcie w IDE. O nim zapominamy. Pozostaje na scenie Subversion (svn). Scentralizowane zarządzanie repozytorium, nietuzinkowe problemy z gałęziami. Odpada w czasach repozytoriów rozproszonych, niescentralizowanych ze wsparciem dla rozgałęziania bez specjalnych konstrukcji. I wchodzimy w obszar SCMów rozproszonych. Tutaj mamy linusowego Gita, Mercuriala (hg) i jeszcze coś, ale nie pamiętam. Różnica między Gitem a Mercurialem jest niewielka, ale wybór Mercuriala padł ze względów na numerowanie wersji - miało być "normalnie" z kolejnymi liczbami całkowitymi, a jest właśnie tak, jak w Gitcie - sumy kontrolne w hexa. To jedyny powód, dla którego usiadłem przy Google Code (hg) zamiast GitHubie (git). Widzę jednak, że coś nie tak z tymi numerami wersji.
OdpowiedzUsuńNie wiem Jacku kiedy Ty masz czas tyle książek czytać. Szczerze podziwiam.
OdpowiedzUsuńA co do "magazynowania" danych, to pojawiają się ostatnio nowe rozwiązania. Jednym z nich jest CouchDB, o którym pewnie będzie w następnym Java Express.
Pozdrawiam!