Monthly Archives: September 2009

I po próżności – wyniki konkursu

Czas leci, a ja jakoś nie zauważyłem, iż konkurs w którym mój blog brał udział zakończył się ponad tydzień temu, a ja zapomniałem o tym napisać.

Jak widać na stronie konkursu zająłem drugie miejsce. Bardzo mi z tej okazji miło i w tym miejscu chciałbym podziękować wszystkim głosującym. Dobrze jest mieć poczucie, iż to co się robi znajduje uznanie w oczach innych. Jeszcze raz Wszystkim dziękuję.

Advertisements

Thinking in Java

thija4

Ostatnimi czasy odnoszę wrażenie, że ilość dyskusji typu “Czy uczyć się Javy, a jeśli tak to z czego?” jakby wzrosła. Do tego w każdej z nich co i rusz wspomina się o książce Bruce’a Eckela . Jednakże mam wrażenie, że jakoś żaden z dyskutantów nie zwraca uwagi na podstawową cechę tej książki – nie jest ona przeznaczona dla początkujących!

Przyznam szczerze, że sam uległem temu przekonaniu, gdyż Thinking in Java była moją pierwszą książką o Javie. Je też lubię posiadać cegłę, która zdaje się skrywać odpowiedzi na wszystkie pytania, którą można też podprzeć regał kiedy się przekrzywi 🙂

Problem polega na tym, iż Java sama z siebie jest językiem, w którym próg wejścia jest o niebo wyższy, niż w przypadku choćby języków skryptowych (choć może powinienem powiedzieć, iż dotyczy to bardziej JEE). W PHP, na którym się trochę znam, wystarczy zainstalować WAMPa ( jedna paczka instalacyjna, domyślne ustawienia ), stworzyć plik index.php oraz wpisać przysłowiowe:

echo "dupa";

I viola – “Mamo, tato, umiem programować!”. W przypadku Javy (rozwiązań webowych) bez solidnego IDE i kreatora projektów zajmie to naprawdę sporo czasu. I tutaj tkwi problem – w porównaniu do wspomnianego PHP po przejściu 200-300 stron z książki Eckela wiemy, że gdzieś dzwoni, ale nie do końca w którym to kościele. Natomiast po 300 stronach książki o “PHP&MySQL&Apache&CSS&JS” można na szybko stworzyć znośną stronę, którą można pokazać klasie w szkole, czy wrzucić jako stronkę produktu na aukcji Allegro.

Eckel o tym doskonale wie i nie próbuje iść pod prąd. Poza samym Swingiem, Flexem oraz bodajże SWT nie porusza zagadnień dodatkowych frameworków czy bibliotek. Pozostaje w cichym i ciepłym bagienku Javy SE i nie chce niczego więcej ( choćby bajeranckiego interfejsu we Flexie). I tutaj właśnie tkwi siła tej książki! Siła, którą odkryłem podczas przygotowań do SCJP – czytanie kolejnych rozdziałów z interesujących mnie tematów było wręcz… zabawą? Kiedy osiągnie się pewien poziom znajomości języka Thinking in Java zaczyna nabierać o wiele większego uroku – przestaje być opasłą knigą pełną kodu pisanego drobnym druczkiem, ale składnicą wiedzy, do której każdy powinien zaglądać. Taką biblią dla programisty – może nie trzeba jej czytać codziennie – jednakże dobrze przejrzeć od czasu do czasu. Zwłaszcza kiedy się czegoś nie wie.

Strony błędów w JSF i co z tego wynikło

Jak pisałem w poprzednim wpisie – na poważnie rozpocząłem deployment aplikacji napisanej w JSF na serwerze hostingowym. Siłą rzeczy powiedzenia programistów “u mnie działa” nie wzięły się znikąd – fakt – u mnie działa, na serwerze już jednak niekoniecznie.

Ostatnio link do mojego bloga pojawia się w masie miejsc. Wzrost ilości odwiedzin jest łatwo widoczny – stąd też nie wszyscy mogą być świadomi, iż do tej pory nie miałem większych problemów z hostowaniem swojej aplikacji napisanej w GrailsHowToJava. Jednakże dorzucenie na serwer kolejnego programistycznego projektu – ProgramBash zaowocowało pewnymi komplikacjami, które zajęły mnie przez ostatnie dni.

Pierwsza rzecz warta wzmianki to fakt, iż oszalał mi NetBeans. Moja sprawdzona wersja 6.5.1 zaczęła w pewnym momencie (pomimo braku zmian w kodzie) wyrzucać przy deploymencie na lokalnym Tomcacie wyjątek o niemożliwości dostania się do elementów layoutu w katalogu WEB-INF i wpadała w kaskadę wyjątków, która skutecznie zabierała 100% procesora i trzeba było zabijać proces IDE i serwera. Z konieczności zatem zdecydowałem się na zmiany, które zaowocowały instalacją wersji 6.7.1 – na razie działa stabilnie, oby tak dalej.

Pisałem również wcześniej, iż w tym projekcie użyję Postgresa. Jednakże zanim doczekam się go na serwerze pewnie jeszcze trochę minie – zatem z konieczności development toczy się na starym dobrym MySQL. I nie byłoby w tym nic strasznego gdyby nie fakt, iż o ile HowToJava pięknie sobie z bazą radzi, o tyle ProgramBash zaczął “wysiadać”. Konkretnie aplikacja wyrzucała wyjątki mówiące o zakończeniu połączenia.

Wyruszyłem na mały research. Uzbrojony w nowe IDE mogłem zabrać się za rozwiązywanie problemu, który dość często uniemożliwiał spojrzenie na aplikację, gdyż dostawało się komunikat błędu. Zapuściłem się w otchłań internetu z wujkiem Google i oto co się okazało – Hibernate standardowo musi zostać stuningowany, aby nadawał się do celów produkcyjnych (szkoda tylko, że moja mądra książka o Hibernate jakoś o tym nie wspomina). Oto urywek z dokumentacji:

Hibernate’s own connection pooling algorithm is, however, quite rudimentary. It is intended to help you get started and is not intended for use in a production system, or even for performance testing. You should use a third party pool for best performance and stability.

No dobra, zatem trzeba pomyśleć co z tym fantem zrobić. Ano okazuje się, że należy zainteresować się dostarczanym wraz z Hibernate pakietem/biblioteką o nazwie C3P0. Nadpisuje ona domyślne ustawienia connection pools i umożliwia zabawę na bardziej wymyślnym placu zabaw. Zatem do naszego pliku hibernate.cfg.xml należy dorzucić następujący fragment kodu:

    <property name="hibernate.c3p0.min_size">5</property>
    <property name="hibernate.c3p0.max_size">20</property>
    <property name="hibernate.c3p0.timeout">300</property>
    <property name="hibernate.c3p0.max_statements">50</property>
    <property name="hibernate.c3p0.idle_test_period">3000</property>
    <property name="current_session_context_class">thread</property> 

I w ten sposób problemy z niestabilnością połączenia rozwiązują się w mgnieniu oka. Hibernate ponoć tę bibliotekę posiada – jednakże w wersji dostarczanej przez NetBeans jakoś jej nie podpięto. Zatem trzeba dodać kolejnego JARa do naszych bibliotek w aplikacji.

Deployment i działa. Póki co 🙂 Jednakże wraz z wyrzucaniem błędów w połączeniu naszła mnie myśl o zmianie wyświetlanej strony błędów. Wszak wyrzucenie StackTrace użytkownikowi końcowemu nie jest raczej zachowaniem pożądanym. Rzecz jasna wziąłem się za poprawę tego stanu rzeczy.

Sprawa wydawała się prosta. Obsługę błędów w JSF można rozwiązać na dwa sposoby. Albo dodać stosowne dyrektywy do strony widoku (dobre chyba w rozwiązaniach typu HelloWorld), albo też zadeklarować rzecz w deskryptorze wdrożenia. Oto jak wygląda plik web.xml po utworzeniu projektu w JSF:

 <error-page>
        <exception-type>javax.faces.FacesException</exception-type>
         <location>/servlet/ExceptionHandlerServlet</location>
    </error-page>

    <error-page>
        <exception-type>javax.servlet.ServletException</exception-type>
        <location>/servlet/ExceptionHandlerServlet</location>
    </error-page>
    <error-page>
        <exception-type>java.io.IOException</exception-type>
        <location>/servlet/ExceptionHandlerServlet</location>
    </error-page>
    
    <error-page>
        <exception-type>com.sun.rave.web.ui.appbase.ApplicationException</exception-type>
        <location>/servlet/ExceptionHandlerServlet</location>
    </error-page>

    <servlet-mapping>
        <servlet-name>ExceptionHandlerServlet</servlet-name>
        <url-pattern>/error/ExceptionHandler</url-pattern>
    </servlet-mapping>

   <servlet>
        <servlet-name>ExceptionHandlerServlet</servlet-name>
        <servlet-class>com.sun.errorhandler.ExceptionHandler</servlet-class>
              <init-param>
            <param-name>errorHost</param-name>
            <param-value>localhost</param-value>
        </init-param>
        <init-param>
            <param-name>errorPort</param-name>
            <param-value>24444</param-value>
        </init-param>
    </servlet>

I w tym momencie wszystkie błędy są obsługiwane przez standardowe widoki JSF. By zmienić ten stan rzeczy najprościej jest po prostu utworzyć stronę widoku (HTML, JSP) i podlinkować do niej obsługę błędów poprzez odpowiednie nadanie wartości parametru location. Powinno to wyglądać zatem tak:

<error-page>
        <exception-type>com.sun.rave.web.ui.appbase.ApplicationException</exception-type>
        <location>/error.html</location>
    </error-page>

I w ten sposób wyszczególniony wyjątek będzie obsługiwany przez naszą stronę. Najlepiej jest zdefiniować jedną stronę błędów, a pod nią podpiąć wszystkie błędy. Najlepiej zatem tak:

<error-page>
        <exception-type>java.lang.Throwable</exception-type>
        <location>/error.html</location>
    </error-page>

I życie od razu staje się przyjemniejsze. Istnieje też druga wersja – można wyszczególnić kod błędu (konkretnie kodów HTTP). Czyli by ładnie obsłużyć stronę 404 (nie znaleziono zasobu) można zrobić coś takiego:

<error-page>
        <error-code>404</error-code>
        <location>/error404.html</location>
    </error-page>

I w taki oto sposób ProgramBash przybliżył się do działającej aplikacji. Mam nadzieję, że w przyszłym wpisie zajmę się już czymś bardziej konkretnym – wstępnie myślę o rejestracji i logowaniu. Na otarcie łez można rzucić okiem na użycie RichFaces klikając na link O AUTORZE.

Deploymentów ciąg dalszy

Postanowiłem uporządkować trochę wszystkie tematy związane z napisanymi do tej pory aplikacjami oraz hostingiem. Istniejąca do tej pory domena chlebik.pl wskazywała na ostatni skończony projekt czyli HowToJava. Dziś uległo to zmianie.

Pod wyżej wymienionym adresem można znaleźć skromną stronkę z linkami do istniejących projektów (w tym bloga oraz klienta do gry w arkę). Dzięki temu domena służy zbieraniu wszystkiego w jednym miejscu, zaś konkretne aplikacje (nawet działające) można znaleźć pod stosownymi adresami. Od tej pory wszystkie zmiany w pisanych przeze mnie aplikacjach będą automatycznie umieszczane na serwerze wraz z kolejnymi wpisami. Od tej pory wystarczy pamiętać jeden adres – chlebik.pl

Program Bash również w sieci

Zgodnie z obietnicą z poprzedniego postu wracam do programowania. Ostatni wpis dotyczący ProgramBash miał miejsce bodajże 5 sierpnia. Minęło całkiem sporo czasu zatem wypada coś z tym tematem zrobić.

Dziś zaś nie zamierzałem rozpoczynać tworzenia nowej funkcjonalności, ale za to postanowiłem wrzucić to co do tej pory istnieje na swój serwer hostingowy. Zakładam, że o wiele milej jest zobaczyć coś w działaniu, niż tylko podglądać screeny. Proces deplyomenu był całkiem miły i przebiegł bez zakłóceń – stworzenie pliku WAR, następnie eksport na serwer, dorzucenie kontekstu dla Jetty i poszło. Zasadniczo problemów nie było – poza jednym. Domyślne formatowanie taga (czy tagu?) <f:convertDateTime /> leci po ustawionym Locale. Jednakże wpis na ten temat jest (zakładam) odczytywany z systemu, albo też NetBeans przy budowaniu projektu i uruchamianiu go u mnie lokalnie podpina moje ustawienia lokalne (czyli polskie). Zaś na serwerze takowe nie chciały zaskoczyć i nagle daty przy newsach zaczęły wyświetlać się po angielsku. Pomogło umieszczenie w pliku faces-config.xml takiego oto kodu:

 <application>
    <locale-config>
      <default-locale>pl</default-locale>
    </locale-config>
  </application>

I poszło bez problemu. Obecnie aplikację można obejrzeć sobie pod tym adresem. Ostatnio serwery, na których trzymam swoje “dzieła” objawiają się dziwnym zachowaniem zatem jeśli coś nie działa to zapraszam do odwiedzin za jakiś czas. Cóż, może w końcu się wykosztuję na jakiś full-professional serwis, no choć te kilka stów rocznie można przeznaczyć zawsze na coś innego.

SCJP – ZDANY

Tak, tak moi drodzy – w tym pięknym dniu 11 września (rocznica psiamać) Anno Domini 2009 zdałem tenże egzamin. Rzecz ta miała miejsce w Warszawie w centrum egzaminacyjnym BizTech przy ulicy bodajże Wolność. I tyle.

No może nie tyle – wszak wpis byłby zbyt krótki. Konkretnie zdawałem już nową wersję egzaminu o czy pisałem już wcześniej. I co? No i nie wiem. Oczywiście egzamin zdany, ale z wynikiem 71%. Hmmm, trochę kiepsko. Jedakże trzeba spojrzeć na wyniki:

Declarations, Initializations, Scoping 80%
Flow Control 81%
API Contents 42%
Concurrency 100%
OO Concepts 50%
Collections/Generics 75%
Fundamentals 77%
Questions 43/60

Zasadniczo poza API i OO Concepts wszystko poszło mi całkiem dobrze (100% ze współbieżności!!). Kwestia po prostu jest taka – w rzeczach, które podpowiada IDE zasadniczo jestem kiepski. Choć to dziwne, gdyż w moim odczuciu wszystkie pytania o API były całkiem proste ( albo o to właśnie chodziło by tak wyglądało ), zaś koncepcje programowania obiektowego to też zakładam, że rozumiem (nawet posługując się na co dzień PHP). Podsumowując – nie wiem co o tym myśleć.

Jednakże certyfikat już posiadam – zatem można założyć, iż pewną wiedzą o samym języku jestem się w stanie wykazać. Zatem mogę bez wstydu odpowiadać na ogłoszenia o pracę, gdzie “wyższe studia informatyczne” są koniecznie potrzebne. Przynajmniej w dziedzinie samej Javy obronię się bez problemu.

Co dalej? Ano w końcu po pewnym okresie przerwy powrócę do programowania. Czyli kontynuacja ProgramBash, a także zamierzam z drugiej strony rozpocząć naukę w dziedzinie narzędzi Javy, ale nie będących frameworkami. Konkretnie chodzi o web-services, parsery XMLa, narzędzia do zarządzania projektem czy ciągłej integracji. Dwutorowość póki co dobrze mi wychodziła, mam nadzieję, że tym razem będzie tak samo.