Przejdź do głównej zawartości

JRuby on Rails + NetBeans + GlassFish +… Microsoft SQL Server 2008 (cz. 3)

To już ostatnia część tutoriala. W poprzednich częściach przygotowaliśmy środowisko pracy oraz utworzyliśmy bazy danych dla naszego projektu. Wykorzystując NetBeans wygenerowaliśmy również wstępną formę projektu aplikacji Rails i sprawdziliśmy z powodzeniem, czy jej uruchomienie jest możliwe.

Teraz zajmiemy się rozbudową przykładowej aplikacji (nie ukrywam, że wygenerowany przez nas w części drugiej projekt był po prostu pusty…). Właściwie, to powinniśmy podejść do sprawy fachowo, czyli zaprojektować aplikację w oparciu o wzorzec MVC, jednak do naszych potrzeb użyjemy generatora rusztowań – będziemy po prostu “scaffoldowali” (scaffold – oznacza m. in. szkielet lub rusztować).

Otwórzmy naszą aplikację-projekt Rails (SimpleApp) w środowisku NetBeans. Możemy jeszcze raz sprawdzić, czy wszystko gra (czyli działa). Jeśli tak, to kontynuujemy.

W panelu Projects odnajdujemy nazwę naszego projektu (SimpleApp) i klikamy w nią prawym przyciskiem myszy. Z menu kontekstowego wybieramy opcję Generate, co powoduje pojawienie się okienka generatorów Rails. Jako typ generatora (lista rozwijalna) wybieramy scaffold. Teraz decydujemy (ależ nieprofesjonalne podejście, no no!), do czego będzie służyć nasza przykładowa aplikacja. Niech więc to będzie prosta aplikacja WWW przechowująca dane o filmach DVD: tytuł filmu, imię i nazwisko reżysera oraz liczbę płyt w pudełku. Biorąc te dane pod uwagę wypełniamy okienko jak na rysunku poniżej:

Nazwa modelu w naszym przypadku to Video (koniecznie liczba pojedyncza!), a atrybuty to tytuł (title) oraz reżyser (director) typu napisowego (string) oraz liczba płyt (krótko count) typu liczbowego całkowitego. Kolejne pary atrybut:typ oddzielane są spacjami. Generator rusztowania można uruchomić “na poważnie” lub w trybie przeglądowym (bez zmian w projekcie), można również za pomocą tego generatora usunąć nieudane rusztowanie – zamiast opcji Generate zaznaczamy Destroy. Wygenerujmy więc nasz szkielet na poważnie – kliknijmy OK. Po względnie krótkiej chwili środowisko zgłosi nam udane zakończenie pracy nad rusztowaniem – możemy się rozejrzeć po projekcie i wyszukać poszczególne elementy typu model, kontroler i widok. My jednak od razu zmierzać będziemy do uruchomienia i wdrożenia naszej aplikacji.

Najpierw musimy nakazać frameworkowi Rails utworzenie odpowiednich tablic w bazie danych (podczas tworzenia aplikacji pracujemy na wersji deweloperskiej bazy danych - simple_development). Proces ten w fachowym języku JRoR nazywany jest migracją – Rails automatycznie wygeneruje odpowiednie instrukcje SQL-DDL konieczne do utworzenia tabel oraz połączy się z SQL Serverem i wyda mu odpowiednie polecenia. Migrację do aktualnej wersji bazy danych przeprowadzamy – jak większość operacji – klikając prawym przyciskiem myszy w nazwę projektu i wybierając z menu kontekstowego Migrate Database –> To Current Version. Jeśli proces migracji przebiegnie w sposób udany, zapis logu w panelu u dołu okna głównego NetBeans będzie zawierał informację, że utworzono tablicę videos (zauważcie, że użyta została liczba mnoga – automatycznie przez Rails!). Aby przekonać się, że to prawda, należy udać się do panelu Services i rozwinąć połączenie z naszą bazą danych – przy okazji dowiemy się, że Rails wygenerował tablicę zawierającą więcej informacji, niż sami chcieliśmy, m. in. klucz główny i pola dat utworzenia i modyfikacji rekordu:

No więc wyobraźcie sobie, że to już wszystko! Właśnie wygenerowaliście aplikację Rails! Pozostaje już tylko ją uruchomić i przetestować jej działanie w przeglądarce (w naszej konfiguracji podajemy adres http://localhost:3000/videosvideos to jednocześnie nazwa tabeli, kontrolera i widoku z nim skojarzonego).

Oto aplikacja po pierwszym uruchomieniu:

Klikamy New Video i wprowadzamy dane filmu:

Klikamy przycisk Create i film zostaje zarejestrowany – najpierw widzimy informację o tym fakcie:

a następnie, klikając Back, wracamy do strony głównej:

Podejrzewam, że działań związanych z opcjami Show, EditDestroy nie trzeba pokazywać na przykładach :-)

Jeśli nasza aplikacja pomyślnie przejdzie testy, możemy ją wdrożyć na serwerze produkcyjnym. W tym celu musimy zmienić konfigurację aplikacji z development/test na production. Na początku zmienimy konfigurację projektu. Za pomocą prawego przycisku myszy wybierzemy z menu kontekstowego projektu opcję Properties. W okienku, które się pojawi, w opcji Rails environment z listy rozwijalnej wybieramy production i zatwierdzamy klikając OK:

Następnym krokiem jest migracja bazy danych – tym razem jednak musimy wykorzystań bazę simple_production. Ponieważ ta baza jest skojarzona właśnie z środowiskiem produkcyjnym, nie musimy nigdzie podawać jej nazwy, jedynie konieczne będzie przedefiniowanie zmiennej środowiskowej RAILS_ENV podczas migracji.

Migrację przeprowadzimy trochę inaczej. Otóż po kliknięciu prawym przyciskiem myszy w nazwę projektu, z menu kontekstowego wybieramy Run/Debug Rake Task. W okienku, które pojawiło się po wybraniu tej opcji, w polu Parameters wpisujemy:

RAILS_ENV=production

i uruchamiamy migrację (klikamy Run):

Jeśli wszystko się uda, to powinniśmy mieć utworzoną tablicę videos w bazie simple_production:

Dla sprawdzenia poprawności powyższych operacji możemy jeszcze raz uruchomić naszą aplikację – tym razem w trybie produkcyjnym – na testowym serwerze Glassfish (glassfish-gem) z poziomu NetBeans. Jeśli poprzednio, w środowisku development, wprowadziliśmy do bazy jakieś dane i ich nie usunęliśmy, to teraz żadnych danych nie zobaczymy, ponieważ pracujemy na innej bazie. Myślę, że jest to w miarę zrozumiałe :-)

Najwyższy czas wdrożyć naszą palikację w środowisku produkcyjnym na niezależnym (czyli nie związanym z naszym środowiskiem pracy – NetBeans) serwerze WWW. Jak wspominałem w części pierwszej, wybrałem potężny serwer GlassFish v3, w którym skonfigurowałem również niezależne od NetBeans środowisko JRuby on Rails (jak je przygotować i połączyć z GlassFish’em poczytać możecie w aneksie do tutoriali).

Po pierwsze, zakończmy NetBeans, zapisując wszystkie dotychczas niezapisane zmiany.

Folder zawierający naszą aplikację – zwykle jest to folder o nazwie takiej, jak nazwa aplikacji i znajduje się w domyślnym folderze projektów NetBeans (jeśli nie wskazaliśmy innego podczas tworzenia projektu) - możemy teraz skopiować do folderu zawierającego aplikacje WWW przeznaczone do wdrożenia w warunkach produkcyjnych. Z wielu względów zalecam takie rozwiązanie, ponieważ nic nie stoi na przeszkodzie, żeby wdrażać aplikację umieszczoną w folderze roboczym i wiele osób tak może robić. Jestem jednak zwolennikiem trzymania osobno wersji deweloperskiej (rozwijanej) i wersji produkcyjnej. Zresztą narzuca ten sposób myślenia sama architektura Rails i filozofia tego frameworka. A poza tym, po ponownym uruchomieniu NetBeans i przed rozpoczęciem dalszych prac nad naszą aplikacją na pewno przywrócimy ją do konfiguracji typu development – ze względów oczywistych (odrębna baza danych, możliwość zmian kodu “w locie” itp.)

W przypadku mojej konfiguracji folder wdrożeniowy to:

C:\Developing\RailsWWWRoot

Co prawda nazwa folderu “Developing” wskazuje jednoznacznie, jakie jest jego przeznaczenie, jednak – wierzcie mi – podfolder “RailsWWWRoot” przeznaczony jest wyłącznie do testowania aplikacji produkcyjnych.

Kopiujemy więc naszą aplikację do tego folderu i uruchamiamy konsolę (wiersz polecenia). Oczywiście moglibyśmy wdrażać aplikację z poziomu konsoli zarządzania serwerem GlassFish v3 (poprzez przeglądarkę WWW) ale… ta operacja powoduje występowanie błędów (zresztą zgłoszonych już twórcom GlassFish). Na szczęście w konsoli wszystko gra :-)

Na poniższym obrazku widzimy kolejne polecenia wydawane w celu wdrożenia aplikacji:

Najpierw sprawdzamy nazwę folderu z naszą aplikacją (po prostu dir). Następnie – jeśli nie zrobiliśmy tego wcześniej lub jeśli serwer nie uruchamia się automatycznie wraz ze startem systemu – uruchamiamy serwer GlassFish:

asadmin start-domain

I po uruchomieniu serwera wdrażamy naszą aplikację, wskazując jednocześnie serwerowi, że ma działać w trybie produkcyjnym:

asadmin deploy --property jruby.rackEnv=production SimpleApp/

Jeśli nie będzie żadnego komunikatu o błędzie, nasza aplikacja jest wdrożona i możemy ją testować:

Zauważmy, że adres WWW naszej aplikacji to teraz:

Adres portu 8081 zależy od Waszej konfiguracji serwera.

Jeśli aplikacja Wam się znudzi lub nie spełnia oczekiwań/założeń, to można ją odinstalować za pomocą polecenia

asadmin undeploy SimpleApp/

co pokazane zostało na rysunku poniżej:

I w ten sposób trzecia i ostatnia część tutoriala dobiegła końca. Mam nadzieję, że przyda się on komukolwiek i ktokolwiek go przeczyta, ponieważ istnieje masa podobnych kursów :-) Liczę jednak na Wasze opinie i uwagi, ponieważ mój tutorial jest oczywiście wyjątkowy, choćby za względu na nietypowe środowisko pracy (zwykle wszyscy piszą o natywnym Ruby, systemie baz danych MySQL czy prostym SQLite, niedziałającym koniec końców wdrażaniu na popularnych serwerach WWW itp.). Środowisko nietypowe, ale działające! Oczywiście jeśli ktoś nie chce pracować w systemach Windows, może po prostu zmienić SQL Server 2008 na MySQL (ostatnio zresztą znów polubiłem ten serwer :-)) czy PostgreSQL.

Zachęcam do śledzenia mojego bloga na bieżąco, ponieważ będę starał się wracać do tematyki Rails, choćby już wkrótce – muszę przecież napisać parę słów o konfiguracji serwera GlassFish v3 do współpracy z JRuby on Rails oraz SQL Serverem 2008.

Dziękuję za uwagę!

Komentarze

Popularne posty z tego bloga

Niesamowicie prosty czujnik zmierzchowy.

Tym razem zero programowania, będzie natomiast nostalgiczno-wspomnieniowy układzik, lekko zmodyfikowany.
Otóż kilka dni temu rozmawialiśmy w gronie znajomych o różnego rodzaju czujnikach zmierzchowych i czujnikach ruchu. Ponieważ należę do tych wariatów, co to hołdują jeszcze owej przestarzałej i kompletnie odrealnionej dziś zasadzie: "po co kupować, gdy można zrobić", stwierdziłem, że poskładam takie coś (czujnik zmierzchowy; sensor ruchu faktycznie lepiej nabyć, choćby ze względu na rozmiary ;)) i być może podłączę do jakiegoś mikrokontrolera. Przypomniało mi się też przy okazji, że znalazłem ostatnio w elektronicznych śmieciach stary fotorezystor (dla niewtajemniczonych: element zmieniający rezystancję, czyli opór elektryczny, pod wpływem działania strumienia światła) RPP130, jeden z kilku pozostałych po montowanych wieki temu układach tranzystorowych do zdalnego sterowania pracą urządzeń za pomocą latarki... No OK, nie było to specjalnie rozbudowane zdalne sterowanie ;)

Android i zewnętrzny moduł GPS

Od kilku dni jestem w posiadaniu smyrfona z Androidem 4.1.1 na pokładzie. Kwestie związane z wyborem systemu roztrząsałem już na G+, a ten artykuł tutaj ma konkretny temat, więc nie będę wyjaśniał po raz n-ty. Po prostu zwyciężyły popularność i ekosystem oraz przywiązanie do produktów sieciowych Google. Mniejsza.

Zbliża się sezon urlopowy :-) Moi podopieczni już mają wakacje, a ja wyjeżdżam wkrótce. W każdym bądź razie wakacje to podróże - samochodem, rowerem, na piechotę, żaglówką, motorówką, samolotem... Zaawansowane urządzenia mobilne przyzwyczaiły nas już do usług lokalizacyjnych, z których najważniejszą jest GPS (na dalszym planie mamy A-GPS, lokalizacje w oparciu o sieci WiFi itp.). Często korzystamy z programów, które w coraz ciekawszy sposób wiążą naszą lokalizację, pobraną z np. GPS-a, z przeróżnymi danymi, nieraz ocierając się o AR.
Każdy współczesny smartfon, a przynajmniej znakomita ich większość, wyposażona jest we wbudowany odbiornik sygnału lokalizacyjnego (GPS, GLONASS…

Po co mi to całe Arduino?

Oczywiście tytuł ma być jedynie prowokacją. Chociaż nie do końca - artykuł jest właśnie poświęcony pracy w Arduino IDE z mikrokontrolerami, ale bez płytek Arduino.
Czym jest Arduino - wiemy wszyscy, zarówno początkujący fani programowania elektroniki, jak i zaawansowani mikrokontrolerowcy. Jeśli jednak nie do końca wiemy, zachęcam do odwiedzenia strony domowej projektu (link 5 na końcu artykułu) oraz zerknięcia np. w poradnik (link 4).

Jakiś czas temu, przełamując się i zmieniając zdanie ("o 180 stopni" ;-)) nabyłem sobie Arduino Leonardo, głównie w celu jego "obwąchania" i zapoznania się z bogatym zbiorem bibliotek dostępnych dla tej platformy. Zgoda, różne biblioteki są dostępne niezależnie od Arduino, ale i tak się zdecydowałem. Dlaczego Leonardo? Otóż miałem ochotę przyrządzić dwie pieczenie na jednym ogniu - mieć Arduino i przetestować ATmegę 32u4. Dziś doskonale zdaję sobie sprawę, że żeby pobawić się Arduino nie trzeba go w ogóle posiadać... Ale po kolei.

Pi…