Jak poznawać nowy język programowania? (w/g Rafała)

Często czytam wypowiedzi czy artykuły różnych programistów, stanowiące sprawozdania z procesu poznawania jakiegoś nowego dla nich języka programowania. Metody poznawcze bywają różne. Wielu programistów podchodzi do problemu analitycznie - wgłębiają się w każdy szczegół języka, analizują jego składnię, znajdują niedoróbki i niekonsekwencje, badają efektywność różnych konstrukcji, zastanawiają się nad ich przydatnością i tak dalej. I jest to podejście bardzo słuszne w swym założeniu, pozwalające na rzeczywiste zgłębienie języka. Ale nie sposób też nie zauważyć, że jest to podejście czasochłonne, a zwykle programiści - jeżeli poznawanie nowego języka nie jest ich zajęciem zasadniczym - cierpią na chroniczny brak czasu, ścigani przez terminy „na wczoraj”.
Jedną z moich informatycznych myśli przewodnich jest „rozwój poprzez poznawanie jednego nowego języka programowania na rok”. Gdybym stosował metodę przedstawioną wcześniej, prawdopodobnie miałbym problemy z wyrobieniem się w czasie. Mój sposób na poznawanie języka jest trochę inny. Opiera się na kilku założeniach: poznawanie języka poprzez programowanie w nim, czytanie szczegółowej dokumentacji w miarę potrzeb (na początku używam ogólnie dostępnej literatury zarówno drukowanej, jak i elektronicznej), rozpoznanie i wykorzystywanie bibliotek dostępnych dla danego języka. Oczywiście żeby zacząć pisać jakiś program, muszę mieć pomysł albo jakiś problem do rozwiązania. Najlepszym rodzajem „problemu do rozwiązania” jest zlecenie, z którym związane są konkretne terminy i - co nie jest bez znaczenia - równie konkretne pieniądze (tzw. czynnik motywujący). No ale to już inna sprawa.
Wracając do zgłębiania tajników języka - po prostu zaczynam pisać program. I już. Potem jest następny i jeszcze jeden, potem analizuję kod tych programów, wyłapuję błędy (umiem to zrobić, ponieważ zwykle w miarę pisania kolejnych programów moja znajomość języka zwiększa się - naturalna rzecz, jak myślę), poprawiam je, zapamiętując przy okazji różne techniki i metody charakterystyczne dla danego języka. W ten sposób poznałem m. in. Javę i C#, po części też C++, natomiast Pascala (tak, dawne czasy) nauczyłem się metodą wspomnianą na samym początku tego artykułu.
Czy mój sposób jest doskonały? Oczywiście, że nie. Choćby dlatego, że mogą mi umknąć np. ograniczenia pewnych elementów języka, szczegóły konstrukcyjne środowiska (nie IDE!) języka, różne szczegóły techniczne typu jakie wyjątki rzucają metody danej klasy. Nie jest to też sposób akademicki, który zakładałby poznawanie języka poprzez analizowanie jego dokumentacji (składnia, słowa kluczowe, zakresy zmiennych itp. a potem dopiero programowanie - tak uczyłem się wspomnianego Pascala). Mój sposób jest jednakowoż szalenie wygodny i wydajny (efektywny), ponieważ skupiam się na wykorzystaniu języka (narzędzia!) do rozwiązania konkretnego problemu czy grupy problemów. Po tych doświadczeniach mogę podjąć decyzję, czy dalej będę brnął w ten język, czy też nie nadaje się on do moich celów. A, i oczywiście staram się nie dopasowywać problemu do narzędzia, lecz odwrotnie: wybieram narzędzie nadające się najbardziej do rozwiązania danego problemu (np. dostępność i stopień zaawansowania bibliotek, dodatki, pluginy, szybkość pisania programu itp.).
A jak to jest z początkującymi, czyli ludźmi, którzy przygodę z programowaniem dopiero zaczynają? Niestety, muszą przede wszystkim poznać podstawowe pojęcia związane ze sztuką programowania i oczywiście zaznajomić się z komputerem jako urządzeniem programowalnym... Dlaczego „niestety”? Chyba dlatego, że jest to często najtrudniejszy etap nauki programowania, w którym najczęściej ludzie „wymiękają”, szczególnie ci, którzy myślą, że programy powstają jak obrazki w Paint`cie :-) Ale jest to wiedza dla nas niezbędna, „niestety” ;-)

Jaka jest geneza tego artykułu... Otóż ma to być kolejna próba odpowiedzi na pytanie: „Jak uczyć się programowania w danym języku?”. No to przedstawiłem moją propozycję odpowiedzi. A jaki język wybrać na początek? Myślę, że chyba coś klasycznego, jak C++ czy Java (patrząc też pod kątem popularności języków). Jednak zawsze znajdzie się jakieś "ale", tyle, że to jest temat na kolejny artykuł.

Krótkie podsumowanie, czyli "w odpowiedzi na komentarz..."

Przyzwyczaiłem się już do sytuacji, że pod moimi wpisami w blogach nie ma komentarzy. Wynika to albo z braku zainteresowania Internautów moimi wypocinami, albo z nikłej kontrowersyjności tekstów (nikogo nie wnerwiam). Stawiam na to pierwsze - przypomnina mi się koszulka z napisem: "Nobody reads your blog!" ;-) Jednak czasem komentarz się pojawia, a ja go całkowicie nie zauważam (patrz: pierwsze zdanie o przyzwyczajeniu). Muszę pogrzebać w konfiguracji bloga - może jest jakieś informowanie mailem, czy coś w tym rodzaju?

Ostatnio odkryłem, że użytkownik demikaze napisał komentarz pod moim wpisem testowym, opublikowanym przez jedną z pierwszych wersji programu BlogTweetProject (był to jednocześnie mój pierwszy program napisany w Pythonie). demikaze zastanawiał się, jakie jest moje spojrzenie na Pythona, jeśli dotychczas programowałem w "klasycznych" językach, jak Java, C++ czy C#. Zastanawiał się też, od którego momentu można potraktować dany język programowania jako poważne narzędzie (czytaj: do wykorzystania w celach produkcyjnych i zarobkowych).
Postaram się teraz napisać parę słów w odpowiedzi (spóźnionej) na ten interesujący komentarz.

Python od początku bardzo mi się spodobał. Pozytywne wrażenie zrobiła na mnie jego prostota, pozwalająca na poświęcenie większej uwagi temu, co mam zrobić, a nie jak mam to zrobić. Spodobało mi się założenie, które przyjęli zapewne twórcy Pythona - żeby nie kazać programiście skupiać się na tak denerwujących rzeczach, jak ręczne przetwarzanie łańcuchów znaków, tworzenie i obudowywanie masą kodu wyszukanych struktur danych itp. Spodobało mi się również bogactwo bibliotek/pakietów/modułów zawierających kod do rozwiązywania prawie każdego problemu, jaki sobie wymyśliłem (oczywiście ostrożnie podchodząc do poważnych problemów, jak np. tworzenie zaawansowanych aplikacji typu enterprise, raczej skupiłem się na drobniejszych, przynajmniej chwilowo). Zresztą wiele rzeczy mógłbym tutaj wymieniać: świetną składnię, dyscyplinę wcięć, ułatwiającą analizę kodu, proste testy, do których nie trzeba pisać specjalnego kodu... No i do tego dochodzi jeszcze niesamowita sprawność i szybkość działania, jak na język interpretowany.

Znalazłem też kilka wad. Co prawda nie dopatrzyłem się póki co niekonsekwencji (prędzej niedoróbek),  no, może z pominięciem niektórych bibliotek - czasem są to eleganckie moduły obiektowe, czasem zbiory funkcji, a ja nie przepadam za mieszaniem różnych stylów programowania (jeśli w moich programach takie coś ma miejsce - bo nie da się wszystkiego uniknąć czy obejść - mam problemy z zasypianiem ;-)), jednak trochę "szarpie" mnie kompletnie wyluzowane podejście do obiektowości. Może będzie to bluźnierstwo, ale obiektowość w Pythonie poniekąd przypomina mi tą z Turbo Pascala 7.0 (firmy Borland, dla DOSu) - wszystko publiczne, żadnych ograniczeń... No ale ma też to swoje zalety - jak kiedyś napisał Łukasz Langa: Python zakłada, że jesteśmy inteligentnymi programistami i wiemy, co robimy. Toteż dyscyplinę w obiektowości możemy narzucić sobie sami.

Co do granicy, która przebiega między językiem-zabawką a językiem-narzędziem, cóż, chyba nie ma czegoś takiego, a przynajmniej nie jest to stabilna granica. Jeśli się okaże, że Twój projekt, czy choćby tylko jego fragmenty łatwiej i sprawniej da się zaimplementować w Pythonie, to zrób to - wyłącznie na tym zyskasz. Moje zdanie jest w tej materii niezmienne: język programowania to narzędzie, które powinniśmy umieć odpowiednio wykorzystać. Nie możemy na siłę lansować jednego języka programowania i jednego paradygmatu jako narzędzi uniwersalnych ("jeśli masz w ręku młotek, to wszystko dokoła wygląda jak gwóźdź") . Im więcej znamy języków, tym sprawniejszymi i elastyczniejszymi jesteśmy programistami. I jeśli jesteśmy PRAWDZIWYMI programistami, to nie ma mowy o rozproszeniu uwagi - nieprawdziwe jest w naszym przypadku stwierdzenie, że jak ktoś się zna na wszystkim, to tak naprawdę nie zna się na niczym.

Chwilowo dobrze się bawię Pythonem - rozwijam Kolejny Program do Blogowania!, mam zamiar skrobnąć klienta gpsd, pobawić się w oprogramowanie Wii Remote (sprawuje się świetnie - choć trzeba dużo cierpliwości, żeby zmusić cwiid do stabilnej pracy w moim 64-bitowym Ubuntu) i popróbować czegoś poważniejszego (bazy danych itp.). Zobaczymy! W każdym razie o wszystkim będę pisał na tym blogu.

Ruby on Rails i klaster po indiańsku ;-)

Zacznę od tego, że winienem wszystkim, którzy czytali mój tutorial o początkach pracy z JRuby on Rails, kilka wyjaśnień. Trochę już napisałem we wcześniejszych postach, więc tutaj tematykę rozwinę (o ile mi się uda ją rozwinąć).

Otóż zrezygnowałem z Ruby'ego implementowanego na platformie Java nie dlatego, że okazał się do bani, lecz z zupełnie innego powodu. Otóż pracując z JRuby on Rails niejednokrotnie borykałem się z problemem niekompatybilności różnych wersji gemów (głównie rack, ale i innych paczek) a to z potężnym Glassfishem, a to z jego wersją deweloperską, stworzoną specjalnie do pisania i testowania aplikacji JRoR (glassfish-gem). Pomijam oczywiście fakt, że musiałem ciągle używać JRE/JDK w wersji 1.6.0_17, podczas gdy mamy już 1.6.0_21... Ale na nowszych Glassfish 3.0 (takiego używałem) padał na kolana. Przynajmniej u mnie, ale z tego, co czytałem, nie byłem jedynym użytkownikiem z tym problemem. Wszystko to przekładało się na konieczność testowania każdej istniejącej aplikacji po uaktualnieniu Rails i innych składników, ale jakoś sobie radziłem. Kolejny element to zmiana platformy roboczej - przeszedłem na Linuksa, a w związku z tym zamieniłem świetny SQL Server 2008 na MySQL (głównie ze względu na popularność tego ostatniego). Mogłem pozostać przy SQL Serverze, ale wiązało by się to z pracą z systemem Windows na maszynie wirtualnej, co raczej nie jest wygodne, jeśli nie jest konieczne :-) Owszem, w Linuksie wszystko działa, ale oprócz potężnego Glassfisha, jednego z najlepszych serwerów w swojej klasie, mamy do dyspozycji dużo lżejszego apache'a, który - w połączeniu z mongrelem - bardzo sprawnie serwuje aplikacje RoR. No i jest najpopularniejszym serwerem WWW. Tym bardziej zacząłem skłaniać się ku serwerowi apache, że Glassfish w środowisku produkcyjnym ma sens jedynie w przypadku, gdy jest optymalnie wykorzystany (J2EE!), a nie tylko do obsługi serwisów JRoR. Stąd, mając na uwadze oszczędność mocy i nie wytaczanie działa przeciwko pchle, zmieniłem zaplecze na natywnego Ruby, serwer mongrel z pakietem mongrel_cluster i starego, poczciwego apacza.

Jednak dwóch rzeczy nie zmieniłem na pewno:

• po pierwsze zdania na temat JRuby on Rails i serwera Glassfish (tzn. że są świetnymi narzędziami); pod warunkiem, że - jak pisałem wyżej - Glassfish nie jest "stawiany" tylko dla aplikacji JRoR;
• po drugie środowiska programistycznego - nadal pracuję w NetBeans (teraz w wersji 6.9.1).

To tyle w temacie nagłej "zmiany światopoglądu" :-)

A teraz wracam do wątku zasadniczego.


Napisałem sobie na próbę aplikację Rails, która ma mi pomóc w pracy (prezentuje informację o sprawozdaniach z ćwiczeń i uczniach, którzy już je oddali, ocenach itd. itd.). Oczywiście w nowym środowisku (Ruby 1.9, Rails 2.3.9, mongrel 1.2.0.pre2, mongrel_cluster 1.0.6, MySQL, apache). I tak: z poziomu NetBeans, jak i za pomocą polecenia script/server wszystko działało idealnie. No, może nie do końca - brakowało polskich znaków, więc:

• skonfigurowałem MySQL do obsługi kodowania UTF-8 (Google i podręczniki do MySQL online)
• zainstalowałem gema magic_encoding, za pomocą którego dodałem komentarz (podobny do tego w Pythonie) na początku każdego z plików źródłowych aplikacji informujący o zastosowanym kodowaniu ("# -*- encoding: utf-8 -*-")

OK, polskie znaki ruszyły. Potem nadszedł czas na wdrożenie aplikacji w środowisku produkcyjnym. Nie będę opisywał przygód po kolei, ważne, że się udało. Ale:

• oczywiście przeczytałem instrukcję, co i jak zrobić (np. tutaj)
• dodałem parę "łatek" na sterownik dla MySQL (link) i dla mongrela (dyskusja, link, plik mongrel.rb musi być skopiowany do katalogu config/initializers aplikacji)
• napisałem własny skrypt uruchomieniowy i podpiąłem pod odpowiednie /etc/rcX.d (link)
• a potem (bo przecież nie zadziałało...) dopisałem dwie linie w pliku config/environments.rb mojej aplikacji:

Encoding.default_external="UTF-8"
Encoding.default_internal="UTF-8"

• w międzyczasie kilkukrotnie restartowałem system, bo - wyobraźcie sobie - po zrestartowaniu samego mongrela i klastra wszystko zawsze działało, a po restarcie systemu już nie (można by znaleźć rozwiązanie, ale mi się nie chciało)... 
• ile się naprzeklinałem, to moje ;-)

W każdym razie od wczoraj aplikacja wymiata. Tym samym doszedłem dokładnie do tego punktu, w którym byłem używając Glassfisha i JRoR z tym, że proces uruchamiania serwerów i samej aplikacji jest teraz dużo krótszy, no i nie ma strat mocy :-) No i (2) jest bardziej linuksowo, a o to przecież chodziło.

O dodatkach, które musiałem zastosować, żeby aplikacja produkcyjna ruszyła, napisałem głównie dla tych, którzy czytali mój tutorial i chcieliby równie łatwo wdrażać aplikacje w natywnym Ruby on Rails na apache'u, jak w JRuby on Rails na Glassfishu. I żeby nie musieli szukać zbytnio, choć wujek Google jest szalenie cierpliwy :-)

Java 4-ever

Kolejny film (tym razem trailer z przymrużeniem oka) w temacie: "czy jesteś pewien, że nie lubisz Javy?"

Adres: Java 4-ever

Ruby 1.9.2 i przygód kilka...

Ponieważ repozytoria Ubuntu 10.04 są dosyć biedne jeśli chodzi o świeże wersje różnych programów, czasem trzeba sięgnąć po źródła. Rozczarowany ograniczeniami Ruby 1.8.7 dostarczanego przez repozytoria Ubuntu usunąłem go wraz z całą "świtą" pakietów (bezustannie dziwię się, dlaczego wszystko jest tak rozdrobnione w repozytoriach, podczas gdy w źródłach mamy all-in-one; czasem mam obawy, że wyrzucam coś, co może być gdzieś potrzebne), pobrałem sobie źródła wersji 1.9.2, przekompilowałem i szafa gra. Choć od razu pojawiły się problemy - o ile Rails 2.3.8 zostały poprawnie zainstalowane (plus jeszcze parę innych dodatków), mongrel wszedł jak nóż w masło, mongrel_cluster tak samo, o tyle okazało się, że ani sam mongrel, ani mongrel_cluster nie mogą pracować razem, ani też pod kontrolą Ruby 1.9... Już chciałem robić downgrade Ruby'ego, gdy znalazłem w serwisie github.com repozytoria źródeł nowych wersji obu wspomnianych pakietów. Po przebudowaniu "dżemów" i ich zainstalowaniu wszystko, co zostało opisane na stronach:

• Ruby on Rails - Apache - Mongrel
• Looking for the Ultimate Ruby on Rails Hosting Stack?

(z małymi przeróbkami - wszak każdy system ma jakieś tam swoje "cechy osobiste") zadziałało. Pozostaje tylko jeszcze uzupełnić skrypty startowe Ubuntu tak, żeby klaster uruchamiał się przed startem apache.
Repozytoria, o których wspominałem (to dla chcących się bawić):

• kyusik/mongrel_cluster
• fauna/mongrel 

Mongrela w wersji 1.2.0 beta można też zainstalować poleceniem:

gem install mongrel --pre

Pożegnanie z Glassfishem i JRuby on Rails

Tytuł straszny, ale nie jest tak źle. Po prostu wracam do Railsów bazujących na natywnym Ruby i do serwera Mongrel, tym bardziej, że do celów produkcyjnych można wykorzystać starego dobrego indianina. Wiem, że nie jest to odkrywcze, ale znalazłem bodaj jedyną sensowną metodę udostępniania aplikacji RoR poprzez właśnie serwer apache. Opis tej metody można znaleźć tutaj: Apache + JRuby + Rails + GlassFish = Easy Deployment!.
Wcześniej żadna ze sztuczek nie skutkowała, ta zaś zaczyna działać w środowisku natywnym Ruby (trzeba ją troszkę doszlifować), mimo, że opis dotyczy JRoR. Poza tym - jak by nie było - apache jest dużo lżejszym serwerem, niż Glassfish, a instalowanie i obsługa tak potężnego narzędzia, jakim jest Glassfish, tylko po to, żeby serwować na nim aplikacje RoR jednak nie do końca ma sens. Chyba, że ktoś uruchamia jeszcze na nim javowskie aplikacje sieciowe.
Kolejny powód rezygnacji z tego serwera, to wieczne problemy z kompatybilnością gemów i kolejnych wersji J2SE - od początku musiałem kombinować, jak postawić w miarę stabilną platformę serwerową i uniknąć niespodzianek (zresztą pisałem już o tym). Każdy upgrade gemów wiązał się z testowaniem wszystkich aplikacji i kombinowaniem, co się "sypie". Stwierdziłem więc, że szkoda mi na to czasu. Jednak - żeby nie było nieporozumień - sam Glassfish to potężne i IMHO niezastąpione narzędzie jeśli chodzi o szeroko pojęte, wydajne serwery aplikacyjne. Tylko z JRubym i Railsami coś się nie bardzo dogadują bez kilku zabiegów.
Być może jeszcze wrócę do Glassfisha i JRoR - nigdy nie powinno się mówić "nigdy". Tymczasem dziękuję wszystkim, którzy pomogli mi w bojach (zwycięskich!) z kombinacją Glassfish + JRoR.

Dodano później:
Znalazłem jeszcze taki opis: Ruby on Rails - Apache - Mongrel autorstwa Pawła Kraszewskiego. Zapowiada się bardzo ciekawie.

Rails 3.0 w świetle dziennym

No i nareszcie mamy Rails 3.0! Zapowiada się ciekawie, choć pojawił się problem. Otóż framework został w pewnym stopniu przebudowany (jeszcze dokładnie się z nową wersją nie zapoznałem - wykonałem tylko kilka prób), co powoduje, że działające aplikacje utworzone w wersji 2.x muszą zostać "odrobinę" przerobione. Niestety, w moim przypadku - o ile "stare" aplikacje mogą sobie spokojnie pracować w Railsach 2.x - nowa wersja frameworka pociąga za sobą zmiany w środowisku pracy, przede wszystkim upgrade NetBeans (używam wersji 6.8), a kto wie, czy nie musiałbym też dźwigać GlassFish'a. W sumie można by powiedzieć: w czym problem? A no w braku czasu - głównie poświęcić go trzeba na dopieszczanie środowiska po upgrade'ach. Inna rzecz, to świeżość Rails 3 - myślę, że nie będzie od rzeczy przeczekanie pierwszej fazy szału na nową wersję i zainteresowanie się np. wersją 3.0.1.

Dla chcących migrować z Rails 2 na 3 dostępna jest ciekawa (jak mniemam) książka: Rails 3 Upgrade Handbook oraz screencast pokazujący migrację przeprowadzaną "na żywym organizmie".

Moving to Python

Mówi się, że prawdziwy informatyk powinien co roku poznawać nowy język programowania :-) Fajna sprawa, ale u mnie z tą częstotliwością bywało różnie. Zresztą między poznawaniem języka, a jego biegłym używaniem jest zasadnicza różnica. Poznałem na przestrzeni kilkunastu lat wiele języków programowania, jednak tak na prawdę programowałem i programuję tylko w trzech: C++ (w tym C++/CLI), C# i Java. Pozostałe, a było ich wiele - Forth, Lisp, wszelkie odmiany Basica, Perl, PHP (choć mocno go onegdaj używałem), Pascal, stary, dobry asembler i inne, których nazw już nawet nie pamiętam - gdzieś sobie zniknęły w czeluściach pamięci. Ostatnio nawet Ruby gdzieś mi zaczął umykać, ponieważ już dawno nie napisałem ani kawałka kodu... Jednak w tym przypadku sprawa jest ciągle otwarta - przymierzam się do pewnego projektu.

Ostatnio przeczytałem początek cyklu artykułów autorstwa Łukasza Langi opublikowanych w SDJ, a traktujących o programowaniu w Pythonie. I mnie ruszyło. O Pythonie słyszałem od dawna, ale jako oldschoolowiec nigdy nie miałem zaufania do języków interpretowanych (dopiero przy Ruby mi się trochę odmieniło). Jednak siedząc od pewnego czasu wyłącznie w systemie Linux (chwaliłem się tym parę miesięcy temu :-)) i widząc, jak doskonale sobie radzą języki interpretowane z Pythonem właśnie na czele, postanowiłem poznać ten język. Tym bardziej, że Python znajduje obecnie zastosowanie zarówno do tworzenia aplikacji Webowych (Django), z graficznym interfejsem użytkownika (np. PyGTK), klasycznych CLI, przeznaczonych na urządzenia przenośne itp... Słowem super sprawa!

Pewnie wielu moich znajomych (i nieznajomych) pomyśli, że rychło w czas, ale cóż, tak, jak pisałem wcześniej, zajmowałem się trochę innymi językami.

A w temacie języków programowania pozostając, problem z wyborem odpowiedniego języka do nauki programowania dla początkujących jest ciągle aktualny. Dramat ma miejsce głównie w polskiej oświacie (a jakże). Nie wiem, czy coś się zmieniło, ale dwa lata temu (i wcześniej również) miałem przyjemność uczyć programowania młodzież zdobywającą wykształcenie w zawodzie technik informatyk. Pomijając fakt, że zawód technik informatyk z takim programem nauczania, jaki obowiązuje (lub przynajmniej obowiązywał jakiś czas temu), to - delikatnie mówiąc - nieporozumienie, nauka programowania, jej założenia itp. są "zdziebko" przestarzałe. Programowanie jest w szkole podzielone na dwie części: programowanie strukturalne (Pascal...) i programowanie obiektowe (C++, potem ewentualnie Java). Można by powiedzieć: ale przecież nauczyciel mógłby uczyć innego języka, zamiast muzealnego Pascala. Owszem, też tak myślałem, a potem spojrzałem w standardy wymagań egzaminacyjnych i mnie zemdliło... Zadania z Pascala... Wyobraźcie sobie, jak potraktowaliby nauczyciela absolwenci, którzy znając C++ czy nawet C, dostaliby na egzaminie zadania z Pascala :-) Inna rzecz: znajdzcie mi w szkole nauczyciela przedmiotów informatycznych, który zna coś więcej niż Pascala/Basic/C... Przepraszam, nie "zna", tylko "programuje w". I potrafi tego prawidłowo nauczyć!

Swoją drogą, nieraz moi uczniowie byli zaskoczeni, że nie jestem tylko specjalistą od pocztówek w MS Paint :-)

Wracając do Pythona, polubiłem ten język, oczywiście jeżeli można tak powiedzieć po jednym dniu jegoż intensywnego poznawania i myślę, że dołączy on do mojej Wielkiej Trójki.

Życzę sobie powodzenia i wytrwałości!

No po prostu musiałem :-))))

Czy ktoś jeszcze nie lubi Javy?

Obejrzyj na YotuTube: LadyJava Music Video for JavaZone

Dla chcących zgłębić C++

Często zarówno uczniowie, jak i inni adepci sztuki programowania pytają mnie o dobry podręcznik do C++. Szczerze powiedziawszy ciężko znaleźć naprawdę dobry podręcznik traktujący o referencyjnym (dla mnie przynajmniej) języku programowania, jakim właśnie jest C++, w sposób dogłębny, bez naleciałości rodem z Pascala (!) czy C (niestety, długo musiałem się tych naleciałości wyzbywać - teraz znowu mam inne "zboczenie": wszystko piszę jak w Javie...). Na szczęście przypomniało mi się, że jest w Internecie dostępny świetny kurs/niekurs języka C++ - może nie do końca dla początkujących (trzeba znać podstawy programowania) i może nie w 100% wyczerpujący, ale prezentujący (jak rzadko) PRAWIDŁOWY styl programowania w C++ (w zgodzie ze standardami).

Gorąco polecam:

"C++ bez cholesterolu" by Sektor van Skijlen

Z cyklu: źródła znalezione w starych archiwach - animacje siatkowe 3D w Javie

Szukałem i znalazłem! Parę lat temu, nudząc się okropnie postanowiłem przypomnieć sobie, jak to było w czasach, kiedy nie mieliśmy do dyspozycji OpenGL ani DirectX i wszelkie operacje trójwymiarowe trzeba było programować "z palca". Napisałem kilka programów, pokazujących nieskomplikowaną animację figur (sześcian, kula, pierścień) - w zasadzie wyłącznie przekształcenia afiniczne. Oczywiście wszystko zrobione jest jak w starym, dobrym asemblerze. Zapraszam do pobrania binarek oraz przejrzenia źródeł. Szczególnie polecam tym wszystkim, którzy pragną zacząć przygodę z grafiką komputerową.
Zdaję sobie sprawę, że programy nie są mistrzostwem świata, ale - jak wspomniałem - powstały z nudów, a pisanie ich było zabawą :-)

Do pobrania/przejrzenia:
- Sześcian (bin) (src) (doc)
- Kula (bin) (src) (doc) - tylko model punktowy; nie chciało mi się dorabiać siatki i tak już zostało...
- Pierścień (bin) (src) (doc)

Animacja w akcji:

Materiały dodatkowe do nauki Ruby on Rails

Mój tutorial nie jest wyczerpujący, to rzecz, którą można zauważyć na pierwszy rzut oka. Nie skupiałem się w nim na samym języku Ruby, ani też na szczegółach Rails. W związku z tym zamieszczam parę linków do stron, gdzie znaleźć można wiele ciekawych informacji, również dla początkujących:

• Tutoriale Ruby on Rails w środowisku aptana/radrails – nieco przestarzałe, ale pod względem jakości bardzo dobre.
• Polskie forum Ruby on Rails
• Railscasts – screencasty na temat RoR
• Wzorzec projektowy Model-View-Controller (wikipedia jako obszar startowy :-))
• Wzorzec projektowy Active Record (j.w.)

Z książek (drukowanych) na początek mógłbym polecić np. B.A. Tate, C. Hibbs: Ruby on Rails. Wprowadzenie, Helion, 2007 (drugie wydanie). I oczywiście inne pozycje wydawnictwa Helion (moim zdaniem jest to wydawnictwo informatyczne nr 1 na naszym rynku, dlatego się nie rozdrabniam).

O samym języku Ruby dowiemy się najwięcej rozglądając się po stronach oficjalnego serwisu. Mogę polecić również interesujący podręcznik (tutaj w wersji online) :-)

Aneks (2) do tutoriala – Glassfih v3 + JRuby (on Rails) + MS SQL Server 2008

W artykułach:

• Nowa wersja activerecord-jdbc-adapter – 0.9.4 // usunięty //
• Problem z activerecord-jdbc-adapter w wersji 0.9.3 // usunięty //

przedstawiłem problem, jaki wystąpił podczas próby wpisywania danych do tabel SQL Servera z poziomu aplikacji JRuby on Rails poprzez rdzenny activerecord-jdbc-adapter w wersjach 0.9.3 i 0.9.4, później również – o czym już nie pisałem – w wersji 0.9.5. W tym rozwiązaniu wykorzystywany był sterownik JDBC dla Microsoft SQL Servera 2008.
Ostatnio znalazłem dedykowany adapter dla SQL Servera (activerecord-jdbcmssql-adapter, w wersji 0.9.5). Postanowiłem go wypróbować. Okazało się, że działa! A ponadto nie jest już potrzebny osobny sterownik JDBC i proces tworzenia aplikacji za pomocą kreatora znacznie się uprościł.
Aby skorzystać z dobrodziejstwa activerecord-jdbcmssql-adapter’a należy go oczywiście zainstalować (razem z innymi, ważnymi elementami – bodaj jeden dodatkowy pakiet oraz aktualizacja elementów activerecord) i zmienić odrobinę ustawienia kreatora aplikacji w trzecim kroku (Database Configuration):

Zauważcie, że jako adapter bazodanowy pozostawiłem mysql (jdbc) /mssql nie pojawił się na liście…/, podałem jedynie prawidłową nazwę bazy danych (tutaj video_collection_development). Można też było podać nazwę użytkownika i hasło w celu poprawnej rejestracji w serwerze baz danych, ale te informacje pominąłem.
Dalej wszystko odbyło się jak opisywałem wcześniej – koniec końców została utworzona aplikacja JRuby on Rails. Wygenerowałem sobie dla niej rusztowanie (scaffold) jak w cz. 3 tutoriala i zanim przystąpiłem do uruchomienia migracji, zmieniłem zawartość pliku database.yml na następującą:

# MySQL.  Versions 4.1 and 5.0 are recommended.
#
#####################################################
# Changed to MS SQL (via jdbcmssql adapter) by RW
#####################################################
#
# Be sure to use new-style password hashing:
#   http://dev.mysql.com/doc/refman/5.0/en/old-client.html
development:
#  adapter: jdbcmysql
adapter: jdbcmssql
encoding: utf8
reconnect: false
database: video_collection_development
pool: 5
username: rails_app
password: rails_app
host: localhost

# Warning: The database defined as "test" will be erased and
# re-generated from your development database when you run "rake".
# Do not set this db to the same as development or production.
test:
#  adapter: jdbcmysql
adapter: jdbcmssql
encoding: utf8
reconnect: false
database: video_collection_test
pool: 5
username: rails_app
password: rails_app
host: localhost

production:
#  adapter: jdbcmysql
adapter: jdbcmssql
encoding: utf8
reconnect: false
database: video_collection_production
pool: 5
username: rails_app
password: rails_app
host: localhost

W zasadzie zmianie uległa tylko nazwa adaptera (jdbcmssql) oraz nazwa użytkownika i hasło, reszta jak w pierwowzorze (dla mysql). Kreator, mimo że podałem nazwę bazy w wersji development, sprytnie dopasował nazwy pozostałych dwóch baz. Jedyne, co teraz zostało do zrobienia, to utworzenie baz danych (z odpowiednimi uprawnieniami dla użytkownika rails_app), przeprowadzenie migracji i rozwijanie aplikacji. Przetestowałem z poziomu środowiska wbudowanego w NetBeans oraz serwera testowego glassfish-gem, ale myślę, że w warunkach produkcyjnych też wszystko będzie działało prawidłowo.

Aneks do tutoriala – Glassfih v3 + JRuby (on Rails) + MS SQL Server 2008

W trzech częściach tutoriala na temat początków tworzenia i wdrażania aplikacji JRuby on Rails na platformie, w skład której wchodzą serwer aplikacyjny Glassfish v3 oraz serwer baz danych Microsoft SQL Server 2008, zabrakło informacji, jak przygotować niezależny od NetBeans serwer Glassfish do współpracy z produkcyjnym JRubym, a JRuby’ego do obsługi SQL Servera poprzez JDBC. Niniejszym nadrabiam zaległości.

Najpierw musimy zainstalować (proces instalacji jest raczej intuicyjny i chyba nie wymaga opisu) i uruchomić niezależny serwer Glassfish, np. za pomocą polecenia (oczywiście polecenie do uruchomienia, nie instalacji :-)):

asadmin start-domain

Następnie w odpowiednim polu naszej ulubionej przeglądarki wpisujemy adres (numer portu według naszej konfiguracji, ustalonej w procesie instalacji – tutaj wartość domyślna):

http://localhost:4848

Po udanym logowaniu do Konsoli Administratora (adres podany wyżej prowadzi właśnie do tej konsoli), udajemy się do podstrony Ruby Container:

Na tej podstronie podajemy informacje na temat położenia na dysku środowiska produkcyjnego JRuby oraz kilka innych danych, które proponuję wstępnie ustawić jak na obrazku powyżej. Co do środowiska JRuby – należy pamiętać, aby to środowisko, nazywane przeze mnie produkcyjnym, wyposażyć we wszystkie dodatki (pakiety gems), których używaliśmy w środowisku deweloperskim podczas tworzenia naszej aplikacji. Zapewni nam to bezproblemowe wdrażanie aplikacji. Oczywiście można, zamiast tego, użyć pakietów aktualizacyjnych Glassfisha zawierających JRuby i Rails, jednak przedstawiona tu metoda (użycie zewnętrznej instalacji JRuby) zdaje się dawać nam większą kontrolę nad JRubym.

Kolejna sprawa to sterownik JDBC dla SQL Servera. Otóż przeczytałem gdzieś w Internecie, że wystarczy przekopiować plik sqljdbc4.jar do podfolderu lib folderu zawierającego instalację JRuby. Okazuje się, że ta metoda działa :-) Plik sqljdbc4.jar to oczywiście sterownik JDBC dla SQL Servera dostarczony przez Microsoft.

Po tych zabiegach możemy już wdrażać i testować nasze aplikacje railsowskie na niezależnym serwerze aplikacyjnym Glassfish v3. Wykorzystanie Glassfish do obsługi JRuby on Rails to rozwiązanie moim zdaniem najlepsze, ponieważ W 100% DZIAŁA! I jest to – jak by nie było – sprawdzony, profesjonalny i duży serwer aplikacyjny.

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/videos – videos 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, Edit i Destroy 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:

http://localhost:8081/SimpleApp/videos

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ę!

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

W tej części tutoriala przygotujemy do pracy serwer baz danych, utworzymy w nim konto użytkownika, za pomocą którego wygenerujemy odpowiednie bazy danych - wykorzystamy je dalej przy tworzeniu przykładowej aplikacji Rails. Następnie "zmusimy" środowisko NetBeans do współpracy z SQL Serverem poprzez interfejs JDBC, wygenerujemy przykładową aplikację Rails i sprawdzimy, jak sobie radzi pod kontrolą serwera testowego GlassfishGem.

Najpierw krótkie przypomnienie. Aplikacja railsowska potrzebuje trzech baz danych:

• trybu tworzenia aplikacji (development);
• trybu testowania aplikacji (test);
• trybu produkcyjnego (wersja końcowa - production)

Pierwsza z nich przeznaczona jest do celów developerskich - cechują tę bazę częste zmiany, migracje i ich cofanie oraz przeładowywanie związanych z nią obiektów przy każdym odwołaniu do aplikacji.
Druga, jak sama nazwa wskazuje, przeznaczona jest do testów aplikacji, natomiast trzecia wykorzystywana będzie w przypadku właściwego uruchomienia aplikacji w środowisku produkcyjnym.

Tak, jak obiecałem w części pierwszej, nie będę tutaj wyłuszczał teorii na temat Ruby on Rails, MVC itd. Wszystkie te informacje zostały potraktowane w sposób wyczerpujący w odpowiednich publikacjach.

Spróbujemy teraz utworzyć trzy bazy danych dla naszej aplikacji.

Najpierw jednak musimy utworzyć konto użytkownika SQL Servera dla aplikacji Rails - musi to być, przynajmniej na czas budowy aplikacji, konto z wysokimi uprawnieniami, jednak szczerze odradzałbym iść na łatwiznę (patrz tutoriale o Ruby on Rails z MySQL'em) i używać wbudowanego konta administratora (sa). W naszym kursie konto użytkownika SQL Servera będzie nosiło nazwę rails_app i tak samo będzie brzmiało hasło. Konto założymy logując się do SQL Servera za pomocą Microsoft SQL Server Management Studio, oczywiście korzystając z istniejącego konta użytkownika o uprawnieniach pozwalających na tworzenie kont (może to być właśnie sa). Z poziomu Object Explorera, w drzewku naszego serwera baz danych rozwijamy gałąź Security, klikamy prawym przyciskiem myszy Logins i wybieramy opcję New login. W okienku, które ukazało się właśnie naszym oczom, na zakładce General ustalamy nazwę użytkownika (rails_app), zaznaczamy opcję SQL Server authentication i odznaczamy Enforce password policy. Podajemy dwukrotnie hasło (rails_app) i przechodzimy na zakładkę Server Roles. Tam zaznaczamy rolę dbcreator, klikamy OK i... konto użytkownika utworzone.
Aby się przekonać, że nasze konto rails_app nadaje się do czegokolwiek, wylogujmy się z SQL Servera i zalogujmy ponownie, używając tegoż właśnie konta. Udało się? Jeśli tak, to w porządku.

Ponieważ nasz nowy użytkownik posiada uprawnienia do tworzenia baz danych, bez większych problemów możemy utworzyć owe trzy bazy potrzebne naszemu projektowi. Klikamy zatem prawym przyciskiem myszy w węzeł Databases (Object Explorer; cały czas pracujemy w Microsoft SQL Server Management Studio), wybieramy New database... i podajemy nazwę simple_development. Zatwierdzamy klikając OK i pierwsza baza danych utworzona. Podobnie postępujemy tworząc bazy danych simple_test i simple_production. Słowo "simple" to nazwa właściwa naszej bazy danych, związana ściśle z nazwą aplikacji, którą utworzymy za moment. I oczywiście słowo to oddaje precyzyjnie istotę naszej aplikacji ;-)

Jeśli nie wystąpiły żadne problemy z tworzeniem baz danych, możemy się wylogować i zakończyć Microsoft SQL Server Management Studio.

Teraz do gry wchodzi NetBeans. Po uruchomieniu środowiska musimy zapewnić naszej aplikacji (i innym, tworzonym w przyszłości) dostęp do baz danych serwowanych przez SQL Server wykorzystując interfejs JDBC. W tym celu musimy zaopatrzyć się w odpowiedni sterownik, którego lokalizację podałem w części pierwszej tutoriala. Sterownik JDBC dla SQL Servera dostarczany jest jako archiwum ZIP, więc musimy je rozpakować. Zawartość archiwum umieszczamy w jakimś łatwo dostępnym folderze i przechodzimy do okna głównego NetBeans. Tutaj, w panelu Services rozwijamy węzeł Databases i klikamy prawym przyciskiem myszy podwęzeł Drivers. Domyślnie oczywiście nie ma sterownika dla SQL Server, więc wybieramy jedyną dostępną opcję, czyli New driver... W okienku New JDBC driver dodajemy (Add...) plik sqljdbc4.jar i klikamy OK, zgadzając się na domyślną nazwę - jak pokazano na obrazku poniżej.

I to wszystko - teraz każda aplikacja tworzona w NetBeans będzie mogła swobodnie korzystać z baz danych SQL Servera.

Utwórzmy więc projekt naszej aplikacji. Z menu File okna głównego NetBeans wybieramy opcję New project... i w okienku, które się wyświetliło, odnajdujemy kategorię Ruby i wybieramy w niej typ projektu Ruby on Rails Application.

Po kliknięciu Next (Następny) wybieramy nazwę naszej aplikacji (SimpleApp), ustalamy jej lokalizację, wybieramy platformę Ruby (polecam wbudowaną platformę JRoR - tej "niezależnej" użyjemy podczas wdrażania) i serwer testowy, wykorzystywany podczas uruchamiania naszej aplikacji w procesie jej tworzenia - oczywiście Glassfish Gem.

Po przejściu do następnego kroku (Next) musimy skonfigurować bazy danych naszej aplikacji i sposób łączenia się z nimi. Po pierwsze, zaznaczamy opcję Access Database Using JDBC.

Zostawiamy zaznaczone pole Configure Using IDE Connections i z listy rozwijalnej skojarzonej z każdym z trzech rodzajów baz danych wybieramy pozycję New Database Connection...

Dla każdej z trzech baz danych naszej aplikacji musimy ustalić szczegóły połączenia. Poniższy obrazek pokazuje, co należy podać w okienku połączenia dla bazy simple_development (analogicznie postępujemy w przypadku pozostałych baz):

Oczywiście nazwa hosta powinna być właściwa dla konfiguracji Waszych komputerów. Nazwę użytkownika i hasło ustaliliśmy wcześniej. Jeśli ktoś używa SQL Servera w wersji Express, to konieczne będzie wypełnienie pola nazwy instancji, np. SQLEXPRESS, chyba, że zainstalowano serwer jako tzw. instancję domyślną.

Po kliknięciu OK, jeśli wszystko będzie w porządku, czyli NetBeans nawiąże połączenie z SQL Serverem, będziemy musieli wybrać na zakładce Advanced odpowiedni schemat - sugeruję dbo.

Klikamy OK i połączenie zostaje dodane do środowiska.

Mamy więc przygotowane dla naszej aplikacji bazy danych i wiemy, jak się z nimi łączyć - automatycznie wracamy do okienka konfiguracji baz danych i możemy przechodzić dalej.

Ostatnie okno pozwala nam wybrać jedną z dostępnych wersji Rails - proponuję najnowszą, jaką mamy.

Klikamy Zakończ i w napięciu oczekujemy, aż środowisko wygeneruje nam projekt wstępny naszej aplikacji. Po upływie określonego czasu, silnie zależnego od mocy obliczeniowej naszego komputera, środowisko NetBeans ukaże nam się w pełnej krasie, zachęcając do twórczej pracy, wspieranej przez JRuby on Rails :-)

Zwykle NetBeans na "dzień dobry" prezentuje nam zawartość pliku database.yml - widzimy, jak misternie wyplecione jest nasze połączenie z bazami danych.

No ok, sprawdźmy więc, czy nasza aplikacja jest prawdziwą aplikacją JRoR. Najprościej przekonamy się o tym, gdy ją uruchomimy (serwer + klient, czyli przeglądarka WWW). Kliknijmy więc prawym przyciskiem myszy nazwę naszej aplikacji w panelu Projects i wybierzmy polecenie Run. Po chwili (uwaga na temat czasu - patrz wyżej) uruchomiona zostanie nasza domyślna przeglądarka, w której Rails powitają nas serdecznie:

Jednak to nam nie wystarczy. Kliknijmy w link About your application's environment. Jeśli zobaczymy jakikolwiek komunikat o błędzie, musimy sprawdzić, czy jest wszystko w porządku ze środowiskiem i jego składnikami (głównie JRuby i Rails oraz sterownik JDBC). W przeciwnym wypadku otrzymamy piękny zestaw informacji:

...i możemy z niecierpliwością wyczekiwać następnej części tutoriala, w której wgryziemy się głębiej w naszą aplikację oraz wdrożymy ją w środowisku produkcyjnym.

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

Część pierwsza tutoriala o “mieszance wybuchowej”. Znalazłem wreszcie czas, żeby się za nią zabrać – temat jest interesujący i odrobinę intrygujący. Wszyscy, którzy próbują swych sił ze znakomitym frameworkiem Ruby on Rails zwykle korzystają z układu: Ruby + Rails, MySQL oraz serwer Webrick lub Mongrel. Ja mam propozycję inną.
Na jednym ze spotkań Śląskiej Regionalnej Grupy Microsoft mój kolega Sebastian, podczas przerwy kawowej, słuchając moich wywodów na temat doskonałości Rails zaproponował mi zwrócenie uwagi na rozwiązanie o przewrotnej nazwie JRuby on Rails. Literka “J” przed nazwą jednego z coraz bardziej popularnych, interpretowanych języków programowania oznacza, że wersja ta została w całości napisana w Javie (moim ulubionym języku programowania :-)). No więc się zainteresowałem. Dlaczego? Mam nadzieję, że ten tutorial udzieli odpowiedzi na to pytanie i przy okazji wiele wyjaśni.
O czym będzie w tej części?

1. Wstępniak drugi, czyli co mnie skłoniło ku takiemu rozwiązaniu.
2. Krótko o użytych narzędziach.
3. Przygotowanie środowiska pracy.

Jednakowoż muszę zaznaczyć, że nie będę tutaj wyjaśniał szczegółowo, co to jest JRuby on Rails, jak działa i do czego służy, ponieważ zakładam, że te informacje każdy czytający znalazł już czy to w Internecie, czy w literaturze (polecam).
No to start!
001 Co mnie skłoniło ku tak dziwnemu rozwiązaniu?
Przejście na JRuby on Rails spowodowane było poszukiwaniem przeze mnie serwera produkcyjnego, na którym można by śmiało i bezpiecznie uruchamiać aplikacje railsowskie przeznaczone do wykorzystania przez użytkowników końcowych. Serwerki wbudowane w Rails (Webrick lub Mongrel – po doinstalowaniu odpowiedniego GEMa) nadają się raczej do celów testowych lub uruchamiania pojedynczych aplikacji w sieci lokalnej. Ja chciałem czegoś więcej, a tym czymś jest GlassFish v3 – doskonały serwer aplikacyjny rozwijany przez społeczność na zasadach Open Source, zgodny z J2EE 6 itd., w pełni zarządzany, skalowalny, stabilny, wydajny i co tam jeszcze ;-) Ale na poważnie – GlassFish jest faktycznie serwerem przeznaczonym do tworzenia środowisk produkcyjnych, stanowiący platformę dla aplikacji sieciowych Java. Ponieważ JRuby jest aplikacją javowską i ponieważ GlassFish w wersji 3 obsługuje ruby’ego w sposób bezpośredni (nie jak to było kiedyś – poprzez doinstalowanie pakietu JRuby i Rails), ponadto zaś nie trzeba aplikacji railsowskiej pakować warblerem w celu uzyskania pakietu *.war (do zainstalowania na serwerze niczym aplikacja rdzennie-javowska), wybór był oczywisty.
Kolejna rzecz, to serwer baz danych. Ponieważ pracuję w systemach Windows częściej niż pod Linuksami i dysponuję jednym z najpotężniejszych serwerów bazodanowych – SQL Server 2008 firmy Microsoft (mam Developer Edition, więc lepiej być nie może), postanowiłem zaprząc tenże właśnie serwer do pracy na mojej platformie uruchomieniowej. Inna rzecz, że chciałem sprawdzić, jak framework Rails poradzi sobie z tym dość nietypowym dla niego serwerem (zwykle używamy MySQL – bo jest taniej ;-)). Oczywiście wykorzystując w pełni “objavienie” mojego środowiska uruchomieniowego, postanowiłem wykorzystać do łączenia się z SQL Serverem technologię JDBC. W zasadzie SQL Server jest jedynym elementem tej układanki uzależniającym cały projekt od systemu Windows (u mnie XP). Gdyby wykorzystać standardowego MySQL czy PostgreSQL, to śmiało możemy wszystko przerzucić na Linuksy.
002 Krótko o użytych narzędziach
Żeby pobawić się tym tutorialem, będziecie musieli zaopatrzyć się w następujące narzędzia:

1. darmowe, otwarte środowisko programistyczne NetBeans – najlepiej wersję kompletną, chyba, że nie zamierzacie testować jego pełnych możliwości, wtedy można pobrać wersję dla RoR;
2. Microsoft SQL Server 2008 – nam wystarczy właściwie darmowa wersja Express Edition (ważne, żeby zainstalować też Microsoft SQL Server Management Studio – można pobrać razem z wersją Express, a jest to przydatne narzędzie), ale jeżeli dysponujecie pełną wersją komercyjną, tym lepiej; pamiętajcie: nie toleruję piractwa – nie kradnijcie wersji komercyjnej, jeśli i tak darmowa wystarczy!!!

I to wszystko na początek. Potem będziemy pobierać serwer GlassFish oraz osobną instalację JRuby z dodatkami. Środowisko NetBeans w wersji dostosowanej do tworzenia aplikacji Rails lub w wersji pełnej dostarcza (prawie) wszystkich narzędzi, których będziemy potrzebowali. W przypadku SQL Servera musimy jedynie pobrać i skonfigurować sterownik JDBC ze strony firmy Microsoft.
Spróbujmy więc przygotować nasze środowisko pracy.
003 Przygotowanie środowiska pracy
Po pierwsze musimy pobrać i zainstalować SQL Server i NetBeans. Nie będę opisywał tutaj procesu instalacji, ponieważ wszystko zostało opisane w innych miejscach (przejrzyjcie linki w tekście). Zresztą, jeśli ktoś bierze się za programowanie, nie powinien mieć problemów z instalacją (chyba)…
Na początek uruchomimy środowisko NetBeans. Po względnie krótkiej chwili powinniśmy zobaczyć okno główne środowiska jak na rysunku poniżej (na zrzucie widać kilka testowych projektów :-)).

Następnie musimy sprawdzić, czy na pewno mamy do dyspozycji w naszym środowisku oprogramowanie JRuby (wbudowane). W tym celu wybieramy z Menu Narzędzia >> Ruby Platforms i sprawdzamy, co jest wyświetlone w okienku. Zwykle mamy do dyspozycji w pełni zainstalowane podstawowe środowisko JRuby wraz z Rails i innymi dodatkami. Oto okienko pokazujące informacje o zainstalowanych wersjach JRuby:

Jak widać, w przypadku mojego komputera oprócz wbudowanej wersji JRuby jest też wersja dodatkowa, ale o niej póki co nie mówimy.
Sprawdźmy teraz, jakie dodatki są zainstalowane w ramach naszej wbudowanej wersji JRuby. Mam nadzieję, że nie zamknęliście okienka, o którym przed chwilą pisałem. Znajduje się w nim bowiem przycisk, za pomocą którego uruchomimy menedżera pakietów GEM. Kliknijmy więc przycisk Gem manager i przyjrzymy się nowemu okienku:

Na zakładce Installed widzimy wszystkie pakiety GEM zainstalowane w naszej wersji JRuby. Zakładka Updated zawiera pakiety zaktualizowane (możemy zaktualizować wybrane pakiety do najnowszej wersji), a zakładka New Gems zawiera propozycje pakietów, które możemy sobie zainstalować, jeśli tylko będziemy mieli ochotę. W zrzucie ekranowym okienka Ruby Gems widzicie wszystkie pakiety, jakie mam zainstalowane w swoim środowisku roboczym, jednak aby przetestować rozwiązania proponowane w tym tutorialu wystarczy mieć zainstalowane pakiety wchodzące w skład zestawu domyślnego. Jeśli w tym zestawie nie ma pakietu activerecord-jdbc-adapter, to musimy go dodać sami (zakładka New Gems). Dopiero w dalszej części tutoriala dowiemy się, jak skonfigurować własną instancję JRuby z frameworkiem Rails.
Ważna uwaga: koniecznie musimy pamiętać, aby zainstalować pakiet GEM glassfish, ponieważ nie jest on dostarczany domyślnie. Jeśli zainstalujemy ten pakiet (zakładka New Gems) w wersji np. 1.0.2, to nie możemy “dźwigać” pakietu rack do nowszej wersji (musi zostać 1.0.1), ponieważ wszystko weźmie w łeb. Wyszperałem swego czasu ten problem i został on opublikowany w bugtracku projektu Glassfish GEM.
I to tyle, jeśli chodzi o część pierwszą. Ciąg dalszy już wkrótce, a w nim: przygotowanie baz danych i konta użytkownika SQL Servera, instalacja sterownika JDBC, utworzenie i uruchomienie pierwszej, szkieletowej aplikacji JRuby on Rails… No i testy! Zapraszam!