W jednym z komentarzy Tomasz Bartczak zapytał o nowiny z życia takiej firmy. Tych którzy są zainteresowani tym tematem zapraszam na oficjalny blog mojej firmy. Jako że jest on oficjalny raczej nie znajdziecie na nim przemyśleń o naturze polityków, ale z pewnością od czasu do czasu będę tam publikował noty techniczne oprócz nowin z firmy. Jeśli ktoś będzie zainteresowany wyłącznie technologią proszę subskrybować kanały odpowiednie dla danych kategorii. :-)

Ważnym pytaniem jest – co się stanie z tym blogiem? W sieci istnieje cała masa notatników która nie była aktualizowana od wieków, wszystko wskazuje na to że ten stanie się kolejnym. Może od czasu do czasu coś tu się pojawi ale ani tego nie obiecuję (jak zwykłem do tej pory robić) ani nie planuję.

• Łatwiejsze tworzenie, ang. Ease of Development (Eod): W wcześniejszym szkicu zostały zaprezentowane adnotacje jako sposób na stworzenie Servletu – POJO. Jakkolwiek po dyskusji i odpowiedzi społeczności adnotacje @GET i @POST na poziomie metod zostały wycofane. Zostają jednak adnotacje dla typów – deklaracja sevletu @WebServlet oraz deklaracja filtru @ServletFilter, @WebServletContextListener będzie alternatywnym sposobem na zdefiniowanie context listenera. Dodatkowo adnotacje takie jak @Resouorce będą wspierane w aplikacjach webowych będą zachowywać się tak jak w starszej wersji specyfikacji (2.5).
• Rozszerzalność: szkielety webowe zbudowane na bazie servletów są bardzo popularne. Jest ich bardzo wiele, do wyboru w zależności od problemów, które mają rozwiązywać. Specyfikacja będzie umożliwiała łatwiejszą konfigurację tychże szkieletów.
• Przetwarzanie asynchroniczne: największym wyzwaniem i zmianą jaką podjęli autorzy specyfikacji. W poprzedniej wersji zostały zdefiniowane operacje zatrzymania (suspend) oraz wznowienia (resume). Po publikacji grupa ekspertów podjęła dyskusję na temat przypadków użycia takiego rozwiązania.

Na łamach InfoQ są fragmenty dyskusji na temat fragmentów specyfikacji. Ludzie z JBossa krytykują Jetty, inni krytykują grupę która pracuje nad specyfikacją, że kiepsko współpracuje ze społecznością.

Mam osobiście nadzieję, że ta burza mózgów wyjdzie nam na dobre i adnotacje w Servlet API 3.0 nie będą jedyną nowością. :-)

Kolejny problem jaki wylazł to zapisywanie obiektów w db4o. Początkowo założyłem sobie, że niektórym elementom będę przypisywał lokalizacje (na diagramie interfejs IResourceLink). Okazało się jednak, że pochodne IResource (IFolder, IFile) w Eclipse zawierają sporo informacji, z których zapisaniem był problem (PreferencesStore), a które z punktu widzenia AgaviIDE były zbyteczne. Ilość zapisanych obiektów była przytłaczająca, już po chwili pracy baza projektu miała ponad 1 megabajt. Biorąc pod uwagę to, że jest tam zapisywany model, który zmienia się często i w którym wyszukiwanie powinno być możliwie najszybsze sytuacja taka była nie do przyjęcia. Znowu przekopałem cały kod modelu, tym razem po to by korzystać ze klasy java.io.File. Masakra, koniec końców udało mi się całość uruchomić. Builder działa, obiekty są zapisywane (drugi obrazek). Teraz dorzucić jeszcze wyciąganie informacji z plików php i powinno być ok..

Oto output, którym w tej chwili częstuje builder.

Pomyślcie jak fajnie będzie się edytować routing.. podanie ścieżki, wskazanie akcji i gotowe.. albo konfiguracja walidatorów na podobna do tej z JSF Tools

Oczywiście przy pisaniu napotkałem problemy. Pierwszym z nich było zniknięcie klasy buildera, drugim wywalanie się db4o (dev 7.0). O ile pierwszy uraczył mnie gromadą logów o tyle drugi poza pokaźnym stosem nie dał mi nic. Typ wyjątku com.db4o.ext.ObjectNotStorableException - nazwa w miarę jasna, problem w tym, że za tym żadnego uzasadnienia, powodu dla którego wyjątek by leciał. Zero, dosłownie zero informacji.
Na forum db4o znalazłem parę postów - z nich wyciągnąłem wniosek - konieczne jest użycie taska ant, który zmodyfikuje bytecode klasy, ponieważ w przeciwnym wypadku db4o próbuje serializować obiekt, a gdy mu się nie uda rzuca w/w wyjątek.

Skrypt ant - który załatwia problem, dla potomnych (przeróbka z forum):

<project name="db4o enhance project" default="enhance" basedir=".">

	<!-- inny projekt z workspace'a -->
	<property name="model.classes.location" location="E:/agavi-ide/org.codehouse.model" />
	<!--
	położenie eclipse, db4o szpera w poszukiwaniu zależności klas, tak się składa,
	że mój kod korzysta z paru rzeczy z org.eclipse.core.resources, normalnie ta
	wstawka się nie pojawia
	-->
	<property name="eclipse.location" location="E:/eclipse-3.3/eclipse" />

	<target name="pack-model">
		<echo message="Tworzę archiwum z modelem" />
	    <jar destfile="lib/model.jar">
	        <fileset dir="${model.classes.location}/bin/">
	        	<!-- włączamy wszystkie skomilowane klasy -->
	            <include name="**/*.class" />
	        </fileset>
	    </jar>
	</target>

	<!-- classpath dla projektu -->
	<path id="project.classpath">
		<pathelement path="${basedir}/bin" />
		<fileset dir="lib">
			<include name="**/*.jar" />
		</fileset>
		<fileset dir="${eclipse.location}/plugins/">
			<include name="**/*.jar" />
		</fileset>
	</path>

    <!-- odwołanie do taska z db4o-tools.jar -->
    <taskdef name="db4o-enhance" classname="com.db4o.enhance.Db4oEnhancerAntTask" classpathref="project.classpath" />

	<target name="enhance" depends="pack-model">
		<!-- przeoranie źródeł i zależności -->
		<db4o -enhance classtargetdir="${basedir}/bin" jartargetdir="${basedir}/lib">
			<classpath refid="project.classpath" />
			<sources dir="${basedir}/bin" /> <!-- w tym katalogu db4o zajmie się plikami .class -->
			<jars dir="${basedir}/lib">
				<include name="*.jar" />
				<exclude name="db4o-*.jar" />
				<exclude name="ant.jar" />
				<exclude name="bloat-1.0.jar" />

			</jars>
		</db4o -enhance>
	</target>

</project>

Program prezentacji zapowiadał się i był ciekawy. Przede wszystkim rzecz z którą wiązałem największe zainteresowanie to tandem Spring+OSGi, głównie z racji na podpinanie Springa pod Eclipse RCP. Drugi temat, który był mi bliski to Spring Web MVC + Freemaker, z racji na to, że z jednym i drugim będę miał prawdopodobnie styczność w pracy.
Trzeci tematem, który budził z mojej strony stosunkowo niskie zainteresowanie było JRuby, jednak sama treść prezentacji i sposób jej prowadzenia spowodowały że wciąż jestem pod wrażeniem tego mariażu Javy i Ruby. Wiktorowi podczas prezentacji wyskoczył tylko jeden chochlik, którego dosyć sprawnie wyeliminował. :)

Na końcu chciałem wspomnieć o tym że i ja miałem swój udział na WarsJavie prowadząc warsztat na temat JAXB. Prawdę powiedziawszy czułem się nieco przerażony - wszyscy podjęli się poważnych tematów, Spring, OSGi, JRuby, JMS podczas gdy ja miałem powiedzieć o bibliotece do robienia obiektów z XMLa i XMLa z obiektów. Szczerze powiedziawszy miałem również spore obawy czy treść, którą przygotowałem będzie w stanie zapełnić półtorej godziny, jakie dostałem na prezentację tematu. Postanowiłem więc dokładnie napisać co jest do zrobienia, dopieścić przykłady, wynikiem czego kładłem się spać o 3 w nocy. Węsząc problemy zawczasu spakowałem laptopa, jak się okazało słusznie - obudziłem się na tyle prędko, że zdążyłem wciągnąć spodnie, wybiec na tramwaj.. Gdy dotarłem na miejsce była już 9:10, dosłownie pięć minut przed rozpoczęciem. Byłaby niezła wpadka gdyby zwiał mi tramwaj i musiałbym czekać 10 minut na kolejny. Szczęście - udało się dotrzeć. Na początku drobne problemy z rzutnikiem, następnie z konfiguracją rozdzielczości.. i tym sposobem uleciało dobre 15 minut.
Parę slajdów, które miałem przygotowane minęło stanowczo zbyt szybko i musiałem siadać do klawiatury. Dziwna rzecz, kiedy człowiek siada, używa tylko dłoni, a mimo wszystko język ma zaplątany. :) Zaiste, problematyczne było pisanie i mówienie. Właściwie to więcej pisałem jak mówiłem. Czas zleciał bardzo szybko, zdążyłem w zasadzie omówić 2 aspekty, na które się gotowałem czyli użycie adnotacji i generowanie kodu ze schematu XSD jak i jeden na który się nie przygotowywałem - radzenie sobie z wyjątkami ;). Nie zdążyłem nic powiedzieć na temat wpływania na zachowanie kompilatora schemy (xjc) poprzez tworzenie plików xjb oraz pisania własnych pluginów. Te punkty staną się najprawdopodobniej tematem przyszłych not.
Szczerze byłem również bardzo mile zaskoczony tym, że ktoś poprosił o kod po prezentacji. :)

Na grupie pojawił się wątek z opiniami po warsztatach. Niestety nie byłem na Javarsovii i nie mam punktu odniesienia "co było lepsze". Jakkolwiek zdaje mi się, że tradycyjne prezentacje, gdzie jest kilkanaście slajdów i odrobina kodu zdaje się lepsze. Daje dosyć ogólny pogląd na więcej aspektów niż powstający kod. Z drugiej jednak strony forma warsztatu jest bardziej efektowna, co można było bez wątpienia zaobserwować w przypadku JRuby. Z resztą sama dyskusja tuż po prezentacji Wiktora mogła pokazać jak wiele emocji budzi owe novum. :)

Dla zainteresowanych - zamieściłem źródła wszystkich projektów jakie realizowałem przed i w trakcie prezentacji oraz filmik "z kodowania" (nagrany w Cam Studio). Ostrzegam, że avik jest słabo skompresowany i po wypakowaniu zajmuje 670MB!

• Aktywacja
  Wyobraź sobie drzewo obiektów, które są ładowane z db4o. Kiedy Twoja aplikacja dobiera się do własności z korzenia z drzewa, normalnym zdaje się wczytanie całego drzewa do pamięci, prawda? Z tym, że jeśli drzewo jest rozłożyste, zajmuje to wiele czasu i wile pamięci. db4o dostarcza teraz funkcjonalności, która wczytuje tylko te obiekty, których na prawdę potrzebujesz. Proces ładowania tych własności nazwaliśmy właśnie 'aktywacją'.
• Zapytania natywne
  Zapytania natywne są w pełni bezpieczne (typesafe?), można je refaktoryzować. Są również normalnie obsługiwane w czasie kompilacji, zgodnie ze składnią języka, w którym został napisany program. Zaglądając pod maskę - wytażenie zapisane przy użyciu konstrukcji języka jest analizowane i konwertowane tak by używać indeksów tam gdzie tylko można. Dla zainteresowanych PDF w języku angielskim.
• Wydajność
  Obydwa powyższe mechanizmy są przeźroczyste, jakkolwiek Twój byte-code po kompilacji musi zostać przeanalizowany i zoptymalizowany by wykorzystać zaawansowane możliwości, które oferuje db4o. Optymalizator jest dostępny jako task dla Ant bądź jako aplikacja napisana w Javie. Możesz wykonywać swoją pracę w sposób, w jaki robiłeś to do tej pory, a Twoje aplikacje oparte o db4o będą po prostu działały szybciej i zabierały mniej pamięci.

Jak twierdzą Twórcy db4o - z wydaniem wersji developerskiej 7.0, dzięki połączeniu 3 wymienionych wyżej technik, zrobili duży krok w przód, w kierunku realizacji zasadniczych celów, dla których powstaje ich produkt:

• Developer nie powinien pisać kodu wiążącego się z zapisywaniem obiektów. To jest rola, którą ma pełnić db4o.
• Standardowy język programowania. Idealna obiektowa baza danych używa konstrukcji dostarczanych w języku programowania oraz nie narzuca nowej składni.
• Łatwość użycia nie ponosi za sobą straty wydajności. Kod, którym zarządza system utrwalania obiektów może być wydajniejszy od pisanego z ręki oszczędzając równocześnie więcej pamięci.

Kontynuując dalej czytanie newsa trafiamy na pytanie - "Wszystko do brzmi jak typowy techniczny bełkot, ale jak to wszystko może mi pomóc w realizacji projektów w ramach czasowych i w jaki sposób przekłada się na szczęście mojego klienta?"
W odpowiedzi wymienione zostają plusy, jakie niosą ze sobą nowe możliwości z perspektywy użytkownika:

• Możesz zachować swój spójność i porządek swojego kodu nawet gdy w grę wchodzi odczytywanie obiektów z bazy
• Używając db4o z dużymi drzewami obiektów staje się łatwiejsze, ponieważ nie musisz już dłużej przejmować się inicjowaniem obiektów w Twoim kodzie
• Twoja aplikacja będzie działała szybciej równocześnie pochłaniając mniej zasobów, ponieważ wczyta obiekty których potrzebuje w danej chwili.
• Nowy optymalizator może być uruchamiany z poziomu Twojego IDE, optymalizując klasy i jar-y w locie. Nie będziesz musiał zmieniać zachowania swojego IDE w żaden sposób by móc skorzystać z mechanizmu aktywacji i optymalizacji zapytań.

Dlaczego o tym wszystkim wspominam? :) Ponieważ zastanawiam się czy użyć db4o do obsługi "modelu" w Agavi IDE. Modelem w przypadku Agavi IDE były by przede wszystkim informacje o modułach, akcjach itp.

Czas jakiś temu udało mi się stworzyć pierwszy działający edytor w oparciu o Eclipse.
Kilka informacji co pod spodem:

• SharedHeaderFormEditor - ładny tekstowy nagłówek oraz możliwość dodawania zakładek
• FormPage i FormToolkit - użyte do stworzenia układu, który widać na załączonym obrazku
• JFace Databinding - zapewnia propagowanie zmian z formularza do obiektów
• JAXB 2 - mapowanie plików XML do odpowiednich klas
• JFace - table viewer i parę innych dodatków

Całość ogólnie jest prosta niczym konstrukcja cepa, w działaniu sprawia się dobrze. Jak tylko ogarnę kod postaram się opisać krok po kroku jak można coś podobnego stworzyć na własny użytek.

Splatch wraca do gry i będzie grać wysoko! ;-)

Wiadomo, że ten release wyjdzie, podobnie jak Europa, 29 czerwca. Pojawiły się pierwsze zmiany, które wejdą w skład nowej dystrybucji. Na tą chwilę jeszcze nie wiadomo ile projektów będzie obejmować Ganimedes, póki co jest ich kilka, miejmy nadzieję, że przynajmniej tyle co Europa!