GeeCON - czy Twój szef wystarczająco dba o Ciebie?
Tytuł może zbyt kontrowersyjny ale w innym przypadku pewnie nie zwrócilibyście na niego uwagi
Jak zapewne większość z Was wie, wczoraj wystartowaliśmy z rejestracją na GeeCON - pierwszą w pełni międzynarodową konferencją poświęconą Javie w Polsce. Jest to dobry moment aby przybliżyć pokrótce powody dla których ją organizujemy oraz dlaczego poważnie powinieneś zastanowić się nad udziałem w GeeCON.
Po pierwsze, głównym powodem dla którego zabraliśmy się za organizację GeeCON była chęć umożliwienia Wam i sobie udziału w konferencji podczas której prelegentami będą ludzie z naprawdę topową wiedzą. Część z nich to znane osoby pracujące nad rozwojem technologii których używacie codziennie w pracy, część to ludzie pracujący nad ciekawymi projektami, którzy są chętni podzielić się swoim doświadczeniem. Staramy się ich zebrać w jednym miejscu i czasie, tak aby stworzyć możliwie najbardziej interesujące wydarzenie “javowe” w tym roku w Polsce.
Oczywiście, nie wszystkie tematy muszą wszystkim odpowiadać, możliwe też, że część z prezentacji, które znajdują się w agendzie byłaby Waszym zdaniem gorsza od tych, które musieliśmy odrzucić z braku wolnych slotów (aktualne wolne sloty w agendzie są przeznaczone dla prelegentów, którzy nie śpieszą się z podsyłaniem tematów i abstraktów).
Organizując GeeCON staramy się unikać tego czego sami nie lubimy, dlatego też ograniczyliśmy do absolutnego minimum wszystkie marketingowe aspekty prezentacji, a prelegenci sponsorów będą opowiadać o rozwiązaniach open source i technologiach ogólnie dostępnych, to jest jeden z naszych głównych celów.
Pomimo faktu, że wszyscy organizujemy konferencję za free (ot taki rodzaj wolontariatu), nie uda nam się doprowadzić do tego aby wejściówki były za darmo. Niestety są pewne koszty stałe, których pokrycie konieczne jest do realizacji pełni naszej wizji. Gdybyśmy z nich zrezygnowali to GeeCON nie byłby już GeeCONem w tej postaci jaką możecie obserwować (byłby krótszy i z udziałem mniejszej ilości zagranicznych prelegentów oraz z dużym udziałem prezentacji marketingowych).
Na całe szczęście udało nam się zminimalizować stawkę do poziomu, który część osób naprawdę zadowala (pozostałe zawsze będą narzekać, że jest zbyt drogo :P). 389 PLN to chyba stawka do przełknięcia dla wszystkich firm informatycznych w kraju i dla większości developerów (już nie narzekajcie jak to mało zarabiacie), w ten sposób prawdopodobnie odrzucamy główny argument Waszego PM’a, który pewnie zawsze mówi Wam, że wyjazd na zagraniczne konferencje to zbyt duży koszt
Faktycznie porównując z takimi konferencjami jak QCon, Jazoon czy też ApacheCon to GeeCON jest śmiesznie tani. Oczywiście wiadomo, że te konferencje są sporo większe od GeeCON ale z drugiej strony i tak możecie uczestniczyć w jednej ścieżce w jednej chwili co sprawia, że w przeliczeniu na godzinę prezentacji GeeCON to zdecydowanie mniejszy koszt. I o to właśnie wszystkim organizatorom chodziło, nie organizować imprezy dla zysku a tylko dlatego aby dostarczyć Wam godne uwagi wydarzenie “javowe”.
Jeśli już dotarliście do tego miejsca to mam nadzieję, że podzielicie się swoimi uwagami i spostrzeżeniami, zarówno jeśli chodzi o GeeCON, jak i inne rzeczy które mogą się Wam wydać istotne w kontekście tego wpisu. Na koniec jeszcze chciałem wszystkich zaprosić do udziału w GeeCON i nie tylko, bo już wielkimi krokami zbliża się kolejna Javarsovia i Java4People
Inicjalizacja danych w zależności od trybu uruchomienia aplikacji Grails
Pisząc aplikacje w Grails niejednokrotnie stajecie przed koniecznością wykonania pewnej logiki podczas startu aplikacji, logika taka to np. dodanie użytkownika do bazy danych, zapisanie podstawowych i zarazem koniecznych do działania aplikacji danych w bazie.
Logika taka powinna zostać zawarta w klasie BootStrap znajdującej się w katalogu conf Waszej aplikacji. Początkowa postać tej klasy to:
def init = { servletContext ->
}
def destroy = {
}
}
W bloku init możecie umieścić kod, który zostanie wywołany podczas uruchomienia aplikacji, blok destroy powinien zawierać operacje, które mają zostać wykonane podczas zakończenia aplikacji - zakończenie takie musi odbyć się w sposób standardowy, zakończenie wykonania aplikacji spowodowane sytuacją nadzwyczajną nie spowoduje wykonania instrukcji zawartych w bloku destroy.
Dodajmy do powyższej klasy kod, który zostanie wykonany podczas startu naszej aplikacji:
def init = { servletContext ->
new User(username: ‘admin’, password: ‘admin’).save()
}
def destroy = {
}
}
W ten sposób zapisujemy użytkownika o loginie admin i haśle admin, oczywiście musimy mieć utworzoną klasę domenową User z odpowiednimi polami
Teraz podczas startu naszej aplikacji nasz przykładowy użytkownik będzie zawsze dodawany do bazy,
pytanie co zrobić gdy chcemy wykonać logikę w zależności od środowiska w którym uruchamiamy aplikację, jak wiadomo standardowo mamy trzy środowiska: development, test, production. Uruchomienie aplikacji w konfiguracji odpowiadającej określonemu środowisku odbywa się poprzez wykonanie komendy grails run-app z odpowiednim parametrem, np.:
Powyższa komenda uruchomi aplikację w trybie produkcyjnym.
Dobra, pojawia się teraz pytanie jak w klasie BootStrap sprawdzić w jakim trybie została uruchomiona nasza aplikacja?
Odpowiedź jest bardzo prosta, użyjemy do tego celu takiego oto fragmentu kodu:
Jest to wywołanie statycznej metody getEnvironment, znajdującej się w klasie GrailsUtil (dla niewtajemniczonych wywołania getterów w Groovy wyglądają jak odwołania do pól klasy). Teraz zmienna env będzie zawierała wartość dzięki której będziemy w stanie zidentyfikować rodzaj trybu w jakim uruchomiona została aplikacja, będą to odpowiednio: test, development, production dla trybów: testowego, developerskiego, produkcyjnego.
Teraz nie pozostaje nam nic innego jak uzależnić od zwróconej wartości wykonanie odpowiedniego kodu, można tu standardowo zastosować instrukcję if-else, można też to zrobić sprytniej i wykorzystać dobrodziejstwa jakie daje nam Groovy:
def init = { servletContext ->
def env = GrailsUtil.environment
InitializeData.“$env”()
}
def destroy = {
}
}
Co oznacza powyższy blok kodu, a w szczególności tajemnicza konstrukcja InitializeData.”$env”()?
A więc dzięki niej w bardzo ciekawy sposób rozdzieliliśmy wykonanie kodu zależnego od trybu w którym została uruchomiona aplikacja, umieszczając go w klasie InitializeData w jej statycznych metodach:
static void development() {
//kod wykonywany dla środowiska developerskiego
}
static void test() {
//kod wykonywany dla środowiska testowego
}
static void production() {
//kod wykonywany dla środowiska produkcyjnego
}
}
Zastosowana konstrukcja InitializeData.”$env”() służy do wywołania statycznej bezparametrowej metody o nazwie odpowiadającej wartości zmiennej env, która została zdefiniowana w klasie InitializeData
Groovy - przydatne informacje
Dzisiaj kilka przydatnych linków dla wszystkich zainteresowanych Groovy:
- Strona domowa projektu
- Grails
- Groovy on Grails
- Gradle
- GroovyMag
- Grails Podcast
- Hosting aplikacji napisanych w Grails
- Groovy Zone
- Grails Jobs
- Groovy Blogs
- Grails Tutorials
- IntelliJ IDEA
- About Groovy
- Grails Crowd
- Grails success stories
- Groovy Awards
- Groovy Live
Strona projektu Groovy, znajdziecie tam specyfikację języka, tutoriale i masę linków do różnego typu blogów i portali poświęconych językowi Groovy.
Strona domowa najpopularniejszego frameworku webowego napisanego w Groovy
Agregator blogów o Groovy i Grails.
Narzędzie do budowania aplikacji stworzonych przy pomocy języka Groovy (i nie tylko).
Magazyn developerów Groovy, bardzo ciekawy lecz płatny
Podcast poświęcony Groovy i Grails.
Najlepszy hosting aplikacji Grails.
Wydzielona część DZone w całości poświęcona Groovy.
Szukasz pracy jako deweloper Grails? W takim razie ta strona jest warta Twojej uwagi.
Kolejny agregator blogów o Groovy.
BARDZO przydatna strona z linkami HOWTO w Groovy i Grails.
Bezsprzecznie najlepsze środowisko do Groovy i Grails.
Newsy, Podcasty, Książki o Groovy i Grails - wszystko w jednym miejscu.
Szukasz projektów napisanych w Groovy lub Grails? Musisz odwiedzić powyższą stronę.
Lista tzw. “success stories” na oficjalnej stronie Grails.
Kto jest najlepszym developerem Groovy? Sprawdź na Groovy Awards.
Znacie Try Ruby!? Jeśli tak to czas na Groovy Live, co prawda w chwili obecnej po chińsku ale w niczym to nie przeszkadza
ROOT application context w aplikacji Grails
Pisząc ostatnio aplikacje w Grails, stanąłem przed problemem zmiany kontekstu aplikacji z domyślnego na ROOT, czyli chciałem aby moja aplikacja uruchamiała się po wpisaniu adresu serwera i portu, bez konieczności podawania specjalnej nazwy kontekstu. Zadanie wydawałoby się proste, mógłbym się bawić w konfigurowanie aplikacji w kontenerze w którym uruchamiałem aplikację, jednak chciałem to zrobić w sposób zalecany przez twórców Grails (wtedy nie wiedziałem, że tak ciężko będzie znaleźć informację na ten temat).
Po dość uciążliwym googlowaniu natrafiłem na rozwiązanie. Okazało się, że ustawienie kontekstu aplikacji sprowadza się do zdefiniowania odpowiedniego wpisu w pliku Config.groovy:
W ten oto sposób możecie ustawić kontekst aplikacji na tzw. ROOT.
Dziwi mnie fakt, że dokumentacja Grails nie informuje o tym, moim zdaniem użytecznym parametrze, ja odnalazłem informację o nim w jednym z wpisów w dedykowanym Grails’om systemie obsługi zgłoszeń.
Dodam jeszcze, że w chwili pisania tego wpisu Google pokazuje tylko 123 wyniki dla zapytania “grails.app.context”, widać więc, że rozwiązanie to jest mało znane.
URL mapping w Grails
Dzisiaj będzie szybko aczkolwiek treściwie
Podczas pisania aplikacji w Grails niejednokrotnie pojawia się potrzeba zmienienia mapowania URLi. Mapowanie takie definiujemy w pliku UrlMappings w katalogu conf naszej aplikacji. Plik taki ma początkowo następującą postać:
static mappings = {
“/$controller/$action?/$id?”
{
constraints {
// apply constraints here
}
}
}
Załóżmy jednak, że chcielibyśmy aby pod następującą ścieżką:
Była dostępna strona która będzie rozpoznawana za pomocą parametru id.
Mapowanie takie możemy zdefiniować za pomocą następującego wpisu w pliku UrlMapping:
{
controller = “main”
action = “showPage”
constraints {
// apply constraints here
}
}
Mapowanie to sprawi, że po wywołaniu adresu kończącego się na /site/home zostaniemy przekierowani do kontrolera o nazwie main (nazwa klasy to MainController) i zdefiniowanej w nim akcji showPage. Z poziomu akcji możemy pobrać identyfikator strony, uczynimy to w następujący sposób:
[pageInstance: Page.findByPageId(params.id)]
}
Jak widać w powyższym kodzie, parametr id zdefiniowany w mapowaniu URL’a będzie dostępny w params pod tą samą nazwą. W ten sposób pobierzemy stronę której parametr pageId jest równy home gdyż taka właśnie wartość odpowiada naszemu parametrowi id.
Dodatkowo w sekcji constraints możemy zdefiniować warunki dla których nasz URL będzie mapowany, np.:
{
controller = “main”
action = “showPage”
constraints {
id(matches:/[A-Z]{5}/)
}
}
Dodanie id(matches:/[A-Z]{5}/) do bloku constraints spowoduje, iż jako parametr id podane będą mogły być wartości spełniające wyrażenie regularne, w tym wypadku identyfikator id musi się składać z pięciu liter z których dopuszczalne to A-Z.
Ostatnia ważna rzecz przy mapowaniu URLi to zdefiniowanie parametru będącego częścią URL’a jako parametru opcjonalnego:
{
controller = “main”
action = “showPage”
constraints {
}
}
Zmieniliśmy tutaj ciąg znaków “/site/$id” na “/site/$id?“, dodanie pytajnika oznacza, że parametr ten jest opcjonalny. Niezależnie od tego czy go podamy, czy też nie to zostaniemy przekierowani do akcji showPage w kontrolerze MainController.
Grails - walidacja danych
Pisząc aplikacje niejednokrotnie spotykacie się z koniecznością sprawdzania poprawności wprowadzonych danych, dane te weryfikowane są pod względem długości, zgodności z wzorcem lub wartością w innym polu, czy też samego sprawdzenia czy zostały wprowadzone.
Nie powinien więc Was dziwić fakt, że i Grailsy posiadają obsługę walidacji danych, a jaka jest to obsługa dowiecie się w tym wpisie
Walidacja w Grailsach jest definiowana per klasa modelu, oznacza to w praktyce, że Wasza walidacja musi zostać zdefiniowana w klasach modelu, a dokładniej za pomocą statycznego pola o nazwie constraints.
Na początek zdefiniujmy walidację dla pól w aplikacji zapisującej notki, która była przedstawiona w jednym z poprzednich przykładów:
Jak widać w powyższym przykładzie, dodanie walidacji pól jest sprawą stosunkowo prostą.
Efekt dodania walidacji sprawdzamy poprzez uruchomienie aplikacji i przejście do ekranu dodania nowej notki, uruchamiamy więc aplikację (komenda grails run-app) i przechodzimy do strony pod domyślnym adresem http://localhost:8080/notes/note/create, a następnie klikamy na przycisk “Create”.
Waszym oczom powinna się ukazać następująca strona:

Oczywiście walidator sprawdzający czy wpisano wartość w określone pole to nie jest jedynym dostępnym walidatorem, w dokumentacji do Grailsów można znaleźć o wiele więcej gotowych walidatorów, w tym:
- numeru karty kredytowej
- emaila
- zgodności z wzorcem
- sprawdzający długość wpisanej wartości
- i wiele, wiele innych…
Dostępność licznych walidatorów nie oznacza oczywiście, że nie możemy tworzyć swoich własnych, poniżej przedstawiam sposób jak sprawdzić wprowadzone dane za pomocą własnego kodu walidującego:
Różnica między powyższym kodem a przedstawionym wcześniej, polega na dodaniu dodatkowej walidacji pola title. Niestandardowy walidator który wprowadziłem został zaimplementowany przy pomocy domknięć (closures). Zmienna it zawiera wartość pola title, ponieważ chciałem aby wszystkie notatki miały od chwili obecnej tytuł zaczynający się od ciągu znaków “Notatka”, stąd też wykorzystałem metodę klasy String o nazwie startsWith, która to sprawdza czy wartość przypisana do zmiennej typu String zaczyna się od podanego w argumencie ciągu znaków.
Dobra, teraz czas sprawdzić czy nasz walidator działa, uruchamiamy ponownie aplikację i wprowadzamy nieprawidłowe dane:

I proszę, efekt zgodny z oczekiwaniami, tytuł notatki nie zaczyna się od ciągu znaków “Notatka” i dlatego też nie możemy zapisać danych. Zmienimy teraz tytuł na “Notatka pierwsza”:

Notatka została utworzona! Walidator działa!
Na koniec dla tych którzy zaspali prawie cały zeszły tydzień. SpringSource czyli firma stojąca za znanym wszystkim frameworkiem Spring kupiła G2One, firmę świadczącą usługi konsultingowe związane z Groovym i Grails. Więcej informacji na ten temat znajdziecie tutaj. Oj będzie się działo!
Grails - wprowadzenie
Zapewne część z Was zna przynajmniej ze słyszenia Ruby on Rails. RoR jest frameworkiem, który zdobył uznanie i popularność dzięki świeżemu podejściu do tworzenia aplikacji webowych. Cechą charakterystyczną RoR jest przedkładanie konwencji nad konfigurację, sprowadza się to do tego, że prawie cała struktura aplikacji tworzona jest w oparciu o pewną z góry założoną hierarchię, dzięki temu programista poświęca zdecydowanie mniej czasu na zajmowanie się projektowaniem i konfigurowaniem aplikacji, zyskując w zamian czas na tworzenie właściwego kodu, który ma realizować pewne założenia biznesowe. O samym Ruby on Rails przeczytacie więcej tutaj, ja natomiast zajmę się innym frameworkiem, który wzorowany jest na RoR, a napisany został w Groovym, są nim tytułowe Grailsy.
Grailsy, to podobnie jak Rails’y framework webowy podczas tworzenia którego przewodnią myślą było hasło “Convention over Configuration”.
Dzieki temu Grailsy umożliwiają szybkie tworzenie aplikacji, duża część aplikacji jest automatycznie generowana, a programista jest jedynie zmuszony dostarczyć model danych na podstawie którego zostanie wygenerowana warstwa prezentacji oraz kontrolery.
Grailsy jednak w przeciwieństwie do Ruby on Rails powinny być bliższe programistom języka Java, powodów jest tutaj kilka, wśród nich na uwagę zasługuje fakt, iż zostały napisane w Groovym, a więc języku skryptowym stworzonym z myślą o JVM, integrują się one również mocno ze sztandarowymi frameworkami Javy, a mianowicie Springiem i Hibernate, integracja ta pozwala programistom Java na wykorzystanie posiadanych umiejętności i łatwiejszy start z Grailsami.
Zalet Grailsów jest wiele (wady też się znajdą :P), najlepiej jednak będzie poznać je w praktyce.
Utwórzmy więc pierwszą prostą aplikację, aplikacja ta pozwoli na wprowadzanie notatek przy pomocy interfejsu webowego. Aby przystąpić do działania należy pobrać Groovy’ego i Grailsy, a następnie je zainstalować. Ja proponuję pobrać obie paczki w wersji spakowanej, bez instalatora. Instalacja sprowadzi się wtedy do rozpakowania paczek oraz zdefiniowania zmiennych środowiskowch GROOVY_HOME i GRAILS_HOME.
Gdy już zainstalujecie Groovy i Grails, należy sprawdzić czy są one widoczne w systemie, w tym celu wpiszcie następujące komendy w wierszu poleceń:
Aby sprawdzić wersję Groovyego:
U mnie Groovy wypisał na konsoli:
To znak, że jest widoczny w systemie
Aby sprawdzić wersję Grailsów:
Tu trochę więcej informacji:
Licensed under Apache Standard License 2.0
Grails home is set to: C:\Progs\grails\grails-1.0.3
No script name specified. Use ‘grails help’ for more info or ‘grails interactive’ to enter interactive mode
Jeśli udało Wam się wykonać obie komendy to możecie przystąpić do napisania aplikacji:
1. Tworzymy strukturę projektu wpisując:
gdzie notes to nasza nazwa aplikacji, po wykonaniu komendy zostanie utworzona struktura projektu (w kolejnym wpisie zostanie ona bliżej opisana).
2. Utwórzmy pierwszą klasę, która będzie odpowiadała pojedyńczej notatce (aby to zrobić musicie znajdować się w katalogu aplikacji):
Po jej wykonaniu zobaczycie mniej-więcej takie logi:
Licensed under Apache Standard License 2.0
Grails home is set to: C:\Progs\grails\grails-1.0.3
Base Directory: D:\projects\notes
Note: No plugin scripts found
Running script C:\Progs\grails\grails-1.0.3\scripts\CreateDomainClass.groovy
Environment set to development
[copy] Copying 1 file to D:\projects\notes\grails-app\domain
Created Domain Class for Note
[copy] Copying 1 file to D:\projects\notes\test\integration
Created Tests for Note
Nasza klasa jest już gotowa!
3. Dodajmy pola do utworzonej właśnie klasy:
Jest to bardzo prosta klasa, notka będzie zawierała jedynie tytuł i opis.
4. Wygenerujmy pozostałe części aplikacji używając do tego klasy z modelem:
Po zakończeniu wykonania komendy pojawią się logi:
Generating controller for domain class Note …
Finished generation for domain class Note
To znak, że Grailsy zakończyły generację kontrolera i widoków, Wasza aplikacja jest już gotowa!
Czas ją uruchomić:
Wykonanie komendy objawi się podobnymi do poniższych logami:
Licensed under Apache Standard License 2.0
Grails home is set to: C:\Progs\grails\grails-1.0.3
Base Directory: D:\projects\sample\notes
Note: No plugin scripts found
Running script C:\Progs\grails\grails-1.0.3\scripts\RunApp.groovy
Environment set to development
[groovyc] Compiling 2 source files to C:\Documents and Settings\radek\.grails\1.0.3\projects\notes\classes
[copy] Copying 1 file to C:\Documents and Settings\radek\.grails\1.0.3\projects\notes
Running Grails application..
2008-11-04 20:50:50.337::INFO: Logging to STDERR via org.mortbay.log.StdErrLog
2008-11-04 20:50:51.603::INFO: jetty-6.1.4
2008-11-04 20:50:51.743::INFO: No Transaction manager found - if your webapp requires one, please configure one.
2008-11-04 20:50:51.056:/notes:INFO: Set web app root system property: ‘notes-development-0.1′ = [D:\projects\sample\no
tes\web-app\]
2008-11-04 20:50:51.056:/notes:INFO: Initializing log4j from [file:C:\Documents and Settings\radek/.grails/1.0.3/projec
ts/notes/resources/log4j.properties]
2008-11-04 20:50:51.071:/notes:INFO: Initializing Spring root WebApplicationContext
[0] spring.GrailsWebApplicationContext Refreshing org.codehaus.groovy.grails.commons.spring.GrailsWebApplicationContext@
3534c1: display name [org.codehaus.groovy.grails.commons.spring.GrailsWebApplicationContext@3534c1]; startup date [Tue N
ov 04 20:50:53 CET 2008]; parent: org.springframework.web.context.support.XmlWebApplicationContext@1fe1e26
[0] spring.GrailsWebApplicationContext Bean factory for application context [org.codehaus.groovy.grails.commons.spring.G
railsWebApplicationContext@3534c1]: org.springframework.beans.factory.support.DefaultListableBeanFactory@1da5362
2008-11-04 20:50:56.241:/notes:INFO: Initializing Spring FrameworkServlet ‘grails’
2008-11-04 20:50:57.397::INFO: Started SelectChannelConnector@0.0.0.0:8080
Server running. Browse to http://localhost:8080/notes
W powyższych logach widać, iż aplikacja uruchamiana jest za pomocą wbudowanego w Grailsy kontenera servletów Jetty, podczas startu aplikacji inicjalizowany jest również kontekst Springa, widać to w tej lini:
Spring springiem ale czas zobaczyć naszą aplikację, uruchamiamy w przeglądarce podany na końcu link: http://localhost:8080/notes.
I oto co widzimy:

Jest to domyślny i zarazem główny ekran aplikacji, wyświetla on listę dostępnych kontrolerów, kliknijmi na NoteController i następnie na opcję “Add Note”, a znajdziemy się na ekranie dodawania notki:

Po uzupełnieniu pól klikamy “Create” i naszym oczom ukazuje się lista stworzonych notek z poziomu której możemy przeglądać szczegóły poszczególnych notek (poniżej ekran szczegółów notki):

Właśnie utworzyłeś swoją pierwszą notkę za pomocą samodzielnie napisanej aplikacji w Grailsach!
Prawda, że proste i przyjemne?
Na zakończenie pozostawiam Wam rozpoznanie pozostałych podstron aplikacji, które to składają się na tzw CRUD (Create, Read, Update, Delete) i pozwalają nie tylko na dodawanie i wyświetlanie listy notatek, ale również na ich aktualizowanie i usuwanie.
Wybór nowego języka programowania
Od pewnego czasu myślałem o poznaniu kolejnego języka programowania, przez ostatnie miesiące przyglądałem się kilku: Scala, Ruby, Groovy, Python, C#. Starałem się specjalnie nie szukać języka, który miałby swoją implementację na platformie Java, jednak istnienie takiej implementacji mimo wszystko było istotnym atutem, stąd też początkowy zbiór ograniczyłem do języków powiązanych z platformą Java: Scala, Ruby (JRuby), Groovy, Python (Jython).
Po tym pierwszym etapie selekcji przyszedł czas na przeczytanie artykułów i różnych tutoriali dotyczących wcześniej przedstawionych języków. O ile składnia Groovy’ego jest bardzo zbliżona do Javy, a właściwie to w wielu przypadkach można przekopiować kod Javy do pliku z rozszerzeniem .groovy i uruchomić bez dodatkowych modyfikacji, o tyle poznanie składni pozostałych języków wymagało większego wysiłku, dzięki temu Groovy zapunktował u mnie jako język na naukę którego będę musiał poświęcić mniej czasu ![]()
Trzeci etap podejmowania wyboru skupiła się na pytaniu: “Czy język ma być dynamiczny?”, po zachwalaniu przez Wiktora Gworka języków dynamicznych postanowiłem dać szansę trójce: Groovy, Ruby (JRuby), Python (Jython).
Wybór już znacznie uproszczony, zostało 3 z 5 ![]()
Czas na dalszą eliminację… nauka nowego języka powinna być przyjemna, nie jestem tradycjonalistą i zawsze jestem otwarty na nowe propozycje ale w tym wypadku chciałem używać narzędzi do których jestem przyzwyczajony i o których wiem, że są najwyższej jakości, a gwarancję taką dawał mi IntelliJ IDEA, do którego dostępne są dwie firmowane przez JetBrains wtyczki: JetGroovy oraz IntelliJ Ruby Plugin, wtyczka do Pythona również istnieje niestety nie jest ona regularnie aktualizowana… w ten sposób ograniczyłem wybór do Groovy’ego i Ruby’ego.
Nadszedł czas na porównanie frameworków do tworzenia aplikacji webowych, zapewne wszyscy wiedzą, że w świecie Ruby’ego królują Railsy, podobnie jest w przypadku Groovy’ego dla którego głównym frameworkiem webowym są wzorowane na Railsach Grailsy. Obydwa frameworki cechują się podejściem convention over configuration, jednakże cechą która zadecydowała wyborze Grails‘ów jest ich powiązanie ze Spring‘iem i Hibernate. Powiązanie to nie było dla mnie bez znaczenia, oba frameworki są mi znane, oba też stanowią niekwestionowany standard w swoich kategoriach.
Jak więc widzicie, w sposób mniej lub bardziej słuszny wybrałem język za którego rozpoznanie zabrałem się ostatnio, jest nim Groovy. Aktualnie kończę czytać świetną książkę Programming Groovy (zachęcam do wypożyczenia z biblioteczki Polish JUG), której recenzję umieszczę w najbliższym czasie, zapoznałem się również wstępnie z Grails’ami, a nawet stworzyłem swoje pierwsze aplikacje webowe napisane w Grails!
Na koniec chciałem jeszcze dodać, iż spotkała mnie miła niespodzianka dotycząca NetBeans, czyli drugiego środowiska które używam, otóż powstaje plugin do NetBeans pozwalający na tworzenie aplikacji w Groovy i Grails, więcej szczegółów na jego temat znajdziecie na oficjalnej stronie wtyczki.





