Exverxes Tech Blog

Jak w zasadzie działają moduły flexa

2010-09-30T00:39:00.000-07:00

Ponieważ straciłem ostatnio sporo czasu na próbach podłączenia modułu do istniejącej już aplikacji (nie mając dostępu do aplikacji/źródeł), postanowiłem podzielić się swoimi przemyśleniami.

Generalnie, flex jako flex jest bardzo fajnym narzędziem, ale jak każda technologia ma trochę problemów. Ja ostatnio natrafiłem na problemy związane z podłączeniem modułu który komunikował się za pomocą WebService. Warto nadmienić, że sam moduł, został przygotowany nie jako moduł, ale jako osobna aplikacja webowa, co dostarczyło mi dodatkowych problemów. Przejdźmy do sedna:

Moduły/Aplkiacje flexowe można ładować na kilka sposobów. Po pierwsze możemy skorzystać z loadera i przy jego pomocy załadować aplikację. Przykładowy kod wygląda następująco:
MXML:

 <mx:moduleloader url="SomeModule.swf"/>

AS:



var loader : ModuleLoader = new ModuleLoader();
loader.url = "SomeModule.swf";
contentPanel.addChild(loader);

Sprawy oczywiście się dalej komplikują, bo jak można się domyślić, nie jest to jedyny sposób ładowania modułów. Po pierwsze możemy użyć różnych loaderów. Dla przykładu SwfModuleLoader nadaje się do załadowania aplikacji a nie modułu (jak również swf wykonanego we flashu). Zastosowanie tego loadera potrafi rozwiązać wiele problemów które można spotkać z innymi loaderami, w szczególności można przy jego pomocy prawidłowo ustawić moduł na ekranie. Obsługuje on również eventy związane ze zmianą wielkości obszaru aplikacji. Użycie tego loadera rozwiązało moje problemy związane z ładowaniem modułu (o których napiszę dalej).

Aby sprawy dalej skomplikować, można również użyć ModuleManager, co zostało zastosowane w przypadku aplikacji do której się podłączałem. Stosowanie ModuleManager wymaga jednak nieco innego podejścia. Jest to element który zarządza załadowanymi modułami. Przykładowy kod zastosowania wygląda następująco:


var moduleInfo : IModuleInfo;
moduleInfo = ModuleManager.getModule(_url);
moduleInfo.load();
var module:Object = moduleInfo.factory.create();
container.addChild(module);

Jak widać, flex pozwala na na prawdę dużą dowolność. W szczególności można użyć po prostu Loader. W zasadzie nie było by to aż tak skomplikowane, gdyby nie fakt, że dodatkowo jest jeszcze takie pojęcie jak ApplicationDomain. Domena aplikacji de-facto oznacza, w jakim środowisku dany moduł powinien zostać załadowany. Domenę ładuje się następująco:


var applicationDomain:ApplicationDomain = ...;

-----------------------------------------------------

var moduleInfo : IModuleInfo;
moduleInfo = ModuleManager.getModule(_url);
moduleInfo.load(applicationDomain);

-----------------------------------------------

var loader : ModuleLoader = new ModuleLoader();
loader.url = "SomeModule.swf";
contentPanel.addChild(loader, applicationDomain);

Pod zmienną applicationDomain z przykładu można podstawić 3 (w zasadzie 4) wartości. Pierwsza (domyślna) to wartość:


var applicationDomain:ApplicationDomain = new ApplicationDomain(ApplicationDomain.currentDomain);

lub

var applicationDomain:ApplicationDomain = null;

Tego typu zapis oznacza, że moduł jest modułem dzieckiem. Do rodzica można dostać się poprzez ApplicationDomain.parrentDomain. Niestety, jest to tylko teoria. Obie domeny co prawda są odseparowane, ale jeżeli korzystamy w naszej aplikacji z singletonów, to będą się one zachowywać na dwa sposoby. Albo będą modułowe, albo aplikacyjne. Jeżeli singleton nie został zainicjalizowany w aplikacji (a wystarczy tylko wspomnienie takie jak var sig:SomeSingleton = null), to jego zasięg będzie dotyczył tylko modułu (nawet, jeżeli występuje w innych modułach). Natomiast, jeżeli został zainicjalizowany w aplikacji, to będzie to singleton aplikacyjny. Przypomnę, że w moim wypadku nie miałem dostępu do kodu aplikacji, a więc nie byłem w stanie sprawdzić, czy singleton którego używam, był użyty w aplikacji.
Samo to nie jest jeszcze straszne, ale są dalsze konsekwencje. Może wystąpić sytuacja, w której sigleton dynamicznie powołuje do instnienia obiekty klas (po nazwie klasy). Takie zachowanie ma na przykład SchemaTypeRegistry.getInstance().registerClass(...) używane do rejestrowania klas dla WebService. Nagle pojawia się Error #1065, oznaczający, że nie można załadować klasy, ponieważ nie została ona dołączona do skompilowanego kodu. Dokładnie rzecz ujmując ApplicationDomain znajdujący się w aplikacji (w przypadku singletona aplikacyjnego) próbuje powołać do życia obiekt, dla którego klasa znana jest tylko w ApplicationDomain modułu. Osobiści podejrzewam, że jest to jakiś błąd w flexie, ale jak szukałem informacji na temat, to przekrój czasowy w jakim można znaleźć posty na ten temat jest imponujący (2005-2010). Nawet Flex 4 posiada bardzo podobnie wyglądający błąd.

Jak pisałem, są jeszcze 2 warianty przypisania AppliacationDomain:


var applicationDomain:ApplicationDomain = new ApplicationDomain();

oraz

var applicationDomain:ApplicationDomain = ApplicationDomain.curentDomain;

Pierwszy sposób tworzy całkowicie odrębną domenę aplikacji. Osobiście tematu nie zbadałem, ale to co mogę powiedzieć, to to, że aplikacja nie chciała mi się uruchomić z modułem, musiałem zmienić moduł na aplikację, żeby osiągnąć jakikolwiek efekt.

Ostatni sposób, tworzy wspólną domenę dla modułu oraz aplikacji. Takie podejście powoduje, że nagle klasy których mi brakowało, znajdują się w tej samej domenie co aplikacja. Oznacza to, że mój problem przestaje istnieć, jednak warto wspomnieć, że nie ma również separacji modułu i aplikacji.

Więcej informacji można znaleźć w tych artykułach:
http://livedocs.adobe.com/flex/3/loading_applications.pdf
http://livedocs.adobe.com/flex/3/html/help.html?content=modular_5.html
http://life.neophi.com/danielr/2006/07/flex_2_runtime_error_1065.html

Jak uwalić projekt - Epilog

2010-09-16T01:29:00.001-07:00

Ponieważ minęło trochę czasu, postanowiłem napisać obiecany epilog do poprzedniej historii.

Firma odkryła, że jest jakiś problem i zatrudniała Audytora. Audytor zajął się oglądaniem jak są prowadzone projekty, głównie na poziomie zarządzania. Audyt zajął około miesiąca i obejmował głównie rozmowy z project managerami i dyrektorem technicznym. Po miesiącu Audytor został nowym dyrektorem technicznym, natomiast dyrektor techniczny został architektem systemu (który przecież trwa już od ponad roku).
Projekt w tym czasie spokojnie sam posuwał się do przodu. Kierownictwo było zajęte głównie roszadami oraz przygotowywaniem papierków, negocjacjami z klientem oraz audytorem/nowym dyrektorem. Oznacza to, że tak na prawdę, nikt nie kontrolował jak idą prace. Co prawda programiści są kompetentni, więc tyle ile mogą robią, ale mimo wszystko kompletny brak kontroli jest nieco niepokojący.

W między czasie, zaczeło wychodzić (przynajmniej w gronie programistów), że nowi programiści (zdalni) w zasadzie niewiele wnoszą do projektu, a dodatkowo poświeca się im sporo czasu. Mimo to, zawsze można jeszcze pod-zlecić innej firmie część prac. O ile osobiście uważam, że jest to całkiem niezły pomysł, to w sytuacji w której dokumentacja jest na poziomie niskim (nie zgodnym z założeniami, nie dokładnym, nie aktualnym, itd.), nie da się ani dobrze oszacować czasu, ani nie da się po prostu pod-zlecić. Trzeba dodatkowo dać kogoś, w zasadzie na pełen etat kto będzie wyjaśniał wątpliwości. Mimo to, pod-zlecanie stało się nowym motto firmy. Żeby było lepiej, to zawsze można wziąć firmę po znajomości (a nie koniecznie po kwalifikacjach jej pracowników).

Miesiąc po objęciu stanowiska przez nowego dyrektora zaczęły się ruchy w poszukiwaniu czasu programistów. Pojawiły się duże znaki zapytania odnośnie urlopów oraz prośby zaplanowania go na później jeżeli tylko się da. Pojwaiły się również spotkania personalne z dyrektorem w zakresie: Co robisz, ile ci to jeszcze zajmie, kiedy planujesz urlop i jak ma on się do tego co masz zaplanowane do zrobienia. Mam jednak wrażenie, że mimo dobrych chęci, nie wnosiły one niczego w projekt. Oczywiście część programistów zajmowała się tylko komunikacją z zleceniobiorcami (w tym programistami zewnętrznymi) więc nie zajmowali się programowaniem. Co interesujące, dzięki temu ruchowi, prace spowolniły tempo.

Mniejwięcej w tamtym okresie sprawy przybrały jeszcze gorszy obrót, bo okazało się, że dwóch najbardziej doświadczonych programistów stwierdziło, że odchodzi. Ponieważ jeden miał na głowie bezpieczeństwo aplikacji a drugi silnik, to rozpoczęto działania w celu przekazania zadań związanych z silnikiem. Przekazanie bezpieczeństwa zostawiono na 2 ostatnie dni pracy. W końcu ten autorski rozbudowany system spełniający masę wymagań (często na wyrost) na pewno łatwo można przekazać...

Mniejwięcej w tamtym okresie okazało się również, że firma oficjalnie zawiesza projekt, ze względu na brak umówionej płatności ze strony klienta. W zasadzie, można by przyjąć, że to już był koniec projektu. Oczywiście firma planowała jeszcze wywiązać się ze zobowiązań kontynuując projekt wewnętrznie, ale oficjalnie projekt był zawieszony.
Klient oczywiście chciał, żeby projekt był kontynuowany, ale z punktu widzenia firmy, lepsza była ścieżka sądowa.

Na tym etapie rozpoczęto również zrywanie umów z podwykonawcami (czyli po około miesiącu).

Stan: Realizacja projektu w miarę obiektywnie 75% (ale pewne problemy nie zostały w ogóle podjęte), wg firmy 90 - 95%. Oficjalnie zawieszony.
Zespół: 3 programistów 2 osoby od kontaktów.
[EDIT] Zgodnie z komentarzem. Brak testów obciążeniowych, a funkcjonalność ta co jest, przetestowana pobieżnie, przez testerów którzy nie znają się na pisaniu testów i programowaniu (czytaj: Osoby które przeklikają aplikację).

Ta zupełnie teoretyczna historia mogła się wydarzyć na prawdę. Takich firm w Polsce jest wiele. Nie każdy, mimo tego, że potrafi wykonać mały produkt, powinien brać się za realizację dużych projektów. Dodatkowo, warto jednak zatrudnić specjalistów, w dziedzinach które dla dużych projektów są istotne, takich jak analitycy, architekci, specjaliści z danych dziedzin. Małe projekty nie wymagają tak silnego zaplecza. Można je realizować znacznie luźniej, uzupełniając pewne elementy w biegu. W przypadku dużych projektów, błędy w architekturze, dokumentacji, zarządzaniu kosztują firmy na prawdę duże pieniądze.

PS. Pozdrowienia dla tych, którzy jednak czytają tego bloga :)

Problem z 59Hz

2010-05-06T00:19:00.000-07:00

Od 3 lat posiadam dobry moniotr LCD. Do tej pory nie było z nim problemów.. aż do czasu. Zmieniłem komputer, a ponieważ musiałem oszczędzić na karcie graficznej to kupiłem najtańszą, ale taką która obsłuży rozdzielczość 1900x1200. Niestety okazało się to nie wystarczające. Co prawda karta obsługuje tą rozdzielczość, ale okazuje się, że pod Windows 7 (i z tego co czytałem również w Vista) są dość ciekawe sterowniki dla monitorów.

Windows źle rozpoznaje częstotliwość podawaną przez monitor. Część monitorów LCD pracuje w częstotliwości 59.94. Niestety Windows nie rozpoznaje ich jaką tą częstotliwość tylko 59Hz. O ile dla zwykłego monitora nie stanowi to problemu, o tyle dla LCD powoduje brak synchronizacji. Dla złącz DVI powoduje brak ekranu (lub jego pojawianie się i znikanie (na przykład 1s jest.. 10s nie ma), dla złącza VGA powoduje migotanie lub pasy na ekranie.

Problem jest taki, że na liście obsługiwanych częstotliwości mam 59 i 60Hz, ale nigdy nie można ustawić 60Hz (które jest prawidłowe), ponieważ monitor zgłasza że obsługuje 59.94 (a więc nie 60).

Microsoft temat zamknął określając że wszystko jest w porządku (http://support.microsoft.com/kb/2006076).

Rozwiązania:

Zmiana karty graficznej - Tak wiem... teoretycznie problem z monitorem, ale w praktyce monitor już wcześniej pracował prawidłowo z moim Laptopem, a po zmianie karty graficznej problem zniknął. (Poprzednia karta jest w porządku, z monitorem kineskopowym działa ok)
Powerstrip - program pozwala na dość mocne sterowanie kartą graficzną (w tym częstotliwościami dla monitora)
Można próbować definiować własne rozdzielczości, ale u mnie nie zdało to egzaminu.

Jak uwalić projekt informatyczny za grube pieniądze

2010-04-28T09:35:00.000-07:00

Na usta cisną mi się tylko słowa Grega Zorby "Jaka piękna katastrofa" , ale wybiegam odrobinę w przyszłość.

Postanowiłem się podzielić z szerszą publiką moimi przemyśleniami na temat zarządzania projektami informatycznymi, a przede wszystkim, jak nie powinno się prowadzić projektu. Ponieważ obowiązuje mnie tajemnica, będę się starał unikać szczegółów, a pewne fakty mogą zostać przeze mnie zmienione.

Uczestniczę obecnie w projekcie który do małych nie należy a jego wartość wyceniona została na sumę, której w LOTTO z reguły wygrać się nie da. Projekt zawiera bardzo wiele powiązanych ze sobą systemów, zaczynając od CRM poprzez CMS, GIS, oraz zarządzanie bazą danych (w tym graficzną jej reprezentację) z poziomu GUI. Aplikacja pozwala na pracę w przeważającej części za pomocą przeglądarki. Z samego zakresu technologii, jak również jego wartości jasno wynika, że projekt do małych nie należy. Jak na projekt tej wielkości przystało, projekt jest zarządzany zgodnie z jedną z bardziej popularnych metodyk (jednak tylko na styku z klientem). Czas realizacji: około 1,5 roku + utrzymanie.

A teraz prosty przepis, jak taki projekt uwalić:
Na początek mamy podpisanie umowy, w ramach której obiecujemy klientowi gruszki na wierzbie. Przy czym, klient sam nie do końca wie co mu jest potrzebne, więc wymaga jak najwięcej się da. Nie ma przy tym sensu sprawdzenie, czy wymagania w ogóle mają sens, lub czy się wzajemnie nie wykluczają. Klient w końcu nigdy w życiu nie dał by sprzecznych ze sobą wytycznych, nawet jeżeli jest kilkanaście osób które ze strony klienta mogą decydować i wspólnie podejmować decyzje. Dodatkowo, ponieważ klient wymaga wstępnego projektu, można wziąć projekt innego systemu i trochę przystosować. Ponad dwustu tabel w dokumentacji bazy danych i tak nikt nie będzie czytał. W zasadzie, jak się głębiej nad tym zastanowić. To te tabele można żywcem wziąć, po co to przystosowywać, dopisać tylko do tego jakąś otoczkę.

Kolejnym krokiem jest zebranie wymagań. Ten krok można w zasadzie pominąć, bo przecież wymagania zostały już w zasadzie zebrane w ramach umowy, a tylko doprecyzować jak to w zasadzie ma być w ramach analizy.

A więc przystępujemy do analizy. Oczywiste jest, że w tej fazie, osoby zbierające wymagania nie muszą mieć ani doświadczenia, ani śladowego wykształcenia informatycznego. W końcu system który będzie wykonywany można zaplanować całkowicie w oderwaniu od sprzętu czy oprogramowania. Jeżeli przypadkiem okazuje się, że nie można do końca zebrać wymagań, to należy w dokumentacji wpisać jakieś ogólniki - uzupełni się w ramach projektu technicznego. Ponieważ zespól zbierający te informacje nie musi być duży, w zasadzie wystarczy 5 osób, to może się okazać, że będzie problem z dotrzymaniem terminów. Na szczęście, klient wymaga więcej, niż było podpisane w umowie, w związku z czym można podpisać aneks do analizy. Osób co prawda więcej nie będzie, ale zawsze można dłużej pisać. Klient niestety jest cwańszy, bo co prawda zgadza się na przesunięcie terminu oddania analizy (z aneksem), ale nie pozwala na przesunięcie terminu oddania projektu technicznego, którego realizacja ma być wykonana w terminie, a co najwyżej zostanie uzupełniony później o aneks. W ten oto sposób, aneks zostaje ze sporymi bólami oddany w terminie, co wypada w połowie czasu przewidzianego na oddanie projektu technicznego.

Stan:
Połowa czasu przewidzianego na projekt techniczny.
Analiza - po łepkach, nie kompletna a miejscami sprzeczna.
Aneks do analizy - tak samo
Projekt Techniczny -brak

A więc teraz można przystąpić do realizacji projektu technicznego. Najlepiej jak go zrobi jedna osoba techniczna. Osoba techniczna, to zresztą odrobinę nadużycie semantyczne. w/w osoba, to programista, z 3,5 letnim doświadczeniem, nawet dość szerokim, ale twierdzący, że jego najsłabszą stroną są bazy danych. A więc najlepiej będzie, jeżeli to właśnie ta osoba zaprojektuje bazę danych. Jednak, aby trochę życie ułatwić część bazy danych już jest gotowa i nie należy jej dotykać. Wynika to z faktu, że są gotowe narzędzie wypełniające tą bazę. Co prawda nikt tak na prawdę nie wie jakie to narzędzia, w jakim języku są napisane ani czy ta struktura która jest to właśnie z tych narzędzi, ale są. Oczywiście programista kompletnie nie jest wprowadzony w tematykę GIS, na której całość aplikacji się opiera. Wszystkie osoby które mają jakiekolwiek pojęcie są oczywiście zajęte pisaniem aneksu do analizy, a programista ma wytyczne "zrób projekt techniczny, tam jest analiza". W razie pytań dostaje odpowiedź "wszystko jest w analizie", co oczywiście załatwia sprawę. Po zakończeniu aneksu do analizy (przypominam w połowie trwania projektu technicznego), okazuje się, że w sumie nie wiadomo dlaczego, ale projekt techniczny jest w lesie, klient dodatkowo poza modelem danych wymaga jeszcze projektu interfejsów oraz przypadków użycia, a dodatkowo to co jest, nie jest zgodne z aneksem do analizy, który przecież już od 3 dni leży w repozytorium. Programista zostaje należycie opieprzony za jego niekompetencję a wiec sprawa jest załatwiona. Wprawiony team od analizy siada i wspólnymi siłami oraz posiłkując się dokumentacją z poprzedniego projektu generuje setki stron dokumentów technicznych. Co prawda są pewne zgrzyty, bo okazuje się, że chyba jednak nie wszystko jest w analizie, główny standard wymiany danych jest nie dopracowany (mimo, że zatwierdzony przez klienta). W związku z tym pewne elementy nie zostają doprecyzowane. Ponieważ termin realizacji projektu technicznego stoi pod wielkim znakiem zapytania atmosfera jest bardzo nieprzyjemna i napięta, ale praca wre.
Wreszcie następuje przełom. Okazuje się, że klient zgodził się na rozszerzenie. Oznacza to, że mamy 1,5 miesiąca więcej na wykonanie projektu technicznego. Co prawda klient wymaga teraz trochę więcej i w ramach rozszerzenia przemyca pewne funkcjonalności, ale mimo to są szanse się wyrobić, szczególnie, że projekt interfejsów i przypadki użycia są w powijakach. Jest jednak mały haczyk, polegający na tym, że równolegle należy rozpocząć już implementację, bo projekt techniczny do rozszerzenia idzie jakby torem obok.

To jest dobry moment na rozpoczęcie rekrutacji zespołu który ten projekt zrealizuje. A więc na dobry początek należy stwierdzić ile osób potrzeba. Ponieważ mamy kupę czasu (i nie są znane pełne wymagania), programista szacuje, że potrzeba około 6 osób od zaraz, do samej części CRM, CMS aby projekt zrealizować, około 5 do GIS. Oczywiście programista nie wie co mówi, ale rekrutacja się rozpoczyna. Po dwóch miesiącach rekrutacji są w zespole programistycznym już 3 osoby (w tym programista, który cały czas zajmuje się projektem technicznym). Od tego momentu, programista staje się team leaderem, ponieważ jest osobą techniczną która ma najbardziej całościowy pogląd na cały projekt (i jedyną która ma jakikolwiek pogląd od strony technicznej).

A więc po 2 miesiącach stan jest taki, że zostaje wykonany szkielet aplikacji oraz wypracowane zostają standardy kodowania w wybranych (nowych) technologiach. Warto nadmienić, że cały zespół części technologii uczy się od zera. W końcu jak by przynajmniej jedna osoba znała technologię....

Myślę, że to jest moment, w którym możemy określić, że tak na prawdę (z 2 miesięcznym opóźnieniem) rozpoczęła się faza implementacji.
Status:
2 miesiące do tyłu
3 osoby w zespole (zamiast 6).
0 osób w zespole GIS (zamiast 5).
Projekt techniczny bazujący na kulawej analizie wykonany przez zbyt małą grupę ludzi nie mających o tym zielonego pojęcia. - Sumarycznie 1,5 tyś stron.
Projekty Interfejsów taki, że każdy interfejs nie jest powiązany z żadnym innym (i nie przystaje do technologii).
Przypadki Użycia w dużej części nie są powiązane z interfejsami a dodatkowo część z nich jest pozostałością z innego systemu.

Ponownie zostaje zadane pytanie ile osób potrzeba - odpowiedź - na dzień dzisiejszy 7 w samym zespole do CRM, CMS. Na zapotrzebowanie do innych zespołów nie ma odpowiedzi, ponieważ prace nie są jeszcze na ten moment zaplanowane. Miesiąc później zespół liczy już 5 osób. Liczba ta utrzymuje się przez kolejne miesiące. Kierownictwo ma coraz większe zastrzeżenia do opóźnień i wielokrotnie stara się otrzymać od zespołu informację kiedy nadgonią opóźnienia. Warto nadmienić, że żadne nadgodziny, a przynajmniej płatne nie wchodzą w grę.

Mijają 3 miesiące i okazuje się, że jednak opóźnienia zamiast maleć rosną. Winny jest team leader który nie potrafi doprowadzić do zmniejszenia opóźnienia. Drań jeden dodatkowo próbuje się bronić, mówiąc, że od początku mówił, że potrzeba 7 osób a nie 5. W zespole od GIS również nie dzieje się dobrze. Zespół nie dość, że jest między dwoma projektami, to jeszcze wredny team leader zespołu GIS postanowił odejść z pracy. Coś mówił o burdelu w zarządzaniu, wymagał jakiś procedur i nie pozwalał na to, żeby jednej osobie zlecało pracę 5 osób w ciągu jednego dnia, ale szefostwo wie, że i tak tylko wprowadzał niepotrzebny zamęt w projekcie i w sumie lepiej że go nie będzie.

Mijają 2 tygodnie. Klient zaczyna się niepokoić stanem prac i twierdzi, że jak prace nie zostaną nadgonione, to będzie trzeba wprowadzić plan naprawczy. Zarząd, a za nim kierownictwo projektu nie zgadzają się jednak na to, żeby już wprowadzać plan naprawczy, w związku z czym zespół dostaje polecenie zrobić tak, żeby następna prezentacja aplikacji przeszła bez problemów. Team leader informuje kierownictwo, że jedyną możliwością aby to zrobić, to będzie zrobienie kompletnej wydmuszki (mockupu), już nie tak jak do tej pory, że jest masa błędów, ale generalnie jest, tylko całkowitej wydmuszki. Propozycja zostaje przyjęta.

Mijają 3 tygodnie. Udało się. Klient jest zadowolony ze zwiększonych postępów pracy. Co prawda w czasie prezentacji następuje spora awaria bazy danych więc nie wszystkie funkcjonalności można pokazać, ale ogólnie prezentacja kończy się sukcesem. Co prawda programiści zostają przedstawieni jako banda niekompetentnych... (oszczędzę sobie szczegółów), ale prezentacja przeszła dobrze.

Z bliżej nie określonych powodów w następnym tygodniu prace jakoś nie idą za szybko.

Są decyzje. Teraz już nie ukrywamy problemów. Można zacząć naprawiać błędy.

Minął kolejny miesiąc. Prace co prawda nie postępują, ale aplikacja zaczyna powoli działać. Zaczynają się co prawda problemy z określeniem postępów prac. Tym razem przy wyznaczaniu harmonogramu prac nikt już się nie konsultuje z team leaderem, bo w końcu tak spieprzył poprzedni harmonogram prac, że nie ma to sensu. Aby zapewnić pełną kontrolę nad źle zarządzanym projektem, tematem zajmuje się od tej pory project manager. Co prawda team leader niby nadal jest team leaderem, ale wszelkie podziały prac i decyzje są dokonywane poza nim.

2 tygodnie później, po ostrej awanturze za powolne wykonywanie obowiązków programisty, team leader (teraz już 7 osobowego zespołu) rezygnuje ze swojego stanowiska. Nikt inny nie zostaje wyznaczony do tej (nikomu nie potrzebnej) roli.

Stan na dzień:
-2 miesiące względem pierwotnego harmonogramu.
- +0 miesięcy względem harmonogramu z planu naprawczego (przy czym wg. starego team leadera już pierwszy miesiąc jest niewykonalny, ale jego nikt o zdanie nie pyta)
-7 osoób w zespole, z czego 2 osoby mają pracować zdalnie
- brak team leadera
- brak nałożonych kar ze strony klienta (ale są już odpowiednie zapisy odnośnie planu naprawczego)

C.D.N.

Zaznaczanie kawałka tekstu w dla pola input=text

2009-07-15T05:05:00.000-07:00

O ile problem nie jest specjalnie nowy, o tyle znalezienie rozwiązania stanowiło dla mnie spore wyzwanie. W pierwszym momencie uznałem nawet, że javascript po prostu nie daje takich możliwości. Dopiero gdy postanowiłem znaleźć jak się ustawia kursor w dowolnym miejscu pola input, okazało się, że zaznaczanie tekstu również jest dość proste. Oto rozwiązanie:


if (input.createTextRange) {
    var range = input.createTextRange();
    range.collapse(true);
    range.moveEnd('character', selectionEnd);
    range.moveStart('character', selectionStart);
    range.select();
  }
  else if (input.setSelectionRange) {
    input.focus();
    input.setSelectionRange(selectionStart, selectionEnd);
  }
}

Rozwiązanie zaczerpnięte ze strony http://faqts.com/knowledge_base/view.phtml/aid/13562

Piractwo komputerowe

2009-06-29T01:51:00.000-07:00

W ostatnim czasie pojawiło się sporo aresztowań związanych z piractwem. Ofiarami tego procederu są głównie studenci, chociaż nie tylko. Ponieważ jest to blog dotyczący programowania, postanowiłem przedstawić swój punkt widzenia związany z piractwem.

Tak na prawdę, mamy kilka grup pozyskujących oprogramowanie:

Osoby które pobierają oprogramowanie nielegalnie, i nie zrobiły by inaczej.
Osoby które pobierają oprogramowanie nielegalnie, bo tak jest prościej.
Osoby które pobierają oprogramowanie nielegalnie, bo nie stać ich aby pozyskać je inaczej.
Osoby które kupują oprogramowanie, bo nie potrafiły złamać zabezpieczeń
Osoby które kupują oprogramowanie, bo uważają, że twórca powinien dostać wynagrodzenie za swój trud.

W zasadzie nie popieram piractwa. Mówię w zasadzie, ponieważ mój punkt widzenia jest uzależniony od tego, o której grupie mówię.

Jeżeli mówimy o grupie pierwszej, do której należą osoby które celowo pobierają oprogramowanie, łamią zabezpieczenia i na przykład sprzedają je dalej, tak aby osiągnąć z tego powodu korzyści, to uważam, że jest to postępowanie karygodne i należy je tępić.

Jeżeli mówimy o osobach wygodnych, to jest to kwestia złej polityki firm wydających oprogramowanie. Nie mówię tutaj o zaostrzeniu polityki bezpieczeństwa, tylko o złych zasadach udostępniania oprogramowania. Jeżeli ktoś z tej grupy ma możliwość pobrania za darmo oprogramowania z ograniczoną funkcjonalnością, to istnieje duża szansa, że takie oprogramowanie pobierze. Dodatkowo, jeżeli w przyszłości będzie potrzebował pełnej funkcjonalności, to istnieje duża szansa, że to oprogramowanie zakupi.

W przypadku osób których nie stać, to są to osoby, które i tak by nie zakupiły naszego oprogramowania i ściganie ich, tak na prawdę nic nie zmienia, a dodatkowo psuje wizerunek naszej firmie. Co komu zawinił biedny student, że się nasyła na niego policję i ze sporym prawdopodobieństwem rujnuje dalsze życie? Ten student i tak by oprogramowania nie zakupił, a co za tym idzie, nie poniesiemy żadnej straty z tytułu tego, że pobierze on nasze oprogramowanie. Warto przygotować dla takiego rynku specjalną ofertę, ale tak na prawdę ściganie mija się z celem.

Dla nie potrafiących złamać zabezpieczenia. Cóż, podstawowe zabezpieczenia w aplikacji warto stosować, właśnie ze względu na tą grupę. Natomiast bardziej zaawansowane algorytmy mijają się z celem. Zastosowanie bardziej skomplikowanych algorytmów spowoduje tylko większe zainteresowanie hakerów pragnących wyzwań, i w ten sposób powstanie w miarę łatwo dostępny crack do naszych zabezpieczeń. Po co dawać takie wyzwanie? Lepsza jest dobra polityka licencyjna dająca dostęp do produktu, nawet jeżeli z biznesowego punktu widzenia nie koniecznie ma to sens.

Dla pozostałej grupy należą się podziękowania za uczciwość. Dzięki tej grupie zarówno biznes oprogramowania jak i muzyczno-filmowy nadal może się rozwijać.

Do tego wszystkiego dochodzi jeszcze kwestia samych zabezpieczeń, które osiągnęły poziom, przy którym wgrywa się cracka tylko po to, żeby łatwiej się korzystało z produktu. Mam kilku znajomych, którzy kupują oryginalne oprogramowanie, a następnie wgrywają cracki, bo na przykład nie chce im się za każdym razem jak chcą pograć w grę, szukać płyty.

Myślę że swój punkt widzenia przedstawiłem. Jestem przeciwny piractwu, ale jestem jednocześnie przeciwny idiotycznym politykom licencyjnym oraz ściganiem ludzi którzy nigdy nie nabyli i nie mogli nabyć danego oprogramowania.

Hibernate, dziwne zachowanie InheritanceType.SINGLE_TABLE

2009-05-18T04:53:00.000-07:00

Dziś trafiłem na bardzo ciekawy problem. Korzystałem z obiektów, z dziedziczeniem oraz mapowaniem z wykorzystaniem pojedyńczej tabeli. Tego typu rozwiązanie ma tą zaletę, że jest szybkie, oraz tą wadę, że potrzeba trochę więcej miejsca w bazie. Dla mnie to drugie nie było problemem w tej konkretnej sytuacji, a ponieważ zależało mi na szybkości, to ta metoda na pozór wyglądała bardzo ciekawie.

W skrócie moje klasy wyglądały tak:


@Entity
@Inheritance(strategy=InheritanceType.SINGLE_TABLE)
@DiscriminatorValue("PLAYER_SHORT_INFO")
public class PlayerShortInfo implements IsSerializable {

    @Id @GeneratedValue
    @Column(name = "ID", unique = true, nullable = false)
    private long id;
[...]
}

@Entity
@DiscriminatorValue("PLAYER_INFO")
@PrimaryKeyJoinColumn(name="ID")
public class PlayerInfo extends PlayerShortInfo implements IsSerializable {
@ManyToOne(optional = false, cascade = {CascadeType.REFRESH, CascadeType.PERSIST}, fetch = FetchType.EAGER)
PlayerType type;
[...]
}

Nigdy nie tworzyłem obiektów klasy PlayerShortInfo.Dziedziczneie było zrobione głownie dla ograniczenie ilości danych przesylanych klientowi, gdy potrzebuje tylko danych skróconych (ale na przykład nie dla jednego obiektu, a dla 100). Takie rozwiązanie wydało mi sie proste i wydajne. Niestety, dziś okazało sie inaczej.

Klasa PlayerInfo, jest klasa która nigdy nie jest przekazywana do warstwy WEB. Jest wykorzystywana tylko w logice biznesowej, a wiec nawet nie było potrzeby, aby implementowała IsSerializable (wymagane przez GWT). W czasie testów, wyszło jednak, ze GWT nie może przetransportować listy zawierającej PlayerShortInfo ponieważ PlayerType (!!!) nie implementuje IsSerializable. Po sprawdzeniu, okazało sie, ze zeczywiscie nie implementuje, tylko ze PlayerType nigdy nie miał być przesyłany do warstwy WEB.

Po dłuższych poszukiwaniach, okazało sie ze SELECT: (List)em.createQuery("select d from PlayerShortInfo d order by id").getResultList(); zwraca listę nie PlayerShortInfo ale PlayerInfo

Wnioski:
InheritanceType.SINGLE_TABLE jest nieco mylące. Obiektem ładowanym z bazy jest zawsze obiekt który został zapisany, nawet jeżeli w Select jest jasno podane ze chcemy załadować obiekt wyższego rzędu. Co sie dzieje, jest wykonywane załadowanie obiektu który został zapisany a następnie rzutowanie go na element docelowy. Sprawa jest bardziej skomplikowana, bo jeżeli dziecko jest obiektem ciężkim, to pomimo ze chcemy załadować lekkiego rodzica, załadowany zostanie ciężki obiekt dziecka, razem ze wszystkimi atrybutami które ono posiada (na przykład listami innych obiektów).

Rozwiązanie:
Moim zdaniem nie ma dobrego rozwiązania. Trzeba być świadomym problemu i stosować takie rozwiązania w swojej aplikacji, aby nie było potrzeby stosowania tego rodzaju dziedziczenia.

Duża ilość elementów w GWT

2009-05-11T02:22:00.001-07:00

GWT generalnie jest fajną platformą, ale niestety sam javascript nie jest najszybszy. Okazuje się, że dodanie dużej ilości elementów załadowanych z bazy i wstawienie ich do tabeli stanowi spory problem. Na przykład, ładując 500 elementów i wstawiając je do FlexTable albo do Grid, strona ładuje się dość długo, szczególnie na słabszych komputerach. Ponieważ zależało mi na szybkości ładowania elementów, postanowiłem temat zbadać i spróbować coś z nim zrobić.

Zarówno Grid jak i FlexTable, a w zasadzie również VerticalPanel oraz HorizontalPanel są oparte o tablice. Tablica jako taka jest elementem dość skomplikowanym w budowie, a dodatkowo GWT dodaje dość dużo kodu sprawdzającego, warunkowego oraz debugu. Cały ten kod powoduje, że Całość działa o wiele wolniej.

Ponieważ efekt zbliżony do tabeli można osiągnąć również przy pomocy arkusza styli CSS oraz zwykłych div, postanwoiłem spróbować przerobić standardową tabelę na pseudotabelę zrobioną przy pomocy DIV z flow:left; GWT posiada kilka elementów które mi na to pozwalają. Pierwszy z nich to FlowPanel który jest tłumaczony na DIV i pozwala na dodanie innych komponentów do środka. Drugi to Label, SimplePanel oraz Hyperlink pozwalające na dodanie innych elementów.

Są dwie zasady jeżeli chcemy osiągnąć efekt właściwy.

Wszystkie elementy muszą mieć na stałe ustawioną wysokośc oraz szerokość
Sumaryczna szerokość elemtnów wewnątrz "tabeli" musi być równa szerokości "tabeli"

Wygenerowany kod będzie wyglądał tak:



<div style="width:200px;display:block;">
   <div style="float:left;width:100px;height:20px;">Nazwa 1</div>
   <div style="float:left;width:100px;height:20px;">Wartosc 1</div>
   <div style="float:left;width:100px;height:20px;">Nazwa 2</div>
   <div style="float:left;width:100px;height:20px;">Wartosc 2</div>
</div>

Efekt wyglada tak:

Nazwa 1

Wartosc 1

Nazwa 2

Wartosc 2

Z wygladu mamy tabele, a wiec to o co chodzi.

To samo mozna osiagnac w GWT, tylko style nalezy przeniesc do arkusza styli.


FlowPanel content = new FlowPanel();
Label l1 = new Label("Nazwa 1");
Label w1 = new Label("Wartosc 1");
Label l2 = new Label("Nazwa 2");
Label w2 = new Label("Wartosc 2");

content.setStyleName("table_main");
l1.setStyleName("table_field");
l2.setStyleName("table_field");
w1.setStyleName("table_field");
w2.setStyleName("table_field");

content.add(l1);
content.add(l2);
content.add(w1);
content.add(w2);

initWidget(content);

STYLE:

.table_main{
width:200px;
display:block;
}

.table_field{
float:left;
width:100px;
height:20px;
}

Ponieważ FlowPanel nie wymaga dużo sprawdzeń i inicjalizacji to jego utworzenie jest bardzo proste. Dodanie kolejnych elementów nie wymaga tworzenia struktury drzewa, tak jak w przypadku kontenerów opartych o tablice. Dzięki temu, ilość kodu javascript który musi zostać wykonany jest dużo mniejsza, a co za tym idzie jest mocno zauważalny wzrost wydajności tego rozwiązania w stosunku do standardowej tabeli.
Wada tego rozwiązania jest taka, że jednak nie jest to standardowa tabela, a co za tym idzie, nie ma możliwości skalowania tabeli. Na szczęście w większości dzisiejszych layoutów wielkości są zablokowane na stałe, a więc ten problem dotyczy niewielkiej ilości przypadków.

PS. Nie mieżyłem wzrostu wydajności, ale wzrost wydajności był zauważalny bez mieżenia. Strona oparta o tabele ładowała się wolno. Strona oparta o to rozwiązanie ładowała się w zasadzie odrazu.

Richfaces VS Icefaces

2009-04-21T03:35:00.000-07:00

Ten artykuł był w sumie jednym z pierwszych które chciałem napisać. Było to spowodowane dylematem który miałem podczas wyboru technologii webowej do następnej aplikacji. W tamtym okresie miałem już doświadczenia z IceFaces i nie byłem do końca przekonany do tej właśnie technologii, natomiast brakowało mi doświadczeń z RichFaces, a był to framework który zapowiadał się bardzo ciekawie. Niestety, nie udało mi się znaleźć na sieci dobrego porównania tych technologii, w związku z tym postanowiłem napisać ten artykuł.

Ogółem

W ogólnym zarysie obie technologie wyglądają podobnie. Posiadają dokładnie to samo zastosowanie, podobny zakres komponentów oraz oparte są na technologii JSF. Można zauważyć pewne drobne różnice jeżeli idzie o dostępne komponenty, ale posiadają podobną ilość. Osobiście odniosłem jednak wrażenie, że IceFaces ma komponenty jednak troche lepiej dobrane i kompletne, podczas gdy w RichFaces są one odrobinę bardziej surowe, ale tak na prawdę jest to raczej subiektywne odczucie. Na podstawie pobieżnego obejrzenia nie byłem w stanie jednak jednoznacznie wybrać bądź odrzucić żadnej z technologii.

Instalacja

Instalacja IceFaces nie należała do najprzyjemniejszych. Co prawda mówię o wersji 1.6, a więc mogło się to zmienić, nie mniej taką właśnie wersję instalowałem. O ile praca odbywała się na serwerze WebLogic problemów nie było. Wszystko działało tak jak trzeba. Niestety na etapie instalacji na JBoss (4.2.2) instalacja nawet przykładowej aplikacji nie była możliwa do wykonania. IceFaces zawiera wbudowaną wersję JSF. Jest to również prawda w przypadku serwera JBoss. Jak można się łatwo domyślić wersje te nie były zgodne i nie chciały ze sobą współpracować. Po wielu próbach rozwiązania problemu, włącznie z postami na forum IceFaces z prośbą o pomoc poddałem się. Dwa miesiące później na forum pojawiły się jakieś pomysły rozwiązań, ale jeżeli mam być szczery, to było to obejście problemu (na poziomie serwera) a nie jego rozwiązanie.

Instalacja RichFaces była stosunkowo prosta. Jedyne co dodatkowo musiałem zrobić, to zainstalować implementacje JSF, ponieważ sam framework był dostarczony bez. Po zainstalowaniu wszystko działało zarówno na serwerze JBoss jak i na WebLogic.

Ajax

Największą zaletą obu frameworków jest obsługa AJAX. Oba podchodzą do problemu trochę inaczej. W przypadku IceFaces Ajax jest wbudowany w komponenty i w zasadzie przezroczysty dla użytkownika. Kontrola nad nim sprowadza sie do kilku ustawień w web.xml oraz parametrach w komponentach. W przypadku RichFaces Ajax jest bardzo widoczny. Jest to rozwiązane za pomocą całej serii dodatkowych komponentów (framework Ajax 4 Java (a4j)). Ten dodatkowy framework jest odpowiedzialny za całą komunikację z serwerem. Niestety oznacza to również, że programista musi napisać dodatkowy kod aby ajax działał w przeciwieństwie do IceFaces, gdzie proces zachodzi automatycznie. Wykorzystanie tego dodatkowego frameworku pozwala jednak na wykorzystanie standardowych komponentów JSF i dodanie do nich obsługi AJAX bez konieczności zastępowania ich. Takie podejście sprawia, że można w łatwy sposób dodać obsługę AJAX do już istniejącej aplikacji. Oba frameworki prezentują również troche inne podejście do odświeżania stanu aplikacji. Oba pozwalają na odpytywanie w celu sprawdzenia czy są nowe dane. Jednak, jeżeli idzie o push, to rozwiązanie zastosowane w obu frameworkach jest nieco inne. W przypadku IceFaces połączenie jest inicjowane ze strony serwera. W przypadku gdy pojawią się jakieś dane, serwer (który utrzymuje cały czas połączenie) wysyła do klienta nowe dane. W przypadku RichFaces klient co jakiś czas odpytuje serwera czy są jakieś dane. Jeżeli serwer przygotował jakąś paczkę danych, to jest ona pobierana. Warto wspomnieć, że RichFaces nie utrzymuje stałego połączenia z serwerem w przeciwieństwie do IceFaces. Osobiście miałem sporo problemów z tym utrzymywanym połączeniem. IceFaces zakładało, że sieć jest idealna, i takie połączenie nie zostanie zerwane. W przypadku zerwania aplikacja nie zachowywała się dobrze. Miało to zostać naprawione w późniejszych wersjach (i jest duża szansa, że obecnie problem już nie występuje).

Problemy

W przypadku obu frameworków natrafiłem na kilka problemów.

IceFaces
Ponieważ sprawa dotyczy starej wersji frameworku myślę, że nie ma sensu opisywać konkretnych problemów z samym frameworkiem, natomiast postaram się oddać zakres problemów z jakim się spotkałem. Po pierwsze były problemy z konkretnymi komponentami, ale były to raczej niewielkie problemy i były raczej uciążliwe, niż uniemożliwiające prace. Rozwiązanie problemów albo było w repozytorium kodu, albo było planowane do wypuszczenia z następną wersją. Niestety problem na który natrafiłem ja był planowany z następną wersją. Mówię niestety, bo o ile po zmianie wersji problem zniknął, o tyle pojawił się inny dużo poważniejszy w komponencie który wcześniej działał prawidłowo. Sama zmiana wersji (z wersji 1.5.x na 1.6) nie przebiegała w sposób prosty i bezproblemowy. Ponieważ zostało zmienione całkowicie nazewnictwo klas w stylach aplikacja straciła cały wygląd. Wymagało to ręcznej zmiany wszystkich styli na docelowe. W wersji 1.6.1 dodane zostało narzędzie do automatycznej migracji styli, ale niestety było to już dłuższy czas po tym, jak style zostały dostosowane. Może to tylko moje odczucia, ale bardzo mi się nie podobało taki załatwienie sprawy.
Dodanie własnego komponentu pracującego razem z AJAX wymagało sporo wysiłku ze strony programisty. Wszelkie niestandardowe rozwiązania, nie przewidziane przez programistów tworzących Framework były dość trudne do zaimplementowania, ponieważ sam framework stanowi dość zamkniętą całość.
Community jest dość rozbudowane i często chętne do pomocy, ale jednak na odpowiedź trzeba trochę poczekać, szczególnie jeżeli problem jest bardziej złożony.
Dokumentacja do projektu jest dość dobra, jest sporo przykładów.

RichFaces
Problemy z samym frameworkiem były podobne do tych z IceFaces. Pojedyńcze elementy nie do końca dobrze funkcjonowały, natomiast znalezienie rozwiązania było znacznie łatwiejsze. Główne problemy natomiast, były nieco innej natury. Do IceFaces można było znaleźć pokaźną ilość przykładów czy HOWTO. Z RichFaces już nie było tak lekko. Ilość przykładów dostarczonych z aplikacją była bardzo skąpa a przykładowy kod demonstrowany w Component Showcase przeklejony żywcem nie zawsze działał. Po analizie kodu źródłowego okazywało się, że źródłowy zawarty na stronie nie posiadał paru elementów koniecznych do działania elementu do którego się odwoływał. Dojście do tego jak dany komponent działał, wymagało przejrzenia kodu źródłowego samej aplikacji demonstracyjnej. Community jest również znacznie mniejsze i trudniej jest uzyskać pomoc w przypadku problemów.

Podsumowanie

Oba frameworki są oprogramowaniem dobrym i stanowią ciekawą ofertę. RichFaces jest napisany tak, że pozwala na zaimplementowanie bardziej specyficznych rozwiązań dużo niższym kosztem, bo kod jest tak pomyślany, że dodanie obsługi Ajax jest proste a same komponenty w większości są standardową implementacją JSF (Sun lub MyFaces). Niestety, to samo rozwiązanie powoduje, że ta dodatkowa kontrola wymaga pisania dodatkowego kodu, a więc dla aplikacji która nie stosuje niestandardowych rozwiązań i liczy się czas, IceFaces jest dużo lepszym rozwiązaniem. Dodatkowo IceFaces jest znacznie lepszy jeżeli idzie o poznanie samego frameworku. Dokumentacja, dobre i duże community sprawia ze ten framework zdobywa coraz większe uznanie. Ja osobiście jednak bardziej polubiłem RichFaces. Miałem z nim znacznie mniej problemów a jednocześnie daje mi dużo większą kontrolę nad tym co się dzieje w aplikacji, co mi osobiście bardzo odpowiada. W przypadku IceFaces czas który został zaoszczędzony na dodatkowym kodzie, został wykorzystany na pisanie łatek do niedziałającego kodu samego frameworku, lub poprawianie nowych problemów po wgraniu kolejnej wersji poprawiającej inne błędy.

Jeżeli miał bym wybierać framework oparty o JSF do następnego projektu to skłaniał bym się bardziej w kierunku RichFaces, jako bardziej dopracowanego i dającego większą swobodę.

GWT oraz Session Beans

2009-04-15T02:06:00.000-07:00

Uwaga do tego artykułu.

Kod zawarty w tym wpisie w części nie jest kodem napisanym przezemnie. Sam pomysł został zaczerpnięty z grup googlowych, ja postanowiłem, że pomysł jest na tyle ciekawy, że warto go przedstawić.

Standardowo GWT nie jest zawarte w transakcji. Ten stan raczej nie jest do końca wygodny, szczególnie jeżeli odbywa się jakieś przetwarzanie po stronie serwera. Standardowa struktura aplikacji jest następująca

Klient (przeglądarka)
Serwer (GWT)
Serwer (EJB) (logika biznesowa)
DB

Oczywiście ta struktura może być różna, w zależności od aplikacji, ale generalnie wygląda podobnie. Problem polega na tym, że na poziomie Server(GWT) dane nie są objęte transakcjami. Okazuje się jednak, że przy pomocy stosunkowo prostego zabiegu da się tą warstwę całkowicie pominąć.

Standardowo aplikacja GWT wymaga zdefiniowania 2 interfejsów oraz ich implementacji. Interfejsy są zrobione standardowo

Service:


public interface SmapleService extends RemoteService {
  // Sample interface method of remote interface
  String getMessage(String msg);

  /**
   * Utility/Convenience class.
   * Use SmapleService.App.getInstance () to access static instance of SmapleServiceAsync
   */
  public static class App {
      private static SmapleServiceAsync app = null;

      public static synchronized SmapleServiceAsync getInstance() {
          if (app == null) {
              app = (SmapleServiceAsync) GWT.create(SmapleService.class);
              ((ServiceDefTarget) app).setServiceEntryPoint(GWT.getModuleBaseURL() +
                                       "smaple.Smaple/SmapleService");
          }
          return app;
      }
  }
}

ServiceAsync:


public interface SmapleServiceAsync {
  void getMessage(String msg, AsyncCallback async);
}

Standardowa implementacja wygląda tak:

 
public class SmapleServiceImpl 
       extends RemoteServiceServlet 
       implements SmapleService {
  // Implementation of sample interface method
  public String getMessage(String msg) {
      return "Client said: \"" + msg + "\"
Server answered: \"Hi!\"";
  }
}

Ten kod niestety nie pozwala na transakcyjność. Wystarczy jednak zrobić kilka niewielkich zmian. Po pierwsze klasa SampleServiceImpl nie powinna implementować interfejsu SampleService. Po drugie, należy przeciążyć metodę processCall odpowiedzialną za obsługę przychodzących wywołąń tak, aby wywoływała metody z SSB.


public class SampleServiceImpl 
       extends RemoteServiceServlet {
  private static final Logger log = Logger.getLogger(SampleServiceImpl.class);

  public String processCall(String payload) throws SerializationException {
      try {
          Object bean = getBean();
          synchronized (bean) {
              RPCRequest rpcRequest = RPC.decodeRequest(payload, bean.getClass());
              log.debug("RPC METHOD CALL: " + 
                        rpcRequest.getMethod() + 
                        " PARAMETERS: " + 
                        Arrays.toString(rpcRequest.getParameters()));
              return RPC.invokeAndEncodeResponse(bean, rpcRequest.getMethod(),
                      rpcRequest.getParameters());
          }

      } catch (IncompatibleRemoteServiceException ex) {
          ex.printStackTrace();
          return RPC.encodeResponseForFailure(null, ex);
      } catch (NamingException ne) {
          ne.printStackTrace();
          return RPC.encodeResponseForFailure(null, ne);
      }
  }

  public ISampleBeanService getBean() throws NamingException {
      final HttpSession httpSession = getThreadLocalRequest().getSession();
      ISampleService bean = (ISampleBeanService) httpSession.getAttribute("SampleBeanService");

      if (bean != null) try {
          // Call a method to test whether the bean is still live; 
          // if it's dead, we'll re-create it
          synchronized (bean) {
              bean.isAlive();
              log.debug("Bean alive");
          }
      } catch (NoSuchEJBException ex) {
          log.debug("Bean dead");
          bean = null;
          httpSession.removeAttribute("SampleBeanService");
      }

      if (bean == null) {
          InitialContext ic = new InitialContext();
          Object objRef = ic.lookup("sample/SampleBeanService/local");
          bean = (ISampleBeanService) PortableRemoteObject.narrow(objRef,
                                      ISampleBeanService.class);
          httpSession.setAttribute("SampleBeanService", bean);
      }

      return bean;
  }

Warto zwrocic uwage, ze nie zgadzaja sie nazwy interfejsow. Bean korzysta z interfejsu ISampleBeanService podczas gdy GWT korzysta z SampleService. To nie jest błąd.


public interface ISampleBeanService extends SampleService {
  public boolean isAlive();
}

Ten interfejs jest pomocniczy implementuje tylko metodę isAlive(), wykorzystywaną do sprawdzenia czy SSB zostało stworzone, oraz czy jest nadal dostępne.

Aby całość działała brakuje już tylko samego SSB:


@Stateless(name = "SampleBeanService")
@Local(ISampleBeanService.class)
public class SampleService implements ISampleBeanService {
  // Implementation of sample interface method
  public String getMessage(String msg) {
      return "Client said: \"" + msg + "\"
Server answered: \"Hi!\"";
  }
  public boolean isAlive() {
      return true;
  }

}

Bean jak widać jest standardowym beanem. Nie wymaga niczego nadzwyczajnego.

Napotkałem na dwa problemy przy implementacji tego rozwiązania.

Problem z sesją. Na dobrą sprawę, jeżeli użyjemy tego rozwiązania pojawia się problem z przechowywaniem danych. Standardowo w GWT dane wrzucane są do sesji HTTP. Niestety w przypadku Statless bean z założenia dane nie są w nim trzymane, a z poziomu SSB nie ma dostępu do Sesji HTTP. Rozwiązaniem jakie się w sumie samo nasuwa są Statefull Session Bean, które w zasadzie właśnie do tego celu były przewidziane.
Problem z kompilacją modułów (w Idei). Chodzi o zależności między modułami. W tym przypadku SSB musi być w module WEB, a to nie jest dobre rozwiązanie. Na szczęście znalazłem inne rozwiązanie, które zostało opisane w osobnym wpisie w tym blogu.

Wykorzystanie obiektów z warstw niższych w warstwie WEB GWT.

2009-03-25T08:54:00.000-07:00

Jednym z problemów jaki miałem w korzystaniu z GWT było wykorzzystanie tych samych obiektów na poziomie warstwy logiki biznesowej, czy DAO oraz na poziomie warstwy WEB. Teoretycznie są to obiekty POJO, więc problemów być nie powinno, jednak wymaganie, z drugiej strony ich deklaracje znajdują się w module web (a więc w większości przypadków w plikach war).
Okazuje się jednak, że tak być nie musi. Klasy muszą się znajdować w katalogu GWT (w ktatlogu client) w czasie kompilacji kodu GWT, ale później można je przenieść w dowolne miejsce w aplikacji.

Muszą zostać jednak spełnione dwa warunki:

Pakiet w którym znajduje się klasa musi być nadal ten sam.
Moduł web musi mieć dostęp do skompilowanych źródeł.

W związku z tym struktura, w której całość działała w mojej aplikacji wyglądała tak:

EAR

dao.jar
business.jar
web.war
META-INF

WAR

images
css
WEB-INF
WEB-INF -> lib -> web.jar
META-INF
[...].js
[...].html

Co istotne, obiekty zawarte były w dao.jar a nie w web.jar.

Oczywiście tego typu struktura wymaga aby biblioteka GWT była importowana w module DAO (ze względu na interfejs IsSerializable), ale jest to niewielkie poświęcenie za możliwość korzystania z tych samych obiektów w module GWT oraz w modulach biznesowych. Dzięki takiemu rozwiązaniu mogę załadować obiekt, na przykład przy pomocy JPA z bazy a następnie przekazać go bezpośrednio do warstwy webowej.

Kompilacja
Całość została przezemnie zautomatyzowana przy pomocy skryptów antowych.
Standardowo obiekty są umieszczone w module DAO.
Przed kompilacją Obiekty są przenszone do modułu GWT.


       <move todir="dao/src/pl/project/client/objects">
           <fileset dir="webui/src/pl/project/client/objects"/>
       </move>

Ant, kompiluje moduł GWT przy pomocy taska antowego dostępnego w bibliotece ant-gwt.


       <taskdef resource="dk/contix/ant/gwt/ant-gwt.xml" 
                classpathref="project.classpath"/>
       <gwtcompile destdir="${build.dir}/gwt-web" optimize="true">
           <fileset dir="${module.web.basedir}/web/src">
               <include name="**/*.gwt.xml"/>
           </fileset>
       </gwtcompile>

Przenosze spowrotem obiekty do DAO


       <move todir="web/src/pl/project/client/objects">
           <fileset dir="dao/src/pl/project/client/objects"/>
       </move>

Kompiluje pozostałe elementy a następnie składam tworze pliki JAR, WAR oraz EAR

Warto wspomnieć, że GWT nie miało problemów z anotacjami.

Następnym razem napisze jak wymusić na GWT aby wywoływało bezpośrednio Beana EJB (na przyklad Stateless Session Bean), dzięki czemu wszystkie operacje wykonywane są wewnątrz transakcji.

Obsługa wyjątków w GWT

2009-03-23T13:36:00.000-07:00

Sprawa jest stosunkowo prosta od momentu gdy powstało GWT 1.5. Mechanizm RPC zastosowany w GWT pozwala na przekazywanie wyjątków powstałych w warstwach niższych, jednak te wyjątki muszą spełniać pewne warunki.

Wyjątek musi dziedziczyć po Throwable (a więc na przykład Exception). Musi implementować java.io.Serializable oraz co najważniejsze musi implementować com.google.gwt.user.client.rpc.IsSerializable. Ta ostatnia klasa jest wymagana dla przekazywania wszelkich obiektów poprzez RPC, a więc dotyczy to również wyjątków.

Wyjątek jest przechwytywany w metodzie public void onFailure(Throwable caught) i zawarty jest w zmiennej caught. Dalszą obsługę wyjątku możemy robić już w standardowy sposób.

Przykładowy kod:

Klasa błędu


import com.google.gwt.user.client.rpc.IsSerializable;
import java.io.Serializable;

public class MyException extends Exception
                       implements Serializable, IsSerializable {
String name = getClass().getName();

public String getName() {
return name;
}
}

Obsługa błedu


MyAppService.App.getInstance().method(new AsyncCallback<Void>() {
public void onFailure(Throwable caught) {
  if (caught instanceof MyException)
    handleException((MyException)caught);
  else
    handleUnknownException(caught);
}

public void onSuccess(Void result) {
  [...]
}
});

Deklaracja metody w MyAppAsync


public interface MyAppAsync(){
void method(AsyncCallback<Void> async);
}

Niestety to rozwiązanie posiada dwa poważne problemy.
Po pierwsze pozwala na przesłanie tylko własnych klas błędów.
Po drugie wymaga aby klasa błędu była w pakiecie client w module zawierającym kod GWT. Oznacza to poważny problem w zależnościach między modułami.

Rozwiązanie drugiego problemu w skrócie:
Jest możliwa kompilacja modułu GWT przy pomocy kompilatora GWT (do postaci javascript), a następnie kompilacja źródeł z innym modułem. To może być na przykład moduł trzymający wszystkie obiekty. Istotne jest tylko, aby moduł GWT posiadał dostęp do tej skompilowanej klasy oraz klasa znajdowała się w odpowiednim pakiecie.

Ten konkretny problem postaram się opisać szerzej następnym razem.

Wstęp

2009-03-23T13:14:00.000-07:00

Postanowiłem stworzyć tego bloga, aby podzielić się z szerszym gronem moimi frustracjami oraz spostrzeżeniami. Może ktoś, dzięki moim spostrzeżeniom w przyszłości uniknie błędów, z którymi ja się spotkałem.