Ruby On Rails 3.1 - dzień pierwszy

Zawsze uważałem, że najlepszy poradnik, to zbiór wskazówek pisanych przez początkującego, nie koniecznie zaś zapełniane przez mądrego człowieka annały, które jak na początek, mogą być za mądre. Równocześnie, najlepiej aby początkujący miał już doświadczenie z innymi podobnymi zagadnieniami  jednak w danej technologii był początkujący. Taki układ daje duże szanse, że poradnik będzie profesjonalny, pisany prostym językiem i zrozumiały dla maluczkich, którzy oczekują prowadzenia krok po kroku. Mam nadzieję, że moje wpisy o Ruby On Rails 3.1 takie właśnie będą.

Dlaczego?

Mam za sobą już, od jakiegoś czasu, Rails for Zombies, czytałem o Ruby On Rails i jeszcze nigdy nie spotkałem się z osobą, która zaczęłaby kurs Railsów od RVM. Podstawy podstaw - jak na mój gust.

Gdy piszesz jakikolwiek program, aplikację musisz zdecydować się na dwie rzeczy: wersję języka programowania i wersję pozostałych bibliotek, które używasz. U mnie to wygląda tak: zaglądam na stronę języka programowania (w tym przypadku języka Ruby), zaglądam na stronę biblioteki (w tym przypadku Railsów) i nakręcam się na napisanie aplikacji w najnowszej wersji, która wprowadza najświeższe udogodnienia, nowości, nowatorskie technologie i wszystko co sprawia, że bycie geekiem jest piękne i pełne wrażeń jak przejażdżka górską kolejką w parku "Six Flags Great Adventure".

Później przychodzi faza druga, która nazywa się "sprawdźmy co jest na serwerze" i ta przynosi znacznie więcej rozczarowań, niż radości dopóki nie używasz ArchLinux lub nie jesteś twórcą biblioteki, której właśnie zamierzasz użyć. Wtedy klniesz pod nosem, że "przecież administrator mógł przejść na sida" i jakbyś tylko miał uprawnienia użytkownika root!

I tutaj właśnie objawia się piękno RVM. Pozwala ono bowiem bez uprawnienia super-użytkownika zainstalować dowolne wersje języka Ruby, w locie podmieniać interpreter oraz wersje używanych bibliotek, które w wielu różnych kombinacjach mogą koegzystować w wirtualnych środowiskach zwanych gemsetami. Wszystko bez wychodzenia poza katalog domowy.

Rok 2010 rokiem przełomów w aplikacjach sieciowych

To wręcz niesamowite jak wiele dzieje się w tym roku w dziedzinie aplikacji sieciowych. Być może to tylko wrażenie, jakie można mieć co roku ale moim zdaniem jest to rok przełomowy.

Dzisiaj po 2 w nocy wyszła wersja Release Candidate 1 Gallery 3. Jest to ogromny krok w dziedzinie aplikacji do przetrzymywania zdjęć. Większość dostępnych w sieci skryptów zakłada, że istnieje jeden właściciel galerii, który publikuje w niej zdjęcia. Gallery to jedyny znany mi do tej pory system pozwalający w ramach jednej galerii tworzenie wielu albumów i przydzielania uprawnień do nich wielu użytkownikom.

Gallery posiada pewne bardzo proste - acz daleko idące w skutkach założenie - jeżeli nie masz dostępu do zdjęcia - nie masz do niego dostępu wogóle, nawet poprzez bezpośredni link. Gallery w wersji 2 realizowało to poprzez przetrzymywanie obrazków poza folderami dostępnymi przez Apache zaś każde żądanie pliku PNG, JPG czy innego było tłumaczone przez mod_rewrite na wywołanie skryptu PHP, który sprawdzał uprawnienia do pliku i ewentualnie zezwalał na jego wyświetlenie.

Niestety - przy galeriach dużych rozmiarów całość znacznie rzutowała na wydajność, wygodę i szybkość korzystania.

Gallery 3 to krok milowy w każdej tych dziedzin. Dzięki modelowaniu uprawnień na poziomie plików .htaccess udało się otrzymać wydajny i szybki mechanizm bezpieczeństwa. Celem stało się utrzymanie aplikacji sprawną, lekką i wydajną. Dołożono do tego interfejs oparty o jQuery. Całość zaś oparto na fantastycznym frameworku Kohana.

Kolejne zaskoczenie to milowe w dzidzinie od lat zgłaszanych braków Django 1.2. W końcu poprawki w dziedzinie modeli, obsługa wielu baz danych, zamknięcie wielu ticketów, które od lat straszą na Djangowym bug tracku. Django w końcu przełamuje barierę "argumentu za użyciem Pylons" jakim był brak możliwości obsługi wielu baz danych co czyni go znacznie bliższym zastosowań enterprise.

Skoro już przy Pylons jesteśmy. Nigdy nie wierzyłem, że dożyję dnia kiedy zostanie wydana publicznie wersja Pylons 1.0 beta. Jednak stało się. Pylons pretenduje do wersji stabilnej z niezmiennym API i w końcu może zacząć być używany w projektach gdzie liczy się stałość i ciągłość wersji w aktualizacji 3rd party components.

Nie można też pominąć Rails 3 - chociaż tutaj nie chcę się wypowiadać to z oglądanych przeze mnie prelekcji, wypowiedzi Yehudy Katz oraz wpisów na blogach Polskich Rubystów widać, że Rails 3 jest krokiem milowym w jakości tego frameworka ku doskonałości.

Wszystko wskazuje na to, że również Drupal 7 pojawi się w tym roku. Dwa dni temu została wypuszczona wersja Alpha 2 - co oczywiście w przypadku Drupala kompletnie o niczym nie świadczy - ale zawsze to jakiś krok do przodu. Oby prace poszły szybko - bo zapowiada się naprawdę fantastyczny framework.

Prawdopodobnie jeszcze wiele zaskoczeń czeka nas w dziedzinie aplikacji sieciowych - jednak Luty i Marzec to prawdziwy wysyp. Dzisiejszy dzień to jeden z tych, w których nie mogę uwierzyć, że jest aż tak dobrze. Oby więcej takich postępów i dobrze wykonanej pracy!

Trendy polskie a praca na świeci

Nie wiem co mnie dziś tknęło ale postanowiłem sprawdzić pewną rzecz.

Przeczesując zasoby polskiej sieci, w poszukiwaniu informacji na temat tworzenia witryn internetowych, trafiamy głównie na kursy Ruby On Rails albo Django. Dzisiaj postanowiłem zobaczyć jak sprawa się ma jeżeli chodzi o "jobtrends" na świecie. Wyniki z serwisu Indeed.com/jobtrends poniżej.

O ile popularność Railsów mnie nie zszokowała (może co najwyżej jej skala) o tyle fakt iż Drupal stoi znacznie wyżej niż dziesiątki razy opisywany w polskiej sieci Django - mocno mnie zdziwiło. Czyżby Django przegrywało w świecie biznesu z Drupalem? Może to jakaś wskazówka? Szczególnie, jeżeli planujemy naszą przyszłość w perspektywie pracy programisty. I jak sytuacja ta ma się do polskich warunków pracy? Pytania pozostawiam bez odpowiedzi.

Sprostowanie co do mojego merbowania

Pisałem jakiś czas temu (dawno) na moim blogu o Merbie, zachwycałem się HAMLem i SASSem (bo naprawdę byłem pod ich wrażeniem). Później zacząłem krytykować Railsy za ich kody i wykazywałem totalne niezrozumienie i krytykę wobec osób, które nadal programowały w Railsach.

W Merbie nie napisałem ani jednej aplikacji. Robiłem tyle co pisałem na Blogu. Generalnie templaty: HAML/SASS i odbieranie jakiś danych w kontrolerze. Na modele byłem zawsze za leniwy. Jeżeli ktokolwiek poczuł się urażony moją ostrą krytyką - to przepraszam. Niestety mój "perfekcjonizm" programisty dał mi się we znaki i zamiast krytykować Railsy zacząłem jak widzę krytykować osoby.

Do kodu Railsów nigdy nie zaglądałem i moje zdanie jest zdaniem wyrobionym na bazie idei obu projektów, celów im przyświecających oraz opiniom rzeczy osób programujący w Rails i Merb, których blogi czytam. Czepiam się nie funkcjonalności a jakości kodu, który w Rails jest podobno słabej jakości.

W Rails robiłem kiedyś jakiś tutorial oparty na scaffoldingu i generowaniu kodu :]

Urażonych przepraszam :) Mam nadzieję, że sprawę wyjaśniłem dość jasno. W Merbie i w Rails nie pisałem żadych dużych projektów. Bawiłem się nimi tylko jako frameworkami, gdzie w Merbie robiłem to tylko na bazie wysyłania formularzy i bawienia się HAML i SASSem a w Rails jakimś tutorialem w stylu "scaffolding" czy jakieś magiczne automaty :)

web2py - wymiękłem

Jeszcze tydzień temu zachwalałem, w swojej prezentacji, na konferencji w Warszawie Pylons. Prezentowałem jego cechy, zalety oraz braki. No właśnie braki. Po obejrzeniu prezentacji Webhosting.pl o wdrożeniu Pylons oraz "Pylons - Demonstracja możliwości" Tomasza Nazara. Można je znaleźć na stronie materiałów PyCon2008 PL zaczęło do mnie docierać, że Pylons nie jest niczym - fenomenalnym.

Zacząłem analizować ... porównania. Porównania z innymi frameworkami. W Merb zachwyciła mnie modularność, wydajność i czytelność kodu. Przyznaję się. Nie napisałem w tym frameworku nawet pół linijki kodu. Cały podziw dla kunsztu przedkładam wyłącznie z wypowiedzi z jakimi spotykam się w sieci. Przeglądając pluginy znalazłem ciekawą opcję walidacji danych wchodzących do datamapeera jednak zabrakło mi gdzieś generowania formulrzy czy chociażby samej obecności admin panelu. Wiem, że ma być obecny w wersji 2.0 :) To cieszy. Być może coś przeoczyłem jednak przy moich obecnych obserwajach Merb w porównaniu do Pylons ma fantastyczne validowanie, z tłumaczeniami błędów i to w kilku języka... I do tego ta elegancja składni dekoratorów - miodzio.

No właśnie. Skoro już przy tym jesteśmy. Pylons tak jak merb nie posiada admin panelu. Tutaj na tle frameworków Pythonowych króluje Django. Nie ma mowy o scaffoldingu czy czymkolwiek takim. Nic z tych rzeczy. Modularność może cieszyć, jednak niestety nie znajdujemy mechanizmów do generowania formularz (znowu) ... Co prawda jest FormBuild ale wygląda bynajmniej podejrzanie, pomimo tego że jest opisana w PylonsBook, i jakoś ... nie o takim generowaniu marzę.

No więc może Django. Posiadania rozbudowane generowanie formularzy oraz admin panel. Pomimo tego nie dorasta do pięt Pylons w walidowaniu formularzy o braku możliwości testowania kodu (co często jest krytczne) nie wspomnę.

Sprostowanie

Od wersji 1.0 Django posiada możliwość pisania zarówno unittestów (z użyciem Pythonowej biblioteki unittest) jak i functional testów. Jest temu poświęcony poddział dokumentacji.

Co do Railsów - wydają się tutaj rozsądne. Posiadają na przykłąd mailer, którego na próżno szukać w jakimkolwiek pythonowym frameworku. Jest konsola (jak w Pylons), Scaffolding. Może brak admin panelu (chociaż może ktoś zna takowy), ale nie ma co narzekać: mailer, rack do testowania, migracje. HAML, SASS, spory wybór możliwych do podpięcia ORMów ... bomba.
A co gdybyśmy chcieli programować w Pythonie ? HAML i SASS oczywiście nie zagościł tutaj, mailerów nie można się spodziewać (choć szkoda, bo przydałaby się dobrze przetesowana biblioteka odporna na MailInjection) .

Wszystkie frameworki są do siebie jednak podobne. Generowany jest jakiś kod, używa się poleceń skryptowych i konsoli...
Dziś trafiłem na ten screencast pokazujący możliwości frameworka web2py



Nie wiem jakie macie podejście do tego co jest na nim pokazane. Wszystko co jest tam zaprezentowane to prawda, choć bardziej przypomina to "klikanie" aplikacji, niż jej tworzenie. Na prawdę. Nie otworzyłem ani przez sekundę edytora. Konsola też w gruncie rzeczy jest zbędna (chyba, że chcesz w niej odpalić serwer). Jest scaffolding (wow). Co prawda nie zauważyłem, żeby można było sobie wygenerować jego kod do pliku "od tak" jak w Rails, ale jest ! i to nie lada. Formularzy się "nie generuje" po prostu ... są :) i walidowanie jest ... bajecznie proste.
Wydaje mi się troszkę, że tak zautomatyzowany framework będzie podpadał pod zarzuty pod jakimi padał Django w ogniu Grono.net jednak ... to co dziś widziałem robi na mnie wrażenie. Web2Py to coś ... innego, coś co zmienia myślenie o tworzeniu aplikacji internetowych. Zobaczymy co jeszcze :)

Merb - i propaganda Railsowców

To już kolejny raz kiedy napatocza mi się ktoś ze znajomych, który mówi "Widziałeś Railsy jaaa - fantastyczne !", albo "Będę się uczył Railsów", albo "Właśnie skończyliśmy projekt w Railsach, który robiliśmy z kolegami.". Kurcze belek. Bawiłem się w Railsach, używałem też kilku innych frameworków takich np. jak CakePHP, CodeIgniter, Symfony czy Pylons a także jestem wciąż naocznym świadkiem wszystkich odkryć współlokatora, który zgłębia Django i nie rozumiem - czym się ludzie zachwycają. Rails - przereklamowany, z tego co czytałem, bezmyślnie zaimplementowany, niewydajny, posidający błędy framework, który jak widać pomimo swoich wad wciąż robi wielki show więc do listy dodałbym jeszcze podkreślając  po raz kolejny przereklamowany framework.

W przyszłym miesiącu premiera Merba. Śledzę jego karierę od czasu gdy wpisy zaczęły pojawiać się na blogu Zabiello, później zaimportowałem sobie kanał RSS z Merbist, przeszukałem sieć pod kątem materiałów na jego temat, pooglądałem slajdu z MerbCamp... i wciąż zastanawiam się co jest z ludźmi zafascynowanymi Railsami nie tak.  Żadne argumenty nie przemawiają do osób, które zamierzają się uczyć Railsów, aby spróbować z Merbem. Nie ważne czy powiem: "jest szybszy", "jest przemyślanie zaimplementowany", "uczy się na błędach railsów", "jest napisany przez fachowców od Rubego" - argument zawsze jest ten sam: "Do Railsów jest więcej książek, Railsów jest się łatwiej nauczyć". Ludzie - co z tego, że jest do nich 2,5 miliona książek. Do Merba jest kilka 5,3 GB filmów. Natrafiłem również na ciekawy - wyglądało na to całościowy - kurs Merba [http://merb.4ninjas.org/] choć jeszcze nie dokończony  - cóż więcej można chcieć ?

Nadal będę próbował propagować ideę Merba, przekonywać do niego railsowców. Może zrobię do niego slajdy. Uważam, że jest to fantastyczny framework. Używałem w nim wyłącznie templatów i kontrolerów, ale już samo HAML i SASS mnie tak użekło iż stwierdziłem, że ten framework to numer 1 :) i basta !

Z pozdrowieniami dla wszystkich railsowców jadących wciąż lokomtową parową w czasach ażewe :) Merb propagator :P

Ruby on Rails vs .... series

Dziś kolega, zafascynowany Ruby on Rails, pokazał mi filmiki z serii Ruby on Rails vs .... http://pl.youtube.com/results?search_query=Ruby+On+Rails+vs&search_type=&aq=f

Na starcie zapytałem: "A jak wygląda filmik z Django" [http://pl.youtube.com/watch?v=PLUS00QrYWw] Chyba musieli się naprawdę wysilić żeby coś takiego wymyślić. Moim zdaniem - śmiech na sali. W momencie, w którym to obejrzałem twórcy wydali mi sie śmieszni i w gruncie rzeczy - sami ośmieszyli Railsy.

Przy informacjach, jakie można znaleźć na blogach, w których zarzutami przeciwko railsom jest wydajność (tutaj Django pokazuje klasę że hoho) czy też błędy znane od lat, czy chociaż kiepski sposób implementacji porównywanie siebie z Django z góry z założeniem "Railsy muszą wypaść na plus" - jest bez sensowne.