niedziela, 30 stycznia 2011

XI Spotkanie SJUG - Wrażenia

Sława!
W ostatni czwartek stycznia odbyło się już 11. spotkanie szczecińskiej jugi. Tym razem na zaproszeniu widniała dumna myśl przewodnia - „Wprowadzenie do Google App Engine (Java API) na przykładzie Google Web Toolkit”. Tym razem zabrakło mi czasu i chęci zainteresować się wcześniej czym w ogóle jest to Google App Engine więc oczekiwania miałem spore...

wtorek, 11 stycznia 2011

Łubudubne osadzanie SQL Developer

Sława!
Niedawnymi czasy mus miałem zainstalować Oracle SQL Developer pod miętowym systemem pigwinkowym, który akurat bazuje na Ubuntu. Na moje szczęście, ponieważ instalacja „ręczna” w tych systemach nigdy mi specjalnie się nie podobała (a szkoda?), znalazłem sposób na instalację z „pakietu”.
Sposób ten znalazłem na blogu Marcina Izdebskiego, gdzie serdecznie odsyłam. Od siebie dodam, że operacja bazująca na wyżej wymienionym koncepcie poszła sprawnie, aczkolwiek nie wiem za bardzo dlaczego utworzony skrót dla menu aplikacji nie działa w mintMenu (aczkolwiek działa z Kupfera czy ze standardowego menu Gnome)... Cóż, może się dowiem tego od któregoś z PT Czytelników...

niedziela, 19 grudnia 2010

Mikołajowych moc prezentów

Sława!
Grudzień nadszedł. Rok chyli się ku końcowi, a niebo śniegiem sypnęło z rękawa, to i Mikołaj gorszy być nie chciał kilka prezentów niespodzianie przed Wigilią nam podrzucił. 
Pierwszym z nich o którym słów parę wspomnę to nowa, jubileuszowa, dziesiąta wersja IntelliJ Idea. Twórcy chwalą się szeregiem nowych możliwości, niestety, trochę wstyd przyznać, nadal nie wykorzystuję szeregu możliwości tego IDE, więc w całkiem sporej mierze muszę wierzyć na słowo, że jest lepiej ;) Na moje dość krótkie doznania z obcowania jednak śmiem stwierdzić, że nowa wersja istotnie sprawia wrażenie sprawniejszej, więc chyba przynajmniej nowy mechanizm indeksowania istotnie działa szybciej. W każdym razie jakoś się do Idei przyzwyczaiłem i pracuje mnie się w niej sympatycznie.

niedziela, 21 listopada 2010

Siećkierowcy tempomatu ustawianie

Sława!
Ostatnimi czasy zajęć wszelakich namnożyło mi się niczym zajęcy na wiosnę, więc i dzienniczek zaniedbany troszeczkę został. Na szczęście Jego, Szanownych Czytelników oraz osoby autora skromnej jedno z nich sposobność do wpisu świeżego uczyniło. Otóż okazji w tym okresie szalonym do obcowania ze świeżymi wersjami rozwojowymi Selenium 2 i WebDriver mam, aż za nadto. A oseski te, jak to oseski cierpią katusze chorób okresu dziecięcego w ilościach, że niejedna orda Tatarzynów Dzikie Pola pustosząca drobną hulajpartią się wydawać może.

wtorek, 2 listopada 2010

Impresji pojubileuszowych garść parę...

Sława!
W ostatni czwartek października odbyło się jubileuszowe, dziesiąte już spotkanie Szczecińskiej JUGi, na którym toż to i sługa Waszmościów uniżony zaszczyt miał się pojawić. Po prawdzie i szczerością przepełnion, stwierdzić muszę, iż rozpisywać o wrażeniach specjalnej potrzeby nie odczuwam antycypując, że Imć Darkowi starczyłoby gromkie „Było Git!”. Los jednak chce inaczej, a skoro słowo się rzekło, to i kobyłka u płota być musi. Obiecałem parę słów krytyki, to przyzwoitość nakazuje się wywiązać. Niestety. ;)
Zacznę więc od zastrzeżenia, że jakikolwiek obraz wrażeń mych skrzywiony wyjdzie, to niech Szanowni Czytelnicy przyjmą łaskawie do wiadomości, że podobało mi się. Naprawdę. Jak bum cyk cyk!
No to teraz ognia Rufusie!

piątek, 15 października 2010

Jubileuszowe X spotkanie Szczecińskiej JUGi

Sława!
Wakacje minęły i oto niczym feniks z popiołu, spotkanie Szczecińskiej JUGi postanowiło wstać z kocyka, otrzepać się z piasku i szerokim gestem zaprosić Nas do siebie. Tym razem powody do radosnej i niczym nieskrępowanej krytyki po swojej prezentacji, w ostatni październikowy czwartek, zamierza dać nam Darek „Lock” Łuksza. O dziwo, nie będzie (wreszcie?) o testowaniu, tylko słów parę o projekcie EGit w którym to się rączo On udziela. Tak więc nie zostaje mi nic innego niż postraszyć Darka, że się zjawię, a Szanownych Czytelników równie gorąco zachęcić do współudziału.
Do zobaczenia w sali 128 WIPS (ZUT), 28.X.2010 o godzinie 18:00

wtorek, 10 sierpnia 2010

Bzycząco pozorowane obiektów wspaniałości.

Sława!
Tak to przypadkiem zupełnym ostatnimi czasy potrzeba mnie naszła napisania paru testów jednostkowych. Ponieważ nieszczęścia parami chadzać lubują, to do potrzeby tej doszła potrzeba upozorowywania obiektów, a że afektem darzę w tym celu podbudowę Mockito, to nie zastanawiając się Mockito w dłoń, hajda na koń, Baśkę uwolnić od zbója! Uwalnianie idzie gładko, Tatarzyn umyka, że kurz wstrzymuje ruch lotniczy na połowie kontynentu, to lecim na Szczecin bez zagrychy. Aż tu nagle jak mi NullPointerException z siurpryzy między oczy nie przydzwoni, aż się moje testy nogami nakryły.
 - O Ty! W ząbek czesany figlarzu! Ładnie to tak zza węgla bez uprzedzenia po zębach przygarowywać? - mu wygarniam, a ten nic, tylko szczerzy się jak głupi do sera i repetę zasuwa. Ale nie takie cwaniaki z nami pogrywać próbowały, czyż nie proszę Szanowego Państwa? Trzeba wziąć ino sprawę rozumowo, a nie sercowem uczuciem. Takoż więc należy się urwipołciowi dokładnie przykapować i detalicznie inspekt przedstawić. Kod mój niniejszym się przedstawia:
ClassImplentingIface ciff = Mockito.mock(ClassImplentingIface.class);

Mockito.when(ciff.doSomething(3)).thenReturn("ReturnedValue");

assert "ReturnedValue" == ciff.doSomething(3);
Gdzie ClassImplementingIface jest klasą w języku groovy, a objawiony wyjątek to:
java.lang.NullPointerException at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:39) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:40) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:117) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125) at com.blogspot.pacykarz.Testowa.test(Testowa.groovy:19)
Jak widać wyjątek rzuca się już przy konfiguracji stworzonego pozoranta, a śledztwo szczegółowsze wykazuje, iż próba wywołania jakiejkolwiek metody na nim skutkuje podobnym wyjątkiem. Dogłębniejsze rzucenie wzroku narządem i winnego mamy! Otóż jest nim, jakże zacny i szanowany skądinąd, mechanizm mopowania, którego metody w tej sytuacji też są pozorowane przez Mockito i stąd cały ten ambaras. Jak więc wyjść z twarzą i po honorowemu z zajścia?
Sposób pierwszy i niezawodny, to pozorować zamiast klasy jej interfejs(y). Szparko wszystko zaiwania wygalantowanie, że tylko pozazdrościć. Pozazdrościć jeżeli pozorowana klasa nie implementuje interfejsu, który możemy wykorzystać. Co wtedy? Wtedy niestety są ograniczenia i dwudziesty stopień zasilania. Pochylmy się znów nad egzamplą:
//This working always:
Iface mockedIface = Mockito.mock(Iface.class);
Mockito.when(mockedIface.doSomething(Mockito.anyInt())).thenReturn("ReturnedValue");

assert "ReturnedValue" == mockedIface.doSomething(3);
Mockito.verify(mockedIface, Mockito.times(1)).doSomething(Mockito.anyInt());

//This not working with matchers
ClassNotImplentingIface mockedClass = Mockito.mock(ClassNotImplentingIface.class, Mockito.withSettings().extraInterfaces(GroovyInterceptable));

Mockito.when(mockedClass.doSomething(3)).thenReturn("ReturnedValue");

assert "ReturnedValue" == mockedClass.doSomething(3);
Mockito.verify(mockedClass, Mockito.times(1)).doSomething(3);

//This also not working with matchers, but also returns wrong verifications.
ClassNotImplentingIface spiedClass = Mockito.spy(new ClassNotImplentingIface());

Mockito.when(spiedClass.doSomething(3)).thenReturn("ReturnedValue");

assert "ReturnedValue" == spiedClass.doSomething(3);

//Be aware of given 4 times invocation instead of 1!
Mockito.verify(spiedClass, Mockito.times(4)).doSomething(3);

//This also not working with matchers and returns wrong verifications.
ClassNotImplentingIface mockedClass2 = Mockito.mock(ClassNotImplentingIface.class, new Answer() {
  Object answer(InvocationOnMock invocationOnMock) {
      if (invocationOnMock.getMethod().getName() ==~ /.*get.*MetaClass/) {
          return invocationOnMock.callRealMethod();
      } else {
         return null; /* or other default answer*/
      }
  }
});

Mockito.when(mockedClass2.doSomething(3)).thenReturn("ReturnedValue");

assert "ReturnedValue" == mockedClass2.doSomething(3);

//Be aware of given 4 times invocation instead of 1!
Mockito.verify(mockedClass2, Mockito.times(4)).doSomething(3);
Pierwszym obejściem jest dodanie do pozoranta interfejsu GroovyInterceptable, jeżeli możemy sobie na to pozwolić. Istnieje wtedy duże prawdopodobieństwo, że kod testowy będzie działać, z jednym szkopułem. Nie jest możliwe niestety używanie odpowiedników (matcher) z Hamcrest/Mockito, gdyż przy próbie ich użycia, dobrze nam znajomy NPE podstawia hakiem nogie i to tak dyskretnie, że dostajemy dość mylący komunikat o mieszaniu odpowiedników z surowymi typami.
Obejście drugie polega na szpiegowaniu obiektu. Niestety w tym wypadku nie dość, że również nie możemy skorzystać z odpowiedników, to do tego dostajemy wyniki weryfikacji zwiększone o pewien narzut z mopowania, czego mus być świadomym.
Obejście trzecie zaś to użycie przy tworzeniu pozoranta domyślnej odpowiedzi (np. w sytuacji gdy żaden z powyższych konceptów niemożliwy jest do zastosowania). Podobnie jak w drugim, tutaj także brużdżą odpowiedniki i wyniki weryfikacji, a cały myk zaś polega na obsłużeniu wszystkich żądań o metaklasy przez realną, a nie pozorowaną metodę klasy. Kto wie, może nawet mykiem tym dałoby się obsłużyć zastosowanie odpowiedników? Nie upieram się przy stwierdzeniu, że się nie da.
Ostatnim na dziś, czwartym sposobem, bardzo możliwe, że często może być najrozumniejszym, jest użycie innej podbudowy pozoranckiej dedykowanej dla grówiego, np. GMock czy inszego MockFor.