Monthly Archives: August 2008

Czy się stoi, czy się leży…

Zgodnie z tą starą sentencją (chyba typowo polską 🙂 udaję się na urlop. Co prawda dziś jeszcze jeden dzień w pracy, ale od piątku można mnie znaleźć chyba tylko za pomocą Google Earth.

Dla ciekawych – jadę do Szklarskiej Poręby, w końcu móc pochodzić sobie po ulubionych górach, pogrzeszyć w diecie i odpocząć w ciszy i spokoju. Działalność na blogu natenczas zawieszam (branie laptopa na urlop uważam za objawy uzależnienia), ale mam nadzieję, że po powrocie kolejne artykuły posypią się bardzo szybko. Na chwilę obecną na pewno będzie to coś o wyrażeniach regularnych, a także pierwsza część tutoriala – ‘Tworzymy swój system blogowy’. Mam nadzieję, że po powrocie jeszcze ktoś tu będzie zaglądał (jak pokazują statystyki ktoś zagląda, nawet całkiem sporo ‘ktosi’ 🙂 Czyli jest dla kogo pisać postanawiam zatem nie spadać z gór, ani nie dać się zjeść niedźwiedziom.

Java API tak na sam początek

Standardowo książki poświęcone PHP szczegółowo opisują większość możliwości tego języka. Czyli wpierw mamy słowa kluczowe, przepływ sterowania, potem coś o tablicach, stringach, plikach, itd. W Javie niestety – rzecz ma się zupełnie inaczej.

A by się o tym przekonać wystarczy spojrzeć na spis treści książek poświęconych temu językowi. Taka Thinking in Java to ponad tysiąc stron czystego tekstu (wraz z kodem), a nie omawia nawet połowy tych funkcjonalności języka, które w każdej książce o PHP są szczegółowo omówione. Podobnie z Java Core, choć tutaj jest trochę lepiej. Dlaczego o tym piszę? Bynajmniej nie zamierzam płakać, że nie jestem prowadzony za rączkę, co to, to nie! Pragnę tylko zaznaczyć, iż czasy kiedy po przeczytaniu książki można było spokojnie klepać jakieś proste aplikacje się skończyły. API Javy to ponad 3 tyś. klas!!! To znaczy, że w tych klasach mamy jeszcze najczęściej parę metod, które wyczyniają cuda, których nie powstydziłby się Pan McGyver z Chuckiem Norrisem razem wziętymi. Zapamiętać to jest niemożliwością, omawianie tego w książce również.

Dlatego też trzeba przysiąść fałdów i zajrzeć samemu do specyfikacji języka. Można ją odnaleźć tutaj, ale te sterty HTMLa niekoniecznie wyglądają zachęcająco. Postanowiłem zatem poszukać czegoś w bardziej przystępnej formie, co zaowocowało wizytą na stronie KickJava.com Od zwykłego opisania API na stronach Suna odróżniają tę stronę dwie rzeczy – bardziej przyjazny design (tak, wiem, że strony Suna czyta się lepiej pod linksem czy innym konsolowym ustrojostwem), a także przykłady kodu. Jest to bardzo istotna rzecz dla newbiesów w Javie, gdyż często wrzucenie samej deklaracji metody z listą parametrów nie załatwia sprawy. Tutaj zaś każda klasa jest opatrzona bardzo konkretnym kawałkiem kodu. Dla przykładu kod dla javax.servlet.http opisuje zarówno tworzenie obiektu jak i procesowanie żądania – kliknij tutaj.

Jak zatem widać jest to obowiązkowa strona dla wszystkich. Pozostając zaś w tematyce ciekawych serwisów poświęconych Javie należy wskazać na JavaBlackBelt.com. Serwis ten umożliwia sprawdzenie swojej wiedzy na temat Javy (oraz całości platformy) w formie testów. Kolejne stopnie wtajemniczenia są opisywane poprzez kolory pasów (podobnie jak w sztukach walki). Dla początkujących polecam podstawowe zestawy pytań dotyczące Javy SE, servletów oraz OO. Co prawda jeszcze nie zarejestrowałem się w serwisie (nastąpi to pewnie po powrocie z nadchodzącego urlopu), ale na pewno nie odpuszczę możliwości podrasowania sobie ego zdobywając kolejne kyu. Niech moc będzie z Wami!

Java Server Pages i servletowe podwórko

Wspomniałem już przy okazji poprzedniego wpisu o serwletach oraz o technologii Java Server Pages. W dużym skrócie – serwlety to po prostu aplikacje Javy wykonywane po stronie serwera, zaś JSP to technologia umożliwiająca dynamiczne generowanie dokumentów (X)HTML poprzez osadzenie w kodzie HTMLa wstawek z języka Java (za Wikipedią). Dodatkowo rzecz z automatu jest realizowana we wzorcu MVC (Model-View-Controller), co można ostatecznie podsumować stwierdzeniem, że mamy bardzo przyjemne narzędzie do tworzenia aplikacji internetowych.

Dlaczego o tym piszę? Albowiem jako programista PHP pracujący nad projektami o bardzo pojemnej nazwie ‘webdevelopment’ automatycznie kieruję się w stronę znanych mi rozwiązań, a za takowe JSP (i potem Java Server Faces – to framework) można uznać. Jednoczesne poznawanie Javy (za pomocą Bruce’a Eckela i jego ‘Thinking in Java’) oraz JSP (książka ‘Head First JSP’) póki co okazało się dość obiecującym rozwiązaniem, gdyż zamiast klepać standardowe do bólu System.out.println i zachwycać się rozbudowaną konwersacją z konsolą, można tworzyć kod wypełniając znany sobie szkielet aplikacji (np. tworząc system blogowy).

Do rozpoczęcia zabawy z JSP potrzebujemy jednej rzeczy – kontenera na serwlety. Rolę tę pełni świetnie Apache, kiedy doinstaluje się do niego odpowiedni moduł, albo też kiedy zainstaluje się Apache Tomcat jako samodzielny serwer (www + jsp w jednym). Zasadniczo wyszedłem od tej koncepcji (czy wspominałem już, że jestem leniwy jeśli chodzi o babranie się z administracją?), a następnie spróbowałem jakoś to wrzucić (pluginem oczywiście) pod Eclipse’a. Po strawieniu 3h nad konfigiem oraz próbą zmuszenia tej aplikacji by w końcu zobaczyła mój plugin do Tomcata dałem za wygraną i postanowiłem ściągnąć NetBeans. Downloaded, zainstaluj, uruchom, ściągnij update i viola!!! Nagle okazało się, że wystarczy stworzyć nowy projekt i nacisnąć ‘Build all’ – wszystko pięknie śmiga. Jako, że była gdzieś 3 nad ranem porzuciłem zabawę, ale wróciłem do niej zaraz następnego dnia.

NetBeans ma to do siebie, że można go ściągnąć w kilku wersjach. Bardzo ważne jest to, że możemy również wybrać wersję niejako ‘out of the box’, gdyż razem z IDE dostarczany jest też Tomcat oraz GlassFish (to serwer aplikacji J2EE firmy Sun). Po zainstalowaniu otrzymujemy (pod Windowsem oczywiście) w pełni skonfigurowane narzędzie. Tutaj właśnie uwaga – opiszę co i jak by skonfigurować pierwszy projekt i uruchomić go. W książce ‘Head First JSP’ przedstawiono podział na 2 środowiska – developerskie oraz aplikacyjne (czyli produkcyjne). Jest to rozwiązanie poniekąd słuszne, jednakże na czas nauki, kiedy człowiek musi przypominać sobie czasem składnię podstawowych funkcji, jakoś nie widzę ku temu sensu.

W NetBeans zatem skonfigurujemy projekt tak, aby dało się w obrębie jednego katalogu jednocześnie posiadać kod źródłowy, jak i widzieć go (po kompilacji oczywiście) z poziomu przeglądarki. Oto co trzeba zrobić:

1. Okienko z projektami -> prawy przycisk myszy i oczywiście New Project
2. Pokazuje się lista do wyboru, nas interesuje Web, a potem Web Application
3. Nadajemy projektowi nazwę, NetBeans automatycznie poda domyślną ścieżkę do niego (czyli katalog webapps w katalogu gdzie zainstalowano Tomcata).
4. Pojawią się informacje o używanej wersji serwera i takich tam – wybieramy oczywiście to, co zainstalowane (najprawdopodobniej Tomcat 6.0, Java EE 5).
5. W następnym kroku mamy możliwość wyboru używanego frameworka. Jako, że nic takiego na razie nie ma miejsca, to klikamy Finish i mamy gotowy szkielet projektu.

By przetestować działanie całości należy prawym przyciskiem myszy kliknąć na nasz projekt (w okienku projektów) i wybrać Build. NetBeans nam pokompiluje co trzeba i następnie znowu pod prawym przyciskiem wybieramy Run i po paru sekundach mielenia otwiera się nam przeglądarka i pojawia się śliczne ‘Hello wordl!’ (adres to http://localhost:8084/TWOJANAZWAAPLIKACJI/).

Teraz kiedy już mamy działający projekt trzeba objaśnić trochę strukturę katalogów. Różni się ona od przyjętej w ‘Head First’, zatem dla jasności napiszę co i gdzie. Struktura katalogów w folderze naszej aplikacji wygląda tak:

1. Katalog nbproject to internalsy NetBeans i nie należy tego na razie dotykać.
2. Podobnie rzecz ma się ze znajdującym się w katalogu aplikacji plikiem build.xml oraz katalogiem dist – to informacje na temat sposobu budowania projektu, a w katalogu z kolei umieszcza się ostatecznie przygotowaną paczkę z kodem (w formie pliku *.war).
3. Katalog test służy zgodnie z nazwą do testów (testów jednostkowych opartych na JUnit)
4. W katalogu build zgodnie z nazwą budowany jest cała aplikacja
5. W katalog src znajduje się nasz kod źródłowy
6. I na sam koniec w folderze web znajdują się nasze pliki *.jsp i *.html (wraz z plikiem web.xml).

Oczywiście normalnie nikt nie będzie grzebał bezpośrednio w plikach w tym folderze – od tego jest IDE. Jednakże dobrze wiedzieć co i z czym, zwłaszcza dla początkujących informacja ta może być dość istotna. Nasz projekt póki co nie zawiera kodu Javy, ale jest w pełni gotowy na jego przyjęcie. Na razie rzut oka na okienko IDE:

Aplikacja na razie jest dla nas interesująca w dwóch miejscach. Pierwszym z nich jest katalog Source Packages. Tutaj należy dodawać kolejne pakiety, a w nich klasy (np. com.wordpress.chlebik.TestowaKlasa.java). Umieszczone tutaj zostaną w procesie budowania projektu skompilowane i przerobione na postać strawną dla serwera. Drugim ważnym katalogiem jest katalog web, gdzie znajduje się cały HTMLowy lub JSPowy kod. Dla przykładu – znajdź w tymże folderze plik index.jsp i zmień jego nazwę na np. index2.jsp. Teraz w przeglądarkę wrzuć adres http://localhost:8084/WebApplication1/. I co? Ano nic, błąd. Ale z kolei wpisanie http://localhost:8084/WebApplication1/index2.jsp już jak najbardziej działa. Na prostym przykładzie widać, co gdzie i z czym jeśli chodzi o HTML i JSP. W katalogu tym można również odnaleźć podkatalog WEB-INF gdzie znajduje się plik web.xml, który służy do (powiedzmy uogólniając) kierowania routingiem w naszej aplikacji. Jednakże to uczący się JSP już raczej wiedzą i nie potrzeba tego tematu rozwijać.

Mam nadzieję, że to krótkie i pewnie trochę chaotyczne wypociny jednakże komuś pomogą, a i może skłonią do sięgnięcia po NetBeans.

Java – czyli co z czym i dlaczego

Pamiętam jak dziś podziw w jaki wpadłem kiedy za czasów dalece prehistorycznych zainstalowałem na kompie coś, co nazywało się Borland C++ Builder IDE (w wersji chyba 4.0) i zobaczyłem, że stworzenie okienkowej aplikacji działającej w Windows może być proste jak konstrukcja gwoździa. Oczywiście od tamtego czasu (jakiś 1997 rok) minęło trochę czasu, ale i tak równie nabożny lęk ogarniał mnie wówczas, kiedy stykałem się (głównie przypadkiem) z możliwościami platformy Javy. Kiedy w końcu postanowiłem zgłębić to zagadnienie okazało się, że nie jest to wcale takie proste.

By jednakże nie komplikować za wiele – Java jest silnie typowanym językiem programowania stworzonym pierwotnie przez firmę Sun. Kod źródłowy programów jest kompilowany do tzw. byte-codu, a następnie uruchamiany za pomocą tzw. wirtualnej maszyny Javy (JVM). Odrębne dystrybucje tejże maszyny zostały napisane dla niemal wszystkich będących w użyciu systemów operacyjnych, co sprawia, że programy napisane w Javie mogą być uruchamiane na niemalże każdej platformie systemowej.

Oczywiście sam język Java to dopiero podstawa całej platformy. Istnieje kilka tzw. edycji tego języka, które są używane w zależności od potrzeby. To właśnie ich istnienie było dla mnie na początek zastanawiające – oto lista:

  • Java SE – jest to ‘podstawowa’ wersja języka Java. Zawiera ona także JRE (Java Runtime Environment), czyli mówiąc inaczej jest to implementacja wirtualnej maszyny. Jest to wersja ogólnego przeznaczenia – zarówno dla tworzenia aplikacji desktopowych jak i internetowych. Obecnie wersja ta nosi numer 1.6 zaś suffix SE jest dodawany po to, aby odróżnić tę wersję od pozostałych (o tych dalej). Należy także wspomnieć o numeracji – wersja 1.2 języka Java przyniosła tak duże zmiany, że zaczęto nazywać tę wersję (i późniejsze również) wersją numer 2. Znalazło to nawet nazewnictwo w książkach – jak choćby “Core 2 Java” (2 tomy). Jednakże od wersji 1.6 zrezygnowano z tego i dziś należy mówić o Javie SE (Standard Edition) w wersji 1.6.
  • Java ME – jest to wersja Javy przeznaczona dla urządzeń w domyśle małych (ME to inaczej Micro Edition). Tutaj mowa przede wszystkim o komórkach, ale też o wszystkich innych urządzeniach mobilnych, w których potrzebna jest funkcjonalność Javy.
  • Java EE – to jest to co tygrysy lubią najbardziej. Jest to Enterprise Edition, czyli rozwiązanie przeznaczone na potężne serwery internetowe. Zawiera w sobie wszystko to, co posiada wersja SE, ale też masę innych bibliotek, które umożliwiają tworzenie oprogramowania dla serwerów.

Sam język programowania Java nie zdziała nic wielkiego (no może poza konsolowymi wprawkami). To co przesądza o jego potędze to technologie, które zostały na nim oparte, a dziś są one podstawą dla tworzenia aplikacji zarówno desktopowych, jak i serwerowych. Przedstawię pokrótce ich przegląd:

  • Standardowe aplikacje desktopowe – myślę, że każdemu programiście wystarczy dać na przykład Eclipse IDE by łatwo pojął istotę tychże aplikacji. Język Java jest tutaj podstawą, zaś do konstruowania wymyślnego GUI używa się bibliotek graficznych, np. SWT, czy Swing. Dzięki tym bibliotekom można tworzyć bardzo rozbudowane aplikacje uruchamiane niezależnie od platformy.
  • Aplety – aplet to taka ‘przeglądarkojavascriptowa’ konstrukcja języka Java. By jednakże być bardziej konkretnym wystarczy wspomnieć, iż applet jest kodem języka Java, który jest najczęściej osadzany na stronach WWW, skąd jest pobierany do klienta i wykonywany po jego stronie. Przypomina to technologię Flash i zasadniczo niewiele się od niej różni. By uruchomić aplet na komputerze klienta musi być zainstalowana wirtualna maszyna. Najczęstszym użyciem apletów jest osadzanie na stronach WWW małych, ale jednocześnie dość skomplikowanych aplikacji (np. czaty czy klienty IRCa).
  • Servlety – w odróżnieniu od apletów są to porcje kodu Javy wykonywane po stronie serwera. Są one podstawą dla technologii Java Server Pages (czegoś na kształt PHP). O technologii tej będę jeszcze pewnie nie raz pisał, gdyż naukę Javy przeprowadzam równolegle z klepaniem kodu w JSP. Tutaj tylko pragnę zaznaczyć, że nie można utożsamiać serwletów z JSP! Są to dwie oddzielne rzeczy, które choć występują razem, po części (przynajmniej serwlet) mogą istnieć niezależnie.

Wiemy już zatem co i jak z wersjami Javy, wiemy w jakich postaciach pisze się programy w tym języku, teraz czas na rozjaśnienie kilku magicznych słów, które przewijają się na stronach poświęconych Javie, a na poczatku niekoniecznie muszą być zrozumiałe dla noobów:

  • Serwery aplikacji – podobnie jak kod PHP nie da się uruchomić ot tak na zawołanie, również i w większości przypadków kod Javy wykonywany po stronie serwera, musi być uruchomiony pod auspicjami przeznaczonego do tego serwera aplikacji. Tutaj można wyróżnić dwie kategorie – pierwszą z nich są tzw. kontenery serwletów. Służą one zgodnie z nazwą do uruchamiania serwletów. Innymi zaś słowy – jest to serwer WWW, który umożliwia dostęp do aplikacji napisanych w formie serwletów lub opartej na JSP. Najpopularniejszym tego typu rozwiązaniem jest Apache Tomcat. Drugą kategorią są serwery aplikacji ‘pełną gębą’, takie jak JBoss, lub też WebSphere (płatny). Dają one dostęp do pełnej funkcjonalności platformy Java EE, ale też umożliwiają uruchamianie serwletów.
  • JavaServerPages – o tej technologii wspomniałem już wcześniej przy okazji omawiania serwletów. Otóż JSP jest technologią, która opiera się na wzorcu MVC, gdzie kontrolerem są serwlety, modele to zwykłe klasy języka Java, zaś za tworzenie widoku odpowiada właśnie JSP. Można powiedzieć, że kiedy używa się PHP z Symfony czy Zend Framework to zasadniczo robi się to samo co JSP tylko w troszkę innej technologii. W przypadku JSP jednakże, jest to zaledwie podstawa – działanie wspierające tworzenie aplikacji internetowych w tej technologii dają frameworki języka Java – Java Server Faces lub Struts (by wymienić te najpopularniejsze).
  • Enterpreise JavaBeans – ‘fasolki’ lub ‘ziarna’ jak się o nich mówi to zasadniczo coś na kształt serwletów, z tym tylko, że do uruchomienia potrzebują pełnego serwera aplikacji (kontenera EJB). Są one jednym z elementów składowych (jeśli tak to można nazwać) korporacyjnej wersji Javy. Alternatywą dla tej technologii jest jej podobna – Spring Framework, który jest mniej rygorystyczny oraz o wiele ‘lżejszy’ od ziarenek.
  • Ant, Maven – są to narzędzia do zautomatyzowanego budowania projektów. Dają dużo możliwości konfiguracji, a według opinii na necie dzięki temu javowcy wciąż mają włosy na głowach. Póki co nie miałem okazji korzystać, gdyż od tego mam IDE NetBeans, ale pewnikiem zaniedługo trzeba się będzie ogarnąć w tym temacie.

Mam nadzieję, że powyższe informacje pozwolą na systematyzację wiedzy dotyczącą języka Java, a co za tym idzie dadzą zarys planu nauki oraz kierunku rozwoju.

A tak poza tym

Dlaczego Java? Ano bo pewnego razu zachciało mi się coś zmienić w życiu zawodowym, co zaowocowało postanowieniem nauczenia się tego języka. Wybór był dość prosty – gdziekolwiek nie obróci się webdeveloper (za takowego się uważam), słyszy narzekania, że w tym PHP to OOP to parodia, gdzie tam mu do Javy. Wzorce projektowe to też na siłę używane, gdzie tam im do Javy. Bezpieczeństwo, poprawność kodowania, czy co tam komu do głowy nie przyjdzie – najlepsze w Javie. Pomijając trollujących po forach i usenecie zealotów tego czy innego rozwiązania, trzeba przyznać rację sporej rzeszy programistów. Java jest narzędziem potężnym, zaś nadbudowane na niej technologie występują wszędzie dookoła nas. Powszechność użycia, ale też z drugiej strony wymagania stawiane programistom, sprawiły iż postanowiłem poznać tajniki tego języka, aby w przyszłości móc (kto wie kiedy, na razie klepanie kodu PHP wciąż mnie kręci) popracować z użyciem tej technologii.

Tyle o motywacji. Zaś po co kolejny blog? Ano dlatego, że gdzie się w necie nie obrócić, można napotkać spore community Javovców, jednakże dość ‘zaawansowane tematycznie’. Stron czy też forów (vide PHP.PL) dla początkujących, jakoś za wiele nie znalazłem. Uprzedzając purystów i miłośników firmy na G – dyskusji o ‘książkach dla początkujących’ nie zaliczam do tejże kategorii. Pierwsze podejście do choćby zorientowania się w gąszczu tych wszystkich Antów, Strutsów czy innych Hibernatów nie było łatwe, a przecie na co dzień piszę w Zend Framework, trochę rzeczy już w życiu przeczytałem i nakodowałem, że o znajomości Turbo Pascala nie wspomnę 🙂 Nie jest zatem łatwo na początku. Helionowe biblie są dobre (do czytania przed snem jak i przy porannej kawie), jednakoż często skupiają się na samym języku, zaś cholera potem trudno wynaleźć informację jak poprawnie sobie skonfigować Eclipsa z piętnastoma pluginami i najlepiej by się kompilowało ostatecznie tam gdzie się chce.

Jako noob w dziedzinie Javy i zasadniczo również języków kompilowanych (choć może powiem inaczej – innych niż skryptowe czy tam interpretowane), po kolei przechodzę wszystkie problemy, jakie dotykają młodych Javovców. By zaś ułatwić drogę ‘tym co przyjdą po mnie’ :), jak i by nie wyjść z wprawy w operowaniu słowem pisanym (studia właśnie skończone) stworzyłem ten blog. Mam nadzieję, że okaże się pomocny dla wielu osób, zwłaszcza zaś, że pozwoli uniknąć podstawowych problemów z jakimi można się spotkać podczas nauki Javy.