Category Archives: HowToJava

Przerwa techniczna w pracy serwera

Zasadniczo tak jak w tytule. Wystąpiła konieczność migracji na inny serwer wszystkich aplikacji z serwerka. Dlatego też chcący obejrzeć aplikacyjki muszą póki co obejść się smakiem. Mam nadzieję, że przerwa skończy się jak najszybciej.

Advertisements

VPS gotowy

W tym jakże pięknym choć mroźnym dniu nadejszła wielkopomna chwila – mój VPS oficjalnie zostaje zaprezentowany światu.

Punktem wejścia jest domena chlebik.pl, gdzie znajduje się mini-portfolio z linkami, które prowadzą do aplikacji i bloga. Od dziś aplikacje stworzone przeze mnie i działające online będą podpinane pod kolejne subdomeny. Na razie zatem mamy http://programbash.chlebik.pl oraz http://howtojava.chlebik.pl.

Na VPSie działa Tomcat, który okazał się o wiele bardziej przyjazny dla moich aplikacji niż Jetty. Jak serwer proxy przed nim został postawiony superlekki Ngix, zaś system to sprawdzony od lat Debian. Zaniedługo pojawi się pierwszy wpis dotyczący sposobu skonfigurowania takiego serwera, a w przyszłości wpisy na temat optymalizacji oraz zabezpieczania serwera. Na razie to tyle – zapraszam do odwiedzin.

Chlebik leży i kwiczy

Kwiczy i leży. Trwają prace nad przeniesieniem aplikacji na VPS  z Tomcatem na pokładzie. Dlatego niestety wszystkie aplikacje, które stworzyłem edukacyjnie wraz z wpisami na blogu są nieaktywne. Stan ten utrzyma się jeszcze przez kilka dni niestety. Ale pewnie będę mógł napisać kilka ciekawych wpisów o konfiguracji Debiana do pracy jako serwer dla Javy.

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

HowToJava, ostateczny szlif

Po dłuższym okresie walki z językiem Groovy i Grailsami uznałem, że przyszedł czas by zakończyć prace nad aplikacją HowToJava. Ostateczny kształt nie poraża może możliwościami, ale podczas prac dowiedziałem się tylu nowych rzeczy, że to co powstało w pełni mi wystarcza (pewnie nie raz sypnie wyjątkiem na serwerze :).

Rzecz głównie w zupełnie odmiennej filozofii pracy z kodem (w odróżnieniu choby od używanego na co dzień PHP). Domyślam się, że to sprawka samego języka, ale też i frameworka, który upraszcza wszystko niemożebnie, co momentami jednakże prowadzi do wkurzających wręcz sytuacji, z którymi musiałem sobie poradzić. Z perspektywy czasu nie uważam poznania tej dziedziny programowania w Javie za stracony! Jak radził na początku Jacek Laskowski poznanie Grailsów daje możliwość zapoznania się z świetnie działającym konglomeratem kilkunastu uznanych powszechnie technologii/frameworków/abstrakcji, a ostatecznie przy bliższym poznaniu składowych – docenienie Grailsów w pełni.

Zakładam, że jednakże minie jeszcze trochę czasu, zanim będę mógł kompetentnie się w tej dziedzinie wypowiadać. Na razie kontynuuję przygotowania do certyfikacji SCJP. W końcu czerwca udaję się na tygodniowy urlop, zakładam zatem, że do tego czasu z całą pewnością do egzaminu nie będę podchodził. Ale lipiec to jak najbardziej realny termin. Z braku wykształcenia kierunkowego muszę nadrabiać zdawaniem certyfikatów, cóż począć 🙂

Zastanawiam się także nad rozpoczęciem prac nad nowym projektem (no bo ile można katować czystą Javę 🙂 – teraz tylko pytanie o technologię. Czy wyjść z poziomu niewiele niższego niż Grails? Może zatem czysty Hibernate i Spring? A może trochę nowoczesności – GWT lub Seam (ten ostatni ma fajną dokumentację)? Ciągną też rozwiązania niskopoziomiowe – JSP, JSF, Struts. Każdy wybór ma swoje wady i zalety. Powiedzmy sobie szczerze – nikt raczej nie zatrudnia młodzika na juniora by od razu po przyjściu kodował olbrzymie systemy w Springu. Zaś do konserwacji przedpotopowego kodu pisanego w JSP już jak najbardziej tak. Ankieta u Jacka również jest ciekawa i daje wiele do myślenia. No nic, dam sobie kilka dni do przemyśleń.

PS. HowToJava można też obejrzeć pod łatwiejszym adresem http://chlebik.pl

Grailsujemy dalej – zadajemy pytania w HowToJava

Po dłuższej przerwie wróciłem do kodowania w Grails. Zostało jeszcze parę rzeczy, by uznać, że na bardzo podstawowym poziomie, przykładowa aplikacja HowToJava jest skończona. Dziś pierwszy krok na tej drodze – możliwość tworzenia tematów/zadawania pytań.

Warstwa widoku, walidacji błędów, klas domenowych nie wychodzi poza rzeczy, której do tej pory opisywałem. Na tym temacie zatem nie będę się specjalnie skupiał. Jedyną rzeczą, którą możnaby przećwiczyć jest kolejny plugin, który zamierzam użyć – FCKEditor. Biblioteka ta jest uniwersalnym GUI przeznaczonym dla stron internetowych. Umożliwia wyczynianie cudów z wpisywanym tekstem – dla potrzeb mojej aplikacji jest tego aż nadto. Zainteresowanych samym edytorem mogę odesłać na jego stronę domową. Zaś dla nas bardziej interesująca będzie strona opisująca plugin, który umożliwia wykorzystanie mocy tegoż edytora w Grails.

Standardowo przechodzimy do katalogu z aplikacją i wydajemy polecenie:

grails install-plugin fckeditor

I po chwili możemy cieszyć się kolejną funkcjonalnością w aplikacji. Zainstalowałem wersję 0.9.2, która jest najnowszą, mam zatem nadzieję, że da się z niej korzystać. Kiedy integrowałem swego czasu FCKEditora z Zend Framework miałem trochę zabawy. No i wykrakałem…

Okazuje się, że skrypt ściągający plugin nie rozpakowywuje go odpowiednio. Zatem musiałem wybrać się na stronę pluginu i ściągnąć go dla pewności ręcznie. Następnie plik *.zip trzeba rozpakować do katalogu /plugins, a konkretniej do folderu fckeditor-0.9.2. Zaś w widoku wrzucamy taki oto kod:

<fckeditor:editor
name="question"
width="100%"
height="200"
toolbar="Basic"
fileBrowser="default">
</fckeditor:editor>

No i działa. Wrzuciłem minimalny pasek z narzędziami, ale to można łatwo zmienić. Dla bardziej zaawansowanej konfiguracji polecam przyjrzenie się plikowi fckconfig.js w katalogu z pluginem.
Walidacja jest prosta jak konstrukcja gwoździa (ogranicza się tylko i wyłącznie do walidacji klasy domenowej). Jedynym problemem była data dodania. Jakoś na początku swej przygody z programowaniem dla web pałałem prawdziwą miłością do typu DATETIME w MySQL. Jednakże jakiś czas temu zostałem wyleczony z używania tej kolumny, na rzecz TIMESTAMPA (unixowego). Po prostu wyszukiwanie po kolumnach jest kilkakrotnie szybsze (wartości TIMESTAMP są zapisywane jako INT(11) ), a także sam format TIMESTAMP jest o wiele bardziej uniwersalny – każdy język programowania (no, przynajmniej te w których kodowałem) miał bardzo sympatyczne wsparcie dla tego formatu. W Javie obecny TIMESTAMP (uwaga: konkretnie chodzi mi o ilość sekund od 1970, a nie milisekund, co zresztą w kodzie widać) można wydobyć w taki sposób:

Math.round( System.currentTimeMillis()/1000 )

I takim oto szybkim obejściem dało się to załatwić. Tak wygląda widok dodający nowy temat:

dodawanieTematu

Chlebik walks alone – deployment HowToJava

Zgodnie z zapowiedziami dorobiłem się w końcu własnej przestrzeni w necie. Do tego przestrzeni całkiem sympatycznej bo z własnym Jetty i paroma innymi rzeczami. Rzecz jasna trzeba było spróbować ponownie pokazać światu moje Grailsowe wypociny.

Samego procesu deploymentu do tej pory nie ruszałem. Lokalnie uruchamianie aplikacji odbywa się poprzez NetBeans, zapędów do konfiguracji serwerów/kontenerów też póki co nie mam. Jak wspomniałem również wcześniej – niedługo Helion wyda na podobne tematy książkę, zatem poczekam jeszcze trochę by zapoznać się z tematem dogłębniej. Jednakże by wrzucić coś na serwer docelowy z całą pewnością wypada skonfigurować dostęp do bazy danych. Oczywiście by to osiągnąć wypada wpisać odpowiednie dane dostępowe do DataSource.groovy.

Kiedy się z tym uporałem przyszedł czas na zbudowanie paczki dystrybucyjnej. W Grails jest to proste jak konstrukcja gwoździa. Wystarczy przejść do katalogu z aplikacją i wydać polecenie:

grails war

Pomieli, przemieli i ostatecznie w tymże katalogu wypluje nam paczkę (plik z rozszerzeniem *.WAR). Teraz ten plik (ja jego nazwę zmieniłem na howtojava.war, wyrzucając numerację wersji) należy wrzucić na serwer produkcyjny. Domyślnie Jetty wszystkie aplikacje próbuje odnaleźć w katalogu /webapps. Konwencja ta jest słuszna, zatem w tymże katalogu stworzyłem następny (o nazwie a jakże howtojava) i do niego wrzuciłem plik WAR. Teraz przyszedł czas na konfig serwera.

Należy zajrzeć do pliku jetty.xml, który rezyduje w podkatalogu /etc podstawowego folderu serwera. Możemy z góry określić wspólną konfigurację dla serwera (jak np. uruchamia się na nim jedną aplikację) – i to są ustawienia domyślne. Ja jednakże postanowiłem, iż dla każdej aplikacji (na razie jedna, ale może będzie i więcej) będę posiadał oddzielny plik konfiguracyjny. Wyedytowałem plik i dodałem takie oto zapisy:

<Call name="addLifeCycle">
<Arg>
<New class="org.mortbay.jetty.deployer.ContextDeployer">
<Set name="contexts"><Ref id="Contexts"/></Set>
<Set name="configurationDir"><SystemProperty name="jetty.home" default="."/>/contexts</Set>
<Set name="scanInterval">5</Set>
</New>
</Arg>
</Call>

W folderze z Jetty należy utworzyć wskazany katalog (/contexts). I następnie wrzucamy do niego pliczek o wdzięcznej nazwie Howtojava.xml. Wygląda on tak:

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN" "http://jetty.mortbay.org/configure.dtd">
<configure class="org.mortbay.jetty.webapp.WebAppContext">
<Set name="contextPath">/howtojava</Set>
<Set name="war"><SystemProperty name="jetty.home" default="."/>/webapps/howtojava/howtojava.war</Set>
</configure>

Jednakże przy takiej konfiguracji, wejście na podstawową domenę powoduje brzydkie zgłoszenie błędu 404 i wylistowanie wszystkich dostępnych kontekstów. Dlatego tez dodałem jeszcze jeden plik w katalogu /contexts – default.xml. Oto on:


<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN" "http://jetty.mortbay.org/configure.dtd">
<configure class="org.mortbay.jetty.webapp.WebAppContext">
<Set name="contextPath">/</Set>
<Set name="war"><SystemProperty name="jetty.home" default="."/>/webapps/howtojava/howtojava.war</Set>
</configure>

Dzięki temu domyślnie wskazanie na domenę leci pod konkretny adres. Uruchomienie serwera to odpalenie pliku start.jar z odpowiednimi uprawnieniami. Mój jakże miły admin (choć nie wiem czy to on, czy po prostu lekko wyedytował defaultowe skrypty) dostarczył mi 2 pliczki, które opakowywują uruchamianie i zamykanie serwera: Start.sh:

#!/bin/sh

export port=$(expr $(cat base_port) + 0)

echo "Starting the Jetty process at port $port"

nohup java -Xmx$(cat ram_size)m -Drun.mode=production -Djetty.port=$port -jar -server start.jar etc/jetty.xml >> logs/std.out 2>> logs/err.out &
echo $! > prod.pid
echo "The PID is $!"

Nie jest to nic skomplikowanego. Obok tego pliku w katalogu leżą 2 inne pliki – jeden (base_port) zawiera informację o porcie, na którym ma być uruchomiony serwer, a drugi (ram_size) to wejściowa ilość RAMu dla serwera. Przypisany ID procesu jest zapisywany do pliku, a wyjście zarówno System.out, jak i strumień błędów są przekierowywane do odpowiednich katalogów. Drugi skrypt to po prostu odczytanie zapisanego ID procesu z pliku i zabicie tego procesu. Uwadze polecam również plik /bin/jetty-service.conf, gdzie można znaleźć kilka ciekawych zmiennych, którymi można się pobawić.

I tyle. Teraz wystarczy odwiedzić : pewien adres by zobaczyć jak śmiga HowToJava. Subdomena póki co mi nie chwyciła, ale jak załapie to z całą pewnością przepnę ją na nowy adres.

Gdyby ktoś był zainteresowany hostingiem dla aplikacji Grails i bardzo profesjonalną obsługą, wówczas wystarczy napisać mejla na adres admin@serenity.org.pl i ładnie poprosić o ofertę. Jako, że serwery cały czas są w fazie ‘beta’ (w sumie GMail też jest :), zatem szereg rzeczy jeszcze nie działa tak jak powinno, a części póki co nie ma. Ale ceny bardzo konkurencyjne, zaś z jakości usługi jestem póki co bardzo zadowolony.