Merb - tworzenie nowego projektu

Opublikowane przez Jarosław Zabiełło Wed, 19 Nov 2008 01:13:00 GMT

Rozpoczęcie pracy z Merb’em, podobnie jak w Rails, zaczyna się od stworzenia projektu. Domyślnie Merb proponuje predefiniowany zestaw dobranych modułów, nie jest to jednak jedyna opcja i dobrze wiedzieć o tym szczególnie dla tych co chcieliby użyć Merb w JRuby (jeden z domyślnych modułów, DataMapper, jeszcze nie jest przygotowany do pracy z JRuby).

Projekt “z pudełka”

To opcja dla tych, co chcieliby od razu wystartować z gotowym, predefiniowanym zestawem. Merb za taki zestaw uznaje: SQLite3 jako domyślna baza danych, DataMapper jako domyślny ORM i RSpec jako domyślny framework do pisania testów.

Poza tym domyślnie (config/dependency.rb) włączone są następujące moduły:

  • merb-action-args – Dostęp do zmiennych wysyłanych metodą GET/POST jest, podobnie jak w Rails, dostępny w haszu params. Dzięki temu gemowi możliwe jest dodatkowe użycie parametrów formalnych w akcji kontrolera tak jak w zwykłej metodzie Ruby’ego.
  • merb-cache – obsługa cache, buforowania kodu.
  • merb-helpers – helpery dla warstwy widoku (np. helpery upraszczające pisanie formularzy).
  • merb-slices – moduł do tworzenia komponentów. W zasadzie komponentami zajmuje się “merb_parts:http://www.merbivore.com/documentation/1.0/doc/rdoc/merb_parts/index.html (nie jest w zestawie domyślnym). Slices są czymś bliżej idei wielu aplikacji w ramach jednego projektu (podobnie jak to jest w Django). Dzięki slices, można aplikację Merb’a zamienić w slice, zapakować w gema i z takich klocków do wielokrotnego użycia, składać większą aplikację. Dzięki temu, że każdy slice jest gemem (pakietem Ruby’ego), możliwe jest znacznie potężniejsze i wygodniejsze (niż to jest w Django) kontrolowanie zależności, wersji i dystrybucji każdego modułu.
  • merb-auth-core – Podframework autentykacji o bardzo ciekawych właściwościach (m.in. możliwe jest definiowanie kaskady strategii autentykacji).
  • merb-auth-more – dodatkowe opcje dla autentykacji, m.in. można kontrolować dostęp na podstawie modeli (podstawowy moduł skupia się na kontroli sesji)
  • merb-param-protection – filtruje i kontroluje dostęp do zmiennych w haszy params. Można np. zablokować możliwość wstrzyknięcia dodatkowych zmiennych za pomocą innego formularza.
  • merb-exceptions – zapewnia mechanizm automatycznego powiadamiania w wypadku wystąpienia gdzieś wyjątku w aplikacji. Możliwe jest powiadamianie mailem albo poprzez wysyłanie requestu POST na wskazany adres, który może dalej coś z tym zrobić (np. wstawić informacje o błędzie do bazy zamiast wysyłać mail)

DataMapper, wzorem Merb’a, jest równie podzielony na moduły. Domyślnie projekt włącza następujące gemy:

  • dm-core – główna funkcjonalność ORM’a.
  • dm-aggregates – dodaje funkcje agregujące (suma, wartość średnia, minimalna, maksymalna, count itp.)
  • dm-migrations – dodaje mechanizm migracji dla DataMapper’a.
  • dm-timestamps – dodaje “magiczne” metody created_at, updated_at automatycznie aktualizowane bez konieczności robienia tego ręcznie.
  • dm-types – dodaje możliwość korzystania z wysokopoziomowych typów dla pól modelu (podobnie jak ma ORM w Django) a nie tylko standardowych, dostępnych przez relacyjną bazę danych.

Projekt bazujący na powyższych, domyślnych gemach, generuje się za pomocą skryptu generatora:

merb-gen app myproj

Warto wiedzieć, że przeciwnie do Rails, merb-gen generuje jak i kasuje stworzone pliki.

Stworzenie kontrolera (wraz z plikami do testow):
meb-gen controller hello
Usunięcie stworzonych plików:
merb-gen controller -d hello
Dodatkowe opcje (m.in. można wybrać sobie inny rodzaj szablonów niż ERb czy test_unit zamiast domyślnego rspec):
merb-gen controller --help

Dostępne opcje wyświetlane switchem --help są dostępna różnie na różnych poziomach. Np. ogólną pomoc do generatora wyświetli merb-gen --help ale już pomoc dla generatora modeli wyświetla się za pomocą komendy merb-gen model --help. Warto tam zajrzeć, bo opis jest zwięzły ale czytelny.

Projekt podstawowy

Chwilowo DataMapper nie działa z JRuby (od stycznia ruszają ostre prace mające to zmienić). Także ci, co chcieliby użyć innego ORM’a zamiast generować projekt w sposób domyślny, powinni zainteresować się inną opcją.

merb-gen core myproj

Powyższa linijka tworzy podstawowy, minimalny projekt pozbawiony w ogóle pliku config/dependencies.rb z wyłączoną opcją obsługi baz (opcja use_orm w pliku config/init.rb jest zakomentowana). Oczywiście wygodniej jest bardziej sprofilować tworzony projekt (zobacz merb-gen core --help). Np. załóżmy, że chcemy stworzyć projekt używający ActiveRecord jako ORM i Haml jako system szablonów:

merb-gen core myproj --orm=activerecord --template-engine=haml

Co jednak z plikiem config/database.yml? Można go ręcznie stworzyć, albo wpierw wygenerować jakiś model i odpalić aplikację (lub konsolę: merb -i) Merb wtedy stworzy plik database.yml.sample. W wypadku ActiveRecord będzie to plik dla MySQL (na razie ta opcja nie jest aż tak elastyczna jak w Rails, gdzie za pomocą switcha -d można tworzyć domyślne ustawienia początkowe dla różnych baz). Jak komuś potrzeba domyślnych ustawień dla innej bazy, może po prostu stworzyć sobie czysty projekt Rails z odpowiednią opcją i skopiować plik database.yml (np. rails -d postgresql testproj).

Dla miłośników Sinatry i innych mikroframeworków.

Poza Rails i Merb’em, od czasu udostępnienia Rack’a mamy niezły wysyp małych frameworków Ruby’ego. Niektórzy chcieliby coś bardzo prostego, dosłownie na jeden plik. Rails nie ma tu nic do zaproponowania, z definicji tworzy pełny projekt z masą domyślnych modułów. Merb potrafi też tworzyć projekt z grupą proponowanych domyślnie modułow, ale potrafi też tworzyć mały projekt podstawowy który można sobie potem rozbudować o opcje jakie chcemy używać. Jednak poza merb-gen app myproj i merb-gen core myproj Merb pozwala tworzyć jeszcze mniejsze projekty za pomocą

merb-gen flat myproj

I zupełnie skrajnie mały

merb-gen very_flat myproj

Ta ostatnia opcja to cały framework w jednym, małym pliku. Ci, co chcieliby czegoś prostego na wzór mikroframeworków takich jak Sinatra, Mack, waves czy camping, mogą wybrać powyższą opcję very_flat. Merb jest tu jednak o tyle lepszy od tych mikroframeworków, że pozwala na łatwą rozbudowę od takiego małego projektu do dużego, poskładanego ze slices.

Merb czy Rails?

Tak naprawdę, liczy się to co potrzebujemy. Rails jest dłużej w użyciu, ma większą bazę użytkowników i mnóstwo książek. Minęły już też czasy, kiedy Rails był wolniejszy od jakichkolwiek frameworków opartych na PHP. Aktualna wersja Rails jest sporo szybsza od wszelkich znanych mi frameworków PHP. Różnica jest tym większa im większy projekt. (PHP bardzo zwalnia przy większym kodzie w związku ze swoim sposobem pracy – a konkretnie – koniecznością inicjowania i niszczenia wszystkich swych obiektów za każdym przeładowaniem strony). Ruby jest po prostu dużo lepiej zaprojektowanym językiem.

Merb z całą pewnością trafi do tych, którzy chcieliby z jednej strony – większej wydajności (Merb jest 3-5x szybszy od Rails i kompletnie deklasuje frameworki napisane w języku PHP), a z drugiej – większej elastyczności i modularności. Osobiście bardziej do mnie przemawia filozofia Merb’a. Uważam też, że Merb jest solidniej zaprojektowany i lepiej od Rails nadaje się do większych projektów (m.in. dzięki silnemu wsparciu dla komponentów i dużej wydajności) Nie bez znaczenia jest także, to że twórcom Merb’a udało się już zainteresować samego twórcę języka RubyYukihiro Matsumoto (Matza) którego wsparcie może nieźle spopularyzować Merb’a (tak jak stało się z Django dzięki poparciu Guido van Rossum, twórcy języka Python).

Z chwilą wydania Merb’a 1.0 agregator blogów wypełnia się coraz ciekawszymi artykułami. Widać też wyraźnie, że pojawienie się Merb’a 1.0 wstrząsnęło społecznością skupioną wokół Rails. Sam DHH na razie stara się w blogu nie używać słowa “Merb”, ale widać, że ostatnie jego posty w blogu są pośrednią polemiką częściowo także wobec argumentów podnoszonych przez miłośników Merb’a (vide problem monolityczności Rails na który błyskawicznie odpisał w swym blogu Yehuda Katz, jeden z czołowych developerów Merb’a)

Tagi , , , ,  | 33 comments

Comments

  1. Avatar Jan Koprowski powiedział about 5 hours later:

    Na dniach będę przygotowywał prezentację o Merbie, na spotkanie dla harcerzy i harcerek w Warszawie :] Powiem szczerze, że tak jak od pewnego czasu śledzę Merba jest to moim zdaniem coś fenomenalnego. Na wersję 1.0 Django czekało się – dłuuuugo, wersja 1.0 Merba wyszła (w porównaniu z Django o Pylons nie wspomnę) – błyskawicznie.

    Dalej. Na wersję 2.0 mamy czekać mniej niż 12 miesięcy – na wersję 2.0 Rails też trzeba było trochę czekać.

    Przy tym ! Projekt jakim jest Merb (o ile dobrze odczytuje wątku wielu osób – w przeciwieństwie do Rails) musi spełniać wyśróbowane wymogi coding-standards, wydajnościowe, projekcyjne i kilkanaście innych.

    Większe wymagania dla developerów, krótszy czas wydaniowy, wyśrubowane wymagania – szacunek dla ludzi, którzy to piszą ! Chylę głowę !

  2. Avatar kazik powiedział about 7 hours later:

    Merba a nie Merb’a. Sorry, ale ten blad wystepuje tak czesto, ze musialem Ci zwrocic uwage.

    Zeby nie odbiegac od tematu wpisu – moze Twoja kolejna ksiazka (czekam na obecna) bedzie o Merbie wlasnie?

    Pozdrawiam

  3. Avatar Radarek powiedział about 8 hours later:

    Bardzo fajny tekst jako wprowadzenie do merba. Mnie dodatkowo podoba się to, że merb oficjalnie wspiera różne pluginy (gemy merb-*), od czego railsy umywają ręce. Potem jak się szuka jakiegoś plugina to okazuje się, że jest takich 10, z czego 5 nie działa z najnowszą wersją, a pozostałe są przepełnione meta-programowaniem.

  4. Avatar Radarek powiedział about 8 hours later:

    ...a pozostałe są przepełnione meta-programowaniem, co często prowadzi do dziwnych zachowań, które ciężko wyśledzić.

  5. Avatar Jiima powiedział about 8 hours later:

    @JZ Co do DataMappera, nie chcę być złośliwy, ale on w ogóle nie jest przygotowany do pracy. Natywne rozszerzenia w Data Objects nie ratują wydajności, a blokują wybitnie międzyplatformowość. Napisanie ich w Javie nie rozwiąże problemu. Szkoda, bo DM ma o wiele większe możliwości niż np. AR. Niestety, twórcy wyraźnie nie wyrabiają tempa narzuconego przez Yehudę i resztę ekipy Merba (teoria głosiła że DM 1.0 wyjdzie równo z Merbem 1.0).

    Co do JRuby, ja bym raczej zastanowił się nad adaptacją GORM-a z Groovy do JRuby (nie wiem czy to możliwe, w bebechy GORMa jeszcze nie zaglądałem). To fajna dynamiczna warstwa pośrednia do JPA/Hibernate, aż żal że w JRuby nie ma podobnej. Zaś jak mamy siedzieć w JVM, to JPA naprawdę jest o wiele lepiej zintegrowany z środowiskiem i oferuje support (w tym komercyjny) do większej ilości baz niż jakikolwiek ORM Ruby.

  6. Avatar Jiima powiedział about 8 hours later:

    Co do PHP, to wreszcie nadmieniłeś istotę problemu frameworków PHPowych – całe drzewo klas jest w nich ładowane przy każdym requescie. Dlatego najszybszy jest Igniter, który ma tych klas mało i są względnie proste (jeszcze szybszy jest mój prywatny, napisany dla zabawy MVC, który ma tylko 3 klasy i wbrew pozorom spore możliwości). Ponadto nie wiem czemu wszyscy uparli się używać autoload’a, co dodatkowo zabija wydajność (doctrine ma opcję kompilacji frameworka do jednego pliku, co zdecydowanie daje mu wydajnościowego kopa w stosunku do wersji bezpośrednio wyjętej z paczki). RoR da się zainstalować jako CGI również i nie chcę wspominać nawet jak bardzo wtedy jest mało wydajny. Acha, jeszcze sprawdziłem odnośnie GC w PHP – w zasadzie nie istnieje. Mamy reference-counting, w dodatku o jakości porównywalnej z GC w COM Microsoftu (tzn. referencje cykliczne żyją forever). Nikt tego nie zamierza poprawiać w najbliższym czasie, bo przecież i tak pamięć posprząta się sama po zakończeniu skryptu…

  7. Avatar himn1 powiedział about 14 hours later:

    @Jiima Nie jest do końca prawdą, to co mówisz na temat tego, że w frameworkach napisanych w PHP całe drzewo klas jest ładowane przy każdym requeście. Znaczy pod kontem traktowania tego jak zarzut. To tak jakbyś oceniał railsy przez pryzmat środowiska developerskiego, gdzie dzieje się podobnie. W środowisku produkcyjnym, aby wyeliminować wielokrotne kompilowanie kodu źródłowego do postaci drzewa kodów operacji, stosuje się tzw. pamięci podręczne kodów operacji, które kompilują kod źródłowy od postaci kodów operacji i składują tak przetworzoną wersję skryptu w pamięci podręcznej. Sama kompilacja może zająć nawet 1/3 czasu generowania strony, dlatego wydajność znacznie wzrasta. Sam komfort pracy z CodeIgniterem np. a Railsami to już inna sprawa, ale warto wziąć sobie poprawkę na wyniki testów porównujących wydajność równych frameworków.

  8. Avatar Radarek powiedział about 15 hours later:

    @himn1: czy to o czym piszesz załatwiają wszelakie akceleratory PHP czy jeszcze trzeba coś dodatkowego użyć?

  9. Avatar himn1 powiedział about 16 hours later:

    Popularnymi narzędziami typu “opcode caches” są: komercyjna platforma Zend, APC (Alternative PHP Cache), która jest częścią repozytorium PECL oraz eAccelerator (następca nierozwijanego już Turck MMCache). Czyli chodzi o narzędzia popularnie zwane “akceleratorami”.

  10. Avatar Jarosław Zabiełło powiedział about 19 hours later:

    @himn1: Problem ciągłego tworzenia i niszczenia wszystkich obiektów za każdym requestem wynika ze sposobu pracy PHP (który był projektowany do pracy w stylu CGI) i żaden akcelerator tego nie zmieni. Im większy projekt z tym większą ilością obiektów PHP musi walczyć. Dlatego większe frameworki (Symfony) czy CMS (ezPublish) są tak wolne. Po prostu PHP był pierwotnie zaprojektowany jako proceduralny język szablonów i trochę na siłę zrobiono z niego język do budowania złożonych aplikacji webowych (próbowano nawet użyć go do tworzenia aplikacji desktopowych, co jest już zupełnie bez sensu).

    Jednakże ilość pracy (i frustracji) potrzebna do stworzenia i utrzymania aplikacji, którą można lepiej i łatwiej zbudować w Django, Rails czy Merbie, nie jest chyba tego warta.

    IMHO rola PHP będzie coraz bardziej maleć. Widać wyraźnie, że rozwój PHP zwalnia. Nie ma chętnych do jego rozwijania. Zobacz jak długo utknęli na wersji alpha1 PHP 5.3. Myślę, że ta technologia się kończy.

  11. Avatar Paweł Kondzior powiedział about 20 hours later:

    Zmierzch Supergwaizdy webdevelopmentu ;]

  12. Avatar szymon powiedział about 21 hours later:

    Ło matko, php upadnie?... co teraz poczną dziesiątki firm z mojego miasta, które dają setki ogłoszeń na temat programisty php/mysql (koniecznie ze znajomością photoshopa i flasha) proponując pensję w granicach błędu statystycznego. Pewnie firmy będą miały się dobrze, studenci już teraz uczą się nowego super cool języka jakim jest python, kod wielu takich stron w sumie niczym nie różni się od tego co widujemy często w php.

  13. Avatar himn1 powiedział about 22 hours later:

    @J.Zabiełło Pomijając fakt, jakie były cele podczas projektowania PHP, nie da się ukryć, że użycie akceleratora znacznie podnosi wydajość. > rok temu, przywołałeś nawet na blogu test niejakiego Alronda zdaje się, w którym wydajność duetu CodeIgniter + eAccellerator wzrosła o kilkaset procent, w stosunku do samego CI i to tylko jest ważne.

    “Jednakże ilość pracy (i frustracji) potrzebna do stworzenia i utrzymania aplikacji…” – pisałem o tym w pierwszym komentarzu, chociaż CodeIgniter i Rails być może wydajnościowo odpowiadają sobie, to jednak ten drugi jest frameworkiem dużo bardziej złożonym. W CI nawet o określeniu powiązań między tabelami możemy zapomnieć. Wybierając CI do złożonych aplikacji, lepiej jeszcze raz się zastanowić..

    A co do tego, że popularność PHP będzie maleć – możliwe, ale nie sądzę, że w mocno zauważalny sposób. Nawet jeśli rozwój bardzo zwolni, to jak wiele osób nadal dziś korzysta z PHP4? Passenger też miał sprawić, że Railsy bedą w ofercie większości firm hostingowych.. Obecnie unikam programowania w PHP, Railsy pozwalają mi na pisanie na dużo wyższym poziomie, niż CI np. a i przyjemność jest nieporównywalnie większa, jednak gdybym miał zrobić stronę-wizytówkę, z minimalną funkcjonalnością, to wybrałbym CI, głównie ze względu na popularność PHP na hostingach współdzielonych. Nisza na PHP będzie jeszcze długo.. do tego duża popularność, ‘łatwy’ hosting i liczba firm które stworzyły w PHP swoje produkty, powodują, że jeszcze przez długi czas będzie w czołówce popularności…

  14. Avatar Paweł Kondzior powiedział about 23 hours later:

    @szymon: a zdazylo sie zeby jacys studenci uczyli sie php ?

  15. Avatar himn1 powiedział about 23 hours later:

    @Paweł Kondzior Na WSI w Bielsku Białej nadal uczą PHP w wersji… 3 (słownie trzeciej)

  16. Avatar Jarosław Zabiełło powiedział 1 day later:

    @himn1: wiem, że akcelerator zwiększa wydajność, po to jest. Ale ma swoje granice. Nie jest w stanie przezwyciężyć konieczności tworzenia i niszczenia obiektów i zmiennych w PHP za każdym przeładowaniem strony. A to są kosztowne operacje rosnące wraz z wielkością kodu. Ruby nie ma tego problemu, bo na serwerze pracuje bardziej jak serwlet niż CGI. Frameworki PHP nawet z akceleratorem są wolniejsze od nowego Rails i Merba. Nie mówiąc o JRuby, który nie dość że kompiluje kod, to na dodatek używa agresywnej optymalizacji JIT’t co pozwala mu “rozgrzać się” do szybkości nieosiągalnych dla rozwiązań opartych na bibliotekach C/C++.

  17. Avatar szymon powiedział 1 day later:

    @Paweł, fakt, nadużycie, wybacz, studenci używają php, nie to żeby się czegokolwiek tam uczyli

  18. Avatar jiima powiedział 1 day later:

    @Himn1

    Problem z akceleratorem jest taki, że bez uzależniania aplikacji od konkretnego akceleratora (np. APC), składuje on TYLKO bytecode. A kompilator PHP nie jest wcale taki wolny. Konstruowanie frameworka, instancjacja obiektów itp. odbywa się za każdym razem. W trybie developerskim Rails rekonstruowane są tylko niektóre obiekty. Oczywiście, takie APC udostępnia na przykład pamięć zmiennych, ale np. obiekty są w niej przechowywane w postaci zserializowanej, poza tym API poszczególnych akceleratorów jest niekompatybilne. Rozwiązaniem byłoby napisanie aplikacji w PHP która udostępnia interfejs FCGI / SCGI / cokolwiek (albo użyć PHPowego serwera HTTP który już z resztą ktoś napisał). Niestety, memory management PHP zniechęca do takich rozwiązań (aplikacja będzie najprawdopodobniej “puchnąć” z czasem, zwłaszcza jeśli użyjesz jakiegoś ORM-a). BTW, jeśli już mówimy o przyspieszaniu PHP, sprawę poprawia nawet upakowanie kodu do mniejszej ilości plików, zamiast udawania Javy / Perla i pakowania jednej klasy na plik, po czym wciągania wszystkiego przez autoload.

    @JZ PHP umiera? No nie wiem, jest za nim kasa. Nawet jeśli będzie animowanym trupem pod względem rozwojowym (chyba idea namespaces i closures nie spodobała się “prawdziwym PHPowcom”) to ten zombie będzie funkcjonował. Popatrz na Zenda, IBM, Microsoft (sponsorowany przez nich Phalanger który jest lepszą wersją PHP niż oryginał), Borland (VCL dla PHP, ktoś tego używa????), Aptana… Poza tym Python i Ruby nie są za bardzo alternatywą. Czysty mod_python czy eRB nie są tak proste w korzystaniu, a mówimy o rozwiązaniu łopatologicznym. Wsparcie baz danych też nieporównywalne (nie mówię o jakości tylko o ilości) – PHP ma sterowniki do serii różnych baz, Python do SQLite, Ruby nie ma nawet standardowego API dla baz danych (owszem, PHP też, ale mówimy o językach z innej epoki, moim zdaniem język obiektowy powinien mieć uporządkowane API tego typu, albo jako hierarchię klas jak Java czy .NET, albo jako guidelines jak Python). Fakt że za Ruby i Python powoli zaczyna gromadzić się kasa jest nie bez znaczenia dla ich rozwoju. Dobrym przykładem może być tu Jython, który istniał sobie jako pet project, umierał ze dwa razy a teraz nagle przeskoczył z v. 2.2 na v.2.5 dzięki zatrudnieniu głowy projektu przez Suna. Iron Python też zmarłby śmiercią naturalną gdyby nie zaopiekował się nim M$. Może nie są to mainstreamowe interpretery Pythona, ale ich istnienie owocuje powstawaniem profesjonalnych narzędzi (nakładki na VS a ostatnio również na Netbeansy). Czyli jak zwykle nie liczy się to co dobre, ale to co kasowe. (oczywiście jeśli kasowe jest dobre, jak w wypadku Pythona to fajnie, ale biznes miał wielokrotnie tendencje do wspierania poronionych technologii jak COM / ActiveX, J2EE, XML…)

  19. Avatar Paweł Kondzior powiedział 1 day later:

    @jiima: zginie, jak kazda technologia, zastapi je cos innego, ale programisci nadla beda potrzebni bo ktos musi i utrzymac ten caly legacy code. PHP mialo byc pewna alternatywa dla Perla… jesli chodzi o rozwoj.. to wszystkei znaki na niebie i ziemi wskazuja ze podzieli los Perl’a.

  20. Avatar jiima powiedział 2 days later:

    @PK

    Los Perla powiadasz? Czyli: - Następna wersja umrze w wyniku stosowania antywzorca “Death by planning” - Wszyscy nadal będą używać wersji aktualnej, uzupełnionej o okazjonalne patche dotyczące głównie wielowątkowości i unicode - Stanie się de facto standardowym językiem skryptowym bez względu na wysiłki konkurencji - Dorobi się jednej z największych bibliotek modułów, o której inne języki mogą tylko pomarzyć. - Dorobi się serii “programistów” wyznających zasadę że im mniej czytelny kod tym lepszy.

    Ale nie umrze i nie zostanie zapomniany, a już na pewno nie będzie niszowy…

    Chyba lepiej by nie podzielił losu Perla, bo nigdy się go nie pozbędziemy…

  21. Avatar hmtt powiedział 14 days later:

    Witam!

    Rozdział o tytule “PHP” uważam w moim życiu za definitywnie zamknięty. W tej chwili poszukuję nowych technologii pozwalających na tworzenie wydajnych aplikacji internetowych w sposób czysty i przyjemny.

    W tej chwili jestem w trakcie testowania technologii takich jak RoR, Merb, Django, Pylons oraz Erlang.

    W chwili obecnej skupiam się nad tworzeniem środowiska prudukcyjnego i sprawdzaniem wydajności ale także sposobów wdrażania poszczególnych technologii.

    Oczywistym jest że RoR lub Merb to technologie które mają wielkie szanse na odniesienie sukcesu to znaczy osiągnięcia miana technologii dla ludu. Sam skłaniałem się w stronę Merba. Jednak ostatnio spotkało mnie niemiłe zaskoczenie. Instalowałem REE na wirtualnym systemie (Debian, Arch) i wszystko działa dosyć dobrze. Oczywiście skonfigurowałem wszystkie pozostałe elementy tej układanki to znaczy Passenger, Apache, RubyGems itp. Wcześniej testowałem Ruby, nginx + mongrel lub thin. A teraz trochę o tym niemiłym zaskoczeniu. Postanowiłem zainstalować REE na osobnym komputerze. Wybór padł na sprzęt z procesorem PIII 750 MHz i 256 MB RAM, system operacyjny Debian (Etch).

    Instalacja Ruby: OK Instalacja RubyGems: OK Instalacja Rails z gem: Tragedia

    Test powtórzyłem na innym komputerze o podobnych parametrach ale tym razem z systemem Linux Arch. Niestety okazało się że problem także tutaj występuje i na dodatek dotyczy on także Merba.

    Stwierdziłem że sprawdzę jak wygląda sytuacja z REE. Pobrałem pakiety źródłowe REE i uruchomiłem skrypt kompilujący. I tutaj znowu problem! Okazało się że kompilator nie jest w stanie prawidłowo kompilować REE z opcją tcmalloc. Kompilowanie bez tej opcji jest możliwe ale znacznie spowalnie działanie Apache+REE+Passenger. Na początku myślałem że to problem kompilatora i sprawdzałem różne ustawienia i wersje GCC. Nic to nie zmieniło. Stwierdziłem że uruchomię kompilacje na wirtualnej maszynie z bliźniaczym systemem operacyjnym ale uruchomionym na znacznie szybszym komputerze. Okazało się że kompilacja przebiegła bez żadnych problemów, oczywiście z włączonym tcmalloc.

    Jakie wnioski? Nie sądzę że gdzieś popełniłem błąd, chociaż i to jest możliwe. Można się długo zastanawiać i rozważać problemy wydajności technologii opartych na Ruby. Ja kolejny raz niemiło się rozczarowałem tą technologią. Sama idea i rozwiązania języka Ruby i paczek gem jest bardzo trafna tylko ja osobiście uważam że właśnie teraz, w dobie roznącej społeczności użytkowników RoR i samego języka Ruby, wychodzą braki samej implementacji języka Ruby. To że grupa Phusion tworzy coś takiego jak REE również świadczy o tym że w implementacji języka Ruby jest jeszcze wiele do poprawienia.

    Chciałbym jeszcze napisać o technologiach związanych z językiem Erlang. Osobiście uważam że to technologie z innej planety. Niestety mój komentarz wykracza już sporo poza treść wpisu Pana Zabiełło, także jego długość jest trochę przesadzona, dlatego może o tym napiszę innym razem ;)

    Pozdrawiam i gratuluję innowacyjnego pod względem treści bloga. Oby tak dalej Panie Zabiełło.

  22. Avatar Radarek powiedział 15 days later:

    hmtt, “Instalacja Rails z gem: Tragedia”. A dokładnie jaki problem był?

    “Niestety okazało się że problem także tutaj występuje i na dodatek dotyczy on także Merba.”

    Rozumiem, że chodzi o “Instalacja Merba z gem: Tragedia”;-). Dalej nie wiem co było nie tak?

    “Stwierdziłem że uruchomię kompilacje na wirtualnej maszynie z bliźniaczym systemem operacyjnym ale uruchomionym na znacznie szybszym komputerze. Okazało się że kompilacja przebiegła bez żadnych problemów, oczywiście z włączonym tcmalloc.”

    Szczerze w to wątpię. Jeśli to ta sama architektura, ten sam OS, te same wersje oprogramowania to nie widzę powodu by tak miało być.

    Ustosunkowując się do pozostałej części wypowiedzi. Oczywiście Ruby (jako język, platforma i jego implementacje) ciągle się rozwija. To nie ulega wątpliwości. Ale szybkość zmiana jaka zachodzi w tym świecie jest imponująca. Jeśli coś nie działa to zamiast wyżalać się w komentarzach czy nie lepiej byłoby skontaktować się z autorami danego oprogramowania?

    Proszę opisać szczegółowo problem (np na forum.rubyonrails.pl lub IRCu #ruby.pl) a na pewno ktoś znajdzie się do pomocy.

  23. Avatar hmtt powiedział 15 days later:

    Radarek: może nie wyraziłem się jasno. Chodzi o czas instalacji rail lub innych paczek poprzez gem. Ponad miesiąc temu udało mi się zainstalować rails z rubygems, niestety na słabym komputerze (PIII) trwało to ok godziny. W tym tygodniu sprawdziłem na różnych komputerach o podobnych parametrach czy problem rzeczywiście występuje. Okazało się że instalacja rails może trwać nawet ponad godzinę, nie wiem ile by trwała i czy by się zakończyła powodzeniem (zabrakło mi cierpliwości).

    Moja wypowiedź nie miała w żaden sposób zniechęcać do używania Ruby (rails, merb). Napisałem o swoich doświadczeniach i problemach na które niestety natrafiłem. Uważam że Ruby będzie odgrywał bardzo ważną rolę w świecie programistów.

    Możliwe że popełniam błąd stawiając obok siebie języki takie jak Ruby i Erlang. Pamiętam jak ok 7 lat temu uruchomiłem ma P166MMX, 48MB RAM, program Wings 3D napisany w Erlangu. Był to chyba jedyny program który płynnie działał na tym komputerze. Jak powstanie podobny program napisany przy pomocy technologii takich jak Ruby, JRuby czy Java i będzie tak samo dobrze działał to będę bardzo zadowolony ;)

    OK, koniec tego wypisywania moich idiotycznych teorii. Idę spać ;) Kiedyś się przekonacie i się ze mną zgodzicie.

  24. Avatar Radarek powiedział 15 days later:

    hmtt: nawet na najsłabszym PIII (450Mhz) instalacja nie powinna trwać tak długo. Podejrzewam, że to była kwestia ilości pamięci RAM. Jak dużo ma jej ten komputer? Proszę spróbować zainstalować gemy w następujący sposób:

    gem install rails --no-rdoc --no-ri

    “Moja wypowiedź nie miała w żaden sposób zniechęcać do używania Ruby (rails, merb). Napisałem o swoich doświadczeniach i problemach na które niestety natrafiłem.”

    Bynajmniej nie odebrałem tego jako zniechęcanie, bardziej jako marudzenie :). Problemy były i będą. Community Rubiego jest bardzo pomocne, trzeba po prostu przedstawić jasno problem.

    “Jak powstanie podobny program napisany przy pomocy technologii takich jak Ruby, JRuby czy Java i będzie tak samo dobrze działał to będę bardzo zadowolony ;)”

    “Use the right tool for the right job”. Piszesz super-skalowalny rozproszony serwer, z możliwością połączeń wielu klientów? Wybierz Erlanga. Piszesz aplikację do obsługi banku, chcesz bezpieczeństwa? Wybierz Javę. Piszesz aplikację webową? Wybierz Rubiego. Itp. Każdy z tych języków “działa dobrze”, trzeba tylko dobrze dopasować je do problemu. Zużycie zasobów to ważna kwestia, ale co raz częściej (i dobrze!) drugorzędna sprawa.

  25. Avatar Radarek powiedział 15 days later:

    Widzę, że blog zrobił swoje z poleceniem dla gem, więc wklejam link do pastie: http://pastie.org/331371

  26. Avatar jiima powiedział 16 days later:

    @hmtt

    Co do Rubygems rzeczywiście wymagają one poprawek (z resztą te poprawki na bierząco wchodzą, RG jako manager pakietów się rozwija). Problemem jest głównie indeks, który do niedawna (nie wiem czy już tego nie zmienili, ostatnio wypadłem trochę z obiegu) był zaciągany za każdym razem w całości, a jest już dość pokaźnym kawałkiem YAML-a. Podobne rozwiązania na innych platformach (Teapot dla TCL, easy-install Pythona czy CPAN perla) chodzą o wiele szybciej i nie jest to tylko kwestia wydajności języka (python i perl są rzeczywiście obecnie nieco wydajniejsze niż ruby, ale już co do TCLa śmiem wątpić).

    Co do szybkich programów w Javie – to jest szybki język. Specyfikacja Java real time pozwala na tworzenie aplikacji równie szybkich jak natywne i mających czas reakcji wystarczająco krótki by pisać w tym np. aplikacje kontroli lotu. Tak więc szybkość porównywalna z vm erlanga. Jedyne czego Javie w tym polu brakuje to hot-swappingu na poziomie oferowanym przez Erlang vm (w Javie jest hot swapping ale jest to funkcja debuggera i chyba nie działa w trybie produkcyjnym). Jedynie startup time pozostawia wiele do życzenia, ale nad tym Sun też pracuje.

    Co do porównania kompilowanego języka funkcyjnego z dedykowaną maszyną wirtiualną do interpretowanego języka dynamicznego, chwilowo bez maszyny wirtualnej, to wybacz, ale porównywanie samolotu z samochodem nie ma specjalnie sensu. Języki interpretowane mają inne zalety i inne zastosowania. Ja na przykład lubię języki funkcyjne, ale nie znam wielu innych entuzjastów tych technologii, przeciętny “programista z ulicy” dwa razy padnie trupem zanim napisze coś w Erlangu czy Ocamlu, o takim Haskellu nie wspominając. Tak więc stwierdzenie że są to języki z innej planety ma sporo sensu, ale nie jest to raczej komplement…

  27. Avatar climbus powiedział 16 days later:

    Spotkałem się raz z wolnym instalowaniem gemów. Problem leżał po stronie dnsy czy revdns. Tak bywa na niektórych konfiguracjach. Niestety nie pamiętam jak problem rozwiązałem.

  28. Avatar Jarosław Zabiełło powiedział 16 days later:

    To było kiedyś. Teraz RubyGems 1.3.1 jest szybki. Zresztą poprawili to znacznie już od wersji 1.2. Można też doistalować sobie gem o nazwie ‘minigems’, i używać lżejszego skryptu minigem zamiast gem.

  29. Avatar hmtt powiedział 16 days later:

    @JZ: niestety w wersji 1.3.1 problem nadal występuje. Moim zadaniem ta wersja to nie jest jakaś wielka rewolucja. Minigems jeszcze nie sprawdzałem.

    @climbus: u mine prawdopodobnie nie jest to problem związany z dns. Podczas instalacji z gem dysk twardy potrafi cały czas pracować przez kawał czasu co by mogło świadczyć o problemie z samym Rubygems. Jeszcze raz przypominam że instalowałem na różnych komputerach więc problem wadliwego dysku twardego lub systemu operacyjnego nie wchodzi w grę.

    @jiima: w większości się z Tobą zdecydowanie zgadzam.

    @Radarek: co do odpowiedniego przeznaczenia konkretnych języków programowania czy technologii to muszę Tobie przyznać rację.

  30. Avatar Paweł Kondzior powiedział 19 days later:

    @hmtt: zjaw sie jesli masz czas na #rubyonrails.pl ktoregos dnia i popyutaj omnie albo o radarka, chetnie ci pomozemy, byc moze jest to jakis bug rubygems a byc moze robisz po prostu cos zle.

    Faktem jest ze instalacja z gemow jest wolna, ale wynika to tylko i wylacznie z tego iz kazdy gem generuje dokumentacje na podstawie zrodel (ri i rdoc). Mozna to wylaczyc, w 99 % przypadkow nie jest to potrzebne, aczkolwiek sie przydaje uzyc czasem ri String#gsub w konsoli.

    Czy po tym jak radarek zaproponowal ci instalcje bez generowania dokumentacji, poczules jakas roznice ? tj:
    gem install rails --no-rdoc --no-ri 
  31. Avatar Paweł Kondzior powiedział 19 days later:

    Oczywiscie chodzi o #rubyonrails.pl na irc.freenode.net

  32. Avatar Szymon powiedział about 1 month later:

    Widze ze rozgorzala tez dyskusja na temat PHP vs reszta swiata ;) Wlasnie sie ucze Python/Django, myslicie ze Merb jest lepszy? Z tego co wiem to Django jest szybsze niz np RoR. Dzieki za info :)

  33. Avatar Jarosław Zabiełło powiedział about 1 month later:

    @Szymon,

    Django zostało wyodrębnione z komercyjnego CMS’a – Ellington, stąd pewne jego ukierunkowanie. Django jest sprawdzone w dużych portalach, ale trudniejsze, wolniejsze i monolityczne. (Praktycznie przy jakimkolwiek większym projekcie słyszy się, że trzeba hackować kod źródłowy aby jakoś omijać ograniczenia Django) Dużo bardziej elastyczny jest Pylons, ale ten z kolei jest dużo bardziej skomplikowany.

    Merb został stworzony jako framework ogólnego zastosowania (z naciskiem na wydajność i modularność). Od strony inżynierskiej został bardzo solidnie zrobiony. Merb skorzystał też z doświadczeń po Rails. Ogólnie można powiedzieć, że Merb jest szybszy i znacznie bardziej modularny od Django. Np. nie ma problemu z pracą z wieloma bazami, świetnie (i b. szybko) działa w JRuby (Jython jest tu dużo wolniejszy i mniej dojrzały), ma zdecydowanie lepszy resolver URL djangowego. W Merbie można wybrać sobie dowolny ORM (z których np. Sequel ma większe możliwości od djangowego), można wybrać dowolny system szablonów, a nawet system automatycznego testowania kodu (RSpec, TestUnit). Można też projekt zamienić w gem (pakiet podobny do egg w Pythonie) i z takich klocków składać sobie następne aplikacje.

    Merb się niedawno połączył z Rails, co powinno zaowocować jeszcze lepszymi możliwościami mającego nadejść Rails 3. Nie bez znaczenia jest też kwestia prostoty. Merb/Rails są łatwiejsze do opanowania i użycia (bariera wejścia w Django jest moim zdaniem wyższa), a kod Ruby’ego po prostu jest ładniejszy.

(leave url/email »)

   Pomoc języka formatowania Obejrzyj komentarz